51学通信

深度解析 3GPP TS 29.244：5.2.1A Packet Detection Rule Handling (PDR处理机制详解)

20分钟阅读

好的，我们继续深入解析3GPP TS 29.244规范。

深度解析 3GPP TS 29.244：5.2.1A Packet Detection Rule Handling (PDR处理机制详解)

本文技术原理深度参考了3GPP TS 29.244 V18.9.0 (2025-03) Release 18规范中，关于“5.2.1A Packet Detection Rule Handling”的核心章节，旨在为读者深入剖析分组转发模型中最核心的组件——包检测规则（PDR）的详细配置、优化机制与高级应用。理解PDR的精髓，是掌握5G用户面可编程性的关键。

引言：PDR——用户面流量处理的“第一道门”

在上一篇文章中，我们对TS 29.244第5章的核心——分组转发模型（Packet Forwarding Model）进行了宏观解读。我们了解了UPF如何像一个高度可编程的流水线，依据SMF下发的PDR、FAR、QER、URR等一系列规则，对数据包进行精细化处理。其中，**包检测规则（PDR）**作为整个流程的入口，其作用是无可替代的“侦察兵”，负责精准地“识别”出每一个数据包的“身份”。只有被正确识别，数据包才能被后续的规则正确地处理。

本文将聚焦于规范的5.2.1A章节，对PDR的处理机制进行一次“显微镜”级别的深度剖析。我们将探讨PDR的配置原则、如何通过“流量端点”优化信令、双向过滤器的应用场景，以及如何通过应用ID和PFD实现超越IP五元组的深度应用识别。

我们将继续跟随主角“鹰眼-01”的脚步，但场景将变得更为复杂，以凸显PDR精细化配置的重要性： 主角设定：工业质检摄像头“鹰眼-01”。 场景深化：“鹰眼-01”的PDU会话中承载着三类上行业务流，它们都需要被UPF精确区分：

  1. 高优先级视频流：UDP流量，发往边缘AI服务器10.1.1.1的8888端口，用于实时瑕疵检测。
  2. 低优先级遥测流：HTTPS流量，发往云端监控平台https://telemetry.myfactory.com，用于上报摄像头状态。
  3. 双向控制流：TCP流量，用于与边缘AI服务器10.1.1.1的9999端口进行双向信令交互，如接收PTZ（云台俯仰变焦）控制指令并回送状态。 SMF必须为这三类截然不同的流量制定出无歧义、高效率的PDR组合，这正是本篇文章要详细阐述的核心内容。

1. PDR配置基本原则 (5.2.1A.1 General)

PDR的核心是其内部的包检测信息（PDI），它定义了一组用于匹配数据包的字段和值。为了保证UPF处理的确定性，规范首先明确了一个基本原则：唯一性。

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; in this case, it is the precedence of the PDRs that determines which PDR is applied.

这段规定非常关键。它意味着在一个PFCP会话中，不允许存在两条PDI完全相同的PDR。这是因为如果存在两条完全相同的规则，当一个数据包到来时，UPF将无法确定应该应用哪一条，导致处理逻辑的混乱。

但是，规范允许存在PDI“部分”相同的PDR。在这种情况下，必须通过**优先级（Precedence）**来区分它们。UPF在查找匹配规则时，会从优先级最高（数值最小）的PDR开始，一旦找到匹配的，就立即停止查找。这确保了“更具体”的规则总能优先于“更通用”的规则被匹配。

场景示例： 假设SMF要为“鹰眼-01”配置处理规则。

  • 合规配置：
    • PDR 1 (Precedence=100)：PDI匹配所有发往10.1.1.1的数据包。
    • PDR 2 (Precedence=50)：PDI匹配发往10.1.1.1且目的端口为8888的UDP数据包。 这是一个合规且常见的配置。当一个发往10.1.1.1:8888的UDP视频包到达时，它同时满足PDR 1和PDR 2的条件。但由于PDR 2的优先级更高（50 < 100），UPF会优先匹配PDR 2，并执行其关联的规则（例如高带宽的QER），从而保证了视频流的特殊处理。
  • 违规配置：
    • PDR 3 (Precedence=200)：PDI匹配所有发往10.1.1.1的数据包。
    • PDR 4 (Precedence=300)：PDI同样匹配所有发往10.1.1.1的数据包。 这是一个违规配置。SMF不应向下发送这样的指令，因为PDI的匹配字段和值完全相同，违反了唯一性原则。

