# 待机手机的叫醒服务：寻呼原理 深夜两点，你的手机躺在床头一动不动，屏幕黑着，没有流量，看似和 network 彻底断了联系。可就在这时，有人拨通了你的号码——一秒之内，手机准时响起。问题来了：**基站明明不知道你此刻的精确位置，它凭什么一找一个准？** 答案是一套精巧的「约定时刻、定点广播」机制：**寻呼（Paging）**。它是移动性管理里最容易被忽略、却最能体现设计智慧的一环——切换解决的是「连接着的人怎么搬家」（此前我们写过《换站瞬间》），位置更新解决的是「人到了新片区怎么登记」（此前写过《手机为啥要报平安》），而寻呼解决的是最后一个反直觉的问题：**对一部没有连接、不报位置、还在睡觉的手机，网络怎么把它找出来。** ## 一、先把问题拆开：找一个「不报位置的人」有多难 想象你是酒店前台，一位客人寄居在你这栋楼里，但你只知道他住在这个片区的某个房间，不知道具体是哪间。现在有他的快递到了，你怎么送达？ 朴素的做法有两个，都不划算： - **挨个房间敲门**——总能找到，但成本爆炸。对应到无线网络：基站持续向所有小区发送呼叫信号，空口资源被白白烧掉，手机也得时刻竖着耳朵，电量大亏。 - **让他别睡了，一直守着对讲机**——随叫随到，但客人会被熬死。对应到手机：接收机持续开机监听，待机功耗会翻好几倍，一天充三次电。 所以寻呼的设计，本质是在三个相互撕扯的目标之间找平衡： 1. **省电**：手机绝大部分时间要睡觉，接收机必须关掉； 2. **可达**：只要有人找，必须在可接受的时延内叫醒它； 3. **省资源**：网络不能为每部待机手机单独维护一条通道。 下面三个设计决策，就是这场平衡的三个支点。 ## 二、设计决策一：记片区，不记点位 网络根本不记录待机手机的精确位置。手机只在「换片区」时才上报一次位置（即位置区更新），核心网账本上只记一句：**这个用户在 A 片区**。 这里的「片区」就是**跟踪区（Tracking Area，TA）**：由运营商规划的一组相邻小区的集合，可能覆盖一个城区。有人找你时，网络不用知道你在哪个基站下面，直接把这个片区的**所有小区全部广播一遍**。一部手机的寻呼，是几十上百个基站同时开口喊的——以广播的「浪费」，换来了对手机位置感知的「零要求」。 这个思路初看很笨：为了找一个人，喊遍整个片区。但算一笔账就明白：位置更新是**每个手机、每次跨片区**都要发生的信令，而寻呼只在**真有人找**时才发生。用「低频事件的大范围广播」，避免了「高频事件的全网信令」，这是整个移动性管理里最经典的以空间换时间。 ## 三、设计决策二：不随时听，只在约定时刻睁眼 光有片区还不够，手机自己也在睡觉。这就引出第二个机制：**非连续接收（DRX，Discontinuous Reception）**。 网络和手机事先约定一个**寻呼周期 T**：每隔 T 时间，手机才把接收机打开一小会儿，听一耳朵有没有人叫它，没有就立刻接着睡。约定好的取值是 32、64、128 或 256 个无线帧——一个无线帧长 10 毫秒，所以周期就是： | 周期配置 | 醒来间隔 | 被叫响应时延 | 待机功耗 | 典型取舍 | | --- | --- | --- | --- | --- | | 32 帧 | 320 ms | 最低 | 最高 | 语音优先 | | 64 帧 | 640 ms | 较低 | 较低 | 智能手机常用 | | 128 帧 | 1.28 s | 较高 | 低 | 普通数据业务 | | 256 帧 | 2.56 s | 最高 | 最低 | 深度省电 | 这就是「睡眠-检查-再睡」的节奏。T 越长越省电，但来电响铃越慢——你选了 2.56 秒的周期，最坏情况下电话要多等两秒半才震起来。面向物联网的设备还可以把周期进一步拉长（扩展非连续接收），用水表、传感器「几个月被叫一次」的场景，换出以周计的续航。 ## 四、设计决策三：睁眼时刻不用通知，自己算 现在是关键问题：全网几亿部手机，网络要不要挨个通知「你明天 8:05 醒来」？不需要。**睁眼时刻是每部手机用自己的身份算出来的**，双方各算各的，结果必然一致。 整套时间表是三层漏斗，从粗到细： ```mermaid flowchart TD A["寻呼周期 T
多久去一趟邮局
320ms 至 2.56s"] --> B["寻呼帧 PF
这个周期里的哪一天去"] B --> C["寻呼时刻 PO
那一天中的哪个时段
每帧最多 4 个"] C --> D["PDCCH 监听窗口
具体盯住哪个瞬间"] ``` 这就像一个**邮局信箱**的使用规则：你不会每五分钟跑一趟邮局（周期 T 决定多久去一次），也不会随机挑日子（寻呼帧 PF 决定周期里哪一天去），到了那天还要定死时段（寻呼时刻 PO 决定当天几点去开箱）。 具体怎么算？手机入网时从小区广播里读到一组参数（寻呼周期、每帧寻呼时刻数、帧偏移），再加上自己的临时身份，两步算出唯一答案。 **第一步，算出自己在这个周期里的「寻呼帧」：** $$\left( \mathrm{SFN} + \mathrm{PF_{offset}} \right) \bmod T = \left\lfloor \frac{T}{N} \right\rfloor \times \left( \mathrm{UE\_ID} \bmod N \right)$$ 其中 SFN 是系统帧号（网络的全局时钟），满足这个等式的那个帧号，就是你的寻呼帧。 **第二步，算出寻呼帧里的「寻呼时刻」序号：** $$i_s = \left\lfloor \frac{\mathrm{UE\_ID}}{N} \right\rfloor \bmod N_s$$ 每个寻呼帧内可有 1、2 或 4 个寻呼时刻（$N_s$ 决定），$i_s$ 就是你分到的那个时段编号。 **第三步，身份取模。** 手机的计算种子是自己的临时身份对 1024 取余： $$\mathrm{UE\_ID} = \mathrm{5G\text{-}S\text{-}TMSI} \bmod 1024$$ 汇总一下这几个角色： | 参数 | 谁提供 | 直觉含义 | | --- | --- | --- | | T（寻呼周期） | 小区广播 | 多久醒一次，320ms～2.56s 四档 | | N | 由广播参数算出 | 一个周期里被划成多少个「寻呼帧日」 | | PF_offset | 小区广播 | 你的「那一天」在周期里的整体偏移 | | Ns | 小区广播 | 每个「那一天」里再分几个时段（1/2/4） | | UE_ID | 手机自算 | 临时身份取模，唯一决定你分到哪个时刻 | 注意一个漂亮的性质：**所有广播参数全网一致，唯一的变量是手机自己的 ID。** 于是人群被自然地打散——ID 尾号不同的手机，散落在不同的帧、不同的时刻，同一瞬间醒来的只是一小撮人。既不会全城手机同时睁眼把基站挤爆，也不需要网络为任何人单独排班。**零信令开销，天然负载均衡**，这就是寻呼能扩展到亿级用户的根本原因。 ## 五、睁眼之后：候诊室里的叫号广播 到了约定时刻，几百部手机同时醒来盯着同一个窗口。基站在这里广播的不是一部手机的专享消息，而是一张**叫号名单**： - 控制信道上用专门的寻呼标识加扰一条调度指令，相当于大屏幕亮出「开始叫号」； - 名单（寻呼记录列表）里逐条列着被叫手机的临时身份，**一条消息最多可携带约 32 条寻呼记录**，把同一时刻醒来的多部被叫手机打包喊话。 每部醒来的手机解开名单，逐条比对：有自己的临时身份？起身响应。没有？立刻接着睡，全过程不到几毫秒。 ```mermaid flowchart TD A["闹钟到点
手机睁眼"] --> B["监听控制信道
寻找寻呼指示"] B --> C{"有寻呼调度吗"} C -->|没有| D["继续睡觉"] C -->|有| E["解出叫号名单"] E --> F{"名单里有自己吗"} F -->|没有| D F -->|有| G{"当前处于什么状态"} G -->|空闲态| H["发起完整连接建立"] G -->|非激活态| I["走快速恢复流程"] ``` 像不像候诊室叫号？广播是给所有人听的，但叫到名字的只有一个人。**广播的介质，私享的效果**——这是空口「下行天然是广播信道」这一物理特性，被协议设计用到极致的案例。 顺带一提，名单里喊的是临时身份（外号），不是永久的设备号（真名）。空口广播谁都能听，直接喊真名等于让人可以被长期追踪定位。这套「对外只报外号」的隐私设计与我们之前写过的《别报真名：SUCI身份加密原理》一脉相承，此处不再展开。 ## 六、两条寻呼路：核心网喊人，基站也喊人 很多人以为寻呼只有一种，其实有两条路，消息格式几乎一样，差别在**谁发起、喊什么身份、手机醒来干什么**： | 维度 | 核心网寻呼 | 无线网寻呼 | | --- | --- | --- | | 发起者 | 核心网（如有人打电话、发消息） | 基站自己（如网络侧数据到达） | | 手机状态 | 空闲态（无连接） | 非激活态（连接被「暂停」） | | 名单中的身份 | 临时身份（5G-S-TMSI 类） | 完整的恢复标识 | | 广播范围 | 整个跟踪区的所有小区 | 原基站下属的无线区 | | 醒来后动作 | 从零开始建立连接 | 快速恢复原有连接 | 第二条路是 5G 的新设计。5G 引入了一个中间状态：手机和网络的连接不彻底拆除，而是**「挂起」**——上下文像合上的书一样留在原处。下次要恢复时，不必重读全书，直接翻到书签页。这就是「快速恢复」：省掉一串建立信令，被叫接通时延明显缩短。一句话对比：**4G 醒来是重新开机，5G 醒来是从睡眠中唤醒。** ```mermaid flowchart TD A["有人找这部手机"] --> B{"手机什么状态"} B -->|空闲态| C["核心网发起寻呼
携带临时身份"] B -->|非激活态| D["原基站发起寻呼
携带恢复标识"] C --> E["整个跟踪区
所有小区广播"] D --> F["原基站周边
无线区内广播"] E --> G["手机从零建链"] F --> H["手机快速恢复"] ``` 范围差异也值得品味：核心网不知道你的精确位置，只能按「片区」喊，喊得广；基站自己挂起的连接，本来就知道你最后待在自己的地盘里，喊得窄。**谁掌握的信息多，谁就能喊得省。** ## 七、一通深夜来电的完整旅程 把所有机制串起来，看被叫电话从拨出到振铃的全过程： ```mermaid sequenceDiagram participant C as 主叫方 participant A as 核心网 participant G as 片区基站群 participant U as 被叫手机 C->>A: 拨打被叫号码 A->>A: 查登记位置（跟踪区） A->>G: 向整个片区下发寻呼 G->>U: 名单广播（含被叫外号） Note over U: 被叫恰在约定时刻醒来 U->>G: 对上号，随机接入 G->>A: 连接建立，通知核心网 A->>C: 振铃接通 ``` 注意时序图里那行注释：**「恰在约定时刻醒来」**。寻呼能否成功，一半的赌注押在手机身上——它必须在自己算出的那个时刻准确醒来。如果被叫恰好处于 2.56 秒的长周期，主叫这头就要多等上一两秒；如果手机正在隧道里错过了一个醒来的窗口，网络还要按周期**重发寻呼**，等它下次睁眼再喊一遍。你感受到的「接通快慢」，就是这些环节排队时间的总和。 ## 八、实战连接：调试时这些知识用在哪 **1. 寻呼容量与拥塞。** 一个小区单位时间能送的寻呼量 ≈ 每周期的寻呼时刻数 × 每条消息可带的记录数。跨年晚会、演唱会散场这类话务洪峰，寻呼请求可能挤爆控制信道。扩容的旋钮有三个：把每帧时段数调大（Ns 从 1 到 4）、把寻呼帧密度调高（N 增大）、把周期调短（T 减小）——但每个旋钮都让手机更费电、基站控制开销更大。**寻呼容量和待机功耗，是一根杠杆的两端。** **2. 跟踪区规划是一门平衡术。** 片区划得太大：寻呼要在海量小区里广播，负荷高、成功率被稀释；划得太小：手机频繁跨区、位置更新信令暴涨。成熟网络还会刻意让片区边界绕开交通干线和人流密集带——否则通勤人流来回横跳，边界小区会被位置更新信令打爆。 **3. 常见调试陷阱。** - **误判一：寻呼不到就查覆盖。** 无线覆盖差确实会导致手机收不到寻呼，但别急着重走路段——核心网侧用户状态异常、号码签约问题、跟踪区登记错乱，都会让寻呼根本没被下发。先分段定位：信令到底发到基站了没有。 - **误判二：把接通慢都赖给无线。** 长寻呼周期是最常见的「隐形时延」：设备出厂选了 2.56 秒周期省电，用户却抱怨电话响得慢。看一眼周期的配置，往往一行参数就破案。 - **误判三：忽视寻呼重发的时延叠加。** 被叫错过一次寻呼窗口，网络会隔周期重发，最坏情况是多个周期叠加，在指标上表现为被叫建立时延的「长尾」。 - **新方向的减负：寻呼提前指示。** 后续版本引入了「预告灯」机制——在正式叫号前先发一个极低功耗的短指示，手机瞄一眼就知道这个窗口跟自己有没有关系，没关系就直接睡回笼觉，连主控制信道都不必解。这是同一套原理在新硬件功耗需求下的自然延伸。 标准在各环节允许多种实现选择，具体参数行为以各设备厂家官方文档为准。 ## 九、回顾：三条设计哲学 把寻呼拆开，我们看到的是三条可迁移的设计智慧： 1. **用粗粒度换信息省略**——记片区不记点位，位置感知的代价被压到最低； 2. **用约定换通信**——睁眼时刻由双方各自计算，零信令完成亿级设备的排班； 3. **用广播换规模**——一张叫号名单服务同时醒来的所有人，广播介质做出了私享效果。 下次深夜来电一秒响起时，你会知道：这不是魔法，而是你的手机和全城基站，早就把「几点几分、哪条街道、喊哪个外号」约定好了。 ## 常见问题 **Q: 寻呼和切换有什么区别？** A: 服务对象不同。切换管的是「已经建立连接」的手机在基站之间搬家，数据跟着无缝接力；寻呼管的是「没有连接」的待机手机——它没有专享通道，只能靠广播喊醒。一个在连接态发生，一个在空闲/非激活态发生。 **Q: 为什么广播里喊外号（临时身份），不直接喊真名？** A: 空口广播是开放介质，任何人用接收设备都能监听。若长期喊同一个真名，持有者的行踪轨迹就能被第三方绘制出来。临时外号会定期更换，监听者无法把先后两个外号关联到同一个人，隐私由此保住。 **Q: 手机怎么知道该几点醒来？网络又怎么知道？** A: 双方不需要互相通知。小区广播参数人人可见，手机加上自己的临时身份即可算出唯一时刻；网络侧用同一套公式、同一个身份，算出同一个答案。这就是「约定」的力量——两边独立执行同一算法，天然对齐。 **Q: 寻呼周期是谁决定的？能改吗？** A: 默认周期由小区广播给所有手机；个别手机在连接建立时也可协商专用周期（常用于语音优先场景取短周期）。物联网设备用扩展非连续接收把周期拉到分钟级以上，用被叫时延换续航。 **Q: 为什么有时被叫接通特别慢，要好几秒？** A: 接通时延是排队总和：寻呼周期等待 + 片区多小区广播 + 手机随机接入 + 连接建立，任何一环拥塞都会累加。实战中最常见的根因有两个——手机用了长寻呼周期，或者首次寻呼丢失后等待周期性重发。 ## 参考来源 1. [ShareTechnote: 5G/NR Paging](https://www.sharetechnote.com/html/5G/5G_Paging.html) — 本文寻呼周期取值、PF/PO 计算公式、寻呼记录列表结构、CN/RAN 双路径对比等关键事实的主要核对来源 2. 樊昌信《通信原理》（第7版） — 调制与广播信道部分的经典教材参考 3. 杨鸿文等《移动通信》课程讲义及同类高校教材 — 跟踪区规划、位置更新与寻呼权衡的通行论述 --- > 本文由「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 等场景全覆盖。