5G信令流程解析：从RRC、NGAP到NAS的抓包实践指南

简介：面向5G通信学习者与技术人员的信令流程解析文档，围绕背景知识、核心概念、信令类型以及接入、鉴权安全、移动性管理、资源分配和服务质量保障等关键环节展开，可帮助初学者快速建立整体框架。文档从UE、gNB与核心网的协作关系切入，说明控制信令与用户数据信令的差异，并对每个环节的功能定位逐一梳理。学习技巧部分给出系统学习、深入理解、实践仿真、案例分析与持续跟进五条路径，兼顾自学与培训场景。内容以docx格式呈现，全包共1个文件，大小约11KB，轻便易读，便于结合仿真软件进行验证。目前已有402人学习，适合正在打基础或准备从事5G网络优化、设备调试的读者参考。

1. 5G信令流程解析：从“看过流程图”到“能对着抓包讲清楚”

5G信令流程解析这个主题，表面听起来无非是注册、PDU会话建立、切换那几个名字，但真拿一份抓包去对照时，你很快会发现要同时面对RRC、NGAP、NAS三层消息，核心网控制面又被拆成AMF和SMF两个角色，任何一层对不上，整条链路都解释不通。之前我处理一个模拟项目X里的跨基站切换问题时，明明看到NGAP侧出现了HandoverRequired，却一直对应不到核心网侧的响应，折腾到中午才发现是SCTP流的信令负载被分散到了另一个关联里。这类经历反复出现以后，我才意识到：5G信令流程的学习必须按“一条完整链路”来推进，而不是像LTE时代那样只看单一接口。这套资源的价值就是把流程串成可对照的路径，从初始接入、注册直到会话建立和移动性，适合做5G网络优化、核心网测试、协议栈开发，以及刚从LTE转5G的工程师。

2. 5G信令流程解析入门前：先划清RRC、NGAP、NAS的边界

2.1 三层信令管的事完全不一样

5G信令流程解析的第一步，是把三条协议栈的分工边界划清楚：UE和gNB之间跑RRC，gNB和AMF之间跑NGAP，UE和AMF之间真正对话的是NAS。三者不在一层，却同属一条决策链。如果你之前做过LTE优化，最大的惯性是把RRCSetupComplete当成“接入已经成功”的标志；放到5G环境里，这条消息只是完成了RRC连接建立，真正决定网络如何对待这个UE的，是它内部携带的NAS消息。

常见做法是把这三层理解成“管道、搬运、内容”三个角色：RRC负责建出空口管道，NGAP负责把NAS消息搬到正确的AMF，NAS本身才是核心网要处理的内容。这样切分对后续排障非常有用——RRC层失败多发生在空口覆盖、随机接入或接入等级控制；NGAP层失败多见SCTP连接异常或AMF选择问题；NAS层失败基本要回到签约数据、切片策略和DNN配置里找原因。

这里有个容易走的弯路：拿LTE的接口习惯套5G。LTE里MME同时负责移动性管理和会话管理，很多人习惯了把核心网当成“一个盒子”；但5G里AMF和SMF职责分开了，注册请求牵着AMF，PDU会话建立请求牵着SMF，两个流程可以先后触发，也可以并发执行。实际抓包里，注册完成后往往紧跟着PDU会话建立，不少新人把这两段拼接成一段来理解，概念上勉强说得通，但一到排障，消息对应关系就乱。严格来说，注册流程负责让UE被网络识别，PDU会话流程负责给UE一条能传数据的通道。一条消息属于哪个流程，看它携带的NAS消息类型最准。

RRC的状态迁移也值得顺带记忆。RRC_IDLE、RRC_INACTIVE、RRC_CONNECTED三态切换，会直接影响NGAP层是否有UE上下文存在。比如空闲态纯信令交互时，可能只有NAS消息而没建数据无线承载，这时看不到InitialContextSetup反而正常，不代表流程出错。

