JP6174716B2 - 管理システム、全体管理ノード及び管理方法 - Google Patents

Description

本発明は、通信システムの管理に関する管理システム、全体管理ノード及び管理方法に関する。

従来から、様々な目的で、サーバ仮想化技術によってコンピュータを仮想マシン（ＶＭ：Virtual Machine）とすることが行われている。また、この技術によって、移動体通信網（移動通信ネットワーク）のコアネットワークにおけるノードを仮想マシンとすることが検討されている。

ETSI Group Specification(ETSI GS NFV 002 v1.1.1(2013.10)) Network Functions Virtualization(NFV); Architectural Framework

移動体通信網のコアネットワークにおけるノードは、例えば、仮想マシン上の仮想化された通信機能であるＶＮＦ（Virtual Network Function）によって実現される。上記のような移動体通信網の管理を、ＶＮＦＭ（ＶＮＦ Manager）、ＶＩＭ（Virtual Infrastructure Manager）及びオーケストレータ（Orchestrator）の３つの機能エンティティで行うことが考えられる。ＶＮＦＭは、ＶＮＦを仮想マシン上で実現するための詳細情報を保持し、ＶＮＦの管理機能を有する。ＶＩＭは、仮想マシンが実現される物理サーバ（物理的なサーバ、仮想化資源）の状況を監視し、ＶＮＦＭ又はオーケストレータからの制御によって物理サーバ上に仮想マシン及びＶＮＦを生成、削除する。

なお、物理サーバは、通常、データセンタに複数まとめて配置されており、ＶＩＭは、１つ以上のデータセンタに設置された物理サーバ群に対する処理を行う。また、データセンタにおける物理サーバ群の管理（資源管理）は、ＯＰＥＮＳＴＡＣＫ（登録商標）あるいはｖＣｅｎｔｅｒといった異なる実装方式で行われている。ＶＩＭは、データセンタにおける実装方式毎に設けられている。オーケストレータは、複数のＶＩＭにまたがる全体の資源管理を行う。

ところで、現在の仮想化されていない移動体通信網を構成するノード（通信ノード）は、そのノードを提供するベンダによって、そのノードの内部構造が異なっている。その内部構造は、ベンダ毎の設計ノウハウとなっている。

このノードをＶＮＦとして仮想化する際には、ＶＩＭが、仮想化資源の予約を行い、その後、予約した仮想化資源上に仮想マシンを生成すると共にＶＮＦを仮想化マシン上に生成する。また、ＶＮＦを仮想化マシン上に生成するためには、ＶＮＦＭが保持する、ＶＮＦを仮想マシン上で実現するための詳細情報が必要となる。この詳細情報は、上記の仮想化されていないノードの内部構造に相当するものであり、ベンダ毎の設計ノウハウを含む。

ＶＩＭが、ＶＮＦを仮想化マシン上に生成するためには、ＶＮＦＭに保持された詳細情報に基づくＶＮＦの生成の要求を受け付けなければならない。また、ＶＮＦの生成の要求は、上述したＯＰＥＮＳＴＡＣＫあるいはｖＣｅｎｔｅｒといったデータセンタの実装方式（仮想化資源の管理方式）に応じて行われる必要がある。

ここで、ＶＮＦＭは、通常、ＶＮＦ毎にベンダより提供される。従って、ＶＮＦＭがＶＮＦの生成の要求を行うことを考えると、全てのＶＮＦＭが仮想化資源の管理方式に応じた形式でＶＮＦの生成の要求を行う機能を有していなければならない。即ち、ＶＩＭの方式数×ＶＮＦＭ数の実装パターンをサポートする必要が生じ、非効率となってしまうおそれがある。

本発明は、上記に鑑みてなされたものであり、異なる仮想化資源の管理方式が含まれている場合であっても非効率にならずに、通信処理を実行する仮想サーバを仮想化資源上において実現することができる管理システム、全体管理ノード及び管理方法を提供することを目的とする。

上記目的を達成するために、本発明の一実施形態に係る管理システムは、通信処理を実行する仮想サーバが生成される物理サーバを含む仮想化資源を含んで構成される通信システムに含まれると共に、当該仮想サーバが有する通信処理を実行する機能を管理する仮想通信機能管理ノードと、互いに異なる方式で当該仮想化資源各々を管理する複数の仮想化資源管理ノードと、当該仮想化資源全体の管理を行う全体管理ノードとを備える管理システムであって、仮想化資源管理ノードは、仮想化資源の使用状況を監視する監視手段と、仮想化資源における、仮想サーバの生成に必要な資源の予約の要求を受け付けて予約を行う予約手段と、予約手段によって予約された仮想サーバの生成に必要な資源上に当該仮想サーバを生成させる要求を受け付けて当該仮想サーバを生成する仮想サーバ生成手段と、を備え、仮想通信機能管理ノードは、仮想サーバを仮想化資源上で実現するための詳細情報を保持する保持手段と、全体管理ノードに対して、保持手段に保持された詳細情報を出力する詳細情報出力手段と、を備え、全体管理ノードは、物理サーバでの仮想サーバの生成を伴う通信処理の機能に係る要求を受け付ける要求受付手段と、仮想通信機能管理ノードから詳細情報を入力し、入力した詳細情報を仮想化資源管理ノードによる仮想化資源の管理方式に応じて書き換えて、書き換えた詳細情報を用いて、仮想化資源管理ノードに対して、予約手段によって予約された必要な資源上に当該仮想サーバを生成させる要求を行う仮想サーバ生成要求手段と、を備え、管理システムは、要求受付手段によって受け付けられた要求、及び監視手段によって監視された仮想化資源の使用状況に基づいて、仮想サーバの生成に必要な資源を算出して、仮想化資源管理ノードに対して予約を要求する予約要求手段を、備える。

本発明の一実施形態に係る管理システムでは、全体管理ノードによって、詳細情報が仮想化資源の管理方式に応じて書き換えられて、書き換えられた詳細情報が用いられて、仮想化資源管理ノードに対して仮想サーバを生成させる要求が行われる。従って、仮想通信機能管理ノードが、仮想化資源の管理方式に応じた処理を行う必要がない。これにより、本発明の一実施形態に係る管理システムによれば、異なる仮想化資源の管理方式が含まれている場合であっても非効率にならずに、通信処理を実行する仮想サーバを仮想化資源上において実現することができる。

上記の通信システムに含まれる全体管理ノードは、それら自体が新規な構成を有しており発明に相当する。即ち、本発明の一実施形態に係る全体管理ノードは、通信処理を実行する仮想サーバが生成される物理サーバを含む仮想化資源を含んで構成される通信システムに含まれると共に、当該仮想サーバが有する通信処理を実行する機能を管理する仮想通信機能管理ノードと、互いに異なる方式で当該仮想化資源各々を管理する複数の仮想化資源管理ノードと、当該仮想化資源全体の管理を行う全体管理ノードとを備える管理システムにおける全体管理ノードであって、物理サーバでの仮想サーバの生成を伴う通信処理の機能に係る要求を受け付ける要求受付手段と、仮想通信機能管理ノードから、仮想サーバを仮想化資源上で実現するための詳細情報を入力し、入力した詳細情報を仮想化資源管理ノードによる仮想化資源の管理方式に応じて書き換えて、書き換えた詳細情報を用いて、仮想化資源管理ノードに対して、仮想化資源における、仮想サーバの生成に必要な、予約された資源上に当該仮想サーバを生成させる要求を行う仮想サーバ生成要求手段と、を備える。

ところで、本発明は、上記のように管理システム及び全体管理ノードの発明として記述できる他に、以下のように管理方法の発明としても記述することができる。これはカテゴリが異なるだけで、実質的に同一の発明であり、同様の作用及び効果を奏する。

即ち、本発明の一実施形態に係る管理方法は、通信処理を実行する仮想サーバが生成される物理サーバを含む仮想化資源を含んで構成される通信システムに含まれると共に、当該仮想サーバが有する通信処理を実行する機能を管理する仮想通信機能管理ノードと、互いに異なる方式で当該仮想化資源各々を管理する複数の仮想化資源管理ノードと、当該仮想化資源全体の管理を行う全体管理ノードとを備える管理システムの動作方法である管理方法であって、仮想通信機能管理ノードは、仮想サーバを仮想化資源上で実現するための詳細情報を保持する保持手段を備え、仮想化資源管理ノードが、仮想化資源の使用状況を監視する監視ステップと、仮想化資源における、仮想サーバの生成に必要な資源の予約の要求を受け付けて予約を行う予約ステップと、予約ステップにおいて予約された仮想サーバの生成に必要な資源上に当該仮想サーバを生成させる要求を受け付けて当該仮想サーバを生成する仮想サーバ生成ステップと、仮想通信機能管理ノードが、全体管理ノードに対して、保持手段に保持された詳細情報を出力する詳細情報出力ステップと、全体管理ノードが、物理サーバでの仮想サーバの生成を伴う通信処理の機能に係る要求を受け付ける要求受付ステップと、仮想通信機能管理ノードから詳細情報を入力し、入力した詳細情報を仮想化資源管理ノードによる仮想化資源の管理方式に応じて書き換えて、書き換えた詳細情報を用いて、仮想化資源管理ノードに対して、予約ステップにおいて予約された必要な資源上に当該仮想サーバを生成させる要求を行う仮想サーバ生成要求ステップと、管理システムが、要求受付ステップにおいて受け付けられた要求、及び監視ステップにおいて監視された仮想化資源の使用状況に基づいて、仮想サーバの生成に必要な資源を算出して、仮想化資源管理ノードに対して予約を要求する予約要求ステップと、を含む。

また、本発明の一実施形態に係る管理方法は、通信処理を実行する仮想サーバが生成される物理サーバを含む仮想化資源を含んで構成される通信システムに含まれると共に、当該仮想サーバが有する通信処理を実行する機能を管理する仮想通信機能管理ノードと、互いに異なる方式で当該仮想化資源各々を管理する複数の仮想化資源管理ノードと、当該仮想化資源全体の管理を行う全体管理ノードとを備える管理システムにおける全体管理ノードの動作方法である管理方法であって、物理サーバでの仮想サーバの生成を伴う通信処理の機能に係る要求を受け付ける要求受付ステップと、仮想通信機能管理ノードから、仮想サーバを仮想化資源上で実現するための詳細情報を入力し、入力した詳細情報を仮想化資源管理ノードによる仮想化資源の管理方式に応じて書き換えて、書き換えた詳細情報を用いて、仮想化資源管理ノードに対して、仮想化資源における、仮想サーバの生成に必要な、予約された資源上に当該仮想サーバを生成させる要求を行う仮想サーバ生成要求ステップと、を含む。

また、本発明の一実施形態に係る管理システムは、通信処理を実行する仮想サーバが生成される物理サーバを含む仮想化資源を含んで構成される通信システムに含まれると共に、当該仮想サーバが有する通信処理を実行する機能を管理する仮想通信機能管理ノードと、１以上の方式で当該仮想化資源各々を管理する１以上の仮想化資源管理ノードと、当該仮想化資源全体の管理を行う全体管理ノードとを備える管理システムであって、仮想化資源管理ノードは、仮想化資源の使用状況を監視する監視手段と、仮想化資源における、仮想サーバの生成に必要な資源の予約の要求を受け付けて予約を行う予約手段と、予約手段によって予約された仮想サーバの生成に必要な資源上に当該仮想サーバを生成させる要求を受け付けて当該仮想サーバを生成する仮想サーバ生成手段と、を備え、仮想通信機能管理ノードは、仮想サーバを仮想化資源上で実現するための詳細情報を保持する保持手段と、全体管理ノードに対して、保持手段に保持された詳細情報を出力する詳細情報出力手段と、を備え、全体管理ノードは、物理サーバでの仮想サーバの生成を伴う通信処理の機能に係る要求を受け付ける要求受付手段と、仮想通信機能管理ノードから詳細情報を入力し、入力した詳細情報を仮想化資源管理ノードによる仮想化資源の管理方式に応じて書き換えて、書き換えた詳細情報を用いて、仮想化資源管理ノードに対して、予約手段によって予約された必要な資源上に当該仮想サーバを生成させる要求を行う仮想サーバ生成要求手段と、を備え、管理システムは、要求受付手段によって受け付けられた要求、及び監視手段によって監視された仮想化資源の使用状況に基づいて、仮想サーバの生成に必要な資源を算出して、仮想化資源管理ノードに対して予約を要求する予約要求手段を、備える。

また、本発明の一実施形態に係る全体管理ノードは、通信処理を実行する仮想サーバが生成される物理サーバを含む仮想化資源を含んで構成される通信システムに含まれると共に、当該仮想サーバが有する通信処理を実行する機能を管理する仮想通信機能管理ノードと、１以上の方式で当該仮想化資源各々を管理する１以上の仮想化資源管理ノードと、当該仮想化資源全体の管理を行う全体管理ノードとを備える管理システムにおける全体管理ノードであって、物理サーバでの仮想サーバの生成を伴う通信処理の機能に係る要求を受け付ける要求受付手段と、仮想通信機能管理ノードから、仮想サーバを仮想化資源上で実現するための詳細情報を入力し、入力した詳細情報を仮想化資源管理ノードによる仮想化資源の管理方式に応じて書き換えて、書き換えた詳細情報を用いて、仮想化資源管理ノードに対して、仮想化資源における、仮想サーバの生成に必要な、予約された資源上に当該仮想サーバを生成させる要求を行う仮想サーバ生成要求手段と、を備える。

また、本発明の一実施形態に係る管理方法は、通信処理を実行する仮想サーバが生成される物理サーバを含む仮想化資源を含んで構成される通信システムに含まれると共に、当該仮想サーバが有する通信処理を実行する機能を管理する仮想通信機能管理ノードと、１以上の方式で当該仮想化資源各々を管理する１以上の仮想化資源管理ノードと、当該仮想化資源全体の管理を行う全体管理ノードとを備える管理システムの動作方法である管理方法であって、仮想通信機能管理ノードは、仮想サーバを仮想化資源上で実現するための詳細情報を保持する保持手段を備え、仮想化資源管理ノードが、仮想化資源の使用状況を監視する監視ステップと、仮想化資源における、仮想サーバの生成に必要な資源の予約の要求を受け付けて予約を行う予約ステップと、予約ステップにおいて予約された仮想サーバの生成に必要な資源上に当該仮想サーバを生成させる要求を受け付けて当該仮想サーバを生成する仮想サーバ生成ステップと、仮想通信機能管理ノードが、全体管理ノードに対して、保持手段に保持された詳細情報を出力する詳細情報出力ステップと、全体管理ノードが、物理サーバでの仮想サーバの生成を伴う通信処理の機能に係る要求を受け付ける要求受付ステップと、仮想通信機能管理ノードから詳細情報を入力し、入力した詳細情報を仮想化資源管理ノードによる仮想化資源の管理方式に応じて書き換えて、書き換えた詳細情報を用いて、仮想化資源管理ノードに対して、予約ステップにおいて予約された必要な資源上に当該仮想サーバを生成させる要求を行う仮想サーバ生成要求ステップと、管理システムが、要求受付ステップにおいて受け付けられた要求、及び監視ステップにおいて監視された仮想化資源の使用状況に基づいて、仮想サーバの生成に必要な資源を算出して、仮想化資源管理ノードに対して予約を要求する予約要求ステップと、を含む。

