好的，我们继续。

深度解析 3GPP TS 29.244：5.1 & 5.2 Packet Forwarding Model (Part 1 - 核心模型与PDR处理)

本文技术原理深度参考了3GPP TS 29.244 V18.9.0 (2025-03) Release 18规范中，关于“第5章 General description”及“第5.2节 Packet Forwarding Model”的核心章节，旨在为读者构建一个关于PFCP协议核心数据转发模型的全景视图。本文将聚焦于PFCP最核心的规则——包检测规则（PDR）的原理、构成与处理机制。

前言：从“范围”到“模型”

在上一篇文章中，我们解读了TS 29.244的第1章“Scope”，明确了PFCP协议作为5G核心网CUPS架构基石的定位、应用接口（如N4）以及通信双方（CP功能与UP功能）的角色。这为我们理解PFCP协议“是什么”和“用在哪”奠定了基础。

然而，真正理解一项协议的精髓，在于深入其内部机制，探究它“如何工作”。从本篇文章开始，我们将正式进入TS 29.244的核心技术腹地——第5章所定义的分组转发模型（Packet Forwarding Model）。这一模型是PFCP协议的灵魂，它定义了控制面（CP）如何通过一系列标准化的规则集，精确指挥用户面（UP）对每一个数据包进行细粒度的处理。

在开始深度解析之前，需要说明的是，规范的第2章“References”和第3章“Definitions and abbreviations”提供了重要的参考和术语基础。其中，第2章是规范所引用的外部文档列表，我们无需为其撰写独立文章；第3章则定义了大量术语，为了避免陷入枯燥的术语罗列，我们将不在本文中逐条解释，而是在后续解读具体技术点时，结合场景进行穿插说明，使读者能在实际语境中更深刻地理解其含义。

我们将继续沿用智能制造工厂的场景，与我们的主角——AI质检摄像头“鹰眼-01”——一同探索PFCP的转发世界。

场景回顾：“鹰眼-01”通过5G专网，将高清视频流实时传输至工厂边缘的AI服务器。会话管理功能（SMF）作为控制面的“大脑”，必须通过N4接口上的PFCP协议，向用户面功能（UPF）下达一套完整的指令，告诉UPF如何识别、转发、保障并统计“鹰眼-01”的数据流。这套指令的集合，正是由分组转发模型所定义的。

1. PFCP分组转发模型概述

PFCP协议的核心思想，是将复杂的数据处理逻辑分解为一系列模块化的规则，由CP功能（如SMF）生成，并下发给UP功能（如UPF）执行。这种模型极大地增强了用户面处理的灵活性和可编程性。

The CP function controls the packet processing in the UP function by establishing, modifying or deleting PFCP Session contexts and by provisioning (i.e. adding, modifying or deleting) PDRs, FARs, QERs, URRs, BAR and/or MAR or by activating/deactivating pre-defined PDRs, FARs, QERs, URRs, per PFCP session context…

正如规范所言，CP对UP的控制是通过管理**PFCP会话上下文（PFCP Session Context）**来实现的。对于每一个PDU会话，SMF都会在UPF上创建一个对应的PFCP会话上下文。这个上下文包含了一套完整的规则，主要包括以下几种：

• PDR (Packet Detection Rule - 包检测规则)：是整个模型的入口和触发器。它的任务是“识别”数据包，定义了匹配特定数据流的条件。
• FAR (Forwarding Action Rule - 转发行为规则)：指示UPF将PDR识别出的数据包“发往何处”，例如是转发到数据网络、丢弃、还是送往CP面进行处理。
• QER (QoS Enforcement Rule - QoS执行规则)：规定了数据包的“服务质量”要求，如保证比特率（GBR）、最大比特率（MBR）以及QoS标记等。
• URR (Usage Reporting Rule - 使用情况报告规则)：定义了如何对数据包进行“统计与报告”，用于计费和流量监控。
• BAR (Buffering Action Rule - 缓冲行为规则)：当数据包需要被临时缓存时（例如UE处于空闲态），BAR定义了具体的“缓冲策略”。
• MAR (Multi-Access Rule - 多接入规则)：专用于ATSSS（多接入流量导向、切换与分离）场景，指示数据包如何在3GPP和非3GPP接入之间进行“分流或切换”。

