51学通信

深度解析 3GPP TS 29.244：第5.2.9节 & 5.3节 (规则激活失败处理 & CPUP间数据转发)

23分钟阅读

好的，我们继续进行深度解析。

深度解析 3GPP TS 29.244：第5.2.9节 & 5.3节 (规则激活失败处理 & CP/UP间数据转发)

本文技术原理深度参考了3GPP TS 29.244 V18.9.0 (2025-03) Release 18规范中，关于“5.2.9 Handling of Rules that cannot be activated”和“5.3 Data Forwarding between the CP and UP Functions”的核心章节，并结合3GPP TS 23.501 V18.9.0 (2025-03)的系统架构，旨在为读者深入剖析PFCP协议中的“容错机制”与一个特殊但至关重要的功能——控制面与用户面之间的数据转发。

引言：当“大脑”与“肌肉”需要传递“包裹”

在之前的系列文章中，我们已经全面探讨了PFCP分组转发模型的“IF-THEN”执行链。PDR负责“IF”（识别流量），而URR、FAR、QER、MAR和SRR则构成了“THEN”（执行统计、转发、保障、状态上报等）的完整动作集。这套模型完美诠释了控制面（CP）如何指挥用户面（UP）处理绝大多数的用户数据。

然而，在复杂的网络世界里，总有一些特殊情况需要处理。首先，如果CP下发的指令集（如一个包含多条规则的PFCP会话修改请求）中，有部分指令因为UP侧的原因无法执行，整个流程是全盘失败，还是可以“部分成功”？这就是**第5.2.9节“无法激活规则的处理”**所要解决的“容错”问题。

其次，虽然控制面与用户面分离（CUPS）的核心思想是让用户数据完全在用户面（UP）路径上流动，但仍存在一些特殊场景，需要将一小部分用户数据“上送”到控制面（CP）进行处理，或者由CP主动下发数据到UP。这些场景包括但不限于：终端IP地址的DHCP分配、切换过程中的“End Marker”信令、可选的控制面数据缓冲以及物联网（CIoT）的控制面优化传输。**第5.3节“CP与UP功能间的数据转发”**正是为这些特殊场景量身打造的机制。它定义了UPF与SMF之间如何通过一个专用的GTP-U隧道，安全、高效地传递这些特殊的“用户面包裹”。

为了生动地理解这些概念，我们将引入一位新主角和他的工作场景： 主角设定：小明，一位需要随时随地稳定办公的远程工程师。 场景设定：小明使用公司的5G笔记本电脑（内置5G模块）接入企业专网。公司策略规定，所有接入终端的IP地址必须由公司内部的DHCP服务器统一分配。当小明的笔记本开机并请求建立一个PDU会话时，他的DHCP请求报文（这本质上是用户数据）必须被准确地从UPF转发到SMF，再由SMF代理转发给企业内部的DHCP服务器。这个过程完美地诠释了CP/UP间数据转发的核心价值。稍后，当小明乘坐高铁移动办公时，我们将通过他的PDU会话在不同基站间无缝切换的场景，来解析“End Marker”的转发机制。

1. 规则激活的“容错”机制：5.2.9节 无法激活规则的处理

在SMF与UPF的交互中，SMF常常会在一个PFCP请求消息中，要求UPF同时创建或修改多条规则（PDRs, FARs等）。如果UPF因为某些原因（如资源不足、不支持某项特性、或收到了一个无效的预定义规则ID）无法执行其中某一条规则，该如何响应？默认情况下，UPF会“一票否决”，拒绝整个请求。

If the CP function or the UP function does not support the PSUCC feature, the UP function shall reject a PFCP session establishment or modification request if at least one rule fails to be applied.

然而，这种严格的“原子性”在某些场景下可能过于僵化，可能导致整个PDU会话建立失败，或是一次包含多项更新的修改操作完全失效。为了提高系统的鲁棒性，PFCP引入了一个可选的特性——部分成功（Partial Success）。

1.1 部分成功（PSUCC）特性

The CP function shall indicate support of the Partial Success (PSUCC) feature (see clause 8.2.58) during the PFCP association setup or update procedure, if it supports PFCP session establishment or modification with Partial Success…

PSUCC特性需要在PFCP关联建立时，由CP功能（SMF）和UP功能（UPF）双方通过UP Function Features IE 和 CP Function Features IE 相互宣告支持。