また、本発明の一実施形態に係る管理方法は、通信処理を実行する仮想サーバが生成される物理サーバを含む仮想化資源を含んで構成される通信システムに含まれると共に、当該仮想サーバが有する通信処理を実行する機能を管理する仮想通信機能管理ノードと、１以上の方式で当該仮想化資源各々を管理する１以上の仮想化資源管理ノードと、当該仮想化資源全体の管理を行う全体管理ノードとを備える管理システムにおける全体管理ノードの動作方法である管理方法であって、物理サーバでの仮想サーバの生成を伴う通信処理の機能に係る要求を受け付ける要求受付ステップと、仮想通信機能管理ノードから、仮想サーバを仮想化資源上で実現するための詳細情報を入力し、入力した詳細情報を仮想化資源管理ノードによる仮想化資源の管理方式に応じて書き換えて、書き換えた詳細情報を用いて、仮想化資源管理ノードに対して、仮想化資源における、仮想サーバの生成に必要な、予約された資源上に当該仮想サーバを生成させる要求を行う仮想サーバ生成要求ステップと、を含む。

本発明の一実施形態によれば、仮想通信機能管理ノードが、仮想化資源の管理方式に応じた処理を行う必要がないため、異なる仮想化資源の管理方式が含まれている場合であっても非効率にならずに、通信処理を実行する仮想サーバを仮想化資源上において実現することができる。

本発明の実施形態に係る管理システムの構成、及び当該管理システムを含む移動体通信システムを示す図である。 本発明の実施形態に係る管理システムの機能構成を示す図である。 本発明の実施形態に係る管理システムに含まれるノードのハードウェア構成を示す図である。 管理システムで用いられる情報を格納するテーブルである。 管理システムで用いられる情報を格納するテーブルである。 管理システムで用いられる情報を格納するテーブルである。 管理システムで用いられる情報を格納するテーブルである。 管理システムで用いられる情報を格納するテーブルである。 管理システムで用いられる情報を格納するテーブルである。 管理システムで用いられる情報を格納するテーブルである。 管理システムで用いられる情報を格納するテーブルである。 管理システムで用いられる情報を格納するテーブルである。 管理システムで用いられる情報を格納するテーブルである。 管理システムで用いられる情報を格納するテーブルである。 本発明の実施形態に係る管理システムでインスタンシエーション時に実行される処理（管理方法）を示すシーケンス図である。 本発明の実施形態に係る管理システムでインスタンシエーション時に実行される処理（管理方法）を示すシーケンス図である。 本発明の実施形態に係る管理システムでオートヒーリング時に実行される処理（管理方法）を示すシーケンス図である。 本発明の実施形態に係る管理システムでオートヒーリング時に実行される処理（管理方法）を示すシーケンス図である。 本発明の実施形態に係る管理システムでスケールアウト時に実行される処理（管理方法）を示すシーケンス図である。 本発明の実施形態に係る管理システムでスケールアウト時に実行される処理（管理方法）を示すシーケンス図である。 本発明の実施形態に係る管理システムでスケールイン時に実行される処理（管理方法）を示すシーケンス図である。 本発明の実施形態に係る管理システムでスケールイン時に実行される処理（管理方法）を示すシーケンス図である。 インスタンシエーション、スケールアウト及びスケールインを概念的に示す図である。 増強単位の判断を行う処理を示すフローチャートである。 削減単位の判断を行う処理を示すフローチャートである。 内部機能部単位に増強又は削減するのに必要な情報を格納するテーブルである。 仮想化機能の性能増減単位と実施形態との関係を示した表である。 本発明の実施形態のバリエーションを示す図である。

以下、図面と共に本発明に係る管理システム、全体管理ノード及び管理方法の実施形態について詳細に説明する。なお、図面の説明においては同一要素には同一符号を付し、重複する説明を省略する。

図１に本実施形態に係る管理システム１０を含む移動体通信システム１の構成を示す。移動体通信システム１は、図示しない移動通信端末（移動機）に移動体通信の機能を提供するシステムである。移動通信端末は、ユーザにより用いられて移動体通信システム（移動体通信網）に無線通信によって接続して移動体通信を行う装置である。具体的には、移動通信端末は、携帯電話機等に相当する。移動通信端末は、例えば、移動体通信システム１を介して対向ノードとの間で呼接続を確立して通信を行う。対向ノードは、例えば、別の移動通信端末や移動通信端末に様々なサービスを提供するサーバ装置、あるいは他の通信網に接続するための装置（例えば、ＭＭＥ（Mobility Management Entity）、Ｓ−ＧＷ（Serving Gateway）、Ｐ−ＧＷ（PDN Gateway））等に相当する。移動通信端末は、例えば、移動通信端末のユーザが移動体通信システム１の通信事業者と契約することによって移動体通信を行うことが可能になる。なお、移動通信端末は、従来の移動通信端末と同様のものでよい。

図１に示すように管理システム１０は、オーケストレータ２０と、ＶＮＦＭ３０と、ＶＩＭ４０とを含んで構成されている。また、移動体通信システム１には、ＯＳＳ／ＢＳＳ（Operations Support System／Business Support System）５０と、ＮＦＶＩ（ＮＦＶ Infrastructure）６０と、ＶＮＦ（Virtual Network Function）７０と、ＥＭＳ（Element Management System）８０とを含んで構成されている。これらの構成要素は、移動体通信システム１（移動体通信網）のコアネットワークを構成するものである。なお、互いに情報の送受信が必要な構成要素間は、有線等で接続されており情報の送受信が可能となっている。

本実施形態に係る移動体通信システム１は、物理サーバ上に実現される仮想マシンにおいて動作する仮想サーバによって移動通信端末に対して通信機能が提供される。即ち、移動体通信システム１は、仮想化された移動体通信ネットワークである。通信機能は、仮想マシンによって当該通信機能に応じた通信処理を実行することで移動通信端末に対して提供される。

ＮＦＶＩ６０は、仮想化環境を構成する物理資源、仮想化層、仮想化資源である。物理資源には、計算資源、記憶資源、伝送資源が含まれる。仮想化層は、物理資源を仮想化しＶＮＦ７０（ＡＰＬ）に提供する（例えば、ハイパーバイザー）。仮想化資源は、ＶＮＦ７０に提供される仮想化されたインフラ資源である。即ち、ＮＦＶＩ６０は、移動体通信システム１において通信処理を行う物理的なサーバ装置である物理サーバを含んで構成されている仮想化資源である。物理サーバは、ＣＰＵ（コア、プロセッサ）、メモリ、及びハードディスク等の記憶手段を備えて構成される。通常、ＮＦＶＩ６０を構成する物理サーバは、複数まとめてデータセンタ（ＤＣ）等の拠点に配置される。データセンタでは、配置された物理サーバがデータセンタ内部のネットワークによって接続されており、互いに情報の送受信を行うことができるようになっている。また、移動体通信システム１には、複数のデータセンタが設けられている。データセンタ間はネットワークで接続されており、異なるデータセンタに設けられた物理サーバはそのネットワークを介して互いに情報の送受信を行うことができる。

ＶＮＦ７０は、通信処理を実行する仮想的な通信処理ノードである仮想サーバ（が有する通信処理を実行する機能）である。ＶＮＦ７０は、ＮＦＶＩ６０において実現される。ＶＮＦ７０は、例えば、仮想マシン（ＶＭ）技術が利用されて、ＮＦＶＩ６０が備えるＣＰＵがＶＮＦ７０用に割り当てられて、割り当てられたＣＰＵ上において仮想マシンが実現され、仮想マシン上でプログラムが実行されることにより実現される。ＶＮＦ７０は、通常、実行する通信処理に応じて生成（実現）される。また、ＶＮＦ７０は、その構成要素であるＶＮＦＣ（Virtual Network Function Components）を複数含むものとして構成されていてもよい。

移動体通信システム１には、１以上（あるいは複数）のＶＮＦ７０が含まれる。ＶＮＦ７０は、ＩＭＳでは、ＣＳＣＦ（Call Session Control Function）、ＡＳ（Application Server）等のノードに相当する。あるいは、ＶＮＦ７０は、移動体通信システムの一つであるＧＰＲＳ（General Packet Radio Service）システムでは例えば、ＳＧＳＮ（Serving GPRS Support Node）、ＬＴＥ／ＥＰＣ（Long Term Evolution/Evolved Packet Core）システムでは、ＭＭＥ（Mobility Management Entity）やＳ−ＧＷ（Serving Gateway）等のノードに相当する。

ＥＭＳ８０は、ＶＮＦ７０を監視及び制御するノードである。ＥＭＳ８０も、ＶＮＦ７０と同様にＮＦＶＩ６０において仮想的に実現される。ＥＭＳ８０は、ＶＮＦ７０に対応付けられて（例えば、図１に示すようにＶＮＦ７０と一対一の関係で）生成される。ＥＭＳ８０は、対応付けられたＶＮＦ７０の監視及び制御を行う。ＥＭＳ８０は、ＶＮＦ７０のＦＣＡＰＳ（障害、構成、課金、性能、セキュリティ）管理を行う。ＥＭＳ８０は、前述の説明のように仮想的に実現しても良いし、ＦＣＡＰＳ管理を行う上で管理の複雑性を避けるために物理的に実現しても良い。

ＯＳＳ／ＢＳＳ５０は、移動体通信システム１におけるサービス管理を行い、管理システム１０に移動体通信システム１での通信機能に係る指示を行うノードである。例えば、ＯＳＳ／ＢＳＳ５０は、管理システム１０に対して、新たな通信機能（通信サービス）を起動するように指示を行う。また、ＯＳＳ／ＢＳＳ５０は、ＥＭＳ８０から情報を受け取り、その情報に基づいて管理システム１０又はＥＭＳ８０に対して指示を行う。また、ＯＳＳ／ＢＳＳ５０は、移動体通信システム１に係る通信事業者によって操作されえる。

管理システム１０の構成要素であるオーケストレータ２０は、仮想化資源であるＮＦＶＩ６０全体の管理を行う全体管理ノード（機能エンティティ）である。オーケストレータ２０は、ＯＳＳ／ＢＳＳ５０（のうちのＯＳＳ５１）からの指示を受信し、当該指示に応じた処理を行う。オーケストレータ２０は、インフラと通信サービスの移動体通信網の仮想化資源全体にわたる管理を行う。オーケストレータ２０は、複数のＶＮＦ７０から構成される通信サービスをＶＮＦＭ３０及びＶＩＭ４０を経由して適切な場所に実現する。例えば、サービスのライフサイクル管理（具体的には例えば、生成、更新、スケール制御、イベント収集）、移動体通信網内全体にわたる資源の分散・予約・割当管理、サービス・インスタンス管理、及びポリシー管理（具体的には例えば、リソースの予約・割当、地理・法令等に基づく最適配置）を行う。

管理システム１０の構成要素であるＶＮＦＭ３０は、ＶＮＦ７０を管理する仮想通信機能管理ノード（機能エンティティ）である。ＶＮＦＭ３０は、移動体通信システム１に複数、設けられていてもよい。その場合、ＶＮＦ７０毎に管理されるＶＮＦＭ３０が予め定められていてもよい。ＶＮＦＭ３０は、ＶＮＦ７０（ＡＰＬ）のライフサイクル管理を行う。ＶＮＦＭ３０は、ＶＮＦ７０の仮想化に関わる制御全般を行う。例えば、ＶＮＦ７０インスンタスの生成、更新、スケール制御、終了、オートヒーリング（自動ヒーリング）を行う。

管理システム１０の構成要素であるＶＩＭ４０は、ＮＦＶＩ６０におけるＶＮＦ７０が実現される単位の仮想化資源（インフラリソース）各々を管理する仮想化資源管理ノード（機能エンティティ）である。具体的には、資源の割当・更新・回収の管理、仮想資源と物理との関連付け、ハードウェア資源とＳＷ資源（ハイパーバイザー）一覧の管理を行う。通常、ＶＩＭ４０は、データセンタ（局舎）毎に管理を行う。仮想化資源の管理は、データセンタに応じた方式で行われえる。データセンタの管理方式（管理資源の実装方式）は、ＯＰＥＮＳＴＡＣＫやｖＣｅｎｔｅｒ等の種類がある。通常、ＶＩＭ４０は、データセンタの管理方式毎に設けられる。即ち、管理システム１０には、互いに異なる方式で、ＮＦＶＩ６０におけるＶＮＦ７０が実現される単位の仮想化資源各々を管理する複数のＶＩＭ４０が含まれる。なお、異なる管理方式で管理される仮想化資源の単位は、必ずしもデータセンタ単位でなくてもよい。

なお、オーケストレータ２０、ＶＮＦＭ３０及びＶＩＭ４０は、物理的なサーバ装置上でプログラムが実行されることにより実現される（但し仮想化上で実現されることを制限するものでは無く、管理系統を分離した上で、仮想化上で実現してもよい）。オーケストレータ２０、ＶＮＦＭ３０及びＶＩＭ４０は、それぞれ別々の物理的なサーバ装置で実現されていてもよいし、同じサーバ装置で実現されていてもよい。オーケストレータ２０、ＶＮＦＭ３０及びＶＩＭ４０（を実現するためのプログラム）は、別々のベンダから提供されていてもよい。

なお、上記アーキテクチャは、非特許文献１に記載されたものに準じたものである。また、移動体通信システム１には、移動体通信機能を実現するために、上記以外の構成要素が含まれていてもよい、例えば、移動体通信システム１には、基地局の装置及びオープンフローネットワーク（上記のような仮想化されたものも含む）等が含まれていてもよい。

引き続いて、管理システム１０が有する、本実施形態に係る機能を説明する。図２に示すようにオーケストレータ２０は、要求受付部２１と、予約要求部２２と、仮想サーバ生成要求部２３とを備える。要求受付部２１は、ＯＳＳ／ＢＳＳ５０（のＯＳＳ５１）から、ＮＦＶＩ６０に含まれる物理サーバでのＶＮＦ７０の生成を伴う通信処理の機能に係る要求を受け付ける要求受付手段である。

予約要求部２２は、要求受付部２１によって受け付けられた要求、及びＶＩＭ４０によって監視されたＮＦＶＩ６０の使用状況やＶＮＦＭ３０からの情報等に基づいて、ＶＮＦ７０の生成に必要な資源を算出して、ＶＩＭ４０に対してＮＦＶＩ６０におけるＶＮＦ７０の生成に必要な資源の予約を要求する予約要求手段である。

仮想サーバ生成要求部２３は、ＶＮＦＭ３０から、ＶＮＦ７０をＮＦＶＩ６０上で実現するための詳細情報を入力し、入力した詳細情報をＶＩＭ４０による仮想化資源（ＮＦＶＩ６０）の管理方式に応じて書き換えて、書き換えた詳細情報を用いて、ＶＩＭ４０に対して、ＮＦＶＩ６０において予約された必要な資源上にＶＮＦ７０を生成させる要求を行う仮想サーバ生成要求手段である。

図２に示すようにＶＮＦＭ３０は、保持部３１と、詳細情報出力部３２とを備える。保持部３１は、ＶＮＦ７０をＮＦＶＩ６０上で実現するための詳細情報を保持する保持手段である。詳細情報出力部３２は、オーケストレータ２０に対して、保持部３１に保持された詳細情報を出力する詳細情報出力手段である。

図２に示すようにＶＩＭ４０は、監視部４１と、予約部４２と、仮想サーバ生成部４３とを備える。監視部４１は、ＮＦＶＩ６０の使用状況を監視する監視手段である。予約部４２は、ＮＦＶＩ６０におけるＶＮＦ７０の生成に必要な資源の予約の要求をオーケストレータ２０から受け付けて予約を行う予約手段である。仮想サーバ生成部４３は、予約部４２によって予約されたＶＮＦ７０の生成に必要な資源上に当該ＶＮＦ７０を生成させる要求をオーケストレータ２０から受け付けて当該ＶＮＦ７０を生成する仮想サーバ生成手段である。

