首页 › protocols › 5G寻呼流程信令全链拆解

5G寻呼流程信令全链拆解：从触发到PO计算，eDRX/PTW与寻呼限制的协议级解析

一、引言：寻呼为何是5G信令体系中最"朴素"却最复杂的机制

在5G系统中，寻呼（Paging）是核心网恢复与空闲态UE通信的唯一手段。无论是下行数据到达、下行NAS信令（如SMS over NAS、LCS定位触发），还是网络侧主动发起的业务请求，只要UE处于CM-IDLE状态，都必须先通过寻呼把UE"唤醒"，再由UE发起Service Request建立信令与用户面连接。

看似简单的一条消息，背后牵涉的协议面却横跨 TS 23.501（架构与状态机）、TS 23.502 §4.2.3（流程）、TS 38.413（NGAP）、TS 38.331（RRC）、TS 38.304（物理层PO/PF计算）、TS 24.501（NAS） 六大规范，并叠加了R16引入的 Paging Restriction（寻呼限制）、Assistance Data for Paging（寻呼辅助数据），以及面向物联网场景的 eDRX / PTW（扩展非连续接收 / 寻呼时间窗） 等增强机制。本文聚焦 TS 23.502 §4.2.3 与 TS 38.413 PAGING 消息，逐层拆解这条信令从触发到UE响应的完整链路，并给出抓包识别、故障排查与厂商差异的实战视角。

二、寻呼触发机制与设计意图

5G寻呼的触发源（trigger source）决定了整条信令链的起点。TS 23.502 §4.2.3 将其归纳为三类：

下行用户面数据到达（最常见）：UPF收到下行数据，但UE处于CM-IDLE，N3隧道已释放。UPF缓存数据并向SMF发送 PFCP Session Report（Data Notification），SMF判定UE不可达后向AMF触发寻呼。
下行NAS信令：AMF自身有下行NAS消息需投递（如SMS over NAS的MT SMS、LCS的MT-LR定位请求、或网络发起的Configuration Update），但UE在CM-IDLE。
RAN侧触发（RRC_INACTIVE）：UE处于CM-CONNECTED但RRC_INACTIVE，最后一个服务gNB保留了UE上下文与N3隧道，下行数据直接到达gNB，由gNB在 RNA（RAN-based Notification Area） 范围内执行RAN寻呼。

设计意图：5G将寻呼决策权集中在 AMF，而不是让RAN自行其是。这样做有两个好处：其一，AMF持有UE的注册区（Registration Area / TAI List）和DRX参数，能精准控制"在哪里寻、以什么频率寻"；其二，把Paging Priority、Paging Origin、Paging Restriction等策略统一在AMF收敛，便于和QoS（ARP）、双注册（3GPP/non-3GPP接入）、节电策略（eDRX）协同。这与EPS中MME主导的寻呼一脉相承，但5G新增了大量跨域策略接口。

三、端到端信令时序图（TS 23.502 §4.2.3）

下图描述下行数据到达触发、UE在CM-IDLE时的完整寻呼与响应链路：

sequenceDiagram
    participant AF as AF/外部数据网
    participant UPF as UPF
    participant SMF as SMF
    participant AMF as AMF
    participant gNB as NG-RAN (gNB)
    participant UE as UE (CM-IDLE)

    AF->>UPF: 下行数据包
    Note over UPF: UE处于CM-IDLE, N3隧道已释放<br/>缓冲下行数据
    UPF->>SMF: N4 PFCP Session Report<br/>(Data Notification, DRO田字)
    SMF->>SMF: 判定UE不可达 (CM-IDLE)<br/>确定PPI (基于ARP)
    SMF->>AMF: Namf_Communication_N1N2MessageTransfer<br/>(N2 info=Paging, PDU Session ID,<br/>Paging Policy Indication)
    Note over AMF: 查询UE上下文:<br/>TAI List, DRX, eDRX/PTW,<br/>UE Radio Cap for Paging, Paging Restriction
    AMF->>gNB: NGAP PAGING (N2)<br/>(5G-S-TMSI, TAI List for Paging,<br/>Paging Priority, PagingOrigin,<br/>Assistance Data for Paging)
    Note over gNB: 计算每个小区的PF/PO<br/>(TS 38.304 §7.1)
    gNB->>UE: RRC Paging (PCCH/PDCCH)<br/>(PagingRecord: NG-5G-S-TMSI)
    Note over UE: 匹配自身5G-S-TMSI<br/>触发Service Request
    UE->>gNB: RRC Setup Request + NAS Service Request
    gNB->>AMF: N2 Initial UE Message (Service Request)
    Note over AMF: CM-IDLE → CM-CONNECTED<br/>恢复N2/N3隧道
    AMF->>SMF: Nsmf_PDUSession_UpdateSMContext<br/>(激活用户面)
    SMF->>UPF: N4 Session Modification (转发下行规则)
    UPF->>UE: 转发缓存的下行数据

