5GC信令排查实战三板斧：从一次晚高峰成功率下跌说起

概述

5G核心网排查为什么比EPC时代难？本文用一次真实的现网处置案例（细节已脱敏、数值取整）回答这个问题：某省5GC晚高峰PDU会话建立成功率突降5个百分点，无线侧与核心网口径打架、N4接口防火墙回程被丢，最终靠“对口径、抓信令、复现收敛”三板斧在70分钟内收敛。文章给出定界流程图、抓包点速查表、5GSM拒绝原因对照和一套可以落地的运维工具链与十条军规，供核心网一线工程师直接套用。

一、先说清楚：为什么5GC的故障越来越难查

干了十几年核心网的工程师都有体感：EPC时代查故障，抓一个GTP-C v2包（UDP 2123端口），看cause value，基本能定位到八九不离十。二进制协议、状态机明确、网元边界清晰，MME和SGW之间谁没回话，抓包一看便知。

到了5GC，游戏规则变了三件事：

第一，控制面从“链路”变成了“服务”。 SBI走HTTP/2加JSON，NF之间通过NRF动态注册和发现，今天SMF调UDM走的是实例A，明天可能就是实例B。链路固定时代积累的“拓扑式排障直觉”失效了。

第二，部署形态从虚机变成了容器。 微服务化之后，一个SMF可能是几十个Pod，Kubernetes的调度、探针重启、滚动升级都会“制造”瞬断。日志分散在几十个容器里，没有聚合平台基本是盲人摸象。

第三，接口数量翻倍，协议栈混杂。 N2是SCTP上的NGAP（38412端口），N3/N9是GTP-U（2152端口），N4是PFCP（UDP 8805端口），SBI又是TCP/TLS上的HTTP/2——一次会话建立要横跨四五种协议栈，断在哪一跳，考验的不是单个协议知识，而是分层定界能力。

一句话总结：EPC排障是“查电路”，5GC排障是“查服务调用链”。

二、实战复盘：晚高峰成功率跌了5个百分点

下面这个案例来自某省5GC现网，按惯例做了脱敏，数值取整，但过程和根因原汁原味。

2.1 背景与现象

某月中旬，一批新建UPF刚完成扩容割接，承接全省约8%的PDU会话流量。割接当晚20:47，网管告警：PDU会话建立成功率从99.2%一路下滑到94.1%，跌了5.1个百分点，且持续走低没有自愈迹象。客服侧同时开始出现“信号满格打不开网页”的零星投诉，量级不大，但趋势向上。

2.2 时间线

2.3 定界过程拆解

第一步：对口径，别急着动手。 网管上无线口径的“会话建立成功率”基于NGAP的PDU Session Resource Setup应答统计，核心网口径基于SMF侧5GSM层统计。这次故障恰好发生在SMF之后的N4环节，无线口径完全无感，两边差了5个百分点。如果一开始就盯着无线侧指标找问题，方向就全错了。先花10分钟对口径，往往能省下两小时的无用功。

第二步：单用户Trace优于全网抓包。 通过3GPP定义的信令跟踪机制（TS 32.421/32.423定义的Trace体系）锁定一个失败用户，看到完整链条：NAS请求正常到达SMF，SMF在N4侧超时后按失败处理，AMF下发会话建立拒绝。单用户视角把“哪个网元没回话”这个关键问题直接摆上了台面。

第三步：抓包点成对部署，一锤定音。 在SMF侧和UPF侧同时抓8805端口：

• SMF侧：tcpdump -i any -w smf_n4.pcap udp port 8805，抓到PFCP Session Establishment Request以相同Sequence Number反复重发，无任何Response；
• UPF侧：同样抓包，请求已收到，且UPF本机日志确认发出了Response——但pcap里只有请求、没有自己发出的响应离开网卡前被谁拦下，最终在防火墙镜像口确认响应包进了防火墙、没出去。

