JP2022054417A - エッジ環境における作業負荷配置のための方法、装置および製造物 - Google Patents

Abstract

【課題】エッジ環境における作業負荷配置のための方法、装置、システム及び製造物を提供する。【解決手段】エッジ環境において、作業負荷配置のための装置は、エッジ環境内のエッジ・プラットフォームから作業負荷を実行する要求を受信するオーケストレータと、エッジ・プラットフォームからの作業負荷についての動作パラメータを決定するために要求を解析し、動作パラメータに基づいて候補エッジ層及びエッジ・プラットフォーム配置を解析する機能コントローラとを含んでいる。オーケストレータは、動作パラメータを満たす候補エッジ層及びエッジ・プラットフォーム配置に基づいて作業負荷のための候補エッジ層及びエッジ・プラットフォーム配置を決定する。【選択図】図３

Description

本開示は、概括的にはエッジ環境に関し、より詳細には、エッジ環境における作業負荷配置のための方法、装置、および製造物に関する。

エッジ環境（たとえば、エッジ、ネットワークエッジ、フォッグコンピューティング、マルチアクセス・エッジ・コンピューティング（multi-access edge computing、MEC）、またはモノのインターネット（IoT）ネットワーク）は、作業負荷実行（たとえば、一つまたは複数のコンピューティングタスクの実行、入力データを使用する機械学習モデルの実行など）を、その作業負荷の実行を要求するエンドポイント装置の近く、またはより近くで可能にする。エッジ環境は、インターネットのようなネットワークを介してクラウドインフラストラクチャー、エンドポイント装置、または追加のエッジインフラストラクチャーに接続されるエッジ・サービスのようなインフラストラクチャー（たとえば、ネットワークインフラストラクチャー）を含んでいてもよい。エッジ・サービスは、中央集中化されたサーバーなどのクラウドインフラストラクチャーよりも、エンドポイント装置に近接していることがありうる。

本開示の教示による、エッジ・サービスおよびアプリケーションを提供するための例示的なエッジ・コンピューティング・システムを示す。

本開示の教示による、クライアント計算ノードから受信された要求を処理するためのエッジ・プラットフォームの例示的実装を示す。

作業負荷のための候補エッジ層およびエッジ・プラットフォーム配置を決定するよう図2および／または図3の例示的なオーケストレータを実装するために実行されうる例示的な機械読み取り可能命令を表わすフローチャートである。

エッジ・プラットフォームにおいて実装される作業負荷の動作パラメータを決定するために要求を解析するよう図2および／または図3の例示的なオーケストレータを実装するために実行されうる例示的な機械読み取り可能命令を表わすフローチャートである。

動作パラメータに基づいて候補エッジ層およびエッジ・プラットフォーム配置を解析するよう図2および／または図3の例示的なオーケストレータを実装するために実行されうる例示的な機械読み取り可能命令を表わすフローチャートである。

作業負荷のための候補エッジ層およびエッジ・プラットフォーム配置を決定するよう図2および／または図3の例示的なオーケストレータを実装するために実行されうる例示的な機械読み取り可能命令を表わすフローチャートである。

図2のオーケストレータを実装するために、図3の命令を実行するように構成された例示的な処理プラットフォームのブロック図である。

ソフトウェア（たとえば、図3～図6の例示的なコンピュータ読み取り可能命令に対応するソフトウェア）をクライアント装置、たとえば消費者（たとえば、ライセンス、販売および／または使用についての）、小売業者（たとえば、販売、再販売、ライセンスおよび／またはサブライセンスについての）、および／またはオリジナル機器製造業者（original equipment manufacturer、OEM）（たとえば、小売業者および／または直接購入顧客に配送される製品に含めるための）に配布するための例示的なソフトウェア配布プラットフォームのブロック図である。

本開示の教示による、エッジ・コンピューティングのためのエッジ・クラウド構成の概観を示す。

本開示の教示による、エンドポイント、エッジ・クラウド、およびクラウド・コンピューティング環境の間の動作レイヤーを示す。

本開示の教示による、エッジ・コンピューティング・システムにおけるネットワーキングおよびサービスのための例示的な環境のブロック図を示す。

本開示の教示による、複数のエッジ・ノードと複数のテナントとの間で動作するエッジ・コンピューティング・システムにおける仮想エッジ構成の展開を示す。

本開示の教示による、エッジ・コンピューティング・システムにおいてコンテナを展開するさまざまな計算構成を示す。

本開示の教示による、例示的なエッジ・コンピューティング・システムにおけるアプリケーションへのモバイルアクセスに関わる例示的な計算・通信使用事例を示す。

本開示の教示による、図9～図12および／または図14に示されるエッジ・コンピューティング・システムのうちの1つにおいて展開されうる例示的な計算ノードの例示的な実装のブロック図である。

本開示の教示による、図9～図12および／または図14に示されるエッジ・コンピューティング・システムのうちの1つにおいて展開されうる例示的な計算ノードの例示的な実装の別のブロック図である。

図面は縮尺通りではない。一般に、同じまたは同様の部分を参照するために、図面および添付の書面による説明を通じて、同じ参照番号が使用される。接続への言及（たとえば、取り付けられた、結合された、接続された、つながれた）は、広義に解釈されるべきであり、特に断らない限り、要素の集まりの間の中間部材および要素間の相対的な動きを含んでいてもよい。よって、接続への言及は、必ずしも2つの要素が直接接続され、互いに固定した関係にあると推定するわけではない。

特に断らない限り、「第1」、「第2」、「第3」等の記述子は、優先順位、物理的順序、リスト内の配列、および／または任意の仕方での順序付けのいかなる意味ももたせたり、あるいは他の仕方で示すことなく、本明細書において使用され、単に、開示された例を理解しやすくするために要素を区別するためのラベルおよび／または任意の名称として使用される。

エッジ・コンピューティングは、一般的なレベルでは、エンドポイント装置（たとえば、消費者のコンピューティング装置、ユーザー機器など）のより近くへの、計算および記憶資源の移行を指し、総所有コストを最適化し、アプリケーション・レイテンシーを短縮し、サービス機能を改善し、データのプライバシーまたはセキュリティ要件の遵守を改善するために採用される。エッジ・コンピューティングは、いくつかのシナリオでは、多くのタイプの記憶および計算資源の間でアプリケーションのためのオーケストレーションおよび管理を提供するクラウド様の分散式サービスを提供する。結果として、エッジ・コンピューティングのいくつかの実装は「エッジ・クラウド」または「フォグ」と呼ばれている。これは、これまで大規模なリモートデータセンターでのみ利用可能であった強力な計算資源が、エンドポイントのより近くに移され、ネットワークの「エッジ」において消費者による使用のために利用可能にされるためである。

「モバイルエッジ・コンピューティング」としても知られるマルチアクセス・エッジ・コンピューティング（multi-access edge computing、MEC）アプローチと統合するために、モバイルネットワーク場面におけるエッジ・コンピューティングの使用事例が開発された。MECアプローチは、アプリケーション開発者およびコンテンツ提供者が、動的モバイルネットワーク場面において、ネットワークのエッジにおいてコンピューティング機能および情報技術（IT）サービス環境にアクセスできるようにするために設計された。MECシステム、プラットフォーム、ホスト、サービス、およびアプリケーションの動作のための共通インターフェースを定義する試みにおいて、欧州電気通信標準化機構（ETSI）業界仕様グループ（ISG）によって、限定された規格が開発されている。

エッジ・コンピューティング、MEC、および関連技術は、伝統的なクラウドネットワーク・サービスや広域ネットワーク接続において提供されるものよりも、短縮されたレイテンシー、向上した応答性、およびより可用性の高いコンピューティングパワーを提供しようとする。しかしながら、移動性と動的に立ち上げられるサービスを、いくつかのモバイル使用および装置処理使用事例に統合したことで、特に多くの参加者（たとえば、装置、ホスト、テナント、サービス・プロバイダー、オペレーターなど）が関与する複雑な移動性場面において、オーケストレーション（orchestration）、機能調整（functional coordination）、および資源管理に関する制限および懸念をもたらした。

同様に、モノのインターネット（IoT）ネットワークおよび装置は、多様なエンドポイントから分散式計算構成を提供するように設計される。IoT装置は、ネットワーク上で通信することができる物理的または仮想化されたオブジェクトであってもよく、センサー、アクチュエータ、および他の入出力コンポーネントを含むことができ、それらは、データを収集するため、または現実世界の環境においてアクションを実行するために使用されうる。たとえば、IoT装置は、建物、車両、パッケージ等のような日常のものに埋め込まれるか取り付けられる低電力エンドポイント装置を含み、それらのものの人工的な感覚知覚のさらなるレベルを提供することができる。近年、IoT装置はより一般的になり、これらの装置を使用するアプリケーションが普及している。

いくつかの例では、エッジ環境は企業エッジを含むことができ、企業エッジとの通信および／または企業エッジ内での通信が、無線および／または有線接続を介して促進できる。さまざまなエッジ、フォグ、MEC、およびIoTネットワーク、装置、およびサービスの展開は、ネットワークのエッジおよびエッジ付近で発生する多くの先進的な使用事例およびシナリオを導入した。しかしながら、これらの先進的な使用事例は、数ある問題の中でも、セキュリティ、処理およびネットワーク資源、サービスの可用性および効率に関係するいくつかの対応する技術的課題をももたらした。そのような課題の1つは、エンドポイント装置に代わって作業負荷を実行するエッジ、フォグ、MEC、およびIoTネットワーク、装置、およびサービスに関する。

本願の技法および構成は、現在のネットワーク化されたシステムの多くの側面との関連で利用されうるが、エッジ・クラウド、IoT、マルチアクセスエッジ・コンピューティング（MEC）、および他の分散式コンピューティング展開を参照して提供される。以下のシステムおよび技法は、多様な分散式の、仮想化された、または管理されたエッジ・コンピューティング・システムにおいて実装されてもよく、またはかかるエッジ・コンピューティング・システムを増強してもよい。これらは、ネットワーク・サービスが、マルチアクセスエッジ・コンピューティング（MEC）、第4世代（4G）または第5世代（5G）無線ネットワーク構成を使用して、またはファイバー、銅、および他の接続をに関わる有線ネットワーク構成において、実装または管理される環境を含む。さらに、それぞれのコンピューティングコンポーネントによる処理の諸側面は、スマートフォン、車両通信コンポーネント、IoT装置などのような、ユーザー機器または他のエンドポイント位置と地理的に近接した計算要素に関わっていてもよい。さらに、本開示の技法は、他のエッジ/MEC/IoTネットワーク通信標準および構成、ならびに他の中間処理エンティティおよびアーキテクチャーに関するものであってもよい。

エッジ・コンピューティングは、典型的には、基地局、ゲートウェイ、ネットワーク・ルータ、またはデータを生成し消費するエンドポイント装置にずっと近い他の装置において実装されるコンピューティング・プラットフォームの使用を通じて、ネットワークの「エッジ」において、またはその近くでコンピューティングが実行される発展中のパラダイムである。たとえば、エッジ・ゲートウェイ・サーバーは、接続されたクライアント装置のための低レイテンシーの使用事例（たとえば、自律運転またはビデオ監視）のためにリアルタイムで計算を実行するために、メモリおよび記憶資源のプールを備えていてもよい。あるいは、一例として、基地局は、バックホール・ネットワークを介してデータをさらに通信することなく、接続されたユーザー機器のためのサービス作業負荷を直接処理するために、計算および加速資源で増強されてもよい。あるいは、別の例として、中央オフィス・ネットワーク管理ハードウェアが、仮想化されたネットワーク機能を実行し、接続された装置のためのサービスおよび消費者機能の実行のための計算資源を提供するコンピューティング・ハードウェアで置き換えられてもよい。

エッジ環境は、クラウド環境とエンドポイント環境の間に位置するネットワークおよび／またはネットワークの一部を含む。エッジ環境は、ネットワークのエッジにおける作業負荷の計算を可能にする。たとえば、エンドポイント装置は、クラウド環境における中央サーバーではなく、近くの基地局に作業負荷を計算することを要求してもよい。エッジ環境は、メモリ、記憶資源、および／または処理資源のプールを含むエッジ・プラットフォームを含む。エッジ・プラットフォームは、作業負荷の実行などの計算を、他のエッジ・プラットフォームおよび／またはエッジ・ノードに代わって実行する。エッジ環境は、生産者（たとえば、作業負荷実行者、エッジ・プラットフォーム）と消費者（たとえば、他のエッジ・プラットフォーム、エンドポイント装置）との間の接続を容易にする。

エッジ・プラットフォームは、クラウド環境における中央集中化されたサーバーよりもエンドポイント装置に近接している可能性があるため、エッジ・プラットフォームは、クラウド環境よりも低いレイテンシー（たとえば応答時間）で作業負荷の計算を可能し、一方で、データ、計算要求、および結果の伝送のために被る通信遅延およびネットワーク利用も、クラウド環境に比べて少なくなる。エッジ・プラットフォームはまた、地理的位置またはネットワークトポグラフィーに基づく作業負荷の局所化された実行をも可能にしうる。たとえば、エンドポイント装置は、作業負荷が第1の地理的エリアにおいて実行されることを要求することがあるが、中央集中化されたサーバーは第2の地理的エリアに位置することがありうる。エンドポイント装置は、企業または規制の制約に従うために、第1の地理的エリアに位置するエッジ・プラットフォームによる作業負荷実行を要求することができる。

エッジ環境で実行される作業負荷〔ワークロード〕の例は、自律運転計算、ビデオ監視モニタリング、機械学習モデル実行、およびリアルタイムデータ分析を含む。作業負荷のさらなる例は、メディアストリームの送達および／またはエンコード、広告インプレッション率（impression rate）の測定、メディアストリームにおけるオブジェクト検出、発話分析、資産および／または在庫管理、および拡張現実処理を含む。

エッジ・プラットフォームは、作業負荷の実行と、実行された作業負荷の結果をエンドポイント装置に返すことの両方を、クラウド環境におけるサーバーの応答時間よりも短い応答時間で可能にする。たとえば、エッジ・プラットフォームがクラウド・サーバーよりもネットワーク上のエンドポイント装置の近くに位置している場合、エッジ・サービスは、クラウド・サーバーよりも速くエンドポイント装置からの作業負荷実行要求に応答する可能性がある。エンドポイント装置は、クラウド・サーバーではなく、エッジ・サービスに、時間的制約のある作業負荷の実行を要求してもよい。

さらに、エッジ・プラットフォームは、作業負荷実行の分散と脱中央集中化を可能にする。たとえば、エンドポイント装置は、第1の作業負荷実行および第2の作業負荷実行を要求してもよい。いくつかの例では、クラウド・サーバーが両方の作業負荷実行要求に応答することができる。しかし、エッジ環境では、第1のエッジ・プラットフォームが第1の作業負荷実行要求を実行してもよく、第2のエッジ・プラットフォームが第2の作業負荷実行要求を実行してもよい。

エンドポイント装置の低レイテンシーおよび／または高帯域幅の要求を満たすために、多くの資源（たとえば、ハードウェア資源、ソフトウェア資源、仮想ハードウェアおよび／またはソフトウェア資源など）の利用に関するタイムリーな情報と、それらの資源がエンドポイント装置に課された要求を満たすことができる効率とに基づいて、エッジ・クラウドにおけるオーケストレーション（orchestration）が実行される。そのようなタイムリーな情報は、一般に、テレメトリー（telemetry）（たとえば、テレメトリー・データ、テレメトリー情報など）と呼ばれる。

テレメトリーは、各ハードウェアコンポーネントまたはその一部、仮想マシン（VM）、オペレーティング・システム（OS）、アプリケーション、およびオーケストレータを含む複数の源から生成できる。テレメトリーは、どの資源またはそのどの部分において実行のためにスケジュールされている計算タスクの数、量および／またはタイプと、そのような計算タスクの完了までの予想時間とを、履歴および／または現在の（瞬時のまたはほぼ瞬時の）テレメトリーに基づいて決定するために、オーケストレータ、スケジューラなどによって使用されることができる。たとえば、マルチコア中央処理ユニット（CPU）のコアは、コアおよび／またはより一般的にはマルチコアCPUをサンプリングするパフォーマンス・モニタリング・ユニット（PMU）を使用して、1秒よりも短い時間毎に、千を超える異なる多様な情報を生成することができる。所与のエッジ・プラットフォーム、エッジ・ノード等におけるすべてのそのようなテレメトリーを定期的に集約および処理することは、困難で煩雑なプロセスとなりうる。関心のある顕著な特徴を優先し、テレメトリーからそのような顕著な特徴を抽出して、資源に関連する現在または将来の問題、ストレッサー（stressor）などを同定することは困難である。さらに、負荷のかかる資源から作業負荷をオフロードするための別の資源を識別することは、複雑な作業である。

いくつかのエッジ環境は、データ処理またはビデオ分析機能（たとえばマシンビジョン、自律車両のための画像処理、顔認識検出、視覚的オブジェクト検出など）のような多様な機能またはサービスを実行する資源に関連するテレメトリー・データを得ることを望む。しかしながら、一つまたは複数のビデオ分析機能を含む多くのハイスループット作業負荷は、1ミリ秒未満（または他の比較的短い継続時間）で実行されることがある。そのようなエッジ環境は、プラットフォーム（たとえば、資源プラットフォーム、ハードウェア・プラットフォーム、ソフトウェア・プラットフォーム、仮想化プラットフォームなど）上で実行されるそのような高い粒状性の（highly-granular）ステートレス機能をモニタリングすることができる分散式のモニタリング・ソフトウェアもしくはハードウェア解決策またはそれらの組み合わせを有していない。

多くのエッジ環境は、資源管理およびオーケストレーションのための多様なコンポーネントを含む。

より伝統的な中央集中式のクラウド環境（たとえば、中央オフィス）とは異なる、エッジ・プラットフォーム（たとえば、基地局）における電力および／または熱的な制約を考えれば、エッジ・プラットフォームにおける動的で、知的で、およびテナントごとの電力管理ポリシーが、エッジ・アーキテクチャーに関連する資本支出および／または運用支出を削減および／または回収することができる。たとえば、エッジ・サービス・プロバイダーのエッジ・アーキテクチャーに投資されたすべての機能をマネタイズすることによって、エッジ・プロバイダーは、エッジ・アーキテクチャーの機能に関連する資本支出および／または運用支出を回収することができる。いくつかのエッジ・アーキテクチャーは、太陽エネルギーと風力エネルギーによって電力を受けることができる。エッジ・プラットフォームにおける計算資源および／または熱条件が、可変の再生可能エネルギー（たとえば、太陽光、風力、水力など）によって、および／または制限された容量のバッテリーバックアップを用いて電力供給される場合、サービスのための正確な電力管理を提供できないと、エッジ・プラットフォームの信頼性が低下する可能性がある。さらに、いくつかのエッジ・アーキテクチャーは、安定した電力を有することができるが（たとえば、グリッドに接続されている）、熱的条件のバランスを取ることは、そのようなエッジ・アーキテクチャーにおいては困難であることがある。

オリジナル機器製造業者（OEM）およびシリコンベンダー（silicon vendor）は、分散コンピューティング環境の電力要件および／または電源を考慮しているが、多くは、停電時のサポートのために利用可能な無停電電源装置や発電機を備えた、データセンターのような、連続的で安定して電力供給される環境を想定している。エッジ・プラットフォームのための多くのOEMおよびシリコンベンダー設計は、動的な電力および／または熱的な包絡の下で最適かつ柔軟に動作するためのサポートを欠いている。さらに、エッジ・プラットフォームは、エッジ環境で動作するのではなく、伝統的なコンピューティング環境で動作する場合、異なる電力パフォーマンスの意味合いを持つことがある。

エッジ環境におけるもう一つの課題は、電力だけでなく、エッジ・プラットフォームの弾力性（elasticity）にも関する、限られた供給である。伝統的なデータセンターのようなクラウド実務を、種々のエッジ位置でのアプリケーションのホスティングに拡張する際、考慮すべき要因は次のものを含む：エッジ・プラットフォームでの各作業負荷（たとえばサービス、アプリケーション）に割り当てられる資源の数；ワット当たりの良好なパフォーマンスを得るためにアクセラレータをどこでおよび／またはどのように利用するか、電力消費におけるスパイクを防ぐためにどのサービスをエッジ・プラットフォーム間で移行させるか；さまざまなテナント作業負荷に関連するサービス・レベル合意間で（across service level agreements）電力需要をどのようにバランスさせるか（たとえばポリシーに基づく）。

エッジ環境において生じうる一様でない、予測不可能な需要は、エッジ環境における電力および／または他の資源の非弾力的な供給とともに、ユーザー／テナントのサービス／アプリケーションに電力および／または他の資源を消費させるだけでなく、システム・ソフトウェア・スタックおよびエッジ・プラットフォーム管理コンポーネントにも電力およびハードウェアを消費させる。たとえば、いくつかのエッジ・プラットフォームでは、ソフトウェア・スタックおよびエッジ・プラットフォーム管理コンポーネントは、全体的なエッジ・プラットフォームのフットプリントの30%を利用することがある。

本明細書に開示される例は、エッジ・プラットフォームの作業負荷実行の要求の処理を制御するための、エッジ環境における作業負荷配置のための方法、装置、および製造物を含む。本明細書に開示される例は、エッジ環境内のエッジ・プラットフォームから作業負荷を実行する要求を受信することを含む。本明細書に開示される例は、エッジ・プラットフォームからの作業負荷についての動作パラメータを決定するために前記要求を解析することを含む。いくつかの例では、動作パラメータを決定することは、動作パラメータに必要な要因のサブセットを導出することを含む。いくつかの例では、要因のサブセットは、セキュリティのレベル、精度のレベル、エッジ・プラットフォームの他のマイクロサービスへの依存性、エッジ環境内の依存性の位置、エッジ・プラットフォームの使用情報、またはエッジ・プラットフォームのサービス・レベル合意（service level agreement、SLA）属性を含む。いくつかの例では、動作パラメータを決定することは、エッジ・プラットフォームについての資源要件を推定することを含み、資源要件は、要因の前記サブセットに基づく、作業負荷についての電力測定、熱測定、レイテンシー測定、および／または帯域幅測定を含む。いくつかの例では、資源要件は、更新された動作パラメータに基づいて更新される。

本明細書に開示される例は、動作パラメータに基づいて、作業負荷の候補エッジ層およびエッジ・プラットフォーム配置を解析することを含む。いくつかの例では、候補エッジ層およびエッジ・プラットフォーム配置を解析することは、候補エッジ層およびエッジ・プラットフォーム配置のそれぞれの資源利用可能性を決定することを含む。いくつかの例では、資源利用可能性は、候補エッジ層およびエッジ・プラットフォーム配置のそれぞれからのテレメトリー・データに基づく、候補エッジ層およびエッジ・プラットフォーム配置のそれぞれにおける、電力利用可能性、熱的利用可能性、レイテンシー利用可能性、および／または帯域幅利用可能性に対応する。本明細書に開示される例は、動作パラメータを満足する候補エッジ層およびエッジ・プラットフォーム配置に基づいて、作業負荷についての候補エッジ層およびエッジ・プラットフォーム配置を決定することを含む。いくつかの例では、エッジ・プラットフォームについての候補エッジ層およびエッジ・プラットフォーム配置を決定することは：候補エッジ層およびエッジ・プラットフォーム配置のそれぞれについての動作パラメータ割合を決定し、該動作パラメータ割合はエッジ・プラットフォームの資源要件を満たすエッジ層およびエッジ・プラットフォーム配置の資源利用可能性のパーセンテージに対応し；最適な動作パラメータ割合をもつエッジ層およびエッジ・プラットフォーム配置を、候補エッジ層およびエッジ・プラットフォーム配置として選択し；候補エッジ層およびエッジ・プラットフォーム配置において作業負荷を実行することを含む。いくつかの例では、候補エッジ層およびエッジ・プラットフォーム配置のそれぞれについての動作パラメータ割合が閾値を満足しないことに応答して、資源要件およびコスト関数重みが調整される。本明細書で使用されるところでは、「コスト関数重み」または「コスト関数」とは、作業負荷の配置（placement）および実行（execution）中に正確さおよびセキュリティを確保するために、誤差の大きさ（たとえば、反復工程数）とともに増加するペナルティを指す。

いくつかの例では、コスト関数重みは、候補エッジ層およびエッジ・プラットフォーム配置の選択に、漸進的により保守的になるようにバイアスをかけるために使用される。より保守的とは、より高いコスト関数重みを適用することをいい、これは、たとえばSLAが破られる前に、安全マージンを増加させるためにより多くの資源を割り当てることに対応する。言い換えれば、コスト関数重みは、SLAが破られないことを保証するために、資源のより高い配分を優遇する最適化手順またはモデルにおいて利用される。すなわち、最初の動作が好適な候補エッジ層およびエッジ・プラットフォーム配置を返さなかった（たとえば、SLA閾値を満たさない、電力資源要件を満たさない、など）後、コスト関数および資源要件について、調整された値を用いてもう一回の動作が実行される。本明細書に開示されるいくつかの例では、予想される（projected）SLAの違反がなくなるか、または予想されるレイテンシーおよびスループットがSLAから逸脱するか、または逐次反復のための反復回数または時間の最大を超えるまで、任意の回数の逐次反復が使用されうる。他の例は、上述した逐次反復側面自体がトレーニングされたモデルに統合される、異なる収束フローを使用してもよい。

本明細書に開示される例は、はいってくるテレメトリーと、決定されるエッジ層およびエッジ・プラットフォーム配置決定に基づく、種々のノードの予想される将来の利用とを収集することができる。よって、現在のテレメトリーは、実際の測定値（これは、少量だけ過去に時間シフトされることがありうる）と、進行中の要求配置決定からの予想される利用率の両方からなる。

いくつかの例では、エッジ・サービス・プロバイダーが、先に、好ましいエッジ・プラットフォーム位置でおよび／またはその近くでは十分な資源が利用可能でないと判断した場合、エッジコロケーション（edge co-location、"Co-Lo"）インフラストラクチャーに進入するためのプレミアムコストを支払うことによって、追加の資源を調達することができる。

本明細書に開示されるいくつかの例では、たとえばSLA違反に関する統計が改善するまたは劣化するにつれて、システムが、最適でない解にロックされるのではなく、変化する条件に適応できるようにするため、キャッシュされた結果は周期的にエイジ・アウトされる（aged out）。

いくつかの例では、はいってくる要求および要約されたテレメトリーからのデータが、配置決定の実際の結果（それらがSLA基準を満たすか満たさないかにかかわらず）とともに要約され、バックエンド・クラウドにアップロードされる。それらは、作業負荷タイプ（すなわち、要求タイプ）と量子化されたSLAからパフォーマンス、帯域幅、電力ニーズにマップするモデルをトレーニングするため、またはかかるトレーニングを洗練するために使用される。同様のオフライン・トレーニングが、たとえばコスト関数についてのデフォルト重みを調整するために使用されてもよい。

本明細書に開示される例は、強化学習（re-enforced learning）のような人工知能（AI）目的ベースの技術を用いて拡張できる。たとえば、各サービス毎の生成されたデータおよび没後性能（post-mortem performance）およびテレメトリー・データがAIモデルに提供されることができ、その後、AIモデルが、開示された例を利用して、判断プロセスにおける別の入力をもつことができる。多くの他のタイプのアーキテクチャーと同様に、強化学習は、クラウドのような中央集中化された位置で実装されることができ（そして分散された諸レイヤーにフィードバックされる）、または連合学習（federated learning）アプローチで実装されることができる。後者は、たとえば、エッジ・コンピューティング・システム100の地理的位置または異なる部分に基づいて、より特定的な学習を許容しうる。

本明細書で使用されるところでは、「エッジ・プラットフォーム」とは、エッジ・ゲートウェイ・プラットフォーム、エッジ集約プラットフォーム、フォグ・プラットフォーム（たとえば、クラウドレット）、コア・データセンター、および／またはエッジ環境で実装／実行される作業負荷を指す。本明細書に開示される例では、エッジ・プラットフォームは、ハードウェア、ソフトウェア、ファームウェア、および／またはハードウェア、ソフトウェア、および／またはファームウェアの任意の組み合わせによって実装できる。本明細書に開示される例では、エッジ・プラットフォームは、資源を仮想マシン、ポッド、コンテナなどに組み立てられた計算資産として割り当てのために利用可能にし、組み立てられた仮想マシン、ポッド、コンテナなどを集約およびネットワーキングを通じて作業負荷の実行に向けてプロビジョニングすることによって資源を分配する。