2.2 NGAP过程代码：判断信令走到哪一步的关键指针

NGAP层在N2接口上有一个关键字段叫procedureCode，它表示这条NGAP消息属于哪个过程。实际抓包时不用手动去解整数值，Wireshark在NGAP协议树里会直接显示成类似“InitialContextSetup (13)”的文本。写过滤条件时，一条“ngap”就能把N2接口上的过程消息全部列出来，但要把不同过程的语义分清，还是得记住几个典型名字。

建议把NGAP过程分成三类去记。第一类是gNB主动发起的，典型代表是InitialUplinkNASTransport、UplinkNASTransport、UEContextReleaseRequest。第二类是AMF主动发起的，典型是InitialContextSetupRequest、UEContextModificationRequest、DownlinkNASTransport。第三类是切换相关，常见是HandoverRequired、HandoverRequest、HandoverCommand。这样分类的好处是，看到一条消息时能快速判断是哪一方在做决策。比如gNB向AMF发UEContextReleaseRequest，基本可以断定gNB侧认为UE上下文不需要保留了，原因值通常指向无线链路或接入控制。

一个需要特别盯紧的点：UEContextReleaseRequest名字里带“Release”，它不等于PDU会话释放，也不等于让UE彻底下线。在5G中，上下文释放可以发生在注册完成后转入空闲态，也可以发生在PDU会话释放之后。判断一个整体流程是否真正收尾，不能只看有没有“Release”字样，而要确认UE是否已经迁到RRC_INACTIVE或RRC_IDLE状态。我实操时一般看到ReleaseComplete之后，还会再往后翻几帧，确认没有后续NAS消息或新NGAP过程启动。

下面这个表是我常用的一组NGAP过程对应关系，适合贴在笔记里做速查：

看熟这个表以后，分析NGAP消息时基本不会迷路。再进一步，可以把每个过程所承载的NAS消息类型也加一列，因为NGAP往往只是“壳”，壳里面装的内容才是业务流程的真实意图。

2.3 NAS层：注册与会话，各自成对出现

5G NAS层从类型上分为两大块：移动管理类消息管注册、鉴权、位置更新，会话管理类消息管PDU会话建立、修改、释放。移动管理和会话管理的消息一般不会混在同一个NAS PDU里，这让排障有个天然便利——看到NAS消息种类的字段，基本能判断当前处于哪一段流程。

注册流程里，消息大体按“请求—响应—确认”成对出现。UE先发RegistrationRequest，网络回AuthenticationRequest或SecurityModeCommand，最终以RegistrationAccept或RegistrationReject收尾。PDU会话建立流程里则是PDUSessionEstablishmentRequest配PDUSessionEstablishmentAccept；如果出现Reject，要看原因值，比如SNSSAI不可用、DNN不允许，问题就落在切片或数据网络配置上。

还有一个高频困惑：拿到pcap后发现NAS层全是密文，以为抓包失败。其实5G支持安全上下文建立之前的明文NAS，也支持建立后的密文NAS。安全模式命令之前，请求内容基本明文可见；安全模式命令之后，多数NAS消息会被加密。如果不想一上来就被“黑匣子”困住，建议先把安全模式命令之后的NAS消息当作黑盒，用NGAP消息和时序去验证流程，等需要深挖具体原因时再导入密钥解密。

3. 实操：用Wireshark把一条5G信令流程完整复现

3.1 先过滤再展开：把混杂帧降到最低

打开一份5G信令pcap时，如果里面混着SCTP控制帧、PFCP会话帧，甚至GTP-U用户面流量，直接看全量列表一定眼花。我给自己定了三步流程：定时间范围、定信令接口、定关键NAS消息。操作界面上先用显示过滤器缩小范围：

tshark -r sample.pcap -Y "ngap || nas-5gs || rrc" -T fields -e frame.number -e frame.time_relative -e _ws.col.Protocol -e _ws.col.Info

