次のコールフローは、Pure-P PDN の初期接続手順の概要を示しています。

• P-GW は S5/S8 インターフェイスで APN を含むセッション作成要求メッセージを受信します。

• P-GW-C はデータパスを確立するために、PRD、FAR 情報を使用して、Sxb インターフェイスから選択された P-GW-U に向けて Sx 確立要求を開始します。PGW-C は TEID（トンネル識別子）の割り当てをサポートしていません。 トンネル識別子は PGW-U によって割り当てられます。

• リソースが割り当てられると（TEID など）、P-GW-U は P-GW-C に Sx 確立応答メッセージを送信します。

• P-GW は、割り当てられたアドレス、TEID、および追加情報を含む Create Session Response メッセージで S-GW に応答します。

• S5/S8 データプレーントンネルが確立され、PGW-U は PDN との間でパケットを送受信できます。

次のコールフローは、Pure-P PDN の初期切断手順の概要を示しています。

• P-GW は S5/S8 インターフェイスで APN を含むセッション作成要求メッセージを受信します。

• P-GW-C はデータパスを確立するために、PRD、FAR 情報を使用して、Sxb インターフェイスから選択された P-GW-U に向けて Sx 確立要求を開始します。PGW-C は TEID（トンネル識別子）の割り当てをサポートしていません。 トンネル識別子は PGW-U によって割り当てられます。

• リソースが割り当てられると（TEID など）、P-GW-U は P-GW-C に Sx 確立応答メッセージを送信します。

• P-GW は、割り当てられたアドレス、TEID、および追加情報を含む Create Session Response メッセージで S-GW に応答します。

• S5/S8 データプレーントンネルが確立され、PGW-U は PDN との間でパケットを送受信できます。

次のコールフローは、Pure-S PDN の初期接続手順の概要を示しています。

• S11 インターフェイスで、S-GW-C は MME から、アクセスポイント名（APN）を含むセッション作成要求メッセージを受信します。

• S-GW-C は、データパスを確立するため、選択した S-GW-U への Sxa インターフェイスで PDR、FAR 情報を含む Sx 確立要求を開始します。このとき、S-GW-C による TEID（トンネル識別子）の割り当てはサポートされません。割り当ては S-GW-U が行います。

• egree TEID などのリソース割り当て後、S-GW-U は S-GW-C に対して Sx 確立応答メッセージを送信します。

• S-GW-C は、選択した P-GW-C に対してセッション作成要求を開始します。

• P-GW-C は、IP アドレスとデフォルトベアラー関連情報を含むセッション作成応答で応答します。

• SGW-C は、既存のセッションの FAR（転送アクション）情報を更新するため、SGW-U に対して Sx 変更要求メッセージを開始します。

• SGW-U は、情報を更新した後、Sx 変更の成功応答を返します。

• SGW-C は、デフォルトベアラーに必要なすべての情報を含むセッション作成応答を MME に送信します。

• MME は、eNodeB の F-TEID 情報を受信すると、SGW-C に対するベアラー変更要求メッセージを開始します。

• SGW-C は、eNodeB の F-TEID の FAR 情報を更新するため、SGW-U に対して Sx 変更要求を開始します。

• 正常に更新されると、Sx 変更応答が SGW-C に送信されます。

• 今度は SGW-C が MME に変更応答メッセージを送信して、接続手順を完了します。

• SGW-U では、eNodeB への S1U 側のデータトンネルと PGW-U への S5/S8 側のデータトンネルが確立しました。これで SGW-U は、PGW および eNodeB との間でパケットを送受信できます。

• S5/S8 データプレーントンネルが確立され、PGW-U は PDN との間でパケットを送受信できます。

次のコールフローは、Pure-S PDN の初期切断手順の概要を示しています。

• MME からセッション削除要求を受信すると、SGW は SGW-U への Sx 削除要求メッセージを開始します。

• SGW-U は、割り当てられたすべてのユーザープレーンリソースをクリアし、Cause Success とともに SGW-C に応答します。

• SGW-C は、セッション削除応答メッセージで MME に応答します。

CUPS アーキテクチャでは、Pure-S コール向けの専用ベアラーの追加、削除、および更新がサポートされています。

この機能をサポートするため、次の機能が追加されています。

• SAEGW-CP は、Pure-S コール専用ベアラーのベアラー作成要求をサポートします。

• SAEGW -CP は、単一のベアラー作成要求で複数のベアラーコンテキストに対応できます。

