ワイヤレス : Cisco ASR 5000 シリーズ

ASR5K の OCS 失敗解決のための失敗処理およびサーバ到達不能 メカニズムを設定して下さい

2016 年 10 月 27 日 - 機械翻訳について
その他のバージョン: PDFpdf | 英語版 (2016 年 4 月 21 日) | フィードバック

概要

この資料にオンライン貸出方式(OCS)で見つけられる問題を解決するために失敗処理(FH)を設定する方法をおよび Gy のサーバ到達不能(SU)メカニズム インターフェイスします記述されていますまたはポリシーおよび充満適用機能(PCEF)および OCS 間の接続に関して。 情報は集約されたサービス ルータ(ASR5K)で Cisco 5000 シリーズ動作する Home Agent (HA)、ゲートウェイ General Packet Radio Service (GPRS) サポート ノード(GGSN)、およびパケット データ ネットワーク ゲートウェイ(この資料に説明がある PGW)に適当機能性です。

Shashank Varshney によって貢献される、Cisco TAC エンジニア。

前提条件

要件

Cisco はシステム大会これらの必要条件 FH および SU メカニズムを使用するためことを推奨します:

  • 拡張 な充満サービス(ECS)は利用できます

  • HA、GGSN、または PGW の内で存在 する PCEF

  • diabase によって適切な直径接続があります

  • 直径クレジット制御アプリケーション(DCCA)は利用できます

使用するコンポーネント

この文書に記載されている情報は ASR5K のすべてのバージョンに基づいています。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。 このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。 ネットワークが稼働中の場合は、コマンドが及ぼす潜在的な影響を十分に理解しておく必要があります。

背景説明

PCEF は基礎プロトコルおよび DCCA として直径を使用する Gy インターフェイス上の OCS に接続されます。 これは PCEF と OCS 間のメッセージフローです:

  • 与信管理要求(CCR) –このメッセージは PCEF から OCS に送られます。 CCR メッセージには 3 つの型があります: 頭文字、アップデートおよび終端。

  • 与信管理返事(CCA) –このメッセージは CCR に応じて OCS から PCEF に送信 されます。 また CCA メッセージには 3 つの型があります: 頭文字、アップデートおよび終端。

  • 再許可要求(RAR) –このメッセージは OCS から PCEF にセッション再許可が必要となるとき送られます。

  • 再許可返事(RAA) –これは PCEF からの OCS へ RAR への応答です。

直径接続は PCEF と OCS の間でメッセージフローを有効に するために確立されます。 PCEF と OCS の間で OCS が否定的なメッセージを送信 するかもしれませんという可能性が転送接続失敗するかもしれませんありますまたはメッセージはサブスクライバ セッション確立で失敗を引き起こす場合があるタイムアウトかもしれました。 これはサービスの使用からサブスクライバを防ぐことができます。

これら二つのメカニズムはこの問題を解決するために使用することができます:

  • FH メカニズム

  • SU メカニズム

設定

このセクションはコンフィギュレーションを説明します FH および SU メカニズムをサポートするために必要となる。

ネットワーク図

この文書に記載されている情報はこのトポロジーを使用します:

Tx 終止

これは直径クレジット コントロール設定で設定可能の DCCA のためのアプリケーション レベル タイマーです。 値は 1 秒から 300 秒の間に及ぶことができます。

次に例を示します。

[local]host_name(config-dcca)# diameter pending-timeout <value>

応答タイムアウト

これは diabase タイムアウトで、直径エンドポイント設定で設定可能です。 値は 1 秒から 300 秒の間に及ぶことができます。

: このタイマーのために設定される値は Tx 終止タイマーに使用するそれより大きいはずです。

次に例を示します。

[context_name]host_name(config-ctx-diameter)# response-timeout <value>

直径セッション フェールオーバー

システムがプライマリ サーバが到達不能になるときセカンダリサーバを使用するようにするこの機能は直径与信管理セッション フェールオーバーを有効に するか、またはディセーブルにするために使用されます。 これは直径クレジット コントロール設定で設定可能です。

次に例を示します。

