UEが登録してPDU Sessionを確立し、パケットが正常に転送されていても、SMFに想定した使用量更新が届かないことがあります。Usage Reporting Rule（URR）を確認してください。SMFがPFCPを使ってN4経由で設定し、UPFがトラフィックを測定して設定条件に従って報告します。使用量レポートは課金、監視、ポリシー判断を支えますが、課金全体には追加の機能と手順が必要です。
PFCPルールにおけるURRの役割
Packet Detection Rule（PDR）はトラフィックを識別し、適用するルールを参照します。Forwarding Action Rule（FAR）は転送、破棄、バッファリングを指定し、QoS Enforcement Rule（QER）はQoSとゲート制御を担い、Buffering Action Rule（BAR）は関連するバッファリング指示を提供します。URRは使用量の測定と報告、および設定されている場合のクォータ動作を定義します。
一つのPDRは複数のURRを参照でき、複数のPDRでURRを共有することもできます。実際に一致するPDR、URR ID参照、意図した集約範囲を確認します。URRはPDRと関連付けられていなくても存在できますが、存在するだけでは試験トラフィックが測定されている証拠になりません。
Measurement Methodと計上範囲
Measurement Methodはデータ量、時間、イベント、または対応する組み合わせを選択します。Volume Measurementは合計、上り、下りのオクテット数を報告します。一オクテットは一バイトです。UPFが対応している場合、Measurement InformationのMNOPによってパケット数も要求できます。バイト数、パケット数、アプリケーションのペイロードサイズを混同しないでください。
時間の測定は時間計測設定に依存します。Immediate Start Time Meteringは指示を受けた時点で測定を開始でき、それ以外は最初のパケットで開始します。Inactivity Detection Timeがゼロ以外の場合、設定された無通信期間の後に時間測定を中断し、通信再開時に再開します。イベント測定には対応するイベント検出設定が必要です。
データ量の報告は通常、QoS適用後の使用量を対象とします。QoS適用前の測定も要求されている場合は、別々のUsage ReportsでUsage Informationを使って二つの範囲を区別します。しきい値はQoS適用後に適用されます。カウンターの不一致と判断する前に、方向、計上期間、処理範囲をそろえて比較してください。
報告トリガー、しきい値、クォータ
Reporting Triggersは関連パラメーターと併せて解釈します。PERIOはMeasurement Periodを使い、VOLTH、TIMTH、EVETHはデータ量、時間、イベントのしきい値、VOLQU、TIMQU、EVEQUはクォータに関係します。STARTとSTOPTは適用される検出条件の下で通信の開始と停止を報告します。Quota Holding Timeは割り当て後の無通信に関するもので、定期報告タイマーではありません。
| パラメーター | 意味と境界 |
|---|---|
| Volume Threshold | 報告の境界であり、通信の許容量や自動的なパケット停止ではありません。 |
| Volume Quota | 割り当てられた使用許容量です。使い切ると、指定されたクォータ動作に従って転送の停止や制限が必要になる場合があります。 |
| Measurement Period | 要求された定期使用量レポートの間隔です。 |
| Monitoring Time | 指定時刻の前後の使用量を分ける境界で、該当する後続のしきい値やクォータを伴います。 |
クォータ動作は通知だけではありません。TS 29.244では、設定されたクォータを使い切ると、転送を停止するか、事業者ポリシーに従って限られた通信だけを許可する場合があります。対応していて設定済みの場合、FAR ID for Quota Actionは破棄、バッファリング、リダイレクトのための代替FARを選択します。QERとFAR/BARの責任は引き続き異なります。しきい値のみのURRは帯域制限機能ではありません。
しきい値とクォータの両方を設定していても、しきい値トリガーだけを有効にした場合、クォータ枯渇時の二回目の報告を意味しません。両方のトリガーを有効にした場合、確認したRelease 18仕様では両方の境界で報告しますが、以前のリリースでは動作が異なる場合があります。実装リリース、機能、例外、ルール全体を確認してください。
Usage ReportがSMFに届く仕組み
UPFはReport TypeでUsage Reportを示すPFCP Session Report Requestを送信できます。URR ID、UR-SEQN、Usage Report Triggerを確認し、該当するVolume MeasurementまたはDuration Measurementを確認します。Start Time、End Time、パケットのタイムスタンプは期間の特定に役立ちます。STARTだけによるレポートには、ゼロ以外の使用量測定値が含まれなくても構いません。
SMFはPFCP Session Report Responseを返します。そのCauseを確認してください。正常に届いたことは、課金の成功やクォータの更新を証明しません。SMFは別途PFCP Session Modification Requestを送ってルールを更新できます。Usage Reportsは該当する手順に従ってPFCP Session Modification ResponseやPFCP Session Deletion Responseにも含まれるため、自発的な要求だけを探すと計上記録を見落とす可能性があります。
Monitoring Timeにより、同じURR IDで境界の前後を別々に報告することがあります。Usage Informationとシーケンス情報を保持し、再送と新しいレポートを区別して報告期間を照合してください。すべての値をセッション全体の累積カウンターとして扱わないでください。
例：10240バイトのデータ量しきい値
データ量測定、VOLTH、TOVOLを設定した合計Volume Threshold 10240バイトを想定します。測定した合計が境界に達するとUPFが報告します。この値は10240バイトの許容量ではありません。パケット単位の粒度により、報告値がしきい値を超える場合があります。クォータが設定されている場合は別途解析が必要です。
使用量の欠落や想定外の値を調べるトレース確認項目
PFCPセッションと実際に一致するPDRを特定し、URR参照と上り・下りPDR間の集約を確認します。
Measurement Method、測定の有効化、MNOP対応、時間計測設定、QoS適用前後の範囲を確認します。
要求した各トリガーをしきい値、クォータ、タイマーに対応付け、Monitoring Timeと後続の値を確認します。
要求と応答、Cause、URR ID、UR-SEQN、報告期間、再送を追跡し、変更と削除の応答も含めます。
報告が成功している場合、SMF処理、課金連携、更新されたクォータ、該当するQER/FARの変更を確認します。実際の転送動作は別に検証します。
よくある質問
一つのURRで両方向の通信を測定できますか？
はい。関連する上り・下りPDRは同じURRを参照できます。一つのURRが常に一方向または一サービスを表すと決めつけず、意図した集約を確認してください。
Usage Reportは顧客への請求を証明しますか？
いいえ。UPFで報告イベントが発生したことを示します。課金の対応付け、料金計算、請求結果には、対応する制御プレーンと課金システムの証拠が必要です。
すべてのURRレポートを合算すべきですか？
確認せずに合算してはいけません。レポートは異なる期間、監視境界、QoS適用前後の範囲を表す場合があり、再送で同じレポートが繰り返されることもあります。集約前に識別子と測定の文脈を照合してください。
