JP6698165B2 - ネットワークの運営方法、該方法で用いるネットワークとオーケストレーター - Google Patents

Description

本発明は、ネットワークのより低いレベルのサービス機能（モジュール）を組み合わせることによってより高いレベルのサービス機能（サービス）を構成し、少なくとも２つのモジュールが当該サービスを提供及び／又は監視及び／又は最適化するためのポリシーに従って対話する、ネットワークの運営方法に関する。本発明はまた、当該方法で用いる対応するネットワーク及びオーケストレーターに関する。

近年、キャリアネットワークという文脈での「サービスファンクションチェイニング」にかなりの注目が向けられてきた。その考え方は、より低いレベルのサービス機能を組み合わせる、すなわち、「チェイニングする」ことにより、より高レベルのサービスを構成するというものである。一例として、ユーザ側から順にペアレンタルコントロール機能、映像変換機能、及びキャッシュをチェイニングする映像配信サービスがあげられよう。ＮＡＴ（Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｉｏｎ：“ネットワークアドレストランスレーション”）やファイアウォールなどの一般的なネットワークサービス機能を加えるとより大きな“サービス機能チェーン”になる。

明白なことに、これらのサービス機能は完全に相互に隔離されており、連続してそれらを通過するトラフィックのデータプレーンを介してのみ対話する。ただし、通常、機能間でより密接な対話を行ってもよい。“サービス指向アーキテクチャ”空間において、このことが長い間提案されてきた。そこでは、各サービスが他の（すなわち、ウェブ）サービスによって呼び出し可能な公共ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ：“アプリケーションプログラミングインタフェース”）を公開し、ＢＰＥＬ（Ｂｕｓｉｎｅｓｓ Ｐｒｏｃｅｓｓ Ｅｘｅｃｕｔｉｏｎ Ｌａｎｇｕａｇｅ：“ビジネスプロセス実行言語”）などのオーケストレーション言語が個々のウェブサービスが呼び出されるシーケンス及び制御論理を定義することにより、より高いレベルのサービスを構成する。本発明では、より低いレベルのサービスを「モジュール」と呼び、モジュールはより高いレベルサービスに構成できる。より高いレベルのサービスを以後単に「サービス」と呼ぶ。

このようなモジュールサービスの利点の１つは、個々のモジュールを独立してスケーリングでき、インフラストラクチャの中で種々の物理マシンに再配置できることである。これは、各モジュールは同一の物理マシン上でのコロケーションが可能だが、ローカルエリアネットワークにより又はワイドエリアネットワークによっても分割可能であることを意味する。あるサービスの２つ以上のモジュールが物理的に分割された状態で対話する場合、当該対話は、“遠隔手続き呼出し”（Ｒｅｍｏｔｅ Ｐｒｏｃｅｄｕｒｅ Ｃａｌｌ：ＲＰＣ）や“レプリゼンテーショナルステートトランスファー”（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒ：ＲＥＳＴ）呼び出しなどのネットワーク通信によって行う必要がある。モジュール同士が高レイテンシの、又は輻輳したネットワーク上で大量に対話した場合、サービス全体のパフォーマンスが悪影響を受けることは明らかである。ところが、サービス開発者はサービスをコンパイル中、インフラストラクチャにおける各モジュールの最終的な配置を認識していない、また認識したいとも思わない。そのため、（サービス品質の向上につながる）モジュール対話の粒度とモジュール間通信のパフォーマンスとの間で妥当なトレードオフがなされるようにサービスを設計することができない。従って、サービス開発者は各モジュールがコロケーションされてモジュール間で粒度の高い対話が行われる、又は各モジュールが「ある程度」物理的に分割されて相互の対話量が制限されることを想定しなくてはならない。都合の悪いことに、“サービス指向アーキテクチャ”マイクロサービス又は“サービスファンクションチェーニング”の考え方が各モジュールはランタイムに再配置可能ということであるため、実際のデプロイの前にモジュールの配置を知ることができない。これは、一度低レイテンシのローカルソケット接続だったものが、サービス寿命中に高遅延のワイドエリアネットワーク接続に容易に変わりうることを意味する。

“サービスファンクションチェーニング”の３つの例を以下に説明する。

