5G信令流程底层逻辑：状态依赖如何决定接入、会话与切换的顺序

简介：面向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 + NID2，NID2由PSS携带，NID1由SSS携带。如果这一步失败，UE会回到频点扫描，试下一个频点。

为什么非要先做同步？因为后续所有系统消息都是按OFDM符号、slot、无线帧来组织时频资源的。UE不知道系统的帧边界，就没法确定MIB落在哪个时频位置。PSS/SSS本质上是让UE先拿到一张「对表的时钟」，把下行时钟对齐，才有可能正确解调广播信道。这是小区搜索和后续步骤之间第一层状态依赖。

同步之后，UE读MIB，从里面拿到SSB波束信息、系统帧号SFN和SIB1的时频位置。MIB本身被刻意设计得很小，它不告诉你小区的完整配置，只告诉你去哪里找下一份地图。接着UE读SIB1，SIB1在一个NR小区里承担的是RMSI角色，里面带着上行初始BWP、初始BWP中的信道配置、TDD小区的半静态配比、OSI的搜索空间等。之后读OSI，获取邻区、重选这类移动性相关信息。

这里有个容易被忽略的停止条件：SIB1里的CellBarred字段如果被置为barred，UE直接停止系统消息获取。这是网络用来临时禁入一个小区的开关，常见于小区维护或负载控制。排查接入失败时，这是第一个要核对的字段，很多人看信令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是周期广播，哪些需要按需订阅。后者就叫ODOSI，On 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资源上随机选一个前导码发出去，这是Msg1；gNB回随机接入响应RAR，即Msg2，里面带临时C-RNTI和时间提前量TA；UE拿到调度后在Msg3里带上自己的身份，可能是5G-S-TMSI也可能是随机数；如果没撞车，gNB在Msg4里回显这个身份，竞争解决，UE拿到唯一C-RNTI。

这条链路的关键在竞争解决。两个UE很可能选了同一个前导码，gNB在Msg1阶段完全区分不了。设计上把身份确认推迟到Msg3和Msg4：UE在Msg3里声明「我是谁」，gNB选择胜出身份在Msg4里回显，输掉的UE重新发起随机接入。所以Msg4在网络侧不一定只发给一个UE，收到Msg4的UE必须检查自己上报的身份是否被回显，没被回显就得从头再来。

基于非竞争的随机接入没有这个过程：gNB直接分配专用前导码，UE发Msg1，gNB回Msg2，两步结束。它用在切换、波束失败恢复、上行失步等场景。为什么切换一定要用非竞争？切换是时间敏感操作，竞争接入引入的随机退避可能让UE在目标小区拖几百毫秒，对正在进行的业务不可接受。gNB在切换准备阶段提前分配好专用前导码，等于预先留好了车位。

3. RRC连接与上下文管理：为什么RRCSetup只是开始，安全模式和UE能力查询才真正建立上下文

随机接入解决的是上行同步，但UE此时还没有任何专用信令通道。RRC连接建立在SRB1上建立起第一对专用信令承载。不过RRC连接建立完成只代表空口控制面通了，核心网要真正「记住」这个UE，还得走初始上下文建立流程。很多刚接触5G信令的人把RRCSetupComplete当作入网终点，实际上后半段——安全模式、UE能力查询、上下文创建——才是UE从「能发能收」变成「被网络识别」的分水岭。

3.1 RRC连接建立：三条消息拉起SRB1，establishmentCause决定优先级

RRC连接建立流程很短：UE发RRCSetupRequest，gNB回RRCSetup，UE再回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 cause，UE可以尝试选择其它小区。

另一条路径是RRCSetupRequest发出后既没等到RRCSetup、也没等到RRCReject，UE侧的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给UE，UE确认算法一致后回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 Type（IPv4/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把寻呼请求发给跟踪区覆盖下的所有gNB，gNB在自己辖区内广播PAGING。UE收到匹配身份的寻呼后，发起NAS层的业务请求——Service Request，经随机接入、RRC建立、服务请求完成后，网络才重建用户面隧道。被叫流程的时延，很大部分耗在5GC寻呼在跟踪区范围内广播上。