链路的关键节点在于 SMF→AMF 的 Namf_Communication_N1N2MessageTransfer：这条SBI消息携带的不是普通N2容器，而是一个特殊的指示 n2InfoContainer 内的 N2 information = "Paging"，可选携带 Paging Policy Indication (PPI)。AMF收到后并不立即向RAN转发，而是先执行一次"策略收敛"——读取UE上下文中的DRX、eDRX/PTW、Paging Restriction数据，再生成NGAP PAGING消息。

四、NGAP PAGING消息IE深度解析（TS 38.413 §9.x）

NGAP PAGING消息是整个寻呼流程的"信息枢纽"，所有策略最终都汇聚到这条消息的IE集合中。下表对照其关键IE：

IE名称	必备/可选	取值/语义	作用
UE Paging Identity	M	5G-S-TMSI 或 Full I-RNTI	UE标识。CM-IDLE寻呼用5G-S-TMSI；Full I-RNTI用于RRC_INACTIVE的特定寻呼场景
TAI List For Paging	M	TAI列表	决定RAN在哪些跟踪区广播寻呼，通常=UE注册区
Paging DRX	O	32, 64, 128, 256 (无线帧)	UE特定DRX周期，覆盖SIB1广播的默认DRX
Paging Priority	O	等级1～8 (1最高)	ARP/PPI映射而来的寻呼优先级，影响PO内时序资源抢占
Paging Origin	O	"3gpp access" / "non-3gpp access"	限定仅在某接入类型上寻呼，避免双注册UE被无谓唤醒
UE Radio Capability for Paging	O	UE无线能力子集	供RAN在早期寻呼时匹配正确的小区参数（band/带宽）
Assistance Data for Paging	O (R16)	Recommended Cells / TA List / RNA	协助RAN缩小寻呼范围，尤其RRC_INACTIVE UE
Assist Data for Paged UE	O (R17)	历史小区、覆盖等级等	进一步优化寻呼效率，降低空口开销

其中最值得深究的是 Paging Origin 与 Assistance Data for Paging：

Paging Origin 解决的是"双注册UE的寻呼抖动"问题。当一个UE同时通过3GPP接入和非3GPP接入（如untrusted WiFi经N3IWF）注册到同一5GC时，如果下行数据从3GPP侧PDU会话到达，AMF应只通过3GPP接入寻呼，避免在WiFi链路上无谓唤醒UE导致耗电。该IE在TS 23.501的non-3GPP接入章节与TS 38.413中联动定义。
Assistance Data for Paging (R16) 是为 RRC_INACTIVE 场景量身打造的。当UE进入RRC_INACTIVE并发生RNA内移动后，最后一个服务gNB可能已无法覆盖UE当前位置。AMF在触发寻呼时携带"推荐小区列表"与"推荐TA/RNA"，帮助RAN优先在这些区域广播，显著缩短寻呼时延——这对URLLC类业务的可达性至关重要。

下图展示NGAP PAGING消息的IE层级结构，以及各策略字段的来源：

