寻呼：人海中精准定位一部手机

一、从一个生活类比说起

想象你是一个快递公司的调度员，现在有一份加急件要送给客户老王。你只知道老王住在某个城市，但不知道他此刻到底在哪个街区、哪栋楼、哪个房间。你该怎么办？

最笨的办法是：派快递员把整座城市的每一栋楼都喊一遍"老王，有你的快递！"。这当然能找到他，但代价是整座城市的人都被吵醒了，快递员也累瘫了。

聪明的做法是：让老王每天定时主动发一条"我现在在城南片区"的位置短信给你。这样你就知道他大概在哪个区域，只需要在这个区域的几栋楼里喊他名字就够了。

这就是移动通信里寻呼（Paging）的全部思想精髓。网络要把一个来电、一条微信、一段下行业务送给某部手机时，它并不知道这部手机此刻在哪一个基站下、哪一个小区里——它只掌握一个"粗略"的位置。寻呼，就是网络在那个粗略位置范围内"广播喊人"的过程；而手机主动上报位置的动作，叫做位置更新（Location Update / Tracking Area Update）。

这两件事是一对天生的矛盾体，理解它们的拉锯，你就理解了整个移动性管理的"位置侧"逻辑。

二、核心矛盾：两个开销的拔河

要真正读懂寻呼为什么这么设计，必须先抓住它的核心矛盾。手机有两个相反的需求：

• 想省电：手机大部分时间并不在通话，它希望尽量少做上报、少听广播，能睡就睡。
• 想被找到：当有下行业务到来时，网络又必须能在合理时间内找到它。

围绕这两个需求，产生了两类开销的拉锯：

注意到了吗？这两个开销是此消彼长的。如果你把网络划分得粒度很细（比如每个小区都让手机上报），那么寻呼开销极小（只在 1 个小区喊），但位置更新信令会爆炸——你在地铁里每过 10 秒就跨过几个小区，手机会疯狂上报。反过来，如果你把全国划成一个超大区域，手机几乎不用上报，但只要来一个电话，全国所有小区都要一起广播喊人，空口资源和基站处理能力立刻崩溃。

所以移动通信从来没有"一刀切"的最优解，只有针对场景的折中。下面要讲的跟踪区、注册区列表、DRX，全都是围绕这个折中做出的工程选择。

flowchart LR
    subgraph 拉锯["位置管理的核心拉锯"]
        direction LR
        A["粒度越细<br/>（每小区上报）"] -->|寻呼开销↓ 位置更新开销↑| B["粒度越粗<br/>（超大区域）"]
    end
    A -.最优不存在.-> C["工程折中点"]
    B -.最优不存在.-> C
    C --> D["跟踪区 TA<br/>注册区 TA List<br/>DRX/eDRX"]

三、位置管理的粒度：从小区到跟踪区

为了在上述拉锯中找到平衡点，网络设计了一个分层的位置概念，从粗到细是：

为什么要发明"跟踪区"这个中间层，而不是直接用小区？ 因为如果按小区粒度管理位置，手机每切换一个小区就要上报一次，信令根本扛不住。跟踪区相当于把若干地理上相邻的小区"打包"成一个行政区，只要手机还在这个行政区内移动，就不需要上报——它把这个粒度问题从"几十米"放大到了"几公里"，上报频率立刻降了几个数量级。

每个跟踪区有一个全局唯一的身份证号，叫 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 之间反复横跳、反复上报（这叫"乒乓位置更新"）。给了它一个覆盖边界的列表，乒乓问题就消除了。

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, 不在列表内.-> 触发["触发位置更新<br/>Mobility Registration Update"]
    触发 -->|核心网发新列表| UE

四、位置更新（TAU）：手机主动"打卡"

当手机发现自己进入了不在注册区列表内的跟踪区时，它就必须主动发起一次位置更新，告诉核心网"我现在的位置变了，请把我的归属信息更新一下，并给我一张新的行政区地图"。在 4G 里这个过程叫 TAU（Tracking Area Update），在 5G 里规范名称叫 Mobility Registration Update，本质完全一样。

位置更新还有几个触发时机：周期性超时（比如网络要求每 54 分钟必须报到一次，确认手机还在线）、从覆盖盲区回到有信号区、能力信息变化等。

位置更新的信令时序如下：

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<br/>(携带原 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 位置<br/>计算新的注册区
    AMF->>gNB->>UE: 9. Registration Accept<br/>(下发新 TA List)
    Note over UE: 10. 保存新列表, 后续在该范围内不再上报

为什么位置更新要带"用户临时标识"（5G 里叫 5G-S-TMSI）而不直接用永久号码 IMSI？因为永久号码一旦在空口明文出现，就有被跟踪、被冒用的风险。用临时的、可周期性更换的标识，是为了隐私和安全——这是位置更新流程里经常被忽略、却非常关键的一个"为什么"。

五、寻呼的完整信令流程：网络"喊人"

有了位置更新打底，核心网始终知道每一部空闲手机"大概在哪个 TA 列表范围内"。当有下行业务到来时，寻呼就可以精准地只在这个范围内广播了。一次完整的下行寻呼触发信令如下：

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 的注册区<br/>= 一组 TA
    AMF->>gNB: 5. 向注册区内所有 gNB 发 Paging<br/>(UE 标识 + TA 列表 + 寻呼原因 + 优先级)
    Note over gNB: 6. 在每个相关小区<br/>计算 PF/PO, 安排广播
    gNB->>UE: 7. 在寻呼时机广播<br/>(用 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 不同的手机，几乎一定会落到不同的格子里，从而实现负载均衡。

这个"按 ID 取模打散"的设计，是整个寻呼机制里最优雅的一笔。它让成千上万部手机在没有任何协调的情况下，自发地错峰醒来，把寻呼信道的瞬时负载摊平——这正是分布式系统里"用确定性哈希实现负载均衡"的经典思想。

七、eDRX：物联网设备的极致省电

普通手机的 DRX 周期到秒级就够省电了，但物联网设备（水表、烟感、跟踪器）有更极端的需求：它们可能一天只收一次指令，电池要撑十年。于是有了 eDRX（extended DRX）——把 DRX 周期大幅延长。

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 — 通信原理图解权威站点，含 PO/PF 计算与寻呼信道映射的详细说明。
2. 5G Paging Procedure - techlteworld — 含 Paging Frame / Paging Occasion 与 P-RNTI 工作机制的教程式讲解。
3. Paging in 5G Network - free5GC — 开源 5G 核心网项目对寻呼优先级与触发流程的实现视角解读。
4. 5G Paging Procedure and How It Differs from LTE Paging - LinkedIn — 5G 与 LTE 寻呼差异对比，含 RRC_INACTIVE 与 RNA 寻呼增强说明。
5. Discontinuous Reception (DRX) in 5G NR - telecomHall — 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 等场景全覆盖。