好的，我们继续跟随5G基站工程师小雷，深入探索NG接口上那些与5G广播组播服务（MBS）相关的关键流程。在上一篇中，我们已经学会了如何为MBS业务“搭建广播台”，现在，我们将聚焦于如何“唤醒”那些可能对组播节目感兴趣的“沉睡的听众”。

深度解析 3GPP TS 38.410：6.24 Multicast Group Paging Procedures (组播组寻呼流程)

本文技术原理深度参考了3GPP TS 38.410 V18.2.0 (2024-06) Release 18规范中，关于“6.24 Multicast Group Paging Procedures”的核心章节，并结合其在NGAP协议（TS 38.413）中的具体实现，为读者完整呈现5G网络中，针对MBS组播业务的“集体唤醒”机制——组播组寻呼的端到端信令视图。

引言：从“个体寻呼”到“群组唤醒”的效率革命

在之前的6.5节解读中，我们已经深入了解了标准的**单用户寻呼（Paging）**流程。那就像是在一个巨大的候车大厅里，通过广播寻找某一位特定的旅客：“请旅客张三注意！”。这种方式对于找到“张三”个人是有效的。

但现在，一个新的挑战出现了。一个MBS组播（Multicast）业务——例如，一场针对特定付费体育迷群体的“足球赛VIP视角”直播——即将在小雷的gNB覆盖下开始。这个“体育迷群组”里，可能有成百上千名用户，而他们中的大部分人，手机都处于IDLE或INACTIVE的省电状态。

如果网络要为这上千名用户，逐一发送单用户寻呼，将会产生一场巨大的“信令风暴”，不仅效率低下，而且会极大地消耗核心网和空口的信令资源。

为了解决这个问题，5G引入了一种革命性的“集体唤醒”机制——组播组寻呼（Multicast Group Paging）。它不再是寻找“张三”个人，而是在候车大厅里喊话：“请所有乘坐G123次列车的旅客注意！”。

第6.24节定义的Multicast Group Paging流程，正是NG接口为实现这一“群组唤醒”而设计的专属信令通道。

---

1. 流程的“剧本”：Multicast Group Paging 的唯一使命

6.24 Multicast Group Paging Procedures

The following Multicast Group Paging procedure is used to send multicast group paging requests to the NG-RAN nodes:

• Multicast Group Paging.

与单用户寻呼一样，6.24节的描述也极其简洁，只定义了一个流程——Multicast Group Paging。这同样是一个由AMF单向发起、gNB负责执行、无需响应的命令式流程。

核心使命: 允许AMF向一个或多个gNB，发送一条单一的组寻呼请求，以一次性地唤醒所有加入了某个特定MBS组播会话的、且正处于IDLE或INACTIVE状态的UE群体。

与单用户寻呼的根本区别：

特性	单用户寻呼 (Unicast Paging)	组播组寻呼 (Multicast Group Paging)
寻呼对象	单个UE (by 5G-S-TMSI)	一个UE群组 (by MBS Session ID)
触发原因	针对单个UE的下行数据/信令	针对整个组播业务的下行数据/信令
信令效率	N个UE需要N条NGAP消息	N个UE只需要1条NGAP消息
空口效率	N个UE需要在Paging消息中列出N个ID	只需要在Paging消息中列出1个组ID

---

2. “集体唤醒令”的详细解读：MULTICAST GROUP PAGING 消息

NGAP Procedure: Multicast Group Paging (AMF Initiated) NGAP PDU: MULTICAST GROUP PAGING (AMF → gNB)

当核心网决定需要唤醒一个MBS组播群组时，AMF会向该群组用户可能在的寻呼区域内的所有gNB，发送一条MULTICAST GROUP PAGING消息。这条消息，就是我们所说的“集体唤醒令”。

实战演练：VIP足球直播即将开始

• 触发: 核心网的MBSF/SMF检测到，“VIP足球直播”这个MBS组播会话即将有数据下发（例如，赛前广告或精彩集锦）。它需要唤醒所有订阅了这个服务的、正处于“睡眠”状态的用户。

