JP7740538B2 - 統合制御装置、統合制御システム、統合制御方法及びプログラム - Google Patents

Description

本開示内容は、物理ネットワーク（ネットワーク基盤＝ＮＦＶ環境）上で異なる目的の複数の仮想ネットワークを構築するための複数の制御エンジンを統合制御する技術に関する。

ネットワークの各サービスは、サービス事業者又はネットワーク事業者（通信事業者）によって設計又は提供される制御アルゴリズムにより運用されている。

将来的には、例えば、図６に示すように、ユーザ端末３３０と接続先サーバ３１０ｚの間のデータ伝送経路に関して、ネットワーク事業者が運営する単一の物理ネットワーク上で、一のサービス事業者が運営する仮想ネットワーク（経路長の最小化を目的とした制御アルゴリズム）と、他のサービス事業者が運営する仮想ネットワーク（設備の負荷分散を目的とした制御アルゴリズム）が独立して構築されることが考えられる。この場合、経路長の最小化を目的とした制御アルゴリズムでは、サーバ３１０ａが各ノード（転送装置３２０、サーバ３１０ｘ，３１０ｙ）等の設備負荷状況を考慮せずに仮想ネットワークを構築する。一方、設備の負荷分散を目的とした制御アルゴリズムでは、サーバ３１０ｂが要求品質は考慮せずに、各ノード等の設備負荷状況を平準化するよう仮想ネットワークを構築する。

ところが、単一の物理ネットワーク上で、異なった目的の複数の仮想ネットワークを構築しようとすると、図７に示すようなネットワーク制御の競合が生じる場合がある。例えば、図７に示すように、各ノード（転送装置）３２０ａ～３２０ｅのデータ転送可能な容量が「１０」の場合であって、先に、設備の負荷分散を目的とした制御アルゴリズムを採用したサーバ３１０ｂが「１０」のデータ容量を、「３」、「３」、「４」の各データ容量に分散して、ユーザ端末３３０ｂにデータを転送した状況を考える。この場合、後から、経路長の最小化を目的とした制御アルゴリズムを採用したサーバ３１０ａが「１０」のデータ容量を分散しないでそのまま転送すると、既にいずれのノード３２０ａ～３２０ｅも残りのデータ転送可能な容量は「１０」もないため、ユーザ端末３３０ａにデータ転送するための仮想ネットワークを構築しようとしても、リソースが不足しているという問題が生じてしまう。

これに対して、図８に示すようなネットワーク制御の協調により、上記問題を解決することができる。例えば、図８のように、図７と同じ物理ネットワークであっても、サーバ３１０ａが、ノード３２０ａ，３２０ｄを使用して「１０」のデータ容量のデータ転送を行った後、サーバ３１０ｂが、サーバ３１０ａによって使用されなかったノード３２０ｂ，３２０ｃ，３２０ｅを使用する仮想ネットワークを構築すれば、「１０」のデータ容量を、「５」、「５」の各データ容量に分散してデータ転送しても、それぞれの目的を達成することができる。

そのため、ネットワーク制御の協調を実現すべく、従来、非特許文献１に示す技術が提案されている。ここで、図９及び図１０を用いて、従来の仮想ネットワーク制御について説明する。図９は、従来のネットワークの全体構成を示す図である。図１０は、従来の統合制御エンジン２００の機能構成例を示す図である。

図９に示すように、統合制御システム１０は、ネットワーク基盤としての物理ネットワーク３００と接続される。物理ネットワーク３００は、汎用サーバ３１０、ノード（転送装置）３２０、及びユーザ端末３３０が含まれるネットワーク環境である。統合制御システム１００は、統合制御エンジン２００を有する１以上のコンピュータである。統合制御システム１０は、統合制御エンジンにより、物理ネットワーク３００上の仮想ネットワークを制御する。統合制御システム１０は、情報収集・蓄積装置３０を介して、物理ネットワーク３００から、ネットワーク状態（状況）を示すネットワーク情報を取得し、統合制御エンジン２００により算出した制御結果及び設定命令を、オーケストレータ５０を介して物理ネットワークの各ノード３２０に送信することで、ネットワーク制御の協調を実現している。

具体的には、図１０に示すように、統合制御エンジン２００は、ＮＦＶ環境情報（ネットワーク構成情報、ユーザ需要、ネットワーク観測情報（トラヒック情報、サーバ利用情報等））に基づき、最適な汎用サーバ３１０への仮想リソースや仮想機能の割当、及び、最適な経路を計算する。統合制御エンジン２００は、モジュール化された各種制御エンジンｅ１００（ｅ１０１～ｅ１０５等）との連携を前提に、各種制御エンジン間の情報共有を行うための情報共有エンジン４００にて実現される。情報共有エンジン４００は、学習指示エージェント４１０、各制御エージェント４３０（４３１，４３２，４３３，４３４，４３５等）、総合評価算出部４５０、入出力変換部４６０を有している。

これらのうち、学習指示エージェント４１０は、総合評価に基づいて各制御エージェントの選択を学習する。各制御エージェント４３０は、総合評価に基づいて、各制御エンジンｅ１００の解の変更を学習する。総合評価算出部４５０は、各制御エンジンｅ１００の評価から、総合評価である報酬を計算する。入出力変換部４６０は、各制御エンジンｅ１００の入出力の形式を変換する。入出力変換部４６０の定式化は、各制御エンジンｅ１００の組合せごとに行う。

このようにして、非特許文献１では、情報共有エンジン４００が、各制御エンジンｅ１００から上述の各種情報を収集し、それぞれの解がどのように制御したいのかということを認識した上で、各制御エンジンの各制御アルゴリズムが持っている目的関数を評価しながら解を変更する。次に、情報共有エンジン４００が、この変更した解を各制御エンジンｅ１００に送ることで、各制御エンジンｅ１００が新たな解を求める。再度、情報共有エンジン４００が各制御エンジンｅ１００から上述の各種情報を収集する処理を繰り返すことで、最終的な解を決めることができる。但し、非特許文献１では、各制御エンジンｅ１００が持つ各制御アルゴリズムには、制御ポリシ(品質の向上、リソース効率の向上等)及び制約条件(サービス提供条件、リンク容量、サーバ容量等)が開示されていることを前提としている。

Akito Suzuki, Ryoichi Kawahara, Masahiro Kobayashi, Yousuke Takahashi, Shigeaki Harada, and Keisuke Ishibashi, "Extendable NFV-Integrated Control Method Using Reinforcement Learning," IEICE Trans. Communications, vol. E103-B, no. 8, pp. 826-841, Aug. 2020.

