5G 寻呼（Paging）机制信令全链拆解

一、为什么需要单独把"寻呼"拆开讲

在很多人的认知里，"寻呼"是 4G 时代就有的老机制，似乎没什么新东西。但如果你打开 3GPP TS 38.413 V18.5.0，会发现 NGAP 的 PAGING 消息里塞进了数量惊人的可选 IE——Paging Origin、Paging Priority、Paging DRX、Assistance Data for Paging、Paging Attempt Information、NR Paging eDRX Information、PEIPS Assistance Information、Paging Cause、Paging Policy Differentiation……这些 IE 不是一次性堆出来的，而是从 R15 到 R18，为了解决"省电""低时延""切片差异化""卫星""MBS""多 USIM"等十几个截然不同的需求，逐 Release 叠加上去的。

更需要澄清的一点是：在 Rel-18 的 TS 23.502 中，已经没有独立的"4.2.3 Paging procedure"章节了。寻呼流程被合并进了 clause 4.2.3 Service Request procedures 之下的 4.2.3.3 Network Triggered Service Request（网络触发的服务请求）。换句话说，在 5GC 的视角里，"寻呼"不是一个孤立的过程，而是"网络要把一个 CM-IDLE 的 UE 唤醒以建立信令/用户面连接"这个目标的第一步。理解这一点，是理解 5G 寻呼整体设计的钥匙。

本文聚焦 TS 23.502 clause 4.2.3.3 + TS 38.413 clause 8.5.1 / 9.2.4.1，从触发源一路拆到 RRC Paging 接收与 Service Request 响应，并逐一解析 NGAP PAGING 消息中的关键 IE，最后给出抓包识别与排错实战。

二、寻呼的三大触发场景

5G 的寻呼触发源比 4G 丰富得多，本质上对应三类"网络需要主动联系 UE"的需求：

1. 移动终结数据（MT Data）：UE 处于 CM-IDLE，UPF 收到下行数据，但 N3 隧道已断。UPF 缓存并触发 N4 Downlink Data Notification（DDN）（TS 29.244）给 SMF，SMF 再通过 Namf_Communication_N1N2MessageTransfer（TS 29.518）请求 AMF 寻呼 UE。这是最常见、流量最大的触发源。

2. 移动终结信令（MT Signalling）：网络要给 UE 下发 NAS 信令，例如 UE Configuration Update（策略更新）、下行 NAS 传输、SOR（Steering of Roaming）、下行 SMS over NAS 等。这类寻呼由 AMF 自身发起，不经过 SMF。

3. 非 3GPP 接入的寻呼（non-3GPP access paging）：这是 5G 相对 4G 全新的特性。UE 通过 N3IWF/W-AGF/TNGF 接入时，若 UE 同时在 3GPP 接入侧 CM-IDLE，网络可以在 3GPP 接入侧寻呼以通知"non-3GPP 侧有事件"。这正是 NGAP Paging Origin IE 取值为 non-3GPP access 的语义来源。

设计要点：5G 把寻呼触发与寻呼执行解耦——触发源（SMF/UPF 或 AMF 内部模块）只负责"告诉 AMF 我要找这个 UE"，而"如何找、在哪些 TA 找、用什么 DRX、是否带优先级"全部由 AMF 作为唯一的寻呼协调者来决策，再下发给 NG-RAN 执行。这种集中式协调是 5G 控制面服务化架构（SBA）的一个典型体现。

三、端到端信令时序图

下面这条时序图展示了一次完整的"下行数据触发的网络寻呼"全过程，从 UPF 收到下行数据包开始，到 UE 响应 Service Request 建立 N3 用户面为止。

sequenceDiagram
    participant DN as DN/服务器
    participant UPF as UPF
    participant SMF as SMF
    participant AMF as AMF
    participant RAN as NG-RAN(gNB)
    participant UE as UE(CM-IDLE/RRC_IDLE)

    DN->>UPF: 下行数据包(UE处于CM-IDLE)
    Note over UPF: N3隧道未建立,缓存数据
    UPF->>SMF: N4 Session Report(DDN, Downlink Data Notification)
    SMF->>AMF: Namf_Communication_N1N2MessageTransfer<br/>(SM信息+N2 Paging指示)
    Note over AMF: AMF决策:确定TA List、DRX、优先级、Paging Origin
    AMF->>RAN: N2 NGAP PAGING消息(非UE相关信令)
    Note over RAN: 按TAI List for Paging<br/>计算Paging Frame(PO/PF)
    RAN->>UE: Uu接口 RRC Paging(在对应PO上,PCCH逻辑信道)
    Note over UE: 核对5G-S-TMSI,匹配则响应
    UE->>RAN: RRC Setup Request(含Service Request,NAS)
    RAN->>AMF: INITIAL UE MESSAGE(Service Request)
    Note over AMF: 鉴权/安全模式(若需要)
    AMF->>SMF: Nsmf_PDUSession_UpdateSMContext(激活用户面)
    SMF->>UPF: N4 Session Modification(下发N3隧道信息)
    Note over AMF,SMF: N2 SM(隧道信息)->RAN,建立N3
    AMF->>UE: Service Accept
    UPF->>UE: 缓存的下行数据开始转发

