特許 7333876 ファクトリーオートメーション用の公衆網におけるマルチサイトオーケストレーションを提供する方法、オーケストレータ及び通信システム

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

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

(11)【特許番号】

(24)【登録日】2023-08-17

(45)【発行日】2023-08-25

(54)【発明の名称】ファクトリーオートメーション用の公衆網におけるマルチサイトオーケストレーションを提供する方法、オーケストレータ及び通信システム

(51)【国際特許分類】

   H04W 24/02 20090101AFI20230818BHJP

   H04L 41/0806 20220101ALI20230818BHJP

   H04L 41/0895 20220101ALI20230818BHJP

   H04W 28/08 20230101ALI20230818BHJP

【ＦＩ】

H04W24/02

H04L41/0806

H04L41/0895

H04W28/08

【請求項の数】 15

(21)【出願番号】P 2022561260

(86)(22)【出願日】2021-02-04

(65)【公表番号】

(43)【公表日】2023-02-15

(86)【国際出願番号】 JP2021005133

(87)【国際公開番号】W WO2021199708

(87)【国際公開日】2021-10-07

【審査請求日】2022-06-15

(31)【優先権主張番号】20315104.8

(32)【優先日】2020-04-03

(33)【優先権主張国・地域又は機関】EP

(73)【特許権者】

【識別番号】503163527

【氏名又は名称】ミツビシ・エレクトリック・アールアンドディー・センター・ヨーロッパ・ビーヴィ

【氏名又は名称原語表記】ＭＩＴＳＵＢＩＳＨＩ ＥＬＥＣＴＲＩＣ Ｒ＆Ｄ ＣＥＮＴＲＥ ＥＵＲＯＰＥ Ｂ．Ｖ．

【住所又は居所原語表記】Ｃａｐｒｏｎｉｌａａｎ ４６， １１１９ ＮＳ Ｓｃｈｉｐｈｏｌ Ｒｉｊｋ， Ｔｈｅ Ｎｅｔｈｅｒｌａｎｄｓ

(74)【代理人】

【識別番号】100110423

【弁理士】

【氏名又は名称】曾我 道治

(74)【代理人】

【識別番号】100111648

【弁理士】

【氏名又は名称】梶並 順

(74)【代理人】

【識別番号】100122437

【弁理士】

【氏名又は名称】大宅 一宏

(74)【代理人】

【識別番号】100147566

【弁理士】

【氏名又は名称】上田 俊一

(74)【代理人】

【識別番号】100161171

【弁理士】

【氏名又は名称】吉田 潤一郎

(72)【発明者】

【氏名】カンフシ、ムーラド

【審査官】鈴木 重幸

(56)【参考文献】

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

【文献】特開２０１８－１２５７４４（ＪＰ，Ａ）

【文献】Nathan F. Saraiva de Sousaa, Danny A. Lachos Pereza, Raphael V. Rosaa, Mateus A. S. Santosb，Network Service Orchestration: A Survey，ARXIV.ORG, CORNELL UNIVERSITY LIBRARY，2019年05月20日，pp.1-33，https://arxiv.org/pdf/1803.06596.pdf

【文献】Jaspreet Singh Waliaa et al.，5G Network Slicing Strategies for a Smart Factory，COMPUTERS IN INDUSTRY, ELSEVIER, AMSTERDAM, NL, vol. 111，2019年08月06日，https://research.aalto.fi/files/35822747/ELEC_Walia_5G_Network_Slicing_Strategies_for_a_Smart_Factory.pdf

【文献】Karima Velasquez et al.，Service Orchestration in Fog Environmen，2017 IEEE 5TH INTERNATIONAL CONFERENCE ON FUTURE INTERNET OF THINGS AND CLOUD (FICLOUD)，2017年08月21日，https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=8114500

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

Ｈ０４Ｂ ７／２４－ ７／２６

Ｈ０４Ｗ ４／００－９９／００

Ｈ０４Ｌ４１／０８０６

Ｈ０４Ｌ４１／０８９５

３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１－４

ＳＡ ＷＧ１－４

ＣＴ ＷＧ１，４

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

【請求項1】

ファクトリーオートメーション用の公衆網においてマルチサイトオーケストレーションを提供する方法であって、前記公衆網は、前記公衆網のスライスを用いて互いに通信するように構成されている複数のサイトに通信及び計算機能を提供し、前記方法は、
前記複数のサイト内の異なるサイト間の通信の初期性能に基づいてマルチサイトオーケストレーションモデルを構築することと、
前記マルチサイトオーケストレーションモデルを使用することにより、前記異なるサイト間のコレオグラフィーの機会を決定することと、
前記異なるサイト間のコレオグラフィーをトリガーすることと、
前記異なるサイト間のコレオグラフィーの性能を評価し、前記マルチサイトオーケストレーションモデルを更新することと、
を含む、方法。

【請求項2】

前記マルチサイトオーケストレーションモデルを構築する前に、
粗い初期モデルを特定するように初期オーケストレーションを開始することであって、前記マルチサイトオーケストレーションモデルは前記初期オーケストレーションに基づいて構築される、開始すること
を更に含む、請求項１に記載の方法。

【請求項3】

前記初期オーケストレーションは、比例公平オーケストレーションであり、前記複数のサイトの各サイトは、前記比例公平オーケストレーションを用いて、同じデータパケット帯域幅で前記サイトの近傍サイトと通信する、請求項２に記載の方法。

【請求項4】

前記マルチサイトオーケストレーションモデルは、前記サイトの表現及び前記サイト間の通信条件の表現を含む、請求項１に記載の方法。

【請求項5】

前記マルチサイトオーケストレーションモデルは、前記サイトを表すノードと、前記ノードの任意の対の間のエッジとを含むグラフを含み、前記エッジは、前記ノード間の通信又は処理能力を表す、請求項１に記載の方法。

