次のフローでは、特定のユーザープレーングループを選択するためのキーとして APN がどのように使用されるのかを説明します。

     APN → Associated IP Pool → Associated User Plane Profile ID → User Plane Profile 

すべての APN は、関連付けられた IPv4 プールと IPv6 プールの両方で設定されます。また、APN 設定で設定されたすべての IP プールは、同じユーザープレーングループに関連付けられます。このグループには、ユーザープレーンの IP アドレスとユーザープレーンの機能に関連する情報が含まれています。コントロールプレーンがすべての APN の同じユーザープレーンと通信する必要がある場合、APN 設定の IPv4 および IPv6 プール設定は必要ありません。

注：

• コントロールプレーンは、複数のユーザープレーンと通信するように設定できます。

• ユーザープレーンと APN 間には 1-n マッピングがあります。

• 同じユーザープレーンを介して複数の APN に到達できますが、APN ごとに関連付けられるユーザープレーンは 1 つだけです。

次のフローでは、特定のユーザープレーングループを選択するためのキーとして APN がどのように使用されるのかを説明します。APN プロファイルは、関連付けられたユーザープレーングループを使用して設定する必要があります。このグループには、ユーザープレーンの IP アドレスとユーザープレーンの機能に関連する情報が含まれています。

     APN Profile → Associated User Plane Profile ID → User Plane Group 

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

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

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

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

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

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

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

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

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

   重要	Create Uplink PDR は、「S5/S8-U S-GW F-TEID」の IP アドレス情報に基づく「Outer Header Removal」で送信されます。 Create Downlink FAR は、「Outer Header Creation」を「S5/S8-U S-GW F-TEID」にして送信されます。

   • さらに、コントロールプレーンは、P-GW 入力 PDR「S5/S8-U P-GW F-TEID」に F-TEID を割り当てるようユーザープレーンに要求します。

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

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

4. Sx セッション確立応答を受信すると、SAEGW-PGW-C は「S5/S8-U P-GW F-TEID」を含むセッション作成応答を S-GW に送信します。

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

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

   • APN プロファイルに基づいてユーザープレーンを選択します。

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

   • GTP-U インタラクションなし（非 CUPS 動作には必要であることに注意してください）。

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

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

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

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

     • S-GW 出力 PDR「S5/S8-U S-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」

4. Sx セッション確立応答を受信すると、SAEGW-SGW-C は「S5/S8-U S-GW F-TEID」を含むセッション作成要求を P-GW に送信します。

5. セッション作成応答を受信すると、SAEGW-SGW-C で次の処理が実行されます。

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

     • 「Outer Header Creation」を「S5/S8-U P-GW F-TEID」にしてアップリンク FAR を更新します。

     • 「S5/S8-U P-GW F-TEID」の IP アドレス情報に基づく「Outer Header Removal」でダウンリンク PDR を更新します。

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

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

   • MBR は S-GW ノードによって消費されます。P-GW ノードへの GTP シグナリングはありません。

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

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

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

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

次のコールフローは、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 を送信します。

次のコールフローは、UE 開始 Pure-P PDN の接続解除手順の概要を示しています。

1. セッション削除要求を受信すると、SAE-GW-C が Sxab インタラクションを実行し、アップリンクとダウンリンク両方のデータパスに対する Apply Action を「DROP」にして FAR を更新します。

2. Sx セッション変更応答を受信すると、SAE-GW-C が MME にセッション削除応答を送信します。

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

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

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

4. Sx セッション削除応答を受信すると、SAEGW-PGW-C で次の処理が実行されます。

   • Gx 通信（CCR-T および CCA-T）を実行します。

   • 受信した URR 情報に基づいて CDR（Gz）を生成します。

次のコールフローは、ネットワーク開始 Pure-P PDN の接続解除手順の概要を示しています。

1. ベアラー削除要求（RAR により開始されたもの、または clear sub all CLI によるもの）を受信すると、SAEGW-PGW-C は Sxab インタラクションを実行し、アップリンクとダウンリンク両方のデータパスに対する Apply Action を「DROP」にして FAR を更新します。

2. Sx セッション変更応答を受信すると、SAEGW-PGW-C が SGW にベアラー削除要求を送信します。

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

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

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