这段命令的“-r”指定读入的pcap文件，“-Y”后面跟显示过滤表达式，“ngap || nas-5gs || rrc”表示只要帧中包含这三种协议层中的任意一种就保留，之后“-T fields”切换成字段输出模式，“-e”指定要打印的字段，按顺序分别是帧号、相对时间、协议缩写和Info列内容。这样跑完，就能得到一张按时间排列的信令消息概览表，比在图形界面里逐帧翻快不少。

如果习惯图形界面，可以直接在Wireshark的显示过滤器栏里输入同样一条表达式。建议把相对时间列显示出来，方便计算消息之间的间隔。比如RegistrationRequest之后超过3秒才看到网络侧响应，就要怀疑空口重传或核心网处理时延；如果间隔极小但后续流程中断，多半是某个NGAP过程没有收到正常响应。

判断信令面接口时，还可以参考SCTP的目标端口。NGAP普遍使用标准的SCTP信令端口，看到目标端口是38412或38422这类值，基本可以确定是N2接口流量。抓包环境里如果端口被改过，那就按“sctp”过滤后逐个观察，再结合NGAP协议标识确认。

3.2 解密NAS层：密钥和算法必须同时正确

5G测试环境里，很多设备默认关闭了NAS加密；但商用环境或部分仿真环境会打开完整性保护和加密。打开抓包后如果NAS消息全是密文，先别急着下结论，按以下顺序检查。第一步，在Wireshark的协议偏好设置里找到5G NAS相关协议，填入根密钥K、RRC加密密钥以及完整性保护密钥。第二步，核对算法标识，比如NEA0、NEA1、NEA2、NEA3，还有对应的完整性算法。密钥对了但算法选错，解码结果仍然是乱码。第三步，确认当前抓包点是否能拿到安全模式命令之前的明文NAS；如果测试环境打开加密很早，很多内容确实解不出来，那不是工具问题。

命令行环境下可以通过tshark做部分字段抽取。比如只把NAS消息类型打出来对比：

tshark -r sample.pcap -Y "nas-5gs" -T fields -e frame.number -e nas-5gs.message_type

参数解释一下：“-Y nas-5gs”让输出只保留包含NAS 5GS协议的帧，“-e nas-5gs.message_type”指定打印消息类型字段。如果这一列出现“unknown (xx)”或者大量空值，说明当前解析器版本或密钥条件下解码不完整，回图形界面检查配置更直接。需要提醒的是，5G安全上下文建立后，如果中间发生过密钥更新，早期帧和后期帧的解密条件并不相同，回头再用旧密钥去解新帧，解不出是正常的，不等于抓包失败。

3.3 核对关键字段：InitialContextSetup和PDU会话绑定

注册流程里，真正在空口之外判断“注册是否被接受”的关键，是看AMF有没有下发InitialContextSetupRequest，以及gNB有没有回InitialContextSetupResponse。如果响应里携带失败原因，比如radioNetwork下不支持某个QoS能力，说明无线侧当前配置满足不了核心网要求的承载能力。这种问题在5G信令排障里很容易被误判为“核心网参数错误”，实际上不少是gNB的切片或QoS配置与AMF下发的配置不一致。

再往后看PDU会话建立流程，定位PDUSessionResourceSetupRequest。这条NGAP消息里会携带PduSessionId和SNSSAI。检查gNB返回的Response里是否包含同一个PduSessionId；如果不包含，说明这条会话没有建立成功，这时再去NAS层找PDUSessionEstablishmentReject。原因值如果指向SNSSAI不可用，问题大概率在切片配置：允许的切片列表、签约切片或AMF策略。如果原因值指向DNN，就去核对数据网络名称和用户签约。

我带过的很多人卡在这一步，是因为习惯了看“有没有Accept”。实际上，一个PDU会话真正建立成功，必须同时满足三个条件：NGAP层有PDUSessionResourceSetupResponse且绑定同一PduSessionId，NAS层有PDUSessionEstablishmentAccept，并且gNB侧完成数据无线承载建立。三条缺一条，都不能认为流程完整。验证用完了以后，按这个标准把每个流程跑一遍，对应的消息清单自然就熟了。