【請求項6】

前記マルチサイトオーケストレーションモデルは、前記異なるサイト間の通信の効用に関して表される前記サイトの需要のモデルを含む、請求項１に記載の方法。

【請求項7】

前記マルチサイトオーケストレーションモデルは、輻輳コストに関して表される前記異なるサイト間の通信の輻輳のモデルを含む、請求項１に記載の方法。

【請求項8】

前記マルチサイトオーケストレーションモデルは、前記異なるサイト間のパケットのランダムウォークと確率行列とに基づく特定のフロー伝送に基づくサイトランキングを含む、請求項１に記載の方法。

【請求項9】

前記マルチサイトオーケストレーションモデルは、関連する属性を有するオーケストレーションを実行するように適合されたサイトのデータベースを含む、請求項１に記載の方法。

【請求項10】

前記公衆網の初期性能は、ネットワーク状態、スループット、パケットエラー及び／又は遅延の定期的なモニタリングによって得られる、請求項１に記載の方法。

【請求項11】

前記マルチサイトオーケストレーションモデルを使用することにより、前記異なるサイト間のコレオグラフィーの機会を決定することは、前記マルチサイトオーケストレーションモデルから予測された性能と測定されたトラフィック性能との誤差に基づき、又は、前記マルチサイトオーケストレーションモデルから得られるトポロジー基準を通して、処理される、請求項１０に記載の方法。

【請求項12】

前記異なるサイト間のコレオグラフィーをトリガーすることは、前記コレオグラフィーに参加している前記異なるサイト間でエッジクラウドを設定することと、前記異なるサイト間で情報の交換を開始することとを含む、請求項１に記載の方法。

【請求項13】

前記異なるサイト間のコレオグラフィーの性能を評価し、前記マルチサイトオーケストレーションモデルを更新することは、前記公衆網をモニタリングすることを含む、請求項１に記載の方法。

【請求項14】

ファクトリーオートメーション用の公衆網においてマルチサイトオーケストレーションを提供するオーケストレータであって、前記公衆網は、前記公衆網のスライスにより互いに通信するように構成されている複数のサイトに通信及び計算機能を提供し、前記オーケストレータは、
前記公衆網の初期性能に基づいてマルチサイトオーケストレーションモデルを構築し、
前記マルチサイトオーケストレーションモデルを使用することにより、前記複数のサイト内の異なるサイト間のコレオグラフィーの機会を決定し、
前記異なるサイト間のコレオグラフィーをトリガーし、
前記異なるサイト間のコレオグラフィーの性能を評価し、前記マルチサイトオーケストレーションモデルを更新する
ように構成されている、オーケストレータ。

【請求項15】

請求項１４に記載のオーケストレータを備える、ファクトリーオートメーション用の通信システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ファクトリーオートメーション用のマルチサイトオーケストレーションのためのネットワークオーケストレーションに関し、特に、ファクトリーオートメーション用の公衆網においてマルチサイトオーケストレーションを提供する方法に関する。

【背景技術】

【0002】

１つの工場の複数のサイト間で、又は異なる工場間で分散される通信のためのリソースプロビジョニングは、ファクトリーオートメーションに適合している。通常、リソースプロビジョニングは、ファクトリーオートメーション通信専用の低コストのネットワークスライスを展開することにより、公衆陸上移動体通信網（ＰＬＭＮ）等の公共事業者から得られる。

【0003】

本技術分野において、マルチサイトオーケストレーションは、このネットワークスライスにおいて通信を確立／解放するために使用される。この通信の確立及び解放は、ＰＬＭＮから取得される帯域幅及び計算リソースの使用メトリクスに関するスライス使用に基づいて行われる。

【0004】

特に、一般的なリソースプロビジョニングの問題は、３つの調整される最適化問題の解として提示されてきた。これらの最適化問題は、スライスコストとして定義されるリソース使用表示（ルーティング／計算リソース）によって調整される。詳細な問題を以下に定義する。

【0005】

Ａ．スライス所有者最適化問題：（帯域幅の）スライススループット需要は、スライスルーティングコストと輻輳コストと計算使用コストとをパラメータとして使用する効用最大化最適化問題を通して得られる。異なるサイトに対して、同じ効用関数を使用する。

【0006】

Ｂ．クラウド所有者最適化問題：サイト間の通信及び異なるＶＮＦ間の経路に必要とされる仮想ネットワーク機能（ＶＮＦ）をサポートするために必要である計算リソースとともに、クラウド使用コストは、クラウド所有者によって提供される。これらのリソースは、ＰＬＭＮスライス帯域幅に比例する。この問題は、スライス計算コストをスライス所有者最適化問題に出力し、ルーティングコスト及び輻輳コストを入力として使用する。

【0007】

Ｃ．ネットワーク所有者最適化問題：スライスにおけるサイト間の通信に対して異なるフローをルーティングするために、ネットワーク所有者により、ルーティングコスト及びスライスコストが見つけられる。このネットワーク所有者最適化問題により、スライス所有者及びクラウド提供者に対してネットワークの能力を知らせるためのスライス輻輳コストが得られる。

【0008】

最適化問題（Ｃ）の解によって提供されるスライスルーティング及び輻輳コストは、問題（Ａ）によって設定されたスライス所有者需要要件、問題（Ｂ）を解くことによって得られるクラウド所有者最適化要件を達成するネットワークの可能性を表す。要件が達成されない場合、コストは高く、達成される場合、コストは低い。スライスリソース割当て問題の解としての最新技術におけるマルチサイト割当ての全体的な概要を、本技術分野におけるマルチサイトオーケストレーションアーキテクチャを示す図１において概説する。

【0009】

図１に示す状況において、１つの会社の２つのサイトＳ１及びＳ２は、公衆網ＰＬＭＮのスライスｉを使用して通信することを望む（図１ではＰ１と記す）。この通信確立のステップは以下の通りである。