• SAEGW-CP は、異なる PDN に対する複数のベアラー作成要求を並行してサポートします。これらの PDN は、Pure-S PDN または Collapsed と Pure-S の組み合わせです。

• SAEGW-UP は、ベアラーごとに Pure-S コールの VPP でアップリンク方向とダウンリンク方向のベアラーストリームを作成します。各方向ごとのストリーム数は、GTP-U サービスの IP アドレスによって異なります。

• SAEGW-CP は、専用ベアラーを使用したアクセスベアラー解放（RAB）要求をサポートしているため、すべてのベアラーに対応するすべての FAR が変更されます。

• SAEGW-CP は、専用ベアラーを使用したベアラー変更要求（アイドルモード、接続モード）をサポートします。

• SAEGW-CP は、MME からのベアラー作成応答の障害処理をサポートします。

• SAEGW-CP および SAEGW-UP は、VPP を使用したデフォルトおよび専用ベアラーの DSCP マーキングをサポートします。

• SAEGW-CP および SAEGW-UP は、専用ベアラーのベアラー削除要求をサポートします。SAEGW-UP は、それらのベアラーに属するベアラーストリームと TEP エントリを削除します。

• SAEGW-CP は、コールがアイドル状態の場合に Pure-S 専用ベアラーの作成をサポートします。

• SAEGW-CP は、Pure-S 専用ベアラーの S-GW 再配置（X2 ベースと S1 ベースの両方）をサポートします。

• SAEGW-CP は、Pure-S 専用ベアラーの更新シナリオをサポートします。

• SAEGW-CP は、セッション作成応答とともに Pure-S コール専用ベアラーのベアラー作成要求のピギーバックをサポートします。

• SAEGW-CP は、ベアラー変更要求とともに Pure-S コール専用ベアラーのベアラー作成応答のピギーバックをサポートします。

• P-GW が CCA-I の一部としてベアラー作成を受信し、P-GW がピギーバック要求を送信しない場合、SAEGW-CP は Pure-S 専用ベアラ―の作成をサポートします。この結果、セッション作成応答の後にベアラー作成要求が続きます。

• SAEGW-CP は、Pure-S 専用ベアラーを使用したセッションリカバリと ICSR をサポートします。

• SAEGW-CP は、ベアラー作成要求とベアラー削除要求（デフォルトのベアラー）のコリジョンをサポートします。

• SAEGW-CP は、ベアラー作成要求とセッション削除要求のコリジョンをサポートします。

• SAEGW-CP は、ベアラー作成応答とベアラー削除要求（デフォルトのベアラー）のコリジョンをサポートします。

• SAEGW-CP は、ベアラー作成応答とセッション削除要求のコリジョンをサポートします。

• SAEGW-CP は、Pure-S のデフォルトおよび専用ベアラーを使用した終了マーカーをサポートします。

• SAEGW-UP は、Pure-S のデフォルトおよび専用ベアラーを使用したセッションリカバリをサポートします。

• SAEGW-UP は、アイドル状態からアクティブ状態に遷移中の IPv4 から IPv6 へ、または IPv6 から IPv4 への IP トランスポートの動作、および S1U インターフェイスでのハンドオーバー手順をサポートします。接続時に S1U で選択されたトランスポートがサポートされます。たとえば、IPv4 eNodeB から IPv6 eNodeB への eNode ハンドオーバーが該当します。

• SAEGW-CP は、原因が Partially Accepted および Context Not Found の CBRsp をサポートします。

• SAEGW-CP は Pure-S コールのダウンリンク方向のデータ通知をサポートしているため、UE が Pure-S コールでアイドル状態に遷移すると、FAR アクションは バッファに設定されます。

• SAEGW-CP は、原因が PARTIALLY_ACCEPTED でコンテキストが見つからない場合のベアラー更新応答をサポートします。

• SAEGW-CP は、ユーザープレーンノードを含む他のピアノードからのエラー処理と障害処理をサポートします。

Pure-S コールの場合、アイドル セッション タイムアウトはサポートされていません。

次のコールフローは、Collapsed PDN の初期接続手順の概要を示しています。

1. CUPS SAEGW Collapsed コールの場合、SAEGW-C で次の処理が実行されます。

   • Gx インタラクション後、Gx 通信（CCR-I および CCA-I）を実行します。

   • IP プール（IP プールに関連付けられた APN）を使用して設定された user-plane-profile に基づいてユーザープレーンを選択します。

   • GTP-U セッションを確立します（IPv6/IPv4v6 PDN の場合、RA/RS に必要）。

   • 選択したユーザープレーンと Sxab のインタラクションを実行します。

