首页 › deep-tech › 寻呼原理：网络的大海捞针术

寻呼原理：网络的大海捞针术

一、从一个生活场景说起

假设你住在一个有一万间客房的超大型酒店里，手机关了静音睡午觉。朋友突然有急事找你，但他只知道你"住在三楼到五楼某个房间"，不知道具体哪一间。他该怎么办？

最笨的办法是从 301 房间开始挨个敲门——这是"遍历搜索"，效率低到令人发指。聪明一点的办法是：你和朋友事先约定好，每小时的第 15 分钟，你一定会到三楼大厅前台看看有没有留给你的便签。这样朋友只需要在前台放一张纸条，到点你自然会来取。

蜂窝移动通信里的寻呼（Paging），干的就是这件事——只不过"前台"是无线空口，"便签"是寻呼消息，而"约定见面的时间"是一套精密计算出来的时刻，叫做寻呼时机（Paging Occasion, PO）。

这篇文章要回答的核心问题是：当一台手机处于休眠状态时，网络如何以最小的代价把它"喊醒"，并让它建立连接来接收来电或数据？

二、为什么要"喊醒"它，而不是直接发数据？

要理解寻呼，先得理解手机的工作状态。5G 里 UE 有三种 RRC 状态：

RRC_CONNECTED（连接态）：手机和基站之间有完整的 RRC 连接，上下行随时可传数据，网络精确知道手机在哪个小区。
RRC_IDLE（空闲态）：手机没有 RRC 连接，但周期性醒来监听寻呼；网络只知道它在哪个跟踪区（Tracking Area, TA），不知道具体小区。
RRC_INACTIVE（非激活态）：5G 新增的"半休眠"状态，RRC 连接被挂起但 UE 上下文还保留在基站里，网络知道它在哪个 RNA（RAN 通知区）。

为什么要设计空闲态？因为手机绝大部分时间并不在打电话或刷视频。如果一直保持连接，基站的 RRC 上下文、空口控制信道资源会被上亿台手机占满，电池也撑不过半天。于是协议规定：没活干的时候，手机主动断开连接、进入睡眠，只在约定的时刻醒一下看看"有没有人找我"。

这就带来一个根本矛盾：网络想把数据发给手机，但不知道它确切在哪个小区，而且它正在睡觉。 直接发数据？发不出去——没有 RRC 连接，没有空口承载。于是必须先用寻呼把它"喊醒"，让它发起连接建立，建立之后数据才能真正送达。

一句话总结：寻呼是网络对休眠终端的一次"点名"，目的是触发终端从空闲态/非激活态回到连接态。

三、寻呼消息的"三层管道"：PCCH → PCH → PDSCH

寻呼消息从协议栈走下来，要经过三层信道映射，理解这个映射是看懂空口寻呼的基础：

flowchart LR
    A["RRC层<br/>Paging消息"] --> B["逻辑信道<br/>PCCH"]
    B --> C["传输信道<br/>PCH"]
    C --> D["物理信道<br/>PDSCH"]
    D --> E["空口<br/>被P-RNTI加扰的DCI 1_0调度"]

    style A fill:#e8f5e9
    style B fill:#fff3e0
    style C fill:#e3f2fd
    style D fill:#f3e5f5
    style E fill:#fce4ec

为什么要分这么多层？这是蜂窝协议栈"层层封装"的设计哲学——每一层只管自己的职责：

PCCH（寻呼控制信道）是逻辑信道，专门承载寻呼这类"一对多"的广播类控制信息，因为它要发给不知道具体在哪的 UE，不能用专用的逻辑信道（如 DCCH）。
PCH（寻呼信道）是传输信道，负责把 PCCH 的数据块映射到物理层，并支持寻呼消息的合并（soft combining）——如果 UE 没解对，下次还能做 HARQ 合并，提高解调成功率。
PDSCH（物理下行共享信道）是物理信道，寻呼消息最终和大家抢着用的下行共享物理资源一起发出。