しかしながら、例えば、サードパーティーが制御エンジン（制御アルゴリズム）を作成する場合、制御エンジンの制御ポリシや制約条件等が必ずしもネットワーク事業者側に開示されているわけではない。そのため、非特許文献１に開示の技術では、各制御エンジンの評価を計算することや各制御エンジンの解の変更を学習することができない場合があるという課題が生じる。

本発明は、上述の事情に鑑みてなされたもので、制御エンジンの制御ポリシや制約条件等の開示が無くても、全ての制御エンジンを対象とした制御完了状態（個々の制御ポリシが満たされた最適な状態、又は全体としてそれ以上改善することが不可能な状態）までの統合制御を効率よく実施することを目的とする。

上記目的を達成するため、請求項１に係る発明は、物理ネットワーク上で異なる複数の仮想ネットワークを構築するための複数の制御エンジンを統合制御する統合制御装置であって、前記物理ネットワークの状況を示すＮＦＶ（Network Functions Virtualization）環境情報を取得して前記複数の制御エンジンに配布することで、前記複数の制御エンジンから前記複数の仮想ネットワークに関する制御依頼を受け付ける情報配布部と、前記複数の制御エンジンから受け取った前記制御依頼に基づき、現在の前記物理ネットワークの状況に対して前記複数の制御エンジンからの前記制御依頼における制御指示の総数を集計する総合評価推定部と、前記総合評価推定部によって集計された前記制御指示の総数が前回の集計時に比べて少なくなるように、強化学習を利用して制御許可決定用の行動価値関数を更新する制御許可先学習部と、前記総合評価推定部によって集計された前記制御指示の総数が前回と今回で変化した場合には、前記複数の制御エンジンのうち、前記行動価値関数に基づいて所定の制御エンジンを決定し、当該所定の制御エンジンから受け取った所定の制御依頼を前記物理ネットワーク側へ転送する制御適用判断部と、を有する統合制御装置である。

以上説明したように本発明によれば、制御エンジンの制御ポリシや制約条件等の開示が無くても、全ての制御エンジンを対象とした制御完了状態までの統合制御を効率よく実施することができるという効果を奏する。

第１の実施形態に係る通信システムの全体構成図である。 統合制御システムの電気的なハードウェア構成図である。 第１の実施形態に係る統合制御の処理を示すフローチャートである。 第２の実施形態に係る通信システムの全体構成図である。 第２の実施形態に係る統合制御の処理を示すフローチャートである。 物理ネットワーク上で異なる目的の複数の仮想ネットワークを構築する場合概念図である。 物理ネットワーク上で異なる目的の複数の仮想ネットワークを構築する場合に、ネットワーク制御の競合が生じたときの概念図である。 物理ネットワーク上で異なる目的の複数の仮想ネットワークを構築する場合に、ネットワーク制御の協調を行う場合の概念図である。 従来の通信システムの全体構成を示す図である。 従来の統合制御エンジン２００の機能構成図である。

以下、図面を用いて本発明の実施形態を説明する。

●第１の実施形態
まずは、本発明の第１の実施形態について説明する。

〔実施形態のシステム構成〕
図１を用いて、第１の実施形態の通信システムの構成の概略について説明する。図１は、第１の実施形態に係る通信システムの全体構成図である。

図１に示されているように、本実施形態の通信システムは、統合制御システム１０、情報収集・蓄積装置３０、オーケストレータ５０、ネットワーク基盤としての物理ネットワーク３００によって構築されている。

物理ネットワーク３００は、ネットワーク事業者によって管理及び運営されており、複数の汎用サーバ３１０、複数のノード（転送装置）３２０、及び複数のユーザ端末３３０によって構築されている。

これらのうち、汎用サーバ３１０は、単一又は複数のコンピュータによって構築されており、オーケストレータ５０を介して統合制御システム１０により設定される仮想リソース（ＶＲ：Virtual Resource）や仮想ネットワーク機能（ＶＮＦ：Virtual Network Function）を実現する。ＶＲとしては、例えば、ＣＰＵ（Central Processing Unit）やＨＤＤ（Hard Disk Drive）、ＧＰＵ（Graphics Processing Unit）、ＦＰＧＡ（Field Programmable Gate Array）等を組み合わせたＶＭ（Virtual Machine）が挙げられる。また、ＶＮＦとしては、例えば、ＣＰＥ（Customer Premises Equipment）、ＦＷ（Firewall）、ＬＢ（Load Balancer）、ＤＰＩ（Deep Packet Inspection）、Ｐｒｏｘｙ、ＩＤＳ（Intrusion Detection System）、ＮＡＴ（Network Address Translation）等が挙げられる。汎用サーバ３１０は、サーバ利用情報を取得し、情報収集・蓄積装置３０を介してサーバ利用情報を統合制御システム１０に送信する。また、汎用サーバ３１０は、オーケストレータ５０を介して統合制御システム１０により設定されたＶＲ及びＶＮＦに従ってトラヒックを処理し、トラヒックを発生させる。

ノード３２０は、スイッチやサーバ等の転送装置であり、トラヒックを転送する転送装置として機能する。ノード３２０は、トラヒック情報を取得し、情報収集・蓄積装置３０を介してトラヒック情報を統合制御システム１０に送信する。また、ノード３２０は、統合制御システム１０により算出された経路に従ってトラヒックを処理する。

ユーザ端末３３０は、単一又は複数のコンピュータによって構築されており、ユーザの通信行動（例えば、サービスの利用開始操作等）により発生したトラヒック需要を、他のユーザ端末３３０や汎用サーバ３１０等に送信する。また、ユーザ端末３３０は、情報収集・蓄積装置３０を介してユーザ需要を統合制御システム１０に送信する。

仮想ネットワークとは，提供するサービスにあわせてＶＲ、ＶＮＦ、及びユーザ端末を組み合わせた論理的なネットワークであり，ＶＲやＶＮＦを汎用サーバに設定し、トラヒックが転送されることで各種サービスが実現される。

なお、サーバ利用情報とは、汎用サーバ３１０の物理リソース（例えばＣＰＵやメモリ等）の利用率等である。トラヒック情報とは、物理ネットワーク３００に含まれる任意のリンクのデータ量等である。ユーザ需要とは、ＶＲ及びＶＮＦの需要情報（ユーザ端末３３０毎に必要なＶＲ及びＶＮＦの量）、サービスの制約条件（ユーザ端末３３０毎に経由する必要があるＶＲ及びＶＮＦ）等である。

情報収集・蓄積装置３０は、ネットワーク事業者によって管理及び運営されており、単一又は複数のコンピュータによって構築されている。情報収集・蓄積装置３０は、物理ネットワーク３００や各種リソースの負荷状況を一元的に監視する。そのため、情報収集・蓄積装置３０は、物理ネットワーク３００から、ネットワーク観測情報（トラヒック情報やサーバ利用情報等）及びユーザ需要を取得及び蓄積すると共に、統合制御システムに転送する。

