51学通信

深度解析 3GPP TS 23.527：5.3.3-5.5 N9接口恢复 (核心网UPF间故障篇)

23分钟阅读

深度解析 3GPP TS 23.527：5.3.3-5.5 N9接口恢复 (核心网UPF间故障篇)

本文技术原理深度参考了3GPP TS 23.527 V18.5.0 (2024-09) Release 18规范中，关于“5.3.3 Procedure for GTP-U Error Indication received from UPF”, “5.4 Restoration Procedures upon User Plane Path Failure”以及“5.5 Reporting of a Peer GTP-U Entity Restart”的核心章节，旨在为读者深入剖析5G核心网内部用户面（N9接口）的故障恢复机制，揭示网络在面对UPF间的链路中断和节点重启时的自我修复能力。

前言：当“数据动脉”遭遇栓塞

在上一篇文章中，我们见证了当自动驾驶汽车“智行一号”所连接的基站（gNB）丢失上下文时，5G网络如何通过一系列精密的信令交互，快速重建N3用户面链路，驱散“数据迷雾”。然而，5G网络的复杂性远不止于此。数据的旅程并非只有从基站到核心网这“最后一公里”，它还需要在核心网内部的“数据动脉”——N9接口上流转。

为了实现边缘计算、保证业务低时延，“智行一号”的数据流通常采用分层UPF架构。数据包先从gNB经N3接口到达位于路边的I-UPF（中间UPF），进行V2X（车与万物）消息的实时处理；随后，再经由N9接口，被转发到位于区域数据中心的PSA UPF（PDU会话锚点UPF），最终连接到互联网或自动驾驶服务云。

现在，让我们设想一个更深层次的故障：位于区域数据中心的PSA UPF突然重启，或者连接I-UPF与PSA UPF之间的光纤链路被意外挖断。这将导致核心网内部的“数据动脉”发生栓塞。I-UPF面对源源不断从“智行一号”传来的数据，却发现无路可送。这种核心网内部的故障，其恢复机制与RAN侧故障有何不同？5G网络又是如何应对这种更隐蔽、更核心的挑战的？本文将继续跟随“智行一号”的数字轨迹，深入探索N9接口上的恢复风暴。

1. 连锁反应：处理来自对等UPF的错误指示 (基于TS 23.527 5.3.3)

当故障发生在核心网用户面内部，一个UPF向下游UPF发送数据时，也可能遭遇“上下文丢失”的问题。

1.1 从5G-AN侧接收错误指示 (基于5.3.3.1)

5.3.3.1 GTP-U Error Indication received by 5G-AN Upon receipt of a GTP-U Error Indication, the 5G-AN shall proceed as follows:

  • if the GTP-U Error Indication was received from an UPF over a NG-U tunnel that is not an indirect forwarding tunnel, the 5G-AN shall initiate a PDU Session Resource Notify procedure and release immediately the resources of the PDU session…

这个条款描述了当gNB收到来自UPF的GTP-U Error Indication时的行为。这通常发生在切换等场景，例如UE切换到新的gNB，旧gNB向UPF转发数据，但UPF在新gNB的路径尚未完全建立时，可能会向旧gNB返回错误。此时，gNB的标准动作是触发PDU会话资源的释放。

1.2 从另一个UPF接收错误指示 (基于5.3.3.2)

这是我们本章的核心场景，即故障发生在N9接口上。

场景：位于区域数据中心的PSA UPF（服务“智行一号”）突然重启，丢失了所有会话上下文。此时，路边的I-UPF仍正常工作，并将“智行一号”的上传数据包通过N9隧道发往PSA UPF。

5.3.3.2 GTP-U Error Indication received by another UPF Upon receipt of a GTP-U Error Indication, the UPF shall identify the related PFCP session and send an Error Indication Report to the SMF…

与N3接口的流程类似，当I-UPF收到来自PSA UPF的GTP-U Error Indication后，它会立即通过N4接口向SMF报告：“老板，我通往PSA UPF的N9隧道，对方说不认识了！”

然而，接下来SMF的决策，却与处理RAN侧故障时大相径庭。

