51学通信

深度解析 3GPP TS 23.380：4.1 & 4.2 S-CSCF数据恢复与注册流程

26分钟阅读

深度解析 3GPP TS 23.380：4.1 & 4.2 S-CSCF数据恢复与注册流程

本文技术原理深度参考了3GPP TS 23.380 V18.1.0 (2024-09) Release 18规范中，关于“Chapter 4: Restoration of Data in the S-CSCF”的核心章节，旨在为读者提供一个关于IMS核心网元S-CSCF故障后，系统如何通过注册流程进行自我修复和业务恢复的全景视图。文章将首先对规范的范围、引用和核心定义进行铺垫，随后聚焦于4.1和4.2章节，深入剖析S-CSCF故障场景下的各种注册恢复机制。

0. 前言：为何需要IMS故障恢复？

在当今的通信世界，无论是个人用户的高清VoLTE/VoNR通话，还是企业的富媒体通信（RCS）服务，其背后都离不开一个强大而稳定的核心网络——IP多媒体子系统（IMS）。IMS网络如同一座精密的城市，各个网元各司其职，协同工作，确保每一条信令、每一个媒体包都能准确无误地送达。

然而，没有任何系统能保证100%的稳定运行。硬件故障、软件崩溃或网络链路中断都可能导致IMS中的关键网元（如S-CSCF、P-CSCF）发生服务中断。这种中断对于用户而言，可能意味着一次重要通话的突然掉线，或者无法接收到来电，其影响是直接且严重的。

为了将这种影响降到最低，3GPP定义了一系列精密的“城市应急预案”——IMS Restoration Procedures，也就是TS 23.380规范的核心内容。本规范详细描述了当IMS核心网元（特别是S-CSCF和P-CSCF）发生故障时，网络如何能够自动、快速地进行恢复，以最小的业务中断为代价，保障最终用户的服务连续性。

在深入技术细节之前，我们先快速浏览一下规范的前三章，为后续的深度解析奠定基础。

  • 第一章 Scope (范围)：明确指出本规范专注于处理S-CSCF（服务CSCF）和P-CSCF（代理CSCF）的服务中断场景，目标是最小化对最终用户业务的影响。其他网元的恢复机制在本规范中并未定义。
  • 第二章 References (参考文献)：列出了理解本规范所必须依赖的其他3GPP及IETF规范，例如TS 29.228（Cx接口）、TS 23.501（5G系统架构）等。这是我们追根溯源、构建完整知识体系的地图。
  • 第三章 Definitions, symbols and abbreviations (定义、符号和缩写)：为我们提供了一套统一的技术语言。其中有两个定义至关重要：
    • Service Interruption (服务中断)：指一个或多个网络单元在一段时间内不响应请求，也不向系统其他部分发送任何请求。这是触发恢复流程的“警报”。
    • S-CSCF Restoration Information (S-CSCF恢复信息)：S-CSCF为已注册用户处理业务所需的关键信息。这些信息平时存储在HSS中，当S-CSCF丢失数据后，可以从HSS取回。这是IMS网络“记忆”和“重生”的关键。

理解了这些背景，我们正式开启对IMS心脏——S-CSCF的“急救手册”的深度解读。

1. 主角登场：商务精英“小张”的一天

为了让抽象的技术流程变得生动具体，我们引入本文的主角——商务精英小张。

小张是一家跨国公司的销售总监，她的工作高度依赖运营商提供的VoNR（5G高清语音）和企业融合通信服务。她的智能手机（UE）始终注册在IMS网络上，确保随时都能进行高质量的音视频通话和接收重要信息。今天，她正驱车前往一个决定公司未来的重要客户会议，一场突如其来的网络“风暴”正在酝酿。

我们将跟随小张的视角，看看当她所连接的IMS网络中的S-CSCF突然“宕机”时，3GPP规范是如何在幕后悄无声息地完成一系列复杂的恢复操作，保障小张的通信生命线畅通无阻的。

2. S-CSCF数据恢复总览 (Chapter 4.1 General)