4. Sx セッション削除応答を受信すると、SAEGW-PGW-C で次の処理が実行されます。

   • Gx 通信（CCR-T および CCA-T）を実行します。

   • 受信した URR 情報に基づいて CDR（Gz）を生成します。

次のコールフローは、UE 開始 Pure-S PDN の接続解除手順の概要を示しています。

1. セッション削除要求を受信すると、SAEGW-SGW-C が Sxa インタラクションを実行し、アップリンクとダウンリンク両方のデータパスに対する Apply Action を「DROP」にして「FAR を更新」します。

2. Sx セッション変更応答を受信すると、SAEGW-SGW-C が P-GW にセッション削除要求を送信します。

3. セッション削除応答を受信すると、SAEGW-SGW-C が Sxa インタラクションを実行して Sx セッションを削除します。

4. Sx セッション削除応答を受信すると、SAEGW-SGW-C が MME にセッション削除応答を送信します。

次のコールフローは、ネットワーク開始 Pure-S PDN の接続解除手順の概要を示しています。

1. ベアラー削除要求を受信すると、SAEGW-SGW-C が Sxa インタラクションを実行し、アップリンクとダウンリンク両方のデータパスに対する Apply Action を「DROP」にして「FAR を更新」します。

2. Sx セッション変更応答を受信すると、SAEGW-SGW-C が MME にベアラー削除要求を送信します。

3. MME からセッション削除応答を受信すると、SAEGW-SGW-C が Sxa インタラクションを実行して Sx セッションを削除します。

4. Sx セッション削除応答を受信すると、SAEGW-SGW-C が P-GW にベアラー削除応答を送信します。

次のコールフローは、UE が開始した Collapsed PDN の切断手順の概要を示しています。

1. セッション削除要求を受信すると、SAEGW-C は Sxab インタラクションを実行し、アップリンクとダウンリンクの両方のデータパスに対する Apply Action を「DROP」として FAR を更新します。

2. Sx セッション変更応答を受信すると、SAEGW-C は MME にセッション削除応答を送信します。

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

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

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

4. Sx セッション削除応答を受信すると、SAEGW-C で次の処理が実行されます。

   • Gx 通信（CCR-T および CCA-T）を実行します。

   • 受信した URR 情報に基づいて CDR（Gz）を生成します。

次のコールフローは、ネットワークが開始した Collapsed PDN の接続解除手順の概要を示しています。

1. ベアラー削除要求（RAR により開始されたもの、または clear sub all CLI によるもの）を受信すると、SAEGW-C は Sxab インタラクションを実行し、アップリンクとダウンリンクの両方のデータパスに対する適用アクションを「DROP」にして FAR を更新します。

2. Sx セッション変更応答を受信すると、SAEGW-C は MME にベアラー削除要求を送信します。

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

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

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

4. Sx セッション削除応答を受信すると、SAEGW-C で次の処理が実行されます。

   • Gx 通信（CCR-T および CCA-T）を実行します。

   • 受信した URR 情報に基づいて CDR（Gz）を生成します。

1. UE が最初の PDN を介して接続手順を開始します。S-GW が、他の必須パラメータとともに IMSI、APN、EBI、APN AMBR UL/DL を含むセッション作成要求を PGW-C に転送して PDN 接続を確立します。

2. PGW-C が Credit-Control-Request（初期）を PCRF に送信します。

3. PCRF が、APN AMBR UL/DL を使用して PGW-C に Credit-Control-Answer（初期）で応答し、デフォルトの QoS とは異なる QCI ARP でダイナミック/事前定義済みルールをインストールします。

4. PCRF から Credit-Control-Answer（初期）を受信すると、PGW-C が PGW-U への Sx セッション確立要求を開始し、ID x を選択してデフォルトベアラーの PDR を作成するとともに、ID y を選択して専用ベアラーの PDR を作成します。

5. P-GW-U が、作成された PDR と PGW-U のローカル FTEID のリストを使用して、Sx セッション確立応答で PGW-C に応答します。

6. P-GW-C が、最初の PDN 接続セットアップのために S-GW にセッション作成応答を送信します。

7. P-GW が、ベアラーコンテキストに P-GW の Data FTEID が入力されたベアラー作成要求を S-GW に送信します。

