本文技术原理深度参考了3GPP TS 38.413 V18.5.0 (2025-03) Release 18规范中，关于“8.17 Broadcast Session Management Procedures”、“8.18 Multicast Session Management Procedures”及“8.19 Timing Synchronisation Status Reporting Procedures”的核心章节，旨在为读者提供一个关于5G网络如何管理广播/多播业务以及高精度时间同步的深度洞察。

深度解析 3GPP TS 38.413：8.17-8.19 5G的群体智慧与精准节拍：广播、多播与时间同步管理

大家好，欢迎回到我们的3GPP规范深度解析系列！在探索了众多以单个用户为核心的流程之后，今天我们将把目光投向5G网络中更宏大、更具协同性的能力：群体通信与网络同步。这不仅仅是关于个体连接，更是关于网络如何组织和协调大规模的信息分发，以及如何为未来的关键应用校准其“心跳”。

本文将深入探讨三个关联紧密但功能各异的流程，它们共同构成了5G网络高级服务能力的基石：

1. 广播业务管理 (Broadcast Session Management)：如同城市应急广播系统，它能在特定地理区域内，向所有UE“喊话”，是公共预警等场景的利器。

2. 多播业务管理 (Multicast Session Management)：如同一个加密的会员频道，它能将特定内容高效地分发给一个封闭的用户群组，完美契合体育赛事直播、远程教育、车联网V2X等场景。

3. 时间同步状态报告 (Timing Synchronisation Status Reporting)：如同乐队的指挥家，它确保网络的“节拍”——时间同步——精准无误，这是实现工业自动化、远程医疗等超低时延、高可靠（URLLC）业务的生命线。

为了生动地理解这些流程，我们将构建一个大型城市马拉松的综合保障场景：

• 主角：赛事总指挥Eva，她需要利用5G网络确保赛事安全、高效地进行。

• 网络节点：覆盖赛道的 gNB-Marathon，以及核心网的“大脑” AMF-CityCenter，还有专门负责多播/广播业务的MB-SMF和负责时间敏感业务的TSCTSF。

我们将通过Eva在赛事保障中的三个关键决策，来逐一剖析这三大流程：

• 场景一（广播）：Eva需要向赛道沿线所有公众发布紧急天气预警。

• 场景二（多播）：Eva需要向所有裁判和安保人员的专用设备，实时下发高优先级的调度指令和选手位置信息。

• 场景三（时间同步）：赛道上的高精度计时和终点线的高速摄像系统，需要网络提供纳秒级的时间同步保证。

现在，让我们跟随Eva的指挥棒，深入探索5G网络如何从“一对一”的服务，升级到“一对多”的协同，并为这一切校准最精准的“节拍”。

---

1. Broadcast Session Management Procedures (广播会话管理流程)

广播业务（MBS Broadcast）是5G中实现“广而告之”的最高效手段。它允许网络在特定地理区域内，向所有能够接收信号的UE发送相同的数据，无需关心接收者是谁，也无需为每个UE建立单独的连接。

1.1 Broadcast Session Setup (广播会话建立)

这是为一项广播业务“预留频道”的初始步骤。

8.17.1.1 General

The purpose of the Broadcast Session Setup procedure is to request the NG-RAN node to setup MBS session resources for a broadcast MBS session. The procedure uses non-UE associated signalling.

场景引入：

马拉松赛事开始前，Eva需要确保一个紧急预警通道随时可用。她通过赛事指挥系统，请求5G网络在整个赛道区域预留一个用于广播的MBS会话。这个请求最终由核心网的MB-SMF处理，并通过AMF-CityCenter向gNB-Marathon下达。

The AMF initiates the procedure by sending a BROADCAST SESSION SETUP REQUEST message to the NG-RAN node. If the NG-RAN node accepts all the MBS QoS flows in the MBS session in at least in one of its cells, the NG-RAN node responds with the BROADCAST SESSION SETUP RESPONSE message.

流程如图“Figure 8.17.1.2-1: Broadcast Session Setup, successful operation”所示，AMF发送BROADCAST SESSION SETUP REQUEST，gNB若能满足资源要求，则回复BROADCAST SESSION SETUP RESPONSE。

REQUEST消息的核心IE：

• MBS Session ID: 广播会话的唯一标识，通常包含一个TMGI（临时移动组标识），就像是这个广播“频道”的号码。

• S-NSSAI: 指明这个广播业务属于哪个网络切片。

• MBS Service Area: 定义了广播的地理覆盖范围，可以由一系列小区ID或TAI组成。对于马拉松场景，这里会包含赛道沿线所有小区的列表。

• MBS Session Setup Request Transfer: 这是一个透明容器，里面装着来自MB-SMF的更详细的QoS要求等信息，AMF只做转发。

gNB收到请求后，会检查自己是否有足够的无线资源（如下行带宽、广播信道资源）来承载这个广播业务。如果可以，就在内部预留资源，并回复RESPONSE。如果资源不足，则回复BROADCAST SESSION SETUP FAILURE。