4. 这套资源怎么学：拆流程、对照表、按接口去记

4.1 按流程拆主干，不等于按页翻资料

5G信令流程解析资料最常见的错误打开方式，是从第一页顺序读到最后一页。文档型资源的正确用法是先拆主干再补细节。我拿到这套资料后，先只看注册流程、PDU会话建立流程、切换流程三张总图，其他细节章节先跳过。把主干流程拆成“必选步骤”和“条件步骤”两类，必选步骤用于建立记忆骨架，条件步骤用于真实抓包时判断分支。

比如注册流程里，RegistrationRequest、Authentication、SecurityModeCommand、RegistrationAccept基本属于必选或高度必选路段；而身份请求、鉴权失败后重新鉴权则属于条件步骤。实际网络里如果看到UE发出RegistrationRequest后直接收到RegistrationAccept，说明网络配置了免鉴权或已缓存安全上下文，这也是正常分支，不是异常。学的时候不要觉得“没有鉴权消息就一定是抓包不完整”，要先判断网络策略。

4.2 一张跨接口对照表，抵三张流程图

5G信令比LTE更费心的地方，在于同一业务逻辑被分散到空口、N2、NAS三条线上。资源里有一张跨接口对照表，把同一时间戳下的RRC帧、NGAP帧和NAS消息放在同一行。我看这张表的方式比较特殊：遮住接口列，只留NAS消息内容，自己判断这条NAS消息应该从哪个接口、由哪个NGAP过程携带。练两三轮以后，再回抓包里定位帧，速度会明显加快。

一个值得反复对比的是切换流程里的两张分支图：Xn切换和N2切换。Xn切换时gNB之间直接完成上下文转发，AMF不参与中间的每条信令交换，所以NGAP层看不到HandoverRequired；N2切换则由AMF全程参与，NGAP层会明显出现HandoverRequired和HandoverRequest。把两张图放在同一屏里对比，找出两条路径的第一条消息分别是什么，之后看到消息名就能判断当前走的是哪条路径。

4.3 文档型资料怎么用才不浪费：把规范变成检索表

这套资源并不是一份正式规范，它不会把每个信元的每个bit位都展开；但它做了一件更重要的事——把散落在规范里的流程串成了可检索的路径。所以使用时，更适合“索引式阅读”而不是“从头背诵”。遇到一个具体流程，先找同名章节，再看里面列的步骤和方向，然后翻回抓包验证字段值。

我通常会把每个流程的关键字段抽成一条简单清单，比如：流程名称、起始消息、需要关注的NGAP过程代码、收尾消息、常见原因值。资源里已有的就沿用，资源里没写的自己补。这样就算某一台商用设备的行为和文档描述有细微出入，我也有自己维护的清单可以做二次判断，不会因为某个文档注释不完整而卡住。资料的价值在于降低起步门槛，但最终的判断标准永远是实际抓包里的字段和时序。

5. 5G信令流程避坑与排查：五个常见的翻车点

5.1 坑一：看到Registration字眼就以为注册完成

现象：抓包里看到RegistrationRequest，后面也看到了RegistrationAccept，就直接判定注册流程成功。

原因：有些场景下终端收到的是RegistrationReject，或者网络要求重新注册；也有部分版本下，流程还没真正结束但消息名里带了Registration字样，单纯看名字容易误判。

解决：核对注册流程的收尾结果，同时查看gNB是否收到InitialContextSetupRequest。如果AMF没有把UE上下文建立下来，即使看到RegistrationAccept，注册也只是部分完成。以NAS层的接受/拒绝字段和上下文建立结果为准，不要只凭消息名下结论。

5.2 坑二：把NGAP过程和NAS消息混为一谈