几个值得注意的协议细节：

• AMF 发给 NG-RAN 的 PAGING 是 非 UE 关联信令（non-UE associated signalling），因为它走的是 SCTP 流上的全局信令通道，而不是某个 UE 专用的 NGAP 连接——此时 UE 还没建立 NGAP UE 上下文。
• PAGING 消息只会发到那些"服务 UE 注册区域内某些 TA"的 NG-RAN 节点。AMF 维护着每个 UE 的 TAI List（注册区），寻呼就按这个列表精准下发。
• RRC Paging 不是一条专用信令，而是承载在 PCCH 逻辑信道上的广播，UE 按 DRX 周期在特定的"寻呼时机（Paging Occasion, PO）"醒来监听。如果这条 PO 上的寻呼记录里没有自己的 5G-S-TMSI，UE 立即继续休眠——这是寻呼省电的核心。

四、NGAP PAGING 消息 IE 深度解析

打开 TS 38.413 clause 9.2.4.1，PAGING 消息由下列 IE 组成。下表对核心 IE 逐一说明（来源：TS 38.413 V18.5.0，第 8.5.1 节"Successful Operation"与第 9.3 节 IE 定义）。

其中最容易被忽视、却最能体现 5G 设计精髓的是 UE Identity Index Value。在 4G 里，eNodeB 自己用 IMSI mod 1024 算寻呼索引；而 5G 把这个计算结果由 AMF 算好放进 IE 传给 gNB，好处是 NG-RAN 与 CN 对"这个 UE 监听哪个 PO"达成一致，不会因为两边算法实现差异导致寻呼漏呼。

下面用一张结构图展示 PAGING 消息的 IE 组织关系，尤其是 Assistance Data for Paging 这个容器 IE 内部的嵌套：

flowchart TD
    PAGING["NGAP PAGING 消息<br/>(非UE关联信令)"]
    PAGING --> M1["UE Paging Identity<br/>= 5G-S-TMSI"]
    PAGING --> M2["UE Identity Index Value<br/>= 5G-S-TMSI mod 1024"]
    PAGING --> M3["TAI List for Paging"]
    PAGING --> O1["Paging DRX (O)"]
    PAGING --> O2["Paging Priority (O)"]
    PAGING --> O3["Paging Origin (O)<br/>3GPP / non-3GPP"]
    PAGING --> O4["Paging Cause (O, R17/R18)"]
    PAGING --> ADP["Assistance Data for Paging (O)"]
    PAGING --> ED["NR/eDRX/PEIPS 辅助信息 (O)"]

    ADP --> A1["Recommended Cells for Paging<br/>(推荐的寻呼小区)"]
    ADP --> A2["Recommended RAN Nodes for Paging"]
    ADP --> A3["Paging Attempt Information<br/>含 Next Paging Area Scope"]
    ADP --> A4["Paging Assistance Data for CE UE"]

    A3 --> A3a["Paging Attempt Count<br/>(第几次尝试)"]
    A3 --> A3b["Intended Attempt Count"]
    A3 --> A3c["Next Paging Area Scope<br/>(下次寻呼范围)"]

五、NG-RAN 如何决定"何时、在哪个 PO 上"寻呼

NGAP PAGING 到达 gNB 后，真正的"空中寻呼"由 NG-RAN 根据 TS 38.304（idle 模式）clause 7.1 的 DRX 规则计算。核心是两个量：Paging Frame（PF） 与 Paging Occasion（PO）。

• 寻呼周期 T：取 min(默认寻呼 DRX, UE 专属 DRX, T3413 相关) 的公共周期。
• PF 的系统帧号：SFN mod T = (T div N) × (UE_ID mod N)，其中 N = min(T, nB)，UE_ID 来自 NGAP 的 UE Identity Index Value。
• PO 的位置：由 i_s（从 UE_ID mod Ns 派生）和 Ns（每 PF 内 PO 数）确定，落在某个时隙。

这套公式的目的是让网络里所有被寻呼的 UE 在帧/子帧维度上被均匀打散，避免所有 UE 挤在同一个 PO 上解码造成拥塞。下图概括了从 NGAP 到 RRC 的 PO 计算决策链：