关键的"暗号"是 P-RNTI（Paging RNTI），固定值为 0xFFFE。基站在 PDCCH 上发一个用 P-RNTI 加扰的下行控制信令（DCI format 1_0），相当于在大喇叭里喊："下面这条 PDSCH 是给寻呼用的，所有醒着的空闲手机都来听！" UE 醒来后第一件事就是去自己的 PO 上抓 PDCCH，看有没有被 P-RNTI 加扰的 DCI；有就去解 PDSCH，没有就接着睡。

四、核心设计：约定见面时间——PF 与 PO

这是寻呼最精妙、也最容易被工程师误解的部分。

4.1 为什么不能让所有手机在同一时刻醒来？

如果一万个手机都在同一毫秒醒来监听寻呼，会有两个灾难性后果：

空口拥塞：大家同时去解同一批 PDCCH/PDSCH，但一个 PO 能塞下的寻呼记录有限，挤不下就丢呼。
瞬时功耗尖峰：射频前端同时唤醒，电流冲击大。

所以协议把时间轴切成一个个寻呼帧（Paging Frame, PF），每个 PF 里再切成若干个寻呼时机（Paging Occasion, PO），让每个手机根据自己的身份号算出自己的 PF 和 PO，从而把上亿用户均匀打散到不同的时刻醒来。这本质上是一种基于身份的负载均衡哈希。

4.2 三个关键参数

参数	含义	说明
T	寻呼 DRX 周期	手机两次醒来之间的间隔，单位是无线帧（10ms）。典型值 32/64/128/256。T 越大越省电，但寻呼延迟越大。
nB	寻呼密度参数	取值可以是 4T、2T、T、T/2……，控制每 T 个无线帧里有多少个 PF、每个 PF 里有多少个 PO。
N	每 T 帧中的 PF 数	$N = \min(T, nB)$，即一个 DRX 周期内的 PF 个数。
Ns	每个 PF 中的 PO 数	$Ns = \max(nB/T, 1)$。
UE_ID	用户身份哈希值	$UE_ID = \text{5G-S-TMSI} \bmod 1024$，把 48 比特的临时身份压成 0~1023。
PF_offset	寻呼帧偏移	用于错开不同小区的 PF 时序，避免邻区干扰。

4.3 两个决定命运的公式

给定上述参数，每个手机用两步算出自己醒来的时间：

$$ (SFN + PF_offset) \bmod T = (UE_ID \bmod T) $$

这个等式成立的那些系统帧号（SFN），就是该 UE 的寻呼帧 PF。

$$ i_s = \left\lfloor \frac{UE_ID}{N} \right\rfloor \bmod Ns $$

算出来的 $i_s$（取值 0 ~ Ns−1），就是该 UE 在这个 PF 里的第几个 PO。

为什么用取模和整除？ 这正是"哈希打散"的数学精髓：

第一个公式的 UE_ID mod T 把用户分到 T 个桶里（决定"哪个周期内的哪个 PF"）；
第二个公式的 floor(UE_ID/N) mod Ns 进一步把同一个 PF 桶里的用户细分成 Ns 个小组（决定"PF 内的第几个 PO"）。

因为 UE_ID 是从临时身份派生的伪随机值，不同的手机会自然分散到不同的 (PF, PO) 组合上，几乎不会撞车。这就是工程上的优雅：用两行取模运算，解决了一个上亿用户的负载均衡问题，而且完全去中心化——每个基站、每个手机各自独立计算，结果却天然对齐。

下面这张图展示了一个 T=64、Ns=4 的时间轴上，三台手机各自落在不同的 PO：

flowchart LR
    subgraph TA["DRX周期 T = 64个无线帧"]
        direction TB
        P0["PO #0  (UE_A)"]
        P1["PO #1  (UE_B)"]
        P2["PO #2  (空)"]
        P3["PO #3  (UE_C)"]
    end

    PF1["寻呼帧 PF<br/>含4个PO时机"] --> P0
    PF1 --> P1
    PF1 --> P2
    PF1 --> P3

    Sleep["手机在两个PO之间<br/>深度睡眠(关射频)"]:::sleep --> PF1

    classDef sleep fill:#37474f,color:#fff
    style TA fill:#e8f5e9
    style PF1 fill:#fff3e0

