5G寻呼PO/PF机制全链拆解：从NGAP PAGING到RRC Paging的跨层信令深度解析

一、为什么寻呼是5G协议栈最难讲清的一条信令

在5G（5GS）中，"寻呼"（Paging）并不是某一条协议的私有流程，而是一条横跨四层、横跨SBI/NGAP/RRC/PHY的跨层信令：业务触发在SBI（Namf_Communication_N1N2MessageTransfer），寻呼控制消息走NGAP（N2接口的PAGING），空口承载走RRC（Paging over PCCH），而UE到底在哪个无线帧的哪个时隙被唤醒，则由TS 38.304的PO/PF计算公式决定。正因为如此，做协议开发和网络排障时，"寻呼"几乎是最容易"链路某一段对了、另一段错了"的流程。

本文聚焦一个最具体的问题：当UE处于CM-IDLE/RRC_IDLE时，网络下行数据是如何一步步"敲到"UE门口的，UE又凭什么知道该在哪个PO醒来监听PDCCH。 我们将以3GPP TS 38.413第8.5.1节、TS 23.502第4.2.3.3节、TS 38.331第5.3.2节和TS 38.304第7.1节为主线，逐消息、逐IE、逐公式地拆解。

设计上，5G寻呼相比4G有三个关键增强：一是把"核心网寻呼（CN Paging）"和"接入网寻呼（RAN Paging）"拆成两条独立的触发路径（分别对应RRC_IDLE和RRC_INACTIVE）；二是引入了RRC_INACTIVE态，让UE在不释放NG/UE上下文的前提下深度睡眠，由gNB自己寻呼（I-RNTI），大幅降低信令开销；三是Rel-17引入PEI（Paging Early Indication）+ Paging Subgrouping，用DCI 2_7让大量UE"看了眼指示牌就走"，进一步省电。

二、端到端寻呼信令时序

下机启动一次寻呼的典型触发是"UE在CM-IDLE态，UPF收到下行数据但没有AN Tunnel Info"。完整信令流如下（对应TS 23.502 clause 4.2.3.3 的step 2a→3a→4b）：

sequenceDiagram
    participant UE
    participant gNB as NG-RAN (gNB)
    participant AMF
    participant SMF
    participant UPF

    Note over UPF: 收到下行数据，无AN Tunnel Info
    UPF->>SMF: 2a) PFCP Session Report Request<br/>(Data Notification, N4 Session ID, QFI, DSCP)
    SMF-->>UPF: 2b) PFCP Session Report Response
    Note over SMF: 决定Paging Policy Indicator、ARP、5QI
    SMF->>AMF: 3a) Namf_Communication_N1N2MessageTransfer<br/>(SUPI, PDU Session ID, ARP, PPI, 5QI)
    Note over AMF: UE=CM-IDLE，决定发起寻呼<br/>确定Registration Area与Paging DRX
    AMF-->>SMF: 3b) Response: "Attempting to reach UE"
    AMF->>gNB: 4b) NGAP PAGING<br/>(UE Paging Identity=5G-S-TMSI,<br/>TAI List for Paging, Paging DRX,<br/>Paging Priority, UE Radio Cap for Paging)
    Note over gNB: 对TAI List内每个cell各发一次空口page<br/>映射到PO/PF，P-RNTI加扰PDCCH
    gNB->>UE: RRC Paging (PCCH)<br/>(pagingRecordList: NG-5G-S-TMSI)
    Note over UE: 匹配自己的5G-S-TMSI<br/>trigger = mt-Access
    UE->>gNB: RRCSetupRequest (cause=mt-Access)
    UE->>AMF: NAS Service Request (5GMM)
    Note over AMF,UPF: 走Service Request后续建立N2/N3，<br/>下行数据投递

这条链路里有几个容易被忽视的细节：

1. 触发源不止是SMF。TS 23.502 clause 4.2.3.3明确，该流程可由SMSF（MT-SMS）、PCF（AM策略更新）、LMF/GMLC（定位）、NEF、UDM等触发，触发点都是Namf_Communication_N1N2MessageTransfer或Namf_MT_EnableUEReachability，AMF都汇聚成同一条NGAP PAGING。这也是为什么NGAP PAGING里没有"业务类型"字段——业务上下文留在AMF，RAN只负责把人喊出来。

2. AMF是寻呼策略的唯一仲裁者。step 3b中AMF会先回"Attempting to reach UE"，把N2 SM信息暂时丢弃；同时AMF会检查Paging Restriction Information（Multi-USIM UE可主动要求限制寻呼）、MICO模式、extended idle mode DRX等条件，决定是否真发、发几次、发到多大的范围。

