SAEGW-C は、「プラットフォームの要件」の項で特定されている最小要件を満たすハードウェア上の Cisco USP プラットフォームでホストできます。SAEGW-C は、どこに配置されているか、およびどのプラットフォームでホストされているかを問わず複数のユーザープレーンを制御できます。したがって、SAEGW-C は異なるタイプが混在していても SAEGW-U を制御できます。SAEGW-C は、制御対象となるすべての SAEGW-U に応じて、統計/バルク統計、ロギング、LI インターセプトを集約/統合し、必要なノード設定（事前定義済み/静的ルール、APN プロファイル情報、ACL 情報などを含む）をプッシュします。したがって、SAEGW-C は、オペレータの CUPS ソリューション管理の複雑さを簡素化するのに役立ちます。

SAEGW-C は、ユーザープレーンとやり取りするために、3GPP 標準ベースの Sx プロトコルをサポートします。標準形式の 3GPP Sx は、ゲートウェイが必要とするすべての機能を対象としているわけではません。そのため、CUPS でカスタム機能をサポートするために、プライベート拡張機能が追加されています。プライベート拡張については、『Ultra Packet Core CUPS Sx インターフェイス管理およびリファレンスガイド』を参照してください。

CUPS CP 機能

CUPS CP には次の機能があります。

• セッションサブシステム

• IP プールサブシステム

• AAA および冗長サブシステム

セッションサブシステム

IP プールサブシステム

AAA および冗長サブシステム

CUPS CP（SAEGW-C）とサポートされている機能の詳細については、『Ultra Packet Core CUPS コントロールプレーン管理ガイド』を参照してください。

SAEGW-U VNF は、「プラットフォーム要件」の項で特定された最小要件を満たすハードウェア上の Cisco USP プラットフォームでホストできます。SAEGW-U は、同じデータセンター内の SAEGW-C と同じ場所に配置することも、離れた別のデータセンターに配置することもできます。詳細については、『Ultra Packet Core CUPS ユーザープレーン管理ガイド』を参照してください。

CUPS UP の機能

CUPS UP には次の機能があります。

• セッションサブシステム

• IP プールサブシステム

• 冗長サブシステム

セッションサブシステム

IP サブシステム

冗長サブシステム

CUPS UP イベントデータレコード（EDR）

CUPS UP ノードは、EDR を生成するように設定できます。有効にすると、UP インスタンスはサブスクライバの IP フローごとに個別のレコードを生成します。これらは、トランザクションの終了時（HTTP GET/POST 要求など）または IP フローの終了時に生成されるように設定できます。これらのレコードに含まれる情報も設定可能です。生成されたレコードは UP のローカルストレージに一時的に保存され、後で SFTP を使用して、生成されたレコードを設定に従って外部ストレージ/サーバーにプッシュします。詳細については、『Ultra Packet Core CUPS ユーザープレーン管理ガイド』の「CUPS のイベントデータレコード」の章を参照してください。

CUPS UP 冗長性

CUPS UP では、次の 2 種類の冗長性がサポートされています。

• 1:1 の UP 冗長性

• N:M の UP 冗長性

次の図に、UP ノードをネットワークに冗長性を持たせて展開する方法を示します。

Redundancy and Configuration Manager

Redundancy and Configuration Manager（RCM）は、次の機能を提供するシスコ独自のノードです。

• UP の設定管理

• RCM がサービスを提供するすべての UP からの情報のセッション状態ストレージ

• N:M 冗長モードで展開される UP モニタリング

• スタンバイ UP の障害検知とセッション状態の復元

RCM の詳細については、『Redundancy and Configuration Manager Configuration and Administration Guide』を参照してください。

1:1 の UP 冗長性

1:1 展開モードでは、UP はホットスタンバイモードで展開されます。このモードでは、UP の設定にのみ RCM が必要です。TCP 上の独自のプロトコル（Session Redundancy Protocol（SRP）という）が 2 つの UP 間で使用され、アクティブ/スタンバイ状態をネゴシエートし、相互に監視します。

状態のネゴシエーションが完了すると、セッション状態情報を交換するために、アクティブ UP のセッションマネージャとスタンバイ UP のセッションマネージャとの間でピアツーピア TCP 接続が確立されます。セッション状態の一部として渡される情報には、次のものが含まれます。

• 通話/セッション ID

• ピア CP アドレス

