简介面向5G无线网络优化与运维人员的信令分析指导文档围绕开机入网、上下文管理、会话管理、寻呼、切换及NAS流程等核心环节展开帮助读者建立从小区搜索、系统消息广播、随机接入到RRC连接建立与注册的完整信令链路认知适合需要排查接入失败、切换异常和会话建立问题的中高级网优工程师查阅。资源包共1个docx文件约4.24MB以分章节的流程说明和关键消息解读为主体目录层级清晰便于按信令阶段定位查阅。目前已有62人学习。内容覆盖竞争与非竞争随机接入、RRC建立/拒绝/重发、初始上下文建立、PDU会话建立修改释放、5GC与RAN寻呼、站内及Xn/N2/LNR切换与重定向并对MIB、SIB1、SI等关键消息做解读可作为日常优化分析、问题定位和信令流程梳理的案头参考。1. 5G-信令分析指导书从一条 NGAP 消息看清接入失败的真相核心网抓包群里最常见的一句话是“用户附着不上帮忙看下信令”。很多人第一反应是把 pcap 拖进 Wireshark用ngap过滤看到一屏 NGAP 消息却不知从哪条读起。5G-信令分析指导书要解决的问题很具体把一条 NGAP 或 NAS 消息还原成“谁在什么阶段、因为什么原因拒绝了谁”。它面向日常要处理接入失败、切换异常、PDU 会话建立失败的无线与核心网运维、测试工程师也面向刚接触 5G 协议栈、需要一套固定排查顺序的人。下面按“先读懂消息语义、再落到抓包与解码、最后处理坑”的顺序走一遍我平时用的路子。2. 信令链路先立住NGAP 与 NAS 到底谁管什么2.1 从接口分工看消息归属5G 接入信令不是一条线上的消息而是几层协议叠出来的。基站gNB和核心网 AMF 之间跑 NGAP承载的是“接入层之上的控制面动作”初始上下文建立、PDU 会话资源建立、切换请求、寻呼、UE 上下文释放。UE 和 AMF 之间的 NAS 消息注册请求、鉴权、安全模式命令、PDU 会话建立请求对 gNB 是透明的gNB 只负责透传。这个分工决定了排查方向如果抓包点在 N2 口gNB 与 AMF 之间你能同时看到 NGAP 和它里面承载的 NAS如果抓包点在 Uu 口或基站内部NAS 可能是加密的只能看到 NGAP 层的容器。很多新手在 N2 口看到InitialUEMessage里挂着一坨NAS-PDU就以为是 NGAP 字段其实那是 NAS 的十六进制载荷需要单独解。我一般按这个顺序确认链路是否健康NGSetupRequest/Response是否成功失败说明 gNB 与 AMF 的 PLMN、TAC、切片配置对不上。有没有NGSetupFailure里面带 Cause常见是Misc: Unknown PLMN或Slice not supported。单用户流程里InitialUEMessage之后是否很快出现DownlinkNASTransport没有就说明 AMF 侧没接住。提示NG 接口建立失败时先别抓用户面N2 都不通后面全是空谈。2.2 NAS 消息为什么是排查重点真正决定“能不能接入”的是 NAS。注册流程里Registration Request带 5GMM 能力、请求的切片S-NSSAI、UE 安全能力AMF 回Authentication Request走完 5G-AKA 后下发Security Mode Command再回Registration Accept或Registration Reject。拒绝的原因编码就藏在Registration Reject的 5GMM Cause 里。常见几类5GMM Cause含义典型触发3Illegal UE卡信息与签约不匹配75GS services not allowed签约里没开 5G11PLMN not allowed漫游或 PLMN 配置错22CongestionAMF 过载保护27N1 mode not allowed终端能力或策略限制在 N2 抓包里Registration Reject通常出现在DownlinkNASTransport的 NAS-PDU 字段中。把这段 hex 复制出来用 NAS 解码工具按 5GMM 消息类型解第一字节高半字节是安全头类型低半字节才是消息类型别一上来就按明文读。2.3 一条消息的字段拆解示范以InitialUEMessage为例它的必备 IE 包括 RAN UE NGAP ID、NAS-PDU、User Location Information、RRC Establishment Cause。RAN UE NGAP ID 是 gNB 侧给这个 UE 分配的临时标识后续所有 N2 消息靠它和 AMF UE NGAP ID 配对。如果两条消息的 RAN UE NGAP ID 对不上就说明你串了不同用户这是抓包里最容易翻车的地方尤其在多用户并发时。User Location Information 里的 NR CGI 和 TAI 决定了 AMF 选哪个切片、做不做位置限制。TAI 不在允许列表里注册就会被拒Cause 一般落在 11 或 12。所以看到拒绝先别怀疑终端先核对 TAI 和 S-NSSAI 是否在签约和 AMF 配置的交集里。3. 抓包与解码把 pcap 变成可读的会话时间线3.1 抓包点选择与最小过滤命令N2 口抓包最常见做法是在 gNB 的 N2 链路或 AMF 的对接网口做镜像。抓到后用 tshark 先做一轮粗过滤把单用户的会话挑出来# 按 NGAP 过程码过滤0 是 InitialUEMessage 所在流程按需改 tshark -r n2_capture.pcap -Y ngap.procedureCode 0 -T fields \ -e frame.number -e ngap.RAN_UE_NGAP_ID -e ngap.nas_pdu # 按 RAN UE NGAP ID 锁定单用户导出该用户全部 NGAP 消息 tshark -r n2_capture.pcap -Y ngap.RAN_UE_NGAP_ID 3412 \ -T fields -e frame.time -e ngap.procedureCode -e ngap.nas_pdu第一条命令按过程码抓初始 UE 消息-T fields指定输出字段适合快速扫有多少用户发起了接入。第二条用 RAN UE NGAP ID 做单用户过滤这个 ID 是十六进制还是十进制取决于字段显示方式建议先用-V看一眼原始值再填。-e ngap.nas_pdu输出的是纯 hex方便后续喂给 NAS 解码脚本。注意不同厂商对 NGAP 私有 IE 的填充不完全一致tshark 版本太旧会把未知 IE 标成Unknown升级到较新版本再解能少走很多弯路。3.2 用 Python 把 NAS-PDU 解成消息类型tshark 能解 NGAP但对加密后的 NAS 只能给出密文。如果抓包点在 AMF 侧且 NAS 已解密可以直接用脚本按 5GMM 消息类型做归类统计import binascii # 5GMM 消息类型低半字节映射仅列常用项 MM_TYPE { 0x41: Registration Request, 0x42: Registration Accept, 0x43: Registration Complete, 0x44: Registration Reject, 0x45: Deregistration Request, 0x56: Authentication Request, 0x57: Authentication Response, 0x5c: Security Mode Command, 0x5d: Security Mode Complete, 0x67: UL NAS Transport, 0x68: DL NAS Transport, } def decode_nas(hex_str: str) - str: raw binascii.unhexlify(hex_str.replace(:, )) if not raw: return empty # 首字节高半字节安全头类型低半字节才是消息类型 msg_type raw[0] 0x0F # 明文 5GMM 消息首字节本身就是消息类型兼容两种布局 key raw[0] if raw[0] in MM_TYPE else msg_type return MM_TYPE.get(key, funknown(0x{raw[0]:02x})) if __name__ __main__: # 示例Registration Reject 的明文 NAS-PDU print(decode_nas(7e0044)) # 输出 Registration Reject print(decode_nas(7e0041)) # 输出 Registration Request这段代码的逻辑是先去掉分隔符转成字节串再区分两种常见布局带安全头的 NAS 首字节高半字节表示安全保护类型低半字节是消息类型而明文 5GMM 消息首字节直接就是类型值。MM_TYPE字典只覆盖注册、鉴权、安全模式和 NAS 传输这几类高频消息实际排查时按需补全。跑出来的统计结果可以按消息类型计数快速判断是“大量用户卡在鉴权”还是“零星用户被拒”。3.3 时间线还原把消息按 NGAP ID 排序单用户流程最有效的呈现方式是按时间排序的消息序列。用下面这条命令导出关键字段再拼成“时间 方向 过程码 NAS 类型”的表tshark -r n2_capture.pcap -Y ngap.RAN_UE_NGAP_ID 3412 \ -T fields -E separator| \ -e frame.time_relative -e ip.src -e ip.dst \ -e ngap.procedureCode -e ngap.nas_pdu-E separator|用竖线分隔方便导入表格工具。frame.time_relative是相对首帧的时间比绝对时间更适合看阶段耗时比如InitialUEMessage到Authentication Request隔了多久超过 1 秒就要怀疑 AMF 侧排队或链路重传。4. 注册与 PDU 会话流程的逐段验证4.1 注册流程四个阶段的判定点一条完整的初始注册在 N2 口上大致能看到这些消息InitialUEMessage带 Registration Request、DownlinkNASTransport带 Authentication Request、再一轮上下行的鉴权响应、Security Mode Command/Complete、最后的Registration Accept。每个阶段的判定点很明确卡在鉴权Authentication Request发出后没有Authentication Response查 UE 侧 USIM 和 AMF 的鉴权向量常见是 K/OPc 配错导致 MAC 校验失败。卡在安全模式Security Mode Command后没有Complete多半是 UE 算法与 AMF 允许的算法无交集看Security Mode Command里的加密与完整性保护算法列表。卡在注册接受前说明鉴权安全都过了是签约或切片校验拒绝直接读Registration Reject的 Cause。我习惯在时间线上标注这四个阶段哪个阶段断开就只查那个阶段的字段不用全量翻包。4.2 PDU 会话建立失败的定位方法注册成功后UE 发UL NAS Transport承载PDU Session Establishment RequestAMF 通过PDU Session Resource Setup Request让 gNB 建资源gNB 回 Response最后DL NAS Transport带回PDU Session Establishment Accept或Reject。失败时优先看PDU Session Resource Setup Response里的 CausegNB 侧常见原因有NGAP Cause含义排查方向Radio Network: radio resources not available无线资源不足查小区负荷与准入控制Radio Network: unknown PDU session ID会话 ID 不匹配查 gNB 与 AMF 的会话映射Transport: transport resources unavailableN3 隧道建不起来查 UPF 地址与 GTP-U 隧道如果 NGAP 层都成功但 UE 收到PDU Session Establishment Reject那问题在 SMF/UPF 侧Cause 常见是Insufficient resources或DNN not supported。这时候 N2 口已经帮不上忙要去查 SMF 的会话管理日志和 UPF 的 N4 会话状态抓包点要移到 N4 或 N6。提示N2 上看到PDU Session Resource Setup Request但始终没有 Response先查 gNB 与 AMF 之间的 SCTP 链路是否丢包别急着怀疑核心网。4.3 用过滤表达式缩小故障域排查时最耗时的不是解码而是从几万条消息里定位异常用户。几个常用过滤组合# 所有注册拒绝消息 tshark -r n2_capture.pcap -Y ngap.nas_pdu contains 7e0044 # 指定时间段内的 InitialUEMessage定位突发接入 tshark -r n2_capture.pcap -Y ngap.procedureCode 0 frame.time \2024-01-01 10:00:00\ # 只看失败响应类消息 tshark -r n2_capture.pcap -Y ngap.procedureCode 15 ngap.cause第一条用 NAS-PDU 的 hex 片段做包含匹配7e0044是带安全头的注册拒绝常见前缀实际以你抓到的样本为准。第二条把过程码和时间组合用于分析整点突发接入是否引发拥塞拒绝。第三条过滤 PDU 会话资源建立响应并只保留带 Cause 的帧快速统计失败原因分布。这些表达式不追求一次到位边看边加条件比写一条复杂过滤更实际。5. 避坑与排查五条血泪经验5.1 抓包点选错看到的是加密 NAS现象全程只能看到 NGAP 消息NAS-PDU 全是密文解不出消息类型。原因抓包点在 gNB 与 UE 之间或 gNB 内侧NAS 已被加密gNB 只透传。解决把抓包点移到 N2 口 AMF 侧或让核心网侧提供解密后的跟踪若只能拿密文就别在 NAS 层下结论改用 NGAP Cause 和流程是否完整来判断。5.2 NGAP ID 串用户时间线拼错现象同一时间线里出现两个Registration Request却只有一个 UE或消息顺序明显违背流程。原因多用户并发时只用 IP 对过滤没按 RAN UE NGAP ID 锁定单用户。解决先用InitialUEMessage导出全部 RAN UE NGAP ID再按单个 ID 过滤确认 AMF UE NGAP ID 与它成对出现后再拼时间线。5.3 Cause 编码读错字节现象看到Registration Reject就断言“被 AMF 拒绝”但 Cause 显示的含义与现场完全不符。原因把 NAS 首字节整体当消息类型读忽略了安全头半字节或把 NGAP Cause 和 5GMM Cause 混为一谈。解决NAS 按 5GMM 消息格式解先看安全头再看类型NGAP 的 Cause 在ngap.cause字段两套编码不要混用。5.4 时间偏差导致误判重传现象Authentication Request到Response间隔很长误判为链路重传或 AMF 卡顿。原因抓包设备时钟未与网元同步相对时间被拉长。解决抓包前统一 NTP或改用frame.time_relative并交叉验证 SCTP 重传计数别单看一帧的时间差就下结论。5.5 忽略切片与 TAI 的交集校验现象终端注册被拒Cause 是 11 或 12查终端和卡都正常。原因只核对了签约里的 S-NSSAI没核对 AMF 侧允许的 TAI 列表与切片映射。解决把User Location Information里的 TAI、NR CGI 与 AMF 配置的允许区域、签约切片三者做交集任何一个为空都会拒绝这一步要放到查终端之前。6. 进阶把单次排查沉淀成可复用的判定脚本做了多次排查后会发现真正费时间的不是解一条消息而是每次都要重新拼过滤表达式、重新对字段。我的做法是把高频判定固化成一个脚本输入 pcap 和 RAN UE NGAP ID输出该用户的阶段耗时、拒绝 Cause 和可疑点。核心思路是复用前面两条 tshark 命令把输出转成结构化数据后再做规则判断。import subprocess, json def extract(pcap: str, ran_id: int): cmd [ tshark, -r, pcap, -Y, fngap.RAN_UE_NGAP_ID {ran_id}, -T, fields, -E, separator|, -e, frame.time_relative, -e, ngap.procedureCode, -e, ngap.cause, -e, ngap.nas_pdu, ] out subprocess.run(cmd, capture_outputTrue, textTrue).stdout rows [] for line in out.strip().splitlines(): t, proc, cause, nas (line.split(|) [, , , ])[:4] rows.append({t: float(t) if t else 0.0, proc: proc, cause: cause, nas: nas}) return rows def judge(rows): # 规则出现拒绝 Cause或鉴权后 2 秒内无后续消息标为可疑 flags [] for r in rows: if r[cause]: flags.append(fframe{r[t]:.3f}s cause{r[cause]}) stages [r[t] for r in rows if r[proc] in (0, 15)] if len(stages) 2 and stages[-1] - stages[0] 2.0: flags.append(stage gap 2s, check retransmission) return flags if __name__ __main__: data extract(n2_capture.pcap, 3412) print(json.dumps(judge(data), ensure_asciiFalse, indent2))脚本里extract负责调 tshark 并解析成行judge做两条最简单的规则出现 Cause 就记录阶段间隔超过 2 秒就提示查重传。参数上ran_id要和抓包里的字段一致-E separator必须和解析时的分隔符对齐否则整行会错位。阈值 2 秒是经验值接入密集场景可以放宽Wireshark 里也可以直接用frame.time_delta做同样的观察。这套东西的价值不在脚本本身而在于把“先看建立、再看注册四阶段、最后看会话建立”的顺序固定下来新同事拿到 pcap 也能按同一路径走。我自己吃过最大的亏是跳过 NG 建立直接查用户流程翻了两小时才发现是 TAC 配错导致 NGSetup 就没成功。后来每次先跑一遍链路建立检查再进单用户基本不会再走回头路。希望帮到你。本文还有配套的精品资源点击获取
简介面向5G无线网络优化与运维人员的信令分析指导文档围绕开机入网、上下文管理、会话管理、寻呼、切换及NAS流程等核心环节展开帮助读者建立从小区搜索、系统消息广播、随机接入到RRC连接建立与注册的完整信令链路认知适合需要排查接入失败、切换异常和会话建立问题的中高级网优工程师查阅。资源包共1个docx文件约4.24MB以分章节的流程说明和关键消息解读为主体目录层级清晰便于按信令阶段定位查阅。目前已有62人学习。内容覆盖竞争与非竞争随机接入、RRC建立/拒绝/重发、初始上下文建立、PDU会话建立修改释放、5GC与RAN寻呼、站内及Xn/N2/LNR切换与重定向并对MIB、SIB1、SI等关键消息做解读可作为日常优化分析、问题定位和信令流程梳理的案头参考。1. 5G-信令分析指导书从一条 NGAP 消息看清接入失败的真相核心网抓包群里最常见的一句话是“用户附着不上帮忙看下信令”。很多人第一反应是把 pcap 拖进 Wireshark用ngap过滤看到一屏 NGAP 消息却不知从哪条读起。5G-信令分析指导书要解决的问题很具体把一条 NGAP 或 NAS 消息还原成“谁在什么阶段、因为什么原因拒绝了谁”。它面向日常要处理接入失败、切换异常、PDU 会话建立失败的无线与核心网运维、测试工程师也面向刚接触 5G 协议栈、需要一套固定排查顺序的人。下面按“先读懂消息语义、再落到抓包与解码、最后处理坑”的顺序走一遍我平时用的路子。2. 信令链路先立住NGAP 与 NAS 到底谁管什么2.1 从接口分工看消息归属5G 接入信令不是一条线上的消息而是几层协议叠出来的。基站gNB和核心网 AMF 之间跑 NGAP承载的是“接入层之上的控制面动作”初始上下文建立、PDU 会话资源建立、切换请求、寻呼、UE 上下文释放。UE 和 AMF 之间的 NAS 消息注册请求、鉴权、安全模式命令、PDU 会话建立请求对 gNB 是透明的gNB 只负责透传。这个分工决定了排查方向如果抓包点在 N2 口gNB 与 AMF 之间你能同时看到 NGAP 和它里面承载的 NAS如果抓包点在 Uu 口或基站内部NAS 可能是加密的只能看到 NGAP 层的容器。很多新手在 N2 口看到InitialUEMessage里挂着一坨NAS-PDU就以为是 NGAP 字段其实那是 NAS 的十六进制载荷需要单独解。我一般按这个顺序确认链路是否健康NGSetupRequest/Response是否成功失败说明 gNB 与 AMF 的 PLMN、TAC、切片配置对不上。有没有NGSetupFailure里面带 Cause常见是Misc: Unknown PLMN或Slice not supported。单用户流程里InitialUEMessage之后是否很快出现DownlinkNASTransport没有就说明 AMF 侧没接住。提示NG 接口建立失败时先别抓用户面N2 都不通后面全是空谈。2.2 NAS 消息为什么是排查重点真正决定“能不能接入”的是 NAS。注册流程里Registration Request带 5GMM 能力、请求的切片S-NSSAI、UE 安全能力AMF 回Authentication Request走完 5G-AKA 后下发Security Mode Command再回Registration Accept或Registration Reject。拒绝的原因编码就藏在Registration Reject的 5GMM Cause 里。常见几类5GMM Cause含义典型触发3Illegal UE卡信息与签约不匹配75GS services not allowed签约里没开 5G11PLMN not allowed漫游或 PLMN 配置错22CongestionAMF 过载保护27N1 mode not allowed终端能力或策略限制在 N2 抓包里Registration Reject通常出现在DownlinkNASTransport的 NAS-PDU 字段中。把这段 hex 复制出来用 NAS 解码工具按 5GMM 消息类型解第一字节高半字节是安全头类型低半字节才是消息类型别一上来就按明文读。2.3 一条消息的字段拆解示范以InitialUEMessage为例它的必备 IE 包括 RAN UE NGAP ID、NAS-PDU、User Location Information、RRC Establishment Cause。RAN UE NGAP ID 是 gNB 侧给这个 UE 分配的临时标识后续所有 N2 消息靠它和 AMF UE NGAP ID 配对。如果两条消息的 RAN UE NGAP ID 对不上就说明你串了不同用户这是抓包里最容易翻车的地方尤其在多用户并发时。User Location Information 里的 NR CGI 和 TAI 决定了 AMF 选哪个切片、做不做位置限制。TAI 不在允许列表里注册就会被拒Cause 一般落在 11 或 12。所以看到拒绝先别怀疑终端先核对 TAI 和 S-NSSAI 是否在签约和 AMF 配置的交集里。3. 抓包与解码把 pcap 变成可读的会话时间线3.1 抓包点选择与最小过滤命令N2 口抓包最常见做法是在 gNB 的 N2 链路或 AMF 的对接网口做镜像。抓到后用 tshark 先做一轮粗过滤把单用户的会话挑出来# 按 NGAP 过程码过滤0 是 InitialUEMessage 所在流程按需改 tshark -r n2_capture.pcap -Y ngap.procedureCode 0 -T fields \ -e frame.number -e ngap.RAN_UE_NGAP_ID -e ngap.nas_pdu # 按 RAN UE NGAP ID 锁定单用户导出该用户全部 NGAP 消息 tshark -r n2_capture.pcap -Y ngap.RAN_UE_NGAP_ID 3412 \ -T fields -e frame.time -e ngap.procedureCode -e ngap.nas_pdu第一条命令按过程码抓初始 UE 消息-T fields指定输出字段适合快速扫有多少用户发起了接入。第二条用 RAN UE NGAP ID 做单用户过滤这个 ID 是十六进制还是十进制取决于字段显示方式建议先用-V看一眼原始值再填。-e ngap.nas_pdu输出的是纯 hex方便后续喂给 NAS 解码脚本。注意不同厂商对 NGAP 私有 IE 的填充不完全一致tshark 版本太旧会把未知 IE 标成Unknown升级到较新版本再解能少走很多弯路。3.2 用 Python 把 NAS-PDU 解成消息类型tshark 能解 NGAP但对加密后的 NAS 只能给出密文。如果抓包点在 AMF 侧且 NAS 已解密可以直接用脚本按 5GMM 消息类型做归类统计import binascii # 5GMM 消息类型低半字节映射仅列常用项 MM_TYPE { 0x41: Registration Request, 0x42: Registration Accept, 0x43: Registration Complete, 0x44: Registration Reject, 0x45: Deregistration Request, 0x56: Authentication Request, 0x57: Authentication Response, 0x5c: Security Mode Command, 0x5d: Security Mode Complete, 0x67: UL NAS Transport, 0x68: DL NAS Transport, } def decode_nas(hex_str: str) - str: raw binascii.unhexlify(hex_str.replace(:, )) if not raw: return empty # 首字节高半字节安全头类型低半字节才是消息类型 msg_type raw[0] 0x0F # 明文 5GMM 消息首字节本身就是消息类型兼容两种布局 key raw[0] if raw[0] in MM_TYPE else msg_type return MM_TYPE.get(key, funknown(0x{raw[0]:02x})) if __name__ __main__: # 示例Registration Reject 的明文 NAS-PDU print(decode_nas(7e0044)) # 输出 Registration Reject print(decode_nas(7e0041)) # 输出 Registration Request这段代码的逻辑是先去掉分隔符转成字节串再区分两种常见布局带安全头的 NAS 首字节高半字节表示安全保护类型低半字节是消息类型而明文 5GMM 消息首字节直接就是类型值。MM_TYPE字典只覆盖注册、鉴权、安全模式和 NAS 传输这几类高频消息实际排查时按需补全。跑出来的统计结果可以按消息类型计数快速判断是“大量用户卡在鉴权”还是“零星用户被拒”。3.3 时间线还原把消息按 NGAP ID 排序单用户流程最有效的呈现方式是按时间排序的消息序列。用下面这条命令导出关键字段再拼成“时间 方向 过程码 NAS 类型”的表tshark -r n2_capture.pcap -Y ngap.RAN_UE_NGAP_ID 3412 \ -T fields -E separator| \ -e frame.time_relative -e ip.src -e ip.dst \ -e ngap.procedureCode -e ngap.nas_pdu-E separator|用竖线分隔方便导入表格工具。frame.time_relative是相对首帧的时间比绝对时间更适合看阶段耗时比如InitialUEMessage到Authentication Request隔了多久超过 1 秒就要怀疑 AMF 侧排队或链路重传。4. 注册与 PDU 会话流程的逐段验证4.1 注册流程四个阶段的判定点一条完整的初始注册在 N2 口上大致能看到这些消息InitialUEMessage带 Registration Request、DownlinkNASTransport带 Authentication Request、再一轮上下行的鉴权响应、Security Mode Command/Complete、最后的Registration Accept。每个阶段的判定点很明确卡在鉴权Authentication Request发出后没有Authentication Response查 UE 侧 USIM 和 AMF 的鉴权向量常见是 K/OPc 配错导致 MAC 校验失败。卡在安全模式Security Mode Command后没有Complete多半是 UE 算法与 AMF 允许的算法无交集看Security Mode Command里的加密与完整性保护算法列表。卡在注册接受前说明鉴权安全都过了是签约或切片校验拒绝直接读Registration Reject的 Cause。我习惯在时间线上标注这四个阶段哪个阶段断开就只查那个阶段的字段不用全量翻包。4.2 PDU 会话建立失败的定位方法注册成功后UE 发UL NAS Transport承载PDU Session Establishment RequestAMF 通过PDU Session Resource Setup Request让 gNB 建资源gNB 回 Response最后DL NAS Transport带回PDU Session Establishment Accept或Reject。失败时优先看PDU Session Resource Setup Response里的 CausegNB 侧常见原因有NGAP Cause含义排查方向Radio Network: radio resources not available无线资源不足查小区负荷与准入控制Radio Network: unknown PDU session ID会话 ID 不匹配查 gNB 与 AMF 的会话映射Transport: transport resources unavailableN3 隧道建不起来查 UPF 地址与 GTP-U 隧道如果 NGAP 层都成功但 UE 收到PDU Session Establishment Reject那问题在 SMF/UPF 侧Cause 常见是Insufficient resources或DNN not supported。这时候 N2 口已经帮不上忙要去查 SMF 的会话管理日志和 UPF 的 N4 会话状态抓包点要移到 N4 或 N6。提示N2 上看到PDU Session Resource Setup Request但始终没有 Response先查 gNB 与 AMF 之间的 SCTP 链路是否丢包别急着怀疑核心网。4.3 用过滤表达式缩小故障域排查时最耗时的不是解码而是从几万条消息里定位异常用户。几个常用过滤组合# 所有注册拒绝消息 tshark -r n2_capture.pcap -Y ngap.nas_pdu contains 7e0044 # 指定时间段内的 InitialUEMessage定位突发接入 tshark -r n2_capture.pcap -Y ngap.procedureCode 0 frame.time \2024-01-01 10:00:00\ # 只看失败响应类消息 tshark -r n2_capture.pcap -Y ngap.procedureCode 15 ngap.cause第一条用 NAS-PDU 的 hex 片段做包含匹配7e0044是带安全头的注册拒绝常见前缀实际以你抓到的样本为准。第二条把过程码和时间组合用于分析整点突发接入是否引发拥塞拒绝。第三条过滤 PDU 会话资源建立响应并只保留带 Cause 的帧快速统计失败原因分布。这些表达式不追求一次到位边看边加条件比写一条复杂过滤更实际。5. 避坑与排查五条血泪经验5.1 抓包点选错看到的是加密 NAS现象全程只能看到 NGAP 消息NAS-PDU 全是密文解不出消息类型。原因抓包点在 gNB 与 UE 之间或 gNB 内侧NAS 已被加密gNB 只透传。解决把抓包点移到 N2 口 AMF 侧或让核心网侧提供解密后的跟踪若只能拿密文就别在 NAS 层下结论改用 NGAP Cause 和流程是否完整来判断。5.2 NGAP ID 串用户时间线拼错现象同一时间线里出现两个Registration Request却只有一个 UE或消息顺序明显违背流程。原因多用户并发时只用 IP 对过滤没按 RAN UE NGAP ID 锁定单用户。解决先用InitialUEMessage导出全部 RAN UE NGAP ID再按单个 ID 过滤确认 AMF UE NGAP ID 与它成对出现后再拼时间线。5.3 Cause 编码读错字节现象看到Registration Reject就断言“被 AMF 拒绝”但 Cause 显示的含义与现场完全不符。原因把 NAS 首字节整体当消息类型读忽略了安全头半字节或把 NGAP Cause 和 5GMM Cause 混为一谈。解决NAS 按 5GMM 消息格式解先看安全头再看类型NGAP 的 Cause 在ngap.cause字段两套编码不要混用。5.4 时间偏差导致误判重传现象Authentication Request到Response间隔很长误判为链路重传或 AMF 卡顿。原因抓包设备时钟未与网元同步相对时间被拉长。解决抓包前统一 NTP或改用frame.time_relative并交叉验证 SCTP 重传计数别单看一帧的时间差就下结论。5.5 忽略切片与 TAI 的交集校验现象终端注册被拒Cause 是 11 或 12查终端和卡都正常。原因只核对了签约里的 S-NSSAI没核对 AMF 侧允许的 TAI 列表与切片映射。解决把User Location Information里的 TAI、NR CGI 与 AMF 配置的允许区域、签约切片三者做交集任何一个为空都会拒绝这一步要放到查终端之前。6. 进阶把单次排查沉淀成可复用的判定脚本做了多次排查后会发现真正费时间的不是解一条消息而是每次都要重新拼过滤表达式、重新对字段。我的做法是把高频判定固化成一个脚本输入 pcap 和 RAN UE NGAP ID输出该用户的阶段耗时、拒绝 Cause 和可疑点。核心思路是复用前面两条 tshark 命令把输出转成结构化数据后再做规则判断。import subprocess, json def extract(pcap: str, ran_id: int): cmd [ tshark, -r, pcap, -Y, fngap.RAN_UE_NGAP_ID {ran_id}, -T, fields, -E, separator|, -e, frame.time_relative, -e, ngap.procedureCode, -e, ngap.cause, -e, ngap.nas_pdu, ] out subprocess.run(cmd, capture_outputTrue, textTrue).stdout rows [] for line in out.strip().splitlines(): t, proc, cause, nas (line.split(|) [, , , ])[:4] rows.append({t: float(t) if t else 0.0, proc: proc, cause: cause, nas: nas}) return rows def judge(rows): # 规则出现拒绝 Cause或鉴权后 2 秒内无后续消息标为可疑 flags [] for r in rows: if r[cause]: flags.append(fframe{r[t]:.3f}s cause{r[cause]}) stages [r[t] for r in rows if r[proc] in (0, 15)] if len(stages) 2 and stages[-1] - stages[0] 2.0: flags.append(stage gap 2s, check retransmission) return flags if __name__ __main__: data extract(n2_capture.pcap, 3412) print(json.dumps(judge(data), ensure_asciiFalse, indent2))脚本里extract负责调 tshark 并解析成行judge做两条最简单的规则出现 Cause 就记录阶段间隔超过 2 秒就提示查重传。参数上ran_id要和抓包里的字段一致-E separator必须和解析时的分隔符对齐否则整行会错位。阈值 2 秒是经验值接入密集场景可以放宽Wireshark 里也可以直接用frame.time_delta做同样的观察。这套东西的价值不在脚本本身而在于把“先看建立、再看注册四阶段、最后看会话建立”的顺序固定下来新同事拿到 pcap 也能按同一路径走。我自己吃过最大的亏是跳过 NG 建立直接查用户流程翻了两小时才发现是 TAC 配错导致 NGSetup 就没成功。后来每次先跑一遍链路建立检查再进单用户基本不会再走回头路。希望帮到你。本文还有配套的精品资源点击获取
