<!-- title: 5GC信令排查实战三板斧 -->

# 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时代 |
| --- | --- | --- |
| 控制面协议 | GTP-C v2（UDP 2123）、Diameter | SBI：HTTP/2 + JSON，服务化接口 |
| 定界依据 | GTP-C cause、Diameter结果码 | HTTP状态码 + ProblemDetails + 5GSM cause |
| 网元关系 | 链路静态配置，拓扑固定 | NRF动态注册发现，实例随时漂移 |
| 部署形态 | 虚机/专用设备，边界清晰 | 容器微服务，一个网元几十个实例 |
| 排查盲区 | 相对少，抓单点包即可 | 防火墙/LB会话表、容器网络、NRF选路 |
| 典型工具 | GTP-C抓包 + 网元告警 | 跨接口抓包 + 分布式日志/指标/Trace |

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

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

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

### 2.1 背景与现象

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

### 2.2 时间线

| 时间 | 事件 | 动作 |
| --- | --- | --- |
| 20:47 | 成功率越过阈值告警 | 值班启动应急，先看告警面板 |
| 20:52 | 发现无线侧统计成功率99.0%正常，核心网侧94.1% | 意识到口径打架，先对口径 |
| 21:02 | 对齐口径：核心网口径含SMF拒绝场景，锁定差异在SMF | 随机抽取失败话单 |
| 21:08 | 单用户Trace显示：NAS层PDU会话建立请求发出后收到拒绝 | 定界到核心网侧 |
| 21:15 | SMF日志批量出现N4会话建立超时 | 检查SMF与UPF之间链路 |
| 21:20 | SMF侧抓包：PFCP请求反复重发、无响应 | 抓包点成对部署到UPF侧 |
| 21:28 | UPF侧抓包：请求已收到且已回复，响应出不了机房 | 定界到传输安全设备 |
| 21:35 | 确认：新UPF回程流量经另一台防火墙，无会话表项被丢 | 应急旁路防火墙策略 |
| 21:50 | 成功率回升到99%以上 | 进入观察期，次日组织复盘 |

### 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 信令断点示意图

```mermaid
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。每一跳都有独立的观测量：

```mermaid
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技巧

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

| 接口 | 协议与端口 | 抓包关注点 |
| --- | --- | --- |
| N2 | NGAP / SCTP 38412 | 偶联状态、T1重传、Heartbeat、NG Setup |
| N4 | PFCP / UDP 8805 | 请求与响应的Sequence Number配对、SEID、重发间隔 |
| N3/N9 | GTP-U / UDP 2152 | 内层IP连通性、QFI、分片与MTU |
| SBI | HTTP/2（TCP/TLS） | 3xxx/4xx/5xx状态码、ProblemDetails、stream阻塞 |
| N11 | SBI（AMF-SMF） | Nsmf_PDUSession_CreateSMContext成败 |

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是运维的“风洞”

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

| 工具 | 角色 | 实战用途 |
| --- | --- | --- |
| Open5GS | 开源5GC（EPC/5GC双模） | 搭建AMF/SMF/UPF全功能实验室 |
| free5GC | 开源5GC（3GPP R15+） | SBI调用链研究、二次开发验证 |
| UERANSIM | gNB+UE模拟器 | 无需真基站即可跑通N2/N3/N1全流程 |
| Wireshark | 协议解码 | 5GC全协议栈分析 |
| tcpdump | 现网采集 | 配合交换机镜像口部署 |
| Prometheus + Grafana | 指标监控 | 核心网KPI可视化与阈值告警 |
| Loki / ELK | 日志聚合 | 容器化网元日志集中检索 |
| iperf3 / netshoot | 传输面验证 | MTU、路由、防火墙策略双向验证 |

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

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

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

| 5GSM Cause | 含义 | 典型根因 |
| --- | --- | --- |
| #26 | 资源不足 | UPF容量打满、许可（licence）未扩容 |
| #27 | 缺失或未知DNN | DNN拼写错误、未签约、网侧未配置 |
| #28 | 未知PDU会话类型 | 终端请求类型与网侧配置不一致 |
| #31 | 请求被拒绝，未指明原因 | 需结合SMF日志定位，常为内部处理失败 |
| #65 | 特定切片和DNN组合资源不足 | S-NSSAI未在全网元一致放通 |

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

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](https://www.3gpp.org/dynareport/23502.htm) — 5G系统流程规范，PDU会话建立流程的权威定义（第4.3.2.2节）
2. [3GPP TS 29.244 - PFCP between SMF and UPF](https://www.3gpp.org/dynareport/29244.htm) — N4接口PFCP协议规范
3. [Open5GS - 开源5G核心网与EPC](https://github.com/open5gs/open5gs) — 开源5GC/EPC实现，可用于搭建实验室复现环境
4. [free5GC - 开源5G核心网](https://github.com/free5gc/free5gc) — 遵循3GPP规范的开源5GC项目
5. [UERANSIM - 开源5G UE与gNB模拟器](https://github.com/aligungr/UERANSIM) — 无需真实基站即可验证N2/N3/N1全流程的模拟工具

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