以上が、管理システム１０が有する、本実施形態に係る機能である。なお、シーケンス図を用いた管理システム１０による処理の説明において、オーケストレータ２０、ＶＮＦＭ３０及びＶＩＭ４０の本実施形態に係る機能をより詳細に説明する。また、オーケストレータ２０、ＶＮＦＭ３０及びＶＩＭ４０には、上記の機能部に含まれない機能を有しているが、その機能の説明もシーケンス図を用いた管理システム１０による処理の説明に含まれる。

図３に本実施形態に係る管理システム１０に含まれるオーケストレータ２０、ＶＮＦＭ３０及びＶＩＭ４０を構成するサーバ装置のハードウェア構成を示す。図３に示すように当該サーバ装置は、ＣＰＵ１０１、主記憶装置であるＲＡＭ（Random Access Memory）１０２及びＲＯＭ（Read Only Memory）１０３、通信を行うための通信モジュール１０４、並びにハードディスク等の補助記憶装置１０５等のハードウェアを備えるコンピュータを含むものとして構成される。これらの構成要素がプログラム等により動作することにより、上述及び後述するオーケストレータ２０、ＶＮＦＭ３０及びＶＩＭ４０の機能が発揮される。なお、オーケストレータ２０、ＶＮＦＭ３０及びＶＩＭ４０は複数のサーバ装置からなるコンピュータシステムによって構成されていてもよい。また、移動体通信システム１に含まれる上記以外のノードも上記のハードウェア構成を有するサーバ装置によって実現されてもよい。以上が、本実施形態に係る管理システム１０の構成である。

引き続いて、図４〜図１４のテーブル及び図１５〜２２のシーケンス図を用いて、本実施形態に係る管理システム１０で実行される処理である管理方法を説明する。以下では、移動体通信システム１において、（１）インスタンシエーション（Instantiation）、（２）オートヒーリング（Auto-Healing）、（３）スケールアウト（Scale-Out）、（４）スケールイン（Scale-In）が行われる場合の処理を上記の場合毎に説明する。また、図２３に、インスタンシエーション、スケールアウト及びスケールインの概要を示す。

まず、図１５及び図１６のシーケンス図を用いて、（１）インスタンシエーションが行われる場合の処理を説明する。なお、図１６に示すシーケンス図は、図１５のシーケンス図と（時系列的に）連続するものである。インスタンシエーションとは、移動体通信システム１において、新たな通信サービス（通信機能）を提供可能とするため、当該通信サービスに応じた新たなＶＮＦ７０を生成することである。インスタンシエーションにより、移動体通信システム１において新たな通信サービスが提供される。

まず、オーケストレータ２０では、各ＶＩＭ４０に対して、資源使用状況問い合わせが行われる（Ｓ００１）。ＶＩＭ４０では、監視部４１によって当該資源使用状況問い合わせが受信される。監視部４１によってＶＩＭ４０の管理対象となっているＮＦＶＩ６０の資源使用状況が監視される。監視された結果得られた資源使用状況を示す情報が、資源使用状況問い合わせ応答として監視部４１からオーケストレータ２０に送信される（Ｓ００２、監視ステップ）。オーケストレータ２０では、当該情報が受信される。Ｓ００１及びＳ００２の処理は、ＶＩＭ４０毎に定期的に行われる。

この情報は、図４（ａ）の表Ｔ１に示すようにデータセンタ（ＤＣ）毎の情報であり、仮想マシン、ネットワーク（ＮＷ）の資源情報及び提供機能を示す情報が対応付けられたものである。即ち、この情報は、移動体通信システム１（移動体通信網）全体の資源の状態情報である。当該情報は、オーケストレータ２０が有するネットワーク全体資源情報データベースに常に保持される。

図４（ａ）の表Ｔ１における、使用可能帯域とは、データセンタとデータセンタ外部との間の（データセンタの出口の）通信経路の使用可能帯域である。使用可能外部アドレスとは、ＶＮＦ７０に付与可能な、ＶＮＦ７０が他のＶＮＦ７０又はＶＮＦ７０以外と通信を行うために必要なアドレスである。提供機能とは、データセンタが、専用のハードウェアあるいはソフトウェアによって提供できる通信に係る機能である。具体的には、高速パケット処理機能（例えば、Ｉｎｔｅｌ社のＤＰＤＫ）や仮想化層のバイパス技術の機能（例えば、ＳＲ−ＩＯＶ）等がある。

続いて、ＯＳＳ／ＢＳＳ５０（のＯＳＳ５１）から、オーケストレータ２０に対して通信サービスに係るサービス生成の要求（信号（１））が送信される。通信サービスは、例えば、音声通信、メール又は動画（リッチメディア）を送受信する通信である（送信するデータの種別毎に通信サービスが異なる）。この要求は、ＮＦＶＩ６０に含まれる物理サーバでのＶＮＦ７０の生成を伴う通信処理の機能に係る要求である。オーケストレータ２０では、要求受付部２１によって、当該信号が受信される（Ｓ００３、要求受付ステップ）。

当該信号には、生成サービスをユニークに識別する番号としてのサービスＩＤ、生成する通信サービス、性能条件及びネットワーク情報を示す情報が含まれる。具体的には、信号には、通信サービスに“通信サービス１”、性能条件に“１００”、ＮＷ（ネットワーク）条件には「ＤＣ１と５Ｇｂｐｓ以上の帯域で接続するＤＣ」を意味する“ＤＣ１接続、帯域５Ｇｂｐｓ以上”が含まれる（設定される）。

性能条件は、ＶＮＦ７０及びＶＮＦ７０が構成するサービスに対する制御（生成、増強、削減等）において能力を示すために正規化した指標値である。性能条件は、予めＯＳＳ５１とＶＮＦＭ３０との間で取り決められている。

続いて、信号に含まれる情報によって特定される通信サービスを構成するＶＮＦ７０（仮想化機能）及びＶＮＦＭ２０（管理機能）が、予めオーケストレータ２０に登録されている運用データより特定される。具体的には、運用データである図５（ａ）の表Ｔ２より、“通信サービス１”を構成するＶＮＦ７０として“ＶＮＦ１０”と“ＶＮＦ２１”が、次に運用データである図５（ｂ）の表Ｔ３より、“ＶＮＦ１０”のＶＮＦＭ３０が“ＶＮＦＭ１”、“ＶＮＦ２１”のＶＮＦＭ３０が“ＶＮＦＭ２”であることが導き出される（Ａ、Ｓ００４）。

以降（Ｓ００５〜Ｓ０２２）の処理は、ＶＮＦ７０単位にシーケンシャル又は並行して実施される。ここでは、“ＶＮＦ１０”の生成を示す。

続いて、オーケストレータ２０では、特定した“ＶＮＦ１０”の必要とする資源情報を得るため、生成するＶＮＦ７０をユニークに識別する番号としてＶＮＦ識別番号“ＶＮＦ＿００１”が払い出され、信号（１）で受信した性能条件“１００”とサービスＩＤ、ＶＮＦ種別に“通信サービス１”より導き出した“ＶＮＦ１０”が設定されて、信号（２）により、その管理機能である“ＶＮＦＭ１”に問い合わせがおこなわれる（Ｓ００５）。

“ＶＮＦＭ１”では、当該問い合わせが受け付けられる。続いて、“ＶＮＦＭ１”では、受け付けられた信号（２）のＶＮＦ種別に設定されていた“ＶＮＦ１０”の詳細情報が、予め“ＶＮＦＭ１”の保持部３１に保持（登録）されているＶＮＦ詳細情報データベースより読み出される。詳細情報には図６の表Ｔ９のＶＮＦ内部構造と性能条件に応じた資源情報（ＶＭ）、資源情報（ＮＷ）、機能情報の組み合せが登録されている。図６の表Ｔ９の型番はそれぞれの組み合せの識別子である。資源情報（ＶＭ）のイメージファイルは、ＶＭを構成するための情報をファイルとして保持したものであり、ＶＮＦ７０を起動する際に使用する。イメージファイルはＶＩＭ４０が読み出し可能な通信網内の任意の場所に予め格納されている。ＶＮＦ７０は１つ以上の内部機能部から構成され、ＶＮＦ７０の生成のための資源は内部機能部毎にＶＩＭ４０で確保される。配置・起動情報は、ＶＩＭ４０で確保される内部機能部毎の資源とイメージファイルの対応関係、イメージファイルを用いてＶＮＦ７０を起動するための設定情報と内部機能部毎の起動手順、およびＶＮＦ７０を削除する際の内部機能部毎の削減手順を含むものである。資源情報（ＮＷ）のＮＷ構成情報はＶＮＦ７０の内部機能部のＮＷ接続形態を示す情報である。

“ＶＮＦＭ１”では、読み出された詳細情報（図６の表Ｔ９）から信号（２）で受け付けられたＶＮＦ種別“ＶＮＦ１０”の性能条件“１００”に必要となる資源情報（ＶＭ）、資源情報（ＮＷ）、機能情報が取り出され、内部機能部の組み合わせとして図１０（ｃ）の表Ｔ２０が得られる（Ｃ１´、Ｓ００６）。詳細には、読み出された図６の表Ｔ９より、“ＶＮＦ１０”は内部機能部“ＶＮＦＣ１００”と“ＶＮＦＣ１０１”から構成されることが分かる。さらに、性能条件“１００”の場合には、内部機能部“ＶＮＦＣ１００”は、ＣＰＵ性能“Ｈｉｇｈ”を用いた型番“００１”またはＣＰＵ性能“Ｌｏｗ”を用いた型番“００２”の仮想資源（ＶＭ、ＮＷ）により生成可能であり、内部機能部“ＶＮＦＣ１０１”は、ＣＰＵ性能“Ｈｉｇｈ”を用いた型番“００５”またはＣＰＵ性能“Ｌｏｗ”を用いた型番“００６”の仮想資源（ＶＭ、ＮＷ）により生成可能であることが分かる。これより、信号（２）で指示されたＶＮＦ種別“ＶＮＦ１０”の性能条件“１００”となるＶＮＦ７０を生成するのに必要な仮想資源の組み合わせは、“ＶＮＦＣ１００”と“ＶＮＦＣ１０１”がＣＰＵ性能”Ｈｉｇｈ”のみ、ＣＰＵ性能“Ｈｉｇｈ”と”Ｌｏｗ”、ＣＰＵ性能“Ｌｏｗ”のみから構成される４通りとなる。ここでＣＰＵ性能は、ＣＰＵの動作周波数、物理コア数や演算高速化技術などを基にした演算性能に関する分類を表す。“ＶＮＦＭ１”では、得られた表Ｔ２０の資源情報が信号（３）に設定され、信号（２）の応答としてオーケストレータ２０に返送される（Ｓ００７）。“ＶＮＦＭ１”では、信号（２）のサービスＩＤ、ＶＮＦ種別、ＶＮＦ識別番号と詳細情報の表Ｔ９が記憶される。

オーケストレータ２０では、信号（３）が受け付けられる。信号（３）が受け付けられたオーケストレータ２０では、Ａ（Ｓ００４）で特定された“ＶＮＦ１０”を生成するために、“ＶＮＦ１０”を配置可能なデータセンタが、図５（ｃ）の表Ｔ４の運用条件、信号（１）により入力されたＮＷ条件、及び図５（ｅ）の表Ｔ５のデータセンタの接続構成が用いられて選択される。予めオーケストレータ２０に登録されている図５（ｃ）の表Ｔ４から、“ＶＮＦ１０”の配置可能なデータセンタとして“ＤＣ２”“ＤＣ３”“ＤＣ４”“ＤＣ５”が候補として得られる。次に、入力されたＮＷ条件の“ＤＣ１接続、帯域５Ｇｂｐｓ以上”と、予めオーケストレータ２０に登録されている図５（ｅ）の表Ｔ５から得られる“ＤＣ１”に接続しているデータセンタが、“ＤＣ２”“ＤＣ３”“ＤＣ４”という接続情報より、“ＤＣ５”が条件を満たさないことが判明し、候補のデータセンタが“ＤＣ２”“ＤＣ３”“ＤＣ４”とされる。

続いて、オーケストレータ２０では、定期収集により蓄積しているネットワーク全体資源情報データベースの図４（ａ）の表Ｔ１から、選択した“ＤＣ２”“ＤＣ３”“ＤＣ４”の資源情報が読み出される。読み出された資源情報を、図４（ｂ）の表Ｔ８に示す（Ｂ´、Ｓ００８）。

続いて、読み出された、図４（ｂ）の表Ｔ８の資源情報が、信号（３）で受け付けられた、図１０（ｃ）の表Ｔ２０の必要資源情報と比較されて、利用可能なデータセンタが抽出される。具体的には表Ｔ２０より“ＶＮＦ１０”は“機能１”及び“機能２”を必要とし、図４（ｂ）の表Ｔ８より“機能１”及び“機能２”を提供可能なデータセンタは“ＤＣ２”及び“ＤＣ３”であることが判断される。

次に、利用可能なデータセンタの提供する資源でＶＮＦ７０を生成するために必要な資源情報が導き出される。具体的には図４（ｂ）の表Ｔ８より、“ＤＣ２”がＨｉｇｈ及びＬｏｗ、“ＤＣ３”がＬｏｗのＣＰＵ性能を提供可能であることが判別できる。これが、表Ｔ２０の組み合わせにおけるＣＰＵ性能と照らし合わされて（ＶＮＦ７０の生成に必要な資源情報が、データセンタで使用可能かが判断されて）、“ＤＣ２”及び“ＤＣ３”で取り得る資源情報の組み合わせとして、表Ｔ２０の組み合わせにおける“ＤＣ２”では組み合わせ１〜４、“ＤＣ３”では組み合わせ１を取りえることが判断でき、図７（ａ）の表Ｔ１０が得られる（Ｃ２、Ｓ００９）。

続いて、オーケストレータ２０では、予約要求部２２によって資源情報とデータセンタの組み合わせ表（図７（ａ）の表Ｔ１０）に、予めオーケストレータ２０に登録されている図５（ｆ）の表Ｔ１２の優先度指標に基づき優先度が付与され、図７（ｂ）の表Ｔ１３が得られる（Ｄ、Ｓ０１０）。具体的な手順を説明する。図５（ｆ）の表Ｔ１２より第１優先度はＤＣ間帯域となる。図７（ａ）の表Ｔ１０より候補となるＤＣは“ＤＣ２”と“ＤＣ３”であり、図５（ｅ）の表Ｔ５より“ＤＣ１”との間のＮＷ帯域は“ＤＣ３”より“ＤＣ２”の方が大きいことが分かり“ＤＣ２”が高優先となる。次に、図５（ｆ）の表Ｔ１２より第２優先度はＣＰＵ性能となる。図７（ａ）の表Ｔ１０より、“ＤＣ２”の組み合せにおいては、ＣＰＵ性能“Ｈｉｇｈ”だけの組み合せ２の優先度が最も高く、ＣＰＵ性能“Ｌｏｗ”だけの組み合せ１が最も低いことが分かる。ＣＰＵ性能“Ｈｉｇｈ”と“Ｌｏｗ”の組み合せ３と４については、第３優先度のＶＭ用記憶領域：少を用いる。図７（ａ）の表Ｔ１０より、ＶＭ用記憶領域は、組み合せ３が３００ＧＢのＶＭが（１＋２）個、組み合せ４が３００ＧＢのＶＭが２個と５００ＧＢのＶＭが１個となり、ＶＭ用記憶領域の総量が少ない組み合せ３の優先度が高いことが分かる。これより必要資源の組み合せに優先度を付与した図７（ｂ）の表Ｔ１３が得られる。