• ユーザー ID 情報（IMSI、MSISDN）

• トラフィック エンドポイント アドレス（QCI、eNodeB アドレスなど）

• APN-MBR

• サブスクライバにインストールされたルール

• アカウンティング/使用状況情報

• 統計情報

1:1 の UP 冗長性の詳細については、『Ultra Packet Core CUPS ユーザープレーン管理ガイド』の「4G CUPS の 1:1 のユーザープレーン冗長性」の章を参照してください。

（注）	現在、VoLTE/IMS トラフィックをサポートする UP には 1:1 UP 冗長性を使用することをお勧めしますが、VoLTE/IMS 以外のデータトラフィックをサポートする UP は 1:1 または N:M の UP 冗長性を実装できます。

N:M の UP 冗長性

N:M 展開モードでは、UP はコールドスタンバイモードで展開されます。このモードでは、UP の設定と監視、UP インスタンスの状態管理、アクティブな UP が失敗した場合のセッション状態の保存と復元に RCM が必要です。

UP インスタンスと RCM 間のインターフェイスは TCP 上の独自のプロトコルで、1:1 の冗長性で使用されるものと同じです。Bidirectional Forwarding Detection（BFD）プロトコルは、UP インスタンスの障害を監視および検出するために使用されます。セッション状態情報を交換するために、アクティブな UP インスタンスのセッションマネージャと RCM の対応するチェックポイントマネージャの間でピアツーピア TCP 接続が確立されます。

UP と RCM の間で交換されるセッション状態情報は、1:1 冗長モードで交換される情報と同じです。チェックポイントマネージャは、受信したセッション状態情報をメモリに保存します。アクティブ UP の障害が検出されると、保存されているチェックポイント情報がスタンバイ UP のセッションマネージャにプッシュされ、セッション状態の復元に使用されます。

N:M の UP 冗長性の詳細については、『Ultra Packet Core CUPS ユーザープレーン管理ガイド』の「N:M の冗長性」 の章を参照してください。

Sx は、分割された P-GW のコントロールプレーンとユーザープレーンと、パケット転送制御プロトコル（PFCP）サービスを提供する Evolved Packet Core（EPC）の S-GW アーキテクチャとの間のインターフェイスです。Sx インターフェイスの主なタスクの 1 つは、コントロールプレーン機能を有効にし、ユーザーデータトラフィックの転送方法についてユーザープレーン機能に指示することです。

Sx の一部である機能には次のものが含まれます。

• ハートビート手順

• パケット検出情報（PDI）の最適化

• Sx over IPsec

詳細については、『Ultra Packet Core CUPS Sx インターフェイス管理およびリファレンスガイド』 を参照してください。

Vector Packet Processor for Mobility（VPPMOB）は、FD.io（高速データ：入力/出力）VPP に基づくモビリティ中心のソリューションです。Cisco Vector Packet Processing テクノロジーを利用して、仮想化された展開に高性能のパケット処理エンジン（転送プレーン）を提供します。

VPP は、ソフトウェアベースのネットワーク処理ユニット（NPU）であり、すぐに使用できる生産品質のスイッチおよびルータ機能を提供する拡張可能なフレームワークをサポートします。これは、市販の CPU で実行できる高性能のパケット処理スタックです。

アーキテクチャ

VPP は、有向グラフノードのセットです。グラフ内の各ノードは、パケット処理の特定のステップを実行します。各ノードは、1 つの関数に対して最適化されています。たとえば、IP 転送情報ベース（FIB）ルックアップ、イーサネット処理などのためのグラフノードがあります。そのため、パケット処理関数は一連のグラフノードに対して分割されます。VPP のユニークな機能は、一度に最大 256 パケットのベクトル（「フレーム」ともいう）を処理することです。これは、つまりベクトルに 256 個のパケットがある場合、これらの 256 個のパケットが IP FIB ルックアップを通じて実行され、256 個のパケットがユーザー データグラム プロトコル（UDP）処理を通じて実行されることを示します。

処理の開始時に、ドライバ（通常、データプレーン開発キット（DPDK））は回線をポーリングし、すべてのパケットをベクトルにグループ化し、それを処理の最初のステップである最初のグラフノードに渡します。たとえば、イーサネット処理は、IPv4/IPv6 などと同様に、最初のグラフノードになることがあります。処理パスに基づいて、パケットは次の処理段階に移動します。パケットは、処理状態に応じてパイプラインが分割されている場合にそのパイプライン内を移動します。これにより、パイプライン アーキテクチャに従います。

