JP2017538357A - 仮想化されたリソースのステアリング - Google Patents

Abstract

本発明は、仮想化されたリソースを制御するための、方法、装置、システム、およびコンピュータプログラム製品であって、ネットワークサービスをネットワーク要素で実装するための要求を受信することと、ネットワークサービスのキーパラメータを探索することと、ネットワークサービスによる少なくとも１つの計算リソースを選択することと、ネットワークサービスを満たすために要されるほどの、少なくとも１つのアプリケーションを展開することと、ネットワーク要素を少なくとも１つのアプリケーションと相互接続するための、少なくとも１つのトランスポートリソースを選択することと、アクセス制御コンダクタに、トランスポートアクセスマネージャが、ネットワーク要素のリソースの少なくとも一部への排他的アクセスを有するということを指示することと、トランスポートアクセスマネージャに、トランスポート経路をネットワーク要素で確立するように指示することとを含む、方法、装置、システム、およびコンピュータプログラム製品を対象とする。

Description

本発明は、一般的には、例えば有線およびワイヤレス通信ネットワーク内で適用可能である、仮想化されたリソースのステアリングに関係し、より詳細には、クラウドアプリケーションを相互接続し、クラウド管理システムとの連関でネットワーク機能を提供する目的で、仮想ソフトウェア定義ネットワーキング対応トランスポートネットワーク要素の構成、および、それらの要素へのソフトウェア定義ネットワーキングコントローラの割り当てのための、改善された管理ソリューションを提供するための、方法、装置、システム、およびコンピュータプログラム製品に関係する。

今日では標準である、ウェブ、および、その多数のサービスの興隆によって、基礎的なインフラストラクチャのオペレータが、競争力を得るために、または、市場に遅れないようにするだけのために、それらのオペレータのリソースを効率的に管理することは不可欠になった。このことを達成するための、広く採用されている方法は、仮想化、すなわち、共有される物理ハードウェア上への、異なるアプリケーションおよびサービスの整理統合である。従来の情報技術ＩＴ環境では、これらの物理リソースは、普通は、計算ハードウェアおよびネットワークハードウェアに細分割される。従前からこれらは、２つの別々の人員グループ、サーバアドミニストレータおよびネットワークアドミニストレータにより管理される。結果的に、計算仮想化手法およびネットワーク仮想化手法は、ほとんどの場合、互いから独立して開発されてきた。

クラウドコンピューティング、および、その動的リソース割り振りの増大する流行によって、これらの仮想リソースを、互いに、および、それらのリソースのユーザと接続するネットワークは、この高い程度の自動化に遅れないようにするのに十分柔軟ではなかったということが明らかになった。ネットワークはほとんどの場合、計算インフラストラクチャから独立して管理および開発されたので、自動化の、それらのネットワークのレベルは、はるかに進歩していない状態であった。相当量の人間のインタラクションが、依然として、仮想ネットワークをクラウドコンピューティング利用者に提供するために必要であったということであり、そのことは、展開（ｄｅｐｌｏｙｍｅｎｔ）プロセスをかなり遅らせるものである。この問題に対する一般的な原因として、プロプライエタリデバイスでのハードウェアおよびソフトウェアの緊密な統合により引き起こされる、ネットワーキングでの技術革新の遅いペースが特定されている。この問題点を直すために、ソフトウェア定義ネットワーキングＳＤＮの概念が採用された。主要ＳＤＮ原理は、ネットワークの、制御プレーンおよびデータプレーンの分離、論理的に集中化された制御、オープンインターフェイス、ならびにプログラマビリティである。

一般的には、制御プレーンおよびデータプレーンの分離は、最も重要なＳＤＮ原理とみなされるものであり、なぜならばそれによって、互いから独立して、制御プレーンおよびデータプレーンの開発が可能になるからであり、そのことは、より短い技術革新サイクルにつながるものであり、なぜならばソフトウェア制御プレーンは今や、はるかに速く進化し得るものであり、遅いハードウェア開発サイクルにより制限されないからである。基本的な３層ＳＤＮアーキテクチャが、図１ａで示される。

データプレーンは、パケットデータの実際のフォワーディングを遂行するプログラマブルスイッチからなる。これらは、ハードウェアスイッチ、例えばＨＰ ＰｒｏＣｕｒｖｅ ２９２０、Ｐｉｃａ８ Ｐｒｏｎｔｏ ３２９０、または、Ｏｐｅｎ ｖＳｗｉｔｃｈのようなソフトウェアスイッチであり得る。制御命令は、スイッチに制御プレーンから「サウスバウンドＡＰＩ」によって送信される。このインターフェイスの最も流行している実現形態は、現時ではＯｐｅｎＦｌｏｗプロトコルである。別の例は、ＩＥＴＦ ＦｏｒＣＥＳであることになる。コントローラプレーンは、従来のオペレーティングシステムのようでないということはなく、制御アプリケーションに対するインターフェイス抽象化およびトポロジー検出／追跡などの基本的な低レベル機能性を提供し、それらの制御アプリケーションは、コントローラプレーンと「ノースバウンドＡＰＩ」によって通信する。コントローラプレーンの実装形態は、例えばＯｐｅｎＤａｙＬｉｇｈｔおよびＲｙｕコントローラである。ノースバウンドインターフェイスは、最もよく目にする形では、ＲＥＳＴ原理を使用して実装される。

基本的なアーキテクチャが３層である一方で、実現形態の関係性は、３つのインスタンスだけに制限されない。複数のネットワーク要素が、単一のコントローラにより制御され得るものであり、そのコントローラは、責任の領域によって階層的な、または、機能性によって積層される、複数の等しいノードにわたって分散され得る。加えて、間接参照の複数のレイヤが、フロー空間仮想化およびマルチテナンシを容易にするために導入され得る。実装形態でのこの柔軟性によって、ユーザは、特定の展開シナリオに全体的には適合しないことがあるプロプライエタリソリューションに依拠しなければならないということの代わりに、そのユーザの要件によってネットワークを構築することが可能となる。

ＩＴのほとんどすべての領域でのクラウドコンピューティングの広く行き渡った導入の後は、さらには原理を、ワイドエリアネットワークＷＡＮオプティマイザ、ディープパケットインスペクタ、サービス品質ＱｏＳ／体感品質ＱｏＥモニタ、その他のようなネットワーク機能ＮＦに適用するための論理段階であった。これらのネットワーク機能は、従来からミドルボックスとしてネットワーク内に展開され、そのネットワークはまさに、それらのネットワーク機能が、スケーラブルでなく、要望に応じて展開されないことがあり、非常に高価であるという欠点を有するものである。これらのネットワーク機能をソフトウェアとして、クラウドの内側の仮想マシン上で実現することは、性能および管理に関する複数の難題を提起する。したがって、欧州電気通信標準化機構ＥＴＳＩの作業グループが、そのような機能を展開するための標準化された方策を見出すために創設された。最近ＯｐｅｎＮＦＶが、ネットワーク機能仮想化手法のオープンソース実装形態を提供するためのプロジェクトとして登場した。多くのベンダ、例えばＥｍｂｒａｎｅはすでに、仮想化されたネットワーク機能をそれらのベンダのポートフォリオに有する。

ネットワーク機能仮想化ＮＦＶは、特定の機能に対する特定のハードウェアを含む、今日のネットワークアーキテクチャを、データセンタプラットフォーム（サーバ、スイッチ、およびストレージ）上で作動し得る、ならびに、従前のネットワークノードおよびエンドユーザデバイスとインターワーキングし得るソフトウェアアプリケーションをネットワーク機能が含む、ネットワークアーキテクチャに変換するための、テレコムネットワークオペレータおよびベンダに対する指針を指定するための業界構想である。そのＮＦＶは、ある範囲の業界標準サーバハードウェア上で作動し得る、および、高度に自動化された様式で、要されるほどのネットワーク内の様々な場所で、新しいハードウェア機器の設置に対する必要性なしに、インスタンス化され（および、ことによると、動作の間に再配置され）得る、ソフトウェアでの、ネットワーク機能の実装形態を目論む。ＮＦＶは、仮想化およびクラウドコンピューティングの分野でのＩＴ業界の最近の進歩をもとに成り立つものであり、テレコム業界内のこれらの技術に、テレコムドメインの、特別な要件、および、複雑なユースケースに対処することにより順応することを試行する。

