51学通信

深度解析TS 29.244：5.34 - 5G组播与广播服务(5MBS)的N4实现

15分钟阅读

非常好，我们继续这场关于3GPP TS 29.244规范的深度探索之旅。

在前几期的内容中，我们已经穿越了PCC策略执行、会话管理、异常处理以及对边缘计算等高级特性的复杂迷宫。这些功能共同描绘了一幅5G网络作为智能、可靠连接平台的宏伟蓝图。然而，5G的演进并未止步，5G-Advanced正将网络的“神经末梢”向更广泛的“一对多”通信场景延伸，这就是5G组播与广播服务（5MBS, 5G Multicast and Broadcast Service）。

传统的IPTV支持让我们看到了5G在承载组播业务方面的潜力，但5MBS将其提升到了一个全新的战略高度。它不再局限于电视直播，而是为车联网（V2X）中的车辆软件更新、体育场馆内的赛事多角度直播、公共安全领域的紧急信息发布、乃至元宇宙（XR）应用中的大规模场景同步等，提供了一个原生、高效、可管可控的数据分发框架。

为了实现这一目标，5G架构引入了新的网络功能（MB-SMF和MB-UPF）和新的参考点（N4mb）。本篇文章将聚焦于TS 29.244规范的核心章节5.34，深入剖析PFCP协议是如何通过在N4mb和N4接口上的扩展，将5MBS的复杂逻辑转化为用户面上精确的数据流建立、分发和控制动作的。

我们将再次回到“未来制造”的智慧工厂。今天，工厂决定利用5G网络向园区内所有的自动导引车（AGV）推送一次关键的固件升级包，以提升其运行效率。网络工程师小明需要确保这次大规模的软件分发既高效又不影响产线正常运行。我们将跟随他的配置过程，看看PFCP协议是如何调度MB-UPF建立组播会话，并指挥各个AGV所连接的UPF加入该数据流，最终完成这次关键任务的。

深度解析TS 29.244：5.34 - 5G组播与广播服务(5MBS)的N4实现

本文技术原理深度参考了3GPP TS 29.244 V18.9.0 (2025-03) Release 18规范中，关于“5.34 Support of 5G Multicast and Broadcast Service”的核心章节。

1. 5MBS的“总指挥部”：N4mb接口与MB-SMF/MB-UPF

5MBS的核心思想是在核心网层面建立一个“分发中心”，即MB-UPF（组播/广播用户面功能），由MB-SMF（组播/广播会话管理功能）进行统一控制。这两者之间的接口，就是专为5MBS定义的N4mb接口。一个5MBS业务，对应一个MBS会话，MB-SMF会为这个MBS会话在MB-UPF上建立一个PFCP会话。

1.1 PFCP在N4mb上的核心扩展 (5.34.2.1A)

为了指挥MB-UPF处理组播/广播业务，PFCP引入了一系列N4mb专用的标志位和参数：

  • JMBSSM (Join MBS Session SSM) 标志位：在MBS Session N4mb Control Information IE中设置。它指示MB-UPF加入上游（N6mb接口）的源特定组播（SSM）树，从而开始从内容源（如AF/AS）接收MBS数据。
  • PLLSSM (Provide Low Layer Source Specific Multicast address) 标志位：同样在MBS Session N4mb Control Information IE中设置。它请求MB-UPF为该MBS会话分配一个用于下层组播传输的地址（LLSSM）和一个公共隧道端点标识符（C-TEID）。这个LLSSM地址将用于在N3mb（到RAN）或N19mb（到UPF）接口上通过IP组播方式分发数据。
  • FSSM (Forward packets to lower layer SSM) 标志位：在Apply Action IE中设置。它指示MB-UPF将接收到的MBS数据，使用其先前分配的LLSSM地址和C-TEID，通过组播传输方式向下游转发。
  • MBSU (Forward and replicate MBS data using Unicast transport) 标志位：同样在Apply Action IE中设置。它指示MB-UPF将MBS数据复制多份，并通过单播GTP-U隧道分别发送给多个下游节点（如RAN或UPF）。

