简介：这份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）、N2（gNB到AMF）、N3（gNB到UPF）。空口上跑的是RRC和NAS，RRC管小区接入、测量控制、DRB承载配置；NAS（5GMM/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数据也要一起抓。下表把这四类信令的边界列清楚：

提示：实战里先看空口消息拿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和38422；N3用户面的GTP-U走UDP 2152；AMF服务化接口多为HTTP/2，端口常见38462。看到SCTP就基本锁定是N2方向，看到UDP 2152就是N3方向，看到大量HTTP/2则要考虑是不是走了服务化接口。第三个手段是IP段，网管的IP规划表里gNB、AMF、UPF通常各占一段地址，批量抓包时把几个镜像口的数据混在一起，用ip.addr==10.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达到几十GB，wireshark打开都吃力。建议按问题场景控制抓包窗口：注册失败就抓“终端从开机到注册完成”，切换问题就抓“业务过程中切换的前后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单个chunk，wireshark会把分片标记为“Reassembled SCTP（n 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结束时按Ctrl+C会打印一行统计：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。每个点都有对应的失败表现，下表是我平时对流程时的核对清单：

实际核对顺序我习惯是：先数清楚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/N3：UE发PDU Session Establishment Request（NAS，5GSM消息），AMF收到后向gNB发PDUSessionResourceSetupRequest，gNB在空口通过RRCReconfiguration给UE配DRB，UE回RRCReconfigurationComplete，gNB再回AMF PDUSessionResourceSetupResponse，最后UPF侧建立GTP-U隧道。

看这段流程，我建议按“三个对象”去核对：PDU Session ID、QFI、TEID。PDU Session ID区分是哪一条会话，QFI标识一个QoS Flow，TEID是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映射表里有没有QFI=9（默认大流量承载），没有就很可能是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版本不支持这个字段名，用“Ctrl+F搜索分组字节流”输入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 Flow，N2侧的建立流程是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. 把抓包文件变成一页纸流程摘要：tshark+Python的自动化工装

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 header=y -E separator=, -E quote=d > sig_flow.csv

-Y后面是显示过滤器，只保留三类信令层；-T fields指定输出字段；-e frame.time_epoch输出秒级时间戳，方便做差值计算；_ws.col.Info带出wireshark解析后的消息描述。逻辑很简单：把wireshark人眼看的列变成结构化文本，交给脚本统计。参数上，header=y给CSV加列名，separator=,指定逗号分隔，quote=d把包含逗号和引号的内容安全包起来。遇到几百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，顺序不能跳。这条规矩帮我少翻了无数次车，把它写在这里，希望帮到你。

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