ＥＴＳＩは、どのように、仮想化されたネットワーク機能ＶＮＦのエコシステムが作動すべきかに関する勧告を準備するために、業界仕様グループＩＳＧを設立している。ＮＦＶの主たる目的は、ＶＮＦを、レガシおよび仮想の両方のネットワーク機能ＮＦが共存するハイブリッド環境内で展開されるようにすることである。ＮＦＶの責任は、仮想化されたネットワーク機能が、共通の、ベンダに独立した方策で展開され得る、エコシステムを提供するように制限される。エコシステムは、異なる責任および機能性を伴うブロックに分解される。ブロックが、図２で示される。

仮想ネットワーク機能ＶＮＦは、古典的なＮＦの仮想化されたバージョンである。ＶＮＦマネージャＶＮＦＭは、ＶＮＦのライフサイクル管理（インスタンス化、更新、スケーリング、終結、その他）に対して責任を負う。２つ以上のＶＮＦＭが、エコシステム内で動作し、各々が、１つまたは複数のＶＮＦを管理することがある。仮想化されたインフラストラクチャマネージャＶＩＭは、インフラストラクチャ（例えば、データセンタリソース）の管理に対して責任を負う。そのＶＩＭは、インベントリを維持し、仮想リソースの割り振りおよび解放を管理する。複数の、および特定の（例えば、ネットワーク、ストレージ、ワイドエリアトランスポートリソース）ＶＩＭが、エコシステム内で動作し得る。ネットワーク機能仮想化オーケストレータＮＦＶＯ（これより先、ネットワークオーケストレータと表象される）は、利用可能な、および割り振られるリソース、ならびにそれらの能力の、全体の視点を有する、システムの中心構成要素である。ＮＦＶＯは、リソース取り扱いを制御すること、および、ポリシを適用することに対して責任を負う。

ＥＴＳＩ ＮＦＶアーキテクチャは、ネットワークサービスの展開のためのシステムを、クラウド内の仮想ネットワーク機能として説明する。しかしながら現代のクラウドは、複数の場所でのデータセンタにわたって分散されることが多い。したがって、それらのデータセンタの間のトランスポート相互接続が必要である。加えて、ＳＤＮベースネットワークサービスが、クラウドの外側のデータプレーン構成要素を制御する、クラウド内でホストされる制御プレーンによって展開され得る。このことによって、遂行されることを必要とする、いくつかのタスクが結果として生じる。
・クラウド管理システムと連関して、クラウドベースネットワーク機能の間の接続性を提供するための、トランスポートリソースの構成（例えば、第２のデータセンタ内に在るパケットデータゲートウェイＰ−Ｇｗアプリケーションに接続される、第１のデータセンタ内の仮想化されたホーム加入者サーバＨＳＳアプリケーション）
・仮想トランスポートリソースに対する、トランスポートプレーンでのネットワークサービス要件の構成および強制
・クラウドの外側に在るネットワーク機能による、クラウド内で作動するアプリケーションの構成（例えば、仮想化されたモバイル管理エンティティＭＭＥを、物理ｅノードＢと接続すること）
・データセンタ内で作動するアプリケーションの外のトランスポートリソースのステアリング（例えば、アグリゲーションスイッチの物理リソースを制御して、ＧＰＲＳトンネルプロトコルＧＴＰトンネルハンドリングをＳＤＮによって管理する、ゲートウェイＧｗ制御アプリ）

物理トランスポートリソースの同じプールへの制御アクセスを有する、ネットワーク内のいくつかの仮想化されたエンティティ（例えば、トランスポートＳＤＮコントローラ、アプリケーション）が存する事例では、ネットワークトランスポートリソース利用に関する競合が存することになる。それらのエンティティが互いを認識しない事例（デフォルトの事例）では、前記リソースへの制御アクセスをステアリングする制御インスタンスに対する必要性が存することになる。

イントラクラウド（ｉｎｔｒａ−ｃｌｏｕｄ）接続性を提供し、ＳＤＮデータ経路を展開するための、２つの従来の方策が存する。第１の方策は、ネットワーク要素の、それらの要素の管理インターフェイス、または管理システムを介しての、ネットワークアドミニストレータによる、多かれ少なかれ「手動の」構成である。この手法は、自動化されず、したがって、遅く、柔軟性を欠く。人間のアドミニストレータが、手が空いた状態になり、サービス要件を決定し、次いで、デバイスを構成するのには時間がかかる。これは、今日の「即時の」クラウドアプリケーションまたはネットワーク機能に対して、十分には速くない。さらに、手動の構成は常に、多数のサービス中断につながり得る、ヒューマンエラーのリスクをもつ。

代替案は、ネットワークサービス全体を単一のデータセンタの内側で展開することにより、クラウドの外側のトランスポートネットワーク要素に対する必要性を回避（バイパス）することである。このことによって、すべてのサービス構成要素、および、要される接続性の、自動化された展開に対する、クラウド管理システムの使用が可能となる。この手法の欠点は、ネットワークサービス全体が１つのサイト内で集中化され、そのことによって、レイテンシおよび／または回復性の問題点が結果として生じ得るということである。さらに、データセンタの外側のトランスポートネットワーク要素を、ネットワーク内でＳＤＮベースネットワーク機能を可能にするように構成することは可能でない。

従来技術の弱点を克服するために、本発明は、仮想化されたリソースの改善された制御を有用に提供する。

特に本発明は、クラウドアプリケーションを相互接続し、クラウド管理システムとの連関でネットワーク機能を提供する目的で、仮想ＳＤＮ対応トランスポートネットワーク要素の構成、および、それらの要素へのＳＤＮコントローラの割り当てのための、改善された管理ソリューションを提供するための、方法、装置、システム、およびコンピュータプログラム製品を有用に提供する。

本発明の第１の態様によれば、仮想化されたリソースを制御するためのプロセッサ実装方法であって、ネットワークサービスをネットワーク要素で実装するための要求を受信するステップと、ネットワークサービスのキーパラメータを探索するステップと、ネットワークサービスによる少なくとも１つの計算リソースを選択するステップと、ネットワークサービスを満たすために要されるほどの、少なくとも１つのアプリケーションを展開するステップと、ネットワーク要素を少なくとも１つのアプリケーションと相互接続するための、少なくとも１つのトランスポートリソースを選択するステップと、アクセス制御コンダクタに、トランスポートアクセスマネージャが、ネットワーク要素のリソースの少なくとも一部への排他的アクセスを有するということを命令するステップと、トランスポートアクセスマネージャに、トランスポート経路をネットワーク要素で確立するように命令するステップとを含む、プロセッサ実装方法が提供される。

本発明の第２の態様によれば、仮想化されたリソースを制御するための装置であって、少なくとも１つのプロセッサと、プロセッサにより実行されることになる命令を記憶するための少なくとも１つのメモリとを含み、少なくとも１つのメモリ、および命令は、少なくとも１つのプロセッサによって、装置が少なくとも、ネットワークサービスをネットワーク要素で実装するための要求を受信することと、ネットワークサービスのパラメータを探索することと、ネットワークサービスによる少なくとも１つの計算リソースを選択することと、ネットワークサービスを満たすために要されるほどの、少なくとも１つのアプリケーションを展開することと、ネットワーク要素を少なくとも１つのアプリケーションと相互接続するための、少なくとも１つのトランスポートリソースを選択することと、アクセス制御コンダクタに、トランスポートアクセスマネージャが、ネットワーク要素のリソースの少なくとも一部への排他的アクセスを有するということを命令することと、トランスポートアクセスマネージャに、トランスポート経路をネットワーク要素で確立するように命令することとを遂行することを引き起こすように構成される、装置が提供される。

本発明の第３の態様によれば、仮想化されたリソースを制御するためのシステムであって、計算リソースを含むデータセンタと、ネットワークサービスのパラメータを記憶するデータベースと、ネットワークサービスによる少なくとも１つの計算リソースを選択するように構成されるクラウド管理システムと、ネットワークサービスを満たすために要されるほどの、少なくとも１つのアプリケーションを展開するように構成されるアプリケーション管理システムと、ネットワークサービスにより影響を受けるネットワーク要素へのアクセスを制御するように構成されるアクセス制御コンダクタと、ネットワーク要素を少なくとも１つのアプリケーションと相互接続するための、少なくとも１つのトランスポートリソースを選択し、トランスポート経路をネットワーク要素で確立するように構成されるトランスポートアクセスマネージャと、ネットワークサービスを実装するための要求に基づいて、クラウド管理システム、アプリケーション管理システム、アクセス制御コンダクタ、およびトランスポートアクセスマネージャを制御するように構成されるオーケストレータとを含む、システムが提供される。