1.2 MBS会话的建立与转发指令 (5.34.2.2)

当MB-SMF需要为一个新的MBS业务（如下载AGV固件）建立会话时，它会向MB-UPF发送一条PFCP Session Establishment Request消息，其中包含了周密的部署指令：

  1. 会话标识：通过MBS Session N4mb Control Information IE，提供MBS Session Identifier（如TMGI），如果是位置相关的业务，还需提供Area Session ID。
  2. 上游连接：
    • 如果内容源使用组播分发，MB-SMF会设置JMBSSM标志，并在下行PDR中提供IP Multicast Addressing Info IE，让MB-UPF去“订阅”上游的组播流。
    • 如果内容源使用单播，MB-SMF则会在下行PDR或Traffic Endpoint中请求MB-UPF分配一个Local Ingress Tunnel，用于接收来自N6mb或Nmb9接口的单播数据。
  3. 下游分发：
    • 组播分发：如果计划使用N3mb/N19mb组播，MB-SMF会设置PLLSSM标志，请求MB-UPF分配LLSSM地址。同时，FAR的Apply Action会被设置为FSSM。
    • 单播分发：如果计划使用单播，且下游节点的F-TEID此时已知（例如在会话恢复场景），FAR的Apply Action可以设置为MBSU，并附上Add MBS Unicast Parameters IE，其中包含具体的下游F-TEID列表。
    • 初始状态：通常在会话初建时，下游节点未知，因此Apply Action常被设置为DROP或BUFF，等待后续的更新。
  4. QoS处理：MB-SMF会为每个MBS QoS流创建QER，并通过IQFISN标志位指示MB-UPF在下行数据包的PDU Session Container中插入DL MBS QFI序列号。

1.3 资源优化：会话的(去)激活与(非)活跃检测 (5.34.2.3, 5.34.2.4)

为了节省网络资源，当一个MBS频道长时间没有用户或没有内容时，可以被临时去激活。

  • 不活跃检测：MB-SMF可以像普通PDU会话一样，通过User Plane Inactivity Timer IE指示MB-UPF监控MBS会话的下行流量，并在超时后上报不活跃事件。
  • 去激活：收到不活跃报告或AF的指令后，MB-SMF会发送PFCP Session Modification Request，将FAR的Apply Action从FSSM和/或MBSU修改为BUFF和NOCP（等待数据到达时激活），或者直接修改为DROP。
  • 再激活：当MB-UPF的缓冲区收到新的下行数据包时，NOCP标志会触发它向MB-SMF发送Downlink Data Report。MB-SMF收到报告或AF的指令后，再通过PFCP Session Modification Request将Apply Action改回FSSM和/或MBSU，恢复数据分发。

2. 用户的“最后一公里”：N4接口与PDU会话关联

当一个UE（如一台AGV）决定加入一个MBS会话时，它会通过其已有的PDU会话发送信令。SMF收到请求后，需要指示为该PDU会话服务的UPF去“接入”MBS的数据流。这个过程通过常规的N4接口完成。

2.1 核心机制：将PDU会话关联到MBS会话 (5.34.3.2)