For a GTP-U Error Indication received from another UPF, the SMF shall delete the PFCP session and PDU session, unless the UPF from which the Error Indication was received is controlled by the same SMF and the SMF is able to restore the user plane connectivity of the PDU session…

  • 深度解析：规范指出，SMF的标准动作是删除PFCP会话和PDU会话。这是一个非常严厉的决定。为什么？

    • 锚点丢失：PSA UPF是PDU会话的锚点，它负责IP地址分配和与外部数据网络的连接。它的上下文丢失，意味着UE的IP地址 anchoring point失效，整个会话的基础已不复存在。
    • 恢复路径复杂：与RAN侧不同，核心网内部的UPF故障，特别是PSA UPF的故障，没有一个简单的“网络触发服务请求”流程可以直接恢复。最干净、最可靠的方式就是彻底拆除旧会话，让终端重新发起建立。

  • 例外情况：规范中也提到了一个“unless”的例外。如果发送和接收错误指示的两个UPF都由同一个SMF控制，并且SMF有能力恢复用户面连接（例如，这只是两个串联的I-UPF之间的故障，PSA锚点依然稳固），那么SMF可以尝试恢复而不是删除。但在我们的场景中，故障方是PSA UPF，所以这个例外不适用。

结论：当N9接口因为下游PSA UPF上下文丢失而中断时，SMF的标准操作是释放整个PDU会话。“智行一号”的当前数据连接将被中断，需要车载终端重新发起连接请求。

2. 无声的断裂：用户面路径故障恢复 (基于TS 23.527 5.4)

现在我们讨论另一种情况：I-UPF和PSA UPF节点本身都正常，但它们之间的N9接口物理链路（如光纤）中断了。此时，不会有GTP-U Error Indication，因为数据包根本无法到达对端。

5.4 Restoration Procedures upon User Plane Path Failure Upon detecting a GTP-U user plane path failure as specified in clause 5.2.2, the UPF shall report the user plane path failure to the SMF, by sending a PFCP Node Report Request…

  • 检测：UPF通过GTP-U层面的Echo心跳机制（如上一篇所述）发现路径不通。
  • 上报：发现路径故障的UPF（例如I-UPF）会向SMF发送一个PFCP Node Report Request，报告内容为：“老板，我到IP地址为[PSA UPF地址]的GTP-U对端节点的路径中断了。”

收到报告后，SMF面临一个重要的决策：是立即放弃，还是耐心等待？规范为此提供了多种策略选项，体现了极大的灵活性。

When the SMF receives the PFCP Node Report Request with a User Plane Path Failure Report, the SMF may:

  • delete the PDU session contexts associated with the path in failure; or
  • maintain the PDU session contexts associated with the path in failure during an operator configurable maximum path failure duration.

2.1 策略一：果断放弃 (Delete)

这是最简单的策略。SMF收到路径故障报告后，立即删除所有受影响的PDU会话。

  • 优点：处理简单，能快速释放网络资源。
  • 缺点：即便是瞬时的网络抖动（例如，路由协议在几秒内收敛并切换到备用路径），也会导致业务中断。

2.2 策略二：耐心等待 (Maintain)

这是更具韧性的策略。SMF会保持会话上下文一段时间（例如，运营商可配置的30秒）。

  • 优点：能够容忍瞬时或短暂的路径故障。如果路径在配置的时间内恢复，UPF会向SMF上报“User Plane Path Recovery Report”，SMF即可恢复数据转发，业务对用户完全无感。
  • 缺点：在故障期间会占用SMF和UPF的会话资源。如果故障时间较长，最终还是需要删除会话，这反而延迟了资源的释放。

NOTE 1: During transient path failures (e.g. path failures not exceeding few minutes at most), maintaining the PDU session contexts… enables the delivery of end user services (when the path is re-established again)… NOTE 2: It is not intended to maintain PDU session contexts during long path failures… as this would imply undesirable effects like undue charging.

规范的注记非常关键，它指出了“Maintain”策略的适用场景是短暂故障，并提醒在故障期间要考虑避免不当计费的问题。

2.3 针对N3接口的特殊策略

  • maintain the PDU session contexts… if the path in failure is towards a 5G-AN. When deciding to maintain…, it shall send a PFCP Session Modification Request message with changing Apply-Action from FORW to BUFF and NOCP…