这些规则之间通过ID进行关联，形成一个逻辑清晰、功能完备的指令集。

1.1 UPF的数据包处理流程

当一个数据包（无论是上行还是下行）到达UPF时，UPF的处理逻辑是高度确定和标准化的，这也是该模型强大之处。

On receipt of a user plane packet, the UP function shall perform a lookup of the provisioned PDRs in the UP function to identify only one PDR in a PFCP session according to the following steps:

• identify first the PFCP session to which the packet corresponds; and
• find the first PDR matching the incoming packet, among all the PDRs provisioned for this PFCP session, starting with the PDRs with the highest precedence and continuing then with PDRs in decreasing order of precedence.

UPF的处理流程可以概括为两步查找法：

1. PFCP会话查找：首先，UPF需要确定这个数据包属于哪个UE的哪个PDU会话，即定位到对应的PFCP会话上下文。这个查找通常基于数据包的底层隧道信息（如GTP-U隧道ID）或IP地址等。
2. PDR查找：在确定了PFCP会话后，UPF会遍历该会话内的所有PDR，按照**优先级（Precedence）**从高到低的顺序进行匹配。一旦找到第一个完全匹配该数据包的PDR，查找即停止。

规范中的 Figure 5.2.1-1: Packet processing flow in the UP function 直观地展示了这一过程。这张图告诉我们，一个数据包进入UPF后，会经过“PFCP Session look up”和“PFCP session’s PDR look up”两个阶段，最终找到唯一一个最高优先级的匹配PDR。

找到匹配的PDR后，UPF就会执行该PDR所关联的一系列规则（FARs, QERs, URRs等），完成对该数据包的转发、QoS保障、计费统计等一系列动作，最终将处理后的数据包“Packet Out”。

场景示例： 当“鹰眼-01”的视频数据包（上行）到达UPF时：

1. 会话查找：UPF检查数据包的GTP-U头部，通过隧道端点标识符（TEID）识别出这个包来自服务于“鹰眼-01”的基站隧道，从而定位到为“鹰眼-01”的PDU会话所建立的PFCP会话上下文。
2. PDR查找：UPF在该上下文中查找匹配的PDR。假设SMF为“鹰眼-01”配置了两个上行PDR：
   • PDR_Video (Precedence=100)：用于匹配发往AI服务器（端口8888）的高清视频流。
   • PDR_Heartbeat (Precedence=200)：用于匹配发往运维中心（端口9999）的心跳/状态包。 UPF首先用PDR_Video的规则去匹配，如果数据包的目的端口是8888，则匹配成功，UPF立即停止查找，并执行PDR_Video关联的FAR、QER等规则。如果目的端口不是8888，UPF继续用PDR_Heartbeat去匹配，如果匹配成功，则执行其关联规则。这个严格的优先级机制保证了不同业务流量能够得到差异化的处理。

2. 模型的基石：PDR (Packet Detection Rule) 深度解析

从上述流程可以看出，PDR是整个分组转发模型的入口和决策起点，其重要性不言而喻。一个PDR的定义是否准确，直接决定了用户数据流能否被正确地识别和处理。接下来，我们将深入剖析PDR的构成和关键机制。

2.1 PDR的核心作用与匹配原则

The CP function shall not provision more than one PDR with the same match fields in the PDI (i.e. with the same set of match fields and with the same value). The CP function may provision PDRs with the same value for a subset of the match fields of the PDI but not all;

规范明确规定，在一个PFCP会话内，不允许存在两个具有完全相同匹配字段和值的PDR。这保证了匹配结果的唯一性。然而，允许存在部分匹配字段相同的PDR，并通过优先级（Precedence）来区分它们。优先级是一个数值，数值越小，优先级越高。

