5G基础信令详解：三层协议栈与注册、会话、切换流程指南

简介面向5G网络工程师、通信协议开发与测试人员的《5G基础信令基础讲解》PPT课件系统梳理了5G相对4G的新特性与无线网络架构重点解析控制面的UE状态、RRC连接建立/重配/重建/恢复/释放/RLF、统一接入控制、系统信息、寻呼、移动性管理、SUL及EN-DC双连接用户面部分则详细讲解整体流程、新QoS机制、PDCP split与duplication、精简RLC以及SRB到CCCH/DCCH信道的承载映射。课件还对比了4G/5G高层协议规范框架覆盖36系列与38系列主要协议号便于读者按协议栈对照学习并总结了On-demand SI、Inactive态、BWP、RNAU、Flow vs Bearer、波束管理等5G关键技术特性。资源共1个PPTX文件大小约3.65MB已有400人学习适合作为5G信令流程的系统入门与工作复习参考。1. 5G基础信令为什么值得专门讲一讲一个新开的5G基站现场指标什么都好RRC建立成功率99.5%可用户一打电话就断核心网侧没收到任何异常告警。两边工程师坐在一起看数据一个说终端没发起注册另一个说网络没下发响应。这种扯皮我见过太多次最后打开信令抓包一句话都不用吵——谁的消息没到到没到哪一步一清二楚。5G基础信令说白了就是把UE和网络之间那些看不见的“对话”翻译成可读的流程。你不需要把3GPP规范背下来但你需要知道一条注册流程要过几道门、每个环节等多久、失败时看哪个定时器。这份课件式的讲解就是用来带新人、做实训室方案、或者在排查现场把责任边界划清楚的。它适合三类人刚转岗5G的网优和基站工程师需要快速建立信令主线的培训讲师以及做5G实训室方案、要把信令教学落地的技术负责人。2. 5G协议栈详解三层信令接口的职责与嵌套2.1 协议栈结构RRC、NAS、NgAP各自站在哪先画一张控制面的地图。UE和gNB之间走的是RRC协议UE和AMF之间走的则是NAS协议gNB和AMF之间走的是NgAP。三层接口两段链路这是解读所有信令流程的地基。很多新手看信令流程喜欢先记消息名RRC Setup Request、Initial UE Message、Registration Accept背得挺熟但不知道它们之间谁嵌套谁。这个顺序一乱后面看什么都是云里雾里。我一般建议先把“消息在哪条接口上、由谁封装、送给谁”搞清楚再去看具体内容。NAS层又分成两个子块MM负责移动性管理管注册、鉴权、位置更新SM负责会话管理管PDU会话的建立、修改、释放。RRC层负责空口上的资源管理和NAS消息搬运gNB侧再把NAS消息装入NgAP的Initial UE Message送到AMF。反过来核心网下发的NAS消息通过Downlink NAS Transport到gNB再由RRC封装发给UE。这个“乘客-车厢”关系比任何一条具体消息都重要。2.2 5G协议栈详解三层接口的信令任务与承载关系RRC作为空口信令的老大负责连接的建立、重配、释放还要管测量配置、安全模式激活和切换命令。最常看到的几条RRC Setup Request、RRC Setup、RRC Reconfiguration、RRC Release、Measurement Report。它们全部跑在SRB上SRB0传RRC建立消息SRB1建好后传后续RRC和NASSRB2专门承载高优先级的NAS消息比如非紧急的NAS信令。NAS走的是逻辑通道不直接暴露在空口而是被RRC当成负载扛过空口。典型消息包括Registration Request、Authentication Request、Identity Request、PDU Session Establishment Request。这些消息到了gNBRRC层根本不理业务内容只负责原封不动打包成NgAP消息继续往上送。NgAP位于gNB和AMF之间的SCTP连接上标准端口号通常用38412。它做的事情更偏“管理”NG Setup完成站点注册Initial Context Setup把用户上下文从核心网下发到基站PDU Session Resource Setup为会话分配资源Handover相关流程负责移动性的网络侧准备。三个接口有清晰的职责边界RRC管无线侧的状态和资源NAS管移动性与会话业务逻辑NgAP管核心网与基站的协作。这样拆分之后看流程图就不会再纠结消息该出现在哪一层。2.3 信令超时参数先认识这几个数字信令流程能跑通一半靠消息正确另一半靠定时器别乱跳。定时器就是每条流程的“等待时长”超时之前没等到预期响应就直接判定失败。终端侧的定时器里T300等RRC Setup响应T304等切换完成响应T310判断无线链路是否彻底失步。NAS层T3510等Registration AcceptT3512控制周期性注册更新T3520等Service Accept。网络侧也有对应定时器gNB侧T300反向等待UE的RRC Setup CompleteAMF侧则跟踪整条注册流程的处理超时。做排查时谁先超时问题边界基本就在谁身上。定时器所在层启动条件超时判定T300RRCUE发出RRC Setup Request未收到RRC Setup或拒绝判定RRC建立失败T304RRC收到切换命令或重配未完成目标小区随机接入判定切换失败T310RRC检测到物理层失步未恢复同步进入无线链路失败流程T3510NASUE发出Registration Request未收到Registration Accept/Reject重置流程T3512NAS周期性定时主动发起周期性注册更新T3520NASUE发出Service Request未收到Service Accept/Reject需重试这些参数在商用设备里基本都可配常见值T300从100ms到2000ms不等T3510是15秒左右T3512默认300秒以上。讲解信令时把这些数字放进流程图对应位置比单独列一页参数表好懂得多。3. 三大流程拆解注册、会话建立与切换的信令时序3.1 注册流程从RRC Setup到Registration Accept的一整条链路注册流程是理解5G信令的“hello world”。终端开机后先做小区搜索然后随机接入接着发起RRC连接建立。RRC Setup Request里携带的是初始UE身份如果终端之前注册过带的是5G-GUTI否则会用SUCI。gNB回复RRC Setup给终端分配SRB1UE回RRC Setup Complete这一步开始NAS消息就上车了。RRC Setup Complete里封装着第一条NAS消息Registration Request。gNB收到后不做业务解析直接把它封装进NgAP的Initial UE Message发给AMF。到了AMF才真正开始核心网侧的处理如果带了GUTI就直接识别用户如果没有就先触发身份请求走鉴权流程然后下Security Mode Command激活NAS和AS安全。空口侧的安全由RRC Reconfiguration完成其中带上安全配置参数。AMF回Registration Accept时路径是反的NgAP Downlink NAS Transport到gNBgNB把它放进RRC UL Information Transfer的下行版本发给UE。UE回Registration Complete整条注册流程闭环。从头到尾消息跨了三条接口但真正的业务逻辑只在NAS层发生RRC和NgAP都只是搬运工。3.2 PDU会话建立流程用户面打通前发生了什么注册成功后用户要上网还需要建立PDU会话。终端发起NAS的PDU Session Establishment Request里面带上PDU会话ID、S-NSSAI、DNN、请求的QoS类别。AMF收到后会先和SMF确认切片和会话策略用户面网关准备好之后再通过AMF下发PDU Session Resource Setup Request给gNB消息里包含核心网分配的用户面隧道信息、QoS Flow和对应的承载参数。gNB这时候要干一件关键事把核心网的会话参数翻译成空口配置通过RRC Reconfiguration下发给UE。里面会带DRB的建立配置比如DRB标识、QoS映射关系、PDCP配置、RLC模式以及MAC和物理层相关参数。UE收到后配置好底层协议栈回RRC Reconfiguration Complete。gNB确认空口承载建立成功再给核心网回PDU Session Resource Setup Response带出gNB侧的用户面隧道信息。这条流程里最容易出问题的字段都在RRC Reconfiguration里QoS Flow到DRB的映射如果没下发终端就不知道哪个业务走哪条承载DRB的RLC模式如果配错高清视频可能会断断续续。信令讲解到这里时要跟峰值速率的计算结合起来看——PDCP层吞吐、MAC调度周期、MCS等级这些参数最终决定了用户面能跑多快这也是5G信令和4G信令在讲解深度上一个明显的分水岭。3.3 切换流程A3事件测量与T304的配合移动性管理是5G基础信令里看起来简单、实际最容易翻车的一块。首先是测量阶段gNB通过RRC Reconfiguration下发测量配置里面包含测量对象、上报周期、事件阈值最常用的是A3事件。A3事件的进入条件可以写成这个形式邻区RSRP加上偏置高于当前服务小区RSRP再加上迟滞。小区偏置和迟滞这两个参数直接决定切换的灵敏程度调小了频繁切换调大了容易掉话。UE上报Measurement Report之后源gNB判断需要切换会通过NgAP发起切换准备目标gNB做准入控制并准备好资源返回切换命令相关信息。源gNB把这些封装成RRC Reconfiguration下发给UE这条消息里带上目标小区的同步配置UE在目标小区发起随机接入成功之后上报RRC Reconfiguration Complete目标gNB再通过NgAP通知核心网切换路径把用户面从源侧改到目标侧。整个过程中T304是核心的兜底定时器。UE从收到切换命令开始计时如果在T304内没完成目标小区接入就会判定切换失败进入RRC重建用户业务中断。排查切换问题时先看Measurement Report有没有上报再测目标小区的PRACH配置和随机接入前导最后看T304是否超时这几步能筛掉80%的切换问题。4. 用5G信令定位问题抓包入口、过滤语法与排查逻辑4.1 抓包前的准备日志入口在UE、DU/CU、AMF哪里找信令排查第一步不是打开Wireshark而是先知道日志从哪里导。商用基站的硬件通常按AAU、DU、CU三级部署信令跟踪入口也分散在这几个层级AAU侧一般只有射频指标和告警信令细节很少DU侧能看到调度、RLC、MAC和部分RRC日志CU侧才有完整的RRC和NgAP。也就是说你要查空口建链问题DU日志优先要查核心网交互问题CU的NgAP日志才是关键。如果用的是开源研究环境比如OpenAirInterface这类5G实现日志输出会更透明也能看到每条NAS消息的原始内容。终端侧的抓包通常用商用测试工具导出空口日志里面能同时看到RRC和NAS消息是确认“终端到底发了什么”的最直接证据。工程人员最容易犯的错是只抓一端。UE侧报了注册失败就去抓空口基站侧说是核心网问题就去抓CU日志。实际上注册流程跨了UE、gNB、AMF三段至少需要空口日志和NgAP日志配合着看才能锁定丢消息的位置。4.2 Wireshark过滤5G信令的常用语法拿到日志并转成pcap后Wireshark的过滤语法值得记几条。下面这组是实战里最常用的# 只抓NgAP消息38412是最常用的SCTP端口 sctp.port 38412 || tcp.port 38412 # 只看5G NAS层消息新版本Wireshark的协议名 nas-5gs # 只看RRC空口信令 rrc # 在NgAP消息里过滤带NAS负载的帧 ngap.NAS-PDU逻辑说明NgAP跑在SCTP之上所以先按端口抓协议NAS消息被封装在RRC和NgAP里面直接过滤协议名只能看到独立解析的NAS帧想要看它被哪个RRC或NgAP消息携带就得用承载协议字段去定位。最后一行的ngap.NAS-PDU就是把gNB和AMF之间传递的NAS消息单独挑出来配合上下行方向信息能快速看清核心网回给终端的到底是Accept还是Reject。参数说明端口过滤适合核心网侧抓包nas-5gs是较新版本Wireshark的协议名旧版本可能叫NAS实际用的时候以协议解析窗口里显示的名为准。现场如果发现NAS过滤不出来先确认pcap里协议解析器有没有加载5G相关配置。4.3 排查实操按“NAS失败还是RAN失败”定边界实战排查我习惯先做“边界划分”看失败消息出现在哪条链路上。如果RRC Setup都完成了但NAS的Registration Reject直接下发问题大概率在核心网侧如果RRC建立过程本身就超时中断问题大概率在空口或基站。用注册失败举例。先抓CU侧NgAP日志看到Initial UE Message有没有正常送到AMF如果送了再看Downlink NAS Transport里带的是Accept还是Reject如果是Reject看cause code网络侧拒绝和终端侧拒绝的原因值含义完全不同。如果下行NAS消息迟迟不来这时候回到UE侧看T3510是否超时T3510超时意味着AMF没在时间内给响应可能是AMF过载、切片不匹配或者安全流程没走完。PDU会话失败也走同样的逻辑PDU Session Resource Setup Request如果没到gNB是核心网和切片协商的问题到了gNB但RRC Reconfiguration没完成就是空口承载建立问题。先划边界再看具体字段这是信令排查的固定动作。5. 讲清基础信令最容易踩的五个坑5.1 把无线链路失败和切换失败混为一谈现象一个问题用户上报“切换失败”排查时直接把T304和A3事件翻来覆去调但实际问题出在源小区无线链路质量太差UE早就触发T310进入无线链路失败流程连测量报告都没来得及发。原因两类失败在现象上接近终端都会出现短暂的业务中断但信令触发点完全不同。解决先看Measurement Report有没有上报。有上报再查切换参数没有上报重点看T310和物理层失步告警这两个方向差得很远。5.2 只看NAS消息不看RRC上下文现象抓空口日志看到Registration Reject直接下结论“核心网拒发”。原因NAS Reject虽然是核心网发的但触发原因可能是RRC安全模式配置没有完成。AMF下发了安全参数UE侧AS层没生效核心网判定终端不具备接入条件才会回Reject。解决看Reject之前有没有完整的RRC Reconfiguration完成消息安全上下文有没有建立。信令流程是一环扣一环的跳过中间环节直接看结果很容易误判。5.3 参数记串T3510和T3520不分现象排查终端无法驻网问题看到终端发了Registration Request就盯着T3510等不到超时却发生在新流程重发。原因两个定时器名字太像T3520管Service Request流程和注册流程完全不是一回事。解决做速查表时按流程分组而不是按数字排列。注册流程组里放T3510、T3502服务请求组里放T3520RRC组里放T300、T304、T310。分组记忆之后现场查参数基本不会再错。5.4 课件里消息方向画反现象PPT里把RRC Setup画成UE发给gNB把Registration Accept画成gNB直接发给UE。原因画流程图时按“谁先发起就谁先出”的习惯走忽略了接口封装关系。解决每一条信令消息都要按“接口-方向-承载消息”三个维度核对。比如Registration Accept一定是AMF经NgAP下发给gNB再由gNB通过RRC下发给UE中间有两个方向的转换画成一条线直接连到UE就是错的。这类小问题在现场技术评审时最容易暴露。5.5 过度依赖信令抓包忽略物理层底噪现象信令流程全都正常核心网也回了Accept用户就是上不了网。原因信令只证明了控制面通了用户面吞吐还受制于射频底噪、MCS调度和天线通道状态。信令分析不是万能的遇到控制面全绿但速率上不去的情况要从物理层指标入手检查信道质量、下行MCS分布和AAU告警。信令负责画清楚链路射频负责解释速率两者缺一不可。6. 一个进阶习惯先画时序图再记参数讲5G基础信令或者自学5G基础信令最值钱的一个习惯是先把每个流程的时序图画到能默写再往图上填参数。具体做法是准备两张纸第一张纸上只画消息名和接口方向UE在左gNB在中间AMF在右把注册流程从头到尾用箭头串起来。不看任何资料能一次画对RRC Setup Request、RRC Setup Complete、Initial UE Message、Registration Accept的先后顺序再进入第二张纸在每个箭头旁边标定时器RRC Setup旁边标T300切换命令旁边标T304注册请求旁边标T3510。这个习惯厉害在哪它逼你把信令从“消息列表”变成“链路关系”。很多人在现场查了半小时日志都没意识到消息根本没到gNB就是因为脑子里没有这张时序图。我自己带新人第一周不让他们碰任何告警和统计只要求把注册、PDU会话建立、切换三条时序图默写一遍写完再给真实抓包。这个方法是血泪换来的——当年排查一个VoNR呼叫失败我盯着NAS重传看了眼花最后是同事看了一眼时序图说“消息压根没到AMF”一验证果然如此。从那以后我经手的每一个信令课件的开头都是时序图不是参数表。你做完这份5G基础信令讲解材料后不妨把最后三页改成一页注册时序图、一页PDU会话时序图、一页切换时序图再附一张定时器速查表。用的时候先看图再对参数效率和正确率都会明显好于逐条记消息。希望帮到你。本文还有配套的精品资源点击获取