例１：ＶｏＩＰサーバーＶＮＦ（Ｖｉｒｔｕａｌ Ｎｅｔｗｏｒｋ Ｆｕｎｃｔｉｏｎ：“仮想ネットワーク機能”）は、セッション毎の連続パケットと使用コデックのロスである、パケットロスを明らかにするためにＡＰＩを提供する。ＶＮＦ、例えば、Ｎａｇｉｏｓは、特定の経路に沿ったレイテンシとジッター測定値を明らかにするためにＡＰＩを提供する。ＶｏＩＰコントロールアプリは、異なるＶｏＩＰセッションの“平均オピニオン評点”（Ｍｅａｎ Ｏｐｉｎｉｏｎ Ｓｃｏｒｅ：ＭＯＳ）を算定するためにＶｏＩＰサーバーＶＮＦ及び監視ＶＮＦにアクセスする。ＶｏＩＰコントロールアプリがＶｏＩＰサーバーとプローブにどのくらい近いかによって、ＶｏＩＰコントロールアプリは限られたＫＰＩ（Ｋｅｙ Ｐｅｒｆｏｒｍａｎｃｅ Ｉｎｄｉｃａｔｏｒ：重要業績評価指標）のみを求め、大まかなＭＯＳ近似値となってしまう他のＫＰＩ、例えば、サーバーからのパケットロスＫＰＩやＮａｇｉｏｓからのレイテンシを無視する。若しくは、例えば、１／秒から１／分までのポーリング周波数を適応させる、若しくは一層表現豊かなＭＯＳ計算値を求めるために全てのＫＰＩを求める。

例２：“ＲＡＮ（Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ：無線アクセスネットワーク）コントローラーＶＮＦ”と“バックホールコントローラーＶＮＦ”（これらはＲＡＮ／ＢＨ全体のコントローラーである必要はなく局所的コントローラーであればよい）が離れている場合、それらは負荷閾値に基づいて相互動作する、すなわち、緊急に何かを行う必要がある（例えば、特定のＲＡＮセルが輻輳した又はバックホールが輻輳した）ときだけ、これらのコントローラーは共通の解決法を見つけるために相互に通信する。その際、“ＲＡＮコントローラーＶＮＦ”と“バックホールコントローラーＶＮＦ”は影響を受けたＲＡＮ箇所についての総負荷ＫＰＩをやりとりするだけの場合もある。別の極端なケースでは、“ＲＡＮコントローラーＶＮＦ”と“バックホールコントローラーＶＮＦ”は、どのＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ：“ユーザ装置”）を他のサイトにハンドオーバーするか、どのようにアンテナの傾斜角度、ｅＮＢのパワーレベルなどを変更するか、又はＵＥ毎の最適なエンド−ツーエンドパフォーマンスに達するためにどのようにバックホールにおけるトンネルの経路又はトンネルの大きさを再設定するかを決めるために継続的かつ複雑な交渉を行うことがある。

例３：ネットワークの異なる箇所にあるプローブＶＮＦのセットがそれぞれのデータプレーンからランダムなパケットのコピーを作り、それらをＩＤＳ（Ｉｎｔｅｌｌｉｇｅｎｔ Ｄｅｃｉｓｉｏｎ Ｓｙｓｔｅｍ：“インテリジェントディシジョンシステム”）システム又は分析エンジンに送る。プローブとＩＤＳ ＶＮＦがどのくらい近いかによって、実際のデータセッションのサンプリングレートが変わる場合があり、またそのようなサンプリングレートによってＩＤＳの正確さが変わる場合がある。

“サービスファンクションチェーニング”を用いた公知のネットワーク運用方法及び対応するネットワークには柔軟性と効率性が不足している。

従って、本発明の目的は、簡単かつ確実にネットワークの運用方法と対応するネットワークを改善及び発展させて効率性と柔軟性を高めることである。

本発明によれば、前記目的は、ネットワークの運用方法であって、
前記ネットワークのより低いレベルのサービス機能（モジュール）を組み合わせることによってより高いレベルのサービス機能（サービス）を構成し、
少なくとも２つのモジュールが前記サービスを提供、及び／又は監視、及び／又は最適化するためのポリシーに従って対話し、
前記モジュールは、ランタイム中に位置及び／又は近接性の認識及び前記ポリシーによって
モジュール間対話の量及び／又は種類、及び／又は
少なくとも１つの他のモジュールの位置
を決定及び／又は変更するために少なくとも１つの他のモジュールに対する位置及び／又は近接性を認識している、ネットワークの運用方法により達成される。