2. 提升信令效率：PDI优化与流量端点 (5.2.1A.2 PDI Optimization)

在一个复杂的PDU会话中，可能会有数十甚至上百条PDR。例如，“鹰眼-01”的所有上行流量都来自同一个N3隧道，这意味着它们共享相同的Source Interface和Local F-TEID。如果在每一条上行PDR中都重复携带这些信息，会造成巨大的信令冗余。为此，规范引入了PDI优化机制。

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）**可以被理解为一个“PDI信息模板”。SMF可以将多个PDR共有的PDI字段（如Source Interface, Local F-TEID, UE IP Address, Network Instance等）提取出来，打包成一个带有唯一ID的Traffic Endpoint。之后，在创建那些共享这些信息的PDR时，只需在其PDI中引用这个Traffic Endpoint ID即可，无需再携带完整的公共信息。

场景示例： 为了优化“鹰眼-01”的上行PDR配置，SMF可以这样做：

  1. 创建流量端点：
    • 首先，SMF向UPF发送一条PFCP消息，创建一个ID为TEID_UL_Eagle01的Traffic Endpoint。
    • 该Traffic Endpoint包含公共信息：Source Interface = Access side, Local F-TEID = [鹰眼-01的N3隧道信息]。
  2. 创建引用该端点的PDRs：
    • PDR-Video (Precedence=100): PDI中不再包含F-TEID等信息，而是包含Traffic Endpoint ID = TEID_UL_Eagle01，并附加上其独有的SDF Filter：dest IP=10.1.1.1, dest port=8888, proto=UDP。
    • PDR-Control (Precedence=80): PDI中同样包含Traffic Endpoint ID = TEID_UL_Eagle01，并附加上其独有的SDF Filter：dest IP=10.1.1.1, dest port=9999, proto=TCP。
    • PDR-Telemetry (Precedence=200): PDI中也包含Traffic Endpoint ID = TEID_UL_Eagle01，并附加上独有的应用ID：Application ID = TelemetryApp (详见后文)。

通过这种方式，Source Interface和Local F-TEID这两个较长的字段只下发了一次，显著减少了N4接口上的信令负载。

2.1 SDF过滤器的灵活配置 (5.2.1A.2A Provisioning of SDF filters)

SDF过滤器（即IP五元组）作为最精细的匹配工具，其配置位置也相当灵活，可以配合流量端点实现进一步优化。

An SDF filter may be provisioned either as part of the PDI of a PDR which does not refer to a Traffic Endpoint, or as part of the PDI of a PDR which refers to a Traffic Endpoint, or as part of a Traffic Endpoint.

这意味着SDF过滤器可以被放在三个不同的位置：

  • 直接在PDR的PDI中：适用于不使用Traffic Endpoint的简单场景。
  • 在引用了Traffic Endpoint的PDR的PDI中：这是最常见的用法，Traffic Endpoint定义了连接的“端点”，PDR中的SDF Filter定义了该端点上的具体业务流。
  • 直接在Traffic Endpoint中：如果多个PDR不仅共享L3/L4端点信息，还共享同一个SDF Filter，那么这个SDF Filter也可以被放入Traffic Endpoint中。

场景示例： 假设“鹰眼-01”的视频流和PTZ控制流都发往10.1.1.1，SMF可以创建一个包含Destination IP = 10.1.1.1的Traffic Endpoint。然后，PDR-Video和PDR-Control各自在其PDI中添加dest port来区分彼此。这展示了第二种用法。如果未来有一种新业务，它也使用10.1.1.1:8888这个地址和端口，但需要根据其他PDI字段（例如不同的QFI）做进一步区分，那么dest IP=10.1.1.1, dest port=8888就可以被放入一个更具体的Traffic Endpoint中，供多个PDR引用。

