51学通信

深度解析 3GPP TS 23.527：9 网络授时状态监控恢复 (TSCTSFTSN篇)

20分钟阅读

深度解析 3GPP TS 23.527：9 网络授时状态监控恢复 (TSCTSF/TSN篇)

本文技术原理深度参考了3GPP TS 23.527 V18.5.0 (2024-09) Release 18规范中，关于“9 Restoration Procedures for Network Timing Synchronization Status Monitoring”的核心章节。本文旨在为读者揭示5G网络在支撑未来工业4.0、自动驾驶等时间敏感型应用时，其核心的“节拍器”——网络授时系统在遭遇故障时的精密恢复机制。

前言：当“机器人交响乐”遭遇“节拍器”失灵

在未来高度自动化的智能工厂中，一支名为“Robo-Arm Quartet”的机器人手臂四重奏，正在进行一台航空发动机涡轮叶片的高精度装配。它们的每一个旋转、抓取、焊接动作，都必须在亚毫秒级别上完美同步，如同演奏一曲精密的工业交响乐。任何一个微小的时钟偏差，都可能导致叶片安装角度错误，甚至引发机器人间的灾难性碰撞。

这场“机器人交响乐”的完美演绎，依赖于5G的一项革命性技术——时间敏感网络（Time-Sensitive Networking, TSN）。而为整个工厂网络提供统一、高精度时间基准的，正是5G核心网中的一个全新角色——TSCTSF（Time Sensitive Communication and Time Synchronization Function），网络的“主节拍器”。

为了确保时间同步的万无一失，TSCTSF并不仅仅是“授时”，它还需要监控时间的传递质量。它会向网络中的“现场工头”——**NG-RAN（基站）**订阅“授时状态报告”。这条监控链是：TSCTSF <-> AMF (区域经理) <-> NG-RAN。

现在，一场控制面的危机正在酝酿。如果作为“主节拍器”的TSCTSF、“区域经理”AMF、或是“现场工头”NG-RAN，其中任何一环发生故障，整个授时监控体系就会崩溃。“Robo-Arm Quartet”可能会在不知不觉中失去精准的节拍，酿成大错。3GPP TS 23.527第9章，正是为这支“交响乐团”的指挥体系量身定做的应急预案。

1. “节拍器”的指挥链：授时监控的基本流程 (基于TS 23.527 9.1)

在深入故障恢复之前，我们必须先理解这条授时监控的“指挥链”是如何建立的。

9.1 General This clause specifies the procedures supported in the 5G System to restore network timing synchronization status monitoring upon a failure affecting the AMF, NG-RAN or TSCTSF. The stage 2 procedures for network timing synchronization status monitoring are specified in clause 4.15.9.5 of 3GPP TS 23.502.

  • 深度解析：本章的使命，是为影响AMF、NG-RAN或TSCTSF这“铁三角”的故障，提供授时监控的恢复方案。而监控流程本身，则定义在TS 23.502这本更宏观的流程规范中。
  • 基本流程：
    1. **TSCTSF（主节拍器）**想要了解某个区域（例如，工厂A区）的时间同步质量。
    2. 它向管理该区域的**AMF（区域经理）**发起一个Namf_NonUeN2InfoSubscribe请求，订阅该区域内基站的“非UE相关的N2信息”，具体内容就是“授时状态（TSS）信息”。
    3. AMF收到订阅后，再向其管辖下的目标**NG-RAN（现场工头）**发送一个NGAP Timing Synchronization Status Request消息，指令gNB开始监控并上报TSS信息。
    4. 之后，gNB会周期性地将TSS报告通过AMF中转，送达TSCTSF。

这条指挥链的任何一环断裂，都会导致监控中断。

2. “区域经理”失联：AMF故障恢复 (基于TS 23.527 9.2)

第一类危机，发生在作为中间枢纽的AMF身上。

