概要
このドキュメントでは、Gyがクォータ管理に使用されるプリペイドサブスクライバのコントロールプレーン(CUPS)およびユーザプレーン(CUPS UP)での動作について説明します。
前提条件
要件
次の項目に関する知識があることが推奨されます CUPSアーキテクチャ。
使用するコンポーネント
このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
背景説明
この設定オプションは、credit-control-groupに存在します。
credit-control-group xxx
pending-traffic-treatment quota-exhausted drop
レガシーPGW/SAEGWでは、この設定により、その評価グループのトラフィックがドロップされます。
- クォータ許可が消費され、新しいクォータ要求が進行中の場合。
- または、OCSサーバから最後のCCAでクォータが完全に消費されるため（Final-Unit-Indication属性がFinal-Unit-Actionとともに存在するため）。
CUPS環境との関連性
CUPS環境では、状況が少し異なります。UPのフローは次のとおりです。
- レーティンググループのクォータが不足すると、VPPはsessmgr-Uに通知し、sessmgr-UはVPPから使用状況を照会します。ここにわずかな遅れがある。
- この間、VPPはトラフィックをドロップしません。
- Sessmgr-Uは、次のタイプの要求をレポートするセッションを送信します。使用状況レポート。次の情報が含まれています。
- 使用状況レポートトリガー：ボリュームクォータ
- 体積測定：合計ボリューム/アップリンクボリューム/ダウンリンクボリューム
注：ボリュームが許可されたクォータを超えている可能性があります。これは、vpp通知とsessmgr-Uがボリューム統計情報を取得するまでの遅延が原因です。
4.新しいクォータを受信すると、UPのトラフィック数が再開されます（新しいクォータが要求されている間に既に送信されたデータを考慮に入れます）。
5.クォータの更新ごとに同じイベントのサイクルが発生します。
6.最後のクォータ許可を受信すると、次の処理が行われます。
- CPでは、CCA-UがFinal-Unit-Indication（およびFinal-Unit-Action）とともに受信されます。
- CPは、残りのクォータを含むUPへのセッション変更要求を、アクションDROPを持つ新しく作成されたFARとともにトリガーします（「pending-traffic-treatment quota-exhausted drop」設定により）
- これは、最終的なクォータを消費したときにトラフィックがドロップされることをUPに示します。
ラボでのデモンストレーション
このラボテストでは、この動作について詳細に説明します。
OCS設定：
- 合計クォータ： 5000000
- クォータの許可： 500000
- クォータしきい値： 0
高速ダウンロードテスト。
セッション全体を通じて、SXセッションレポート要求の500000オクテットのクォータ許可よりも常に高い使用率がUPから報告されます。これは、高速ダウンロードと、クォータが枯渇したときに更新されたボリューム統計を取得するためのfastpath/sessmgr間の遅延が組み合わされているためです。この時間のスループットが高いほど、この差は大きくなります。
SEID: 0x0004000000000000, Message type: SX_SESSION_REPORT_REQUEST (0x38)
VOLUME MEASUREMENT:
Total Volume: 792288
Uplink Volume: 155652
Downlink Volume: 636636
SEID: 0x0004000000000000, Message type: SX_SESSION_REPORT_REQUEST (0x38)
VOLUME MEASUREMENT:
Total Volume: 533220
Uplink Volume: 143376
Downlink Volume: 389844
SEID: 0x0004000000000000, Message type: SX_SESSION_REPORT_REQUEST (0x38)
VOLUME MEASUREMENT:
Total Volume: 682584
Uplink Volume: 332724
Downlink Volume: 349860
SEID: 0x0004000000000000, Message type: SX_SESSION_REPORT_REQUEST (0x38)
VOLUME MEASUREMENT:
Total Volume: 514380
Uplink Volume: 247620
Downlink Volume: 266760
SEID: 0x0004000000000000, Message type: SX_SESSION_REPORT_REQUEST (0x38)
VOLUME MEASUREMENT:
Total Volume: 519792
Uplink Volume: 209916
Downlink Volume: 309876
SEID: 0x0004000000000000, Message type: SX_SESSION_REPORT_REQUEST (0x38)
VOLUME MEASUREMENT:
Total Volume: 539508
Uplink Volume: 249624
Downlink Volume: 289884
SEID: 0x0004000000000000, Message type: SX_SESSION_REPORT_REQUEST (0x38)
VOLUME MEASUREMENT:
Total Volume: 690876
Uplink Volume: 341292
Downlink Volume: 349584
SEID: 0x0004000000000000, Message type: SX_SESSION_REPORT_REQUEST (0x38)
VOLUME MEASUREMENT:
Total Volume: 586632
Uplink Volume: 286176
Downlink Volume: 300456
OCSからの最終認可：
SEID: 0x0018000000000003, Message type: SX_SESSION_MODIFICATION_REQUEST (0x34)
Total Volume: 140720
Uplink Volume: 70360
Downlink Volume: 70360
SEID: 0x0004000000000000, Message type: SX_SESSION_REPORT_REQUEST (0x38)
VOLUME MEASUREMENT:
Total Volume: 141372
Uplink Volume: 75684
Downlink Volume: 65688
その後、次のコマンドでUPで確認できるように、UP上のすべてのトラフィックが（CCがドロップされたように）ドロップされます。
[local]saegw-up1# show subs user-plane-only full all
CC Dropped Uplink Pkts: 2583 CC Dropped Downlink Pkts: 2551
CC Dropped Uplink bytes: 3687672 CC Dropped Downlink Bytes: 3642828
しかし、最終的な使用状況レポートのボリューム測定値がUPから認可を超えないのはなぜですか。
CPは、最後のクォータ許可で、アクションをdropに設定した新しいFARを作成し、これがURRにバインドされます。これは、最後の認可が消費された直後にトラフィックをドロップするようにVPPに指示します。
Wednesday March 10 2021
<<<<OUTBOUND 01:29:16:551 Eventid:221302(3)
[C-PLANE]PFCP Tx PDU, from 10.1.50.1:50007 to 10.1.50.3:8805 (163)
SEID: 0x0018000000000002, Message type: SX_SESSION_MODIFICATION_REQUEST (0x34)
Sequence Number: 0x00150B (5387)
…
INFORMATION ELEMENTS
CREATE FAR:
Type: 3
Value:
FAR ID:
Type: 108
Value: 0x0005
APPLY ACTION:
Type: 44
Value:
DROP: 1
FORW: 0
BUFF: 0
NOCP: 0
DUPL: 0
UPDATE URR:
Type: 13
Value:
URR ID:
Type: 81
Value: 0x80000027
MEASUREMENT METHOD:
Type: 62
Event: 0
Volume: 1
Duration: 1
REPORTING TRIGGERS:
Type: 37
Volume Quota: 1
Time Quota: 1
Envelope Closure: 0
Periodic Reporting: 0
Volume Threshold: 0
Time Threshold: 0
Quota Holding Time: 0
Start of Traffic: 0
Stop of Traffic: 0
Dropped DL Traffic Threshold: 0
Linked Usage Reporting: 0
VOLUME QUOTA:
Type: 73
Total Volume: 140720
Uplink Volume: 70360
Downlink Volume: 70360
TIME QUOTA:
Type: 74
Value: 1000
FAR ID:
Type: 108
Value: 0x0005
注：CUPS UPでのこの動作は、CPで見られるようなクォータの過剰消費を引き起こしません。
CP# show active-charging session full
…
Rating-Group: 100
Service-Identifier: 0
State: Final Unit
Checkpoint State: Current
Pending Update: No
Last Answer: 0h00m49s
Final-Unit-Action: Terminate
Quota Usage Total Usage
------------------ ------------- ------------- -------------
CC-Time: - 0 10
CC-Total-Octets: - 0 5000652
CC-Input-Octets: - 0 2042064
CC-Output-Octets: - 0 2958588
注：この動作は、OCSで見積もりしきい値が0に設定されているために明確に表示されます。ゼロ以外のクォータのしきい値が設定されている場合、しきい値に達すると（フルクォータの認可が消費される前に）、UPは新しいクォータを要求します。
フィードバック