51学通信

深度解析 3GPP TS 23.527：4.4 SMF Restoration Procedures (SMF恢复机制)

24分钟阅读

深度解析 3GPP TS 23.527：4.4 SMF Restoration Procedures (SMF恢复机制)

本文技术原理深度参考了3GPP TS 23.527 V18.5.0 (2024-09) Release 18规范中，关于“4.4 SMF Restoration Procedures”的核心章节，旨在为读者提供一个当5G核心网的“大脑”——SMF发生故障时，网络如何实现自我修复与业务接管的全景视图。

前言：当生产线上的“大脑”遭遇“宕机”

在上一篇文章中，我们探讨了当用户面功能（UPF）——网络的“强壮臂膀”发生故障时，5G系统如何快速恢复。我们以工业质检摄像头“鹰眼-01”为例，见证了控制面的SMF如何像一位沉着冷静的指挥官，为“失忆”的UPF重建指令，确保生产线数据流的连续性。

然而，一个更严峻的问题摆在我们面前：如果指挥官本身，也就是SMF（会话管理功能）自身发生了故障，又将是何种景象？SMF是5G会话管理的“大脑”，它掌管着所有PDU会话的生命周期、QoS策略、计费规则以及用户面路径的选择。一个SMF的失效，其影响范围远超单个UPF，可能导致其管理下的成千上万个会话瞬间“群龙无首”。

为了应对这种核心节点的单点故障风险，3GPP引入了“SMF Set”的概念——一个由多个SMF实例组成的、具备高可用性的集群。本文将继续以“鹰眼-01”的场景为线索，深入剖析当SMF发生重启或彻底故障时，尤其是当它作为SMF Set的一员时，UPF以及整个5G系统是如何协同工作，实现会话的无缝接管，确保“鹰眼-01”的质检任务不受中断。这不仅仅是技术的博弈，更是对5G网络“五高一强”中“高可靠性”承诺的直接兑现。

1. SMF故障恢复的基本原则 (基于TS 23.527 4.4.1)

首先，我们需要理解SMF故障带来的直接后果以及恢复机制的核心思想。

4.4.1 General When a SMF fails, all its PDU session contexts and PFCP associations affected by the failure may become invalid and may be deleted.

这句话描绘了最糟糕的情况：如果一个孤立的SMF发生故障，它内存中所有的会话上下文（比如“鹰眼-01”的QoS是5ms，数据要发往AI服务器B等信息）以及它与所有UPF建立的PFCP控制关联，都可能永久丢失。这对于网络来说是灾难性的。

然而，现代电信网络的设计哲学是“假设一切都可能失败”（Design for Failure）。因此，3GPP引入了SMF Set作为关键的冗余机制。

When the SMF that fails is deployed as part of an SMF set, the PDU session contexts that were served by that SMF are maintained by the SMF set. The MPAS and SSET procedures specified for SMF set in clause 5.22 of 3GPP TS 29.244 enable the restarted SMF to continue serving its own PFCP sessions, or other SMFs of an SMF set to take over seamlessly the PFCP sessions that were served by the SMF that fails.

这是整个SMF恢复机制的灵魂所在。当故障的SMF隶属于一个SMF Set时，情况发生了根本性的转变。

  • 会话上下文被“维护”：PDU会话信息不再仅存于单个SMF的内存中，而是由整个SMF Set共享和维护。这通常通过一个高可用的后端数据库或分布式内存同步机制实现。
  • 无缝接管成为可能：规范中提到的MPAS（Multi-homed PDU Session Anchor）和SSET（Session and Service Continuity）等高级特性，使得SMF Set内的其他健康成员能够“无缝地”接管故障SMF所服务的PFCP会话。

在我们的场景中，这意味着管理“鹰眼-01”的SMF（我们称之为SMF-Alpha）是“智能工厂SMF Set”的一员。即使SMF-Alpha宕机，会话上下文依然安全地保存在Set的共享存储中，它的兄弟节点SMF-Bravo随时可以挺身而出。

If F-TEID allocation is performed in the SMF, the SMF should ensure as far as possible that previously used F-TEID values are not immediately reused after a SMF restart, in order to avoid inconsistent TEID allocation throughout the network.

与UPF恢复类似，这里也强调了F-TEID（GTP隧道端点标识）的重用“冷静期”。一个刚刚重启的SMF不应该立即将它之前分配过的隧道ID用于新的会话，以防网络中其他节点（如UPF）还未完全清理旧会话的状态，从而导致隧道冲突。

