9. 課金 (Accounting)

本課金プロトコルはサーバ主導モデル (server directed model) に基づき, 課金情報のリアルタイム配信機能を備えています. さまざまな障害状況および使用機器の能力に関する仮定の下で課金データの損失を最小化するため, 複数の障害耐性手法 [RFC2975] がプロトコルに組み込まれています.

9.1. サーバ主導モデル (Server Directed Model)

サーバ主導モデルとは, 課金データを生成するデバイスが, 認可サーバ (接触した場合) または課金サーバから, 課金データの転送方法に関する情報を取得することを意味します. この情報には, 課金記録の適時性要件が含まれます.

[RFC2975] で論じられているように, 課金記録のリアルタイム転送は要件です (与信限度チェックや不正検知など). バッチ課金は要件ではないため, Diameter ではサポートされません. 将来バッチ課金が必要になった場合は, 新しい Diameter アプリケーションを作成するか, 別のプロトコルで処理する必要があります. ただし, Diameter 層では課金要求が 1 件ずつ処理されても, Diameter の下位で用いるトランスポートプロトコルは高トラフィック時に同一パケット内で複数の要求をバッチ化することが多く, 多くのアプリケーションには十分な場合があります.

認可サーバ (チェーン) は, ユーザーとローミング提携関係に関する知識に基づき, 適切な転送戦略の選択を指示します. サーバ (またはエージェント) は Acct-Interim-Interval AVP および Accounting-Realtime-Required AVP を用いて, クライアントとして動作する Diameter ピアの動作を制御します. Acct-Interim-Interval AVP が存在する場合, クライアントとして動作する Diameter ノードに対し, セッション中も継続的に課金記録を生成するよう指示します. Accounting-Realtime-Required AVP は, Diameter クライアントからの課金記録の転送が遅延または失敗した場合のクライアントの動作を制御するために用いられます.

Diameter 課金サーバは, Accounting-Answer メッセージに Acct-Interim-Interval または Accounting-Realtime-Required AVP を含めることで, 中間間隔またはリアルタイム要件を上書きしてもよい (MAY) です. これらの AVP のいずれかが存在する場合, 同一セッションの以降の課金活動では, 受信した最新の値を用いるべきです (SHOULD).

9.2. プロトコルメッセージ (Protocol Messages)

Diameter サーバから成功した認証および/または認可メッセージを受信した Diameter ノードは, そのセッションの課金情報を収集すべきです (SHOULD). Accounting-Request メッセージは課金情報を Diameter サーバへ送信するために用いられ, サーバは受信確認のために Accounting-Answer メッセージで応答しなければなりません (MUST). Accounting-Answer メッセージには Result-Code AVP が含まれ, 課金メッセージにエラーがあったことを示してもよい (MAY) です. 当該セッションについて以前に受信した Accounting-Realtime-Required AVP の値は, 拒否された Accounting-Request メッセージを受信した際にユーザーセッションを終了しなければならないことを示す場合があります.

9.3. 課金アプリケーション拡張と要件 (Accounting Application Extension and Requirements)

各 Diameter アプリケーション (例: NASREQ, Mobile IP) は, 「Accounting AVPs」という見出しの節で, Accounting-Request メッセージに存在しなければならない (MUST) サービス固有 AVP を定義すべきです (SHOULD). アプリケーションは, 本文書で説明する AVP がすべての課金メッセージに存在することを前提としなければならず (MUST), その節ではそれぞれのサービス固有 AVP のみを定義すれば足ります.

アプリケーションは, 次の課金アプリケーション拡張モデルのいずれか一方または両方を用いることができます.

分離課金サービス (Split Accounting Service)

課金メッセージは Diameter ベース課金アプリケーションの Application Id を運びます (第 2.4 節参照). 課金メッセージは, 対応する Diameter アプリケーション以外の Diameter ノードへルーティングされてもよい (MAY) です. それらは複数の異なる Diameter アプリケーション向けに課金サービスを提供する集中課金サーバである場合があります. これらのノードは, 能力交換の際に Diameter ベース課金 Application Id を告知しなければなりません (MUST).