3. 简化配置：双向SDF过滤器 (5.2.1A.3 Bidirectional SDF Filters)

对于许多通信场景，上下行流量的五元组是相互对称的。例如，“鹰眼-01”的PTZ控制流，上行是从[UE IP]:PortA到10.1.1.1:9999，下行则是从10.1.1.1:9999到[UE IP]:PortA。为这种场景分别配置上行和下行两条PDR会显得冗余。因此，规范支持了双向SDF过滤器。

When the bidirectional SDF filter is provisioned for a PDR, the SDF Filter shall apply to both uplink and downlink directions. The CP function shall provision only one PDR with a bidirectional SDF filter for a given SDF in a PFCP session.

当SMF在一条SDF Filter中设置了“双向”标志时，UPF会自动用它来匹配两个方向的流量。

  • 对于上行流量，UPF会严格按照SDF Filter中定义的源/目的IP和端口进行匹配。
  • 对于下行流量，UPF会自动将SDF Filter中的源/目的IP和端口反转后进行匹配。

场景示例： 为了处理“鹰眼-01”的双向PTZ控制流，SMF只需下发一条PDR：

  • PDR-Control (Precedence=80):
    • PDI:
      • Source Interface = Access side
      • SDF Filter (bidirectional): src IP=[UE IP], dest IP=10.1.1.1, src port=*, dest port=9999, proto=TCP
    • 关联的FAR: Apply Action = FORW, Destination Interface = Core side
    • 关联的QER/URR等。 UPF收到这条规则后，其行为如下：
  1. 当一个上行TCP包从[UE IP]到10.1.1.1:9999，它会匹配这条PDR，并被转发到Core side。
  2. 当一个下行TCP包从10.1.1.1:9999到[UE IP]，UPF会自动将SDF Filter反转来匹配，发现也匹配成功。此时，UPF会忽略PDR中的Source Interface字段（因为它是为上行设计的），直接应用关联的FAR。但FAR指示转发到Core side，这显然不适用于下行包。这是一个关键点，规范在FAR的定义中解决了这个问题：FAR可以包含针对不同方向的转发参数。因此，这条PDR关联的FAR会是这样的：Apply Action = FORW, Forwarding Parameters for UL: {Dest Interface = Core}, Forwarding Parameters for DL: {Dest Interface = Access}。这样，UPF就能正确处理双向流量了。

4. 超越五元组：基于PFD的应用检测 (5.2.1A.4 Application detection with PFD)

随着网络应用的发展，仅靠IP五元组识别流量变得越来越困难。例如，“鹰眼-01”的遥测数据使用HTTPS，端口固定为443，这与无数其他网页浏览、App后台通信流量的端口完全一样。如何区分它们？答案是进行应用层检测。

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. When application detection applies to a PDR, the PDI of that PDR contains an Application ID.

这个机制分为两步：

  1. PFD管理：SMF通过一个独立的PFD管理流程，向UPF下发一份“应用指纹库”。这份库定义了**应用ID（Application ID）和包流描述（Packet Flow Descriptions, PFDs）**之间的映射关系。PFD可以定义应用层的匹配规则，例如HTTP Host头部字段、TLS SNI（服务器名称指示）字段等。
  2. PDR配置：在需要进行应用检测的PDR中，PDI不再使用SDF Filter，而是直接使用Application ID。