【0010】

１）マルチサイトオーケストレータＭＯは、サイトＳ１とサイトＳ２との間の通信の帯域幅需要をソフトウェア定義ネットワーク（ＳＤＮ）コントローラに送信する。この需要は、スループット及びレイテンシーの両方に関する。

【0011】

２）ＳＤＮコントローラは、サイトＳ１とサイトＳ２との間の通信のスライスルーティング問題を解決し、ルーティング決定及びスライスコストをクラウドコントローラＣＣとマルチサイトオーケストレーションＭＯとに送信する（図１ではＰ２と記す）。ＳＤＮコントローラによって送信されるスライスコストは、本質的に、スライスのスループット需要の達成に関連する。

【0012】

３）クラウドコントローラＣＣは、ＳＤＮコントローラのルーティング決定に基づき、スライスに対して仮想ネットワーク機能を割り当てる手段により、スライスのレイテンシー要件を確保するため、計算リソースをプロビジョニングする（図１ではＰ３と記す）。クラウドコントローラＣＣは、スライスの計算コスト、すなわち、スライスのレイテンシー要件が満たされる程度を送信する（図１ではＰ４と記す）。

【0013】

４）マルチサイトオーケストレータＭＯは、ルーティング決定及びコスト（ルーティングコスト及び計算コスト）を受信し、ネットワークにおける現時点の状況に最適に適合するようにスライス需要を調整する（図１ではＰ５と記す）。

【0014】

したがって、最新技術では、サイト間の通信のために、仮想経路確立及びスライスリソースプロビジョニングが提示及び適用され、すなわち、この問題は、ＰＬＭＮによって提供されるスライスに基づくマルチサイト運用のための周期的かつ再構成可能なスライス設計として捉えられる。

【発明の概要】

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

【0015】

しかしながら、上述した手法の１つの欠点は、オーケストレーションのレイテンシーである。その理由は、マルチサイトオーケストレータが、サイトから情報を受信し、異なるサイト間の伝送方式を決定するためである。加えて、サイトとマルチサイトオーケストレータとの間で往復のシグナリングが生じているため、ネットワークにシグナリングのオーバーヘッドが発生している。

【0016】

さらに、別の欠点は、本技術分野におけるマルチサイトオーケストレータの複雑性が高いことである。その理由は、本技術分野におけるオーケストレータが、伝送戦略並びにサイトのスループット及び計算に関する需要も判断しなければならないためである。

【0017】

本発明は、これらの欠点を改善することを目的とする。

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

【0018】

これに関して、本発明の１つの態様によれば、ファクトリーオートメーション用の公衆網においてマルチサイトオーケストレーションを提供する方法が提供される。公衆網は、公衆網のネットワークスライスを用いて互いに通信するように構成されている複数のサイトに通信及び計算機能を提供する。方法は、
異なるサイト間の通信の初期性能に基づいてマルチサイトオーケストレーションモデルを構築することと、
マルチサイトオーケストレーションモデルを使用することにより、異なるサイト間のコレオグラフィーの機会を決定することと、
異なるサイト間のコレオグラフィーをトリガーすることと、
異なるサイト間のコレオグラフィーの性能を評価し、マルチサイトオーケストレーションモデルを更新することと、
を含む。

【0019】

こうした構成により、本発明は、集中型オーケストレーションを分散オーケストレーションと組み合わせてもよい。分散オーケストレーションは、マルチサイトオーケストレータに維持されるネットワークのモデルにおいてマルチサイトオーケストレータを介するエッジクラウドリソースの分散プロビジョニングに依存する。その結果として、オーケストレーションプロセスのレイテンシーを最小化することができる。

【0020】

一実施の形態において、マルチサイトオーケストレーションモデルを構築する前に、本発明による方法は、粗い初期モデルを特定するように初期オーケストレーションを開始することを更に含む。ここで、マルチサイトオーケストレーションモデルは初期オーケストレーションに基づいて構築される。

【0021】

さらに、初期オーケストレーションは、比例公平オーケストレーションであり、各サイトは、比例公平オーケストレーションを用いて、同じデータパケット帯域幅でサイトの近傍サイトと通信する。

【0022】

さらに、マルチサイトオーケストレーションモデルは、サイト及びサイト間の通信条件の表現又はこれらを抽象化したものを含む。

【0023】

代替的に、マルチサイトオーケストレーションモデルは、サイトを表すノードと、ノード間の通信又は処理能力を表す、ノードの対の間のエッジとを含むグラフを含む。

【0024】

代替的に、マルチサイトオーケストレーションモデルは、例えば、サイト間の通信の効用に関して表されるサイトの需要のモデルを含む。

【0025】

代替的に、マルチサイトオーケストレーションモデルは、例えば、輻輳コストに関して表されるサイト間の通信の輻輳のモデルを含む。

【0026】

代替的に、マルチサイトオーケストレーションモデルは、サイト間のパケットのランダムウォークと確率行列とに基づく特定のフロー伝送に基づくサイトランキングを含む。

【0027】

代替的に、マルチサイトオーケストレーションモデルは、関連する属性を有するオーケストレーションを実行するように適合されたサイトのデータベースを含む。

【0028】

代替的に、公衆網の初期性能は、ネットワーク状態、スループット、パケットエラー及び／又は遅延の定期的なモニタリングによって得られる。加えて、マルチサイトオーケストレーションモデルを使用することにより、異なるサイト間のコレオグラフィーの機会を決定するステップは、マルチサイトオーケストレーションモデルからの予測された性能と測定されたトラフィック性能との誤差に基づき、又は、マルチサイトオーケストレーションモデルから得られるトポロジー基準を通して、処理される。

【0029】

