概述

「电话打得出去，就是接不进来」——这类被叫失败投诉，是核心网运维最头疼的工单类型：主叫正常、上网正常，唯独被叫时隐时现，KPI上看不出全网络异常。本文以一起5G SA网络被叫投诉聚集事件的排查为主线，拆解寻呼这条从AMF到空口的完整链条：它如何工作、会在哪一环断掉、用什么工具把断点找出来。技术细节锚定ShareTechnote的5G Paging专题、3G4G博客与3GPP TS 38.331/38.304规范，实战部分来自笔者团队的脱敏复盘。

目录

• 一、一通打了六次的电话：工单里的被叫失踪
• 二、寻呼是一条接力赛：先把链条画清楚
• 三、链条会在哪里断：六类典型死因
• 四、实战复盘：四小时追回一片被叫失踪
• 五、物联网设备的假死：PSM、eDRX与失联工单
• 六、KPI口径之争：寻呼成功率怎么算才不骗人
• 七、运维工具箱与开通检查清单
• 八、结语：被叫体验是网络的一面镜子

一、一通打了六次的电话：工单里的被叫失踪

先讲一个真实场景。2025年底，某地市5G SA网络商用放量后，客服侧涌来一批奇怪的投诉：用户主叫正常、数据业务正常，但被叫经常失败。有位做小生意的用户描述得特别具体——「快递员给我打了六次，六次都是您拨打的用户暂时无法接通，可我手机明明就在桌上，信号满格」。他打出去没事，别人打进来，十次里有两三次直接进不了振铃。

这类工单的特点是「三无」：无告警、无割接、无区域性中断。网管上看一切正常，核心网CPU平稳，基站退服率是零，KPI大盘绿得发亮。但用户感知是真实的，而且被叫失败比主叫失败恶劣得多——主叫失败用户会重拨，被叫失败意味着他根本不知道有人找过他。对外卖、网约车、医生、跑腿这些靠电话接单的人群，一次被叫失败就是一单生意。

按老规矩，先把投诉分类。回访了三十多个投诉用户，发现几个共同点：都集中在两个行政区的交界地带；都是5G终端驻留5G SA网络；都办理了VoNR或VoLTE语音；用户 重启手机或开关飞行模式后，被叫又能恢复一段时间。最后这个细节最关键——它说明终端和网络之间的「注册状态」出了岔子，而不是单纯的无线覆盖问题。覆盖差的话，主叫也会失败。

于是这起故障被定性为：寻呼可达性问题。要理解它，得先把寻呼这条链一节一节拆开看。

二、寻呼是一条接力赛：先把链条画清楚

很多人对寻呼的理解停留在「网络广播找人」，但作为运维，你需要的是精确到消息和参数的版本。下面这个流程是最典型的被叫语音场景——被叫终端处于CM-IDLE状态，主叫侧网络经由IMS把呼叫路由到被叫所在的AMF，AMF发起寻呼：

sequenceDiagram
    participant C as 主叫侧网络与IMS
    participant A as AMF
    participant G as gNodeB
    participant U as 被叫终端
    Note over U: CM-IDLE 只在寻呼机会短暂醒来
    C->>A: 被叫业务到达 请求寻呼
    A->>G: NGAP Paging 发往TAI List内全部gNB
    G->>U: PDCCH用P-RNTI加扰 RRC Paging
    U->>G: 寻呼响应 RRC Setup Request
    G->>A: N2初始UE消息 携带业务请求
    A->>U: 接受业务 建立用户面

这条链上有几个运维必须吃透的细节，我结合ShareTechnote的5G Paging专题（基于3GPP TS 38.331 v19.3.0整理）逐条说明。

第一，5G的寻呼消息「变瘦」了。 在LTE时代，寻呼消息是个多用途容器，唤醒终端、系统消息修改通知、地震海啸预警（ETWS）都塞在里面。到了NR，寻呼回归本职——只负责触发RRC Setup或RRC连接恢复；系统消息变更和公共预警改用P-RNTI加扰的DCI短消息来通知，终端醒来先看一眼DCI上的「小旗子」，有必要才进一步解码。这意味着你在抓包分析时，不要再去寻呼消息里找ETWS指示了——那是4G的记忆。

