51学通信

深度解析 3GPP TS 23.527：6.1-6.2 SBA恢复机制 (Part 1 - NRF的“上帝视角”)

22分钟阅读

深度解析 3GPP TS 23.527：6.1-6.2 SBA恢复机制 (Part 1 - NRF的“上帝视角”)

本文技术原理深度参考了3GPP TS 23.527 V18.5.0 (2024-09) Release 18规范中，关于“6.1 General”和“6.2 NF (NF Service) Failure and Restart Detection using the NRF”的核心章节，旨在为读者揭示5G服务化架构（SBA）下，作为“注册中心”和“服务总线”的NRF，是如何扮演网络故障的“吹哨人”角色，实现对网元故障与重启的集中式检测与通知。

前言：当自动驾驶的“大脑”与“中枢”失联

在之前的旅程中，我们跟随自动驾驶汽车“智行一号”，探索了5G网络在用户面（N3/N9）和控制面-用户面接口（N4）上的恢复机制。我们看到了网络如何应对基站的“失忆”、UPF的“宕机”和SMF的“指挥权交接”。然而，这些场景大多还带有传统移动网络的影子——基于点对点的隧道和接口。5G核心网的真正革命，在于其全新的服务化架构（Service-Based Architecture, SBA）。

在SBA的世界里，核心网功能（NF）不再是功能固化的、通过点对点接口连接的“黑盒子”，而是演变成了一个个提供标准API接口的“微服务”。AMF需要会话管理服务时，它不再是连接一条固定的N11接口，而是像在互联网上调用一个Web Service一样，去“发现”并“消费”由SMF提供的服务。这个发现和消费的过程，完全依赖于整个SBA架构的基石——NRF（Network Function Repository Function），网络的“注册中心”与“黄页”。

现在，让我们设想一个全新的挑战：“智行一号”驶入一座新的城市，其服务AMF（我们称之为“AMF-Gatekeeper”）需要为它建立一个超低时延的V2X数据会话。AMF-Gatekeeper向NRF查询，NRF告诉它，本地最优的会话管理器是“SMF-SessionMaster”。AMF-Gatekeeper随即与SMF-SessionMaster通过服务化接口建立了联系。但如果SMF-SessionMaster所在的服务器突然断电，或者它提供的会话管理服务因软件bug而崩溃，AMF-Gatekeeper如何得知这个噩耗？它难道要等到下一次请求超时才后知后觉吗？本篇文章，我们将深入SBA的神经中枢，揭示NRF是如何扮演“上帝视角”的观察者，主动地检测故障，并向全网广播“讣告”，从而启动整个SBA体系的故障恢复流程。

1. SBA恢复哲学的基石 (基于TS 23.527 6.1)

SBA的恢复机制建立在几个核心概念之上，这些概念为动态、弹性的故障处理奠定了基础。

6.1 General A NF may detect a failure or a restart of a peer NF or NF service using the NRF as specified in clause 6.2. A NF may also detect a restart of a peer NF or NF service by receiving recovery time information in signalling exchanged with that peer NF or NF service.

规范开篇就指明了SBA中故障检测的两大路径：

  1. 通过NRF检测：一种集中式的、基于订阅-通知的模式，这是本文的重点。
  2. 通过直接信令检测：一种点对点的、在业务交互中顺便传递恢复信息的方式，我们将在后续文章中探讨。

1.1 从“个体”到“集群”：NF (Service) Set

When NF (Service) Set is deployed in the network… an NF Service Producer in a NF (Service) Set creates resource contexts and the context data is shared by all the NF (Service) instances pertaining to the same NF (Service) set… requests targeting the resource may be served by any NF (Service) Instance within the NF (Service) set…

SBA将高可用性的理念贯彻到底。单个NF实例（NF Instance）可以组成一个NF Set，单个服务实例（NF Service Instance）可以组成一个NF Service Set。

  • 场景演绎：“SMF-SessionMaster”并非一个人在战斗，它隶属于一个“城市边缘计算SMF Set”。这个Set里的所有SMF实例共享同一个后端数据库，保存着“智行一号”等车辆的会话信息。
  • 核心价值：当AMF-Gatekeeper与“SMF-SessionMaster”交互并创建了会话资源后，这个资源实际上是属于整个SMF Set的。这意味着，即使“SMF-SessionMaster”实例失效，Set中的其他健康成员也能够无缝地接手处理后续的请求。