flowchart TD
    A["NGAP PAGING 抵达gNB"] --> B{"Paging DRX IE 是否存在?"}
    B -- 是 --> C["T = min(默认DRX, UE专属DRX)"]
    B -- 否 --> D["T = 默认寻呼DRX"]
    C --> E["读取 UE Identity Index Value = UE_ID"]
    D --> E
    E --> F["计算 PF: SFN mod T = (T div N)*(UE_ID mod N)"]
    F --> G["计算 i_s = floor(UE_ID/N) mod Ns"]
    G --> H["定位 PO 时隙"]
    H --> I{"PEIPS/eDRX 辅助信息?"}
    I -- 是 --> J["应用子组早指示 / eDRX时间窗"]
    I -- 否 --> K["在对应PO上发送RRC Paging"]
    J --> K
    K --> L["UE在PO醒来匹配5G-S-TMSI"]

六、UE 的响应：Service Request 与"拒绝寻呼"

UE 收到 RRC Paging 并匹配到自己的 5G-S-TMSI 后，并不直接回复"我收到了"，而是发起 Service Request（TS 24.501 / TS 23.502 clause 4.2.3.2），其本质是一次完整的接入流程：RRC Setup → INITIAL UE MESSAGE（含 Service Request）→ 鉴权/安全 → N2/N3 用户面建立。

Rel-17 引入的多 USIM（Multi-USIM）特性在这里产生了一个有趣分支：UE 可以在 Service Request 中携带 Reject Paging Indication，明确告诉网络"这次寻呼我不接，请释放 N1 连接且不要建用户面"，并可选地提供 Paging Restriction Information（如"接下来 30 秒别因为这条接入再寻呼我"）。这在双卡手机一边通话、另一边被寻呼的场景下非常有用，避免反复唤醒造成功耗浪费。AMF 收到后更新 UE 上下文中的 Paging Restriction Information，并在后续网络触发的 Service Request（4.2.3.3）中强制执行。

七、CN Paging 与 RAN Paging 的根本区别

5G 引入了 RRC_INACTIVE 状态：UE 空口连接挂起但保留 NG-RAN 上下文。于是寻呼分裂为两种完全不同的机制：

RAN Paging 的核心价值是 以极低的开销保住"几乎一直在线"的连接，这对海量物联网和时延敏感业务至关重要。当 UE 在 RNA 区域内移动时无需通知网络，只有当有下行数据到达挂起的 gNB、或周期性 RNA 更新超时，才触发 RAN Paging。这是 5G 省电体系里和 DRX 并列的两大支柱。

八、设计意图：为什么 5G 寻呼长成这样

把上述机制合在一起看，5G 寻呼的设计哲学可以概括为四点：

1. 集中决策、分布执行：AMF 掌握全部上下文（注册区、DRX、切片订阅、优先级、non-3GPP 状态），统一决策"在哪寻呼、怎么寻呼、给什么优先级"，gNB 只负责按规则执行 PO 计算与空口广播。这把复杂性集中在控制面、把执行简单化。

2. 省电优先，一切为功耗让路：从 DRX、RRC_INACTIVE、PEIPS 子组早指示、eDRX，到 Multi-USIM 的 Reject Paging，几乎每一条 R16/R17 增强都是为了让 UE 尽量少醒、醒了少解码。Paging Origin/Paging Cause 透传到 UE，让终端有能力做更聪明的本地决策（比如非 3GPP 侧事件、语音业务优先响应）。

3. 差异化与切片感知：Paging Priority（MPS/紧急）与 Paging Policy Differentiation（切片维度）让网络能对"哪类 UE 优先寻呼"做精细控制，这是 4G 不具备的能力。

4. 演进友好、向后叠加：TS 38.413 的 PAGING 消息保留了海量可选 IE，每个新特性（eDRX、PEIPS、Paging Cause、Multicast Group Paging）都以"可选 IE + shall if supported"的形式叠加，老 gNB 忽略、新 gNB 受益，保证了 15 年内的平滑演进。

九、抓包识别与故障排错实战

如何在 Wireshark 抓包里识别寻呼流程：

1. N4 侧：过滤 pfcp && pfcp.msg_type==19（Session Report Request），观察其中是否携带 Downlink Data Notification——这是寻呼的"火种"。
2. N11/SBI 侧：过滤 HTTP POST /namf-comm/v1/ue-contexts/{ueContextId}/n1-n2-messages，即 Namf_Communication_N1N2MessageTransfer，请求体里若 n2InfoContainer 为 NgapPaging 类型，则将触发寻呼。
3. N2/NGAP 侧：过滤 ngap.procedureCode==12（Paging），这是非 UE 关联信令，你会看到一条消息里携带 UE Paging Identity、TAI List for Paging、可选的 Paging Priority/Paging Origin。
4. 空口/Uu 侧：用终端 log 或路测工具看 PCCH 上的 Paging，确认 ue-Identity 是否等于该 UE 的 5G-S-TMSI。