local]host_name(config-dcca)# diameter session failover

FH メカニズム

FH メカニズムは直径セッション フェールオーバーがある場合その時だけ動作します。 FH は接続またはメッセージレベル エラーが発生するときシステムがかどうかセッションを続け、オフ・ラインでに変換するか、またはセッションを終了するために選択するようにします。

: FH はデフォルトで有効に なり、設定されます。

FH メカニズム 設定

FH メカニズムは直径クレジット コントロール設定で設定することができます。 FH 設定で使用する構文はここにあります:

failure-handling { initial-request | terminate-request | update-request } { continue
[ go-offline-after-tx-expiry | retry-after-tx-expiry ] | retry-and-terminate,
[ retry-after-tx-expiry ] | terminate }

最初のセクションは要求型を規定 します: 頭文字(CCR-I)、アップデート(CCR-U)、および終端(CCR-T)。

第 2 セクションは FH メカニズムがアクティブになるとき実行された必要がある操作を規定 します。 この 3 つの操作は FH メカニズムと可能性のあるです:

  • 続けて下さい–これはセッションが続くようにし、オフ・ラインでにそれを変換します。 この機能は Tx 終止と関連している 2 つのオプションを使用します:

    • 行オフ・ラインの後 tx 終止–これは Tx 終止が行われた後オフ・ラインで満たし始めます。

    • 再試行の後 tx 終止–これは Tx 終止が行われた後セカンダリサーバを再試行します。

  • 再試行および終端–これはシステムの後でセカンダリサーバが利用できない場合、セッションを再試行しますセカンダリサーバを終了します。 これはまた Tx 終止が行われた後セカンダリサーバを再試行する再試行の後 tx 終止オプションを使用します。

  • 終端–これはセカンダリサーバを接続する試みなしでセッションを終了します。

FH メカニズム デフォルトの動作

このセクションは設定が時 FH デフォルトの動作を記述します。 デフォルトで、FH メカニズムは応答タイムアウト(RT)の間に終端操作が設定されるとき、以外アクティブになります。

クレジット コントロール失敗処理属性値ペア(AVP)がサーバから届く場合、受け取った設定は適用します。

次に例を示します。

  • 最初の要求 > 終端

  • Update 要求 > 再試行および終端

  • Terminate-Request > 再試行および終端

FH メカニズム詳しいコールフロー

このセクションはすべての可能性のある オプションの FH メカニズムの詳しいコールフローを記述します。

最初の要求

CCFH 設定CLI コマンドTx の動作RT の動作セカンダリは稼働していますセカンダリはダウンしています

[Continue]

最初の要求
continue

N/A

[Continue]

セカンダリ
後引き継ぎます
RT

オフ・ラインで別の RT の後で。
これ以上のクォータ要求は実行された
セッション内の定格 グループのため
DCCA 失敗の後(
DCCA への接続は復元する)

最初の要求
行オフ・ラインの後で続けて下さい
tx 終止

offline

N/A

オフ・ラインで Tx で

オフ・ラインで Tx で

最初の要求
再試行の後で続けて下さい
tx 終止

[Continue]

N/A

セカンダリ
後引き継ぎます
Tx

オフ・ラインで別の Tx の後で

再試行および終端

最初の要求
再試行および終端

N/A

再試行

セカンダリ
後引き継ぎます
RT

別の RT の後の終端

最初の要求
再試行および終端
再試行の後 tx 終止

再試行

N/A

セカンダリ
後引き継ぎます
Tx

別の Tx の後の終端

Terminate

最初の要求
terminate

Terminate

N/A

Tx の後の終端

Tx の後の終端

Update 要求

CCFH 設定CLI コマンドTx の動作RT の動作セカンダリは稼働していますセカンダリはダウンしています

[Continue]

Update 要求
continue

N/A

[Continue]

セカンダリ
後引き継ぎます
RT

オフ・ラインで別の RT の後で

Update 要求
行オフ・ラインの後で続けて下さい
tx 終止

offline

N/A

オフ・ラインで Tx で

オフ・ラインで Tx で

