简介这是一份面向网络优化网优工程师、5G核心网及无线侧运维人员的5G信令分析指导书聚焦于端到端信令流程梳理与关键消息解读帮助读者在现网排障、信令跟踪和参数优化中快速定位问题。手册按流程模块组织覆盖开机入网全流程小区搜索与选择、系统消息广播与更新、ODOSI过程、基于竞争/非竞争的随机接入、RRC连接建立及拒绝处理、注册、初始上下文建立、PDU会话管理5G QoS架构与会话建立/修改/释放、5GC与RAN寻呼、站内/Xn/N2/LNR切换及重定向、NAS流程注册、去注册、业务请求等完整链路并对MIB、SIB1、SI等广播消息做了字段级解读便于对照实际信令报文学习。资源包共1个docx文档压缩包大小4.24MB内容以表格、流程图和消息参数说明相结合适合系统学习及现场查阅。目前已有60人学习下载对希望从流程视角掌握5G信令分析要点的网优从业者与通信专业学生具有实用参考价值。1. 5G信令分析指导书从开机入网到NAS流程的一张信令地图5G信令分析是网优工程师绕不开的基本功尤其是5G SA组网下UE从开机到业务建立要经历小区搜索、系统消息读取、随机接入、RRC建立、注册、初始上下文建立、PDU会话建立等多段信令过程每一段都涉及UE、gNB、5GC三方的消息配合任一环脱节都会表现为接入失败、寻呼无响应或者切换掉线。这份指导书按开机入网、上下文管理、会话管理、寻呼、切换、NAS六个模块组织每个流程都配了信令图例和关键字段的逐条解读覆盖5G SA从接入到承载建立的完整信令链路适合网优、测试和协议开发人员当案头手册用。对刚转5G的从业者来说照着流程图一步步捋下来比零散翻协议要快得多对熟手来说里面不少参数对照表和分析要点能省下翻规范的时间。2. 开机入网从小区搜索到系统消息读取的完整链路2.1 小区搜索PSS/SSS同步与PCI获取的技术细节UE开机后的第一件事不是发起注册而是先找到小区。指导书里给的小区搜索流程是UE按3GPP TS 38.104定义的Synchronization Raster搜索频点检测PSS/SSS取得下行时频同步并获取PCI读取MIB获取SSB波束信息和SIB1的时频位置再读SIB1拿初始BWP配置和随机接入参数。这个过程在空口信令里是看不到的因为PSS/SSS是物理层信号抓包工具一般不会在RRC层显示日志。但理解它依然重要。PCI的计算方式是 PCI 3 × NID1 NID2NID1来自SSS取值0~335NID2来自PSS取值0~2一旦PSS和SSS检测成功PCI就已经确定。实际排查中如果发现某个小区UE驻留不了先看SSB的频域位置和PCI混淆情况而不是急着查核心网。PCI混淆在密集城区经常出现两个小区PCI相同且在同一频点UE会频繁重选或切入错误小区。SSB本身的时频结构也需要理解。一个SSB块在时域占4个OFDM符号频域占240个子载波周期由网络侧的ssbPeriodicityServingCell配置常见取值是5ms、10ms、20ms。指导书里专门提醒SSB周期会影响UE的同步时间和功耗周期太短浪费资源太长则UE接入变慢。在TDD组网下SSB还要避开下行时隙的边界这个和半静态配比强相关配错了SSB和PDCCH冲突UE会周期性丢失同步表现就是时而接入成功时而无响应。频点搜索也是容易被忽略的一环。NR的同步栅格密度比LTE小不是每个频点都去扫。如果gNB配置的SSB实际频点和同步栅格不匹配UE按标准栅格扫不到这个小区。这个在实验室调测时经常遇到基站侧把SSB频点设成了一个非栅格值UE死活搜不到小区。解决方法是把SSB频点对齐到全局同步栅格或者通过frequencyInfoDL里的额外频点列表让UE知道该去哪个位置找。2.2 系统消息获取MIB到SIB1再到OSI的读取顺序系统消息是UE入网拿到的第一份说明书。指导书把系统消息分为两大类MSIMinimum System Information和OSIOther System Information。MSI只包含MIB和SIB1是UE能否驻留的底线信息OSI包含SIB2到SIBn是邻区、移动性、告警等扩展信息。MIB是UE开机后读到的第一条系统消息承载在BCCH上周期固定80ms内容虽短但每个字段都关键。指导书里对MIB字段的解读可以整理成下面的表这份表在排查驻留问题时我每次都会翻MIB字段作用信令分析要点systemFrameNumber系统帧号高6位与SSB的SFN低4位组合成完整SFN用于帧同步subCarrierSpacingCommonSIB1的公共子载波间隔15/30kHz两种配错会导致SIB1解码失败ssb-SubcarrierOffsetSSB相对PRB0的频域偏移结合k_SSB才能正确找到SIB1的RB位置dmrs-TypeA-PositionPDSCH DMRS符号位置影响下行数据解调性能pdcch-ConfigSIB1SIB1的PDCCH搜索空间配置配置错误直接导致SIB1收不到cellBarred小区是否被禁止接入barred时UE直接放弃该小区换频点搜索SIB1的内容比MIB多得多。指导书把SIB1的字段分成小区选择、初始BWP、TDD配比、OSI搜索空间、UAC统一接入控制几组。实际排查中我一般先看三个参数initialDownlinkBWP里PRACH的时频配置、TDD的上下行时隙配比、cellReservedForOtherUse字段。这三个地方出错UE会反复驻留失败或者随机接入不成功。尤其是TDD配比如果gNB广播的时隙配比和实际调度不一致UE会在上行时隙里发PRACHgNB根本收不到。这个问题的诡异之处在于空口抓包看起来UE一直在发Msg1基站侧统计却显示PRACH接收为零典型的两边对不上。排到这一步先拿SIB1里的tdd-UL-DL-ConfigurationCommon和网管侧实际配对比一遍就能看出来。OSI的获取有两种方式周期广播和按需订阅ODOSI。这是5G相比4G新增的机制算是这代网络里比较新的玩法。如果SIB1里指示其他SIB走周期广播UE直接使用SIB1里给的OSI搜索空间去监听即可如果指示的是订阅广播UE需要通过Msg1或Msg3发起订阅请求gNB再按需广播。ODOSI的坑在于如果gNB配置了订阅广播但UE不支持Msg3订阅方式——部分低版本终端只有Msg1能力——就会一直拿不到SIB2~SIBn最后表现为邻区关系丢失、小区重选异常。排查时先看SIB1里si-SchedulingInfo中的si-BroadcastStatus字段如果标记为notBroadcasting说明这个SI确实需要订阅再检查UE是否成功发起了订阅请求。2.3 系统消息更新触发条件与ODOSI过程UE不会反复读取系统消息。指导书明确写了只有三种情况会重新读取收到gNB寻呼指示系统消息变化systemInfoModification、收到寻呼指示有ETWS或CMAS告警广播、距离上次成功接收系统消息超过3小时。这个3小时定时器定义在38.331的5.2.2.2.1到期后UE会删除所有存储的SI版本并重新完整获取。网优分析中如果小区改了系统消息参数但UE侧一直不生效多半是gNB没发systemInfoModification的寻呼指示或者UE行为异常没响应。验证方法是抓空口寻呼消息看pagingRecord里有没有systemInfoModification标志。抓包的常见做法是# 用 tshark 过滤寻呼和SIB1确认系统消息更新标志是否置位 tshark -r sib_update.pcapng -Y rrc-nr.paging || rrc-nr.dl.dcch.sib1 -V | \ grep -E systemInfoModification|etws|cmas这条命令把寻呼消息和SIB1都过滤出来再grep系统消息更新相关字段。如果systemInfoModification标志从0变1说明gNB确实发了更新指示如果长时间没变化问题就在gNB侧参数配置或者寻呼消息封装上这时候要看网管侧是否打开了系统消息更新开关。注意如果小区里UE数量很大gNB不会对每个UE单独发更新指示而是在寻呼消息里带一个公共的更新标志UE收到后自己去重新读SIB1。ODOSI过程本身也值得单独看。UE发起订阅请求的方式有两种Msg1方式和Msg3方式。Msg1方式用PRACH前导码做订阅标识Msg3方式通过RRCSystemInfoRequest消息带上请求的SIB列表。指导书里强调gNB在SIB1中通过si-RequestConfig配置了两种方式分别使用的资源UE按能力选择。如果订阅消息发了但gNB不回广播先检查gNB侧是否开启了按需广播功能再看订阅请求里请求的SIB ID是否在允许列表里。有些厂家的实现里ODOSI的订阅广播窗口是固定的如果订阅请求来得晚了UE要等下一个周期才能收到广播。这种场景下抓包看到的现像是UE发了一次订阅请求后要隔几百毫秒甚至更久才收到SI容易被误判为网络异常。实际上只要确认gNB最终把SI发出去了而且UE成功解码流程就算正常只是延迟偏大。3. 随机接入与RRC连接建立从竞争四步到RRC重发处理的完整链路3.1 基于竞争的随机接入四步消息里容易被忽略的细节随机接入是UE和gNB建立上行同步的过程也是空口信令分析里见得最多的流程之一。基于竞争的随机接入CBRA是四步消息指导书里每一步都单独画了流程Msg1UE发送PRACH前导码携带RA-RNTI作为临时标识。Msg2gNB回复随机接入响应RAR包含定时提前量TA、临时C-RNTI和UL grant。Msg3UE在UL-SCH上发送第一条调度消息携带用户标识和具体业务原因。Msg4gNB发送竞争解决消息UE收到后确认自己是唯一的接入者。指导书对这四步的解读有几个值得注意的点。第一Msg2里不仅有时序提前量还携带UL grant也就是说gNB在RAR里就直接分配了上行调度资源UE不需要再等单独的调度请求。第二如果Msg3里带了C-RNTI说明这个UE已经有C-RNTI了——典型场景是切换入的UE——竞争解决会简化gNB不需要再做身份冲突检测。第三TA的值是12位取值范围0~1282单位是Tc0.509ns换算下来每个TA单位对应约0.65米的传输距离。这个换算在做TA分析和覆盖评估时很实用一眼就能从TA值看出UE离基站大概多远。实际信令分析中随机接入失败的排查重点在两个地方PRACH时频资源配置和RAR窗口设置。PRACH的prach-ConfigurationIndex决定前导码在时域上的发送时机如果UE的发送时机和gNB的接收窗口不匹配Msg2永远等不到。RAR窗口由rars-WindowLength配置单位是时隙如果窗口设置太短UE在窗口内没收到RAR就会重发Msg1形成循环。这两个参数在指导书的随机接入章节都有对照表直接查表比翻规范快得多。随机接入还有一类问题是前导码冲突概率过高。每个小区的CPECell-specific Preamble数量是固定的如果小区里用户数很多两个UE同时选到同一个前导码的概率就上去了。Msg4竞争解决失败的比例会升高UE会重试整个流程。网优上遇到这种情况优先看PRACH资源的密度和冲突概率指标必要时增加PRACH配置的频域密度。3.2 基于非竞争的随机接入切换场景为什么更常用基于非竞争的随机接入CFRA通常用于切换、波束失败恢复、辅小区添加等场景。指导书里把CFRA流程写成三步gNB通过RRC信令分配专用的PRACH资源或前导码UE在指定资源上发起Msg1gNB直接回复Msg2完成接入。CFRA和CBRA的根本区别在于Msg1不需要竞争解决因为前导码是gNB专门分配给该UE的不会和其他UE冲突。代价是专用资源消耗大、管理复杂。在切换场景中目标gNB会在切换命令里携带专用前导码UE到目标小区后直接发这个码省掉Msg3/Msg4的往返能明显缩短切换中断时间。5G的切换中断目标一般要求做到几十毫秒以内CFRA是关键手段之一。实践中的坑是CFRA的专用前导码是一次性的如果UE发了Msg1但没收到Msg2这个前导码就作废了UE只能回退到CBRA重新来。从信令分析角度看如果切换时看到UE先是CFRA发起然后转入CBRA基本可以确认是目标小区的RACH资源紧张或者连续发送次数到达上限触发了回退。指导书在切换流程部分也提到了这一点排查时优先看目标小区的RACH配置尤其是专用前导码的分配数量是不是太少。还有一种情况是CFRA触发了但UE一直没发Msg1。这种现像常见于目标小区的SSB波束方向配置和UE的实际位置不匹配——UE扫描到的SSB波束质量不满足门限就不会在对应的PRACH资源上发前导码。这时候空口看起来就是切换命令下了、目标小区没反应最后源小区等超时触发RRC重建。排到这里要去看目标小区的波束覆盖而不是一直分析切换信令本身。3.3 RRC建立、拒绝与重发三类异常信令现象RRC连接建立是UE和gNB之间的握手包含三个子过程正常建立、RRC拒绝、RRC重发。指导书把三类现象分开讲每类都给了消息字段和排查方向。正常流程是UE发RRCSetupRequestgNB回RRCSetupUE再回RRCSetupComplete。RRCSetupRequest里最关键的是establishmentCause也就是UE告诉网络为什么建立连接。取值包括emergency、highPriorityAccess、mt-Access、mo-Signalling、mo-Data等。如果大量UE都用emergency发起接入说明终端侧或NAS层有异常这个指标在网管侧也能看到。RRCSetup里重点看radioBearerConfig和masterCellGroup配置这两个决定了UE后续的承载和MAC层行为尤其masterCellGroup里的schedulingRequestConfig配错了会导致UE连SR都发不出去。RRCSetupComplete里会携带NAS消息比如注册请求以及registeredAMF和selectedPLMN-Identity字段用于告诉网络UE选了哪个PLMN和AMF。RRC拒绝是gNB明确拒绝UE的建立请求。RRCReject消息里带一个waitTime参数单位秒告诉UE要等多久才能再次发起。实际中常见的原因是拥塞控制gNB的RRC连接数达到上限或者该UE被统一接入控制拦截。排查时先看拒绝消息里的waitTime和扩展拒绝原因再看gNB侧的负载指标。如果waitTime总是很大比如十几秒说明gNB长期处于拥塞状态这不是信令问题而是容量问题得从资源评估入手。RRC重发是另一类现象UE发了RRCSetupRequest但超时没收到RRCSetup于是重发请求。驱动RRC重发的是T300定时器如果T300超时且没有收到RRCSetup或RRCRejectUE就重发RRCSetupRequest。T300设置太短会频繁重发太长则接入延迟变大。标准里T300的范围是100ms到2000ms网优里一般建议在覆盖边缘场景放长一些避免接入还没完成就超时。排查思路分两步先看RRCSetupRequest有没有到达gNB如果到了但gNB没回RRCSetup问题在gNB的调度或下行覆盖如果gNB根本没收到问题在上行覆盖或PRACH配置。实际操作时可以用下面的命令统计# 统计 RRCSetupRequest 的 establishmentCause 分布和重复UE标识 tshark -r rrc.pcapng -Y rrc-nr.establishmentCause -T fields \ -e rrc-nr.establishmentCause -e rrc-nr.ue.identity | \ sort | uniq -c | sort -rn这条命令把每条RRCSetupRequest的establishmentCause和UE标识提取出来按出现次数排序。如果某个establishmentCause大量出现且UE标识重复基本可以坐实重发问题如果UE标识每次都不一样那可能是覆盖边缘大量新UE接入属于业务高峰的正常现象。重发率这个指标在网管里通常也有统计但不如直接看抓包来得直观尤其是定位到具体UE时。4. 上下文管理与会话管理从安全模式到PDU会话的信令链条4.1 初始上下文建立安全模式与UE能力查询的配合RRC建立完成后网络侧要做两件事激活安全模式和查询UE能力这两件事和初始上下文建立绑在一起。指导书把初始上下文建立过程拆成了NGAP消息和RRC消息两段来看。NGAP侧核心网下发Initial Context Setup Request里面携带UE安全能力、NAS消息、以及可选的PDU会话建立列表。gNB收到后如果消息里带了安全参数就先启动安全模式过程如果带了UE能力请求标志就发起UE能力查询。安全模式完成后gNB回Initial Context Setup Response把建立的DRB列表、QoS Flow状态回给核心网。这里有一个容易忽略的细节Initial Context Setup Request里如果带了PDU会话建立列表gNB会并行处理上下文建立和PDU会话建立而不是逐个等。所以抓包里会看到SecurityModeCommand、UECapabilityEnquiry、RRCReconfiguration几乎同时发下来这不是异常是正常的并行流程。安全模式过程是gNB下发SecurityModeCommandUE执行完整性保护和加密算法协商后回SecurityModeComplete。指导书里特别提醒如果UE回的是SecurityModeFailure多半是算法协商不一致比如gNB配置了UE不支持的加密算法。信令分析时还要同时看NAS层因为RRC安全模式建立在NAS鉴权成功的基础上NAS鉴权没过RRC安全模式也走不下去。实际中见过一种现像核心网侧配置了NEA0空加密但RAN侧没开导致UE和gNB算法列表对不上来回失败。UE能力查询是gNB通过UECapabilityEnquiry问UE支持什么UE回复UECapabilityInformation。正常流程下gNB在首次上下文建立时查询一次并缓存UE能力。但如果UE是从LTE切换过来的gNB可能没有缓存的能力信息就得重新查。UECapabilityInformation里的关键信元包括bandList支持的频段、supportedBandwidthList带宽组合、ca-BandwidthCombinationList载波聚合组合。网优在分析5G驻留问题时经常要核对UE上报的bandList是否覆盖了当前小区的SSB频点有些终端软件版本问题会导致bandList里漏报某些频段表现为这个频段下只有特定终端无法驻留。4.2 5G QoS架构QoS Flow到DRB的映射规则5G QoS架构和4G最大的区别是引入了QoS Flow的概念。指导书里把5G QoS架构拆成三层核心网侧QoS Flow、RAN侧DRB、空口侧承载。QoS Flow是PDU会话内服务质量的最小粒度一个或多个QoS Flow可以映射到一个DRB上由gNB决定映射关系。QoS参数是理解映射规则的关键指导书在4.1节给了一张QoS参数表核心参数整理如下这些参数在PDU会话建立、修改、切换准备时都会用到QoS参数作用典型值5QI标准化的QoS指标标识1语音、5IMS信令、8/9普通数据ARP分配和保留优先级1~15数值越小优先级越高GBR保证比特率GBR QoS Flow必须分配固定资源MBR最大比特率超出会被丢弃或降速PDB包延迟预算5QI1时PDB为100msPER包错误率5QI7时PER为10^-4QoS Flow到DRB的映射规则由gNB决定核心网通过NGAP消息把QoS Flow配置发给gNB。指导书强调了一个容易踩坑的点QoS Flow的GBR参数和DRB的实际调度参数不是一一对应的gNB需要结合空口资源情况决定是否接受这个QoS Flow。如果空口资源不够gNB会在PDU Session Resource Setup Response消息里带上Failed to Setup List把拒绝原因回给核心网。还有一类映射问题是同一个DRB下挂了多个QoS Flow但它们的5QI不同。比如一个DRB里既有QoS Flow 1语音又有QoS Flow 9普通数据这在调度上会导致DRB的PDCP层配置无法同时满足两者的PDB要求。指导书的建议是不同5QI类别的QoS Flow尽量映射到不同DRB除非网络允许一定程度的延迟提升。实际组网里运营商一般会把语音和视频单独建DRB普通数据走默认DRB避免调度冲突。4.3 PDU会话建立与修改NGAP和RRCReconfiguration的配合PDU会话建立是UE获得IP地址和数据承载的关键过程。整个流程涉及两条信令面N2接口的NGAP消息和空口的RRC消息指导书在4.2到4.4节把建立、修改、释放分别画了流程。N2侧核心网下发PDU Session Resource Setup Request携带PDU会话ID、QoS Flow列表、UP传输层信息——也就是gNB需要把用户面数据发往核心网的地址和TEID。gNB收到后做资源分配和DRB配置如果成功就回PDU Session Resource Setup Response响应里带上gNB侧分配的UP传输层地址和TEID。空口侧gNB通过RRCReconfiguration消息把PDU会话配置下发给UE里面带了PDU Session Configuration包括DRB配置、SDAP配置、QoS Flow到DRB的映射列表。UE配置完成后回RRCReconfigurationComplete。如果UE侧配置失败会回RRCReconfigurationFailuregNB再决定是重配还是释放这个PDU会话。实际排查中有一个高频问题PDU会话建立请求到了gNB但gNB一直不回响应。这种情况优先查UP传输层信息——如果核心网下发的UPF地址或TEID不对gNB无法建立用户面隧道就会卡在这里。用tshark可以这样提取关键字段# 查看 PDU Session Resource Setup Request 中的 QoS Flow 和 UPF 地址 tshark -r ngap.pcapng -Y ngap.pdu_session_resource_setup_request -V | \ grep -E QoS Flow|UPF|TEID|PDU Session ID|SNSSAI这条命令提取NGAP建立请求里的QoS Flow标识、UPF传输层地址、TEID、PDU会话ID和网络切片标识用来核对gNB侧收到的用户面参数是否与核心网配置一致。如果UPF地址段和实际核心网网段对不上说明核心网配置有误或者接口IP规划冲突。注意TEID在GTP-U协议里是32位标识如果配置成了16位也会导致用户面建不起来。PDU会话修改过程的排查思路类似。核心网下发PDU Session Resource Modify RequestgNB修改对应DRB参数后回Modify Response。如果修改涉及QoS Flow到DRB的映射变化gNB会再发一次RRCReconfigurationUE完成配置后上报Complete。修改过程最容易出错的是QoS Flow的5QI变化和DRB参数不匹配——比如原DRB是AM模式新加入的QoS Flow需要UM模式gNB需要新建DRB而不是复用旧的。这种问题在抓包里表现为RRCReconfiguration里同时出现了drb-ToAddMod和drb-ToRelease但UE侧实际上不支持某个PDCP配置组合。5. 寻呼与切换信令异常排查五个高频坑与解决步骤5.1 5GC寻呼与RAN寻呼触发条件与信令差异寻呼分两种5GC寻呼和RAN寻呼。指导书把两种流程都画了信令图差别很关键用错排查思路会浪费很多时间。5GC寻呼的典型场景是UE处于CM-IDLE状态有下行数据到达核心网通过NGAP PAGING消息通知gNBgNB再通过空口RRC PAGING消息找UE。NGAP PAGING里携带UE Identity5G-S-TMSI、TAI列表、以及可选的Paging DRX信息。gNB收到后在自己跟踪区范围内所有小区发RRC PAGING。RRC PAGING里的核心字段是pagingRecord列表每个记录包含5G-S-TMSI和pagingCause。RAN寻呼的场景是UE处于RRC_INACTIVE状态此时UE的上下文还保存在gNB。当下行数据到达时gNB直接在RAN通知区内发RRC PAGING不需要核心网介入。指导书里单独用5.2节讲RAN寻呼核心区别在于RAN寻呼的触发源是gNB而不是核心网寻呼范围是gNB管辖的RAN通知区而不是跟踪区。这个区别在排查寻呼不到UE的问题时非常关键如果UE在RRC_INACTIVE状态但gNB配置的RAN通知区不对UE就跑出寻呼范围了此时5GC寻呼也救不了因为核心网认为UE还在同一个gNB下面。5.2 切换类型对比站内、Xn、N2、LNR切换的边界指导书把切换分成四类站内切换gNB内部、Xn切换gNB间、N2切换通过核心网、LNR切换NR到LTE。边界条件不同排查思路也不同。站内切换不涉及Xn或N2接口由同一个gNB完成目标小区配置信令最简。Xn切换是gNB之间的直接切换需要Xn接口可用且两边的上下文能传输。N2切换走核心网适用于Xn不可用的场景信令路径变长中断时间也更长。LNR切换是从5G切到4G跨系统流程复杂RRC消息格式和QoS映射都要转换最容易出兼容性问题。实际组网里最常见的是Xn切换和LNR切换。Xn切换的失败排查先看Xn接口的Handover Request是否到达目标gNB再看目标gNB回复的是Ack还是Failure。如果Xn链路不通就要走N2切换兜底。LNR切换则要同时看5G侧和4G侧的RRC消息还要核对核心网下发的切换命令里是否携带了正确的LTE侧配置。LNR切换的QoS映射尤其容易出问题5G的QoS Flow映射到LTE的EPS Bearer时需要核心网提前做好5QI到QCI的映射表如果映射表缺项切换准备就会失败。5.3 常见问题排查五个反复出现的坑把实际信令分析中反复遇到的五类问题整理成现象-原因-解决的格式每条都是踩过的坑记下来能省不少时间。坑一寻呼消息发了但UE没响应现象核心网下发NGAP PAGING后空口也看到RRC PAGING但UE始终不回RRC Setup Request。原因最常见的是UE实际驻留的小区不在gNB下发寻呼的小区列表里或者UE处于非激活态但RAN寻呼范围配置错误。解决先核对NGAP PAGING里的TAI列表和gNB实际广播的TAI是否一致再查RRC PAGING里的寻呼记录是否携带了正确的5G-S-TMSI。抓两段数据N2接口看NGAP PAGING有没有到gNB空口看RRC PAGING有没有正确组帧。如果空口PAGING里携带的UE标识hash值和UE计算的对不上那UE根本不会响应这种问题在核心网和RAN侧使用不同寻呼参数配置时会出现。坑二切换准备失败Handover Request被目标gNB拒绝现象源gNB发Handover Request后目标gNB回了Handover Preparation Failure。原因目标gNB资源不足、UE能力信息不匹配、或者目标小区的加密算法配置与源侧不一致。解决看Handover Preparation Failure里的Cause值。如果是Radio Network Layer Cause优先查目标小区的空口资源比如目标小区是否处于拥塞或者被 barred如果是Protocol Cause查参数配置重点对比源和目标小区的加密算法列表和UE能力。指导书在切换章节后面列了常见Cause值的对照表排查时直接翻比翻协议快。坑三RRCReconfiguration下发后UE一直不回Complete现象gNB发了RRCReconfiguration但空口迟迟等不到RRCReconfigurationComplete。原因大概率是RRCReconfiguration里的配置UE不支持比如某个DRB的QoS参数超出UE能力或者PDCP配置里的discardTimer设置不合理。UE实际上会回RRCReconfigurationFailure但这条消息在抓包里容易漏看因为失败消息和正常消息在同一个逻辑信道上过滤条件写窄了就丢了。解决把抓包里所有RRCReconfigurationFailure都提出来比对failureCause。如果没抓到Failure再查下行覆盖可能是RRCReconfiguration重传也丢了。实际操作时可以按RRCSetupComplete里填的UE标识过滤把该UE后续的所有DL-DCCH消息都拉出来看。坑四PDU会话建立后业务还是不通现象PDU会话建立成功QoS Flow也映射到DRB了但用户面数据ping不通。原因常见的是UPF地址和TEID配置错误或者SDAP层把QoS Flow映射到了错误的DRB上。解决先核对NGAP Setup Response里的UPF传输层地址和TEID再检查RRCReconfiguration里的SDAP配置重点看QoS Flow to DRB mapping表。指导书里的QoS映射表模板照填一遍基本能定位出是核心网参数还是RAN侧映射的问题。有一种隐蔽情况是gNB侧为同一个PDU会话分配了多个DRB但SDAP层配置里QoS Flow ID到DRB ID的映射表和NGAP侧下发的不一致导致数据被发到错误DRB上空口侧完全看不出来只能对比两边的映射表。坑五去注册流程异常导致UE状态不一致现象UE发起去注册但核心网没回Deregistration Accept或者回的是网络发起的去注册。原因NAS层去注册请求里的deregistrationType和accessType配置不对或者UE在去注册过程中又触发了新的业务请求导致状态机冲突。解决看NAS去注册请求里的deregistrationType和5GMM Cause值。如果是UE发起的正常去注册核心网必须回Accept如果回Reject拿Reject里的5GMM Cause值对照NAS层规范表排查重点看是不是重复注册导致老上下文被顶掉。还有一种情况是UE同时发起去注册和PDU会话释放核心网处理顺序不对导致会话状态残留后面再注册时会话建立失败。6. 信令分析五步法从抓包到定位的实操习惯信令分析不是拿到pcap就一通乱翻。我自己的习惯是固定走五步每一步都有明确产出这样不管多复杂的信令问题都能在半小时内找到方向。第一步按接口拆解抓包。N2接口看NGAP空口看RRCUE侧看NAS。三个接口分开过滤后先确认每一段的关键信令都出现了。比如注册流程里NGAP的Initial UE Message、RRC的RRCSetupComplete、NAS的Registration Request必须三连出现。缺了哪一段问题就在哪个接口这一步能把问题范围缩小到单接口。第二步拉通时间线。把同一个UE的所有信令按时间排序标注每个时间点的事件。这一步我会用tshark把单个UE的信令先过滤出来# 按 5G-S-TMSI 过滤单个 UE 的全流程信令按时间排序输出 tshark -r full.pcapng -Y ngap || rrc-nr || nas-5gs -T fields \ -e frame.time_epoch -e frame.protocols -e ngap.procedureCode \ -e rrc-nr.dl.dcch.message -e nas-5gs.mm.type | \ grep 5g-stmsi | head -50这条命令把NGAP、RRC、NAS三类消息按时间戳拉出来grep出和指定5G-S-TMSI相关的记录然后就能直观看到UE的完整信令轨迹。参数grep 5g-stmsi里填的是实际抓包里看到的TMSI值如果第一次抓包没看到可以先用ngap.paging_identity或者rrc-nr.pagingrecord里的字段反查。第三步对照指导书里的标准信令流程图找差异。差异不等于故障但每个差异都要能解释。比如标准注册流程里注册成功后应该有Initial Context Setup Request如果没看到说明网络侧没有成功建立UE上下文回去查AMF侧的UE上下文创建是否成功。这一步需要把指导书对应章节的流程图翻开一条消息一条消息地比。第四步查关键字段。注册流程看NAS的5GMM Cause上下文建立看NGAP Cause切换看Handover Preparation Failure的Cause。指导书后面已经把这些原因值列了对照表直接翻对应章节就能找到含义和常见处理方式。查字段时要注意Cause值只是结果不是原因比如PDU会话建立失败报Radio Network Layer Cause还得继续看是资源不足还是切片不支持。第五步写分析结论。结论要包含三部分现象是什么、原因是什么、建议怎么改。网优工程师最怕的就是只报现象不报原因写清楚这三部分研发侧才能快速处理也能减少来回确认的时间。写结论时附上关键信令的截图和抓包时间点方便后续复现验证。这套五步法我用了一段时间每处理一个信令问题都会回看指导书的对应章节确认自己的排查路径有没有漏掉某一环。从那以后每次拿到新的信令抓包我都强制先走一遍这个流程不再一上来就翻包找异常。五步走完问题基本能定位到具体接口和具体消息希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/12 19:04:36 · 阅读 1.2k 5G信令分析实战：从开机入网到NAS流程的完整排查指南
简介这是一份面向网络优化网优工程师、5G核心网及无线侧运维人员的5G信令分析指导书聚焦于端到端信令流程梳理与关键消息解读帮助读者在现网排障、信令跟踪和参数优化中快速定位问题。手册按流程模块组织覆盖开机入网全流程小区搜索与选择、系统消息广播与更新、ODOSI过程、基于竞争/非竞争的随机接入、RRC连接建立及拒绝处理、注册、初始上下文建立、PDU会话管理5G QoS架构与会话建立/修改/释放、5GC与RAN寻呼、站内/Xn/N2/LNR切换及重定向、NAS流程注册、去注册、业务请求等完整链路并对MIB、SIB1、SI等广播消息做了字段级解读便于对照实际信令报文学习。资源包共1个docx文档压缩包大小4.24MB内容以表格、流程图和消息参数说明相结合适合系统学习及现场查阅。目前已有60人学习下载对希望从流程视角掌握5G信令分析要点的网优从业者与通信专业学生具有实用参考价值。1. 5G信令分析指导书从开机入网到NAS流程的一张信令地图5G信令分析是网优工程师绕不开的基本功尤其是5G SA组网下UE从开机到业务建立要经历小区搜索、系统消息读取、随机接入、RRC建立、注册、初始上下文建立、PDU会话建立等多段信令过程每一段都涉及UE、gNB、5GC三方的消息配合任一环脱节都会表现为接入失败、寻呼无响应或者切换掉线。这份指导书按开机入网、上下文管理、会话管理、寻呼、切换、NAS六个模块组织每个流程都配了信令图例和关键字段的逐条解读覆盖5G SA从接入到承载建立的完整信令链路适合网优、测试和协议开发人员当案头手册用。对刚转5G的从业者来说照着流程图一步步捋下来比零散翻协议要快得多对熟手来说里面不少参数对照表和分析要点能省下翻规范的时间。2. 开机入网从小区搜索到系统消息读取的完整链路2.1 小区搜索PSS/SSS同步与PCI获取的技术细节UE开机后的第一件事不是发起注册而是先找到小区。指导书里给的小区搜索流程是UE按3GPP TS 38.104定义的Synchronization Raster搜索频点检测PSS/SSS取得下行时频同步并获取PCI读取MIB获取SSB波束信息和SIB1的时频位置再读SIB1拿初始BWP配置和随机接入参数。这个过程在空口信令里是看不到的因为PSS/SSS是物理层信号抓包工具一般不会在RRC层显示日志。但理解它依然重要。PCI的计算方式是 PCI 3 × NID1 NID2NID1来自SSS取值0~335NID2来自PSS取值0~2一旦PSS和SSS检测成功PCI就已经确定。实际排查中如果发现某个小区UE驻留不了先看SSB的频域位置和PCI混淆情况而不是急着查核心网。PCI混淆在密集城区经常出现两个小区PCI相同且在同一频点UE会频繁重选或切入错误小区。SSB本身的时频结构也需要理解。一个SSB块在时域占4个OFDM符号频域占240个子载波周期由网络侧的ssbPeriodicityServingCell配置常见取值是5ms、10ms、20ms。指导书里专门提醒SSB周期会影响UE的同步时间和功耗周期太短浪费资源太长则UE接入变慢。在TDD组网下SSB还要避开下行时隙的边界这个和半静态配比强相关配错了SSB和PDCCH冲突UE会周期性丢失同步表现就是时而接入成功时而无响应。频点搜索也是容易被忽略的一环。NR的同步栅格密度比LTE小不是每个频点都去扫。如果gNB配置的SSB实际频点和同步栅格不匹配UE按标准栅格扫不到这个小区。这个在实验室调测时经常遇到基站侧把SSB频点设成了一个非栅格值UE死活搜不到小区。解决方法是把SSB频点对齐到全局同步栅格或者通过frequencyInfoDL里的额外频点列表让UE知道该去哪个位置找。2.2 系统消息获取MIB到SIB1再到OSI的读取顺序系统消息是UE入网拿到的第一份说明书。指导书把系统消息分为两大类MSIMinimum System Information和OSIOther System Information。MSI只包含MIB和SIB1是UE能否驻留的底线信息OSI包含SIB2到SIBn是邻区、移动性、告警等扩展信息。MIB是UE开机后读到的第一条系统消息承载在BCCH上周期固定80ms内容虽短但每个字段都关键。指导书里对MIB字段的解读可以整理成下面的表这份表在排查驻留问题时我每次都会翻MIB字段作用信令分析要点systemFrameNumber系统帧号高6位与SSB的SFN低4位组合成完整SFN用于帧同步subCarrierSpacingCommonSIB1的公共子载波间隔15/30kHz两种配错会导致SIB1解码失败ssb-SubcarrierOffsetSSB相对PRB0的频域偏移结合k_SSB才能正确找到SIB1的RB位置dmrs-TypeA-PositionPDSCH DMRS符号位置影响下行数据解调性能pdcch-ConfigSIB1SIB1的PDCCH搜索空间配置配置错误直接导致SIB1收不到cellBarred小区是否被禁止接入barred时UE直接放弃该小区换频点搜索SIB1的内容比MIB多得多。指导书把SIB1的字段分成小区选择、初始BWP、TDD配比、OSI搜索空间、UAC统一接入控制几组。实际排查中我一般先看三个参数initialDownlinkBWP里PRACH的时频配置、TDD的上下行时隙配比、cellReservedForOtherUse字段。这三个地方出错UE会反复驻留失败或者随机接入不成功。尤其是TDD配比如果gNB广播的时隙配比和实际调度不一致UE会在上行时隙里发PRACHgNB根本收不到。这个问题的诡异之处在于空口抓包看起来UE一直在发Msg1基站侧统计却显示PRACH接收为零典型的两边对不上。排到这一步先拿SIB1里的tdd-UL-DL-ConfigurationCommon和网管侧实际配对比一遍就能看出来。OSI的获取有两种方式周期广播和按需订阅ODOSI。这是5G相比4G新增的机制算是这代网络里比较新的玩法。如果SIB1里指示其他SIB走周期广播UE直接使用SIB1里给的OSI搜索空间去监听即可如果指示的是订阅广播UE需要通过Msg1或Msg3发起订阅请求gNB再按需广播。ODOSI的坑在于如果gNB配置了订阅广播但UE不支持Msg3订阅方式——部分低版本终端只有Msg1能力——就会一直拿不到SIB2~SIBn最后表现为邻区关系丢失、小区重选异常。排查时先看SIB1里si-SchedulingInfo中的si-BroadcastStatus字段如果标记为notBroadcasting说明这个SI确实需要订阅再检查UE是否成功发起了订阅请求。2.3 系统消息更新触发条件与ODOSI过程UE不会反复读取系统消息。指导书明确写了只有三种情况会重新读取收到gNB寻呼指示系统消息变化systemInfoModification、收到寻呼指示有ETWS或CMAS告警广播、距离上次成功接收系统消息超过3小时。这个3小时定时器定义在38.331的5.2.2.2.1到期后UE会删除所有存储的SI版本并重新完整获取。网优分析中如果小区改了系统消息参数但UE侧一直不生效多半是gNB没发systemInfoModification的寻呼指示或者UE行为异常没响应。验证方法是抓空口寻呼消息看pagingRecord里有没有systemInfoModification标志。抓包的常见做法是# 用 tshark 过滤寻呼和SIB1确认系统消息更新标志是否置位 tshark -r sib_update.pcapng -Y rrc-nr.paging || rrc-nr.dl.dcch.sib1 -V | \ grep -E systemInfoModification|etws|cmas这条命令把寻呼消息和SIB1都过滤出来再grep系统消息更新相关字段。如果systemInfoModification标志从0变1说明gNB确实发了更新指示如果长时间没变化问题就在gNB侧参数配置或者寻呼消息封装上这时候要看网管侧是否打开了系统消息更新开关。注意如果小区里UE数量很大gNB不会对每个UE单独发更新指示而是在寻呼消息里带一个公共的更新标志UE收到后自己去重新读SIB1。ODOSI过程本身也值得单独看。UE发起订阅请求的方式有两种Msg1方式和Msg3方式。Msg1方式用PRACH前导码做订阅标识Msg3方式通过RRCSystemInfoRequest消息带上请求的SIB列表。指导书里强调gNB在SIB1中通过si-RequestConfig配置了两种方式分别使用的资源UE按能力选择。如果订阅消息发了但gNB不回广播先检查gNB侧是否开启了按需广播功能再看订阅请求里请求的SIB ID是否在允许列表里。有些厂家的实现里ODOSI的订阅广播窗口是固定的如果订阅请求来得晚了UE要等下一个周期才能收到广播。这种场景下抓包看到的现像是UE发了一次订阅请求后要隔几百毫秒甚至更久才收到SI容易被误判为网络异常。实际上只要确认gNB最终把SI发出去了而且UE成功解码流程就算正常只是延迟偏大。3. 随机接入与RRC连接建立从竞争四步到RRC重发处理的完整链路3.1 基于竞争的随机接入四步消息里容易被忽略的细节随机接入是UE和gNB建立上行同步的过程也是空口信令分析里见得最多的流程之一。基于竞争的随机接入CBRA是四步消息指导书里每一步都单独画了流程Msg1UE发送PRACH前导码携带RA-RNTI作为临时标识。Msg2gNB回复随机接入响应RAR包含定时提前量TA、临时C-RNTI和UL grant。Msg3UE在UL-SCH上发送第一条调度消息携带用户标识和具体业务原因。Msg4gNB发送竞争解决消息UE收到后确认自己是唯一的接入者。指导书对这四步的解读有几个值得注意的点。第一Msg2里不仅有时序提前量还携带UL grant也就是说gNB在RAR里就直接分配了上行调度资源UE不需要再等单独的调度请求。第二如果Msg3里带了C-RNTI说明这个UE已经有C-RNTI了——典型场景是切换入的UE——竞争解决会简化gNB不需要再做身份冲突检测。第三TA的值是12位取值范围0~1282单位是Tc0.509ns换算下来每个TA单位对应约0.65米的传输距离。这个换算在做TA分析和覆盖评估时很实用一眼就能从TA值看出UE离基站大概多远。实际信令分析中随机接入失败的排查重点在两个地方PRACH时频资源配置和RAR窗口设置。PRACH的prach-ConfigurationIndex决定前导码在时域上的发送时机如果UE的发送时机和gNB的接收窗口不匹配Msg2永远等不到。RAR窗口由rars-WindowLength配置单位是时隙如果窗口设置太短UE在窗口内没收到RAR就会重发Msg1形成循环。这两个参数在指导书的随机接入章节都有对照表直接查表比翻规范快得多。随机接入还有一类问题是前导码冲突概率过高。每个小区的CPECell-specific Preamble数量是固定的如果小区里用户数很多两个UE同时选到同一个前导码的概率就上去了。Msg4竞争解决失败的比例会升高UE会重试整个流程。网优上遇到这种情况优先看PRACH资源的密度和冲突概率指标必要时增加PRACH配置的频域密度。3.2 基于非竞争的随机接入切换场景为什么更常用基于非竞争的随机接入CFRA通常用于切换、波束失败恢复、辅小区添加等场景。指导书里把CFRA流程写成三步gNB通过RRC信令分配专用的PRACH资源或前导码UE在指定资源上发起Msg1gNB直接回复Msg2完成接入。CFRA和CBRA的根本区别在于Msg1不需要竞争解决因为前导码是gNB专门分配给该UE的不会和其他UE冲突。代价是专用资源消耗大、管理复杂。在切换场景中目标gNB会在切换命令里携带专用前导码UE到目标小区后直接发这个码省掉Msg3/Msg4的往返能明显缩短切换中断时间。5G的切换中断目标一般要求做到几十毫秒以内CFRA是关键手段之一。实践中的坑是CFRA的专用前导码是一次性的如果UE发了Msg1但没收到Msg2这个前导码就作废了UE只能回退到CBRA重新来。从信令分析角度看如果切换时看到UE先是CFRA发起然后转入CBRA基本可以确认是目标小区的RACH资源紧张或者连续发送次数到达上限触发了回退。指导书在切换流程部分也提到了这一点排查时优先看目标小区的RACH配置尤其是专用前导码的分配数量是不是太少。还有一种情况是CFRA触发了但UE一直没发Msg1。这种现像常见于目标小区的SSB波束方向配置和UE的实际位置不匹配——UE扫描到的SSB波束质量不满足门限就不会在对应的PRACH资源上发前导码。这时候空口看起来就是切换命令下了、目标小区没反应最后源小区等超时触发RRC重建。排到这里要去看目标小区的波束覆盖而不是一直分析切换信令本身。3.3 RRC建立、拒绝与重发三类异常信令现象RRC连接建立是UE和gNB之间的握手包含三个子过程正常建立、RRC拒绝、RRC重发。指导书把三类现象分开讲每类都给了消息字段和排查方向。正常流程是UE发RRCSetupRequestgNB回RRCSetupUE再回RRCSetupComplete。RRCSetupRequest里最关键的是establishmentCause也就是UE告诉网络为什么建立连接。取值包括emergency、highPriorityAccess、mt-Access、mo-Signalling、mo-Data等。如果大量UE都用emergency发起接入说明终端侧或NAS层有异常这个指标在网管侧也能看到。RRCSetup里重点看radioBearerConfig和masterCellGroup配置这两个决定了UE后续的承载和MAC层行为尤其masterCellGroup里的schedulingRequestConfig配错了会导致UE连SR都发不出去。RRCSetupComplete里会携带NAS消息比如注册请求以及registeredAMF和selectedPLMN-Identity字段用于告诉网络UE选了哪个PLMN和AMF。RRC拒绝是gNB明确拒绝UE的建立请求。RRCReject消息里带一个waitTime参数单位秒告诉UE要等多久才能再次发起。实际中常见的原因是拥塞控制gNB的RRC连接数达到上限或者该UE被统一接入控制拦截。排查时先看拒绝消息里的waitTime和扩展拒绝原因再看gNB侧的负载指标。如果waitTime总是很大比如十几秒说明gNB长期处于拥塞状态这不是信令问题而是容量问题得从资源评估入手。RRC重发是另一类现象UE发了RRCSetupRequest但超时没收到RRCSetup于是重发请求。驱动RRC重发的是T300定时器如果T300超时且没有收到RRCSetup或RRCRejectUE就重发RRCSetupRequest。T300设置太短会频繁重发太长则接入延迟变大。标准里T300的范围是100ms到2000ms网优里一般建议在覆盖边缘场景放长一些避免接入还没完成就超时。排查思路分两步先看RRCSetupRequest有没有到达gNB如果到了但gNB没回RRCSetup问题在gNB的调度或下行覆盖如果gNB根本没收到问题在上行覆盖或PRACH配置。实际操作时可以用下面的命令统计# 统计 RRCSetupRequest 的 establishmentCause 分布和重复UE标识 tshark -r rrc.pcapng -Y rrc-nr.establishmentCause -T fields \ -e rrc-nr.establishmentCause -e rrc-nr.ue.identity | \ sort | uniq -c | sort -rn这条命令把每条RRCSetupRequest的establishmentCause和UE标识提取出来按出现次数排序。如果某个establishmentCause大量出现且UE标识重复基本可以坐实重发问题如果UE标识每次都不一样那可能是覆盖边缘大量新UE接入属于业务高峰的正常现象。重发率这个指标在网管里通常也有统计但不如直接看抓包来得直观尤其是定位到具体UE时。4. 上下文管理与会话管理从安全模式到PDU会话的信令链条4.1 初始上下文建立安全模式与UE能力查询的配合RRC建立完成后网络侧要做两件事激活安全模式和查询UE能力这两件事和初始上下文建立绑在一起。指导书把初始上下文建立过程拆成了NGAP消息和RRC消息两段来看。NGAP侧核心网下发Initial Context Setup Request里面携带UE安全能力、NAS消息、以及可选的PDU会话建立列表。gNB收到后如果消息里带了安全参数就先启动安全模式过程如果带了UE能力请求标志就发起UE能力查询。安全模式完成后gNB回Initial Context Setup Response把建立的DRB列表、QoS Flow状态回给核心网。这里有一个容易忽略的细节Initial Context Setup Request里如果带了PDU会话建立列表gNB会并行处理上下文建立和PDU会话建立而不是逐个等。所以抓包里会看到SecurityModeCommand、UECapabilityEnquiry、RRCReconfiguration几乎同时发下来这不是异常是正常的并行流程。安全模式过程是gNB下发SecurityModeCommandUE执行完整性保护和加密算法协商后回SecurityModeComplete。指导书里特别提醒如果UE回的是SecurityModeFailure多半是算法协商不一致比如gNB配置了UE不支持的加密算法。信令分析时还要同时看NAS层因为RRC安全模式建立在NAS鉴权成功的基础上NAS鉴权没过RRC安全模式也走不下去。实际中见过一种现像核心网侧配置了NEA0空加密但RAN侧没开导致UE和gNB算法列表对不上来回失败。UE能力查询是gNB通过UECapabilityEnquiry问UE支持什么UE回复UECapabilityInformation。正常流程下gNB在首次上下文建立时查询一次并缓存UE能力。但如果UE是从LTE切换过来的gNB可能没有缓存的能力信息就得重新查。UECapabilityInformation里的关键信元包括bandList支持的频段、supportedBandwidthList带宽组合、ca-BandwidthCombinationList载波聚合组合。网优在分析5G驻留问题时经常要核对UE上报的bandList是否覆盖了当前小区的SSB频点有些终端软件版本问题会导致bandList里漏报某些频段表现为这个频段下只有特定终端无法驻留。4.2 5G QoS架构QoS Flow到DRB的映射规则5G QoS架构和4G最大的区别是引入了QoS Flow的概念。指导书里把5G QoS架构拆成三层核心网侧QoS Flow、RAN侧DRB、空口侧承载。QoS Flow是PDU会话内服务质量的最小粒度一个或多个QoS Flow可以映射到一个DRB上由gNB决定映射关系。QoS参数是理解映射规则的关键指导书在4.1节给了一张QoS参数表核心参数整理如下这些参数在PDU会话建立、修改、切换准备时都会用到QoS参数作用典型值5QI标准化的QoS指标标识1语音、5IMS信令、8/9普通数据ARP分配和保留优先级1~15数值越小优先级越高GBR保证比特率GBR QoS Flow必须分配固定资源MBR最大比特率超出会被丢弃或降速PDB包延迟预算5QI1时PDB为100msPER包错误率5QI7时PER为10^-4QoS Flow到DRB的映射规则由gNB决定核心网通过NGAP消息把QoS Flow配置发给gNB。指导书强调了一个容易踩坑的点QoS Flow的GBR参数和DRB的实际调度参数不是一一对应的gNB需要结合空口资源情况决定是否接受这个QoS Flow。如果空口资源不够gNB会在PDU Session Resource Setup Response消息里带上Failed to Setup List把拒绝原因回给核心网。还有一类映射问题是同一个DRB下挂了多个QoS Flow但它们的5QI不同。比如一个DRB里既有QoS Flow 1语音又有QoS Flow 9普通数据这在调度上会导致DRB的PDCP层配置无法同时满足两者的PDB要求。指导书的建议是不同5QI类别的QoS Flow尽量映射到不同DRB除非网络允许一定程度的延迟提升。实际组网里运营商一般会把语音和视频单独建DRB普通数据走默认DRB避免调度冲突。4.3 PDU会话建立与修改NGAP和RRCReconfiguration的配合PDU会话建立是UE获得IP地址和数据承载的关键过程。整个流程涉及两条信令面N2接口的NGAP消息和空口的RRC消息指导书在4.2到4.4节把建立、修改、释放分别画了流程。N2侧核心网下发PDU Session Resource Setup Request携带PDU会话ID、QoS Flow列表、UP传输层信息——也就是gNB需要把用户面数据发往核心网的地址和TEID。gNB收到后做资源分配和DRB配置如果成功就回PDU Session Resource Setup Response响应里带上gNB侧分配的UP传输层地址和TEID。空口侧gNB通过RRCReconfiguration消息把PDU会话配置下发给UE里面带了PDU Session Configuration包括DRB配置、SDAP配置、QoS Flow到DRB的映射列表。UE配置完成后回RRCReconfigurationComplete。如果UE侧配置失败会回RRCReconfigurationFailuregNB再决定是重配还是释放这个PDU会话。实际排查中有一个高频问题PDU会话建立请求到了gNB但gNB一直不回响应。这种情况优先查UP传输层信息——如果核心网下发的UPF地址或TEID不对gNB无法建立用户面隧道就会卡在这里。用tshark可以这样提取关键字段# 查看 PDU Session Resource Setup Request 中的 QoS Flow 和 UPF 地址 tshark -r ngap.pcapng -Y ngap.pdu_session_resource_setup_request -V | \ grep -E QoS Flow|UPF|TEID|PDU Session ID|SNSSAI这条命令提取NGAP建立请求里的QoS Flow标识、UPF传输层地址、TEID、PDU会话ID和网络切片标识用来核对gNB侧收到的用户面参数是否与核心网配置一致。如果UPF地址段和实际核心网网段对不上说明核心网配置有误或者接口IP规划冲突。注意TEID在GTP-U协议里是32位标识如果配置成了16位也会导致用户面建不起来。PDU会话修改过程的排查思路类似。核心网下发PDU Session Resource Modify RequestgNB修改对应DRB参数后回Modify Response。如果修改涉及QoS Flow到DRB的映射变化gNB会再发一次RRCReconfigurationUE完成配置后上报Complete。修改过程最容易出错的是QoS Flow的5QI变化和DRB参数不匹配——比如原DRB是AM模式新加入的QoS Flow需要UM模式gNB需要新建DRB而不是复用旧的。这种问题在抓包里表现为RRCReconfiguration里同时出现了drb-ToAddMod和drb-ToRelease但UE侧实际上不支持某个PDCP配置组合。5. 寻呼与切换信令异常排查五个高频坑与解决步骤5.1 5GC寻呼与RAN寻呼触发条件与信令差异寻呼分两种5GC寻呼和RAN寻呼。指导书把两种流程都画了信令图差别很关键用错排查思路会浪费很多时间。5GC寻呼的典型场景是UE处于CM-IDLE状态有下行数据到达核心网通过NGAP PAGING消息通知gNBgNB再通过空口RRC PAGING消息找UE。NGAP PAGING里携带UE Identity5G-S-TMSI、TAI列表、以及可选的Paging DRX信息。gNB收到后在自己跟踪区范围内所有小区发RRC PAGING。RRC PAGING里的核心字段是pagingRecord列表每个记录包含5G-S-TMSI和pagingCause。RAN寻呼的场景是UE处于RRC_INACTIVE状态此时UE的上下文还保存在gNB。当下行数据到达时gNB直接在RAN通知区内发RRC PAGING不需要核心网介入。指导书里单独用5.2节讲RAN寻呼核心区别在于RAN寻呼的触发源是gNB而不是核心网寻呼范围是gNB管辖的RAN通知区而不是跟踪区。这个区别在排查寻呼不到UE的问题时非常关键如果UE在RRC_INACTIVE状态但gNB配置的RAN通知区不对UE就跑出寻呼范围了此时5GC寻呼也救不了因为核心网认为UE还在同一个gNB下面。5.2 切换类型对比站内、Xn、N2、LNR切换的边界指导书把切换分成四类站内切换gNB内部、Xn切换gNB间、N2切换通过核心网、LNR切换NR到LTE。边界条件不同排查思路也不同。站内切换不涉及Xn或N2接口由同一个gNB完成目标小区配置信令最简。Xn切换是gNB之间的直接切换需要Xn接口可用且两边的上下文能传输。N2切换走核心网适用于Xn不可用的场景信令路径变长中断时间也更长。LNR切换是从5G切到4G跨系统流程复杂RRC消息格式和QoS映射都要转换最容易出兼容性问题。实际组网里最常见的是Xn切换和LNR切换。Xn切换的失败排查先看Xn接口的Handover Request是否到达目标gNB再看目标gNB回复的是Ack还是Failure。如果Xn链路不通就要走N2切换兜底。LNR切换则要同时看5G侧和4G侧的RRC消息还要核对核心网下发的切换命令里是否携带了正确的LTE侧配置。LNR切换的QoS映射尤其容易出问题5G的QoS Flow映射到LTE的EPS Bearer时需要核心网提前做好5QI到QCI的映射表如果映射表缺项切换准备就会失败。5.3 常见问题排查五个反复出现的坑把实际信令分析中反复遇到的五类问题整理成现象-原因-解决的格式每条都是踩过的坑记下来能省不少时间。坑一寻呼消息发了但UE没响应现象核心网下发NGAP PAGING后空口也看到RRC PAGING但UE始终不回RRC Setup Request。原因最常见的是UE实际驻留的小区不在gNB下发寻呼的小区列表里或者UE处于非激活态但RAN寻呼范围配置错误。解决先核对NGAP PAGING里的TAI列表和gNB实际广播的TAI是否一致再查RRC PAGING里的寻呼记录是否携带了正确的5G-S-TMSI。抓两段数据N2接口看NGAP PAGING有没有到gNB空口看RRC PAGING有没有正确组帧。如果空口PAGING里携带的UE标识hash值和UE计算的对不上那UE根本不会响应这种问题在核心网和RAN侧使用不同寻呼参数配置时会出现。坑二切换准备失败Handover Request被目标gNB拒绝现象源gNB发Handover Request后目标gNB回了Handover Preparation Failure。原因目标gNB资源不足、UE能力信息不匹配、或者目标小区的加密算法配置与源侧不一致。解决看Handover Preparation Failure里的Cause值。如果是Radio Network Layer Cause优先查目标小区的空口资源比如目标小区是否处于拥塞或者被 barred如果是Protocol Cause查参数配置重点对比源和目标小区的加密算法列表和UE能力。指导书在切换章节后面列了常见Cause值的对照表排查时直接翻比翻协议快。坑三RRCReconfiguration下发后UE一直不回Complete现象gNB发了RRCReconfiguration但空口迟迟等不到RRCReconfigurationComplete。原因大概率是RRCReconfiguration里的配置UE不支持比如某个DRB的QoS参数超出UE能力或者PDCP配置里的discardTimer设置不合理。UE实际上会回RRCReconfigurationFailure但这条消息在抓包里容易漏看因为失败消息和正常消息在同一个逻辑信道上过滤条件写窄了就丢了。解决把抓包里所有RRCReconfigurationFailure都提出来比对failureCause。如果没抓到Failure再查下行覆盖可能是RRCReconfiguration重传也丢了。实际操作时可以按RRCSetupComplete里填的UE标识过滤把该UE后续的所有DL-DCCH消息都拉出来看。坑四PDU会话建立后业务还是不通现象PDU会话建立成功QoS Flow也映射到DRB了但用户面数据ping不通。原因常见的是UPF地址和TEID配置错误或者SDAP层把QoS Flow映射到了错误的DRB上。解决先核对NGAP Setup Response里的UPF传输层地址和TEID再检查RRCReconfiguration里的SDAP配置重点看QoS Flow to DRB mapping表。指导书里的QoS映射表模板照填一遍基本能定位出是核心网参数还是RAN侧映射的问题。有一种隐蔽情况是gNB侧为同一个PDU会话分配了多个DRB但SDAP层配置里QoS Flow ID到DRB ID的映射表和NGAP侧下发的不一致导致数据被发到错误DRB上空口侧完全看不出来只能对比两边的映射表。坑五去注册流程异常导致UE状态不一致现象UE发起去注册但核心网没回Deregistration Accept或者回的是网络发起的去注册。原因NAS层去注册请求里的deregistrationType和accessType配置不对或者UE在去注册过程中又触发了新的业务请求导致状态机冲突。解决看NAS去注册请求里的deregistrationType和5GMM Cause值。如果是UE发起的正常去注册核心网必须回Accept如果回Reject拿Reject里的5GMM Cause值对照NAS层规范表排查重点看是不是重复注册导致老上下文被顶掉。还有一种情况是UE同时发起去注册和PDU会话释放核心网处理顺序不对导致会话状态残留后面再注册时会话建立失败。6. 信令分析五步法从抓包到定位的实操习惯信令分析不是拿到pcap就一通乱翻。我自己的习惯是固定走五步每一步都有明确产出这样不管多复杂的信令问题都能在半小时内找到方向。第一步按接口拆解抓包。N2接口看NGAP空口看RRCUE侧看NAS。三个接口分开过滤后先确认每一段的关键信令都出现了。比如注册流程里NGAP的Initial UE Message、RRC的RRCSetupComplete、NAS的Registration Request必须三连出现。缺了哪一段问题就在哪个接口这一步能把问题范围缩小到单接口。第二步拉通时间线。把同一个UE的所有信令按时间排序标注每个时间点的事件。这一步我会用tshark把单个UE的信令先过滤出来# 按 5G-S-TMSI 过滤单个 UE 的全流程信令按时间排序输出 tshark -r full.pcapng -Y ngap || rrc-nr || nas-5gs -T fields \ -e frame.time_epoch -e frame.protocols -e ngap.procedureCode \ -e rrc-nr.dl.dcch.message -e nas-5gs.mm.type | \ grep 5g-stmsi | head -50这条命令把NGAP、RRC、NAS三类消息按时间戳拉出来grep出和指定5G-S-TMSI相关的记录然后就能直观看到UE的完整信令轨迹。参数grep 5g-stmsi里填的是实际抓包里看到的TMSI值如果第一次抓包没看到可以先用ngap.paging_identity或者rrc-nr.pagingrecord里的字段反查。第三步对照指导书里的标准信令流程图找差异。差异不等于故障但每个差异都要能解释。比如标准注册流程里注册成功后应该有Initial Context Setup Request如果没看到说明网络侧没有成功建立UE上下文回去查AMF侧的UE上下文创建是否成功。这一步需要把指导书对应章节的流程图翻开一条消息一条消息地比。第四步查关键字段。注册流程看NAS的5GMM Cause上下文建立看NGAP Cause切换看Handover Preparation Failure的Cause。指导书后面已经把这些原因值列了对照表直接翻对应章节就能找到含义和常见处理方式。查字段时要注意Cause值只是结果不是原因比如PDU会话建立失败报Radio Network Layer Cause还得继续看是资源不足还是切片不支持。第五步写分析结论。结论要包含三部分现象是什么、原因是什么、建议怎么改。网优工程师最怕的就是只报现象不报原因写清楚这三部分研发侧才能快速处理也能减少来回确认的时间。写结论时附上关键信令的截图和抓包时间点方便后续复现验证。这套五步法我用了一段时间每处理一个信令问题都会回看指导书的对应章节确认自己的排查路径有没有漏掉某一环。从那以后每次拿到新的信令抓包我都强制先走一遍这个流程不再一上来就翻包找异常。五步走完问题基本能定位到具体接口和具体消息希望帮到你。本文还有配套的精品资源点击获取