51学通信

深度解析 3GPP TS 23.527：5.1-5.3.2 N3N9用户面恢复 (RAN侧故障篇)

21分钟阅读

深度解析 3GPP TS 23.527：5.1-5.3.2 N3/N9用户面恢复 (RAN侧故障篇)

本文技术原理深度参考了3GPP TS 23.527 V18.5.0 (2024-09) Release 18规范中，关于“5 Restoration Procedures related to the User Plane Interfaces N3 and N9”的前半部分，重点聚焦于“5.1 General”, “5.2 User Plane Failure Detection”及“5.3.2 Procedure for GTP-U Error Indication received from 5G-AN”，旨在为读者清晰地描绘出当5G用户面（特别是RAN侧）发生上下文丢失时，网络是如何检测故障并执行恢复的。

前言：当自动驾驶汽车驶入“数据迷雾”

在车水马龙的智慧城市中，一辆名为“智行一号”的L4级自动驾驶汽车正平稳地行驶着。它的“眼睛”和“耳朵”——激光雷达、高清摄像头和各类传感器，每秒钟都在产生海量数据，通过5G网络实时上传至边缘云进行分析决策；同时，云端也在不断向它下发高清地图更新、实时路况和协同驾驶指令。这条双向的数据流，是维系“智行一号”安全行驶的数字生命线。

这条生命线由5G的N3（gNB与UPF之间）和N9（UPF之间）接口共同构成的用户面高速公路承载。在这条路上，每个车辆的每个业务都被封装在专属的GTP-U隧道中飞驰。然而，任何道路都可能出现意外。如果“智行一号”正连接的基站（gNB）因一次软件瞬时抖动，突然“忘记”了为它建立的隧道信息，会发生什么？

对于UPF来说，它仍会敬业地将云端下发的数据包送往该gNB，但这时的gNB面对这些“不认识”的数据包，会一脸茫然。数据传输中断，高清地图无法更新，“智行一号”可能会因为信息缺失而紧急降级为人工驾驶模式，甚至在极端情况下引发安全风险。这片突如其来的“数据迷雾”，正是3GPP TS 23.527中用户面恢复程序需要解决的核心问题。本文将带您深入幕后，看看5G网络是如何快速驱散这片迷雾的。

1. 5G数据高速公路的守护者 (基于TS 23.527 5.1)

首先，让我们明确本章的讨论范围。

5.1 General This clause specifies the procedures supported in the 5G System to detect and handle failures affecting the user plane interfaces N3 and N9.

规范明确指出，本章节聚焦于N3和N9接口的故障检测与处理。N3接口连接着无线接入网（NG-RAN）和核心网用户面（UPF），是终端数据进出核心网的第一跳；N9接口则连接着核心网内不同的UPF，是数据在核心网内部流转的动脉。这两个接口的稳定与否，直接决定了用户体验。

“智行一号”的数据流，正是先通过N3接口从gNB进入第一个UPF（I-UPF），可能再经过N9接口到达作为PDU会话锚点（PSA）的另一个UPF，最终连接到边缘云。

2. 探知迷雾：用户面故障检测机制 (基于TS 23.527 5.2)

在解决问题之前，我们必须先能发现问题。5G用户面的故障检测主要分为两类：上下文丢失和路径失效。

2.1 节点的“失忆症”：GTP-U上下文丢失 (基于5.2.1)

这是本篇文章的核心场景，即网络节点本身是活的，但它忘记了会话的隧道信息。

5.2.1 Loss of GTP-U contexts A GTP-U entity may lose its GTP-U contexts upon a failure or restart. When a GTP-U node receives a G-PDU for which no corresponding GTP-U tunnel exists, the GTP-U node shall discard the G-PDU and return a GTP-U Error Indication to the sending node…

  • 深度解析：GTP-U上下文，本质上就是GTP隧道的路径信息，包括对端IP地址、隧道端点ID（TEID）以及与该隧道关联的QoS规则等。一个GTP-U节点（如gNB或UPF）因故障或重启，就可能丢失这些宝贵的内存信息，患上“失忆症”。
  • “错误指示”信标：当一个“失忆”的节点收到一个它无法识别的GTP数据包（G-PDU）时，它的标准动作是：丢弃数据包，并向发送方回送一个GTP-U Error Indication（GTP-U错误指示）消息。这个消息，就是迷雾中亮起的第一个求救信号。