手机醒来的逻辑很关键：它不是每 10ms 都醒，而是在自己算出的那一个 PO 时刻醒一小会儿（监听若干个 PDCCH 监听时机），检查有没有被 P-RNTI 加扰的 DCI。没抓到，立即关射频继续睡；抓到了，去解 PDSCH 里的寻呼记录，看里面有没有自己的身份号。这种"绝大多数时间在睡、只在精确时刻探头看一眼"的模式，正是手机能待机好几天的根本原因。

五、寻呼的完整信令时序

光有 PO 计算还不够，真正把一台手机喊醒，是核心网、无线网、终端三方接力。下面是CN 寻呼（核心网寻呼）的完整时序，针对 RRC_IDLE 态的终端：

sequenceDiagram
    participant UE as 终端 UE (空闲态)
    participant gNB as 基站 gNB
    participant AMF as 核心网 AMF
    participant SMF as 会话管理 SMF
    participant UPF as 用户面 UPF
    participant Caller as 主叫方

    Caller->>UPF: 下行数据包到达<br/>(但UE无N3连接)
    UPF->>SMF: 缓存数据, 通知有下行数据
    SMF->>AMF: 发起寻呼请求<br/>(携带UE的5G-S-TMSI、TA列表)
    Note over AMF: AMF查UE上下文<br/>得到UE注册的TA列表
    AMF->>gNB: 向TA列表内所有gNB发Paging<br/>(Namf_Communication_N1N2MessageTransfer / Paging)
    Note over gNB: 每个gNB各自用UE_ID<br/>算出PF和PO
    gNB->>UE: 在正确的PO上发<br/>PDCCH(P-RNTI加扰的DCI1_0)
    gNB->>UE: 在PDSCH上发Paging消息
    Note over UE: UE醒来检测, 匹配到自己身份
    UE->>gNB: 发起RRC Setup Request
    gNB->>AMF: 触发Initial UE Message / 业务请求
    AMF->>SMF: 通知UE已被唤醒
    SMF->>UPF: 建立N3隧道, 释放缓存数据
    UPF->>UE: 下行数据正式送达

注意几个工程上极重要的细节：

寻呼是"广播"给 TA 内所有基站的。AMF 不知道 UE 在哪个小区，所以它把寻呼请求发给 UE 注册的整个 TA 列表里的所有 gNB。这是一个"宁可错杀一片、不可漏掉一个"的冗余设计——代价是空口资源开销。
真正在空口发寻呼的，是 UE 当前驻留的那个 gNB（其他 gNB 收到了请求但 UE 不在它覆盖下，UE 自然收不到，没关系）。
寻呼消息里带的是 5G-S-TMSI（临时身份）而不是永久身份 SUPI，这是为了隐私——防止空口监听者通过 SUPI 追踪用户行踪。
数据先在 UPF 缓存，等 UE 真正建立连接后才下发，所以"接通了"那一刻其实数据早就到了门口，只是没有钥匙开门。

六、两种寻呼：CN 寻呼 vs RAN 寻呼

5G 引入 RRC_INACTIVE 态后，寻呼分成了两类。这是 5G 相对 4G 的一个重要优化，理解它们的区别是工程师必备的内功：

维度	CN 寻呼（核心网寻呼）	RAN 寻呼（无线网寻呼）
适用终端状态	RRC_IDLE	RRC_INACTIVE
发起者	AMF（核心网）	最后服务 gNB（无线网）
寻呼范围	TA 列表（核心网跟踪区）	RNA（RAN 通知区，通常更小）
UE 上下文	已释放，不在基站	挂起但保留在原 gNB
唤醒后的动作	全新 RRC 连接建立（较重）	RRC 连接恢复（Resume，较快）
设计目标	兜底可达性	减少信令、快速恢复、省电
跨基站协同	经 N2 接口	经 Xn 接口在 RNA 内 gNB 间转发