• AMF → gNB (MULTICAST GROUP PAGING):

  • 流程启动！ AMF向小雷的gNB（以及寻呼区内所有其他gNB）发送MULTICAST GROUP PAGING消息。
  • 消息内容（“集体唤醒令”）:
    • Multicast Group Paging Area List: 关键的“唤醒范围”。与单用户寻呼类似，它定义了本次组寻呼需要覆盖的地理范围，通常由一组TAI（跟踪区标识）列表来描述。AMF只会向服务于这些TA的gNB发送此消息。
    • MBS Session ID List: 最重要的部分。这是一个列表，包含了一个或多个需要被寻呼的MBS会话ID。这相当于在“唤醒令”上明确指出：“要叫醒的是哪些‘旅行团’的成员”。
    • Paging Priority (可选): 寻呼的优先级。对于付费的VIP直播，AMF可能会设置一个较高的优先级。

• gNB的“广场喊话”工作:

  • 小雷的gNB收到了这份“集体唤醒令”。
  • gNB的RRC协议栈会生成一个或多个特殊的空口Paging消息。
  • 在这个Paging消息中，它不再包含某个具体的UE ID（5G-S-TMSI），而是会包含一个或多个从MBS Session ID映射而来的组级别的标识符（例如，G-RNTI或特定的Paging DCI格式）。
  • gNB在计算好的寻呼时机（PO）上，将这条“群组点名”的Paging消息，在所有指定小区的空口上广播出去。

• UE群组的响应:

  • 所有之前加入了“VIP足球直播”这个MBS组播会话、并且正处于IDLE/INACTIVE状态的UE，在监听到这个专属的组标识符后，就知道是“组织在召唤”。
  • 它们会集体地被唤醒，并各自发起**服务请求（Service Request）**流程，恢复到CONNECTED状态，准备接收即将到来的组播数据。
  • 而那些没有加入这个MBS会话的用户，则对这个特殊的组寻呼标识符“无感”，会继续保持“睡眠”状态。

---

3. “群组唤醒”的意义：MBS业务的“催化剂”

Multicast Group Paging流程，虽然只是一个简单的单向指令，但它对于5G MBS业务，特别是**组播（Multicast）**业务的成功商用，起着“催化剂”般的作用。

• 解决了信令风暴:

  • 它是解决“一对多”唤醒场景下信令风暴问题的唯一解。没有组播组寻呼，大规模的组播业务将因为寻呼瓶颈而变得不切实际。

• 提升了网络效率:

  • 极大地降低了核心网AMF的处理负荷（从生成N条消息变为生成1条）和NG接口的信令带宽占用。
  • 极大地降低了空口Paging信道的资源占用，为其他单用户寻呼和系统信息广播，留出了更多的空间。

• 优化了终端功耗:

  • 虽然组播组寻呼本身不直接降低单个UE的功耗，但它使得UE能够放心地进入IDLE/INACTIVE状态成为可能。因为UE知道，即使自己“睡着了”，当有属于它的组播内容时，网络也有一个高效的机制能把它“叫醒”，而不会错过重要信息。这反过来鼓励了更激进的终端节能策略。

---

总结：于细节处，见证5G的“效率革命”

通过对6.24节“组播组寻呼流程”的深度剖析，我们看到了5G在追求极致性能的道路上，对“效率”二字的深刻理解和极致追求。

• 一个简洁而强大的流程: Multicast Group Paging以一条NGAP消息，解决了唤醒成千上万个用户的行业难题，是“四两拨千斤”的典范。
• 从“个体”到“群体”的思维转变: 它标志着5G的网络管理思维，从传统的、以单个UE为中心的模式，向着能够高效处理用户群体的、业务驱动的模式演进。
• MBS业务的“临门一脚”: 它是MBS业务能够从“实验室”走向“大众”，特别是对于需要唤醒IDLE/INACTIVE用户的组播场景，能够提供电信级服务质量的关键技术拼图。

对于基站工程师小雷来说，MULTICAST GROUP PAGING这条信令，是他网络中“效率革命”的生动体现。当他看到这条信令时，他知道他的gNB不再是像一个“户籍警”一样，挨家挨户地去敲门“查水表”，而是像一个“社区广播员”，用一个“大喇叭”，就将通知传达到了整个小区的家家户户。这种从“点”到“面”的效率飞跃，正是5G网络能够从容应对未来千亿连接、万千业务挑战的信心所在。