本発明の第４の態様によれば、コンピュータに対するコンピュータプログラム製品であって、製品がコンピュータ上で作動されるときに、少なくとも、第１の態様によるステップを遂行するためのソフトウェアコード部分を含む、コンピュータプログラム製品が提供される。

本発明の上述の例の態様の、有利なさらなる発展形態または修正形態が、従属請求項に記されている。

本発明の所定の例の実施形態によれば、ネットワーク機能仮想化オーケストレータ（ｏｒｃｈｅｓｔｒａｔｏｒ）は、ソフトウェア定義ネットワーキングシステムのネットワークオーケストレーション部分である。

さらに、本発明の所定の例の実施形態によれば、アクセス制御コンダクタは、同じネットワーク要素のトランスポートリソースへのアプリケーションまたはコントローラの競合的アクセスを管理するように構成される。

さらに、本発明の所定の例の実施形態によれば、計算リソースは仮想マシンである。

さらに、本発明の所定の例の実施形態によれば、トランスポートアクセスマネージャは、ソフトウェア定義ネットワーキングトランスポートコントローラを含む。

さらに、本発明の所定の例の実施形態によれば、トランスポートアクセスマネージャは、それぞれのネットワーク要素への制御アクセスのアクセシビリティを管理するように構成されるアクセス制御コンダクタをさらに含む。

その上さらに、所定の例の実施形態によれば、要求は、オペレーションサポートシステム（ｏｐｅｒａｔｉｏｎｓ ｓｕｐｐｏｒｔ ｓｙｓｔｅｍ）およびビジネスサポートシステム（ｂｕｓｉｎｅｓｓ ｓｕｐｐｏｒｔ ｓｙｓｔｅｍ）などの高レベルエンティティから受信される。

本発明の例の実施形態の、より完全な理解のために、ここで、付随する図面に関して行う、以下の説明を参照する。

ソフトウェア定義ネットワーキングシステムの基本的なアーキテクチャを概略的に例示する図である。 例の仮想計算リソースを概略的に示す図である。 欧州電気通信標準化機構（ＥＴＳＩ）による仕様による、仮想化されたネットワーク機能のエコシステムを概略的に例示する図である。 ＥＴＳＩ ＮＦＶ準拠システムの例の実施形態が適用されるシステムを概略的に例示する図である。 トランスポートリソースを含むＥＴＳＩ ＮＦＶ準拠システムの所定の例の実施形態による、仮想化されたリソースを制御するための編成を例示する図である。 本発明の所定の例の実施形態による、トランスポートアクセスマネージャの原理を例示する図である。 本発明の所定の例の実施形態による、仮想化されたリソースを制御するための編成を例示する図である。 本発明の所定の例の実施形態による、リソース制御アクセスステアリングの実装形態例を示す図である。 本発明の所定の例の実施形態による、リソース制御アクセスステアリングの実装形態例を示す図である。 図２のＥＴＳＩネットワーク機能仮想化アーキテクチャへの、本発明による所定の例の実施形態のマッピングを概略的に示す図である。 本発明の一部の例の実施形態による方法を概略的に例示する図である。 本発明の一部の例の実施形態による装置を概略的に例示する図である。 本発明の一部の例の実施形態によるシステムを例示する図である。 本発明の所定の例の実施形態による実装形態例を示す図である。 本発明のさらなる所定の例の実施形態による実装形態例を示す図である。

本発明の例の態様を、本明細書の下記で説明する。より具体的には、本発明の例の態様を、本明細書では以降、個別の非制限的な例を、および、本発明の想像可能な例の実施形態であると現在考えられるものを参照して説明する。当業者であれば、本発明は、決してこれらの例に制限されず、より広範に適用され得るということを察知するであろう。

本発明、および、その例の実施形態の、以下の説明は主に、所定の例のネットワーク構成および展開に対する非制限的な例として使用されている仕様を参照するということが留意されるべきである。すなわち、本発明、および、その例の実施形態を主に、例えば、所定の例のネットワーク構成および展開に対する非制限的な例として使用されている、例えば３ＧＰＰに対するネットワーク仮想化の仕様との関係で説明する。したがって、本明細書で与えられる例の実施形態の説明は、具体的には、それらの実施形態に直接関係付けられる専門用語に言及する。そのような専門用語は、提示される非制限的な例の文脈で使用されるのみであり、当然ながら、本発明を決して制限しない。むしろ、任意の他の仮想化およびネットワーク構成またはシステム展開その他が、さらには、本明細書で説明する特徴に準拠する限り利用され得る。

本明細書では以降、本発明の様々な例の実施形態および実装形態、ならびに、その態様または例の実施形態を、いくつかの代替案を使用して説明する。一般的には、所定の必要性および制約によって、説明する代替案のすべては、単独で、または、任意の想像可能な組み合わせ（さらには、様々な代替案の個々の特徴の組み合わせを含む）で提供され得るということが留意される。

特に、以下の例、バージョン、および実施形態は、例示的な例としてのみで理解されるべきものである。本明細書では、「１つの（ａｎ）」、「１つの（ｏｎｅ）」、または「一部の」、例のバージョン、または、例の実施形態に、いくつかの場所で言及することがあるが、このことは、各々のそのような言及が、同じ例のバージョン、もしくは、例の実施形態に対するものであるということ、または、特徴が、単一の例のバージョン、もしくは、例の実施形態に適用されるのみであるということを必ずしも意味しない。異なる例の実施形態の単一の特徴は、さらには、他の例の実施形態を提供するために組み合わされ得る。さらに、「備える」および「含む」という単語は、説明する例の実施形態を、述べられた特徴のみからなるようには制限しないと理解すべきであり、そのような例のバージョン、および、例の実施形態はさらには、具体的には述べられていない、特徴、構造、ユニット、モジュール、その他もまた内包し得る。

すでに上記で指し示したように、本発明は、クラウドアプリケーションを相互接続し、クラウド管理システムとの連関でネットワーク機能を提供する目的で、仮想ＳＤＮ対応トランスポートネットワーク要素の構成、および、それらの要素へのＳＤＮコントローラの割り当てのための、改善された管理ソリューションを提供する。

一般的には（ネットワーク）オペレータは、種々の計算仮想化技法および概念から選定して、それらのオペレータの作業負荷を、それらのオペレータの特定のユースケースおよび事情によって管理し得る。手法の間の主要な差は、仮想リソースの間の隔離、および、基礎的な物理ハードウェアへのアクセスのレベルにある。

図１ｂで例示されるような、完全仮想化の事例では、オペレーティングシステムは、それが仮想環境内で作動されるという事実に気付かず、すなわち、そのオペレーティングシステムは、物理ハードウェア上での動作に対して無修正である。これは、ＶＭｗａｒｅ ＥＳＸｉ、ＫＶＭ、またはＭｉｃｒｏｓｏｆｔ Ｈｙｐｅｒ−Ｖなどの、大多数のハイパーバイザによりサポートされる、仮想化の最もよく目にする形の形式である。仮想化の用意が整ったハードウェア、例えばＩｎｔｅｌ ＶＴ−ｘとの連関で、この手法は、最良の性能隔離を見せる。しかしながら、その手法はさらには、相当量の仮想化オーバヘッドを引き起こす。低減されたオーバヘッドを伴う変形例が、準仮想化である。ここでは、ゲストオペレーティングシステムは、ハイパーバイザに対する特別なＡＰＩコールをサポートするように修正されなければならず、すなわち、そのゲストオペレーティングシステムは、仮想化を認識した状態にされなければならない。Ｘｅｎは、動作のこのモードに対して最もよく知られているものであるが、そのモードはさらには、他のハイパーバイザで見出され得る。最も少ない量のオーバヘッドを伴う手法が、コンテナ仮想化である。ここでは、オペレーティングシステム全体が仮想化されるのではなく、むしろアプリケーションは、同じオペレーティングシステムの上部上の隔離された環境（コンテナ）内で作動される。この変形例の最も流行している代表が、Ｄｏｃｋｅｒにより提供される展開ツールによって採用の相当量の増進を得ている、Ｌｉｎｕｘ（登録商標）カーネルコンテナである。

