有線のプロビジョニングとアカウンティングのための 3GPP ポリシーおよび課金制御
有線プロビジョニングとアカウンティングのための 3GPP ポリシーおよび課金制御の概要
第 3 世代パートナーシップ プロジェクト(3GPP)の Policy and Charging Control(PCC)は、有線プロビジョニングの統合と顧客へのアカウンティングを提供します。 図 1 は、3GPP PCC アーキテクチャ全体のコンポーネントを示しています。
PCC アーキテクチャの 4 つの主要コンポーネントは次のとおりです。
ポリシー課金ルール機能(PCRF):ビジネス ポリシーと課金ルールを導入してブロードバンド ネットワーク リソースを割り当て、加入者とサービスのフローベースの料金を管理する一元的なポリシー決定ポイントです。PCRFは、3GPP Gxプロトコルとオンラインポリシーインターフェイスを使用して、ポリシーおよび課金適用機能(PCEF)にルールをプッシュします。
PCEF(Policy and Charging Enforcement Function):ゲートウェイでユーザー トラフィックの処理と QoS を提供し、サービス データ フローを検知し、PCRF から受信したルールを適用する機能です。PCEFは、3GPP Gyプロトコルを使用してオンライン課金システム(OCS)内のオンライン課金機能(OCF)とオプションで対話し、クォータとクレジット制御のポリシーと課金許可を取得します。
OCS(オンライン課金システム):PCEF とのやり取りを担当するコンポーネント。PCEF はオプションで使用状況を報告し、3GPP Gy プロトコルを使用して OCS から追加の許可を受けます。OCS とのブロードバンド PCEF(BPCEF)のやり取りでは、一元的なユニット決定と一元的なレーティングによるオンライン セッション課金が使用されます。
オフライン課金システム(OFCS):ネットワークリソース使用の情報をそのリソース使用と同時に収集するプロセス。クレジットベースの認証が必要ない場合、PCEF は 3GPP Gz プロトコルを使用してポリシーを適用し、OFCS に使用を報告します。また、OCS をプライマリ アカウンティングの宛先として使用し、OFCS をバックアップとして使用することもできます。
表 1 は、PCRF と PCEF の機能上の違いを示しています。
機能 |
Pcrf |
PCEF |
---|---|---|
課金ポリシングの実装 |
さまざまなレベルに関与。は、ホスティング ネットワーク内の情報を集約し、PCC アーキテクチャの一部と見なされます。 |
さまざまなレベルに関与。ゲートウェイにあるとします。 |
機能を含む |
主にポリシー制御決定機能とフローベース制御機能が含まれます。 |
ポリシー適用機能とフローベース課金機能を備えています。 |
事前定義されたPCCルール |
事前定義された PCC ルールのアクティブ化または非アクティブ化は、PCRF でのみ実行できます。 |
PCEF によって事前に設定されています。 |
オンラインとオフラインの充電のやり取り |
サポートされていません |
サポート |
図 1 の PCC アーキテクチャを構成する他の 3 つのコンポーネントは次のとおりです。
アプリケーション機能(AP)—アプリケーション機能は、動的PCCを必要とするアプリケーションまたはサービスと対話します。アプリケーション機能は、アプリケーション シグナリングからセッション情報を抽出し、Rx プロトコルを使用してアプリケーション セッション関連情報を PCRF に提供します。
サブスクリプションプロファイルリポジトリ(SPR)—SPRには、パケット単位のデータネットワーク(PDN)ベースの加入者およびサブスクリプション情報が含まれています。SP プロトコルにより、PCRF は加入者のサービスまたはセッションに関連するサブスクリプション情報を要求できます。
ベアラー バインディングおよびイベント レポート機能(BBERF):パケットが適切な QoS 処理を受信するように PCC ルールを特定の IP ベアラーにマッピングする必要があります。PCC ルールとベアラーの間の関連付けをベア ラー バインディングと呼びます。BBERFの場所は、アクセス技術に依存します。3GPP の場合、BBERF はサービング ゲートウェイ内にあり、Gxx プロトコルを使用します。
3GPP のポリシーおよび課金制御アーキテクチャのメリット
有線加入者のプロビジョニングとアカウンティングのための統一フレームワークを提供します。
ブロードバンド 有線加入者向けのポリシーおよび課金適用機能の概要
PCEF(Policy and Charging Enforcement Function)は、図 2 の第 3 世代パートナーシップ プロジェクト(3GPP)のポリシーおよび課金制御(PCC)アーキテクチャの 4 つの主要コンポーネントの 1 つです。
PCEF は、ゲートウェイでユーザー トラフィックの処理とサービス品質(QoS)を提供し、サービス データ フローを検知し、PCRF(Policy Control and Charging Rules Function)から受信したルールを適用します。3GPP は、PcRF と PCEF 間のオンライン ポリシー プロトコルとして Gx を定義し、加入者にポリシーとフローベースの料金を制御します。PCRFは、ビジネスポリシールールを導入してブロードバンドネットワークリソースを割り当て、加入者とサービスのフローベース料金を管理する一元的なポリシー決定ポイントです。オプションとして、PCEFは3GPP Gyプロトコルを使用してOCS(オンライン課金システム)と対話し、クォータとクレジット制御のポリシーと課金許可を取得します。
PCEF は、以下の環境をサポートします。
有線アクセス環境
モバイル加入者の場合、ユーザー機器はサービスを要求します。PCRFはサービスを要求します有線環境では、PCRFはサービスリクエスターとして機能し、PCEFはサービスレシーバーおよびエンフォーサとして機能します。
有線環境でPCCモデルを適応することで、次のようなメリットが得られます。
利便 性
高度な技術
すでにキャリアの無線ブランチによって実装されており、有線ブランチよりもはるかに大きなビジネスを提供することが多い
PCRFは充電ルールをプッシュすることでPCEFを制御します。課金ルールはサービス(ポリシー)ルールとして再利用され、ポリシーをプッシュします。課金ルールには、関連するレーティンググループ、または課金キーが含まれる場合があります。その結果、PCEF 構成では課金ルールを定義し、クレジット制御サービス(cc-services)とレーティング グループ間のマッピングを定義する必要があります。
多くの場合、OCSおよびOPC(オフライン課金システム)の両方の3GPPアカウンティングサービスでは、加入者の識別にモバイルデバイス国際加入者電話番号(MSISDN)を使用する必要があります。MSISDN はサブスクリプション ID として渡されます。各モバイル ユーザー機器デバイスには MSISDN が関連付けられていますが、有線加入者はこの情報を利用できません。PCRFがサブスクリプションIDパラメーターを動的に渡し、さまざまな認証、許可、プロビジョニング設定をサポートするために、 表2 のジュニパー属性値ペア(AVP)は、ジュニパーベンダーIDスペース(2636)ベンダー固有属性(VSA)から割り当てられています。
動的サブスクリプション ID を受信しなかった場合、OCS および OFCS 通信は開始されません。
AVP 名 |
ベンダーID |
AVP タイプ |
直径タイプ |
直径フラグ |
---|---|---|---|---|
ジュニパー-Dyn-サブスクリプションインジケータ |
2636 |
10001 |
Enum |
V |
Juniper-Dyn-Subscription-ID |
2636 |
10002 |
分類 |
Vm |
Juniper-Dyn-Subscription-ID-Type |
2636 |
10003 |
整数32 |
Vm |
Juniper-Dyn-Subscription-id-data |
2636 |
10004 |
UTF8ストリング |
Vm |
クライアントシステム(ルーター)は、サブスクリプションIDの動的割り当てのサポートを示すために、Juniper-Dyn-Subscription-Id-Indicator AVPを送信します。Juniper-Dyn-Subscription-Id-Indicator属性には、2つの値があります。
DYN_SUBSCRIPtION_NOT_SUPPORTED(0)
DYN_SUBSCRIPTION_SUPPORTED(1)
次に、サーバーはサポートを示すクライアントにJuniper-Dyn-Subscription-Id AVPを送信します。これは、Subscription-Id-Type と Subscription-Id-Data として送信される値を含むグループ化 AVP です。
PCRFサーバーは、標準のサブスクリプションID AVPを使用して、ダイナミックサブスクリプションIDをルーターに通信することができます。
PCRF から Juniper-Dyn-Subscription-ID と Subscription-ID の両方が送信された場合、サブスクリプション ID 値が使用されます。
多くの場合、有線加入者は1つのIPファミリーのみをサポートしており、これはAAAサービスとPCRFの両方に必要な情報です。この情報を示すために、 表3のJuniper Vendor-ID Space(2636)VSAから、ジュニパーネットワークスファミリーインジケータAVPが割り当てられています。
AVP 名 |
ベンダーID |
AVP タイプ |
直径タイプ |
直径フラグ |
---|---|---|---|---|
ジュニパーネットワークスファミリーインジケータ |
2636 |
10010 |
Enum |
V |
クライアントシステム(ルーター)は、Juniper-Network-Family-Indicator AVPを送信し、どのネットワークファミリーがサービスリクエストに関連付けされ、加入者によってサポートされているかを示します。Juniper-Network-Family-Indicator AVPが関連するネットワークファミリーを示すように設定すると、システムは情報をPCRFに送信します。ジュニパーネットワークスファミリーインジケータ属性には、4つの値があります。
未指定(0)
IPV4_FAMILY(1)
IPV6_FAMILY(2)
IPV4_IPV6_FAMILY(3)
有線のお客様の多くは、PCRFのみを介してユーザーサービスを制御し、OCSを実施ユニットとしてではなく、便利なリアルタイムの使用監視メカニズムとして使用します。誤って発生する可能性のある OCS 設定の数を減らすには、 ステートメントを 階層レベルに[edit access ocs partition partition-name]
含force-continue
めて、ブロードバンド PCEF(BPCEF)を強制して、OCS およびクォータの有効期限からのマイナスの応答の影響を制限し、影響を受けるレーティング グループに対して OCS 通知を送信しないようにします。PCEF は、報告されたグループに対して否定的な応答を受信するたびに、このグループを OCS に報告しなくなります。
Junos OS 環境
Junos OS 環境内には、次の 3 つのカテゴリーの動的プロファイルがあります。
クライアント動的プロファイル
cos-service-dynamic-profiles
ファイアウォールサービスダイナミックプロファイル
クライアント動的プロファイルおよび cos-service-dynamic-profiles は、加入者に提供されるサービスの帯域幅とその他の特性を定義します。ファイアウォールサービスプロファイルは、フィルタリングと使用状況カウントを実行します。すべての動的プロファイルのカテゴリーでは、サービス動的プロファイル名が Charging-Rule-Name AVP の値として使用されます。
サービス動的プロファイルに変数がない場合、またはサービス動的プロファイル定義で提供されるデフォルトが要求された場合、追加の要素は必要ありません。サービス動的プロファイルにカスタム値を提供するには、追加のVSAで課金ルール定義AVPを使用します。
PCRF は、既存の Juniper-Substitution VSA(Vendor-ID 2636 および Type 2024)を使用して、属性を名前と値のペアとして供給します。PCRF は、ルール名の一部の位置記法としてパラメータを含めることもできます。リダイレクト情報 AVP(ベンダー ID 10415 およびタイプ 1085)は、リダイレクト URL パラメーターの値を提供します。
顧客から要求されたすべてのサービス動的プロファイル パラメーター名に対して、新しい Juniper-Parameter VSA が定義されます。 表 4 は、固定 Juniper-Parameter VSA の初期セットを示しています。
パラメーター |
VSA名 |
ベンダーID |
型 |
直径タイプ |
---|---|---|---|---|
Cos-Tcp |
Juniper-Param-Cos-Tcp |
2636 |
10005 |
UTF8ストリング |
V4 ファイアウォール入力フィルター |
Juniper-Param-V4-Firewall-Input-Filter |
2636 |
10006 |
UTF8ストリング |
V4 ファイアウォール出力フィルター |
Juniper-Param-V4-Firewall-Output-Filter |
2636 |
10007 |
UTF8ストリング |
V6ファイアウォール入力フィルター |
Juniper-Param-V6-Firewall-input-filter |
2636 |
10008 |
UTF8ストリング |
V6 ファイアウォール出力フィルター |
Juniper-Param-V6-Firewall-output-filter |
2636 |
10009 |
UTF8ストリング |
PCRFでパラメータまたはサービス識別子および定格グループを示す必要がある場合、課金ルール定義AVPが使用されます。それ以外の場合は、Charging-Rule-Name AVPが使用されます。
Charging-Rule-Definition ::= < AVP Header: 1003 > { Charging-Rule-Name } [ Service-Identifier ] [ Rating-Group ] [ Online ] [ Precedence ] [ Juniper-Param-VSA ] [ AVPs ] – standard AVPs used as parameters
例えば、サービス識別子とレーティンググループの組み合わせがある場合、またはサービス識別子のみ、または Rating-Group のみが指定されている場合、その組み合わせは加入者にインストールされたルール間で一意である必要があります。ルーターに service-context-id を設定します。
ルーターとPCRF間のGx相互作用の理解
Diameterメッセージのシーケンスは、PCRF(Policy Control and Rules Charging Function)と、PCEF(Policy and Charging Enforcement Function)として動作するルーターとの間で、第3世代パートナーシッププロジェクト(3GPP)Gxプロトコルによって交換されます。
Junos OS リリース 17.3R1 以降、Gy および Gx プロトコルを使用して、追加の OCS および PCRF 機能のサポートが追加されました。新しいステートメント:
accept-sdr
は、 階層レベル[edit access pcrf partition partition-name]
で PCRF パーティションに追加されます。alternative-partition-name
は、 階層レベル[edit access ocs partition partition-name]
で OCS パーティションに追加されます。
これらのユーザーは、以下の加入者アクセス タスクを実行するために対話します。
加入者ログイン
ルーターは、固定された必要な情報セットを含む Diameter CCR リクエストを PCRF(ポリシー マネージャー)に送信し、ポリシーやその他の情報を含む CCA 応答を受信します。階層レベルで ステートメントを含めると provisioning-order pcrf
、加入者に Gx プロビジョニングが [edit access profile profile-name]
有効になります。アプリケーションが AAA を要求して加入者のセッションをアクティブ化すると、ルーターは CCR-GX-I(INITIAL_REQUESTを表す)メッセージを PCRF に送信し、加入者セッションのプロビジョニング情報の修正セットを要求し、ポリシーやその他の情報(結果コード AVP(AVP コード 268)を含むその他の情報を含む CCA-GX-I 応答メッセージを受信します。
アクセス プロファイルで ステートメントを provisioning-order
設定すると、ブロードバンド PCEF(BPCEF)モジュールは、クライアント のアクティブ化中にプロビジョニング要求を PCRF に送信します。以下の例は、CCR-GX-I および CCA-GX-I パケット交換を示しています。
CCR-GX-Iパケットの例
CCR-GX-I ::= <Diameter Header: 272, REQ, PXY 16777238> { <Session-Id> } { Auth-Application-Id: 16777238 } { Origin-Host: <configurable-string> } { Origin-Realm: <configurable-string> } { Destination-Realm: <configurable-string> } { CC-Request-Type: INITIAL_REQUEST(1) } { CC-Request-Number: 0 } { Subscription-Id: { Subscription-Id-Type: <configurable-integer> } { Subscription-Id-Data: <configurable-string> } } } [ Destination-Host: <configurable-string> ] -- if configured [ Origin-State-Id: <u32> ] -- if configured to send [ Framed-IP-Address: <ipv4-address-in-radius-encoding> ] -- if available [ Framed-IPv6-Prefix: <ipv6-prefix-in-radius-encoding> ] -- if available { IP-CAN-Type: <configurable-integer> } { Online: ENABLE_ONLINE (1) } [ User-Name: <string> ] [ NAS-Port-Id: <string> ] -- if included by config [ Juniper-Virtual-Router: <virtual-router-name> ] -- if included by config [ Event-Timestamp: <timestamp> ] -- login timestamp, if included by config { Juniper-Dyn-Subscription-Indicator: DYN_SUBSCRIPTION_SUPPORTED(1) } { Juniper-Network-Family-Indicator: <subscriber-family> }
CCR-GX-I を再送信すると、T ビットが再計算します(再送信される可能性があるメッセージ)。このフラグは、重複するリクエストを削除するためのリンク フェイルオーバー手順の後に設定されます。
CCA-GX-I パケットの例
CCA-GX-I ::= <Diameter Header: 272, PXY, 16777238> { <Session-Id> } { Result-Code: <integer> } { Auth-Application-Id: 16777238 } { Origin-Host: <string> } -- should match destination-host if configured { Origin-Realm: <string> } -- should match destination-realm { Result-Code: <integer> } { CC-Request-Type: INITIAL_REQUEST(1) } { CC-Request-Number: 0 } [ Juniper-Dyn-Subscription-Id: {Juniper-Dyn-Subscription-Id-Type: <value-to-be-used-for-ocs-interactions> } {Juniper-Dyn-Subscription-Id-Data: <value-to-be-used-for-ocs-interactions> } ] *[ Supported-Features ] -- ignored [ Origin-State-Id: <u32> ] -- Indicates restart PCRF side *[ Downstream data units ]
ルールインストールAVPがCCA-GX-Iで定義されていない場合、デフォルトルールがインストールされます。
まだ定義されていないイベント トリガーも含め、すべてのイベント トリガーを受け入れます。ただし、実装時に実際にイベントを生成するのは少数のイベント トリガーのみです。
PCRF は、 表 5 に示す結果カテゴリにマッピングされた結果コード AVP(AVP コード 268)を含む CCA-GX-I メッセージを返します。
結果コード-AVP 値 |
結果のカテゴリー |
---|---|
SUCCESS(2001)、LIMITED_SUCCSS(2002)、および有効なメッセージ |
付与 |
AUTHENTICATION_REJECTED(4001)、UNKNOWN_SESSION_ID(5002)、AUTHORIZATION_REJECTED(5003)、およびUSER_UNKNOWN(5030) |
拒否 |
UNABLE_TO_DELIVER(3002)、REALM_NOT_SERVED(3003)、TOO_BUSY(3004)、LOOP_DETECTED(3005)、REDIRECT_INDICATION(3006) |
失敗 |
その他すべての Diameter パーマネント障害の結果コード AVP が 5000 以上、すべての Diameter プロトコル エラー結果コード AVP が 3000 以上 4000 未満 |
恒久的な障害 |
無効なメッセージまたは応答がない場合のその他の結果コード AVP |
失敗 |
表6に示すように、CCA-GX-I応答処理は3つの要因に依存します。
ローカル決定タイムアウトが期限切れになったかどうか
ローカル決定の設定
結果のカテゴリ
表 6 には、PCRF ローカル決定タイムアウト有効期限アクションも含まれています。
PCRF ローカル 決定タイムアウト |
PCRF のローカル決定 |
結果 のカテゴリー |
アクション |
---|---|---|---|
有効期限切れでない |
– |
付与 |
ローカル決定タイマーをクリアし、CCA-GX-I からルールを適用し、OCS(オンライン課金システム)に通知してから、加入者のアクティベーションを確認します。 |
有効期限切れでない |
– |
拒否 |
ローカル決定タイマーをクリアし、加入者のアクティベーションに失敗します。 |
有効期限切れでない |
– |
失敗 |
ローカル決定タイムアウトになるまで CCA-GX-I を再試行してください。 |
有効期限切れでない |
付与 |
恒久的な障害 |
ローカル決定タイマーをクリアし、デフォルト ルールを適用し、加入者のアクティベーションを確認してから、CCA-GX-I を再試行し続けます。 |
有効期限切れでない |
拒否 |
恒久的な障害 |
加入者のアクティベーションに失敗し、加入者のログアウトプロセスを開始します。 |
有効期限切れ時 |
付与 |
– |
デフォルトルールを適用し、CCA-GX-Iを無期限に再試行し続け、加入者のアクティベーションを確認します。 |
有効期限切れ時 |
拒否 |
– |
加入者のアクティベーションに失敗し、加入者のログアウトプロセスを開始します。 |
期限 切れ |
付与 |
付与 |
CCA-GX-I にルールが含まれている場合、デフォルト のルールを削除して受信したルールをインストールしてから、OCS に通知して加入者のアクティベーションを確認します。 |
期限 切れ |
付与 |
拒否 |
クライアントをログアウトします。 |
期限 切れ |
付与 |
失敗 |
CCA-GX-Iを無限に再試行し続けてください。 |
期限 切れ |
付与 |
恒久的な障害 |
長い一時停止してから、CCA-GX-I を再試行して再起動します。 |
期限 切れ |
拒否 |
拒否 |
加入者がまだログアウトする場合は、加入者を無視します。それ以外の場合は、アクションは必要ありません。 |
加入者ログインは、以下の一連のイベントを開始します。
DHCP、PPP、静的加入者セッションなどのクライアントアプリケーションは、AAAを要求して加入者を認証します。
加入者アクセスプロファイルがRADIUS認証を指定した場合、認証が開始されます。認証に成功すると、ログインは続行されます。プロファイルのステートメントで
authentication-order
RADIUS認証が指定されていない、または認証がない場合、ログインは失敗します。認証に失敗した場合、ログインも失敗します。デフォルトサービスは、加入者向けにアクティブ化されます。認証付与に認証サーバーが含まれるサービスはすべて有効になります。さらに、クライアント アプリケーションに対してデフォルト サービスが構成されている場合もあります。
加入者アクセス プロファイルが Gx プロビジョニングを指定した場合、ルーターは CCR-GX-I メッセージを PCRF に送信することで Gx メッセージ交換を開始します。ルーターは、設定可能なタイムアウト期間内にPCRFがCCA-GX-Iメッセージで応答するのを待ちます。
PCRFがタイムアウト期間内に応答し、CCA-GX-Iメッセージに課金ルールインストールAVPが含まれる場合、ルーターがデフォルトサービスを非アクティブ化し、指定されたサービスのアクティブ化を試みる間、加入者のログインが遅れます。
指定されたすべてのサービスがアクティブ化されると、ログインが完了します。
サービスのいずれかをアクティブにできない場合、ルーターは PCRF に CCR-GX-U(U がUPDATE_REQUESTを表す)メッセージをサービスのステータス(ルール レポート)で送信します。PCRF は、アクティベーションのための新しいサービス・セットを含めることができる CCA-GX-U でこのメッセージに応答します。
CCA-GX-Iメッセージにサービスが含まれていない場合でも、ルーターはデフォルトサービスを無視します。このような状況では、サービスはアクティブ化されません。
タイムアウト時間内に PCRF が CCA-GX-I を返さない場合、加入者ログインは完了します。
ルーターは、認証サーバーから返されたサービスを最初に検索し、見つけたサービスをアクティブにします。そのようなサービスが見つからない場合、ルーターはローカルに設定されたデフォルトサービスをアクティブにします。加入者ログインは、デフォルトのサービスアクティベーションに成功すると完了しますが、デフォルトサービスのアクティベーションに失敗すると失敗します。デフォルトサービスは存在する必要がないため、デフォルトサービスが見つからない場合もログインが完了します。
ログインが完了した場合(デフォルトサービスの有無にかかわらず)、ルーターはCCR-GX-IメッセージをPCRFに定期的に再送信します。PCRF が後で CCA-GX-I を返す場合、ルーターはデフォルト サービス(存在する場合)を無効にし、CCA-GX-I に含まれるサービスをアクティブにします。メッセージにサービスが含まれていない場合、サービスはアクティブ化されず、デフォルトサービスもありません。
CCA-GX-I に含まれるサービスのいずれかをアクティブにできない場合、ルーターは PCRF にサービスのステータス(ルール レポート)を含む CCR-GX-U メッセージを送信します。PCRF は、アクティベーションのための新しいサービス・セットを含めることができる CCA-GX-U でこのメッセージに応答します。
加入者ログインエラーの回復
Junos リリース 20.1R1 以降では、加入者セッションを再初期化してルーターと PCRF サーバーの状態を再同期することで、特定の PCRF サーバー エラーから回復するようにルーターを設定できます。一部のPCRFサーバーは、ルーターに送信されたCCA-GX-Iメッセージが失われる状況を適切に処理しない場合があります。ルーターがCCR-GX-IをPCRFに送信を再試行すると、サーバーは既に返信を送信しており、ルーターがメッセージを受信しなかったことは認識していないため、ルーターと同期していません。この状態の不一致により、次のいずれかのエラーが発生する可能性があります。
PCRF サーバーは、Diameter Result Code AVP(Code 268)の値が 5012(DIAMETER を準拠できない)を含む CCA-GX-I で再試行に応答します。これは永久的な障害と見なされます(表 5)。
PCRF サーバーは RAR を送信します。サーバーは、CCA-GX-Iをルーターに送信し、メッセージが受信されていないことを認識していないため、セッションがアクティブであることを期待しています。サーバーは、以下の RAR メッセージのいずれかを送信することがあります。
セッションが悪いと見なされるため、セッションを切断するRAR-GX-D
不正セッションに関する情報を読み取るRAR-GX-A
RAR-GX-youは、セッションが正常に動作しているとみなしているため、セッションを更新します。
PCRF local-decision
設定を使用して、これらのエラーのいずれかまたは両方に応じて加入者セッションを再度初期化できます。
永続的な障害エラーの
reinit-on-failure
オプションを含めます。RARエラーのオプションを含めます
reinit-on-rar
。
再初期化操作には、次のような追加の設定要件があります。
ローカル決定
grant
オプションを設定する必要があります。元のセッションと同じログインイベントに関連付けられた新しいセッションの状態を維持できるように、拡張セッションIDを使用するようにルーターを設定する必要があります。これを行うには、PCRF
use-session-stamp
オプションを設定します。
再初期化操作は、両方の場合で次の手順で構成されています。
ルーターは、セッション終了要求 CCR-GX-T を PCRF に送信して、セッションを終了します。これは、ルーターとPCRFサーバーがこのセッションで同じ状態を得ようとするために行われます。
ルーターは、CCA-GX-T を受信するために、再初期化タイムアウト期間を待機します。オプションを
reinit-timeout
使用して、デフォルトとは異なる期間を指定できます。タイムアウト期間内にルーターがCCA-GX-Tを受信するか、タイムアウトが切れる前にCCA-GX-Tが到着しない場合、ルーターは新しい拡張セッションIDを使用してCCR-GX-IをPCRFに送信します。拡張セッションIDは、DiameterセッションID AVP(AVPコード263)で伝達されます。
ルーターは、ルーターがCCR-GX-Iを作成する際のUTC時間で構成されるセッションスタンプを追加することで、拡張セッションIDを形成します。たとえば、次の Diameter セッション ID AVP を考えてみましょう。セッションIDは23で、
use-session-stamp
設定されていません。test-host1;0000000000;0000000023;
設定された場合
use-session-stamp
、セッションタイムスタンプはAVP値に追加されます。test-host1;0000000000;0000000023;1557788595;
表 7 は、現在のローカル PCRF 状態に基づいて、ルーターがこれらのエラーにどのように対応するかを示しています。
ローカル州 |
PCRF エラー発生時のアクション |
|
ルーターは以下を実行します。
|
|
デフォルトのプロビジョニングが完了すると、ルーターは以下を実行します。
|
|
デフォルトサービスが設定されていない場合、ルーターは以下を実行します。
デフォルトサービスが設定されている場合、ルーターは以下を実行します。
デフォルトのプロビジョニングが完了すると、ルーターは以下を実行します。
|
加入者の最新情報
ルーターでトリガーイベントが発生するたびに、更新要求がPCRFに送信されます。以下の例は、CCR-GX-U(UはUPDATE_REQUESTを表す)とCCA-GX-Uパケット交換を示しています。
CCR-GX-Uパケットの例
CCR-GX-U ::= <Diameter Header: 272, REQ, PXY 16777238> { <Session-Id> } { Auth-Application-Id: 16777238 } { Origin-Host: <configurable-string> } { Origin-Realm: <configurable-string> } { Destination-Realm: <configurable-string> } { CC-Request-Type: UPDATE_REQUEST(2) } { CC-Request-Number: <u32> } [ Destination-Host: <configurable-string> ] -- if configured [ Origin-State-Id: <u32> ] -- if configured to send *[ Upstream data units ]
CCR-GX-U が再送信されると、T ビットが再計算されます。
CCA-GX-Uパケットの例
CCA-GX-U ::= <Diameter Header: 272, PXY, 16777238> { <Session-Id> } { Auth-Application-Id: 16777238 } { Origin-Host: <string> } -- should match destination-host if configured { Origin-Realm: <string> } -- should match destination-realm { Result-Code: <integer> } { CC-Request-Type: UPDATE_REQUEST(2) } { CC-Request-Number: <u32> } [ Origin-State-Id: <u32> ] -- Indicates PCRF restart *[ Downstream data units ]
PCRF は、 表 8 に示す結果カテゴリにマッピングされた結果コード AVP(AVP コード 268)を含む CCA-GX-U メッセージを返します。
結果コード-AVP 値 |
結果のカテゴリー |
---|---|
SUCCESS(2001)、LIMITED_SUCCSS(2002)、および有効なメッセージ |
成功 |
UNABLE_TO_DELIVER(3002)、REALM_NOT_SERVED(3003)、TOO_BUSY(3004)、LOOP_DETECTED(3005)、REDIRECT_INDICATION(3006) |
失敗 |
その他すべての Diameter パーマネント障害の結果コード AVP が 5000 以上、すべての Diameter プロトコル エラー結果コード AVP が 3000 以上 4000 未満 |
成功 |
無効なメッセージまたは応答がない場合のその他の結果コード AVP |
失敗 |
加入者のログアウト
クライアントアプリケーションが加入者ログアウト通知をAAAに送信すると、GxはCCR-GX-T(TがTERMINATION_REQUESTを表す)メッセージを送信し、プロビジョニングされた加入者セッションが終了したことをPCRFに通知します。
ルーターでトリガーイベントが発生するたびに、PCRFに終了要求が送信されます。以下の例は、CCR-GX-T および CCA-GX-T パケット交換を示しています。
CCR-GX-Tパケットの例
CCR-GX-T ::= <Diameter Header: 272, REQ, PXY 16777238> { <Session-Id> } { Auth-Application-Id: 16777238 } { Origin-Host: <configurable-string> } { Origin-Realm: <configurable-string> } { Destination-Realm: <configurable-string> } { CC-Request-Type: TERMINATION_REQUEST(3) } { CC-Request-Number: <u32> } [ Destination-Host: <configurable-string> ] -- if configured { Termination-Cause: DIAMETER_LOGOUT(1) } [ Origin-State-Id: <u32> ] -- if configured to send *[ Upstream data units ]
CCR-GX-T が再送信されると、T ビットが再計算されます。
CCA-GX-T パケットの例
CCA-GX-T ::= <Diameter Header: 272, PXY, 16777238> { <Session-Id> } { Auth-Application-Id: 16777238 } { Origin-Host: <string> } -- should match destination-host if configured { Origin-Realm: <string> } -- should match destination-realm { Result-Code: <integer> } { CC-Request-Type: TERMINATION_REQUEST(3) } { CC-Request-Number: <u32> } [ Origin-State-Id: <u32> ] -- Indicates PCRF restart *[ Downstream data units ]
PCRF は、 表 9 に示す結果カテゴリにマッピングされた結果コード AVP(AVP コード 268)を含む CCA-GX-T メッセージを返します。
結果コード-AVP 値 |
結果のカテゴリー |
---|---|
SUCCESS(2001)、LIMITED_SUCCSS(2002)、および有効なメッセージ |
成功 |
UNABLE_TO_DELIVER(3002)、REALM_NOT_SERVED(3003)、TOO_BUSY(3004)、LOOP_DETECTED(3005)、REDIRECT_INDICATION(3006) |
失敗 |
その他すべての Diameter パーマネント障害の結果コード AVP が 5000 以上、すべての Diameter プロトコル エラー結果コード AVP が 3000 以上 4000 未満 |
成功 |
無効なメッセージまたは応答がない場合のその他の結果コード AVP |
失敗 |
結果コード値が成功した場合、Gx は AAA に通知し、AAA はログアウトが完了したことをアプリケーションに通知します。GxがCCA-GX-Tメッセージを受信しない場合、または結果コードAVPに他の値がある場合、または欠落している場合、CCA-GX-Tメッセージが成功して返されるまで終了要求が再試行されます。ルーターは、CCA応答によって確認される別のCCR要求を送信することで、加入者のログアウトについてPCRFに通知します。PCRF は、RAR リクエストを使用して、加入者のログアウトを強制したり、適用されるサービスを変更したりすることもできます。
結果コード値が Failure の場合、リクエストは再試行されます。
加入者の切断
加入者の切断を実行するために、PCRF は RAR-GX-D(D は DISCONNECT を表す)を送信し、BPCEF は RAA-GX-D メッセージを返します。
以下の例は、RAR-GX-D と RAA-GX-D のパケット交換を示しています。
RAR-GX-Dパケットの例
RAR-GX-D ::= <Diameter Header: 258, PXY, 16777238> { <Session-Id> } { Auth-Application-Id: 16777238 } { Origin-Host: <string> } -- should match destination-host if configured { Origin-Realm: <string> } -- should match destination-realm { Destination-Realm: <string> } -- should match origin-realm { Destination-Host: <string> } -- should match origin-host { Re-Auth-Request-Type: AUTHORIZE_ONLY(0) } [ Origin-State-Id: <u32> ] -- Indicates PCRF restart { Session-Release-Cause: <enum> } *[ Downstream data units ] -- ignored
RAA-GX-Dパケットの例
RAA-GX-D ::= <Diameter Header: 272, REQ, PXY, 16777238> { <Session-Id> } { Auth-Application-Id: 16777238 } { Origin-Host: <configurable-string> } { Origin-Realm: <configurable-string> } { Result-Code: <integer> } [ Origin-State-Id: <u32> ] *[ Upstream data units ]
PCRF は、 表 10 に示す結果カテゴリにマッピングされた結果コード AVP(AVP コード 268)を含む RAA-GX-T メッセージを返します。
結果コード-AVP 値 |
結果のカテゴリー |
---|---|
DIAMETER_SUCCESS(2001) |
加入者の切断が進行中か、加入者が見つからない場合 |
DIAMETER_UNABLE_TO_COMPLY(5012) |
加入者は取り外しできません |
DIAMETER_TOO_BUSY(3004) |
未解決の切断要求が多すぎる |
BPCEF には、512 以上の RAR-GX-D メッセージまたは RAA-GX-D メッセージ用のバッファリング スペースが含まれています。
接続障害回復
Gxは、ルーターやPCRFの障害を検出するためにデバイス間の接続状態に依存しない。一部のイベントは接続状態に影響せず、他のイベントはデバイス間に Diameterリレーまたはプロキシがある場合には検出されない。
PCRF の接続障害を軽減するために、ルーターは次の障害回復手順を使用します。
PCRF が利用できない場合、デフォルト サービスをインストールして設定した場合、加入者ログインはそれに応じて続行されます。
無意識のプロビジョニングリクエストは、加入者がログアウトするまで無限に再生されます。
ログアウトリクエストは、最後のOCS問い合が完了するのを待ってから、認識されていないログアウトリクエストが24時間再生されます。
ルーターは、標準の Diameter トランスポート冗長性を使用して冗長 PCRF と通信します。
Gx耐障害性の重要な点は、加入者のログインおよび終了要求が、PCRFから十分な応答を受信するまで24時間再試行(再生)されるということです。コマ ンドを clear network-access pcrf subscribers
発行して、すべての PCRF 加入者をクリアできます。
ルーターとOCS間のGyのやり取りの理解
情報または問い合わせは、OCS(オンライン課金システム)とPCEF(Policy and Charging Enforcement Function)として機能するルーターとの間で、第3世代パートナーシッププロジェクト(3GPP)Gyプロトコルによって交換されます。OCS とのブロードバンド PCEF(BPCEF)のやり取りでは、一元的なユニット決定と一元的なレーティングによるオンライン セッション課金が使用されます。PCEF はオプションで使用状況を報告し、Gy プロトコルを使用して OCS から追加の許可を受けます。
Junos OS リリース 17.3R1 以降、Gy および Gx プロトコルを使用して、追加の OCS および PCRF 機能のサポートが追加されました。新しいステートメント:
accept-sdr
は、 階層レベル[edit access pcrf partition partition-name]
で PCRF パーティションに追加されます。alternative-partition-name
は、 階層レベル[edit access ocs partition partition-name]
で OCS パーティションに追加されます。
Junos OS リリース 18.1R1 以降、ブロードバンド PCEF は、OCS へのプライマリ パスと代替パスの両方が利用できない場合、OCS データのファイル バックアップを提供します。CCR-GY-T フレームは、遠隔地のファイルに保存されます。バックアップは 階層 [edit access ocs partition partition-name]
でサポートされています。
PCRF(Policy Control and Rules Charging Function)と PCEF の間で加入者のプロビジョニングが完了すると、ルーターは OCS と PCEF の間で以下の問い合わせの送信を開始します。
OCS への最初の尋問
最初の問い合わせの間、ルーターは、固定された必要な情報セットを含む Diameter CCR 要求を OCS 課金サーバーに送信します。次に、OCS課金サーバーは、有効期間、レーティンググループ、使用率クォータに返信します。
この実装フェーズでは、ルーターは、OCS の応答を待たずに加入者アクセスを許可し、OCS は常に必要なクォータを付与します。
Gyプロトコルを介してOCSと情報を通信するための課金サービスのリストを設定するには、 階層レベルで ステートメントを[edit access profile profile-name]
設定charging-service-list ocs
します。次の例は、CCR-GY-I と CCA-GY-I のパケット交換を示しています。
CCR-GY-I を再送信すると、T ビット(再送信される可能性があるメッセージ)が再計算されます。このフラグは、リンク フェイルオーバー手順の後に設定され、重複するリクエストの削除を支援します。
CCR-GY-I パケットの例
CCR-GY-I ::= <Diameter Header: 272, REQ, PXY 16777238> { <Session-Id> } { Origin-Host: <configurable-string> } { Origin-Realm: <configurable-string> } { Destination-Realm: <configurable-string> } { Auth-Application-Id: 4 } { Service-Context-Id: 98924@customer.com } { CC-Request-Type: INITIAL_REQUEST(1) } { CC-Request-Number: 0 } [ Destination-Host: <configurable-string> ] -- if configured [ User-Name: <string> ] [ Origin-State-Id: <u32> ] -- if configured to send [ Event-Timestamp: <timestamp> ] -- login timestamp, if included by config { Subscription-Id: { Subscription-Id-Type: <received-from-pcrf> } { Subscription-Id-Data: <received-from-pcrf> } } { Multiple-Services-Indicator: MULTIPLE_SERVICES_SUPPORTED(1) } { Multiple-Services-CC: { Service-Identifier: 7 } { Rating-group: 292 } } { Multiple-Services-CC: { Service-Identifier: 7 } { Rating-group: 293 } } { Multiple-Services-CC: { Service-Identifier: 7 } { Rating-group: 292 } } { Multiple-Services-CC: { Service-Identifier: 1 } { Rating-group: 17 } }
CCA-GY-I パケットの例
CCA-GY-I ::= <Diameter Header: 272, REQ, PXY 16777238> { <Session-Id> } { Result-Code: DIAMETER_SUCCESS(2001) } { Origin-Host: <string> } -- should match dest-host if configured { Origin-Realm: <string> } -- should match dest-realm { Auth-Application-Id: 4 } { CC-Request-Type: INITIAL_REQUEST(1) } { CC-Request-Number: 0 } { CC-Session-Failover: FAILOVER_NOT_SUPPORTED(0) } -– ignored } { Multiple-Services-CC: { Granted-Service-Unit: { CC-Time: 123456 } { CC-Total-Octets: 123455999000 } } { Service-Identifier: 7 } { Rating-group: 292 } { Validity-Time: 7200 } { Result-Code: DIAMETER_SUCCESS(2001) } } { Multiple-Services-CC: { Service-Identifier: 7 } { Rating-group: 293 } { Result-Code: DIAMETER_CREDIT_CONTROL_NOT_APPLICABLE(4011) } } { Multiple-Services-CC: { Service-Identifier: 7 } { Rating-group: 292 } { Result-Code: DIAMETER_CREDIT_CONTROL_NOT_APPLICABLE(4011) } } { Multiple-Services-CC: { Granted-Service-Unit: { CC-Time: 123456 } { CC-Total-Octets: 123455999000 } } { Service-Identifier: 1 } { Rating-group: 17 } { Result-Code: DIAMETER_SUCCESS(2001) } } { CC-Failure-Handling: TERMINATE(0) }
OCS への中間尋問
ルーターが固定の必要な情報セットをOCS課金サーバーに送信した後、OCS課金サーバーは有効期間、レーティンググループ、使用率クォータに返信します。有効期間とクォータの有効期限は、中間の問い合ーション イベントをトリガーします。
ルーターでトリガー イベントが発生するたびに、更新要求が OCS に送信されます。次の例は、CCR-GY-U(UはUPDATE_REQUESTを表す)とCCA-GY-Uパケット交換を示しています。
CCR-GY-U パケットの例
CCR-GY-U ::= <Diameter Header: 272, REQ, PXY 16777238> { <Session-Id> } { Origin-Host: <configurable-string> } { Origin-Realm: <configurable-string> } { Destination-Realm: <configurable-string> } { Auth-Application-Id: 4 } { Service-Context-Id: 98924@customer.com } { CC-Request-Type: UPDATE_REQUEST(2) } { CC-Request-Number: <integer> } [ Destination-Host: <configurable-string> ] -- if configured [ User-Name: <string> ] [ Origin-State-Id: <u32> ] -- if configured to send [ Event-Timestamp: <timestamp> ] -- change timestamp, if included by config { Multiple-Services-Indicator: MULTIPLE_SERVICES_SUPPORTED(1) } { Multiple-Services-CC: { Used-Service-Unit: { Reporting-Reason: VALIDITY_TIME(4) } { CC-Time: 7200 } { CC-Total-Octets: 12345 } { CC-Input-Octets: 10000 } { CC-Output-Octets: 2345 } } { Service-Identifier: 7 } { Rating-group: 292 } } { Multiple-Services-CC: { Used-Service-Unit: { Reporting-Reason: FINAL(2) } { CC-Time: 334556 } { CC-Total-Octets: 12345 } { CC-Input-Octets: 10000 } { CC-Output-Octets: 2345 } } { Service-Identifier: 1 } { Rating-group: 17 } } *[ More Multiple-Services-CC]
CCA-GY-U パケットの例
CCA-GY-U ::= <Diameter Header: 272, REQ, PXY 16777238> { <Session-Id> } { Result-Code: DIAMETER_SUCCESS(2001) } { Origin-Host: <string> } -- should match dest-host if configured { Origin-Realm: <string> } -- should match dest-realm { Auth-Application-Id: 4 } { CC-Request-Type: UPDATE_REQUEST(1) } { CC-Request-Number: <integer> } { Multiple-Services-CC: { Granted-Service-Unit: { CC-Time: 123456 } { CC-Total-Octets: 123455999000 } } { Service-Identifier: 7 } { Rating-group: 292 } { Validity-Time: 7200 } { Result-Code: DIAMETER_SUCCESS(2001) } } *[ More Multiple-Services-CC]
OCS に対する最後の問い合て
クライアント アプリケーションが加入者ログアウト通知を AAA に送信すると、Gy は CCR-GY-T(T はTERMINATION_REQUESTを表す)メッセージを送信し、プロビジョニングされた加入者が終了したことを OCS に通知します。
ルーターでトリガーイベントが発生するたびに、終了要求がOCSに送信されます。次の例は、CCR-GY-T と CCA-GY-T のパケット交換を示しています。
CCR-GY-T パケットの例
CCR-GY-T ::= <Diameter Header: 272, REQ, PXY 16777238> { <Session-Id> } { Origin-Host: <configurable-string> } { Origin-Realm: <configurable-string> } { Destination-Realm: <configurable-string> } { Auth-Application-Id: 4 } { Service-Context-Id: 98924@customer.com } { CC-Request-Type: TERMINATE_REQUEST(2) } { CC-Request-Number: <integer> } [ Destination-Host: <configurable-string> ] -- if configured [ User-Name: <string> ] [ Origin-State-Id: <u32> ] -- if configured to send [ Event-Timestamp: <timestamp> ] -- logout timestamp, if included by config { Termination-Cause: DIAMETER_LOGOUT(1) } { Multiple-Services-CC: { Used-Service-Unit: { Reporting-Reason: FINAL(2) } { CC-Total-Octets: 12345 } { CC-Input-Octets: 10000 } { CC-Output-Octets: 2345 } } { Service-Identifier: 7 } { Rating-group: 292 } } *[ More Multiple-Services-CC]
CCA-GY-T パケットの例
CCA-GY-T ::= <Diameter Header: 272, REQ, PXY 16777238> { <Session-Id> } { Result-Code: DIAMETER_SUCCESS(2001) } { Origin-Host: <string> } -- should match dest-host if configured { Origin-Realm: <string> } -- should match dest-realm { Auth-Application-Id: 4 } { CC-Request-Type: TERMINATE_REQUEST(1) } { CC-Request-Number: <integer> }
接続障害回復
Gy はルーターや OCS の障害を検出するためにデバイス間の接続状態に依存しません。一部のイベントは接続状態に影響せず、その他のイベントはデバイス間に Diameter リレーまたはプロキシがある場合は検出されません。
OCS の接続障害を緩和するために、ルーターは次の障害回復手順を使用します。
OCSが利用できない場合、 階層レベルで ステートメントを設定することで、加入者トラフィックを
force-continue
[edit access ocs partition partition-name]
許可するように設定できます。メモ:force-continue
ステートメントは、必須の設定ステートメントです。無意識のうちに最初から中間の問い合せが、加入者がログアウトするまで、無期限に再生されます。
知らない最後の問い合げが最大 24 時間リプレイされます。
ルーターは、標準的な Diameter トランスポートの冗長性を使用して、冗長な OCS と通信します。
トランスポート冗長イベントを設定して、アプリケーション トラフィックの障害をトリガーできます。
Gyの耐障害性の重要な点は、十分な応答がOCSから受信されるまで、加入者のログインおよび終了要求を24時間再試行(再生)することです。コマンドを clear network-access ocs statistics
発行して、すべてのOCS統計をクリアできます。
セッションリクエストの中止
受信しているMXシリーズルーターが最終的なデータを収集し、最終的な問い合さを投稿すると、OCSがASR(Abort-Session-Request)を発行する可能性があります。MXシリーズルーターが応答を受信すると、関係するセッションのOCSの更新を停止します。
Gy ファイル バックアップの概要
Gy プロトコルは OCS とも呼ばれ、中間データを保持しながら増分使用状況レポートに基づいています。そのため、OCS サーバーには、直径のトランスポート冗長性、OCS への代替パス、ファイル バックアップなど、複数の障害保護メカニズムが含まれています。Junos OS リリース 18.1R1 以降、プライマリ パスも代替パスも利用できない場合、ブロードバンド PCEF はファイル バックアップを提供します。CCR-GY-T フレームは、遠隔地のファイルに保存されます。
OCS バックアップは、OCS 最終応答タイムアウトが期限切れになったときに有効になります。データはバックアッププロセスのためにキューに入れ、加入者のログアウトはpcrfセッションの終了に進みます。いずれの場合も、バックアップ操作は以下の設定パラメーターによって制御されます。
backup-limit—バックアップ エントリーの総数に制限されます。この制限に達すると、バックアップオーバーフロー設定に応じて、新しい加入者のログインに失敗したり、最も古いバックアップエントリーが削除されたりします。
backup-timeout— バックアップ操作のタイムアウト。
backup-overflow— バックアップ エントリーの数がバックアップ制限を超えた場合のアクションを制御します。
OCS SFTPバックアップ
stfp-backupは、実装された最初のバックアップメカニズムです。操作は、以下のパラメーターによって制御されます。
累積タイムアウト – ファイルは、最初の CCR-GY-T 送信のファイル累積時間の後に書き込まれます。
累積カウント – ファイル・アカウント・カウントの要求数が満たされた後にファイルが書き込まれます。
累積サイズ – ファイルは、そのサイズが累積サイズ制限に達した後に書き込まれます。
再試行間隔 - 失敗した書き込み操作はすべて、backup-timeoutが累積するまで、この間隔の後に再試行されます。
response-timeout – 個々のsftpコマンド応答のタイムアウト。
OCS SFTP-Backup サーバーは、アドレス、ログイン、パスワード、ディレクトリ、ファイルプレフィックスで構成されます。ターゲット・ディレクトリーがデフォルトで存在しない場合は、そのディレクトリーが作成されます。同じ名前のターゲットファイルがすでに存在する場合は、上書きされます。
Gyファイルバックアップのメリット
内部ネットワークの不安定性に対処するためのもう 1 つの方法を提供します。
PCRF、PCEF、OCS 間の相互作用を理解する
PCRF(Policy and Charging Rules Function)、PCEF(Policy and Charging Enforcement Function)、OCS(Online Charging System)は、加入者サービスを提供および課金するために対話します。これらのやり取りには、加入者ログイン、既存セッションのサービス更新、接続と監視、加入者の終端とログアウトが含まれます。
図 3 は、第 3 世代パートナーシップ プロジェクト(3GPP)のポリシーおよび課金制御(PCC)アーキテクチャ全体のコンポーネントを示しています。PCRFは、3GPP Gxプロトコルを使用して、MXシリーズルーター上のPCEFにルールをプッシュします。PCEF はサービス データ フローを検出し、PCRF から受信したルールを適用します。オプションとして、PCEF は 3GPP Gy プロトコルを使用して OCS と対話し、クォータとクレジット制御のポリシーと課金の許可を取得します。OCS とのブロードバンド PCEF(BPCEF)のやり取りでは、一元的なユニット決定と一元的なレーティングによるオンライン セッション課金が使用されます。
PCRF は、既存のセッションに適用されたルールに対する変更をプッシュすることもできます。ただし、レーティング グループの変更はサポートされていません。また、 ステートメントを で設定 force-continue
する [edit access ocs partition partition-name] hierarchy level
必要があります。
ログイン操作
このログイン イベント シーケンスは、PCEF 上のサービス データ フローの検出によってトリガーされます。これは通常、加入者(CPE)によって送信された DHCP DISCOVER または PPPoE PADI パケットです。
PCEF は、加入者を識別する情報を含む CCR-GX-I を PCRF に送信します。
PCRF は、加入者に適用するルールのインストラクションを PCEF に CCA-GX-I と返信します。
PCEF は、加入者に要求されたサービス/ルールをインストールします。
OCS を使用している場合、PCEF は CCR-GY-I メッセージを使用して最初の問い合てを OCS に送信し、OCS は CCA-GY-I メッセージを使用して該当するレポートを PCRF に送信します。
設定されている場合、PCEF は、要求されたサービス/ルールの処理後に、CCR-GX-U メッセージによって通知を PCRF に送信します。
以下の両方に該当する場合、このルールは 非アクティブ として PCRF に報告されます。
サービス動的プロファイルのインスタンス化に失敗します。
課金ルールに対して、リソース割り当て通知(ENABLE_NOTIFICATION)が設定されています。
ルールが非アクティブと報告された場合、加入者のログインやその他のルールには影響しません。
次のすべてが当てはまる場合、このルールは アクティブ として PCRF に報告されます。
サービス動的プロファイルのインスタンス化は成功します。
課金ルールに対して、リソース割り当て通知(ENABLE_NOTIFICATION)が設定されています。
SUCCESSFUL_RESOURCE_ALLOCATION イベント トリガーが要求で設定されます。
レポートするルールがない場合、レポートは送信されません。
PCRF は CCA-GX-U メッセージを返します。
PCEF が加入者のサービスをアクティブ化します。
インタラクションの更新
このイベントの更新シーケンスは、PCRF から PCEF が受信した RAR-GX-U メッセージによってトリガーされます。
更新要求にレーティング グループを含むルールのインストールまたは変更が含まれている場合、PCEF はその要求を拒否します。それ以外の場合、PCRFにRAA-GX-Uメッセージを送信して要求を確認します。
PCEF は、サービスの削除とインストールのプロセスを開始します。
PCEF は、サービスの削除とインストールのプロセスが完了するのを待ち、必要に応じて OCS にレポートするための最終的なデータ収集プロセスを開始します。最終的な統計情報を収集すると、PCEF は CCR-GY-U リクエストを送信して OCS に通知します。これは、次の場合のそれぞれで、既存のサービスの削除プロセスの一部です。
サービスが削除されると、レーティング グループが設定されます。
レーティンググループの新しいルールを追加した場合。
レーティング グループのルールを削除して追加した場合。
PCEF は、CCR-GX-U メッセージを使用して、該当するレポートを PCRF に送信します。
以下の両方に該当する場合、このルールは 非アクティブ として PCRF に報告されます。
サービス動的プロファイルのインスタンス化に失敗します。
課金ルールに対して、リソース割り当て通知(ENABLE_NOTIFICATION)が設定されています。
非アクティブとして報告されたルールは、更新やその他のルールには影響しません。
次のすべてが当てはまる場合、このルールは アクティブ として PCRF に報告されます。
サービス動的プロファイルのインスタンス化は成功します。
課金ルールに対して、リソース割り当て通知(ENABLE_NOTIFICATION)が設定されています。
SUCCESSFUL_RESOURCE_ALLOCATION イベント トリガーが要求で設定されます。
レポートするルールがない場合、レポートは送信されません。
クォータの有効期限と有効期間のインタラクション
クォータの期限切れおよび有効期間の対話では、ルーターは CCR-GY-U メッセージを使用して中間尋問を OCS に送信し、OCS 応答を処理します。
接続と監視のやり取り
PCRF、OCS、または Diameter リレー/プロキシー サーバーとの接続を確立すると、Diameter デーモンは標準の CER(機能交換要求)/CEA(Capability Exchange Answer)トランザクションを実行します。既存の Junos OS Diameter インフラストラクチャを使用して、必要な冗長性機能を備えた適切なトポロジーを設定します。さらに、PCRF 通信と OCS 通信の両方、およびその他のアプリケーションに同じ Diameter 接続を使用できます。
次の例は、2 つの異なる通信接続シナリオを示しています。
PCRF との通信に使用する専用接続を使用した CER の例
CER ::= <Diameter Header: 257, REQ> { Origin-Realm: CSim.PCRF.net } { Origin-Host: MX-GWR3 } { Host-IP-Address: 10.8.52.91 } { Vendor-Id: 2636 } { Product-Name: JUNOS } [ Origin-State-Id: 7777 ] -- if configured { Supported-Vendor-Id: 10415 } { Supported-Vendor-Id: 2636 } -- have Juniper VSAs { Auth-Application-Id: 16777238 } { Vendor-Specific-Application-Id { { Vendor-Id: 10415 } { Auth-Application-Id: 16777238 } { Acct-Application-Id: 16777238 } }
または [edit access ocs partition partition-name]
階層レベルで[edit access pcrf partition partition-name]
ルーターのsend-origin-state-id
ステートメントを設定すると、CER、DWR(Device Watchdog Request)/DWA(Device Watchdog Answer)、DPR(Disconnect Peer Request)/DPA(Disconnect Peer Answer)などの Diameter レベルメッセージに発信元ステートIDが含まれます。
PCRFとOCSの両方と通信するために使用される専用接続を使用したCERの例
CER ::= <Diameter Header: 257, REQ> { Origin-Realm: CSim.PCRF.net } { Origin-Host: MX-GWR3 } { Host-IP-Address: 10.8.52.91 } { Vendor-Id: 2636 } { Product-Name: JUNOS } [ Origin-State-Id: 7777 ] -- if configured { Supported-Vendor-Id: 10415 } { Supported-Vendor-Id: 2636 } -- have Juniper VSAs { Auth-Application-Id: 4 } -- this is the difference with previous { Auth-Application-Id: 16777238 } { Vendor-Specific-Application-Id { { Vendor-Id: 10415 } { Auth-Application-Id: 16777238 } { Acct-Application-Id: 16777238 } }
Auth-Application-Id: 4フィールドと値は、OCSの認証アプリケーションIDです。これは、1つ目の例と2番目の例の違いです。
標準的な DWR/DWA および DPR/DPA メッセージを使用して、接続を監視および管理します。
ログアウトインタラクション
この一連のイベントのログアウトは、以下のいずれかによってトリガーされます。
DHCP リリースや PPPoE PADT パケットなどの加入者ログアウト要求。
PCEF は、加入者セッションを終了するリクエストとともに PCRF から RAR を受信します。
ログアウトがトリガーされると、次のシーケンスが発生します。
システム インフラストラクチャは、加入者のログアウトが開始されたことを OCS に通知します。
該当する場合、OCS は最終的なデータ収集プロセスを開始します。
削除されたサービスにレーティング グループがある場合は、このサービスの最終的なデータを報告する必要があります。OCS は、必要に応じて最終的なデータ収集を開始します。
PCRFとPCEFの両方が、最終的な尋問プロセスが完了するのを待ちます。
PCEF は、終了要求(CCR-GX-T メッセージ)を PCRF に送信し、PCRF から応答 (CCA-GX-T メッセージ) を待ちます。
PCEF は、加入者のログアウト プロセスを完了します。
PCRF のアップストリームおよびダウンストリーム メッセージについて
MX シリーズ ルーターには、ダウンストリームトランザクションとアップストリームトランザクションの両方のデータ過負荷から保護するためのさまざまな対策が実装されています。ダウンストリームトランザクションは、過負荷状態の下でネットワークからの入力を調整することで保護されます。アップストリームのトランザクションは、未処理のリクエストの数を制限し、信頼性の高い回復のために最初の未承認メッセージのゆっくりとした再試行を使用することで保護されます。
ポリシー&チャージング適用機能(PCEF)環境に組み込まれた機能により、過度の加入者ログイン率による過負荷から保護します。再認証要求(RAR-GX)メッセージによってルールの変更と切断操作が多すぎる場合、ルーターは、結果コードである DIAMETER_TOO_BUSY(3004)を使用して、再認証応答(RAA-GX)応答を送信します。
ルーターのAAAコンポーネント内では、セッションはセッションデータベース(SDB)内の加入者(クライアント)セッションエントリーを表します。
これは、加入者セッションのみの表現です。電話番号に似た接続非依存の恒久的な識別子ではありません。加入者が切断と再接続を行い、2番目の接続用に別のセッションIDを受信した場合。
セッションIDは、セッションID(AVPコード263)で伝達されます。セッションとセッション ID 値の間には 1 対 1 の対応があります。セッションIDは、一意のルーターIDに紐付けされ、他の情報を参照せずにユーザーセッションを識別するために使用されるため、グローバルかつ永遠に一意です。切断および再接続イベントからの 1 つなど、複数のセッションに同じ加入者をマッピングできます。ただし、セッションは常に単一加入者に関連付けられています。セッションID AVPのデフォルトフォーマットは次のとおりです。
Session-Id AVP ::=<DiameterIdentity>; <upper 32 bits of the AAA COMPONENT session-id>; <lower 32 bits of the AAA COMPONENT session-id>;
フィールドは DiameterIdentity Diameter 原点ホストに設定する値です。内部セッションIDは、昇順で割り当てられた64ビットの整数です。セッションID文字列の両方の数値部分は、 形式を使用して %010u 生成されます。これにより、Session-Id AVP値が内部64ビットセッションと同じ順序で語句的に同じ順序であることを保証します。
拡張セッション ID を使用するようにルーターを設定して、セッション スタンプを ID に追加することもできます。セッションスタンプは、ルーターがCCR-GX-Iを作成するUTC時刻で構成されます。この場合、セッションID AVPの形式は次のとおりです。
Session-Id AVP ::=<DiameterIdentity>; <upper 32 bits of the AAA COMPONENT session-id>; <lower 32 bits of the AAA COMPONENT session-id>; <32 bits of UTC time>;
AVP の最初の 64 ビットは変更されず、PCRF が再初期化をトレースできるようにします。
PCRF サーバーのエラーに応じてセッションを再度初期化する場合、拡張セッション ID を使用するようにルーターを常に設定します。詳細については、 ルーターとPCRF間のGxインタラクションの 理解を参照してください。
PCRF(Policy and Charging Rules Function)は、3GPP Gxプロトコルとオンラインポリシーインターフェイスを使用して、ルールとメッセージをPCEFにプッシュします。PCRF および Gx プロトコルには、以下のメッセージが含まれています。
一般的なアップストリーム メッセージ
開始、更新、終了に対する信用制御応答(CCR-GX-I、CCR-GX-U、および CCR-GX-T)および RAA-GX のアップストリーム メッセージには、以下のルール、パラメーター、データが含まれる場合があります。
イベント タイムスタンプ AVP
以下に、PCRF と Gx 間の CCR-GX-I、CCR-GX-U、CCR-GX-T、および RAA-GX メッセージの AVP を示します。
{ Event-Timestamp: <timestamp> }
イベントタイムスタンプAVPを設定すると、ダウンストリームメッセージに含まれます。 表 11 のメッセージ定義は、トランザクションによって異なります。
メッセージ |
定義 |
---|---|
CCR-GX-I |
加入者ログインタイムスタンプ |
課金ルールのインストール通知
以下の通知は、PCRF と Gx 間の CCR-GX-U メッセージの課金ルールのインストールの失敗したインストール例と正常なインストール例を示しています。
クライアントのログアウト時に、未承認のレポートがまだ保留中の場合、これらの課金ルールは CCR-GX-T メッセージに含まれます。
ルールのインストール失敗を報告する通知
{ Charging-Rule-Report { Charging-Rule-Name: <string> } { Charging-Rule-Name: <string> } { PCC-Rule-Status: INACTIVE(1) } { Rule-Failure-Code: UNKNOWN_RULE_NAME(1) } }
ルールのインストールの成功を通知する通知
{ Charging-Rule-Report { Charging-Rule-Name: <string> } { Charging-Rule-Name: <string> } { PCC-Rule-Status: ACTIVE(0) } }
イベント トリガー コマンド
PCRF と Gx 間の CCR-GX および RAA-GX メッセージに対して、事前定義されたイベント・トリガー・コマンドを以下に示します。
{ Event-Trigger: SUCCESSFUL_RESOURCE_ALLOCATION(22) }
一般的なダウンストリーム メッセージ
初期化および更新のための信用制御応答(CCA-GX-I および CCA-GX-U)および RAR-GX のダウンストリーム メッセージには、パラメーターとデータに以下の事前定義されたルールが含まれる場合があります。
CCA-GX-T(終端)メッセージは、ダウンストリーム メッセージとして含まれません。
課金ルールのインストール コマンド
以下の例は、PCRF と Gx 間の CCA-GX および RAR-GX メッセージに対して事前定義されたルール・インストール・コマンドを示しています。
{ Charging-Rule-Install { Charging-Rule-Name: “fixed-cos” } { Charging-Rule-Definition: { Charging-Rule-Name: “firewall” } { Service-Identifier: 10 } { Rating-Group: 292 } { Juniper-Param-V4-Input-Filter: “my_input_filter” } { Juniper-Param-V4-Output-Filter: “my_output_filter” } } [ Resource-Allocation-Notification: ENABLE_NOTIFICATION(0) ] }
一部の PCRF では、リソース割り当て通知 AVP を生成できない場合があります。その結果、 階層レベルの report-resource-allocation
[edit access pcrf partition partition-name]
ステートメントは、生成されたレポートをデフォルトで提供します。
課金ルールの削除コマンド
以下の例では、PCRF と Gx 間の CCA-GX および RAR-GX メッセージに対して事前定義されたルール除去コマンドを示しています。
{ Charging-Rule-Remove { Charging-Rule-Name: “predefined-ftp” } { Charging-Rule-Name: “firewall” } }
ルーターは、ルールのインストール操作の前にすべてのルール削除操作を処理するため、既存のルールの削除と、1 回のトランザクションで同じベース名を持つルールのインストールの両方を同時に要求できます。
イベント トリガー コマンド
PCRF と Gx 間の CCA-GX および RAR-GX メッセージに対して、事前定義されたイベント・トリガー・コマンドを以下に示します。
{ Event-Trigger: SUCCESSFUL_RESOURCE_ALLOCATION(22) }
SUCCESSFUL_RESOURCE_ALLOCATION(22)トリガー値がダウンストリーム データに存在する場合、ブロードバンド PCEF は、課金ルールインストール AVP でリソース割り当て通知 AVP とマークされたルールのインストールが正常に完了したことを報告します。
一部の PCRF では、このイベントトリガーが生成できない場合があります。その結果、 階層レベルの report-successful-resource-allocation
[edit access pcrf partition partition-name]
ステートメントは、生成されたレポートをデフォルトで提供します。
OCS パーティションの設定
OCS(オンライン課金システム)は、特定の論理システム内で動作します。ルーティング インスタンス コンテキストはパーティションと呼ばれます。
現在、1 つのパーティションのみがサポートされています。デフォルトの論理システム:ルーティングインスタンスコンテキスト内で設定する必要があります。
OCS パーティションを設定する前に、次のタスクを実行します。
階層レベルで Diameter インスタンスを設定します
[edit diameter]
。直径 の設定を参照してください。
OCS パーティションの設定は、パーティションの名前を指定してから、多数のパラメーターを定義または関連付けてパーティションの特性を定義することです。
OCS パーティションを設定するには:
PCRF パーティションの設定
PCRF(Policy Control and Rules Charging Function)は、特定の論理システム内で動作します。ルーティング インスタンス コンテキストは、パーティションと呼ばれます。
現在、1 つのパーティションのみがサポートされています。デフォルトの論理システム:ルーティングインスタンスコンテキスト内で設定する必要があります。
PCRF パーティションを設定する前に、以下のタスクを実行します。
階層レベルで Diameter インスタンスを設定します
[edit diameter]
。直径 の設定を参照してください。
PCRF パーティションの設定は、パーティションの名前を付けた後、多数のパラメーターを定義または関連付けてパーティションの特性を定義することです。
PCRF パーティションを設定するには:
OCSグローバルパラメーターの設定
第 3 世代パートナーシップ プロジェクト(3GPP)のグローバル属性を設定できます。OCS(オンライン課金システム)の Diameter クレジット制御サービス課金システムは、PCEF(Policy and Charging Enforcement Function)と対話します。
現在、唯一設定可能なグローバル属性は、サービスプロバイダまたはオペレーターが割り当てるサービスコンテキスト識別子です。この値は、サービスコンテキストID AVPに対応し、サービス識別子-AVPと一緒に Diameterクレジット制御サービスを一意かつグローバルに識別します。
OCSグローバルパラメーターを設定するには:
サービスコンテキスト識別子を設定します。
[edit access ocs global] user@host# set service-context-id service-context