Gy インターフェイスのサポート

この章では、Gy インターフェイスの概要と、Gy インターフェイスの設定方法について説明します。

次の製品のシスコシステムで Gy インターフェイスがサポートされています。

GGSN
HA
IPSG
PDSN
P-GW

この章に記載する手順を実行する前に、展開する製品のアドミニストレーションガイドの説明に従って、お使いのサービスモデルに最適な設定例を選択し、そのモデルに必要な要素を設定することを推奨します。

機能の概要と変更履歴

要約データ


該当製品または機能エリア	PGW
該当プラットフォーム	ASR 5500 VPC-DI VPC-SI
このリリースでの関連する変更点	N/A
関連資料	Command Line Interface Reference PGW Administration Guide Statistics and Counters Reference

マニュアルの変更履歴

重要	リリース 21.2 および N5.1 よりも前に導入された機能の改訂履歴の詳細は示していません。


改訂の詳細	リリース
CDR のサーバー到達不能フィールドを追加するためのサポートが追加されました。	21.27
最初の導入。	21.22

はじめに

Gy インターフェイスは、PCEF/GW（課金トリガー機能（CTF））とオンライン課金システム（課金データ機能（CDF））間のオンライン課金インターフェイスです。

Gy インターフェイスは、アクティブ課金サービス（ACS）や Enhanced Charging Service（ECS）を利用して、データサービスのコンテンツベースの課金にリアルタイムで対応します。これは 3GPP 標準規格に基づいており、クォータ割り当てに依存しています。オンライン課金システム（OCS）は、オンライン課金データを PCEF/GW に提供する Diameter クレジット制御サーバーです。Gy を使用すると、カスタマートラフィックをゲートウェイに送り、オンラインまたは前払いの形式で課金できます。時間ベースと使用量ベースの課金モデルがサポートされています。これらのモデルでは、ECS のシャローパケットインスペクションまたはディープパケットインスペクションに基づいて、各種サービスに異なるレートを適用できます。

最も単純なインストールでは、システムは Diameter TCP リンクを介して、システム自体と 1 台の前払いサーバーとの間で、Gy Diameter メッセージを交換します。インストールを堅牢化するには、複数のサーバーを使用します。これらのサーバーは、必要に応じて単一のクォータデータベースを共有またはミラーリングして、あるサーバーから別のサーバーへの Gy セッションのフェールオーバーに対応します。拡張性の高いインストールでは、プロキシまたは他の Diameter エージェントのレイヤを導入して、マルチパスメッセージルーティング、メッセージやセッションのリダイレクト機能などを提供できます。

次の図は、ポリシーと課金アーキテクチャの Gy 参照ポイントを示しています。

次の図は、ECS と OCS（CDF/サーバー）を実行している CTF/ゲートウェイ/PCEF/クライアント間の Gy インターフェイスを示しています。PCEF/GW 内では、Gy プロトコル機能は、DCCA モジュール内（ECS）で処理されます。

ライセンス要件

Gy インターフェイスのサポートは、ライセンス供与されたシスコの機能です。別の機能ライセンスが必要になる場合があります。特定のライセンス要件の詳細については、シスコのアカウント担当者にお問い合わせください。ライセンスのインストールと確認の詳細については、『システム管理ガイド』の「ソフトウェア管理操作」の「ライセンスキーの管理」の項を参照してください。

サポートされる標準

Gy インターフェイスのサポートは、次の標準に基づいています。

IETF RFC 4006：Diameter Credit Control Application（2005 年 8 月）
3GPP TS 32.299 V9.6.0 (2010-12) 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Telecommunication management; Charging management; Diameter charging applications (Release 9)

機能と用語

ここでは、Gy 機能に関連する機能と用語について説明します。

課金シナリオ

重要	イベントのオンライン課金（「即時イベント課金」および「予約によるイベント課金」）はサポートされていません。「予約によるセッション課金」のみがサポートされます。

予約によるセッション課金

ユニット予約によるセッション課金は、セッションのクレジット制御に使用されます。

分散型ユニット決定と集中型レート設定

このシナリオでは、CTF はセッションの指揮の前にユニットの予約を要求します。セッションの終了処理が終わると、口座引き落とし操作が実行されます。

集中型ユニット決定と集中型レート設定

このシナリオでは、CTF が、OCS に、CTF によって指定されるセッション識別子に基づいてユニットを予約するように要求します。セッションの終了後に、口座引き落とし操作が実行されます。

分散型ユニット決定と分散型レート設定

重要	分散型レート設定は、このリリースではサポートされていません。分散型ユニットの決定は、CLI 設定コマンドを使用して行われます。

このシナリオでは、CTF は OCS に対して、指定された単位の金額の支払い予約をサブスクライバのアカウントで保証するよう要求します。サブスクライバのアカウントからの支払いをトリガーするアカウントのデビット操作は、セッションの確立の終了後に実行されます。

基本操作

重要	即時イベント課金は、このリリースではサポートされていません。「予約ユニット要求」と「予約ユニット応答」は、イベント課金ではなく、セッション課金に対して実行されます。

オンラインクレジット制御では、基本的な論理演算「デビットユニット」と「予約ユニット」を使用します。

デビットユニット要求（CTF から OCS に送信）：CTF は、サブスクライバからサービス要求を受信した後、デビットユニット要求を OCS に送信します。CTF では、サービス識別子（集中型ユニット決定）または要求されるユニット数（分散型ユニット決定）のいずれかを指定できます。返金を目的として、CTF はデビットユニット要求も OCS に送信します。
デビットユニット応答（OCS から CTF に送信）：OCS はデビットユニット応答で応答します。この応答は、デビットユニット要求の結果として付与されたユニット数を CTF に通知します。これには、付与されたユニット数が、要求されたサービスをレンダリングする権限を示す場合も含まれます。返金を目的として、OCS はデビットユニット応答で応答します。
予約ユニット要求（CTF から OCS に送信）：CTF によって提供されるサービスのためにユニット数を予約するよう要求します。集中型ユニット決定の場合、CTF は予約ユニット要求でサービス識別子を指定し、OCS は要求されるユニット数を決定します。分散型ユニット決定の場合、要求されるユニット数は CTF によって指定されます。
予約ユニット応答（OCS から CTF に送信）：「予約ユニット要求」の結果として予約されたユニット数を CTF に通知する OCS からの応答。

ユニット予約（SCUR）によるセッション課金では、「デビットユニット」と「予約ユニット」の両方の操作が使用されます。SCUR では、RFC 4006 で指定されているセッションベースのクレジット制御手順が使用されます。ユニット予約によるセッション課金では、「デビットユニット」操作と「予約ユニット」操作の両方が必要な場合、これらの操作は 1 つのメッセージに統合されます。

重要	コスト情報、残高、および残高減少を示す AVP はサポートされていません。

消費されたユニットは、サービスの提供後にサブスクライバのアカウントから差し引かれます。そのため、予約済みユニットと消費済みユニットは必ずしも同一ではありません。この操作を使用して、CTF は、以前に予約されたユニットの返戻分を含めて、現在の予約を変更することもできます。

再承認

サーバーは、付与されたクォータに関連付けられたアイドルタイムアウトを指定できます。または、クライアントに設定可能なデフォルト値を指定することもできます。このタイマーが切れると、再承認要求がトリガーされます。

セッション中のサービスイベント（再承認トリガー）によって、現在のサービス使用状況のレーティングが影響を受ける場合があります。サーバーは、レーティング条件に影響を与える可能性のあるさまざまなセッション関連のトリガーが発生した場合に、クォータを再承認するようにクレジット制御クライアントに指示する場合があります。

再承認がトリガーされると、クライアントはクォータの使用状況を報告します。クォータが報告されている理由がサーバーに通知されます。

しきい値ベースの再承認トリガー

サーバーはオプションで、クォータの再承認をトリガーする残りのクォータしきい値のクライアントへの指示を追加することができます。

終了アクション

サーバーは、最後に許可されたユニットの消費時の動作をクライアントに対して指定できます。これは終了アクションと呼ばれます。

Diameter 基本プロトコル

Diameter 基本プロトコルは、Diameter クライアントと Diameter サーバー間の基礎となる接続を維持します。クライアントとサーバー間の接続は TCP ベースです。接続と機能のステータスを確認するために、一連のメッセージが交換されます。

機能交換メッセージ：機能交換メッセージは、互いの機能と互いのアイデンティティを認識するために、Diameter ピア間で交換されます。

機能交換要求（CER）：このメッセージは、サーバーの機能を認識するためにクライアントからサーバーに送信されます。
機能交換応答（CEA）：このメッセージは、CER メッセージへの応答としてサーバーからクライアントに送信されます。

重要	Acct-Application-Id は解析されず、送信された場合は PCEF/GW によって無視されます。Result-Code が DIAMETER_SUCCESS でない場合、ピアとの接続は閉じられます。

デバイスウォッチドッグ要求（DWR）：CER/CEA メッセージが交換された後、しばらくの間ピア間のトラフィックがなくなった場合、接続の正常性をモニターするために、DWR メッセージがクライアントから送信されます。デバイスウォッチドッグタイマー（Tw）は PCEF/GW で設定可能で、6 ～ 30 秒の範囲で設定できます。値を小さくすると、メッセージの重複が発生します。デフォルト値は 30 秒です。DWA がない状態で Tw が 2 回連続して期限切れになると、ピアはダウンしていると見なされます。

重要	DWR は、サーバーから最後のメッセージ受信した後、Tw の期限切れ後にのみ送信されます。たとえば、ピア間で継続的にメッセージが交換される場合、サーバーからの最後のメッセージ受信時刻から現在時刻までの経過時間が Tw よりも小さい場合、DWR は送信されない可能性があります。

デバイスウォッチドッグ応答（DWA）：これは、サーバーからの DWR メッセージに対する応答です。接続状態のモニタリングに使用されます。
ピア切断要求（DPR）：このメッセージは、接続をシャットダウンするように通知するためにピアに送信されます。PCEF/GW はこのメッセージの受信のみを行います。現在、Diameter サーバーにメッセージを送信する機能はありません。
ピア切断応答（DPA）：このメッセージは、ピアからの DPR 要求に対する応答です。DPR を受信すると、ピアは DPA を送信し、接続状態を「DO NOT WANT TO TALK TO YOU」状態にします。ピアを再度設定する以外、接続を元に戻す方法はありません。

切断されたピアを再試行するためのタイムアウト値を指定する必要があります。
Tw タイマー期限切れ動作：クライアントとサーバー間の接続は、DIABASE アプリケーションによって管理されます。Tw タイマーが 2 回連続で期限切れになると、ピア状態はアイドルに設定され、接続の確立が再試行されます。その後、その接続上のすべてのアクティブセッションは、セカンダリ接続に転送されます（セカンダリ接続が設定されている場合）。すべての新しいセッションのアクティブ化も、セカンダリ接続で試行されます。

Tw タイマーとも同等である接続タイムアウト間隔があります。その期間中、CER がサーバーに送信された後、接続の再確立の試行中に応答を受信しない場合、接続は閉じられ、状態はアイドルに設定されます。

Diameter クレジット制御アプリケーション

Diameter クレジット制御アプリケーション（DCCA）は、ECS サブシステムの一部です。Diameter クレジット制御が有効になっているすべてのプリペイドのお客様について、セッションが開始されるたびに、Diameter サーバーに接続され、サブスクライバのクォータが取得されます。

クォータの動作

さまざまな形式のクォータが存在し、これを使用して効率的な方法でサブスクライバに課金できます。さまざまなクォータメカニズムにより、エンドユーザーには選択可能な多様なオプションが提供されます。また、サービスプロバイダーはクォータをより効果的に扱えるようになります。

時間クォータ

クレジット制御サーバーは、クライアントとの任意の問い合わせ中に、サブスクライバの CC-Time クォータを送信できます。また、以下で説明するさまざまなメカニズムもあり、これらを時間クォータと組み合わせて使用して、顧客満足度を高めるさまざまな方法を派生させることができます。

Quota-Consumption-Time：サーバーはオプションで、パケットが受信されない「Quota-Consumption-Time」と等しい期間が経過するか、セッションの終了時かのどちらか早い方で、クォータ消費を停止する必要があることをクライアントに示すことができます。Quota-Consumption-Time に等しいアイドル期間は、報告される使用量に含まれます。クォータは通常、Quota-Consumption-Time 以下の期間のトラフィックギャップ中に消費されます。クォータの消費は、サービスデータフローに属するパケットをさらに受信すると再開されます。

CCR（Update）/CCA 交換時のパケットフローが許可されており、提供されたクォータの Quota-Consumption-Time AVP 値が以前に提供されたクォータと同じである場合、Quota-Consumption-Time は、この手順で正常に実行されます。たとえば、CCR（U）がトリガーされたときに 10 秒の QCT タイマーのうち 5 秒が経過しており、CCA（U）が 2 秒後に返された場合、QCT タイマーは CCA の受信から 3 秒後に期限切れとなり、新しいクォータでパケットが送信されなかった場合でも、算入されていない残りの 5 秒分の使用量が新しいクォータに対して記録されます。

