51学通信

深度解析 3GPP TS 23.380：6 SCC AS 故障恢复 (服务连续性的最后一道防线)

22分钟阅读

深度解析 3GPP TS 23.380：6 SCC AS 故障恢复 (服务连续性的最后一道防线)

本文技术原理深度参考了3GPP TS 23.380 V18.1.0 (2024-09) Release 18规范中，关于“Chapter 6 Recovery after SCC AS failure”的核心章节，旨在为读者揭示在IMS（IP多媒体子系统）中，保障音视频业务在不同网络间无缝切换（如VoLTE到3G通话）的核心网元——SCC AS发生故障时，网络如何启动应急预案，确保业务连续性的最后一道防线。在深入本章前，我们将首先简要回顾并收尾第五章中关于P-CSCF恢复的两个特殊互操作性场景。

0. 承前启后：P-CSCF恢复的互操作性补遗

在我们正式探讨SCC AS的恢复机制之前，需要对第五章的最后两个小节——5.9 P-CSCF Restoration in EPC with 5GC interworking和5.10 P-CSCF Restoration in EPC for untrusted WLAN when N10 is used instead of S6b进行简要的说明和过渡。

这两个章节内容非常简短，它们并非引入全新的恢复机制，而是将我们在前几篇文章中详细讨论过的P-CSCF恢复流程，应用于特定的、复杂的网络互操作场景中。

  • 章节5.9 描述了当用户在5G核心网（5GC）和4G核心网（EPC）之间移动时，P-CSCF的恢复如何进行。此时，网络中存在HSS+UDM和PGW-C+SMF这样的融合网元。该章节的核心思想是，当HSS+UDM收到来自S-CSCF的恢复指示后，它会智能地判断用户当前的位置，如果用户在EPC下，它会触发我们在5.4节中讨论的HSS-based机制（通过MME）；如果用户在5GC下，它会触发我们在5.8节中讨论的UDM-based机制（通过SMF/AMF）。这确保了恢复流程能够适应用户的动态移动性。

  • 章节5.10 则针对一种更特殊的WLAN接入场景：当核心网使用N10接口（PGW-C+SMF与HSS+UDM之间）替代传统的S6b接口时。这里的恢复逻辑与5.9类似，HSS+UDM会通过N10接口，将恢复指令下发给PGW-C+SMF，后续流程则复用已有的P-CSCF恢复程序。

综上所述，5.9和5.10章节是对P-CSCF恢复机制在高级互操作场景下的应用说明，其底层逻辑并未脱离我们已经建立的知识框架。现在，让我们将目光转向一个全新的、对保障通话连续性至关重要的角色——SCC AS。

1. 故事新挑战：悬崖边缘的通话

我们的主角，商务精英小张，刚刚结束了在一个5G信号全覆盖的智慧园区的关键会议。此刻，她正驾车离开园区，沿着蜿蜒的山路返回市区。她正在与公司最重要的海外投资人进行一通VoNR高清视频通话，汇报刚刚取得的重大突破。

车载屏幕上，投资人赞许的表情和实时共享的数据图表都清晰可见。然而，随着车辆深入山区，手机信号条上的“5G”标志开始闪烁，并很快切换为了“3G”。这是一个典型的覆盖切换场景。在理想情况下，小张的通话应该能无缝地从5G的数据网络（PS域）平滑切换到3G的语音网络（CS域），这个神奇的技术被称为SRVCC (Single Radio Voice Call Continuity)。

然而，就在切换即将发生的那一刻，负责执行SRVCC切换的核心大脑——SCC AS (Service Centralization and Continuity Application Server)，因为一次突发的软件异常而崩溃了。

小张的通话，此刻正悬于“断线”的悬崖边缘。IMS网络能否再次创造奇迹，在这千钧一发之际，挽救这次价值连城的通话？这正是第六章要为我们解答的终极难题。

2. 最后的防线：SCC AS及其恢复机制 (Chapter 6.1 General)

在深入技术细节前，我们必须理解SCC AS的“江湖地位”。