3. AMF->gNB是一条PAGING、多cell寻呼。NGAP层面AMF只给gNB发一条PAGING（携带TAI List for Paging），由gNB自行在该TA下每个cell各生成一次空口page（见TS 38.413 clause 8.5.1.2："For each cell that belongs to any of the tracking areas indicated in the TAI List for Paging IE, the NG-RAN node shall generate one page on the radio interface"）。

三、NGAP PAGING消息逐IE拆解

NGAP PAGING消息定义见TS 38.413 clause 9.2.4，其关键Information Element如下表所示。这是整条链路"承载语义最重"的一条消息，因为它要把"是谁、在哪儿、多急、用什么无线能力、要不要省电"压缩进一条非UE-associated信令里。

几个设计意图值得强调。第一，PAGING是NGAP中极少数非UE-associated（UE无N2连接）的消息，因此它没有AMF UE NGAP ID/RAN UE NGAP ID，靠UE Paging Identity寻址。第二，Paging Origin的存在，使得同一条PAGING既能服务于3GPP下行数据，也能服务于"经3GPP接入把非3GPP的PDU会话拉起来"的场景（见TS 23.502 clause 4.2.3.3 step 4b关于associated access的说明）。第三，所有Optional IE的存在性都围绕一个目标：在不惊动UE的前提下，让gNB把寻呼做"精准化"——少扫几个cell、少醒几次、少占几个PO。

四、空口RRC Paging与PO/PF计算

gNB收到NGAP PAGING后，要做的事是把"5G-S-TMSI"翻译成"在哪个SFN的哪个PO发PDCCH"。这部分由TS 38.304 clause 7.1规定，参数则由SIB1的PCCH-Config提供（TS 38.331）。

4.1 SIB1中的关键参数（PCCH-Config）

4.2 PF与PO的确定公式（TS 38.304 clause 7.1）

UE_ID = 5G-S-TMSI mod 1024

PF：  (SFN + PF_offset) mod T = (T div N) × (UE_ID mod N)

PO：  i_s = floor(UE_ID / N) mod Ns

• PF（Paging Frame）：UE需要监听的系统帧号。UE_ID mod N把UE分散到N个帧组，(T div N)是帧组的步长。
• i_s（PO索引）：在PF内的第几个PO。由floor(UE_ID/N) mod Ns得到，取值0~Ns-1。

举个具体例子：设 T=64（rf64，640ms）、N=T/4=16（quarterT）、Ns=4，某UE的 5G-S-TMSI mod 1024 = 300，PF_offset=0。

• PF：(64/16) × (300 mod 16) = 4 × 12 = 48，故 SFN ≡ 48 (mod 64)，即UE在SFN=48这一帧醒来。
• PO：floor(300/16) mod 4 = 18 mod 4 = 2，即该PF内的第3个PO（0号起算）。

整个DRX周期里，UE只在"SFN=48 + i_s=2对应的时隙"这一极短窗口监听PDCCH（用P-RNTI=0xFFFE加扰），其余时间深度睡眠。这正是idle DRX省电的本质：寻呼地址 = 函数(UE_ID, 小区广播参数)，网络和UE用同一套公式各自算出"见面时间地点"，无需任何交互。

下面的流程图展示了从UE_ID到PF/PO的完整派生链路，以及PEI的"提前指示"作用：

flowchart TD
    A["5G-S-TMSI<br/>(注册时分配)"] --> B["UE_ID = 5G-S-TMSI mod 1024"]
    S["SIB1 PCCH-Config<br/>T, N, Ns, PF_offset"] --> B
    B --> C{"确定 PF<br/>(SFN + PF_offset) mod T<br/>= (T div N)(UE_ID mod N)"}
    C --> D["得到目标 SFN<br/>例: SFN=48"]
    B --> E{"确定 PO 索引 i_s<br/>= floor(UE_ID/N) mod Ns"}
    E --> F["得到 PO 例: i_s=2"]
    D --> G["该 PF 内 i_s=2 的首个<br/>PDCCH监听时机"]
    F --> G
    G --> H["用 P-RNTI=0xFFFE 监听 PDCCH"]
    H --> I{"DCI 1_0 (Paging)<br/>指示 RRC Paging?"}
    I -- 是 --> J["解码 PDSCH 上的 RRC Paging"]
    I -- 否 --> K["继续睡眠到下一个 DRX 周期"]
    PEI["PEI: DCI 2_7<br/>(Rel-17, PF之前)"] -.-> H
    PEI -. "本子组无寻呼?" .-> K
    J --> L["匹配自己的 5G-S-TMSI?<br/>触发 Service Request (mt-Access)"]

4.3 RRC Paging消息本身