これに関して、本発明において、レイテンシーが低減した、柔軟なモデルに基づくマルチサイトオーケストレーションにより、ネットワークモニタリングから決定されるいくつかの条件でオーケストレーションがトリガーされる。レイテンシーを最小化するとともにオーケストレーションのＱｏＳを最適化するために、必要な場合にはローカルオーケストレーションが決定される。これらのローカルコレオグラフィーを使用して、マルチサイトオーケストレーションに使用されるモデルが強化される。

【0030】

更に別の実施の形態において、異なるサイト間のコレオグラフィーをトリガーするステップは、コレオグラフィーに参加している異なるサイト間でエッジクラウドを設定することと、異なるサイト間で情報の交換を開始することとを含む。

【0031】

更に別の実施の形態において、異なるサイト間のコレオグラフィーの性能を評価し、マルチサイトオーケストレーションモデルを更新するステップは、公衆網をモニタリングすることを含む。

【0032】

上述した代替的な特徴は、適合性のない場合を除き、互いに組み合わせることができる。

【0033】

本発明の別の態様によれば、ファクトリーオートメーション用の公衆網においてマルチサイトオーケストレーションを提供するオーケストレータが更に提供される。公衆網は、公衆網のスライスにより互いに通信するように構成されている複数のサイトを含む。オーケストレータは、
公衆網の初期性能に基づいてマルチサイトオーケストレーションモデルを構築し、
マルチサイトオーケストレーションモデルを使用することにより、異なるサイト間のコレオグラフィーの機会を決定し、
異なるサイト間のコレオグラフィーをトリガーし、
異なるサイト間のコレオグラフィーの性能を評価し、マルチサイトオーケストレーションモデルを更新する
ように構成されている。

【0034】

本発明の更に別の態様によれば、上述したオーケストレータを備える、ファクトリーオートメーション用の通信システムが更に提供される。

【0035】

これに関して、本発明は、マルチサイトオーケストレータが、受信されたスループット、レイテンシー、パケットエラーレート又は他の様々なネットワーク無線メトリクスに基づいて、工場の異なるサイト間のオーケストレーションプロセスのモデルを維持する、認知モデルに基づくマルチサイトオーケストレーションを提案する。これらのメトリクスは、ネットワークによって提供されるスライスを介する通信の連続モニタリングを通して得られる。言い換えれば、本発明では、マルチサイトオーケストレータは、レイテンシーを最小化するとともにシステムのＱｏＳを改善するために、オーケストレーションの機会及びローカルオーケストレーション（コレオグラフィー）の機会及びトリガーを決定する。コレオグラフィーステップにより、マルチサイトオーケストレーションモデルが強化される。

【0036】

したがって、本技術分野における標準モデルに基づくオーケストレーションと比較して、本発明は、より高い柔軟性を提供する。その理由は、本発明が、オーケストレーション性能を改善するとともにその全体的なシグナリング及び複雑性を低減させるために、粗いモデルから開始してモデルを調整することができるためである。

【0037】

本発明の他の特徴及び利点は、添付図面に関連して以下の説明において明らかとなろう。

【図面の簡単な説明】

【0038】

【図1】本技術分野におけるマルチサイトオーケストレーションアーキテクチャを示す図である。

【図2】本発明によるマルチサイトオーケストレーションアーキテクチャを示す図である。

【図3】本発明による例示的な方法のフローチャートである。

【発明を実施するための形態】

【0039】

図２に、本発明によるマルチサイトオーケストレーションアーキテクチャを示す。図２において、マルチサイトオーケストレータＭＯは、所与のＰＬＭＮネットワークのＳＤＮコントローラによって提供されるネットワークスライス内の異なるサイトＳ１、Ｓ２及びＳ３の間（例えば、サイトＳ１とサイトＳ２との間）で通信帯域幅を調整し、エッジクラウド又はマルチアクセスエッジ通信プラットフォームを介して各サイトに密接して配置されている計算リソースに依存している。

【0040】

マルチサイトオーケストレータドメインの各サイトは、ネットワークが提供しているスライスにわたるスループットｒ_ｉをネットワークに要求することによって得られる利得を表すローカル効用関数Ｕ_ｉを定義する。

【0041】

効用関数は、サイトｉに対して要求されるスループットが全体的な利得（スループット変動に関する利得の変動からスループットコストを引いたもの）に基づいて調整されるように、スライス輻輳コストλ_ｉに基づいて調整される。

【0042】

マルチサイトオーケストレータＭＯは、各サイト間の輻輳コストを示すのではなく、異なるサイトに対して組み合わされた輻輳コストを示して、異なるサイト間の帯域幅のバランスを取ることにより、システムの全体的な利得、すなわちネットワークにおける効用の和を最大化するという目的を有する。

【0043】

これに関して、マルチサイトオーケストレータＭＯは、異なるサイト間での帯域幅バランスのネットワークのモデルに基づいて決定し、このモデルについて以下に詳述する。本発明は、帯域幅バランスを、比例公平帯域幅バランスで開始することにより反復的に実行し、このステップから、オーケストレーションのための関連するモデルパラメータを特定しようとするものであり、モデルパラメータのサブセットは、ローカルオーケストレーションを通して更新され、モデルパラメータ特定のためにローカルオーケストレーション（コレオグラフィー）をトリガーする必要がある。

【0044】

したがって、概して、本発明は、以下の特徴を含む解決法を提案する。

【0045】

－マルチサイトオーケストレータは、サイト間のオーケストレーションのためのモデルを構築する。特に、マルチサイトオーケストレータＭＯは、オーケストレーションのために公衆網及び／又はクラウドの異なるＫＰＩをモニタリングすることにより、モデルを評価する。加えて、マルチサイトオーケストレーションは、ＰＬＭＮのＫＰＩに基づいてサービスコレオグラフィーの機会を決定する。オーケストレーションの機会は、例えば、サイト間のローカル分散オーケストレーション、すなわちサービスコレオグラフィーを実行するために十分な無線及び／又はサービスレベルＫＰＩである。

