# 被叫不通背后：一次5G寻呼成功率劣化的完整排查复盘
## 概述
“用户关机”？“不在服务区”？当VoNR被叫接通率突然从99%量级跌落，投诉工单涌向客服时，核心网和无线专业往往互相甩锅——AMF说寻呼消息都发出去了，gNB说空口什么都没收到。本文以一个脱敏自多个真实项目的复合案例为载体，完整复盘一次寻呼成功率劣化从发现、定位到根因的全过程：新开站TAC规划错误叠加寻呼策略配置不当，造成“_register在A区、人躺在B区”的隐形黑洞。文章同时给出一套可直接落地的五级排查阶梯、分层检查清单，以及寻呼过载保护和AI寻呼预测等进阶优化方向。读者读完应能回答：寻呼失败到底该先查什么、按什么顺序查、哪些定时器和信元是关键证据。
## 一、为什么寻呼是“最跨域”的KPI
在核心网做了十几年，我的体会是：附着成功率、会话建立率出问题，责任界面基本清晰；唯独**寻呼成功率（Paging Success Rate）**，天生就是核心网、承载、无线、终端四个域的“交叉地带”。
按3GPP TS 23.502定义的网络触发业务请求（Network Triggered Service Request）流程，一次完整的被叫接通要闯五关：
1. **AMF决定寻呼**——SMF发来Downlink Data Notification，或被叫信令到达，AMF确认UE处于CM-IDLE，决策发起寻呼；
2. **NGAP Paging下发**——AMF按UE注册的TAI列表，通过N2口向相关gNB发NGAP Paging消息（TS 38.413）；
3. **空口广播**——gNB在UE的寻呼时机（PO，由DRX周期计算）用P-RNTI加扰的PDCCH调度寻呼；
4. **UE响应**——UE识别到自己的5G-S-TMSI，发起Service Request（空闲态）或RRCResumeRequest（非激活态）；
5. **业务恢复**——N2/N3用户面资源重建，下行数据从UPF缓存中吐出。
free5GC的技术博客把前三步概括得很清楚：AMF依据AMF context中保存的Registration Area/TA信息缩小gNB范围，UE按DRX周期“醒来—监听—没找到自己就继续睡”。**任何一关断了，表现出来都是同一个症状：被叫不通。** 这就是寻呼排障为什么容易变成“罗生门”。
更麻烦的是，寻呼失败的三种经典成因——UE无响应、寻呼区域错误、网络拥塞——分别指向完全不同的团队。所以行业里需要一个统一的排查阶梯，先切分“断在第几关”，再谈根因。
## 二、案例复盘：地铁新线开通后的“隐形黑洞”
> 说明：以下为作者亲历的多个项目脱敏合并而成的复合案例，网络数据做了量级化处理，不对应任何单一运营商的公开数据。
### 2.1 现象
某城市地铁新线开通两周后，网优侧发现新线沿线区域的指标出现三个异常：
- VoNR被叫接通率从99.2%左右滑落到96%上下，且**劣化高度集中在沿线的十几个新建站**；
- AMF侧统计的寻呼下发量正常，但**T3513超时无响应比例**在这些区域明显偏高；
- 客服工单的关键词高度一致：“别人打我电话提示无法接通，但我能打出去”。
“能主叫、被叫不通”——这是寻呼问题的教科书式症状。主叫是UE主动发起Service Request，不需要网络找到它；被叫要网络在正确的时间、正确的区域把UE“喊醒”。
### 2.2 排查时间线
```mermaid
timeline
title 案例排查时间线（脱敏复合案例）
第1天 : 客服投诉量异常聚集 : 网优发现新线区域被叫接通率劣化3个百分点
第2天 : 核心网自查 : AMF侧确认NGAP Paging均已发出且收到gNB确认
第3天 : 无线侧自查 : 空口寻呼发送正常、无拥塞告警 : 双方陷入"各自都没问题"僵局
第4天 : 分层切分 : 按五级阶梯定位断点在"空口广播/UE响应"之间 : 关联发现劣化站均为新开站
第5天 : 根因确认 : 新开站SIB1广播TAC抄错邻站值 : UE重选至新站后TAI与注册区不匹配
第6-7天 : 整改验证 : 修正TAC并重查全线TAC规划 : 接通率回升至99%量级
```
### 2.3 关键转折：先切分断点，再谈根因
前三天僵局的根源是双方都在“自证清白”：核心网证明“我发了”，无线证明“我广播了”。第四天换思路——**不再争论谁的问题，而是用信令证据确定“第一个硬断点”在哪里**。
参考3glteinfo给出的故障隔离框架，寻呼问题必须先分成四种场景，因为它们的下一步动作完全不同：
| 场景 | 现象 | 断点位置 | 下一步该查什么 |
|---|---|---|---|
| 压根没寻呼 | AMF无寻呼决策记录 | 寻呼生成之前 | 下行数据通知是否到达、UE状态是否CM-IDLE、是否被策略限制 |
| 寻呼了但UE无响应 | T3513超时 | 空口广播或UE监测 | TAI/TAC对齐、覆盖、DRX/eDRX窗口 |
| UE响应了但恢复失败 | Service Request被拒 | RRC恢复或NAS层 | Service Reject原因值、T3447/T3448、上下文一致性 |
| 恢复成功但没流量 | UE可达但业务不通 | N3/UPF | PDU会话重激活结果、隧道与QoS |
本案例属于第二类：**AMF发了、gNB广播了、但UE没响应**。而UE“不响应”未必是无线信号差——它可能压根 camp 在了错误的区域上。
### 2.4 根因：一个抄错的TAC
对劣化小区逐站解码SIB1后，问题浮出水面：**部分新开站的`trackingAreaCode`字段直接抄用了邻站规划文档中的旧值**，导致这些站广播的TAI与其所属的AMF注册区不一致。
故障链是这样的：
```mermaid
flowchart TD
A[新开站SIB1广播错误TAC] --> B[空闲态UE重选进入该站]
B --> C[UE在错误TAI下驻留
但未触发注册更新]
D[被叫到达] --> E[AMF按注册TAI列表下发NGAP Paging]
E --> F[gNB在正确的TA内广播寻呼]
F --> G[UE实际驻留在错误TA的小区
在自己的PO上永远等不到寻呼]
G --> H[T3513超时
被叫失败]
```
值得说明的是，TAC不匹配的故障谱系里，UE的行为取决于它是“路过”还是“驻留”：如果UE在移动中做注册更新，AMF会以Registration Reject明确拒绝，原因值通常是**#12（Tracking area not allowed）、#13（Roaming not allowed in this tracking area）、#15（No suitable cells in tracking area）**之一，投诉会表现为“注册失败”；而本案例中UE通过重选静默驻留、又恰好在注册周期更新边界内，形成了更隐蔽的“不报错、只是喊不应”状态——这正是它难查的原因。
三个原因值在现网中最容易被混为一谈，实操中必须分清：
| 原因值 | 含义 | UE该做什么 | 排查方向 |
|---|---|---|---|
| #12 | 该TA对该用户不允许 | 停止在该TA尝试 | 签约区域限制、PLMN+TAC组合 |
| #13 | 该TA不允许漫游 | 寻找其他允许的TA | 漫游策略、区域授权 |
| #15 | TA内无合适小区 | 重选其他小区/PLMN | 邻区与TAC连续性、小区suitable条件 |
5G的TAC是24比特，容量比4G大得多，规划工具批量生成时一个模板错误就能污染一整条新线。**新站开通的TAC核查清单里，“与邻站广播值比对”必须是强制项**，不能只看网管配置库——网管库里的值是对的、空口广播出去的值是错的，这种“账实不符”恰恰是本案例的陷阱。
### 2.5 整改与验证
- 立即项：修正错误TAC并重启相关小区广播，逐站用路测终端解码SIB1比对规划值；
- 短期项：将TAC一致性核查纳入新站开通验收的自动化脚本（批量抓取SIB1与网管配置做diff）；
- 中期项：在AMF侧增加TAI突变监控——当同一TAC下的注册量出现断崖式变化时提前告警。
整改后一周，该区域被叫接通率回到99%量级，T3513无响应比例回落到基线水平。
## 三、沉淀：寻呼排障的五级阶梯与检查清单
把这个案例的方法论沉淀下来，就是一套“先切分、后深挖”的五级阶梯。每一级都有明确的证据标准和升级条件，避免“各查各的”式内耗。
### 3.1 五级阶梯
```mermaid
flowchart TD
S[被叫不通工单/寻呼成功率劣化] --> L1{L1: AMF是否发起寻呼?}
L1 -- 否 --> R1[查下行数据通知/UE状态/寻呼策略限制]
L1 -- 是 --> L2{L2: NGAP Paging是否送达gNB?}
L2 -- 否 --> R2[查N2链路/TAI列表与gNB归属映射]
L2 -- 是 --> L3{L3: UE是否响应?}
L3 -- 否 --> R3[查SIB1 TAC/TAI对齐/覆盖/DRX窗口
本案例断点在此]
L3 -- 是 --> L4{L4: Service Request是否成功?}
L4 -- 否 --> R4[解码Service Reject原因值
查T3517/T3447/T3448]
L4 -- 是 --> L5{L5: 业务是否恢复?}
L5 -- 否 --> R5[查PDU会话重激活/N3隧道/UPF]
```
### 3.2 分层检查清单
| 层 | 关键证据 | 常见坑 |
|---|---|---|
| AMF/核心网 | 寻呼触发原因、NGAP Paging记录、T3513结果、策略限制标记 | 把“发了没人应”一律归因无线，忽略TAI映射错误 |
| NGAP/承载 | gNB是否回Paging ACK、N2关联状态 | 传输闪断导致偶发丢失，需按次数聚合而非单看告警 |
| 无线空口 | SIB1的TAC/PLMN广播值、邻区TAC连续性、PO与DRX配置 | 网管配置与空口广播“账实不符”；eDRX窗口理解错误 |
| NAS/终端 | Registration/Service Reject原因值、重试行为 | 混淆#12/#13/#15；忽略终端节电特性导致的响应延迟 |
| 用户面 | PDU会话重激活结果、N3隧道状态 | UE可达≠业务恢复，重激活范围与期望不符 |
几个值得强调的实操细节：
- **定时器是天然的“断点标签”**。T3513是AMF的寻呼监督定时器，T3517管Service Request监督，T3447/T3448涉及退避与控制面限制。哪个定时器到期，断点就在哪一段，这是跨团队对齐时最无歧义的语言。
- **“UE响应了”是一个分水岭**。一旦UE开始发起接入或Service Request，寻呼本身就成功了，后续失败要换一套完全不同的排查思路——继续盯着寻呼查只会浪费时间。
- **偶发性劣化优先查“账实不符”**。网管库值与空口广播值不一致、多厂商边界的TAI映射表不同步，这类问题单体失败率不高，但覆盖面大，最能拉低整体KPI。
## 四、进阶优化：从“查得快”到“不发错”
排障是防守，优化是进攻。三个方向值得投入：
**其一是寻呼策略精细化。** 3GPP TS 23.502允许AMF采用子区域寻呼（sub-area based paging）策略：先在UE最后已知小区寻呼一次，无响应再扩大到整个注册TA重试。free5GC的技术文章也提到，AMF在多次重试失败后还可协调邻AMF转发寻呼。合理设置“先小后大”的两段式策略，可以在成功率和空口信令量之间取得更好的平衡。
**其二是寻呼过载保护。** 大规模故障恢复（比如大片基站掉电后集中回网）时，积压的下行数据会触发寻呼风暴。主流商用AMF都有对应机制——以Cisco UCC 5G AMF 2026.03配置手册为例，其Paging Overload Protection特性提供寻呼限速，被丢弃的NGAP寻呼消息通过`RateLimitPaging_Dropped`计数器统计。**关键不是有没有这个功能，而是阈值有没有按本网话务模型校准过**——很多网络出厂默认值直接上生产，出事才知道没调过。
**其三是AI寻呼预测。** 学术界和开源社区的思路已经比较收敛：用LSTM等序列模型预测空闲态UE的下一驻留小区，AMF先寻呼预测小区、失败再回退全TA寻呼。MDPI发表的论文在5G仿真环境下验证了基于机器学习与马尔可夫过程的概率寻呼可显著减少寻呼信令；GitHub上的开源项目`ai-assisted-paging-5g`则给出了完整的“移动性仿真器+LSTM预测+顺序寻呼”实现，并明确对标3GPP TS 23.288定义的NWDAF架构——由NWDAF收集服务小区历史、切换频次等数据做预测，通过分析输出供AMF消费。这套路线与3GPP正在讨论的AI原生核心网方向一致，值得网优团队在测试床上先跑起来。
## 五、经验教训
复盘到此，四条经验送给同行：
1. **先切分断点，再讨论归属。** 寻呼问题的团队内耗，90%源于跳过“断在第几关”直接争论“谁的问题”。T3513超时无响应和Service Reject被拒，是两个世界的问题。
2. **空口广播值必须实测核查。** 网管配置正确不等于网络正确。新站开通验收里，SIB1解码比对应该是自动化强制项——本案例一个抄错的TAC，两周内悄悄吃掉了3个点的接通率，还没有任何告警。
3. **分清三个TA相关拒绝原因值。** #12查签约、#13查漫游、#15查小区suitability，方向完全不同。把#13当成#12去查签约，会白耗一整天。
4. **UE可达不等于业务恢复。** 寻呼成功、Service Request成功之后，还有PDU会话重激活这道坎。被叫排障的最后一公里在N3和UPF，不在空口。
寻呼是移动网里最古老的机制之一，从GSM时代活到5G时代，逻辑没变，但5G把它拆成了更细的步骤、更多的定时器和更开放的策略空间。机制越开放，“账实相符”就越重要——这大概就是运维这份工作十八年来教会我的最重要的一课。
## 参考来源
1. [Paging in 5G Network — free5GC官方博客](https://free5gc.org/blog/20241204/20241204/) — 5G寻呼流程、触发条件、错误处理与重试策略的权威开源实现方解读
2. [5G Paging and Service Resume Troubleshooting — 3GLTEInfo](https://www.3glteinfo.com/troubleshooting/5g/paging-and-idle-mode-issues/paging-and-service-resume-troubleshooting/) — 寻呼失败阶梯式隔离框架，T3513/T3517/T3447/T3448定时器与证据清单
3. [5G TAI and Tracking Area Mismatch Troubleshooting — 3GLTEInfo](https://www.3glteinfo.com/troubleshooting/5g/registration-and-access-failures/tai-and-tracking-area-mismatch/) — SIB1 TAC广播核查、Registration Reject原因值#12/#13/#15辨析
4. [Cisco UCC 5G AMF Configuration Guide, Release 2026.03 — AMF Message Rate Control](https://www.cisco.com/c/en/us/td/docs/wireless/ucc/amf/2026-03/config-and-admin/ucc-5g-amf-config-and-admin-guide-2026-03/m_amf-message-rate-control.html) — 商用AMF寻呼过载保护与RateLimitPaging_Dropped统计
5. [ai-assisted-paging-5g — GitHub开源项目](https://github.com/jimjed/ai-assisted-paging-5g) — LSTM移动性预测+顺序寻呼的开源实现，对标3GPP NWDAF（TS 23.288）
6. [Machine Learning-Based Paging Enhancement in 5G Network — MDPI Applied Sciences](https://www.mdpi.com/2076-3417/12/19/9555) — 基于机器学习的概率寻呼在5G AMF中的性能评估
---
> 本文由「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 等场景全覆盖。
