5G Coreのユーザープレーンをトラブルシューティングしていると、よく見られる問題があります。UEは正常に登録され、PDU Sessionも確立され、PDRはトラフィックを正しく識別し、FARも想定どおりの経路へパケットを転送しているのに、SMFから見える利用量カウンターが変化しないというケースです。課金イベントが発生しなかったり、クォータ制御が期待したタイミングで動作しなかったりすることもあります。多くの場合、パケット転送そのものは正常です。不足しているのは、ユーザープレーンの利用量をどのように測定し、その結果をいつコントロールプレーンへ報告するかをUPFに指示する仕組みです。その仕組みが、N4インターフェース上のURR（Usage Reporting Rule）です。

URRはパケットの転送先を決めるルールではなく、帯域制限を直接適用するものでもありません。URRがUPFに指示するのは、一致したどのトラフィックを測定するか、その利用量をどのように測定するか、そしてどの条件で測定結果をコントロールプレーンへ報告するかです。これにより、ユーザープレーンのトラフィックは単に転送されるだけでなく、測定可能な対象になります。実際の測定はUPFが行い、SMFがPFCPを通じて報告条件を設定し、生成されるUsage Reportがユーザープレーンとコントロールプレーンの間に継続的なフィードバックループを形成します。

N4のルール体系でURRはどの問題を解決するのか？

URRを理解する最も簡単な方法は、その責務をPDR、FAR、QERの責務と分けて考えることです。UPFがパケットを受信すると、まずPDRがそのパケットがどのトラフィックに属するかを判定します。分類後、FARがパケットの処理方法と転送先を決定します。QERは必要なQoS処理を適用します。URRが答えるのは別の問い、つまりこのトラフィックは実際にどれだけ利用されたのか？です。

主なPFCPルールの役割は、次のように整理できます。

PDR：これはどのトラフィックか？
FAR：パケットをどのように処理し、どこへ転送するか？
QER：このトラフィックにどのQoS処理を適用するか？
URR：このトラフィックはどれだけ利用され、いつその利用量を報告するか？

URRは対象となるPDRに関連付ける必要があります。理由は明確です。どのパケットがそのUE、サービス、またはトラフィックフローに属するかが分からなければ、UPFは「ユーザーがどれだけ利用したか」を意味のある形で測定できません。PDRがトラフィックを識別すると、それに関連付けられたURRが一致したパケットの利用量を測定できます。1つの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は時間しきい値に対応します。STARTとSTOPTは、UPFがトラフィックの開始または停止を検出したときに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を作成し、特定のPDRに一致するトラフィックをボリュームベースで測定するようUPFへ指示するとします。また、Reporting TriggerとしてVOLTHを有効にします。

Volume ThresholdでTOVOLを指定し、値を10240バイトに設定した場合、このルールはユーザーが10240バイトまでしか利用できないという意味ではありません。意味するのは、測定したアップリンクとダウンリンクの総ボリュームがこのしきい値に達したら、UPFはUsage Reportを生成するということです。

UEがトラフィックを生成し始めると、UPFは通常どおりパケットを転送しながら、URRで定義された利用量カウンターも累積します。累積ボリュームが報告しきい値に達すると、UPFはPFCP Session Report Requestを送信します。Usage ReportではVOLTHがトリガー理由として示され、Volume Measurementには実際の総利用量と該当するアップリンク・ダウンリンク値が格納されます。

最終的な報告値が必ず10240バイトで止まるとは限りません。UPFは実際のパケット処理中にしきい値を評価するため、1つの完全なパケットによって累積利用量がしきい値未満から一気にしきい値超過へ移ることがあります。そのため、Usage Reportの値が設定したThresholdよりわずかに大きくても矛盾ではありません。

ここから、URRの挙動を解析するうえで重要な原則が分かります。Thresholdは報告の境界であり、測定値を正確な数値に切り詰める仕組みではありません。 同時にQuotaが設定されている場合、クォータ枯渇によって追加の制御動作が発生する可能性がありますが、それは単純なしきい値報告とは別の制御経路として解析すべきです。