【0046】

－モデルベースのオーケストレーションの性能は、更新すべきモデルパラメータのサブセットを特定するために、オーケストレーションの性能をモニタリングする手段によって評価される。ネットワークのモニタリングは、以下であり得るＫＰＩを追跡することからなる。

【0047】

オーケストレーションの性能の評価には、オーケストレーションサービスレベル要件又はＳＬＡ（サービスレベル合意）の実現等、サービス関連のＫＰＩが使用される。

【0048】

オーケストレーションの性能の評価には、パケットエラーレート性能、エンドツーエンドレイテンシー、ジッター性能等、無線レベル又はトランスポートレベルのＫＰＩが使用される。

【0049】

－マルチサイトオーケストレータは、オーケストレーションの性能が低いとき、又はサービスコレオグラフィーの機会が検出されたとき、サイト間のサービスコレオグラフィーをトリガーする。オーケストレータは、情報の交換により、シグナリングにより、コンテナを介する計算リソースのプロビジョニングにより、サイト間の分散オーケストレーションをトリガーする。サービスコレオグラフィーは、サイト間で実行され、オーケストレーションモデルを改善するために使用される。

【0050】

ここで、本発明による例示的な方法のフローチャートである図３を参照することにより、本発明の方法による詳細なステップについて説明する。

【0051】

図３に示すように、本発明による方法の例示的な実施形態は、以下のステップを含む。

【0052】

ステップ０：初期オーケストレーションステップ
モデル構築ステップの前に、マルチサイトオーケストレータは、マルチサイトオーケストレータのための粗い初期モデルを設定するような、任意選択的な初期オーケストレーションステップで開始してもよい。

【0053】

初期オーケストレーションは、マルチサイトオーケストレータが、ＰＬＭＮによって提供されるスライスの容量Ｃビット／秒を知っており、帯域幅ｒ＝Ｃ／Ｎでデータパケットを送信することによって通信するように、ネットワークのＮ個のサイトのそれぞれをトリガーする、比例公平オーケストレーションによって与えられてもよい。各サイトは、同じデータパケット帯域幅で近傍サイトと通信する。

【0054】

ステップ１：マルチサイトオーケストレーションモデルを構築する
このステップでは、初期オーケストレーションステップに基づき、マルチサイトオーケストレータにおいて、サイトと異なるサイト間の通信条件との表現又はモデルが構築される。

【0055】

この表現は、以下を含んでもよい。

【0056】

－グラフ（有向又は無向）。グラフのノードは、工場のサイトを表し、ノードのペア間のエッジは、ノード間の通信／処理能力を表す。サイトＳ１とサイトＳ２との間の通信／処理能力は、例えば、以下によって定義することができる。

【0057】

・単位時間当たりに送信されるパケットの数として表される、通信のパケットスループットｒ_１，２。

【0058】

・単位時間当たりに送信されるビットの数として表される、通信のビットスループットｂ_１，２。

【0059】

・Ｎ個のパケットの通信ごとの秒で表される、通信のレイテンシーｔ_１，２。

【0060】

・ノードＳ１とノードＳ２との間の経路において利用可能な計算リソースの量を表す、処理能力ｐ_１，２。ここでは、処理能力がスループット能力と関連するという仮定をｐ_１，２＝ωｒ_１，２として考える。なお、ωは、１パケットのデータを処理するのに必要な処理量である。

【0061】

－微分効用関数に関して表されたサイトの需要のモデル。例えば、サイトＳ１とサイトＳ２との間の通信の効用は、Ｕ_１，２＝Ｕ_１（ｒ_１，２）－Ｕ_２（ｒ_１，２）として表される。ここで、関数Ｕ_１は、スループットｒ_１，２をノード２に送信するための利得を表し、関数Ｕ_２は、スループットｒ_１，２をサイトＳ２から受信するための利得を表す。両方の利得が、Ｓ１とＳ２との間のサービスに依存している。

【0062】

効用関数は、サイトに対して同じ関数であっても、サイトごとに異なる関数であってもよい。効用関数は、以下のように、パラメータαによってパラメータ化されるα公平効用関数であってもよい。すなわち、α＞１の場合、

【数1】

であり、α＝０の場合はＵ（ｒ）＝ｌｏｇ（ｒ）である。式中、ｒは、ノードで進行中のパケットのスループットである。

【0063】

－異なるサイト間の通信の輻輳のモデル。このモデルは、サイト間の伝送のパケットエラーレート（ＰＥＲ）及び／又はノード間のパケットスループットの関数であってもよい輻輳コストλとして表される。ＰＥＲが高い場合、輻輳コストは高く、ＰＥＲが低い場合、輻輳コストは低い。スループットが低い場合、輻輳コストは高く、スループットが高い場合、輻輳コストは低い。輻輳コストはまた、異なるサイト間の伝送中に喪失したパケットをモデル化する伝送のレイテンシーを含んでもよい。

【0064】

異なるサイト間の通信は、ランダムウォークとしてモデル化され、確率行列Ｓが定義される。行列要素Ｓ_１，２は、ノード１で進行中のトラフィックの比として表され、すなわち、Ｓ_１，２＝１／ｄ（１）である。ここで、ｄ（１）は、ノード１が通信することができるノードの数である。ここでは、サイトＳ１はサイトＳ２と確率Ｓ_１，２で通信していると仮定している。

【0065】

－ランダムウォーク行列から、２つのパラメータβ、ｎによってパラメータ化される遷移行列Ｇ。パラメータβ∈［０，１］は、現時点でのマルチサイト通信とサイト間の純粋なランダムウォークとして記述されるマルチサイト通信との相関を記述する。パラメータｎは、ノード１からのウォークに含まれないサイトへの通信試行を制御する。要素Ｇ_１，２は、Ｇ_１，２＝βＳ_１，２＋（１－β）（１／ｎ）によって与えられる。