Update 要求
再試行の後で続けて下さい
tx 終止

[Continue]

N/A

セカンダリ
後引き継ぎます
Tx

オフ・ラインで別の Tx の後で

再試行および終端

Update 要求
再試行および終端

N/A

再試行

セカンダリ
後引き継ぎます
RT

別の RT の後の送信 CCR-T

Update 要求
再試行および終端
再試行の後 tx 終止

再試行

N/A

セカンダリ
後引き継ぎます
Tx

別の Tx の後の送信 CCR-T

Terminate

Update 要求
terminate

Terminate

N/A

Tx の後の送信 CCR-T

Tx の後の送信 CCR-T

Terminate-Request

CCFH 設定CLI コマンドTx の動作RT の動作セカンダリは稼働していますセカンダリはダウンしています

[Continue]

terminate-request
continue

N/A

再試行

CCR-T は送信 されます
セカンダリに
RT の後

別の RT の後の終端

terminate-request
行オフ・ラインの後で続けて下さい
tx 終止

再試行

N/A

CCR-T は送信 されます
セカンダリに
Tx の後

別の Tx の後の終端

terminate-request
再試行の後で続けて下さい
tx 終止

再試行

N/A

CCR-T は送信 されます
セカンダリに
Tx の後

別の Tx の後の終端

再試行および終端

terminate-request
再試行および終端

N/A

再試行

CCR-T は送信 されます
セカンダリに
RT の後

別の RT の後の終端

terminate-request
再試行および終端
再試行の後 tx 終止

再試行

N/A

CCR-T は送信 されます
セカンダリに
Tx の後

別の Tx の後の終端

Terminate

terminate-request
terminate

Terminate

N/A

後終端
Tx

Tx の後の終端

SU メカニズム

SU メカニズムは類似した FH メカニズムですが、失敗手順の粒状制御を提供します。 セッションの継続に加えて応答が OCS から遅い時メッセージおよび接続レベル(転送する)失敗が、このメカニズム使用することができた後。 それはまた終了の前にオプションをにしばらくの間続けるか、セッション 期間/クォータ枯渇を、または使用します設定可能な暫時クォータ セッションがオフ・ラインでに変換されるか、または終了される前に(音量および時間)および設定可能なサーバ再試行を提供します。 

SU メカニズム 設定

SU メカニズムは直径クレジット コントロール設定で設定することができます。 SU 設定で使用する構文は使用するバージョンに従って変わります。

バージョン 12.1 および それ 以前に関しては、これは SU メカニズム 設定のために使用する構文です:

servers-unreachable { initial-request { continue | terminate [ after-timer-expiry
<
timeout_period> ] } | update-request { continue | terminate [ after-quota-expiry
| aftertimer-expiry <
timeout_period> ] } }

バージョン 12.2 および それ 以降に関しては、これは SU メカニズム 設定のために使用する構文です:

servers-unreachable { behavior-triggers { initial-request | update-request }
result-code { any-error | <
result-code> [ to <end-result-code> ] }
| transport-failure [ response-timeout | tx-expiry ] | initial-request
{ continue [ { [ after-interim-time <
timeout_period> ] [ after-interim-volume
<
quota_value> ] } server-retries <retry_count> ] | terminate [ {
[ after-interim-time <
timeout_period> ] [ after-interim-volume <quota_value> ]
} server-retries <
retry_count> | after-timer-expiry <timeout_period> ] }
| update-request { continue [ { [ after-interim-time <
timeout_period> ]
[ after-interim-volume <
quota_value> ] } server-retries <retry_count> ]
| terminate [ { [ after-interim-time <
timeout_period> ] [ after-interim-volume
<
quota_value> ] } server-retries <retry_count> ] | after-quota-expiry |
after-timer-expiry <
timeout_period> ] } }

: バージョン 12.2 以前のバージョンでは、FH および SU メカニズムを独自に設定する柔軟性がありました; ただし、バージョン 12.2 および それ 以降で、SU メカニズムは設定されたとき FH メカニズムに優先します。