2. Sx 確立要求には、次の情報が含まれます。

   • S-GW アップリンクおよびダウンリンクデータパス（Sxa タイプ PDR）の Create PDR/FAR 情報。

   • アップリンクおよびダウンリンクデータパス（Sxb タイプ PDR）の Create PDR/FAR/URR 情報。ダイナミック/事前定義/静的ルールの場合。

   • RA/RS（Sxb タイプ PDR）の Create PDR/FAR：IPv6/IPv4v6 PDN タイプに必要。

   • さらに、次の目的で F-TEID を割り当てるように、コントロールプレーンがユーザープレーンに要求します。

     • S-GW 入力「S1-U S-GW F-TEID」

     • S-GW 出力「S5/S8-U S-GW F-TEID」

     • P-GW 入力 PDR「S5/S8-U P-GW F-TEID」

3. ユーザープレーンは、Sx セッション確立応答の一部として次の情報を提供します。

   • 作成された PDR：S-GW 入力 PDR「S1-U S-GW F-TEID」

   • 作成された PDR：S-GW 出力 PDR「S5/S8-U S-GW F-TEID」

   • 作成された PDR：P-GW 入力 PDR「S5/S8-U P-GW F-TEID」

4. 正常な Sx セッション確立応答を受信すると、コントロールプレーンは次の情報を使用して Sx 変更要求をトリガーします。

   • 「S5/S8-U S-GW F-TEID」の IP アドレス情報に基づいて「Outer Header Removal」を使用して P-GW（Sxb）の「アップリンク PDR」を更新

   • 「Outer Header Creation」を「S5/S8-U S-GW F-TEID」として P-GW（Sxb）の「ダウンリンク FAR」を更新

   • 「Outer Header Creation」を「S5/S8-U P-GW F-TEID」として S-GW（Sxa）の「アップリンク FAR」を更新

   • 「S5/S8-U P-GW F-TEID」の IP アドレス情報に基づいて「Outer Header Removal」を使用して S-GW（Sxa）の「ダウンリンクPDR」を更新

5. Sx セッション変更応答を受信すると、SAEGW-C は「S1-U S-GW F-TEID」および「S5/S8-U P-GW F-TEID」を使用してセッション作成応答を MME に送信します。

6. ベアラー変更要求（MBR）を受信すると、SAEGW-C で次の処理が実行されます。

   • Sx セッション変更要求のトリガー：

     • 「Outer Header Creation」を「S1 eNodeB F-TEID」としてダウンリンク FAR を更新します。

     • 「S1 eNodeB F-TEID」の IP アドレス情報に基づいて、「Outer Header Removal」を使用してアップリンク PDR を更新します。

7. Sx セッション変更応答を受信すると、SAEGW-SGW-C は「S1-U S-GW F-TEID」を使用して MBR を送信します。

• ユーザープレーンモジュールは、セッション確立要求の一部として受信した URR のリストの保存をサポートします。

• 各 PDR は、1 つ以上の URR に関連付けられます。

• 特定の URR が別の URR にリンクされます。

• 各 URR には、測定方法（時間またはボリューム）と、ユーザープレーンが使用状況レポートを送信する必要があるイベントを示すレポートトリガーが含まれています。

• URR には、Gy-URR のボリュームクォータとボリュームしきい値の両方が存在します。

ユーザープレーンから送信されるこのメッセージは、コントロールプレーンからのセッション削除要求への応答です。このメッセージにより、ユーザープレーンで Sx セッションが終了します。使用状況レポートは、Sx セッション削除応答の一部として含まれています。

オンライン課金システム（OCS）で発生した問題、またはポリシー/課金適用機能（PCEF）と OCS 間の接続で発生した問題を解決するため、コントロールプレーン（CP）で Gy インターフェイスに対する Server-Unreachable（SU）メカニズムが設定されます。SU 設定により、障害発生後でもセッションを継続できるようになります。そのためのオプションとして、セッションがオフラインに変換されるまたは終了されるまでの暫定クォータ（ボリュームや時間）とサーバー再試行回数を設定できます。

新しい使用状況レポートルール（URR）バケットが作成されます。このバケットには、Gy セッションが SU 状態になったときの SU クォータが含まれます。新しい URR の ID は、SU URR が割り当てられると動的に生成されます。