VPP をコアとし、VPPMOB を一連の VPP プラグインとして使用すると、ソリューションは利用可能なコアのサブセット上の単一の VM で実行されます。パケット処理は、サービスポートからの着信パケットで実行され、一部のサブセットはカーネルと StarOs（NPUSIM、SM_U など）との間で中継されます。

図に示すように、サービスポートは DPDK ドライバに接続され、カーネルは「AF_Packet」と呼ばれるインターフェイスを介して接続され、これら（サービスポートとカーネル）は VPP に接続されます。

他のサブシステムは、バイナリ API インターフェイスと MEMIF インターフェイスを使用して VPP と通信します。NPUMGR は VPP を制御し、NPUSIM は VPP の機能を強化するための補助処理レイヤとなり、セッションマネージャはサブスクライバを管理します。

バイナリ API は、コンポーネントと VPP 間の通信をサポートするだけでなく、通信に使用されるメッセージング形式である 16 進数データの交換も可能にします。

MEMIF は、NPUSIM と SM_U が VPP とパケットを交換するために使用する共有メモリベースのメモリ パケット インターフェイスです。各セッション マネージャ アプリケーション インスタンスには、MEMFIF インターフェイスがあります。

VPC-SI 上の CUPS

コントロールプレーン（CP）には、VPC-DI/VPC-SI インスタンスで実行されているサブスクライバポリシー、トラフィック分類ルールなどのすべての設定が含まれています。

UP は 1 つ以上の VPC-SI インスタンスで構成され、CP と同じ場所に配置することも、ネットワークのエッジにリモートで展開することもできます。各 VPC-SI インスタンスには、VPP と SM_U のソフトウェアタスクを使用してサブスクライバ データ セッションを処理する転送要素が含まれています。SM_U はトラフィックを分類し、データ処理をオフロードする前に、サブスクライバに適用する必要があるポリシーを識別し、転送要素をプログラムします。

このモデルでは、VPPMOB は、NPU スタイルのフロー処理と IP 転送機能の両方を備えたモビリティ転送ソリューションを提供する VPC-SI システム上で実行されます。また、SM_P Fastpath を実行して、SM_U をオフロードします。NPUMGR と SM_U の両方が VPPMOB の設定と管理の責任を共有し、SM_U は Fastpath 関連の設定を担います。

詳細については、『 Ultra Packet Core CUPS コントロールプレーン管理ガイド』または『Ultra Packet Core CUPS ユーザープレーン管理ガイド』の「VPP サポート」の章を参照してください。

CUPS の共存では、SAEGW-C VNF と SAEGW-U（複数）VNF の両方が同じデータセンターに配置され、同じ展開インスタンスの一部になります。

リモート CUPS では、コントロールプレーンとユーザープレーンが地理的に離れたデータセンターに展開されます。UPC CUPS アーキテクチャのユーザープレーン機能をリモートで展開することで、携帯電話事業者は、それを単一の EPC ゲートウェイとして運用し続けることができる一方で、UP の機能をトラフィック終端ポイントのすぐ近くに配置できます。EPC ゲートウェイのユーザープレーンを主要な集約ポイントまたは終端ポイントに配置することで、携帯電話事業者が中央の場所にバックホールする必要があるトラフィックの量が大幅に変わります。この利点は、企業、ビデオコンテンツ配信、および大量のトラフィックが特定の顧客ロケーションで終端できる IoT の使用例で特に重要になります。

CUPS CP は、同じ場所にある CUPS UP とリモートにある CUPS UP の両方を同時に制御できるため、同じ CUPS CP によって制御されるさまざまなタイプの CUPS UP の展開を混在させる柔軟性がもたらされます。そのため、モバイル エッジ コンピューティング（MEC）の要件は、リモート CUPS で対処されます。

次の図に、リモートで展開されたユーザープレーンの使用例におけるパケットコア機能の分布を示します。

リモート CUPS の利点と使用例

リモート CUPS の利点と使用例は次のとおりです。

• バックホールのコスト削減

• 遅延の短縮とユーザーエクスペリエンスの向上

• エンタープライズ/企業強化の使用例

• モバイル エッジ コンピューティングの使用例

• 運用の効率化