5G信令流程解析：注册、PDU会话与切换的实战排查指南

简介：《5G信令流程解析》面向通信工程学生、网络工程师与5G技术爱好者，聚焦5G网络中复杂而关键的信令交互机制，系统梳理从终端接入、会话建立到数据传输的完整链路。资源对设备接入流程中的身份验证、鉴权与RRC连接建立，会话建立中的核心网激活与PDU会话创建，以及数据传输阶段的QoS协商、流量控制等关键环节均作了明确讲解，并归纳了5G信令流程复杂性、高效性、安全性等特点，以及兼容性、资源管理、安全威胁等现实挑战，有助于读者建立对5G网络运作机制的整体认知。包内为1个pdf文档，压缩包约105KB，轻量便于随时查阅。该资料已有254人学习浏览，是快速入门5G信令流程、补充移动通信知识脉络的实用参考资料。

1. 一份 5g信令流程解析.pdf：为什么值得逐行读，而不是收藏吃灰

做核心网联调的人都有这种体会：UE 附着失败时，翻协议文本和翻一份按流程组织的 5g信令流程解析.pdf，效率完全不同。前者按功能拆章节，你得把几十页自己拼成一条时间线；后者已经按注册、PDU 会话建立、切换把消息顺序排好，字段、方向、原因值都在一张图里。这份文档不是入门教材，而是排查故障时的参照系。适合两类人：刚转 5G 的测试工程师，需要快速建立消息、接口、网元的对应关系；联调现场被问题卡住的开发者，需要判断是无线侧没建承载、核心网拒绝了请求，还是信令流程压根没走通。下面我从读法、抓包、踩坑到验证环境，把这份文档真正用起来。

2. 读信令文档前先立住三大流程主线：注册、PDU 建立与移动切换

一份 5g信令流程解析.pdf 里通常是一张接一张的交互图，第一次打开容易被网元之间的箭头淹没。我的习惯是先把细节放下，把三类最基础的流程在脑子里搭出骨架：开机注册、PDU 会话建立、移动性切换。其余的信令，比如服务请求、去注册、区域更新，基本都是这三条的变体。骨架立住以后再往里面填字段，就不容易看乱。

2.1 注册流程：从 RRC Setup 到 Registration Accept 的关键帧

先看注册。UE 开机后跟 gNB 之间先走 RRC 连接，RRCSetupComplete 里叠着第一张关键 NAS 消息 Registration Request。注意这条消息携带的是 SUCI 而不是明文身份，这是 5G 与 4G 最直观的区别。gNB 把它包在 NGAP 的 InitialUEMessage 里传给 AMF，AMF 拿到后决定走完整鉴权还是直接接受。

读这一节时重点不是背消息名，而是看两条路径：UE 和 AMF 之间的 NAS 对话是通过 gNB 透传的，gNB 自己能读懂的是 RRC 和 NGAP。凡是穿越 Uu、N1、N2 三层的消息，先在脑子里标一下哪一跳是透传、哪一跳是真正处理，这是新手最容易混乱的地方。我看 PDF 时习惯在注册页眉上直接写一句话：gNB 是信令的搬运工，AMF 是注册流程的大脑。

2.2 PDU 会话建立：从 NAS 请求到 DRB 落地的数据面路径

PDU 会话建立是用户面打通的关键一步。UE 发 PDU Session Establishment Request，带上 S-NSSAI、DNN 和 PDU Session ID。AMF 不是一个人把活干完，它把请求转给 SMF，SMF 选择 UPF 并建立 N4 会话，然后 AMF 通过 NGAP 的 PDU Session Resource Setup Request 把 QoS Flow 描述下发给 gNB。gNB 把 QoS Flow 映射到空口 DRB，通过 RRC Reconfiguration 配置给 UE，数据面才算真正通。

文档里 PDU 会话建立通常按完整时序展开，但现场最常见的现象是“会话建立成功，用户依然没网”。问题往往不在 NAS 层，而在这张 QoS Flow 到 DRB 的映射表里。我把这一页单独折角，排错时先核对它，再去查空口和核心网的承载是否对得上。

2.3 切换流程：Xn 切换与 N2 切换在文档里的两条路

切换分两大类。Xn 切换是 gNB 之间直接交互，核心网在切换完成后收到一条路径迁移通知，把下行数据路径切到新 gNB；N2 切换则从头到尾有 AMF 参与，两条路的差异直接决定故障排查边界。读 PDF 时出现 Handover Preparation、Handover Resource Allocation 这类名称，属于 N2 流程；看到 XnAP 域的 Handover Request，就是 Xn 流程。