SMF通过PFCP Session Establishment/Modification Request消息，为用户的PDU会话添加专门用于接收MBS流量的规则。

  1. 标识MBS会话：SMF在请求中包含MBS Session N4 Control Information IE，其中指明了要加入的MBS Session Identifier和Area Session ID。
  2. 创建DL PDR：SMF创建一条新的下行PDR，其PDI中的关键匹配字段就是**MBS Session Identifier和Area Session ID**。这条PDR的作用就是告诉UPF：“凡是带有这个MBS标识的数据包，都属于这个PDU会话的流量”。
  3. 连接MB-UPF：
    • 组播方式：如果MB-UPF使用N19mb组播分发，SMF会在MBS Session N4 Control Information IE中提供Multicast Transport Information（包含了从MB-SMF处获得的LLSSM地址和C-TEID）。UPF收到后，就会发送IGMP JOIN请求，加入这个组播树，开始接收数据。
    • 单播方式：如果使用N19mb单播，SMF会在DL PDR中请求UPF分配一个本地F-TEID（通过设置CHOOSE标志）。UPF分配后会在响应中返回这个F-TEID。
  4. QoS映射：SMF可能会为不同的MBS QoS流创建不同的DL PDR，并关联不同的QER。QER中可以包含一个新的QFI，指示UPF将从MB-UPF收到的MBS QoS流的QFI，替换为该PDU会话中为其分配的**关联QoS流（Associated QoS Flow）**的QFI。
  5. UPF的响应与状态同步：UPF在响应消息中，会通过MBS Session N4 Information IE向SMF报告其操作结果：
    • NN19DT (New N19mb Downlink Tunnel) 标志位：如果UPF为N19mb单播分配了一个新的F-TEID（因为它是第一个加入该MBS会话的用户），该位置“1”。SMF得知后，就需要将这个新的F-TEID上报给MB-SMF，以便MB-UPF开始向这个地址发送数据。
    • JMTI (Joined N19mb Multicast Tree Indication) 标志位：如果UPF成功加入了N19mb的组播树，该位置“1”。
    • N19DTR (N19mb Downlink Tunnel Removal) 标志位：当最后一个用户离开MBS会话，UPF准备拆除N19mb隧道时，该位置“1”，通知SMF去通知MB-SMF停止向该隧道发流。

场景代入：为AGV推送固件更新

  1. MBS会话建立 (N4mb)：
    • MB-SMF为“AGV固件更新”业务（TMGI: 1001）选择一台MB-UPF，并发送PFCP Session Establishment Request。
    • 请求中设置PLLSSM=1（请求分配N19mb组播地址）和JMBSSM=1（请求加入上游N6mb组播）。
    • FAR的Apply Action初始设置为DROP。
  2. AGV加入 (N4)：
    • 园区内的AGV-A发起加入TMGI: 1001的请求。请求到达其服务的SMF-A。
    • SMF-A向服务AGV-A的UPF-A发送PFCP Session Modification Request，其中包含MBS Session N4 Control Information（TMGI=1001）和从MB-SMF处获得的N19mb组播信息。
    • 请求中创建一条DL PDR，PDI中匹配MBS Session Identifier为1001。
    • UPF-A收到后，发送IGMP Join加入MB-UPF的N19mb组播树，并在响应中设置JMTI=1。
  3. 开始分发：
    • 固件更新开始。MB-SMF修改MB-UPF上的FAR，将Apply Action设为FSSM。
    • MB-UPF开始将固件数据包通过N19mb组播分发。
    • UPF-A收到组播包，匹配DL PDR，复制一份并发往AGV-A。园区内其他加入该业务的AGV（可能连接在不同的UPF上），也以同样的方式接收数据。整个过程，固件包在核心网中只传输了一份，大大节省了带宽。

总结

5G组播与广播服务（5MBS）是5G网络迈向高效“一对多”通信的关键一步。PFCP协议通过在N4和引入新的N4mb接口上的协同扩展，为其提供了坚实的用户面实现方案：

  • N4mb接口：作为MB-SMF与MB-UPF之间的控制通道，它通过JMBSSM、PLLSSM等新标志，实现了对上游内容源的接入和下游分发路径（组播或单播）的建立与管理。
  • N4接口：作为SMF与UPF之间的常规接口，它通过引入基于MBS Session Identifier的新PDR匹配规则，以及MBS Session N4 Control/Information等IE，实现了单个PDU会话与宏观MBS会话的动态关联与解关联。
  • 双层会话模型：5MBS的实现巧妙地运用了PFCP的双层会话模型。MB-SMF管理着宏观的、业务级别的MBS PFCP会话；而各个SMF则管理着微观的、用户级别的PDU PFCP会话。两者通过N19mb接口在用户面连接，并通过SMF与MB-SMF之间的控制面交互（经由PCF/MBSF）进行策略协同，共同完成了从内容源到每个终端的高效数据分发。

这些机制使得5G网络能够以一种原生、可扩展、可运营的方式，支持从大规模媒体分发到关键物联网通信的各类组播/广播应用，为5G的未来发展打开了新的想象空间。😊

关系图谱