2. 指挥官的归来：SMF重启恢复程序 (基于TS 23.527 4.4.2)

当SMF经历了一次重启并重新上线后，网络需要一套明确的流程来恢复其功能。这个流程根据SMF是独立部署还是作为SMF Set成员而有显著不同。

2.1 独立SMF的重启 (General, 基于4.4.2.1)

这是没有冗余保护的基础场景。

4.4.2.1 General During or immediately after a SMF Restart, the SMF shall place local SMF-C Recovery Time Stamp value in all Heartbeat Request/Response messages. The UPF will receive the SMF recovery time stamps in PFCP heartbeat requests/responses.

重启后的SMF-Alpha会立刻在与所有UPF的心跳消息中，附上自己全新的“恢复时间戳”，宣告自己的“重生”。

When a UPF detects that a peer PFCP entity in the SMF has restarted (as specified in clause 4.2), the UPF shall delete all session contexts affected by the PFCP entity restart that it may have stored.

UPF收到这个新的时间戳后，它的反应是果断而决绝的：“我的指挥官重启了，他已经失忆了。他之前给我的所有命令（会话上下文）都已经作废，我必须全部清除！”

When the UPF receives a GTP-U PDU not matching any PDRs, it shall discard the GTP-U PDU and return a GTP error indication to the originating node (e.g. other UPF, gNB or N3IWF).

清除了所有规则后，当UPF再收到“鹰眼-01”的数据包时，它会因为找不到匹配的PDR而将其丢弃，并向上游节点返回一个GTP错误指示。最终，这将导致PDU会话被从网络侧释放。

结论：对于独立SMF，一次重启就意味着其管理的所有会话中断，需要终端重新发起连接才能恢复。

2.2 SMF Set中成员的重启 (基于4.4.2.2)

这是高可用性设计的精髓所在，也是现代5G网络部署的常态。

场景：SMF-Alpha因为升级而重启，但它是“智能工厂SMF Set”的一员。

4.4.2.2 Restart of an SMF in an SMF Set During or immediately after the restart of an SMF in an SMF set, using the MPAS or SSET procedure… the SMF shall not modify the local SMF Recovery Time Stamp value in its Heartbeat Request/Response messages.

这是一个非常关键且违反直觉的规定。重启的SMF-Alpha在心跳消息中，并不会更新自己的恢复时间戳。为什么？因为UPF的关联对象并非SMF-Alpha这个“个体”，而是整个“SMF Set”这个“集体”。只要SMF Set本身是健康的（共享数据没有丢失），那么从UPF的视角看，它的“指挥官集体”就没有经历重启。

Accordingly, the UPF does not detect that the peer PFCP entity in the SMF has restarted and will not delete the session contexts that were served by the restarted PFCP entity in the SMF.

正是因为时间戳没有变化，UPF不会认为SMF发生了重启，因此它会继续保留所有由SMF-Alpha建立的会话上下文。网络的稳定性得到了维持。

When re-establishing its PFCP association with the UPF, the restarted SMF shall set the PFCP Session Retention Information IE to request the UPF to retain all its existing PFCP sessions… Accordingly, the UPF shall retain all PFCP sessions that were established with the existing PFCP association…

重启后的SMF-Alpha在与UPF重建PFCP关联时，会携带一个名为“PFCP会话保留信息”的特殊指示。这个指示等于在告诉UPF：“兄弟，我（SMF-Alpha）刚刚重启了，但我属于一个团队。请务必保留我们之前建立的所有会话，不要删除它们。” UPF收到这个请求后，便会遵从指令，保持“鹰眼-01”等会话的上下文完整无损。

结论：在SMF Set架构下，单个成员的重启对业务是透明的。UPF会保留所有会话，重启的SMF能够从Set的共享数据中恢复状态，业务得以延续。

3. 指挥官的“阵亡”：SMF彻底故障恢复 (基于TS 23.527 4.4.3)

现在我们来讨论更极端的情况：SMF-Alpha彻底宕机，无法重启恢复。

3.1 独立SMF的故障 (General, 基于4.4.3.1)

4.4.3.1 General When a UPF detects that a peer PFCP entity in the SMF is not reachable for a preconfigured time, and the MPAS or SSET procedure… are not used, the UPF shall delete all the session contexts affected by the peer PFCP entity failure…

如果SMF-Alpha是独立部署的，UPF在连续多次心跳探测失败后，会确认它的指挥官已经“阵亡”。在没有备用指挥官的情况下，UPF只能执行“战时条例”：销毁所有与该SMF相关的会话上下文，导致业务全面中断。