サーバが CC-FH AVP を戻し、SU メカニズムが一組の動作 トリガーのために設定されれば場合、SU 設定は適用します; さもなければ、CC-FH AVP 値は適用します。 デフォルトで、3002、3004、および 3005 のような結果コードは配信失敗の下で下り、RT として扱われます。

これらの操作は SU メカニズムと可能性のあるです:

  • 動作トリガー–これは最初の要求(CCR-I)または Update 要求(CCR-U)のどれである場合もあるメッセージ の タイプを規定 します。 これらのトリガーのために利用可能 な 3 つのオプションがあります:

    • 結果コード–これはメッセージタイプと共に特定の結果コードの設定、結果コード(3000-5999)の範囲、またはエラーを可能にします。

    • 転送する失敗–この仕様はバージョン 12.0 と逆方向に互換性がある転送する障害に動作を引き起こします。 この設定のために利用可能 な 2 つのオプションがあります:

      • 応答タイムアウト–このオプションは RT に動作を引き起こし、トランスポート エラーと常に使用する必要があります。

      • Tx 終止–このオプションは Tx 終止に動作を引き起こし、トランスポート エラーと常に使用する必要があります。

    • 操作–これは CCR-I または CCR-U のための SU トリガーが発生するとき実行された操作を規定 します。 この操作はメッセージタイプおよびソフトウェア バージョンに従って変わります。

  • 続けて下さい–これはセッションがオフ・ラインでに変換されるようにし、続きます。 バージョン 12.2 前にバージョンでこのアクションの使用のために利用可能 なそれ以上のオプションがありません。 バージョン 12.2 および それ 以降では、暫時分担、サーバ再試行およびの後タイマー終止オプションはこのアクションを用いる設定に利用できます。

  • 終端–これはセッションの終了という結果にサーバが到達不能になるとき終ります。 この操作は暫時クォータ、サーバ再試行およびの後タイマー終止オプションを可能にします。

これらのオプションは継続または終端操作と使用することができます:

    • の後中間時間–このオプションは暫時タイムアウト期間以降にコールの継続か終了を可能にします。 これは操作が実行された前に時間クォータに類似したです。 値は秒にフォーマットされ、1 と 4,294,967,295 の間で及ぶことができます。

    • の後中間音量–このオプションは暫時クォータを割り当て、設定された音量の枯渇の前にセッションの継続か終了を可能にします。 値はバイトでフォーマットされ、1 と 4,294,967,295 の間で及ぶことができます。

    • サーバ再試行–このオプションは PCEF がセッションの継続か終了の前に OCS を再試行するようにします。 リトライ回数は 0 と 65,535 間の値範囲設定し。 値がゼロである場合、再試行は発生しないし、操作はすぐに適用します。

: の後中間時間およびの後中間音量 オプションはサーバ再試行オプションと常に使用されます、または 3 つはすべて同時に使用することができ、に適用されて操作を続け、終えて下さい。 の後中間時間およびの後中間音量 オプションはまた時間、また音量クォータを割り当て、最初に排出されるクォータはサーバ再試行を引き起こします。

  • の後タイマー終止–このオプションは(終了が発生する前にセッションがオフライン ステータスに残る秒で)時間期間を規定 します。 値は 1 と 4,294,967,295 の間で及ぶことができます。 このオプションは終端操作にだけ適当です。

  • の後クォータ終止–このオプションは既に割り当てられたクォータの枯渇にセッションを終了します。

覚えるべき重要な情報はここにあります:

  • の後中間時間、の後中間音量およびサーバ再試行オプションはそれぞれまたは組み合せで使用することができ適当に続け、終えます操作をです。

  • の後クォータ終止オプションは Update 要求 動作 トリガーにだけ適当です。

  • の後タイマー終止オプションは終端操作にだけ適当です。

  • の後中間時間、の後中間音量およびサーバ再試行オプションはバージョン 12.2 および それ 以降にだけ適当です。

  • 直径セッション フェールオーバーが(サポートされ、)設定されます、SU メカニズムが引き起こされる前にセカンダリサーバは常に接続されます。

  • サーバは最後に連絡された SU メカニズムが引き起こされる前に暫時時間または中間音量が排出されるオプションがゼロより大きい値で設定されるサーバ再試行とき常に接続され。 たとえば OCS1 が最初に試みられれば、および OCS2 OCS1 のエラーの後で試みられます、そして OCS2 の通信は SU メカニズムを引き起こします。 次にサーバ再試行の間に、OCS2 は否定応答が OCS2 から届く場合最初におよび OCS1 連絡されます。