RAN寻呼由gNB发起，针对RRC Inactive态的UE。这是5G引入的新状态：UE在RRC层看起来是空闲的，但gNB保留着它的UE上下文和最后已知小区，核心网也认为它还在连接态。gNB只在一个RAN通知区——RNA——内寻呼，范围比跟踪区小得多，恢复也快得多：UE回一条RRCResume请求，gNB不用重拉全部上下文。

两种寻呼切换的关键在状态管理。UE从连接态进Inactive，gNB通过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 Acknowledge，UE在目标小区完成随机接入和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验证一遍。

坑1：PDU会话建立后空口一直没有数据

• 现象：信令面看着完整，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日志里有没有安全模式失败的内部原因。

坑3：Xn切换成功率上不去，UE总在目标小区失步

• 现象：切换请求都正常，目标侧也回了Handover Request Acknowledge，但UE到目标小区后一直随机接入失败。
• 原因：测量报告里的PCI对应到了两个小区，俗称PCI混淆。UE实际去的物理位置和目标gNB准备的小区不是同一个。
• 解决：用NCGI——NR Cell Global Identifier——区分同PCI小区，检查邻区表里有没有PCI冲突。PCI规划是老话题，但在5G同频组网下更敏感。

坑4：RRC Inactive UE下行数据来了，寻呼却没响应

• 现象：核心网下发数据到gNB，gNB在RAN通知区发了PAGING，UE没反应，业务超时。
• 原因：UE已经移动出RNA但没触发RNA更新，或者RNA范围太大、寻呼次数不够。
• 解决：查UE上下文里的RNA配置和UE最后上报的小区，缩小RNA范围或调整寻呼参数；同时确认RRCRelease里的suspendConfig是否真正下发给了UE。

坑5：LNR重定向后业务长时间无法恢复

• 现象：重定向流程显示成功，UE在新小区也完成了RRC建立，但业务迟迟起不来。
• 原因：重定向消息里携带的目标频点或系统消息不全，UE到新小区后要重新等SIB1和OSI，广播周期大时耗时几秒。
• 解决：配齐重定向参数，包括目标频点和目标小区系统消息；如果能走真正的LNR切换就别用重定向。必须用重定向时，把目标小区的广播周期调短。

6. 信令设计的取舍：从3小时过期到不完美的重定向，5G信令一直在效率和可靠性之间博弈

看完整份指导书，最值得琢磨的不是某个消息怎么解读，而是这些信令流程为什么被设计成今天这个样子。随便挑几个点，都能看到设计者在效率和可靠性之间的拉扯。

这四个点没有一个是完美解，都是针对特定场景的次优解：3小时过期是对配置下发实时性和UE功耗的折中；ODOSI用接入延迟换广播资源；Flow到DRB的映射用复杂度换灵活性；LNR重定向用业务中断换实现简单。看懂取舍，就知道网优配置里哪些是红线、哪些可以大胆调。

我在信令上翻过的最大的车，是把一个RRCReject当成覆盖问题，反复调天线倾角调了几天，直到某导师点醒我去看核心网拥塞。从那以后，我每次排查信令都强制把UE状态、gNB上下文、核心网上下文三列对齐画出来，先问「当前依赖什么状态，谁的状态没到位」，再去看消息本身。这份5G信令分析指导书恰恰把开机入网、上下文管理、会话管理、寻呼切换、NAS流程全串在这条状态依赖线上，包括去注册时终端侧和网络侧各自清理哪些上下文、业务请求主被叫两条路径的差异，都适合做排查对照表。如果你在做网优或基站侧协议分析，把其中关键消息解读部分和实际log放在一起读，能少踩不少坑。希望帮到你。

本文还有配套的精品资源，点击获取