CUPS ユーザープレーン（UP）ノードでは、既存の Vector Packet Processor（VPP）ストリームが新しい LC レコードによって変更されます。このレコードには、更新された SU URR バケットと既存の課金バケットが含まれます。

VPP ストリームが SU 状態の場合、GyURR と SU URR の 2 つのクォータ行を使用できます。GyURR が [linked-usage-reporting] トリガーが設定された状態で SU 状態になった場合、SU URR のクォータ行は VPP ストリームにリンクされます。

ここでは、CUPS における SU コールフローについて説明します。

CUPS における新しい動作

CUPS の新たな SU メカニズムは次のとおりです。

• 非 CUPS アーキテクチャでは、単一のノード（P-GW）によって Gy セッション状態とデータトラフィックが処理されるため、メッセージングによる遅延なく SU URR が作成されます。一方、CUPS モードでは、CP は追加のノードとなります。このノードは、セッション状態に関する情報を保持し、ユーザープレーン（UP）からの URR 要求を処理します。Gy セッションを SU URR に関連付けることができるのは、CP だけです。UP と CP 間のこのメッセージングにより遅延が発生し、データパケットは [Pending-Traffic-Treatment] 設定に従って処理され、通信が完了します。

• 非 CUPS アーキテクチャでは、SU 状態タイマーは、Time-Quota タイマーとは異なる方法で処理されます。SU クォータを使い切ると、OCS への再試行が発生し、新たに [next-interim-time-quota] が開始されます。一方、CUPS モードでは、SU 時間クォータを使用する場合、クォータの枯渇が CP に報告され、セッションが再びサーバー到達不能状態になると、前回の使用状況レポートからの経過時間が使用状況に計上されます。

• CUPS で servers-unreachable after-timer-expiry timeout_period CLI コマンドを使用することは推奨されません。代わりに、servers-unreachable after-interim-time timeout_period server-retries retry_count を使用して同様の動作を実現しますが、再試行回数は 1 回です（retry_count を「1」に設定）。

制限到達後の後処理は、CUPS と非 CUPS の両方のアーキテクチャでサポートされている 3GPP 非準拠の独自の動作です。この機能により、課金バケットのクォータを使い切った場合に、実装済みのリダイレクトまたは制限操作が可能になります。ただし、OCS サーバーは [FUI-Redirect] または [FUI-Restrict] を付与できません。この機能を使用する場合、オペレータは、使用可能なすべてのルール一致基準を組み合わせて（たとえば、IMSI ベースの一致基準を有効にするなど）、サブスクライバ/トラフィックごとに異なる処理を選択的に適用できます。この機能を有効にするには、次の CLI コマンドを使用します。

configure 
   active-charging service service_name 
      rulebase rulebase_name 
         post-processing policy always 
         end 

また、rule-application post-processing CLI コマンドは、[ACS Ruledef Configuration] モードで limit-reached に設定する必要があります。

この機能により、サブスクライバは OCS からの応答を待機している間にネットワークを使用できます。Limited-Pass 設定では、サブスクライバが OCS からのクォータ応答を待機している間に消費できるボリュームを指定できます。使用量はそれぞれの課金バケットでカウントされ、次のクォータ割り当てに対して調整されます。

この機能を有効にするには、次の CLI コマンドを使用します。

configure 
   active-charging service service_name 
      credit-control 
         pending-traffic-treatment noquota limited-pass volume volume 
         end 

Limited Pass Volume は、noquota のケース（クォータを初めて要求する評価グループ（RG））にのみ使用され、quota-exhausted には使用されません。Limited Pass Volume は、後続のクレジット要求には使用されません。

Limited Pass Volume が使い果たされるまで、トラフィックの通過が許可されます。使用量はそれぞれの課金バケットでカウントされ、付与された「クォータ」に対して調整されます。「クォータ」割り当てが実際の使用量よりも少ない場合、使用状況レポートを使用した OCS への即時レポートが発生し、より多くのクォータ割り当てが要求されます。後続の着信パケットは、「quota-exhausted」PTT 設定に従って処理されます。

OCS がクォータの拒否で応答する前に Limited Pass Volume が使い果たされていない場合、トラフィックは OCS 応答後にブロックされます。ゲートウェイは、OCS が応答するまで、CCR-U（FINAL）（CUPS 以外の場合）または CCR-T（CUPS の場合）の Limited Pass Volume の使用状況を報告します。

