3、核心网异常分类体系
做核心网运维这些年，我最大的体会就是：异常不可怕，可怕的是你不知道它属于哪一类。就像医生看病，先得知道是感冒还是肺炎，才能对症下药。今天我就把这七类核心网异常掰开揉碎了讲给你听。
核心观点：异常分类是故障定位的第一步。分对了类，你就成功了一半。
3.1 信令风暴
信令风暴，说白了就是信令通道被挤爆了。我2019年处理过一个案例——某市地铁早高峰，大量用户同时从隧道切换到站台，MME的S1AP信令瞬间飙升到平时的20倍。嗯，那场面，监控大屏直接飘红。
为什么会这样？核心网的信令处理能力是有上限的。当大量终端同时发起附着、TAU、业务请求时，信令链路就像早高峰的收费站——车太多，道太少。
- 典型场景：大型活动（演唱会、体育赛事）、地铁/高铁移动场景、物联网终端批量上线
- 关键指标：每秒信令事务数（TPS）、信令链路利用率、MME/S-CSCF CPU负载
- 影响范围：轻则用户接入失败，重则全网瘫痪
我的经验：信令风暴往往有前兆。我习惯在监控系统里设置两级阈值——黄色预警（70%容量）和红色告警（85%容量）。别等到100%才动手，那时候已经晚了。
3.2 用户面丢包
用户面丢包，这是用户感知最直接的异常。你想想看，用户正在看视频，突然卡住了——大概率就是用户面出了问题。
我在项目中遇到过一种情况：UPF和gNB之间的N3接口，某条链路的误码率突然升高，导致GTP-U报文大量重传。用户反馈说「网速慢」，实际上是有30%的包丢了。
| 丢包类型 | 常见原因 | 排查手段 |
|---|---|---|
| N3接口丢包 | 传输链路质量差、MTU配置不当 | ping大包测试、抓包分析 |
| N6接口丢包 | 防火墙策略、NAT表项溢出 | 流量镜像、会话表检查 |
| 内部转发丢包 | UPF转发性能瓶颈、缓存溢出 | CPU/内存监控、硬件计数器 |
避坑指南：我曾经遇到一个案例，丢包率只有0.1%，但用户投诉不断。后来发现是周期性丢包——每10秒丢一个包，刚好卡在视频关键帧上。所以，丢包率低不等于没问题，要看丢包模式。
3.3 网元过载
网元过载，就是某个网元「累趴了」。我见过最夸张的一次，某AMF的CPU跑到98%，处理一个注册请求要5秒钟——正常应该是50毫秒。
过载的原因无非三种：
- 硬件资源不足：CPU、内存、磁盘I/O达到瓶颈
- 软件缺陷：内存泄漏、线程死锁、消息队列积压
- 流量突增：超出设计容量（比如突发的大规模接入）
我个人习惯用「三层过载检测法」：
- 第一层：系统级指标（CPU、内存、磁盘）——5秒采集一次
- 第二层：进程级指标（每个NF进程的线程数、句柄数）——30秒采集一次
- 第三层：业务级指标（消息处理时延、队列深度）——1分钟采集一次
3.4 会话建立失败
会话建立失败，这是5G核心网里最常见的异常之一。用户手机显示5G信号满格，但就是上不了网——十有八九是PDU会话建立失败了。
我总结了一个「会话建立失败五步排查法」：
- 第一步：看信令——是N1还是N2消息失败？
- 第二步：看原因值——3GPP规范里定义了几百个Cause值，每个都有含义
- 第三步：看切片——是不是切片资源不够？
- 第四步：看策略——PCF下发的QoS策略是否合理？
- 第五步：看传输——N4接口（SMF-UPF）是否正常？
关键点：会话建立失败的原因值，一定要看3GPP TS 24.501和TS 29.502。别自己瞎猜，规范里写得清清楚楚。
3.5 注册失败
注册失败，用户连网都上不了。这比会话建立失败更严重——手机连注册都过不去，直接显示「无服务」。
常见的注册失败场景：
- SUCI解密失败：UDM和AUSF之间的密钥不匹配
- 鉴权向量获取失败：UDM返回了错误的鉴权参数
- AMF选择错误：gNB把用户路由到了错误的AMF
- NSSF返回无效切片：用户请求的S-NSSAI不被允许
我记得有一次，某省用户大面积注册失败。查了两天，最后发现是UDM的数据库表空间满了——新用户无法写入鉴权数据。嗯，这种低级错误，往往最隐蔽。
3.6 PDU会话异常
PDU会话异常，指的是已经建立好的会话突然出问题。用户正在刷抖音，突然断了——这就是典型的PDU会话异常。
我把它分为三类：
| 异常类型 | 表现 | 常见原因 |
|---|---|---|
| 会话释放异常 | 用户无故掉线 | UPF检测到N3隧道超时、SMF策略冲突 |
| QoS降级 | 网速变慢、时延变大 | 无线侧资源不足、核心网QoS参数协商失败 |
| UPF路径切换失败 | 用户移动后业务中断 | N9接口转发异常、UPF间隧道建立失败 |
我的习惯：PDU会话异常，我第一件事就是查N4会话的存活状态。SMF和UPF之间的N4接口，是PDU会话的「生命线」。N4断了，会话必死。
3.7 切片资源枯竭
切片资源枯竭，这是5G特有的异常。说白了，就是某个网络切片「满客了」。
举个例子：某运营商给工业互联网客户分配了一个切片，S-NSSAI是1-123456，带宽100Mbps，最大用户数1000。结果客户搞了个促销活动，一下子涌进来2000个终端——切片资源直接爆了。
切片资源枯竭的典型表现：
- NSSF返回切片不可用：用户请求的S-NSSAI被拒绝
- AMF/SMF过载：特定切片内的网元负载过高
- UPF带宽超限：切片内的流量超过签约带宽
避坑指南：我曾经遇到一个案例，切片资源明明还有余量，但用户就是无法接入。查了半天，发现是NSSF的切片配额缓存没有及时更新——资源释放了，但NSSF不知道。所以，切片资源的实时同步非常重要。
好了，这七类异常，就是核心网运维的「七种武器」。你想想看，每次故障，是不是都能归到其中一类？
我个人建议，把这七类异常做成一张检查表，贴在工位上。每次接到告警，先问自己三个问题：
- 这是哪一类异常？
- 影响范围有多大？
- 我手头有没有现成的处理脚本？
嗯，有了分类体系，你就不会慌了。
公众号:蓝海资料掘金营，微信deep3321