简介面向5G网络优化工程师与通信专业学习者这份《5G-信令分析指导书》以信令流程梳理为主线覆盖从开机入网到会话管理、寻呼、切换及NAS流程的完整信令闭环。内容不仅包含小区搜索与选择、系统消息广播与更新、随机接入、RRC连接建立、注册流程等基础过程还涉及RRC拒绝与重发处理并针对MIB、SIB1、SI等关键系统消息做专项解读会话管理部分详解5G QoS架构及PDU会话建立、修改、释放流程切换部分区分站内、Xn、N2和LNR切换/重定向NAS流程则覆盖注册、去注册以及主被叫业务请求等场景。文档按流程模块组织目录便于快速定位信令异常排查点适合日常网优分析与问题定位。资源为1个docx文档大小4.24MB已有61人学习是系统掌握5G信令流程、提升空口与核心网信令分析能力的实用参考资料。1. 信令不只是一串消息为什么5G信令流程的顺序由状态依赖决定做网优的人没有几个没背过5G信令流程开机先搜网再读系统消息然后随机接入、建RRC连接、注册入网。真到现场排查时死背流程的顺序几乎不管用——信令分析最反直觉的一点是这些流程之所以是这个顺序不是协议起草者随意定的清单而是每一步都在等上一步在UE和网络两边形成确定的状态。安全模式必须排在UE能力查询之前因为能力信息要等加密链路建立后才允许上报PDU会话必须排在注册之后因为核心网的隧道要锚定一份已经注册的UE上下文。这份5G信令分析指导书的价值不在于把流程画得多全而在于把每条流程背后的状态依赖摆到了台面上。2. 开机入网为什么UE从搜频点到注册要拆成五步少一步都走不通UE开机之后不是直接去连基站而是按「小区搜索→系统消息→随机接入→RRC连接建立→注册」的次序一步步推进。这套次序常被当成流程清单来背但每一步其实都卡着上一步的状态结果没有同步就解不了MIB没有MIB就找不到SIB1没有SIB1就不知道随机接入资源在哪。注册则是整个入网过程里唯一和核心网打交道的步骤它把所有空口状态沉淀成一份核心网可识别的UE上下文。2.1 小区搜索PSS/SSS只是让UE先把时钟对齐再谈别的UE开机后的第一件事是按照Synchronization Raster扫描特定频点。频点扫描是个粗筛过程UE在候选频点上尝试检测PSS和SSS。PSS负责符号级定时同步SSS负责帧级定时同步两者组合还能算出PCI——物理小区标识标准写法是PCI 3 × NID1 NID2NID2由PSS携带NID1由SSS携带。如果这一步失败UE会回到频点扫描试下一个频点。为什么非要先做同步因为后续所有系统消息都是按OFDM符号、slot、无线帧来组织时频资源的。UE不知道系统的帧边界就没法确定MIB落在哪个时频位置。PSS/SSS本质上是让UE先拿到一张「对表的时钟」把下行时钟对齐才有可能正确解调广播信道。这是小区搜索和后续步骤之间第一层状态依赖。同步之后UE读MIB从里面拿到SSB波束信息、系统帧号SFN和SIB1的时频位置。MIB本身被刻意设计得很小它不告诉你小区的完整配置只告诉你去哪里找下一份地图。接着UE读SIB1SIB1在一个NR小区里承担的是RMSI角色里面带着上行初始BWP、初始BWP中的信道配置、TDD小区的半静态配比、OSI的搜索空间等。之后读OSI获取邻区、重选这类移动性相关信息。这里有个容易被忽略的停止条件SIB1里的CellBarred字段如果被置为barredUE直接停止系统消息获取。这是网络用来临时禁入一个小区的开关常见于小区维护或负载控制。排查接入失败时这是第一个要核对的字段很多人看信令log时直接跳过SIB1内容结果在小区被禁这种最浅层原因上绕圈子。2.2 系统消息分层MIB是入场券、SIB1是地图、OSI是详情页系统消息按内容分成MSI和OSI两大类。MSI包括MIB和SIB1是所有UE接入网络的最小信息集OSI包括SIB2到SIBn是补充信息。分层的动机很直接最小信息集要尽量小所以MIB和SIB1用固定周期广播不常用的大块信息放进OSI根据策略决定怎么下发。更值得琢磨的是OSI的下发方式。SIB1里会通过si-SchedulingInfo通知所有UE哪些SIB是周期广播哪些需要按需订阅。后者就叫ODOSIOn Demand SI。设计思路很直白不是所有SIB都对所有UE有意义如果网络按固定周期广播那些没人用的SIB资源全浪费了。ODOSI把这类SIB改成「有人要才发」。UE怎么触发订阅SIB1里会指示两种SODOSI机制——Msg1方式和Msg3方式。Msg1方式是UE在PRACH上发一个专门为SI请求保留的前导码gNB收到就知道有UE想要某个SIB随即开始广播Msg3方式是UE通过Msg3携带RRCSystemInfoRequest消息显式列出请求的SIB列表。提示Msg1方式更省空口资源但要求PRACH配置里预留了专门用于SI请求的前导码。如果配置里没有预留UE会回退到Msg3方式交互更重、延迟更高。UE拿到系统消息后不会反复重读只在三种情况下刷新收到寻呼指示systemInfoModification、收到ETWS或CMAS广播指示、距离上次成功接收满3小时。3小时这个值很多人不理解周期太短UE反复解调广播信道待机功耗压不住周期太长网络改了配置比如重选权重、邻区表UE迟迟感知不到。3小时是功耗和配置生效实时性之间的折中网优调整系统消息参数时要清楚这个生效延迟的存在。2.3 随机接入竞争和非竞争本质是抢车位和预留车位的区别系统消息读完UE和小区之间有了下行同步但还没有上行同步。随机接入的目的就是建立上行同步它分成基于竞争和基于非竞争两类。基于竞争的随机接入流程大家很熟UE在PRACH资源上随机选一个前导码发出去这是Msg1gNB回随机接入响应RAR即Msg2里面带临时C-RNTI和时间提前量TAUE拿到调度后在Msg3里带上自己的身份可能是5G-S-TMSI也可能是随机数如果没撞车gNB在Msg4里回显这个身份竞争解决UE拿到唯一C-RNTI。这条链路的关键在竞争解决。两个UE很可能选了同一个前导码gNB在Msg1阶段完全区分不了。设计上把身份确认推迟到Msg3和Msg4UE在Msg3里声明「我是谁」gNB选择胜出身份在Msg4里回显输掉的UE重新发起随机接入。所以Msg4在网络侧不一定只发给一个UE收到Msg4的UE必须检查自己上报的身份是否被回显没被回显就得从头再来。基于非竞争的随机接入没有这个过程gNB直接分配专用前导码UE发Msg1gNB回Msg2两步结束。它用在切换、波束失败恢复、上行失步等场景。为什么切换一定要用非竞争切换是时间敏感操作竞争接入引入的随机退避可能让UE在目标小区拖几百毫秒对正在进行的业务不可接受。gNB在切换准备阶段提前分配好专用前导码等于预先留好了车位。3. RRC连接与上下文管理为什么RRCSetup只是开始安全模式和UE能力查询才真正建立上下文随机接入解决的是上行同步但UE此时还没有任何专用信令通道。RRC连接建立在SRB1上建立起第一对专用信令承载。不过RRC连接建立完成只代表空口控制面通了核心网要真正「记住」这个UE还得走初始上下文建立流程。很多刚接触5G信令的人把RRCSetupComplete当作入网终点实际上后半段——安全模式、UE能力查询、上下文创建——才是UE从「能发能收」变成「被网络识别」的分水岭。3.1 RRC连接建立三条消息拉起SRB1establishmentCause决定优先级RRC连接建立流程很短UE发RRCSetupRequestgNB回RRCSetupUE再回RRCSetupComplete。三句话就能讲完的流程有价值的信息全在字段上。RRCSetupRequest携带establishmentCause和initialUE-Identity。initialUE-Identity如果是5G-S-TMSI说明这个UE已经在核心网注册过gNB可以把这次RRC建立和已有NAS上下文关联起来如果是随机值那是一个全新UE。establishmentCause告诉gNB这次接入的动机紧急呼叫、高优先级接入、被叫、主叫信令、主叫数据。接纳控制策略完全依赖这个cause——拥塞时优先放行emergency和highPriorityAccess普通mo-Data可能直接触发RRCReject。RRCSetup里下发的是SRB1专用配置、MAC配置和PHY配置。网优这里常有个疑问为什么RRCSetup不直接下发DRB因为DRB要等核心网确认PDU会话之后才建。RRC层只能先把脚下这块地铺好业务通道要等上层决策。RRCSetupComplete里带5G-S-TMSI和NAS消息比如注册请求或业务请求。到这一步UE在空口有了专用信令通道NAS信息也透传给了核心网但真正的上下文还没有建立。3.2 RRC拒绝与重发T300超时重发不是网络傻是状态机设计RRC连接建立不总是成功gNB可以回RRCReject。RRCReject出现在网络过载、小区被禁止、UE身份无法识别等场景。UE收到RRCReject后按协议停止RRC建立尝试不能继续在当前频点死磕如果是emergency causeUE可以尝试选择其它小区。另一条路径是RRCSetupRequest发出后既没等到RRCSetup、也没等到RRCRejectUE侧的T300定时器超时触发重发。T300是RRC建立等待定时器每次重发都会重启。重发次数达到上限后UE宣告RRC建立失败进入空闲态。判断路径比背参数更重要T300超时通常是下行覆盖差、SIB1解不出来或随机接入失败快速收到RRCReject则通常是核心网过载或接纳控制拒绝。区分依据就是看log里有没有伴随RRCReject消息以及重发间隔是否稳定。把这两条路径混为一谈是网优排查时最常犯的错误之一。3.3 初始上下文建立为什么安全模式必须先于UE能力查询RRC连接建立完成后核心网才开始干活。AMF收到RRCSetupComplete里的NAS消息触发初始上下文建立。这条NGAP消息——INITIAL CONTEXT SETUP REQUEST——是5G信令里信息量最大的消息之一。它的关键IE结构大致如下INITIAL CONTEXT SETUP REQUEST ├── AMF UE NGAP ID # AMF侧为该UE分配的标识 ├── RAN UE NGAP ID # gNB侧为该UE分配的标识 ├── UE Aggregate Maximum Bit Rate # 该UE的聚合上下行速率上限 ├── Security Key # 用于推导空口加密/完整性密钥 ├── UE Radio Capability # UE无线能力可选下发 └── PDU Session Resource Setup List └── PDU Session Resource Setup Item ├── PDU Session ID ├── S-NSSAI # 网络切片选择辅助信息 └── QoS Flow Setup Request List这一组IE说明初始上下文建立不是孤立的信令事件它把NAS身份、空口安全、PDU会话三条线索拧到了一起。gNB收到安全密钥后执行安全模式过程发SecurityModeCommand给UEUE确认算法一致后回SecurityModeComplete。这一来一回之后SRB的加密和完整性保护才生效。紧接着才是UE能力查询UECapabilityEnquiry和UECapabilityInformation一唱一和把UE支持的频段、MIMO能力、测量能力上报给网络。这个顺序是强制性的。UE能力信息里包含频段、协议版本这些敏感内容明文链路传输能被伪基站截获同时gNB需要在安全上下文里校验能力信息的真实性。所以协议把UE能力查询硬性放在安全模式之后。实战里看到安全模式失败或UE能力查询超时基本不用查空口直接查安全上下文里的密钥和算法列表。4. 会话管理5G QoS为什么把承载拆成QoS Flow和DRB两层PDU会话怎么建立RRC和上下文建立解决了「UE是谁」的问题而业务要跑起来还差「UE能用什么管道」这层状态。这就是会话管理的范畴。5G在会话管理上做了一个和4G截然不同的设计把核心网和接入网的QoS粒度拆开核心网用QoS Flow描述业务需求空口用DRB承载实际数据。理解这层设计才能理解PDU会话建立过程里那么多NGAP和RRC消息到底在对齐什么。4.1 5G QoS架构Flow是业务需求DRB是空口管道4G时代核心网、空口和终端之间对齐的粒度是EPS承载一个承载对应一组固定QoS参数。5G把这一层拆成两段核心网和接入网之间以QoS Flow为粒度空口上则把多个Flow映射到同一个DRB。为什么这么拆核心原因在于4G的承载是端到端概念核心网要为应用整条路径保留固定资源5G业务更碎片化同一部终端上可能同时跑实时视频和普通浏览两者对时延和丢包的要求完全不同。QoS Flow允许核心网按业务粒度下发QoS需求而DRB只负责空口那一小段的调度资源。SDAP层在PDCP之上做flow-to-DRB映射核心网不感知空口调度空口也不关心核心网隧道细节。QoS参数里最重要的三个5QI不是一个速率值而是一组QoS特性索引默认的优先级、包时延预算、包错误率都挂在它后面ARP决定资源竞争时的保留和抢占优先级GFBR/MFBR是保证速率和最大速率GFBR一般用于语音这类实时业务。还有反射QoS机制网络在下行数据包里携带QoS规则UE根据下行包反推上行的QoS映射省掉一次NAS交互。实际网络里反射QoS用得不多因为多数场景还是通过NAS信令显式下发规则。QoS Flow到DRB可以一对一也可以多对一。一个DRB能承载多个Flow的前提是QoS需求接近比如都是默认Non-GBR业务。为什么允许多对一空口的DRB数量有限Flow太多终端管不过来调度器按DRB做资源分配把需求相近的Flow合并空口效率更高。代价是粒度变粗网络没法在空口区分同一DRB里两个Flow的优先级。这就是取舍灵活性上来了网优调度的复杂度也跟着上来了。4.2 PDU会话建立NGAP和RRC怎么接力UE要跑业务必须有PDU会话。PDU会话是UE和UPF之间的逻辑隧道空口一侧对应一个或多个DRB。建立过程在信令面上是两条腿走路。第一条腿是NGAP。AMF收到UE的NAS PDU Session Establishment Request后经过SMF分配UPF资源向gNB下发PDU SESSION RESOURCE SETUP REQUEST。这条消息里携带PDU Session ID、S-NSSAI、PDU Session TypeIPv4/IPv6/Ethernet、QoS Flow Setup Request List。gNB的任务是把消息里的QoS Flow翻译成空口侧的DRB配置。第二条腿是RRC。gNB生成RRCReconfiguration里面携带SDAP配置、DRB配置PDCP、RLC、MAC逻辑信道通过SRB1下发给UE。UE配置好DRB后回RRCReconfigurationComplete。gNB只有确认终端侧也把DRB立起来才回给AMF PDU SESSION RESOURCE SETUP RESPONSE核心网此时才认为会话可用。为什么非要这样接力因为核心网和UE之间隔着gNB双方看不到彼此状态。NGAP消息只能保证gNB和核心网达成一致RRC消息只能保证gNB和UE达成一致。两份约定都完成PDU会话才是真的通了。网优看log时最常见的错觉是只见NGAP链路、不见RRC链路导致会话状态不一致。4.3 PDU会话修改与释放为什么改QoS可能比建立更敏感PDU会话修改用在业务流变化时新增一个QoS Flow、删掉一个、修改某个Flow的GFBR。MODIFY REQUEST里携带的QoS Flow列表会做全量更新gNB把变更后的Flow重新映射到DRB。如果新Flow和已有Flow的需求不兼容gNB会新建DRB这是最常见的情况。PDU会话释放则把NG隧道、DRB和SDAP映射全部拆除。这里有个网优容易忽略的点核心网释放PDU会话时gNB必须同步释放对应DRB并通知UE释放RRC配置。顺序错了会导致UE以为DRB还在后续调度全乱。修改为什么敏感因为改GFBR或5QI意味着DRB的调度参数要变而RRCReconfiguration下发新配置时UE要按流程重置PDCP或RLC。这个重置不一定断流但网优调QoS参数时最好在业务低峰期操作并且在log里确认RRCReconfigurationComplete触发后才算生效。把修改当增量、把释放当删除——这种直觉放在会话管理里是不够用的因为每个操作都牵动两层协议的状态。5. 寻呼与切换排查从5GC寻呼到LNR重定向移动性信令的常见坑与排查路径UE不会永远挂在连接态。没有业务时网络让UE进空闲态或Inactive态来省电但下行数据随时可能来于是有了寻呼UE在小区间移动于是有了切换。这两个流程一个回答「UE在哪、怎么喊醒它」一个回答「UE要去哪、路径怎么切」。5G里这两种流程都拆成了多条路径路径选择取决于UE的状态和网络拓扑。5.1 5GC寻呼与RAN寻呼UE在哪一层发呆决定了谁来喊它5GC寻呼由AMF发起针对CM-Idle态的UE。核心网只知道UE在一个跟踪区级别的位置不知道具体小区于是AMF把寻呼请求发给跟踪区覆盖下的所有gNBgNB在自己辖区内广播PAGING。UE收到匹配身份的寻呼后发起NAS层的业务请求——Service Request经随机接入、RRC建立、服务请求完成后网络才重建用户面隧道。被叫流程的时延很大部分耗在5GC寻呼在跟踪区范围内广播上。RAN寻呼由gNB发起针对RRC Inactive态的UE。这是5G引入的新状态UE在RRC层看起来是空闲的但gNB保留着它的UE上下文和最后已知小区核心网也认为它还在连接态。gNB只在一个RAN通知区——RNA——内寻呼范围比跟踪区小得多恢复也快得多UE回一条RRCResume请求gNB不用重拉全部上下文。两种寻呼切换的关键在状态管理。UE从连接态进InactivegNB通过RRCRelease消息里的suspendConfig告诉UE「你还在我这挂了号」UE移动出RNA要自己触发RNA更新。gNB发现UE很久不回来会释放上下文、把状态踢回Idle后续寻呼就落入5GC寻呼的管辖。状态迁移一乱寻呼失败就跟着来。5.2 四种切换路径为什么不能只用一种切换切换是移动性里信令最密集的部分。5G里切换路径至少有四种每种解决一个层面的问题。站内切换源小区和目标小区在同一个gNB里信令在gNB内部消化不经过Xn也不经过N2。这是同站补盲或波束切换最常见的形式信令最少、延迟最低。Xn切换跨gNB但都在同一AMF/UPF域内。源gNB通过Xn接口向目标gNB发Handover Request目标gNB准备资源后返回Handover Request AcknowledgeUE在目标小区完成随机接入和RRC重配最后源gNB向核心网做路径切换把PDU会话的NG隧道从源gNB迁到目标gNB。Xn切换不需要动核心网的会话状态所以比N2快。N2切换跨AMF或跨核心网域的切换必须走NG接口。N2切换要核心网参与信令链路更长。为什么不能全用Xn因为Xn接口只存在于相邻gNB之间跨区域或跨厂商域时核心网需要统一协调仲裁。LNR切换和LNR重定向这是LTE和NR之间的系统间互操作。LNR切换能在目标系统上无缝接入但要求两个系统配置了完整切换关系LNR重定向则是「假切换」——网络释放UE的RRC连接在释放消息里带上目标系统的频点UE按频点去新小区重新完整走一遍随机接入、RRC建立、注册。重定向实现门槛低但业务中断几秒是实实在在的。网优现场经常因为重定向参数没配全导致UE到目标小区后找不到合适驻留频点整段业务拉不起来。5.3 避坑移动性信令排查里五类高频踩坑记录以下五条是网优现场高频踩过的坑按现象、原因、解决三段式列出每条都值得拿实际log验证一遍。坑1PDU会话建立后空口一直没有数据现象信令面看着完整PDU SESSION RESOURCE SETUP RESPONSE也回了但UE空口速率始终为0。原因RRCReconfiguration里的SDAP配置没把QoS Flow映射到DRB或映射的DRB ID和NGAP消息里的DRB ID不一致。解决先抓RRCReconfiguration确认每个QoS Flow的flow-to-DRB mapping再用PDU SESSION RESOURCE SETUP REQUEST里的QoS Flow列表逐项核对。坑2注册流程卡在Initial Context Setup之后UE收不到SecurityModeCommand现象NGAP INITIAL CONTEXT SETUP REQUEST已经发给gNB空口上却看不到SecurityModeCommand。原因安全上下文没建立成功最常见是AMF下发的安全密钥与gNB配置的算法不匹配或gNB侧安全算法优先级为空。解决查INITIAL CONTEXT SETUP REQUEST里的Security Key和允许的加密算法列表核对gNB本地算法清单再看gNB日志里有没有安全模式失败的内部原因。坑3Xn切换成功率上不去UE总在目标小区失步现象切换请求都正常目标侧也回了Handover Request Acknowledge但UE到目标小区后一直随机接入失败。原因测量报告里的PCI对应到了两个小区俗称PCI混淆。UE实际去的物理位置和目标gNB准备的小区不是同一个。解决用NCGI——NR Cell Global Identifier——区分同PCI小区检查邻区表里有没有PCI冲突。PCI规划是老话题但在5G同频组网下更敏感。坑4RRC Inactive UE下行数据来了寻呼却没响应现象核心网下发数据到gNBgNB在RAN通知区发了PAGINGUE没反应业务超时。原因UE已经移动出RNA但没触发RNA更新或者RNA范围太大、寻呼次数不够。解决查UE上下文里的RNA配置和UE最后上报的小区缩小RNA范围或调整寻呼参数同时确认RRCRelease里的suspendConfig是否真正下发给了UE。坑5LNR重定向后业务长时间无法恢复现象重定向流程显示成功UE在新小区也完成了RRC建立但业务迟迟起不来。原因重定向消息里携带的目标频点或系统消息不全UE到新小区后要重新等SIB1和OSI广播周期大时耗时几秒。解决配齐重定向参数包括目标频点和目标小区系统消息如果能走真正的LNR切换就别用重定向。必须用重定向时把目标小区的广播周期调短。6. 信令设计的取舍从3小时过期到不完美的重定向5G信令一直在效率和可靠性之间博弈看完整份指导书最值得琢磨的不是某个消息怎么解读而是这些信令流程为什么被设计成今天这个样子。随便挑几个点都能看到设计者在效率和可靠性之间的拉扯。设计点换来的好处付出的代价系统消息3小时过期UE不必反复监听广播待机功耗可控网络改配置最长要3小时才生效ODOSI按需广播不常用的SIB不占广播资源UE多一次SI请求交互接入延迟变高QoS Flow映射到DRB核心网和空口各自按最合适的粒度管理映射配错时业务质量不可预期LNR重定向跨系统互操作实现门槛低业务中断几秒用户体验打折这四个点没有一个是完美解都是针对特定场景的次优解3小时过期是对配置下发实时性和UE功耗的折中ODOSI用接入延迟换广播资源Flow到DRB的映射用复杂度换灵活性LNR重定向用业务中断换实现简单。看懂取舍就知道网优配置里哪些是红线、哪些可以大胆调。我在信令上翻过的最大的车是把一个RRCReject当成覆盖问题反复调天线倾角调了几天直到某导师点醒我去看核心网拥塞。从那以后我每次排查信令都强制把UE状态、gNB上下文、核心网上下文三列对齐画出来先问「当前依赖什么状态谁的状态没到位」再去看消息本身。这份5G信令分析指导书恰恰把开机入网、上下文管理、会话管理、寻呼切换、NAS流程全串在这条状态依赖线上包括去注册时终端侧和网络侧各自清理哪些上下文、业务请求主被叫两条路径的差异都适合做排查对照表。如果你在做网优或基站侧协议分析把其中关键消息解读部分和实际log放在一起读能少踩不少坑。希望帮到你。本文还有配套的精品资源点击获取