简介：这份文档面向移动通信初学者、通信工程专业学生及希望系统梳理5G信令流程的从业者，围绕5G信令解析所需的核心概念与学习路径展开，帮助读者建立从网络架构到流程环节的整体认知框架。内容涵盖用户终端、基站、核心网等关键网元之间的通信关系，区分控制信令与用户数据信令，并梳理接入、鉴权与安全、移动性管理、资源分配与调度、服务质量保障等流程环节，同时给出系统学习、深入理解、实践操作、案例分析与持续跟进等学习技巧。资源包共1个docx文档，约11KB，结构紧凑，适合作为入门梳理与复习提纲使用。目前已有402人学习下载，可作为理解5G信令流程、规划后续深入学习的参考材料。
1. 5G信令流程解析：从“黑匣子”到能上手抓包的第一课
很多人第一次接触5G信令流程解析，都是被一张密密麻麻的流程图劝退的：几十条箭头、一堆英文缩写、还分NSA和SA两套。但真正做过网络优化或者核心网排障的人都知道，信令流程不是背出来的，是“看”出来的——你只要能抓到一次完整的注册流程，把每条消息的时间戳、方向、关键IE对上，后面所有场景都是这套逻辑的变体。这篇笔记面向两类人：一是刚入行、需要快速建立信令框架的网优或核心网工程师；二是做终端、模组、物联网平台，需要定位“为什么附着不上”“为什么切换失败”的开发者。我会按“先立框架、再动手抓、最后讲排错”的顺序，把5G信令流程解析拆成能复现的步骤，参数怎么设、坑在哪，都写清楚。
2. 先把框架立住：5G信令流程到底分几层、谁在说话
2.1 控制面与用户面：别把N1和N2搞混
5G信令流程解析的第一个门槛，是分清楚“谁和谁在说话”。终端（UE）和接入网（gNB）之间的信令走空口，叫Uu接口；gNB和核心网AMF之间的信令走N2接口；UE和AMF之间的非接入层信令叫NAS，它虽然逻辑上是端到端的，但实际消息要穿过gNB透传。很多新手看抓包文件时，看到NAS消息被包在NGAP消息里就懵了，其实这就是“透传”两个字的意思。
我一般会用一个简单的判断法：看抓包文件的协议栈列。如果最外层是NGAP，里面套着NAS，那就是N2接口的抓包；如果最外层是RRC，里面套着NAS，那就是空口抓包。两者看到的消息内容有重叠，但视角完全不同。做核心网排障，重点看N2；做无线侧排障，重点看Uu。这个区分立住了，后面看流程才不会串线。
2.2 注册流程的七条关键消息：从RRC建立到注册完成
5G信令流程解析里最核心、也最常被问到的就是初始注册流程。我把它压缩成七条关键消息，按时间顺序排：
- RRC Setup Request / RRC Setup（空口第一条，UE发起）
- RRC Setup Complete（里面带NAS Registration Request）
- Initial UE Message（gNB把NAS消息通过N2发给AMF）
- Authentication Request / Response（鉴权，NAS层）
- Security Mode Command / Complete（安全模式，NAS层）
- Initial Context Setup Request（AMF让gNB给UE建上下文）
- Registration Accept / Complete（注册接受，流程收尾）
这七条里，第3条和第6条是N2接口的NGAP消息，其余是NAS或RRC。实际抓包时，你可能会看到多条重传或并行消息，但主线就这七条。把这七条的时间戳和关键IE记住，再看切换、去注册、PDU会话建立，都是在这个骨架上加分支。
2.3 NSA与SA的信令差异：为什么NSA抓不到完整的NAS流程
NSA（非独立组网）和SA（独立组网）在信令上的最大区别是：NSA的控制面锚点还在4G，5G只是用户面增强。所以你在NSA场景下抓空口，能看到NR的RRC消息，但NAS消息仍然走LTE的MME，不会出现完整的5G注册流程。很多新手拿着NSA的抓包找“Registration Request”，翻半天找不到，就是没搞清这个前提。
判断方法很简单：看系统消息里的IE。如果SIB2里带了NSA相关的配置，或者UE先接入LTE再添加NR小区，那就是NSA。SA场景下，UE直接在NR上发起RRC建立，NAS消息完整走5G核心网。做5G信令流程解析，建议先从SA抓包入手，流程最干净，没有4G/5G互操作的干扰。
3. 动手抓一次：用开源工具在本地复现5G信令解析环境
3.1 工具选型：为什么我常用srsRAN加Wireshark
要复现5G信令流程解析，最省成本的方案是用开源基站软件加抓包分析。我一般会选srsRAN（开源5G基站实现）配合srsUE（开源终端），跑在本地两台Linux机器或者一台性能足够的机器上，中间用虚拟网卡连接。核心网可以用Open5GS或free5GC，都是开源实现，能跑通完整的注册流程。抓包用Wireshark，它自带NGAP和NAS的解析器，能直接把二进制消息翻译成可读的IE树。
这个组合的好处是：所有消息都在你控制下，可以反复抓、反复看，不像现网那样只能看不能动。缺点是配置项多，第一次搭环境容易卡在某个参数上。下面我给一个最小可跑的配置片段，重点讲参数含义。
3.2 最小可跑配置：核心网和基站的对接参数
以Open5GS为例，AMF的配置文件里需要关注几个关键项：
# amf.yaml 关键片段 amf: ngap: - address: 127.0.0.5 # AMF的N2接口地址，gNB要连这个 guami: - plmn_id: mcc: 001 mnc: 01 amf_id: region: 2 set: 1 tai: - plmn_id: mcc: 001 mnc: 01 tac: 1 # 跟踪区码，要和gNB配置一致gNB侧的配置（以srsRAN为例）需要对应：
# gnb.yml 关键片段 gnb_id: 0x12345 plmn: "00101" # 必须和AMF的PLMN一致 tac: 1 # 必须和AMF的TAC一致 amf: addr: 127.0.0.5 # 指向AMF的N2地址 bind_addr: 127.0.0.1 # 本地绑定地址逻辑说明：PLMN和TAC是网络身份标识，两边不一致会导致NGAP建立失败，抓包会看到NG Setup Failure。AMF地址是gNB主动去连的，所以gNB配置里写AMF的地址，AMF配置里写自己监听的地址。这两个参数对不上，后面所有流程都跑不起来。
参数说明：MCC和MNC组成PLMN，测试环境常用00101；TAC是跟踪区码，同一个TAI列表里的小区可以共享寻呼资源。实际调的时候，先把这两个对齐，再检查IP可达性。
3.3 抓包点选择：在N2和Uu之间怎么选
抓包位置决定了你能看到什么。如果你想看完整的NAS流程，最好在N2接口上抓，因为gNB会把NAS消息透传给AMF，Wireshark能直接解析出Registration Request、Authentication Request这些消息。如果你想看空口资源分配，那要在Uu接口抓，需要支持空口抓包的设备或软件。
我一般会同时在两个点抓：N2上抓NGAP+NAS，Uu上抓RRC。然后按时间戳对齐，看一条NAS消息发出后，空口上对应的RRC重配是什么。这样能建立“信令触发—空口动作”的对应关系。注意：N2抓包时，如果gNB和AMF之间走了加密，NAS消息可能被加密，Wireshark解不出来。测试环境一般关掉加密，或者把密钥配到Wireshark里。
3.4 第一次解析：用Wireshark过滤出注册流程
抓完包，在Wireshark里用过滤器ngap || nas-5gs就能把5G信令相关消息筛出来。然后按时间顺序看，找到第一条Initial UE Message，右键选择“Follow NAS-5GS Stream”，就能看到完整的NAS消息序列。
关键IE要重点看：Registration Request里的5GS Mobile Identity（SUCI或5G-GUTI）、UE Security Capability；Authentication Request里的RAND和AUTN；Security Mode Command里的Selected NAS Security Algorithms。这些IE决定了后续流程能不能走通。比如SUCI里的加密算法如果和AMF支持的不匹配，鉴权就会失败，抓包会看到Authentication Failure。
4. 参数与消息细节：把每条关键IE对到实际排障场景
4.1 5GS Mobile Identity：SUCI和5G-GUTI什么时候用哪个
5GS Mobile Identity是注册请求里最重要的IE之一。第一次注册时，UE没有临时标识，只能用SUCI（加密后的永久标识）。AMF收到SUCI后，会去UDM做鉴权，然后分配一个5G-GUTI给UE。后续再注册时，UE就用5G-GUTI，AMF能直接定位到上下文，省去鉴权步骤。
排障时，如果看到UE一直用SUCI发起注册，说明它没拿到或没保存5G-GUTI。可能原因：AMF没下发、UE没存、或者UE重启后丢了。这时候要看Registration Accept里有没有带5G-GUTIIE。如果没有，检查AMF配置里是否允许分配GUTI。
4.2 鉴权向量：RAND和AUTN不匹配会怎样
鉴权流程是5G信令流程解析里最容易翻车的地方。AMF从UDM拿到鉴权向量（RAND、AUTN、XRES），把RAND和AUTN发给UE，UE用SIM卡里的密钥算出RES和AUTN，比对AUTN是否正确，然后回RES。AMF比对RES和XRES，一致就通过。
常见坑：AUTN里的SQN（序列号）不同步。UE会认为这是重放攻击，回Authentication Failure，原因值Synch failure。这时候需要看UE和UDM的SQN管理机制，测试环境可以重置SQN。另一个坑是算法不匹配，比如UDM用Milencage，UE只支持XOR，那也会失败。抓包里看Authentication Response的原因值，能快速定位。
4.3 PDU会话建立：和注册流程怎么衔接
注册完成后，UE要建立PDU会话才能上网。PDU会话建立流程走NAS的PDU Session Establishment Request，AMF会选一个SMF，SMF再选UPF，然后通过N4接口配置用户面。抓包时，你会看到NAS消息里套着PDU Session Establishment Accept，里面带QoS Rules和Session-AMBR。
排障时，如果PDU会话建立失败，先看PDU Session Establishment Reject的原因值。常见的有：Insufficient resources（UPF资源不够）、Missing or unknown DNN（DNN配错）、User authentication failed（二次鉴权失败）。DNN配错是最常见的，检查SMF配置里的DNN列表和UE请求的是否一致。
5. 避坑与排查：5G信令流程解析里最容易踩的五个坑
5.1 抓包文件里看不到NAS消息
现象：Wireshark里只看到NGAP消息，展开后没有NAS层。 原因：N2接口的NAS消息被加密了，或者抓包点不对，抓的是加密后的SCTP载荷。 解决：测试环境关掉NAS加密，或者在Wireshark里配置NAS解密密钥。检查抓包点是否在gNB和AMF之间的明文链路上。
5.2 NG Setup Failure：PLMN或TAC不一致
现象：gNB和AMF建立NGAP连接时失败，抓包看到NG Setup Failure。 原因：gNB配置的PLMN/TAC和AMF配置的不一致。 解决：逐项核对两边的MCC、MNC、TAC，确保完全一致。注意PLMN的格式，有的工具写“00101”，有的写“001-01”，要统一。
5.3 注册流程卡在鉴权阶段
现象：UE发出Authentication Response后，AMF没有回Security Mode Command。 原因：RES和XRES不匹配，或者AUTN验证失败。 解决：看Authentication Response里的原因值。如果是Synch failure，检查SQN；如果是MAC failure，检查密钥和算法。测试环境可以抓UDM的日志，看它生成的向量和UE算的是否一致。
5.4 切换失败：Xn接口没建起来
现象：UE在基站间移动时，切换准备失败，抓包看到Handover Preparation Failure。 原因：Xn接口没配置或不可达，或者目标基站没有UE的上下文。 解决：检查Xn接口的IP连通性和配置。如果Xn不可用，可以走N2切换，但需要AMF参与，流程更长。抓包里看Handover Required和Handover Request的方向，判断走的是Xn还是N2。
5.5 Wireshark解析异常：版本不匹配导致IE解析错误
现象：Wireshark把某个IE解析成未知类型，或者解析出的值和实际不符。 原因：Wireshark的NGAP/NAS解析器版本和抓包时的协议版本不一致。 解决：升级Wireshark到最新版，或者在首选项里手动指定协议版本。如果还是不行，用十六进制视图对照3GPP规范手动解析关键字段。
6. 进阶技巧：用脚本批量提取信令消息并做时序分析
当你抓了几十个包之后，手动看效率太低。我一般会写一个Python脚本，用pyshark库批量提取关键消息的时间戳和类型，然后输出成表格，方便对比不同场景的时序差异。
import pyshark def extract_nas_flow(pcap_file): cap = pyshark.FileCapture(pcap_file, display_filter='nas-5gs') flow = [] for pkt in cap: if hasattr(pkt, 'nas_5gs'): msg_type = pkt.nas_5gs.get_field('nas_5gs.mm.message_type') timestamp = float(pkt.sniff_time.timestamp()) flow.append((timestamp, msg_type)) cap.close() return flow # 输出按时间排序的消息列表 for ts, msg in sorted(extract_nas_flow('register.pcap')): print(f"{ts:.3f} {msg}")逻辑说明：display_filter='nas-5gs'只抓NAS消息，message_type字段能区分注册请求、鉴权请求等。时间戳用sniff_time转成浮点数，方便算消息间隔。参数说明：pcap_file是抓包文件路径，脚本依赖pyshark和tshark，运行前确保Wireshark安装目录在PATH里。
拿到时序表后，重点看两个指标：注册流程总时长（从RRC Setup Request到Registration Complete）和鉴权往返时延（Authentication Request到Response）。正常SA注册在1秒内完成，如果超过2秒，检查空口质量和核心网处理时延。我习惯把不同场景的时序表放一起对比，比如正常注册、弱覆盖注册、跨AMF注册，差异一眼就能看出来。
最后说一个我自己的教训：刚开始做5G信令流程解析时，我总想一次看懂所有IE，结果每个都查规范，效率极低。后来改成“先看消息类型和方向，再看关键IE，最后查异常原因值”，速度快了很多。信令流程是活的，抓一次比背十遍规范管用。希望帮到你。
本文还有配套的精品资源，点击获取