现象：分析时看到UplinkNASTransport，就认为这是UE上行的NAS请求，直接读该帧正文。

原因：UplinkNASTransport是NGAP层的过程名称，真正的NAS请求内容被封装在它的NAS PDU字段里。协议的层次关系没有拉开，看到什么读什么，自然容易错位。

解决：查看消息时先把协议树展开，定位到NAS 5GS层，再读具体消息类型。或者在显示过滤器里只保留nas-5gs，强制忽略NGAP壳层。习惯上看到带Transport字样的消息，第一反应应该是“这是搬运的壳，内容在壳里面”，再去剥开壳看正文。

5.3 坑三：明确是Xn切换，却一直找NGAP切换消息

现象：交接分析时，日志里始终没有HandoverRequired，却看到目标侧出现了上下文建立相关消息，分析方向完全跑偏。

原因：5G切换有Xn切换和N2切换两条路径。Xn切换不经过AMF转发信令，gNB之间直接协调，因此NGAP层看不到HandoverRequired；N2切换才会在NGAP层出现典型切换过程。环境网络实际执行的是Xn切换，去NGAP里找Handover消息当然找不到。

解决：先判断UE当前小区和目标小区之间的切换路径。从资源里的切换分支图入手，标注两条路径各自的起始消息；抓包中看到第一条切换相关消息是XnAP的HandoverRequest而不是NGAP的HandoverRequired，就直接转到Xn路径验证，不要硬等NGAP过程出现。

5.4 坑四：密钥或算法不一致，NAS全是乱码

现象：密钥填完后NAS消息依旧是乱码，或者消息类型打印成unknown。

原因：多数情况是根密钥或中间密钥填错，算法标识选择与网络侧不一致；少数情况是站点开启的加密算法较新，当前Wireshark解析器版本不支持。

解决：先从核心网侧确认实际的完整性保护算法和加密算法，再回Wireshark的协议偏好逐项核对。命令行版本参数兼容不稳定时，退回图形界面先完成解密验证，再导出pcap继续分析。还要注意安全上下文建立后可能发生密钥更新，旧密钥解新帧解不出来是正常现象，不要反复怀疑抓包文件损坏。

5.5 坑五：只用ngap过滤，NAS关键消息被漏掉

现象：过滤词输入ngap以后，NGAP过程消息都在，却始终找不到某条PDU会话建立的NAS Accept，于是怀疑漏抓包。

原因：ngap显示过滤器只匹配包含NGAP协议层的帧，但部分NAS消息所依附的帧没有被解析出NGAP过程字段，或者该帧里只有NAS协议层。过滤条件太窄，把原本存在的NAS结果挡在了显示范围之外。

解决：改用“ngap || nas-5gs”组合过滤，或单独过滤“nas-5gs”，确保纯NAS帧不丢失。如果还是找不到，就加“frame.time_relative”限定对应时间窗口，排除其他业务流程的NAS帧干扰。在命令行下把NAS消息类型打出来逐条看，也比肉眼看包列更稳。

6. 多走一步：做一张自己的5G信令消息速查卡

避坑避得再多，最终要落到自己能快速检索。我实际操作时，会为每个常用流程做一张速查卡，固定格式如下：

填写这张卡的过程比看一遍资料有用得多。填到切换流程时，把Xn切换和N2切换分别做两张卡，起始消息换掉，NGAP过程换掉，对比自然就出来了。填完后，每周挑一条真实抓包，对照自己的卡片重新走一遍：第一步找到起始消息，第二步判断当前走的是哪个分支，第三步核对收尾消息和绑定关系。这个循环坚持几次，信令流程就从“背过”变成了“用过”。

后来我每次拿到新的pcap，都强制自己先做一遍速查卡再动手分析，哪怕那些步骤我已经很熟，也绝不省略。这样做的好处是，分析思路始终围绕流程主干展开，不会一上来就陷进某个字段的细节里。希望帮到你。

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