首页 › core-network › 5G寻呼机制全链拆解

5G寻呼机制全链拆解:从下行数据到RRC Paging的策略差异化与节能增强

本文聚焦 3GPP TS 23.502 §4.2.3.3「Network Triggered Service Request」中的寻呼触发链路,结合 TS 23.501 §5.4.3.2(PPD)、§5.38.3(语音寻呼原因)、§5.31.7(eDRX)、TS 38.413(NGAP Paging)与 TS 38.331(RRC Paging)的 IE 定义,逐层拆解一次完整的 5G 寻呼是如何从核心网下行数据一路穿透到 UE 的。

一、为什么 5G 寻呼值得单独深拆

很多工程师把寻呼(Paging)当作"一条 NGAP 消息 + 一条 RRC 消息"的简单流程,但实际上 5G 寻呼是一个跨越 7 个网元、3 层协议栈、且与 QoS/切片/IMS/节能深度耦合的端到端机制。它的复杂性集中在三件事上:

  1. 谁触发、用什么身份寻:CM-IDLE 态用 5G-S-TMSI 做核心网寻呼(CN Paging),CM-CONNECTED + RRC_INACTIVE 态用 fullI-RNTI 做无线网寻呼(RAN Paging),两者身份、触发节点、覆盖范围完全不同。
  2. 寻呼策略如何差异化:IMS 语音包和普通 TCP ACK 包进入同一个 UE 时,SMF 需要根据 IP 包头里的 DSCP 反推出 Paging Policy Indicator(PPI),让 gNB 把语音寻呼调度得更优先。
  3. 节能与可达性如何权衡:eDRX 周期可达 44 分钟以上,AMF 必须在 Paging Time Window(PTW)内完成至少一次寻呼,否则 MT 业务将彻底"够不到"UE。

下面按真实数据流向,自上而下拆解整条链路。

二、端到端寻呼时序:下行数据如何唤醒 UE

当 UE 处于 CM-IDLE、没有任何 N3 用户面隧道时,任何来自数据网(DN)的下行数据都会触发下面的完整链路:

sequenceDiagram
    autonumber
    participant DN as 数据网(DN)
    participant UPF as UPF
    participant SMF as SMF
    participant AMF as AMF
    participant gNB as NG-RAN(gNB)
    participant UE as UE(CM-IDLE)

    DN->>UPF: 下行数据包(无N3隧道, DSCP标记)
    Note over UPF: 缓存下行包(Extended Buffering可选)
    UPF->>SMF: PFCP Session Report(Data Notification,<br/>QFI, DSCP, N4会话ID)
    SMF->>SMF: 根据DSCP推演PPI (TS 23.501 §5.4.3.2)
    SMF->>AMF: Namf_Communication_N1N2MessageTransfer<br/>(SUPI, PDU Session ID, ARP, PPI, 5QI,<br/>N2 SM Info, Extended Buffering)
    AMF-->>SMF: 响应 cause="Attempting to reach UE"<br/>(携带的N2 SM Info暂存/丢弃)
    Note over AMF: 依据PPI/ARP映射出NGAP PagingPriority
    AMF->>gNB: NGAP Paging(UE Paging Identity=5G-S-TMSI,<br/>TAIs for Paging, PagingPriority, Paging DRX)
    gNB->>gNB: 按PO/PF计算寻呼时机,<br/>映射PagingOrigin
    gNB->>UE: RRC Paging(PCCH,pagingRecordList:<br/>ue-Identity=ng-5G-S-TMSI, accessType)
    UE->>UE: 匹配5G-S-TMSI, 触发Service Request
    UE->>gNB: RRC Setup Request
    gNB->>AMF: Initial UE Message(Service Request)
    Note over AMF,SMF: 建立N3隧道, 激活用户面
    AMF-->>SMF: 通知用户面已激活
    SMF-->>UPF: 放行缓存的下行数据
    UPF->>UE: 下行数据送达

