**概述**：早高峰，5G核心网PDU会话建立成功率从99.6%跌到93.8%，告警系统却一声不吭——因为门限卡在95%。为什么手机满格却上不了网？锅到底在终端、无线、AMF、SMF还是UPF？本文以3GPP TS 24.501定义的5GSM cause（失败原因值）为解读主轴，讲清楚一次PDU会话建立要过哪五道关、每个cause值指向谁的责任，并用一次双因叠加的跌量排查实录，沉淀出一套可复用的五步定位法。核心观点：cause值分布是比告警更早、更诚实的“网络病历”，运维团队应该把它变成资产，而不是日志垃圾。 ## 目录 - 一、曲线跌了三个点，告警却一声不吭 - 二、一次PDU会话建立，要过五道关 - 三、cause值：网元递给你的病历本 - 四、二十四小时破案实录：双因叠加的跌量 - 五、五步定位法：把排查变成SOP - 六、把cause值变成资产：从救火到防火 - 七、写在最后 ## 一、曲线跌了三个点，告警却一声不吭 核心网运维最怕的，不是红色告警刷屏，而是绿色屏幕底下藏着一条正在下坠的曲线。 PDU会话建立成功率，是5G核心网最要命的KPI之一——用户每次点亮数据开关、每次APP唤起联网请求，背后都是一次PDU会话建立。这个指标正常水位通常在99%以上：跌到98%，投诉开始冒头；跌到95%以下，客服电话就要被打爆。 麻烦在于，很多网管系统的KPI告警门限习惯性设在95%甚至更低。99.6%跌到96.5%，门限不破、告警不出，而用户侧已经大面积感知：手机显示5G满格，微信转圈，网页打不开。等投诉量把曲线“顶”进告警视野，往往已经过去两三个小时——这三个小时，就是纯纯的定位黄金期，也可能是_shutdown级的口碑损失期。 所以第一条经验：**别等告警，去看cause分布**。成功率的分母是尝试次数，分子是成功次数，而每一次失败都携带一个失败原因值（cause）。告警靠人设门限，cause是网元的“主观陈述”——它不会撒谎，只会被忽视。 ## 二、一次PDU会话建立，要过五道关 破案之前，先把流程捋清楚。以下描述是3GPP标准中可验证的规范行为，依据是TS 23.502（5G系统阶段2流程）与TS 24.501（5G NAS协议）这两份公开规范： 1. **终端发起**：UE通过gNB向AMF发送NAS层的PDU会话建立请求，里面带着DNN（数据网络名称，4G时代叫APN）、S-NSSAI（切片标识）、请求的会话类型（IPv4/IPv6/以太网）； 2. **AMF转手**：AMF不处理会话业务，它把请求转发给选中的SMF，创建SM上下文； 3. **SMF审签**：SMF去UDM核对用户签约——订了这个DNN吗？订了这个切片吗？会话类型在允许清单里吗？任何一关不过，直接拒绝并塞进cause值； 4. **SMF选路**：签约没问题，SMF通过NRF/DNS选择合适的UPF，经N4接口（PFCP协议）下发转发规则，打通用户面； 5. **结果回传**：成功，沿原路返回“PDU会话建立接受”；失败，返回“PDU会话建立拒绝”，拒绝消息携带5GSM cause值——这就是破案的指纹。 ```mermaid 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值，直接进对门。 ## 三、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值上，这种偏斜在健康网络里根本不会出现。 ## 五、五步定位法：把排查变成SOP 把这次和历年同类故障的经验沉淀下来，就是五步定位法。前四步是标准动作，可复制；每一步的门限取值属于笔者个人经验，仅供参考： ```mermaid 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值变成资产：从救火到防火 会抢修只是及格线，成熟团队会把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规范原文和所采购产品的官方文档为准。 ## 参考来源 1. [3GPP TS 24.501 — 5GS非接入层（NAS）协议](https://www.3gpp.org/dynareport/24501.htm) — 本文解读主轴：5GSM/5GMM cause值的权威定义与语义 2. [ETSI TS 124 501 规范全文（可下载）](https://www.etsi.org/deliver/etsi_ts/124500_124599/124501/) — cause值完整清单一手文本，第9章信息单元定义 3. [3GPP TS 23.502 — 5G系统流程规范](https://www.3gpp.org/dynareport/23502.htm) — PDU会话建立的标准流程与网元交互 4. [3GPP TS 38.413 — NGAP规范](https://www.3gpp.org/dynareport/38413.htm) — gNB与AMF间NGAP cause定义，用于无线侧失败归因 5. [ShareTechnote — 5G/NR技术笔记](https://www.sharetechnote.com/) — 一线工程师常用的5G信令流程与消息结构参考 --- > 本文由「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 等场景全覆盖。