判断有个技巧：切换消息按准备、执行、路径迁移三块看。准备阶段失败，大概率是目标小区资源或准入策略问题；执行阶段失败，重点看 UE 侧随机接入；路径迁移阶段失败，去看核心网侧用户面承载是否更新。文档的章节顺序也基本按这三个阶段排，拿阶段去对照流程图，定位会比逐条读快很多。

3. 把 PDF 里的信令流程变成抓包取证：从字段名到过滤器的落地

PDF 给你的是逻辑顺序，现场给你的是 pcap，两者之间需要一道翻译。学会把流程文档里的消息名翻译成抓包里的过滤条件，是文档从“看得懂”走向“用得上”的分水岭。下面用几个接地气的命令和对照表，示范怎么做这道翻译。

3.1 用 tshark 把 NGAP 消息从 pcap 里拉出来：最小命令与字段选择

拿到一份现场 pcap，第一步不是打开图形界面，而是先用命令行把 NGAP 消息拉出来看有哪些帧。

# 列出 pcap 里所有 NGAP 帧，先看概览：帧号、时间、消息描述 tshark -r 5g_attach.pcapng -Y "ngap" -T fields -e frame.number -e frame.time -e _ws.col.Info -E separator=, | head -30 # 叠加空口 NAS 消息一起导出，文件名里的 nas-5gs 是 5G NAS 协议名 tshark -r 5g_attach.pcapng -Y "ngap || nas-5gs" -T fields -e frame.number -e frame.time -e _ws.col.Info | head -60

第一条命令里-Y "ngap"是显示过滤器，只保留 NGAP 协议帧；-T fields打开字段输出模式，-e指定要打印的字段，_ws.col.Info是抓包工具预置的信息列文本，会显示类似 InitialUEMessage 或 PDU Session Resource Setup 这样的消息名。-E separator=,让输出用逗号分隔，方便后续导入表格。

第二步如果需要精确定位某条流程，比如初始注册里的 InitialUEMessage，直接配合系统命令过滤消息名：

tshark -r 5g_attach.pcapng -Y "ngap" -T fields -e frame.number -e frame.time -e _ws.col.Info | grep -i "InitialUE"

这里用 grep 匹配消息名，而不是用协议字段的数值条件，原因是不同版本的抓包工具对 NGAP Procedure Code 的字段拼写不一致，直接在界面里点开消息树右键生成过滤条件更可靠。老版本里 NAS 5GS 协议名写作 nas_5gs，新版本统一成 nas-5gs，导入 pcap 后先在消息树里确认字段名再写过滤器，能省下不少反复试错的时间。

3.2 从文档字段表到排查清单：先看这四个必查项

信令文档里字段很多，现场排错不需要全部看懂，先盯住四个必查项：注册类型、切片标识、PDU 会话 ID、Cause 值。这四个字段决定了流程预期、准入边界、对账主线和下一步去哪查。

为什么是这四个而不是别的？注册类型决定你这个流程按什么预期去核对，切片决定核心网要不要你，PDU 会话 ID 是把多段信令串成一条会话的账本，Cause 值则告诉你下一步去哪个网元要日志。读 PDF 时把这四个字段在文档里画圈，现场排查时就能少翻一半协议。

3.3 字段级对照：一个 NAS Registration Request 从字面到字节的核对方法

有些场景下字段名对了还不够，比如终端和网络对某个 IE 的理解不一致，就得回到字节级核对。我一般会把 pcap 里的原始字节导出来，对照文档里的字段顺序表逐字节填一遍。

# 导出 NAS 消息的十六进制原始字节，配合协议解析逐段核对 tshark -r reg_attach.pcapng -Y "nas-5gs" -x | head -40

-x参数让 tshark 同时输出每一帧的十六进制和 ASCII 视图。第一次做逐字节对照很费时间，但做过一次你对协议头长度的理解会完全不同。常见坑是把 5GMM 头的 message type 和 5GSM 消息的 message type 混在一起看，长度怎么数都对不上。记住一个粗粒度规律：5GMM 的协议描述符一般是 7e 开头，PDU 会话相关的 5GSM 消息一般是 2e 开头，拿这个做初步分层，再数长度就不容易乱。

4. 5G 信令排查里常见的 5 个翻车点：原因值、上下文与定时器

信令排查翻车，翻得最多的不是协议看不懂，而是现象与原因之间隔着一层“看似正常”。下面五条是我在联调现场反复遇到的真实场景，每条按现象、原因、解决三步写，供你直接对照。

