ホーム > 特許ランキング > 株式会社ＮＴＴドコモ
知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】6196322
(24)【登録日】2017年8月25日
(45)【発行日】2017年9月13日
(54)【発明の名称】管理システム、仮想通信機能管理ノード及び管理方法
(51)【国際特許分類】
H04L 12/70 20130101AFI20170904BHJP
G06F 9/46 20060101ALI20170904BHJP
G06F 9/50 20060101ALI20170904BHJP
【ＦＩ】
H04L12/70 D
G06F9/46 350
G06F9/46 462A
H04L12/70 100Z
【請求項の数】4
【全頁数】37
(21)【出願番号】特願2015-554996(P2015-554996)
(86)(22)【出願日】2014年12月25日
(86)【国際出願番号】JP2014084305
(87)【国際公開番号】WO2015099035
(87)【国際公開日】20150702
【審査請求日】2016年5月10日
(31)【優先権主張番号】特願2013-272420(P2013-272420)
(32)【優先日】2013年12月27日
(33)【優先権主張国】JP
(73)【特許権者】
【識別番号】392026693
【氏名又は名称】株式会社ＮＴＴドコモ
(74)【代理人】
【識別番号】100088155
【弁理士】
【氏名又は名称】長谷川 芳樹
(74)【代理人】
【識別番号】100113435
【弁理士】
【氏名又は名称】黒木 義樹
(74)【代理人】
【識別番号】100121980
【弁理士】
【氏名又は名称】沖山 隆
(74)【代理人】
【識別番号】100128107
【弁理士】
【氏名又は名称】深石 賢治
(72)【発明者】
【氏名】岩科 滋
(72)【発明者】
【氏名】清水 敬司
(72)【発明者】
【氏名】田村 基
(72)【発明者】
【氏名】中村 哲也
(72)【発明者】
【氏名】浅羽 英則
(72)【発明者】
【氏名】カーン アシック
(72)【発明者】
【氏名】山崎 敬広
(72)【発明者】
【氏名】山▲崎▼ 健生
(72)【発明者】
【氏名】トリエイ マルケース ジョアン
(72)【発明者】
【氏名】ペレズ カパロス ダビッド
(72)【発明者】
【氏名】ソウビル バートランド
【審査官】
速水 雄太
(56)【参考文献】
【文献】
ETSI GS NFV 002 V1.1.1(2013-10)，２０１３年１０月，ＵＲＬ，http://www.etsi.org/deliver/etsi_gs/nfv/001_099/002/01.01.01_60/gs_nfv002v010101p.pdf
【文献】
Network Functions Virtualisation - Update White Paper Issue 1，２０１３年１０月，ＵＲＬ，https://portal.etsi.org/nfv/nfv_white_paper2.pdf
(58)【調査した分野】（Int.Cl.，ＤＢ名）
Ｈ０４Ｌ １２／７０
Ｇ０６Ｆ ９／４６
Ｇ０６Ｆ ９／５０
(57)【特許請求の範囲】
【請求項1】
通信処理を実行する仮想サーバが生成される物理サーバを含む仮想化資源を含んで構成される通信システムに含まれると共に、当該仮想サーバが有する通信処理を実行する機能を管理する仮想通信機能管理ノードと、当該仮想化資源各々を管理する仮想化資源管理ノードと、当該仮想化資源全体の管理を行う全体管理ノードとを備える管理システムであって、
前記仮想化資源管理ノードは、
前記仮想化資源の使用状況を監視する監視手段と、
前記仮想化資源における、前記仮想サーバの生成に必要な資源の予約の要求を受け付けて予約を行う予約手段と、
前記予約手段によって予約された前記仮想サーバの生成に必要な資源上に当該仮想サーバを生成させる要求を受け付けて当該仮想サーバを生成する仮想サーバ生成手段と、を備え、
前記全体管理ノードは、前記物理サーバでの仮想サーバの生成を伴う前記通信処理の機能に係る要求を受け付ける要求受付手段を備え、
前記管理システムは、前記要求受付手段によって受け付けられた要求、及び前記監視手段によって監視された前記仮想化資源の使用状況に基づいて、前記仮想サーバの生成に必要な資源を算出して、前記仮想化資源管理ノードに対して前記予約を要求する予約要求手段と、
前記仮想通信機能管理ノードは、
前記仮想サーバを前記仮想化資源上で実現するための詳細情報を保持する保持手段と、
前記仮想化資源管理ノードに対して、前記保持手段に保持された前記詳細情報を用いて、前記予約手段によって予約された前記必要な資源上に当該仮想サーバを生成させる要求を行う仮想サーバ生成要求手段と、を備え、
前記管理システムは、互いに異なる方式で前記仮想化資源各々を管理する複数の仮想化資源管理ノードを備え、
前記仮想サーバ生成要求手段は、前記仮想化資源管理ノードによる仮想化資源の管理方式に応じて前記詳細情報を書き換えて、前記仮想サーバを生成させる要求を行う、管理システム。
前記仮想化資源管理ノードは、
前記仮想化資源の使用状況を監視する監視手段と、
前記仮想化資源における、前記仮想サーバの生成に必要な資源の予約の要求を受け付けて予約を行う予約手段と、
前記予約手段によって予約された前記仮想サーバの生成に必要な資源上に当該仮想サーバを生成させる要求を受け付けて当該仮想サーバを生成する仮想サーバ生成手段と、を備え、
前記全体管理ノードは、前記物理サーバでの仮想サーバの生成を伴う前記通信処理の機能に係る要求を受け付ける要求受付手段を備え、
前記管理システムは、前記要求受付手段によって受け付けられた要求、及び前記監視手段によって監視された前記仮想化資源の使用状況に基づいて、前記仮想サーバの生成に必要な資源を算出して、前記仮想化資源管理ノードに対して前記予約を要求する予約要求手段と、
前記仮想通信機能管理ノードは、
前記仮想サーバを前記仮想化資源上で実現するための詳細情報を保持する保持手段と、
前記仮想化資源管理ノードに対して、前記保持手段に保持された前記詳細情報を用いて、前記予約手段によって予約された前記必要な資源上に当該仮想サーバを生成させる要求を行う仮想サーバ生成要求手段と、を備え、
前記管理システムは、互いに異なる方式で前記仮想化資源各々を管理する複数の仮想化資源管理ノードを備え、
前記仮想サーバ生成要求手段は、前記仮想化資源管理ノードによる仮想化資源の管理方式に応じて前記詳細情報を書き換えて、前記仮想サーバを生成させる要求を行う、管理システム。
【請求項2】
通信処理を実行する仮想サーバが生成される物理サーバを含む仮想化資源を含んで構成される通信システムに含まれると共に、当該仮想サーバが有する通信処理を実行する機能を管理する仮想通信機能管理ノードと、当該仮想化資源各々を管理する仮想化資源管理ノードと、当該仮想化資源全体の管理を行う全体管理ノードとを備える管理システムにおける仮想通信機能管理ノードであって、
前記仮想サーバを前記仮想化資源上で実現するための詳細情報を保持する保持手段と、
前記仮想化資源管理ノードに対して、前記保持手段に保持された前記詳細情報を用いて、前記仮想化資源における、前記仮想サーバの生成に必要な、予約された資源上に当該仮想サーバを生成させる要求を行う仮想サーバ生成要求手段と、を備え、
前記管理システムは、互いに異なる方式で前記仮想化資源各々を管理する複数の仮想化資源管理ノードを備え、
前記仮想サーバ生成要求手段は、前記仮想化資源管理ノードによる仮想化資源の管理方式に応じて前記詳細情報を書き換えて、前記仮想サーバを生成させる要求を行う、仮想通信機能管理ノード。
前記仮想サーバを前記仮想化資源上で実現するための詳細情報を保持する保持手段と、
前記仮想化資源管理ノードに対して、前記保持手段に保持された前記詳細情報を用いて、前記仮想化資源における、前記仮想サーバの生成に必要な、予約された資源上に当該仮想サーバを生成させる要求を行う仮想サーバ生成要求手段と、を備え、
前記管理システムは、互いに異なる方式で前記仮想化資源各々を管理する複数の仮想化資源管理ノードを備え、
前記仮想サーバ生成要求手段は、前記仮想化資源管理ノードによる仮想化資源の管理方式に応じて前記詳細情報を書き換えて、前記仮想サーバを生成させる要求を行う、仮想通信機能管理ノード。
【請求項3】
通信処理を実行する仮想サーバが生成される物理サーバを含む仮想化資源を含んで構成される通信システムに含まれると共に、当該仮想サーバが有する通信処理を実行する機能を管理する仮想通信機能管理ノードと、当該仮想化資源各々を管理する仮想化資源管理ノードと、当該仮想化資源全体の管理を行う全体管理ノードとを備える管理システムの動作方法である管理方法であって、
前記仮想通信機能管理ノードは、前記仮想サーバを前記仮想化資源上で実現するための詳細情報を保持する保持手段を備え、
前記仮想化資源管理ノードが、
前記仮想化資源の使用状況を監視する監視ステップと、
前記仮想化資源における、前記仮想サーバの生成に必要な資源の予約の要求を受け付けて予約を行う予約ステップと、
前記予約ステップにおいて予約された前記仮想サーバの生成に必要な資源上に当該仮想サーバを生成させる要求を受け付けて当該仮想サーバを生成する仮想サーバ生成ステップと、
前記全体管理ノードが、前記物理サーバでの仮想サーバの生成を伴う前記通信処理の機能に係る要求を受け付ける要求受付ステップと、
前記管理システムが、前記要求受付ステップにおいて受け付けられた要求、及び前記監視ステップにおいて監視された前記仮想化資源の使用状況に基づいて、前記仮想サーバの生成に必要な資源を算出して、前記仮想化資源管理ノードに対して前記予約を要求する予約要求ステップと、
前記仮想通信機能管理ノードが、
前記仮想化資源管理ノードに対して、前記保持手段に保持された前記詳細情報を用いて、前記予約ステップにおいて予約された前記必要な資源上に当該仮想サーバを生成させる要求を行う仮想サーバ生成要求ステップと、
を含み、
前記管理システムは、互いに異なる方式で前記仮想化資源各々を管理する複数の仮想化資源管理ノードを備え、
前記仮想サーバ生成要求ステップにおいて、前記仮想化資源管理ノードによる仮想化資源の管理方式に応じて前記詳細情報を書き換えて、前記仮想サーバを生成させる要求を行う、管理方法。
前記仮想通信機能管理ノードは、前記仮想サーバを前記仮想化資源上で実現するための詳細情報を保持する保持手段を備え、
前記仮想化資源管理ノードが、
前記仮想化資源の使用状況を監視する監視ステップと、
前記仮想化資源における、前記仮想サーバの生成に必要な資源の予約の要求を受け付けて予約を行う予約ステップと、
前記予約ステップにおいて予約された前記仮想サーバの生成に必要な資源上に当該仮想サーバを生成させる要求を受け付けて当該仮想サーバを生成する仮想サーバ生成ステップと、
前記全体管理ノードが、前記物理サーバでの仮想サーバの生成を伴う前記通信処理の機能に係る要求を受け付ける要求受付ステップと、
前記管理システムが、前記要求受付ステップにおいて受け付けられた要求、及び前記監視ステップにおいて監視された前記仮想化資源の使用状況に基づいて、前記仮想サーバの生成に必要な資源を算出して、前記仮想化資源管理ノードに対して前記予約を要求する予約要求ステップと、
前記仮想通信機能管理ノードが、
前記仮想化資源管理ノードに対して、前記保持手段に保持された前記詳細情報を用いて、前記予約ステップにおいて予約された前記必要な資源上に当該仮想サーバを生成させる要求を行う仮想サーバ生成要求ステップと、
を含み、
前記管理システムは、互いに異なる方式で前記仮想化資源各々を管理する複数の仮想化資源管理ノードを備え、
前記仮想サーバ生成要求ステップにおいて、前記仮想化資源管理ノードによる仮想化資源の管理方式に応じて前記詳細情報を書き換えて、前記仮想サーバを生成させる要求を行う、管理方法。
【請求項4】
通信処理を実行する仮想サーバが生成される物理サーバを含む仮想化資源を含んで構成される通信システムに含まれると共に、当該仮想サーバが有する通信処理を実行する機能を管理する仮想通信機能管理ノードと、当該仮想化資源各々を管理する仮想化資源管理ノードと、当該仮想化資源全体の管理を行う全体管理ノードとを備える管理システムにおける仮想通信機能管理ノードの動作方法である管理方法であって、
前記仮想通信機能管理ノードは、前記仮想サーバを前記仮想化資源上で実現するための詳細情報を保持する保持手段を備え、
前記仮想化資源管理ノードに対して、前記保持手段に保持された前記詳細情報を用いて、前記仮想化資源における、前記仮想サーバの生成に必要な、予約された資源上に当該仮想サーバを生成させる要求を行う仮想サーバ生成要求ステップ、
を含み、
前記管理システムは、互いに異なる方式で前記仮想化資源各々を管理する複数の仮想化資源管理ノードを備え、
前記仮想サーバ生成要求ステップにおいて、前記仮想化資源管理ノードによる仮想化資源の管理方式に応じて前記詳細情報を書き換えて、前記仮想サーバを生成させる要求を行う、管理方法。
前記仮想通信機能管理ノードは、前記仮想サーバを前記仮想化資源上で実現するための詳細情報を保持する保持手段を備え、
前記仮想化資源管理ノードに対して、前記保持手段に保持された前記詳細情報を用いて、前記仮想化資源における、前記仮想サーバの生成に必要な、予約された資源上に当該仮想サーバを生成させる要求を行う仮想サーバ生成要求ステップ、
を含み、
前記管理システムは、互いに異なる方式で前記仮想化資源各々を管理する複数の仮想化資源管理ノードを備え、
前記仮想サーバ生成要求ステップにおいて、前記仮想化資源管理ノードによる仮想化資源の管理方式に応じて前記詳細情報を書き換えて、前記仮想サーバを生成させる要求を行う、管理方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、通信システムの管理に関する管理システム、仮想通信機能管理ノード及び管理方法に関する。【背景技術】
【0002】
従来から、様々な目的で、サーバ仮想化技術によってコンピュータを仮想マシン（ＶＭ：Virtual Machine）とすることが行われている。また、この技術によって、移動体通信網（移動通信ネットワーク）のコアネットワークにおけるノードを仮想マシンとすることが検討されている（例えば、非特許文献１参照）。【先行技術文献】
【非特許文献】
【0003】
【非特許文献1】ETSI Group Specification(ETSI GS NFV 002 v1.1.1(2013.10)) Network Functions Virtualization(NFV); Architectural Framework
【発明の概要】
【発明が解決しようとする課題】
【0004】
移動体通信網のコアネットワークにおけるノードは、例えば、仮想マシン上の仮想化された通信機能であるＶＮＦ（Virtual Network Function）によって実現される。上記のような移動体通信網の管理を、ＶＮＦＭ（ＶＮＦ Manager）、ＶＩＭ（Virtual Infrastructure Manager）及びオーケストレータ（Orchestrator）の３つの機能エンティティで行うことが考えられる。ＶＮＦＭは、ＶＮＦを仮想マシン上で実現するための詳細情報を保持し、ＶＮＦの管理機能を有する。ＶＩＭは、仮想マシンが実現される物理サーバ（物理的なサーバ、仮想化資源）の状況を監視し、ＶＮＦＭ又はオーケストレータからの制御によって物理サーバ上に仮想マシン及びＶＮＦを生成、削除する。【0005】
なお、物理サーバは、通常、データセンタに複数まとめて配置されており、ＶＩＭは、１つ以上のデータセンタに設置された物理サーバ群に対する処理を行う。また、データセンタにおける物理サーバ群の管理（資源管理）は、ＯＰＥＮＳＴＡＣＫ（登録商標）あるいはｖＣｅｎｔｅｒといった異なる実装方式で行われている。ＶＩＭは、データセンタにおける実装方式毎に設けられている。オーケストレータは、複数のＶＩＭにまたがる全体の資源管理を行う。【0006】
ところで、現在の仮想化されていない移動体通信網を構成するノード（通信ノード）は、そのノードを提供するベンダによって、そのノードの内部構造が異なっている。その内部構造は、ベンダ毎の設計ノウハウとなっている。【0007】
このノードをＶＮＦとして仮想化する際には、ＶＩＭが、仮想化資源の予約を行い、その後、予約した仮想化資源上に仮想マシンを生成すると共にＶＮＦを仮想化マシン上に生成する。また、ＶＮＦを仮想化マシン上に生成するためには、ＶＮＦＭが保持する、ＶＮＦを仮想マシン上で実現するための詳細情報が必要となる。この詳細情報は、上記の仮想化されていないノードの内部構造に相当するものであり、ベンダ毎の設計ノウハウを含む。【0008】
上述した３つの機能エンティティは、互いに異なるベンダにより提供されることがある。ＶＮＦを実現する際に、ＶＮＦＭが保持する詳細情報が、例えば、オーケストレータのような他の機能エンティティに出力される構成では、以下のような問題がある。即ち、オーケストレータとＶＮＦＭとが異なるベンダから提供される場合に、ＶＮＦの詳細情報（内部構造）がオーケストレータベンダに伝わり、ノウハウが漏洩してしまう懸念がある。そのため、マルチベンダの阻害要因となるおそれがある。【0009】
本発明は、上記に鑑みてなされたものであり、通信処理を実行する仮想サーバを仮想化資源上において実現するための詳細情報の漏洩を防止することができる管理システム、仮想通信機能管理ノード及び管理方法を提供することを目的とする。【課題を解決するための手段】
【0010】
上記目的を達成するために、本発明の一実施形態に係る管理システムは、通信処理を実行する仮想サーバが生成される物理サーバを含む仮想化資源を含んで構成される通信システムに含まれると共に、当該仮想サーバが有する通信処理を実行する機能を管理する仮想通信機能管理ノードと、当該仮想化資源各々を管理する仮想化資源管理ノードと、当該仮想化資源全体の管理を行う全体管理ノードとを備える管理システムであって、仮想化資源管理ノードは、前記仮想化資源の使用状況を監視する監視手段と、仮想化資源における、仮想サーバの生成に必要な資源の予約の要求を受け付けて予約を行う予約手段と、予約手段によって予約された仮想サーバの生成に必要な資源上に当該仮想サーバを生成させる要求を受け付けて当該仮想サーバを生成する仮想サーバ生成手段と、を備え、全体管理ノードは、物理サーバでの仮想サーバの生成を伴う通信処理の機能に係る要求を受け付ける要求受付手段を備え、管理システムは、要求受付手段によって受け付けられた要求、及び監視手段によって監視された仮想化資源の使用状況に基づいて、仮想サーバの生成に必要な資源を算出して、仮想化資源管理ノードに対して予約を要求する予約要求手段と、仮想通信機能管理ノードは、仮想サーバを仮想化資源上で実現するための詳細情報を保持する保持手段と、仮想化資源管理ノードに対して、保持手段に保持された詳細情報を用いて、予約手段によって予約された必要な資源上に当該仮想サーバを生成させる要求を行う仮想サーバ生成要求手段と、を備える。【0011】
本発明の一実施形態に係る管理システムでは、仮想通信機能管理ノードによって自身が保持する詳細情報が用いられて、仮想化資源管理ノードに対して仮想サーバを生成させる要求が行われる。従って、詳細情報を仮想通信機能管理ノードから全体管理ノードに通知する必要がなく、当該仮想サーバの生成が行われる。即ち、本発明の一実施形態に係る管理システムによれば、通信処理を実行する仮想サーバを仮想化資源上において実現するための詳細情報の漏洩を防止することができる。【0012】
管理システムは、互いに異なる方式で仮想化資源各々を管理する複数の仮想化資源管理ノードを備え、仮想サーバ生成要求手段は、仮想化資源管理ノードによる仮想化資源の管理方式に応じて詳細情報を書き換えて、仮想サーバを生成させる要求を行う。この構成によれば、仮想化資源管理ノード毎に仮想化資源が異なる方式で管理されている場合であっても適切に仮想サーバの生成が行われる。
【0013】
上記の通信システムに含まれる仮想通信機能管理ノードは、それら自体が新規な構成を有しており発明に相当する。即ち、本発明の一実施形態に係る仮想通信機能管理ノードは、通信処理を実行する仮想サーバが生成される物理サーバを含む仮想化資源を含んで構成される通信システムに含まれると共に、当該仮想サーバが有する通信処理を実行する機能を管理する仮想通信機能管理ノードと、当該仮想化資源各々を管理する仮想化資源管理ノードと、当該仮想化資源全体の管理を行う全体管理ノードとを備える管理システムにおける仮想通信機能管理ノードであって、仮想サーバを仮想化資源上で実現するための詳細情報を保持する保持手段と、仮想化資源管理ノードに対して、保持手段に保持された詳細情報を用いて、仮想化資源における、仮想サーバの生成に必要な、予約された資源上に当該仮想サーバを生成させる要求を行う仮想サーバ生成要求手段と、を備え、管理システムは、互いに異なる方式で仮想化資源各々を管理する複数の仮想化資源管理ノードを備え、仮想サーバ生成要求手段は、仮想化資源管理ノードによる仮想化資源の管理方式に応じて詳細情報を書き換えて、仮想サーバを生成させる要求を行う。
【0014】
ところで、本発明は、上記のように管理システム及び仮想通信機能管理ノードの発明として記述できる他に、以下のように管理方法の発明としても記述することができる。これはカテゴリが異なるだけで、実質的に同一の発明であり、同様の作用及び効果を奏する。【0015】
即ち、本発明の一実施形態に係る管理方法は、通信処理を実行する仮想サーバが生成される物理サーバを含む仮想化資源を含んで構成される通信システムに含まれると共に、当該仮想サーバが有する通信処理を実行する機能を管理する仮想通信機能管理ノードと、当該仮想化資源各々を管理する仮想化資源管理ノードと、当該仮想化資源全体の管理を行う全体管理ノードとを備える管理システムの動作方法である管理方法であって、仮想通信機能管理ノードは、仮想サーバを仮想化資源上で実現するための詳細情報を保持する保持手段を備え、仮想化資源管理ノードが、仮想化資源の使用状況を監視する監視ステップと、仮想化資源における、仮想サーバの生成に必要な資源の予約の要求を受け付けて予約を行う予約ステップと、予約ステップにおいて予約された仮想サーバの生成に必要な資源上に当該仮想サーバを生成させる要求を受け付けて当該仮想サーバを生成する仮想サーバ生成ステップと、全体管理ノードが、物理サーバでの仮想サーバの生成を伴う通信処理の機能に係る要求を受け付ける要求受付ステップと、管理システムが、要求受付ステップにおいて受け付けられた要求、及び監視ステップにおいて監視された仮想化資源の使用状況に基づいて、仮想サーバの生成に必要な資源を算出して、仮想化資源管理ノードに対して予約を要求する予約要求ステップと、仮想通信機能管理ノードが、仮想化資源管理ノードに対して、保持手段に保持された詳細情報を用いて、予約ステップにおいて予約された必要な資源上に当該仮想サーバを生成させる要求を行う仮想サーバ生成要求ステップと、を含み、管理システムは、互いに異なる方式で仮想化資源各々を管理する複数の仮想化資源管理ノードを備え、仮想サーバ生成要求ステップにおいて、仮想化資源管理ノードによる仮想化資源の管理方式に応じて詳細情報を書き換えて、仮想サーバを生成させる要求を行う。
【0016】
また、本発明の一実施形態に係る管理方法は、通信処理を実行する仮想サーバが生成される物理サーバを含む仮想化資源を含んで構成される通信システムに含まれると共に、当該仮想サーバが有する通信処理を実行する機能を管理する仮想通信機能管理ノードと、当該仮想化資源各々を管理する仮想化資源管理ノードと、当該仮想化資源全体の管理を行う全体管理ノードとを備える管理システムにおける仮想通信機能管理ノードの動作方法である管理方法であって、仮想通信機能管理ノードは、仮想サーバを仮想化資源上で実現するための詳細情報を保持する保持手段を備え、仮想化資源管理ノードに対して、保持手段に保持された詳細情報を用いて、仮想化資源における、仮想サーバの生成に必要な、予約された資源上に当該仮想サーバを生成させる要求を行う仮想サーバ生成要求ステップ、を含み、管理システムは、互いに異なる方式で仮想化資源各々を管理する複数の仮想化資源管理ノードを備え、仮想サーバ生成要求ステップにおいて、仮想化資源管理ノードによる仮想化資源の管理方式に応じて詳細情報を書き換えて、仮想サーバを生成させる要求を行う。
【発明の効果】
【0017】
本発明の一実施形態によれば、詳細情報を仮想通信機能管理ノードから全体管理ノードに通知する必要がなく仮想サーバの生成が行われるため、通信処理を実行する仮想サーバを仮想化資源上において実現するための詳細情報の漏洩を防止することができる。【図面の簡単な説明】
【0018】
【図1】本発明の実施形態に係る管理システムの構成、及び当該管理システムを含む移動体通信システムを示す図である。
【図2】本発明の実施形態に係る管理システムの機能構成を示す図である。
【図3】本発明の実施形態に係る管理システムに含まれるノードのハードウェア構成を示す図である。
【図4】管理システムで用いられる情報を格納するテーブルである。
【図5】管理システムで用いられる情報を格納するテーブルである。
【図6】管理システムで用いられる情報を格納するテーブルである。
【図7】管理システムで用いられる情報を格納するテーブルである。
【図8】管理システムで用いられる情報を格納するテーブルである。
【図9】管理システムで用いられる情報を格納するテーブルである。
【図10】管理システムで用いられる情報を格納するテーブルである。
【図11】管理システムで用いられる情報を格納するテーブルである。
【図12】管理システムで用いられる情報を格納するテーブルである。
【図13】管理システムで用いられる情報を格納するテーブルである。
【図14】管理システムで用いられる情報を格納するテーブルである。
【図15】本発明の実施形態に係る管理システムでインスタンシエーション時に実行される処理（管理方法）を示すシーケンス図である。
【図16】本発明の実施形態に係る管理システムでインスタンシエーション時に実行される処理（管理方法）を示すシーケンス図である。
【図17】本発明の実施形態に係る管理システムでオートヒーリング時に実行される処理（管理方法）を示すシーケンス図である。
【図18】本発明の実施形態に係る管理システムでオートヒーリング時に実行される処理（管理方法）を示すシーケンス図である。
【図19】本発明の実施形態に係る管理システムでスケールアウト時に実行される処理（管理方法）を示すシーケンス図である。
【図20】本発明の実施形態に係る管理システムでスケールアウト時に実行される処理（管理方法）を示すシーケンス図である。
【図21】本発明の実施形態に係る管理システムでスケールイン時に実行される処理（管理方法）を示すシーケンス図である。
【図22】本発明の実施形態に係る管理システムでスケールイン時に実行される処理（管理方法）を示すシーケンス図である。
【図23】インスタンシエーション、スケールアウト及びスケールインを概念的に示す図である。
【図24】増強単位の判断を行う処理を示すフローチャートである。
【図25】削減単位の判断を行う処理を示すフローチャートである。
【図26】内部機能部単位に増強又は削減するのに必要な情報を格納するテーブルである。
【図27】仮想化機能の性能増減単位と実施形態との関係を示した表である。
【図28】本発明の実施形態のバリエーションを示す図である。
【発明を実施するための形態】
【0019】
以下、図面と共に本発明に係る管理システム、仮想通信機能管理ノード及び管理方法の実施形態について詳細に説明する。なお、図面の説明においては同一要素には同一符号を付し、重複する説明を省略する。【0020】
図１に本実施形態に係る管理システム１０を含む移動体通信システム１の構成を示す。移動体通信システム１は、図示しない移動通信端末（移動機）に移動体通信の機能を提供するシステムである。移動通信端末は、ユーザにより用いられて移動体通信システム（移動体通信網）に無線通信によって接続して移動体通信を行う装置である。具体的には、移動通信端末は、携帯電話機等に相当する。移動通信端末は、例えば、移動体通信システム１を介して対向ノードとの間で呼接続を確立して通信を行う。対向ノードは、例えば、別の移動通信端末や移動通信端末に様々なサービスを提供するサーバ装置、あるいは他の通信網に接続するための装置（例えば、ＭＭＥ（Mobility Management Entity）、Ｓ−ＧＷ（Serving Gateway）、Ｐ−ＧＷ（PDN Gateway））等に相当する。移動通信端末は、例えば、移動通信端末のユーザが移動体通信システム１の通信事業者と契約することによって移動体通信を行うことが可能になる。なお、移動通信端末は、従来の移動通信端末と同様のものでよい。【0021】
図１に示すように管理システム１０は、オーケストレータ２０と、ＶＮＦＭ３０と、ＶＩＭ４０とを含んで構成されている。また、移動体通信システム１には、ＯＳＳ／ＢＳＳ（Operations Support System／Business Support System）５０と、ＮＦＶＩ（ＮＦＶ Infrastructure）６０と、ＶＮＦ（Virtual Network Function）７０と、ＥＭＳ（Element Management System）８０とを含んで構成されている。これらの構成要素は、移動体通信システム１（移動体通信網）のコアネットワークを構成するものである。なお、互いに情報の送受信が必要な構成要素間は、有線等で接続されており情報の送受信が可能となっている。【0022】
本実施形態に係る移動体通信システム１は、物理サーバ上に実現される仮想マシンにおいて動作する仮想サーバによって移動通信端末に対して通信機能が提供される。即ち、移動体通信システム１は、仮想化された移動体通信ネットワークである。通信機能は、仮想マシンによって当該通信機能に応じた通信処理を実行することで移動通信端末に対して提供される。【0023】
ＮＦＶＩ６０は、仮想化環境を構成する物理資源、仮想化層、仮想化資源である。物理資源には、計算資源、記憶資源、伝送資源が含まれる。仮想化層は、物理資源を仮想化しＶＮＦ７０（ＡＰＬ）に提供する（例えば、ハイパーバイザー）。仮想化資源は、ＶＮＦ７０に提供される仮想化されたインフラ資源である。即ち、ＮＦＶＩ６０は、移動体通信システム１において通信処理を行う物理的なサーバ装置である物理サーバを含んで構成されている仮想化資源である。物理サーバは、ＣＰＵ（コア、プロセッサ）、メモリ、及びハードディスク等の記憶手段を備えて構成される。通常、ＮＦＶＩ６０を構成する物理サーバは、複数まとめてデータセンタ（ＤＣ）等の拠点に配置される。データセンタでは、配置された物理サーバがデータセンタ内部のネットワークによって接続されており、互いに情報の送受信を行うことができるようになっている。また、移動体通信システム１には、複数のデータセンタが設けられている。データセンタ間はネットワークで接続されており、異なるデータセンタに設けられた物理サーバはそのネットワークを介して互いに情報の送受信を行うことができる。【0024】
ＶＮＦ７０は、通信処理を実行する仮想的な通信処理ノードである仮想サーバ（が有する通信処理を実行する機能）である。ＶＮＦ７０は、ＮＦＶＩ６０において実現される。ＶＮＦ７０は、例えば、仮想マシン（ＶＭ）技術が利用されて、ＮＦＶＩ６０が備えるＣＰＵがＶＮＦ７０用に割り当てられて、割り当てられたＣＰＵ上において仮想マシンが実現され、仮想マシン上でプログラムが実行されることにより実現される。ＶＮＦ７０は、通常、実行する通信処理に応じて生成（実現）される。また、ＶＮＦ７０は、その構成要素であるＶＮＦＣ（Virtual Network Function Components）を複数含むものとして構成されていてもよい。【0025】
移動体通信システム１には、１以上（あるいは複数）のＶＮＦ７０が含まれる。ＶＮＦ７０は、ＩＭＳでは、ＣＳＣＦ（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）等のノードに相当する。【0026】
ＥＭＳ８０は、ＶＮＦ７０を監視及び制御するノードである。ＥＭＳ８０も、ＶＮＦ７０と同様にＮＦＶＩ６０において仮想的に実現される。ＥＭＳ８０は、ＶＮＦ７０に対応付けられて（例えば、図１に示すようにＶＮＦ７０と一対一の関係で）生成される。ＥＭＳ８０は、対応付けられたＶＮＦ７０の監視及び制御を行う。ＥＭＳ８０は、ＶＮＦ７０のＦＣＡＰＳ（障害、構成、課金、性能、セキュリティ）管理を行う。ＥＭＳ８０は、前述の説明のように仮想的に実現しても良いし、ＦＣＡＰＳ管理を行う上で管理の複雑性を避けるために物理的に実現しても良い。【0027】
ＯＳＳ／ＢＳＳ５０は、移動体通信システム１におけるサービス管理を行い、管理システム１０に移動体通信システム１での通信機能に係る指示を行うノードである。例えば、ＯＳＳ／ＢＳＳ５０は、管理システム１０に対して、新たな通信機能（通信サービス）を起動するように指示を行う。また、ＯＳＳ／ＢＳＳ５０は、ＥＭＳ８０から情報を受け取り、その情報に基づいて管理システム１０又はＥＭＳ８０に対して指示を行う。また、ＯＳＳ／ＢＳＳ５０は、移動体通信システム１に係る通信事業者によって操作されえる。【0028】
管理システム１０の構成要素であるオーケストレータ２０は、仮想化資源であるＮＦＶＩ６０全体の管理を行う全体管理ノード（機能エンティティ）である。オーケストレータ２０は、ＯＳＳ／ＢＳＳ５０（のうちのＯＳＳ５１）からの指示を受信し、当該指示に応じた処理を行う。オーケストレータ２０は、インフラと通信サービスの移動体通信網の仮想化資源全体にわたる管理を行う。オーケストレータ２０は、複数のＶＮＦ７０から構成される通信サービスをＶＮＦＭ３０及びＶＩＭ４０を経由して適切な場所に実現する。例えば、サービスのライフサイクル管理（具体的には例えば、生成、更新、スケール制御、イベント収集）、移動体通信網内全体にわたる資源の分散・予約・割当管理、サービス・インスタンス管理、及びポリシー管理（具体的には例えば、リソースの予約・割当、地理・法令等に基づく最適配置）を行う。【0029】
管理システム１０の構成要素であるＶＮＦＭ３０は、ＶＮＦ７０を管理する仮想通信機能管理ノード（機能エンティティ）である。ＶＮＦＭ３０は、移動体通信システム１に複数、設けられていてもよい。その場合、ＶＮＦ７０毎に管理されるＶＮＦＭ３０が予め定められていてもよい。ＶＮＦＭ３０は、ＶＮＦ７０（ＡＰＬ）のライフサイクル管理を行う。ＶＮＦＭ３０は、ＶＮＦ７０の仮想化に関わる制御全般を行う。例えば、ＶＮＦ７０インスンタスの生成、更新、スケール制御、終了、オートヒーリング（自動ヒーリング）を行う。【0030】
管理システム１０の構成要素であるＶＩＭ４０は、ＮＦＶＩ６０におけるＶＮＦ７０が実現される単位の仮想化資源（インフラリソース）各々を管理する仮想化資源管理ノード（機能エンティティ）である。具体的には、資源の割当・更新・回収の管理、仮想資源と物理との関連付け、ハードウェア資源とＳＷ資源（ハイパーバイザー）一覧の管理を行う。通常、ＶＩＭ４０は、データセンタ（局舎）毎に管理を行う。仮想化資源の管理は、データセンタに応じた方式で行われえる。データセンタの管理方式（管理資源の実装方式）は、ＯＰＥＮＳＴＡＣＫやｖＣｅｎｔｅｒ等の種類がある。通常、ＶＩＭ４０は、データセンタの管理方式毎に設けられる。即ち、管理システム１０には、互いに異なる方式で、ＮＦＶＩ６０におけるＶＮＦ７０が実現される単位の仮想化資源各々を管理する複数のＶＩＭ４０が含まれる。なお、異なる管理方式で管理される仮想化資源の単位は、必ずしもデータセンタ単位でなくてもよい。【0031】
なお、オーケストレータ２０、ＶＮＦＭ３０及びＶＩＭ４０は、物理的なサーバ装置上でプログラムが実行されることにより実現される（但し仮想化上で実現されることを制限するものでは無く、管理系統を分離した上で、仮想化上で実現してもよい）。オーケストレータ２０、ＶＮＦＭ３０及びＶＩＭ４０は、それぞれ別々の物理的なサーバ装置で実現されていてもよいし、同じサーバ装置で実現されていてもよい。オーケストレータ２０、ＶＮＦＭ３０及びＶＩＭ４０（を実現するためのプログラム）は、別々のベンダから提供されていてもよい。【0032】
なお、上記アーキテクチャは、非特許文献１に記載されたものに準じたものである。また、移動体通信システム１には、移動体通信機能を実現するために、上記以外の構成要素が含まれていてもよい、例えば、移動体通信システム１には、基地局の装置及びオープンフローネットワーク（上記のような仮想化されたものも含む）等が含まれていてもよい。【0033】
引き続いて、管理システム１０が有する、本実施形態に係る機能を説明する。図２に示すようにオーケストレータ２０は、要求受付部２１と、予約要求部２２とを備える。要求受付部２１は、ＯＳＳ／ＢＳＳ５０（のＯＳＳ５１）から、ＮＦＶＩ６０に含まれる物理サーバでのＶＮＦ７０の生成を伴う通信処理の機能に係る要求を受け付ける要求受付手段である。【0034】
予約要求部２２は、要求受付部２１によって受け付けられた要求、及びＶＩＭ４０によって監視されたＮＦＶＩ６０の使用状況やＶＮＦＭ３０からの情報等に基づいて、ＶＮＦ７０の生成に必要な資源を算出して、ＶＩＭ４０に対してＮＦＶＩ６０におけるＶＮＦ７０の生成に必要な資源の予約を要求する予約要求手段である。【0035】
図２に示すようにＶＮＦＭ３０は、保持部３１と、仮想サーバ生成要求部３２とを備える。保持部３１は、ＶＮＦ７０をＮＦＶＩ６０上で実現するための詳細情報を保持する保持手段である。仮想サーバ生成要求部３２は、ＶＩＭ４０に対して、保持部３１に保持された詳細情報を用いて、ＮＦＶＩ６０において予約された必要な資源上にＶＮＦ７０を生成させる要求を行う仮想サーバ生成要求手段である。また、ＶＮＦＭ３０は、ＶＩＭ４０による仮想化資源（ＮＦＶＩ６０）の管理方式に応じて詳細情報を書き換えて、ＶＮＦ７０を生成させる要求を行うこととしてもよい。【0036】
図２に示すようにＶＩＭ４０は、監視部４１と、予約部４２と、仮想サーバ生成部４３とを備える。監視部４１は、ＮＦＶＩ６０の使用状況を監視する監視手段である。予約部４２は、ＮＦＶＩ６０におけるＶＮＦ７０の生成に必要な資源の予約の要求をオーケストレータ２０から受け付けて予約を行う予約手段である。仮想サーバ生成部４３は、予約部４２によって予約されたＶＮＦ７０の生成に必要な資源上に当該ＶＮＦ７０を生成させる要求をＶＮＦＭ３０から受け付けて当該ＶＮＦ７０を生成する仮想サーバ生成手段である。【0037】
以上が、管理システム１０が有する、本実施形態に係る機能である。なお、シーケンス図を用いた管理システム１０による処理の説明において、オーケストレータ２０、ＶＮＦＭ３０及びＶＩＭ４０の本実施形態に係る機能をより詳細に説明する。また、オーケストレータ２０、ＶＮＦＭ３０及びＶＩＭ４０には、上記の機能部に含まれない機能を有しているが、その機能の説明もシーケンス図を用いた管理システム１０による処理の説明に含まれる。【0038】
図３に本実施形態に係る管理システム１０に含まれるオーケストレータ２０、ＶＮＦＭ３０及びＶＩＭ４０を構成するサーバ装置のハードウェア構成を示す。図３に示すように当該サーバ装置は、ＣＰＵ１０１、主記憶装置であるＲＡＭ（Random Access Memory）１０２及びＲＯＭ（Read Only Memory）１０３、通信を行うための通信モジュール１０４、並びにハードディスク等の補助記憶装置１０５等のハードウェアを備えるコンピュータを含むものとして構成される。これらの構成要素がプログラム等により動作することにより、上述及び後述するオーケストレータ２０、ＶＮＦＭ３０及びＶＩＭ４０の機能が発揮される。なお、オーケストレータ２０、ＶＮＦＭ３０及びＶＩＭ４０は複数のサーバ装置からなるコンピュータシステムによって構成されていてもよい。また、移動体通信システム１に含まれる上記以外のノードも上記のハードウェア構成を有するサーバ装置によって実現されてもよい。以上が、本実施形態に係る管理システム１０の構成である。【0039】
引き続いて、図４〜図１４のテーブル及び図１５〜２２のシーケンス図を用いて、本実施形態に係る管理システム１０で実行される処理である管理方法を説明する。以下では、移動体通信システム１において、（１）インスタンシエーション（Instantiation）、（２）オートヒーリング（Auto-Healing）、（３）スケールアウト（Scale-Out）、（４）スケールイン（Scale-In）が行われる場合の処理を上記の場合毎に説明する。また、図２３に、インスタンシエーション、スケールアウト及びスケールインの概要を示す。【0040】
まず、図１５及び図１６のシーケンス図を用いて、（１）インスタンシエーションが行われる場合の処理を説明する。なお、図１６に示すシーケンス図は、図１５のシーケンス図と（時系列的に）連続するものである。インスタンシエーションとは、移動体通信システム１において、新たな通信サービス（通信機能）を提供可能とするため、当該通信サービスに応じた新たなＶＮＦ７０を生成することである。インスタンシエーションにより、移動体通信システム１において新たな通信サービスが提供される。【0041】
まず、オーケストレータ２０では、各ＶＩＭ４０に対して、資源使用状況問い合わせが行われる（Ｓ００１）。ＶＩＭ４０では、監視部４１によって当該資源使用状況問い合わせが受信される。監視部４１によってＶＩＭ４０の管理対象となっているＮＦＶＩ６０の資源使用状況が監視される。監視された結果得られた資源使用状況を示す情報が、資源使用状況問い合わせ応答として監視部４１からオーケストレータ２０に送信される（Ｓ００２、監視ステップ）。オーケストレータ２０では、当該情報が受信される。Ｓ００１及びＳ００２の処理は、ＶＩＭ４０毎に定期的に行われる。【0042】
この情報は、図４（ａ）の表Ｔ１に示すようにデータセンタ（ＤＣ）毎の情報であり、仮想マシン、ネットワーク（ＮＷ）の資源情報及び提供機能を示す情報が対応付けられたものである。即ち、この情報は、移動体通信システム１（移動体通信網）全体の資源の状態情報である。当該情報は、オーケストレータ２０が有するネットワーク全体資源情報データベースに常に保持される。【0043】
図４（ａ）の表Ｔ１における、使用可能帯域とは、データセンタとデータセンタ外部との間の（データセンタの出口の）通信経路の使用可能帯域である。使用可能外部アドレスとは、ＶＮＦ７０に付与可能な、ＶＮＦ７０が他のＶＮＦ７０又はＶＮＦ７０以外と通信を行うために必要なアドレスである。提供機能とは、データセンタが、専用のハードウェアあるいはソフトウェアによって提供できる通信に係る機能である。具体的には、高速パケット処理機能（例えば、Ｉｎｔｅｌ社のＤＰＤＫ）や仮想化層のバイパス技術の機能（例えば、ＳＲ−ＩＯＶ）等がある。【0044】
続いて、ＯＳＳ／ＢＳＳ５０（のＯＳＳ５１）から、オーケストレータ２０に対して通信サービスに係るサービス生成の要求（信号（１））が送信される。通信サービスは、例えば、音声通信、メール又は動画（リッチメディア）を送受信する通信である（送信するデータの種別毎に通信サービスが異なる）。この要求は、ＮＦＶＩ６０に含まれる物理サーバでのＶＮＦ７０の生成を伴う通信処理の機能に係る要求である。オーケストレータ２０では、要求受付部２１によって、当該信号が受信される（Ｓ００３、要求受付ステップ）。【0045】
当該信号には、生成サービスをユニークに識別する番号としてのサービスＩＤ、生成する通信サービス、性能条件及びネットワーク情報を示す情報が含まれる。具体的には、信号には、通信サービスに“通信サービス１”、性能条件に“１００”、ＮＷ（ネットワーク）条件には「ＤＣ１と５Ｇｂｐｓ以上の帯域で接続するＤＣ」を意味する“ＤＣ１接続、帯域５Ｇｂｐｓ以上”が含まれる（設定される）。【0046】
性能条件は、ＶＮＦ７０及びＶＮＦ７０が構成するサービスに対する制御（生成、増強、削減等）において能力を示すために正規化した指標値である。性能条件は、予めＯＳＳ５１とＶＮＦＭ３０との間で取り決められている。【0047】
続いて、信号に含まれる情報によって特定される通信サービスを構成するＶＮＦ７０（仮想化機能）及びＶＮＦＭ３０（管理機能）が、予めオーケストレータ２０に登録されている運用データより特定される。具体的には、運用データである図５（ａ）の表Ｔ２より、“通信サービス１”を構成するＶＮＦ７０として“ＶＮＦ１０”と“ＶＮＦ２１”が、次に運用データである図５（ｂ）の表Ｔ３より、“ＶＮＦ１０”のＶＮＦＭ３０が“ＶＮＦＭ１”、“ＶＮＦ２１”のＶＮＦＭ３０が“ＶＮＦＭ２”であることが導き出される（Ａ、Ｓ００４）。【0048】
以降（Ｓ００５〜Ｓ０２４）の処理は、ＶＮＦ７０単位にシーケンシャル又は並行して実施される。ここでは、“ＶＮＦ１０”の生成を示す。【0049】
続いて、オーケストレータ２０では、上記で特定された“ＶＮＦ１０”を生成するために、“ＶＮＦ１０”を配置可能なデータセンタが、図５（ｃ）の表Ｔ４の運用条件、信号（１）により入力されたＮＷ条件、及び図５（ｅ）の表Ｔ５のデータセンタの接続構成が用いられて選択される。予めオーケストレータ２０に登録されている図５（ｃ）の表Ｔ４から、“ＶＮＦ１０”の配置可能なデータセンタとして“ＤＣ２”“ＤＣ３”“ＤＣ４”“ＤＣ５”が候補として得られる。次に、入力されたＮＷ条件の“ＤＣ１接続、帯域５Ｇｂｐｓ以上”と、予めオーケストレータ２０に登録されている図５（ｅ）の表Ｔ５から得られる“ＤＣ１”に接続しているデータセンタが、“ＤＣ２”“ＤＣ３”“ＤＣ４”という接続情報より、“ＤＣ５”が条件を満たさないことが判明し、候補のデータセンタが“ＤＣ２”“ＤＣ３”“ＤＣ４”とされる。【0050】
続いて、オーケストレータ２０では、定期収集により蓄積しているネットワーク全体資源情報データベースの図４（ａ）の表Ｔ１から、選択した“ＤＣ２”“ＤＣ３”“ＤＣ４”の資源情報が読み出される。読み出された資源情報を、図４（ｂ）の表Ｔ８に示す。続いて、生成するＶＮＦ７０をユニークに識別する番号としてＶＮＦ識別番号“ＶＮＦ＿００１”が払い出される（Ｂ、Ｓ００５）。【0051】
続いて、配置可能なデータセンタ候補としてＢ（Ｓ００５）で抽出された“ＤＣ２”“ＤＣ３”“ＤＣ４”と読み出したそれぞれの資源情報の組み合わせ表（図４（ｂ）の表Ｔ８）、信号（１）で入力された性能条件の“１００”、生成対象ＶＮＦ種別として“ＶＮＦ１０”、払い出したＶＮＦ識別番号“ＶＮＦ＿００１”が、上記のＡ（Ｓ００４）で読み出された“ＶＮＦ１０”のＶＮＦＭ３０である“ＶＮＦＭ１”に、必要資源問い合わせ（信号（２））として送信される（Ｓ００６）。【0052】
なお、Ｓ００６において、各データセンタの資源情報を含めない実施形態も可能となる。この場合には、各データセンタの資源情報の代わりに、各データセンタを管理するＶＩＭ４０の識別番号が、予めオーケストレータ２０に登録されている図５（ｄ）の表Ｔ６から読み出され、Ｓ００６において送信される情報に含められる。例えば、“ＤＣ２”のＶＩＭ４０が“ＶＩＭ１”、“ＤＣ３”のＶＩＭ４０が“ＶＩＭ１”、“ＤＣ４”のＶＩＭ４０が“ＶＩＭ２”という組み合わせが送信される情報に含められる。【0053】
信号（２）は、“ＶＮＦＭ１”において受信される。信号（２）を受信した“ＶＮＦＭ１”では、各データセンタに対する資源情報の設定有無（信号（２）に資源情報が含まれているか否か）が確認される。資源情報ではなくＶＩＭ識別番号が設定されてきた場合、“ＶＮＦＭ１”は自身で各データセンタの資源情報をＶＩＭ４０に要求し収集する。例えば、“ＶＮＦＭ１”によって、信号（２）で受け付けられた“ＶＩＭ１”に対して“ＤＣ２”及び“ＤＣ３”の、“ＶＩＭ２”に対して“ＤＣ４”の資源情報が問い合わせられ、図４（ｂ）の表Ｔ８が得られる（Ｓ００７、Ｓ００８）。【0054】
信号（２）、若しくはＳ００７及びＳ００８の処理にてデータセンタの資源情報（図４（ｂ）の表Ｔ８）を入手した“ＶＮＦＭ１”では、信号（２）のＶＮＦ種別に設定されていた“ＶＮＦ１０”の詳細情報が、予め“ＶＮＦＭ１”の保持部３１に保持（登録）されているＶＮＦ詳細情報データベースより読み出される。詳細情報には図６の表Ｔ９のＶＮＦ内部構造と性能条件に応じた資源情報（ＶＭ）、資源情報（ＮＷ）、機能情報の組み合せが登録されている。図６の表Ｔ９の型番はそれぞれの組み合せの識別子である。資源情報（ＶＭ）のイメージファイルは、ＶＭを構成するための情報をファイルとして保持したものであり、ＶＮＦ７０を起動する際に使用する。イメージファイルはＶＩＭ４０が読み出し可能な通信網内の任意の場所に予め格納されている。ＶＮＦ７０は１つ以上の内部機能部から構成され、ＶＮＦ７０の生成のための資源は内部機能部毎にＶＩＭ４０で確保される。配置・起動情報は、ＶＩＭ４０で確保される内部機能部毎の資源とイメージファイルの対応関係、イメージファイルを用いてＶＮＦ７０を起動するための設定情報と内部機能部毎の起動手順、およびＶＮＦ７０を削除する際の内部機能部毎の削減手順を含むものである。資源情報（ＮＷ）のＮＷ構成情報はＶＮＦ７０の内部機能部のＮＷ接続形態を示す情報である。【0055】
“ＶＮＦＭ１”では、読み出された詳細情報（図６の表Ｔ９）から信号（２）で受け付けられたＶＮＦ種別“ＶＮＦ１０”の性能条件“１００”に必要な資源情報と機能情報が取り出される（Ｃ１、Ｓ００９）。【0056】
取り出された資源情報及び機能情報と、信号（２）、若しくはＳ００７及びＳ００８の処理にて得られた資源情報（図４（ｂ）の表Ｔ８）の使用可能資源情報と提供機能とが比較されて、利用可能なデータセンタが抽出される。具体的には図６の表Ｔ９より“ＶＮＦ１０”は“機能１”及び“機能２”を必要とし、図４（ｂ）の表Ｔ８より“機能１”及び“機能２”を提供可能なデータセンタは“ＤＣ２”及び“ＤＣ３”であることが判断される。【0057】
次に、利用可能なデータセンタの提供する資源でＶＮＦ７０を生成するために必要な資源情報が導き出される。具体的には図４（ｂ）の表Ｔ８より、“ＤＣ２”がＨｉｇｈ及びＬｏｗ、“ＤＣ３”がＬｏｗのＣＰＵ性能を提供可能であることが判別できる。ここでＣＰＵ性能は、ＣＰＵの動作周波数、物理コア数や演算高速化技術などを基にした演算性能に関する分類を表す。これが、Ｓ００９の処理で読み出された図６の表Ｔ９のＣＰＵ性能と照らし合わされて（ＶＮＦ７０の生成に必要な資源情報が、データセンタで使用可能かが判断されて）、“ＤＣ２”及び“ＤＣ３”で取り得る資源情報の組み合わせとして図７（ａ）の表Ｔ１０が得られる。詳細には、Ｓ００９の処理で読み出された図６の表Ｔ９より、“ＶＮＦ１０”は内部機能部“ＶＮＦＣ１００”と“ＶＮＦＣ１０１”から構成されることが分かる。さらに、性能条件“１００”の場合には、内部機能部“ＶＮＦＣ１００”は、ＣＰＵ性能“Ｈｉｇｈ”を用いた型番“００１”またはＣＰＵ性能“Ｌｏｗ”を用いた型番“００２”の仮想資源（ＶＭ、ＮＷ）により生成可能であり、内部機能部“ＶＮＦＣ１０１”は、ＣＰＵ性能“Ｈｉｇｈ”を用いた型番“００５”またはＣＰＵ性能“Ｌｏｗ”を用いた型番“００６”の仮想資源（VM、NW）により生成可能であることが分かる。これより、信号（２）で指示されたＶＮＦ種別“ＶＮＦ１０”の性能条件“１００”となるＶＮＦ７０を生成するのに必要な仮想資源の組み合わせは、ＣＰＵ性能”Ｈｉｇｈ”と”Ｌｏｗ”を提供可能な“ＤＣ２”では４通り、ＣＰＵ性能”Ｌｏｗ”のみを提供可能な“ＤＣ３”では１通りとなり、図７（ａ）の表Ｔ１０が得られる。信号（２）のサービスＩＤ、ＶＮＦ種別及びＶＮＦ識別番号、並びに詳細情報の図６の表Ｔ９が記憶される（Ｃ２、Ｓ０１０）。【0058】
続いて、“ＶＮＦＭ１”からオーケストレータ２０に、導出された資源情報とデータセンタの組み合わせを示す図７（ａ）の表Ｔ１０が返送される（信号（３）、Ｓ０１１）。【0059】
オーケストレータ２０では、予約要求部２２によって信号（３）が受信される。信号（３）で受信された資源情報とデータセンタの組み合わせ表（図７（ａ）の表Ｔ１０）に、予めオーケストレータ２０に登録されている図５（ｆ）の表Ｔ１２の優先度指標に基づき優先度が付与され、図７（ｂ）の表Ｔ１３が得られる。具体的な手順を説明する。図５（ｆ）の表Ｔ１２より第１優先度はＤＣ間帯域となる。図７（ａ）の表Ｔ１０より候補となるＤＣは“ＤＣ２”と“ＤＣ３”であり、図５（ｅ）の表Ｔ５より“ＤＣ１”との間のＮＷ帯域は“ＤＣ３”より“ＤＣ２”の方が大きいことが分かり“ＤＣ２”が高優先となる。次に、図５（ｆ）の表Ｔ１２より第２優先度はＣＰＵ性能となる。図７（ａ）の表Ｔ１０より、“ＤＣ２”の組み合せにおいては、ＣＰＵ性能“Ｈｉｇｈ”だけの組み合せ２の優先度が最も高く、ＣＰＵ性能“Ｌｏｗ”だけの組み合せ１が最も低いことが分かる。ＣＰＵ性能“Ｈｉｇｈ”と“Ｌｏｗ”の組み合せ３と４については、第３優先度のＶＭ用記憶領域：少を用いる。図７（ａ）の表Ｔ１０より、ＶＭ用記憶領域は、組み合せ３が３００ＧＢのＶＭが（１＋２）個、組み合せ４が３００ＧＢのＶＭが２個と５００ＧＢのＶＭが１個となり、ＶＭ用記憶領域の総量が少ない組み合せ３の優先度が高いことが分かる。これより必要資源の組み合せに優先度を付与した図７（ｂ）の表Ｔ１３が得られる（Ｄ、Ｓ０１２）。【0060】
続いて、優先度の高い組み合わせの順番に、データセンタを管理するＶＩＭ４０への予約が実施される。予約要求部２２によって、図７（ｂ）の表Ｔ１３で優先度の最も高い組み合わせ２の必要資源と対象の“ＤＣ２”が設定されて、資源の予約要求が、図５（ｄ）の表Ｔ６より読み出された“ＤＣ２”の管理機能である“ＶＩＭ１”に送出される（信号（４）、Ｓ０１３、予約要求ステップ）。図７（ｂ）の表Ｔ１３の優先度１の組み合わせの場合は、図８（ａ）の表Ｔ１４の情報が必要資源情報（ＶＭ、ＮＷ）となる（必要資源情報として設定される）。資源予約が失敗した場合は、次優先度の組み合わせの予約要求が行われる（Ｆ、処理Ｓ０１６からの戻り）。【0061】
“ＶＩＭ１”では、信号（４）が受け付けられる。信号（４）が受け付けられた“ＶＩＭ１”では、予約部４２によって、信号（４）に設定されている“ＤＣ２”に信号（４）で要求された、図８（ａ）の表Ｔ１４に示される必要資源を確保できるかが、管理域内資源情報データベースをもとに確認され、資源が予約されて予約番号が払い出される（Ｅ、Ｓ０１４、予約ステップ）。“ＶＩＭ１”では、予約番号とともに、予約した“ＤＣ２”、予約された資源情報（表Ｔ１４）が記憶される。“ＶＩＭ１”では、資源が確保できた場合には予約番号が、資源が確保できない場合にはエラーがオーケストレータ２０に応答される（信号（５）、Ｓ０１５）。【0062】
オーケストレータ２０では、“ＶＩＭ１”からの信号（５）が受信される。“ＶＩＭ１”からの信号（５）が受信されたオーケストレータ２０では、資源の予約結果が確認される（Ｆ、Ｓ０１６）。資源の予約が出来なかった場合（Ｆ、Ｓ０１６のＮＧ）には、再度、Ｄ（Ｓ０１２）の処理に戻り次優先度の組み合わせの予約が実施される。【0063】
オーケストレータ２０では、予約が成功したら、Ｓ００５の処理で払い出されたサービスＩＤ、資源予約先のＶＩＭ識別番号として“ＶＩＭ１”、図５（ｄ）の表Ｔ６から取得されたＶＩＭ種別、及び“ＶＩＭ１”から信号（５）で受信された予約番号、予約資源情報（ＶＭ、ＮＷ）として図８（ａ）の表Ｔ１４の資源情報が設定され、“ＶＮＦＭ１”に“ＶＮＦ１０”の生成が要求される（信号（６）、Ｓ０１７）。また、オーケストレータ２０では、サービスＩＤと、ＶＮＦ種別、ＶＮＦ識別番号、予約番号、予約した“ＶＩＭ１”、予約した“ＤＣ２”が記憶される。【0064】
“ＶＮＦＭ１”では、仮想サーバ生成要求部３２によって、信号（６）が受信される。続いて、仮想サーバ生成要求部３２によって、信号（６）で受信したサービスＩＤより、Ｃ２（Ｓ０１０）で記憶されている詳細情報の図６の表Ｔ９が読み出され、信号（６）で受信された予約資源情報（ＶＭ、ＮＷ）の図８（ａ）の表Ｔ１４の型番“００１”、“００５”に対応する配置・起動情報、ＮＷ（ネットワーク）構成情報が決定される。続いて、仮想サーバ生成要求部３２によって、生成する仮想マシン（ＶＭ）にＶＭ識別番号が払い出され付与される。【0065】
続いて、“ＶＮＦＭ１”では、仮想サーバ生成要求部３２によって、信号（６）で受信したＶＩＭ種別に応じて、配置・起動情報、ＮＷ構成情報の書式が変更される（ＶＩＭ４０の管理方式に応じて詳細情報が書き換えられる）（Ｇ、Ｓ０１８、仮想サーバ生成要求ステップ）。なお、この書き換えは、従来技術によって行われえる。【0066】
続いて、仮想サーバ生成要求部３２によって、“ＶＩＭ１”用に書式が変更された配置・起動情報とＮＷ構成情報、信号（６）で受信された予約番号が、信号（６）で受信した予約先の“ＶＩＭ１”に通知され、“ＶＮＦ１０”の生成が要求される（信号（７）、Ｓ０１９、仮想サーバ生成要求ステップ）。配置・起動情報、ＮＷ構成情報として設定される情報は図８（ｂ）の表Ｔ１５となる。“ＶＮＦＭ１”では、Ｃ２（Ｓ０１０）で記憶されたサービスＩＤ、ＶＮＦ種別、ＶＮＦ識別子（ＶＮＦ識別番号）に、信号（６）で受けたＶＩＭ識別番号、予約番号と内部機能部、ＶＭ識別番号が対応付けられて記憶される。【0067】
“ＶＩＭ１”では、仮想サーバ生成部４３によって、信号（７）が受信される。続いて、仮想サーバ生成部４３によって、信号（７）で受け付けられた予約番号よりＶＮＦ７０を起動する資源としてＥ（Ｓ０１４）の処理で確保された“ＤＣ２”の資源が特定される。続いて、仮想サーバ生成部４３によって、信号（７）で受け付けた配置・起動情報とＮＷ構成情報に基づき“ＤＣ２”にＶＭ及びＶＮＦのイメージファイルが読み込まれて、ＶＭ及びＶＮＦ７０が生成・起動される。【0068】
“ＶＩＭ１”では、仮想サーバ生成部４３によって、予め割り当てられている外部ＩＰアドレス帯域から、信号（７）で指定された数の外部アドレスとして“外部ＩＰアドレス０１”“外部ＩＰアドレス０２”がＶＭに付与される。“ＶＩＭ１”では、予約番号と、データセンタ、“ＶＮＦＭ１”のＶＭ識別番号、物理装置（ＨＷ）、割り当てた資源情報と信号（７）の送信元ＶＮＦＭ３０の対応付けとして図９（ａ）の表Ｔ１６の情報が記憶される（Ｈ、Ｓ０２０、仮想サーバ生成ステップ）。【0069】
続いて、仮想サーバ生成部４３によって、ＶＭ生成時に割り当てられた“外部ＩＰアドレス０１”“外部ＩＰアドレス０２”とＶＭの対応関係がＮＷ（ネットワーク）情報として設定された図９（ｂ）の表Ｔ１７が信号（８）で“ＶＮＦＭ１”に応答される（図１６のＳ０２１）。【0070】
“ＶＮＦＭ１”では、Ｇ（Ｓ０１８）の処理で記憶されたサービスＩＤに関連する情報に信号（８）に設定されているＮＷ情報が追加されて記憶される。情報の内容は図９（ｃ）の表Ｔ１８となる（Ｊ、Ｓ０２２）。【0071】
ＶＮＦ生成が成功した場合には、“ＶＮＦＭ１”からオーケストレータ２０に対して、ＮＷ情報として“外部ＩＰアドレス０１”“外部ＩＰアドレス０２”が設定された信号（９）が通知される（Ｓ０２３）。【0072】
オーケストレータ２０では、信号（９）が受け付けられる。信号（９）が受け付けられたオーケストレータ２０では、ＶＮＦ生成が完了したことが確認される。オーケストレータ２０では、Ｓ０１７の処理で記憶されたＶＮＦ７０の情報と信号（９）に設定されているＮＷ情報が、サービスＩＤに対応付けられて記憶される。情報の内容は図９（ｄ）の表Ｔ１９となる（Ｋ、Ｓ０２４）。【0073】
“ＶＮＦ２１”についても同様にＢ〜Ｋの手順（Ｓ００５〜Ｓ０２４の処理）が実施され、オーケストレータ２０では、“ＶＮＦ１０”の結果に“ＶＮＦ２１”の生成結果が反映された図１０（ａ）の表Ｔ２１が得られる。“ＶＮＦ２１”は、“ＶＮＦ１０”と同一のデータセンタに生成されたものとする（Ｌ、Ｓ０２５）。【0074】
Ａ（Ｓ００４）で生成対象と判断した“ＶＮＦ１０”、“ＶＮＦ２１”の生成が完了したことを確認したオーケストレータ２０によって、データセンタ間ネットワークを管理するＶＩＭ４０である“ＶＩＭ−ＮＷ”が、図５（ｄ）の表Ｔ６により特定され、図１０（ａ）の表Ｔ２１より“ＶＮＦ１０”と“ＶＮＦ２１”のＮＷ情報のＩＰアドレスが通知されてＶＮＦ間の接続が要求される（信号（１０）、Ｓ０２６）。“ＶＩＭ−ＮＷ”では、当該要求に応じた処理が行われ、その応答がオーケストレータ２０に送信される（Ｓ０２７）。【0075】
また、オーケストレータ２０からＯＳＳ５１に対して、信号（９）で受信された“ＶＮＦ１０”と“ＶＮＦ２１”のＶＮＦ種別、ＶＮＦ識別番号、性能、ＮＷ情報が信号（１０）で通知される（Ｓ０２８）。【0076】
ＯＳＳ５１では、信号（１１）が受信され、信号（１）の要求内容と信号（１１）の結果が対応付けられて図１０（ａ）の表Ｔ２２として保持される（Ｍ、Ｓ０２９）。“ＶＮＦ１０”に続いて“ＶＮＦ２１”が生成された場合、ＶＮＦＭ３０で有する図９（ｃ）の表Ｔ１８に“ＶＮＦ２１”が追加され図１０（ｃ）の表Ｔ２３となる（Ｎ、Ｓ０３０）。図１０（ｃ）の表Ｔ２３は、ＶＮＦＭ３０（全体）の管理する情報を示しているが、ＶＮＦＭ３０毎に（当該ＶＮＦＭ３０が管理するＶＮＦ７０毎に）管理してもよい（以降、図１０（ｃ）の表Ｔ２３について同様）。【0077】
通信サービス生成の完了後に、オーケストレータ２０、ＶＮＦＭ３０及びＶＩＭ４０は、それぞれ図１０（ａ）の表Ｔ２１、図１０（ｃ）の表Ｔ２３及び図９（ａ）の表Ｔ１６の情報を保持し、サービスに対する増強、削減、終了などの制御や、障害、輻輳、工事などの保守運用において使用する。【0078】
例えば、ＶＩＭ４０は、図９（ａ）の表Ｔ１６の情報を用いて、ハードウェア障害発生時には該当ハードウェアに関連するＶＭを特定し、その管理機能部であるＶＮＦＭ３０やオーケストレータ２０に通知することにより、オートヒーリングや保守者による障害への対処が可能となる。またＶＭに対する増減や終了操作においても、影響する資源を特定し資源情報の管理を行うために使用する。同様に、オーケストレータ２０とＶＮＦＭ３０も、図１０（ａ）の表Ｔ２１及び図１０（ｃ）の表Ｔ２３の対応関係を、通信サービスや内部機能に対する増強、削減、終了などの操作を実施するために使用する。【0079】
また、これらの対応関係情報は通信網全体の運用システム（ＯＳＳ５１）に集約され、通信網全体の監視・運用のために使用することも可能である。以上が、（１）インスタンシエーションが行われる場合の処理である。【0080】
続いて、図１７及び図１８のシーケンス図を用いて、（２）オートヒーリングが行われる場合の処理を説明する。なお、図１８に示すシーケンス図は、図１７のシーケンス図と（時系列的に）連続するものである。オートヒーリングとは、ハードウェア又はソフトウェアの異常によりＶＮＦ７０が正常に動作しなくなった場合に、正常に動作するＶＮＦ７０を自動的に生成することである。オートヒーリングにより、移動体通信システム１において、通信機能が自動的に回復する。【0081】
ＯＳＳ５１は、従来システム同様に運用管理システムであるＥＭＳ８０を通じて、インスタンシエーション処理（手順）で生成したＶＮＦ７０の状態を監視して運用する。運用中にＶＮＦ７０の異常（例えば無応答）を検知したＥＭＳ８０は異常をＯＳＳ５１に通知し（Ｓ１０１）、ＯＳＳ５１はＶＮＦ７０の再配置をすることができる。インスタンシエーション処理で生成した“ＶＮＦ１０”“ＶＮＦ２１”のうち、“ＶＮＦ１０”の動作異常（例えば無応答）を検出したＥＭＳ８０からの情報を受信したＯＳＳ５１が、“ＶＮＦ１０”に代わる再配置を決定し、オーケストレータ２０に対して代替ＶＮＦ７０の生成を要求する例を記載する。【0082】
ＯＳＳ５１からオーケストレータ２０に対して、再配置元ＶＮＦ７０生成時に使用したサービスＩＤ、再配置対象を識別するためのＶＮＦ識別番号“ＶＮＦ＿００１”、再配置する性能を示す性能条件（例えば、現状同等の性能指標値）である“１００”、ＮＷ条件として現状と別ＤＣへの設置を意味する“別ＤＣ”を設定した信号（１）が送信される（Ｓ１０２）。【0083】
オーケストレータ２０では、要求受付部２１によって、サービス再配置要求が受け付けられる（Ｓ１０２、要求受付ステップ）。サービス再配置要求が受け付けられたオーケストレータ２０では、サービスＩＤとＶＮＦ識別番号が用いられて、再配置元のＶＮＦ７０に関する情報として、ＶＮＦ種別、データセンタがＶＮＦ７０生成時に記憶したデータより特定される。図１０（ａ）の表Ｔ２１より、サービスＩＤとＶＮＦ識別番号“ＶＮＦ＿００１”に対応するＶＮＦ種別が“ＶＮＦ１０”、データセンタが“ＤＣ２”、“ＶＮＦ１０”のＶＮＦＭ３０が図５（ｂ）の表Ｔ３より“ＶＮＦＭ１”であることが導き出される（Ａ、Ｓ１０３）。【0084】
続いて、オーケストレータ２０では、上記で特定した“ＶＮＦ１０”を再配置するために、“ＶＮＦ１０”を配置可能なデータセンタが、図５（ｃ）の表Ｔ４の運用条件、信号（１）により入力されたＮＷ条件及び図５（ｅ）の表Ｔ５のデータセンタの接続構成が用いられて選択される。図５（ｃ）の表Ｔ４から、“ＶＮＦ１０”の配置可能なデータセンタとして“ＤＣ２”“ＤＣ３”“ＤＣ４”“ＤＣ５”が候補として得られる。次に、入力されたＮＷ条件より再配置元ＶＮＦ７０の“ＤＣ２”とは別データセンタであることと、再配置元のＶＮＦ７０が配置されている“ＤＣ２”に接続しているデータセンタが、“ＤＣ１”“ＤＣ３”“ＤＣ５”という図５（ｅ）の表Ｔ５から得られる接続情報より、候補のデータセンタが“ＤＣ３”“ＤＣ５”とされる。【0085】
続いて、オーケストレータ２０では、定期収集により蓄積しているネットワーク全体資源情報データベースの図４（ａ）の表Ｔ１から、候補となった “ＤＣ３”“ＤＣ５”の資源情報が読み出される。読み出された資源情報を、図１１（ａ）の表Ｔ３１に示す。続いて、再配置するＶＮＦ７０をユニークに識別する番号としてＶＮＦ識別番号“ＶＮＦ＿０１０”が払い出される（Ｂ、Ｓ１０４）。【0086】
続いて、再配置ＶＮＦ識別番号“ＶＮＦ＿０１０”、配置可能なデータセンタ候補としてＢ（Ｓ１０４）で抽出された“ＤＣ３”“ＤＣ５”と読み出したそれぞれの資源情報の組み合わせ表（図１１（ａ）の表Ｔ３１）、再配置元ＶＮＦ識別番号“ＶＮＦ＿００１”、ＶＮＦ種別“ＶＮＦ１０”、信号（１）で入力されたサービスＩＤと性能条件の“１００”が、上記のＡ（Ｓ１０３）で読み出された“ＶＮＦ１０”のＶＮＦＭ３０である“ＶＮＦＭ１”に、必要資源問い合わせ（信号（２））として送信される（Ｓ１０５）。【0087】
なお、Ｓ１０５において、各データセンタの資源情報を含めない実施形態も可能となる。この場合には、各データセンタの資源情報の代わりに、各データセンタを管理するＶＩＭ４０の識別番号が、図５（ｄ）の表Ｔ６から読み出され、Ｓ１０６において送信される情報に含められる。例えば、“ＤＣ３”のＶＩＭ４０が“ＶＩＭ１”、“ＤＣ５”のＶＩＭ４０が“ＶＩＭ３”という組み合わせが送信される情報に含められる。【0088】
信号（２）は、“ＶＮＦＭ１”において受信される。信号（２）を受信した“ＶＮＦＭ１”では、各データセンタに対する資源情報の設定有無（信号（２）に資源情報が含まれているか否か）が確認される。資源情報ではなくＶＩＭ識別番号が設定されてきた場合、“ＶＮＦＭ１”は自身で各データセンタの資源情報をＶＩＭ４０に要求し収集する。例えば、“ＶＮＦＭ１”によって、信号（２）で受け付けられた“ＶＩＭ１”に対して“ＤＣ３”の、“ＶＩＭ３”に対して“ＤＣ５”の資源情報が問い合わせられ、図１１（ａ）の表Ｔ３１が得られる（Ｓ１０６、Ｓ１０７）。【0089】
信号（２）、若しくはＳ１０６及びＳ１０７の処理にてデータセンタの資源情報（図１１（ａ）の表Ｔ３１）を入手した“ＶＮＦＭ１”では、信号（２）のＶＮＦ種別に設定されている“ＶＮＦ１０”の詳細情報が、予め“ＶＮＦＭ１”の保持部３１に保持（登録）されているＶＮＦ詳細情報データベースより読み出される。詳細情報には図６の表Ｔ９のＶＮＦ内部構造と性能条件に応じた資源情報（ＶＭ）、資源情報（ＮＷ）、機能情報が登録されている。【0090】
“ＶＮＦＭ１”では、読み出された詳細情報（図６の表Ｔ９）から信号（２）で受け付けたＶＮＦ種別“ＶＮＦ１０”の性能条件“１００”に必要な資源情報と機能情報が取り出される（Ｃ１、Ｓ１０８）。【0091】
取り出された資源情報及び機能情報と、信号（２）、若しくはＳ１０６及びＳ１０７の処理にて得られた資源情報（図１１（ａ）の表Ｔ３１）の使用可能資源情報と提供機能とが比較されて、利用可能なデータセンタが抽出される。具体的には図６の表Ｔ９より“ＶＮＦ１０”は“機能１”及び“機能２”を必要とし、図１１（ａ）の表Ｔ３１より“機能１”及び“機能２”を、候補の“ＤＣ３”及び“ＤＣ５”は共に提供可能であることが判断される。【0092】
次に、利用可能なデータセンタの提供する資源でＶＮＦ７０を生成するために必要な資源情報が導き出される。具体的には図１１（ａ）の表Ｔ３１より、“ＤＣ３”がＬｏｗ、“ＤＣ５”がＨｉｇｈのＣＰＵ性能を提供可能であることが判別できる。これが、Ｓ１０８の処理で読み出された図６の表Ｔ９のＣＰＵ性能と照らし合わされて、“ＤＣ３”及び“ＤＣ５”で取り得る資源情報の組み合わせとして図１１（ｂ）の表Ｔ３２が得られる。詳細には、Ｓ１０８の処理で読み出された図６の表Ｔ９より、“ＶＮＦ１０”は内部機能部“ＶＮＦＣ１００”と“ＶＮＦＣ１０１”から構成されることが分かる。さらに、性能条件“１００”の場合には、内部機能部“ＶＮＦＣ１００”はＣＰＵ性能“Ｈｉｇｈ”を用いた型番“００１”またはＣＰＵ性能“Ｌｏｗ”を用いた型番“００２”の仮想資源（ＶＭ、ＮＷ）により生成可能であり、内部機能部“ＶＮＦＣ１０１”は、ＣＰＵ性能“Ｈｉｇｈ”を用いた型番“００５”またはＣＰＵ性能“Ｌｏｗ”を用いた型番“００６”の仮想資源（ＶＭ、ＮＷ）により生成可能であることが分かる。これより、信号（２）で指示されたＶＮＦ種別“ＶＮＦ１０”の性能条件“１００”となるＶＮＦ７０を生成するのに必要な仮想資源の組み合わせは、ＣＰＵ性能”Ｌｏｗ”を提供可能な“ＤＣ３”では１通り、ＣＰＵ性能”Ｈｉｇｈ”を提供可能な“ＤＣ５”でも１通りとなり、“ＤＣ３”及び“ＤＣ５”で取り得る資源情報の組み合わせとして図１１（ｂ）の表Ｔ３２が得られる。信号（２）のサービスＩＤ、再配置ＶＮＦ種別及び再配置ＶＮＦ識別番号、並びに詳細情報の図６の表Ｔ９が記憶される（Ｃ２、Ｓ１０９）。【0093】
続いて、“ＶＮＦＭ１”からオーケストレータ２０に、導出された資源情報とデータセンタの組み合わせを示す図１１（ｂ）の表Ｔ３２が返送される（信号（３）、Ｓ１１０）。【0094】
オーケストレータ２０では、予約要求部２２によって信号（３）が受信される。信号（３）で受信された資源情報とデータセンタの組み合わせ表（図１１（ｂ）の表Ｔ３２）に、図５（ｆ）の表Ｔ１２の優先度指標が適用される。表Ｔ１２より、第１優先はデータセンタ間帯域であり、図５（ｅ）の表Ｔ５より再配置元ＶＮＦ７０の“ＤＣ２”と“ＤＣ３”との間、“ＤＣ２”と“ＤＣ５”との間の帯域では、“ＤＣ２”と“ＤＣ３”との間の帯域が大きいことが判断できる。これに基づき優先度が付与され、図１１（ｃ）の表Ｔ３３が得られる（Ｄ、Ｓ１１１）。【0095】
続いて、優先度の高い組み合わせの順番に、データセンタを管理するＶＩＭ４０への予約が実施される。予約要求部２２によって、図１１（ｃ）の表Ｔ３３で優先度の最も高い“ＤＣ３”の組み合わせ１の必要資源と対象の“ＤＣ３”が設定されて、資源の予約要求が、図５（ｄ）の表Ｔ６より読み出された“ＤＣ３”の管理機能である“ＶＩＭ１”に送出される（信号（４）、Ｓ１１２、予約要求ステップ）。図１１（ｃ）の表Ｔ３３の優先度１の組み合わせの場合は、図１２（ａ）の表Ｔ３４の情報が必要資源情報（ＶＭ、ＮＷ）となる。資源予約が失敗した場合は、次優先度の組み合わせの予約要求が行われる（Ｆ、処理Ｓ１１５からの戻り）。【0096】
“ＶＩＭ１”では、信号（４）が受け付けられる。信号（４）が受け付けられた“ＶＩＭ１”では、予約部４２によって、信号（４）に設定されている“ＤＣ３”に信号（４）で要求された、図１２（ａ）の表Ｔ３４に示される必要資源を確保できるかが、管理域内資源情報データベースをもとに確認され、資源が予約されて予約番号１０が払い出される（Ｅ、Ｓ１１３、予約ステップ）。“ＶＩＭ１”では、予約番号１０とともに、予約した“ＤＣ３”、予約された資源情報が記憶される。“ＶＩＭ１”では、資源が確保できた場合には予約番号が、資源が確保できない場合にはエラーがオーケストレータ２０に応答される（信号（５）、Ｓ１１４）。【0097】
オーケストレータ２０では、“ＶＩＭ１”からの信号（５）が受信される。“ＶＩＭ１”からの信号（５）が受信されたオーケストレータ２０では、資源の予約結果が確認される（Ｆ、Ｓ１１５）。資源の予約が出来なかった場合（Ｆ、Ｓ１１５のＮＧ）には、再度、Ｄ（Ｓ１１１）の処理に戻り次優先度の組み合わせの予約が実施される。【0098】
オーケストレータ２０では、予約が成功したら、再配置元ＶＮＦ７０生成時のサービスＩＤ、資源予約先のＶＩＭ識別番号として“ＶＩＭ１”、図５（ｄ）の表Ｔ６から取得されたＶＩＭ種別、及び“ＶＩＭ１”から信号（５）で受信された予約番号、予約資源情報（ＶＭ、ＮＷ）として図１２（ａ）の表Ｔ３４の資源情報が設定され、“ＶＮＦＭ１”に“ＶＮＦ１０”の再配置が要求される（信号（６）、Ｓ１１６）。また、オーケストレータ２０では、再配置ＶＮＦの情報として、サービスＩＤと、ＶＮＦ種別、ＶＮＦ識別番号、予約番号、予約した“ＶＩＭ１”、予約した“ＤＣ３”が記憶される。【0099】
“ＶＮＦＭ１”では、仮想サーバ生成要求部３２によって、信号（６）が受信される。続いて、仮想サーバ生成要求部３２によって、信号（６）で受信されたサービスＩＤより、Ｃ２（Ｓ１０９）で記憶されている詳細情報の図６の表Ｔ９が読み出され、信号（６）で受信された予約資源情報（ＶＭ、ＮＷ）の図１２（ａ）の表Ｔ３４の型番“００２”、“００６”に対応する配置・起動情報、ＮＷ（ネットワーク）構成情報が決定される。続いて、仮想サーバ生成要求部３２によって、生成する仮想マシン（ＶＭ）にＶＭ識別番号が払い出され付与される。【0100】
続いて、“ＶＮＦＭ１”では、仮想サーバ生成要求部３２によって、信号（６）で受信されたＶＩＭ種別に応じて、配置・起動情報、ＮＷ構成情報の書式が変更される（ＶＩＭ４０の管理方式に応じて詳細情報が書き換えられる）（Ｇ、Ｓ１１７、仮想サーバ生成要求ステップ）。【0101】
続いて、仮想サーバ生成要求部３２によって、“ＶＩＭ１”用に書式が変更された配置・起動情報とＮＷ構成情報、信号（６）で受信された予約番号が、信号（６）で受信された予約先の“ＶＩＭ１”に通知され、“ＶＮＦ１０”の生成が要求される（信号（７）、Ｓ１１８、仮想サーバ生成要求ステップ）。配置・起動情報、ＮＷ構成情報として設定される情報は図１２（ｂ）の表Ｔ３５となる。“ＶＮＦＭ１”では、Ｃ２（Ｓ１０９）で記憶されたサービスＩＤ、ＶＮＦ種別、ＶＮＦ識別番号に、信号（６）で受けたＶＩＭ識別番号、予約番号と図６の表Ｔ９から読み出された内部機能部、払い出したＶＭ識別番号が対応付けられて記憶される。【0102】
“ＶＩＭ１”では、仮想サーバ生成部４３によって、信号（７）が受信される。続いて、仮想サーバ生成部４３によって、信号（７）で受け付けられた予約番号よりＶＮＦ７０を起動する資源としてＥ（Ｓ１１３）の処理で確保された“ＤＣ３”の資源が特定される。続いて、仮想サーバ生成部４３によって、信号（７）で受け付けた配置・起動情報とＮＷ構成情報に基づき“ＤＣ３”にＶＭ及びＶＮＦのイメージファイルが読み込まれて、ＶＭ及びＶＮＦ７０が生成・起動される。【0103】
“ＶＩＭ１”では、仮想サーバ生成部４３によって、予め割り当てられている外部ＩＰアドレス帯域から、信号（７）で指定された数の外部アドレスとして“外部ＩＰアドレス１０”“外部ＩＰアドレス１１”がＶＭに付与される。“ＶＩＭ１”では、Ｅ（Ｓ１１３）の処理の予約番号と、データセンタに加えて、“ＶＮＦＭ１”のＶＭ識別番号、物理装置（ＨＷ）の対応付けとして、図１４（ａ）の表Ｔ４１の情報が記憶される（Ｈ、図１８のＳ１１９、仮想サーバ生成ステップ）。【0104】
続いて、仮想サーバ生成部４３によって、ＶＭ生成時に割り当てられた外部ＩＰアドレスがＮＷ情報として設定された図１２（ｃ）の表Ｔ３６が信号（８）で“ＶＮＦＭ１”に応答される（Ｓ１２０）。【0105】
“ＶＮＦＭ１”では、Ｇ（Ｓ１１７）の処理で記憶されたサービスＩＤに関連する情報に信号（８）に設定されているＮＷ情報が追加されて記憶される。情報の内容は図１３（ａ）の表Ｔ３７となる（Ｊ、Ｓ１２１）。図１３（ａ）の表Ｔ３７は、ＶＮＦＭ３０（全体）の管理する情報を示しているが、ＶＮＦＭ３０毎に（当該ＶＮＦＭ３０が管理するＶＮＦ７０毎に）管理してもよい（以降、図１３（ａ）の表Ｔ３７については同様）。【0106】
ＶＮＦ生成が成功した場合には、“ＶＮＦＭ１”からオーケストレータ２０に対して、ＮＷ情報として“外部ＩＰアドレス１０”“外部ＩＰアドレス１１”が設定された信号（９）が通知される（Ｓ１２２）。【0107】
オーケストレータ２０では、信号（９）が受け付けられる。信号（９）が受け付けられたオーケストレータ２０では、ＶＮＦ７０生成が完了したことが確認される。オーケストレータ２０では、Ｓ１１６の処理で記憶された再配置ＶＮＦ７０の情報と信号（９）に設定されているＮＷ情報が、サービスＩＤに対応付けられて生成時に作成された図１０（ａ）の表Ｔ２１に追加されて記憶される。情報の内容は図１３（ｂ）の表Ｔ３８となる（Ｋ、Ｓ１２３）。【0108】
再配置元ＶＮＦ７０が接続していたＶＮＦ７０である“ＶＮＦ２１”のＮＷ情報が、生成時に作成された図１３（ｂ）の表Ｔ３８より読み出され、ＮＷ接続が行われる。表Ｔ３８より読み出された“ＶＮＦ２１”の通信用の“外部ＩＰアドレス２０”と、信号（９）で受信された再配置された“ＶＮＦ１０”の通信用の“外部ＩＰアドレス１０”が設定された接続要求が、図５（ｄ）の表Ｔ６から特定されるＶＮＦ７０間ネットワークを管理する“ＶＩＭ−ＮＷ”に対して行われる（信号（１０）、Ｓ１２４）。“ＶＩＭ−ＮＷ”では、信号（１０）が受信されて、それに対する応答がオーケストレータ２０に送信される（Ｓ１２５）。信号（１０）が受信された“ＶＩＭ−ＮＷ”では、“外部ＩＰアドレス２０”と、“外部ＩＰアドレス１０”との接続が実施される（Ｌ、Ｓ１２６）。【0109】
オーケストレータ２０では、Ｓ１２４の接続要求に対する“ＶＩＭ−ＮＷ”からの応答（Ｓ１２５）が受信される。続いて、オーケストレータ２０では、ＶＮＦ７０間接続が完了したら、信号（９）で受信した“ＶＮＦ１０”のＶＮＦ種別、ＶＮＦ識別番号、性能、ＮＷ情報が信号（１１）でＯＳＳ５１に通知される（Ｓ１２７）。ＯＳＳ５１では、信号（１１）が受信されて、信号（１）の要求内容と信号（１１）の結果とを対応付けて生成時の図１０（ａ）の表Ｔ２２に追記した図１３（ｃ）の表Ｔ３９が保持される（Ｍ、Ｓ１２８）。この後、ＯＳＳ５１は、対向する“ＶＮＦ１０”の切り替えを通知するために、再配置された“ＶＮＦ１０”のＮＷ情報をＥＭＳ８０を通じて“ＶＮＦ２１”に通知することにより運用が再開される。ＯＳＳ５１は、再配置された“ＶＮＦ１０”と接続先の“ＶＮＦ２１”の通信が開始されたことを確認した後に、再配置元の“ＶＮＦ１０”に対して、停止や終了の保守操作を開始する。以上が、（２）オートヒーリングが行われる場合の処理である。【0110】
続いて、図１９及び図２０のシーケンス図を用いて、（３）スケールアウトが行われる場合の処理を説明する。なお、図２０に示すシーケンス図は、図１９のシーケンス図と（時系列的に）連続するものである。スケールアウトとは、ＶＮＦ７０の負荷が大きくなった場合にＶＮＦ７０の負荷分散をさせるため等に、当該ＶＮＦ７０と同じ機能を有するＶＮＦ７０を生成することである。スケールアウトにより、移動体通信システム１において適切な負荷分散等が図られる。【0111】
ＯＳＳ５１は、従来システム同様に運用管理システムであるＥＭＳ８０を通じて、インスタンシエーション処理（手順）で生成したＶＮＦ７０の状態を監視して運用する。ＥＭＳ８０は、ＶＮＦ７０からの状態情報の通知を受信し（Ｓ２０１）、受信した状態情報をＯＳＳ５１に送信する（Ｓ２０２）。上記の処理は、定期的に行われる。ＯＳＳ５１は、運用中に状態情報に基づき、ＶＮＦ７０の負荷上昇を検知し、運用中に一定レベルを上回る負荷への上昇をしたＶＮＦ７０の性能を増強することができる。インスタンシエーション処理で生成した“ＶＮＦ１０”“ＶＮＦ２１”のうち、“ＶＮＦ１０”の負荷上昇を検出したＯＳＳ５１が、ＶＮＦ７０の性能の１００％増強を決定し、オーケストレータ２０に対して要求する例を記載する。【0112】
ＯＳＳ５１からオーケストレータ２０に対して、増強元ＶＮＦ７０生成時に使用したサービスＩＤ、増強対象を識別するためのＶＮＦ識別番号“ＶＮＦ＿００１”、増強する性能を示す性能条件（例えば、現状同等の性能指標値）である“１００”、ＮＷ条件として現状と別ＤＣへの設置を意味する“別ＤＣ”を設定した信号（１）が送信される（Ｓ２０３）。【0113】
オーケストレータ２０では、要求受付部２１によって、サービス増強要求が受け付けられる（Ｓ２０３、要求受付ステップ）。サービス増強要求が受け付けられたオーケストレータ２０では、サービスＩＤとＶＮＦ識別番号が用いられて、増強元のＶＮＦ７０に関する情報として、ＶＮＦ種別、データセンタがＶＮＦ７０生成時に記憶したデータより特定される。図１０（ａ）の表Ｔ２１より、サービスＩＤとＶＮＦ識別番号“ＶＮＦ＿００１”に対応するＶＮＦ種別が“ＶＮＦ１０”、データセンタが“ＤＣ２”、“ＶＮＦ１０”のＶＮＦＭ３０が図５（ｂ）の表Ｔ３より“ＶＮＦＭ１”であることが導き出される（Ａ、Ｓ２０４）。【0114】
続いて、オーケストレータ２０では、上記で特定した“ＶＮＦ１０”を増強するために、“ＶＮＦ１０”を配置可能なデータセンタが、運用条件及び信号（１）により入力されたＮＷ条件及び図５（ｅ）の表Ｔ５のデータセンタの接続構成が用いられて選択される。図５（ｃ）の表Ｔ４から、“ＶＮＦ１０”の配置可能なデータセンタとして“ＤＣ２”“ＤＣ３”“ＤＣ４”“ＤＣ５”が候補として得られる。次に、入力されたＮＷ条件より増強元ＶＮＦ７０の“ＤＣ２”とは別データセンタであることと、増強元と接続先のＶＮＦ７０が配置されている“ＤＣ２”に接続しているデータセンタが、“ＤＣ１”“ＤＣ３”“ＤＣ５”という図５（ｅ）の表Ｔ５から得られる接続情報より、候補のデータセンタが“ＤＣ３”“ＤＣ５”とされる。【0115】
続いて、オーケストレータ２０では、定期収集により蓄積しているネットワーク全体資源情報データベースの図４（ａ）の表Ｔ１から、候補となった “ＤＣ３”“ＤＣ５”の資源情報が読み出される。読み出された資源情報を、図１１（ａ）の表Ｔ３１に示す。続いて、増強するＶＮＦ７０をユニークに識別する番号としてＶＮＦ識別番号“ＶＮＦ＿０１０”が払い出される（Ｂ、Ｓ２０５）。【0116】
続いて、増強ＶＮＦ識別番号“ＶＮＦ＿０１０”、配置可能なデータセンタ候補の情報として図１１（ａ）の表Ｔ３１、増強元ＶＮＦ識別番号に“ＶＮＦ＿００１”、信号（１）で入力されたサービスＩＤと性能条件の“１００が、上記のＡ（Ｓ２０４）で読み出された“ＶＮＦ１０”のＶＮＦＭ３０である“ＶＮＦＭ１”に、必要資源問い合わせ（信号（２））として送信される（Ｓ２０６）。【0117】
なお、Ｓ２０６において、各データセンタの資源情報を含めない実施形態も可能となる。この場合には、各データセンタの資源情報の代わりに、各データセンタを管理するＶＩＭ４０の識別番号が、図５（ｄ）の表Ｔ６から読み出され、Ｓ２０６において送信される情報に含められる。例えば、“ＤＣ３”のＶＩＭ４０が“ＶＩＭ１”、“ＤＣ５”のＶＩＭ４０が“ＶＩＭ３”という組み合わせが送信される情報に含められる。【0118】
信号（２）は、“ＶＮＦＭ１”において受信される。信号（２）を受信した“ＶＮＦＭ１”では、各データセンタに対する資源情報の設定有無（信号（２）に資源情報が含まれているか否か）が確認される。資源情報ではなくＶＩＭ識別番号が設定されてきた場合、“ＶＮＦＭ１”は自身で各データセンタの資源情報をＶＩＭ４０に要求し収集する。例えば、“ＶＮＦＭ１”によって、信号（２）で受け付けられた“ＶＩＭ１”に対して“ＤＣ３”の、“ＶＩＭ３”に対して“ＤＣ５”の資源情報が問い合わせられ、図１１（ａ）の表Ｔ３１が得られる（Ｓ２０７、Ｓ２０８）。【0119】
信号（２）、若しくはＳ２０７及びＳ２０８の処理にてデータセンタの資源情報（図１１（ａ）の表Ｔ３１）を入手した“ＶＮＦＭ１”では、信号（２）のＶＮＦ種別に設定されていた“ＶＮＦ１０”の詳細情報が、予め“ＶＮＦＭ１”の保持部３１に保持（登録）されているＶＮＦ詳細情報データベースより読み出される。詳細情報には図６の表Ｔ９のＶＮＦ内部構造と性能条件に応じた資源情報（ＶＭ）、資源情報（ＮＷ）、機能情報が登録されている。【0120】
“ＶＮＦＭ１”では、読み出された詳細情報（図６の表Ｔ９）から信号（２）で受け付けたＶＮＦ種別“ＶＮＦ１０”の性能条件“１００”に必要な資源情報と機能情報が取り出される（Ｃ１、Ｓ２０９）。【0121】
取り出された資源情報及び機能情報と、信号（２）、若しくはＳ２０７及びＳ２０８の処理にて得られた資源情報（図１１（ａ）の表Ｔ３１）の使用可能資源情報と提供機能とが比較されて、利用可能なデータセンタが抽出される。具体的には図６の表Ｔ９より“ＶＮＦ１０”は“機能１”及び“機能２”を必要とし、図１１（ａ）の表Ｔ３１より“機能１”及び“機能２”を、候補の“ＤＣ３”及び“ＤＣ５”は共に提供可能であることが判断される。【0122】
次に、利用可能なデータセンタの提供する資源でＶＮＦ７０を生成するために必要な資源情報が導き出される。具体的には図１１（ａ）の表Ｔ３１より、“ＤＣ３”がＬｏｗ、“ＤＣ５”がＨｉｇｈのＣＰＵ性能を提供可能であることが判別できる。これが、Ｓ２０９の処理で読み出された図６の表Ｔ９のＣＰＵ性能と照らし合わされて、“ＤＣ３”及び“ＤＣ５”で取り得る資源情報の組み合わせとして図１１（ｂ）の表Ｔ３２が得られる。詳細には、Ｓ２０９の処理で読み出された図６の表Ｔ９より、“ＶＮＦ１０”は内部機能部“ＶＮＦＣ１００”と“ＶＮＦＣ１０１”から構成されることが分かる。さらに、性能条件“１００”の場合には、内部機能部“ＶＮＦＣ１００”は、ＣＰＵ性能“Ｈｉｇｈ”を用いた型番“００１”またはＣＰＵ性能“Ｌｏｗ”を用いた型番“００２”の仮想資源（ＶＭ、ＮＷ）により生成可能であり、内部機能部“ＶＮＦＣ１０１”は、ＣＰＵ性能“Ｈｉｇｈ”を用いた型番“００５”またはＣＰＵ性能“Ｌｏｗ”を用いた型番“００６”の仮想資源（ＶＭ、ＮＷ）により生成可能であることが分かる。これより、信号（２）で指示されたＶＮＦ種別“ＶＮＦ１０”の性能条件“１００”となるＶＮＦ７０を生成するのに必要な仮想資源の組み合わせは、ＣＰＵ性能”Ｌｏｗ”を提供可能な“ＤＣ３”では１通り、ＣＰＵ性能”Ｈｉｇｈ”を提供可能な“ＤＣ５”でも１通りとなり、“ＤＣ３”及び“ＤＣ５”で取り得る資源情報の組み合わせとして図１１（ｂ）の表Ｔ３２が得られる。信号（２）のサービスＩＤ、増強ＶＮＦ種別及び増強ＶＮＦ識別番号、並びに詳細情報の図６の表Ｔ９が記憶される（Ｃ２、Ｓ２１０）。【0123】
続いて、“ＶＮＦＭ１”からオーケストレータ２０に、導出された資源情報とデータセンタの組み合わせを示す図１１（ｂ）の表Ｔ３２が返送される（信号（３）、Ｓ２１１）。【0124】
オーケストレータ２０では、予約要求部２２によって信号（３）が受信される。信号（３）で受信された資源情報とデータセンタの組み合わせ表（図１１（ｂ）の表Ｔ３２）に、図５（ｆ）の表Ｔ１２の優先度指標が適用される。表Ｔ１２より、第１優先はデータセンタ間帯域であり、図５（ｅ）の表Ｔ５より接続先ＶＮＦ７０である“ＶＮＦ２１”の“ＤＣ２”と“ＤＣ３”との間、“ＤＣ２”と“ＤＣ５”との間の帯域では、“ＤＣ２”と“ＤＣ３”との間の帯域が大きいことが判断できる。これに基づき優先度が付与され、図１１（ｃ）の表Ｔ３３が得られる（Ｄ、Ｓ２１２）。【0125】
続いて、優先度の高い組み合わせの順番に、データセンタを管理するＶＩＭ４０への予約が実施される。予約要求部２２によって、図１１（ｃ）の表Ｔ３３で優先度の最も高い“ＤＣ３”の組み合わせ１の必要資源と対象の“ＤＣ３”が設定されて、資源の予約要求が、図５（ｄ）の表Ｔ６より読み出された“ＤＣ３”の管理機能である“ＶＩＭ１”に送出される（信号（４）、Ｓ２１３、予約要求ステップ）。図１１（ｃ）の表Ｔ３３の優先度１の組み合わせの場合は、図１２（ａ）の表Ｔ３４の情報が必要資源情報（ＶＭ、ＮＷ）となる。資源予約が失敗した場合は、次優先度の組み合わせの予約要求が行われる（Ｆ、処理Ｓ２１６からの戻り）。【0126】
“ＶＩＭ１”では、信号（４）が受け付けられる。信号（４）が受け付けられた“ＶＩＭ１”では、予約部４２によって、信号（４）に設定されている“ＤＣ３”に信号（４）で要求された、図１２（ａ）の表Ｔ３４に示される必要資源を確保できるかが、管理域内資源情報データベースをもとに確認され、資源が予約されて予約番号１０が払い出される（Ｅ、Ｓ２１４、予約ステップ）。“ＶＩＭ１”では、予約番号１０とともに、予約した“ＤＣ３”、予約された資源情報が記憶される。“ＶＩＭ１”では、資源が確保できた場合には予約番号が、資源が確保できない場合にはエラーがオーケストレータ２０に応答される（信号（５）、Ｓ２１５）。【0127】
オーケストレータ２０では、“ＶＩＭ１”からの信号（５）が受信される。“ＶＩＭ１”からの信号（５）が受信されたオーケストレータ２０では、資源の予約結果が確認される（Ｆ、Ｓ２１６）。資源の予約が出来なかった場合（Ｆ、Ｓ２１６のＮＧ）には、再度、Ｄ（Ｓ２１２）の処理に戻り次優先度の組み合わせの予約が実施される。【0128】
オーケストレータ２０では、予約が成功したら、増強元ＶＮＦ７０生成時のサービスＩＤ、資源予約先のＶＩＭ識別番号として“ＶＩＭ１”、図５（ｄ）の表Ｔ６から取得されたＶＩＭ種別、及び“ＶＩＭ１”から信号（５）で受信された予約番号、予約資源情報（ＶＭ、ＮＷ）として図１２（ａ）の表Ｔ３４の資源情報が設定され、“ＶＮＦＭ１”に“ＶＮＦ１０”の増強が要求される（信号（６）、Ｓ２１７）。また、オーケストレータ２０では、増強ＶＮＦの情報として、サービスＩＤと、ＶＮＦ種別、ＶＮＦ識別番号、予約番号、予約した“ＶＩＭ１”、予約した“ＤＣ３”が記憶される。【0129】
“ＶＮＦＭ１”では、仮想サーバ生成要求部３２によって、信号（６）が受信される。続いて、仮想サーバ生成要求部３２によって、信号（６）で受信されたサービスＩＤより、Ｃ２（Ｓ２１０）で記憶されている詳細情報の図６の表Ｔ９が読み出され、信号（６）で受信された予約資源情報（ＶＭ、ＮＷ）の図１２（ａ）の表Ｔ３４の型番“００２”、“００６”に対応する配置・起動情報、ＮＷ（ネットワーク）構成情報が決定される。続いて、仮想サーバ生成要求部３２によって、生成する仮想マシン（ＶＭ）にＶＭ識別番号が払い出され付与される。【0130】
続いて、“ＶＮＦＭ１”では、仮想サーバ生成要求部３２によって、信号（６）で受信されたＶＩＭ種別に応じて、配置・起動情報、ＮＷ構成情報の書式が変更される（ＶＩＭ４０の管理方式に応じて詳細情報が書き換えられる）（Ｇ、Ｓ２１８、仮想サーバ生成要求ステップ）。【0131】
続いて、仮想サーバ生成要求部３２によって、“ＶＩＭ１”用に書式が変更された配置・起動情報とＮＷ構成情報、信号（６）で受信された予約番号が、信号（６）で受信された予約先の“ＶＩＭ１”に通知され、“ＶＮＦ１０”の生成が要求される（信号（７）、Ｓ２１９、仮想サーバ生成要求ステップ）。配置・起動情報、ＮＷ構成情報として設定される情報は図１２（ｂ）の表Ｔ３５となる。“ＶＮＦＭ１”では、Ｃ２（Ｓ２１０）で記憶されたサービスＩＤ、ＶＮＦ種別、ＶＮＦ識別番号に、信号（６）で受けたＶＩＭ識別番号、予約番号と図６の表Ｔ９から読み出された内部機能部、払い出したＶＭ識別番号が対応付けられて記憶される。【0132】
“ＶＩＭ１”では、仮想サーバ生成部４３によって、信号（７）が受信される。続いて、仮想サーバ生成部４３によって、信号（７）で受け付けられた予約番号よりＶＮＦ７０を起動する資源としてＥ（Ｓ２１４）の処理で確保された“ＤＣ３”の資源が特定される。続いて、仮想サーバ生成部４３によって、信号（７）で受け付けた配置・起動情報とＮＷ構成情報に基づき“ＤＣ３”にＶＭ及びＶＮＦのイメージファイルが読み込まれて、ＶＭ及びＶＮＦ７０が生成・起動される。【0133】
“ＶＩＭ１”では、仮想サーバ生成部４３によって、予め割り当てられている外部ＩＰアドレス帯域から、信号（７）で指定された数の外部アドレスとして“外部ＩＰアドレス１０”“外部ＩＰアドレス１１”がＶＭに付与される。“ＶＩＭ１”では、Ｅ（Ｓ２１４）の処理の予約番号と、データセンタに加えて、“ＶＮＦＭ１”のＶＭ識別番号、割り当てられた資源情報と物理装置（ＨＷ）の対応付けとして、図１４（ａ）の表Ｔ４１の情報が記憶される（Ｈ、図２０のＳ２２０、仮想サーバ生成ステップ）。【0134】
続いて、仮想サーバ生成部４３によって、ＶＭ生成時に割り当てられた外部ＩＰアドレスがＮＷ情報として設定された図１２（ｃ）の表Ｔ３６が信号（８）で“ＶＮＦＭ１”に応答される（Ｓ２２１）。【0135】
“ＶＮＦＭ１”では、Ｇ（Ｓ２１８）の処理で記憶されたサービスＩＤに関連する情報に信号（８）に設定されているＮＷ情報が追加されて記憶される。情報の内容は図１３（ａ）の表Ｔ３７となる（Ｊ、Ｓ２２２）。【0136】
ＶＮＦ生成が成功した場合には、“ＶＮＦＭ１”からオーケストレータ２０に対して、ＮＷ情報として“外部ＩＰアドレス１０”“外部ＩＰアドレス１１”が設定された信号（９）が通知される（Ｓ２２３）。【0137】
オーケストレータ２０では、信号（９）が受け付けられる。信号（９）が受け付けられたオーケストレータ２０では、ＶＮＦ７０生成が完了したことが確認される。オーケストレータ２０では、Ｓ２１７の処理で記憶された増強ＶＮＦ７０の情報と信号（９）に設定されているＮＷ情報が、サービスＩＤに対応付けられて生成時に作成された図１０（ａ）の表Ｔ２１に追加されて記憶される。情報の内容は図１３（ｂ）の表Ｔ３８となる（Ｋ、Ｓ２２４）。【0138】
増強元ＶＮＦ７０が接続しているＶＮＦ７０である“ＶＮＦ２１”のＮＷ情報が、生成時に作成された図１３（ｂ）の表Ｔ３８より読み出され、ＮＷ接続が行われる。表Ｔ３８より読み出された“ＶＮＦ２１”の通信用の“外部ＩＰアドレス２０”と、信号（９）で受信された増強された“ＶＮＦ１０”の通信用の“外部ＩＰアドレス１０”が設定された接続要求が、図５（ｄ）の表Ｔ６から特定されるＶＮＦ７０間ネットワークを管理する“ＶＩＭ−ＮＷ”に対して行われる（信号（１０）、Ｓ２２５）。“ＶＩＭ−ＮＷ”では、信号（１０）が受信されて、それに対する応答がオーケストレータ２０に送信される（Ｓ２２６）。信号（１０）が受信された“ＶＩＭ−ＮＷ”では、“外部ＩＰアドレス２０”と、“外部ＩＰアドレス１０”との接続が実施される（Ｌ、Ｓ２２７）。【0139】
オーケストレータ２０では、Ｓ２２５の接続要求に対する“ＶＩＭ−ＮＷ”からの応答（Ｓ２２６）が受信される。続いて、オーケストレータ２０では、ＶＮＦ７０間接続が完了したら、信号（９）で受信した“ＶＮＦ１０”のＶＮＦ種別、ＶＮＦ識別番号、性能、ＮＷ情報が信号（１１）でＯＳＳ５１に通知される（Ｓ２２８）。ＯＳＳ５１では、信号（１１）が受信されて、信号（１）の要求内容と信号（１１）の結果とを対応付けて生成時の図１０（ａ）の表Ｔ２２に追記した図１３（ｃ）の表Ｔ３９が保持される（Ｍ、Ｓ２２９）。以上が、（３）スケールアウトが行われる場合の処理である。【0140】
続いて、図２１及び図２２のシーケンス図を用いて、（４）スケールインが行われる場合の処理を説明する。なお、図２２に示すシーケンス図は、図２１のシーケンス図と（時系列的に）連続するものである。スケールインとは、負荷が低い同じ機能を有する複数のＶＮＦ７０がある場合等に、ＶＮＦ７０を集約することである。スケールインにより、移動体通信システム１において適切な資源の活用が図られる。【0141】
ＯＳＳ５１は、従来システム同様に運用管理システムであるＥＭＳ８０を通じて、インスタンシエーション処理（手順）で生成し、更にスケールアウト処理（手順）で増強したＶＮＦ７０の状態を監視して運用する。ＥＭＳ８０は、ＶＮＦ７０からの状態情報の通知（信号（１））を受信し（Ｓ３０１）、受信した状態情報（信号（１））をＯＳＳ５１に送信する（Ｓ３０２）。上記の処理は、定期的に行われる。ＯＳＳ５１は、運用中に状態情報に基づき、ＶＮＦの負荷低減を検知し、運用中に一定レベルを下回る負荷への低減をしたＶＮＦ７０の性能を削減することができる。上述したスケールアウト処理で増強して、複数となった“ＶＮＦ１０”について、一定レベルを下回る負荷への低下を検知したＯＳＳ５１が、“ＶＮＦ１０”全体の性能の削減を決定し、オーケストレータ２０に対して要求する例を記載する。【0142】
ＯＳＳ５１では、オーケストレータ２０を通じて生成、増強又は削減したＶＮＦ７０のサービス種別について、図１３（ｃ）の表Ｔ３９のように管理されている。【0143】
ＯＳＳ５１では、上記の信号（１）にあるようにＶＮＦ７０から定期的にＶＮＦ７０の負荷量が収集され、同一機能のＶＮＦ７０について、統合しても負荷が十分に定格以内に収まるのであれば、分散した処理のスケールイン統合が判断される。例えば、ＯＳＳ５１では、信号（１）（メッセージ（１））で取得された複数のＶＮＦ７０（“ＶＮＦ＿００１”と“ＶＮＦ＿０１０”）のうち、より負荷量の少ないほうを削除対象とする（Ａ、Ｓ３０３）。【0144】
ＯＳＳ５１では、図１３（ｃ）の表Ｔ３９が参照されて、同サービスにて、削除対象となるＶＮＦ７０と接続している対向ノード（表Ｔ３９では、“ＶＮＦ＿０２１”）が判断され、対向ノードに対して、新たに発生するトラヒックについて削除対象のＶＮＦ７０（“ＶＮＦ＿０１０”）に送信しないように、ＥＭＳ８０を介して信号（２）にて構成変更が指示される（Ｓ３０４、Ｓ３０５）。【0145】
“ＶＮＦ＿０２１”では、信号（２）が受信されて、対向している“ＶＮＦ＿００１”と“ＶＮＦ＿０１０”に負荷分散していたトラヒックについて、削除対象のＶＮＦ７０（“ＶＮＦ＿０１０”）に新たなトラヒックを送信しないように構成変更が行われ（Ｓ３０６）、応答メッセージ（３）（信号（３））がＥＭＳ８０を介してＯＳＳ５１に返信される（Ｓ３０７、Ｓ３０８）。【0146】
ＯＳＳ５１では、当該応答メッセージ（３）（信号（３））が受信される。続いて、ＯＳＳ５１では、ＥＭＳ８０を介して削除対象となるＶＮＦ７０（“ＶＮＦ＿０１０”）に対して、メッセージ（４）（信号）にて閉塞、ユーザ追出し要求が行われる（Ｓ３０９、Ｓ３１０）。【0147】
“ＶＮＦ＿０１０”では、既に収容しているユーザトラヒックについて処理が完了するのが待たれ（又は強制終了され）、処理が収斂される（Ｃ、Ｓ３１１）。続いて、“ＶＮＦ＿０１０”から、ＥＭＳ８０を介してＯＳＳ５１に対して応答メッセージ（５）（信号（５））が返信される（Ｓ３１２、Ｓ３１３）。【0148】
ＯＳＳ５１では、当該応答メッセージ（５）（信号（５））が受信される。続いて、ＯＳＳ５１では、ＶＮＦ生成時に使用したサービスＩＤ、削減対象を識別するためのＶＮＦ識別番号“ＶＮＦ＿０１０”、削減する性能を示す性能条件は、削減したい性能値である“１００”が設定された信号（６）が生成され（Ｓ３１４）、サービス削減要求としてオーケストレータ２０に対して送信される（図２２のＳ３１５）。【0149】
オーケストレータ２０では、サービス削減要求が受け付けられる。サービス削減要求が受け付けられたオーケストレータ２０では、サービスＩＤとＶＮＦ識別番号が用いられて、削減対象のＶＮＦ７０に関する情報として、ＶＮＦ種別、データセンタがＶＮＦ７０作成又は増強時に記憶したデータより特定される。図１３（ｂ）の表Ｔ３８より、サービスＩＤとＶＮＦ識別番号“ＶＮＦ＿０１０”に対応するＶＮＦ種別が“ＶＮＦ１０”、データセンタが“ＤＣ３”、“ＶＮＦ１０”のＶＮＦＭ３０が図５（ｂ）の表Ｔ３より“ＶＮＦＭ１”であることが導き出される（Ｅ、Ｓ３１６）。【0150】
続いて、オーケストレータ２０では、上記で特定した“ＶＮＦ＿０１０”を削除するために、図１３（ｂ）の表Ｔ３８より、削除対象となるＶＮＦ７０生成時のサービスＩＤ、削除対象となるＶＮＦ種別、ＶＮＦ識別番号、予約先のＶＩＭ識別番号（“ＶＩＭ１”）、予約番号（“１０”）が得られる（Ｆ、Ｓ３１７）。オーケストレータ２０では、“ＶＮＦＭ１”に対して、これらの情報が含められて信号（７）により、“ＶＮＦ＿０１０”の削減が要求される（Ｓ３１８）。【0151】
“ＶＮＦＭ１”では、信号（７）が受信される。“ＶＮＦＭ１”では、信号（７）で受信されたＶＮＦ削減要求メッセージから、サービスＩＤ、ＶＮＦ種別、ＶＮＦ識別番号、ＶＩＭ識別番号、予約番号が得られて、図６（ａ）の表Ｔ９より削減手順が得られる（Ｇ、Ｓ３１９）。続いて、“ＶＮＦＭ１”では、“ＶＩＭ１”に対して、ＶＮＦ削減要求メッセージである信号（８）によって、予約番号により、該当のＶＭの削減が要求される（Ｓ３２０）。【0152】
“ＶＩＭ１”では、信号（８）で受信したＶＮＦ削減要求メッセージから、予約番号が得られて、図１４（ａ）の表Ｔ４１より、削除対象となるＤＣ番号“ＤＣ３”とＶＭ識別番号を得て、ＶＭの削減が実行される（Ｈ、Ｓ３２１）。続いて、“ＶＩＭ１”では、信号（９）により、ＶＮＦ削減応答が、“ＶＮＦＭ１”を介してオーケストレータ２０に返信される（Ｓ３２２、Ｓ３２３）。“ＶＮＦＭ１”では、図１３（ａ）の表Ｔ３７から“ＶＮＦ＿０１０”を削減した図１０（ｃ）の表Ｔ２３が保持される。【0153】
オーケストレータ２０では、ＶＮＦ削減応答（ＶＮＦ削除応答メッセージ）が受信される。続いて、オーケストレータ２０では、図１３（ｂ）の表Ｔ３８より、削除を行ったＶＮＦ７０間の接続の解放要求が生成されて（Ｊ、Ｓ３２４）、信号（１０）により“ＶＩＭ−ＮＷ”に送信される（Ｓ３２５）。【0154】
“ＶＩＭ−ＮＷ”では、信号（１０）が受信されて、解放要求に対する応答が行われる（Ｓ３２６）。また、“ＶＩＭ−ＮＷ”では、ＶＮＦ７０間の接続の解放が実施される（Ｋ、Ｓ３２７）。【0155】
オーケストレータ２０では、“ＶＩＭ−ＮＷ”からの応答が受信されて、図１３（ｃ）の表Ｔ３８から“ＶＮＦ＿０１０”を削減した図１０（ａ）の表Ｔ２１が保持され、信号（１１）によって、サービス削減応答がＯＳＳ５１に対して行われる（Ｓ３２８）。【0156】
ＯＳＳ５１では、信号（１）の要求内容と信号（１１）の結果を対応付けて、生成時の図１３（ｃ）の表Ｔ３９からＶＮＦを削減した図１４（ｂ）の表Ｔ４３の情報が保持される（Ｓ３２９）。以上が、（４）スケールインが行われる場合の処理である。【0157】
上述した実施形態では、仮想通信機能（ＶＮＦ７０）単位での増強・削減手順を示したが、一般には、ＶＮＦ７０は１つ以上の内部機能部（ＶＮＦＣ）から構成され、内部機能部単位に増強・削減する運用も実施されている。【0158】
上述した実施形態では、スケールアウト、スケールイン、オートヒーリングにおいてインスタンシエーションと共通のＶＮＦ詳細情報（図６の表Ｔ９）を用いた。しかし、予め内部機能部単位の増強・削減パターンをＶＮＦ詳細情報として登録し、生成（起動）しているＶＮＦ７０の内部機能部の組み合わせを基に、指定された性能条件を満たす内部機能部の増強・削減パターンを抽出する手順を追加することにより、内部機能部単位の増強・削減が可能となる。【0159】
この際、ＶＮＦ単位の操作対象を識別していたＶＮＦ識別番号を内部機能部単位の操作を特定できる識別子とする必要がある。例えば、１つのＶＮＦ内の内部機能部の上限数（図２６（ａ）の表ＴＸ）、ＶＮＦ内部機能単位の増強・削除パターン（図２６（ｂ）の表ＴＹ）、を詳細情報として予めＶＮＦＭ３０のデータベースに追加登録しておく。【0160】
スケールアウトの場合、以下のように行われる。図１９のスケールアウトの処理における処理（手順）Ｃ１での増強元ＶＮＦの詳細情報の読み出しの際に、図２４のフローチャートで示される増強単位の判断を追加する。Ｓ２０６の信号（２）にてＶＮＦ１０の増強として性能条件“１００”を受信する例を記載する。処理（手順）Ｃ１で増強元ＶＮＦの詳細情報（図１３（ａ）の表Ｔ３７）を読み出し、増強元ＶＮＦのＶＭ数を図２６（ａ）の表ＴＸの上限数と比較し、上限数に達していない場合にはＶＮＦＣ単位の増強を行うと判断する。次に予めＶＮＦＭ３０に登録されている図２６（ｂ）の表ＴＹより、性能条件“１００”に必要な資源情報と機能情報として型番“１０１”の構成が取り出される。【0161】
増強単位をＶＮＦ７０単位とするか内部機能部単位とするかをＶＮＦＭ３０で判断するのではなくＯＳＳ５１から指示することも可能である。内部機能部単位の増強パターンが表ＴＹより抽出された以降は、上述したスケールアウトの実施形態と同様の手順を適用する。【0162】
スケールインの場合、以下のように行われる。図２２のスケールインの処理における処理（手順）Ｇでの削減ＶＮＦの詳細情報の読み出しの際に、図２５のフローチャートで示される削減単位の判断を追加し、１つの削減パターンを抽出する。ＶＮＦＭ３０が削減単位を判断するために、図２２のシーケンス図においてＯＳＳ５１では信号（６）で受信した性能条件“１００”を信号（７）に含めてＶＮＦＭ３０に対して要求される。ＶＮＦＭ３０では受信された信号（７）よりＶＮＦ識別番号、性能条件が得られる。ＶＮＦＭ３０”では、信号（７）で受信されたＶＮＦ識別番号を基に、保持する削減元ＶＮＦの詳細情報（図１３（ａ）の表Ｔ３７）を読み出し、削減元ＶＮＦのＶＭ数を図２６（ａ）の表の最小構成数と比較し、最小構成でなければＶＮＦＣ単位の削減を行うと判断する。次に予めＶＮＦＭ３０に登録されている図２６（ｂ）の表ＴＹより、性能条件“１００”に対応する資源情報と機能情報として型番“１０１”の構成が取り出され、削減対象の資源と手順を得る。【0163】
削減単位をＶＮＦ７０単位とするか内部機能部単位とするかをＶＮＦＭ３０で判断するのではなくＯＳＳ５１から指示することも可能である。内部機能部単位の削減パターンが表ＴＹより抽出された以降は、上述したスケールインの実施形態と同様の手順を適用する。【0164】
仮想化機能の性能増減単位と実施形態との関係を図２７に示す。【0165】
本発明の実施形態のバリエーションを図２８に示す。図２８において、「選択」は、候補となる資源エリア（ＶＩＭ４０／データセンタ）の抽出を示す。「予約」は、候補エリアの中から資源予約の依頼を行うことを示す。「配置計画」は、予約資源へのＶＮＦ７０の配置計画作成を示す。「割当」は、配置計画に基づく資源割当（ＶＮＦ７０の生成）を示す。「詳細条件」は、配置計画を作成するための条件を示す。「条件」は、詳細条件を抽象化した条件を示す。「全体」は、全体資源情報を示す。域内は、管理域内資源情報を示す。また、図２８中の破線の領域に示したように、プロプライエタリではない資源情報は何れの経路でも入手可能である。【0166】
上述した実施形態は、ＶＩＭ４０（データセンタ）の選択をＶＮＦＭ３０が、ＶＮＦ７０の配置計画の生成をＶＮＦＭ３０が、ＶＩＭ４０へのＶＮＦ７０の生成の指示をＶＮＦＭ３０が、それぞれ行うパターンであった（図２８のパターンの左から２つ目のパターン）。しかしながら、ＶＩＭ（データセンタ）４０の選択をＶＮＦＭ３０ではなく、オーケストレータ２０が行うパターンとしてもよい（図２８のパターンの左から１つ目のパターン）。【0167】
本実施形態に係る管理システム１０では、ＶＮＦＭ３０によって自身が保持する詳細情報が用いられて、ＶＩＭ４０に対してＶＮＦ７０を生成させる要求が行われる。従って、詳細情報（具体的には、図６の表Ｔ９の配置・起動情報及びＮＷ構成情報）をＶＮＦＭ３０からオーケストレータ２０に通知する必要がなく、当該ＶＮＦ７０の生成が行われる。即ち、本実施形態に係る管理システム１０によれば、通信処理を実行するＶＮＦ７０を仮想化資源上において実現するための詳細情報の漏洩を防止することができる。これによって、マルチベンダの促進を図ることができる。【0168】
例えば、ＶＮＦＭ３０とオーケストレータ２０とは、別々のベンダによって提供される場合であっても、ＶＮＦＭ３０を提供するベンダのノウハウであるＶＮＦ７０の詳細情報が、オーケストレータ２０のベンダへ漏洩することがない。【0169】
なお、上述した実施形態では、移動通信端末に移動体通信の機能を提供する移動体通信システムであるものとしたが、本発明は、必ずしも移動体通信システムである必要はない。本発明は、固定の通信端末に固定通信の機能を提供する固定通信システムに適用することが可能である。固定の通信端末と固定通信システムとは、上述した移動体通信システムとは異なり、有線で接続されている。上述した実施形態を、移動通信端末を固定通信端末と、移動体通信を固定通信と、移動体通信システムを固定通信システムとそれぞれ置き換えることで本発明に係る固定通信システムの実施形態とすることができる。但し、この場合、具体的なノードは固定通信システムに応じたものである。また、移動体通信と固定通信とが混在した通信システムにおいて本発明を実施することも可能である。【0170】
即ち、本発明は、移動通信端末、移動体通信及び移動体通信システムに限られるものではなく、上述した実施形態と同様の枠組みを有するものであれば、任意の通信端末、任意の通信、及び任意の通信システムに適用することが可能である。【符号の説明】
【0171】
１…移動体通信システム、１０…管理システム、２０…オーケストレータ、２１…要求受付部、２２…予約要求部、３０…ＶＮＦＭ、３１…保持部、３２…仮想サーバ生成要求部、４０…ＶＩＭ、４１…監視部、４２…予約部、４３…仮想サーバ生成部、５０…ＯＳＳ／ＢＳＳ、５１…ＯＳＳ、６０…ＮＦＶＩ、７０…ＶＮＦ、８０…ＥＭＳ、１０１…ＣＰＵ、１０２…ＲＡＭ、１０３…ＲＯＭ、１０４…通信モジュール、１０５…補助記憶装置。