続いて、優先度の高い組み合わせの順番に、データセンタを管理するＶＩＭ４０への予約が実施される。予約要求部２２によって、図７（ｂ）の表Ｔ１３で優先度の最も高い組み合わせ２の必要資源と対象の“ＤＣ２”が設定されて、資源の予約要求が、図５（ｄ）の表Ｔ６より読み出された“ＤＣ２”の管理機能である“ＶＩＭ１”に送出される（信号（４）、Ｓ０１１、予約要求ステップ）。図７（ｂ）の表Ｔ１３の優先度１の組み合わせの場合は、図８（ａ）の表Ｔ１４の情報が必要資源情報（ＶＭ、ＮＷ）となる（必要資源情報として設定される）。資源予約が失敗した場合は、次優先度の組み合わせの予約要求が行われる（Ｆ、処理Ｓ０１４からの戻り）。

“ＶＩＭ１”では、信号（４）が受け付けられる。信号（４）が受け付けられた“ＶＩＭ１”では、予約部４２によって、信号（４）に設定されている“ＤＣ２”に信号（４）で要求された、図８（ａ）の表Ｔ１４に示される必要資源を確保できるかが、管理域内資源情報データベースをもとに確認され、資源が予約されて予約番号が払い出される（Ｅ、Ｓ０１２、予約ステップ）。“ＶＩＭ１”では、予約番号とともに、予約した“ＤＣ２”、予約された資源情報（表Ｔ１４）が記憶される。“ＶＩＭ１”では、資源が確保できた場合には予約番号が、資源が確保できない場合にはエラーがオーケストレータ２０に応答される（信号（５）、Ｓ０１３）。

オーケストレータ２０では、“ＶＩＭ１”からの信号（５）が受信される。“ＶＩＭ１”からの信号（５）が受信されたオーケストレータ２０では、資源の予約結果が確認される（Ｆ、Ｓ０１４）。資源の予約が出来なかった場合（Ｆ、Ｓ０１４のＮＧ）には、再度、Ｄ（Ｓ０１０）の処理に戻り次優先度の組み合わせの予約が実施される。

オーケストレータ２０では、予約が成功したら、Ｓ００５の処理で払い出されたサービスＩＤ、予約資源情報（ＶＭ、ＮＷ）として図８（ａ）の表Ｔ１４の資源情報が設定され、“ＶＮＦ１０”の管理機能である“ＶＮＦＭ１”に“ＶＮＦ１０”の生成に必要な配置・起動情報、ＮＷ構成情報が要求される（信号（６）、Ｓ０１５）。また、オーケストレータ２０では、サービスＩＤと、ＶＮＦ種別、ＶＮＦ識別番号、予約番号、予約した“ＶＩＭ１”、予約した“ＤＣ２”が記憶される。

“ＶＮＦＭ１”では、詳細情報出力部３２によって、信号（６）が受信される。続いて、詳細情報出力部３２によって、信号（６）で受信したサービスＩＤより、Ｃ１´（Ｓ００６）で記憶されている詳細情報の図６の表Ｔ９が読み出され、信号（６）で受信された予約資源情報（ＶＭ、ＮＷ）の図８（ａ）の表Ｔ１４の型番“００１”、“００５”に対応する配置・起動情報、ＮＷ（ネットワーク）構成情報が決定される。続いて、詳細情報出力部３２によって、生成する仮想マシン（ＶＭ）にＶＭ識別番号が払い出され付与される（Ｇ、Ｓ０１６）。

続いて、“ＶＮＦＭ１”では、詳細情報出力部３２によって、予約できた資源情報と対応させた図８（ｂ）の表Ｔ１５が、信号（７）としてオーケストレータ２０に応答される（Ｓ０１７、詳細情報出力ステップ）。“ＶＮＦＭ１”では、Ｃ１´で記憶されたサービスＩＤ、ＶＮＦ種別、ＶＮＦ識別子に、ＶＭ識別番号、内部機能部が対応付けられて図９（ｃ）の表Ｔ２６が記憶される。

オーケストレータ２０では、仮想サーバ生成要求部２３によって、信号（７）が受信される。続いて、仮想サーバ生成要求部２３によって、Ｓ０１５で記憶された“ＶＩＭ１”、“ＤＣ２”と予約番号１とが読み出される。続いて、仮想サーバ生成要求部２３によって、図５（ｄ）の表Ｔ６より“ＶＩＭ１”の種別が確認され、ＶＩＭ種別に応じて、信号（７）で受信された図８（ｂ）の表Ｔ１５の配置・起動情報、ＮＷ構成情報の書式が変更される（ＶＩＭ４０の管理方式に応じて詳細情報が書き換えられる）（Ｉ、Ｓ０１８、仮想サーバ生成要求ステップ）。なお、この書き換えは、従来技術によって行われえる。

続いて、仮想サーバ生成要求部２３によって、“ＶＩＭ１”用に書式が変更された配置・起動情報とＮＷ構成情報、読み出された予約番号１が設定された信号（８）により、“ＶＩＭ１”に“ＶＮＦ１０”の生成が要求される（Ｓ０１９、仮想サーバ生成要求ステップ）。配置・起動情報、ＮＷ構成情報として設定される情報は図８（ｂ）の表Ｔ１５となる。

“ＶＩＭ１”では、仮想サーバ生成部４３によって、信号（８）が受信される。続いて、仮想サーバ生成部４３によって、信号（８）で受け付けられた予約番号よりＶＮＦ７０を起動する資源としてＥ（Ｓ０１２）の処理で確保された“ＤＣ２”の資源が特定される。続いて、仮想サーバ生成部４３によって、信号（８）で受け付けた表Ｔ１５の配置・起動情報とＮＷ構成情報に基づき“ＤＣ２”にＶＭ及びＶＮＦのイメージファイルが読み込まれて、ＶＭ及びＶＮＦ７０が生成・起動される。

“ＶＩＭ１”では、仮想サーバ生成部４３によって、予め割り当てられている外部ＩＰアドレス帯域から、信号（８）で指定された数の外部アドレスとして“外部ＩＰアドレス０１”“外部ＩＰアドレス０２”がＶＭに付与される。“ＶＩＭ１”では、予約番号と、データセンタに加えて、割り当てた資源情報と物理装置（ＨＷ）の対応付けとして図９（ａ）の表Ｔ２５の情報が記憶される（Ｈ、Ｓ０２０、仮想サーバ生成ステップ）。

続いて、仮想サーバ生成部４３によって、ＶＭ生成時に割り当てられた“外部ＩＰアドレス０１”“外部ＩＰアドレス０２”とＶＭの対応関係がＮＷ（ネットワーク）情報として設定された図９（ｂ）の表Ｔ１７が信号（９）でオーケストレータ２０に応答される（図１６のＳ０２１）。

オーケストレータ２０では、信号（９）が受信される。信号（９）が受信されたオーケストレータ２０では、Ｓ０１５の処理で記憶されたＶＮＦ７０の情報に信号（９）に設定されているＶＭ識別番号、ＮＷ情報が追加されて記憶される。情報の内容は図９（ｄ）の表Ｔ２７となる（Ｊ、Ｓ０２２）。

“ＶＮＦ２１”についても同様にＢ〜Ｊの手順（Ｓ００５〜Ｓ０２２の処理）が実施され、オーケストレータ２０では、“ＶＮＦ２１”の生成結果が反映された図９（ｅ）の表Ｔ２８が得られる（Ｋ、Ｓ０２３）。

Ａ（Ｓ００４）で生成対象と判断した“ＶＮＦ１０”、“ＶＮＦ２１”の生成が完了したことを確認したオーケストレータ２０によって、データセンタ間ネットワークを管理するＶＩＭ４０である“ＶＩＭ−ＮＷ”が、図５（ｄ）の表Ｔ６により特定され、図９（ｅ）の表Ｔ２８より“ＶＮＦ１０”と“ＶＮＦ２１”のＮＷ情報のＩＰアドレスが通知されてＶＮＦ７０間の接続が要求される（信号（１０）、Ｓ０２４）。“ＶＩＭ−ＮＷ”では、当該要求に応じた処理が行われ、その応答がオーケストレータ２０に送信される（Ｓ０２５）。

オーケストレータ２０では、ＶＮＦ７０間接続が完了したら、“ＶＮＦ１０”と“ＶＮＦ２１”の性能、ＶＮＦ種別、ＶＮＦ識別番号、ＮＷ情報が信号（１１）でＯＳＳ５１に通知される（Ｓ０２６）。

ＯＳＳ５１では、信号（１１）が受信され、信号（１）の要求内容と信号（１１）の結果が対応付けられて図１０（ａ）の表Ｔ２９として保持される（Ｌ、Ｓ０２７）。

“ＶＮＦ１０”に続いて生成される“ＶＮＦ２１”のＶＮＦＭ３０である“ＶＮＦＭ２”では、図９（ｆ）の表Ｔ３０の情報が保持される（Ｍ、Ｓ０２８）。

通信サービス生成の完了後に、オーケストレータ２０、“ＶＮＦ１０”のＶＮＦＭ３０、“ＶＮＦ２１”のＶＮＦＭ３０、及びＶＩＭ４０は、それぞれ図９（ｅ）の表Ｔ２８、図９（ｃ）の表Ｔ２６、図９（ｆ）の表Ｔ３０、及び図９（ａ）の表Ｔ２５の情報を保持し、サービスに対する増強、削減、終了などの制御や、障害、輻輳、工事などの保守運用において使用する。

例えば、ＶＩＭ４０は、図９（ａ）の表Ｔ２５の情報を用いて、ハードウェア障害発生時には該当ハードウェアに関連するＶＭを特定し、その管理機能部であるＶＮＦＭ３０やオーケストレータ２０に通知することにより、オートヒーリングや保守者による障害への対処が可能となる。またＶＭに対する増減や終了操作においても、影響する資源を特定し資源情報の管理を行うために使用する。同様に、オーケストレータ２０とＶＮＦＭ３０も、図９（ｅ）の表Ｔ２８及び図９（ｆ）の表Ｔ３０の対応関係を、通信サービスや内部機能に対する増強、削減、終了などの操作を実施するために使用する。

また、これらの対応関係情報は通信網全体の運用システム（ＯＳＳ５１）に集約され、通信網全体の監視・運用のために使用することも可能である。以上が、（１）インスタンシエーションが行われる場合の処理である。

続いて、図１７及び図１８のシーケンス図を用いて、（２）オートヒーリングが行われる場合の処理を説明する。なお、図１８に示すシーケンス図は、図１７のシーケンス図と（時系列的に）連続するものである。オートヒーリングとは、ハードウェア又はソフトウェアの異常によりＶＮＦ７０が正常に動作しなくなった場合に、正常に動作するＶＮＦ７０を自動的に生成することである。オートヒーリングにより、移動体通信システム１において、通信機能が自動的に回復する。

ＯＳＳ５１は、従来システム同様に運用管理システムであるＥＭＳ８０を通じて、インスタンシエーション処理（手順）で生成したＶＮＦ７０の状態を監視して運用する。運用中にＶＮＦ７０の異常（例えば無応答）を検知したＥＭＳ８０は異常をＯＳＳ５１に通知し（Ｓ１０１）、ＯＳＳ５１はＶＮＦ７０の再配置をすることができる。インスタンシエーション処理で生成した“ＶＮＦ１０”“ＶＮＦ２１”のうち、“ＶＮＦ１０”の動作異常（例えば無応答）を検出したＥＭＳ８０からの情報を受信したＯＳＳ５１が、“ＶＮＦ１０”に代わる再配置を決定し、オーケストレータ２０に対して代替ＶＮＦ７０の生成を要求する例を記載する。

ＯＳＳ５１からオーケストレータ２０に対して、再配置元ＶＮＦ７０生成時に使用したサービスＩＤ、再配置対象を識別するためのＶＮＦ識別番号“ＶＮＦ＿００１”、再配置する性能を示す性能条件（例えば、現状同等の性能指標値）である“１００”、ＮＷ条件として現状と別ＤＣへの設置を意味する“別ＤＣ”を設定した信号（１）が送信される（Ｓ１０２）。

オーケストレータ２０では、要求受付部２１によって、サービス再配置要求が受け付けられる（Ｓ１０２、要求受付ステップ）。サービス再配置要求が受け付けられたオーケストレータ２０では、サービスＩＤとＶＮＦ識別番号が用いられて、再配置元のＶＮＦ７０に関する情報として、ＶＮＦ種別、データセンタがＶＮＦ７０生成時に記憶したデータより特定される。図９（ｅ）の表Ｔ２８より、サービスＩＤとＶＮＦ識別番号“ＶＮＦ＿００１”に対応するＶＮＦ種別が“ＶＮＦ１０”、データセンタが“ＤＣ２”、“ＶＮＦ１０”のＶＮＦＭ３０が図５（ｂ）の表Ｔ３より“ＶＮＦＭ１”であることが導き出される（Ａ、Ｓ１０３）。

続いて、オーケストレータ２０では、再配置のために生成するＶＮＦ７０をユニークに識別する番号としてＶＮＦ識別番号“ＶＮＦ＿０１０”が払い出される。続いて、オーケストレータ２０では、信号（１）で受信した生成時のサービスＩＤ“サービスＩＤ１”、性能条件“１００”、再配置元ＶＮＦ識別番号“ＶＮＦ＿００１”、再配置ＶＮＦ識別番号“ＶＮＦ＿０１０”、ＶＮＦ種別“ＶＮＦ１０”が設定された信号（２）が、上記のＡ（Ｓ１０３）で読み出された“ＶＮＦ１０”のＶＮＦＭ３０である“ＶＮＦＭ１”に、必要資源問い合わせ（信号（２））として送信される（Ｓ１０４）。

信号（２）は、“ＶＮＦＭ１”において受信される。信号（２）を受信した“ＶＮＦＭ１”では、信号（２）のＶＮＦ種別に設定されている“ＶＮＦ１０”の詳細情報が、予め“ＶＮＦＭ１”の保持部３１に保持（登録）されているＶＮＦ詳細情報データベースより読み出される。詳細情報には図６の表Ｔ９のＶＮＦ内部構造と性能条件に応じた資源情報（ＶＭ）、資源情報（ＮＷ）、機能情報が登録されている。

“ＶＮＦＭ１”では、読み出された詳細情報（図６の表Ｔ９）から信号（２）で受け付けたＶＮＦ種別“ＶＮＦ１０”の性能条件“１００”に必要な資源情報と機能情報が取り出される（Ｃ１´、Ｓ１０５）。取り出された情報は、内部機能部の組み合わせとして図１０（ｃ）の表Ｔ２０として得られる（Ｃ１´、Ｓ１０５）。詳細には、読み出された図６の表Ｔ９より、“ＶＮＦ１０”は内部機能部“ＶＮＦＣ１００”と“ＶＮＦＣ１０１”から構成されることが分かる。さらに、性能条件“１００”の場合には、内部機能部“ＶＮＦＣ１００”は、ＣＰＵ性能“Ｈｉｇｈ”を用いた型番“００１”またはＣＰＵ性能“Ｌｏｗ”を用いた型番“００２”の仮想資源（ＶＭ、ＮＷ）により生成可能であり、内部機能部“ＶＮＦＣ１０１”は、ＣＰＵ性能“Ｈｉｇｈ”を用いた型番“００５”またはＣＰＵ性能“Ｌｏｗ”を用いた型番“００６”の仮想資源（ＶＭ、ＮＷ）により生成可能であることが分かる。これより、信号（２）で指示されたＶＮＦ種別“ＶＮＦ１０”の性能条件“１００”となるＶＮＦ７０を生成するのに必要な仮想資源の組み合わせは、“ＶＮＦＣ１００”と“ＶＮＦＣ１０１”がＣＰＵ性能”Ｈｉｇｈ”のみ、ＣＰＵ性能“Ｈｉｇｈ”と”Ｌｏｗ”、ＣＰＵ性能“Ｌｏｗ”のみから構成される４通りとなる。“ＶＮＦＭ１”では、得られた表Ｔ２０の資源情報が設定され、信号（３）としてオーケストレータ２０に返送される（Ｓ１０６）。“ＶＮＦＭ１”では、信号（２）のサービスＩＤをもとに、生成時に記憶した情報に再配置ＶＮＦ種別、再配置ＶＮＦ識別番号が加えられて記憶される。