4.1 NAS 层一直重发 Registration Request，log 里却没有原因值

现象：UE 每隔几秒重发一次 Registration Request，网元侧日志只有收到记录，没有任务拒绝原因。看起来像是消息丢了，但又不知道丢在哪。

原因：绝大多数情况是安全上下文没建立起来，AMF 挂不起后续流程；另一种常见情况是 UE 携带的 5G-GUTI 在 AMF 里查不到，触发 Identity 流程后响应没有匹配上，流程中断在半路。

解决：先看抓包里有没有 Security Mode Command，没有就说明安全流程没走到。再看 AMF 侧 UE 上下文是否存在。最笨但有效的方法是把卡里的 GUTI 清掉，让 UE 用 SUCI 重新走一次完整注册，流程会立刻变清楚。这一步能区分终端残留状态和网络侧上下文丢失。

4.2 PDU 会话建立被拒：文档原因值和抓包里的 Cause 对不上

现象：文档里写某个 Cause 值表示资源不足，抓包里显示的数值却与文档对不上，怀疑自己看错了文档。

原因：不同协议层有各自的 Cause 空间。NAS 5GMM、5GSM、NGAP 是三个不同的枚举，PDF 表格通常只列 NAS 层的值，而抓包默认显示的是 NGAP 层的 Cause，两者本就不该相等。

解决：先在抓包界面展开最内层的 NAS 消息，找到 5GSM Cause 或 5GMM Cause 再做对照；如果 NAS 层没有携带 Cause，去 AMF 或 SMF 的接口日志里找原因，N11 或 N4 接口上的失败原因往往才是根因。多层的 Cause 分开查，能避免白折腾。

4.3 切换后数据断流，但信令流程图上每一步都是绿的

现象：Xn 切换流程全部成功，UE 也重同步到目标小区，但业务从切换那一刻开始就不通，用户面静默中断。

原因：最常见的根因是路径迁移没生效。新 gNB 向核心网发送了路径切换请求，但核心网侧没有把下行方向的隧道标识更新掉，旧 gNB 仍在收下行数据；或者旧路径上的用户面承载没有被释放，数据在环形路径上转发。

解决：在空口和核心网侧同时抓包，看下行 GTP-U 报文里的隧道标识是否已经切换成新 gNB 的。如果指向旧 gNB，把路径切换消息和用户面网元的建流日志并排看，就能定位到是哪一跳没更新。信令全绿不代表用户面全通，数据面和控制面要分开验证。

4.4 QoS Flow 建好了业务体验没起来：DRB 映射与 SDAP 头丢了

现象：PDU 会话和 QoS Flow 都建立成功，但业务速率上不去，或者高优先级数据的时延没有达到预期，终端和网络都显示一切正常。

原因：QoS Flow 和 DRB 不是一一对应。多个 Flow 复用同一个 DRB 时，靠 SDAP 头的 QFI 区分上下行数据，如果 gNB 下发的 RRC 配置里的映射表与核心网下发的 QoS Flow 描述不一致，收端按错误的 QFI 往上送，数据就直接丢了。

解决：把 RRC Reconfiguration 里的 SDAP 配置和 NGAP 下发的 PDU Session Resource Setup Request 里的 QoS Flow 描述并排看，核对 QFI 与 DRB 的映射关系。文档上画得干净，现场配置一旦有厂商差异，问题就藏在“两个表对不上”之间。

4.5 把日志时间戳当成信令时序，流程看起来是乱的

现象：跨网元拿到两份日志，按时间排序后流程前后颠倒，总以为丢了消息，反复重抓却找不到问题。

原因：分布式抓包的时间基准不同步。跨服务器、跨机房时，时间戳差几百毫秒甚至几秒都很正常，直接按时间排序会把一条完整流程拆成两半。

解决：不要用时间排序，用消息自带的关联标识排序。NGAP 里有 gNB UE NGAP ID 和 AMF UE NGAP ID，同一对 ID 才是同一条流程。时间戳只用来确认消息间隔是否异常，不作为先后顺序的依据。这个习惯要从第一次读流程就养成。

5. 把 PDF 的知识变成可复现检查单：用最小环境走通验证

只看文档记不牢，最有效的办法是让信令真实跑一遍。搭一个最小验证环境，把文档里的注册和 PDU 会话建立流程走通，再结合一条自动核对脚本，这条学习路径比反复读十遍 PDF 都管用。

5.1 搭一个最小核心网环境：让文档里的消息真实跑一遍