这条时序里有两个容易被忽视的关键设计:第 4 步 PFCP 上报必须携带 DSCP,以及第 6 步 AMF 的即时响应。后者意味着 SMF 一旦收到 "Attempting to reach UE" 就必须停止重复发送 Data Notification,转而等待——否则会引发 AMF 的"重复/低优先级请求拒绝"逻辑(详见第六节排错)。

三、逐层 IE 解析:消息里到底装了什么

3.1 SMF→AMF:Namf_Communication_N1N2MessageTransfer

这是寻呼真正的"触发源"。TS 23.502 §4.2.3.3 步骤 3a 明确规定了该服务操作(TS 29.518 定义)携带的完整字段:

字段 含义 与寻呼的关系
SUPI / PDU Session ID 定位 UE 与会话 AMF 据 SUPI 查本地 UE 上下文取 5G-S-TMSI
ARP Allocation & Retention Priority AMF 用于判断资源抢占优先级
Paging Policy Indicator (PPI) 寻呼策略指示 由 SMF 据 DSCP 推导,决定寻呼差异化
5QI 5G QoS Identifier 辅助 gNB 理解业务特性
N2 SM Information QFI、QoS Profile、CN N3 Tunnel 寻呼成功后用于建隧道(CM-IDLE 态先缓存/丢弃)
Area of validity for N2 SM Information N2 SM 信息有效区 越区失效后需重新下发
Extended Buffering support 扩展缓存指示 IoT 场景下允许 UPF 长时间缓存
N1N2TransferFailure Notification Target Address 失败回调地址 寻呼彻底失败时回调 SMF

需要特别强调:SMF 不得同时携带 N1 SM Container 与 N2 SM Information,除非 N1 容器与 N2 信息相关联——这条约束来自 TS 23.502 步骤 3a 的硬性规定,目的是避免 AMF 在寻呼尚未成功时就错乱地处理两条信息。

3.2 AMF→gNB:NGAP Paging 消息结构

NGAP Paging 由 TS 38.413 定义,其 IE 组来源于规范第 9.3 节。下面这张图展示了 NGAP Paging 的 IE 组装逻辑:

flowchart TB
    NP["NGAP Paging 消息"]
    NP --> UPI["UE Paging Identity<br/>(9.3.3.18)<br/>= 5G-S-TMSI (9.3.3.20) 或 Full I-RNTI"]
    NP --> TFP["TAIs for Paging<br/>Tracking Area Identity 列表"]
    NP --> PRIO["Paging Priority<br/>(9.3.1.78)<br/>prioLevel0~7"]
    NP --> PDRX["Paging DRX<br/>(9.3.1.90)"]
    NP --> PO["Paging Origin<br/>(9.3.3.22)<br/>cn / ran / via-ran"]
    NP --> URC["UE Radio Capability for Paging"]
    NP --> AD["Assistance Data for Recommended Cells<br/>(9.3.1.70) +<br/>Recommended Cells for Paging (9.3.1.71)"]
    NP --> IRN["Information on Recommended<br/>Cells and RAN node list (9.3.1.100)"]
    NP --> PEI["Paging eDRX Information"]

    style NP fill:#2d6a4f,color:#fff

关键 IE 详解:

NGAP IE 规范节号 作用 设计意图
UE Paging Identity 9.3.3.18 携带 5G-S-TMSI(CM-IDLE)或 Full I-RNTI(RRC_INACTIVE) 5G-S-TMSI = AMF Set ID + AMF Pointer + 5G-TMSI,既隐藏 SUPI 又能全局寻址
TAIs for Paging — 一组 Tracking Area Identity AMF 只向 UE 注册区所属 TA 的 gNB 发寻呼,而非全网广播,省无线资源
Paging Priority 9.3.1.78 prioLevel0(最高)~ prioLevel7 由 PPI/ARP 映射而来,决定 gNB 在 PCCH 上的调度优先级
Paging Origin 9.3.3.22 cn / ran / via-ran 区分是核心网发起还是无线网发起,影响是否触发 RAN 寻呼收敛
Paging DRX 9.3.1.90 寻呼非连续接收周期 gNB 据此与 UE 协商一致的 DRX 周期
Recommended Cells 9.3.1.70/71/100 上次驻留小区推荐 减少 UE 需要监听的小区数,省电