オーケストレータ５０は、ネットワーク事業者によって管理及び運営されており、単一又は複数のコンピュータによって構築されている。オーケストレータ５０は、物理ネットワーク３００への制御指示を一元的に受付及び適用する。例えば、オーケストレータ５０は、ネットワーク機器（ルータ、スイッチ、仮想サーバ等）に制御信号を送って、ソフトウェア的にリアルタイムで仮想ネットワークを制御変更する。そのため、統合制御システム１０から、統合制御システム１０により算出された最適な配置及び最適な経路を示す解（制御解）に応じた制御結果及び設定命令を取得し、各汎用サーバ３１０及び各ノード３２０に送信することで、様々な種別のネットワークサービスを提供することが可能なＮＦＶ（Network Functions Virtualization）環境の制御が行われる。オーケストレータ５０は、「リソースオーケストレーション」及び「サービスオーケストレーション」と呼ばれる機能によりＶＲ及びＶＮＦの制御を行う。リソースオーケストレーションとは、物理ネットワーク上にＶＲ及びＶＮＦを配置する機能のことである。サービスオーケストレーションとは、ＶＲやＶＮＦ間を繋ぐＥｎｄ－ｔｏ－Ｅｎｄの経路を算出する機能のことである。

統合制御システム１０は、単一又は複数のコンピュータによって構築されており、ネットワーク事業者によって管理されている。統合制御システム１０は、ネットワーク事業者自身が作成した制御エンジン、サービス事業者等のサードパーティーが作成した制御エンジン等である複数の制御エンジンｅ１，ｅ２，ｅ３を有している。以降、制御エンジンｅ１，ｅ２，ｅ３の総称は、「制御エンジンｅ」と示す。各制御エンジンｅは、個別独立したサービスの機能配置を計算する。

各制御エンジンｅは、それぞれ独自の制御アルゴリズムによって実行される。なお、図１では、紙面の都合上３つの制御エンジンが開示されているが、２つでもよく、４つ以上でもよい。また、統合制御システム１０は、統合制御アルゴリズムＡ１０を有している。また、制御エンジンｅは、統合制御アルゴリズムとは別のサーバ（個別制御装置）で構築されていてもよい。

統合制御アルゴリズムＡ１０は、リソースオーケストレーション及びサービスオーケストレーションの実現に向けて、ＮＦＶオーケストレータに設定命令を行うアルゴリズムである。統合制御アルゴリズムＡ１０は、複数の制御エンジンのうちの単一の所定の制御エンジンを選択し、この選択した単一の制御エンジンからの制御依頼（制御結果及び設定命令）を、オーケストレータ５０を介して物理ネットワーク３００に適用する。なお、本実施形態の各制御エンジンｅは、単独で仮想ネットワークを構築するために、経路、ＶＲ、及びＶＮＦの全ての制御依頼を行うことができる点で、経路、ＶＲ、及びＶＮＦのいずれかの制御依頼しか行うことができない従来の制御エンジンｅ１００（図１０参照）と異なる前提を置いている。

このように、統合制御システム１０は、統合制御アルゴリズムＡ１０を用いて、物理ネットワーク３００上におけるＶＲ及びＶＮＦの最適な配置と、これらＶＲ及びＶＮＦ間を繋ぐＥｎｄ－ｔｏ－Ｅｎｄの最適な経路とを算出することで、ＮＦＶ環境を制御する。このとき、統合制御システム１０は、物理ネットワーク３００から受信したネットワーク観測情報（トラヒック情報やサーバ利用情報等）及びユーザ需要と、ネットワーク構成情報とに基づいて、ＶＲ及びＶＮＦの最適な配置と、最適な経路とを算出する。

なお、ネットワーク構成情報とは、物理ネットワーク３００のネットワークトポロジー情報や、リソースの制約条件（例えば、物理ネットワーク３００に含まれる各物理リソースの量（各汎用サーバ３１０のサーバ容量や各ノード３２０のリンク容量等））である。統合制御アルゴリズムＡ１０により実現される各機能に関しては、後述する。なお、統合制御アルゴリズムＡ１０は、各制御エンジンｅとは別のサーバ（統合制御装置）に構築されていてもよい。

〔ハードウェア構成〕
次に、図２を用いて、統合制御システム１０の電気的なハードウェア構成を説明する。図２は、統合制御システムの電気的なハードウェア構成図である。

統合制御システム１０は、コンピュータとして、図２に示されているように、ＣＰＵ(Central Processing Unit)１０１、ＲＯＭ(Read Only Memory)１０２、ＲＡＭ(Random Access Memory)１０３、ＳＳＤ(Solid State Drive)１０４、外部機器接続Ｉ／Ｆ(Interface)１０５、ネットワークＩ／Ｆ１０６、メディアＩ／Ｆ１０９、及びバスライン１１０を備えている。

これらのうち、ＣＰＵ１０１は、統合制御システム１０全体の動作を制御する。ＲＯＭ１０２は、ＩＰＬ(Initial Program Loader)等のＣＰＵ１０１の駆動に用いられるプログラムを記憶する。ＲＡＭ１０３は、ＣＰＵ１０１のワークエリアとして使用される。

ＳＳＤ１０４は、ＣＰＵ１０１の制御に従って各種データの読み出し又は書き込みを行う。なお、ＳＤＤ１０４の代わりに、ＨＤＤ(Hard Disk Drive)を用いても良い。

外部機器接続Ｉ／Ｆ１０５は、各種の外部機器を接続するためのインターフェースである。この場合の外部機器は、ディスプレイ、スピーカ、キーボード、マウス、ＵＳＢ(Universal Serial Bus)メモリ、及びプリンタ等である。

ネットワークＩ／Ｆ１０６は、物理ネットワーク３００等の通信ネットワークを介してデータ通信をするためのインターフェースである。

メディアＩ／Ｆ１０９は、フラッシュメモリ等の記録メディア１０９ｍに対するデータの読み出し又は書き込み（記憶）を制御する。記録メディア１０９ｍには、ＤＶＤ(Digital Versatile Disc)やＢｌｕ-ｒａｙ Ｄｉｓｃ（登録商標）等も含まれる。

バスライン１１０は、図２に示されているＣＰＵ１０１等の各構成要素を電気的に接続するためのアドレスバスやデータバス等である。

なお、情報収集・蓄積装置３０、オーケストレータ５０、汎用サーバ３１０、ノード３２０、ユーザ端末３３０は、統合制御システム１０と同様の構成を有するため、ハードウェア構成の説明は省略する。