If the CP function indicated support of the the PSUCC feature, and if this feature is also supported by the UP function, the UP function should partially accept a PFCP session establishment or modification request, if possible, even when it fails to create or modify one or more rules.

当双方都支持PSUCC特性后，如果UPF在处理一个包含多条规则的PFCP请求时遇到部分失败，它**应当（should）**尽力执行那些可以成功的规则，并以“部分成功”的方式响应SMF。

1.2 “部分成功”的报告机制

当UPF部分接受一个请求时，它必须向SMF清晰地报告哪些规则失败了以及失败的原因。

In such a case, the UP function shall set the cause to “Request partially accepted” in the response and include the Partial Failure Information IE identifying the rules that the UP function could not activate and the cause of the failure.

具体的响应行为如下：

  1. 在PFCP响应消息（如PFCP Session Establishment/Modification Response）中，将主Cause IE的值设置为**“Request partially accepted”**。
  2. 对于每一条失败的规则，都在响应消息中包含一个Partial Failure Information IE。

Partial Failure Information IE 是一个分组IE，它包含了两个关键信息：

  • Failed Rule ID：指明是哪条规则（PDR, FAR, URR等）失败了。
  • Failure Cause：指明该规则失败的具体原因，例如“Unknown Pre-defined Rule” 或 “No resources available”。

场景示例： 假设SMF向UPF发送一个PFCP Session Modification Request，要求：

  1. Create PDR-1: 关联到一个预定义的URR，名为”video_usage_rule”。
  2. Update FAR-2: 修改转发路径。
  3. Create QER-3: 设置一个新的GBR。

UPF在处理时发现，本地并没有配置名为”video_usage_rule”的预定义URR，导致PDR-1无法创建，但FAR-2和QER-3的更新/创建都可以成功。

  • 如果不支持PSUCC：UPF会直接拒绝整个请求，响应Cause为”Rule creation/modification Failure”。FAR-2和QER-3的更新也不会生效。
  • 如果支持PSUCC：UPF会成功更新FAR-2并创建QER-3。然后，它会发送一个PFCP Session Modification Response，其中：
    • 主Cause IE = “Request partially accepted”。
    • 包含一个Partial Failure Information IE，其中：
      • Failed Rule ID = PDR (Rule ID Type) + PDR-1的ID (Rule ID value)。
      • Failure Cause = “Unknown Pre-defined Rule”。

SMF收到这个响应后，便知道FAR-2和QER-3已成功应用，但PDR-1失败了，并知道了失败的原因。SMF可以据此调整策略，例如，后续重新下发一个不依赖预定义规则的PDR-1，或者向运维系统告警，提示UPF配置缺失。

2. CP与UP功能间的数据转发：5.3节

CUPS架构的核心是用户面与控制面的分离，但这种分离并非绝对的物理隔离。在某些特定场景下，CP功能（SMF）需要直接处理一些源自UE或DN的用户面报文，或者需要主动向UE下发一些控制类报文。

Forwarding of user plane data between the CP and UP functions may take place as part of the following scenarios…

规范中的 Table 5.3.1-1: Data forwarding scenarios between the CP and UP functions清晰地罗列了这些场景。

场景描述转发方向5GC适用性
1. UE与CP功能间的用户面报文转发（如DHCP信令）UPF → SMF, SMF → UPF是
2. CP功能与外部DN间的报文转发（如与DN-AAA服务器交互）UPF → SMF, SMF → UPF是
3. 在CP功能中进行缓冲的报文UPF → SMF, SMF → UPF是
4. 由CP功能构建并下发的End Marker报文SMF → UPF是
5. 使用控制面CIoT 5GS优化的用户数据转发UPF → SMF, SMF → UPF是

2.1 转发机制：专用的GTP-U隧道

User plane packets shall be forwarded between the CP and UP functions by encapsulating the user plane packets using GTP-U encapsulation (see 3GPP TS 29.281).

CP和UP之间的数据转发，其底层机制是通过建立一个专用的GTP-U隧道来实现的。这个隧道通常被称为N4-u隧道。SMF通过PFCP协议，为这个特殊的转发路径配置专门的PDR和FAR。

