简介这份5G信令分析指导书以docx文档形式整理面向5G网络优化工程师、通信专业学生及从事信令排查的一线网优人员。内容按开机入网、上下文管理、会话管理、寻呼流程、切换流程、NAS流程六大模块展开系统覆盖小区搜索与选择、系统消息广播、随机接入、RRC连接建立、注册流程、PDU会话建立/修改/释放、5GC与RAN寻呼、站内/Xn/N2/LNR切换及重定向、终端与网络发起的去注册、主被叫业务请求等关键过程并深入解读MIB、SIB1、SI等关键系统消息对理解5G端到端信令流程与常见异常定位有直接帮助。资源包共1个docx文件大小4.24MB内容组织有清晰目录层级适合作为日常查询手册或系统学习资料。已有60人学习下载。1. 5G信令分析到底分析什么一个入网失败场景带出完整链路某次外场测试前台报“终端能收到SSB和SIB1但注册始终失败”后台指标一片正常NR覆盖曲线也看不出问题。我把gNB侧抓包打开发现UE发完RRCSetupComplete之后就再没有上行信令再对N2接口的抓包gNB发出的InitialUEMessage根本没到AMF——问题出在SCTP偶联上而不是空口或核心网业务逻辑。这就是5G信令分析典型的一天从空口RRC、到N1的NAS、再到N2的NGAP一层层把“信令走到哪一步断了”找出来。这篇指导书就是给无线网优、核心网运维和协议测试同学的一份可复现作业方法分接口、抓包、跑流程、看cause、避坑。跟着章节走新手能独立定位大部分5G入网和会话建立问题熟手也能在这里对齐一套排查顺序少翻车。2. N1/N2/N3接口的信令分工先分层再抓包避免白抓一场2.1 四层信令各管一段RRC、NAS、NGAP、GTP-U的职责边界5G信令和4G最大的区别是控制面被拆得更散。以UE从开机到能上网为例信令至少要经过三个物理接口空口UE到gNB、N2gNB到AMF、N3gNB到UPF。空口上跑的是RRC和NASRRC管小区接入、测量控制、DRB承载配置NAS5GMM/5GSM是UE与AMF之间的“会话层”信令管注册、鉴权、身份、PDU会话。RRC在UE和gNB之间NAS看着是UE和AMF之间但在空口上NAS是被包在RRC消息的DedicatedNAS-Message字段里透传的。也就是说空口抓包能看到NAS的明文内容但这段NAS同时也会被gNB原封不动地封装进N2消息再送往AMF。这里有个新手最容易懵的点N1接口其实没有独立物理口。NAS消息在空口被RRC承载在N2被NGAP的NAS-PDU字段承载所以同一份NAS内容会在RRC消息和NGAP消息里各出现一次这不是重复而是同一信令在不同协议层的两次封装。分析时我习惯这样区分RRC里的那份是UE视角的“发射记录”NGAP里那份是网络视角的“接收记录”两者时间差就是空口上行和gNB处理时延。N2接口跑的是NGAP底层是SCTP协议承载在gNB与AMF之间的IP链路上。NGAP的消息类型很多InitialUEMessage、Uplink/DownlinkNASTransport、InitialContextSetup、PDUSessionResourceSetup、UEContextRelease等。N2上大量消息的作用就是“UE和AMF之间的NAS消息搬运工”加“gNB上下文管理”。N3接口是用户面跑GTP-U严格说不是信令面但PDU会话建立成功与否要看N2上交换的TEID能不能和N3上的真实流量对上所以做信令分析时N3的GTP-U数据也要一起抓。下表把这四类信令的边界列清楚信令层级所处接口底层承载主要消息信令分析意图RRC空口UE-gNB无线RRCSetupRequest/Setup/Reconfiguration看接入、DRB配置、测量NASUE-AMF空口N2透传RRC容器/NAS-PDU字段Registration Request/PDU Session Establishment看注册、鉴权、会话请求NGAPN2gNB-AMFSCTPInitialUEMessage、PDUSessionResourceSetup看NG-RAN上下文与承载建立GTP-UN3gNB-UPFUDP/IPGTP-U DataTEID标识核验用户面隧道与流量提示实战里先看空口消息拿UE侧结论再看N2消息拿网络侧结论。空口失败通常有明确cause值N2失败多是上下文配置问题两者分开看不容易混淆。2.2 从抓包文件里快速分出接口端口、协议与IP段识别拿到一个陌生人给的pcap先别急着点开看。我习惯第一件事是跑协议层级统计花十秒钟就能知道这个包里有没有想要的信令层tshark -r 5g_sig.pcap -q -z io,phs这条命令会输出各个协议的包数、字节数和占比。如果输出里没有SCTP或NGAP大概率这段抓包不在N2接口上如果只有GTP-U没有NGAP说明抓的是N3用户面或镜像口给漏了。逻辑上-z io,phs表示会话结束后输出协议层级统计-r指定文件路径。协议层级统计是信令分析的第一道闸门能避免后面对着错误数据包浪费时间。识别接口的第二个手段是端口。常见部署里gNB与AMF之间的NGAP承载在SCTP上标准端口是38412和38422N3用户面的GTP-U走UDP 2152AMF服务化接口多为HTTP/2端口常见38462。看到SCTP就基本锁定是N2方向看到UDP 2152就是N3方向看到大量HTTP/2则要考虑是不是走了服务化接口。第三个手段是IP段网管的IP规划表里gNB、AMF、UPF通常各占一段地址批量抓包时把几个镜像口的数据混在一起用ip.addr10.x.x.x快速筛出目标网元。实际作业时我建议把SCTP偶联状态作为第一观察点。NGAP是面向连接的每个gNB和AMF之间先建立SCTP association偶联建立后才开始传NGAP消息。如果包里只有INIT/INIT-ACK/COOKIE-ECHO没有后续NGAP消息说明偶联建完后立刻断开这本身就是定位方向要么SCTP端口配置不对要么对端AMF没有监听要么IP路由不通。先把偶联建立流程看懂后面所有NGAP消息才有意义。N1接口没有独立物理口的结论也意味着想抓N1只能通过空口日志或N2上的NAS-PDU来还原不要指望在某个交换机端口上直接抓到“N1流量”。3. 抓包与回放5G信令分析的最小作业姿势与关键配置3.1 在gNB侧抓取N1/N2信令的tcpdump命令模板现场抓包多数时候是登到gNB的控制面接口或镜像口上抓。各厂商网管的抓包菜单不一样但底层思路都一样就是抓SCTP和GTP-U两类流量。最常用的模板是tcpdump -i any -s 0 -B 4096 -w /tmp/n2_sig.pcap sctp or (udp and port 2152)-i any表示在所有网卡上抓适合不确定信令从哪个物理口出去的场景-s 0抓完整包长度避免截断导致wireshark无法重组SCTP分片-B 4096把内核环形缓冲开到4096KB高信令流量下减少丢包-w指定输出文件。过滤器里sctp关键字在高版本tcpdump直接支持老版本不支持时可以写成ip proto 132因为SCTP的IP协议号是132。注意这个过滤条件同时抓了N2和N3如果只需要N2改成sctp port 38412。实际工程里有个细节抓包时长别太长。信令量大的时候4096KB缓冲也可能不够用-B能往上调到8192但落盘速度和磁盘IO也要跟得上。我见过有人一个文件抓了几个小时结果单个pcap达到几十GBwireshark打开都吃力。建议按问题场景控制抓包窗口注册失败就抓“终端从开机到注册完成”切换问题就抓“业务过程中切换的前后30秒”用起来最顺手。如果是在测试终端侧抓空口信令普通手机没有调试口需要专用的测试终端或路测工具从它们的日志里导出RRC和NAS信令。这类工具导出的日志通常会按时间段和事件打点省去抓包再分析的步骤但缺点是看不到N2侧真实收发时间。最稳的组合拳是测试终端导空口日志gNB侧导N2抓包两份时间对齐后互相印证问题要么在空口、要么在N2、要么在核心网一个下午能排完。3.2 wireshark回放关键配置时间戳、列显示与协议名抓完包回到办公室wireshark打开第一件事不是翻消息而是设置时间显示。默认pcap存的是UTC时间现场网管日志一般是本地时间不调整的话对不上。推荐在“视图-时间显示格式”里选择“日期和时间本地”或者用自1970年以来的秒数做精确对比。后者尤其在跨接口对齐时好用因为不同工具导出的log精度不一样epoch秒可以直接做差。这里有个小习惯每次定位完问题我会把“用了哪个时间格式”记在问题单里不然三天后回看同一个包会怀疑自己记错。列配置上默认的No/Time/Source/Destination/Protocol/Info够用但做信令分析我还会加三列SCTP PPID、NAS消息类型、RRC消息类型。wireshark里右键列标题可以添加自定义列输入sctp.ppid、nas_5gs.message_type、nr_rrc.message_type这类字段名即可。PPID能告诉你SCTP负载里装的是NGAP还是别的协议NAS消息类型能让你在长流程中一眼扫到每个5GMM消息RRC消息类型则用于空口侧的同名过滤。这三列加完后几千个包的流程能压缩成一张可扫读的表。回放时还要注意SCTP分片重组问题。NGAP消息可能超过SCTP单个chunkwireshark会把分片标记为“Reassembled SCTPn segments”并在Info列显示。查看时要以重组后的完整消息为准不要看中间的分片片段分片里的协议字段往往不全容易误判。如果文件是循环抓包覆盖保存的pcapng建议先另存一份只含目标接口的pcapng再分析避免大量无关包干扰过滤。保存习惯上原始抓包文件永远不动所有过滤和裁剪都另存后面要复核还能找得回来。3.3 抓包参数的现场选择时长、轮转与丢包确认现场抓包另一个常被问的问题是“抓多久、要不要轮转”。我的默认做法是定位性问题抓到现象复现后再等30秒收包批量性能问题抓5到10分钟。为了不让单个文件过大tcpdump支持按时间轮转落盘tcpdump -i eth0 -s 0 -w /tmp/rot/5g_%Y%m%d_%H%M.pcap -G 300 -W 12 sctp or (udp and port 2152)-G 300表示每300秒切换一个新文件-W 12表示最多保留12个文件配合%Y%m%d_%H%M时间戳命名轮转一圈刚好覆盖一小时。逻辑上轮转抓包最适合长时间挂测场景比如夜间自动测试第二天起来按时间段挑文件不用面对一个几十GB的大文件。参数上-G单位是秒不建议小于60秒否则频繁切换文件反而丢包。抓包结束后还要确认“到底有没有丢包”。tcpdump结束时按CtrlC会打印一行统计x packets captured, y packets received by filter, z packets dropped by kernel。第三行是内核丢包数如果z不是0说明缓冲不够或抓包机负载太高这次抓包结果要慎重使用。我看到z值偏大时通常会加-B缓冲或换一台空闲的抓包机重抓而不是硬着头皮分析。这个确认动作两秒钟但能避免把丢包误判成“信令缺失”。4. 注册与PDU会话流程逐条拆解从MSG1到N2建立的核对点4.1 注册流程从随机接入到Registration Accept的核对点5G注册流程从UE开机搜网开始但信令分析一般从随机接入的MSG1开始看。完整的注册链可以拆成八个关键点RRCSetupRequest、RRCSetup、RRCSetupComplete内含Registration Request、InitialUEMessage、鉴权与安全通常出现但可选、Security Mode Command/Complete、DownlinkNASTransport内含Registration Accept、InitialContextSetup。每个点都有对应的失败表现下表是我平时对流程时的核对清单流程节点关键字段/消息常见失败表现随机接入MSG1/2/3/4MSG3无响应、冲突解决失败RRCSetupRequestestablishmentCause字段UE反复发MSG3、rrcSetup定时器超时RRCSetupCompleteDedicatedNAS-Message里的Registration RequestNAS消息为空、PLMN选择不对InitialUEMessage携带NAS-PDU、GUAMI、PLMN IDgNB未转发、SCTP偶联断鉴权流程Authentication Request/Response身份不匹配、USIM参数错误Security Mode安全算法选择与密钥派生完整性校验失败、算法不匹配Registration Accept5GMM cause、网络切片信息TAC不允许、切片不被支持InitialContextSetupInitialContextSetup RequestgNB侧上下文建立失败、承载配置冲突实际核对顺序我习惯是先数清楚UE到底发了几次RRCSetupRequest。如果同一个establishmentCause的请求反复出现多半是MSG3没被gNB正确解出属于空口问题如果MSG3之后没有RRCSetup则要看下行调度和干扰如果RRCSetupComplete发出去但N2上没有对应的InitialUEMessage问题就在gNB到AMF的SCTP偶联上。这个顺序能把问题定位范围一步步缩小。再补充一个点看RRCSetupComplete里的establishmentCause能判断UE这次接入是应对什么业务比如mt-Access是高优先级语音mo-Signalling是普通信令对不上的话要怀疑终端侧的接入策略配置。N2侧最重要的一段是InitialUEMessage里的NAS-PDU它就是UE发的Registration Request明文内容包含5G-GUTI或SUCI、请求的NSSAI、UE能力等。wireshark里点开NAS-PDU可以直接读到5GMM消息类型和各个IE。注册失败常见的NAS cause比如2号PLMN不允许、3号IMSI未知、6号非法的ME看到这些cause直接进核心网侧排查签约和号码状态。如果这里读不到内容先确认NAS是否已加密避坑章节有展开说明。4.2 PDU会话建立N2承载建立与QoS Flow映射怎么看注册完成不代表能上网PDU会话建立是用户面打通的关键。这一步的信令同样跨N1/N2/N3UE发PDU Session Establishment RequestNAS5GSM消息AMF收到后向gNB发PDUSessionResourceSetupRequestgNB在空口通过RRCReconfiguration给UE配DRBUE回RRCReconfigurationCompletegNB再回AMF PDUSessionResourceSetupResponse最后UPF侧建立GTP-U隧道。看这段流程我建议按“三个对象”去核对PDU Session ID、QFI、TEID。PDU Session ID区分是哪一条会话QFI标识一个QoS FlowTEID是N3用户面隧道的端点标识。如果RRCReconfiguration里配了DRB但N2的PDUSessionResourceSetupResponse里没有对应QFI或者Response里回传的UL TEID和N3抓包里的GTP-U报文TEID对不上就会出现“信令流程全绿但业务不通”的现象。很多人排查到这里就开始怀疑核心网其实先对TEID能省掉大量时间。QoS Flow映射的核对重点是5QI和QFI的对应关系。N2的PDUSessionResourceSetupRequest里每个QoS Flow Setup Request Item携带QFI、5QI、分配与保留优先级。空口RRCReconfiguration的DRB配置里每个DRB又映射到一个或多个QFI。我常用的判断方式是业务不通时先看RRC的DRB映射表里有没有QFI9默认大流量承载没有就很可能是gNB没按N2要求完成承载映射需要去gNB侧查5QI到DRB的配置有QFI但N3无GTP-U流量再看UPF侧TEID和路由。另外别忘了N2响应里会带核心网侧的DL TEID这个值和后续N3下行数据包的目的TEID必须一致不一致就是UPF或gNB隧道管理出错。4.3 用过滤表达式快速定位失败信令的通用套路定位失败信令的高效套路是先把包按接口过滤出来再搜cause。wireshark显示过滤栏输入ngap就能只看N2信令想看所有带cause的NGAP消息输入ngap.cause。如果当前wireshark版本不支持这个字段名用“CtrlF搜索分组字节流”输入cause关键字也能找到差不多的集合。NAS侧的失败原因在5GMM/5GSM消息里不同版本字段名略有差异最快的方法是点开一条Registration Reject消息在消息详情里右键相关字段直接生成过滤条件这样最稳。命令行场景下可以用tshark快速扫tshark -r n2_sig.pcap -Y ngap -T fields -e frame.number -e _ws.col.Info | grep -i -E cause|failure|reject这条命令把N2信令的消息列表打印出来再用grep过滤带cause、failure、reject字样行十几秒就能在几千个包里定位到失败消息所在帧号。回到wireshark按帧号跳转再顺着这个帧往上一个关键流程节点找根因。整套套路的核心思想是先按接口缩小范围再按cause关键字缩小到帧最后顺着帧看上下文而不是从头到尾逐包读。还有一个小技巧把过滤结果导出成CSV或用“文件-导出分组解码”导出文本方便贴进问题单。5. 5G信令分析避坑指南5个翻车现场与排查方法5.1 翻车现场一NGAP在wireshark里整片标红现象打开的N2抓包文件里SCTP和NGAP消息全部显示为校验错误或“Malformed Packet”Info列看起来像乱码。第一次遇到的人会以为文件抓坏了重新抓包结果重抓好几次都一样。原因服务器网卡启用了SCTP校验和offload网卡在发送时由硬件计算校验和并填充但tcpdump抓到的包是填充之前的原始包校验和字段对不上。解决抓包机上关闭SCTP offload再抓命令是ethtool -K eth0 tx-checksum-sctp off如果现场没法关offload就在wireshark里忽略校验和错误对现有文件继续分析NGAP消息内容不受影响。这个坑里最容易翻车的地方是“重抓”而不是“忽略”建议先看内容再决定是否重抓。5.2 翻车现场二安全模式之后NAS全成了加密黑匣子现象注册流程前面几段还能看到明文但Security Mode Command之后所有NAS消息的载荷都变成不可读的乱码既看不到Registration Accept也看不到后续的cause。原因接入网侧完成安全性激活后NAS和RRC的加密算法生效抓包工具没有密钥自然解不开。解决实际工程中测试环境把加密算法配成空算法nea0/eia0是常见做法能直接看到后续明文生产环境则依托核心网侧日志或信令监测设备输出解码后的内容。如果只有抓包文件重点放到加密前的明文部分比如初始NAS消息里的cause和请求参数以及安全模式命令本身选择的算法根据算法推后续行为方向。别在解密上死磕没有密钥的解密只会越查越偏。5.3 翻车现场三UTC时间和本地时间对不上流程顺序全乱现象把pcap回放和网管日志放在一起对比发现同一条信令在抓包里是早上八点在网管日志里是下午四点整体偏移八小时初看像是两个时间点发生的不同流程。原因pcap默认记录UTC时间网管平台一般显示本地时间。解决进入wireshark的“视图-时间显示格式”选择“日期和时间本地”或直接用frame.time_epoch字段做数值对比tshark里用-e frame.time_epoch输出整数秒再换算。复盘时在问题单里同时记录两种时间制是我的习惯能避免三天后再回看同一条记录时怀疑自己看错。这个坑在跨时区的远程抓包里特别常见时间对不齐先想时区别急着怀疑对端设备时钟。5.4 翻车现场四拿4G的RAB Assignment思路找5G承载现象用LTE时代的经验找RABAssignmentRequest或“承载指派”消息在5G的N2抓包里怎么也找不到开始怀疑抓包缺段。原因5G的用户面承载粒度从EPS Bearer变成了QoS FlowN2侧的建立流程是PDUSessionResourceSetup而不是RABAssignment。解决把关键词换成PDUSessionResourceSetup与PDUSessionResourceSetupResponse空口侧对应的承载配置在RRCReconfiguration里的DRB字段里。只要流程正确N2上会有明确的PDU会话资源建立请求和响应QFI和TEID都在里面。如果按新关键词仍找不到再从接口是否正确、SCTP偶联是否建立两个方向检查而不是继续怀疑流程没走到。5.5 翻车现场五用户面抓包当信令面分析NGAP过滤为空现象抓了一整包数据过滤ngap却一条都没有打开全是UDP和GTP-U怀疑是wireshark版本兼容性问题。原因抓包位置在UPF或N3镜像口上抓的是用户面数据不是gNB和AMF之间的N2控制面。解决抓包前先确认抓包点在哪条链路上。N2抓包要放在gNB与AMF互联口或AMF侧镜像口N3抓包才去UPF侧。已经抓错的情况下先用tshark -z io,phs看协议分布确认存在SCTP再继续没有SCTP就基本可以判断是抓错口。现场条件不允许重抓时也可以从用户面GTP-U的TEID反查N2侧建立的会话但定位效率会差很多能重抓还是重抓。5.6 排查顺序从空口到N2的固定检查链把上面五个坑串起来我形成了一套固定检查链第一步看协议层级统计确认包里有SCTP和NGAP第二步统一时间戳转到本地时间或epoch秒第三步数RRCSetupRequest和RRCSetupComplete的次数与序号第四步对照N2的InitialUEMessage确认gNB是否转发第五步找NGAP带cause的消息跳到具体帧读上下文。这套顺序在近一年的外场和实验室问题里帮我把平均定位时间从按天缩短到按小时。它不复杂胜在每次都不跳步避免被加密字段和端口混淆带偏。建议新人也先按这个顺序练熟练后再按问题特点跳步。6. 把抓包文件变成一页纸流程摘要tsharkPython的自动化工装6.1 用tshark导出关键字段CSV问题定位完还要出报告原始pcap几百MB不适合直接贴问题单。我通常用tshark把关键字段导成CSV再用Python生成一页纸流程摘要包含消息序列和分段耗时。导出命令如下tshark -r 5g_sig.pcap -Y ngap or nas_5gs or nr_rrc -T fields \ -e frame.number -e frame.time_epoch -e ip.src -e ip.dst \ -e _ws.col.Protocol -e _ws.col.Info \ -E headery -E separator, -E quoted sig_flow.csv-Y后面是显示过滤器只保留三类信令层-T fields指定输出字段-e frame.time_epoch输出秒级时间戳方便做差值计算_ws.col.Info带出wireshark解析后的消息描述。逻辑很简单把wireshark人眼看的列变成结构化文本交给脚本统计。参数上headery给CSV加列名separator,指定逗号分隔quoted把包含逗号和引号的内容安全包起来。遇到几百MB的大包导出时间在数十秒量级可接受。6.2 用Python统计注册流程耗时与消息计数拿到CSV后我用一个精简脚本统计两件事注册流程总耗时、各信令层消息条数。注册流程的起止用两条关键消息界定RRCSetupComplete含Registration Request和Registration Accept所在的下行NAS Transport。import csv rows list(csv.DictReader(open(sig_flow.csv))) start None end None count {ngap: 0, nas_5gs: 0, nr_rrc: 0} for r in rows: proto (r.get(_ws.col.Protocol) or ).lower() info r.get(_ws.col.Info) or if rrcsetupcomplete in info.lower() and start is None: start float(r[frame.time_epoch]) if registration accept in info.lower(): end float(r[frame.time_epoch]) for key in count: if key in proto: count[key] 1 if start and end: print(注册流程耗时: %.1f ms % ((end - start) * 1000)) else: print(未找到完整注册流程请检查关键词匹配) print(消息条数:, count)逻辑上脚本遍历每行CSV遇到第一个包含rrcsetupcomplete的消息记起点遇到包含registration accept的消息记终点同时按协议名累加消息数。参数说明要注意wireshark不同版本的Protocol列写法略有差异所以我用了关键词包含判断而不是等值判断如果Info列显示的内容不在预期关键词里把脚本里的匹配词改成实际显示内容即可。这个脚本的价值在于可复用换一个抓包文件直接跑就能得出可贴在问题单里的摘要不用每次手动数和估算。再多一步延伸在CSV基础上按消息序列做分段耗时统计从RRCSetupRequest到InitialUEMessage、从InitialUEMessage到Security Mode Command、从Security Mode Command到PDU会话建立把每段耗时打出来就能快速定位哪一段最可疑。具体做法是维护一个状态机和对应的时间戳变量遇到特定消息就记录。这套“导出-统计-摘要”的流程不替你做判断但能把大半小时的人工读包压缩到几分钟把精力留给真正的cause分析。最后说一个习惯。早期我拿到抓包就直奔cause字段有次在实验室调模拟项目X的注册失败问题只看到网络侧cause就下了结论结果后来发现真正的根因在gNB侧切片配置缺失cause只是表象。那次之后我给自己定了规矩先分接口、再对流程、后看cause顺序不能跳。这条规矩帮我少翻了无数次车把它写在这里希望帮到你。本文还有配套的精品资源点击获取