场景演绎： PSA UPF将一份高清地图更新数据包，通过N3接口的GTP隧道发往“智行一号”所在的gNB。然而，该gNB刚刚经历了一次进程重启，丢失了关于“智行一号”PDU会话的所有GTP-U上下文。

gNB收到数据包后，查看其TEID，发现自己的内存里没有任何关于这个TEID的记录。于是，它立即丢弃该数据包，并向发送方（PSA UPF）回送了一个GTP-U Error Indication，告知：“你发来的这个包裹，收件人查无此人！”

The receipt of a GTP-U Error Indication is an indication for the sending GTP-U entity that the peer GTP-U entity cannot receive any more user plane traffic on the corresponding GTP-U tunnel.

这个错误指示的意义是明确的：此路已不通。发送方（UPF）必须停止在旧隧道上继续发送数据。

2.2 道路的“中断”：用户面路径故障 (基于5.2.2)

这是另一种故障类型，即节点本身状态完好，但它们之间的物理或逻辑链路中断了。

5.2.2 User Plane Path Failure A GTP-U entity may detect a user plane path failure by using GTP-U Echo Request and Echo Response messages, as specified in clause 20.3.1 of 3GPP TS 23.007.

  • 深度解析：这种故障的检测依赖于GTP-U层面的“心跳”机制。节点之间会周期性地发送Echo Request（回声请求），如果对端能在规定时间内回复Echo Response（回声响应），则证明路径是通畅的。反之，则判定路径故障。这与我们在N4接口看到的PFCP心跳机制原理类似，但作用于用户面。

本文将主要聚焦于第一种“上下文丢失”的场景及其恢复，路径故障的恢复将在后续文章中探讨。

3. 重建通途：从RAN侧故障中恢复 (基于TS 23.527 5.3)

当UPF收到来自gNB的GTP-U Error Indication后，一场精心编排的恢复大戏便拉开了序幕。

3.1 恢复的基本行为 (基于5.3.1)

5.3.1 General The following clauses specify the behaviour of the different network entities when receiving a GTP-U Error Indication.

这一节作为引子，预告了接下来将详细描述各网元（UPF, SMF, AMF等）在收到错误指示后的联动反应。

3.2 gNB的求救信号：处理来自5G-AN的错误指示 (基于5.3.2)

这是恢复流程的核心，规范通过 Figure 5.3.2.1-1: GTP-U Error Indication from 5G-AN 给出了详细的信令交互图。我们将结合“智行一号”的场景，一步步拆解这个流程。