1.2 故障恢复的“时间戳”与“绑定”

…the NF Service Producer may provide a recovery timestamp associated to the highest resiliency level that it supports for the resource context, i.e. the binding entity with which the context data is shared (bound). Binding entities are sorted from the highest to the lowest resilience levels as follows: an NF Set, NF Instance, NF service set or NF service instance.

这是SBA恢复机制中一个极其精妙的设计：

  • Recovery Timestamp (恢复时间戳)：每个NF或NF Set在启动/重启时都会有一个时间戳，代表了其“上下文”的“创世时间”。
  • Binding Entity (绑定实体)：一个资源（如“智行一号”的会话上下文）可以被“绑定”到不同层级的实体上。绑定的层级越高，代表其弹性（resiliency）越强。
    • 绑定到NF Set：最高级别。表示上下文由整个集群共享，单个实例的重启不会导致上下文丢失。其恢复时间戳是整个Set的创建/重启时间。
    • 绑定到NF Instance：较低级别。表示上下文仅存在于该实例内存中。实例一旦重启，上下文就会丢失。其恢复时间戳是该实例的重启时间。
  • 作用：一个NF Consumer（如AMF-Gatekeeper）在与Producer交互时，会收到这个时间戳和它绑定的实体层级。当它后续发现Producer的时间戳变新了，它就能根据绑定的层级判断出自己创建的资源是否已经丢失。如果绑定在NF Set，而只是一个Instance重启，那么资源安然无恙；如果绑定在Instance，那资源就凶多吉少了。

2. NRF的“上帝视角”：基于NRF的故障与重启检测 (基于TS 23.527 6.2)

NRF作为所有NF的注册中心，天然具备了监控全网NF健康状态的“上帝视角”。

6.2.1 General This clause describes optional procedures that may be supported by NFs to detect the failure or restart of a NF or a NF service using the NRF.

2.1 场景一：NF实例的彻底“死亡” (基于6.2.2, Figure 6.2.2-1)

这是最直接的故障场景：整个NF实例（例如，运行SMF-SessionMaster的虚拟机）彻底崩溃。

规范中的 “Figure 6.2.2-1: NF Failure Detection and Notification” 描绘了这一过程。

我们结合场景来分解这个流程：

  1. 订阅“生死簿” (Step 1)

    1. NF A subscribes to the NRF to receive notifications of changes of the NF B Profile… AMF-Gatekeeper在通过NRF发现SMF-SessionMaster后，为了防患于未然，它会向NRF发起一个订阅请求。请求内容是：“尊敬的NRF，请密切关注SMF-SessionMaster的动态。一旦它的状态有任何风吹草动，请立刻通知我。”

  2. 故障发生 (Step 2)

    2. A NF failure occurs at NF B. 运行SMF-SessionMaster的服务器突然断电，SMF-SessionMaster与网络彻底失联。

  3. NRF的“心跳”检测 (Step 3)

    3. The NRF detects that NF B is no longer operative using the NF Heart-Beat procedure… The NRF changes the NFStatus of NF B to SUSPENDED. NRF并不会坐等NF来报告自己的死亡。它会周期性地向所有已注册的NF实例发送“心跳”探测（NF Heart-Beat）。当NRF连续多次无法收到SMF-SessionMaster的心跳响应时，它就会做出判断：“SMF-SessionMaster已经失联”。随即，NRF会在自己的数据库中，将SMF-SessionMaster的NFStatus（网络功能状态）标记为**SUSPENDED（暂停）**。

  4. 发布“讣告” (Step 4)

    4. The NRF notifies NFs having subscribed to receive notifications of changes of the NF B Profile that the NFStatus of NF B is changed to SUSPENDED. 因为AMF-Gatekeeper之前订阅过，所以NRF会立刻向它发送一个状态变更通知（Nnrf_NFManagement_NFStatusNotify）。通知内容很简单：“你所关注的SMF-SessionMaster，其状态现已变更为SUSPENDED。”

  5. 启动恢复 (Step 5)

    5. NF A may trigger appropriate restoration or clean-up actions… 收到“讣告”后，AMF-Gatekeeper立刻明白它的合作伙伴已经“阵亡”。它会立即启动恢复程序：例如，清理与SMF-SessionMaster相关的旧有上下文；对于新的会话请求，它会重新向NRF查询，寻找一个健康的SMF实例（比如“城市边缘计算SMF Set”中的另一个成员）。