SCC AS是IMS中的一个特殊应用服务器，它的核心使命就是保障业务的连续性，尤其是在异构网络切换时。对于语音业务而言，它最重要的功能就是SRVCC。在VoLTE/VoNR通话期间，SCC AS就像一个“双面间谍”，一端连接着IMS域，另一端通过与MME/MSC Server的交互，为这个通话预留了一条通往传统2G/3G电路域（CS）的“逃生通道”。当5G/4G信号弱时，它负责 orchestrating (精心编排) 整个切换过程，确保用户的通话在用户毫无察觉的情况下，从PS域平滑过渡到CS域。

It is an optional feature to support SCC-AS restoration. If SCC-AS restoration is supported, it is required to support enhanced third party registration procedure described in 6.2.1 and enhanced service request procedure described in 6.2.2 together.

规范开宗明义地指出，SCC AS的故障恢复是一个可选功能。但如果要实现它，就必须同时实现两个配套的增强流程：

  1. 增强的第三方注册流程 (6.2.1)：用于在平时“备份”SRVCC所需的关键信息。
  2. 增强的业务请求流程 (6.2.2)：用于在故障发生时“恢复”这些信息并继续业务。

“备份”与“恢复”，这套我们已经熟悉的组合拳，再次成为了保障网络高可用性的核心。

3. 未雨绸缪：备份SRVCC的“逃生路线图” (Chapter 6.2.1 Enhanced Third Party Registration Procedure)

SRVCC的切换过程，依赖于一套精确的“逃生路线图”。这张图的关键信息之一，就是**ATCF (Access Transfer Control Function)**的地址。ATCF是IMS域与CS域信令转换的“桥头堡”。SCC AS必须知道该联系哪个ATCF来执行切换。

如果SCC AS故障，这张“路线图”就会丢失。因此，恢复机制的第一步，就是在用户正常注册IMS时，由SCC AS将这张图的关键信息，备份到绝对可靠的HSS中。

3.1 备份流程深度解析

我们回到小张驾车进入园区，手机开机并首次注册IMS的时刻。这个看似普通的注册流程背后，隐藏着精密的备份动作。规范中的“Figure 6.2.1.2-1 Enhanced Third Party Registration Procedure”描绘了这一过程。

  1. 步骤1-14 (正常的IMS第三方注册)：小张的手机发起注册，S-CSCF根据她的签约信息（iFC），将注册请求“fork”一份给SCC AS。这被称为第三方注册。SCC AS成功处理了注册。
  2. 步骤21 (核心备份动作)：
  1. For the first time the SCC-AS receives a third party registration of a served user, the SCC-AS shall store the ATCF-Path-URI, ATCF–Management-URI parameters and g.3gpp.accesstype media feature tag (if received) contained in the SIP REGISTER request as new Repository Data in the HSS. For the subsequent third party registration …, the SCC-AS shall update the … Repository Data…

这是整个备份机制的核心。在处理完第三方注册后，SCC AS会向HSS发送一个PUR (Profile-Update-Request) 消息。它在这个消息中，将从注册请求里获知的、与SRVCC相关的关键信息，作为“Repository Data”（仓库数据）存入HSS。这些信息包括：

  • ATCF-Path-URI / ATCF-Management-URI：ATCF的联系地址，这是“逃生路线图”的核心。
  • g.3gpp.accesstype media feature tag：媒体特征标签，用于描述接入网络类型，辅助切换决策。

HSS收到后，会将这些数据存储在小张的用户档案中，就像在一个保险箱里为她的SRVCC能力上了份“数据保险”。

深度解析：“仓库数据” HSS原本主要存储的是用户签约数据，是相对静态的。而“Repository Data”这个概念，允许应用服务器（如SCC AS）将一些动态的、与业务上下文相关的数据，也存放在HSS中。这极大地扩展了HSS的功能，使其从一个单纯的用户数据库，演进为了一个通用的、高可用的网络功能数据存储中心。SCC AS的恢复，正是这个演进思想的典型应用。

4. 绝地求生：故障发生时的“临危受命” (Chapter 6.2.2 Enhanced Service Request Procedure)

现在，让我们回到小张驾车驶向山区的惊险时刻。VoNR通话正在进行，手机检测到5G信号衰减，MME触发了SRVCC流程。信令被送往S-CSCF，S-CSCF需要将其转发给SCC AS来执行切换。但此时，为小张服务的主用SCC AS（我们称之为SCC-AS1）突然崩溃了。

4.1 恢复流程深度解析