3.2 SMF Set中成员的故障 (基于4.4.3.2)

这是展现SMF Set价值的决定性时刻。

场景：UPF通过心跳机制发现SMF-Alpha失联，且迟迟没有恢复。

4.4.3.2 Failure of an SMF in a SMF set When the MPAS or SSET procedure… is used, when the UPF detects that a peer PFCP entity in an SMF is not responsive…, the UPF shall move the PFCP sessions that were served by the failed PFCP entity to another PFCP entity in the same SMF or another SMF…

UPF并不会删除会话，而是启动“指挥权移交”程序。它需要将由SMF-Alpha管理的会话，“移动”给SMF Set中的另一个健康成员，例如SMF-Bravo。

规范中的 Figure 4.4.3.2-1: Failure (without restart) of an SMF in an SMF set using the MPAS or SSET feature 清晰地展示了这一过程。

我们来一步步拆解这个核心流程：

  1. 初始状态：SMF Set中的SMF1(Alpha), SMF2(Bravo), SMF3都与同一个UPF建立了PFCP关联。它们在建立关联时，会告诉UPF彼此是“备胎”关系（通过Alternative SMF IP Address IE）。SMF1(Alpha)正在为“鹰眼-01”的会话提供服务。

  2. 故障发生：SMF1(Alpha)突然故障。

  3. UPF检测与触发：UPF通过心跳机制，发现SMF1(Alpha)长时间无响应。它知道SMF1有备份（SMF2和SMF3），于是决定启动会话迁移。

  4. UPF向新SMF汇报：UPF会选择一个备用SMF，比如SMF2(Bravo)，并向它发送一个PFCP Session Report Request（会话报告请求）消息。这个消息是整个流程的关键，它包含了：

    • 旧SMF的身份标识 (old CP F-SEID)：UPF告诉SMF2，“我需要汇报一个会话的情况，这个会话之前是由你的同事（由old CP F-SEID标识的SMF1）负责的。”
    • 会话SEID设为null/zero：表示UPF并非要创建一个新会话，而是在为一个已存在的会话寻找新的控制方。

  5. 新SMF接管：SMF2(Bravo)收到请求后，凭借old CP F-SEID，在SMF Set的共享数据库中查询到了这个会话的完整上下文信息。它随即确认自己有能力接管，并将该会话的控制权掌握在自己手中。

  6. 新SMF确认接管：SMF2(Bravo)向UPF回复一个PFCP Session Report Response消息。这个消息中包含了它自己的身份标识 (new CP F-SEID)。这相当于SMF2在告诉UPF：“收到！从现在起，我就是这个会话的新指挥官。以后关于这个会话的所有事情，请用这个新的ID来向我汇报。”

  7. 无缝切换完成：UPF更新了本地的会话上下文，将控制方从SMF1(Alpha)的F-SEID更新为SMF2(Bravo)的F-SEID。至此，控制权的交接在控制面悄然完成。

对于正在传输高清视频的“鹰眼-01”来说，它的用户面数据流在这整个过程中，几乎没有受到任何影响，依旧平稳地在UPF中被处理和转发。这就是SMF Set带来的高可靠性保障。

4. N4路径故障的特殊说明 (基于TS 23.527 4.5)

规范还简要提及了一种特殊情况——N4路径故障。

4.5 N4 path failure If the N4 path to the UPF is down, the SMF should handle this as an UPF Failure without Restart, see clause 4.3.3. If the N4 path to the SMF is down, the UPF should handle this as a SMF Failure without Restart, see clause 4.4.3.

这是一个逻辑上的归类说明。它指出，如果SMF和UPF之间的网络链路（即N4接口的承载网络）中断，虽然两个网元本身可能都是健康的，但从对端的视角来看，其行为等同于“节点故障但未重启”。

  • SMF看UPF：N4路径中断，SMF无法联系到UPF，这在处理上等同于我们上一篇文章中提到的“UPF Failure without Restart”。
  • UPF看SMF：N4路径中断，UPF无法联系到SMF，这在处理上就等同于本文刚刚讨论的“SMF Failure without Restart”。

因此，处理流程将完全复用4.3.3和4.4.3章节中定义的机制，特别是对于部署了SMF Set的场景，路径故障同样可以触发无缝的会话控制权移交。

5. 总结