第二条接力路线容易混淆。 NR里寻呼有两条路：CN发起的寻呼由AMF触发，寻呼记录里携带的是ng-5G-S-TMSI，收到它的RRC_IDLE终端走完整RRC Setup；RAN发起的寻呼由gNB自己触发（针对RRC_INACTIVE终端），携带的是fullI-RNTI，终端走快速的RRC Resume。两条路消息格式一模一样，区别只在里面的身份字段。还有个容易被忽略的行为：处于RRC_INACTIVE的终端如果收到的是CN发起的寻呼，标准规定它会先转到RRC_IDLE并通知NAS，再走建立流程——排查时别被这种「绕路」吓到。另外5G还允许通过非3GPP接入寻呼终端：用户在Wi-Fi下经N3IWF注册着，网络照样能「敲另一扇门」找到他。

第三，一条寻呼消息是个「名单」。 网络不会给每个终端单独发一条无线消息——空口资源扛不住。寻呼消息里装的是PagingRecordList，一次最多携带约32个终端记录（maxNrofPageRec典型值32），终端醒来解码整个列表，找到自己的临时标识才响应，找不到立即接着睡。这也解释了为什么寻呼负荷要按「条」和「记录数」两个维度监控。

第四，也是最核心的：终端什么时候醒来，是一套纯数学的约定。 终端不可能一直监听，网络在SIB1里通过PCCH-Config广播一套时序参数：defaultPagingCycle定义唤醒周期（rf32、rf64、rf128、rf256四个档位，对应约320毫秒、640毫秒、1.28秒、2.56秒），帧偏移把不同终端摊到不同无线帧上，ns定义一个寻呼帧里有几个寻呼时机（4、2或1），再往下还有PDCCH监测时机的精确定位。终端用5G-S-TMSI算出自己的「就诊时间」：按TS 38.304第7.1节的公式，未启用eDRX时UE_ID取5G-S-TMSI模1024，寻呼帧满足 (SFN + PF_offset) mod T = (T div N) × (UE_ID mod N)，时机索引 i_s = floor(UE_ID / N) mod Ns。全小区广播参数相同，唯一区分终端的就是这个UE_ID——不需要任何专用信令，寻呼机制因此才能扩展到整 cells 级规模。

这套设计的本质是功耗与可达性的交易。3GPP TR 38.869里给过一组量级：5G终端在RRC空闲/非激活态功耗是数十毫瓦，连接态是数百毫瓦。寻呼周期越长终端越省电，但被叫振铃时延越大；周期越短响应越快，终端耗电越狠。记住这个交易，后面排查时会反复用到。

三、链条会在哪里断：六类典型死因

把第二节那条接力链竖起来看，每一棒都可能掉棒。按出现频率排个序：

死因一：网络记录的位置和终端实际位置脱节（最常见）。 AMF寻呼的依据是终端最近一次注册成功时上报的TAI List——它只会把寻呼发往这个注册区内的基站。如果终端跨过了TA边界但TAU没成功（信令丢失、重选乒乓期间定时器超时、边界小区配置异常），网络拿着旧地址去找人，自然扑空。用户随后的任何主叫行为会刷新注册，「过一会儿又好了」就是这个原因——也完美解释了开头那位用户开关飞行模式就恢复的现象。

死因二：TA/TAC规划本身有问题。 TA边界如果沿着高话务走廊（快速路、通勤铁路）划分，边界小区的用户会在两个TA之间反复重选，TAU信令风暴和位置脱节同时发生。行规是边界画在低话务区——河流、山脊、农田。另外TAC冲突是经典坑：两个不相邻的区域用了同一个TAC，寻呼范围解析就乱了。

死因三：临时标识与路由配置错位。 4G时代的老教训值得复习：3G4G博客引用的TS 23.003第2.8节明确写着，S-TMSI由MMEC加M-TMSI构成，MMEC必须在整个MME池区内保持唯一，池区重叠时更要在重叠区唯一。终端在空闲态就靠这个短标识被找到——标识编码错了、池扩容时GUAMI改了没同步，寻呼就会发去错误的节点或根本解不出来。5G的5G-S-TMSI与GUAMI是同一逻辑的延续。

死因四：终端节能特性把「失联」当成了设计目标。 PSM、eDRX、MICO模式（3G4G博客有专文分析MICO）都会让终端长时间不可达——严格说这不是故障，是终端按约定在睡觉。但毫不知情的用户照样会投诉「手机关机了吗」，物联网设备更是成片「假死」。第五节展开。