3.3 gNB→UE:RRC Paging(TS 38.331)

RRC 层 Paging 走 PCCH 逻辑信道、TM 模式,ASN.1 结构(TS 38.331 第 11 章)如下:

Paging ::= SEQUENCE {
    pagingRecordList          PagingRecordList,    -- Need N
    lateNonCriticalExtension  OCTET STRING OPTIONAL,
    nonCriticalExtension      SEQUENCE {} OPTIONAL
}
PagingRecord ::= SEQUENCE {
    ue-Identity   PagingIdentity,    -- ng-5G-S-TMSI 或 fullI-RNTI
    accessType    ENUMERATED {nr, eutra, ...} OPTIONAL
}

R17 在 Paging-v1700-IEs 中新增了 pagingGroupList-r17,用于支持 Paging Early Indication(PEI):UE 可以在解码 PagingRecord 之前,先读一个短指示位,判断当前 PO 是否真的有本组的寻呼,没有就直接关机收发——这是 R17 给 RedCap 与海量 IoT 设备的关键省电特性。

UE 侧匹配逻辑(TS 38.331 第 5.2.2 节)很简洁: - 若 ue-Identity 匹配本 UE 上层分配的 5G-S-TMSI → 视为核心网寻呼,触发 Service Request; - 若匹配本 UE 存储的 fullI-RNTI → 视为无线网寻呼,触发 RRC Resume; - 否则忽略。

四、CN 寻呼 vs RAN 寻呼:两套寻呼身份的分流

5G 把"寻呼"一分为二,这是相对 4G 最本质的变化。下图刻画 UE 在三态之间的迁移与对应寻呼机制:

stateDiagram-v2
    [*] --> RM_DEREG
    RM_DEREG --> CM_IDLE : 注册成功
    CM_IDLE --> CM_CONN : UE发起Service Request
    CM_CONN --> RRC_INACTIVE : gNB挂起(N2 UE Context Suspend)
    RRC_INACTIVE --> CM_CONN : RRCResume(RAN Paging)
    CM_CONN --> CM_IDLE : N2 Release
    RRC_INACTIVE --> CM_IDLE : RAN寻呼超时/周期更新失败

    note right of CM_IDLE
      CN Paging: 身份=5G-S-TMSI
      发起节点=AMF, 范围=TA List
    end note
    note right of RRC_INACTIVE
      RAN Paging: 身份=fullI-RNTI
      发起节点=gNB, 范围=RNA(RAN Notification Area)
    end note
维度 CN Paging(核心网寻呼) RAN Paging(无线网寻呼)
触发态 CM-IDLE CM-CONNECTED + RRC_INACTIVE
寻呼身份 5G-S-TMSI fullI-RNTI
发起节点 AMF gNB
覆盖范围 UE 注册区(TA List) RNA(RAN Notification Area,通常更小)
恢复过程 完整 Service Request(含认证/上下文建立) RRC Resume(信令开销极小)
计费/隧道 需重建 N3 隧道 N3 隧道仍挂在锚点 gNB,快速恢复
设计目标 找回"彻底离线"的 UE 在小范围内快速唤醒、省信令

设计意图:RRC_INACTIVE 态让 UE 保持 RRC 连接上下文与 N3 隧道,只在无线侧"假睡",从而让小数据、周期性上报类业务用极小代价被唤醒。AMF 通过 RRC Inactive Assistance Information(TS 23.501 §5.3.3.2.5)把 RNA 范围、DRX 周期、eDRX 值下发给 gNB,实现 CN 与 RAN 两套寻呼参数的协同。

五、策略差异化深度:PPI 到底怎么发挥作用