SMF作为5G核心网的智慧中枢，其稳定性直接决定了整个网络的服务质量。3GPP TS 23.527通过引入SMF Set的概念，并围绕其设计了一套精密的恢复与接管机制，极大地提升了网络的可靠性。

  1. 冗余是关键：独立SMF的故障是灾难性的，而SMF Set通过共享会话上下文，为故障恢复提供了根本性的保障。
  2. 重启与故障的差异化处理：
    • 对于Set内成员重启，通过“不更新时间戳”和“会话保留”指示，实现了对业务的透明恢复。
    • 对于Set内成员彻底故障，通过UPF发起的、携带旧SMF标识的“会话报告”流程，实现了控制权的无缝迁移。
  3. UPF的角色：在SMF恢复中，UPF不再仅仅是执行者，它还扮演着故障“监测哨”和会话迁移“发起者”的关键角色，是整个高可用体系中不可或缺的一环。

在智能工厂的场景中，正是这套复杂的机制在背后默默守护。当SMF-Alpha倒下时，SMF-Bravo能够立即接替它的工作，确保“鹰眼-01”的“火眼金睛”永远在线，为生产线的质量安全站好每一班岗。这便是5G技术在垂直行业应用中，真正从“能用”走向“好用”和“可靠”的核心价值所在。

FAQ

Q1：UPF是如何知道一个SMF属于某个SMF Set，以及Set里有哪些其他的SMF成员作为备份的？

A1：这些信息是在PFCP关联建立阶段由SMF告知UPF的。当一个SMF（如SMF-Alpha）与UPF建立PFCP关联时，它可以在PFCP Association Setup Request消息中包含一个或多个Alternative SMF IP Address信息元（IE）。这些IP地址就是SMF Set中其他成员（如SMF-Bravo）的地址。UPF收到后会缓存这些信息，一旦检测到主SMF失联，它就知道可以向这些备用地址发起会话迁移请求。

Q2：SMF Set中的多个SMF实例是如何做到会话信息同步的？规范对此有要求吗？

A2：3GPP规范主要定义网元之间接口的行为（即“黑盒”外部特性），而对于网元内部以及同类网元之间的实现细节（“黑盒”内部）则给予厂商较大的自由度。SMF Set成员间如何同步会话上下文，属于后者。业界的常见实现方式包括：

  • 后端共享数据库：所有SMF实例都连接到一个高可用的分布式数据库（如TiDB, CockroachDB），会话上下文实时写入该数据库。
  • 内存复制/同步：SMF实例之间通过内部的高速接口直接进行状态同步和内存复制，性能更高但实现更复杂。 无论哪种方式，其目标都是确保任何一个SMF实例写入的会话状态，能被其他所有实例近乎实时地读取到。

Q3：在SMF Set中，当一个SMF故障，UPF将会话迁移到另一个SMF后，计费会受影响吗？

A3：理论上不应受大的影响。因为会话的计费信息（如已用流量、时长等）也是PDU会话上下文的一部分，同样被存储在SMF Set的共享数据中。当SMF-Bravo接管会话时，它会从共享存储中读取到该会话最新的计费信息，并在此基础上继续累加。因此，可以保证计费的连续性和准确性，避免了因SMF切换而导致的计费信息丢失或重复计费。

Q4：为什么SMF Set中单个成员重启时，它在心跳中“不更新”恢复时间戳？这听起来很奇怪。

A4：这是为了“欺骗”UPF，让它认为什么都没有发生，从而避免UPF执行默认的“删除所有会话”操作。这里的关键是区分“个体”和“集体”的“生命周期”。恢复时间戳代表的是一个PFCP关联端点的生命周期。在SMF Set架构下，UPF逻辑上是与整个“SMF Set”这个集体建立关联，而不是与SMF-Alpha这个个体。只要Set的共享数据是完整的，这个“集体”就没有“重启”。因此，即使作为物理实例的SMF-Alpha重启了，它也必须使用代表“集体”生命周期的、未改变的时间戳，以维持UPF对会话的信心。

Q5：当UPF将会话从失败的SMF-Alpha无缝切换到SMF-Bravo时，对正在通信的终端（UE）来说，这个过程是完全透明的吗？

A5：是的，这个过程对UE是完全透明的。整个切换过程发生在核心网内部的N4接口上，是控制面的操作。UE与核心网之间的N1接口（信令面）和N3接口（用户面）均不受影响。UE的IP地址保持不变，与RAN侧的连接也保持不变，用户数据包继续通过N3接口在RAN和UPF之间传输。因此，无论是“鹰眼-01”摄像头还是普通用户手机，都不会感知到核心网内部发生了一次SMF的“指挥权交接”。

关系图谱