〔統合制御システムの機能構成〕
続いて、図１を用いて、本実施形態に係る統合制御システム１０の機能構成について説明する。統合制御システム１０は、各制御エンジンｅの制御ポリシ及び制約条件に関する情報を利用せずに、各制御エンジンｅが出力した制御依頼から各制御エンジンｅが保持している現在のネットワーク状態に対する評価を推定する。

具体的には、該当する制御エンジンｅから受け取ったオーケストレータへの制御指示数を、その制御エンジンｅが満たすべき制御ポリシ又は最適な状態との乖離量とみなす。

統合制御システム１０は、統合制御が収束するまで、統合制御アルゴリズムＡ１０によって実現される機能による処理を繰り返し実施する。

この統合制御アルゴリズムＡ１０によって、情報配布部１１、総合評価推定部１２、制御許可先学習部１３、制御適用判断部１４の各機能を実現することができる。

これらのうち、情報配布部１１は、情報収集・蓄積装置３０から物理ネットワークのネットワーク状態を示すＮＦＶ環境情報（ネットワーク観測情報、ユーザ需要等）を取得して複数の制御エンジンｅに配布することで、複数の制御エンジンｅから各制御エンジンが所掌する仮想ネットワークに関する制御依頼を受け付ける。

総合評価推定部１２は、複数の制御エンジンｅから受け取った制御依頼に基づき、現在のネットワーク状況に対して複数の制御エンジンｅが求める制御指示の総数を集計する。制御指示は、仮想ネットワークを１つの単位としても良いし、仮想ネットワークを構成するＶＲ及びＶＮＦの配置変更、又はトラヒック経路の変更等の個々の要素を１つの単位としても良いが、各制御エンジンで共通の単位を用いる。例えば、制御エンジンｅ１が２つの仮想ネットワークに対する制御指示を含む制御依頼を行い、制御エンジンｅ２が３つの仮想ネットワークに対する制御指示を含む制御依頼を行い、制御エンジンｅ３が４つの仮想ネットワークに対する制御指示を含む制御依頼を行った場合、制御指示の総数（累積数）は、９（＝２＋３＋４）となる。

制御許可先学習部１３は、総合評価推定部１２によって集計された前記制御指示の総数が前回の集計時に比べて少なくなるように、強化学習を利用して制御許可決定用の行動価値関数を更新する。統合制御アルゴリズムＡ１０から、オーケストレータ５０を介して物理ネットワークへ転送できるのは、複数の制御エンジンｅのうちの所定の制御エンジンによる制御依頼だけである。そのため、制御許可先学習部１３は、各制御エンジンｅからの制御指示の総数が前回よりも少なくなるように、複数の制御エンジンｅから所定の制御エンジンｅ（制御依頼）を決めることで、後述のＳ１１～Ｓ２０の統合制御を収束させる。

制御適用判断部１４は、制御許可決定用の評価が変化した場合には、複数の制御エンジンｅのうちの所定の制御エンジンｅから受け取った所定の制御依頼をオーケストレータ５０へ転送することで、物理ネットワーク側へ転送する。これにより、所定の制御依頼を物理ネットワーク３００へ適用させることができる。このように処理することで、次の処理では、例えば、制御エンジンｅ１が１つの制御指示を含む制御依頼を行い、制御エンジンｅ２が２つの制御指示を含む制御依頼を行い、制御エンジンｅ３が２つの制御指示を含む制御依頼を行った場合、制御指示の総数（累積数）は、６（＝１＋２＋３）となり、前回の総数「９」よりも少なくなっているため、徐々に統合処理が収束する。

〔統合制御システムの処理又は動作〕
続いて、図３を用いて、第１の実施形態に係る統合制御システム１０の処理又は動作について説明する。図３は、第１の実施形態に係る統合制御の処理を示すフローチャートである。

Ｓ１１：情報収集・蓄積装置３０は、ＮＦＶ環境情報（ネットワーク観測情報及びユーザ需要等）を収集する。

Ｓ１２：情報配布部１１は、情報収集・蓄積装置３０から取得したＮＦＶ環境情報を各制御エンジンｅへ配布する。

ここで、各制御エンジンｅの処理を説明する。

Ｓ１０１：制御エンジンｅ１は、情報配布部１１から、ＮＦＶ環境情報を受け取る。

Ｓ１０２：制御エンジンｅ１は、非開示の制御内容の演算を行う。

Ｓ１０３：制御エンジンｅ１は、情報配布部１１に対して制御依頼を送信する。

このＳ１０１～１０３の処理は、制御エンジンｅ２，ｅ３によっても行われる。

Ｓ１３：情報配布部１１は、各制御エンジンｅからの制御依頼を受け付ける。

Ｓ１４：総合評価推定部１２は、各制御依頼における制御指示数を集計する。

Ｓ１５：総合評価推定部１２は、各制御エンジンｅにおける、前回の制御適用判断時の制御指示数と今回の制御指示数の差分を計算する。

Ｓ１６：制御許可先学習部１３は、前回の制御適用許可に対する評価を更新する。

Ｓ１７：制御適用判断部１４は、前回と今回で評価が変化したか否かを判断する。

Ｓ１８：制御適用判断部１４がステップＳ１７で評価が変化したと判断した場合（ＹＥＳ）、制御適用判断部１４は、各制御エンジンｅから受け取った制御依頼（評価結果及び設定命令）のうち、評価に基づき適用許可を与える制御依頼を１つ決定し、この１つ制御依頼をオーケストレータ５０へ転送する。

Ｓ１９：オーケストレータ５０は、制御適用判断部１４から受け取った１つの制御依頼を物理ネットワーク３００へ適用する。

Ｓ２０：オーケストレータ５０は、適用完了を確認する。その後は、ステップＳ１１の処理に戻る。このステップＳ１１～Ｓ２０，Ｓ１０１～Ｓ１０３は、評価が変化しなくなるまで（Ｓ１７：ＮＯ）、繰り返される。

一方、ステップＳ１７で、制御適用判断部１４が、評価が変化したと判断しなかった場合、つまり評価が変化しなかったと判断した場合（ＮＯ）、制御適用判断部１４は、どの制御エンジンｅからの制御依頼も不採用とし、一旦制御を終了する。その後は、ステップＳ１１の処理に戻る。そして、情報収集・蓄積装置３０は、ＮＦＶ環境情報（ネットワーク観測情報及びユーザ需要）を収集して（Ｓ１１）、評価が変化し始めると（Ｓ１７；ＹＥＳ）、制御適用判断部１４は、各制御エンジンｅから受け取った制御依頼（評価結果及び設定命令）のうち、評価に基づき適用許可を与える制御依頼を１つ決定し、この１つ制御依頼をオーケストレータ５０へ転送する。