計算作業負荷の分離の代わりに、ネットワーク仮想化は、同じ物理基板上のネットワークの分離に、性能およびセキュリティの観点から取り組む。今日ではこのことは、ほとんどの場合、仮想ローカルエリアネットワークＶＬＡＮまたはマルチプロトコルラベルスイッチングＭＰＬＳのようなタギング概念、および、仮想拡張可能ＬＡＮ ＶＸＬＡＮ、または、汎用ルーティングカプセル化を使用するネットワーク仮想化（Ｎｅｔｗｏｒｋ Ｖｉｒｔｕａｌｉｚａｔｉｏｎ ｕｓｉｎｇ Ｇｅｎｅｒｉｃ Ｒｏｕｔｉｎｇ Ｅｎｃａｐｓｕｌａｔｉｏｎ）ＮＶＧＲＥのようなトンネリング手法によって達成される。ネットワーク仮想化が、どのように中間リンク上のデータが解釈またはスケジューリングされるかに取り組む一方で、これらの戦略の強制が、ネットワークノードで行われる。計算仮想化技法を使用して、ネットワークノードそれら自体が、さらには仮想化され得る。しかしながらデータセンタでは、仮想ネットワークノードは、よく目にする形では、物理ホストの上部上のハイパーバイザと直接統合される。これらの仮想スイッチ、例えばＣｉｓｃｏ Ｎｅｘｕｓ １０００Ｖは、パケットをカプセル化する、または、それらのパケットにタグを割り当てることにより、仮想オーバレイネットワーク内へのエントリポイントとしてサービングすることが多い。ネットワークの仮想化は、ハードウェア前処理、例えば、異なる仮想ネットワークからのパケットを、個々の処理パイプラインまたはキューに割り当てることによりサポートされ得る。

仮想化が、作業負荷を整理統合するための強力なツールである一方で、相当量のコスト低減は、物理リソース、および、それらの物理リソース上での作業負荷の分散が、自動化された方式で効率的および理想的に管理され得る場合に、達成されるのみであり得る。この目標は、データセンタ内の、および他のところでの、ハードウェアリソースの共同管理のための包括的なシステムの導入によって達成されている。今日ではこれらの管理システムは、それらのシステムの物理リソースとともに、「クラウド」という用語のもとに、よく目にする形で要約されている。

クラウドシステムは、普通は、以下の基本的な構成要素、すなわち、管理システム、計算ノード、およびストレージシステムを含む。

計算ノードは、作業負荷を処理するために使用されるコンピューティングデバイスであり、例えばそれらの計算ノードは、仮想マシンの形式で作業負荷をホストする、ハイパーバイザを作動させるｘ８６サーバであり得る。ストレージシステムは、仮想マシンの仮想ドライブを収容するための異なるタイプのディスク空間、および、新しいＶＭの創出のためのテンプレートを提供する。管理システムは、新しい仮想マシンを計算ノード上に、アプリケーション要件によって、利用可能なテンプレートおよびストレージ空間を使用して創出することにより、クラウドを制御する。さらにその管理システムは、作業負荷を物理ホストの間で移動させて、リソース利用を増大し、エネルギー消費を低減し得る。そのような管理システムに対する例は、ＶＭｗａｒｅ ｖＣｌｏｕｄおよびＭｉｃｒｏｓｏｆｔ Ｓｙｓｔｅｍ Ｃｅｎｔｅｒのような商用のソリューション、または、ＯｐｅｎＳｔａｃｋおよびＯｐｅｎＮｅｂｕｌａのようなオープンソースプロジェクトである。

クラウド管理システム単独によるアプリケーションの迅速な自動化された展開のために、大きな数の仮想マシンテンプレートが、オペレーティングシステムおよびアプリケーションソフトウェアの最も基本的な組み合わせさえもカバーするために必要であることになる。したがって、クラウド管理システムは、仮想マシンを標準オペレーティングシステムイメージによってインスタンス化するのみであるということが標準となった。アプリケーションは次いで、これらの仮想マシン内に、構成システムを使用して、自動的にインストールされる。クラウド管理システムおよび構成システム、例えば、ＯｐｅｎＳｔａｃｋ Ｈｅａｔ、および、ＣｈｅｆまたはＰｕｐｐｅｔは、理想的には互いと統合される。

したがって本発明は、ＥＴＳＩ ＮＦＶフレームワークと調和してこれらのタスクの実行を容易にする、トランスポートアプリケーションマネージャＴＡＭを含む。

特に本発明は、アプリケーションが、利用可能なプールの外のトランスポートリソースをステアリング／制御することを可能とする機構を提供する。これらの機構はさらには、すべての仮想化されたリソース（計算、トランスポート、無線、…）が（ＥＴＳＩ ＮＦＶにより対処されるなど）１つまたは多数のオーケストレーションエンティティにより管理される環境に適用可能である。さらに本発明は、トランスポートネットワークオーケストレーションとアプリケーションとの間の、前記リソースへの制御アクセスの管理を可能とする、追加的な機能を提供する。

本文書の全体を通して使用される「オーケストレータ」という用語は、説明するシステムのネットワークオーケストレーション部分を対象としており、したがって、「ネットワークオーケストレータ」と同義的に使用される。

図３は、本発明によって拡張されることになるシステムを例示する。この編成では、仮想化された計算リソース（図３の左のデータセンタおよび仮想マシンにより表される）は、例えばモバイルネットワークに対する、電気通信システムのネットワークサービスを構成するために、多数のステアリング要素により制御される。そのようなシステムではネットワークサービスは、特定のサービスを可能にするために相互接続されるアプリケーションの配置構成（最もよく目にする形では、サービスグラフと表象される）を含む。そのようなサービスグラフは例えば、モビリティ管理エンティティおよびゲートウェイに接続されることになる、いくつかの無線基地局を含み得る。そのようなサービスグラフの実装形態は、処理リソース、および、それらのリソースを利用するアプリケーション（例えば、モビリティ管理エンティティＭＭＥ）、および、前記アプリケーション（それらは例えば、データセンタ内で作動し得る）へのトポロジー的点（ｔｏｐｏｌｏｇｉｃａｌ ｐｏｉｎｔ）（無線基地局）の対応する相互接続を要することになる。

これらのサービスグラフは、データベース（図３でのネットワークサービスデータベースを参照）内に記憶され、それらのデータベースは、本明細書ではオーケストレータと表象される主ネットワークサービス管理システムによりアクセス可能である。

典型的には、そのようなネットワークサービス（またはサービスグラフ、それぞれ）の実装形態は、オペレーションサポートシステムＯＳＳまたはビジネスサポートシステムＢＳＳからの要望に起因して呼び出される。例えば、新しい基地局がロールアウトされ、仮想化されたネットワークにアタッチされることを必要とするならば、または、新しいサービスがロールアウトされることになるならば、オーケストレータは、高レベルコマンドにより、ネットワークサービスを、所与のトポロジー的および／またはＱｏＳ制約（例えば、５００００人のユーザに対するネットワークサービス番号１２３、トポロジー的領域Ａをアプリケーションと１０Ｇビット／秒で相互接続する）によって実装するように命令され得る。

１つの実装形態ではオーケストレータは、相応のサービスグラフを、そのオーケストレータのネットワークサービスデータベース内で探索し、相応のアクションを行い得るものであり、そのことによって、ＯＳＳ／ＢＳＳのようなより高いレイヤの管理システムは、それらのシステムが、リソース、アプリケーション等々に関するナレッジを有することの必要性なしに、単純な抽象的なコマンドを使用することが可能となる。

一般的には、クラウド管理システム、アプリケーション管理システム、および、本発明の一部の例の実施形態によれば、例えばＳＤＮコントローラ（図４で示される）のような追加的なエンティティを典型的には含む、管理機能のセットによりサポートされるオーケストレータ。

クラウド管理システムによって、仮想マシンのような仮想計算リソースのインスタンス化、および、それらのリソースの上部上で作動し得るアプリケーションの間の相互接続が可能になる。普通は、データセンタは、オープンソース（ＯｐｅｎＳｔａｃｋのような）、商用（ＶＭｗａｒｅ ｖＣｌｏｕｄ）、または、テーラリングされた、ベンダ固有の、いずれかのソリューションである、「クラウドミドルウェア」により管理される、民生用の（ｃｏｍｍｅｒｃｉａｌ−ｏｆｆ−ｔｈｅ ｓｈｅｌｆ）サーバおよびスイッチを使用して構築される。使用されるクラウドプラットフォーム（ＯｐｅｎＳｔａｃｋ、ＶＭｗａｒｅ ｖＣｌｏｕｄ）に依存して、クラウドアプリケーションインフラストラクチャ管理概念は、用いられるクラウドプラットフォームの細部を反映して（ＯｐｅｎＳｔａｃｋ Ｈｅａｔ、または、ＶＭｗａｒｅ ｖＡｐｐのように）異なる。