結合課金サービス (Coupled Accounting Service)

課金メッセージは, それを使用するアプリケーションの Application Id を運びます. アプリケーション自体が受信した課金記録を処理するか課金サーバへ転送します. 能力交換での課金アプリケーション告知は不要で, 課金メッセージは他のアプリケーションメッセージと同様にルーティングされます.

アプリケーションが独自の課金サービスを定義しない場合は, 分離課金モデルの使用が望ましいです.

9.4. 障害耐性 (Fault Resilience)

Diameter ベースプロトコルの仕組みにより, 小規模なメッセージ損失と一時的なネットワーク障害に対処します.

クライアントとして動作する Diameter ピアは, サーバ障害および特定のネットワーク障害に備え, フェイルオーバーの使用を実装しなければなりません (MUST). エージェントとして動作する Diameter ピアまたは関連するオフライン処理システムは, 同一記録を複数サーバへ送信したことや転送中のメッセージ複製によって生じる重複課金記録を検出しなければなりません (MUST). この検出は Session-Id と Accounting-Record-Number AVP の組の検査に基づかなければなりません (MUST). 付録 C で重複検出の必要性と実装上の論点を扱います.

Diameter クライアントは, 再起動や長時間のネットワーク障害, ネットワーク分割, サーバ障害にわたり課金記録を安全に保存するための不揮発性メモリを備えてもよい (MAY) です. そのようなメモリがある場合, クライアントは記録が作成された直ちに新しい課金記録をそこに格納し, Diameter サーバからの受信の肯定応答があるまで保持すべきです (SHOULD). 再起動後, クライアントは不揮発性メモリ内の記録を, 終了原因, セッション長, その他関連情報の適切な修正を加えて課金サーバへ送り始めなければなりません (MUST).

本プロトコルの拡張アプリケーションでは, 不揮発性メモリへコミットせず Diameter サーバへ転送する前に, Diameter クライアントに保存してよい課金記録の最大数を制御する AVP を含めてもよい (MAY) です.

正しい Accounting-Answer を受信する前に, クライアントはいずれのメモリ領域からも課金データを削除すべきではありません (SHOULD NOT). メモリなどのリソースが枯渇した場合, クライアントは最も古い未配信または未確認の課金データを削除してもよい (MAY) です. この条件下で新規セッションを受け入れるかは実装依存です.

9.5. 課金記録 (Accounting Records)

すべての課金記録に Session-Id AVP が存在しなければなりません (MUST). User-Name AVP は Diameter クライアントが利用可能であれば存在しなければなりません (MUST).

課金対象サービスの実際の種類と認可サーバの中間課金に関する指示に応じて, 異なる種類の課金記録が送信されます. 課金対象サービスが一回限りのイベント (開始と終了が同時) である場合, Accounting-Record-Type AVP が存在し, 値 EVENT_RECORD でなければなりません (MUST).

課金対象サービスが測定可能な長さを持つ場合, その AVP は START_RECORD, STOP_RECORD, および場合により INTERIM_RECORD を用いなければなりません (MUST). 認可サーバがセッションに中間課金を有効にしていない場合, セッション型サービスごとに 2 つの課金記録を生成しなければなりません (MUST). 所定セッションの最初の Accounting-Request を送信する際, Accounting-Record-Type AVP は START_RECORD でなければなりません (MUST). 最後の Accounting-Request を送信する際, 値は STOP_RECORD でなければなりません (MUST).

認可サーバが中間課金を有効にした場合, Diameter クライアントは START_RECORD と STOP_RECORD の間に INTERIM_RECORD と印付きの追加記録を生成しなければなりません (MUST). これらの記録の生成は Acct-Interim-Interval およびセッションの再認証または再認可によって指示されます. 同一セッション用に新しい記録が生成される場合, Diameter クライアントは配信用にローカル保存された以前の中間課金記録を上書きしなければなりません (MUST). これにより, 任意の所定セッションについてアクセスデバイス上に保留中の中間記録は 1 つだけとなります.

