简介《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 里传给 AMFAMF 拿到后决定走完整鉴权还是直接接受。注册阶段消息 / 接口携带的关键信息读文档时重点看什么RRC 连接建立RRCSetupCompleteUu5G-S-TMSI 或 SUCI注册类型、UE 网络能力鉴权Authentication RequestN1RAND / AUTN鉴权失败时是哪个参数不匹配安全Security Mode CommandN1加密与完整性算法完整性保护是否开启注册接受InitialContextSetupRequestN2Registration Accept、allowed NSSAI、TAI list是否下发 5G-GUTI、默认切片是什么读这一节时重点不是背消息名而是看两条路径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 不是一个人把活干完它把请求转给 SMFSMF 选择 UPF 并建立 N4 会话然后 AMF 通过 NGAP 的 PDU Session Resource Setup Request 把 QoS Flow 描述下发给 gNB。gNB 把 QoS Flow 映射到空口 DRB通过 RRC Reconfiguration 配置给 UE数据面才算真正通。检查点对应消息 / 配置现场容易出问题的地方PDU Session IDNAS 消息头UE 与 AMF 对会话 ID 的理解不一致重传后对不上QFIQoS Flow 描述 / SDAP 配置多个 Flow 合并到同一 DRB 时映射关系错位5QI 与资源类型QoS 特性参数与切片配置冲突被 AMF 或 SMF 直接拒绝SDAP 映射RRC Reconfiguration收端按错误 QFI 解析上行数据出现静默丢包文档里 PDU 会话建立通常按完整时序展开但现场最常见的现象是“会话建立成功用户依然没网”。问题往往不在 NAS 层而在这张 QoS Flow 到 DRB 的映射表里。我把这一页单独折角排错时先核对它再去查空口和核心网的承载是否对得上。2.3 切换流程Xn 切换与 N2 切换在文档里的两条路切换分两大类。Xn 切换是 gNB 之间直接交互核心网在切换完成后收到一条路径迁移通知把下行数据路径切到新 gNBN2 切换则从头到尾有 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 值。这四个字段决定了流程预期、准入边界、对账主线和下一步去哪查。排查项抓包里对应内容异常时意味着什么注册类型NAS Registration Request 里的注册类型字段0 表示初始注册1 表示移动性更新2 表示周期性注册与业务预期不符就要查终端行为切片标识NGAP 或 NAS 消息里的 S-NSSAI 列表与 AMF 允许的切片配置不一致请求会被直接拒绝PDU 会话 IDNAS 消息头初始请求和重传请求的会话 ID 不一致说明终端状态机异常Cause 值NGAP Cause、NAS 5GMM Cause、接口层 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 Requestlog 里却没有原因值现象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, encodingutf-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 IDNAS 层有 5G-GUTIN11 接口上对应 SM Context IDN4 接口上对应转发规则和隧道标识。同一会话在不同接口留下一串互相关联的 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 的第一天就开始用希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/13 3:31:49 · 阅读 1.2k 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 里传给 AMFAMF 拿到后决定走完整鉴权还是直接接受。注册阶段消息 / 接口携带的关键信息读文档时重点看什么RRC 连接建立RRCSetupCompleteUu5G-S-TMSI 或 SUCI注册类型、UE 网络能力鉴权Authentication RequestN1RAND / AUTN鉴权失败时是哪个参数不匹配安全Security Mode CommandN1加密与完整性算法完整性保护是否开启注册接受InitialContextSetupRequestN2Registration Accept、allowed NSSAI、TAI list是否下发 5G-GUTI、默认切片是什么读这一节时重点不是背消息名而是看两条路径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 不是一个人把活干完它把请求转给 SMFSMF 选择 UPF 并建立 N4 会话然后 AMF 通过 NGAP 的 PDU Session Resource Setup Request 把 QoS Flow 描述下发给 gNB。gNB 把 QoS Flow 映射到空口 DRB通过 RRC Reconfiguration 配置给 UE数据面才算真正通。检查点对应消息 / 配置现场容易出问题的地方PDU Session IDNAS 消息头UE 与 AMF 对会话 ID 的理解不一致重传后对不上QFIQoS Flow 描述 / SDAP 配置多个 Flow 合并到同一 DRB 时映射关系错位5QI 与资源类型QoS 特性参数与切片配置冲突被 AMF 或 SMF 直接拒绝SDAP 映射RRC Reconfiguration收端按错误 QFI 解析上行数据出现静默丢包文档里 PDU 会话建立通常按完整时序展开但现场最常见的现象是“会话建立成功用户依然没网”。问题往往不在 NAS 层而在这张 QoS Flow 到 DRB 的映射表里。我把这一页单独折角排错时先核对它再去查空口和核心网的承载是否对得上。2.3 切换流程Xn 切换与 N2 切换在文档里的两条路切换分两大类。Xn 切换是 gNB 之间直接交互核心网在切换完成后收到一条路径迁移通知把下行数据路径切到新 gNBN2 切换则从头到尾有 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 值。这四个字段决定了流程预期、准入边界、对账主线和下一步去哪查。排查项抓包里对应内容异常时意味着什么注册类型NAS Registration Request 里的注册类型字段0 表示初始注册1 表示移动性更新2 表示周期性注册与业务预期不符就要查终端行为切片标识NGAP 或 NAS 消息里的 S-NSSAI 列表与 AMF 允许的切片配置不一致请求会被直接拒绝PDU 会话 IDNAS 消息头初始请求和重传请求的会话 ID 不一致说明终端状态机异常Cause 值NGAP Cause、NAS 5GMM Cause、接口层 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 Requestlog 里却没有原因值现象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, encodingutf-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 IDNAS 层有 5G-GUTIN11 接口上对应 SM Context IDN4 接口上对应转发规则和隧道标识。同一会话在不同接口留下一串互相关联的 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 的第一天就开始用希望帮到你。本文还有配套的精品资源点击获取