サーバーが CCA で QCT を送信しない場合は、クライアントで、ローカルに設定可能なデフォルト値を使用できます。
組み合わせクォータ：Discrete-Time-Period（DTP）と Continuous-Time-Period（CTP）は、時間クォータを消費するための Quota-Consumption-Time を拡張および一般化するメカニズムを定義します。
- DTP と CTP はどちらも、使用されるクォータの時間エンベロープを作成するために使用される「Base-Time-Interval」を使用します。
- DTP と CTP は、クォータを直線的に消費するのではなく、付与されたクォータを、各 Base-Time-Interval の開始時に、Base-Time-Interval のチャンク単位で段階的に消費します。
- このアルゴリズムのいずれかが、CCA のサーバーから送信された「Time-Quota-Mechanism」AVP に基づいて選択されます。
- 使用量のレポートは、クォータの付与中に CCA のサーバーによって送信される Envelope-Reporting AVP によって制御することもできます。この AVP の値に基づいて、使用量を、エンベロープごとの使用量またはその付与の通常の累積使用量として報告できます。
Discrete-Time-Period：Discrete-Time-Period の長さは Base-Time-Interval によって定義されます。そのため、各時間エンベロープは、1 つの Discrete-Time-Period に正確に対応します。そのため、トラフィックが検出されると、Base-Time-Interval に等しいサイズのエンベロープが作成されます。トラフィックは時間エンベロープを通過できます。トラフィックが Base-Time-Interval を超えると、Base-Time-Interval に等しい別の新しいエンベロープが作成されます。これは、使用されているクォータがクォータ付与を超えるか、そのクォータのしきい値制限に達するまで続きます。
Continuous-Time-Period：Continuous-Time-Period メカニズムは、トラフィックを含まない Base-Time-Interval までの（この Base-Time-Interval を含む）時間エンベロープを、トラフィックが発生した連続した Base-Time-Interval から構築します。そのため、前の Base-Time-Interval にトラフィックがあった場合、クォータ消費が時間エンベロープ内で継続されます。エンベロープが閉じられた後のクォータ消費は、エンベロープが閉じられた後の最初のトラフィックでのみ再開されます。CTP のエンベロープには、トラフィックを含まない最後の Base-Time-Interval が含まれます。

エンベロープのサイズは、パーキングメーターの場合のように一定ではありません。エンベロープの終わりは、過去に遡ることによってのみ判断できます。
Quota-Holding-Time：サーバーは、Quota-Holding-Time AVP を使用して、付与されたクォータに関連付けられるアイドルタイムアウトを指定できます。この時間にわたって、クォータに関連付けられたトラフィックが観測されない場合、クライアントはトラフィックが停止したことを認識し、クォータがサーバーに返されます。クォータ消費が停止すると、クライアントがクォータホールドタイマーを開始します。これは常にトラフィックの終了時に発生します。つまり、タイマーは各パケットの終了時に再開されます。これは、付与された時間クォータと付与されたボリュームクォータに等しく適用されます。タイマーは、CCR の送信時に停止され、CCA を受信すると、以前に使用された値または Quota-Holding-Time の新しい値（受信した場合）で再初期化されます。

または、この AVP が存在しない場合、クライアントのローカルに設定可能なデフォルト値が使用されます。Quota-Holding-Time の値がゼロの場合、このメカニズムは使用されません。
Quota-Validity-Time：サーバーは、クライアントへの問い合わせ中にオプションでクォータの有効時間を送信できます。Validity-Time AVP は、MSCC レベルに存在し、そのカテゴリに存在するクォータ全体に等しく適用されます。クォータは有効時間の終了時に無効になり、CCR-Update が、Used-Service-Units AVP およびレポートの理由（VALIDITY_TIME）とともにサーバーに送信されます。そのカテゴリに存在するクォータ全体が Quota-Validity-Time の有効期限時に無効になり、そのカテゴリのクォータを含む CCA-Update を受信するまで、そのカテゴリのトラフィックが、設定に応じて渡されるかドロップされます。

ゼロの Validity-Time は無効です。Validity-Time は相対的であり、絶対的ではありません。

Final-Reporting では、「SN-Remaining-Service-Unit」AVP がエンコードされます。

「SN-Remaining-Service-Unit」AVP の動作は「Used-Service-Unit」AVP から継承されます。この Final-Reporting は、現在組み込まれている Remaining-Service-Unit AVP にはありません。

ボリュームクォータ

サーバーは、サブスクライバにボリュームクォータを提供するために CC-Total-Octets AVP を送信します。DCCA は現在、アップリンクパケットとダウンリンクパケットに等しく適用される CC-Total-Octets AVP のみをサポートしています。アップリンクパケットとダウンリンクパケットの合計が許容されている CC-Total-Octets を超えると、クォータが使い果たされたと見なされます。

CC-Input-Octets と CC-Output-Octets のいずれかまたは両方が指定されている場合、指定に応じて、クォータは CC-Input-Octets と CC-Output-Octets のいずれかまたは両方に対してカウントされます。

重要	CC-Input-Octets と CC-Output-Octets に基づく使用量の制限は、このリリースではサポートされていません。

ユニットクォータ

サーバーは、パケットをユニットとしてカウントするために使用される CC-Service-Specific-Units クォータを送信できます。パケットあたりのユニット数は、設定可能なオプションです。

クォータの付与

Gy の実装では、CC-Total-Octets AVP が存在するときは常に、アップリンクとダウンリンクの両方にボリュームクォータが付与されていることが前提となっています。

Granted-Service-Unit にデータが含まれていない場合、Gy はこれを無効な CCA として扱います。

値がゼロの場合、クォータは付与されなかったと見なされます。

この AVP にデータのないサブ AVP が含まれている場合は、無限クォータと見なされます。

QHT、QCT などのカテゴリに関連する追加パラメータは、有効なボリュームまたは時間の付与を受信した後にカテゴリに設定されます。

サブスクライバに対してデフォルトクォータが設定されている場合、サブスクライバトラフィックを受信すると、デフォルトクォータに対してカウントされます。デフォルトクォータは最初の要求にのみ適用され、セッションの途中に再付与されることはありません。サブスクライバが切断されて再接続されると、最初の要求に対してデフォルトのクォータが再度適用されます。

クォータの要求

特定のカテゴリタイプのクォータは、CCR で Requested-Service-Unit AVP を使用して要求できます。MSCC には、トラフィックのカテゴリに対応する Rating-Group AVP と、Requested-Service-Unit (RSU) AVP がデータなしで入力されます。

Requested-Service-Unit には、具体的な時間または量の付与を要求するために使用される CC AVP を含めることができます。Gy CLI を使用して、カテゴリタイプのクォータを要求できます。

または、CCR- I の特定のカテゴリに関してプリエンプティブにサーバーからクォータを要求することもできます。サーバーがクレジット制御応答を介してプリエンプティブクォータを許可すると、そのカテゴリのトラフィックがヒットした場合にのみクォータが使用されます。クォータは、CLI を使用して、クレジット制御サーバーからプリエンプティブに要求できます。

MSCC AVP は、サーバーの再試行時に CCR-I でスキップされます。対応するクォータの使用状況は、次の CCR-U（USU および RSU を含む MSCC AVP）で報告されます。

クォータの報告

クォータは、次のようなさまざまな理由でサーバーに報告されます。

Threshold
QHT の期限切れ
クォータ枯渇
評価条件の変更
強制再承認
有効期間の期限切れ
サーバーからのカテゴリインスタンスの終了中の最後

QHT および終了中の最後の場合を除き、上記では Requested-Service-Unit AVP が CCR に存在します。

サーバーにクォータ報告の理由を知らせるために、報告理由が CCR に存在します。理由がすべてのクォータに適用されるか、単一のクォータに適用されるかに応じて、Reporting-Reason AVP が MSCC レベルまたは Used Service Unit（USU）レベルのいずれかに配置されます。

これらの条件のいずれかが満たされると、Reporting-Reason で使用状況を報告する理由、およびトリガーの適切な値（場合に応じて）を示す Multiple-Services-Credit-Control AVP を含む CCR 更新がサーバーに送信されます。しきい値に達した場合でも、DCCA は引き続き、しきい値で定義されたクォータ量を使用できます。

その他すべての報告理由については、クライアントは残りのクォータを破棄し、このカテゴリに一致する以降のユーザートラフィックを破棄するか、ユーザートラフィックの通過を許可するか、設定に従ってトラフィックをバッファします。

Reporting-Reason がレーティング条件の変更である場合、Gy では、CCR の一部として Trigger Type AVP を配置し、報告および再承認要求の原因となったトリガーイベントを示す必要があります。

エンドユーザーサービス拒否の Reporting-Reason は、カテゴリがクレジット管理サーバーによってブラックリストに登録されている場合に発生します。この場合、値がゼロの場合でも、使用されているサービスユニットとともに CCR-U が送信されます。その特定のカテゴリについてサーバーからさらにクォータを受信すると、ブラックリストの登録は削除されます。

サブスクライバに対してデフォルトクォータが設定されている場合、料金設定グループ、または料金設定グループとサービス ID の組み合わせに対して、サブスクライバに対して受信した最初の GSU からデフォルトクォータの通信量が差し引かれます。

デフォルトクォータ処理

デフォルトクォータが 0 に設定されている場合、データは渡されたり報告されたりしません。
デフォルトクォータが設定されており、OCS がクォータで応答する前にデフォルトクォータが使い果たされない限り、トラフィックは通過します。初期デフォルトクォータが使用されると、割り当てられている初期クォータに照らしてカウントされます。割りてられているクォータが実際の使用量よりも少ない場合、実際の使用量が報告され、追加のクォータが要求されます。追加のクォータを使用できない場合、トラフィックは拒否されます。
OCS が応答でクォータを拒否する前にデフォルトクォータが使い果たされていない場合、 OCS 応答後にゲートウェイでトラフィックがブロックされます。この場合でも、ゲートウェイはデフォルトクォータの使用状況を CCR-U（FINAL）または CCR-T で報告します。
OCS が応答する前にデフォルトクォータが使い果たされ、OCS のデッド状態が宣言されていない場合（上記の使用例 1 の定義を参照）、OCS が応答するまでトラフィックはブロックされます。

しきい値（Thresholds）

Gy クライアントは、次のしきい値タイプをサポートしています。

Volume-Quota-Threshold
Time-Quota-Threshold
Units-Quota-Threshold

しきい値は常に、特定のクォータおよび特定のクォータタイプに関連付けられます。Multiple-Services-Credit-Control AVP では、Time-Quota-Threshold、Volume-Quota-Threshold、および Unit-Quota-Threshold は、オプションの AVP です。

これらは符号なしの数値で表され、時間クォータの単位は秒、ボリュームクォータの単位はオクテット、サービス固有クォータの単位はユニットです。クォータがしきい値に達すると、サーバーに対する追加のクォータの要求がトリガーされます。ユーザートラフィックのフローは、引き続き許可されます。ユーザーに有効なクォータがまだあるため、トラフィックの中断は発生しません。

Gy は、CCR-U を、1 つ以上の User-Service-Unit AVP で報告された使用状況、THRESHOLD に設定された Reporting-Reason、およびデータのない Requested-Service-Unit AVP を含む Multiple-Services-Credit-Control AVP とともに送信します。

複数のタイプのクォータがカテゴリに割り当てられており、それぞれに独自のしきい値が設定されている場合、いずれかのユニットタイプがそのしきい値に達すると、他のユニットタイプが消費されていなくても、しきい値に達したと見なされます。

ボリュームクォータを報告する場合、DCCA は常に、CC-Input-Octets AVP と CC-Output-Octets AVP をそれぞれ使用して、アップリンクとダウンリンクを別々に報告します。

Gy は、CCA で追加のクォータを受け取ると、CCR の送信以降にまだ消費されていないクォータを破棄します。そのため、現在消費可能なクォータの量は、新たに受け取った量から、CCR を最後に送信してから消費された可能性があるクォータを差し引いたものになります。

クォータの再承認の条件

クォータは、次のシナリオでサーバーから再承認/再要求されます。

しきい値に達した
クォータが枯渇した
有効期間の期限切れ
評価条件が変更された：
- セル ID の変更：GGSN と P-GW の導入にのみ適用されます。
- LAC の変更：GGSN および P-GW の導入にのみ適用されます。
- QoS の変更
- RAT の変更
- SGSN/サービングノードの変更：GGSN および P-GW の導入にのみ適用されます。

トラフィックフローの破棄、許可、バッファリング

Gy がサーバーからの CCA を待機している場合、その特定のタイプのトラフィックが Gy で発生する可能性があります。パケットに対して実行する必要がある動作は、設定によって決まります。設定に基づいて、トラフィックの通過が許可されるか、サーバーからの CCA を待機している間に破棄またはバッファリングされます。

この動作は、次の場合にクライアントからサーバーへのすべての問い合わせに適用されます。

その特定のカテゴリのクォータがない
そのカテゴリの有効性タイマーが期限切れ
そのカテゴリのクォータを使い果たした
サーバーからの強制再承認

ユーザートラフィックの許可や破棄に加えて、クォータが使い果たされた場合や、トラフィックをバッファするクォータがない場合に使用できるオプションがあります。これは通常、サーバーが追加のクォータを要求したが、有効なクォータ応答がサーバーから受信されなかった場合に発生します。この場合、ユーザートラフィックはバッファに格納され、サーバーから有効なクォータ応答を受信すると、バッファリングされたトラフィックのパススルーが許可されます。

時間クォータの消費手順

QCT がゼロ：QCT が非アクティブ化された場合、消費は実時間ベースです。パケットフローがない場合でも、消費は継続します。
QCT がアクティブ：QCT が CCA にある、またはセッションに対してローカルに設定されている場合、クォータの消費は最初のパケットの到着時にのみ開始されます。クォータは、最後のパケットの到着に QCT の時間を加えた時間まで通常どおり消費され、次のパケットの到着までは消費がパスされます。

問い合わせの途中に QCT 値が変更された場合、新しい QCT は CCA の受信時から有効になります。たとえば、QCT が CCA で非アクティブ化された場合、パケットフローがなくてもクォータの消費は通常どおり再開します。または、QCT が非アクティブからアクティブ化された場合、クォータの消費は、CCA 後の最初のパケット受信後のみに再開されます。
QHT がゼロ：QHT が非アクティブ化された場合、それ以上の使用がない（ボリュームクォータについて、かつ時間クォータの QCT を使用）場合において、ユーザーはクォータを無期限に保持します。QHT は CCA と次の CCR の間でアクティブになります。
QHT がゼロでない：QHT が CCA にある、またはセッションに対してローカルに設定されている場合、QHT のアイドル時間の後に、CCR-Update の送信とクォータ使用状況の報告により、クォータがサーバーに返されます。CCR-U を受信しても、サーバーはクォータを付与しません。QHT タイマーは、CCR の送信時に停止し、QHT が CCA にある場合にのみ再開されます。

QHT タイマーは、パケットが到着するたびにリセットされます。