以上により、第１の実施形態に係る統合制御の処理の説明を終了する。

〔処理の具体例〕
続いて、第１の実施形態に係る統合制御の処理の具体例について２種類説明する。

＜具体例１―１＞
まず、第１の実施形態に係る統合制御の処理の具体例１―１を説明する。

ある一定の時間間隔Δtにより時刻を離散化し、t(=(t-Δt,t))で表す。Δtは、各制御エンジンの応答時間及びオーケストレータ５０によるネットワーク制御適用時間よりも長いものとする。また、制御エンジン数をNとする。時刻tにおける処理として、統合制御アルゴリズムＡ１０は、時刻t-1における各制御エンジンiの制御依頼M_i(x_t-1)を保持してるものとする。

Ｓ１１１：情報配布部１１は、情報収集・蓄積装置３０からネットワーク状態s_tを取得し、各制御エンジンi∈{1,…,N}にネットワーク状態s_tを通知する。ネットワーク状態s_tは、時刻（t-Δt,t）の期間に収集されたＮＦＶ環境情報（トラヒック量、リソース使用量等）に基づき生成される。

Ｓ１１２：各制御エンジンi∈{1,…,N}は、内部ロジックに従って機能配置を計算し、統合制御アルゴリズムＡ１０へ制御依頼M_i(x_t)を通知する。

Ｓ１１３：総合評価推定部１２は、全ての制御エンジンから制御依頼M_i(x_t)を受け取り、（式１）で与えられる状態評価y_i,t-1を計算する。

ここで、|M(x)|は、制御依頼がM(x)であるときのオーケストレータ５０への制御指示数とする。

Ｓ１１４：制御許可先学習部１３は、状態評価の総和r_tを計算し、（式２）で示すように行動価値関数Q(s',i)を更新する。

ここで、s'_tは，s_tを離散化したベクトルとする。

Ｓ１１５：制御適用判断部１４は、ネットワーク状態s'_tに基づき、（式３）の方策に従い適用許可先の制御エンジンa_t∈{1,…,N}を決定し、制御依頼

をオーケストレータ５０へ転送する。

ここで、ε は別途与えるパラメータとする。

なお、前回（時刻t-1）の決定によって系全体としての制御指示数がどの程度下がったかの評価（Ｓ１１１～Ｓ１１３）をQ関数に反映（Ｓ１１４してから、現時点（時刻t）の適用許可先（Ｓ１１５）を決定するため、後述の具体例１－２と比較して、１時刻分だけ制御適用先決定時の情報量が多い。但し、解算出のレスポンスが遅い制御エンジンがあると、前段のQ関数更新に時間がかかり、適用許可先決定までに時間を要する。

以上により、第１の実施形態に係る統合制御の処理の具体例１－１の説明を終了する。

＜具体例１－２＞
続いて、第１の実施形態に係る統合制御の処理の具体例１－２を説明する。

上記具体例１－１と同様の条件、即ち、ある一定の時間間隔Δtにより時刻を離散化し、t(=(t-Δt,t))で表す。Δtは、各制御エンジンの応答時間及びオーケストレータ５０によるネットワーク制御適用時間よりも長いものとする。また、制御エンジン数をNとする。時刻tにおける処理として、統合制御アルゴリズムＡ１０は、時刻t-1における各制御エンジンiの制御依頼M_i(x_t-1)を保持してるものとする。

Ｓ１２１：情報配布部１１は、情報収集・蓄積装置３０からネットワーク状態s_tを取得する。ネットワーク状態s_tは、時刻（t-Δt,t）の期間に収集されたＮＦＶ
環境情報（トラヒック量、リソース使用量等）に基づき生成される。

Ｓ１２２：制御適用判断部１４は、ネットワーク状態s'_tに基づき、上記（式３）の方策に従い適用許可先の制御エンジンa_t∈{1,…,N}を決定する。

Ｓ１２３：情報配布部１１は、各制御エンジンi∈{1,…,N}にネットワーク状態s_tを通知する。

Ｓ１２４：各制御エンジンi∈{1,…,N}は、内部ロジックに従って機能配置を計算し、統合制御アルゴリズムＡ１０へ制御依頼M_i(x_t)を通知する。

Ｓ１２５：制御適用判断部１４は、制御エンジンa_t から制御依頼

を受け取り次第、オーケストレータ５０へ転送する。

Ｓ１２６：総合評価推定部１２は、全ての制御エンジンから制御依頼M_i(x_t)を受け取り、上記（式１）で与えられる状態評価y_i,t-1を計算する。ここで、|M(x))|は制御依頼がM(x)であるときのオーケストレータ５０への制御指示数とする。