场景：“智行一号”的PDU会话用户面已激活。UPF正在向gNB下发数据，但gNB丢失了上下文。

  • 步骤 1 & 2: 故障暴露

    1. The user plane connection of an existing PDU session is activated. Downlink G-PDUs are sent towards the 5G-AN.
    2. The 5G-AN returns a GTP-U Error Indication if it does not have a corresponding GTP-U context…

    UPF发送下行数据包（G-PDU），gNB因找不到对应的GTP-U上下文，回复GTP-U Error Indication。

  • 步骤 3: UPF上报控制面

    3. 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…

    UPF作为用户面的“执行者”，它本身没有决策权。收到错误指示后，它立刻通过N4接口向其“大脑”——SMF发送一个Error Indication Report（N4会话报告，类型为错误指示报告）。报告内容大致是：“老板，我发往gNB的TEID为XXXX的隧道，对方说不认识了。”

  • 步骤 4: SMF下令“暂停并缓冲”

    4. For a GTP-U Error Indication received from a 5G-AN, the SMF shall modify the PFCP session to instruct the UPF to buffer downlink packets.

    SMF收到报告后，立刻意识到N3用户面链路已断。为了防止后续数据丢失，它立即做出第一个关键决策：向UPF发送PFCP Session Modification Request消息，指令UPF将该PDU会話的下行数据处理动作（Apply Action）从“转发（FORW）”改为“缓冲（BUFF）”。UPF从此开始将所有下发给“智行一号”的数据包暂存在自己的缓冲区里，等待新路径的建立。

  • 步骤 5 & 6: SMF请求拆除旧链路

    5. …the SMF shall initiate an Namf_Communication_N1N2MessageTransfer service operation to request the 5G-AN to release the PDU session’s resources… 6. Upon receipt of an Namf_Communication_N1N2MessageTransfer request to transfer the PDU Session Resource Release Command, the AMF shall: proceed with the request… if the UE is in CM-CONNECTED state…

    SMF的恢复策略不是在旧的、已损坏的链路上“打补丁”，而是“推倒重建”。它通过AMF，向gNB发送一个PDU Session Resource Release Command（PDU会话资源释放命令），要求gNB彻底清除与该PDU会话相关的所有无线资源。AMF会检查UE是否处于连接态，如果是，则将命令转发给gNB。

  • 步骤 7: 拆除确认 gNB执行资源释放后，通过AMF向SMF返回确认消息。至此，旧的、有问题的N3用户面链路被彻底、干净地拆除了。

  • 步骤 8: 触发重建

    8. If the PDU session resource is released in the 5G-AN, the SMF initiates the Network Triggered Service Request procedure… to re-activate the user plane connection of the PDU session.

    在确认旧链路已拆除后，SMF发起第二个关键决策：启动“网络触发的服务请求”流程。这个流程会通过AMF寻呼UE（“智行一号”的车机），触发UE重新建立RRC连接和NAS信令连接，从而建立一个全新的、干净的无线承载和N3用户面隧道。一旦新的隧道建立完成，UPF就会收到新的TEID，SMF会再次修改PFCP会话，将Apply Action从“缓冲（BUFF）”改回“转发（FORW）”，并将缓冲区的数据发送到新隧道中。

    至此，“智行一号”的数据迷雾被驱散，数据流恢复正常。由于有缓冲机制的存在，整个恢复过程中数据的丢失被降到了最低。

3.3 更灵活的恢复：针对分离式PDU会话的特殊处理

规范还为一种特殊场景——分离式PDU会话（Split PDU Session）提供了更优化的恢复选项。这通常用于多接入场景，如5G和Wi-Fi同时连接。

(Step 5 alternative) If the affected PDU session is a split PDU session, the SMF may instead initiate an Namf_Communication_N1N2MessageTransfer service operation including the “PDU Session Resource Modify Request Transfer” IE…

  • 深度解析：假设“智行一号”同时连接了5G和LTE（通过双连接技术），5G链路用于高清地图，LTE用于普通遥测。如果只是5G链路在gNB侧的上下文丢失了，SMF不必释放整个PDU会话，而可以只请求gNB“修改”会话资源。
  • 修改流程(步骤6a-10)：SMF向AMF发送PDU Session Resource Modify Request，gNB收到后，可以尝试为5G链路分配一个新的N3隧道（新的TEID），或者决定将原本走5G的QoS流暂时移到正常的LTE链路上。gNB将自己的决定通过AMF上报给SMF，SMF再更新UPF的转发规则即可。

这种“修改”而非“释放”的方式，避免了寻呼UE和全流程重建，恢复速度更快，对业务的影响更小，体现了5G架构的灵活性。

4. 总结