SU メカニズム コールフロー

SU メカニズムは CCR-I または CCR-U の失敗によって引き起こし原因はエラーコード、トランスポート エラー、Tx 終止、または RT のどちらである場合もあります。 操作は(時間や音量)、サーバ リトライ回数、タイマー値(セッションを指定時間と終了のためにだけオフラインになるために引き起こします)暫時クォータのアロケーションである場合もあります、またはセッションの前のクォータ終止は(CCR-U および終了のためにだけ)オフラインになるか、または終わります。

暫時クォータはセッションごとの基礎で、マルチプルサービス与信管理(MSCC)シナリオのない毎定格 グループ(RG)基礎提供されます。

プライマリ サーバがトランスポート エラーを引き起こし、セカンダリサーバが Tx 終止か応答タイムアウトを引き起こすという可能性があります。 このシナリオでは、最新のエラーは失敗のトリガーであると考慮されます。

SU メカニズムがあらゆる失敗トリガーのために設定されない場合、FH メカニズムは引き起こされます。

: 続くセクションは SU メカニズムと関連しているいくつかのコールフロー例を提供します。 これらのコールフローは直径セッション フェールオーバーがサポートされるセカンダリサーバがであり、RT 値よりより少し Tx 終止値で設定されると仮定して提供されます。 また SU メカニズムがトランスポート エラー、Tx 終止および RT のために設定されることが、仮定されます。

セッション 接続解除のない最初の要求

このシナリオのためのメッセージフローはここにあります:

  1. PCEF は OCS に CCR-I を送信 します。

  2. タイムアウトかトランスポート エラーは検出する。 トランスポート エラーが検出する場合、PCEF はセカンダリサーバとすぐに再試行します; さもなければ、Tx 終止は引き起こされます。

  3. セカンダリサーバにまたトランスポート エラーかタイムアウトがある場合、SU メカニズムは引き起こされます。 これはトランスポート エラーのために、またはタイムアウトのための Tx 終止の後にすぐに発生します。

  4. 暫時音量や時間が設定される場合、暫時クォータはセッションに割り当てられます。

  5. 暫時クォータの枯渇の後(時間または音量)およびサーバ再試行値がゼロ、そして CCR-I より大きければ再度 SU メカニズムを引き起こした サーバに送信 されます。 もう一つの失敗がある場合、CCR-I は別のサーバに送信 されます。

  6. トランスポート エラーか Tx タイムアウトが再度検出する場合、ステップ 2 〜サーバ再試行値が排出されるか、または正常な応答が OCS から来ないまで 5 は繰り返されます。

  7. それでも存在 する問題がそしてセッション(オフ・ラインでに変換されて)続いたりまたは設定によって終われば。

: セッションが CCR-I による SU モードに入る間、消費される暫時クォータは次の CCR-I で報告されません。 使用された暫時クォータすべては正常な CCA-I に続く CCR-U で報告されます。

セッション 接続解除の最初の要求