根因水落石出： 割接时新UPF的回程路由调整，SMF发往UPF的请求走防火墙A，UPF返回SMF的响应走了防火墙B。PFCP基于UDP，没有连接概念，防火墙B上没有对应的会话表项，按策略默认丢弃所有“无首包记录”的UDP回包。请求过去了，响应回不来。

2.4 信令断点示意图

sequenceDiagram
    participant UE as 终端UE
    participant gNB
    participant AMF
    participant SMF
    participant FW as 防火墙B
    participant UPF
    UE->>gNB: PDU会话建立请求（DNN、S-NSSAI）
    gNB->>AMF: N2上行NAS传输
    AMF->>SMF: N11创建SM上下文
    SMF->>FW: PFCP会话建立请求（UDP 8805）
    FW->>UPF: 请求经防火墙A转发成功
    UPF--xFW: 响应走回程路由进入防火墙B
    FW--xSMF: 无会话表项，响应被丢弃
    SMF->>SMF: 等待超时后按相同序号重发
    SMF--xAMF: N4超时，创建上下文失败
    AMF--xUE: 会话建立拒绝

2.5 影响评估与整改

影响时段约70分钟，按当时话务量估算，约3.5万次会话建立尝试失败，涉及承接于新UPF资源池的约8%用户。无语音受影响（IMS会话走独立路径），无计费差错（失败会话未生成话单）。

整改四件事：

1. 传输策略基线化：所有跨防火墙的5GC接口（N2/N4/SBI）必须在割接方案中标注双向路径，执行“去程、回程”双向验证测试，验证不通过不得入网；
2. N4健康度独立拨测：SMF对每个PFCP对端做周期性Heartbeat监测，心跳异常即触发独立于成功率KPI的告警，把这类问题从“用户感知发现”前移到“接口层发现”；
3. 割接观察期制度：变更后30分钟成功率KPI跑不平、拨测不通过，一律回退；
4. 防火墙策略纳入配置管理：与核心网配置同级管理，每次变更留痕可回溯。

三、三板斧方法论：定界、抓包、复现

把上面案例沉淀成方法论，就是三句话：先对口径定界，再抓包取证，最后实验室复现闭环。

3.1 第一斧：定界——把“成功率跌了”翻译成“断在哪一跳”

定界的本质是KPI树的逐层下钻。一次PDU会话建立（流程见3GPP TS 23.502第4.3.2.2节）要经过：UE→gNB（N1）→AMF（N2）→SMF（N11）→UDM/PCF（N10/N7签约与策略）→UPF（N4）→回N2给gNB→NAS应答UE。每一跳都有独立的观测量：

flowchart TD
    A["成功率突降告警"] --> B["第一斧：对齐口径"]
    B --> C["无线口径与核心网口径取交集"]
    C --> D["单用户Trace锁定失败点"]
    D --> E{"失败发生在哪一跳"}
    E -->|"N2偶联"| F["查SCTP重传与Heartbeat"]
    E -->|"N11"| G["查AMF与SMF互操作及NRF注册"]
    E -->|"N4"| H["抓8805端口看请求响应配对"]
    E -->|"N3或N9"| I["查GTP-U连通性、VLAN与MTU"]
    F --> J["定位根因"]
    G --> J
    H --> J
    I --> J
    J --> K["第三斧：实验室复现"]
    K --> L["灰度修复并基线化"]

两个容易踩的坑：

• N2偶联抖动伪装成业务故障。 SCTP偶联（Association）来回震荡时，部分用户会话建立撞在偶联中断窗口上，表现为成功率“间歇性下跌、自动恢复”。判断特征：失败集中在特定AMF/gNB对，且与SCTP Heartbeat异常时间吻合。
• NRF故障是全局放大器。 SMF发现不了UDM或PCF，会话建立在N7/N10环节失败，现象却是“成功率跌”。核查方法：直接查NRF上的NF注册表与心跳状态，别只看SMF自己的日志。

3.2 第二斧：抓包——接口速查与Wireshark技巧