死因五：空口环节丢寻呼。 AMF的NGAP Paging正常下发了，但基站侧因为覆盖空洞、干扰、寻呼资源拥塞（一条消息32个记录的容量在寻呼风暴时会打满）、寻呼时机上的PDCCH资源被挤占，终端根本没机会读到那条名单。这要靠基站侧计数器和路测区分。

死因六：终端侧因素。 双卡终端的射频仲裁（一张卡打电话时另一张卡离网）、终端芯片对VoNR寻呼响应的实现问题、用户自己开了勿扰或呼转——排查一周最后发现是终端设置，这种故事每个老运维都有一箩筐。

给这张「死因地图」配上检查手段，就是下面这张速查表：

四、实战复盘：四小时追回一片被叫失踪

回到开头的案例。以下是我们团队当天的处置过程，网络信息已脱敏。方法本身比结论值钱——它就是第三节那张表的实际用法。

复盘时有三个体会值得单独说。其一，「AMF正常下发」不等于「寻呼成功」，这两个统计点之间隔着整个空口，中间任何一个环节都可能静默丢包——KPI必须分段看。其二，新站开通检查清单里，TAC四核对（与规划表核、与邻区核、与全网查重核、与AMF侧TA配置核）必须设为硬卡点，模板复制是TAC错误的头号来源。其三，边界用户的「位置滞后」是结构性问题，只要边界画在人流走廊上，寻呼脱节就会周期性复发，改参数治标，改边界才治本。

整改后的排查逻辑沉淀成了一张决策图，团队现在遇到被叫工单聚集，基本按这个走：

flowchart TD
    A["被叫失败工单聚集"] --> B{"终端注册态是否正常"}
    B -->|否| C["查注册与TAU告警"]
    B -->|是| D{"AMF是否发出NGAP Paging"}
    D -->|否| E["查5G-S-TMSI与GUAMI配置"]
    D -->|是| F{"gNB空口是否发出寻呼"}
    F -->|否| G["核对TAC归属与TAI List"]
    F -->|是| H["查覆盖干扰与终端行为"]
    C --> Z["闭环整改与KPI回看"]
    E --> Z
    G --> Z
    H --> Z

五、物联网设备的假死：PSM、eDRX与失联工单

被叫失踪不只在人身上发生。智能水表、气表、 trackers 这类NB-IoT/RedCap设备的「批量失联」工单，是核心网投诉台另一大来源——而其中大部分根本不是网络故障。

原理在第二节那笔「功耗与可达性的交易」里就埋好了。为了给物联网终端做到年数量级的电池寿命（3GPP对部分场景的立项目标是10年），标准给了终端三件「合法失踪」的工具：PSM让终端在完成业务后直接进入深度休眠，下行完全不可达，直到它自己醒来做周期性TAU或有上行需求；eDRX把寻呼监听周期拉长到远超普通终端的2.56秒上限，代价是被叫时延按分钟甚至小时计；MICO模式则是5G里的「只发不收」极端形态，终端只在主动发起连接时可达。3GPP TR 38.869研究low-power唤醒信号与唤醒接收机（LP-WUS/LP-WUR）的动机正在于此——让终端平时连寻呼都不用醒，主收发机彻底关断，靠一个微瓦级的唤醒接收机待命，兼顾长电池和低时延（Rel-18立项研究，相关成果进入后续版本）。

运维层面的关键认知是：对这类设备，「寻呼不可达」往往是配置出来的结果，不是故障。接到批量失联工单，先查三件事：签约数据里PSM/eDRX是否激活、核心网与无线侧的eDRX周期参数是否与终端侧一致、业务模型是否真的需要被叫能力。电表上报读数是纯上行业务，失联几小时毫无问题；但同样是这块表，如果还承担远程阀控（下行指令），eDRX周期就得和业务时延要求对表——按TR 38.869引用的场景描述，消防联动这类要求1到2秒内响应的业务，长eDRX周期根本不适用，这就是为什么标准要另起炉灶研究唤醒接收机。反过来，给不需要低时延的水表配短周期，就是拿整网电池寿命换不存在的体验。