オーケストレータは、クラウド管理システムを使用して、仮想計算リソースを予約、管理、および監視し、ただしさらには、相互接続パラメータ（内部／外のＩＰアドレスのような）を導出し得る。このクラウド管理システムは、ある程度、ＥＴＳＩ ＮＦＶ ＭＡＮＯでの仮想インフラストラクチャマネージャＶＩＭを反映する。

さらにオーケストレータは、アプリケーション管理システム（ＥＴＳＩ ＮＦＶ ＭＡＮＯでの、ＶＮＦ、仮想ネットワーク機能マネージャ）を利用して、アプリケーションを仮想マシン上で展開し、それらを相互接続し得る。一部の実装形態ではオーケストレータが、リソース予約を行うことになり、他の実装形態ではアプリケーションマネージャが、このことをオーケストレータのために行うことになる。

そのような編成によって、アプリケーションは、要望に応じて、動的に呼び出され／シャットダウンされ、監視され得る。これらのアプリケーションは、互いに通信し得るものであり、さらには、データセンタの外側のノードを、例えばＩＰアドレスを使用することによりアドレス指定し得る。

そのようなシステムに対する第１の有益な拡張は、さらには、トランスポートリソースを、ネットワークサービスを実装するときに考慮され得る仮想リソースとしてアクセス可能にすることであることになる。

図４は、さらにはトランスポートリソースが管理され得る編成を例示する。この編成では、仮想化されたトランスポートリソース（下部でのＳＤＮデータフォワーディングネットワーク要素ＮＥにより表される）は、トランスポートアクセスマネージャＴＡＭ制御エンティティにアクセス可能にされ、そのＴＡＭ制御エンティティの主構成要素は、トランスポートＳＤＮコントローラ（図４での中央部右）である。

このＴＡＭエンティティによって、オーケストレータは、高レベルの抽象的なコマンドを使用して、データセンタの外側のエンティティとの接続性を確立することが可能となることになり、一方で、使用されるトランスポートリソースは、サードパーティオペレータ／トランスポートネットワークプロバイダと共有され得る。例えばトランスポートネットワークが、レイヤ２ＳＤＮスイッチ上で構築されるならば、所定のオペレータに対してアクセス可能であるリソースは、このオペレータが利用し得るトランスポートリソースのプールを形成する。

図５は、ＴＡＭの原理を例示する。オーケストレータは、抽象的なコマンド（例えば、「トポロジー的点Ａとトポロジー的点Ｂとの間の１０Ｇビット／秒の接続性を提供する」）を発行し得る。この抽象的なコマンドは、ノースバウンドインターフェイスハンドラで分析されることになり、例えば、経路計算要素ＰＣＥを用いることにより、トラフィックエンジニアリングデータベースＴＥＤに問い合わせることを結果として生じさせ得る。このことの結果としてＴＡＭは、どのＮＥが、ＡとＢとの間の接続（ａｃｏｎｎｅｃｔｉｏｎ）の一部として影響を受けることになるかのナレッジを有することになる。引き続いてＳＤＮコントローラが、ＡとＢとの間の１０Ｇビット／秒の接続を、ＳＤＮ制御プロトコル（ＯｐｅｎＦｌｏｗまたはＦｏｒＣＥＳなど）を使用して設置するように命令されることになる。

図４の例では、データセンタ内で作動しているアプリケーションは、さらにはＳＤＮベース仮想トランスポートネットワークに接続されるホストと通信することになる。典型的な例は、データセンタクラウド内で作動するＭＭＥインスタンスと通信するｅノードＢ（物理ハードウェア）であり得る。

そのため、ネットワークサービスを実装するとき、オーケストレータは、クラウド管理システムを使用して、計算リソースを予約（およびクラウド相互接続）し、アプリケーション管理システムを使用して、アプリケーションを呼び出し、ＴＡＭ／ＳＤＮコントローラを使用して、インクラウド（ｉｎ−ｃｌｏｕｄ）アプリケーションを、適切なトランスポートリソースを柔軟に割り当てることにより、クラウドの外側のホストと接続し得る。

このシステムの別の有益な拡張は、アプリケーションが、さらには、仮想トランスポートリソースをステアリングすることを可能とすることであることになる。そのようなユースケースに対する典型的な例は、ゲートウェイ、ブロードバンドリモートアクセスサーバＢＲＡＳのような固定ゲートウェイ、ならびに、サービングゲートウェイＳ−ＧｗおよびパケットデータゲートウェイＰ−Ｇｗのようなモバイルゲートウェイである。それらのノードは、ユーザデータＵプレーンが、シグナリングプレーンＣプレーンと密接に統合されるという共通性を有する。したがって、これらがデータセンタ内のアプリケーションとして作動される事例では、すべてのユーザデータ（例えば、ＨＤビデオ）はさらには、データセンタ内へ方向付けされなければならず、そのことは、Ｕプレーンをハンドリングするためだけに多量のリソースを消費し得る。しかしながら、シグナリングプレーンとデータプレーンとの間の密接なインターワーキングは、制御プレーンをデータセンタ内で作動させる状態で、Ｕプレーンを標準データフォワーディングノード（ルータおよびスイッチなど）内で作動させるのみであること（そのことが、最も好ましいソリューションであることになる）を可能とはせず、なぜならば、例えば（モバイルゲートウェイに対する）ＧＴＰトンネルハンドリングは、スイッチまたはルータで利用可能でないからである。しかしながら、アプリケーション（Ｓ−Ｇｗ制御プレーンなど）は、ＳＤＮコントローラを使用して、ＳＤＮ ＮＥのデータフォワーディングプレーンに、フローテーブルを相応に構成することにより、パケットヘッダをパケットごとに操作するように命令し得る。そのような編成によって、データセンタ内で作動するＣプレーン、および、トランスポートレイヤでハンドリングされるＵプレーンに関する、Ｕ／Ｃプレーン分離が可能である。

しかしながら、アプリケーションが、（例えば、上記で説明したようなゲートウェイ分解の事例で）トランスポートリソースの使用をステアリング／構成するために使用される場合、同じリソースへの制御アクセスを有する、ネットワーク内のいくつかのエンティティが存し、そのことは、不整合性につながることになる。

図６では、ビルトインＳＤＮコントローラを伴うアプリケーション「アプリ」が、ＳＤＮデータフォワーディング要素ＮＥ（両方とも灰色に色付けされている）をステアリングしている編成が存する。加えて、ＮＥ（やはり灰色のもの）を制御して、（図４で示されるように）クラウド内のアプリケーションをクラウドの外側のホストと相互接続するために使用される、トランスポートＳＤＮコントローラが存する。この事例では、両方のＳＤＮコントローラが、（灰色の）ＳＤＮ ＮＥでのリソース取り扱いを構成する必要性を有し得る。コンフリクト（例えば、リソースの二重の取り扱い）を避けるために、同じＮＥへの様々な（ＳＤＮ）制御エンティティの制御アクセスのアクセシビリティを管理することになる、追加的な機能「アクセス制御コンダクタ」が存することになる。

図７および８は、そのようなリソース制御アクセスステアリングの、２つの異なる実装形態例を示す。図７では、アプリケーションおよびトランスポートＳＤＮコントローラが、同じＮＥにアクセスして、リソース取り扱いを構成することになる。ここではアクセス制御コンダクタＡＣＣが、コントローラプロキシとして実現され、そのプロキシは、それが適切と考えるリソースのみを、ステアリング構成要素（ＳＤＮコントローラ）に可視であるようにすることになる。例えばＮＥが、８つの物理ポート（ポート０…７と表象される）を有することになるならば、ＡＣＣは、Ａｐｐ−ＳＤＮ−Ｃｔｒｌに対してはポート０…３、および、トランスポートＳＤＮコントローラに対してはポート４…７の修正を可能とするのみであることになる、コントローラプロキシとして働き得る。このようにしてＮＥは、両方のコントローラに対して４ポートスイッチとして見える。一部の実装形態では、ＡＣＣおよびＮＥを並置することが有益であり得るものであり、他の実装形態ではＡＣＣは、トランスポートアクセスマネージャＴＡＭ（図４および５を確認されたい）の一部である。