For forwarding data from the UP function to the CP function, the CP function shall provision PDR(s) per PFCP session context, with the PDI identifying the user plane traffic to forward to the CP function and with a FAR set with the Destination Interface “CP function side” and set to perform GTP-U encapsulation and to forward the packets to a GTP-u F-TEID uniquely assigned in the CP function per PFCP session and PDR.

  • 上行转发 (UPF → SMF)：SMF会下发一条高优先级的PDR，用于精确匹配需要上送CP的流量（例如DHCP请求）。该PDR关联的FAR会将目的接口（Destination Interface）设置为“CP function side”，并在**外层头创建（Outer Header Creation）**中指定SMF为此隧道分配的F-TEID。
  • 下行转发 (SMF → UPF)：SMF将数据封装在GTP-U隧道中发往UPF。同时，SMF会下发另一条PDR，用于匹配来自这个特殊隧道的流量（源接口（Source Interface）设置为“CP-function”）。该PDR关联的FAR则指示UPF对数据包进行解封装，并转发给UE。

2.2 场景解析1：DHCP IP地址分配

这是CP/UP间数据转发最典型的应用场景。让我们跟随小明，看看他的笔记本电脑是如何获取IP地址的。

  1. 小明的笔记本发起DHCP Discover报文。这个报文被封装后，通过5G空口到达gNB，再通过N3隧道到达UPF。
  2. 在UPF中，这个DHCP报文（UDP目的端口为67）会匹配一条由SMF预先下发的高优先级PDR。
  3. 该PDR关联的FAR指示UPF执行以下动作：
    • Apply Action = FORW
    • Destination Interface = CP function side
    • Outer Header Creation: 创建一个GTP-U/UDP/IP头，目标地址是SMF的IP，TEID是SMF为此DHCP流程分配的隧道ID。
  4. UPF将DHCP Discover报文封装后，通过N4-u隧道发送给SMF。
  5. SMF收到报文后，将其解封装，并代表UE与企业内部的DHCP服务器进行交互。
  6. DHCP服务器返回DHCP Offer报文给SMF。
  7. SMF将DHCP Offer报文封装进一个GTP-U隧道，并通过N4-u发往UPF。
  8. 在UPF中，这个来自SMF的GTP-U报文会匹配另一条PDR，其PDI中的Source Interface被设置为CP-function。
  9. 该PDR关联的FAR指示UPF：
    • Apply Action = FORW
    • Destination Interface = Access side
    • Outer Header Creation: 创建通往gNB的N3隧道头。
  10. UPF将解封装后的DHCP Offer报文封装进N3隧道，发往UE。后续的DHCP Request和ACK流程与此类似。

2.3 场景解析2：切换中的信使——End Marker

Sending of “end marker” is a functionality which involve SMF and UPF in order to assist the reordering function in the Target RAN.

当小明乘坐高铁时，他的UE会频繁地在不同基站（小区）之间切换。在切换过程中，为了防止数据包乱序导致业务中断（如视频卡顿），源基站（S-RAN）需要一种机制来告知目标基站（T-RAN），“我这边的数据已经发完了”。**End Marker（结束标记）**就是扮演这个角色的“信使”。

The construction of End Marker packets may either be done in the CP function or UP function, based on network configuration, as specified in … clause 5.8.2.9 of 3GPP TS 23.501 for 5GC.

End Marker的构建可以在UPF或SMF中完成。

  • UPF构建（推荐方式）：这是更高效的方式。

    A CP function complying with this release of the specification should request the UP function to construct End Marker packets. If so, the CP function shall request the UP function to construct and send End Marker packets by sending a Session Modification Request including FAR(s) with the new downstream F-TEID and with the SNDEM (Send End Marker Packets) flag set. 在切换流程中，SMF向UPF发送PFCP Session Modification Request，更新下行转发路径到T-RAN。同时，在指向旧路径（S-RAN）的FAR更新指令中，设置**SNDEM（Send End Marker Packets）**标志位。UPF在收到该指令后，会先将缓冲区中发往旧路径的数据包全部发送完毕，然后自行构建一个或多个End Marker包，发送到旧路径上。

  • SMF构建（可选方式）：这种方式更为复杂，主要用于兼容不支持在UPF构建End Marker的旧版本设备。

    For End Marker packets constructed in the CP function, the CP function shall:

    • establish (once) one standalone PFCP session not tied to any PDN connection, per the UP function, for forwarding End Marker packets…
    • construct the GTP-U End Marker packets…
    • encapsulate the constructed GTP-U End Marker packets in GTP-U packets according to the principles specified in clause 5.3.1 for data forwarding between the CP function and the UP function, and send them towards the F-TEID assigned in the UP function for the above PFCP session… 在这种模式下，SMF需要亲自构建End Marker报文，然后利用前述的CP/UP间数据转发机制，将其“快递”给UPF，再由UPF转发到旧的用户面路径上。这涉及到两次GTP-U封装，效率较低。