As an exception to the previous principle, the CP function may provision a PDR with all match fields wildcarded (i.e. all match fields omitted in the PDI) in a separate PFCP session, to control how the UP function shall process packets unmatched by any PDRs of any other PFCP session. The CP function may provision the UP function to send these packets to the CP function or to drop them. The UP function shall grant the lowest precedence to this PDR.

此外，规范还定义了一种特殊的“通配PDR（wildcarded PDR）”。这个PDR不包含任何具体的匹配字段，可以匹配任何数据包。它通常被赋予最低的优先级（即数值最大），作为一种“默认规则”或“兜底规则”。如果一个数据包遍历了所有高优先级的具体PDR后都未匹配成功，最后就会落入这个通配PDR的范围。SMF可以配置这个PDR关联的FAR，指示UPF是丢弃这些未知流量，还是将其上报给SMF做进一步分析，这对于网络的安全和故障排查非常有价值。

2.2 PDR的关键组成：PDI (Packet Detection Information)

PDR的核心是包检测信息（Packet Detection Information, PDI）。PDI定义了用于识别数据包的一组匹配条件。一个数据包必须满足PDI中定义的所有条件，才算与该PDR匹配。

参考3GPP TS 23.501中的 Table 5.8.5.3-1: Attributes within Packet Detection Rule 以及TS 29.244中的相关描述，PDI包含了一系列丰富的匹配字段，其中最核心的包括：

• Source Interface (源接口)：定义了数据包的来源方向。常用值包括：

  • Access side：来自无线接入网（AN）侧，通常指上行流量。
  • Core side：来自数据网络（DN）侧，通常指下行流量。
  • SMF：来自SMF，用于CP和UP之间传输特定信令（如DHCP）。
  • 5G VN internal：用于5G虚拟网络（5G VN）组内通信的本地转发。

• Local F-TEID (本地F-TEID)：F-TEID（Fully Qualified TEID）包含了UPF分配的GTP-U隧道端点标识符（TEID）和UPF自身的IP地址。这是识别上行数据流来源的最常用字段，因为它唯一标识了一个从基站到UPF的用户面隧道。

• UE IP address (UE IP地址)：用于匹配数据包的源IP地址（上行）或目的IP地址（下行）。这对于非GTP封装的流量（如离开UPF进入DN的流量）或需要基于IP地址进行精细化策略的场景至关重要。

• SDF Filter (业务数据流过滤器)：这是最精细的匹配规则，通常是一个五元组（源/目的IP地址、源/目的端口号、协议号）。通过SDF Filter，UPF可以识别出特定应用或服务的流量。

• Application ID (应用ID)：当需要进行应用层检测时使用。该ID关联一组由SMF预先下发给UPF的包流描述（Packet Flow Descriptions, PFD）。UPF会根据PFD的内容进行深度包检测（DPI），识别出特定应用的流量，例如识别出某款视频App的流量，而不仅仅是匹配端口号。

场景示例： 我们来为“鹰眼-01”的完整通信链路设计一套PDRs：

1. 上行视频流PDR (UL Video)：

   • PDI:
     • Source Interface: Access side
     • Local F-TEID: [UPF为鹰眼-01分配的N3隧道TEID]
     • SDF Filter: Destination IP = [AI服务器IP], Destination Port = 8888, Protocol = UDP
   • 功能：精准识别从“鹰眼-01”发出、经由N3隧道、发往AI服务器的UDP视频流。

2. 上行心跳包PDR (UL Heartbeat)：

   • PDI:
     • Source Interface: Access side
     • Local F-TEID: [UPF为鹰眼-01分配的N3隧道TEID]
     • SDF Filter: Destination IP = [运维中心IP], Destination Port = 9999, Protocol = TCP
   • 功能：识别发往运维中心的心跳包。

