# 5G寻呼信令流与PO计算机制 ## 一、为什么需要寻呼：CM-IDLE 与省电的根本矛盾 5G 系统中，当一个 UE 长时间没有业务时，网络会释放其空口资源（RRC 连接）和 N2 信令连接，使其进入 **CM-IDLE**（NAS 层）+ **RRC_IDLE**（AS 层）的"双重空闲"状态。此时 AMF 上仍保留该 UE 的上下文（包括其注册区 Registration Area、5G-S-TMSI、订阅的 DRX 周期等），UPF 上也保留着 PDU Session 的 N3/N4 隧道，但 N3 隧道末端不再有可达的 gNB。 矛盾由此产生：当下行数据到达时（例如别人给 UE 打电话、发微信、推送消息），网络必须先把这个处于睡眠状态的 UE "唤醒"，重建空口连接，才能把数据送下去。**寻呼（Paging）就是这套唤醒机制的核心信令流程**，定义在 TS 23.502 Section 4.2.3.2（Network Triggered Service Request via Paging）以及 TS 23.501 Section 5.3.4（UE Reachability）中。 寻呼之所以不能"无脑全频段广播"，根本原因在于 UE 省电：处于 RRC_IDLE 的 UE 绝大部分时间在睡眠（深睡眠），只在极少数、可计算的子帧（Paging Occasion, PO）醒来监听 PDCCH。网络和 UE 必须在"何时醒"这一点上**用同一套公式严格对齐**，否则要么 UE 醒早了白耗电，要么网络在 UE 睡眠时发寻呼而漏呼。这就是本文要拆解的两条主线：**N2/空口的信令流**，以及 **gNB/UE 双方各自计算 PO 的数学机制**。 ## 二、寻呼的触发场景：不只是下行数据 很多人误以为寻呼只为"来电话/来数据"服务。实际上 TS 23.502 / TS 38.413 定义了至少五类触发： 1. **移动终止数据（MT Data）**：UPF 收到下行数据但 N3 隧道不可达（UE 在 CM-IDLE），UPF 触发 Data Notification → SMF → AMF，AMF 发起寻呼。这是最常见的场景。 2. **移动终止信令（MT Signalling）**：例如网络要下发 Configuration Update、UE Policy 或非 3GPP 接入相关信令。 3. **SMS over NAS**：下行短信通过 NAS 携带，需先把 UE 唤醒。 4. **ETWS/CMAS 告警通知**：地震海啸、商业移动告警。这类寻呼往往承载在 SI 更新指示或 RRC Paging 的 `etws-AndCmasIndication` 字段中。 5. **注册区/系统信息变更提示**：告知 UE 重新读取系统信息或发起注册更新。 > 设计意图：把"唤醒 UE"这件事统一抽象为一条 NGAP Paging + 一条 RRC Paging 的两级广播，无论上层是数据、信令还是告警，底层复用同一套寻呼信道和 PO 计算，最大化空口资源复用。 ## 三、端到端信令时序图：从 UPF 收包到 UE 起呼 下图基于 TS 23.502 Section 4.2.3.2，描绘一次完整的网络触发寻呼（mobile-terminated data 场景）： ```mermaid sequenceDiagram participant UE as UE (CM-IDLE/RRC-IDLE) participant gNB as gNB (NG-RAN) participant AMF as AMF participant SMF as SMF participant UPF as UPF Note over UPF: 下行数据到达，但N3隧道无对应gNB UPF->>SMF: ① N4 Session Report (Data Notification, DLD=1) Note over SMF: UE处于CM-IDLE，N1N2无法直接下发 SMF->>AMF: ② Namf_Communication_N1N2MessageTransfer
(PDU Session ID, QFI, ARP, Paging Policy) Note over AMF: 计算寻呼区=UE的Registration Area(TA List) AMF->>gNB: ③ NGAP PAGING (非UE相关信令)
UEPagingIdentity=5G-S-TMSI
TAIListForPaging, PagingDRX, PagingPriority Note over gNB: 用5G-S-TMSI计算PF/PO
在UE的PO上发送空口寻呼 gNB->>UE: ④ RRC Paging (PCCH/PDSCH, P-RNTI加扰DCI1_0)
pagingRecordList含NG-5G-S-TMSI Note over UE: 在自己的PO醒来,解码匹配到自己的ID UE->>gNB: ⑤ RRC Setup Request (cause=mt-Access) gNB->>AMF: ⑥ NGAP Initial UE Message (Service Request, ServiceType=mobile terminated) Note over AMF: 触发网络触发Service Request流程 AMF->>gNB: ⑦ NGAP Initial Context Setup Request (含N2 SM Info) AMF->>SMF: ⑧ Nsmf_PDUSession_UpdateSMC_Request SMF->>UPF: ⑨ N4 Session Modification (下发gNB N3 F-TEID) Note over gNB,UE: RRC Reconfiguration + Data Forwarding gNB->>AMF: ⑩ Initial Context Setup Response (含gNB N3 F-TEID) Note over UPF: N3隧道打通，下行数据送达UE ``` 关键节点说明： - **①** UPF 通过 N4 Session Report（Data Notification）告知 SMF 有下行数据且无法转发（Downlink Data Notification Flag=1）。若配置了缓冲，UPF 同时缓存数据。 - **②** SMF 调用 `Namf_Communication_N1N2MessageTransfer` 把 N2 SM 信息（含 QFI、5QI、TEID）和 N1 SM（PDU Session ID）打包交给 AMF。AMF 识别 UE 在 CM-IDLE，于是发起寻呼而非直接走 N2 下发。 - **③** AMF 向 UE 注册区内所有 TA 涉及的 gNB 发送 NGAP PAGING。这是**非 UE 相关信令**（不依赖已有 UE 上下文），沿 NG-C 接口广播。 - **④** gNB 在计算出的 PO 上，用 P-RNTI 加扰 DCI 1_0，PDSCH 承载 RRC Paging 消息，里面 `pagingRecordList` 含一条 `NG-5G-S-TMSI` + `accessType`。 - **⑤~⑩** UE 命中后发起随机接入与 Service Request，重建 N2/N3，最终下行数据经 N3 送达。 ## 四、NGAP PAGING 消息：IE 结构与逐字段拆解 NGAP PAGING 消息定义在 TS 38.413 Section 9.x，是一条**纯 Initiating Message**（无应答、无关联的响应）。其 IE 容器结构如下： ```mermaid flowchart LR A["NGAP PAGING
(procedureCode = id-Paging)"] --> B["UEPagingIdentity (M)"] A --> C["TAIListForPaging (M)"] A --> D["PagingPriority (O)"] A --> E["PagingDRX (O)"] A --> F["PagingeDRXInformation (O)"] A --> G["UEAssistanceInformationForPaging (O)"] A --> H["PagingCause (O, R16)"] A --> I["NR Paging Subgroup ID (O, R16)"] A --> J["AssistanceDataForPaging (O, R17: 含推荐小区/子组/PEI)"] A --> K["OriginatingNodeInformation (O)"] B --> B1["5G-S-TMSI / Full I-RNTI"] G --> G1["UE Identity Index Value
Recommended Cells
Time Stayed in Cell"] ``` 下表汇总核心 IE 的取值与作用（依据 TS 38.413 Rel-18）： | IE 名称 | 必备性 | 取值 / 结构 | 作用说明 | |---------|--------|------------|---------| | UEPagingIdentity | M | CHOICE: 5G-S-TMSI / Full I-RNTI | 标识被呼 UE。CM-IDLE 用 48bit 5G-S-TMSI；RRC_INACTIVE 的 RAN 寻呼用 Full I-RNTI | | TAIListForPaging | M | List of TAI（PLMN+TAC） | 限定寻呼广播范围，gNB 只在该 TAI 覆盖的小区发空口寻呼 | | PagingPriority | O | 0..7（数值越大越优先） | 携带 ARP / MPS 优先级，gNB 据此决定是否抢占低优先级寻呼资源 | | PagingDRX | O | s32 / s64 / s128 / s256（无线帧） | UE 特定 DRX 周期，覆盖默认 DRX；UE 实际用 min(默认, 特定) | | PagingeDRXInformation | O | eDRX 周期（最高可达 ~10.24s） | 物联网/低频唤醒场景的扩展 DRX，进一步省电 | | PagingCause | O (R16) | traffic / signalling / voice / sms / high priority | 让 gNB 按业务类型差异化调度寻呼（如语音降低延迟） | | NR Paging Subgroup ID | O (R16) | 整数 | 寻呼子组，UE 只需在自己子组的 PO 醒来，降低碰撞与功耗 | | UEAssistanceInformationForPaging | O | 推荐小区、驻留时长、UE Identity Index Value | gNB 据此缩小 PO 计算与波束发送范围，提升寻呼效率 | > 设计意图（双标识体系）：5G-S-TMSI 用于**核心网寻呼**（CM-IDLE），Full I-RNTI 用于**RAN 级寻呼**（RRC_INACTIVE，TS 38.413 / TS 38.300）。后者由 gNB 直接发起（不经过 AMF），用于把短暂挂起的 INACTIVE UE 拉回 CONNECTED，避免重复走完整注册区广播。这是 5G 相对 LTE 在连接态管理上的关键增强。 ## 五、PO/PF 计算机制：网络与 UE 的数学握手 这是整条寻呼链路中最"硬核"的部分，定义在 **TS 38.304 Section 7.1**。其本质是用 UE 的 5G-S-TMSI 推导出一个确定性的"指纹"，让网络和 UE **在没有任何协商**的情况下，算出同一个 (PF, PO)。 ### 5.1 关键参数（来自 SIB1 `pcch-Config` / NAS） | 参数 | 含义 | 取值来源 | |------|------|---------| | T | UE 实际 DRX 周期（无线帧） | min(默认 DRX, UE 特定 DRX)；默认 DRX 在 SIB1 广播，特定 DRX 由 NAS 信令下发 | | nB | 每个 DRX 周期内寻呼时机的密度 | SIB1 广播，取值 T/4、T/2、T、2T、4T | | N | 一个 DRX 周期内的 PF 数量 | N = min(T, nB) | | Ns | 每个 PF 内的 PO 数量 | Ns = max(1, nB/T) | | UE_ID | UE 寻呼标识指纹 | UE_ID = 5G-S-TMSI mod 1024 | ### 5.2 两条核心公式 ``` PF（系统帧号）: SFN mod T = (T div N) * (UE_ID mod N) PO 索引 i_s : i_s = floor(UE_ID / N) mod Ns ``` - 第一式确定**在哪个系统帧（System Frame Number）发寻呼**； - 第二式确定**在该帧内第几个 PO 发寻呼**； - `i_s` 再通过 SIB1 中的 `firstPDCCH-MonitoringOccasionOfPO` 映射到具体的 PDCCH 监听时机。 由于 UE_ID 完全由 5G-S-TMSI 决定，而 5G-S-TMSI 是 AMF 分配给 UE 的唯一临时标识，网络（gNB）和 UE 拿着同一个 5G-S-TMSI，代入同一组 T/nB，必然算出同一个 (PF, PO)。**这就是寻呼能"精准命中"而无需额外握手的原因。** ```mermaid flowchart TD Start["5G-S-TMSI (48bit)"] --> A["UE_ID = 5G-S-TMSI mod 1024"] SIB["SIB1: T, nB"] --> B["N = min(T,nB) ; Ns = max(1,nB/T)"] A --> C1["PF: SFN mod T = (T div N)*(UE_ID mod N)"] B --> C1 A --> C2["i_s = floor(UE_ID/N) mod Ns"] B --> C2 C1 --> D["确定系统帧 PF"] C2 --> E["确定 PF 内第 i_s 个 PO"] D --> F["在 PF 的 PO 上: gNB 发 P-RNTI DCI1_0"] E --> F F --> G{PDSCH 中含
本UE的NG-5G-S-TMSI?} G -->|是| H["UE 响应: 发起 Service Request"] G -->|否| I["UE 继续睡眠到下一DRX周期"] ``` ### 5.3 PO 的物理层结构 在 NR 中，一个 **PO = 一组 PDCCH 监听时机（PMO）**，长度通常等于一个 SSB 波束扫描周期。也就是说，gNB 会在同一 PO 内、按每个 SSB 波束依次重复发送同一条 Paging 消息，确保 UE 无论驻留在哪个波束都能收到。协议（TS 38.304 / 38.213）规定一个 PO 最多可承载的寻呼 UE 数量受限于 DCI 与 PDSCH 容量，高负荷小区会出现"一个 PO 装不下、UE 排到下一 PF"的现象。 ## 六、省电与负荷优化：PEI 与寻呼子组 随着 5G 终端规模和物联网连接数爆炸，寻呼信道（PCH）本身成了瓶颈。R16/R17 引入了两项关键增强： **1. 寻呼子组（Paging Subgroup, R16）**：AMF 把 UE 划入若干子组（NR Paging Subgroup ID），gNB 只在该子组对应的 PO 子集上发送子组指示；UE 只需在自己子组的 PO 醒来，把平均唤醒次数再降低一个量级。对应 NGAP 的 `NR Paging Subgroup ID` IE。 **2. PEI（Paging Early Indication, R17）**：在真正的 PO 之前，用一个极轻量的 DCI 比特组（基于 DCI 2_5，PEI-RNTI 加扰）提前告诉 UE："这个 PO 里有没有属于你子组的寻呼 / 推荐波束上有没有你的寻呼"。UE 若发现"没有"，连 PDSCH 都不解码就回去睡，显著降低功耗。对应 R17 `AssistanceDataForPaging` 中携带的 PEI 辅助信息。 ## 七、两种寻呼的对比：CN Paging vs RAN Paging 下表对比 CM-IDLE 的核心网寻呼与 RRC_INACTIVE 的 RAN 级寻呼，这是排错时最容易混淆的两条路径： | 维度 | CN Paging（核心网寻呼） | RAN Paging（RAN 级寻呼） | |------|----------------------|------------------------| | UE 状态 | CM-IDLE + RRC-IDLE | CM-CONNECTED + RRC-INACTIVE | | 发起方 | AMF | gNB（基于 RNA/源 gNB） | | 信令消息 | NGAP PAGING（TS 38.413） | XnAP RAN Paging（TS 38.423）+ RRC Paging | | UE 标识 | 5G-S-TMSI | Full I-RNTI（含 gNB ID） | | 寻呼范围 | Registration Area（TA List） | RNA（RAN-based Notification Area） | | 触发后结果 | 完整 Service Request + N2/N3 重建 | 直接 RRC Resume，N2/N3 通常保持 | | 设计目标 | 唤醒完全睡眠的 UE | 低时延拉回挂起态 UE，省去全流程重建 | ## 八、抓包识别与排错实战 **如何用 Wireshark/tshark 识别一条寻呼链路**： - N4：`pfcp.session_report_request` 中带 `downlink_data_notification` 标志； - SBI：HTTP/2 POST `/namf-comm/v1/ue-contexts/{supti}/n1-n2-messages`（N1N2MessageTransfer）； - N2（NGAP）：`ngap.paging`，过滤 `ngap.procedureCode == 17`，展开看 `UEPagingIdentity`、`TAIListForPaging`； - 空口（RRC）：`rrc.paging`（PCCH），检查 `pagingRecordList` 是否含目标 NG-5G-S-TMSI，以及 `systemInfoModification` / `etws-AndCmasIndication` 标志。 **常见故障点**： 1. **寻呼区计算错误**：AMF 缓存的 TA List 与 UE 实际驻留小区不一致（多见于跨 TA 移动但未及时注册更新），导致在错误小区广播，UE 收不到。排错：核对 AMF 上 UE 的 `TaiList` 与 UE 上报的 `RegistrationArea`。 2. **DRX 周期不匹配**：gNB 与 UE 算出不同 PO。典型原因是 UE 特定 DRX（NAS 下发）与默认 DRX（SIB1）取 min 规则实现不一致。排错：确认 `PagingDRX` IE 是否被 gNB 正确用于 PO 计算。 3. **PO 负荷过载漏呼**：高负荷小区一个 PO 容纳不下所有 UE，被挤掉的 UE 在本周期漏呼，只能等下一 DRX 周期。表现：寻呼时延抖动大。缓解：开启 Paging Subgroup、扩容 nB。 4. **5G-S-TMSI 解析错误**：UE_ID = 5G-S-TMSI mod 1024 计算时字节序/位数取错（必须取 48bit），导致 PF 完全算错。这是协议开发中最常见的 bug。 5. **RAN/CN 寻呼用错标识**：对 INACTIVE UE 用了 5G-S-TMSI 走 CN 寻呼，导致不必要的 N2/N3 重建，时延增加。 ## 九、常见问题 **Q1: UE 如何知道该用默认 DRX 还是 UE 特定 DRX？** A: UE 同时持有两个值——默认 DRX 来自 SIB1 广播，UE 特定 DRX 由 AMF 通过 NAS（注册接受/UE 配置更新）下发。实际 T 取两者中**较短**的一个，并由 UE 和 gNB 各自独立计算，无需空口协商（见 TS 38.304 7.1）。 **Q2: 一个 PO 最多能寻呼多少个 UE？** A: 受限于 PDCCH/PDSCH 容量与高层 Paging Record 数。TS 38.331/38.304 没有给固定上限，工程上一个 PO 通常承载几十个 UE；超出的 UE 会被排到下一 PF 或下一 DRX 周期，正是高负荷小区漏呼的根因。 **Q3: RAN Paging 和 CN Paging 会同时发生吗？** A: 不会。UE 在任一时刻只处于（CM-IDLE+RRC-IDLE）或（CM-CONNECTED+RRC-INACTIVE）之一。前者用 CN Paging（5G-S-TMSI），后者用 RAN Paging（Full I-RNTI），二者互斥。AMF/gNB 根据保存的 RRC 状态决定走哪条路径。 **Q4: 为什么不用 IMSI 直接做寻呼标识？** A: 出于隐私与安全。IMSI 是永久身份，明文广播会暴露用户身份并招致追踪攻击。5G 用临时标识 5G-S-TMSI，且在 R17 之前进一步通过 SUCI 机制保护注册阶段，寻呼阶段则用临时标识轮换降低关联风险。 **Q5: eDRX 把唤醒周期拉到 10 秒级，会不会导致漏接电话？** A: 会有时延代价。eDRX（最高约 10.24s）以"用更晚的唤醒换取省电"为代价，主要用于物联网低频小数据。对时延敏感业务（语音），网络应通过 ARP / `PagingCause=voice` / `PagingPriority` 强制高优先级寻呼，并避免对该 UE 协商过长 eDRX。 ## 参考来源 1. [3GPP TS 23.502 V18.x — Section 4.2.3.2 Network Triggered Service Request (with Paging)](https://www.3gpp.org/dynareport/23502.htm) — 寻呼触发的端到端服务请求流程定义 2. [3GPP TS 38.413 V18.x — NGAP, Section 8.x Paging / Section 9.2.x Paging message IEs](https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3223) — NGAP PAGING 消息与 IE 字段定义 3. [3GPP TS 38.304 V18.x — Section 7.1 RRC_IDLE paging (PF/PO calculation, DRX)](https://www.3gpp.org/dynareport/38304.htm) — PO/PF 计算公式与 DRX 参数 4. [3GPP TS 38.331 V18.x — Section 5.2.2 Paging (RRC)](https://www.3gpp.org/dynareport/38331.htm) — 空口 RRC Paging 消息与 PCCH 承载 5. [free5GC — Paging in 5G Network](https://free5fc.org/blog/20241204/20241204/) — 开源 5GC 实现视角的寻呼流程与 AMF 重试寻呼区机制 6. [3glteinfo — 5G Paging Procedure Call Flow](https://www.3glteinfo.com/call-flows/5g-paging-procedure/) — 寻呼可达性、标识与响应分支实战解读 7. [知乎 — 5G 寻呼 paging 总结](https://zhuanlan.zhihu.com/p/578559945) — 中文视角的 SA 寻呼端到端协调配合分析 --- > 本文由「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 等场景全覆盖。