エンベロープレポート

サーバーは、標準のクォータ管理に加えて、特定のアクティビティの開始時刻と終了時刻を示す付加的な詳細レポートが必要であると判断する場合があります。サーバーは、適切な値の Envelope-Reporting AVP を使用して CCA を送信することでこのレポートを制御します。DCCA クライアントは、コマンドを受信すると、Quota-Consumption-Time AVP によって制御される一定の期間トラフィックをモニターし、トラフィックが存在していた各 Quota-Consumption-Time の期限について、各期間を単一のエンベロープとしてレポートします。サーバーは、時間のみまたは時間とボリュームについて、エンベロープレポートを要求する可能性があります。クォータについてのサーバーへのレポートは、Envelope-Start-Time と Envelope-End-Time、および使用情報を使用して、Envelope AVP により制御されます。

クレジット制御要求

クレジット制御要求（CCR）は、クォータと承認を要求するためにクライアントからサーバーに送信されるメッセージです。CCR は、MIP セッション確立前と MIP セッション終了時に送信されます。より多くのクォータを要求するためにサービス提供中に送信できます。

クレジット制御要求 - 初期（CCR-I）
クレジット制御要求 - 更新（CCR-U）
クレジット制御要求 - 終了（CCR-T）
クレジット制御応答（CCA）
クレジット制御応答 - 初期（CCA-I）
クレジット制御応答 - 更新（CCA-U）

MSCC AVP が CCA-U に含まれていない場合は、無効な CCA として扱われ、セッションは終了します。
クレジット制御応答 - 終了（CCA-T）

保留中の更新があるときにコールがクリアされた場合、ゲートウェイは、CCA-U の着信またはタイムアウトの発生（どちらか早い方）を待ちます。

ICSR スイッチオーバー中の監査の失敗によりコールが終了した場合、DCCA は、Gy インターフェイスを介した CCR-T の生成を許可します。

次の図は、GGSN/P-GW/IPSG Gy 実装における単純なコール要求のコールフローを示しています。

図 3. GGSN/P-GW/IPSG の単純なコール要求の Gy コールフロー

次の図は、HA Gy 実装における単純なコール要求のコールフローを示しています。

Tx タイマーの有効期限切れの動作

タイマーは、CCR がシステムから送信されるたびに開始され、応答は Tx 時間内に到着する必要があります。タイムアウト値は、Diameter クレジット制御コンフィギュレーションモードで設定できます。

Tx 期間内に特定の CCR について Diameter サーバーからの応答がなく、代替サーバーが設定されている場合は、「Tw タイマーの有効期限切れの動作」で説明されているように、Tw の有効期限が切れた後に CCR が代替サーバーに送信されます。

また、これは、以前の要求の Credit-Control-Session-Failover AVP 値にも依存します。この AVP が存在し、FAILOVER_SUPPORTED にコード化されている場合は、クレジット制御メッセージストリームがセカンダリサーバーに移動されます（セカンダリサーバーが設定されている場合）。AVP 値が FAILOVER_NOT SUPPORTED である場合は、セカンダリサーバーが設定されていても、コールは、失敗するとドロップされます。

CCR-U が Gy インターフェイスを介して送信されると、コンテナは、CCA-U を正常に受信した後にのみキャッシュされます。Rf トリガーは、CCA-U メッセージを受信した後にのみ送信されます。

リダイレクト

Final-Unit-Indication AVP では、Final-Unit-Action が REDIRECT の場合や Redirect-Server AVP がコマンドレベルで存在する場合、リダイレクトが実行されます。

リダイレクトは、指定されたカテゴリのクォータ消費の最後に行われます。Gy は RSU や Rating-Group AVP なしで CCR 更新を送信するため、サーバーはこれ以上のクォータを割り当てません。

Final-Unit-Action AVP が RESTRICT_ACCESS の場合は、Restriction-Filter-Rule AVP または Filter-Id AVP の設定に従います。Gy は、使用されたクォータを付けて CCR 更新をサーバーに送信します。

トリガー

Diameter サーバーは、クライアントが特定のカテゴリを再承認する必要があるトリガーを提供できます。トリガーはローカルでも設定できますが、サーバーからの CCA に存在するトリガーがすべて優先されます。

重要	このリリースでは、Gy トリガーは HA ではサポートされません。

サポートされているトリガータイプは次のとおりです。

SGSN/サービングノードの変更
QoS の変更 - 任意
RAT の変更
LAC の変更
CellID の変更

トリガータイプで説明されている何らかのイベントが発生すると、クライアントはサーバーとの間でクォータの再承認を行います。レポートの理由は RATING_CONDITION_CHANGE に設定されます。

タリフ時間の変更

サーバーが料金変更メカニズムを適用する必要があることを示した場合は常に、料金変更の時点でアクティブ状態の各カテゴリインスタンスに料金変更メカニズムが適用されます。

デュアルクーポンの概念がサポートされています。このとき、サーバーはタリフ時間の変更を伴う 2 つのクォータを付与します。この場合、最初に付与されたサービスユニットが料金変更時間まで使用され、料金変更時間に達すると、その時点までの使用量が報告されます。追加の使用量は累積されず、2 番目に付与されたサービスユニットが使用されます。

サーバーが、自身が付与したクォータの有効時間内にタリフ変更が発生すると予想している場合、CCA に Tariff-Time-Change AVP を含めます。DCCA は使用量を報告しますが、2 つの Used-Service-Unit AVP を使用することで変更時間をまたぎます。1 つは Turiff-Change-Usage が UNIT_BEFORE_TARIF_CHANGE に設定され、もう 1 つは Tariff-Change-Usage が UNIT_AFTER_TARFF_CHANGE に設定されます。これはアプリケーションで使用されるユニットのタイプとは無関係です。使用量と時間クォータの両方がこの方法で報告されます。

タリフ時間の変更機能も同様に、Validity-Time AVP を使用して実行されます。Validity-Time は Tariff Time Change に設定され、クライアントが Validity-Time の失効時にクォータを再承認して取得します。これでは特定の時間にサーバーに対して数多くの再承認要求がトリガーされてしまうため、推奨されません。

クライアントへの応答メッセージの Tariff-Time-Usage AVP とTariff-Time-Change AVP は、Multiple-Services-Credit-Control で定義されたクォータがタリフ時間の変更前または後に使用されることを示します。2 つの個別のクォータの 1 つは Tariff-Time-Change の前、もう 1 つは Tariff-Time-Change の後に割り当てられます。これにより、通信事業者はユーザーに対して期間ごとに異なるクォータを割り当てることができます。この場合、DCCA は更新メッセージ内の使用前と使用後のカウントをサーバーに送信してはいけません。応答メッセージに Tariff-Time-Usage AVP がなく Tariff-Time-Change AVP が存在する場合、クォータは単一クォータメカニズムとして使用されます。クライアントは更新での使用前と使用後のクォータをサーバーに送信する必要があります。

重要	このリリースでは、Gy は UNIT_INDETERMINATE 値をサポートしていません。

StarOS 21.20.22 リリースでは、Tariff-Time-Change AVP のサポートが強化され、Tariff-Time-Change AVP が料金設定グループの Gy から受信された場合に、高速パスの継続的なトラフィックフローとユーザーのトラフィックレートが維持されるようになりました。

最終ユニット通知

Final-Unit-Indication AVP は、特定のクォータがサーバーからの最終クォータであり、AVP で指定された対応するアクションを実行する必要があることを示すために、サーバーからの CCA に存在する場合があります。

コマンドレベルでの最終ユニット通知

現在、Gy はコマンドレベルで FUI AVP をサポートしていません。この AVP がコマンドレベルで存在する場合は無視されます。FUI AVP がコマンドレベルで存在し、Final-Unit-Action AVP が TERMINATE に設定されている場合、Gy は USU AVP 内のすべてのクォータを使用して、クォータの期限切れ時に CCR-Terminate を送信します。

重要	コマンドレベルの FUI AVP は、終了アクションでのみサポートされています。

MSCC レベルでの最終ユニット通知

Final-Unit-Indication AVP が MSCC レベルで存在し、Final-Unit-Action AVP が TERMINATE に設定されている場合、割り当てられたクォータの期限切れ時に CCR 更新が送信され、終了したカテゴリの使用状況がレポートされます。

リダイレクションケースの詳細については、「リダイレクト」を参照してください。

クレジット制御障害の処理（CCFH）

CCFH AVP は、クライアントとサーバー間に任意のタイプの障害が発生した場合に何を行う必要があるかを定義します。CCFH 機能は設定で定義できますが、CCFH AVP が CCA に存在する場合は、それが優先されます。CCFH AVP は、さまざまな障害処理を柔軟に実施できます。

Gy は、次の障害処理オプションをサポートしています。

TERMINATE
CONTINUE
RETRY AND TERMINATE

フェールオーバーがサポートされている CCFH

セカンダリサーバーが設定されていて、CC-Session-Failover AVP が FAILOVER_SUPPORTED に設定されている場合は、次の動作が行われます。

終了：CCR-I でいずれかの Tx が期限切れになると、メッセージが破棄され、セッションが切断されます。CCR-Update および Terminate の場合、応答タイムアウト後にメッセージがセカンダリサーバーに送信され、セッションがセカンダリサーバーで続行されます。セカンダリサーバーにも障害が発生した場合、セッションは切断されます。
続行：いずれかの Tx が期限切れになると、応答タイムアウト後にメッセージがセカンダリサーバーに送信され、セッションがセカンダリサーバーで続行されます。セカンダリサーバーでも障害が発生した場合、セッションは確立されたままですが、クォータ管理は行われません。
再試行と終了：いずれかの Tx が期限切れになると、応答タイムアウト後にメッセージがセカンダリサーバーに送信されます。セカンダリサーバーにも障害が発生した場合、セッションは切断されます。

フェールオーバーがサポートされていない CCFH

セカンダリサーバーが設定されていて、CC-Session-Failover AVP が FAILOVER_NOT_SUPPORTED に設定されている場合は、次に示すように以下の動作が行われます。システムにセカンダリサーバーが設定されていない場合も同様です。

終了：いずれかの Tx の期限切れ時に、セッションは停止します。
続行：いずれかの Tx の有効期限が切れてもセッションは確立されたままですが、クォータ管理は行われません。
再試行と終了：いずれかの Tx の期限が切れると、セッションは停止します。

フェールオーバーのサポート

CC-Session-Failover AVP および Credit-Control-Failure-Handling（CCFH）AVP は、CCA-I の CC サーバーによって返される場合があり、フェールオーバー手順を管理するために DCCA によって使用されます。これらが CCA に存在する場合、システムにローカルで設定されているデフォルト値を上書きします。

CC-Session-Failover が FAILOVER_NOT_SUPPORTED に設定されている場合、CC セッションは Diameter 代替サーバーに移動されません。

CC-Session-Failover の値が FAILOVER_SUPPORTED に設定されている場合、Gy は要求が失敗したと見なすと、CC セッションを代替サーバーに移動しようとします。次に例を示します。

結果コード「DIAMETER_UNABLE_TO_DELIVER」、「DIAMETER_TOO_BUSY」、または「DIAMETER_LOOP_DETECTED」を受信した場合。
要求タイムアウトの有効期限が切れたとき。
サーバーがクライアントに直接接続されている場合に、DWA を受信せずに Tw が期限切れになったとき。

CCFH は障害時のクライアントの動作を決定します。Tx タイマーが期限切れになると、CCFH 値に基づいて次のアクションが実行されます。

CONTINUE：中断（遅延応答）に関係なく、関連するカテゴリの MIP セッションとユーザートラフィックの続行を許可します。他のカテゴリのクォータ管理は影響を受けないことに注意してください。
TERMINATE：MIP セッションを終了します。これは、すべてのカテゴリに影響を及ぼします。
RETRY_AND_TERMINATE：中断（遅延応答）に関係なく、関連するカテゴリの MIP セッションとユーザートラフィックの続行を許可します。クライアントは送信失敗の状態を確認すると、CCR の送信を再試行します。これも失敗すると、MIP セッションは終了します。

フェールオーバーアクションが試行された後も、引き続き送信失敗や一時的なエラーが発生する場合は、CCFH アクションに応じて、次のアクションが実行されます。

CONTINUE：MIP セッションの続行を許可します。
TERMINATE：MIP セッションを終了します。
RETRY_AND_TERMINATE：MIP セッションを終了します。

リカバリメカニズム

DCCA は、セッションマネージャに障害が発生した場合にデータを大量に失うことなくセッションを回復するために使用されるリカバリメカニズムをサポートしています。定期的な間隔で、また更新などの重要なイベントの発生時に、Gy データが継続的にチェックされます。

重要	DCCA は、ICSR チェックポイントおよびリカバリに関して最大 3 つのベアラー（デフォルトを含む）をサポートします。DCCA で 4 つ以上のベアラーが設定されている場合は、すべてのベアラーについて、チェックポイントがアクティブからスタンバイへと発生します。ただし、リカバリ時には、最初の 3 つのベアラーだけが回復され、残りは、リソースを消費するメモリに残ります。

リカバリメカニズムの詳細については、『System Administration Guide』を参照してください。

エラーメカニズム

サポートされているエラーメカニズムは以下のとおりです。

サポートされていない AVP

「M」ビットが設定されたサーバーからのサポートされていないすべての AVP は無視されます。

サーバーからの応答が無効

サーバーからの応答が無効な場合、CCFH の設定によって Gy アクションが決まります。

continue の場合、MIP セッションコンテキストは Gy によってさらに制御されることなく続行されます。
terminate および retry-and-terminate の場合、MIP セッションは終了し、CCR-T が Diameter サーバーに送信されます。

結果コードの動作