再送を除き, 特定の Accounting-Sub-Session-Id の値は Diameter クライアントからの 1 つの課金記録系列にのみ現れてはなりません (MUST). 送信されるその 1 系列は, Accounting-Record-Type AVP が EVENT_RECORD の 1 件の記録か, START_RECORD を持つ 1 件から始まり 0 件以上の INTERIM_RECORD と 1 件の STOP_RECORD で終わる複数記録のいずれかでなければなりません (MUST). 特定の Diameter アプリケーション仕様は, 使用しなければならない系列の種類を定義しなければなりません (MUST).

9.6. 課金記録の相関 (Correlation of Accounting Records)

アプリケーションが課金メッセージを用いる場合, 課金メッセージ内で特定アプリセッションの Session-Id を用いて, 課金記録をそのアプリセッションと相関できます. 課金メッセージはアプリセッションとは異なる Session-Id を用いてもよく (MAY), その場合は相関のために他のセッション関連情報が必要です.

アプリケーションが複数の課金子セッションを要する場合, Accounting-Sub-Session-Id AVP で各子セッションを区別します. Session-Id はすべての子セッションで一定のままとし, 特定アプリセッションへのすべての子セッションの相関に用います. もともと START_RECORD メッセージで子セッションを用いたのに, Accounting-Sub-Session-Id AVP のない STOP_RECORD を受信した場合, すべての子セッションが終了したことを意味します.

また, 複数のアプリセッションを 1 つの課金記録に相関させる必要がある場合もあります. 課金記録は, 所定時刻に同一ユーザーが用いる複数の異なる Diameter アプリケーションとセッションにまたがることがあります. その場合 Acct-Multi-Session-Id AVP を用います. サーバが要求が既存セッションに属すると判断したとき (通常は認可中), Acct-Multi-Session-Id AVP をアクセスデバイスへ通知すべきです (SHOULD). アクセスデバイスは, 以降のすべての課金メッセージに Acct-Multi-Session-Id AVP を含めなければなりません (MUST).

Acct-Multi-Session-Id AVP には元の Session-Id の値を含めてもよい (MAY) です. 内容は実装固有ですが, 他の Acct-Multi-Session-Id 全体でグローバルに一意でなければならず (MUST), セッション存続期間中は変わってはなりません (MUST NOT).

Diameter アプリケーションドキュメントは, 課金対象セッションの正確な概念を定義しなければならず (MUST), マルチセッションの概念を定義してもよい (MAY) です. 例えば NASREQ DIAMETER アプリケーションでは, ネットワークアクセスサーバへの単一 PPP 接続を 1 セッションとし, マルチリンク PPP セッションの集合を 1 マルチセッションとみなします.

9.7. 課金コマンドコード (Accounting Command Codes)

本節は, 課金サービスを提供するすべての Diameter 実装がサポートしなければならない (MUST) コマンドコード値を定義します.

9.7.1. Accounting-Request

コマンドコードフィールドが 271 でコマンドフラグの R ビットがセットされた Accounting-Request (ACR) コマンドは, クライアントとして動作する Diameter ノードがピアと課金情報を交換するために送信します.

以下に挙げる AVPに加え, Accounting-Request メッセージにはサービス固有の課金 AVP を含めるべきです (SHOULD).

メッセージ形式 (Message Format)

::= < Diameter Header: 271, REQ, PXY >
    < Session-Id >
    { Origin-Host }
    { Origin-Realm }
    { Destination-Realm }
    { Accounting-Record-Type }
    { Accounting-Record-Number }
    [ Acct-Application-Id ]
    [ Vendor-Specific-Application-Id ]
    [ User-Name ]
    [ Destination-Host ]
    [ Accounting-Sub-Session-Id ]
    [ Acct-Session-Id ]
    [ Acct-Multi-Session-Id ]
    [ Acct-Interim-Interval ]
    [ Accounting-Realtime-Required ]
    [ Origin-State-Id ]
    [ Event-Timestamp ]
    * [ Proxy-Info ]
    * [ Route-Record ]
    * [ AVP ]

