简介：在移动网络优化中，KPI指标正常并不代表用户体验良好，信令才是定位问题的原始现场。5G信令分析是网优工程师必须掌握的关键技能，围绕RRC建立、NAS注册、切换流程和QoS承载等核心环节，通过信令跟踪、pcap抓包和字段判读，可以精准定位接入失败、切换异常、速率受限等隐性问题。本文从一张KPI全绿却连不上网的投诉工单出发，系统梳理5G信令分析的框架、取数路径与判读逻辑，并结合工程实践中的避坑经验，帮助工程师快速建立从信令时间线到因果链的分析能力，高效支撑投诉处理与网络优化落地。

1. 5G信令分析指导书：从一张KPI全绿却连不上网的投诉工单说起

半夜两点，某个地市转来一张投诉工单，说有片区域的5G手机经常断连，刷视频一直转圈。我先打开网管KPI看了一眼：RRC建立成功率99.1%，切换成功率98.7%，全是绿的。可用户的问题真实存在，指标却看不出任何异常。最后把按IMSI过滤的UE级信令拖出来，才发现每次断连都发生在RRCSetupComplete之后的NAS注册阶段，核心网回了一条Registration reject，5GMM cause #7。无线侧再漂亮，问题也出在签约数据上。KPI是均值，信令才是单用户、单流程的原始现场。这篇指导书把5G信令分析的框架、取数路径、字段判读和常见坑一次讲清，适合网优、核心网、投诉处理和测试验证的工程师照着落地。

2. 5G信令分析先立框架：四条主线流程与两条判读主线

2.1 接入流程：RRC建立与NAS注册的两段式判读

做5G信令分析，第一步不是打开抓包工具，而是在脑子里先立起一条时间线。接入流程看起来长，实际可以切成两段：RRC建立段和NAS注册段。RRC段跑在UE和gNB之间，消息在空口Uu口上；NAS段跑在UE和核心网AMF之间，但NAS消息本身是封装在RRC消息里透传的。也就是说，你抓一条空口日志，既能看见RRCSetupRequest，也能看见Registration Request，只是后者被塞在RRCSetupComplete的dedicatedInfoNASList字段里。很多新手对着日志一脸懵，就是没搞懂这条包含关系。

RRC段的标准链是：UE发RRCSetupRequest，gNB回RRCSetup，UE再回RRCSetupComplete。到这一步，无线接入就算成功了。真正的注册流程从NG口才开始：gNB收到RRCSetupComplete后，从里面把NAS消息取出来，包装成NGAP的InitialUEMessage发给AMF。AMF随后走鉴权、身份识别，最后回Registration Accept。判读原则很简单：RRC段失败，责任在无线侧；RRC段成功、但AMF迟迟不回NAS响应或者直接回Reject，责任大概率在核心网。

实操里需要盯几个字段。RRCSetupRequest里的establishmentCause，取值一般是emergency、mt-Access、mo-Signalling、mo-Data几种，能帮你判断这批终端是主动呼叫还是被叫触发。InitialUEMessage里的RANUE NGAP ID是gNB侧给这条UE上下文分配的临时标识，后面所有NG口消息都靠它关联。Registration Accept里的5G-GUTI、TAI list和s-NSSAI则决定了终端后续驻留和切片接入的合法性。有一个常见误用：一看到RRCSetupComplete里有NAS消息就以为是核心网故障，其实RRC阶段建立失败和NAS注册失败要分开看，别混在一起下结论。

2.2 切换流程：MR上报、RRC重配与Xn转发三张脸

切换的信令链比接入长，但只要盯住三张脸：UE上报测量、网络下发重配、Xn口目标小区准备资源。完整流程里，UE先发MeasurementReport，携带A3事件的测量结果，包含服务小区和目标邻区的RSRP、RSRQ、SINR，以及目标小区的物理小区标识PCI和频点信息。源gNB收到后决定切换，就向目标gNB发Xn Handover Request；目标小区准备好资源后回Xn Handover Response，源gNB再向UE下发RRCReconfiguration，把目标小区的随机接入配置和DRB配置一并带下去。

