想象一个生活场景：你中午在宿舍睡觉，门牌号没挂、手机静音，但快递员必须把一件急件送到你手上。快递员不知道你在哪张床上，只知道你登记的宿舍楼栋。他唯一能做的办法，是站在楼下喊你的名字——喊不到，就隔十分钟再喊一轮。
蜂窝网络每天都在重复这个故事。对方拨通电话、服务器推来一条消息时，你的手机大概率正处于“睡觉”状态：没有连接、不占信道、甚至不知道自己在哪个小区的覆盖下。网络要把你找回来，靠的就是一套精密的“下楼喊人”机制——寻呼（Paging）。
这篇文章把寻呼这件事拆开讲透：手机为什么要睡觉、网络凭什么知道去哪儿喊、手机凭什么只在自己“值班”的时刻醒来、一次完整的被叫接力中每一跳信令都发生了什么。理解了寻呼，你就理解了移动网络在“省电”与“可达”这对矛盾上的全部设计哲学。
先建立一个反直觉的事实：手机待机时，和网络之间没有任何专用连接。
很多人以为“手机有信号”就等于“手机连着网”。实际上，一部安静躺在你口袋里的手机，与网络之间只有一份“登记关系”——网络知道你大概在哪个区域，但没有为你预留任何无线资源。原因只有一个字：电。
我们算一笔账。如果手机要保持一条常开的无线连接：
所以移动网络的设计者做了一个干脆的取舍：没有数据往来时，就把连接拆掉，让手机睡觉。但拆掉连接带来一个新问题——下行数据是网络发起的。上行好办，手机想发数据，随时醒来敲门（随机接入）就行；可对方打来的电话、服务器推来的消息，网络怎么交给一部“正在睡觉、且没有连接”的手机？
答案就是寻呼：手机睡觉，但不睡死；网络喊人，但不瞎喊。双方靠一套预先约定好的“值班表”配合，手机只在约定的极短时刻醒来听一耳朵，其余时间射频全关；网络只在必要的范围内广播，不做全城喇叭。
理解寻呼之前，必须先理解手机的 RRC 状态。RRC（无线资源控制）状态决定了手机和网络之间的“熟络程度”，也决定了谁来喊、在哪儿喊。
用一个公司类比：
三种状态下，下行数据的到达方式、手机的耗电、移动时的信令行为完全不同：
| 状态 | 生活类比 | 下行数据如何到达 | 手机移动时 | 耗电水平 |
|---|---|---|---|---|
| CONNECTED | 坐在工位 | 专用通道直接下发 | 上报测量，网络指挥切换 | 高 |
| INACTIVE | 园区待命 | 基站在小范围通知区内寻呼 | 小范围移动不打扰核心网 | 中 |
| IDLE | 回家睡觉 | 核心网在登记区域内寻呼 | 跨登记区才重新报备 | 低 |
这张表里藏着移动性管理的骨架：状态越“深”，连接越省事但越耗电；状态越“浅”，越省电但找到你越费劲。寻呼，就是“浅状态”下网络找到你的唯一正规渠道。
这里还牵出网络侧的一张底账：手机在空闲态移动时，跨过登记区边界才向网络重新报备一次。所以网络手里始终握着一份粗粒度的位置档案——你不在哪个具体小区，但你在某几个登记区的列表里。寻呼的范围，就是按这份档案划定的。
如果网络喊人的时候手机完全不监听，那永远喊不到；如果手机时刻监听，那就等于没睡觉。工程上的折中方案叫非连续接收（DRX，Discontinuous Reception），它是整个寻呼机制的心脏。
DRX 的思路是把时间切成一层一层的格子，造出一张“排班表”：
整个结构画出来是这样：
flowchart TD
A["寻呼周期 T 例如 1.28 秒"] --> B["周期内划分出若干寻呼帧 PF"]
B --> C["每个 PF 里再划出寻呼时机 PO"]
C --> D["手机用自己的 ID 算出专属 PF 与 PO"]
D --> E["只在那一刻短暂监听控制信道"]
E --> F{"窗口里有自己的名字吗"}
F -->|有| G["解码寻呼消息 发起响应"]
F -->|没有| H["关闭射频 继续睡到下个周期"]
这套设计最精妙的地方在第四步之前的一个问题：一部手机怎么知道自己该在哪个格子醒来？
答案是取模错开。网络在登记时给每部手机分配了一个临时用户标识，手机把它拿来对周期内的格子总数做取模运算：
$$\text{专属寻呼帧号} = (\text{临时用户标识}) \bmod \text{周期内寻呼帧数}$$
（这是概念示意；实际计算还要叠加帧号偏移、寻呼分组等细节，各代网络略有差异，但核心思想就是取模。）
模运算的结果天然均匀分布——成千上万部手机，各自的临时标识不同，取模后就自动散落到了不同的寻呼帧和寻呼时机上。没有人排班，但每部手机都有一张互不冲突的专属值班表。这样带来两个直接好处：
注意一个容易误解的点：DRX 周期决定了寻呼的下限时延。假设周期是 1.28 秒，那么一条下行数据到达时，手机最坏情况要睡到 1.28 秒后才会醒来看见寻呼。这就是为什么打电话时，从“网络收到被叫请求”到“你手机响铃”之间总有一段无法压缩的等待——那段时间里，你的手机很可能还在睡觉。
现在把镜头拉远，看一次完整的寻呼接力。假设有人给你的手机发来一条消息（或者一个语音呼叫路由到了你的号码），此时你的手机正在空闲态睡觉：
sequenceDiagram
participant P as UPF
participant A as AMF
participant G as 基站
participant U as 手机
P->>A: 下行数据到达 发现用户无连接
A->>A: 查用户状态与登记的 TA 列表
A->>G: 向登记区内所有基站发寻呼指令
G->>U: 空口广播寻呼 含用户临时标识
Note over U,G: 手机在专属值班窗口醒来听到
U->>G: 发起随机接入请求连接
U->>A: 业务请求 我在 我要收数据
A->>P: 建立下行隧道
P->>U: 数据下发 响铃或消息弹出
逐段拆解这场接力：
第一棒：数据到了核心网。数据包先抵达用户面网关（UPF）。UPF 不关心你睡没睡觉，它只发现一件事：这个用户的下行隧道是断的，包发不出去。于是它通知控制面的大脑 AMF：有人找这个用户，但他现在没连接。
第二棒：AMF 查户口。AMF 翻出这个用户的登记档案——他上次报备的位置是“登记区列表”（由若干个跟踪区组成，可能横跨几十上百个基站）。注意，AMF 不知道也不需要知道你在哪个具体小区，它只知道范围。
第三棒：范围广播。AMF 通过基站间的接口，向登记区列表覆盖的所有基站、所有小区下达寻呼指令。这张网可能罩住几平方公里的城区。每个基站在空口上用一条专门的寻呼控制信令（业内用固定保留的无线标识 P-RNTI 来加扰，手机开机就认得这个“大喇叭专用频道”）把寻呼消息喊出去，消息里带着你的临时标识。
第四棒：手机在值班窗口听见。你的手机此刻正按第三节讲的排班表睡觉。当下一个专属寻呼时机到来，它睁开眼、解码控制信道、发现大喇叭里喊的正是自己的临时标识。这里有个隐私细节：广播的是网络分配的临时标识，而不是你的真实号码或永久身份——这只是顺手一提，身份隐身是另一套机制，这里不展开。
第五棒：手机敲门。听见喊自己，手机不再睡了，立刻发起随机接入，向网络发出业务请求：“我在，请把通道给我建起来。”此后走的是标准的连接建立流程，核心网重建下行隧道，积压的数据包哗啦啦送达——电话在这时开始响铃。
把寻呼环节再单独画一张全景图：
flowchart TD
A["对方来电或下行数据"] --> B["数据先抵达 UPF"]
B --> C["发现手机没有连接"]
C --> D["AMF 查手机登记的 TA 列表"]
D --> E["向登记区内所有基站发寻呼"]
E --> F["各小区空口广播寻呼消息"]
F --> G{"手机醒了吗"}
G -->|到点醒来听到| H["随机接入并发起业务请求"]
G -->|还在睡 下周期再听| F
H --> I["连接建立 数据送达"]
留意 G 到 F 那条回路：手机没醒，寻呼会按策略重发。实际网络通常采用分层重试——第一轮喊完没人应，间隔一小段时间再喊第二轮，甚至扩大范围重喊。你在现网里看到的“寻呼成功率”，统计的就是这几轮广播之后能把人喊醒的比例。
5G 引入的 INACTIVE 状态，把寻呼分成了两种玩法，它们的发起者、范围和代价都不同：
| 对比项 | 核心网寻呼（对空闲态） | 无线侧寻呼（对非激活态） |
|---|---|---|
| 谁来喊 | AMF 发起 | 锚点基站自己发起 |
| 在哪儿喊 | 整个登记区列表（可能几十上百个基站） | 一小块通知区（通常几个到几十个小区） |
| 手机的位置档案 | 由核心网维护，靠跨区报备更新 | 由基站维护，范围外移动才更新 |
| 广播开销 | 大 | 小 |
| 找到你的速度 | 较慢，范围大、链路长 | 较快，范围小、链路短 |
| 典型场景 | 普通待机的手机 | 刚断开连接、随时可能再传数据的手机 |
为什么要有两种喊法？还是那对根本矛盾。有些业务（比如断断续续的小包传输）频繁地在“有数据”和“没数据”之间切换：走空闲态，每次都要核心网全面寻呼加完整建链，信令开销太大；走连接态，耗电又顶不住。INACTIVE 状态是工程师们在中间挖出的第三条路：连接的“骨头”（上下文）还留在基站里，但手机的射频可以睡觉。要找你，基站自己在小范围内喊一声就行，既不用惊动核心网，又能快速恢复到全速传输。
理解这一点对调试很有价值：如果你在现网抓信令，看到核心网层面毫无动静、但空口却有寻呼记录，大概率就是无线侧寻呼——它根本不经过 AMF。
寻呼机制里没有“最优参数”，只有“按场景取舍的参数”。把最重要的几个旋钮摆在一起看：
| 设计旋钮 | 调大后的收益 | 调大后的代价 |
|---|---|---|
| 寻呼 DRX 周期 | 手机更省电，待机时间更长 | 被叫接通更慢，最坏要等一个整周期 |
| 登记区覆盖范围 | 手机移动时报备更少，信令更省 | 单次寻呼的广播面更大，寻呼信道负载更重 |
| 寻呼重发次数 | 喊醒成功率更高 | 空口资源占用更多，整体接通时延更差 |
| 全省电模式（如注册时声明“只发不收”） | 物联网设备可做到极长待机 | 网络完全不来找你，下行永远不可达 |
这几行表格里藏着运营商网络规划中最经典的矛盾——登记区划多大？
历史上不少运营商都为登记区划分交过学费，最终普遍收敛到类似的工程共识：按话务和人口密度划区，让“报备频率”和“寻呼负载”两边都不爆表。标准本身不规定划多大，只提供机制——怎么划，是每个网络自己的规划艺术。
另外两个旋钮也值得一提。DRX 周期对手机厂商是体验问题（省电直接决定待机口碑），对网络是时延问题，双方按能力协商取一个交集；而物联网场景干脆给出了极端选项——设备注册时声明自己“只发不收”，网络从此彻底不喊它，换取以年计的电池寿命，代价是这类设备永远收不到下行。
最后把原理接回日常工程。以下几类问题，根子都在寻呼机制上：
“测速飞快，被叫却打不通。”这是最经典的用户投诉组合。上下行速率反映的是连接态的性能，而被叫不通查的是空闲态的可达性——两者走的是完全不同的机制。遇到这种投诉，先查寻呼成功率，再查手机登记状态，而不是盯着带宽看。
“被叫接通时延忽长忽短。”拆一下时延构成：随机接入几百毫秒、连接建立几百毫秒、核心网处理几十毫秒——这些都很稳定。真正随机的部分是寻呼等待：取决于数据到达时手机正睡在周期的哪个位置，最坏要等整整一个 DRX 周期。看到被叫时延分布出现“阶梯状”的多峰，峰间距接近 DRX 周期档位，基本可以断定瓶颈在寻呼等待。
“寻呼成功率阴跌。”可能的原因链很长：登记区边界规划不合理导致手机位置档案过期、寻呼信道拥塞导致广播被压、重发策略配置过激进导致资源互踩、甚至终端侧深度休眠行为变化。排查的共同起点是把“哪一轮寻呼、哪个范围、哪种标识”三个维度拆开统计——原理清晰了，指标才能拆到根因。
“广播风暴类故障。”如果登记区划得过大、或某个边界区用户反复跨越，寻呼广播和报备信令会互相推高。判断方法同样来自原理：看寻呼量与报备量是否呈跷跷板状——这边压下去那边抬起来，说明范围划分需要重新调配。
还有一个常见的认知误区值得单独提醒：寻呼范围不是越大越保险。“多喊几个基站，成功率不就上去了吗？”——单次看是这样，系统看是反的。广播面扩大带来寻呼信道负载上升，拥塞后所有用户的寻呼都开始丢，成功率反而整体下滑。寻呼从来是一场“恰到好处”的艺术，不是火力覆盖的游戏。
把全文收拢成一句话：寻呼是用“预先约定的排班表 + 粗粒度的位置档案”换来的省电与可达平衡。手机睡觉但按取模错开的值班时刻醒来；网络不掌握你的精确位置，但知道自己该在哪个范围内开喇叭；喊不到就分层重试，喊到了就走标准建链把数据送达。DRX 周期、登记区大小、重发策略，每个旋钮都在“省电、时延、信令负载”三角里做取舍——没有完美档位，只有场景匹配。
下次你的手机在口袋里响起时，那声铃背后是：一个数据包在核心网的等待、一张覆盖数百小区的广播网、一次精确到毫秒的准时睁眼，和一段从睡觉到全速连接的百米冲刺。移动通信的很多智慧，都藏在这种“没人注意的日常”里。
Q: 寻呼为什么不能像短信秒达一样立刻到达手机？ A: 因为空闲态手机在按 DRX 周期睡觉，网络发出寻呼后，必须等手机走到自己下一个专属值班窗口才能听见。这个等待最长可达一个完整寻呼周期（几百毫秒到两三秒），是机制保证省电的固有代价，无法通过优化信令消除，只能靠调短周期来换——但那要牺牲待机时间。
Q: 手机重启后位置变了但没报备，寻呼会不会找不到人？ A: 网络有兜底策略：第一轮在旧登记区喊不到，会按策略扩大范围或在更新后的档案里重试；同时手机发现自己跨了登记区，也会在下次符合条件时主动重新报备。极端情况下（长时间无报备且重试失败），网络会将该用户标记为不可达，呼叫方会直接听到“无法接通”。
Q: 寻呼消息里喊的是我的手机号吗？别人能监听到我的行踪吗？ A: 不是手机号，通常是网络分配的临时用户标识，且临时标识会定期更换。空口上的寻呼广播只暴露“某个临时标识被呼叫”这一事实，想凭它持续追踪某个特定用户，需要能跟踪标识的更换规律，机制上做了刻意的阻隔设计。
Q: 4G 和 5G 的寻呼机制差别大吗？ A: 骨架完全一脉相承——DRX 排班、取模错开、按登记区广播，这套思想两代通用。5G 的主要增量是新增了非激活态，多出一种由基站自己发起的小范围寻呼，让“刚断开但随时回来”的会话不用每次都惊动核心网；此外支持按寻呼分组进一步降低无效唤醒。
Q: 物联网水表这类设备，是不是永远打不进来电话？ A: 如果设备注册时声明了“只发不收”类省电模式，则网络不会寻呼它，下行确实不可达——这是设备主动选择的契约，适合水表这种“只上传”的场景。若设备需要被呼叫（如智能门禁、可远程唤醒的终端），就要注册成普通可达模式，并接受相应的耗电代价。
本文由「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 等场景全覆盖。