8. S-GW が、リモートデータ FTEID を使用してベアラー作成応答を送信します。これを受信すると、UP 機能への Sx 変更要求が開始され、リモート F-TEID を使用してすべてのダウンリンク FAR に対して Update FAR が送信されます。

9. P-GW-U が P-GW-C に Sx セッション変更応答で応答します。

次のコールフローは、MBR/MCmd/CCA-U および RAR によるベアラーの作成の概要を示しています。

1. PCRF から Credit-Control-Answer（更新）または再承認要求を受信すると、P-GW-C が P-GW-U への Sx セッション変更要求を開始し、ID x を選択してデフォルトベアラーの PDR を作成するとともに、ID y を選択して専用ベアラーの PDR を作成します。

2. P-GW-U が、作成された PDR と P-GW-U のローカル FTEID のリストを使用して、Sx セッション変更応答で P-GW-C に応答します。

3. P-GW が、ベアラーコンテキストに P-GW の Data FTEID が入力されたベアラー作成要求を S-GW に送信します。

4. S-GW が、リモートデータ FTEID を使用してベアラー作成応答を送信します。これを受信すると、UP 機能への Sx 変更要求が開始され、リモート F-TEID を使用してすべてのダウンリンク FAR に対して Update FAR が送信されます。

5. P-GW-U が P-GW-C に Sx 変更応答で応答します。

次のコールフローは、Collapsed コールのベアラー作成の概要を示しています。

1. UE が最初の PDN を介して接続手順を開始します。SGW-C が、他の必須パラメータとともに IMSI、APN、EBI、APNAMBR UL/DL を含むセッション作成要求を PGW-C に転送して PDN 接続を確立します。

2. PGW-C が Credit-Control-Request（初期）を PCRF に送信します。

3. PCRF が、APN AMBR UL/DL を使用して PGW-C に Credit-Control-Answer（初期）で応答し、デフォルトの QoS とは異なる QCI ARP でダイナミック/事前定義済みルールをインストールします。

4. PCRF から Credit-Control-Answer（初期）を受信すると、PGW-C が SAEGW-U への Sx セッション確立要求を開始し、ID x を選択してデフォルトベアラーの PDR を作成するとともに、ID y を選択して専用ベアラーの PDR を作成します。

5. SAEGW-U が、作成された PDR と PGW-U のローカル FTEID のリストを使用して、Sx セッション確立応答で PGW-C に応答します。

6. SAEGW-U が、作成された PDR と PGW-U のローカル FTEID のリストを使用して、Sx セッション確立応答で PGW-C に応答します。

7. PGW-C が、最初の PDN 接続セットアップのために SGW-C にセッション作成応答を送信します。

8. PGW-C が、ベアラーコンテキストに PGW の Data FTEID が入力されたベアラー作成要求を SGW-C に送信します。

9. SGW-C が、Sx トランザクションが開始される eNodeB TEID を含むベアラー変更要求を受信します。

10. SGW-C が、リモートデータ FTEID を含むベアラー作成応答を受信します。これを受信すると、UP 機能への Sx 変更要求が開始され、リモート F-TEID を使用してすべてのダウンリンク FAR に対して Update FAR が送信されます。

11. SAEGW-U が P-GW-C に Sx セッション変更応答で応答します。

次のコールフローは、Collapsed コールに対して有効になっているピギーバックを使用したベアラー作成の概要を示しています。

1. UE が最初の PDN を介して接続手順を開始します。SGW-C が、他の必須パラメータとともに IMSI、APN、EBI、APNAMBR UL/DL を含むセッション作成要求を PGW-C に転送して PDN 接続を確立します。

2. PGW-C が Credit-Control-Request（初期）を PCRF に送信します。

3. PCRF が、APN AMBR UL/DL を使用して PGW-C に Credit-Control-Answer（初期）で応答し、デフォルトの QoS とは異なる QCI ARP でダイナミック/事前定義済みルールをインストールします。

4. PCRF から Credit-Control-Answer（初期）を受信すると、PGW-C が SAEGW-U への Sx セッション確立要求を開始し、ID x を選択してデフォルトベアラーの PDR を作成するとともに、ID y を選択して専用ベアラーの PDR を作成します。