本明細書で使用されるところでは、「作業負荷〔ワークロード〕」とは、クラウドレット（たとえば、一つまたは複数の物理的なプラットフォームにおいて動的にプロビジョンされる仮想化された資源（プロセッサ、メモリ、記憶、加速ユニット）の集合体）上で実行される、さまざまな計算要件、パフォーマンス要件、セキュリティ要件、コスト要件などを有するものとして指定されるアプリケーション・タスクを指す。

本明細書で使用されるところでは、「エッジ・ノード」とは、該エッジ・ノードで実行される作業負荷が必要とする資源をプロビジョンするために割り当てられるプロセッサ、メモリなどを有する、いくつか（1つ、2つ、5つなど）の相互ネットワーク接続されたマシンを指す。本明細書に開示される例では、エッジ・ノードを決定することは、作業負荷を実行するためのエッジ層（edge tier）（近エッジ、遠エッジ、アクセスエッジ、データセンター・クラウドなど）を決定することをも指す。

本明細書で使用されるところでは、「エッジ層配置（edge tier placement）」および「エッジ層およびエッジ・プラットフォーム配置（edge tier and edge platform placement）」とは、エッジ層内のエッジ・プラットフォームにおける作業負荷の配置、および所与の作業負荷のために計算動作を実行する際に使用されるエッジ環境内の資源の選択を指す。

本明細書で使用されるところでは、「最適な動作パラメータ割合（optimal operating parameter percentage）」とは、i）利用可能である、ii）利用可能であり、最も近い、iii）利用可能であり、最も近く、最も安価である、iv）利用可能であり、最も安価であり、十分に近い等のいくつかの望ましい動作パラメータを組み合わせて、それらの望ましい動作パラメータを含む、エッジ層およびエッジ・プラットフォーム配置に関連する割合を決定する関数をいう。

図1は、エッジ・コンピューティング・システム100の諸レイヤーにわたって分散された、一つまたは複数のクライアント計算プラットフォーム102、一つまたは複数のエッジ・ゲートウェイ・プラットフォーム112、一つまたは複数のエッジ集約プラットフォーム122、一つまたは複数のコア・データセンター132、およびグローバル・ネットワーク・クラウド142の間に分散された、エッジ・サービスおよびアプリケーションをマルチステークホルダー・エンティティに提供するための例示的なエッジ・コンピューティング・システム100を示す。エッジ・コンピューティング・システム100の実装は、電気通信サービス・プロバイダー（telecommunication service provider、"telco"または"TSP"）、モノのインターネット・サービス・プロバイダー、クラウド・サービス・プロバイダー（CSP）、企業エンティティ、または任意の他の数のエンティティにおいて、またはそれらに代わって提供されてもよい。エッジ・コンピューティング・システム100の種々の実装および構成は、サービス目的を満たすようにオーケストレーションされるときのように、動的に提供されてもよい。

エッジ・コンピューティング・システム100の個々のプラットフォームまたは装置は、レイヤー120、130、140、150、および160に対応する特定のレイヤーに位置する。たとえば、クライアント計算プラットフォーム102a、102b、102c、102d、102e、102fはエンドポイント・レイヤー120に位置し、エッジ・ゲートウェイ・プラットフォーム112a、112b、112cはエッジ・コンピューティング・システム100のエッジ装置レイヤー130（ローカルレベル）に位置する。さらに、エッジ集約プラットフォーム122a、122b（および／または、フォグ・ネットワーキング構成126と共に、または、その間で配置されるまたは動作させられる場合はフォグ・プラットフォーム124）は、ネットワーク・アクセス・レイヤー140（中間レベル）に位置する。フォグ・コンピューティング（または「フォギング」）とは、一般に、クラウド・コンピューティングの、企業のネットワークのエッジへの拡張、またはクラウド／エッジ・ランドスケープを横断するトランザクションを管理する能力を指し、典型的には、協調された分散式ネットワークまたはマルチノードネットワークで行なわれる。フォグ・コンピューティングのいくつかの形態は、クラウド・コンピューティング位置に代わって、エンド装置とクラウド・コンピューティング・データセンターとの間で、計算、記憶、およびネットワーク・サービスの展開を提供する。フォグ・コンピューティングのいくつかの形態は、全体的なサービス・レベル合意を満たす能力に基づいて、ある種の作業負荷をエッジまたはクラウドにプッシュすることによって、全体的なトランザクションに関して作業負荷／作業フロー・レベル・サービスを管理する能力をも提供する。

フォグ・コンピューティングは、多くのシナリオにおいて、脱中央集中化されたアーキテクチャーを提供し、一つまたは複数のエッジ・ノード装置と協働することにより、クラウド・コンピューティングに対する拡張として機能し、エンド装置のために、ローカライズされた制御、構成、および管理のその後の量ならびにずっと多くを提供する。さらに、フォグ・コンピューティングは、諸エッジ資源が、同様の資源を識別し、単独でまたはクラウド・コンピューティングと連携して、計算、記憶、または接続関連のサービスを完了するために使用されることができるエッジローカルなクラウド（edge-local cloud）を生成するように協働する能力を提供する。フォグ・コンピューティングはまた、クラウドベースのサービスが、諸装置のネットワークのエッジまでそのリーチ範囲を拡張し、エッジ装置へのローカルで、より迅速なアクセス可能性を提供することをも許容しうる。よって、フォグ・コンピューティングのいくつかの形態は、本明細書で論じられるエッジ・コンピューティングと整合する動作を提供し、本明細書で論じられるエッジ・コンピューティングの諸側面は、フォグ・ネットワーク、フォギング、およびフォグ構成にも適用可能である。さらに、本明細書で論じられるエッジ・コンピューティング・システムの諸側面は、フォグとして構成されてもよく、またはフォグの諸側面は、エッジ・コンピューティング・アーキテクチャーに統合されてもよい。

コア・データセンター132は、コア・ネットワーク・レイヤー150（地域的または地理的中央レベル）に位置し、一方、グローバル・ネットワーク・クラウド142は、クラウド・データセンター・レイヤー160（全国的または世界的レイヤー）に位置する。「コア」の使用は、複数のエッジ・プラットフォームまたはコンポーネントによってアクセス可能な、ネットワーク内のより深いところの、中央集中化されたネットワーク位置のための用語として提供されるが、「コア」は、必ずしもネットワークの「中心」または最も深い位置を示すものではない。よって、コア・データセンター132は、エッジ・クラウド110内に、エッジ・クラウド110に、またはエッジ・クラウド110の近くに位置してもよい。図1には、クライアント計算プラットフォーム102a、102b、102c、102d、102e、102f；エッジ・ゲートウェイ・プラットフォーム112a、112b、112c；エッジ集約プラットフォーム122a、122b；エッジ・コア・データセンター132；およびグローバル・ネットワーク・クラウド142の例示的な数が示されているが、エッジ・コンピューティング・システム100は、各レイヤーにおいて任意の数の装置および／またはシステムを含んでいてもよいことを理解しておくべきである。任意のレイヤーの装置は、互いにピア・ノードおよび／またはピア・プラットフォームとして構成されることができ、よって、サービス目標を達成するために協働的な仕方で動作する。たとえば、追加的または代替的な例において、エッジ・ゲートウェイ・プラットフォーム112a、112b、112cは、エッジ・ゲートウェイ・プラットフォーム112a、112b、112cがピアツーピア接続を介して通信するようにエッジのエッジ（an edge of edges）として構成されることができる。いくつかの例では、エッジ集約プラットフォーム122a、122bおよび／またはフォグ・プラットフォーム124は、エッジ集約プラットフォーム122a、122bおよび／またはフォグ・プラットフォームがピアツーピア接続を介して通信するようにエッジのエッジ（an edge of edges）として構成されることができる。さらに、図1に示されるように、それぞれのレイヤー120、130、140、150、および160のコンポーネントの数は、一般に、それぞれのより下位のレベルにおいて（たとえば、エンドポイント（たとえば、クライアント計算プラットフォーム102a、102b、102c、102d、102e、102f）のより近くに進むときに）増大する。このように、1つのエッジ・ゲートウェイ・プラットフォーム112a、112b、112cが、クライアント計算プラットフォーム102a、102b、102c、102d、102e、102fのうちの複数のプラットフォームにサービスすることができ、1つのエッジ集約プラットフォーム（たとえば、エッジ集約プラットフォーム122a、122bの1つ）が、エッジ・ゲートウェイ・プラットフォーム112a、112b、112cのうちの複数のプラットフォームにサービスすることができる。

本明細書で提供される例と整合して、クライアント計算プラットフォーム（たとえば、クライアント計算プラットフォーム102a、102b、102c、102d、102e、102fのうちの1つ）は、データの生産者または消費者として通信することができる任意のタイプのエンドポイント・コンポーネント、装置、機器、または他のものとして実装されることができる。たとえば、クライアント計算プラットフォームは、携帯電話、ラップトップコンピュータ、デスクトップコンピュータ、自律車両内のプロセッサプラットフォームなどを含むことができる。追加的または代替的な例では、クライアント計算プラットフォームは、カメラ、センサー等を含むことができる。さらに、エッジ・コンピューティング・システム100において使用されるラベル「プラットフォーム」、「ノード」、および／または「装置」は、必ずしも、そのようなプラットフォーム、ノード、および／または装置がクライアントまたはエージェント／ミニオン／フォロワーの役割で動作することを意味するのではなく、むしろ、エッジ・コンピューティング・システム100におけるプラットフォーム、ノード、および／または装置のいずれも、エッジ・クラウド110を助けるおよび／または使用するための離散的なおよび／または接続されたハードウェアおよび／またはソフトウェア構成を含む個々のエンティティ、プラットフォーム、ノード、および／またはサブシステムを指す。

このように、エッジ・クラウド110は、それぞれ、エッジ・ゲートウェイ・プラットフォーム112a、112b、112cと、レイヤー130、140のエッジ集約プラットフォーム122a、122bとによって、それらの中で、動作させられるネットワーク・コンポーネントおよび機能的特徴から形成される。エッジ・クラウド110は、図1にクライアント計算プラットフォーム102a、102b、102c、102d、102e、102fとして示されている、無線アクセス・ネットワーク（RAN）対応のエンドポイント装置（たとえば、モバイルコンピューティング装置、IoT装置、スマート装置など）に近接して位置するエッジ・コンピューティングおよび／または記憶資源を提供する、任意のタイプのネットワークとして実装されうる。換言すれば、エッジ・クラウド110は、ストレージおよび／または計算機能をも提供しつつ、エンドポイント装置および伝統的なネットワーク・アクセスポイントを接続し、モバイルキャリアネットワーク（たとえば、グローバル移動通信システム（GSM）ネットワーク、ロングタームエボリューション（LTE）ネットワーク、5G/6Gネットワークなど）を含むサービス・プロバイダー・コア・ネットワークへの入口点として機能する「エッジ」として構想されてもよい。他のタイプおよび形態のネットワーク・アクセス（たとえば、Wi-Fi、光ネットワークを含む長距離の無線、有線ネットワーク）も、そのような3GPPキャリア・ネットワークの代わりに、またはそれと組み合わせて利用されうる。

いくつかの例では、エッジ・クラウド110は、フォグ・ネットワーキング構成126（たとえば、フォグ・プラットフォーム（単数または複数）124のネットワーク；詳細は示されていない）への、またはこれを横切る入口点の一部を形成するか、または他の仕方で該入口点を提供することができ、これは、資源を分散するシステム・レベルの水平および分散アーキテクチャーとして実装されうる。たとえば、エッジ・クラウド100は、資源または機能を、仮想マシン、ポッド、コンテナなどにアセンブルされた計算資産として、割り当てのために利用可能にすることによって、フォグ・ネットワーク構成126への入口点の一部を形成することができる。さらに、エッジ・クラウド110は、アセンブルされた仮想マシン、ポッド、コンテナなどを、集約およびネットワークキングを通じた作業負荷の実行ならびに特定の機能を実行するためのサービスに向けてプロビジョンしてもよい。たとえば、フォグ・プラットフォーム（単数または複数）124の協調された分散ネットワークは、IoTシステム構成の文脈において、計算、記憶、制御、またはネットワーキングの諸側面を実行してもよい。コア・データセンター132とクライアント・エンドポイント（たとえば、クライアント計算プラットフォーム102a、102b、102c、102d、102e、102f）との間で、エッジ・クラウド110において、他のネットワーク接続され、集約され、分散化された機能が存在してもよい。これらのいくつかは、複数のテナントのためにオーケストレーションされる仮想エッジおよび仮想サービスの使用を含む、ネットワーク機能またはサービス仮想化のコンテキストで、以下のセクションで論じられる。

下記でより詳細に論じられるように、エッジ・ゲートウェイ・プラットフォーム112a、112b、112cおよびエッジ集約プラットフォーム122a、122bは協調して、クライアント計算プラットフォーム102a、102b、102c、102d、102e、102fにさまざまなエッジ・サービスおよびセキュリティを提供する。さらに、クライアント計算プラットフォーム（たとえば、クライアント計算プラットフォーム102a、102b、102c、102d、102e、102fのうちの1つ）は、固定または移動可能でありうるので、それぞれのエッジ・ゲートウェイ・プラットフォーム112a、112b、112cは、対応するクライアント計算プラットフォーム102a、102b、102c、102d、102e、102fがある領域のあたりを移動する際に、現在提供されているエッジ・サービス、関連するサービスデータ、およびセキュリティを伝播させるために、他のエッジ・ゲートウェイ・プラットフォームと協働することができる。そうするために、エッジ・ゲートウェイ・プラットフォーム112a、112b、112c、および／またはエッジ集約プラットフォーム122a、122bは、複数テナントおよび複数のテナント構成をサポートすることができ、複数のサービス・プロバイダー、所有者、および複数の消費者からのサービス（またはそれらのためにホストされるサービス）が、単一または複数の計算装置にわたってサポートおよび調整されることができる。

本明細書に開示される例では、エッジ・コンピューティング・システム100内のエッジ・プラットフォームは、メタオーケストレーション機能を含む。たとえば、遠エッジにおけるエッジ・プラットフォーム（たとえば、エッジ・ユーザー、エッジ装置レイヤー130などにより近いエッジ・プラットフォーム）は、遠エッジ・プラットフォームに関連するオーケストレーション・タスクのパフォーマンスまたは電力消費を低減して、遠エッジ・プラットフォームにおけるオーケストレーション・コンポーネントの実行が遠エッジ・プラットフォームにおいて利用可能な電力およびパフォーマンスのわずかな部分を消費するようにすることができる。

さまざまな遠エッジ・プラットフォームにおけるオーケストレータは、エンドツーエンドのオーケストレーション・アーキテクチャーに参加する。本明細書に開示される例は、包括的なオペレーティング・ソフトウェア・フレームワーク（たとえば、オープン・ネットワーク自動化プラットフォーム（open network automation platform、ONAP）または類似のプラットフォーム）が拡張され、またはその中でオプションが創出されることを予期しており、よって、本明細書に開示される例は、それらのフレームワークと互換でありうる。たとえば、本明細書に開示される例を実施するエッジ・プラットフォームのオーケストレータは、ONAPオーケストレーション・フローとインターフェースし、エッジ・プラットフォーム・オーケストレーションおよびテレメトリー活動を促進することができる。本明細書に開示される例を実装するオーケストレータ（orchestrator）は、エッジ・プラットフォームにおいて実行されるオーケストレーションおよびテレメトリー活動を調節するように機能し、かかる調節は、ローカル・オーケストレーション（orchestration）およびテレメトリー・コンポーネントによって消費される電力および／または資源を増加または減少させること、オーケストレーションおよびテレメトリー・プロセスをリモート・コンピュータに委任すること、および／または電力および／または資源が利用可能である場合にリモート・コンピュータからオーケストレーションおよびテレメトリー・プロセスを取り戻すことを含む。

上述したリモート装置は、テレメトリーおよびオーケストレーション・プロセスをオフロードする、エッジ・プラットフォームに関して代替位置に配置される。たとえば、上述したリモート装置は、対照的に、近エッジ・プラットフォーム（たとえば、ネットワーク・アクセス・レイヤー140、コア・ネットワーク・レイヤー150、中央オフィス、ミニデータセンターなど）に配置されることができる。テレメトリーおよび／またはオーケストレーション・プロセスを近エッジ・プラットフォームにおいてオフロードすることにより、近エッジ・プラットフォームにあるオーケストレータは、（比較的）安定した電力供給、および十分な計算資源を保証され、それがテレメトリーおよび／またはオーケストレーション・プロセスの実行を容易にする。近エッジ・プラットフォームにあるオーケストレータ（たとえば、グローバルループに従って動作する）は、遠エッジ・プラットフォームにあるオーケストレータ（たとえば、ローカルループに従って動作する）から委任されたテレメトリーおよび／またはオーケストレーション・プロセスを取ることができる。たとえば、近エッジ・プラットフォームにあるオーケストレータが委任されたテレメトリーおよび／またはオーケストレーション・プロセスを取る場合、近エッジ・プラットフォームにあるオーケストレータは、遠エッジ・プラットフォームにおいて条件が変化すると（たとえば、遠エッジ・プラットフォームにおいてより高いレベルのパワーおよび／または計算資源が利用可能になるなどのため、遠エッジ・プラットフォームにおけるパワーおよび計算資源が閾値レベルを満たすと）、委任されたテレメトリーおよび／またはオーケストレーション・プロセスを遠エッジ・プラットフォームにあるオーケストレータに返すことができる。

エッジ・クラウド110のアーキテクチャー内では、多様なセキュリティ・アプローチが利用されうる。マルチステークホルダー環境では、テナントの利益を含むステークホルダーの利益を強制するポリシーをプロビジョンするために使用される、複数のロード可能セキュリティモジュール（loadable security module、LSM）があることがある。いくつかの例では、他の事業者、サービス・プロバイダー等は、テナントの利益と競合するセキュリティ利害（security interests）を有することがある。たとえば、テナントは、無料で完全なサービス（たとえば、エッジ・プラットフォームによって提供される）を受け取ることを好むことがありうる一方、サービス・プロバイダーは、ほとんど仕事を実行しないこと、またはほとんど費用をかけないことについて、完全な支払いを受けることを望むであろう。強制ポイント環境（enforcement point environment）は、ロードされたLSMポリシーの組み合わせが適用される複数LSM（たとえば、A、B、Cのステークホルダーのいずれかがアクセスを制約すればアクセスが制約されるなど、最も制約された効果的なポリシーが適用される）をサポートすることができる。エッジ・クラウド110内では、各エッジ・エンティティは、エッジ・エンティティの利益を強制するLSMをプロビジョンすることができる。クラウドエンティティは、クラウドエンティティの利益を強制するLSMをプロビジョンすることができる。同様に、さまざまなフォグおよびIoTネットワークエンティティは、フォグ・エンティティの利益を強制するLSMをプロビジョンすることができる。

これらの例では、サービスは、成分レベルで考えられるか人間が知覚可能なレベルで考えられるかによらず、一組の契約または成分（ingredient）に対する、実行される、トランザクションの観点から考えることができる。よって、サービス・プロバイダーとサービス契約を結んでいるユーザーは、SLAの条件の下でサービスが提供されることを期待する。詳細には論じられないが、本明細書で論じられるエッジ・コンピューティング技法の使用は、契約の交渉中および契約の履行の測定中に役割を果たすことがある（たとえば、サービスを実施するためにどんな要素がシステムによって要求されるか、システムがサービス条件および変化にどのように応答するかなどを識別するために）。

さらに、本明細書に開示される例では、エッジ・プラットフォームおよび／またはそのオーケストレーション・コンポーネントは、エッジ環境におけるサービスおよび／またはアプリケーションをオーケストレーションする際に、いくつかの要因を考慮することができる。これらの要因は、次世代の中央オフィス・スマート・ネットワーク機能仮想化およびサービス管理、エッジ・プラットフォームでの電力の制限を克服するためにエッジ・プラットフォームでのおよび／またはオーケストレーション・コンポーネントの、ワット当たりのパフォーマンスを改善すること、オーケストレーション・コンポーネントのおよび／またはエッジ・プラットフォームでの電力消費の低減、管理およびオーケストレーション効率を高めるためのハードウェア利用の改善、物理的なおよび／またはエンドツーエンドのセキュリティの提供、個々のテナントのサービス品質および／またはサービス・レベル合意満足の提供、各使用事例およびテナント・ビジネスモデルについてのネットワーク機器構築システム準拠レベルの改善、加速コンポーネントのプーリング、エッジ環境を改善するための請求およびメータリング・ポリシー、結果の精度の改善、一時的な中断の可能性および継続期間の低減、および他の仕方でユーザー体験の知覚される品質を改善することを含む。

「サービス」とは、しばしばさまざまな状況に適用される広義の用語であるが、一般には、あるエンティティが別のエンティティの利益のために仕事をオファーし、実行するという、2つのエンティティ間の関係を指す。しかしながら、あるエンティティから別のエンティティに提供されるサービスは、ある種のガイドラインをもって実行されなければならず、それが、エンティティ間の信用を保証し、サービスの開始時、期間中、および終了時に規定された契約条件に従ってトランザクションを管理する。

エッジ・コンピューティング・システムで使用されるサービス間の例示的な関係を以下に説明する。エッジ・コンピューティングのシナリオでは、いくつかのサービスと、互いに依存する、動作中の諸トランザクション・レイヤーが存在する。これらのサービスは、「サービスチェーン」を形成する。最低レベルでは、成分（ingredient）がシステムを構成する。これらのシステムおよび／または資源は、互いに、ならびに周囲の他の永続的もしくは過渡的なエンティティに対して多数のサービスを提供するために、互いに通信し、協働する。次いで、これらのエンティティは、人が消費できるサービスを提供することができる。この階層構造（hierarchy）では、サービスを提供する個々のコンポーネント（またはサブエンティティ）が契約上合意された目的および仕様を遵守することを確実にするために、各層（tier）で提供されるサービスがトランザクション的に接続されなければならない。各レイヤー（layer）での逸脱は、サービスチェーン全体に対する全体的な影響をもたらす可能性がある。

エッジ環境の階層構造において提供されうるサービスの1つのタイプは、シリコン・レベル・サービス（Silicon Level Services）である。たとえば、ソフトウェア定義シリコン（Software Defined Silicon、SDSi）タイプのハードウェアは、機能しているサービス・レベル合意の提供をイントラスケールし（intra-scale）、管理し、および保証する能力を通じて、トランザクションへの低レベルの遵守を保証する能力を提供する。SDSiおよび類似のハードウェア制御の使用は、システム内の機能および資源を特定のテナントに関連付け、それらの資源に対する個々の権原（権利）を管理する能力を提供する。そのような機能の使用は、計算資源を作業負荷に動的に「持ち込む」一つの方法である。

たとえば、機能レベル合意および／またはサービス・レベル合意は、「トランザクション・スループット」または「適時性」〔タイムリー性〕を定義することができる。SDSiの場合、システムおよび／または資源は、サービス・レベル合意（SLA）の特定のサービス・レベル仕様（service level specifications）（SLS）およびサービス・レベル目標（objectives）（SLO）を保証するためにサインアップすることができる。たとえば、SLOは、アプリケーション（たとえばサービス、作業負荷など）の特定のキーパフォーマンス指標（KPI）（たとえば、毎秒フレーム数、毎秒浮動小数点演算数、レイテンシー目標など）に対応することができ、SLAは、特定のSLO（たとえば、毎秒10フレームのための1ギガバイトのメモリ）を満たすためのプラットフォーム・レベルの合意に対応することができる。また、SDSiハードウェアは、インフラストラクチャーや資源所有者が、シリコン・コンポーネント（たとえば、メトリック・テレメトリーを生成する複合システムのコンポーネント）が製品機能にアクセスし、これを管理（追加／除去）し、ハードウェアの機能と利用を自由にスケールアップおよびスケールダウンすることができるようにする能力をも提供する。さらに、テナントごとに決定論的特徴割り当てを提供する能力を提供する。また、実行中のサービス、クライアント動作を中断したり、あるいはシステムをリセットもしくはリブートしたりする必要なく、決定論的オーケストレーションおよびサービス管理を、機能の動的な（またはサブスクリプション・ベースの）アクティブ化に結び付ける機能も提供する。

最下レイヤーでは、SDSiは、単一の資源がシステム内で提供しなければならない契約で合意されたサービス・レベル仕様に対する能動的な遵守を確実にするために、システムに対してサービスおよび保証を提供することができる。さらに、SDSiは、コンポーネント当たりの一つまたは複数のテナントの契約上の権利（権原）、使用および関連する財務、さらにはシリコンレベルの機能（たとえば、SKU機能）を管理する能力を提供する。シリコンレベルの機能は、計算、記憶またはネットワーク機能、パフォーマンス、決定論性（determinism）、またはさらにはセキュリティ、暗号化、加速などに関連していてもよい。これらの機能は、テナントが特定のサービス・レベルの合意を達成できるだけでなく、管理およびデータ収集に関して支援し、最低の管理可能なコンポーネント・レベルでトランザクションと契約の合意を保証することを保証する。

サービス階層構造のより上位レイヤーでは、資源レベル・サービス（Resource Level Services）は、SDSiを介してシステム・レベルの機能を取得し、有効にすることによって、または個別にアドレス指定可能な資源（計算、記憶、およびネットワーク）の合成を通じて、作業負荷需要を満たす能力を（完全にまたは合成を通じて）提供するシステムおよび／または資源を含む。サービス階層構造のさらに上位のレイヤーでは、作業フロー・レベル・サービス（Workflow Level Services）は、サービスチェーンが作業フロー・レベル要件を持つ可能性があるため、水平である。作業フローは、エンドツーエンド・サービスに特定のサービス・レベル目標および要件を提供するために、作業負荷間の依存関係を記述する。これらのサービスは、高可用性、冗長性、リカバリー、フォールトトレランス、または負荷平準化などの特徴および機能を含みうる（これにはさらに多くを含めることができる）。作業フロー・サービスは、エンドツーエンド・サービスを保証するために、資源とシステムと間の依存性と関係を定義し、関連するネットワークとストレージに対する要件を記述し、トランザクション・レベルの要件と関連する契約とを記述する。作業フロー・レベル・サービスは通例、サービス・レベル目標で測定され、必須のサービス要件および期待されるサービス要件をもつ。

サービス階層構造のさらに上位のレイヤーでは、ビジネス機能サービス（Business Functional Services、BFS）が運用可能であり、これらのサービスは、互いに関係をもち、顧客のために特定の機能を提供する、そのサービスの異なる要素である。エッジ・コンピューティングの場合、自律運転の例の中では、ビジネス機能は、たとえば「イベントへのタイムリーな到着」のサービスを構成していることがありうる――このサービスは、ユーザーエンティティの目標を達成するために協調して協働する、いくつかのビジネス機能を要求するであろう：GPSガイダンス、ローカルな交通状況のRSU（Road Side Unit［路側機］）認識、ユーザーエンティティの支払履歴、資源のユーザーエンティティの認可などである。さらに、これらのBFSは複数のエンティティにサービスを提供するので、各BFSは自らのSLAを管理し、自らの資源に対する需要（作業負荷および作業フロー）に対処する能力を認識する。要件および需要が増加すると、サービス変更要件を作業フローおよび資源レベルのサービス・エンティティーに通信し、該サービス・エンティティーが、自分たちが満たす能力についての洞察を提供することができるようにする。このステップは、全体的なトランザクションおよび次のレイヤーへのサービス提供を支援する。

サービス階層構造における最上位レイヤーでは、ビジネス・レベル・サービス（Business Level Services、BLS）は、提供される機能に結びつけられる。このレベルでは、顧客またはエンティティは、サービスがどのように構成されているか、またはサービスを提供するためにどのような成分が使用され、管理され、および／または追跡されるかを気にしないことがありうる。ビジネス・レベル・サービスの主な目的は、合意された財務合意において顧客と提供者との間で確立された全体的な契約条件に従って、顧客が設定した目標を達成することである。BLSは、いくつかのビジネス機能サービス（Business Functional Services、BFS）と全体的なSLAから構成される。