また、前記目的は、ネットワークであって、
前記ネットワークのより低いレベルのサービス機能（モジュール）を組み合わせることによってより高いレベルのサービス機能（サービス）を構成し、
少なくとも２つのモジュールが前記サービスを提供、及び／又は監視、及び／又は最適化するためのポリシーに従って対話するように設計され、
前記モジュールは、ランタイム中に位置及び／又は近接性の認識及び前記ポリシーによって
モジュール間対話の量及び／又は種類、及び／又は
少なくとも１つの他のモジュールの位置
を決定及び／又は変更するために少なくとも１つの他のモジュールに対する位置及び／又は近接性を認識している、ネットワークにより達成される。

また、上記方法において用いられるオーケストレーターであって、前記オーケストレーターは前記モジュールに前記認識を提供するように設計され、前記オーケストレーターは様々な前記モジュールの個々の動作点を認識しており、前記オーケストレーターは前記ネットワーク内の前記個々の動作点に基づいて前記モジュールを配置する、オーケストレーターが請求される。

本発明によれば、少なくとも１つの他のモジュールに対する位置及び／又は近接性を認識しているモジュールによる“サービスファンクションチェーニング”を用いて非常に効率的で柔軟性のあるネットワーク運用方法を提供できることが確認された。この認識は、ランタイムにおけるモジュール間の対話の量及び／又は種類の決定及び／又は変更、及び／又は少なくとも１つのモジュールの位置の決定及び／又は変更のために用いることができる。近接したモジュールは相互の粒度の高い対話を選択でき、一方遠隔したモジュールは粒度の低い対話又はまったく対話しないことを選択できる。そのような決定及び／又は変更は、位置及び／又は近接性と上記ポリシーによって決まる。

このように、少なくとも１つの他のモジュールに対する位置及び／又は近接性を認識しているモジュールを単に提供することにより、ネットワーク運用方法の効率性と柔軟性を簡単かつ確実に高めることができる。

図１は本発明の実施形態によるネットワーク構造を示す図である。

本発明の実施形態によれば、前記認識は基本ミドルウェアにより可能に又は提供されてもよく、若しくはハイパーバイザー層の一部であってよく、若しくはレイテンシ又はモジュール間測定によってモジュール自体により取得されてもよい。一般に、各モジュールが位置又は近接性の認識を取得する方法はそのソフトウェアのエコシステムに依存しうる。

更なる実施形態によれば、前記認識はオーケストレーター又はサービスオーケストレーター機能により前記モジュールに付与又は提供してもよい。そのようなオーケストレーター又はサービスオーケストレーター機能により、各モジュールの効率的かつ柔軟な管理、及び各モジュールによる位置及び／又は近接性認識が実現できる。

更なる実施形態において、前記認識は前記モジュールに各モジュールのＡＰＩプリミティブを介して送信してもよい。この実施形態により前記認識が各モジュールへ非常に簡単かつ確実に送信される。

更なる実施形態によれば、位置情報又は近接性情報はメトリックで表してもよい。ただし、位置情報又は近接性情報を表す他の手段も考えられる。

更なる実施形態によれば、近接性情報はモジュール間のレイテンシ、ホップ数、又はネットワーク帯域幅で表してもよい。請求された方法やネットワークで用いられる位置情報又は近接性情報を表す場合種々の好適な手段が考えられる。

更なる実施形態によれば、前記サービスはモバイルエッジコンピューティング（Ｍｏｂｉｌｅ Ｅｄｇｅ Ｃｏｍｐｕｔｉｎｇ：ＭＥＣ）アプリケーションであってもよい。

更なる実施形態において、モジュールはＭＥＣノード上で動作するＲＡＮ認識映像変換モジュールであってもよい。そのようなモジュールはＭＥＣインターフェースを介してローカルＲＡＮ情報にアクセス可能である。

更なる実施形態によれば、オーケストレーター又はサービスオーケストレーター機能は様々な前記モジュールの個々の動作点を認識していてもよい。動作点はモジュール間の近接性と「利点メトリック」との間の依存関係宣言と定義することができ、「利点メトリック」とはモジュール間対話の粒度により規定される予想モジュールパフォーマンス品質に対する所与の近接性の影響を捕捉するものである。