为什么要发明 RAN 寻呼？ 想象一个 IoT 场景：成千上万个传感器，每隔几秒发一个几十字节的小包。如果每次发完就回到 IDLE 态，每次发送都要做完整的位置更新和 RRC 建立，核心网信令会被压垮。于是 5G 让这类终端停留在 INACTIVE 态——上下文还挂在基站，但空口连接释放。基站用一个比 TA 更小的 RNA 来跟踪它。当有下行数据时，基站自己在 RNA 范围内寻呼，根本不打扰核心网，UE 用 Resume 快速接回，既省信令又省电。

这体现了移动性管理的一个深刻权衡：位置跟踪的精度越高，跟踪信令开销越大；精度越低，寻呼开销越大。 TA/RNA 的大小，就是在"位置更新信令"和"寻呼资源"之间找平衡点。

七、寻呼范围是怎么来的：跟踪区设计

寻呼之所以能限定在 TA 内而不是全网广播，靠的是手机主动上报位置。这里有一条隐形的契约：

手机侧：当它移动到一个不属于当前注册 TA 列表的新小区时，必须主动发起注册更新，把自己所在的新 TA 告诉网络。
网络侧：AMF 把 UE 的 TA 列表记在上下文里，下次寻呼就在这个列表范围内发。

为什么不直接跟踪到小区级？因为如果跟踪到小区级，手机每跨一个小区就要上报一次（城市里可能几十米一个小区），信令风暴会让网络瘫痪。TA 通常包含几十到上百个小区，手机跨 TA 才上报，上报频率降低一两个数量级。

更进一步，网络给 UE 分配的往往不是一个 TA，而是一个 TA 列表（TA List）——一组相邻的 TA。只要 UE 还在这组 TA 里移动，就不需要做注册更新。这是把"位置跟踪粒度"和"乒乓注册"问题一起解决的妙招：在 TA 边界来回晃悠的手机，不会因为频繁跨越单一边界而疯狂上报。

flowchart TB
    subgraph RegArea["UE的注册区 = TA列表 (TA1, TA2, TA3)"]
        TA1["TA1<br/>含多个小区"]
        TA2["TA2<br/>含多个小区"]
        TA3["TA3<br/>含多个小区"]
    end
    UE(["UE"]) -.在RegArea内移动.-> TA1
    UE -.在RegArea内移动.-> TA2
    UE -.在RegArea内移动.-> TA3
    Note1["✅ 在TA列表内移动: 无需注册更新<br/>❌ 移出TA列表: 触发注册更新<br/>📞 下行数据: AMF在TA列表内广播寻呼"]
    RegArea --> Note1
    style RegArea fill:#e3f2fd
    style Note1 fill:#fff8e1

八、实战连接：工程师怎么用这些知识

理论落到现网，寻呼原理在三个场景里特别有用：

场景一：被叫打不通（最常见）

用户投诉"别人打我电话打不通，但我自己能打出去"。这种单向故障，排查的第一步就是看寻呼有没有发出去、有没有成功。用抓包工具看：

核心网侧：AMF 有没有发出 Paging？发给了哪些 TA？如果根本没发，要往上查 SMF/UPF 是否检测到下行数据、是否触发了寻呼。
基站侧：gNB 有没有收到、有没有在 PO 上发 PDCCH？
终端侧：UE 在不该睡的时候是不是一直在睡？DRX 周期配对了吗？

场景二：寻呼成功率低 / 寻呼拥塞

现网指标里有一个"寻呼成功率"。如果偏低，常见原因：

PO 拥塞：某个时刻 PO 上要塞的寻呼记录太多塞不下，丢了一部分。这时候要调 nB 增加寻呼密度，或者优化 UE_ID 的分布。
覆盖问题：UE 在弱覆盖区，PDCCH 解不出来，醒来了但没抓到 DCI。表现为随机接入前先掉队。
DRX 周期不匹配：UE 期望的 DRX 周期和网络配置不一致，导致醒来时刻算错，永远对不上。这是最容易踩的坑。

