特許 7097340 リソース管理装置、リソース管理システム、リソース管理方法、およびプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2022-06-29

(45)【発行日】2022-07-07

(54)【発明の名称】リソース管理装置、リソース管理システム、リソース管理方法、およびプログラム

(51)【国際特許分類】

   H04L 41/5019 20220101AFI20220630BHJP

   H04L 41/0823 20220101ALI20220630BHJP

【ＦＩ】

H04L41/5019

H04L41/0823

【請求項の数】 6

(21)【出願番号】P 2019175955

(22)【出願日】2019-09-26

(65)【公開番号】P2021052365

(43)【公開日】2021-04-01

【審査請求日】2021-06-25

(73)【特許権者】

【識別番号】000208891

【氏名又は名称】ＫＤＤＩ株式会社

(74)【代理人】

【識別番号】100114258

【弁理士】

【氏名又は名称】福地 武雄

(74)【代理人】

【識別番号】100125391

【弁理士】

【氏名又は名称】白川 洋一

(74)【代理人】

【識別番号】100208605

【弁理士】

【氏名又は名称】早川 龍一

(72)【発明者】

【氏名】黒木 圭介

【審査官】野元 久道

(56)【参考文献】

【文献】米国特許出願公開第２０１９／０１７３８０３（ＵＳ，Ａ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｌ ４１／００

(57)【特許請求の範囲】

【請求項1】

仮想通信機器のリソースを管理するリソース管理装置であって、
目的とするネットワーク毎にネットワーク構築に必要な通信機器およびそのＳＬＡを管理し、ネットワーク構築指示をするネットワーク構築部と、
前記ネットワーク構築指示に基づいて、前記通信機器に対応する仮想通信機器の機能、前記機能が使用するハードウェアリソース、および性能値を確認し、前記仮想通信機器の構成を決定する通信機器構成部と、
前記決定された仮想通信機器の構成に基づいてハードウェアリソースを割り当てる機能構築部と、
前記ハードウェアリソースの使用状況を監視するリソース監視部と、を備え、
前記通信機器構成部は、前記ネットワーク構築指示に含まれるネットワークの優先度に基づいて、既に構築された１以上のネットワークを削除すると共に優先度の高いネットワークの仮想通信機器の構成を決定し、
前記通信機器構成部は、既に構築された１以上のネットワークを削除した後のリソースで前記優先度の高いネットワークの仮想通信機器を構成するときに、前記優先度の高いネットワークの仮想通信機器を構成した後のリソースの使用状況に基づいて、前記削除されるネットワークの仮想通信機器を構成できるか判断し、
前記削除されるネットワークの仮想通信機器を構成できる場合、前記削除されるネットワークの仮想通信機器の新たな構成を決定し、
前記削除されるネットワークの仮想通信機器を構成できない場合、その情報をユーザに通知することを特徴とするリソース管理装置。

【請求項2】

前記通信機器構成部は、前記仮想通信機器に複数の構成がある場合、前記複数の構成毎の性能値の１以上の値に基づいて前記仮想通信機器の構成を決定することを特徴とする請求項１記載のリソース管理装置。

【請求項3】

前記通信機器構成部は、前記リソース監視部の監視するリソースの使用状況に基づいて、現状のリソースまたは既に構築された１以上のネットワークを削除した後のリソースで前記仮想通信機器を構成できるがその構成の性能値では構築するネットワークのＳＬＡを満たさない場合、その情報をユーザに通知し、ユーザの指示に従い前記仮想通信機器の構成を決定することを特徴とする請求項１または請求項２記載のリソース管理装置。

【請求項4】

仮想通信機器のリソースを管理するリソース管理システムであって、
請求項１から請求項３のいずれかに記載のリソース管理装置と、
前記リソース管理装置と通信を行い、複数種類のハードウェアリソースを備えるハードウェアリソースプールを有する１以上のサーバと、
前記リソース管理装置に管理される、ネットワーク毎に必要な通信機器の種類およびそのＳＬＡを保持するネットワーク構成ＤＢ、前記通信機器の種類毎に対応する１以上の仮想通信機器の情報を保持する通信機器種別ＤＢ、前記仮想通信機器の機能構成、使用するハードウェアリソース、および性能値を保持する機能紐づけＤＢ、および、前記ハードウェアリソースプールのハードウェアリソースの使用状況を保持するリソースＤＢと、を備え、
前記サーバは、前記リソース管理装置の制御に従い、前記ハードウェアリソースプールのハードウェアリソースによって１以上の仮想通信機器を構成することでネットワークを構築することを特徴とするリソース管理システム。

