Diameter クレジット管理アプリケーション

Diameter クレジット制御アプリケーションは、さまざまなエンド ユーザー サービスに対してリアルタイムのクレジット制御を実装するために使用される Diameterアプリケーション用のネットワーク プロトコルです。

これは、RFC 4006 で最初に定義され、RFC 8506 で更新された IETF 標準です。

Diameter クレジット管理アプリケーションの目的は、主にゲートウェイ/制御ポイントとバックエンドのアカウント/残高システム (通常はオンライン課金システム)間の通信を目的とした、リアルタイム課金のフレームワークを提供することです。

アプリケーションでは、次のメソッドを指定します。

• 割り当て管理（予約、再承認、放棄）
• シンプルなデビット/クレジット
• 残高チェック
• 価格に関するお問い合わせ

直径クレジット制御アプリケーションでは、どのタイプのユニットが購入/使用され、どのアイテムが課金されるかは指定されません。これは、一部のセマンティクスと同様に、別途指定する必要があるサービス コンテキストに委ねられます。

使用/購入したユニットの例:

• 時間
• アップロード/ダウンロードバイト
• SMS（テキストメッセージ）

請求対象となる項目の例:

• お金
• ポイント
• 単位（例：残高が使用されている単位と同じ単位で保持されている場合）

Diameter クレジット コントロールでは、単一のユーザー残高に対して複数のユニット タイプが使用/課金されるというかなり複雑な問題の処理方法も指定します。たとえば、ユーザーはオンライン時間とダウンロード バイトの両方に対して料金を支払う場合がありますが、アカウント残高は 1 つしかありません。

セッション ベースのクレジット管理プロセスでは、最初の照会、中間の照会、最後の照会など、複数の照会が使用されます。照会中は、ユーザー アカウントからお金が予約されます。セッション ベースの課金は、通常、課金単位が継続的に消費されるシナリオ (アップロード/ダウンロード バイトの課金など) で使用されます。

イベントベースのクレジット制御プロセスでは、課金メカニズムとしてイベントを使用します。イベントベースの課金は、通常、ユニットが継続的に消費されない場合 (ユーザーが MMS を送信する場合など) に使用されます。

Diameter によるクレジット制御をサポートするために、CCR (クレジット制御要求) と CCA (クレジット制御応答) の 2 つの Diameter メッセージがあります。CCR/CCA のコマンド コードは RFC 4006 で定義されている 272 です。

クォータ管理の場合、クライアントは CCR をサーバーに送信してユニットを要求し、消費量を報告します。サーバーはユニットを付与し、ユーザーに請求します。単純なデビット/クレジットの場合、クライアントは CCR を送信して、ユーザーのアカウントにクレジット/デビットするようにサーバーに要求します。価格の問い合わせの場合、クライアントはサーバーにユニットの価格を尋ね、サーバーは価格を応答します。

メッセージ フローは、一般的に、ユニットを要求するコントロール ポイントと、ユニットを許可するサーバーによって駆動されます。メッセージは、時間/使用量が制限されているセッション用の NASREQ (RFC4005) などの他の Diameter アプリケーションによって生成される場合もあります。

次の図は、クォータ許可を使用したセッションの簡略化されたメッセージ フローを示しています。

クライアントは、サーバーに 10 ユニットを要求することから始めます。サーバーは、ユーザー/加入者に十分な残高があるかどうかを確認します。この例では、サーバーはクライアントが要求したすべてのユニットを許可します。加入者の残高が不十分な場合は、許可するユニット数を減らすか、完全に拒否することができます。

加入者セッションが付与されたユニットを使用したとき、または使用する前に、クライアントはサーバーに更新を送信し、使用されたユニット数と今回付与するユニット数を通知します。クライアントは、サーバーとの通信中に加入者セッションが中断されるのを避けるために、前回の付与が完全に使用される前にユニットを要求できます。この例では、クライアントは、以前に付与された 10 ユニットのうち 7 ユニットが使用されたときに要求を送信し、さらに 10 ユニットを要求し、サーバーはそれを付与します。サーバーは、使用されたユニット数を使用して加入者の残高から引き落とすことができます (ユニットを付与しても、それが使用されるとは限りません。Used-Units AVP には実際の使用量が含まれます)。また、サーバーがクライアントに付与の有効期間を通知することもできます。その場合、クライアントは付与タイマーの期限が切れたときに更新を送信することが求められます。

セッション中に多くの更新メッセージが発生する可能性があります。

最後に、加入者がセッションを終了し、クライアントは最後の使用済みユニットを含む終了メッセージをサーバーに送信します。サーバーは終了メッセージを使用して、バックエンドの残高管理システムで行われた関連する予約をクリアできます。加入者が自分でセッションを終了せず、代わりに残高を使い果たした場合、サーバーは更新メッセージに対して拒否で早めに応答し、クライアント/コントロール ポイントにトラフィックをリダイレクトするように指示する可能性があります (これは通常、HTTP / WAPトラフィックに対してのみ意味があります)。

新しいコマンド コード CCA および CCR では、以下に示すように、いくつかの AVP が必要になる場合があります。太字の AVP は DCCA の新機能です。

表では次の記号を使用します。

• 0 AVPはメッセージに存在してはならない
• 0+ メッセージにはAVPのインスタンスが0個以上存在する可能性がある
• 0–1 メッセージ内にAVPのインスタンスが0個または1個存在する場合があります。AVPのインスタンスが複数ある場合はエラーとみなされます。
• 1 メッセージにはAVPのインスタンスが1つ存在する必要がある
• 1+ メッセージには少なくとも 1 つの AVP インスタンスが存在する必要があります。

• RFC 4005 - Diameter ネットワーク アクセス サーバー アプリケーション。
• RFC 4006 - Diameter クレジット制御アプリケーション (廃止)
• RFC 8506 - Diameter クレジット制御アプリケーション。
• 3GPP 32.299 - 3GPP 通信管理 - 課金管理 - Diameter 課金アプリケーション。