URRのトラブルシューティングは「関連付け・測定・トリガー・報告」の4層で進める

URRの問題は気付きにくいことがあります。ユーザープレーンのサービス自体は完全に正常に見えるからです。UEはネットワークへアクセスでき、PDRも正しく一致し、FARもパケットを転送し続けているのに、バックエンド側の利用量カウンターが正しくない、Usage Reportが生成されない、あるいはしきい値到達後に期待するコントロールプレーンイベントが発生しないことがあります。

そのため、URRのトラブルシューティングを「ユーザーはネットワークにアクセスできるか？」という問いから始めるべきではありません。利用量測定のチェーン全体を順に追う必要があります。

まずPDRとURRの関連付けを確認する

実際にトラフィックに一致しているPDRを特定し、それに関連付けられたURR IDを確認します。1つのPFCP Sessionに複数のPDRやURRが含まれることがあります。誤ったURRを解析している場合、そのURRのパラメーターがすべて正しく見えても、現在の利用量結果を説明できません。

典型的な問題の一つは、PDRのマッチング条件が変更されたにもかかわらず、URRが以前のPDR IDに関連付けられたままになっているケースです。この場合、測定対象そのものが実際のトラフィックから外れています。

次にMeasurement Methodと方向を確認する

URRがVolume、Duration、Eventのどの測定方式に設定されているかを確認します。ボリュームベースの場合は、Total、UL、DL、またはパケット数も測定しているかを確認します。

アップリンクとダウンリンクの統計が期待どおりでない場合、この確認は特に重要です。URRが一方向だけを測定している一方、テストトラフィックが反対方向に流れているため、期待するカウンターが変化しないだけというケースもあります。

Reporting Triggerと対応するThresholdを確認する

UPFが報告を生成しない場合は、コントロールプレーンが実際にどのトリガーを要求したかを確認します。適切なVolume ThresholdなしでVOLTHを設定した場合や、PERIOが有効でないのに周期報告を期待した場合、想定したサービス動作とは異なる結果になります。

同様に、時間ベースの報告は1つのトリガーフラグだけを切り離して見るのではなく、関連する時間測定パラメーターや監視条件と合わせて解釈する必要があります。

最後にPFCP Session Reportを追跡する

トリガー条件を満たしたら、UPFが期待するUsage Reportを送信しているか確認します。現在のPFCP Sessionと照合しながら、Report Type、URR ID、UR-SEQN、Usage Report Triggerを確認します。

UPFがすでに報告を生成しているのに、新しいクォータ、しきい値、後続の制御処理が見られない場合、UPFカウンターに注目し続けるのではなく、SMFとその後のコントロールプレーンロジックへ調査範囲を移すべきです。

QoS適用前後の測定が問題になる場合は、Measurement InformationとUsage Informationの関連フラグも確認する必要があります。URRは単なる1つの独立した数値ではありません。測定時間の範囲、測定対象のトラフィック、そして測定が行われる処理段階のすべてが、最終的な利用量値の解釈に影響します。

「利用量が合わない」ケースの多くは、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を暗記するより、1本の完全な流れを追う方が有効です。

PDRが測定対象トラフィックを選択 → URRが測定方法を定義 → UPFが継続的に利用量を測定 → Reporting Triggerが報告タイミングを決定 → Usage Reportが結果をSMFへ返す → SMFが必要に応じて制御ポリシーを更新。

この流れを理解すると、Volume Threshold、Volume Quota、Measurement Period、Monitoring Time、各種Reporting Triggerは、ばらばらのPFCPフィールドではなくなります。同じ5G利用量測定・報告メカニズムの中にある異なる制御ポイントとして理解できます。

利用量ベースの課金、リアルタイムのクォータ管理、または消費量に応じたポリシー調整が必要なサービスでは、この仕組みが基盤となり、5Gユーザープレーンをトラフィック転送だけでなく測定可能かつ制御可能にします。

よくある質問