DIAMETER_RATING_FAILED：このコードを受信すると、Gy は、そのカテゴリのすべてのトラフィックを破棄し、サーバーからのクォータを要求しなくなります。このコードは MSCC レベルでサポートされており、コマンドレベルではサポートされていません。
DIAMETER_END_USER_SERVICE_DENIED：このコードを受信すると、Gy は該当するカテゴリを一時的にブラックリストに登録し、以降のトラフィックではサーバーからの新しいクォータが要求されます。このコードは MSCC レベルでサポートされており、コマンドレベルではサポートされていません。
DIAMETER_CREDIT_LIMIT_REACHED：このコードを受信すると、Gy は、該当するカテゴリのすべてのトラフィックを破棄し、設定された時間待機します。その後、同じカテゴリのトラフィックが発生した場合は、サーバーからのクォータを要求します。このコードは MSCC レベルでサポートされており、コマンドレベルではサポートされていません。
DIAMETER_CREDIT_CONTROL_NOT_APPLICABLE：このコードを受信すると、Gy はセッションの確立を許可しますが、クォータ管理は行われません。このコードは、コマンドレベルでのみサポートされており、MSCC レベルではサポートされていません。
DIAMETER_USER_UNKNOWN：このコードを受信すると、DCCA はクレジット制御セッションの確立を許可せず、セッションは終了します。この結果コードは、コマンドレベルでのみサポートされており、MSCC レベルではサポートされません。

他のすべての持続的/一時的な障害の場合、Gy アクションは CCFH の設定によって異なります。

サポートされる AVP

Gy 機能では、次の AVP がサポートされています。

RFC 4006 で規定されている、サポートされている Diameter クレジット制御 AVP
- CC-Input-Octets（AVP コード：412）：
  
  Gy は、この AVP を USU でのみサポートしています。
- CC-Output-Octets（AVP コード：414）：
  
  Gy は、この AVP を USU でのみサポートしています。
- CC-Request-Number（AVP コード：415）
- CC-Request-Type（AVP コード：416）：
  
  Gy は現在、EVENT_REQUEST 値をサポートしていません。
- CC-Service-Specific-Units（AVP コード：417）
- CC-Session-Failover（AVP コード：418）
- CC-Time（AVP コード：420）：
  
  Gy は、RSU ではこの AVP をサポートしていません。
- CC-Total-Octets（AVP コード：421）：
  
  Gy は、RSU ではこの AVP をサポートしていません。
- Credit-Control-Failure-Handling（AVP コード：427）
- Final-Unit-Action（AVP コード：449）：
  
  Multiple Services-Credit-Control に分類された AVP レベルでサポートされます。コマンドレベルではサポートされません。
- Last-Unit-Indication（AVP コード：430）：
  
  Multiple-Services-Credit-Control に分類された AVP レベルでは完全にサポートされ、コマンドレベルでは部分的に（TERMINATE）サポートされます。
- Granted-Service-Unit（AVP コード：431）
- Multiple-Services-Credit-Control（AVP コード：456）
- Multiple-Services-Indicator（AVP コード：455）
- Rating-Group（AVP コード：432）
- Redirect-Address-Type（AVP コード：433）：
  
  Gy は現在、URL（2）の値のみをサポートしています。
- Redirect-Server（AVP コード：434）
- Redirect-Server-Address（AVP コード：435）
- Requested-Service-Unit（AVP コード：437）
- Result-Code（AVP コード：268）
- Service-Context-Id（AVP コード：461）
- Service-Identifier（AVP コード：439）
- Subscription-Id（AVP コード：443）
- Subscription-Id-Data（AVP コード：444）
- Subscription-Id-Type（AVP Code：450）
- Talf-Change-Usage（AVP コード：452）：
  
  Gy は UNIT_INDETERMINATE（2）値をサポートしていません。
- Talf-Time-Change（AVP コード：451）
- Used-Service-Unit（AVP コード：446）：
  
  Gy は、すべての AVP について、最後の CCA-U からの増分カウントのみを送信します。
- User-Equipment-Info（AVP コード：458）
- User-Equipment-Info-Type（AVP コード：459）：
  
  Gy は現在、IMEISV 値のみをサポートしています。
  
  Cisco GGSN と P-GW は、デフォルトで IMEISV をサポートしています。
- User-Equipment-Info-Value（AVP コード：460）
- Validity-Time（AVP コード：448）
3GPP TS 32.299 で規定されている、サポートされている 3GPP 固有の AVP
- 3GPP-Charging-Characteristics（AVP コード：13）
- 3GPP-Charging-Id（AVP コード：2）
- 3GPP-GGSN-MCC-MNC（AVP コード：9）
- 3GPP-GPRS-QoS-Negotiated-Profile（AVP コード：5）
- 3GPP-IMSI-MCC-MNC（AVP コード：8）
- 3GPP-NSAPI（AVP コード：10）
- 3GPP-PDP-Type（AVP コード：3）
- 3GPP-RAT-Type（AVP コード：21）
- 3GPP-Selection-Mode（AVP コード：12）
- 3GPP-Session-Stop-Indicator（AVP コード：11）
- 3GPP-SGSN-MCC-MNC（AVP コード：18）
- 3GPP-User-Location-Info（AVP コード：22）
- Base-Time-Interval（AVP コード：1265）
- Charging-Rule-Base-Name（AVP コード：1004）
- Envelope（AVP コード：1266）
- Envelope-End-Time（AVP コード：1267）
- Envelope-Reporting（AVP コード：1268）
- Envelope-Start-Time（AVP コード：1269）
- GGSN-Address（AVP コード：847）
- Offline-Charging（AVP コード：1278）
- PDP-Address（AVP コード：1227）
- PDP-Context-Type（AVP コード：1247）
  
  この AVP は CCR-I にのみ存在します。
- PS-Information（AVP コード：874）
- Quota-Consumption-Time（AVP コード：881）：
  
  このオプション AVP は、CCA にのみ存在します。
- Quota-Holding-Time（AVP コード：871）：
  
  このオプション AVP は、CCA コマンドにのみ存在します。これは、Multiple-Services-Credit-Control AVP に含まれています。これは、付与された時間クォータと付与されたボリュームクォータに等しく適用されます。
- Reporting-Reason（AVP コード：872）：
  
  Gy は現在、POOL_EXHAUSTED（8）値をサポートしていません。現在サポートされていないクレジットプーリングの場合に使用されます。
- Service-Information（AVP コード：873）：
  
  PS 情報のみサポートされています。
- SGSN-Address（AVP コード：1228）
- Time-Quota-Mechanism（AVP コード：1270）：
  
  Gy サーバーは、時間クォータを付与するときに、この AVP を Multiple-Services-Credit-Control AVP に含めることができます。
- Time-Quota-Threshold（AVP コード：868）
- Time-Quota-Type（AVP コード：1271）
- Triger（AVP コード：1264）
- Trigger-Type（AVP コード：870）
- Unit-Quota-Threshold（AVP コード：1226）
- Volume-Quota-Threshold（AVP コード：869）
3GPP TS 32.299 V8.1.0 で規定されている、サポートされている Diameter AVP
- Auth-Application-Id（AVP コード：258）
- Destination-Host（AVP コード：293）
- Destination-Realm（AVP コード：283）
- Disconnect-Cause（AVP コード：273）
- Error-Message（AVP コード：281）
- Event-Timestamp（AVP コード：55）
- Failed-AVP（AVP コード：279）
- Multiple-Services-Credit-Control（AVP コード：456）
- Origin-Host（AVP コード：264）
- Origin-Realm（AVP コード：296）
- Origin-State-Id（AVP コード：278）
- Redirect-Host（AVP コード：292）
- Redirect-Host-Usage（AVP コード：261）
- Redirect-Max-Cache-Time（AVP コード：262）
- Rating-Group（AVP コード：432）
- Result-Code（AVP コード：268）
- Route-Record（AVP コード：282）
- Session-Id（AVP コード：263）
- Service-Context-Id（AVP コード：461）
- Service-Identifier（AVP コード：439）
- Supported-Vendor-Id（AVP コード：265）
- Termination-Cause（AVP コード：295）
- Used-Service-Unit（AVP コード：446）
- User-Name（AVP コード：1）

サポートされていない AVP

この項では、サポートされていない AVP を示します。

RFC 4006 で指定されている、サポート対象外のクレジット制御 AVP：
- CC-Correlation-Id
- CC-Money
- CC-Sub-Session-Id
- CC-Unit-Type（AVP コード：454）
- Check-Balance-Result
- Cost-Information（AVP コード：423）
- Cost-Unit（AVP コード：445）
- Credit-Control
- Currency-Code（AVP コード：425）
- Direct-Debiting-Failure-Handling（AVP コード：428）
- Exponent（AVP コード：429）
- G-S-U-Pool-Identifier（AVP コード：453）
- G-S-U-Pool-Reference（AVP コード：457）
- Requested-Action（AVP コード：436）
- Service-Parameter-Info（AVP コード：440）
- Service-Parameter-Type（AVP コード：441）
- Service-Parameter-Value（AVP コード：442）
- Unit-Value（AVP コード：424）
- Value-Digits（AVP コード：447）
3GPP TS 32.299 V8.1.0 で指定されている、サポート対象外の Diameter AVP：
- Acct-Application-Id（AVP コード：259）
- Error-Reporting-Host（AVP コード：294）
- Experimental-Result（AVP コード：297）
- Experimental-Result-Code（AVP コード：298）
- Proxy-Host
- Proxy-Info
- Proxy-State
3GPP TS 32.299 V8.1.0 で指定されている、サポート対象外の 3GPP 固有 AVP：
- 3GPP-CAMEL-Charging-Info（AVP コード：24）
- 3GPP-MS-TimeZone（AVP コード：23）
- 3GPP-PDSN-MCC-MNC
- Authorised-QoS
- Access-Network-Information
- Adaptations
- Additional-Content-Information
- Additional-Type-Information
- Address-Data
- Address-Domain
- Addressee-Type
- Address-Type
- AF-Correlation-Information
- Alternate-Charged-Party-Address
- Application-provided-Called-Party-Address
- Application-Server
- Application-Server-Information
- Applic-ID
- Associated-URI
- Aux-Applic-Info
- Bearer-Service
- Called-Asserted-Identity
- Called-Party-Address
- Calling-Party-Address
- Cause-Code
- Charged-Party
- Class-Identifier
- Content-Class
- Content-Disposition
- Content-Length
- Content-Size
- Content-Type
- Data-Coding-Scheme
- Deferred-Location-Event-Type
- Delivery-Report-Requested
- Destination-Interface
- Domain-Name
- DRM-Content
- Early-Media-Description
- イベント
- Event-Type
- Expires
- File-Repair-Supported
- IM-Information
- IMS-Charging-Identifier（ICID）
- IMS-Communication-Service-Identifier
- IMS-Information
- Incoming-Trunk-Group-ID
- Interface-Id
- Interface-Port
- Interface-Text
- Interface-Type
- Inter-Operator-Identifier
- LCS-APN
- LCS-Client-Dialed-By-MS
- LCS-Client-External-ID
- LCS-Client-ID
- LCS-Client-Name
- LCS-Client-Type
- LCS-Data-Coding-Scheme
- LCS-Format-Indicator
- LCS-Information
- LCS-Name-String
- LCS-Requestor-ID
- LCS-Requestor-ID-String
- Location-Estimate
- Location-Estimate-Type
- Location-Type
- Low-Balance-Indication
- MBMS-Information
- MBMS-User-Service-Type
- Media-Initiator-Flag
- Media-Initiator-Party
- Message-Body
- Message-Class
- メッセージ ID
- メッセージサイズ（Message-Size）
- Message-Type
- MMBox-Storage-Requested
- MM-Content-Type
- MMS-Information
- Node-Functionality
- Number-Of-Participants
- Number-Of-Received-Talk-Bursts
- Number-Of-Talk-Bursts
- Originating-IOI
- Originator
- Originator-Address
- Originator-Interface
- Originator-SCCP-Address
- Outgoing-Trunk-Group-ID
- Participant-Access-Priority
- Participants-Group
- Participants-Involved
- PDG-Address
- PDG-Charging-Id
- PoC-Change-Condition
- PoC-Change-Time
- PoC-Controlling-Address
- PoC-Group-Name
- PoC-Information
- PoC-Server-Role
- PoC-Session-Id
- PoC-Session-Initialtion-Type
- PoC-Session-Type
- PoC-User-Role
- PoC-User-Role-IDs
- PoC-User-Role-info-Units
- Positioning-Data
- 優先順位
- PS-Append-Free-Format-Data（AVP コード：867）：
  
  PCEF/GW は、オンライン課金セッションに対して PS フリー形式のデータが保存されていない場合、この AVP を無視します。
- PS-Free-Format-Data（AVP コード：866）
- PS-Furnish-Charging-Information（AVP コード：865）
- RAI（AVP コード：909）
- Read-Reply-Report-Requested
- Received-Talk-Burst-Time
- Received-Talk-Burst-Volume
- Recipient-Address
- Recipient-SCCP-Address
- Refund-Information
- Remaining-Balance
- Reply-Applic-ID
- Reply-Path-Requested
- Requested-Party-Address
- Role-of-node
- SDP-Answer-Timestamp
- SDP-Media-Component
- SDP-Media-Description
- SDP-Media-Name
- SDP-Offer-Timestamp
- SDP-Session-Description
- SDP-TimeStamp
- Served-Party-IP-Address
- Service-Generic-Information
- Service-ID
- Service-Specific-Data
- Service-Specific-Info
- Service-Specific-Type
- SIP-Method
- SIP-Request-Timestamp
- SIP-Response-Timestamp
- SM-Discharge-Time
- SM-Message-Type
- SM-Protocol-Id
- SMSC-Address
- SMS-Information
- SMS-Node
- SM-Status
- SM-User-Data-Header
- Submission-Time
- Talk-Burst-Exchange
- Talk-Burst-Time
- Talk-Burst-Volume
- Terminating-IOI
- Time-Stamps
- Token-Text
- Trunk-Group-ID
- Type-Number
- User-Participating-Type
- User-Session-ID
- WAG-Address
- WAG-PLMN-Id
- WLAN-Information
- WLAN-Radio-Container
- WLAN-Session-Id
- WLAN-Technology
- WLAN-UE-Local-IPAddress

PLMN およびタイムゾーンレポート