更なる実施形態において、前記モジュールは少なくとも１つの他のモジュールに対する位置及び／又は近接性に基づいてそれぞれの動作点を適応させてもよい。モジュールはその動作点を記憶装置の中に保存することができる。

更なる実施形態によれば、前記適応は、前記モジュールが“ステートパターン”により及びその様々な動作点に対しステートマシンを維持することにより実行してもよく、あるモジュールの内部ステートマシンは前記モジュールの別のモジュール又はその他のモジュールまでの近接性によって更新してもよい。

更なる実施形態において、モジュールはその内部状態によって既定の動作を実行してもよい。そのような動作はあるＲＡＮ情報を取得することであってもよい。

更なる実施形態によれば、モジュール間の対話は、個々のアプリケーションやアプリケーションの分野に依存しうる適切な方法でネットワーク通信により可能にされてもよい。

本発明の実施形態は、サービスグラフ内のモジュールを近接性認識させることができ、各モジュールはこの近接性情報を用いてそれぞれの動作点、すなわち、サービスグラフ内の隣接するモジュールとのネットワーク通信の量及び／又は粒度を適応させることができる、方法及びシステム又はネットワークを提供する。

前記方法及びネットワークの実施形態によれば、前記サービスグラフの仕様は、モジュール間のリンクが主として対話依存関係を表すようなものであってもよい。このような仕様は、例えば、オーケストレーターがモジュール配置に関してパレート最適な決定をすることができるように、種々の動作点、すなわち、所定の「近接性メトリック」に依存する「利点メトリック」を明らかにすることができる。そのようなオーケストレーターは、配置に関する決定をする際サービスグラフ内の種々の動作点を考慮してもよい。

更なる実施形態において、前記オーケストレーターは前記ネットワークの物理インフラストラクチャを横切ってモジュールを配置してもよい。また、各モジュールはサービスグラフ内の様々な隣接するモジュールへの近接性を知っていてもよい。決定した近接性値に基づいて、各モジュールはそれぞれの動作点を適応させてもよい。

従来技術では、通信対話の粒度をサービス設計時に固定する必要がある。本発明の実施形態では、この粒度をランタイム中に動的に変更できる。このことは、仮想モジュール（ＶＮＦ）をランタイム中に動的に再配置できる“ネットワーク機能仮想化”（Ｎｅｔｗｏｒｋ Ｆｕｎｃｔｉｏｎ Ｖｉｒｔｕａｌｉｚａｔｉｏｎ：ＮＦＶ）時代に極めて適している。

本発明の内容を有利に設計し発展させる方法がいくつもある。そのため、図に示された本発明の実施形態の例についての以下の説明を参照されたい。

本発明の実施形態では、各モジュールが別のモジュールに対する位置及び／又は近接性を認識するようにされ、この認識を用いてランタイムにおけるモジュール間対話の量を決定する。また変更する場合もある。近接したモジュールは多くのＲＰＣを用いた粒度の高い相互の対話を選択し、一方遠隔したモジュールは粒度の低い対話又はまったく対話しないことを選択することになろう。依存関係グラフ内で隣接モジュールとの対話がない中でそれぞれの仕事を履行するために、各モジュールは、他のモジュールがより近接していた場合などに正確に提供できたであろうコンテキスト変数についての自身の測定や見積もりに基づいて自立的行為に訴えなければならないであろう。本発明によれば、対話の粒度の高低がサービスのランタイム中にモジュール配置の変動により変動する場合がある。

実際のデプロイ又は実施形態では、各モジュールが位置又は近接性の認識を得る方法はそのソフトウェアのエコシステムに依存する。それらの認識は、例えば、ＣＯＲＢＡやその後継機種などの基本ミドルウェアにより可能にされてもよく、若しくは、“Ｊａｖａリモートメソッドインボケーション”の場合、Ｊａｖａ ＶＭなどのハイパーバイザー層の一部であってもよく、若しくは、レイテンシや他のモジュール間測定によってモジュール自体により取得されてもよく、若しくは、ＮＦＶＯ（“ＮＦＶ Ｏｒｃｈｅｓｔｒａｔｏｒ”）がこの命令をＶＮＦＭ（“ＶＮＦ Ｍａｎａｇｅｒ”）を介して出すＥＴＳＩ ＮＦＶアーキテクチャにおいてサービスオーケストレーター機能により各モジュールに提供してもよい。本発明はこの認識を得る厳密な方法について何ら制約を設けないが、説明のために、以後、認識はオーケストレーターにより生成され各モジュールに信号で送信されるものとする。位置情報又は近接性情報は種々のメトリックで表すことができる。近接性はモジュール間のレイテンシで表すことができ、ホップ数、ネットワーク帯域幅、その他のメトリックで表すこともできる。

