想象你周末在家休息，朋友想来找你。你会怎么应对？如果一直把门开着、竖起耳朵听楼道动静，那你能第一时间听到敲门声，可一整天精神紧绷、什么都干不了；如果干脆把门反锁、手机关机、钻进被窝，那倒是彻底放松了，可朋友站在门口喊破喉咙你也听不见。
移动通信里的终端（手机）每天就处在这个两难里。当手机没有正在进行的通话或数据业务时，它会进入空闲态，把射频收发机尽量关掉以省电——毕竟没有人愿意一天充三次电。可问题来了：如果某条微信、某个来电此时恰好到达，网络该怎样找到一台"基本处于休眠"的手机？让手机一直醒着太费电，让手机彻底睡死又找不到它。寻呼（Paging），连同它的省电搭档 DRX（非连续接收），就是为破解这个矛盾而生的一整套机制。
理解寻呼的关键不是背流程，而是看懂一个贯穿始终的设计思想：网络和终端各算各的，却能在同一个时间点不约而同地"碰头"。 这种无需实时协商的分布式默契，是整个空闲态移动性管理最精巧的地方。
空闲态终端最显著的特征是：网络并不知道它到底在哪个小区（Cell）里。 这听起来很反常——网络不是时刻盯着手机吗？其实不然。终端一旦进入空闲态，基站上属于它的上下文（context）就被删除了，它和某个具体小区之间不再有任何连接。核心网只保留了一条粗粒度的位置记录：这台手机在某个跟踪区（Tracking Area，TA）范围内。
跟踪区是若干小区的集合，由一个或多个基站组成。核心网用一个聪明的设计进一步降低信令开销——跟踪区列表（TA List）：注册时一次性给终端分配一组相邻的跟踪区，只要终端还在列表范围内活动，就不需要做任何位置更新；只有当它走出列表、进入一个全新的跟踪区时，才发起一次跟踪区更新（TAU）。这就像给你的会员卡关联了三家连锁店，你在任何一家消费都不用重新登记，直到你去第四家才需要更新。
代价是：当有来电到达时，核心网只能确知"手机在这几个跟踪区里"，却不知道具体哪个小区。于是它采用最直接也最"暴力"的办法——在这几个跟踪区覆盖的所有小区里，同时广播一条寻呼消息，广而告之地把这台手机"点出来"。
graph TB
AMF["🧠 AMF<br/>核心网：知道UE在TA List内<br/>不知具体小区"]
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<br/>藏在某个小区"]
C2 -.->|"广播Paging"| UE
C3 -.->|"广播Paging"| UE
C4 -.->|"广播Paging"| UE
这种"找人不去敲某一扇门，而是全商场广播"的方式，牺牲了空口资源（要在很多小区重复发），换取了无需精确定位的可达性。这是一个典型的工程权衡：在跟踪区粒度上做位置管理，把"找人"的代价摊到了广播上。
那么一条寻呼消息，从"下行数据到达"到"终端被唤醒"，究竟走过了哪些节点？这正是工程师在抓包排查"接不到电话"问题时最关心的一条链路。
sequenceDiagram
participant UE as 📱 UE（空闲态·沉睡）
participant gNB as 📡 gNB
participant AMF as 🧠 AMF
participant UPF as 🌐 UPF
Note over UPF: 下行数据到达<br/>但该UE无N3连接
UPF->>AMF: 下行数据通知
Note over AMF: 仅知UE所在TA List<br/>不知具体小区
AMF->>gNB: NGAP Paging（UE ID + TA List）
Note over gNB: 在相关小区<br/>按公式计算该UE的PF/PO
gNB->>UE: 空口Paging（P-RNTI加扰PDCCH）
Note over UE: DRX周期恰好到期<br/>在PO唤醒并监听
UE->>gNB: RRC Setup Request
gNB->>AMF: Initial UE Message
AMF->>gNB: 初始上下文建立
Note over UE: 进入连接态<br/>开始接收下行数据
整条链路有两个关键"接力棒"。第一棒在核心网内部：用户面节点收到发给空闲态终端的数据，发现没有可用的下行隧道，于是把数据暂存，转而去通知控制面节点——是控制面来决定怎么"找人"，用户面只管"东西到了"。第二棒在空口：基站收到寻呼请求后，并不是立刻就发，而是要先把这条寻呼"塞进"目标终端的那个特定的、唯一的唤醒时刻里去。这就要进入寻呼机制最精妙的部分——DRX与寻呼时机的计算。
如果手机在每个无线帧、每个子帧都老老实实监听下行控制信道，那它根本省不下电来。非连续接收（DRX） 的思路极其朴素：手机绝大部分时间关掉接收机睡大觉，只在预定的、周而复始的几个"闹钟时刻"醒过来听一下。
整个机制围绕一个DRX周期（记作 $T$） 运转。在每一个长度为 $T$ 个无线帧的周期里，终端只唤醒一次，去监听属于自己的那一个寻呼时机（Paging Occasion，PO）。其余时间它都可以安心休眠。$T$ 越长，手机睡得越久、越省电，但网络找到它的最大延迟也就越大——这是个明摆着的省电与时延的权衡旋钮。
graph LR
subgraph 周期T["DRX周期 T"]
S1["😴 沉睡<br/>接收机关闭"] -->|"..."| W1["⏰ PO<br/>监听PDCCH"]
W1 -->|"无寻呼"| S2["😴 沉睡"]
end
S2 -->|"下一周期"| S3["😴 沉睡..."]
S3 --> W2["⏰ 下一个PO"]
W1 -.->|"听到了我的寻呼"| R["发起RRC连接"]
这里有个极其关键的问题：网络怎么知道在哪个时刻去广播？手机又怎么知道在哪个时刻醒来？两边没有实时通信（手机正睡着呢），却必须分毫不差地对上时间。答案藏在几个简单的取模公式里——网络和终端各自拿着同一套公式和同一个身份号码，独立计算出一个完全相同的时刻。这就是寻呼机制最优雅的地方。
理解寻呼计算，先要认识两个时间锚点。寻呼帧（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$ 是网络的寻呼容量旋钮，控制的是"每个 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 的做法是把一个 PO 直接定义为一个完整的 SSB（同步信号块）波束扫描周期。基站像灯塔一样，依次用波束 0、波束 1、波束 2……逐个方向把同一条寻呼消息重复广播一遍。终端根据自己平时测量到的"最佳 SSB"，在对应的那个波束时机上去监听即可。
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 = 一个完整的<br/>SSB 波束扫描周期<br/>每个波束都重复发同一条寻呼"]
这个设计巧妙地"一鱼两吃"：波束扫描本来就是为了用窄波束换取增益、扩大覆盖；把它和寻呼时机绑定后，终端既能在信号最好的波束上收到寻呼，网络又不必为每个终端单独判断它该用哪个波束——因为终端会自己挑最好的那个波束去听。 当然代价是空口开销变大（一条消息要在所有波束上重复发），这就是波束赋形带来的寻呼效率折损，也是工程上需要权衡的地方。
对普通手机来说，几秒一次的 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学通信」提供深度技术答疑和行业洞察。
[!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 等场景全覆盖。