OCS が応答する前に Limited Pass Volume が使い果たされた場合、OCS からクォータが付与されるまで、セッションの後続の着信パケットはドロップされます。

noquota のデフォルトの pending-traffic-treatment は Drop です。default pending-traffic-treatment noquota コマンドは、設定されたすべての Limited Pass Volume サイズを削除します。

CUPS アーキテクチャの Pending-Traffic-Treatment（PTT）Quota-Exhausted Limited-Pass は、バッファリングオプションの代わりに使用できます。高速ネットワークでは、バッファリングオプションには現実的な制限があります。バッファリングでは、ゲートウェイで多数のパケットをバッファリングする必要があるため、メモリが不足し、帯域幅の速度に影響を及ぼすリスクが発生します。PTT Quota-Exhausted Limited Pass では、クォータ枯渇シナリオで設定された制限に達するまで、トラフィックを通過させます。

PTT は、Limited-Pass ボリュームを使いきるまでトラフィックを許可します。PTT は、付与された「クォータ」を基準に、それぞれの課金バケットの使用状況を計算し、調整します。「クォータ」割り当てが実際の使用量よりも少ない場合は、使用状況レポートを通じてすぐに OCS に報告し、追加のクォータ割り当てを要求します。

OCS によるクォータの拒否応答までに Limited-Pass ボリュームが枯渇しなければ、OCS 応答後にトラフィックがブロックされます。ゲートウェイは、CCR-U（FINAL）で使用状況をレポートします。

OCS からの応答前に Limited-Pass ボリュームが枯渇した場合、OCS からクォータが付与されるまで、セッションの以降の着信パケットがドロップされます。

クォータが枯渇した場合の pending-traffic-treatment のデフォルト動作は [Drop] です。デフォルトの pending-traffic-treatment quota-exhausted CLI コマンドにより、設定済みの Limited-Pass ボリュームのサイズは削除されます。

この機能を有効にするには、次の CLI コマンドを使用します。

configure 
   active-charging service service_name 
      credit-control 
         pending-traffic-treatment quota-exhausted limited-pass volume volume 
         end 

（注）	上記の CLI コマンドは、CUPS アーキテクチャにのみ適用されます。

注：

• limited-pass ：OCS に到達できない場合に、サブスクライバへの制限付きアクセスを有効にします。

• volume volume ：OCS に到達できない場合に、サブスクライバへの制限付きボリュームアクセスを有効にします。volume は、デフォルトのクォータサイズ（バイト単位）を指定します。クォータサイズは 1 ～ 4294967295 までの整数で指定する必要があります。

MSCC バケットのクォータ有効時間が受信されると、同じ情報がユーザープレーンに送信されます。直接使用できる特定の IE がないため、QVT 値が Time-Quota IE に入力され、URR がユーザープレーンに送信されます。QVT またはタイムクォータの小さい方の値が、Time-Quota IE で設定されます。また、Time-Quota でユーザープレーンからの使用状況レポートがトリガーされると、解釈が行われて、Validity-Timeout の CCR-Update が生成されます。

• CCR/CCA-I、CCR/CCA-U および CCR/CCA-T、RAR/RAA メッセージのみがサポートされます。

• セッションセットアップ時およびセッション中のどちらでも、[Dynamic Rules with Online Enabled] がサポートされます。

• セッションセットアップ時およびセッション中のどちらでも、[Predefined Rules]（ダイナミックのみ）がサポートされます。「プリエンプティブな要求」の設定に制限はありません。

• オンライン課金を使用する静的ルールがサポートされます。

• Ignore-service-id がサポートされます。

• ボリュームクォータ/ボリュームしきい値メカニズムがサポートされます。

• イベントトリガー（クエリ URR が発生するもの）、および OCS への使用状況情報の送信がサポートされます。

  重要	RAT 変更機能は、このリリースでは検証されていません。

• OCS が新しいクォータを付与する Sx セッション変更手順を通じた「updateURR」手順がサポートされます。

• ベアラーレベルの Gy とサブスクライバレベルの Gy がサポートされます。

• Pending-Traffic-Treatment（PTT）の [Drop] / [Pass] は、次の制限付きでサポートされます。

  • 現在サポートされているシナリオは、クォータなしとクォータ枯渇です。

  • トリガー/再承認シナリオはサポートされていません。

  • PTT アクション（[Forward] / [Drop]）は、クォータ取得で取得できるクォータが枯渇した後に考慮されます。