规范中的“Figure 6.2.2.2-1 Enhanced Service Request Procedure”为我们展示了这场悬崖边的救援行动。

  1. 步骤1-2 (S-CSCF发现“前线失守”)：
  1. The S-CSCF receives session service request message and it attempts to route the message towards the registered SCC-AS, that in the figure 6.2.2.2-1 is “SCC-AS1”.
  2. The S-CSCF detects the failure of SCC-AS1. S-CSCF收到了SRVCC的切换请求信令，并尝试将其发往之前为小张注册的SCC-AS1。然而，请求超时，S-CSCF判定SCC-AS1已经发生故障。
  1. 步骤3 (S-CSCF的智能重选)：
  1. S-CSCF re-selects a new available SCC-AS, i.e. “SCC-AS2” e.g. by a DNS procedure or by configuration in the matched Filter Criteria of an alternative SCC-AS to provide services to the user. S-CSCF并没有放弃。它展现了高度的智能：它会通过DNS查询或本地的备份配置，找到一个健康的、可用的备用SCC AS，我们称之为SCC-AS2。S-CSCF的iFC（初始过滤原则）中，通常会配置主备SCC AS，这使得重选成为可能。

  1. 步骤4 (SCC-AS2的“临危受命”)： S-CSCF将SRVCC切换请求转发给了这位“新兵”——SCC-AS2。

  2. 步骤5-6 (从“保险箱”中恢复“路线图”)：

  1. After receiving the service request message, if no subscriber data is found, SCC-AS2 starts implicit registration procedure … After retrieving required subscriber data from the HSS, the SCC-AS2 shall request the ATCF related information and the g.3gpp.accesstype media feature tag stored as Repository Data (if present).
  2. If ATCF related Repository Data is stored in the HSS, it is received back by the SCC-AS2. 这是恢复流程的“魔法”所在。SCC-AS2收到请求后，发现自己对小张和她正在进行的通话一无所知。于是，它会启动一个“隐式注册”流程，向HSS查询小张的所有数据。 * 关键点：在这次查询中，SCC-AS2不仅会请求用户的常规签约数据，还会特别请求之前SCC-AS1存放在HSS里的那些“Repository Data”。 * HSS在UDA（User-Data-Answer）中，将包含ATCF地址等关键信息的“仓库数据”返回给了SCC-AS2。
  1. 步骤7-8 (继续执行SRVCC切换)：
  1. If ATCF related Repository Data is received by the SCC-AS2, it shall send a MESSAGE with its own ATU-STI towards the ATCF that is identified by received ATCF-Management-URI.
  2. The SCC-AS2 continues the session as normal. 此刻，SCC-AS2已经从HSS的“保险箱”中，拿到了由SCC-AS1留下的那份宝贵的“逃生路线图”。它现在清楚地知道该联系哪个ATCF来执行切换。于是，它向正确的ATCF发送信令，指挥ATCF完成IMS域到CS域的切换。

最终结果：在小张看来，她的VoNR视频通话可能只是画面瞬间的凝固，随后便无缝地切换成了一个普通的3G语音通话。视频虽然中断了，但最重要的语音通信得以连续，她与投资人的关键对话没有因为网络覆盖的切换和核心网元的故障而中断。IMS网络的最后一道防线，成功守住了！

5. 总结：超越故障恢复的服务连续性

通过对SCC AS故障恢复机制的深度剖析，我们将IMS高可用性设计的认知，提升到了一个新的高度——从“业务可用性”到“业务连续性”。

  • P-CSCF/S-CSCF的恢复，其核心目标是保障业务可用性。即使用户通话中断，网络也能快速恢复，让用户可以重新发起通话。
  • SCC AS的恢复，其核心目标是保障业务连续性。它追求的是在特定的业务场景（如SRVCC切换）中，即使发生了核心网元故障，也能让正在进行中的业务（通话）不中断，或者以一种“优雅降级”（如视频变语音）的方式得以延续。