【請求項5】

仮想通信機器のリソースを管理するリソース管理方法であって、
目的とするネットワーク毎にネットワーク構築に必要な通信機器およびそのＳＬＡを管理し、ネットワーク構築指示をするネットワーク構築ステップと、
前記ネットワーク構築指示に基づいて、前記通信機器に対応する仮想通信機器の機能、前記機能が使用するハードウェアリソース、および性能値を確認し、前記仮想通信機器の構成を決定する通信機器構成ステップと、
前記決定された仮想通信機器の構成に基づいてハードウェアリソースを割り当てる機能構築ステップと、
前記ハードウェアリソースの使用状況を監視するリソース監視ステップと、を含み、
前記通信機器構成ステップは、前記ネットワーク構築指示に含まれるネットワークの優先度に基づいて、既に構築された１以上のネットワークを削除すると共に優先度の高いネットワークの仮想通信機器の構成を決定し、
前記通信機器構成ステップは、既に構築された１以上のネットワークを削除した後のリソースで前記優先度の高いネットワークの仮想通信機器を構成するときに、前記優先度の高いネットワークの仮想通信機器を構成した後のリソースの使用状況に基づいて、前記削除されるネットワークの仮想通信機器を構成できるか判断し、
前記削除されるネットワークの仮想通信機器を構成できる場合、前記削除されるネットワークの仮想通信機器の新たな構成を決定し、
前記削除されるネットワークの仮想通信機器を構成できない場合、その情報をユーザに通知することを特徴とするリソース管理方法。

【請求項6】

仮想通信機器のリソースを管理するリソース管理プログラムであって、
目的とするネットワーク毎にネットワーク構築に必要な通信機器およびそのＳＬＡを管理し、ネットワーク構築指示をする処理と、
前記ネットワーク構築指示に基づいて、前記通信機器に対応する仮想通信機器の機能、前記機能が使用するハードウェアリソース、および性能値を確認し、前記仮想通信機器の構成を決定する処理と、
前記決定された仮想通信機器の構成に基づいてハードウェアリソースを割り当てる処理と、
前記ハードウェアリソースの使用状況を監視する処理と、の一連の処理をコンピュータに実行させ、
前記通信機器の構成を決定する処理は、前記ネットワーク構築指示に含まれるネットワークの優先度に基づいて、既に構築された１以上のネットワークを削除すると共に優先度の高いネットワークの仮想通信機器の構成を決定し、
前記通信機器の構成を決定する処理は、既に構築された１以上のネットワークを削除した後のリソースで前記優先度の高いネットワークの仮想通信機器を構成するときに、前記優先度の高いネットワークの仮想通信機器を構成した後のリソースの使用状況に基づいて、前記削除されるネットワークの仮想通信機器を構成できるか判断し、
前記削除されるネットワークの仮想通信機器を構成できる場合、前記削除されるネットワークの仮想通信機器の新たな構成を決定し、
前記削除されるネットワークの仮想通信機器を構成できない場合、その情報をユーザに通知することを特徴とするプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、アプリケーションのマイクロサービス化に対応できるリソース管理装置、リソース管理システム、リソース管理方法、およびプログラムに関する。

【背景技術】

【0002】

昨今、ＮＦＶ（Network Function Virtualization）に代表されるように、通信機器の仮想化が進み、汎用サーバ上で仮想通信機器が実現されるようになってきた。汎用サーバ上での仮想通信機器の実装は、一般的にはＣＰＵで実行されるが、処理性能向上のために、ＧＰＵやＦＰＧＡなどのアクセラレータの利用もされる。

【0003】

特許文献１は、どのアプリケーションが、どのアクセラレータを利用するかに関して、アプリケーションとアクセラレータを紐付け、アプリケーションの実行時に利用したいアクセラレータを利用できるかを確認後、リソースとして割り当てるアクセラレータ管理装置が開示されている。

【先行技術文献】

【特許文献】

【0004】

【文献】特開２０１３－１９６２０６号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

