# 寻呼：人海中精准定位一部手机 ## 一、从一个生活类比说起 想象你是一个快递公司的调度员，现在有一份加急件要送给客户老王。你只知道老王住在某个城市，但不知道他此刻到底在哪个街区、哪栋楼、哪个房间。你该怎么办？ 最笨的办法是：派快递员把整座城市的每一栋楼都喊一遍"老王，有你的快递！"。这当然能找到他，但代价是整座城市的人都被吵醒了，快递员也累瘫了。 聪明的做法是：让老王每天定时主动发一条"我现在在城南片区"的位置短信给你。这样你就知道他大概在哪个区域，只需要在这个区域的几栋楼里喊他名字就够了。 这就是移动通信里**寻呼（Paging）**的全部思想精髓。网络要把一个来电、一条微信、一段下行业务送给某部手机时，它并不知道这部手机此刻在哪一个基站下、哪一个小区里——它只掌握一个"粗略"的位置。寻呼，就是网络在那个粗略位置范围内"广播喊人"的过程；而手机主动上报位置的动作，叫做**位置更新（Location Update / Tracking Area Update）**。 这两件事是一对天生的矛盾体，理解它们的拉锯，你就理解了整个移动性管理的"位置侧"逻辑。 ## 二、核心矛盾：两个开销的拔河 要真正读懂寻呼为什么这么设计，必须先抓住它的核心矛盾。手机有两个相反的需求： - **想省电**：手机大部分时间并不在通话，它希望尽量少做上报、少听广播，能睡就睡。 - **想被找到**：当有下行业务到来时，网络又必须能在合理时间内找到它。 围绕这两个需求，产生了两类开销的拉锯： | 开销类型 | 产生原因 | 想要的方向 | |---------|---------|-----------| | **寻呼开销（Paging Load）** | 网络在一个范围内对所有小区广播喊人 | 希望范围越小越好 → 知道手机越精确越好 | | **位置更新开销（Signaling Load）** | 手机每跨过一个边界就主动上报"我搬家了" | 希望上报越少越好 → 范围越大越好 | 注意到了吗？这两个开销是**此消彼长**的。如果你把网络划分得粒度很细（比如每个小区都让手机上报），那么寻呼开销极小（只在 1 个小区喊），但位置更新信令会爆炸——你在地铁里每过 10 秒就跨过几个小区，手机会疯狂上报。反过来，如果你把全国划成一个超大区域，手机几乎不用上报，但只要来一个电话，全国所有小区都要一起广播喊人，空口资源和基站处理能力立刻崩溃。 所以移动通信从来没有"一刀切"的最优解，只有**针对场景的折中**。下面要讲的跟踪区、注册区列表、DRX，全都是围绕这个折中做出的工程选择。 ```mermaid flowchart LR subgraph 拉锯["位置管理的核心拉锯"] direction LR A["粒度越细
（每小区上报）"] -->|寻呼开销↓ 位置更新开销↑| B["粒度越粗
（超大区域）"] end A -.最优不存在.-> C["工程折中点"] B -.最优不存在.-> C C --> D["跟踪区 TA
注册区 TA List
DRX/eDRX"] ``` ## 三、位置管理的粒度：从小区到跟踪区 为了在上述拉锯中找到平衡点，网络设计了一个**分层的位置概念**，从粗到细是： | 层级 | 名称 | 含义 | 网络是否知道手机在哪 | |------|------|------|---------------------| | 最细 | 小区（Cell） | 一个基站覆盖的一片区域 | ❌ 空闲态不知道 | | 中等 | **跟踪区 TA**（Tracking Area） | 一组小区的集合，有唯一编号 TAI | ❌ 只知道在哪个 TA | | 较粗 | **注册区**（Registration Area） | 核心网分配给手机的 TA 列表 | ✅ 知道在这组 TA 内 | | 最粗 | PLMN | 整个运营商网络 | 知道在哪个运营商 | **为什么要发明"跟踪区"这个中间层，而不是直接用小区？** 因为如果按小区粒度管理位置，手机每切换一个小区就要上报一次，信令根本扛不住。跟踪区相当于把若干地理上相邻的小区"打包"成一个行政区，只要手机还在这个行政区内移动，就不需要上报——它把这个粒度问题从"几十米"放大到了"几公里"，上报频率立刻降了几个数量级。 每个跟踪区有一个全局唯一的身份证号，叫 **TAI（Tracking Area Identity）**，它由三部分拼成： $$ TAI = PLMN\ ID \ (\text{MCC}+\text{MNC}) + TAC \ (\text{Tracking Area Code}) $$ 其中 MCC 是国家码，MNC 是运营商码，TAC 是这个跟踪区在运营商内部的编号。手机读到的每一个小区广播里，都会持续发送自己所属的 TAI，手机据此判断"我是不是还待在原来的行政区内"。 **更巧妙的设计是 TA 列表（Registration Area）。** 核心网给手机分配的不是一个 TA，而是**一组 TA 的列表**。只要手机在这组 TA 之间的任何一个里，都不需要做位置更新。这有什么好处？考虑一部手机正好停在两个 TA 的边界上，如果只分配单个 TA，它会在两个 TA 之间反复横跳、反复上报（这叫"乒乓位置更新"）。给了它一个覆盖边界的列表，乒乓问题就消除了。 ```mermaid flowchart TB UE["📱 手机（空闲态）"] subgraph RA["注册区 TA List（核心网分配）"] TA1["TA-1"] TA2["TA-2"] TA3["TA-3"] TA1 --> c11["小区"] TA1 --> c12["小区"] TA2 --> c21["小区"] TA3 --> c31["小区"] end UE -.读取小区广播的 TAI.-> TA2 UE -.判断: TA2 在列表内, 不上报.-> RA subgraph 外部["列表之外"] TA9["TA-9（陌生区）"] end UE -.进入 TA-9, 不在列表内.-> 触发["触发位置更新
Mobility Registration Update"] 触发 -->|核心网发新列表| UE ``` ## 四、位置更新（TAU）：手机主动"打卡" 当手机发现自己进入了**不在注册区列表内**的跟踪区时，它就必须主动发起一次位置更新，告诉核心网"我现在的位置变了，请把我的归属信息更新一下，并给我一张新的行政区地图"。在 4G 里这个过程叫 **TAU（Tracking Area Update）**，在 5G 里规范名称叫 **Mobility Registration Update**，本质完全一样。 位置更新还有几个触发时机：周期性超时（比如网络要求每 54 分钟必须报到一次，确认手机还在线）、从覆盖盲区回到有信号区、能力信息变化等。 位置更新的信令时序如下： ```text sequenceDiagram participant UE as 📱 手机 participant gNB as 基站 gNB participant AMF as 核心网 AMF participant UDM as 用户数据 UDM Note over UE: 检测到新小区 TAI 不在列表内 UE->>gNB: 1. Registration Request
(携带原 TAI/列表、用户临时标识) gNB->>AMF: 2. 转发注册请求 (基于 TAI 选择 AMF) Note over AMF: 3. 决定是否需鉴权/安全模式 AMF->>UE: 4. （可选）Authentication / Security Mode UE->>AMF: 5. 安全模式完成 AMF->>UDM: 6. 查询/订阅用户上下文 UDM-->>AMF: 7. 返回签约数据 AMF->>AMF: 8. 更新 UE 位置
计算新的注册区 AMF->>gNB->>UE: 9. Registration Accept
(下发新 TA List) Note over UE: 10. 保存新列表, 后续在该范围内不再上报 ``` 为什么位置更新要带"用户临时标识"（5G 里叫 **5G-S-TMSI**）而不直接用永久号码 IMSI？因为永久号码一旦在空口明文出现，就有被跟踪、被冒用的风险。用临时的、可周期性更换的标识，是为了**隐私和安全**——这是位置更新流程里经常被忽略、却非常关键的一个"为什么"。 ## 五、寻呼的完整信令流程：网络"喊人" 有了位置更新打底，核心网始终知道每一部空闲手机"大概在哪个 TA 列表范围内"。当有下行业务到来时，寻呼就可以精准地只在这个范围内广播了。一次完整的下行寻呼触发信令如下： ```mermaid sequenceDiagram participant Data as 下行数据/信令 participant UPF as 用户面 UPF participant SMF as 会话管理 SMF participant AMF as 移动管理 AMF participant gNB as 基站 gNB participant UE as 📱 手机(空闲) Data->>UPF: 1. 下行数据到达, 但手机空闲 UPF->>SMF: 2. 下行数据通知 SMF->>AMF: 3. 请求寻呼该 UE Note over AMF: 4. 查 UE 的注册区
= 一组 TA AMF->>gNB: 5. 向注册区内所有 gNB 发 Paging
(UE 标识 + TA 列表 + 寻呼原因 + 优先级) Note over gNB: 6. 在每个相关小区
计算 PF/PO, 安排广播 gNB->>UE: 7. 在寻呼时机广播
(用 P-RNTI 加扰) Note over UE: 8. 醒来解码, 匹配自己的标识 UE->>gNB: 9. 匹配成功 → 发起 Service Request gNB->>AMF: 10. 建立/恢复连接 Note over UE: 11. 进入连接态, 下行数据开始传送 ``` 这里有三个极其精妙的设计点，值得逐一说清"为什么"： **第一，为什么寻呼要在"注册区范围内"广播，而不是只发一个小区？** 因为空闲态下网络并不知道手机在哪个具体小区——手机只有跨出整个注册区时才会主动上报。所以网络能做的最精确动作，就是把整个注册区里的所有基站都喊一遍。这就是为什么注册区大小直接决定了寻呼开销：注册区越大，要喊的基站越多。 **第二，空口上用什么"频道"喊？** 寻呼消息在空口并不是一条专用信道，而是和普通下行业务**复用在同一条物理下行共享信道（PDSCH）**上。那手机怎么知道这一帧里有没有喊到自己？靠一个专门的"寻呼身份证"——**P-RNTI（Paging RNTI）**。基站在物理下行控制信道（PDCCH）上用 P-RNTI 对控制信息加扰，手机如果用 P-RNTI 能解开这个控制信息，就说明这一帧里"有寻呼内容"，然后再去 PDSCH 上读具体的寻呼消息，比对里面有没有自己的 5G-S-TMSI。这是一种"先看门牌、再拆信"的两级设计，非常省电。 **第三，寻呼消息里携带"优先级"。** 这是 5G 的一个增强。不同业务可以被赋予不同寻呼优先级，时间敏感的业务（比如紧急告警、重要语音）会优先排队广播，避免被海量普通物联网寻呼挤兑。这也是工程师做容量规划时要关注的点：寻呼信道虽然是共享的，但它有吞吐上限。 ## 六、DRX 非连续接收：手机如何"睡"着等寻呼 到这里有一个省电的关键问题还没解决：如果手机必须随时听寻呼，它就得一直开着接收机，电池根本撑不了一天。解决办法是 **DRX（Discontinuous Reception，非连续接收）**——手机并不持续监听，而是**周期性地醒来听一会儿**。 DRX 的核心思想用一个生活比喻最清楚：你不是 24 小时盯着门口等快递，而是约定"每 30 分钟去门口看一眼"。快递员也会在你"该出现"的那个时间点来敲门。双方对齐了这个"看门时刻表"，就既不会错过快递，又不用一直站着。 在寻呼场景下，这个"看门时刻表"由两个量精确决定： - **寻呼帧 PF（Paging Frame）**：在哪个无线帧（系统帧号 SFN）醒来。一个无线帧 = 10ms。 - **寻呼时机 PO（Paging Occasion）**：在 PF 内的哪一个时刻去听 PDCCH。 手机会在自己专属的那个 PO 醒来一小段，听完就继续睡；下一个 DRX 周期再醒来。这个周期长度 T 由网络配置，典型值是 32 或 64 个无线帧（即 320ms / 640ms 档位），还有更长的高节能档位。 那么，上千万部手机都按 DRX 周期醒来，怎么避免它们挤在同一时刻醒来、造成寻呼信道的瞬时拥塞？答案是把它们**均匀打散**到周期内的不同 PO 上。打散的依据是每部手机的临时标识，于是有了下面这组公式： $$ N = \min(T,\ n_B), \quad N_s = \max(1,\ nB/T) $$ $$ (SFN \bmod T) = (T \div N) \times (UE\_ID \bmod N) \quad \rightarrow \text{确定 PF} $$ $$ i_s = \left\lfloor UE\_ID / N \right\rfloor \bmod N_s \quad \rightarrow \text{确定 PF 内的第几个 PO} $$ 其中 T 是 DRX 周期，nB 控制一个周期里放多少个寻呼时机（也就是寻呼"密度"），UE_ID 由手机的 5G-S-TMSI 推导。这几行公式看着吓人，本质就一句话：**用手机自己的 ID 做一次取模，把它"摊"到周期的某个固定格子里**。ID 不同的手机，几乎一定会落到不同的格子里，从而实现负载均衡。 | 参数 | 含义 | 工程意义 | |------|------|---------| | T | DRX 周期（帧） | 越大越省电，但寻呼延迟越大 | | nB | 单位周期内的寻呼时机密度 | 网络可调，平衡寻呼容量 | | N | = min(T, nB) | 用于 PF 计算 | | Ns | 每个 PF 内的 PO 数 | 决定一帧内能容纳多少手机 | | UE_ID | 由 5G-S-TMSI 派生 | 把手机打散到不同 PO | 这个"按 ID 取模打散"的设计，是整个寻呼机制里最优雅的一笔。它让成千上万部手机在没有任何协调的情况下，自发地错峰醒来，把寻呼信道的瞬时负载摊平——这正是分布式系统里"用确定性哈希实现负载均衡"的经典思想。 ## 七、eDRX：物联网设备的极致省电 普通手机的 DRX 周期到秒级就够省电了，但物联网设备（水表、烟感、跟踪器）有更极端的需求：它们可能一天只收一次指令，电池要撑十年。于是有了 **eDRX（extended DRX）**——把 DRX 周期大幅延长。 | 模式 | 典型 DRX 周期 | 适用场景 | 寻呼延迟 | |------|--------------|---------|---------| | 普通 DRX | 320ms ~ 640ms | 智能手机 | 毫秒~百毫秒级 | | 高节能 DRX | 数秒 | 低活跃手机 | 秒级 | | **eDRX** | 数分钟 ~ 数十分钟 | NB-IoT / 物联网 | 分钟级，可接受 | eDRX 的代价很直白：手机睡得太沉，寻呼延迟就拉长。所以它只用于"对延迟不敏感、但极在乎功耗"的物联网业务。这是一个典型的不可能三角——**功耗、延迟、可达性**三者只能取其二。工程师在做 NB-IoT 项目规划时，必须先和业务方确认"这个设备多久必须能被找到一次"，再据此选 eDRX 周期，否则会出现"指令发了半天设备才响应"的投诉。 ## 八、RRC_INACTIVE 与 RNA 寻呼：5G 的省电新招 5G 比 4G 多了一个全新的无线状态：**RRC_INACTIVE（去激活态）**。这是介于"完全空闲"和"完全连接"之间的中间态。 为什么要发明这个中间态？因为很多业务（比如网页浏览、即时消息）是"阵发性"的——传一小会儿数据就停了，但很快又会来下一波。如果每次空闲都彻底拆掉所有无线上下文，下次来业务又要从头建立连接，时延和信令开销都大。RRC_INACTIVE 让手机保留一部分上下文，需要时能快速"恢复（resume）"。 但这个状态带来了一个新的寻呼问题：手机在 INACTIVE 态下小范围移动时，网络同样不知道它的精确小区位置，于是需要在它最后登记的一小块区域（**RNA，RAN-based Notification Area**）内做寻呼。RNA 寻呼由无线接入网（RAN）自己完成，不一定要惊动核心网，开销比传统核心网寻呼小得多。这是 5G 在"低时延 + 低信令"上的一个重要权衡设计。 ## 九、实战连接：工程师在哪会用到这些 这些原理听起来抽象，但在现网调试里处处都是它们的影子。挑几个典型场景： **场景一：寻呼成功率低、被叫难打通。** 如果大量用户反映"来电打不通，但过会儿自己就来了"，很可能是寻呼失败。排查时要先看是"空口寻呼就没发出去"（核心网或传输问题），还是"发了但手机没响应"（手机没在正确 PO 醒来、DRX 配置异常、覆盖太差、或者手机真的进入了 eDRX 长睡周期）。这时懂 PO/PF 和 DRX 周期，就能从抓包里判断"手机到底该在哪个帧醒来"，而不是瞎猜。 **场景二：寻呼信道拥塞。** 物联网海量接入后，某个城市的寻呼信道利用率飙高。这时要回到那个核心矛盾——是注册区划太大了（每个寻呼要在太多基站广播），还是 nB 寻呼密度配低了？规划上可以考虑缩小注册区、调整寻呼密度，或对物联网终端用单独的 eDRX 策略错峰。 **场景三：边界乒乓与信令风暴。** 某地铁/高铁沿线信令飙升，往往是 TA 边界划得不合理，导致大量用户反复跨区上报。这是典型的"注册区列表设计"问题，需要重新规划跟踪区边界、用好 TA List 覆盖交通干线。 **常见误解提醒：** 很多人以为"寻呼就是给手机打电话"，其实寻呼只是一个**寻人广播**，它本身不传业务；真正通话是在手机响应、进入连接态之后才建立的。另一个常见误解是以为"网络一直知道我在哪个小区"——空闲态下网络真的不知道，它只知道你在哪个 TA 范围。理解这一条，很多"为什么来电会有几秒延迟"的疑惑就豁然开朗了。 ## 十、收束：寻呼的本质是"用确定性换取效率" 把整条线索串起来看，寻呼机制其实回答了一个深邃的工程哲学问题：**当系统不可能精确掌握每一个体的实时位置时，如何用最小的代价把消息送到？** 移动通信给出的答案精彩而统一：用**分层粒度**（TA / 注册区）压缩位置追踪成本，用**周期性上报**保持位置新鲜度，用**按 ID 哈希打散的 DRX**让海量终端自发错峰、把瞬时负载摊平，用**临时标识**兼顾隐私与安全，再用**中间态（INACTIVE）和扩展睡眠（eDRX）**适配从手机到物联网的全谱功耗需求。 这背后没有魔法，全是权衡。下次当你接到一个突然响起的来电，不妨想一想：在你按下接听之前的某个瞬间，整个城市某片区域的几十个基站，刚刚按照一张由你的手机 ID 决定的时刻表，整齐地、错峰地、对你喊了一声"你在吗"——而你正好在那个毫秒醒来，听见了。这就是寻呼。 ## 常见问题 **Q1：寻呼（Paging）和切换（Handover）有什么区别？** A：两者都涉及"移动性"，但方向相反。寻呼是网络找手机——网络有下行业务要送，但不知道手机在哪个小区，于是在注册区内广播喊人，发生在手机空闲态/去激活态。切换是手机找网络——手机正在通话中移动，为了不掉线，网络把它的连接从一个基站接力到另一个基站，发生在连接态。一个解决"被动找到"，一个解决"主动不掉"。 **Q2：为什么是"跟踪区列表"而不是"单个跟踪区"？** A：为了消除边界乒乓。如果只给手机一个 TA，当它停在两个 TA 边界时，会反复横跳、反复上报位置更新，造成信令风暴。给一组覆盖边界的 TA 列表，手机在该范围内任意移动都不上报，既省信令又提升体验。 **Q3：DRX 周期是不是越长越好（越省电）？** A：不是。DRX 周期越长越省电，但寻呼延迟也越大——因为网络只能等到手机"该醒来的时刻"才能喊到它。手机用秒级 DRX，物联网用分钟甚至几十分钟级的 eDRX，本质是在"功耗 vs 可达延迟"间取舍，必须匹配业务需求。 **Q4：空闲态下网络到底知不知道我在哪个小区？** A：不知道。空闲态下网络只知道你在哪个注册区（一组 TA）范围内。只有当你响应寻呼、进入连接态后，服务基站才把你的小区级位置报告给核心网。这正是来电会有一点延迟的根本原因。 **Q5：PO/PF 那套公式为什么用手机 ID 取模？** A：为了把海量手机的"醒来时刻"均匀打散。用每部手机唯一的 ID 做取模，相当于一次确定性哈希，让 ID 不同的手机自发落到周期内不同的时刻格子里，避免所有人挤在同一瞬间醒来造成寻呼信道瞬时拥塞——这是分布式负载均衡的经典思想。 ## 参考来源 1. [5G Paging Procedure - ShareTechnote](https://www.sharetechnote.com/html/5G/5G_Paging.html) — 通信原理图解权威站点，含 PO/PF 计算与寻呼信道映射的详细说明。 2. [5G Paging Procedure - techlteworld](https://techlteworld.com/5g-paging-procedure/) — 含 Paging Frame / Paging Occasion 与 P-RNTI 工作机制的教程式讲解。 3. [Paging in 5G Network - free5GC](https://free5gc.org/blog/20241204/20241204/) — 开源 5G 核心网项目对寻呼优先级与触发流程的实现视角解读。 4. [5G Paging Procedure and How It Differs from LTE Paging - LinkedIn](https://www.linkedin.com/pulse/5g-paging-procedure-how-differs-from-lte-ravi-shekhar-singh-k1jvc/) — 5G 与 LTE 寻呼差异对比，含 RRC_INACTIVE 与 RNA 寻呼增强说明。 5. [Discontinuous Reception (DRX) in 5G NR - telecomHall](https://www.telecomhall.net/t/discontinuous-reception-drx-in-5g-nr/31334) — DRX/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 等场景全覆盖。