场景示例： 为了识别“鹰眼-01”发往https://telemetry.myfactory.com的遥测流量：

  1. PFD管理：SMF首先向UPF下发PFD，内容大致为：
    • Application ID: TelemetryApp-01
    • PFD: 匹配TLS Client Hello消息中SNI = telemetry.myfactory.com的流量。
  2. PDR配置：
    • PDR-Telemetry (Precedence=200):
      • PDI:
        • Traffic Endpoint ID = TEID_UL_Eagle01
        • Application ID = TelemetryApp-01 UPF收到目的为任意IP地址443端口的TLS包后，如果其PDI中包含Application ID，UPF就会执行深度包检测。它会解析TLS握手包，提取SNI字段。如果SNI的值是telemetry.myfactory.com，则与PFD匹配，进而与PDR-Telemetry匹配。这样，遥测流量就被从海量的HTTPS流量中精确地识别了出来，并可以应用特定的QoS、计费和转发策略。

FAQ环节

Q1：PDI（包检测信息）和Traffic Endpoint（流量端点）有什么区别？

A1：PDI是定义在单个PDR内部的一组匹配字段，用于识别特定的数据包，是PDR的“匹配条件”部分。而Traffic Endpoint是一个独立于PDR的对象，它的作用是将多个PDR所共有的PDI字段（例如来自同一个UE的所有上行流量都共享的Source Interface和Local F-TEID）打包成一个可复用的“模板”。PDR可以通过引用Traffic Endpoint ID来继承这些公共字段，从而大大减少N4接口上的信令开销。简单来说，PDI是单个规则的匹配内容，而Traffic Endpoint是多个规则共享的PDI内容的“快捷方式”。

Q2：一个数据包可以同时应用双向SDF过滤器和应用ID（PFD）吗？

A2：不可以。在一个PDR的PDI中，SDF过滤器和应用ID是两种不同的、通常是互斥的流量识别维度。SDF过滤器工作在网络层和传输层（L3/L4），而应用ID则触发应用层（L7）的深度包检测。一个PDR通常会选择其中一种作为其核心识别手段。此外，双向SDF过滤器的机制是基于IP和端口的对称性反转，这种机制无法直接应用于复杂的、非对称的应用层协议特征，因此它与PFD的应用场景是分开的。

Q3：使用应用ID（Application ID）进行流量检测，对UPF的性能有什么影响？

A3：相比于仅基于IP五元组（SDF Filter）的检测，使用应用ID和PFD进行检测对UPF的性能要求更高。基于SDF Filter的检测通常可以通过硬件（如ASIC）高效完成，因为它只检查固定的IP和TCP/UDP头部字段。而基于应用ID的检测则需要UPF执行深度包检测（DPI），解析更高层协议（如TLS、HTTP）的载荷内容，这通常需要更多的CPU计算资源，可能会带来一定的处理时延和吞吐量下降。因此，网络规划时需要根据业务需求，在识别精度和处理性能之间做出权衡，并将具备相应DPI能力的UPF部署在合适的网络位置。

Q4：如果一个PDR的PDI中既包含了Traffic Endpoint ID，又包含了SDF Filter，UPF会如何匹配？

A4：在这种情况下，UPF会执行“与”逻辑。一个数据包必须同时满足Traffic Endpoint中定义的所有匹配条件，并且满足该PDR的PDI中定义的SDF Filter条件，才算与该PDR匹配。这是一种非常灵活和强大的组合方式，允许在共享的端点基础上，为不同的业务流定义精细化的匹配规则。例如，我们的场景中，所有上行流量共享一个Traffic Endpoint（基于F-TEID），而视频流和控制流则通过各自PDR中的SDF Filter（基于端口号）来进一步区分。

Q5：PFD（包流描述）是由谁生成的？它可以更新吗？

A5：PFD通常是由网络运营商或通过北向接口由第三方应用提供商定义，并由控制面网元（在5GC中是PCF，然后下发给SMF）进行统一管理。SMF负责通过PFCP协议的PFD管理流程将这些PFD下发到UPF。PFD是可以动态更新的。当一个应用的服务器地址、域名或者协议特征发生变化时，PCF可以通知SMF，SMF再通过PFD管理流程向UPF推送更新后的PFD内容，从而保证UPF能够持续准确地识别该应用，这体现了5G用户面策略控制的灵活性和动态性。

关系图谱