マイクロサービスアーキテクチャにおいては、アプリケーションは複数の小さな機能に分けられる。しかしながら、特許文献１記載の技術では、アプリケーション毎にアクセラレータを紐づけているため、アプリケーションの機能毎に使用するアクセラレータを管理することができない。また、ネットワークスライシングにおいて複数の仮想通信機器等のアプリケーションを含むサービスとアクセラレータが紐付けられる場合、有限のハードウェアリソースを効率よく使用するためには、複数のネットワークの優先順位などを考慮に入れた管理手法が必要となる。

【0006】

本発明は、このような事情に鑑みてなされたものであり、アプリケーションのマイクロサービス化およびネットワークスライシングに対応できるリソース管理装置、リソース管理システム、リソース管理方法、およびプログラムを提供することを目的とする。

【課題を解決するための手段】

【0007】

（１）上記の目的を達成するため、本発明は、以下のような手段を講じた。すなわち、本発明のリソース管理装置は、仮想通信機器のリソースを管理するリソース管理装置であって、目的とするネットワーク毎にネットワーク構築に必要な通信機器およびそのＳＬＡを管理し、ネットワーク構築指示をするネットワーク構築部と、前記ネットワーク構築指示に基づいて、前記通信機器に対応する仮想通信機器の機能、前記機能が使用するハードウェアリソース、および性能値を確認し、前記仮想通信機器の構成を決定する通信機器構成部と、前記決定された仮想通信機器の構成に基づいてハードウェアリソースを割り当てる機能構築部と、前記ハードウェアリソースの使用状況を監視するリソース監視部と、を備える。

【0008】

このように、仮想通信機器のリソース管理をネットワーク－通信機器－仮想通信機器－機能－ハードウェアリソースという階層構造によって管理することで、構築するネットワークのＳＬＡ（Service Level Agreement）を満たしつつアクセラレータを含むハードウェアリソースを柔軟に利用でき、アプリケーションのマイクロサービス化およびネットワークスライシングに対応できる。

【0009】

（２）また、本発明のリソース管理装置において、前記通信機器構成部は、前記ネットワーク構築指示に含まれるネットワークの優先度に基づいて、既に構築された１以上のネットワークを削除すると共に優先度の高いネットワークの仮想通信機器の構成を決定する。

【0010】

これにより、ネットワークの優先度に基づいて、優先度の高いネットワークの構築を優先できる。

【0011】

（３）また、本発明のリソース管理装置において、前記通信機器構成部は、前記仮想通信機器に複数の構成がある場合、前記複数の構成毎の性能値の１以上の値に基づいて前記仮想通信機器の構成を決定する。

【0012】

これにより、仮想通信機器に複数の構成がある場合、複数の構成毎の性能値に基づいて適切な仮想通信機器の構成をすることができる。

【0013】

（４）また、本発明のリソース管理装置において、前記通信機器構成部は、既に構築された１以上のネットワークを削除した後のリソースで前記優先度の高いネットワークの仮想通信機器を構成するときに、前記優先度の高いネットワークの仮想通信機器を構成した後のリソースの使用状況に基づいて、前記削除されるネットワークの仮想通信機器を構成できるか判断し、前記削除されるネットワークの仮想通信機器を構成できる場合、前記削除されるネットワークの仮想通信機器の新たな構成を決定し、前記削除されるネットワークの仮想通信機器を構成できない場合、その情報をユーザに通知する。

【0014】

これにより、ネットワークが削除されるときに、削除されるネットワークを残ったリソースで再構築できる場合に再構築し、再構築できない場合にユーザがそのことを知ったうえで、優先度の高いネットワークを構築するか、既に構築されたネットワークを維持するかを判断することができる。

【0015】

（５）また、本発明のリソース管理装置において、前記通信機器構成部は、前記リソース監視部の監視するリソースの使用状況に基づいて、現状のリソースまたは既に構築された１以上のネットワークを削除した後のリソースで前記仮想通信機器を構成できるがその構成の性能値では構築するネットワークのＳＬＡを満たさない場合、その情報をユーザに通知し、ユーザの指示に従い前記仮想通信機器の構成を決定する。

【0016】

これにより、現状のリソースまたは既に構築された１以上のネットワークを解除した後のリソースで仮想通信機器を構成できるがその構成の性能値では構築するネットワークのＳＬＡを満たさない場合に、ユーザがそのことを知ったうえで、ＳＬＡを満たさないネットワークの構築を指示することができ、ネットワークを柔軟に構築できる。

【0017】

