在故障排除 5G 核心網路使用者平面問題時，經常會遇到一種情況：UE 註冊正常，PDU Session 已建立，PDR 能正確識別流量，FAR 也按預期路徑轉發封包，但 SMF 側看到的使用量計數器卻始終沒有變化。計費事件可能沒有被觸發，配額控制也可能沒有在預期時機回應。很多時候，封包轉發本身完全正常，真正缺少的是一種機制，用來告訴 UPF 應該如何測量使用者平面使用量，以及何時把測量結果報告給控制平面。這個機制就是 N4 介面上的 URR（Usage Reporting Rule，使用量報告規則）。

URR 不負責決定封包應該轉發到哪裡，也不會直接執行頻寬限制。它告訴 UPF：哪些已匹配的流量需要測量、這些使用量應該如何測量，以及在什麼條件下應將測量結果報告給控制平面。 因此，URR 讓使用者平面流量不再只是被轉發，還可以被計量。實際測量由 UPF 執行，SMF 透過 PFCP 下達報告條件，產生的 Usage Report 則在使用者平面與控制平面之間形成持續的回饋閉環。

URR 在 N4 規則框架中解決什麼問題？

理解 URR 最直接的方法，是把它的職責與 PDR、FAR 和 QER 區分開來。UPF 收到封包後，PDR 首先判斷該封包屬於哪類流量；完成分類後，FAR 決定封包應如何處理以及轉發到哪裡；QER 則應用所需的 QoS 處理。URR 回答的是另一個問題：這些流量實際已經使用了多少？

PFCP 中主要的規則類型可以概括為：

PDR：這是什麼流量？
FAR：封包應該如何處理，並轉發到哪裡？
QER：這類流量應該應用什麼 QoS 處理？
URR：這些流量已經使用了多少，以及何時應該報告這些使用量？

URR 需要與相關 PDR 建立關聯。原因很直接：如果 UPF 還不知道哪些封包屬於某個 UE、服務或流量流，就無法有意義地測量“使用者已經使用了多少”。當 PDR 識別出目標流量後，與之關聯的 URR 才能對這些匹配封包的使用量進行測量。如果一個 PDU Session 中包含多個 PDR，也可以使用不同 URR 建立更細粒度的使用量測量關係。

因此，故障排除 URR 問題時，第一個問題通常不應該是“URR 是否已經下達？”，而應該是：“當前被測流量由哪個 PDR 匹配？該 PDR 引用了哪個 URR ID？” 如果這個關聯缺失或錯誤，後續的測量與報告階段就無法按預期工作。

URR 如何定義 UPF 要測量的內容？

URR 不只是一個簡單的流量計數器。Create URR 中最先定義的要素之一是 Measurement Method（測量方法），它告訴 UPF 應該測量哪一種“使用量”。根據服務需求，測量可以基於流量、時間或事件。

對於常見封包資料服務，基於流量的測量通常最容易觀察。UPF 可以測量上行、下行以及總流量，Volume Measurement 中的相關欄位則用於指明包含哪些統計項。流量按位元組累加，因此 URR 可以統計總使用量，也可以根據設定區分 UL 和 DL 流量。

如果啟用了所需能力，測量還可以包含封包數量。例如，Measurement Information 中的 MNOP 旗標可以要求 UPF 測量上行、下行以及總封包數。這樣，營運人員看到的不僅是傳輸了多少位元組，還可以看到在測量週期內處理了多少個封包。

基於時間的測量關注服務持續時間。根據設定，它可以涉及 Time Threshold、Time Quota、Inactivity Detection Time 以及適用的時間測量機制等參數。基於事件的測量則可以統計特定服務事件，並在事件數量達到指定值時進行報告。

因此，Measurement Method 回答了 URR 最基礎的問題：對於這條規則而言，“使用量”究竟指什麼？ 如果不先明確這一點，在分析 PFCP 訊息時就很容易混淆 Threshold、Quota 和 Reporting Trigger。所選擇的測量方法會直接影響 UPF 維護的計數器類型、Usage Report 的格式，以及 SMF 對結果的解釋方式。

Reporting Trigger 決定 UPF 何時必須傳送報告

只有測量方法還不夠。如果 UPF 只是不斷累加計數器，卻沒有任何報告條件，那麼 SMF 就沒有一個明確的時點來接收結果。因此，Reporting Trigger（報告觸發條件） 也是 URR 機制的核心組成部分。

