刚接触5G核心网那会儿，我被UE开机后的那串信令绕得晕头转向：注册、鉴权、安全模式、PDU会话，消息一封接一封，每一封都在UE和AMF之间来回。后来把Wireshark打开，看到一条Registration Request在协议树里一层层展开，很多协议字段才真正对上号。这篇就围绕5G核心网里的NAS消息解析，从协议字段讲起，再落到Wireshark的实际抓包演示，适合正在学5G协议、做核心网测试，或者准备从LTE转5G的朋友。
1. NAS消息在5G信令面里的位置，以及为什么值得专门抓它
1.1 NAS到底干的是什么活
NAS是非接入层（Non-Access Stratum），翻译成人话就是：它不属于某个基站或某条无线链路，而是在UE和核心网之间“端到端”交互的信令。4G里有APN、Attach那一套，5G里换成了一整套新的NAS流程，但核心思路一致：终端要和网络完成身份校验、安全协商、注册、会话建立，这些动作基本都靠NAS消息承载。
5G的NAS又分成两个子层：
- 5GMM（5G Mobility Management）：管移动性，比如注册、去注册、服务请求、TAU之类的流程，都是它的事。
- 5GSM（5G Session Management）：管会话，比如PDU会话的建立、修改、释放，跟数据连接密不可分。
这两层消息在抓包里很容易区分，因为它们的 Extended Protocol Discriminator 不一样，5GMM是0x7E，5GSM是0x2E。只要看到Wireshark协议树里展开的NAS-5GS，就说明这层已经到了核心网用户面的“大脑”了。
1.2 为什么非要抓NAS，直接看RRC和NGAP不行吗
NAS本身是放在空口的RRC消息里，或者N2口的NGAP消息里传到核心网的。所以理论上，只看RRC或者NGAP也能看到一部分信息，但你看到的多半是“壳子”——比如RRCConnectionSetupComplete里裹着一条NAS消息，但你不知道里面具体是注册请求还是PDU会话相关，更看不到SUCI、GUTI、NSSAI这些关键字段。
NAS消息相当于一个“信封”，把移动性管理和会话管理的具体内容装在里面。排障的时候，如果UE注册不上，最常见的动作就是：到N2口抓一条NGAP消息，展开里面那个 NAS-PDU 字段，看里面的NAS层到底报了什么原因。这个动作我做过无数遍，可以说是5G核心网排障里最基础也最有效的一招。
再有一个重要原因：NAS消息里藏着网络选择、安全参数、切片信息这些核心网的核心决策。比如Registration Request里的Requested NSSAI，直接决定了用户能不能用某个网络切片；PDU Session Establishment Request里的DNN和SSC mode，又决定了数据会话怎么建立。不懂这些字段，光看接口告警根本定位不了问题。
1.3 明文还是密文，决定了你能看到什么
NAS有一个特别容易把人劝退的点：消息分明文和受保护两种状态。Wireshark里看Security Header Type，0就是明文，非0就是完整性保护或加密保护。在真实商用网络里，注册流程走到Security Mode Command之后，NAS消息基本就加密了，抓包看到后面一堆乱码很正常。
这也是为什么我特别推荐用模拟环境来学NAS解析：在Open5GS加UERANSIM这套组合里，可以把安全算法配成NEA0/NIA0，让安全模式建立后的消息也保持明文。这样一来，完整流程的每一条NAS都能在Wireshark里逐字段拆开看，学习效率比对着规范硬啃高得多。后面第4部分我会给出具体做法。
2. 先背熟这套NAS协议字段，抓包才看得懂
2.1 先看懂NAS的“信封”：EPD、Security Header Type、Message Type
每一段5G NAS消息，头三个字节几乎是必看的。第一个字节是Extended Protocol Discriminator（EPD），用来说明这段消息到底是5GMM还是5GSM，或者其它协议。第二个字节里的低4位是Security Header Type，高4位是Spare，通常为0。第三字节就是Message Type，也就是消息类型编号。
我平时分析裸字节流时，基本只看前三个字节就能判断这段消息大概是什么。比如：
- 0x7E 0x00 0x01，就是5GMM的Registration Request，明文。
- 0x7E 0x00 0x02，就是Registration Accept。
- 0x2E 0x00 0xC1，就是5GSM的PDU Session Establishment Request。
这个习惯在调试接口报文时特别有用。有时候Wireshark没有自动解析出NAS层，你就得自己从字节流里找到NAS的起始位置，然后靠前三个字节手动识别。
Security Header Type的取值也很关键，在Wireshark里通常会显示成字符串，比如 Plain NAS, not security protected。规范里的含义大概是：
| Security Header Type | 含义 |
|---|---|
| 0 | 明文，未受保护 |
| 1 | 完整性保护 |
| 2 | 完整性和机密性保护 |
| 3 | 完整性保护的新安全上下文 |
| 4 | 完整性和机密性保护的新安全上下文 |
实际抓包时，Registration Request刚启动时经常是0，等到Security Mode Command完成后，后续消息就可能变成1或2。如果你发现某条NAS消息看不懂，先看一眼Security Header Type，别急着怀疑解析器坏了。
2.2 5GMM消息类型速查表
NAS层消息类型非常多，但日常定位问题最常碰到的，是注册和服务请求相关的那些。这张表我建议直接存下来，抓包看到就能立刻反应出来是谁发给谁的：
| 消息类型 | 消息代码 | 方向 | 主要用途 |
|---|---|---|---|
| Registration request | 0x01 | UE → AMF | 初始注册、移动性更新、周期更新、紧急注册 |
| Registration accept | 0x02 | AMF → UE | 接受注册，下发给用户相关的GUTI、TAI list、NSSAI等 |
| Registration complete | 0x03 | UE → AMF | 确认收到GUTI等参数 |
| Registration reject | 0x04 | AMF → UE | 拒绝注册，带Reject cause |
| Deregistration request (UE orig) | 0x05 | UE → AMF | UE主动去注册 |
| Deregistration accept (UE orig) | 0x06 | AMF → UE | UE去注册确认 |
| Deregistration request (network orig) | 0x07 | AMF → UE | 网络侧踢用户下线 |
| Deregistration accept (network orig) | 0x08 | UE → AMF | 用户确认下线 |
| Service request | 0x0C | UE → AMF | UE触发服务请求，比如回数据或发信令 |
| Service accept | 0x0E | AMF → UE | 网络放通服务请求 |
| Service reject | 0x0D | AMF → UE | 网络拒绝服务请求 |
| Identity request | 0x1C | AMF → UE | 网络请求UE上报身份 |
| Identity response | 0x1D | UE → AMF | UE返回身份信息 |
| Authentication request | 0x2C | AMF → UE | 下发鉴权参数 |
| Authentication response | 0x2D | UE → AMF | UE响应鉴权结果 |
| Authentication failure | 0x2E | UE → AMF | 鉴权失败 |
| Authentication result | 0x2F | AMF → UE | 告知鉴权结果 |
| Security mode command | 0x3C | AMF → UE | 激活安全上下文，协商算法 |
| Security mode complete | 0x3D | UE → AMF | UE确认安全模式完成 |
| Security mode reject | 0x3E | UE → AMF | UE拒绝安全模式 |
Wireshark里过滤的话，可以直接用nas-5gs.message_type == 0x01只看Registration Request。这比在info列里人肉筛选快得多。
2.3 Registration Request / Accept 的关键字段，抓包必看
Registration Request是整个5G注册流程里信息量最大的一条。我拆包的时候，会重点看这几个字段：
- 5GS Registration Type：告诉网络这次是初始注册、移动性更新注册、周期注册还是紧急注册。初始注册值是1，移动性更新是2，周期更新是3。
- ngKSI：NAS密钥集标识，用来标识当前NAS安全上下文是哪一套。
- 5GS Mobile Identity：这是重中之重。首次注册时可能是SUCI，用来保护用户身份；非首次注册时多数是5G-GUTI，方便网络按上下文找回用户。
- UE Security Capability：UE支持哪些加密和完整性算法。比如5G-EA里支持NEA0、128-NEA1、128-NEA2、128-NEA3，5G-IA里支持NIA0、128-NIA1、128-NIA2、128-NIA3。网络之后下发的Security Mode Command会从这里选算法。
- Requested NSSAI：UE请求的切片列表。每个S-NSSAI由SST（切片类型）和SD（切片区分符）组成。这个字段直接影响核心网为这个用户分配哪个切片。
- PDU Session Status：告诉网络当前UE侧有哪些PDU会话还活着。做注册更新时，这个字段能帮网络回收状态。
Registration Accept的字段则体现了“网络给用户发了什么配置”：
- 5GS Registration Result：标记注册是否成功，以及是否切了NSSAI。
- TAI List：给UE分配的跟踪区列表，UE在这个范围内移动时做小区更新可以不重新注册。
- 5G-GUTI：网络给UE重新分配的临时身份，后续消息里就不再携带SUCI了。
- Allowed NSSAI：网络允许UE使用的切片集合。
- Equivalent PLMNs：若UE漫游，网络可能给出等效PLMN列表，UE可以优先选择。
排障时如果用户“注册上了但业务不通”，我通常会对比Request里的Requested NSSAI和Accept里的Allowed NSSAI，很多时候是切片没匹配上，导致PDU会话建在了一个不合适的切片上。
2.4 5GSM消息和PDU会话参数
PDU会话是用户真正跑数据的通道，5GSM消息里最常看的是PDU Session Establishment Request。它的Message Type是0xC1，Wireshark里的过滤写法是nas-5gs.message_type == 0xc1。
这条消息里值得关注的有：
- PDU Session ID：会话的本地标识，后面所有增删改查都靠它定位。
- PDU Session Type：IPv4、IPv6、IPv4v6、Ethernet还是非结构化。企业专线类业务常看到Ethernet类型。
- SSC Mode：会话与服务连续性模式，1/2/3模式对应UE移动时PDU会话保持或重建的策略。
- DNN（也叫APN概念延续）：数据网络名称，通常决定用户路由到哪个UPF、访问哪个外部网络。
- Requested QoS Rules：UE请求的QoS参数，包括5QI、GBR/MBR等。做视频类业务测试时，这个字段能直接看出端到端QoS的预期。
看这些字段的时候，脑子里要有一个业务链路意识：用户要开一个视频会话，首先得通过注册流程进网，然后发起PDU会话请求，核心网根据DNN和切片信息选择UPF，最终建立数据通道。每一步对应的NAS消息都不一样，所以抓包要按流程串起来看，不能只看单条。
2.5 用“快递单”类比理解NAS消息结构
我自己带新人时常用一个类比：NAS消息就像一张快递单。
- EPD是快递公司名，告诉你这个包裹归谁管：5GMM还是5GSM。
- Security Header Type是包装方式，是普通塑料袋还是加密保险箱——决定你拆开时能不能直接看到内容。
- Message Type是快递业务类型，是同城件、国际件还是生鲜件。
- 后面的IE就是包裹里的实际物品，每个IE有自己的编号和长度，就像快递单上的物品名称。
一旦建立了这个框架，看Wireshark协议树就是一个个“拆包裹”的过程：先看快递公司，再看包装，然后看业务类型，最后逐个解析包裹里的“物品”。这也是为什么我不建议大家死记规范里的IE顺序表，而是先理解字段功能，再用Wireshark对照验证。
3. Wireshark抓包前的准备与三种实战场景
3.1 版本选择和NAS-5GS解析器设置
Wireshark对5G NAS的支持在4.0以后比较完善，建议直接用4.2以上版本。老版本对NGAP和NAS-5GS的某些字段解析不全，比如S-NSSAI、GUTI的显示都有可能出现偏差，排查起来很别扭。
装好Wireshark后，先确认NAS-5GS的协议解析器已启用。默认情况下，只要抓到的数据里能识别出NGAP，Wireshark会自动把里面的NAS-PDU作为内嵌载荷解析出来。但如果你手动跟某条SCTP流，里面是裸NAS数据，就需要在协议首选项里检查：Edit -> Preferences -> Protocols -> NAS-5GS，确保相关选项正常。
如果抓到的文件里NGAP没有自动解析，可以在SCTP流上右键 -> Decode As，把端口38412指定为NGAP，这样Wireshark就会重新解析一次，NAS层就能出来了。这个小技巧在模拟环境里特别常用，因为有时候SCTP头比较零散，自动识别不够灵敏。
另外，为了让抓的包不被截断，去 Edit -> Preferences -> Capture 里看一眼，确认没有勾选 “Limit each packet to X bytes”。如果前面有人把这个关了但设了520字节，那你看到的每个包都只有前520字节，后面的NAS正文全丢了，协议树再点也点不出来。这种情况我遇到太多次，理由还五花八门，最后都是这一处设置改回来。
3.2 三种典型抓包场景对比
NAS消息不是凭空出现的，它得从某个接口出来。根据你手里的权限和网络环境，抓包通常有以下几种方式：
| 场景 | 抓包位置 | 工具 | 可见内容 | 适合场景 |
|---|---|---|---|---|
| 空口测试终端 | UE和gNB之间的Uu口 | 测试终端加路测软件，或手机内部日志 | 空口RRC和NAS明文/密文 | 验证端到端注册流程、业务时延 |
| 核心网N2口 | AMF与gNB之间 | tcpdump/Wireshark抓SCTP 38412端口 | NGAP和NAS-PDU字段完整 | 核心网侧定位注册和移动性问题 |
| 开源模拟环境 | 本机回环或docker网桥 | tcpdump抓loopback或虚拟网卡 | 所有NAS明文（配NEA0后） | 学习协议、调测新功能、自动化回归 |
现网N2口的抓包动作往往涉及生产维护流程，不建议自己随便在商用环境里乱抓。如果是学习目的，最推荐的就是开源模拟环境，风险低，还容易复现问题。
3.3 常用过滤器和抓包命令
我平时在模拟环境里抓N2口信令，用的命令很简单：
tcpdump -i lo -s 0 -w ngap.pcap 'sctp port 38412'这里的关键是-s 0，表示不截断包长度。如果忘了加，默认snaplen可能只保留包前一部分，回头就会发现NAS字段不全，冤枉得很。
把抓回来的ngap.pcap拖进Wireshark后，最常用的过滤条件有这些：
- 只看所有NGAP消息：
ngap - 只看NAS消息：
nas-5gs - 只看某个消息类型，比如注册请求：
nas-5gs.message_type == 0x01 - 只看注册接受：
nas-5gs.message_type == 0x02 - 看某条PDU会话建立请求：
nas-5gs.message_type == 0xc1 - 按用户GUTI关联：
nas-5gs.guti == "..."
如果用的是tshark，也可以在命令行里直接过滤：
tshark -r ngap.pcap -Y "nas-5gs.message_type == 0x01" -V这样能直接看到一条Registration Request的完整协议树，适合写脚本批量抓字段。
4. 实操解析：一条Registration Request的完整拆包过程
4.1 在Open5GS + UERANSIM环境里抓一次注册
我建议你在本地搭一套Open5GS加UERANSIM的模拟环境。UE启动后，会自动向AMF发起初始注册请求。这时候在宿主机上跑tcpdump抓loopback，就能抓到完整的NGAP和NAS消息。
为了保证加密消息也能明文看到，可以在Open5GS的AMF配置和UERANSIM的gnb配置里把安全算法都配成NIA0/NEA0。这样从开机注册到PDU会话建立，所有NAS消息都保持明文，对学习协议字段非常友好。
抓完包后，Wireshark里执行：
nas-5gs你会看到一列UE和AMF之间的NAS消息，时间顺序大致是：Registration Request -> Authentication Request/Response -> Security Mode Command/Complete -> Registration Accept -> Registration Complete，之后可能还有PDU Session Establishment相关消息。
4.2 逐字段拆解Registration Request
Wireshark里双击一条Registration Request，展开协议树后大概是这种感觉：
NAS-5GS Extended protocol discriminator: 5G mobility management (126) Security header type: Plain NAS, not security protected (0) NAS message type: Registration request (0x01) 5GS registration request 5GS registration type: Initial registration (1) ngKSI: 0 5GS mobile identity Mobile identity: ... ...... UE security capability 5G-EA: 128-NEA1 128-NEA2 128-NEA3 5G-IA: 128-NIA1 128-NIA2 128-NIA3 Requested NSSAI S-NSSAI 1 SST: 1 (eMBB)我拆这种包时，并不是每个字段都停下来看，而是按业务目的来选。第一次注册场景，我会看三件事：注册类型是不是Initial；身份标识是SUCI还是GUTI；UE支持的安全算法有哪些。
比如你看到Mobile Identity里是一个长串SUCI，这说明UE这轮注册还没拿到GUTI，AMF需要通过后续流程给UE下发GUTI。如果你看到的是5G-GUTI，那说明UE之前注册过，AMF可以用这个GUTI查上下文，免掉一部分鉴权流程。
Requested NSSAI字段也很关键。模拟环境里默认配一个SST=1的切片，通常会显示为eMBB。如果UE请求的NSSAI和AMF允许的NSSAI对不上，注册请求走到后面就可能被Reject。抓包里看到这个字段，基本能判断切片配置方向性问题。
4.3 再看Registration Accept与后续交互
Registration Accept通常跟在鉴权和安全模式之后。Wireshark里展开后，重点关注：
- 5GS Registration Result：显示Registration result value，确认注册成功。
- TAI List：AMF给UE圈定的跟踪区，UE在这个范围内移动不用频繁注册更新。
- 5G-GUTI：AMF分配的新临时标识，UE应在Registration Complete里确认。
- Allowed NSSAI：网络允许的切片集合。
如果看到Allowed NSSAI里没有UE请求的切片，那基本就是网络侧切片配置或订阅数据的问题。这时候别光盯NAS消息，得去AMF的日志里查切片选择逻辑。
再往后，UE会回一条Registration Complete，消息很短，主要用来确认收到GUTI。然后UE如果想跑业务，会再发起PDU Session Establishment Request，进入5GSM流程。
4.4 如何顺着信令流把一次注册过程串起来
抓包的意义不只是看单条消息，而是要看完整流程。我在Wireshark里习惯这样操作：
- 先用
nas-5gs过滤出所有NAS消息。 - 显示列里把 Time、Source、Destination、Info 显示完整。
- 从第一条Registration Request开始，按时间顺序往下刷。
刷的过程中，你会发现每条NAS消息的前后依赖：
- Registration Request发出后，AMF会回Authentication Request，前提是AMF需要对这个用户做鉴权。
- 鉴权通过后，AMF下发Security Mode Command，协商安全算法。
- 安全上下文建立后，AMF才能安全地下发Registration Accept，里面带着GUTI和TAI List。
- UE回复Registration Complete后，注册流程才彻底闭环。
如果中间某条消息没出现，或者出现Reject，Wireshark的Info列里一般会直接显示原因，比如 Registration reject。这时候点进去看Cause值，再回到核心网日志里定位，基本能锁定问题。
4.5 用tshark提取关键字段做自动化巡检
除了在Wireshark界面里一条条看，我还会用tshark把NAS字段提取出来，做成自动化巡检脚本。比如想检查一批抓包里所有Registration Request的注册类型和UE安全算法：
tshark -r ngap.pcap -Y "nas-5gs.message_type == 0x01" -T fields \ -e frame.number \ -e nas-5gs.registration_type \ -e nas-5gs.ue_security_capability输出结果会是一个表格，方便直接拉到Excel里对比多次抓包差异。这个习惯在跑回归测试时特别有用，不然每次都手动打开Wireshark点来点去，效率太低了。
5. 常见拦路问题与排错速查
5.1 抓包文件里看不到NAS解析
现象：打开pcap后，Info列只显示NGAP，不显示NAS-5GS，协议树里也找不到NAS-PDU字段。
原因和处理办法：先确认包是通过SCTP的NGAP端口传的，默认端口是38412。如果端口不对，Wireshark不会自动识别。这时候选中那条SCTP流，右键选择Decode As，把端口指定为NGAP，NAS层就会重新解析出来。
如果是纯NAS数据没有NGAP封装，那就直接在Decode As里指定NAS-5GS，或者检查协议首选项里的NAS-5GS是否关闭了。
5.2 Wireshark只显示520字节，后面的内容全没了
这是老生常谈但特别容易踩的坑。现象是包列表里能看到一条注册请求，点开后协议树到某个字段就断了，后面的IE全部缺失。
原因：抓包时snaplen被限制为520字节，或者Wireshark捕获选项里开了“Limit each packet to X bytes”。
处理办法：
- 检查 Edit -> Preferences -> Capture，把包长度限制关掉。
- 用tcpdump重新抓包时带
-s 0，表示不限制。 - 如果已经抓完的pcap被截断了，没法补回缺失字节，只能重新抓。
我建议每次抓包前都先确认snaplen设置，尤其在生产环境或长时间后台抓包时，一个小设置会浪费几个小时排查时间。
5.3 注册流程后面的NAS消息全是密文
现象：Security Mode Command之后的消息，Wireshark显示Security Header Type为2，内容变成类似乱码的加密载荷。
原因：这是正常现象。5G网络在安全模式激活后会对NAS消息做完整性和机密性保护，没密钥的抓包工具无法解密。
处理办法：
- 学习环境：把模拟核心网和UE的安全算法都配置成NIA0/NEA0，即可看到明文。
- 测试环境：如果需要验证加解密逻辑，得从核心网侧导出密钥材料，但这属于专业测试工具范围，一般排障用不到。
在真实商用环境里，NAS密文是用户隐私保护的一部分。做协议分析时，记住“看到加密不代表抓错”，而是流程已经进入安全状态了。
5.4 长时间抓包很卡，或文件巨大打不开
现象：跑业务压测时用Wireshark直接抓包，十分钟后Wireshark卡死，pcap文件几个GB。
原因：Wireshark把每个包都解析到UI层，量大时性能撑不住。
处理办法：
- 用dumpcap或tcpdump先抓原始包，不要直接开Wireshark实时抓。
- 抓包时用capture filter缩小范围，只抓SCTP 38412端口或特定IP。
- 按时间或按大小分文件保存，比如
tcpdump -G 60 -W 100 -w ngap_%Y%m%d_%H%M%S.pcap，每分钟一个文件，总共最多100个。 - 分析时先用
tshark -r过滤出NAS消息，再导入Wireshark看结果，避免一次性加载巨包。
5.5 怎么看UDP前后两包的时间间隔
这个需求在做时延分析和流控排查时经常遇到。Wireshark默认在显示列里带一个Time，可以设置为frame.time_delta_displayed，就是相邻显示包的时间差。
如果只想筛出间隔超过某阈值的UDP包，可以直接用显示过滤器：
udp && frame.time_delta_displayed > 0.05这会把显示出来的UDP包中前后间隔大于50毫秒的包过滤出来。如果是在5G用户面抓GTP-U包，这招可以快速定位有没有明显的传输间隙。
5.6 NAS消息的移动性和时间关联问题
有时候注册流程看起来一切正常，但用户在移动过程中掉线。这种情况下，只抓NAS消息还不够，要把AMF日志、gNB日志和Wireshark抓包时间对齐来看。
我通常的做法是：
- 在Wireshark里按
frame.time导出NAS消息时间戳。 - 与AMF的注册日志按时间匹配。
- 先看是由哪条NAS消息触发的异常，比如Deregistration Request，再看网络侧当时的切换或重注册状态。
时间对齐这件事，看起来笨，但却是最可靠的分析路径。很多协议栈问题并不是单条消息格式错误，而是多条消息之间的状态迁移出了岔子。
6. 从抓包到排障：我的一点体会
NAS消息解析这件事，上手门槛不在字段多，而在于你能不能把一条消息放进完整的信令流程里去看。我见过不少同事能背字段表，但真到排障时，抓了一堆包不知道从哪里看起。我的建议很简单：拿到一个pcap，先别急着查细节，先把nas-5gs过滤出来，按时间顺序浏览一遍，看流程走到的哪一步断了，再从断点那一条消息的字段里找原因。
如果要在模拟环境里练手，我强烈建议你亲手跑通一次完整注册，抓包后把Registration Request、Registration Accept、PDU Session Establishment Request三条消息的协议树截图留档。截图的过程其实就是逼自己把每个字段过一遍，比只看教程效果好太多。
我自己踩过最大的坑，就是刚开始抓包时没注意snaplen，抓回来的包只有520字节，以为协议栈有问题，查了一整天才发现是抓包配置的问题。从那以后，我每次抓包前都会检查两件事：snaplen有没有设对，端口过滤有没有写对。这两点看起来不起眼，但能省掉后面一大半的无效劳动。
最后再分享一个小习惯：抓包文件命名一定要带上时间和接口信息，比如ngap_20250925_amf_lo.pcap。时间久了你就知道，规范的命名比任何笔记都管用。
