简介在移动网络优化中KPI指标正常并不代表用户体验良好信令才是定位问题的原始现场。5G信令分析是网优工程师必须掌握的关键技能围绕RRC建立、NAS注册、切换流程和QoS承载等核心环节通过信令跟踪、pcap抓包和字段判读可以精准定位接入失败、切换异常、速率受限等隐性问题。本文从一张KPI全绿却连不上网的投诉工单出发系统梳理5G信令分析的框架、取数路径与判读逻辑并结合工程实践中的避坑经验帮助工程师快速建立从信令时间线到因果链的分析能力高效支撑投诉处理与网络优化落地。1. 5G信令分析指导书从一张KPI全绿却连不上网的投诉工单说起半夜两点某个地市转来一张投诉工单说有片区域的5G手机经常断连刷视频一直转圈。我先打开网管KPI看了一眼RRC建立成功率99.1%切换成功率98.7%全是绿的。可用户的问题真实存在指标却看不出任何异常。最后把按IMSI过滤的UE级信令拖出来才发现每次断连都发生在RRCSetupComplete之后的NAS注册阶段核心网回了一条Registration reject5GMM 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发RRCSetupRequestgNB回RRCSetupUE再回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口的消息对应起来看会更清楚。下面这张表是我做切换分析时常用的对照关系流程阶段Uu口消息Xn/NG口消息关键字段切换准备MeasurementReportHandover Required / Request / ResponsemeasResult、physCellId、cause切换执行RRCReconfiguration、随机接入前导码Handover Request Acknowledgera-PreambleIndex、rach-Config切换完成RRCReconfigurationCompleteHandover Successc-RNTI、lastVisitedCell很多人一看到切换失败就写「邻区漏配」这是最偷懒的结论。邻区漏配的表现是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到6MCS也被迫压低吞吐率自然上不去。这种情况信令看起来一切正常但问题确实在无线环境或干扰需要回到覆盖和干扰层面去查。所以信号分析不只能看「通不通」还要能看「快不快」。3. 把信令拿到桌面上三种取数路径与最小可用命令3.1 网管侧信令跟踪低峰期做一次UE级跟踪最常见的取数路径是网管跟踪。我一般会进某主流厂家的网管系统找到「信令跟踪管理」模块按小区或按UE粒度发起跟踪。菜单名字各家叫法不同有叫「信令追踪」的有叫「LTE/NR Trace」的但逻辑都是一样的选定接口、选定过滤对象、设定跟踪时长、启动后导出pcap或解码文本。建议过滤对象直接填IMSI或5G-GUTI只跟踪那一两个投诉用户不要全小区跟踪。全小区跟踪的代价在5G网元上比4G更明显gNB要同时处理用户面数据和信令面解码CPU很容易被打满反过头来影响网络指标。跟踪时长也别贪15到20分钟足够覆盖几轮注册、切换和释放流程了。导出时有个选项容易被忽略导出格式选「原始信令pcap」而不是「事件摘要」。摘要里只有流程级结果看不到原始IE遇到cause值缺省的情况很难继续往下查。有同事吃过这个亏后文避坑部分会专门说。网管侧跟踪参数我常用这套直接照着填就好参数项建议值备注跟踪对象IMSI或5G-GUTI精确到单个用户跟踪接口Uu NG Xn能覆盖无线与核心网两侧跟踪时长15分钟覆盖完整注册和切换周期导出格式pcap含原始IE不要选事件摘要执行时段凌晨或低峰期降低对gNB的影响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_filterFILTER) 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还有-85dBmSINR也不错但UE报了一个邻区并触发A3那可能是邻区优先级配置太高或者迟滞参数太小属于参数层面的误切换。反过来如果服务小区RSRP已经跌到-110dBm以下邻区也弱切换自然容易失败这时候怪参数没有意义。这里面最容易翻车的是只看RSRP不看SINRRSRP不差但SINR差往往是有同频干扰切换成功也不代表用户体验会好。切换失败的信令判读按阶段分我用这张表做了个速查失败阶段看哪个信令常见原因准备阶段失败Xn口Handover Preparation Failure目标小区资源不足、causeRadioNetwork报错执行阶段失败UE侧随机接入过程ra-Problem、目标小区PRACH配置异常、上行干扰完成阶段失败RRCReconfigurationComplete是否回传下行重配消息丢失、UE侧解码失败在某个专项优化里某项目的切换失败指标连续一周超标一开始团队判断是邻区漏配结果加了二十多条邻区关系一点用没有。后来把目标小区的信令拉出来发现每次失败都发生在随机接入环节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里下发了几个DRBQoS 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参数。打标之后按时间线展开一帧一帧回放用户从开机到投诉发生的那几分钟绝大多数问题都能在因果链上找到断层。做这个打标处理时我常用一张映射表辅助判读阶段标记典型信令关注字段接入RRCSetupRequest / RRCSetupCompleteestablishmentCause、InitialUEIdentity注册Registration Request / Accept5GMM cause、5G-GUTI、s-NSSAI会话PDU Session Establishment Accept5QI、Session-AMBR切换MeasurementReport / RRCReconfigurationRSRP、SINR、PCI、causeRadioNetwork释放RRC Connection ReleaseReleaseCause、lastVisitedCell有一次某用户投诉频繁掉线很多人盯着RRC重建立失败看反复优化覆盖和切换参数问题依旧。我把NAS和RRC串起来后才发现一个规律每次RRC重建立失败之前都会先出现一轮TA更新失败核心网侧返回的cause指向终端在注册区边缘反复横跳。真正的触发点是TA边界配置与小区覆盖不匹配而不是无线链路本身。这让我把分析习惯彻底改成链式思维——不看到前因不下结论。做信令分析这几年最大的教训就是单条消息只能告诉你「发生了什么」只有一串消息才能告诉你「为什么会发生」。不管手头是网管跟踪还是路测日志先拉时间线、再打标签、最后做因果关联这套流程比任何复杂的分析工具都可靠。希望这篇指导书能帮你少走几步弯路也欢迎你在自己的项目里把这套方法跑一遍用真实数据去验证它。本文还有配套的精品资源点击获取