JP2014531792A - ＯｐｅｎＦｌｏｗデータ及び制御プレーンでのクラウドコンピュータにおける３Ｇパケットコアの実装 - Google Patents

Abstract

スプリットアーキテクチャを有する第３世代（３Ｇ）ネットワークのパケットコア（ＰＣ）内にＧＰＲＳ（general packet radio service）トンネルプロトコル（ＧＴＰ）を実装するための方法であって、前記３Ｇネットワークの前記ＰＣの制御プレーンは、クラウドコンピューティングシステム内にあり、前記クラウドコンピューティングシステムは、コントローラを含み、前記コントローラは、複数の制御プレーンモジュールを実行し、前記制御プレーンは、制御プレーンプロトコルを通じて前記ＰＣのデータプレーンと通信し、前記データプレーンは、前記３Ｇネットワークの複数のネットワークエレメント内に、ＳＧＳＮ及びＧＧＳＮのデータプレーンを実装するスイッチを構成し、及び第１及び第２のＧＴＰトンネルエンドポイントを確立するように中間スイッチを構成することにより、実装される、方法。【選択図】図１９

Description

本発明の実施形態は、クラウドコンピュータシステムにおいて第３世代パケットコアの制御プレーンを実装するための方法及びシステムに関する。具体的には、本発明の実施形態は、クラウドコンピュータシステムにおいて実行される制御プレーンによるデータプレーンの制御を実装するためのＯｐｅｎＦｌｏｗプロトコルの使用に関する。

ＧＰＲＳ（general packet radios system）は、セルラーフォンといったユーザデバイスとインターネットとの間でインターネットプロトコルパケットを送信するために使用されるシステムである。ＧＰＲＳシステムはＧＰＲＳコアネットワークを含み、ＧＰＲＳコアネットワークはＧＳＭ（global system for mobile communication）の統合された部分である。これらシステムは、大規模なエリアにわたってセルラーフォンサービスを可能とするために、セルラーフォンネットワークプロバイダにより広く利用されている。

ＧＰＲＳトンネリングプロトコル（ＧＴＰ）は、ＧＰＲＳコアネットワーク内で利用される、重要な通信プロトコルである。ＧＴＰは、ＧＳＭネットワーク内のエンドユーザデバイス（例えば、セルラーフォン）がインターネットへの接続を継続しながらあちらこちらへと移動することを可能とする。エンドユーザデバイスは、ＧＧＳＮ（gateway GPRS support node）を通じてインターネットへ接続される。ＧＧＳＮは、エンドユーザデバイスから発せられるセッションをハンドリングしている、エンドユーザデバイスのＳＧＳＮ（serving GPRS support node）からのエンドユーザデバイスのデータを追跡する。

ＧＰＲＳコアネットワークによって、３つの形式のＧＴＰが使用される。ＧＴＰ−Ｕは、各パケットデータプロトコル（ＰＤＰ）コンテキストについて別個のトンネル内でのユーザデータの移送のために使用される。ＧＴＰ−Ｃは、ＧＰＲＳコアネットワーク内でＧＧＳＮとＳＧＳＮとの間のシグナリングのために使用される、ＧＴＰ´は、ＧＳＭ又はＵＭＴＳネットワークの課金データ機能（ＣＤＦ）から課金ゲートウェイ機能（ＣＧＦ）へ課金データを搬送するために使用される。ＣＧＦは、請求システム（billing system）へ必須のエンドユーザデバイス使用情報を提供する。ＧＴＰ´は、ＧＴＰ−Ｃ及びＧＴＰ−Ｕと同じメッセージ構造を使用する。

スプリットアーキテクチャを有する第３世代（３Ｇ）ネットワークのパケットコア（ＰＣ）内にＧＰＲＳ（general packet radio service）トンネルプロトコル（ＧＴＰ）を実装するための方法であって、上記３Ｇネットワークの上記ＰＣの制御プレーンは、クラウドコンピューティングシステム内にあり、上記クラウドコンピューティングシステムは、コントローラを含み、上記コントローラは、複数の制御プレーンモジュールを実行し、上記制御プレーンは、制御プレーンプロトコルを通じて上記ＰＣの上記データプレーンと通信し、上記データプレーンは、上記３Ｇネットワークの複数のネットワークエレメント内に実装され、上記方法は：上記コントローラにより、加入者セッションのための上記３Ｇネットワークの上記ＰＣ内のＳＧＳＮ（serving GPRS support node）とＧＧＳＮ（gateway GPRS support node）との間のＧＴＰトンネルを生成するためのリクエストを受信するステップと；上記制御プロトコルを介して、上記ＳＧＳＮのデータプレーンを実装するスイッチを、上記加入者セッションのパケットをカプセル化し及び非カプセル化し、並びに第１のＧＴＰトンネルエンドポイントを確立するように構成するステップと；上記制御プレーンプロトコルを介して、上記ＧＴＰトンネルのルート内の少なくとも１つのスイッチを、上記ＧＴＰトンネルに従って上記加入者セッションのパケットを転送するように構成するステップと；上記制御プレーンプロトコルを介して、上記ＧＧＳＮのデータプレーンを実装するスイッチを、上記加入者セッションの上記パケットをカプセル化し及び非カプセル化し、並びに第２のＧＴＰトンネルエンドポイントを確立するように構成するステップと、を含む。

スプリットアーキテクチャを有する第３世代（３Ｇ）ネットワークのパケットコア（ＰＣ）内のＧＰＲＳ（general packet radio service）トンネルプロトコル（ＧＴＰ）の実装を管理するためのクラウドコンピューティングシステムであって、上記３Ｇネットワークの上記ＰＣの制御プレーンは、上記クラウドコンピューティングシステム内にあり、上記制御プレーンは、制御プレーンプロトコルを通じて上記ＰＣのデータプレーンと通信し、上記データプレーンは、上記３Ｇネットワークの複数のネットワークエレメント内に実装され、上記クラウドコンピューティングシステムは、上記ＰＣの上記データプレーンを実装する上記複数のネットワークエレメントと通信し、及び互いに通信する複数のサーバ、を備え、上記複数のサーバは、上記ＰＣの上記制御プレーンを実装する複数の制御プレーンモジュールを実行するように構成されるコントローラと、上記コントローラへ通信可能に結合され、上記ＰＣの上記複数の制御プレーンモジュールの実行を管理するように構成されるクラウドマネージャと、を実行し、各制御プレーンモジュールは、上記データプレーンを管理するための制御プレーン機能のセットを提供し、上記コントローラは、加入者セッションのための上記３Ｇネットワークの上記ＰＣ内のＳＧＳＮ（serving GPRS support node）とＧＧＳＮ（gateway GPRS support node）との間のＧＴＰトンネルを生成するためのリクエストを受信するように構成され、上記コントローラは、上記制御プレーンプロトコルを介して、上記ＳＧＳＮのデータプレーンを実装するスイッチを、上記加入者セッションのパケットをカプセル化し及び非カプセル化し、並びに第１のＧＴＰトンネルエンドポイントを確立するように構成する、ように構成され、上記コントローラは、上記制御プレーンプロトコルを介して、上記ＧＴＰトンネルのルート内の少なくとも１つのスイッチを、上記ＧＴＰトンネルに従って上記加入者セッションのパケットを転送するように構成する、ように構成され、上記コントローラは、上記制御プレーンプロトコルを介して、上記ＧＧＳＮのデータプレーンを実装するスイッチを、上記加入者セッションの上記パケットをカプセル化し及び非カプセル化し、並びに第２のＧＴＰトンネルエンドポイントを確立するように構成する、ように構成される。

本発明は、添付図面の図において限定ではなく例示の手段で図示され、その中で類似する参照は同様のエレメントを示す。本開示における“一”又は“１つの”実施形態への様々な言及は必ずしも同じ実施形態についてのものではなく、そうした参照は少なくとも１つを意味することに留意すべきである。さらに、特定の特徴、構造又は特性が一実施形態との関連で説明される際、明示的に説明されているか否かに関わらず、そうした特徴、構造又は特性を他の実施形態との関連で作用させることは、当業者の知識の範囲内であると考える。

ＯｐｅｎＦｌｏｗスイッチを伴う例としてのネットワークの１つの実施形態の図である。 フローテーブルエントリの内容の１つの実施形態を例示する図である。 ＯｐｅｎＦｌｏｗを実装する他の例としてのアーキテクチャを示している。 ＯｐｅｎＦｌｏｗスイッチのパケット処理パイプラインを通じたパケットの処理の１つの実施形態を示している。 ＯｐｅｎＦｌｏｗルールマッチング処理の１つの実施形態のフローチャートである。 パケットに適用すべきルールを識別するためにマッチング処理が利用することのできるフィールド群の図である。 ＯｐｅｎＦｌｏｗヘッダ処理（processing）のための処理（process）の１つの実施形態のフローチャートである。 ＯｐｅｎＦｌｏｗヘッダ処理のための処理の１つの実施形態のフローチャートである。 第３世代（３Ｇ）パケットコア（ＰＣ）の１つの実施形態の図である。 プライマリＧＴＰ−Ｕカプセル化ヘッダ内のヘッダフィールド群の１つの実施形態の図である。 クライアントのセットにサービスするクラウドコンピューティングシステムの１つの実施形態の図である。 クライアントのＶＰＣに新たなサービスインスタンスを追加する処理を示す、クラウドコンピューティングシステムの他の実施形態の図である。 クラウドコンピューティングシステム内に実装される３Ｇ ＰＣの１つの実施形態の図である。 ３Ｇ ＰＣネットワークの基本的な動作のための処理の１つの実施形態のフローチャートである。 単一のデータセンタの外部の複数の事業者ネットワークを管理サービス会社が管理することをクラウドコンピューティングシステム内の３Ｇ ＰＣがどのように可能にするかの１つの実施形態の図である。 特殊なサービスの取り扱いのためのピアリング及び差別化ルーティングのための処理の１つの実施形態の図である。 ＧＴＰ ＴＥＩＤルーティングのためのＯｐｅｎＦｌｏｗテーブルの修正の１つの実施形態の図である。 フローテーブルの行の構造の図である。 ３Ｇ ＰＣにおけるセッションの生成のフローチャートである。 ３Ｇ ＰＣにおけるセッションの修正のフローチャートである。 ３Ｇ ＰＣにおけるセッションの削除のフローチャートである。 セッション生成リクエスト手続のためのＯｐｅｎＦｌｏｗメッセージフローの１つの実施形態の図である。 セッション修正リクエスト手続のためのＯｐｅｎＦｌｏｗメッセージシーケンスの１つの実施形態の図である。 セッション削除リクエスト手続のためのＯｐｅｎＦｌｏｗメッセージフローの１つの実施形態の図である。

以下の説明において、多くの特定の詳細が呈示される。しかしながら、それら特定の詳細が無くとも本発明の実施形態は実践され得ることが理解される。他の例において、よく知られた回路、構造及び技法は、本説明の理解を曖昧にしないために、詳細には示されていない。しかしながら、そうした特定の詳細が無くとも本発明は実践され得ることが、当業者には理解されるであろう。過剰な実験をせずとも、包含した説明があれば、当業者は適切な機能性を実装することができるであろう。

図８、１０〜１２、１４及び１５の例示的な実施形態を参照しながら、フロー図の動作が説明されるであろう。しかしながら、フロー図の動作は図８、１０〜１２、１４及び１５を参照しながら議論されるものとは別の本発明の実施形態によって実行されることができること、並びに、図８、１０〜１２、１４及び１５を参照しながら議論される実施形態は図５、７、１３、１８、１９、２０及び２１のフロー図を参照しながら議論されるものとは異なる動作を実行することができること、が理解されるべきである。

図中に示す技法は、１つ以上の電子デバイス（例えば、端局、ネットワークエレメントなど）上で記憶され及び実行されるコード及びデータを用いて実装されることができる。そうした電子デバイスは、非一時的なマシン読取可能な又はコンピュータ読取可能な記憶媒体（例えば、磁気ディスク、光学ディスク、ランダムアクセスメモリ、リードオンリメモリ、フラッシュメモリデバイス及び相変化メモリ）などの、非一時的なマシン読取可能な又はコンピュータ読取可能な媒体を用いて、コード及びデータを記憶し及び（内部的に、及び／又はネットワーク上で他の電子デバイスとの間で）通信する。加えて、そうした電子デバイスは、典型的には、１つ以上の記憶デバイス、ユーザ入出力デバイス（例えば、キーボード、タッチスクリーン及び／又はディスプレイ）並びにネットワーク接続などの、１つ以上の他のコンポーネントと結合される、１つ以上のマイクロプロセッサのセットを含む。マイクロプロセッサのセットと他のコンポーネントとの間の結合は、典型的には、１つ以上のバス及びブリッジ（バスコントローラともいう）を通じてなされる。記憶デバイスは、１つ以上の非一時的なマシン読取可能な又はコンピュータ読取可能な記憶媒体及び非一時的なマシン読取可能な又はコンピュータ読取可能な通信媒体を表現する。よって、所与の電子デバイスの記憶媒体は、典型的には、電子デバイスの１つ以上のプロセッサのセット上での実行のための、コード及び／又はデータを記憶する。当然ながら、本発明の一実施形態の１つ以上の部分が、ソフトウェア、ファームウェア及び／又はハードウェアの異なる組合せを用いて実装されてもよい。

ここで使用されるように、ネットワークエレメント（例えば、ルータ、スイッチ、ブリッジなど）は、ネットワーク上の他の機器（例えば、他のネットワークエレメント、端局など）と通信可能に相互接続するハードウェア及びソフトウェアを含む１つのネットワーキング機器である。いくつかのネットワークエレメントは、マルチネットワーキング機能（例えば、ルーティング、ブリッジング、スイッチング、レイヤ２統合、セッションボーダ制御、マルチキャスティング、及び／若しくは加入者管理）についてのサポートを提供し、並びに／又は、マルチアプリケーションサービス（例えば、データ、ボイス及びビデオ）についてのサポートを提供する、“マルチサービスネットワークエレメント”である。加入者端局（例えば、サーバ、ワークステーション、ラップトップ、パームトップ、モバイルフォン、スマートフォン、マルチメディアフォン、ＶＯＩＰ（Voice Over Internet Protocol）フォン、ポータブルメディアプレーヤ、ＧＰＳユニット、ゲーミングシステム、セットトップボックス（ＳＴＢ）など）は、インターネット上で提供されるコンテンツ／サービス、及び／又は、インターネット上に重畳される仮想プライベートネットワーク（ＶＰＮ）上で提供されるコンテンツ／サービスにアクセスする。コンテンツ及び／又はサービスは、典型的には、サービスプロバイダ若しくはコンテンツプロバイダに属する１つ以上の端局（例えば、サーバ端局（server end stations））又はピアツーピアサービスに参加する端局によって提供され、パブリックウェブページ（無料コンテンツ、ストアフロント、検索サービスなど）、プライベートウェブページ（例えば、電子メールサービスを提供する、ユーザ名／パスワードによりアクセスされるウェブページ）、ＶＰＮ上の企業ネットワーク、ＩＰＴＶなどを含み得る。典型的に、加入者端局は、（例えば、（無線又は有線で）アクセスネットワークに結合される顧客構内の機器を通じて）エッジネットワークエレメントに結合され、当該エッジネットワークエレメントは、（例えば、他のエッジネットワークエレメントへの１つ以上のコアネットワークエレメントを通じて）他の端局（例えば、サーバ端局）に結合される。

本発明の実施形態は、従来技術の欠点を回避するための方法及びシステムを提供する。従来技術の欠点は、３Ｇパケットコアの従来の実装が特定のネットワークエンティティ専用のサーバのプールを使用することであり、例えばＳＧＳＮのホスティング専用のサーバのプールなどである。追加的なシグナリングの需要が余分なキャパシティを要する場合、新たなＳＧＳＮのインスタンスがサーバプール内でインスタンス化される。しかしながら、ホーム加入者サーバ（ＨＳＳ）のサービスについて需要が大きい場合、ＨＳＳサーバ専用のサーバプールは高負荷で利用されることになり、しかしＳＧＳＮのためのサーバプールはそれほど利用されない。それほど利用されない当該サーバプールは、依然としてメンテナンスを要し、運用費用を発生させ、しかしネットワーク事業者のために最適なパフォーマンスを提供しない。