9.7.2. Accounting-Answer

コマンドコードフィールドが 271 でコマンドフラグの R ビットがクリアされた Accounting-Answer (ACA) コマンドは, Accounting-Request コマンドを確認するために用いられます. Accounting-Answer コマンドは対応する要求と同じ Session-Id を含みます.

ターゲットとなる Diameter サーバ (ホーム Diameter サーバ) のみが Accounting-Answer コマンドで応答すべきです (SHOULD).

以下に挙げる AVPに加え, Accounting-Answer メッセージにはサービス固有の課金 AVP を含めるべきです (SHOULD).

メッセージ形式 (Message Format)

::= < Diameter Header: 271, PXY >
    < Session-Id >
    { Result-Code }
    { Origin-Host }
    { Origin-Realm }
    { Accounting-Record-Type }
    { Accounting-Record-Number }
    [ Acct-Application-Id ]
    [ Vendor-Specific-Application-Id ]
    [ User-Name ]
    [ Accounting-Sub-Session-Id ]
    [ Acct-Session-Id ]
    [ Acct-Multi-Session-Id ]
    [ Error-Message ]
    [ Error-Reporting-Host ]
    [ Failed-AVP ]
    [ Acct-Interim-Interval ]
    [ Accounting-Realtime-Required ]
    [ Origin-State-Id ]
    [ Event-Timestamp ]
    * [ Proxy-Info ]
    * [ AVP ]

9.8. 課金 AVP (Accounting AVPs)

本節は, 特定セッションに関連する課金利用情報を記述する AVP を含みます.

9.8.1. Accounting-Record-Type AVP

Accounting-Record-Type AVP (AVP コード 480) は列挙型で, 送信される課金記録の種類を含みます. Accounting-Record-Type AVP に現在定義されている値は次のとおりです.

EVENT_RECORD 1

課金イベント記録は, 一回限りのイベントが発生した (開始と終了が同時である) ことを示すために用いられます. この記録にはサービスに関連するすべての情報が含まれ, そのサービスの唯一の記録です.

START_RECORD 2

課金開始, 中間, 停止記録は, 測定可能な長さのサービスが提供されたことを示すために用いられます. 課金開始記録は課金セッションを開始し, セッション開始に関連する課金情報を含みます.

INTERIM_RECORD 3

中間課金記録は, 既存の課金セッションに対する累積課金情報を含みます. 再認証または再認可が行われるたびに中間課金記録を送信すべきです (SHOULD). さらに, アプリケーション固有の Diameter アプリケーションにより追加の中間記録トリガを定義してもよい (MAY) です. INTERIM_RECORD を用いるかどうかは Acct-Interim-Interval AVP により選択されます.

STOP_RECORD 4

課金停止記録は課金セッションを終了するために送信され, 既存セッションに関連する累積課金情報を含みます.

9.8.2. Acct-Interim-Interval AVP

Acct-Interim-Interval AVP (AVP コード 85) は符号なし 32 ビット整数型で, Diameter ホーム認可サーバから Diameter クライアントへ送られます. クライアントはこの AVP の情報に基づき, 課金記録の生成方法とタイミングを決定します. この AVP の値により, ホーム組織のニーズに応じてサービスセッションは 1 件, 2 件, または 2+N 件の課金記録となり得ます. この AVP の含有により指示される課金記録生成の動作は次のとおりです.

Acct-Interim-Interval AVP を省略するか, Value フィールドを 0 にすると, サービスに応じて EVENT_RECORD, START_RECORD, STOP_RECORD が生成されることを意味します.
Value フィールドが非ゼロの値で AVP を含めると, START_RECORD と STOP_RECORD の間に INTERIM_RECORD 記録を生成しなければなりません (MUST). この AVP の Value フィールドはこれらの記録間の公称間隔 (秒) です. 課金情報を発信する Diameter ノード (クライアント) は, START_RECORD からこの公称間隔が経過したおおよその時点で最初の INTERIM_RECORD を生成し, さらに間隔ごとに次々と生成し, セッション終了時に STOP_RECORD を生成しなければなりません (MUST).

