本文聚焦 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 的。
很多工程师把寻呼(Paging)当作"一条 NGAP 消息 + 一条 RRC 消息"的简单流程,但实际上 5G 寻呼是一个跨越 7 个网元、3 层协议栈、且与 QoS/切片/IMS/节能深度耦合的端到端机制。它的复杂性集中在三件事上:
5G-S-TMSI 做核心网寻呼(CN Paging),CM-CONNECTED + RRC_INACTIVE 态用 fullI-RNTI 做无线网寻呼(RAN Paging),两者身份、触发节点、覆盖范围完全不同。下面按真实数据流向,自上而下拆解整条链路。
当 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 的"重复/低优先级请求拒绝"逻辑(详见第六节排错)。
这是寻呼真正的"触发源"。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 在寻呼尚未成功时就错乱地处理两条信息。
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 需要监听的小区数,省电 |
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;
- 否则忽略。
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 两套寻呼参数的协同。
PPD(Paging Policy Differentiation,TS 23.501 §5.4.3.2)是 5G 寻呼最有"工程味"的机制,专为 IMS 语音而生。其完整逻辑链:
Namf_Communication_N1N2MessageTransfer 中下发给 AMF。Paging Priority(prioLevel0~7)。与语音寻呼原因(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 内部全程不被篡改,否则会导致错误的寻呼策略被意外触发。
| 接口 | 协议 | 过滤条件 | 关键判据 |
|---|---|---|---|
| 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 配置。
| 现象 | 可能根因 | 排查方向 |
|---|---|---|
| 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、或采用更可靠的传输机会来实现。
本文由「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 等场景全覆盖。