（６）また、本発明のリソース管理システムは、仮想通信機器のリソースを管理するリソース管理システムであって、上記（１）から（６）のいずれかに記載のリソース管理装置と、前記リソース管理装置と通信を行い、複数種類のハードウェアリソースを備えるハードウェアリソースプールを有する１以上のサーバと、前記リソース管理装置に管理される、ネットワーク毎に必要な通信機器の種類およびそのＳＬＡを保持するネットワーク構成ＤＢ、前記通信機器の種類毎に対応する１以上の仮想通信機器の情報を保持する通信機器種別ＤＢ、前記仮想通信機器の機能構成、使用するハードウェアリソース、および性能値を保持する機能紐づけＤＢ、および、前記ハードウェアリソースプールのハードウェアリソースの使用状況を保持するリソースＤＢと、を備え、前記サーバは、前記リソース管理装置の制御に従い、前記ハードウェアリソースプールのハードウェアリソースによって１以上の仮想通信機器を構成することでネットワークを構築する。

【0018】

このように、仮想通信機器のリソース管理をネットワーク－通信機器－仮想通信機器－機能－ハードウェアリソースという階層構造によって管理することで、構築するネットワークのＳＬＡを満たしつつアクセラレータを含むハードウェアリソースを柔軟に利用でき、アプリケーションのマイクロサービス化およびネットワークスライシングに対応できる。

【0019】

（７）また、本発明のリソース管理方法は、仮想通信機器のリソースを管理するリソース管理方法であって、目的とするネットワーク毎にネットワーク構築に必要な仮想通信機器およびそのＳＬＡを管理し、ネットワーク構築指示をするネットワーク構築ステップと、前記ネットワーク構築指示に基づいて、前記仮想通信機器の機能および前記機能が使用するハードウェアリソースを確認し、前記仮想通信機器の構成を決定する通信機器構成ステップと、前記決定された仮想通信機器の構成に基づいてハードウェアリソースを割り当てる機能構築ステップと、前記ハードウェアリソースの使用状況を監視するリソース監視ステップと、を含む。

【0020】

このように、仮想通信機器のリソース管理をネットワーク－通信機器－仮想通信機器－機能－ハードウェアリソースという階層構造によって管理することで、ネットワークのＳＬＡを満たしつつアクセラレータを含むハードウェアリソースを柔軟に利用でき、アプリケーションのマイクロサービス化およびネットワークスライシングに対応できる。

【0021】

（８）また、本発明のプログラムは、仮想通信機器のリソースを管理するリソース管理プログラムであって、目的とするネットワーク毎にネットワーク構築に必要な仮想通信機器およびそのＳＬＡを管理し、ネットワーク構築指示をする処理と、前記ネットワーク構築指示に基づいて、前記仮想通信機器の機能および前記機能が使用するハードウェアリソースを確認し、前記仮想通信機器の構成を決定する処理と、前記決定された仮想通信機器の構成に基づいてハードウェアリソースを割り当てる処理と、前記ハードウェアリソースの使用状況を監視する処理と、の一連の処理をコンピュータに実行させる。

【0022】

このように、仮想通信機器のリソース管理をネットワーク－通信機器－仮想通信機器－機能－ハードウェアリソースという階層構造によって管理することで、ネットワークのＳＬＡを満たしつつアクセラレータを含むハードウェアリソースを柔軟に利用でき、アプリケーションのマイクロサービス化およびネットワークスライシングに対応できる。

【発明の効果】

【0023】

本発明によれば、ネットワーク上の仮想通信機器のリソース管理をネットワーク－仮想通信機器－機能－ハードウェアリソースという階層構造によって管理することで、ネットワークのＳＬＡ を満たしつつアクセラレータを含むハードウェアリソースを柔軟に利用でき、アプリケーションのマイクロサービス化およびネットワークスライシングに対応できる。

【図面の簡単な説明】

【0024】

【図1】本実施形態に係るリソース管理システムの概念の一例を示す図である。

【図2】本実施形態に係るリソース管理装置の概略構成の一例を示すブロック図である。

【図3】ネットワーク名、ネットワーク構築に必要な通信機器、満たすべきＳＬＡ、および優先度の一例を示す表である。

【図4】通信機器の種類毎に対応する仮想通信機器の情報の一例を示す表である。

【図5】仮想通信機器の機能構成パターン、使用するハードウェアリソース、および性能値の一例を示す表である。

