# 5G MBS多播会话加入与建立信令全链拆解（TS 23.247） > 面向海量终端的点对多点（Point-to-Multipoint, PTM）内容分发，是5G系统区别于纯单播架构的关键能力。3GPP在Release 17引入了5G MBS（Multicast and Broadcast Services），并在R18/R19持续增强。本文聚焦**TS 23.247 clause 7.2.1.3「Multicast session join and session establishment procedure」**这一核心信令流程，逐消息拆解MBS会话从AF创建、UE加入到空口PTM分发的完整链路，并厘清5GC Shared Delivery与5GC Individual Delivery两条数据平面的本质区别。 --- ## 一、为什么5G MBS不复用4G eMBMS 4G LTE时代的eMBMS依赖**MBSFN（Multimedia Broadcast Multicast Single Frequency Network）**——要求服务区内多个eNB空口严格同步、联合调度，才能在物理层形成单频网增益。这种"刚性同步"带来了三个工程痛点：调度灵活性差、部署复杂、难以适配5G差异化的QoS需求（如URLLC的低时延高可靠、IPTV的高吞吐）。 5G MBS的设计哲学（见Samsung等厂商在SA2的贡献）是**最大化复用现有5GC网元**，只新增两个网元： - **MB-SMF（Multicast/Broadcast Session Management Function）**：类比单播SMF，负责MBS会话生命周期管理、QoS策略下发、TMGI分配。 - **MB-UPF（Multicast/Broadcast User Plane Function）**：类比单播UPF，作为MBS数据进入5GS的锚点，负责组播分发的数据复制。 其余能力由现有AMF、SMF、UPF、NEF、UDM、PCF、NRF"软件升级"承担。RAN侧彻底放弃MBSFN，改由**每个gNB独立调度**MBS数据，何时、如何发送完全由gNB自主决策，并引入HARQ快速重传、PTP/PTM动态切换、基于序列号（SN）同步的无损切换。下表给出4G/5G组播架构的关键差异。 | 维度 | 4G eMBMS / MBSFN | 5G MBS | |------|------------------|--------| | 控制面网元 | BM-SC + MBMS-GW | MB-SMF（复用SMF框架） | | 用户面网元 | MBMS-GW + eNB | MB-UPF + UPF（5GC Individual回退） | | 空口同步 | 多eNB物理层MBSFN同步 | gNB独立调度 + SN同步 | | 重传机制 | 基本无HARQ | HARQ（PTP/PTM）+ ARQ可选 | | UE状态 | 仅RRC_CONNECTED | R18起支持RRC_INACTIVE接收 | | 会话模型 | 承载级 | MBS会话 + 关联PDU会话 | --- ## 二、关键网元、接口与TMGI标识 5G MBS在架构上引入了一组新的参考点和标识符，理解它们是读懂信令的前提。 **新增/扩展接口：** - **Nmb（MB-SMF ↔ MB-UPF）**：本质仍是PFCP（N4），用于MB-SMF配置MB-UPF的组播分发规则。 - **Nmbsmf**：MB-SMF对外SBI服务，包含`Nmbsmf_TMGI_Allocate`、`Nmbsmf_MBSSession_Create`、`Nmbsmf_MBSSession_ContextStatusSubscribe`、`Nmbsmf_MBSSession_ContextUpdate`等操作。 - **N6mb**：内容源（AF或MBSTF）→ MB-UPF的入口隧道。 - **N3mb**：MB-UPF → NG-RAN的**共享分发隧道**（5GC Shared Delivery），每个MBS会话、每个gNB仅一条。 - **N19mb**：MB-UPF → UPF(PSA)的**独立分发隧道**（5GC Individual Delivery回退路径），每个MBS会话、每个UPF仅一条。 **TMGI（Temporary Mobile Group Identity）：** 复用自EPS eMBMS，作为MBS Session ID最常用的形式。其结构如下： ```text classDiagram class TMGI { +总长度: 48 bit (6 octet) } class "PLMN ID (24 bit)" { MCC + MNC 标识提供MBS服务的归属PLMN } class "MBS Service ID (24 bit)" { 标识具体的MBS服务流 } class "MBS Service Set ID (2 bit)" { 位于MBS Service ID高位 供NG-RAN识别共址会话 用于PTP/PTM资源共享分组 } class "Flow Identifier (22 bit)" { 具体的MBS数据流标识 } TMGI --> "PLMN ID (24 bit)" TMGI --> "MBS Service ID (24 bit)" "MBS Service ID (24 bit)" --> "MBS Service Set ID (2 bit)" "MBS Service ID (24 bit)" --> "Flow Identifier (22 bit)" ``` MBS Session ID除了TMGI，也可以是**SSM（Source-Specific Multicast，源特定组播地址+源IP）**——当AF是IP组播源时，MB-UPF直接用SSM加入内容提供商的组播树，无需分配TMGI。两种标识的选择影响信令走向（见FAQ）。 --- ## 三、MBS会话创建流程（AF触发，clause 7.1.1.2） UE加入之前，MBS会话需先在5GC"注册"。AF通过NEF/MBSF触发**MBS Session Creation without PCC**（TMGI分配 + 会话创建），其逻辑如下： ```mermaid flowchart TD A[AF: 发起MBS业务] --> B["Nnef_MBSTMGI_Allocate Request
(TMGI数量, MBS服务区)"] B --> C[NEF/MBSF: AF鉴权 + 地理区域转换] C --> D[NRF: 发现/选择MB-SMF] D --> E["Nmbsmf_TMGI_Allocate
MB-SMF分配TMGI + 有效期"] E --> F["AF: Service Announcement
向UE广播TMGI/SSM/服务区/起止时间"] F --> G["Nnef_MBSSession_Create Request
(MBS Service Type, MBS Service Info,
Any UE指示, 服务区, start/end time)"] G --> H[NEF/MBSF: 内容商鉴权 + 选MB-SMF] H --> I["Nmbsmf_MBSSession_Create
MB-SMF本地推导QoS参数"] I --> J[MB-SMF选择MB-UPF
预留入口资源/N3mb隧道端点] J --> K["MB-UPF: 选择入口地址IP+Port
或加入SSM组播树"] K --> L["Nnef_MBSSession_Create Response
(TMGI, 入口地址, 区域缩减信息)"] L --> M{业务类型} M -->|Broadcast| N[继续7.3.1: 向AMF/gNB预留广播资源] M -->|Multicast| O["等待UE Join (clause 7.2.1)
会话状态可为Inactive"] ``` 几个设计要点值得标注： 1. **TMGI分配与会话创建解耦**：AF可先要TMGI（用于提前向UE公告），再正式创建会话（step 1-6 与 step 8-22分离）。这避免了"业务开播瞬间海量UE同时Join被拒"的信令风暴——SMF可在start time前就接受Join并告诉UE开播时间（clause 7.2.1.3 step 4的back-off机制）。 2. **服务区裁剪**：若AF请求的MBS服务区超出单个MB-SMF的能力范围，NEF/MBSF会**拒绝**或**拆分**为多个服务区组（step 3/10）。响应中携带"Information of area reduction"，让AF感知实际覆盖范围。 3. **MB-UPF入站方式二选一**：AF请求入口地址时，MB-UPF分配IP+Port（拉模式）；AF提供SSM时，MB-UPF加入组播树（推模式）。 --- ## 四、多播会话加入与建立信令时序（核心，clause 7.2.1.3） 这是本文最核心的流程。UE通过**关联PDU会话（Associated PDU Session）**携带TMGI发起Join，网络据此建立MBS会话上下文并打通数据平面。完整时序如下： ```text sequenceDiagram autonumber participant UE participant RAN as NG-RAN (gNB) participant AMF participant SMF participant NRF participant UDM participant MB-SMF participant MB-UPF participant UPF as UPF(PSA) Note over UE,UPF: 前提: MBS会话已由AF创建(clause 7.1.1.2), UE已注册 UE->>SMF: PDU Session Modification Request
(MBS Session ID[=TMGI] + Join请求)
经AMF透传(N1 SM container) Note over SMF: 若无MBS会话上下文, SMF需发现MB-SMF SMF->>NRF: 查询MB-SMF (按MBS Session ID/服务区) NRF-->>SMF: MB-SMF profile (或空) SMF->>MB-SMF: Nmbsmf_MBSSession_ContextStatusSubscribe(MBS Session ID) Note over MB-SMF: 若是任意SMF首次订阅该会话=
判定为"首个UE加入", 触发MB-UPF加入内容组播树 MB-SMF->>MB-UPF: [条件] 加入AF/MBSF组播树 MB-SMF-->>SMF: 响应(多播QoS flow信息, start time,
会话状态Active/Inactive, Any UE指示,
多播DL隧道信息, 多播会话安全上下文) SMF->>UDM: 获取MBS签约数据(鉴权) Note over SMF: 鉴权: UE是否签约多播服务 +
TMGI是否在签约内或Any UE指示成立 SMF->>AMF: Nsmf_PDUSession_UpdateSMContext Response
(N2 SM: PDU Session ID, MBS Session ID,
单播QoS flow↔多播QoS flow映射;
N1 SM: PDU Session Modification Command) AMF->>RAN: N2 PDU Session Resource Setup/Modify
(N2 SM信息 + N1 container) Note over RAN: gNB判定: 是否支持MBS?
支持→建立MBS会话上下文+MRB; 不支持→回退单播 RAN<->>UE: AN特定信令(RRC Reconfig)
配置多播无线承载MRB, 下发N1 container RAN-->>AMF: PDU Session Modification Response
(N2 SM: MBS支持指示,
RRC_INACTIVE接收能力指示) AMF->>SMF: Nsmf_PDUSession_UpdateSMContext Request(N2 SM) Note over SMF: 根据gNB是否支持MBS, 决定数据平面模式 rect rgb(230,245,230) Note over MB-UPF,RAN: 模式A: 5GC Shared MBS Delivery (gNB支持MBS) SMF->>MB-SMF: [7.2.1.4] 建立N3mb共享隧道 MB-SMF->>MB-UPF: 配置N3mb隧道端点 MB-UPF->>RAN: 多播PDU经N3mb共享隧道
(每会话每gNB仅一条) RAN->>UE: MBS Radio Bearer传输
(动态选择PTP或PTM) end rect rgb(245,230,230) Note over MB-UPF,UPF: 模式B: 5GC Individual MBS Delivery (gNB不支持MBS, 回退单播) SMF->>UPF: 请求创建N19mb隧道(MBS Session ID) UPF-->>SMF: DL N19mb隧道端点(新建标识) SMF->>MB-SMF: Nmbsmf_MBSSession_ContextUpdate(DL隧道信息) MB-SMF->>MB-UPF: 配置向UPF的N19mb传输 MB-UPF->>UPF: 多播PDU经N19mb隧道 UPF->>RAN: 经关联PDU会话的N3单播隧道转发 RAN->>UE: 关联QoS flow的单播无线承载传输 end ``` ### 4.1 逐消息IE拆解 **① UE的Join请求（N1 SM容器）** UE复用单播PDU会话的NAS信令通道发起Join，核心是**PDU Session Modification Request**中追加： - `MBS Session ID`（TMGI 或 SSM）——可一次携带多个，表示同时加入多个多播组； - `Join请求`指示。 若UE还没有合适的关联PDU会话，则改发**PDU Session Establishment Request**携带TMGI+Join，网络先执行TS 23.502 clause 4.3.2.2的步骤4-10建立PDU会话，再继续MBS流程。这种"借用PDU会话做控制通道"的设计，使得MBS不必另起一套NAS信令体系。 **② SMF发现MB-SMF（NRF）** SMF收到带TMGI的请求后，若本地无MBS会话上下文，则向NRF查询。MB-SMF在注册时已声明其支持的TMGI范围或MBS服务区（clause 7.1.2）。**NRF返回空profile**是常见异常：SMF可自行选一个MB-SMF并请求其配置该多播会话，或直接拒绝Join并回带cause value。 **③ Nmbsmf_MBSSession_ContextStatusSubscribe（控制面核心）** SMF向MB-SMF订阅MBS会话上下文，MB-SMF响应中返回的IE是后续所有动作的依据： | IE | 含义 | 用途 | |----|------|------| | 多播QoS flow信息 | 多播QoS流的QoS profile（5QI、GBR参数等） | 供SMF映射到关联PDU会话的单播QoS flow | | start time | 会话开播时间 | 早到的Join可被接受并回传start time | | 会话状态(Active/Inactive) | 多播会话当前是否在传输数据 | 决定是否立即配置空口无线资源（step 7a） | | Any UE指示 | 该多播会话是否"对任意UE开放" | 鉴权时绕过逐UE TMGI签约检查 | | 多播DL隧道信息 | N3mb隧道端点/组播地址 | Shared Delivery数据平面使用 | | 多播会话安全上下文 | 应用层安全密钥材料 | RAN透明，端到端UE↔业务层加密 | 关键设计：**MB-SMF通过"是否任意SMF首次订阅"来判定首个UE加入**。首个UE加入时，若MB-UPF尚未在创建阶段加入内容组播树，MB-SMF此刻才指示MB-UPF加入——这是典型的**延迟加入（deferred join）**，避免空会话长期占用组播树资源。 **④ UDM鉴权** SMF从UDM取`MBS subscription data`，与Any UE指示联合判断： - UE已签约多播服务 **且** TMGI在签约列表内 → 授权； - 或收到Any UE指示（开放业务）→ 授权。 鉴权失败、Join在Inactive期但策略拒绝、或UE数达上限，SMF回`PDU Session Modification Reject`，并可能带**back-off timer**和MBS assistance info。 **⑤ N2 SM信息（SMF→AMF→gNB）** 这是控制面与无线面的桥梁，关键IE： - `PDU Session ID` + `MBS Session ID`：建立PDU会话与MBS会话的关联； - **单播QoS flow ↔ 多播QoS flow映射（associated QoS flow information）**：SMF将多播QoS flow的QFI与PDU会话已用QFI比对，分配未占用的QFI给"对应单播QoS flow"——这是Individual Delivery回退的关键，让gNB在不支持MBS时仍能用单播承载传同样的QoS； - MBS assistance info（来自UDM签约辅助信息）。 **⑥ gNB的MBS能力判定与响应（N2 SM回传）** gNB在`PDU Session Modification Response`中回带： - **MBS支持指示**：决定SMF走Shared还是Individual数据平面； - **RRC_INACTIVE接收能力指示**（R18）：若gNB支持多播且允许RRC_INACTIVE态UE接收，回传该指示，SMF据此后续可不下发专用RRC配置。 --- ## 五、两条数据平面的本质区别与决策 5G MBS数据从MB-UPF到UE有两条路径，这是理解整个机制的钥匙。 | 维度 | 5GC Shared Delivery | 5GC Individual Delivery | |------|---------------------|--------------------------| | 触发条件 | gNB**支持**MBS | gNB**不支持**MBS（回退） | | CN隧道 | N3mb（MB-UPF→gNB） | N19mb（MB-UPF→UPF）+ N3（UPF→gNB） | | 隧道粒度 | 每MBS会话、每gNB一条（**共享**） | 每MBS会话、每UPF一条（组内PDU会话共享N19mb，但N3段仍单播） | | 空口承载 | MBS Radio Bearer（PTP/PTM动态选择） | 关联单播QoS flow的普通DRB | | MB-UPF负担 | 每gNB复制一份 | 每UPF复制一份，UPF再逐PDU会话复制 | | 资源效率 | 高（PTM一次发多UE） | 低（实质单播），但兼容老旧gNB | | 与SMF交互 | 走clause 7.2.1.4建N3mb | 走step 11a-11e建N19mb + 配置UPF转发 | 决策流（SMF视角）： ```mermaid flowchart TD S[SMF收到gNB的MBS支持指示] --> T{gNB支持MBS?} T -->|是| SH[5GC Shared Delivery] T -->|否, 但PDU会话含对应单播QoS flow| IN[5GC Individual Delivery] T -->|否, 且无单播QoS flow| RJ[UE Join失败/RAN拒绝资源建立] SH --> SH1[clause 7.2.1.4 建立N3mb共享隧道] SH1 --> SH2[MB-UPF每gNB复制一份数据] SH2 --> SH3[gNB用MRB, 动态选PTP/PTM, 可RRC_INACTIVE接收] IN --> IN1[step 11a: SMF→UPF建N19mb隧道端点] IN1 --> IN2[step 11b-d: SMF→MB-SMF→MB-UPF配置传输] IN2 --> IN3[step 11e: SMF配置UPF在PDU会话内转发] IN3 --> IN4[UPF经N3单播隧道→gNB→UE单播承载] ``` 值得强调的是：**N19mb本身仍是"组内共享"的**（每个UPF一条），真正的单播复制发生在UPF经N3向gNB转发时。这种分层设计让MB-UPF不感知每UE，由UPF承担逐会话复制——巧妙复用了现有UPF的单播能力。 --- ## 六、MBS会话状态转换 多播会话（区别于广播会话）具有显式的Active/Inactive状态机，这是早到Join和动态激活的基础。 ```mermaid stateDiagram-v2 [*] --> Created: AF创建会话(7.1.1.2)
分配TMGI/入口资源 Created --> Inactive: 创建完成默认Inactive
(或多播会话等待激活) Inactive --> Active: MBS Session Update(7.1.1.6)
AF激活/首个UE Join后激活 Active --> Inactive: 会话去激活/数据暂停 Inactive --> Deleted: MBS Session Deletion(7.1.1.4) Active --> Deleted: MBS Session Deletion Deleted --> [*] note right of Active 数据正在MB-UPF→RAN/UPF传输 gNB配置MRB无线资源 已Join的UE接收PTM/PTP数据 end note note right of Inactive UE可Join(被接受)但不传数据 start time未到时UE可提前Join gNB不配置/释放无线资源 end note ``` UE侧则维护"是否已Join某MBS会话"的本地状态，并与关联PDU会话生命周期绑定——PDU会话释放时，其关联的所有MBS会话成员关系一并解除。 --- ## 七、抓包识别与实战排错 ### 7.1 抓包如何识别这个流程 | 接口 | 协议 | 识别特征 | |------|------|----------| | UE↔SMF (N1) | 5G NAS | `PDU Session Modification Request/Command`中携带`MBS Session ID`（TMGI/SSM）IE | | SMF↔AMF (N11) | HTTP/2 SBI | `nsmf_pdusession` 的 `UpdateSmContext`，N2 SM容器含MBS Session ID与QoS flow映射 | | SMF↔MB-SMF | HTTP/2 SBI | `nmbsmf_mbssession` 服务：`ContextStatusSubscribe`/`ContextUpdate` | | SMF/MB-SMF↔MB-UPF | PFCP (N4) | PFCP Session Establishment含MBS相关IE（MBS flags、组播分发规则） | | MB-UPF↔gNB | GTP-U (N3mb) | MBS组播隧道，TFT/TEID关联MBS Session ID | | MB-UPF↔UPF | GTP-U (N19mb) | Individual Delivery回退隧道 | Wireshark 4.2+已支持5G MBS相关IE的解码（N1 NAS的MBS Session ID、SBI的nmbsmf服务）。实战中可先用 `tshark -Y "http2.headers.authority contains nmbsmf"` 快速过滤控制面SBI。 ### 7.2 常见故障点 1. **Join被拒 + back-off timer**：多为start time未到且策略要求严格开播、或单gNB已Join UE数达上限（NOTE 7：RAN拒绝PDU Session Resource setup）。排错看SMF返回的cause value与back-off时长。 2. **NRF返回空MB-SMF profile**：说明该TMGI对应会话尚未在任何MB-SMF创建，或TMGI超出所有MB-SMF注册范围。检查AF的MBS Session Creation是否成功、TMGI是否过期。 3. **gNB不支持MBS但无对应单播QoS flow**：Individual Delivery回退需要PDU会话内已有对应单播QoS flow，否则NOTE 7所述Join失败。检查SMF是否正确执行了QoS flow映射（step 5）。 4. **首个UE加入后无数据**：MB-UPF未成功加入内容组播树（SSM场景）或入口地址配置错误。检查MB-SMF在step 3的"首次订阅触发加入"逻辑、N6mb入口连通性。 5. **TMGI过期**：NEF/MBSF在分配时返回expiration time（clause 7.1.1.2 step 5），AF必须续期，否则UE用失效TMGI Join会被拒。 ## 常见问题 **Q1: MBS Multicast（多播）和MBS Broadcast（广播）有什么区别？** A：多播是"按需加入"——UE必须显式Join（本文流程），5GS仅在有兴趣UE的小区传输，支持逐UE鉴权和QoS保证，适合会议、群组业务；广播是"区域广播"——无需Join，服务区内所有UE（含未注册）均可接收，资源由创建流程直接向AMF/gNB预留（clause 7.3.1），适合直播电视、公共安全通告。 **Q2: 5GC Shared Delivery和5GC Individual Delivery到底何时切换？** A：完全由**gNB是否支持MBS**决定。gNB支持→Shared（N3mb，PTM，高效）；不支持→Individual（N19mb+N3，单播回退，兼容性）。二者可在会话级动态切换以保障业务连续性（如UE切换到不支持MBS的小区时回退单播）。 **Q3: MBS会话和PDU会话是什么关系？** A：MBS会话是独立的多播实体（由MB-SMF管理，有独立QoS flow和TMGI）；PDU会话是UE的单播通道。二者通过"关联PDU会话"耦合——UE的Join信令、Individual Delivery的数据回退、鉴权都依附于关联PDU会话。一个PDU会话可关联多个MBS会话。 **Q4: TMGI和SSM作为MBS Session ID有什么区别？** A：TMGI是3GPP定义的标识（PLMN+MBS Service ID），网络侧分配，适合内容源非IP组播的场景；SSM是标准IP组播（源IP+组地址），AF作为组播源时MB-UPF直接用SSM加入组播树，无需TMGI分配步骤。二者走不同的创建子流程，但加入流程一致（UE都需在Join中携带MBS Session ID）。 **Q5: 为什么UE要在start time之前就发Join？** A：为避免"开播瞬间海量UE同时Join"造成的SMF/MB-SMF信令风暴和拒绝（clause 7.2.1.3 NOTE 1/4）。网络允许UE提前Join并在会话Inactive时接受，回传start time，到点后统一激活数据传输。这是一种典型的信令削峰设计。 --- ## 参考来源 1. [3GPP TS 23.247 V19.x.x — Architectural enhancements for 5G multicast-broadcast services](https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3854) — clause 7.1.1.2（MBS Session Creation）、7.2.1.3（Multicast session join and establishment）、7.2.1.4（Shared delivery toward RAN） 2. [TS 23.247 Section 7.2.1.3 解读 — iTecSpec](https://itecspec.com/3gpp/23.247/s/7.2.1.3) — 多播加入流程逐步骤原文 3. [Samsung Research — 5G MBS: Unleashing the Potential of Multicast and Broadcast Communication in 5G](https://research.samsung.com/blog/5G-MBS-Unleashing-the-Potential-of-Multicast-and-Broadcast-Communication-in-5G) — 架构设计原理、Shared/Individual Delivery、PTP/PTM与R18增强 4. [ETSI TS 123 247 V17.x.x (5G MBS Stage 2)](https://www.etsi.org/deliver/etsi_ts/123200_123299/123247/) — TMGI、MBS会话模型、QoS flow映射 5. [5G-MAG — MBS Service & System Aspects](https://hub.5g-mag.com/Tech/pages/5g-multicast-broadcast-services/mbs-service-system-aspects.html) — MBSF/MBSTF服务层功能与组播树管理 --- > 本文由「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 等场景全覆盖。