本明細書に記載されるこの構成および他のサービス管理機能は、エッジ・コンピューティングのさまざまな要件を、そのユニークで複雑な資源およびサービス相互作用によって満たすように設計される。このサービス管理構成は、エージェントやミドルウェアの機能を通じてではなく、フレームワーク内の資源基本サービスのいくつかを本質的に扱うことを意図している。位置特定、発見、アドレス指定、トレース、追跡、識別および／または登録といったサービスは、フレームワーク上に資源が現われると、すぐに有効にされてもよく、資源ドメインのマネージャーまたは所有者は、秩序だった資源発見、登録、および認証を保証するために、管理規則およびポリシーを使用することができる。

さらに、本明細書に記載される任意の数のエッジ・コンピューティング・アーキテクチャーは、サービス管理機能をもって適応されてもよい。これらの機能は、システムが常時、資源の動き、ベクトル、および／または方向に関する情報を認識し、記録するとともに、これらの機能を、装置に関連するテレメトリーおよびメタデータの両方として完全に記述することを可能にしてもよい。これらのサービス管理機能は、セキュリティの要素と同様に、資源管理、請求、および／またはメータリングのために使用できる。同じ機能は、関連する資源にも適用され、センサーのようなそれほどインテリジェントでない装置が、エッジ・ゲートウェイのような、より管理しやすい資源に取り付けられてもよい。サービス管理フレームワークは、資源の監督権またはカプセル化の変更を認識させられる。ノードとコンポーネントは、短時間またはライフサイクル全体にわたって、直接アクセス可能であるか、または親装置または代替的な責任ある装置を通じて間接的に管理される可能性があるため、このタイプの構造は、そのインターフェースを通じてサービス・フレームワークに中継され、外部の問い合わせ機構に対して利用可能にされる。

さらに、このサービス管理フレームワークは、常にサービスを意識しており、当然、サービス提供要件と、資源の能力および可用性ならびにデータ分析システムへのデータ・アップロードのためのアクセスとのバランスをとる。ネットワーク・トランスポートが劣化する、障害を起こす、またはより高いコストもしくはより低い帯域幅機能に変化する場合、サービス・ポリシー・モニタリング機能が、ユーザーのプライバシーまたはコスト制約の範囲内で、代替の分析およびサービス提供機構を提供する。これらの機能を用いると、ポリシーは、分析およびダッシュボードサービスの呼び出しをエッジでトリガーし、低下した忠実度または粒度で、連続的なサービス可用性を保証することができる。ひとたびネットワーク・トランスポートが再確立されると、通常のデータ収集、アップロード、分析サービスが再開できる。

マルチステークホルダー・エッジ・コンピューティング・システムの展開は、複数のテナントおよびサービス・プロバイダーによって使用されるために、複数のエッジ・プラットフォームおよびサブシステムの間で、複数のサービスおよび仮想エッジ・インスタンスの展開を可能にするように、配置およびオーケストレーションされうる。クラウド・サービス・プロバイダー（CSP）に適用可能なシステム例では、エッジ・コンピューティング・システムの展開は、クラウド・コンピューティングに対する補足ツールとしてエッジ・コンピューティング・プラットフォームを導入するために「オーバー・ザ・トップ」アプローチを介して提供されてもよい。電気通信サービス・プロバイダー（TSP）に適用可能な対照的なシステム例では、エッジ・コンピューティング・システムの展開は、「ネットワーク集約」アプローチを介して提供されて、（異なるタイプのデータ・アクセス・ネットワークからの）ネットワーク・アクセスが集約される（aggregated）位置においてエッジ・コンピューティング・プラットフォームを導入してもよい。しかしながら、これらのオーバー・ザ・トップ・アプローチおよびネットワーク集約アプローチは、ハイブリッド式のまたは併合されたアプローチまたは構成において、一緒に実装されてもよい。

図2は、本開示の教示による、クライアント計算ノードから受信される作業負荷の要求を処理するためのエッジ・プラットフォーム200の例示的実装を示している。たとえば、エッジ・ゲートウェイ・プラットフォーム112a、112b、112c；エッジ集約プラットフォーム122a、122b；フォグ・プラットフォーム124；および／またはコア・データセンター132の任意のものが、エッジ・プラットフォーム200によって実装されることができる。図2の例示的なエッジ・プラットフォーム200は、例示的なオーケストレータ202、例示的な機能コントローラ204、例示的なテレメトリー・コントローラ206、例示的なエッジ・プラットフォーム（EP）データベース208、および例示的な資源210を含む。図2の例では、オーケストレータ202、機能コントローラ204、テレメトリー・コントローラ206、EPデータベース208、および／または資源210のうちの任意のものが、例示的な通信バス212を介して通信することができる。本明細書に開示される例では、通信バス212は、任意の好適な有線および／または無線通信を使用して実装されうる。追加的または代替的な例では、通信バス212は、ソフトウェア、機械可読命令、および／または通信プロトコルを含み、これらによって、オーケストレータ202、機能コントローラ204、テレメトリー・コントローラ206、EPデータベース208、および／または資源210の間で情報が通信される。いくつかの例では、オーケストレータ202は、オーケストレーションするための手段またはオーケストレーション手段である。いくつかの例では、機能コントローラ204は、機能を制御する手段または機能制御手段である。いくつかの例では、テレメトリー・コントローラ206は、テレメトリーを制御する手段、またはテレメトリー制御手段である。いくつかの例では、EPデータベース208は、記憶する手段または記憶手段である。いくつかの例では、資源210は、資源のための手段または資源手段である。

いくつかの例では、エッジ・プラットフォーム200は、情報中心ネットワーキング（Information Centric Networking、ICN）との関連で使用されてもよい。ここで、ICNは既存のエッジネットワーク・レイヤーの上のレイヤーとして動作する。たとえば、ICNは、複数のエッジ・プラットフォーム200上でEPデータベース208の内容をキャッシュおよび複製するICNルーティング・ノードの形で、EPデータベース208に接続されてもよい。いくつかの例では、ICNは、EPデータベース208を、オーケストレータ202、機能コントローラ204、テレメトリー・コントローラ206、および／または資源210を実装するコンテキストにおいて読み取り／書き込みを求める他のEPノードのより近くにもってくることによって、EPデータベース208へのアクセスを最適化する。

図2に示される例では、オーケストレータ202、機能コントローラ204、テレメトリー・コントローラ206、EPデータベース208、および資源210は、エッジ・プラットフォーム200に含まれ、エッジ・プラットフォーム200に対応し、および／または他の仕方でエッジ・プラットフォーム200を代わす。しかしながら、いくつかの例では、オーケストレータ202、機能コントローラ204、テレメトリー・コントローラ206、EPデータベース208、および資源210のうちの一つまたは複数は、エッジ・プラットフォーム200に含まれるのではなく、エッジ・プラットフォーム200を含むエッジ環境（たとえば、エッジ・クラウド110）に含まれることができる。たとえば、オーケストレータ202は、エッジ・プラットフォーム200の外側にある間に、エンドポイント・レイヤー（たとえば、エンドポイント・レイヤー120）、エッジ装置レイヤー（たとえば、エッジ装置レイヤー130）、ネットワーク・アクセス・レイヤー（たとえば、ネットワーク・アクセス・レイヤー140）、コア・ネットワーク・レイヤー（たとえば、コア・ネットワーク・レイヤー150）、および／またはクラウド・データセンター・レイヤー（たとえば、クラウド・データセンター・レイヤー160）に接続されることができる。

他の例では、オーケストレータ202、機能コントローラ204、テレメトリー・コントローラ206、EPデータベース208、および資源210のうちの一つまたは複数が、エッジ環境に含まれる別個の装置である。さらに、オーケストレータ202、機能コントローラ204、テレメトリー・コントローラ206、EPデータベース208、および資源210のうちの一つまたは複数は、エッジ装置レイヤー（たとえば、エッジ装置レイヤー130）、ネットワーク・アクセス・レイヤー（たとえば、ネットワーク・アクセス・レイヤー140）、コア・ネットワーク・レイヤー（たとえば、コア・ネットワーク・レイヤー150）、および／またはクラウド・データセンター・レイヤー（たとえば、クラウド・データセンター・レイヤー160）に含まれることができる。たとえば、オーケストレータ202がエッジ装置レイヤー（たとえば、エッジ装置レイヤー130）に含まれることができ、または資源210がネットワーク・アクセス・レイヤー（たとえば、ネットワーク・アクセス・レイヤー140）、コア・ネットワーク・レイヤー（たとえば、コア・ネットワーク・レイヤー150）、および／またはクラウド・データセンター・レイヤー（たとえば、クラウド・データセンター・レイヤー160）に含まれることができる。

いくつかの例では、クライアント計算プラットフォーム（たとえば、クライアント計算プラットフォーム102a、102b、102c、102d、102e、102fのうちの1つ）および／またはエッジ・プラットフォームからの作業負荷を実行する要求に応答して、オーケストレータ202は、クライアント計算プラットフォーム（たとえば、エッジ・プラットフォーム）からの作業負荷についての動作パラメータを決定するために、前記要求を解析する。いくつかの例では、オーケストレータ202は、複数の要求を受信することができ、それらの要求を重複除去してもよい。すなわち、オーケストレータ202は、「作業負荷A」を実行する要求を複数受信することがある。「作業負荷A」に対する要求のすべてを解析する代わりに、オーケストレータ202は、「作業負荷A」に対する要求の1つを解析し、その結果を「作業負荷A」に対する残りの要求に入れることで資源（たとえば、熱的資源、計算資源など）を節約できる。

動作パラメータを決定するために、例示されている例のオーケストレータ202は、動作パラメータのために要求される因子のサブセットを導出する。いくつかの例では、オーケストレータ202は、セキュリティのレベル、精度のレベル、エッジ・プラットフォームの他のマイクロサービスへの依存性、エッジ環境内の依存性の位置、エッジ・プラットフォームの使用情報、またはエッジ・プラットフォームおよび／または作業負荷のサービス・レベル合意（SLA）属性を含む要因のサブセットを導出する。オーケストレータ202は、計算資源を節約するために、ルックアップテーブルから要因のサブセットを導出することができる。たとえば、オーケストレータ202は、「作業負荷A」に対する要求を受け取り、テーブルにおいて「作業負荷A」を検索し、サービス・レベル合意（SLA）属性または「作業負荷A」を実行するために必要な特定レベルのセキュリティを含む要因のサブセットを決定することができる。

いくつかの例では、動作パラメータを決定するとき、オーケストレータ202は、エッジ・プラットフォームおよび／または作業負荷のための資源要件を推定する。資源要件は、要因の前記サブセットに基づく、作業負荷についての電力測定、熱測定、レイテンシー測定、および／または帯域幅測定を含む。たとえば、オーケストレータ202は、ルックアップテーブルから要因のサブセットを決定し、要因のサブセットを満足させるために必要な資源要件を推定する。図示された例のオーケストレータ202は、更新された動作パラメータまたは要因のサブセットに基づいて資源要件を更新する。

図示された例のオーケストレータ202は、候補エッジ層およびエッジ・プラットフォーム配置のそれぞれの資源利用可能性を決定することによって、動作パラメータに基づいて、前記要求（単数または複数）についての候補エッジ層およびエッジ・プラットフォーム配置を解析する。いくつかの例では、資源利用可能性は、候補エッジ層およびエッジ・プラットフォーム配置のそれぞれからのテレメトリー・データに基づく、候補エッジ層およびエッジ・プラットフォーム配置のそれぞれにおける、電力利用可能性、熱的利用可能性、レイテンシー利用可能性、および／または帯域幅利用可能性のうちの一つまたは複数に対応する。図示された例では、オーケストレータ202は、機能コントローラ204と通信して、資源利用可能性を決定する。機能コントローラ204は、エッジ・プラットフォーム200、作業負荷（たとえば、クラウドレット）および他のエッジ・プラットフォーム200の機能を決定する。たとえば、機能コントローラ204は、機能データ（たとえば、エッジ・プラットフォーム200における熱的資源、電力資源、帯域幅資源、ハードウェア資源、記憶資源、ネットワーク資源、ソフトウェア資源など）を生成する。たとえば、機能コントローラ204は、機能データに基づいて、エッジ・プラットフォーム200に割り当てられた資源、たとえば、ハードウェア資源（たとえば、計算、ネットワーク、セキュリティ、記憶などのハードウェア資源）、ソフトウェア資源（たとえば、ファイアウォール、ロード・バランサー、仮想マシン（VM）、ゲスト・オペレーティングシステム（OS）、アプリケーション、ハイパーバイザーなど）など、および／またはそれらの組み合わせを決定することができ、そこから、エッジ・コンピューティング作業負荷（たとえば、登録された作業負荷）が実行されることができる。いくつかの例では、機能コントローラ204は、エッジ・プラットフォーム200においてプロビジョンされるおよび／または実行されるコンテナを決定することができる。たとえば、機能コントローラ204は、エッジ・プラットフォーム200にプロビジョンされたコンテナおよび／またはエッジ・プラットフォーム200においてコンテナに割り当てられた資源に関連するマイクロサービスを識別することができる。

いくつかの例では、機能コントローラ204は、EPデータベース208から機能データを取得する。たとえば、オーケストレータ202が作業負荷を実行するための要求を受け取ると、オーケストレータ202は、機能コントローラ204および／またはEPデータベース208にアクセスすることによって、エッジ・プラットフォーム200の機能が、作業負荷タスクを満たすための適正な資源（単数または複数）を含むかどうかを識別する。たとえば、オーケストレータ202は、2つのコアをもつプロセッサを必要とする作業負荷を実行する要求を受信し、オーケストレータ202は、機能コントローラ204および／またはEPデータベース208にアクセスして、エッジ・プラットフォーム200が要求された作業負荷を処理する機能を含むかどうかを判定することができる。すなわち、オーケストレータ202は、機能コントローラ204にアクセスして、要求（たとえば、作業負荷）についての候補エッジ層およびエッジ・プラットフォーム配置を識別するための資源利用性を判別する。

図2の例では、機能コントローラ204は、さらに、エッジ・プラットフォーム200に割り当てられた新規および／または追加の資源の機能を決定する。たとえば、エッジ・プラットフォーム200がエッジ・サービス・プロバイダーによって、追加の計算資源、記憶資源、および／またはネットワーク資源を含むようにアップグレードされる場合、機能コントローラ204は、追加の資源を登録し、追加の資源に関連する機能データを生成することができる。いくつかの例では、機能コントローラ204は、エッジ・プラットフォーム200における資源（たとえば、資源210）とインターフェースするためのプロトコルを生成し、および／またはオーケストレータ202、テレメトリー・コントローラ206、および／またはEPデータベース208のうちの一つまたは複数に送信することができる。

図2の図示した例では、テレメトリー・コントローラ206は、エッジ・コンピューティング環境におけるエッジ・プラットフォームに関連するテレメトリー・データに基づいて、エッジ・コンピューティング作業負荷の（たとえば、諸エッジ・プラットフォームのうちでの）分散および実行を改善する。たとえば、テレメトリー・コントローラ206は、テレメトリー・データに基づいて、第1のエッジ・プラットフォームおよび／または第2のエッジ・プラットフォームが、ハードウェア資源（たとえば、計算、ネットワーク、セキュリティ、記憶（たとえば、不揮発性メモリ・エクスプレス）などのハードウェア資源）、ソフトウェア資源（たとえば、ファイアウォール、ロード・バランサー、仮想マシン（VM）、ゲスト・オペレーティングシステム（OS）、アプリケーション、ハイパーバイザーなど）など、および／またはそれらの組み合わせなどの資源210の利用可能な一つ（または複数）をもち、そこからエッジ・コンピューティング作業負荷が実行できることを判別することができる。そのような例では、テレメトリー・データは、エッジ・プラットフォーム（たとえば、エッジ・プラットフォーム200および／または代替的なエッジ・プラットフォーム）のうちの少なくとも1つの資源210の一つ（または複数）に関連する、利用率（たとえば、利用されているかまたは利用されていない資源の割合）、サービスを受けることにおける遅延（たとえば、平均遅延）（たとえばレイテンシー）、資源が利用可能であるレート（たとえば、平均レート）（たとえば、帯域幅、スループットなど）、電力消費量、温度などを含むことができる。

動作パラメータを満足する候補エッジ層およびエッジ・プラットフォームの配置に基づいて、エッジ・プラットフォーム（たとえば、作業負荷またはクラウド）のための候補エッジ層およびエッジ・プラットフォームの配置を決定するために、オーケストレータ202は、候補エッジ層およびエッジ・プラットフォーム配置のそれぞれについて、動作パラメータ割合を決定する。図示された例の動作パラメータ割合は、エッジ・プラットフォームの資源要件を満足するエッジ層およびエッジ・プラットフォーム配置の資源利用可能性のパーセンテージに対応する。たとえば、オーケストレータ202は、2つのコアをもつプロセッサを必要とする作業負荷を実行するための要求を受信することがありうる。この例では、オーケストレータ202は、機能コントローラ204および／またはEPデータベース208にアクセスして、候補エッジ層およびエッジ・プラットフォーム配置のそれぞれについての動作パラメータ割合を決定することができる。この例において、オーケストレータ202は、1つの候補エッジ層およびエッジ・プラットフォーム配置が100%の動作パラメータ割合をもつ（すなわち、2つのコアをもつプロセッサを有する）こと、および、残りの候補エッジ層およびエッジ・プラットフォーム配置が0%の動作パラメータ割合を有する（すなわち、2つのコアをもつプロセッサを有しない）ことを判別することがありうる。図示された例のオーケストレータ202は、最適な動作パラメータ割合をもつエッジ層およびエッジ・プラットフォーム配置を、候補エッジ層およびエッジ・プラットフォーム配置として選択し、該候補エッジ層およびエッジ・プラットフォーム配置において作業負荷を実施する。いくつかの例では、オーケストレータ202は、i）利用可能である、ii）利用可能であり、最も近い、iii）利用可能であり、最も近く、最も安価である、iv）利用可能であり、最も安価であり、十分に近い等のいくつかの望ましい動作パラメータを組み合わせて、それらの望ましい動作パラメータを含む、エッジ層およびエッジ・プラットフォーム配置に関連する割合を決定することによって、最適な動作パラメータ割合を決定する。たとえば、オーケストレータ202は、ある候補エッジ層およびエッジ・プラットフォーム配置がエッジ環境において最も近く、利用可能であり、最も安価であると判断することができる。よって、オーケストレータ202は、他の最適な動作パラメータ割合（たとえば、利用可能でない、より高価である、などのエッジ層配置）よりも高い最適な動作パラメータ割合を決定することができる。

いくつかの例では、候補エッジ層およびエッジ・プラットフォーム配置のそれぞれについての動作パラメータ割合が閾値を満たさないこと（たとえば、70%未満、40%未満など）に応答して、オーケストレータ202は、資源要件およびコスト関数重みを調整する。たとえば、オーケストレータ202は、動作パラメータ割合閾値を下げること、特定の候補エッジ層およびエッジ・プラットフォーム配置において作業負荷を実行するために費やすことができる金額に関連するコスト関数を低減することなどにより、資源要件を調整することができる。しかしながら、オーケストレータ202は、閾値回数の逐次反復（たとえば、資源要件およびコスト関数調整）の後に、要求がエッジ環境において処理されることができないと識別されると判断してもよい。たとえば、作業負荷を実行することに関連するコストは、コスト関数閾値を満たさない。いくつかの例では、コスト関数は、最適な動作パラメータ割合を減少させるペナルティ要因である。たとえば、コスト関数は、レイテンシー、ジッタ、誤り率、パケット破棄、ネットワーク帯域幅消費などに関する統計的閾値を超えることに対するペナルティに対応する。

図2の図示した例では、エッジ・プラットフォーム200は、データ（たとえば、テレメトリー・データ、作業負荷、機能データ、資源利用可能性など）を記録するためのEPデータベース208を含む。EPデータベース208は、揮発性メモリ（たとえば、同期動的ランダムアクセスメモリ（SDRAM）、動的ランダムアクセスメモリ（DRAM）、RAMBUS動的ランダムアクセスメモリ（RDRAM）など）および／または不揮発性メモリ（たとえば、フラッシュメモリ）によって実装できる。EPデータベース208は、追加的または代替的に、DDR、DDR2、DDR3、DDR4、モバイルDDR（mDDR）などのダブルデータレート（DDR）メモリによって実装できる。EPデータベース208は、追加的または代替的にハードディスクドライブ、コンパクトディスクドライブ、デジタル多用途ディスクドライブ、ソリッドステートディスクドライブなどの一つまたは複数の大容量記憶装置によって実装できる。図示された例では、EPデータベース208は単一のデータベースとして示されているが、EPデータベース208は、任意の数および／またはタイプのデータベースによって実装できる。さらに、EPデータベース208に記憶されたデータは、たとえば、バイナリデータ、カンマ区切りデータ、タブ区切りデータ、構造化照会言語（SQL）構造などの任意のデータフォーマットであることができる。

図2の図示した例では、資源（単数または複数）210は、クライアント計算プラットフォームから得られた作業負荷（たとえば、エッジ・コンピューティング作業負荷）を実行するために呼び出される。たとえば、資源210は、エッジ・プラットフォームまたはその一部に対応することができ、および／または他の仕方でそれらを表わすことができる。たとえば、オーケストレータ202、機能コントローラ204、テレメトリー・コントローラ206、EPデータベース208、および／またはより一般には、エッジ・プラットフォーム200は、一つまたは複数のエッジ・コンピューティング作業負荷を実行するために資源210のそれぞれの1つを呼び出すことができる。

いくつかの例では、資源210は、ハードウェア資源、ハードウェア資源の仮想化、ソフトウェア資源、ソフトウェア資源の仮想化など、および／またはそれらの組み合わせを表わす。たとえば、資源210は、一つまたは複数のCPU（たとえば、マルチコアCPU）、一つまたは複数のFPGA、一つまたは複数のGPU、一つまたは複数のネットワークインターフェースカード（NIC）、一つまたは複数のビジョン処理ユニット（VPU）など、および／または任意の他のタイプのハードウェアまたはハードウェアアクセラレータを含む、それらに対応する、および／または他の仕方でそれらを表わすことができる。そのような例では、資源210は、前記一つまたは複数のCPU、前記一つまたは複数のFPGA、前記一つまたは複数のGPU、前記一つまたは複数のNICなどの仮想化を含む、それらに対応する、および／または他の仕方でそれらを表わすことができる。他の例では、オーケストレータ202、機能コントローラ204、テレメトリー・コントローラ206、EPデータベース208、資源210、および／または、より一般には、エッジ・プラットフォーム200は、一つまたは複数のソフトウェア資源、該ソフトウェア資源の仮想化など、たとえばハイパーバイザー、ロード・バランサー、OS、VMなど、および／または、それらの組み合わせを含む、それらに対応する、および／または他の仕方でそれらを表わすことができる。

いくつかの例では、クライアント計算プラットフォーム（たとえば、クライアント計算プラットフォーム102a、102b、102c、102d、102e、102fのうちの1つ）からの作業負荷を実行する要求に応答して、オーケストレータ202は、資源210およびクライアント計算プラットフォーム（たとえば、クライアント計算プラットフォーム102a、102b、102c、102d、102e、102fのうちの1つ）のうちの少なくとも1つと通信して、実行されるべき作業負荷の記述に関連付けられた契約（contract）（たとえば、作業負荷契約）を作成する。クライアント計算プラットフォーム（たとえば、クライアント計算プラットフォーム102a、102b、102c、102d、102e、102fの1つ）は、契約および作業負荷の記述に関連するタスクをオーケストレータ202に提供し、オーケストレータ202は、該タスクをエッジ・プラットフォームにおいて実行されるようスケジュールする。タスクは、契約および実行されるべき作業負荷の記述を含むことができる。いくつかの例では、タスクは、作業負荷を実行するために使用される資源を獲得するおよび／または他の仕方で割り当てる要求を含む。

図1のエッジ・プラットフォーム200を実装する例示的な仕方が図2に示されているが、図2に示された要素、プロセスおよび／または装置のうちの一つまたは複数は、他の任意の仕方で組み合わされ、分割され、再配置され、省略され、除去され、および／または実装されてもよい。さらに、例示的なオーケストレータ202、例示的な機能コントローラ204、例示的なテレメトリー・コントローラ206、例示的なEPデータベース208、例示的な資源210、および／またはより一般には、図2の例示的なエッジ・プラットフォーム200は、ハードウェア、ソフトウェア、ファームウェア、および／またはハードウェア、ソフトウェア、および／またはファームウェアの任意の組み合わせによって実装されてもよい。よって、たとえば、例示的なオーケストレータ202、例示的な機能コントローラ204、例示的なテレメトリー・コントローラ206、例示的なEPデータベース208、例示的な資源210、および／またはより一般には、例示的なエッジ・プラットフォーム200の任意のものは、一つまたは複数のアナログまたはデジタル回路、論理回路、プログラマブルプロセッサ、プログラマブルコントローラ、グラフィックス処理ユニット（GPU）、デジタル信号プロセッサ（DSP）、特定用途向け集積回路（ASIC）、プログラマブル論理デバイス（PLD）および／またはフィールドプログラマブル論理デバイス（FPLD）によって実装されうる。本特許の装置またはシステムクレームのいずれかを、純粋にソフトウェアおよび／またはファームウェアの実装をカバーするよう読む場合、例示的なオーケストレータ202、例示的な機能コントローラ204、例示的なテレメトリー・コントローラ206、例示的なEPデータベース208、例示的な資源210、および／またはより一般には例示的なエッジ・プラットフォーム200のうちの少なくとも1つは、該ソフトウェアおよび／またはファームウェアを含んでいるメモリ、デジタル多用途ディスク（DVD）、コンパクトディスク（CD）、ブルーレイディスクなどの非一時的なコンピュータ読み取り可能記憶デバイスまたは記憶ディスクを含むように、ここに明確に定義される。さらに、図2の例示的なエッジ・プラットフォーム200は、図2に示されたものに加えて、またはその代わりに、一つまたは複数の要素、プロセスおよび／または装置を含んでいてもよく、および／または図示された要素、プロセスおよび装置のいずれかまたは全部を二つ以上含んでいてもよい。本明細書で使用されるところでは、「通信して」という句は、その変形を含めて、直接通信および／または一つまたは複数の中間コンポーネントを通じた間接的な通信を包含し、直接的な物理的（たとえば、有線）通信および／または常時通信を必要とせず、むしろ、周期的な間隔、スケジュールされた間隔、非周期的な間隔、および／または1回限りの事象における選択的な通信をさらに包含する。

例示的なハードウェア論理、機械読み取り可能命令、ハードウェア実装された状態マシン、および／またはエッジ・プラットフォーム200を実装するためのそれらの任意の組み合わせを表わすフローチャートが、図3～図6に示されている。機械読み取り可能命令は、コンピュータプロセッサおよび／またはプロセッサ回路、たとえば図7との関連で後述する例示的なプロセッサプラットフォーム700に示されるプロセッサ712による実行のための一つまたは複数の実行可能プログラムまたは実行可能プログラムの一部であってもよい。プログラムは、CD-ROM、フロッピーディスク、ハードドライブ、DVD、ブルーレイディスク、またはプロセッサ712に付随するメモリのような非一時的なコンピュータ読み取り可能記憶媒体上に記憶されたソフトウェアにおいて具現されてもよいが、プログラム全体および／またはその一部は、代替的に、プロセッサ712以外の装置によって実行され、および／またはファームウェアもしくは専用ハードウェアにおいて具現されてもよい。さらに、例示的なプログラムは、図3～図6に示されるフローチャートを参照して説明されるが、例示的なエッジ・プラットフォーム200を実装する多くの他の方法が代替的に使用されうる。たとえば、ブロックの実行順序は変更されてもよく、および／または記載されるブロックのいくつかが変更され、削除され、または組み合わされてもよい。追加的または代替的に、ブロックのいずれかまたは全部は、ソフトウェアまたはファームウェアを実行することなく対応する動作を実行するように構成された一つまたは複数のハードウェア回路（たとえば、離散的なおよび／または集積されたアナログおよび／またはデジタル回路、FPGA、ASIC、比較器、演算増幅器（オペアンプ）、論理回路など）によって実装されてもよい。プロセッサ回路は、異なるネットワーク位置に分散されていてもよく、および／または一つまたは複数の装置（たとえば、単一マシン内のマルチコアプロセッサ、サーバーラックを通じて分散された複数のプロセッサなど）にローカルであってもよい。

