## 概述 「电话打得出去，就是接不进来」——这类被叫失败投诉，是核心网运维最头疼的工单类型：主叫正常、上网正常，唯独被叫时隐时现，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发起寻呼： ```mermaid 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寻呼响应的实现问题、用户自己开了勿扰或呼转——排查一周最后发现是终端设置，这种故事每个老运维都有一箩筐。 给这张「死因地图」配上检查手段，就是下面这张速查表： | 断点环节 | 典型故障特征 | 核查手段 | | --- | --- | --- | | 终端注册态 | TAU失败、注册区过期、隐式去附着 | 核心网注册/TAU成功率KPI、用户级信令回放 | | TAI/TAC规划 | 边界TAU量畸高、TAC冲突、寻呼发错区域 | 按TAC下钻TAU量与寻呼响应率、TAC全网查重 | | 标识与路由 | 5G-S-TMSI解码异常、寻呼送往错误节点 | GUAMI/AMF配置核对、池区唯一性检查 | | 节能特性 | 用户长时间离线、物联网批量失联 | 核查PSM/eDRX/MICO签约与参数、主动呼测试 | | 空口下发 | NGAP正常但空口无寻呼、响应率低 | 基站寻呼计数器、路测抓空口信令 | | 终端侧 | 单用户偶发、重启恢复、双卡相关 | 用户回访、换机复测、终端日志 | ## 四、实战复盘：四小时追回一片被叫失踪 回到开头的案例。以下是我们团队当天的处置过程，网络信息已脱敏。方法本身比结论值钱——它就是第三节那张表的实际用法。 | 时间 | 动作 | 关键发现 | | --- | --- | --- | | 09:30 | 汇总近一周被叫失败工单，按用户位置落图 | 投诉点密集分布在A、B两区交界约8公里带上 | | 10:10 | 提取交界小区的TAU与重选统计 | 边界两个TAC的TAU请求量是全网同类TAC均值的4倍多 | | 10:40 | 信令回放五个典型投诉号码的被叫尝试 | AMF均按注册的TAI List正常下发NGAP Paging，无寻呼下发失败 | | 11:20 | 对比终端实际驻留小区与寻呼目标TA | 多数失败场景下终端已跨过TA边界，注册区信息滞后 | | 12:00 | 现场核查边界小区开通工参 | 发现三处问题：TA边界沿快速路划分；两座新站TAC抄用模板未按规划改；一处TAC与邻市冲突 | | 13:10 | 制定整改：重划边界至沿河低话务带、修正两站TAC、处理冲突TAC | 评估影响后安排当晚割接窗口 | | 21:30 | 割接实施，全网TAC查重通过 | 完成边界11个小区的TAC与邻区关系调整 | | 次日10:00 | 回看KPI与工单 | 边界TAU量回落至正常水位，一周后被叫类投诉基本清零 | 复盘时有三个体会值得单独说。**其一，「AMF正常下发」不等于「寻呼成功」**，这两个统计点之间隔着整个空口，中间任何一个环节都可能静默丢包——KPI必须分段看。其二，**新站开通检查清单里，TAC四核对（与规划表核、与邻区核、与全网查重核、与AMF侧TA配置核）必须设为硬卡点**，模板复制是TAC错误的头号来源。其三，**边界用户的「位置滞后」是结构性问题**，只要边界画在人流走廊上，寻呼脱节就会周期性复发，改参数治标，改边界才治本。 整改后的排查逻辑沉淀成了一张决策图，团队现在遇到被叫工单聚集，基本按这个走： ```mermaid 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，先问口径再看数字。寻呼类指标尤其如此，因为它天然分段，每一段都能被单独定义成「寻呼成功率」： | 口径 | 统计位置 | 分子/分母 | 能暴露的问题 | 掩盖的问题 | | --- | --- | --- | --- | --- | | 寻呼下发成功率 | AMF | gNB确认收到/NGAP Paging下发 | N2链路、gNB不可达 | 空口全部问题 | | 空口寻呼响应率 | gNB/路测 | 寻呼响应/空口寻呼发送 | 覆盖、干扰、容量 | 注册区错位（寻呼发对了地方，但发错了「地址」） | | 端到端MT接通率 | 核心网/IMS | 振铃或应答/被叫尝试 | 全链条 | 无法定位断点；受终端侧因素污染 | 只看第一行的网络，可以做到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](https://www.sharetechnote.com/html/5G/5G_Paging.html) — 5G/NR寻呼机制专题，基于TS 38.331 v19.3.0整理，本文寻呼消息结构、PCCH-Config参数、CN/RAN双路由、PF/PO计算公式的主要依据 2. [The 3G4G Blog (Zahid Ghadialy)](https://blog.3g4g.co.uk/search?q=paging) — 资深通信工程师博客，本文S-TMSI构成与MMEC池区唯一性（引TS 23.003）、LP-WUS/LP-WUR与TR 38.869功耗数据、MICO模式专题的出处 3. [3GPP TS 38.331 (NR RRC规范)](https://www.3gpp.org/ftp/Specs/archive/38_series/38.331/) — PCCH-Config、Paging消息ASN.1的官方定义 4. [3GPP TS 38.304 (空闲与非激活态过程)](https://www.3gpp.org/ftp/Specs/archive/38_series/38.304/) — 寻呼帧/寻呼时机计算公式（第7.1节）的原始出处 5. [3GPP TR 38.869 (LP-WUS/LP-WUR研究)](https://www.3gpp.org/ftp/Specs/archive/38_series/38.869/) — 终端功耗量级、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 等场景全覆盖。