1.2 Broadcast Session Modification, Release & Transport

这些流程是对已建立广播会话的生命周期管理：

• Modification (修改) (8.17.2): 用于更新已建立会话的参数。例如，马拉松路线临时变更，Eva需要更新MBS Service Area。AMF会发送BROADCAST SESSION MODIFICATION REQUEST来完成。

• Release (释放) (8.17.3 & 8.17.4): 用于在业务结束后释放资源。赛事结束后，AMF会发送BROADCAST SESSION RELEASE REQUEST来“关闭频道”。Release Required则是gNB在资源紧张时，主动请求AMF释放广播会话。

• Transport (传输) (8.17.5): 这个流程用于为广播会话建立**用户面（NG-U）**的传输隧道。前面的Setup主要是在控制面预留资源，而Transport流程则是真正打通从核心网UPF到gNB的数据管道，以便广播数据（如预警文本）能够被实际传输。

---

2. Multicast Session Management Procedures (多播会话管理流程)

与广播的“普发”不同，多播（MBS Multicast）是面向特定用户群体的“组发”。只有加入（join）了该多播组的UE，才能接收数据。

2.1 Distribution Setup & Release (分发建立与释放)

这是为多播会话建立和拆除核心网到接入网的“主干管道”（Distribution Tree）的流程。

8.18.1.1 General

The purpose of the Distribution Setup procedure is to assign NG-U resources for a multicast MBS session.

场景引入：

Eva需要为所有裁判和安保人员的专用设备建立一个内部通信频道，用于实时下发指令。这个请求由MB-SMF处理，并通过AMF向gNB发起DISTRIBUTION SETUP REQUEST。

这个流程（如图“Figure 8.18.1.2-1”）的核心是为这个多播组建立一个高效的NG-U传输路径。数据可以从一个UPF，通过IP多播或共享的单播隧道，分发到所有需要广播该业务的gNB。DISTRIBUTION SETUP就是建立这条路径，而DISTRIBUTION RELEASE（8.18.2）则是在业务结束后拆除它。

2.2 Multicast Session Activation & Deactivation (多播会话激活与去激活)

这是多播业务相比广播业务一个非常重要的区别和优势：按需激活。

8.18.3.1 General

The purpose of the Multicast Session Activation procedure is to request a NG-RAN node to activate the MBS session resources of a multicast MBS session.

分发管道（Distribution）建立后，gNB只是知道了有这么一个多播会话存在，但并不会立即在空口上分配资源去广播它。只有当真正有数据需要下发时，AMF才会发送MULTICAST SESSION ACTIVATION REQUEST（如图“Figure 8.18.3.2-1”）。

gNB收到激活指令后，才会开始在空口上分配物理信道资源，并通知已加入该组的UE准备接收数据。

• Activation (激活): 赛事开始前，Eva通过指挥系统激活裁判频道，开始下发指令。AMF发送ACTIVATION REQUEST。

• Deactivation (去激活) (8.18.4): 在赛事平稳进行、没有指令下发的时段，为了节省空口资源，Eva可以“暂停”该频道。AMF会发送MULTICAST SESSION DEACTIVATION REQUEST。gNB会暂停空口广播，但UE与该多播会话的关联关系仍然保持。

这种“激活/去激活”机制，使得多播业务可以非常灵活地使用无线资源，只在必要时占用空口，大大提升了频谱效率。

2.3 Multicast Session Update (多播会话更新)

8.18.5.1 General

The purpose of the Multicast Session Update procedure is to request the NG-RAN node to update the NG-RAN MBS session resources or area related to a multicast MBS session.

这个流程（如图“Figure 8.18.5.2-1”）用于在线更新一个正在进行的多播会话。

场景演绎：

赛事进行中，终点线区域突然需要增加安保人员。Eva需要将这个多播频道扩展到终点区域。指挥系统会触发AMF向gNB发送MULTICAST SESSION UPDATE REQUEST，其中可能包含更新的MBS Service Area，或者更新的QoS要求（MBS QoS Flows To Be Setup or Modify List）。gNB收到后会动态调整其广播覆盖和资源分配。

---

3. Timing Synchronisation Status Reporting Procedures (时间同步状态报告流程)

这是一个与具体业务无关，但对高精度业务至关重要的底层支撑流程。它服务于5G的TSC（Time-Sensitive Communication）能力。

3.1 通用流程 (General)

8.19.1.1 General

The purpose of the Timing Synchronisation Status procedure is to enable the AMF to request the NG-RAN node to start or stop reporting of RAN timing synchronisation status information…

场景引入：

马拉松的终点线部署了多台高速摄像机，用于精确判定冠军归属。这些摄像机的数据需要被打上纳秒级精度的同步时间戳。为了实现这一点，核心网的**TSCTSF（时间敏感通信与时间同步功能）**需要确保为这些设备服务的gNB-Marathon自身具有极高的时钟精度。

3.2 成功操作 (Successful Operation)

这是一个由AMF发起的请求-响应流程，以及一个由gNB发起的报告流程。