【0066】

－関連する属性を有するオーケストレーションを実行することができるサイトのデータベース。この場合、サイトＳ１は、受信したトラフィックから、その近傍サイトとの通信の関連するパラメータとともに、近傍サイトの処理能力をローカルに決定し、決定した属性とともにデータベースに登録する。このデータベースは、マルチサイトオーケストレータＭＯにより、異なるサイト間の通信のためのリソースのプロビジョニングを通してオーケストレーションを実行するために使用される。このオーケストレーションは、データベースにおける登録されたサイトの属性に基づく。サイトとマルチサイトオーケストレータとの間のシグナリングオーバーヘッドを低減するために、アプリケーションインターフェース（ＡＰＩ）シグナリング最適化のためのウェブベースの表現状態転送（ＲＥＳＴ）フレームワークを使用してもよい。

【0067】

データベースの更新は、異なるサイト間のローカルオーケストレーションによって実行される。

【0068】

上述したモデルは、単独で又は組み合わせて適用することができる。したがって、マルチサイトオーケストレーションモデルは、ネットワーク状態、スループット、パケットエラー、遅延等の定期的なモニタリング（図２ではＮ１と記す）から、マルチサイトオーケストレータＭＯにおいて構築され（図２ではＮ２と記す）、ネットワークと異なるサイトとの間のシグナリングを低減させるために、マルチサイトオーケストレーションＭＯにおいて使用される。加えて、マルチサイトオーケストレータＭＯにおいて、サイト間の予測された通信プロファイルとネットワークモニタリング期間中の実際の測定された性能との誤差を検査することにより、モデルの信頼性をローカルで評価してもよい。

【0069】

ステップ２：コレオグラフィーの機会を決定する
したがって、マルチサイトオーケストレータは、モデルから予測された性能（サイトＳ１とサイトＳ２との間の通信の予測されたスループット等）とネットワークモニタリング期間中に測定されたトラフィック性能との誤差に基づき、又は、マルチサイトオーケストレーションモデルの特定の特性から得られるトポロジー基準によって、又は、誤差に基づくトリガーとトポロジーに基づくトリガーとの組合せによって、コレオグラフィーの機会を決定する。

【0070】

誤差は、例えば、スループット誤差ＰＥＲ及び遅延推定誤差、並びにコレオグラフィー中にモニタリングされる様々な他のネットワーク性能指標の関数として得られる、誤差行列に集められる。

【0071】

特に、コレオグラフィーの機会は、以下が達成されるときに定義してもよい。

【0072】

－誤差ｅ_１，２が、マルチサイトオーケストレータＭＯにあらかじめ構成されている誤差閾値を上回る場合、サイトＳ１及びＳ２に対してコレオグラフィーがトリガーされる。

【0073】

－サイトＳ１及びＳ２の総誤差が閾値を上回るとともに、性能指標（スループット、レイテンシー、パケットエラーレート）のうちの少なくとも１つが閾値を下回る場合、サイトＳ１及びＳ２に対してコレオグラフィーがトリガーされる。

【0074】

代替的に、以下のトポロジー基準が実現されるとき、サイトＳ１とサイトＳ２との間でコレオグラフィーをトリガーしてもよい。

【0075】

－サイトＳ１及びＳ２が、グラフにおいて高次数を有している場合、サイトＳ１及びＳ２に対してコレオグラフィーがトリガーされる。グラフのノードＳ１の次数は、サイトＳ１が通信することができる近傍サイトの数として定義される。グラフにおける高次ノードは、閾値を上回る次数を有するノードである。

【0076】

－サイトＳ１及びＳ２が、ネットワークにおける任意の２つのサイトの間の多数の通信経路に寄与している場合、サイトＳ１及びＳ２に対してコレオグラフィーがトリガーされる。この場合、ノードＳ１及びＳ２が、ネットワークにおいて高い中心性を有している場合、サイトＳ１とサイトＳ２との間のコレオグラフィーがトリガーされる。高い中心性は、閾値を上回る中心性として定義される。

【0077】

－ノードは、遷移行列Ｇに関してランク付けされ、サイトＳ１及びＳ２のランクが閾値を下回る場合、サイトＳ１及びＳ２に対してコレオグラフィーがトリガーされる。この選択肢において考慮されるランキングは、例えば、ノードに対応する行列Ｇの固有値、又は行列Ｇの何らかの特定の固有値に対応する固有ベクトルである。

【0078】

－サイトＳ１及びＳ２が、マルチサイト展開において別のサイトからのルーティングツリーに寄与しており、それらの相対的な輻輳コストλ_１，２が増加した場合、サイトＳ１及びＳ２に対してコレオグラフィーがトリガーされる。相対的な輻輳コストλ_１，２は、サイトＳ１とサイトＳ２との間の通信に対するルーティングコストとして定義される。

【0079】

ステップ３：マルチサイトコレオグラフィーをトリガーする
その後、図２にＮ４として記すマルチサイトコレオグラフィーは、マルチサイトオーケストレータＭＯにより、以下のシグナリングを通してトリガーされてもよい。

【0080】

－サイトＳ１及びＳ２は、オーケストレータからマルチサイトコレオグラフィーをトリガーする明示的な制御メッセージを受信したとき、コレオグラフィーを実行する。このメッセージは、コレオグラフィーに寄与しているサイトのＩＰアドレスと、コレオグラフィーステップにおいてサイト間の通信に使用される仮想ネットワークのＱｏＳパラメータとを含んでもよい。

【0081】

－遷移行列Ｇは、パラメータβを低減させることによって更新され、オーケストレータにおいて、ネットワークに対するランキングが更新され、ランクは、サイトＳ１及びＳ２に送信される（図２ではＮ３と記す）。サイトは、それらのランクが閾値を下回る場合、コレオグラフィーを実行することを決定する。コレオグラフィーは、同様の相対的に低いランクを有するサイト間で実行される。

