ホーム > 特許ランキング > 楽天モバイル株式会社
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2023-06-06
(54)【発明の名称】自律ネットワーク、コントローラおよび方法
(51)【国際特許分類】
G06F 8/20 20180101AFI20230530BHJP
【ＦＩ】
G06F8/20
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2022562716
(86)(22)【出願日】2021-03-17
(85)【翻訳文提出日】2022-10-26
(86)【国際出願番号】 JP2021010757
(87)【国際公開番号】W WO2021210329
(87)【国際公開日】2021-10-21
(31)【優先権主張番号】63/010,660
(32)【優先日】2020-04-15
(33)【優先権主張国・地域又は機関】US
(81)【指定国・地域】
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＢＬＵＥＴＯＯＴＨ
(71)【出願人】
【識別番号】319010088
【氏名又は名称】楽天モバイル株式会社
(74)【代理人】
【識別番号】100105924
【弁理士】
【氏名又は名称】森下 賢樹
(72)【発明者】
【氏名】今井 ピエール
(72)【発明者】
【氏名】ハーヴィー ポール
(72)【発明者】
【氏名】アミン タレック
【テーマコード（参考）】
5B376
【Ｆターム（参考）】
5B376AA25
5B376AA32
5B376BC08
5B376BC18
5B376BC31
5B376BC38
(57)【要約】
【解決手段】自律ネットワークのためのコントローラは、コントローラコンポーネントを構成するために相互接続された態様で構成可能および置換可能なモジュールを実行するプロセッサを含む。コントローラコンポーネントは、コントローラの制御下の少なくとも一つの被制御要素に関する測定データを収集する測定コンポーネントと、少なくとも一つの被制御要素の現状を取得するために収集された測定データを処理する分析コンポーネントと、取得された現状に基づいて、少なくとも一つの被制御要素に関して取るべきアクションを決定する決定コンポーネントと、少なくとも一つの被制御要素の動作、および、少なくとも一つの被制御要素の構成、の少なくともいずれかにおける変化をもたらすことによって、少なくとも一つの被制御要素に関して決定されたアクションを実行するアクションコンポーネントと、を備える。
【選択図】図１
【選択図】図１
【特許請求の範囲】
【請求項1】
複数の構成可能および置換可能なモジュールを含む少なくとも一つのメモリと、少なくとも一つのメモリに接続され、コントローラコンポーネントを構成するために相互接続された態様で複数のモジュールを実行するように構成される少なくとも一つのプロセッサと、
を備え、
コントローラコンポーネントは、
コントローラの制御下の少なくとも一つの被制御要素に関する測定データを収集するように構成される測定コンポーネントと、
少なくとも一つの被制御要素の現状を取得するために収集された測定データを処理するように構成される分析コンポーネントと、
取得された現状に基づいて、少なくとも一つの被制御要素に関して取るべきアクションを決定するように構成される決定コンポーネントと、
少なくとも一つの被制御要素の動作、および、少なくとも一つの被制御要素の構成、の少なくともいずれかにおける変化をもたらすことによって、少なくとも一つの被制御要素に関して決定されたアクションを実行するように構成されるアクションコンポーネントと、
を備える自律ネットワークのためのコントローラ。
【請求項2】
コントローラコンポーネントのそれぞれは、複数のモジュールのうち相互接続されたモジュールを備える、請求項１に記載のコントローラ。
【請求項3】
コントローラコンポーネントのそれぞれの相互接続されたモジュールは、少なくともソースモジュールと、ソースモジュールに直接的または間接的に接続されるシンクモジュールを備え、一のコントローラコンポーネントのソースモジュールが、他のコントローラコンポーネントのシンクモジュールに接続される、
請求項２に記載のコントローラ。
【請求項4】
複数のモジュールのそれぞれは、アプリケーションプログラミングインターフェース（API）を備え、当該ＡＰＩは、
複数のモジュールのうち前記モジュールをユニークに特定するユニークなＩＤと、
前記モジュールの少なくとも入力および出力を定める従属関係と、
を備え、
一のモジュールのＡＰＩにおける入力を定める従属関係が、他のモジュールのＡＰＩにおける出力を定める従属関係に合う場合、複数のモジュールのうち二つのモジュールが接続可能である、
請求項１から３のいずれかに記載のコントローラ。
【請求項5】
複数のモジュールのそれぞれは、モジュールの論理演算を実行するために少なくとも一つのプロセッサによって実行可能なコード、
論理演算を初期化および構成するために少なくとも一つのプロセッサによって使用されるパラメータ、
少なくとも一つのＡＰＩの記述、モジュールの入力または出力を含むメタ情報、
の少なくともいずれかを更に備える、
請求項４に記載のコントローラ。
【請求項6】
少なくとも一つのプロセッサは、相互接続されたモジュールの一つを他の構成可能および置換可能なモジュールに置換すること、相互接続されたモジュールの間の接続を変更すること、の少なくともいずれかを、他のコントローラによって決定および実行されるアクションに対応する命令に応じて実行するように構成される、請求項１から５のいずれかに記載のコントローラ。
【請求項7】
少なくとも一つのメモリは、少なくとも一つのコントローラコンポーネントによってアクセス可能であり、以前の選択および対応する結果を含む知識ベースを更に含む、請求項１から６のいずれかに記載のコントローラ。
【請求項8】
コントローラコンポーネントは、少なくとも一つの被制御要素の動作、および、少なくとも一つの被制御要素の構成、の少なくともいずれかを最適化するために、認識制御ループを共に実行するように構成される、請求項１から７のいずれかに記載のコントローラ。
【請求項9】
システム階層グラフ中に相互接続される複数のコントローラを備え、複数のコントローラのそれぞれは、
複数の構成可能および置換可能なモジュールを含む少なくとも一つのメモリと、
少なくとも一つのメモリに接続され、コントローラグラフに応じて、前記各コントローラの制御下の少なくとも一つの被制御要素に関する測定データに基づいて、少なくとも一つの被制御要素に関するアクションを実行するために、相互接続された態様で複数のモジュールを実行するように構成される少なくとも一つのプロセッサと、
を備え、
複数のコントローラは、
少なくとも一つの被制御要素の動作における変化をもたらすことによって、アクションを実行するように構成される少なくとも一つの動作コントローラ（OC）と、
少なくとも一つの被制御要素の構成における変化をもたらすことによって、アクションを実行するように構成される少なくとも一つの展開コントローラ（EC）と、
を備える、
自律ネットワーク。
【請求項10】
少なくとも一つのＯＣの制御下の少なくとも一つの被制御要素は、システム階層グラフにおいて少なくとも一つのＯＣの下の他のＯＣ、ハードウェア機器の少なくともいずれかを含み、少なくとも一つのＥＣの制御下の少なくとも一つの被制御要素は、システム階層グラフにおいて少なくとも一つのＥＣの下の他のコントローラ、ハードウェア機器の少なくともいずれかを含む、
請求項９に記載のネットワーク。
【請求項11】
少なくとも一つのＥＣの制御下の少なくとも一つの被制御要素は、システム階層グラフにおいて少なくとも一つのＥＣの下の他のコントローラを含み、少なくとも一つのＥＣは、前記他のコントローラのコントローラ展開、システム階層グラフにおいて少なくとも一つのＥＣの下のサブグラフの階層展開の少なくともいずれかを実行することによって、前記他のコントローラに関するアクションを実行するように構成される、
請求項１０に記載のネットワーク。
【請求項12】
コントローラ展開は、前記他のコントローラにおいて相互接続されたモジュールの一つを、同一モジュールの異なるインスタンス、または、異なる構成可能および置換可能なモジュールで置換すること、
前記他のコントローラのコントローラグラフを変えること、
の少なくともいずれかを含む、
請求項１１に記載のネットワーク。
【請求項13】
階層展開は、前記他のコントローラを異なるコントローラで置換させること、
少なくとも一つのＥＣの下のサブグラフにおいて変化をもたらすこと、
の少なくともいずれかを含む、
請求項１２に記載のネットワーク。
【請求項14】
複数のコントローラのそれぞれについて、前記各コントローラにおいて相互接続される複数の構成可能および置換可能なモジュールのそれぞれは、アプリケーションプログラミングインターフェース（API）を備え、
当該ＡＰＩは、
複数のモジュールのうち前記モジュールをユニークに特定するユニークなＩＤと、
前記モジュールの少なくとも入力および出力を定める従属関係と、
を備え、
一のモジュールのＡＰＩにおける入力を定める従属関係が、他のモジュールのＡＰＩにおける出力を定める従属関係に合う場合、複数のモジュールのうち二つのモジュールが接続可能である、
請求項９から１３のいずれかに記載のネットワーク。
【請求項15】
ＥＣは、システム階層グラフにおいてＥＣの下のサブグラフにおける一または複数の更なるコントローラを制御するように構成され、ＥＣは、ＥＣのソースモジュールのＡＰＩを介して現れる少なくとも一つの特別な従属関係を備え、
ＥＣは、前記一または複数の更なるコントローラの数およびタイプ、前記一または複数の更なるコントローラのコントローラ展開の実行可否、ＥＣの下のサブグラフの階層展開の実行可否、の少なくともいずれかを示すために、少なくとも一つの特別な従属関係を定めるように構成される、
請求項１４に記載のネットワーク。
【請求項16】
複数のコントローラのそれぞれの少なくとも一つのプロセッサは、少なくとも一つの被制御要素の動作、および、少なくとも一つの被制御要素の構成、の少なくともいずれかを最適化する認識制御ループを実行するために、複数の相互接続されたモジュールを実行するように構成される、請求項９から１５のいずれかに記載のネットワーク。
【請求項17】
システム階層グラフ中に相互接続される複数のコントローラを備える自律ネットワークの稼働方法であって、動作コントローラ（OC）または展開コントローラ（EC）である複数のコントローラのそれぞれは、複数の構成可能および置換可能なモジュールを含む少なくとも一つのメモリと、少なくとも一つのメモリに接続され、相互接続された態様で複数のモジュールを実行するように構成される少なくとも一つのプロセッサと、を備え、
方法は、
ＯＣによって、システム階層グラフにおいて下方のハードウェア機器または他のＯＣを制御することと、
ＥＣによって、システム階層グラフにおいて下方の既存コントローラを制御および展開することと、
を備え、
前記展開することは、コントローラグラフのセクションを完了するように構成可能な、構成可能および置換可能な候補モジュールの数を特定することと、コントローラグラフのセクションを完了するように様々な候補モジュールが相互接続される複数の異なる構成を決定することと、それぞれが複数の構成の一つに対応する、複数の展開されるコントローラを出力することと、を備え、
試行管理部によって、複数の展開されるコントローラのいずれかによって前記既存コントローラが置換可能かを判定するために、オンライン試行を実行することと、
を更に備える自律ネットワークの稼働方法。
【請求項18】
複数の展開されるコントローラのそれぞれについて、前記オンライン試行は、展開されるコントローラが論理的な誤りを含むか否かを判定するためのサニティチェック、
有用性関数を使用することによって、展開されるコントローラの有用性を評価するためのシミュレーション、
試行管理部が、初めは展開されるコントローラの物理的範囲または時間的範囲の少なくともいずれかを制限し、展開されるコントローラの測定または評価された有用性に基づいて、徐々に前記物理的範囲または時間的範囲の少なくともいずれかを大きくするネットワークトライアル、
の少なくともいずれかを含む、
請求項１７に記載の方法。
【請求項19】
試行管理部によって、ネットワークにおいて他のコントローラを展開する複数のＥＣによって開始された複数のオンライン試行を協調させることを更に備え、前記協調させることは、リソース配分およびスケジューリングの少なくともいずれかを含む、
請求項１７または１８に記載の方法。
【請求項20】
構成可能および置換可能な候補モジュールのそれぞれは、アプリケーションプログラミングインターフェース（API）を備え、当該ＡＰＩは、
前記候補モジュールをユニークに特定するユニークなＩＤと、
前記候補モジュールの少なくとも入力および出力を定める従属関係と、
を備え、
候補モジュールのＡＰＩにおける入力を定める従属関係が、他の候補モジュールのＡＰＩにおける出力を定める従属関係に合う場合、コントローラグラフのセクションを完了するための複数の構成のそれぞれが、候補モジュールを相互接続することによって決定される、
請求項１７から１９のいずれかに記載の方法。
【発明の詳細な説明】
【背景技術】
【0001】
ネットワーキングおよび通信システムは、日々の生活に大きなインパクトを持つ。自動車、ウェアラブル、および他のIoT（Internet-of-Things）関連用途の予想される拡大のために、この影響は近い将来に成長することが予想されている。この大規模な変革は、理解および／または管理の面で複雑化しながら成長する通信ネットワークの進歩に依拠している。
【図面の簡単な説明】
【0002】
本開示の様々な側面は、付随する図面を参照しながら以下の詳細な記述を読むことで良く理解される。なお、産業における標準的な慣行に従って、様々な特徴は原寸通りに描かれない。実際、様々な特徴の寸法は、議論の明確性のために任意に増減されうる。
【0003】
【図1】いくつかの実施形態に係る自律ネットワークのためのコントローラの模式的なブロック図である。
【図2】いくつかの実施形態に係る自律ネットワークのセクションの模式的なブロック図である。
【図3】いくつかの実施形態に係るコントローラ展開において展開されているコントローラの部分のいくつかの模式的なブロック図を示す。
【図4】いくつかの実施形態に係るコントローラ展開のためのオンライン試行における自律ネットワークの部分の模式的なブロック図である。
【図5】いくつかの実施形態に係る自律ネットワークにおける方法のフローチャートである。
【図6】いくつかの実施形態に係るＣＤＮのための自律ネットワークのトラフィックロードバランシングセクションの模式的なブロック図である。
【図7】いくつかの実施形態に係る測定コンポーネントの様々な構成の模式的なブロック図である。
【図8】いくつかの実施形態に係るコンピュータハードウェア構成例の模式的なブロック図である。
【発明を実施するための形態】
【0004】
以下の開示は、提供される主題の異なる特徴を実施するための多くの異なる実施形態または例を提供する。コンポーネント、値、動作、材料、配置等の具体的な例は、本開示を単純化するために後述される。もちろん、これらは単なる例に過ぎず、限定する意図ではない。他のコンポーネント、値、動作、材料、配置等も考えられる。例えば、以下の記述において第２の特徴の上方または上に第１の特徴を形成することは、第１および第２の特徴が直接的に接触して形成される実施形態を含んでもよいし、第１および第２の特徴が直接的に接触しないように追加的な特徴が第１および第２の特徴の間に形成される実施形態を含んでもよい。加えて、本開示は、参照番号および／または文字を様々な例において繰り返してもよい。この繰返しは、簡潔性および明確性のためであり、それ自体が様々な実施形態および／または議論される構成の間の関係を規定するものではない。
【0005】
急成長中および／または複雑な通信ネットワークに関して現れる課題に取り組む一つのアプローチは、ネットワークを自律型にすることである。自律（型）ネットワークは、予期しないイベントに対処および適応する、および／または、例えば、僅かな人的介入または人的介入なしで、利用可能になった新しい技術を取り込むことによって、将来のチャレンジに対して自身を向上および適合させるように構成される。
【0006】
いくつかの実施形態は、構成可能および置換可能なモジュールからコントローラを構成し、より高いレベルのコントローラがより低いレベルのコントローラを制御および／または展開するように構成されるシステム階層グラフにおいてコントローラを相互接続し、展開されるコントローラを評価するためのオンライン試行を実行することによって、自律ネットワークを実現することを可能にする。少なくとも一つの実施形態では、構成可能および置換可能なモジュールが、例えば、一または複数の既存のモジュールを、異なる同等のモジュールおよび／または既存のモジュールの異なるインスタンスで置換することによって、コントローラの変更、最適化または展開を容易にする。一または複数の実施形態では、コントローラの最適化／展開および／またはオンライン試行がランタイムに実行されるように構成され、自律ネットワークが、現れる課題に取り組む、および／または、新しい技術に適応することを可能にする。様々な実施形態の他の利点もここで記述される。
【0007】
図１は、いくつかの実施形態に係る自律ネットワークのためのコントローラ１００の模式的なブロック図である。
【0008】
コントローラ１００は、複数の相互接続されたコントローラコンポーネント（フェーズまたはステージとも表される）を備える。図１における構成例では、複数のコントローラコンポーネントは、測定コンポーネント１１０、分析コンポーネント１２０、決定コンポーネント１３０、アクションコンポーネント１４０を備える。コントローラコンポーネントのそれぞれは、複数の相互接続されたモジュールを備える。例えば、測定コンポーネント１１０は、ソースモジュール１１１、シンクモジュール１１２、ソースモジュール１１１およびシンクモジュール１１２の間に接続される一または複数の中間モジュール１１５、１１６を備える。同様に、分析コンポーネント１２０、決定コンポーネント１３０、アクションコンポーネント１４０は、各ソースモジュール１２１、１３１、１４１、各シンクモジュール１２２、１３２、１４２、各ソースモジュールおよびシンクモジュールの間の各中間モジュール１２５、１３５、１４５を備える。少なくとも一つの実施形態では、コントローラコンポーネントのシンクモジュールが、同じコントローラコンポーネントのソースモジュールに直接的に接続可能である。図１におけるコントローラコンポーネント間の矢印によって示されるように、ループにおける先のコントローラコンポーネントのシンクモジュールが次のコントローラコンポーネントのソースモジュールに接続され、次のコントローラコンポーネント（すなわち、次のフェーズ）のソースモジュールに先のコントローラコンポーネント（すなわち、先のフェーズ）のシンクモジュールからの出力へのアクセスが与えられるように、コントローラコンポーネント１１０、１２０、１３０、１４０はループ中に相互接続される。各コントローラコンポーネント（すなわち、各フェーズ）に対する要求の詳細な記述は、この次のフェーズ内に存在するモジュールから取得される追加的な要求と併せて、コントローラ仕様書（ここで記述される）によって提供される。例えば、測定コンポーネント１１０のシンクモジュール１１２は、分析コンポーネント１２０のソースモジュール１２１に接続され、分析コンポーネント１２０のシンクモジュール１２２は、決定コンポーネント１３０のソースモジュール１３１に接続され、決定コンポーネント１３０のシンクモジュール１３２は、アクションコンポーネント１４０のソースモジュール１４１に接続され、アクションコンポーネント１４０のシンクモジュール１４２は、測定コンポーネント１１０のソースモジュール１１１に接続される。少なくとも一つの実施形態では、コントローラコンポーネントのループは、ここで記述されるように認識制御ループである。図１の各コントローラコンポーネント１１０、１２０、１３０、１４０における数および／または様々なモジュールが相互接続される態様は例である。例えば、図３に関して記述されるように、他の配置も様々な実施形態の範囲内である。
【0009】
コントローラ１００は、例えば、図８におけるコンピュータハードウェア構成に関して記述されるように、少なくとも一つのメモリ（図１では不図示）と、少なくとも一つのメモリに接続される少なくとも一つのプロセッサ（図１では不図示）を備える。少なくとも一つの実施形態では、コンピュータハードウェア構成の一または複数の他のコンポーネントもコントローラ１００に含まれる。各コントローラコンポーネント１１０、１２０、１３０、１４０中またはコントローラ１００全体中に相互接続される、記述されるモジュール１１１、１１２、１１５、１１６、１２１、１２２、１２５、１３１、１３２、１３５、１４１、１４２、１４５は、コントローラ１００の少なくとも一つのメモリに含まれる構成可能および置換可能なモジュールである。コントローラコンポーネント１１０、１２０、１３０、１４０は、少なくとも一つのプロセッサが相互接続された態様でモジュールを実行する際に、コントローラ１００の少なくとも一つのプロセッサによって構成される。例えば、少なくとも一つの実施形態では、測定コンポーネント１１０を構成するためのモジュールを実行する少なくとも一つのプロセッサによって、ダイナミックリンクライブラリ（DLL）がランタイムで相互接続されるのと同様に、モジュール１１１、１１５、１１６、１１２がランタイムで相互接続される。少なくとも一つの実施形態では、モジュールがロードタイムで相互接続される。少なくとも一つの実施形態では、コントローラ１００のいくつかのコントローラコンポーネント、またはコントローラ１００全体が、プロセッサによって実装される。更なる実施形態では、コントローラ１００の少なくとも一つのコントローラコンポーネントが、接続またはネットワーク上に分散されたいくつかのプロセッサによって実装される。
【0010】
前述のように、コントローラ１００のコントローラコンポーネントを構成するモジュールは、具体的な要求を満たすために様々な組合せで選択および相互接続されるように構成される構成可能および置換可能なモジュールである。このようなモジュールは、少なくとも一つの実施形態においてコントローラ１００を容易に変更または展開できるように更に置換可能である。構成可能および置換可能なモジュールの構成例は、コントローラ１００における測定コンポーネント１１０のモジュール１１５に関して与えられる。
【0011】
モジュール１１５等の構成可能および置換可能なモジュールは、ソフトウェアセクション１５０および対応する構成情報１６０を備える。
【0012】
ソフトウェアセクション１５０は、モジュール１１５の動作ロジックを表し、一または複数の実行可能コード１５２、一または複数のパラメータ１５４、アプリケーションプログラミングインターフェース（API）１５６を備える。実行可能コード１５２はモジュール１１５の論理演算を表し、コントローラ１００の少なくとも一つのプロセッサは、モジュール１１５の論理演算を実行するために実行可能コード１５２を実行する。タイムアウト前の待機時間等のパラメータ１５４は、実行可能コード１５２の論理演算を初期化および／または構成するために、コントローラ１００の少なくとも一つのプロセッサによって使用される。ＡＰＩ１５６は、モジュール１１５を相互作用可能にする。少なくとも一つの実施形態では、ＡＰＩ１５６は、モジュール１１５を他のモジュールからユニークに特定するユニークなＩＤ（UID）と、実行可能コード１５２の論理演算に対応する機能を指定する一または複数の従属関係を備える。
【0013】
構成情報１６０は、インターフェース記述１６２、モジュール１１５が要求する能力の入力記述１６４、モジュール１１５が提供する能力の出力記述１６６を含むメタ情報を含む。少なくとも一つの実施形態では、構成情報１６０の目的はモジュールの機能的に正しい構成を担保することである。
【0014】
構成可能および置換可能なモジュールについて記述される構成は例である。構成可能および置換可能なモジュールについての他の構成も、様々な実施形態の範囲内である。少なくとも一つの実施形態では、構成可能および置換可能なモジュールの構成が、使用されるソフトウェア、全体動作目的、モジュールの範囲のいずれにおいても、特定の技術選択を要求しない。これは、アプリケーションにおけるソフトウェアモジュールのサイズおよび範囲を決定する概念と同等である。少なくとも一つの実施形態では、コントローラ１００を構成する一または複数の構成可能および置換可能なモジュールが、ユーザによって提供される。いくつかの実施形態では、コントローラ１００を構成する一または複数の構成可能および置換可能なモジュールが、自動生成またはソフトウェア生成される。
【0015】
いくつかの実施形態では、モジュールは互いに接続または置換される他のモジュールによって提供されるＡＰＩ１５６等のＡＰＩの存在および／または記述に依存する。ＡＰＩは、コントローラコンポーネントまたはコントローラ全体を生成するためのモジュールを、プログラム的または自動的に一斉に構成することを可能にする。例えば、同じＡＰＩが複数の異なるモジュールによって提供される。例えば、音声エンコーディング機能を有するオーディオコーデックは、例えば、無損失のフリーロスレスオーディオコーデック（FLAC: Free Lossless Audio Codec）モジュールに対応するオプションのタグ無損失や、例えば、有損失のＭＰ３モジュールに対応するオプションのタグ有損失を有するエンコードＡＰＩを提供する。オプションのタグは、エンコードされた出力のデコーディングがビット的に同一の入力データを返すか否かを示す。いくつかの実施形態では、オプションのタグと組み合わされるグローバルにユニークなＡＰＩの特定部が、構成可能性および相互運用性についての「契約」を構成し、特定のＡＰＩを要求するモジュールが同じ与えられたＡＰＩを有する任意のモジュールを利用できることを保証する。同じＡＰＩを有するモジュールは、互いに置換可能または交換可能である。更なる例では、同じモジュールが、パラメータ１５４、モジュールへの入力等の異なるパラメータに対応する異なるインスタンスを有する。このような同じモジュールの異なるパラメータによるインスタンスも、置換可能または交換可能である。少なくとも一つの実施形態では、一のモジュールのＡＰＩを通じて現れる一または複数の従属関係が、このモジュールが接続される他のターゲットモジュールによって提供される必要がある条件または要求を定める。プログラミング用語では、このような接続は、例えば、必要なＡＰＩを提供するオブジェクトに対するポインタ、または遠隔ホスト上の遠隔手続呼出し（RPC: Remote Procedure Call）機能によって表される。図１における構成例では、モジュール１１６のＡＰＩにおける入力（要求）を定める従属関係が、モジュール１１５のＡＰＩ１５６における出力（提供）を定める従属関係に合う場合、モジュール１１６がモジュール１１５の下流に接続可能である。
【0016】
三つのモジュールの各ＡＰＩを通じて現れる以下の記述を有する三つの構成可能および置換可能なモジュールに関して、更なる具体例が以下で与えられる。
【表1】
【0017】
以上に示されるように、記述言語を使用して各モジュールの能力、構成可能パラメータ、インターフェースを指定することによって、ユニークなＩＤ、すなわち「LowPassFilter」「HighPassFilter」「FLAC」のそれぞれによって、上記三つのモジュールのそれぞれをユニークに特定することが可能である。各モジュールの記述の残りは、このモジュールが提供する能力、その要求、その構成パラメータの許容範囲を定める。許容範囲は、各構成パラメータが取れる値の範囲および／または可能なパラメータの値の組を記述する。例えば、モジュール「LowPassFilter」は、コーデックおよびフィルタを提供し、コーデックを要求し、「0..9, 1..100, {5, 7, 9}」の範囲における構成パラメータを受け入れる。モジュール「LowPassFilter」の入力（要求）を定める従属関係（コーデック）が、モジュール「HighPassFilter」の出力 （提供）を定める従属関係（同じくコーデック）に合うため、モジュール「LowPassFilter」はモジュール「HighPassFilter」の下流に接続可能である（図３に関して記述されるように）。
【0018】
少なくとも一つの実施形態では、構成情報１６０等の標準的な記述を各モジュールに提供させることによって、同等だが異なるモジュールまたはモジュールインスタンスがプログラム的に交換可能になる。例えば、ウェブサーバのために構成された圧縮モジュールは、モジュール記述に互換性がある限りロギングシステムにおいても再利用可能である。このモジュール再利用は、少なくとも一つの実施形態における利点である。
【0019】
いくつかの実施形態では、ここで記述されるような測定データを受け取る測定コンポーネント１１０の文脈において、測定データを測定コンポーネント１１０に提供するセンサの記述が、関連するセンサまたは提供されるセンサデータを測定コンポーネント１１０が理解できるように提供される。センサについては二つのタイプの記述がある。第１のタイプのセンサ記述は、上記のモジュール記述と同様であり、サーミスタ、パケットプローブ、エネルギーメータ等のセンサの記号的記述や、それらが生成する摂氏温度、パケット損失、ジュール等のデータタイプに関する。センサの開発者は、この情報を仕様書によって提供する。一または複数の実施形態はセンサタイプおよびデータの分類をサポートし、他のセンサネットワークおよび／またはIoTにおける努力は、正しいツールを正しいジョブに対して利用するために、センサタイプおよびデータの両方を課題ドメインによって分類することを可能にする。モジュールと同様の標準的な記述を使用してセンサを記述することによって、少なくとも一つの実施形態において一または複数の次の利点が実現される：一つのドメインからのセンサが他のドメインにおいて再利用可能になる、同等だが異なるセンサが交換可能になる、分類が「良い」モジュール構成のプロセスをガイドできる、分類が測定データの集約および同様のセンサクラス間の当該集約の後の再利用のプロセスの自動化を促進できる。第２の記述タイプは、生のセンサデータからの意味の推測に関する。この場合、存在論と組み合わされる分類学の使用が、これらの関係の推測を可能にする。
【0020】
図１における構成例では、コントローラコンポーネント１１０、１２０、１３０、１４０が、いくつかの実施形態では自律制御ループまたは認識サイクル等とも表される認識制御ループであるループ中に相互接続される。このような認識制御ループでは、測定コンポーネント１１０が、コントローラ１００の制御下の少なくとも一つの被制御要素に関する測定データを収集するように構成される。分析コンポーネント１２０は、少なくとも一つの被制御要素の現状を取得するために収集された測定データを処理するように構成される。決定コンポーネント１３０は、取得された現状に基づいて、少なくとも一つの被制御要素に関して取るべきアクションを決定するように構成される。アクションコンポーネント１４０は、少なくとも一つの被制御要素に関して決定されたアクションを実世界で実行するように構成される。アクションは、少なくとも一つの被制御要素の動作または構成における変化を伴う。
【0021】
少なくとも一つの実施形態では、認識ループは自律性を実現するための一つの考慮事項である。認識制御ループは、ここで記述されるように、ハードウェア機器、自律ネットワークにおける他のコントローラ、自律ネットワークのセクションまたはドメインを含む被制御要素の動作または構成を制御、評価または最適化するためにコントローラ１００によって実行される。少なくとも一つの実施形態では、このコントローラ１００の制御または最適化タスクのサイズおよび範囲がユーザによって定められる。いくつかの実施形態では、認識制御ループが、Ｑ学習等の機械学習、教師あり学習、半教師あり学習、教師なし学習、深層学習、深層強化学習等を備える。いくつかの実施形態では、コントローラ１００の少なくとも一つのメモリが、コントローラコンポーネント１１０、１２０、１３０、１４０の少なくとも一つによってアクセス可能であり、機械学習または最適化に使用される以前の選択および対応する結果の履歴を含む知識ベース１９０を更に含む。少なくとも一つの実施形態では、知識ベース１９０が、ここで記述される自律ネットワークの複数のコントローラの間で共有され、ここで記述されるように一または複数のメモリに格納される。
【0022】
例えば、コントローラ１００の制御下の被制御要素は、ネットワーク１７０を介してコントローラ１００に接続されるハードウェア機器を含む。通信ネットワークの文脈では、コントローラ１００によって制御可能なハードウェア機器の例は、基地局、アンテナ、送受信機回路、コンテンツストレージ、サーバ、ルータ等を含むが、これらに限定されない。ソースモジュール１１１を介して測定コンポーネント１１０によって受け取られる測定データ１７１は、アンテナ方向、送信パワー、割当可能または使用中リソース、ビーム形状、トラフィック、要求の数、利用可能ストレージ等を含むが、これらに限定されないハードウェア機器の動作に関するデータを含む。少なくとも一つの実施形態では、コントローラ１００の測定コンポーネント１１０が、温度等のハードウェア機器および／またはコントローラ１００が稼働する環境１８０に関する測定データ１７３を更に受け取るように構成される。用語「センサデータ」は、測定コンポーネント１１０に提供される情報を記述するために使用されるが、全てのこのような情報がセンサを使用することによって収集される必要はない。例えば、送信パワーまたはアンテナの傾き等のハードウェア機器の動作に関する特定の情報は、センサに収集を要求しなくてもハードウェア機器での制御コマンドから取得可能または推測可能である。他の例として、センサデータは、知識ベース１９０等のネットワーク情報データベースにおける履歴データにアクセスする測定コンポーネント１１０のモジュールを介して得られるデータを含む。ここの記述では「センサデータ」は「テレメトリ」とも表される。
【0023】
分析コンポーネント１２０は、ハードウェア機器の動作が所定のサービス品質レベル等の所定の基準を満たすか否かを判定するために、測定コンポーネント１１０によって収集された測定データを分析する。ハードウェア機器の現在の動作によって所定の基準が満たされないとの分析コンポーネント１２０による判定に応じて、決定コンポーネント１３０は、例えば、アンテナの傾斜角度を調整することによって、ハードウェア機器の現在の動作を改善するために取るべきアクションを決定する。そして、アクションコンポーネント１４０は、例えば、ハードウェア機器にアンテナ傾斜角度を調整するように指示するコマンド１７５をハードウェア機器に送ることによって、決定コンポーネント１３０によって決定されたアクションを実行する。いくつかの実施形態では、アクションコンポーネント１４０が、次の制御周期における使用のために、実行されたアクションに関する情報を測定コンポーネント１１０にも送る。こうして認識制御ループが完成する。
【0024】
いくつかの制御周期を経てもハードウェア機器の動作が改善または最適化されない場合（例えば、知識ベース１９０における履歴を通じて認識される）、決定コンポーネント１３０はハードウェア機器を置換することを決定し、アクションコンポーネント１４０は置換を実行するためのコマンドを発行する。例えば、アクションコンポーネント１４０は、現在のアンテナの代わりに他のアンテナを使用する、または、メンテナンスセンターに現在のアンテナの置換の要求を送ることを基地局に指示する。
【0025】
更なる例では、コントローラ１００の制御下の被制御要素が、ここで記述されるような自律ネットワークにおける他のコントローラを含む。少なくとも一つの実施形態では、制御下の他のコントローラの動作または構成を制御、最適化、評価するために、認識制御ループがコントローラ１００によって実行される。決定コンポーネント１３０が、是正アクションが実行されるべきと判定した場合、アクションコンポーネント１４０は、制御下の他のコントローラに動作または構成を変更するように指示する、または変更させる。制御下の他のコントローラの動作における変化は、少なくとも一つの実施形態では、他のコントローラによって直接的または間接的に制御されるハードウェア機器の動作における変化を伴う。制御下の他のコントローラの構成における変化は、少なくとも一つの実施形態では、モジュール、または、例えば、ここで記述されるコントローラ展開におけるように、制御下の他のコントローラにおけるモジュールが相互接続されるコントローラグラフの構成を変更することによって有効になる。
【0026】
いくつかの実施形態では、各コントローラ要素１１０、１２０、１３０、１４０が、他とは独立した時間スケールで動作する。例えば、測定コンポーネント１１０によるセンシングは連続的なプロセスである一方、分析コンポーネント１２０による分析は収集されたデータを解釈するために随時行われる。決定コンポーネント１３０による決定は、周期的または環境および／または被制御要素における変化またはイベントによって引き起こされ、アクションコンポーネント１４０によるアクションは決定に応じたものとなる。
【0027】
ここで、各コントローラ要素は、コントローラグラフに応じて相互接続されたモジュールの構成である。同じコントローラコンポーネントを実装するための様々な構成および／またはグラフの例は、図３に関して与えられる。コントローラ１００は、認識ループにおける各コントローラコンポーネントについての単方向のグラフ（コントローラグラフ）として可視化される。このコントローラグラフにおける各ノードは、一つのモジュールインスタンスを表す。このコントローラグラフのルートは、認識ループにおける次のコントローラコンポーネントの要求される入力に応じたシンクモジュール（例えば、１１２、１２２、１３２、１４２）である。シンクモジュール（例えば、１１２、１２２、１３２、１４２）の目的は、各コントローラコンポーネント（例えば、１１０、１２０、１３０、１４０）が、コントローラ１００の次のコントローラコンポーネント（例えば、１２０、１３０、１４０、１１０）にとって必要な全てを提供することを担保することである。少なくとも一つの実施形態では、少なくとも一つのシンクモジュール（例えば、１１２、１２２、１３２、１４２）が、対応するソースモジュール（例えば、１２１、１３１、１４１、１１１）の鏡像である。
【0028】
ここで記述されるように、モジュールは任意の数の従属関係（すなわち、モジュール記述において定められるＡＰＩ）を有し、コントローラグラフにおける頂点がこれらの従属関係を表す。但し、コントローラグラフの構造は固定されない。各モジュールインスタンス（ノード）の従属関係が、そのノードにおいて開始するサブグラフの構造を案内するため、任意に複雑なグラフが可能である。
【0029】
コントローラの構成のゼロからの生成、再配置、置換、構成変更を通じた操作によって、いくつかの実施形態が新しい状況および状況の変化の両方に適応することを可能にする。図１における構成例では、コントローラ１００が、それぞれ測定、分析、決定、アクションのステージを体現する四つの相互接続されたコントローラコンポーネントを含むものとして記述されたが、少なくとも一つの実施形態ではコントローラ１００を単一の構成として実装することも可能である。しかし、記述されるような四つのコントローラコンポーネントの構成は、（人間および機械の）理解を容易にすると共に、潜在的なモジュール構成の状態空間を低減する。少なくとも一つの実施形態では、ユーザが有用性関数によって、コントローラの適合性または有用性の測定方法のためのメトリックを提供する。具体的な有用性関数は、図６に関する例として以下で与えられる。他の有用性関数および／または有用性関数の自動生成を伴う構成も除外されない。少なくとも一つの実施形態では、コントローラの有用性関数が、コントローラ仕様書に記述される、または、そのソフトウェアに含まれる。少なくとも一つの実施形態では、有用性関数が、コントローラを構成する構成可能および置換可能なモジュールの少なくとも一つに含まれる。
【0030】
加えて、いくつかの実施形態では、全てのコントローラコンポーネントが、知識ベース１９０を通じた永続的な知識へのアクセスを共有する。この構成は、以前の選択および対応する結果、変化するシステム状態、異なる更新期間に亘る同期の理解を容易にする。少なくとも一つの実施形態では、保存しておくべき知識が具体的なコントローラによって異なり、適用可能な場合には異なるコントローラによって利用可能である。少なくとも一つの実施形態では、知識ストレージが結果的に一貫した分散データストレージとなる。
【0031】
図２は、いくつかの実施形態に係る自律ネットワーク２００のセクションの模式的なブロック図である。図２における自律ネットワーク２００のセクションは、複数のコントローラを備える制御プレーンである。自律ネットワーク２００は、図２において例示されるコントローラのうち動作コントローラによって制御されるハードウェア機器を更に備える。簡潔性のため、図２ではハードウェア機器が示されない。ハードウェア機器の例はここで記述され、基地局、アンテナ、送受信機回路、コンテンツストレージ、サーバ、ルータ等を含むが、これらに限定されない。更に、図２における制御プレーンは、トラフィックシェーピングおよびアンテナの傾きの最適化のための具体的なユースケースの例である。コントローラの他の配置および／または他のユースケースも、様々な実施形態の範囲内である。
【0032】
少なくとも一つの実施形態では、自律ネットワーク２００の各コントローラが、図１に関して記述されたような構成を有する。自律ネットワーク２００の複数のコントローラは、図２において例示されるように、システム階層グラフ中に相互接続される。示されるシステム階層グラフは例である。他のシステム階層グラフも、様々な実施形態の範囲内である。自律ネットワーク２００の複数のコントローラは、少なくとも一つの動作コントローラ（OC）および少なくとも一つの展開コントローラ（EC）を備える。ＯＣは、システム階層グラフにおいてＯＣの下の少なくとも一つの被制御要素の動作における変化を制御するように構成される。例えば、ＯＣは、ハードウェア機器（図２では不図示）または他のＯＣを制御するように構成される。ＥＣは、システム階層グラフにおいてＥＣの下の少なくとも一つの被制御要素の構成を制御するように構成される。例えば、ＥＣは、ハードウェア機器（図２では不図示）またはＥＣまたはＯＣである他のコントローラを制御するように構成される。
【0033】
図２における構成例では、自律ネットワーク２００が、ＥＣ２１０、２２０、２２２、２３０、２３２、２４０、２４２、２４４、および、ＯＣ２５０、２５２、２６０、２６２、２７２、２７２、２７４を備える。ＥＣによって実行される制御は、展開制御と表される。ＯＣによって実行される制御は、動作制御と表される。ハードウェア機器を直接的に制御するＯＣは、ローカルＯＣと表される。他のＯＣを制御するＯＣは、グローバルＯＣと表される。ローカルＯＣを制御するＥＣは、ローカルＥＣと表される。グローバルＯＣを制御するＥＣは、グローバルＥＣと表される。グローバルおよびローカルＥＣは、図２のシステム階層グラフの最高レベルにおけるマスタＥＣ２１０によって制御されるメタＥＣによって制御される。
【0034】
少なくとも一つの実施形態では、図２において例示されるシステム階層グラフが適応性を有し、ランタイムで定められるコントローラの階層構造を含む。前述のように、自律ネットワーク２００におけるコントローラは、同じ階層構造内に二つの異なるタイプのコントローラを含む。すなわち、一のタイプは展開を可能にするためのＥＣであり、他のタイプは動作タスクのためのＯＣである。
【0035】
ＥＣは、システム階層グラフにおいてＥＣの下のサブグラフにおいてコントローラを展開するタイミングおよび方法を決定するように構成される。各ＥＣは、対応するソフトウェアセクション（図１における１５０と同様）において、それ自身の従属関係を定めるように構成される。すなわち、各ＥＣは、ここで記述されるようなソフトウェアまたは直接的にその対応するコントローラ記述において、自身の直下の層またはサブグラフにおいて必要とするコントローラの種類（ＥＣまたはＯＣ）および数（ＯＣの数、ＥＣの数）を定める。少なくとも一つの実施形態では、これはＥＣのＡＰＩを介して現れる特別ＡＰＩ従属関係を介して実装される。この特別ＡＰＩ従属関係は、現在のＥＣの直下の層またはサブグラフ上にインスタンス生成されるべきコントローラのそれぞれのための仕様書または構成を返す。例えば、グローバルＥＣ２３０は、グローバルＯＣ２５０を展開するタイミングおよび方法を決定するように構成され、グローバルＥＣ２３０の直下の層またはサブグラフ上のグローバルＯＣ２５０のための仕様書を返す特別ＡＰＩ従属関係を有する。他の例として、メタＥＣ２２０は、グローバルＥＣ２３０およびローカルＥＣ２４０、２４２を展開するタイミングおよび方法を決定するように構成され、メタＥＣ２２０の直下の層またはサブグラフ上のグローバルＥＣ２３０およびローカルＥＣ２４０、２４２のそれぞれのための仕様書を返す一または複数の特別ＡＰＩ従属関係を有する。少なくとも一つの実施形態では、ＥＣが、その直属、すなわち、ＥＣ直下のサブグラフにおける一または複数のＥＣまたはＯＣの有用性関数に基づいて、自身の有用性関数を演算する方法を決定するために、ＥＣのＡＰＩにおける特別ＡＰＩ従属関係を介して現れる自由を有するように構成される。少なくとも一つの実施形態では、ＥＣが、自身の下方のサブグラフが変化すべきタイミング、すなわち、直属のコントローラを追加または削除すべきタイミングや、直属のコントローラを再構築または再構成するタイミングを決定するために、ＥＣのＡＰＩにおける更なる特別ＡＰＩ従属関係を介して現れる更なる自由を有するように構成される。少なくとも一つの実施形態では、ＥＣが、例えば、独立に展開されたＯＣをデータセンター毎、地域毎、グローバルに適用し、結果を比較し、ＥＣの有用性関数によって測定されるように、どのアプローチが最も効率的か判定するように構成される。
【0036】
一方、ＯＣは、ネットワーク要素（ハードウェア機器）および他のＯＣを制御するように構成される。ＯＣは、自律ネットワーク２００のシステム階層グラフまたは自律ネットワーク２００の展開プロセスに影響するように構成されない。ＯＣは、他のＯＣおよびＥＣの両方によって制御可能である。例えば、ローカルＯＣ２６２は、グローバルＯＣ２５０によって動作的に制御され、ローカルＥＣ２４２によって構成的に制御される。いくつかの実施形態では、ＥＣがＥＣの下のコントローラ（およびＥＣの下の階層ブランチ、サブグラフ）の構成を制御し、ＯＣが直属（下方）ＯＣおよび／または被制御要素（例えば、ハードウェア機器）の動作を指示する。
【0037】
図２における構成例では、自律ネットワーク２００が、トラフィックシェーピングおよびアンテナの傾きの最適化の両方を扱うように構成される。トラフィックシェーピングの場合、グローバルＯＣ２５０は場所毎に高レベルな重み付けを決定し、二つのローカルＯＣ２６０、２６２はグローバルな重みに従いながらトラフィックを整形する。これらのＯＣ２５０、２６０、２６２は、対応するローカルまたはグローバルＯＣ２３０、２４０、２４２によって独立に展開される。アンテナの傾きの場合、三つ全てのローカルＯＣ２７０、２７２、２７４が、一つのローカルＥＣ２４４によって展開され、グローバルＯＣ２５２によって動作的に制御される。グローバルＯＣ２５２は、グローバルＯＣ２３２によって展開されている。トラフィックシェーピングおよびアンテナの傾きの最適化のそれぞれの場合の全てのグローバルおよびローカルＥＣは、マスタＥＣ２１０によって展開される対応するメタＥＣ２２０、２２２を通じて展開される。
【0038】
少なくとも一つの実施形態では、ＯＣの階層を生成する目的は、速い反応を要求しうるローカルな決定を、より遅く実行されうるより慎重なグローバルな決定から分離することである。例えば、単一の基地局コントローラ（ローカルＯＣ）は、接続されたデバイスの数および条件に基づいて、そのアンテナの傾きを調整することを迅速に決定するように構成されるが、グローバルＯＣは多くのローカルＯＣからのフィードバックを得て、より大きな時間的粒度でのより全般的なポリシーの判断を提供する。より高いおよびより低いレベルのＯＣは、例えば、最適化問題を解決することを通じて、または、そうするようにＥＣによって展開されることを通じて、いくつかのユースケースを解決するために協働するように構成される。下位のコントローラ（またはハードウェア機器）を監督するため、または、共有されたコントローラを利用するために専用コントローラを使用するか否かは、具体的な用途、コントローラ構成、展開結果等の様々な設計ファクタによる。ここで記述される実施形態は、様々な設計ファクタに対応可能な十分な柔軟性を提供する。
【0039】
ＥＣの階層的序列は、しばしば最適化または適応戦略が依存する手元のタスクおよび動作環境に応じて、いくつかの実施形態が異なる展開アプローチを適用することを可能にする。例えば、入力データセンターのリソース配分のための最適化戦略は、地域的戦略（異なる時間スケール、アプリケーショングループ毎の重みに対する装置への明示的割当等）とは異なりうる。マスタＥＣの下位ＥＣへのマッピングは、同様のロジックに従う。
【0040】
いくつかの実施形態では、ここで記述されるモジュールおよび／またはセンサを記述するための一または複数の記述言語が、コントローラを記述するために使用可能である。記述言語は、機能的構成およびセンサデータからの意味の取得を可能にする。このような言語は、提供される機能的構築ブロック（例えば、モジュールおよび／またはコントローラ）およびセンサについて、システムがプログラム的に理解および理由付けすることを可能にする標準化層を提供する。加えて、少なくとも一つの実施形態では、記述言語が、コントローラおよび／またはコントローラ階層ブランチ（例えば、コントローラのサブグラフ）および／または対応する有用性関数についての制約を設定することで、一または複数の新しいまたは展開されるコントローラまたは階層（例えば、コントローラのサブグラフ）を追加することを可能にする。
【0041】
少なくとも一つの実施形態では、特定の用途または機能に関してどのコントローラが自律ネットワーク２００に存在すべきかをガイドする制約も、記述言語によって設定される。図１に関して記述されたように、各コントローラは、複数のコントローラコンポーネントまたは測定、分析、決定、アクションフェーズ等のフェーズを備える。コントローラコンポーネントまたはフェーズの間の接続は、各コントローラコンポーネントまたはフェーズの対応するソースおよびシンクモジュールを通じて提供される。
【0042】
モジュールと同様に、実施例における各コントローラも、各ＡＰＩ、ソフトウェア（コード）および一または複数の従属関係または要求を有する。要求は記述言語において記述され、ＡＰＩを介して現れる。ロードバランシングのためにＯＣおよびＥＣに適用されてＯＣおよびＥＣの各ＡＰＩを介して現れる、制約または要求を記述するための記述言語の一例は以下に与えられる。
【表2】
【0043】
上記のロードバランシングの例では、ＯＣがユニークなＩＤ「LoadBalancer」を有し、測定、分析、決定、アクションフェーズのそれぞれに対する複数の要求「ReqOutputs」を有する。測定フェーズに対する要求は、リンク統計「LinkStats」、装置リソース統計「MachineResourceStats」、クエリ統計「QueryStats」、ロードバランシングパフォーマンス統計 「LBPerfStats」を含む。分析フェーズに対する要求は、毎秒ネット負荷「NetLoadPerSecond」、毎秒装置負荷 「MachineLoadPerSecond」、毎秒クエリ「QPS」、クエリ成功率「QuerySuccessRatio」、毎秒クエリ遅延スコア「QueryLatencyScorePerSecond」を含む。決定フェーズに対する要求は、リンク重み「Link Weights」、装置重み「MachWeights」を含む。アクションフェーズに対する要求は、ドメインネームシステム（ＤＮＳ）重み割当「DNSWeightAssignments」、装置ジョブ割当「MachJobAssignments」を含む。ＯＣの有用性関数「Utility」は、「Product(QPS,QuerySuccessRatio,Query遅延Score)」、すなわち「QPS」「QuerySuccessRatio」「Query遅延Score」のプロダクトである。少なくとも一つの実施形態では、ＯＣが、その有用性関数を最適化するための最適化問題を解決するための認識ループを実行する。有用性関数の値が所定のターゲット範囲内の場合、ＯＣは、図６に関して記述されるようなコンテンツサーバおよび／またはＤＮＳ等の被制御要素に対する調整を施さない。一方、有用性関数の値が所定のターゲット範囲外の場合、ＯＣは、例えば、「DNSWeightAssignments」および「MachJobAssignments」の少なくともいずれかを変更することによって、有用性関数の値が所定のターゲット範囲内に収まるように被制御要素の動作を変化させる。
【0044】
更に上記のロードバランシングの例では、ＥＣが「LoadBalancerEvoCtlr」であり、タイプがいずれも「LoadBalancer」である二つの異なるロードバランシングＯＣ（下位のコントローラ）の展開を担う。ＥＣは、「LoadBalancer(2)」と表される特別ＡＰＩ従属関係または要求「ReqControllers」を有し、ＥＣの直下の層またはサブグラフにおける下位のコントローラのタイプ（すなわち「LoadBalancer」）、各コントローラタイプにおける下位のコントローラの数（すなわち「2」）を特定する。ＥＣは、測定、分析、決定、アクションフェーズのそれぞれに対する複数の要求「ReqOutputs」も有する。測定フェーズに対する要求は、下位のコントローラの統計「LoadBalancerStats(2)」、環境の特性が変化したか否かを示す環境の統計「EnvironmentStats」を含む。分析フェーズに対する要求は、二つの下位のコントローラの有用性関数「ControllerUtility(2)」、現在の温度が高いまたは低い等の環境的統計から抽出される情報を示す「Environment状況」を含む。決定フェーズに対する要求は、インスタンス生成されていない特定のコントローラを示す「ControllerPlans(2)」を含む。アクションフェーズに対する要求は、下位のコントローラの構成「LoadBalancer(0)」および「LoadBalancer(1)」、すなわち、それぞれ「ControllerComposition(LoadBalancer(0))」および「ControllerComposition(LoadBalancer(1))」を含む。ここで記述されるように、下位の各コントローラの構成は、モジュールの数およびタイプだけでなく、コントローラを構成するためにモジュールが相互接続される態様（例えば、コントローラグラフ）も含む。ＥＣの有用性関数「Utility」は、二つの下位のコントローラの有用性関数の平均であり、「Avg(ControllerUtility(2))」と表される。少なくとも一つの実施形態では、ＥＣが、その有用性関数を最適化するための最適化問題を解決するための認識ループを実行する。有用性関数の値が所定のターゲット範囲内の場合、ＥＣは、下位のコントローラ、すなわち、ＯＣ「LoadBalancer」に対する調整を施さない。一方、ＥＣの有用性関数の値が所定のターゲット範囲外の場合、ＥＣは、ＥＣの有用性関数の値が所定のターゲット範囲内に収まるように、構成、すなわち下位のコントローラの少なくともいずれかの仕様書または構成を変化させる。少なくとも一つの実施形態では、ＥＣが、展開されるまたは新しいコントローラを生成するためにその有用性関数の最適化を図る。
【0045】
上記の例では、各コントローラについて、要求される出力が明示的に指定されたが、要求される入力は、必要とされる出力を提供する構成の要求から直接的に取得される。少なくとも一つの実施形態では、これらの入力要求が、先のフェーズに対する追加的な出力要求にも繋がる。更に、全ての下位のコントローラを評価するために使用されるＥＣの有用性関数が、上記の例ではＥＣ仕様書内で直接的に定められていたが、少なくとも一つの実施形態では、ＥＣの有用性関数がＥＣのソフトウェアにおいて定められてもよい。
【0046】
少なくとも一つの実施形態では、自律ネットワーク２００の利点は、被制御ネットワークエンティティの動作を適応させる能力だけでなく、それ自身を展開する能力も含む。具体的には、図１に関して記述されたように、自律ネットワーク２００におけるコントローラは、既にコントローラグラフ内にある一のノード（モジュールインスタンス）の従属関係を提供する一の構成可能および置換可能なモジュールの新規または既存のインスタンスを選択し、選択された新規または既存のインスタンスを従属関係「スロット」中に「プラグ」（挿入または追加）することによって、利用可能な構成可能および置換可能なモジュールから構成される。このプロセスは、コントローラにおける全てのモジュールの全ての従属関係が満たされるまで続く。少なくとも一つの実施形態では、このコントローラグラフにおける最終要求「層」が、以前のコントローラコンポーネントのシンクモジュールの鏡像と解釈され、すなわち、認識ループにおける以前のコントローラコンポーネントが利用可能にした全てのデータを提供するソースモジュールによって提供される。
【0047】
図３は、いくつかの実施形態に係るコントローラ展開において展開されているコントローラの部分のいくつかの模式的なブロック図を含む。展開されているコントローラは、自律ネットワーク２００におけるＥＣまたはＯＣである。このコントローラ展開を実行するコントローラは、展開されているコントローラを制御するＥＣである。例えば、展開されているコントローラはＯＣ２６０であり、このコントローラ展開を実行するコントローラはＥＣ２４０である。
【0048】
図３では、全ての潜在的に有効なコントローラの組、つまり候補モジュール３０３～３１１等のモジュールインスタンスの全ての有効な構成、およびそれらの構成が、ＯＣ２６０のコントローラ展開プロセスにおいてＥＣ２４０によって探索される探索空間３００を定める。全ての有効な構成の探索空間またはドメイン３００は、図３におけるソースモジュール３０１からシンクモジュール３０２までの全ての利用可能なモジュールを通じた全ての可能な経路（コントローラグラフ）によって表される。ＥＣ２４０は、コントローラをインスタンス生成するために、探索ドメイン３００内の一または複数のまたは任意の可能なソリューションを特定および利用するように構成される。結果として、二つの有効なコントローラ構成３２０および３３０が得られる。有効なコントローラ構成３２０および３３０は、相互接続されたモジュールおよび／またはモジュールが相互接続されるコントローラグラフの構成において異なる。なお、有効なコントローラ構成３２０は、前述のような対応する従属関係に基づく、モジュール「LowPassFilter」および「HighPassFilter」の間の接続を含む。二つの特定された有効なコントローラ構成３２０、３３０は、図４に関して記述されるように、続くオンライン試行の対象となるものとして示される。
【0049】
少なくとも一つの実施形態では、有効なコントローラ構成３２０および３３０が、既存のＯＣ２６０の同じ有用性関数に基づいて特定される。結果として、有効なコントローラ構成３２０および３３０が、ＯＣ２６０の展開されるコントローラの候補となる。更なる実施形態では、有効なコントローラ構成３２０および３３０が、既存のＯＣ２６０の有用性関数とは異なる有用性関数に基づいて特定される。結果として、異なる有用性関数がパフォーマンスまたは動作の最適化のための異なるターゲット（または目的）を示すため、有効なコントローラ構成３２０および３３０が新しいコントローラの候補となる。例えば、ＯＣ２６０の現在の有用性関数がロードバランシングを最適化することを目的としている一方で、異なる有用性関数はコストを最適化することを目的としており、異なる新しいコントローラをもたらす。簡潔性のため、「展開されるコントローラ」および「新しいコントローラ」は、特に断らない限り同義のものとして使用される。
【0050】
少なくとも一つの実施形態では、ＥＣ２４０がＥＣ２４０の同じ有用性関数を使用することによって、ＯＣ２６０の稼働中のパフォーマンス、および、特定された有効なコントローラ構成３２０、３３０のオンライン試行中のパフォーマンスを評価するように構成される。ＥＣ２４０による評価に基づいて、一または複数の特定された有効なコントローラ構成３２０、３３０がＯＣ２６０より良いパフォーマンス（例えば、ＥＣ２４０の有用性関数のより高い値）を提供すると分かった場合、特定された有効なコントローラ構成３２０または３３０のうちパフォーマンスが良い方が、他のＥＣまたは他の自律ネットワークが使用できる、および／または、ＯＣ２６０の代わりにＥＣ２４０によって使用できるように、コントローラリポジトリに新しいコントローラとして含まれる。
【0051】
少なくとも一つの実施形態では、ＥＣ２４０自身が、メタＥＣ２２０等の他のＥＣによって制御または評価される。例えば、メタＥＣ２２０は、自身の有用性関数を使用して、ＥＣ２４０がどれだけ速くおよび／または正確に探索空間３００を探索し、３２０および３３０等の有効なコントローラ構成を特定できるかを評価する。図３における構成例では、全ての可能な経路（コントローラグラフ）および全ての利用可能なモジュールの数が、説明目的のために限定されている。実世界のオペレーションにおけるいくつかの実施形態では、探索空間３００が大きく、百、千、それ以上の可能な経路および利用可能なモジュールを含む。ＥＣ２４０は、探索アルゴリズムを使用し、このように大きな探索空間３００を探索して有効なコントローラ構成を特定するように構成される。探索アルゴリズムは、例えば、ＥＣ２４０を構成する構成可能および置換可能なモジュールのうち一つのモジュールに含まれる。探索空間３００を探索するためにＥＣ２４０によって使用される探索アルゴリズムの探索時間および／または正確性が許容できないとメタＥＣ２２０が自身の有用性関数を通じて判定した場合、メタＥＣ２２０は、例えば、現在の探索アルゴリズムを含むモジュールを他の探索アルゴリズムを含む他のモジュールに変更することによって、ＥＣ２４０の構成を変更し、例えば、ここで記述されるようなオンライン試行を通じて、展開されるＥＣのパフォーマンスを再評価するように構成される。少なくとも一つの実施形態では、探索空間３００の大きいサイズのために、ＥＣ２４０が探索空間３００を探索するスピードと、ＥＣ２４０が見つけた探索空間３００における点（例えば、有効なコントローラ構成）の正確性の間にトレードオフがある。メタＥＣ２２０は、最適なソリューション、すなわち、探索空間３００を探索するＥＣ２４０が許容できる探索時間および正確性の両方を実現できるＥＣ２４０の最適な構成に到達するための最適化問題を解決するように構成される。他のより高いレベルのＥＣによる記述されたＥＣの制御または展開は例である。他の構成も、様々な実施形態の範囲内である。
【0052】
図３に関して記述されたコントローラ展開に加えて、いくつかの実施形態に係る自律ネットワーク２００の他の側面として階層展開が挙げられる。モジュールおよびモジュールがコントローラ中に相互接続されるコントローラグラフの構成の変更を伴うコントローラ展開に対して、階層展開は、コントローラおよびコントローラが展開された自律ネットワーク中に相互接続されるシステム階層グラフの構成の変更を伴う。
【0053】
少なくとも一つの実施形態では、各ＥＣが、システム階層グラフにおいてＥＣの下方のコントローラのサブグラフがランタイムで構成される態様を定めるように構成される。従って、システム階層グラフにおけるコントローラの構成は、反復的なプロセスである。システム階層グラフのルート、すなわちマスタＥＣ２１０は、最初にインスタンス生成され、その下方のサブグラフの構成に関する意図について尋ねられる。そして、マスタＥＣ下のサブグラフのための対応するコントローラインスタンスが、マスタＥＣの要求に応じてインスタンス生成される。同じプロセスが全ての下位ＥＣについて反復的に続けられる。前述のように、ＯＣはランタイムで従属関係を選ぶ自由を持たず、代わりに、少なくとも一つの実施形態では、ＯＣの従属関係グラフが管理者によって定められた仕様書を介して取得される。
【0054】
認識ループ制御の結果としてＥＣが管理するサブグラフの構成を変更すると決定した場合、前述の構成方法が当該サブグラフのみに適用される。
【0055】
全ての潜在的に有効なシステム階層グラフまたはサブグラフの組は、対応するＥＣによって展開プロセスにおいて探索される探索空間を構成する。いくつかの状況では、全ての有効なグラフがインスタンス生成を通じて探索される場合の過剰なオーバーヘッドのために、反復的な探索プロセスがいくつかの実施形態に応じて使用される。少なくとも一つの実施形態では、階層を決定するためだけの各コントローラの完全なインスタンス生成は不要であり、代わりに、必要なＡＰＩおよび従属関係を提供するモジュールのみがインスタンス生成される。
【0056】
図４は、いくつかの実施形態に係るコントローラ展開のためのオンライン試行における自律ネットワーク４００の部分の模式的なブロック図である。
【0057】
自律ネットワーク４００は自律ネットワーク２００に対応するが、試行管理部４２０が追加されている。試行管理部４２０は、例えば、図１０におけるコンピュータハードウェア構成に関して記述されるように、少なくとも一つのメモリ（図４では不図示）と、少なくとも一つのメモリに接続される少なくとも一つのプロセッサ（図４では不図示）を備える。いくつかの実施形態では、試行管理部４２０は、自律ネットワーク４００のコントローラから独立したプロセスである。
【0058】
図４における状況では、コントローラ１００が、ＯＣ４１０を展開するように構成されるＥＣである。図２に関して記述されたように、ＯＣ４１０を展開するための一または複数の構成可能および置換可能なモジュールは、モジュールリポジトリ４０９から取得される。いくつかの実施形態では、モジュールリポジトリ４０９が、コントローラ１００の少なくとも一つのメモリに格納されている。一または複数の実施形態では、モジュールリポジトリ４０９が、自律ネットワーク４００の一または複数の他のコントローラによってアクセス可能な共有ストレージデバイス上に格納されている。ＯＣ４１０の展開に好適な一または複数の構成可能および置換可能な候補モジュールは、コントローラ１００によってモジュールリポジトリ４０９から読み出される。図３はソースモジュールからシンクモジュールまでの完全なコントローラグラフが展開されるコントローラ展開例を記述したが、一または複数の実施形態ではＯＣ４１０のコントローラグラフのサブグラフ等のセクションのみを展開することも可能である。少なくとも一つの実施形態では、コントローラ展開が、ＯＣ４１０の展開されるサブグラフにおける既存のモジュールを、同じモジュールの異なるインスタンス、または、異なる構成可能および置換可能なモジュールによって置換すること、および／または、ＯＣ４１０のサブグラフまたはコントローラグラフを変更すること、を伴う。コントローラ１００は、モジュールリポジトリ４０９から取得された候補モジュールを使用して、展開されるコントローラグラフまたはサブグラフのための全ての可能な経路を構築し、図３に関して記述されたように、一または複数の有効な構成を対応する一または複数の展開されるコントローラとして示す。
【0059】
展開されるコントローラは、続いて評価のためのオンライン試行のために試行管理部４２０に送られる。このオンライン試行の理由は、コントローラをプログラム的に展開する能力によって、いくつかの実施形態では、多数の新しいまたは展開されるコントローラを自動的に生成できるためである。これらの新しいまたは展開されるコントローラの制御のいくつかのドメインに適用される上での有用性または適合性を理解するために、オンライン試行が実行される。
【0060】
少なくとも一つの実施形態では、試行管理部４２０が、試行への多層アプローチにおけるオンラインでの試行錯誤試行としてのオンライン試行を実行するように構成される。最初に、新しいまたは展開されるコントローラは、論理的誤りを含まないことを担保するためのサニティチェック４２１を受ける。例えば、存在しない光センサモジュールを使おうとする新しいまたは展開されるコントローラは、論理的誤りを含む。少なくとも一つの実施形態では、分類学および存在論の使用が、このサニティチェック４２１を支援する。
【0061】
次に、新しいまたは展開されるコントローラは、例えばここで記述されるように、最初に有用性関数を使用してそれらの有用性を評価するためのシミュレーション４２２においてテストされる。いくつかのシミュレーションツールが、潜在的な成功または即座の失敗の指標として使用可能である。この情報に基づいて、試行管理部４２０は、最終的に、新しいまたは展開されるコントローラが徐々に実通信ネットワーク等の実生産ネットワーク内でテストされる次のステージに進むか否かを判定するように構成される。ネットワークトライアルについて、試行管理部４２０は、テストされる新しいまたは展開されるコントローラの（物理的および時間的）範囲を制限するように構成され、新しいまたは展開されるコントローラの測定された（または評価された）有用性関数に基づいて徐々に拡張する。
【0062】
新しいまたは展開されるコントローラの試行的なトライアルを監督しながら、試行管理部４２０は同時進行中の異なる試行を協調させるように構成されてもよい。これは、新たに展開されるコントローラのオンライン試行を要求する複数のＥＣまたはマスタＥＣが存在する状況における考慮事項である。直感的には、試行同士が干渉する場合のコンフリクトおよび偽の有用性のリスクのために、全てのオンライン試行を同時に実行することは不可能に思われる。加えて、不安定性、高ゲイン動作における干渉、テストの優先度等のリスクもある。通信ネットワークは巨大な相互接続されたシステムであるため、干渉は不可避である。しかし、試行管理部４２０は、例えば、スケジューラ４２３、リソースアロケータ４２５、および／または、試行独立性担保部４２４として機能する、または、を含むことによって、これを制限するように構成される。
【0063】
いくつかの実施形態では、異なるコントローラのパフォーマンスの公平な比較が、それらのいずれかに不公平な利点を与えない状況においてコントローラが評価されることに依存するため、試行独立性担保部４２４は試行が互いに独立に実行されることを担保する。少なくとも一つの実施形態では、試行独立性担保部４２４は、試行が意味を有し実際の動作環境を表すことを担保する。例えば、試行では、伝送制御プロトコル（TCP）上で実行されるメッセージングプロトコルが、スループット、遅延および信頼性に基づく有用性メトリック（有用性関数）によって、ユーザデータグラムプロトコル（UDP）を利用する他のプロトコルに対して評価される。この試行がパケット損失または並び替えのない信頼できるトランスポート上で実行される限り、ＵＤＰは小さいオーバーヘッド（三方向ハンドシェイクがなく、ヘッダサイズも小さい）のために不公平な利点を有する。しかし、環境における変化または他の同時進行中の試行のトランスポート層への影響によって一旦トランスポートが信頼できなくなると、入力パケットの再送信および要求を担保するＴＣＰの能力が自身を有利なポジションに置く可能性がある。試行独立性担保部４２４は、一のコントローラに関する試行セットアップが、他のコントローラのための他の試行セットアップに影響を及ぼさないことを保証するように構成される。
【0064】
オンライン試行では、テスト中の新しいまたは展開されるコントローラ、そのパラメータ構成、有用性関数、現在の試行範囲、結果が収集され、これらの情報の一または複数は試行管理部４２０の試行リポジトリ４２６に後の参照および／または学習のために保存される。結果は、要求するＥＣの試行管理部４２０、すなわち、コントローラ１００のいずれかによって、試行中の新しいまたは展開されるコントローラが既存コントローラ４１０を置換すべきか否かを判定するために使用される。提供された情報に基づいて、コントローラ１００および／または試行管理部４２０は、試行における潜在的なコンフリクトを推測できる。
【0065】
【0066】
動作５０５では、図２に関して記述されたように、ＯＣが自律ネットワークのシステム階層グラフにおける下方のハードウェア機器または他のＯＣを制御する。
【0067】
動作５２５では、図３に関して記述されたように、ＥＣがシステム階層グラフにおける下方の既存コントローラを制御および展開する。例えば、動作５３０では、例えば、図３におけるモジュール３０３－３１１に関して記述されたように、構成可能および置換可能な候補モジュールの数が特定される。動作５３５では、図３におけるコントローラ構成３２０、３３０に関して記述されたように、コントローラグラフのセクションを完了するために様々な候補モジュールが相互接続される複数の異なる構成が特定される。動作５４０では、図４に関して記述されたように、動作５３５で取得された候補モジュールの構成が展開されるコントローラとして出力される。
【0068】
動作５４５では、図４に関して記述されたように、展開されるコントローラが、既存コントローラが複数の展開されるコントローラのいずれかによって置換可能か否かを判定するためのオンライン試行の対象となる。例えば、オンライン試行は、動作５５０でのサニティチェック、動作５５５でのシミュレーション、動作５６０でのネットワークトライアルを含む。少なくとも一つの実施形態では、これらのサニティチェック、シミュレーションまたはネットワークトライアルのいずれかが失敗した場合、展開されるコントローラは既存コントローラを置換するには不適切と判定される。展開されるコントローラが既存コントローラを置換するのに適切とオンライン試行によって示された場合、コントローラ展開を実行するＥＣは、この置換を実施する、および／または、展開されるコントローラを自律ネットワークにおける他のＥＣにとって利用可能にするように構成される。
【0069】
いくつかの実施形態に係る自律ネットワークの例を、ＣＤＮの文脈において記述する。コンテンツデリバリネットワーク（CDN）は、地理的にコンテンツを配信し、遅延、スループット、利用可能性、強靱性を改善するためのサービスを顧客およびエンドユーザに提供する。かつてはキャッシングを通じたダウンロードおよびストリーミングのパフォーマンスの向上に注力していたＣＤＮは、今日では多くの追加的なサービス（モバイルコンテンツ高速化、コンテンツトランスコーディング、分散型サービス拒否（DDoS）攻撃防御、ウェブアプリケーションファイアウォール等）を提供する。演算機能の増強を通じて、ＣＤＮはモバイルエッジ演算プロバイダに変容しつつある。ＣＤＮは、その性質上、失敗の場合における高い利用可能性（強靱性）を担保し、需要のスパイクに対処するために過剰なサービスを提供しなければならない。いくつかの状況では、複数の場所においてコンテンツを単純に提供するだけでは、異なる場所の間で負荷が均等または最適に分散されることが必ずしも担保されない。ＣＤＮによるパフォーマンスを最適化するためのいくつかの考慮事項は、トラフィックロードバランシング、コンピュータロードバランシング、コンテンツプレースメントを含む。これらの側面のそれぞれは、一または複数の実施形態に係る自律ネットワークによって改善可能である。
【0070】
図６は、いくつかの実施形態に係るＣＤＮのための自律ネットワークのトラフィックロードバランシングセクション６００の模式的なブロック図である。
【0071】
クライアントは歴史的に、目的ＩＰアドレスをホストする一つのサーバにルーティングするトランスポート層によってコンテンツおよびサービスにアクセスしていた。同じコンテンツが複数の場所で提供される場合、このアプローチはもはや十分ではない。ユーザ需要は変動し、いくつかの場合には常軌を逸することもあるため、静的な割当は本質的に最適ではない。この問題に対処するため、いくつかの実施形態は、各ＩＰ範囲から各提供場所までのおおよその遅延が既知であり、各ＰｏＰ（Point of Presence）がそれ自身のＩＰ範囲に割り当てられる動的なＤＮＳに基づくアプローチを提供する。
【0072】
図６における構成例では、自律ネットワークのトラフィックロードバランシングセクション６００が、ＰｏＰ６２０、６３０、６４０（例えば、各エリア１－３についてのコンテンツサーバ）のそれぞれについての重みを配信し、分散型エニーキャストＤＮＳサーバ６５０にサービス（A-D）を提供するように構成される、コントローラ６１０の形態でのグローバルＯＣ（「グローバルＯＣ６１０」とも表される）を備える。コントローラ６１０は、コントローラ１００に対応する構成を備える。ＤＮＳサーバ６５０は、コントローラ６１０の制御下の被制御要素またはハードウェア機器に対応する。ＰｏＰ６２０、６３０、６４０のそれぞれについての重みは、アップデート６６０を介してＤＮＳサーバ６５０に配信される。続いてＤＮＳサーバ６５０は、テレメトリ６７０を介して、前回のサイクル中にＤＮＳサーバ６５０が送信した各（サービス、ＰｏＰ）対に対するレスポンスの数を報告する。同様に、ＰｏＰ６２０、６３０、６４０は、テレメトリ６８０を介して、イングレス（ingress）およびエグレス（egress）リンク負荷や、サービス利用率およびキャパシティを、コントローラ６１０に報告する。更に、コントローラ６１０は、各サービスＡ－Ｄの重要性または有用性等の優先度、その遅延および帯域幅要求に関する情報を有する。クライアント６０１は、コンテンツ（サービスＡ－Ｄの少なくともいずれか）についての問合せを、リンク６０５を介してＤＮＳサーバ６５０に送る。クライアントによって要求されるサービスおよびコントローラ６１０によって提供されるＰｏＰ６２０、６３０、６４０のそれぞれについての重みに基づいて、ＤＮＳサーバ６５０はクライアント６０１を一または複数の適切なＰｏＰ６２０、６３０、６４０にリダイレクトする。ＤＮＳサーバ６５０によってリダイレクトされたクライアント６０１は、要求されたサービスを受けるために、一または複数の各リンク６０２、６０３、６０４を介して、一または複数のＰｏＰ６２０、６３０、６４０にアクセスする。
【0073】
グローバルＯＣ６１０が満たすように構成される要求の例が、テーブル１（表３）に詳細に記載されている。これらの要求に基づいて、モジュールがテーブル２（表４）において指定され、ここからグローバルＯＣ６１０が構成される。テーブル２における各モジュールについて、その能力およびインターフェースの仕様書言語における対応する記述が提供される。グローバルＯＣ６１０の測定フェーズに対するモジュール構成の組の例が図７Ａに示される。挙げられているモジュールの全てがトラフィックロードバランシングのタスクにユニークに関連付けられる訳ではない。センシングモジュールのそれぞれも、ＣＤＮヘルスモニタリングコントローラにとって使用可能である。このように、モジュール再利用は少なくとも一つの実施形態における利点である。
【0074】
テーブル１：グローバルＯＣ６１０のコントローラコンポーネント（フェーズ）の要求（出力）の例
【表3】
【0075】
テーブル２：コントローラコンポーネント（フェーズ）毎のモジュールの例
【表4】
【0076】
この情報を使用して、トラフィックロードバランシングセクション６００は、ＣＤＮトラフィックロードバランシングタスクのためのコントローラを生成および展開するための基本的な入力を得る。分析および測定コンポーネントを使用することによって、コントローラ６１０は自身のアクション（すなわち、重み付け）が、現在の環境的な状況においてサービスオペレーションにどのように影響するかを理解できる。そして、コントローラ６１０の決定コンポーネントは、コントローラ６１０のアクションコンポーネントによってＤＮＳサーバ６５０に伝えられる重みをどのように変更するかを決定できる。
【0077】
有用性関数は、全体の重み付けがネットワークの現在の条件にどれだけ良く合致したかを理解できる手段を提供する。以下は有用性関数の例である。
ここで、Ｒは全ての要求の集合であり、ｌ（ｒ）は要求ｒについて測定された遅延であり、ｔ（Ｒ）は測定されたスループットであり、ｓ（ｒ）は要求が向けられたサービスであり、ｕはサービス値、測定された遅延、測定されたスループットに基づく各要求の有用性を演算する管理者によって定められた関数である。簡潔性のため、各要求に対処するコストは、利用される帯域幅および場所に関わらず同一であるものとする。動作コントローラの目標は、有用性関数を全般的に最大化することである。
【数1】
【0078】
グローバルＯＣ６１０を設計および再設計（展開）するために、ＥＣが提供される。ＥＣは、グローバルＯＣ６１０がトラフィックのロードバランシングを効率化するという目標を実現することを担保するように構成されるだけでなく、既存のグローバルＯＣ６１０より性能が高い可能性がある利用可能なモジュールに基づいて新しい／展開されるＯＣを見つける。ネットワークからの現在および過去のデータ、環境の分類、グローバルＯＣ６１０の現在のブループリント、グローバルＯＣ６１０の有用性の定義が、ＥＣによって使用される。履歴データが示唆するように、この例においてＥＣは期間に亘って決定を下す。ＥＣモジュール例のリストはテーブル３（表５）に示される。このリストは網羅的なものではない。
【0079】
テーブル３：トラフィックロードバランシングのためのＥＣのモジュール
【表5】
【0080】
グローバルＯＣ６１０が状況を与えるというタスクを十分に効果的に遂行できないと測定または評価された有用性関数によって判定された場合、ＥＣはそれを他の既存または新規のＯＣで置換することを決定するように構成される。状況が変わって異なるコントローラが新しい条件の下で現在のコントローラより優れた性能を発揮した場合、ＥＣは再びＯＣを置換するように構成される。十分な性能を発揮するＯＣが見つからない場合、ＥＣは新しいコントローラ構成を生成するように構成される。
【0081】
続いて、新たに展開されるコントローラが実際に現在の条件の下で、トラフィックのロードバランシングにおいて他の既存コントローラより良い仕事を行うかどうかを確認するための試行錯誤試行が実行される。「より良い」は、現在のコントローラと同じ有用性関数を使用して測定された場合に、より高い有用性関数の値を提供することと定義される。第１に、新しいコントローラが完全であることを担保するためのサニティチェックが実行された。サニティチェックは、コントローラが要求しうる全てのアクションがロードバランシングのドメインに制限され、アクションが他のドメインにおいて取られていないことを担保するためのものである。他のチェックは、新しいコントローラがいわゆるデッドロック状態に陥ることなく進行することを担保するためのものである。第２に、シミュレーションを通じて、新しいコントローラが想定通りに動作することが検証される。例えば、新しいコントローラがサンドボックス環境においてインスタンス生成されて、記録されたセンサデータが提供されると、新しい重みが適用される期間についての要求ログを使用して、新しいコントローラが生成する重みの変更が実際のロードバランシングにどのように影響するかが評価され、これらの変更の有用性関数の値が演算される。更に、一の場所から他の場所に大量のトラフィックを動かしうる突発的な変化およびアサイメントにおける変動が低頻度または不存在であることが検証される。第３に、新しいコントローラがネットワークにおいて徐々に展開される（低インパクト領域または比較的重要性が低いサービスから期間限定で開始する）。パフォーマンスが低い場合、割り当てられたトライアル期間が終わる前に、トライアル前の状態に戻される。そうでない場合、より重要な領域およびサービスについてトライアルが延長される。以上のステージは、ＥＣおよび／または試行管理部によって完全に自動化される。
【0082】
図７Ａ－７Ｄは、いくつかの実施形態に係る測定コンポーネントの第１～第４の構成７１０Ａ－７１０Ｄの模式的なブロック図である。少なくとも一つの実施形態では、測定コンポーネントが、図６に関して記述されたコントローラ６１０の測定コンポーネントに対応する。
【0083】
図７Ａでは、測定コンポーネントの第１の構成７１０Ａが、テーブル２において列挙された測定フェーズについてのモジュールに対応する四つのソースモジュール７１１、７１２、７１３、７１４と、集約モジュール７１５と、シンクモジュールすなわちレポートモジュール７１６を含む。ソースモジュール７１１、７１２、７１３、７１４は、図６におけるテレメトリ６７０、６８０等の様々なソースから測定データを受け取るように構成される。集約モジュール７１５は、様々な測定データをレポートモジュール７１６のために集約するように構成される。シンクモジュールであるレポートモジュール７１６は、集約された測定データを分析コンポーネント７２０に提供するために、次のフェーズすなわち分析コンポーネント７２０のソースモジュール７２１に接続される。レポートモジュール７１６は、更に知識ベース１９０とデータを交換するように構成される。
【0084】
図７Ｂ－７Ｄは、第１の構成７１０Ａに基づいてＥＣによって生成される、展開されるまたは新しいコントローラにおける測定コンポーネントの第２～第４の構成７１０Ｂ－７１０Ｄを示す。簡潔性のために、分析コンポーネント７２０および知識ベース１９０は、図７Ｂ－７Ｄにおいて示されていない。
【0085】
図７Ｂにおける測定コンポーネントの第２の構成７１０Ｂは、図７Ａと同じモジュールを含むが相互接続態様が異なる。具体的には、二つのソースモジュール７１１、７１２は集約モジュール７１５に接続されているが、他の二つのソースモジュール７１３、７１４はレポートモジュール７１６に直接的に接続される。
【0086】
図７Ｃにおける測定コンポーネントの第３の構成７１０Ｃは、集約モジュール７１５を除く図７Ａのほとんどのモジュールを含む。集約モジュール７１５がないため、全てのソースモジュール７１１、７１２、７１３、７１４はレポートモジュール７１６に直接的に接続される。
【0087】
図７Ｄにおける測定コンポーネントの第４の構成７１０Ｄは、二つのソースモジュール７１１、７１４が省略される点を除いて、図７Ｂにおける第２の構成７１０Ｂと同様である。構成７１０Ａ－７１０Ｄは例であり、他の構成も様々な実施形態の範囲内である。少なくとも一つの実施形態では、例えば、測定コンポーネントを有するコントローラの展開または制御を担うＥＣの決定フェーズに応じて、測定コンポーネントが構成７１０Ａ－７１０Ｄのうちの一の構成から他の構成に展開される。
【0088】
いくつかの実施形態では、認識ループの概念が、複数の独立に設計された制御および最適化タスク間の相互作用および協働を可能にする。コントローラ階層は、これらのタスクが、より高いレベルの認識ループがそれらの直属を監督、制御および展開する総合的な態様で統合されることを可能にする。適切な認識、学習および最適化の戦略の少なくともいずれかによって、展開は実現される。このオンライン展開は、機能的構成および試行的評価によって可能になる。機能的構成は、いくつかの実施形態が、小さい機能的構成ブロック（モジュール）を使用して、それ自身で新規およびユニークなコントローラを構成することを可能にする。これらのコントローラは、ネットワークインフラストラクチャの動作を制御および改善することに限らず、制御システム自体のアーキテクチャおよび機能もランタイムで変更および改善する。更に、いくつかの実施形態では、利用可能になった新しい技術および研究成果をシームレスに取り込むことが可能になる。試行的展開は、いくつかの実施形態が、これらの自律的に展開されるコントローラの実際のパフォーマンスを実際のネットワーク内でテストおよび検証することを可能にする。これらの技術の一または複数あるいは全ての組合せによって、いくつかの実施形態は真に自律型の制御および最適化を発生的な態様で実現できる。
【0089】
図８は、いくつかの実施形態に係るコンピュータハードウェア８００の例のブロック図である。コンピュータハードウェア８００は、ここで記述されるコントローラおよび／または試行管理部の少なくともいずれかとして動作するように構成可能である。コンピュータハードウェア８００は、少なくとも一つのハードウェアプロセッサ８０２、少なくとも一つの非一時的でコンピュータ読取可能なストレージ媒体またはメモリ８０４を備える。少なくとも一つの実施形態では、コンピュータハードウェア８００は、バス８０８、入力／出力（I/O）インターフェース８１０、ネットワークインターフェース回路８１２の少なくともいずれかを更に備える。
【0090】
プロセッサ８０２は、記述されるプロセスおよび／または方法の一部または全部をコンピュータハードウェア８００に実行させるために、ストレージ媒体８０４における構成可能および置換可能なモジュール等のコンピュータプログラムコードを実行するように構成される。一または複数の実施形態では、プロセッサ８０２は、中央処理ユニット（CPU）、マルチプロセッサ、分散処理システム、特定用途向け集積回路（ASIC）、および／または、適切な処理ユニットを備える。
【0091】
ストレージ媒体８０４は、他のものと併せて、プロセッサ８０２によって実行されるコンピュータプログラムコード、すなわち、構成可能および置換可能なモジュール８０６でエンコードされる（すなわちそれを格納する）。一または複数の実施形態では、ストレージ媒体８０４が、電子型、磁気型、光学型、電磁気型、赤外線型、および／または、半導体型のシステム（または装置やデバイス）を備える。例えば、ストレージ媒体８０４は、半導体または固体状態メモリ、磁気テープ、フロッピーディスク、ランダムアクセスメモリ（RAM）、リードオンリーメモリ（ROM）、硬性磁気ディスク、および／または、光学ディスクを含む。光学ディスクを使用する一または複数の実施形態では、ストレージ媒体８０４が、ＣＤリードオンリーメモリ（CD-ROM）、ＣＤリード／ライト（CD-R/W）、および／または、デジタルビデオディスク（DVD）を含む。
【0092】
Ｉ／Ｏインターフェース８１０は、ユーザおよび／または外部回路／機器がコンピュータハードウェア８００と相互作用することを可能にするための、入力デバイス、出力デバイスおよび／または組み合わされた入力／出力デバイスを含む。入力デバイスは、情報およびコマンドをプロセッサ８０２に通信するために、例えば、キーボード、キーパッド、マウス、トラックボール、トラックパッド、タッチスクリーン、および／または、カーソルキーを備える。出力デバイスは、ユーザに情報を伝達するために、例えば、ディスプレイ、プリンタ、音声シンセサイザ等を備える。
【0093】
ネットワークインターフェース回路８１２は、プロセッサ８０２およびストレージ媒体８０４がネットワーク８１０を介して他の機器に接続できるように、ネットワーク８１４に接続される。ネットワークインターフェース回路８０４は、BLUETOOTH、WIFI、WIMAX等の無線ネットワークインターフェース、ETHERNET、USB、IEEE-1364等の有線ネットワークインターフェースを含む。
【0094】
いくつかの実施形態では、記述されるプロセスおよび／または方法の一部または全部が、プロセッサによる実行のためのスタンドアロンソフトウェアアプリケーションとして実装される。いくつかの実施形態では、記述されるプロセスおよび／または方法の一部または全部が、追加的なソフトウェアアプリケーションの一部であるソフトウェアアプリケーションとして実装される。いくつかの実施形態では、記述されるプロセスおよび／または方法の一部または全部が、ソフトウェアアプリケーションへのプラグインとして実装される。
【0095】
記述される方法およびアルゴリズムは動作例を含むが、必ずしも示された順序で実行されることが要求される訳ではない。開示の実施形態の精神および範囲に従って、動作は追加されてもよいし、置換されてもよいし、順番が変えられてもよいし、および／または、適切な場合には削除されてもよい。異なる特徴および／または異なる実施形態を組み合わせる実施形態は開示の範囲内であり、本開示に接した後の当業者にとって自明である。
【0096】
いくつかの実施形態では、自律ネットワークのためのコントローラが、複数の構成可能および置換可能なモジュールを含む少なくとも一つのメモリと、少なくとも一つのメモリに接続され、コントローラコンポーネントを構成するために相互接続された態様で複数のモジュールを実行するように構成される少なくとも一つのプロセッサと、を備える。コントローラコンポーネントは、コントローラの制御下の少なくとも一つの被制御要素に関する測定データを収集するように構成される測定コンポーネントと、少なくとも一つの被制御要素の現状を取得するために収集された測定データを処理するように構成される分析コンポーネントと、取得された現状に基づいて、少なくとも一つの被制御要素に関して取るべきアクションを決定するように構成される決定コンポーネントと、
少なくとも一つの被制御要素の動作、および、少なくとも一つの被制御要素の構成、の少なくともいずれかにおける変化をもたらすことによって、少なくとも一つの被制御要素に関して決定されたアクションを実行するように構成されるアクションコンポーネントと、を備える。
少なくとも一つの被制御要素の動作、および、少なくとも一つの被制御要素の構成、の少なくともいずれかにおける変化をもたらすことによって、少なくとも一つの被制御要素に関して決定されたアクションを実行するように構成されるアクションコンポーネントと、を備える。
【0097】
いくつかの実施形態では、自律ネットワークが、システム階層グラフ中に相互接続される複数のコントローラを備える。複数のコントローラのそれぞれは、複数の構成可能および置換可能なモジュールを含む少なくとも一つのメモリと、少なくとも一つのメモリに接続され、コントローラグラフに応じて、前記各コントローラの制御下の少なくとも一つの被制御要素に関する測定データに基づいて、少なくとも一つの被制御要素に関するアクションを実行するために、相互接続された態様で複数のモジュールを実行するように構成される少なくとも一つのプロセッサと、を備える。複数のコントローラは、少なくとも一つの被制御要素の動作における変化をもたらすことによって、アクションを実行するように構成される少なくとも一つの動作コントローラ（OC）と、少なくとも一つの被制御要素の構成における変化をもたらすことによって、アクションを実行するように構成される少なくとも一つの展開コントローラ（EC）と、を備える。
【0098】
いくつかの実施形態に係る自律ネットワークの稼働方法が提供される。ネットワークは、システム階層グラフ中に相互接続される複数のコントローラを備える。動作コントローラ（OC）または展開コントローラ（EC）である複数のコントローラのそれぞれは、複数の構成可能および置換可能なモジュールを含む少なくとも一つのメモリと、少なくとも一つのメモリに接続され、相互接続された態様で複数のモジュールを実行するように構成される少なくとも一つのプロセッサと、を備える。方法は、ＯＣによって、システム階層グラフにおいて下方のハードウェア機器または他のＯＣを制御することと、ＥＣによって、システム階層グラフにおいて下方の既存コントローラを制御および展開することと、を備える。展開することは、前記既存コントローラのコントローラグラフのセクションを完了するように構成可能な、構成可能および置換可能な候補モジュールの数を特定することと、コントローラグラフのセクションを完了するように様々な候補モジュールが相互接続される複数の異なる構成を決定することと、それぞれが複数の構成の一つに対応する、複数の展開されるコントローラを出力することと、を備える。方法は、試行管理部によって、複数の展開されるコントローラのいずれかによって前記既存コントローラが置換可能かを判定するために、オンライン試行を実行することと、を更に備える。
【0099】
以上、本開示の側面をより良く理解できるように、いくつかの実施形態の特徴の概要を示した。当業者であれば、同じ目的を達成し、および／または、ここで紹介された実施形態と同じ利点を実現するために、他のプロセスおよび構造を設計または変更するための基礎として本開示が利用されうると理解する。当業者は、このような同等の構成が本開示の精神および範囲から逸脱するものではなく、本開示の精神および範囲から逸脱することなく様々な変更、代用、変形を加えることができると認識する。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【国際調査報告】