一個常見的 5G 使用者平面故障場景起初很容易讓人困惑：PDU Session 已成功建立，UE 獲得了 IP 位址，PDR 正確匹配預期流量，FAR 中也包含 FORW，封包甚至已經開始傳輸。但使用者仍然遇到視訊緩衝、下載速率異常偏低，或者只有單向流量能夠正常工作的情況。
出現這種情況時，僅檢查 PDR 和 FAR 可能仍然找不到原因。問題可能並不在於 流量是否被正確識別 或 封包被轉送到了哪裡，而是在於 允許轉送之後，UPF 對這部分流量套用了哪一種 QoS 策略。在 N4 介面的 PFCP 規則體系中， QER（QoS Enforcement Rule，QoS 執行規則） 負責在 UPF 中實施這些 QoS 策略。它可以控制流量是否允許通過、限制上行或下行速率、把流量關聯到某個 QoS Flow，並套用傳輸層標記。因此，要理解完整的使用者平面行為，需要把 PDR、FAR 和 QER 一起分析。
為什麼 PDR 和 FAR 已經正常工作後仍然需要 QER？
理解 QER 最簡單的方法，是把 UPF 中不同規則的職責分開來看。
PDR 首先回答“這是什麼流量？”它通過 PDI、UE IP 位址、F-TEID、SDF Filter 等條件檢測並分類封包。流量識別完成後，FAR 回答下一個問題：“這個封包接下來應該怎麼處理，又應該轉送到哪裡？”
但允許一個封包轉送，並不意味著它可以不受任何限制地傳輸。如果網路仍然需要控制速率、Gate 狀態、QoS Flow 關聯或傳輸層標記，UPF 就必須套用關聯的 QER。
因此，一個典型的處理順序可以簡化為：
PDR 識別流量 → FAR 決定轉送動作 → QER 執行 QoS 策略。
這些規則不是互相替代，而是協同運作。封包可以正確匹配 PDR，也可以被 FAR 允許轉送，但仍然受到 QER 所定義的速率限制或 Gate 條件約束。沒有 QER，UPF 可能知道封包應該被轉送，卻缺少描述這些流量從 QoS 角度應如何處理的相同策略資訊。
QER 在什麼時候安裝？為什麼後續還可能被更新？
在 PDU Session 的 PFCP Session Establishment 過程中，QER 通常由 SMF 作為使用者平面規則的一部分下達至 UPF。它並不是 UPF 在觀察到流量之後自行建立的一條 QoS 規則。控制面決定應執行什麼 QoS 行為，而 UPF 負責執行最終下達的規則。
QER 並不一定在整個 Session 生命週期內保持不變。如果服務運作期間策略發生變化，SMF 可以透過 PFCP Session Modification 更新現有 QER。因此，訂閱策略、應用程式策略或其他控制面決策的變化，都可能帶來新的速率限制、不同的 Gate 狀態、改變 QoS Flow 關聯或其他 QoS 參數。
因此，故障排查不能只停留在最初的 Create QER。如果 QoS 問題是在 Session 運作一段時間後才出現，還應繼續檢查後續的 Update QER 資訊，並與初始參數進行比較。
從控制面角度看，SMF 使用的 QoS 策略可能來自本機設定，也可能來自與 PCF 相關的策略資訊。當策略到達 N4 介面時，會被表示為 UPF 可以執行的 PFCP 規則。根據服務設計，QoS 執行可以作用於 PDU Session 層級、QoS Flow 層級，也可以針對更具體的 SDF 或應用程式流量。
為什麼會話看起來正常時 Gate Status 仍然可能阻斷流量？
Gate Status 是 QER 中最直接的參數之一，因為它可以立即改變流量是否允許通過。
上行和下行 Gate 狀態可以分別控制。Gate 為 OPEN 時，對應方向的流量可以繼續通過；Gate 為 CLOSED 時，對應方向的流量會被 QoS 執行規則阻斷。
因此，一個典型的排查過程可能是：
PDU Session 已成功建立；
UE 已獲得 IP 位址；
PDR 匹配正確；
FAR 中包含 FORW；
但應用程式流量仍然無法正常工作。
此時應檢查關聯 QER 中的 UL Gate 和 DL Gate。因為兩個方向分別控制，所以可能出現一個 Gate 為 OPEN、另一個為 CLOSED 的情況。最終症狀可能表現為單向使用者平面故障：UE 可以接收下行流量，卻無法成功發送上行流量，或者相反。
這就是為什麼 QER 是一條執行規則，而不僅僅是描述性的 QoS 屬性。它的參數可以直接決定某類流量是否允許繼續通過 UPF。
MBR、GBR 和 Packet Rate 分別控制什麼？
Gate Status 回答的是“流量能不能通過？”與速率相關的參數回答的是另一個問題：“允許通過多少流量，以什麼速率通過？”QER 可以同時根據位元率和封包速率執行限制。
最大位元率（MBR）
MBR 定義匹配流量的最大位元率，並且可以分別設定上行和下行方向。在 5GC 環境中，根據規則設計，具體限制可以對應 Session 層級限制、某個特定 QoS Flow，或者更具體的服務流。
如果使用者可以正常存取服務，但吞吐量總是穩定停在一個可重複出現的上限附近，那麼關聯 QER 中的 MBR 就是值得檢查的參數之一。
MBR 很容易與無線端容量混淆。無線條件良好、傳輸頻寬充足，並不保證應用程式可以使用全部實體容量。如果 UPF 被要求執行更低的 MBR，使用者平面吞吐量就會持續受這一限制約束。因此，排查低吞吐量時還應檢查 N4 上的 QoS 規則，而不能只關注無線效能。
保證位元率（GBR）
GBR 描述需要一定資源保障的流量所對應的保證位元率，也可以分別針對上行和下行方向指定。
GBR 可能用於需要更可預測效能的服務，例如某些即時語音、視訊或其他對 QoS 敏感的應用程式。它不應被視為一個孤立數字，還需要結合對應的 QoS Flow 和整體 QoS 策略一起理解。
從概念上看，MBR 定義允許速率的上限，而 GBR 描述服務策略中所要求的保證速率。
封包速率（Packet Rate）
有些流量僅用位元率並不能準確描述。QER 還可以包含 Packet Rate 參數，用於限制指定時間區間內允許通過的封包數量。
這對會產生大量小封包的服務尤其重要，例如 DNS 交易、IoT keepalive 或類似信令的流量。它們的總位元率可能仍然較低，但每秒封包數卻很高。在這種情況下，只檢查 MBR 可能無法解釋觀察到的 QoS 行為。
當觸發封包速率限制後，即使整體頻寬佔用看起來不高，使用者也可能遇到更高延遲、回應變慢或請求失敗。
QFI、Flow Level Marking 和 PPI 在 QER 中分別起什麼作用？
QER 不只是一個限速器。除了 Gate Status、MBR 和 GBR，它還可以攜帶與 QoS Flow 識別和封包處理相關的參數。這些參數共同決定使用者平面中的流量如何被處理。
QoS Flow 識別碼（QFI）
QFI 用於識別一個 QoS Flow。一個 PDU Session 可以包含多個 QoS Flow，從而讓不同服務流量接受不同的 QoS 處理。
從使用者平面角度看，QFI 表示某個封包關聯的是哪一個 QoS Flow。在 QER 中，這個識別碼可用於把相應的 QoS 執行行為與對應的 QoS Flow 關聯起來。
如果規則中的 QFI 與預期的服務設計不一致，即使速率參數本身看起來正確，流量也可能被關聯到錯誤的 QoS Flow，從而獲得與原設計不同的資源處理方式。
DL Flow Level Marking
QER 可以要求 UPF 對下行流量套用流量層級標記，例如為 IP 傳輸網路設定某個 DSCP 值。
這種標記並不決定封包屬於哪個 5G QoS Flow。它影響的是封包進入 IP 傳輸網路之後，如何被識別和處理。
如果傳輸層標記不正確，5G QoS 本身可能設定正確，但下游傳輸網路仍可能以錯誤的優先級處理該封包。
Paging Policy Indicator（PPI）
PPI 與下行流量的 Paging 策略處理相關。在適用的轉送場景中，QER 可以提供與 Paging 策略有關的資訊，從而讓涉及 Paging 行為時的不同流量得到差異化處理。
對於目前不處於活動使用者平面狀態的 UE，不同類型的下行流量可能具有不同的 Paging 影響。PPI 提供的資訊可以作為這種差異化處理的一部分。
Averaging Window
速率執行不能總是只根據某一個封包的瞬時狀態判斷。Averaging Window 定義的是評估位元率相關行為時使用的時間視窗。
較短的視窗會更快回應突發流量，較長的視窗則會形成更平滑的平均值，並以不同方式容忍短時間突發。這也是為什麼分析 QER 不能只看 QER ID 和 MBR。最終 QoS 行為可能由多個參數共同決定。
如何利用 PFCP 訊息驗證 QER 是否按預期工作？
分析 QER 最有價值的方法，並不是記住每一個資訊元素，而是把 PFCP 規則與實際服務症狀對應起來。
例如，一條 Create QER 可能包含：
QER ID = 1；
UL Gate = OPEN；
DL Gate = OPEN；
UL MBR = 100000 kbps；
DL MBR = 150000 kbps。
這些數值只是示例，但說明瞭一個重要問題： Gate 為 OPEN 並不意味著不存在 QoS 限制。 流量可以被允許通過，同時仍然受到 MBR 的限制。
一個實用的排查順序可以按照以下步驟進行：
先識別 PDR。 確定到底是哪一條 PDR 匹配了受影響的流量。如果選錯 PDR，預期的 QER 就不會正確套用。
檢查 PDR 引用的 QER ID。 不要脫離上下文去檢查 PFCP Session 中的每一條 QER。先確定與當前分析流量真正關聯的是哪一條 QER。
檢查 Create QER 和 Update QER。 確認當前實際生效的規則是否在後續 PFCP Session Modification 中被修改。QoS 問題可能來自後續更新，而不是最初的會話建立。
檢查 Gate Status。 分別核對上行和下行 Gate 狀態。只有一個方向 Gate 關閉，也會造成單向服務故障。
檢查 MBR、GBR 和 Packet Rate。 把設定限制與實際吞吐量或封包行為進行比較，尤其是在服務總是停在固定速率附近時。
檢查 QFI 和其他 QoS 參數。 確認預期的 QoS Flow、標記以及與 Paging 相關的設定是否與服務設計一致。
把規則與真實使用者平面流量進行比較。 PFCP 表示 UPF 預期應該執行什麼；吞吐量測試和封包擷取則顯示實際發生了什麼。兩者之間的差異通常是最有價值的故障線索。
這種方法比單獨解讀某一個 QER 欄位更可靠。PFCP 信令告訴我們 UPF 應該執行什麼，而使用者平面測試顯示的是 實際觀察到的結果。比較這兩個觀點，是判斷 QER 是否按預期工作的關鍵。
FAQ
QER 與 FAR 最主要的區別是什麼？
FAR 主要決定匹配後的封包應該如何處理以及轉送到哪裡，包括 FORW、DROP、BUFF 等動作。QER 則執行與 QoS 相關的行為，例如 Gate 控制、速率限制、QoS Flow 關聯以及傳輸層標記。兩者通常都在 PDR 完成流量識別後發揮作用。可以簡單理解為：FAR 決定 封包要轉送到哪裡，以及如何轉送，而 QER 決定 這部分流量應套用什麼 QoS 處理。
為什麼 Gate Status 為 OPEN 時使用者吞吐量仍然可能很低？
OPEN 只表示對應方向的流量允許通過，並不會取消其他 QoS 限制。仍然需要檢查 MBR、GBR、Packet Rate 以及關聯的 QoS Flow。如果 MBR 設定低於可用的無線或傳輸容量，即使上下行 Gate 都完全開啟，吞吐量仍然會受到限制。
QER 只能在 PFCP Session Establishment 期間建立嗎？
不是。QER 可以在 PFCP Session Establishment 期間建立，之後還可以透過 PFCP Session Modification 修改。如果 Session 運作之後 QoS 行為發生變化，應檢查後續 Update QER，而不能只分析最初的 Create QER。
QFI 和 QER 是同一個概念嗎？
不是。QFI 是 QoS Flow 的識別碼，而 QER 是由 UPF 執行的一條 QoS 規則。QER 可以包含或引用 QFI 資訊，從而把特定 QoS 處理關聯到對應的 QoS Flow。QFI 識別的是 哪一個 QoS Flow ；QER 定義的是 如何對這部分流量執行 QoS 控制。
為什麼 PDR 已經匹配、FAR 也允許轉送，流量仍然可能失敗？
因為使用者平面處理並不一定在 FAR 結束。允許轉送之後，關聯的 QER 仍可能套用 Gate Status、MBR、GBR、Packet Rate 或其他 QoS 約束。因此，故障排查應把 PDR、FAR 和 QER 看作一條連續處理鏈。其中任何一個階段不匹配，都可能影響最終服務結果。