這些觸發條件可以根據網路策略組合使用。PERIO 可用於週期性報告；VOLTH 表示達到流量閾值時應產生報告；TIMTH 對應時間閾值；當 UPF 檢測到流量開始或停止時，START 和 STOPT 可以觸發 Usage Report。

另一組觸發條件與配額控制關係更緊密。VOLQU 與流量配額條件相關，TIMQU 與時間配額條件相關，EVEQU 與事件配額條件相關。當已經授予配額，但使用者在指定時間內沒有產生使用者平面流量時，還可以使用 Quota Holding Time。

尤其需要區分 Threshold（閾值） 和 Quota（配額），因為它們在 PFCP 中承擔不同作用，在追蹤分析時也經常被混淆：

Threshold 主要關注的是何時應該報告測量結果，而 Quota 更接近於還剩多少資源可以使用。如果 PFCP 追蹤中只看到設定了 VOLTH 或 VOLQU，但工程師沒有繼續檢查對應的 Threshold 或 Quota 參數，就很容易誤判實際服務邏輯。

例如，如果設定了 VOLTH，但沒有正確定義對應的 Volume Threshold，那麼 UPF 就沒有一個有意義的流量邊界來觸發預期報告。

UPF 如何把使用量結果傳送給 SMF？

URR 機制透過 PFCP Session Report 流程形成完整回饋閉環。一旦滿足 URR 定義的報告條件，UPF 不一定需要等待 SMF 主動查詢計數器，而可以直接向 SMF 傳送 PFCP Session Report Request。

當 Report Type 表明訊息中包含 Usage Report 時，SMF 可以識別這是一個使用者使用量報告事件。分析時有幾個欄位尤其重要：URR ID 用於標識是哪條規則產生了報告；UR-SEQN 標識該 URR 的 Usage Report 序號；Usage Report Trigger 則說明產生報告的原因。

實際測量值會出現在與 Measurement Method 相對應的欄位中。對於基於流量的測量，Volume Measurement 可以包含總量、上行和下行使用量；對於基於時間的測量，Duration Measurement 更為重要。Start Time、End Time、Time of First Packet 和 Time of Last Packet 等欄位也可以幫助確定報告覆蓋的準確測量區間。

收到 Usage Report 並不一定意味著流程結束。根據服務邏輯，SMF 還可以繼續傳送 PFCP Session Modification 來更新 URR，例如修改報告閾值、分配新的配額，或調整下一次報告的觸發條件。

完整的 URR 工作流程可以概括為：

SMF 下達 URR → UPF 測量匹配流量 → 滿足 Reporting Trigger 條件 → UPF 傳送 Usage Report → SMF 處理使用量結果 → 如有需要則更新 URR。

因此，使用量報告並不只是 UPF 上傳一個計數器值，而是一個動態過程：控制平面定義測量策略，使用者平面執行測量，結果持續回饋給控制平面。任何一個階段出現問題，都可能導致使用量數值不準確或報告缺失。

Volume Threshold 如何觸發實際的 Usage Report？

把 URR 放到具體流量場景中會更容易理解。假設 SMF 在 PFCP Session Establishment 過程中創建一條 URR，並指示 UPF 對某個指定 PDR 匹配到的流量採用基於流量的測量，同時啟用 VOLTH 作為 Reporting Trigger。

如果 Volume Threshold 設定為 TOVOL，取值為 10240 位元組，這條規則並不是說使用者最多只能使用 10240 位元組，而是表示：當測得的上行與下行總流量達到該閾值時，UPF 應產生 Usage Report。

隨著 UE 開始產生流量，UPF 會繼續正常轉發封包，同時累加 URR 定義的使用量計數器。當累計流量達到報告閾值後，UPF 傳送 PFCP Session Report Request。Usage Report 會把 VOLTH 標記為觸發原因，而 Volume Measurement 則包含實際總使用量以及相應的上行、下行數值。

最終報告值並不一定恰好停在 10240 位元組。UPF 是在處理真實封包的過程中判斷閾值，一個完整封包可能會讓累計使用量從閾值以下直接躍升到閾值以上。因此，Usage Report 中的數值略高於設定的 Threshold 並不矛盾。

由此可以得到分析 URR 行為時的一條重要原則：Threshold 是報告邊界，而不是把測量值截斷到某個精確數字的機制。 如果同時設定了 Quota，配額耗盡可能會觸發額外的控制行為，但應把它作為獨立的控制路徑分析，而不要與簡單的閾值觸發報告混為一談。