5. SAEGW-U が、作成された PDR と PGW-U のローカル FTEID のリストを使用して、Sx セッション確立応答で PGW-C に応答します。

6. Sx 変更要求がトリガーされ、デフォルトベアラーと専用ベアラー両方の PDR と FAR が更新されます。

7. PGW-C が、最初の PDN 接続セットアップのために SGW-C にセッション作成応答を送信します。

8. PGW-C が、ベアラーコンテキストに PGW の Data FTEID が入力されたベアラー作成要求を SGW-C に送信します。これは、PDN が完全に接続されるまで SGW-C でバッファリングされます。

9. SGW-C が、Sx トランザクションが開始される eNodeB TEID を含むベアラー変更要求を受信します。

10. SGW-C が、リモートデータ FTEID を含むベアラー作成応答を受信します。これを受信すると、UP 機能への Sx 変更要求が開始され、リモート F-TEID を使用してすべてのダウンリンク FAR に対して Update FAR が送信されます。

11. SAEGW-U が P-GW-C に Sx セッション確立応答で応答します。

次のコールフローは、Pure P コールのコマンドコールフローの概要を示しています。

1. UE が最初の PDN を介して接続解除手順を開始します。SGW-C が、一連の専用ベアラーを削除するために、ベアラー削除コマンドを PGW-C に転送します。

2. PGW-C が、Apply Action を DROP にして専用ベアラーの All Update FAR で Sx 変更要求を送信します。

3. PGW-U が PGW-C に Sx セッション変更応答で応答します。

4. PGW-C がアクセス側にベアラー削除要求を送信し、ベアラー削除応答を受信すると、専用ベアラーの PDR と FAR を削除するために Sx 変更要求がトリガーされます。

次のコールフローは、Pure P コールのサブスクライバ EBI クリアの概要を示しています

1. PGW-C が最初の PDN を介して接続解除手順を開始します。

2. PGW-C が、Apply Action を DROP にして専用ベアラーの All Update FAR で Sx 変更要求を送信します。

3. PGW-U が PGW-C に Sx セッション変更応答で応答します。

4. PGW-C がアクセス側にベアラー削除要求を送信し、ベアラー削除応答を受信すると、専用ベアラーの PDR と FAR を削除するために Sx 変更要求がトリガーされます。

次のコールフローは、Pure P コールの PCRF 開始削除の概要を示しています。

1. PCRF が Rule-removal を実行し、これによって専用ベアラーが削除されます。

2. PGW-C が、Apply Action を DROP にして専用ベアラーの All Update FAR で Sx 変更要求を開始します。

3. PGW-U が PGW-C に Sx セッション変更応答で応答します。

4. PGW-C がアクセス側にベアラー削除要求を送信し、ベアラー削除応答を受信すると、専用ベアラーの PDR と FAR を削除するために Sx 変更要求がトリガーされます。

専用ベアラーの作成と削除および変更（更新）には、次の制限があります。

• Pure S コールの専用ベアラーの作成はサポートされません。

• コリジョンシナリオでは、削除がすでに進行中のベアラーに対してイベント/操作が要求されると、セッションのクリーンアップがトリガーされます。たとえば、DELETE_BEARER_COMMAND（EBI = 6）の実行中に CCA-U/RAR（EBI = 6）が受信されます。

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 は、ユーザープレーンノードを含む他のピアノードからのエラー処理と障害処理をサポートします。

このセクションでは、OI が 1 に設定されている場合における X2 ベースのハンドオーバーの S-GW 再配置コールフローについて説明します。

このセクションでは、OI が 1 に設定されている場合における S1 ベースのハンドオーバーの S-GW 再配置コールフローについて説明します。

• コントロールプレーン機能は、Sx セッション確立要求で URR のリストと、対応する PDR での参照先を送信します。

• CCR/CCA-I メッセージ交換は、Sx セッション確立要求が CP によって生成され、ダイナミックルールとプリエンプティブ MSCC のクォータが OCS から受信されるまでに行われます。

• セッション中に PCRF からルール変更/インストールが行われると、PDR と URR をプロビジョニングするために Sx セッション変更要求が使用されます。セッション中に URR を作成するときにクォータ情報が OCS に存在しない場合は、「Start-of-Packet」トリガーが測定方法（時間とボリューム）とともに設定されます。