図１において、モジュールＢ、Ｃはコロケーションされている。これらのモジュールはこのことを、例えば、各モジュールの専用ＡＰＩプリミティブを介してオーケストレーターからの通知により認識しているので、場合によっては多くのＲＰＣを含む、高粒度の協同モードを用いることになろう。モジュールＢ、ＣはともにモジュールＡとの対話依存関係も有しているが、対話は粒度の低いものになる可能性が高い。これは、モジュールＡは高速ネットワーク接続によって接続されているが、異なる物理マシン、すなわち、“ノード１”の上に配置されているからである。モジュールＣ、Ｄは低速ネットワーク接続によって接続されているので、一層低い対話粒度を選択する可能性が高い、又はまったくＲＰＣ対話を持たなくなって純粋なデータプレーン転送の関係になる場合もある。

本発明の実施形態とともに用いられる周知の例として、ＲＡＮ認識映像変換モジュールなどの“モバイルエッジコンピューティング”（Ｍｏｂｉｌｅ Ｅｄｇｅ Ｃｏｍｐｕｔｉｎｇ：ＭＥＣ）アプリケーションがある。このようなモジュールがＭＥＣノード上で動作する場合、ＭＥＣインターフェースを介してローカルＲＡＮ情報にアクセスすることになる。オーケストレーターが当該変換モジュールをＲＡＮから離れた場所に、例えば、アグリゲーションネットワークコンピュートノードに配置することに決定した場合、このモジュールは通常、遠隔のＭＥＣインターフェースへのアクセスが限られてしまうか（限られたＲＡＮ情報を更にアグリゲーションネットワークに流すという提案が一部の事業者によってなされている）、アプリレベルの遅延監視などの何らかのＲＡＮ測定を自ら行わなくてはならなくなるか、ローカルなＴＣＰスタック情報へのアクセスなどのＲＡＮ不可知的方法を実行しなくてはならなくなるであろう。この例から、モジュール間の近接性、ここでは変換モジュールとＭＥＣ“モジュール”との近接性がどのように種々の動作点、すなわち、対話の種々の粒度になるかが明らかに理解できよう。

オーケストレーターが情報を得た上で配置に関する決定を行うには、様々なモジュールの種々の動作点を認識していなければならない。この文脈での動作点は、モジュール間の近接性と「利点メトリック」との間の依存関係宣言と定義され、「利点メトリック」とはモジュール間対話の粒度により規定される予想モジュールパフォーマンス品質に対する所与の近接性の影響を捕捉するものである。そのため、サービスグラフ、すなわち、サービス実行のためにオーケストレーターにハンドオーバーされるサービス仕様において、これらの動作点はモジュール間のリンク毎に明確化されなくてはならない。

位置又は近接性を認識しているだけで十分とは言えない。各モジュールは更に、この情報に基づいて動作可能、すなわち、この情報に適応可能でなければならない。１実施形態として、これをいわゆる“ステートパターン”によって行ってもよい（https://en.wikipedia.org/wiki/State_patternを参照）。すなわち、各モジュールがそれぞれの動作点についてステートマシンを維持する。あるモジュールの内部ステートマシンはサービスグラフ内の当該モジュールの他の隣接モジュールへの近接性によって更新され、各モジュールはそれぞれの内部状態に従って別々に上記例における特定のＲＡＮ情報の取得などの特定の動作を行う。

ここで説明した本発明の変形例や他の実施形態が、本発明が関係し上記の説明や添付の図面に示された内容の恩恵を受ける当業者により想到されよう。従って、本発明は開示された特定の実施形態に限定されるべきではなく、変形例や他の実施形態が添付の特許請求の範囲に含まれることが意図されていると理解すべきである。ここでは特定の用語が使われているが、それらは限定する目的ではなく一般的及び説明的意味で使われている。