在IMS网络中，S-CSCF（Serving-CSCF）扮演着“会话大脑”的角色。它负责处理用户的注册、会话建立、路由、业务触发等核心功能。一旦用户在S-CSCF上完成注册，S-CSCF就会维护该用户的完整会话上下文信息。

但如果这个“大脑”突然失忆了呢？比如S-CSCF节点因为软件升级而重启，或者发生硬件故障。这时，它所保存的所有用户的注册状态和会话信息都会丢失。这正是TS 23.380 Chapter 4所要解决的核心问题：如何在S-CSCF服务中断后，恢复其用户数据，重建会话能力。

The following clauses describe the IMS Restoration Procedures for the S-CSCF service interruption in each of the scenarios where they apply.

这段简单的原文宣告了本章的使命：分场景阐述S-CSCF服务中断后的IMS恢复流程。这些场景主要包括：用户注册时、有来电时（被叫流程）、用户打电话时（主叫流程）等。本篇文章，我们首先聚焦在最基础也是最关键的场景——注册流程 (Registration Procedure)。

3. 注册过程中的S-CSCF故障恢复 (Chapter 4.2 Registration Procedure)

注册是用户接入IMS网络、享受一切服务的前提。当小张的手机开机或进入新的5G覆盖区时，它会发起IMS注册流程。这个流程的恢复机制，是整个IMS高可用性设计的基石。

The following clauses specify the behaviour of HSS and S-CSCF if they support the IMS restoration feature.

规范开宗明义，接下来的内容是为那些支持IMS恢复特性的HSS（归属签约用户服务器）和S-CSCF“量身定制”的行为准则。这意味着，IMS恢复并非一个默认功能，而是需要网元明确支持的“高级技能”。

3.1 场景一：注册时，原S-CSCF彻底失联 (Chapter 4.2.2 S-CSCF Restoration after Failure)

故事背景：小张的手机正试图进行一次常规的IMS周期性重注册（Re-registration），以保持其VoNR服务的在线状态。然而，不幸的是，之前为她服务的S-CSCF-1突然发生了故障，彻底无法访问。

网络的入口是I-CSCF（Interrogating-CSCF），它像一个“接待员”，负责查询HSS（用户数据库）找到该分配给哪个S-CSCF（会话管理员）。现在，这个“接待员”发现之前记录的“会话管理员”S-CSCF-1失联了。

If the UE initiates a SIP REGISTER and the S-CSCF returned by the HSS during user registration status query procedure fails, the I-CSCF is unable to contact the S-CSCF. In this case, regardless of this registration is an initial registration, a re-registration or a de-registration, the I-CSCF shall send UAR with Authorization Type set to REGISTRATION_AND_CAPABILITIES to the HSS to explicitly request S-CSCF capabilities. After re-assignment of another S-CSCF according to the S-CSCF capabilities, the I-CSCF shall forward the REGISTER to the new S-CSCF.

这段原文描述了一个清晰的“Plan B”流程，我们来逐步拆解：

  1. I-CSCF发现异常：I-CSCF首先通过向HSS发送一个UAR（User-Authorization-Request）消息，查询小张当前注册在哪个S-CSCF上。HSS返回了S-CSCF-1的地址。但当I-CSCF尝试将小张的SIP REGISTER请求转发给S-CSCF-1时，却收不到任何回应（timeout）。

  2. 启动应急预案：I-CSCF意识到S-CSCF-1已经故障。此时，无论小张是想初次注册、重注册还是注销，I-CSCF都会采取相同的行动：它会再次向HSS发送一个UAR请求。但这次的UAR与之前不同，它的Authorization Type被设置为REGISTRATION_AND_CAPABILITIES。

    • 深度解析：这个特殊的Authorization Type是一个关键信号。它不再是简单地询问“用户现在在哪里”，而是在告知HSS：“我需要为这个用户找一个新的S-CSCF，请告诉我备选S-CSCF需要具备哪些能力（capabilities）”。HSS中存储了用户的签约信息，比如用户是否订购了VoNR、RCS等业务，这些业务可能需要S-CSCF具备特定的功能。HSS会返回这些能力要求，确保新分配的S-CSCF能胜任小张的业务需求。

  3. 重新选择与转发：HSS在UAA（User-Authorization-Answer）中返回了S-CSCF的能力要求列表。I-CSCF根据这个列表，结合本地的配置和负载均衡策略，选择了一个新的、健康的S-CSCF，我们称之为S-CSCF-2。然后，I-CSCF将小张的SIP REGISTER请求原封不动地转发给这个S-CSCF-2。

  4. 新S-CSCF的行为：