这场“悬崖边缘的救援”，其成功的关键在于：

  1. 事前备份：通过“增强的第三方注册”，SCC AS将SRVCC上下文（如ATCF地址）作为“仓库数据”备份在HSS，未雨绸缪。
  2. 智能重选：S-CSCF具备故障检测和动态重选备用AS的能力，是启动恢复流程的关键一环。
  3. 按需恢复：新的SCC AS在“临危受命”后，能够从HSS中按需取回备份的上下文数据，从而无缝地接管业务流程。
  4. HSS角色的升华：HSS在此机制中，彻底升华为一个通用的、高可用的业务上下文数据存储库，为各类应用服务器的无状态化和高可用部署，提供了坚实的基础。

小张的故事至此告一段落。从S-CSCF的“大脑失忆”，到P-CSCF的“门户坍塌”，再到SCC AS的“悬崖救援”，我们一同见证了3GPP TS 23.380规范如何通过一套又一套精妙、复杂、层层递进的机制，为我们看似简单的每一次通话，构建了一个强大而坚韧的“隐形守护网络”。

FAQ环节

Q1：什么是SCC AS？它和S-CSCF有什么区别？ A1：S-CSCF（Serving-CSCF）是IMS的会话控制核心，负责处理所有用户的注册、会话建立、路由等基础信令流程，是IMS网络不可或缺的基础网元。SCC AS（Service Centralization and Continuity Application Server）是IMS的应用服务器（AS）之一，它专注于提供业务连续性的增值服务。它不是IMS的必需品，但对于实现像SRVCC（语音从4G/5G到2G/3G的切换）这样的高级功能至关重要。可以理解为：S-CSCF是“操作系统内核”，而SCC AS是运行在这个系统上的一个“关键应用程序”。

Q2：ATCF（Access Transfer Control Function）是什么角色？为什么它的信息对SRVCC如此重要？ A2：ATCF是实现SRVCC的“信令网关”或“转换锚点”。它位于IMS域（PS域）和传统电路域（CS域）的边缘。当SRVCC发生时，SCC AS会将IMS侧的会话控制权“交接”给ATCF，再由ATCF与CS域的MSC Server进行信令交互，完成切换。因此，SCC AS必须准确地知道该联系哪个ATCF来处理某个特定用户的切换。这个ATCF的地址，就是“逃生路线图”上最重要的坐标，一旦丢失，切换就无法进行。

Q3：SCC AS的恢复过程看起来很快，它真的能在通话掉线前完成吗？ A3：是的，这个流程被设计为高速执行。整个恢复过程发生在核心网内部，S-CSCF、SCC-AS2和HSS之间的信令交互通常在几十到几百毫秒内就能完成。而SRVCC的切换窗口本身就有一定的容忍时间。因此，只要网络配置合理，备用SCC AS健康可用，这套恢复机制完全可以在用户察觉到通话中断之前完成，实现“无感”的故障恢复和业务切换。

Q4：为什么SCC AS的恢复机制是可选的？难道不应该所有支持SRVCC的网络都部署吗？ A4：将其定义为“可选”是出于多方面考虑：

  1. 实现复杂性：这套机制要求S-CSCF、SCC AS和HSS都进行相应的增强开发，增加了设备商的实现成本和运营商的部署复杂度。
  2. 替代方案：一些运营商可能通过在物理层面部署高可用性的SCC AS集群（例如，Active-Standby或负载均衡集群），并利用IP层面的路由切换来实现高可用，而不是依赖3GPP定义的这套信令层面的恢复机制。
  3. 业务优先级：在网络建设初期，运营商可能会优先保障基础的通话能力，而将SRVCC下的故障恢复作为后续的优化项。 因此，规范提供了这个选项，让运营商可以根据自己的网络成熟度、成本预算和对业务连续性的要求来决定是否部署。

Q5：S-CSCF是如何知道哪个SCC AS是主用（SCC-AS1），哪个是备用（SCC-AS2）的？ A5：这是通过S-CSCF的**iFC（initial Filter Criteria）**配置来实现的。iFC是存储在HSS中、在用户注册时下发给S-CSCF的一组触发规则。运营商在配置用户的iFC时，可以为一个业务（如SRVCC）指定一个SCC AS组，并定义它们的优先级。例如，规则可以写成：“当收到SRVCC相关信令时，首先尝试发往scc-as1.operator.com（优先级1），如果失败，则尝试发往scc-as2.operator.com（优先级2）”。这种基于优先级的配置，就赋予了S-CSCF在主用AS故障时，自动、智能地选择备用AS的能力。

关系图谱