场景三：物联网终端大量接入

几百万 NB-IoT/RedCap 终端，每个都周期性小数据。如果不优化，要么寻呼风暴，要么信令风暴。这里 RRC_INACTIVE + RAN 寻呼 + 小 RNA 的组合拳就是答案——把寻呼范围缩到最小、把恢复流程做到最轻。

常见调试陷阱

误以为寻呼是"一发就到"：寻呼本质上是无确认的广播。网络发了寻呼，UE 没响应，网络并不知道 UE 到底在不在，只能等下一次数据再触发一次寻呼（通常重试若干次后放弃）。所以"寻呼发了 ≠ 终端收到了"。
混淆 PO 与子帧：4G 的 PO 是子帧级别的概念，5G 的 PO 是一组 PDCCH 监听时机的集合，可能跨多个时隙。把 4G 的直觉直接套到 5G 上会算错。
忽略 PF_offset 的作用：邻区如果 PF 完全对齐，会同时发寻呼造成干扰。PF_offset 就是为了错开。调网优时如果某些小区寻呼成功率系统性偏低，查一下 PF_offset 配置。

九、常见问题

Q1: 寻呼和随机接入有什么关系？是不是一回事？ A: 不是。寻呼是网络找终端（下行方向），发生在终端空闲/非激活时；随机接入是终端找网络（上行方向），是终端主动发起的敲门过程。两者的联系是：终端收到属于自己的寻呼后，会发起随机接入来建立/恢复连接，也就是说寻呼是"前菜"，随机接入才是真正"上桌吃饭"的动作。

Q2: DRX 周期设多长最合适？ A: 这是一个典型的"省电 vs 时延"权衡。周期越长（如 256 帧 ≈ 2.56s），终端越省电，但被叫接通延迟越大；周期越短（如 32 帧），响应快但费电。语音用户倾向短周期保证接通率，IoT 传感器倾向长周期省电。现网通常是分场景配置，甚至给同一终端在不同时段配不同周期。

Q3: 为什么寻呼消息要用临时身份 5G-S-TMSI，而不用永久号码？ A: 纯粹为了隐私和安全。永久身份 SUPI 是用户的长期凭证，如果明文在空口广播，监听者就能追踪用户位置甚至冒充。用临时身份寻呼，即使被截获也只能看到一个会定期更换的临时编号，无法关联到具体用户。这和"快递只显示收件人姓氏、不显示完整身份证号"是同一个道理。

Q4: RAN 寻呼为什么能比 CN 寻呼快？ A: 因为 RAN 寻呼时，UE 的 RRC 上下文、安全上下文、QoS 流都还保留在原基站，UE 只要发一个 Resume Request，基站把挂起的连接"解冻"即可，跳过了完整的连接建立、鉴权、会话重建等重流程。这就像酒店保留你的房间没有退房，你回来直接用房卡开门，而 CN 寻呼相当于重新办入住。

Q5: 一台手机会不会同时收到多个基站的寻呼？ A: 会。因为 AMF 把寻呼发给整个 TA 列表的所有基站，UE 驻留小区的邻区也可能在发（如果 UE 在小区边缘）。这是设计的冗余，UE 只需响应其中一个（通常是信号最好的那个）。多余寻呼是"必要浪费"，换取的是可达性保证。

参考来源

5G NR Paging 寻呼原理与实现机制 - 阿里云开发者社区 — 详解 PCCH→PCH→PDSCH 三层信道映射与寻呼接收流程。
Paging in 5G Network - free5GC — 5G 开源核心网项目对空闲态寻呼机制的权威解读。
5G 寻呼 paging 总结 - 知乎 — 端到端视角的寻呼信令协调流程解析。
5G 信令流程 — UE 寻呼（Paging）流程 - 华为云社区 — 结合 AMF/SMF/UPF 的现网寻呼信令流程。
5G NR Paging（寻呼) - CSDN — DRX、PF、PO 计算与接收流程的系统讲解。

本文由「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 等场景全覆盖。

51学通信知识星球海报-扫码加入