2.2 场景二：NF服务的“局部坏死” (基于6.2.2, Figure 6.2.2-2)

这种情况更为微妙：NF实例本身是活的，但它提供的某项特定服务却失效了。

规范中的 “Figure 6.2.2-2: NF Service Failure Detection and Notification” 描绘了此场景。

  1. 订阅 (Step 1): 同上，AMF-Gatekeeper订阅了SMF-SessionMaster的profile变更。

  2. 服务故障 (Step 2)

    2. A NF Service failure occurs at NF B. NF B (other than the failed NF Service) is still operative. SMF-SessionMaster的进程本身没有崩溃，心跳也正常。但由于一个数据库连接池耗尽的bug，它提供的Nsmf_PDUSession服务（用于创建和管理PDU会話）无法正常工作了。

  3. 主动上报病情 (Step 3)

    3. NF B (or OAM) updates its NF Profile in the NRF, by setting the NFServiceStatus of the failed NF Service to SUSPENDED. 在这种情况下，NRF的心跳机制是无能为力的。此时，需要SMF-SessionMaster主动（或者由其运维管理系统OAM代劳）向NRF发送一个NF Profile更新请求。请求内容是：“报告NRF，我的Nsmf_PDUSession服务现在不可用了，请将它的NFServiceStatus（网络功能服务状态）标记为SUSPENDED。”

  4. 发布“病危通知” (Step 4 & 5) NRF收到这个更新后，同样会通知所有订阅者。AMF-Gatekeeper收到通知后，便知道了SMF-SessionMaster的这项特定服务已不可用，它会避免再向其发送创建会话的请求，而是去寻找其他能提供此服务的SMF。

2.3 场景三：NF的“失忆”重启 (基于6.2.3, Figure 6.2.3-1)

重启，意味着NF实例的进程恢复了，但内存中的动态数据（上下文）可能已经丢失。

规范中的 “Figure 6.2.3-1: NF Restart Detection and Notification” 描绘了此场景。

  1. 注册与订阅 (Step 1 & 2) SMF-SessionMaster在最初向NRF注册时，它的Profile中就包含了一个关键字段：recoveryTime，即我们之前提到的恢复时间戳。AMF-Gatekeeper同样订阅了它的Profile变更。

  2. 重启发生 (Step 3)

    3. NF B restarts. SMF-SessionMaster因软件升级而重启。

  3. 更新“创世时间” (Step 4)

    4. If contexts are lost during the restart, NF B (or OAM) updates the recoveryTime in its NF Profile in the NRF. 重启完成后，SMF-SessionMaster做的第一件事，就是带着一个全新的、当前时间的recoveryTime，重新向NRF注册。这个动作，等于在向全网宣告：“我已重生，此前的种种譬如昨日死。”

  4. 发布“重生”公告 (Step 5) NRF检测到recoveryTime字段发生了变化，立即向所有订阅者（包括AMF-Gatekeeper）通知这一变更。

  5. 判断并清理 (Step 6)

    6. NF A may consider that all the resources created in the NF B before the NF B recovery time as have been lost. NF A triggers then appropriate restoration or clean-up actions. AMF-Gatekeeper收到通知，看到新的recoveryTime。它会与自己之前为“智行一号”创建会话时记录的那个旧recoveryTime进行比较。如果发现自己创建资源的时间早于这个新的“创世时间”，它就明白，自己当年创建的那个“王朝”已经被这次“重启”彻底推翻了。于是，AMF-Gatekeeper会启动清理程序，删除所有与旧会话相关的上下文，并在需要时重新发起业务流程。

4. 总结

NRF在5G服务化架构的可靠性中扮演了无可替代的核心角色。它所主导的集中式故障检测机制，将SBA的灵活性和弹性提升到了新的高度：

  1. 变被动为主动：NF Consumer不再需要通过一次次的请求超时来被动地猜测Producer的状态，而是可以通过订阅NRF，主动、及时地获取精准的故障和重启信息。
  2. 故障信息的精细化：NRF的通知机制能够清晰地区分NF实例故障（整个节点不可达）、NF服务故障（节点存活但部分功能失效）和NF重启（节点恢复但上下文可能丢失）这三种截然不同的场景，使得Consumer能够采取最恰当的恢复策略。
  3. 解耦与可扩展性：Producer的健康状态由其自身和NRF来维护，Consumer只需关心NRF的通知即可。这种松耦合的设计，使得整个系统的可靠性管理变得极为清晰和可扩展。