面对用户面RAN侧的上下文丢失故障，5G系统展现了一套成熟而稳健的恢复机制，其核心思想可以概括为：

  1. 快速检测：通过GTP-U层面的Error Indication消息，将用户面的故障状态快速暴露给核心网控制面。
  2. 控制面主导：整个恢复流程由SMF统一指挥，UPF、AMF、RAN各司其职，协同联动。
  3. 缓冲减损：在恢复期间，SMF指令UPF缓冲下行数据，最大限度地减少了业务数据的丢失，保障了用户体验。
  4. 推倒重建：标准恢复流程的核心是“先释放，再重建”，通过网络触发的服务请求，建立一条全新的、干净的用户面路径，保证了恢复后的网络状态一致性和稳定性。
  5. 灵活优化：针对多接入等高级场景，提供了“修改”会话的优化路径，实现了更快速、更低感知的恢复。

对于“智行一号”而言，即使短暂驶入“数据迷雾”，5G网络强大的自愈能力也能在极短时间内为其重新点亮前行的道路，确保其安全、高效地抵达目的地。

FAQ

Q1：GTP-U上下文丢失和用户面路径故障有什么本质区别？

A1：本质区别在于故障点不同。

  • GTP-U上下文丢失是节点内部的问题，好比一个快递站（gNB）的电脑系统重启了，丢失了所有包裹的派送信息，但快递站本身和通往它的道路都是完好的。
  • 用户面路径故障是节点之间的问题，好比两个快递站（UPF和gNB）的系统都正常，但它们之间的运输道路（物理光纤或网络链路）中断了。 检测方式也不同，前者通过GTP-U Error Indication被动触发，后者通过GTP-U Echo心跳主动探测。

Q2：当gNB丢失上下文后，SMF为什么不直接尝试在gNB上重建隧道，而是要先释放再重建？

A2：采用“先释放，再重建”的策略主要是为了保证状态的最终一致性和流程的可靠性。直接在可能有问题的gNB上“打补丁”，可能会因为gNB内部状态不一致而失败，或者留下未知的隐患。而通过标准的“资源释放”流程，可以确保gNB侧与该会话相关的资源被彻底清理干净。然后通过“网络触发的服务请求”这一成熟的标准流程来重建，能保证最终建立的无线承载、安全上下文和用户面隧道都是一个全新的、一致的状态，可靠性更高。

Q3：在恢复过程中，UPF缓冲的数据包会占用多大内存？如果恢复时间很长，会把UPF撑爆吗？

A3：UPF的缓冲区大小是有限的，并且通常是可配置的。运营商会根据网络情况和业务模型来设定合理的缓冲大小和缓冲超时时间。如果缓冲的数据量超过了配额，或者缓冲时间超过了阈值（意味着恢复过程过长或失败），UPF会开始丢弃数据包（通常是丢弃最旧的包）。因此，缓冲机制旨在缓解短时中断造成的数据丢失，但无法应对长时间的故障。

Q4：整个恢复流程看起来很复杂，耗时会很长吗？对于“智行一号”这样的实时业务，能接受吗？

A4：虽然信令步骤看起来多，但在实际网络中，这些交互都是毫秒级的。整个恢复流程（从UPF上报到新隧道建立）通常可以在数百毫秒到几秒内完成。对于大多数业务来说，这是一次可接受的短暂中断。然而，对于自动驾驶、工业控制等超高要求的uRLLC业务，这个时间可能仍然偏长。因此，5G也在持续演进，通过引入如URLLC的冗余用户面路径（双UPF、双N3隧道）等更高级的可靠性技术，来实现零中断或近零中断的切换。

Q5：在这个流程中，AMF扮演了什么角色？为什么SMF不直接和gNB通信？

A5：AMF是移动性管理和接入管理的核心，是核心网与RAN之间N2接口的信令终结点。SMF（会话管理）的职责不涉及接入层的具体管理。因此，SMF需要下发针对RAN的指令时（如释放/修改会话资源），必须通过AMF进行中转。AMF负责将SMF的会话级请求，转换成RAN可以理解的、具体的N2接口信令（NGAP消息），并管理UE的连接态/空闲态转换（如寻呼）。这种职责分离是5G核心网服务化架构（SBA）的重要体现。

关系图谱