図８は、ＡＣＣがＮＥを構成する実装形態を示す。ＮＥでハンドリングするリソースを構成することを必要とする２つのコントローラインスタンスが存する事例では、ＡＣＣは、例えば、２つの異なるフローテーブルへのアクセスを提供することにより、ＮＥでの２つの仮想スイッチをインスタンス化し得る（一方はＡｐｐ−ＳＤＮ Ｃｔｒｌにより、他方はＴＲＡ−ＳＤＮ−Ｃｔｒｌにより指揮される）。各々のフローテーブルは、ポート０〜３またはポート９上のリソースをステアリングすることを可能とするのみであることになる。図８はさらには、任意選択の「アタッチ」機構を示す。それらの機構は、ＳＤＮコントローラが、利用可能なリソースに関して、それらのコントローラにアクティブにアタッチするＮＥにより通知されるシナリオで使用され得る。構成プロトコルに対する可能な選択肢は、例えば、ＯＦ Ｃｏｎｆｉｇ、または、簡易ネットワーク管理プロトコルＳＮＭＰである。

図９は、本発明の一部の例の実施形態による、ＥＴＳＩ ＮＦＶアーキテクチャへの上記の原理のマッピングを示す。

ＮＦＶオーケストレータは、ネットワークサービスを実装するための、ＯＳＳ／ＢＳＳ（または、任意の他の高レベルエンティティ）からの命令を受信することになる。それらのサービスは、ここではクラウドアプリケーションマネージャＣＡＭと表象される、ＶＮＦマネージャによって展開されるアプリケーションを含む。それらのサービスはさらには、（データセンタの内側および外側の）アプリケーションと、データセンタの外側の物理ノード（ホスト）との間の相互接続を含む。これらのアプリケーションは、クラウド管理システム（ＣＭＳ）により提供される仮想リソースを使用する。これらのアプリケーションが、仮想トランスポートリソースによって、データセンタの外側の他のアプリケーション（ホスト）と接続されることになっているならば、オーケストレータは、ＴＡＭに、この相互接続をトランスポートＳＤＮコントローラによって管理するように命令し得る。ＴＡＭはしたがって、ＶＮＦマネージャと同じ機能レベルで配置される、仮想トランスポートマネージャ（ＶＴＦマネージャ）と考えられ得る。さらに図９は、仮想ネットワーク機能ＶＮＦとして作動している、Ｓ−Ｇｗ制御プレーンアプリケーションを表すアプリケーションＳＧｗ−Ｃを示す。このアプリケーションは、ＳＤＮ−ＮＥでのＧＴＰ Ｕプレーンハンドリングに対するＳＤＮフォワーディングリソースのステアリングをハンドリングするＳＤＮ−Ｃｔｒｌを内包する、または、そのＳＤＮ−Ｃｔｒｌへのアクセス有する。物理トランスポートリソース（ＮＥ）の同じプールへのＳＤＮ制御アクセスを有する、システム内の２つのエンティティ（ＳＧｗ−Ｃ、および、トランスポートＳＤＮコントローラ）が存するので、ＴＡＭは、（論理的には、クラウド管理システムと同じレベル上の）トランスポート管理システムＴＭＳに命令することになる。このＴＭＳは、上記で説明したような、トランスポートＳＤＮコントローラおよびＡＣＣを含む。ＮＦＶアーキテクチャに対して新しいすべてのエンティティは、灰色に陰影を付けられている。

この例ではＴＭＳは、ＣＭＳと同じアドミニストレーティブレベル上に在る。ＣＭＳが、仮想クラウドリソースを構成することになる一方で、ＴＭＳは、仮想トランスポートリソースを構成することになる。結果的にＴＡＭは、ＣＡＭと同じアドミニストレーティブレベル上にあると考えられる。ＣＡＭは、「仮想ネットワーク機能」マネージャとして働き、ＴＡＭは、「仮想ネットワークトランスポート」マネージャとして働くことになる。この方針にしたがって、無線アクセスまたは光学リソースのような、将来の新しいタイプの仮想リソースは、この原理にしたがい得る。

図１０は、プロセッサ実装方法として、ネットワーク機能仮想化オーケストレータにより、非制限的な例として遂行され得る、本開示の一部の例の実施形態による方法を示す。

Ｓ１１で、ネットワークサービスをネットワーク要素で実装するための要求が受信される。

次いでＳ１２で、ネットワークサービスのキーパラメータが探索される。

さらにＳ１３で、ネットワークサービスによる少なくとも１つの計算リソースが選択される。

その上さらにＳ１４で、ネットワークサービスを満たすために要されるほどの、少なくとも１つのアプリケーションが展開される。

さらにＳ１５で、ネットワーク要素を少なくとも１つのアプリケーションと相互接続するための、少なくとも１つのトランスポートリソースが選択される。

次いでＳ１６で、アクセス制御コンダクタは、トランスポートアクセスマネージャが、ネットワーク要素のリソースの少なくとも一部への排他的アクセスを有するということを指示される。

最後にＳ１７で、トランスポートアクセスマネージャは、トランスポート経路をネットワーク要素で確立するように指示される。

図１１で、仮想化されたリソースの制御を、本開示の例の実施形態の一部に関して説明したように実装するように構成される、本開示の一部の例の実施形態による制御要素に含まれる要素の構成を例示する線図が示される。例の実施形態は、制御要素内で、または、制御要素により履行され得る。制御要素は、制御要素の一部である、または、別々の要素として制御要素、仮想マシン、もしくは類するものにアタッチされることもある、チップセット、チップ、モジュール、その他などの、要素または機能を備え得るということが留意されるべきである。各々のブロック、および、それらの任意の組み合わせは、ハードウェア、ソフトウェア、ファームウェア、１つもしくは複数のプロセッサ、および／または回路などの、様々な手段、または、それらの組み合わせにより実装され得るということが理解されるべきである。

図１１で示される制御要素２０は、制御要素制御手順に関係付けられる、プログラムまたは類するものにより与えられる指示を実行することに適している、ＣＰＵまたは類するものなどの、処理機能、制御ユニット、またはプロセッサ２１を備え得る。

プロセッサ２１は、仮想化されたリソースの、上記で説明した制御に関係付けられる処理を実行するように構成される。特にプロセッサ２１は、ネットワークサービスをネットワーク要素で実装するための要求を受信するように構成される受信ユニットとしての下位部分２１０を備える。部分２１０は、図１０のＳ１１による処理を遂行するように構成され得る。さらにプロセッサ２１は、ネットワークサービスのパラメータを探索するように構成される探索ユニットとして使用可能な下位部分２１１を備える。部分２１１は、図１０のＳ１２による処理を遂行するように構成され得る。さらにプロセッサ２１は、ネットワークサービスによる少なくとも１つの計算リソースを選択するように構成される第１の選択ユニットとして使用可能な下位部分２１２を備える。部分２１２は、図１０のＳ１３による処理を遂行するように構成され得る。その上さらにプロセッサ２１は、ネットワーク要素を相互接続するための、少なくとも１つのトランスポートリソースを選択するように構成される第２の選択ユニットとして使用可能な下位部分２１３を備える。部分２１３は、図１０のＳ１４による処理を遂行するように構成され得る。さらにプロセッサ２１は、ネットワークサービスを満たすために要されるほどの、少なくとも１つのアプリケーションを展開することに対して構成される展開ユニットとして使用可能な下位部分２１４を備える。部分２１４は、図１０のＳ１５による処理を遂行するように構成され得る。その上さらにプロセッサ２１は、アクセス制御コンダクタに、トランスポートアクセスマネージャが、ネットワーク要素のリソースの少なくとも一部への排他的アクセスを有するということを指示するように構成される第１の指示ユニットとして使用可能な下位部分２１５を備える。部分２１５は、図１０のＳ１６による処理を遂行するように構成され得る。さらにプロセッサ２１は、トランスポートアクセスマネージャに、トランスポート経路をネットワーク要素で確立するように指示するように構成される第２の指示ユニットとして使用可能な下位部分２１６を備える。部分２１６は、図１０のＳ１７による処理を遂行するように構成され得る。

参照符号２２および２３は、プロセッサ２１に接続される、送受信器または入出力（Ｉ／Ｏ）ユニット（インターフェイス）を表象する。Ｉ／Ｏユニット２２は、例えばリソースおよび／またはネットワーク要素と通信することに対して使用され得る。Ｉ／Ｏユニット２３は、例えば管理アプリケーションと通信することに対して使用され得る。参照符号２４は、例えば、プロセッサ２１により実行されることになるデータおよびプログラムを記憶することに対して、ならびに／または、プロセッサ２１の作業記憶域として、使用可能なメモリを表象する。

図１２は、本発明の一部の例の実施形態による、仮想化されたリソースを制御するためのシステムを概略的に例示する。