このシナリオのためのメッセージフローはここにあります:

  1. PCEF は OCS に CCR-I を送信 します。

  2. タイムアウトかトランスポート エラーは検出する。 トランスポート エラーが検出する場合、PCEF はセカンダリサーバとすぐに再試行します; さもなければ、Tx 終止は引き起こされます。

  3. セカンダリサーバにまたトランスポート エラーかタイムアウトがある場合、SU メカニズムは引き起こされます。 これはトランスポート エラーのために、またはタイムアウトのための Tx 終止の後にすぐに発生します。

  4. 暫時音量や時間が設定される場合、暫時クォータはセッションに割り当てられます。

  5. 暫時クォータの枯渇の後(時間または音量)およびサーバ再試行値がゼロ、そして CCR-I より大きければ再度 SU メカニズムを引き起こした サーバに送信 されます。 もう一つの失敗がある場合、CCR-I は別のサーバに送信 されます。

  6. トランスポート エラーか Tx タイムアウトが再度検出する場合、ステップ 2 〜サーバ再試行値が排出されるか、または正常な応答が OCS から来ないまで 5 は繰り返されます。 この時点で、セッションは全体の暫時クォータの消費なしで切断されています。

  7. セッション 終了の後で、PCEF は再度新しいセッションを始めるために CCR-I を送信 します。 これが正常である場合、PCEF は使用した全体一時クォータを報告する CCR-T を送信 します。

セッション 接続解除のない Update 要求

このシナリオのためのメッセージフローはここにあります:

  1. PCEF は OCS に CCR-U を送信 します。

  2. タイムアウトかトランスポート エラーは検出する。 トランスポート エラーが検出する場合、PCEF はセカンダリサーバとすぐに再試行します; さもなければ、Tx 終止は引き起こされます。

  3. セカンダリサーバにまたトランスポート エラーかタイムアウトがある場合、SU メカニズムは引き起こされます。 これはトランスポート エラーのために、またはタイムアウトのための Tx 終止の後にすぐに発生します。

  4. 暫時音量や時間が設定される場合、暫時クォータはセッションに割り当てられます。

  5. 暫時クォータの枯渇の後(時間または音量)およびサーバ再試行値がゼロ、そして CCR-U より大きければ再度 SU メカニズムを引き起こした サーバに送信 されます。 もう一つの失敗がある場合、全体の消費された無報告クォータが含まれている CCR-U は別のサーバに送信 されます。

  6. トランスポート エラーか Tx タイムアウトが再度検出する場合、ステップ 2 〜サーバ再試行値が排出されるか、または正常な応答が OCS から来ないまで 5 は繰り返されます。

  7. 全体の消費されたクォータは正常な CCR-U の OCS に報告されます。

  8. それでも存在 する問題がそしてセッション(オフ・ラインでに変換されて)続いたりまたは設定によって最大リトライ数値の枯渇の後で終われば。

セッション 接続解除の Update 要求

このシナリオのためのメッセージフローはここにあります:

  1. PCEF は OCS に CCR-U を送信 します。

  2. タイムアウトかトランスポート エラーは検出する。 トランスポート エラーが検出する場合、PCEF はセカンダリサーバとすぐに再試行します; さもなければ、Tx 終止は引き起こされます。

  3. セカンダリサーバにまたトランスポート エラーかタイムアウトがある場合、SU メカニズムは引き起こされます。 これはトランスポート エラーのために、またはタイムアウトのための Tx 終止の後にすぐに発生します。

  4. 暫時音量や時間が設定される場合、暫時クォータはセッションに割り当てられます。

  5. 暫時クォータの枯渇の後(時間または音量)およびサーバ再試行値がゼロ、そして CCR-U より大きければ再度 SU メカニズムを引き起こした サーバに送信 されます。 もう一つの失敗がある場合、全体の消費された無報告クォータが含まれている CCR-U は別のサーバに送信 されます。

  6. トランスポート エラーか Tx タイムアウトが再度検出する場合、ステップ 2 〜サーバ再試行値が排出されるか、または正常な応答が OCS から来ないまで 5 は繰り返されます。 この時点で、セッションは全体の一時クォータを消費する前に切断されています。

  7. PCEF は OCS に全体の消費されたクォータを報告するために CCR-T を送信 します。

  8. OCS が結果コードと 2002 応答する場合、追加レポートは必要ではないです。

未知セッションの Update 要求