UE收到RRCReconfiguration后，要在目标小区做随机接入，发前导码、收随机接入响应RAR，然后回RRCReconfigurationComplete。这时候目标gNB才会向源gNB发Xn Handover Success，整个切换才算闭环。判读的重点有两个：一是看切换是正常触发还是异常触发，二是看失败发生在准备阶段还是执行阶段。准备阶段失败，要看Xn口的Handover Preparation Failure消息里的CauseRadioNetwork；执行阶段失败，通常表现为UE在目标小区随机接入失败，重发前导码直到RLF。

把Uu口和Xn口的消息对应起来看会更清楚。下面这张表是我做切换分析时常用的对照关系：

很多人一看到切换失败就写「邻区漏配」，这是最偷懒的结论。邻区漏配的表现是UE根本不报目标小区，因为测量配置里没有那个频点和PCI；而信令里已经出现目标小区PCI和MeasurementReport，就说明邻区关系是存在的，这时候要去查目标小区的资源、干扰和随机接入配置。判断方向错了，后面所有优化动作都会跑偏。

2.3 承载与QoS流程：PDU Session、QoS Flow与DRB的三角关系

速率类投诉在5G里占了很大比例，但很多人不会看承载相关的信令。5G的会话建立分三层：NAS层的PDU Session Establishment流程负责和核心网协商QoS参数；RRC层的RRCReconfiguration负责在空口建立DRB数据无线承载；调度层的CQI、MCS、BLER负责真正的空口传输效率。三层缺一不可，只盯一层必然误判。

NAS层要看PDU Session Establishment Accept里的5QI、Session-Aggregate-Maximum-Bitrate和默认QoS Flow信息。这里尤其注意Session-AMBR，它直接决定了这条会话的签约限速。如果Accept里给的AMBR就是10Mbps，那用户投诉速率上不去就别怪无线侧，签约就限死了。RRC层要看RRCReconfiguration里的drb-ToAddModList，里面有DRB ID、RLC模式（AM还是UM）、逻辑信道优先级映射。如果NAS层QoS Flow建立成功、但RRC迟迟不下发DRB配置，问题多半出在gNB的资源分配上。

判读顺序我一般固定为：先看QoS Flow有没有建成功，再看DRB有没有配上，最后看空口调度参数的反馈。很多实际案例里，QoS和DRB都正常，用户还是觉得慢，最后查CQI上报，发现终端上报的CQI长期徘徊在4到6，MCS也被迫压低，吞吐率自然上不去。这种情况信令看起来一切正常，但问题确实在无线环境或干扰，需要回到覆盖和干扰层面去查。所以信号分析不只能看「通不通」，还要能看「快不快」。

3. 把信令拿到桌面上：三种取数路径与最小可用命令

3.1 网管侧信令跟踪：低峰期做一次UE级跟踪

最常见的取数路径是网管跟踪。我一般会进某主流厂家的网管系统，找到「信令跟踪管理」模块，按小区或按UE粒度发起跟踪。菜单名字各家叫法不同，有叫「信令追踪」的，有叫「LTE/NR Trace」的，但逻辑都是一样的：选定接口、选定过滤对象、设定跟踪时长、启动后导出pcap或解码文本。建议过滤对象直接填IMSI或5G-GUTI，只跟踪那一两个投诉用户，不要全小区跟踪。

全小区跟踪的代价在5G网元上比4G更明显，gNB要同时处理用户面数据和信令面解码，CPU很容易被打满，反过头来影响网络指标。跟踪时长也别贪，15到20分钟足够覆盖几轮注册、切换和释放流程了。导出时有个选项容易被忽略：导出格式选「原始信令pcap」而不是「事件摘要」。摘要里只有流程级结果，看不到原始IE，遇到cause值缺省的情况很难继续往下查。有同事吃过这个亏，后文避坑部分会专门说。

网管侧跟踪参数我常用这套，直接照着填就好：

3.2 用抓包工具过滤出三类信令消息

如果拿到的已经是pcap，后面的分析基本都在抓包分析工具里完成。5G信令在pcap里是以协议分层的形式存在的，空口的RRC消息、UE和AMF之间的NAS消息、NG接口的NGAP消息、Xn接口的XNAP消息，分别挂在不同的协议树上。直接用工具打开整个包，帧数动辄上万，必须用显示过滤器先收窄范围。

我常用的显示过滤器就这几个，简单但够用：