続いて、オーケストレータ２０では、信号（３）が受信される。オーケストレータ２０では、Ａ（Ｓ１０３）で特定した“ＶＮＦ１０”を再配置するために、“ＶＮＦ１０”を配置可能なデータセンタが、図５（ｃ）の表Ｔ４の運用条件、信号（１）により入力されたＮＷ条件及び図５（ｅ）の表Ｔ５のデータセンタの接続構成が用いられて選択される。図５（ｃ）の表Ｔ４から、“ＶＮＦ１０”の配置可能なデータセンタとして“ＤＣ２”“ＤＣ３”“ＤＣ４”“ＤＣ５”が候補として得られる。次に、入力されたＮＷ条件より再配置元ＶＮＦ７０の“ＤＣ２”とは別データセンタであることと、再配置元のＶＮＦ７０が配置されている“ＤＣ２”に接続しているデータセンタが、“ＤＣ１”“ＤＣ３”“ＤＣ５”という図５（ｅ）の表Ｔ５から得られる接続情報より、候補のデータセンタが“ＤＣ３”“ＤＣ５”とされる。

続いて、オーケストレータ２０では、定期収集により蓄積しているネットワーク全体資源情報データベースの図４（ａ）の表Ｔ１から、候補となった“ＤＣ３”“ＤＣ５”の資源情報が読み出される。読み出された資源情報を、図１１（ａ）の表Ｔ３１に示す（Ｂ´、Ｓ１０７）。

続いて、オーケストレータ２０では、“ＤＣ３”“ＤＣ５”の資源情報（図１１（ａ）の表Ｔ３１）と、信号（３）で受けた必要資源情報の図１０（ｃ）の表Ｔ２０とが比較されて、利用可能なデータセンタが抽出される。具体的には図１０（ｃ）の表Ｔ２０より“ＶＮＦ１０”は“機能１”及び“機能２”を必要とし、図１１（ａ）の表Ｔ３１より“機能１”及び“機能２”を、候補の“ＤＣ３”及び“ＤＣ５”は共に提供可能であることが判断される。

次に、利用可能なデータセンタの提供する資源でＶＮＦ７０を生成するために必要な資源情報が導き出される。具体的には図１１（ａ）の表Ｔ３１より、“ＤＣ３”がＬｏｗ、“ＤＣ５”がＨｉｇｈのＣＰＵ性能を提供可能であることが判別できる。これが、図１０（ｃ）の表Ｔ２０の組み合わせにおけるＣＰＵ性能と照らし合わされて、“ＤＣ３”及び“ＤＣ５”で取り得る資源情報の組み合わせとして図１１（ｂ）の表Ｔ３２が得られる（Ｃ２´、Ｓ１０８）。

続いて、オーケストレータ２０では、予約要求部２２によって、資源情報とデータセンタの組み合わせ表（図１１（ｂ）の表Ｔ３２）に、図５（ｆ）の表Ｔ１２の優先度指標が適用される。表Ｔ１２より、第１優先はデータセンタ間帯域であり、図５（ｅ）の表Ｔ５より再配置元ＶＮＦ７０の“ＤＣ２”と“ＤＣ３”との間、“ＤＣ２”と“ＤＣ５”との間の帯域では、“ＤＣ２”と“ＤＣ３”との間の帯域が大きいことが判断できる。これに基づき優先度が付与され、図１１（ｃ）の表Ｔ３３が得られる（Ｄ、Ｓ１０９）。

続いて、優先度の高い組み合わせの順番に、データセンタを管理するＶＩＭ４０への予約が実施される。予約要求部２２によって、図１１（ｃ）の表Ｔ３３で優先度の最も高い“ＤＣ３”の組み合わせ１の必要資源と対象の“ＤＣ３”が設定されて、資源の予約要求が、図５（ｄ）の表Ｔ６より読み出された“ＤＣ３”の管理機能である“ＶＩＭ１”に送出される（信号（４）、Ｓ１１０、予約要求ステップ）。図１１（ｃ）の表Ｔ３３の優先度１の組み合わせの場合は、図１２（ａ）の表Ｔ３４の情報が必要資源情報（ＶＭ、ＮＷ）となる。資源予約が失敗した場合は、次優先度の組み合わせの予約要求が行われる（Ｆ、処理Ｓ１１３からの戻り）。

“ＶＩＭ１”では、信号（４）が受け付けられる。信号（４）が受け付けられた“ＶＩＭ１”では、予約部４２によって、信号（４）に設定されている“ＤＣ３”に信号（４）で要求された、図１２（ａ）の表Ｔ３４に示される必要資源を確保できるかが、管理域内資源情報データベースをもとに確認され、資源が予約されて予約番号１０が払い出される（Ｅ、Ｓ１１１、予約ステップ）。“ＶＩＭ１”では、予約番号１０とともに、予約した“ＤＣ３”、予約された資源情報が記憶される。“ＶＩＭ１”では、資源が確保できた場合には予約番号が、資源が確保できない場合にはエラーがオーケストレータ２０に応答される（信号（５）、Ｓ１１２）。

オーケストレータ２０では、“ＶＩＭ１”からの信号（５）が受信される。“ＶＩＭ１”からの信号（５）が受信されたオーケストレータ２０では、資源の予約結果が確認される（Ｆ、Ｓ１１３）。資源の予約が出来なかった場合（Ｆ、Ｓ１１３のＮＧ）には、再度、Ｄ（Ｓ１０９）の処理に戻り次優先度の組み合わせの予約が実施される。

オーケストレータ２０では、予約が成功したら、再配置元ＶＮＦ７０生成時のサービスＩＤ、予約資源情報（ＶＭ、ＮＷ）として図１２（ａ）の表Ｔ３４の資源情報が設定され、“ＶＮＦＭ１”に“ＶＮＦ１０”の再配置に必要な配置・起動情報、ＮＷ構成情報が要求される（信号（６）、Ｓ１１４）。また、オーケストレータ２０では、再配置ＶＮＦの情報として、サービスＩＤと、ＶＮＦ種別、ＶＮＦ識別番号、予約番号、予約した“ＶＩＭ１”、予約した“ＤＣ３”が記憶される。

“ＶＮＦＭ１”では、詳細情報出力部３２によって、信号（６）が受信される。続いて、詳細情報出力部３２によって、信号（６）で受信したサービスＩＤより、Ｃ１´（Ｓ１０５）で記憶されている詳細情報の図６の表Ｔ９が読み出され、信号（６）で受信された予約資源情報（ＶＭ、ＮＷ）の図１２（ａ）の表Ｔ３４の型番“００２”、“００６”に対応する配置・起動情報、ＮＷ（ネットワーク）構成情報が決定される。続いて、詳細情報出力部３２によって、生成する仮想マシン（ＶＭ）にＶＭ識別番号が払い出され付与される（Ｇ、Ｓ１１５）。

続いて、“ＶＮＦＭ１”では、詳細情報出力部３２によって、予約できた資源情報と対応させた図１２（ｂ）の表Ｔ３５が、信号（７）としてオーケストレータ２０に応答される（Ｓ１１６、詳細情報出力ステップ）。“ＶＮＦＭ１”では、Ｃ１´（Ｓ１０５）で記憶されたサービスＩＤ、ＶＮＦ種別、ＶＮＦ識別子に、ＶＭ識別番号、内部機能部が対応付けられて図９（ｇ）の表Ｔ４２が記憶される。

オーケストレータ２０では、仮想サーバ生成要求部２３によって、信号（７）が受信される。続いて、仮想サーバ生成要求部２３によって、Ｓ１１４で記憶された“ＶＩＭ１”、“ＤＣ３”と予約番号１０とが読み出される。続いて、仮想サーバ生成要求部２３によって、図５（ｄ）の表Ｔ６より“ＶＩＭ１”の種別が確認され、ＶＩＭ種別に応じて、信号（７）で受信された図１２（ｂ）の表Ｔ３５の配置・起動情報、ＮＷ構成情報の書式が変更される（ＶＩＭ４０の管理方式に応じて詳細情報が書き換えられる）（Ｉ、Ｓ１１７、仮想サーバ生成要求ステップ）。

続いて、仮想サーバ生成要求部２３によって、“ＶＩＭ１”用に書式が変更された配置・起動情報とＮＷ構成情報、読み出された予約番号１０が設定された信号（８）により、“ＶＩＭ１”に“ＶＮＦ１０”の生成が要求される（Ｓ１１８、仮想サーバ生成要求ステップ）。配置・起動情報、ＮＷ構成情報として設定される情報は図１２（ｂ）の表Ｔ３５となる。

“ＶＩＭ１”では、仮想サーバ生成部４３によって、信号（８）が受信される。続いて、仮想サーバ生成部４３によって、信号（８）で受け付けられた予約番号よりＶＮＦ７０を起動する資源としてＥ（Ｓ１１１）の処理で確保された“ＤＣ３”の資源が特定される。続いて、仮想サーバ生成部４３によって、信号（８）で受け付けた表Ｔ３５の配置・起動情報とＮＷ構成情報に基づき“ＤＣ３”にＶＭ及びＶＮＦのイメージファイルが読み込まれて、ＶＭ及びＶＮＦ７０が生成・起動される。

“ＶＩＭ１”では、仮想サーバ生成部４３によって、予め割り当てられている外部ＩＰアドレス帯域から、信号（８）で指定された数の外部アドレスとして“外部ＩＰアドレス１０”“外部ＩＰアドレス１１”がＶＭに付与される。“ＶＩＭ１”では、Ｅ（Ｓ１１１）の予約番号と、データセンタに加えて、“ＶＮＦＭ１”のＶＭ識別番号、物理装置（ＨＷ）の対応付けとして、図１４の表Ｔ４１の情報が記憶される（Ｈ、Ｓ１１９、仮想サーバ生成ステップ）。

続いて、仮想サーバ生成部４３によって、ＶＭ生成時に割り当てられた外部ＩＰアドレスがＮＷ情報として設定された図１２（ｃ）の表Ｔ３６が信号（９）でオーケストレータ２０に応答される（図１８のＳ１２０）。

オーケストレータ２０では、信号（９）が受信される。信号（９）が受信されたオーケストレータ２０では、再配置対象のＶＮＦ７０の生成が完了したことが確認される。オーケストレータ２０では、Ｓ１１４の処理で記憶されたＶＮＦ７０の情報に信号（９）に設定されているＶＭ識別番号、ＮＷ情報が生成時に作成された図９（ｅ）の表Ｔ２８に追加して記憶される。情報の内容は図１０（ｂ）の表Ｔ４０となる（Ｊ、Ｓ１２１）。

再配置元ＶＮＦ７０が接続していたＶＮＦ７０である“ＶＮＦ２１”のＮＷ情報が、表Ｔ４０より読み出され、再配置したＶＮＦ７０とのＮＷ接続が行われる。表Ｔ４０より読み出された“ＶＮＦ２１”の通信用の“外部ＩＰアドレス２０”と、信号（９）で受信された再配置された“ＶＮＦ１０”の通信用の“外部ＩＰアドレス１０”が設定された接続要求が、図５（ｄ）の表Ｔ６から特定されるＶＮＦ７０間ネットワークを管理する“ＶＩＭ−ＮＷ”に対して行われる（信号（１０）、Ｓ１２２）。“ＶＩＭ−ＮＷ”では、信号（１０）が受信されて、それに対する応答がオーケストレータ２０に送信される（Ｓ１２３）。信号（１０）が受信された“ＶＩＭ−ＮＷ”では、“外部ＩＰアドレス２０”と、“外部ＩＰアドレス１０”との接続が実施される（Ｌ、Ｓ１２４）。

オーケストレータ２０では、Ｓ１２２の接続要求に対する“ＶＩＭ−ＮＷ”からの応答（Ｓ１２３）が受信される。続いて、オーケストレータ２０では、ＶＮＦ７０間接続が完了したら、信号（９）で受信した“ＶＮＦ１０”のＮＷ情報、性能、ＶＮＦ種別及びＶＮＦ識別番号が信号（１１）でＯＳＳ５１に通知される（Ｓ１２５）。ＯＳＳ５１では、信号（１１）が受信されて、信号（１）の要求内容と信号（１１）の結果とを対応付けて生成時の図１０（ａ）の表Ｔ２９に追記した図１３の表Ｔ３９が保持される（Ｍ、Ｓ１２６）。この後、ＯＳＳ５１は、対向する“ＶＮＦ１０”の切り替えを通知するために、再配置された“ＶＮＦ１０”のＮＷ情報をＥＭＳ８０を通じて“ＶＮＦ２１”に通知することにより運用が再開される。 ＯＳＳ５１は、再配置された“ＶＮＦ１０”と接続先の“ＶＮＦ２１”の通信が開始されたことを確認した後に、再配置元の“ＶＮＦ１０”に対して、停止や終了の保守操作を開始する。以上が、（２）オートヒーリングが行われる場合の処理である。

続いて、図１９及び図２０のシーケンス図を用いて、（３）スケールアウトが行われる場合の処理を説明する。なお、図２０に示すシーケンス図は、図１９のシーケンス図と（時系列的に）連続するものである。スケールアウトとは、ＶＮＦ７０の負荷が大きくなった場合にＶＮＦ７０の負荷分散をさせるため等に、当該ＶＮＦ７０と同じ機能を有するＶＮＦ７０を生成することである。スケールアウトにより、移動体通信システム１において適切な負荷分散等が図られる。

ＯＳＳ５１は、従来システム同様に運用管理システムであるＥＭＳ８０を通じて、インスタンシエーション処理（手順）で生成したＶＮＦ７０の状態を監視して運用する。ＥＭＳ８０は、ＶＮＦ７０からの状態情報の通知を受信し（Ｓ２０１）、受信した状態情報をＯＳＳ５１に送信する（Ｓ２０２）。上記の処理は、定期的に行われる。ＯＳＳ５１は、運用中に状態情報に基づき、ＶＮＦ７０の負荷上昇を検知し、運用中に一定レベルを上回る負荷への上昇をしたＶＮＦ７０の性能を増強することができる。インスタンシエーション処理で生成した“ＶＮＦ１０”“ＶＮＦ２１”のうち、“ＶＮＦ１０”の負荷上昇を検出したＯＳＳ５１が、ＶＮＦ７０の性能の１００％増強を決定し、オーケストレータ２０に対して要求する例を記載する。

ＯＳＳ５１からオーケストレータ２０に対して、増強元ＶＮＦ７０生成時に使用したサービスＩＤ、増強対象を識別するためのＶＮＦ識別番号“ＶＮＦ＿００１”、増強する性能を示す性能条件（例えば、現状同等の性能指標値）である“１００”、ＮＷ条件として現状と別ＤＣへの設置を意味する“別ＤＣ”を設定した信号（１）が送信される（Ｓ２０３）。

