# 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 用户面为止。 ```mermaid 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
(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
计算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 定义）。 | IE 名称 | 章节号 | 存在性 | 含义与作用 | |---------|--------|--------|-----------| | **UE Paging Identity** | 9.3.3.18 | 必选(M) | 携带被寻呼 UE 的临时身份。CM-IDLE 场景固定为 **5G-S-TMSI**（由 AMF Set ID + AMF Pointer + 5G-TMSI 拼成），用于 RRC 层寻呼记录匹配 | | **UE Identity Index Value** | 9.3.3.23 | 必选(M) | AMF 计算的 `5G-S-TMSI mod 1024`，NG-RAN 用它派生寻呼帧/寻呼时机，避免每个 gNB 重复计算 | | **TAI List for Paging** | 9.3.1.x | 必选(M) | 本次寻呼的目标跟踪区列表，NG-RAN 仅在这些 TA 覆盖的小区上发送 RRC Paging | | **Paging DRX** | 9.3.1.90 | 可选(O) | UE 专属 DRX 周期（若订阅/协商过），gNB 据此结合默认 DRX 计算 PO | | **Paging Priority** | 9.3.1.78 | 可选(O) | 优先级指示（取值在 RAN 层映射），用于 MPS/紧急业务等高优先级寻呼 | | **Paging Origin** | 9.3.3.22 | 可选(O) | 取值 `3GPP access` 或 `non-3GPP access`，透传给 UE，告知其"该寻呼源自哪个接入" | | **Paging Cause** | 9.3.1.x | 可选(O) | R17/R18 新增，指示寻呼原因（如语音业务），透传给 UE 助其决策 | | **Assistance Data for Paging** | 9.3.1.69 | 可选(O) | 容器 IE，内含 Recommended Cells、Recommended RAN Nodes、Paging Attempt Information 等 | | **NR Paging eDRX Information** | 9.3.1.227 | 可选(O) | R17 扩展 DRX，含 Paging Time Window，用于超低功耗物联网/卫星 UE | | **PEIPS Assistance Information** | — | 可选(O) | R17 寻呼子组（subgroup）辅助信息，让 UE 在 PO 前用早指示判断是否需解码完整寻呼 | 其中最容易被忽视、却最能体现 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 内部的嵌套： ```mermaid flowchart TD PAGING["NGAP PAGING 消息
(非UE关联信令)"] PAGING --> M1["UE Paging Identity
= 5G-S-TMSI"] PAGING --> M2["UE Identity Index Value
= 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)
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
(推荐的寻呼小区)"] ADP --> A2["Recommended RAN Nodes for Paging"] ADP --> A3["Paging Attempt Information
含 Next Paging Area Scope"] ADP --> A4["Paging Assistance Data for CE UE"] A3 --> A3a["Paging Attempt Count
(第几次尝试)"] A3 --> A3b["Intended Attempt Count"] A3 --> A3c["Next Paging Area Scope
(下次寻呼范围)"] ``` ## 五、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 计算决策链： ```mermaid 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 上下文。于是寻呼分裂为两种完全不同的机制： | 维度 | CN Paging（核心网寻呼） | RAN Paging（接入网寻呼） | |------|------------------------|--------------------------| | UE 状态 | CM-IDLE / RRC_IDLE | CM-CONNECTED / RRC_INACTIVE | | 寻呼标识 | 5G-S-TMSI | I-RNTI（Resume 用） | | 发起方 | AMF | last serving gNB | | 跨 NG-RAN | 是，按 TAI List 全网 | 否，仅在 RNA 区域内的 gNB 间（Xn） | | 走 NGAP `PAGING` | 是（非UE关联信令） | 否（RRC 内部 + Xn RAN Paging Request） | | 信令开销 | 大（全网寻呼） | 小（局部 RNA 寻呼） | | 目的 | 唤醒 UE 建立全新连接 | 恢复挂起的连接，承载快速小数据 | 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](https://www.etsi.org/deliver/etsi_ts/123500_123599/123502/18.10.00_60/ts_123502v181000p.pdf) — clause 4.2.3.2 / 4.2.3.3 Service Request procedures（含网络触发寻呼流程） 2. [3GPP TS 38.413 V18.5.0 — NG Application Protocol (NGAP)](https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3224) — 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](https://www.3gpp.org/dynareport/38304.htm) — clause 7.1 Discontinuous Reception for paging（PF/PO 与 DRX 计算） 4. [ShareTechnote — 5G/NR Paging](https://www.sharetechnote.com/html/5G/5G_Paging.html) — 寻呼机制流程图与 PO/PF 计算解读 5. [3GPP TS 29.244 V18 — Interface between SMF and UPF (N4 PFCP)](https://www.3gpp.org/dynareport/29244.htm) — Downlink Data Notification 触发寻呼的 N4 信令 6. [3glteinfo — 5G NGAP Paging Message](https://www.3glteinfo.com/messages/5g/ngap/paging/) — 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 等场景全覆盖。