【図6】リソース管理システムの概略構成の一例を示すブロック図である。

【図7】ネットワーク－通信機器－仮想通信機器－機能－ハードウェアリソースという階層構造の一例を示す図である。

【図8】ネットワーク構築の動作の一例を示すフローチャートである。

【図9】優先度を含む場合のネットワーク構築の動作の一例を示すフローチャートである。

【図10】優先度を含む場合のネットワーク構築の動作の一例を示すフローチャートである。

【図11】削除されるネットワークの再構築の動作の一例を示すフローチャートである。

【0025】

本発明者らは、仮想通信機器のリソース管理をネットワーク－通信機器－仮想通信機器－機能－ハードウェアリソースという階層構造によって管理することで、構築するネットワークのＳＬＡを満たしつつアクセラレータを含むハードウェアリソースを柔軟に利用でき、アプリケーションのマイクロサービス化およびネットワークスライシングに対応できることを見出し、本発明をするに至った。

【0026】

すなわち、本発明のリソース管理装置は、仮想通信機器のリソースを管理するリソース管理装置であって、目的とするネットワーク毎にネットワーク構築に必要な通信機器およびそのＳＬＡを管理し、ネットワーク構築指示をするネットワーク構築部と、前記ネットワーク構築指示に基づいて、前記通信機器に対応する仮想通信機器の機能、前記機能が使用するハードウェアリソース、および性能値を確認し、前記仮想通信機器の構成を決定する通信機器構成部と、前記決定された仮想通信機器の構成に基づいてハードウェアリソースを割り当てる機能構築部と、前記ハードウェアリソースの使用状況を監視するリソース監視部と、を備える。

【0027】

これにより、本発明者らは、ネットワークのＳＬＡを満たしつつアクセラレータを含むハードウェアリソースを柔軟に利用でき、アプリケーションのマイクロサービス化およびネットワークスライシングに対応することを可能とした。以下、本発明の実施形態について、図面を参照しながら具体的に説明する。

【0028】

［実施形態］
（リソース管理システムの概念）
図１は、本実施形態に係るリソース管理システムの概念の一例を示す図である。ネットワークは論理的にサービス毎に分かれている。図１には車用ネットワーク、携帯電話用ネットワークが表示されている。それぞれのネットワークは１つ以上の仮想通信機器を構成することで実現され、更に仮想通信機器は１つ以上の機能で構成されて動作している。それぞれの機能はハードウェアリソースを消費することで実行されるが、機能毎に消費するリソースには違いがある。例えば、図１の機能ＢはハードウェアリソースプールのＦＰＧＡ１とＣＰＵ１を利用して実行されることを表している。リソース管理装置は、このようなリソース管理システムを監視、制御している。リソース管理システムの構成の詳細は後述する。

【0029】

（リソース管理装置の構成）
図２は、本実施形態に係るリソース管理装置の概略構成の一例を示すブロック図である。リソース管理装置１００は、ネットワーク構築部１１０、通信機器構成部１２０、機能構築部１３０、およびリソース監視部１４０によって構成されている。

【0030】

ネットワーク構築部１１０は、ユーザからのネットワーク構築依頼を受け付ける。ネットワーク構築部１１０は、目的とするネットワーク毎にネットワーク構築に必要な通信機器およびそのＳＬＡを管理し、ネットワーク構築指示をする。ネットワーク構築指示には、少なくともネットワーク名、必要な通信機器および満たすべきＳＬＡが含まれる。ネットワーク構築指示には、ネットワークの優先度が含まれていてもよい。

【0031】

図３は、ネットワーク構築部１１０が管理する情報の一例を示す表である。図３に示されるように、ネットワーク構築部１１０は、例えば、ネットワーク名、ネットワーク構築に必要な通信機器、および満たすべきＳＬＡを管理し、必要であれば優先度を管理する。

【0032】

必要な通信機器は、図３に示されるように、例えば、ルータ、ファイアウォール、基地局、モバイルコア等が考えられるが、これに限定されるわけではない。また、満たすべきＳＬＡは、図３に示されるように、例えば、最低スループットや累積遅延等が考えられるが、これに限定されるわけではない。満たすべきＳＬＡとして、他に消費電力等も考えられる。最低スループットは、必要な各通信機器に対応する各仮想通信機器の性能値のスループットのうち、最も大きい値である。また、累積遅延は、必要な各通信機器に対応する各仮想通信機器の性能値の処理遅延の合計値である。なお、仮想通信機器の性能値の詳細については後述する。