For registrations and re-registrations, S-CSCF shall proceed with the registration procedure as for initial registration, except for the clauses specified in 4.2.3.

S-CSCF-2收到这个注册请求后，会把它当作一个全新的初始注册来处理。这是非常重要的一点。因为它意味着S-CSCF-2会执行完整的注册流程：向HSS发送SAR（Server-Assignment-Request）下载小张的用户签约数据，然后返回200 OK给小张的手机，完成注册。

通过这个流程，小张的手机在完全无感知的情况下，业务已经从故障的S-CSCF-1无缝切换到了健康的S-CSCF-2。她的VoNR图标依然点亮，随时可以接打重要电话。这就是IMS恢复机制的强大之处。

3.2 现代化的恢复机制：基于SBI的接口支持 (Chapter 4.2.2A SBI Support for S-CSCF Restoration after Failure)

随着5G核心网向服务化架构（SBA）演进，网元间的通信方式也从传统的Diameter协议（如Cx接口）逐渐转向基于HTTP/2的服务化接口（SBI）。4.2.2A章节描述了在这种新架构下的恢复流程，其核心思想一致，但实现细节有所不同。

故事背景：假设小张所在的网络是先进的5G SA网络，IMS也部署了支持SBI接口的网元。

If the I-CSCF is unable to contact the currently assigned S-CSCF, regardless of this registration is an initial registration, a re-registration or a de-registration, the I-CSCF shall reselect an S-CSCF and forward the REGISTER to the new S-CSCF. The I-CSCF shall include a reselection indication in the REGISTER request. The S-CSCF shall proceed with the registration procedure as for initial registration. Additionally, the S-CSCF shall include the reselection indication towards the HSS.

我们来对比一下这个流程与传统流程的差异：

  1. I-CSCF的自主性更强：在SBI架构下，I-CSCF（在5G中可能由IMS-AS或I-CSCF NF体现）在发现S-CSCF-1故障后，不再需要向HSS/UDM发送一个特殊的请求去获取“能力”。它可以基于本地策略或从NRF（网络功能仓库功能）获取的信息，直接重新选择一个新的S-CSCF-2。这简化了流程，减少了信令交互。

  2. 引入“重选指示”：这是一个关键的创新。

    • I-CSCF在将SIP REGISTER请求转发给新的S-CSCF-2时，会在请求中加入一个“reselection indication”（重选指示）。
    • S-CSCF-2收到这个指示后，在与HSS/UDM交互时，也会带上这个“重选指示”。

  3. HSS的智能决策：

When receiving the reselection indication, the HSS shall allow the new S-CSCF to overwrite the current S-CSCF.

HSS/UDM收到带有“重选指示”的注册请求后，就明白了这是一个S-CSCF故障恢复场景。它会允许这个新的S-CSCF-2的信息覆盖掉数据库里旧的、已故障的S-CSCF-1的信息。

  • 深度解析：如果没有这个指示，HSS可能会认为这是一个异常注册（比如用户在不同地方同时注册），并可能拒绝S-CSCF-2的请求。这个小小的指示，相当于给S-CSCF-2颁发了一张“尚方宝剑”，使其能够名正言顺地接管用户服务，确保了恢复流程的顺畅。

总的来说，基于SBI的恢复流程更简洁、高效，体现了5G服务化架构的优势。

3.3 恢复后的数据同步难题 (Chapter 4.2.3 S-CSCF Restoration during Registration Process)

现在，小张的手机已经成功注册到了新的S-CSCF-2上。但是，一个更复杂的问题出现了。小张不仅有手机，她还有一个支持eSIM的平板电脑，也使用同一个工作号码（即同一个Public User Identity）。