いくつかの状況において、管理サービス会社がモバイル事業者のネットワークを構築し及び稼働させ、一方でモバイル事業者自身はマーケティング、請求及びカスタマリレーションを扱う。各モバイル事業者のネットワークについてのシグナリング及びデータトラフィックは、それらネットワークと競業者のネットワークとが同じ管理サービス会社により管理され得るとしても、プライベートに保たれ、その競業者のトラフィックからは隔離される。管理サービス会社は、完全に別個のサーバプールと、自身がサポートするモバイル事業者ごとの物理的なシグナリングネットワークとを維持しなければならない。結果として、リソースの大幅な冗長性と、サーバキャパシティの利用率低下（underutilization）とが存在する。これは、追加的な機器、電力及び冷却要件に起因して、管理サービス会社及びモバイル事業者ネットワークのための運用費用を増加させる。

現在定義されている通りの３Ｇパケットコアアーキテクチャは、モバイル事業者の固定的なコア／インターネットとモバイル統合ネットワークとの間にプレゼンス点（ＰｏＰ：point of presence）を１つのみ許容しており、即ち、単一のＧＧＳＮ（gateway GPRS support node）が存在する。モバイルネットワーク事業者は、統合ネットワーク内の隣接する事業者の間に、複数のピアリング点及びＰｏＰをセットアップすることができない。これは、モバイル事業者のコアネットワークへ流入するトラフィックの量を低減し、それによりコアネットワークの高価で時間の掛かるアップグレードについての必要性が低減される。加えて、ピアリング点は、サービスレベル協定（ＳＬＡ：service level agreements）が遵守されている限りは、通常は事業者にコストを掛けない。しかしながら、この配備の柔軟性は、単一のモバイルゲートウェイにおいてコア／インターネットとのＰｏＰをアンカリング（anchor）しなければならないことに起因して、モバイル事業者にとって利用可能でない。

３Ｇ ＰＣアーキテクチャは、ユーザフローの特殊な取り扱い（treatment）のための柔軟性もあまり含まない。当該アーキテクチャはサービス品質（ＱｏＳ）を確立するためのサポートを提供するものの、他の種類のデータ管理は利用可能でない。例えば、特殊なディープパケットインスペクション、又は、トランスコード若しくは拡張現実アプリケーションのために利用され得るローカルデータキャッシュ及び処理リソースとのとのやり取りといった、ミドルボックスが関与するサービスは、現行の３Ｇ ＰＣアーキテクチャではサポートすることが難しい。そうしたアプリケーションのほとんど全ては、パケットフローがＧＧＳＮを通って退出することを要し、そこでＧＴＰからトンネル解除（de-tunnneled）され、有線ネットワーク内で処理されることになる。

３Ｇ ＰＣの制御プレーンのクラウドコンピューティング設備における実装と、ＯｐｅｎＦｌｏｗプロトコル（例えば、ＯｐｅｎＦｌｏｗ１．１）を用いた制御プレーンとデータプレーンとの間の通信の管理に加えて、ＯｐｅｎＦｌｏｗスイッチのセットを用いた３Ｇ ＰＣのデータプレーンの実装は、ＯｐｅｎＦｌｏｗプロトコルが、３Ｇ ＰＣのデータプレーンの実装のために必要とされる、ＧＴＰ又はＧＴＰトンネルエンドポイント識別子（ＴＥＩＤ）ルーティングをサポートしないという問題を生じさせる。

本発明の実施形態は、従来技術のこれら欠点を克服する。３Ｇ ＰＣアーキテクチャのために制御プレーンとデータプレーンとを分離（split）し、クラウドコンピューティング設備内に３Ｇ ＰＣ制御プレーンエンティティを配備することにより制御プレーンを実装することで、従来技術の欠点が回避され、一方で、データプレーンはＯｐｅｎＦｌｏｗスイッチの集合を分散させることにより実装される。ＯｐｅｎＦｌｏｗプロトコルは、その２つをＧＴＰルーティングをサポートする拡張と共に接続するために使用される。３Ｇ ＰＣアーキテクチャは既に制御プレーンとデータプレーンとの間の分離を有するものの、ＳＳＧＮ及びＧＧＳＮがそもそもデータプレーンエンティティであってＨＬＲ（home location register）、ＨＳＳ（home subscriber server）及びＡＵＣ（authentication center）がそもそも制御プレーンエンティティであるという意味において、その分離はモビリティ管理プロトコル、ＧＴＰ、のレベルでなされたものである。

標準の３Ｇ ＰＣアーキテクチャは、標準によってルーティングが行われるトランスポート用ＩＰネットワークを前提とし、その上位（top）でモバイルネットワークエンティティ及びプロトコルが実装される。ここで説明される拡張される３Ｇ ＰＣアーキテクチャは、代わりに、ＩＰルーティング及びメディアアクセス制御（ＭＡＣ）スイッチングのレベルにあたる。ＩＰルーティングとイーサネット及びＩＰルーティングの管理を分散させるために、Ｌ２ルーティングプロトコル及びＬ３内部ゲートウェイプロトコルを、分散された制御エンティティの集合として使用する代わりに、Ｌ２及びＬ３ルーティングの管理がクラウド設備内に一元化され、ルーティングがＯｐｅｎＦｌｏｗプロトコルを用いてクラウド設備から制御される。ここで使用されるように、“ＯｐｅｎＦｌｏｗプロトコル”は、スタンフォード大学によってホスティングされているウェブサイトであるwww.openflowswitch.orgにてＯｐｅｎＦｌｏｗスイッチ仕様内で定義されている、ＯｐｅｎＦｌｏｗネットワークプロトコル及びスイッチング仕様をいう。ここで使用されるように、“ＯｐｅｎＦｌｏｗスイッチ”は、ＯｐｅｎＦｌｏｗプロトコルを実装するネットワークエレメントをいう。

クラウド内で、標準の３Ｇ ＰＣ制御プレーンエンティティであるＨＳＳ、ＨＬＲ、ＡＵＣ、ＶＬＲ（visitor location register）、ＥＩＲ（equipment identity register）、ＳＭＳ−ＩＷＭＳＣ（sort message service interworking message center）、ＳＭＳ−ＧＭＳＣ（SMS gateway message center）及びＳＬＦ（subscriber location function）並びにＳＧＳＮ及びＧＧＳＮの制御プレーンの側面が配備される。データプレーンは、ＩＰルータ及びイーサネットスイッチよりもむしろ、ＧＴＰパケットをルーティングするための必要に応じた拡張を伴って、標準のＯｐｅｎＦｌｏｗスイッチから構成される。最小限で、ＳＧＳＮ及びＧＧＳＮのデータプレーン部分、並びにＥ−ＵＴＲＡＮ内のＮｏｄｅＢのパケットルーティング部分は、ＧＴＰルーティングのためのＯｐｅｎＦｌｏｗ拡張を要する。ルーティングについてどれほど精細な制御を事業者が要するかに依存して、３Ｇ ＰＣアーキテクチャ内の他のスイッチにＧＴＰルーティングのための追加的な拡張が必要とされ得る。ＧＴＰルーティングのための拡張は、３Ｇ ＰＣアーキテクチャ内で、ＧＴＰトンネルを確立するための処理、ＧＴＰトンネルを修正するための処理、及びＧＴＰトンネルをティアダウンさせるための処理を含む。

３Ｇ ＰＣの制御プレーン部分及びデータプレーン部分の間の分離を仮想プライベートクラウド（ＶＰＣ）技術と共に用いて、単一の３Ｇ ＰＣ内の複数のＰｏＰを実装し、特殊なアプリケーションのためのＧＴＰフロー固有のルーティングを提供し、単一のクラウドコンピューティング設備から複数の事業者ネットワークを稼働させることができる。

１つの実施形態において、クラウドベースの３Ｇ ＰＣシステムを、ハードウェアデバイスのセットとして実装することができる。他の実施形態において、システムコンポーネントはソフトウェア（例えば、マイクロコード、アセンブリ言語又は上位レベルの言語）で実装される。それらソフトウェアの実装は、非一時的なコンピュータ読取可能な媒体上に記憶され得る。非一時的な“コンピュータ読取可能な”媒体は、情報を記憶可能ないかなる媒体をも含み得る。非一時的なコンピュータ読取可能な媒体の例は、リードオンリ―メモリ（ＲＯＭ）、フロッピーディスク、ＣＤ Ｒｏｍ、ＤＶＤ、フラッシュメモリ、ハードドライブ、光学ディスク又は類似の媒体を含む。

［ＯｐｅｎＦｌｏｗ１．０ネットワーク］
図１は、ＯｐｅｎＦｌｏｗ１．０仕様に準拠するＯｐｅｎＦｌｏｗスイッチを伴う例としてのネットワークの１つの実施形態の図である。ＯｐｅｎＦｌｏｗ１．０プロトコルは、コントローラ１０１が、ＯｐｅｎＦｌｏｗ１．０対応のスイッチ１０９へセキュアチャネル１０３を用いて接続し、スイッチ１０９内の単一の転送テーブル１０７を制御することを可能とする。コントローラ１０１は、ユーザがＯｐｅｎＦｌｏｗ１．０スイッチ１０９を設定することを可能とする遠隔コンピューティングデバイスによって実行される外部ソフトウェアコンポーネントである。セキュアチャネル１０３は、ローカルエリアネットワーク（ＬＡＮ）又はインターネットなどのワイドエリアネットワーク（ＷＡＮ）を含む任意のタイプのネットワークによって提供可能である。

図２は、フローテーブルエントリの内容の１つの実施形態を例示する図である。転送テーブル１０７は、パケットヘッダ内のフィールド群についてのマッチングを定義するルール２０１、フローマッチに関連付けられるアクション２０３、及びフローについての統計の集合２０５からなるエントリで形成される。インカミングパケットが受信されると、フローテーブル１０７内でマッチングするルールのルックアップが行われる。インカミングパケットが特定のルールに適合する場合、フローテーブルエントリ内で定義されている関連付けられるアクションが当該パケットについて実行される。

ルール２０１は、プロトコルスタック内のいくつかのヘッダからのキーフィールド群、例えば、ソース及び宛て先イーサネットＭＡＣアドレス、ソース及び宛て先ＩＰアドレス、ＩＰプロトコルタイプ番号、インカミング及びアウトゴーイングＴＣＰ／ＵＤＰポート番号、を含む。フローを定義するために、利用可能な全てのマッチングフィールドが使用されてよい。但し、望まれないフィールドについてはワイルドカードを使用することで、利用可能なフィールドのサブセットにマッチングルールを制限することも可能である。

ＯｐｅｎＦｌｏｗ１．０の仕様により定義されているアクションは、適合したパケットを破棄するＤｒｏｐ、１つ又は全てのアウトゴーイングポートへ、インカミング物理ポートそれ自身へ、セキュアチャネルを介してコントローラへ、又は（もし存在すれば）ローカルネットワークスタックへパケットを転送するＦｏｒｗａｒｄ、である。ＯｐｅｎＦｌｏｗ１．０プロトコルデータユニット（ＰＤＵ）は、Ｃプログラミング言語を用いて特定される構造のセットで定義されている。より一般的に使用されるメッセージのいくつかは、スイッチ構成レポートメッセージ、（フローエントリ修正メッセージ及びポート修正メッセージを含む）ステート修正メッセージ、ステート読取りメッセージ、パケット送信メッセージであり、システムの稼動中にステート読取りメッセージを用いて現行の自身のステートに関してデータパスが問合せされ、パケット送信メッセージはコントローラがデータパスを通じて外部へパケットを送信することを希望する場合に使用される。

ＯｐｅｎＦｌｏｗ１．０は、何らかのプロトコルエレメントを拡張することを可能とする“ベンダ拡張（vendor extensions）”をサポートする。プロトコルメッセージ及びテーブルアクションは拡張可能だが、フローマッチングルールは可能ではない。クラウドベースのＥＰＣアーキテクチャとの関連におけるこれら拡張の使用が以下にさらに議論される。

［ＯｐｅｎＦｌｏｗ１．１ネットワーク］
図３は、ＯｐｅｎＦｌｏｗ１．１仕様に準拠する、ＯｐｅｎＦｌｏｗを実装する他の例としてのアーキテクチャを示している。本実施形態において、複数のフローテーブル３０１についての明示的な提供がある。これは、テーブルサイズの組合せによる激増を引き起こすことなく、特定のルール及びアクションをミックスしマッチングするためのパケット処理パイプラインを可能とする。例えば、１つのフローテーブルはＱｏＳ処理を実行可能であり、一方で別のフローテーブルはルーティングを行う。

図４は、ＯｐｅｎＦｌｏｗ１．１スイッチによるパケット処理パイプラインを通じたパケットの処理の１つの実施形態を示している。受信されたパケットは、フローテーブル４０１の各々に対して比較される。各フローテーブルのマッチング後に、アクションがアクションセットに蓄積される。他のフローテーブルに対するマッチングを処理が必要とする場合、適合したルール内のアクション群は、処理をパイプライン内の次のテーブルへと向かわせるアクションを含む。全ての蓄積されたアクション群を即座に実行するというアクションをセット内に含まない場合、アクション群はパケット処理パイプラインの最終段４０３において実行される。あるアクションはメタデータレジスタへのデータの書き込みを可能とし、メタデータレジスタはパケット処理パイプラインに沿ってパケットヘッダと同様に搬送される。

図５は、ＯｐｅｎＦｌｏｗ１．１のルールマッチング処理の１つの実施形態のフローチャートである。ＯｐｅｎＦｌｏｗ１．１は、パケットのタグ付けについてのサポートを含む。ＯｐｅｎＦｌｏｗ１．１は、ヘッダフィールド及びＭＰＬＳ（multi-protocol label switching）ラベルに基づくマッチングを可能とする。１つの仮想ＬＡＮ（ＶＬＡＮ）ラベル及び１つのＭＰＬＳラベルがテーブルごとにマッチング可能である。処理すべきパケットの到達と共に、ルールマッチング処理が開始される（ブロック５０１）。第１のテーブル０から、受信されたパケットとの適合を判定するためにルックアップが実行される（ブロック５０３）。当該テーブル内で適合がなければ、デフォルトアクションのセットのうちの１つが行われる（即ち、コントローラへのパケットの送信、パケットの破棄又は次のテーブルへ続行）（ブロック５０９）。適合があれば、カウンタ、パケット又は適合セットフィールド及びメタデータと共に、アクションセットの更新が行われる（ブロック５０５）。処理すべき次のテーブルを判定するためのチェックが行われ、それはシーケンシャルな次のテーブルか、又は適合したルールのアクションにより特定されるテーブルであり得る（ブロック５０７）。テーブルの全てが一度処理されると、導かれたアクションセットが実行される（ブロック５１１）。

図６は、パケットに適用すべきルールを識別するためにマッチング処理が利用することのできるフィールド群の図である。アクションは、ラベルをプッシュし及びポップすることによるタグスタックの操作を可能とする。複数のテーブルと組み合わされて、ＶＬＡＮ又はＭＰＬＳラベルスタックを、テーブルごとに１つのラベルをマッチングすることにより処理することができる。

図７は、ヘッダパース（header parsing）処理の１つの実施形態のフローチャートである。パース処理は、マッチングフィールドのセットを初期化し、様々なヘッダタイプのセットの出現をチェックすることにより、パケットヘッダをマッチングする（ブロック７０１）。本プロセスは、ＶＬＡＮタグについてチェックを行う（ブロック７０３）。ＶＬＡＮタグが出現している場合、当該ＶＬＡＮタグのための一連の処理ステップが存在する（ブロック７０５〜７０７）。スイッチがＭＰＬＳをサポートする場合（ブロック７０９）、ＭＰＬＳヘッダ情報を検出し処理するための一連のステップが存在する（ブロック７１１〜７１５）。スイッチがアドレス解決プロトコル（ＡＲＰ）をサポートする場合、ＡＲＰヘッダを処理するための一連のステップが存在する（ブロック７１９及び７２１）。パケットがＩＰヘッダを有する場合（ブロック７２３）、当該ＩＰヘッダを処理するための一連のステップが存在する（ブロック７２５〜７３３）。本処理は、受信されるパケットごとに実行される。