【0033】

通信機器構成部１２０は、ネットワーク構築指示に基づいて、通信機器に対応する仮想通信機器の機能、その機能が使用するハードウェアリソース、および性能値を確認し、仮想通信機器の構成を決定する。また、通信機器構成部１２０は、決定した仮想通信機器の構成情報を、機能構築部１３０に通知する。

【0034】

図４および図５は、通信機器構成部１２０が確認する、通信機器の種類毎に対応する仮想通信機器の情報の一例と、仮想通信機器の機能構成パターン、使用するハードウェアリソース、および性能値の一例を示す表である。図４および図５に示されるように、通信機器構成部１２０は、ネットワーク構築指示に含まれるネットワーク構築に必要な通信機器に基づいて、これに対応する仮想通信機器を確認する。また、通信機器構成部１２０は、仮想通信機器の機能構成パターン、および性能値を確認する。また、通信機器構成部１２０は、ネットワーク構築指示に含まれる満たすべきＳＬＡに基づいて、確認した性能値でＳＬＡが満たされるかどうかを判断し、満たされる場合は、その機能構成パターンによるハードウェアリソースの構成を決定する。

【0035】

性能値は、例えば、スループットや処理遅延が考えられる。これらの値に基づいて、ネットワークのＳＬＡが満たされるかどうかが判断される。

【0036】

通信機器構成部１２０は、仮想通信機器に複数の構成がある場合、複数の構成毎の性能値の１以上の値に基づいて仮想通信機器の構成を決定することが好ましい。これにより、仮想通信機器に複数の構成がある場合、複数の構成毎の性能値に基づいて適切な仮想通信機器の構成をすることができる。なお、仮想通信機器に複数の構成がある場合とは、図４の表の基地局の欄のように、基地局に複数の仮想通信機器アおよびカが対応している場合、および、図５の表の仮想通信機器アの欄のように、仮想通信機器アに複数の機能構成パターンが対応している場合のいずれも含む。

【0037】

複数の構成から１つを決定する方法は様々考えられるが、例えば、複数の性能値について、それぞれがより性能値の高い構成を決定することができる。このように決定すると、ネットワークの使用者が快適にネットワークを使用できる。また、ネットワークの種類に応じて、重視する性能値を変更して、ＳＬＡを満たす構成の中で、重視する性能値が高い構成を決定することもできる。このとき、性能値に重みづけをして、性能値のスコアを算出して構成を決定してもよい。このように決定すると、ネットワークの種類毎に必要な性能値が高い構成が決定されるため、すべての性能値が高い構成でなくても、ネットワークの使用者が十分に快適にネットワークを使用できる。また、例えば、ＳＬＡを満たす構成の中で、できるだけ性能値が低い構成を決定することもできる。このように決定すると、性能値が高くなるハードウェアリソースを消費していないため、後述する優先度の高いネットワークがあとから構築される場合に、当該ネットワークの再構築が行われにくくなる。

【0038】

通信機器構成部１２０は、ネットワーク構築指示にネットワークの優先度が含まれる場合、ネットワークの優先度に基づいて、既に構築された１以上のネットワークを削除すると共に優先度の高いネットワークの仮想通信機器の構成を決定することが好ましい。

【0039】

これにより、ネットワークの優先度に基づいて、優先度の高いネットワークの構築を優先できるため、例えば、既に別のネットワークを構築したあとに、それよりも優先度の高いネットワークを構築する場合であっても、有限のハードウェアリソースを優先度の高いネットワークに割り当てることができる。

【0040】

削除するネットワークを決定する方法は様々考えられるが、例えば、単純に優先度の低い（優先度の数値が大きい）ネットワークを削除するネットワークとして決定してもよい。また、複数のネットワークを削除することも考えられるが、例えば、複数のネットワークの組み合わせのうち、他の組み合わせと比較して優先度の高い（優先度の数値が小さい）ネットワークが含まれる組み合わせは削除するネットワークとして選択しないようにしてもよい。また、例えば、後述するネットワークの再構築をする場合、ネットワークの再構築にかかる時間やユーザの指示回数などを再構築のコストとして数値化し、再構築のコストが低いネットワークの組み合わせを削除するネットワークの組み合わせとして選択してもよい。

【0041】