オーケストレータ２０では、要求受付部２１によって、サービス増強要求が受け付けられる（Ｓ２０３、要求受付ステップ）。サービス増強要求が受け付けられたオーケストレータ２０では、サービスＩＤとＶＮＦ識別番号が用いられて、増強元のＶＮＦ７０に関する情報として、ＶＮＦ種別、データセンタがＶＮＦ７０生成時に記憶したデータより特定される。図９（ｅ）の表Ｔ２８より、サービスＩＤとＶＮＦ識別番号“ＶＮＦ＿００１”に対応するＶＮＦ種別が“ＶＮＦ１０”、データセンタが“ＤＣ２”、“ＶＮＦ１０”のＶＮＦＭ３０が図５（ｂ）の表Ｔ３より“ＶＮＦＭ１”であることが導き出される（Ａ、Ｓ２０４）。

続いて、オーケストレータ２０では、増強のために生成するＶＮＦ７０をユニークに識別する番号としてＶＮＦ識別番号“ＶＮＦ＿０１０”が払い出される。続いて、オーケストレータ２０では、信号（１）で受信した生成時のサービスＩＤ“サービスＩＤ１”、性能条件“１００”、増強元ＶＮＦ識別番号“ＶＮＦ＿００１”、増強ＶＮＦ識別番号“ＶＮＦ＿０１０”、ＶＮＦ種別“ＶＮＦ１０”が設定された信号（２）が、上記のＡ（Ｓ２０３）で読み出された“ＶＮＦ１０”のＶＮＦＭ３０である“ＶＮＦＭ１”に、必要資源問い合わせ（信号（２））として送信される（Ｓ２０５）。

信号（２）は、“ＶＮＦＭ１”において受信される。信号（２）を受信した“ＶＮＦＭ１”では、信号（２）のＶＮＦ種別に設定されている“ＶＮＦ１０”の詳細情報が、予め“ＶＮＦＭ１”の保持部３１に保持（登録）されているＶＮＦ詳細情報データベースより読み出される。詳細情報には図６の表Ｔ９のＶＮＦ内部構造と性能条件に応じた資源情報（ＶＭ）、資源情報（ＮＷ）、機能情報が登録されている。

“ＶＮＦＭ１”では、読み出された詳細情報（図６の表Ｔ９）から信号（２）で受け付けたＶＮＦ種別“ＶＮＦ１０”の性能条件“１００”に必要な資源情報と機能情報が取り出される（Ｃ１´、Ｓ２０６）。取り出された情報は、内部機能部の組み合わせとして図１０（ｃ）の表Ｔ２０として得られる（Ｃ１´、Ｓ２０６）。詳細には、読み出された図６の表Ｔ９より、“ＶＮＦ１０”は内部機能部“ＶＮＦＣ１００”と“ＶＮＦＣ１０１”から構成されることが分かる。さらに、性能条件“１００”の場合には、内部機能部“ＶＮＦＣ１００”は、ＣＰＵ性能“Ｈｉｇｈ”を用いた型番“００１”またはＣＰＵ性能“Ｌｏｗ”を用いた型番“００２”の仮想資源（ＶＭ、ＮＷ）により生成可能であり、内部機能部“ＶＮＦＣ１０１”は、ＣＰＵ性能“Ｈｉｇｈ”を用いた型番“００５”またはＣＰＵ性能“Ｌｏｗ”を用いた型番“００６”の仮想資源（ＶＭ、ＮＷ）により生成可能であることが分かる。これより、信号（２）で指示されたＶＮＦ種別“ＶＮＦ１０”の性能条件“１００”となるＶＮＦ７０を生成するのに必要な仮想資源の組み合わせは、“ＶＮＦＣ１００”と“ＶＮＦＣ１０１”がＣＰＵ性能”Ｈｉｇｈ”のみ、ＣＰＵ性能“Ｈｉｇｈ”と”Ｌｏｗ”、ＣＰＵ性能“Ｌｏｗ”のみから構成される４通りとなる。“ＶＮＦＭ１”では、得られた表Ｔ２０の資源情報が設定され、信号（３）としてオーケストレータ２０に返送される（Ｓ２０７）。“ＶＮＦＭ１”では、信号（２）のサービスＩＤをもとに、生成時に記憶した情報に増強ＶＮＦ種別、増強ＶＮＦ識別番号が加えられて記憶される。

続いて、オーケストレータ２０では、信号（３）が受信される。オーケストレータ２０では、Ａ（２０４）で特定した“ＶＮＦ１０”を増強するために、“ＶＮＦ１０”を配置可能なデータセンタが、図５（ｃ）の表Ｔ４の運用条件、信号（１）により入力されたＮＷ条件及び図５（ｅ）の表Ｔ５のデータセンタの接続構成が用いられて選択される。図５（ｃ）の表Ｔ４から、“ＶＮＦ１０”の配置可能なデータセンタとして“ＤＣ２”“ＤＣ３”“ＤＣ４”“ＤＣ５”が候補として得られる。次に、入力されたＮＷ条件より増強元ＶＮＦ７０の“ＤＣ２”とは別データセンタであることと、増強元のＶＮＦ７０が配置されている“ＤＣ２”に接続しているデータセンタが、“ＤＣ１”“ＤＣ３”“ＤＣ５”という図５（ｅ）の表Ｔ５から得られる接続情報より、候補のデータセンタが“ＤＣ３”“ＤＣ５”とされる。

続いて、オーケストレータ２０では、定期収集により蓄積しているネットワーク全体資源情報データベースの図４（ａ）の表Ｔ１から、候補となった“ＤＣ３”“ＤＣ５”の資源情報が読み出される。読み出された資源情報を、図１１（ａ）の表Ｔ３１に示す（Ｂ´、Ｓ２０８）。

続いて、オーケストレータ２０では、“ＤＣ３”“ＤＣ５”の資源情報（図１１（ａ）の表Ｔ３１）と、信号（３）で受けた必要資源情報の図１０（ｃ）の表Ｔ２０とが比較されて、利用可能なデータセンタが抽出される。具体的には図１０（ｃ）の表Ｔ２０より“ＶＮＦ１０”は“機能１”及び“機能２”を必要とし、図１１（ａ）の表Ｔ３１より“機能１”及び“機能２”を、候補の“ＤＣ３”及び“ＤＣ５”は共に提供可能であることが判断される。

次に、利用可能なデータセンタの提供する資源でＶＮＦ７０を生成するために必要な資源情報が導き出される。具体的には図１１（ａ）の表Ｔ３１より、“ＤＣ３”がＬｏｗ、“ＤＣ５”がＨｉｇｈのＣＰＵ性能を提供可能であることが判別できる。これが、図１０（ｃ）の表Ｔ２０の組み合わせにおけるＣＰＵ性能と照らし合わされて、“ＤＣ３”及び“ＤＣ５”で取り得る資源情報の組み合わせとして図１１（ｂ）の表Ｔ３２が得られる（Ｃ２´、Ｓ２０９）。

続いて、オーケストレータ２０では、予約要求部２２によって、資源情報とデータセンタの組み合わせ表（図１１（ｂ）の表Ｔ３２）に、図５（ｆ）の表Ｔ１２の優先度指標が適用される。表Ｔ１２より、第１優先はデータセンタ間帯域であり、図５（ｅ）の表Ｔ５より接続先ＶＮＦ７０である“ＶＮＦ２１”の“ＤＣ２”と“ＤＣ３”との間、“ＤＣ２”と“ＤＣ５”との間の帯域では、“ＤＣ２”と“ＤＣ３”との間の帯域が大きいことが判断できる。これに基づき優先度が付与され、図１１（ｃ）の表Ｔ３３が得られる（Ｄ、Ｓ２１０）。

続いて、優先度の高い組み合わせの順番に、データセンタを管理するＶＩＭ４０への予約が実施される。予約要求部２２によって、図１１（ｃ）の表Ｔ３３で優先度の最も高い“ＤＣ３”の組み合わせ１の必要資源と対象の“ＤＣ３”が設定されて、資源の予約要求が、図５（ｄ）の表Ｔ６より読み出された“ＤＣ３”の管理機能である“ＶＩＭ１”に送出される（信号（４）、Ｓ２１１、予約要求ステップ）。図１１（ｃ）の表Ｔ３３の優先度１の組み合わせの場合は、図１２（ａ）の表Ｔ３４の情報が必要資源情報（ＶＭ、ＮＷ）となる。資源予約が失敗した場合は、次優先度の組み合わせの予約要求が行われる（Ｆ、処理Ｓ２１４からの戻り）。

“ＶＩＭ１”では、信号（４）が受け付けられる。信号（４）が受け付けられた“ＶＩＭ１”では、予約部４２によって、信号（４）に設定されている“ＤＣ３”に信号（４）で要求された、図１２（ａ）の表Ｔ３４に示される必要資源を確保できるかが、管理域内資源情報データベースをもとに確認され、資源が予約されて予約番号１０が払い出される（Ｅ、Ｓ２１２、予約ステップ）。“ＶＩＭ１”では、予約番号１０とともに、予約した“ＤＣ３”、予約された資源情報が記憶される。“ＶＩＭ１”では、資源が確保できた場合には予約番号が、資源が確保できない場合にはエラーがオーケストレータ２０に応答される（信号（５）、Ｓ２１３）。

オーケストレータ２０では、“ＶＩＭ１”からの信号（５）が受信される。“ＶＩＭ１”からの信号（５）が受信されたオーケストレータ２０では、資源の予約結果が確認される（Ｆ、Ｓ２１４）。資源の予約が出来なかった場合（Ｆ、Ｓ２１４のＮＧ）には、再度、Ｄ（Ｓ２１０）の処理に戻り次優先度の組み合わせの予約が実施される。

オーケストレータ２０では、予約が成功したら、増強元ＶＮＦ７０生成時のサービスＩＤ、予約資源情報（ＶＭ、ＮＷ）として図１２（ａ）の表Ｔ３４の資源情報が設定され、“ＶＮＦＭ１”に“ＶＮＦ１０”の増強に必要な配置・起動情報、ＮＷ構成情報が要求される（信号（６）、Ｓ２１５）。また、オーケストレータ２０では、増強ＶＮＦの情報として、サービスＩＤと、ＶＮＦ種別、ＶＮＦ識別番号、予約番号、予約した“ＶＩＭ１”、予約した“ＤＣ３”が記憶される。

“ＶＮＦＭ１”では、詳細情報出力部３２によって、信号（６）が受信される。続いて、詳細情報出力部３２によって、信号（６）で受信したサービスＩＤより、Ｃ１´（Ｓ２０６）で記憶されている詳細情報の図６の表Ｔ９が読み出され、信号（６）で受信された予約資源情報（ＶＭ、ＮＷ）の図１２（ａ）の表Ｔ３４の型番“００２”、“００６”に対応する配置・起動情報、ＮＷ（ネットワーク）構成情報が決定される。続いて、詳細情報出力部３２によって、生成する仮想マシン（ＶＭ）にＶＭ識別番号が払い出され付与される（Ｇ、Ｓ２１６）。

続いて、“ＶＮＦＭ１”では、詳細情報出力部３２によって、予約できた資源情報と対応させた図１２（ｂ）の表Ｔ３５が、信号（７）としてオーケストレータ２０に応答される（Ｓ２１７、詳細情報出力ステップ）。“ＶＮＦＭ１”では、Ｃ１´（Ｓ２０６）で記憶されたサービスＩＤ、ＶＮＦ種別、ＶＮＦ識別子に、ＶＭ識別番号、内部機能部が対応付けられて図９（ｇ）の表Ｔ４２が記憶される。

オーケストレータ２０では、仮想サーバ生成要求部２３によって、信号（７）が受信される。続いて、仮想サーバ生成要求部２３によって、Ｓ２１５で記憶された“ＶＩＭ１”、“ＤＣ３”と予約番号１０とが読み出される。続いて、仮想サーバ生成要求部２３によって、図５（ｄ）の表Ｔ６より“ＶＩＭ１”の種別が確認され、ＶＩＭ種別に応じて、信号（７）で受信された図１２（ｂ）の表Ｔ３５の配置・起動情報、ＮＷ構成情報の書式が変更される（ＶＩＭ４０の管理方式に応じて詳細情報が書き換えられる）（Ｉ、Ｓ２１８、仮想サーバ生成要求ステップ）。

続いて、仮想サーバ生成要求部２３によって、“ＶＩＭ１”用に書式が変更された配置・起動情報とＮＷ構成情報、読み出された予約番号１０が設定された信号（８）により、“ＶＩＭ１”に“ＶＮＦ１０”の生成が要求される（Ｓ２１９、仮想サーバ生成要求ステップ）。配置・起動情報、ＮＷ構成情報として設定される情報は図１２（ｂ）の表Ｔ３５となる。

“ＶＩＭ１”では、仮想サーバ生成部４３によって、信号（８）が受信される。続いて、仮想サーバ生成部４３によって、信号（８）で受け付けられた予約番号よりＶＮＦ７０を起動する資源としてＥ（Ｓ２１２）の処理で確保された“ＤＣ３”の資源が特定される。続いて、仮想サーバ生成部４３によって、信号（８）で受け付けた表Ｔ３５の配置・起動情報とＮＷ構成情報に基づき“ＤＣ３”にＶＭ及びＶＮＦのイメージファイルが読み込まれて、ＶＭ及びＶＮＦ７０が生成・起動される。

“ＶＩＭ１”では、仮想サーバ生成部４３によって、予め割り当てられている外部ＩＰアドレス帯域から、信号（８）で指定された数の外部アドレスとして“外部ＩＰアドレス１０”“外部ＩＰアドレス１１”がＶＭに付与される。“ＶＩＭ１”では、Ｅ（Ｓ２１２）の予約番号と、データセンタに加えて、“ＶＮＦＭ１”のＶＭ識別番号、割り当てた資源情報、物理装置（ＨＷ）の対応付けとして、図１４の表Ｔ４１の情報が記憶される（Ｈ、Ｓ２２０、仮想サーバ生成ステップ）。

続いて、仮想サーバ生成部４３によって、ＶＭ生成時に割り当てられた外部ＩＰアドレスがＮＷ情報として設定された図１２（ｃ）の表Ｔ３６が信号（９）でオーケストレータ２０に応答される（図２０のＳ２２１）。

オーケストレータ２０では、信号（９）が受信される。信号（９）が受信されたオーケストレータ２０では、増強対象のＶＮＦ７０の生成が完了したことが確認される。オーケストレータ２０では、Ｓ２１５の処理で記憶されたＶＮＦ７０の情報に信号（９）に設定されているＶＭ識別番号、ＮＷ情報が生成時に作成された図９（ｅ）の表Ｔ２８に追加して記憶される。情報の内容は図１０（ｂ）の表Ｔ４０となる（Ｊ、Ｓ２２２）。

増強元ＶＮＦ７０が接続していたＶＮＦ７０である“ＶＮＦ２１”のＮＷ情報が、表Ｔ４０より読み出され、増強したＶＮＦ７０とのＮＷ接続が行われる。表Ｔ４０より読み出された“ＶＮＦ２１”の通信用の“外部ＩＰアドレス２０”と、信号（９）で受信された増強された“ＶＮＦ１０”の通信用の“外部ＩＰアドレス１０”が設定された接続要求が、図５（ｄ）の表Ｔ６から特定されるＶＮＦ７０間ネットワークを管理する“ＶＩＭ−ＮＷ”に対して行われる（信号（１０）、Ｓ２２３）。“ＶＩＭ−ＮＷ”では、信号（１０）が受信されて、それに対する応答がオーケストレータ２０に送信される（Ｓ２２４）。信号（１０）が受信された“ＶＩＭ−ＮＷ”では、“外部ＩＰアドレス２０”と、“外部ＩＰアドレス１０”との接続が実施される（Ｌ、Ｓ２２５）。