オンライン課金を実装すると、OCS が PCEF に対してロケーション固有のサブスクライバ情報レポートを要求する場合があります。特定のサブスクライバタイプの場合は、サブスクライバがロケーション、タイムゾーン、サービスネットワークを変更すると、PLMN、タイムゾーン、URI などのサブスクライバ情報が Gy インターフェイスを介して送信されるため、正確なオンライン課金サービスを提供できます。このような情報は、時間および使用量ベースのレポートとは別に報告できます。

PLMN およびタイムゾーンレポート機能が有効になっており、次の条件が満たされている場合、Gx からのトリガーに基づくロケーションイベントレポートがサポートされます。

クレジット制御が有効になっているルールベースに課金アクションがないため、または Gy セッションの開始が遅延したため、セッションベースの Gy が開始されません。
PLMN およびタイムゾーンレポート機能は、クレジット制御グループ内で有効になるか、Gx から受信したトリガーの使用によって有効になります。

セッションベースの Gy の開始に失敗した場合、または設定やネットワークの問題が原因でセッションがオフラインになった場合、イベントベースの Gy セッションは開始されません。

重要	障害処理はイベントベースの Gy ではサポートされないことに注意してください。

イベントベースの Gy では、複数のイベントを個別かつ同時に報告できますが、これは現在サポートされていません。以前に報告されたイベントの CCA-Event（CCA-E）の待機中にイベントが発生した場合、新しいイベントはキューに送られ、CCA-E を受信した場合かメッセージがタイムアウトになった場合にのみ報告されます。

PLMN およびタイムゾーンレポート機能を有効にするために、PCRF は CCA のコマンドレベルで Trigger AVP（Trigger Type 1、Trigger Type 2）を送信します。

イベントベースの Gy セッションは、次のシナリオで終了します。

ベアラー/サブスクライバの終了（サブスクライバレベル Gy）。
セッションベースの Gy セッションの開始（遅延セッション開始）。
CCR-E トランザクションが完了すると、それ以降のイベントは報告されません。

この機能の設定方法については、Gy インターフェイス機能を使用する製品のアドミニストレーションガイドの「Gy Interface Support」の章を参照してください。

セッションベース Gy とイベントベース Gy 間のインターワーキング

セッションベース Gy モードとイベントベース Gy モードの両方がアクティブである場合、セッションベース Gy モードが優先されます。つまり、対応するトリガーが有効であれば、すべてのイベントが CCR-U 経由でレポートされます。イベントベース Gy モードは、セッションベース Gy が無効になっており、その存続期間中に該当するセッションに対して以前にアクティブにされたことがない場合にのみアクティブになります。

OCS 到達不能障害処理機能

OCS がダウンした場合、または使用できなくなった場合に対処するには、OCS 到達不能障害処理機能が必要です。この機能は、Gy でのポジティブ想定としても示されます。

OCS は、次のシナリオでは使用不可または到達不能と見なされます。

PCEF が CCR-U または CCR-I メッセージを送信したものの、指定されたタイムアウト時間までに応答が受信されない
Diameter ウォッチドッグ要求が現在の RDR に対してタイムアウトし、TCP 接続状態がダウンとマークされる
Diameter コマンドレベルのエラーコードが CCA で受信される
PCEF が CCR-T の送信を正常に検証できないときに、ユーザーが切断しているため、PCEF によって暫定クォータが割り当てられない

CLI コマンド servers-unreachable behavior-triggers initial-request { result-code { any-error | result-code [ to end-result-code ] } } を使用してエラー結果コードを設定し、サーバー到達不能モードをトリガーできます。同じ設定を更新要求にも適用できます。この CLI コマンドの詳細については、『Command Line Interface Reference』の「Credit Control Configuration Mode Commands」の章 [英語] を参照してください。ただし、CLI コマンド no servers-unreachable behavior-triggers { initial-request | update-request } result-code { any-error | result-code [ to end-result-code ] } が設定されている場合は、ハードコードエラーコードのデフォルトセットが適用されます。

デフォルトセットは次のとおりです。

UNABLE_TO_DELIVER 3002
UNABLE_TOO_BUSY 3004
LOOP_DETECTED 3005
ELECTION_LOST 4003
恒久的なエラー 5001 ～ 5999（5002、5003、5031 を除く）。

既存の障害処理メカニズムが強化され、トランスポート接続の障害が原因で OCS に到達不能になった場合や、Diameter 要求メッセージへの応答が遅いため OCS に到達不能であると思われる場合に、暫定ボリュームや暫定時間の事前設定された量をサブスクライバが参照できるようになりました。

この機能の目的は、OCS の障害が発生した場合に Gy ベースのデータセッションをサポートすることです。Diameter クライアントは、ユーザーのデータセッションを一定のクォータの間継続できるようにし、その後、OCS サーバーを再試行して通常の機能の復旧を試みます。この機能により、既存の障害処理メカニズムの精度が向上します。

この機能の導入により、サービス障害中の Gy レポートがサポートされます。OCS の障害が発生した場合、一時的な時間クォータやボリュームクォータがユーザーに割り当てられ、障害期間中に使用されます。

OCS のサービスが再開されると、GW は使用されたすべてのクォータを OCS に報告し、通常の Gy レポートを続行します。

各 DCCA サービスでは、次のオプションに CLI 制御を使用できます。

暫定クォータボリューム（バイト単位）およびクォータ時間（秒）。両方の値が同時に適用され（一緒に設定されている場合）、クォータ時間またはクォータボリュームのいずれかが使い果たされると、Diameter クライアントは OCS を再試行します。
セッションに一時的なクォータを割り当てることができる回数を制限するオプション。ユーザーがこの量を超過すると、セッションは終了するか後払いに切り替えられます。

クォータ値は DCCA サービス設定の一部であり、その DCCA サービスを使用するすべてのサブスクライバに適用されます。一時クォータはボリューム（バイト）や時間（秒）で指定され、両方のクォータ追跡メカニズムを個別にまたは同時に適用できます。

障害処理シナリオで使用するために設定された暫定合計クォータまたは時間をユーザーが消費すると、GW は OCS サーバーを再試行して、機能が復旧されたかどうかを判断します。サービスが復旧された場合、クォータの割り当てと追跡は、標準の使用状況レポート手順に従って続行されます。障害中に使用されたデータが OCS に報告されます。

OCS サービスが復旧されていない場合、GW は設定された量のクォータや時間をユーザーに再割り当てします。OCS がオンラインに戻ると、GW は集積されたすべての使用済みデータを OCS に報告します。複数の再試行と暫定的な割り当てが発生した場合、GW はすべての割り当て期間中に使用されたクォータを報告します。このサイクルは、OCS サービスが正常に復旧されるか、またはクォータ割り当てが最大数に達するまで続行されます。

OCS の到達不能な CLI コマンドのサポートは、Diameter クレジット制御コンフィギュレーションモードで追加されます。

P-GW/XGW/GGSN の場合、この動作は、PCRF によってオンライン課金が有効になっているすべての APN およびサブスクライバに適用されます。HA の場合、この動作は AAA によってオンライン課金が有効になっているすべてのユーザーに適用されます。設定が DCCA サービスに適用されます。

次の拡張機能は、ポジティブ想定 Gy 機能の一部として導入されます。

エラーコード処理ごとに、ポジティブ想定モードに入るように設定可能
5002 エラーを受信したグレースフルセッションの再起動

重要	グレースフルセッション再起動機能はお客様固有のものであることに注意してください。詳細については、シスコのアカウント担当者にお問い合わせください。

エラーコード処理ごとに設定可能

この機能により、お客様は、CLI コマンド「servers-unreachable behavior-triggers 」を使用してエラー結果コードを設定できます。設定すると、CCR 初期メッセージと CCR 更新メッセージに対して、実行中にポジティブ想定モードの開始がトリガーされます。CCR 終了メッセージは現在サポートされていません。

CLI コマンドを使用して、3xxx ～ 5xxx の範囲にあるエラー結果コードを指定できます。この機能は、エラー結果コードに対してポジティブ想定モードがトリガーされる際のより柔軟で精度の高い方法を実現するために導入されています。

グレースフルセッション再起動

5002 エラーコード受信後のグレースフルセッション再起動は、ポジティブ想定状態の間にサーバーが再試行した CCR-U メッセージでサポートされます。また、その時点から CCA-I を受信するまでにサーバーが CCR-U を再試行した後、未報告の使用状況は、同じ使用状況で CCR-U をトリガーすることですぐに報告されます。

重要	グレースフルセッション再起動機能はお客様固有のものであることに注意してください。詳細については、シスコのアカウント担当者にお問い合わせください。

5002 の CCA-U がサーバーから受信されると、保留中の更新はすべて中止されます。また、未報告の使用状況が保留中である場合にのみ、セッションの再起動直後に CCR-U がトリガーされます。

重要	サーバーが 5002 エラー結果コードで応答した場合、要求された料金設定グループに対して付与されたサービスユニットはこの応答に含まれません。

この機能のサポートで導入されたコマンドの詳細については、『Command Line Interface Reference』の「Credit Control Configuration Mode Commands」の章 [英語] を参照してください。

Gy の OCS 障害レポートの強化

機能説明

Cisco-Event-Trigger-Type AVP が CCA-I、CCA-U、または値が CREDIT_CONTROL_FAILURE（5）の RAR メッセージの PCRF によってインストールされる場合、シスコイベントグループ化 AVP が P-GW によって、OCS 障害コードの正確な値を含む CCR-U メッセージで PCRF に送信されます。このトリガーは、Gy で障害が発生した場合にのみ送信され、設定（クレジット制御障害の処理）に基づいて「続行」アクションが実行され、Gy セッションがオフライン状態に移行します。

この機能強化により、範囲ではなく正確な障害コードが PCRF に報告されます。たとえば、シスコイベントトリガータイプが CREDIT_CONTROL_FAILURE（5）で、 CCA-U の OCS 障害コードが 3002 の場合、PCRF に送信される CCR-U では、シスコ CC 障害タイプ（グループ化された AVP シスコイベントの一部）が値 3002 で送信されます。

CDR のサーバー到達不能フィールドの追加

機能説明

オンライン課金システム（OCS）がネガティブメッセージを送信すると、ポリシー/課金適用機能（PCEF）と OCS 間のトランスポート接続が失敗します。接続エラーにより、セッションの確立が失敗し、サブスクライバはサービスを使用できなくなります。接続エラーに対処するために、次の手順が使用されます。

障害処理（FH）：既存の FH メカニズムは、Diameter セッションのフェールオーバーが発生した場合に動作し、システムは接続またはメッセージレベルのエラーが発生したときに、セッションを続行してオフラインに切り替えるか、セッションを終了するかを選択できます。
サーバー到達不能（SU）：この障害処理メカニズムにより、障害時の手順をより詳細に制御できます。このメカニズムは、メッセージレベルおよび接続レベル（トランスポート）の障害後のセッションに加えて、OCS からの応答が遅い場合に使用されます。また、一定の期間セッションを続行するか、クォータを使い切ってから終了するオプションも提供されます。

設定されたサーバーと暫定クォータ（通信量と時間）を使用するために、セッションがオフラインに変換される前、または終了する前に SU が再試行します。

gtpp attribute servers-unreachable が gtpp グループの下で設定され、SU 機能が有効になっている場合、serversUnreachableContinue または serversUnreachableTerminate を使用して、暫定または最終 CDR で次のプロセスフローが可能になります。

SU 障害がトリガーされる。
CDR が生成される。
コール制御プロファイルの SU 設定に基づいて、生成された CDR に serversUnreachableContinue フィールドまたは serversUnreachableTerminate フィールドが含まれる。

次の表で、CDR 内の serversUnreachable フィールドについて説明します。

表 1. CDR の ServersUnreachable フィールド
フィールド名	Description	タグ	Format	Size	ASN1 コード
serversUnreachableContinue	サーバー到達不能手順が実行されると、要素が発生します。	256	ブール値	1	0x9f8200
serversUnreachableTerminate	サーバー到達不能手順が実行されると、要素が発生します。	257	ブール値	1	0x9f8201

表 2. ACS 設定内のサーバー到達不能 CDR フィールド
SU の設定	暫定状態時に SU が検出するフィールド	暫定状態の終了後に SU が検出するフィールド	SU が検出しないフィールド（Gy との通常のコール）
server-unreachable initial-request terminate	CDR フィールドが別にトリガーされた場合、SU terminate フィールドは含まれない（暫定 CDR であるため）。 SU continue が FALSE 最終 CDR で SU Terminate が FALSE	SU continue が FALSE 最終 CDR で SU Terminate が TRUE	SU continue が FALSE 最終 CDR で SU Terminate が FALSE
server-unreachable update-request terminate	CDR フィールドが別にトリガーされた場合、SU terminate フィールドは含まれない（暫定 CDR であるため）。 SU continue が False 最終 CDR で SU Terminate が False	暫定 CDR と最終 CDRの両方で SU continue が True 最終 CDR で SU Terminate が False	SU continue が False 最終 CDR で SU Terminate が False
server-unreachable initial-request continue	SU continue が False 最終 CDR で SU Terminate が False	暫定 CDR と最終 CDRの両方で SU continue が True 最終 CDR で SU Terminate が False	SU continue が False 最終 CDR で SU Terminate が False
server-unreachable update-request continue	SU continue が False 最終 CDR で SU Terminate が False	暫定 CDR と最終 CDRの両方で SU continue が True 最終 CDR で SU Terminate が False	SU continue が False 最終 CDR で SU Terminate が False

詳細については、『SAEGW Administration Guide』の Gy に関する章を参照してください。

CDR へのサーバー到達不能フィールドの追加

次の設定コマンドを使用して、CDR にサーバー到達不能フィールドを追加します。

configure 
   context context_name 
      gtpp group group_name 
         gtpp attribute servers-unreachable   
         end

注：

gtpp attribute servers-unreachable：このオプションを指定すると、CDR にオプションのフィールド ServersUnreachablesContinue または ServersUnreachablesTerminate が追加されます。

モニタリングおよびトラブルシューティング