【0082】

サイトＳ１及びＳ２の効用関数は、各サイトにおいてオーケストレータによって、コレオグラフィーが以下のように実行されるように更新される。効用関数のパラメータαは低減し、異なるサイト間の通信のスループットは、

【数2】

に設定される。式中、λ_１，２は、サイトＳ１とサイトＳ２との間の通信のための輻輳コストの最新の推定値である。

【0083】

ステップ４：ローカルオーケストレーション（マルチサイトコレオグラフィー）、及びマルチサイトオーケストレーションモデルを更新する
オーケストレータＭＯは、ローカルオーケストレーションに参加するさまざまなサイトにおけるエッジクラウドと、異なるエッジクラウド間の通信のための仮想ネットワークとを設定する。エッジクラウドは、エッジクラウドコンテナベースの技術を通して調整される。ローカルオーケストレーションに参加しているサイトは、以下のように定義されたスループットで情報の交換を開始する。

【0084】

－サイトの効用のパラメータαは低減し、異なるサイト間の通信のスループットは、

【数3】

に設定される。式中、λ_１，２は、サイトＳ１とサイトＳ２との間の通信のための輻輳コストの最新の推定値である。

【0085】

－サイトの効用のパラメータαは低減し、異なるサイト間の通信のスループットは、

【数4】

に設定される。式中、λ_１，２は、サイト１とサイト２との間の通信のための輻輳コストの最新の推定値である（輻輳コストλ_１，２の信頼性が低い場合）。

【0086】

－スループットは、その現在の値から、ＭＮＯによって提供されるか又はサイトＳ１及びＳ２によって自律的に選択される、劣化したスループットに低下する。

【0087】

一方、マルチサイトオーケストレータＭＯは、図２ではＮ５として記される、２つのサイトの間の通信性能をモニタリングしている。特に、マルチサイトオーケストレータは、そのモニタリング期間中に最終的にサイトのローカル効用を調整することを決定し、効用関数の最新の値を記憶する。例えば、モニタリングが遷移行列Ｇに基づく場合、オーケストレータは、良好なスループット／レイテンシー性能を有する近傍の数ｍ_１，２として、新たなパラメータで行列Ｓの値を更新する。この場合、Ｓ_１，２＝ｍ_１，２／ｄ（１）である。

【0088】

マルチサイトオーケストレータのモデル／データベースは、ローカルオーケストレーション中に学習されたパラメータで更新される（図２ではＮ６と記す）。

【0089】

本発明を更に説明するために、以下、上述した方法を使用していくつかの実施形態について記載する。

【0090】

Ｎ個のサイトのマルチサイトオーケストレーションシナリオを想定する。そこでは、各サイトはそれ自体の効用関数を最適化し、マルチサイトオーケストレーションは、サイトの効用関数の和を最大化する操作である。サイトは、通信に対して同じネットワークスライスを使用しており、ネットワークスライスに割り当てられた最大スループット又は帯域幅、すなわちスライス容量は、Ｃである。

【0091】

効用関数は、各サイトのスループット需要、すなわち、所与のサービスに対して通信に必要な帯域幅と処理に必要な帯域幅とを決定する。サイトの帯域幅需要とサイトにおける仮想機能の処理能力との間に比例関係があると想定する。

【0092】

この実施形態において、本発明者らが提案するマルチサイトオーケストレーションは、異なるサイト間の通信のためのスループットの調整と、通信停止を最小限にするとともにスライスにおける帯域幅使用を最適化するための需要の調整とに対する戦略に基づく。

【0093】

効用関数は、以下に示す、サイトのスループットｒ_ｉの関数として、通信に必要な帯域幅に関してサイト需要を表すα公平効用関数としてモデル化される。

【数5】

【0094】

パラメータαは、スループットに関して需要を調整し、全体的なマルチサイトオーケストレーション問題は、複数の需要パラメータを用いるネットワーク効用関数最大化としてみなされる。

【0095】

全体的なマルチサイトオーケストレーション問題は、以下のように与えられる。

【数6】

【0096】

変数Ａ_ｉ，ｊは、ネットワークのルーティング変数、すなわち、サイトｉとサイトｊとの間の通信の、ネットワークスライスにおけるトラフィックに対する寄与である。ｒ_ｉ，ｊは、サイトｉとサイトｊとの間の通信のスループットである。

【0097】

ネットワークスライスに対する輻輳コストλを含めると、以下の大域的なラグランジュの公式が得られる。

【数7】

【0098】

各ローカルオーケストレータは、以下の局所的なラグランジュの問題を解いている。

【数8】

【0099】

この局所的なラグランジュの問題の解は以下のように与えられる。

【数9】

【0100】

これは、各サイトが、ルーティングパラメータＡ_ｉ，ｊとスライスコストパラメータλとを考慮することによりそのスループットを調整することを意味する。本発明は、主要なルーティングパラメータが各サイトにおいて以下のように特定される、簡略化したマルチサイトオーケストレーションを提案する。

【数10】

【0101】

サイトは、以下のようにそのスループットを調整する。

【数11】

【0102】

サイトがスライスの全容量を使用していると想定すると、各スライスは、以下のスループットで送信する。

【数12】

【0103】

サイトｉとサイトｊとの間のスループットは、以下の関係によって提供される。

【数13】

【0104】

本発明によれば、主要なルーティングは、上述したように、モデルから推定又は決定され、コストに関してスループットを調整している。

【0105】

この実施形態において、本発明の一例である方法は、以下のステップを含む。

【0106】

１．マルチサイトオーケストレータは、パラメータα_ｉ＝１、すなわち試験シーケンスを用いてオーケストレーションを開始し、マルチサイト展開の１つのサイトから他のサイトにパケットが送信される順序であるスケジュールが、オーケストレーションモデル｛Ａ_ｉ，ｊ｝を特定するために使用される。各サイトに対する主要なルーティングは、異なるサイト間の通信の測定されたスループットから得られる。

