想象一个万人体育场馆，所有人同时看同一场直播。如果用传统的单播方式，基站需要为每个观众分别发送一份相同的视频流——一万人就需要发一万次。这就像一个老师在课堂上给50个学生分别念50遍同一篇课文，荒谬且浪费。
多播广播技术就是为了解决这个问题：同样的内容，只发一次，所有人同时收到。 老师只需要念一遍课文，全班同学同时听。
这就是5G MBS（Multicast and Broadcast Service，多播广播服务）的核心思想。
先看一组数据。假设一个4K直播视频流需要20Mbps带宽，一个基站小区的总容量约为1Gbps：
| 场景 | 同时观看人数 | 单播总带宽需求 | 占小区容量比 |
|---|---|---|---|
| 小型直播 | 10人 | 200Mbps | 20% |
| 体育场馆 | 100人 | 2Gbps | 超载200% |
| 紧急广播 | 1000人 | 20Gbps | 超载2000% |
单播模式下，用户数线性增长，带宽需求也线性增长。当用户数量达到某个阈值，网络必定崩溃。而MBS模式下，无论多少人同时接收，空口只消耗一份无线资源。
很多人混淆"多播"和"广播"，但它们在5G中有明确的技术定义：
| 特性 | 广播（Broadcast） | 多播（Multicast） |
|---|---|---|
| 接收者 | 小区内所有终端 | 仅加入MBS会话的终端 |
| 是否需要加入 | 不需要 | 需要主动加入 |
| 是否需要RRC连接 | 不需要（空闲态可接收） | 需要（RRC连接态） |
| HARQ反馈 | 不支持 | 可选支持 |
| 典型场景 | 紧急警报、公共广播 | V2X组通信、付费直播 |
| 可靠性 | 尽力而为 | 可保证QoS |
用一个比喻来理解：广播是"大喇叭喊话"，走过路过都能听到；多播是"微信群聊"，只有群成员才能收到消息。
多播广播并非5G首创。LTE时代就有eMBMS（enhanced Multimedia Broadcast Multicast Service），但市场应用并不广泛。为什么？
| 痛点 | LTE eMBMS | 5G MBS |
|---|---|---|
| 频谱效率 | 需要预留专用MBSFN子帧，浪费资源 | 共享信道灵活调度，不预留 |
| 移动性 | 跨MBSFN区域不支持连续接收 | 支持跨小区的MBS会话连续性 |
| 可靠性 | 广播模式无HARQ反馈 | 多播模式支持HARQ反馈 |
| QoS | 无差异化QoS | 支持MBS QoS流，可保证服务质量 |
| 组通信 | 不支持 | 支持组管理和成员控制 |
| 架构 | 需要专用BM-SC、MBMS-GW | 融入5GC服务化架构，新增MB-SMF/MB-UPF |
5G MBS最关键的设计理念是：不建"第二张网"，而是在现有5G架构上做增强。
5G MBS在核心网侧引入了两个新的网络功能，并与现有5GC网元协同工作：
graph TB
AF[AF<br>应用功能] --> MBSF[MBSF<br>MBS功能]
MBSF --> MBSTF[MBSTF<br>MBS流量功能]
MBSF -->|Nmb10| MB-SMF[MB-SMF<br>MBS会话管理]
MB-SMF -->|N4mb| MB-UPF[MB-UPF<br>MBS用户面]
MBSTF --> MB-UPF
MB-SMF -->|Nmb11| AMF[AMF]
AMF -->|N2| gNB1[gNB]
AMF -->|N2| gNB2[gNB]
MB-UPF -->|N3mb 共享隧道| gNB1
MB-UPF -->|N3mb 共享隧道| gNB2
gNB1 --> UE1[UE组]
gNB1 --> UE2[UE]
gNB2 --> UE3[UE]
style MB-SMF fill:#e1f5fe
style MB-UPF fill:#e1f5fe
style MBSF fill:#fff3e0
style MBSTF fill:#fff3e0
MB-SMF（MBS Session Management Function）——MBS会话管家
MB-SMF是MBS最核心的新增网元，负责MBS会话的全生命周期管理： - 接收应用层发起的MBS会话建立请求 - 向MB-UPF下发转发规则（把数据复制到哪些gNB） - 管理MBS会话的QoS参数 - 通过AMF通知gNB建立MBS无线资源
MB-UPF（MBS User Plane Function）——MBS数据分发器
MB-UPF是MBS用户面的关键节点，负责数据包的复制和分发： - 接收来自MBSTF的MBS数据流 - 通过共享隧道（N3mb接口）将数据分发给多个gNB - 执行QoS策略（限速、标记等）
MBSF（MBS Function）——MBS业务入口
MBSF是MBS业务的应用层控制点： - 处理MBS业务公告（告诉用户有什么多播/广播节目） - 与应用功能（AF）交互，接收MBS业务请求 - 协调MBSTF进行FEC前向纠错编码
MBSTF（MBS Traffic Function）——MBS流量处理器
MBSTF负责对MBS数据流进行应用层处理： - FEC编码：增加冗余数据，提高传输可靠性 - 数据包复制：为需要更高可靠性的场景生成副本
5G MBS定义了两种数据从核心网到RAN的分发方式，这是理解MBS架构的关键：
graph LR
subgraph 共享分发["架构1：共享隧道分发"]
MB-UPF1[MB-UPF] -->|N3mb<br>一条共享隧道| gNB_A[gNB-A]
MB-UPF1 -->|N3mb<br>一条共享隧道| gNB_B[gNB-B]
MB-UPF1 -->|N3mb<br>一条共享隧道| gNB_C[gNB-C]
end
subgraph 独立分发["架构2：独立隧道分发"]
UPF2[UPF] -->|N3<br>UE1专用隧道| gNB_D[gNB-D]
UPF2 -->|N3<br>UE2专用隧道| gNB_D
UPF2 -->|N3<br>UE3专用隧道| gNB_E[gNB-E]
end
style MB-UPF1 fill:#c8e6c9
style UPF2 fill:#ffccbc
| 对比项 | 共享隧道（Shared Delivery） | 独立隧道（Individual Delivery） |
|---|---|---|
| 隧道数量 | 1条MB-UPF到每个gNB | 每个UE一条UPF到gNB |
| 用户面路径 | MB-UPF → gNB | UPF → gNB（复用普通PDU会话） |
| 核心网负载 | 低（数据只发一次） | 高（每个UE一份） |
| RAN负载 | 低（空口PTM共享） | 高（每UE独立传输） |
| 适用场景 | 大规模组播/广播 | 支持MBS的UE与小规模场景 |
| 兼容性 | gNB需支持MBS | 不支持MBS的gNB也能用 |
关键洞察：架构2本质上是"退回单播"，但数据源来自MBS会话。它解决了一个实际问题——当某个gNB不支持MBS功能时，MBS数据仍能通过普通PDU会话送到UE。
理解了核心网如何分发数据，接下来看空口如何传输。5G NR gNB支持三种MBS传输模式：
graph TD
MBS[MBS数据到达gNB] --> 判断{gNB判断传输模式}
判断 -->|模式1| PTM[PTM传输<br>多播/广播无线承载]
PTM --> PTM_组[一组UE共享同一承载]
判断 -->|模式2| PTP[PTP传输<br>每个UE独立承载]
PTP --> PTP_1[UE1的承载]
PTP --> PTP_2[UE2的承载]
判断 -->|模式3| 混合[PTM+PTP混合<br>基础层PTM + 增强层PTP]
混合 --> PTM_基础[PTM: 所有UE收到基础画质]
混合 --> PTP_增强1[PTP: UE1收到增强画质]
混合 --> PTP_增强2[PTP: UE2收到增强画质]
style PTM fill:#c8e6c9
style PTP fill:#ffccbc
style 混合 fill:#e1bee7
这是MBS的"标准模式"。gNB用一套无线资源发送MBS数据，所有接收该MBS会话的UE共享同一份传输： - 使用专用的MBS无线承载（MRB，MBS Radio Bearer） - 调度信息通过组无线网络临时标识（G-RNTI）加扰 - 信道质量取"短板"——为覆盖最差的UE保守编码
类比：电视广播塔发射信号，所有天线都能接收。
当接收MBS的UE很少时，PTM反而不如PTP高效（因为PTM的MCS要照顾最差的UE）。这时gNB可以为每个UE建立独立的无线承载： - 复用普通的数据无线承载（DRB） - 每个UE有独立的调度和自适应编码 - HARQ反馈正常工作，可靠性更高
类比：VIP一对一服务，每个人享受定制化传输。
这是Release 17引入的创新模式，兼顾效率和体验： - 基础层数据通过PTM发送给所有UE（确保基本接收） - 增强层数据通过PTP单独发送给每个UE（提升个体体验） - 信号好的UE可以收到基础层+增强层（高清） - 信号差的UE只收到基础层（标清但可用）
$$R_{total} = R_{PTM}^{base} + R_{PTP}^{enhance}$$
其中 $R_{PTM}^{base}$ 是所有UE共享的基础速率，$R_{PTP}^{enhance}$ 是每个UE独享的增强速率。
类比：全员发标准版教材（PTM），再加私教辅导课（PTP）。
gNB不是固定用某种模式，而是根据以下因素动态切换：
| 决策因素 | 倾向PTM | 倾向PTP |
|---|---|---|
| 接收UE数量 | 多（>阈值） | 少（<阈值） |
| UE信道质量差异 | 差异小 | 差异大 |
| 小区负载 | 资源紧张 | 资源充裕 |
| 可靠性要求 | 尽力而为 | 高可靠要求 |
理解了架构和传输模式，看一个完整的多播MBS会话建立流程：
sequenceDiagram
participant AF as 应用功能
participant MBSF as MBSF
participant MB-SMF as MB-SMF
participant MB-UPF as MB-UPF
participant AMF as AMF
participant gNB as gNB
participant UE as UE
Note over AF,UE: 阶段1：MBS会话创建（AF触发）
AF->>MBSF: 请求创建MBS会话
MBSF->>MB-SMF: Nmb10: 创建MBS会话
MB-SMF->>MB-UPF: N4mb: 建立MBS会话上下文
MB-SMF-->>MBSF: 返回MBS会话ID和TMGI
Note over AF,UE: 阶段2：MBS会话激活（开始传输数据）
AF->>MBSF: 激活MBS会话
MBSF->>MB-SMF: 激活MBS会话
MB-SMF->>MB-UPF: 建立共享分发隧道
MB-SMF->>AMF: Nmb11: 通知MBS会话激活
AMF->>gNB: N2: MBS会话资源建立
gNB->>gNB: 配置MBS无线承载和G-RNTI
gNB-->>AMF: MBS资源建立响应
Note over AF,UE: 阶段3：UE加入MBS会话
UE->>AMF: NAS: Join MBS Session请求
AMF->>MB-SMF: 通知UE加入
MB-SMF->>AMF: 返回MBS上下文信息
AMF->>gNB: N2: 建立MBS会话上下文
gNB->>UE: RRC: 配置MBS无线承载（MRB）
Note over UE: UE开始接收MBS数据
Note over AF,UE: 阶段4：数据传输
AF->>MBSF: MBS数据流
MBSF->>MB-UPF: 经MBSTF处理的数据
MB-UPF->>gNB: N3mb: 共享隧道分发
gNB->>UE: PTM传输（G-RNTI加扰）
这个流程分为四个阶段，对应四个关键问题： 1. 创建：应用层告诉网络"我要开一个多播频道" 2. 激活：网络为这个频道分配好所有资源 3. 加入：UE主动申请接收这个频道 4. 传输：数据开始流动
广播模式更简单，UE不需要"加入"：
AF → MBSF → MB-SMF → MB-UPF → gNB → 所有UE
↑
无需RRC连接
空闲态也能接收
gNB通过系统信息广播（SIB）告知UE当前有哪些广播MBS会话可用，UE自行决定是否接收。
5G MBS引入了专用的QoS框架，这是相比LTE eMBMS的重大提升：
| QoS参数 | 说明 | 取值示例 |
|---|---|---|
| MBS QoS Flow | MBS专用QoS流标识 | 唯一QFI |
| 5QI for MBS | MBS的QoS等级 | 84（延迟敏感）、85（可靠性敏感） |
| ARP | 分配保留优先级 | 抢占和被抢占能力 |
| GBR | 保证比特速率 | 确保最低传输速率 |
| MFBR | 最大流比特速率 | 限制最高速率 |
5G MBS新增了两个专用的5QI值：
| 5QI | 资源类型 | 优先级 | 延迟预算 | 丢包率 | 典型应用 |
|---|---|---|---|---|---|
| 84 | Non-GBR | 2 | 30ms | 10⁻² | 实时组播视频 |
| 85 | Non-GBR | 0.5 | 5ms | 10⁻³ | V2X安全消息 |
为什么MBS的QoS默认是Non-GBR？因为多播服务面向一组用户，为整组预留固定资源不现实。但在关键场景（如公共安全），可以配置GBR保障。
传统广播（如电视、FM电台）是"发完就发完了"，接收不好只能认倒霉。5G MBS引入了两层可靠性机制：
多播模式下，gNB可以配置组HARQ反馈： - UE收到MBS数据后发送ACK/NACK - gNB统计组内NACK比例，决定是否重传 - 为避免"反馈风暴"，采用NACK-only机制（只有没收到才反馈）
$$P_{NACK} = \frac{N_{NACK}}{N_{group}}$$
当 $P_{NACK}$ 超过阈值时触发重传。
MBSTF在发送前对MBS数据包进行FEC编码，增加冗余包： - 即使空口丢了几个包，UE通过冗余包恢复原始数据 - 不需要重传，节省空口资源 - 特别适合广播模式（没有HARQ反馈）
$$k个原始包 + (n-k)个冗余包 = n个编码包$$
UE只需收到n个编码包中的任意k个就能恢复全部数据。
不是所有场景都适合MBS。一个简单的判断公式：
$$\text{启用MBS的条件}: \quad N_{UE} \times R_{per_UE} > R_{PTM}$$
当 $N_{UE}$ 个用户各自需要 $R_{per_UE}$ 的单播速率，总需求超过一份PTM传输的开销时，MBS才有价值。通常阈值在10-20个用户左右。
每个MBS会话在gNB内分配一个G-RNTI。如果两个MBS会话被分配了相同的G-RNTI，UE会混淆调度信息。现网中需要确保G-RNTI分配不冲突。
UE在多播模式下移动到新小区时，需要保持MBS会话连续。有两种方案： - 接收模式切换：在新小区加入PTM传输 - 回退到单播：如果新小区不支持MBS，通过独立隧道继续传输
| 错误类型 | 现象 | 排查方法 |
|---|---|---|
| MB-UPF隧道未建立 | gNB收不到MBS数据 | 检查N4mb会话和N3mb隧道状态 |
| G-RNTI未配置 | UE无法解码MBS调度 | 检查RRC重配消息中的MRB配置 |
| QoS参数不匹配 | 画面卡顿或马赛克 | 对比MB-SMF和gNB的QoS Profile |
| FEC冗余不足 | 丢包率过高 | 增加MBSTF的FEC编码率 |
| 场景 | 模式 | 核心价值 | 成熟度 |
|---|---|---|---|
| 体育场馆多视角直播 | 多播 | 节省90%+无线资源 | R17已定义 |
| V2X安全消息广播 | 多播/广播 | 低延迟群组通信 | R17已定义 |
| 紧急警报（PWS增强） | 广播 | 空闲态也能接收 | R17已定义 |
| IoT固件批量更新 | 多播 | 一次发送万个设备升级 | R18增强 |
| AR/VR场馆体验 | 多播+混合模式 | 基础层共享+个性化增强 | R18研究中 |
| 公共安全组通信 | 多播 | 可靠组播+优先级保障 | R18增强 |
Q: 5G MBS和LTE eMBMS能共存吗？
A: 能。5G MBS是独立于LTE eMBMS的新架构。在NSA组网下，UE可以通过LTE接收eMBMS，通过NR接收5G MBS。在SA组网下，5G MBS完全独立运行。从演进路径看，eMBMS逐渐被5G MBS替代。
Q: 广播模式下空闲态UE如何接收MBS数据？
A: gNB通过SIB（系统信息块）广播MBS配置信息，包括可用的广播MBS会话列表、G-RNTI、调度参数等。空闲态UE读取SIB后，根据G-RNTI解码对应的PDCCH，获取调度信息，然后在PDSCH上接收MBS数据。全程不需要建立RRC连接。
Q: PTM模式下如何照顾信道质量差的UE？
A: PTM模式下，gNB需要选择一个所有接收UE都能解码的MCS（调制编码方案），本质上取"木桶的短板"。这正是混合模式（PTM+PTP）的设计初衷——基础层用保守MCS覆盖所有UE，增强层用激进MCS单独服务信道好的UE。
Q: MBS的组调度和普通调度有什么区别？
A: 普通调度用C-RNTI（每个UE一个）加扰PDCCH，UE只解码属于自己的调度信息。MBS的组调度用G-RNTI加扰，所有接收同一MBS会话的UE都解码这个PDCCH。一个gNB可以同时有多个G-RNTI，对应不同的MBS会话。
Q: 为什么MBS在R17才引入，不更早？
A: 5G第一个版本（R15）专注于eMBB基础能力，多播广播优先级不高。随着5G应用场景扩展到V2X、公共安全、大规模IoT，多播广播成为刚需。同时，R16的URLLC基础能力为MBS的可靠性设计提供了基础。时机成熟才引入，是标准制定的务实策略。
本文由「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 等场景全覆盖。