graph TD
    MSG["NGAP PAGING 消息"] --> M1["UE Paging Identity<br/>(5G-S-TMSI)"]
    MSG --> M2["TAI List For Paging"]
    MSG --> M3["Paging DRX"]
    MSG --> M4["Paging Priority"]
    MSG --> M5["Paging Origin"]
    MSG --> M6["UE Radio Cap for Paging"]
    MSG --> M7["Assistance Data for Paging"]

    SRC1["UE上下文 (注册时存储)"] -.->|DRX| M3
    SRC1 -.->|Radio Cap| M6
    SRC2["SMF PPI ← ARP优先级<br/>TS 23.501 §5.4.3.3"] -.->|映射| M4
    SRC3["下行数据来源接入类型"] -.->|3gpp/non-3gpp| M5
    SRC4["R16 gNB上报的RNA/推荐小区"] -.->|经AMF| M7
    SRC5["UE注册区 TAI List"] -.-> M2

五、RAN侧寻呼与PO/PF计算（TS 38.304 §7.1）

AMF把NGAP PAGING发给一个或多个gNB后，真正的"广播动作"在无线侧完成。gNB需要在每个属于TAI List的小区内，依据 TS 38.304 §7.1 的算法计算该UE的 Paging Frame (PF) 与 Paging Occasion (PO)，并在对应时刻通过 PCCH/PDCCH 发送RRC Paging。

核心公式（简化）：

寻呼周期 T = min(T_default, T_UE)，其中 T_default 来自SIB1的 nB，T_UE 来自UE特定DRX。
UE_ID = 5G-S-TMSI mod 1024
PF：满足 SFN mod T = (T div N) × (UE_ID mod N) 的帧，其中 N = min(T, nB)
PO在PF内的索引：i_s = floor(UE_ID / N) mod Ns，Ns = max(1, nB/T)

设计意图：用UE标识直接散列到PF/PO，使得大量UE的寻呼时机在时域/频域上均匀分布，避免单帧内寻呼风暴。这也是为什么 5G-S-TMSI 的低10位（mod 1024）对寻呼负载均衡如此敏感——一旦AMF分配5G-S-TMSI时哈希不均，就会出现某些PO拥塞、UE漏呼。

UE在RRC_IDLE时按自己的DRX周期"醒来"，在PO对应的PDCCH上检测用 P-RNTI（值固定为0xFFFE）加扰的DCI，若检测到则读取PDSCH上的Paging消息，比对 PagingRecord 中的 ng-5G-S-TMSI 是否与自己匹配。匹配则触发Service Request。

下图概括UE在不同状态下的寻呼响应路径：

stateDiagram-v2
    [*] --> CM_IDLE: 注册完成
    CM_IDLE --> RRC_IDLE: 无RRC连接
    RRC_IDLE --> ServiceReq: 收到AMF/核心网寻呼<br/>(5G-S-TMSI匹配)
    CM_IDLE --> CM_CONNECTED: Service Request完成
    CM_CONNECTED --> RRC_CONNECTED: 正常数据收发
    CM_CONNECTED --> RRC_INACTIVE: gNB触发suspend<br/>(保留RNA/N3)
    RRC_INACTIVE --> RAN_Paging: 下行数据到达最后gNB<br/>(I-RNTI, RNA内广播)
    RAN_Paging --> RRC_CONNECTED: UE响应Resume
    RAN_Paging --> Core_Paging: RNA内无响应<br/>gNB通知AMF, AMF按TAI List寻呼
    RRC_CONNECTED --> CM_CONNECTED
    ServiceReq --> CM_CONNECTED

六、寻呼策略三要素：PPI、Paging Priority、Paging Origin

这三者经常被混淆，但它们处在信令链的不同位置、解决不同问题：

策略要素	产生位置	取值依据	最终落脚点
Paging Policy Indication (PPI)	SMF（TS 23.501 §5.4.3.3）	QoS流的ARP优先级	通过SBI传给AMF，由AMF映射为NGAP Paging Priority
Paging Priority	AMF（NGAP）	PPI映射 + 本地策略	gNB据此调整PO内时序优先级，拥塞时高优先级UE先寻
Paging Origin	AMF（NGAP）	下行数据来源接入类型	限定寻呼仅在3GPP或非3GPP接入执行