【0107】

２．輻輳コストは、マルチサイトオーケストレータにおいて異なるサイトについて測定されたスループットから得られる。

【0108】

３．マルチサイトオーケストレータは、最大ルーティング値

【数14】

を有するサイトの組を選択し、それらのサイトのスループットを

【数15】

に設定する。輻輳コストが増大するか、又はいくつかのサイトが停止した場合、マルチサイトは、ローカルオーケストレーションをトリガーして、主要なルーティング

【数16】

を有するノードを有しているノードの特定のペア間でモデルを更新する。

【0109】

４．ローカルコレオグラフィーは、｛Ａ_ｉ，ｊ｝の推定値を更新し、ステップ（２）に進む。

【0110】

代替的に、別の実施形態において、本発明は、上述した局所的なラグランジュ関係を最大化するために、サイト需要を調整することを提案する。需要は、ｋが以下の反復指数を定義している以下の関係を用いてパラメータα_ｉによって反復的に記述されるパラメータによって記述される。

【数17】

【0111】

サイトｉとサイトｊとの間のスループットは、以下の関係によって提供される。

【数18】

【0112】

スライス輻輳コストは、以下によってスライス容量を最適化するように更新される。

【数19】

式中、δは、輻輳コスト又はスライス使用量を更新するためのステップである。この更新ステップは、固定であっても適応的であってもよい。固定ステップの場合、全ての輻輳コスト更新に同じステップが維持され、適応的ステップでは、スライス輻輳コストの増加率が高い場合、ステップδを低減させることもできる。

【0113】

これに関して、本発明によるこの代替実施形態におけるマルチサイトオーケストレーションは、以下のステップを含む。

【0114】

１．マルチサイトオーケストレータは、パラメータα_ｉ＝１、すなわち試験シーケンスを用いてオーケストレーションを開始し、スケジュールが、オーケストレーションモデルを特定するために使用される。各サイトに対する主要なルーティングは、異なるサイト間の通信の測定されたスループットから得られる。初期輻輳コストはＣに設定され、サイトは通信していない。

【0115】

２．初期輻輳コストは、マルチサイトオーケストレータにおいて異なるサイトに対する測定されたスループットから得られる。

【0116】

３．マルチサイトオーケストレータは、最大ルーティング値

【数20】

を有するサイトの組を選択し、各サイトは、上記関係によりその需要

【数21】

を設定し、上述した関係によりサイトｉとサイトｊとの間のスループットを決定する。

【0117】

４．オーケストレータは、上記関係で輻輳コストを更新する。

【0118】

５．ローカルコレオグラフィーは、｛Ａ_ｉ，ｊ｝の推定値を更新し、ステップ（２）に進む。

【0119】

要約すると、本発明は、以下の特徴を含む認知モデルに基づくマルチサイトオーケストレーションを提案する。

【0120】

－ＰＬＭＮの性能をモニタリングし、マルチサイトオーケストレーション（サービス又は無線オーケストレーション）に対するマルチサイトオーケストレーションモデルを構築する。

【0121】

－モデルからサイト間の分散オーケストレーション又はコレオグラフィーの機会を決定し、異なるサイト間のコレオグラフィーをトリガーする。

【0122】

－コレオグラフィーを使用して、マルチサイトオーケストレーションモデルを更新する。

【0123】

したがって、本発明は、ＰＬＭＮ及び／又はクラウドネットワークから得られる部分的な情報を考慮するため、柔軟性を有する。したがって、オーケストレーションの目的が最適化され、オーケストレーションの複雑性が全体的に低減する。加えて、本発明により、マルチサイトオーケストレーションのレイテンシー及び公衆網とのシグナリングオーバーヘッドもまた低減する。

【0124】

加えて、当業者に既知であるように、本発明によって上記で説明した上述の例示のアーキテクチャは、多くの方法、例えば、プロセッサによる実行のためのプログラム命令、ソフトウェアモジュール、マイクロコード、コンピュータ可読媒体上のコンピュータプログラム製品、論理回路、特定用途向け集積回路、ファームウェア等において実施することができる。本発明の実施形態は、完全にハードウェアの実施形態の形式、完全にソフトウェアの実施形態の形式、又はハードウェア要素及びソフトウェア要素の双方を含む実施形態の形式を取ることができる。好ましい実施形態において、本発明は、ソフトウェアにおいて実施され、ソフトウェアは、ファームウェア、常駐ソフトウェア、マイクロコード等を含むが、これらに限定されない。

【0125】

さらに、本発明の実施形態は、コンピュータ、処理デバイス、又は任意の命令実行システムによる、又はこれらに関連した使用のためのプログラムコードを提供するコンピュータ使用可能又はコンピュータ可読媒体からアクセス可能なコンピュータプログラム製品の形式を取ることができる。本明細書において、コンピュータ使用可能又はコンピュータ可読媒体は、命令実行システム、装置又はデバイスによる、又はこれらに関連した使用のためのプログラムを収容、記憶、通信、又は送達することができる任意の装置とすることができる。媒体は、電子、磁気、光学、又は半導体システム（又は装置若しくはデバイス）とすることができる。コンピュータ可読媒体の例としては、半導体又はソリッドステートメモリ、磁気テープ、取り外し可能コンピュータディスケット、ＲＡＭ、リードオンリーメモリ（ＲＯＭ）、リジッド磁気ディスク、光学ディスク等が挙げられるが、これらに限定されない。光学ディスクの現在の例として、コンパクトディスクリードオンリーメモリ（ＣＤ－ＲＯＭ）、コンパクトディスクリード／ライト（ＣＤ－Ｒ／Ｗ）及びＤＶＤが挙げられる。

【図1】

【図2】

【図3】