回到“智行一号”的场景，当AMF-Gatekeeper需要与SMF-SessionMaster协作时，NRF就像一个24小时待命的哨兵。无论是SMF彻底崩溃，还是其服务暂时不可用，亦或是它经历了一次失忆性重启，NRF都会在第一时间吹响号角，让AMF-Gatekeeper能够迅速做出反应，为“智行一号”寻找新的服务路径，确保其数字生命线的永不中断。

FAQ

Q1：NRF是如何知道一个NF实例已经“死亡”（Failure）的？它会一直等心跳超时吗？

A1：NRF主要通过其NF心跳（Heart-Beat）机制来检测NF实例的存活。每个在NRF注册的NF实例都需要周期性地向NRF“报平安”。如果NRF在连续几个周期内都没有收到某个NF实例的心跳，就会判定该NF实例发生故障，并将其状态更新为SUSPENDED。这是一个主动探测的过程，而非被动等待。

Q2：NF故障（NF Failure）和NF服务故障（NF Service Failure）有什么根本区别？

A2：根本区别在于故障的范围和影响。

  • NF Failure：指的是整个NF实例不可用，例如虚拟机/容器崩溃、服务器断电。这意味着该实例提供的所有服务都将中断，并且NRF的心跳也会失败。
  • NF Service Failure：指的是NF实例本身还在运行，心跳正常，但其提供的某一项或几项特定服务因内部原因（如软件bug、资源耗尽）而无法工作。这是一种更细粒度的、局部性的故障。

Q3：为什么规范说“通过NRF的检测程序”是可选的（optional）？难道还有网络可以不实现它吗？

A3：规范将其定义为“可选”，是考虑到SBA提供了多种恢复机制。除了通过NRF的集中式检测，NF之间还可以通过直接信令（将在下一篇文章中详述）来交换恢复信息。在某些特定的、交互频繁的NF对之间，直接检测可能比绕道NRF更快。然而，在实际的大规模商用网络中，基于NRF的订阅/通知机制因其普适性和解耦的优越性，是构建整个SBA可靠性体系的事实标准和基础。一个不实现此机制的SBA网络，其可靠性将大打折扣。

Q4：当一个NF重启并更新了recoveryTime后，消费方（Consumer）是如何利用这个时间戳来精确判断哪些资源丢失了？

A4：消费方在每次成功与生产方（Producer）创建一个需要长期维持的资源（如一个PDU会话上下文、一个订阅关系等）时，都应该缓存当时生产方的recoveryTime，并将它与这个资源关联起来。当收到来自NRF的recoveryTime更新通知后，消费方会遍历自己所有与该生产方相关的资源，比较每个资源当初创建时缓存的recoveryTime和收到的新recoveryTime。如果（缓存的旧时间戳 < 新的恢复时间戳），就意味着这个资源是在生产方“重生”之前创建的，已经被“历史的尘埃”所掩埋，即判定为已丢失，需要清理。

Q5：如果一个NF实例属于一个NF Set，当这个实例重启时，它上报给NRF的recoveryTime是它自己的重启时间，还是整个Set的时间？

A5：这取决于**上下文绑定（Binding）**的级别。规范在6.1节中提到，recoveryTime与“绑定实体”相关联。

  • 如果上下文是绑定到NF Instance级别（即上下文只存在于该实例内存中），那么这个实例重启后，它必须上报自己新的重启时间作为recoveryTime，以通知大家它的私有上下文已丢失。
  • 如果上下文是绑定到NF Set级别（即上下文存储在共享数据库中，对所有实例可见），那么单个实例的重启并不会影响共享上下文。在这种情况下，该实例重启后，它上报的应该是代表整个NF Set生命周期的recoveryTime，这个时间戳在单个实例重启时是不会改变的。这样，消费方看到时间戳没变，就知道自己绑定到Set的资源是安全的。

关系图谱