3. 下行AI指令PDR (DL Command)：

   • PDI:
     • Source Interface: Core side
     • UE IP address: [鹰眼-01的IP地址]
     • SDF Filter: Source IP = [AI服务器IP], Source Port = 8888, Protocol = UDP
   • 功能：精准识别从AI服务器发回给“鹰眼-01”的控制指令或分析结果。

2.3 PDI优化：Traffic Endpoint (流量端点)

当一个PFCP会话中包含大量PDR时，如果许多PDR共享相同的PDI字段（例如，来自同一个UE的所有上行PDR都共享相同的Local F-TEID），反复在每个PDR中下发这些相同信息会造成信令冗余。为此，规范引入了PDI优化机制。

The PDI Optimization feature should be supported by CP and UP functions complying with this release of the specification. This feature allows the CP function to optimize the signaling towards the UP function by creating the information that are common to multiple PDRs as a Traffic Endpoint with a Traffic Endpoint ID and then referring to this common information from multiple PDRs.

这个机制的核心是流量端点（Traffic Endpoint）。SMF可以将多个PDR共有的PDI信息（如Local F-TEID、UE IP地址、Network Instance等）提取出来，定义成一个带有唯一ID的Traffic Endpoint。之后，在创建这些PDR时，只需在PDI中引用这个Traffic Endpoint ID，而无需再携带那些公共信息。

场景示例： 对于“鹰眼-01”的上行流量，PDR_Video和PDR_Heartbeat都共享相同的Source Interface和Local F-TEID。使用Traffic Endpoint优化后，SMF的指令将变为：

1. Create Traffic Endpoint (ID=1):
   • Source Interface: Access side
   • Local F-TEID: [UPF为鹰眼-01分配的N3隧道TEID]
2. Create PDR_Video (Precedence=100):
   • PDI:
     • Traffic Endpoint ID: 1
     • SDF Filter: Destination IP = [AI服务器IP], Destination Port = 8888, Protocol = UDP
3. Create PDR_Heartbeat (Precedence=200):
   • PDI:
     • Traffic Endpoint ID: 1
     • SDF Filter: Destination IP = [运维中心IP], Destination Port = 9999, Protocol = TCP

通过这种方式，公共信息只下发了一次，显著减少了N4接口上的信令开销，尤其是在具有复杂业务模型的场景下，优化效果更为明显。

2.4 其他PDR特性

除了上述核心机制，PDR还支持一些其他重要特性，进一步增强了其灵活性。

2.4.1 基于PFD的应用检测 (Application detection with PFD)

The detection information for a given application may be provisioned by the CP function to the UP function via PFD management procedure. See clause 6.2.5.

当PDR中的PDI包含应用ID（Application ID）时，意味着启动了基于应用特征的检测，而不仅仅是基于IP五元组。这个应用ID关联着一组由SMF通过PFD管理流程（PFD Management Procedure）下发给UPF的包流描述（Packet Flow Descriptions, PFDs）。PFD中定义了识别某个应用的具体规则，例如特定HTTP头字段、URL关键字等。UPF会利用这些PFD对匹配PDR的数据包进行深度检测，从而实现对应用的精准识别。

2.4.2 双向SDF过滤器 (Bidirectional SDF Filters)

When the bidirectional SDF filter is provisioned for a PDR, the SDF Filter shall apply to both uplink and downlink directions.

通常情况下，SDF过滤器是单向的。但规范也支持双向SDF过滤器（Bidirectional SDF Filters）。当SMF在一个SDF Filter中设置了双向标记时，UPF会自动将其应用于上行和下行两个方向。例如，一个双向的SDF Filter定义了 IP_A:Port_X <-> IP_B:Port_Y，那么无论是从A到B的流量，还是从B到A的流量，都会被这个过滤器匹配。这简化了对称通信场景（如多数客户端-服务器交互）的规则配置。

FAQ环节