• 最初のパケットが到着すると、パケット検出のために「Start-of-Packet」トリガーがコントロールプレーンに送信され、コントロールプレーンは OCS サーバーとのクォータネゴシエーションを開始します。

• P-GW ユーザープレーンは、Sx セッション削除応答の一部として URR 情報を送信します。

• P-GW コントロールプレーンは、これらの URR を対応する MSCC バケットにマッピングし、既存のフレームワークを使用して Gy/Ro インターフェイスで Credit-Control-Message を送信します。

• P-GW ユーザープレーンは、Sx 削除応答の一部として URR 情報を送信します。

• PGW コントロールプレーンは、これらの URR を対応する MSCC バケットにマッピングし、既存のフレームワークを使用して Gy/Ro インターフェイスで Credit-Control-Message を送信します。

P-GW ユーザープレーンは、ボリューム、時間クォータ、しきい値、有効時間、クォータホールド時間などのトリガーの使用状況レポートを送信します。P-GW コントロールプレーンは、対応する課金バケット（MSCC）に URR をマッピングし、各 MSCC の Credit-Control-Request Update を開始します。

URR レポートでは、P-GW ユーザープレーンによって送信されるトリガーに応じて、Credit-Control-Request-Update が生成されます。

• ユーザープレーンがトリガーの URR を報告すると、最初にコントロールプレーンの MSCC バケットにマッピングされます。値は MSCC データ構造で更新されます。

• 現在のレポートで URR バケットが処理されると、コントロールプレーンは更新中の MSCC バケットを分析し、すべての MSCC バケットを含む Credit-Control-Request-Update 要求を開始します。

  重要	このリリースでは、単一の MSCC-per-update 機能はサポートされていません。

障害処理設定は、OCS サーバーとの通信中に障害が発生した場合に実行するアクションを指定するためのものです。指定可能な障害処理設定は、Continue、Terminate、Retry、Terminate です。Terminate と Retry-Terminate は、コントロールプレーンでのみ行われます。Continue の場合、次のアクションが実行されます。

• CCFH Continue アクションが適用されると、すべての Gy URR の関連付けが解除されて PDR から削除されるため、オンライン課金のレポート/課金は行われません。

• 「removeURR」IE は、ユーザープレーンへのすべての Gy URR に対してプロビジョニングされ、ユーザープレーンは URR へのすべての参照をクリアして内部で削除を行います。

• mscc 結果コード 4010、4012、5003、5012、5031 を除く、MSCC レベルのエラー結果コードの処理がサポートされています。

RAR 要求が OCS サーバーから送信されると、コントロールプレーンは必要な課金バケットの「QueryURR」をユーザープレーンに送信します。ユーザープレーンが URR レポートをコントロールプレーンに送り返すと、コントロールプレーンは FORCED_REAUTHORIZATION トリガーの CCR-Update を送信します。

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

オンライン課金システム（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 までの整数で指定する必要があります。

• 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 情報は、Sx セッション削除応答の一部として PGW ユーザープレーンによって送信されます。

• P-GW コントロールプレーンは、これらの URR を対応する課金バケットにマッピングし、既存のフレームワークを使用して、Gz、Gy などの各インターフェイスで課金レコードを送信します。

P-GW ユーザープレーンは、ボリュームまたは時間しきい値のようなトリガーに関する使用状況レポートを送信します。P-GW コントロールプレーンは、対応する課金バケットに URR をマッピングします。

URR レポートにより、P-GW ユーザープレーンによって送信されたトリガーに応じて LOSDV バケットが作成され、P-GW CDR が生成されます。

• ベアラーレベルの URR を受信すると、対応するサブセッション/ベアラーの P-GW CDR が生成され、既存の LOSDV コンテナと現在のレポート要求の一部として作成される LOSDV コンテナが報告されます。ベアラーレベルの URR を受信すると、ユーザープレーンがすべての SDF レベルの URR も送信したと想定されます。

• SDF レベルの URR を受信すると、それらの URR は LOSDV コンテナとして保存されます。この場合、 fbc_bucket は URR から必要なカウントまたはタイムスタンプを使用して作成されます。