本明細書に記載される機械読み取り可能な命令は、圧縮フォーマット、暗号化フォーマット、フラグメント化されたフォーマット、コンパイルされたフォーマット、実行可能フォーマット、パッケージ化されたフォーマット等のうちの一つまたは複数で記憶されてもよい。本明細書に記載される機械読み取り可能な命令は、データ、または、機械実行可能な命令を作成、製造、および／または生成するために利用されうるデータ構造（たとえば、命令の一部、コード、コードの表現など）として記憶されてもよい。たとえば、機械読み取り可能な命令は、フラグメント化され、（たとえば、クラウド内、エッジ装置内などの）ネットワークまたはネットワークの集合の同じまたは異なる位置に配置された一つまたは複数の記憶装置および／またはコンピューティング装置（たとえば、サーバー）に記憶されてもよい。機械読み取り可能な命令は、コンピューティング装置および／または他の機械によって直接読み取り可能、解釈可能、および／または実行可能にするために、インストール、修正、適応、更新、組み合わせ、補足、構成、暗号化解除、圧縮解除、パッキング解除、分配、再割り当て、コンパイルなどのうちの一つまたは複数を必要とすることがある。たとえば、機械読み取り可能な命令は、個別に圧縮され、暗号化され、別々の計算装置に記憶される複数の部分に格納されてもよく、それらの部分は、暗号化解除され、圧縮解除され、組み合わされたときに、一緒に本明細書に記載されるようなプログラムを形成することができる一つまたは複数の機能を実装する実行可能命令のセットを形成する。

別の例では、機械読み取り可能な命令は、それらがプロセッサ回路によって読み取られうる状態で記憶されてもよいが、特定のコンピューティング装置または他の装置上で該命令を実行するためには、ライブラリ（たとえば、動的リンクライブラリ（DLL））、ソフトウェア開発キット（SDK）、アプリケーション・プログラミング・インターフェース（API）などの追加を必要とすることがある。別の例では、機械読み取り可能な命令および／または対応するプログラムの全体または一部が実行できる前に、機械読み取り可能な命令は、構成される必要があることがある（たとえば、設定が記憶され、データが入力され、ネットワークアドレスが記録されるなど）。よって、本明細書で使用されるところの機械読み取り可能媒体は、機械読み取り可能な命令および／またはプログラムを、記憶されるまたは他の仕方で静止しているときまたは移送中の該機械読み取り可能な命令および／またはプログラムの具体的なフォーマットまたは状態にかかわりなく、含んでいてもよい。

本明細書に記載される機械読み取り可能な命令は、過去、現在、または将来の任意の命令言語、スクリプト言語、プログラミング言語などによって表現できる。たとえば、機械読み取り可能な命令は、以下の言語：C、C++、Java、C#、Perl、Python、JavaScript、ハイパーテキストマークアップ言語（HTML）、構造化照会言語（SQL）、Swiftなどのいずれかの言語を使用して表現されてもよい。

上述したように、図7の例示的なプロセスは、ハードディスクドライブ、フラッシュメモリ、リードオンリーメモリ、コンパクトディスク、デジタル多用途ディスク、キャッシュ、ランダムアクセスメモリ、および／または情報が任意の期間（たとえば、長期間、永久に、短いインスタンスのために、一時的にバッファリングするために、および／または情報をキャッシュするために）記憶される任意の他の記憶デバイスまたは記憶ディスクのような非一時的コンピュータおよび／または機械読み取り可能な媒体上に記憶される実行可能な命令（たとえば、コンピュータおよび／または機械読み取り可能な命令）を使用して実施されてもよい。本明細書で使用されるところでは、非一時的なコンピュータ読み取り可能媒体という用語は、任意のタイプのコンピュータ読み取り可能な記憶デバイスおよび／または記憶ディスクを含み、伝搬信号を除外し、伝送媒体を除外するものとして明確に定義される。

「含む」および「有する」（およびそのすべての形態および時制）は、本明細書では、オープンエンドの用語として使用される。よって、クレームが「含む」または「有する」（たとえば、有する、含む、有している、含んでいる、もつ等）のいずれかの形を前提部として、または任意の種類のクレーム記載の中で用いるときは常に、対応するクレームまたは記載の範囲から外れることなく、追加の要素、項目等が存在してもよいことが理解される。本明細書で使用されるところでは、たとえばクレームの前提部において「少なくとも」という句が移行用語として使用される場合、これは、「有する」および「含む」という用語がオープンエンドであるのと同様にオープンエンドである。たとえばA、B、および／またはCのような形式で使用されるときの用語「および／または」は、（1）Aのみ、（2）Bのみ、（3）Cのみ、（4）AとB、（5）AとC、（6）BとC、（7）AとBとCのようなA、B、Cの任意の組み合わせまたはサブセットを指す。本明細書で使用されるところでは、構造、コンポーネント、項目、オブジェクトおよび／または物を記述する文脈において、「AおよびBのうちの少なくとも1つ」という句は、（1）少なくとも1つのA、（2）少なくとも1つのB、および（3）少なくとも1つのAおよび少なくとも1つのBのうちの任意のものを含む実装を指すことが意図されている。同様に、本明細書で使用されるところでは、構造、コンポーネント、項目、オブジェクトおよび／または物を記述する文脈において、「AまたはBのうちの少なくとも1つ」という句は、（1）少なくとも1つのA、（2）少なくとも1つのB、および（3）少なくとも1つのAおよび少なくとも1つのBのうちの任意のものを含む実装を指すことが意図されている。本明細書で使用されるところでは、プロセス、命令、アクション、活動および／またはステップの実行または実施を記述する文脈において、用語「AおよびBのうちの少なくとも1つ」は、（1）少なくとも1つのA、（2）少なくとも1つのB、および（3）少なくとも1つのAおよび少なくとも1つのBの任意のものを含む実装を指すことが意図されている。同様に、本明細書で使用されるところでは、プロセス、命令、アクション、活動および／またはステップの実行または実施を記述する文脈において、用語「AまたはBのうちの少なくとも1つ」は、（1）少なくとも1つのA、（2）少なくとも1つのB、および（3）少なくとも1つのAおよび少なくとも1つのBの任意のものを含む実装を指すことが意図されている。

本明細書中で使用されるところでは、単数形の言及（たとえば、「a」、「an」、「第1」、「第2」など）は、複数を除外しない。「a」または「an」エンティティという用語は、本明細書において使用されるところでは、そのエンティティの一つまたは複数を指す。用語「a」（または「an」）、「一つまたは複数」、および「少なくとも1つ」は、本明細書では交換可能に使用されることができる。さらに、個々に列挙されているが、複数の手段、要素、または方法アクションが、たとえば、単一のユニットまたはプロセッサによって実装されてもよい。さらに、個々の特徴が異なる例または請求項に含まれることがあるが、これらは可能性としては組み合わされてもよく、異なる例または請求項に含まれることは、特徴の組み合わせが実現可能でないおよび／または有利でないことを含意しない。

図3は、図2の例示的なエッジ・プラットフォーム200を実装するために実行されうる例示的な機械読み取り可能な命令300を表わすフローチャートである。機械読み取り可能な命令300は、ブロック302で始まり、そこでオーケストレータ202は、エッジ環境内のエッジ・プラットフォームから作業負荷を実行する要求を受け取る。

ブロック304では、オーケストレータ202は、要求を解析して、エッジ・プラットフォームからの作業負荷のための動作パラメータを決定する。たとえば、オーケストレータ202は、動作パラメータに必要な要因のサブセットを導出する。

ブロック306では、オーケストレータは、動作パラメータに基づいて候補エッジ層およびエッジ・プラットフォーム配置を解析する。たとえば、例示された例のオーケストレータ202は、候補エッジ層およびエッジ・プラットフォーム配置のそれぞれの資源利用可能性を決定することによって、動作パラメータに基づいて前記要求（単数または複数）についての候補エッジ層およびエッジ・プラットフォーム配置を解析する。

ブロック308では、オーケストレータは、作業負荷要件および動作パラメータを満足する候補エッジ層およびエッジ・プラットフォーム配置に基づいて、作業負荷のための候補エッジ層およびエッジ・プラットフォーム配置を決定する。たとえば、オーケストレータ202は、候補エッジ層およびエッジ・プラットフォーム配置のそれぞれについて、動作パラメータ割合を決定する。図示された例の動作パラメータ割合は、作業負荷の資源要件を満たす、エッジ層およびエッジ・プラットフォーム配置の資源利用可能性のパーセンテージに対応する。たとえば、オーケストレータ202は、2つのコアをもつプロセッサを必要とする作業負荷を実行する要求を受け取ることがある。この例では、オーケストレータ202は、機能コントローラ204および／またはEPデータベース208にアクセスして、候補エッジ層およびエッジ・プラットフォーム配置のそれぞれについての動作パラメータ割合を決定することができる。この例では、オーケストレータ202は、1つの候補エッジ層およびエッジ・プラットフォーム配置が100%の動作パラメータ割合を有する（すなわち、2つのコアをもつプロセッサを有する）こと、および、残りの候補エッジ層およびエッジ・プラットフォーム配置が0%の動作パラメータ割合を有する（すなわち、2つのコアをもつプロセッサを有しない）ことを判別することができる。図示された例のオーケストレータ202は、最適な動作パラメータ割合をもつエッジ層およびエッジ・プラットフォーム配置を、候補エッジ層およびエッジ・プラットフォーム配置として選択し、その候補エッジ層およびエッジ・プラットフォーム配置において作業負荷を実装する。いくつかの例では、候補エッジ層およびエッジ・プラットフォーム配置のそれぞれについての動作パラメータ割合が閾値を満たさないこと（たとえば、70%未満、40%未満など）に応答して、オーケストレータ202は、資源要件およびコスト関数重みを調整する。たとえば、オーケストレータ202は、動作パラメータ割合閾値を下げること、特定の候補エッジ層およびエッジ・プラットフォーム配置において作業負荷を実行するためにどのくらいの金額を費やすことができるか、もしくはどのくらいのデータ損失を許容できるか、もしくはどのくらいのレイテンシーを受けてもよいかなどに関連するコスト関数を低減することにより、資源要件を調整することができる。しかしながら、オーケストレータ202は、閾値回数の反復工程（たとえば、資源要求およびコスト関数調整）の後に、要求がエッジ環境において処理されることができないと識別されると判断してもよい。たとえば、作業負荷を実行することに関連するコストは、コスト関数閾値を満たさない。機械読み取り可能な命令300は終了する。

図4は、エッジ・プラットフォームからの作業負荷のための動作パラメータを決定するために要求を解析するよう図2の例示的なオーケストレータ202を実装するために実行されることができる、例示的な機械読み取り可能な命令304を表わすフローチャートである。機械読み取り可能な命令304は、ブロック402で始まり、そこで、オーケストレータ202は、動作パラメータに必要な要因のサブセットを導出する。たとえば、オーケストレータ202は、セキュリティのレベル、精度のレベル、作業負荷の他のマイクロサービスへの依存性、エッジ環境内での該依存性の位置、作業負荷の使用情報、または作業負荷のサービス・レベル合意（SLA）属性を含む要因のサブセットを導出する。オーケストレータ202は、計算資源を節約するためにルックアップテーブルから要因のサブセットを導出することができる。たとえば、オーケストレータ202は、「作業負荷A」の要求を受け取り、テーブル内で「作業負荷A」を検索し、「作業負荷A」を実行するために必要なセキュリティの特定レベルまたはサービス・レベル合意（SLA）属性を含む要因のサブセットを決定することができる。

ブロック404では、オーケストレータ202は、要因のサブセットに基づいて、作業負荷のための資源要件を推定する。たとえば、要因の前記サブセットに基づく、作業負荷を処理するために使用される各エッジ・プラットフォームについての電力測定、熱測定、レイテンシー測定、および／または帯域幅測定を含む、作業負荷のための資源要件を推定する。たとえば、オーケストレータ202は、ルックアップテーブルから要因のサブセットを決定し、要因のサブセットを満足させるために必要な資源要件を推定する。

ブロック406では、オーケストレータ202は、更新された動作パラメータが利用可能であるかどうかを判定する。たとえば、示される例のオーケストレータ202は、更新された動作パラメータまたは要因のサブセットに基づいて、資源要件を更新する。オーケストレータが、更新された動作パラメータが利用可能であると識別する場合、機械読み取り可能な命令304は、該動作パラメータに必要な要因のサブセットを導出するためにブロック402に進む。たとえば、オーケストレータ202は、更新されたSLA属性を識別し、更新されたSLA属性に必要な要因の更新されたサブセットを導出することに進んでもよい。オーケストレータ202が、利用可能な更新された動作パラメータがないと判断した場合、機械読み取り可能な命令304は戻ってブロック306に進む。

図5は、動作パラメータに基づいて候補エッジ層およびエッジ・プラットフォーム配置を解析するよう、図2の例示的なオーケストレータ202を実装するために実行されることができる例示的な機械読み取り可能な命令306のフローチャートである。機械読み取り可能な命令306は、ブロック502で始まり、そこでオーケストレータ202は、候補エッジ層およびエッジ・プラットフォーム配置のそれぞれからテレメトリー・データを受領する。たとえば、オーケストレータ202は、決定されたエッジ層およびエッジ・プラットフォーム配置決定に基づいた種々のノードの予想される将来の利用、実際の測定（これは少量だけ過去に時間シフトされることがありうる）、および進行中の要求配置決定からの予想される利用に対応するテレメトリー・データを受領してもよい。

ブロック504では、オーケストレータ202は、候補エッジ層およびエッジ・プラットフォーム配置のそれぞれの資源の利用可能性を決定する。たとえば、資源利用可能性は、候補エッジ層およびエッジ・プラットフォーム配置のそれぞれからのテレメトリー・データに基づいて、候補エッジ層およびエッジ・プラットフォーム配置のそれぞれにおける、電力利用可能性、熱的利用可能性、レイテンシー利用可能性、および／または帯域幅利用可能性に対応する。いくつかの例では、オーケストレータ202は、資源利用可能性を決定するために機能コントローラ204と通信する。

ブロック506では、オーケストレータ202は、更新されたテレメトリー・データが利用可能かどうかを判定する。オーケストレータ202が更新されたテレメトリー・データが利用可能であると判断した場合、機械読み取り可能な命令306はブロック502に進み、候補エッジ層およびエッジ・プラットフォーム配置のそれぞれからテレメトリー・データを受領する。オーケストレータ202が更新されたテレメトリー・データが利用可能でないと判断した場合は、機械読み取り可能な命令304は戻ってブロック308に進む。

図6は、作業負荷要件および動作パラメータを満足する候補エッジ層およびエッジ・プラットフォーム配置に基づいて、作業負荷のための候補エッジ層およびエッジ・プラットフォーム配置を決定するよう、図2の例示的なオーケストレータ202を実装するために実行されうる、例示的な機械読み取り可能な命令308を表わすフローチャートである。機械読み取り可能な命令308は、ブロック602で始まり、そこで、オーケストレータ202は、候補エッジ層およびエッジ・プラットフォーム配置のそれぞれのための動作割合を決定する。たとえば、オーケストレータ202は、候補エッジ層およびエッジ・プラットフォーム配置のそれぞれについて、動作パラメータ割合を決定する。示された例の動作パラメータ割合は、エッジ・プラットフォームの資源要件を満足するエッジ層およびエッジ・プラットフォーム配置の資源利用可能性のパーセンテージに対応する。たとえば、オーケストレータ202は、2つのコアをもつプロセッサを必要とする作業負荷を実行する要求を受け取ることがある。この例では、オーケストレータ202は、機能コントローラ204および／またはEPデータベース208にアクセスして、候補エッジ層およびエッジ・プラットフォーム配置のそれぞれについての動作パラメータ割合を決定することができる。この例では、オーケストレータ202は、1つの候補エッジ層およびエッジ・プラットフォーム配置が100%の動作パラメータ割合を有する（すなわち、2つのコアをもつプロセッサを有する）こと、および、残りの候補エッジ層およびエッジ・プラットフォーム配置が0%の動作パラメータ割合を有する（すなわち、2つのコアをもつプロセッサを有しない）ことを判別することができる。いくつかの例では、オーケストレータ202は、ある候補エッジ層およびエッジ・プラットフォーム配置がエッジ環境において最も近く、利用可能であり、最も安価であることを判別してもよい。よって、オーケストレータ202は、他の最適な動作パラメータ割合（たとえば、利用可能でない、より高価である、などのエッジ層配置）より高い最適な動作パラメータ割合を決定してもよい。

ブロック604では、オーケストレータ202は、最適な動作パラメータ割合をもつエッジ層およびエッジ・プラットフォーム配置を、候補エッジ層およびエッジ・プラットフォーム配置として選択する。

ブロック606では、オーケストレータ202は、動作パラメータ割合が閾値を満たすかどうかを判定する。たとえば、例示された例のオーケストレータ202は、最適な動作パラメータ割合（たとえば、70%、所望の動作パラメータの最大の集計値（aggregate）など）をもつエッジ層およびエッジ・プラットフォーム配置を選択し、その動作パラメータ割合を閾値（たとえば、75%、80%、90%など）と比較する。オーケストレータ202が動作パラメータ割合が閾値を満足すると判断した場合、機械読み取り可能な命令308はブロック608に進み、オーケストレータ202は候補層エッジ配置において作業負荷を実施する。

オーケストレータ202が、動作パラメータ割合が閾値を満足しないと判断した場合、機械読み取り可能な命令308はブロック610に進み、反復工程の数が閾値より下であるかどうかを判定する。たとえば、要求がオーケストレータ202によって受信され処理されてエッジ層およびエッジ・プラットフォーム配置を決定するたびに、反復工程カウントが決定される。たとえば、オーケストレータ202は、第1の反復工程の間に、第1の要求を受信して処理し、候補エッジ層およびエッジ・プラットフォーム配置を決定することができる。よって、該要求には1の反復工程カウントを含む。すなわち、オーケストレータ202は、第1の反復工程の間に、要求のSLA属性を満たすエッジ層およびエッジ・プラットフォーム配置を決定することができた。オーケストレータ202が、反復工程の数が閾値（たとえば、5、8、12など）より下でないと判断した場合は、機械読み取り可能な命令308は終了する。たとえば、作業負荷の実行に関連するコストがコスト関数閾値を超えた（たとえば、SLA属性が満たされなかった）ために、反復工程の数が閾値を超えた。

オーケストレータ202が、反復工程の数が閾値より下であると判断した場合、機械読み取り可能な命令308はブロック612に進み、反復工程カウントを増加させる。

ブロック614では、オーケストレータ202は、資源要件およびコスト関数重みを調整する。たとえば、オーケストレータ202は、動作パラメータ割合閾値を下げることによって資源要件を調整することができ、特定の候補エッジ層およびエッジ・プラットフォーム配置において作業負荷を実行するために費やすことができる金額などに関連するコスト関数を増加させることができる。いくつかの例では、オーケストレータ202は、候補エッジ層およびエッジ・プラットフォーム配置において作業負荷を実施するために費やすことができる金額を増加させる。たとえば、オーケストレータ202は、ブロック614でコスト関数重みを更新し（たとえば、支出可能な金額を増加させる、利用できる資源の量を増加させる、利用できるエッジ・プラットフォームの量を増加させる、など）、ブロック602に戻ることができる。機械読み取り可能な命令308は、作業負荷を実施した後に機械読み取り可能な命令300に戻るか、または反復工程の数が超過したときには終了する。

図7は、図3～図6の命令を実行してエッジ・プラットフォーム200を実装するように構成された例示的なプロセッサプラットフォーム700のブロック図である。プロセッサプラットフォーム700は、たとえば、サーバー、パーソナルコンピュータ、ワークステーション、自己学習マシン（たとえばニューラルネットワーク）、モバイル装置（たとえば、携帯電話、スマートフォン、iPad（登録商標）のようなタブレット）、パーソナルデジタルアシスタント（PDA）、インターネットアプライアンス、DVDプレーヤー、CDプレーヤー、デジタルビデオレコーダー、ブルーレイプレーヤー、ゲームコンソール、パーソナルビデオレコーダー、セットトップボックス、ヘッドセット、またはその他のウェアラブル装置、またはその他の任意のタイプのコンピューティング装置でありうる。

図示された例のプロセッサプラットフォーム700は、プロセッサ712を含む。図示された例のプロセッサ712は、ハードウェアである。たとえば、プロセッサ712は、一つまたは複数の集積回路、論理回路、マイクロプロセッサ、GPU、DSP、または任意の所望のファミリーまたは製造業者のコントローラによって実装できる。ハードウェアプロセッサは、半導体ベースの（たとえば、シリコンベースの）デバイスであってもよい。この例では、プロセッサは、例示的なオーケストレータ202、例示的な機能コントローラ204、例示的なテレメトリー・コントローラ206、例示的なEPデータベース208、例示的な資源210、および／または、より一般には、例示的なエッジ・プラットフォーム200を実装する。

図示された例のプロセッサ712は、ローカルメモリ713（たとえば、キャッシュ）を含む。図示された例のプロセッサ712は、バス718を介して、揮発性メモリ714および不揮発性メモリ716を含むメインメモリと通信している。揮発性メモリ714は、同期動的ランダムアクセスメモリ（SDRAM）、動的ランダムアクセスメモリ（DRAM）、RAMBUS（登録商標）動的ランダムアクセスメモリ（RDRAM（登録商標））および／または任意の他のタイプのランダムアクセスメモリ・デバイスによって実装されうる。不揮発性メモリ716は、フラッシュメモリおよび／または任意の他の所望のタイプのメモリデバイスによって実装されうる。メインメモリ714、716へのアクセスは、メモリコントローラによって制御される。

図示された例のプロセッサプラットフォーム700は、インターフェース回路720をも含む。インターフェース回路720は、イーサネットインターフェース、ユニバーサルシリアルバス（USB）、Bluetooth（登録商標）インターフェース、近接場通信（NFC）インターフェース、および／またはPCIエクスプレス・ンターフェースなど、任意のタイプのインターフェース規格によって実装されうる。

図示された例では、一つまたは複数の入力装置722がインターフェース回路720に接続されている。入力装置722は、ユーザーがデータおよび／またはコマンドをプロセッサ712に入力することを可能にする。入力装置は、たとえば、オーディオセンサー、マイクロフォン、カメラ（スチールまたはビデオ）、キーボード、ボタン、マウス、タッチスクリーン、トラックパッド、トラックボール、アイソポイント、および／または音声認識システムによって実装できる。

一つまたは複数の出力装置724も、図示された例のインターフェース回路720に接続される。出力装置724は、たとえば、ディスプレイ装置（たとえば、発光ダイオード（LED）、有機発光ダイオード（OLED）、液晶ディスプレイ（LCD）、陰極線管ディスプレイ（CRT）、現場スイッチング（in-place switching、IPS）ディスプレイ、タッチスクリーンなど）、触覚出力装置、プリンタおよび／またはスピーカーによって実装できる。よって、図示された例のインターフェース回路720は、典型的には、グラフィックスドライバカード、グラフィックスドライバチップ、および／またはグラフィックスドライバプロセッサを含む。

図示された例のインターフェース回路720は、ネットワーク726を介して外部マシン（たとえば、任意の種類のコンピューティング装置）とのデータの交換を容易にするために、送信機、受信機、トランシーバ、モデム、住宅ゲートウェイ、無線アクセスポイント、および／またはネットワークインターフェースのような通信装置をも含む。通信は、たとえば、イーサネット接続、デジタル加入者線（DSL）接続、電話線接続、同軸ケーブルシステム、衛星システム、ライン・オブ・サイト無線システム、セルラー電話システムなどを介して行なうことができる。

図示された例のプロセッサプラットフォーム700はまた、ソフトウェアおよび／またはデータを記憶するための一つまたは複数の大容量記憶装置728をも含む。そのような大容量記憶装置728の例は、フロッピーディスクドライブ、ハードドライブディスク、コンパクトディスクドライブ、ブルーレイディスクドライブ、独立ディスクの冗長アレイ（RAID）システム、およびデジタル多用途ディスクドライブを含む。

図3～図6の機械実行可能な命令732は、大容量記憶装置728内、揮発性メモリ714内、不揮発性メモリ716内、および／またはCDまたはDVDのようなリムーバブルな非一時的なコンピュータ読み取り可能記憶媒体上に記憶されてもよい。

図7の例示的なコンピュータ読み取り可能命令732のようなソフトウェアを第三者に配布するための例示的なソフトウェア配布プラットフォーム805を示すブロック図が図8に示されている。例示的なソフトウェア配布プラットフォーム805は、ソフトウェアを記憶し、他のコンピューティング装置に送信することができる任意のコンピュータ・サーバー、データ設備、クラウド・サービスなどによって実装されうる。第三者は、ソフトウェア配布プラットフォームを所有および／または運営するエンティティの顧客であってもよい。たとえば、ソフトウェア配布プラットフォームを所有および／または運営するエンティティは、図7の例示的なコンピュータ読み取り可能な命令732のようなソフトウェアの開発者、販売者、および／またはライセンサーであってもよい。第三者は、使用および／または再販売および／またはサブライセンシングのためにソフトウェアを購入および／またはライセンスする消費者、ユーザー、小売業者、OEMなどでありうる。図示された例では、ソフトウェア配布プラットフォーム805は、一つまたは複数のサーバーおよび一つまたは複数の記憶装置を含む。記憶装置は、上述のように、図3～図6の例示的なコンピュータ読み取り可能な命令300に対応しうるコンピュータ読み取り可能な命令732を記憶する。例示的なソフトウェア配布プラットフォーム805の前記一つまたは複数のサーバーは、ネットワーク810と通信しており、ネットワーク810は、インターネットおよび／または上記の例示的なネットワークのうちのいずれかの一つまたは複数に対応しうる。いくつかの例では、前記一つまたは複数のサーバーは、商業取引の一部として、ソフトウェアを要求者に送信する要求に応答する。ソフトウェアの配信、販売、および／またはライセンスに対する支払いは、ソフトウェア配信プラットフォームの前記一つまたは複数のサーバーによって、および／またはサードパーティーの支払い機関によって処理されうる。サーバーは、購入者および／またはライセンサーが、ソフトウェア配布プラットフォーム805からコンピュータ読み取り可能な命令732をダウンロードすることを可能にする。たとえば、図7の例示的なコンピュータ読み取り可能な命令732に対応しうるソフトウェアは、例示的なプロセッサプラットフォーム1000にダウンロードされてもよく、該例示的なプロセッサプラットフォームが、エッジ・プラットフォーム200を実装するためにコンピュータ読み取り可能な命令732を実行する。いくつかの例では、ソフトウェア配布プラットフォーム805の一つまたは複数のサーバーは、改良、パッチ、更新等が配布され、エンドユーザー装置において当該ソフトウェアに適用されることを確実にするために、ソフトウェア（たとえば、図7の例示的なコンピュータ読み取り可能な命令732）に対する更新を定期的に提供、送信、および／または強制する。