１つの実施形態において、ＯｐｅｎＦｌｏｗ１．１プロトコルとの関係でグループテーブルをサポートすることができる。グループテーブルは、単一のフローの適合が複数のポート上での転送をトリガすることを許容する方法を可能とする。グループテーブルエントリは、４つのフィールドからなる：グループを識別する３２ビットの符号無し整数であるグループ識別子；グループのセマンティクスを決定するグループタイプ；グループについての統計を維持するカウンタ；及び、そのパラメータと共に実行すべきアクションのセットを各々収容するアクションバケットの順序付きリストであるアクションバケットリスト。

グループには４つの異なるタイプがある：バケットリスト内の全てのアクションを実行し、これはブロードキャスト又はマルチキャスト転送のために使用される、オール（All）；ＯｐｅｎＦｌｏｗプロトコルの範囲外のスイッチにより決定されるアルゴリズムに基づいてパケットごとに１つのバケットを実行し、これはマルチパス転送を実装するために使用される、セレクト（Select）；全てのパケットについて単一のバケットを実行し、これは複数の転送テーブルエントリ内で定義されるアクションを有するよりもむしろ複数のフロー又はグループがアクションの単一の集合をポインティングすることを可能とする、インダイレクト（Indirect）；各バケットがその生存性（liveness）を制御するポートに関連付けられる状況において第１の生存バケット（live bucket）を実行し、これはコントローラの関与なく他のポートへスイッチがフェイルオーバすることを可能とする、高速フェイルオーバ（Fast Failover）。

ＯｐｅｎＦｌｏｗ１．１を利用して、仮想ポートをサポートすることができる。ここで使用されるように、仮想ポートは、物理ポートが行うようにネットワーク接続へ向けてパケットを単純に転送するのではなく、何らかの種類の処理アクションを実行する“アクションブロック”である。数少ないビルトインの仮想ポートの例は：入口ポート及び“転送不要（Do Not Forward）”とマークされた任意のポートを除く全てのポートへポートを転送するオール（ALL）；パケットをカプセル化してコントローラへ送信するコントローラ（CONTROLLER）；パケットを第１のフローテーブルへ投入（submit）することによりパケット処理パイプラインへ挿入し、本アクションはパケットアウトメッセージのアクションセット内でのみ有効である、テーブル（TABLE）；及び、パケットを入力ポートから送出するイン＿ポート（IN_PORT）。他の実施形態において、スイッチによって定義される仮想ポートもあり得る。

［３Ｇ ＰＣアーキテクチャ］
図８は、３Ｇパケットコア（３Ｇ ＰＣ）ネットワークの１つの実施形態の図である。３Ｇ ＰＣネットワークは、コアネットワーク（ＣＮ）８０１、無線アクセスネットワーク（ＲＡＮ）８０３、及びユーザ機器（ＵＥ）８０５という、相互作用する３つのドメインからなる。ユーザ機器８０５は、コンピューティングデバイス、セルラーフォン及び類似のデバイスであり得る。無線アクセスネットワーク８０３は、ＵＭＴＳ（universal mobile telecommunications system）８４１又はＧＳＭ（global systems for mobile communications）ネットワーク８４３を含む任意の数のネットワーク又は任意のネットワークの組合せであり得る。これらネットワークは、無線ネットワークセンタ（ＲＮＣ）８３１又はパケット制御ユニット（ＰＣＵ）８３３を通じてコアネットワーク８０１とインタフェースすることができる。

コアネットワーク８０１の主な機能は、ユーザ機器８０５からのユーザトラフィックについて、スイッチング、ルーティング及びトランジットを提供することである。コアネットワーク８０１は、データベース及びネットワーク管理機能をも含む。それは、ＧＳＭ／ＧＰＲＳ、ＷＣＤＭＡ（wideband code division multiple access）／ＨＳＰＡ（high speed packet access）及び非３ＧＰＰモバイルネットワークについて共通的なパケットコアネットワークである。コアネットワーク８０１は、インターネットプロトコル（ＩＰ）パケットを送信するために使用される。コアネットワーク８０１は、ＧＧＳＮ８１９を通じて、インターネット８５１及び他のネットワーク８５３とインタフェースする。

コアネットワーク８０１は、回線交換ドメイン及びパケット交換ドメインに区分される。回線交換用のエレメントは、ＭＳＣ（mobile services switching centre）８１１、ＶＬＲ（visitor location register）８１３及びゲートウェイＭＳＣ８１５を含む。パケット交換用のエレメントは、ＳＧＳＮ８１７及びＧＧＳＮ８１９である。ＥＩＲ８２１、ＨＬＲ８２３、ＶＬＲ８１３及びＡＵＣ８２５のような他のネットワークエレメントは、双方のドメインによって共用される。

コアネットワーク８０１のアーキテクチャは、新たなサービス及び特徴が導入されると変化し得る。他の実施形態では、ユーザが古い電話番号を維持しつつネットワークを変更することを可能とするために、ＮＰＤＢ（number portability database）が使用され得る。ネットワーク境界間の加入者ハンドリングを最適化するために、ＧＬＲ（gateway location register）が使用されてもよい。

モバイル無線ネットワーキングに関するコアネットワーク８０１の主要な機能は、モビリティ管理及びＱｏＳである。これら機能は、典型的には固定ブロードバンドネットワークでは提供されないが、無線ネットワークにとっては極めて重要（crucial）である。モビリティ管理は、無線端末がある基地局から他へと移動する場合にパケットネットワークの接続性を保証するために必要とされる。ＱｏＳが必要とされるのは、固定ネットワークとは違って、無線リンクは端末へどの程度の帯域を提供可能であるかに厳密に制約され、ユーザに受入れ可能なサービス品質を提供するために固定ネットワークよりも厳しく帯域を管理する必要があるためである。

モビリティ管理機能及びＱｏＳ機能を実装するためのシグナリングは、ＧＰＲＳトンネリングプロトコル（ＧＴＰ）により提供される。ＧＴＰは、２つのコンポーネントを有する：ＧＴＰ−Ｃ … モビリティ管理のためのトンネルの確立と、有線バックホール及びパケットコアのＱｏＳを無線リンクＱｏＳに適合させるＱｏＳ管理のためのベアラの確立とをサポートする制御プレーンプロトコル；及び、ＧＴＰ−Ｕ … ルータとして動作するネットワークエレメントの間のトンネルを実装するために使用されるデータプレーンプロトコル。ＧＴＰ−Ｃプロトコルには２つのバージョンがあり、即ちＧＴＰバージョン１（ＧＴＰｖ１−Ｃ及びＧＴＰｖ１−Ｕ）と、（ＬＴＥのために設計された）ＧＴＰバージョン２−Ｃである。ＧＴＰｖ１は、主に、３Ｇ ＰＣベースのシステムとの関係で利用される。

ネットワークサービスは、エンドツーエンドであると見なされ、これは端末機器（ＴＥ：Terminal Equipment）から他のＴＥへという意味である。エンドツーエンドサービスサービスは、ネットワークサービスのユーザに提供されるあるサービス品質（ＱｏＳ）を有し得る。提供されるＱｏＳに満足するか否かを決定するのはユーザである。あるネットワークＱｏＳを実現するために、明確に定義された特性と機能性とを伴うサービスが、サービスのソースから宛て先へとセットアップされることになる。

ＱｏＳパラメータに加えて、各ベアラは、関連付けられるＧＴＰトンネルを有する。ＧＴＰトンネルは、トンネルエンドポイントノード（無線基地局、ＳＧＳＮ及びＧＧＳＮ）のＩＰアドレス、ソース及び宛て先ＵＤＰポート、及びトンネルエンドポイント識別子（ＴＥＩＤ）からなる。ＧＴＰトンネルは一方向的であって、よって各ベアラは２つのＴＥＩＤに関連付けられ、１つはアップリンク、１つはダウンリンクのトンネルである。ＧＴＰトンネルの１つのセット（アップリンク及びダウンリンク）は、無線基地局とＳＧＳＮとの間に延伸し、１つのセットはＳＧＳＮとＧＧＳＮとの間に延伸する。ＧＴＰ−ＵのためのＵＤＰ宛て先ポート番号は２１５２である一方、ＧＴＰ−Ｃのための宛て先ポート番号は２１２３である。ソースポート番号は、送信ノードによって動的に割り当てられる。図９は、プライマリＧＴＰ−Ｕカプセル化ヘッダ内のヘッダフィールド群の１つの実施形態の図である。

［クラウドコンピューティング］
データセンタは、外部の顧客に、コンピューティング、ストレージ及びネットワーク通信リソースを提供する。提供されるサービスは、より実際的な目的では顧客の支払い能力によってのみ制限される、弾性的でオンデマンドのプロセッシング、ストレージと、インターネットへのネットワーク帯域と、からなることができる。このデータセンタにより提供されるサービスのセットを、ここでクラウドコンピューティングという。

サーバ仮想化技術は、サーバのプールを本質的に１つの大規模な計算リソースとして管理することを可能とする。オペレーティングシステムとハードウェアとの間に、ハイパーバイザ（hypervisor）と呼ばれるソフトウェアのレイヤが存在する。ハイパーバイザは、仮想マシン（ＶＭ）の実行をスケジューリングする。ＶＭは、いくつかのアプリケーションと共にパッケージ化されたオペレーティングシステムイメージである。ハイパーバイザは、ＶＭが一時停止しロードバランシングのためにサーバ間で移動することを可能とする。ロードバランシング、及びクラッシュを捕捉するためのＶＭの実行のモニタリングは、特殊なソリューションと共により高コストで達成される企業アプリケーションのために、同じ種類の耐障害性（fault tolerance）とスケーラビリティサービスとを提供する。クラウドマネージャシステムは、ＶＭの実行、ＶＭの需要を満たすための実行のスケジューリング、並びにサーバ利用の最適化及び電力消費の最小化を監督する。クラウドマネージャあるいはクラウドオペレーティングシステムは、クラウドコンピューティングシステムにおけるＶＭ及びそのアプリケーションへの進行中のサービスの提供に影響を与えることなくハードウェア及びソフトウェアのサービス内アップグレードを可能とするように、実行をスケジューリングすることのできるソフトウェアプログラムである。

マシン間のＶＭの任意の移動をサポートするために、データセンタ内のネットワーキングもまた仮想化されなければならない。クラウドコンピューティングシステムは、ハイパーバイザに仮想スイッチを取り入れることにより、ネットワークを仮想化することができる。仮想スイッチは、ハイパーバイザの制御下で実行中のＶＭに仮想ネットワークポートを提供する。仮想スイッチソフトウェアは、サーバリソースがハイパーバイザによって仮想化されるのと同様のやり方で、ネットワークリソースを仮想化することも可能とする。ハイパーバイザ及び仮想スイッチは、それにより、ＶＭがサーバ間で移動可能となるように協働する。ハイパーバイザは、ＶＭを移動させる際、新たなロケーションに関して仮想スイッチと通信し、仮想スイッチは、パケットが新たなロケーションへルーティングされるようにＶＭのアドレス（Ｌ２ＭＡＣアドレス、潜在的にＩＰアドレスも）についてのネットワークルーティングテーブルが更新されることを保証する。

クラウドコンピューティングシステムは、どういった範囲のケイパビリティ（例えば、処理パワー又はストレージ容量）を有するいくつのコンピューティングデバイスから構成されることもできる。クラウドコンピューティングシステムは、プライベートシステムでもパブリックシステムでもあり得る。コンピューティングデバイスは、いかなる通信システム又はネットワークをまたいで互いに通信することもできる。クラウドコンピューティングシステムは、単一のクラウド若しくはサービスをサポート可能であり、又はいくつの離散的なクラウド若しくはサービスをサポートすることもできる。サービス、アプリケーション及び同様のプログラムは、標準的なコードとして仮想化され又は実行され得る。１つの実施形態において、クラウドコンピューティングシステムは、ウェブサービスアプリケーションをサポートすることができる。ウェブサービスアプリケーションは、ウェブサーバのプールへリクエストを送り出すロードバランシングフロントエンドからなる。リクエストはインターネット上のリモートマシン上のアプリケーションから発せられ、従って、プライベートな企業ネットワーク内のアプリケーションのためのものよりも、セキュリティ及びプライバシー要件は非常に緩い。

クラウドコンピュータシステムは、セキュアなマルチテナント（multi-tenancy）をサポートすることもでき、そこでは、クラウドコンピュータシステムプロバイダは、クラウド外のクライアントの分散したオフィスネットワークと、クラウドコンピューティングシステム内のＶＰＮとの間のＶＰＮ（virtual private network）ライクな接続を提供する。これは、クラウドコンピューティングシステム内のクライアントのアプリケーションが企業ＷＡＮに似たネットワーク環境において動作することを可能とする。プライベートデータセンタについては、当該データセンタを所有する企業の範囲内の顧客にサービスが提供されるのみであり、マルチテナントのためのセキュリティ及びプライバシー要件は緩和される。しかし、パブリックデータセンタについては、複数のテナントからのトラフィックが隔離されており、１つのクライアントからのトラフィックが他のクライアントのネットワークへ到達する可能性が無いことを、クラウド事業者は保証しなければならない。

図１０は、クライアントのセットへサービスするクラウドコンピューティングシステムの１つの実施形態の図である。ここで使用されるように、“セット”は、正である任意の総数のアイテムをいう。図１０に示した実施形態では、２つの仮想プライベートクラウド（ＶＰＣ）が２つの異なる外部の企業顧客のためにセットアップされている。ＶＰＣは、ＶＭ、ストレージ及びネットワークリソースの集合から構成され、それらはクラウド内のスペースを借り受けている企業にセキュアなマルチテナントを提供する。企業顧客は、パブリック事業者ネットワーク上で稼働しているインターネット上のＶＰＮを介して、ＶＰＣへ接続する。

図１１は、クライアントのＶＰＣへ新たなサービスインスタンスを追加する処理を示す、クラウドコンピューティングシステムの他の実施形態の図である。このケースでは、クラウド内のＶＰＮは、ＭＡＣレイヤ仮想ＬＡＮ（ＶＬＡＮ）を用いて実装される。新たなサービスインスタンスをリクエストする企業のために、ＶＰＣ内のハイパーバイザ管理型サーバ（hypervisor managed server）上にＶＭが生成される（ステップ１）。新たなＶＭを企業のクラウド内ＶＰＮに含めるように仮想スイッチＶＬＡＮが構成され、それによりクラウド内のサービス接続性が確立される（ステップ２）。新たなサービスのために仮想カスタマエッジルータ（ＣＥ）が更新される（ステップ３）。新たなサービスで、企業ＶＰＮが稼動している事業者ネットワーク内のプロバイダエッジルータが更新される（ステップ４）。

［クラウドコンピューティングシステムにおける３Ｇ ＰＣの実装］
図１２は、クラウドコンピューティングシステム内に実装されるＥＰＣの１つの実施形態の図である。３Ｇ ＰＣの制御プレーンエンティティ（ＡＵＣ，ＨＬＲ，ＨＳＳ）１２０７、及びサポートノード（ＳＧＳＮ，ＧＧＳＮ）の制御プレーン部分１２０７、即ちＧＴＰシグナリングをハンドリングする部分が、ＯｐｅｎＦｌｏｗコントローラ１２０５の一部としてクラウドコンピューティングシステム１２０１内に実装される。制御プレーンエンティティ１２０７及びＯｐｅｎＦｌｏｗコントローラ１２０５は、ＶＭとしてパッケージ化される。ＯｐｅｎＦｌｏｗコントローラ１２０５と制御プレーンエンティティ１２０７との間のアプリケーションプログラムインタフェース（ＡＰＩ）は、リモートプロシージャコール（ＲＰＣ）又は類似のインタフェースであり得る。この実装技術は、クラウド内の制御プレーンエンティティのスケーラブルな管理にとって好都合であり、なぜなら、需要に従って別々に制御プレーンエンティティ１２０７の実行とコントローラ１２０５の実行とを管理することを可能とするからである。クラウドマネージャ１２０３は、ＶＭか、又はクラウドコンピューティングシステム１２０１内で実行されるアプリケーションであり得る。