1. Timing Synchronisation Status (状态请求) (8.19.1)

   • 流程: AMF向gNB发送TIMING SYNCHRONISATION STATUS REQUEST消息，其中RAN TSS Request Type IE可以设置为"start"或"stop"。这相当于TSCTSF（通过AMF）在问gNB：“请开始（或停止）向我汇报你的时钟同步状态。” gNB收到后会回复RESPONSE或FAILURE。

   • 场景: 在赛事开始前，TSCTSF命令AMF向gNB-Marathon发送请求，要求其开始上报时钟同步状态。

2. Timing Synchronisation Status Report (状态报告) (8.19.2)

   • 流程: 在收到“start”请求后，gNB会周期性地或在状态变化时，主动向AMF发送TIMING SYNCHRONISATION STATUS REPORT消息。

   • 消息核心IE:

     • Routing ID: 指明这个报告是发给哪个TSCTSF的。

     • RAN Timing Synchronisation Status Information: 包含了gNB的时钟同步状态（如locked, holdover, freeRun）、时钟源（traceable to UTC/GNSS）、时钟精度等关键信息。

   • 场景: gNB-Marathon开始向AMF（并转发给TSCTSF）上报：“我的时钟已通过GPS锁定，当前精度在50纳秒以内。” TSCTSF确认网络满足要求后，才允许终点线的高精度业务启动。

这个流程确保了核心网对接入网的时间同步能力有完全的可见性，是实现端到端确定性网络的关键一步。

---

FAQ

Q1: 广播和多播业务，对用户的手机电量消耗有影响吗？

A1:

有影响，但5G设计了多种机制来优化。UE需要周期性地唤醒来监听MBS相关的控制信道（MCCH）和数据信道（MTCH）。为了省电，UE可以进入DRX模式。对于多播业务，因为有“激活/去激活”机制，只有在会话被激活时，UE才需要消耗更多电量来接收数据，在去激活期间则可以保持较低功耗。总的来说，相比于维持一个持续的单播连接来接收相同的数据（如看直播），MBS在网络资源和终端功耗上都具有巨大优势。

Q2: 我如何知道我的手机加入了哪个多播会话？这个过程是自动的吗？

A2:

这个过程通常是由应用和用户订阅驱动，并通过核心网完成的。例如，当你在一个体育App中点击“订阅某场比赛的实时多播”时，App会通过信令通知核心网的MB-SMF。MB-SMF在验证你的订阅资格后，就会通过UE的PDU会话，将你“加入”到这个多播组中。这个“加入”（Join）的过程对于接入网gNB来说是透明的。之后，当该多播会话被激活并寻呼时，你的手机就会响应并开始接收数据。

Q3: 为什么Configuration Transfer和RIM Transfer流程中AMF是透明的，但在MBS流程中AMF却扮演了主要的发起者角色？

A3:

这是一个很好的架构问题，体现了不同流程的设计意图。

• 在Configuration Transfer和RIM中，信息交换的主体是RAN节点之间。AMF只是一个方便的“中转站”，核心网本身不关心也不需要理解这些RAN内部的配置信息。

• 在MBS流程中，业务的发起和管理主体在核心网侧（MB-SMF）。MBS会话的建立、激活、释放等决策都由MB-SMF做出。AMF在这里扮演的是核心网向接入网的“总代理”和“指令下发者”。它负责接收来自MB-SMF的业务级指令，并将其翻译成具体的NGAP流程，下发给一个或多个相关的gNB。

Q4: 时间同步状态报告中的“locked”, “holdover”, “freeRun”三个状态分别代表什么？

A4:

这三个状态描述了gNB时钟的精准程度和可靠性：

• locked (锁定)：这是最佳状态。表示gNB的时钟已经成功地与一个高精度的主时钟源（如GPS/GNSS卫星、PTP主时钟）实现了同步，并且正在持续地根据主时钟进行校准。此时的时钟精度最高。

• holdover (保持)：当gNB与主时钟源的连接意外中断时（例如，GPS信号丢失），gNB会进入保持模式。它会利用其内部高质量的晶体振荡器，在一段时间内继续维持相当高的时钟精度。但随着时间推移，精度会逐渐下降。

• freeRun (自由运行)：这是最差的状态。表示gNB既没有锁定到主时钟，也超出了保持模式的有效时间。它只能依靠其内部的普通振荡器运行，时钟精度无法得到保证，不能用于支持时间敏感业务。

Q5: 如果一个gNB上报其时间同步状态为freeRun，会对网络产生什么影响？

A5:

核心网的TSCTSF收到这个报告后，会立即采取措施。首先，它会禁止任何新的、对时间同步有严格要求的业务（如工业控制、远程手术）调度到这个gNB上。对于已经在该gNB上运行的时间敏感业务，TSCTSF可能会触发告警，或者尝试通过切换等方式将UE迁移到其他时钟状态正常的gNB上，以避免业务质量下降或失败。同时，网管系统会收到严重告警，通知运维人员检查gNB的时钟同步链路。