常见故障点：

• UE 不响应寻呼（最常见）：90% 的原因是 PO 计算不一致。重点检查 AMF 下发的 UE Identity Index Value 是否等于 5G-S-TMSI mod 1024、UE 侧 5G-S-TMSI 与 AMF 是否同步、DRX 周期协商是否一致。其次是 TA 不匹配——UE 实际驻留的小区不在 TAI List for Paging 内（比如发生了未触发的越区）。
• 寻呼时延长、漏呼：检查 Paging DRX 周期是否设置过长；若 UE 订阅了 eDRX 但业务对时延敏感（如语音），需评估 Paging Time Window 是否覆盖业务需求。
• 寻呼风暴：通常是应用层心跳/保活导致大量 DDN，可结合 UPF 的 DDN 聚合、SMF 的"同一 PDU Session 短时间内只触发一次寻呼"逻辑、以及 UE 侧 PSM/eDRX 来缓解。
• AMF 侧 T3413（寻呼响应定时器）超时：会触发重寻呼，若多次失败则释放。需排查是空口问题还是 UE 问题。

常见问题

Q1：CN Paging 和 RAN Paging 能同时对一个 UE 发生吗？ A：理论上不会同时发生，因为它们对应不同的连接管理状态（CM-IDLE vs CM-CONNECTED）。但存在边界场景：当 UE 处于 RRC_INACTIVE（CM-CONNECTED）且 RAN Paging 多次失败后，NG-RAN 可能将 UE 释放到 RRC_IDLE，此时状态转为 CM-IDLE，后续由 AMF 发起 CN Paging。这是状态机驱动的级联，而非并发。

Q2：Paging Origin = non-3GPP access 到底是什么意思？ A：它表示这次寻呼是为了通知 UE"非 3GPP 接入（如通过 N3IWF 的 untrusted Wi-Fi）侧有事件等待处理"。典型场景是 UE 在 non-3GPP 侧 CM-IDLE，网络需要联系它，但选择在 3GPP 接入侧寻呼。UE 收到后可决定是否切回 non-3GPP 侧处理。这是 5G ATSSS/多接入特性的伴生能力。

Q3：UE Identity Index Value 为什么由 AMF 算好下发给 gNB，而不是各 gNB 自己算？ A：为了保证 CN 与 RAN 对 PO 的绝对一致。5G-S-TMSI 在 UE、AMF、gNB 三处都可得，取模运算虽简单，但统一在 AMF 计算、mod 1024 后作为 10 比特值显式传递，消除了"任何一端实现差异导致 UE 监听的 PO 与 gNB 发送的 PO 错位"的风险——这是协议层面的防呆设计。

Q4：PEIPS（寻呼子组早指示）到底省了什么？ A：传统 PO 上，所有"分配到该 PO 的 UE"醒来后都要解码完整的 PCCH 寻呼记录列表，哪怕最终没有自己的记录。PEIPS 在 PO 之前用更短的早指示携带"子组 ID"，UE 只需比对子组 ID——若不匹配立即继续休眠，无需解码完整寻呼。这把"无效解码"的功耗大幅降低，对海量物联网终端尤其关键。

Q5：为什么不直接用 SUPI 寻呼而要用 5G-S-TMSI？ A：出于隐私。SUPI 是永久身份，若明文在空口广播，会被用于追踪用户。5G-S-TMSI 是临时身份（由 AMF 分配，可周期性更新），在空口寻呼记录中以 ng-5G-S-TMSI 形式出现，使被动监听者无法将寻呼与具体用户长期绑定。这与 5G 的 SUCI 隐私保护（身份加密）一脉相承。

参考来源

1. 3GPP TS 23.502 V18.10.0 — Procedures for the 5G System — clause 4.2.3.2 / 4.2.3.3 Service Request procedures（含网络触发寻呼流程）
2. 3GPP TS 38.413 V18.5.0 — NG Application Protocol (NGAP) — clause 8.5.1 Paging procedure、9.2.4.1 PAGING 消息、9.3.x 各 IE 定义（Paging Priority/DRX/Origin/Cause、UE Paging Identity、Assistance Data for Paging）
3. 3GPP TS 38.304 V18 — NR; User Equipment (UE) radio access layer — clause 7.1 Discontinuous Reception for paging（PF/PO 与 DRX 计算）
4. ShareTechnote — 5G/NR Paging — 寻呼机制流程图与 PO/PF 计算解读
5. 3GPP TS 29.244 V18 — Interface between SMF and UPF (N4 PFCP) — Downlink Data Notification 触发寻呼的 N4 信令
6. 3glteinfo — 5G NGAP Paging Message — NGAP PAGING 消息与 IE 字段速查

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