クラウドマネージャ１２０３は、３Ｇ ＰＣ制御プレーンエンティティ１２０７のＣＰＵ（central processor unit）利用率、及びクラウド内の３Ｇ ＰＣ制御プレーンエンティティ１２０７間の制御プレーントラフィックをモニタリングする。また、エンドユーザデバイス（ＵＥ）１２２５と、クラウドコンピューティングシステム１２０１内に制御プレーンエンティティを有しないＮｏｄｅＢ１２１７、及び３Ｇ ＰＣ制御プレーンエンティティ１２０７との間の制御プレーントラフィックをもモニタリングする。３Ｇ ＰＣ制御プレーンエンティティ１２０７が例えば過剰なＣＰＵ時間の利用又は処理すべき過剰なトラフィックのキューイングといった過負荷のサインを呈し始めると、過負荷を受けている制御プレーンエンティティ１２０７は、クラウドマネージャ１２０３に、負荷をハンドリングする新たなＶＭをスタートアップすることをリクエストする。追加的に、３Ｇ ＰＣ制御プレーンエンティティ１２０７は、過負荷を経験し始めていることを内部的に検出した場合に、自分でクラウドマネージャ１２０３へイベント通知を発行することができる。

クラウドマネージャ１２０４は、いずれかの３Ｇ ＰＣ制御プレーンエンティティ１２０７がクラッシュしそうであれば、特定の制御プレーンエンティティ１２０７又は機能のためのＶＭをリスタートさせることにより、信頼性及びフェイルオーバをも提供する。このリスタート処理の間、クラウドマネージャは、診断データを収集し、障害を起こした３Ｇ ＰＣ制御プレーンエンティティのコアファイルを保存し、システム管理者へ障害が発生したことを通報することができる。制御プレーンエンティティ１２０７は、図８に示した３ＧＰＰ ３Ｇ ＰＣアーキテクチャ内のものと同じ、制御プレーンエンティティの間のプロトコルインタフェースを維持する。

ここでは点線で示されているＯｐｅｎＦｌｏｗ制御プレーン１２３２１は、ネットワーク内のルーティング及びスイッチング構成を管理する。ＯｐｅｎＦｌｏｗ制御プレーン１２２１は、クラウドコンピューティングシステム１２０３を、ＳＧＳＮ−Ｄ１２１５（即ち、ＳＧＳＮのデータプレーン）、標準ＯｐｅｎＦｌｏｗスイッチ１２１３、及びＧＧＳＮ−Ｄ１２１１（即ち、ＧＧＳＮのデータプレーン）へ接続する。ＯｐｅｎＦｌｏｗ制御プレーン１２２１の物理的な実装は、完全に別個の物理ネットワークとしてなされてもよく、又は同じ物理ネットワーク上でデータプレーンとして稼動する仮想ネットワークであってもよい。仮想ネットワークは、優先度付きＶＬＡＮ若しくはＭＰＬＳラベルスイッチパスで実装され、又はＧＲＥ（generic routing encapsulation）若しくは他のＩＰトンネルでさえ実装されてよい。ＯｐｅｎＦｌｏｗ制御プレーン１２２１は、原理上は、ＧＴＰ−Ｃ及び他のモバイルネットワークシグナリングとして、同じ物理制御プレーンパスを使用することができる。ＳＧＳＮ−Ｄ１２１５及びＧＧＳＮ−Ｄ１２１１は、以下でさらに説明されるＯｐｅｎＦｌｏｗ ＧＴＰスイッチ拡張を用いてパケットカプセル化し及び非カプセル化（decapsulate）する、ＯｐｅｎＦｌｏｗ ＧＴＰ拡張ゲートウェイとして動作する。

３Ｇ ＰＣとＮｏｄｅＢとの間で必要とされる無線アクセスネットワーク（ＲＡＮ）シグナリングは単にＩＰルーティングパラメータではなく無線パラメータを含むため、ＮｏｄｅＢ１２１７は、クラウド内に制御プレーンエンティティを有しない。従って、クラウドコンピューティングシステム１２０１内のＯｐｅｎＦｌｏｗコントローラ１２０５とＮｏｄｅＢ１２１７との間にＯｐｅｎＦｌｏｗ制御プレーン１２２１接続は無い。ＮｏｄｅＢ１２１７は、しかしながら、ＯｐｅｎＦｌｏｗを用いたデータプレーン接続へのローカル制御を実装することにより、ＯｐｅｎＦｌｏｗ ＧＴＰ拡張ゲートウェイとして動作することができる。これは、ＮｏｄｅＢ１２１７のパケットスイッチングの側面がパケットゲートウェイとして同じＯｐｅｎＦｌｏｗ ＧＴＰスイッチング拡張を利用することを可能とする。

３Ｇ ＰＣクラウドコンピューティングシステムの動作は次のように働く。ＵＥ１２２５、ＮｏｄｅＢ１２１７、ＳＧＳＮ１２０７及びＧＧＳＮ１２０７は、ＧＴＰトンネルを確立し、修正し及び削除するために、ＨＬＲ、ＨＳＳ、ＡＵＣ、ＳＭＳ−ＧＭＳＣ１２０７へ標準的な３Ｇ ＰＣプロトコルを用いてシグナリングを行う。このシグナリングは、リクエストされた通りに３Ｇ ＰＣ内のルーティングを修正する、ＯｐｅｎＦｌｏｗコントローラに伴うプロシージャコールをトリガする。ＯｐｅｎＦｌｏｗコントローラは、制御プレーンエンティティによりリクエストされたルーティングを可能とするフロールール及びアクションで、標準のＯｐｅｎＦｌｏｗスイッチ、ＯｐｅｎＦｌｏｗ ＳＧＳＮ１２１５及びＧＧＳＮ１２１１を構成する。この構成の詳細は、以下にさらに詳細に説明される。

図１３は、３Ｇ ＰＣの基本的な動作の１つの実施形態のフローチャートである。１つの実施形態において、クラウドコンピューティングシステム内のＯｐｅｎＦｌｏｗコントローラ内の３Ｇ ＰＣの制御プレンモジュールの初期化によって、処理は開始される（ブロック１３４０１）。複数の制御プレーンモジュールのうちの各制御プレーンモジュールは、クラウドマネージャにより別個のＶＭとして初期化される。そして、クラウドマネージャは、各制御プレーンモジュールのリソース利用率と共に、各制御プレーンモジュールによりハンドリングされる制御プレーントラフィックの量とタイプとをモニタリングする（ブロック１３０３）。クラウドマネージャは、このデータを直接的にモニタリングし、制御プレーンモジュールからレポートを受信し、又はそれらの組合せを行い得る。

クラウドマネージャは、モニタリング中の複数の制御プレーンモジュールのうちのいずれかについて閾値レベルのリソース利用率又はトラフィック負荷を検出すると（ブロック１２０５）、このシナリオに自動的に対処するためのステップを行うことができる。クラウドマネージャは、別個の仮想マシンとして、新たな制御プレーンモジュール又は当該制御プレーンモジュールのインスタンスを初期化し得る（ブロック１２０７）。そして、この新たな制御プレーンモジュール又はインスタンスは、同じタイプの既存の制御プレーンモジュール又はインスタンスの負荷をシェアすることができ、それにより当該モジュール上の負荷が動的に軽減される。

同様に、クラウドマネージャは、複数の制御プレーンモジュールの１つの障害又は利用率低下を検出し得る（ブロック１２０９）。そして、クラウドマネージャは、障害を起こした制御プレーンモジュールをリスタートさせ、又は利用率の低下した制御プレーンモジュールを終了させ得る（ブロック１２１１）。制御プレーンモジュールのリスタートは、制御プレーンモジュールのプールについて、あるレベルの負荷のシェアを保証する。制御プレーンモジュールの非アクティブ化は、リソースを解放し、当該制御プレーンモジュールにより生み出されていたオーバヘッドを削減する。クラウドマネージャは、クラウドコンピューティングシステムのリソースを使用するＶＰＣ及びモバイル事業者をまたいでこれら機能を実行することができ、それにより、モバイル事業者間のデータ及びトラフィックの厳密な隔離を維持しながら、利用可能なリソースの使用が最大化され、運用コストが削減される。

図１４は、単一のデータセンタの外部の複数の事業者ネットワークを管理サービス会社が管理することをクラウドコンピューティングシステム内の３Ｇ ＰＣがどのように可能にするかの１つの実施形態の図である。管理サービスクラウドコンピューティング設備１４０１は、管理サービス会社がコンタクトを有するモバイル事業者ごとに、３Ｇ ＰＣ制御プレーンの別個のインスタンスを稼働させる。各３Ｇ ＰＣインスタンスは、データセンタのクラウドコンピューティング設備１４０１内の他のテナントからモバイル事業者のトラフィックを隔離するＶＰＣ１４０３Ａ、Ｂ内にある。モバイル事業者のための３Ｇ ＰＣ制御プレーンインスタンスは、モバイル事業者の地理的に分散した３Ｇ ＰＣ ＯｐｅｎＦｌｏｗデータプレーンスイッチングファブリック１４０７Ａ、Ｂ、及びモバイル事業者の基地局群へ、仮想エッジルータ１４０９Ａ、Ｂを通じて接続される。仮想エッジルータ１４０９Ａ、Ｂは、データセンタと、適切なモバイル事業者の３Ｇ ＰＣデータプレーンスイッチングファブリック１４０７Ａ、Ｂとの間で、データセンタからのからのトラフィックをルーティングする。図１４の例としての実施形態は２つのモバイル事業者が別個のスイッチングファブリックを有するケースを示しているが、いくつかのケースでは、モバイル事業者は、基地局及び３Ｇ ＰＣスイッチングファブリックを共用さえしてもよい。

［３Ｇ ＰＣピアリング及びクラウドコンピューティングシステム内の差別化ルーティング］
図１５は、特殊なサービスの取り扱い（specialized service treatment）のための３Ｇ ＰＣピアリング（peering）及び差別化ルーティング（differential routing）のための処理の１つの実施形態の図である。実線及び矢印１５０１で示されているＯｐｅｎＦｌｏｗシグナリングは、３Ｇ ＰＣ内のスイッチ及びゲートウェイ上に差別化ルーティングのためにフロールール及びアクションをセットアップする。それらフロールールは、ＧＴＰフローを特定のロケーションへと向かわせる。この例における事業者は、自身の３Ｇ ＰＣを、他の２つの固定事業者とピアリングさせる。各ピアリング点を通じたルーティングは、それぞれＧＧＳＮ１及びＧＧＳＮ２ １５０３Ａ、Ｂによりハンドリングされる。破線及び矢印１５０５は、他のピアリング事業者へルーティングされる必要のある、ＵＥ１５０７からのトラフィックを示している。ＯｐｅｎＦｌｏｗスイッチ１５０９及びゲートウェイ１５０３Ａ、Ｂ内に、ＯｐｅｎＦｌｏｗコントローラ１５１１により、トラフィックがどのピアリング点を通過すべきかを区別するフロールール及びアクションがインストールされる。ＯｐｅｎＦｌｏｗコントローラ１５１１は、外部トラフィックについて維持しているルーティングテーブル、並びにパケットのソース及び宛て先に基づいて、さらにＤＳＣＰでマークされたパケットについて要する任意の特殊な転送の取り扱いによって、これらフロールール及びアクションを計算する。

２点鎖線及び矢印１５１５は、外部ソースからコンテンツを取得しているＵＥ１５１７の例を示している。コンテンツは、もともとはＵＥ１５１７の画面のために編成されておらず、そのため、ＯｐｅｎＦｌｏｗコントローラ１５１１は、ＧＧＳＮ１ １５０３Ｂ、ＳＧＳＮ １５１９及びＯｐｅｎＦｌｏｗスイッチ１５０９上に、当該フローをクラウドコンピューティング設備内のトランスコーディングアプリケーション１５２１を経由させるようにルーティングするためのフロールール及びアクションをインストールしている。トランスコーディングアプリケーション１５２１は、コンテンツをＵＥ１５１７の画面にフィットするように再フォーマットする。ＭＳＣは、ＵＥがＩＰマルチメディアサブシステム（ＩＭＳ）又は他のシグナリングプロトコルを介して外部のコンテンツソースとのセッションをセットアップする際に、この特殊な取扱いをリクエストする。

［ＧＴＰ ＴＥＩＤルーティング］
１つの実施形態において、ＯｐｅｎＦｌｏｗは、ＧＴＰ ＴＥＩＤルーティングを提供するように修正される。図１６は、ＧＴＰ ＴＥＩＤルーティングのためのＯｐｅｎＦｌｏｗテーブルの修正の１つの実施形態の図である。ＴＥＩＤルーティングをサポートするＯｐｅｎＦｌｏｗスイッチは、少なくとも１つのフローテーブル（例えば、最初のフローテーブル）において、他のＯｐｅｎＦｌｏｗヘッダフィールドに加えて、２バイト（１６ビット）のヘッダフィールドの集合と４バイト（３２ビット）のＧＴＰ ＴＥＩＤについてのマッチングを行う。ＧＴＰ ＴＥＩＤフラグは、ワイルドカードであり得る（即ち、マッチングは“何でもよい”）。１つの実施形態において、３Ｇ ＰＣプロトコルは、ＴＥＩＤに、標準的なＵＤＰ／ＴＣＰトランスポートプロトコルにおけるポートのような、トンネルについてのエンドポイント識別子としてのもの以外の何らの意味も割当てない。他の実施形態において、ＴＥＩＤは、相関付けられる意味及びセマンティクスを有し得る。ＧＴＰヘッダフラグフィールドはワイルドカードであってもよく、これは次のビットマスクと組み合わせることで部分的にマッチングされ得る：０ｘＦＦ００ … メッセージタイプフィールドとマッチング；０ｘｅ０ … バージョンフィールドとマッチング；０ｘ１０ … ＰＴフィールドとマッチング；０ｘ０４ … Ｅフィールドとマッチング；０ｘ０２ … Ｓフィールドとマッチング；及び、０ｘ０１ … ＰＮフィールドとマッチング。

１つの実施形態において、ＯｐｅｎＦｌｏｗは、高速パス（fast path）ＧＴＰ ＴＥＩＤカプセル化及び非カプセル化のための仮想ポートをサポートするように修正され得る。ＯｐｅｎＦｌｏｗモバイルゲートウェイは、仮想ポートと共にＧＴＰカプセル化及び非カプセル化をサポートするために使用され得る。ＧＴＰカプセル化及び非カプセル化の仮想ポートは、ＧＴＰ−Ｕトンネル内でのユーザデータパケットの高速なカプセル化及び非カプセル化のために使用され、ハードウェアで又はファームウェアで十分に実装可能な程度に単に設計され得る。この理由で、ＧＴＰ仮想ポートは、それらがハンドリングすることになるトラフィックについて、次の制限を有し得る：プロトコルタイプ（ＰＴ）フィールド＝１、この場合ＧＴＰカプセル化ポートはＧＴＰのみをサポートし、ＧＴＰ´（ＰＴフィールド＝０）をサポートしない；拡張ヘッダフラグ（Ｅ）＝０、この場合サポートされる拡張ヘッダはない、シーケンス番号フラグ（Ｓ）＝０、この場合シーケンス番号はサポートされない；Ｎ−ＰＤＵフラグ（ＰＮ）＝０；及び、メッセージタイプ＝２５５、この場合Ｇ−ＰＤＵメッセージ、即ちトンネリングされるユーザデータのみが高速パスにおいてサポートされる。

パケットがカプセル化を必要とし、若しくは非ゼロのヘッダフラグ、ヘッダ拡張と共にカプセル化されて受信された場合、及び／又は、ＧＴＰ−ＵパケットがＧ−ＰＤＵパケットではない（即ち、ＧＴＰ−Ｕ制御パケットである）場合、処理は、ゲートウェイの低速パス（ソフトウェア）制御プレーンを介して進められなければならない。ゲートウェイのＩＰアドレス宛てのＧＴＰ−Ｃパケット及びＧＴＰ´パケットは、構成ミスの結果であってエラーである。それらパケットは、クラウドコンピューティングシステム内のＳＧＳＮ及びＧＧＳＮ制御プレーンエンティティによりハンドリングされるため、ＯｐｅｎＦｌｏｗコントローラへ送信されなければならず、又は、ＳＧＳＮ及びＧＧＳＮデータプレーンスイッチではなく、ＧＴＰ´をハンドリングする請求エンティティへ送信されなければならない。