このシナリオのためのメッセージフローはここにあります:

  1. PCEF は OCS に CCR-U を送信 します。

  2. タイムアウトかトランスポート エラーは検出する。 トランスポート エラーが検出する場合、PCEF はセカンダリサーバとすぐに再試行します; さもなければ、Tx 終止は引き起こされます。

  3. セカンダリサーバにまたトランスポート エラーかタイムアウトがある場合、SU メカニズムは引き起こされます。 これはトランスポート エラーのために、またはタイムアウトのための Tx 終止の後にすぐに発生します。

  4. 暫時音量や時間が設定される場合、暫時クォータはセッションに割り当てられます。

  5. 暫時クォータの枯渇の後(時間または音量)およびサーバ再試行値がゼロ、そして CCR-U より大きければ再度 SU メカニズムを引き起こした サーバに送信 されます。 もう一つの失敗がある場合、全体の消費された無報告クォータが含まれている CCR-U は別のサーバに送信 されます。

  6. OCS は OCS がセッションID 情報を再起動し、失ったシナリオで可能性のあるである CCR-U のための a (未知セッションID)結果コードと 5002 答えます。

  7. PCEF は CCR-I の新しいセッションを始め、CCA-I を受け取ります。

  8. PCEF はそれ以降のメッセージの CCR-U によって全体の消費された暫時クォータを報告します。

多重 RGs (MSCC シナリオ)の Update 要求

このシナリオのためのメッセージフローはここにあります:

  1. PCEF は OCS に RG1 のための CCR-U を送信 します。

  2. タイムアウトかトランスポート エラーは検出する。 トランスポート エラーが検出する場合、PCEF はセカンダリサーバとすぐに再試行します; さもなければ、Tx 終止は引き起こされます。

  3. セカンダリサーバにまたトランスポート エラーかタイムアウトがある場合、SU メカニズムは引き起こされます。 これはトランスポート エラーのために、またはタイムアウトのための Tx 終止の後にすぐに発生します。

  4. 暫時音量や時間が設定される場合、暫時クォータはセッションに割り当てられます

  5. この時点で RG2 はまたセッションが SU モードに既にあっている始めないし、暫時クォータを消費し始めますので全体の割り当てられたクォータを排出しが、CCR-U を。

  6. 暫時クォータの枯渇の後(時間または音量)およびサーバ再試行値がゼロ、そして CCR-U より大きければ再度 SU メカニズムを引き起こした サーバに送信 されます。 もう一つの失敗がある場合、両方のための全体の消費された無報告クォータが RGs 含まれている CCR-U は別のサーバに送信 されます。

  7. トランスポート エラーか Tx タイムアウトが再度検出する場合、ステップ 2 〜サーバ再試行値が排出されるか、または正常な応答が OCS から来ないまで 6 は繰り返されます。

  8. 全体の消費されたクォータは正常な CCR-U の OCS に報告されます。

  9. それでも存在 する問題がそしてセッション(オフ・ラインでに変換されて)続いたりまたは設定によって最大リトライ数値の枯渇の後で終われば。

Terminate-Request

このシナリオのためのメッセージフローはここにあります:

  1. PCEF は OCS に CCR-T を送信 します。

  2. タイムアウトかトランスポート エラーは検出する。 トランスポート エラーが検出する場合、PCEF はセカンダリサーバとすぐに再試行します; さもなければ、Tx 終止は引き起こされます。

  3. セカンダリサーバにまたトランスポート エラーかタイムアウトがある場合、セッションは取除かれます。

CCR エラーコード処理

このシナリオのためのメッセージフローはここにあります:

  1. PCEF 送信 OCS への CCR、および OCS はエラーコードと答えます。

  2. エラーコードは SU メカニズムで静的に設定されます。

  3. PCEF はセカンダリサーバに再試行なしで暫時クォータを提供します。

FH および SU 設定例

このセクションは FH および SU メカニズムに設定例を提供します。 FH および SU メカニズムが両方設定されるとき、SU は同じ動作 トリガーのための FH に優先します。

次に例を示します。

credit-control group test

diameter origin endpoint test

diameter peer-select peer test

quota volume-threshold percent 10

diameter pending-timeout 80 deciseconds msg-type any

diameter session failover

trigger type rat lac

apn-name-to-be-included virtual

quota request-trigger exclude-packet-causing-trigger

failure-handling initial-request continue retry-after-tx-expiry

