当 UPF 收到一个用户面数据包时，并不会立即决定该数据包应转发到哪里。它首先需要确定数据包属于哪个 PFCP 会话，以及应应用哪条处理规则。在 N4 接口的 PFCP 规则框架中， PDR（Packet Detection Rule，数据包检测规则） 负责数据包处理的第一阶段。PDR 告诉 UPF 哪些数据包属于某一特定流量类别。数据包一旦匹配，UPF 就可以应用关联的 FAR、QER、URR 及其他规则，完成转发、QoS 执行和用量上报。
理解 PDR 最简单的方法，是把三个不同职责分开来看： PDR 负责识别流量，PDI 定义匹配条件，而 FAR/QER/URR 决定匹配后如何处理。 把这些角色区分开，比逐个记忆所有 IE 更容易理解 PFCP 数据包处理过程。
PDR 在 N4 接口上解决什么问题？
N4 是 5G 核心网中 SMF 与 UPF 之间的控制接口。SMF 通过 PFCP 会话向 UPF 下发用户面处理规则，其中 PDR 是负责检测和分类数据包的规则类型。PDR 通常在 PFCP 会话建立过程中创建，之后还可以通过 PFCP 会话修改进行新增、删除或更新。也就是说，数据包分类由 SMF 根据当前 PDU Session、业务流和转发需求下发的规则进行控制。
一个 PFCP 会话可以包含多个 PDR。例如，同一个 PDU Session 通常需要分别为上行和下行流量配置规则。当会话中包含多个业务数据流、不同 QoS Flow，或需要更细粒度的流量分类时，还可能需要额外的 PDR。因此，可以把 PDR 看作 UPF 的流量选择规则：它先判断到达的是哪一类数据包，然后再由其他规则决定如何处理该数据包。
UPF 如何找到匹配的 PDR？
UPF 中的数据包处理遵循明确的顺序。数据包进入 UPF 后，首先识别对应的 PFCP 会话，然后评估该会话关联的 PDR。如果有多个 PDR 都可能匹配，UPF 会使用 Precedence（优先级） 值确定它们的相对优先顺序。Precedence 数值越小，优先级越高，因此在查找匹配规则时，高优先级规则会先于低优先级规则被评估。
当某个 PDR 匹配后，PDR 本身并不会完成后续所有数据包处理操作，而是可以引用其他 PFCP 规则：
FAR（Forwarding Action Rule，转发动作规则）：决定数据包应如何处理和转发，包括转发、丢弃、缓存，或发送到特定目标接口。
QER（QoS Enforcement Rule，QoS 执行规则）：应用与 QoS 相关的控制，例如门控、速率限制以及其他流量处理策略。
URR（Usage Reporting Rule，用量上报规则）：统计流量使用情况，并提供可用于计费、监控或策略相关用途的上报信息。
因此，UPF 的整体处理路径可以简化为：
识别 PFCP 会话 → 按 Precedence 评估 PDR → 对数据包分类 → 应用 FAR/QER/URR。 处理顺序非常重要。FAR 回答的是数据包应如何处理，而 UPF 必须先通过 PDR 确定该动作适用于哪个数据包或业务流。
PDR 中有哪些主要参数？
Create PDR 包含多个 Information Element，但在理解数据包检测行为时，只需要先掌握其中一组关键参数。这些参数定义规则如何被标识、数据包如何进行匹配，以及匹配结果关联哪些后续处理规则。
| 参数 | 主要作用 |
|---|---|
| PDR ID | 在 PFCP 会话内唯一标识该 PDR，并将其与其他数据包检测规则区分开 |
| Precedence | 当评估多个规则时定义 PDR 的相对优先级；数值越小表示优先级越高 |
| PDI | 包含 UPF 用于判断入站流量是否匹配 PDR 的数据包检测条件 |
| Outer Header Removal（外层头删除） | 指示 UPF 是否删除外层协议头，例如上行流量中的 GTP-U/UDP/IP 头 |
| FAR ID | 引用定义匹配数据包转发动作的 FAR |
| URR ID | 引用用于流量统计和用量上报的 URR |
| QER ID | 引用对匹配流量实施 QoS 处理的 QER |
| Activate Predefined Rules（激活预定义规则） | 激活一个或多个已在 UPF 中预先配置的规则 |
| Activate Time / Deactivate Time（激活时间/停用时间） | 定义 PDR 何时生效以及何时停止生效 |
在这些参数中，真正定义 哪些数据包可以匹配 PDR 的是 PDI（Packet Detection Information，数据包检测信息）。FAR ID 和 QER ID 引用的是流量完成分类后执行的动作；PDI 则包含完成分类本身所需的信息。
PDI 如何定义数据包匹配条件？
PDI 可以理解为 PDR 内部的一组数据包检测条件。它不是单一字段，而是包含多个参数，这些参数可以组合使用，根据数据包进入 UPF 的位置、隧道信息、UE 地址、业务流特征和 QoS 信息来识别流量。常见的 PDI 参数包括：
Source Interface（源接口）：标识数据包从哪个逻辑侧进入，例如 Access 表示接入侧流量，或 Core 表示来自核心网或数据网络侧的流量。
Local F-TEID（本地 F-TEID）：可用于匹配与 GTP-U 隧道关联的 TEID 及相关地址信息，因此在检测上行隧道流量时尤其重要。
Network Instance（网络实例）：标识 UPF 中配置的逻辑网络，例如与 Internet 或 IMS 相关的网络实例。
UE IP Address（UE IP 地址）：根据数据包方向，按 UE 的源 IP 地址或目标 IP 地址匹配流量。
Traffic Endpoint ID（流量端点 ID）：标识一个可用于受支持 PDI 优化场景的流量端点。
SDF Filter（SDF 过滤器）：基于源地址、目标地址、协议、端口和流量方向等参数提供更细粒度的过滤。
Application ID（应用 ID）：当 UPF 具备所需的应用检测能力时，可用于应用层流量识别。
QFI（QoS Flow Identifier，QoS 流标识符）：标识与数据包关联的 QoS Flow。
Source Interface Type（源接口类型）：提供与源端相关的 3GPP 接口附加信息，例如 N3、N6 或 N9。
当 PDI 中存在多个匹配参数时，这些参数共同定义数据包检测条件。只有入站数据包满足适用条件，PDR 才被视为匹配。这样，SMF 既可以创建宽泛的会话级分类规则，也可以实现更具体的业务流检测。
SDF Filter 能把流量检测细化到什么程度？
Source Interface、F-TEID 和 UE IP Address 可能足以识别一个会话或较宽泛的流量类别，但并不总能区分单独的业务数据流。 SDF Filter 可以提供更细粒度的分类。其 Flow Description（流描述） 可以包含源 IP 地址、目标 IP 地址、协议号、源端口、目标端口和流量方向。这些字段使 UPF 能够区分具体的 IP 流，而不是把与某个 UE 关联的所有数据包都采用相同方式处理。
SDF Filter 还可以携带其他匹配信息：
TOS / Traffic Class（服务类型/流量类别）：匹配 IPv4 的 Type of Service 字段或 IPv6 的 Traffic Class 字段。
Security Parameter Index（SPI，安全参数索引）：可用于匹配与 IPsec Security Association 关联的流量。
Flow Label（流标签）：匹配 IPv6 头中的 Flow Label。
SDF Filter ID：用于管理和引用时标识关联的 SDF Filter。
这形成了分层分类模型。接口、隧道和 UE 地址等 PDI 参数可以先把流量范围缩小到特定上下文，然后由 SDF Filter 在该上下文中识别单独的 IP 流。如果还支持应用识别，UPF 还可以增加应用层分类机制，而不仅依赖地址和端口。
上行 PDR 与下行 PDR 有什么区别？
对比上行和下行流量，是理解 PDR 工作方式最直观的方法之一。两个方向使用相同的总体规则结构，但数据包从不同接口进入 UPF，因此需要不同的检测条件。
对于典型上行流量，数据包从无线接入侧进入 UPF，因此 PDI 可以使用 Source Interface = Access。此外，该规则还可以使用 Local F-TEID 标识 GTP-U 隧道，并使用 UE IP Address 标识 UE 流量。一个典型的上行 PDR 因此可能要求：
Source Interface 为 Access；
入站 GTP-U 数据包匹配指定的 F-TEID，包括相关 TEID 和地址信息；
UE IP 地址与该会话关联的地址一致。
当这些条件满足时，PDR 即匹配。由于通过 N3 接收的流量通常封装在 GTP-U 中， Outer Header Removal 可以指示 UPF 在按关联 FAR 处理数据包之前，删除 GTP-U/UDP/IP 外层头。
下行检测从相反方向开始。数据包通常从数据网络侧进入 UPF，因此 PDI 可以使用 Source Interface = Core。在这种情况下， Network Instance 和 UE IP Address 等参数可用于确定数据包属于哪个 PDU Session。一个典型的下行 PDR 因此可能要求：
Source Interface 为 Core；
Network Instance 与所需的逻辑网络匹配，例如“internet”或“ims”；
数据包目标地址与该会话关联的 UE IP 地址一致。
下行 PDR 匹配后，关联 FAR 决定数据包应如何向接入侧转发，包括所需的隧道转发行为。因此，上行和下行 PDR 的差别，本质上反映了数据包进入 UPF 的方向以及可用于识别它们的信息不同。
PDR、FAR、QER 和 URR 如何协同工作？
PDR 解决的是数据包识别问题，但它并不代表完整的用户面处理策略。PFCP 把数据包检测、转发、QoS 执行和用量统计划分为不同规则类型。这样的分离使每类规则能够承担明确功能，同时仍在同一个 PFCP 会话内协同工作。
PDR：这是什么流量？（检测与分类）
FAR：应如何处理以及转发到哪里？（转发动作）
QER：应应用什么 QoS 处理？（QoS 执行）
URR：应如何统计和上报其使用量？（用量上报）
以一个匹配 PDR 的上行数据包为例。UPF 确定该数据包属于哪个 UE 和业务流之后，可以删除所需的 GTP-U 外层头，应用 FAR 引用的转发行为，执行适用的 QER，并根据关联 URR 进行流量统计。因此，数据包检测结果为后续所有操作提供了必要上下文。
从工程角度看，PDR 不应被视为一条孤立的转发策略。它是进入 PFCP 用户面规则集的入口。当理解了 PDR 用于分类、PDI 用于定义匹配条件、FAR/QER/URR 用于后续处理 之间的关系后，Source Interface、F-TEID、UE IP Address 和 SDF Filter 等参数在实际 N4 信令和数据包分析中就更容易理解。
FAQ
UPF 在 PFCP 会话内评估 PDR 时会使用 Precedence。但如果两条规则的 PDI 条件完全互斥，那么两个 PDR 不可能同时匹配同一个数据包，因此它们之间的相对优先级不会改变最终匹配结果。只有当规则条件存在重叠、同一流量可能匹配多个 PDR 时，Precedence 才尤其重要。
如果作为 PDI 匹配条件使用的 UE 地址发生变化，与该地址关联的规则也必须反映更新后的会话信息。SMF 可以通过 PFCP Session Modification 更新相关 PDR 信息，使 UPF 能够继续正确分类 UE 流量。
可以。SDF 过滤并不要求使用所有可能字段把流量限制到某一个端口。根据规则定义，可以使用端口范围或限制较少的匹配条件来覆盖更广泛的流量。当适用的过滤定义需要匹配一段地址范围时，也可以使用地址掩码。
如果入站数据包无法关联到适用的 PDR，那么在相关上下文中，UPF 就没有可用于该流量的数据包处理匹配规则。最终如何处理取决于适用的 PFCP 规则、UPF 实现以及会话配置。在故障排查中，如果流量已经到达 UPF 但未按预期转发，异常的 PDR 不匹配是一个重要检查点。
PFCP 支持已经预配置在 UP 功能中的预定义规则，并可在需要时激活。对于适用场景，控制面无需反复下发每一项规则参数，而可以直接激活相应的预定义规则。当同一组规则在多个合适会话中重复使用时，这种方式可以减少所需的信令量。