ＧＴＰ仮想ポートは、構成プロトコルを用いて、ＯｐｅｎＦｌｏｗコントローラから構成される。構成プロトコルの詳細は、スイッチ依存である。構成プロトコルは、次の機能を実行するメッセージをサポートしなければならない：スイッチがＧＴＰ高速パス仮想ポートをサポートするか、並びに高速パス及び低速パスＧＴＰ−Ｕ処理のためにどの仮想ポート番号が使用されるか、の標識をコントローラが問合せし及び返答することを可能とすること；ＯｐｅｎＦｌｏｗテーブルのset-output-portアクションにおける使用のためにスイッチのデータパス内にＧＴＰ−Ｕ高速パス仮想ポートをコントローラがインスタンス化することを可能とすること。アクションの結果がコントローラへレポートバックされた際に、リクエストされたデータパスのためのＧＴＰ−Ｕ高速パス仮想ポートがインスタンス化されており、又はリクエストが報われなかった理由を示すエラーが返信されるように、構成コマンドはトランザクションにおいて実行されなければならない。コマンドは、ＯｐｅｎＦｌｏｗコントローラがＧＴＰ−Ｕ仮想ポートを物理ポートにバインディングすることをも可能とする。非カプセル化仮想ポートについて、物理ポートは入力ポートである。カプセル化仮想ポートについて、物理ポートは出力ポートである。

ＯｐｅｎＦｌｏｗコントローラは、ＧＴＰ ＴＥＩＤルーティングのためのスイッチ内にルールをインストールするに先立って、ＧＴＰトンネルを通じてルーティングされるパケットを送信し又は受信し得る物理ポートごとに、仮想ポートをインスタンス化する。

１つの実施形態において、ＯｐｅｎＦｌｏｗ ＧＴＰゲートウェイは、ＧＴＰ ＴＥＩＤをそれらのベアラのためのトンネルヘッダフィールドへマッピングするハッシュテーブルを維持する。図１７は、フローテーブルの行の構造の図である。ＴＥＩＤのハッシュキーは、例えばＳＨＡ−１といった、衝突頻度の低い適切なハッシュアルゴリズムを用いて計算される。ゲートウェイは、ＧＴＰ ＴＥＩＤ／ベアラごとにこうした１つのフローテーブルの行を維持する。ＴＥＩＤフィールドは、当該トンネルのためのＧＴＰ ＴＥＩＤを含む。ＶＬＡＮタグフィールド及びＭＰＬＳラベルフィールドは、パケットのルーティング先とならなければならないトンネルを定義する、ＶＬＡＮタグ及び／又はＭＰＬＳラベルの順序付きリストを含む。ラベル内には、ＶＬＡＮ優先度ビット及びＭＰＬＳトラフィッククラスビットが含まれる。そのようなトンネルは必要とされてもされなくてもよい。必要とされない場合、これらフィールドは空である。トンネリング元（tunnel origin）ソースＩＰアドレスは、当該トンネルに関与する制御トラフィック（例えば、エラー標識）が向かうべきカプセル化ゲートウェイ上のアドレスを含む。トンネリング先（tunnel end）宛て先ＩＰアドレスフィールドは、トンネリングされるパケットのルーティング先となるべきゲートウェイのＩＰアドレスを含み、そのルーティング先においてパケットは逆カプセル化されＧＴＰトンネルから除去されることになる。ＱｏＳ ＤＳＣＰフィールドは、もしあるならば、専用ベアラのケースにおいてベアラについてのＤｉｆｆＳｅｒｖｅコードポイントを含む。このフィールドは、ベアラがベストエフォート型のＱｏＳを伴うデフォルトベアラであれば空であってよく、但しベアラＱｏＳがベストエフォートを超えるものであれば非ゼロの値を含むであろう。

１つの実施形態において、ＧＴＰのための低速パスのサポートが、ＯｐｅｎＦｌｏｗゲートウェイスイッチと共に実装される。ＯｐｅｎＦｌｏｗモバイルゲートウェイスイッチは、低速パスパケット処理のためのソフトウェア制御プレーンについてのサポートをも含む。このパスは、非ゼロのヘッダフィールド又は拡張ヘッダを伴うＧ−ＰＤＵ（メッセージタイプ２５５）パケット、及びそうしたフィールドでのカプセル化又は拡張ヘッダの追加を要するユーザデータプレーンパケットによって、またＧＴＰ−Ｕ制御パケットによって選択される（taken）。この目的で、スイッチは、ソフトウェア制御プレーン内で３つのローカルポートをサポートする：LOCAL_GTP_CONTROL … スイッチの高速パスがＧＴＰ−Ｕ制御メッセージを含むゲートウェイＩＰアドレス宛てのＧＴＰカプセル化パケットを転送し、ローカルスイッチソフトウェア制御プレーンがＧＴＰ−Ｕ制御メッセージに依存してローカル制御プレーンのアクションを開始する；LOCAL_GTP_U_DECAP … スイッチの高速パスが非ゼロのヘッダフィールド又は拡張ヘッダを有する（即ち、Ｅ！＝０、Ｓ！＝０、又はＰＮ！＝０）Ｇ−ＰＤＵパケットをこのポートへ転送する。これらパケットは、特殊なハンドリングを要する。ローカルスイッチのソフトウェアの低速パスが当該パケットを処理し特殊なハンドリングを実行する；LOCAL_GTP_U_ENCAP … スイッチの高速パスが非ゼロのヘッダフィールド又は拡張ヘッダ（即ち、Ｅ！＝０、Ｓ！＝０、又はＰＮ！＝０）でのＧＴＰトンネルにおけるカプセル化を要するユーザデータプレーンパケットをこのポートへ転送する。これらパケットは、特殊なハンドリングを要する。ローカルスイッチのソフトウェアの低速パスが当該パケットをカプセル化し特殊なハンドリングを実行する。パケットを転送することに加えて、スイッチの高速パスは、ＯｐｅｎＦｌｏｗメタデータフィールドを低速パスソフトウェアに向けて利用可能にする。

低速パスのカプセル化をサポートするために、スイッチ上のソフトウェア制御プレーンは、ＧＴＰ−Ｕ ＴＥＩＤから計算されるキーを伴うハッシュテーブルを維持する。ＴＥＩＤのハッシュキーは、例えばＳＨＡ−１といった、衝突頻度の低い適切なハッシュアルゴリズムを用いて計算される。フローテーブルエントリは、ＧＴＰカプセル化ヘッダを含むパケットヘッダがどのように構成されるべきかのレコードを含む。これは、次を含む：図１８におけるハードウェア又はファームウェアのカプセル化テーブルと同じヘッダフィールド；ＧＴＰヘッダフラグのための値（ＰＴ、Ｅ、Ｓ及びＰＮ）；もしあれば、シーケンス番号及び／又はＮ−ＰＤＵ番号；Ｅフラグが１であれば、フローテーブルは、低速パスがＧＴＰヘッダへ挿入すべきそのタイプを含む拡張ヘッダのリストを含む。

１つの実施形態において、システムは、高速パスカプセル化仮想ポートを実装する。クラウドコンピューティングシステム内で稼働しているＳＧＳＮ及びＧＧＳＮの制御プレーンソフトウェアによりリクエストされると、ＯｐｅｎＦｌｏｗコントローラは、ゲートウェイスイッチをプログラムして、高速パスＧＴＰカプセル化仮想ポートを介してＧＴＰトンネルへパケットをルーティングするための、ルール、アクション及びＴＥＩＤハッシュテーブルエントリをインストールする。ルールは、ＧＴＰトンネルのベアラの入力側にパケットフィルタをマッチングさせる。典型的には、これは、４つのタプルとなる：ＩＰソースアドレス；ＩＰ宛て先アドレス；ＵＤＰ／ＴＣＰ／ＳＣＴＰソースポート；及び、ＵＤＰ／ＴＣＰ／ＳＣＴＰ宛て先ポート。ＩＰソースアドレス及び宛て先アドレスは、典型的には、ユーザデータプレーントラフィックの、即ちＵＥ又はＵＥとやり取り中（transacting）のインターネットサービスのためのアドレスであり、ポート番号についても同様である。ＧＴＰ−Ｕトンネルの入力側にマッチングするルールについて、関連付けられる指示は次の通りである：
Write-Metadata（GTP-TEID, 0xFFFFFFFF）
Apply-Actions（Set-Output-Port GTP-Encap-VP）

スイッチは、パケットについてのトンネルヘッダフィールドを含むＴＥＩＤハッシュテーブル内のエントリの書き込みをも行う。ＧＴＰ−ＴＥＩＤは、ＧＴＰトンネルエンドポイント識別子である。ＧＴＰ−Ｅｎａｃａｐ−ＶＰは、カプセル化されたパケットが最終的にそこからルーティングされることになる物理ポートに結び付けられた、ＧＴＰ高速パスカプセル化仮想ポートである。

パケットヘッダが仮想ポートに関連付けられるルールに適合する場合、ＧＴＰ ＴＥＩＤがメタデータの下位３２ビットに書き込まれ、パケットは仮想ポートへ向けられる。仮想ポートは、ＴＥＩＤのハッシュを計算し、トンネルヘッダテーブル内のトンネルヘッダ情報をルックアップする。当該トンネル情報が存在しなければ、パケットはエラー標識と共にコントローラへ転送される。そうでなければ、仮想ポートは、ＧＴＰトンネルヘッダを構築し、パケットをカプセル化する。何らかのＤＳＣＰビット又はＶＬＡＮ優先度ビットが追加的にＩＰ又はＭＡＣトンネルヘッダへセットされ、何らかのＶＬＡＮタグ又はＭＰＬＳラベルがパケットへプッシュされる。カプセル化されたパケットは、仮想ポートに結び付けられた物理ポートから転送される。

１つの実施形態において、システムは、ＧＴＰ高速パス非カプセル化仮想ポートを実装する。クラウドコンピューティングシステム内で稼働しているＳＧＳＮ及びＧＧＳＮの制御プレーンソフトウェアによりリクエストされると、ゲートウェイスイッチは、ＧＴＰトンネルから出るＧＴＰカプセル化パケットをルーティングするための、ルール及びアクションをインストールする。図１６に示した修正されたＯｐｅｎＦｌｏｗのフローテーブルでは、パケットについてのＧＴＰヘッダフラグ及びＧＴＰ ＴＥＩＤに、次のようにルールがマッチングされる：ＩＰ宛て先アドレスが、ゲートウェイが予期しているＧＴＰトラフィックのＩＰアドレスである；ＩＰプロトコルタイプがＵＤＰ（１７）である；ＵＤＰ宛て先ポートがＧＴＰ−Ｕ宛て先ポート（２１５２）である；ヘッダフィールド及びメッセージタイプフィールドがフラグ０ＸＦＦＦ０でワイルドカード指定されており、フィールドの上位２バイトがＧ−ＰＤＵメッセージタイプ（２５５）に適合し、一方で下位２バイトが０ｘ３０、即ち当該パケットがＧＴＰ´パケットではなくＧＴＰパケットであること、に適合し、バージョン番号が１である。仮想ポートは、単純にＧＴＰトンネルヘッダを除去し、内包されていたユーザデータプレーンパケットを結び付けられている物理ポートから転送する。

１つの実施形態において、システムは、ＧＴＰ−Ｕ制御パケットのハンドリングを実装する。ＯｐｅｎＦｌｏｗコントローラは、ＧＴＰトラフィックのために使用される各ゲートウェイスイッチのＩＰアドレスについて、５つのルールと共にゲートウェイスイッチのフローテーブルをプログラムする。これらルールは、次のようなフィールドのための特定の値を含む：ＩＰ宛て先アドレスは、ゲートウェイが予期しているＧＴＰトラフィックのＩＰアドレスである；ＩＰプロトコルタイプはＵＤＰ（１７）である；ＵＤＰ宛て先ポートはＧＴＰ−Ｕ宛て先ポート（２１５２）である；ＧＴＰヘッダフラグ及びメッセージタイプフィールドはフラグ０ＸＦＦＦ０でワイルドカード指定される；ヘッダフラグフィールドの値は０ｘ３０、即ちバージョン番号が１であってＰＴフィールドが１、である；及び、メッセージタイプフィールドの値は、１（エコーリクエスト）、２（エコーレスポンス）、２６（エラー標識）、３１（拡張ヘッダ通知についてのサポート）又は２５４（エンドマーカ）のうちの１つである。

これらルールのうち１つのマッチングに関連付けられる指示は次の通りである：
Apply-Actions（Set-Output-Port LOCAL_GTP_CONTROL）

これは、パケットがローカルソフトウェア制御プレーンによって処理のためにゲートウェイスイッチのローカルＧＴＰ−Ｕ制御ポートへ転送されることを引き起こす。当該スイッチにより発信されるＧＴＰ−Ｕ制御パケットは、当該ソフトウェア制御プレーン上で生成され、制御プレーンによってルーティングされる。

１つの実施形態において、システムは、拡張ヘッダ、シーケンス番号及びＮ−ＰＤＵ番号を伴うＧ−ＰＤＵパケットのハンドリングを実装する。拡張ヘッダ、シーケンス番号及びＮ−ＰＤＵ番号を伴うＧ−ＰＤＵパケットは、処理のためにローカルスイッチのソフトウェア制御プレーンへ転送される必要がある。ＯｐｅｎＦｌｏｗコントローラは、この目的のために３つのルールをプログラムする。それらは、次の共通的なヘッダフィールドを有する：ＩＰ宛て先アドレスは、ゲートウェイが予期しているＧＴＰトラフィックのＩＰアドレスである；ＩＰプロトコルタイプはＵＤＰ（１７）である；ＵＤＰ宛て先ポートはＧＴＰ−Ｕ宛て先ポート（２１５２）である。

３つのルールについてのヘッダフラグ及びメッセージタイプフィールドは、次のようにビットマスクでワイルドカード指定されマッチングされる；ビットマスク0xFFF4、上位２バイトがＧ−ＰＤＵメッセージタイプ（２５５）に適合し、一方で下位２バイトは０ｘ３４であり、これはバージョン番号が１、当該パケットはＧＴＰパケット、拡張ヘッダが存在することを示す；ビットマスク0xFFF2、上位２バイトがＧ−ＰＤＵメッセージタイプ（２５５）に適合し、一方で下位２バイトは０ｘ３２であり、これはバージョン番号が１、当該パケットはＧＴＰパケット、シーケンス番号が存在することを示す；ビットマスク0xFF01、上位２バイトがＧ−ＰＤＵメッセージタイプ（２５５）に適合し、一方で下位２バイトは０ｘ３１であり、これはバージョン番号が１、当該パケットはＧＴＰパケット、Ｎ−ＰＤＵが存在することを示す。

これらルールについての指示は次の通りである：
Apply-Actions（Set-Output-Port LOCAL_GTP_U_DECAP）

これは、パケットを、特殊な処理のためのソフトウェア低速パスのＧＴＰ−Ｕ逆カプセル化パスへ送る。

１つの実施形態において、システムは、拡張ヘッダ、シーケンス番号及びＮ−ＰＤＵ番号でのＧ−ＰＤＵカプセル化を要するユーザデータプレーンパケットのハンドリングを実装する。ＧＴＰカプセル化の間に拡張ヘッダ、シーケンス番号又はＮ−ＰＤＵ番号を要するユーザデータプレーンパケットは、ソフトウェア低速パスによる特殊なハンドリングを要する。ＯｐｅｎＦｌｏｗコントローラは、これらパケットのために、４つのタプルにマッチングされるルールをプログラムする：ＩＰソースアドレス；ＩＰ宛て先アドレス；ＵＤＰ／ＴＣＰ／ＳＣＴＰソースポート；及び、ＵＤＰ／ＴＣＰ／ＳＣＴＰ宛て先ポート。パケットのマッチングのための指示は：
Write-Metadata（GTP-TEID, 0xFFFFFFFF）
Apply-Actions（Set-Output-Port LOCAL_GTP_U_ENCAP）

これは、パケットを、ソフトウェア低速パスのＧＴＰカプセル化ポートへ送り、さらに低速パスに向けてＴＥＩＤを利用可能にする。