FAQ环节

Q1：为什么用户数据有时需要被发送到控制面的SMF？这是否违背了CUPS（控制面与用户面分离）的设计原则？

A1： 将特定用户数据上送SMF处理，看似与CUPS原则相悖，但实际上是为了在CUPS架构下，以一种标准化的方式解决一些必须由控制面参与的特殊业务流程。CUPS的核心是将海量的、常态化的数据包转发与少量的、决策性的信令处理分离开。对于DHCP、RADIUS认证等协议，其报文内容直接关系到PDU会话的建立和参数配置，这些是SMF的核心职责，因此必须由SMF来解析和处理。PFCP的CP/UP间数据转发机制，正是通过定义一个受控的、小带宽的GTP-U“特殊通道”，让这些少量但关键的“用户数据”能够被送到SMF，而不会影响到UPF处理海量普通数据流的高性能。这是一种在坚持CUPS大原则下的灵活变通。

Q2：什么是“部分成功（Partial Success）”特性？它在实际网络中有什么好处？

A2： “部分成功”（PSUCC）是PFCP协议中的一种容错机制。当SMF向UPF发送一个包含多条规则创建/修改指令的请求时，如果UPF因为资源不足、配置错误等原因无法执行其中某一条指令，在没有PSUCC特性的情况下，UPF会拒绝整个请求，导致所有指令都失败。而启用PSUCC特性后，UPF会尽力执行能够成功的指令，然后向SMF返回一个“请求部分接受”的响应，并通过Partial Failure Information IE明确告知哪条指令失败了以及失败的原因。这样做的好处是显著提高了网络的健壮性，避免了因单个规则的小问题导致整个会话建立或策略更新的失败，同时也为SMF提供了更精确的故障诊断信息，便于后续的策略调整或告警。

Q3：什么是End Marker？为什么在切换时需要它？

A3： End Marker（结束标记）是在移动性切换场景中，由源侧用户面节点（如S-RAN或源UPF）向下游节点发送的一种特殊信令包。它的主要作用是明确地告知下游节点：“从我这里发往旧路径的数据包到此结束”。这对于保证数据包的有序性至关重要。在切换过程中，UE的数据流路径会从旧路径切换到新路径，这意味着下游节点（如目标RAN或目标UPF）可能会同时从两条路径收到数据包。End Marker的到来，就如同旧路径队伍末尾的一面旗帜，让下游节点知道何时可以安全地停止接收旧路径的数据，并将新路径的数据无缝衔接上来，从而有效避免数据包丢失和乱序，保障了用户业务（如通话、视频）的连续性体验。

Q4：UPF是如何区分一个普通的下行数据包和一个由SMF主动下发的、需要特殊处理的数据包（如下行DHCP报文）的？

A4： UPF通过PDR中的源接口（Source Interface）字段来区分。普通的用户下行数据包来自数据网络（DN），通过N6接口进入UPF，因此它们匹配的PDR中Source Interface被设置为“Core side”。而由SMF主动下发的数据包，是通过专用的N4-u隧道发送给UPF的，它们匹配的PDR中Source Interface被设置为**“CP-function side”**（或简写为CP-function）。通过配置不同源接口的PDR，UPF可以清晰地区分来自不同逻辑源头的流量，并为它们应用不同的处理规则，例如对来自SMF的报文执行解封装，而对来自DN的报文执行封装。

Q5：PFCP协议中提到的CP（控制面）缓冲和UP（用户面）缓冲有什么区别？

A5： 两者都是为了在下行数据无法立即送达UE时进行暂存，但实现位置和适用场景不同。UP缓冲是主流的、标准化的机制，由UPF执行。当UE进入CM-IDLE状态时，SMF会通过PFCP修改FAR规则，指示UPF对下行数据进行缓冲（BUFF），并关联一条BAR（缓冲动作规则）来定义缓冲策略（如时长和包数）。这是处理CM-IDLE状态下行数据的标准流程。而CP缓冲是一种可选的、非主流的机制。在这种模式下，SMF会指示UPF将无法送达的下行数据通过N4-u隧道转发给SMF自己进行缓冲。这种方式会增加CP/UP间的信令交互和SMF的负担，通常只在特定的网络架构或业务需求下使用。😊

关系图谱