还有一类「假死」藏在参数不一致里：终端侧芯片实现的eDRX与网络广播的配置不匹配，终端在自己以为的寻呼机会醒来，网络却在另一时刻发寻呼——两边永远错过。这类问题靠空口路测抓终端唤醒时刻与网络下发时刻的偏差来定位。标准允许的配置组合很多，各网络的具体参数行为以自身规范和厂家官方文档为准，这里只给方法论。

六、KPI口径之争：寻呼成功率怎么算才不骗人

写了这么多年复盘，我最想劝新人的一个习惯是：报上来的KPI，先问口径再看数字。寻呼类指标尤其如此，因为它天然分段，每一段都能被单独定义成「寻呼成功率」：

只看第一行的网络，可以做到KPI常年99.9%而用户骂声一片——因为寻呼在空口全丢了它也感知不到。只看第三行的网络，数据真实但无法行动。正确姿势是三层都看，而且按TAC、按时段、按终端型号下钻：寻呼失败有时间聚集性（寻呼容量在话务高峰打满）、空间聚集性（某个TA的覆盖或规划问题）、终端聚集性（芯片实现差异）三种模式，下钻维度选对，根因自己浮出来。

另一个口径陷阱是重发策略。标准允许网络自行配置寻呼重发次数与间隔，寻呼总次数除以用户数得出的「负荷」和「成功率」都受策略影响——对比两个网络的寻呼指标前，先确认双方策略是否可比。各家网络的具体策略实现，以官方文档为准，不要拿A网的默认值套B网的现象。

七、运维工具箱与开通检查清单

最后把这套打法工具化。排查被叫问题，笔者日常依赖四类工具：信令回放（按号码拉取全流程信令，从IMS侧INVITE到NGAP Paging到空口响应，逐跳比对时间戳）、KPI下钻（寻呼与TAU指标按TAC/小区/时段三维切片）、工参核查（TAC、TAI List、GUAMI与全网查重脚本）、空口路测（终端侧抓RRC信令，验证唤醒时刻与寻呼接收）。工具不分贵贱，能把「三无」工单变成有据可依的定位链条就是好工具。

把前文经验压成两张清单。新站开通必查：TAC与规划表一致；与邻区TAC关系正确；全网TAC查重通过；AMF侧TA配置含该TAC；NG Setup中声明的TA列表与小区广播一致。被叫投诉必查：用户注册态与最近TAU时间；5G-S-TMSI/GUAMI归属核对；注册TAI List与实际驻留位置比对；PSM/eDRX/MICO签约状态；终端双卡与设置回访。两张清单贴在工位上，能挡掉八成的低级故障。

八、结语：被叫体验是网络的一面镜子

这次复盘写完，回头再看开头那个「打了六次都没人接」的用户，感触是：移动网络把最复杂的机制恰恰藏在了最日常的场景里。寻呼是整套系统中功耗、覆盖、移动性、标识、容量五个维度妥协的交汇点——覆盖划定了终端在哪里，TA规划决定了网络去哪里找，寻呼周期决定终端何时听，临时标识决定找的是谁，容量决定同一时刻能找几个人。任何一个维度的配置失当，最终都以「被叫失败」这种用户最容易感知的方式冒头。

所以老运维有个共识：看一个网络管得好不好，别看下行速率排行榜，去看被叫接通率和它的分段口径。速率差一点，用户抱怨但能用；被叫丢了，用户对网络的信任就断了——他不知道下一次重要的电话会不会也消失在某个没画好的TA边界上。把这根链条盯紧，是核心网工程师对用户最基本的交代。

参考来源

1. 5G | ShareTechnote: Paging — 5G/NR寻呼机制专题，基于TS 38.331 v19.3.0整理，本文寻呼消息结构、PCCH-Config参数、CN/RAN双路由、PF/PO计算公式的主要依据
2. The 3G4G Blog (Zahid Ghadialy) — 资深通信工程师博客，本文S-TMSI构成与MMEC池区唯一性（引TS 23.003）、LP-WUS/LP-WUR与TR 38.869功耗数据、MICO模式专题的出处
3. 3GPP TS 38.331 (NR RRC规范) — PCCH-Config、Paging消息ASN.1的官方定义
4. 3GPP TS 38.304 (空闲与非激活态过程) — 寻呼帧/寻呼时机计算公式（第7.1节）的原始出处
5. 3GPP TR 38.869 (LP-WUS/LP-WUR研究) — 终端功耗量级、eDRX时延局限与唤醒接收机研究动机

本文由「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 等场景全覆盖。