• 次のような障害シナリオが認定されています。

  • 障害処理の終了、続行と再試行、および終了：CC グループ/FHT を使用

  • エラー結果コードの処理（MSCC レベルとコマンドレベルの両方）がサポートされます。

• 実測時間クォータメカニズムがサポートされます。

• その他の時間クォータメカニズム（離散期間および連続期間）はサポートされません。

• Final-Unit-Indication Terminate メカニズムがサポートされます。

• [FUI-Restrict] はサポートされません。

• セッション中のルールのインストール/削除/変更はサポートされます。

• RAR メカニズムがサポートされます。

• Server-Unreachable（SU）メカニズムがサポートされたことにより、非 CUPS P-GW と比較して動作が若干変更されました。

  • URR が UP でクォータを必要とする場合、使用状況レポートが CP に生成され、CP がリンクされた SU_URR で応答するまで、この URR に一致するパケットは [Pending-Traffic-Treatment] 設定で処理されます。

  • SU 時間クォータを使用する場合、クォータの枯渇が CP に報告され、セッションが再びサーバー到達不能状態になると、前回の使用状況レポートからの経過時間が使用状況に計上されます。

• Pending-Traffic-Treatment バッファメカニズムはサポートされません。

• [send-ccri on traffic-start] がサポートされます。

• [Quota-Hold-Time] がサポートされます。

• Quota-Consumption-Time メカニズムはサポートされません。

• [Quota-Validity-Time] がサポートされます。

• Gy でイベントが発生した場合の、Gy からの Gz レコードのトリガーがサポートされます。 Gy-Gz 同期はサポートされません。

• Gy でイベントが発生した場合の、Gy からの Rf レコードのトリガーはサポートされません。

• [rated-group] 値では、「content-id」以外の値の設定がサポートされます。

  • RG「0」はサポートされません。

• Out-of-Credit、Reallocation-of-Credit イベントの PCRF へのトリガーは認定されていません。

  重要	PCRF に対するイベントトリガーの [Out-of-Credit] は、1 回限りの付与クォータ（合計ボリュームと付与ボリュームが同じ値）という制限付きで検証されます。

• CCR-I に関する OCS からの遅延応答がサポートされます。

• [Service-Specific-Units] はサポートされません。

• [Tariff-Time] の変更は、3GPP 仕様に従ってサポートされます。

• [Quota-Retry Timer] がサポートされます。

• diameter mscc-final-unit-action terminate session CLI コマンドは、[Credit Control Configuration] モードでサポートされます。

• [FUI-Redirect] は、次の制限付きでサポートされます。

  • HTTP のリダイレクトはサポートされません。

  • フィルタ ID/フィルタルールを使用した FUI リダイレクトはサポートされません。

  • WSP プロトコルはサポートされません。

  • 3GPP 仕様に従って、リダイレクトされたトラフィックは、[FUI-Redirect] のルールにヒットした場合にもリダイレクトされます。リダイレクトされたトラフィックの通過を許可するプロビジョニングはありません。

    • 3GPP 仕様に従って、CUPS アーキテクチャは no diameter fui-redirected-flow allow CLI コマンドの動作に準拠しています。

  • redirect-require-user-agent CLI コマンドはサポートされません。ユーザーエージェントが存在しない場合でも、リダイレクトは引き続き機能します。

  • 元の URL の追加はサポートされません。

  • diameter redirect-validity-timer immediate CLI コマンドがサポートされます。ただし、diameter redirect-validity-timer traffic-start CLI コマンドはサポートされません。

  • リダイレクトを脱するトークンベースのメカニズムはサポートされません。CUPS でリダイレクトを終了するには、OCS が Redirect Validity-Time または RAR を送信します。

  • FUI リダイレクトは、非 CUPS アーキテクチャでの動作と同様に、URL に対してのみサポートされます。

• PCRF/OCS からの rulebase の変更がサポートされます。

• ユーザープレーンモジュールは、セッション確立要求の一部として受信した URR のリストの保存をサポートします。

• 各 PDR は、1 つ以上の URR に関連付けられます。

• 特定の URR が別の URR にリンクされます。

• 各 URR には、測定方法（時間またはボリューム）と、ユーザープレーンが使用状況レポートを送信する必要があるイベントを示すレポートトリガーが含まれています。

ユーザープレーンから送信されるこのメッセージは、コントロールプレーンからのセッション削除要求への応答です。このメッセージにより、ユーザープレーンで Sx セッションが終了します。使用状況レポートは、Sx セッション削除応答の一部として含まれています。