Ｓ１２７：制御許可先学習部１３は、状態評価の総和r_tを計算し、上記（式２）で示すように行動価値関数Q(s',i)を更新する。

なお、前回（時刻t-1）までのQ関数に基づいて制御適用先の決定（Ｓ１２１～Ｓ１２５）を行ってから前回の決定に対してQ関数を更新（Ｓ１２６，Ｓ１２７）するため、制御依頼の適用にあたっては、上述の具体例１－１と比べてレスポンスが早い。但し、選択された制御アルゴリズムのレスポンスが遅い場合には、具体例１－１と同等になる。また、前回の決定に対する評価（Q関数の更新）が今回の決定の後となることで、状況変化への追従性が下がる。

〔第１の実施形態の効果〕
以上説明したように、本実施形態の統合制御システム１０は、制御エンジンの制御ポリシや制約条件に関する情報を利用せずに、各制御エンジンが出力した制御依頼から各制御エンジンが保持している現在のネットワーク状態に対する評価推定を実現する。そして、統合制御システム１０は、その結果を踏まえ、各制御エンジンから受け取った制御依頼を、ネットワーク基盤（物理ネットワーク３００）への制御指示を行うオーケストレータへ転送する。これにより、統合制御システム１０は、制御エンジン側のアルゴリズムの開示を受けなくても、全ての制御エンジンを対象とした制御完了状態（個々の制御ポリシが満たされた最適な状態、もしくは全体としてそれ以上改善することが不可能な状態）までの統合制御を効率よく実施することが可能となるという効果を奏する。

●第２の実施形態
次に、本発明の第２の実施形態について説明する。なお、第２の実施形態は、第１の実施形態の変形例であり、第２の実施形態に係る統合制御システム２０は、第１の実施形態に係る統合制御システム１０に対して、メディエータｍ１，ｍ２，ｍ３が追加されている。なお、ここでは、３つのメディエータｍ１，ｍ２，ｍ３が示されているが、２つであっても良いし、４つ以上であってもよい。また、メディエータｍ１，ｍ２，ｍ３の総称を「メディエータｍ」と示す。メディエータｍは、制御エンジンｅ毎に設けられている。

〔実施形態のシステム構成〕
図４を用いて、第２実施形態の通信システムの構成の概略について説明する。図４は、第２の実施形態に係る通信システムの全体構成図である。

図１４示されているように、本実施形態の通信システムは、統合制御システム２０、情報収集・蓄積装置３０、オーケストレータ５０、ネットワーク基盤としての物理ネットワーク３００によって構築されている。なお、第１の実施形態と同様の装置、構成又は機能は、同一の記号を付して説明を省略する。

統合制御システム２０は、単一又は複数のコンピュータによって構築されており、ネットワーク事業者によって管理されている。統合制御システム２０は、ネットワーク事業者自身が作成した制御エンジン、サードパーティーであるサービス事業者が作成した制御エンジン等である複数の制御エンジンｅを有している。また、統合制御システム２０は、統合制御アルゴリズムＡ２０及び複数のメディエータｍを有している。

統合制御アルゴリズムＡ２０は、基本的に第１の実施形態に係る統合制御アルゴリズムＡ１０と同様の役割を果たす。統合制御アルゴリズムＡ２０と統合制御アルゴリズムＡ１０の相違点は後述する。

メディエータｍは、情報収集・蓄積装置３０から受け取ったＮＦＶ環境情報に対し、各制御エンジンｅに対する制御許可頻度に応じた調整量を加算することでＮＦＶ環境情報を加工して、各制御エンジンｅに配布する。即ち、メディエータｍは、情報配布部２１が出力した複数のＮＦＶ環境情報に基づいて所定の単一のＮＦＶ環境情報に加工し、加工後のＮＦＶ環境情報を各制御エンジンｅに配布する。例えば、メディエータｍは、後述のＦＰＬ(Follow the Perturbed Leader)アルゴリズムを用いて、複数のＮＦＶ環境情報に一様ランダムな値を加えて平均を取ることで加工後のＮＦＶ環境情報を得る。

〔統合制御システムの機能構成〕
本実施形態では、統合制御アルゴリズムＡ２０が学習した行動価値関数に基づき、制御適用許可先を決定する。そのため、制御エンジンｅ間で制御適用許可を受ける頻度も異なれば、制御許可を得られない期間に該当制御エンジンｅが受け持つサービスの状況が悪化する可能性がある。そこで、本実施形態では、オンライン意思決定法を活用することで、各制御エンジンｅの時間平均性能を改善する。具体的には、統合制御システム２０は、統合制御アルゴリズムＡ２０と各制御エンジンｅの間にそれぞれの制御エンジン用のメディエータｅを用い、制御エンジンｅに配布する情報に対して、制御許可頻度に応じた大きさの調整量を加えることで、一時的なネットワーク状態に強く依存しない解を制御エンジンｅに算出させる。

統合制御システム２０は、統合制御が収束するまで、統合制御アルゴリズムＡ２０によって実現される機能による処理を繰り返し実施する。

この統合制御アルゴリズムＡ２０によって、情報配布部２１、総合評価推定部２２、制御許可先学習部２３、及び制御適用判断部２４の各機能を実現することができる。情報配布部２１、総合評価推定部２２、制御許可先学習部２３、及び制御適用判断部２４は、それぞれ基本的に、情報配布部１１、総合評価推定部１２、制御許可先学習部１３、及び制御適用判断部１４と同様の機能である。但し、情報配布部２１は、各メディエータｍを介することで、各制御エンジンｅに加工後のＮＦＶ環境情報を配布することができる。また、総合評価推定部２２は、各制御エンジンｅから各メディエータｍを介して制御依頼（制御指示）を受け取る。

〔統合制御システムの処理又は動作〕
続いて、図５を用いて、第２の実施形態に係る統合制御システム２０の処理又は動作について説明する。図５は、第２の実施形態に係る統合制御の処理を示すフローチャートである。

Ｓ３１：情報収集・蓄積装置３０は、物理ネットワークのネットワーク状態を示すＮＦＶ環境情報（ネットワーク観測情報及びユーザ需要等）を収集する。

Ｓ３２：情報配布部２１は、情報収集・蓄積装置３０から取得したＮＦＶ環境情報を各メディエータｍに送信する。また、各メディエータｍは、ＮＦＶ環境情報を加工して、対応する各制御エンジンｅへ配布する。

ここで、各制御エンジンｅの処理を説明する。

Ｓ２０１：制御エンジンｅ１は、メディエータｅ１から、加工後のＮＦＶ環境情報を受け取る。

Ｓ２０２：制御エンジンｅ１は、非開示の制御内容の演算を行う。

Ｓ２０３：制御エンジンｅ１は、情報配布部１１に対して制御依頼を送信する。

このＳ２０１～２０３の処理は、制御エンジンｅ２，ｅ３によっても行われる。

Ｓ３３：各メディエータｍは、各制御エンジンｅからの制御依頼を受け付け、総合評価推定部２２に渡す。

Ｓ３４：総合評価推定部２２は、各制御依頼における制御指示数を集計する。

Ｓ３５：総合評価推定部２２は、各制御エンジンｅにおける、前回の制御適用判断時の制御指示数と今回の制御指示数の差分を計算する。

Ｓ３６：制御許可先学習部２３は、前回の制御適用許可に対する評価を更新する。

Ｓ３７：制御適用判断部２４は、前回と今回で評価が変化したか否かを判断する。

Ｓ３８：制御適用判断部２４がステップＳ３７で評価が変化したと判断した場合（ＹＥＳ）、制御適用判断部２４は、各制御エンジンｅから受け取った制御依頼（評価結果及び設定命令）のうち、評価に基づき適用許可を与える制御依頼を１つ決定し、この１つ制御依頼をオーケストレータ５０へ転送する。

Ｓ３９：オーケストレータ５０は、制御適用判断部２４から受け取った１つの制御依頼を物理ネットワーク３００へ適用する。

Ｓ４０：オーケストレータ５０は、適用完了を確認する。その後は、ステップＳ３１の処理に戻る。このステップＳ３１～Ｓ４０，Ｓ２０１～Ｓ２０３は、評価が変化しなくなるまで（Ｓ３７：ＮＯ）、繰り返される。

一方、ステップＳ３７で、制御適用判断部２４が、評価が変化したと判断しなかった場合、つまり評価が変化しなかったと判断した場合（ＮＯ）、制御適用判断部２４は、どの制御エンジンｅからの制御依頼も不採用とし、一旦制御を終了する。その後は、ステップＳ３１の処理に戻る。そして、情報収集・蓄積装置３０は、ＮＦＶ環境情報（ネットワーク観測情報及びユーザ需要）を収集して（Ｓ３１）、評価が変化し始めると（Ｓ３７；ＹＥＳ）、制御適用判断部２４は、各制御エンジンｅから受け取った制御依頼（評価結果及び設定命令）のうち、評価に基づき適用許可を与える制御依頼を１つ決定し、この１つ制御依頼をオーケストレータ５０へ転送する。

以上により、第２の実施形態に係る統合制御の処理の説明を終了する。

〔処理の具体例〕
続いて、第２の実施形態に係る統合制御の処理の具体例について２種類説明する。

＜具体例２―１＞
まず、第２の実施形態に係る統合制御の処理の具体例２―１を説明する。

上記具体例１－１と同様の条件、即ち、ある一定の時間間隔Δtにより時刻を離散化し、t(=(t-Δt,t))で表す。Δtは、各制御エンジンの応答時間及びオーケストレータ５０によるネットワーク制御適用時間よりも長いものとする。また、制御エンジン数をNとする。時刻tにおける処理として、統合制御アルゴリズムＡ２０は、時刻t-1における各制御エンジンiの制御依頼M_i(x_t-1)を保持してるものとする。

Ｓ２１１：情報配布部１１は、情報収集・蓄積装置３０からネットワーク状態s_tを取得し、各メディエータi∈{1,…,N} にネットワーク状態s_tを通知する。ネットワーク状態s_tは、時刻（t-Δt,t）の期間に収集されたＮＦＶ環境情報（トラヒック量、リソース使用量等）に基づき生成される。

Ｓ２１２：各メディエータi∈{1,…,N}は、（式４）で与えられる加工済のネットワーク状態x_i,tを各制御アルゴリズムM_iに通知する。

この場合、x_i,tは、後述のＦＰＬ(Follow the Perturbed Leader)アルゴリズムに基づいている。

Ｓ２１３：各制御エンジンi∈{1,…,N}は、内部ロジックに従って機能配置を計算し、各メディエータを介して統合制御アルゴリズムＡ２０へ制御依頼M_i(x_i,t)を通知する。

Ｓ２１４：総合評価推定部１２は、全ての制御エンジンから制御依頼M_i(x_i,t)を受け取り、（式５）で与えられる状態評価y_i,t-1を計算する。

ここで、|M(x)|は、制御依頼がM(x)であるときのオーケストレータ５０への制御指示数とする。

Ｓ２１５：制御許可先学習部１３は、状態評価の総和r_tを計算し、上記（式２）で示すように行動価値関数Q(s',i))を更新する。

Ｓ２１６：制御適用判断部１４は、ネットワーク状態s'_tに基づき、上記（式３）の方策に従い適用許可先の制御エンジンa_t∈{1,…,N}を決定し、制御依頼

をオーケストレータ５０へ転送する。

なお、この具体例２－１では、ネットワーク情報の加工に後述のＦＰＬアルゴリズムを利用しているが、例えば回帰分析などを活用した予測アルゴリズムに置き換えても良い。

以上により、第２の実施形態に係る統合制御の処理の具体例２－１の説明を終了する。

＜具体例２－２＞
続いて、第２の実施形態に係る統合制御の処理の具体例２－２を説明する。

上記具体例１－１と同様の条件、即ち、ある一定の時間間隔Δtにより時刻を離散化し、t(=(t-Δt,t))で表す。Δtは、各制御エンジンの応答時間及びオーケストレータ５０によるネットワーク制御適用時間よりも長いものとする。また、制御エンジン数をNとする。時刻tにおける処理として、統合制御アルゴリズムＡ２０は、時刻t-1における各制御エンジンiの制御依頼M_i(x_t-1)を保持してるものとする。

Ｓ２２１：情報配布部１１は、情報収集・蓄積装置３０からネットワーク状態s_tを取得する。ネットワーク状態s_tは、時刻（t-Δt,t）の期間に収集されたＮＦＶ環境情報（トラヒック量、リソース使用量等）に基づき生成される。

Ｓ２２２：制御適用判断部１４は、ネットワーク状態s'_tに基づき、上記（式３）の方策に従い適用許可先の制御エンジンa_t∈{1,…,N}を決定する。

Ｓ２２３：情報配布部１１は、各メディエータi∈{1,…,N}にネットワーク状態s_tを通知する。

Ｓ２２４：各メディエータi∈{1,…,N}は、上記（式４）で与えられる加工済のネットワーク状態x_i,tを各制御アルゴリズムM_iに通知する。

Ｓ２２５：各制御エンジンi∈{1,…,N}は、内部ロジックに従って機能配置を計算し、統合制御アルゴリズムＡ２０へ制御依頼M_i(x_i,t)を通知する。

Ｓ２２６：制御適用判断部１４は、制御エンジンa_t から制御依頼

を受け取り次第、オーケストレータ５０へ転送する。

Ｓ２２７：総合評価推定部１２は、全ての制御エンジンから制御依頼M_i(x_i,t)を受け取り、上記（式５）で与えられる状態評価y_i,t-1を計算する。

Ｓ２２８：制御許可先学習部１３は、状態評価の総和r_tを計算し、上記（式２）で示すように行動価値関数Q(s',i)を更新する。

なお、この具体例２－２では、具体例２－１と同様に、ネットワーク情報の加工に後述のＦＰＬアルゴリズムを利用しているが、例えば回帰分析などを活用した予測アルゴリズムに置き換えても良い。

以上により、第２の実施形態に係る統合制御の処理の具体例２－２の説明を終了する。

＜ＦＰＬアルゴリズム＞
続いて、メディエータｍが行うネットワーク情報の加工の一例として、ＦＰＬアルゴリズムを用いた場合について説明する。

まず、前提として、n次元空間における線形和コストのオンライン意思決定問題として、以下の状態になっているものとする。

時刻tの時の意思決定をd_t とする：d_t∈D⊂Rⁿ
意思決定d_t の後に（ネットワーク）状態s_tが観測される：s_t∈S⊂Rⁿ
コストは意思決定と（ネットワーク）状態の内積d・sで定義される
M(s)をsが与えられた時のコスト最小解を与える関数とする

この場合、
（１）ＦＰＬ(δ)アルゴリズムは、各時刻tにおいて、p_t
を

から一様にランダムに選ぶ。
（２）制御エンジンｅは、

を意思決定とする。

また、定理として、ＦＰＬアルゴリズムによる累積コストの期待値はδをパラメータとして以下で与えられる．

但し、

全てのd,d'∈Dに対して、

全てのd∈D, s∈Sに対して、

全てのs∈Sに対して、

である。

〔第２の実施形態の効果〕
以上説明したように、本実施形態の統合制御システム１０は、第１の実施形態と同様の効果を奏する。

更に、オーケストレータ５０では、特定の１つの制御エンジンｅによる制御依頼しか採用しないため、統合制御が収束するには多くの時間が掛かり、又は所定時間内で統合制御できる頻度が減ってしまうという課題が生じる。これを防ぐために、第２の実施形態では、メディエータｍが、例えば、１０回分の取得したネットワーク情報を記憶しておき、ＦＰＬアルゴリズム等を利用することで、１回分の単一のネットワーク情報に加工してから制御エンジンｅに送る。これにより、当該課題を解決することができる。

〔補足〕
以上、本発明は、上記の実施形態に限定されることなく、例えば以下に示すように、種々の変更及び応用が可能である。

（１）統合制御システム１０、２０、統合制御装置Ａ１０，Ａ２０は、コンピュータとプログラムによって実現できるが、このプログラムを（非一時的）記録媒体に記録することも、インターネット等の通信ネットワークを介して提供することも可能である。

（２）ＣＰＵ１０１は、単一だけでなく、複数であってもよい。

１０ 統合制御システム
Ａ１０ 統合制御アルゴリズム（統合制御装置）
１１ 情報配布部
１２ 総合評価推定部
１３ 制御許可先学習部
１４ 制御適用判断部
ｅ，ｅ１～ｅ３ 制御エンジン
Ａ２０ 統合制御アルゴリズム（統合制御装置）
２１ 情報配布部
２２ 総合評価推定部
２３ 制御許可先学習部
２４ 制御適用判断部
ｍ，ｍ１～ｍ３ メディエータ
３０ 情報収集・蓄積装置
５０ オーケストレータ
３００ 物理ネットワーク（ネットワーク基盤、ＮＦＶ環境）
３１０ 汎用サーバ
３２０ ノード（転送装置）
３３０ ユーザ端末

Claims (8)

1. 物理ネットワーク上で異なる複数の仮想ネットワークを構築するための複数の制御エンジンを統合制御する統合制御装置であって、
   前記物理ネットワークの状況を示すＮＦＶ（Network Functions Virtualization）環境情報を取得して前記複数の制御エンジンに配布することで、前記複数の制御エンジンから前記複数の仮想ネットワークに関する制御依頼を受け付ける情報配布部と、
   前記複数の制御エンジンから受け取った前記制御依頼に基づき、現在の前記物理ネットワークの状況に対して前記複数の制御エンジンからの前記制御依頼における制御指示の総数を集計する総合評価推定部と、
   前記総合評価推定部によって集計された前記制御指示の総数が前回の集計時に比べて少なくなるように、強化学習を利用して制御許可決定用の行動価値関数を更新する制御許可先学習部と、
   前記総合評価推定部によって集計された前記制御指示の総数が前回と今回で変化した場合には、前記複数の制御エンジンのうち、前記行動価値関数に基づいて所定の制御エンジンを決定し、当該所定の制御エンジンから受け取った所定の制御依頼を前記物理ネットワーク側へ転送する制御適用判断部と、
   を有する統合制御装置。
2. 請求項１に記載の統合制御装置と、
   前記複数の制御エンジンと、
   を有する統合制御システム。
3. 請求項２に記載の統合制御システムであって、
   前記情報配布部が出力した複数の前記ＮＦＶ環境情報に基づいて所定の単一のＮＦＶ環境情報に加工し、加工後のＮＦＶ環境情報を前記複数の制御エンジンに配布するメディエータを有する統合制御システム。
4. 前記メディエータは、ＦＰＬアルゴリズムを用いて、複数の前記ＮＦＶ環境情報に一様ランダムな値を加えて平均を取ることで前記加工後のＮＦＶ環境情報を得る、請求項３に記載の統合制御システム。
5. 物理ネットワーク上で異なる複数の仮想ネットワークを構築するための複数の制御エンジンを統合制御する統合制御システムであって、
   前記物理ネットワークの状況を示すＮＦＶ環境情報を取得して前記複数の制御エンジンに配布することで、前記複数の制御エンジンから前記複数の仮想ネットワークに関する制御依頼を受け付ける情報配布部と、
   前記複数の制御エンジンから受け取った前記制御依頼に基づき、現在の前記物理ネットワークの状況に対して前記複数の制御エンジンからの前記制御依頼における制御指示の総数を集計する総合評価推定部と、
   前記総合評価推定部によって集計された前記制御指示の総数が前回の集計時に比べて少なくなるように、強化学習を利用して制御許可決定用の行動価値関数を更新する制御許可先学習部と、
   前記総合評価推定部によって集計された前記制御指示の総数が前回と今回で変化した場合には、前記複数の制御エンジンのうち、前記行動価値関数に基づいて所定の制御エンジンを決定し、当該所定の制御エンジンから受け取った所定の制御依頼を前記物理ネットワーク側へ転送する制御適用判断部と、
   を実現する統合制御アルゴリズムと、
   前記複数の制御エンジンと、
   を有する統合制御システム。
6. 請求項５に記載の統合制御システムであって、
   前記情報配布部が出力した複数の前記ＮＦＶ環境情報に基づいて所定の単一のＮＦＶ環境情報に加工し、加工後のＮＦＶ環境情報を前記複数の制御エンジンに配布するメディエータを有する統合制御システム。
7. 物理ネットワーク上で異なる複数の仮想ネットワークを構築するための複数の制御エンジンを統合制御する統合制御装置が実行する統合制御方法であって、
   前記統合制御装置は、
   前記物理ネットワークの状況を示すＮＦＶ環境情報を取得して前記複数の制御エンジンに配布することで、前記複数の制御エンジンから前記複数の仮想ネットワークに関する制御依頼を受け付ける情報配布処理と、
   前記複数の制御エンジンから受け取った前記制御依頼に基づき、現在の前記物理ネットワークの状況に対して前記複数の制御エンジンからの前記制御依頼における制御指示の総数を集計する総合評価推定処理と、
   前記総合評価推定処理によって集計された前記制御指示の総数が前回の集計時に比べて少なくなるように、強化学習を利用して制御許可決定用の行動価値関数を更新する制御許可先学習処理と、
   前記総合評価推定処理によって集計された前記制御指示の総数が前回と今回で変化した場合には、前記複数の制御エンジンのうち、前記行動価値関数に基づいて所定の制御エンジンを決定し、当該所定の制御エンジンから受け取った所定の制御依頼を前記物理ネットワーク側へ転送する制御適用判断処理と、
   を実行する統合制御方法。
8. コンピュータに、請求項７に記載の方法を実行させるプログラム。