図9は、以下の例の多くで「エッジ・クラウド」として言及される処理のレイヤーを含む、エッジ・コンピューティングのための構成の概観を示すブロック図900である。図示されるように、エッジ・クラウド910は、アクセスポイントまたは基地局940、ローカル処理ハブ950、または中央オフィス920のようなエッジ位置に共配置され（co-located）、よって、複数のエンティティ、装置、および機器インスタンスを含むことができる。エッジ・クラウド910は、クラウド・データセンター930よりもエンドポイント（消費者および生産者）データ源960（たとえば、自律車両961、ユーザー機器962、ビジネスおよび産業設備963、ビデオ捕捉装置964、ドローン965、スマートシティおよびビルディング装置966、センサーおよびIoT装置967など）のずっと近くに配置される。エッジ・クラウド910内のエッジにおいて提供される計算、メモリ、および記憶資源は、エンドポイント・データ源960によって使用されるサービスおよび機能のための超低レイテンシー応答時間を提供するとともに、エッジ・クラウド910からクラウド・データセンター930へのネットワーク・バックホール・トラフィックを低減するのに枢要であり、これにより、他の利点の中でも、エネルギー消費および全体的なネットワーク利用を改善する。いくつかの例では、エッジ・プラットフォーム200は、エッジ・クラウド910内で実装できる。いくつかの例では、図1～8に関連して上述したエッジ・プラットフォーム200は、アクセスポイントまたは基地局940、ローカル処理ハブ950、中央オフィス920、データ源960（たとえば、自律車両961、ユーザー機器962、ビジネスおよび産業設備963、ビデオ捕捉装置964、ドローン965、スマートシティおよびビルディング装置966、センサーおよびIoT装置967など）、またはクラウド・データセンター930のいずれかとして実装できる。いくつかの例では、エッジ・プラットフォーム200は、図9～図15Bに開示された例を用いて実装できる。

計算、メモリ、およびストレージは、希少な資源であり、一般に、エッジ位置に依存して減少する（たとえば、中央オフィスよりも基地局で、基地局よりも消費者エンドポイント装置で、利用可能な処理資源が少ない）。しかしながら、エッジ位置がエンドポイント（たとえば、UE）に近いほど、空間と電力が制約されることが多い。よって、エッジ・コンピューティングは、地理的およびネットワーク・アクセス時間の両方でより近くに位置する資源をより多く分配することを通じて、ネットワーク・サービスに必要とされる資源の量を減らそうと試みる。このように、エッジ・コンピューティングは、適宜、計算資源を作業負荷データのところにもってくるか、または作業負荷データを計算資源のところにもっていこうとする。

以下は、複数の潜在的な展開をカバーし、一部のネットワーク事業者やサービス・プロバイダーが自身のインフラストラクチャーにおいてもつ可能性のある制約に対処するエッジ・クラウド・アーキテクチャーの諸側面を記述する。これらは、エッジ位置に基づく構成のバリエーション（たとえば、基地局レベルでのエッジは、マルチテナント・シナリオにおいて、より制約された性能および機能を有する可能性があるため）；エッジ位置、位置の層、または位置のグループに対して利用可能な計算、メモリ、ストレージ、ファブリック、アクセラレーション、または同様の資源のタイプに基づく構成；サービス、セキュリティ、および管理およびオーケストレーション機能；ならびに、エンドサービスの使い勝手および性能を達成するための関連目的のバリエーションを含む。これらの展開は、レイテンシー、距離、およびタイミング特性に依存して、「近エッジ（near edge）」、「クロース・エッジ（close edge）」、「ローカル・エッジ」、「中間エッジ」、または「遠エッジ」レイヤーとみなすことができるネットワーク・レイヤーにおける処理を達成することができる。

エッジ・コンピューティングは、ネットワークの「エッジ」において、または「エッジ」により近いところで、典型的には、基地局、ゲートウェイ、ネットワーク・ルータ、またはデータを生成および消費するエンドポイント装置にずっと近い他の装置において（たとえば、「ローカル・エッジ」、「クロース・エッジ」、または「近エッジ」において）実装される計算プラットフォーム（たとえば、x86またはARM計算ハードウェアアーキテクチャー）の使用を通じて、コンピューティングが実行される発達中のパラダイムである。たとえば、エッジ・ゲートウェイ・サーバーは、接続されたクライアント装置のための低レイテンシーの使用事例（たとえば、自律運転またはビデオ監視）のためにリアルタイムで計算を実行するために、メモリおよび記憶資源のプールを備えることができる。あるいは、一例として、基地局は、バックホール・ネットワークを介してデータをさらに通信することなく、接続されたユーザー機器のためのサービス作業負荷を直接処理するために、計算および加速資源で増強されてもよい。あるいは、別の例として、中央オフィス・ネットワーク管理ハードウェアが、仮想化されたネットワーク機能を実行し、接続された装置のためのサービスおよび消費者機能の実行のための計算資源を提供する標準化された計算ハードウェアで置き換えられてもよい。エッジ・コンピューティング・ネットワーク内では、計算資源がデータのところに「移動」されるサービスでのシナリオ、およびデータが計算資源のところに「移動」されるシナリオが存在しうる。あるいは、一例として、基地局の計算、加速、およびネットワーク資源は、休眠容量をアクティブ化することにより、必要に応じて作業負荷需要をスケーリングするためのサービスを提供することができる（オンデマンドの容量、加入）。きわどい希少事例〔コーナーケース〕、緊急事態を管理するため、または、展開された資源についてかなり長めの実装ライフサイクルにわたって長寿命化を提供するためである。

図10は、エンドポイント、エッジ・クラウド、およびクラウド・コンピューティング環境の間の動作レイヤーを示す。具体的には、図10は、ネットワーク・コンピューティングの複数の例示的なレイヤーの間でエッジ・クラウド910を利用する、計算使用事例1005の例を示す。これらのレイヤーは、エッジ・クラウド910にアクセスしてデータ作成、解析、およびデータ消費活動を実施するエンドポイント（装置およびモノ）レイヤー1000で始まる。エッジ・クラウド910は、複数のネットワーク・レイヤー、たとえば、物理的に近接したエッジ・システム内に位置するゲートウェイ、オンプレミス・サーバー、またはネットワーク機器（ノード1015）を有するエッジ装置レイヤー1010；基地局、無線処理ユニット、ネットワークハブ、地域データセンター、またはローカルネットワーク機器（機器1025）を含むネットワーク・アクセス・レイヤー1020；およびそれらの間に位置する任意の機器、装置、またはノード（レイヤー1012、詳細には図示せず）にまたがってもよい。エッジ・クラウド910内およびさまざまなレイヤーの間のネットワーク通信は、図示されていない接続アーキテクチャーおよび技術を介するものを含め、任意の数の有線または無線媒体を介して行なわれてもよい。

ネットワーク通信距離および処理時間の制約から帰結するレイテンシーの例は、エンドポイント・レイヤー1000の中ではミリ秒（ms）未満、エッジ装置レイヤー1010（たとえば、「近エッジ」または「クロース・エッジ」レイヤー）では5ミリ秒未満、ネットワーク・アクセス・レイヤー1020（たとえば、「中間エッジ」レイヤー）にあるノードと通信する場合は10～40ミリ秒の範囲でありうる。エッジ・クラウド910の外側には、コア・ネットワーク1030およびクラウド・データセンター1040のレイヤーがあり、それぞれレイテンシーが増加する（たとえば、コア・ネットワーク・レイヤー1030では50～60msの間、クラウド・データセンター・レイヤーでは100ms以上、いずれも「遠エッジ」レイヤーと考えてもよい）。結果として、コア・ネットワーク・データセンター1035またはクラウド・データセンター1045における、少なくとも50～100ms以上のレイテンシーを有する動作は、使用事例1005の多くの時間クリティカルな機能を達成することができない。これらのレイテンシー値のそれぞれは、例解およびコントラストの目的のために提供されており、他のアクセス・ネットワーク媒体および技術の使用がレイテンシーをさらに短縮しうることが理解されるであろう。

さまざまな使用事例1005は、複数のサービスがエッジ・クラウドを利用するため、はいってくるストリームからの使用圧力の下で資源にアクセスすることがある。低いレイテンシーで結果を達成するために、エッジ・クラウド910内で実行されるサービスは、次のものに関するさまざまな要件をバランスさせる：（a）優先度（スループットまたはレイテンシー）およびサービス品質（QoS）（たとえば、自律自動車のためのトラフィックは、応答時間要件に関して温度センサーよりも高い優先度を有することがある；または、アプリケーションに依存して、計算／アクセラレータ、メモリ、記憶、またはネットワーク資源においてパフォーマンス敏感さ／ボトルネックが存在することがある）、（b）信頼性および弾力性（たとえば、いくつかの入力ストリームはミッションクリティカルな信頼性をもって作用され、トラフィックがルーティングされる必要があり、一方、いくつかの他の入力ストリームは、アプリケーションに依存して、時折の障害は許容しうる）、および（c）物理的制約（たとえば、電力、冷却、および形状因子）。

これらの使用事例のエンドツーエンド・サービス・ビューは、サービスフローの概念を含み、トランザクションに関連付けられる。トランザクションは、サービスを消費するエンティティについての全体的なサービス要件と、資源、作業負荷、作業フロー、ビジネス機能およびビジネス・レベルの要件についての関連するサービスとを詳述する。記載された「条件」で実行されるサービスは、サービスのライフサイクルの間のトランザクションについてリアルタイムで、ランタイムの契約遵守を保証するように、各レイヤーにおいて管理されうる。トランザクションにおけるあるコンポーネントがその合意されたSLAを満たしていない場合、システム全体（トランザクションにおける諸コンポーネント）は、（1）SLA違反の影響を理解し、（2）全体的なトランザクションSLAを取り戻すためにシステム内の他のコンポーネントを増強し、（3）是正するための諸ステップを実装する能力を提供しうる。いくつかの例では、そのような是正のコストまたはペナルティは、図3～図6に関連して上述したようなコスト関数重みとして該是正を利用することによって、作業負荷の配置を決定する際にオーケストレータ202によって利用されることができる。

このように、これらのバリエーションおよびサービス機能を念頭に置くと、エッジ・クラウド910内のエッジ・コンピューティングは、リアルタイムまたはほぼリアルタイムで、使用事例1005の複数のアプリケーション（たとえば、オブジェクト追跡、ビデオ監視、接続された車両など）にサービスし、応答するとともに、これらの複数のアプリケーションについての超低レイテンシー要件を満たす能力を提供することができる。これらの利点は、レイテンシーまたは他の制限のため従来のクラウド・コンピューティングを利用できない全く新しいクラスのアプリケーション（仮想ネットワーク機能（VNF）、サービスとしての機能（FaaS）、サービスとしてのエッジ（EaaS）、標準プロセスなど）を可能にする。

しかしながら、エッジ・コンピューティングの利点には、以下の注意点がある。エッジに配置された装置は、しばしば資源が制約され、そのため、エッジ資源の使用に圧力がかかる。典型的には、これは、複数のユーザー（テナント）および装置によって使用されるためのメモリおよびストレージ資源のプールを通じて対処される。エッジは、電力および冷却が制約される可能性があり、よって、電力使用量は、最も電力を消費しているアプリケーションによって説明される必要がある。これらのプールされたメモリ資源の多くは、より多くの電力がより大きなメモリ帯域幅を必要とする新興のメモリ技術を使用する可能性が高いため、これらの資源には本来的な電力‐パフォーマンスのトレードオフが存在する可能性がある。同様に、エッジ位置が無人である可能性があり、許可されたアクセスを必要とする（たとえば、第三者の場所に収容されている場合）可能性さえあるため、ハードウェアの改善されたセキュリティおよび信頼される機能の信頼ルートも必要とされる。そのような問題は、サービスおよびアプリケーションが多数のユーザーによって要求されるマルチテナント、マルチオーナー、またはマルチアクセス場面において、エッジ・クラウド910において拡大される。特に、ネットワークの使用が動的に変動し、複数のステークホルダー、使用事例、およびサービスの組成が変化するからである。

より一般的なレベルでは、エッジ・コンピューティング・システムは、クライアントおよび分散コンピューティング装置からの協調を提供する、エッジ・クラウド910内で動作する前述の諸レイヤー（ネットワーク・レイヤー1000～1040）における任意の数の展開を包含するように記載されてもよい。一つまたは複数のエッジ・ゲートウェイ・ノード、一つまたは複数のエッジ集約ノード、および一つまたは複数のコア・データセンターは、ネットワークの諸レイヤーにわたって分散されて、電気通信サービス・プロバイダー（「電話会社」または「TSP」）、モノのインターネット・サービス・プロバイダー、クラウド・サービス・プロバイダー（CSP）、企業エンティティ、または他の任意の数のエンティティによって、またはそれらに代わって、エッジ・コンピューティング・システムの実装を提供してもよい。エッジ・コンピューティング・システムのさまざまな実装および構成は、サービス目標を満たすようにオーケストレーションされるときのように、動的に提供されてもよい。

本明細書で提供される例と整合して、クライアント計算ノードは、データの生産者または消費者として通信することができる任意のタイプのエンドポイント・コンポーネント、装置、アプライアンス、または他のものとして具現されうる。さらに、エッジ・コンピューティング・システムにおいて使用されるようなラベル「ノード」または「装置」は、必ずしもそのようなノードまたは装置がクライアントまたはエージェント／ミニオン／フォロワーの役割で動作することを意味するのではなく、むしろ、エッジ・コンピューティング・システムにおけるノードまたは装置の任意のものは、エッジ・クラウド910を促進または使用するための離散的なまたは接続されたハードウェアまたはソフトウェア構成を含む個々のエンティティ、ノードまたはサブシステムを指す。

よって、エッジ・クラウド910は、ネットワーク・レイヤー1010～1030の間で、エッジ・ゲートウェイ・ノード、エッジ集約ノード、または他のエッジ計算ノードによっておよびその内部で動作させられるネットワーク・コンポーネントおよび機能的特徴から形成される。よって、エッジ・クラウド910は、本明細書に記載される無線アクセス・ネットワーク（RAN）対応のエンドポイント装置（たとえば、モバイルコンピューティング装置、IoT装置、スマートデバイスなど）に近接して位置する、エッジ・コンピューティングおよび／または記憶資源を提供する任意のタイプのネットワークとして具現されうる。換言すれば、エッジ・クラウド910は、エンドポイント装置と、伝統的なネットワーク・アクセスポイントとを接続する「エッジ」として想定されてもよい。伝統的なネットワーク・アクセスポイントは、記憶および／または計算機能をも提供しつつ、モバイルキャリアネットワーク（たとえば、グローバル移動通信システム（GSM）ネットワーク、ロングタームエボリューション（LTE）ネットワーク、5G/6Gネットワークなど）を含むサービス・プロバイダー・コア・ネットワークへの入口点として機能するものである。他のタイプおよび形態のネットワーク・アクセス（たとえば、Wi-Fi、光ネットワークを含む長距離の無線、有線ネットワーク）も、そのような3GPPキャリア・ネットワークの代わりに、またはそれと組み合わせて利用されうる。

エッジ・クラウド910のネットワーク・コンポーネントは、サーバー、マルチテナントサーバー、アプライアンスコンピューティング装置、および／または任意の他のタイプのコンピューティング装置であってもよい。たとえば、エッジ・クラウド910は、ハウジング、シャーシ、ケースまたはシェルを含む自己完結型の電子装置であるアプライアンスコンピューティング装置を含んでいてもよい。いくつかの状況では、ハウジングは、人が持ち運ぶ、および／または輸送されることができるように、可搬性のために寸法決めされてもよい。例示的なハウジングは、アプライアンスの内容物を部分的または完全に保護する一つまたは複数の外面を形成する材料を含んでいてもよく、保護は、天候保護、危険な環境保護（たとえば、EMI、振動、極端な温度）を含み、および／または水に沈めるのを可能にすることを含んでいてもよい。例示的なハウジングは、AC電力入力、DC電力入力、AC/DCまたはDC/ACコンバータ、電力レギュレータ、変圧器、充電回路、バッテリー、有線入力および／または無線電力入力のような、固定および／またはポータブル実装のための電力を供給するための電力回路を含んでいてもよい。例示的なハウジングおよび／またはその表面は、建物、電気通信構造（たとえば、ポール、アンテナ構造など）および／またはラック（たとえば、サーバーラック、ブレードマウントなど）への取り付けを可能にするために、取り付けハードウェアを含んでいてもよく、または取り付けハードウェアに接続してもよい。例示的なハウジングおよび／またはその表面は、一つまたは複数のセンサー（たとえば、温度センサー、振動センサー、光センサー、音響センサー、容量性センサー、近接センサーなど）を支持してもよい。一つまたは複数のそのようなセンサーは、アプライアンスの表面に含まれていてもよいし、表面によって担持されていてもよいし、または他の仕方で表面に埋め込まれていてもよいし、および／または表面に取り付けられていてもよい。例示的なハウジングおよび／またはその表面は、推進ハードウェア（たとえば、ホイール、プロペラなど）および／または関節式で動くハードウェア（たとえば、ロボットアーム、旋回可能な付属肢など）のような機械的接続性を支持してもよい。いくつかの状況では、センサーは、ユーザーインターフェースハードウェア（たとえば、ボタン、スイッチ、ダイヤル、スライダーなど）のような任意のタイプの入力装置を含んでいてもよい。いくつかの状況では、例示的なハウジングは、その中に含まれる、その中に担持される、その中に埋め込まれる、および／またはそれに取り付けられる出力装置を含む。出力装置は、ディスプレイ、タッチスクリーン、ライト、LED、スピーカー、I/Oポート（たとえば、USB）などを含むことができる。いくつかの状況では、エッジ装置は、特定の目的（たとえば、交通信号）のためにネットワーク内に提示される装置であるが、他の目的のために利用されうる処理および／または他の力量を有していてもよい。そのようなエッジ装置は、他のネットワーク装置から独立していてもよく、その主要な目的に適した形状因子を有するハウジングを備えていてもよく、それでいて、その主要なタスクに干渉しない他の計算タスクのためにも利用可能であってもよい。エッジ装置は、モノのインターネット装置を含む。アプライアンスコンピューティング装置は、装置温度、振動、資源利用、更新、電力問題、物理的およびネットワーク・セキュリティなどの局所的な問題を管理するためのハードウェアおよびソフトウェア・コンポーネントを含んでいてもよい。アプライアンスコンピューティング装置を実装するための例示的なハードウェアが、図7Bとの関連で記載されている。エッジ・クラウド910は、一つまたは複数のサーバーおよび／または一つまたは複数のマルチテナントサーバーをも含んでいてもよい。そのようなサーバーは、オペレーティング・システムおよび仮想コンピューティング環境を含んでいてもよい。仮想コンピューティング環境は、一つまたは複数の仮想マシン、一つまたは複数のコンテナなどを管理（派生（spawning）、展開、破棄など）するハイパーバイザーを含んでいてもよい。そのような仮想コンピューティング環境は、一つまたは複数のアプリケーションおよび／または他のソフトウェア、コードまたはスクリプトが、一つまたは複数の他のアプリケーション、ソフトウェア、コードまたはスクリプトから隔離されている間に実行されうる実行環境を提供する。

図11は、さまざまなクライアント・エンドポイント1110（モバイル装置、コンピュータ、自律自動車、ビジネス・コンピューティング装置、工業用処理設備の形のもの）が、例示的なエッジ・クラウド910と要求および応答を交換する例示的な環境1100のブロック図を示す。たとえば、コンピュータ、ビジネス・コンピューティング装置、および工業用処理設備は、オンプレミス・ネットワーク・システム1132を通じて要求および応答1122を交換することによって、有線ブロードバンド・ネットワークを介してネットワーク・アクセスを得ることができる。モバイルコンピューティング装置は、セルラー・ネットワーク・タワー1134を通じて要求および応答1124を交換することによって、無線ブロードバンド・ネットワークを介してネットワーク・アクセスを得ることができる。自律車両は、街頭に配置されたネットワーク・システム1136を通じて無線車両ネットワークを介して、要求および応答1126のためのネットワーク・アクセスを得ることができる。しかしながら、ネットワーク・アクセスのタイプに関係なく、TSPは、トラフィックおよび要求を集約するために、エッジ・クラウド910内に集約ポイント1142、1144を展開することができる。よって、エッジ・クラウド910内で、TSPは、要求されたコンテンツを提供するために、エッジ集約ノード1140におけるような、さまざまな計算および記憶資源を展開してもよい。エッジ集約ノード1140およびエッジ・クラウド910の他のシステムは、クラウドまたはデータセンター1160に接続され、クラウドまたはデータセンター1160は、ウェブサイト、アプリケーション、データベース・サーバーなどのためのクラウド／データセンターからの、より高いレイテンシーの要求を満たすために、バックホール・ネットワーク1150を使用する（エッジ集約ノード1140および集約ポイント1142、1144の追加的なまたは統合されたインスタンスは、単一のサーバー・フレームワーク上に展開されるものを含めて、エッジ・クラウド910またはTSPインフラストラクチャーの他の領域内にも存在してもよい）。

図12は、複数のエッジ・ノードおよび複数のテナントの間で動作させられるエッジ・コンピューティング・システムを横断した仮想エッジ構成についての展開およびオーケストレーションを示す。具体的には、図12は、さまざまな仮想エッジ・インスタンスにアクセスするさまざまなクライアント・エンドポイント1210（たとえば、スマートシティ／ビルディング・システム、モバイル装置、コンピューティング装置、ビジネス／ロジスティクス・システム、産業システムなど）についての要求および応答を満たすための、エッジ・コンピューティング・システム1200における第1のエッジ・ノード1222および第2のエッジ・ノード1224の協調を示す。ここで、仮想エッジ・インスタンスは、エッジ・クラウドにおいてエッジ計算機能および処理を提供し、ウェブサイト、アプリケーション、データベース・サーバーなどのためのより高いレイテンシーの要求のためにはクラウド／データセンター1240へのアクセスがある。しかしながら、エッジ・クラウドは、複数のテナントまたはエンティティのための複数のエッジ・ノード間での処理の調整を可能にする。

図12の例では、これらの仮想エッジ・インスタンスは：エッジ記憶、コンピューティング、およびサービスの第1の組み合わせを提供する第1のテナント（テナント1）に提供される第1の仮想エッジ1232と、エッジ記憶、コンピューティング、およびサービスの第2の組み合わせを提供する第2の仮想エッジ1234とを含む。仮想エッジ・インスタンス1232、1234は、エッジ・ノード1222、1224の間に分散され、要求および応答が同じまたは異なるエッジ・ノードから満たされるシナリオを含んでいてもよい。分散されているが協調した仕方で動作するようにするエッジ・ノード1222、1224の構成は、エッジ・プロビジョニング機能1250に基づいて行なわれる。複数のテナントの間で、アプリケーションおよびサービスのための協調した動作を提供するためのエッジ・ノード1222、1224の機能性は、オーケストレーション機能1260に基づいて生じる。

1210内の装置のいくつかは、テナント1がテナント1「スライス」内で機能する一方、テナント2がテナント2スライス内で機能するマルチテナント装置であることが理解されるべきである（さらなる例では、追加的なテナントまたはサブテナントが存在してもよく、各テナントは、特定のハードウェア機能に至るまで、特定的にタイトルを与えられ、トランザクション上、特定の機能セットに結びつけられることさえある）。信頼されるマルチテナント装置は、さらに、テナント固有の暗号鍵を含んでいてもよく、鍵とスライスの組み合わせが「信頼のルート」（root of trust、RoT）またはテナント固有のRoTとみなされてもよい。RoTはさらに、DICE（Device Identity Composition Engine［装置アイデンティティ合成エンジン］）アーキテクチャーを使用して動的に計算されて、構成されてもよく、それにより、装置機能のレイヤー構成のためのレイヤー構成にされた信頼されるコンピューティング・ベース・コンテキストを構築するために、単一のDICEハードウェア構築ブロックが使用されてもよい（たとえばフィールドプログラマブルゲートアレイ（FPGA））。RoTは、さらに、信頼されたコンピューティング・コンテキストがマルチテナント性をサポートするために有用な「ファンアウト」を可能にするために使用されてもよい。マルチテナント環境内では、各エッジ・ノード1222、1224は、ノード毎に複数のテナントに割り当てられるローカル資源についてのセキュリティ機能強制ポイントとして動作することができる。さらに、テナントのランタイムおよびアプリケーション実行（たとえば、インスタンス1232、1234におけるもの）は、潜在的に複数の物理ホスティング・プラットフォームにまたがる資源の仮想エッジ抽象化を作り出すセキュリティ機能のための強制ポイントとして機能してもよい。最後に、オーケストレーション・エンティティにおけるオーケストレーション機能1260は、テナント境界に沿って資源をマーシャリングする（marshalling）ためのセキュリティ機能強制ポイントとして動作してもよい。

エッジ・コンピューティング・ノードは、資源（メモリ、CPU、GPU、割り込みコントローラ、I/Oコントローラ、メモリコントローラ、バスコントローラなど）を分割することができ、ここで、それぞれの分割は、RoT機能を含んでいてもよく、DICEモデルによるファンアウトおよびレイヤー構成がさらにエッジ・ノードに適用されてもよい。コンテナ、FaaSエンジン、サーブレット、サーバー、または他の計算抽象化からなるクラウド・コンピューティング・ノードは、DICEレイヤー構成およびファンアウト構造に従って分割され、それぞれについてのRoTコンテキストをサポートしてもよい。よって、諸RoTにまたがるそれぞれの装置1210、1222、および1240は、すべての要素をエンドツーエンドでリンクするテナント固有の仮想的な信頼される安全なチャネルが確立できるように、分散信頼計算ベース（distributed trusted computing base、DTCB）の確立を調整することができる。

さらに、コンテナは、以前のエッジ・ノードからそのコンテンツを保護するデータまたは作業負荷固有の鍵を有していてもよいことが理解されるであろう。コンテナのマイグレーションの一部として、源エッジ・ノードにおけるポッドコントローラは、ターゲット・エッジ・ノードのポッドコントローラからマイグレーション鍵を取得することができ、ここで、マイグレーション鍵がコンテナ固有の鍵をラップする（wrap）ために使用される。コンテナ／ポッドがターゲット・エッジ・ノードにマイグレーションされると、アンラップ鍵がポッドコントローラに対して露出され、ポッドコントローラがその後、ラップされた鍵を解読する。これで鍵は、コンテナ固有のデータに対する操作を実行するために使用されうる。マイグレーション機能は、適正に認証されたエッジ・ノードおよびポッド・マネージャー（上述）によってゲートされてもよい。

さらなる例では、エッジ・コンピューティング・システムが拡張されて、マルチオーナー、マルチテナント環境におけるコンテナ（コードおよび必要な依存性を提供するソフトウェアの、収容された、展開可能なユニット）の使用を通じて、複数のアプリケーションのオーケストレーションを提供する。マルチテナント・オーケストレータは、図12の信頼される「スライス」概念のプロビジョニングおよびライフサイクルに関連する鍵管理、信頼アンカー管理、および他のセキュリティ機能を実行するために使用されうる。たとえば、エッジ・コンピューティング・システムは、複数の仮想エッジ・インスタンスから（および、クラウドまたはリモートのデータセンターから）のさまざまなクライアント・エンドポイントについて要求および応答を満たすように構成されてもよい。これらの仮想エッジ・インスタンスの使用は、複数のテナントおよび複数のアプリケーション（たとえば、拡張現実（AR）／仮想現実（VR）、企業アプリケーション、コンテンツ配信、ゲーム、計算オフロード）を同時にサポートしうる。さらに、仮想エッジ・インスタンス内には、複数のタイプのアプリケーション（たとえば、通常のアプリケーション、レイテンシーに敏感なアプリケーション、レイテンシークリティカルなアプリケーション、ユーザープレーンのアプリケーション、ネットワーキングアプリケーションなど）が存在しうる。仮想エッジ・インスタンスは、異なる地理的位置にある複数の所有者のシステム（または、複数の所有者によって共同所有または共同管理されている各コンピューティング・システムおよび資源）にまたがっていてもよい。

たとえば、エッジ・ノード1222、1224のそれぞれは、一つまたは複数のコンテナのグループを提供するコンテナ「ポッド」1226、1228の使用のような、コンテナの使用を実装してもよい。一つまたは複数のコンテナポッドを使用する場面において、ポッドコントローラまたはオーケストレータは、ポッド内のコンテナのローカルな制御およびオーケストレーションを受け持つ。それぞれのエッジ・スライス1232、1234について提供されるさまざまなエッジ・ノード資源（たとえば、六角形で描かれている記憶、計算、サービス）は、各コンテナのニーズに従って分割される。