9.2 AMF failure with or without restart When an AMF instance fails with or without restart, the subscriptions for non-UE specific N2 information that were created at this AMF instance before the AMF failure are lost.

  • 深度解析：AMF的故障，无论是否重启，其后果都是灾难性的——它内存中所有由TSCTSF创建的订阅关系，都会丢失。AMF“忘记”了自己曾答应过TSCTSF要去gNB那里收集报告。

恢复的责任方：TSCTSF

恢复的责任，落在了最初的订阅发起者——TSCTSF身上。

Upon detecting that the AMF instance has failed with or without restart, a TSCSTF that had subscribed to TSS information reporting via the failed or restarted AMF instance should subscribe again to TSS information reporting… via the restarted AMF instance or via an alternative AMF instance from the same or a different AMF set…

  • 步骤一：TSCTSF的“察觉” TSCTSF通过我们在Part 2和Part 3中详细讨论的SBA恢复机制（例如，NRF的通知或直接信令调用失败），检测到它之前订阅的那个AMF实例已经“失联”。

  • 步骤二：TSCTSF的“重建订阅” TSCTSF必须重新发起一次完整的订阅流程。它会向NRF查询，找到一个健康的AMF（可能是刚刚重启的那个，也可能是AMF Set中的另一个成员），然后向这个新的AMF发送全新的Namf_NonUeN2InfoSubscribe和Namf_NonUeN2MessageTransfer请求。

NOTE 3: When a failure with or without restart affects only one AMF service instance, other AMF service instances of the same AMF instance can take over the subscriptions… seamlessly for the NG-RAN and TSCTSF.

  • 高可用保障：规范的注记指出了理想情况。如果AMF部署为高可用的集群（AMF Set），并且故障只影响了其中一个服务实例，那么Set内的其他实例可以无缝地接管订阅，整个恢复过程对TSCTSF和NG-RAN都是透明的。

场景演绎： 管理工厂A区的AMF-Factory-A突然崩溃。远端数据中心的“主节拍器”TSCTSF通过NRF收到了“讣告”。TSCTSF立刻查询NRF，发现AMF-Factory-A隶属于一个AMF Set，其健康的伙伴AMF-Factory-B仍在正常工作。于是，TSCTSF立刻向AMF-Factory-B重新发起了对工厂A区基站的授时状态监控订阅。监控链得以重建。

3. “现场工头”失忆：NG-RAN故障恢复 (基于TS 23.527 9.3)

第二类危机，发生在最前线的NG-RAN身上。

9.3 NG-RAN failure with or without restart When an NG-RAN node fails with or without restart, the subscriptions for TSS information reporting that were created at the NG-RAN node before the NG-RAN failure are lost.

  • 深度解析：gNB的故障，同样会导致其内存中所有关于“需要向AMF上报TSS信息”的订阅任务丢失。它“忘记”了TSCTSF交给它的监控任务。

恢复的责任方：AMF与TSCTSF协同

这次的恢复，需要AMF和TSCTSF的紧密配合。

Upon detecting that an NG-RAN node fails with or without restart, the AMF shall notify the TSCSTFs subscribed to TSS information reporting about the failure… by sending an Namf_NonUeN2InfoNotify request…

  • 步骤一：AMF的“发现与报告” AMF作为gNB的直接上级，它会通过N2接口心跳（SCTP）最先发现gNB的故障。AMF的责任是，立刻将这个“坏消息”，通过NonUeN2InfoNotify消息，通知所有曾订阅过这个gNB信息的TSCTSF。这份报告会明确指出是哪个gNB发生了故障。