ここでは、show コマンドを使用してこの機能を監視およびトラブルシューティングする方法について説明します。

コマンドと出力の表示

このセクションでは、この機能のサポートにおける show コマンドとその出力について説明します。

show gtpp group name <group name>


フィールド	説明
到達不能なサーバーが存在します	サーバーが到達不能な要素の存在を示す「Yes」または「No」を表示します。

バックプレッシャ処理

Diameter ベース（Diabase）はアウトバウンドストリームを維持します。アプリケーションがソケットにメッセージを書き込むとき、それらのメッセージのメッセージハンドルがアウトバウンドストリームに保存されます。対応する要求の応答を受信した場合にのみ、保存されているメッセージハンドルがアウトバウンドストリームから削除されます。ASR 5500 はサーバーから受信した応答に基づいてメッセージトランザクションにレート制限を適用するために、アウトバウンドストリームに保存されるメッセージ数の制限を維持します。これは、「max-outstanding <>」CLI を使用して行います（デフォルト値は 256 です）。アプリケーションによって作成されたメッセージの数が未処理の最大数を超えると、Diabase はアプリケーションに「バックプレッシャ」通知を送信し、Diabase から輻輳解消の通知を受信するまで待機してから、再試行するように伝えます。

サーバーからの応答を受信すると、対応する要求メッセージハンドルがアウトバウンドストリームから削除され、アプリケーションが別のメッセージを書き込むためのスロットが作成されます。このスロットの可用性を伝えるために、輻輳解消通知が登録済みのアプリケーションに送信されます。アプリケーションはすべてのセッションをループし、保留中の送信トリガーを処理します。

アプリケーションはシステム内のセッションをループするときに、ソートされた順序でセッションをトラバースし、保留中の CCR-Initial、CCR-Terminate、CCR-Update を送信する必要があるかどうかを各セッションでチェックします。最初のセッションでアウトバンドストリームに入るスロットが取得されると、メッセージがストリームに書き込まれます。これで、スロットは満杯状態に戻り、再び未処理数の上限に達します。したがって、残りのセッションは引き続きバックプレッシャ状態のままになります。

Credit-Control-Initial や Credit-Control-Terminate などのバックプレッシャ状態の要求は、セッションの作成や終了と関係があるため、Credit-Control-Update よりも高い優先順位が与えられます。そのため、DCCA には輻輳解消通知に加えて、定期的にメッセージの送信を試みる内部タイマーがあります。したがって、重度のバックプレッシャ状態の場合、CCR-I や CCR-T が送信される確率は CCR-U よりも高くなります。

Gy バックプレッシャの強化

この機能により、メッセージ（バックプレッシャリスト）の作成中にバックプレッシャとなった DCCA セッションのリストを維持でき、現在のポーリング手順が不要になります。また、バックプレッシャされるすべてのタイプのメッセージ（CCR-I、CCR-U、CCR-T、CCR-E）に対して単一のキューが維持されます。メッセージはキューから FIFO の順番に送信されます。

バックプレッシャキューからのセッションを処理した後、DCCA はピアの輻輳ステータスをチェックし、ピアの未処理メッセージのキューに空のスロットがある場合にのみ続行します。

最大未処理数が少なく、ネットワークが輻輳している場合、CPU 使用率は非常に高くなります。

（最大未処理数に達したときに）バックプレッシャにトリガーされた CCR メッセージに関連付けられているすべての DCCA セッションは、ACS マネージャインスタンス（クレジット制御）レベルごとに維持されるバックプレッシャリストに入れられます。

このリストには、入れられるセッション数に関する設定可能な特定の制限はありません。これは、サブスクライバまたは DCCA セッションの数に依存する固有の制限がすでに存在するためです。

この新しい個別のバックプレッシャリストを使用すると、バックプレッシャが高い場合に CPU 使用率が低下します。

GTP ベースの S2a/S2b の Gy サポート

P-GW での Wi-Fi 統合では、GTP ベースの S2a/S2b に Gy サポートが提供されます。この実装は、標準の Rel-11 非 3GPP アクセス仕様 32.399: S5-120748 S5-131017 S5-143090 に準拠しています。

この機能拡張の一部として、次の AVP の変更が導入されました。

Serving-Node-Type AVP の新しい列挙値として TWAN が追加されました。
新しい Diameter AVP「TWAN-User-Location-Info」が追加されました。これはグループ化された AVP で、Trusted WLAN Access Network（TWAN）内の UE ロケーション（アクセスポイントの BSSID および SSID）が含まれます。

TWAN AVP は、3GPP リリース 11 でのみ有効で、標準の Gy ディクショナリにのみ追加されます。つまり、CLI コマンド「diameter update-dictionary-avps 3gpp-rel11 」が設定されている場合にのみ、TWAN AVP が CCR-I/CCR-U/CCR-T メッセージに含まれます。

ルールと RG 間の関連付けの変更による OOC/ROC の生成

既存の Gy の実装により、同じルールの PCRF に対するクレジット不足/クレジット再割り当て（ROC）レポートの重複が防止されます。異なる料金設定グループを使用した同じルールでのサブスクライバスロットリングは OOC イベントで機能しません。この問題を解決するため、次の設定の導入を考慮しました。

ある料金設定グループのクレジットが不足すると、その料金設定グループに現在関連付けられているすべてのルールに OOC が送信されます。この動作は、そのルールがすでに OOC になっているかどうかに関係なく実行されます。同様に、OOC 状態になった後に料金設定グループがクォータを取得すると、現在その料金設定グループに現在関連付けられているすべてのルールに ROC が送信されます。この動作は、そのルールがすでに ROC になっているかどうかに関係なく実行されます。

ルールレベルのステータスビットは、同様のバックツーバック OOC/ROC イベントを回避するために使用されなくなりました。今後、OOC/ROC イベントのトリガーは、MSCC の状態とトリガーにのみ依存するようになります。

お客様がルールと RG の関連付けを変更したり、オーバーライド機能を使用したりすると、Gx での OOC/ROC イベントが増加する可能性があります。

CCR のスタティックルールベース

APN とサブスクライバには 1 つのルールベースを適用できますが、CCR メッセージを介して異なるまたは同じルールベースを常に OCS に渡すようスタティックルールベースを設定できます。

CCR AVP「Charging-Rule-Base-Name」で、APN テンプレートまたはサブスクライバテンプレートに存在するルールベース名を上書きおよび変更するために、新しい CLI コマンド「charging-rulebase-name rulebase_name 」がクレジット制御（CC）グループに導入されました。CC グループに設定されたルールベース値は、CCR 経由で OCS に送信されます。この CLI コマンドが設定されていない場合は、APN テンプレートまたはサブスクライバテンプレートから取得されたルールベースが OCS に送信されます。

CC グループに設定されたルールベースの値は、すべての CCR（I/U/T）メッセージで送信されます。これは、セッション中に CC グループのルールベース値が変更されると、これが反映されるのは次の CCR メッセージになることを意味します。

この機能を CLI コマンドでアクティブ化すれば、OCS システムでの企業ごとのサービスの追加や削除といった、サービスの設定に伴う複雑さが軽減されます。

CC ベース選択的 Gy セッション制御

このセクションでは、サブスクライバの課金特性（CC）プロファイルに基づいた選択的 Gy セッション制御機能の概要と導入について説明します。

このセクションでは、この機能に関する次のトピックについて説明します。

機能説明
CC ベース選択的 Gy セッション制御の設定
選択的 Gy セッション制御機能のモニタリングと障害対応

機能説明

GGSN サービスでは、特定の課金特性（CC）値をプリペイドまたは後払いとして設定できる機能が利用できます。今回、この機能が P-GW サービスに拡張されました。

受信した CC 値に基づいて Gy セッションを有効化または無効化するために、APN 設定が拡張され、CC 値ごとに追加のクレジット制御グループおよびプリペイド禁止値を設定できるようになりました。

cc profile cc-profile-index prepaid prohibited CLI コマンドは、クレジット制御ベースの課金を無効にする CC 値を設定するために使用されます。この APN を使用する P-GW、GGSN、SAEGW サービスサブスクライバセッションは、この設定を使用して、OCS への Gy メッセージのトリガーを停止できます。

UE は課金特性値を提供し、アクティブなサブスクライバは APN を介して接続されます。CC インデックスマッピングは、APN で設定されている対応する CC グループおよびプリペイド禁止値に対して行われます。一致すると、Gy セッションは OCS に対して有効または無効になります。

セッションコントローラは、AAA マネージャの APN 設定を保存および更新します。セッションのセットアップ中に、セッションマネージャはセッション認証要求で受信した CC 値を入力し、それを AAA マネージャに送信します。AAA マネージャは、これをローカルに保存された APN 設定と照合し、セッションに必要なクレジット制御グループまたはプリペイド禁止設定を選択します。次に、セッションマネージャは AAA マネージャから受信したこのクレジット制御グループまたはプリペイド禁止情報を ACS マネージャに渡します。

ローカル認証（セッションセットアップ要求）が完了すると、一致する課金特性を持つクレジット制御グループが選択され、使用されます。クレジット制御グループの選択で一致する課金特性設定が見つからない場合は、APN のデフォルトのクレジット制御グループが選択されます。

特定の CC がプリペイドとして設定されている場合、この CC とのセッションは Gy 接続をトリガーしません。セッションの存続期間中の CC の変更は無視されます。

CC ベース Gy セッション制御機能は、セッション確立中に GTP 認証要求を介して受信した CC 値にのみ適用されます。セッションのセットアップ後に AAA または PCRF を介して更新された CC 値により、すでに選択されているクレジット制御グループが変更されることはありません。セッションのセットアップ後にクレジット制御グループが選択されると、この機能は適用されなくなります。

Diameter エラーコードとカウンタ

SaMOG は、さまざまな StarOS プラットフォーム（ASR5500/ASR5700）上の P-GW LBO モジュールを介して、SaMOG（Web 認証）サービスのすべてのトランザクションと Diameter インターフェイスの Diameter エラーコードカウンタをサポートしています。

以下の結果コード固有カウンタは、Gy インターフェイスで OCS（オンライン課金システム）から受信した応答に使用できます。DCCA（Diameter クレジット制御アプリケーション）は、Gy インターフェイスで使用されるプロトコルです。

表 3. 結果コード固有カウンタ
エラーカテゴリ	結果コード	結果コード値
一時的な障害（4XXX）	DIAMETER_END_USER_SERVICE_DENIED	4010
一時的な障害（4XXX）	DIAMETER_CREDIT_LIMIT_REACHED	4012
恒久的なエラー（5XXX）	DIAMETER_RATING_FAILED	5031

他の機能との関係

この機能は、GGSN サービスによって CC プロファイル設定が有効になっている場合にも使用できます。CC プロファイルが APN サービスと GGSN サービスで設定されている場合、サービスに関係なく、一致する CC プロファイルのプリペイド禁止設定が適用されます。

制限事項

この機能には次の制限があります。

1 つの課金特性値を 1 つの APN 内の 1 つの credit-control-group/prepaid-prohibited 設定にのみマッピングできます。
課金特性に基づく OCS の選択は、セッションのセットアップ中にのみ可能です。credit-control-group が選択されると（セッションセットアップ後）、この機能は適用されません。

CC ベース選択的 Gy セッション制御の設定

ここでは、サブスクライバの CC プロファイルに基づいて Gy セッション制御機能を設定するためのコマンドについて説明します。

CC（Charging Characteristic）値の設定

課金特性（Charging Characteristic）の値を後払い/前払いとして設定して、OCS への Gy セッションを無効/有効にするために、次のコマンドが使用されます。

configure 
   context context_name 
      apn apn_name 
         cc-profile { cc_profile_index | any } { prepaid-prohibited | credit-control-group cc_group_name } 
         end

注：

cc_profile_index ：CC プロファイルインデックスを指定します。cc_profile_index は、0 ～ 15 までの整数にする必要があります。
any ：このキーワードは、オーバーライドされない任意の cc-profile インデックスに適用されます。このキーワードは、CC プロファイル値の特定の設定に対して最も低い優先度を持ちます。したがって、 any キーワードを設定しても、APN の他の特定の設定がオーバーライドされることはありません。
prepaid-prohibited ：設定されたプロファイルインデックスのプリペイド Gy セッションを無効にします。
cc_group_name ：クレジット制御グループの名前を 1 ～ 63 文字の英数字文字列で指定します。
no cc-profile cc_profile_index ：このコマンドは、設定されている CC プロファイルインデックス値に関係なく、「any」の cc-profile 動作にフォールバックします。

選択的 Gy セッション制御設定の確認

選択的 Gy セッション制御機能の設定を表示または確認するには、Exec モードで次のコマンドを使用します。

show configuration

選択的 Gy セッション制御機能のモニタリングと障害対応

ここでは、選択的 Gy セッション制御機能のサポートにおける show コマンドおよびその出力について説明します。

show active-charging sessions

show active-charging sessions [ callid | imsi | msisdn ] コマンド出力の一部として表示される「クレジット制御」フィールドにより、ユーザーは、クレジット制御状態のオンライン課金対応セッションが「オン」かどうか、プリペイド禁止セッションが「オフ」かどうかを判別し、サブスクライバセッションをモニターできます。

ルールベースのクレジット制御グループの設定

このセクションでは、サブスクライバのルールベースに基づくクレジット制御（CC）グループ選択の概要と実装について説明します。

このセクションでは、この機能に関する次のトピックについて説明します。

機能説明
ルールベースのクレジット制御グループの設定
ルールベースでの CC グループ選択のモニタリングとトラブルシューティング

機能説明

この機能は、ポジティブ想定シナリオでのさまざまなタイプのサブスクライバの動作をカスタマイズするために導入されました。このカスタマイズは、PCRF によって動的に選択されたルールベースに基づいて、ユーザーが目的のクレジット制御（CC）グループを指定できるようにすることによって実現されます。

通常、ポジティブ想定の動作は、CC グループ内で設定されます。今回、この CC グループ選択機能が、ルールベース設定に拡張されました。