一个典型场景：运营商的MPS（多媒体优先服务）用户，其PDU会话QoS流的ARP优先级为1。SMF据此生成 PPI=高，AMF在NGAP PAGING中携带 Paging Priority=级别1。当RAN侧某PO内有多个UE等待寻呼、空口资源紧张时，gNB会优先为该UE分配寻呼资源，保证MPS用户在拥塞下仍可被快速唤醒。

七、eDRX与PTW机制：物联网场景的省电利器（TS 23.501 / TS 24.501）

标准DRX周期最长仅约2.56秒（10.24s级别），对大量低功耗物联网设备而言仍过于频繁。3GPP引入 eDRX（Extended DRX），允许CM-IDLE态UE的寻呼周期延长到 NR约43.7分钟（2621.44s）、NB-IoT更长，极大降低UE功耗。

eDRX引入两个核心参数，均在 Registration 过程中协商（TS 24.501）：

eDRX value：扩展DRX周期长度。
PTW value（Paging Time Window）：每个eDRX周期内UE必须醒来监听寻呼的"时间窗"。

参数	协商方向	典型取值（NR CM-IDLE）	说明
eDRX value	UE请求 → AMF协商	5.12s ~ 2621.44s (~43.7min)	周期越长越省电，但寻呼时延越大
PTW value	UE请求 → AMF协商	2.56s ~ 40.96s 等级	窗口越长，UE在周期内"活跃"时间越多，寻呼成功率越高

协商流程：UE在REGISTRATION REQUEST中携带 eDRX参数IE（含请求的eDRX cycle与PTW，按接入类型区分）；AMF根据本地策略（如运营商允许的最大eDRX周期）在REGISTRATION ACCEPT中返回 协商后的eDRX参数，可能小于UE请求值。AMF存储协商结果，并在后续NGAP PAGING或RAN交互时提供给gNB，使gNB能在正确的PTW内、正确的PF/PO上广播寻呼。

PTW的物理意义：eDRX周期内，UE只在PTW窗口内按子DRX周期监听PO，窗口外完全休眠。这意味着PTW之外的下行数据，AMF即使触发寻呼也无法立即送达，必须等到下一个PTW——这正是Paging Restriction等机制存在的背景：网络与UE需要对"可达性窗口"达成共识。

八、Paging Restriction：让UE主动"屏蔽"寻呼（TS 23.501 §5.4.4，R16）

R16引入的 Paging Restriction 是一个常被忽视但极具工程价值的机制。它允许处于CM-IDLE的UE通过NAS信令向AMF声明：在一段时间内，不要因为某些低优先级业务寻呼我。

UE通过 Registration / Configuration Update 携带 Paging Restriction数据IE，可限制两类寻呼：

下行用户面数据触发的寻呼（restrict paging for downlink data）
下行信令触发的寻呼（restrict paging for downlink signalling）

设置后，AMF在收到对应触发的寻呼请求时（如SMF因下行低优先级数据请求寻呼），会主动丢弃该寻呼，仅在收到高优先级/紧急业务时才寻呼。

设计意图与价值：

省电：UE知道自己短期内不期望被唤（如智能水表在非上报时段），主动屏蔽寻呼可避免被无关下行流量唤醒。
保护AMF资源：在大规模物联网部署中，大量"暂时不可达"UE若被无差别寻呼，会冲击AMF与空口；Paging Restriction让AMF在源头过滤。
与eDRX互补：eDRX延长周期、PTW缩小监听窗，Paging Restriction则从业务层面拒绝不必要的唤醒，两者叠加是5G物联网省电的完整方案。

需注意：Paging Restriction对紧急呼叫、高优先级业务（MPS/MCS）通常豁免，以保证关键通信可达——这是协议的安全兜底。

九、抓包识别与故障排查实战

9.1 如何在抓包中识别寻呼链

SBI接口（HTTP/2）：关注 Namf_Communication_N1N2MessageTransfer，其body中 n2InfoContainer.ngapIeType = "Paging" 即为SMF触发寻呼的标志。
N2接口（NGAP/SCTP）：直接搜 PAGING 消息，确认 UEPagingIdentity、TAIListForPaging、PagingOrigin。
Uu口（MAC/RLC/PDCCH）：在Wireshark中用 nr-rrc.paging 过滤RRC Paging，并用 mac-nr 配合 P-RNTI (0xFFFE) 检测PDCCH DCI_1_0寻呼调度。
N4接口（PFCP）：PFCP Session Report Request 携带 Downlink Data Report，是UPF通知SMF下行数据到达的源头。