servers-unreachable initial-request terminate after-interim-volume 200
after-interim-time 3600 server-retries 0

servers-unreachable behavior-triggers initial-request transport-failure
tx-expiry

servers-unreachable update-request continue after-interim-volume 200
after-interim-time 3600 server-retries 50

servers-unreachable behavior-triggers update-request transport-failure
tx-expiry

確認

設定がきちんと機能することを確認するために、提示アクティブ充満サービス <service name> コマンドを入力して下さい:

# show active-charging service name test



Service name: test



TCP Flow Idle Timeout : 300 (secs)

UDP Flow Idle Timeout : 300 (secs)

ICMP Flow Idle Timeout : 300 (secs)

ICMP Flow Idle Timeout : 300 (secs)

ALG Media Idle Timeout : 120 (secs)



TCP Flow-Mapping Idle Timeout : 300 (secs)

UDP Flow-Mapping Idle Timeout : Not Configured



Deep Packet Inspection: Enabled

Passive Mode : Disabled

CDR Flow Control : Enabled

CDR Flow Control Unsent Queue Size: 75

Unsent Queue high watermark: 56

Unsent Queue low watermark: 18



Content Filtering: Disabled



Dynamic Content Filtering: Disabled



URL-Blacklisting: Disabled

URL-Blacklisting Match-method: Exact



Content Filtering Match-method: Generic





Interpretation of Charging-rule-base-name: active-charging-group-of-ruledefs





Selection of Charging-rule-base AVP : Last



Credit Control:

Group : test



Mode : diameter

APN-name-to-be-included: gn

Trigger-Type : N/A



Failure-Handling:

Initial-Request : continue retry-after-tx-expiry

Update-Request : retry-and-terminate

Terminate-Request: retry-and-terminate



Server Unreachable Failure-Handling:

Initial-Request : terminate

Update-Request : continue

トラブルシューティング

SU および FH メカニズムと関連している統計情報を表示するために提示アクティブ充満クレジット コントロール statistics コマンドを入力して下さい。 次に出力例を示します。

#show active-charging credit-control statistics
...

OCS Unreachable Stats:

Tx-Expiry: 2291985 Response-TimeOut: 615

Connection-Failure: 2 Action-Continue: 0

Action-Terminated: 0 Server Retries: 2023700



Assumed-Positive Sessions:

Current: 2 Cumulative: 2196851

この出力例についてのいくつかの注記はここにあります:

  • Tx 終止–これは Tx 終止による SU 状態を示します。

  • 応答タイムアウト–これは RT による SU 状態を示します。

  • 接続障害–これはトランスポート エラーによる SU 状態を示します。

  • 処理続けて下さい–このフィールドはオフラインになったセッションの数を示します。

  • 処理終端–このフィールドはセッションの数を示します終わった。

  • サーバ再試行–このフィールドは OCS が再試行されたこと回数を示します。

  • 仮定肯定的なセッション:

    • 現在の–このフィールドはセッションの数を示します SU 状態に現在ある。

    • 累積–このフィールドはセッションの総数を示します SU ステータスに移動した。

情報を表示するために提示アクティブ充満セッションをすべてのコマンド十分に入力して下さいセッションの SU 状態と関連している。 次に出力例を示します。

#show active-charging sessions full all
..
..

Current Server Unreachable State: CCR-I

Interim Volume in Bytes (used / allotted): 84/ 200

Interim Time in Seconds (used / allotted): 80/ 3600

Server Retries (attempted / configured): 1/ 50

この出力例についてのいくつかの注記はここにあります:

  • 現在のサーバ 到達不能州はこれ電流 SU 状態が CCR-I か CCR-U が原因であるかどうか規定 します。

  • バイトの暫時音量は(使用される/割り当てられる)割り当てられるバイト vs 使用されるバイトで–これ暫時音量を示します。

  • 秒の暫時時間(使用される/割り当てられる) –これは割り当てられる秒 vs 使用される秒に暫時音量を示します。

  • サーバは(試みられる/設定される) –これをです設定されるそれ vs 試みられるサーバ再試行の数再試行します

関連情報



Document ID: 118993