51学通信

深度解析 3GPP TS 23.527：8.3.3-8.3.4 5G MBS恢复 (Part 3 - “幽灵基站”与“VIP专线”重建)

19分钟阅读

深度解析 3GPP TS 23.527：8.3.3-8.3.4 5G MBS恢复 (Part 3 - “幽灵基站”与“VIP专线”重建)

本文技术原理深度参考了3GPP TS 23.527 V18.5.0 (2024-09) Release 18规范中，关于“8.3.3 Broadcast MBS session restoration Procedure for NG-RAN failure without restart”和“8.3.4 Multicast MBS session restoration Procedure for NG-RAN failure with or without restart”的核心章节。本文旨在为读者揭示5G MBS业务在面对RAN侧“非重启”故障时的清理机制，并深入剖析更为复杂的组播（Multicast）业务在RAN侧故障后的两种核心恢复策略。

前言：当“信号塔”变成“幽灵”

在上一篇文章中，我们探讨了当“世界电竞总决赛”赛场上的gNB-Stadium-ZoneA-01基站重启时，AMF或MB-SMF如何为其“注入记忆”，快速恢复广播业务。然而，网络故障的形式远比重启更为诡谲。

新危机一：“幽灵基站”。gNB-Stadium-ZoneA-01并未重启，其硬件和主程序都运转正常。但连接它与AMF的传输网络（例如，承载SCTP协议的光纤链路）却被意外中断了。对于AMF来说，这个基站就像一个“幽灵”，无法通信，生死未卜。对于MB-UPF来说，它可能仍在向这个“幽灵”的IP地址发送数据，但这些数据都将石沉大海。这种“非重启”的故障，网络该如何应对？是无限期等待，还是果断清理？

新危机二：“VIP专线”中断。粉丝“Leo”为了获得极致的观赛体验，订阅了“红队专属”的**组播（Multicast）**频道，可以实时收听战队内部语音。与广播（Broadcast）向指定区域内所有人发送相同内容不同，组播只向一个特定的、授权的用户群体发送。现在，gNB-Stadium-ZoneA-01的故障，不仅切断了公共广播，也切断了Leo的这条“VIP专线”。组播的恢复，与广播有何不同？网络是等待Leo自己抱怨“没声音了”再行动，还是能智能地、主动地为他重建这条专线？

本文将继续深入这场发生在网络边缘的恢复之战，首先探索网络如何处理“幽灵基站”带来的广播中断问题，然后重点剖析5G网络为Leo这样的VIP用户，精心设计的两种组播业务恢复方案。

1. “幽灵基站”的处置：广播会话的无重启故障恢复 (基于TS 23.527 8.3.3)

当gNB并非重启，而是因路径中断等原因变得不可达时，其恢复流程的重点，从“重建”转向了“清理”。

The procedure specified in this clause may be supported to restore a Broadcast MBS session affected by an NG-RAN failure without restart. When the AMF detects NG-RAN failure without restart, e.g. using SCTP path failure detection mechanism, it shall report such event to the MB-SMF… to enable the MB-SMF to remove the DL F-TEID allocated by the failed NG-RAN in the MB-UPF when unicast transport is used over N3mb interface.

我们结合规范中的 Figure 8.3.3-1: Broadcast MBS session restoration by MB-SMF upon NG-RAN failure without restart 来分析这个流程。

场景：AMF与gNB-Stadium-ZoneA-01之间的SCTP链路中断。

  • 步骤 1 & 2: AMF的“侦测”

    2. The AMF detects the NG-RAN failure without restart e.g. using SCTP path failure detection mechanism. AMF通过其与gNB之间的N2接口心跳机制（基于SCTP协议），发现gNB-Stadium-ZoneA-01失联。AMF无法确定gNB是死是活，只知道通信路径断了。

  • 步骤 3: AMF向“总导演”报告

    3. The AMF sends Namf_MBSBroadcast_ContextStatusNotify Request message to the MB-SMF… including the MBS Session ID, the NG-RAN ID of failed NG-RAN, Failure indication. AMF立刻向MB-SMF发送ContextStatusNotify报告：“总导演请注意，gNB-Stadium-ZoneA-01失联，原因：非重启故障。它之前承载的‘世界电竞总决赛’广播业务可能已中断。”

  • 步骤 5: MB-SMF的“清理”指令

    5. The MB-SMF modifies the PFCP sessions corresponding to the affected MBS sessions to remove the NG-RAN DL F-TEID for unicast transport over N3mb. MB-SMF收到报告后，做出核心决策：既然这个gNB已经不可达，那么MB-UPF就不应该再徒劳地向它发送数据。

    • 如果广播采用的是单播模式，MB-SMF会向MB-UPF发送PFCP Session Modification指令，要求其删除与gNB-Stadium-ZoneA-01相关的下行隧道（DL F-TEID）。
    • 如果采用的是多播模式，MB-SMF会更新其内部状态，标记该gNB已不在多播分发树中。