我一般会在本地起一个轻量的信令验证环境，一台机器部署模拟的 AMF、SMF、UPF 功能，配合模拟接入网和终端模拟器，把完整的注册流程跑一遍。跑通之后，PDF 里的每一张交互图都变成了能暂停、能单步看的真实状态机。

以配置文件的一个片段为例，说明关键参数怎么设：

# 信令验证环境核心网网元配置片段 amf: region: 1 set: 1 tai_list: - { mcc: "001", mnc: "01", tac: 1 } allowed_s_nssai: - { sst: 1, sd: "000001" } smf: dnn: "internet" upf: ip: "192.0.2.10" teid_range: [1000, 2000]

这里有几个参数容易踩坑。S-NSSAI 的 SD 值是十六进制字符串，写成十进制会直接导致切片配置解析失败；TAI 列表必须和模拟基站上报的小区信息一致，不一致会触发区域拒绝；TEID 范围给得太小，多用户并发注册时会分配冲突。用这套配置跑一遍注册和 PDU 建立，大约半小时就能让文档里的主流程成为肌肉记忆。

5.2 把 PDF 检查项变成自动核对脚本：从期望流程到比对结果

每次手动核对流程费眼睛，我把文档里的流程顺序写成一个简单的核对脚本，用抓包导出的消息列表做输入，自动检查主流程是否完整。

# 简易信令流程核对：期望序列 vs 实际导出序列 expected = [ "RRCSetupComplete", "InitialUEMessage", "AuthenticationRequest", "AuthenticationResponse", "SecurityModeCommand", "SecurityModeComplete", "InitialContextSetupRequest", "RegistrationAccept", ] import sys def main(actual_seq_file: str) -> None: with open(actual_seq_file, encoding="utf-8") as f: actual = [line.strip() for line in f if line.strip()] pos = 0 for msg in actual: if pos < len(expected) and msg == expected[pos]: pos += 1 if pos == len(expected): print("主流程核对通过") else: print(f"主流程在 {expected[pos]} 处断链，实际看到 {msg}") if __name__ == "__main__": main(sys.argv[1])

脚本做的是顺序匹配，不要求消息连续出现，符合信令流程中间夹杂其它过程的实际情况。expected 列表直接照抄 PDF 里的流程顺序；实际序列文件用上一节 tshark 导出的 Info 列，再按空格裁掉帧号和时间即可。这个脚本只核对顺序，不核对字段值，字段级校验保留人工，避免脚本复杂度过高反而失去落地价值。

5.3 文档不会写但现场一定会遇到的三个差异

无论 PDF 画得多完整，它默认讲的是协议标准行为，现场至少有三个差异是文档不写的。第一是定时器配置，协议给的是默认值，运营商和厂商都可以自定义 T3510、T3512 等定时器，现场看重发间隔必须以配置为准，不能按文档推理。第二是重复消息，流程图上一笔画一条，实际抓包里因为 RLC 分段、NAS 打包和重传，会出现大量重复帧，看到重复不等于异常，先确认是不是同一帧的分段。第三是实现差异，不同厂商对可选 IE 的补全程度不同，解析时缺省值容易偏差，核对时要把“协议必选”和“厂商必选”分开对待。

6. 进阶：用追踪标识把单条信令串成端到端会话

只看单个接口的抓包，永远只能看到流程的一个片段。把空口、N2、N11、N4 四个平面的消息串成一条完整的会话，靠的不是时间戳，而是追踪标识。NGAP 里有 gNB UE NGAP ID 和 AMF UE NGAP ID，NAS 层有 5G-GUTI，N11 接口上对应 SM Context ID，N4 接口上对应转发规则和隧道标识。同一会话在不同接口留下一串互相关联的 ID，把它们列成一张对照表，整条链路就串起来了。

我的做法是这样的：拿到一个 UE 的 5G-GUTI，先在 N2 pcap 里过滤出对应帧，记下 gNB UE NGAP ID 和 AMF UE NGAP ID；再去 AMF 侧日志里用这对 ID 找到 SM Context ID；最后拿隧道标识去 N3 和 N4 抓包里核对数据面路径。每次联调，我都会顺手维护一张会话 ID 对照表，排查时能直接把问题定位到具体网元，而不是反复猜。

有一次我对着 pcap 查了快两天，所有现象都对不上，最后发现是拿错了另一个 UE 的 5G-GUTI，两条流程叠在一起看，自然处处矛盾。从那以后，我坚持先列追踪标识对照表再上工具分析，排错成功率明显提高。这个习惯也推荐给你，从读完这份 5g信令流程解析.pdf 的第一天就开始用，希望帮到你。

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