rrc.nr // 5G空口RRC消息，看RRC建立、重配和释放 nas-5gs // 5G NAS消息，看注册接受/拒绝、PDU会话建立 ngap // NG接口NGAP消息，看gNB与AMF之间的交互 xnap // Xn接口切换消息，看切换准备与执行

如果文件很大，可以用命令行工具快速验证文件里到底有没有目标信令，避免在图形界面里等半天。比如用tshark统计NGAP消息数量：

# 统计ngap.pcap里NGAP消息的总帧数 tshark -r ngap.pcap -Y "ngap" -T fields -e frame.time_epoch | wc -l

这个命令只做一件事：把pcap里所有NGAP消息的帧时间戳打出来，再用wc统计行数。行数接近0，说明抓包时NG口没抓到目标用户的数据，要回头检查过滤条件或抓包位置。参数里的-Y是显示过滤器，-T fields指定只输出字段，-e frame.time_epoch取的是帧的绝对时间戳，后面排序需求直接在这些数字上做就行。

3.3 写个Python小脚本：从pcap里抽出信令时间线

图形界面适合单帧深挖，不适合看全貌。我一般会写一个Python脚本，把pcap里某个用户的所有信令按时间顺序拉成一张表，几十秒就能看清整个流程的顺序对不对。脚本本身不复杂，核心就是读取pcap、按显示过滤器筛选、把帧时间戳和协议名打出来。

#!/usr/bin/env python3 # filter_signaling_timeline.py # 依赖: pip install pyshark（需要本机装有tshark） import pyshark PCAP = "ngap.pcap" # 网管导出的NG接口pcap文件 FILTER = "ngap || nas-5gs" # 只保留NGAP与NAS消息 cap = pyshark.FileCapture(PCAP, display_filter=FILTER) rows = [] for i, pkt in enumerate(cap): t = float(pkt.frame_info.time_epoch) # 帧绝对时间戳 proto = pkt.highest_layer # 该帧最高层协议名 rows.append((t, proto, i)) cap.close() # 按时间排序后打印前50帧 for t, proto, idx in sorted(rows)[:50]: print(f"{idx:>5} {t:>12.3f} {proto}")

这段脚本有两个关键点。一是display_filter只保留NGAP和NAS两类消息，把海量的用户面GTP-U包直接挡在门外，否则全量pcap里能刷出几万帧GTP-U数据，时间线完全没法看。二是用frame_info.time_epoch取绝对时间，这样不同接口的多个pcap后续也能按同一时间轴对齐。想按用户过滤，只要在FILTER里加一条字段条件，比如按GUTI或IMSI过滤，脚本不用改结构。

脚本的价值在于把「人肉翻包」变成「自动拉时间线」。跑完一眼就能看出某个用户从注册到会话建立的顺序是否正常：是先有Registration Accept、还是先有PDU Session Establish，时间间隔是毫秒级还是秒级。如果中间有一段长时间空白，那段时间大概率就是网络侧卡住或信令丢失的区间，再回到图形界面里针对那几百毫秒细查。

4. 从信令字段到问题定位：三类指标背后的判读逻辑

4.1 RRC建立失败定位：先看establishmentCause，再看失败阶段

RRC建立成功率是网络指标里最常看的，但它只能告诉你"成功还是失败"，给不了失败原因。定位RRC建立失败，要按失败阶段拆开看。最常见的一个操作是，从网管导出的文本日志里统计establishmentCause的分布：

# 统计RRCSetupRequest里的establishmentCause分布，确认终端行为 grep -oP 'establishmentCause[^,}]+' rrc_log.txt | sort | uniq -c

这条命令用grep把日志里所有establishmentCause字段连同取值一起抠出来，sort加uniq -c统计每一种取值的数量。输出会像120 mo-Data、5 mo-Signalling这样。如果绝大多数终端都是mo-Data，说明这批接入是用户主动发起的流量请求；如果有大量mt-Access，就要怀疑是不是被叫场景下寻呼响应出了问题。结合失败阶段，能快速圈定排查方向。

我把RRC建立失败拆成三个位置，判读起来非常直接：