ルールの挿入をプログラムするＯｐｅｎＦｌｏｗメッセージは、シーケンス番号、Ｎ−ＰＤＵ番号又は拡張ヘッダのタイプ及び内容についての値と共に、逆カプセル化ゲートウェイ及びベアラトランスポートを指定するパケットヘッダフィールドと、ＧＴＰ−ＴＥＩＤと、に関する情報をも含む。この情報は、ＴＥＩＤによるキーを付して、スイッチの制御プレーンソフトウェアによってソフトウェアカプセル化テーブルへ挿入される。

１つの実施形態において、システムは、ＧＴＰ−Ｃ及びＧＴＰ´制御パケットのハンドリングを実装する。ゲートウェイスイッチ上のＩＰアドレスに向けられる任意のＧＴＰ−Ｃ及びＧＴＰ´制御パケットは、エラーである（in error）。これらパケットは、スイッチ内のＳＧＳＮ及びＧＧＳＮエンティティではなく、クラウドコンピューティングシステム内のＳＧＳＮ、ＧＧＳＮ及びＧＴＰ´プロトコルエンティティによってハンドリングされる必要がある。そうしたパケットを捕捉するために、ＯｐｅｎＦｌｏｗコントローラは、次の２つのルールでスイッチをプログラムしなければならない：ＩＰ宛て先アドレスは、ゲートウェイが予期しているＧＴＰトラフィックのＩＰアドレスである；ＩＰプロトコルタイプはＵＤＰ（１７）である；１つのルールについてＵＤＰ宛て先ポートはＧＴＰ−Ｕ宛て先ポート（２１５２）であり、他のルールについてＵＤＰ宛て先ポートはＧＴＰ−Ｃ宛て先ポート（２１２３）である；ＧＴＰヘッダフラグ及びメッセージタイプフィールドはワイルドカード指定される。

これらルールは、ゲートウェイスイッチのフローテーブル内の全てのＧＴＰルールのうちで最低の優先度でなければならない。それらは、他のより具体的なルールに適合しないいかなるＧＴＰパケットにも適合するであろう。これらルールについての指示は次の通りである：
Apply-Actions（Set-Output-Port CONTROLLER）

これは、パケットをカプセル化してＯｐｅｎＦｌｏｗコントローラへ送信する。

１つの実施形態において、システムは、非ゲートウェイＧＴＰルーティングを実装する。ＧＴＰ拡張ＯｐｅｎＦｌｏｗスイッチは、カプセル化及び非カプセル化のゲートウェイ機能を実行することなく、ＧＴＰルーティングを達成することもできる。ＧＴＰルーティング機能は、自身のゲートウェイ機能に加えて、ゲートウェイスイッチによって実行されることもでき、又は分散型のＥＰＣスイッチングファブリック内でゲートウェイ機能を欠く他のスイッチによって実行されることもできる。

ＧＴＰ拡張ＯｐｅｎＦｌｏｗスイッチは、図１６におけるもののようなＧＴＰヘッダフィールドとのマッチングを行うルールをハンドリングする、少なくとも１つのフローテーブルを含む。ＯｐｅｎＦｌｏｗコントローラは、ＧＴＰルーティングを行うための他のフィールド加えて、ＧＴＰヘッダフィールドのルールをプログラムし、ルールが適合した場合の適切なアクションを追加する。例えば、次のルールは制御プレーンＶＬＡＮ内には無い、クラウドコンピューティングシステム内の制御プレーンエンティティ（ＭＳＣ，ＳＧＳＮ，ＧＧＳＮ）へ向けられるＧＴＰ−Ｃ制御パケットに適合する：ＶＬＡＮタグが制御プレーンＶＬＡＮに設定されておらず、宛て先ＩＰアドレスフィールドはターゲット制御プレーンエンティティのＩＰアドレスに設定されており、ＩＰプロトコルフィールドはＵＤＰ（１７）であり、ＵＤＰ宛て先ポートはＧＴＰ−Ｃ宛て先ポート（２１２３）であり、ＧＴＰヘッダフラグ及びメッセージタイプは０ｘＦ０でワイルドカード指定され、適合するバージョン及びプロトコルタイプフィールドは２及び１であり、これは当該パケットがＧＴＰｖ１制御プレーンパケットであってＧＴＰ´ではないことを示す。

次のアクションは、制御プレーンＶＬＡＮタグをパケットへプッシュし、それを関係する制御プレーンエンティティによる処理のためにクラウドへ転送する。当該パケットは、何らのＬ３処理もされずに（即ち、ＩＰ ＴＴＬを修正せずに）転送される：
Write-Action（Set-VLAN-ID CP_VLAN_TAG）
Write-Action（Set-Source-MAC-Address SWITCH_MAC_ADDR）
Write-Action（Set-Dest-MAC-Address NEXT_HOP_MAC_ADDR）
Set-Output-Port NEXT_HOP_PORT

［ＯｐｅｎＦｌｏｗのためのＧＴＰの拡張］
３Ｇ ＰＣの管理を可能とするＧＴＰのための拡張を提供するように、ＯｐｅｎＦｌｏｗプロトコルを修正することができる。ＯｐｅｎＦｌｏｗは、当該プロトコルが特定のフローにルールを適合させるための基準を定義することを可能とする、フローマッチ構造と呼ばれるデータ構造を利用する。ofp_matchというＯｐｅｎＦｌｏｗのフローマッチ構造は、フローマッチ構造を拡張可能とする、タイプ及びレングスという２つのフィールドを含む。タイプフィールドは当該拡張のタイプに設定され、レングスフィールドは拡張されたofp_match構造の長さに設定され得る。１つの実施形態において、ＧＴＰフローマッチングのためのランダム数に基づく新たなタイプが定義される：
enum ofp_match_type_ext｛
ERSMT_GTP＝48696,
｝;

タイプは、他の拡張されたタイプと干渉しないように、ランダムに生成され得る。現在のところ、ＯｐｅｎＦｌｏｗにおけるタイプ識別子を登録するための組織的な仕組みは存在しない。

ersmt_gtp構造は、ＧＴＰフローのルーティングのためのフローテーブルのフィールドを次のように定義する：
struct ersmt_gtp｛
unit8_t gtp_wildcard;
uint16_t gtp_type_n_flags;
uint16_t gtp_flag_mask;
uint32_t gtp_teid;
｝;

gtp_type_n_flagsフィールドは、上位８ビットにＧＴＰメッセージタイプを、下位８ビットにＧＴＰヘッダフラグを含む。gtp_teidフィールドは、ＧＴＰ ＴＥＩＤを含む。gtp_wildcardフィールドは、ＧＴＰタイプ及びフラグ並びにＴＥＩＤがマッチングされるべきかを示す。その下位４ビットが１であればタイプ及びフラグフィールドは無視されるべきであり、上位４ビットが１であればＴＥＩＤは無視されるべきである。下位４ビットがゼロであればタイプ及びフィールドフラグはgtp_flag_maskフィールド内のフラグを対象としてマッチングされるべきであり、上位ビットがゼロであればＴＥＩＤはマッチングされるべきである。マスクは、論理ＡＮＤを用いてパケットのメッセージタイプ及びヘッダフィールドと合成され、その結果がマッチングの値となる。当該マスクが値１を有するフィールドの部分のみが、適合（matched）となる。

フローテーブルのフィールドに加えて、仮想ポートＴＥＩＤハッシュテーブルエントリのカプセル化をエンコードするためのオブジェクトが必要とされる。ersmt_gtp_tuninfo構造を、この情報を定義するために使用することができる：
struct ermst_mpls_lbl｛
uint8_t mpls_lbl_low;
uint8_t mpls_lbl_mid;
uint8_t mpls_lbl_high;
｝;

struct ersmt_gtp_tuninfo｛
uint16_t gtp_tuninfo_length;
uint32_t gtp_tuninfo_saddr;
uint32_t gtp_tuninfo_daddr;
uint8_t gtp_tuninfo_dscp;
uint8_t gtp_tuninfo_vlan_len;
unit16_t gtp_tuninfo_vlan_tags[0]; /*variable length*/
uint8_t gtp_tuninfo_mpls_len;
struct mpls_lbl gtp_tuninfo_mpls_labels[0]; /*variable length*/
｝;

ermst_mpls_lbl構造体（struct）は、ＭＰＬＳラベルをエンコードするための２４ビットのデータ構造を提供する。ersmt_gtp_tunifo構造は、ＧＴＰトンネルを記述するフィールド群を含む。これらは、カプセル化仮想ポートへ挿入される。当該構造は可変長であり、なぜなら可変的な数のＶＬＡＮタグ及び／又はＭＰＬＳラベルを含み得るからである。gtp_tuninfo_lengthフィールドは、当該構造の長さを含む。gtp_tuninfo_saddr、gtp_tuninfo_daddr及びgtp_tuninfo_dscpフィールドは、当該トンネルのソースアドレス（カプセル化を実行するスイッチ上のインタフェースのアドレス）、当該トンネルの宛て先アドレス（トンネリングされるパケットのルーティング先となり当該パケットを逆カプセル化することとなるスイッチ）、及び、（もしあれば）当該トンネルのベアラに割り当てられたＤｉｆｆＳｅｒｖｅコードポイント、を含む。ベアラのＤＳＣＰは、当該ベアラが専用ベアラであってベストエフォート型のベアラでなければ、非ゼロとなる。

gtp_tuninfo_vlan_len及びgtp_tuninfo_mpls_lenは、それぞれ、ＶＬＡＮタグフィールド及びＭＰＬＳラベルフィールドの長さを含む。gtp_tuninfo_vlan_tags[0]及びgtp_tuninfo_mpls_labels[0]フィールドは、パケットのトンネルヘッダへプッシュされなければならない実際のＶＬＡＮタグ及び／又はＭＰＬＳラベルを含む。トンネルについてＶＬＡＮが使用されず又はＭＰＬＳラベルスイッチパス（ＬＳＰ）が使用されない場合、これらフィールドは不在になる（対応する長さフィールドはゼロになる）。

１つの実施形態において、ＯｐｅｎＦｌｏｗは、３Ｇ ＰＣベアラ又はＧＴＰトンネルを追加し、削除し、又は修正するための拡張メッセージを追加するように修正される。３Ｇ ＰＣベアラ又はＧＴＰトンネルを追加し、修正し、又は削除するためのＯｐｅｎＦｌｏｗシグナリングは、ersmt_gtp GTPフロー定義を含む１つのＯｐｅｎＦｌｏｗメッセージ、ofp_flow_modメッセージから構成される。ＯｐｅｎＦｌｏｗプロトコルパーサが拡張されたフローをハンドリング可能な限り、標準のＯｐｅｎＦｌｏｗ ofp_flow_modメッセージを使用することができる。フローの修正がカプセル化仮想ポートのＴＥＩＤハッシュテーブルの変更を要する場合、ＯｐｅｎＦｌｏｗコントローラは、ＴＥＩＤハッシュテーブルエントリを含むＧＴＰ ＯｐｅｎＦｌｏｗ拡張メッセージを発行しなければならない。ＯｐｅｎＦｌｏｗコントローラは、双方のメッセージを順番に、まずofp_flow_modメッセージを、そしてＴＥＩＤハッシュテーブル修正メッセージを発行しなければならず、そして、ＯｐｅｎＦｌｏｗコントローラは、ＯｐｅｎＦｌｏｗスイッチによる双方のメッセージの処理を強制するために、OFPT_BARRIER_REQUESTメッセージを発行しなければならない。

ＯｐｅｎＦｌｏｗメッセージの拡張ヘッダ構造ofp_experimenter_headerは、実験者（experimenter）と呼ばれるexperimenter idフィールドを含む。１つの実施形態において、このフィールドは、Ericsson IEEE OUI, 0x01ec又は類似の製造者若しくはプロバイダＯＵＩに設定され得る。構造の残りは、ＧＴＰ拡張メッセージを含む。これらメッセージを、次のメッセージコードによって識別することができる：
enum ermst_gtp_message_code｛
GTP_ADD_TEID_TABLE_ENTRY＝0,
GTP_DEL_TEID_TABLE_ENTRY＝1,
｝;

ＧＴＰ ＯｐｅｎＦｌｏｗ拡張は、ＴＥＩＤハッシュテーブルエントリを追加するための及び削除するためのメッセージを含む。エントリは、まず当該ＴＥＩＤのためのエントリを削除し、そして同じＴＥＩＤのための新たなエントリを追加することにより、修正される。カプセル化仮想ポートのハッシュテーブル内に新たなＴＥＩＤエントリを投入するためのＧＴＰ ＯｐｅｎＦｌｏｗ拡張メッセージは：
struct ermst_teid_table_add｛
ermst_gtp_message_code teid_table_add_type;
uint16_t teid_table_add_teid;
struct ermst_gtp_tuninfo teid_table_add_entry;
｝;

teid_table_add_typeフィールドはGTP_ADD_TEID_TABLE_ENTRYに設定され、teid_table_add_teidフィールドはＴＥＩＤを含み、teid_table_add_entryは追加されるべきテーブルエントリを含む。カプセル化仮想ポートのハッシュテーブルからＴＥＩＤエントリを削除するためのＧＴＰ ＯｐｅｎＦｌｏｗ拡張メッセージは：
struct ermst_teid_table_del｛
ermst_gtp_message_code teid_table_del_type;
uint16_t teid_table_del_teid;
｝;

teid_table_del_typeフィールドはGTP_DEL_TEID_TABLE_ENTRYに設定され、teid_table_del_teidフィールドは削除されるべきエントリについてのＴＥＩＤを含む。

１つの実施形態において、ＧＴＰのためのＯｐｅｎＦｌｏｗの拡張は、ＯｐｅｎＦｌｏｗスイッチの構成をも包含する。３Ｇ ＰＣのクラウドの制御プレーンエンティティから何らかのＧＴＰルーティング更新ＲＰＣを受け取る前に、ＯｐｅｎＦｌｏｗコントローラは、ＧＴＰ拡張型のＯｐｅｎＦｌｏｗゲートウェイスイッチ上にＧＴＰカプセル化及び／又は非カプセル化仮想ポートを構成しなければならない。その構成は、スイッチ固有の構成プロトコルを用いて達成され、上で説明されている。

ＧＴＰ拡張型のＯｐｅｎＦｌｏｗゲートウェイ上の仮想ポートの構成に加えて、ベストエフォートよりも上位のＧＴＰベアラトラフィックを転送することになる何らかのＯｐｅｎＦｌｏｗスイッチ上に、ＱｏＳキューの構成が必要とされ得る。ＯｐｅｎＦｌｏｗプロトコルはキューを構成するためのメッセージを含んでおらず、この構成は、仮想ポートについてもそうであるように、構成プロトコルに委ねられる。何らかのフロールートをインストールする前に、ＯｐｅｎＦｌｏｗコントローラは、ベストエフォートよりも上位のＧＴＰベアラをルーティングすることになるスイッチ内の物理ポート及び／又は仮想ポートと接続するためのキューを構成しなければならない。この構成ステップは、ＧＴＰ拡張型のＯｐｅｎＦｌｏｗスイッチ及び標準のＯｐｅｎＦｌｏｗスイッチの双方について行われなければならない。

１つの実施形態において、ＧＴＰ動作のためのＯｐｅｎＦｌｏｗメッセージフローが修正される。上述したように、ＳＧＳＮ及びＳＳＳＮの３Ｇ ＰＣ制御プレーン部分を含む３Ｇ ＰＣ制御プレーンエンティティは、データセンタにおけるクラウドコンピューティング設備内にある。ＳＧＳＮ及びＧＧＳＮの制御プレーンは、ＧＴＰシグナリングによってルーティング変更がトリガされると、クラウド内のＯｐｅｎＦｌｏｗコントローラとの間で、リモートプロシージャコール（ＲＰＣ）又は類似の仕組みを介して通信する。ＯｐｅｎＦｌｏｗコントローラは、データプレーン上の変更を、ＧＴＰ拡張型のＯｐｅｎＦｌｏｗ対応のデータプレーンゲートウェイ、ＳＧＳＮ及びＧＧＳＮの制御プレーン、並びにここでは“ＧｘＯＦＳ”と呼ばれるＧＴＰルーティングのために拡張されたＯｐｅｎＦｌｏｗスイッチへ、クラウドとゲートウェイ及びスイッチとを接続する制御プレーンネットワーク上のＯｐｅｎＦｌｏｗシグナリングを通じて設定（enact）する。