PPD(Paging Policy Differentiation,TS 23.501 §5.4.3.2)是 5G 寻呼最有"工程味"的机制,专为 IMS 语音而生。其完整逻辑链:

  1. 应用层打标:P-CSCF 在向 UE 发送 IMS 语音相关 IP 包时,把 DSCP 值设为特定值(如会话语音)。
  2. UPF 上报 DSCP:当 UPF 触发 Data Notification 给 SMF 时,把下行 IP 包头的 DSCP(TOS/TC)连同 QFI 一起上报(TS 23.501 §5.4.3.2 第 5 段)。
  3. SMF 推导 PPI:SMF 按"运营商配置的 DSCP→PPI 映射表",把 DSCP 翻译成 PPI,并在 Namf_Communication_N1N2MessageTransfer 中下发给 AMF。
  4. AMF 映射 PagingPriority:AMF 据 PPI 把优先级映射成 NGAP 的 Paging Priority(prioLevel0~7)。
  5. gNB 调度:gNB 在 PCCH 上据此优先级调度寻呼,高优先级 UE(语音)被更早、更可靠地寻呼到。

与语音寻呼原因(Paging Cause Indication for Voice Service,TS 23.501 §5.38.3)联动:仅当 UE 在注册时声明支持该特性,AMF 才会在 Paging 消息中携带 Voice Service Indication,UE 收到后可直接以"语音"为原因发起高优先级接入(如走高优先级 RACH)。网络判断"是否语音"的依据,正是上面推导出的 PPI。这条链印证了规范 NOTE 3/4 的告诫:DSCP→PPI 的触发信息必须在 5GS 内部全程不被篡改,否则会导致错误的寻呼策略被意外触发。

六、抓包识别与常见故障

6.1 抓包如何认出一次寻呼

接口 协议 过滤条件 关键判据
N4 (SMF↔UPF) PFCP pfcp.msg_type == 39(Session Report Request) 检查是否含 Data Notification + DSCP
SBI (SMF→AMF) HTTP/JSON POST /namf-comm/v1/ue-contexts/{supi}/n1-n2-messages body 含 pduSessionId、ppi、arp
N2 (AMF↔gNB) NGAP ngap.procedureCode == 1(Paging) 解码 UEPagingIdentity、TAIListForPaging、PagingPriority
Uu (gNB↔UE) RRC rrc.nrPaging pagingRecordList[].ue-Identity 与 UE 的 5G-S-TMSI 比对

实战技巧:用 tshark 时把 N4 与 N2 联动看——若 N4 有 Data Notification 但 N2 没有 Paging,问题大概率在 SMF→AMF 的 SBI;若 N2 有 Paging 但 Uu 无 RRC Paging,则查 gNB 的 PO/PF 计算或 DRX 配置。

6.2 高频故障与排错

现象 可能根因 排查方向
UE 收不到寻呼,长期不可达 UE 协商了长 eDRX,AMF 未在 PTW 内寻呼 核对 AMF 是否强制"PTW 内至少一次寻呼"(TS 23.501 §5.31.7.x)
SMF 反复收到 "Attempting to reach UE" 后请求被拒 AMF 的低/同优先级请求拒绝逻辑 检查是否多会话并发下行,PPI 相同导致互相挤兑
寻呼发出但 UE 不响应 5G-S-TMSI 推导的 PO 计算错误 核对 UE_ID = 5G-S-TMSI mod 1024、DRX 周期 T、nB 参数
语音呼叫接续慢 PPI 未正确映射 / DSCP 被中间设备改写 抓 N4 看上报 DSCP,查运营商 DSCP→PPI 映射表
漫游场景寻呼失败 HR 漫游下 PPD 配置缺失 TS 23.501 §5.4.3.2 NOTE 2:需运营商间协议约定 DSCP 值
携带 N1+N2 但行为异常 SMF 违规同时下发 校验 SMF 是否遵守"N1/N2 不同时下发"约束
## 七、状态机与可达性闭环

把以上机制合到一张图,可以看到 AMF 如何在"可达性"与"省电"之间闭环:

flowchart TD
    DL["下行数据到达"] --> Q1{UE状态?}
    Q1 -->|CM-CONNECTED<br/>RRC_CONNECTED| DUP["直接转发,无需寻呼"]
    Q1 -->|RRC_INACTIVE| RAN["gNB用fullI-RNTI<br/>RAN Paging"]
    Q1 -->|CM-IDLE| Q2{可达性窗口?}
    Q2 -->|在PTW/DRX ON| CN["AMF用5G-S-TMSI<br/>CN Paging"]
    Q2 -->|eDRX休眠期| BUF["Extended Buffering<br/>等待下一个PTW"]
    RAN --> Q3{响应?}
    CN --> Q3
    Q3 -->|是| SR["Service Request<br/>建隧道"]
    Q3 -->|否| RT["按策略重发/<br/>升级PagingPriority"]
    RT --> CN

这张图揭示了一个核心约束:AMF 永远不能"无脑广播"。每一次寻呼都受可达性窗口(DRX/eDRX/PTW)、优先级(PPI→PagingPriority)、限制信息(Paging Restriction)三重门控。

八、常见问题

Q1: CN 寻呼和 RAN 寻呼能不能同时对一个 UE 发生? A: 不应同时。当 UE 处于 CM-CONNECTED + RRC_INACTIVE 时,下行数据应触发 gNB 的 RAN Paging(用 fullI-RNTI);只有当 RAN 寻呼失败或 UE 已转 CM-IDLE,才退化为 AMF 的 CN Paging(用 5G-S-TMSI)。两者的寻呼身份互斥,避免 UE 重复响应。

Q2: 5G-S-TMSI 比 4G 的 S-TMSI 多了什么? A: 5G-S-TMSI 显式编码了 AMF Set ID + AMF Pointer(共 10 比特)加上 5G-TMSI(32 比特)。这让任何 gNB 都能从寻呼身份里直接知道 UE 属于哪个 AMF Set,是 5G 控制面池化(AMF Set)的关键寻址基础。

Q3: PPI 和 ARP 是一回事吗? A: 不是。ARP(Allocation & Retention Priority)描述承载/会话的分配与抢占优先级,面向资源管理;PPI(Paging Policy Indicator)专门描述"这个下行包该用什么寻呼策略",由 DSCP 推导,面向寻呼调度。二者都出现在 N1N2MessageTransfer 里,但含义和用途独立。

Q4: 为什么 UE 在 eDRX 下可能"完全失联"? A: eDRX 周期最长可达 44 分钟以上(NB-IoT 更长)。若 AMF 未在该 UE 的 Paging Time Window(PTW)内发起寻呼,下行 MT 业务将错过整个可达窗口。因此 TS 23.501 §5.31.7 规定 AMF 必须保证"至少在 PTW 内寻呼一次",这是 eDRX 业务可用性的硬约束。

Q5: 抓包时 N2 看到了 PagingPriority,但 RRC Paging 里没有优先级字段,怎么回事? A: 正常现象。NGAP 的 Paging Priority 是给 gNB 内部用于 PCCH 调度的指示,并不一定透传到 RRC Paging 消息。NR RRC 的 Paging 消息本身只携带 ue-Identity、accessType 等字段;优先级差异通过 gNB 把高优先级 UE 的寻呼调度到更早的 PO、或采用更可靠的传输机会来实现。

参考来源

  1. 3GPP TS 23.501 V18.x — System architecture for the 5G System — §5.4.3.2 Paging Policy Differentiation、§5.31.7 eDRX、§5.38.1 Paging Restriction、§5.38.3 Paging Cause Indication for Voice Service
  2. 3GPP TS 23.502 V18.x — Procedures for the 5G System — §4.2.3.3 Network Triggered Service Request、§5.2.2.2.7 Namf_Communication_N1N2MessageTransfer
  3. 3GPP TS 38.413 V18.x — NGAP — §9.3.1.70/71/78/90/100、§9.3.3.18/20/22 IE 定义;Paging 基本过程
  4. 3GPP TS 38.331 V18.x — NR RRC — 第 11 章 Paging 消息 ASN.1、第 5.2.2 节 Paging 接收
  5. TS 29.518 V18.x — AMF Services — Namf_Communication_N1N2MessageTransfer 服务操作定义;free5GC《Paging in 5G Network》博客作为开源实现对照

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

51学通信知识星球海报-扫码加入