通信機器構成部１２０は、既に構築された１以上のネットワークを削除した後のリソースで優先度の高いネットワークの仮想通信機器を構成するときに、優先度の高いネットワークの仮想通信機器を構成した後のリソースの使用状況に基づいて、削除されるネットワークの仮想通信機器を構成できるか判断し、削除されるネットワークの仮想通信機器を構成できる場合、削除されるネットワークの仮想通信機器の新たな構成を決定し、削除されるネットワークの仮想通信機器を構成できない場合、その情報をユーザに通知することが好ましい。

【0042】

これにより、ネットワークが削除されるときに、削除されるネットワークを残ったリソースで再構築できる場合に自動的に再構築し、再構築できない場合にユーザがそのことを知ったうえで、優先度の高いネットワークを構築し既に構成されたネットワークを削除するか、優先度の高いネットワークの構築を断念し既に構築されたネットワークを維持するかを判断することができる。

【0043】

通信機器構成部１２０は、リソース監視部１４０の監視するリソースの使用状況に基づいて、現状のリソースまたは既に構築された１以上のネットワークを削除した後のリソースで仮想通信機器を構成できるがその構成の性能値では構築するネットワークのＳＬＡを満たさない場合、その情報をユーザに通知し、ユーザの指示に従い仮想通信機器の構成を決定することが好ましい。

【0044】

これにより、現状のリソースまたは既に構築された１以上のネットワークを削除した後のリソースで仮想通信機器を構成できるがその構成の性能値では構築するネットワークのＳＬＡを満たさない場合に、ユーザがそのことを知ったうえで、ＳＬＡを満たさないネットワークの構築を指示することができ、ネットワークを柔軟に構築できる。このとき、ユーザがＳＬＡを満たさないネットワークの構築を指示しない場合、リソース管理装置１００は、当該ネットワークの構築をしないことが好ましい。このようにすることで、ＳＬＡを満たさないネットワークの構築が、ユーザの関知しないところで行われることを防ぐことができる。ＳＬＡを満たさないネットワークの構築は、通常のネットワークの構築、既に構築されたネットワークを削除して行う優先度の高いネットワークの構築、削除されるネットワークの再構築、のいずれの場合であっても行うことができる。

【0045】

機能構築部１３０は、決定された仮想通信機器の構成に基づいてハードウェアリソースを割り当てる。割り当てるハードウェアリソースは、決定された仮想通信機器の構成に基づいてハードウェアリソースプールから選択する。ハードウェアリソースプールに使用可能な同一のハードウェアリソースが複数存在する場合、選択するハードウェアリソースは、順に選択するようにしてもよいし、ランダムに選択するようにしてもよい。ハードウェアリソースプールの詳細は後述する。

【0046】

機能構築部１３０は、ハードウェアリソースを割り当てる際に、仮想通信機器およびその機能を実現するソフトウェアを、割り当てたハードウェアリソースに読み込ませる。これらのソフトウェアは、ネットワーク構築部１１０が管理することが好ましい。

【0047】

リソース監視部１４０は、ハードウェアリソースの使用状況を監視する。リソース監視部１４０の監視は、所定の短いサイクルで繰り返し行う常時監視でもよいし、ネットワークの構築（再構築を含む）毎に行う監視でもよい。なお、ハードウェアリソースプールの構成が変更される場合は、必ず行うことが好ましい。

【0048】

リソース管理装置１００は、上記機能とは別に、外部インターフェース部１５０を有する。外部インターフェース部１５０は、ネットワーク構築の制御および通信を行う。外部インターフェース部１５０は、ユーザの入力の受け付けやユーザへの通知の出力を行う機能を有していてもよいが、外部インターフェース部１５０とは別に入出力部を有していてもよい。また、入出力部は、リソース管理装置１００とは別に存在していてもよい。

【0049】

（リソース管理システムの構成）
図６は、リソース管理システムの概略構成の一例を示すブロック図である。リソース管理システム１０は、リソース管理装置１００、ＤＢ（データベース）２００、サーバ３００、によって構成されている。リソース管理装置１００は、上記で説明した機能を有する。ＤＢ（データベース）２００は、リソース管理装置１００に管理される。ＤＢ２００は、以下のような複数のＤＢを含む。

【0050】

