當 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 功能中的預定義規則，並可在需要時激活。對于適用場景，控制面無需反復下發每一項規則参數，而可以直接激活相應的預定義規則。當同一組規則在多個合適會话中重復使用時，這種方式可以減少所需的信令量。