9.2 常见故障点

UE漏呼（被叫不通）：最常见。排查5G-S-TMSI分配是否正确、UE DRX周期与网络广播的 nB 是否一致、PO/PF计算是否正确（尤其切换TAI List后）。若AMF侧无NGAP PAGING发出，回溯SMF是否判定UE可达性错误。
Paging Origin错配：双注册UE被在错误的接入类型上寻呼，导致唤醒失败。检查AMF是否正确设置Paging Origin。
eDRX场景下时延过大：业务侧投诉"被叫延迟几十分钟"，往往是协商的eDRX周期过长或PTW过小，需与运营商核对eDRX订阅策略。
Paging Restriction误开：UE异常设置了Paging Restriction，导致正常下行数据无法触发寻呼。检查UE上报的Paging Restriction数据IE。
RRC_INACTIVE UE跨RNA失联：最后gNB RNA内寻呼无响应却未及时通知AMF做核心网寻呼，导致下行超时。检查gNB的RNA寻呼失败重试与AMF通知逻辑。

常见问题

Q1：PPI（Paging Policy Indication）和 NGAP Paging Priority 是什么关系？ A：PPI由SMF基于QoS流ARP优先级生成，通过SBI传给AMF；AMF再将其映射为NGAP PAGING消息中的Paging Priority IE（1～8级）。两者是"策略输入→空口执行"的关系，PPI是核心网内部概念，Paging Priority是N2接口对RAN的最终指示。

Q2：CM-IDLE的eDRX周期最长能到多少？PTW的作用是什么？ A：NR CM-IDLE态eDRX周期最长约43.7分钟（2621.44秒），NB-IoT更长。PTW（Paging Time Window）是每个eDRX周期内UE必须醒来监听寻呼的时间窗——周期内只有PTW期间UE才检测PO，窗口外完全休眠，从而在"长周期省电"与"保证可寻"之间取得平衡。

Q3：UE处于RRC_INACTIVE时，谁负责寻呼？ A：最后一个服务gNB保留UE上下文与N3隧道，下行数据直接到达该gNB，由其在RNA（RAN-based Notification Area）内执行RAN寻呼（用I-RNTI）。只有当RNA内寻呼无响应、gNB判定UE已离开RNA时，才通知AMF，由AMF按TAI List执行核心网寻呼（用5G-S-TMSI）。

Q4：Paging Restriction开启后，UE会不会彻底无法被叫？ A：不会。Paging Restriction可限制下行用户面数据或下行信令触发的寻呼，但对紧急业务、高优先级（MPS/MCS）寻呼通常豁免，保证关键通信可达。其本质是UE主动声明"短期不希望被低优先级业务唤醒"，而非完全关闭寻呼。

Q5：为什么5G-S-TMSI的低10位对寻呼如此重要？ A：PO/PF计算中 UE_ID = 5G-S-TMSI mod 1024，即低10位直接决定UE的寻呼时机。若AMF分配5G-S-TMSI时低10位哈希不均匀，会导致大量UE挤在少数PO上（寻呼风暴），部分PO则空闲，引发拥塞丢呼与负载不均。

参考来源

3GPP TS 23.502 V18.6.0 — System procedures, §4.2.3 Paging procedure — 寻呼流程Stage 2定义，触发源与SMF/AMF交互
3GPP TS 38.413 V18.6.0 — NGAP, PAGING message — NGAP PAGING消息IE全集（UE Paging Identity、Paging Origin、Assistance Data等）
3GPP TS 23.501 — System Architecture, §5.4.3.3 PPI / §5.4.4 Paging Restriction / eDRX — PPI映射、寻呼限制、eDRX架构定义
ShareTechnote — 5G Paging — 寻呼PO/PF计算与RRC Paging结构图解
3glteinfo — 5G NGAP Paging message — NGAP PAGING消息IE逐项说明与必选项分析

本文由「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学通信知识星球海报-扫码加入