コンテナポッドの使用に関し、ポッドコントローラが、コンテナおよび資源の分割および割り当てを監督する。ポッドコントローラは、物理資源をどのように、どのくらいの継続時間にわたって分割するのが最良かについて該コントローラに命令するオーケストレータ（たとえばオーケストレータ1260）からの命令を受信する。これはたとえば、SLA契約に基づくキーパフォーマンス指標（KPI）ターゲットを受信することによる。ポッドコントローラは、作業負荷を完了してSLAを満たすために、どのコンテナがどの資源をどのくらいの期間にわたって必要とするかを決定する。ポッドコントローラはまた、コンテナの作成、コンテナに資源およびアプリケーションをプロビジョンすること、ある分散アプリケーションに対して一緒にはたらく複数のコンテナ間の中間結果を調整すること、作業負荷が完了したときにコンテナを解体することなど、コンテナ・ライフサイクル操作を管理する。さらに、ポッドコントローラは、正しいテナントが認証されるまで資源の割り当てを防止する、または認証結果が満足されるまでコンテナへのデータまたは作業負荷のプロビジョニングを防止するセキュリティ役割を果たすことができる。

コンテナポッドの使用に関してはまた、テナント境界は依然として存在しうるが、コンテナの各ポッドのコンテキストにおいてである。それぞれのテナント固有のポッドがテナント固有のポッドコントローラを有する場合、典型的な資源飢餓状況を回避するために資源割り当て要求を統合する共有ポッドコントローラが存在する。ポッドおよびポッドコントローラの認証および信頼性を確実にするために、さらなる制御が提供されてもよい。たとえば、オーケストレータ1260は、認証検証を実行するローカルなポッドコントローラに認証検証ポリシーをプロビジョンすることができる。認証が、第1のテナントのポッドコントローラについてのポリシーを満たすが、第2のテナントのポッドコントローラについてのポリシーを満たさない場合、第2のポッドは、それを満たす異なるエッジ・ノードにマイグレーションされることができる。あるいはまた、第1のポッドが実行されることが許容されてもよく、第2のポッドが実行される前に、異なる共有されるポッドコントローラがインストールされ、呼び出される。

図13は、エッジ・コンピューティング・システム内のコンテナを展開する追加的な計算構成を示す。簡略化された例として、システム構成1310、1320は、ポッドコントローラ（たとえば、コンテナ・マネージャ1311、1321、1331）が、計算ノード（構成1310における1315）を介した実行を通じて、コンテナ化されたポッド、機能、およびサービスとしての機能のインスタンスを起動するように、または計算ノード（構成1320における1323）を介した実行を通じて、コンテナ化された仮想化されたネットワーク機能を別々に実行するように適合された場面を示す。この構成は、例示的なシステム構成1330（計算ノード1336を使用）における複数のテナントの使用のために適応されている。ここで、コンテナ化されたポッド（たとえば、ポッド1312）、機能（たとえば、機能1313、VNF 1322、1336）、およびサービスとしての機能インスタンス（たとえば、FaaSインスタンス1315）が、それぞれのテナントに固有の仮想マシン（たとえば、テナント1332、1333についてのVM 1334、1335）内で起動される（仮想化されたネットワーク機能の実行は別）。この構成はさらに、コンテナベースのオーケストレーション・システム1341によって調整されるように、計算ノード1344上で、コンテナ1342、1343、またはさまざまな機能、アプリケーション、および関数の実行を提供するシステム構成1340での使用のために適応される。

図13に示されたシステム構成は、VM、コンテナ、および機能をアプリケーション組成に関して等しく扱うアーキテクチャーを提供する（結果として得られるアプリケーションは、これらの3つの成分（ingredient）の組み合わせである）。各成分は、ローカルバックエンドとして一つまたは複数のアクセラレータ（FPGA、ASIC）コンポーネントの使用に関わってもよい。このようにして、諸アプリケーションは、オーケストレータによって調整されて、複数のエッジ所有者を横断して分割されることができる。

図13のコンテキストでは、ポッドコントローラ／コンテナ・マネージャ、コンテナ・オーケストレータ、および個々のノードは、セキュリティ実施ポイントを提供することができる。しかしながら、テナント隔離がオーケストレーションされてもよい。ここで、あるテナントに割り当てられる資源は、別のテナントに割り当てられる資源とは異なるが、エッジ所有者は、資源割り当てがテナントの境界を越えて共有されないように協力する。あるいは、テナントは、サブスクリプション、トランザクション／契約ベースで「使用」を許可することができるため、資源割り当てはテナント境界を越えて隔離されることができる。これらのコンテキストでは、仮想化、コンテナ化、エンクレーブ、およびハードウェア分割スキームが、テナント性（tenancy）を強制するためにエッジ所有者によって使用されてもよい。他の隔離環境は：裸金属（専用）設備、仮想マシン、コンテナ、コンテナ上の仮想マシン、またはそれらの組み合わせを含みうる。

さらなる例では、ソフトウェア定義されるまたは制御されるシリコン・ハードウェア、および他の構成可能なハードウェアの諸側面は、エッジ・コンピューティング・システムをアプリケーション、機能、およびサービスと統合することができる。ソフトウェア定義されるシリコンは、何らかの資源またはハードウェア成分が、（たとえば、ハードウェア構成自体の中でのアップグレード、再構成、または新機能の提供によって）自分自身または作業負荷の一部を是正するその成分の能力に基づいて契約またはサービス・レベル合意を満たす能力を確保するために使用されうる。

本明細書で論じられるエッジ・コンピューティング・システムおよび構成は、移動性に関わるさまざまな解決策、サービス、および／または使用事例において適用可能でありうることが理解されるべきである。一例として、図14は、図9のエッジ・クラウド910のようなエッジ・クラウドを実装する例示的なエッジ・コンピューティング・システム1400におけるアプリケーションへのモバイルアクセスに関わる、例示的な単純化された車両計算および通信使用事例を示す。この使用事例では、それぞれのクライアント計算ノード1410は、道路の進行中に例示的なエッジ・ゲートウェイ・ノード1420と通信する、対応する車両内に位置する車両内計算システム（たとえば、車両内ナビゲーションおよび／または情報娯楽システム）として具現されてもよい。たとえば、エッジ・ゲートウェイ・ノード1420は、路側キャビネットの中に、または道路に沿って、道路の交差点に、もしくは道路の近くの他の位置に配置されうる、他の別個の機械的なユーティリティを有する構造中に組み込まれた他のエンクロージャの中に位置してもよい。それぞれの車両が道路に沿って進むにつれて、そのクライアント計算ノード1410とエッジ・ゲートウェイ・ノード1420のうちの特定の一つとの間の接続は、例示的なクライアント計算ノード1410のための一貫した接続およびコンテキストを維持するように伝搬することができる。同様に、モバイル・エッジ・ノードは、高優先度のサービスに、または（たとえばドローンの場合）根底にあるサービス（単数または複数）のためのスループットもしくはレイテンシー解決要件に従って集約することができる。それぞれのエッジ・ゲートウェイ・ノード1420は、ある量の処理および記憶機能を含んでおり、よって、クライアント計算ノード1410のためのデータの何らかの処理および／または記憶は、エッジ・ゲートウェイ・ノード1420のうちの一つまたは複数で実行することができる。

エッジ・ゲートウェイ・ノード1420は、通信基地局1442（たとえば、セルラーネットワークの基地局）に、またはその中に位置する計算サーバー、アプライアンス、またはコンポーネントとして例示的に具現される一つまたは複数のエッジ資源ノード1440と通信することができる。上述のように、それぞれのエッジ資源ノード1440は、ある量の処理および記憶能力を含み、よって、クライアント計算ノード1410のためのデータの何らかの処理および／または記憶は、エッジ資源ノード1440上で実行されうる。たとえば、それほど緊急でないまたは重要でないデータの処理は、エッジ資源ノード1440によって実行されてもよく、緊急性または重要性がより高いデータの処理は、エッジ・ゲートウェイ装置1420によって実行されてもよい（たとえば、各コンポーネントの能力、または緊急性または重要性を示す、要求内の情報に依存して）。処理活動の間に処理の優先度が変化するとき、データアクセス、データ位置またはレイテンシーに基づいて、エッジ資源ノード上で作業が継続されてもよい。同様に、新たな需要を満たすための追加的な資源を提供する（たとえば、計算資源を作業負荷データに適合させる）ために、構成可能なシステムまたはハードウェア資源自体が（たとえば、ローカルなオーケストレータを通じて）アクティブ化されることができる。

エッジ資源ノード1440は、コア・データセンター1450とも通信する。コア・データセンターは、中央位置（たとえば、セルラー通信ネットワークの中央オフィス）に位置する計算サーバー、アプライアンス、および／または他のコンポーネントを含みうる。例示的なコア・データセンター1450は、エッジ資源ノード1440およびエッジ・ゲートウェイ装置1420によって形成されるエッジ・クラウド910動作のためのグローバル・ネットワーク・クラウド1460（たとえば、インターネット）へのゲートウェイを提供することができる。さらに、いくつかの例では、コア・データセンター1450は、ある量の処理および記憶能力を含んでいてもよく、クライアント計算装置のためのデータの何らかの処理および／または記憶は、コア・データセンター1450上で実行されてもよい（たとえば、緊急性または重要性が低い、または複雑性が高い処理）。

エッジ・ゲートウェイ・ノード1420またはエッジ資源ノード1440は、ステートフル・アプリケーション1432および地理的分散データベース1434の使用を提供してもよい。アプリケーション1432およびデータベース1434は、エッジ・クラウドのあるレイヤーにおいて水平方向に分布しているように図示されているが、アプリケーションの資源、サービス、または他の構成要素は、エッジ・クラウドを通じて垂直方向に分布してもよい（クライアント計算ノード1410で実行されるアプリケーションの一部、エッジ・ゲートウェイ・ノード1420またはエッジ資源ノード1440で実行される他の部分などを含む）ことが理解されるであろう。さらに、前述したように、サービスの目的と義務を満たすために、どのレベルでもピア関係が存在しうる。さらに、特定のクライアントまたはアプリケーションのためのデータは、変化する条件に基づいて（たとえば、加速資源の利用可能性に基づいて、車両の移動に追随して、など）、エッジからエッジへ移動することができる。たとえば、アクセスの「減衰レート（rate of decay）」に基づいて、継続するための次の所有者、またはデータもしくは計算アクセスがもはや実行可能でなくなる時を識別するために、予測を行なうことができる。これらのおよびその他のサービスは、トランザクションをコンプライアンスを守りロスのない状態に保つために必要とされる作業を完了するために利用されてもよい。

さらなるシナリオでは、コンテナ1436（またはコンテナのポッド）は、エッジ・ノード1420のうちの1つから他のエッジ・ノード（たとえば、エッジ・ノード1420のうちの別のもの、エッジ資源ノード1440、1450、1460のうちの1つなど）に柔軟にマイグレーションされてもよく、それにより、マイグレーションが機能するために、アプリケーションおよび作業負荷をもつコンテナが再建、再コンパイル、再解釈される必要はない。しかしながら、そのような場面では、いくつかの是正または「スウィズリング」〔かき混ぜ〕（swizzling）変換操作が適用されることがある。たとえば、エッジ資源ノード1440における物理的ハードウェアは、エッジ・ゲートウェイ・ノード1420におけるハードウェアとは異なっていてもよく、よって、コンテナの底部エッジ（bottom edge）を構成するハードウェア抽象化レイヤー（hardware abstraction layer、HAL）は、ターゲット・エッジ・ノードの物理レイヤーに再マッピングされる。これは、コンテナのネイティブ・フォーマットから物理ハードウェア・フォーマットへのHALのバイナリ変換のような、何らかの形の遅延バインディング（late-binding）技法に関わっていてもよく、あるいは、マッピング・インターフェースおよび操作に関わっていてもよい。ポッドコントローラは、異なるハードウェア環境への／からのマイグレーションを含むコンテナ・ライフサイクルの一部として、インターフェース・マッピングを駆動するために使用されうる。

図14に包含されるシナリオは、エッジ・ノードがそれをホストするプラットフォームに沿って他の地理的位置に移動する際に、車両（自動車／トラック／路面電車／列車）内にホストされるエッジ・ノードまたは他のモバイル・ユニットのようなさまざまなタイプのモバイル・エッジ・ノードを利用することができる。車両間通信では、個々の車両が、他の車両のためのネットワーク・エッジ・ノードとして（たとえば、キャッシュ、報告、データ集約などを実行するために）作用することさえある。よって、さまざまなエッジ・ノードにおいて提供されるアプリケーション・コンポーネントは、個々のエンドポイント装置またはエッジ・ゲートウェイ・ノード1420におけるいくつかの機能または動作、エッジ資源ノード1440におけるいくつかの他の機能または動作、およびコア・データセンター1450またはグローバル・ネットワーク・クラウド1460における他の機能または動作の間の協調を含め、静的またはモバイルな場面において分散されてもよいことが理解されるであろう。

さらなる構成では、エッジ・コンピューティング・システムは、それぞれの実行可能なアプリケーションおよび機能の使用を通じてFaaSコンピューティング機能を実装することができる。一例では、開発者は、一つまたは複数のコンピュータ機能を表わす機能コード（たとえば、ここでは「コンピュータコード」）を書き、機能コードは、たとえば、エッジ・ノードまたはデータセンターによって提供されるFaaSプラットフォームにアップロードされる。たとえば、サービス使用事例またはエッジ処理イベントのようなトリガーが、FaaSプラットフォームを用いた機能コードの実行を開始する。

FaaSの一例では、機能コード（たとえば、サードパーティーによって提供されうるアプリケーション）が実行される環境を提供するためにコンテナが使用される。コンテナは、任意の隔離実行エンティティでありえ、プロセス、ドッカー（Docker）またはクバネティス（Kubernetes）のコンテナ、仮想マシンなどであってもよい。エッジ・コンピューティング・システム内では、さまざまなデータセンター、エッジ、エンドポイント（モバイルを含む）装置が、オンデマンドでスケーリングされる機能を「スピンアップ」する（たとえば、機能アクションをアクティブ化する、および／または割り当てる）ために使用される。機能コードは物理インフラストラクチャー（たとえば、エッジ・コンピューティング・ノード）装置と根底にある仮想化されたコンテナ上で実行される。最後に、コンテナは、実行が完了したことに応答して、インフラストラクチャー上で「スピンダウン」される（たとえば、非アクティブ化される、または割り当て解除される）。

FaaSのさらなる諸側面は、サービスとしてエッジ・コンピューティング（Edge-as-a-Service［サービスとしてのエッジ］または「EaaS」）をサポートするそれぞれの機能のサポートを含め、サービス式にエッジ機能の展開を可能にしてもよい。FaaSの追加的な特徴は：顧客（たとえば、コンピュータコード開発者）が支払うのがその顧客のコードが実行されたときのみにできる粒状の（granular）課金コンポーネント；一つまたは複数の機能による再利用のためにデータを記憶するための共通データストレージ；個々の機能の間でのオーケストレーションおよび管理；機能実行管理、並列性、および統合；コンテナおよび機能メモリスペースの管理；機能のために利用可能な加速資源の調整；およびコンテナ（初期化、展開、または構成を必要とする「コールド」に対する、すでに展開されて動作している「ウォーム」コンテナを含む）間での機能の分配を含む。

エッジ・コンピューティング・システム1400は、エッジ・プロビジョニング・ノード1444を含んでいてもよく、または、エッジ・プロビジョニング・ノード1444と通信してもよい。エッジ・プロビジョニング・ノード1444は、図15Bの例示的なコンピュータ読み取り可能な命令1582のようなソフトウェアを、本明細書に記載される方法のいずれかを実装するために、さまざまな受信者に配布することができる。例示的なエッジ・プロビジョニング・ノード1444は、ソフトウェア命令（たとえば、コード、スクリプト、実行可能バイナリ、コンテナ、パッケージ、圧縮ファイル、および／またはそれらの派生物）を記憶するおよび／または他のコンピューティング装置に送信することができる、任意のコンピュータ・サーバー、ホーム・サーバー、コンテンツ配信ネットワーク、仮想サーバー、ソフトウェア配信システム、中央施設、記憶装置、記憶ノード、データ施設、クラウド・サービスなどによって実装されてもよい。例示的なエッジ・プロビジョニング・ノード1444のコンポーネントは、クラウド内、ローカルエリアネットワーク内、エッジネットワーク内、広域ネットワーク内、インターネット上、および／または受信者（単数または複数）と通信上結合された任意の他の位置に配置されてもよい。前記受信者は、エッジ・プロビジョニング・ノード1444を所有および／または運用するエンティティの顧客、クライアント、関係者、ユーザーなどであってもよい。たとえば、エッジ・プロビジョニング・ノード1444を所有および／または運営するエンティティは、図15Bの例示的なコンピュータ読み取り可能な命令1582のようなソフトウェア命令の開発者、販売者、および／またはライセンサー（またはその顧客および／または消費者）であってもよい。前記受信者は、使用および／または再販売および／またはサブライセンスのために前記ソフトウェア命令を購入および／またはライセンスする消費者、サービス・プロバイダー、ユーザー、小売業者、OEMなどであってもよい。

一例では、エッジ・プロビジョニング・ノード1444は、一つまたは複数のサーバーおよび一つまたは複数の記憶装置を含む。記憶装置は、以下に記載されるように、図15Bの例示的なコンピュータ読み取り可能な命令1582のようなコンピュータ読み取り可能な命令をホストする。上述のエッジ・ゲートウェイ装置1420と同様に、エッジ・プロビジョニング・ノード1444の前記一つまたは複数のサーバーは、基地局1442または他のネットワーク通信エンティティと通信する。いくつかの例では、前記一つまたは複数のサーバーは、商業取引の一部として、前記ソフトウェア命令を要求者に送信する要求に応答する。前記ソフトウェア命令の配信、販売、および／またはライセンスに対する支払いは、ソフトウェア配信プラットフォームの前記一つまたは複数のサーバーによって、および／またはサードパーティーの支払いエンティティを介して処理されうる。サーバーは、購入者および／またはライセンサーが、エッジ・プロビジョニング・ノード1444からコンピュータ読み取り可能な命令1582をダウンロードできるようにする。たとえば、図15Bの例示的なコンピュータ読み取り可能な命令1582に対応しうるソフトウェア命令は、本明細書に記載される方法を実施するためにコンピュータ読み取り可能な命令1582を実行する例示的なプロセッサプラットフォーム（単数または複数）にダウンロードされてもよい。

いくつかの例では、コンピュータ読み取り可能な命令1582を実行するプロセッサプラットフォームは、種々の地理的位置、法的管轄区などに物理的に位置することができる。いくつかの例では、エッジ・プロビジョニング・ノード1444の一つまたは複数のサーバーは、改良、パッチ、更新などが配布され、エンドユーザー装置において実装されていソフトウェア命令に適用されることを確実にするために、ソフトウェア命令（たとえば、図15Bの例示的なコンピュータ読み取り可能な命令1582）に対して更新を定期的に提供、送信、および／または強制する。いくつかの例では、コンピュータ読み取り可能な命令1582の異なるコンポーネントは、異なる源からおよび／または異なるプロセッサプラットフォームに配布されることができ、たとえば、コンパイルされたかインタープリットされたかにかかわらず、異なるライブラリ、プラグイン、コンポーネント、および他のタイプの計算モジュールは、異なる源からおよび／または異なるプロセッサプラットフォームに配布されることができる。たとえば、ソフトウェア命令の一部（たとえば、それ自体は実行可能でないスクリプト）が第1の源から配布されてもよく、その間、インタープリタ（前記スクリプトを実行できる）が第2の源から配布されてもよい。

さらに別の例では、本願のエッジ・コンピューティング・システムおよび環境を参照して論じられた計算ノードまたは装置のいずれも、図15Aおよび15Bに示されるコンポーネントに基づいて充足されうる。それぞれのエッジ計算ノードは、装置、アプライアンス、コンピュータ、または他のエッジ、ネットワーキング、もしくはエンドポイント・コンポーネントと通信できる他の「モノ」のタイプとして具現されてもよい。たとえば、エッジ・コンピューティング装置は、パーソナルコンピュータ、サーバー、スマートフォン、モバイル計算装置、スマートアプライアンス、車載型計算システム（たとえば、ナビゲーションシステム）、外装ケース、シェル等を有する自己完結型の装置、または記載される機能を実行することができる他の装置またはシステムとして具現されてもよい。

図15Aは、計算エンジン（本明細書では「計算回路」とも呼ばれる）1502、入出力（I/O）サブシステム1508、データ記憶1510、通信回路サブシステム1512、および任意的に一つまたは複数の周辺装置1514を含む、例示的なエッジ計算ノード1500の例示的実装のブロック図である。他の例では、それぞれの計算装置は、コンピュータにおいて典型的に見られるもの（たとえば、ディスプレイ、周辺装置など）のような、他のまたは追加的なコンポーネントを含んでいてもよい。さらに、いくつかの例では、例示的なコンポーネントの一つまたは複数は、別のコンポーネントに組み込まれてもよく、または他の仕方で別のコンポーネントの一部をなしてもよい。図15の例示的なエッジ計算ノード1500は、図9～図12および／または図14に示されるエッジ・コンピューティング・システムの1つにおいて展開されて、本明細書に開示される例の任意のエッジ計算ノードを実装してもよい。

計算ノード1500は、さまざまな計算機能を実行することができる任意のタイプのエンジン、装置、または装置の集合として具現されてもよい。いくつかの例では、計算ノード1500は、集積回路、埋め込みシステム、フィールドプログラマブルゲートアレイ（FPGA）、システム・オン・チップ（SOC）、または他の集積システムもしくは装置などの単一の装置として具現されてもよい。例示的な例では、計算ノード1500は、プロセッサ1504およびメモリ1506を含むか、またはそれらとして具現される。プロセッサ1504は、本明細書に記載される機能を実行する（たとえば、アプリケーションを実行する）ことができる任意のタイプのプロセッサとして具現されうる。たとえば、プロセッサ1504は、マルチコアプロセッサ、マイクロコントローラ、処理ユニット、特化されたまたは特殊目的の処理ユニット、または他のプロセッサもしくは処理／制御回路として具現されてもよい。

いくつかの例では、プロセッサ1504は、FPGA、特定用途向け集積回路（ASIC）、再構成可能なハードウェアまたはハードウェア回路、または本明細書に記載される機能の実行を容易にするための他の特化されたハードウェアとして具現されてもよく、それらを含んでいてもよく、またはそれらに結合されていてもよい。また、いくつかの例では、プロセッサ1504は、データ処理ユニット（DPU）、インフラストラクチャー処理ユニット（IPU）、またはネットワーク処理ユニット（NPU）としても知られる特化されたx-処理ユニット（xPU）として具現されてもよい。そのようなxPUは、スタンドアローン回路または回路パッケージとして具現されてもよく、SOC内に統合されてもよく、またはネットワーク回路（たとえば、SmartNICにおいて）、加速回路、記憶装置、またはAIハードウェア（たとえば、GPUまたはプログラムされたFPGA）と統合されてもよい。そのようなxPUは、CPUまたは汎用処理ハードウェアの外部で、一つまたは複数のデータストリームを処理し、該データストリームのための特定のタスクおよびアクション（たとえば、マイクロサービスのホスティング、サービス管理またはオーケストレーションの実行、サーバーまたはデータセンター・ハードウェアの組織化または管理、サービス・メッシュの管理、またはテレメトリーの収集および配布）を実行するためのプログラミングを受信するように設計されてもよい。しかしながら、プロセッサ704のxPU、SOC、CPU、および他のバリエーションは、互いに協調して動作して、計算ノード1500内で、それに代わって多くのタイプの演算および命令を実行することができることが理解されるであろう。

メインメモリ1506は、本明細書に記載される機能を実行することができる、任意のタイプの揮発性（たとえば、動的ランダムアクセスメモリ（DRAM）など）または不揮発性のメモリまたはデータ記憶装置として具現されてもよい。揮発性メモリは、媒体によって記憶されたデータの状態を維持するために電力を必要とする記憶媒体であってもよい。揮発性メモリの非限定的な例は、DRAMまたは静的ランダムアクセスメモリ（SRAM）のようなさまざまなタイプのランダムアクセスメモリ（RAM）を含むことができる。メモリモジュールにおいて使用されうるDRAMの1つの特定のタイプは、同期ダイナミックランダムアクセスメモリ（SDRAM）である。

一例では、メモリデバイスは、NANDまたはNOR技術に基づくもののようなブロック・アドレス指定可能なメモリデバイスである。メモリデバイスはまた、三次元クロスポイント・メモリデバイス（たとえば、Intel（登録商標）3D XPoint（商標）メモリ）、または他のバイト・アドレス指定可能なその場書き込み式の（write-in-place）不揮発性メモリデバイスをも含んでいてもよい。メモリデバイスは、ダイ自体および／またはパッケージ化されたメモリ製品を指しうる。いくつかの例では、3Dクロスポイント・メモリ（たとえば、Intel（登録商標）3D XPoint（商標）メモリ）は、メモリセルがワード線とビット線との交点に位置し、個々にアドレス指定可能であり、ビット記憶がバルク抵抗の変化に基づいているトランジスタのないスタッカブルなクロスポイント・アーキテクチャーを含んでいてもよい。いくつかの例では、メインメモリ1506の全部または一部がプロセッサ1504に統合されてもよい。メインメモリ1506は、一つまたは複数のアプリケーション、アプリケーションによって操作されるデータ、ライブラリ、およびドライバなど、動作中に使用されるさまざまなソフトウェアおよびデータを記憶することができる。

計算回路1502は、I/Oサブシステム1508を介して計算ノード1500の他のコンポーネントと通信的に結合され、I/Oサブシステムは、計算回路1502（たとえば、プロセッサ1504および／またはメインメモリ1506）もしくは計算回路1502の他のコンポーネントとの入出力動作を容易にするための回路および／またはコンポーネントとして具現されうる。たとえば、I/Oサブシステム1508は、メモリコントローラハブ、入出力制御ハブ、集積センサーハブ、ファームウェア装置、通信リンク（たとえば、ポイントツーポイントリンク、バスリンク、ワイヤ、ケーブル、光ガイド、プリント回路基板トレースなど）、および／または入出力動作を容易にするための他のコンポーネントおよびサブシステムとして具現されてもよく、または他の仕方でそれらを含んでいてもよい。いくつかの例では、I/Oサブシステム1508は、システム・オン・チップ（SoC）の一部を形成し、プロセッサ1504、メインメモリ1506、および計算回路1502の他のコンポーネントのうちの一つまたは複数とともに、計算回路1502に組み込まれてもよい。

前記一つまたは複数の例示的なデータ記憶装置1510は、たとえば、メモリデバイスおよび回路、メモリカード、ハードディスクドライブ、ソリッドステートドライブ、または他のデータ記憶装置のような、データの短期的または長期的な記憶のために構成された任意のタイプのデバイスとして具現されうる。個々のデータ記憶装置1510は、データ記憶装置1510のためのファームウェアコードおよびデータを記憶するシステム・パーティションを含んでいてもよい。個々のデータ記憶装置1510は、たとえば、計算ノード1500のタイプに依存して、オペレーティング・システム用の実行可能プログラムおよびデータファイルを記憶する一つまたは複数のオペレーティング・システム・パーティションをも含んでいてもよい。

通信回路1512は、計算回路1502と別の計算装置（たとえば、実装エッジ・コンピューティング・システムのエッジ・ゲートウェイ）との間のネットワークを通じた通信を可能にすることができる任意の通信回路、装置、またはそれらの集合として具現されうる。通信回路1512は、そのような通信を実施するために、一つまたは複数の通信技術（たとえば、有線または無線通信）および関連するプロトコル（たとえば、3GPP 4Gまたは5G標準のようなセルラー・ネットワーキング・プロトコル、IEEE802.11/Wi-Fi（登録商標）のような無線ローカルエリアネットワーク・プロトコル、無線広域ネットワーク・プロトコル、イーサネット、Bluetooth（登録商標）、Bluetooth Low Energy、IoTプロトコル、たとえばIEEE802.15.4またはZigBee（登録商標）、低電力広域ネットワーク（LPWAN）または低電力広域（LPWA）プロトコルなど）を使用するように構成されてもよい。

