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 场景）：

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<br/>(PDU Session ID, QFI, ARP, Paging Policy)
    Note over AMF: 计算寻呼区=UE的Registration Area(TA List)
    AMF->>gNB: ③ NGAP PAGING (非UE相关信令)<br/>UEPagingIdentity=5G-S-TMSI<br/>TAIListForPaging, PagingDRX, PagingPriority
    Note over gNB: 用5G-S-TMSI计算PF/PO<br/>在UE的PO上发送空口寻呼
    gNB->>UE: ④ RRC Paging (PCCH/PDSCH, P-RNTI加扰DCI1_0)<br/>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 容器结构如下：

flowchart LR
    A["NGAP PAGING<br/>(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<br/>Recommended Cells<br/>Time Stayed in Cell"]

下表汇总核心 IE 的取值与作用（依据 TS 38.413 Rel-18）：

设计意图（双标识体系）：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）

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)。这就是寻呼能"精准命中"而无需额外握手的原因。

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 中含<br/>本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 级寻呼，这是排错时最容易混淆的两条路径：

八、抓包识别与排错实战

如何用 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) — 寻呼触发的端到端服务请求流程定义
2. 3GPP TS 38.413 V18.x — NGAP, Section 8.x Paging / Section 9.2.x Paging message IEs — NGAP PAGING 消息与 IE 字段定义
3. 3GPP TS 38.304 V18.x — Section 7.1 RRC_IDLE paging (PF/PO calculation, DRX) — PO/PF 计算公式与 DRX 参数
4. 3GPP TS 38.331 V18.x — Section 5.2.2 Paging (RRC) — 空口 RRC Paging 消息与 PCCH 承载
5. free5GC — Paging in 5G Network — 开源 5GC 实现视角的寻呼流程与 AMF 重试寻呼区机制
6. 3glteinfo — 5G Paging Procedure Call Flow — 寻呼可达性、标识与响应分支实战解读
7. 知乎 — 5G 寻呼 paging 总结 — 中文视角的 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 等场景全覆盖。