内容

概要

前提条件

要件

使用するコンポーネント

背景説明

CUPS環境との関連性

ラボでのデモンストレーション

概要

このドキュメントでは、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のフローは次のとおりです。

1. レーティンググループのクォータが不足すると、VPPはsessmgr-Uに通知し、sessmgr-UはVPPから使用状況を照会します。ここにわずかな遅れがある。

2. この間、VPPはトラフィックをドロップしません。

3. 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は新しいクォータを要求します。