例示的な通信回路1512は、ホストファブリックインターフェース（HFI）とも呼ばれることのあるネットワークインターフェースコントローラ（NIC）1520を含む。NIC 1520は、一つまたは複数のアドインボード、ドーターカード、ネットワークインターフェースカード、コントローラチップ、チップセット、または他の計算装置（たとえば、エッジ・ゲートウェイ・ノード）と接続するために計算ノード1500によって使用されうる他の装置として具現されてもよい。いくつかの例では、NIC 1520は、一つまたは複数のプロセッサを含むシステム・オン・チップ（SoC）の一部として具現されてもよく、またはやはり一つまたは複数のプロセッサを含むマルチチップ・パッケージ上に含まれてもよい。いくつかの例では、NIC 1520は、いずれもNIC 1520に対してローカルであるローカルプロセッサ（図示せず）および／またはローカルメモリ（図示せず）を含んでいてもよい。そのような例では、NIC 1520のローカルプロセッサは、本明細書に記載される計算回路1502の機能の一つまたは複数を実行することが可能でありうる。追加的または代替的に、そのような例では、NIC 1520のローカルメモリは、ボードレベル、ソケットレベル、チップレベル、および／または他のレベルでクライアント計算ノードの一つまたは複数のコンポーネントに統合されてもよい。

さらに、いくつかの例では、それぞれの計算ノード1500は、一つまたは複数の周辺装置1514を含んでいてもよい。そのような周辺装置1514は、計算ノード1500の特定のタイプに依存して、オーディオ入力装置、ディスプレイ、他の入出力装置、インターフェース装置、および／または他の周辺装置のような、計算装置またはサーバーに見出される任意のタイプの周辺装置を含んでいてもよい。さらなる例では、計算ノード1500は、エッジ・コンピューティング・システムまたは同様の形のアプライアンス、コンピュータ、サブシステム、回路、または他のコンポーネントにおけるそれぞれのエッジ計算ノード（クライアント、ゲートウェイ、または集約ノードのいずれでもよい）によって具現されてもよい。

より詳細な例では、図15Bは、図2のエッジ・プラットフォーム200のような、本明細書に記載される技法（たとえば、動作、プロセス、方法、および方法論）を実施するために、図3～図6の命令を実行するように構成された例示的なエッジ・コンピューティング・ノード1550のブロック図を示す。このエッジ・コンピューティング・ノード1550は、コンピューティング装置（たとえば、モバイル装置、基地局、サーバー、ゲートウェイなど）として、またはその一部として実装された場合に、ノード1500のそれぞれのコンポーネントのより詳しい図を提供する。エッジ・コンピューティング・ノード1550は、本明細書で参照されるハードウェアまたは論理コンポーネントの任意の組み合わせを含んでいてもよく、エッジ通信ネットワークまたはそのようなネットワークの組み合わせとともに使用可能な任意の装置を含んでいてもよく、またはそれと結合してもよい。それらのコンポーネントは、エッジ・コンピューティング・ノード1550において適応されたIC、その一部、離散的な電子装置、または他のモジュール、命令セット、プログラマブル論理またはアルゴリズム、ハードウェア、ハードウェアアクセラレータ、ソフトウェア、ファームウェア、またはそれらの組み合わせとして、またはより大きなシステムのシャーシ内に他の仕方で組み込まれたコンポーネントとして、実装されてもよい。たとえば、エッジ・コンピューティング・ノード1550は、たとえば、サーバー、パーソナルコンピュータ、ワークステーション、自己学習マシン（たとえば、ニューラルネットワーク）、モバイル装置（たとえば、携帯電話、スマートフォン、iPad（登録商標）のようなタブレット）、パーソナルデジタルアシスタント（PDA）、インターネットアプライアンス、DVDプレーヤー、CDプレーヤー、デジタルビデオレコーダー、ブルーレイプレーヤー、ゲームコンソール、パーソナルビデオレコーダー、セットトップボックス、ヘッドセットまたは他のウェアラブル装置、モノのインターネット（IoT）装置、または任意の他のタイプのコンピューティング装置でありうる。

エッジ・コンピューティング装置1550は、マイクロプロセッサ、マルチコアプロセッサ、マルチスレッドプロセッサ、超低電圧プロセッサ、埋め込みプロセッサ、xPU/DPU/IPU/NPU、特殊目的処理ユニット、特化した処理ユニット、または他の既知の処理要素でありうるプロセッサ1552の形の処理回路を含んでいてもよい。プロセッサ1552は、プロセッサ1552および他のコンポーネントが単一の集積回路、または単一のパッケージ、たとえば米国カリフォルニア州サンタクララのインテル社のエジソン（商標）またはガリレオ（商標）SoCボードに形成されるシステム・オン・チップ（SoC）の一部であってもよい。一例として、プロセッサ1552は、Quark（商標）、Atom（商標）、i3、i5、i7、i9、またはMCUクラスのプロセッサなどのIntel（登録商標）Architecture Core（商標）ベースのCPUプロセッサ、またはIntel（登録商標）から入手可能な別のそのようなプロセッサを含んでいてもよい。しかしながら、いくつもある他のプロセッサが使用されてもよい。たとえば、米国カリフォルニア州サニーベールのAdvanced Micro Devices, Inc. （AMD（登録商標））から入手可能なもの、米国カリフォルニア州サニーベールのMIPS Technologies, Inc.のMIPS（登録商標）ベースの設計、ARM Holdings, Ltd.からライセンスされるARM（登録商標）ベースの設計またはそれらの顧客、またはそれらのライセンシーもしくは採用者からのものである。プロセッサは、Apple（登録商標）Inc.からのA5-A13プロセッサ、Qualcomm（登録商標）Technologies, Inc.からのSnapdragon（商標）プロセッサ、またはTexas Instruments, Inc.からのOMAP（商標）プロセッサなどのユニットを含みうる。プロセッサ1552および付随する回路は、限定されたハードウェア構成または図15に示されるすべての要素よりも少数を含む構成を含め、単一ソケット形状因子、複数ソケット形状因子、または多様な他のフォーマットで提供されてもよい。この例では、プロセッサ1552は、例示的なオーケストレータ202、例示的な機能コントローラ204、例示的なテレメトリー・コントローラ206、例示的なEPデータベース208、例示的な資源210、および／または、より一般には、例示的なエッジ・プラットフォーム200を実装する。

プロセッサ1552は、相互接続1556（たとえば、バス）を通じてシステムメモリ1554と通信してもよい。所与の量のシステムメモリを提供するために、任意の数のメモリデバイスが使用されうる。例として、メモリは、DDRまたはモバイルDDR標準（たとえば、LPDDR、LPDDR2、LPDDR3またはLPDDR4）のような合同電子装置エンジニアリング評議会（Joint Electron Devices Engineering Council、JEDEC）設計に基づくランダムアクセスメモリであってもよい。具体的な例では、メモリ・コンポーネントは、JEDECによって公布されたDRAM標準、たとえば、DDR SDRAMのためのJESD79F、DDR2 SDRAMのためのJESD79-2F、DDR3 SDRAMのためのJESD79-3F、DDR4 SDRAMのためのJESD79-4A、低電力DDR（LPDDR）のためのJESD209、LPDDR2のためのJESD209-2、LPDDR3のためのJESD209-3、およびLPDDR4のためのJESD209-4に準拠することができる。そのような規格（および類似の規格）は、DDRベースの規格と称されてもよく、そのような規格を実装する記憶装置の通信インターフェースは、DDRベースのインターフェースと称されてもよい。さまざまな実装において、個々のメモリデバイスは、単一ダイパッケージ（SDP）、デュアルダイパッケージ（DDP）、またはクワッドダイパッケージ（Q17P）のような、任意の数の異なるパッケージタイプであってもよい。これらのデバイスは、いくつかの例では、マザーボード上に直接はんだ付けされて、より低いプロファイルの解決策を提供してもよく、一方、他の例では、これらのデバイスは、所与のコネクタによってマザーボードに接続される一つまたは複数のメモリモジュールとして構成される。他のタイプのメモリモジュール、たとえばマイクロDIMMまたはミニDIMMを含むがこれらに限定されない、異なる変種のデュアルインラインメモリモジュール（DIMM）のような、任意の数の他のメモリ実装が使用されうる。

データ、アプリケーション、オペレーティング・システムなどの情報の永続的な記憶を提供するために、記憶1558は、相互接続1556を介してプロセッサ1552にも結合してもよい。一例では、記憶1558は、ソリッドステートディスクドライブ（SSDD）を介して実装されてもよい。記憶1558のために使用されうる他の装置は、SDカード、マイクロSDカード、XDピクチャーカード等のフラッシュメモリカード、およびUSBフラッシュドライブを含む。一例では、メモリデバイスは、カルコゲナイドガラスを使用するメモリデバイス、複数閾値レベルのNANDフラッシュメモリ、NORフラッシュメモリ、単一または複数レベルの相変化メモリ（PCM）、抵抗性メモリ、ナノワイヤメモリ、強誘電体トランジスタ・ランダムアクセスメモリ（FeTRAM）、反強誘電体メモリ、メモリスタ技術を組み込んだ磁気抵抗ランダムアクセスメモリ（MRAM）、金属酸化物ベース、酸素空孔ベースおよび伝導性ブリッジ式のランダムアクセスメモリ（CB-RAM）を含む抵抗性メモリ、またはスピン伝達トルク（STT）-MRAM、スピントロニック磁気接合メモリベースのデバイス、磁気トンネル接合（MTJ）ベースのデバイス、DW（ドメインウォール）およびSOT（スピン軌道移行）ベースのデバイス、サイリスタベースのメモリデバイス、またはこれらのいずれかの組み合わせ、またはその他のメモリであってもよく、またはそれを含んでいてもよい。

低電力実装では、記憶1558は、プロセッサ1552に関連付けられたオンダイ・メモリまたはレジスタであってもよい。しかしながら、いくつかの例では、記憶1558は、マイクロハードディスクドライブ（HAD）を用いて実装されてもよい。さらに、記憶1558のためには、上述の技術に加えて、またはその代わりに、いくつもある新しい技術が使用されてもよい。たとえば、中でも、抵抗変化メモリ、相変化メモリ、ホログラフィックメモリ、または化学メモリなどである。8922。

コンポーネントは、相互接続1556を通じて通信することができる。相互接続1556は、工業標準アーキテクチャー（ISA）、拡張ISA（EISA）、周辺コンポーネント相互接続（PCI）、周辺コンポーネント相互接続拡張（PCIx）、PCIエクスプレス（PCIe）、またはいくつもある他の技術を含む、任意の数の技術を含んでいてもよい。相互接続1556は、たとえば、SoCベースのシステムで使用される独自バスであってもよい。とりわけ、I2Cインターフェース、SPIインターフェース、ポイント・ツー・ポイント・インターフェース、およびパワー・バスのような他のバス・システムが含まれてもよい。

相互接続1556は、接続されたエッジ装置1562との通信のために、プロセッサ1552をトランシーバ1566に結合してもよい。トランシーバ1566は、とりわけBluetooth（登録商標）Special Interest Groupによって定義されるBluetooth（登録商標）低エネルギー（BLE）標準またはZigBee（登録商標）標準を使用して、IEEE802.15.4標準のもとで2.4ギガヘルツ（GHz）伝送など、任意の数の周波数およびプロトコルを使用することができる。特定の無線通信プロトコルのために構成される任意の数の無線機が、接続されたエッジ装置1562への接続のために使用されてもよい。たとえば、無線ローカルエリアネットワーク（WLAN）ユニットが、米国電気電子技術者協会（IEEE）802.11規格に従ってWi-Fi（登録商標）通信を実装するために使用されてもよい。さらに、たとえばセルラーまたは他の無線広域プロトコルに従う無線広域通信が、無線広域ネットワーク（WWAN）ユニットを介して行なわれてもよい。

無線ネットワークトランシーバ1566（または複数のトランシーバ）は、異なる範囲での通信のために、複数の標準または無線機を使用して通信してもよい。たとえば、エッジ・コンピューティング・ノード1550は、電力を節約するために、BLEに基づくローカルトランシーバまたは他の低電力無線機を使用して、たとえば約10メートル以内で、近くの装置と通信することができる。より遠方の、たとえば約50メートル以内にある接続されたエッジ装置1562は、ZigBee（登録商標）または他の中間的な電力無線機を通じて到達されうる。両方の通信技術は、異なる電力レベルで単一の無線機を通じて行なわれてもよく、または、別個のトランシーバ、たとえば、BLEを使用するローカルトランシーバおよびZigBee（登録商標）を使用する別個のメッシュトランシーバを通じて行なわれてもよい。

無線ネットワークトランシーバ1566（たとえば、無線トランシーバ）は、ローカルまたは広域ネットワーク・プロトコルを介してエッジ・クラウド1590内の装置またはサービスと通信するために含まれてもよい。無線ネットワークトランシーバ1566は、とりわけ、IEEE802.15.4またはIEEE802.15.4g標準に従うLPWAトランシーバであってもよい。エッジ・コンピューティング・ノード1550は、SemtechおよびLoRa Allianceによって開発されたLoraWAN（商標）（Long Range Wide Area Network［長距離広域ネットワーク］）を使用して、広い範囲にわたって通信することができる。本明細書に記載される技法は、これらの技術に限定されるものではなく、Sigfoxなどの長距離、低帯域幅通信、およびその他の技術を実装する任意の数の他のクラウドトランシーバとともに使用されてもよい。さらに、IEEE802.15.4e仕様に記載されている時間スロット化されたチャネル・ホッピングのような他の通信技法が使用されてもよい。

本明細書に記載される無線ネットワークトランシーバ1566のために言及されるシステムに加えて、任意の数の他の無線通信およびプロトコルが使用されてもよい。たとえば、トランシーバ1566は、高速通信を実装するためにスペクトラム拡散（SPA/SAS）通信を使用するセルラートランシーバを含んでいてもよい。さらに、中速通信用のWi-Fi（登録商標）ネットワークやネットワーク通信の提供など、任意の数の他のプロトコルが使用されてもよい。トランシーバ1566は、本開示の最後にさらに詳細に説明される、ロングタームエボリューション（LTE）および第5世代（5G）通信システムなど、任意の数の3GPP（第3世代パートナーシッププロジェクト）仕様と互換性のある無線機を含んでいてもよい。エッジ・クラウド1590のノードまたは他の装置、たとえば接続されたエッジ装置1562（たとえばメッシュにおいて動作する）に有線通信を提供するために、ネットワーク・インターフェース・コントローラ（NIC）1568が含まれてもよい。有線通信は、イーサネット接続を提供してもよく、または、他のタイプのネットワーク、たとえばとりわけ、コントローラエリアネットワーク（CAN）、ローカル相互接続ネットワーク（LIN）、DeviceNet、ControlNet、Data Highway+、PROFIBUS、またはPROFINETに基づいてもよい。第2のネットワークへの接続を可能にするために追加的なNIC 1568が含まれてもよく、たとえば、第1のNIC 1568がイーサネットを通じてクラウドへの通信を提供し、第2のNIC 1568が、別のタイプのネットワークを通じて他の装置への通信を提供する。

前記装置から別のコンポーネントまたはネットワークへの適用可能な通信のタイプが多様であるため、前記装置によって使用される適用可能な通信回路は、コンポーネント1564、1566、1568、または1570のうちのいずれか一つまたは複数を含んでいてもよく、またはそれによって具現されてもよい。よって、さまざまな例において、通信（たとえば、受信、送信等）のための適用可能な手段は、そのような通信回路によって具現されてもよい。

エッジ・コンピューティング・ノード1550は、加速回路1564を含んでいてもよく、またはそれに結合されてもよく、加速回路は、一つまたは複数のAIアクセラレータ、ニューラル計算スティック、神経形態ハードウェア、FPGA、諸GPUの配置、xPU/DPU/IPU/NPUの配置、一つまたは複数のSoC、一つまたは複数のCPU、一つまたは複数のデジタル信号プロセッサ、専用ASIC、または一つまたは複数の特化したタスクを達成するように設計された他の形の特化したプロセッサまたは回路によって具現化されてもよい。これらのタスクは、AI処理（機械学習、トレーニング、推論、および分類操作を含む）、ビジュアルデータ処理、ネットワークデータ処理、オブジェクト検出、規則解析などを含みうる。これらのタスクは、本稿の他所で論じたサービス管理およびサービス操作のための特定のエッジ・コンピューティング・タスクをも含んでいてもよい。

相互接続1556は、プロセッサ1552を、追加の装置またはサブシステムを接続するために使用されるセンサーハブまたは外部インターフェース1570に接続してもよい。装置は、加速度計、レベルセンサー、流量センサー、光学光センサー、カメラセンサー、温度センサー、グローバルナビゲーションシステム（たとえば、GPS）センサー、圧力センサー、気圧センサーなどのセンサー1572を含んでいてもよい。ハブまたはインターフェース1570は、さらに、電力スイッチ、弁アクチュエータ、可聴音発生器、視覚警告装置などのようなアクチュエータ1574にエッジ・コンピューティング・ノード1550を接続するために使用されてもよい。

いくつかの任意的な例では、さまざまな入出力（I/O）装置が、エッジ・コンピューティング・ノード1550内に存在してもよく、またはエッジ・コンピューティング・ノード1550に接続されてもよい。たとえば、表示装置または他の出力装置1584が、センサーの読みまたはアクチュエータ・ポジションなどの情報を示すために含まれてもよい。入力を受け付けるために、タッチスクリーンまたはキーパッドのような入力装置1586が含まれてもよい。出力装置1584は、エッジ・コンピューティング・ノード1550の動作から生成または発生される文字、グラフィックス、マルチメディアオブジェクトなどの出力を有する、二状態インジケータ（たとえば、LED）およびマルチキャラクタビジュアル出力などの単純なビジュアル出力、または表示画面（たとえば、LCD画面）などのより複雑な出力を含む、いくつもある形態のオーディオまたはビジュアルディスプレイを含んでいてもよい。本システムのコンテキストでは、ディスプレイまたはコンソールハードウェアが、エッジ・コンピューティング・システムの出力を提供し、入力を受領し；エッジ・コンピューティング・システムのコンポーネントまたはサービスを管理し；エッジ・コンピューティング・コンポーネントまたはサービスの状態を識別し；またはいくつもある他の任意の管理またはアドミン機能またはサービス使用事例を実施するために使用されてもよい。

バッテリー1576は、エッジ・コンピューティング・ノード1550に電力を供給してもよいが、エッジ・コンピューティング・ノード1550が固定位置に取り付けられる例では、電気グリッドに結合された電力供給源を有してもよく、または該バッテリーは、バックアップとして、または一時的な能力のために使用されてもよい。バッテリー1576は、リチウムイオン電池、または亜鉛空気電池、アルミニウム空気電池、リチウム空気電池などの金属空気電池であってもよい。

バッテリー・モニター／充電器1578がエッジ計算ノード1550に含まれてもよい含まれてもよく、含まれる場合、バッテリー1576の充電状態（SoCh）を追跡してもよい。バッテリー・モニター／充電器1578は、バッテリー1576の健康状態（SoH）および機能状態（SoF）など、障害予測を提供するための、バッテリー1576の他のパラメータをモニタリングするために使用されてもよい。バッテリー・モニター／充電器1578は、LTC4020またはLTC2990（Linear Technologies社製）、ADT7488A（アリゾナ州フィーニクスのON Semiconductor社製）、またはUCD90xxxファミリーのIC（テキサス州ダラスのTexas Instruments社製）などのバッテリー・モニタリング集積回路を含んでいてもよい。バッテリー・モニター／充電器1578は、相互接続1556を介して、バッテリー1576に関する情報をプロセッサ1552に通信してもよい。バッテリー・モニター／充電器1578はまた、プロセッサ1552がバッテリー1576の電圧またはバッテリー1576からの電流を直接モニタリングすることを可能にするアナログ‐デジタル変換器（ADC）を含んでいてもよい。バッテリー・パラメータは、送信周波数、メッシュ・ネットワーク動作、センシング周波数などのように、エッジ・コンピューティング・ノード1550が実行しうる動作を決定するために使用されうる。

バッテリー1576を充電するために、電力ブロック1580、またはグリッドに結合された他の電源がバッテリー・モニター／充電器1578に結合されてもよい。いくつかの例では、電力ブロック1580は、たとえばエッジ・コンピューティング・ノード1550内のループアンテナを通じて無線で電力を得るために、無線電力受信機で置き換えられてもよい。カリフォルニア州ミルピタスのLinear TechnologiesからのLTC4020チップなどのような無線バッテリー充電回路が、バッテリー・モニター／充電器1578に含まれてもよい。具体的な充電回路は、バッテリー1576のサイズ、よって必要とされる電流に基づいて選択されてもよい。充電は、Airfuel Allianceによって公布されたAirfuel標準、Wireless Power Consortiumによって公布されたQi無線充電標準、またはAlliance for Wireless Powerによって公布されたRezence充電標準などを使用して実行されてもよい。

記憶1558は、本明細書に記載される技法を実装するためのソフトウェア、ファームウェア、またはハードウェアコマンドの形態の命令1582を含んでいてもよい。そのような命令1582は、メモリ1554および記憶1558に含まれるコードブロックとして示されているが、コードブロックのいずれも、たとえば、特定用途向け集積回路（ASIC）に組み込まれた固定結線の回路で置き換えることができることが理解されよう。

一例では、メモリ1554、記憶1558、またはプロセッサ1552を介して提供される命令1582は、エッジ・コンピューティング・ノード1550内で電子的な動作を実行するプロセッサ1552に指令するコードを含む非一時的な機械読み取り可能媒体1560として具現されてもよい。プロセッサ1552は、相互接続1556を通じて、非一時的な機械読み取り可能媒体1560にアクセスすることができる。たとえば、非一時的な機械読み取り可能媒体1560は、前記記憶1558のために記載された諸装置によって具体化されてもよく、または光ディスク、フラッシュドライブ、またはいくつもある他のハードウェア装置のような特定の記憶ユニットを含んでいてもよい。非一時的な機械読み取り可能媒体1560は、たとえば、上述の動作および機能のフローチャートおよびブロック図に関して述べたように、アクションの特定のシーケンスまたはフローを実行するようにプロセッサ1552に指令する命令を含んでいてもよい。本明細書中で使用されるところでは、「機械読み取り可能媒体」および「コンピュータ読み取り可能媒体」という用語は交換可能である。

さらなる例では、機械読み取り可能媒体はまた、機械による実行のための命令を記憶する、エンコードする、または担持することができ、該機械に本開示の方法のうちのいずれか一つまたは複数を実行させるか、またはそのような命令によって利用されるかそのような命令に関連するデータ構造を記憶する、エンコードする、または担持することができる任意の有体の媒体を含む。よって、「機械読み取り可能媒体」は、固体メモリ、および光学および磁気媒体を含んでいてもよいが、これらに限定されない。機械読み取り可能媒体の具体的な例は、半導体メモリデバイス（たとえば、電気的にプログラマブルな読み出し専用メモリ（EPROM）、電気的に消去可能なプログラマブル読み出し専用メモリ（EEPROM））、フラッシュメモリデバイス；内蔵ハードディスクおよび取り外し可能ディスクのような磁気ディスク；光磁気ディスク；ならびにCD-ROMおよびDVD-ROMディスクを含むが、これらに限定されない不揮発性メモリを含む。機械読み取り可能媒体によって具現される命令は、いくつもある転送プロトコル（たとえば、HTTP）のうちの任意のものを利用するネットワークインターフェース装置を介して、伝送媒体を使用して、通信ネットワークを通じて送信または受信されうる。

機械読み取り可能媒体は、非一時的なフォーマットでデータをホストすることができる記憶装置または他の装置によって提供されてもよい。一例では、機械読み取り可能媒体上に記憶されるまたは他の仕方で提供される情報は、命令を表わしていてもよく、命令それ自体またはそこから命令が導出されうるフォーマットなどである。この、そこから命令が導出されうるフォーマットは、ソースコード、（たとえば、圧縮または暗号化された形の）エンコードされた命令、パッケージ化された命令（たとえば、複数のパッケージに分割される）などを含みうる。機械読み取り可能媒体における命令を表わす情報は、処理回路によって処理されて、本明細書で議論される動作のいずれかを実装するための命令になってもよい。たとえば、情報から命令を導出すること（たとえば、処理回路による処理）は、以下を含みうる：（たとえば、ソースコード、オブジェクト・コードなどから）コンパイルすること、インタープリットすること、ロードすること、編成すること（たとえば、動的または静的にリンクすること）、エンコードすること、デコードすること、暗号化すること、暗号化解除すること、パッケージングすること、パッケージング解除すること、または他の仕方で情報を操作して前記命令にすること。

一例では、命令の導出は、機械読み取り可能媒体によって提供される何らかの中間または前処理されたフォーマットから前記命令を生成するために、（たとえば、処理回路による）情報のアセンブリ、コンパイル、またはインタープリットを含んでいてもよい。前記情報は、複数の部分で提供される場合、前記命令を作成するために組み合わされ、パッケージング解除され、修正されてもよい。たとえば、前記情報は、一つまたは複数のリモート・サーバー上の複数の圧縮されたソースコード・パッケージ（またはオブジェクト・コード、またはバイナリの実行可能コードなど）内にあってもよい。ソースコード・パッケージは、ネットワークを通じて転送中に暗号化され、必要に応じて暗号化解除、圧縮解除、アセンブル（たとえば、リンク）され、ローカルマシンにおいてコンパイルまたはインタープリットされ（たとえば、ライブラリ、スタンドアローンの実行可能プログラムなどにされる）、該ローカルマシンによって実行されてもよい。

機械実行可能命令1582は、大容量記憶装置728内、揮発性メモリ714内、不揮発性メモリ716内、および／またはCDまたはDVDのようなリムーバブルな非一時的なコンピュータ読み取り可能記憶媒体上に記憶されてもよい。

以上から、例示的な方法、装置および製造物が、エッジ環境における作業負荷配置のために開示されていることが理解されるであろう。開示された方法、装置、および製造物は、エッジ・プラットフォームの利用可能な電力および／または熱レベルに基づいて、作業負荷において作業負荷を実行する要求をオーケストレーションすることに費やされる計算資源を調整することによって、コンピューティング装置を使用する効率を改善する。よって、開示された方法、装置、および製造物は、コンピュータの機能における一つまたは複数の改良に向けられる。

さらなる例およびその組み合わせは下記を含む：実施例１は、装置であって：
エッジ環境内のエッジ・プラットフォームから作業負荷を実行する要求を受信するオーケストレータと；
前記エッジ・プラットフォームからの前記作業負荷についての動作パラメータを決定するために前記要求を解析し；
前記動作パラメータに基づいて候補エッジ層およびエッジ・プラットフォーム配置を解析する
機能コントローラとを有しており、前記オーケストレータは、前記動作パラメータを満たす候補エッジ層およびエッジ・プラットフォーム配置に基づいて前記作業負荷のための候補エッジ層およびエッジ・プラットフォーム配置を決定する、
装置を含む。

実施例２は、前記機能コントローラは、前記動作パラメータを決定するときに、前記動作パラメータに必要とされる要因のサブセットを導出する、実施例１に記載の装置を含む。

実施例３は、前記要因のサブセットは、前記エッジ・プラットフォームのサービス・レベル合意（SLA）属性を含む、実施例１または２に記載の装置を含む。

実施例４は、前記要因のサブセットは、セキュリティのレベル、精度のレベル、前記エッジ・プラットフォームの他のマイクロサービスへの依存性、前記エッジ環境内の前記依存性の位置、または前記エッジ・プラットフォームの使用情報のうちの少なくとも1つを含む、実施例１ないし３のうちいずれか一項に記載の装置を含む。

実施例５は、前記機能コントローラは、前記エッジ・プラットフォームのための資源要件を推定し、前記資源要件は、前記要因のサブセットに基づく、前記作業負荷のための、電力測定、熱測定、レイテンシー測定、および帯域幅測定を含む、実施例１ないし４のうちいずれか一項に記載の装置を含む。

実施例６は、前記機能コントローラが、更新された動作パラメータに基づいて前記資源要件を更新する、実施例１ないし５のうちいずれか一項に記載の装置の装置を含む。

前記オーケストレータは、前記候補エッジ層およびエッジ・プラットフォーム配置のそれぞれからテレメトリー・データを受信する、実施例１ないし６のうちいずれか一項に記載の装置を含む。

実施例８は、前記機能コントローラは、前記候補エッジ層およびエッジ・プラットフォーム配置のそれぞれの資源利用可能性を決定し、前記資源利用可能性は、前記テレメトリー・データに基づく、前記候補エッジ層およびエッジ・プラットフォーム配置のそれぞれにおける、電力利用可能性、熱的利用可能性、レイテンシー利用可能性、および帯域幅利用可能性に対応する、実施例１ないし７のうちいずれか一項に記載の装置を含む。