一般には、ＧＴＰフローのために特別なルーティングの取り扱いが必要とされなければ、ＧｘＯＦＳへはシグナリングは必要とされない。そうした取扱いが必要とされ得るケースは、例えば：事業者の３Ｇ ＰＣがインターネットとの間で１つよりも多くの場所でピアリング点を有し、結果として１つよりも多くのゲートウェイを有していて、最適なゲートウェイへのルーティングが中間スイッチにて３Ｇ ＰＣ内のトラフィックを誘導する（steer）ことを要し得るケース；及び、ＧＴＰフローが事業者のネットワーク内、例えばクラウド内のどこかでアプリケーションによる特殊な取り扱いを受けなければならないケース、である。そうした特殊な取り扱いの一例は、トランスコーディングであえる。中間スイッチは、ユーザプレーンパケットをトランスコーディングアプリケーションへルーティングするためのプログラミングを要し得る。この列挙は網羅的ではなく、中間スイッチ上のＧＴＰルーティングの他の多くの応用が可能である。

ＧＴＰ ＰＤＰコンテキストトンネルは、ＧＴＰ−Ｃ ＰＤＰコンテキスト生成リクエストメッセージを用いてセットアップされることができる。この手続は、例えばＥ−ＵＴＲＡＮ初期アタッチ手続などの、多様なメッセージシーケンスで使用される。

図１８Ａ〜Ｃは、３Ｇ ＰＣにおけるセッションの生成、修正及び削除のフローチャートである。図１８Ａには、セッションを生成するための処理が例示されている。処理は、加入者セッションのためのＳＧＳＮとＧＧＳＮとの間のＧＴＰトンネルを生成するためのリクエストへの応答として開始される（ブロック１８０１）。加入者セッションは、３Ｇ ＰＣ内のユーザ機器を加入者セッションの他のエンドポイントに接続するために開始され、他のエンドポイントは他のユーザ機器、サーバ又は類似のエンドポイントであり得る。ＧＴＰトンネルは、３Ｇ ＰＣネットワークのコアネットワークをまたいでピアリング点、インターネット又は類似のエンドポイントへの加入者セッションのルートを確立する。コントローラは、ＳＧＳＮを実装するスイッチを、加入者セッションのためにデータパケットをカプセル化し及び非カプセル化し、並びに第１のＧＴＰトンネルエンドポイントを確立するように構成する（ブロック１８０３）。また、コントローラは、ＧＴＰトンネルのルート内の各スイッチを、ＧＴＰトンネルのルートに従い、各方向においてパケットを転送するように構成する（ブロック１８０５）。コントローラは、ＧＧＳＮのデータプレーンを、加入者セッションのパケットをカプセル化し及び非カプセル化して、ＧＧＳＮにおいて当該ＧＴＰトンネルの第２のエンドポイントを確立するように構成する（ブロック１８０７）。

図１８Ｂには、セッションを修正するための処理が例示されている。処理は、加入者セッションのためのＳＧＳＮとＧＧＳＮとの間のＧＴＰトンネルを修正するためのリクエストへの応答として開始される（ブロック１８１１）。加入者セッションは、３Ｇ ＰＣ内のユーザ機器を加入者セッションの他のエンドポイントに接続し、他のエンドポイントは他のユーザ機器、サーバ又は類似のエンドポイントであり得る。ＧＴＰトンネルは、３Ｇ ＰＣネットワークのコアネットワークをまたいでピアリング点、インターネット又は類似のエンドポイントへの加入者セッションの、確立済みのルートである。修正処理は、同じエンドポイント又は異なるエンドポイントへの３Ｇ ＰＣネットワークをまたぐ加入者セッションをルート付けし直す（re-route）ために利用され得る。ＧＴＰトンネルのエンドポイントとＧＴＰのパスとの任意の組合せが、本処理を用いて変更可能である。コントローラは、ＳＧＳＮを実装するスイッチの構成を、加入者セッションのためにデータパケットをカプセル化し及び非カプセル化し、並びに第１のＧＴＰトンネルエンドポイントを修正するように、修正する（ブロック１８１３）。また、コントローラは、ＧＴＰトンネルの現在のルート及び新たなルート内の各スイッチを、ＧＴＰトンネルの当該ルートに従って各方向においてパケットを転送するように構成する（ブロック１８１５）。コントローラは、ＧＧＳＮのデータプレーンの構成を、加入者セッションのパケットをカプセル化し及び非カプセル化して、ＧＧＳＮにおいて当該ＧＴＰトンネルの第２のエンドポイントを確立するように、修正する（ブロック１８１７）。

図１８Ｃには、セッションを削除するための処理が例示されている。処理は、加入者セッションのためのＳＧＳＮとＧＧＳＮとの間のＧＴＰトンネルを削除するためのリクエストへの応答として開始される（ブロック１８２１）。加入者セッションは、３Ｇ ＰＣ内のユーザ機器を加入者セッションの他のエンドポイントに接続し、他のエンドポイントは他のユーザ機器、サーバ又は類似のエンドポイントであり得る。ＧＴＰトンネルは、３Ｇ ＰＣネットワークのコアネットワークをまたいでピアリング点、インターネット又は類似のエンドポイントへの加入者セッションの、確立済みのルートである。加入者セッション及び関連付けられるＧＴＰトンネルは、ユーザ機器上の関連付けられるアプリケーション、又は、加入者セッションの他端における他方のユーザ機器上のアプリケーション若しくはサーバアプリケーションが接続を終了させた際に削除される。すると、加入者セッションのリソースは、加入者セッション及びＧＴＰトンネルを削除することにより、再生（reclaim）される。コントローラは、加入者セッションのためにデータパケットをカプセル化し及び非カプセル化してきた、ＳＧＳＮを実装するスイッチにおけるＧＴＰトンネルの構成を除去し、それにより第１のＧＴＰトンネルエンドポイントが除去される（ブロック１８２３）。また、コントローラは、ＧＴＰトンネルのルートに従って各方向においてパケットを転送してきたＧＴＰトンネルのルート内の各スイッチから、ＧＴＰトンネルのための構成を除去する（ブロック１８２５）。コントローラは、加入者セッションのパケットをカプセル化し及び非カプセル化してきた、ＧＧＳＮのデータプレーンから、ＧＴＰトンネルのための構成を除去し、それによりＧＧＳＮにおけるＧＴＰトンネル第２のエンドポイントが除去される（ブロック１８２７）。

図１９に、セッション生成リクエスト手続についてのＯｐｅｎＦｌｏｗメッセージフローの一例が示されている。図示された例において、ＳＳＧＮ制御プレーンコンポーネントは、クラウドコンピューティングシステム内のＧＧＳＮ制御プレーンコンポーネントへセッション生成リクエストを送信し、ＧＧＳＮ制御プレーンコンポーネントは、当該リクエストをＧＴＰルーティング更新ＲＰＣコールを通じてコントローラへ送信する。当該ＲＰＣコールは、ＯｐｅｎＦｌｏｗコントローラがデータプレーン内のＳＧＳＮ及びＧＧＳＮに新たなＧＴＰトンネルエンドポイントを確立し、必要ならば中間スイッチ上に新たなＧＴＰベアラ又はトンネルのためのルートをインストールすること、を要求する。

ＧＴＰルーティング更新ＲＰＣからの結果を制御プレーンＧＧＳＮへ返送する前に、ＯｐｅｎＦｌｏｗコントローラは、適切なデータプレーンゲートウェイエンティティへＯｐｅｎＦｌｏｗメッセージのシーケンスを発行する。例示的な実施形態において、当該シーケンスは、後続のメッセージの処理に影響し得る保留中のメッセージはないことを保証するOFP_BARRIER_REQUESTから開始する。そして、マッチングフィールドとしてのＧＴＰ拡張を伴うofp_match構造とコマンドフィールドとしてのOFPFC_ADDとを含むOFPT_FLOW_MODメッセージが発行される。当該メッセージは、上で説明したように、適切な仮想ポートを通じてパケットをカプセル化し及び逆カプセル化するＧＴＰトンネルのためのフロールートを確立するための、アクション及び指示（instructions）を特定する。加えて、OFPT_FLOW_MODメッセージにすぐ続いて、ＯｐｅｎＦｌｏｗコントローラは、カプセル化仮想ポートのためのＴＥＩＤハッシュテーブルエントリを含むゲートウェイへ、GTP_ADD_TEID_TABLE_ENTRYメッセージを発行する。上で説明したように、当該２つのＯｐｅｎＦｌｏｗメッセージに、ゲートウェイに手続を進める前にフロールート及びＴＥＩＤハッシュテーブルの更新を処理することを強制するためのOFPT_BARRIER_REQUESTメッセージが続く。

ＧＴＰルーティング更新ＲＰＣからの返答の前に、ＯｐｅｎＦｌｏｗコントローラは、カスタマイズされたＧＴＰフロールーティングに関与する必要のあるＧＴＰ拡張型のＯｐｅｎＦｌｏｗスイッチ（ＧｘＯＦＳ）へ、ＧＴＰフロールーティング更新をも発行する。これら更新におけるメッセージは、OFP_BARRIER_REQUESTと、それに続く、マッチングフィールドとしての新たなＧＴＰフローのためのＧＴＰ拡張を伴うofp_match構造とコマンドフィールドとしてのOFPFC_ADDとを含むOFPT_FLOW_MODメッセージと、カスタマイズされたＧＴＰフロールーティングのための上述したアクション及び指示と、からなる。最終的なOFP_BARRIER_REQUESTは、応答の前に変更を処理することをスイッチに強制する。図１９に例示したように、何らかのＧｘＯＦＳ上のフロールートは、データプレーン内のＳＧＳＮ上にＧＴＰトンネルエンドポイントルートをインストールした後、データプレーン内のＧＧＳＮ上にＧＴＰトンネルエンドポイントルートをインストールする前に、インストールされる。ＯｐｅｎＦｌｏｗコントローラは、全てのフロールーティング更新が達成されるまで、制御プレーンＧＧＳＮ ＲＰＣに応答しない。

一度ＲＰＣについて返答がなされると、制御プレーンのＧＧＳＮ及びＳＧＳＮは、ＰＤＰコンテキスト生成レスポンスメッセージを返答する。ＧＴＰベアラの特性は、ＰＤＰコンテキスト更新リクエスト処理を用いて変更される。そうした変更は、例えば、ＩＰパケットに割り当てられたＱｏＳを含み得る。この手続は、例えばＵＥによりトリガされるサービスリクエストといった、多様な３Ｇ ＰＣメッセージシーケンスで使用される。

図２０は、セッション修正リクエスト手続のためのＯｐｅｎＦｌｏｗメッセージシーケンスの１つの実施形態の図である。セッションの生成もそうであるように、３Ｇ ＰＣクラウド制御プレーンＳＧＳＮが、制御プレーンＧＧＳＮへＰＤＰコンテキスト更新リクエストメッセージを発行し、制御プレーンＧＧＳＮが、新たなトンネルの更新情報を含むＧＴＰルーティング更新ＲＰＣをＯｐｅｎＦｌｏｗコントローラへ発行する。そして、ＯｐｅｎＦｌｏｗコントローラは、データプレーンＳＧＳＮ、ＧｘＯＦＳ及びデータプレーンＧＧＳＮへ、ＧＴＰ拡張ＯｐｅｎＦｌｏｗメッセージを発行する。

ＧＴＰルーティング更新ＲＰＣからの結果を制御プレーンＧＧＳＮへ返送する前に、ＯｐｅｎＦｌｏｗコントローラは、適切なデータプレーンゲートウェイエンティティへＯｐｅｎＦｌｏｗメッセージのシーケンスを発行する。当該シーケンスは、後続のメッセージの処理に影響し得る保留中のメッセージはないことを保証するOFP_BARRIER_REQUESTから開始する。そして、マッチングフィールドとしてのＧＴＰ拡張を伴うofp_match構造とコマンドフィールドとしてのOFPFC_MODIFY又はOFPFC_MODIFY_STRICTとを含むOFPT_FLOW_MODメッセージが発行される。必要であれば、当該メッセージは、上で説明したように、適切な仮想ポートを通じてパケットをカプセル化し及び逆カプセル化するＧＴＰトンネルのための新たなフロールートを確立するための、アクション及び指示を特定する。加えて、ＴＥＩＤハッシュテーブルにおいて変更が必要であれば、OFPT_FLOW_MODメッセージにすぐ続いて、ＯｐｅｎＦｌｏｗコントローラは、エントリを削除するためのTP_DEL_TEID_TABLE_ENTRYと、それに続く新たなエントリをインストールするためのTP_ADD_TEID_TABLE_ENTRYメッセージを発行する。上で説明したように、当該２つのＯｐｅｎＦｌｏｗメッセージに、ゲートウェイに手続を進める前にフロールート及びＴＥＩＤハッシュテーブルの更新を処理することを強制するためのOFPT_BARRIER_REQUESTメッセージが続く。

ＧＴＰルーティング更新ＲＰＣからの返答の前に、ＯｐｅｎＦｌｏｗコントローラは、カスタマイズされたＧＴＰフロールーティングに関与する必要のあるＧＴＰ拡張型のＯｐｅｎＦｌｏｗスイッチ（ＧｘＯＦＳ）へ、必要なＧＴＰフロールーティング更新をも発行する。これら更新におけるメッセージは、OFP_BARRIER_REQUESTと、それに続く、マッチングフィールドとしての新たなＧＴＰフローのためのＧＴＰ拡張を伴うofp_match構造とコマンドフィールドとしてのOFPFC_MODIFY又はOFPFC_MODIFY_STRICTとを含むOFPT_FLOW_MODメッセージと、必要ならばカスタマイズされたＧＴＰフロールーティングのための上述したアクション及び指示と、からなる。最終的なOFP_BARRIER_REQUESTは、応答の前に変更を処理することをスイッチに強制する。図２０に例示したように、何らかのＧｘＯＦＳ上のフロールートは、データプレーンＳＧＳＮ上にＧＴＰトンネルエンドポイントルートをインストールした後、データプレーンＧＧＳＮ上にＧＴＰトンネルエンドポイントルートをインストールする前に、インストールされる。ＯｐｅｎＦｌｏｗコントローラは、全てのフロールーティング更新が達成されるまで、制御プレーンＧＧＳＮ ＲＰＣに応答しない。一度ＲＰＣについて返答がなされると、制御プレーンのＧＧＳＮ及びＳＧＳＮは、ＰＤＰコンテキスト更新メッセージを返答する。

ＧＴＰトンネルは、セッション削除リクエスト手続を用いて削除される。この手続は、例えばＵＥによりトリガされるデタッチリクエストといった、多様な３Ｇ ＰＣメッセージシーケンスで使用され得る。図２１は、セッション削除リクエスト手続のためのＯｐｅｎＦｌｏｗメッセージシーケンスの１つの実施形態の図である。セッションの生成及び修正と同様に、３Ｇ ＰＣクラウド制御プレーンＳＧＳＮが、制御プレーンＧＧＳＮへＰＤＰコンテキスト削除リクエストメッセージを発行し、制御プレーンＧＧＳＮが、トンネル削除情報を含むＧＴＰルーティング更新ＲＰＣをＯｐｅｎＦｌｏｗコントローラへ発行する。そして、ＯｐｅｎＦｌｏｗコントローラは、データプレーンＳＧＳＮ、ＧｘＯＦＳ及びデータプレーンＧＧＳＮへ、ＧＴＰ拡張ＯｐｅｎＦｌｏｗメッセージを発行する。

