# 寻呼时机：终端的省电闹钟 ## 一、从一个根本矛盾说起：可达性与省电的两难 想象你周末在家休息，朋友想来找你。你会怎么应对？如果一直把门开着、竖起耳朵听楼道动静，那你能第一时间听到敲门声，可一整天精神紧绷、什么都干不了；如果干脆把门反锁、手机关机、钻进被窝，那倒是彻底放松了，可朋友站在门口喊破喉咙你也听不见。 移动通信里的终端（手机）每天就处在这个两难里。当手机没有正在进行的通话或数据业务时，它会进入**空闲态**，把射频收发机尽量关掉以省电——毕竟没有人愿意一天充三次电。可问题来了：如果某条微信、某个来电此时恰好到达，网络该怎样找到一台"基本处于休眠"的手机？让手机一直醒着太费电，让手机彻底睡死又找不到它。**寻呼（Paging）**，连同它的省电搭档 **DRX（非连续接收）**，就是为破解这个矛盾而生的一整套机制。 理解寻呼的关键不是背流程，而是看懂一个贯穿始终的设计思想：**网络和终端各算各的，却能在同一个时间点不约而同地"碰头"。** 这种无需实时协商的分布式默契，是整个空闲态移动性管理最精巧的地方。 ## 二、寻呼的本质：广而告之的点名 空闲态终端最显著的特征是：**网络并不知道它到底在哪个小区（Cell）里。** 这听起来很反常——网络不是时刻盯着手机吗？其实不然。终端一旦进入空闲态，基站上属于它的上下文（context）就被删除了，它和某个具体小区之间不再有任何连接。核心网只保留了一条粗粒度的位置记录：**这台手机在某个跟踪区（Tracking Area，TA）范围内。** 跟踪区是若干小区的集合，由一个或多个基站组成。核心网用一个聪明的设计进一步降低信令开销——**跟踪区列表（TA List）**：注册时一次性给终端分配一组相邻的跟踪区，只要终端还在列表范围内活动，就**不需要**做任何位置更新；只有当它走出列表、进入一个全新的跟踪区时，才发起一次跟踪区更新（TAU）。这就像给你的会员卡关联了三家连锁店，你在任何一家消费都不用重新登记，直到你去第四家才需要更新。 代价是：当有来电到达时，核心网只能确知"手机在这几个跟踪区里"，却不知道具体哪个小区。于是它采用最直接也最"暴力"的办法——**在这几个跟踪区覆盖的所有小区里，同时广播一条寻呼消息，广而告之地把这台手机"点出来"。** ```mermaid graph TB AMF["🧠 AMF
核心网：知道UE在TA List内
不知具体小区"] subgraph TA1["跟踪区 TA1"] C1["小区1"] C2["小区2"] end subgraph TA2["跟踪区 TA2"] C3["小区3"] C4["小区4"] end AMF -->|"NGAP Paging"| G1["gNB-A"] AMF -->|"NGAP Paging"| G2["gNB-B"] G1 --> C1 G1 --> C2 G2 --> C3 G2 --> C4 C1 -.->|"广播Paging"| UE["📱 UE
藏在某个小区"] C2 -.->|"广播Paging"| UE C3 -.->|"广播Paging"| UE C4 -.->|"广播Paging"| UE ``` 这种"找人不去敲某一扇门，而是全商场广播"的方式，牺牲了空口资源（要在很多小区重复发），换取了**无需精确定位**的可达性。这是一个典型的工程权衡：在跟踪区粒度上做位置管理，把"找人"的代价摊到了广播上。 ## 三、寻呼信令的完整旅程 那么一条寻呼消息，从"下行数据到达"到"终端被唤醒"，究竟走过了哪些节点？这正是工程师在抓包排查"接不到电话"问题时最关心的一条链路。 ```mermaid sequenceDiagram participant UE as 📱 UE（空闲态·沉睡） participant gNB as 📡 gNB participant AMF as 🧠 AMF participant UPF as 🌐 UPF Note over UPF: 下行数据到达
但该UE无N3连接 UPF->>AMF: 下行数据通知 Note over AMF: 仅知UE所在TA List
不知具体小区 AMF->>gNB: NGAP Paging（UE ID + TA List） Note over gNB: 在相关小区
按公式计算该UE的PF/PO gNB->>UE: 空口Paging（P-RNTI加扰PDCCH） Note over UE: DRX周期恰好到期
在PO唤醒并监听 UE->>gNB: RRC Setup Request gNB->>AMF: Initial UE Message AMF->>gNB: 初始上下文建立 Note over UE: 进入连接态
开始接收下行数据 ``` 整条链路有两个关键"接力棒"。第一棒在核心网内部：用户面节点收到发给空闲态终端的数据，发现没有可用的下行隧道，于是**把数据暂存，转而去通知控制面节点**——是控制面来决定怎么"找人"，用户面只管"东西到了"。第二棒在空口：基站收到寻呼请求后，并不是立刻就发，而是要先把这条寻呼"塞进"目标终端的那个特定的、唯一的唤醒时刻里去。这就要进入寻呼机制最精妙的部分——DRX与寻呼时机的计算。 ## 四、DRX：终端的省电闹钟 如果手机在每个无线帧、每个子帧都老老实实监听下行控制信道，那它根本省不下电来。**非连续接收（DRX）** 的思路极其朴素：手机绝大部分时间关掉接收机睡大觉，只在预定的、周而复始的几个"闹钟时刻"醒过来听一下。 整个机制围绕一个**DRX周期（记作 $T$）** 运转。在每一个长度为 $T$ 个无线帧的周期里，终端**只唤醒一次**，去监听属于自己的那一个**寻呼时机（Paging Occasion，PO）**。其余时间它都可以安心休眠。$T$ 越长，手机睡得越久、越省电，但网络找到它的最大延迟也就越大——这是个明摆着的省电与时延的权衡旋钮。 ```mermaid graph LR subgraph 周期T["DRX周期 T"] S1["😴 沉睡
接收机关闭"] -->|"..."| W1["⏰ PO
监听PDCCH"] W1 -->|"无寻呼"| S2["😴 沉睡"] end S2 -->|"下一周期"| S3["😴 沉睡..."] S3 --> W2["⏰ 下一个PO"] W1 -.->|"听到了我的寻呼"| R["发起RRC连接"] ``` 这里有个极其关键的问题：网络怎么知道在哪个时刻去广播？手机又怎么知道在哪个时刻醒来？两边没有实时通信（手机正睡着呢），却必须分毫不差地对上时间。答案藏在几个简单的取模公式里——网络和终端各自拿着同一套公式和同一个身份号码，**独立计算出一个完全相同的时刻**。这就是寻呼机制最优雅的地方。 ## 五、PF 与 PO：为什么是取模 理解寻呼计算，先要认识两个时间锚点。**寻呼帧（Paging Frame，PF）** 指的是"在哪个无线帧醒"，**寻呼时机（Paging Occasion，PO）** 指的是"在该帧内的哪个监听时机醒"。一个终端在一个 DRX 周期内，会被唯一地分配到**一个 PF**，以及该 PF 内的**一个 PO**。 整个计算的源头，是终端的临时身份号： $$ \text{UE\_ID} = \text{5G-S-TMSI} \mod 1024 $$ 为什么对 1024 取模？因为寻呼的"时间格子"本质上是在 $T$（最大 256 帧）这个量级里循环分配的，1024 这个数足够覆盖各种周期配置下的取模空间，又不会浪费太多比特。接着，网络广播一个关键参数 $nB$，它决定了寻呼的**容量**（后文详解）。由 $nB$ 和 $T$ 进一步算出两个中间量： $$ N = \min(T,\; nB), \qquad N_s = \max\left(1,\; \frac{nB}{T}\right) $$ 有了这些，PF 与 PO 就被算出来了： $$ (\text{SFN} \mod T) = (T \div N) \times (\text{UE\_ID} \mod N) $$ $$ i_s = \left\lfloor \frac{\text{UE\_ID}}{N} \right\rfloor \mod N_s $$ 公式看着唬人，但内核是一种大家很熟悉的思想——**哈希式的负载打散**。设想一下：如果一个城市里成千上万台手机都在同一个 PO 醒来，那个 PO 上的控制信道和数据信道会瞬间被挤爆，大量寻呼发不出去、造成漏呼。取模运算的作用，正是把每台手机均匀地"摊"到不同的 PF 和 PO 上，让寻呼负载均衡分布。终端的身份号 $5G\text{-}S\text{-}TMSI$ 天然各不相同，用它取模，就相当于把不同的手机丢进不同的"格子"。 最妙的是：**网络根本不需要去"通知"手机几点醒。** 手机自己用同样的公式、同样的身份号，算出"我的 PO 在第 X 帧的第 Y 个时机"；网络在生成这条寻呼时，也用同样的公式算出"这台手机的 PO 是第 X 帧第 Y 个时机"，于是把消息正好放到那个时刻去广播。两边没有一句对话，时间却严丝合缝地对上了。这种**预先约定算法、无需实时信令**的协调方式，是移动通信里反复出现的经典设计。 ## 六、nB 的玄机：一个容量旋钮，而非省电旋钮 很多人会把 $nB$ 误当成"调手机省不省电"的参数，这是最常见的误解之一。其实 $nB$ 是**网络的寻呼容量旋钮**，控制的是"每个 DRX 周期里，网络一共承诺发送多少个寻呼时机"。 仔细看上面两个中间量，可以推出一个简洁的恒等式： $$ N \times N_s = nB $$ 也就是说，**一个 DRX 周期内可供寻呼使用的 PO 总数，恰好等于 $nB$。** 当 $nB > T$ 时，说明容量需求大于帧数，于是通过增大 $N_s$ 让每个 PF 容纳多个 PO（把 PO 往一个帧里塞）；当 $nB < T$ 时，容量小于帧数，于是通过减小 $N$ 让多个帧共用更少的 PF。无论怎么调，$nB$ 都牢牢锁定着每周期可承载的寻呼名额。 对终端而言，它的唤醒频率只取决于 $T$，与 $nB$ 无关——这是必须牢牢记住的。$nB$ 影响的是网络一侧每秒钟能"点名"多少台手机。 | 参数 | 含义 | 典型取值 | 对终端/网络的作用 | |------|------|----------|-------------------| | $T$ | DRX 周期（无线帧数） | 32 / 64 / 128 / 256 | 终端省电与时延的核心旋钮 | | $nB$ | 每周期寻呼容量 | $4T \sim T/32$ | 网络"点名名额"，与终端省电无关 | | $N$ | 一个周期内 PF 数 | $\min(T, nB)$ | 把手机分散到不同寻呼帧 | | $N_s$ | 每个 PF 内 PO 数 | $\max(1, nB/T)$ | 一个帧内能寻呼多少台 | | $\text{UE\_ID}$ | 终端寻呼标识 | 5G-S-TMSI mod 1024 | 决定该终端被分到哪个格子 | | PF | 寻呼帧 | 满足上述公式的 SFN | 终端"在哪一帧"醒 | | PO | 寻呼时机 | 由 $i_s$ 索引确定 | 终端"在该帧何时"听 | ## 七、5G 的特色：波束扫描下的寻呼 到了 5G，特别是中高频段，基站普遍用上了大规模天线，靠**窄波束**轮流扫射来覆盖整个扇区。这给寻呼带来了一个新课题：寻呼消息该挂在哪个波束上发？ 5G 的做法是**把一个 PO 直接定义为一个完整的 SSB（同步信号块）波束扫描周期**。基站像灯塔一样，依次用波束 0、波束 1、波束 2……逐个方向把同一条寻呼消息**重复广播一遍**。终端根据自己平时测量到的"最佳 SSB"，在对应的那个波束时机上去监听即可。 ```mermaid graph TB gNB["📡 gNB"] -->|"波束0（SSB#0）"| B0["PO 起始时机"] gNB -->|"波束1（SSB#1）"| B1["对应时机"] gNB -->|"波束2（SSB#2）"| B2["对应时机"] gNB -->|"波束3（SSB#3）"| B3["对应时机"] B0 -.->|"相同Paging重复发送"| UE["📱 UE"] B1 -.->|"相同Paging重复发送"| UE B2 ==>|"UE最佳波束·在此监听"| UE B3 -.->|"相同Paging重复发送"| UE Note["一个 PO = 一个完整的
SSB 波束扫描周期
每个波束都重复发同一条寻呼"] ``` 这个设计巧妙地"一鱼两吃"：波束扫描本来就是为了用窄波束换取增益、扩大覆盖；把它和寻呼时机绑定后，终端既能在信号最好的波束上收到寻呼，网络又不必为每个终端单独判断它该用哪个波束——**因为终端会自己挑最好的那个波束去听。** 当然代价是空口开销变大（一条消息要在所有波束上重复发），这就是波束赋形带来的寻呼效率折损，也是工程上需要权衡的地方。 ## 八、eDRX 与 PSM：IoT 的终极睡眠 对普通手机来说，几秒一次的 DRX 周期已经是很好的折中。但对大量物联网终端——智能水表、环境传感器、远程抄表设备——它们可能几天甚至几个月才需要被网络找一次。如果还按普通 DRX 醒来，电池很快耗尽。于是衍生出两套更激进的省电机制。 | 机制 | 最长"睡眠"周期 | 可达性 | 典型应用 | |------|----------------|--------|----------| | **DRX** | 数秒（NR 约 2.56s，LTE 约 10.24s） | 高（几乎实时可达） | 普通手机 | | **eDRX**（扩展非连续接收） | LTE 约 44 分钟，NB-IoT 约 3 小时 | 中（寻呼延迟可达分钟级） | 智能穿戴、跟踪器 | | **PSM**（省电模式） | 数天至数月 | 极低（休眠期几乎不可达） | 水气表、传感器 | eDRX 本质上就是把 DRX 周期拉长到分钟甚至小时级——终端一睡睡很久，只在超长的"闹钟"到点时醒来听一下。PSM 则更极端：终端在发完自己的数据后，**直接进入近似关机状态**，关掉接收机，只有它自己主动发起通信时才"复活"。两者都在用可达性换电池寿命，背后是同一个朴素的取舍：**一个不常被找的设备，就不该为"也许有人找我"白白耗电。** ## 九、工程实战：调试中的陷阱与诀窍 这些原理在现网排查时，几乎处处都能派上用场。 **"信号满格却接不到电话"** 是最经典的寻呼故障。满格只代表参考信号好，不代表寻呼一定成功。问题可能出在 PF/PO 计算失配（比如终端和网络对 DRX 周期 $T$ 的理解不一致，常见于参数配置不同步）、波束切换中错过了最佳波束的 PO、或者基站侧寻呼拥塞导致 PO 被丢弃。排查时要顺着"核心网是否发出 NGAP Paging → 基站是否在空口该 PO 发了 P-RNTI → 终端是否在该 PO 唤醒"这条链路逐段定位。 **寻呼拥塞** 是另一类高发问题。当某个跟踪区内同时有大量终端（比如演唱会散场、高铁到站人群集中涌入），网络瞬时寻呼量激增。这时合理调大 $nB$（增加每周期寻呼名额）、优化跟踪区划分（避免边界小区反复触发 TAU 与寻呼风暴）就是网优的常规手段。要牢记：调 $nB$ 治"网络点不过来名"，调 $T$ 才治"终端醒得太频"，两者不能混为一谈。 **高铁场景**还有额外的难点。高速移动下终端可能快速穿过多个跟踪区，既要频繁 TAU 又要稳定接收寻呼，DRX 周期和跟踪区列表的规划需要特别针对线性覆盖优化，否则极易出现"刚更新完位置又被切走"的乒乓现象。 下面这张表把 4G 与 5G 寻呼的关键差异梳理清楚，方便对照理解 5G 的演进逻辑： | 维度 | 4G LTE 寻呼 | 5G NR 寻呼 | |------|-------------|------------| | 空口承载 | PDCCH（P-RNTI）+ PDSCH | PDCCH（P-RNTI）+ PDSCH | | 波束方式 | 扇区级宽波束 | 多波束扫描，PO 与 SSB 绑定 | | PO 定义 | 一个子帧 | 一组 PDCCH 监听时机（含多波束） | | 空闲态粒度 | RRC_IDLE | RRC_IDLE + RRC_INACTIVE（可被寻呼"唤醒"） | | 核心网节点 | MME | AMF | | eDRX 支持 | NB-IoT/eMTC 强支持 | NR 进一步增强，周期更长 | 值得一提的是 5G 新增的 **RRC_INACTIVE** 状态：终端看似"断开"了，但基站上还保留着它的上下文，被寻呼唤醒后可以**快速恢复连接**而不必重建，比 4G 的纯空闲态更省信令——这是为物联网与小数据传输专门做的优化，背后同样是"可达性 vs 省（信令）电"的权衡。 ## 常见问题 **Q1：DRX 周期 T 和 nB 到底谁决定终端省不省电？** A：是 $T$。$T$ 是终端的唤醒周期，越长越省电、越延迟。$nB$ 是网络侧每 DRX 周期承诺发送的 PO 总数，属于"网络点名容量"，与单台终端的唤醒频率无关。两者解决的是完全不同的问题，调试时绝不能调错旋钮。 **Q2：为什么网络不直接通知终端几点醒来监听？** A：因为终端大部分时间在休眠，收不到任何实时信令。所以网络和终端必须**各自用相同的公式独立计算**同一个 PO，靠预先约定的算法而非实时通信来对齐时间。这种"无信令协调"是寻呼机制能在终端休眠时仍然工作的根本前提。 **Q3：取模公式真的能把所有终端均匀打散吗？** A：基本能。终端的 5G-S-TMSI 是核心网分配的、近似随机分布的标识，用它取模相当于一次哈希，能较均匀地把终端分配到不同的 PF/PO 格子里。当用户数极大、且某些 PO 接近容量上限时仍可能局部拥塞，这就需要靠调整 $nB$、增大 $N_s$ 等手段扩容。 **Q4：寻呼消息为什么要在那么多小区重复广播，太浪费了吧？** A：这是用空口资源换"免精确定位"的可达性。核心网只知道终端在跟踪区列表范围内，不知道具体小区，要保证一定能找到它，就只能在该范围内全量广播。代价是空口开销，收益是终端无需为位置管理付出极高代价——这是移动性管理整体设计的一个核心权衡，跟踪区列表的引入正是为了尽量缩小这个广播范围。 **Q5：5G 里 PO 和波束是什么关系，终端怎么知道用哪个波束听？** A：5G 的一个 PO 等于一个完整的 SSB 波束扫描周期，基站会逐个波束重复广播同一条寻呼。终端平时持续测量各 SSB 的质量，自然知道自己的最佳波束是哪个，于是就在那个波束对应的监听时机上去听。网络无需为每个终端单独判断波束，由终端自行挑选，既保证接收质量，又简化了网络实现。 --- > 本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵**爱卫生**（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 > 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。 ## 参考来源 1. [5G | ShareTechnote - Paging](https://www.sharetechnote.com/html/5G/5G_Paging.html) — 5G NR 寻呼机制的权威图解教程，含 PF/PO 计算与波束扫描详解 2. [5G NR Paging 寻呼原理与实现机制 - 阿里云开发者社区](https://developer.aliyun.com/article/977822) — DRX 周期、PF、PO 的中文原理拆解与参数说明 3. [5g 寻呼信道 - 知乎专栏](https://zhuanlan.zhihu.com/p/510522403) — 4G/5G 寻呼 PF 与 PO 公式对比及取模计算过程 4. [What is eDRX (Extended Discontinuous Reception)? - Sierra Wireless](https://www.sierrawireless.com/iot-blog/edrx-lpwa/) — eDRX 扩展非连续接收在物联网中的省电原理 5. [eDRX and PSM for IoT: Battery-saving features explained - Onomondo](https://onomondo.com/blog/edrx-and-psm-for-lte-low-power-iot/) — eDRX 与 PSM 两种 IoT 省电机制的对比与应用场景 > [!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 等场景全覆盖。