実施例９は、
前記オーケストレータは：
前記候補エッジ層およびエッジ・プラットフォーム配置のそれぞれについての動作パラメータ割合を決定する段階であって、前記動作パラメータ割合は、前記エッジ・プラットフォームの前記資源要件を満たす、あるエッジ層およびエッジ・プラットフォーム配置の前記資源利用可能性の割合に対応する、段階と；
最適な動作パラメータ割合をもつエッジ層およびエッジ・プラットフォーム配置を、前記候補エッジ層およびエッジ・プラットフォーム配置として選択する段階と；
前記候補エッジ層およびエッジ・プラットフォーム配置において前記作業負荷を実施する段階とを実行する、
実施例１ないし８のうちいずれか一項に記載の装置を含む。

実施例１０は、前記オーケストレータは、前記候補エッジ層およびエッジ・プラットフォーム配置のそれぞれについての前記動作パラメータ割合が閾値を満たさないことに応答して、資源要件およびコスト関数重みを調整する、実施例１ないし９のうちいずれか一項に記載の装置を含む。

実施例１１は、装置であって：
エッジ環境内のエッジ・プラットフォームから作業負荷を実行する要求を受信するオーケストレーション手段と；
前記エッジ・プラットフォームからの前記作業負荷についての動作パラメータを決定するために前記要求を解析し；
前記動作パラメータに基づいて候補エッジ層およびエッジ・プラットフォーム配置を解析する
機能制御手段とを有しており、前記オーケストレーション手段は、前記動作パラメータを満たす候補エッジ層およびエッジ・プラットフォーム配置に基づいて前記作業負荷のための候補エッジ層およびエッジ・プラットフォーム配置を決定する、
装置を含む。

実施例１２は、前記機能制御手段は、前記動作パラメータを決定するときに、前記動作パラメータに必要とされる要因のサブセットを導出する、実施例１１に記載の装置を含む。

実施例１３は、前記要因のサブセットは、前記エッジ・プラットフォームのサービス・レベル合意（SLA）属性を含む、実施例１１または１２に記載の装置を含む。

実施例１４は、前記要因のサブセットは、セキュリティのレベル、精度のレベル、前記エッジ・プラットフォームの他のマイクロサービスへの依存性、前記エッジ環境内の前記依存性の位置、または前記エッジ・プラットフォームの使用情報のうちの少なくとも1つを含む、実施例１１ないし１３のうちいずれか一項に記載の装置を含む。

実施例１５は、前記機能制御手段は、前記エッジ・プラットフォームのための資源要件を推定し、前記資源要件は、前記要因のサブセットに基づく、前記作業負荷のための、電力測定、熱測定、レイテンシー測定、および帯域幅測定を含む、実施例１１ないし１４のうちいずれか一項に記載の装置を含む。

実施例１６は、前記機能制御手段が、更新された動作パラメータに基づいて前記資源要件を更新する、実施例１１ないし１５のうちいずれか一項に記載の装置を含む。

実施例１７は、前記オーケストレーション手段は、前記候補エッジ層およびエッジ・プラットフォーム配置のそれぞれからテレメトリー・データを受信する、実施例１１ないし１６のうちいずれか一項に記載の装置を含む。

実施例１８は、前記機能制御手段は、前記候補エッジ層およびエッジ・プラットフォーム配置のそれぞれの資源利用可能性を決定し、前記資源利用可能性は、前記テレメトリー・データに基づく、前記候補エッジ層およびエッジ・プラットフォーム配置のそれぞれにおける、電力利用可能性、熱的利用可能性、レイテンシー利用可能性、および帯域幅利用可能性に対応する、実施例１１ないし１７のうちいずれか一項に記載の装置を含む。

実施例１９は、前記オーケストレーション手段は：
前記候補エッジ層およびエッジ・プラットフォーム配置のそれぞれについての動作パラメータ割合を決定する段階であって、前記動作パラメータ割合は、前記エッジ・プラットフォームの前記資源要件を満たす、あるエッジ層およびエッジ・プラットフォーム配置の前記資源利用可能性の割合に対応する、段階と；
最適な動作パラメータ割合をもつエッジ層およびエッジ・プラットフォーム配置を、前記候補エッジ層およびエッジ・プラットフォーム配置として選択する段階と；
前記候補エッジ層およびエッジ・プラットフォーム配置において前記作業負荷を実施する段階とを実行する、
実施例１１ないし１８のうちいずれか一項に記載の装置を含む。

実施例２０は、前記オーケストレーション手段は、前記候補エッジ層およびエッジ・プラットフォーム配置のそれぞれについての前記動作パラメータ割合が閾値を満たさないことに応答して、資源要件およびコスト関数重みを調整する、実施例１ないし１９のうちいずれか一項に記載の装置を含む。

実施例２１は、データを有する非一時的なコンピュータ読み取り可能な媒体であって、前記データは、実行可能な命令に構成されることができ、構成され実行されると、少なくとも1つのプロセッサに少なくとも以下の段階、すなわち：
エッジ環境内のエッジ・プラットフォームから作業負荷を実行する要求にアクセスする段階と；
前記エッジ・プラットフォームからの前記作業負荷についての動作パラメータを決定するために前記要求を解析する段階と；
前記動作パラメータに基づいて候補エッジ層およびエッジ・プラットフォーム配置を解析する段階と；
前記動作パラメータを満たす候補エッジ層およびエッジ・プラットフォーム配置に基づいて前記作業負荷のための候補エッジ層およびエッジ・プラットフォーム配置を決定する段階とを実行させる、
非一時的なコンピュータ読み取り可能媒体を含む。

実施例２２は、前記命令は、構成され、実行されるとき、前記少なくとも1つのプロセッサに、前記動作パラメータを決定するときに、前記動作パラメータに必要とされる要因のサブセットを導出させる、実施例２１に記載の非一時的なコンピュータ読み取り可能媒体を含む。

実施例２３は、前記要因のサブセットは、前記エッジ・プラットフォームのサービス・レベル合意（SLA）属性を含む、実施例２１または２２に記載の非一時的なコンピュータ読み取り可能媒体を含む。

実施例２４は、前記要因のサブセットは、セキュリティのレベル、精度のレベル、前記エッジ・プラットフォームの他のマイクロサービスへの依存性、前記エッジ環境内の前記依存性の位置、または前記エッジ・プラットフォームの使用情報のうちの少なくとも1つを含む、実施例２１ないし２３のうちいずれか一項に記載の非一時的なコンピュータ読み取り可能媒体を含む。

実施例２５は、前記命令は、構成され、実行されるとき、前記少なくとも1つのプロセッサに、前記エッジ・プラットフォームのための資源要件を推定させ、前記資源要件は、前記要因のサブセットに基づく、前記作業負荷のための、電力測定、熱測定、レイテンシー測定、および帯域幅測定を含む、実施例２１ないし２４のうちいずれか一項に記載の非一時的なコンピュータ読み取り可能媒体を含む。

実施例２６は、前記命令は、構成され、実行されるとき、前記少なくとも1つのプロセッサに、更新された動作パラメータに基づいて前記資源要件を更新させる、実施例２１ないし２５のうちいずれか一項に記載の非一時的なコンピュータ読み取り可能媒体を含む。

実施例２７は、前記命令は、構成され、実行されるとき、前記少なくとも1つのプロセッサに、前記候補エッジ層およびエッジ・プラットフォーム配置のそれぞれからテレメトリー・データを受信させる、実施例２１ないし２６のうちいずれか一項に記載の非一時的なコンピュータ読み取り可能媒体を含む。

実施例２８は、前記命令は、構成され、実行されるとき、前記少なくとも1つのプロセッサに、前記候補エッジ層およびエッジ・プラットフォーム配置のそれぞれの資源利用可能性を決定させ、前記資源利用可能性は、前記テレメトリー・データに基づく、前記候補エッジ層およびエッジ・プラットフォーム配置のそれぞれにおける、電力利用可能性、熱的利用可能性、レイテンシー利用可能性、および帯域幅利用可能性に対応する、実施例１ないし２７のうちいずれか一項に記載の非一時的なコンピュータ読み取り可能媒体を含む。

実施例２９は、前記命令は、構成され、実行されるとき、前記少なくとも1つのプロセッサに：
前記候補エッジ層およびエッジ・プラットフォーム配置のそれぞれについての動作パラメータ割合を決定する段階であって、前記動作パラメータ割合は、前記エッジ・プラットフォームの前記資源要件を満たす、あるエッジ層およびエッジ・プラットフォーム配置の前記資源利用可能性の割合に対応する、段階と；
最適な動作パラメータ割合をもつエッジ層およびエッジ・プラットフォーム配置を、前記候補エッジ層およびエッジ・プラットフォーム配置として選択する段階と；
前記候補エッジ層およびエッジ・プラットフォーム配置において前記作業負荷を実施する段階とを実行させる、
実施例１ないし２８のうちいずれか一項に記載の非一時的なコンピュータ読み取り可能媒体を含む。

実施例３０は、前記命令は、構成され、実行されるとき、前記少なくとも1つのプロセッサに、前記候補エッジ層およびエッジ・プラットフォーム配置のそれぞれについての前記動作パラメータ割合が閾値を満たさないことに応答して、資源要件およびコスト関数重みを調整させる、実施例２１ないし２９のうちいずれか一項に記載の非一時的なコンピュータ読み取り可能媒体を含む。

実施例３１は、方法であって：
エッジ環境内のエッジ・プラットフォームから作業負荷を実行する要求を受領する段階と；
前記エッジ・プラットフォームからの前記作業負荷についての動作パラメータを決定するために前記要求を解析する段階と；
前記動作パラメータに基づいて候補エッジ層およびエッジ・プラットフォーム配置を解析する段階と；
前記動作パラメータを満たす候補エッジ層およびエッジ・プラットフォーム配置に基づいて前記作業負荷のための候補エッジ層およびエッジ・プラットフォーム配置を決定する段階とを含む、
方法を含む。

実施例３２は、前記動作パラメータを決定することが、前記動作パラメータに必要とされる要因のサブセットを導出することを含む、実施例３１に記載の方法を含む。

実施例３３は、前記要因のサブセットは、前記エッジ・プラットフォームのサービス・レベル合意（SLA）属性を含む、実施例３１または３２に記載の方法を含む。

実施例３４は、前記要因のサブセットは、セキュリティのレベル、精度のレベル、前記エッジ・プラットフォームの他のマイクロサービスへの依存性、前記エッジ環境内の前記依存性の位置、または前記エッジ・プラットフォームの使用情報のうちの少なくとも1つを含む、実施例３１ないし３３のうちいずれか一項に記載の方法を含む。

実施例３５は、前記動作パラメータを決定することが、前記エッジ・プラットフォームのための資源要件を推定することを含み、前記資源要件は、前記要因のサブセットに基づく、前記作業負荷のための、電力測定、熱測定、レイテンシー測定、および帯域幅測定を含む、実施例３１ないし３４のうちいずれか一項に記載の方法を含む。

実施例３６は、更新された動作パラメータに基づいて前記資源要件を更新する段階をさらに含む、実施例３１ないし３５のうちいずれか一項に記載の方法を含む。

実施例３７は、前記候補エッジ層およびエッジ・プラットフォーム配置のそれぞれからテレメトリー・データを受信する段階をさらに含む、実施例１ないし３６のうちいずれか一項に記載の方法を含む。

実施例３８は、前記候補エッジ層およびエッジ・プラットフォーム配置の前記解析は、前記候補エッジ層およびエッジ・プラットフォーム配置のそれぞれの資源利用可能性を決定することを含み、前記資源利用可能性は、前記テレメトリー・データに基づく、前記候補エッジ層およびエッジ・プラットフォーム配置のそれぞれにおける、電力利用可能性、熱的利用可能性、レイテンシー利用可能性、および帯域幅利用可能性に対応する、実施例３１ないし３７のうちいずれか一項に記載の方法を含む。

実施例３９は、前記エッジ・プラットフォームについての前記候補エッジ層およびエッジ・プラットフォーム配置の前記決定は：
前記候補エッジ層およびエッジ・プラットフォーム配置のそれぞれについての動作パラメータ割合を決定する段階であって、前記動作パラメータ割合は、前記エッジ・プラットフォームの前記資源要件を満たす、あるエッジ層およびエッジ・プラットフォーム配置の前記資源利用可能性の割合に対応する、段階と；
最適な動作パラメータ割合をもつエッジ層およびエッジ・プラットフォーム配置を、前記候補エッジ層およびエッジ・プラットフォーム配置として選択する段階と；
前記候補エッジ層およびエッジ・プラットフォーム配置において前記作業負荷を実施する段階とを含む、
実施例３１ないし３８のうちいずれか一項に記載の方法を含む。

実施例４０は、前記候補エッジ層およびエッジ・プラットフォーム配置のそれぞれについての前記動作パラメータ割合が閾値を満たさないことに応答して、資源要件およびコスト関数重みを調整することをさらに含む、実施例１ないし３９のうちいずれか一項に記載の方法を含む。

実施例４１は、実施例３１ないし４０のうちいずれかを実行するための命令を含む非一時的なコンピュータ読み取り可能媒体である。

実施例４２は、実施例３１ないし４０のいずれかを実行するための処理回路を備えるエッジ・コンピューティング・ゲートウェイである。

実施例４３は、方法であって：
エッジ環境内のクラウドレットを実行する要求を受領する段階と；
前記クラウドレットについての動作パラメータを決定するために前記要求を解析する段階と；
前記動作パラメータに基づいて候補エッジ層およびエッジ・プラットフォーム配置を解析する段階と；
前記動作パラメータを満たす候補エッジ層およびエッジ・プラットフォーム配置に基づいて前記クラウドレットのための候補エッジ層およびエッジ・プラットフォーム配置を決定する段階とを含む、
方法を含む。

実施例４４は、前記動作パラメータを決定することが、前記動作パラメータに必要とされる要因のサブセットを導出することを含む、実施例４３に記載の方法を含む。

実施例４５は、前記要因のサブセットは、前記クラウドレットのサービス・レベル合意（SLA）属性を含む、実施例４３または４４に記載の方法を含む。

実施例４６は、前記要因のサブセットは、セキュリティのレベル、精度のレベル、前記クラウドレットの他のマイクロサービスへの依存性、前記エッジ環境内の前記依存性の位置、または前記クラウドレットの使用情報のうちの少なくとも1つを含む、実施例４３ないし４５のうちいずれか一項に記載の方法を含む。

実施例４７は、前記動作パラメータを決定することが、前記クラウドレットのための資源要件を推定することを含み、前記資源要件は、前記要因のサブセットに基づく、前記クラウドレットのための、電力測定、熱測定、レイテンシー測定、および帯域幅測定を含む、実施例４３ないし４６のうちいずれか一項に記載の方法を含む。

実施例４８は、更新された動作パラメータに基づいて前記資源要件を更新する段階をさらに含む、実施例４３ないし４７のうちいずれか一項に記載の方法を含む。

実施例４９は、前記候補エッジ層およびエッジ・プラットフォーム配置のそれぞれからテレメトリー・データを受信する段階をさらに含む、実施例４３ないし４８のうちいずれか一項に記載の方法を含む。

実施例５０は、前記候補エッジ層およびエッジ・プラットフォーム配置の前記解析は、前記候補エッジ層およびエッジ・プラットフォーム配置のそれぞれの資源利用可能性を決定することを含み、前記資源利用可能性は、前記テレメトリー・データに基づく、前記候補エッジ層およびエッジ・プラットフォーム配置のそれぞれにおける、電力利用可能性、熱的利用可能性、レイテンシー利用可能性、および帯域幅利用可能性に対応する、実施例４３ないし４９のうちいずれか一項に記載の方法を含む。

実施例５１は、前記クラウドレットについての前記候補エッジ層およびエッジ・プラットフォーム配置の前記決定は：
前記候補エッジ層およびエッジ・プラットフォーム配置のそれぞれについての動作パラメータ割合を決定する段階であって、前記動作パラメータ割合は、前記クラウドレットの前記資源要件を満たす、あるエッジ層およびエッジ・プラットフォーム配置の前記資源利用可能性の割合に対応する、段階と；
最適な動作パラメータ割合をもつエッジ層およびエッジ・プラットフォーム配置を、前記候補エッジ層およびエッジ・プラットフォーム配置として選択する段階と；
前記候補エッジ層およびエッジ・プラットフォーム配置において前記クラウドレットを実施する段階とを含む、
実施例４３ないし５０のうちいずれか一項に記載の方法を含む。

実施例５２は、前記候補エッジ層およびエッジ・プラットフォーム配置のそれぞれについての前記動作パラメータ割合が閾値を満たさないことに応答して、資源要件およびコスト関数重みを調整することをさらに含む、実施例４３ないし５１のうちいずれか一項に記載の方法を含む。

実施例５３は、実施例４３ないし５２のうちいずれかを実行するための命令を含む非一時的なコンピュータ読み取り可能媒体である。

実施例５４は、実施例４３ないし５２のいずれかを実行するための処理回路を備えるエッジ・コンピューティング・ゲートウェイである。

実施例５５は、方法であって：
エッジ環境内のクラウドレットを実行する要求を受領する段階と；
前記クラウドレットについての動作パラメータを決定するために前記要求を解析する段階と；
前記動作パラメータに基づいて候補エッジ層配置を解析する段階と；
前記動作パラメータを満たす候補エッジ層配置に基づいて前記クラウドレットのための候補エッジ層配置を決定する段階とを含む、
方法を含む。

実施例５６は、前記動作パラメータを決定することが、前記動作パラメータに必要とされる要因のサブセットを導出することを含む、実施例５６に記載の方法を含む。

実施例５７は、前記要因のサブセットは、前記クラウドレットのサービス・レベル合意（SLA）属性を含む、実施例５５または５６に記載の方法を含む。

実施例５８は、前記要因のサブセットは、セキュリティのレベル、精度のレベル、前記クラウドレットの他のマイクロサービスへの依存性、前記エッジ環境内の前記依存性の位置、または前記クラウドレットの使用情報のうちの少なくとも1つを含む、実施例５５ないし５７のうちいずれか一項に記載の方法を含む。

実施例５９は、前記動作パラメータを決定することが、前記クラウドレットのための資源要件を推定することを含み、前記資源要件は、前記要因のサブセットに基づく、前記クラウドレットのための、電力測定、熱測定、レイテンシー測定、および帯域幅測定を含む、実施例５５ないし５８のうちいずれか一項に記載の方法を含む。

実施例６０は、更新された動作パラメータに基づいて前記資源要件を更新する段階をさらに含む、実施例５５ないし５９のうちいずれか一項に記載の方法を含む。

実施例６１は、前記候補エッジ層配置のそれぞれからテレメトリー・データを受信する段階をさらに含む、実施例５５ないし６０のうちいずれか一項に記載の方法を含む。

実施例６２は、前記候補エッジ層配置の前記解析は、前記候補エッジ層配置のそれぞれの資源利用可能性を決定することを含み、前記資源利用可能性は、前記テレメトリー・データに基づく、前記候補エッジ層配置のそれぞれにおける、電力利用可能性、熱的利用可能性、レイテンシー利用可能性、および帯域幅利用可能性に対応する、実施例５５ないし６１のうちいずれか一項に記載の方法を含む。

実施例６３は、前記クラウドレットについての前記候補エッジ層配置の前記決定は：
前記候補エッジ層配置のそれぞれについての動作パラメータ割合を決定する段階であって、前記動作パラメータ割合は、前記クラウドレットの前記資源要件を満たす、あるエッジ層配置の前記資源利用可能性の割合に対応する、段階と；
最適な動作パラメータ割合をもつエッジ層配置を、前記候補エッジ層配置として選択する段階と；
前記候補エッジ層配置において前記クラウドレットを実施する段階とを含む、
実施例５５ないし６２のうちいずれか一項に記載の方法を含む。

実施例６４は、前記候補エッジ層配置のそれぞれについての前記動作パラメータ割合が閾値を満たさないことに応答して、資源要件およびコスト関数重みを調整することをさらに含む、実施例５５ないし６３のうちいずれか一項に記載の方法を含む。

実施例６５は、実施例５５ないし６４のうちいずれかを実行するための命令を含む非一時的なコンピュータ読み取り可能媒体である。

実施例６６は、実施例５５ないし６４のいずれかを実行するための処理回路を備えるエッジ・コンピューティング・ゲートウェイである。

ある種の例示的な方法、装置および製造物が本明細書に開示されているが、本特許のカバー範囲はそれに限定されない。逆に、本特許は、本特許のクレームの範囲内にはいるすべての方法、装置および製造物をカバーする。

以下の特許請求の範囲は、この参照により、この詳細な説明に組み込まれ、各特許項は、本開示の別個の実施形態として自立する。

Claims (25)

1. エッジ環境における作業負荷配置のための装置であって：
   エッジ環境内のエッジ・プラットフォームから作業負荷を実行する要求を受信するオーケストレータと；
   前記エッジ・プラットフォームからの前記作業負荷についての動作パラメータを決定するために前記要求を解析し；
   前記動作パラメータに基づいて候補エッジ層およびエッジ・プラットフォーム配置を解析する
   機能コントローラとを有しており、前記オーケストレータは、前記動作パラメータを満たす候補エッジ層およびエッジ・プラットフォーム配置に基づいて前記作業負荷のための候補エッジ層およびエッジ・プラットフォーム配置を決定する、
   装置。
2. 前記機能コントローラは、前記動作パラメータを決定するときに、前記動作パラメータに必要とされる要因のサブセットを導出する、請求項１に記載の装置。
3. 前記要因のサブセットは、前記エッジ・プラットフォームのサービス・レベル合意（SLA）属性を含む、請求項２に記載の装置。
4. 前記要因のサブセットは、セキュリティのレベル、精度のレベル、前記エッジ・プラットフォームの他のマイクロサービスへの依存性、前記エッジ環境内の前記依存性の位置、または前記エッジ・プラットフォームの使用情報のうちの少なくとも1つを含む、請求項２に記載の装置。
5. 前記機能コントローラは、前記エッジ・プラットフォームのための資源要件を推定し、前記資源要件は、前記要因のサブセットに基づく、前記作業負荷のための、電力測定、熱測定、レイテンシー測定、および帯域幅測定を含む、請求項１に記載の装置。
6. 前記機能コントローラが、更新された動作パラメータに基づいて前記資源要件を更新する、請求項５に記載の装置。
7. エッジ環境における作業負荷配置のための装置であって：
   エッジ環境内のエッジ・プラットフォームから作業負荷を実行する要求を受信するオーケストレーション手段と；
   前記エッジ・プラットフォームからの前記作業負荷についての動作パラメータを決定するために前記要求を解析し；
   前記動作パラメータに基づいて候補エッジ層およびエッジ・プラットフォーム配置を解析する
   機能制御手段とを有しており、前記オーケストレーション手段は、前記動作パラメータを満たす候補エッジ層およびエッジ・プラットフォーム配置に基づいて前記作業負荷のための候補エッジ層およびエッジ・プラットフォーム配置を決定する、
   装置。
8. 前記機能制御手段は、前記動作パラメータを決定するときに、前記動作パラメータに必要とされる要因のサブセットを導出する、請求項７に記載の装置。
9. 前記要因のサブセットは、前記エッジ・プラットフォームのサービス・レベル合意（SLA）属性を含む、請求項８に記載の装置。
10. 前記要因のサブセットは、セキュリティのレベル、精度のレベル、前記エッジ・プラットフォームの他のマイクロサービスへの依存性、前記エッジ環境内の前記依存性の位置、または前記エッジ・プラットフォームの使用情報のうちの少なくとも1つを含む、請求項８に記載の装置。
11. 前記機能制御手段は、前記エッジ・プラットフォームのための資源要件を推定し、前記資源要件は、前記要因のサブセットに基づく、前記作業負荷のための、電力測定、熱測定、レイテンシー測定、および帯域幅測定を含む、請求項７に記載の装置。
12. 前記機能制御手段が、更新された動作パラメータに基づいて前記資源要件を更新する、請求項１１に記載の装置。
13. 実行可能な命令に構成されることができるデータを有する非一時的なコンピュータ読み取り可能な媒体であって、前記データは、構成され実行されると、少なくとも1つのプロセッサに少なくとも以下の段階、すなわち：
    エッジ環境内のエッジ・プラットフォームから作業負荷を実行する要求にアクセスする段階と；
    前記エッジ・プラットフォームからの前記作業負荷についての動作パラメータを決定するために前記要求を解析する段階と；
    前記動作パラメータに基づいて候補エッジ層およびエッジ・プラットフォーム配置を解析する段階と；
    前記動作パラメータを満たす候補エッジ層およびエッジ・プラットフォーム配置に基づいて前記作業負荷のための候補エッジ層およびエッジ・プラットフォーム配置を決定する段階とを実行させる、
    非一時的なコンピュータ読み取り可能媒体。
14. 前記命令は、構成され、実行されるとき、前記少なくとも1つのプロセッサに、前記動作パラメータを決定するときに、前記動作パラメータに必要とされる要因のサブセットを導出させる、請求項１３に記載の非一時的なコンピュータ読み取り可能媒体。
15. 前記要因のサブセットは、前記エッジ・プラットフォームのサービス・レベル合意（SLA）属性を含む、請求項１４に記載の非一時的なコンピュータ読み取り可能媒体。
16. 前記要因のサブセットは、セキュリティのレベル、精度のレベル、前記エッジ・プラットフォームの他のマイクロサービスへの依存性、前記エッジ環境内の前記依存性の位置、または前記エッジ・プラットフォームの使用情報のうちの少なくとも1つを含む、請求項１４に記載の非一時的なコンピュータ読み取り可能媒体。
17. 前記命令は、構成され、実行されるとき、前記少なくとも1つのプロセッサに、前記エッジ・プラットフォームのための資源要件を推定させ、前記資源要件は、前記要因のサブセットに基づく、前記作業負荷のための、電力測定、熱測定、レイテンシー測定、および帯域幅測定を含む、請求項１３に記載の非一時的なコンピュータ読み取り可能媒体。
18. 前記命令は、構成され、実行されるとき、前記少なくとも1つのプロセッサに、更新された動作パラメータに基づいて前記資源要件を更新させる、請求項１７に記載の非一時的なコンピュータ読み取り可能媒体。
19. エッジ環境における作業負荷配置のための方法であって：
    エッジ環境内のエッジ・プラットフォームから作業負荷を実行する要求を受領する段階と；
    前記エッジ・プラットフォームからの前記作業負荷についての動作パラメータを決定するために前記要求を解析する段階と；
    前記動作パラメータに基づいて候補エッジ層およびエッジ・プラットフォーム配置を解析する段階と；
    前記動作パラメータを満たす候補エッジ層およびエッジ・プラットフォーム配置に基づいて前記作業負荷のための候補エッジ層およびエッジ・プラットフォーム配置を決定する段階とを含む、
    方法。
20. 前記動作パラメータを決定することが、前記動作パラメータに必要とされる要因のサブセットを導出することを含む、請求項１９に記載の方法。
21. 前記要因のサブセットは、前記エッジ・プラットフォームのサービス・レベル合意（SLA）属性を含む、請求項２０に記載の方法。
22. 前記要因のサブセットは、セキュリティのレベル、精度のレベル、前記エッジ・プラットフォームの他のマイクロサービスへの依存性、前記エッジ環境内の前記依存性の位置、または前記エッジ・プラットフォームの使用情報のうちの少なくとも1つを含む、請求項２０に記載の方法。
23. 前記動作パラメータを決定することが、前記エッジ・プラットフォームのための資源要件を推定することを含み、前記資源要件は、前記要因のサブセットに基づく、前記作業負荷のための、電力測定、熱測定、レイテンシー測定、および帯域幅測定を含む、請求項１９に記載の方法。
24. 更新された動作パラメータに基づいて前記資源要件を更新する段階をさらに含む、請求項２３に記載の方法。
25. 請求項１９ないし２４のうちいずれか一項に記載の方法を実行するための命令を含む非一時的なコンピュータ読み取り可能媒体。

Images