简介《5G-信令分析指导书》面向5G无线网优工程师及信令分析入门人员围绕空口与核心网交互中的关键流程帮助读者建立从信令视角排查网络问题的分析框架。压缩包内含1个docx文档大小约4.24MB单文件结构便于按章节检索、标注和复盘。目录覆盖开机入网中的小区搜索与选择、系统消息获取更新及ODOSI过程随机接入、RRC连接建立/拒绝/重发与注册流程并延伸至初始上下文建立、5G QoS架构与PDU会话建立修改释放、5GC与RAN寻呼、站内/Xn/N2/LNR切换及重定向以及NAS注册、去注册和主被叫业务请求。读者可据此对照MIB、SIB1、SI等关键消息解读梳理流程节点、消息交互顺序与常见异常定位思路也便于用于项目培训或案例复盘。已有62人学习下载适合需要系统补强5G信令流程的网优从业者查阅。1. 信令地图网优看5G信令先要建立哪几条流程线5G 信令跟踪打开后界面像瀑布一样往下刷几百条消息挤在一起真正决定成败的只有少数几个关键节点。做过网优的人多半有这样的体会消息本身不难记难的是不确定自己现在读到哪一段了。把 5G SA 的信令压成一张地图其实只有六条主线——开机入网、上下文管理、会话管理、寻呼、切换、NAS。其中开机入网是唯一一条「从零开始」的线其余五条都建立在它之上。每条线的首尾消息是固定的中间消息可以省略、可以合并但起点和终点不会变。抓住起点和终点中间的取舍才有依据抓不住就会被大量不该出现的消息带偏。2. 开机入网从小区搜索到RRC连接的五级台阶开机入网是整份信令分析指导书里最长、也最容易让人糊涂的一段。它由五个子过程串起来小区搜索与选择、系统消息广播、随机接入、RRC 连接建立、注册。这五步是有严格先后顺序的前一步失败后面几步的消息根本不会出现。很多人分析入网失败时直接跳到 RRC结果发现空口连一条 RRCSetupRequest 都没有回头才发现失败原因停在小区搜索或 MIB 解析。按顺序逐级检查比凭经验猜快得多。2.1 小区搜索与选择先同步、再读MIB、后读SIB1小区搜索的目标是取得时间和频率同步、检测小区 IDPCI并确认这个小区能不能驻留。流程是分段递进的UE 按同步栅格搜索频点尝试检测 PSS/SSS检测成功后取得下行时钟同步和 PCI然后读取 MIB拿到 SSB 波束信息、系统帧号以及广播 SIB1 的时频域位置再读 SIB1拿到上行初始 BWP 配置、初始 BWP 内的信道配置、TDD 小区的半静态配比以及广播 OSI 的搜索空间信息最后读 OSI补齐移动性相关信息。这段流程值得记住的关键点是每一级都在为下一级提供定位信息。MIB 不给 SIB1 的位置UE 就不知道去哪里接 SIB1SIB1 不给 OSI 的搜索空间UE 就不知道去哪里接 SIB2 及以后的消息。分析时如果发现时间轴在 MIB 之后就断了问题多半出在下行覆盖或 SSB 波束配置而不在核心网侧。另一个容易忽略的细节是 CellBarredMIB 里如果指示小区禁止接入UE 会直接停止系统消息获取后续流程一步都不会走。看到「只有 MIB、没有 SIB1」的跟踪先确认小区状态比反复查接入参数有效。2.2 系统消息广播MSI与OSI的分类、ODOSI按需订阅系统消息按内容分成两大类MSI最小系统信息和 OSI其他系统信息。MSI 包括 MIB 和 SIB1SIB1 也叫 RMSIOSI 包括 SIB2 到 SIBn。这个划分不只是叫法不同它决定了下发方式MSI 必定是周期广播OSI 既可以是周期广播也可以是订阅后广播也就是 ODOSI。大类子类承载信道下发方式主要内容MSIMIBPBCH周期广播初始接入信息、SIB1 的捕获信息MSISIB1RMSIPDSCH周期广播OSI 的捕获信息、OSI 的发送机制OSISIB2SIBnPDSCH周期广播或订阅广播ODOSI小区重选、邻区等移动性相关信息UE 获取系统消息的判定顺序是固定的先解析 MIB 检查小区状态CellBarred 为禁止就停止再用 MIB 里的参数解析 SIB1失败就停止然后根据 SIB1 指示的发送方式处理 OSI周期广播的直接按搜索空间接收不是周期广播的走 ODOSI 订阅流程。ODOSI 有两种触发方式一种通过 Msg1专用前导一种通过 Msg3具体用哪种由 SIB1 通知给所有用户。这一点在分析里很关键如果 SIB1 指示的是 Msg1 方式空口会先出现一个专用前导然后才有 SIB 下发按周期广播的思路去找永远对不上。系统消息的更新条件也值得单独记一下。UE 在开机选网、小区重选、系统内切换完成、从其他 RAT 进入 5G、从非覆盖区返回覆盖区这些场景会主动读取系统消息读完之后不会反复读。只有三种情况才会重新读取收到 gNB 寻呼指示系统消息发生变化、收到寻呼指示有 ETWS 或 CMAS 消息广播、距离上次正确接收超过 3 小时。3 小时这个有效期来自协议对 SIB 有效性的规定实际排查中它容易被忽视跟踪里明明没有变更通知UE 却重新读了系统消息很可能只是有效期到了。2.3 随机接入竞争与非竞争两条路径怎么分随机接入解决的问题是上行同步。UE 和 gNB 建立上行同步之后才能发后续的 RRC 消息。它分两条路径区分方式很直接前导是不是专用分配的。基于竞争的随机接入是四步交互UE 发 Msg1随机选择前导gNB 回 Msg2RAR携带时间提前量、临时 C-RNTI 和上行授权UE 在授权资源上发 Msg3gNB 回 Msg4 完成竞争解决。四个消息缺一不可因为多个 UE 可能同时选了同一个前导必须靠 Msg4 把赢家确定下来。基于非竞争的随机接入只有两步gNB 预先分配专用前导UE 发 Msg1gNB 回 Msg2没有竞争也没有 Msg3、Msg4。它主要用于切换、下行数据到达这类需要快速接入、且网络侧已经知道是哪个 UE 的场景。分析时的判断方法是看 Msg1 之前有没有专用前导的分配消息以及 Msg2 之后有没有 Msg3。如果跟踪里 Msg2 之后直接进了 RRC 消息说明走的是非竞争路径如果 Msg2 之后有 Msg3 和 Msg4走的是竞争路径。还有一个容易踩坑的地方Msg3 里携带的内容取决于触发原因可能是 RRCSetupRequest也可能是 RRCResumeRequest 或者其他的消息。只看 Msg3 的出现与否、不看它携带的是什么内容很容易把恢复流程误判成建立流程。2.4 RRC连接建立Request、Setup、Complete与拒绝重发RRC 建立是三步UE 发 RRCSetupRequestgNB 回 RRCSetupUE 回 RRCSetupComplete。RRCSetupRequest 里带 UE 标识和建立原因RRCSetup 里带无线资源配置包括 SRB1 的配置RRCSetupComplete 里带选择的 PLMN 和第一条 NAS 消息注册请求就是从这条消息里带上去的。这个三步结构里有一个容易被忽略的依赖关系注册流程的 NAS 消息不是单独发的它搭在 RRCSetupComplete 上。所以看到 RRCSetupComplete 却没有后续的注册交互要么是 NAS 消息没带上去要么是核心网侧没响应问题不在空口这一段。消息方向关键内容分析关注点RRCSetupRequestUE→gNBUE 标识、建立原因建立原因是否与场景匹配RRCSetupgNB→UESRB1 无线资源配置配置是否完整、是否含接入限制RRCSetupCompleteUE→gNB选择的 PLMN、首个 NAS 消息是否携带注册请求RRCRejectgNB→UE等待时间等是否属于网络侧主动拒绝拒绝和重发是两个不同性质的现象混为一谈是最常见的判断错误。RRCReject 是 gNB 主动下发拒绝说明网络侧此刻不接受这次建立可能是过载保护一类的处理跟踪里会看到明确的 RRCReject 消息。而重发是 UE 侧行为发完 RRCSetupRequest 之后等不到 RRCSetup定时器超时UE 重新发一次请求。前者说明网络侧做了动作后者说明网络侧根本没有响应。把重发当成拒绝会把排查方向整个带偏。看到连续两条 RRCSetupRequest先确认中间有没有 RRCReject没有就是超时重发问题出在响应缺失。3. 上下文与会话UE在核心网侧的两本账RRC 建立完成之后UE 在网络上就有了身份接下来核心网侧要维护两本账一本是 UE 上下文记录这个 UE 的安全能力、无线能力、位置等另一本是 PDU 会话记录它要传什么业务、走什么 QoS。这两本账分别由上下文管理流程和会话管理流程来维护各自都有建立、修改、释放三种动作。把这两组动作对照着记比一条一条背消息省力得多。3.1 初始上下文建立安全模式与能力查询的先后顺序初始上下文建立这条流程的入口是 NGAP 的 INITIAL CONTEXT SETUP REQUEST由核心网侧下发到 gNB。这条消息里携带了安全相关参数、是否需要查询 UE 能力的指示以及需要建立的 PDU 会话资源。gNB 收到之后并不是直接回响应中间要插入两个子过程安全模式过程和 UE 能力查询过程。安全模式过程是 RRC SecurityModeCommand 和 RRC SecurityModeComplete 一来一回。它的作用是把加密和完整性保护的算法确定下来并激活。分析这条流程时重点是看两侧算法是否一致以及 Complete 是否正常返回。安全模式没完成后面的能力查询和会话建立都无从谈起因为消息本身需要保护。UE 能力查询过程是 RRC UECapabilityEnquiry 和 RRC UECapabilityInformation。gNB 通过查询拿到 UE 支持哪些频段、哪些能力再决定后续怎么配置。注意这条流程的触发不是无条件的INITIAL CONTEXT SETUP REQUEST 里可以指示是否需要查询如果网络侧已经有缓存的能力信息这一步可能被跳过。看到能力查询缺失就判定为流程异常是常见的误判。两个子过程都完成之后gNB 才回 NGAP INITIAL CONTEXT SETUP RESPONSE。这条响应里携带的是实际建立成功的会话资源列表。对照请求和响应看哪些会话资源建立成功、哪些失败是这条流程最有价值的分析点。消息层次方向作用NGAP INITIAL CONTEXT SETUP REQUESTNGAP核心网→gNB触发上下文建立携带安全与能力查询指示RRC SecurityModeCommandRRCgNB→UE下发加密与完整性算法RRC SecurityModeCompleteRRCUE→gNB确认算法生效RRC UECapabilityEnquiryRRCgNB→UE请求 UE 无线能力RRC UECapabilityInformationRRCUE→gNB上报 UE 能力NGAP INITIAL CONTEXT SETUP RESPONSENGAPgNB→核心网返回建立的会话资源结果上下文还有另外两个动作修改和释放。修改对应 UE 上下文修改过程用于更新上下文中已经变化的部分释放对应 UE 上下文释放过程由一侧发起另一侧确认。把它们和建立过程放在一起看会发现消息结构高度对称请求、响应请求、响应。这种对称性在排查时很有用看到释放请求没有响应就知道流程断在确认环节。3.2 5G QoS架构QoS Flow、关键参数与到DRB的映射5G 的 QoS 架构和 LTE 的承载模型不一样这一点是复习时的重点。5G 里 QoS 的基本粒度是 QoS Flow不是承载。一个 PDU 会话里可以有多个 QoS Flow每个 QoS Flow 有一个 QFI 标识QoS Flow 再映射到 DRB 上映射动作在 SDAP 层完成。这层抽象带来的直接后果是QoS Flow 和 DRB 不是一一对应的。多个 QoS Flow 可以映射到同一个 DRB 上尤其是 QoS 特性接近的流合并到一条 DRB 能减少空口开销。所以看 RRCReconfiguration 里的 DRB 配置时如果发现 DRB 数量和 QFI 数量对不上不一定是配置错误很可能就是多流复用到了一条 DRB。QoS 参数里有几组必须记住的参数含义分析时的作用5QI5G QoS 标识对应一组预定义的特性判断业务类型与调度优先级ARP分配与保留优先级判断资源紧张时谁先让路QFIQoS Flow 标识空口与核心网侧对齐的索引GFBR / MFBR保证流比特率 / 最大流比特率判断速率类业务的约束条件QoS Flow 到 DRB 的映射关系是贯穿会话管理与空口配置的一条线索。核心网侧的会话资源请求里带的是 QFI 和对应的 QoS 参数gNB 侧决定怎么映射映射结果体现在 RRC 重配置的 DRB 配置里。分析时如果只看了其中一侧看到的就是两套互相看不懂的编号。把 QFI 和 DRB ID 的对应关系画出来很多看似矛盾的配置就解释得通了。3.3 PDU会话与UE上下文三组建立、修改、释放的对称性PDU 会话管理有三个动作建立、修改、释放。每个动作在核心网侧和空口侧各有对应的消息形成一组配对。建立过程是 NGAP 的 PDU SESSION RESOURCE SETUP REQUEST 下发到 gNBgNB 通过 RRCReconfiguration 把空口配置下发给 UEUE 回 RRCReconfigurationCompletegNB 再回 NGAP 的 PDU SESSION RESOURCE SETUP RESPONSE。修改和释放的骨架完全一样只是消息名不同MODIFY REQUEST / MODIFY RESPONSE、释放对应的请求与响应。这种对称结构给了排查一个很好用的切入点任何一条 NGAP 请求在空口侧都应该能找到对应的 RRC 重配置动作。如果 NGAP 请求下发了空口侧却没有 RRCReconfiguration问题在 gNB 内部处理如果 RRCReconfiguration 发了UE 没回 Complete问题在空口或 UE 侧如果 Complete 回来了NGAP 响应却没上去问题在 gNB 与核心网之间的接口。三段一切故障域就缩小了。4. 寻呼与切换连接态与空闲态的两套动作前面几条流程解决的是「怎么连上、连上之后建什么」。寻呼和切换解决的是另一个维度的问题UE 不在连接态时怎么被找到以及连接态下怎么在不中断业务的前提下换小区。这两件事看着不相关实际都围绕一个核心问题——网络侧怎么知道 UE 现在在哪。寻呼是靠区域广播去找切换是靠信令交互把连接搬过去。理解了这一点两条流程的消息设计就都好记了。4.1 寻呼5GC寻呼与RAN寻呼的边界在哪寻呼分两种区分标准是 UE 处在哪个状态。5GC 寻呼面向 RRC_IDLE 态的 UE。UE 空闲时核心网侧只知道它大致在哪个注册区不知道具体在哪个小区所以由核心网发起 NGAP PAGING 下发到辖区内的多个 gNB各 gNB 在空口发 RRC Paging。RAN 寻呼面向 RRC_INACTIVE 态的 UE。这个状态下 UE 的上下文还保留在 RAN 侧所以寻呼由 RAN 自己发起在 RAN 通知区域内广播 RAN PAGING不需要经过核心网。类型触发侧适用状态关键消息范围5GC 寻呼核心网RRC_IDLENGAP PAGING、RRC Paging注册区内的多个 gNBRAN 寻呼gNBRRC_INACTIVERAN PAGINGRAN 通知区域这两者最容易混淆的地方在于空口上看到的都是一条 Paging 消息但触发来源完全不同。只看空口、不看回程判断不出是核心网找不到 UE 还是 RAN 找不到 UE。正确的顺序是先看有没有 NGAP PAGING有就是 5GC 寻呼没有再看 RAN 侧就是 RAN 寻呼。寻呼消息什么时候发由寻呼帧和寻呼时机决定。UE 根据自身标识和 DRX 周期算出应该在哪一帧、哪一时刻监听网络侧按同样的规则在这些时刻下发。这意味着寻呼不是随时可发的发早了发晚了 UE 都收不到。分析寻呼失败时先确认下发时刻是否落在 UE 的监听时机上比直接怀疑覆盖更有效率。4.2 切换站内、Xn、N2三种路径怎么判定切换分三种路径判定的依据是源小区和目标小区之间有没有直接接口。站内切换发生在同一个 gNB 内部源小区和目标小区属于同一个基站。这种切换最简单全部在基站内部完成回程上不会有 Xn 或 N2 的信令空口上体现为一次 RRCReconfiguration。看到切换前后没有任何回程消息只有空口重配置基本可以确定是站内切换。Xn 切换发生在两个 gNB 之间且两者之间有 Xn 接口。源 gNB 直接通过 Xn 向目标 gNB 发切换请求目标侧准备好之后回确认源侧再通过空口命令 UE 切换。整条链路不经过核心网时延短。判断标志是回程上出现 Xn 侧的切换请求与响应而 NGAP 侧没有对应的切换消息。N2 切换同样发生在两个 gNB 之间但两者之间没有 Xn 接口只能绕道核心网。源 gNB 通过 NGAP 向核心网发切换请求核心网转发给目标 gNB目标侧准备完成后逐级回传。判断标志是 NGAP 侧出现成对的切换请求与响应。类型源与目标关系是否经过核心网回程判断标志站内切换同一 gNB 内否无回程切换信令仅空口重配置Xn 切换不同 gNB有 Xn否Xn 侧切换请求与响应N2 切换不同 gNB无 Xn是NGAP 侧切换请求与响应这三种路径的失败点分布差别很大。站内切换失败基本是空口或内部资源问题Xn 切换失败要看 Xn 链路和两侧的资源配置N2 切换失败还要多考虑一段核心网转发。只盯空口看切换最多只能判断出「切换没成功」判断不出「在哪一段没成功」。4.3 LNR切换与LNR重定向跨制式时的差异跨制式的场景有两条路切换和重定向。它们的区别在于是否保持连接连续性。LNR 切换是把连接从 LTE 侧搬到 NR 侧过程中业务尽量不中断。它要走完整的切换准备流程源侧和目标侧都要参与最后 UE 在目标侧接入并确认。LNR 重定向不保证连续性网络侧下发一条重定向命令告诉 UE 去哪个频点或哪个制式UE 释放当前连接后自己去搜、自己去接。前面第 2 章讲的整套开机入网流程在重定向之后要重新走一遍。这个差异对分析的意义在于重定向之后出现一段完整的入网流程是正常的不是异常。有经验的人看到重定向命令后面跟着小区搜索、系统消息、随机接入、RRC 建立会知道这是设计如此经验不足的人容易把这段当成「切换失败后重新接入」误判为故障。判断的关键就是前面那条命令是切换命令还是重定向命令。4.4 NAS流程注册、去注册与业务请求的信令组合NAS 流程是 UE 与核心网之间的对话空口只是通道。它主要有三类注册、去注册、业务请求。注册是 UE 向网络登记自己的过程发生在开机入网的最后一步也可以在其他需要重新登记的场景触发。去注册分终端发起和网络发起两种发起方不同消息的走向也不同终端发起是 UE 主动请求离开网络侧确认网络发起是网络侧通知 UE 被去注册UE 回应。这两种在跟踪里的消息顺序是镜像的看第一条消息的方向就能分清。业务请求分主叫和被叫。主叫是 UE 主动发起业务先发业务请求网络侧响应后再建立承载被叫是网络侧有下行数据要送给 UE先寻呼UE 响应后再发起业务请求。这两条流程的入口完全不同主叫的入口是 UE被叫的入口是寻呼。所以分析被叫失败第一步应该看寻呼有没有发出去、UE 有没有响应而不是直接去看业务请求。NAS 流程和 AS 流程是咬合的。注册消息搭在 RRCSetupComplete 上业务请求的响应会触发后续的会话资源建立。这意味着 NAS 层面的每一次交互在空口和回程上都有对应的动作。把 NAS 消息当成独立的一条线去看会漏掉它与上下文、会话流程之间的因果关系。5. 易漏点信令分析里最容易翻车的五处细节5.1 只看单层不做三层时间轴对齐易漏点只盯空口 RRC 消息或者只盯 NGAP 消息把两层分开看。为什么漏抓包工具默认按协议分层展示每层一个窗口滚动的时候很容易只在自己熟悉的那一层里看。RRC 消息和 NGAP 消息的时间戳往往相差几毫秒到几十毫秒不对齐就看不出因果关系。怎么补把三层消息按时间戳合并成一条链。下面这段脚本把 RRC、NGAP、NAS 三条记录合并排序输出的就是一条可以直接读的时间轴# 将三层信令记录按时间戳合并为单条时间轴 # 每条记录格式: (时间戳毫秒, 协议层, 消息名, 方向) records [ (1020, RRC, RRCSetupRequest, UE-gNB), (1055, RRC, RRCSetup, gNB-UE), (1080, RRC, RRCSetupComplete, UE-gNB), (1102, NGAP, INITIAL_UE_MESSAGE, gNB-AMF), (1200, NGAP, INITIAL_CONTEXT_SETUP_REQUEST, AMF-gNB), ] # 按时间戳升序排列同一时刻保持原有顺序 records.sort(keylambda r: r[0]) for ts, layer, msg, direction in records: # 输出格式相对时间 | 协议层 | 方向 | 消息名 print(f{ts:6}ms | {layer:5} | {direction:7} | {msg})参数说明元组第一个字段是相对时间戳单位毫秒取自抓包的绝对时间减去首包时间第二个字段是协议层用来区分消息归属第三个字段是消息名第四个字段是方向。排序键只取时间戳是因为同一毫秒内的消息顺序在抓包里本来就是确定的重排反而会打乱。这段脚本的价值不在代码本身而在于逼着自己把三层放在同一行上看——很多「消息缺失」的疑问对齐之后会发现只是发生在另一层。5.2 忽略 SIB1 里的 OSI 发送方式易漏点默认所有 SIB 都是周期广播按固定周期去找 SIB2 及以后的消息。为什么漏LTE 时代的习惯带过来了系统消息就是周期广播按时隙去找就行。5G 引入了 ODOSISIB1 里明确指示了 OSI 是周期广播还是订阅广播以及订阅走 Msg1 还是 Msg3。这段指示信息藏在 SIB1 的字段里不逐字段读就会漏掉。怎么补拿到 SIB1 之后先定位 OSI 的发送机制字段确认是周期广播还是 ODOSI。如果是 ODOSI再确认触发方式是 Msg1 还是 Msg3然后按对应的信令顺序去找。指望着在固定周期上等 SIB2等多久都不会出现。5.3 把 RRC 重发当成 RRC 拒绝易漏点看到连续两条 RRCSetupRequest就判定为网络侧拒绝接入。为什么漏两条请求挨得很近看起来像是被拒后重试。实际上拒绝是有明确消息的RRCReject 由 gNB 下发携带等待时间等信息。没有 RRCReject 的重发是 UE 侧定时器超时后的行为性质完全不同。怎么补判断标准只有一条——中间有没有 RRCReject。有是网络侧主动拒绝方向查网络侧的处理逻辑和资源状态没有是响应缺失方向查下行覆盖、gNB 处理时延、以及请求消息本身是否被正确接收。两种情况的排查路径几乎没有交集。5.4 切换只分析空口不看回程的 AP 层易漏点切换失败时反复看空口重配置忽略了 Xn 或 NGAP 侧的切换请求与响应。为什么漏空口消息直观抓包也容易回程消息需要另外配置抓取点。而且站内切换确实没有回程消息做多了站内切换就容易形成「切换只看空口」的惯性。怎么补先判定切换类型。空口重配置前后没有任何回程切换信令是站内切换有 Xn 侧请求与响应是 Xn 切换有 NGAP 侧请求与响应是 N2 切换。判定完类型再按对应的路径去查失败点。跳过类型判定直接看空口等于放弃了三分之二的故障域。5.5 QFI 与 DRB ID 的映射关系没有对齐易漏点看 RRCReconfiguration 的 DRB 配置时发现 DRB 数量和会话请求里的 QFI 数量不一致判定为配置错误。为什么漏默认 QoS Flow 和 DRB 是一一对应的。5G 的 SDAP 层允许多个 QoS Flow 复用到同一条 DRB 上只要 QoS 特性接近就可以合并合并之后数量自然对不上。怎么补把核心网侧会话请求里的 QFI 列表和空口侧 RRC 重配置里的 DRB 配置列在一起逐条对齐映射关系。对齐之后如果发现某个 QFI 没有落到任何 DRB 上那才是真的问题数量不一致本身不是问题。另外要注意默认 DRB 的存在它承载的往往是不带专用 QoS 要求的流容易被当成多余的配置。6. 复习清单把六条流程压成一张可复述的表复习这件事我自己的做法是不背消息名而是背「每条流程的起点、终点、以及中间可能断在哪」。消息名忘了可以查流程断了却不知道断在哪才是真的卡住。下面这张表是我每次复盘都会过一遍的版本按流程顺序排每行只留最必要的信息。流程起点消息终点消息最常断的位置小区搜索与选择PSS/SSS 检测OSI 读取完成MIB 之后无 SIB1先查小区禁止状态系统消息广播MIB 解析OSI 获取完成SIB1 指示 ODOSI 却按周期广播找随机接入Msg1 前导Msg4 竞争解决或 Msg2 完成Msg2 之后无 Msg3查上行授权RRC 连接建立RRCSetupRequestRRCSetupComplete连续请求无 Reject是超时重发初始上下文建立INITIAL CONTEXT SETUP REQUESTINITIAL CONTEXT SETUP RESPONSE安全模式未完成后续全部阻塞PDU 会话建立PDU SESSION RESOURCE SETUP REQUEST对应 RESPONSERRC 重配置发出但无 Complete寻呼NGAP PAGING 或 RAN PAGINGUE 响应下发时刻不在 UE 监听时机上切换切换请求切换完成未判定切换类型就开始查空口NAS 注册Registration RequestRegistration Accept未确认是否搭载在 RRCSetupComplete 上查漏补缺的方法我习惯按「三段切分」走一遍拿到一段跟踪先把消息按核心网侧、回程、空口三段分开再确认每段的起点和终点是否配对也就是请求有没有响应、命令有没有确认最后只在不配对的那一段里找原因。这个方法的好处是不依赖对具体消息名的记忆只要配对关系清楚故障域就能一路缩小。还有一个我踩过的坑值得单独说早期分析入网失败我总是从 RRC 往上翻翻了半天发现根本没有 RRC 消息问题停在系统消息那一步。后来改了习惯任何一次入网分析都从小区搜索开始按顺序过一遍不跳步。跳步省下的那几分钟往往要在后面用几倍的时间补回来。从那以后我每次拿到跟踪文件都强制自己先过一遍五级台阶的顺序确认每一步的起点消息都出现了再去做深入分析。希望这些梳理能帮到你少走几段我走过的弯路。本文还有配套的精品资源点击获取