在S-CSCF-1故障前，她的手机和平板都已注册，S-CSCF-1存有这两台设备的注册信息（对应两个不同的Private User Identity）。现在S-CSCF-2只处理了手机的注册，它对平板的存在一无所知。如果此时有电话打给小张，S-CSCF-2只会将呼叫送往她的手机，而平板则不会响铃。这显然不符合用户的预期。

4.2.3章节就是要解决这个数据同步和一致性的问题。

During the registration procedure, the HSS shall send all the registered Private User Identities sharing the same Public User Identity which is being registered in the SAA, in addition to the basic user data to the S-CSCF. … If there are any registered Private User Identities the S-CSCF does not have their registration data, the S-CSCF shall send SAR with Server Assignment Type set to NO_ASSIGNMENT to the HSS to retrieve the S-CSCF restoration information for the registered Public User Identity.

让我们用小张的例子来详细解读这个精妙的同步过程：

  1. HSS的主动告知：当S-CSCF-2为小张的手机（我们称之为IMPI-1）向HSS发送SAR请求时，HSS在返回的SAA响应中，除了包含小张的基础签约数据外，还会主动告诉S-CSCF-2：“嘿，注意了！与这个号码（IMPU-1）关联的，除了你正在注册的这个IMPI-1，还有一个已经注册过的设备叫IMPI-2（小张的平板）。”

  2. S-CSCF-2发现信息缺失：S-CSCF-2将HSS返回的已注册私有身份列表（IMPI-1, IMPI-2）与自己当前存储的信息（只有IMPI-1）进行比较。它立刻发现：“我这里缺少IMPI-2的详细注册数据！”

  3. 请求“恢复信息”：为了补全数据，S-CSCF-2会立即向HSS发送一个新的SAR请求。这个请求非常特殊，它的Server Assignment Type被设置为NO_ASSIGNMENT。

    • 深度解析：NO_ASSIGNMENT这个类型又是一个关键信令。它告诉HSS：“我不是要为用户分配服务器，也不是要下载用户配置。我是在执行一次恢复操作，请把之前那个倒霉的S-CSCF-1备份在你那里的、关于这个用户的所有**恢复信息（Restoration Information）**都发给我。”

  4. HSS发送恢复数据：

If there are S-CSCF restoration information related to the Public User Identity stored in the HSS, the HSS shall send the S-CSCF restoration information together with the user profile in the SAA to the S-CSCF. The result code shall be set to DIAMETER_SUCCESS.

HSS收到NO_ASSIGNMENT请求后，便从其“备份数据库”中提取出S-CSCF-1之前存储的所有关于小张这个号码的恢复信息。这些信息可能非常详细，包括：

  • 所有已注册设备的Contact地址。
  • 每个设备的注册有效期。
  • 路径信息（Path headers）。
  • 安全关联信息等。

HSS将这些宝贵的恢复数据打包在SAA中发给S-CSCF-2。

  1. 数据恢复与业务一致性：S-CSCF-2收到这些恢复信息后，就在自己的内存中重建了小张所有设备（手机和平板）的完整注册上下文。现在，S-CSCF-2完全掌握了小张的业务状态，就如同S-CSCF-1从未发生过故障一样。此时若有电话呼入，S-CSCF-2将能够正确地将呼叫同时送往小张的手机和平板，保证了业务的完全一致性。

这个过程巧妙地利用HSS作为S-CSCF状态数据的中央备份和恢复中心，确保了即使在S-CSCF节点发生灾难性故障后，用户的多设备注册状态也能被完整、准确地恢复，体现了IMS架构设计的鲁棒性和高可用性。

4. 总结