ネットワーク構成ＤＢ２１０は、図３の例に示されるような、ネットワーク毎に必要な通信機器の種類およびそのＳＬＡを保持する。通信機器種別ＤＢ２２０は、図４の例に示されるような、通信機器の種類毎に対応する仮想通信機器の情報を保持する。機能紐づけＤＢ２３０は、図５の例に示されるような、仮想通信機器の機能構成、使用するハードウェアリソース、および性能値を保持する。リソース管理ＤＢ２４０は、ハードウェアリソースプールのハードウェアリソースの使用状況を保持する。

【0051】

ＤＢ２００は、リソース管理装置１００に含まれていてもよいが、リソース管理装置１００と通信可能であれば、どこにあってもよい。また、サーバ３００に含まれていてもよい。なお、ネットワーク構成ＤＢ２１０、通信機器種別ＤＢ２２０、機能紐づけＤＢ２３０、およびリソース管理ＤＢ２４０は、保持される情報の種類によって分けて説明をしたが、これらの情報は、１の装置に含まれていてもよいし、複数の装置に分散されていてもよい。

【0052】

サーバ３００は、リソース管理装置１００と通信を行い、複数種類のハードウェアリソースを備えるハードウェアリソースプールを有する。サーバ３００は、リソース管理装置１００の制御に従い、ハードウェアリソースプールのハードウェアリソースによって１以上の仮想通信機器を構成することでネットワークを構築する。サーバ３００は、１のみであっても、２以上であってもよい。なお、サーバ３００とリソース管理装置１００が一体となっていてもよい。

【0053】

（ハードウェアリソースプールの構成）
ハードウェアリソースプールは、複数種類のハードウェアリソースを備える。ハードウェアリソースは、図１に示されるような、ＣＰＵ（Central Processing Unit）に加え、ＧＰＵ（Graphics Processing Unit）、ＦＰＧＡ（Field Programmable Gate Array）等のアクセラレータを含むが、これらに限定されるわけではない。例えば、メモリ、ハードディスク等を含んでいてもよい。

【0054】

図１は、ハードウェアリソースプールが、地域（あ）と地域（い）に分散されて配置されていることを示している。この場合、サーバ３００は、地域（あ）と地域（い）に配置されているため、複数配置されていることになる。このように、ハードウェアリソースプールは、地域ごとに分散されていても、どこか全国に１箇所に集中して配置されていても構わない。１箇所に複数のサーバ３００が配置されていてもよい。なお、プール化の手法は問わない。

【0055】

仮想通信機器の機能が利用する個々のハードウェアリソースは、例えば、ＧＰＵを、ＧＰＵ１、ＧＰＵ２のように性能毎、若しくはメーカ毎に分けてプール化されていることが好ましい。図１は、ＧＰＵおよびＦＰＧＡについて、２つのカテゴリに分けてプール化している状況を示している。ハードウェアリソースを性能毎、若しくはメーカ毎に分けてプール化することで、ハードウェアリソースを細かく管理することができ、仮想通信機器の構成を多様に変化させることができる。例えば、このカテゴリを低機能と高機能に分けてプール化することにより、仮想通信機器の機能の実現に不必要な高度な機能を有するハードウェアリソースを無駄に消費する恐れが低減できる。

【0056】

本発明のリソース管理装置およびリソース管理システムによって、図７に示されるように、仮想通信機器のリソース管理をネットワーク－通信機器－仮想通信機器－機能－ハードウェアリソースという階層構造によって管理することができる。

【0057】

（ネットワーク構築の動作）
図８は、ネットワーク構築の動作の一例を示すフローチャートである。図８は、リソース管理装置を構成する各部およびユーザの指示および判断を含む。まず、ユーザがリソース管理装置にネットワーク構築を依頼する（ステップＳ１）。次に、ネットワーク構築部がネットワーク構成ＤＢを参照し必要な通信機器およびそのＳＬＡを確認し（ステップＳ２）、通信機器構成部に必要な通信機器およびそのＳＬＡを通知しネットワーク構築を依頼する（ステップＳ３）。

【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】

１０ リソース管理システム
１００ リソース管理装置
１１０ ネットワーク構築部
１２０ 通信機器構成部
１３０ 機能構築部
１４０ リソース監視部
１５０ 外部インターフェース部
２００ データベース
２１０ ネットワーク構成ＤＢ
２２０ 通信機器種別ＤＢ
２３０ 機能紐付けＤＢ
２４０ リソース管理ＤＢ
３００ サーバ

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】