オーケストレータ２０では、Ｓ２２３の接続要求に対する“ＶＩＭ−ＮＷ”からの応答（Ｓ２２４）が受信される。続いて、オーケストレータ２０では、ＶＮＦ７０間接続が完了したら、信号（９）で受信した増強された“ＶＮＦ１０”のＮＷ情報、性能、ＶＮＦ種別及びＶＮＦ識別番号が信号（１１）でＯＳＳ５１に通知される（Ｓ２２６）。ＯＳＳ５１では、信号（１１）が受信されて、信号（１）の要求内容と信号（１１）の結果とを対応付けて生成時の図１０（ａ）の表Ｔ２９に追記した図１３の表Ｔ３９が保持される（Ｍ、Ｓ２２７）。以上が、（３）スケールアウトが行われる場合の処理である。

続いて、図２１及び図２２のシーケンス図を用いて、（４）スケールインが行われる場合の処理を説明する。なお、図２２に示すシーケンス図は、図２１のシーケンス図と（時系列的に）連続するものである。スケールインとは、負荷が低い同じ機能を有する複数のＶＮＦ７０がある場合等に、ＶＮＦ７０を集約することである。スケールインにより、移動体通信システム１において適切な資源の活用が図られる。

ＯＳＳ５１は、従来システム同様に運用管理システムであるＥＭＳ８０を通じて、インスタンシエーション処理（手順）で生成し、更にスケールアウト処理（手順）で増強したＶＮＦ７０の状態を監視して運用する。ＥＭＳ８０は、ＶＮＦ７０からの状態情報の通知（信号（１））を受信し（Ｓ３０１）、受信した状態情報（信号（１））をＯＳＳ５１に送信する（Ｓ３０２）。上記の処理は、定期的に行われる。ＯＳＳ５１は、運用中に状態情報に基づき、ＶＮＦの負荷低減を検知し、運用中に一定レベルを下回る負荷への低減をしたＶＮＦ７０の性能を削減することができる。上述したスケールアウト処理で増強して、複数となった“ＶＮＦ１０”について、一定レベルを下回る負荷への低下を検知したＯＳＳ５１が、“ＶＮＦ１０”全体の性能の削減を決定し、オーケストレータ２０に対して要求する例を記載する。

ＯＳＳ５１では、オーケストレータ２０を通じて生成、増強又は削減したＶＮＦ７０のサービス種別について、図１３の表Ｔ３９のように管理されている。

ＯＳＳ５１では、上記の信号（１）にあるようにＶＮＦ７０から定期的にＶＮＦ７０の負荷量が収集され、同一機能のＶＮＦ７０について、統合しても負荷が十分に定格以内に収まるのであれば、分散した処理のスケールイン統合が判断される。例えば、ＯＳＳ５１では、信号（１）（メッセージ（１））で取得された複数のＶＮＦ７０（“ＶＮＦ＿００１”と“ＶＮＦ＿０１０”）のうち、より負荷量の少ないほうを削除対象とする（Ａ、Ｓ３０３）。

ＯＳＳ５１では、図１３の表Ｔ３９が参照されて、同サービスにて、削除対象となるＶＮＦ７０と接続している対向ノード（表Ｔ３９では、“ＶＮＦ＿０２１”）が判断され、対向ノードに対して、新たに発生するトラヒックについて削除対象のＶＮＦ７０（“ＶＮＦ＿０１０”）に送信しないように、ＥＭＳ８０を介して信号（２）にて構成変更が指示される（Ｓ３０４、Ｓ３０５）。

“ＶＮＦ＿０２１”では、信号（２）が受信されて、対向している“ＶＮＦ＿００１”と“ＶＮＦ＿０１０”に負荷分散していたトラヒックについて、削除対象のＶＮＦ７０（“ＶＮＦ＿０１０”）に新たなトラヒックを送信しないように構成変更が行われ（Ｓ３０６）、応答メッセージ（３）（信号（３））がＥＭＳ８０を介してＯＳＳ５１に返信される（Ｓ３０７、Ｓ３０８）。

ＯＳＳ５１では、当該応答メッセージ（３）（信号（３））が受信される。続いて、ＯＳＳ５１では、ＥＭＳ８０を介して削除対象となるＶＮＦ７０（“ＶＮＦ＿０１０”）に対して、メッセージ（４）（信号）にて閉塞、ユーザ追出し要求が行われる（Ｓ３０９、Ｓ３１０）。

“ＶＮＦ＿０１０”では、既に収容しているユーザトラヒックについて処理が完了するのが待たれ（又は強制終了され）、処理が収斂される（Ｃ、Ｓ３１１）。続いて、“ＶＮＦ＿０１０”から、ＥＭＳ８０を介してＯＳＳ５１に対して応答メッセージ（５）（信号（５））が返信される（Ｓ３１２、Ｓ３１３）。

ＯＳＳ５１では、当該応答メッセージ（５）（信号（５））が受信される。続いて、ＯＳＳ５１では、ＶＮＦ生成時に使用したサービスＩＤ、削減対象を識別するためのＶＮＦ識別番号“ＶＮＦ＿０１０”、削減する性能を示す性能条件は、削減したい性能値である“１００”が設定された信号（６）が生成され（Ｓ３１４）、サービス削減要求としてオーケストレータ２０に対して送信される（図２２のＳ３１５）。

オーケストレータ２０では、サービス削減要求が受け付けられる。サービス削減要求が受け付けられたオーケストレータ２０では、サービスＩＤとＶＮＦ識別番号が用いられて、削減対象のＶＮＦ７０に関する情報として、ＶＮＦ種別、データセンタがＶＮＦ７０作成又は増強時に記憶したデータより特定される。図１０（ｂ）の表Ｔ４０より、サービスＩＤとＶＮＦ識別番号“ＶＮＦ＿０１０”に対応するＶＮＦ種別が“ＶＮＦ１０”、データセンタが“ＤＣ３”、“ＶＮＦ１０”のＶＮＦＭ３０が図５（ｂ）の表Ｔ３より“ＶＮＦＭ１”であることが導き出される（Ｅ、Ｓ３１６）。

続いて、オーケストレータ２０では、上記で特定した“ＶＮＦ＿０１０”を削除するために、図１０（ｂ）の表Ｔ４０より、削除対象となるＶＮＦ７０生成時のサービスＩＤ、削除対象となるＶＮＦ種別、ＶＮＦ識別番号、予約先のＶＩＭ識別番号（“ＶＩＭ１”）、予約番号（“１０”）が得られる（Ｆ、Ｓ３１７）。オーケストレータ２０では、“ＶＮＦＭ１”に対して、これらの情報が含められて信号（７）により、“ＶＮＦ＿０１０”の削減が要求される（Ｓ３１８）。

“ＶＮＦＭ１”では、信号（７）が受信される。“ＶＮＦＭ１”では、信号（７）で受信されたＶＮＦ削減要求メッセージから、サービスＩＤ、ＶＮＦ種別、ＶＮＦ識別番号、ＶＩＭ識別番号、予約番号が得られる（Ｇ、Ｓ３１９）。続いて、“ＶＮＦＭ１”では、これらの情報から、図６の表Ｔ９から削減手順が得られ、オーケストレータ２０に返信される（信号（８）、Ｓ３２０）。

オーケストレータ２０では、信号（８）が受信される。オーケストレータ２０では、信号（８）で受信したＶＮＦ削減情報応答メッセージから、予約番号、ＶＭ識別番号、削減手順が得られて（Ｈ、Ｓ３２１）、“ＶＩＭ１”にＶＮＦ削除要求が送信される（信号（９）、Ｓ３２２）。

“ＶＩＭ１”では、信号（９）が受信される。“ＶＩＭ１”では、信号（９）で受信したＶＮＦ削減要求メッセージから、予約番号が得られて、図１４の表Ｔ４１より、削除対象となるＤＣ番号“ＤＣ３”とＶＭ識別番号を得て、ＶＭの削減が実行される（Ｊ、Ｓ３２３）。続いて、“ＶＩＭ１”では、信号（１０）により、ＶＮＦ削減応答がオーケストレータ２０に返信される（Ｓ３２４）。

オーケストレータ２０では、ＶＮＦ削減応答（ＶＮＦ削除応答メッセージ）が受信される。続いて、オーケストレータ２０では、図１０（ｂ）の表Ｔ４０より、削除を行ったＶＮＦ７０間の接続の解放要求が生成されて（Ｋ、Ｓ３２５）、信号（１１）により“ＶＩＭ−ＮＷ”に送信される（Ｓ３２６）。

“ＶＩＭ−ＮＷ”では、信号（１１）が受信されて、解放要求に対する応答が行われる（Ｓ３２７）。また、“ＶＩＭ−ＮＷ”では、ＶＮＦ７０間の接続の解放が実施される（Ｌ、Ｓ３２８）。

オーケストレータ２０では、“ＶＩＭ−ＮＷ”からの応答が受信されて、信号（１２）によって、サービス削減応答がＯＳＳ５１に対して行われる（Ｓ３２９）。図１０（ｂ）の表Ｔ４０から“ＶＮＦ＿０１０”を削減した図９（ｅ）の表Ｔ２８が保持される。

ＯＳＳ５１では、信号（１）の要求内容と信号（１１）の結果を対応付けて、図１３の表Ｔ３９からＶＮＦを削減した図１０（ｂ）の表Ｔ２９の情報が保持される。以上が、（４）スケールインが行われる場合の処理である。

上述した実施形態では、仮想通信機能（ＶＮＦ７０）単位での増強・削減手順を示したが、一般には、ＶＮＦ７０は１つ以上の内部機能部（ＶＮＦＣ）から構成され、内部機能部単位に増強・削減する運用も実施されている。

上述した実施形態では、スケールアウト、スケールイン、オートヒーリングにおいてインスタンシエーションと共通のＶＮＦ詳細情報（図６の表Ｔ９）を用いた。しかし、予め内部機能部単位の増強・削減パターンをＶＮＦ詳細情報として登録し、生成（起動）しているＶＮＦ７０の内部機能部の組み合わせを基に、指定された性能条件を満たす内部機能部の増強・削減パターンを抽出する手順を追加することにより、内部機能部単位の増強・削減が可能となる。

この際、ＶＮＦ単位の操作対象を識別していたＶＮＦ識別番号を内部機能部単位の操作を特定できる識別子とする必要がある。例えば、１つのＶＮＦ内の内部機能部の上限数（図２６（ａ）の表ＴＸ）、ＶＮＦ内部機能単位の増強・削除パターン（図２６（ｂ）の表ＴＹ）、を詳細情報として予めＶＮＦＭ３０のデータベースに追加登録しておく。

スケールアウトの場合、以下のように行われる。図１９のスケールアウトの処理における処理（手順）Ｃ１での増強元ＶＮＦの詳細情報の読み出しの際に、図２４のフローチャートで示される増強単位の判断を追加する。Ｓ２０５の信号（２）にてＶＮＦ１０の増強として性能条件“１００”を受信する例を記載する。処理（手順）Ｃ１´で増強元ＶＮＦの詳細情報（図９（ｄ）の表Ｔ２７）を読み出し、増強元ＶＮＦのＶＭ数を図２６（ａ）の表ＴＸの上限数と比較し、上限数に達していない場合にはＶＮＦＣ単位の増強を行うと判断する。次に予めＶＮＦＭ３０に登録されている図２６（ｂ）の表ＴＹより、性能条件“１００”に必要な資源情報と機能情報として型番“１０１”の構成が取り出される。

増強単位をＶＮＦ７０単位とするか内部機能部単位とするかをＶＮＦＭ３０で判断するのではなくＯＳＳ５１から指示することも可能である。内部機能部単位の増強パターンが表ＴＹより抽出された以降は、上述したスケールアウトの実施形態と同様の手順を適用する。

スケールインの場合、以下のように行われる。図２２のスケールインの処理における処理（手順）Ｇでの削減ＶＮＦの詳細情報の読み出しの際に、図２５のフローチャートで示される削減単位の判断を追加し、１つの削減パターンを抽出する。ＶＮＦＭ３０が削減単位を判断するために、図２２のシーケンス図においてＯＳＳ５１では信号（６）で受信した性能条件“１００”を信号（７）に含めてＶＮＦＭ３０に対して要求される。ＶＮＦＭ３０では受信された信号（７）よりＶＮＦ識別番号、性能条件が得られる。ＶＮＦＭ３０”では、信号（７）で受信されたＶＮＦ識別番号を基に、保持する削減元ＶＮＦの詳細情報（図９（ｇ）の表Ｔ４２）を読み出し、削減元ＶＮＦのＶＭ数を図２６（ａ）の表の最小構成数と比較し、最小構成でなければＶＮＦＣ単位の削減を行うと判断する。次に予めＶＮＦＭ３０に登録されている図２６（ｂ）の表ＴＹより、性能条件“１００”に対応する資源情報と機能情報として型番“１０１”の構成が取り出され、削減対象の資源と手順を得る。

削減単位をＶＮＦ７０単位とするか内部機能部単位とするかをＶＮＦＭ３０で判断するのではなくＯＳＳ５１から指示することも可能である。内部機能部単位の削減パターンが表ＴＹより抽出された以降は、上述したスケールインの実施形態と同様の手順を適用する。

仮想化機能の性能増減単位と実施形態との関係を図２７に示す。

本発明の実施形態のバリエーションを図２８に示す。図２８において、「選択」は、候補となる資源エリア（ＶＩＭ４０／データセンタ）の抽出を示す。「予約」は、候補エリアの中から資源予約の依頼を行うことを示す。「配置計画」は、予約資源へのＶＮＦ７０の配置計画作成を示す。「割当」は、配置計画に基づく資源割当（ＶＮＦ７０の生成）を示す。「詳細条件」は、配置計画を作成するための条件を示す。「条件」は、詳細条件を抽象化した条件を示す。「全体」は、全体資源情報を示す。域内は、管理域内資源情報を示す。また、図２８中の破線の領域に示したように、プロプライエタリではない資源情報は何れの経路でも入手可能である。

上述した実施形態は、ＶＩＭ４０（データセンタ）の選択をオーケストレータ２０が、ＶＮＦ７０の配置計画の生成をＶＮＦＭ３０が、ＶＩＭ４０へのＶＮＦ７０の生成の指示をオーケストレータ２０が、それぞれ行うパターンであった（図２８のパターンの左から１つ目のパターン）。しかしながら、ＶＩＭ（データセンタ）４０の選択をオーケストレータ２０ではなく、ＶＮＦＭ３０が行うパターンとしてもよい（図２８のパターンの左から２つ目のパターン）。また、ＶＮＦ７０の配置計画の生成をＶＮＦＭ３０ではなく、オーケストレータ２０が行うパターンとしてもよい（図２８のパターンの左から３つ目のパターン）。なお、選択をＶＮＦＭ３０で実施していながら、より詳細な情報を必要とするＶＭ配置をオーケストレータ２０とする組み合わせ（図２８のパターンの左から４つ目のパターン）は現実解ではない。