本文通过商务精英小张的场景，深度剖析了3GPP TS 23.380规范中关于S-CSCF在注册流程中发生故障时的核心恢复机制。我们了解到：

  • I-CSCF作为故障的“第一发现者”，通过与HSS的特殊信令交互（请求CAPABILITIES或使用reselection indication），能够为用户找到一个新的、健康的S-CSCF。
  • 新的S-CSCF会将故障后的首次注册视为初始注册，以确保流程的干净和可靠。
  • 为了解决多设备注册状态不一致的问题，新S-CSCF会与HSS进行二次交互，通过NO_ASSIGNMENT请求类型，获取并恢复所有相关的S-CSCF恢复信息，从而重建完整的用户注册上下文。

这些机制共同构成了一套强大而精密的“应急预案”，确保了IMS网络在面对核心网元故障时，依然能够为用户提供连续、可靠的服务。在接下来的文章中，我们将继续跟随小张的旅程，探讨在通话过程中（主叫和被叫流程）S-CSCF发生故障时，网络又将如何应对。

FAQ环节

Q1：为什么在4.2.2的传统恢复流程中，I-CSCF需要向HSS请求S-CSCF的“能力（Capabilities）”，而不是直接让HSS分配一个新的S-CSCF地址？ A1：这是一个解耦和权责分离的设计。HSS负责存储用户的签约数据和S-CSCF的能力需求，它像是“需求提出方”。而I-CSCF则负责网络拓扑和负载均衡，它了解当前网络中哪些S-CSCF是可用的、负载情况如何，是“资源调度方”。由HSS提供能力要求，I-CSCF根据这些要求和实时的网络状况来选择最合适的S-CSCF，这种方式比HSS直接指定一个S-CSCF更加灵活和高效，能更好地实现负载均衡和容灾。

Q2：基于SBI的恢复流程（4.2.2A）中，“reselection indication”（重选指示）到底起到了什么关键作用？ A2：这个指示的核心作用是“上下文通知”。它像一个标签，明确告知接收方（新的S-CSCF和HSS）：“这次注册不是一次普通的注册，而是一次由于前序S-CSCF故障而引发的恢复性注册”。这使得HSS在收到新S-CSCF的注册信息时，能够放心地用它来覆盖旧的、已失效的S-CSCF信息，而不会误判为非法或冲突的注册。它简化了I-CSCF与HSS之间的交互，避免了额外的查询步骤，提高了恢复效率。

Q3：什么是“S-CSCF Restoration Information”？它和普通的用户签约数据（User Profile）有什么区别？ A3：用户签约数据是相对静态的，描述了用户“能用什么业务”，比如是否开通VoNR，签约的媒体策略等。而S-CSCF恢复信息是高度动态的，它描述了用户“当前业务的使用状态”，是用户与网络实时交互产生的结果。它包括具体的注册详情，如UE的IP地址和端口（Contact Header）、注册的有效期、P-CSCF的地址（Path Header）等。S-CSCF在重启后，仅有用户签约数据是无法恢复通话的，必须获取这些动态的恢复信息才能重建会话上下文。

Q4：在4.2.3的数据同步流程中，如果HSS发现某个用户的S-CSCF恢复信息丢失或者不完整，会发生什么？ A4：规范的设计是健壮的。如果HSS没有某个私有身份（如小张的平板）的恢复信息，那么S-CSCF-2在请求后也无法获取到。这意味着该设备事实上已经处于“非注册”状态。网络侧将无法主动联系到这个设备。通常，该设备（平板）自身的IMS客户端会因为周期性重注册失败或发现与网络的连接丢失，而主动发起一次全新的IMS初始注册。这次注册会重建其在网络中的所有状态，从而最终解决数据不一致的问题。

Q5：如果一个新的S-CSCF在恢复了一个用户的部分数据后自己也发生了故障，IMS网络会如何处理？ A5：IMS的恢复机制是无状态和可重入的。如果新的S-CSCF-2在恢复过程中也失败了，整个流程会从头再来一遍。当用户的UE下一次发起注册时（可能是因为上一次注册没有收到200 OK而重试），I-CSCF会发现S-CSCF-2也失联了，然后它会再次执行S-CSCF的重选流程，找到S-CSCF-3。整个恢复过程不依赖于前一个S-CSCF的状态，保证了即使在连续故障的极端情况下，只要网络中还有可用的S-CSCF，最终总能完成恢复。

关系图谱