接下来，根据故障类型的不同，TSCTSF的动作也有所区别。

  • 场景一：gNB无重启故障（“幽灵工头”）

    Upon being notified by the AMF of the NG-RAN failure without restart, the TSCSTF may log the information and should consider that no more TSS information can be received from the failed NG-RAN. AMF报告说gNB失联了。TSCTSF会记录下这个事件，并标记来自该gNB的监控数据流已经中断。它会进入等待状态，等待AMF后续的恢复通知。

  • 场景二：gNB重启故障（“失忆工头”）

    Upon being notified by the AMF of the NG-RAN failure with restart, the TSCTSF should subscribe again to TSS information reporting (by sending an Namf_NonUeN2MessageTransfer request… but without sending a Namf_NonUeN2InfoSubscribe request since the subscription already exists at the AMF)…

    AMF报告说gNB重启了。这是一个关键的区别：AMF与TSCTSF之间的总订阅关系在AMF侧仍然是有效的。失效的只是AMF与gNB之间的具体任务。因此，恢复流程被大大简化了：

    1. TSCTSF不需要重新发起...Subscribe请求。
    2. 它只需要重新发送一次...MessageTransfer请求，这个请求会携带那个NGAP Timing Synchronization Status Request消息。
    3. AMF收到后，直接将这个“任务指令”转发给刚刚重启的gNB，为其“注入记忆”。

结论：NG-RAN重启的恢复，比AMF重启的恢复更轻量。它只是一个“任务的重新激活”，而不是“订阅关系的重建”。

4. “主节拍器”的崩塌：TSCTSF故障恢复 (基于TS 23.527 9.4)

最严重的危机，发生在作为源头的TSCTSF身上。

9.4 TSCTSF failure with or without restart The procedure specified in this clause is optional to support. When a TSCTSF instance fails with or without restart, the subscription(s) for TSS information reporting… including the non-UE specific N2 information subscription in the AMF(s), are lost at the TSCTSF…

  • 深度解析：TSCTSF的故障，意味着整个监控链的“大脑”消失了。它在AMF那里创建的订阅，以及AMF下发给gNB的任务，都变成了没有目标的“孤儿订阅”。

恢复的责任方：AMF的“善后清理”

此时，AMF必须扮演“清理工”的角色，避免网络中出现无用的信令流量。

Upon detecting that a TSCTSF instance which subscribed to the AMF… has failed… the AMF may:

  • delete the non-UE specific N2 information subscription from the TSCTSF instance locally…
  • send an NGAP Timing Synchronization Status Request message… to stop TSS reporting on behalf of the failed TSCTSF…

  • 步骤一：AMF的“察觉” AMF通过SBA机制（NRF或直接信令）检测到之前向它订阅TSS信息的那个TSCTSF已经“阵亡”。

  • 步骤二：AMF的“双向清理”

    1. 对内：AMF在本地删除这个已经失效的订阅关系。
    2. 对下：AMF向相关的gNB发送一个NGAP Timing Synchronization Status Request消息，但这次的指令是**stop**。它在命令“现场工头”：“停止上报TSS报告！你的老板（TSCTSF）已经不在了，不要再做无用功了。”

这个“善后”流程至关重要，它避免了gNB持续地向AMF发送无人接收的TSS报告，从而节省了宝贵的N2接口带宽和处理资源。

高可用方案：TSCTSF Set

NOTE 1: The procedure specified in this clause is not needed for deployments where the TSCSTF supports resiliency across TSCTSF instances. If the TSCTSF instance is deployed within an TSCTSF set, the failure… is seamless for the AMF and NG-RANs…

  • 深度解析：规范再一次强调了Set部署的重要性。如果TSCTSF以高可用的集群（TSCTSF Set）方式部署，那么单个实例的故障，将由Set内的其他成员无缝接管。AMF和gNB甚至不会感知到这次故障，监控链将保持稳定。

5. 总结

5G网络授时状态监控的恢复机制，是一套围绕TSCTSF、AMF、NG-RAN这“铁三角”构建的、权责清晰、逻辑严谨的协同系统。

  1. 分层级的恢复责任：

    • AMF故障：由TSCTSF负责，需要重建订阅关系。
    • NG-RAN故障：由AMF通知，TSCTSF负责，只需重新激活任务，流程更轻。
    • TSCTSF故障：由AMF负责，重点是清理孤儿订阅，避免网络资源浪费。

  2. 订阅与任务的分离：AMF与TSCTSF之间的订阅关系，和AMF与NG-RAN之间的具体任务，是两个不同层面的概念。这种分离使得在NG-RAN重启时，可以实现更高效的恢复。

  3. Set部署是终极保障：无论是AMF还是TSCTSF，将其部署为高可用的Set集群，是实现无缝、透明故障恢复的根本。对于承载“Robo-Arm Quartet”这类关键任务的TSN网络，Set部署是“必选项”而非“可选项”。