この機能は、IMSA が使用されず、AAA サーバーが認証中に CC グループを送信できず、すべてのサブスクライバに 1 つの APN/サブスクライバプロファイルのみが使用されたシナリオで明示的に必要になります。このような状況において、この機能は、ルールベース内にプレミアム CC グループを提供して、タイプに基づいたサブスクライバに対するプレミアム処理を可能にすることを目的としています。

この機能により、ルールベース設定内に新しい設定可能なオプションが導入され、サブスクライバセッションのセットアップ中にルールベースが選択されるたびに、ユーザーが目的の CC グループを指定できるようになります。この設定された CC グループは、サブスクライバプロファイル/APN 内で設定済みの CC グループを上書きします（それらより高い優先順位を持つ）。AAA または PCRF サーバーが CC-Group AVP を送信すると、AVP を通じて定義された CC グループ値によって、ルールベースで設定された CC グループが上書きされます。

この機能を有効にすると、この設定により、ルールベース名と CC グループ間の関連付けを指定できるようになり、プレミアムサブスクライバの接続時にプレミアムルールベースとプレミアム CC グループが選択されるようになります。

重要	セッション中の設定変更は、システム内の既存のサブスクライバには影響しません。この設定変更は、新しいセッションにのみ影響します。

この新しい設定オプションの実装により、使用可能なクォータに基づいて、サブスクライバのさまざまなタイプのポジティブ想定の動作が有効になります。これにより、プレミアム顧客の優先処理が実現されます。

CC グループの選択の優先順位は、次のように定義されます。

PCRF で提供される CC グループ
AAA で提供される CC グループ
ルールベースで設定された CC グループ
サブスクライバプロファイル/APN で選択された CC グループ
デフォルトのクレジット制御グループ

重要	この機能は、認証プロセス中に AAA サーバーが CC グループを送信するオプションがある場合は使用しないでください。認証中に、AAA サーバーが CC グループを送信し、選択されたルールベースに CC グループが定義されている場合は、ルールベースで定義された CC グループが、そのセッション用に選択されます。

制限事項

この機能には制限や制約事項はありません。ただし、CC グループ選択の優先順位に留意することが重要です。

ルールベースのクレジット制御グループの設定

ここでは、サブスクライバのルールベースに基づいてクレジット制御グループを設定するためのコマンドについて説明します。

クレジット制御グループの定義

PCRF によって選択されたルールベースの使用時に、該当するクレジット制御グループ名を設定するには、次のコマンドを使用します。

configure 
require active-charging 
active-charging service service_name 
   rulebase rulebase_name 
      credit-control-group cc_group_name 
      end

cc_group_name ：クレジット制御グループの名前を 1 ～ 63 文字の英数字文字列で指定します。
no credit-control-group ：以前に設定した CC グループをルールベースの設定から削除します。これがデフォルトの設定です。
この CLI 設定は、セッションのセットアップ中にのみ適用されます。CC グループのセッション中の変更は許可されません。
これはオプションの CLI 設定であり、カスタマイズされたポジティブ想定の動作がサブスクライバに対して必要な場合にのみ使用されます。
この CLI コマンドが設定されている場合、CC グループは優先順位に基づいて選択されます。つまり、ルールベースで定義された CC グループは、サブスクライバ/APN プロファイルで指定された CC グループの値よりも優先されます。
CC グループの設定がルールベースに存在しない場合は、デフォルトのサブスクライバ/APN プロファイルの設定が適用されます。

クレジット制御グループ設定の確認

ルールベースの CC グループの設定を表示または確認するには、Exec モードで次のコマンドを使用します。

show configuration verbose

ルールベースでの CC グループ選択のモニタリングとトラブルシューティング

この項では、この機能のサポートにおける show コマンドまたはその出力について説明します。

show active-charging sessions full

この show CLI コマンドの出力には、セッションで選択されているクレジット制御グループが表示されます。出力の詳細は、この機能の問題の検証とトラブルシューティングに役立ちます。

show configuration errors コマンドを入力します。

この show CLI では、ルールベース内で設定されているクレジット制御グループが定義されていない場合、エラーが表示されます。

ユーザーが [support record] セクションを指定していない場合は、show configuration verbose

このコマンドでは、ルールベースに指定されている「credit-control-group」オプションが表示されます。トラブルシューティングのために、show configuration verbose と show subscribers full の出力を、「Radius Access-Accept」を含む monitor-protocol の出力とともにキャプチャしてください。

QoS 変更シナリオのための複合 CCR-U トリガー

EPS ベアラー QoS および APN AMBR のデフォルト値が変更されると、P-GW は、アクセス側に、デフォルトベアラーおよび APN AMBR を 1 つのメッセージで変更するための更新要求を送信します。P-GW は、それに応じて APN AMBR とデフォルトのベアラー QoS を適用し、この変更条件に対して Gy に CCR-U を 1 つだけ送信します。

重要	この動作変更は、P-GW コールにのみ適用されます。この変更は、Rf/CDR レコードおよび GGSN/P-GW eHRPD コールには影響しません。

また、この動作は、複数のベアラー更新要求がアクセス側に送信される分割 TFT の場合（QoS + APN AMBR + TFT）には適用されないことに注意してください。

障害後のオフライン Gy セッションの再アクティブ化

この項では、Diameter クレジット制御アプリケーションでの障害の検出時にオフライン Gy セッションを再度有効にする機能について説明します。

この項では、次のトピックについて取り上げます。

機能説明

この機能により、PCRF からの指示に基づいて、オフライン Gy セッションをオンライン課金に戻すためのメカニズムが導入されました。PCRF から Online AVP を受信すると、ゲートウェイは Gy セッションを確立します。

セッションがオフラインとしてマークされると Gy がアクティブ化される設定は存在しませんでした。Diameter クレジット制御アプリケーションで障害が検出されると、設定済みのクレジット制御障害処理（CCFH）アクションが実行されました。Gy セッションが CCFH 続行アクションを実行すると、サブスクライバセッションを再試行/再有効化することはできませんでした。

Charging-Rule-Definition の Online AVP は、CCFH 続行アクションが実行された後、オフライン Gy セッションを有効にするための PCRF からのトリガー/指示と見なされます。PCRF からのコマンドレベルでの Online AVP は、オフライン Gy セッションを有効にするトリガーとは見なされません。3GPP 29.212（リリース 12.12.0）に基づき、Online AVP（1009）は、Charging-Rule-Definition グループ AVP（1003）内のオプションの AVP です。

制限事項と制約事項

ここでは、この機能の制限事項と設定上の制約事項について説明します。

この機能は、ボリュームクォータメカニズムのみに限定されます。Quota-Validity-Time（QVT）タイマーおよび Quota-Hold-Time（QHT）タイマーに対して特別な処理は行われません。Gy セッションがオフラインになった後に復帰した場合、これらのタイマーは開始されません。次の CCA-U が OCS からの情報を提供する場合にのみタイマーが開始されます。
Gy セッションがオンラインとマークされている場合、CDR のクローズは不要です。これは請求システムによって処理されます。
この機能は、イベントベースのクレジット制御セッションには拡張されません。
MSCC レベルの障害が原因で CCFH アクションが実行されると、既存の動作が保持され、次の動作が起こります。
- CCFH 続行：Gy で課金せずにカテゴリ（MSCC）を続行します。これは MSCC に適用されます（セッション全体ではありません）。show active-charging sessions full コマンドの出力の MSCC ステータスには「Nocharge」と表示されます。
- CCFH 終了/リトライと終了：ベアラーが終了されます。
MSCC レベルで結果コード 4011（DIAMETER_CREDIT_CONTROL_NOT_APPLICABLE）を受信すると、カテゴリは無料とマークされ、このカテゴリに対するそれ以上のアカウンティングは実行されません。この結果コードがコマンドレベルで受信されると、Gy セッションがオフラインになります。オフライン Gy セッションは PCRF の Online AVP を使用して再度オンラインにでき、アカウンティングは正常に再開されます（このセッションの OCS で CCR-U が認識されます）。
CCFH 継続が設定されている場合に CCR-I 障害が発生すると、次の動作が起こります。
- Diabase エラー：Diabase エラー（TCP 接続の切断）が発生すると、Gy セッションがオフラインとマークされ、セッション状態が維持されます（セッション ID が作成されます）。Gy セッションを再度有効にすると、新しい CCR-I が（データを待たずに）すぐに送信されます。
- 応答タイムアウト：応答タイムアウトが発生したときに、CCR-I がセッションセットアップで送信され、セッションセットアップタイムアウトが応答タイムアウトの前に発生した場合、ベアラー自体は終了します。diameter send-crri traffic-start 設定は、CCR-I タイムアウトがベアラーの作成に影響を与えないようにするために、オプションで使用できます。
- Gy セッションが CCR-I 応答のタイムアウトによりオフラインになり、Gy セッションがオンラインとしてマークされている場合、同じセッション ID が使用されます。
- CCR-I エラー応答が原因で Gy セッションがオフラインになった場合、セッション情報は削除されます（次に使用されるセッション ID は異なります）。
オンラインルールが既存のベアラーに移動または関連付けられたりするような、ベアラー間（LTE から Wi-Fi またはその逆）でのルール移動が発生した場合、Gy セッションのステータスは変更されません。
オフライン Gy セッションをオンラインにマークするトリガーは、課金ルール定義の PCRF から受信した Online AVP にのみ基づきます。

障害後のオフライン Gy セッションの設定

次の項では、オフライン Gy セッションを再度有効にするための設定コマンドについて説明します。

オフライン Gy セッションの再有効化

障害の後にオフライン Gy セッションを再度有効にするには、次の設定を使用します。

configure 
   active-charging service service_name 
      credit-control 
         [ no ] offline-session re-enable 
         end

注：

offline-session re-enable が設定され、PCRF が、「Online」 AVP 値が 1 に設定されたルールをインストールまたは変更すると、オフライン DCCA はオンラインとマークされます。
デフォルトの設定は、no offline-session re-enable です。この機能はデフォルトで無効になっており、無効になっている場合、show configuration verbose コマンドでのみこの設定が表示されます。

設定の確認

オフライン/オンライン状態遷移のタイムスタンプを確認するには、次のコマンドを使用します。

show active-charging sessions full

障害後のオフライン Gy セッションの監視と障害対応

この項では、この機能のサポートにおける show コマンドまたはその出力について説明します。

この機能に関連する障害をトラブルシュートするには、次の操作を実行する必要があります。

show active-charging sessions full コマンドの CLI 出力を確認できます。「Last State Change Time」フィールドは、セッションがオフラインになったタイムスタンプおよびオンラインに戻ったタイムスタンプを示します。
monitor subscriber next-call コマンドからのメッセージを「verbosity 3」で有効にすると、サブスクライバで発生するメッセージ交換を分析できます。
「acsmgr」および「debug」レベルのログを有効にして、さらに詳しくデバッグできます。

show active-charging sessions full

次の新しいフィールドがこのコマンドの出力に追加され、状態遷移のタイムスタンプが表示されるようになりました。

Last State Change Time：
- オフライン/オンライン：オフラインのタイムスタンプは、Gy セッションがオフラインになると更新されます。オンラインのタイムスタンプは、セッションがオンラインに戻ると更新されます。

AVP の抑制

この機能により、「Gx、Gy、および CDR の MVNO 情報のサポート」機能が強化されます。

機能説明

この機能により、「Gx、Gy、および CDR の MVNO 情報のサポート」機能が強化されます。SAEGW はこれらの AVP を PCRF から受信するたびに、OCS と CDR に Gy メッセージで MVNO-Reseller-ID および MVNO-Subclass-ID AVP を送信します。

この機能強化により、この動作が CLI で制御されるようになり、Gy インターフェイスで送信される AVP を抑制する新しい CLI コマンドが導入されました。

以前の動作：Reseller-id および subclass-id AVP は、ATT ディクショナリの PCRF から同じものを受信すると、Gy で送信されていました。

新しい動作：新しい CLI コマンド suppress_avp が追加されました。これにより、Reseller-id と subclass-id AVP を抑制できます。

コマンドの変更

suppress_avp

AVP を抑制するために、クレジット制御グループコンフィギュレーションモードに新しい CLI コマンドが追加されました。この CLI コマンドを設定すると、MVNO-subclass-id AVP および MVNO-Reseller-Id AVP が抑制されます。


   configure 
      active-charging service <acs_service_name>  
         credit-control group <group_name>  
            diameter suppress-avp reseller-id subclass-id 
            [ no | default ] diameter suppress-avp reseller-id subclass-id 
      end

注：

no: AVP の抑制を無効にします。PCRF が MVNO-subclassid AVP および MVNO-Reseller-id AVP を Gx インターフェイスで送信するたびに、同じものが Gy メッセージで送信されます。
default: デフォルト設定を設定します。デフォルトでは AVP は抑制されません。PCRF が MVNO-subclassid AVP および MVNO-Reseller-id AVP を Gx インターフェイスで送信するたびに、同じものが Gy メッセージで送信されます。
suppress-avp: MVNO-subclassid AVP および MVNO-Reseller-id AVP の両方を抑制します。
reseller-id: MVNO-Reseller-Id AVP を抑制します。
subclass-id: MVNO-Sub-Class-Id AVP を抑制します。

パフォーマンス指標の変更

show configuration

このコマンドは、以下の出力を表示するように変更されました。


credit-control group default 
      diameter origin endpoint sundar 
      diameter peer-select peer minid1 secondary-peer minid2 
      diameter session failover 
      diameter dictionary dcca-custom32 
      failure-handling initial-request continue 
      failure-handling update-request continue 
      diameter dynamic-rules request-quota on-traffic-match 
      diameter suppress-avp reseller-id subclass-id

Gy インターフェイスのサポートの設定

Gy インターフェイスのサポートを設定するには、次の手順を実行します。

手順

ステップ 1

このアドミニストレーションガイドの説明に従って、コアネットワークサービスを設定します。

ステップ 2

セクション「GGSN/P-GW/IPSG Gy インターフェイスサポートの設定」および「HA/PDSN Gy インターフェイスのサポートの設定」の説明に従って、Gy インターフェイスのサポートを設定します。