本実施形態に係る管理システム１０では、オーケストレータ２０によって、詳細情報（具体的には、図６の表Ｔ９の配置・起動情報及びＮＷ構成情報）が仮想化資源の管理方式に応じて書き換えられて、書き換えられた詳細情報が用いられて、ＶＩＭ４０に対してＶＮＦ７０を生成させる要求が行われる。従って、ＶＮＦＭ３０が、仮想化資源の管理方式に応じた処理を行う必要がない。これにより、本実施形態に係る管理システム１０によれば、異なる仮想化資源の管理方式が含まれている場合であっても非効率にならずに、通信処理を実行するＶＮＦ７０を仮想化資源上において実現することができる。例えば、ＶＮＦＭ３０を提供するベンダは、仮想化資源の管理方式を考慮する必要がない。これにより、仮想化資源の管理方式に応じたＶＮＦＭ３０を調達する必要がなく、コストの増大を防止することができる。

なお、上述した実施形態では、移動通信端末に移動体通信の機能を提供する移動体通信システムであるものとしたが、本発明は、必ずしも移動体通信システムである必要はない。本発明は、固定の通信端末に固定通信の機能を提供する固定通信システムに適用することが可能である。固定の通信端末と固定通信システムとは、上述した移動体通信システムとは異なり、有線で接続されている。上述した実施形態を、移動通信端末を固定通信端末と、移動体通信を固定通信と、移動体通信システムを固定通信システムとそれぞれ置き換えることで本発明に係る固定通信システムの実施形態とすることができる。但し、この場合、具体的なノードは固定通信システムに応じたものである。また、移動体通信と固定通信とが混在した通信システムにおいて本発明を実施することも可能である。

即ち、本発明は、移動通信端末、移動体通信及び移動体通信システムに限られるものではなく、上述した実施形態と同様の枠組みを有するものであれば、任意の通信端末、任意の通信、及び任意の通信システムに適用することが可能である。

また、上述した実施形態では、ＶＮＦ７０の生成に先立って予約が行われているが、必ずしも予約が行われる必要はない。

また、上述した管理システム１０には、互いに異なる方式で、ＮＦＶＩ６０におけるＶＮＦ７０が実現される単位の仮想化資源各々を管理する複数のＶＩＭ４０が含まれることとしていた。しかしながら、必ずしもこの構成を前提とする必要はなく、１以上の方式で、ＮＦＶＩ６０におけるＶＮＦ７０が実現される単位の仮想化資源各々を管理する複数のＶＩＭが含まれる管理システムを前提としてもよい。なお、一般に、システム（ソフトウェア）は同一製品でもバージョンが更新される。１つのＶＩＭと、方式の異なる複数のＶＮＦＭが接続するケースにおいても、ＶＩＭのバージョン更新に伴い接続相手の複数のＶＮＦＭが改版を必要とすることがある。このようなケースにおいても、オーケストレータを介する本実施形態の方式を適用することで影響箇所をオーケストレータの１箇所に留めることができ、効率化が図られる。

１…移動体通信システム、１０…管理システム、２０…オーケストレータ、２１…要求受付部、２２…予約要求部、２３…仮想サーバ生成要求部、３０…ＶＮＦＭ、３１…保持部、３２…詳細情報出力部、４０…ＶＩＭ、４１…監視部、４２…予約部、４３…仮想サーバ生成部、５０…ＯＳＳ／ＢＳＳ、５１…ＯＳＳ、６０…ＮＦＶＩ、７０…ＶＮＦ、８０…ＥＭＳ、１０１…ＣＰＵ、１０２…ＲＡＭ、１０３…ＲＯＭ、１０４…通信モジュール、１０５…補助記憶装置。

Claims (8)

1. 通信処理を実行する仮想サーバが生成される物理サーバを含む仮想化資源を含んで構成される通信システムに含まれると共に、当該仮想サーバが有する通信処理を実行する機能を管理する仮想通信機能管理ノードと、互いに異なる方式で当該仮想化資源各々を管理する複数の仮想化資源管理ノードと、当該仮想化資源全体の管理を行う全体管理ノードとを備える管理システムであって、
   前記仮想化資源管理ノードは、
   前記仮想化資源の使用状況を監視する監視手段と、
   前記仮想化資源における、前記仮想サーバの生成に必要な資源の予約の要求を受け付けて予約を行う予約手段と、
   前記予約手段によって予約された前記仮想サーバの生成に必要な資源上に当該仮想サーバを生成させる要求を受け付けて当該仮想サーバを生成する仮想サーバ生成手段と、を備え、
   前記仮想通信機能管理ノードは、
   前記仮想サーバを前記仮想化資源上で実現するための詳細情報を保持する保持手段と、
   前記全体管理ノードに対して、前記保持手段に保持された前記詳細情報を出力する詳細情報出力手段と、を備え、
   前記全体管理ノードは、
   前記物理サーバでの仮想サーバの生成を伴う前記通信処理の機能に係る要求を受け付ける要求受付手段と、
   前記仮想通信機能管理ノードから前記詳細情報を入力し、入力した詳細情報を前記仮想化資源管理ノードによる仮想化資源の管理方式に応じて書き換えて、書き換えた詳細情報を用いて、前記仮想化資源管理ノードに対して、前記予約手段によって予約された前記必要な資源上に当該仮想サーバを生成させる要求を行う仮想サーバ生成要求手段と、を備え、
   前記管理システムは、前記要求受付手段によって受け付けられた要求、及び前記監視手段によって監視された前記仮想化資源の使用状況に基づいて、前記仮想サーバの生成に必要な資源を算出して、前記仮想化資源管理ノードに対して前記予約を要求する予約要求手段を、備える管理システム。
2. 通信処理を実行する仮想サーバが生成される物理サーバを含む仮想化資源を含んで構成される通信システムに含まれると共に、当該仮想サーバが有する通信処理を実行する機能を管理する仮想通信機能管理ノードと、互いに異なる方式で当該仮想化資源各々を管理する複数の仮想化資源管理ノードと、当該仮想化資源全体の管理を行う全体管理ノードとを備える管理システムにおける全体管理ノードであって、
   前記物理サーバでの仮想サーバの生成を伴う前記通信処理の機能に係る要求を受け付ける要求受付手段と、
   前記仮想通信機能管理ノードから、仮想サーバを前記仮想化資源上で実現するための詳細情報を入力し、入力した詳細情報を前記仮想化資源管理ノードによる仮想化資源の管理方式に応じて書き換えて、書き換えた詳細情報を用いて、前記仮想化資源管理ノードに対して、前記仮想化資源における、前記仮想サーバの生成に必要な、予約された資源上に当該仮想サーバを生成させる要求を行う仮想サーバ生成要求手段と、
   を備える全体管理ノード。
3. 通信処理を実行する仮想サーバが生成される物理サーバを含む仮想化資源を含んで構成される通信システムに含まれると共に、当該仮想サーバが有する通信処理を実行する機能を管理する仮想通信機能管理ノードと、互いに異なる方式で当該仮想化資源各々を管理する複数の仮想化資源管理ノードと、当該仮想化資源全体の管理を行う全体管理ノードとを備える管理システムの動作方法である管理方法であって、
   前記仮想通信機能管理ノードは、前記仮想サーバを前記仮想化資源上で実現するための詳細情報を保持する保持手段を備え、
   前記仮想化資源管理ノードが、
   前記仮想化資源の使用状況を監視する監視ステップと、
   前記仮想化資源における、前記仮想サーバの生成に必要な資源の予約の要求を受け付けて予約を行う予約ステップと、
   前記予約ステップにおいて予約された前記仮想サーバの生成に必要な資源上に当該仮想サーバを生成させる要求を受け付けて当該仮想サーバを生成する仮想サーバ生成ステップと、
   前記仮想通信機能管理ノードが、
   前記全体管理ノードに対して、前記保持手段に保持された前記詳細情報を出力する詳細情報出力ステップと、
   前記全体管理ノードが、
   前記物理サーバでの仮想サーバの生成を伴う前記通信処理の機能に係る要求を受け付ける要求受付ステップと、
   前記仮想通信機能管理ノードから前記詳細情報を入力し、入力した詳細情報を前記仮想化資源管理ノードによる仮想化資源の管理方式に応じて書き換えて、書き換えた詳細情報を用いて、前記仮想化資源管理ノードに対して、前記予約ステップにおいて予約された前記必要な資源上に当該仮想サーバを生成させる要求を行う仮想サーバ生成要求ステップと、
   前記管理システムが、前記要求受付ステップにおいて受け付けられた要求、及び前記監視ステップにおいて監視された前記仮想化資源の使用状況に基づいて、前記仮想サーバの生成に必要な資源を算出して、前記仮想化資源管理ノードに対して前記予約を要求する予約要求ステップと、
   を含む管理方法。
4. 通信処理を実行する仮想サーバが生成される物理サーバを含む仮想化資源を含んで構成される通信システムに含まれると共に、当該仮想サーバが有する通信処理を実行する機能を管理する仮想通信機能管理ノードと、互いに異なる方式で当該仮想化資源各々を管理する複数の仮想化資源管理ノードと、当該仮想化資源全体の管理を行う全体管理ノードとを備える管理システムにおける全体管理ノードの動作方法である管理方法であって、
   前記物理サーバでの仮想サーバの生成を伴う前記通信処理の機能に係る要求を受け付ける要求受付ステップと、
   前記仮想通信機能管理ノードから、仮想サーバを前記仮想化資源上で実現するための詳細情報を入力し、入力した詳細情報を前記仮想化資源管理ノードによる仮想化資源の管理方式に応じて書き換えて、書き換えた詳細情報を用いて、前記仮想化資源管理ノードに対して、前記仮想化資源における、前記仮想サーバの生成に必要な、予約された資源上に当該仮想サーバを生成させる要求を行う仮想サーバ生成要求ステップと、
   を含む管理方法。
5. 通信処理を実行する仮想サーバが生成される物理サーバを含む仮想化資源を含んで構成される通信システムに含まれると共に、当該仮想サーバが有する通信処理を実行する機能を管理する仮想通信機能管理ノードと、１以上の方式で当該仮想化資源各々を管理する１以上の仮想化資源管理ノードと、当該仮想化資源全体の管理を行う全体管理ノードとを備える管理システムであって、
   前記仮想化資源管理ノードは、
   前記仮想化資源の使用状況を監視する監視手段と、
   前記仮想化資源における、前記仮想サーバの生成に必要な資源の予約の要求を受け付けて予約を行う予約手段と、
   前記予約手段によって予約された前記仮想サーバの生成に必要な資源上に当該仮想サーバを生成させる要求を受け付けて当該仮想サーバを生成する仮想サーバ生成手段と、を備え、
   前記仮想通信機能管理ノードは、
   前記仮想サーバを前記仮想化資源上で実現するための詳細情報を保持する保持手段と、
   前記全体管理ノードに対して、前記保持手段に保持された前記詳細情報を出力する詳細情報出力手段と、を備え、
   前記全体管理ノードは、
   前記物理サーバでの仮想サーバの生成を伴う前記通信処理の機能に係る要求を受け付ける要求受付手段と、
   前記仮想通信機能管理ノードから前記詳細情報を入力し、入力した詳細情報を前記仮想化資源管理ノードによる仮想化資源の管理方式に応じて書き換えて、書き換えた詳細情報を用いて、前記仮想化資源管理ノードに対して、前記予約手段によって予約された前記必要な資源上に当該仮想サーバを生成させる要求を行う仮想サーバ生成要求手段と、を備え、
   前記管理システムは、前記要求受付手段によって受け付けられた要求、及び前記監視手段によって監視された前記仮想化資源の使用状況に基づいて、前記仮想サーバの生成に必要な資源を算出して、前記仮想化資源管理ノードに対して前記予約を要求する予約要求手段を、備える管理システム。
6. 通信処理を実行する仮想サーバが生成される物理サーバを含む仮想化資源を含んで構成される通信システムに含まれると共に、当該仮想サーバが有する通信処理を実行する機能を管理する仮想通信機能管理ノードと、１以上の方式で当該仮想化資源各々を管理する１以上の仮想化資源管理ノードと、当該仮想化資源全体の管理を行う全体管理ノードとを備える管理システムにおける全体管理ノードであって、
   前記物理サーバでの仮想サーバの生成を伴う前記通信処理の機能に係る要求を受け付ける要求受付手段と、
   前記仮想通信機能管理ノードから、仮想サーバを前記仮想化資源上で実現するための詳細情報を入力し、入力した詳細情報を前記仮想化資源管理ノードによる仮想化資源の管理方式に応じて書き換えて、書き換えた詳細情報を用いて、前記仮想化資源管理ノードに対して、前記仮想化資源における、前記仮想サーバの生成に必要な、予約された資源上に当該仮想サーバを生成させる要求を行う仮想サーバ生成要求手段と、
   を備える全体管理ノード。
7. 通信処理を実行する仮想サーバが生成される物理サーバを含む仮想化資源を含んで構成される通信システムに含まれると共に、当該仮想サーバが有する通信処理を実行する機能を管理する仮想通信機能管理ノードと、１以上の方式で当該仮想化資源各々を管理する１以上の仮想化資源管理ノードと、当該仮想化資源全体の管理を行う全体管理ノードとを備える管理システムの動作方法である管理方法であって、
   前記仮想通信機能管理ノードは、前記仮想サーバを前記仮想化資源上で実現するための詳細情報を保持する保持手段を備え、
   前記仮想化資源管理ノードが、
   前記仮想化資源の使用状況を監視する監視ステップと、
   前記仮想化資源における、前記仮想サーバの生成に必要な資源の予約の要求を受け付けて予約を行う予約ステップと、
   前記予約ステップにおいて予約された前記仮想サーバの生成に必要な資源上に当該仮想サーバを生成させる要求を受け付けて当該仮想サーバを生成する仮想サーバ生成ステップと、
   前記仮想通信機能管理ノードが、
   前記全体管理ノードに対して、前記保持手段に保持された前記詳細情報を出力する詳細情報出力ステップと、
   前記全体管理ノードが、
   前記物理サーバでの仮想サーバの生成を伴う前記通信処理の機能に係る要求を受け付ける要求受付ステップと、
   前記仮想通信機能管理ノードから前記詳細情報を入力し、入力した詳細情報を前記仮想化資源管理ノードによる仮想化資源の管理方式に応じて書き換えて、書き換えた詳細情報を用いて、前記仮想化資源管理ノードに対して、前記予約ステップにおいて予約された前記必要な資源上に当該仮想サーバを生成させる要求を行う仮想サーバ生成要求ステップと、
   前記管理システムが、前記要求受付ステップにおいて受け付けられた要求、及び前記監視ステップにおいて監視された前記仮想化資源の使用状況に基づいて、前記仮想サーバの生成に必要な資源を算出して、前記仮想化資源管理ノードに対して前記予約を要求する予約要求ステップと、
   を含む管理方法。
8. 通信処理を実行する仮想サーバが生成される物理サーバを含む仮想化資源を含んで構成される通信システムに含まれると共に、当該仮想サーバが有する通信処理を実行する機能を管理する仮想通信機能管理ノードと、１以上の方式で当該仮想化資源各々を管理する１以上の仮想化資源管理ノードと、当該仮想化資源全体の管理を行う全体管理ノードとを備える管理システムにおける全体管理ノードの動作方法である管理方法であって、
   前記物理サーバでの仮想サーバの生成を伴う前記通信処理の機能に係る要求を受け付ける要求受付ステップと、
   前記仮想通信機能管理ノードから、仮想サーバを前記仮想化資源上で実現するための詳細情報を入力し、入力した詳細情報を前記仮想化資源管理ノードによる仮想化資源の管理方式に応じて書き換えて、書き換えた詳細情報を用いて、前記仮想化資源管理ノードに対して、前記仮想化資源における、前記仮想サーバの生成に必要な、予約された資源上に当該仮想サーバを生成させる要求を行う仮想サーバ生成要求ステップと、
   を含む管理方法。

Images