在这场工业交响乐中，即使“主节拍器”、“区域经理”或“现场工头”中的任何一员短暂失灵，5G网络这支训练有素的“乐队”也能够通过这套精密的应急预案，快速恢复指挥体系，确保每一个机器人手臂，都能踩准那亚毫秒级的精准节拍，共同奏响智能制造的华美乐章。

FAQ

Q1：TSCTSF、AMF、NG-RAN在授时监控中的角色分别是什么？

A1：可以类比一个项目管理团队：

  • TSCTSF (主节拍器)：是项目经理。它定义了监控的需求（“我要知道A区的授时质量”），是监控数据的最终消费者。
  • AMF (区域经理)：是团队主管。它接收项目经理的指令，负责将任务分解并指派给正确的执行者，并汇总执行结果。
  • NG-RAN (现场工头)：是一线工程师。它在现场直接执行监控任务，并向上级（AMF）汇报实际的监控数据（TSS报告）。

Q2：AMF故障和NG-RAN故障，为什么TSCTSF的恢复动作不同（一个要重发Subscribe，一个不用）？

A2：因为订阅关系的存储位置不同。TSCTSF与AMF之间的订阅关系，是存储在AMF的内存中的。当AMF故障，这个订阅就丢失了，必须由TSCTSF重新发起...Subscribe来重建。而AMF下发给NG-RAN的监控任务，是存储在NG-RAN的内存中的。当NG-RAN故障，只是这个任务丢失了，但AMF侧的那个总订阅关系还在。所以TSCTSF只需让AMF把旧任务再发一遍即可，无需重建总订阅。

Q3：当TSCTSF故障后，AMF为什么要去命令gNB停止报告？这对网络有什么好处？

A3：这样做的好处是避免产生无用的“僵尸流量”。如果AMF不主动制止，gNB会继续忠实地执行它内存中那个“孤儿任务”，周期性地生成TSS报告并发送给AMF。AMF收到后，发现这个报告的“主人”（TSCTSF）已经不在了，只能将其丢弃。这个过程会持续不断地、毫无意义地消耗N2接口的带宽和AMF/gNB的处理资源。AMF的“清理”动作，就是及时地为这个无效流程画上句号，保持网络的干净和高效。

Q4：TSCTSF Set是如何实现无缝恢复的？

A4：TSCTSF Set通过共享上下文和虚拟IP/服务名等技术实现高可用。

  1. 共享上下文：所有TSCTSF实例共享一个后端数据库，里面存储了所有订阅关系。
  2. 统一入口：AMF在向TSCTSF订阅时，其请求的目标是一个代表整个Set的、稳定的服务名或虚拟IP，而不是某个具体的物理实例。底层的负载均衡器会将请求路由到一个健康的实例上。 当一个TSCTSF实例故障时，负载均衡器会自动将后续的流量（例如gNB上报的TSS报告）切换到Set中的其他健康实例。由于上下文是共享的，新的实例可以无缝地接替处理这些报告，对AMF和gNB完全透明。

Q5：网络授时同步和基站自身运行所需的GPS时间同步是一回事吗？

A5：不是一回事，但有关系。

  • 基站的GPS同步：是基站为了实现蜂窝网络（特别是TDD系统）的空口同步、实现小区间的正常切换和协同所必须的基础时间同步。这是基站自身的“生存需求”。
  • 5G网络授时（TSN）：是5G网络向终端用户（UE）提供的一种增值服务。它利用已经同步好的网络作为基础，通过特定的协议和流程，将高精度的时间戳传递给UE，以满足如工业控制、车联网等特定应用的需求。 TSCTSF监控的，正是这后一种“服务”的质量，而不仅仅是基站自身的同步状态。

关系图谱