• 当gNB根本没收到RRCSetupRequest，先查覆盖盲区、上行干扰，再看SIB1里的接入禁止参数ac-Barring是否配置异常，导致终端连请求都不发。
• 当gNB回了RRCSetup、但UE没回RRCSetupComplete，优先怀疑下行覆盖差、下行干扰强，或UE被调度到了极低的MCS，解不出RRCSetup这条消息。
• 当RRCSetupComplete正常回传、但后续NAS注册失败，问题已经不在RRC层，去查核心网返回的Registration reject cause，别在无线侧继续耗。

另外一个细节，RRCSetupRequest里的InitialUEIdentity有两种形态：有5G-S-TMSI时带的是ng-5G-S-TMSI，没有有效标识时终端会带一个randomValue。如果某个终端长期用randomValue上报，说明它一直拿不到或丢失了有效临时标识，常见于终端频繁重启、长时间待机或者从异系统返回后。这种问题信令上看不出RRC失败，但确实会影响接入效率。

4.2 切换失败定位：MeasurementReport里看三组量，Xn消息里看失败阶段

切换失败是投诉处理里最磨人的一类，因为涉及源基站、目标基站和UE三方，任何一个环节出错，表象都是切换失败。我的做法是先回退到MeasurementReport，看上报内容里三组关键量：服务小区的RSRP和SINR、目标小区的PCI和频点、邻区测量结果与当前服务小区的差值。这三组量能回答第一个问题：切换是谁触发的，触发合理不合理。

如果服务小区RSRP还有-85dBm，SINR也不错，但UE报了一个邻区并触发A3，那可能是邻区优先级配置太高或者迟滞参数太小，属于参数层面的误切换。反过来，如果服务小区RSRP已经跌到-110dBm以下，邻区也弱，切换自然容易失败，这时候怪参数没有意义。这里面最容易翻车的是只看RSRP不看SINR：RSRP不差但SINR差，往往是有同频干扰，切换成功也不代表用户体验会好。

切换失败的信令判读按阶段分，我用这张表做了个速查：

在某个专项优化里，某项目的切换失败指标连续一周超标，一开始团队判断是邻区漏配，结果加了二十多条邻区关系一点用没有。后来把目标小区的信令拉出来，发现每次失败都发生在随机接入环节，UE发了前导码但一直收不到RAR，最后定位到目标小区存在持续上行干扰，PRACH解调不过关。这个案例说明，信令的失败阶段比失败结果更重要，先定位在哪一步、再分析为什么，别一上来就改配置。

4.3 QoS与速率问题定位：从PDU建立信令到调度参数的逐层对照

速率投诉的定位逻辑和接入、切换都不一样，它要跨三层看。很多工程师查速率慢，第一反应是测速软件问题，或者盯着一两个ping包看时延，这都不系统。我一般按三层对照法来查：先看NAS层的PDU Session Establishment Accept，再看RRC层的DRB配置，最后看空口调度反馈。

第一层看的是这条会话被授权的速率上限。PDU Session Establishment Accept里有一个关键字段Session-Aggregate-Maximum-Bitrate，也就是所谓的会话AMBR。如果这个值本身就很小，比如10Mbps，那用户再怎么投诉，实际速率也不可能突破这个上限，这是核心网签约侧的问题，无线侧不用背锅。第二层看DRB配置，确认RRCReconfiguration里下发了几个DRB，QoS Flow到DRB的映射是否正确，逻辑信道的优先级是不是把这条承载放在了不该放的位置。

第三层才轮到空口调度。QoS建立成功、DRB配置也对，但速率就是上不去，这时候要看CQI上报、MCS分配和BLER三条曲线。一个典型的矛盾现场是：CQI上报15，但MCS长期稳在低位。这说明终端反馈的信道质量很好，但基站调度器没有按对应的MCS去调度，问题反而在基站侧调度算法或干扰抑制配置上。如果CQI本身就低，MCS低就是正常的，问题回到覆盖和干扰。速率问题别只看平均吞吐，要看MCS分布和BLER拐点，才能分清楚是无线环境差、调度配置错，还是核心网限速。

5. 信令分析避坑实录：五条踩坑记录

5.1 时间戳没对齐，关联全乱