当故障路径是通往gNB的N3接口时，规范推荐SMF采取更积极的“Maintain”策略。此时，SMF不仅要保持会话，还应立刻指示UPF：

  • BUFF (Buffer)：缓冲下行数据。
  • NOCP (Notify Control Plane)：当有新的下行数据到达时，通知SMF。 这个机制使得SMF可以在收到数据到达通知后，或在UE发起服务请求时，主动尝试重建N3链路，恢复流程更加主动和高效。

场景演绎：连接I-UPF和PSA UPF的N9接口光纤中断。SMF的策略被配置为“Maintain 60秒”。

  • 0-60秒：“智行一号”的数据传输暂停，但会话在SMF和UPF上仍然存在。网络路由协议正在紧急切换到备用光纤链路上。
  • 第15秒：备用链路启用，路径恢复。I-UPF检测到路径恢复后，上报SMF。SMF恢复数据转发。
  • 结果：“智行一号”经历了15秒的数据中断，但会话本身没有被拆除，业务在路径恢复后自动延续。如果SMF配置的是“Delete”策略，那么业务将彻底中断，需要车辆重新发起连接。

3. 效率革命：对端GTP-U实体重启的聚合报告 (基于TS 23.527 5.5)

在处理大规模故障时，信令风暴是一个必须解决的问题。想象一个PSA UPF重启，它上面承载了数万个会话。如果上游的I-UPF为每一个会话都向SMF发送一个Error Indication Report，将会瞬间淹没SMF。为此，规范引入了一种更智能、更高效的可选机制。

5.5 Reporting of a Peer GTP-U Entity Restart To reduce massive amount of N4 signalling… a user plane function (UPF) and a control plane function (SMF) may optionally support reporting of a peer GTP-U entity restart.

场景：PSA UPF重启。I-UPF开始收到来自它的GTP-U Error Indication消息（因为PSA UPF重启后，I-UPF发给它的包它不认识了）。

3.1 传统方式 vs. 新方式

  • 传统方式：I-UPF每收到一个Error Indication，就向SMF转发一个对应的Error Indication Report。N个会话 = N次N4信令。
  • 新方式：I-UPF检测到对端（PSA UPF）发生了重启（通过GTP-U Echo消息中更大的恢复时间戳），它不再逐条上报，而是向SMF发送一个单独的PFCP Node Report Request消息。

… it shall send a PFCP Node Report Request message to the control plane function to report that:

  • the peer GTP-U entity identified by Remote GTP-U Peer IE has restarted; and
  • all PFCP sessions associated with the restarted peer GTP-U entity have been modified by the user plane function… the Apply-Action… changed to BUFF and NOCP…

3.2 I-UPF的主动作为

这个聚合报告的背后，是I-UPF被赋予了更大的自主权。在向SMF报告之前，I-UPF会主动地：

  1. 识别所有受影响的会话：找出所有目的地是已重启PSA UPF的PFCP会话。
  2. 修改本地状态：将所有这些会话的下行转发动作批量修改为BUFF和NOCP。

然后，它才向SMF发送那个聚合的PFCP Node Report，报告：“老板，我的对端伙伴[PSA UPF的地址]重启了。所有相关的会话，我已经帮你处理好了，全部进入缓冲模式。接下来怎么做，请指示。”

SMF收到这个报告后，其行为就好像收到了大量独立的错误报告一样，会根据策略（通常是删除会话）进行后续处理。但整个过程，N4接口的信令交互从N次锐减到了1次。这种效率的提升，对于保障大规模网络的稳定性至关重要。

4. 总结

通过对5G核心网内部用户面恢复机制的探索，我们可以看到一个更加成熟、分层和高效的故障处理体系：

  1. 区分故障根源：对于上下文丢失（如PSA UPF重启），由于会话锚点失效，标准做法是快速释放会话，以保证网络状态的确定性。
  2. 弹性应对路径故障：对于链路中断，SMF被赋予了基于策略的决策能力，可以选择“果断放弃”或“耐心等待”，使得网络能够更好地适应不同的故障场景和业务需求。
  3. 聚合报告提升效率：可选的“对端重启报告”机制，通过在UPF侧进行预处理和聚合上报，极大地降低了大规模故障下的信令风暴风险，是网络走向大规模、高密度部署的必然演进。