Q1：PDR、FAR、QER、URR这些规则之间是什么关系？哪个是核心？ A1：这些规则共同构成了PFCP对一个数据流的完整处理逻辑，它们之间是“触发与执行”的关联关系。PDR（包检测规则）是绝对的核心和入口。当一个数据包到达UPF，UPF的首要任务就是根据优先级找到匹配该数据包的PDR。PDR本身不定义具体动作，但它包含了指向其他规则的ID，如FAR ID、QER ID、URR ID(s)。一旦PDR匹配成功，UPF就会根据这些ID找到对应的FAR、QER、URR等规则，并执行它们所定义的动作：FAR决定“如何转发”，QER决定“服务质量”，URR决定“如何计费”。可以理解为PDR是“if条件”，而FAR/QER/URR是“then动作”。

Q2：PDR的“Precedence”（优先级）有什么用？为什么需要它？ A2：Precedence（优先级）是解决规则冲突、实现差异化服务的关键机制。在一个PDU会话中，一个数据包可能同时满足多个PDR的匹配条件。例如，一个发往视频服务器的HTTP流量，既满足“匹配所有HTTP流量”的PDR，也满足“匹配所有发往该视频服务器IP”的PDR。此时，就需要Precedence来决定哪个规则先生效。Precedence是一个数值，数值越小，优先级越高。UPF会按照优先级从高到低的顺序检查PDR，一旦找到第一个匹配的PDR，就立即停止查找并执行。这确保了更具体、更重要的业务规则（如针对特定应用的规则）能优先于更宽泛、通用的规则（如匹配所有流量的规则）被执行，从而实现对高价值业务的优先处理和保障。

Q3：什么是PDI？它和PDR是什么关系？ A3：PDI（Packet Detection Information，包检测信息）是PDR（包检测规则）的一个核心组成部分，是PDR内部用于定义“匹配条件”的结构化信息。可以理解为PDR是一个容器，而PDI是这个容器里装着的具体“匹配说明书”。PDI包含了诸如源接口、UE IP地址、本地F-TEID、SDF过滤器（五元组）等一系列字段。一个数据包必须同时满足PDI中定义的所有字段条件，才算与这个PDR匹配。因此，PDR定义了一条检测规则的整体属性（如规则ID、优先级），而PDI则具体规定了这条规则的检测内容。

Q4：为什么要引入Traffic Endpoint（流量端点）这种优化机制？ A4：引入Traffic Endpoint是为了优化N4接口的信令效率，减少冗余信息的传输。在一个复杂的PDU会话中，一个UE可能会有多种不同业务类型的上行或下行数据流，SMF需要为每种数据流配置不同的PDR。但这些PDR往往有很多共同的PDI信息，例如，来自同一个UE的所有上行数据流都共享相同的源接口（Access side）和相同的N3隧道信息（Local F-TEID）。如果没有优化，这些相同的信息需要在每个PDR中重复下发。Traffic Endpoint机制将这些公共信息提取出来，定义成一个可被引用的“流量端点”，并分配一个ID。之后，SMF在下发PDR时，只需携带这个ID，而无需再携带庞大的公共信息本身，从而显著降低了PFCP消息的大小和处理开销。

Q5：UPF如何区分来自不同UE的数据包？最常用的PDI字段是什么？ A5：UPF区分不同UE的数据包主要依赖PDI中的关键标识字段。在5G网络中，最常用且最可靠的字段是Local F-TEID（本地完全限定隧道端点标识）。当UE通过基站（gNB）与UPF建立用户面连接（N3隧道）时，UPF会为这个隧道分配一个唯一的TEID。所有从该UE经由该gNB发来的上行数据包，都会被封装在以此TEID为标识的GTP-U隧道中。因此，UPF仅通过检查GTP-U头部的TEID，就能准确无误地将会话定位到具体的UE。对于下行流量，PDI中的UE IP address则是关键的识别字段，UPF通过匹配数据包的目的IP地址来确定该数据包应被发往哪个UE。