## 概述 被叫打不通，是运营商投诉工单里最常见的“无头案”：用户手机满格、能上网，就是接不到电话。本文从一次典型的寻呼成功率跳水排查切入，拆解 3GPP 跟踪区（TA）与位置更新机制的底层账本，并以 NTT docomo 2012 年“位置注册风暴”系列故障为权威案例锚点（据 NTT docomo 官方公布及总务省行政指导文件），给出 TAC 规划、寻呼参数优化与被叫失联排查的完整实战方法。本文回答三个问题：手机失联到底丢在哪一环、TA 该怎么切才不会翻车、寻呼参数该怎么调才有立竿见影的收益。 ## 目录 - 一、一通打不通的电话，卡在哪一环 - 二、TA 与位置更新：3GPP 给手机记的账 - 三、案例锚点：docomo 的位置注册风暴 - 四、TAC 规划六条实战法则 - 五、寻呼参数优化：把每一毫秒都算清楚 - 六、被叫失联排查五步法 - 七、写在最后：运维的账本思维 - 参考来源 ## 一、一通打不通的电话，卡在哪一环 凌晨 1 点，网管 KPI 看板上一条曲线突然跳水：全市寻呼成功率从 98.6% 掉到 91.2%，被叫未接通投诉随之涌入客服。这种场景，做无线和核心网运维的老兵都遇到过。它麻烦的地方在于：主叫侧一切正常，用户手机信号满格，问题却发生在“网络找手机”这个最不起眼的环节。 一通电话被叫接通，背后是一条完整的信令链：IMS 域选查询被叫状态 → HSS/HLR 确认可达 → MME/AMF 在被叫注册的跟踪区内下发寻呼 → 空口 Paging → UE 响应发起业务请求 → 承载建立、振铃。这条链上任何一环卡住，表现都是同一个——"打不通”。而实践中最常见的故障源，恰恰是平时没人关注的**位置更新（TAU/LAU）与寻呼机制的配合**：手机的位置信息是手机自己“报上来”的，网络只是被动记账。账记错了、记晚了、记漏了，寻呼自然扑空。 用一张图看这条链路，以及每一环对应的故障类型： ```mermaid flowchart TD A["主叫发起呼叫"] --> B["IMS 域选查询被叫"] B --> C{"HSS 签约数据
是否正常"} C -->|数据异常| X["未发起寻呼
查HSS与域选"] C -->|数据正常| D["MME 在TA列表内
下发寻呼"] D --> E["小区空口 Paging"] E --> F{"UE 收到寻呼
且响应？"} F -->|收到并响应| G["Service Request
承载建立振铃"] F -->|无响应| Y["寻呼扑空
查TAU与无线环境"] ``` 看懂这张图，你就明白了运维排查的第一性原理：**先分清“没寻呼”还是“寻呼了没响应”**，两者的排查方向完全相反。而决定“寻呼能不能找到人”的底层机制，就是下一节要讲的 TA 与位置更新。 ## 二、TA 与位置更新：3GPP 给手机记的账 3GPP 在 TS 23.401（E-UTRAN 阶段）和 TS 23.501（5GC 阶段）中设计了一套“以空间换信令”的位置管理机制，核心账本有三个条目。 **第一本账：跟踪区与 TAI 列表。** 网络把地理区域切成一个个跟踪区（Tracking Area），每个 TA 用 TAC 标识，TA 与小区号共同构成 TAI。MME 给每个空闲态 UE 分配一个 **TAI 列表**（最多 16 个 TA），UE 只要在列表内的 TA 里活动，就**不需要**做任何位置更新。寻呼时，MME 在整个列表覆盖的所有小区同时发 Paging。这是一次典型的折中：列表越长，寻呼范围越大、寻呼信令越多，但 TAU 越少；列表越短，TAU 频繁，寻呼却更收敛。 **第二本账：TAU 触发条件。** 空闲态 UE 主要在三种情况下发起 TAU：一是移动进入了一个不在 TAI 列表内的 TA（广播消息里的 TAC 对不上）；二是周期性 TAU（定时器 T3412，规范默认值 54 分钟，可配置延长），相当于手机定期向网络“报到”，防止长期静默后账本失真；三是系统间或能力变化触发的更新（如与 2G/3G 互操作）。连接态下，切换过程本身会由网络侧完成位置刷新，这是很多新同事容易误解的点——空闲态才是 TAU 的主战场。 **第三本账：寻呼的空口账单。** 寻呼不是想发就发，UE 空闲态下按 DRX 周期“睡-醒”循环，只在属于自己的寻呼时刻醒来听 PDCCH。3GPP TS 36.304 定义了精确的调度公式： - 寻呼周期 T ∈ {32, 64, 128, 256} 个无线帧（默认周期在 SIB2 广播，专有周期可按签约配置）； - UE_ID = IMSI mod 4096，决定这个 UE 永远落在固定的寻呼帧（PF）与寻呼时刻（PO）上； - PF 满足 SFN mod T = (T div N) × (UE_ID mod N)，其中 N = min(T, nB)，Ns = max(1, nB/T)； - nB 参数（取值 4T 到 T/32）决定每个寻呼周期内可承载多少个离散的寻呼时刻。 这套机制意味着：**寻呼容量是可计算的资源**。周期 T 越短，UE 醒得越勤、被叫响应越快，但耗电与 PDCCH 负荷越高；nB 越大，可并行的寻呼分组越多，突发寻呼风暴时越从容。而一旦某个 TA 的用户规模或信令模型超出账本容量，就是事故的开始——docomo 用三次全国性故障给全行业上了这一课。 ## 三、案例锚点：docomo 的位置注册风暴 这是本文的权威案例锚点，素材来自 NTT docomo 官方公布的故障说明、总务省的行政指导及其后广泛公开的媒体复盘（时间线汇总可参见日文维基百科"NTT docomo 通信障害"条目）。 **2012 年 1 月 26 日**，docomo Xi 数据业务发生全国性故障，据其公布，晚间高峰时段开始、持续约 4 小时，最大影响约 231 万用户。**2012 年 10 月 17 日**，几乎相同的故障再次发生：上午 8 时 23 分起 Xi 用户无法建立数据连接，持续约 4 个半小时，最大影响约 151 万人。据 docomo 事后说明，根因是**位置注册处理在短时间内集中涌向位置注册装置（HLR/DB 前端），处理能力被击穿**，数据连接的认证环节整体阻塞——手机反复重试注册，进一步加剧拥塞，形成典型的信令风暴正反馈。**2013 年 1 月 18 日**，第三次故障来袭，约 76 万用户受影响约 7 小时，据公开报道与数据恢复作业期间的写入集中有关。 | 日期 | 持续时长 | 最大影响用户 | 诱因（据公开说明） | |---|---|---|---| | 2012-01-26 | 约 4 小时 | 约 231 万 | 位置注册处理集中，装置过载 | | 2012-10-17 | 约 4.5 小时 | 约 151 万 | 同类机制复发，认证阻塞 | | 2013-01-18 | 约 7 小时 | 约 76 万 | 数据恢复作业期间写入集中 | 需要分清哪些是可验证事实、哪些是行业解读：**“三个日期、时长、影响人数、根因指向位置注册装置过载”**是 docomo 官方公布与总务省文件层面的事实；而“重试风暴放大拥塞”的细节属于行业事后普遍认同的机理分析。docomo 公布的再发防止对策包括：位置注册装置处理能力分阶段扩容、注册处理分散化（错峰削峰）、装置负荷监控与阈值体系重建。这套组合拳后来成为全球核心网容量规划的标准动作——每一次大规模集中注册场景（节假日零点、灾害后全网复电、终端厂商 OTA 推送触发批量重注册）都要按“峰值注册速率”而非“平均注册速率”来设计容量。 这三次故障对本文主题的意义在于：**位置更新的信令账本不是软约束，而是硬容量**。当 TAC 规划失当或外部事件把 TAU 流量推过装置极限，“位置更新”就从维护可达性的手段，变成了摧毁可达性的凶器。 ## 四、TAC 规划六条实战法则 结合规范约束与一线经验，TAC/TA 规划的实战法则可以收敛为六条。注意：具体参数取值与设备能力，各厂家实现不同，标准允许多种实现，落地时以现网测算和厂家官方文档为准，以下给的是方法框架与经验量级。 **法则一：边界避开高移动性走廊。** TA 边界绝不能压在高速公路、铁路、河流桥梁、跨江隧道上。通勤人流每天数万次穿越边界，每一次都会触发边界两侧的 TAU 乒乓。正确做法是让边界穿过多山、水域开阔、人口稀疏的低移动区域。 **法则二：话务密度决定 TA 粒度。** 城市核心商务区 TA 切小、郊区农村 TA 放大。道理是双向的：话务密度高的区域，同等面积下寻呼负荷大，TA 切小可以让寻呼更收敛；而郊区用户稀疏，大 TA 几乎不增加寻呼负担，却显著减少 TAU。 **法则三：按峰值注册速率做容量校核。** 借用 docomo 的教训：规划文档里每个 TA 都要有三列数字——附着用户数、忙时 TAU 速率、寻呼容量上限。校核场景必须包括极端场景：跨年零点、大型演出散场、台风过境后复电。尤其要警惕全网性批量事件（如大规模终端升级引发的集中重注册），这类流量的特征是“定时、定向、洪峰式”。 **法则四：TAI 列表长度是调节阀。** 静止用户多的区域用长列表（省 TAU），高速移动场景（高铁沿线）考虑短的专有列表策略，让位置信息更新鲜、寻呼更准。列表策略要和寻呼容量一起做联合仿真或现网拨测，不要拍脑袋。 **法则五：割接灰度与回退预案。** TAC 割接是高危操作——改的是全网手机的“地址簿”。必须分区域灰度：先选一个话务低、结构简单的郊区 TA 试点，观察 24~48 小时 TAU 成功率、寻呼成功率、MME 负荷三组曲线，再逐片推进。回退预案要精确到“改回哪个值、多久生效、生效期间用户感知如何”。 **法则六：边界 TA 的监控单独建组。** 把所有跨 TA 边界小区的 TAU 尝试频次单独拉一张报表，乒乓 TAU（同一 UE 短时间内双向 TAU）一眼可见。这张表是 TAC 规划质量最灵敏的体检指标。 ## 五、寻呼参数优化：把每一毫秒都算清楚 TAC 规划定了“账本的结构”，寻呼参数则决定“账本每天怎么记账”。四组参数最值得花功夫。 **寻呼周期 T 与 nB 的组合。** 对被叫时延敏感的现网（尤其 VoLTE/VoNR 语音），默认 128 帧周期意味着最坏情况下寻呼空口延迟可达 1.28 秒，叠加多级重发，被叫接续时延肉眼可见。语音份额高的区域，评估将默认周期下调至 64 帧的收益——代价是 PDCCH 负荷与终端耗电上升，必须与无线侧联合评估。nB 则决定同一周期内寻呼时刻的分组数，节假日寻呼洪峰前，检查 nB 余量是核心网值班的必查项。 **寻呼重发策略。** MME 侧的重发间隔与次数、以及是否在首次无响应后扩大寻呼范围，直接决定“扑空”的最终判定时间。参数过激会放大信令风暴（docomo 式正反馈），过缓则被叫接续时延劣化。这里的标准允许多种实现，调整前务必在厂家文档中确认当前网的重发树逻辑。 **周期性 TAU 定时器 T3412。** 它是“账本保鲜度”与“网络信令负荷”的总阀门。缩短 T3412，位置信息更准、寻呼成功率上升，但全网 TAU 量线性放大；物联网场景（尤其 NB-IoT）则反其道而行，配合 eDRX 与寻呼时间窗（PTW）把报到间隔拉长到小时级。手机用户与物联网用户要用不同的模板，绝不能一张参数表打天下。 **5G 时代的对应物。** 5GC 里 TA 列表演化为注册区（RA），寻呼由 AMF 执行，并区分 AMF 寻呼与 RAN 寻呼（RRC 非激活态）。机制一脉相承，但有一个新的实战要点：4G/5G 互操作场景下，语音靠 EPS Fallback 或 VoNR 的现网中，被叫寻呼横跨两代网络，寻呼成功率要按“端到端被叫接通率”重新定义口径，否则两代网各自 KPI 都漂亮，用户投诉却降不下来。 | 参数 | 作用 | 调整方向与代价 | |---|---|---| | 寻呼周期 T | UE 醒来听寻呼的节奏 | 调小响应快，代价是耗电与 PDCCH 负荷 | | nB | 寻呼时刻分组密度 | 调大抗洪峰，占用更多寻呼资源 | | T3412 | 周期性报到间隔 | 调小位置准、TAU 涨；手机网与物联网分治 | | 寻呼重发 | 扑空判定与风暴边界 | 过激放大风暴，过缓拖慢接续 | | TAI 列表长度 | TAU 与寻呼范围的折中 | 长列表省 TAU、寻呼面大 | ## 六、被叫失联排查五步法 最后把全文收拢成一套可执行的动作。被叫失联投诉到手，按以下五步走，绝大多数“无头案”能在两小时内收敛： ```mermaid flowchart TD S0["工单：被叫打不通"] --> S1["一步：核域选与签约"] S1 -->|域选正常| S2["二步：调寻呼下发记录"] S2 -->|寻呼已下发| S3["三步：比对寻呼响应"] S3 -->|无响应| S4["四步：查TAU与覆盖"] S4 -->|TAU乒乓或漂移| S5["五步：TAC与参数整改"] S4 -->|覆盖空洞| S6["转无线补盲优化"] S3 -->|有响应未接通| S7["查核心网承载建立"] ``` **第一步，核查域选与签约数据。** 确认呼叫是否真的发起了寻呼——大量“打不通”其实卡在 HSS 签约、补充业务（如号码未注册 VoLTE 后回落失败）或域选策略，根本没走到寻呼环节。这一步只要一条核心网查询记录就能定案。 **第二步，调取寻呼下发记录。** MME/AMF 侧确认 Paging 是否发出、发到了哪些 TAC。如果寻呼范围与用户实际位置对不上（用户人在 A 区，账本里还挂在三天前的 B 区），位置更新链路就是嫌疑主体。 **第三步，比对寻呼响应。** 空口侧确认对应 PF/PO 上寻呼是否下发成功、UE 是否上发了 Service Request。这里用信令 trace 按 IMSI/S-TMSI 串起 S1-MME 全程，比看任何统计指标都直接。 **第四步，查 TAU 行为与无线环境。** 有无边界乒乓 TAU、周期性 TAU 是否超时失联、UE 最后一次 TAU 之后是否进了覆盖空洞。众测类 APP 的弱覆盖热力图在这一步非常好用。 **第五步，归因整改。** TAC 结构问题走规划流程，参数问题走参数单，终端行为问题（长期关机、飞行模式、物联网卡异常 Dormant）则回到业务侧定义口径。 这套方法的价值不在某一步有多高深，而在于**顺序不能乱**：先排除“没寻呼”，再查“寻呼不到”，最后才轮到“寻呼到了没接通”。顺序一乱，团队就会在无线和核心网之间来回甩锅，浪费的是最贵的资源——时间。 ## 七、写在最后：运维的账本思维 docomo 三次故障已经过去十多年，但其揭示的规律在今天只增不减：5G 时代终端数量翻了一个数量级，RedCap、无源物联网把“手机报到”的模型扩展到了电池和算力都极度受限的设备上；AI 值班的告警系统能压缩告警数量，却压缩不了位置更新与寻呼这对底层矛盾——**可达性与信令负荷，永远是一对需要记账管理的成本**。 老运维和新运维的差别，往往不在于会不会调参数，而在于调一个参数之前，能不能说清它在整个账本里的位置：这个值动了，TAU 会怎么变、寻呼会怎么变、耗电会怎么变、极端场景下容量还剩多少余量。把每一次故障复盘沉淀成账本里的一个校验项，把每一条参数都当成有价格的资源——这才是位置更新风暴留给运维人最值钱的遗产。 ## 参考来源 1. [3GPP TS 36.304（UE 空闲态过程，寻呼 DRX 与 PF/PO 计算公式）](https://www.3gpp.org/ftp/Specs/archive/36_series/36.304/) — 3GPP 官方规范，本文寻呼机制公式的原始出处 2. [3GPP TS 23.401（E-UTRA 与 EPC 阶段 GPRS 增强，TA/TAI List 与 TAU 机制）](https://www.3gpp.org/ftp/Specs/archive/23_series/23.401/) — 跟踪区与位置更新机制的规范定义 3. [NTTドコモの通信障害（日文维基百科条目）](https://ja.wikipedia.org/wiki/NTT%E3%83%89%E3%82%B3%E3%83%A2%E3%81%AE%E9%80%9A%E4%BF%A1%E9%9A%9C%E5%AE%B3) — 对 docomo 2012–2013 年系列位置注册故障时间线的公开整理，原始数据出自 docomo 官方故障说明与总务省行政指导文件 4. [ShareTechnote: LTE Paging](https://www.sharetechnote.com/html/Handbook_LTE_Paging.html) — 寻呼机制工程视角的参数推导与示例计算，适合作为规范之外的工程师手册 5. [NTT docomo 官网 障害情報](https://www.nttdocomo.co.jp/info/error/) — docomo 历次故障的官方说明与再发防止对策公告入口 --- > 本文由「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 等场景全覆盖。