RRC Paging消息（TS 38.331 clause 5.3.2）的载荷很轻，核心是pagingRecordList，每个PagingRecord含ue-Identity（CN寻呼=NG-5G-S-TMSI；RAN寻呼=I-RNTI-Value/ShortI-RNTI-Value）和可选的accessType。此外消息里还可捎带systemInfoModification、etws-Notification、cmas-Warning等"搭便车"的系统通知——这也是为什么UE即便在PO醒来发现自己不在pagingRecordList里，仍要检查这些字段（比如基站广播了地震预警）。

五、CN寻呼 vs RAN寻呼：两条路径的对比

5G把"喊人"这件事拆成两套，对应UE的两个"睡姿"。理解它们的差异，是理解5G省电与信令优化的关键。

RAN Paging是5G相对4G的标志性优化：UE在RRC_INACTIVE态下，AMF侧仍是CM-CONNECTED，所以当有下行数据时，UPF→gNB的N3隧道往往仍可达，gNB直接在自己掌控的RNA范围内用I-RNTI喊UE，UE用一条RRCResume就能把空口恢复——全程不经过AMF，不发NGAP PAGING，不重建N2/N3。这就是为什么TS 23.502 NOTE 13专门提醒：NG-RAN可能使用RRC_INACTIVE，且5G-GUTI的一部分被用于计算Paging Frame。

为了让gNB"知道怎么喊"RRC_INACTIVE的UE，AMF会通过UE CONTEXT MODIFICATION把Core Network Assistance Information for RRC INACTIVE（含配置的RNA、UE不活跃定时器建议、PEIPS子组等）和RAN Paging Priority（IE 9.3.3.15）下发给gNB，gNB据此决定何时进入RRC_INACTIVE、如何配置RNA、如何排定RAN寻呼优先级。

六、连接管理与RRC状态的对应关系

寻呼的本质是"把一个空闲/挂起的UE重新拉回连接"，因此必须把NAS层（CM状态）、RRC层（RRC状态）和寻呼类型对齐。下图给出三者的映射与各类寻呼的触发点：

stateDiagram-v2
    [*] --> RRC_IDLE : 开机/去注册
    RRC_IDLE --> RRC_CONNECTED : 初始接入/响应CN Paging
    RRC_CONNECTED --> RRC_INACTIVE : gNB决定挂起(Suspend)
    RRC_INACTIVE --> RRC_CONNECTED : RRCResume/响应RAN Paging
    RRC_CONNECTED --> RRC_IDLE : 连接释放

    state CM_layer {
        [*] --> CM_IDLE
        CM_IDLE --> CM_CONNECTED : Service Request
        CM_CONNECTED --> CM_IDLE : 去注册/释放
    }

    note right of RRC_IDLE
        CN Paging (5G-S-TMSI)
        区域 = Registration Area
        触发: AMF 经 NGAP PAGING
    end note
    note right of RRC_INACTIVE
        RAN Paging (I-RNTI)
        区域 = RNA
        触发: 最后服务 gNB
        AMF侧仍 CM-CONNECTED
    end note

七、PEI与Paging Subgrouping：Rel-17的省电增强

传统DRX周期里，同一PO上的所有UE都要醒来解码PDCCH，即使最终发现Paging里根本没有自己。在低时延/大连接场景下，这是巨大的功耗浪费。Rel-17（TS 38.331 / TS 38.213 clause 10.4A）引入了PEI（Paging Early Indication）和Paging Subgrouping：

• 网络在PF之前用一个PDCCH监听时机发送DCI format 2_7（PEI DCI），其每个比特对应一个"子组"，指示该子组在关联的PO里是否有寻呼。
• 子组可由两种方式划分：UEID-based（按UE_ID哈希，subgroupsNumForUEID）和CN-assigned（由AMF/UDM通过PEIPS Assistance Information显式分配Paging Subgroup ID，subgroupsNumPerPO）。
• 若UE发现PEI中自己的子组比特=0，则直接跳过该PO的PDCCH监听，继续睡眠。

SIB1中pei-Config、po-NumPerPEI、pei-FrameOffset等字段配置PEI。AMF侧则通过注册流程拿到UE的Paging Subgrouping Support Indication，再决定是否下发CN子组（见TS 23.502中AMF PEIPS Assistance Information相关描述）。这一机制把"为了被喊而必须醒"的人群大幅缩小，是5G面向海量物联网终端省电的关键一环。

八、抓包识别与排错实战

8.1 抓包里怎么认出这条流程

在一份完整的NG接口+空口+SBI抓包里，一次成功寻呼应能依次看到：