URR 故障排除應按四層展開：關聯、測量、觸發與報告

URR 問題往往不容易被發現，因為使用者平面服務本身可能看起來完全正常。UE 可以訪問網路，PDR 匹配正確，FAR 也持續轉發封包，但後端看到的使用量計數器仍然錯誤，可能沒有產生 Usage Report，或者達到閾值後預期的控制平面事件始終沒有發生。

因此，故障排除 URR 時不應從“使用者能否訪問網路？”開始，而應沿著完整的使用量測量鏈逐層檢查。

首先確認 PDR 與 URR 的關聯

先找出實際匹配當前流量的 PDR，再確認與之關聯的 URR ID。一個 PFCP Session 可能包含多個 PDR 和多個 URR。即使某條 URR 的所有參數看起來都正確，如果分析的是錯誤的 URR，也無法解釋當前的使用量結果。

一種典型問題是 PDR 的匹配條件已經發生變化，但 URR 仍然與之前的 PDR ID 關聯。此時，測量目標本身已經偏離了實際流量。

然後核對 Measurement Method 和方向

檢查 URR 設定的是 Volume、Duration 還是 Event 測量。如果使用基於流量的測量，還要確認規則測量的是 Total、UL、DL，還是同時包含封包計數。

當上行和下行統計與預期不一致時，這一步尤其重要。有些看似故障的情況，只是因為 URR 只測量一個方向，而測試流量實際走的是另一個方向，因此預期計數器一直沒有變化。

檢查 Reporting Trigger 及其對應 Threshold

如果 UPF 沒有產生報告，應確認控制平面實際請求了哪一種觸發條件。設定了 VOLTH 卻沒有合適的 Volume Threshold，或者在沒有啟用 PERIO 的情況下期待週期性報告，都會導致實際結果與預期服務行為不同。

同樣，基於時間的報告也應結合相關時間測量參數和監控條件一起解釋，而不能只孤立查看某一個觸發旗標。

最後追蹤 PFCP Session Report

觸發條件滿足後，確認 UPF 是否傳送了預期的 Usage Report。需要結合當前 PFCP Session 檢查 Report Type、URR ID、UR-SEQN 和 Usage Report Trigger。

如果 UPF 已經產生報告，但沒有出現新的配額、閾值或後續控制動作，故障排除重點就應該轉向 SMF 以及後續控制平面邏輯，而不是繼續停留在 UPF 計數器上。

如果問題涉及 QoS 執行前或執行後的測量，還需要檢查 Measurement Information 和 Usage Information 中的相關旗標。URR 並不是一個孤立的數字。測量時間窗口、被測流量以及執行測量時所處的處理階段都會影響最終使用量數值應如何解釋。

很多“使用量對不上”的案例，並不是 UPF 計數器本身錯誤，而是實際測量範圍與預期計費範圍之間不一致。

URR 把使用者平面流量轉化為控制平面可計量的資訊

PDR、FAR 和 QER 主要描述封包在 UPF 內如何被識別、轉發並接受 QoS 處理。URR 增加了另一項關鍵能力：讓控制平面能夠知道使用者平面流量實際已經消耗了多少。

URR 使用 Measurement Method 定義測量範圍，使用 Reporting Trigger 決定何時需要報告，並透過 Threshold、Quota、Monitoring Time 等參數控制使用量測量的不同階段。滿足所需條件後，UPF 會透過 PFCP Usage Report 把結果傳送回 SMF，之後控制平面可以在需要時更新 URR 或執行其他策略動作。

因此，理解 URR 最實用的方法不是記住幾十個 Information Element，而是沿著一條完整鏈路理解：

PDR 選擇要測量的流量 → URR 定義測量方法 → UPF 持續測量使用量 → Reporting Trigger 決定何時報告 → Usage Report 把結果返回 SMF → SMF 按需更新控制策略。

當這條鏈路明確後，Volume Threshold、Volume Quota、Measurement Period、Monitoring Time 以及各種 Reporting Trigger 就不再是彼此孤立的 PFCP 欄位，而是同一套 5G 使用量測量與報告機制中的不同控制點。

對於需要按使用量計費、實時配額管理，或根據使用情況動態調整策略的服務，這套機制提供了基礎，使 5G 使用者平面不僅能夠轉發流量，還能做到可測量、可控制。

常見問題