“智行一号”的数字生命线，不仅依赖于N3接口的坚韧，更依赖于N9这条“数据动脉”的稳健。无论是动脉栓塞（上下文丢失）还是道路塌方（路径故障），5G网络都准备了相应的应急预案。从简单的删除，到策略性的等待，再到智能化的聚合报告，这些不断演进的恢复机制，共同构筑了支撑未来关键任务型应用（如自动驾驶）所需的高可靠网络基石。

FAQ

Q1：为什么同样是收到GTP-U Error Indication，来自gNB（N3）和来自PSA UPF（N9）的，SMF的处理方式会截然不同（一个恢复，一个删除）？

A1：关键在于故障点对PDU会话的影响程度不同。

  • 来自gNB：表示无线侧或N3接口的上下文丢失。PDU会话的核心锚点（PSA UPF）、UE的IP地址都还在。SMF可以通过“网络触发服务请求”流程，在RAN侧重建无线承载和N3隧道，会话的核心得以保留。
  • 来自PSA UPF：表示PDU会話的锚点本身丢失了上下文。这意味着UE的IP地址分配信息、与外部DN的连接状态等核心要素都已丢失。恢复的代价和复杂性极高，最稳妥、最干净的方式就是释放整个会话，让UE重新发起，以获得一个全新的、状态一致的会话。

Q2：用户面路径故障检测中的GTP-U Echo和N4接口的PFCP Heartbeat有什么关系和区别？

A2：它们都是心跳机制，但作用的层面和接口不同。

  • PFCP Heartbeat：作用于N4控制面接口，用于SMF和UPF之间检测彼此的存活状态和重启事件。它保证了“大脑”和“手臂”之间的指令通道是通畅的。
  • GTP-U Echo：作用于N3/N9用户面接口，用于GTP-U节点（如gNB, UPF）之间检测用户面数据路径的连通性。它保证了“手臂”和“手臂”之间，或“手臂”和“末端设备”之间的数据公路是通畅的。两者相互独立，共同保障网络的健康。

Q3：对于路径故障，SMF“Maintain”会话的策略，那个“可配置的最大时长”应该设为多少比较合适？

A3：这个值的设定是一个典型的网络工程权衡。

  • 设得太短（如5秒）：可能无法覆盖一些需要路由协议收敛（可能耗时数秒到数十秒）才能恢复的故障，导致不必要的业务中断。
  • 设得太长（如5分钟）：在发生真正的永久性故障时，会长时间占用网络资源，并且可能导致UPF缓冲区溢出、数据大量丢失，以及潜在的计费问题。 通常，运营商会根据其网络的具体情况（如路由协议的收敛时间、物理链路的保护倒换时间等）来设定一个合理的值，常见的范围在30秒到180秒之间。

Q4：“对端GTP-U实体重启的聚合报告”（5.5）机制，既然这么高效，为什么规范要规定它是“可选的”（optional）？

A4：主要有几个原因：

  • 实现复杂性：这个机制要求UPF具备更强的智能，它需要能够检测“重启”事件（而不仅仅是简单的路径故障或收到错误指示），并能主动、批量地修改本地会话状态。这对UPF的实现提出了更高的要求。
  • 标准演进：3GPP标准是逐步演进的，一些高级、优化的功能往往在初期被定义为“可选”，以降低早期设备商的实现门槛，保证基本功能的互联互通。随着技术成熟和网络规模扩大，这些可选功能可能会在后续版本中被更广泛地要求支持。
  • 部署场景：在一些规模较小或业务单一的网络中，大规模UPF重启的概率较低，信令风暴的风险不突出，运营商可能认为实现这个功能的成本收益不成正比。

Q5：在路径故障恢复中，SMF指令UPF将转发动作改为BUFF和NOCP。NOCP（Notify Control Plane）的具体作用是什么？

A5：NOCP是一个触发器。当一个会话的转发规则被设为BUFF和NOCP后，UPF不仅会缓冲下行数据包，而且每当有新的下行数据包到达缓冲区时，它就会向SMF发送一个Data Notification消息。这个通知的作用是提醒SMF：“老板，有新数据来了，但路不通发不出去，你是不是该想想办法了？”。这使得SMF可以更智能地决策，例如，如果SMF收到这个通知，它可以立即尝试发起网络触发的恢复流程，而不需要等待UE发起服务请求，从而使恢复过程更加主动和及时。

关系图谱