现象：核心网侧信令显示某UE在10:03:15完成了注册，但路测日志里同一时刻连RRCSetupRequest都还没发。原因是网管服务器和路测电脑的时间没有对齐，两边差了将近两分钟。解决方案：分析前先确认系统时区一致，最好统一用UTC或同一时区的本地时间；再用一个明显的事件做基准对齐，比如找一次TA更新或Ping包，把两条时间线的偏移量算出来，之后所有关联都按偏移量校正后再看。吃了一次亏之后，我在每次分析开头都加一步时间校准，不做这一步不看任何信令关系。

5.2 只拿事件摘要，丢了cause值

现象：某次分析用网管导出的「事件列表」定位注册失败，里面只写了Registration reject，没有具体cause值，整个团队按「核心网拒签」排查了半天，最后才发现是切片s-NSSAI不匹配。原因是导出时选了摘要格式，NAS层原始IE被聚合掉了。解决方案：导出时一定要选pcap或带完整IE的文本格式，拒绝也要看到5GMM cause值才能下结论。从那以后，我要求任何信令导出必须包含原始IE，摘要只能用来圈流程，不能用来判因果。

5.3 把正常释放当成掉话

现象：某项目投诉处理里，有人把一条RRC连接释放当成掉话上报，指标被污染了两天。原因是只看流程「从建立到释放」就认为异常，没有看释放原因值。解决方法是：RRC释放要核对ReleaseCause，如果是normal-release或者网络侧主动释放，而且前面有完整的业务结束信令，比如VoNR通话挂断，这就是正常流程。区分掉话和正常释放，看最后一个流程节点是「业务完成后的释放」还是「业务进行中的异常断开」，这一点在投诉回访话术里也很重要，别让正常挂机变成网络问题。

5.4 切换失败全赖邻区漏配，实际是目标小区随机接入问题

现象：某区域的A3切换频繁失败，大量投诉指向「切换不上网」。第一轮排查写的是邻区漏配，加邻区后指标无变化。原因是团队只看切换失败这个结果，没看失败阶段。解决方案：把信令拉到随机接入过程，发现UE在目标小区反复发前导码、收不到RAR，进一步查目标小区上行干扰，是外部干扰源导致PRACH解调失败。这条经验直接改变了团队的分析习惯：切换失败先分阶段，再定责任，信令里明明有阶段痕迹，不要用猜的。

5.5 全小区信令跟踪影响业务感知

现象：某次为了抓一个偶发问题，开了全小区信令跟踪，跟踪期间用户反映更卡了，投诉反而增多。原因是跟踪范围过大，gNB的信令处理负载飙升，调度时延变大，业务感知劣化。解决方案：跟踪只针对目标UE，用IMSI或GUTI精确过滤；确需全小区跟踪时选择凌晨低峰期，并限定15分钟内的时长；跟踪结束后立即对比跟踪前后的KPI，确认没有遗留影响。信令分析是为了定位问题，不能为了定位制造新的问题。

6. 信令分析进阶技巧：把NAS与RRC串成一条因果链

分析信令跟分析故障一样，最忌只盯单点。我现在养成的习惯是：拿到一条完整流程后，给每一帧打三个标签——阶段标签、方向标签、关键字段标签。阶段标签表示它属于注册、鉴权、会话建立、切换还是释放；方向标签表示上行、下行还是网元间内部消息；关键字段标签记下那帧里最值得注意的cause值、PCI、QoS参数。打标之后按时间线展开，一帧一帧回放用户从开机到投诉发生的那几分钟，绝大多数问题都能在因果链上找到断层。

做这个打标处理时，我常用一张映射表辅助判读：

有一次，某用户投诉频繁掉线，很多人盯着RRC重建立失败看，反复优化覆盖和切换参数，问题依旧。我把NAS和RRC串起来后才发现一个规律：每次RRC重建立失败之前，都会先出现一轮TA更新失败，核心网侧返回的cause指向终端在注册区边缘反复横跳。真正的触发点是TA边界配置与小区覆盖不匹配，而不是无线链路本身。这让我把分析习惯彻底改成链式思维——不看到前因，不下结论。

做信令分析这几年，最大的教训就是：单条消息只能告诉你「发生了什么」，只有一串消息才能告诉你「为什么会发生」。不管手头是网管跟踪还是路测日志，先拉时间线、再打标签、最后做因果关联，这套流程比任何复杂的分析工具都可靠。希望这篇指导书能帮你少走几步弯路，也欢迎你在自己的项目里把这套方法跑一遍，用真实数据去验证它。

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