# 寻呼无响应：被叫不通排查实战 **概述**：用户手机信号满格，别人打过来却提示“无法接通”——这是核心网运维最经典、也最容易被误判的工单类型。本文以一桩典型的区域被叫不通故障复盘为主线，沿着“被叫业务如何触发寻呼、AMF 如何选目标 TA、gNB 如何在空口喊人、UE 何时醒来应答”这条完整链路，拆解 5G 寻呼的机制细节与 3GPP 参数体系，并给出基于 Wireshark NGAP 解码的排查工具链与参数优化清单。案例为一线运维经验脱敏整理，机制与参数均锚定 3GPP TS 38.304、ShareTechnote 工程笔记与 Wireshark 官方协议字段文档三处权威来源。 ## 目录 - 一、满格信号为何打不通：问题比想象中普遍 - 二、一通被叫电话的完整旅程：寻呼链路全景 - 三、两条寻呼路线：CN 寻呼与 RAN 寻呼 - 四、UE 何时醒来：PF/PO 公式与四个关键参数 - 五、实战复盘：重复 TAC 引发的区域被叫不通 - 六、排查工具链：用 Wireshark 看懂 NGAP 寻呼 - 七、参数优化清单与经验教训 ## 一、满格信号为何打不通：问题比想象中普遍 在核心网值班室，有一类工单永远排在最让人头疼的前三名：**被叫不通**。用户描述高度一致——手机信号满格、能上网、能往外打，可别人呼入时要么直接“您拨打的电话暂时无法接通”，要么响了很久才振铃。投诉单转到核心网，第一反应往往是“查一下这个号码”，结果用户上下文完好、注册状态正常、鉴权四元组干干净净，一切看起来都对。 问题出在哪？出在**寻呼（Paging）**这条链路上。手机省电的基本盘是“平时睡觉、有事才醒”，网络找人是通过寻呼完成的。这条链路横跨 IMS、AMF、gNB 和空口四个域，任何一环掉链子，表象都是同一个：被叫不通。主叫正常、数据业务正常，恰恰说明用户面是好的，问题被精确压缩在“网络找人”这个窄环节上——这也让被叫不通成为最考验运维人员信令功底的故障类型。 按 ShareTechnote 在其 5G Paging 专页（sharetechnote.com/html/5G/5G_Paging.html）里的说法，寻呼本质上是一部手机的" Wake-Up Call"（唤醒电话）服务：手机揣在口袋里时深度睡眠以省电，有人来电时网络需要“拍拍它的肩膀”把它叫醒。叫不醒，被叫就不通。理解这句话，就理解了本文要排查的一切。 ## 二、一通被叫电话的完整旅程：寻呼链路全景 先把链路画出来。一通 VoNR 被叫电话从主叫侧进入被叫归属网络后，会经历如下过程： ```mermaid sequenceDiagram participant I as 主叫侧网络/IMS participant A as 被叫AMF participant G as gNB participant U as 被叫UE I->>A: 被叫请求触发核心网寻呼 A->>G: NGAP Paging 消息（5G-S-TMSI 与 TAI 列表） G->>U: 空口寻呼（PDCCH 用 P-RNTI 加扰调度） U->>G: RRC Setup Request 发起接入 G->>U: RRC Setup 下发资源 U->>A: Service Request 响应寻呼 A->>I: 通知可达并继续会话建立 I->>U: 振铃接通 ``` 整条链路里有三个容易出问题的接缝，对应三类典型故障： **第一接缝：IMS 到 AMF 的触发**。被叫请求要在 AMF 侧找到这个 UE 的注册上下文，取到它最后一次注册上报的 TAI（跟踪区标识）。如果上下文丢失、TAI 失真，寻呼从源头就投错了地方。 **第二接缝：AMF 到 gNB 的路由**。AMF 按 UE 的 TAI 列表（TAI List For Paging，NGAP 中的真实信元）决定把 NGAP Paging 消息发给哪些 gNB。这一步是区域性问题的高发区——TA 是寻呼的“投递范围”，TA 规划错了，等于快递按错误地址分拣。 **第三接缝：gNB 空口到 UE**。gNB 在对应寻呼时机用 P-RNTI 加扰的 DCI 调度寻呼消息，UE 必须在自己计算出的唤醒时刻恰好听到这一嗓子。gNB 侧参数与 UE 侧计算假设不一致、UE 恰好处在弱覆盖的电梯地库、寻呼重试次数配得太少，都会让“喊了但没人应”。 ## 三、两条寻呼路线：CN 寻呼与 RAN 寻呼 5G 里寻呼有两条路线，消息在空口长得一模一样，但发起者和身份标识不同，这是排查时第一个要分清的事。ShareTechnote 用一张对比图讲得很清楚，这里转述其要点： **CN 寻呼（核心网发起）**：由 AMF 触发，寻呼记录里携带的是 **ng-5G-S-TMSI**（5G 全球唯一临时标识）。被叫语音、下行的短消息、会话到达通知都走这条线。目标 UE 可能处于 RRC_IDLE；如果 UE 处于 RRC_INACTIVE 状态却收到 CN 寻呼，按 38.331 的规定它会先回到 RRC_IDLE 再通知 NAS——相当于“ resume 失败、从头来过”。 **RAN 寻呼（无线侧发起）**：由 gNB 自己触发，不经过 AMF，寻呼记录里携带的是 **fullI-RNTI**。它服务于 RRC_INACTIVE 状态的快速恢复——网络还保存着 UE 的部分上下文，寻呼命中后 UE 走 RRC Connection Resumption（连接恢复）快速路径，不必从头建立 RRC 连接。这是 5G 相对 4G 的重要优化：4G 醒来要“重新开机”，5G 只需“从睡眠中续上”。 还有一个 5G 特有的细节：寻呼信元里带 **accessType**，区分 3GPP 接入（蜂窝）与非 3GPP 接入（如通过 N3IWF 接入的 Wi-Fi）。也就是说 5G 核心网把 Wi-Fi 也当成一扇门，寻呼可以“敲另一扇门”。 另外值得一提的演进信息：R17 在寻呼记录里加了 pagingCause=voice（语音寻呼原因指示），R18 引入了 mt-SDT（小数据可直接在非激活态传输）与组寻呼增强——这些都能在 38.331 v19.3.0 的 ASN.1 定义里看到，ShareTechnote 页面原文引用了完整结构。一条寻呼消息里的 PagingRecordList 最多可携带 32 个寻呼记录（maxNrofPageRec），网络把多个唤醒请求打包广播，节省空口资源。 ## 四、UE 何时醒来：PF/PO 公式与四个关键参数 寻呼体系的核心是一套 UE 与网络**不需要任何单独信令就能对齐的时刻表**。每个小区在 SIB1 里广播 PCCH-Config，UE 读到后结合自己的身份算出唯一属于自己的“醒来时刻”。按 3GPP TS 38.304《NR; User Equipment (UE) procedures in Idle mode and in RRC Inactive state》（3gpp.org/dynareport/38304.htm，RAN2 负责，Rel-15 立项，Rel-18 已演进到 18.4.0 版）第 7.1 节的定义： - 寻呼帧 PF：满足 **(SFN + PF_offset) mod T = (T div N) × (UE_ID mod N)** 的系统帧号 - 帧内寻呼时机索引：**i_s = floor(UE_ID / N) mod Ns** - 其中 UE_ID = 5G-S-TMSI mod 1024（未启用 eDRX 时），T/N/Ns/PF_offset 全部来自 SIB1 广播 这套设计的精妙之处在于：全网所有参数都是广播的，唯一因人而异的就是 UE_ID，一个取模运算就天然把成千上万用户摊开到不同帧、不同时机，避免全城手机同一毫秒醒来冲垮基站。ShareTechnote 用“邮局信箱”类比：T 是“多久去一趟邮局”，PF 是“哪一天去”，PO 是“当天几点去”，四级参数层层收窄，最终唯一点名一个唤醒时机。 四个关键参数的结构如下表： | 参数 | 作用 | 取值 | 影响 | | --- | --- | --- | --- | | defaultPagingCycle（T） | 寻呼周期，多久醒一次 | rf32/rf64/rf128/rf256（无线帧） | rf32 约 320ms 醒一次，rf256 约 2.56s；周期越短被叫响应越快、UE 越耗电 | | nAndPagingFrameOffset | 周期内寻呼帧的偏置与占比 | oneT/halfT/quarterT/oneEighthT/oneSixteenthT | 把用户分散到周期内不同帧，均摊负载 | | ns | 每个寻呼帧内的寻呼时机数 | four/two/one | 时机越多调度越灵活，UE 监听成本略增 | | firstPDCCH-MonitoringOccasionOfPO | PO 内 PDCCH 监听的精确起点 | 随子载波间隔分八档定义 | 最细粒度，确定到底盯哪个搜索空间的哪些符号 | 还有一个容易被忽略的细节：一个 PO 并非单一瞬间，而是 **S×X 个 PDCCH 监听时机**，其中 S 是小区实际发送的 SSB 数量、X 是每 SSB 的监听时机数（未配置时为 1）。这意味着如果 gNB 的 SSB 发送配置在优化中变更（比如波束数调整），而寻呼调度侧的假设没有同步，UE 依然会准时醒来，却在自己监听的位置上什么都看不到——典型的“参数单边变更”事故模式。 ## 五、实战复盘：重复 TAC 引发的区域被叫不通 下面这个案例由一线运维经验脱敏整理，涉及运营商、地市与网元均做模糊化处理，但故障机理、时间线与处置手段完全遵循真实工程逻辑。 ### 故障背景 某省南部有三个相邻地市，5G 用户陆续投诉被叫不通，主叫与上网正常。投诉集中在省界沿线两个区县，日被叫接通率较全省均值低了约 6 个百分点（网管 KPI 口径：寻呼成功率 = 寻呼响应次数/寻呼下发次数）。值得注意的是，故障并非全网性，用户换个位置往往又能接通——典型的“区域性、边界性”特征。 ### 时间线与处置过程 | 时间 | 事件 | | --- | --- | | D0 | 投诉工单聚集成簇，值班按单点故障处理，复测正常关单 | | D2 | 投诉继续聚集，网管发现两区县 VoNR 被叫接通率持续劣化，立案排查 | | D3 | 核心网侧确认 AMF 均已正常发出 NGAP Paging，触发链路排除 | | D3 下午 | 信令跟踪发现：部分寻呼消息被下发到与用户话单位置完全无关的基站群，同时目标基站未收到寻呼 | | D4 | 倒查 TAC 规划库：两省在历史规划期各自独立分配，省界附近存在重复 TAC，恰在近期一次边界基站割接后暴露 | | D4 晚 | 制定 TAC 归一方案，涉及约 120 个基站重配 | | D5 凌晨 | 低话务窗口灰度割接，首批 20 站验证通过后全网实施 | | D7 | KPI 回捞：两区县被叫接通率回升至全省均值水平，投诉归零 | ### 根因分析 TAC（跟踪区码）在 NR 中为 24 比特，TAI = PLMN + TAC 是寻呼路由的基本单位，同一 PLMN 内 TAC 理应全局唯一。两省规划团队当年各自建库、各自分配，边界处出现了重复 TAC——只要两侧基站的 TAI 列表互不交叉，问题就会被“体面地”掩盖：每个 AMF 只在自己省内按 TAI 路由，各寻各的。近期割接把边界一带的 TAI 配置统一刷新，重复 TAC 的两个“平行世界”发生了连通：AMF 按 TAI 投递寻呼时，同一 TAI 匹配到了两片毫不相关的基站群。结果就是信令跟踪看到的诡异现象——**寻呼错投到错误区域的 gNB（白白广播），真正目标基站却在投递名单之外**。UE 主叫与上网不受影响，因为它们不依赖寻呼路由；被叫则听天由命，UE 恰好驻留在名单内的基站就能接通，反之则"暂时无法接通"。 这个案例最深刻的教训是：**寻呼路由对配置一致性的要求远高于用户面**。用户面按隧道转发，端到端配置错了大概率直接不通、容易暴露；寻呼的 TA 机制却允许错误长期潜伏，直到某次变更把两个错误连接起来。割接评审时，“边界 TAC 唯一性核查”必须成为固定检查项。 ## 六、排查工具链：用 Wireshark 看懂 NGAP 寻呼 被叫不通的排查，核心是回答三个问题：寻呼发了吗？发给谁了？UE 的时间表对吗？Wireshark 官方的 NGAP 显示过滤器参考（wireshark.org/docs/dfref/n/ngap.html）恰好覆盖了这条链路的全部关键信元，以下过滤器均出自该文档的真实字段： | 排查问题 | Wireshark 过滤器 | 能看到什么 | | --- | --- | --- | | 寻呼下发了吗 | ngap.Paging | 全部 NGAP 寻呼消息 | | 喊的是哪个用户 | ngap.fiveG_TMSI 或 ngap.FiveG_S_TMSI | 寻呼携带的临时标识 | | 投递范围对不对 | ngap.TAIListForPaging | 本次寻呼的 TA 名单——TAC 重复类故障的一锤定音证据 | | 重试策略如何 | ngap.pagingAttemptCount 与 ngap.intendedNumberOfPagingAttempts | 当前第几次尝试、计划尝试几次 | | UE 睡多深 | ngap.PagingDRX 与 ngap.uESpecificDRX | 网络侧采用的寻呼周期 | | 有没有智能寻呼 | ngap.recommendedCellsForPaging、ngap.InfoOnRecommendedCellsAndRANNodesForPaging | 推荐小区/推荐节点辅助寻呼 | | gNB 支持哪些 TA | ngap.SupportedTAList | NG Setup 阶段 gNB 上报的 TA 清单，核对 TAC 归属 | 配合一套标准动作，排查效率会高很多。第一步，对投诉号码做核心网信令跟踪（3GPP Trace，NGAP 的 TraceStart 信元支持指定跟踪接口，含 NG-C 与 Uu），复现一次被叫；第二步，在抓包中按上表过滤，确认寻呼消息的 TAI 名单与用户实际驻留位置是否吻合；第三步，若核心网已正确下发，再下沉到 gNB 侧核查空口调度与小区状态。值得一提的是，NGAP 里还有 ngap.pagingProbabilityInformation（寻呼概率信息）这类辅助信元，可让网络侧感知 TA 内的寻呼压力——排查区域性被叫劣化时，这些“冷门信元”往往是破案线索。 一个中性提醒：寻呼重试的具体执行策略、推荐小区的生成算法，3GPP 允许多种实现，具体行为以各厂家官方文档为准，排查时应以本网网管的实际配置和信令实测为准绳，而不是套用其他网络的“经验默认值”。 ## 七、参数优化清单与经验教训 故障处置之后，该网络做了三项整改，构成一份可复用的寻呼优化清单： | 优化项 | 优化前 | 优化后 | 预期收益 | | --- | --- | --- | --- | | TAC 全网唯一性核查 | 两省独立规划，边界存在重复 | 全网 TAC 清查归一，纳入割接强制检查项 | 根除寻呼错投 | | 寻呼重试策略 | 单次寻呼，弱覆盖用户易漏接 | 依据 NGAP pagingAttemptInformation 配置多次尝试、拉长间隔 | 弱覆盖与瞬时遮挡场景接通率提升 | | T 与 ns 参数 | 边界农村小区沿用长周期小 ns | 话务热点收紧周期、增加寻呼时机，郊区保持长周期省电 | 在功耗与接通率间取得平衡 | 再加一条面向未来的：对 NB-IoT 等深度休眠终端，标准提供了 eDRX 扩展寻呼周期（此时 UE_ID 改用 5G-S-TMSI mod 4096），让电池寿命与寻呼时延的取舍有了更大空间——物联网业务上线前务必把寻呼策略纳入设计评审。 复盘这个案例，给同行四条带血的经验：**其一**，被叫不通先画链路再动手，从 IMS 触发到空口唤醒逐段确认，不要上来就重启网元；**其二**，TAI List For Paging 是区域被叫问题的第一证物，一条过滤器就能让错投现形；**其三**，任何“跨区域、看运气”的故障特征，都要优先怀疑规划数据（TAC/TAI/邻区）的一致性，而不是硬件；**其四**，寻呼是省电与可达性的永恒权衡，参数没有全局最优，只有与本网话务分布匹配的局部最优——这也正是这个岗位的价值所在：把标准的公式，调成自己的网络。 ## 参考来源 1. [5G Paging — ShareTechnote](http://www.sharetechnote.com/html/5G/5G_Paging.html) — 知名通信工程笔记，CN/RAN 寻呼对比、PCCH-Config 参数与 38.304 寻呼公式详解（引用 38.331 v19.3.0 ASN.1） 2. [3GPP TS 38.304 规范页](https://www.3gpp.org/dynareport/38304.htm) — 3GPP 官方规范目录页：NR 空闲态与 RRC 非激活态 UE 流程，寻呼帧/时机计算公式出处（RAN2，Rel-18 最新版 18.4.0） 3. [Wireshark NGAP Display Filter Reference](https://www.wireshark.org/docs/dfref/n/ngap.html) — Wireshark 官方 NGAP 协议字段参考，本文所有 ngap.* 过滤器均出自此文档 --- > 本文由「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 等场景全覆盖。