好的，我们继续解读TR 21.918的后续章节。
深度解析 3GPP TR 21.918：12.1 5G MBS Phase 2 (5G多播广播业务第二阶段) & 12.2 Enhancements of NR MBS (NR MBS增强)
本文技术原理深度参考了3GPP TR 21.918 V18.0.0 (2025-03) Release 18规范中，关于“12.1 5G MBS Phase 2”和“12.2 Enhancements of NR MBS”的核心章节。本文将合并解读这两个高度相关的章节，旨在为读者深入剖析5G-Advanced在多播广播服务（MBS）领域如何从基础框架走向精细化运营和效率提升，特别是在支持大规模终端接收和RAN共享场景下的关键技术演进。
在数字时代，将相同的内容（如体育赛事直播、软件更新包、紧急告警）同时分发给海量用户，是一种非常普遍的需求。如果采用传统的单播（Unicast）方式，即为每个用户建立一条独立的传输通道，将会对网络造成巨大的资源浪费和信令风暴。为此，3GPP在Release 17中，正式引入了5G多播广播服务（5G MBS），旨在以“一点对多点”的高效方式，解决海量内容的同步分发难题。
然而，Rel-17的MBS主要搭建了基础的系统架构和流程，在实际运营中，仍然面临诸多挑战：如何支持海量物联网或可穿戴设备以极低功耗接收MBS服务？在多个运营商共享无线接入网（RAN Sharing）的场景下，如何避免重复的资源浪费？
为了应对这些挑战，Release 18启动了“5G MBS第二阶段”的增强。12.1章节主要从**系统架构（SA）层面，特别是计费方面进行了完善，而12.2章节则从无线接入网（RAN）**层面，引入了多项关键的功能增强。
今天，我们的主角，是一家大型体育赛事转播公司的技术总监，孙工。他正在为一个即将在智慧体育场举行的国际足球赛事，规划一套全新的5G观赛体验方案。他希望场内的数万名观众，都能够通过5G网络，在其手机上实时、低时延地观看多角度、高清的赛事回放。让我们跟随孙工的需求，深入解读12.1和12.2章节，看看5G MBS是如何通过自我进化，来满足这种极致的“一对多”通信需求的。
1. 计费的完善：MBS商业化的基石 (解读 12.1)
在投入新技术之前，孙工首先要和运营商谈妥商业模式：这项MBS服务，该如何计费？是向他（内容提供方）收费，还是向观众（终端用户）收费？
Charging Aspects for SMF and MB-SMF to Support 5G Multicast-broadcast Services SA2 have specified architecture enhancements for 5G multicast-broadcast services… To support charging for 5G multicast and broadcast services, SA5 work item mainly focus on charging aspect of 5G multicast-broadcast services…
Rel-18的SA5（计费）工作组为此定义了一套完整的MBS计费架构和原则。
- 引入MB-SMF计费: 针对MBS业务流，引入了一个新的计费触发点——MB-SMF（MBS会话管理功能）。运营商可以基于MB-SMF生成的计费数据，直接向孙工这样的内容提供方，按照“MBS会话时长”、“总流量”、“覆盖范围”等维度进行B2B计费。
- 增强SMF计费: 对于终端用户，其接收MBS业务的PDU会话，依然由SMF进行管理和计费。运营商可以为观众提供“MBS流量包”或“赛事通票”，实现B2C计费。
- 灵活的计费策略: 这套双管齐下的计费体系，为运营商和内容提供商的合作，提供了极大的灵活性，扫清了MBS商业化的最后障碍。
2. “沉睡”的观众：Inactive态下的多播接收 (解读 12.2)
解决了商业模式，孙工开始关注技术实现。他发现，体育场内的观众，不可能一直亮着手机屏幕。大部分时间，他们的手机都处于锁屏休眠状态。如果MBS服务只能在RRC_CONNECTED（连接态）下接收，那将毫无意义。
Multicast reception by UEs in RRC_INACTIVE To support a large number of UEs in a cell for services like Mission Critical Services, it is important to support multicast for UEs in RRC_INACTIVE.
12.2章节最重要的增强，就是引入了RRC_INACTIVE态下的多播接收能力。
- “半睡半醒”的接收: 处于Inactive态的UE，其核心网连接上下文（如IP地址）是被保留的，但其RRC连接已经释放，射频单元大部分时间处于休眠。
- PTM配置的获取: 为了能够在Inactive态下正确地接收多播数据，UE需要知道多播传输所使用的无线资源配置（PTM Configuration）。Rel-18规定，这个配置信息可以在UE从Connected态进入Inactive态时，通过
RRCRelease消息携带；UE也可以在Inactive态下，通过监听一个轻量级的**多播MCCH（MBS Control Channel）**来获取或更新这个配置。 - 组级寻呼与唤醒: 当gNB有MBS数据要下发时，它会通过一个特定的组RNTI（G-RNTI）来调度PDSCH。处于Inactive态的UE，会在其DRX周期醒来，监听这个G-RNTI。一旦监听到调度，它就会被唤醒并接收数据，而无需经历完整的RRC连接恢复过程。
这一革命性的增强，使得海量的、处于低功耗状态的终端（无论是观众的手机，还是城市里的物联网传感器），都能够高效地接收多播/广播服务，极大地扩展了MBS的应用场景。
3. RAN共享的智慧：避免“重复劳动” (解读 12.2)
孙工的赛事场馆，由多家运营商（如A和B）通过RAN共享的方式共同覆盖。现在，如果运营商A和运营商B都与孙工签订了转播协议，它们难道要在同一个物理基站上，各自重复地发送一遍完全相同的赛事回放视频流吗？这显然是巨大的资源浪费。
Resource efficiency improvement in the RAN sharing scenarios To improve resource efficiency for MBS broadcast reception in RAN sharing scenarios, 5GC provides the Associated Session ID allocated to the MBS Broadcast service to NG-RAN node to enable identification of MBS services providing the same Broadcast content. NG-RAN node could decide to establish one or multiple NG-U tunnels for the MBS broadcast services delivering the same MBS content.
为了解决这个问题，Rel-18引入了基于“关联会话ID”的资源效率提升机制。
- 内容的“身份证”: 5GC为每一个MBS广播业务流，分配一个关联会话ID（Associated Session ID）。这个ID唯一地标识了业务流的“内容”。
- RAN的智能识别: 当运营商A和B的核心网（5GC）都向共享的gNB请求发送MBS业务时，它们都会带上这个Associated Session ID。
- 合并传输: gNB在收到两个请求后，通过比对Associated Session ID，发现“原来你们俩要发的是同一个视频！”。于是，gNB可以做出一个智能决策：它只从其中一个运营商的核心网（例如，链路质量更好的A）接收数据流，然后在空口上只发送一次。而对于来自运营商B的用户，gNB会在内部建立映射，让他们也能正确地接收和解码这次传输。
通过这个简单的“内容身份证”机制，Rel-18巧妙地解决了RAN共享场景下的空口资源重复浪费问题，大大提升了频谱效率。
4. 广播与单播的协同：共享处理 (解读 12.2)
一个用户的手机，可能既需要接收体育场内MBS广播的赛事回放（来自场馆内基站），又需要同时通过单播，与朋友进行微信聊天（可能连接到场馆外的宏基站）。这两路信号，能否在UE内部共享硬件资源，以降低功耗和处理复杂度？
Shared processing for MBS broadcast and unicast reception If the UE in RRC_CONNECTED state is receiving or interested to receive an MBS broadcast service from a non-serving cell, the UE may use MBS Interest Indication message to inform the serving gNB about the parameters used for the non-serving cell broadcast reception.
Rel-18为此引入了**“MBS兴趣指示（MBS Interest Indication）”**机制。
- UE主动“坦白”: 当一个UE（连接在宏基站A上）想要接收来自场馆基站B的MBS广播时，它可以主动向其主服务基站A发送一个“MBS兴趣指示”消息。
- 告知参数: 在这个消息中，UE会告知基站A，它正在（或想要）收听的那个MBS广播所使用的参数（如频率、SCS、带宽等）。
- 智能调度: 基站A在收到这个信息后，就可以在进行单播调度时，主动规避那些UE需要用来接收MBS的资源，从而避免冲突。这使得UE可以更高效地在单播和广播任务之间进行时分复用，实现硬件资源的共享处理。
总结
3GPP TR 21.918的12.1和12.2章节，共同推动了5G MBS技术从“可用”走向了“好用”和“高效”。它们从商业模式、终端功耗、频谱效率等多个维度，为MBS的规模化商用扫清了障碍。
- 通过完善MBS计费框架，Rel-18为运营商和内容提供商的合作提供了灵活的商业基础。
- 通过引入Inactive态下的多播接收能力，MBS的服务对象，从少数在线用户，扩展到了海量的、沉睡的终端，极大地拓宽了其应用场景。
- 通过设计RAN共享下的资源合并和广播/单播协同处理机制，MBS在复杂网络环境下的部署效率和频谱利用率得到了显著提升。
对于孙工而言，这些增强意味着他的“5G智能观赛”方案，在技术上和商业上都已完全可行。数万名观众，无论手机处于何种状态，都能随时、低时延地获取到精彩的赛事内容，而这一切，又不会给RAN共享的基站带来不成比例的资源压力。
5G MBS Phase 2的演进，是5G-Advanced持续深耕垂直行业、追求极致网络效率的又一个缩影。它正在为体育直播、公共安全、车联网信息分发、物联网固件广播等“一对多”的通信场景，提供一个前所未有的、高效、可靠、可运营的解决方案。
FAQ - 常见问题解答
Q1：多播（Multicast）和广播（Broadcast）在5G MBS中有什么区别？ A1：主要区别在于接收用户的范围和加入方式。广播是**“地理相关”的，gNB在一个特定区域内，向该区域的所有UE发送相同的数据，UE无需事先加入，只要处于该区域就能接收（如果支持的话）。这类似于传统的电视广播。而多播是“群组相关”的，它只将数据发送给一个特定的UE群组**，只有那些事先通过信令流程“加入”了这个多播组的UE，才能接收数据。这类似于一个微信群聊。广播更适合公共告警、区域信息发布等场景，而多播更适合付费视频直播、企业内部培训等需要用户管理的场景。
Q2：UE在RRC_INACTIVE状态下接收多播，相比RRC_CONNECTED状态，有什么优势和劣势？ A2：最大优势是极低的功耗。Inactive态下，UE的射频和大部分处理器都处于休眠，只有在非常稀疏的DRX周期才醒来监听，其平均功耗远低于需要持续监听PDCCH的Connected态。劣势在于交互能力的缺失。Inactive态下，UE没有上行链路，因此无法进行任何反馈，如HARQ ACK/NACK、CSI报告等。这意味着Inactive态的多播是一种“只收不发”的单向传输，其可靠性完全依赖于物理层的信道编码和底层的鲁棒性，无法像Connected态那样通过重传机制来纠错。因此，它更适合视频直播这类对偶尔丢包不敏感、但对终端功耗要求极高的业务。
Q3：什么是Associated Session ID？它和我们熟知的TMGI（临时移动组标识）有什么关系？ A3：可以理解为“内容ID”和“频道ID”的关系。TMGI是MBS业务的**“频道ID”，它在空口上标识了一个特定的MBS业务流，UE通过监听与TMGI关联的G-RNTI来接收数据。在RAN共享场景下，运营商A和B可能会为同一个赛事直播，分配不同的TMGI（例如TMGI-A和TMGI-B）。而Associated Session ID是核心网层面分配的“内容ID”，它唯一地标识了“这场足球赛的视频流”这个内容本身**。当运营商A和B都向共享的gNB请求传输时，虽然它们使用的TMGI不同，但它们携带的Associated Session ID是相同的。gNB正是通过比对这个“内容ID”，才得以识别出这是重复内容，并执行合并传输。
Q4：为什么需要“MBS兴趣指示”（MBS Interest Indication）？UE不能自己处理好单播和广播的接收吗？ A4：UE可以自己处理，但效率不高且可能产生冲突。UE的射频和基带资源是有限的。如果UE在某个时刻需要接收单播数据（由服务小区A调度），同时又需要切换到另一个频率去接收广播数据（由小区B发送），这就需要在两个任务之间进行时分复用（TDM）。如果没有“MBS兴趣指示”，服务小区A对UE的“兼职工作”一无所知，它可能会在UE切换到广播频率去“摸鱼”的时候，恰好调度了一个重要的单播数据包，导致数据丢失。而有了这个指示，UE就相当于向小区A“报备”：“老板，我每天下午3点到3点10分要去隔壁听个广播”。小区A在收到“报备”后，就会智能地在3点到3点10分这个时间段内，避免为该UE调度下行数据，从而避免了冲突，实现了网络与UE之间的高效协同。