システム３０は、計算リソース３２を備えるデータセンタ３１と、ネットワークサービスのパラメータを記憶するデータベース３３と、ネットワークサービスによる少なくとも１つの計算リソースを選択するように構成されるクラウド管理システム３４と、ネットワークサービスを満たすために要されるほどの、少なくとも１つのアプリケーションを展開するように構成されるアプリケーション管理システム３５と、ネットワークサービスにより影響を受けるネットワーク要素へのアクセスを制御するように構成されるアクセス制御コンダクタ３６と、トランスポート経路をネットワーク要素で確立するように構成されるトランスポートアクセスマネージャ３７と、ネットワークサービスを実装するための要求に基づいて、クラウド管理システム３４、アプリケーション管理システム３５、アクセス制御コンダクタ３６、およびトランスポートアクセスマネージャ３７を制御するように構成されるオーケストレータ３８とを備える。

図１３は、上記で説明した原理に対する実装形態例を示す。その図１３は、ネットワークサービス記述子のカタログがネットワークサービスデータベース内に記憶されるシステムを示す。例として、１つまたはいくつかのｅノードＢであって、それらの間の１０Ｇビット／秒での相互接続を伴うものに対する無線リソース管理を含む、ネットワークサービス１９２が示される。

１で、ＯＳＳ／ＢＳＳは、このネットワークサービスをトポロジー的点Ａ（このｅノードＢの、場所またはネットワーク埋め込みを指定する）に対して実装するための要求を実行依頼する。２で、オーケストレータは、このネットワークサービスのキーパラメータを探索し、相応にアクションを行うことになる。３で、オーケストレータは、適した計算リソース（ＶＭ）をクラウド管理システムによって選択することになり、４で、そのオーケストレータは、アプリケーション管理システムに、ネットワークサービスを満たすために要されるほどの、多くの無線リソース管理ＲＲＭアプリケーション（例では、１つのＲＲＭアプリ）を展開するように指示することになる。

ｅノードＢはデータセンタの外側に在るので、ＲＲＭアプリとｅノードＢとの間の相互接続は、ＳＤＮトランスポートリソースの使用を要する。これらの構成は５ａで起こり、オーケストレータは、アクセス制御コンダクタに、ＳＤＮトランスポートコントローラが、ｅノードＢが接続されるＮＥへの排他的アクセスを有するということを指示する。さらにそのオーケストレータは、トランスポートＳＤＮコントローラに、影響を受けるＮＥのフローテーブルを修正することにより、適切なトランスポート経路を確立するように指示する。

例のこの部分は、純粋なトランスポートＳＤＮコントローラの取り扱いを示すのみである。図１４は、２つ以上のＳＤＮステアリングエンティティを伴う、この実装形態例の拡張を示す。

ここでは、追加的なネットワークサービスの２つの例が示され、それらのサービスは、１９２と同様であるが、１０分の１のみの帯域幅を伴うサービス１９３、および、Ｓ−Ｇｗ−Ｃ部分（データセンタ内のアプリケーションとして作動する）と、Ｓ−Ｇｗ−Ｕ部分（トランスポートで１つまたはいくつかのＮＥ上で作動する）とからなる、分解されたモバイルゲートウェイ（Ｓ−Ｇｗ）の編成を説明するサービス２０５である。ゲートウェイＣ部分は、ＮＥのフォワーディングプレーンを（例えば、ＧＴＰトンネルハンドリングを遂行するために）、ＳＤＮ制御機構（例えば、ＯｐｅｎＦｌｏｗプロトコル）を使用してステアリングすることになる。

例では、１３で説明したようなシステムが作動しており、すなわち、ネットワークサービス１９２が実装されている。ここで、１で、ＯＳＳ／ＢＳＳは、オーケストレータに、サービス１９２をサービス１９３に変換し（すなわち、サービスは、その元の容量の１０％に低減されることになる）、加えてサービス２０５（分解された仮想化されたＳ−Ｇｗの編成）を実装するように指示する。２で、オーケストレータは、これらのサービスをネットワークサービスデータベース内で探索する。３および４で、そのオーケストレータは、ＣＭＳおよびＡＭＳに、適した計算リソースを予約するように、および、ＳＧｗ−Ｃアプリケーションを、埋め込まれたＳＤＮコントローラによって展開するように指示する。さらに５ａ、ｂ、ｃで、ＡＣＣは、トランスポートＳＤＮコントローラの制御アクセスを、トポロジー的点ＡでのＮＥに対して、元のリソースの１０分の１に制限するように（例えば、１０ポートスイッチ内のポート０に対する操作のみを可能とするように）指示され、一方でそのＡＣＣは、リソースの９０％に対するアプリＳＧＷ−Ｃへの制御アクセス（例えば、１０ポートスイッチ内のポート１〜９への制御アクセス）を割り当てる。

本発明は、以下のように有用である。
− 本発明によって、仮想計算リソースをステアリングすることに適するのと同様の様式での、仮想トランスポートリソースの利用の自動化された制御が可能となる。
− 本発明によって、トランスポートリソースをステアリングするアプリケーションを構築することが可能となる。
− 前記トランスポートリソースを、イントラクラウド、インタークラウド、および、クラウド−非クラウドの接続性に対して使用することが可能となる。
− いくつかの機能が、同じネットワークトランスポートリソースを独立して利用するということが可能となる。
− リソースへの機能の柔軟な割り当てが可能となり、例えば、制御プレーンはデータセンタ内でハンドリングされ、データプレーンはトランスポートネットワーク内でハンドリングされる。

説明した原理なしでは、
− ネットワークノードを、データプレーンがトランスポートネットワーク内に在るような形で分解する
ことは、可能でないことになる。
結果的に、すべてのユーザペイロードデータは、データセンタに運ばれなければならないことになる。

本発明の例の実施形態は、回路として、ソフトウェア、ハードウェア、アプリケーション論理、または、ソフトウェア、ハードウェア、およびアプリケーション論理の組み合わせで実装され得るということが留意されるべきである。例の実施形態では、アプリケーション論理、ソフトウェア、または指示セットは、様々な従来のコンピュータ可読媒体の任意のもので維持される。本文書の文脈では「コンピュータ可読媒体」は、コンピュータ、もしくはスマートフォン、もしくはユーザ機器などの、指示実行システム、装置、もしくはデバイスによる、または、それらに関しての使用のために、指示を、内包する、記憶する、伝達する、伝搬させる、またはトランスポートすることができる、任意の媒体または手段であり得る。

本出願で使用される際は、「回路（ｃｉｒｃｕｉｔｒｙ）」という用語は、以下のもののすべてを指すものであり、すなわち、（ａ）ハードウェアのみの回路実装形態（アナログおよび／またはデジタル回路のみでの実装形態など）、ならびに、（ｂ）（適用可能な際は）（ｉ）プロセッサの組み合わせを指す、または、（ｉｉ）プロセッサ／ソフトウェアの部分を指すなど、回路およびソフトウェア（および／またはファームウェア）の組み合わせを指し（モバイルフォンまたはサーバなどの装置が、様々な機能を遂行することを引き起こすように一体で作動する、デジタル信号プロセッサ）、ソフトウェア、およびメモリを含む）、ならびに、（ｃ）ソフトウェアまたはファームウェアを動作のために、ソフトウェアまたはファームウェアが物理的に存在しない場合でも求める、マイクロプロセッサ、または、マイクロプロセッサの部分などの回路を指す。「回路」のこの定義は、任意の請求項でということを含めて、本出願では、この用語のすべての使用に適用される。さらなる例として、本出願で使用される際は、「回路」という用語はさらには、単にプロセッサ（または、複数のプロセッサ）、または、プロセッサの部分、ならびに、その（または、それらの）プロセッサの付随するソフトウェアおよび／もしくはファームウェアの実装形態を包含することになる。「回路」という用語はさらには、例えば、および、個別の請求項要素に適用可能であるならば、モバイルフォンに対するベースバンド集積回路もしくはアプリケーションプロセッサ集積回路、または、サーバ、セルラネットワークデバイス、もしくは他のネットワークデバイスでの同様の集積回路を包含することになる。

本発明は特に、ただし制限なしで、例えば、ＧＳＭ（登録商標）、３Ｇ、ＬＴＥ（登録商標）、またはＬＴＥアドバンストのもとでの環境に対する、モバイル通信での仮想化に関係し、有利には、さらには、そのようなネットワークに接続可能な、コントローラ、基地局、ユーザ機器もしくはスマートフォン、またはコンピュータで実装され得る。すなわち本発明は、例えば、接続されるデバイスに対するチップセットとして／内で実装され得る。