ＧＴＰルーティング更新ＲＰＣのコール相手への返送に先立って、ＯｐｅｎＦｌｏｗシグナリングが遂行される。当該シーケンスは、後続のメッセージの処理に影響し得る保留中のメッセージはないことを保証するOFP_BARRIER_REQUESTから開始する。そして、マッチングフィールドとしてのＧＴＰ拡張を伴うofp_match構造とコマンドフィールドとしてのOFPFC_DELETE又はOFPFC_DELETE_STRICTとを含むOFPT_FLOW_MODメッセージが発行される。加えて、OFPT_FLOW_MODメッセージにすぐ続いて、ＯｐｅｎＦｌｏｗコントローラは、ＴＥＩＤハッシュテーブルエントリを削除するためのGTP_DEL_TEID_TABLE_ENTRYを発行する。上で説明したように、このＯｐｅｎＦｌｏｗメッセージに、ゲートウェイに手続を進める前にフロールート及びＴＥＩＤハッシュテーブルの更新を処理することを強制するためのOFPT_BARRIER_REQUESTメッセージが続く。

ＧＴＰルーティング更新ＲＰＣからの返答の前に、ＯｐｅｎＦｌｏｗコントローラは、カスタマイズされたＧＴＰフロールーティングに関与する必要のあるＧＴＰ拡張型のＯｐｅｎＦｌｏｗスイッチへ、必要なＧＴＰフロールーティング更新をも発行する。これら更新におけるメッセージは、OFP_BARRIER_REQUESTと、それに続く、マッチングフィールドとしての新たなＧＴＰフローのためのＧＴＰ拡張を伴うofp_match構造とコマンドフィールドとしてのOFPFC_DELETE又はOFPFC_DELETE_STRICTとを含むOFPT_FLOW_MODメッセージと、からなる。最終的なOFP_BARRIER_REQUESTは、応答の前に変更を処理することをスイッチに強制する。図２１に例示したように、何らかのＧｘＯＦＳ上のフロールートは、データプレーンＳＧＳＮ上にＧＴＰトンネルエンドポイントルートをインストールした後、データプレーンＧＧＳＮ上にＧＴＰトンネルエンドポイントルートをインストールする前に、インストールされる。ＯｐｅｎＦｌｏｗコントローラは、全てのフロールーティング更新が達成されるまで、コール側エンティティ（calling entity）に応答しない。

［代替的な実装］
１つの実施形態において、３Ｇ ＰＣアーキテクチャは、非クラウドの非仮想化システム内に実装され得る。当該３Ｇ ＰＣアーキテクチャの制御プレーンエンティティは、単一のサーバ上に、又は任意の数のサーバ若しくは類似のコンピューティングデバイス上にわたって分散して、記憶され及び実行され得る。同様に、制御プレーンエンティティは、仮想化無しの標準的なソフトウェアコード及びモジュール又は類似のシステムとして実行可能である。それら制御プレーンエンティティは、ローカルシステムコール若しくはプロシージャコール、リモートプロシージャコール又は類似の仕組みを通じて、互いに通信可能である。さらなる実施形態において、制御プレーンエンティティのサブセットはクラウドコンピューティングシステム内で仮想化又は実行可能であり、一方で制御プレーンエンティティの他のサブセットはサーバ、分散型サーバシステム又は類似のシステム内で実行可能である。制御プレーンエンティティは、ここで説明したようなＯｐｅｎＦｌｏｗプロトコルの使用を通じて、又は以下に説明する他の制御プロトコルを通じて、データプレーンと通信することができる。

ここで説明したクラウドコンピューティングシステムは、説明のために提供されたものであり、限定のためのものではない。当業者は、クラウドコンピューティングシステムとの関連で上述した原理及び特徴を、単一のサーバ又は分散型サーバシステムといった他の構成において実装することもできることを理解するであろう。上述したものと同様の原理及び特徴は、単一のサーバシステム、分散型サーバシステム及び類似のコンピューティング環境において実装可能である。それら原理及び特徴は、クラウドコンピューティングシステム、単一サーバ、分散型サーバシステム及び類似のシステムの任意の組合せにおいて実行される非仮想化制御プレーンエンティティを含む非仮想化環境を用いて実装されることもできる。

他の実施形態において、ここで説明したようなＯｐｅｎＦｌｏｗの代わりに、他の制御プロトコルを利用することができる。ＯｐｅｎＦｌｏｗの使用は、例として提示されており、限定ではない。他の制御プロトコルを、制御プレーンとデータプレーンとの間の通信、及びスプリット３Ｇ ＰＣアーキテクチャのデータプレーンの構成を管理するために利用することもできる。そうしたプロトコルの一例は、ネットワーク内の制御プレーンと転送プレーンとを分離するためのＩＥＴＦ標準プロトコルであるＦＯＲＣＥＳである。ＦＯＲＣＥＳプロトコルの仕様は、ＲＦＣ５８１０に記述されている。ＲＦＣ５８１２は、ＯｐｅｎＦｌｏｗスイッチと等価であるＦＯＲＣＥＳ転送エレメントのアーキテクチャを説明している。ＦＯＲＣＥＳプロトコル自体は、転送エレメントへのルートのプログラミングを直接的にはサポートしておらず、むしろ、ＦＯＲＣＥＳコントローラとＦＯＲＣＥＳ転送エレメントとの間のインタラクションのハンドリングのためのフレームワークである。転送エレメントのアーキテクチャは、ＦＯＲＣＥＳコントローラがＦＯＲＣＥＳ転送エレメントをプログラムすることを正確に可能とするプロトコルをいかに設計すべきかを記述している。ＧＴＰ ＴＥＩＤルーティングのためにコントローラがスイッチをプログラムすることを可能とするための、ＧＴＰ ＯｐｅｎＦｌｏｗ拡張といったＯｐｅｎＦｌｏｗの実施形態に関連して上述した特徴を、ＦＯＲＣＥＳベースのシステムが含むことができることを、当業者は理解するであろう。

ＦＯＲＣＥＳ及びＯｐｅｎＦｌｏｗは、例として提示されており、限定ではない。当業者は、ＦＯＲＣＥＳプロトコル及びＯｐｅｎＦｌｏｗプロトコルに関連して上述した原理及び特徴が他の類似の制御プロトコルにおいても実装可能であることを理解するであろう。

このように、クラウドコンピューティングシステム内に３Ｇ ＰＣを実装するための方法、システム及び装置が説明された。理解されるべきこととして、上の説明は例示であって制限的ではないことが意図される。上の説明を読み理解すれば、当業者には他の多くの実施形態が明らかとなるであろう。従って、本発明の範囲は、添付の特許請求の範囲と共に、当該特許請求の範囲に与えられる均等の全ての範囲を基準として、決定されるべきである。

Claims (14)

1. スプリットアーキテクチャを有する第３世代（３Ｇ）ネットワークのパケットコア（ＰＣ）内にＧＰＲＳ（general packet radio service）トンネルプロトコル（ＧＴＰ）を実装するための方法であって、前記３Ｇネットワークの前記ＰＣの制御プレーンは、クラウドコンピューティングシステム内にあり、前記クラウドコンピューティングシステムは、コントローラを含み、前記コントローラは、複数の制御プレーンモジュールを実行し、前記制御プレーンは、制御プレーンプロトコルを通じて前記ＰＣの前記データプレーンと通信し、前記データプレーンは、前記３Ｇネットワークの複数のネットワークエレメント内に実装され、前記方法は、
   前記コントローラにより、加入者セッションのための前記３Ｇネットワークの前記ＰＣ内のＳＧＳＮ（serving GPRS support node）とＧＧＳＮ（gateway GPRS support node）との間のＧＴＰトンネルを生成するためのリクエストを受信するステップと、
   前記制御プロトコルを介して、前記ＳＧＳＮのデータプレーンを実装するスイッチを、前記加入者セッションのパケットをカプセル化し及び非カプセル化し、並びに第１のＧＴＰトンネルエンドポイントを確立するように構成するステップと、
   前記制御プレーンプロトコルを介して、前記ＧＴＰトンネルのルート内の少なくとも１つのスイッチを、前記ＧＴＰトンネルに従って前記加入者セッションのパケットを転送するように構成するステップと、
   前記制御プレーンプロトコルを介して、前記ＧＧＳＮのデータプレーンを実装するスイッチを、前記加入者セッションの前記パケットをカプセル化し及び非カプセル化し、並びに第２のＧＴＰトンネルエンドポイントを確立するように構成するステップと、
   を含む方法。
2. ＧＴＰトンネルを生成するための前記リクエストを前記コントローラにより受信することは、前記ＳＧＳＮの制御プレーンコンポーネントからＰＤＰ（protocol data packet）コンテキスト生成リクエストを受信するステップ、をさらに含む、請求項１の方法。
3. ＧＴＰトンネルを生成するための前記リクエストを前記コントローラにより受信することは、前記ＧＧＳＮの制御プレーンコンポーネントからＧＴＰルーティング更新リクエストを受信するステップ、をさらに含む、請求項１の方法。
4. 前記コントローラにより、前記加入者セッションのための前記３Ｇネットワークの前記ＰＣ内の前記ＳＧＳＮとＧＧＳＮとの間の前記ＧＴＰトンネルを修正するためのリクエストを受信するステップと、
   前記制御プレーンプロトコルを介して、前記加入者セッションのパケットをカプセル化し及び非カプセル化し、並びに前記第１のＧＴＰトンネルエンドポイントを修正するように、前記ＳＧＳＮの前記データプレーンを実装する前記スイッチの構成を修正するステップと、
   前記制御プレーンプロトコルを介して、前記加入者セッションの前記パケットをカプセル化し及び非カプセル化し、並びに前記第２のＧＴＰトンネルエンドポイントを修正するように、前記ＧＧＳＮの前記データプレーンを実装する前記スイッチの構成を修正するステップと、
   をさらに含む、請求項１の方法。
5. 前記ＧＴＰトンネルに従った前記加入者セッションのパケットの転送を終了させるために、前記制御プレーンプロトコルを介して、前記ＧＴＰトンネルの前記ルート内の前記少なくとも１つのスイッチの構成を除去するステップ、をさらに含む、請求項４の方法。
6. 前記制御プレーンプロトコルを介して、前記ＧＴＰトンネルの新たなルート内のスイッチを、前記ＧＴＰトンネルに従って前記加入者セッションのパケットを転送するように構成するステップ、をさらに含む、請求項５の方法。
7. 前記コントローラにより、前記加入者セッションのための前記３Ｇネットワークの前記ＰＣ内の前記ＳＧＳＮとＧＧＳＮとの間の前記ＧＴＰトンネルを削除するためのリクエストを受信するステップと、
   前記加入者セッションのパケットのカプセル化及び非カプセル化を終了させ、並びに前記第１のＧＴＰトンネルエンドポイントを除去するために、前記制御プレーンプロトコルを介して、前記ＳＧＳＮの前記データプレーンを実装する前記スイッチの構成を除去するステップと、
   前記加入者セッションの前記パケットのカプセル化及び非カプセル化を終了させ、並びに前記第２のＧＴＰトンネルエンドポイントを除去するために、前記制御プレーンプロトコルを介して、前記ＧＧＳＮの前記データプレーンを実装する前記スイッチの構成を除去するステップと、
   をさらに含む、請求項１の方法。
8. スプリットアーキテクチャを有する第３世代（３Ｇ）ネットワークのパケットコア（ＰＣ）内のＧＰＲＳ（general packet radio service）トンネルプロトコル（ＧＴＰ）の実装を管理するためのクラウドコンピューティングシステムであって、前記３Ｇネットワークの前記ＰＣの制御プレーンは、前記クラウドコンピューティングシステム内にあり、前記制御プレーンは、制御プレーンプロトコルを通じて前記ＰＣのデータプレーンと通信し、前記データプレーンは、前記３Ｇネットワークの複数のネットワークエレメント内に実装され、
   前記クラウドコンピューティングシステムは、前記ＰＣの前記データプレーンを実装する前記複数のネットワークエレメントと通信し、及び互いに通信する複数のサーバ、を備え、
   前記複数のサーバは、
   前記ＰＣの前記制御プレーンを実装する複数の制御プレーンモジュールを実行するように構成されるコントローラと、
   前記コントローラへ通信可能に結合され、前記ＰＣの前記複数の制御プレーンモジュールの実行を管理するように構成されるクラウドマネージャと、
   を実行し、
   各制御プレーンモジュールは、前記データプレーンを管理するための制御プレーン機能のセットを提供し、
   前記コントローラは、加入者セッションのための前記３Ｇネットワークの前記ＰＣ内のＳＧＳＮ（serving GPRS support node）とＧＧＳＮ（gateway GPRS support node）との間のＧＴＰトンネルを生成するためのリクエストを受信するように構成され、
   前記コントローラは、前記制御プレーンプロトコルを介して、前記ＳＧＳＮのデータプレーンを実装するスイッチを、前記加入者セッションのパケットをカプセル化し及び非カプセル化し、並びに第１のＧＴＰトンネルエンドポイントを確立するように構成する、ように構成され、
   前記コントローラは、前記制御プレーンプロトコルを介して、前記ＧＴＰトンネルのルート内の少なくとも１つのスイッチを、前記ＧＴＰトンネルに従って前記加入者セッションのパケットを転送するように構成する、ように構成され、
   前記コントローラは、前記制御プレーンプロトコルを介して、前記ＧＧＳＮのデータプレーンを実装するスイッチを、前記加入者セッションの前記パケットをカプセル化し及び非カプセル化し、並びに第２のＧＴＰトンネルエンドポイントを確立するように構成する、ように構成される、
   クラウドコンピューティングシステム。
9. 前記コントローラは、ＧＴＰトンネルを生成するための前記リクエストを、前記ＳＧＳＮの制御プレーンコンポーネントからのＰＤＰ（protocol data packet）コンテキスト生成リクエストとして受信する、請求項８のクラウドコンピューティングシステム。
10. 前記コントローラは、ＧＴＰトンネルを生成するための前記リクエストを、前記ＧＧＳＮの制御プレーンコンポーネントからのＧＴＰルーティング更新リクエストとして受信する、請求項８のクラウドコンピューティングシステム。
11. 前記コントローラは、前記加入者セッションのための前記３Ｇネットワークの前記ＰＣ内の前記ＳＧＳＮとＧＧＳＮとの間の前記ＧＴＰトンネルを修正するためのリクエストを受信する、ように構成され
    前記コントローラは、前記制御プレーンプロトコルを介して、前記加入者セッションのパケットをカプセル化し及び非カプセル化し、並びに前記第１のＧＴＰトンネルエンドポイントを修正するように、前記ＳＧＳＮの前記データプレーンを実装する前記スイッチの構成を修正する、ように構成され
    前記コントローラは、前記制御プレーンプロトコルを介して、前記加入者セッションの前記パケットをカプセル化し及び非カプセル化し、並びに前記第２のＧＴＰトンネルエンドポイントを修正するように、前記ＧＧＳＮの前記データプレーンを実装する前記スイッチの構成を修正する、ように構成される、
    請求項８のクラウドコンピューティングシステム。
12. 前記コントローラは、前記ＧＴＰトンネルに従った前記加入者セッションのパケットの転送を終了させるために、前記制御プレーンプロトコルを介して、前記ＧＴＰトンネルの前記ルート内の前記少なくとも１つのスイッチの構成を除去する、ように構成される、請求項１１のクラウドコンピューティングシステム。
13. 前記コントローラは、前記制御プレーンプロトコルを介して、前記ＧＴＰトンネルの新たなルート内のスイッチを、前記ＧＴＰトンネルに従って前記加入者セッションのパケットを転送するように構成する、ように構成される、請求項１２のクラウドコンピューティングシステム。
14. 前記コントローラは、当該コントローラにより、前記加入者セッションのための前記３Ｇネットワークの前記ＰＣ内の前記ＳＧＳＮとＧＧＳＮとの間の前記ＧＴＰトンネルを削除するためのリクエストを受信する、ように適合され
    前記コントローラは、前記加入者セッションのパケットのカプセル化及び非カプセル化を終了させ、並びに前記第１のＧＴＰトンネルエンドポイントを除去するために、前記制御プレーンプロトコルを介して、前記ＳＧＳＮの前記データプレーンを実装する前記スイッチの構成を除去する、ように構成され、
    前記コントローラは、前記加入者セッションの前記パケットのカプセル化及び非カプセル化を終了させ、並びに前記第２のＧＴＰトンネルエンドポイントを除去するために、前記制御プレーンプロトコルを介して、前記ＧＧＳＮの前記データプレーンを実装する前記スイッチの構成を除去する、ように構成される、
    請求項８のクラウドコンピューティングシステム。
    

Images