1. N4（PFCP）：UPF→SMF的Session Report Request，其Report Type含Downlink Data Report（旧称Data Notification），这是寻呼的"火种"。
2. SBI（HTTP/2）：SMF→AMF的POST /namf-comm/v1/ue-contexts/{supi}/n1-n2-messages，body里能看到ARP、Paging Policy Indicator、5QI。
3. NGAP（N2/SCTP）：AMF→gNB的PAGING消息（Wireshark过滤ngap.paging或过程码=2），重点看UE Paging Identity、TAI List for Paging、Paging DRX。
4. RRC/PHY：PDCCH上以P-RNTI (0xFFFE)加扰的DCI 1_0，其后PDSCH承载RRC Paging，pagingRecordList里出现该UE的NG-5G-S-TMSI。
5. UE响应：RRCSetupRequest（establishmentCause=mt-Access）→承载NAS Service Request（5GMM，message type为service request）。mt-Access这个cause值几乎就是"我是被寻呼唤起的"的盖章。

8.2 常见故障点

• 寻呼无响应：AMF的T3413超时后判寻呼失败，向SMF回N1N2 Transfer Failure Notification，SMF可触发Extended Buffering或停止下行。根因常是UE DRX配置/PO计算错位（网络与UE用了不同的N/Ns/T），或UE处在信号盲区。
• TA List过大或过小：过大→寻呼风暴（一个PAGING扇出到成百上千cell）；过小→UE跨TA移动后漏寻呼。需结合Next Paging Area Scope与RNA优化。
• 用IMSI寻呼：正常应始终用5G-S-TMSI；若抓包看到Full IMSI，说明UE尚未分配GUTI或5G-GUTI已被撤销，属异常，且存在隐私风险。
• UE不可达：MICO模式、extended idle DRX、非3GPP-only注册等情况，AMF会直接reject SMF的N1N2消息并给出Estimated Maximum Wait Time。
• Paging Restriction Information：Multi-USIM UE主动要求限制寻呼，AMF据此block paging并回"rejected due to restricted paging"。
• RRC_INACTIVE漏寻呼：RNA配置与UE实际位置不匹配，或gNB的RAN Paging定时器/优先级配置不当。

常见问题

Q1：CN寻呼和RAN寻呼最本质的区别是什么？ A：触发者与上下文保留方式。CN寻呼由AMF发起、UE处于CM-IDLE/RRC_IDLE、RAN上下文已释放、需经Service Request重建；RAN寻呼由最后服务gNB发起、UE处于CM-CONNECTED/RRC_INACTIVE、5GC与RAN上下文都保留、UE用一条RRCResume即可恢复，全程不涉及AMF。

Q2：为什么寻呼用5G-S-TMSI而不是SUPI或IMSI？ A：出于隐私与安全——S-TMSI是临时身份，不在空口暴露永久标识；同时它短，节省PCCH受限资源。只有当UE尚未被分配5G-GUTI的异常情况才会回退到Full IMSI寻呼（属可观测的安全告警点）。

Q3：PO和PF到底怎么省电？ A：网络和UE用同一套公式 PF:(SFN+PF_offset) mod T=(T div N)(UE_ID mod N)、i_s=floor(UE_ID/N) mod Ns 各自算出"见面帧与见面时隙"，UE在一个DRX周期内只在该极短PO醒来监听P-RNTI加扰的PDCCH，其余时间深度睡眠。参数越激进（N大、Ns小、T大），UE醒得越少，省电越多但寻呼时延越大。

Q4：PEI（Paging Early Indication）是Rel几引入的，解决了什么？ A：Rel-17（TS 38.331/38.213）。它用DCI 2_7在PF之前发送"子组有无寻呼"的指示，让大量落在同一PO但本次无寻呼的UE直接跳过PDCCH监听。配合Paging Subgrouping（UEID-based或CN-assigned PEIPS），显著降低海量终端的寻呼功耗。

Q5：UE响应寻呼时，NAS层发的是什么消息？ A：Service Request（5GMM消息），RRC层先发RRCSetupRequest且establishmentCause=mt-Access。这构成了"UE是被网络寻呼唤起"的完整证据链，是抓包判定寻呼是否成功的最直接依据。

参考来源

1. 3GPP TS 38.413 V18.5.0 — NGAP — clause 8.5.1 Paging流程、8.5.1.2 Successful Operation、9.2.4 PAGING消息、9.3.1.x/9.3.3.x各IE定义
2. 3GPP TS 23.502 — 5G系统流程 — clause 4.2.3.3 Network Triggered Service Request（step 2a/3a/4b即寻呼触发与执行）
3. 3GPP TS 38.331 — NR RRC — clause 5.3.2 Paging、PCCH-Config/defaultPagingCycle/nAndPagingFrameOffset/PEI-Config
4. 3GPP TS 38.304 — NR空闲态UE操作 — clause 7.1 PF/PO计算公式（本文公式与示例依据）
5. ShareTechnote - 5G NR Paging / 3glteinfo - NGAP Paging — PO/PF与NGAP PAGING消息的工程化解读

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