所望されるならば、本明細書で論考した異なる機能は、互いに関して、異なる順序で、および／または、同時に遂行され得る。さらに、所望されるならば、上記で説明した機能の１つまたは複数は、任意選択であり得るものであり、または、組み合わされ得る。

本発明の様々な態様が、独立請求項に記されているが、本発明の他の態様は、説明した例の実施形態および／または従属請求項からの特徴の、独立請求項の特徴との他の組み合わせを含むものであり、特許請求の範囲で明示的に記されている組み合わせを単に含むだけではない。

さらには本明細書では、上記のことは、本発明の例の実施形態を説明するものであるが、これらの説明は、制限的な意味で考察すべきではないということが留意される。むしろ、添付の特許請求の範囲で定義されるような本発明の範囲から逸脱することなく行われ得る、いくつかの変形形態および修正形態が存する。

本明細書で使用される略語に対する以下の意味が適用される。
ＡＣＣ アクセス制御コンダクタ
ＢＳＳ ビジネスサポートシステム
ＣＡＭ クラウドアプリケーションマネージャ
ｅノードＢ 進化型ノードＢ（ＬＴＥ環境での基地局）
ＥＴＳＩ 欧州電気通信標準化機構
ＧＴＰ ＧＰＲＳトンネルプロトコル
ＮＥ ネットワーク要素
ＮＦ ネットワーク機能
ＮＦＶ ネットワーク機能仮想化
ＯＳＳ オペレーションサポートシステム
ＰＣＥ 経路計算要素
Ｐ−Ｇｗ パケット（ｐａｋｅｔ）データゲートウェイ
ＲＲＭ 無線リソース管理
ＳＤＮ ソフトウェア定義ネットワーキング
Ｓ−Ｇｗ サービングゲートウェイ
ＴＡＭ トランスポートアプリケーションマネージャ
ＴＭＳ トランスポート管理システム
ＶＩＭ 仮想化されたインフラストラクチャマネージャ
ＶＭ 仮想マシン（計算リソース）
ＶＮＦ 仮想ネットワーク機能
ＶＮＦＭ ＶＮＦマネージャ（Ｍａｎｇｅｒ）

Claims (20)

1. 仮想化されたリソースを制御するためのプロセッサ実装方法であって、
   ネットワークサービスをネットワーク要素で実装するための要求を受信するステップと、
   前記ネットワークサービスのキーパラメータを探索するステップと、
   前記ネットワークサービスによる少なくとも１つの計算リソースを選択するステップと、
   前記ネットワークサービスを満たすために要されるほどの、少なくとも１つのアプリケーションを展開するステップと、
   前記ネットワーク要素を前記少なくとも１つのアプリケーションと相互接続するための、少なくとも１つのトランスポートリソースを選択するステップと、
   アクセス制御コンダクタに、トランスポートアクセスマネージャが、前記ネットワーク要素のリソースの少なくとも一部への排他的アクセスを有するということを指示するステップと、
   前記トランスポートアクセスマネージャに、トランスポート経路を前記ネットワーク要素で確立するように指示するステップと
   を含む、プロセッサ実装方法。
2. ネットワーク機能仮想化オーケストレータは、ソフトウェア定義ネットワーキングシステムのネットワークオーケストレーション部分である、請求項１に記載の方法。
3. 前記アクセス制御コンダクタは、同じネットワーク要素のトランスポートリソースへのアプリケーションまたはコントローラの競合的アクセスを管理するように構成される、請求項１または２に記載の方法。
4. 前記計算リソースは仮想マシンである、請求項１から３までのいずれかに記載の方法。
5. 前記トランスポートアクセスマネージャは、ソフトウェア定義ネットワーキングトランスポートコントローラを備える、請求項１から４までのいずれかに記載の方法。
6. 前記トランスポートアクセスマネージャは、それぞれのネットワーク要素への制御アクセスのアクセシビリティを管理するように構成されるアクセス制御コンダクタをさらに備える、請求項５に記載の方法。
7. 前記要求は、オペレーションサポートシステムおよびビジネスサポートシステムなどの高レベルエンティティから受信される、請求項１から６までのいずれかに記載の方法。
8. 仮想化されたリソースを制御するための装置であって、
   少なくとも１つのプロセッサと、
   前記プロセッサにより実行されることになる指示を記憶するための少なくとも１つのメモリと
   を備え、
   前記少なくとも１つのメモリ、および前記指示は、前記少なくとも１つのプロセッサによって、前記装置が少なくとも、
   ネットワークサービスをネットワーク要素で実装するための要求を受信することと、
   前記ネットワークサービスのパラメータを探索することと、
   前記ネットワークサービスによる少なくとも１つの計算リソースを選択することと、
   前記ネットワークサービスを満たすために要されるほどの、少なくとも１つのアプリケーションを展開することと、
   前記ネットワーク要素を前記少なくとも１つのアプリケーションと相互接続するための、少なくとも１つのトランスポートリソースを選択することと、
   アクセス制御コンダクタに、トランスポートアクセスマネージャが、前記ネットワーク要素のリソースの少なくとも一部への排他的アクセスを有するということを指示することと、
   前記トランスポートアクセスマネージャに、トランスポート経路を前記ネットワーク要素で確立するように指示することと
   を遂行することを引き起こすように構成される、装置。
9. ネットワーク機能仮想化オーケストレータは、ソフトウェア定義ネットワーキングシステムのネットワークオーケストレーション部分である、請求項８に記載の装置。
10. 前記アクセス制御コンダクタは、同じネットワーク要素のトランスポートリソースへのアプリケーションまたはコントローラの競合的アクセスを管理するように構成される、請求項８または９に記載の装置。
11. 前記計算リソースは仮想マシンである、請求項８から１０までのいずれかに記載の装置。
12. 前記トランスポートアクセスマネージャは、ソフトウェア定義ネットワーキングトランスポートコントローラを備える、請求項８から１１までのいずれかに記載の装置。
13. 前記トランスポートアクセスマネージャは、それぞれのネットワーク要素への制御アクセスのアクセシビリティを管理するように構成されるアクセス制御コンダクタをさらに備える、請求項１２に記載の装置。
14. 前記要求は、オペレーションサポートシステムおよびビジネスサポートシステムなどの高レベルエンティティから受信される、請求項８から１３までのいずれかに記載の装置。
15. 仮想化されたリソースを制御するためのシステムであって、
    計算リソースを備えるデータセンタと、
    ネットワークサービスのパラメータを記憶するデータベースと、
    前記ネットワークサービスによる少なくとも１つの計算リソースを選択するように構成されるクラウド管理システムと、
    前記ネットワークサービスを満たすために要されるほどの、少なくとも１つのアプリケーションを展開するように構成されるアプリケーション管理システムと、
    前記ネットワークサービスにより影響を受けるネットワーク要素へのアクセスを制御するように構成されるアクセス制御コンダクタと、
    前記ネットワーク要素を前記少なくとも１つのアプリケーションと相互接続するための、少なくとも１つのトランスポートリソースを選択し、トランスポート経路を前記ネットワーク要素で確立するように構成されるトランスポートアクセスマネージャと、
    前記ネットワークサービスを実装するための要求に基づいて、前記クラウド管理システム、前記アプリケーション管理システム、前記アクセス制御コンダクタ、および前記トランスポートアクセスマネージャを制御するように構成されるオーケストレータと
    を備える、システム。
16. 前記トランスポートアクセスマネージャは、ソフトウェア定義ネットワーキングトランスポートコントローラを備える、請求項１５に記載のシステム。
17. 前記トランスポートアクセスマネージャは、それぞれのネットワーク要素への制御アクセスのアクセシビリティを管理するように構成されるアクセス制御コンダクタをさらに備える、請求項１６に記載のシステム。
18. 前記ネットワーク機能仮想化オーケストレータは、ソフトウェア定義ネットワーキングシステムのネットワークオーケストレーション部分である、請求項１５から１７までのいずれかに記載のシステム。
19. コンピュータに対するコンピュータプログラム製品であって、前記製品が前記コンピュータ上で作動されるときに、請求項１から７までのいずれかに記載のステップを遂行するためのソフトウェアコード部分を含む、コンピュータプログラム製品。
20. 前記コンピュータプログラム製品は、前記ソフトウェアコード部分が記憶されるコンピュータ可読媒体を備える、ならびに／または、
    前記コンピュータプログラム製品は、前記コンピュータの内部メモリ内に直接ロード可能である、および／もしくは、ネットワークを介して、アップロード手順と、ダウンロード手順と、プッシュ手順との中の少なくとも１つによって送信可能である、
    請求項１９に記載のコンピュータプログラム製品。