概述：早高峰，5G核心网PDU会话建立成功率从99.6%跌到93.8%，告警系统却一声不吭——因为门限卡在95%。为什么手机满格却上不了网？锅到底在终端、无线、AMF、SMF还是UPF？本文以3GPP TS 24.501定义的5GSM cause（失败原因值）为解读主轴，讲清楚一次PDU会话建立要过哪五道关、每个cause值指向谁的责任，并用一次双因叠加的跌量排查实录，沉淀出一套可复用的五步定位法。核心观点：cause值分布是比告警更早、更诚实的“网络病历”，运维团队应该把它变成资产，而不是日志垃圾。
核心网运维最怕的，不是红色告警刷屏，而是绿色屏幕底下藏着一条正在下坠的曲线。
PDU会话建立成功率，是5G核心网最要命的KPI之一——用户每次点亮数据开关、每次APP唤起联网请求，背后都是一次PDU会话建立。这个指标正常水位通常在99%以上：跌到98%，投诉开始冒头；跌到95%以下，客服电话就要被打爆。
麻烦在于，很多网管系统的KPI告警门限习惯性设在95%甚至更低。99.6%跌到96.5%，门限不破、告警不出，而用户侧已经大面积感知：手机显示5G满格，微信转圈，网页打不开。等投诉量把曲线“顶”进告警视野，往往已经过去两三个小时——这三个小时，就是纯纯的定位黄金期，也可能是_shutdown级的口碑损失期。
所以第一条经验：别等告警，去看cause分布。成功率的分母是尝试次数，分子是成功次数，而每一次失败都携带一个失败原因值（cause）。告警靠人设门限，cause是网元的“主观陈述”——它不会撒谎，只会被忽视。
破案之前，先把流程捋清楚。以下描述是3GPP标准中可验证的规范行为，依据是TS 23.502（5G系统阶段2流程）与TS 24.501（5G NAS协议）这两份公开规范：
sequenceDiagram
participant U as UE终端
participant G as gNB基站
participant A as AMF
participant S as SMF
participant P as UPF
U->>G: RRC消息携带NAS会话建立请求
G->>A: NGAP上行NAS透传
A->>S: 创建SM上下文请求
S->>P: N4会话建立请求
P-->>S: N4会话建立响应
S-->>A: SM上下文创建应答
A-->>G: NGAP下行NAS透传
G-->>U: PDU会话建立接受或拒绝
Note over S,P: 拒绝时cause值多在SMF侧产生
五道关，意味着五个可能的责任层：终端、无线、AMF、SMF的签约与策略、UPF用户面。没有cause值指引的排查，是五层楼挨个翻；有了cause值，直接进对门。
5GSM cause值的权威定义在3GPP TS 24.501第9章的信息单元规范里。这套编号大量继承了4G时代TS 24.301的ESM cause体系（APN改名为DNN），4G运维老兵上手很快。下面是笔者工作手册里最常用的几行——完整清单请以规范原文为准：
| cause值 | 规范名称 | 通俗解读 | 常见根因 | 首查责任层 |
|---|---|---|---|---|
| #26 | insufficient resources | 资源不够 | UPF会话数触顶、license超限 | 用户面容量 |
| #27 | missing or unknown DNN | DNN不存在或不认识 | DNN拼写错误、SMF未配置该DNN、签约与配置不一致 | 配置一致性 |
| #28 | unknown PDU session type | 会话类型不支持 | 终端请求的类型网侧未开通 | 配置/签约 |
| #29 | user authentication or authorization failed | 认证授权失败 | UDM签约数据异常、AAA对接故障 | 签约数据链路 |
| #36 | regular deactivation | 正常去激活 | 正常释放场景 | 统计口径陷阱 |
| #39 | reactivation requested | 请求重建 | 网络侧要求重建会话 | 流程触发类 |
| #65 | LADN not available | LADN不可用 | 用户已离开LADN服务区域仍请求该DNN | 移动性/规划 |
| #67 | insufficient user plane resources | 用户面资源不足 | UPF容量或N4接口异常 | 用户面 |
三个使用要点，都是拿故障换来的：
第一，先分清是5GSM cause还是5GMM cause。 如果用户连注册都过不去，问题在移动性管理层，要看5GMM cause——#3非法UE、#7业务不允许、#11 PLMN不允许、#15跟踪区内无合适小区、#22拥塞，直接指向签约、鉴权或准入；只有注册成功但会话建不起来，才轮到5GSM cause出场。拿错病历本，查一天也是白查。
第二，警惕统计口径陷阱。 #36“正常去激活”是合法的流程性原因，如果成功率统计把它算成失败，指标会常年虚低；反过来，某些边界场景会被笼统报成#30（请求拒绝，未指明），掩住真凶。还要说明一点：3GPP只规定语义，各产品在具体场景上报哪个值属于实现自由，标准允许多种实现，具体行为以各厂家官方文档为准——所以cause分布必须对照自己网络的历史基线看，别照抄别人的“正常范围”。
第三，看分布，不看单条。 单条信令的cause可能是偶然，批量跌量时cause的分布形状才是铁证：集中在#27，基本是配置和签约打架；集中在#26/#67，往用户面容量查；均匀撒在十几个值上，反而要怀疑共用组件（NRF、DNS、N4链路）在抖。
下面这个案例来自笔者所在团队的一线处置。出于保密要求，运营商、网元型号与具体数值已做脱敏合成处理，请勿对号入座；但故障机理和排查路径是真实场景的还原。
背景：某省会城市5G公网+政企专网混合组网。周末例行发布一批配置变更：为一家新入驻的工业园区开通企业专属DNN，涉及SMF资源池的DNN配置、UDM签约数据、切片策略三处联动。
时间线：
| 时间 | 事件 |
|---|---|
| D0 周日 22:10 | 配置发布启动，SMF资源池按实例滚动下发 |
| D0 22:50 | 发布工具报告“完成”，实际两台SMF实例下发超时且未重试 |
| D1 周一 07:30 | 早高峰开始，成功率跌至93.8%，无KPI告警（门限95%） |
| D1 08:10 | 投诉量上升；值班按惯性先查无线，方向错误，耗掉1小时 |
| D1 09:30 | 信令平台拉取失败cause分布：68%集中在#27，且全部落在同一个SMF SET |
| D1 10:20 | 比对该SET与正常SET的配置差异，确认企业DNN在两台实例上缺失 |
| D1 10:40 | 追加发现：园区用户的S-NSSAI签约与AMF路由配置不符，夹杂少量#65 |
| D1 11:15 | 配置补齐并灰度生效，成功率20分钟内回到99.5%以上 |
| D1 22:00 | 复盘定责：发布工具无“部分失败”告警；KPI无按DNN/切片维度拆分 |
根因是双因叠加。主因：滚动下发中断导致SMF实例间配置不一致——同一个DNN，SET里A实例认识、B实例不认识，请求恰好落到B实例就被#27拒绝。次因：新开通企业的切片签约、AMF路由、SMF配置三方数据没做一致性校验，留下#65的尾巴。影响面评估：跌量持续约3小时45分，波及园区用户及部分被调度到问题实例的公网用户，投诉约400余件。
最大的教训不在技术，而在观测面：如果当天有“cause分布异常偏斜”监控，08:10之前就能定位，不用等投诉。68%的失败集中在一个cause值上，这种偏斜在健康网络里根本不会出现。
把这次和历年同类故障的经验沉淀下来，就是五步定位法。前四步是标准动作，可复制；每一步的门限取值属于笔者个人经验，仅供参考：
flowchart TD
A["PDU会话成功率下跌"] --> B["第一步：拉取cause分布"]
B --> C["分布集中在少数值"]
B --> D["分布高度分散"]
C --> E["第二步：按cause切责任层"]
E --> F["DNN签约类：查三方一致性"]
E --> G["资源容量类：查UPF与N4"]
E --> H["终端类：按机型分群抓包"]
D --> I["第三步：查共用组件"]
I --> J["NRF、DNS、N4链路、license"]
F --> K["第四步：差异比对+灰度修复"]
G --> K
H --> K
J --> K
K --> L["第五步：复盘补监控"]
| 步骤 | 动作 | 关键抓手 |
|---|---|---|
| 1 | 拉失败cause分布，按数量排序 | 前3个cause占比是否超50% |
| 2 | 按cause映射责任层 | 用速查表圈定一层，再动手 |
| 3 | 分布分散时查共用组件 | N4心跳、NRF状态、DNS解析、license水位 |
| 4 | 差异比对+灰度修复 | 故障实例与正常实例配置diff；先回滚，后追因 |
| 5 | 复盘补观测 | 给cause分布加偏斜告警，给KPI加维度拆分 |
这套SOP的精髓是先收敛再深入：不跳过第一步直接抓包，不跳过分布直接看单用户。见过太多排障败在拿着抓包工具从第一条信令开始读——那是学习方法，不是抢修方法。
会抢修只是及格线，成熟团队会把cause数据变成三样东西：
一是告警体系的“第二只眼”。 相比KPI绝对值门限，cause分布偏斜度对配置类故障敏感得多：某个cause值24小时占比超出历史基线三个标准差，或某个SMF SET的cause构成突变，都值得一条低级别告警。这类告警误报率低，因为它测的是“网络行为形状变了”，而不是“数字掉了”。
二是变更发布的预检门禁。 涉及DNN、S-NSSAI、LADN的变更，发布前必须跑一遍三方一致性校验（UDM签约、AMF路由、SMF配置）；发布后必须用测试UE做新DNN的真实建立验证，而不是看发布工具显示“成功”。滚动下发场景要加“实例级完成度”校验——部分失败必须显式告警并可一键重试。本次案例里那条22:50的“完成”报告，就是最贵的一句谎话。
三是KPI的维度拆分。 全网平均成功率是一层雾：按DNN、按切片、按SMF SET、按终端型号拆开才是路。案例里全网93.8%的背后，是某个DNN的归零加某个SET的单侧塌陷——维度拆开，故障自己会跳出来。这两年大模型开始进网管做异常归因，但无论算法多花哨，喂给它的特征里如果没有cause分布，就是让厨师空手上灶。先把数据底座建好，AI才有用武之地。
干了十八年核心网，笔者的体会是：网络从不把故障藏起来，它把答案写在每一次拒绝消息的cause值里，只是我们常常懒得看。
TS 24.501里那些干巴巴的编号，落到现网就是一个个具体场景：一个拼错的DNN、一次中断的下发、一份没同步的签约。标准给出的是词汇表，运维的工作是用这些词汇读懂网络每天讲的故事。把cause值从日志垃圾变成监控资产、变成发布门禁、变成复盘锚点，你的网络会开始“说话”——在用户投诉之前。
最后提醒：本文速查表只覆盖最常用条目，完整cause语义、取值边界与各产品的上报行为，请以3GPP规范原文和所采购产品的官方文档为准。
本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。
[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。