ステップ 3

「PLMN およびタイムゾーンレポートの設定」の説明に従って、イベントベースの Gy のサポートを設定します。

ステップ 4

オプションです。「サーバー到達不能機能の設定」の説明に従って、OCS 到達不能障害処理機能または Gy でのポジティブ想定機能を設定します。

ステップ 5

オプションです。「CCR のスタティックルールベースの設定」の説明に従って、CCR のスタティックルールベースを設定します。

ステップ 6

オプションです。「GTP ベースの S2a/S2b の Gy の設定」の説明に従って、GTP ベースの S2a/S2b の Gy を設定します。

ステップ 7

EXEC モードコマンド save configuration を使用して、フラッシュメモリ、外部メモリデバイスや、ネットワークの場所に設定を保存します。構成ファイルを検証して保存する方法の詳細については、『System Administration Guide』および『Command Line Interface Reference』を参照してください。

重要	この項の設定例で使用されているコマンドは、最もよく使用されているコマンドまたはその可能性の高いコマンド、および/またはキーワードオプションが提示される範囲で、基本機能を提供します。多くの場合は、他のオプションのコマンドやキーワードオプションを使用できます。すべてのコマンドの詳細については、『Command Line Interface Reference』を参照してください。

GGSN/P-GW/IPSG Gy インターフェイスサポートの設定

GGSN/P-GW/IPSG の標準 Gy インターフェイスサポートを設定するには、次の設定を使用します。

configure 
     context <context_name> 
          diameter endpoint <endpoint_name> 
               origin realm <realm> 
               origin host <diameter_host> address <ip_address> 
               peer <peer> realm <realm> address <ip_address> 
               exit 
          exit 
     active-charging service <ecs_service_name> 
          credit-control [ group <cc_group_name> ] 
               diameter origin endpoint <endpoint_name> 
               diameter peer-select peer <peer> realm <realm> 
               diameter pending-timeout <timeout_period> 
               diameter session failover 
               diameter dictionary <dictionary> 
               failure-handling initial-request continue 
               failure-handling update-request continue 
               failure-handling terminate-request continue 
               exit 
          exit 
     context <context_name> 
           apn <apn_name> 
               selection-mode sent-by-ms 
               ims-auth-service <service> 
               ip access-group <access_list_name> in 
               ip access-group <access_list_name> out 
               ip context-name <context_name> 
               active-charging rulebase <rulebase_name> 
               credit-control-group <cc_group_name> 
               end

注：

IP アクセスリストの設定の詳細については、『System Administration Guide』の「Access Control Lists」の章 [英語] を参照してください。
ECS ruledef 設定の詳細については、『Command Line Interface Reference』の「ACS Ruledef Configuration Mode Commands」の章 [英語] を参照してください。
ECS 課金アクション設定の詳細については、『Command Line Interface Reference』の「ACS Charging Action Configuration Mode Commands」の章 [英語] を参照してください。
ECS ルールベース設定の詳細については、『Command Line Interface Reference』の「ACS Rulebase Configuration Mode Commands」の章 [英語] を参照してください。

HA/PDSN Gy インターフェイスのサポートの設定

HA/PDSN Gy インターフェイスのサポートを設定するには、次の設定を使用します。

configure 
     context <context_name> 
          diameter endpoint <endpoint_name> 
               origin realm <realm> 
               origin host <diameter_host> address <ip_address> 
               peer <peer> realm <realm> address <ip_address> 
               exit 
          exit 
     active-charging service <ecs_service_name> 
          ruledef <ruledef_name> 
               ip any-match = TRUE 
               exit 
          charging-action <charging_action_name> 
               content-id <content_id> 
               cca charging credit rating-group <rating_group> 
               exit 
          rulebase <rulebase_name> 
               action priority <action_priority> ruledef <ruledef_name> charging-action <charging_action_name> 
               exit 
          credit-control [ group <cc_group_name> ] 
               diameter origin endpoint <endpoint_name> 
               diameter peer-select peer <peer> realm <realm> 
               diameter pending-timeout <timeout> 
               diameter session failover 
               diameter dictionary <dictionary> 
               failure-handling initial-request continue 
               failure-handling update-request continue 
               failure-handling terminate-request continue 
               pending-traffic-treatment noquota buffer 
               pending-traffic-treatment quota-exhausted buffer 
               exit 
          exit 
     context <context_name> 
          subscriber default 
               ip access-group <acl_name> in 
               ip access-group <acl_name> out 
               ip context-name <context_name> 
               active-charging rulebase <rulebase_name>

               credit-control-group <cc_group_name> 
               end

注：

IP アクセスリストの設定の詳細については、『System Administration Guide』の「Access Control Lists」の章 [英語] を参照してください。
ECS ruledef 設定の詳細については、『Command Line Interface Reference』の「ACS Ruledef Configuration Mode Commands」の章 [英語] を参照してください。
ECS 課金アクション設定の詳細については、『Command Line Interface Reference』の「ACS Charging Action Configuration Mode Commands」の章 [英語] を参照してください。
ECS ルールベース設定の詳細については、『Command Line Interface Reference』の「ACS Rulebase Configuration Mode Commands」の章 [英語] を参照してください。

PLMN およびタイムゾーンレポートの設定

PLMN およびタイムゾーンレポート機能を使用するには、APN またはサブスクライバの設定でクレジット制御グループを定義するか、デフォルトのクレジット制御グループが設定されている必要があります。次の CLI コマンドを使用して、PLMN およびタイムゾーンレポート機能を有効または無効にすることができます。

サブスクライバテンプレートを介して PLMN およびタイムゾーンレポートを有効にするには、次の設定を使用します。

configure 
     context <context_name> 
          subscriber name <subscriber_name> 
               dns primary <primary_ipaddress> 
               dns secondary <secondary_ipaddress> 
               ip access-group test in 
               ip access-group test out 
               ip context-name <context_name> 
               credit-control-client event-based-charging 
               active-charging rulebase <rulebase_name> 
               exit 
               end

注：

credit-control-client event-based-charging コマンドを使用して、PLMN およびタイムゾーンレポートを有効にする必要があります。

PLMN およびタイムゾーンレポート機能の設定に関する詳細については、『Command Line Interface Reference』を参照してください。

APN テンプレートを介して PLMN およびタイムゾーンレポートを有効にするには、次の設定を使用します。

configure 
     context <context_name> 
          apn <apn_name> 
               selection-mode sent-by-ms 
               accounting-mode none 
               ip access-group test in 
               ip access-group test out 
               ip context-name <context_name> 
               ip address pool name<pool_name> 
               credit-control-client event-based-charging 
               active-charging rulebase <rulebase_name> 
               exit 
               end

ディクショナリ、エンドポイントなどのイベントベースの Gy に必要な残りのパラメータは、クレジット制御グループから選択されます。

CLI コマンドを介してトリガーが設定され、さらに別のトリガーセットを Gx から受信するシナリオでは、Gx からのトリガーが優先されます。

サーバー到達不能機能の設定

サーバー到達不能機能では、障害処理動作を Diameter クレジット制御の設定で定義する必要があります。次の CLI コマンドを使用して、OCS 到達不能障害処理機能を有効または無効にすることができます。

OCS 到達不能障害処理機能を有効にするには、次の設定を使用します。

configure 
require active-charging  
         active-charging service <service_name> 
              credit-control  
                   servers-unreachable { initial-request | update-request } { continue | terminate }  [ { after-interim-volume <bytes> | after-interim-time <seconds> } +   server-retries <retry_count> ] 
                   servers-unreachable behavior-triggers { initial-request | update-request } transport-failure [ response-timeout | tx-expiry ] 
                   servers-unreachable behavior-triggers initial-request { result-code { any-error | result-code [ to end-result-code ] } } 
                   servers-unreachable behavior-triggers update-request { result-code { any-error | result-code [ to end-result-code ] } } 
                 end

重要	configure 、require active-charging 、active-charging service `<service_name>` 、および credit-control CLI コマンドを設定した後、設定を保存し、シャーシをリロードしてコマンドを有効にする必要があります。設定ファイルを保存してシャーシをリロードする方法については、使用している展開の『System Administration Guide』を参照してください。

注：

この CLI コマンド「servers-unreachable { initial-request | update-request } { continue | terminate } [ { after-interim-volume ... 」を使用すると、次の方法で interim-volume と interim-time を設定できます。
- after-interim-volume <bytes> 単独で server-retries が続く。
- after-interim-time <secs> 単独で server-retries が続く。
- after-interim-volume <bytes> after-interim-time <secs> に server-retries が続く。
この CLI コマンド「servers-unreachable behavior-triggers 」を使用して、Tx の有効期限切れまたは応答タイムアウトのいずれかでサーバー到達不能障害処理をトリガーします（この CLI は「failure-handling update-request continue retry-after-tx-expiry 」コマンドの retry-after-tx-expiry に似ています）。
この CLI コマンド「servers-unreachable behavior-triggers initial-request { result-code { any-error | result-code [ to end-result-code ] } } 」は、設定された Diameter エラー結果コードに基づいて、サーバー到達不能障害処理をトリガーするために使用されます。

この機能の設定に関する詳細については、『Command Line Interface Reference』[英語] を参照してください。

CCR のスタティックルールベースの設定

ルールベース名の静的設定を CCR メッセージを介して OCS に渡すことができるようにするには、次の設定を使用します。

configure 
    require active-charging 
    active-charging service service_name 
         credit-control group  ccgroup_name 
              charging-rulebase-name rulebase_name 
              no charging-rulebase-name 
              end

重要	configure 、require active-charging 、active-charging service `service_name` 、および credit-control group `ccgroup_name` CLI コマンドを設定した後、設定を保存してから、コマンドのシャーシをリロードして有効にします。設定ファイルを保存してシャーシをリロードする方法については、使用している展開の『System Administration Guide』を参照してください。

注：

デフォルトでは、APN/サブスクライバテンプレートから取得されたルールベースは、CCR メッセージを介して OCS に送信されます。

この機能の設定に関する詳細については、『Command Line Interface Reference』[英語] を参照してください。

GTP ベースの S2a/S2b の Gy の設定

P-GW で GTP ベースの S2a/S2b の Wi-Fi 統合に Gy サポートを提供するには、次の設定を使用します。

configure 
    require active-charging 
    active-charging service service_name 
         credit-control group  ccgroup_name 
              diameter update-dictionary-avps 3gpp-rel11 
              [  default | no ] diameter update-dictionary-avps 
              end

注：

3gpp-rel11 ：標準 Gy ディクショナリ内で 3GPP Rel. 11 固有の AVP のサポートを提供します。

統計情報の収集

ここでは、Gy 関連の統計および設定情報を収集する方法について説明します。

次の表では、最初の列に、収集する統計が示されており、2 つ目の列に、実行するアクションが示されています。


統計/情報	実行するアクション
ECS セッションの完全な統計。	show active-charging sessions full
アクティブ課金サービス（ACS）の詳細情報。	show active-charging service all
サービスに設定されているすべてのルール定義に関する情報。	show active-charging ruledef all
サービスに設定されているすべての課金アクションに関する情報。	show active-charging charging-action all
サービスに設定されているすべてのルールベースに関する情報。	show active-charging rulebase all
クレジット制御アプリケーション（DCCA）の統計。	show active-charging credit-control statistics
クレジット制御アプリケーション（DCCA）のセッションのステータス。	show active-charging credit-control session-states [ rulebase `<rulebase_name>` ] [ content-id `<content_id>` ]

P-GW StarOS リリース 21.28 アドミニストレーション ガイド

偏向のない言語

翻訳について

検索結果

章のタイトル： Gy インターフェイスのサポート

Gy インターフェイスのサポート

機能の概要と変更履歴

要約データ

マニュアルの変更履歴

はじめに

ライセンス要件

サポートされる標準

機能と用語

課金シナリオ

予約によるセッション課金

分散型ユニット決定と集中型レート設定

集中型ユニット決定と集中型レート設定

分散型ユニット決定と分散型レート設定

基本操作

再承認

しきい値ベースの再承認トリガー

終了アクション

Diameter 基本プロトコル

Diameter クレジット制御アプリケーション

クォータの動作

時間クォータ

ボリュームクォータ

ユニットクォータ

クォータの付与

クォータの要求

クォータの報告

デフォルトクォータ処理

しきい値（Thresholds）

クォータの再承認の条件

トラフィックフローの破棄、許可、バッファリング

時間クォータの消費手順

エンベロープレポート

クレジット制御要求

Tx タイマーの有効期限切れの動作

リダイレクト

トリガー

タリフ時間の変更

最終ユニット通知

コマンドレベルでの最終ユニット通知

MSCC レベルでの最終ユニット通知

クレジット制御障害の処理（CCFH）

フェールオーバーがサポートされている CCFH

フェールオーバーがサポートされていない CCFH

フェールオーバーのサポート

リカバリメカニズム

エラーメカニズム

サポートされていない AVP

サーバーからの応答が無効

結果コードの動作

サポートされる AVP

サポートされていない AVP

PLMN およびタイムゾーンレポート

セッションベース Gy とイベントベース Gy 間のインターワーキング

OCS 到達不能障害処理機能

Gy の OCS 障害レポートの強化

機能説明

CDR のサーバー到達不能フィールドの追加

機能説明

CDR へのサーバー到達不能フィールドの追加

モニタリングおよびトラブルシューティング

コマンドと出力の表示

show gtpp group name <group name>

バックプレッシャ処理

Gy バックプレッシャの強化

GTP ベースの S2a/S2b の Gy サポート

ルールと RG 間の関連付けの変更による OOC/ROC の生成

CCR のスタティックルールベース

CC ベース選択的 Gy セッション制御

機能説明

Diameter エラーコードとカウンタ

他の機能との関係

制限事項

CC ベース選択的 Gy セッション制御の設定

CC（Charging Characteristic）値の設定

選択的 Gy セッション制御設定の確認

P-GW StarOS リリース 21.28 アドミニストレーションガイド