本文技术原理深度参考了3GPP TS 38.413 V18.5.0 (2025-03) Release 18规范中，关于“9.2.4 Paging Messages”的核心章节，旨在为读者提供一份关于5G网络寻呼“指令书”的详细解码指南，揭示网络是如何通过具体的信令消息结构来“唤醒”终端的。
深度解析 3GPP TS 38.413：9.2.4 Paging Messages (寻呼消息)
大家好，欢迎回到3GPP规范的深度解析系列。在之前的文章中，我们已经从流程（Procedure）的视角，详细探讨了网络是如何发起寻呼（Paging）来“唤醒”处于RRC_IDLE或RRC_INACTIVE状态的终端。我们理解了寻呼的“为什么”和“宏观上怎么做”。
今天，我们将深入到信令的“原子”层面，从“流程”走向“PDU（协议数据单元）”。我们将聚焦于9.2.4 Paging Messages，详细剖析构成寻呼流程的那封关键“指令书”——PAGING消息本身。我们将逐一拆解消息中的每一个信息元素（IE），理解它们各自承载的精确含义，以及gNB是如何根据这些“字段”来执行一次精准、高效的寻呼动作的。
这就像我们已经知道了寄信的全过程，现在我们要打开信封，仔细研究信件本身的格式和内容——收件人是谁？地址怎么写？信件的紧急程度？有没有附言？
为了生动地理解这份“寻人启事”的每一个细节，我们将引入一位新的主角——消防队长Eva。她在非执勤时间，手机处于RRC_INACTIVE的省电模式。我们将通过两个紧急场景，来剖析本章定义的两种寻呼消息：
PAGING消息：指挥中心需要紧急联系Eva本人，下达一个个人指令。我们将看到网络如何构建这份针对她个人的“寻呼令”。MULTICAST GROUP PAGING消息：城市发生重大突发事件，需要召集特定区域内所有休假的消防员。我们将看到网络如何发出一份“集结号”，同时唤醒一个群组的所有成员。
1. PAGING (单播寻呼消息)
这是用于寻呼单个特定UE的消息，是网络中最常见的“唤醒”指令。
1.1 消息目的与结构
9.2.4.1 PAGING This message is sent by the AMF and is used to page a UE in one or several tracking areas.
AMF是寻呼的发令者。当它需要联系处于“睡眠”状态的Eva时，就会向Eva最后所在位置的gNB发送这份PAGING消息。这份消息的结构如下，它像一张填写得满满当当的寻人布告。
表格 9.2.4.1-1: PAGING 消息内容
| IE/Group Name | Presence | Range | IE type and reference | Semantics description | Criticality | Assigned Criticality |
|---|---|---|---|---|---|---|
| Message Type | M | 9.3.1.1 | YES | ignore | ||
| UE Paging Identity | M | 9.3.3.18 | YES | ignore | ||
| Paging DRX | O | 9.3.1.90 | YES | ignore | ||
| TAI List for Paging | 1 | YES | ignore | |||
| >TAI List for Paging Item | 1.. | - | ||||
| >>TAI | M | 9.3.3.11 | - | |||
| Paging Priority | O | 9.3.1.78 | YES | ignore | ||
| UE Radio Capability for Paging | O | 9.3.1.68 | YES | ignore | ||
| … | ||||||
| Paging Cause | O | ENUMERATED (voice, …) | YES | ignore |
1.2 核心IE深度解码：“寻人启事”的关键要素
让我们逐一拆解这份“寻呼令”上的关键信息。
1.2.1 寻呼谁？- UE Paging Identity
9.3.3.18 UE Paging Identity This IE represents the Identity with which the UE is paged.
这是寻呼的核心目标。它告诉gNB要找的是谁。这个身份标识不是UE永久的ID（如SUPI），而是一个临时的、在核心网（AMF）中唯一的ID——5G-S-TMSI。使用临时ID是为了保护用户的隐私，避免在空口中直接暴露其长期身份。
场景演绎：
指挥中心要联系Eva。AMF在PAGING消息的UE Paging Identity字段中，填入了Eva手机当前的5G-S-TMSI。gNB收到后，就会在空口的寻呼消息中广播这个5G-S-TMSI。Eva的手机在自己的寻呼时机（Paging Occasion）醒来，监听到这个ID与自己匹配，就知道“有人找我了”，然后会立即发起RRC连接恢复流程以响应。
1.2.2 在哪儿找？- TAI List for Paging
TAI List for Paging: … This IE contains a list of TAs where the UE is to be paged.
这个IE定义了寻呼的地理范围。AMF根据UE最后一次上报的位置，将UE所在的跟踪区列表（TAI List）填入此字段。一个TA可能包含多个小区。
场景演绎：
Eva正在一个大型购物中心逛街，这个购物中心跨越了两个跟踪区（TA1和TA2）。AMF不确定她具体在哪一个，于是在TAI List for Paging中同时包含了TA1和TA2。gNB收到后，就会在这两个TA下的所有小区内广播对Eva的寻呼消息。
1.2.3 什么时候找？- Paging DRX
9.3.1.90 Paging DRX This IE indicates the Paging DRX as defined in TS 38.304 and TS 36.304.
这个IE定义了UE的“睡眠-唤醒”周期，即**DRX（非连续接收）**周期。它告诉gNB，UE会在哪个特定的寻呼时机（PO）醒来监听寻呼。这确保了gNB的广播能够与UE的唤醒“精准同步”，避免了不必要的广播和UE的额外功耗。
场景演绎：
AMF知道Eva的手机配置了1.28秒的DRX周期。它将这个值填入Paging DRX IE。gNB收到后，结合UE的ID，就能精确计算出下一次应该在哪个无线帧、哪个子帧上发送寻呼消息，以确保“睡着”的Eva的手机能在那一刻“睁眼”看到。
1.2.4 事情有多急？- Paging Priority
9.3.1.78 Paging Priority This element indicates the paging priority for paging a UE.
这个IE为寻呼任务设定了优先级。gNB在调度空口资源时，会优先处理高优先级的寻呼请求。
场景演绎：
指挥中心对Eva的呼叫是紧急任务，因此AMF在PAGING消息中将Paging Priority设置为一个较高的级别。如果此时gNB正好也在处理一个普通App推送的低优先级寻呼，它会优先为Eva的寻呼分配无线资源。
1.2.5 为什么找？- Paging Cause
9.3.3.63 Paging Policy Differentiation This IE provides paging policy differentiation information for a UE in RRC_INACTIVE state. Paging Cause This IE indicates that the paging is originated due to the PDU sessions from the non-3GPP access.
规范中通过Paging Policy Differentiation和Paging Cause等IE来提供寻呼原因的线索。例如，Paging Cause可以指示寻呼是由于语音呼叫（voice）、短信或其他数据业务触发的。gNB可以利用这些信息进行更精细的资源调度。例如，对语音业务的寻呼，可能会分配更可靠的无线资源。
2. MULTICAST GROUP PAGING (多播组寻呼消息)
当需要同时通知一个特定群组的所有成员时，网络会使用更高效的多播组寻呼。
2.1 消息目的与结构
9.2.4.2 MULTICAST GROUP PAGING This message is sent by the AMF and is used to notify involved UEs about the activation of a multicast MBS session.
场景引入： 城市突发重大火情，指挥中心需要立即召集A区所有休假的消防员。这些消防员的专用设备都预先加入了一个“A区消防应急”多播组。AMF需要通知所有这些设备，MBS会话即将被激活。
AMF向A区的所有gNB发送MULTICAST GROUP PAGING消息。
表格 9.2.4.2-1: MULTICAST GROUP PAGING 消息内容
| IE/Group Name | Presence | Range | IE type and reference | Semantics description |
|---|---|---|---|---|
| Message Type | M | 9.3.1.1 | ||
| MBS Session ID | M | 9.3.1.206 | ||
| MBS Service Area | O | 9.3.1.208 | ||
| Multicast Group Paging Area List | 1 | |||
| >Multicast Group Paging Area Item | 1.. | |||
| >>Multicast Group Paging Area | M | 9.3.1.216 | ||
| >>UE Paging List | 0..1 | |||
| >>>UE Paging Item | 1.. | |||
| >>>>UE Identity Index Value | M | 9.3.3.23 | ||
| >>>>Paging DRX | O | 9.3.1.90 |
2.2 核心IE深度解码：“集结号”的关键信息
-
MBS Session ID: 这是多播组的唯一标识（如TMGI），相当于“A区消防应急”这个频道的号码。gNB将在空口广播这个ID，所有属于该组的UE都会响应。 -
MBS Service Area/Multicast Group Paging Area List: 定义了组寻呼的地理范围。MBS Service Area定义了整个业务区，而Multicast Group Paging Area List则可以将其细化到更小的寻呼区域。 -
UE Paging List: 这是一个非常重要的优化机制。如果AMF知道在某个特定寻呼区域内，只有少数几个UE（例如，只有Eva和另外两名消防员）属于这个多播组，它可以不进行泛泛的组寻呼，而是在这个IE中明确列出这几个UE的UE Identity Index Value（一个用于计算寻呼时机的短ID）和各自的Paging DRX。gNB收到后，就可以像执行多次单播寻呼一样，在各自的PO上精确地唤醒这几个UE。这种方式在组成员稀疏分布时，可以极大地节省空口资源。
场景演绎：
AMF向gNB-Mall-01发送MULTICAST GROUP PAGING，其中MBS Session ID指向“A区消防应急”组。AMF通过后台数据发现，当前在gNB-Mall-01覆盖范围内，只有Eva的设备属于这个组。于是，AMF在UE Paging List中只填入了Eva的信息。gNB-Mall-01收到后，实际上只执行了一次针对Eva的寻呼。而在消防员密集的消防站附近的gNB，AMF可能不会包含UE Paging List，gNB则会在所有PO上广播这个组ID，以唤醒所有设备。
FAQ
Q1: PAGING消息和我们在空口上听到的寻呼消息（Paging Message）是一回事吗？
A1: 不是一回事，它们是两个不同协议层面的消息。
- NGAP PAGING消息：是NG-C接口上的消息，在AMF和gNB之间传输。它是核心网给接入网下达的“寻呼指令”，内容非常丰富，包含了我们今天讨论的各种IE。
- RRC Paging消息：是**Uu接口（空口）**上的消息，在gNB和UE之间传输。它是gNB执行指令后，实际在无线信道上广播的消息。它的内容要简洁得多，主要就是在PDCCH信道上指示一个P-RNTI，然后在PDSCH上携带一个包含一个或多个
UE Paging Identity（如5G-S-TMSI）的列表。
可以理解为，NGAP PAGING是“任务书”，RRC Paging是根据任务书发出的“广播稿”。
Q2: 为什么多播组寻呼消息中还有一个UE Paging List？这不就变成单播了吗？
A2:
这是一种灵活的优化策略，可以理解为“批处理的单播寻呼”。它的目的仍然是激活一个多播组，但执行方式更高效。当一个多播组的成员在某个区域内分布非常稀疏时，进行全时段的组ID广播会浪费大量空口资源。通过UE Paging List，AMF将“大海捞针”变成了“按图索骥”。gNB不再需要盲目地在所有PO上广播组ID，而是可以精确地在每个已知成员的PO上进行寻呼。这大大降低了对其他无关UE的干扰和空口的整体信令负载。
Q3: 在PAGING消息中，UE Paging Identity使用的是5G-S-TMSI。UE在RRC_INACTIVE状态下，gNB知道这个ID吗？
A3:
gNB不知道。在RRC_INACTIVE状态下，gNB只保留了UE的AS层上下文，其中包含一个短的、gNB内部使用的I-RNTI。而5G-S-TMSI是核心网层面的临时ID，保存在AMF和UE中。
寻呼流程是这样工作的：AMF通过PAGING消息将5G-S-TMSI发给gNB。gNB收到后，会将这个5G-S-TMSI映射到UE的I-RNTI（在IDLE模式下，gNB没有I-RNTI，直接使用5G-S-TMSI计算寻呼帧）。然后在空口上，gNB会在PDCCH上使用P-RNTI（寻呼公共RNTI）来加扰，所有处于睡眠状态的UE都会尝试解码。如果UE在自己的PO上成功解码了PDCCH，它就会去读取对应的PDSCH上的Paging消息，查看里面的UE标识列表，如果找到了自己的5G-S-TMSI或I-RNTI，就响应寻呼。
Q4: 如果AMF要寻呼一个UE，但这个UE已经移动到了另一个gNB的覆盖下，会发生什么？
A4: 这取决于UE的状态。
- RRC_IDLE: AMF会在UE注册的整个TA List中的所有gNB上发起寻呼。所以即使UE移动了，只要还在同一个TA内，新的gNB就会收到寻呼请求并广播，UE就能被找到。
- RRC_INACTIVE: AMF会先将寻呼请求发给UE最后一次连接的“锚点gNB”。如果UE还在这个gNB维护的RNA区域内，就会被成功寻呼。如果UE已经移出了RNA，锚点gNB寻呼失败（UE无响应），它不会通知AMF。AMF侧的寻呼定时器会超时，AMF会认为寻呼失败，然后它会将寻呼策略“升级”为在整个TA List内进行广播寻呼，这个过程被称为“RAN Paging failure”后的回退机制。
Q5: 寻呼流程的失败率是网络的一个重要KPI吗？
A5: 是的，寻呼成功率是衡量网络可达性和用户体验的一个非常重要的核心KPI。寻呼成功率低，意味着：
- 用户体验差：用户会频繁遇到电话漏接、消息推送延迟等问题。
- 信令风暴：AMF需要进行多次、更大范围的重试寻呼，增加了核心网和空口的信令负荷。 导致寻呼成功率低的原因有很多，例如：无线覆盖差、UE侧的DRX与网络侧配置不匹配、TA或RNA规划不合理导致UE频繁移出寻呼区域等。网络优化工程师会密切监控这个KPI，并将其作为网络优化的重要依据。