Claims (13)

1. ネットワークの運用方法であって、
   前記ネットワークのより低いレベルのサービス機能（モジュール）を組み合わせることによってより高いレベルのサービス機能（サービス）を構成し、
   少なくとも２つのモジュールが前記サービスを提供、及び／又は監視、及び／又は最適化するためのポリシーに従って対話し、
   前記モジュールは、ランタイム中に位置及び／又は近接性の認識及び前記ポリシーによって
   モジュール間対話の量及び／又は種類
   を決定及び／又は変更するために少なくとも１つの他のモジュールに対する位置及び／又は近接性を認識し、
   前記認識はオーケストレーター又はサービスオーケストレーター機能により前記モジュールに付与され、
   前記オーケストレーター又はサービスオーケストレーター機能が複数の前記モジュールの個々の動作点を認識しており、動作点はモジュール間の近接性と「利点メトリック」との間の依存関係宣言であり、「利点メトリック」は予想モジュールパフォーマンス品質に対するモジュール近接性の影響を捕捉するものであり、前記動作点はサービスグラフにおいてモジュール間のリンク毎に明確化され、サービスグラフはサービス実行のために前記オーケストレーターにハンドオーバーされるサービス仕様であり、前記サービス仕様においてはモジュール間のリンクが対話依存関係を表し、これにより、各モジュールはそれぞれの動作点についてモジュール内部ステートマシンを維持し、前記モジュール内部ステートマシンは前記サービスグラフ内の当該モジュールの他の隣接モジュールへの近接性によって更新される、ネットワークの運用方法。
2. 前記認識は基本ミドルウェアにより可能にされる又は提供される、若しくはハイパーバイザー層の一部である、若しくはレイテンシ又はモジュール間測定により前記モジュール自体により取得される、請求項１に記載の方法。
3. 前記認識は前記モジュールに各モジュールのＡＰＩプリミティブを介して送信される、請求項１又は２に記載の方法。
4. 位置情報又は近接性情報はメトリックで表される、請求項１〜３のいずれかに記載の方法。
5. 近接性情報はモジュール間のレイテンシ、ホップ数、又はネットワーク帯域幅で表される、請求項１〜４のいずれかに記載の方法。
6. 前記サービスはモバイルエッジコンピューティング（ＭＥＣ）アプリケーションである、請求項１〜５のいずれかに記載の方法。
7. モジュールはＭＥＣノード上で動作するＲＡＮ認識映像変換モジュールである、請求項１〜６のいずれかに記載の方法。
8. 前記モジュールは少なくとも１つの他のモジュールに対する位置及び／又は近接性に基づいてそれぞれの動作点を適応させる、請求項１〜７のいずれかに記載の方法。
9. 前記適応は、前記モジュールがステートパターンによりかつそれぞれの様々な動作点に対してステートマシンを維持することにより実行され、あるモジュールの内部ステートマシンは該モジュールの別のモジュール又はその他のモジュールまでの近接性により更新される、請求項８に記載の方法。
10. モジュールはその内部状態により既定の動作を実行する、請求項１〜９のいずれかに記載の方法。
11. モジュール間の対話はネットワーク通信により可能にされる、請求項１〜１０のいずれかに記載の方法。
12. 請求項１〜１１のいずれかに記載のネットワークの運用方法を実行するためのネットワークであって、前記ネットワークのより低いレベルのサービス機能（モジュール）を組み合わせることによってより高いレベルのサービス機能（サービス）を構成し、
    少なくとも２つのモジュールが前記サービスを提供、及び／又は監視、及び／又は最適化するためのポリシーに従って対話するように設計され、
    前記モジュールは、ランタイム中に位置及び／又は近接性の認識及び前記ポリシーによって
    モジュール間対話の量及び／又は種類
    を決定及び／又は変更するために少なくとも１つの他のモジュールに対する位置及び／又は近接性を認識している、ネットワーク。
13. 請求項１〜１１のいずれかに記載の方法において用いられるオーケストレーターであって、前記オーケストレーターは前記モジュールに前記認識を提供するように設計され、前記オーケストレーターは様々な前記モジュールの個々の動作点を認識しており、前記オーケストレーターは前記ネットワーク内の前記個々の動作点に基づいて前記モジュールを配置する、オーケストレーター。