结论：对于“非重启”故障，恢复机制的核心是快速止损和资源清理。网络会假定该gNB已无法提供服务，并从核心网侧（MB-UPF）拆除通往该“幽灵基站”的数据路径，避免资源的无效占用。至于何时恢复，则需要等待gNB与AMF的通信恢复后，再视情况（可能被当作一个新上线的gNB）来重新激活业务。

2. “VIP专线”的重建：组播会话恢复 (基于TS 23.527 8.3.4)

组播业务的恢复，远比广播复杂。因为组播与特定的UE个体（或群体）紧密绑定，其恢复流程也必须与该UE的单播PDU会话深度协同。

The procedure specified in this clause may be supported to restore a Multicast MBS session affected by an NG-RAN failure with or without restart. When a UPF detects the NG-RAN failure… it shall report such event to the SMF to enable the SMF to derive UEs who have joined the MBS sessions… and initiates the restoration procedure…

  • 深度解析：这段话揭示了组播恢复的核心逻辑：
    1. 故障检测方：不再仅仅是AMF，UPF（服务于UE单播会话的那个普通UPF）也成为了关键的“哨兵”。因为它直接与gNB进行用户面交互。
    2. 信息枢纽：故障信息被上报给SMF（管理UE单播会話的SMF）。
    3. 决策依据：SMF需要根据故障信息，推断出哪些UE（例如Leo）的组播接收受到了影响。
    4. 发起恢复：SMF随后主动为这些受影响的UE发起恢复流程。

我们结合规范中的 Figure 8.3.4-1: Multicast MBS session restoration upon NG-RAN failure with or without restart 来深入这场“VIP专线”的重建之战。

场景：gNB-Stadium-ZoneA-01发生故障（重启或非重启均适用），Leo的“红队语音”组播中断。

  • 步骤 1-7: 故障的“多点检测”与“信息汇总”

    • UPF侧：服务Leo单播会话的UPF，通过GTP-U Echo心跳或收到来自gNB的GTP-U Error Indication，检测到gNB用户面异常。它立刻向SMF报告。SMF随即指令UPF移除通往该故障gNB的、用于承载组播数据的隧道。
    • MB-UPF侧：MB-UPF也可能通过N3mb路径探测，检测到gNB的异常，并报告给MB-SMF。MB-SMF也会清理其到gNB的路径。
    • 核心：故障信息从用户面的各个触点，最终汇集到了控制面的SMF。

  • 步骤 8: 恢复的“十字路口” - 两种恢复哲学 SMF现在已经知道Leo的组播专线断了。接下来怎么做？规范给出了两条截然不同的路径。

    路径 8a: 被动恢复 (Reactive Restoration)

    8a. The SMF may wait for UEs who have joined the MBS session(s) which are affected by the NG-RAN failure to trigger a Service Request procedure to re-establish the user plane resource and then restore the Multicast MBS session in NG-RAN.

    • 策略：SMF选择“等待”。它什么也不做，静静地等待Leo的终端自己发起动作。
    • 触发：Leo发现语音没声音了，可能会切换一下应用再切回来，或者他的平板电脑检测到无线链路异常，自动发起一次**服务请求（Service Request）**来尝试恢复连接。
    • 恢复：SMF捕捉到这次服务请求后，“顺便”为Leo重新执行一遍组播会话的激活流程，重建他的“VIP专线”。
    • 优劣：简单，对网络来说最省事。但对用户体验不友好，Leo需要经历一段“服务中断”时间，且恢复的快慢取决于终端的行为。

    路径 8b: 主动恢复 (Proactive Restoration)

    8b. Alternatively, the SMF may derive UEs who have joined the MBS session(s) which are affected by the NG-RAN failure… and perform step 9.

    • 策略：SMF选择“主动出击”。
    • 智能推断：SMF根据收到的故障信息（例如，故障gNB的ID），查询自己的数据库，找出所有通过该gNB接入、并且加入了“红队语音”组播会话的UE列表。它立刻就锁定了Leo。
    • 触发：SMF不等Leo有任何动作，立刻主动为Leo发起网络侧的资源重建流程。

  • 步骤 9: 执行“VIP专线”重建

    9. When step 8b applies, the SMF continues with the MBS session activation procedure as specified in clause 7.2.5.2 of 3GPP TS 23.247 starting from step 3 to restore the MBS sessions for affected UEs for each MBS session.

    无论是被动触发还是主动发起，最终的恢复动作都是相同的：SMF会重新执行一遍在TS 23.247（MBS架构规范）中定义的组播会话激活流程。这个流程会通过AMF，在新的（或恢复后的）gNB上，为Leo重新建立接收组播所需的无线承载和用户面资源。

