**寻呼掉坑记：成功率阴跌排查实录** ## 概述 手机待机时是“睡着”的，网络想找它，只能靠寻呼（Paging）在正确的时刻、正确的小区把它叫醒。这个机制平时安静得让人忘记它的存在，可一旦寻呼成功率开始阴跌，用户感受到的就是“别人打我电话打不通”、“验证码短信收不到”。本文以一次典型的寻呼成功率劣化排查为主线（案例经脱敏与合并处理，不指向任何具体运营商，时间与数字为该类故障的典型量级），把寻呼的空口机制、失败根因的六种身世、从核心网到终端的三层排查法、以及一份可落地的优化清单一次讲透。文中协议机制与定时器均出自 3GPP TS 38.304、TS 24.501、TS 23.501 等规范。 ## 目录 - 一、寻呼是什么：让睡着的手机醒来 - 二、一次阴跌的完整复盘（脱敏案例） - 三、寻呼失败的六种身世 - 四、排查工具链与决策树 - 五、优化清单：TAC、二次寻呼与物联网卡治理 - 六、写在最后 ## 一、寻呼是什么：让睡着的手机醒来 先纠正一个常见误解：你手机信号格满格，不代表网络随时能把电话打进来。待机状态下，终端并不“守着”空口收数据，而是按寻呼非连续接收周期（Paging DRX）沉沉浮浮——绝大多数时间射频通道关闭、省电休眠，只在属于自己的那一小段窗口醒来，扫一眼有没有叫自己。 这段窗口是算出来的，不是碰运气。以 LTE 和 5G NR 通用的机制（规范见 TS 36.304 / TS 38.304）为例：终端用自己身份标识的一个派生值（如 IMSI 对 1024 取模，5G 里则来自 5G-S-TMSI），结合网络广播的 DRX 周期参数，定位到自己的**寻呼帧（PF）和寻呼时机（PO）**——规范里那个经典公式 `SFN mod T = (T div N) × (UE_ID mod N)` 说的就是这件事。DRX 周期 T 通常取 32/64/128/256 个无线帧，对应 320 毫秒到 2.56 秒。也就是说，全网上亿部待机手机，被规范整齐地撒进了不同的时间格子，基站在每个格子口“点名”一次，谁的反应窗口到了就只喊谁。 网络侧找终端的完整链路是这样的：有下行数据或来电到达，核心网（4G 的 MME / 5G 的 AMF）查库拿到终端最后登记的**跟踪区（TA）**，向该跟踪区内所有基站下发寻呼消息，基站在各小区按各自的 PO 发出寻呼。终端被叫醒后回一个业务请求，连接重建，话音或数据才接得通。任何一环掉链子——终端不在登记的跟踪区、休眠太深错过了窗口、空口资源被挤占——寻呼就失败，用户侧就是“第一响没人接”。 5G 还给这套机制加了一层新花样：**RRC_INACTIVE 非激活态**（TS 23.501 / TS 38.304）。终端保持着像“半睡半醒”的中间态——上下文还留在基站里，移动时只在较小的 RNA 通知区内更新。寻呼也分了两级：基站先自己发**RAN 寻呼**，叫不醒再升级请 AMF 发**CN 寻呼**。此外 R17 引入了**寻呼提前指示（PEI）**：先发一个极短的指示信号，终端醒来只需侦测这个信号，有真寻呼才完全唤醒，进一步省电。机制越精细，可调的东西就越多，出问题的姿势也越多——这正是运维要面对的现实。 ## 二、一次阴跌的完整复盘（脱敏案例） 下面这段复盘是典型排查过程的脱敏重演，数字为该类故障的常见量级，但每一步手法都可以直接照抄。 **D0，周报里的异常。** 月度质量周报显示，某地市寻呼成功率从 99.2% 连续两周阴跌到 96.8%。单日看跌幅都不大，没人立案；但两周曲线连起来，方向明确。更扎眼的是另一组数字：同期寻呼请求总量上涨了约四成，话务量却基本没动。**发出去的“点名”多了四成，接通的电话没多——说明大量寻呼发出去就石沉大海。** **D+1，先分责任面。** 寻呼成功率是端到端指标，第一步永远是拆口径：按核心网下发记录统计，AMF 侧发出的寻呼全部正常送达基站（N2 口无丢包、偶联稳定，对照 SCTP 健康度可确认）；空口侧统计显示，寻呼下发后终端无响应的占比飙升。责任面收敛到**空口与终端之间**。 **D+2，按地理位置聚合。** 把寻呼失败记录按 TAC 拆分，两个相邻 TAC 的交界区域贡献了六成以上的失败量，而且失败热点沿一条新开通的城郊快速路延展。这是第一个强信号：**跟踪区边界出了状况**。 **D+3，按终端类型再拆。** 把失败记录再按用户类型分组，物联网卡终端占比高的 TAC 劣化更明显；进一步查这些卡的注册行为，发现一批 NB-IoT 卡配置了很长的扩展DRX（eDRX）周期——部分可达窗口拉长到小时级，寻呼消息发过去时终端根本不在“醒着”的窗口里，失败是必然的。 **D+5，现场核查对上了。** 优化的同事去现场：快速路通车后，沿线的物流园区和新工地涌进了大量人口和车联网/物流跟踪卡。人群每天在两个 TAC 之间往返，边界小区上终端频繁重选、频繁位置更新；更麻烦的是，同园区几百张物联网卡出厂配置相同，**身份派生值相近的卡被规范算进了同一个 PO**，几百张卡挤在一个点名格子里轮流抢有限的下行控制信道资源，人网手机的寻呼消息跟着遭殃——这就解释了为什么“物联网卡多的区域，人也打不通”。 **D+7 到 D+12，三步处置。** 一是重划 TAC 边界，把沿快速路的“拉链式”边界改成沿人口稀疏区绕行的块状边界，减少高频往返终端的乒乓注册；二是调整二次寻呼策略，重试不再简单扩大范围，而是错开时间窗重发，避开拥塞的 PO；三是协调物联网卡管理方，把同园区卡分批错峰配置 DRX/eDRX 参数，打散 PO 聚集。**D+14，寻呼成功率回到 99.1%。** 这次复盘最大的教训写进了例会纪要：寻呼成功率从来不是无线一个专业的指标——**它是无线规划、核心网策略和终端（尤其物联网卡）配置的三方合谋**，哪一方单独看都“没毛病”，合在一起就是把指标拖下水的完整链条。 ## 三、寻呼失败的六种身世 复盘多了会发现，寻呼失败的根因翻来覆去就是六类。排查的价值不在于背下清单，而在于按顺序排除。 | 身世 | 典型现象 | 常见诱因 | 主要责任面 | | --- | --- | --- | --- | | 1. 跟踪区规划失配 | 失败集中在边界带，伴随位置更新量暴涨 | TAC 边界切在人流干道上，终端乒乓注册，库里地址“过时” | 无线规划 | | 2. 寻呼时机冲突 | 失败集中在少数小区，物联网卡密集区尤甚 | 大量终端派生值相近挤在同一 PO，控制信道资源不足 | 规划+终端配置 | | 3. 终端深度休眠 | 失败记录集中在物联网卡，人的投诉反而少 | PSM/eDRX 配置过长，寻呼到达时终端不可达 | 终端/卡管理 | | 4. 空口覆盖空洞 | 失败伴随弱覆盖告警，室内投诉多 | 深层室内、地下室，寻呼信道本身够不着 | 无线建设 | | 5. 核心网上下文异常 | 单点突发、区域性失败，重启后恢复 | 终端上下文丢失、容灾倒换后库数据不齐 | 核心网 | | 6. 寻呼容量拥塞 | 忙时集中失败，闲时自愈 | 寻呼消息量超小区 PDCCH 容量，大话务/异常信令风暴 | 规划+扩容 | 六类里有四类与“终端睡着”有关，这也解释了为什么寻呼问题往往在物联网规模上量之后集中爆发——人的手机待机 DRX 多在 1~2 秒级，而一张配置了长 eDRX 的水表卡，两次“醒来看一眼”之间可以隔上小时级（NB-IoT 的 eDRX 周期上限即在此量级，具体取值以规范与卡配置为准）。给这样的卡发寻呼，网络必须知道并尊重它的休眠节奏，把寻呼压到它下一次醒来的窗口——一旦卡配置与网络侧记录不一致，寻呼就会发往一个“永远没人应”的时刻。 ## 四、排查工具链与决策树 寻呼排查的核心纪律是**分层收敛**：先证明核心网发没发对，再证明空口传没传到，最后才看终端为什么不醒。跳层排查是新手最常见的弯路——在无线参数里折腾两天，最后发现是核心网库数据不对，白熬两个通宵。 先看一次成功寻呼的端到端时序，知道“正常”长什么样，才能识别“不正常”差在哪一环： ```mermaid sequenceDiagram participant UE as 手机端 participant gNB as 基站 participant AMF as 核心网AMF Note over UE: 待机休眠中 AMF->>gNB: 下发寻呼（含TAC列表） gNB->>UE: 在PO时刻以P-RNTI加扰呼叫 Note over UE,gNB: 终端恰在自身窗口内醒来收听到寻呼 UE->>gNB: 发起业务请求应答 gNB->>AMF: 转发业务请求，寻呼闭环 ``` 正常的寻呼闭环在秒级完成。排查时把这段链路每一跳的计数器拉出来对账，差异点就是故障点。工程上沉淀下来的决策树如下： ```mermaid flowchart TD A["寻呼成功率下降"] --> B["核心网侧对账"] A --> C["空口侧对账"] A --> D["终端侧对账"] B --> B1["下发量是否异常"] B --> B2["上下文与库数据是否齐全"] C --> C1["失败是否集中在边界小区"] C --> C2["是否存在PO聚集拥塞"] D --> D1["失败是否集中于物联卡"] D --> D2["休眠参数与网络记录是否一致"] B1 --> E["查信令风暴与重发策略"] C1 --> F["重划TAC边界"] C2 --> G["打散PO与扩容"] D1 --> H["错峰配置eDRX与PSM"] ``` 工具链上，各层的抓手分别是： - **核心网层**：网管的寻呼下发/响应计数器按 TAC、按网元下钻；N2/S1-MME 口信令跟踪确认寻呼消息确实到达基站；AMF/MME 侧的重发日志看二次寻呼占比——**二次寻呼占比是比成功率更早的预警指标**，它涨说明一次点名已经叫不醒人。 - **空口层**：路测与网管的小区级寻呼统计，重点看 PO 冲突计数与 PDCCH 资源占用；边界小区的位置更新频次。 - **终端层**：物联网卡管理平台核对 DRX/eDRX/PSM 配置；抽卡做端到端呼测，确认“卡上配置”与“网络侧记录”是否一致——两者不一致是物联网寻呼故障里最常见的暗坑。 规范层的依据要记牢：终端侧行为（何时醒、怎么算 PO）由 TS 36.304 / 38.304 约束；核心网侧的注册与寻呼监督定时器（如 EPS 的 T3413、5G 的 T3513 寻呼响应监督、T3412/T3512 周期注册）由 TS 24.301 / 24.501 定义，商用网络的重发次数与时长是可配置项，具体取值各网不同，排障前先抄本网配置再对照规范语义。 ## 五、优化清单：TAC、二次寻呼与物联网卡治理 把这类故障的治理经验收敛成一份可落地的清单，按投入产出排序： **1. TAC 边界治理（一次性投入，长期收益）。** 边界画在人口密集的干道、商圈、通勤走廊上，等于让几十万终端每天在两个跟踪区之间反复注册，库里的位置永远是“刚过时的”。原则：边界沿低话务带绕行，单 TAC 面积与位置更新容量匹配，扩容新站后同步核查边界——大量现网问题的根子是**扩了站没人重划边界**。 **2. 二次寻呼策略调优（改配置，见效快）。** 重试策略常见两种：扩大寻呼范围，或错时重发。边界失配型故障用“扩大范围”能兜住；PO 拥塞型故障越扩大越拥塞，必须错时。两张药方治相反的病，**先诊断清楚再动配置**，这是这条清单里唯一不能抄作业的一条。 **3. PO 均衡与寻呼容量核查（物联网区域必做）。** 对物联网卡密集小区，核查同批次卡的派生值分布；批量开卡时让卡管平台把参数打散。寻呼量接近小区控制信道容量的，列入扩容清单。 **4. 物联网卡休眠参数治理（跨部门，最容易被忽视）。** 卡的 DRX/eDRX/PSM 配置必须有台账，且与核心网侧可达性记录定期比对。新行业客户批量入网前，把寻呼可达窗口作为验收项——很多“打不通”的投诉，根子在开卡那天就埋下了。 **5. 监控前置（把立案标准数字化）。** 别等用户投诉。把“寻呼成功率周环比跌幅、二次寻呼占比、边界小区位置更新量”三个指标设成自动预警，本文案例从 D0 到立案花了两周，有了前置监控，这类阴跌第一周就该被抓出来。 标准允许多种实现，各厂商网元在寻呼重发、可达性管理上的具体默认值与行为以官方文档为准；但上述五条治理逻辑是跨网络通用的——它们管的是“让点名的人和被点名的人对上表”，这件事在任何一代网络里都成立。 ## 六、写在最后 寻呼是通信网里最古老的机制之一，从寻呼台时代到 5G 非激活态，换了四次空口，“在正确的时间、正确的地点叫醒正确的人”这个任务内核没变过。也正因为它太基础、太安静，它出问题时往往不是戏剧性的全网瘫，而是成功率曲线上两个点的阴跌——等用户开始抱怨“电话打不通”，坑已经挖了两个星期。 对一线工程师，这篇文章想留下三句话：寻呼成功率是三方合谋指标，别在单一专业里钻牛角尖；二次寻呼占比是最好的预警哨兵，盯它比盯成功率更早发现问题；物联网规模上量的今天，终端休眠参数治理已经从“可选项”变成了寻呼运维的必修课。网络越省电，叫醒它越是一门手艺。 ## 参考来源 1. [3GPP TS 38.304：NR 空闲态与非激活态过程](https://www.3gpp.org/ftp/Specs/archive/38_series/38.304/) — 5G 寻呼接收、PF/PO 计算、RRC_INACTIVE 与 RNA 的原始规范 2. [3GPP TS 36.304：E-UTRA 空闲态过程](https://www.3gpp.org/ftp/Specs/archive/36_series/36.304/) — LTE 寻呼帧/寻呼时机公式与 DRX 机制的规范出处 3. [3GPP TS 24.501：5G NAS 协议](https://www.3gpp.org/ftp/Specs/archive/24_series/24.501/) — 周期注册与寻呼响应监督定时器（T3512/T3513）的定义 4. [3GPP TS 24.301：EPS NAS 协议](https://www.3gpp.org/ftp/Specs/archive/24_series/24.301/) — EPS 侧寻呼监督定时器 T3413 与周期 TAU（T3412）的定义 5. [3GPP TS 23.501：5G 系统架构](https://www.3gpp.org/ftp/Specs/archive/23_series/23.501/) — 寻呼策略、跟踪区管理与 RRC_INACTIVE 状态机的架构规范 --- > 本文由「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 等场景全覆盖。