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组播架构的关键差异。

二、关键网元、接口与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最常用的形式。其结构如下：

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分配 + 会话创建），其逻辑如下：

flowchart TD
    A[AF: 发起MBS业务] --> B["Nnef_MBSTMGI_Allocate Request<br/>(TMGI数量, MBS服务区)"]
    B --> C[NEF/MBSF: AF鉴权 + 地理区域转换]
    C --> D[NRF: 发现/选择MB-SMF]
    D --> E["Nmbsmf_TMGI_Allocate<br/>MB-SMF分配TMGI + 有效期"]
    E --> F["AF: Service Announcement<br/>向UE广播TMGI/SSM/服务区/起止时间"]
    F --> G["Nnef_MBSSession_Create Request<br/>(MBS Service Type, MBS Service Info,<br/>Any UE指示, 服务区, start/end time)"]
    G --> H[NEF/MBSF: 内容商鉴权 + 选MB-SMF]
    H --> I["Nmbsmf_MBSSession_Create<br/>MB-SMF本地推导QoS参数"]
    I --> J[MB-SMF选择MB-UPF<br/>预留入口资源/N3mb隧道端点]
    J --> K["MB-UPF: 选择入口地址IP+Port<br/>或加入SSM组播树"]
    K --> L["Nnef_MBSSession_Create Response<br/>(TMGI, 入口地址, 区域缩减信息)"]
    L --> M{业务类型}
    M -->|Broadcast| N[继续7.3.1: 向AMF/gNB预留广播资源]
    M -->|Multicast| O["等待UE Join (clause 7.2.1)<br/>会话状态可为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会话上下文并打通数据平面。完整时序如下：

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<br/>(MBS Session ID[=TMGI] + Join请求)<br/>经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首次订阅该会话=<br/>判定为"首个UE加入", 触发MB-UPF加入内容组播树
    MB-SMF->>MB-UPF: [条件] 加入AF/MBSF组播树
    MB-SMF-->>SMF: 响应(多播QoS flow信息, start time,<br/>会话状态Active/Inactive, Any UE指示,<br/>多播DL隧道信息, 多播会话安全上下文)
    SMF->>UDM: 获取MBS签约数据(鉴权)
    Note over SMF: 鉴权: UE是否签约多播服务 +<br/>TMGI是否在签约内或Any UE指示成立
    SMF->>AMF: Nsmf_PDUSession_UpdateSMContext Response<br/>(N2 SM: PDU Session ID, MBS Session ID,<br/>单播QoS flow↔多播QoS flow映射;<br/>N1 SM: PDU Session Modification Command)
    AMF->>RAN: N2 PDU Session Resource Setup/Modify<br/>(N2 SM信息 + N1 container)
    Note over RAN: gNB判定: 是否支持MBS?<br/>支持→建立MBS会话上下文+MRB; 不支持→回退单播
    RAN<->>UE: AN特定信令(RRC Reconfig)<br/>配置多播无线承载MRB, 下发N1 container
    RAN-->>AMF: PDU Session Modification Response<br/>(N2 SM: MBS支持指示,<br/>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共享隧道<br/>(每会话每gNB仅一条)
        RAN->>UE: MBS Radio Bearer传输<br/>(动态选择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是后续所有动作的依据：

关键设计：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有两条路径，这是理解整个机制的钥匙。

决策流（SMF视角）：

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和动态激活的基础。

stateDiagram-v2
    [*] --> Created: AF创建会话(7.1.1.2)<br/>分配TMGI/入口资源
    Created --> Inactive: 创建完成默认Inactive<br/>(或多播会话等待激活)
    Inactive --> Active: MBS Session Update(7.1.1.6)<br/>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 抓包如何识别这个流程

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 — 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 — 多播加入流程逐步骤原文
3. Samsung Research — 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) — TMGI、MBS会话模型、QoS flow映射
5. 5G-MAG — MBS Service & System Aspects — 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 等场景全覆盖。