クライアントは, 記録間または共通のサービス開始時刻付近で大規模な課金メッセージストームが発生しないよう, 中間記録の生成時刻をランダム化しなければなりません (MUST).

9.8.3. Accounting-Record-Number AVP

Accounting-Record-Number AVP (AVP コード 485) は符号なし 32 ビット整数型で, 1 セッション内の本記録を識別します. Session-Id AVP はグローバルに一意であるため, Session-Id と Accounting-Record-Number AVP の組み合わせもグローバルに一意であり, 課金記録と確認の照合に用いられます. 一意な番号を付与する簡単な方法は, EVENT_RECORD および START_RECORD で値 0, 最初の INTERIM_RECORD で 1, 2 番目で 2, とし, STOP_RECORD の値を最後の INTERIM_RECORD より 1 大きくすることです.

9.8.4. Acct-Session-Id AVP

Acct-Session-Id AVP (AVP コード 44) はオクテット文字列型で, RADIUS/Diameter 変換が行われる場合にのみ用いられます. この AVP には RADIUS の Acct-Session-Id 属性の内容が含まれます.

9.8.5. Acct-Multi-Session-Id AVP

Acct-Multi-Session-Id AVP (AVP コード 50) は UTF8String 型で, 第 8.8 節で指定された形式に従います. Acct-Multi-Session-Id AVP は, 各セッションが一意の Session-Id を持ち同一の Acct-Multi-Session-Id AVP を持つ, 複数の関連課金セッションをリンクするために用いられます. この AVP は Diameter サーバが認可応答で返してもよく (MAY), 所定セッションのすべての課金メッセージに含めなければなりません (MUST).

9.8.6. Accounting-Sub-Session-Id AVP

Accounting-Sub-Session-Id AVP (AVP コード 287) は符号なし 64 ビット整数型で, 課金子セッション識別子を含みます. Session-Id とこの AVP の組は子セッションごとに一意でなければならず (MUST), すべての新しい子セッションについてこの AVP の値は 1 ずつ単調増加しなければなりません (MUST). この AVP がない場合は子セッションを用いていないことを意味しますが, Accounting-Record-Type が STOP_RECORD に設定された Accounting-Request は例外です. Accounting-Sub-Session-Id AVP のない STOP_RECORD メッセージは, 所定 Session-Id のすべての子セッションの終了を示します.

9.8.7. Accounting-Realtime-Required AVP

Accounting-Realtime-Required AVP (AVP コード 483) は列挙型で, Diameter ホーム認可サーバから Diameter クライアントへ, または課金サーバからの Accounting-Answer で送られます. クライアントは, 例えばネットワーク問題により課金サーバへの課金記録送信が一時的に妨げられた場合に何をすべきかを, この AVP の情報に基づいて決定します.

DELIVER_AND_GRANT 1

Value が DELIVER_AND_GRANT の場合, 課金サーバへの接続がある限りサービスを付与しなければなりません (MUST). この意味では, 代替課金サーバの集合は 1 台のサーバとして扱われます. 課金記録ストリームをバックアップサーバへ移す必要があること自体は, ユーザーへのサービス中断の理由になりません.

GRANT_AND_STORE 2

Value が GRANT_AND_STORE の場合, 接続がある場合はサービスを付与すべきであり (SHOULD), 第 9.4 節に記載のとおり記録をまだ格納できる限り付与すべきです (SHOULD).

認可サーバの応答にこの AVP が含まれない場合, これがデフォルトの動作です.

GRANT_AND_LOSE 3

Value が GRANT_AND_LOSE の場合, 記録を配信または格納できなくてもサービスを付与すべきです (SHOULD).