最终结果：

  • 如果网络采用被动恢复，Leo在经历了一段恼人的沉默后，可能需要自己动手“修复”，体验较差。
  • 如果网络采用主动恢复，Leo可能只会感觉到语音短暂地卡了一下，网络就在后台为他无声地完成了所有复杂的修复工作，VIP体验得到了保障。

3. 总结

5G MBS业务在NG-RAN侧的故障恢复机制，展现了针对不同业务类型、不同故障场景的精细化设计。

  1. 广播恢复的重点是“清理”：对于“非重启”故障下的广播业务，由于网络无法确定gNB的状态，恢复的首要任务是清理核心网侧的无效资源（如GTP-U隧道），避免网络资源的浪费和状态的不一致。

  2. 组播恢复与单播会话深度绑定：组播恢复的复杂性远超广播，其整个流程强依赖于UE的单播PDU会话。故障的检测、受影响UE的识别、以及恢复流程的发起，都离不开SMF和UPF这对“常规武器”的参与。

  3. 主动 vs. 被动：恢复哲学的抉择：在组播恢复上，规范提供了“被动等待”和“主动出击”两种模式。主动恢复无疑能提供更优的用户体验，但对SMF的实现提出了更高的要求（需要具备快速推断受影响UE集合的能力），是衡量5G网络智能化水平的一个重要标尺。

对于在赛场上为红队呐喊的Leo来说，无论是公共的赛事画面，还是专属的队内语音，5G网络都为其准备了周密的保障预案。从对“幽灵基站”的果断处置，到为“VIP专线”的主动重建，这些机制共同确保了在网络的“最后一公里”发生动荡时，用户的沉浸式体验能够得到最大程度的维系。

FAQ

Q1：NG-RAN的“重启（restart）”和“无重启故障（failure without restart）”在恢复流程上最大的区别是什么？

A1：最大的区别在于网络对gNB状态的确定性。

  • Restart：网络（AMF）能确定gNB已经重启，并处于一个干净的、可接受新配置的状态。因此，恢复流程的重点是重建（Restoration），即向其重新下发配置。
  • Failure without Restart：网络（AMF）不确定gNB的状态，只知道它失联了。它可能已经彻底损坏，也可能只是暂时路径不通。在这种不确定的情况下，网络的首要动作是**清理（Clean-up）**核心网侧与该gNB相关的资源，避免状态不一致和资源浪费。

Q2：为什么组播（Multicast）的恢复比广播（Broadcast）复杂这么多？

A2：因为它们的业务模型根本不同。

  • 广播是无状态、面向区域的。核心网只需知道向哪个区域（Area）投递信号，不关心区域内具体有谁在接收。
  • 组播是有状态、面向群体的。核心网必须精确地知道哪个UE加入了哪个组播。因此，组播的上下文是与UE的单播PDU会话绑定的。当故障发生时，网络必须恢复到UE个体级别，这就必然需要SMF/UPF的参与，流程自然就复杂了。

Q3：在组播恢复中，SMF是如何“推断（derive）”出哪些UE受影响的？

A3：SMF在其管理的PDU会话上下文中，会记录该会话的详细信息，包括：

  1. UE当前所接入的小区ID（Cell ID）和gNB ID。
  2. 该UE是否已经加入了某个或某些MBS组播会话。 当SMF收到来自UPF的、关于某个gNB用户面故障的报告时，它就会用这个gNB ID作为索引，去查询自己管理的所有PDU会话。所有满足“当前接入该gNB”且“已加入组播会话”这两个条件的UE，就是被推断出的受影响UE。

Q4：主动恢复（Proactive）听起来好得多，为什么规范还允许被动恢复（Reactive）的存在？

A4：这是一种功能分级的设计考虑。

  • 被动恢复是基础能力。它实现简单，对SMF的性能和逻辑要求最低，可以作为所有支持MBS的SMF必须具备的保底恢复方案。
  • 主动恢复是高级能力。它需要SMF具备更强的状态管理和智能推断能力，对设备实现要求更高。规范允许两种模式并存，使得设备商可以根据其产品的市场定位（高端vs.低端）来提供不同级别的可靠性支持。运营商也可以根据业务的重要性（普通组播vs.关键任务组播）来采购和部署不同能力的SMF。

Q5：SCTP（Stream Control Transmission Protocol）是什么？为什么它能用来检测“无重启故障”？

A5：SCTP是一种可靠的传输层协议，与TCP类似，但提供了更高级的功能。在5G核心网中，AMF与gNB之间的N2接口信令，就是承载在SCTP之上的。SCTP协议内置了心跳（Heartbeat）机制。AMF和gNB会周期性地通过SCTP连接互相发送心跳块（chunk）。如果一方在连续几次发送心TP后都没有收到对方的响应，SCTP连接就会被判定为失败。AMF的上层应用检测到SCTP连接的断开，就等同于检测到了与gNB的路径故障，即“无重启故障”。

关系图谱