抓包点必须成对部署（请求侧+回程侧），这是本案例最大的教训。各接口速查：

Wireshark对5GC协议族的支持已经相当成熟：NGAP、PFCP、GTP-U开箱即解；SBI部分，明文h2c流量可以直接Decode As HTTP/2，再按stream右键追踪单次调用；TLS流量需在网元侧导出密钥日志（SSLKEYLOGFILE方式）才能解开，这一点要提前和设备商确认支持方式。

MTU问题单独提醒：GTP-U外层封装开销约36字节（IPv4）到56字节（IPv6），N3/N9链路MTU与对端不一致时，大包分片丢失，表现为“小包通、大包死、网页打不开但能注册”——和本次案例的用户投诉表象几乎一样，定界时别忘了这一层。

3.3 第三斧：复现——开源5GC是运维的“风洞”

现网上不敢试的操作，实验室里随便试。建议每个核心网维护团队常备一套开源复现环境：

本案例的根因就可以在实验室20分钟复现：两台虚拟UPF走不同防火墙路径，PFCP请求响应不对称，现象与现网完全一致。复现是排障闭环的终点，也是说服所有人“根因找到了”的唯一硬通货。标准允许多种实现，具体行为以各厂家官方文档为准，但PFCP双向通断这类传输层问题，任何厂家的实现都逃不开。

四、常见拒绝原因与高频根因速查

会话建立拒绝时，NAS层5GSM cause是最快的线索（完整列表见TS 24.501，以下为运维高频项摘录）：

高频根因清单，按我个人的现网遇见频率排序：

1. DNN/S-NSSAI多网元配置不一致——AMF、SMF、UDM签约、PCF策略四处对不齐，割接和放号期高发；
2. 传输类问题（VLAN未放通、MTU、防火墙策略、路由不对称）——本案例所属类别，占比不低且最难一眼看出；
3. NRF注册异常——NF心跳超时被注销、注册地址与实际不一致；
4. 时间不同步——NTP漂移导致跨网元日志时序错乱，排查时“因果颠倒”；严重点还会影响加密与计费；
5. 证书与licence到期——SBI TLS证书、网元licence的生命周期必须纳管并提前告警，这是“低级但致命”的经典坑，历史上不止一家运营商栽过跟头。

五、写在最后：核心网运维十条军规

1. 先对口径，再动手——相当比例的“故障”是两套统计口径在打架；
2. 时间同步是排查的生命线，跨网元日志对不上时序，一切分析都是猜；
3. 抓包点成对部署，单侧抓包会冤枉好网元；
4. UDP没有连接，防火墙和负载均衡的会话表是隐形的坑；
5. 变更后留足观察期，KPI跑不平、拨测不过，一律回退；
6. 配置基线可一键diff，手工改动必须进配置管理库；
7. 单用户Trace优先于全网抓包，TS 32.421/32.423的Trace能力别闲置；
8. 实验室常备开源5GC与终端模拟器，复现是排障闭环的终点；
9. 证书、licence、合约到期时间全部纳管，提前告警；
10. 每次故障写复盘，根因、证据、修复、验证四段缺一不可。

5GC把网络从“电路”解构成了“服务”，故障形态随之进化，但排障的底层逻辑从未改变：分层定界、证据说话、复现闭环。工具会过时，这三板斧不会。

参考来源

1. 3GPP TS 23.502 - Procedures for the 5G System — 5G系统流程规范，PDU会话建立流程的权威定义（第4.3.2.2节）
2. 3GPP TS 29.244 - PFCP between SMF and UPF — N4接口PFCP协议规范
3. Open5GS - 开源5G核心网与EPC — 开源5GC/EPC实现，可用于搭建实验室复现环境
4. free5GC - 开源5G核心网 — 遵循3GPP规范的开源5GC项目
5. UERANSIM - 开源5G UE与gNB模拟器 — 无需真实基站即可验证N2/N3/N1全流程的模拟工具

本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。