特許 7612419 エッジ・コンピューティング配備におけるマルチ・エンティティ・リソース、セキュリティ、及びサービス管理

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

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

(11)【特許番号】

(24)【登録日】2024-12-27

(45)【発行日】2025-01-14

(54)【発明の名称】エッジ・コンピューティング配備におけるマルチ・エンティティ・リソース、セキュリティ、及びサービス管理

(51)【国際特許分類】

   H04L 41/0895 20220101AFI20250106BHJP

   H04L 41/50 20220101ALI20250106BHJP

   H04L 47/125 20220101ALI20250106BHJP

   H04W 12/03 20210101ALI20250106BHJP

   H04W 12/0431 20210101ALI20250106BHJP

   H04L 9/08 20060101ALI20250106BHJP

【ＦＩ】

H04L41/0895

H04L41/50

H04L47/125

H04W12/03

H04W12/0431

H04L9/08 C

【請求項の数】 11

(21)【出願番号】P 2020571852

(86)(22)【出願日】2020-04-29

(65)【公表番号】

(43)【公表日】2022-06-30

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

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

(87)【国際公開日】2020-11-12

【審査請求日】2023-04-25

(31)【優先権主張番号】62/841,042

(32)【優先日】2019-04-30

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

(31)【優先権主張番号】62/907,597

(32)【優先日】2019-09-28

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

(31)【優先権主張番号】62/939,303

(32)【優先日】2019-11-22

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

(73)【特許権者】

【識別番号】593096712

【氏名又は名称】インテル コーポレイション

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100135079

【弁理士】

【氏名又は名称】宮崎 修

(72)【発明者】

【氏名】ギム ベルナー，フランセスク

(72)【発明者】

【氏名】アスティジェロス，イグナチオ

(72)【発明者】

【氏名】バリー，スザンヌ エム．

(72)【発明者】

【氏名】バルトファイ－ウォルコット，カタリン

(72)【発明者】

【氏名】ブラウン，ジョン ジェイ．

(72)【発明者】

【氏名】チェン，リー

(72)【発明者】

【氏名】クーパー，トレヴァー

(72)【発明者】

【氏名】クストディオ，エヴァン

(72)【発明者】

【氏名】ドシ，クシティ アルン

(72)【発明者】

【氏名】フィリッポウ，ミルティアディス

(72)【発明者】

【氏名】ガネシュ，ブリンダ

(72)【発明者】

【氏名】ハードリッチ，アンドリュー ジェイ．

(72)【発明者】

【氏名】アイヤー，ラヴィシャンカール アール．

(72)【発明者】

【氏名】ジャイン，ニレシュ

(72)【発明者】

【氏名】クマール，カルティク

(72)【発明者】

【氏名】カッチ，パトリック ジー．

(72)【発明者】

【氏名】マチオッコ，クリスティアン

(72)【発明者】

【氏名】パーカー，ヴァレリー ジェイ．

(72)【発明者】

【氏名】パストール ベネイト，フェリペ

(72)【発明者】

【氏名】プールナチャンドラン，ラジェシュ

(72)【発明者】

【氏名】パワー，ダミアン

(72)【発明者】

【氏名】プラバカラン，スラージ

(72)【発明者】

【氏名】スクーラー，イヴ エム．

(72)【発明者】

【氏名】スミス，ネッド エム．

(72)【発明者】

【氏名】スード，カピル

(72)【発明者】

【氏名】タハン，マリヤム

(72)【発明者】

【氏名】ヴェラール，ティモシー

(72)【発明者】

【氏名】ヴィスワナタン，タルン

(72)【発明者】

【氏名】フォン ボケルン，ヴィンセント

(72)【発明者】

【氏名】ウォルシュ，オーエン

(72)【発明者】

【氏名】ウィルハルム，トーマス

(72)【発明者】

【氏名】セトゥラマン，ラマナタン

(72)【発明者】

【氏名】パテル，ラシュミン

(72)【発明者】

【氏名】ヴェルプランケ，エドウィン

(72)【発明者】

【氏名】シャー，ラフール アール．

【審査官】安井 雅史

(56)【参考文献】

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

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

【文献】特開２００６－０７９１６１（ＪＰ，Ａ）

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

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

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

【文献】Ha, K. et al.，Adaptive VM Handoff Across Cloudlets，[オンライン]，2015年06月30日，[検索日 2024.04.18], インターネット:<URL：https://elijah.cs.cmu.edu/DOCS/CMU-CS-15-113.pdf>

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

Ｈ０４Ｌ ９／００－ ９／４０

Ｈ０４Ｌ １２／００－１２／６６

Ｈ０４Ｌ ４１／００－６９／４０

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

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

【請求項1】

エッジコンピューティングシステムであって、当該エッジコンピューティングシステムは、
複数のエッジコンピューティングノードとの通信を送受信するように構成された通信回路と、
処理回路と、を含み、
該処理回路は、
ソースクラウドレット内のローカルデータストアにおいて、作業負荷に関するデータを暗号化して、暗号化データを作成し、
前記暗号化データの鍵を前記ソースクラウドレットから宛先クラウドレットに転送し、
作業負荷移行の指示を受け取り、及び
該作業負荷移行の指示に応答して、前記暗号化データをネットワーク転送のために再暗号化せずに、前記暗号化データを非セキュアチャネルを通じて前記宛先クラウドレットに送信するように構成される、
エッジコンピューティングシステム。

【請求項2】

前記暗号化データは、暗号化データとして前記ローカルデータストアからワーキングメモリに転送される、請求項１に記載のエッジコンピューティングシステム。

【請求項3】

前記ソースクラウドレットは、前記データが前記ワーキングメモリからプロセッサに転送されるときに、全メモリ暗号化回路を使用して前記暗号化データを復号化する、請求項２に記載のエッジコンピューティングシステム。

【請求項4】

前記暗号化データの部分は、前記作業負荷移行の一部として転送されず、前記部分は、前記作業負荷によるデータ使用をプロファイリングすることによって決定される、請求項１に記載のエッジコンピューティングシステム。

【請求項5】

前記エッジコンピューティングノードは、分散型エッジコンピューティングシステムのレイヤにおけるネットワークピアである、請求項１に記載のエッジコンピューティングシステム。

【請求項6】

エッジコンピューティング環境における複数のエッジコンピューティングノードの間で実行されるクラウドレット移行のための方法であって、当該方法は、
ソースクラウドレット内のローカルデータストアにおいて、作業負荷に関するデータを暗号化して、暗号化データを作成するステップと、
前記暗号化データの鍵を前記ソースクラウドレットから宛先クラウドレットに転送するステップと、
作業負荷移行の指示を受け取るステップと、
前記作業負荷移行の指示に応答して、前記暗号化データをネットワーク転送のために再暗号化せずに、前記暗号化データを非セキュアチャネルを介して前記宛先クラウドレットに送信するステップと、を含む、
方法。

【請求項7】

前記暗号化データは、暗号化データとして前記ローカルデータストアからワーキングメモリに転送される、請求項６に記載の方法。

【請求項8】

前記ソースクラウドレットは、前記データが前記ワーキングメモリからプロセッサに転送されるときに、全メモリ暗号化回路を使用して前記暗号化データを復号化する、請求項７に記載の方法。

【請求項9】

前記暗号化データの部分は、前記作業負荷移行の一部として転送されず、前記部分は、前記作業負荷によるデータ使用をプロファイリングすることによって決定される、請求項６に記載の方法。

【請求項10】

前記エッジコンピューティングノードは、分散型エッジコンピューティングシステムのレイヤにおけるネットワークピアである、請求項６に記載の方法。

【請求項11】

命令を格納した少なくとも１つの非一時的な機械可読記憶媒体であって、前記命令がエッジコンピューティングシステムのプロセッサ回路によって実行されると、該プロセッサ回路に請求項６乃至１０のいずれか一項に記載の方法の動作を実行させる、非一時的な機械可読記憶媒体。

【発明の詳細な説明】

【背景技術】

【0001】

優先権
本願は２０１９年４月３０日付で出願された米国仮特許出願第６２／８４１，０４２号；２０１９年９月２８日付で出願された米国仮特許出願第６２／９０７，５９７号；及び２０１９年１１月２２日付で出願された米国仮特許出願第６２／９３９，３０３号に対する優先権を主張しており、これら全ては参照により全体的に本願に組み込まれる。

【0002】

背景
エッジ・コンピューティングは、一般的な水準における、ネットワークの「エッジ」又は「エッジ」の集まりに近い場所での処理及びリソースの実装、連携、及び利用を指す。この配置の目的は、（特に、従来のクラウド・コンピューティングと比較して）オーナーシップのトータル・コストを改善すること、アプリケーション及びネットワークの待ち時間を削減すること、ネットワークのバックホール・トラフィック及び関連するエネルギ消費を削減すること、サービス能力を向上させること、セキュリティ又はデータ・プライバシー要件の遵守を改善することである。エッジ・コンピューティング・オペレーションを実行することが可能なコンポーネント（「エッジ・ノード」）は、システム・アーキテクチャ又はアドホック・サービスにより必要とされる如何なる場所にも存在することが可能である（例えば、ハイ・パフォーマンス演算データ・センター又はクラウド設備；指定されたエッジ・ノード・サーバー、企業サーバー、路側サーバー、テレコム中央オフィス；又は消費エッジ・サービスを提供するローカル又はピアのアト・ジ・エッジ・デバイス（ａ ｌｏｃａｌ ｏｒ ｐｅｅｒ ａｔ－ｔｈｅ－ｅｄｇｅ ｄｅｖｉｃｅ）に存在する）。

【0003】

エッジ・コンピューティングに適用されるアプリケーションは、従来のネットワーク機能の仮想化（例えば、通信又はインターネット・サービスを処理するためのもの）、次世代の機能及びサービスの導入（例えば、第５世代ネットワーク・サービスをサポートするもの）を含むが、これらに限定されない。エッジ・コンピューティングを広く活用すると予想されるユース・ケースは、コネクテッド自動運転車両、監視、モノのインターネット（ＩｏＴ）デバイスのデータ分析、ビデオ符号化及び分析、位置認識サービス、スマート・シティにおけるデバイス・センシング、その他多くのネットワーク及び演算集約型サービスを含む。

【0004】

エッジ・コンピューティングは、一部のシナリオでは、クラウドのような分散サービスを提供又はホスティングし、多くの種類のストレージ及び計算リソースの中で、アプリケーション及び連携サービス・インスタンスのオーケストレーション及び管理を提供することができる。また、エッジ・コンピューティングは、エンドポイント・デバイス、クライアント、及びゲートウェイがネットワークのエッジにより近い場所でネットワーク・リソース及びアプリケーションにアクセスを試みる場合に、ＩｏＴ及びフォグ（Ｆｏｇ）／分散ネットワーク構成のために開発された既存のユース・ケース及び技術と緊密に統合されることも期待される。

【図面の簡単な説明】

【0005】

図面において、それらは必ずしも縮尺通りに描かれていないが、類似の数字は、異なる図面において類似の構成要素を述べている可能性がある。異なる文字添え字を有する類似の番号は、類似の要素の互いに異なるインスタンスを表わす可能性がある。幾つかの実施形態は、添付図面の図に例として示されているが、これは限定ではない。

【0006】

【図1】エッジ・コンピューティングのためのエッジ・クラウド構成の概要を示す。

【0007】

【図2】エンドポイント、エッジ・クラウド、及びクラウド・コンピューティング環境の間のオペレーショナル・レイヤを示す。

【0008】

【図3】エッジ・コンピューティング・システムの間に配備された分散処理レイヤの概要を示す。

【0009】

【図4】エッジ・コンピューティング・システムの間に配備された分散処理レイヤの概要を示す。

【0010】

【図5】エッジ・コンピューティング・システムにおけるネットワーキング及びサービスのためのオーバー・ザ・トップ及びネットワーク集約アプローチを示す。

【図6】エッジ・コンピューティング・システムにおけるネットワーキング及びサービスのためのオーバー・ザ・トップ及びネットワーク集約アプローチを示す。

【0011】

【図7】複数のエッジ・ノード及び複数のテナントの間で動作するエッジ・コンピューティング・システムを横断する仮想エッジ構成の配備及びオーケストレーションを示す。

【図8】複数のエッジ・ノード及び複数のテナントの間で動作するエッジ・コンピューティング・システムを横断する仮想エッジ構成の配備及びオーケストレーションを示す。

【0012】

【図9】エッジ・コンピューティング・システムにおいてコンテナを配備する様々な処理構成を示す。

【0013】

【図10A】エッジ・コンピューティング・システムにおける連携した処理機能及びサービスを用いる分散エッジ・コンピューティングの展開を示す。

【図10B】エッジ・コンピューティング・システムにおける連携した処理機能及びサービスを用いる分散エッジ・コンピューティングの展開を示す。

【0014】

【図11】エッジ・コンピューティング・システムを提供するエッジ・メッシュ間で連携したエッジ・コンピューティングのための構成を示す。

【0015】

【図12】エッジ・コンピューティング・システムにおけるアプリケーションへのモバイル・アクセスを含む車両コンピューティング及び通信のユース・ケースを示す。

【0016】

【図13】オペレーショナル・ネットワーク・レイヤ間のエッジ・コンピューティングのための動作考察の比較を示す。

【0017】

【図14】オペレーショナル・ネットワーク・レイヤ間のエッジ・コンピューティングのための配置及び待ち時間を示す。

【0018】

【図15】エッジ・コンピューティング・システムのオペレーショナル・レイヤに対する作業負荷の展開及びマッピングを示す。

【0019】

【図16】エッジ・コンピューティング・システムのサービス機能に対する作業負荷タイプのマッピングを示す。

【0020】

【図17】エッジ・コンピューティング・システムにおける実行プラットフォームに対する作業負荷タイプのマッピングを示す。

【0021】

【図18】エッジ・コンピューティング・システムにおけるエッジ・コンピューティング・ハードウェア構成の複数のレイヤの間の複数のテナントのためのサービス動作を示す。

【0022】

【図19】ネットワーク・レイヤにおける動作展開及び待ち時間に対するエッジ・コンピューティング・ハードウェア構成の更なるマッピングを示す。

【0023】

【図20】エッジ・コンピューティング・ハードウェア構成の動作展開に対するユース・ケース及び作業負荷の更なるマッピングを示す。

【0024】

【図21A】動作目的に基づくエッジ・コンピューティング・ハードウェア構成の更なる例を示す。

【図21B】動作目的に基づくエッジ・コンピューティング・ハードウェア構成の更なる例を示す。

【図21C】動作目的に基づくエッジ・コンピューティング・ハードウェア構成の更なる例を示す。

【0025】

【図22A】エッジ・コンピューティング・システム内のコンピューティング・ノードで展開される処理のための例示的なコンポーネントの概要を提供する。

【0026】

【図22B】エッジ・コンピューティング・システムにおけるコンピューティング・デバイス内の例示的な構成要素の更なる概要を提供する。

【0027】

【図22C】エッジ・コンピューティング・システム内のモバイル・コンピューティング・デバイス内の例示的な構成要素の更なる概要を提供する。

【0028】

【図22D】エッジ・コンピューティング・システム内の設定可能なサーバー・ラック（ｒａｃｋ）内の例示的な構成要素の更なる概要を提供する。

【0029】

【図23】エッジ・ハートビート・コンポーネントによる通知に基づく、エッジ・ノードの低接続性クラスタ及び接続調整を示す。

【0030】

【図24】エッジ・ハートビート・コンポーネントによる通知に基づく、エッジ・ノードの高接続性クラスタ及び接続調整を示す。

【0031】

【図25】エッジ・ホスト内のエッジ・ハートビート・コンポーネントを使用した例示的なエッジ展開を示す。

【0032】

【図26】エッジ・ノード間のデータ・フローの例を示す。

【0033】

【図27】エッジ・コンピューティング・ネットワーク内のデータの証明（ａｔｔｅｓｔａｔｉｏｎ）のための技術を示す。

【0034】

【図28】エッジ・サービス分布のためのアーキテクチャを示すシステム図を示す。

【0035】

【図29】エッジ・コンピューティング・システムに対する並列的なデータの加速のためのシナリオを示す。

【0036】

【図30】改善されたエッジ・クラウド推論処理のための構成要素を含むアーキテクチャの例を示す。

【0037】

【図31】エッジ・サービス・ページ・テーブルを実装するためのシステム図を示す。

【0038】

【図32】エッジ・サービス・ページ・テーブルを示す。

【0039】

【図33】異なるエッジ・クラウド・ロケーションにおけるオーケストレータのドメイン分離を示すシステム図を示す。

【0040】

【図34】エッジ・クラウドの領域を管理するエッジ・クラウド・オーケストレータを示すシステム図を示す。

【0041】

【図35】リソースの例示的なブロードキャスト及び借用を示す３つの異なるオーケストレータ間のフローチャートを示す。

【0042】

【図36】エッジ・デバイスにおいてデータを集約するためのアーキテクチャのシステム図を示す。

【0043】

【図37】エッジ・ゲートウェイ・アーキテクチャの例を示す。

【0044】

【図38】予め準備されたハンドオフのために機械学習システムを訓練して使用する例を示す。

【0045】

【図39】エッジ・コンピューティング・ノード間の自動サービス複製の例を示す。

【0046】

【図40】カスタマ・プレミス装置（ＣＰＥ）ベースの実行フォワーディングのためのブロードバンド・ベース及びワイヤレス・ベースのシステム例のブロック図を示す。

【0047】

【図41】ＣＰＥベースの実行フォワーディングのための例示的なシステムのブロック図を示す。

【0048】

【図42】ＣＰＥベースの実行フォワーディングのための計算能力を割り当てる予測可能な手段を達成するためのポリシー主導アプローチのための技法例のフローを示す。

【0049】

【図43】エッジ・エコシステム・ドメイン・アーキテクチャの例を示す。

【0050】

【図44】仮想化されたマルチ・ドメインのモデル例を示す。

【0051】

【図45】エッジ・コンピューティング・ノード間の安全なデータ共有のシナリオを示す。

【0052】

【図46】エッジにおけるグループ・セキュア通信のためのシステム例のブロック図である。

【0053】

【図47】サービスとしての競合分析（ＣＡａＳ）プロバイダを含むエッジ・システムの概要を示すシステム図を示す。

【0054】

【図48】ＣＡａａＳプロバイダのコンポーネントを示すシステム図を示す。

【0055】

【図49】デバイス識別子合成エンジン（ＤＩＣＥ）レイヤリング及び複合デバイス識別子（ＣＤＩ）処理を利用するアーキテクチャの例を示す。

【0056】

【図50】非対称鍵生成を使用するＤＩＣＥレイヤリングによるアーキテクチャの例を示す。

【0057】

【図51】作業負荷に固有の証明鍵を生成するためにＤＩＣＥレイヤリングを使用するＳＬＡパラメータの暗黙的な証明のためのフロー例を示す。

【0058】

【図52】エッジ証明ネーム・サービス（ＥＡＮＳ）アーキテクチャを提供するシステムを示す。

【0059】

【図53】カリー関数（例えば、ビットストリーム）及び作業負荷を受け入れるアクセラレータを示すエッジ・アーキテクチャのシステム図を示す。

【0060】

【図54】動的ＳＬＡ及び課金基準に基づくマルチ・テナント・エッジ・クラウド・パワー管理のためのシステムを示す。

【0061】

【図55】バイオメトリック階層アーキテクチャの例を示す。

【0062】

【図56】エッジ・コンピューティング・システムの複数のエッジ・ノード間におけるＳＬＡのマイグレーション、モニタリング、及びプロパゲーションのシナリオを示す。

【0063】

【図57】サービス・レベル目標に対するエッジ機能ベースの変更のためのシステム図を示す。

【0064】

【図58】クラウド、エッジ、及びモバイル・デバイス・ロケーションの間のエッジ・コンピューティング・システムの３レベル階層を示す。

【0065】

【図59】エッジ・サービス・マイグレーションの例を示す。

【0066】

【図60】部分エッジ・サービス・マイグレーションの例を示す。

【0067】

【図61】エッジ作業負荷における水平プロキシ化の例を示す。

【0068】

【図62】作業負荷コンポーネント・タイプに基づいてエッジ作業負荷を複数のフォワード・エッジ作業負荷に移動させる例を示す。

【0069】

【図63】連携した分散されたエッジ・テレメトリ・サービスのためのシステム図を示す。

【0070】

【図64】エッジ・コンピューティング・システム内で負荷分散を実現するように構成された分散システム間の構成の実装を示す。

【0071】

【図65】異なるエッジ・コンピューティング・ノード間の接続例を示す。

【0072】

【図66】電気通信サービス・プロバイダ（ＴＳＰ）及びクラウド・サービス・プロバイダ（ＣＳＰ）の間のエッジ通信相互作用の例を示す。

【0073】

【図67】例示的なエッジ・コンピューティング・システムにおいて展開することが可能な５Ｇ－ＭＥＣ（マルチ・アクセス・エッジ・コンピューティング）相互接続を示す。

【0074】

【図68】例示的なエッジ・コンピューティング・システムにおいて展開することが可能な全体的な５Ｇ次世代（ＮＧ）システム・アーキテクチャの単純化された図である。

【0075】

【図69】例示的なエッジ・コンピューティング・システムにおいて展開することが可能な非ローミング５Ｇシステム・アーキテクチャを示す。

【0076】

【図70】例示的なエッジ・コンピューティング・システムにおいて展開することが可能な５Ｇサービス・ベースのアーキテクチャ及び一般的なＭＥＣアーキテクチャを示す。

【0077】

【図71】例示的なエッジ・コンピューティング・システムで使用することが可能な５Ｇネットワークにおける統合ＭＥＣの配備を示す。

【0078】

【図72】例示的なモバイル・エッジ・システム参照アーキテクチャを示す。

【0079】

【図73】異なるエッジ・コンピューティング・システム・レベルにおけるＭＥＣ展開オプションの例を示す。

【0080】

【図74】例示的なエッジ・コンピューティング・システムで使用することが可能な５ＧシステムにおけるＭＥＣサポートを示す。

【0081】

【図75】例示的なエッジ・コンピューティング・システムで使用することが可能な５ＧシステムにおけるＭＥＣマッピングを示す。

【図76】例示的なエッジ・コンピューティング・システムで使用することが可能な５ＧシステムにおけるＭＥＣマッピングを示す。

【図77】例示的なエッジ・コンピューティング・システムで使用することが可能な５ＧシステムにおけるＭＥＣマッピングを示す。

【0082】

【図78】例示的な５ＧシステムにおけるＭＥＣの配備を示す。

【0083】

【図79】ネットワーク・スライシングに関連する制御ユニット制御プレーン（ＣＵ－ＣＰ）－制御ユニット・ユーザ・プレーン（ＣＵ－ＵＰ）の分離による例示的な５Ｇ－ＮＲアーキテクチャの構成要素を示す。

【0084】

【図80】エッジ・コンピューティングの配備で使用することが可能なネットワーク・スライスの例を用いた図を示す。

【0085】

【図81】例示的なエッジ・コンピューティング・システムから展開することが可能なスライス管理、リソース管理、及びトレーサビリティ機能をサポートするＭＥＣネットワーク・アーキテクチャを示す。

【0086】

【図82】例示的なエッジ・コンピューティング・システムから展開することが可能なネットワーク機能仮想化（ＮＦＶ）環境におけるＭＥＣ参照アーキテクチャを示す。

【0087】

【図83】例示的なエッジ・コンピューティング・システムから展開することが可能な仮想化ネットワーク機能としてのＭＥＣプラットフォームの管理を示す。

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

【0088】

以下の実施形態は、一般に、データ処理、サービス管理、リソース割り当て、計算管理、ネットワーク通信、アプリケーション分割、及び通信システムの実装に関連し、特に、分散エッジ・コンピューティング環境において複数のエンティティ（例えば、複数のテナント、ユーザ、ステークホルダー（利害関係者）、サービス・インスタンス、アプリケーションなど）を動的にサポートするために、様々なエッジ・コンピューティング・デバイス及びエンティティを適合させるための技術及び構成に関連する。

【0089】

以下の説明において、エッジ・コンピューティング・アーキテクチャ及び実装エッジ・コンピューティング・システムの構成及び機能的能力に対する種々の改良のための方法、構成、及び関連装置が開示される。これらの改良は、様々なユース・ケース、特にエッジ・コンピューティング・システムの複数の利害関係者が関与するもの、に恩恵を与える可能性があり、システムの複数のユーザ、システムにおける複数のテナント、システムと相互作用する複数のデバイス又はユーザ機器、システムから提供される複数のサービス、システム内で利用可能な又は管理される複数のリソース、システムのために公開される複数の形式のネットワーク・アクセス、システムのための動作の複数の場所などの形態によらない。そのような多次元の態様及び考察は、本願では一般に「マルチ・エンティティ」制約と言及され、マルチ・テナント及びマルチ・サービス・エッジ・コンピューティング構成において管理又は調整されるリソースについての具体的な議論がある。

【0090】

以下に説明する例示的なエッジ・ネットワーク・システムでは、コンピューティング及びストレージ・リソースが、ネットワークのエッジに、より近い位置（例えば、クライアント、エンドポイント・デバイス、又は「モノ」に、より近い位置）に移動させられる。コンピューティング及びストレージ・リソースを、データを生成又は使用するデバイスに近づけることによって、標準的なネットワーク（例えば、クラウド・コンピューティング）システムと比較して、様々な待ち時間、コンプライアンス、及び／又は金銭的又はリソースのコスト制約を達成することができる。そうするために、幾つかの例において、コンピューティング、メモリ、及び／又はストレージ・リソースのプールが、ローカル・サーバー、ルータ、及び／又はその他のネットワーク機器に配置されてもよいし、或いはそうでなければ装備されてもよい。このようなローカル・リソースは、システムに課された制約を満たすことを促進する。例えば、ローカルなコンピューティング及びストレージ・リソースは、エッジ・システムが、リアル・タイム又はほぼリアル・タイムで演算を実行することを可能にし、これは、自動運転、ビデオ監視、及びモバイル・メディア消費のような低遅延ユース・ケースにおいて考慮される可能性がある。更に、これらのリソースは、エッジ・システムでのサービス管理から恩恵を受けることが可能であり、エッジ・システムは、ローカルＳＬＡをスケーリングして達成し、階層化されたサービス要件を管理し、一時的又は永続的にローカルな特徴及び機能を可能にする能力を提供する。

【0091】

例示的なエッジ・コンピューティング・システムは、エンドポイント・デバイス（例えば、クライアント・ユーザ機器（ＵＥ））に対して様々なサービスをサポート及び／又は提供することができ、エンドポイント・デバイスのそれぞれは異なる要件又は制約を有する可能性がある。例えば、幾つかのサービスは、電力、冷却、及び形状要因の制約と同様に、優先度又はサービス品質（ＱｏＳ）制約（例えば、自律車両のための交通データは、温度センサー・データよりも高い優先度を有する可能性がある）、信頼性及びレジリエンス（例えば、交通データは、ミッション・クリティカルな信頼性を必要とする可能性があるが、温度データは、幾らかの誤差分散を許容される可能性がある）を有し得る。これら及び他の技術的制約は、マルチ・ステークホルダーの状況で適用される場合に、かなりの複雑性及び技術的課題をもたらす可能性がある。

【0092】

先ず、エッジ・コンピューティング（セクションＩ）に適用することが可能な用語の概略を以下に示す。これに続いて、エッジ・コンピューティング技術及び構成、並びにマルチ・ステークホルダー・サービスのユース・ケース例（セクションＩＩ）を概観する。ユース・ケース（セクションＩＩＩ．Ａ）によりマルチ・ステークホルダー・サービス（セクションＩＩＩ）に対して提供される技術的改善の種類が続き、これは、関連する技術分野の議論に加えて、（ａ）リソースの配分及び解放（セクションＩＩＩ．Ｂ）、（ｂ）セキュリティ及びプライバシー（セクションＩＩＩ．Ｃ）、及び（ｃ）オーケストレーション及びサービス・レベル（セクションＩＩＩ．Ｂ）に対する改善を含む。これに続いて、エッジ・コンピューティング・システムの潜在的な接続構成（セクションＩＶ）、並びに本願で説明される改良を具体化する例示的な構成及び方法についての結論が議論される。

【0093】

Ｉ．用語
本願で使用されるように、「エッジ・コンピューティング」という用語は、クラウド処理アクティビティとして又はクラウド処理リソースによって典型的に実行されるものを含む処理アクティビティ及びリソース（例えば、計算、ストレージ、加速リソース）を、ネットワークの「エッジ」に移動させ、エンドポイント・ユーザ（クライアント・デバイス、ユーザ機器など）の待ち時間を短縮し、スループットを増加させる分散コンピューティングの多くの実装を包含する。このようなエッジ・コンピューティング実装は、一般的に、無線ネットワークを介してアクセス可能な１つ以上の場所から、クラウド類似サービス、機能、アプリケーション、及びサブシステムにおけるこのようなアクティビティ及びリソースを提供することを包含する。従って、本願で使用されるネットワーク、クラスタ、ドメイン、システム、又はコンピュータ構成の「エッジ」に対する言及は、機能的に分散されたコンピューティング要素のグループ又はグループ化であり、従って、グラフ理論で使用されるような「エッジ」（リンク又はコネクション）とは、概して関連していない。

【0094】

（例えば、セルラー及びＷｉ－Ｆｉデータ・ネットワークのような）モバイル無線ネットワークを介してアクセス可能なエッジ・コンピューティング・アプリケーション及びサービスの特定の構成は、「モバイル・エッジ・コンピューティング」又は「マルチ・アクセス・エッジ・コンピューティング」と呼ばれ、これは頭文字「ＭＥＣ」によって参照される可能性がある。本願における「ＭＥＣ」の用法は、欧州電気通信標準化機構（ＥＴＳＩ）によって公布された標準化実装（ＥＴＳＩ ＭＥＣ）を指す場合がある。ＥＴＳＩ ＭＥＣ仕様によって使用される用語は、矛盾する定義又は用法が本願で与えられていない限り、一般的に本願に援用される。

【0095】

本願で使用されているように、用語「コンピューティング・ノード」又は「コンピューティング・デバイス」は、より大きなシステムの一部分、分散されたシステムの集まり、又はスタンドアロン装置であるか否かを問わず、エッジ・コンピューティング動作の態様を実装する識別可能なエンティティを指す。幾つかの例では、コンピューティング・ノードは、クライアント、サーバー、又は中間エンティティとして動作しているか否かを問わず、「エッジ・ノード」、「エッジ・デバイス」、「エッジ・システム」と言及される可能性がある。コンピューティング・ノードの特定の実装は、サーバー、基地局、ゲートウェイ、路側機、オンプレミス、ＵＥ、又は末端消費者デバイスなどに組み込まれることが可能である。更に、コンピューティング・ノード又はコンピューティング・デバイスは、ノード又はデバイスに利用可能なリソース（例えば、電力、処理、スペース、温度、及びその他の動作上の考慮事項又は制約）に基づいて、異なるタイプ又はクラスのハードウェア、又はそのようなハードウェアの構成を含むことが可能である。従って、ハードウェアの多くのバリエーションは、コンピューティング・ノード又はコンピューティング・デバイスに包含されるように意図されている。

【0096】

本願で使用されるように、「基地局」という用語は、ユーザ機器（ＵＥ）への又はＵＥからの１つ以上のセル内での無線信号の送受信を行う第４世代（４Ｇ）又は第５世代（５Ｇ）の移動通信ネットワークのような、無線アクセス・ネットワーク（ＲＡＮ）内のネットワーク要素を指す。基地局は、統合されたアンテナを有することが可能であり、又はフィーダ・ケーブルによってアンテナ・アレイに接続されてもよい。基地局は、特殊なデジタル信号処理及びネットワーク機能ハードウェアを使用する。幾つかの例において、基地局は、柔軟性、金銭的又はリソース的なコスト、及びパフォーマンスのために、ソフトウェアで動作する複数の機能ブロックに分割されることが可能である。幾つかの例では、基地局は、エボルブド・ノードＢ（ｅＮＢ）又は次世代ノードＢ（ｇＮＢ）を含むことが可能である。幾つかの例において、基地局は、コンピューティング・ノードとして動作するために、コンピュータ・ハードウェアを動作させるか、又はそれを含むことができる。しかしながら、本願で議論する多くのシナリオにおいて、ＲＡＮ基地局は、アクセス・ポイント（例えば、無線ネットワーク・アクセス・ポイント）又はその他のネットワーク・アクセス・ハードウェアで置き換えることが可能である。

【0097】

本願で使用されるように、用語「セントラル・オフィス」（又はＣＯ）は、アクセス可能な又は定められた地理的なエリア内の電気通信インフラストラクチャの集約ポイントを示し、電気通信サービス・プロバイダは、しばしば、１つ以上のタイプのアクセス・ネットワークのために交換機器を伝統的に配置してきた。ＣＯは、電気通信インフラ設備、コンピュータ、データ・ストレージ、及びネットワーク・リソースを収容するように物理的に設計されことが可能である。しかしながら、ＣＯは、電気通信サービス・プロバイダにより指定された場所である必要はない。ＣＯは、エッジ・アプリケーション及びサービスのために、あるいはクラウド類似サービスのローカルな実装のためでさえ、任意の数のコンピューティング・デバイスをホストすることができる。

【0098】

本願で使用されるように、「クラウド・サービス・プロバイダ」（又はＣＳＰ）という用語は、セントラル化された、地域的な、及びエッジ・データ・センター（例えば、パブリック・クラウドの状況で使用されるようなもの）で構成される、典型的には大規模な「クラウド」リソースを運用する組織を示す。他の例では、ＣＳＰはまたクラウド・サービス・オペレータ（ＣＳＯ）とも呼ばれる。一般的に、「クラウド・コンピューティング」という言及は、エッジ・コンピューティングに関連する、少なくとも幾らかの増加した待ち時間、距離、又は制約を伴う遠隔地において、ＣＳＰ又はＣＳＯによって提供されるコンピューティング・リソース及びサービスを指す。

【0099】

本願で使用されるように、用語「データ・センター」は、大量の処理、データ・ストレージ及びネットワーク・リソースが単一の場所に存在するように、複数のハイ・パフォーマンス・コンピューティング及びデータ・ストレージ・ノードを収容するように意図された目的設計構造を指す。これは、しばしば、専用のラック及びエンクロージャ・システム、適切な加熱、冷却、換気、セキュリティ、火災抑制、及び電力配分システムを必要とする。また、用語は、幾つかの文脈において、コンピューティング及びデータ・ストレージ・ノードを指す可能性がある。データ・センターは、セントラル化された又はクラウドのデータ・センター（最大）、地域のデータ・センター、エッジ・データ・センター（最小）の間でスケールを変えることが可能である。

【0100】

本願で使用されるように、エッジ・ネットワークの「レイヤ」に対する言及は、「クローズ・エッジ」、「ローカル・エッジ」、「ミドル・エッジ」、「ファー・エッジ」のような用語、又は具体的に名付けられたレイヤの使用にかかわらず、待ち時間、タイミング、又は距離に関連する共通の特性を有する様々な形態又はタイプのエッジ・ネットワーク及びエッジ・ネットワーク構成を包含することが可能である。従って、レイヤに対する言及は、一般に、ＯＳＩモデルにおけるレイヤを必ずしも参照しておらず、むしろ、特性の共通する階層（ｔｉｅｒ）又はセットを有する何らかのネットワーク部分又はセグメントを指すであろう。

【0101】

本願で使用される「アクセス・エッジ・レイヤ」は、エンド・ユーザ又はデバイスに最も近いインフラストラクチャ・エッジのサブレイヤを指す。例えば、そのようなレイヤは、セルラー・ネットワーク・サイトに配備されたエッジ・データ・センターによって実現される可能性がある。アクセス・エッジ・レイヤは、インフラストラクチャ・エッジの最前線として機能し、階層の上位に位置する集約エッジ・レイヤに接続する可能性がある。また本願で使用されるように、「集約エッジ・レイヤ」は、アクセス・エッジ・レイヤから１ホップ離れたインフラストラクチャ・エッジのレイヤを指す。このレイヤは、単一の場所に中規模のデータ・センターとして存在するか、又は複数の相互接続されたマイクロ・データセンターから形成されて、アクセス・エッジを有する階層的トポロジを形成し、アクセス・エッジのみよりも大規模なコラボレーション、作業負荷フェイルオーバー、及びスケーラビリティを可能にすることができる。

【0102】

本願で使用されるように、「ネットワーク機能仮想化」（又はＮＦＶ）という用語は、業界標準の仮想化及びクラウド・コンピューティング技術を用いる、専用機器内の組み込みサービスから、標準ＣＰＵ（例えば、標準ｘ８６（登録商標）及びＡＲＭ（登録商標）サーバー、例えば、Ｉｎｔｅｌ（登録商標）Ｘｅｏｎ（登録商標）、ＡＭＤ（登録商標）Ｅｐｙｃ（登録商標）、Ｏｐｔｅｒｏｎ（登録商標）プロセッサなど）の上で動作するソフトウェア・ベースの仮想化ネットワーク機能（又はＶＮＦ）への、ネットワーク機能の移行を示す。幾つかの態様では、ＮＦＶ処理及びデータ・ストレージは、インフラストラクチャ・エッジ内のローカル・セルラー・サイトに直接接続されるエッジ・データ・センターで行われるであろう。

【0103】

本願で使用されるように、「仮想化ネットワーク機能」（又はＶＮＦ）という用語は、専用の物理装置の代わりにＮＦＶによって使用される、多機能、多目的の演算リソース（例えば、ｘ８６、ＡＲＭ処理アーキテクチャ）上で動作するソフトウェア・ベースのネットワーク機能を示す。幾つかの態様において、幾つかのＶＮＦは、インフラストラクチャ・エッジのエッジ・データ・センターで動作する。

【0104】

本願で使用されるように、用語「エッジ・コンピューティング・ノード」は、サーバー、クライアント、エンドポイント、又はピアモードで動作するかどうか、ネットワークの「エッジ」に位置するか、又はネットワーク内で更に接続された場所に位置するかどうかを問わず、デバイス、ゲートウェイ、ブリッジ、システム又はサブシステム、コンポーネントの形態における演算可能な要素の実世界の、論理的な、又は仮想化された実装を指す。本願で使用される「ノード」に対する言及は、一般に「デバイス」、「コンポーネント」及び「サブシステム」と可換であるが、「エッジ・コンピューティング・システム」に対する言及は、一般に、複数のノード及びデバイスの分散されたアーキテクチャ、構成、又は集合を指し、エッジ・コンピューティング設定においてサービス又はリソースの何らかの態様を達成又は提供するように組織される。

【0105】

本願で使用されるように、用語「クラスタ」は、物理的な存在（例えば、様々なコンピューティング・システム、ネットワーク、又はネットワーク・グループ）、論理的な存在（例えば、アプリケーション、機能、セキュリティ構成、コンテナ）などの形態で、エッジ・コンピューティング・システム（又はシステム）の一部としての存在のセット又はグループを指す。幾つかのロケーションにおいて、「クラスタ」はまた「グループ」又は「ドメイン」とも呼ばれる。クラスタのメンバシップは条件又は機能に基づいて変更され又は影響を受ける可能性があり、動的な又はプロパティ・ベースのメンバシップから、ネットワーク又はシステム管理シナリオから、又はクラスタ内のエンティティを追加、変更、又は削除する後述する様々な例示的な技術からのものを含む。クラスタはまた、そのようなレイヤ、レベル、又はプロパティに基づくセキュリティ機能及び結果のバリエーションを含む、複数のレイヤ、レベル、又はプロパティを含む、又はそれらに関連付けることができる。

【0106】

以下の多くの例は、４Ｇ／５Ｇの３ＧＰＰネットワーク・コンポーネント（又は予想されるテラヘルツベースの６Ｇ／６Ｇ＋技術）の使用を含む、特定のセルラー／モバイル・ネットワーク用語を使用して提供されるが、これらの例は、ワイド・エリア及びローカル・ワイヤレス・ネットワークの他の多くの配備、及び有線ネットワーク（光ネットワーク及び関連するファイバ、トランシーバなどを含む）の統合に適用されてもよいことが理解されるであろう。技術的に可能な場合、種々のネットワーク接続は、本願に開示されたネットワークのいずれかにおいて有線又は無線であってもよく、その結果のシステムは、有線／無線ネットワーク技術双方のハイブリッド配備であってもよい。更に、開示された機能を達成するために、本願で開示される説明される無線ネットワーク接続規格の何れもが、システム又はサブシステムのアーキテクチャ要件によって使用されることが可能である。

【0107】

ＩＩ．エッジ・コンピューティング・システムの具体例
図１は、エッジ・コンピューティングの構成の概要を示すブロック図１００であり、以下の多くの例において「エッジ・クラウド」として参照される処理のレイヤを含む。図示のように、エッジ・クラウド１１０は、アクセス・ポイント又は基地局１４０、ローカル処理ハブ１５０、又はセントラル・オフィス１２０のようなエッジ・ロケーションに共配置され、従って、複数のエンティティ、デバイス、及び機器インスタンスを含む可能性がある。エッジ・クラウド１１０は、エンドポイント（消費者及び生産者）データ・ソース１６０（例えば、自律車両１６１、ユーザ機器１６２、ビジネス及び産業機器１６３、ビデオ・キャプチャ・デバイス１６４、ドローン１６５、スマート・シティ及びビルディング・デバイス１６６、センサー及びＩｏＴデバイス１６７など）に、クラウド・データ・センター１３０よりもかなり近くに配置される。エッジ・クラウド１１０のエッジで提供される処理、メモリ、及びストレージ・リソースは、エンドポイント・データソース１６０によって使用されるサービス及び機能のために非常に短い待ち時間・応答時間を提供し、エッジ・クラウド１１０からクラウド・データ・センター１３０へのネットワーク・バックホール・トラフィックを低減するために重要であり、従って利点の中でも特にエネルギ消費及び全体的なネットワーク利用性を改善する。

【0108】

処理、メモリ、及びストレージは、希少なリソースであり、一般にエッジの位置に依存して減少する（例えば、セントラル・オフィスにおいてよりも、基地局においてよりも、消費者エンドポイント・デバイスにおいては、僅かな処理ソースしか利用可能でない）。しかしながら、エッジ位置がエンドポイント（例えば、ＵＥ）に近いほど、スペース及び電力はしばしば制約されることが多い。従って、エッジ・コンピューティングは、ネットワーク・アクセス時間の中で且つ地理的により近くに位置するより多くのリソースの配分により、ネットワーク・サービスに必要とされるリソース量を減らそうと試みる。このように、エッジ・コンピューティングは、必要に応じて、作業負荷データにコンピューティング・リソースをもたらすか、又は作業負荷データをコンピューティング・リソースにもたらすことを試みる。

【0109】

以下、複数の可能性のある配備をカバーし、一部のネットワーク・オペレータ又はサービス・プロバイダが独自のインフラストラクチャにおいて有する可能性のある制約に対処する、エッジ・クラウド・アーキテクチャの態様を説明する。これらは、エッジ位置に基づく構成のバリエーション（例えば、基地局レベルのエッジは、マルチ・テナント・シナリオにおいて、より制約されたパフォーマンス及び能力を有する可能性があることを理由とする）；エッジ位置、位置の階層、又は位置のグループに利用可能な処理、メモリ、ストレージ、ファブリック、アクセラレーション、又は同様のリソースのタイプに基づく構成；サービス、セキュリティ、管理、及びオーケストレーション機能；並びに、エンド・サービスの有用性及びパフォーマンスを達成するための関連する対象を含む。これらの配備は、待ち時間、距離、及びタイミング特性に応じて、「ニア・エッジ」、「クローズ・エッジ」、「ローカル・エッジ」、「ミドル・エッジ」、又は「ファー・エッジ」レイヤと考えることが可能なネットワーク・レイヤにおける処理を達成することができる。

【0110】

エッジ・コンピューティングは、典型的には、基地局、ゲートウェイ、ネットワーク・ルータ、又は、データを生成し消費するエンドポイント・デバイス（例えば、「ローカル・エッジ」、「クローズ・エッジ」、又は「ニア・エッジ」）にかなり近い他のデバイスに実装されるコンピューティング・プラットフォーム（例えば、ｘ８６又はＡＲＭコンピューティング・ハードウェア・アーキテクチャ）の使用を通じて、ネットワークの「エッジ」又はそれに近い場所で演算が実行される開発パラダイムである。例えば、エッジ・ゲートウェイ・サーバーは、接続されたクライアント・デバイスのための短い待ち時間のユース・ケース（例えば、自動運転又はビデオ監視）に対してリアル・タイムで計算を実行するために、メモリ及びストレージ・リソースのプールを備えることが可能である。或いは、一例として、基地局は、バックホール・ネットワークを介してデータを更に通信することなく、接続されたユーザ機器のためのサービス作業負荷を直接的に処理するために、演算及び加速リソースで補強されてもよい。或いは、別の例として、セントラル・オフィス・ネットワーク管理ハードウェアは、仮想化されたネットワーク機能を実行し、接続されたデバイスのためのサービス及び消費者機能の実行のための計算リソースを提供する、標準化された計算ハードウェアに置き換えることができる。エッジ・コンピューティング・ネットワーク内では、計算リソースがデータに「移動」させられるサービス内のシナリオ、及びデータが計算リソースに「移動」させられるシナリオが存在する可能性がある。或いは、一例として、基地局の演算、加速、及びネットワーク・リソースは、コーナー・ケース、緊急事態を管理するために、又は、かなり長い実装ライフサイクルにわたって配備されたリソースの長寿命化を提供するために、休眠キャパシティをアクティブにすることにより（加入、要求に応じたキャパシティ、加入）、必要に応じて作業負荷の需要に対してスケーリングするためにサービスを提供することができる。

【0111】

図２は、エンドポイント、エッジ・クラウド、及びクラウド・コンピューティング環境の間のオペレーショナル・レイヤを示す。具体的には、図２は、ネットワーク・コンピューティングの複数の例示的なレイヤの中でエッジ・クラウド１１０を利用する演算ユース・ケース２０５の例を示す。これらのレイヤは、エッジ・クラウド１１０にアクセスしてデータ作成、分析、及びデータ消費アクティビティを実行するエンドポイント（デバイス及びモノの）レイヤ２００において始まる。エッジ・クラウド１１０は、複数のネットワーク・レイヤ、例えば物理的に近接したエッジ・システムに配置されたゲートウェイ、オンプレミス・サーバー、又はネットワーク機器（ノード２１５）を有するエッジ・デバイス・レイヤ２１０；基地局、無線処理ユニット、ネットワーク・ハブ、リージョナル・データ・センター、又はローカル・ネットワーク機器（機器２２５）を包含するネットワーク・アクセス・レイヤ２２０；及び（詳細には図示されていないレイヤ２１２における）それらの間に配置された任意の機器、デバイス、又はノードに渡って広がることができる。エッジ・クラウド１１０内及び種々のレイヤの間のネットワーク通信は、図６５－８３を参照して説明される接続アーキテクチャ及び技術によるものを含む、任意数の有線又は無線の媒体を介して行うことができる。

【0112】

ネットワーク通信距離及び処理時間の制約の結果生じる待ち時間の例は、エンドポイント・レイヤ２００の中の中にある場合に、ミリ秒（ｍｓ）未満から、エッジ・デバイス・レイヤ２１０における５ｍｓ未満（例えば、「ニア・エッジ」又は「クローズ・エッジ」レイヤ）、ネットワーク・アクセス・レイヤ２２０のノード（例えば、「ミドル・エッジ」レイヤ）と通信する場合には１０－４０ｍｓの範囲にさえ及んでもよい。エッジ・クラウド１１０の外側には、コア・ネットワーク２３０及びクラウド・データ・センター２４０のレイヤがあり、それら各々は増加した待ち時間を有する（例えば、コア・ネットワーク・レイヤ２３０では５０－６０ｍｓ、クラウド・データ・センター・レイヤでは１００ｍｓ以上であり、いずれも「ファー・エッジ」レイヤと考えられてよい）。結果として、コア・ネットワーク・データセンター２３５又はクラウド・データ・センター２４５における、少なくとも５０－１００ｍｓ以上の待ち時間を有する動作は、ユース・ケース２０５の多くの時間クリティカル機能を達成することができないであろう。これらの待ち時間の値の各々は、説明及び対比の目的のために提供されており、他のアクセス・ネットワーク媒体及び技術の使用は、待ち時間を更に低減し得ることが理解されるであろう。

【0113】

様々なユース・ケース２０５は、エッジ・クラウドを利用する複数のサービスに起因して、到来するストリームからの逼迫する利用の下でリソースにアクセスする可能性がある。短い待ち時間で結果を達成するために、エッジ・クラウド１１０内で実行されるサービスは、（ａ）優先度（スループット又は待ち時間）及びサービス品質（ＱｏＳ）（例えば、自律車両のトラフィックは、応答時間要件に関して温度センサーよりも高い優先度を有する可能性がある；又は、パフォーマンス感度／ボトルネックは、アプリケーションに応じて、コンピュータ／アクセラレータ、メモリ、ストレージ、又はネットワーク・リソースにおいて存在し得る）；（ｂ）信頼性及びレジリエンス（例えば、アプリケーションに応じて、幾つかの入力ストリームが作動する必要があり、トラフィックはミッション・クリティカルな信頼性でルーティングされ、他の一部の入力ストリームは時折生じる障害に耐えることができる）；及び（ｃ）物理的な制約（例えば、電力、冷却、及び形状因子）の観点から、様々な条件のバランスをとる。

【0114】

これらのユース・ケースのエンド・ツー・エンドのサービスの見方は、サービス・フローの概念を含み、トランザクションに関連付けられる。トランザクションは、リソース、作業負荷、ワークフロー、ビジネス機能、及びビジネス・レベルの条件に関し、サービス及び関連サービスを消費するエンティティに対する全体的なサービス条件を詳述する。説明される「条件」で実行されるサービスは、サービスのライフサイクルの間のトランザクションに対するリアル・タイム及びランタイムの契約遵守性を保証する方法で、各レイヤで管理されることが可能である。トランザクションのコンポーネントがＳＬＡに合意することを欠いている場合、システム全体（トランザクションのコンポーネント）は、（１）ＳＬＡ違反の影響を理解し、（２）ＳＬＡトランザクション全体を再開するためにシステム内の他のコンポーネントを増強し、（３）改善するステップを実装する機能を提供することができる。

【0115】

従って、これらのバリエーション及びサービス機能を考慮して、エッジ・クラウド１１０内のエッジ・コンピューティングは、リアル・タイムで又はほぼリアル・タイムで、ユース・ケース２０５の複数のアプリケーション（例えば、オブジェクト追跡、ビデオ監視、コネクテッド・カーなど）に対する応対及び応答を行う能力を提供し、これら複数のアプリケーションに対する非常に短い待ち時間の条件を充足することができる。これらの利点は、待ち時間又は他の制限に起因して従来クラウド・コンピューティングを利用できなかった全く新しいクラスのアプリケーション（ＶＮＦ、ファンクション・アズ・ア・サービス（ＦａａＳ）、標準プロセスなど）を可能にする。

【0116】

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

【0117】

より一般的なレベルでは、エッジ・コンピューティング・システムは、クライアント及び分散コンピューティング・デバイスからの連携を提供する、エッジ・クラウド１１０内で動作する前述のレイヤ（ネットワーク・レイヤ２００－２４０）における任意数の配備を包含するように説明されることが可能である。図３は、説明の目的でエッジ・コンピューティング環境の中に展開される分散コンピューティングのレイヤの抽象化された概要を与える。同一の（例えば、ピア・ツー・ピア）又は異なるレイヤにおける様々なタイプのネットワーク・リンクも描かれている。

【0118】

図３は、１つ以上のクライアント・コンピューティング・ノード３０２、１つ以上のエッジ・ゲートウェイ・ノード３１２、１つ以上のエッジ集約ノード３２２、１つ以上のコア・データ・センター３３２、及びネットワーク・レイヤを横断して分散されるグローバル・ネットワーク・クラウド３４２の間で分散されるように、エッジ・サービス及びアプリケーションをマルチ・ステークホルダー・エンティティに提供するエッジ・コンピューティング・システム３００を一般的に描いている。エッジ・コンピューティング・システム３００の実装は、電気通信サービス・プロバイダ（「ｔｅｌｃｏ」又は「ＴＳＰ」）、モノのインターネット（ＩｏＴ）サービス・プロバイダ、クラウド・サービス・プロバイダ（ＣＳＰ）、エンタープライズ・エンティティ、又は他の任意の数のエンティティにおいて、又はそれらの代わりに提供されることが可能である。システム３００の様々な実装及び構成は、サービス目標に合致するように調整される場合などのように、動的に提供されてもよい。

【0119】

エッジ・コンピューティング・システム３００の個々のノード又はデバイスは、レイヤ２００、２１０、２２０、２３０、２４０に対応する特定のレイヤに配置される。例えば、クライアント・コンピューティング・ノード３０２はエンドポイント・レイヤ２００に位置する一方、エッジ・ゲートウェイ・ノード３１２はエッジ・コンピューティング・システム３００のエッジ・デバイス・レイヤ２１０（ローカル・レベル）に位置する。更に、エッジ集約ノード３２２（及び／又は、フォグ・ネットワーキング構成３２６と共に又はその中で配置又は動作する場合、フォグ・デバイス３２４）は、ネットワーク・アクセス・レイヤ２２０（中間レベル）に配置される。フォグ・コンピューティング（又は「フォギング（ｆｏｇｇｉｎｇ）」）は、一般的に、クラウド・コンピューティングの、企業のネットワークのエッジへの拡張を指し、或いは、クラウド／エッジ・ランドスケープを横断するトランザクションを管理する能力を指し、典型的には、連携して分散した又はマルチノードのネットワークにおけるものである。フォグ・コンピューティングの幾つかの形態は、クラウド・コンピューティングの代わりに、エンド・デバイスとクラウド・コンピューティング・データ・センターとの間においてコンピューティング、ストレージ、及びネットワーキング・サービスの展開を提供する。フォグ・コンピューティングの幾つかの形態は、全体的なサービス・レベル合意を満たす能力に基づいて、特定の作業負荷をエッジへ又はクラウドへプッシュすることによって、全体的なトランザクションに関して作業負荷／ワークフロー・レベル・サービスを管理する能力も提供する。

【0120】

多くのシナリオにおけるフォグ・コンピューティングは、非セントラル化されたアーキテクチャを提供し、１つ以上のエッジ・ノード・デバイスと協調することによってクラウド・コンピューティングへの拡張として機能し、その後のローカライズされた制御、設定、管理を提供し、エンド・デバイスに対するものも提供する。更に、フォグ・コンピューティングは、類似のリソースを識別すること、及び、コンピューティング、ストレージ、又は接続関連サービスを完了するために、単独で又はクラウド・コンピューティングとの組み合わせで使用されることが可能なエッジ・ローカル・クラウドを作成するために協調すること、に対する能力を、エッジ・リソースに提供する。フォグ・コンピューティングはまた、クラウド・ベースのサービスが、それらの届く範囲をデバイスのネットワークのエッジまで拡張し、エッジ・デバイスに対するローカルで迅速なアクセスを提供できるようにすることが可能である。従って、フォグ・コンピューティングの幾つかの形態は、本願で議論されるエッジ・コンピューティングと整合する動作を提供し；本願で議論されるエッジ・コンピューティングの態様は、フォグ・ネットワーク、フォギング、及びフォグ・コンフィギュレーションにも適用可能である。更に、本願で説明されるエッジ・コンピューティング・システムの態様は、フォグ（ｆｏｇ）として構成されてもよく、又はフォグの態様は、エッジ・コンピューティング・アーキテクチャに統合されてもよい。

【0121】

コア・データ・センター３３２は、コア・ネットワーク・レイヤ２３０に（地域的又は地理的にセントラル化されたレベルに）位置する一方、グローバル・ネットワーク・クラウド３４２は、クラウド・データ・センター・レイヤ２４０（全域的又はワールド・ワイド・レイヤ）に位置する。「コア」の使用は、複数のエッジ・ノード又はコンポーネントによってアクセス可能な、ネットワーク内のより深いセントラル化されたネットワーク位置に対する用語として提供されるが、「コア」は、必ずしもネットワークの「中心」又は最も深い位置を示すとは限らない。従って、コア・データ・センター３３２は、エッジ・クラウド１１０の中に、エッジ・クラウド１１０に、エッジ・クラウド１１０の近傍に配置されてもよい。図３には、クライアント・コンピューティング・ノード３０２、エッジ・ゲートウェイ・ノード３１２、エッジ集約ノード３２２、エッジ・コア・データ・センター３３２、グローバル・ネットワーク・クラウド３４２の例示的な数が示されているが、エッジ・コンピューティング・システム３００は、各レイヤにおいて追加のデバイス又はシステムを含んでもよいことが理解されるべきである。如何なるレイヤにおけるデバイスも、互いに対するピア・ノードとして設定されることが可能であり、従って、サービス目標を満たすために協調的な方法で動作することが可能である。更に、図３に示すように、各レイヤ２００、２１０、２２０、２３０、２４０の構成要素の数は、一般に、（例えば、エンドポイントの方に近づいて移動する場合に）それぞれのより低いレベルで増加する。従って、１つのエッジ・ゲートウェイ・ノード３１２は、複数のクライアント・コンピューティング・ノード３０２に応対することが可能であり、１つのエッジ集約ノード３２２は、複数のエッジ・ゲートウェイ・ノード３１２に応対することが可能である。

【0122】

本願で提供される例と矛盾することなく、クライアント・コンピューティング・ノード３０２は、データのプロデューサ又はコンシューマとして通信することが可能な任意のタイプのエンドポイント・コンポーネント、デバイス、機器、又はその他のものとして具体化されてもよい。更に、エッジ・コンピューティング・システム３００で使用されるラベル「ノード」又は「デバイス」は、そのようなノード又はデバイスがクライアント又はスレーブの役割で動作することを必ずしも意味しておらず；むしろ、エッジ・コンピューティング・システム３００内の任意のノード又はデバイスは、エッジ・クラウド１１０を促進又は利用するための個別の又は接続されたハードウェア又はソフトウェア構成を含む個々のエンティティ、ノード又はサブシステムを指すことが可能である。

【0123】

従ってエッジ・クラウド１１０は、エッジ・ゲートウェイ・ノード３１２及びレイヤ２１０、２２０のエッジ集約ノード３２２によって及びその内部でそれぞれ動作させられるネットワーク構成要素及び機能的特徴から形成される。エッジ・クラウド１１０は、クライアント・コンピューティング・ノード３０２として図３に示される無線アクセス・ネットワーク（ＲＡＮ）対応のエンドポイント・デバイス（例えば、モバイル・コンピューティング・デバイス、ＩｏＴデバイス、スマート・デバイスなど）に近接して配置されるエッジ・コンピューティング及び／又はストレージ・リソースを提供する任意のタイプのネットワークとして具体化されることが可能である。換言すれば、エッジ・クラウド１１０は、ストレージ及び／又はコンピューティング能力を提供しつつ、モバイル・キャリア・ネットワーク（例えば、移動通信用グローバル・システム（ＧＳＭ）ネットワーク、ロング・ターム・エボリューション（ＬＴＥ）ネットワーク、５Ｇ／６Ｇネットワークなど）を含むサービス・プロバイダ・コア・ネットワーク内への立ち入りポイントとして機能する従来のネットワーク・アクセス・ポイント及びエンドポイント・デバイスを接続する「エッジ」として想定されてもよい。他のタイプ及び形態のネットワーク・アクセス（例えば、Ｗｉ－Ｆｉネットワーク、長距離無線ネットワーク、光ネットワークを含む有線ネットワーク）もまた、このような３ＧＰＰキャリア・ネットワークの代わりに、又はそれと組み合わせて利用されてもよい。

【0124】

幾つかの例では、エッジ・クラウド１１０は、フォグ・ネットワーキング構成３２６（例えば、フォグ・デバイス３２４のネットワーク、詳細は示されていない）の一部を形成するか、又はフォグ・ネットワーキング構成３２６内への又はそこを横切る立ち入りポイントを提供することができ、特定の機能を実行するためにリソース及びサービスを分散するシステム・レベルの水平及び分散アーキテクチャとして具体化されてもよい。例えば、フォグ・デバイス３２４の連携した分散されたネットワークは、ＩｏＴシステム構成の状況においてコンピューティング、ストレージ、制御、又はネットワーク化の態様を実行することができる。コア・データ・センター３３２とクライアント・エンドポイント（例えば、クライアント・コンピューティング・ノード３０２）との間のエッジ・クラウド１１０には、他のネットワーク化され、集約され、分散された機能が存在してもよい。これらのうちの幾つかは、複数の利害関係者のために調整される仮想エッジ及び仮想サービスの使用を含む、ネットワーク機能又はサービス仮想化の文脈で以下のセクションにおいて議論される。

【0125】

以下において更に詳細に説明されるように、エッジ・ゲートウェイ・ノード３１２及びエッジ集約ノード３２２は、クライアント・コンピューティング・ノード３０２に様々なエッジ・サービス及びセキュリティを提供するように協働する。更に、クライアント・コンピューティング・ノード３０２は、固定的又は移動可能であってもよく、各エッジ・ゲートウェイ・ノード３１２は、対応するクライアント・コンピューティング・ノード３０２が或る領域の周りを移動する際に、現在提供されているエッジ・サービス、関連するサービス・データ、及びセキュリティを伝搬するように、他のエッジ・ゲートウェイ・デバイスと協働することができる。そうするために、エッジ・ゲートウェイ・ノード３１２及び／又はエッジ集約ノード３２２は、複数のテナント及び複数の利害関係者の構成をサポートすることが可能であり、複数のサービス・プロバイダ、所有者、及び複数の消費者からのサービスは、単一の又は複数のコンピューティング・デバイスを介してサポートされ及び連携することが可能である。

【0126】

様々なセキュリティ・アプローチが、エッジ・クラウド１１０のアーキテクチャ内で利用されてもよい。マルチ・ステークホルダー環境では、ステークホルダーの利益を強化するポリシーを提供するために使用される複数のロード可能なセキュリティ・モジュール（ＬＳＭ）が存在する可能性がある。強化ポイント環境は、ロードされたＬＳＭポリシーの組み合わせを適用する複数のＬＳＭをサポートすることが可能である（例えば、Ａ、Ｂ、Ｃの何れか利害関係者がアクセスを制限する場合、アクセスは制限される、などのような最も厳しい効果のポリシーが適用される場合がある）。エッジ・クラウド１１０内では、各エッジ・エンティティは、エッジ・エンティティの利益を強化するＬＳＭを提供することができる。クラウド・エンティティは、クラウド・エンティティの利益を強化するＬＳＭを提供することができる。同様に、様々なフォグ及びＩｏＴネットワーク・エンティティは、フォグ・エンティティの利益を強化するＬＳＭを提供することができる。

【0127】

これらの例では、サービスは、構成要素レベル又は人間の知覚可能なレベルで考慮されるかどうかにかかわらず、一連の契約又は構成要素に対して実行されるトランザクションの観点から考慮されることが可能である。従って、サービス・プロバイダとのサービス契約を有するユーザは、サービスが、ＳＬＡの条件の下で提供されることを期待する。詳細には議論されないが、本願で議論されるエッジ・コンピューティング技術の使用は、契約の交渉中及び契約の履行の評価中に（サービスを実行するためにシステムによってどの要素が要求されるか、システムがサービス条件及び変化にどのように応答するか、などを識別するための）任務を果たすことができる。

【0128】

「サービス」は、しばしば様々な文脈で適用される広義の用語であるが、一般的には、一方のエンティティが他方の利益のために作業を提供して実行する２つのエンティティ間の関係を指す。しかしながら、あるエンティティから他方へ提供されるサービスは、エンティティ間の信頼を保証し、サービスの開始、最中、及び終了時に、定められた契約の条項及び条件に従ってトランザクションを管理する、特定のガイドラインとともに実施されなければならない。

【0129】

エッジ・コンピューティング・システムで使用するサービス間の例示的な関係が図４に描かれている。エッジ・コンピューティングのシナリオでは、互いに依存する動作中の幾つかのサービス及びトランザクション・レイヤ４００が存在し、これらのサービスは「サービス・チェーン」を形成する。最低レベルでは、構成要素はシステムを構成する。これらのシステム（又はリソース）は、互いに通信し、協働して、互いに、更に周囲の他の永続的又は一時的なエンティティに対して、多数のサービスを提供する。次に、これらのエンティティは、人が消費し得るサービスを提供することができる。この階層では、サービスを提供する個々の構成要素（又はサブ・エンティティ）が契約上合意された目的及び仕様を遵守することを確実にするために、各階層で提供されるサービスはトランザクション可能に接続されることを要する。各レイヤにおける逸脱は、サービス・チェーン全体に対する全体的な影響を及ぼす可能性がある。

【0130】

図４に示す階層で提供される可能性のあるサービスのタイプの１つは、シリコン・レベル・サービスである。例えば、ＳＤＳｉ（Ｓｏｆｔｗａｒｅ Ｄｅｆｉｎｅｄ Ｓｉｌｉｃｏｎ）タイプのハードウェアは、オペレーショナル・サービス・レベル合意の配信をイントラ・スケール、管理、及び保証する能力を通じて、トランザクションに対する低レベル遵守性を保証する能力を提供する。ＳＤＳｉ及び類似のハードウェア制御の使用は、システム内の機能及びリソースを特定のテナントに関連付け、それらのリソースに対する各自の資格（権利）を管理する能力を提供する。このような機能の使用は、コンピューティング・リソースを作業負荷に動的に「持ち込む」ことができる。

【0131】

例えば、オペレーショナル・レベル合意は、ＳＤＳｉの場合、「トランザクション・スループット」又は「適時性」を定義することが可能であり、システム（又はリソース）は特定のサービス・レベル仕様（ＳＬＳ ４３０）とサービス・レベル合意（ＳＬＡ ４１０）の目標（ＳＬＯ ４２０）を保証するためにサイン・アップすることが可能である。また、ＳＤＳｉハードウェアは、プロダクトの特性にアクセス及び管理し（追加／削除し）、ハードウェア機能及び利用性を上下に自由にスケーリングする権限を、シリコン構成要素（例えば、メトリック・テレメトリ４４０を生成する構成システム４４２の構成要素）に付与するために、インフラストラクチャ及びリソース・オーナーに能力を与える。更に、それはテナントごとに決定論的な特徴割り当てを行う能力を提供する。また、実行中のサービス、クライアントの動作を中断したり、又はシステムをリセット又はリブートしたりする必要なしに、決定論的なオーケストレーション及びサービス管理を、機能の動的な（又はサブスクリプション・ベースの）活性化に結び付ける機能も提供する。

【0132】

最下位レイヤでは、ＳＤＳｉは、単独のリソースはシステム内で提供することを要する契約で合意されたサービス・レベル仕様に対する積極的な遵守性を保証するために、システムに対してサービス及び保証を提供することができる。更に、ＳＤＳｉは、コンポーネント当たり１つ又は複数のテナントの契約上の権利（資格）、使用及び関連する財務、更にはシリコン・レベルの機能（例えば、ＳＫＵ機能）を管理する能力を提供する。シリコン・レベルの特徴は、コンピューティング、ストレージ又はネットワークの能力に、パフォーマンスに、決定論に、又はセキュリティ、暗号化、加速などの特徴にさえ関連付けることができる。これらの機能は、テナントが特定のサービス・レベルの合意を達成できるだけでなく、管理及びデータ収集を支援し、最も低い管理可能なコンポーネント・レベルでのトランザクション及び契約の合意を保証する。

【0133】

サービス階層のうちのより高いレイヤであるリソース・レベル・サービスは、ＳＤＳｉを介して、又は個別にアドレス指定可能なリソース（コンピューティング、ストレージ、及びネットワーク）の構成を介して、システム・レベル機能を取得及びイネーブルにすることによって、作業負荷の要求を充足するための能力を（完全に又は構成を通じて）提供するシステムを含む。

【0134】

サービス階層のうちのより高いレイヤであるワークフロー・レベル・サービスは、サービス・チェーンがワークフロー・レベル要件を有する可能性があるので、水平になっている。ワークフローは、エンド・ツー・エンド・サービスに特定のサービス・レベル目標及び要件を提供するために、作業負荷の間の依存関係を記述する。これらのサービスは、高い利用可能性、冗長性、回復性、フォールト・トレランス、負荷平準化などの特徴及び機能を含むことが可能である。ワークフロー・サービスは、エンド・ツー・エンド・サービスを保証するために、リソース及びシステムの間の依存性及び関連性を定義し、関連するネットワーク及びストレージの要件を記述し、更にはトランザクション・レベルの要件及び関連する契約を記述する。ワークフロー・レベル・サービスは通常、サービス・レベル目標で評価され、必須の及び期待されるサービス要件を有する。

【0135】

サービス階層のうちのより高いレイヤであるビジネス機能サービス（ＢＦＳ）はオペラブルであり、これらのサービスは、互いに対する関係を有し且つ特定の機能を顧客に提供するサービスの様々な要素である。エッジ・コンピューティングで自動運転の例の場合、ビジネス機能は、例えば「イベントへのタイムリーな到着」のサービスを構成する可能性があり、このサービスは、ユーザ・エンティティの目標を達成するために、幾つかのビジネス機能を協調させる必要があり、ビジネス機能は：即ち、ＧＰＳガイダンス、ローカルな交通状況のＲＳＵ（路側機）認識、ユーザ・エンティティの支払履歴、リソースのユーザ・エンティティの認可などである。更に、これらのＢＦＳは複数のエンティティにサービスを提供する場合に、各ＢＦＳは自らのＳＬＡを管理し、自身のリソース（作業負荷及びワークフロー）に対する需要に対処する能力を認識している。要件及び需要が増加するにつれて、サービス変更要件をワークフロー及びリソース・レベルのサービス・エンティティに伝達し、その結果、サービス・エンティティは、充足のための各自の能力に対する洞察を提供することができる。このステップは、次のレイヤへの全体的なトランザクション及びサービス配信を支援する。

【0136】

サービス階層におけるサービスの最上位レイヤであるビジネス・レベル・サービス（ＢＬＳ）は、提供される機能に結び付けられる。このレベルでは、顧客又はエンティティは、サービスを提供するために、サービスがどのように構成されるか、又はどのような構成要素が使用され、管理され、追跡されるか、を把握していない可能性がある。ビジネス・レベル・サービスの主な目的は、合意された財務上の契約において顧客とプロバイダとの間で設定された全般的な契約条項及び条件に従って、顧客により設定された目標を達成することである。ＢＬＳは幾つかのビジネス機能サービス（ＢＦＳ）及び全体的なＳＬＡにより構成される。

【0137】

本願で説明されるこの構成及びその他のサービス管理機能は、固有の複雑なリソース及びサービスの相互作用を伴うエッジ・コンピューティングの様々な要求を満たすように設計される。このサービス管理構成は、エージェント又はミドルウェア機能によるのではなく、フレームワーク内のリソース・ベーシック・サービスのうちの幾つかに本質的に対処するように意図されている。突き止める、発見する、アドレス指定する、トレースする、追跡する、識別する、登録する等のようなサービスは、リソースがフレームワーク上に現れるように、事実上近くに配置される可能性があり、リソース又はセキュリティ・ドメインのマネージャ又はオーナーは、リソースの発見、登録、及び認証を順番通りに行うことを保証するために管理規則及びポリシーを使用することが可能である。

【0138】

更に、本願で説明される任意の数のエッジ・コンピューティング・アーキテクチャは、サービス管理機能に適合させることができる。これらの特徴は、システムが、リソースの動き、ベクトル、及び方向に関する情報を常に認識及び記録することができるようにし、また、これらの特徴を、デバイスに関連するテレメトリ及びメタデータの両方として完全に記述できるようにする。これらのサービス管理機能は、セキュリティの要素だけでなく、リソース管理、課金、計量に使用することが可能である。同様の機能はまた、関連するリソースにも適用され、その場合において、センサーのようなインテリジェントでないデバイスは、エッジ・ゲートウェイのような、より管理しやすいリソースに接続される可能性がある。サービス管理フレームワークは、リソースの保管又はカプセル化の変更を認識している。ノードとコンポーネントは、短期間の間又はライフサイクル全体の間に、直接的にアクセス可能であるか、又は親デバイス又は代替の責務を有するデバイスを介して間接的に管理される可能性があるので、このタイプの構造は、サービス・フレームワークにそのインターフェースを介して中継され、外部の問い合わせメカニズムに対して利用可能になる。

【0139】

更に、このサービス管理フレームワークは、サービスを認識するものであり、データ分析システムへのデータ・アップロードのためのアクセス及びリソースの利用可能性及び能力とサービス配信要求との間のバランスを自然にとる。ネットワーク転送が劣化し、失敗し、又はより高いコスト又はより低い帯域幅の機能へ変化する場合、サービス・ポリシー監視機能は、ユーザのプライバシー又はコスト制約の範囲内で、代替の分析及びサービス配信メカニズムを提供する。これらの機能を使用すると、ポリシーは、分析及びダッシュボード・サービスの呼び出しをエッジでトリガし、継続的なサービスの可用性を削減された忠実度又は粒度で保証することができる。ネットワーク転送が再確立されると、定期的なデータ収集、アップロード、分析サービスを再開することが可能である。

【0140】

Ａ．エッジ・コンピューティングの構成及び配置
マルチ・ステークホルダー・エッジ・コンピューティング・システムの配置は、複数のテナント及びサービス・プロバイダによって使用するために、複数のエッジ・ノード及びサブシステムの中で、複数のサービス及び仮想エッジ・インスタンスの配備を可能にするように配置及び調整されることが可能である。クラウド・サービス・プロバイダ（ＣＳＰ）に適用可能なシステム例では、エッジ・コンピューティング・システムの配備は、クラウド・コンピューティングに対する補助ツールとしてエッジ・コンピューティング・ノードを導入するために、「オーバー・ザ・トップ」アプローチにより提供されることが可能である。通信サービス・プロバイダ（ＴＳＰ）に適用可能な対照的なシステム例では、エッジ・コンピューティング・システムの配備は、ネットワーク・アクセス（異なるタイプのデータ・アクセス・ネットワークからのもの）が集約される場所にエッジ・コンピューティング・ノードを導入するために、「ネットワーク集約」アプローチを介して提供されることが可能である。図５及び図６は、各エッジ・コンピューティング・システムにおけるネットワーキング及びサービスのためのこれらのオーバー・ザ・トップ及びネットワーク集約のアプローチを対比している。しかしながら、これらのオーバー・ザ・トップ及びネットワーク集約のアプローチは、後の例で示唆されるように、ハイブリッド又はマージされたアプローチ又は構成で一緒に実装されることが可能である。

【0141】

図５では、様々なクライアント・エンドポイント５１０（モバイル・デバイス、コンピュータ、自律車両、ビジネス・コンピューティング装置、産業処理装置の形態におけるもの）が、サービス又はデータ・トランザクションに対する要求５２０を提供し、サービス又はデータ・トランザクションに対する応答５３０を、エッジ・クラウド１１０から（例えば、無線又は有線ネットワーク５４０を介して）受信する。エッジ・クラウド１１０内では、ＣＳＰは、分散コンテンツ配信ネットワークから、キャッシュされたコンテンツを提供するために、エッジ・コンテンツ・ノード５５０のような様々なコンピューティング及びストレージ・リソースを配備することができる。エッジ・コンテンツ・ノード５５０上で利用可能な他の利用可能なコンピューティング及びストレージ・リソースは、他のサービスを実行し、他の作業負荷を充足するために使用されることが可能である。エッジ・コンテンツ・ノード５５０及びエッジ・クラウド１１０の他のシステムは、クラウド又はデータ・センター５７０に接続され、ウェブサイト、アプリケーション、データベース・サーバーなどのための、クラウド／データ・センターからの、より高い待ち時間の要求を満たすために、バックホール・ネットワーク５６０を使用する。

【0142】

図６において、様々なクライアント・エンドポイント６１０（モバイル・デバイス、コンピュータ、自律車両、ビジネス・コンピューティング装置、産業処理装置の形態のもの）は、エンドポイント・ネットワーク集約のタイプに特有の要求及び応答を交換する。例えば、コンピュータ、ビジネス・コンピューティング装置、及び産業処理装置は、オンプレミス・ネットワーク・システム６３２を介して要求及び応答６２２を交換することによって、有線ブロードバンド・ネットワークを介してネットワーク・アクセスを得ることができる。モバイル・コンピューティング・デバイスは、セルラー・ネットワーク・タワー６３４を介して要求及び応答６２４を交換することによって、無線ブロードバンド・ネットワークを介してネットワーク・アクセスを得ることができる。自律車両は、街頭に配置されたネットワーク・システム６３６を通じて、無線車両ネットワークを介して、要求及び応答６２６のためのネットワーク・アクセスを得ることができる。しかしながら、ネットワーク・アクセスのタイプに関係なく、ＴＳＰは、トラフィック及び要求を集約するために、エッジ・クラウド１１０内に集約ポイント６４２、６４４を配備することができる。従って、エッジ・クラウド１１０内で、ＴＳＰは、要求されたコンテンツを提供するために、エッジ集約ノード６４０などの様々なコンピューティング及びストレージ・リソースを配備することができる。エッジ集約ノード６４０及びエッジ・クラウド１１０の他のシステムは、クラウド又はデータ・センター６６０に接続され、クラウド又はデータ・センター６６０は、バックホール・ネットワーク６５０を使用して、ウェブサイト、アプリケーション、データベース・サーバーなどのためのクラウド／データ・センターからのより高い待ち時間の要求を充足する。（エッジ集約ノード６４０及び集約ポイント６４２、６４４の追加又は統合インスタンスは、単一のサーバー・フレームワーク上に配備されたものを含み、エッジ・クラウド１１０又はＴＳＰインフラストラクチャの他の領域内にも存在し得る）。

【0143】

ＣＳＰ又はＴＳＰ構成の何れかの拡張として、図７及び図８は、複数のエッジ・ノード及び複数のテナントの間で動作するエッジ・コンピューティング・システムを横断する仮想エッジ構成の配備及びオーケストレーションを示す。具体的には、図７は、様々な仮想エッジ・インスタンスにアクセスする様々なクライアント・エンドポイント７１０（例えば、スマート・シティ／ビルディング・システム、モバイル・デバイス、コンピューティング・デバイス、ビジネス／ロジスティクス・システム、産業システムなど）に対する要求及び応答を充足するために、エッジ・コンピューティング・システム７００における第１エッジ・ノード７２２及び第２エッジ・ノード７２４の連携を示す。図５及び図６の例と同様に、仮想エッジ・インスタンスは、ウェブサイト、アプリケーション、データベース・サーバーなどに対するより高い待ち時間の要求のためにクラウド／データ・センター７４０へのアクセスとともに、エッジ・クラウドにおけるエッジ・コンピューティング能力及び処理を提供する。しかしながら、エッジ・クラウドは、複数のテナント又はエンティティに対する複数のエッジ・ノード間で処理の連携を可能にする。

【0144】

図７の例では、これらの仮想エッジ・インスタンスは、エッジ・ストレージ、コンピューティング、及びサービスの第１の組み合わせを提供する第１テナント（テナント１）に提供される第１仮想エッジ７３２と、エッジ・ストレージ、コンピューティング、及びサービスの第２の組み合わせを提供する第２仮想エッジ７３４とを含む。仮想エッジ・インスタンス７３２、７３４は、エッジ・ノード７２２、７２４の間に分散され、要求及び応答が同じ又は異なるエッジ・ノードにより満たされるシナリオを含んでもよい。エッジ・ノード７２２、７２４の構成は、エッジ・プロビジョニング機能７５０に基づいて、分散されているが連携している形式で動作する。複数のテナントの間のアプリケーション及びサービスのための連携した動作を提供するエッジ・ノード７２２、７２４の機能は、オーケストレーション機能７６０に基づいて生じる。

【0145】

７１０の装置の一部は、テナント１がテナント１の「スライス」内で機能する一方、テナント２がテナント２のスライス内で機能するマルチ・テナント・デバイスであることが理解されるべきであり（更なる例においては、追加の又はサブテナントが存在する可能性があり、各テナントは、完全に特定のハードウェア機能に至る、特定の機能セットに結びついた権限を具体的に取引可能に与えられる場合さえあり得る）。信頼されたマルチ・テナント・デバイスは、鍵とスライスの組み合わせが「信頼の基点」（ＲｏＴ）又はテナント固有のＲｏＴと考えられることが可能であるように、テナント固有の暗号鍵を更に含んでもよい。更に、単一のＤＩＣＥハードウェア構築ブロックが、デバイス能力（フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）など）を階層化するための階層化され信頼されるコンピューティング基盤を構築するために使用されることが可能であるように、ＤＩＣＥ（Ｄｅｖｉｃｅ Ｉｄｅｎｔｉｔｙ Ｃｏｍｐｏｓｉｔｉｏｎ Ｅｎｇｉｎｅ）アーキテクチャを使用して動的に処理された構成されてもよい。ＲｏＴは、更に、信頼されたコンピューティング・コンテキストに使用されて、マルチ・テナント性をサポートするために有用な「ファン・アウト」を可能にすることができる。マルチ・テナント環境内において、各エッジ・ノード７２２、７２４は、ノード毎に複数のテナントに割り当てられるローカル・リソースのためのＬＳＭ又はセキュリティ機能強化ポイントとして動作することができる。更に、テナントのランタイム及びアプリケーション実行（例えば、インスタンス７３２、７３４）は、潜在的に複数の物理ホスティング・プラットフォームに及ぶリソースの仮想エッジ抽象化を作成するＬＳＭ又は他のセキュリティ機能の強化ポイントとして役立つ可能性がある。最後に、オーケストレーション・エンティティにおけるオーケストレーション機能７６０は、テナント境界に沿ってリソースをマーシャリングするためのＬＳＭ又はセキュリティ機能強化ポイントとして動作することができる。

【0146】

エッジ・コンピューティング・ノードは、リソース（メモリ、ＣＰＵ、ＧＰＵ、割り込みコントローラ、Ｉ／Ｏコントローラ、メモリ・コントローラ、バス・コントローラなど）を区分することが可能であり、各パーティションは、ＲｏＴ機能を含む可能性があり、更に、ＤＩＣＥモデルによるファン・アウト及び階層化はエッジ・ノードに適用される可能性がある。コンテナ、ＦａａＳエンジン、サーブレット、サーバー、又は他の演算抽象化から構成されるクラウド・コンピューティング・ノードは、ＤＩＣＥ階層化及びファン・アウト構造に従って区分され、それぞれのＲｏＴコンテキストをサポートする。従って、個々のＲｏＴスパニング・デバイス７１０、７２２、及び７４０は、全ての要素をエンド・ツー・エンドでリンクするテナント固有の仮想的に信頼されたセキュア・チャネルを確立することが可能であるように、分散した信頼されるコンピューティング基盤（ＤＴＣＢ）の確立を連携することができる。

【0147】

図８の例では、エッジ・コンピューティング・システム８００は、マルチ・オーナー、マルチ・テナントの環境において、コンテナ（内蔵された、コード及び必要な依存性を提供するソフトウェアの内蔵された配備可能なユニット）の利用を通じて、複数のアプリケーションのオーケストレーションを提供するように拡張される。マルチ・テナント・オーケストレータは、図７の信頼される「スライス」の概念のプロビジョニング及びライフサイクルに関連する鍵管理、信頼アンカー管理、及びその他のセキュリティ機能を実行するために使用されることが可能である。オーケストレータは、ＤＩＣＥ階層化及びファン・アウト構造を使用して、テナント固有である信頼コンテキストの基点を作成することができる。従って、後述するオーケストレータによって提供されるオーケストレーション機能８４０は、テナント固有のオーケストレーション・プロバイダとして参加することができる。

【0148】

図７のシナリオと同様に、エッジ・コンピューティング・システム８００は、複数の仮想エッジ・インスタンスからの（及び、不図示のクラウド又はリモート・データ・センターからの）様々なクライアント・エンドポイント８１０に対する要求及び応答を満たすように構成される。これらの仮想エッジ・インスタンスの使用は、複数のテナント及び複数のアプリケーション（例えば、拡張現実（ＡＲ）／仮想現実（ＶＲ）、企業アプリケーション、コンテンツ配信、ゲーム、演算オフロード）を同時にサポートする。更に、仮想エッジ・インスタンス内には、複数のタイプのアプリケーション（例えば、ノーマルなアプリケーション、待ち時間に敏感なアプリケーション、待ち時間が致命的なアプリケーション、ユーザー・プレーン・アプリケーション、ネットワーキング・アプリケーションなど）が存在する可能性がある。また、仮想エッジ・インスタンスはまた、異なる地理的な位置にある複数のオーナーのシステム（又は、複数のオーナーによって共有又は共同管理される個々のコンピューティング・システム及びリソース）に渡って及ぶ可能性がある。

【0149】

エッジ・クラウド内で、第１エッジ・ノード８２０（第１オーナーによって運用される）及び第２エッジ・ノード８３０（第２オーナーによって運用される）はそれぞれ、オーケストレータを操作して、個々のテナントに対して提供される仮想エッジ・インスタンス内の様々なアプリケーションの実行を連携させる。エッジ・ノード８２０、８３０は、エッジ・プロビジョニング機能８５０に基づいて連携させられる一方、種々のアプリケーションの動作は、オーケストレーション機能８４０により連携させられる。更に、オーケストレータは、サービスが各自のＳＬＡに従って完了することを保証するために、たとえオーナーシップの境界を越えて提供されたとしても、あるオーナー（但し、第２オーナーからは隠れているオーナー）に提供に提供される特定のハードウェア機能を識別することができる。従って、仮想エッジ、コンテナ・オーケストレータ、及びサービス／アプリ・オーケストレータは、特定のテナントに結び付けられたノード固有のリソースのために、ＬＳＭ又は他のセキュリティ強化ポイントを提供することができる。

【0150】

図９は、エッジ・コンピューティング・システムにおいてコンテナを配備する様々なコンピューティング構成を示す。簡略化された例として、システム構成９１０、９２０は、コンテナ・マネージャ（例えば、コンテナ・マネージャ９１１、９２１、９３１）が、コンピューティング・ノード（構成９１０における９１５）を介した実行によってコンテナ化されたポッド、機能、及びファンクション・アズ・ア・サービス（ＦａａＳ）インスタンスを開始するように、又はコンピューティング・ノード（構成９２０における９２３）を介した実行によってコンテナ化された仮想化されたネットワーク機能を別々に実行するように適合された設定を示す。この構成は、システム構成９３０（コンピューティング・ノード９３６を使用するもの）における複数のテナントの利用に適合され、コンテナ化されたポッド（例えば、ポッド９１２）、機能（例えば、機能９１３、ＶＮＦ９２２、９３６）、及びファンクション・アズ・ア・サービス・インスタンス（例えば、ＦａａＳインスタンス９１５）は、個々のテナントに特有の仮想マシン（例えば、テナント９３２、９３３に対するＶＭ９３４、９３５）内で起動される（仮想化されたネットワーク機能の実行は別である）。この構成は更に、コンテナ・ベースのオーケストレーション・システム９４１によって連携するように、コンテナ９４２、９４３、又はコンピューティング・ノード９４４における種々の機能、アプリケーション、及び機能の実行を提供するシステム構成９４０での使用に適合される。

【0151】

図８及び図９に示すシステム構成は、ＶＭ、コンテナ、及び機能を、アプリケーション構成の観点から等しく扱うアーキテクチャを提供する（そして、結果として生じるアプリケーションは、これら３つの構成要素の組み合わせである）。各々の構成要素は、ローカル・バックエンドとして１つ以上の加速器（ＦＰＧＡ、ＡＳＩＣ）のコンポーネントの使用を含むことができる。このようにして、アプリケーションは、オーケストレータによって連携させられる複数のエッジ・オーナーを横断して分割されることが可能である。

【0152】

図９の文脈において、コンテナ・マネージャ、コンテナ・オーケストレータ、及び個々のノードは、ＬＳＭ又は他のセキュリティ強化ポイントを提供することが可能である。しかしながら、図８及び図９の構成の何れかにおいて、テナントの隔離が調整されてもよく、テナントに割り当てられるリソースは第２テナントに割り当てられるリソースと異なるが、エッジ・オーナーは、リソースの割り当てがテナント境界を越えては共有されないことを保証するように協働する。また、テナントは、サブスクリプション、トランザクション／契約ベースでの「使用」を許容することが可能であるので、リソースの割り当てはテナント境界にわたって隔離させることが可能である。これらのコンテキストでは、仮想化、コンテナ化、エンクレーブ、及びハードウェア分割方式が、テナントを強化するためにエッジ・オーナーによって使用される可能性がある。他の隔離環境は、ベア・メタル（専用）装置、仮想マシン、コンテナ、コンテナ上の仮想マシン、又はそれらの組み合わせを含むことが可能である。以下で更に説明されるＦａａＳ環境で提供される機能のような機能は、テナントの境界を強化するために、これらの隔離環境のいずれかで実行されることが可能である。

【0153】

図１０Ａ及び１０Ｂは、エッジ・コンピューティング・システムのインスタンスにおける連携したコンピューティング機能及びサービスを用いた分散エッジ・コンピューティングの展開を示す。エッジ・コンピューティング環境１０１０内では、多数の地域的に配置されたエッジ（例えば、１０１１、１０１３、１０１４）は、分散エッジ上のコンピューティング・リソース（シン（ｔｈｉｎ）エッジ・インスタンス１０１３又はクライアントＰＣ１０１４）において、アプリケーション（例えば、１０１５）及び機能（例えば、１０１６）を介して、サービスの実行を連携させるためのコンテナ・マネージャ（例えば、１０１２）を含む。エッジ・コンピューティング環境１０２０内では、分散されたエッジ（シン・エッジ・インスタンス１０２１）は、追加の処理能力を有する他の分散されたエッジ（大／中のエッジ・インスタンス１０３０）と連携する。例えば、特定の分散エッジ・インスタンス（シン・エッジ１０２１）で動作するアプリケーション又は機能（例えば、１０２２又は１０２３）は、（ＧＰＵアズ・ア・サービス１０３０の形態で、大／中エッジ・インスタンス１０３０によって提供される）エッジ・クラウド内でＧＰＵ処理能力を更に呼び出すことが可能であり；又は別の例として、クライアント・コンピュータ（クライアントＰＣ １０２４）におけるアプリケーション又は機能（例えば、１０２５、１０２６）は、（暗号化・アズ・ア・サービス１０３５における、大／中エッジ・インスタンス１０３０によって提供される）エッジ・クラウド内で処理能力を更に呼び出すことができる。他のアプリケーション、機能、ファンクション・アズ・ア・サービス、又はアクセラレータ・アズ・ア・サービス（例えば、１０３１、１０３２、１０３３、１０３４）は、エッジ・クラウド（例えば、計算機１０３６）によって提供されることが可能であり、エッジ・ノード間で連携又は分散などが行われてもよい。更に、エッジ・コンピューティング・アーキテクチャでは、各エッジ・ノード、ＶＭ、コンテナは、又はベア・メタル・ノードさえ、他のノードが「～アズ・ア・サービス」モデルに使用できる一連の提示を作成するように、自己記述型、自己認識型、及び自己管理型であってもよい。

【0154】

更なる例において、ソフトウェアで定義又は制御されたシリコン・ハードウェア、及び他の構成可能なハードウェアの態様は、図１０Ａ及び１０Ｂのアプリケーション、機能、及びサービス、並びに本願で議論される他のシナリオと統合されてもよい。ソフトウェア定義シリコンは、（例えば、ハードウェア構成自体の中でのアップグレード、再構成、又は新機能の提供によって）作業負荷又はその一部を正す構成要素の能力に基づいて、契約又はサービス・レベル合意を充足する何らかのリソース又はハードウェア構成要素の能力を保証するために使用されてもよい。

【0155】

図１１は、エッジ・コンピューティング・システムの種々の形態を提供するエッジ・メッシュの中で連携したエッジ・コンピューティングの構成を示す。最も単純な例示的な構成１１１０は、エッジ・メッシュを示す。より進歩した構成１１２０は、マイクロサービス（「ＭＳ」として示されるマイクロサービスを有する）と共に、エッジ・メッシュの態様を動作させるために使用されるサイドカー・ローディング（「ＳＣ」として示されるサイドカー）を示す。より進歩した構成は、エッジ間にわたって接続されるように、第１エッジ・メッシュ１１３０Ａが第２エッジ・メッシュ１１３０Ｂに接続されることを示す。これらの環境の中で、エッジ・コンピューティング・ノードによって提供されるマイクロサービスは、機能として扱われてもよいが、サイドカーは、他の機能との接続をサポートする機能である。

【0156】

サイドカーの貴重な特徴は、ＬＳＭや他のセキュリティ・ポリシー強化ポイントを提供することであり、その環境は、ペアにされたコンテナ環境と「信頼される経路」の関係を有する。サイドカーはデータ及び状態を共有することが可能である。サイドカーは、セキュア・エンクレーブ（ｓｅｃｕｒｅ ｅｎｃｌａｖｅ）が信頼できる実行環境として認識されるのと同じ程度で「信頼される」又は「信頼できる」ものでなくてもよい；しかしながら、サイドカーはペアにされたコンテナと少なくとも同程度に信頼されることが仮定される。更に、サイドカーは、異なるステージング及びフィルタリングが適用されることが可能なサンドボックス環境を提供するので、外部エンティティとの相互作用を仲介するためにしばしば使用される。これは、ペアにされたコンテナに固有であるアプリケーション・ファイアウォールに類似した機能を提供する。

【0157】

従って、サイドカーは、暗号鍵の生成、保存、及び使用などのセキュリティ機能をサポートするための信頼される実行環境を提供することができる。サイドカーはまた、プライバシー、知的財産、コンテンツ、又はその他の情報資産を、さほどハード化されていないメッシュ・ノードから保護する、セキュリティに敏感な演算を可能にすることができる。更に、信頼されたコンピューティング能力を有するサイドカーは、マイクロサービス構成を、ピア・マイクロサービス及びサイドカー・ノードに対して証明することができる。マイクロサービス／サイドカー・メッシュ・ノードのネスティングは、マイクロサービス及びサイドカー・ノードの構成が、正しい／正しくない構造、接続、及びトポロジについて評価され得るように、ネスティング構造又はメッシュ構造を証明することができる。

【0158】

配置１１１０、１１２０で提供されるメッシュ方式は、機能のネットワーク（カスケード）が存在することを可能にする。例えば、複雑なプログラムは、トップ・レベルの「内部ループ」から構成され、これは更に幾つかの内部－内部ループであり、これは更に内部－内部－内部ループなどから構成されることが可能である。内部ループの各ネスティングは、アクセラレータ・オフロードによってサポートすることができる。従って、多くの複雑な又は連携したシナリオは、これらのエッジ・コンピューティング構成により可能にされ得る。

【0159】

本願で説明されるエッジ・コンピューティング・システム及び構成は、様々なソリューション、サービス、及び／又はユース・ケースに適用可能であることが理解されるべきである。一例として、図１２は、エッジ・クラウド１１０を実装するエッジ・コンピューティング・システム１２００内のアプリケーションへのモバイル・アクセスを含む、簡略化された車両コンピューティング及び通信のユース・ケースを示す。このユース・ケースでは、個々のクライアント・コンピューティング・ノード１２１０は、道路の走行中にエッジ・ゲートウェイ・ノード１２２０と通信する、対応する車両内に位置する車両内コンピューティング・システム（例えば、車両内ナビゲーション及び／又はインフォテインメント・システム）として具現化されることが可能である。例えば、エッジ・ゲートウェイ・ノード１２２０は、道路に沿って、道路の交差点に、又は道路付近の他の位置に、配置されることが可能な、他の、別個の、機械的な効用を有する構造に組み込まれた道路側キャビネット又は他の筐体の中に配置されることが可能である。それぞれの車両が道路に沿って移動する際に、そのクライアント・コンピューティング・ノード１２１０と特定のエッジ・ゲートウェイ・デバイス１２２０との間の接続は、クライアント・コンピューティング・ノード１２１０のための一貫したコネクション及びコンテキストを維持するように伝搬することができる。同様に、モバイル・エッジ・ノードは、高優先度のサービスに集約するか、（ドローンの場合のように）基本サービスのためのスループット又はレイテンシ解決の条件に従って集約することが可能である。それぞれのエッジ・ゲートウェイ・デバイス１２２０は、ある量の処理及びストレージ能力を含み、そのため、クライアント・コンピューティング・ノード１２１０のためのデータの何らかの処理及び／又はストレージは、１つ以上のエッジ・ゲートウェイ・デバイス１２２０上で実行されてもよい。

【0160】

エッジ・ゲートウェイ・デバイス１２２０は、通信基地局１２４２（例えば、セルラー・ネットワークの基地局）に又はその中に配置されたコンピューティング・サーバー、機器、又は構成要素として例示的に統合された１つ以上のエッジ・リソース・ノード１２４０と通信してもよい。上述したように、それぞれのエッジ・リソース・ノード１２４０は、ある量の処理及びストレージ能力を含み、従って、クライアント・コンピューティング・ノード１２１０のためのデータの何らかの処理及び／又はストレージは、エッジ・リソース・ノード１２４０で実行されてもよい。例えば、緊急性又は重要性の低いデータの処理は、エッジ・リソース・ノード１２４０によって実行されてもよい一方、より緊急性又は重要性の高いデータの処理は、エッジ・ゲートウェイ・デバイス１２２０によって実行されてもよい（例えば、各コンポーネントの能力、又は緊急性又は重要性を示すリクエスト内の情報に依存してもよい）。データ・アクセス、データ・ロケーション又は待ち時間に基づいて、処理の優先度が処理アクティビティの間に変化した場合、作業はエッジ・リソース・ノード上で継続する可能性がある。同様に、設定可能なシステム又はハードウェア・リソースそれ自体は（例えば、ローカル・オーケストレータを介して）、新たな需要を満たすために追加のリソースを提供するように活性化されることが可能である（例えば、計算リソースを作業負荷データに適合させる）。

【0161】

エッジ・リソース・ノード１２４０はまた、コア・データ・センター１２５０と通信し、これは、中央位置（例えば、セルラー通信ネットワークのセントラル・オフィス）に配置されたサーバー、機器、及び／又はその他の構成要素を含むことが可能である。コア・データ・センター１２５０は、エッジ・リソース・ノード１２４０及びエッジ・ゲートウェイ・デバイス１２２０によって形成されるエッジ・クラウド１１０の動作のためにグローバル・ネットワーク・クラウド１２６０（例えば、インターネット）に対するゲートウェイを提供することができる。更に、幾つかの例では、コア・データ・センター１２５０は、ある量の処理及びストレージ能力を含んでもよく、クライアント・コンピューティング・デバイスに対するデータの何らかの処理及び／又はストレージ（例えば、緊急性又は重要性が低い、又は複雑性が高い処理）は、コア・データ・センター１２５０で実行されてもよい。

【0162】

エッジ・ゲートウェイ・ノード１２２０又はエッジ・リソース・ノード１２４０は、ステートフル・アプリケーション１２３２及び地理的に分散したデータベース１２３４の使用を提供してもよい。アプリケーション１２３２及びデータベース１２３４は、エッジ・クラウドのレイヤにおいて水平に分散しているように図示されているが、アプリケーションのリソース、サービス、又は他のコンポーネントは、エッジ・クラウドを通じて垂直方向に分散してもよいことが理解されるであろう（クライアント・コンピューティング・ノード１２１０で実行されるアプリケーションの一部、エッジ・ゲートウェイ・ノード１２２０又はエッジ・リソース・ノード１２４０で実行される他の部分などを含む）。更に、前述したように、サービスの目的と義務を満たすために、どのレベルでもピア関係が存在する可能性がある。更に、特定のクライアント又はアプリケーションのためのデータは、変化する条件に基づいて（例えば、加速リソースの利用可能性に基づいて、車両の移動に追従して、等々）、エッジからエッジへ移動することができる。例えば、アクセスの「減衰率」に基づいて、以後の次のオーナーを識別するために、又は、データ又は計算アクセスがもはや実行不可能になる場合に、予測を行うことができる。これら及びその他のサービスは、トランザクションの遵守性及び無損失を保つために必要とされる作業を完了するために利用されることが可能である。

【0163】

更なる例では、図１２は、エッジ・ノードがそれをホストするプラットフォームに沿って他の地理的位置に移動する場合に、車両（自動車／トラック／路面電車／列車）又は他の移動ユニットでホストされるエッジ・ノードのような、種々のタイプの移動エッジ・ノードを利用することができる。ビークル・ツー・ビークル通信では、個々の車両が、他の車両のためのネットワーク・エッジ・ノードとして（例えば、キャッシュ、報告、データ集約などを行うために）動作することさえ可能である。従って、様々なエッジ・ノードで提供されるアプリケーション・コンポーネントは、個々のエンドポイント・デバイス又はエッジ・ゲートウェイ・ノード１２２０における幾つかの機能又は動作、エッジ・リソース・ノード１２４０における幾つかの他の機能等、及びコア・データ・センター１２５０又はグローバル・ネットワーク・クラウド１２６０におけるその他の機能等の間の連携を含む、静的な又は移動可能な設定の中で分散されてもよいことが理解されるであろう。

【0164】

更なる構成において、エッジ・コンピューティング・システムは、それぞれの実行可能なアプリケーション及び機能を使用することにより、ＦａａＳコンピューティング機能を実装することができる。一例では、開発者は、１つ以上のコンピュータ機能を表す機能コード（例えば、本願における「コンピュータ・コード」）を書き込み、機能コードは、例えば、エッジ・ノード又はデータ・センターによって提供されるＦａａＳプラットフォームにアップロードされる。例えば、サービスユース・ケース又はエッジ処理イベントのようなトリガは、ＦａａＳプラットフォームを使用して機能コードの実行を開始する。

【0165】

ＦａａＳの例では、機能コードが実行される環境を提供するために、コンテナが使用される。コンテナは、プロセス、ドッカー（Ｄｏｃｋｅｒ）又はクバネティス（Ｋｕｂｅｒｎｅｔｅｓ）のコンテナ、仮想マシンなどの、任意の孤立した実行エンティティであってよい。エッジ・コンピューティング・システム内では、様々なデータ・センター、エッジ、エンドポイント（モバイルを含む）デバイスが、要求に応じてスケーリングされる機能を「スピン・アップ」するために（機能アクションを活性化及び／又は割り当てるために）使用される。機能コードは物理インフラストラクチャ（例えば、エッジ・コンピューティング・ノード）デバイス及びその下にある仮想化コンテナにおいて実行される。最終的に、コンテナは、実行が完了したことに応じてインフラストラクチャにおいて「スピン・ダウン」される（非活性化される及び／又は割り当て解除される）。

【0166】

ＦａａＳの更なる態様は、エッジ・コンピューティング・アズ・ア・サービス（Ｅｄｇｅ－ａｓ－ａ－Ｓｅｒｖｉｃｅ又は「ＥａａＳ））をサポートする個々の機能のサポートを含むサービス形態でエッジ機能の配備を可能にすることができる。ＦａａＳの追加的な特徴は：顧客（例えば、コンピュータ・コード開発者）が、それらのコードが実行される場合に限って支払いを行うことを可能にする細分化された課金コンポーネント；１つ以上の機能による再利用のためにデータを格納する共通データ・ストレージ；個々の機能の間のオーケストレーション及び管理；機能実行管理、並列化、及び統合；コンテナ及び機能メモリ・スペースの管理；機能に利用可能な加速リソースの連携；及び、コンテナ間の機能の配分（コンテナは、既に配備され又は動作している「ウォーム（ｗａｒｍ）」コンテナ、それに対して、初期化、配備、又は設定を必要とする「コールド（ｃｏｌｄ）」コンテナを含む）を含むことが可能である。

【0167】

更なる構成では、オーケストレーションの態様は、「オーケストレーション・アズ・ア・サービス（ＯａａＳ）」展開のサービス態様により、エッジ・コンピューティング・システムにおいて実装され、エッジ・オーケストレーション及びマルチ・テナントの多くの態様の間で利害関係者の分散を可能にすることができる。一例において、エッジ・コンピューティング・システムのテナントは、ＳＬＡ作成プロセスの一部としてＯａａＳプロバイダを発見する（ブートストラップ機能、コンフィギュレーション・ウィザード、ストアフロントなどの一部として動作する）。この発見と利用をサポートするために必要な技術的能力は、製造者によって各デバイス内に焼き付けられてもよいし、テナントがエッジ・コンピューティング・システム内で選択及び利用する「オンボーディング」型の手順が各ＯａａＳとともに生じてもよい。更に、ＳＬＡ作成プロセスの間に、ＯａａＳプロバイダは、如何なるリソース、条件、又は特徴が、プールから利用可能なものに対して要求されているかを分離し、そして、リソースを利用するために、特定の特徴／機能に対する使用可能化／活性化又はサブスクリプションのための個別のサービス要求を作成することが可能である。

【0168】

ＯａａＳをサポートするために、様々なタイプのハードウェアの改良や構成がエッジ・コンピューティング・デバイス内で実装されることが可能である。例えば、ハードウェア機能は、ＯａａＳトラスト・アンカーを事前に提供してもよいし、ハードウェア製造者がＯａａＳの導入を仲介するための信頼できるクリアリング・ハウスとして機能することを可能にするために、情報を提供してもよい。本願で提案される他のタイプのソフトウェア及びサービスの改良及び構成もまた、ＯａａＳの特徴をサポートするためにエッジ・コンピューティング・システム内で実装されてもよい。

【0169】

Ｂ．作業負荷の分散及び管理
図１３は、オペレーショナル・ネットワーク・レイヤ間のエッジ・コンピューティングのための動作上の考察事項の比較を示す。具体的には、図１３は、異なるコンピューティング処理ロケーションの間で経験されるトレードオフの程度及びタイプを示す。近接デバイス・エッジ・クラウドのエッジ・ゲートウェイ１３２０（例えば、基地局、アクセス・ポイント）及びエッジ・キャビネット１３３０（例えば、ストリート又は路側キャビネット、オンプレミス・キャビネット）、セントラル・オフィス１３４０における集約のポイント、データ・センター１３５０における集約のポイント、又は、インターネット若しくはオーバー・ザ・トップ・サービス１３６０におけるクラウド・データ・センターの間のような、ネットワークの様々なレイヤ（例えば、図２のネットワーク・アクセス・レイヤ２２０及びコア・ネットワーク・レイヤ２３０の間に位置する装置の詳細）において、種々のサービス特性１３０２－１３１８は増加又は減少させられる。エッジ・エンドポイントに近づくように移動する場合、新たなユース・ケース１３０２（例えば、分散及びコンテキスト化ＡＩ、リアル・タイムＦａａＳ）の実施において増加が体験される可能性があり、短縮された待ち時間１３０４（例えば、短縮された応答時間、より速いユーザ体験）、増大されたスループット１３０６（例えば、連携した配分、負荷バランスなど）、オーナーシップ及びトラフィックの低減された総額コスト（例えば、改善されたエンドポイント又はエッジ・フィルタリング、キャッシングなどによるもの）となる。しかしながら、クラウド・データ・センターに近づくように移動するにつれて、セキュリティ１３１０（例えば、改善された隔離、データ保護によるもの）において改善が見受けられる可能性があり、物理的制約１３１２（例えば、電力、空間、セキュリティ、及び熱的な制約）の減少、管理保守１３１４の減少、有線及び無線インフラストラクチャ１３１６の再利用能力、及びより複雑なオーケストレーション１３１８となる。

【0170】

これらのトレードオフは、移動性の特性及び異なるタイプの通信ネットワークによって拡大される。図１４は、セルラー（移動）無線ネットワークにおける、動作ネットワーク・レイヤ間のエッジ・コンピューティングのための動作展開及び待ち時間を示す。具体的には、図１４は、例示的な国の配備においてそれぞれの移動ネットワーク・レイヤ１４２０－１４７０に生じるネットワーク待ち時間の例を示し、ローカル・レイヤ１４２０まで（例えば、典型的には、小セル基地局又はアクセス・ポイントまで１ｍｓ未満であり、それらは「ローカル」又は「クローズ・エッジ」レイヤと考えられてもよい）、オンプレミス・レイヤ１４３０まで（例えば、オンプレミス機器又はクラウドレット／エッジレットを有し、典型的にはこれも１ｍｓ未満でもあり、「エンタープライズ・エッジ」、「ローカル・エッジ」又は「クローズ・エッジ」レイヤと考えられてもよい）、基地局レイヤ１４４０まで（例えば、セル・タワー基地局又は他の無線ネットワーク・ゲートウェイを有し、典型的には１－５ｍｓの間にあり、それらは「ニア・エッジ」レイヤと考えられてもよい）、集約レイヤ１４５０まで（例えば、複数の集約サーバー又はロケーションを有し、典型的には１００キロメートル（ＫＭ）の距離ごとに典型的に１－２ｍｓを５ｍｓに追加した範囲内にあり、これらは「ミドル・エッジ」レイヤと考えられてもよい）、コア・ネットワーク・レイヤ１４６０まで（複数のコア・ネットワーク・サーバー又はロケーションを有し、現在使用されている電気通信技術に基づいて、典型的には４００ＫＭの距離ごとに５ｍｓを５ｍｓに追加した範囲内にあり、これらは「ファー・エッジ」レイヤと考えられてもよい）、及び、クラウド・レイヤ１４７０まで（例えば、１つ以上のクラウド処理ロケーションを有し、典型的には６０ｍｓを超えるもの）のラウンド・トリップ・タイミングの例を提供している。このような待ち時間は、例示の目的のためにのみ提供されており、関連する通信技術のタイプに応じて変わる可能性がある（但し、光の速度によって制限される）。エッジ・クラウド・システムの展開（例えば、エッジ・クラウド１１０の実装）は、レイヤ１４２０－１４５０に関連して後述される。

【0171】

エンド・ユーザによって使用される、又は近くのローカル・レイヤ１４２０を介してアクセス可能であるエンドポイント・デバイスは、「ファー・エッジ」デバイスと考えられてよい。このシナリオのデバイスは、最低の「待ち時間」を提供する可能性がある。しかしながら、ある時点で、ファー・エッジ・デバイスは、所定のタスクを実行するために必要とされる場合に、計算が制限されるか、又はパワーが効率的でなくなる可能性がある。例えば、ネットワーク・トラフィック負荷のある時点で、ＡＲ／ＶＲユース・ケースは、（デバイス自体のファー・エッジのみにおいて作業負荷を実行するよりも悪いパフォーマンスを提供するポイントに対してさえ）深刻な劣化を経験する。

【0172】

（エンタープライズ・エッジ・レイヤとして知られている場合もある）オンプレミス・レイヤ１４３０でのオンプレミス・コンピューティングは、低い待ち時間のネットワーク・エッジ・アーキテクチャの次の潜在的な階層である。オンプレミスは、一定量の計算（小さな形状因子のラックから複数のラックまで）をホストすることが可能なロケーション（典型的には、顧客施設内）を指す。このようなオンプレミス・コンピューティング・プラットフォームは、企業、クラウド・サービス・プロバイダ、又は通信サービス・プロバイダにより所有され運用されてもよい。

【0173】

（ニア又はクローズ・エッジ・レイヤとして知られている場合もある）基地局レイヤ１４４０内の基地局におけるコンピューティングは、複数のアンテナを集約することができ、多くの場合、通信サービス・プロバイダの観点から第１潜在エッジとしてホストされることが可能である。基地局は、５Ｇ無線トラフィックを処理するために、仮想無線アクセス・ネットワーク（例えば、ｖＲＡＮ）タイプの作業負荷を実行する可能性がある。基地局で他のサービスを実行するための主な設計上の課題は、（１）限られたスペース、（２）より多くのセキュリティ及びより良い熱的対応策を必要とする物理的な露出、（３）限られた電力量、（４）このように高度に分散されたコンピューティング環境を管理することから生じるオーナーシップの総額コスト（ＴＣＯ）又は運用経費（ＯＰＥＸ）に関連する。これまで、基地局でサービスを展開する際の課題を概説しているが、基地局はそれでもサブミリ秒の待ち時間を提供する可能性があるインフラストラクチャにおける固有のポイントの１つであることを強調しておくことは重要である。

【0174】

（距離及び待ち時間に応じて、ミドル・エッジ・レイヤ又はファー・エッジ・レイヤとして知られている場合もある）集約レイヤ１４５０内のセントラル・オフィス（ＣＯ）におけるコンピューティングは、ローカル・エリア内の複数の基地局の集約ポイントとして機能することが可能である。例えば、１つのＣＯは約３０の基地局からのトラフィックを集約することができる。この数は、国や人口密度によって変わる可能性がある。次いで、これらのセントラル・オフィスは、地域的な交換サイトに接続する前に、（例えば、光を含む有線のリンクによって）地域の拠点（ＰＯＰ）にリンクすることができる。ＣＯはまた、無線及び有線サービスを一緒にもたらすことが可能である。ＣＯに到達するまでの待ち時間は、多くのエッジ・ユースケース（例えば、電力、スペース、管理の容易さ）を満足し、それらをエッジ・サービスの配置に望ましい場所にすることができる。セントラル・オフィス又は交換サイトはまた、複数のセントラル・オフィス接続を集約することも可能である。

【0175】

図１５は、エッジ・コンピューティング・システム１５００のオペレーショナル・レイヤ（例えば、レイヤ１４２０－１４７０に対応するもの）に対する作業負荷の配備及びマッピングを示す。この構成内では、様々な連携が実行され、計算リソースを作業負荷データに持ち込み、作業負荷データを計算リソースに持ち込むので、エッジ・コンピューティング・システム１５００のデバイスの間で、作業負荷実行の位置及びタイプについて、複数の考察事項及び能力が評価される。考察事項は以下を含むことが可能である。

【0176】

（１）各々の場所の制約（例えば、電力、スペース、プラットフォームのセキュリティ）に応じて、（サービス及び作業負荷の適切なマッピングを実行することに加えて）短期及び長期の使用について、適切なプラットフォーム・アーキテクチャ、ラック設計、又はその他のハードウェア機能又は構成を選択すること。異なるオプションは、異なるアーキテクチャ構成にマッピングされてもよい。

【0177】

（２）ネットワーク又はサービス・オペレータから発生する如何なる要件がアーキテクチャを形成するのかを決定する。これは、（例えば、資本費用とそれに対する運営費用、形状因子、セキュリティ、及びＱｏＳのような）オペレータの要件を満たすプラットフォーム・アーキテクチャを示す可能性がある。

【0178】

（３）エッジ・コンピューティング・アーキテクチャを管理、監視、及び調整するための正しいソフトウェア・アーキテクチャを決定する。調整する適切なインターフェースがなければ、複雑な分散シナリオのクラウド・アーキテクチャは機能しないであろう。更に、適切な抽象化とインターフェースをサービスに対して明らかににし、その下のハードウェア・リソースにアクセスすることは、同程度に重要なことである。

【0179】

これら及び他の決定に基づいて、様々な作業負荷及びユース・ケース・モデル１５１０は、作業負荷マッピング定義１５２０に従って、まずエッジ・コンピューティング・システム１５００のロケーションの間にマッピングされてもよい。そのような作業負荷マッピング定義１５２０は、エッジ・コンピューティング・システム１５００の間に配備されることが可能なプラットフォーム要件及びアーキテクチャ要素１５３０（例えば、ストレージ又はラック・スケール設計技術１５３１、アクセラレーション１５３２、プラットフォーム１５３３、ファブリック又はネットワーク１５３４、ストレージ又はメモリ１５３５）を識別することが可能である。更に、作業負荷マッピング定義１５２０は、セキュリティ１５４１、物理的制約１５４２、管理１５４３、コスト（例えば、金銭、リソース、又は他の資産コスト）１５４４、インフラストラクチャ制限、及び能力１５４５などのような態様に対処する要件マッピング１５４０に基づいてもよい。

【0180】

更に、エッジ・コンピューティング・システム１５００のエンド・ツー・エンドの考察は、定義１５５０（例えば、顧客及び作業負荷の要件１５５１の定義、多層オーケストレーション要件１５５２の定義、基地局、セントラル・オフィス、及びデータ・センター・ロケーション１５５３、１５５４、１５５５の定義）、又は、Ｅ２Ｅ ＱｏＳ又はＳＬＡ構成１５５６の定義に規定されるように、リアル・タイム・オーケストレーション、サービス・レベル合意（ＳＬＡ）、及びＱｏＳ特性の評価を含んでもよい。これらの定義１５５０は、プラットフォーム要件及びアーキテクチャ要素１５３０を選択し、要件マッピング１５４０をランク付け又は優先順位付けし、最終的に作業負荷マッピング１５２０を変更するために使用されてもよい。これらの考察は、定義１５５０又は他の箇所に記載され、以下の特徴を反映する可能性がある。

【0181】

１）待ち時間。これは、エッジ・サービス・ロケーションにおいて重要な役割を果たす最初の重要なパフォーマンス・インジケータ（ＫＰＩ）を提供するために使用される。光の速度は約３００，０００ｋｍ／ｓであり、ワイヤでの伝送はその～２／３であるので、要求される応答待ち時間は、デバイスがエッジからどのくらい遠く離れているかを決定することになる。例えば、幾つかのサービスが４ｍｓ未満の応答待ち時間を必要とする場合、それらはデバイスから１５０ｋｍを超えることはできない。従って、一部の作業負荷（例えば、ＩｏＴデバイス・データ処理）に対して、固有のエッジ定義が基地局によってのみ使用されてもよい一方、他のものがセントラル・オフィスによって使用されてもよい。

【0182】

２）データ・プライバシー、支配権、機密性。これらはコンプライアンスを判断し、運用可能性を検証するために使用される。これらの考察事項は、一部のサービスがエッジの特定のロケーションにのみ存在できることを指示する可能性がある。例えば、ヘルスケア・セグメントにおいて、一部の病院は、エッジ・クラウド上の何らかのサービスではあるがインフラストラクチャの特定の境界（例えば、施設内の機器、セントラル・オフィスなど）を越えるデータを有しないものをホストして共有することを望むかもしれない。

【0183】

３）バックホール・トラフィックの削減。バックホール・トラフィック・データの節約は、ＯＰＥＸ／ＴＣＯを低減するためにネットワークの異なるエッジでトラフィックをフィルタリングすることによって達成されることが可能である（同様に、より小さな帯域幅のＣＡＰＥＸがバックホール・ネットワーク上で必要とされる可能性がある）。この場合、フィルタリングはインフラストラクチャの異なる潜在的なエッジのいずれかで起こる可能性がある。例えば、ビデオ監視は、コンテンツ配信ネットワークがセントラル・オフィスに配置され得る場合に、どの画像がクラウド又はセントラル・オフィスに送られるべきかを識別するために、基地局で処理されることが可能である。

【0184】

４）新しいエッジ処理ユース・ケースの有効化。例えば、生体認証を許容するエッジにおけるサービスである。或いは、信頼性要件が充足される限り、音声分析によりリアル・タイムに支払いが実行されるサービスである。

【0185】

５）リソース・レベルの信頼性の定義及び使用。これはプラットフォーム及びリソース間の能力に対するアクセスの認証を可能にする。

【0186】

特定のユース・ケース又は作業負荷の実際のエッジが存在する場所を定めることは、特定のロケーションそれに提供するＫＰＩ又はバリュー・プロポジションに直接的に関連する。例えば、オペレータ・インフラストラクチャのコアにおけるＩｏＴ又はＡＲ／ＶＲ作業負荷の実行のためにエッジ・コンピューティングを定めることは、待ち時間の観点からＫＰＩ要件を満たすには不可能であるかもしれない。従って、この作業負荷に対するエッジ・コンピューティングは、デバイスにより近い位置にある（基地局又はよりローカルなセントラル・オフィス、ニア又はミドル・レイヤにおけるものである）。一方、コンテンツ配信ネットワーク（ＣＤＮ）（「コンテンツ分配ネットワーク」又は「コンテンツ定義ネットワーク」としても知られる）の作業負荷のエッジ・コンピューティングは、基地局、セントラル・オフィス、又は、オペレータ・インフラストラクチャの何らかの他の中間集約ポイント（ＰＯＡ又はＰＯＰ）（ミドル又はファー・エンド・レイヤにおけるもの）に位置することができる。この場合、何が最も適切なエッジ・ロケーションであるかを定めるために、関連するＯＰＥＸ／ＴＣＯは、ＣＤＮ作業負荷を配置するために何が最良のロケーションであるかを導出することができる。

【0187】

更なる例では、エッジ・コンピューティング・システムにおいて、特定の形式のコンピューティング活動を特定の場所及びシステムにマッピングするために（又は、システム及びロケーション機能のタイプにマッピングするために、作業負荷データを、利用可能なコンピューティング・リソースに、より効率的に持ち込むために）、進歩した形式の作業負荷マッピングが使用されてもよい。図１６は、アクセス・ポイント又は小セル１６２０、ゲートウェイ又は基地局１６４０、及びセントラル・オフィス１６６０（各々が各自の能力を有する）を有するエッジ・コンピューティング・システムのサービス特徴への作業負荷タイプのマッピングを示す。

【0188】

小セル１６２０でのコンピューティングを使用することにより、ネットワーク機能１６１２及びサービス１６１４の組み合わせが提供され、サービス結果１６７２を生成するためのローカルな又は超低待ち時間サービス（例えば、拡張現実、ＩｏＴ、ＦａａＳ）の実行に重点が置かれる。基地局１６４０におけるコンピューティングを使用することにより、ネットワーク機能１６３２及びサービス１６３４の同様の組み合わせが提供されてもよく、基地局１６４０における利用可能なハードウェア処理リソースの量は、ネットワーク機能の量及び複雑さが増加するにつれて増加する。セントラル・オフィス１６６０（又は他の集約ロケーション）でのコンピューティングを使用することにより、アクセス・ポイント／小セル１６２０又はゲートウェイ／基地局１６４０で利用できない追加のコンピューティング・リソースを必要とするサービス１６５４（例えば、ビデオ分析、ストレージ、分析、ＦａａＳ）を補完する、より深いレイヤのネットワーク機能１６５２が提供され得る。

【0189】

エッジ・ロケーション１６２０、１６４０、１６６０及び同様なサブシステムに分散されるハードウェアの位置及びタイプの幾つかの考察事項は、以下を含む可能性がある：

【0190】

（１）作業負荷及びユース・ケースがマッピングされる場所。この決定は、本願で議論される様々な基準又は価値の提案を用いて実行されることが可能である。一旦マッピングが行われると、異なるユース・ケースや作業負荷は、基礎ブロック又は基本ブロックで破壊されることを必要とする。基本ブロックは、アルゴリズム論理ユニット（例えば、ディープ・ニューラル・ネットワーク又は高速フーリエ変換）によって定義されることが可能である。一旦、基本ブロックのマッピング及び分割がエッジの異なる階層で行われると、改善のための特定のブロックが所与の位置で識別される可能性がある。そのため、各自のリソース条件は、その特定の場所でどの程度多くのリソースが必要とされるのかを評価するために使用されることが可能である。

【0191】

（２）各ロケーションの特徴。上述したように、ロケーション（例えば基地局）それぞれは、物理的な要件（例えば、形状因子、電力、温度など）のリストだけでなく、多数の予想される加入者（例えば、基地局においては、その範囲は１－４Ｋの加入者である可能性がある）のリストを有する。物理的な要件は、どれだけ多くのリソースが所与の場所に配置され得るのかに変換され、加入者は、どれだけ多くの演算が特定の作業負荷マッピング及び加入者数に必要であるのかに変換される。従って、これら及び他の要因は、インフラストラクチャ・ロケーション（例えば、小セル、基地局、ＣＯ）でエッジ・コンピューティング処理リソースを配備する際に重要となる可能性がある。

【0192】

これら及びその他のエッジ・コンピューティングのシナリオに関連する設計ポイントは、特に、マルチ・テナント及びマルチ・ステークホルダーのユース・ケースにおいて、ネットワーキング・インフラストラクチャ・サービスが「飢える（ｓｔａｒｖｅ）」又は「失敗する（ｆａｉｌ）」はずはないこと、及び進行中のアプリケーションやサービスによって影響を受けされないまま残る必要があることである。ネットワーク・トラフィック及びネットワーク機能の作業負荷は、決定論的なまま残る必要があるかもしれず、そのため、エッジ・クラウド・アーキテクチャの設計は、ＶＮＦ及びネットワーク・サービスのような高い優先度のユース・ケースに焦点を当てることができる。

【0193】

図１７は、エッジ・コンピューティング・システムにおける実行プラットフォームに対する作業負荷タイプ・マッピングを示す。図示されるように、作業負荷タイプのセット１７１０（タイプ１７００、１７１１、１７１２、１７１３、１７１４として表される）は、作業負荷の最低の優先度及び待ち時間の要件を示すタイプ分類（例えば、ＩｏＴデータ処理に対するもの）から、中間のタイプ分類（例えば、ＡＩ作業負荷、ビデオ分析の作業負荷、ＡＲ／ＶＲ作業負荷）とともに、作業負荷の最高の優先度及び待ち時間の要件を示すタイプ分類（例えば、ネットワーク通信機能に対するもの）へ徐々に進行する。これらの作業負荷タイプ１７１０は、タイプ分類に従って、マルチ・ステークホルダー、マルチ・テナント・エッジ・システム内で調整されることが可能である。

【0194】

それぞれのタイプ分類は、オペレータ要件又は制約１７２２（利用可能なプラットフォーム数、形状因子、電力など）と比較して、特定の分類（例えば、パフォーマンス要件、機能要件）に対する作業負荷の要件１７２１を指定することが可能な一連の要件１７２０に関連付けられることが可能である。呼び出された作業負荷に対する要件１７２０の結果として、作業負荷の実行プラットフォーム１７３０の特定の構成に対して選択が行われてもよい。作業負荷の実行プラットフォーム１７３０の構成（例えば、ハードウェア１７３２、１７３４、１７３６から提供される構成１７３１、１７３３、１７３５）は、複数のエッジ・ノード（例えば、プラットフォーム１－Ｎ）の中から実行プラットフォームを識別することによって；設定可能なラック・スケール設計システム内で実行プラットフォームを再構成することによって；又は、１つ以上のプラットフォームからリソースをプーリング又は結合することを通じて実行プラットフォームを再構成することによって、選択されてもよい。

【0195】

作業負荷タイプのマッピングから提供される要件及び制約に加えて、他の尺度又はインジケータが、エッジ実行プラットフォームを選択又は設定するために使用されてもよい。例えば、特定の実行プラットフォームにおけるサービスのマッピングは：ＫＰＩパフォーマンスの利点又はユーザ体験の利点（例えば、３６０度のビデオに対して良好なユーザ体験を提供するために、どの程度の待ち時間が必要とされるのか）；ＯＰＥＸ／ＴＣＯ（例えば、特定の場所にサービスを提供することから導出されるものとそれに対して期待される収益化）；ＳＬＡ及びサービス・レベル目標（ＳＬＯ）の定義などを考慮することができる。これらの考慮は、分散されたエコシステム及び異なるハードウェアのロケーションの間で、潜在的に高い管理コスト（例えば、高い金銭的コスト又は高いリソース・コスト）を管理するためにオペレータの関心とのバランスを保つ。

【0196】

図１８は、エッジ・コンピューティング・システム１８００におけるエッジ・コンピューティング・ハードウェア構成の複数のレイヤの間で複数のテナントに対するサービスの動作を示す。エッジ・コンピューティング・システム１８００の種々のオペレーショナル・レイヤ（例えば、レイヤ１４２０－１４７０に対応するもの）において、ハードウェアの利用可能性及びプラットフォームの特徴の種々の組み合わせが明らかにされる。例えば、ローカル・レイヤ１４２０で動作する小セルは、限定された又は特化されていないプラットフォーム機能（ソフトウェア又はハードウェア機能）を有する限定されたハードウェア（例えば、低電力ＣＰＵ）を有するかもしれない。オンプレミス・レイヤ１４３０で動作するオンプレミス・クラウドレット／エッジレット／又は他のアプレット・マシンは、追加の又はより強力なハードウェアをホストし、ソフトウェア又はハードウェアの特徴（例えば、ＡＩアクセラレータ、ＦＰＧＡ、ＧＰＵ、暗号サービスなど）を提供することができる。基地局レイヤ１４４０は、更に多くのハードウェア能力（例えば、ハイ・パフォーマンスＣＰＵ又は特殊なコンピューティング・アーキテクチャ処理ユニット）又はより高度なプラットフォーム機能（高度なストレージ・メモリ）を有する可能性があり、ハードウェア及びプラットフォーム機能のより高度な組み合わせ（スマート・ネットワーキング・コンポーネントを含むもの）が、集約レイヤ１４５０及びコア・ネットワーク・レイヤ１４６０において提供されてもよい。

【0197】

システム１８００に示される様々な種類のハードウェア機能及び特徴は、複数のエッジのＦａａＳバリエーションを可能にすることができる。具体的には、特定のサービス又はサービス・プラットフォーム（「サービスＡ」）は、レイヤ１４２０－１４６０の何れかで使用又は実行するために仮想的に提供されてもよいが、レイヤ間のハードウェア及びソフトウェアの様々な組み合わせは、様々な処理結果又はアクションを可能にする。更に、ハードウェア及びソフトウェア（又は、そのようなハードウェア及びソフトウェアの能力）の様々な組み合わせは、特定のテナント又はユーザに基づいて、サービスの利用又は実行のために提供されることが可能である。この文脈では、サービスの実行／ランタイムは、ＬＳＭ又はその他のセキュリティ・ポリシー強化ポイントであるとすることが可能である。（同様に、この文脈では、物理的なパーティション分割又は仮想化を可能にするサービス・レイヤ及びプラットフォーム能力の下でのハードウェア抽象化レイヤは、ＬＳＭ及びその他のセキュリティ・ポリシー強化ポイントも提供することが可能である）。

【0198】

アプリケーションの観点からは、エッジ・ネットワーキング用に特別に設計されたアプリケーション（例えば、アプリケーションのコンポーネントがクラウド内で動作し、個々の処理コンポーネントは、階層的エッジに沿ったエッジ・クラウド内のエッジにある）が存在するかもしれない。従って、システム１８００に示されるアプローチは、例えば超低待ち時間ＦａａＳとそれに対するＦａａＳのようなＦａａＳの複数のバリエーションを、同一又は異なるアプリケーションの一部としてサポートしてもよい。

【0199】

図１９は、エッジ・クラウドの種々のレイヤ１４３０－１４５０及びそれを越えるもの（図４に関して上述した動作ネットワーク・レイヤの例を拡張するもの）に対するハードウェア・プラットフォーム１９０２－１９０８（及びプラットフォーム・タイプ１９０１－１９０９）のマッピングに基づいて、ネットワーク・レイヤにおける動作展開及び待ち時間に対するエッジ・コンピューティング・ハードウェア構成の更なるマッピングを示す。例えば、レイヤ１４３０において、低電力ＣＰＵと複数の特殊なアクセラレータ（ハードウェア１９０２）との組み合わせは、オンプレミス・サービス（例えば、ミリ秒未満の極端に低い待ち時間を必要とするクラウドレット／エッジレット／又は他のアプレット）の実行に適した第１プラットフォーム・タイプを提供することができる。レイヤ１４４０において、低電力ＣＰＵと特殊なアクセラレータ（ハードウェア１９０４）との類似の組み合わせは、複数のタイプのデバイス（例えば、５ｍｓ未満の低い待ち時間を必要とするもの）に対するサービスの低電力実行に適した第２プラットフォーム・タイプを提供することができる。ネットワークのより深いところでは、特殊なＧＰＵを有するサーバー・クラスＣＰＵとアクセラレータ（ハードウェア１９０６）又はストレージ（ハードウェア１９０８）との組み合わせが、集合レイヤ１４５０において提供されてもよい。最終的に、エッジ・クラウドを超えて、マルチ・コア・サーバーＣＰＵ及びストレージ（ハードウェア１９１０）は、コア・ネットワーク・レイヤ１４６０に設けられ、サーバー・クラス（クラウド）の処理を利用できるが、より高い待ち時間とのトレードオフがある。幾つかのシナリオにおいて、ハードウェア・プラットフォーム又は構成は、エッジ・クラウドの異なるレイヤにおけるスワップ可能な又は交換可能なハードウェア構成要素の利用を可能にする等のために、変更可能なプラットフォーム上で動作してもよいことが理解されるであろう。このように、サービス・プロバイダ又はハードウェア・システム・オペレータは、エッジ・システムの配備を、より新しい／より強力なハードウェア（又は、よりコスト効率の良いハードウェア）でアップグレードすることが可能である一方、必要なネットワーク待ち時間でエッジ作業負荷に応対することができる。

【0200】

図２０は、エッジ・コンピューティング・ハードウェア構成の動作展開に対するユース・ケース及び作業負荷の更なるマッピングを示す。具体的には、図２０は、エッジ・クラウドに関連する様々な作業負荷が、サービス・プロバイダによりどのように配備され得るかを示し、各々の作業負荷は異なる要件、アプリケーション、及びバリュー・プロポジションを有する。

【0201】

様々なタイプのユース・ケース及び作業負荷は、ハードウェア構成の選択又は再構成に基づいて、様々なプラットフォーム・タイプにマッピングされる可能性がある。例えば、フレキシブルなＮＦＶ作業負荷２０１０は、ＣＰＵ及びストレージ・リソースを提供する第１プラットフォーム・タイプにマッピングされてもよく；ビデオ処理又はビデオ分析／作業負荷２０２０は、低電力ＣＰＵ及び特殊ＧＰＵ及びＦＰＧＡ処理を提供する第２プラットフォーム・タイプにマッピングされてもよく；ＡＲ／ＶＲ及びゲーム作業負荷２０３０は、ＣＰＵ及びストレージ・リソースを提供する第３プラットフォーム・タイプにマップされてもよく；データ・キャッシュ及びストレージ・ゲートウェイ作業負荷２０４０は、低電力ＣＰＵ及びストレージ・リソースを提供する第４プラットフォーム・タイプにマップされてもよく；モノのインターネット処理２０５０は、低電力ＣＰＵ及びＡＩ加速リソースを提供する第５プラットフォーム・タイプにマップされてもよく；自律車両の作業負荷２０６０及びファンクション・アズ・ア・サービスの作業負荷２０７０は、ＣＰＵ、ストレージ、及び特殊なＧＰＵ処理リソースを提供する第６及び第７プラットフォーム・タイプにマッピングされてもよく；音声認識の作業負荷２０８０は、ＣＰＵ及びストレージ・リソース、及び特殊なＧＰＵ処理リソースを有する第Ｎプラットフォーム・タイプにマップされてもよい。

【0202】

従って、両方の計算リソースが作業負荷データにマッピングされ、作業負荷データ・インスタンスが計算リソースにマッピングされるので、異なるロケーションが、エッジ・クラウド１１０を横切ってサービス管理を実行するために使用することが可能である。高度に分散されたアーキテクチャでは、特徴は基地局上のマッピング・サービスに基づいている。この場合、電力及びスペースの点においてプラットフォームの物理的要件は、この特定のエッジ・ノードに配置されることが可能なハードウェアの量をほとんど制限する。更に、より多くのサービス密度を得るために、ハードウェア推論加速のような加速方式が利用されてもよい。セントラル・オフィス・アーキテクチャでは、アーキテクチャは、セントラル・オフィスの機能及びサービス・ロケーションに従って、分散性は少ないが、電力及びスペースの制約も少ない。この場合、より少ないスペース及び電力の制約で、アーキテクチャ上のソリューションは、ある程度のパフォーマンス又はサービス密度を犠牲にして、より均質にすることができる。

【0203】

初期の作業負荷マッピングは、作業負荷のライフサイクル中又はワークフローの構成における実行時のアクティビティには有効でない可能性があることが理解されるべきである。使用可能にされるべき追加的なサービスは、作業負荷評価・アズ・ア・サービスであり、これは、作業負荷の経時的な特徴付けに基づいて、作業負荷の評価と再割り当てを提供することができる。これに基づいて、以下の例で示唆されるように、作業負荷は、作業負荷のニーズをサポートするために、別のロケーション又は別のハードウェア又はシステム構成に移動させることが可能である。

【0204】

更なる例では、各種の配分、アップグレード、及び変更のアーキテクチャは、作業負荷及びエッジ・コンピューティングサービスを一般的に実装するために、ソフトウェア（及びファームウェア及びハードウェア機能）の更新をサポートするように実装されることが可能である。通常、コンピューティング・プラットフォームのベンダーは、配備されたプラットフォームに適用される機能の変更又はセキュリティ・パッチを作成する責任がある。ベンダーは、典型的には、他のサプライ・チェーン・エンティティが、ファームウェアのアップデートを開発すること、及び／又は他のエンティティがそれらを適用すること、を可能にすることはできない。このシナリオは、エッジ・コンピューティング環境にも適用可能であるが、分散コンピューティング環境は、新しいソフトウェア配分及びアップグレード・ダイナミクスを可能にすることができる。作業負荷が分析され、複数のプラットフォーム、即ち複数のアドミニストレータ及びベンダーにまたがるリソースの「スライス」又は「フレーバー（ｆｌａｖｏｒ）」に分散される場合、ユーザとオーケストレータがどのバージョンのソフトウェア／ファームウェアに対して十分な制御を有するかどうかが考慮される必要があるかもしれない。

【0205】

一例では、作業負荷は特定の設定及配備「フレーバー」で検証又はシミュレートされてもよく、この場合、シミュレーションの結果は、ファームウェア、ソフトウェア、及びその他の設定パラメータに完全に依存する可能性がある。場合によっては、ハードウェア、ファームウェア、ソフトウェアのセキュリティ脆弱性はまた、作業負荷の実行がどのように振る舞うのかを予測する。しかしながら、作業負荷の実行を検証及び／又はシミュレーションするために使用される環境が、それを実行する実際の環境と異なる場合、その差異は、追加的なリスクを表現する。

【0206】

ソフトウェア、ファームウェア、ハードウェアの機能アップデートを管理する方法として、リスクの差異を最小化するために、エッジ・コンピューティング・エコシステムは最適化されてもよい。作業負荷の配備に対する３つの段階的なアプローチ（１）－（３）を使用することが可能である：（１）実行環境の依存性を識別する作業負荷の検証環境をセットアップする。これは、作業負荷アプリケーションを処理するために、どのソフトウェア・モデルが必要とされるのかを考慮する。この依存性のグラフは、検証環境のセットアップの一部として識別される。更に、過剰な機能は、実行時のリスクを追加する増大した攻撃面を提示する。これらの非依存性は、検証環境から除去されることが可能である。（２）シミュレーションが、作業負荷を処理するために必要とされる実際の環境を作成する。これは、シミュレートされたハードウェア、仮想化、又はシミュレートされたパフォーマンス・シナリオの使用を含むことが可能である。作業負荷は、他の作業負荷、オーケストレーション、ユーザ、コラボレーションなどとの相互作用の予測とともに実行される。このシミュレーションは、オペレーショナル・コーナー・ケースが明らかにされることを確実にする。また、シミュレーションは、ハードウェア、ソフトウェア、及びファームウェアのどのバージョンが使用されるかを指定することもできる。これらは、期待される実際の行動をよりよく理解するための、実際のハードウェア、ソフトウェア、及びファームウェアのリソースである可能性がある。（３）シミュレーション環境が実世界の配備で再現される。ハードウェア、ソフトウェア、ファームウェアのバージョンは適切に調整される。おそらくは、これは、シミュレーションで定義された環境に従ってリソースを発見して割り当てるために、後方修正又は後方修正の過ぎ越しに移動することを意味する。これは、作業負荷で使用されないハードウェア、ソフトウェア、及びファームウェアの削除を含む可能性がある。

【0207】

Ｃ．ハードウェア・コンポーネント
図２１Ａは、エッジ・プラットフォーム２１１０の様々なアーキテクチャ態様（例えば、ハードウェア２１１１及び２１１２、ネットワーク機能２１１３、プラットフォーム加速機能２１１４、電力管理機能２１１５、メモリ２１１６、ストレージ２１１７などを計算すること）を、特定のエッジ・プラットフォーム能力２１２０（例えば、Ｉ／Ｏプーリング２１２１、加速プーリング２１２２、メモリ・プーリング２１２３、加速技術２１２４、ストレージ能力２１２５）にマッピングする第１エッジ・コンピューティング・ハードウェア構成を示す。サービスの全体的なソリューションとしてエッジ・クラウド構成を提供するために、サービス及びサービスの要件／制約（例えば、ネットワーク及びＩ／Ｏ、プラットフォームの加速、電力）に対する作業負荷又は基本ハードウェア・コンポーネントは、利用可能なアーキテクチャの態様（例えば、プーリング、ストレージなど）の観点から考慮される。

【0208】

エッジ・プラットフォーム能力２１２０内では、サービス密度がエッジ・クラウドにわたって満たされることを保証するために、特定の加速タイプが、複数の機能の中で設定又は識別されることが可能である。具体的には、（１）高速フーリエ変換（ＦＦＴ）、ｋ近傍法アルゴリズム（ＫＮＮ）、及び機械学習の作業負荷などの基本ブロックを実装するための一般的な加速（例：ＦＰＧＡ）、（２）画像、ビデオ、トランスコーディング・アクセラレータ、（３）推論アクセラレータ、（４）暗号化及び圧縮関連の作業負荷（Ｉｎｔｅｌ（登録商標）ＱｕｉｃｋＡｓｓｉｓｔ（登録商標）技術などで実装される）の４つのプライマリ加速タイプがエッジ・クラウド構成において配備されることが可能である。従って、エッジ・プラットフォーム能力２１２０の特定の設計又は構成（例えば、一般的な加速２１４１、推論加速２１４２、ストレージ２１４３）は、サービス及びスループット密度、並びに利用可能な電力を収容するために選択されることを必要とする適切なタイプの加速及びプラットフォーム製品モデルを考慮することができる。

【0209】

図２１Ｂは、第２エッジ・コンピューティング・ハードウェア構成を示し、第２セットのエッジ・プラットフォーム機能２１４０（例えば、機能２１４１、２１４２、２１４３を有する）とともに、第２エッジ・プラットフォーム２１３０（例えば、上記で示唆されるように、ハードウェア２１３１、２１３２、２１３３、２１３４、２１３５、２１３６、２１３７を有する）を提供し、低電力であるがサービス密度はより高いソリューションに関して配備可能である。このアプローチは、ワット当たりのより良いサービス密度又はサービス・スループットを達成するために加速方式を使用する、より低い電力のソリューションを定めることを目的としている。この主要な設計のトレードオフは、より良いパフォーマンス・パー・ワット比で同じ作業を実行することが可能な特殊なハードウェア（例えば、ＦＰＧＡ、推論アクセラレータ）を優先して、汎用的な計算の犠牲を利用するプラットフォームをもたらす。この例では、「サービス密度」ソリューションは、プラットフォームごと、及びワット当たりのより多くのサービス・アクションを可能にし、或いは、ワット当たりのサービス・レベルでのより多くのスループットをもたらすことができる。

【0210】

プラットフォーム機能２１４０は、電力包絡線の観点からも物理的スペースの観点からも有利であるように設計されることが可能である。結果として、図２１Ｂの構成は、（例えば、ニア又はミドル・エッジ・レイヤにおいて）基地局の配備に適したターゲットを提供することができる。しかしながら、プラットフォーム能力２１４０は：（１）オーケストレーション、メンテナンス、及びシステム管理に関する要件（これは、ＯＰＥＸ／ＴＣＯコストに変換されることが可能である）；（２）全てのシステム・スタックが、明らかにされる様々なアクセラレータと共に動作できるようにすることを、オペレータ・エコシステムに要求すること、を含むトレードオフを有する可能性がある。しかしながら、これらの欠点は、開発されるソフトウェア抽象化レイヤによって軽減される可能性がある。

【0211】

図２１Ｃは、第３エッジ・コンピューティングハードウェア構成を示し、第３エッジ・プラットフォーム２１５０（例えば、上記で示唆されるように、ハードウェア２１５１、２１５２、２１５３、２１５４、２１５５、２１５６、２１５７を有する）を提供し、エッジ・プラットフォーム機能２１６０の第３セット（例えば、機能２１６１、２１６２、２１６３を有する）は、高電力であるが均一であり且つ一般的なアーキテクチャを提供する。図２１Ｃは、オペレータ又はエッジ・オーナーが管理、保守、及び調整に関して処理しなければならない様々なタイプのリソースにおける減少した不均一性を、プラットフォーム・アーキテクチャに提供する、図２１Ｂとは逆のアプローチを提供する。しかしながら、均一性に有利なアクセラレータを除去することは、プラットフォーム・レベルでワット当たりのサービス密度及びサービス・スループットをより少なくすることを犠牲にして到来する。更なる例では、エッジ・プラットフォーム能力２１６０は、汎用加速（例えば、ＦＰＧＡの形態）を実装することができる。

【0212】

図２１Ａ－図２１Ｃに示されるエッジ・プラットフォームの他の派生機能もまた、適合される可能性がある。例えば、プラットフォームは新しい構成要素を組み込むためにサイズを決定し、設計することが可能であり、その構成要素は、サービス及びスループットをより密にするが、例えばオペレータがそれらをシームレスに管理できるように、例えばプラットフォーム内又はダイ上にアクセラレータを含めることにより、より均質に維持する。

【0213】

さらなる例において、本エッジコンピューティングシステム及び環境を参照して説明される計算ノード又は装置のいずれも、図２２Ａ及び２２Ｂに示すコンポーネントに基づいて満たされ得る。それぞれのエッジ計算ノードは、他のエッジ、ネットワーキング、又はエンドポイントコンポーネントと通信することが可能な、装置、機器、コンピュータ、又は他の“モノ”のタイプとして具現化され得る。例えば、エッジ計算装置は、スマートフォン、モバイル計算装置、スマート機器、車載計算システム（例えば、ナビゲーションシステム）、又は記載の機能を実行することができる他の装置若しくはシステムとして具現化され得る。

【0214】

図２２Ａに示す単純化した例において、エッジ計算ノード２２００は、計算エンジン（ここでは「計算回路」とも称する）２２０２、入力／出力（Ｉ／Ｏ）サブシステム２２０８、データストレージ２２１０、通信回路サブシステム２２１２、及びオプションで１つ以上の周辺装置２２１４を含んでいる。他の例において、それぞれの計算装置は、例えばコンピュータにおいて典型的に見られるもの（例えば、ディスプレイ、周辺装置など）などの、他の又は追加のコンポーネントを含み得る。さらに、一部の例では、図示したコンポーネントのうちの１つ以上が、別のコンポーネントに組み込まれたり、又は他の方法でその一部を形成したりすることができる。

【0215】

計算ノード２２００は、種々の計算機能を実行することができる任意のタイプのエンジン、デバイス、又は複数のデバイスの集合として具現化され得る。一部の例において、計算ノード２２００は、例えば集積回路、埋込みシステム、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、システム・オン・チップ（ＳＯＣ）、又は他の集積システム若しくはデバイスなどの、単一のデバイスとして具現化され得る。図示した例において、計算ノード２２００は、プロセッサ２２０４及びメモリ２２０６を含み、又はそれらとして具現化される。プロセッサ２２０４は、ここに記載される機能を実行（例えば、アプリケーションを実行）することが可能な任意のタイプのプロセッサとして具現化され得る。例えば、プロセッサ２２０４は、（１つ以上の）マルチコアプロセッサ、マイクロコントローラ、又は他のプロセッサ若しくはプロセッシング／制御回路として具現化され得る。一部の例において、プロセッサ２２０４は、ＦＰＧＡ、特定用途向け集積回路（ＡＳＩＣ）、再構成可能なハードウェア若しくはハードウェア回路、又はここに記載される機能の実行を容易にする他の特殊なハードウェアとして具現化され、それを含み、又はそれに結合され得る。

【0216】

メインメモリ２２０６は、ここに記載される機能を実行することが可能な任意のタイプの揮発性（例えば、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）など）又は不揮発性メモリ若しくはデータストレージとして具現化され得る。揮発性メモリは、その媒体によって保管されるデータの状態を維持するために電力を必要とする記憶媒体とし得る。揮発性メモリの非限定的な例は、例えばＤＲＡＭ又はスタティックランダムアクセスメモリ（ＳＲＡＭ）などの種々のタイプのランダムアクセスメモリ（ＲＡＭ）を含み得る。メモリモジュールにて使用され得るＤＲＡＭの１つの特定のタイプは、同期ダイナミックランダムアクセスメモリ（ＳＤＲＡＭ）である。

【0217】

一例において、メモリデバイスは、例えばＮＡＮＤ又はＮＯＲテクノロジに基づくものなどの、ブロックアドレス指定可能なメモリデバイスである。メモリデバイスはまた、三次元クロスポイントメモリデバイス（例えば、Ｉｎｔｅｌ（登録商標）３Ｄ ＸＰｏｉｎｔ（登録商標）メモリ）、又は他のバイトアドレス指定可能なライト・イン・プレース（write-in-place）不揮発性メモリデバイスを含み得る。メモリデバイスは、ダイそれ自体及び／又はパッケージングされたメモリプロダクトを指し得る。一部の例において、３Ｄクロスポイントメモリ（例えば、Ｉｎｔｅｌ（登録商標）３Ｄ ＸＰｏｉｎｔ（登録商標）メモリ）は、メモリセルがワードラインとビットラインとの交点に位置し、個々にアドレス指定可能であり、ビット記憶がバルク抵抗の変化に基づいた、トランジスタレスの、スタック可能な、クロスポイントアーキテクチャを有し得る。一部の例において、メインメモリ２２０６の全て又は一部がプロセッサ２２０４に集積されてもよい。メインメモリ２２０６は、例えば１つ以上のアプリケーション、該（１つ以上の）アプリケーションによって操作されるデータ、ライブラリ、及びドライバなど、動作中に使用される様々なソフトウェア及びデータを格納し得る。

【0218】

計算回路２２０２は、Ｉ／Ｏサブシステム２２０８を介して計算ノード２２００の他のコンポーネントに通信可能に結合され、Ｉ／Ｏサブシステム２２０８は、計算回路２２０２との（例えば、プロセッサ２２０４及び／又はメインメモリ２２０６）及び計算回路２２０２の他のコンポーネントとの入力／出力動作を容易にする回路及び／又はコンポーネントとして具現化され得る。例えば、Ｉ／Ｏサブシステム２２０８は、メモリコントローラハブ、入力／出力制御ハブ、集積センサハブ、ファームウェアデバイス、通信リンク（例えば、ポイントツーポイントリンク、バスリンク、ワイヤ、ケーブル、光ガイド、プリント回路基板トレースなど）、及び／又は入力／出力動作を支援する他のコンポーネント及びサブシステムとして具現化され、又はその他の方法でそれを含み得る。一部の例において、Ｉ／Ｏサブシステム２２０８は、システム・オン・チップ（ＳｏＣ）の一部を形成し、プロセッサ２２０４、メインメモリ２２０６、及び計算回路２２０２の他のコンポーネントのうちの１つ以上とともに、計算回路２２０２に組み込まれ得る。

【0219】

１つ以上の図示のデータストレージ装置２２１０は、例えば、メモリデバイス及び回路、メモリカード、ハードディスクドライブ、ソリッドステートドライブ、又は他のデータストレージ装置などの、データの短期間又は長期間の記憶のために構成された任意のタイプの装置として具現化され得る。個々のデータストレージ装置２２１０は、そのデータストレージ装置２２１０のためのデータ及びファームウェアコードを格納するシステムパーティションを含み得る。個々のデータストレージ装置２２１０はまた、例えば、計算ノード２２００のタイプに応じて、オペレーティングシステム用のデータファイル及び実行可能プログラムを格納する１つ以上のオペレーティングシステムパーティションを含み得る。

【0220】

通信回路２２１２は、計算回路２２０２と他の計算装置（例えば、エッジコンピューティングシステム３００のエッジゲートウェイノード３１２）との間でのネットワーク上の通信を可能にすることができる任意の通信回路、デバイス、又はそれらの集合として具現化され得る。通信回路２２１２は、そのような通信を達成するために１つ以上の通信テクノロジ（例えば、有線又は無線通信）及び関連するプロトコル（例えば、例えば３ＧＰＰ ４Ｇ若しくは５Ｇ標準などのセルラネットワーキングプロトコル、例えばＩＥＥＥ ８０２．１１／Ｗｉ－Ｆｉ（登録商標）などの無線ローカルエリアネットワークプロトコル、無線ワイドエリアネットワークプロトコル、Ｅｔｈｅｒｎｅｔ（登録商標）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、Ｂｌｕｅｔｏｏｔｈ Ｌｏｗ Ｅｎｅｒｇｙ、例えばＩＥＥＥ ８０２．１５．４若しくはＺｉｇＢｅｅ（登録商標）などのＩｏＴプロトコル、低電力ワイドエリアネットワーク（ＬＰＷＡＮ）、又は低電力ワイドエリア（ＬＰＷＡ）プロトコルなど）を使用し得る。

【0221】

図示した通信回路２２１２は、ホストファブリックインタフェース（host fabric interface；ＨＦＩ）とも称され得るものであるネットワークインタフェースコントローラ（ＮＩＣ）２２２０を含んでいる。ＮＩＣ２２２０は、他の計算装置（例えば、エッジゲートウェイノード３１２）と接続するために計算ノード２２００によって使用され得る１つ以上のアドインボード、ドーターカード、ネットワークインタフェースカード、コントローラチップ、チップセット、又は他の装置として具現化され得る。一部の例において、ＮＩＣ２２２０は、１つ以上のプロセッサを含むシステム・オン・チップ（ＳｏＣ）の一部として具現化され、又は１つ以上のプロセッサをやはり含むマルチチップパッケージ上に含められ得る。一部の例において、ＮＩＣ２２２０は、どちらもＮＩＣ２２２０に対してローカルであるローカルプロセッサ（図示せず）及び／又はローカルメモリ（図示せず）を含み得る。そのような例において、ＮＩＣ２２２０のローカルプロセッサは、ここに記載される計算回路２２０２の機能のうちの１つ以上を実行することが可能であるとし得る。加えて、あるいは代わりに、そのような例においてＮＩＣ２２２０のローカルメモリは、ボードレベル、ソケットレベル、チップレベル、及び／又は他のレベルで、クライアント計算ノードの１つ以上のコンポーネントに統合され得る。

【0222】

さらに、一部の例において、それぞれの計算ノード２２００は、１つ以上の周辺装置２２１４を含み得る。そのような周辺装置２２１４は、計算ノード２２００の具体的なタイプに応じて、例えばオーディオ入力装置、ディスプレイ、他の入力／出力装置、インタフェース装置、及び／又は他の周辺装置などの、計算装置又はサーバに見出される任意のタイプの周辺装置を含み得る。さらなる例において、計算ノード２２００は、エッジコンピューティングシステム（例えば、クライアント計算ノード３０２、エッジゲートウェイノード３１２、エッジ集約ノード３２２）におけるそれぞれのエッジ計算ノード、又は同様の形態の機器、コンピュータ、サブシステム、回路、又は他のコンポーネントによって具現化され得る。

【0223】

より詳細な一例において、図２２Ｂは、ここに記載される技術（例えば、動作、プロセス、メソッド、及び方法）を実装するためにエッジコンピューティングノード２２５０内に存在し得るコンポーネントの一例のブロック図を示している。このエッジコンピューティングノード２２５０は、コンピューティング装置（例えば、モバイル装置、基地局、サーバ、ゲートウェイなど）として又はその一部として実装されるときのノード２２００のそれぞれのコンポーネントのより綿密な図を提供している。エッジコンピューティングノード２２５０は、ここで参照されるハードウェア又は論理コンポーネントの任意の組み合わせを含むことができ、エッジ通信ネットワーク又はそのような複数のネットワークの組み合わせとともに使用可能な装置を含み又はそれと結合され得る。これらのコンポーネントは、エッジコンピューティングノード２２５０内で適応された、ＩＣ、その一部、ディスクリート電子デバイス、又は他のモジュール、命令セット、プログラマブルロジック若しくはアルゴリズム、ハードウェア、ハードウェアアクセラレータ、ソフトウェア、ファームウェア、又はそれらの組み合わせとして実装されることができ、あるいは、より大きいシステムのシャーシ内にその他の方法で組み込まれたコンポーネントとして実装され得る。

【0224】

エッジコンピューティング装置２２５０は、マイクロプロセッサ、マルチコアプロセッサ、マルチスレッドプロセッサ、超低電圧プロセッサ、埋め込みプロセッサ、又は他の既知のプロセッシング要素とし得るものであるプロセッサ２２５２の形態のプロセッシング回路を含み得る。プロセッサ２２５２は、プロセッサ２２５２及び他のコンポーネントが単一の集積回路又は単一のパッケージ（例えば、カリフォルニア州サンタクララのインテル社からのＥｄｉｓｏｎ（登録商標）又はＧａｌｉｌｅｏ（登録商標）ＳｏＣボードなど）へと形成されるシステム・オン・チップ（ＳｏＣ）の一部とし得る。例として、プロセッサ２２５２は、例えばＱｕａｒｋ（登録商標）、Ａｔｏｍ（登録商標）、ｉ３、ｉ５、ｉ７、ｉ９、又はＭＣＵクラスのプロセッサなどの、Ｉｎｔｅｌ（登録商標） Ａｒｃｈｉｔｅｃｔｕｒｅ Ｃｏｒｅ登録商標）系のＣＰＵプロセッサ、又はＩｎｔｅｌ（登録商標）から入手可能な他のそのようなプロセッサを含み得る。しかしながら、例えば、カリフォルニア州サニーベールのＡｄｖａｎｃｅｄ Ｍｉｃｒｏ Ｄｅｖｉｃｅｓ社（ＡＭＤ（登録商標））から入手可能なもの、カリフォルニア州サニーベールのＭＩＰＳ Ｔｅｃｈｎｏｌｏｇｉｅｓ社からのＭＩＰＳ（登録商標）ベースの設計、ＡＲＭ Ｈｏｌｄｉｎｇｓ社若しくはその顧客、又はそれらのライセンシーも若しくは採用者からライセンス許諾されたＡＲＭ（登録商標）系の設計など、幾つもの他のプロセッサも使用され得る。プロセッサは、例えばＡｐｐｌｅ（登録商標）社からのＡ５－Ａ１３プロセッサ、Ｑｕａｌｃｏｍｍ（登録商標） Ｔｅｃｈｎｏｌｏｇｉｅｓ社からのＳｎａｐｄｒａｇｏｎ（登録商標）プロセッサ、Ｔｅｘａｓ Ｉｎｓｔｒｕｍｅｎｔｓ社からのＯＭＡＰ（登録商標）プロセッサなどのユニットを含んでもよい。プロセッサ２２５２及び付随する回路は、図２２に示される全ての要素よりも少ない要素を含む限られたハードウェア構成又は構成にてを含め、単一ソケットのフォームファクタ、複数ソケットのフォームファクタ、又は多様な他のフォーマットにて提供され得る。

【0225】

プロセッサ２２５２は、インターコネクト２２５６（例えば、バス）上でシステムメモリ２２５４と通信し得る。所与の量のシステムメモリを提供するために、如何なる数のメモリデバイスが使用されてもよい。例として、メモリは、例えばＤＤＲ又はモバイルＤＤＲ規格（例えば、ＬＰＤＤＲ、ＬＰＤＤＲ２、ＬＰＤＤＲ３、若しくはＬＰＤＤＲ４）などの電子素子技術連合評議会（Joint Electron Devices Engineering Council；ＪＥＤＥＣ）設計に従ったランダムアクセスメモリ（ＲＡＭ）とし得る。特定の例において、メモリコンポーネントは、例えば、ＤＤＲ ＳＤＲＡＭに関するＪＥＳＤ７９Ｆ、ＤＤＲ２ ＳＤＲＡＭに関するＪＥＳＤ７９－２Ｆ、ＤＤＲ３ ＳＤＲＡＭに関するＪＥＳＤ７９－３Ｆ、ＤＤＲ４ ＳＤＲＡＭに関するＪＥＳＤ７９－４Ａ、低電力ＤＤＲ（ＬＰＤＤＲ）に関するＪＥＳＤ２０９、ＬＤＤＲ２に関するＪＥＳＤ２０９－２、ＬＤＤＲ３に関するＪＥＳＤ２０９－３、及びＬＤＤＲ４に関するＪＥＳＤ２０９－４などの、ＪＥＤＥＣによって公布されたＤＲＡＭ規格に準拠し得る。このような規格（及び同様の規格）は、ＤＤＲ系規格と称されることがあり、また、このような規格を実装する記憶装置の通信インタフェースは、ＤＤＲ系インタフェースと称されることがある。様々な実装において、個々のメモリデバイスは、例えばシングルダイパッケージ（ＳＤＰ）、デュアルダイパッケージ（ＤＤＰ）、又はクワッドダイパッケージ（ＱＤＰ）などの、幾つもの異なるパッケージタイプのものとし得る。これらのデバイスは、一部の例において、より低いプロファイルのソリューションを提供するようにマザーボード上に直接的にはんだ付けされ得る一方で、他の例において、これらのデバイスは、代わって所与のコネクタによってマザーボードに結合される１つ以上のメモリモジュールとして構成される。例えば、以下に限られないがマイクロＤＩＭＭ又はミニＤＩＭＭを含む様々な変バリエーションのデュアルインラインメモリモジュール（ＤＩＭＭ）といった、他のタイプのメモリモジュールなどの、幾つもの他のメモリ実装も使用され得る。

【0226】

例えばデータ、アプリケーション、オペレーティングシステムなどの情報の永続的な保管を提供するために、ストレージ２２５８も、インターコネクト２２５６を介してプロセッサ２２５２に結合され得る。一例において、ストレージ２２５８は、ソリッドステートディスクドライブ（ＳＳＤＤ）によって実装され得る。ストレージ２２５８に使用され得る他の装置は、例えばＳＤカード、マイクロＳＤカード、ＸＤピクチャカード、及びこれらに類するものなどのフラッシュメモリカード、並びにＵＳＢフラッシュドライブを含む。一例において、メモリデバイスは、カルコゲナイドガラスを使用するメモリデバイス、マルチスレッショルドレベルのＮＡＮＤフラッシュメモリ、ＮＯＲフラッシュメモリ、シングルレベル若しくはマルチレベル相変化メモリ（ＰＣＭ）、レジスティブメモリ、ナノワイヤメモリ、強誘電体トランジスタランダムアクセスメモリ（ＦｅＴＲＡＭ）、反強誘電体メモリ、メモリスタテクノロジを組み込んだ磁気抵抗ランダムアクセスメモリ（ＭＲＡＭ）、金属酸化物ベース、酸素空孔ベース及び導電ブリッジランダムアクセスメモリ（ＣＢ－ＲＡＭ）を含むレジスティブメモリ、又はスピントランスファトルク（ＳＴＴ）－ＭＲＡＭ、スピントロニクス磁気接合メモリベースのデバイス、磁気トンネル接合（ＭＴＪ）ベースのデバイス、ＤＷ（ドメインウォール）及びＳＯＴ（スピン軌道トランスファ）ベースのデバイス、サイリスタベースのメモリデバイス、又はこれらのいずれかの組み合わせ、又は他のメモリであるか、それを含むかであるとし得る。

【0227】

低電力実装では、ストレージ２２５８は、プロセッサ２２５２に付随するオンダイメモリ又はレジスタとし得る。しかしながら、一部の例において、ストレージ２２５８は、マイクロハードディスクドライブ（ＨＤＤ）を用いて実装されてもよい。また、上述のテクノロジに加えて、あるいは代えて、例えばとりわけ、抵抗変化メモリ、相変化メモリ、ホログラフィックメモリ、又は化学メモリなどの、幾つもの新しい技術もストレージ２２５８に使用され得る。

【0228】

これらのコンポーネントは、インターコネクト２２５６上で通信し得る。インターコネクト２２５６は、業界標準アーキテクチャ（ＩＳＡ）、エクステンデッドＩＳＡ（ＥＩＳＡ）、周辺コンポーネントインターコネクト（ＰＣＩ）、周辺コンポーネントインターコネクトエクステンデッド（ＰＣＩｘ）、ＰＣＩエクスプレス（ＰＣＩｅ）、又は幾つも他のテクノロジを含め、幾つものテクノロジを含み得る。インターコネクト２２５６は、例えばＳｏＣベースのシステムで使用される独自のバスであってもよい。例えばとりわけ、Ｉ２Ｃインタフェース、ＳＰＩインタフェース、ポイントツーポイントインタフェース、及びパワーバスなどの他のバスシステムが含められてもよい。

【0229】

インターコネクト２２５６は、接続されたエッジ装置２２６２との通信のために、プロセッサ２２５２をトランシーバ２２６６に結合し得る。トランシーバ２２６６は、例えばとりわけ、Ｂｌｕｅｔｏｏｔｈ（登録商標） Ｓｐｅｃｉａｌ Ｉｎｔｅｒｅｓｔ Ｇｒｏｕｐによって規定されたＢｌｕｅｔｏｏｔｈ（登録商標）ローエナジー（ＢＬＥ）規格又はＺｉｇＢｅｅ（登録商標）規格を用いた、ＩＥＥＥ ８０２．１５．４標準の下の２．４ギガヘルツ（ＧＨｚ）送信など、任意の数の周波数及びプロトコルを使用してもよい。特定の無線通信プロトコル用に構成された任意の数の無線機器が、接続されたエッジ装置２２６２への接続のために使用され得る。例えば、無線ローカルエリアネットワーク（ＷＬＡＮ）ユニットを使用して、電気電子技術者協会（ＩＥＥＥ）８０２．１１標準に従ったＷｉ－Ｆｉ（登録商標）通信を実装し得る。さらに、例えばセルラ又は他の無線広域プロトコルに従った、無線広域通信が、無線ワイドエリアネットワーク（ＷＷＡＮ）ユニットを介して行われ得る。

【0230】

無線ネットワークトランシーバ２２６６（又は複数のトランシーバ）は、異なるレンジでの通信のために、複数の規格又は無線機を使用して通信し得る。例えば、エッジコンピューティングノード２２５０は、例えば約１０メートル以内といった近い装置とは、電力を節約するために、ＢＬＥに基づくローカルトランシーバ又は他の低電力無線機を使用して通信し得る。例えば約５０メートル以内といった、もっと離れた接続エッジ装置２２６２は、ＺｉｇＢｅｅ（登録商標）又は他の中間電力無線機で到達され得る。両方の通信技術が、異なる電力レベルで単一の無線機上で行われてもよいし、例えばＢＬＥを使用するローカルトランシーバ及びＺｉｇＢｅｅ（登録商標）を使用する別個のメッシュトランシーバといった、別々のトランシーバ上で行われてもよい。

【0231】

無線ネットワークトランシーバ２２６６（例えば、無線トランシーバ）は、ローカル又はワイドエリアネットワークプロトコルを介してエッジクラウド２２９０内の装置又はサービスと通信するために含められてもよい。無線ネットワークトランシーバ２２６６は、とりわけＩＥＥＥ ８０２．１５．４又はＩＥＥＥ ８０２．１５．４ｇ標準に従うＬＰＷＡトランシーバとし得る。エッジコンピューティングノード２２５０は、Ｓｅｍｔｅｃｈ及びＬｏＲａのアライアンスによって開発されたＬｏｒａＷＡＮ（登録商標）（ロングレンジワイドエリアネットワーク）を使用して、広域で通信し得る。ここに記載される技術は、これらのテクノロジに限定されず、例えばＳｉｇｆｏｘなどの長距離の低帯域幅通信及び他のテクノロジを実装する任意の数の他のクラウドトランシーバと共に使用され得る。さらに、例えば、ＩＥＥＥ ８０２．１５．４ｅ仕様書に記載されているタイムスロット化チャネルホッピングなど、他の通信技術も使用され得る。

【0232】

ここに記載されるような、無線ネットワークトランシーバ２２６６に関して言及されるシステムに加えて、幾つもの他の無線通信及びプロトコルが使用されてもよい。例えば、トランシーバ２２６６は、高速通信を実装するためにスペクトラム拡散（ＳＰＡ／ＳＡＳ）通信を使用するセルラトランシーバを含み得る。さらに、例えば中速通信のため及びネットワーク通信の提供のためのＷｉ－Ｆｉ（登録商標）ネットワークなど、任意の数の他のプロトコルも使用され得る。トランシーバ２２６６は、本開示の最後でさらに詳細に説明するように、例えばロングタームエボリューション（ＬＴＥ）及び第５世代通信システムなど、任意の数の３ＧＰＰ（第３世代パートナーシッププロジェクト）仕様と互換性のある無線機を含み得る。エッジクラウド２２９０のノード又は例えば（メッシュ内で動作する）接続されたエッジ装置２２６２などの他のデバイスへの有線通信を提供するために、ネットワークインタフェースコントローラ（ＮＩＣ）２２６８が含められてもよい。有線通信は、イーサネット（登録商標）接続を提供してもよいし、あるいは、例えばとりわけ、コントローラエリアネットワーク（ＣＡＮ）、ローカルインターコネクトネットワーク（ＬＩＮ）、ＤｅｖｉｃｅＮｅｔ、ＣｏｎｔｒｏｌＮｅｔ、Ｄａｔａ Ｈｉｇｈｗａｙ＋、ＰＲＯＦＩＢＵＳ、又はＰＲＯＦＩＮＥＴなどの、他のタイプのネットワークに基づいてもよい。第２のネットワークに接続することを可能にするために、さらなるＮＩＣ２２６８が含められてもよく、例えば、第１のＮＩＣ２２６８が、イーサネット（登録商標）上でのクラウドへの通信を提供し、第２のＮＩＣ２２６８が、別のタイプのネットワーク上での他の装置への通信を提供する。

【0233】

装置から別のコンポーネント又はネットワークへの多様なタイプの適用可能な通信を所与として、装置によって使用される適用可能な通信回路は、コンポーネント２２６４、２２６６、２２６８、又は２２７０のうちの任意の１つ以上を含むことができ、又はそれによって具現化され得る。従って、様々な例において、通信する（例えば、受信する、送信するなど）ための適用可能な手段は、そのような通信回路によって具現化され得る。

【0234】

エッジコンピューティングノード２２５０は、１つ以上のＡＩアクセラレータ、ニューラルコンピュータスティック、神経形態学的ハードウェア、ＦＰＧＡ、ＧＰＵの配置、１つ以上のＳｏＣ、１つ以上のＣＰＵ、１つ以上のデジタル信号プロセッサ、専用ＡＳＩＣ、又は１つ以上の特殊なタスクを達成するように設計された他の形態の特殊化されたプロセッサ若しくは回路によって具現化され得るものである加速回路２２６４を含み、又はそれに結合され得る。それらのタスクは、ＡＩ処理（機械学習、訓練、推論、及び分類処理を含む）、ビジュアルデータ処理、ネットワークデータ処理、オブジェクト検出、ルール分析、又はこれらに類するものを含み得る。

【0235】

インターコネクト２２５６は、さらなる装置又はサブシステムを接続するために使用されるセンサハブ又は外部インタフェース２２７０にプロセッサ２２５２を結合してもよい。装置は、例えば加速度計、レベルセンサ、フローセンサ、光学光センサ、カメラセンサ、温度センサ、グローバルナビゲーションシステム（例えば、ＧＰＳ）センサ、圧力センサ、気圧センサ、及びこれらに類するものなどのセンサ２２７２を含み得る。ハブ又はインタフェース２２７０は更に、例えば電力スイッチ、バルブアクチュエータ、可聴音発生器、視覚的警告装置、及びこれらに類するものなどのアクチュエータ２２７４にエッジコンピューティングノード２２５０を接続するために使用されてもよい。

【0236】

一部のオプション例において、様々な入力／出力（Ｉ／Ｏ）装置が、エッジコンピューティングノード２２５０内に存在し、又はそれに接続され得る。例えば、センサ読み取り又はアクチュエータ位置などの情報を示すために、ディスプレイ又は他の出力装置２２８４が含められ得る。入力を受け付けるために、例えばタッチスクリーン又はキーパッドなどの入力装置２２８６が含められ得る。出力装置２２８４は、エッジコンピューティングノード２２５０の動作から生成又は生成される文字、グラフィックス、マルチメディアオブジェクト、及びこれらに類するものなどの出力を伴う、例えば二値のステータスインジケータ（例えば、ＬＥＤ）及びマルチキャラクタビジュアル出力などの単純なビジュアル出力、又は例えばディスプレイスクリーン（例えば、ＬＣＤスクリーン）などのいっそう複雑な出力を含め、幾つもの形態のオーディオ又はビジュアルディスプレイを含み得る。本システムのコンテキストでは、ディスプレイ又はコンソールハードウェアを使用して、エッジコンピューティングシステムの出力の提供及び入力の受信を行ったり、エッジコンピューティングシステムのコンポーネント又はサービスを管理したり、エッジコンピューティングコンポーネント又はサービスの状態を識別したり、幾つもの他の管理若しくは統治機能又はサービスユースケースを実行したりすることができる。

【0237】

バッテリ２２７６がエッジコンピューティングノード２２５０に電力供給し得るが、エッジコンピューティングノード２２５０が固定位置に取り付けられる例では、エッジコンピューティングノード２２５０は、配電網に結合された電源を有することができ、又はバッテリは、バックアップ又は一時的な能力として使用されてもよい。バッテリ２２７６は、リチウムイオン電池、又は例えば亜鉛空気電池、アルミニウム空気電池、リチウム空気電池、及びこれらに類するものなどの金属空気電池とし得る。

【0238】

バッテリ２２７６が含まれる場合、バッテリ２２７６の充電状態（state of charge；ＳｏＣｈ）を追跡するために、バッテリモニタ／充電器２２７８がエッジコンピューティングノード２２５０に含められ得る。バッテリモニタ／充電器２２７８は、故障予測を提供するために、バッテリ２２７６の例えば健康状態（state of health；ＳｏＨ）及び機能状態（state of function；ＳｏＦ）など、バッテリ２２７６の他のパラメータをモニタするために使用されてもよい。バッテリモニタ／充電器２２７８は、例えば、Ｌｉｎｅａｒ Ｔｅｃｈｎｏｌｏｇｉｅｓ社からのＬＴＣ４０２０若しくはＬＴＣ２９９０、アリゾナ州フェニックスのＯＮ Ｓｅｍｉｃｏｎｄｕｃｔｏｒ社からのＡＤＴ７４８８Ａ、又はテキサス州ダラスのＴｅｘａｓ Ｉｎｓｔｒｕｍｅｎｔｓ社からのＵＣＤ９０ｘｘｘファミリーからのＩＣなどの、バッテリモニタリング集積回路を含み得る。バッテリモニタ／充電器２２７８は、バッテリ２２７６についての情報を、インターコネクト２２５６上でプロセッサ２２５２に通信し得る。バッテリモニタ／充電器２２７８はまた、プロセッサ２２５２がバッテリ２２７６の電圧又はバッテリ２２７６からの電流フローを直接モニタすることを可能にするアナログ－デジタル変換器（ＡＤＣ）を含み得る。バッテリパラメータは、例えば送信周波数、メッシュネットワーク動作、センシング周波数、及びこれらに類するものなど、エッジコンピューティングノード２２５０が実行し得るアクションを決定するために使用され得る。

【0239】

電力ブロック２２８０、又は送電網に結合された他の電源が、バッテリモニタ／充電器２２７８に結合されて、バッテリ２２７６を充電し得る。一部の例において、電力ブロック２２８０は、例えばエッジコンピューティングノード２２５０内のループアンテナを介して、ワイヤレスで電力を得るために、ワイヤレス電力レシーバで置き換えられてもよい。とりわけ、例えばカリフォルニア州ミルピタスのＬｉｎｅａｒ Ｔｅｃｈｎｏｌｏｇｉｅｓ社からのＬＴＣ４０２０チップなどのワイヤレスバッテリ充電回路が、バッテリモニタ／充電器２２７８に含められ得る。バッテリ２２７６のサイズ及びそれ故に必要な電流に基づいて、具体的な充電回路が選択され得る。充電は、とりわけ、Ａｉｒｆｕｅｌ Ａｌｌｉａｎｃｅによって公布されたＡｉｒｆｕｅｌ規格、Ｗｉｒｅｌｅｓｓ Ｐｏｗｅｒ Ｃｏｎｓｏｒｔｉｕｍによって公布されたＱｉワイヤレス充電規格、又はＡｌｌｉａｎｃｅ ｆｏｒ Ｗｉｒｅｌｅｓｓ Ｐｏｗｅｒによって公布されたＲｅｚｅｎｃｅ充電規格を使用して実行され得る。

【0240】

ストレージ２２５８は、ここに記載される技術を実装するためのソフトウェア、ファームウェア、又はハードウェアコマンドの形態の命令２２８２を含み得る。そのような命令２２８２は、メモリ２２５４及びストレージ２２５８に含まれるコードブロックとして示されているが、理解され得ることには、これらのコードブロックはいずれも、例えば特定用途向け集積回路（ＡＳＩＣ）に組み込まれて、ハードワイヤード回路で置き換えられてもよい。

【0241】

一例において、メモリ２２５４、ストレージ２２５８、又はプロセッサ２２５２を介して提供される命令２２８２は、エッジコンピューティングノード２２５０における電子的処理を実行するようにプロセッサ２２５２に指示するコードを含んだ非一時的な機械読み取り可能媒体２２６０として具現化されてもよい。プロセッサ２２５２は、インターコネクト２２５６上で、非一時的な機械読み取り可能媒体２２６０にアクセスし得る。例えば、非一時的な機械読み取り可能媒体２２６０は、ストレージ２２５８に関して記載された装置によって具現化されてもよいし、例えば光ディスク、フラッシュドライブ、又は幾つもある他のハードウェア装置などの特定のストレージユニットを含んでもよい。非一時的な機械読み取り可能媒体２２６０は、例えば、上述の動作及び機能の（１つ以上の）フローチャート及び（１つ以上の）ブロック図に関して説明されるように、特定のアクションのシーケンス又はフローを実行するようにプロセッサ２２５２に指示する命令を含み得る。ここで使用されるとき、用語「機械読み取り可能媒体」及び「コンピュータ読み取り可能媒体」は相互に入れ換え可能である。

【0242】

さらなる例において、機械読み取り可能媒体はまた、機械による実行のために命令を格納、エンコード、若しくは担持することができて、本開示の方法のうちのいずれか１つ以上を機械に実行させる有形媒体、又はそのような命令によって利用される若しくはそのような命令に関連付けられたデータ構造を格納、エンコード、又は担持することができる有形媒体を含む。従って、「機械読み取り可能媒体」は、以下に限られないが、ソリッドステートメモリ、並びに光学及び磁気媒体を含み得る。機械読み取り可能媒体の具体的な例は、以下に限られないが、半導体メモリデバイス（例えば、電気的プログラム可能読み出し専用メモリ（ＥＰＲＯＭ）、電気的消去可能プログラム可能読み出し専用メモリ（ＥＥＰＲＯＭ）及びフラッシュメモリデバイス）、例えば内蔵ハードディスク及び取り外し可能ディスクなどの磁気ディスク、光磁気ディスク、並びにＣＤ－ＲＯＭ及びＤＶＤ－ＲＯＭディスクを含む不揮発性メモリを含む。機械読み取り可能媒体によって具現化される命令は更に、多数の転送プロトコル（例えば、ＨＴＴＰ）のうちのいずれか１つを利用するネットワークインタフェース装置を介して、伝送媒体を使用する通信ネットワーク上で送信又は受信され得る。

【0243】

機械読み取り可能媒体は、非一時的なフォーマットでデータをホストすることが可能な記憶装置又は他の装置によって提供され得る。一例において、機械読み取り可能媒体上で記憶され又は他の方法で提供される情報は、例えば命令それ自体又は命令がそこから導出され得るフォーマットなどの命令を表し得る。命令が導出され得るこのフォーマットは、ソースコード、符号化された命令（例えば、圧縮又は暗号化された形式にある）、パッケージ化された命令（例えば、複数のパッケージに分割される）、又はこれらに類するものを含み得る。機械読み取り可能媒体内の命令を表す情報は、ここで説明される動作のいずれかを実装するための命令へと、プロセッシング回路によって処理され得る。例えば、情報から命令を導出すること（例えば、プロセッシング回路によって処理すること）は、情報を命令へと、（例えば、ソースコード、オブジェクトコードなどから）コンパイルすること、解釈すること、ロードすること、編成すること（例えば、動的又は静的にリンク付けること）、符号化すること、復号すること、暗号化すること、解読すること、パッケージ化すること、脱パッケージ化すること、又はその他の方法で操作することを含み得る。

【0244】

一例において、命令の導出は、機械読み取り可能媒体によって提供される何らかの中間フォーマット又は前処理されたフォーマットから命令を生成するための、情報のアセンブリ、コンパイル、又は解釈（例えば、プロセッシング回路による）を含み得る。情報は、複数の部分で提供される場合に、命令を作成するために結合され、解凍され、及び変更され得る。例えば、情報は、１つ又は幾つかのリモートサーバ上の複数の圧縮されたソースコードパッケージ（又はオブジェクトコード、又はバイナリ実行可能コードなど）であることがある。ソースコードパッケージは、ネットワーク上での輸送時に暗号化され、ローカルマシンにて必要に応じて、解読され、解凍され、組み立てられ（例えば、リンク付けられ）、そして、コンパイル又は解釈され（例えば、ライブラリ、スタンドアロン実行ファイルプログラムなどに）、そして、ローカルマシンによって実行される。

【0245】

図２２Ｃは、一例のモバイル装置２２３２内の通信コンポーネントのブロック図である。このモバイル装置２２３２は、ユーザ機器又はユーザ機器のコンポーネントとして実装される場合のノード２２００又は装置２２５０の通信処理コンポーネントのより綿密な図を提供している。モバイル装置２２３２は、無線フロントエンドモジュール（ＦＥＭ）回路２２３４、無線ＩＣ回路２２３６、及びベースバンド処理回路２２３８を含み得る。図示のモバイル装置２２３２は、無線ローカルエリアネットワーク（ＷＬＡＮ）機能及びＢｌｕｅｔｏｏｔｈ（登録商標）機能の両方を含んでいるが、装置の態様はそのように限定されるものではなく、ここで説明される他の無線テクノロジが同様の回路によって実装されてもよい。ＦＥＭ回路２２３４は、例えば、無線ＬＡＮ又はＷｉ－Ｆｉ ＦＥＭ回路２２３４Ａと、Ｂｌｕｅｔｏｏｔｈ（ＢＴ） ＦＥＭ回路２２３４Ｂとを含み得る。ＷＬＡＮ ＦＥＭ回路２２３４Ａは、１つ以上のアンテナ２２３１Ａから受信したＷＬＡＮ ＲＦ信号に対して動作し、受信信号を増幅し、そして、受信信号を増幅したものを更なる処理のためにＷＬＡＮ無線ＩＣ回路２２３６Ａに提供する、ように構成された回路を有する受信信号パスを含み得る。ＢＴ ＦＥＭ回路２２３４Ｂは、１つ以上のアンテナ２２３１Ｂから受信したＢＴ ＲＦ信号に対して動作し、受信信号を増幅し、そして、受信信号を増幅したものを更なる処理のためにＢＴ無線ＩＣ回路２２３６Ｂに提供するように構成された回路を含み得る受信信号パスを含み得る。ＦＥＭ回路２２３４Ａはまた、無線ＩＣ回路２２３６Ａによって提供されるＷＬＡＮ信号を、アンテナ２２３１Ａのうちの１つ以上による無線送信のために増幅するように構成された回路を含み得る送信信号パスを含むことができる。加えて、ＦＥＭ回路２２３４Ｂも、無線ＩＣ回路２２３６Ｂによって提供されるＢＴ信号を、１つ以上のアンテナ２２３１Ｂによる無線送信のために増幅するように構成された回路を含み得る送信信号パスを含むことができる。図２２Ｃの例ではＦＥＭ２２３４Ａ及びＦＥＭ２２３４Ｂが互いに別のものであるように示されているが、本開示の態様は、そのように限定されるものではなく、それらの範囲内に、ＷＬＡＮ信号及びＢＴ信号の双方用の送信パス及び／又は受信パスを含むＦＥＭ（図示せず）の使用、又はこれらのＦＥＭ回路の少なくとも一部がＷＬＡＮ信号及びＢＴ信号の双方用の送信及び／又は受信信号パスを共有する１つ以上のＦＥＭ回路の使用を含む。

【0246】

図示の無線ＩＣ回路２２３６は、ＷＬＡＮ無線ＩＣ回路２２３６Ａ及びＢＴ無線ＩＣ回路２２３６Ｂを含み得る。ＷＬＡＮ無線ＩＣ回路２２３６Ａは、ＦＥＭ回路２２３４Ａから受信したＷＬＡＮ ＲＦ信号をダウンコンバートし、ベースバンド信号をＷＬＡＮベースバンド処理回路２２３８Ａに提供する回路を含み得る受信信号パスを含むことができる。代わって、ＢＴ無線ＩＣ回路２２３６Ｂは、ＦＥＭ回路２２３４Ｂから受信したＢＴ ＲＦ信号をダウンコンバートし、ベースバンド信号をＢＴベースバンド処理回路２２３８Ｂに提供する回路を含み得る受信信号パスを含むことができる。ＷＬＡＮ無線ＩＣ回路２２３６Ａはまた、ＷＬＡＮベースバンド処理回路２２３８Ａによって提供されるＷＬＡＮベースバンド信号をアップコンバートし、ＷＬＡＮ ＲＦ出力信号を、１つ以上のアンテナ２２３１Ａによるその後の無線送信のためにＦＥＭ回路２２３４Ａに提供する回路を含み得る送信信号パスを含むことができる。ＢＴ無線ＩＣ回路２２３６Ｂも、ＢＴベースバンド処理回路２２３８Ｂによって提供されるＢＴベースバンド信号をアップコンバートし、ＢＴ ＲＦ出力信号を、１つ以上のアンテナ２２３１Ｂによるその後の無線送信のためにＦＥＭ回路２２３４Ｂに提供する回路を含み得る送信信号パスを含むことができる。図２２Ｃの例では無線ＩＣ回路２２３６Ａ及び２２３６Ｂが互いに別のものであるように示されているが、本開示の態様は、そのように限定されるものではなく、それらの範囲内に、ＷＬＡＮ信号及びＢＴ信号の双方用の送信信号パス及び／又は受信信号パスを含む無線ＩＣ回路（図示せず）の使用、又はこれらの無線ＩＣ回路の少なくとも一部がＷＬＡＮ信号及びＢＴ信号の双方用の送信及び／又は受信信号パスを共有する１つ以上の無線ＩＣ回路の使用を含む。

【0247】

ベースバンド処理回路２２３８は、ＷＬＡＮベースバンド処理回路２２３８Ａ及びＢＴベースバンド処理回路２２３８Ｂを含み得る。ＷＬＡＮベースバンド処理回路２２３８Ａは、例えば、ＷＬＡＮベースバンド処理回路２２３８Ａの高速フーリエ変換又は逆高速フーリエ変換ブロック（図示せず）における一組のＲＡＭアレイなどのメモリを含み得る。ＷＬＡＮベースバンド回路２２３８Ａ及びＢＴベースバンド回路２２３８Ｂの各々は更に、無線ＩＣ回路２２３６の対応するＷＬＡＮ又はＢＴ受信信号パスから受信した信号を処理するとともに、無線ＩＣ回路２２３６の送信信号パスに対する対応するＷＬＡＮ又はＢＴベースバンド信号を生成するための、１つ以上のプロセッサ及び制御ロジックを含み得る。ベースバンド処理回路２２３８Ａ及び２２３８Ｂの各々は更に、物理層（ＰＨＹ）及びメディアアクセス制御層（ＭＡＣ）回路を含み得るとともに、ベースバンド信号の生成及び処理のため、並びに無線ＩＣ回路２２３６の動作を制御するために、アプリケーションプロセッサ２２５１（又は、他の例では、プロセッサ回路２２５０）とインタフェースを取り得る。

【0248】

なおも図２２Ｃを参照するに、図示した態様によれば、ＷＬＡＮ－ＢＴ共存回路２２４３が、ＷＬＡＮとＢＴとの共存を必要とするユースケースを可能にするためにＷＬＡＮベースバンド回路２２３８ＡとＢＴベースバンド回路２２３８Ｂとの間のインタフェースを提供するロジックを含み得る。さらに、アプリケーションニーズに従ってＷＬＡＮ無線とＢＴ無線との間で切り換わることを可能にするために、ＷＬＡＮ ＦＥＭ回路２２３４ＡとＢＴ ＦＥＭ回路２２３４Ｂとの間に、スイッチ２２３３が設けられ得る。また、アンテナ２２３１Ａ、２２３１Ｂが、それぞれ、ＷＬＡＮ ＦＥＭ回路２２３４Ａ及びＢＴ ＦＥＭ回路２２３４Ｂに接続されているように示されているが、本開示の態様は、その範囲内に、ＷＬＡＮ ＦＥＭとＢＴ ＦＥＭとの間で１つ以上のアンテナを共有すること、又は、ＦＥＭ２２３４Ａ又は２２３４Ｂの各々に接続された２つ以上のアンテナを設けることを含む。

【0249】

本開示の一部の態様において、フロントエンドモジュール回路２２３４、無線ＩＣ回路２２３６、及びベースバンド処理回路２２３８は、単一の無線カード上に設けられ得る。他の態様では、１つ以上のアンテナ２２３１Ａ、２２３１Ｂ、ＦＥＭ回路２２３４、及び無線ＩＣ回路２２３６が、単一の無線カード上に設けられてもよい。本開示の一部の他の態様では、無線ＩＣ回路２２３６及びベースバンド処理回路２２３８が、単一のチップ又は集積回路（ＩＣ）上に設けられ得る。

【0250】

より更なる例において、コンピューティングノードの計算能力は、計算機能を備えるように実装されるデータストレージソリューションを指すものである計算ストレージ、すなわち、「コンピュート・イン・ストレージ」で実装されてもよい。様々な例において、コンピュート・イン・ストレージは、ブロックストレージ装置におけるコンピュートオフローディングとして、オブジェクトベースのストレージ装置におけるコンピュートオフローディングを使用して、分散ストレージシステムにおけるコンピュートオフローディングを使用して、又は非集約的な複数のストレージ環境の間で提供されるコンピュートオフローディングを使用して実装され得る。一例のコンピュート・イン・ストレージシステムは、各ストレージ装置が不揮発性メモリ及びコンピュートオフロードコントローラを有する１つ以上のストレージ装置から提供され得る。このシステムでは、不揮発性メモリがデータを格納し、コンピュートオフロードコントローラが、ホストプロセッサからのコンピュートオフロードコマンドに基づいて、データに対する計算タスクを実行する。数ある例の中でもとりわけ、加速能力及び機能がそのようなコンピュート・イン・ストレージ構成の使用を備え得る。

【0251】

図２２Ｄは、エッジプラットフォームアーキテクチャにおけるサーバ又は他のディスクリート計算ノードの一部に含められ得るラックスケール設計（Rack Scale Design；ＲＳＤ）コンポーネントを例示している。この構成は、サーバとして（例えば、サーバラック、ブレードなどにて）実装される場合のノード２２００又は装置２２５０の構成可能（コンフィギュラブル）な処理コンポーネントのより綿密な図を提供している。このコンフィギュラブルアーキテクチャは、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、不揮発性メモリエクスプレス（ＮＶＭｅ）、及び入力－出力（Ｉ／Ｏ）プーリングリソースを集約しないことによって、他のものとは異なる。ＦＰＧＡ及びＮＶＭｅリソースは、例えば映像分析及び音声分析などの、任意のタイプのエッジサービスに使用され得る要素を提供する。Ｉ／Ｏプーリングは、柔軟なネットワーク機能を提供するために使用され得る。このアーキテクチャは、特定の仮想ネットワーク機能（ＶＮＦ）に対して期待されるデータレート又はネットワーク負荷に従ってネットワークインタフェースをスケーリングすることを可能にする。このアーキテクチャはまた、所与のノードで起こるネットワーク処理のタイプに応じて様々なネットワークカードを計算ノードにマッピングするための柔軟性を可能にする。

【0252】

図示したＲＳＤアーキテクチャは、ポイント・オブ・デリバリー（ＰＯＤ）マネジャ２２４２を含んでいる。ＰＯＤマネジャ２２４２は、ＰＯＤ（例えば、１つ以上のラック）内のリソース（計算及び非集約リソースを含む）を管理することを担う。ＰＯＤマネジャ２２４２は、構成されたノードを生成、管理、又は破壊するために、オーケストレータにインタフェースを公開する。構成されたノードを管理することは、特定の計算スレッド２２４０に接続されたプールされたリソース２２４８の量を増加又は減少させる機能を含む。ＰＯＤマネジャ２２４２は、典型的に、ノードコントローラ上で動作する。ＰＯＤマネジャ２２４２は、ＰＯＤ内のリソースの発見、リソースを構成及び管理すること、並びに論理サーバを構成することを担う。一例において、ＰＯＤマネジャ２２４２はオプションの別個のコンポーネントであり、ラック内には必要とされない。しかしながら、一例において、「ＲＳＤ適合」であるために、ラックは認定ＰＯＤマネジャによって管理可能である。

【0253】

以下は、ＰＯＤマネジャ２２４２の属性の一部の例である。例えば、ラックは、エッジサービス及び他の関連するシステムソフトウェアスタック（例えば、オーケストレーション又は他のシステムサービスなど）を実行するのに使用される一組の計算スレッド２２４０を含み得る。計算スレッド２２４０の１つのタイプは、プールリソーススレッド（Pooled Resources Sled）とし得る。この計算スレッド２２４０は、一組の非集約リソースを管理し得る。ここで、計算スレッド２２４０は、プールされたシステム管理エンジンソフトウェア（pooled System Management Engine；ＰＳＭＥ）２２４１を含み得る。ＰＳＭＥ２２４１は、モジュール又はブレードを引き出しレベルで管理するための管理インタフェースを提供する。一例において、ラックは１つ以上の論理ＰＳＭＥを収容する。例えば、各引き出しがＰＳＭＥを有してもよいし、又は複数のサーバ引き出しがＰＳＭＥを共有してもよいし、又はトップ・オブ・ラック（ＴＯＲ）スイッチ２２４４上又は別個のホスト上でＰＥＭＥが動作してもよい。一例において、ＰＳＭＥ２２４１はＲＳＤ ＡＰＩをサポートする。

【0254】

一例において、計算スレッド２２４０は、ターゲットシステムとして作用するとともに一組の非集約リソースを管理するＮＶＭ－ｏＦ又はＦＰＧＡ－ｏＦを実装するＲＳＤソフトウェアスタックを実行する複数のプロセッサ（例えば、ＣＬＸ）を含み得る。一例において、それらのプロセッサは、ＰＣＩｅ×１６分岐ポートを使用して、ターゲットリソース（ＲＳＤ２２４８内のＦＰＧＡ又はＮＶＭＥ）へのアクセスを提供するＰＣＩｅスイッチ２２４６に接続される。

【0255】

エッジサービスを実行するために、様々なＲＳＤエッジ構成ノードフレーバが計算スレッド２２４０で使用され得る。これらのノード上で動作するサービスは、クライアントソフトウェアライブラリ又はドライバを使用して、ＲＳＤ２２４８内の非集約ＦＰＧＡ及びＮＶＭＥへのトランスパレントなアクセスを提供し得る。さらなる一例において、ラックは、計算スレッド２２４０を一組の非集約リソース（例えば、ＲＳＤ２２４８）に接続する１つ以上のＰＣＩＥスイッチを含む。

【0256】

図２２Ａ、２２Ｂ、２２Ｃ、及び２２Ｄのブロック図は、エッジコンピューティングノードの様々となる装置、サブシステム、又は構成のコンポーネントのハイレベル図を示すことを意図している。しかしながら、理解されることには、他の実装では、図示したコンポーネントの一部が省略されてもよいし、追加のコンポーネントが存在してもよいし、図示したコンポーネントの異なる構成が生じてもよい。また、これらの構成は、後述するもの（例えば、数ある他の例の中でとりわけ、スマートシティ又はスマートファクトリーのための工業的計算におけるモバイルＵＥ）を含め、多様なユースケース及び環境において使用可能である。

【0257】

図２１Ａ－２１Ｃ及び図２２Ａ－２２Ｄのそれぞれの計算プラットフォームは、単一の計算プラットフォーム上で走るテナントコンテナの使用によって、複数のエッジインスタンス（例えば、エッジクラスタ）をサポートし得る。同様に、同一の計算プラットフォーム内の複数のテナント上で走る複数のサブノードとして複数のエッジノードが存在し得る。従って、利用可能なリソース分割に基づいて、単一のシステム又は計算プラットフォームが、サポートする複数のテナント及びエッジノードインスタンスへとパーティション分け又は分割されることができ、それらの各々が、複数の所有者によって複数の計算プラットフォームインスタンス内で操作又は制御される可能性がありながら、複数のサービス及び機能をサポートすることができる。これらの様々なタイプのパーティションは、ＬＳＭの使用又は隔離／セキュリティポリシーの他の実装を介して、複雑なマルチテナント及び多くの組み合わせのマルチステークホルダーをサポートし得る。このようなセキュリティ機能を強化又は実現するＬＳＭ及びセキュリティ機能の使用への言及を、以下のセクションで述べる。同様に、これらの様々なタイプのマルチエンティティパーティション上で動作するサービス及び機能は、必要なサービス目的及び処理を達成するために、ロードバランスされ、マイグレーションされ、及び調整され得る。

【0258】

Ｄ．エッジコンピューティングシステムに関するユースケース
エッジコンピューティングは、マルチシステム計算動作（マルチテナント、マルチユーザ、マルチステークホルダー、マルチデバイスなど）を伴う数多くのタイプのユースケース及び展開に関する幾つかの価値提案（value proposition）及び主要業績評価指標（key performance indicator；ＫＰＩ）を満たす。それらの価値提案は、改善された応答待ち時間、向上されたセキュリティ、より低いバックホールトラフィックを可能にし、これらは全て、新たなユースケースを可能にするものである。

【0259】

特定のユースケース又は作業負荷のために実際のコンピューティングエッジが「存在する」場所を定めることは、特定の場所がそれに提供するＫＰＩ又は価値提案に直接的に関係する。例えば、オペレータインフラストラクチャのコア内にＩｏＴ又は拡張現実／仮想現実（ＡＲ／ＶＲ）作業負荷のための計算エッジを定めることは、待ち時間の観点からＫＰＩ要件を満たさない。従って、この作業負荷のための計算エッジは、もっと装置の近く（計算リソースを作業負荷データに近づける、例えば基地局又はセントラルオフィスにおけるニアエッジ又はミドルエッジ層の中など）に配置される。他方で、ＣＤＮ作業負荷のためにコンピューティングエッジは、基地局にて、セントラルオフィスにて、又はオペレータインフラストラクチャの他の中間集約ポイント（ＰＯＡ又はＰＯＰ）にてホストされ得る。

【0260】

エンドユーザによって使用されている装置（又は装置のメッシュ）は、遠端装置とみなされ得るが、多くはいくらかの計算エッジ能力も提供する。このシナリオでの装置は、可能な限り低い待ち時間を提供し得るとともに、メッシュ又は接続されたＩｏＴネットワークのタイプで機能し得る。しかしながら、ある点では、エンド装置は、計算が限られたものとなったり、所与のタスクを実行するのに必要とされるほどに電力効率が良くなかったりすることがある。例えば、ネットワークトラフィック負荷のある点で、ＡＲ／ＶＲユーザは（装置自体の遠端で作業負荷を実行するのよりも悪い性能をもたらす点までもの）深刻な劣化を経験することになる。

【0261】

様々なネットワーク層の間のエッジコンピューティングで最優先のものは、セントラルオフィス機能、ビデオオンデマンド／コンテンツデータネットワークサービス、メディア分析、ライブストリーミング／トランスコーディング、オンラインゲームを含むＡＶ／ＶＲを含む。セントラルオフィス作業負荷は、例えば、収束したフットプリント及び新サービスモデルのためのＳＤＮ／ＮＦＶを含み得る。ビデオオンデマンド／コンテンツデータネットワーク作業負荷には、例えば、ストリーミング、サーベイランス、アラームシステム、ビルへのアクセス、及びこれらに類するものを含み得る。ライブストリーミング／トランスコーディングは、例えばソーシャルネットワーキングアプリケーションからのライブストリーミングなどの強化されたユーザ体験（ＵＸ）を含み得る。ＡＲ／ＶＲ作業負荷は、例えば、リアルタイム小売、ゲームネットワーク等を含み得る。メディア分析（オーディオ及びビデオの両方を含む）はまた、エッジ展開内で広範囲に展開され得る。これらの作業負荷は、前述の作業負荷（例えばサーベイランス、ＡＲなど）の多くで使用される別の重要な柱を構成する。

【0262】

これらの優先的なものに加えて、他のユースケースがエッジクラウド内で可能にされてもよい。インメモリデータベース（ＩＭＤＢ）は、エッジコンピューティング展開の設計においてますます意味あるものとなっている。それらがターゲットとする利用は、オンライントランザクション処理（ＯＬＴＰ、例えば小規模な読み取り又は書き込みなどの、小規模なトランザクション処理要求を扱うため）及びオンライン分析処理（ＯＬＡＰ、例えばもっと大規模なデータセットクエリ及び計算タスクなどの、もっと大規模な分析処理要求を扱うため）をサービス提供することである。これらの２つのタイプの作業負荷は、インフラストラクチャ管理又は他のタイプの分析若しくはデータストレージ（例えばＩｏＴなど）を改善するために、ほとんどがネットワーク分析にマッピングされる。

【0263】

企業及び政府のユースケースもエッジクラウド内で可能にされ得る。この場合、企業顧客の一部が、自身のプロセスの一部を改善するための可能性ある手法として、可能性あるエッジ展開を見込んでいる。これの例はシン・クライアント（thin client）である。シン・クライアントは、所与の企業の従業員が地理的に移動するときに、シン・クライアントへの低待ち時間アクセスを提供するために、エッジインフラストラクチャを横切って移動することができる。

【0264】

インダストリー４．０イニシアチブに関係するユースケースも可能にされ得る。これは、例えば、５Ｇを介した超高信頼性低遅延通信に関するユースケースでのものなど、製造における仮想化によって改善され得る。そのような通信は、ＴＳＰプロバイダが、工業的な作業負荷及び局所化された５Ｇネットワークの双方に対するいっそう完全なソリューションを提供することを可能にする。

【0265】

ヘルスケアは別の１つの分野であり、技術が進歩し、セキュリティ技術が成熟するにつれて、病院及び他の医療機関は、ヘルスケア関連データを安全に保管及び処理するためにエッジクラウドを使用することになる。この設定では、エッジクラウドは、リソース共有を容易にし、ＣＡＰＥＸ及びＯＰＥＸ／ＴＣＯコストの削減を支援することになる。

【0266】

エッジクラウドを介して可能にされ得る別の１つのユースケース分野は、Ｖ２Ｖ、Ｖ２Ｘ、及び他のタイプの先進運転支援システム（ＡＤＡＳ）作業負荷を含む。自動車テクノロジがますます成熟するにつれて、エッジクラウドは、装置間の通信とともに、エッジ内のユーザがエッジサービスにアクセスする手段（Ｖ２Ｘ）を可能にすることになる。

【0267】

以下のセクションは、エッジクラウドに関連する作業負荷ユースケースの多数の様々な例を、それらの要件、用途例、及びサードパーティサービスプロバイダに対する価値提案とともに説明するものである。これらのセクションは、以下の領域に広く分類され、すなわち、データキャッシング、ビデオ／ビデオ分析、ＮＦＶ、ＲＡＮ、拡張現実／仮想現実（ＡＲ／ＶＲ）、車両運転支援、モノのインターネット（ＩｏＴ）、産業アプリケーション、ゲーム、加速ブラウジング、スピーチ分析に分類される。しかし、理解されることには、一部のエッジクラウドユースケース又はアーキテクチャは、多重的な又は他のカテゴリーの下で関連し得る。

【0268】

ユースケース － データキャッシング

【0269】

データキャッシングは、ユーザ機器におけるいっそう高速なロードのために、エッジでデータをキャッシュすることを指す。データキャッシュの例は、人気のある映像を、より迅速なアクセスのための領域にキャッシュすることを含む。データキャッシングは、ストレージ及び計算リソースを使用し、典型的に、待ち時間拘束されない。データキャッシングは、コンテンツ配信ネットワーク（ＣＤＮ）で使用される。グローバルなモバイルデータトラフィックは着実に増加しており、映像データはもはや、モバイルネットワークデータトラフィックの大部分を占めている。映像コンテンツの配信により、冗長なコンテンツがフェッチされて同一地域のユーザ利用者に配信される可能性が高い。

【0270】

このシナリオに基づいて、エッジクラウドは、ネットワークのエッジでコンテンツをキャッシュするための適切なインフラストラクチャとなり、これは、バックホールトラフィックを大幅に削減することができる。これは、サードパーティサービスプロバイダ（及びさらにはＣＳＰ及びＴＳＰ）に対するＯＰＥＸ／ＴＣＯコストを節減することができる可能性を持つ。コンテンツキャッシングは、映像だけでなく、例えば音楽及び文書などの他の分野にも広がり得る。

【0271】

エッジクラウド内で、コンテンツキャッシングを実行するために、以下のような幾つかの手法が使用され得る。

【0272】

（ａ）トラフィック学習に基づくコンテンツキャッシング
その人気及び増加するリクエスト／トラフィックに基づいて特定の地域にコンテンツをキャッシュする。それとともに、先を見越した戦略として、特定の人気コンテンツに類似するコンテンツをキャッシュすることができる。

【0273】

（ｂ）ターゲットコンテンツキャッシング
ターゲットキャッシングとは、ターゲット視聴者のためにエッジでコンテンツをキャッシングすることを意味する。例えば、スタジアム又は集会における視聴者のためである。

【0274】

（ｃ）ユーザガイド下でのキャッシング
ユーザが、（サービス料金又はユーザのデータプランの一部のために）キャッシュされるべきコンテンツを指し示す。簡単な例は、ユーザが動画サイトで「後で見る」として追加する動画、又はストリーミングビデオサービスでお気に入りリストに入れる動画を、キャッシュする候補とし得る。同一地域に同様のコンテンツ興味を持つ何人かのユーザが存在し得るので、このコンテンツをキャッシュすることは、バックホールトラフィックコスト（金銭コスト及びリソースコスト）を節減する道を開く。

【0275】

（ｄ）サービス体験キャッシング
この機能は、ユーザとプロバイダとの間での取引・体験契約の合意に基づく。例えば、ユーザが４Ｋ映像及び９．１サウンドデータを取得することを望んでいるが、リモートサービス及びローカルサービスがスループット、待ち時間、及びトランスコーディング要求を取り扱うことができない場合、システムは、遅延が生じ得る又は次善策（例えば、再生の開始時の遅延）ではあるが、期待されるＱｏＳで、コンテンツを事前フェッチすることを交渉すべきである。

【0276】

ユースケースとしてのコンテンツキャッシングは、キャッシングを実行するために一緒に実行される異なる作業負荷を持つ。これらのユースケースの一部は、コンテンツキャッシングアルゴリズム、データ集約手順、機械学習コード、コンテンツトラフィック分析、ウェブサーバなどの実行を伴い得る。

【0277】

このユースケースは、待ち時間拘束されない。キャッシングは、通常の時間よりも早くリクエストにサービス提供する機会を増加させるので、エンドユーザ体験が肯定的となるとが期待される。

【0278】

このユースケースは、キャッシングを可能にするために共に動作する様々な作業負荷のセットを使用し得る。従って、リソース使用も様々となり得る。コンテンツキャッシングアルゴリズムは、伝統的にＣＰＵ用に最適化されている。しかしながら、分析を補助する機械学習コード又は推論コードは、ＦＰＧＡを使用することがある。最も使用されるリソースはストレージリソースであり、プールされたストレージのナチュラルユーザである。

【0279】

コンテンツキャッシングの実現は、多くの構成（例えば１マスタープロセス及び複数ワーカープロセスなど）によって提供され得る。例えば、マスタープロセスは、ワーカープロセスがリクエストの実際の処理を行うときに、構成を読み取って評価し、ワーカープロセスを維持するために使用され得る。これは、要求を複数のワーカープロセス間に効率的に分配するために、非同期及びイベントベースのモデル及びＯＳ依存のメカニズムを採用するコンテンツサービスプロバイダによって実装され得る。ワーカープロセスの数は、構成ファイルで規定されて、所与の構成に対して固定されてもよいし、利用可能なＣＰＵコアの数に合わせて自動的に調整されてもよい。これは意味することは、コンテンツサービスプロバイダは、接続ごとに別々のプロセスに専念するのではなく、示されるように１つのワーカープロセスからの複数のリクエストを取り扱い得るということである。

【0280】

コンテンツサービスプロバイダは、複数のプロトコルをサポートし得る（例えば、ＨＤＳ（ＡｄｏｂｅによるＨＴＴＰダイナミックストリーミング）、ＨＬＳ（ＡｐｐｌｅによるＨＴＴＰライブストリーミング）、ＭＰＥＧ－Ｄａｓｈ（オープンソースであり、ＹｏｕＴｕｂｅ及びＮｅｔｆｌｉｘによって使用されている）などのＨＴＴＰ上で）。一般に、これらのプロトコルは、ビデオストリームを幾つかのチャンクにカットし、メタデータ及びプレイリストを作成することによって動作する。クライアントは先ず、映像全体をどのチャンクが構成するかを知るためにプレイリストとともにメタデータをダウンロードし、次いで、各チャンクを取得するためにＨＴＴＰリクエストを実行することになる。ビデオオンデマンド（ＶＯＤ）とライブストリーミングとの間の違いは、ＶＯＤでは、チャンク及びプレイリストが前もって生成されるのに対し、ライブストリーミングでは、新たなチャンクが作成されるとき（ストリームから読み出された後）にプレイリストが生成されることである。

【0281】

ｖＣＤＮのスループットは、スムーズなビデオ視聴体験のために（例えば、ビデオが再生されている間に、コンテンツをロードするための一時停止をユーザが見ることがないように）、所与のハードウェア及びネットワーク構成でＣＤＮがサポートすることができる並列ストリームの数で表され得る。

【0282】

他の一例において、エッジクラウドＣＤＮは、ケーブル、電話会社、及びモバイルネットワークサービスプロバイダが、自身又はパートナーが管理するコンテンツをそれらの加入者に、消費者側装置のタイプ又は加入者の位置にかかわらず、放送ＴＶのような体験で配信するための、プライベートＣＤＮを構築することを可能にする。エッジクラウドＣＤＮは、ビデオオンデマンド（ＶｏＤ）、ライブイベント及びクラウドデジタルビデオレコーダ（ＣＤＶＲ）を含め、ＴＶサービスのストリーミング配信をサポートするように最適化される。これは、（ａ）ＣＳＰソフトウェア配信ノードを展開する（例えば、エッジ位置でコモディティハードウェアを用いて）、及び（ｂ）ノードをＣＳＰに接続する、というＣＤＮの２つの主要な側面を確立するコンテンツサービスプロバイダによって提供され得る。これは、構成、動作、及び性能を管理するサービスプロバイダのクラウドベースのダッシュボードへのセキュアなアクセスを可能にするように構成されたエッジクラウドを使用して行われ得る。

【0283】

一例において、個々のＣＳＰエッジノードが、以下の３つのコンテンツ配信モードをサポートすることができ、すなわち、（ａ）オープンキャッシング：委任を通じた且つ仕様（例えば、Ｓｔｒｅａｍｉｎｇ Ｖｉｄｅｏ Ａｌｌｉａｎｃｅによって認められた仕様）を用いた、ＨＴＴＰ及びＨＴＴＰＳ双方での、サードパーティ及びパートナーのコンテンツの配信；（ｂ）トランスパレントキャッシング：例えば、トランスパレントキャッシングを通じたパートナー、オーバーザトップ、サービスプロバイダ所有のＨＴＴＰコンテンツの配信（例えば、トランスパレントキャッシングが、ネットワークエッジで人気コンテンツを検出、分類、キャッシュ、及び配信するとともに、ネットワーク全体でコンテンツをストリーミングすることを最適化するように自律的に動作するとき）；並びに（ｃ）オープンエッジＣＤＮ：サービスプロバイダネットワーク内で展開され、クラウドベースのオペレーションによって管理されるエッジノードを介した、ＨＴＴＰ及びＨＴＴＰＳ双方での、サービスプロバイダ所有のコンテンツの配信、をサポートすることができる。

【0284】

ユースケース － ビデオ／ビデオ分析

【0285】

ビデオ分析は、ユーザ装置に提示するためにエッジでライブビデオ分析及びビデオ前処理又はトランスコーディングを実行することを指す。トラフィックビデオ分析及び警告システムは、エッジでのビデオ分析の例である。このタイプの使用には、ストレージ及び計算リソースが当てにされる。

【0286】

ビデオ分析は多くの分野で重要な役割を果たす。例えば、交通監視カメラ又はセキュリティカメラからの顔認識は、法と秩序において既に重要な役割を果たしている。例えば物体追跡、動き検出、イベント検出、火炎及び煙検出、ライブストリーム又はビデオアーカイブにおけるパターンのＡＩ学習など、幾つかの他のタイプの分析もビデオコンテンツ上で行われることができる。現在、ビデオ分析は、ニーズ及び確立すべき機能に応じてクラウド上又は専用プライベートサーバ上で行われている。エッジでビデオ分析を実行することは、例えば以下など、幾つかの分野に対する要求及び機会の両方をもたらす。
次に例を示します。

【0287】

監視及び公共安全：例えば、ライブビデオストリームをエッジにてほぼ瞬時に処理することは、より良好な監視、並びに法及び秩序を強制することにつながり得る。顔検出及び事件識別並びにトリガ発生は、エッジで行うことができる機能の一部である。これらの機能は、法執行官が事件に関する緊急行動をとることを可能にし得る。

【0288】

コネクティングカー及び自動運転をサポートする：例えば、自動運転車によって見られるシーンのライブストリームは、車がとるべき行動を決定するために、非常に短い時間内に分析される必要がある。自動運転は、シーンを瞬時に処理するためのリソースを既に含んでいることがある。エッジビデオ分析は、より遠いシーンを処理（又は前処理）したり、継続的な訓練及びフィードバックのために映像を後処理したりする働きをすることができる。

【0289】

スマートシティ及びＩｏＴを実現する：エッジでのビデオ分析は、スマートシティを実現するための重要な要素である。例えば、トラフィックビデオ分析は、最も効率的な道にトラフィックを経路付けるために使用されることができる。あるエリアでの火災又は煙の検出を瞬時に特定することができ、都市インフラ及び特定のエリア内のコネクテッドカーの双方にフィードバックを送ることによって、危険区域に向かう交通が続かないことを確保し得る。

【0290】

向上されたインフォテインメントサービス：エッジでのビデオ分析は、例えばスポーツ、コンサート、及び他のショーなどのイベント観客のリアルタイム体験を向上させるために使用されることができる。イベントにおける複数の異なるカメラアングルからの映像が分析され、ＡＲ／ＶＲ機能を適用され、大型スクリーン、スマートフォン、ＶＲ装置などを通じてライブ観客に提示され得る。

【0291】

エッジでのビデオ分析に対する待ち時間及びターンアラウンド時間（応答所要時間）の要求は、異なるシナリオでは異なる。それらを、以下の表１に例示する。

【表1】

【0292】

ＴＳＰは、エッジで提供されるビデオ分析サービスを収益化する幾つかの方法を有する：
ａ． 改善されたサーベイランス及びモニタリングは、政府機関及び民間警備会社へのサービスとして提供されることができる。
ｂ． スマートシティ向けのビデオ分析（及びその具体的な機能）は、必要に応じて、政府機関、ＩｏＴ装置プロバイダ、及び家庭の双方へのサービスとして提供されることができる。
ｃ． 向上されたインフォテインメント向けのビデオ分析は、イベントの観客又は主催者（代わりに観客に提供する）へのサービスとして提供されることができる。

【0293】

ユースケース － ネットワーク機能仮想化（ＮＦＶ）及び無線アクセスネットワーク（ＲＡＮ）オペレーション

【0294】

柔軟なＮＦＶは、ストレージ及び計算リソース（例えば、ＣＰＵ又はＦＰＧＡ）に大いに頼っている。エッジクラウド展開は、同一プラットフォーム／同一位置でネットワーク（ＮＦＶ）及びサービス機能を共同ホストすることによってユーザ体験を制御し得る。要求されるサービスを実際に提供するサービスの近くにローカルブレイクアウトを配置できることは、より良い応答時間を提供し得るとともに、インフラストラクチャ又はデータセンターを通る不要なトラフィックを減らすことによってＯＰＥＸ／ＴＣＯを減らし得る。

【0295】

同一ネットワーク展開内でのＭＥＣとネットワーク機能仮想化（ＮＦＶ）との統合に関して、ＥＴＳＩ仕様展開の通り、ＭＥＣ及びＮＦＶは独立に存在し得る相補的な概念である。ＭＥＣアーキテクチャは、ＭＥＣシステムの複数の異なる展開オプションが可能であるように設計されている。ＮＦＶに関して、ＭＥＣシステムは、同じネットワーク内のＮＦＶ環境の存在とは独立に実現されることができ、又はそれと共存することができる。ＭＥＣ及びＮＦＶはどちらも仮想化技術を利用し得るので、ＭＥＣアプリケーション及びＮＦＶ仮想化ネットワーク機能は、同一の仮想化インフラストラクチャ上で部分的又は完全にインスタンス化されることができる。

【0296】

ＮＦＶ環境におけるＭＥＣ参照アーキテクチャは、ＮＦＶフレームワークのＶｉｒｔｕａｌｉｚｅｄ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ Ｍａｎａｇｅｒに（幾つかの増強を有して）類似した仮想化インフラストラクチャマネジャの概念と、ＮＦＶ仕様書に記載されるＮＦＶ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ Ｐｏｉｎｔ－ｏｆ－Ｐｒｅｓｅｎｃｅ（ＮＦＶＩ－ＰｏＰ）に大まかに対応する仮想化インフラストラクチャの概念とを再利用する。参照アーキテクチャは、ＭＥＣとＮＦＶとの間での更なるシナジーが達成され得るように設計されている。

【0297】

例えば、完全に仮想化された環境若しくは混合環境、ＭＥＣが最初に展開される若しくはＮＦＶが最初に展開される、これら２つのテクノロジの間での異なるレベルの統合を有する、例えばマルチテナントなどの二次的な側面を考慮に入れるなどといった、オペレータのネットワークに対する嗜好及び移行戦略に応じて、展開に関する複数のシナリオが可能である。ＭＥＣ及びＮＦＶのマネジメント及びオーケストレーションコンポーネントが相互に関係し合う方法（例えば、統合、相互運用、共存）は、統合されたＭＥＣ－ＮＦＶ展開の重要な側面である。ＲＡＮユースケースはまた、（例えば、エッジでの）非中央集権的なＲＡＮ及びＵＰＦの使用を含む。よく理解されるように、ＲＡＮはストレージ及び計算リソース（例えば、ＣＰＵ又はＦＰＧＡ）に大いに頼っている。ＲＡＮ構成の更なる説明については、以下で、５Ｇ接続の例にて提供する。

【0298】

ユースケース － 拡張現実／仮想現実（ＡＲ／ＶＲ）

【0299】

拡張現実（ＡＲ）ユースケースはほとんどが、画像認識（顔、物体など）及びそれらについての分析を伴う。ＡＲ（及びＶＲ）の使用は、エッジによってサポートされるように、相互にインタラクトするエンドポイントの間を含め、ユーザ制御されるエンドポイントに焦点を当てることが期待される。このように想定される使用は、単一のエンドポイント装置、一群の装置、又は装置間アプローチのいずれを含むかにかかわらず、サービス要求を満たすために低遅延時間を必要とすることが多い。

【0300】

ＡＲに関与するクライアント装置は、典型的に、カメラ付きの携帯電話又はウェアラブルの形態である。典型的な使用シナリオは、ユーザがカメラ装置を物体に向けて、その物体に関する有用な注釈を見るというものである。例えばＶｉｅｗＡＲ、Ｖｉｖｉｎｏ、Ａｕｇｍｅｎｔなど、ＡＲサービスを提供する幾つかのスマートフォンアプリが既に存在しており、そのようなアプリ又は関連するウェアラブルは、特定の目的でＡＲを提供するように設計されている。例えば、Ｖｉｖｉｎｏは、ワインボトルのラベルの写真がキャプチャされて提供されるときに、そのワインに関する有用な情報を提供する。同様に、ＶｉｅｗＡＲは、部屋の空間をパッケージング及びプランニングするための３Ｄビジュアル化を支援する。

【0301】

ＡＲシナリオは、典型的に、（ｉ）キャプチャした画像を装置から送信する、（ｉｉ）画像認識と物体識別、及び（ｉｉｉ）分析を実行して結果を生成する（インターネットから見出された有用な情報の注釈、物体の識別などの形式で）、という３つの段階で構成される。上記段階において、（ｉｉ）及び（ｉｉｉ）が一般的に最も時間を要する部分である。特定の機能に特化されたＡＲサービスが、画像認識サービスに対して特定のターゲットを規定する。画像認識サービスが、画像を識別し、それらのターゲットを探す。そして、ＡＲサービスが、結果を用いて、例えば分析又はインターネットからもっと多くの情報を見つけることなどの更なる処理を実行する。そして、それらの結果がユーザに表示される。

【0302】

ＡＲサービスは画像認識のために別のサービスを使用することが一般的である。例えば、上述のアプリの多くは、画像認識のためのメインエンジンとしてＶｕｆｏｒｉａを使用している。ＡＲサービスは、そのＡＰＩを介してターゲットをＶｕｆｏｒｉａエンジンに対して前もって指定することで、画像認識が指定ターゲットを見つけることができるようにする。画像認識は、装置上及びクラウド上の両方で行われることができる。それを装置上で装置上データベースを用いて実行することは電力効率的でない一方で、同じことをクラウド上で実行することは、より長い時間を要する。他の一例は、Ｃａｔｃｈｏｏｍクラウド画像認識サービスである。それは、ＡＲアプリが、クラウド内のそれらのサービスに、ＲＥＳＴｆｕｌ ＡＰＩを介してリクエストを送信することを可能にしており、画像認識で応答する。ＡＲアプリは、画像が認識された後に、クライアント装置から第３の処理を実行し、それは、インターネット上で所望の情報を探し該情報をユーザに提示するというものである。

【0303】

例えばＶｕｆｏｒｉａ及びＣａｔｃｈｏｏｍなどの画像認識サービスは、それらのサービスを使用する幾つかのＡＲアプリを有する。これは、より多くのそのようなＡＲアプリが作成され、それらのＡＲアプリのユーザが増加するときにのみ、将来的に増加することが期待される。それらのサービスは現在、クラウドにホストされているので、画像認識の待ち時間及びターンアラウンド時間がかなり大きい。例えば、Ｖｉｖｉｎｏでワインに関する情報を見つけるには数秒かかる。これは、ウェアラブルが関与し、タイムクリティカルな注釈が必要であり、リアルタイムの動きを考慮される必要があるシナリオでは受け入れられないものとなる。従って、画像認識サービスをクラウドからエッジへ移すことは、総ターンアラウンド時間を改善することができ、シームレスな体験をユーザに与え得る。

【0304】

上述のように、現在のソリューションは、ユーザへの最初の注釈又は最初の出力を生成し始めるのに数秒を要する。この遅延を「応答時間」と称する。これは主に、クラウドにてホストされるサービスであるためである。シームレスなユーザ体験のため、及び将来のタイムクリティカルなＡＲユースケースをサポートするためには、ターンアラウンド時間要求は非常に短いものである。以下の表２は、様々な情報源に従ってそれらの要求をまとめたものである。

【表2】

【0305】

画像認識、物体追跡、及び識別は、ＡＲサービス全体の最も計算集約的な部分である。最もよく知られた画像認識アルゴリズムは、ＳＵＲＦ、ＳＩＦＴ、ＦＡＳＴ、及びＢＲＩＥＦである。例えばＶｕｆｏｒｉａ及びＣａｔｃｈｏｏｍなどのサービスは、使用しているコアの画像認識アルゴリズム及びそれらのリソース要件を開示していない。しかしながら、いずれの画像認識アルゴリズムも、ＣＰＵとＦＰＧＡとを使用するように実装されることができる。これらのサービスが出くわすリクエストの量が、使用可能なＣＰＵ又はＦＰＧＡのサイズを決め得る。例えば、Ｖｕｆｏｒｉａは３００を超えるアプリを登録しており、Ｃａｔｃｈｏｏｍはこれまでに既に７億５千万ものインタラクションを行っており、それは２０２５年までに１００億になると予期される。従って、リクエストの量が増えるにつれて、システムは、到来するリクエストを満たす上でより高い並列性を必要とし、それ故に、より多くのリソースを必要とする。これらのサービスはまた、物体マッチング用の画像リポジトリを格納するためのストレージを使用する。これも、画像認識及び物体識別をインターネット接続なしでエッジから直接的に行うことを可能にするエッジに設けられることができる。高度なシナリオとして、ＡＲサービスアプリはまた、画像が認識されるとすぐに、より速い応答をユーザに提供するために、インターネットからキャッシュしたデータを格納するための、エッジにあるストレージを使用し得る。キャッシュされたデータはまた、メモリ内、ＮＶＲＡＭ上の永続メモリ、又はプールされたＳＳＤストレージなどの異なる層に配置されることもできる。

【0306】

サードパーティサービスプロバイダ（ＴＳＰ）は、エッジでのＡＲサービスを収益化し得る。エッジは、ＡＲアプリによって使用されることが可能な中央の画像認識及び物体識別サービスをホストすることができる。ＡＲアプリは、ＡＰＩを介してターゲットを指定し、このサービスは、入力リクエストが送られたときに所望の物体で応答することができる。アプリは、エッジでのそのサービスに対して支払いをすることになる。

【0307】

エッジは、使用されるリソースに対して支払いをする例えばＶｕｆｏｒｉａ又はＣａｔｃｈｏｏｍなどの画像認識サービスをホストすることができ、また、それらのサービスを使用するアプリとは別のビジネスモデルを持つことができる。例えば、Ｃａｔｃｈｏｏｍ ＳａａＳをエッジから提供することができる。

【0308】

ユースケース － 車両支援及び自律運転オペレーション

【0309】

エッジ計算ノードは、自律車両オペレーションを支援するために使用され得る。ユースケース例は、以下に限られないが、ナビゲーション、車両間（Ｖ２Ｖ）通信、車両インフラストラクチャ間（Ｖ２Ｉ）通信、又は車両エブリシング間（Ｖ２Ｘ）通信を含む。待ち時間は、自律運転のためにほぼリアルタイムの応答時間を確保するための車両支援ユースケースにおけるファクタである。

【0310】

ＥＴＳＩ ＭＥＣは、マルチベンダ、マルチネットワーク及びマルチアクセス環境におけるＶ２Ｘ相互運用性を支援するために、Ｖ２Ｘ ＭＥＣサービスを開発している。それは、Ｖ２Ｘ関連情報フロー、必要な情報及び操作を記述している。ＭＥＣ仕様では、必要なＡＰＩをデータモデル及びデータフォーマットとともに規定している。ＥＴＳＩ ＭＥＣは、Ｃ－Ｖ２Ｘエッジクラウド展開に関する標準化されたソリューションであり、故に、これを考慮に入れて、ＭＥＣ０３０ ＷＩは、後に「Ｖ２Ｘ情報サービス」（ＶＩＳ）と呼ばれることになった新たなＭＥＣサービスを導入している。

【0311】

自動車ユースケースは、様々な自動車メーカー、ＯＥＭ（相手先商標製品製造会社）サプライヤー、ネットワークインフラベンダー、ＭＥＣベンダー、アプリケーション／コンテンツプロバイダ、及び他のステークホルダーという、複数のステークホルダーが関与する。

【0312】

さらに詳細には、ＥＴＳＩ ＭＥＣにおける要件によれば、マルチアクセス、マルチネットワーク及びマルチオペレータのシナリオが、Ｖ２Ｘサービスに適用可能なシナリオを含めて、この分野に関するＭＥＣ規範的作業の必要性を動機付けるリファレンス想定である。例えば、一部のＶ２Ｘサービスは、ＯＥＭによって管理されることができ（いわゆる「車両ＯＥＭシナリオ」）、故に、このようなサービスに関して単一オペレータ及びマルチオペレータの両方のシナリオを考慮することが理にかなっている。なお、Ｖ２Ｘサービスは、同一国及び／又は複数の異なる国において複数の異なるネットワークオペレータによって提供されることが期待される。

【0313】

同様に、更に複数の異なる車両ＯＥＭにサービスを提供し得るものである「ＩＴＳオペレータシナリオ」を検討する場合にも同じことが当てはまる。高度道路交通システム（ＩＴＳ）オペレータは、（異なるＭＥＣシステムを展開している）異なるオペレータネットワークを活用し、且つ異なるＯＥＭに属する車両にこのサービスを提供することによって、全国規模のＶ２Ｘサービスを提供する必要があり得る。なお、この場合にも、Ｖ２Ｘサービスは、同一国及び／又は複数の異なる国において複数の異なるネットワークオペレータによって提供されることが期待される。

【0314】

結果として、全てのユースケースを可能にするために、エッジクラウドにて動作するＶＩＳサービスは、一般的なシナリオで実装されるＣ－Ｖ２Ｘシステムをサポートし得る。特に、これらのシナリオは、複数のＭＥＣベンダーの存在、及びそれらの間で相互運用可能なデータ交換を可能にする必要性を前提とする。

【0315】

さらに、マルチオペレータ相互運用性は、Ｖ２Ｘのためのサービス継続性を保証するための考慮事項である。より具体的には、典型的なマルチオペレータシナリオでは、無線カバレッジの一時的な欠如（例えば、ローミング状況において）が関与する数多くのシナリオが存在し得る。また、伝統的なＶ２Ｘシステムでは、モバイルネットワークオペレータ（ＭＮＯ）間の相互接続がリモート側で終端されていて、高いエンドツーエンド（Ｅ２Ｅ）待ち時間の観点での明らかな欠点を伴うが、他方で、ＶＩＳサービス（ＭＥＣシステム間の「水平通信」も可能にする）の活用のおかげで、ＭＮＯ間の相互接続を低いＥ２Ｅ待ち時間で実現することができる。

【0316】

Ｖ２Ｘサービス継続性は、双方のオペレータのカバレッジエリアを含む全てのテリトリーにわたって確保される必要があり、また、一方のオペレータのカバレッジエリアを去って他方のオペレータのカバレッジエリアに入る時に、サービスの中断がなく、Ｅ２Ｅ性能を保証する必要がある。この目的のために、ＶＩＳは、特にＵＥがカバレッジ外にあるときに、ＰＣ５構成パラメータに関する情報を公開して、マルチオペレータ環境を管理する。

【0317】

ＭＥＣ展開は「エッジ」の定義に依存する。特にＮＦＶ環境内でＭＥＣを展開するとき（実際には、この場合、ＭＥＣエンティティは仮想化ネットワーク機能（ＶＮＦ）としてインスタンス化されることになり、故に、オペレータの展開の観点で高い柔軟性を伴う）、必要な自由度をＭＮＯに提供するために、幾つかのオプションがＭＥＣ規格によって可能にされる。従って、原則として、エッジクラウドはあらゆるところに公開されるので、ユースケース／垂直セグメント／処理される情報に応じてＭＥＣを柔軟に展開することができる。さらに、ＭＥＣシステムの一部のコンポーネントは、システムの一部の要素と同じ場所に置かれる場合に、いっそう良好に配置されたものとなる。一例として、特定のユースケース（例えば、企業）において、ＭＥＣアプリがＭＥＣサービスをローカルに消費する必要があることがあり、それ故に、必要なＡＰＩのセットをローカルに備えたＭＥＣホストを展開することに価値があり得る。他のケースにおいて、（アクセスネットワークから遠く離れた）データセンターにＭＥＣサーバを展開することは、ＲＮＩ ＡＰＩ（これは、無線基地局から無線ネットワーク情報を収集する）のような一部のＡＰＩをホストすることを不要にし得る。他方で、ＲＮＩ情報は、集約点にてクラウドＲＡＮ（ＣＲＡＮ）環境に説明されて利用可能にされ、そうして、好適な無線アウェアなトラフィック管理手順の実行を可能にする。他の一部のケースでは、例えばコンテンツ配信ネットワーク（Content Delivery Network；ＣＤＮ）ベースのサービス用に、輸送ネットワークを適切にセットアップするために、帯域幅管理ＡＰＩが、アクセスネットワークレベルにおいてと、より遠隔の場所においてとの両方に存在することに意味があり得る。

【0318】

ユースケース － モノのインターネット（ＩｏＴ）

【0319】

モノのインターネット（ＩｏＴ）装置は、例えばファクトリーオートメーション、プロセスオートメーション、スマートグリッド、スマート小売、コンシューマ装置、自動車、ホームオートメーション、オフィス及び商業用途、セキュリティ、軍事、及び他の用途などの数多くの分野にある。ＩｏＴは、通信応答時間、計算リソース、及びストレージリソースに大いに頼っている。待ち時間要求は用途に依存する。例えば、ファクトリーオートメーション環境では、０．２５ｍｓから１０ｍｓの往復待ち時間が必要とされることがあり、スマートグリッド実装では、３－２０ｍｓの往復待ち時間が使用されることがあり、そして、プロセスオートメーション環境では、５０－１００ｍｓが使用されることがある。ＩｏＴネットワークで使用されるネットワークトポロジーは、ここに記載されるテクノロジのうちのいずれかを、以下に加えて含むことができ、以下とは、Ｂｌｕｅｔｏｏｔｈ（登録商標）ローエナジー（ＢＬＥ）リンクを用いて提供されるメッシュネットワーク、ＩＥＥＥ ８０２．１１（Ｗｉ－Ｆｉ（登録商標））リンクを介してＩｏＴ装置と通信するために使用される無線ローカルエリアネットワーク（ＷＬＡＮ）、ＬＴＥ／ＬＴＥ－Ａ（４Ｇ）又は５Ｇセルラネットワークを介してＩｏＴ装置と通信するために使用されるセルラネットワーク、又は、例えばＬｏＲａアライアンスによって公布されたＬｏＲａＷａｎ仕様と互換性のあるＬＰＷＡネットワーク、若しくはインターネットエンジニアリングタスクフォース（ＩＥＴＦ）によって公布された仕様と互換性のある低電力ワイドエリアネットワーク（ＬＰＷＡＮ）ネットワーク上のＩＰｖ６といった、低電力ワイドエリア（ＬＰＷＡ）ネットワークである。さらに、それぞれのＩｏＴネットワークは、例えばＬＴＥセルラリンク、ＬＰＷＡリンク、又はＩＥＥＥ ８０２．１５．４標準に基づくリンク（例えばＺｉｇｂｅｅ（登録商標）など）などの幾つもの通信リンクを使用して、外部のネットワークプロバイダ（例えば、ティア２又はティア３のプロバイダ）と通信し得る。それぞれのＩｏＴネットワークはまた、例えばＣｏＡＰ（Constrained Application Protocol）などの多様なネットワーク及びインターネットアプリケーションプロトコルを使用して動作し得る。それぞれのＩｏＴネットワークはまた、リンク付けられた装置及びネットワークのクラスタツリーを形成するリンクのチェーンを提供するコーディネータ装置と統合されてもよい。

【0320】

モノのインターネット（ＩｏＴ）は、データの重要な生産者であるとともに消費者でもあるとして期待される。ＩｏＴネットワークノードは、ノード構成をピアノードに対して証明するハードウェアＲｏＴ（例えば、ＤＩＣＥアーキテクチャを使用する）を含むことができ、ピアノードは、同様に、集約サブネットワーク及びトポロジを次層の証明検証者に対して証明する。この構造は、エッジサーバ、ＦａａＳ、メッシュ、及び仮想テナント「スライス」のネスト及びトポロジダイナミクスに大まかに一致し、従って、理解されることには、トップレベルのエッジツーエッジでの、又は地域、ローカル、若しくは他の分割スキームに細分されたものでのセキュリティを評価する共通の、分散された、一般化された証明検証及び分析機能を使用することができる。

【0321】

ＩｏＴコンポーネントは、典型的に、スマートシティ、スマート小売、スマート車両、スマートホームなどからの要素／装置を含む。ある意味で、例えばビデオ分析及びＡＲ／ＶＲなどの上述の作業負荷もＩｏＴの一部でもある。何故なら、エッジ装置は理論的にはＩｏＴ装置であるからである。例えば、顔検出作業負荷が、スマートシティ環境内の装置のため、又はスマート小売店におけるチェックアウトのため、又は個人ユーザ用のＡＲの一部として実行され得る。従って、ＩｏＴ作業負荷は一般に、特定のデータポイントを処理する点で全てのＡＩ作業負荷を含む。

【0322】

より具体的なＩｏＴ関連の作業負荷は、ＩｏＴゲートウェイである。ＩｏＴ装置は、近い将来において毎日数兆ギガバイトのデータを生成すると予期される。これら全てのデータが、様々な目的のために異なる待ち時間で異なるように処理される必要がある。これはまた、（様々な待ち時間要求を満たすために）これら全てのデータを様々な場所で処理するための計算能力が必要であることを意味する。エッジクラウドは、（ａ）例えばフィルタリングやフォーマット変更などのデータ前処理（双方向）、（ｂ）接続されたコンポーネントを持つ待ち時間クリティカルなユースケース及びシナリオに関するデータ処理、及び（ｃ）部分的なデータ処理及びストレージ、を実行するのに理想的な場所である。

【0323】

データ編成及び処理もエッジクラウドでの操作である。基本的に、データ編成エンティティは、データへの非常に高速なアクセス用に設計される単純なキー値ストアから、複雑な分析操作まで、複雑さにおいて多種多様である。以下は、エッジクラウドにて可能にされ得るデータ編成及び処理ソフトウェアの広い分類である。（ａ）ＮｏＳＱＬキー値ストア／キャッシュ：非常に高速なルックアップ及び取り出しのためにデータを格納し、データに対する処理は行わない（例えば、Ａｅｒｏｓｐｉｋｅ、Ｒｅｄｉｓ）。（ｂ）ＮｏＳＱＬカラムストア：非常に高速なルックアップ及び取り出しのためにデータを格納し、例えばレンジルックアップなど、一部の基本的な操作を実行する（例えば、ＨＢａｓｅ、Ｃａｓｓａｎｄｒａ）。（ｃ）ＮｏＳＱＬドキュメントストア：例えば検索及び索引ベースのルックアップなどの操作を実行する（例えば、ＭｏｎｇｏＤＢ、Ｍａｒｋｌｏｇｉｃ）。（ｄ）ＮｏＳＱＬグラフデータベース：グラフトラバーサルに関係する特殊な操作を実行する。例：Ｎｅｏ４ｊ。（ｅ）ＮｅｗＳＱＬ／ＳＱＬデータベース：膨大な範囲の複雑なデータベースクエリを実行する。（ｆ）分析ソフトウェア：様々なストアからのデータに対して統計的分析を実行する。

【0324】

伝統的にクラウドにて展開されてきた作業負荷及び企業作業負荷の一部が、結局はエッジ位置で同様に展開されることになる。これらは、以下のカテゴリーからの作業負荷を含む。

【0325】

低待ち時間又は文脈化されたデータ分布：この場合、クラウドにて展開される既存の作業負荷の一部が、データへのより高速なアクセスを提供するために、よりセキュアなやり方で（複数のセキュリティドメインを横断する必要はない）で、データアクセスの観点でより小さいジッタで（電話会社インフラから、おそらくエッジにホストされるエンドサーバまで、複数のレイヤを横断する必要はない）、エッジ位置にて展開され得る。作業負荷の第１の例は、例えばＨＡＮＡ又はＳｐａｒｋ－ＳＱＬなどのインメモリデータベース、及び例えばウェブサーバなどのデータフロントエンドである。このユースケースは、一部の例において、加速ウェブブラウジングと組み合わされることができる。作業負荷の第２の例は、エッジでのデータマイニング又は分析であり、この場合、リアルタイム又は事後データ分析を行うために、既存のデータマイニング作業負荷がエッジ位置で使用され得る。これらのユースケースは、動的又は適応的な解をとるためのリアルタイム分析を伴うことができ、これは、例えば、適応ネットワーク機能又は動的ＩｏＴ管理スキームのために使用され得る。エッジの観点でのこのユースケースの主な価値提案は、リアルタイム意思決定の待ち時間についてである。これらのユースケースはまた、擬似リアルタイム又は事後データ処理を伴うことができ、これは、例えば、必ずしもネットワークのバックホール上で格納及び処理される必要があるわけではない、ＩｏＴ装置がエッジに対して生成するデータ、の全てを処理するために使用され得る。エッジの観点でのこのユースケースの主な価値提案は、バックホールトラフィック節減及び計算分散についてである。

【0326】

このエッジクラウド投影戦略は、異なるプラットフォーム、提供サービス、及びユーザ数に対するエッジクラウドの寸法決めを投影することによって、プラットフォーム定義の助けとなり得る。これは、エッジで提供される異なるサービスによって示されるエッジクラウドサイズ（ノード数）を投影すること、異なるサービスに対する例えばＦＰＧＡなどのアクセラレータの有り及び無しでのエッジクラウドの寸法決めを投影すること、及び異なるプラットフォームの電力要求を投影することの効果を有し得る。この目的のために投影モデルが利用され得る。例えば、ある投影モデルは、それぞれのサービス／ユースケースを表す作業負荷特性を分析することによって投影を実行し得る。個々の作業負荷について、作業負荷の簡単な説明、モデル化のための仮定、モデルによって使用されるデータ及び構成が、投影モデルによって考慮され得る。

【0327】

評価に使用されるＡＩモデルの多くは、ＣＮＮベースのディープラーニング推論の開発及び展開のためのツールキットであるＯｐｅｎＶＩＮＯツールキットの一部である。このツールキットは、例えばＣＰＵ、ＧＰＵ、ＦＰＧＡ及びＭｏｖｉｄｉｕｓ Ｎｅｕｒａｌ Ｃｏｍｐｕｔｅ ＳｔｉｃｋｓなどのコンピュータビジョンアクセラレータにまたがってのＡＩモデルのヘテロジニアス実行をサポートする共通のソフトウェアツール及び最適化ライブラリを提供する。ＯｐｅｎＶＩＮＯツールキットはまた、基礎となるハードウェア上で走るように最適化される一組の事前訓練されたＡＩモデルも含んでおり、それらの一部は、作業負荷の評価及び分析に使用されている。このツールキットを用いて、例えば、ビデオ分析が、シナリオに応じて該当するＡＩモデル又は複数のモデルの組み合わせを用いて実行され得る。

【0328】

ユースケース － 検出

【0329】

ＩｏＴ：顔検出ＡＤＡＳ － これは、例えば、乗客が車内にいるかを監視すること、及び屋内の歩行者交通量をカウントすることなどの、多様な目的で使用されている標準的な顔検出モデルである。これはまた、運転補助警告システムにおいて用途を見出す。例えば、これは、疲れ及び疲労の徴候に関して運転者を継続的にスキャンし、必要な場合に、運転者の注意を道路に戻させるよう、視覚的及び聴覚的警告を用いて運転者に警告するために使用されることができる。

【0330】

ＩｏＴ：顔検出 － このモデルは典型的に、例えば、既知の万引犯を識別すること、返品詐欺を行う人を識別することなどの目的で、小売り環境で使用される。さらに、これは、例えば以下などの小売り分析をサポートするモデルと組み合わせたり続かれたりすることができる：（ａ）年齢・性別認識（検出された顔の年齢及び性別を検出するモデルを用いる。顔検出モデルから検出された顔がこのモデルへの入力として提供され、このモデルが、その人物の年齢及び性別を推定する。小売り分野において、それは、例えばどのカテゴリーの人がどのようなアイテムを見て購入するかを理解することなどの分析に使用され得る。このモデルはまた、例えばビデオ監視などの他分野でも使用され得る。）；及び（ｂ）頭部姿勢推定（人物の頭の位置を検出するモデルを用いる。）。小売り環境において、これは、何がその人物の注意を引いたかを理解するために使用され得る。これはまた、ＡＤＡＳ又はビデオ監視分野でも使用され得る。

【0331】

ＩｏＴ：人検出 － 人検出は、屋内環境及び屋外環境の双方で、より高い見晴らしの良い位置に設置されたカメラを用いて、人を検出するために使用される。これは、例えば群衆計数、ビデオ監視などの多様な目的で使用され得る。

【0332】

ＩｏＴ：人、車両、及び自転車検出 － このモデルは、例えば人、自転車に乗っている人、自転車のみ、及び車両の間で区別することなどの目的で、屋外カメラからのビデオ分析に使用される。このモデルにおける多様な照明条件は、昼光、暗闇、及び天候の変動における精度を改善する。

【0333】

ユースケース － ヘルスケア産業用途

【0334】

産業用途は、ヘルスケア分野、製造業、小売業、又は他の産業にあり得る。ヘルスケアにおいて、エッジコンピューティングは、接続性及び分析を通して種々の医療器具を実装するために使用され得る。一例のユースケースは、医師が遠隔で患者を手術することができる遠隔手術である。このようなユースケースは、高い計算、通信、及びストレージリソースを含む。

【0335】

他の一状況において、非伝染性疾患（例、ＮＣＤ、癌、及び糖尿病）に起因するより多くの死亡及び障害では、広範な集団に対する定期的なスクリーニング方法を考案することが重要である。多くの国では、都市部に比べて農村部に居住する専門家が少なく、人は多いという二重の問題を所与として、これらの問題を量って対処するソリューションを探すことが重要である。人工知能（ＡＩ）ベースのテクノロジは、ＮＣＤ／ＣＤのスクリーニングの質の点で非常に大きな成功を示しており、世界中の多くの国がこのテクノロジを採用して、専門家を補い、それによって大規模展開に対処すること（例えば、英国）、及び農村部でＡＩ支援による遠隔スクリーニングを通してこれらのサービスへのアクセスを提供すること（例えば、中国）を始めている。ＡＩ支援による（遠隔）スクリーニングでは、多数のＮＣＤ（及びＣＤ）に対する早期介入を大幅に強化することができ、さもなければ、国のバックボーン、すなわち人的リソースを破壊してしまい得る。ＮＣＤ／ＣＤの早期スクリーニングは、より良い治療計画、及び治療後の、より良い生活の質を提供する助けとなる。そして、これらのサービスは、患者がスクリーニングのために長距離を移動する必要なしで、地方の遠隔地で利用可能にされ得る。これらのＡＩ支援疾患スクリーニングは、画像診断技術（Ｘ線、超音波、眼底、ＯＣＴ、ＰＥＴ、ＭＲＩ、赤外線、ＣＴ）及び非画像診断技術（例えば身長、体重、ＢＭＩ、心拍数、ＥＣＧ、血圧、血糖などの生理学的身体パラメータ）に基づくことができる。

【0336】

ゆっくりと着実に注目を集めている他の１つの側面は、疾病ケアからヘルスケアへと移行しようとするニーズである。これは、早期警告信号のためにモニタされることが可能な潜在的にリスクの高い人物の継続的なリアルタイム分析を必要とする。これは、タイムリーな入力でヘルスケアサービス提供者に警告するために特定の生理学的パラメータを継続的にモニタすることができるウェアラブル医療装置を介して達成され得る。他の１つの使用法は、早期警告信号のためにモニタされることが可能な高齢者の継続的なリアルタイム分析である。これらの分析はまた、ウェアラブル装置を通してモニタされる生理学的パラメータの他に、オーディオビジュアルデータも含む。最後は、在宅ケア又は院内ケアで回復している疾病患者からキャプチャされる生理学的パラメータについての継続的なリアルタイム分析を中心とした使用法である。特定のＡＩベースの疾患診断ソリューションに対する最近のＦＤＡ承認により、高度に保護された医療分野へのＡＩテクノロジの適用の門が開かれている。

【0337】

エッジにて展開可能なヘルスケア分析は、ＡＩテクノロジの適用に関する３つのセグメントに分類され得る：（ａ）ＡＩを通じた疾患スクリーニング；（ｂ）正確な診断品質のためのＡＩを通じたマルチモーダル疾患診断；及び（ｃ）標的療法によって介入効果を向上させるためのＡＩを通じた精密医療。

【0338】

ヘルスケア分析分野でのワークフローには、幾つかの側面がある。新たな証拠又は根拠に基づいてＡＩモデルを更新するという範囲の他に、スクリーニング／診断の質が最も重要なものであることを保証するための絶え間ない努力があり、すなわち、偽陰性は０であるべきであり、偽陽性は０になる傾向がある。これが意味することは、推論できるＡＩエンジンも、新しい証拠又は根拠に基づく増分的モデル更新（再訓練）を実行する性能を持ち得るということである。

【0339】

推論の待ち時間は非常に重要なパラメータである。ＡＩエンジンの性能は、専門家よりも遥かに速く、それ故に、専門家は最終診断のためにＡＩエンジンからタイムリーな入力を得ることができる。

【0340】

診断モダリティの多くは画像に基づくので、非常に重要な疾患バイオマーカーの喪失のない、より良好な画像圧縮に対するニーズが存在する。また、ヘルスケアデータは、利用に関して厳格に管理される。これは、ヘルスケアデータのプライバシー／保護のための十分なサポートが存在することを必要とする。

【0341】

例えば物体検出及びセグメンテーションなどのＡＩ技術は、放射線科医がいっそう迅速且つ正確に問題を特定するのを助ける特有の可能性をもたらし、それが、症例のより良い優先順位付け、より多くの患者のより良い転帰、及び病院にとっての削減された金銭的コストとなり得る。しかしながら、医用撮像用のＡＩは、情報が高解像度で多次元であることが多いので、しばしば難題である。メモリ制約のために、より低い解像度へと画像をダウンサンプリングすることは、バイオマーカーが保存されない限り、誤診を生じさせてしまい得る。ＡＩモデルが許容可能な精度レベルまで訓練されると、それを画像診断アーキテクチャに組み込む必要がある。放射線医学画像が典型的にいかに大きいかを所与として、放射線医のワークフローを遅くさせたりモデルの精度に影響を与えたりすることなく、これらの画像を効率的に処理できることが極めて重要である。

【0342】

例えば、骨年齢予測モデルは、患者の性別とともに、例えば手首などのヒトの骨のＸ線画像からの入力を取る。そして、推論モデルが、骨粗しょうにつながる医学的状態を特定する助けとなるよう、骨からの推定年齢を決定する。例えば、若年患者の推定年齢が実年齢よりも低い場合、その患者は栄養不良を患っている可能性がある。

【0343】

他の一例は、患者の胸部のＣＴスキャンから肺を特定し、次いで、検出された臓器の周囲にセグメント分けマスクを作成する肺セグメンテーションモデルである。その結果を用いて、肺の大きさ及び容積を測定したり、例えば結核又は気胸検出のための、特定臓器向けの疾患スクリーニングモデルをロードしたりすることができる。さらに、画像中の肺を分離することにより、放射線科医は他の臓器によって注意をそらされることなく、臓器のより明確な解剖学的描写を持つことができる。

【0344】

ユースケース － 加速ブラウジング

【0345】

加速ブラウジングは、ページ又は他のコンテンツを準備してユーザ装置に送るための、エッジにおけるウェブページ関連の前処理を指す。加速ブラウジングの例は、ウェブページレンダリング、広告ブロック、コンテンツ評価、及びこれらに類するものを含む。加速ブラウジングは、プロセッサーリソース集約的である（例えば、ＣＰＵ及びＦＰＧＡリソースを使用する）。

【0346】

エッジ加速ウェブは、エッジクラウドサービスが全スマートフォンユーザのために使用されることを可能にするユースケースである。ページロード時間は、通常のネットワークでは、サーバよりもフロントエンド処理の方が支配的である。ブラウザは例えばコンテンツの評価及びレンダリングなどの処理を実行する。これは、時間だけでなく電力も消費し、このことは、例えば携帯電話などの電力クリティカルなエンド装置にとって重大なことである。これらの処理をエッジで実行することにより、ユーザは、精緻なブラウジング体験を経験することができるとともに、自身の装置のバッテリ電力を節約することができる。処理は、広告ブロック、レンダリング、コンテンツ評価、ビデオトランスコーディングなどを含み得る。

【0347】

このユースケースは、待ち時間拘束されるものではないが、様々な要求が、エッジサーバに、処理が遅延して、それにより、ウェブページのロード時間を遅くすることがないようにさせ得る。特に、エッジサーバは、多数のＨＴＴＰリクエストを処理し、個々のリクエストに対して定められたＱｏＳを届けるように適応され得る。

【0348】

ユースケース：スピーチ分析

【0349】

言語ユーザインタフェース（ＬＵＩ）が、ユーザとインタフェースするより自然な方法として定着するのに伴い、より多くのスピーチ分析アプリケーションが我々全員に触れることになるであろう。Ｃｈａｔｂｏｔｓは一例である。以下にて、（エッジ）クラウド（サーバ用法）におけるスピーチ分析の例を提供する。

【0350】

一例において、２人の人物が２つの異なる言語で会話をしている。この会話音声使用には、音声を１つの言語のテキストに変換するボイス（又はスピーチ）認識、１つの言語のテキストを第２の言語のテキストに変換する機械翻訳、及びテキストを第２の言語の音声に変換するスピーチ合成という、幾つかの音声分析コンポーネントが関与する。関連する要求は、高品質、リアルタイム実行、及び低待ち時間を含む。

【0351】

スピーチ分析は、幾つかのユースケース分野にわたる多種多様なユーザインタフェースで使用され得る。例えば、スピーチ分析には幾つかの用途分野が存在する。用途分野は、以下に限られないが、デジタルアシスタント、バーチャルコールセンター、ヘルスケア及び（ソーシャル）メディア、自動車、及びセキュリティを含む。異なる用途分野に、幾つかの可能な用法が存在する。

【0352】

他の一例として、デジタルアシスタント分野には、ボイスメッセージ、ボイス検索、ボイスダイヤル、ボイスメモ、ボイスコマンド、ボイスナビゲート、及びボイスメールがある。

【0353】

他の一例として、バーチャルコールセンター分野には、テレコムセクター、金融セクター、小売セクター、保健セクター、運輸セクター、電子商取引セクター、おもてなしセクター、及びスピーチ分析が使用され得る他のセクターがある。

【0354】

他の一例として、ヘルスケア分野には、医学記録転写、医療アシスタント（例えば、チャットボット）、医学分析（例えば、テキスト、カルテ記入など）、音声認識を伴う電子健康記録などがある。

【0355】

他の一例として、（ソーシャル）メディアアプリケーション分野には、ボイスチャット、自動字幕生成（例えば、ＹＯＵＴＵＢＥ（登録商標）によって行われているような）、コンテンツ発見（音声入力に基づく検索）、言語翻訳、（可能なビジネス手段として）適切な広告をトリガするためのメディアトラフィックへの洞察、及びメディア要約がある。

【0356】

他の一例として、自動車分野には、ボイスコマンド、ボイスナビゲートなどがある。

【0357】

他の一例として、セキュリティ分野には、ボイス認識（例えば、生体認証セキュリティ）、ボイスパスワード、ボイス制御などがある。

【0358】

ここで説明される用途分野ごとに幾つかの用法があり、スピーチ分析のための幾つかの用途分野があるとしても、スピーチ分析のコアコンポーネントは、幾つもの分野にわたって使用され得る。コアコンポーネントは、１）自動音声認識（ＡＳＲ）、２）機械翻訳（ＭＴ）、３）テキスト音声変換（ＴＴＳ）、及び４）自然言語理解（ＮＬＵ）若しくは自然言語処理（ＮＬＰ）を含む。

【0359】

スピーチ分析において一般的に生じる用法の一部は、ＡＳＲ、ＭＴ、ＴＴＳ、ＮＬＰ、及びＢｉｏｍｅｔｒｉｃｓという、スピーチ分析からのプリミティブで構成される。これらの用法は、要求の点で様々であり得る。これらの用法の一般的な要求には、スループット（所与のハードウェアによって処理されることが可能な同時ストリームの数）、待ち時間（秒単位）、及び品質を含む。用法は、会話音声分析は１／２秒を超えるエンドツーエンド待ち時間を許容できないが、文章転写は、およそ数秒（２－４ｓ）の遅延を生じ得るといった、待ち時間に関して多種多様な要求を有し得る。全ての用法が、最高の品質（ＡＩ支援としてのスピーチ分析の受け入れのため）と最高のスループット（コスト効率的なソリューションを提供するため）とを求める要求を有する。

【0360】

スループット、待ち時間、及び品質の他に、数ＭＢから数百ＭＢ（現行技術に基づくが、サイズは増大する可能性が高い）まで及ぶことが期待されるモデルサイズ（語彙サイズにつながる）、サポートされる言語／方言／アクセント、データのプライバシー／セキュリティニーズ、及び画像／映像／オーディオ／音声／テキストデータの統合分析が行われる混合モード分析に関係する要求が存在し得る。さらに、エッジクラウドは、低語彙サイズ及び低待ち時間などの特別な目的のニーズに応え、従って、加速の恩恵を受ける可能性のある、ＣＰＵに対するアクセラレータの使用を駆り立て得る柔軟性対効率に関する要求が存在する。

【0361】

コンタクトセンターでＡＩ対応のスピーチ分析を提供するためには、ソリューションプロバイダが、金銭的コスト又はリソースコストを増加させることなく、高い性能及びスケーラビリティを提供する柔軟なプラットフォーム上に自身のＡＩベースのソリューションを展開することが重要である。Ｖｉｒｔｕａｌ Ｖｏｉｃｅ Ａｓｓｉｓｔａｎｔのエンドツーエンド展開は、ディープニューラルネットワークを用いるアルゴリズム、伝統的なスピーチ処理、グラフ処理、企業ソフトウェア統合などを含む多様なソリューションコンポーネントをひとまとめにする。このような展開のための効率的なプラットフォームアーキテクチャは、これらの作業負荷タイプにわたって主導的な性能を提供し、スループットではなく、リアルタイム待ち時間に適応し得る。このプラットフォームアーキテクチャは、展開環境に複雑さを増すことなくＡＩ対応スピーチ分析作業負荷に性能及びスケーラビリティの利益がもたらされるよう、ＡＩ推論展開に使用されるスケーラブルなＣＰＵ（例えば、Ｉｎｔｅｌ（登録商標）Ｘｅｏｎ（登録商標）スケーラブルＣＰＵ）によって提供され得る。

【0362】

スピーチ分析は、例えば連続音声認識（ＣＳＲ）、自然言語処理（ＮＬＰ）、音声合成（Ｔｅｘｔ－ｔｏ－Ｓｐｅｅｃｈ）、音声バイオメトリクスなどのテクノロジを含む。伝統的にスピーチ分析はオフラインで適用されてきた。例えば、マネジャが、顧客とのやりとりを記録し、少しの会話を選び出し、それらを調べ、そして、エージェントが会社のガイドラインをどれだけ遵守しているかを推測して、抜き取り検査していた。ＡＩベースのスピーチ分析は、企業がリアルタイムに応答することを可能にする。音声認識は、スピーチ分析とチームを組んで、組織がもっと多くの会話、更には１００％に至るまで、モニタすることを可能にする。先を見越すに、これらの支援サービスは、経験豊富なエージェントに電話を引き継ぐ前に、制約のない自然言語インタフェースにて顧客にセルフサービスを提供するボットアシスタントの道を開くことができる。

【0363】

スピーチ分析ユースケースは、例えばスマートスピーカ又はモバイルベースのボイスアシスタントのようなコンシューマ装置に見られる会話型インタフェースの要求に綿密に従うとしても、幾つかの特有の違いも存在する。コンタクトセンター用のスピーチ分析ソリューションは、非常に特定分野向けであまり汎用でない傾向がある。大抵のスピーチ分析ベンダーは、自身のソリューションを産業分野に基づいてカスタマイズするために柔軟性を組み込んでいる。また、それらのソリューションは複数の地域言語をサポートする必要がある。従って、展開されるアルゴリズムの多様性が相当なものとなり得る。

【0364】

ＩＩＩ．マルチステークホルダーエッジコンピューティングシステムのためのリソース割当て及び割当て解除の改良
さらなる例において、高度なリソース割当て及び割当て解除の方法が、多様なマルチステークホルダーエッジコンピューティング環境に拡張され得る。

【0365】

エッジハートビート例

【0366】

エッジ展開における考慮事項の１つはサービス保証である。エッジコンピューティングは、エッジサービス（例えば、サービスコーディネーティングエンティティ上で実行されるコンピューティングサービス）と情報を通信するネットワーク（又はエッジ）装置（例えば、ドローン、センサ、ユーザ機器（ＵＥ）、又は他のコンピューティング装置）が何万又は何十万と存在し得るという点で独特である。多数のネットワーク装置を有することにより、エッジ展開内で障害が発生する運命にある。例えば、センサはある一定の率で故障し得るものであり、そのような装置故障は、エッジサービスの実行可能性を評価するために考慮に入れられる必要があるが、エッジサービスは、ネットワーク装置を含む複数のソースからデータを収集している。

【0367】

以下のハートビート追跡技術は、サービス保証を容易にすることに関連して、エッジコンピューティングネットワーク（例えば、図３から図２２Ｄに示したエッジクラウド１１０及びエッジコンピューティングシステム構成）内の複数のエッジノード又はエッジ装置（例えば、ノード３０２、３１２、３２２）の装置接続性を管理するために、ハートビート、ビーコン、及び追跡の機能と共に使用されることができる。通常、「ハートビート」は、装置、サービス又はアプリケーションがダウンしている又は待ち時間の問題により応答していないときを追跡することに適用される。位置“ビーコン”は、装置、タワー、サーバなどが位置をブロードキャストするときに使用され、受信者は、三角測量又はその他を介してその位置を決定することができる。位置“追跡”は、ピアが訪問した位置のログを作成することができるように位置情報を共有する（又はそれを第三者から取得する）装置には適用される。ハートビートサービスの以下の説明は、これらのタイプの報告態様を、エッジコンピューティング環境に適用可能なハートビートのいっそうロバストなバージョンへと統合する。

【0368】

より具体的には、コンピューティングサービス（例えば、図７から図１２に関して図示して説明したエッジサービス及び機能）を実行するサービスコーディネーティングエンティティ（例えば、図７５から図７８に図示して説明するＭＥＣアーキテクチャに従って実装されるものなどの、マルチアクセスエッジコンピューティング（ＭＥＣ）ホスト）は、以下の機能のうちの１つ以上を実行するように構成されるエッジハートビートコンポーネントを含むことができる：十分な数のエッジ装置がアクティブであってコンピューティングサービスと通信していることをモニタ及び保証すること；エッジ装置が位置している場所を決定し、それら装置を追跡すること（例えば、エッジ装置がターンオンされているか、それともターンオフされているか、コンピューティングサービスとの通信に関してエッジ装置がアクティブであるか、それとも非アクティブであるか、エッジ装置が、装置位置、待ち時間、ジオフェンシングなどに基づいて、コンピューティングサービスと関連しているか）；及びコンピューティングサービスに関するサービス保証を管理することに関連して通知を提供すること（例えば、コンピューティングサービスに通信可能に結合されている、又はそれと能動的に通信しているエッジノードの数が、閾値数よりも少ない又は多いときに通知を提供する）。これらの通知は、メッセージ及びメッセージ交換、格納されたデータ値、インタフェース動作、及びこれらに類するものの形態で提供され得る。

【0369】

図２３は、一部の態様に従った、エッジハートビートコンポーネントによる通知に基づく、エッジノードの低接続性クラスタ及び接続性調整を例示している。図２３を参照するに、略図２３００は、低接続性構成２３０２にある複数のエッジノードを示している。より具体的には、エッジノード（図２３にドットとして示す）は、互いに結合され得るとともに、既存の（又はアクティブな）接続２３０６を介してサービスコーディネーティングエンティティ（例えば、図２３には示していないＭＥＣホスト）上で実行されているエッジサービスに結合され得る。図２３は更に、エッジノード間の可能な（又は非アクティブな）接続２３０８を示している。

【0370】

一部の態様において、エッジハートビートコンポーネント（例えば、図２５に関連して示す）が、エッジノードとエッジサービスとの間の接続の数、及びエッジノード同士間の接続の数をモニタし、接続数が接続性閾値を下回ったときに通知を生成するように構成される。

【0371】

図２３は、Ｋ＝２という接続性閾値の一例を示しており、接続性閾値は、エッジノード当たりのアクティブ接続の最大数を指し示す。低接続性構成２３０２は、例えば２３１０、２３１２、２３１４などの一部のエッジノードが、それら同士間又はエッジサービスとの間で単一のアクティブ接続を持つかアクティブ接続を持たないかであることに関連付けられる。エッジサービスに関する低接続性のエッジハートビートコンポーネント通知の後、接続性が調整され、エッジノードは、例えば２３１６、２３１８、２３２０などのそれぞれのネットワークノードがエッジサービスに対して又は別のノードに対して少なくとも１つのアクティブ接続又は２つのアクティブ接続を持つ通常接続性構成２３０４に移行する。しかし、一般化された証明機能は、ハートビートの結果が高い正確さ、セキュリティ、鮮明さなどを持つ場合に、心拍のような活性及びその他のフィードバックを供給し得る。

【0372】

図２４は、一部の態様に従った、エッジハートビートコンポーネントによる通知に基づく、エッジノードの高接続性クラスタ及び接続性調整を例示している。図２４を参照するに、略図２４００は、高接続性構成２４０２にある複数のエッジノードを示している。より具体的には、例えば２３１０－２３２０などのエッジノード（図２３にドットとして示す）は、互いに結合され得るとともに、既存の（又はアクティブな）接続２４０６を介してサービスコーディネーティングエンティティ（例えば、図２４には示していないＭＥＣホスト）上で実行されているエッジサービスに結合され得る。図２４は更に、エッジノード間の可能な（又は非アクティブな）接続２４０８を示している。

【0373】

一部の態様において、エッジハートビートコンポーネント（例えば、図２５に関連して示す）は、エッジノードとエッジサービスとの間の接続（例えば、ネットワーク動作、論理動作）の数、及びエッジノード同士間の接続の数をモニタし、接続数が接続性閾値を上回ったときに通知を生成するように構成される。

【0374】

図２４は、Ｋ＝２という接続性閾値の一例を示しており、接続性閾値は、エッジノード当たりのアクティブ接続の最大数を指し示す。高接続性構成２４０２は、一部のエッジノードが、それら同士間又はエッジサービス（図２４には示さず）との間で１つよりも多いアクティブ接続を持つことに関連付けられる。エッジサービスに関する高接続性のエッジハートビートコンポーネント通知の後、接続性が調整され、エッジノードは、それぞれのネットワークノードがエッジサービスに対して又は別のノードに対して少なくとも１つのアクティブ接続又は２つのアクティブ接続を持つ通常接続性構成２４０４に移行する。より更なる例において、このようなハートビートは、エッジノードのクラスタ（例えば、論理的又は物理的なグループ又はドメイン）内で展開され得る。

【0375】

図２５は、一部の態様に従った、エッジホスト内のエッジハートビートコンポーネントを使用するエッジ展開２５００の一例を示している。図２５を参照するに、エッジ展開２５００は、複数の基地局２５０４、２５０６、…、２５０８に結合された例えばＭＥＣホスト２５０２などのサービスコーディネーティングエンティティを含む。基地局は、それぞれ、例えば２５１０、…、２５１２、２５１４、…、２５１６、及び２５１８などの複数のエッジ装置に結合されることができる。（ＭＥＣホストが図示されているが、当該概念は固定又は非モバイルのエッジコンピューティングノードにも等しく適用可能である。）

【0376】

一部の例において、それぞれのエッジ装置２５１０、…、２５１２、２５１４、…、２５１６、及び２５１８は、直接的な通信リンク（例えば、図２５に示す破線）を介してＭＥＣホスト２５０２に通信可能に結合されてもよいし、対応する基地局を介してＭＥＣホスト２５０２に通信可能に結合されてもよい。一部の態様において、それぞれのエッジ装置は、複数の通信リンク（例えば、装置２５１４によって使用される通信リンク２５３６）を介してＭＥＣサービス２５２０を使用する１つ以上の他のエッジ装置に結合されてもよい。これに関連し、ハートビート情報を含め、情報は、エッジハートビートコンポーネント２５２２による使用のためにＭＥＣホスト２５０２に通信し戻すよう、装置から装置へと渡されることができる。

【0377】

一部の例において、ＭＥＣホスト２５０２は、例えばＭＥＣサービス２５２０などのエッジサービスを実行している。ＭＥＣサービス２５２０は、基地局２５０４、２５０６、２５０８並びにエッジ装置２５１０、…、２５１２、２５１４、…、２５１６、及び２５１８と、通信可能に結合されて情報を交換することができる。ＭＥＣホスト２５０２は更に、接続性モニタリング及び接続性保証に関連してここで説明される１つ以上の機能を実行するように構成された、好適な回路、インタフェース、及び／又は命令を有し得るエッジハートビートコンポーネント２５２２を含む。そのような機能は：装置ハートビートを構築することであり、装置ハートビート又はビーコンは、ＭＥＣサービス２５２０との通信に関する装置可用性（例えば、その装置がターンオンされていて通信に関してオンライン／利用可能であるか）を指し示す情報、装置位置（例えば、その装置が結合されている基地局に対する位置、又はＭＥＣホスト２５０２に対する位置）を指し示す情報、又は他の装置関連情報を含み得る、構築すること；ハートビート情報の一部として受信した位置情報（例えば、装置と結合された対応する基地局に関する位置情報）を基地局（又は他の装置）に伝搬すること；エッジ装置がダウンしている（例えば、ターンオフされている、又はその他で通信に利用可能でない）か否かを追跡すること；ＭＥＣサービスとの通信に利用可能である（又は利用可能でない）装置を記録すること；ジオフェンス機構を実装すること；などを含み得る。

【0378】

一部の態様において、ＭＥＣホスト２５０２は、エッジ装置のクラスタによる（例えば、ハートビート設定情報２５２４を介した）ハートビート報告を実装するように（例えば、モバイルネットワークオペレータによって）構成される。一例において、それぞれのクラスタは、ハートビートの周波数、ハートビート情報仕様などを（例えば、ハートビート設定情報２５２４を介して）設定される。一部の態様において、エッジハートビートコンポーネント２５２２は、ＭＥＣサービスが過大又は過少に加入／使用されていることの通知（例えば、モバイルオペレータへの）をトリガすべき時を決定する目的で、１つ以上の閾値パラメータ（例えば、図２３及び２４に関連して説明した閾値Ｋ）を設定される。

【0379】

ＭＥＣホスト２５０２がハートビート設定情報２５２４をエッジ装置に通信した後、ハートビート情報を周期的にＭＥＣホストに報告し戻すことができる。例えば、エッジ装置２５１４、…、２５１６は、対応するハートビート情報２５３２、…、２５３４を報告することができる。一部の例において、それぞれのエッジ装置は、ハートビート報告機能、ジオフェンス機能などを実装するための１つ以上のハードウェア及び／又はソフトウェアコンポーネントを（例えば、ネットワークインタフェースカード内に）含む。例えば、エッジ装置２５１８は、ＭＥＣホスト２５０２によって設定された通りにハートビート情報を報告するように構成されたハートビートコンポーネント２５３０を備えたネットワークインタフェースカード２５２８を含んでいる。

【0380】

一部の態様において、ＭＥＣホスト２５０２内のエッジハートビートコンポーネント２５２２は、ジオフェンス設定情報２５２６を用いて１つ以上のジオフェンスを構成することができる。例えば、エッジハートビートコンポーネント２５２２は、ジオフェンス設定情報２５２６を用いて、基地局２５０４の位置に関連付けられ得るものである第１のジオフェンス２５３８を構成することで、基地局２５０４と関連付けられた、ジオフェンス２５３８内の装置のみがＭＥＣサービス２５２０を使用することができるようにし得る。エッジハートビートコンポーネント２５２２は、他のエッジ装置（例えば、基地局２５０６）の位置に基づいた、そのジオフェンス内のエッジ装置をＭＥＣサービス２５２０を使用するように構成するために使用されることが可能な、例えばジオフェンス２５４０などの更なるジオフェンスを構成し得る。一部の態様において、ジオフェンスは、例えばＭＥＣホスト２５０２に対する近接性などの他の基準に基づいて構成され得る。より更なる例において、ＬＳＭ又は他のセキュリティポリシーがジオフェンスポリシーを記述することができ、ＭＥＣホスト、タワー、基地局、又は座標とジオフェンスを持つ他のノードが、ＬＳＭ強制ポイントとして機能することができる。

【0381】

さらなる例において、位置を証明することで、位置センサのＲｏＴ能力が位置座標におけるいっそう高い信頼性を確立し得るようにすることができる。従って、グローバルナビゲーション（例えば、ＧＰＳ）座標が、衛星がＲｏＴキー及び証明信号も含んでいて、衛星信号上で条件付きである場合に、証明された位置座標を報告して、ジオフェンスアクセス強制メカニズムに、より高い信頼性及び弾力性を与えることができる。

【0382】

エッジハートビートコンポーネント２５２２はＭＥＣホスト２５０２内に実装されるように図示されているが、この開示はこの点に関して限定されるものではなく、エッジハートビートコンポーネントは、例えば図２５に示される基地局のうちの１つ以上の中など、１つ以上の他のエッジ装置内に実装されてもよい。

【0383】

一部の例において、それぞれの基地局（２５０４、…、２５０８）又はＭＥＣホスト２５０２は、レポートする頻度及びアラームをトリガするのに使用され得る閾値の設定を含め、エッジ装置のグループにハートビート又はビーコンを実装するように構成され得る。

【0384】

一部の例において、エッジハートビートコンポーネント２５２２は、受信したハートビート情報を用いて、エッジ展開２５００内のエッジ装置に関連する以下の情報、すなわち、装置ＩＤ、基地局ＩＤ（特定された装置に関連付けられた基地局について）、セントラルオフィス（ＣＯ）ＩＤ（特定された装置に関連付けられたＣＯについて）、接続された装置ＩＤリスト（例えば、特定された装置に接続されたエッジ装置のＩＤのリスト）など、を追跡するように構成され得る。一部の態様において、エッジハートビートコンポーネント２５２２は、１つ以上のブルームフィルタ（又は他のソフトウェア若しくはハードウェア構造）を用いて、そのような追跡機構を実装し得るとともに、接続性評価に関連してハートビート処理機能のうちの１つ以上を実行することを支援し得る。

【0385】

一部の例において、ここに開示される技術は、エッジ／ＭＥＣ環境コンテキスト（例えば、図７５－図７８に図示して説明するＭＥＣ／５Ｇアーキテクチャに従って実装されるものなど）において、アクセスエッジとクラウドエッジとの間のギャップに架かるエッジノードのシステムが、エッジからエッジへのパス（又は複数のパス）が存在することを確実にするように適用されることができる。そのような機能は、エッジクラウドインスタンス（例えば、図３から図２２Ｄに示したエッジクラウド１１０及びエッジコンピューティングシステム構成）におけるサービス中断又はリソース中断（例えば、ブラウンアウト）が、先を見越して検出されないという可能性を防止する。

【0386】

一部の例において、ハートビート報告は、それぞれの装置が所定の周波数で周期的にハートビート情報を報告するように構成され得る。一部の例において、それぞれの基地局又はＭＥＣホスト（例えば、エッジハートビートコンポーネントを備えて構成された装置又は複数の装置）は、エッジネットワーク内のそれぞれのエッジ装置からのハートビート情報を周期的にポーリング（又は要求）することができる。

【0387】

さらなる例において、エッジコンピューティングネットワーク内の複数のエッジノードの装置接続性を管理するための技術に関する方法が、エッジハートビートコンポーネントを使用して実装され得る。一部の態様において、当該方法は、エッジコンピューティングネットワーク内の複数のエッジノード（例えば、２５１０、…、２５１８）と通信するエッジサービス（例えば、ＭＥＣサービス２５２０）を実行するサービスコーディネーティングエンティティ（例えば、ＭＥＣホスト２５０２）のエッジハートビートコンポーネント（例えば、２５２２）によって実行され得る。第１の動作にて、ハートビート設定情報（例えば、２５２４）が、複数のエッジノードへの送信のために符号化され、該ハートビート設定情報が、装置ハートビート情報を報告することを設定する。第２の動作にて、ハートビート設定情報に基づいて複数のエッジノードから受信した装置ハートビート情報が復号される。第３の動作にて、装置ハートビート情報に基づいて、複数のエッジノードのうちのコンピューティングサービスに接続されているエッジノードの数が決定される。第４の動作にて、決定されたエッジノードの数に基づいて、コンピューティングサービスに対する装置接続性を指し示す通知が生成される。例えば、エッジサービスを使用しているエッジノードの数が閾値数よりも多いと判定された場合、警告が生成され得る。エッジコンピューティングネットワーク内の装置接続性を管理してサービス保証を支援するために、他のタイプの警告又は通知も、受信したハートビート情報に基づいて生成され得る。

【0388】

エッジハートビートを実装する方法の第１の例（例Ａ１）は、エッジコンピューティングネットワーク（例えば、エッジクラウド１１０、及び例えばノード又は装置２２００、２２３２、２２４０、又は２２５０上で実装されるものなどのシステム及び装置を実装する）複数のエッジノードの装置接続性を管理する方法であり、当該方法は：エッジコンピューティングネットワーク内の複数のエッジノードと通信するコンピューティングサービスを実行するサービスコーディネーティングエンティティの１つ以上のプロセッサによって：複数のエッジノードへの通信のために、ハートビート設定情報を符号化し、該ハートビート設定情報は、装置ハートビート情報を報告することを設定するものであり；ハートビート設定情報に基づいて複数のエッジノードから受信した装置ハートビート情報を復号し；装置ハートビート情報に基づいて、複数のエッジノードのうち、コンピューティングサービスに接続されているエッジノードの数を決定し；そして、決定したエッジノードの数に基づいて、コンピューティングサービスに関する装置接続性を指し示す通知を生成する、ことを有する。

【0389】

第２の例（例Ａ２）において、例Ａ１に係る事項は、サービスコーディネーティングエンティティの１つ以上のプロセッサによって：コンピューティングサービスに接続されているエッジノードの数が閾値数よりも少ないときに通知を生成する、ことを含む。

【0390】

第３の例（例Ａ３）において、例Ａ１－Ａ２に係る事項は、装置ハートビート情報が、複数のエッジノードのうちのそれぞれのノードに関する装置位置情報を含む、ことを含む。

【0391】

第４の例（例Ａ４）において、例Ａ３に係る事項は、装置位置情報が、サービスコーディネーティングエンティティに対する又は複数のエッジノード及びサービスコーディネーティングエンティティと通信可能に結合された基地局に対する位置情報を含む、ことを含む。

【0392】

第５の例（例Ａ５）において、例Ａ４に係る事項は、ハートビート設定情報が、装置ハートビート情報を報告する頻度を設定する、ことを含む。

【0393】

第６の例（例Ａ６）において、例Ａ１－Ａ５に係る事項は、複数のエッジノードのうちの少なくとも１つのエッジノードから受信される装置ハートビート情報が、該少なくとも１つのエッジノードによって送信されるデータパケットの送信時間を指し示すデータパケットを含む、ことを含む。

【0394】

第７の例（例Ａ７）において、例Ａ６に係る事項は、サービスコーディネーティングエンティティの１つ以上のプロセッサによって：送信時間と、データパケットがサービスコーディネーティングエンティティによって受信された時間とに基づいて、上記少なくとも１つのエッジノードとサービスコーディネーティングエンティティとの間の通信待ち時間を決定し；そして、少なくとも、決定した通信待ち時間に基づいて、通知を生成する、ことを含む。

【0395】

第８の例（例Ａ８）において、例Ａ３－Ａ７に係る事項は、サービスコーディネーティングエンティティの１つ以上のプロセッサによって：コンピューティングサービスに関連するジオフェンスを構成する、ことを含む。

【0396】

第９の例（例Ａ９）において、例Ａ８に係る事項は、サービスコーディネーティングエンティティの１つ以上のプロセッサによって：装置ハートビート情報に基づいて、複数のエッジノードのうちの、構成されたジオフェンスの外側にあるエッジノードの数を決定し；そして、少なくとも、決定した、構成されたジオフェンスの外側にあるエッジノードの数に基づいて、通知を生成する、ことを含む。

【0397】

第１０の例（例Ａ１０）において、例Ａ１－Ａ９に係る事項は、マルチアクセスエッジコンピューティング（ＭＥＣ）ホストとしてのサービスコーディネーティングエンティティが、サービスコーディネーティングエンティティの仮想化インフラストラクチャ上でインスタンス化されたＭＥＣアプリケーションとしてコンピューティングサービスを実行する、ことを含む。

【0398】

第１１の例（例Ａ１１）において、例Ａ１０に係る事項は、ＭＥＣホストが、欧州電気通信標準化機構（ＥＴＳＩ）ＭＥＣ標準ファミリーからの標準に従って動作するように構成される、ことを含む。

【0399】

様々な環境において、例Ａ１－Ａ１１（及びこのエッジハートビートユースケースの他の態様）は、ハートビートの使用を規定するＡＰＩ又は仕様；ハートビートの使用を規定する又は伴うプロトコル；及び以下の例（例えば、例Ｂ１－ＡＡ１１）でのハートビートの他の使用及び実装、の結果として観察又はモニタされ得る。例Ａ１－Ａ１１及びハートビートの他の態様はまた、サービス操作及びサービス機能の結果として観察又は実装され得る（例えば、ＦａａＳ又はＥａａＳ環境において起動又は動作されるように、そのようなＦａａＳ又はＥａａＳ要素は、エッジクラスタ内の計算要素上で実行されるように、又はＳＬＡの目的及び義務又はエッジクラスタの他の義務を達成するように機能するエッジクラスタと通信する何らかの計算要素によってサービスされるように、設計されたコードエレメントで構成される）。さらに、例Ａ１－Ａ１１の方法は、実装された命令として（例えば、命令が実行されるときに方法を実行する機械読み取り可能な媒体で）、又は実装されたハードウェア構成として（例えば、方法を実行又は達成するための構成を含む装置で）エッジコンピューティングシステムに提供され得る。従って、例Ａ１－Ａ１１（及びハートビートサービス）の特徴は、システムオーケストレータ又はアーキテクトによって連携又は設計されるように、エッジクラスタ又はエッジクラウドシステムを構成するために、ここでの他の例のうちのいずれかと組み合わされ得る。

【0400】

追跡可能なデータ移動の例

【0401】

エッジ展開には大きなダイナミクスがあり、従って、そのような展開における考慮事項の１つはサービス保証及びデータ証明である。エッジコンピューティングは、エッジサービス（例えば、図７から図１２に関連して図示して説明したエッジサービス及び機能に関して上述したものなどのサービスコーディネーティングエンティティ上で実行されるコンピューティングサービス）と情報を通信するネットワーク（又はエッジ）装置（例えば、ドローン、センサ、ユーザ機器（ＵＥ）、又は他のコンピューティング装置）が何万又は何十万と存在し得るという点で独特である。多数のネットワーク装置を有することにより、任意のインスタンスにて様々なタイプ及び量の情報が装置間で交換される。例えば、センサは、異なるタイプの情報を継続的にエッジに送り得る。発生するキーとなる課題は、信頼の問題、すなわち、エッジインフラストラクチャへの途中で幾つかの中間ホップを流れ抜け得るデータのソースを信頼するための手段を保ちながら、情報を送信する何千もの装置をエッジインフラストラクチャがどのように取り扱い得るのかということである。

【0402】

ここに開示される技術は、エッジクラウド（例えば、図３から図２２Ｄに示したエッジクラウド１１０及びエッジコンピューティングシステム構成）においてデータ証明を処理するために使用され得る。より具体的には、開示される技術は、エッジ装置及びインフラストラクチャに、データ転送を伴うイベントのフローを追跡するのに必要なフックを提供するために使用され得る。例えば、これは、幾つかの他のこのようなストリームを同時に処理しながら（従って、作業負荷データを関連する計算リソースに動的に移動させながら）、センサＡがゲートウェイＢへ、ハブＣへ、エッジサーバＤへデータを送るための信頼あるメカニズムを備え得る。

【0403】

図２６は、一部の態様に従った、エッジノード（例えば、ノード３０２、３１２、３２２の実装）の間のデータフローの一例を示している。図２６を参照するに、エッジコンピューティングネットワーク２６００内の複数のエッジノード２６０２の間でのデータ通信交換が例示されている。より具体的には、エッジノード２６０２（エッジネットワーク装置Ａ－Ｉを含むことができる）は、データフローパス２６０４（エッジノード２６０２間のエッジとして示される）を介してデータを交換する。

【0404】

一部の態様において、エッジコンピューティングネットワーク２６００内の複数のネットワークデスティネイション位置にエッジルックアップテーブルがキャッシュされ得る。図２７のＬＵＴ２７２８と同じとし得るものであるエッジルックアップテーブル（ＬＵＴ）は、エッジノード２６０２のそれぞれのノードに関する認証情報を含むことができる。例えば、ＬＵＴは、エッジコンピューティングネットワーク２６００内の認証されたエッジノード、エッジノードのそれぞれのノードに関する認証信任状、及びデータ証明のために使用され得る他の認証情報をリストアップすることができる。一部の態様において、ＬＵＴは、図２７（例えば、図７５から図７８に図示して説明するＭＥＣアーキテクチャに従って実装される）に示されるように、例えばＭＥＣホストなどのサービスコーディネーティングエンティティを介してエッジノードに供給され得る。

【0405】

一部の態様において、ＬＵＴは、それを通して各データ通信ホップにて情報がソースに帰属される参照メカニズムとして使用されることができる。例えば、データがエッジノード間で通信されるとき、データパケットは、例えば、データが横切ったエッジノードを明記するエッジハンドルを含むことができる。例えば、ある量のデータは、ＩＤ Ａ→Ｂ→Ｃ→Ｄを有するエッジノードがそのパケットを伝送したことを指し示すエッジハンドルを有することができ、そして、ＬＵＴを用いて、エッジハンドルによって明記されたエッジノードのうちの１つ以上が、エッジコンピューティングネットワーク２６００内でのデータ交換に関して認証されているかを判定することができる。一例において、フローパス内の各ノードは、特にフロー指向セキュリティポリシー又はセキュリティ機能の使用を伴った、ＬＳＭ又は他のセキュリティポリシー強制ポイントとすることができる。

【0406】

ノードが認証されていない、又はエッジハンドルによって示される通信交換に関するデータ証明が失敗したと判定すると、通知／警告が生成されてエッジコンピューティングネットワーク内で通信され得る。さらなる例において、情報中心ネットワーキング（information centric networking；ＩＣＮ）の機能が、エッジコンピューティングネットワーク２６００又は２７００内での使用のために含められ又はそれに適応され得る。

【0407】

図２７は、一部の態様に従った、エッジコンピューティングネットワーク内でのデータの証明に関する技術を例示している。図２７を参照するに、エッジ計算ネットワーク２７００は、複数のエッジノード（又はエッジ装置）２７０４、２７０６、２７０８、…、２７１０（例えば、ノード３０２、３１２、３２２の実装）に結合されたエッジ計算ホスト２７０２（例えば、ＭＥＣホスト）を含んでいる。

【0408】

一部の態様において、エッジコンピューティングネットワーク２７００は、データが改ざんされないこと、及び参加するエッジノードがデータ交換のために認証されることを確実にするために、エッジノード間でデータが通信されるときに例えばハードウェア又はソフトウェアフックを使用するなど、信頼あるフロー伝送のためのメカニズムを使用することができる。一部の態様において、複数のエッジ間又はエッジ装置間の通信を含むデータの移動（例えば、データを受信又は送信すること）に関連するそれぞれのネットワーク位置（例えば、エッジノード２７０４、…、２７１０）において、データペイロードがハッシュされ得るとともに、オプションのタイムスタンプが含められ得る。例えば、一部の態様において、エッジノード２７０４を発信元とするデータパケット２７１６は、ハッシュされることができ、又は信頼あるネットワークキー（例えば、エッジコンピューティングネットワーク２７００内の認証されたエッジノードに通信され得るトラステッドキー）でエンコードされることができる。データパケットが他のエッジ装置（例えば、２７０６、…、２７１０）へと横断するとき、それぞれのエッジノードは、データをデコードし、追加の情報を付加し（例えば、データパケットのデータペイロードに添えられたエッジハンドルに、ソースエッジ装置ＩＤ、それまでにデータフローに参加したエッジ装置の装置ＩＤ、各ホップでデータが受信若しくは送信される時のタイムスタンプ情報、及びその他の情報を付加し）、データパケットを再エンコードし、次の装置へと転送することができる。これに関連して、データパケットがエッジサービス（例えば、エッジ計算ホスト２７０２によって実行される）又はターゲットデスティネーションに到着すると、各ホップの受信エッジノードは、データパケットがどこから来たのか、データパケットがデータフローパス内の各装置によっていつ受信若しくは送信されたのか、どの装置がデータフローパス内にあるのか、及びその装置はエッジコンピューティングネットワーク２７００内での通信に関して認証されているのか、並びにデータ証明のための他の認可及び認証処理機能をチェックすることができる。一部の態様において、各データパケットとともに通信されるデータ（例えば、エッジハンドル）は、メッセージが転送されるときにデバッグ目的で使用され得る。

【0409】

一部の態様において、図２７に例示するように、パケットが発信元（ソース）エッジ装置から宛先装置へと移動するときに、エッジハンドルをデータペイロードに付加してデータパケットを形成することができる。例えば、エッジ装置Ａによって認証されたデータを装置Ｂが受信する場合、装置Ｂは、自身を認証し得るとともに、データソースとしてＡを含め、この情報をエッジハンドルとパッケージングすることで、エッジ装置Ｃに転送されるデータパケットを形成する。次いで、エッジ装置Ｃが、ＡからＢからＣへのフローを認証し、更新されたエッジハンドルを生成し、該データパケットをエッジ装置Ｄに転送する。

【0410】

一部の態様において、エッジ装置の証明／認証のプロセスは、ブロックチェーンテクノロジ又は他のタイプの追跡若しくは認証技術に基づき得る。一部の態様において、それぞれのエッジハンドルは、ソースエッジ装置ＩＤ及びデータフローパス（例えば、データパケットを通信することに参加した又は参加している各装置に関する装置識別情報）を含むことができる。一部の態様において、データフローパスに参加している指し示された装置のうちの１つ以上についてタイムスタンプも含められ得る（例えば、タイムスタンプは、データがデータフローパスの一部である対応するエッジ装置から送信される又はそれにて受信される時を指し示す）。

【0411】

図２７の具体例を参照するに、データパケット２７１６は、ソースエッジノード２７０４を起源として、それによって生成される。データパケット２７１６は、データペイロードに添えられてデータパケット２７１６を形成するエッジハンドル２７１５を含む。エッジハンドル２７１５（すなわちＥＨ１）は、例えば、発信元（ソース）エッジ装置のエッジ装置ＩＤ（例えば、データパケット２７１６のソース装置であるエッジ装置２７０４の識別子）並びにデータパケットのための現在データフローパスを形成するエッジ装置の装置識別子などの、情報２７２２を含むことができる。この装置はソース装置であるため、エッジハンドル２７１５内のデータパスは、ノード２７０４のみの識別情報を含む。

【0412】

データパケット２７１６が生成された後、エッジノード２７０４は、該データパケットを、例えばエッジノード２７０６などの通信パス内の次の装置に送信する。パケットがエッジノード２７０６で受信された後、エッジノード２７０６は、エッジノード２７０６の識別情報を含むようにデータフローパスを更新することによって、（例えば、ＥＨ２に）エッジハンドル２７２４を更新する。例えば、エッジハンドルＥＨ２内のデータフローパスは、データパケットがエッジ装置Ａ（２７０４）を起源とし、そしてエッジ装置Ｂ（２７０６）で受信されていることを示す「Ａ－Ｂ」を指し示すことができる。エッジノード２７０６がエッジハンドルを更新してＥＨ２を生成した後、ＥＨ２がデータペイロードに添えられて新たなデータパケット２７１８を形成し、それが、例えばノード２７０８などのデータフローパス内の続くエッジ装置に通信される。

【0413】

パケットがエッジノード２７０８で受信された後、該ノードは、エッジ装置２７０８の識別情報を含むようにデータフローパスを更新することによって、（例えば、ＥＨ３に）エッジハンドル２７２６を更新する。例えば、エッジハンドルＥＨ３内のデータフローパスは、データパケットがエッジノードＡ（２７０４）を起源とし、エッジノードＢ（２７０６）によって転送され、そしてエッジノードＣ（２７０８）で受信されていることを示す「Ａ－Ｃ」を指し示すことができる。エッジノード２７０８がエッジハンドルを更新してＥＨ３を生成した後、ＥＨ３がデータペイロードに添えられて新たなデータパケット２７２０を形成し、これが、例えばデバイス２７１０などのデータフローパス内の続くエッジ装置に通信される。また、データフロー、証明フロー、又は他のフローグラフアクティビティが、エッジテレメトリ又はメタデータとしてモニタ、分析、及び推論されるように、監査人、コンプライアンスエンティティ、又は第三者が、パブリッシュサブスクライブ又は他の類似の分散メッセージングシステムに従ってＥＨ値に署名してもよい。

【0414】

一部の例において、また、上述したように、それぞれのエッジ装置がエッジハンドルを更新するとき、エッジハンドルに同様にタイムスタンプ情報を含めることができる。エッジコンピューティングネットワーク２７００内のエッジ装置間の同期したクロックデータを確実にするために、エッジ計算ホスト２７０２は、同期コンポーネント２７１４を備えて構成され得る。同期コンポーネント２７１４は、好適な回路、インタフェース、及び／又は命令を有することができ、エッジ装置間でのクロック同期を支援するために同期信号を（例えば、エッジコンピューティングネットワーク２７００内で通信する権限のある全てのエッジ装置に、ブロードキャストメッセージを介して）通信するように構成される。

【0415】

一部の例において、エッジ計算ホスト２７０２は、エッジＬＵＴコンポーネント２７１２を備えて構成される。エッジＬＵＴコンポーネント２７１２は、好適な回路、インタフェース、及び／又は命令を有することができ、（例えば、図２６に関連して述べたような）ＬＵＴを生成して維持管理するように構成され、そのＬＵＴ（例えば、ＬＵＴ ２７２８）が、エッジコンピューティングネットワーク２７００内のエッジ装置が装置認証及びデータ証明目的のためにそのようなＬＵＴを使用できるように、全てのエッジ装置に（例えば、装置２７０４、、２７１０へのブロードキャストメッセージを介して）投入され得る。

【0416】

さらなる一例において、データの証明のための技術を実装する方法が、エッジコンピューティングネットワーク内に実装され得る。この技術は、エッジコンピューティングネットワーク（例えば、２７００）内の複数のエッジ装置のうちの第１のエッジ装置（例えば、２７０６）の１つ以上のプロセッサによって実行され得る。第１の動作にて、複数のエッジ装置のうちの第２のエッジ装置（例えば２７０４）から受信したデータパケット（例えば２７１６）がデコードされる。データパケットは、データペイロード及び第１のエッジハンドル（例えば、ＥＨ１）を含んでいる。第１のエッジハンドルは、ソースエッジ装置（例えば、装置２７０４又はＡ）と、データペイロードに関連付けられたデータフローパスとを指し示す。第２の動作にて、ソースエッジ装置（例えば、Ａ）と更新されたデータフローパス（例えば、装置２７０４及び２７０６に関するエッジ装置識別子）とを含むように、第２のエッジハンドル（例えば、ＥＨ２）が生成される。これに関連し、ＥＨ２内の更新されたデータフローパスは、上記データフローパス（例えば、装置Ａのみである、ＥＨ１によって指し示されるデータフローパス）及び第１のエッジ装置（すなわち装置Ｂ）の装置ＩＤに基づく。第３の動作にて、第２のエッジハンドル及びデータペイロードが、複数のエッジ装置のうちの第３のエッジ装置（例えば、２７０８）への送信のためにエンコードされる（例えば、データパケット２７１８として）。

【0417】

これらの例によって示されるように、エッジクラウド内には、多くのデータプロバイダが、データプロバイダからのデータに対して変換を実行する多くのエッジ計算サービス（例えば、図７から図１２に関連して図示して説明したエッジサービス及び機能）とともに存在する。ロバストなサービス環境を可能にするために、エンドポイント装置（及びエッジノード）は、データ提供者とデータを処理しているエッジサービスとの双方を検証（証明）する能力と共に、変換されたデータへのアクセスを必要とすることになる。

【0418】

一例において、エッジ計算サービスの結果又は使用のために、エッジコンピューティングシステム内でデータ及びデータ変換証明が可能にされる。例えば、データ提供者が認証済みデータをエッジサービスに送信するとき、エッジサービスは、そのデータが信頼できるソースを起源としていることを証明することができる。エッジサービスが変換（エッジサービスが実行することができ、且つ実行する能力又は権限を持つ）を適用するとき、エッジサービスの結果が認証される。結果として、データのソースとデータの変換との双方を検証しながら、エッジサービスから得られたデータがエンドポイント装置によって消費され得る。

【0419】

単純な一例として、車両からのカメラが画像をセルタワー又は他の無線アクセスポイントに送信し、そして、エッジサービスが画像に対して低待ち時間の車両又は物体検出処理を実行するというシナリオを考える。このデータのユーザは、物体検出結果を受信するときに、画像が信頼あるカメラによって提供されたこと、及び加えて、物体検出分析が信頼あるエンティティによって実行されたことを検証することができる。

【0420】

一部の状況では、データが単にエッジコンピューティングシステム内の中間処理段階／ノードに現れる得るので、カメラ又はデータの起源がどこであるのかわからないことがある。この処理は、中間ノードが（現在のノードコンテキストに先立って）データが不明の起源を持つことを指し示すときに証明コンテキストを含む。従って、証明情報は、ビジュアルデータが複数のホップによってトランスコード／変換されるときに、エンドポイントとエンドポイントを結ぶパスとの組み合わせを含み得る。

【0421】

データ及びデータ変換証明の使用は、規格又は仕様によって規定されたデータを含む相互運用可能な証明データを介して可能にされ得る。証明インフラストラクチャにとって重要なのは、（１つ以上の）検証者が、（直接だけでなく）間接的にもインタラクトされるリソースを発見できることである（例えば、各データ変換アクションが異なる組のノード及び変換ロジックを含んでいたかもしれないため）。中間アクションの証明は、記憶され、その後のクエリに利用可能にされ得る。例えば、データ及びコード「信頼」が暗号ハッシュとして表現され得る。証明済みリソースのハッシュツリーを用いて、それに先立つ全てのものの現在の「受け入れられた」証明値を維持することができる。中央集権アプローチは、ハッシュツリー更新を維持管理し、クエリに最適化されたコピーを「証明キャッシュ」として複製する。分散アプローチは、ブロックチェーンを利用し得る。

【0422】

データ及びデータ変換証明のコンテキストでは、「証明可能なもの」及びプロパティの豊富な辞書が定義され得る。この辞書リストは、タグ名が証明可能なものを識別し、値がその「測定値」（例えば、ハッシュ）であるタグ－値ペアのセットと同じ単純さであり得る。予め定められたリストがこれらの値の一部を含み得る一方で、ユーザコミュニティも、証明を必要とする特定のアプリケーション向けのリソースのタグを規定し得る。例えば、エッジコンピューティングシステム内のあるステークホルダーが所有するセキュリティカメラが、画像に関するメタデータ（例えば、ＥＸＩＦ）を識別し得る一方で、カメラの製造者又はベンダーが、カメラが首尾よく合格したテストスイートに関する情報を含む証明書を発行し得る。

【0423】

データを追跡するために使用されるタイムスタンプは、同期したクロックを必要とし得るものであり、これは、分散システムにとって難題であり得る。しかしながら、追跡の目的では、イベントのタイミングはキャプチャせずに、イベントのシーケンスをキャプチャするのみで十分であり得る。ブロックチェーンは順序付けを強いるので（ブロックチェーン順序が実際の順序と異なることはあり得るが、このユースケースは実際の正確な順序付けを必要としないとし得る）、ブロックチェーンは、タイミングなしで追跡を達成する一手法である。順序付け追跡の使用では、オーケストレーション又はワークフロー計画をメトリックとして使用し得る。何故なら、それは、意図された順序付けを記述するからである。しかしながら、より単純な例において、ユースケースの焦点が犯罪科学的な目的（例えば、紛争を解決するため、又は攻撃の病理を特徴付けるため）である場合、ローカルプラットフォームのクロックを使用することで十分であり得る（特に、例えば、ローカルクロックに対する変更がブロックチェーンに記録される、及びプラットフォームへの／からのデータフローがブロックチェーンに記録されるなど、前提条件が満たされる場合）。

【0424】

追跡可能なデータ移動を実装する方法の第１の例（例Ｂ１）は、エッジコンピューティングネットワーク（例えば、エッジクラウド１１０、及び例えばノード又は装置２２００、２２３２、２２４０、又は２２５０上で実装されるものなどのシステム及び装置を実装する）内でのデータ証明のための方法であり、当該方法は：エッジコンピューティングネットワーク内の複数のエッジ装置のうちの第１のエッジ装置の１つ以上のプロセッサによって：複数のエッジ装置のうちの第２のエッジ装置から受信したデータパケットをデコードし、該データパケットはデータペイロード及び第１のエッジハンドルを含み、該第１のエッジハンドルは、ソースエッジ装置と、データペイロードに関連付けられたデータフローパスとを指し示し；ソースエッジ装置及び更新されたデータフローパスを含むように第２のエッジハンドルを生成し、該更新されたデータフローパスは、上記データフローパスと、第１のエッジ装置の装置ＩＤとに基づき；そして、第２のエッジハンドル及びデータペイロードを、複数のエッジ装置のうちの第３のエッジ装置への送信のためにエンコードする、ことを有する。

【0425】

第２の例（例Ｂ２）において、例Ｂ１に係る事項は、ソースエッジ装置が、データペイロードの通信を開始すること、及びデータフローパスが、複数のエッジ装置のうちの、データペイロードを通信するのに使用されるサブセットを指し示す、ことを含む。

【0426】

第３の例（例Ｂ３）において、例Ｂ２に係る事項は、第１のエッジ装置の１つ以上のプロセッサによって：データフローパスを用いて、複数のエッジ装置のうちの上記サブセット内のそれぞれのエッジ装置に関する装置ＩＤを決定する、ことを含む。

【0427】

第４の例（例Ｂ４）において、例Ｂ３に係る事項は、第１のエッジ装置の１つ以上のプロセッサによって：決定した装置ＩＤ及び装置認証ルックアップテーブルに基づいて、データフローパスに含まれる複数のエッジ装置のうちの上記サブセットを認証する、ことを含む。

【0428】

第５の例（例Ｂ５）において、例Ｂ４に係る事項は、第１のエッジ装置の１つ以上のプロセッサによって：複数のエッジ装置のうちの上記サブセットのうち少なくとも１つのエッジ装置が認証に失敗したときに通知を生成する、ことを含む。

【0429】

第６の例（例Ｂ６）において、例Ｂ４－Ｂ５に係る事項は、第１のエッジ装置の１つ以上のプロセッサによって：エッジコンピューティングネットワーク内のサービスコーディネーティングエンティティからの装置ブロードキャストメッセージをデコードし、装置ブロードキャストメッセージが、装置認証ルックアップテーブルを更新する、ことを含む。

【0430】

第７の例（例Ｂ７）において、例Ｂ６に係る事項は、装置ブロードキャストメッセージが更に、エッジコンピューティングネットワーク内の複数のエッジ装置間でのセキュア通信のための少なくとも１つの認証キーを含む、ことを含む。

【0431】

第８の例（例Ｂ８）において、例Ｂ７に係る事項は、エンコードすること及びデコードすることは、少なくとも１つの認証キーに基づく、ことを含む。

【0432】

第９の例（例Ｂ９）において、例Ｂ６－Ｂ８に係る事項は、第１のエッジ装置の１つ以上のプロセッサによって：装置ブロードキャストメッセージ内のクロック同期信号に基づいて第１のエッジ装置の装置クロックを同期させる、ことを含む。

【0433】

第１０の例（例Ｂ１０）において、例Ｂ９に係る事項は、第１のエッジ装置の１つ以上のプロセッサによって：第１のエッジ装置のタイムスタンプを更に含むように第２のエッジハンドルをエンコードし、該タイムスタンプは、データペイロードが第３のエッジ装置に送信される時間を指し示す、ことを含む。

【0434】

第１１の例（例Ｂ１１）において、例Ｂ６－Ｂ１０に係る事項は、サービスコーディネーティングエンティティが、サービスコーディネーティングエンティティの仮想化インフラストラクチャ上でインスタンス化されたＭＥＣアプリケーションとしてコンピューティングサービスを実行するマルチアクセスエッジコンピューティング（ＭＥＣ）ホストである構成、を含む。

【0435】

第１２の例（例Ｂ１２）において、例Ｂ１１に係る事項は、ＭＥＣホストが、欧州電気通信標準化機構（ＥＴＳＩ）ＭＥＣ標準化ファミリーからの標準に従って動作するように構成される構成、を含む。

【0436】

第１３の例（例Ｂ１３）において、例Ｂ１－Ｂ１２に係る事項は、エッジコンピューティングネットワーク内のエッジサービスの結果が、エッジサービスに提供されるデータのソース及びエッジサービスによって生成される該データの結果の検証可能証明に基づいて証明可能であることを可能にする構成、を含む。

【0437】

様々な環境において、例Ｂ１－Ｂ１３（及びこの追跡可能なデータ移動ユースケースの他の態様）は、データ追跡構成を規定するＡＰＩ又は仕様；データ追跡構成を規定する又は伴うプロトコル；及びエッジコンピューティング環境内での追跡可能データの他の使用及び実装、の結果として観察又はモニタされ得る。例Ｂ１－Ｂ１３及びデータ追跡の他の態様はまた、（例えば、ＦａａＳ又はＥａａＳ環境において起動又は動作されるように）サービス操作及びサービス機能から観察又は実装され得る。さらに、例Ｂ１－Ｂ１３の方法は、実装された命令として（例えば、命令が実行されるときに方法を実行する機械読み取り可能な媒体で）、又は実装されたハードウェア構成として（例えば、方法を実行又は達成するための構成を含む装置で）エッジコンピューティングシステムに提供され得る。従って、例Ｂ１－Ｂ１３の特徴（及び追跡可能データ移動管理の他の特徴）は、システムオーケストレータ又はアーキテクトによって連携又は設計されるように、エッジクラスタ又はエッジクラウドシステムを構成するために、ここでの他の例のうちのいずれかと組み合わされ得る。

【0438】

グローバルに共有される／サブスクライブ可能な分散エッジキューの例

【0439】

ここで説明されるオーケストレーション及びサービス動作を連携させ及び編成するために、エッジコンピューティングプラットフォーム（例えば、図３から図２２Ｄに示したエッジクラウド１１０及びエッジコンピューティングシステム構成）内で、キューを処理する様々な形態が使用され得る。様々なタイプのコンピューティングシステムが、実行されるべきジョブ又は機能を格納するためのキューを提供する。複数のエッジ位置（例えば、基地局又は他のエッジゲートウェイノード３１２、エッジ集約ノード３２２など）の間で共有されるキューのグローバル（例えば、マルチエッジシステム）セットを動作させるために、キューの概念を、分散エッジコンピューティングプラットフォームでの使用に合わせて拡張することができる。

【0440】

一例において、個々のキューは、異なるエッジノードにわたって一貫性を持つよう保たれるが、ジョブ定義（実行される機能又はサービス、ペイロード、及び可能性のあるデータ）は、リクエストがサブミットされたエッジ位置に格納される。そして、サービスリクエスト又は機能がエッジ装置によって要求されると、その装置が接続されているエッジ位置のオーケストレータが、実行されるジョブを、使用されるメタデータ（例えば、ジョブ定義、サブミッションエッジノードなど）とともに、キューに（継続的に）追加する。それぞれのエッジ位置で動作している異なるオーケストレーションエンティティが、ローカルエッジノードで実行されるジョブを採取する。該ジョブが実行されると、該ジョブ（サービス又はＦａａＳ）がキューから（継続的に）除去され、データ及びジョブ定義が必要に応じて移動され、実行され得る。

【0441】

共有される又はサブスクライブ可能なエッジキューの使用は、分散環境内での作業負荷バランシングの概念を支援し得る。構造化された方法を、キューの使用のために想定することができ、ローカルキューの詳細は、局所的に、対応するオーケストレータ（例えば、ＭＥＣオーケストレータ、ＭＥＯ）のみに知られており、キューサイズのみが時間インターバルでオーケストレータ（例えば、ＭＥＯ）間で交換される。この情報を用いて、キューオーバーフローの発生（及び等価的に、ジョブ「ドロップ」）を減らす目標が試みられ得る。

【0442】

サブスクライブ可能な分散エッジキューの様々な装置実装例が、幾つものエッジコンピューティングハードウェア、回路、ノード、又はシステム構成（例えば、図３から図２２Ｄに示したエッジクラウド１１０及びエッジコンピューティングシステム構成）にて展開されるように、サービスオーケストレーション及び実行システム内に提供され得る。様々な方法例は、グローバルにアクセス可能なキューから情報を追加し、調整し、及び除去し、そして、キューの連携使用に従ってジョブ（１つ以上のサービス、サービスアクション、ワークフローなど）を実行することを含み得る。従って、エッジコンピューティングシステムノードの様々なプロセッシング回路にて実行される方法は、ノード間でジョブ及び機能の組織的実行をコーディネートするように、エッジコンピューティングシステム内で共有キューを展開及び使用することを含み得る。

【0443】

種々の環境において、グローバルに共有される又はサブスクライブ可能なキューは、データ追跡構成の使用を規定するＡＰＩ又は仕様；ネットワーク内でのトラフィック分析による観察、並びにエッジコンピューティング環境内でのキュー及びキューデータの他の使用及び実装、の結果として観察又はモニタされ得る。グローバルに共有される又はサブスクライブ可能なキューはまた、（例えば、ＦａａＳ又はＥａａＳ環境においてサービス間での共有をサポートするために）エッジコンピューティングシステム内でサービス操作及びサービス機能の結果として起動、観察又は実装され得る。従って、以上の例の特徴（及び分散キューの他の特徴）は、システムオーケストレータ又はアーキテクトによって連携又は設計されるように、エッジクラスタ又はエッジクラウドシステムを構成するために、ここでの他の例のうちのいずれかと組み合わされ得る。

【0444】

自動エッジサービス分配の例

【0445】

上述の多くの例によって示唆されるように、エッジクラウドアーキテクチャは、異なるエッジ協調クラスタにグループ化され得る複数のエッジ（例えば、スモールセル、セルタワー、又はアグリゲーションの異なるポイント）で構成される。例えば、それらはインフラストラクチャの所有者によって規定され得る。全体を通してここに記載される他のシステム及び技術の一部は、様々な目標を達成するためのリソースの規定、発見、及びセキュリティグルーピングの方法を議論している。以下にて説明するシステム及び方法は、これらのグループのためのサービス分配を提供し得る。共通（例えば、グループメンバーにわたって）である属性の集合は、セマンティクスをグループ化することを記述する一手法である。ディスカバリープロセスが、コラボレーションの適合性を判断するための一手法として、グループの属性をクエリし、興味ある属性の集合との重なりを比較し得る。属性は、一例において、相互運用可能で、意味的に豊富なタグの集合として捕捉され得る。タグのネームスペースは拡張可能であることができ、コラボレーションオーケストレーションを使用して、技術的には異なるが意味的には同じであるタグを検出し得る。タグは値も持ち得る（例えば、ＣＯＤＥＣをタグとすることができ、その値はサポートされるＣＯＤＥＣアルゴリズムをリストアップし得る）。

【0446】

属性タグ付けアーキテクチャは、マルチテナント協調エッジアーキテクチャ（例えば、図３から図２２Ｄに示したエッジクラウド１１０及びエッジコンピューティングシステム構成）にスケーラブルであることができる。属性タグ付けアーキテクチャは、迅速なターンアラウンドを提供し、所有の全体コストを改善する（例えば、本当に必要とされるときにのみ使用される可能な限り少ないリソース）ために必要とされ得るものである低い待ち時間及び効率を提供するハードウェアを用いて実装され得る。ハードウェアベースの実装はまた、基地局内に置かれたエッジクラウドソリューションでの場合に、電力及び熱的制約付きで、限られた空間内に高い計算及び加速密度を提供し得る。伝統的なデータセンターに適したものであり得る既存のソリューションは、このような環境には適さない。

【0447】

グループ化アーキテクチャは、加速された機能又は機能要求が直接的にプラットフォームによって処理される既存のプラットフォームを拡張する（又は新しいプラットフォームを作り出す）ことができる。従って、ソフトウェアは必要とされない。これは、より少ないメンテナンス（多数の（例えば、１００Ｋ＋）基地局が展開されるエッジシステムにおける考慮事項）、より大きい計算実行密度（例えば、より良いＴＣＯ）、又はクライアントからの要求処理を加速させることによるいっそう良好な応答時間をもたらし得る。さらに、このようなアプローチは、作業負荷データがまた計算リソースに持ち込まれる（移動、連携、結集される）ように、計算リソースを作業負荷データに持ち込む（例えば、移動、連携、結集する）ための１つのメカニズムを提供し得る。

【0448】

エッジクラウドアーキテクチャは、エッジネットワーク及びデータセンターアーキテクチャが、これまで可能でなかった新たなユースケースを可能にする機会を持ち得る将来性ある領域の１つとして浮上してきている。この文脈において、図示したように、電気通信サービスプロバイダ（ＴＳＰ）及びクラウドサービスプロバイダ（ＣＳＰ）にとって意味のあるユースケースの１つは、サービスとしての機能（Function-as-a-service；ＦａａＳ）（例えば、画像を処理して物体を返す）を、それらの作業負荷及び適用を加速させるために、エッジ装置（例えば、スマートフォン又はＩｏＴ）で走っているアプリケーションに公開することである。この文脈においては、後述するように、サービスとしてのアクセラレーション機能（Acceleration Function as a Service）（機能がアクセラレータにて実装及び実行される場合のＦａａＳと同様）が使用され得る。

【0449】

エッジクラウド展開の概説にて上述したように、低待ち時間ＦａａＳ及びＡＦａａＳ（１－１０ｍｓの待ち時間）を公開するため、アクセラレータ及び計算が基地局（ＭＥＣプラットフォーム構成を含む）に置かれる。しかしながら、スケーラブルなエッジクラウドＦａａＳ及びＡＦａａＳを実装するように基地局にプロセッサ及びアクセラレータを置くための主な難題の１つは、（１）物理的な空間制約、（２）クライアント要求／機能を処理するための低待ち時間且つスケーラブルなスケジューリングソリューション、（３）高い実効計算密度及び加速（システムソフトウェアスタックによってではなく、実計算に使用される計算及び加速）である。

【0450】

ここに記載されるシステム及び方法は、ＣＰＥ（加入者宅内機器）、スモールセル、又はセルタワーが、特定のサービスの実行を、そのサービスのためのＱｏＳ又はＳＬＡを維持しながら、エッジアーキテクチャ内の十分に活用されていない他のエッジに向け直すことを可能にする新しいタイプのＭＥＣプラットフォームアーキテクチャ（これは、現行システム及びアーキテクチャに適用され得る）を含む。

【0451】

図28を参照すると、エッジアーキテクチャは、異なるエッジコラボレイティブクラスタ(例えば、インフラストラクチャ所有者によって定義され得るもの)にグループ化される複数のエッジ(例えば、小セル、セルタワー、または異なる集約ポイント)から構成されている。クラスタの各個人は、他のピアに対して(例えば、設定可能なインターバルにおいて)ブロードキャストすることができる。ブロードキャストは、異なるタイプのリソース(例えば、ストレージ、メモリ等)の現在の利用または将来の必要性を含むことができる。

【0452】

所定のエッジロケーションが、エッジデバイス2802(例えば、スマートフォンまたは自動車)から、(例えば、締め切り日およびリソース要件に関する)所定のサービスレベル合意を伴う所与のサービスを実行するための要求を受信した場合に、所定のエッジロケーションは、要求を別のエッジロケーションに転送することを決定することができる。転送の決定は、以下のファクタの１つまたはそれ以上(非排他的)に基づいてよい。

【0453】

別のエッジロケーションは、現在のエッジからの別のロケーションの距離(例えば、待ち時間)および利用可能なリソースを与えられて、そのサービスを実行することができる。現在のエッジにおける利用率または予測利用率。例えば、エッジロケーションは、やって来る要求を学習し、かつ、予測するために使用される小さなMLまたはDL訓練計算エレメントを含むことができる。一つの例において、他の場所の選択は、異なるスキーム(例えば、ラウンドロビン、より少ない利用のエッジ、金銭またはリソースコストの考慮、等)を使用して行われ得る。アーキテクチャは、プログラマブル論理デバイス(例えば、FPGAで実装されているもの)を含んでよく、このことは、転送者（forwarder）を選択することに責任があり、そして、各インフラストラクチャの所有者によって実装されてよい。

【0454】

フォワーディングエッジアーキテクチャは、現在の技術を用いては利用可能でない一式の新たなサービスおよびビジネスケースの使用を含み得る。フォワーディングエッジアーキテクチャは、多種多様なセグメントおよび作業負荷に対して適用可能である。図20は、例えば、フォワーディングエッジアーキテクチャに対して適用され得るいくつかの例を示している。

【0455】

図28は、エッジサービス分布のためのエッジコンピューティングアーキテクチャ2800を伴うシステム図をより具体的に示している。図28に示されるように、アーキテクチャ2800は、個々のエッジロケーション2804において(例えば、カスタマの構内設備、2806のような小さいセル、2808のようなセルタワー、および、ローカルセントラルオフィス2812のような異なる集約ポイントから)機能を実施する(例えば、論理またはコードを介して実施される)ための命令を含み、かつ、実行することができる。命令は、エンティティのためのエッジゲートウェイまたはプラットフォーム2810内において提供されてよく、インテリジェントNIC 2820(「スマートNIC」としても知られているもの)または任意の他のタイプのネットワークカードを介して実装され得る。これらの機能は、以下に説明されるような、エレメントを含み得る。一つの例において、機能は、相互運用可能で、意味的にリッチなタグといった、タグまたは複数のタグを使用して適用されてよく、これらは、また、値も有し得る。

【0456】

機能は、インフラストラクチャ所有者が、所定のエッジに対して、同じコラボレイティブエッジクラスタに属する１つまたはそれ以上の(または、全ての)異なるエッジピアを登録することを可能にする、一式の新たな帯域外インタフェース2822を含み得る。一つの例において、エッジは、複数のエッジクラスタに属してよい。

【0457】

機能は、エッジピアクラスタに対してブロードキャストされるべき、テレメトリおよびリソース利用率データ2824のタイプを含むデータを含み得る。テレメトリは、エッジクラスタそれぞれにおいて異なってよい。機能は、エッジが、テレメトリおよびリソース利用率データ2824を、それが属するエッジコラボレイティブクラスタに対してブロードキャストする周波数を含み得る。このテレメトリは、それぞれの所有者、テナント、またはサービスに対して特有な(または、共有される)ものであり得る。

【0458】

機能は、異なる登録されたクラスタ(もし、あれば)において異なるエッジまたは複数のエッジを選択することに責任を負う、ビットストリーム(または、アクセラレーションアルゴリズム2826が実装される形態)を含み得る。登録されたクラスタは、サービス要求が存在するエッジに対応し得る。このビットストリームは、そうした決定を行うためにテレメトリデータテーブルに対するアクセスを有し得る。

【0459】

機能は、異なるエッジピアからやって来るデータを保管する責任を負うテレメトリデータ構造を含み得る。一つの例において、データは、異なるエッジコラボレイティブクラスタへと構造化され得る。本機能は、そのエッジの将来の利用率を予測するために、所定のエッジに到着するサービスサブミッションのタイプについて機械学習を使用することができる。この機械学習技術は、プログラマブル論理デバイスにおいても、同様に実装され得る。

【0460】

機能は、個々の又は複数のエッジユーザ、テナント、および所有者から来る要求を処理する責任を負う。要求は、実行されるべきサービス、または、SLAおよびソース要件を伴って来ることがある。要求は、前述のビットストリームによってスケジュールされ得る。一つの例において、分布テレメトリデータは、インフラストラクチャ所有者によって構成されたテレメトリデータおよびリソース利用率を収集し、かつ、データを、それが登録されている異なるクラスタに対してブロードキャストするために使用され得る。

【0461】

さらなる例において、エッジサービス分布のための方法は、以下の動作を含むことができる。本方法は、エッジクラスタに属する第１エッジロケーションにおいて要求を受信する第１動作を含んでいる。本方法は、エッジクラスタの第２エッジロケーションを選択するための第２動作を含んでいる。第２エッジロケーションを選択することは、第２エッジロケーションのタグを使用することを含み得る。タグは、利用可能なリソースおよびエッジクラスタ内の第２エッジロケーションのメンバーシップを示している。

【0462】

本方法は、第１エッジロケーションにおいて、第２エッジロケーションの利用可能なリソースに基づいて、要求が、エッジクラスタの第２エッジロケーションにおいて実行可能であることを決定する第３動作を含んでいる。一つの例において、要求が第２エッジロケーションで実行可能であることを決定することは、第２エッジロケーションで要求を実行することが、第１エッジロケーションで要求を実行するよりも少ない計算リソースを必要とするか、または、より少ない時間を必要とすること(例えば、第１エッジロケーションよりも第２エッジロケーションで要求を実行する方が効率的であること)を決定することを含む。効率は、期間にわたる第１エッジロケーションの予測された利用率に基づいてよく、または、第２エッジロケーションから第１エッジロケーションまでの距離に基づいてよい。効率は、第１エッジロケーションにやって来る要求を予測するために機械学習エレメントを使用して決定されてよい。

【0463】

本方法は、実行のために要求を第２エッジロケーションに対して転送するための第４動作を提供する。本方法は、さらに、第１エッジロケーションで、第２エッジロケーションからのテレメトリおよびリソース利用率データを受信することを含んでよい。

【0464】

エッジサービス分布を実装するための第１の例示的方法(実施例C1)は、処理回路(例えば、ノード、もしくは、デバイス2200、2232、2240、または2250の処理回路)を使用して実行される方法である。本方法は、エッジクラスタに属する第１エッジロケーションで要求を受信するステップと、第１エッジロケーションで、第２エッジロケーションの利用可能なリソースに基づいて、要求が、エッジクラスタの第２エッジロケーションで実行可能であることを決定するステップと、実行のために第２エッジロケーションに対して要求を転送するステップと、を含む。

【0465】

第２の例(実施例C2)において、実施例C1の技術的事項（subject matter）は、第２エッジロケーションで要求を実行することが、第１エッジロケーションで要求を実行するよりも少ない計算リソースを必要とするか、または、より少ない時間を必要とすることを決定することによって、要求が第２エッジロケーションで実行可能であることを決定することを含む。

【0466】

第３の例(実施例C3)において、実施例C2の技術的事項は、第２エッジロケーションで要求を実行することが、より少ない計算リソースを必要とするか、または、より少ない時間を必要とするかは、ある期間の第１エッジロケーションの予測される利用率に基づいていると決定すること、を含んでいる。

【0467】

第４の例(実施例C4)において、実施例C2－C3の技術的事項は、第２エッジロケーションで要求を実行することが、より少ない計算リソースを必要とするか、または、より少ない時間を必要とするかは、第２エッジロケーションから第１エッジロケーションまでの距離に基づいていると決定すること、を含んでいる。

【0468】

第５の例(実施例C5)において、実施例C2－C4の技術的事項は、第２エッジロケーションで要求を実行することが、より少ない計算リソースを必要とするか、または、より少ない時間を必要とするかは、第１エッジロケーションにやって来る要求を予測するために機械学習エレメントを使用することを含むと決定すること、を含んでおり、ここで、機械学習エレメントは、履歴の要求に基づいて訓練されている。

【0469】

第６の例(実施例C6)において、実施例C1－C5の技術的事項は、第２エッジロケーションのタグを使用して第２エッジロケーションを選択することを含み、タグは、利用可能なリソースおよびエッジクラスタ内の第２エッジロケーションのメンバーシップを示している。

【0470】

第７の例(実施例C7)において、実施例C1－C6の技術的事項は、第１エッジロケーションで、第２エッジロケーションからテレメトリおよびリソース利用率データを受信することを含む。

【0471】

様々な設定において、実施例C1－C7(および、自動エッジサービス分布の他の態様)は、サービス分布の使用を定義するAPIまたは仕様、サービス分布の使用を定義または包括するプロトコル、および、エッジコンピューティング環境の中のサービスの他の使用および実装の結果として、観察またはモニタリングされ得る。実施例C1－C7およびエッジサービス分布の他の態様も、また、連携されたサービス動作およびサービス機能の結果として(例えば、連携されたサービスが、FaaSまたはEaaS設定において呼び出されるか、または動作されることを可能にするように)、観察または実装され得る。加えて、実施例C1－C7の方法は、エッジコンピューティングシステムにおいて、実装される命令として(例えば、命令が実行されたときに本方法を実行する機械で読取り可能な媒体を用いて)、または、実装されるハードウェア構成として(例えば、本方法を実行または達成するための構成を含む装置を用いて)提供され得る。このように、実施例C1－C7の特徴(および、自動エッジサービス分布の他の特徴)は、システムオーケストレータまたはアーキテクトによって連携または設計されて、エッジクラスタまたはエッジクラウドシステムを構成するために、ここにおける他の実施例のいずれかと組み合わされてよい。

【0472】

アクセラレーションの実行例および定義の実施例

【0473】

一つの例において、エッジコンピューティングシナリオは、分散コンピューティング環境の中でサービスおよびハードウェアのためのアクセラレーションを考慮し、かつ、動作させるように適合され得る。従来の設定において、アクセラレーションは、固定された機能対アクセラレータのマッピングを有するローカルマシンの中で典型的には適用されている。例えば、従来のアプローチでは、所定のサービス作業負荷が所定のアクセラレータを呼び出すことができ、この作業負荷が(ネットワークアクセスにおける変更に基づいて、新たな待ち時間条件を満足するように、等)別のロケーションへに移動または移行する必要がある場合に、作業負荷は、再解析され、かつ、潜在的に再分析される必要があり得る。

【0474】

エッジクラウドアーキテクチャの以下の適応(例えば、エッジクラウド110の適応、および図3から図22Dまでに示されるエッジコンピューティングシステム構成)は、異なるホスト(例えば、エッジコンピューティングノード)において異なるアクセラレーション機能の連携を可能にする。アクセラレータの作業負荷を直列的に処理するのではなく、作業負荷と機能動作を「分割および征服」するために並列的な分布アプローチが使用されている。この並列的な分布アプローチは、アクセラレーションハードウェア(例えば、FPGA、GPUアレイ、AIアクセラレータ)の同一または複数の形態、および、同一または複数のタイプの作業負荷および呼び出された機能の使用の最中に適用され得る。

【0475】

アクセラレーション分布は、クライアントデバイスが、大量のデータ(例えば、10GB、または、デバイスまたはネットワークのタイプに対して著しいあるサイズの量)を提供する作業負荷について、アクセラレーション機能を実行したい場合に使用され得る。データのこのチャンク（chunk）が並列処理をサポートする場合に－データが並列して複数のアクセラレータを用いて実行または分析され得る場合－、複数の処理ノードからアクセラレーションの結果を分布および収集のために、アクセラレーション分布が使用され得る。クライアントデバイスが、より効率的またはタイムリーに作業負荷を満たすために、並行して実行され得る多数の機能(例えば、一度に100以上の機能)を実行したい場合にも、また、以下のアクセラレーション分布アプローチが使用され得る。クライアントデバイスは、所与のSLAおよび所与のリソースコストで実行されるデータおよび作業負荷データを送信する。作業負荷は、複数の処理ノード間に分布され、連携され、そして、収集され、－ノードそれぞれは、アクセラレーションの異なるフレーバーまたは置換を提供する。

【0476】

図29は、エッジコンピューティングシステム2900の中で並列にデータをアクセラレーションするためのアーキテクチャを示している。このシステムには描かれていないが、所定のフレーバー構成を識別し、フレーバーサービス、FaaS、または他のメンバーそれぞれの証明を取得し、かつ、集約された証明結果(例えば、「フレーバー証明」)を提供するために使用される、フレーバーゲートウェイが存在し得る。さらなるシナリオにおいて、作業負荷オーケストレータは、特定のフレーバーグループについて作業負荷をスケジューリングするための前提条件として、フレーバー証明を必要とし得る。そして、さらなるシナリオにおいて、作業負荷は、また、並列エッジ配置においてもアクセラレーションされ得る。

【0477】

第１の例において、(SLAまたは他のサービスアプローチの下で動作する)作業負荷セット2920が、１つまたはそれ以上のクライアントモバイルデバイス2910によって、エッジクラウドの中で処理するために(例えば、クライアントモバイルデバイス2910に対して提供されるようにエッジコンピューティングシステム2900によって実行されるサービスの結果として)提供されている。この作業負荷セット2920は、エッジクラウドによる実行のために、１つまたはそれ以上のアクセラレーション機能を呼び出すことができる。例えば、作業負荷セット2920は、第１作業負荷2921および第２作業負荷2922を含み得る。第１作業負荷2921を処理するために必要なアクセラレーションは、第１サービスとしての機能(function-as-service)(FaaS-1)2931を呼び出し得る。第２作業負荷2922を処理するために必要なアクセラレーションは、第２サービスとしての機能(FaaS-2)2932に加えて、第１サービスとしての機能を呼び出し得る。

【0478】

作業負荷セット2920は、並列にN個の処理ノード間に分布される－N個の処理ノードが同一または異なるアクセラレーションハードウェアの組み合せを含むからである。例えば、第１ノード2941が、第１機能2951の実行をサポートするためのアクセラレーションハードウェア(例えば、FPGA)を含み、一方で、第２ノード2942および第３ノード2943が、同じアクセラレーションハードウェアを含むものと仮定する。結果として、第１サービスとしての機能2931によるといった、第１機能を呼び出すための要求は、ノード2941、2942、2943の間の第１機能を有する作業負荷の実行によって満たされ得るが、別の機能はノード2942で実行されてよい。

【0479】

一つの例において、処理ノード間の作業負荷の分布は、エッジゲートウェイ2940、オーケストレータ(図示なし)、または、別の中間エッジクラウドノードによって連携され得る。例えば、エッジゲートウェイ2940は、データが配分される必要があるアクセラレータの数を決定し(または、アクセラレータによって呼び出される機能を決定し)、ノード上のノードまたはアクセラレータを選択し、かつ、選択されたノードおよびアクセラレータに対してデータを送信する責任を負うことができる。アクセラレータがデータの処理を完了して、データをリターンする場合に、エッジゲートウェイ2940は、低減条項を適用するか(例えば、全ての結果を合計する)、または、他の処理を実行してよい。ペイロードを提供することに加えて、クライアントデバイス2910は、また、機能(または、複数の機能)、および、適用する低減条項を指定してもよく、もしくは、エッジゲートウェイ2940は、機能および低減条項を自動的に識別してよい。作業負荷は、別のノード2944に対して配分される作業負荷の一部(第２機能2952)といった、エッジゲートウェイ2940から独立して配分されてよい。

【0480】

さらなる例において、複数のアクセラレータ間に分布された作業負荷のオーケストレーションおよび連携は、ここにおいて議論される他の技術を使用して、負荷バランシング、モバイルアクセス予測、または、テレメトリの使用に係る態様を含み得る。複数のアクセラレータ間に分布された作業負荷のオーケストレーションと連携は、また、SLA/SLO基準および目的に基づいてよい。アクセラレータは、現在または予測される実行状態に基づいてSLA/SLOを満たす可能性が最も高いように選択されるからである。

【0481】

加えて、図29の環境において、NICは、LSMまたは他のセキュリティポリシ実施ポイントであり得る。例えば、NICは、適切に設定されていないか、ウイルスを含んでいるか、または、必要なアクションを実行していない場合に、ノードがネットワークにアクセスすることを防止することができる。このことは、業界のNAC(Network Access Control)ユースケースに類似している。加えて、そうした設定において、オーケストレータは、LSMまたは他のセキュリティポリシをNICに対して提供することができる。NICは、修復トラフィックを可能にすることができ、一方で、同時に、通常の活動をブロックしているからである。

【0482】

様々なエッジシステム構成において、アクセラレーション機能は、さらに、データ抽象化アクセラレーション作業負荷記述の使用を通して強化され得る。これらのアクセラレーション作業負荷記述は、XMLといった高レベルフォーマットにおいて定義された、均一の作業負荷定義の使用を通じて、エッジインフラストラクチャの中で使用可能にされ得る。そうしたアクセラレーション作業負荷記述は、アクセラレーションされたリソースに対する均一なアクセスを可能にし、そして、エッジコンピューティング・エコシステム内の異なるノード全体にわたりアクセラレーションの強化された使用を可能にするために利用され得る。

【0483】

一つの例として、エンドポイントデバイスがインフラストラクチャの異なるエッジアクセスポイント間を移動すると、デバイスは、アクセラレーションを呼び出すために、エッジアクセスポイントに対して作業負荷定義をサブミットすることができる。そうした作業負荷定義は、作業負荷の定義、データペイロード、作業負荷、リソースコスト、および、他のパラメータについて関連するSLA/SLOの指示、を含み得る。受信エッジアクセスポイント(エッジコンピューティングノード)は、適切なアクセラレータを選択し、作業負荷を特定のビットストリーム定義(アクセラレータと互換性がある)へと変換し、そして、作業負荷を実行する。

【0484】

アクセラレーション記述アプローチは、エッジコンピューティングシステムが、標準化されたIoTフレームワーク(例えば、Open Connectivity Foundation(OCF)、OLE Process Control(OPC)、Thing-Thing)の中で提供されている定義の利点を利用することを可能にし得る。ここで、センサ／アクチュエータ／コントローラノードは、共通の情報モデルおよびデータモデル(メタデータ)を使用して記述されている。結果を発見し、インタラクションし、取得する動作も、また、データモデルによってインタフェース定義の形式で取得される。このようにして、アクセラレーションリソースを有するエッジインフラストラクチャが、同様に抽象化され得る。このことは、上位層が下位層のデータモデル抽象化を提示する、「階層的サービスレイヤ」の形式を提供する。しかしながら、IoTフレームワークの抽象化とは異なり、これらのアクセラレーションの定義は、「サービスホスティング」の抽象化を提供する。サービスホスティングは、呼び出されるサービスまたは機能が指定されていないので、「サービスプロバイダ」の抽象化(例えば、UPNPといった、ディスカバリーアプローチで使用されるようなもの)とは異なっている。むしろ、アクセラレーション定義は、ホスティング環境特性および制約の記述を提供する。

【0485】

最終的に、アクセラレーション作業負荷記述の使用は、「信頼された」ホスティング環境の使用を可能にするように拡張され得る。ここで、環境のセキュリティ強化特性が、また、発見と考慮のために露出される。このことは、信頼できる(証明された)アクセラレーションリソースの選択から、といった、エッジコンピューティング環境における証明の使用を可能する。

【0486】

データ抽象化されたアクセラレーションを実装するための第１の例示的方法(実施例D1)は、処理回路(例えば、ノード、もしくは、デバイス2200、2232、2240、または2250の処理回路)を使用して実行される方法である。本方法は、エッジゲートウェイノードにおいて、アクセラレーション機能を呼び出す作業負荷を受信するステップと、エッジゲートウェイノードから各エッジコンピューティングノードに対して、各エッジコンピューティングノードのアクセラレーション機能によって並列して実行するための作業負荷のデータを分布させるステップと、エッジゲートウェイノードにおいて、アクセラレーション機能によって分布された実行の結果を収集するステップと、を含む。

【0487】

第２の例(実施例D2)において、実施例D1の技術的事項は、各エッジコンピューティングノードのアクセラレーション機能によって使用されている同じタイプのアクセラレーション機能を含む。

【0488】

第３の例(実施例D3)において、実施例D2の技術的事項は、第２タイプのアクセラレーション機能による、少なくとも１つの他のエッジコンピューティングノードの実行を追加的に呼び出す作業負荷を含む。

【0489】

第４の例(実施例D4)において、実施例D1－D3の技術的事項は、FPGA、ASIC、GPUアレイ、AIアクセラレータ、トランスコーディングアクセラレータ、または暗号アクセラレータハードウェア、のうちの少なくとも１つによって実行される各エッジコンピューティングノードのアクセラレーション機能を含む。

【0490】

第５の例(実施例D5)において、実施例D1－D4の技術的事項は、第１サービスとしての機能を呼び出す第１作業負荷と、第２サービスとしての機能を呼び出す第２作業負荷と、を含む作業負荷セットである作業負荷を含み、第１および第２サービスとしての機能は、各エッジコンピューティングノード間で提供されている。

【0491】

第６の例(実施例D6)において、実施例D1－D5の技術的事項は、エッジクライアントノードから受信される作業負荷を含む。

【0492】

第７の例(実施例D7)において、実施例D6の技術的事項は、所与のSLAおよび所与のコストに従って実行される作業負荷を指定しているエッジクライアントノードを含む。

【0493】

第８の例(実施例D8)において、実施例D6－D7の技術的事項は、エッジゲートウェイノードからエッジクライアントノードに対して、アクセラレーション機能によって分散実行の収集結果を提供することを含む。

【0494】

第９の例(実施例D9)において、実施例D1－D8の技術的事項は、エッジコンピューティングシステムの中のアクセラレーション機能がそれぞれのアクセラレーション作業負荷記述の中で示されている構成を含む。

【0495】

様々な設定において、実施例D1－D9(および、アクセラレーション使用の他の態様)は、定義されたアプリケーションプログラミングインタフェースまたはインタフェース仕様、アクセラレーションを起動、受信、または制御するためのプロトコルまたは定義の使用、および、エッジコンピューティング環境の中のアクセラレーションの他の使用および実装、の結果として観察またはモニタリングされ得る。実施例D1－D9およびアクセラレーション管理の他の態様は、また、連携されたサービス動作およびサービス機能の結果として(例えば、アクセラレーションリソースがFaaSまたはEaaS設定内のサービスにおいて起動または動作されるように)観察または実施され得る。加えて、実施例D1－D9の方法は、エッジコンピューティングシステムにおいて、実施される命令として(例えば、命令が実行されたときに本方法を実行する機械で読取り可能な媒体を用いて)、または、実施されるハードウェア構成として(例えば、本方法を実行または達成するための構成を含む装置を用いて)提供され得る。従って、実施例D1－D9の特徴(および、アクセラレーション管理の他の特徴)は、システムオーケストレータまたはアーキテクトによって連携または設計されるように、エッジクラスタまたはエッジクラウドシステムを構成するために、ここにおける他の実施例のいずれかと組み合され得る。

【0496】

エッジデバイスのNIC処理例

【0497】

他で述べたように、エッジコンピューティングは、基地局、セルタワー、等といった、ユーザにより近い作業負荷を処理することを参照する。－スマートシティ、スマート交通、等といった－多くのモノのインターネット(IoT)デバイスを伴う環境において、人工知能(AI)推論はますます重要な作業負荷になる。そうした推論作業負荷において、オーケストレータ(例えば、エッジゲートウェイ)は、推論を実行するために、異なるサービスプロバイダまたはインスタンスに対して推論要求を転送することができる。従って、エッジオーケストレータは、しばしば、要求をダイレクトし、かつ、プラットフォームに対して要求を送信するためのプラットフォームを選択する。選択されたプラットフォーム(例えば、そのプラットフォームにおいて実行しているサービス)は、要求を受信し、そして、プラットフォームがリターンする結果を生成するように要求を処理する。ここで、オーケストレータは、エンドツーエンドの負荷バランシングおよび要求のトラッキングを提供する。エッジユースケースは、しかしながら、しばしば、タイムクリティカルな処理を必要とし、非常に低い待ち時間の処理および推論トレランスを結果として生じている。従って、負荷バランシングは、そうした時間に敏感なタスクには最適でない可能性があり、サービスレベル合意(SLA)を満たすためにはハードウェアが大き過ぎるので、より大きい総所有コスト（TCO）を引き起こすか、もしくは、SLAが失われる。このシナリオは、推論待ち時間に可変性が存在する場合に悪化され得る。

【0498】

エッジ作業負荷のリアルタイム推論ニーズに対処するために、エッジコンピューティングシステム(例えば、エッジクラウド110、および、図3から図22Dまでに示されるエッジコンピューティングシステム構成)においてハードウェア支援技術が使用されてよく、スマートネットワークインタフェースコントローラ（NIC）を介してオーケストレータの負荷バランシングスキームを補完する。具体的には、これらのインテリジェントNICは、AIサービスを意識したものである。プラットフォームのNICには、プラットフォームにおいて実行しているAIサービス、および、AIサービスに対する「入力」に対応するメモリ領域が通知される。AIサービス及びそれらの入力メモリバッファは、サービスの開始中にNICにおいて登録され、そして、軽量のデータ構造(例えば、テーブル)において維持される。さらに、プラットフォーム上でAIサービスを意識したNICを識別するために、プラットフォームNIC、スイッチ、およびオーケストレータ間で同期プロトコルが使用され得る。この情報は、どのサービスまたはモデルがどのプラットフォーム内に配置されるかについてグローバルなビューを構築するために使用され得る。AIを意識したNICでは、プラットフォームインテリジェントNICが要求を受信すると、NICは、より迅速な処理のために、サービスプロバイダまたはモデルの入力メモリバッファの中へ要求を直接的に入れることができる。さらに、入力メモリバッファのサイズを測定するためのインタフェースを用いて、AIを意識したNICは、また、どれだけの量の入力が未だサービスによって処理されていないかを決定することもできる。

【0499】

上述の能力は、いくつかの技術につながる。例えば、オーケストレータは、負荷バランシングを改善するために、サービス上の現在の入力負荷を識別するようにプラットフォームNICをクエリすることができる。また、受信プラットフォームが実行しているAIモデルの複数のインスタンスを有する場合―異なるベンダまたはサービスプロバイダから、といった―、および、要求がそれらのいずれかに対してマップされ得る場合(例えば、セキュリティまたは受諾されたベンダに関して)、オーケストレータは、その要求をプラットフォームに単純に転送することができ、そして、インテリジェントNICは、入力メモリバッファ状態に基づいて、その要求に対して適切な(例えば、最良のマッチングの)サービスプロバイダを選択することができる。このことは、時間を節約しながら、ミクロ管理のオーケストレータを軽減する階層的オーケストレーションを可能にする。

【0500】

MEC設定において、推論タスクについては、その性質がMECオーケストレータ(MEO)に対して知られており、MEOは、既に同じ性質／問題／カテゴリの推論(例えば、顔認識)を実行したMEC／エッジホストに対してタスクを委任するように選択することができる。このようにして、推論結果は、既にタスクの「ディープラーナ（“deep learner”）」であるホストに由来するので、より信頼性が高くなる。

【0501】

AIを意識した又はスマートなNICは、ラックスイッチと共に使用され得る。例えば、ラックスイッチは、ラックによってホストされるプラットフォームにおいて実行しているサービスのリストを獲得することができる。これらのスイッチは、プラットフォームを識別するためにリストを使用することができ、サービス状態を取得するためのプラットフォームNICをクエリすること、または、要求がどこへ転送されて、リターンされるかを連続的に追跡することに基づいて、要求を送信する。

【0502】

一つの例において、プラットフォームNICは、要求を受信すると、ローカルメモリバッファが満杯または重い場合に、要求されたサービスまたはモデルを実行している他のプラットフォームに対して要求を転送することができる。この特徴は、オーケストレータの関与なしに、動的負荷バランシングを明確に可能にする。一つの例において、要求を受諾するプラットフォームNICは、転送される要求に関してオーケストレータに通知することができる。

【0503】

一つの例において、インテリジェントNICは、要求を処理するのにどの位の時間がかかるかを、例えば、現在の入力バッファサイズに基づいて予測するために、システムテレメトリを使用することができる。この予測は、次いで、いくつかのプラットフォームのうちどのプラットフォームに対して、例えば、全体的な処理待ち時間を減少させるように要求が転送され得るかを決定するために、使用され得る。

【0504】

AIを意識したNICは、上述のシナリオにおける標準NICに対していくつかの利点を提供する。例えば、オーケストレーションおよび負荷バランシングのオーバーヘッドが削減される。このことは、エッジに配置されるIoTデバイスおよびサービスの増加のせいで、このオーバーヘッドが重大になることがあるので、重要であり得る。

【0505】

図30は、改善されたエッジクラウド推論処理のためのコンポーネントを含む、エッジコンピューティングアーキテクチャ3000の一つの例を示している。図示されるように、エッジゲートウェイ3004は、サーバラック3005と通信している。エッジゲートウェイ3004は、サーバノード(サーバラック3005といったもの)間で動作または構成を調整するように構成されたオーケストレータ3010を含み得る。そして、そうした動作または構成を支援するために、証明ロジック3012および負荷バランシングロジック3014を実行するように構成され得る。サーバラック3005は、トップスイッチ3007(例えば、ラックのバックプレーンまたはラック内スイッチファブリック)、および、サーバ3006といった１つまたはそれ以上のサーバ(例えば、ブレード)を含む。トップスイッチ3007は、サーバ3006のインテリジェントNIC内にも存在する３つのコンポーネント、すなわち、サービスレジストリ3001、負荷バランシングコンポーネント3002、および予測コンポーネント3003、を含む。他の例において、スイッチ3007は、 (トップではない)他の場所に配置されてよい。

【0506】

サービスレジストリ3001は、サーバ3006および他のノード(例えば、ラック3005)上で、現在のノードにおいて実行しているサービスのマッピングを維持するように構成された回路である。サービスレジストリ3001は、インタフェース(図示なし)を含み、それを通じて、サーバ3006上のプラットフォームは、サーバ3006のためのAIサービスを登録および登録解除することができる。登録および登録解除は、(例えば、エッジゲートウェイ3004における)オーケストレータ3010、オーケストレータ3010の一部であるプラットフォーム上のローカルデーモン、プラットフォーム内のウォッチドッグローカルデーモン、または、AIサービス自体、等によって開始され得る。一つの例において、サービスレジストリ3001は、サービスマッピングを更新するために、(例えば、他のノードからのNIC上の)他のサービスレジストリからブロードキャストを開始または受信するように構成されている。

【0507】

負荷バランシングコンポーネント3002は、AIサービスに対する入力を受信し、そして、対応するサービスの入力メモリバッファの中へその入力を送信するように構成された回路である。負荷バランシングコンポーネント3002は、受信した入力をAIサービスのメモリバッファの中へ追加するか、または、別のノード上のAIサービスの別のインスタンスに対して転送するかを決定するように構成されている。この決定は、現在のメモリバッファの状態または予測コンポーネント3003からの入力といった、ポリシに基づいてよい。一つの例において、負荷バランシングコンポーネント3002は、入力メモリバッファの現在の状態に関するオーケストレータ3010からのクエリに応答するように構成されている。

【0508】

予測コンポーネント3003は、AIサービスによって入力がいつ処理され得るかを理解し、かつ、予測するために、システムテレメトリ、および、任意的に機械学習を使用するように構成された回路である。このために、予測コンポーネント3003は、入力メモリバッファの状態をモニタリングするように構成されている。このことは、処理時間のおおよその見積りを提供するために、機械学習システムに対して入力として提供される。これらの出力は、サービスに対する入力が別のノードについて受諾され、または、転送される必要があるか否かを決定するときに、負荷バランシングコンポーネント3002によって使用され得る。さらなる例においては、他のエッジノードからのメタデータが、より良好な予測を実行するために使用され得る。例えば、サービスおよびフローによって実行される最近の要求は、予測スキームのためのグローバルビューを提供し、かつ、改善するために使用され得る。さらに、NIC(または、他のフォワーディング機能性)のフォワーダコンポーネントは、LSMまたは他のセキュリティポリシ実施ポイントであり得る。そこで、セキュリティポリシは、アウトブレイクの病理を遅らせたり、または、「形作る」ために、転送行為を制限している。

【0509】

さらなる例において、エッジコンピューティングシステムの中のオーケストレーションの適用は、ネットワークアダプタおよび様々な形態の物理的機能オフロードについてソフトウェアプログラム制御を可能にするために、ネットワーク装置およびネットワークアダプタの中の高度な形態のロジックおよびプログラミングによって促進され得る。例えば、そうしたネットワーク装置およびアダプタは、VNF構成、プラットフォームネットワーク装置、または、他のネットワーク動作態様に対して行われた変更またはアップグレードに基づいて、ネットワークオペレータからプログラミングを受信するためのアップグレードまたは変更メカニズムを含み得る。

【0510】

一つの例において、そうしたプログラミングは、ソフトウェアでプログラムされたシングルルート入出力仮想化(SR-IOV)を使用して提供され得る。SR-IOVは、様々なエッジコンピューティングオーケストレーション活動(例えば、この文書の全体を通じて議論されているもの)がネットワーク動作と連携されることを可能にする、仮想関数および物理関数の修正メカニズムを提供し得る。これらの仮想関数と物理関数との間の通信メカニズムはデバイスに依存するので、各ネットワーク機器におけるSR-IOVの使用は、特定のデバイスの中のネットワーク処理のカスタマイズ、および、エッジコンピューティングとネットワーク構成とを可能にする。

【0511】

適用可能なネットワークハードウェアのSR-IOV制御は、NIC、スイッチ、または他のネットワークハードウェアの中で新たな制御機能を可能にするために、標準化または連携され得る。そうした制御は、例えば、オーケストレータ3010によって、オンザフライで実行され得る。さらに、SR-IOV制御および変更の使用は、ネットワーク機器(例えば、NIC)において実装される必要がある重要な構成をVNFが要求する場合といった、新たなマルチテナントVNFシナリオを可能にし得る。そうした設定変更は、仮想関数の特権がより少なく、かつ、適切なサービス動作を保証するために物理関数が呼び出される必要があるシナリオにおいて必要とされ得る。

【0512】

SR-IOV制御の様々な装置の例は、任意の数のエッジコンピューティングハードウェア、回路、ノード、またはシステム構成において配置されるように、ネットワークハードウェアの中で提供され得る。様々な方法の例は、ネットワーキングハードウェアに対するSR-IOVソフトウェアの変更に基づく、仮想および物理ネットワーク機能間の変更を含む、ネットワーキング機能の変更に基づいてエッジコンピューティングシステムの中でオーケストレーションを実行することを含み得る。

【0513】

エッジデバイスNIC処理を実装するための第１の例示的方法(実施例E1)は、処理回路(例えば、ノード、もしくは、デバイス2200、2232、2240、または2250)を使用して実行される方法である。本方法は、エッジコンピューティングシステム内のノードのネットワークインタフェースコントローラ(NIC)のホスト側インタフェースにおいて、ノード上で利用可能な人工知能(AI)サービスの登録を受信するステップであり、登録はサービスに入力するためのメモリエリアを含んでいる、ステップと、NICのネットワーク側インタフェースにおいて、NICにおいてAIサービスのための要求を受信するステップと、要求からの入力データをメモリエリアの中へ配置するステップと、を含む。

【0514】

第２の例(実施例E2)において、実施例E1の技術的事項は、AIサービスを呼び出すことによって、要求からの入力データをメモリ領域の中へ配置するステップを含む。

【0515】

第３の例(実施例E3)において、実施例E1－E2の技術的事項は、NICによって、別のノード内の別のNICからサービスのカタログを要求するステップと、NICによって、第２ノードにおけるAIサービスの別のインスタンスを記録するステップと、を含む。

【0516】

第４の例(実施例E4)において、実施例E3の技術的事項は、ネットワーク側インタフェースにおいてNICによって、AIサービスに対する第２要求を受信するステップと、処理のために第２ノードに対して第２要求を転送するステップと、を含む。

【0517】

第５の例(実施例E5)において、実施例E4の技術的事項は、第２ノードにおける要求の予測完了時間に基づいて、第２ノードに対して転送されている第２要求、を含む。

【0518】

第６の例(実施例E6)において、実施例E1－E5の技術的事項は、ネットワークインタフェース装置の中でシングルルート入出力仮想化(SR-IOV)によって引き起こされるネットワーキング機能の変化を使用して、エッジコンピューティングシステムの中のオーケストレーションが実装される構成を含み、ネットワーク機能の変化は、仮想および物理ネットワーク機能間の変化を含んでいる。

【0519】

他の例において、SR-IOVについて上述した技術(実施例E1－E6のいずれかを含む)は、重根（multiple-root）IOV設定(MR-IOV)において適用され得る。

【0520】

様々な設定において、実施例E1－E6(および、NIC処理の他の態様)は、定義されたアプリケーションプログラミングインタフェース、インタフェース、またはハードウェア仕様、IOVまたはNICの動作を起動、受信、または制御するためのプロトコルまたは定義の使用、サービスおよびサービスインタフェースの使用、並びに、エッジコンピューティング環境の中でのIOVおよびNICの他の使用および実装、の結果として、観察またはモニタリングされ得る。加えて、実施例E1－E6の方法は、実装される命令として(例えば、命令が実行されたときに本方法を実行する機械で読取り可能な媒体を用いて)、または、実装されるハードウェア構成として(例えば、本方法を実行または達成するための構成を含む装置を用いて)エッジコンピューティングシステムにおいて提供され得る。従って、実施例E1－E6の特徴(および、インテリジェントNIC処理の他の特徴)は、3010またはアーキテクトといったシステムオーケストレータによって連携または設計されるように、エッジクラスタまたはエッジクラウドシステムを構成するために、ここにおける他の実施例のいずれかと組み合わされ得る。

【0521】

グローバルサービスページテーブルの実施例

【0522】

特定のサービス、または、異なるサービスを所有するテナントについて、データが複数のエッジロケーションにわたり分散して置かれている、分散アーキテクチャにおけるチャレンジの一つは、これらのサービスセットが特定のデータセットに対して有する権利をどのように管理するかである。これらのデータセットは、データレイクとして知られているもの(例えば、構造化されたデータおよび非構造化データの大きな記憶装置)に保管され得る。一つの例において、新たなハードウェア方法は、ページテーブルの概念を使用して、効率的で、かつ、少ない待ち時間の(メモリにおける)データ分布、および、デバイスに対するアクセスを可能にする。

【0523】

既存のソリューションは、分散ストレージのためのソフトウェアスタックに基づいている。この場合に、ソフトウェアスタックは、サービスから仮想アドレス空間への変換アクセスを物理的ロケーションに対して実行し、そして、特定のデータセットに対してそれらのサービスが有する許諾をチェックする。スケーラビリティは、ソフトウェアスタックの使用について主な制限事項である。同様の問題が、テナントおよびデバイスのためのサービスにおいて発生する。

【0524】

ここにおいて説明されるエッジコンピューティングシステム(例えば、エッジクラウド110、および図3－図22Dに示されるエッジコンピューティングシステム構成)は、エッジページテーブルの実装を用いて拡張される。エッジページテーブルは、どのサービスがどのデータに対するアクセスを有するか、サービスからの仮想アドレスが物理アドレスに対してどのようにマッピングされているか、および、アドレスまたはデータに対する許諾が何であるか、を追跡するために使用される。一つの例において、ページテーブルは、サービスが複数のエッジロケーションにわたりインスタンス化またはマイグレーションされることを可能にし得る。エッジページテーブルは、エンドポイントデバイスにおけるセキュリティまたはテナント隔離を改善し得る(テナント、サービス、または、ユーザーベースのデータ暗号化を使用して、ページテーブルの異なる領域を保護することを含んでいる)。さらに、エッジページテーブルは、テナント固有のリソースコンテキストスイッチングのパフォーマンスを改善するために、「グローバル」またはシステム全体／マルチシステムベースで提供され得る。

【0525】

図31は、エッジサービスページテーブル3120を実装するためのシステム3100を示している。いくつかの例において、エッジサービスページテーブル3120は、メモリおよびストレージコントローラ3114を介して、エッジクラウド110(例えば、デバイス3130を含む)の異なるエッジノードおよびサービスにわたりメモリページ3160を管理するために、エッジクラウド110と共に使用され得る。そうしたメモリページは、可変または設定されたサイズ(例えば、1GB)であってよい。例えば、計算デバイス2200またはエッジコンピューティングデバイス2250は、エッジクラウド110内のエッジデバイスによる使用のためのデータ、サービス、または他のリソースを保管することができ、そして、データ、サービス、または他のリソースは、システム全体の(「グローバル」)サービスページテーブルを使用して管理され得る。グローバルサービスページテーブルは、計算デバイス2200またはエッジコンピューティングデバイス2250上、および、エッジクラウド110内の他のロケーションに(または、コアデータセンタ1250にアクセス可能な分散データベースに実装されるといった、エッジリソースノード1240などの計算リソースにおいて)保管され得る。一つの例において、グローバルサービスページテーブルは、コアデータセンタ1250のデバイス、または、エッジクラウド110のデバイス(例えば、クラウドデータセンタのサーバ)に保管され得る。

【0526】

ページテーブル3120は、所定のメモリページ(例えば、3160)にアクセスするためのアプリケーションの権利を識別するために、プラットフォームまたはCPUレベルにおいて使用される。ページテーブル(または、類似の構造)は、どのエッジリソースまたはサービスが所与のユーザまたはテナントに対してアクセス可能であるかを追跡するために、エッジコンテキストにおいて使用され得る。各エッジロケーションは、（例えば、ポインタ3170で始まる)以下の階層を有するツリーベースの構造を有してよい。ツリーのルート==>サービスのリスト==>プロバイダのリスト==>サービスを実行する権限を有するテナントまたはデバイスのリスト、である。さらなる例において、プロバイダのリストは、プロバイダに対して利用可能な作業負荷を強化するための構成オプションを含むことができる。(例えば、VM、セキュア(例えば、SGX)エンクレーブ、VM+Enclave、Container、Container+Enclave、VMM、VMM+Enclave、OS、FPGA、FPGA+AFU、等)。さらに、Intelソフトウェアガードエクステンション(SGX)または同様の技術(例えば、x86、ARM、または他のアーキテクチャに対して適用可能な他の信頼された実行または信頼されたコンピューティング技術)を含む作業負荷の組み合せは、期待される組み合せをチェックし、かつ、実施するために、強化されたセキュリティ環境を使用することができるだろう。アドレススペースの管理を可能にするために、信頼された実行、CPU、またはプラットフォームハードウェアの様々な適応または修正が利用され得る。

【0527】

一つの例において、ページを追跡するためのツリーは、ハードウェアエンティティ(例えば、FPGA)によって管理される仮想ツリーであり得る。テナントが所与のエッジサービスプロバイダからサービスAを実行することを望む場合に、テナントは、所与のテナントリソース、デバイス、ストレージ、計算のユニット、または、通信／ネットワークのユニットが置かれている許諾を含むリーフに到達するまで、ツリー階層を通って移動することができる。一つの例においては、テナントリソースに対するフロントエンドであるサービスが存在しており、これは、リソースを含み得る(例えば、利用可能なSLA、等といった、メタデータのタイプを含み得る)。３つの層のいずれかにおけるトランスレーションルックアサイドバッファ(TLB3110)ルックアップミスの場合には、(PTのためのプロセスと同様に)、ページウォークが、(ネットワークのセントラルオフィスまたはコアといった)ますます集中化されたリポジトリを目標とするために実行されてよく、そのユーザのためのサービス(例えば、サービス3150について)の特定の許諾を引き出す。

【0528】

一つの例においては、リソース割当てが、同様に実行され得る。ページテーブルを一つの例として使用すると、ページテーブルを有することは、３つの事を含み得る。(1)正当なアドレスと非正当アドレスとの間の区別(例えば、正当性欠陥とセグメンテーションエラー)、(2)アクセス制御(例えば、R/WおよびPKEYのような他のビット)、(3)必要に応じて利用可能なリソースの実現化または生成(例えば、欠陥の処理)である。３つ全てが、リソース管理側に類似物を有している。例えば、(1)サービスは、所定のリソースを拒否され、そして、他のリソースに対する潜在的なアクセスが許可され得る、(2)サービスは、実際にアクセスを有し得るリソースのさまざまな割合を与えられてよく、そのため、このマルチレベルウォークのナビゲーションも、また、制御ポイントであり得る、(3)サービスは、実際に必要とするときにだけリソースが与えられ得る。

【0529】

このアプローチは、テナントアクセス特権が、コアデータセンタにルートキャッシュを置き、そして、基地局またはオンプレミスなエッジノード、並びに、そその間のポイントに複数のコピーを置き、その間のポイントを置くスキームに従って階層的にキャッシュされ得るという点で、集中化されたディレクトリアプローチ(LDAPといったもの)とは異なっている。

【0530】

テナントSLA/SLOおよびオーケストレーションコンテキストは、予想されるロケーション、協同、または作業負荷に基づいて、キャッシュを積極的に温めるために使用され得る。キャッシュに対する頻繁なヒットは、後続の要求のために、キャッシュされたコンテンツを「温かく」保持する。

【0531】

エンドポイントデバイス、ホスト、またはサービスは、ローカルストレージリソースを使用して、キャッシングスキームに参加することができる。例えば、ローカルアクセス要求は、ローカルプラットフォームを離れる必要はない(これは、ネットワーク待ち時間を含み得る)。一つの例において、アクセスコンテキストは、特定のテナントに対して割当てられたリソースのセット内でキャッシュされ得る。例えば、プラットフォームがメモリ暗号化(例えば、Intel(R)のMKTME^ＴＭ)をサポートする場合に、暗号化ユーザキーリソースは、キーを含むように使用されてよく、そうでなければ、TLBキャッシュ3112によってキャッシュされ得る。他のテナント固有のリソース隔離スキームは、プラットフォーム毎またはサービス毎に適用され得る。例えば、永続ストレージ、機能アクセラレーション、CPU割当て、メモリ分割、仮想化、ペリフェラルアフィニティ、または、IoTデバイスネットワーク分割は、テナント固有の分割能力を有し得る。

【0532】

キーの取り消し、または、追加リソースにアクセスするための許諾の追加、といった、アクセスポリシに対する変更は、キャッシュされたコンテキストが古くなるせいで、権限のエスカレーションまたはサービス拒否（denial of service）に潜在的に影響されやすい。システム3100は、パブリッシュサブスクライブ構成または情報指向ネットワーキング（ICN）構成を使用して、キャッシュはテナント固有のコンテキストトピックに対する加入者になるというポリシに基づいて、リソースに対する更新が全てのキャッシュされたコピーに対して同時に一様に適用されることを可能にする。一つの例において、温かいキャッシュは、ローカルで発生するリソースアクセス要求についてタイムリーな更新を保証するために、高いQoS要求を伴い加入する。

【0533】

新たなデータまたは新たなデバイス3130がエッジデータレイクに追加される場合には、エッジサービス(例えば、サービス3150、計算機3140で動作しているもの)に対する特定のアクセス制限が適用され得る。この情報は、データまたはデバイスの同じデータレイクに関与しているエッジまたは複数のエッジに対してマルチキャストされ得る。既存のデータまたはデバイスにおける変更は、データまたはデバイスを共有している別のエッジまたは他のエッジに対してマルチキャストされ得る。一つの例において、特定のエッジロケーション(例えば、システム3100における@Xロケーション)は、特定のエッジデバイス内でホストされているデータまたは機能に割当てられてよい。エッジTLB 3110は、対応するサービス3150が、デバイスまたはデータ、もしくはエッジデバイス内のロケーションにアクセスするための権利を有するか否かをチェックすることができる。

【0534】

図32は、エッジグローバルサービスページテーブル3210の実装を示している。エッジグローバルサービスページテーブル3210は、仮想アドレス3212、および、対応する物理アドレス3214を示している。エッジグローバルサービスページテーブル3210の物理アドレス3214は、エッジデバイス、および、特定のエッジデバイス上のメモリ内の物理アドレスを含み得る。

【0535】

エッジグローバルサービスページテーブル3210は、ローカルおよびリモートメモリアドレスの両方を含んでいる。エッジグローバルサービスページテーブル3210が、メモリアドレスはローカルでないことを示す場合(例えば、サービスを動作させるか、または、テナントをホストするエッジデバイスに対して)、エッジグローバルサービスページテーブル3210は、リモートデバイスでのリモートメモリアクセスを獲得するために、リモートネットワークインタフェースに対してリード（read）を送信し得る。リモートメモリアクセスが許可されたことに応答して、デバイスには、物理アドレスのロケーション、または、書き込みアクセスが与えられ得る。さらなる例において、リモートノードがダウンしている場合に、システムは、要求が他のレプリカに送られる際に、(ページテーブル内に含まれるデータに基づいて)回復性を実装するために、そのサービスのレプリカを含んでよく、そうでなければ、SWスタックに対してエラーが生成される。

【0536】

一つの例において、デバイスによるセキュリティ要件といった、他の属性が、リモートアクセスの最中に考慮され得る。この例において、オリジナルのプラットフォームに対して送り返すことは、セキュアな方法で送信することを必要とし得る。別の例示的な属性は、要求に対してエクストラデータを追加することを要求し得る。(例えば、リモートメモリデータがセキュアである場合に)リモートメモリ内の証明情報を参照する、といったものである。アクセスポリシは、どれだけ大きい帯域幅を割当てるのか、または、どれだけ多くの待ち時間が必要とされるかを示す特性を伴うメタデータを有し得る。リモートデータがローカルノードに対してリターンされる際には、そうした特性が要求され得る。

【0537】

さらなる例において、エッジグローバルサービスページテーブルを実装するための方法は、以下の動作(例えば、ノード、もしくは、デバイス2200、2232、2240、または2250上で、もしくは、それらによって実装される、といったもの)に従って実装され得る。本方法は、仮想アドレス3212を複数のエッジノード上の物理アドレス3214に対してマッピングするように構成されたエッジグローバルサービスページテーブルを維持するための第１動作を含んでいる。本方法は、エッジグローバルサービスページテーブル内で維持されている仮想メモリアドレスに対するアクセスのための要求を受信するための第２動作を含んでいる。一つの例において、仮想メモリアドレス3212は、エッジサービスに対応している。本方法は、物理アドレス3214、および、仮想メモリアドレス3212と関連付けされたエッジノードを識別するための第３動作を含んでいる。一つの例において、エッジノードは、要求を開始するローカルノードからのリモートエッジノードである。本方法は、エッジノード上の物理アドレス3214に対応しているリソースに対するアクセスを提供するための動作で完結する。一つの例において、リソースは、エッジノード上の物理アドレスにおいて保管されたデータ、エッジノード上の物理アドレス3214において動作しているサービス、または、エッジノード上の物理アドレス3214のロケーションを含み得る。

【0538】

エッジサービスページテーブルを実装するための第１の例(実施例F1)は、デバイスであり、処理回路と、その上で具体化される命令を含むメモリとを含む。ここで、命令は、処理回路によって実行されると、エッジデバイス上のリソースを管理するための動作を実行するように、処理回路を構成する。動作は、仮想アドレスを複数のエッジノード上の物理アドレスに対してマッピングするように構成されたエッジグローバルサービスページテーブルを維持すること、エッジグローバルサービスページテーブル内に維持された仮想メモリアドレスにおいてリソースに対するアクセスのための要求を受信すること、物理アドレス、および、仮想メモリアドレスと関連付けられた対応するエッジノードを識別すること、物理アドレスにおいて保管されたリソースに対するアクセスを提供すること、を含んでいる。

【0539】

第２の例(実施例F2)において、実施例F1の技術的事項は、物理アドレスおよび対応するエッジノードを含む情報を要求側デバイスまたはサービスに対して送信することによって、リソースに対するアクセスを提供すること、を含む。

【0540】

第３の例(実施例F3)において、実施例F1－F2の技術的事項は、対応するエッジノードから要求元エッジノードへのリソースのコピーまたは転送を促進することによって、リソースに対するアクセスを提供すること、を含む。

【0541】

第４の例(実施例F4)において、実施例F1－F3の技術的事項は、リソースに対するアクセスを提供する前に、命令が、エッジグローバルサービスページテーブルをチェックすることによって、要求側デバイスがリソースにアクセスするための権限を有するか否かを決定することを含む動作を実行するように、処理回路を構成する。

【0542】

第５の例(実施例F5)において、実施例F1－F4の技術的事項は、デバイスが、複数のエッジノードのエッジノードであり、そして、エッジグローバルサービスページテーブルは、エッジノードにおいてローカルに保管されている、ことである。

【0543】

第６の例(実施例F6)において、実施例F1－F5の技術的事項は、リソースに対するアクセスを提供することが、対応するエッジノードにおいてリモートメモリアクセスを獲得するために、リモートネットワークインタフェースに対してリードを送信することを含む、ことである。

【0544】

第７の例(実施例F7)において、実施例F1－F6の技術的事項は、リソースに対するアクセスを提供することが、リソース、対応するエッジノード、または、要求側デバイスのセキュリティ要件を順守することを含む、ことである。

【0545】

様々な設定において、実施例F1－F7(およびグ、ローバルページテーブルの他の態様)は、定義されたアプリケーションプログラミングインタフェース、またはインタフェース仕様、ページテーブルを呼び出し、または、修正するためのプロトコルまたは定義の使用、および、エッジコンピューティング環境の中で複数のデバイスにわたるページテーブルの他の使用および実装、の結果として、観察またはモニタリングされ得る。実施例F1－F7及びこのグローバルページ構成の他の態様も、また、サービス動作およびサービス機能の結果として(例えば、FaaSまたはEaaS設定においてページおよびデータ構造を共有するために)観察または実装され得る。加えて、実施例F1－F7の方法は、エッジコンピューティングシステムにおいて、実装される命令として(例えば、命令が実行されたときに本方法を実行する機械で読取り可能な媒体を用いて)、または、実装されるハードウェア構成として(例えば、本方法を実行または達成するための構成を含む装置を用いて)提供され得る。従って、実施例F1－F7の特徴(および、グローバルなページ構成および使用の他の特徴)は、システムオーケストレータまたはアーキテクトによって連携または設計されて、エッジクラスタまたはエッジクラウドシステムを構成するために、ここにおける他の実施例のいずれかと組み合わされてよい。

【0546】

ブロードキャスティングリソースのボローイング実施例

【0547】

エッジクラウドインフラストラクチャは、複数の方法で作成されている。セントラルオフィスといった、いくつかのエッジクラウドロケーションは、それぞれのエッジクラウドロケーションにおいてオーケストレーションをホストするために十分なリソースを有し得る。ストリートキャビネットといった、いくつかの他のエッジクラウドロケーションは、ローカルリソースマネージャを用いたリモートオーケストレーションを有し得る。そうしたエッジクラウドのグループは、今日のクラウドにおいて行われている、従来のオーケストレーションおよびリソース管理とは対照的に、革新的な方法を用いて効率的に管理され得る。エッジクラウドは、時間で変動する要件を伴うサービス要求の高い摂取によって特徴付けられる。

【0548】

異なるロケーションに物理的に存在するリソースの共割当ては、周知の概念である。スキームは、たいてい、オンデマンド割当て、または、単純な基準に基づく静的割当てに基づいている。特定のサービスに対するリソースの明白な共割当ては、エッジクラウドにとってあまりに高価であり得る。代わりに、ここにおいて説明されるシステムおよび方法は、全体的なサービス割当ておよびスループットを改善するために効率的に使用されるエッジクラウドのグループを構成する。例えば、それぞれのエッジクラウドは、一式の計算リソースを管理するオーケストレーションインスタンスを有し得る。エッジクラウドのグループは、オーケストレーションクラスタとして設定され得る。

【0549】

エッジコンピューティングシステム(例えば、エッジクラウド110、および、図3－図22Dに示されるエッジコンピューティングシステム構成)において提供される、以下の技術は、一式の計算リソースを管理するためにエッジのグループを使用する方法の例を含んでいる。例えば、それぞれのエッジクラウドは、一式の計算リソースを管理する小さなオーケストレーションインスタンスを有する。エッジクラウドのグループは、オーケストレーションクラスタとして設定され得る。一旦、リソースが利用可能になると、エッジは、自動的に、クラスタ内のエッジオーケストレーションピアに対して、それらのリソースをアドバタイズし得る。エッジオーケストレーションピアは、他のリソースマネージャ／オーケストレータに、リソースのうち一部または全てを特定の量の時間についてリザーブするように要求し得る。リソースマネージャは、その時間期間についてリソースがもはや利用可能ではないことをブロードキャストし得る。

【0550】

オーケストレーションは、プロバイダ対プロバイダモデルまたはプロバイダ対サービス／カスタマモデルを使用して、提供され得る。プロバイダ対プロバイダ(P/P)モデルにおいて、オーケストレータは、増加する負荷、所定の時間について予測される負荷の増加、等といった、ファクタに基づいて、別のピアからリソースを要求し得る。プロバイダ対サービス／カスタマ（P/S）モデルにおいて、サービスは、追加のリソースを見つけるか、または、リソースのボローイングを通してオーケストレータによって満足され得るサービスの別のインスタンスを開始するように、オーケストレータに依頼し得る。これらの技術は、サービスの利用可能性を増加させることができ、効率的なリソース利用でTCOを改善し、もしくは、特定のエッジまたはデバイスにおいてどのリソースが提供され、そして、提供されないかという観点でフレキシビリティを提供する。P/PモデルまたはP/Sモデル、もしくは、他の類似のモデルにおいては、リソースが所定のコストで共有または露出され得るので、コストの次元が考慮されてよい。

【0551】

一つの例においては、ETSI MEC規格が、使用される所与のサービスに係るローカリティの範囲を含むように修正され得る。例えば、事前に合意されたような、固定の時間量についてのリソースのリザーブは、規格を修正するために使用され得る。

【0552】

図33は、異なるエッジクラウドロケーションにおけるオーケストレータのドメイン分離を示すシステム3300を図示している。システム図3300は、２つの異なるエッジクラウドロケーションを含み、異なるエッジクラウドの中の各エッジ(クラスタ3310の中のエッジ3311、3312、3313、および、クラスタ3320の中のエッジ3321、3322、3323)はオーケストレータのインスタンスを有している。エッジクラウドロケーションは、また、２つの異なるクラスタ3310、3320それぞれにおいて形成されているように、システム図3300に示されている。

【0553】

図34は、エッジクラウドの領域を管理しているエッジクラウドオーケストレータを示すシステム3400を図示している。システム図3400は、システム図3300とは対照的に、ある領域内の複数のエッジロケーション(例えば、領域1 3410の中のロケーション3411、3412、3413、および、領域2 3420の中のロケーション3421、3422、3423)が、(例えば、セントラルオフィス内の)リモートオーケストレータによって管理される、オーケストレーションスキームを示している。システム図3400に一緒に示される２つの領域3410、3420は、領域にわたりリソースを借りることを可能にする、といったように、クラスタを形成し得る。各領域は、各エッジロケーションが独自のオーケストレータを有しているのではなく、むしろ、単一のオーケストレータ(例えば、3411、3421)を有し得る。クラスタは、エッジロケーションのローカリティ(ゾーニング)またはエッジクラウドタイプ(例えば、全てのストリートキャビネットが１つのクラスタ内にあり、一方で、セルタワーは別のクラスタ内にあり得る)といった、複数のファクタに基づいて作成され得る。領域セキュリティポリシは、ドメインコンテキストに対して動的に供給され得る。ここで、許容可能な複数地域ポリシが、ドメインコンテキストに対して決定され得る。例えば、領域1と領域2の結合(例えば、ドメイン1)は、最小の共通アクセスが保証されることを確保する。従って、そうした構成は、ドメインコンテキストの動的なフォーメーション(並びに、静的なフォーメーション)をサポートしている。

【0554】

図35は、リソースのブロードキャストおよびボローイングの例を示すための、３つの異なるオーケストレータ間のフロー図3500を図示している。一つの例において、フロー図3500の３つのオーケストレータは、異なるエッジロケーション(例えば、図34の領域)に属してよい。オーケストレータは、リソースの利用可能性をブロードキャストすること、リソースを要求または割当てること、もしくは、ブロードキャストを介してリソースの利用可能性を更新し、そして、次に、借用したリソースを解放すること、のために使用され得る。他のバリエーションおよび動作シーケンスが、このフレームワーク内で適用され得ることが理解されるだろう。

【0555】

例えば、図35におけるオーケストレータ1(3511)は、オーケストレータ2(3512)およびオーケストレータ3(3513)の両方に対してリソースの利用可能性をブロードキャストしているように示されており、他のオーケストレータに対して、順番に、それらの利用可能性をブロードキャストする。リソースは、オーケストレータ間で、要求され、割当てられ、そして、リターンされ得る。リソースの利用可能性は、割当て又は要求の後で、および、リターンの後で再び、再ブロードキャストされ得る。オーケストレータは、要求があれば、例えば、オーケストレータの領域内のエッジロケーションについて、オーケストレータの領域内のデバイスに代わってリソースをリザーブし得る。さらなる例においては、オーケストレーションシーケンスの実行が、モデル化され、または、シミュレーションされ得る。

【0556】

一つの例において、3511、3512、3513といった、エッジオーケストレータは、計算リソースのボローイング－レンディングを促進することに加えて、グループ全体のアドミッション制御ポリシを実装することができる。リソースがリザーブ解除されると、オーケストレータは、新たな要求のバーストがトラフィック形状(または、ある拒否されたサービス)であり得るように、アドミッション制御ポリシを実装することによって補償することができる。新規クライアントを受け入れることが、ジッタを追加し、または、既存のSLA保証に違反する場合、といったものである。

【0557】

オーケストレーションクラスタは、リソースボローイングが変調される際にどれだけのリソースボローイングが実行され得るかを決定するために、フォワード使用予測を実行することができる。例えば、エッジサーバはCPUヘッドルームを有しているので、エッジサーバは、追加的なフローを受け入れることができる。しかしながら、エッジサーバは、処理を進めるのに十分なメモリまたはストレージヘッドルームを保持するように、より重要度が低い、または、現在スリープしているメモリホッグをスワップアウトするために、高性能ストレージプールからの容量をリザーブする必要があり得る。これを効果的に(かつ、スラッシュではなく)行うために、オーケストレータ3511、3512、3514は、どれだけの量のメモリを開放し、そして、必要なスワップのためにどれだけのIO帯域幅が必要とし得るかを予測することができる。一つの例においては、これらのメトリクスに到達するために、オーケストレータ3511、3512、3514は、作業負荷のタイプまたは特性に基づいてこれらの要求を予測することができるモデルを使用し得る。さらに、オーケストレータ3511、3512、3514は、実施ポイントに対するLSMの最も効率的なプロビジョニングのためにポリシをネゴシエートすることができる。

【0558】

サービスは、これらのエッジオーケストレータ3511、3512、3514を用いて登録することができる。サービスは、また、モデルパラメータも登録することができる。オーケストレータ3511、3512、3514はエッジテレメトリと共にパラメータを用いて、どれだけの量を、そして、どれだく長く借用し、または、解放するのか評価する。

【0559】

異なるエッジクラウドが異なるエネルギーおよび熱特性を有し得るとすれば、3511、3512、または3514といったエッジオーケストレータは、DCサーマルヘッドルームのために、エッジクラウドにおける活動を低減し、かつ、リソースを解放するように選択することができる。これらのサービスは、借用されたリソースにおいて実行され得る。

【0560】

さらなる例において、リソースをブロードキャストするための方法は、以下の動作またはその変形を使用して、エッジ領域(例えば、エッジクラウド110の一部分、および、ノードもしくはデバイス2200、2232、2240、または2250、において又はそれによって実装されるといった実装システムおよびデバイスの中)においてオーケストレーション技術を実装することができる。

【0561】

本方法は、他のオーケストレータ3512、3513とインタラクションするためにオーケストレータ3511を実行する第１動作を含み、オーケストレータ3511は、オーケストレータ3511に対応する領域の中でエッジノード間のリソースを連携している。一つの例において、オーケストレータ3511および他のオーケストレータ3512、3513は、クラスタのメンバーである。クラスタは、オーケストレータおよび他のオーケストレータに対応している領域の中でエッジの近接に基づいて選択され得る。別の例において、クラスタは、エッジデバイスタイプに基づいて選択され得る(例えば、ストリートキャビネットをストリートキャビネットと連携し、そして、セルタワーをセルタワーと連携する)。

【0562】

本方法は、さらに、領域内で利用可能でないリソースに対する要求を識別するための第２動作を含む。この動作は、領域内で利用可能なリソースが閾値を下回ると決定することを含み得る。この動作は、領域内のノードのサービスから要求を受信することを含み得る。

【0563】

本方法は、さらに、リソースを要求するように、他のオーケストレータと連携するための第３動作を含む。本方法は、さらに、他のオーケストレータのうちの１つからリソースの割当てを受信するための第４動作を含む。

【0564】

さらなる例において、本方法は、オーケストレータ3511から他のオーケストレータ3512、3513へ、領域内で利用可能なリソースをブロードキャストすることを含み得る。一つの例において、本方法は、領域内でリソースの使用が完了したときに、他のオーケストレータ3512、3513のうちの１つに指示を送信することによってリソースをリターンすることを含み得る。リソースをリターンした後に、他の変更またはリソースのリリース／解放アクションが発生し得る。

【0565】

リソースブロードキャスティングを実装するための第１の例示的方法(例G1)は、処理回路(例えば、ノード、もしくは、デバイス2200、2232、2240、または2250)を使用して実行される方法である。本方法は、他のオーケストレータとインタラクションするためにオーケストレータを実行し、オーケストレータは、オーケストレータに対応している領域内のエッジノード間でリソースを連携する、ステップと、領域内で利用可能でないリソースに対する要求を識別するステップと、リソースを要求するために他のオーケストレータと連携するステップと、他のオーケストレータのうちの１つからリソースの割当てを受信するステップと、を含む。

【0566】

第２の例(実施例G2)において、実施例G1の技術的事項は、リソースに対する要求を識別するステップは、領域内の利用可能なリソースが閾値を下回ると決定すること、を含む。

【0567】

第３の例(実施例G3)において、実施例G1－G2の技術的事項は、リソースに対する要求を識別するステップは、領域内のノードのサービスから要求を受信すること、を含む。

【0568】

第４の例(実施例G4)において、実施例G1－G3の技術的事項は、オーケストレータおよび他のオーケストレータがクラスタのメンバーであること、を含む。

【0569】

第５の例(実施例G5)において、実施例G4の技術的事項は、クラスタが、オーケストレータおよび他のオーケストレータに対応している領域の中でエッジの近接に基づいて選択されること、を含む。

【0570】

第６の例(実施例G6)において、実施例G4－G5の技術的事項は、クラスタが、エッジデバイスタイプに基づいて選択されること、を含む。

【0571】

第７の例(実施例G7)において、実施例G1－G6の技術的事項は、オーケストレータから他のオーケストレータへ、領域内で利用可能なリソースをブロードキャストすること、を含む。

【0572】

第８の例(実施例G8)において、例G1－G7の技術的事項は、リソースの使用が領域内で完了したときに、他のオーケストレータのうちの１つに対して指示を送信することによってリソースをリターンすること、を含む。

【0573】

様々な設定において、実施例G1－G8(および、ブロードキャスティングリソース借り手情報の他の態様)は、定義されたアプリケーションプログラミングインタフェースまたはインタフェース仕様、リソース動作を起動、受信、または制御するためのプロトコルまたは定義の使用、および、エッジコンピューティングクラスタまたは環境の中でオーケストレータによって追跡されるリソース情報の実装、の結果として観察またはモニタリングされ得る。実施例G1－G8およびリソースボローイング動作の他の態様は、また、サービス動作およびサービス機能(例えば、FaaSまたはEaaS設定内でリソースを共有または調整するため)の結果としても観察または実施され得る。加えて、実施例G1－G8の方法は、実施される命令として(例えば、命令が実行されたときに本方法を実行する機械で読取り可能な媒体を用いて)、または、実施されるハードウェア構成として(例えば、本方法を実行または達成するための構成を含む装置を用いて)提供され得る。従って、実施例G1－G8の特徴(および、リソース管理の他の特徴)は、システムオーケストレータまたはアーキテクトによって連携または設計されるように、エッジクラスタまたはエッジクラウドシステムを構成するために、ここにおける他の実施例のいずれかと組み合され得る。

【0574】

データ集約ポリシの実施例

【0575】

エッジクラウドインフラストラクチャは、複数のソースからのデータを保管するために使用され得る。データは、エッジデバイスにおいて収集され、そして、任意的に結合され得る。エッジロケーションにおいてデータリソースを共有することは、テナントまたはやユーザのプライバシー問題が発生し得る。以下の例示的なシステムおよび方法は、エッジコンピューティングシステム(例えば、エッジクラウド110、および、図3から図22Dまでに示されるエッジコンピューティングシステム構成)のデータサプライチェーンにおける、これら及び他の問題に対処する。特には、データの集約を可能にすることによるプライバシーに関連するものである。エッジデバイスでのデータ集約または処理は、低電力デバイス(例えば、IoTデバイス)で電力を節約するため、もしくは、計算能力なし又は計算能力なしで、センサのための計算を提供するために有用である。

【0576】

以下の例は、エッジデバイスにおいて多くのタイプのデータを集約することに関連する。IoTデバイス、車、ドローン、携帯電話、センサ、等といった、デバイスは、しばしば、特定の目的のために、データを生成する。このデータは、その直接の目的を超えて有用であるが、データの収集、保守、および評価が、デバイス上では困難なことがある。

【0577】

例えば、モバイルデバイス(例えば、自律自動車、ドローン、電話、等)は、多くのセンサデータを収集するが、センサデータを処理するための計算能力が制限されていることがある。モバイルデバイスは、特定のタスク(例えば、自動車を道路上に保持すること)のためにデータを収集することができる。データは、次いで、タスクが果たされた後などで、モバイルデバイスに対して役に立たなくなってよい(例えば、車が交差点を通過したときに、交差点に関するセンサデータを削除してよい)。エッジ処理ノード(例えば、基地局、小セル、等)は、より多くの計算能力を有し、そして、これらのモバイルデバイスを含む、複数のデバイスからデータを受信することができる。

【0578】

エッジデバイスは、複数のデバイスからのセンサデータを結合することができる。例えば、エッジデバイスは、同様のタイプの複数のデバイス(例えば、自動車)からデータを受信し、そして、そのデータを集約することができる。別の例において、異なるデバイスは、エッジデバイスにおいて集約されるデータを提供することができる。例えば、エッジデバイスは、(例えば、異なる自動車またはドローンにおける)複数のカメラからのビデオシューティングを結合することによってエリアの3Dモデルを作成するために、集約されたデータを使用することができる。データの集約は、個々のデバイスデータに関する問題を回避することができる(例えば、１台の自動車が１つの車輪におけるスリップを観測した場合には、測定のエラーであり得る)。集約データ、例えば、いくつかの自動車が同じロケーションでスリップを観測し得ること、の使用は、そのロケーションで道路が滑りやすいことを示している。

【0579】

図36は、いくつかの例に従って、エッジデバイスにおいてデータを集約するためのアーキテクチャを含む、システム3600のダイヤグラムを示している。

【0580】

システム3600は、データ提供装置3630からのデータを集約するために使用されるエッジアーキテクチャの異なるエレメントを含んでいる。システム3600は、例えば、データマネージャコンポーネント3620の中で集約機能を保管および登録することに責任を負う命令(例えば、アルゴリズム、ロジック、等を実装するもの)を有するプラットフォーム3610を含む。登録インタフェースは、変換機能の登録を可能にする。変換機能は、機能が適用されるデバイス3641またはセンサタイプを含み得る(例えば、センサタイプは、自動車で測定された温度を含んでよい)。

【0581】

システム3600は、集約機能3642自体を含み得る。例えば、エッジデバイスからのデータセットのリストが与えられるとすれば、集約機能3642は、計算を実行し、そして、クラウドデータプロバイダ3660に保管され、または、送信される単一の値を生成し得る。

【0582】

システム3600は、集約の間隔3643を含み得る。このインターバル3643は、計算を実行する前に、アグリゲータが、そのデバイスタイプIDについてデータを保管するために使用可能な時間の単位(例えば、秒、分といった、時間インターバルで)をいくつ有しているかを示している。別の例において、集約の間隔は、時間単位の代わりに、または、加えて、データが受信される回数を含んでよい。

【0583】

システム3600は、アグリゲータに対してデータを送信するためにデバイス3630によって使用されるインタフェースを含んでいる。集約ロジックは、インタフェース(例えば、アグリゲータに対してデータを送信するためにデバイスによって使用されるインタフェース、または、クラウドデータプロバイダとのインタフェース)を実装する責任を負うことができる。集約機能は、ローカルストレージメモリ強調ポイントであってよく、そこで、ローカルストレージメモリ3650は、集約を使用して、プライバシーに敏感なコンテンツを保護し／不明瞭にするためのセキュリティポリシを含み、または、提供する。（従って、ユーザが集約を要求しなかった場合でも、ローカルストレージメモリ3650は、プライバシーを保護するために集約を適用することができる。）

【0584】

計算コンテキスト(例えば、センサタイプ、同じソースまたは比較可能なソースの過去のトレンドデータ、データソース比較値、または、信頼感を示し得る他の値)が、受信したデータの信頼性を決定するために使用され得る。例えば、検知されるデータに対して「近い（”close”）」センサによって供給されるデータは、より少なく「近い」センサからのデータよりも信頼でき、または信頼性が高いだろう。このコンテキストで「近く」にあることは、物理的な特性であってよく、または、接続性の特性(例えば、センサが、そのセンサによって測定されるデータを生成するシステムに対して検証されているか否か)であってよい。データを解釈する機能に対する「近さ」も、また、信頼性において考慮すべき事項であり得る。ローカリティに係る相対的な「近さ」は、「遠い」ローカリティを有するある場所から到着した場合よりも、データの信頼性が高いことを意味する。さらなる例において、距離がプロバイダのタイプに依存するように、近さの概念が拡張され得る(例えば、第１組織と関連するプロバイダは、１マイル＝１マイルといった、第１メトリックを用いて計算された距離を有し、これに反して、第２組織と関連するプロバイダは、１マイル＝２マイルといった、第２メトリックを用いて計算された距離を有する)。

【0585】

エッジデバイスは、信頼テストの一部としてデータローカリティを評価し得る。データが、保持されているが、リモートノードに戻って通信される場合に、そのデータは、より少ない信頼性のものとして扱われ得る。ローカル計算が集約を結果として生じる場合(例えば、テレメトリについて)、ノードは、それを高いインテグリティ値であるものと見なし得る。この例において、ピアノードは、それ自身のローカリティテストおよび信頼セマンティクス(例えば、第１ノードの信頼性)に基づいて、その値を下げてよい。

【0586】

さらなる例において、エッジデバイスにおいてデータを集約するための方法は、以下の動作を含み得る(例えば、ノード、もしくは、デバイス2200、2232、2240、または2250において、または、それによって実装されるような、エッジクラウド110におけるシステムおよびデバイスによって実装される)。

【0587】

本方法は、エッジノードにおいて、複数のモバイルデバイスからのデータを受信するための第１動作、を含む。

【0588】

本方法は、エッジノードの集約ロジックを使用して、受信したデータを集約するための第２動作、を含む。一つの例において、データは、特定の量のデータ(例えば、送信またはパケットの数)が受信されるまで、または、特定の数のデバイスからデータが受信されるまで、時間間隔といった、間隔にわたり集約され得る。

【0589】

本方法は、集約されたデータ、および、エッジノードにおける集約機能に基づいて値を生成するための第３動作、を含む。

【0590】

本方法は、クラウドデバイスに対して値を送信するための第４動作、を含む。一つの例において、値は、後に受信されるデータを検証するために使用され得る。別の例において、値は、領域の詳細なマップを作成するために使用され得る。さらに別の例において、値は、モバイルデバイスの機能を検証するために使用され得る。なおも別の例において、値は、使用データを生成するため、フィードバックを提供するため、または、セキュリティ設定において使用され得る。

【0591】

本方法は、受信したデータの信頼性レベルを決定するための第５動作、を含む。信頼性は、値を伴って出力され得る。一つの例において、データの集約は、受信データの信頼性におけるファクタリングを含んでよく、例えば、値は、信頼性に基づいて決定されてよい。

【0592】

マルチエッジデータ集約ポリシを実装し、かつ、使用するためのさらなる例示的な方法(実施例H1)は、(例えば、ノード、もしくは、デバイス2200、2232、2240、または2250の)処理回路を使用して実行される方法である。本方法は、エッジノードにおいて、複数のモバイルデバイスからデータを受信するステップと、エッジノードの集約ロジックを使用して、受信したデータを集約するステップと、集約されたデータおよびエッジノードにおける集約機能に基づいて、値を生成するステップと、クラウドデバイスに対して値を送信するステップと、を含む。

【0593】

第２の例(実施例H2)において、実施例H1の技術的事項は、受信データをインターバルにわたり集約することによって、受信したデータを集約すること、を含む。

【0594】

第３の例(実施例H3)において、実施例H2の技術的事項は、構成を含み、そこで、インターバルは、時間間隔、受信される特定量のデータ、または、そこからデータを受信する特定数の受信デバイス、を含む。

【0595】

第４の例(実施例H4)において、実施例H1－H3の技術的事項は、後に受信されるデータを検証するために、値が使用される構成、を含む。

【0596】

第５の例(実施例H5)において、実施例H1－H4の技術的事項は、領域の詳細なマップを作成するために、値が使用される構成、を含む。

【0597】

第６の例(実施例H6)において、実施例H1－H5の技術的事項は、モバイルデバイスの機能を検証するために、値が使用される構成、を含む。

【0598】

第７の例(実施例H7)において、実施例H1－H6の技術的事項は、使用データを生成するため、フィードバックを提供するため、または、セキュリティ設定において、値が使用される構成、を含む。

【0599】

第８の例(実施例H8)において、実施例H1－H7の技術的事項は、受信したデータの信頼性レベルを決定すること、を含む。

【0600】

第９の例(実施例H9)において、実施例H8の技術的事項は、信頼性レベルを出力することによって、値を出力すること、を含む。

【0601】

第１０の例(実施例H10)において、実施例H1－H9の技術的事項は、受信したデータの信頼性を使用することによって、受信したデータを集約すること、を含む。

【0602】

様々な設定において、実施例H1－H10(および、データ集約ポリシの他の態様)は、定義されたアプリケーションプログラミングインタフェースまたはインタフェース仕様、アクセラレーションを起動、受信、または制御するためのプロトコルまたは定義の使用、および、エッジコンピューティング環境の中のポリシ、ロジック、およびマップ(データ転送を介して通信されるものを含む)の他の使用および実装、の結果として観察またはモニタリングされ得る。実施例H1－H10において表されるようなデータ集約ポリシは、また、サービス内で行われる動作の後で、または、その一部として実施することもできる(例えば、FaaSまたはEaaSの一部として実施または達成される)。加えて、実施例H1－H10の方法は、エッジコンピューティングシステムにおいて、実施される命令として(例えば、命令が実行されたときに本方法を実行する機械で読取り可能な媒体を用いて)、または、実施されるハードウェア構成として(例えば、本方法を実行または達成するための構成を含む装置を用いて)提供され得る。従って、実施例H1－H10の特徴(および、データ集約の他の特徴)は、システムオーケストレータまたはアーキテクトによって連携または設計されるように、エッジクラスタまたはエッジクラウドシステムを構成するために、ここにおける他の実施例のいずれかと組み合され得る。

【0603】

リソースフェンシングを用いてプレミアムサービスを保証することの実施例

【0604】

エッジコンピューティングは、しばしば、ネットワークのエッジにおかれるように、モジュラコンピューティングプールを物理的に配置することを含んでいる。これは、一般的に、例えば、リアルタイムデータストリームを処理する場合に、待ち時間に敏感な多様なアプリケーションをサポートするために行われる。エッジコンピューティングのインストレーションは、スマートシティ、拡張または仮想現実、支援または自律運転、ファクトリーオートメーション、および脅威検出、等といった、様々なユースケースをサポートするように拡大している。いくつかの新たなアプリケーションは、イベントトリガー分散機能といった、計算またはデータ集約型アプリケーションをサポートすることを含む。データを生成するデバイスについて基地局またはネットワークルータに対する近接性は、迅速な処理における重要なファクタである。いくつかの例において、これらのエッジインストレーションは、リアルタイムな計算を実装するためのメモリまたはストレージリソースのプールを含み、一方で、バックエンドクラウドにおけるさらなる処理のために、高レベルの要約(例えば、集約)またはフィルタリングを実行している。

【0605】

エッジアーキテクチャは、一般的に、多くのデバイスの分散インストレーションを含んでいる。そうしたネットワークを構築することは、資本集約的であり得る。次世代の基地局およびセントラルオフィスにおいて考慮されているエレメントは、プレミアムサービスのための主要パフォーマンス指標(KPI)を損なうことなく、設備投資(CAPEX)を削減することである。この目的を達成するために、AR/VRといった、複数の高リソース要求サービスが、オペレータのコアビジネスをサポートするセルラ仮想ネットワーク機能(VNF)といった、高サービスレベルアグリーメント(SLA)、または、収益クリティカルな作業と一緒に並べられてよい。

【0606】

収益が重要なプレミアムサービスをサポートするために、オペレータハードウェアは、バリュー処理（value-processing）のために、やって来るトラフィックを吸収できる必要があり、一方で、品質目標が損なわれないように、重要な作業負荷に対して割当てられた計算リソースをモニタリングおよび管理している。伝統的に、サービス品質(QoS)を保証するために、リソースがプレミアムサービスについてリザーブされている。これらのリザーブされたリソースは、その利用可能性を保証するために、他の作業のためには使用できない。しかしながら、非プレミアムサービスも、また、たとえ比較してミッションクリティカルでなくても、同様のリソース(例えば、広帯域幅、電力、等)を必要とするため、このことは、フラグメンテーションおよび高いリソースコストにつながる。従って、ハードウェアプラットフォームは、十分に活用されていない多くの冗長なリソースを含む傾向がある。このようにして重要なオペ動作を分離することは、単にコストを増加させ、効率を低下させるだけでなく、それは、また、エッジクラウドの弾力性を低下させ、エッジクラウドエコシステムにおける新たなサービス、利用モデル、および収益機会の急速な成長を吸収するための能力も制限する。

【0607】

繰り返しになるが、プレミアムサービスへの排他的なリザベーションは、非プレミアムサービスも、また、同様のリソース要件を有するので、エッジデータセンタ内に多数のリソースをインストールする必要性を増加させている。負荷バランシングは、一般的に、それらがプレミアムクライアントのサービスにおけるものであるか否かに応じて、ハードウェアアクセラレーション動作を含み、類似の計算間を連続的に区別するために必要とされる。このように、負荷バランシングは、一般的に、待ち時間および追加的なトランスポート動作を追加する。従って、このようにしてQoSを保証することは、所有の総コスト(TCO)および設備投資を増加させ、一方で、また、エッジデータセンタをフラグメンテーションオーバーヘッドにさらしている。リソースをサイロに入れること（例:サイロ化)は、また、利用可能なインフラストラクチャを、プレミアムQoSまたは通常QoSのどちらかであり得る新たに出現している成長機会に専念させるフレキシビリティを低下させる。

【0608】

これらの問題に対処するために、弾力的アプローチが使用される。そこでは、リソースがプールされ、そして、利用可能なリソースプールがプレミアム作業および非プレミアム(例えば、通常の)作業の間で共有されている。プールされたリソースは、必要性の増加につれて、動的かつシームレスに、より高い優先度の作業へシフトされ、さもなければ残りの作業を取扱うためにリソースをフリーのまま残している。さらに、いくつかの例において、プールされたリソースは、１つのエッジサーバまたはクラスタを形成している複数のエッジの中にプールされてよい。

【0609】

そうしたプールされたリソース管理は、段階的なQoSを提供する。そこでは、プレミアムサービスについてSLA違反が予測されるまで、サービスは、リソースに対する公平なアクセスを享受する。SLAの中断が検出または予測された場合には、重要なサービスのSLAを維持するために、リソースは、速やかに再割当てされ得る。

【0610】

このアプローチは、プレミアムサービスのためのKPIが必ずしもデッドラインとして存在するわけではないので、デッドラインドリブンなスケジューリングとは異なるものである。例えば、第５世代携帯電話(5G)の回線速度の必要性は、複数のVNFにわたり分散されている。また、典型的なデッドラインスケジューリング手順は、一度に１つのシステムまたはリソースにおいて動作する。これらの手順は、あまりにも少なく、あまりにも遅いだろう。特に、99パーセンタイルの待ち時間が、複数の－しばしば何百もの－チェーン化されたインタラクションにおける異なるコンポーネントに及ぶエンドツーエンドのチェーンにおいて一度に１つの待ち時間を緩和することによっては、低減することがはるかに困難な環境において、そうである。

【0611】

エッジコンピューティングシステム(例えば、エッジクラウド110、および、図3から図22Dまでに示されるエッジコンピューティングシステム構成)において適用可能な一つの例においては、エッジゲートウェイ内のハードウェアモニタリングが、VNFの挙動を観察するために使用される。つまり、リソースされることが許されないファーストクラスのプレミアムサービスは不足している。いくらかのリソースの輻輳(例えば、メモリ、計算機、等)のせいで経験パフォーマンスの劣化が発生した場合に、エッジゲートウェイは、例えば、VNFをサービスすることにおいて必要とされるパフォーマンスレベルが達成されるまで、他の、非クリティカルな、サービスからリソースを自動的に再割当てするように設定されている。

【0612】

これらの技術は、例えば、HWベースの自動タイムスタンピングを使用して、時間連携されている計算におけるエンドツーエンド待ち時間を減少させるように動作する。従って、複数の基地局およびセントラルオフィス(CO)環境にわたり分散され、かつ、高いSLAコンプライアンスを必要とする動作－例えば、多地点監視、リモート医療、移動局におけるリアルタイムなモバイルコーディネーション、等－は、サイロ容量を過剰に供給することなく、バースト到着の下でジャストインタイムにアクセラレーションされ得る。従って、TCOおよびCAPEXは、異なるサービスに対する排他的なリザベーションを回避することによって削減され、そして、SLA違反の可能性が高くなったときに、サービス間のリソース割当ての迅速なリフローを可能にし得る。また、リソースのモニタリングおよび再割当ては、エッジゲートウェイに対するハードウェア拡張として実装されるので、ソフトウェアレベルのオーバーヘッドは完全に回避される。実際、多くのソフトウェアレベルのリソースモニタリングおよび再割当ての試みでは、サービスが時間通りに完了されことはできないだろう。加えて、エッジクラウドのシナリオにおいて、SLAとQoSの合意は、本質的に動的であり、かつ、予測不可能である。例えば、日中の異なる時点における特定のサービスについて、そして、また、サービスチェーン内にわたる異なるサブ機能間において、異なるQoSレベルが必要とされ得る。同様に、QoSの合意も、また、頻繁に変更され得る。そうした状況において、排他的なリザベーションは、一般的に、ソフトウェアレベルのオーケストレータによって再マッピングされ、そして、多くの場合、管理者の介入が必要とされ得る。このことは、保守および検証コストを増加させる。

【0613】

図37は、エッジゲートウェイアーキテクチャ3700の一つの例を示している(例えば、エッジクラウド110の実装を提供する)。エッジゲートウェイ3720は、基地局またはセントラルオフィスでのエッジアーキテクチャに対する拡張として動作し得る。QoS予測回路(例えば、プラットフォーム内のマイクロコントローラを介して、または、他の回路を介して実現されるもの)が、エッジゲートウェイ3720、および、エッジコンピューティングプラットフォーム(例えば、エッジコンピューティングプラットフォーム3732、3734)内のインテリジェントネットワークコントローラ3702および3704(iNIC)に追加されている。他の示されるエレメントは、ファブリックマネージャ3710、－VNF3705、3706、および3707といった－様々なアプリケーション、および、テーブル3736といった様々な構成テーブルを含んでいる。

【0614】

QoS予測回路は、VNFリソースに対するインタフェースを露出するように構成されている。一つの例において、VNFは、プロセスアドレス空間識別子（PASID）3738によって識別される。QoS予測回路は、VNFと通信するために必要とされる最小帯域幅についてインタフェースを露出するように構成されている。これらのインタフェースは、VNFを実行することによってどのリソースが要求されるか、並びに、リソース3740に対するVNFの動作パラメータに関して、QoS予測回路に対して情報を提供する。QoS予測回路は、各VNFが(例えば、変化している)KPIターゲット3742を満たすために十分なプラットフォームリソースを有するか否かを追跡するために、この情報を使用するように構成されている。

【0615】

QoS予測回路は、高い優先度のVNFのために、利用率の閾値(例えば、70%)に近づくときに、リソースを漸進的にリザーブするように構成されている。QoS予測回路は、ヒステリシスのため、一旦、利用率が、上記から第２閾値(例えば、60%)へ低下すると、リソースを解放するように構成されている。

【0616】

QoS予測回路によって考慮されるリソースは、プラットフォームリソース(例えば、メモリ、CPUサイクル、電源、等)、または、相互接続リソース(例えば、利用可能なNICまたはスイッチ帯域幅)の両方であり得る。ストレスが低いときに、QoS予測回路は、高レベルな共有を効果的にサポートする。

【0617】

エッジゲートウェイ3703は、QoS予測回路と同様に拡張され、これは、また、異なるプラットフォームにおけるVNF(PASID)によって、どれだけのプラットフォーム最小帯域幅が通信のために必要とされるかを登録するためのインタフェースを露出する。エッジゲートウェイ3703内のQoS予測回路も、また、連続ベースで、帯域幅利用率、および待ち時間を追跡するように構成されている。プラットフォーム内の対応するQoS+予測ロジックと同様に、エッジゲートウェイ3720においても、また、利用率の閾値に基づいて、ファブリッククレジットをリザーブまたはリリースする。それらをリザーブおよび解除する動作は、図37にRsr/Relとして示されている。しかしながら、図37において提供されるスループット値および他のプロパティは、他の値がそれぞれの展開において利用されるので、説明の目的のための提供されていることが理解されるだろう。

【0618】

一つの例において、QoS予測回路は、各VNFへとやって来る要求率に基づく、ハードウェアベース(例えば、フィールドプログラマブルゲートアレイ(FPGA))の分析および予測を含む。情報はプラットフォームに対して伝播され、プラットフォームは、リザベーションの攻撃性を上げ、または、下げるために情報を利用する。

【0619】

エッジインフラストラクチャ(例えば、エッジクラウド110、および、ノード、もしくは、デバイス2200、2232、2240、または2250上で、もしくは、それらによって実装されるといった、実装システムおよびデバイス)において、保証されたプレミアムサービスを効率的に実装するための第１の例示的な方法(実施例I1)は、処理回路を使用して実行される方法を含む。本方法は、エッジノード内にリソースプールを生成するステップと、エッジノードのインテリジェントネットワークコントローラ(iNIC)内の品質制御回路によって、サービス毎の要求率を測定するステップと、品質制御回路によって、サービスに対するリソース割当てを超えるクリティカルなサービスのための可能性あるリソースの必要性を決定するステップと、含み、そして、可能性あるリソースの必要性を満たすために、リソースプールからクリティカルサービスへリソースを再割当てする。

【0620】

第２の例(実施例I2)において、実施例I1の技術的事項は、エッジノードがエッジゲートウェイである構成、を含む。

【0621】

第３の例(実施例I3)において、実施例I2の技術的事項は、サービスが、エッジゲートウェイによってサービスされるプラットフォームにおいて実行している構成、を含む。

【0622】

第４の例(実施例I4)において、実施例I1－I3の技術的事項は、品質制御回路がフィールドプログラマブルゲートアレイである構成、を含む。

【0623】

様々な設定において、実施例I1－I4(および、プレミアムサービスオペレーションの他の態様)は、定義されたアプリケーションプログラミングインタフェース、またはインタフェース仕様、プレミアムサービスを呼び出し、または、修正するためのプロトコルまたは定義の使用、および、エッジコンピューティング環境内のサービスのためのリソースフェンシングまたは他のリソース割当ての他の使用および実装の結果として、観察またはモニタリングされ得る。実施例I1－I4及びこれらのプレミアムサーバ技術の他の態様も、また、サービス動作およびサービス機能の結果として(例えば、FaaSまたはEaaS設定において提供されるサーバにおいて使用されるリソースを再割当てするために)観察または実装され得る。加えて、実施例I1－I4の方法は、エッジコンピューティングシステムにおいて、実装される命令として(例えば、命令が実行されたときに本方法を実行する機械で読取り可能な媒体を用いて)、または、実装されるハードウェア構成として(例えば、本方法を実行または達成するための構成を含む装置を用いて)提供され得る。従って、実施例I1－I4の特徴(および、リソースフェンシングおよびリソース割当ての他の特徴)は、システムオーケストレータまたはアーキテクトによって連携または設計されて、エッジクラスタまたはエッジクラウドシステムを構成するために、ここにおける他の実施例のいずれかと組み合わされてよい。

【0624】

事前プロビジョニングされたハンドオフの実施例

【0625】

エッジクラウドコンピューティングシステムは、しばしば、計算のため又は通信のため（例えば、高帯域幅のリンク）のリソース(例えば、中央処理装置(CPU)、グラフィックス処理装置(GPU)、揮発性作業メモリ、不揮発性ストレージ、等)を過剰にコミットすることなく、リアルタイムに(例えば、待ち時間に敏感な)作業を実行するように展開されている。エッジクラウドは、しばしば、複数の理由により、作業負荷に対する過剰なリソース割当てを制限しようと試みる。特に、大規模なデータセンタークラウドとは異なり、エッジコンピューティングインフラストラクチャは、広い地理的な領域にわたり分散される傾向がある。その結果として、大規模かつリアルタイムに様々な動作を実行するために必要とされ得るマシンおよび電力を提供するために、一般的には、エッジにおいてリソースが少しだけしか存在しない。

【0626】

エッジクラウドにおいて発生し得る問題のうち別の例は、データを配分するためにかかる時間を含む。つまり、データの配分には時間がかかり、そして、そうするためにかかる時間は、発生し得るネットワーク集約的な活動の量における予測不可能な変動に左右される。エッジサービスに対する要求元は、人間からロボット装置、車両までの範囲にわたり、しばしば、エッジサービスを受けながら、ある物理的なロケーションから別のロケーションへ移動している。そうした動的かつ過渡的なエンティティのニーズに対応することは、最小限のネットワークホップでサービスを実行することを必要とし得る。このことは、要求元のために実行される処理を、要求元によって使用される通信エンドポイントに対して物理的に最も近いポイント(例えば、エッジクラウドにおけるエッジノード)へ移動することによって達成され得る。従って、ここにおいて、エッジサービスは、一度に１つの基地局(BS1)から、別の時間に別の基地局(BS2)へ移動することが期待され得る。実際には、この移動は、その移動要求元の通信エンドポイントがBS1のカバーエリアからBS2のカバーエリアへ移行する場合に、BS1に近い１つのマイクロデータセンタからBS2に近い別のマイクロデータセンタへの移動であってよい。

【0627】

移動するクライアント(例えば、サービス要求元)に追いつくために、ある物理的エッジノードから別のエッジノードへ作業負荷を移動することは、いくつかのロジスティックなハードルを含み得る。例えば、エッジサービスを移動するプロセスは、一般的に、そのエッジサービスと関連する状態を、あるロケーションにおけるあるホストから別のロケーションにおける別のホストへ、移転することを含む。実際のサービスインスタンスおよびそのセッションは、移転された状態を使用して、第１ホストで終了し(例えば、終了、シャットダウン、等)、第２ホストで開始(例えば、スタート、ブート、等)され得る。このプロセスは、たいてい、物理的なロケーションを移動している連続的なサービスとして要求元に対して提示される－しかし、要求元は、物理的なロケーションが実際に移動していることを判断することができない場合もある。関連する状態が以前のホストから次のホストへ移動されている一方で、サービス実行において十分に大きな中断が存在する場合に、連続的なサービスの幻想（illusion）は解消され得る。

【0628】

アプリケーションの高度化が進むにつれて、セッション状態として移転される情報の量も、また、増加する。従って、要求元があるポイントから別のポイントへ移動するにつれて、エッジインフラストラクチャ内の異なる計算ポイントで所与のアプリケーションを実行するための予測可能で、かつ、少ない待ち時間を維持することは、より困難になり得る。ますます、エンドツーエンドのインタラクション(例えば、リアルタイム通信)―モバイルビデオ分析プラットフォームとインタラクションするモバイルビデオ監視装置といった、実施例において一般的であるもの―においては、サービスの動作期待を満足するために、中間基地局が、サービスが各エンドにおいて変化し得るとしても、インタラクションの両方のエンドでの待ち時間の増加が制限される必要がある。

【0629】

これらの問題を取扱うために、いくつかのアプローチが試されてきている。いくつかのソリューション－クラウドゲーム、拡張現実(AR)または仮想現実(VR)のような視覚的または没入型アプリケーションにおけるソリューションといったもの－は、専用のプラットフォームおよびソリューション配信ポイントを使用することにより、リアルタイムでシームレスな高品質の体験の幻想を完成する。例えば、コンテンツデータネットワーク(CDN)－ストリーミングビデオサービスを配信するために使用される、といったもの－は、一般的に、近いエッジにおいて大量の処理能力を組み込むために、リソースが豊富なコンシューマ構内エッジ（CPE）サーバを使用する。この設計では、加入者が接続されている基地局が変更されても、なお、そうしたサービスが、それらの計算またはデータホストを移動する必要がほとんどない。さらに、サービスが移動しなければならない場合でさえも、移動は、十分にプロビジョニングされたデータセンタスケールのリソースを介して実行される。

【0630】

CPEベースの処理を用いたCDNのようなソリューションは、しかしながら、しばしば、多くの出現しているサービスに対して一般化できず、そこでは、プロバイダが、自身の近位端のデータセンタにおいて大量のインフラストラクチャを作成し、かつ、維持する能力を欠いている。この懸念を取扱うために、サービスマイグレーションのためのデータ転送は、要求元の動作と同時に実行され得る。ここで、モデルベースの予測技術は、セッション(例えば、サービス状態)移行のために使用され得る。例えば、モデルは、特定の要求元が、要求元が通信している現在の基地局から１つまたはそれ以上の潜在的な次の基地局へ移動する可能性を計算することができる。加えて、移行のために考慮される適用可能なサービス情報は、サービス状態、サービス動作自体、サービスデータ、または、潜在的なユーザーセッションを、含み得る。

【0631】

エッジコンピューティングシステム(例えば、エッジクラウド110、および図3から図22Dまでに示されるエッジコンピューティングシステム構成)において適用可能な一つの例において、モデルは、要求元の現在の軌跡(例えば、方向、速度、動きの連続性、等)に基づいて、最も可能性の高い次の基地局を識別することができる。一つの例において、本予測は、１つ以上の可能性あるターゲット基地局を識別することができる。ここで、モデルは、さらに、最も可能性の高い後続の(例えば、次の次である)基地局、またはステーションも、同様に識別することができる。一つの例において、本モデルは、要求元の動きの以前の履歴、要求元によって実行された検索クエリ、または要求元によって(例えば、マッピングまたはナビゲーションサービスを使用して)確立されてきた実際のルートに基づいて、要求元が通過するであろう最も可能性の高い基地局のシーケンスを識別することによって動作することができる。

【0632】

一つの例において、本モデルは、要求元が識別された基地局の間を通過するであろう、最も高い可能性の時点を予測する。これらの予測に基づいて、データは、要求元に対して近接の１つのポイントから、第２または後続の近接ポイントそれぞれへサービスセッションを移動させるために、マーシャル（marshal）され得る。一つの例において、データは、要求元の実際の移動より先に送信される(例えば、ストリーミング、マルチキャスト、等)。このデータの事前送信は、ジャストインタイムで実行され、予測された軌跡が要求元によって追跡されるときに発生するデータの実際の量を低減する。このようにして、計算リソースがデータロケーションに移動される際でさえ、適切な作業負荷およびサービスデータが計算リソースに対して移動され得る。

【0633】

一つの例において、本モデルは、負の確率を評価するように構成されている。ここで、負の確率は、基地局の以前に予測されたシーケンスが、要求元によって追従されない確率である。この予測は、要求元が接続する可能性が低い基地局に対して先に送信されるデータが、その基地局においては、もはやバッファされる必要がないので、リソースの解放を可能にする。このことは、例えば、要求元によって追従されている軌跡が、要求元について移動の経路に関する意図の変化を強く示唆する方法で以前に予測されていたものから離れる場合に生じ得る。

【0634】

予測モデルは、メカニズムを提供し、それにより、複雑なデータを転送するための追加時間を提供するためにサービス状態データが初期段階において移動され得る。従って、データ送信の待ち時間は、要求元に対して効果的に隠され得る。そうした予測モデルは、また、要求元の動きの変化するパターンに対しても自然に適応する。例えば、事故や渋滞のために高速道路において経路外れ（digression）が存在する場合に、モデルは、そうした観測に反応して、車両が最も取り入れる可能性の高い別の経路に予測を動的に変更する。データ転送待ち時間を低減すること又は除去することに加えて、予測モデルは、インフラストラクチャが、サービスがインスタンス化される必要がある時間より前に、要求元のニーズを満足し、または、それを上回るリソースを事前に調整する(例えば、事前の準備)可能性を作り出す。このプロセスにおいては、動的な最適化の機会が創生される。例えば、モデルは、一連のノード内の予測された次のノードにおいてアクセラレータの事前割当てを可能にし、そして、初期化待ち時間を回避するためにアクセラレータを事前プログラムすることができる。

【0635】

図38は、事前に提供されたハンドオフのための機械学習システム3800の訓練および使用に係る一つの例を示している。図示されたシステム3800は、以下のコンポーネントを含んでいる。予測および実行サブシステムのコンテキストにおいて動作する、軌跡キャプチャおよび関連付けサブシステム、軌跡アキュムレータ3801、コンテキスト、サービス、およびユーザデータベース3802、軌跡データベース3805、訓練サブシステム3803、テレメトリサブシステム3804、である。

【0636】

軌跡アキュムレータ3801は、要求側デバイスと、要求元がインタラクションする基地局との間の距離ベクトルを計算するように構成されている。これらのベクトルは、基地局のアイデンティティおよびタイムスタンプと共に記録される。軌跡アキュムレータ3801は、様々な基地局に進入または退出する際に、要求側デバイスによって移動される経路を符号化する軌跡ベクトルを計算するように構成されている。一つの例において、デバイスがその経路に沿って取った平均速度も、また、(例えば、計算された軌跡ベクトルと共に)記録されている。この情報は、エッジデータベース内に保存される。一つの例において、データは、デバイス自体においてキャッシュされてよい。この情報の取得は、エッジクラウドにおけるデバイスアクションまたはデバイスプロキシの使用に基づくものであってよい。データは、主として予測のために使用され、かつ、不正確な予測の結果は、しばしば、いくらかの効率の単なる低下に過ぎないため、この情報の正確性は、非常に精密(例えば、細分化)である必要はない。

【0637】

軌跡データベース3805は、軌跡アキュムレータ3801によって計算または収集された軌跡を保管するように構成されている。データベース3805は、データベース3802において、ユーザ(例えば、人間のユーザ)、軌跡が収集されたサービスまたはアプリケーション、もしくは、フレキシブルに定義され得る様々な意味のあるコンテキストといった、コンテキスト属性を用いて保管された軌跡を増強するように構成され得る。コンテキストの一つの例は、ルートの名前であってよい－「マイショッピングトリップ」、「自宅から仕事場へのルート」等、といったものである。コンテキストは、任意的に、ユーザによって提供されてよく、要求側アプリケーション(例えば、ナビゲーションアプリケーション)によってプログラム的に符号化されてよい、等。

【0638】

訓練サブシステム3803は、基礎となる予測モデルに対して、訓練、評価、および継続的な改善を提供するように構成されている。このことは、指向性、非指向性、または半指向性の機械学習技術を介して達成され得る。軌跡情報およびコンテキストデータが収集され、かつ、クロスコネクトされると、所与のユーザについて頻繁な、および、頻繁でない経路シーケンス、および、多くのユーザによって追従される共通の(例えば、共有された)経路が、予測モデルを訓練するために評価され、かつ、使用され得る。このデータは、また、事前に訓練された予測モデルを改良するためにも、訓練サブシステム3803によって使用され得る。どの予測が、時間に係るある閾値パーセントより多く真（true）を保持できないかを記録することによるものである。訓練は、一般的には、監督されなくてよい。しかしながら、指示された(例えば、監督された)、または、半ば指示された、訓練に対する修正もしくは改善も、また、使用され得る。例えば、システムは、異常であるとして人間に知られている様々な軌跡を除外することができる(例えば、ジョン・アンダーソンは、ある進行中の緊急活動がある道路の一部を単にスキップするために、異常な軌跡をたどった)。モデル訓練ノードは、LSM実施ポイントであり得る。そこでは、高リスクな軌跡が訓練モデルからフィルタリングされてよく、その結果、それらはモデル操作(例えば、オプトアウト方式)の対象とならない。

【0639】

上記の訓練の結果は、モデル3A 3811として図38に示されている、モデルである。モデル3Aは、現在観測されている軌跡に基づいて、最終目的地を予測し、その後に、予測された最終目的地および現在観測されている軌跡に基づく、最も可能性の高い前方軌跡が続く。

【0640】

テレメトリサブシステム3804は、アプリケーション待ち時間またはデータ強度といった、テレメトリメトリックを収集し、かつ、保管するように構成されている。アプリケーションは、１つの基地局から次の基地局へ移転されることを要するデータの量に対して、程度の差はあるものの、敏感であり得る。移転される必要があるデータの量が非常に少ない場合に、予測モデルを訓練すること又は最新の状態に維持することに多くの努力を払うことは、特には役に立つものではない。この敏感さは、アプリケーションごとに変動し得る。例えば、音声通話は、基地局間の状態移転に対して大いに鈍感であり得る。移転される情報の量が少なく、かつ、小さなジッタは通話の知覚される品質にあまり影響しないからである。しかしながら、高解像度のライブビデオプレゼンテーションは、特に敏感である。これらのアプリケーション待ち時間の敏感さ、および、データ強度ファクタは、各予想される軌跡において遭遇する基地局のシーケンスの予測と共に使用されるテレメトリ情報としてキャプチャされ得る。

【0641】

一つの例において、所与のアプリケーションおよびその使用コンテキストに関連して収集されたテレメトリデータは、データベース3802を取り込むために使用され、または、履歴データプールを生成するために使用され得る。一つの例において、このデータプールは、第２予測モデル(モデル3B 3812として示されている)を生成するために、訓練サブシステム3803に対してデータを提供し得る。この第２モデルは、モデル3Aによって予測される１つまたはそれ以上の次の基地局に近接する計算ノードに対して、アプリケーションのデータを、いつ事前送信することが賢明であるかを予測する。

【0642】

予測および実行サブシステム3816は、モデル(例えば、２つの訓練されたモデル3Aおよび3B)を起動するように構成されており、(例えば、モデル3Aを使用して)所与の現在の軌跡3811から前方経路における宛先、および、(例えば、モデル3Bを使用して)現在のテレメトリ3814が与えられたアプリケーションの待ち時間の敏感さを、それぞれに、予測する。これらのモデル3Aおよび3Bの出力に基づいて、予測および実行サブシステム3816は、所与のアプリケーション(例えば、サービス)が移行されるであろう将来の計算ノードに対するデータ移行を積極的に開始するように構成されている。一つの例において、軌跡が更新され続けるにつれて、モデル3Aは、以前に予測された将来の経路がもはや前に予測されたものではないことを、今では、予測することができる。一つの例において、予測および実行サブシステムは、再生利用コンポーネント3806を含む。再生利用コンポーネント3806は、前方ノードと通信するように構成されており、サービスがもはや移行されないであろうノードに対して以前に積極的に移行されたデータが削除され、または、そうでなければ、データおよびリソースが再生利用され得る。このことは、再生利用されたリソースが他のニーズのために配備されるのを可能にしている。

【0643】

ハンドオフおよびセキュアなストレージを管理するための第１の例示的方法(例J1)は、処理回路(例えば、ノード、もしくは、デバイス2200、2232、2240、または2250上で、または、それによって実装されるといったもの)を使用して実行される方法である。本方法は、要求側デバイスについてロケーション移動情報を取得するステップであり、要求側デバイスは、モバイル無線ネットワークの第１基地局を介して動作するエッジコンピューティングサービスに接続されている、ステップと、予測モデルを用いて、モバイル無線ネットワークの１つまたはそれ以上の他の基地局のうち要求側デバイスの推定ロケーション予測を生成するステップであり、１つまたはそれ以上の他の基地局はエッジコンピューティングサービスを動作させることができる、ステップと、要求側デバイスの推定ロケーション予測を使用して、エッジコンピューティングサービスのデータを、識別し、そして、第１基地局から１つまたはそれ以上の他の基地局に対して転送するステップと、を含む。

【0644】

第２の例(実施例J2)において、実施例J1の技術的事項は、エッジコンピューティングサービスのデータがサービス状態データである構成を含み、ここで、サービス状態データは、要求側デバイスの実際の移動の前に、１つまたはそれ以上の他の基地局に提供される。

【0645】

第３の例(実施例J3)において、実施例J1－J2の技術的事項は、予測モデルが、要求側デバイスの移動軌跡、要求側デバイスまたはエッジコンピューティングサービスと関連する過去の履歴、もしくは、要求側デバイスまたはモバイル無線ネットワークと関連するマップされたルートに基づいて、推定ロケーション予測を推定するように訓練される構成、を含む。

【0646】

第４の例(実施例J4)において、実施例J1－J3の技術的事項は、１つまたはそれ以上の他の基地局間での移動に係る予測シーケンスを含む推定ロケーション予測、を含む。

【0647】

第５の例(実施例J5)において、実施例J4の技術的事項は、負の確率に基づいている推定ロケーション予測を含み、負の確率は、１つまたはそれ以上の他の基地局間での予測された一式の移動が要求側デバイスによって追従されない確率である。

【0648】

第６の例(実施例J6)において、実施例J5の技術的事項は、負の確率に基づいて１つまたはそれ以上の他の基地局の間で解放されるリソース、を含む。

【0649】

第７の例(実施例J7)において、実施例J1－J6の技術的事項は、１つまたはそれ以上の他の基地局間での要求側デバイスの移動について予測される時間を示している推定ロケーション予測を含み、そして、ここで、データを識別すること及び転送することは、要求側デバイスの移動について予測される時間に基づいて発生する。

【0650】

第８の例(実施例J8)において、実施例J1－J7の技術的事項は、要求側デバイスの移動に先立って、１つまたはそれ以上の他の基地局間に配置されたアクセラレータ回路を事前にプログラムするために使用されているエッジコンピューティングサービスのデータを識別すること及び転送すること、を含む。

【0651】

第９の例(実施例J9)において、実施例J1－J8の技術的事項は、予測モデルが軌跡ベクトルに基づいて訓練された機械学習モデルである構成、を含み、軌跡ベクトルは、要求側デバイスおよびサービス基地局からの訓練データと関連付けられている。

【0652】

第１０の例(実施例J10)において、実施例J1－J9の技術的事項は、第１基地局を介して動作しているエッジコンピューティングサービスの使用から生成されるテレメトリ情報を含むロケーション移動情報、を含む。

【0653】

様々な設定において、例J1－J10(および、データまたはサービスハンドオフの他の態様)は、定義されたアプリケーションプログラミングインタフェースまたはインタフェース仕様、ハンドオフ動作を起動、受信、または制御するためのプロトコルまたは定義の使用、および、エッジコンピューティング環境の中のハンドオフ動作のための他の使用および実装、の結果として観察またはモニタリングされ得る。さらなる例において、実施例J1－J10は、データまたはサービスハンドオフのためのコンテキストデータの取得、使用、または操作を含み得る。実施例J1－J10およびこれらのハンドオフ管理技術の他の態様は、また、サービス動作およびサービス機能の結果として(例えば、FaaSまたはEaaS設定内のサービスにおいてハンドオフおよびリソース割当てを実行するように)観察または実施され得る。加えて、実施例J1－J10の方法は、エッジコンピューティングシステムにおいて、実施される命令として(例えば、命令が実行されたときに本方法を実行する機械で読取り可能な媒体を用いて)、または、実施されるハードウェア構成として(例えば、本方法を実行または達成するための構成を含む装置を用いて)提供され得る。従って、実施例J1－J10の特徴(および、ハンドオフおよびリソース割当ての他の特徴)は、システムオーケストレータまたはアーキテクトによって連携または設計されるように、エッジクラスタまたはエッジクラウドシステムを構成するために、ここにおける他の実施例のいずれかと組み合され得る。

【0654】

自動データ複製の実施例

【0655】

エッジコンピューティング環境の中には、サービスの回復力、利用可能性、および、全体的な信頼性に対する様々な要求および期待が存在している。例えば、ビデオ分析は、エッジクラウドの中で実行することが予想されるトップの作業負荷のうちの１つであり、そして、特定のビデオストリームについてデータ処理の99%レベルの回復力または信頼性を確保する、いくつかの予測される要件が計画されている。

【0656】

一般的には、サービスの複製と集中化を通じて、クラウドコンピューティングの設定における回復力と信頼性が達成され得る。例えば、サービスの複数のインスタンスは、バックアップサービス、または、所定の信頼性レベルが満足されない場合にインスタンス化されるサービスを使用して、同じクラウドデータセンタにおいて設定され得る。また、中央サービスオーケストレータによって全てが管理される、他のクラウドロケーションにおいて作成されたバックアップサービスまたはデータアグリゲータが存在している。エッジクラウドインフラストラクチャでは、しかしながら、－単一ノードからマルチラックサーバまで－異なるロケーションにおいて異なるタイプおよびサイズのデータセンタが存在するだろう。加えて、多くのエッジクラウド展開(MEC実装を含む)においては、多くのタイプのエッジノードが分散したロケーションで利用可能になるので、クラウドコンピューティングサービス管理の使用が適切ではないことがある。従って、エッジクラウドインフラストラクチャは、その独自の特性を使用して、この信頼性を確保する独自の方法を必要とする。

【0657】

分散エッジクラウド処理のシナリオにおいて、サービスのためのリソースは、エッジコンピューティング環境内で広く利用可能であり得る。しかしながら、個々のエッジノードまたはサービスコーディネータは、いつどのようにサービスを実行するか、または、どのロケーションでサービスを実行するかを知ることができない。さらに、一つのノードから別のノードへサービス移行が発生する場合には、中断およびコンテキストの損失が存在することがある。以下は、これらの問題に対処し、そして、エッジコンピューティング環境におけるサービスの信頼性と回復力の改善を可能にする。

【0658】

以下の技術を用いて、エッジコンピューティングシステム(例えば、エッジクラウド110、および、図3から図22Dに示されるエッジコンピューティングシステム構成)において適用可能な回復力は、エッジコンピューティングノードにわたりサービスデータを複製することによって獲得され得る。サービスを複製または複写するより、むしろ、サービスによって使用され、かつ／あるいは、生成されているデータは、リアルタイムに複製され、そして、必要に応じてバックアップサービスシナリオにおいて使用され得る。運用上の必要性に応じて、複製は、使用されており、または、現在関連している全てのデータ、もしくは、サービス提供またはサービスの回復性のために必要ないくつかのデータサブセットまたは一部から構成され得る。例えば、複製プロセスは、少量の複製から始まり、必要性の評価が後に続き、そして、次いで、必要であればさらに多くの複製を行う。

【0659】

この形式の複製を通じた信頼性は、２つの方法のうちの１つで達成することができる。(a)複数のエッジにわたりデータを複製すること、または、(b)処理するデータをエッジノードのパイプラインまで複製すること(例えば、ストリートキャビネット->セルタワー->セントラルオフィス)である。いずれかのアプローチを用いてデータ複製を実装するためのプロトコルは、エッジコンピューティングプラットフォームにおいて、もしくは、インテリジェントNICまたは他のプログラムされたネットワークハードウェアを使用して実装され得る。データ複製のこの使用は、高価になり得る(または、性能トレードオフの影響を受ける)同じエッジロケーションでのサービスの複製を回避し、さらに、データを複製することによって、複製されたデータおよび結果として生じるバックアップサービスは、通信および計算負荷に基づいて、フレキシブルに再割当て、または、適合され得る。さらに、このデータ複製は、それぞれのエッジロケーションが、履歴データおよびデータを永続的にする能力に基づいて、異なるレベルの信用または信頼性ファクタを有し得ることを考慮することができる。

【0660】

複数のエッジノードにわたる複製の一つの例において、中央エッジオーケストレータは、エッジロケーション(例えば、ロケーションA)においてサービスを生み出し、そして、取り扱われるデータ(ビデオフィード、といったもの)を複製するためだけに最小のリソースが使用される別のエッジロケーション(例えば、位置B)において最小のリプリケータサービスを生み出すことができる。実際のサービスは実行されていない。データは、廃棄される前に、移動時間ウィンドウについてロケーションBにおいて保管される。ロケーションBは、データを取り上げ、そして、サービスを生み出すことについてロケーションAまたはオーケストレータからメッセージを受け取ったときに、動作する。

【0661】

エッジノードのパイプラインにわたるデータの複製は、たとえ待ち時間を犠牲にしても、複製のための上流ロケーションの選択を含み得る。例えば、ストリートキャビネットは、ビデオストリームについて最も近く、待ち時間が小さいエッジホストであり得る。セルタワーは、パイプラインにおいて次のものであり、その後に、セントラルオフィスが続いている。エッジホストからのデータは、この信頼性を保証するために、パイプライン内で次のエッジロケーションにおいて複製され得る(例えば、セルタワーからセントラルオフィスへ複製される)。プライマリサーバで問題が発生した場合には、パイプライン内で使用可能な次のエッジノードが引き継ぐことができる。そうしたパイプラインベースの複製は、限られたリソースまたは制約(例えば、ソーラー電源装置による電力の制約)に係るエッジコンピューティングノードを支援し、そして、ハードウェアおよびソフトウェアの組み合せによって制御され得る。

【0662】

図39は、エッジコンピューティングサービス展開3900のコンテキストの中で、複数のエッジにわたるデータ複製がどのように実現され得るかの一つの例を示している。複数のテナントまたはエンティティ間で複数のフレーバーのサービスの実行について適用可能であるように、複数のサーバおよびノードが示されている。示されるコンテキストにおいて、図39は、(エッジゲートウェイ3910上で動作している)オーケストレータによって割当てられ、かつ、制御されるように、２つの異なるエッジロケーション(エッジロケーション1 3920、エッジロケーション2 3930)の間で行われるデータ複製を伴うサービスを示している。サービスの実行のためのロケーションが識別されると(サービス3951)、オーケストレータは、データ複製サービス(サービス3952)を生み出す。各エッジノードロケーションでの信頼性管理コンポーネント(3941、3942)が、次いで、適切なデータ複製サービスに対してデータを転送すること(データ複製3950)、および、サービスが中断または過負荷になると予測される場合に、サービス複製を起動し、または、バックアップサービスを開始するためのメッセージを送信すること、に責任を負う。

【0663】

データ複製サービス(サービス3952)は、第２エッジロケーション3930において実行され、そして、信頼性管理コンポーネント（RMU）3941によってアクティブに管理されている。データ複製サービス3952は、(同じサーバ上、または、第２エッジロケーション3930の別のサーバ上の)バックアップサービスによる使用のためにデータを複製する。バックアップサービスは、必要とされるまで何もしないが、データを受信し続ける。このようにして、必要な場合に適切な状態に対してサービスを開始することができる間でさえ、サービス動作の複製を必要とすることがない方法で、データが複製される。データ複製サービス3952は、重要なデータが複製されるように、移動ウィンドウタイムフレーム内でデータ収集するだけのサービスとして定義され得る。そして、サービスは、フェイルオーバーまたはロード問題の最中に必要に応じて再開され得る。さらなる例において、RMU 3941は、どのデータをどれだけ複製する必要があるかを動的に決定することができ、そして、一度に１つ以上のサービスに対してそうした動的な複製を実行している。

【0664】

RMU 3941は、バックアップサービスに対してデータをアクティブに送信すること、および、アラームサービスの異常や中断を予測することに責任を負う。そうした予測は、様々なファクタに基づいてよい。他のモニタリングコンポーネントからの情報、サービスパターンを追跡するために使用される機械学習アルゴリズム、外部状況モニタリングセンサ、アプリケーションとのインタフェース、収集されたテレメトリ値、等といったものである。RMUコンポーネント3941は、また、他のRMUからメッセージを受信すること、および、バックアップサービスのスピンアップ、等といった要求に応じて動作することに責任を負う。さらに、RMU 3941は、接続性の追跡に責任を負い、このことは、データを永続的にするためにエッジロケーションにおいて利用可能な全体的な信頼性または能力の一部として重要な役割を果たす。

【0665】

RMU 3941は、ToR（ラックのトップ）スイッチ(ラックサーバが配置可能なエッジロケーションの場合)またはプラットフォームNIC(シングルまたはマルチサーバエッジのインストールの場合)に係るコンポーネントとして実装され得る。RMU 3941は、また、他のハードウェアコンポーネント(サーバスレッド、回路、等)内に実装されてもよい。

【0666】

データ複製サービスをエッジコンピューティングロケーションでのサーバインスタンス上に割当てる必要はないだろう。さらなる例において、データ複製サービスは、プラットフォームNIC 3944またはラックのTORスイッチ内で直接的に実行されてよい。例えば、RMU 3941は、移動時間ウィンドウによって必要とされる限り、データを保管し、または、持続させることができ、そして、フレームのバッチのために時間ウィンドウが行われると、フレームは廃棄される。このことは、リアルタイム応答を可能にし、その結果、サービス障害が発生した場合に、現在の状態データが即座に利用可能となり、そして、この現在の状態データを用いてバックアップサービスが迅速にスピンアップされ得る。

【0667】

自動データ複製を(例えば、エッジクラウド110の間で)実装するための第１の例(実施例K1)は、処理回路(例えば、ノード、もしくは、デバイス2200、2232、2240、または2250上で、または、それによって実装されるといったもの)を使用して実行される方法である。本方法は、第１エッジコンピューティングノードのサーバインスタンスで動作しているサービスのデータをキャプチャするステップであり、データは、サービスによって消費または生成されるデータと関連している、ステップと、第１エッジコンピューティングノードからのサービスのデータを第２エッジコンピューティングノードのサーバインスタンスへ複製するステップであり、第２エッジコンピューティングノードのサーバインスタンスは、非実行状態におけるサービスのバックアップインスタンスを有している、ステップと、第１エッジコンピューティングノードにおける信頼性問題の識別に際して、第２エッジコンピューティングノード上のサービスのバックアップインスタンスに対して実行状態に入るように指示するステップであり、ここで、実行状態は、複製されたデータを利用する、ステップと、を含む。

【0668】

第２の例(実施例K2)において、実施例K1の技術的事項は、本方法の動作が、第１エッジコンピューティングノードで動作している信頼性管理コンポーネントによって実行されること、を含む。

【0669】

第３の例(実施例K3)において、実施例K2の技術的事項は、信頼性管理コンポーネントが、エッジコンピューティングゲートウェイで動作しているオーケストレータの制御下にあること、を含む。

【0670】

第４の例(実施例K4)において、実施例K3の技術的事項は、第２エッジコンピューティングノードにおける第２信頼性管理コンポーネントが、複製データを受信するように動作すること、を含む。

【0671】

第５の例(実施例K5)において、実施例K2－K4の技術的事項は、信頼性管理コンポーネントが、ネットワークインタフェースカードまたは第１エッジコンピューティングノードとの通信を提供するスイッチに係る回路によって動作されること、を含む。

【0672】

第６の例(実施例K6)において、実施例K2－K5の技術的事項は、第２エッジコンピューティングノードにおけるサービスの制御のための動作が、第２エッジコンピューティングノードで動作している第２信頼性管理コンポーネントによって実行されること、および、第２信頼性管理コンポーネントは、サービスのバックアップインスタンスに対してデータを提供し、かつ、サービスのバックアップインスタンスの実行状態を制御するために使用されること、を含む。

【0673】

第７の例(実施例K7)において、実施例K1－K6の技術的事項は、複製データが時間ウィンドウに基づいて維持されること、を含む。

【0674】

第８の例(実施例K8)において、実施例K1－K7の技術的事項は、第１エッジコンピューティングノードおよび第２エッジコンピューティングノードが、分散エッジコンピューティングシステムのレイヤにおけるネットワークピアであること、を含む。

【0675】

第９の例(実施例K9)において、実施例K1－K8の技術的事項は、第１エッジコンピューティングノードおよび第２エッジコンピューティングノードが、分散エッジコンピューティングシステムの中でコンピューティングパイプラインの異なるレイヤに置かれていること、を含む。

【0676】

第１０の例(実施例K10)において、実施例K1－K9の技術的事項は、信頼性管理コンポーネントが、どのデータを動的に複製するかを動的に決定すること、および、複数のサービス間で複製を動的に実行すること、を含む。

【0677】

様々な設定において、実施例K1－K10(および、自動データ複製の他の態様)は、
定義されたアプリケーションプログラミングインタフェースまたはインタフェース仕様、データ複製動作を起動、受信、または制御するための通信プロトコル、メッセージ、または定義の使用、ノード切断状態、並びに、エッジコンピューティング環境の中のデータ複製のためのポリシおよびロジックの他の使用および実装、の結果として観察またはモニタリングされ得る。実施例K1－K10、および、これらのデータ複製の他の態様も、また、サービス動作およびサービス機能の結果として(例えば、FaaSまたはEaaS設定内の複数のサービス間でデータを複製するために)観察または実施され得る。加えて、実施例K1－K10の方法は、エッジコンピューティングシステムにおいて、実施される命令として(例えば、命令が実行されたときに本方法を実行する機械で読取り可能な媒体を用いて)、または、実施されるハードウェア構成として(例えば、本方法を実行または達成するための構成を含む装置を用いて)提供され得る。

【0678】

カスタマ構内設備ベースの実行フォワーディングの実施例

【0679】

さらなる例において、カスタマ構内設備は、分散された(しかし、協調された)テレメトリアーキテクチャを可能にし得る。ここで、エッジプラットフォームは、証明され、信頼される方法でエッジサービスのためのテレメトリを公開し、かつ、利用する。エッジコンピューティングシステム(例えば、エッジクラウド110、および図3から図22Dまでに示されるエッジコンピューティングシステム構成)のエッジテナントは、アーキテクチャにわたり分散されたそれらのサービスについて、アクセスし、発見し、または、モニタリングを追加することができる。テナントは、テレメトリが、いつどのように生成されるかを検証することができる。以下で説明されるテレメトリは、エッジアウェア（edge-aware）であり、かつ、連携されている。

【0680】

電気通信サービスプロバイダ（TSP）という用語は、例えば、ケーブルサービスプロバイダ、電話／携帯サービスプロバイダ、インターネットサービスプロバイダ、MEC、等の、接続性およびコンテンツを提供することができる全てのベンダ、および、電線やルータを実際に所有することなくサービスを配信することができる、Netflixのような、スパンニングコンテンツ配信ネットワーク(CDN)プロバイダ、の全てを包括したものとして使用されている。これらのプロバイダは、定義された量の計算サービスやソフトウェアサービスをカスタマに提供することができる、Google、Amazon、等のクラウドサービスプロバイダ（CSP）とは異なっている。CSPサービスは、カスタマによって支払いがなされ、または、広告によってサポートされ得る。今日、多くのTSPは、情報ストリーマとしてのコア能力を構築するために、エッジにおいて付加価値あるサービスを提供することを望んでいる。しかしながら、従来のTSPインフラストラクチャは、CSPのコアコンピタンスである計算リソースの弾力性とスケールを欠いている。従って、TSPは、十分な計算負荷を維持することができず、そして、カスタマとCSPとの間のパイプとして主に機能する。

【0681】

典型的には、TSPとCSPベースの計算インフラストラクチャとの間のパイプはスケーラブルではない。パイプは、コストの高いバックホール帯域幅によって制限されており、そして、エンドツーエンドの通信インフラストラクチャをオーバーホールすることは高価である。なぜなら、それは、物理的、法的、または他の障壁のために接続性が制限されている、もしくは、通信リンクが各参加者に対して利用可能な帯域幅割当てが制限されている共有リソースである、多くの地理的領域を縦横に行き来し得るからである。TSPは、CSPから計算リソースを提供することによって、提供したい計算集約的サービスを、容易に、あるいは安価に見つけることはできない。このことは、TSPに対する問題を提起する。計算集約的サービスが、彼らが提供する準備ができているデータ集約的サービスから不可分であり得るからである。

【0682】

さらに、エッジとクラウドの間の通信が重大な問題ではない場合でさえも、TSPは、経済的、ビジネス的、また、カスタマ管理上の理由から、CSPと提携したがらないだろう。なぜなら、二次サービスプロバイダ(例えば、単なるビットムーバ)の役割であることに追いやられるのを望まないからである。これは、部分的に、TSPが、エッジベースのインフラストラクチャだけでなく、アプリケーション／コンシューマデータおよびコンテキストのロケーション近傍を構築することによってサービスを配信することが、帯域幅および待ち時間で効率的なことを理解しているからである。TSPは、ユーザに近いことが特に成長著しい経済セクターにおいて意味する価値によって動機づけられ、または、コンシューマ基盤のより大きいシェアを所有することを欲し得る。

【0683】

CSP同等の役割を達成するために、TSPは、オンデマンドで弾力的に計算するCSPのような能力を構築するか、または、他の誰か(例えばCSP)に保険料率（premium rate）を支払う必要があり得る。CSPとTSPの両方は、デマンドに応じて価格および料金を適合させることができ、そして、販売または入札のポリシをより活用することができる。CSPは、サービスをTSPのカスタマベースに対してより近くに移動するために、コロケーション設備を利用することができ、そして、従って、TSPの役割をさらに重要視しない。ここにおいて説明されるシステムおよび技術により、TSPは、その通信能力をCSPのマッチ計算能力と組み合せることができる。

【0684】

コロケーション(CoLo)サービスは、セルタワーのベースおよび他の近傍のロケーションにデータセンタを配置することによって、クラウドベースのサービスに対する低遅延アクセスを提供することができる。クラウドプロバイダは、また、CDNサービスおよびカスタマ構内設備(CPE)サービスを通じて、独自のプレゼンスを構築することもできる。逆に、CDNコンテンツは、エッジ近くに設置されているベンダ所有の特別目的のデータセンタによって配信され得る。しかし、制御および管理プレーンはパブリッククラウドに実装されている。

【0685】

TSPは、エッジコンピューティングインフラストラクチャプロバイダと契約し、クラウドサービスプロバイダで提供するインフラストラクチャにコンピューティングをプッシュし、または、エッジに／その近くに独自の計算リッチなデータセンタを構築するか、いずれかであり、ネットワーク機能仮想化(NFV)、ソフトウェア定義ネットワーキング(SDN)、およびCDNサービスにおける通信コアの強みに隣接する付加価値サービスと並んで、データセンタの経済性およびクラウドの機動性を達成する。そうした計算の金銭的またはリソース的コストは、実際の現在のコスト(または、上記の入札手続き)に依存するように、それぞれのユーザのプロファイルにマッピングされ得る。

【0686】

従来のアプローチでは、TSP自身の分離したコンピューティングインフラストラクチャを構築する必要なく、既にエッジに近接しているというTSP独自の技術的利点を活かして、ファーストクラスのパートナーとして参加する能力をTSPに提供しない。この結果として、TSPは、付加価値データサービスではなく、むしろ配管工事（plumbing）を提供している。小規模なTSPは、リッチな計算能力を構築して、維持するために増大する投資リスクをとるか、または、CoLoインフラストラクチャプロバイダに支払うためにその収益の一部を放棄する必要がある。

【0687】

TSPは、仮想マシンからの計算インフラストラクチャ、もしくは、基地局またはCPEインフラストラクチャからの調整を用いた家庭および小企業カスタマにホストされたセキュアなコンテナを構成する。TSPは、CoLoサービスプロバイダのTSP所有コンピュータに投資する代わりに、無線ルータまたはその直接的な制御下にある他の通信仲介者を使用して、プライベートネットワークをオーバーレイし、TSPが必要とする動的および弾力的な計算プレーンを結合して計算をスケジューリングすることができる。システムおよび技術は、信頼性が高く保護された共同テナント性を獲得する手段をTSPに提供し、そして、物理的制御ではなく計算能力の突然の損失の可能性を低減するために、リモートデータ伝送(RDT)規定、および、ベースボード管理エンジンといった組み込まれた制御のポイントを含む、ハードウェア内のセキュアなパーティションを提供する。

【0688】

このアプローチは、多数のデータ近接性および帯域幅集約的な機会と歩調を合わせるためだけに、継続的に拡大している計算サイクルに投資するようにTSPに要求することなく、非常にスケーラブルで、かつ弾力的な協調的エコシステムを創出するという利点がある。主導権のある第１ティアのクラウドサービスプロバイダによって支配されていない多極市場が創出される。そうでなければ、TSPおよびサードパーティのサービスプロバイダを、容易に周辺の役割に限定し得るものである。本エッジは、家庭、小規模企業、および、車載車両のようなモバイル機器における計算装置の増大する拡散にピギーバックする、高度に拡張可能で計算弾力的なインフラストラクチャに基づいて形成されている。所有者は、TSP、および、TSPの代理店によりプロバイダに対してブリッジされ得るサービスによって使用され得る、プールに対して様々な量の計算を誓約し得る。

【0689】

CSPは、ここにおいて使用されるように、サービスとしてのインフラストラクチャ(IaaS)、サービスとしてのプラットフォームを(PaaS)、サービスとしてのソフトウェア(SaaS)、サービスとしての機能(FaaS)、を提供するベンダ、および、カスタマまたは広告が様々なサービスとしての全て(X-aaS)のオファリングのために支払うか否かについてカスタマに対する同様なオファリング、として定義される。ある場合に、TSPおよびCSPは、CSPがいくつかのマーケットにおいて独自の通信サービスを創出するときに同じ企業であり得るが、計算インフラストラクチャに基づくTSPとCSPとの間のパイプが、カスタマとTSPとの間の最後の1マイルにおける低い待ち時間と高い帯域幅のアセットのせいで、エッジにおいて必要とされる計算需要の増加と共にスケーラブルでない場合には、ここにおいて説明されるシステムおよび技術は妨げられない。

【0690】

TSPは、カスタマとの信頼関係を有し得る。これらの関係またはサービスは、しばしば、加入者識別モジュール（SIM）、カスタマの家庭／業務ネットワーク、等の中へセキュアに統合されたルータ、といったハードウェアエレメントによってアンカーされる。この信頼関係の結果として、TSPは、それらのデバイスにおいて、および、カスタマのデバイスの中へ、セキュアで、信頼できるソフトウェアモジュールをインストールすることができる。

【0691】

TSPは、アンカーポイントデバイス内に信頼できるソフトウェアモジュールをインストールすることができ、そして、カスタマのオプトイン（opt-in）同意を用いて、カスタマに属しているデバイス内に追加のモジュールをインストールすることもできる。従って、例えば、ジャックとアリスの家の中へ有線／無線サービスを導入するインターネットサービスプロバイダ(ISP)(TSP)は、また、ジャックとアリスのオプトイン合意を得て、ジャックの自宅のコンピュータおよびアリスのスマートフォンにおいて「ISPパーティション」ソフトウェアコンポーネントを得ることもできる。そうしたソフトウェアコンポーネントは、プライバシーとセキュリティを保護し、かつ、良好に振る舞うものとして、政府またはコンシューマ利益団体といった適切な第三者によって精査され、かつ、証明される。これらのコンポーネントは、カスタマの構内設備において設置され、そして、上述した信頼のハードウェアルートに完全に統合されたTSPの「軽量」オーケストレータと共に動作する。そうした軽量オーケストレータは、TSPによるカスタマ構内設備での計算能力の部分的、計量的、および、隔離された使用を提供する。それらは、また、TSPが、動的に変化する計算能力を、TSPのカスタマベースにわたり集約またはプールすることも可能にする。

【0692】

従って、例えば、ボブとジョアンナは、ISPによる彼らのデバイスの部分的、計量的、および、隔離された使用についてオプトインを有する２人の他のカスタマであり、ISPによって彼らのデバイスを同様に利用可能にすることにおいて、ジャックとアリスと一緒になる。TSP(例えば、ISP)は、今や、ジャック、アリス、ボブ、ジョアンナ、などからの計算サイクルのプールから引き出す能力を有している。TSPは、非常に多数のカスタマを有しており、かつ、カスタマは、典型的に、コンピュータデバイスの数を増やし続けるので(例えば、IoT/Smartデバイスのより大きな普及による、等)、TSPに対して利用可能な動的計算サイクルの集約は、TSPによる大規模なリソース経費なしに構築されるカスタマ側クラウドを形成する。TSPは、また、競合他社のCSPと高額な契約を交渉する必要もない。

【0693】

ISPといった、１つのTSPは、そうした集約とフレキシビリティのために、より広範な動的プールを得るために、別のTSPと一緒になることができる。TSPは、新たなサービスを提供すること、サービスに対しカスタマによって支払われる価格を割り引くこと、他の機能をスライディングスケールで提供すること、等によって、この参加または計算容量の共同プーリングを奨励している。TSP管理ルータといった、TSP制御デバイスは、継続的にTSPに対して利用可能であることに留意する。制御(例えば、ハブ)は、主に、ルーティングおよびプロトコル処理のために使用され得る。この制限された計算能力は、それにもかかわらず、ほとんど常にオンであり、そして、TSPが、ハブを介してネットワーク化されたカスタマの計算リソースから、TSPのドメインに入り込むことができる部分的計算能力を調整するために十分である。

【0694】

カスタマが、デバイスを所有し、そして、いつでもオフラインにすることができる一方で、サービス品質(QoS)定義または全体的なSLAが、カスタマとTSPとの間で交渉され、そして、ソフトウェアコンポーネントによって強制され得る。これにより、TSPは、これらのデバイスの利用可能性について、最小限の時間粒度で(例えば、デバイスは、１秒、２秒、等の最小のシャットダウン期間なしでは、オフラインにならない)、変動するが非常に高い予測が可能になる。QoS合意は、全てのデバイスにおいて満たされなくてもよい。例えば、モバイルデバイスは、様々な時点で到達不能になることがある。しかしながら、TSPは、様々なカスタマの構内で、利用可能であり、かつ、最小時間で到達可能でありそうなデバイスについて、統計的な尺度(例えば、確率分布など)を有している。

【0695】

図40において、部分Aは、CPEベースの実行フォワーディングのための一つの例示的なブロードバンドベースのシステム4000に係るブロック図を示している。部分Aは、典型的なモデムベースのブロードバンドサービスを示し、そこでは、論理演算パーティション4010が、ローカル負荷QoSポリシ構成と協調して、ホームおよび小規模企業(デバイス1-4、4011、4012、4013、4014から)で作成されている。

【0696】

図40で、部分Bは、さらに、CPEベースの実行フォワーディングのための一つの例示的な無線ベースのシステム4050に係るブロック図を示している。部分Bは、電気通信プロバイダの基地局／セルタワー、または、制限されたエッジステーションと接触している、モバイル／無線接続のホスト4061、4062、4063における計算能力のための同様なパーティション4060の作成を示している。

【0697】

図41は、CPEベースの実行フォワーディングのための、予測可能な使用および計算能力の割当てを達成することについて、ポリシ駆動アプローチのための一つの例示的な技術に係るフロー図4100を示している(メモリおよびCPU使用の非限定的な例のリストを含む)。図41は、計算能力を、TSPへ、または、そうした計算能力を必要とし、かつ、TSPによって仲介される第三者へ配分する予測可能な手段を達成するためのテーブル／ポリシ駆動のアプローチを示す。この図は、例えば、カスタマデバイス(TSPに対するデバイス、および、TSPに与えられるメモリパーティションの対応するレベル)における4つの異なる量の計算容量4111、4112、4113、4114のフレキシブルなポリシまたはスケジュール駆動の割当て4110を示している。しかしながら、他の量(または同じ量の使用方法)も、また、存在し得る。

【0698】

図42は、アクセラレーション制御プレーン4212をサポートするために、CPEベースの実行フォワーディング転送のためのテレメトリおよび計算容量を取得するための一つの例示的な技術に係るフロー図4200を示している。図42は、様々な規則またはサポート機能4210に基づいて、TSPによって取得される、細粒度のテレメトリおよび計算容量のための(例えば、ハードウェア、ソフトウェア、等における)サポートを示す。

【0699】

TSPがデバイスのカスタマコレクション内に有する制御ポイントを使用して、かつ、図41および図42に示されるカスタマと交渉されたテレメトリおよび時刻ポリシを使用して、TSPは、図40の部分AおよびBに示されるように、様々な計算スライスを割当てる。

【0700】

TSPは、カスタマデバイス内で起動されるプロキシコンポーネントの中で追加的な制御を実装することができ、それによって、カスタマまたはカスタマデバイスにおけるシステムソフトウェアは、交渉された契約の一時的な中断を主張することができる。例えば、カスタマは、様々な時刻に全ての利用可能な電力または全ての利用可能な帯域幅を必要とし得る。その場合、カスタマは、一時的に、TSP、インフラストラクチャのスライスを拒否することができる。このことは、カスタマおよびTSPに対して透明に利用可能なテレメトリおよびロギングによって、カスタマおよびTSPが、交渉し、かつ、実施／奨励した業務上の取り決めにおいて理解される。

【0701】

ハードウェアは、TSPのプロキシコンポーネントに対して、カスタマデバイス上でセキュアな制御ポイントを提供することができる。そうした制御は、CPE上でリソースプロビジョンを作成するように飛び地（enclaves）および他のプロビジョンをサポートするために、ハードウェアの様々なレベルの中へ統合された特定な能力の形式であり得る。このことは、フレキシブルな集約のためのカスタマデバイス能力の、カスタマから隔離されたオーバーレイコンピューティングネットワークへの論理的な分割を可能にする。これらのセキュアな制御ポイントは、また、CPEのストレージまたはメモリへの任意のアクセスをハードな隔離（hard-isolating）を含む、TSPに対して誓約されていないカスタマのデバイス容量の残り部分への潜在的な侵入からカスタマを保護する。従って、セキュアなマルチテナント性が、ハードウェアベースのインテグリティおよび分離機能によってサポートされるハイパーバイザ／OSベースの機能の組み合せによって提供される。原則として、このことは、CSPインフラストラクチャのマルチテナント共有のためにデータセンタ内でCSPが実装する隔離と類似している。

【0702】

いくつかの例において、TSPは、FaaSのために必要とされるといった、コンピューティング作業負荷の短いバーストを主に実行するために、より信頼性が低い利用可能なカスタマ(例えば、ホーム、モバイルカスタマ、等)から得られたこの計算容量を利用することができ、一方で、ピアツーピアの計算オフロードのために利用できる２４×７の利用可能なハードウェア(例えば、常時オン、ホーム／ビジネスベースのアプリケーションサーバ、ファイルサーバ、ウェブサーバ、等であるとして、中小企業によってそのように指定されたコンピュータ)から得られた容量をスケジューリングしている。

【0703】

一つの例において、カスタマは、外部デバイスの小さな電力消費は別として、ユーザにほとんど影響を与えずに、エッジにおいて常に利用可能なマルチカスタマクラウドを作成するために、TSPによって所有されるルータに外部デバイス(例えば、コンピューティングスティック、等)を接続することに同意し得る。これにより、TSPは、実際にCoLoプロバイダと提携することなく、独自のCoLoサービスを作成することができる。CoLoの機能は、カスタマベースで成長するので、大幅に著しくよりスケーラブルであり、そして、TSPが任意のポイントで決定できるようにアップグレード可能である。例えば、TSPは、時間の経過とともに不均一な需要の伸びをTSPが見るネットワークの一部において、計算スティックの中の次世代コンピュータまで選択的に前進し得る。そうした場合に、TSPは、無視できるほどの追加価格で、カスタマのためのローカルCSPとしてさえ機能し得る。

【0704】

TSPは、最悪の場合にバックネットによってバックアップされる、そうしたカスタマベースの計算コンテナにおいて、新たなコンピューティングタスクの欲張りなスケジューリングを実装することができる。その最悪の場合のバックネットは、カスタマの計算デバイスがオフラインになるときに中断される、それらのタスクが送信され得る様々な基地局において、制限された量の計算能力として生成され得る。代替的に、それらのタスクは、バックエンドのクラウドに対して送信され、そこで、TSPは、そうした最悪の場合のオフローディングのためにいくらかの容量を提供し得る。

【0705】

実行フォワーディングのこれらの態様のいずれかは、より効率的なアドホック分散コンピューティングおよび「テザリング」の形態を可能にするために、MEC環境に適用され得る。結果として、所与のTSPに対して登録されたデバイスは、オンデマンドで処理能力を提供することができるようになり、従って、手形割引（bill discount）を見込んだMECサービスのカバレージさえも拡大している。結果として、「MECシステム」の概念は、そうした実行フォワーディングを利用して、著しく拡張され得る。

【0706】

エッジコンピューティングシステム(例えば、エッジクラウド110、および、システムとデバイスとを実装しているもの)において実行フォワーディングを実装するための第１の例示的な方法(実施例L1)は、処理回路(例えば、ノード、もしくは、デバイス2200、2232、2240、または2250上で、または、それによって実装されるもの)を使用して実行される方法である。本方法は、エッジネットワークのサービスプロバイダに対して通信可能に結合されたデバイスから計算リソースのための要求に対する承認応答を受信するステップと、一旦承認を受信すると、デバイス上にセキュアなソフトウェア実行コンポーネントを作成するステップと、サービスプロバイダによって実行されるべき作業負荷を識別するステップと、セキュアなソフトウェア実行コンポーネントにおける実行のために作業負荷を送信するステップと、実行の結果をサービスプロバイダのノードに対して送信するステップと、を含む。

【0707】

第２の例(実施例L2)において、実施例L1の技術的事項は、ソフトウェア実行コンポーネントのプールに対してセキュアなソフトウェア実行コンポーネントを追加するステップと、作業負荷を作業ユニットへと分割するステップと、ソフトウェア実行コンポーネントのプールの各ソフトウェア実行コンポーネントに対して作業ユニットを送信するステップと、を含む。ここで、セキュアなソフトウェア実行コンポーネントにおける実行のために作業負荷を送信するステップは、作業ユニットのうち第１の作業ユニットをセキュアなソフトウェア実行コンポーネントに対して送信するステップ、を含む。

【0708】

第３の例(実施例L3)において、実施例L1－L2の技術的事項は、セキュアなソフトウェア実行コンポーネントを使用して作業負荷の実行について価値を計算するステップと、その価値を用いてデバイスと対応しているユーザアカウントをクレジットするステップと、を含む。

【0709】

第４の例(実施例L4)において、実施例L1－L3の技術的事項は、サービスプロバイダによって提供され、かつ、計算リソースに対する要求で提示されるサービスを識別すること、および、一旦作業負荷を実行するとデバイス上でサービスを有効にすること、を含む。

【0710】

第５の例(実施例L5)において、実施例L1－L4の技術的事項は、作業負荷を実行するためにセキュアなソフトウェア実行コンポーネントが利用可能である時間ウィンドウを識別するステップと、時間ウィンドウの最中にセキュアなソフトウェア実行コンポーネントに対して作業負荷を送信するステップと、を含む。

【0711】

第６の例(実施例L6)において、実施例L1－L5の技術的事項は、エッジネットワークに対して接続されているセルラ基地局を介して、サービスプロバイダに対してデバイスが通信可能に結合されていること、を含む。

【0712】

第７の例(実施例L7)において、実施例L1－L6の技術的事項は、デバイスが、エッジネットワークに接続されたネットワークルータを介してサービスプロバイダに通信可能に接続されていること、を含む。

【0713】

様々な設定において、実施例L1－L7(および、実行フォワーディングの他の態様)は、定義されたアプリケーションプログラミングインタフェースまたはインタフェース仕様、フォワーディング動作を起動、受信、または制御するための通信プロトコル、メッセージ、または定義の使用、並びに、エッジコンピューティング環境(FaaSまたはEaaSアーキテクチャ内のサービスを含む)の中の実行フォワーディングのためのポリシおよびロジックの他の使用および実装、の結果として観察またはモニタリングされ得る。加えて、実施例L1－L7の方法は、エッジコンピューティングシステムにおいて、実施される命令として(例えば、命令が実行されたときに本方法を実行する機械で読取り可能な媒体を用いて)、または、実施されるハードウェア構成として(例えば、本方法を実行または達成するための構成を含む装置を用いて)提供され得る。従って、実施例L1－L7の特徴(および、実行フォワーディングおよび実行管理の他の特徴)は、ここにおける他の実施例のいずれかと組み合されてよく、システムオーケストレータまたはアーキテクトによって連携または設計さるように、エッジクラスタまたはエッジクラウドシステムを構成することができる。

【0714】

ＩＶ．マルチステークホルダのエッジコンピューティングシステムのためのセキュリティおよびプライバシーの改善
さらなる例においては、セキュリティおよびプライバシー手続きの先進的な方法が、多種多様なマルチステークホルダのエッジコンピューティング設定へ拡張され得る。

【0715】

マルチテナントエッジ設定におけるセキュリティポリシおよび適応

【0716】

コンピュータシステム・マルチテナントのコンテキストにおいて、隔離は、１つのテナントのデータを別のテナントから完全に分離するために、セキュリティおよびプライバシーアプローチとして選択され得る。しかしながら、分散およびリソース制約エッジコンピューティング環境において、厳密な隔離は、実行できないであろう。以下のセキュリティおよびプライバシーアプローチは、より動的なアプローチおよび構成を考慮し、エッジコンピューティングシステム(例えば、エッジクラウド110、および、図3から図22Dまでに示されるエッジコンピューティングシステム構成)において、アクセス制御、セキュリティポリシ、および、セキュリティ管理の新たな形態を実装する。

【0717】

特に、ここにおいて説明されるエッジコンピューティング環境は、クラスタ、グループ、または他の構成へのノードの配置、配置転換、または追加の最中に、テナントのセキュリティグループ化またはセキュリティグループ化における変化を推進し得るセキュリティ態様および作業負荷の類似性を考慮することができる。これらの変化は、同じノードの中で動的に発生し、そして、より少ないセキュリティの作業負荷として同じノード上で動作する信頼できる作業負荷とインターリーブされ得る。スループットを増加させるために、並列セキュリティクラスタおよびグループが作成されている。

【0718】

一つの例として、サイドチャネル・リスクを最小化し、かつ、テナント間の利益相反を解決するための以下のアプローチは、セキュリティポリシがサイドチャネル分析についてポテンシャルによるリスクを管理するための基準を確立する技術を提供する。劇的に対立するテナントは（例えば、相互にスパイするように動機付けされ、または、リスクがある）、より多く、そして、より強い隔離技術を用いて相互に分離されているが、一方で、少々対立するか、または、フレンドリーであることが知られている他のテナントは、相互の情報を知る必要はないが、適度な隔離を要求する。これらの異なるレベルの予防策、および、そうした予防策から確立されたグループは、動的で、適応的なセキュリティポリシによって推進され得る。

【0719】

さらなる例として、セキュリティオペレーション、および、エッジコンピューティングシステムリソースがどのように使用され、かつ、配備されるか、を制御するために、様々な形式のセキュリティポリシがエッジコンピューティング設定の中で動的に作成され、そして、実装され得る。利益相反に基づいてセキュリティを評価することは、１つのタイプのセキュリティポリシを生成し得る。複数レベルのセキュリティ分類(例えば、最高機密、機密、機密でない)に基づいてセキュリティを評価することは、別のタイプのセキュリティポリシを生成し得る。これらの評価は、インテグリティ対機密性、タイプ実施、等についても考慮する動的なセキュリティポリシを生成するように、エッジコンピューティング設定において拡張され得る。

【0720】

マルチテナントの隔離は、全てのセキュリティポリシの中で最も強力な(そして、最も厳格な)１つを提供し得るが、協同の可能性を予期していない。他のデータワーカーの存在は隠されている。マルチユーザオペレーティングシステムは、しばしば、このような方法で動作する。－ユーザは、独占的な使用のために利用可能なプロセッサまたは計算リソースを有していると理解し得るが、実際には、それらは共有されている－時間スライスされており－複数のユーザにわたる。マルチレベルセキュリティポリシは、共有が容認できる場合の基準を定義することによって、この非フレキシブル性を排除する(一方で、厳格なマルチテナントポリシは、共有を全く想定していない)。

【0721】

一つの例において、ロード可能なセキュリティモジュールまたは他のセキュリティコンポーネントは、エッジコンピューティングシステムにおいて様々な形態で提供され得る。そうしたロード可能なセキュリティモジュールは、動的セキュリティポリシ、および他のセキュリティ、そしてプライバシー機能の管理、プロビジョニング、配分、および適用を可能にする。例えば、ここにおいて説明されるエッジコンピューティング環境における動的セキュリティポリシの使用は、特に、リソースのより細かい「スライス」が、テナント、アプリケーション、またはサービスごとに一緒に保持され、そして、連携されるので、単純なマルチテナントよりも広い範囲の共有および協同のユースケースを可能にする。一旦、これらのグループまたはリソースのクラスタが特定されると、より大きな共有および協同をサポートする他のセキュリティポリシおよびユースケースが展開され得る。さらに、セキュアで、かつ、信頼できる環境においては、リソースのこれらの細かなスライスでさえも、制御された方法でスライス間のインタラクションを可能にするように管理され得る。セキュリティ分離、アクセス制御、およびプライバシー管理の他の形態は、ロード可能なセキュリティモジュール
を通じて可能にすることができ、そして、グループ化のフレーバー、スライス、許可、および他の形態を結果として生じている。

【0722】

以下の例において、セキュリティポリシおよび考慮事項は、何らかの方法でリソースを共有し、または、インタラクションすることが許可された、クラスタ(グループ)テナント、もしくは、エンティティをキャプチャする、「ドメイン」や類似のセキュリティコンテキストの定義および使用を含み得る。これらのドメインは、ノードまたはノードリソースの配置、再配置、または追加と、動的に適合され得る。これらのドメインは、作業負荷が、同一または関連するノード上で相互運用できるようにし、そして、よりセキュアでない作業負荷として同じノード上で動作する両方の信頼された作業負荷とインターリーブされるリソースの使用を可能にする。同様に、これらのドメインは、(作業負荷が複数のロケーションに配分できるように)並列グループの作成を可能にし、スループットを増加させる。

【0723】

アクセス制限を伴うマルチドメイントラストの確立の実施例

【0724】

エッジコンピューティングは、複数のオペレータ、サプライヤ、サービスプロバイダ、テナント、および、ホスティング環境を含み、これらはエッジ・エコシステム・ステークホルダとして参照され得る。各ステークホルダは、エッジ・エコシステムに参加することについて、利己主義な動機を有している。ときどき、利己主義は、複数のステークホルダにわたり、相乗的かつ共通である。またある時に、利己主義は、競争関係、敵対関係、または、利益相反関係を明らかにし得る。

【0725】

マルチテナント・アクセスポリシは、典型的には、隔離された(例えば、オーバーラップしない)テナント固有のリソースを見つけることに注目している。そうした実践は、しばしば、テナントがエッジリソースについて独占的なアクセスを有しているという幻想を与える。このことは、しかしながら、間違いであり、テナント間でリソース競合を結果として生じ、エッジノードにおける乏しいリソース利用率を招いている。さらに、作業負荷は、複数のベンダエレメントから構成され得る。－制御プレーン、データプレーン、および、課金またはモニタリングサービスのために異なるベンダ仮想ネットワーク機能（VNF）を連携する仮想エボルブド・パケットコア（vEPC）アプリケーション、といったものである。ますます一般的なエッジノードになりつつある、そうしたシナリオにおいて、異なるベンダVNFは、共通の利己主義を有することができ、テナントのリソース排他性ポリシによって妨害されているリソース共有を可能にしている。つまり、リソース排他性、または、リソース排他性という幻想は、豊富な協同的インタラクションを可能にするものではない。

【0726】

エッジコンピューティングシステム(例えば、エッジクラウド110、および、図3から図22Dまでに示されるエッジコンピューティングシステム構成)において豊富な協同を可能にするために、ドメイン(例えば、エッジノードのクラスタ)が、利己主義なアクセスポリシがドメインの観点および関心に関連して定義される場合に、確立され得る。ここで、ピアまたは競合するドメインは、異なるアクセスポリシを表すことができる。これらのドメインは、各ドメインの視点に従ってアクセス権を評価し、協同的なインタラクションのために利用可能なリソースのオーバーラップしているセットを見つける。一つの例において、エッジノードリソースは、リソースについて責任を負うドメイン(例えば、リソースの所有者)に関して表される証明可能なアイデンティティを有している。一つの例において、リソースは、他のドメイン固有のリソースおよびリソースの定義されたアクセスポリシに関して表されるアクセス権を有している。ここで、ペア毎のドメインポリシの交差は、許容可能なアクセスの範囲を特定する。

【0727】

これらのドメインを介して、個々のドメインまたは第三者は、集中化された信頼できる第三者に依存することなく、許容可能なアクセスの範囲を正確に、かつ、独立して計算することができる。従って、ステークホルダは、エッジコミュニティのサブセットに対して信頼または調整を実施することができる。例えば、国-Aにおけるキャリアは、加入者ベースを有し得るが、一方で、国-Bにおけるキャリアは、異なる加入者ベースを有し得る。これらの加入者ベースは、ドメインである。エッジクラウドエコシステムにおいては、任意のステークホルダは自分が管理する加入者ベースを有し得る。それゆえ、任意のステークホルダはドメインであり得る。ドメインAからのテナントAが、ドメインBからのテナントBとインタラクションすることを望む場合に、ドメインおよびリソースアクセスポリシは、おそらく、アドホック、ドメイン－ドメインのフェデレーション信頼、または、テナントAおよびテナントBがインタラクションを許可されるパラメータに基づいて、インタラクションのルールを定義する。フェデレーテッド・トラストパラメータは、リソースに対する追加的なアクセス制限を使用する。加えて、アクセスの粒度は、ドメイン内（intra-domain）のアクセスよりも制約され得る。例えば、アクセスは、アクセスされ得る所定のファイル、ワークフロー、または他のリソースを識別することができ、もしくは、アクセスが許可されているタイムフレームについてより厳しい制限を課すことができる。

【0728】

図43は、エッジエコシステム・ドメイン・アーキテクチャ4300に係る一つの例を示している。図43は、ドメインにおいて配置された各「クラスタ」内に５つのドメインを含む、例示的なエッジ展開を示している。ドメインは、ドメインAからドメインE 4311、4312、4313、4314、4315である。ここで、クラスタは、認識されたドメイン所有者、および、１つまたはそれ以上のエッジサービスを有する。一つの例において、１つまたはそれ以上のクラスタは、テナントまたは加入者の関係性を管理し、サービスレベルアグリーメント(SLA)、または、提供されるサービスのレベルを記述するその他のパフォーマンス契約を実施する。そうした管理クラスタは、SLAの目的を実施するために必要に応じて、SLO、または、クラスタ間における同様な合意を使用して、二次的(例えば、従属的)関係性を介して、SLAを実装する責任を負い得る。

【0729】

図示されるように、長円は、所有者エンティティ(ベンダ4320、といったもの)を識別し、一方で、長方形は、ドメインE 4315において提供されるサービス(コアサーバ4322、といったもの)を示している。ドメインAからドメインE 4311、4312、4313、4314、4315それぞれは、他のドメインAからドメインE 4311、4312、4313、4314、4315のいずれかと同じ、類似した、または、異なる所有者エンティティもしくはサービスを有してよく、他の所有者エンティティもしくはサービスと同様な役割または機能を実行することができる。テナントは、所有者の特別なクラスであり、別個のクラスタ指定を要求しないことがある。このことは、ホストしているクラスタに対するアクセスをテナントが与えられた場合に、SLAが合意された行為を表すので、発生し得る。例えば、図示されるように、テナントT1 4326はドメインA 4311のメンバーであることが許可されており(例えば、オペレータO1 4324によって検査された後で)、そして、テナントT2 4328はドメインB 4312のメンバーであることが許可されている(例えば、オペレータO2 4330によって検査された後で)。共通のクラスタにおけるテナントとオペレータとの間の関係性は、「共有ドメイン」コンテキストとして記述され得る。さらに、これらの所有権または関係性のいくつかは、何らかの関連する時間有効性(別名、満了データ)を有し得る。このことは、いくつかのプロパティが永続的でなく、そして、いくつかのエレメントが接続性によって更新されないことがあるので、重要である。

【0730】

他のステークホルダは、それぞれのクラスタの所有者である。例えば、コントラクタ4332は、オーケストレーションサービス4334を含むドメインB 4312の所有者であってよい。ベンダ4320は、コアサーバ4322を含む、ドメインE 4315の所有者であってよく、－例えば、ベンダ4320は、コアサーバ4322ハードウェアを所有し、かつ、ファームウェア更新処理について責任を負い、一方で、ドメインD 4314内のコントラクタは、他の保守タスクを有し得る。さらに、なおも、ドメインA 4311内のオペレータO1 4324は、コアサーバ4322、等に対して電力を供給することができる。従って、ドメインコンテキストは、所与のサービスまたはリソースについてオーバーラップすることがある。しかしながら、オーバーラップしているコンテキストは、共有ドメインコンテキストと同義でなくてよい。

【0731】

さらなる例において、北-南インタラクション(例えば、ドメインC 4313内に示されるようなもの)は、ドメイン内（intra-domain）トラフィック、並びに、ドメイン間（inter-domain）トラフィックのために、LSMおよびセキュリティポリシによって制御され得る。ドメイン内テナントは、ドメイン間の隔離／共有ポリシとは異なる隔離／共有を要求し得る。LSMは、ドメイン固有のポリシおよびテナント固有のポリシについて階層化され得る。加えて、ゲートウェイ、ファイアウォール、スイッチ、ルータ、および、他の「中間ボックス」は、LSMおよびセキュリティポリシのための実施ポイントになり得る。なおも、さらなる例において、各ドメインは、異なる－ドメイン固有のLSM－を適用することができる、それは、制限され、または、ブロックされたアクセスについて可能性を有し得るものである。

【0732】

図４４は、仮想マルチドメイン通信アーキテクチャ４４００のモデルの一例を示す。シナリオは、バックエンドにバックホールされないが、セキュア且つ信頼できる方法でエッジ間で（例えば、ドメイン４４１０から４４２０へ）トラフィックを転送することを含む、マルチテナントトラフィックについて示される。具体的に、エッジ及びエッジ間ローミングにおけるイースト－ウェスト（East－West）マルチテナント加入者トラフィックが示される。物理基地局、又は基地局のプール４４０４は、次世代中央局計算機及びアクセラレータラックにより、エンタープライズ及びネットワーク機能に加えて、レイヤ１、レイヤ２、又はレイヤ３トラフィックのために複数の仮想基地局（virtualized base stations (vBS)）４４０６を提供する。ここで、テナント（例えば、オペレータ４４０２）は、１つ以上のＶＮＦコンポーネント（VNF component (VNFC)）により更に構成される１つ以上のＶＮＦを実行してよい。一例では、ＶＮＦＣは、テナントのドメイン内から他のＶＮＦＣの各々の中でドメインコンテキスト又はアクセス制御共有ポリシを使用し得る異なる独立ソフトウェアベンダ（independent software vendor (ISV)）からのものであってよい。一例では、ＶＮＦＣは、アクセス制御ポリシ及びＳＬＡにより有効にされるとき、他のテナントとドメインコンテキストを共有してよい。

【0733】

図４４のコンテキストでは、ＭＥＣノード４４０８又はオペレータアクセスコンポーネント４４０２は、別のＬＳＭ実施点を提供してよい。このノード４４０８は、リソースプール、ＭＥＣインフラストラクチャ、プロキシ、又は他の技術へのアクセスを制限してよい。更に、このコンテキストでは、ネットワーク機能をホストする任意の技術からドメイン制御部コンテキストが提供されてよい。ドメイン固有ＬＳＭは、ドメイン境界に跨がる（例えば、ＶＦ＃１を跨がる）任意のテナント作業負荷に適用されてよい。ドメイン内、テナント間相互作用は、範囲の制限される第２ＬＳＭにより制御されてよい。

【0734】

オーナ、加入者、テナント、ベンダ、契約者、オペレータ、等は、彼らのドメイン加入（例えばドメインオーナ）により、資格を与えられてよい（例えば、システム内でユニークに識別される）。リソース、サービス、機能、等は、同様に資格を与えられる（例えば、ドメインリソース）。完全に資格の与えられたドメイン加入は、利害関係者の信頼コンテキストの曖昧さをなくすために使用されてよい。例えば、ドメインは、（権利又は所有権の終了まで）機能又はサービスのセットを実行する又は提供するために信頼される、リソース、ファームウェア、ソフトウェア、ベンダ、サプライヤ、契約者、等の集合を識別する信頼ポリシを形成してよい。

【0735】

一例では、ポリシは、ピアドメインエンティティによる認証、承認、又は証明の条件として、ドメインリソースへのアクセス又は権利を許可するアクセスポリシの形式で実現されてよい。一例では、アクセスポリシは、以下の形式を有してよい：
<peer_domain>.<peer_owner_or_resource>:
<local_domain>.<local_owner_or_resource>.<allowed_rights_or_access>

【0736】

一例では、イースト－ウエストマルチドメイン仮想モデルでは、ポリシは以下の形式を取ってよい：
<peer_domain>.<peer－sub－domain>.<peer_owner_or_resource>:
<local_domain>.<local_owner_or_resource>.<allowed_rights_or_access>

【0737】

信頼確立は、ピアエンティティが自身の信頼性プロパティ、アイデンティティ、能力、又は構成に関するローカルエンティティを承認すると、達成されてよい。一例では、ＶＮＦは、自身をローカルエンティティに対して認証する。しかしながら、一例では、全部のＶＮＦＣは親ＶＮＦに対して認証される。ここで、ＶＮＦＣの信頼は、親又は所有するＶＮＦに委任される。

【0738】

一例では、ドメインアイデンティティは、全ての利害関係者が信頼する中央組織（例えば、認証局、政府、又は金融機関）の存在しなくてよい、自己主権であってよい。一例では、自己主権アイデンティティは、Ｗ３Ｃ（World Wide Web Consortium）分散識別（decentralized identification (DID)）定義に従う。

【0739】

一例では、アクセスは、許可された権利及びアクセスの共通部分を見付けることにより、ドメイン間で手動で計算されてよい。これは、（他のシンタックスが可能であるが）以下の例に従い達成されてよい。

【0740】

ドメインＢはドメインＡアクセスを記述するアクセスポリシを形成する：
<Domain_A>.<Owner_O１>.<Rsrc_R１>
は、以下への：
<Domain_A>.<Owner_O２>.<Rsrc_R２>
<Permissions:P１,P２>によるアクセスを有する。

【0741】

サブドメイン１及び同じドメインＡ内のサブドメイン１は、以下のドメインＣアクセスを記述するアクセスポリシを形成する：
<Domain_A>.<Sub－Domain １>.<Owner_O１>.<Rsrc_R１>
は、以下への：
<Domain_C>.<Sub－Domain ３>.<Owner_O２>.<Rsrc_R２>
<Permissions:P１,P２>によるアクセスを有する。

【0742】

同様に、ドメインＡは、以下のドメインＢへのアクセスを記述するポリシを形成する：
<Domain_B>.<Owner_O２>.<Rsrc_R２>
は、以下により：
<Domain_A>.<Owner_O１>.<Rsrc_R１>
<Permissions:P２,P３>によるアクセスを有する。

【0743】

評価は、Ｐ２を共通許可として明らかにする。ドメインＡ及びＢの両方は、同じ結論に至る。

【0744】

マルチドメイン信頼確立のための本発明の技術は、他の変形に適用可能であってよいことが理解される。例えば、これらの技術は、バックエンドへのバックホールを取得しないマルチテナントトラフィックに、及びセキュア且つ信頼できる方法でエッジ間で生じる必要のあるポリシ転送に、適用してよい。従って、このような技術は、エッジにあるイースト－ウエストマルチテナント（オペレータ）のために、エッジ間ローミングの部分として適用されてよい。

【0745】

エッジコンピューティング環境（例えば、エッジクラウド１１０であり、システム及び装置を実装する）におけるマルチドメイン信頼確立のための第１の例示的な方法（例Ｍ１）は、処理回路（ノード又は装置２２００、２２３２、２２４０、又は２２５０に又はそれにより実装される）を用いて実行される方法である。当該方法は、エッジコンピューティング環境の第１クラスタのエッジコンピューティングノードにおいて、第１クラスタの特定リソースにアクセスするための要求を受信するステップであって、該要求はエッジコンピューティング環境の第２クラスタのエッジコンピューティングノードから生じ、第１及び第２クラスタは、それぞれのクラスタ内のリソースへのアクセス範囲をそれぞれ定める、ステップと、第１及び第２クラスタ内のリソースへのアクセス範囲から、特定リソースへのアクセス権を識別するステップと、特定リソースへの識別されたアクセス権に従い、第１クラスタの特定リソースへのアクセスを可能にするステップと、を含む。

【0746】

第２の例（例Ｍ２）では、例Ｍ１の主題は、クラスタがエッジコンピューティング環境にあるそれぞれのテナントにより制御されることを含む。

【0747】

第３の例（例Ｍ３）では、例Ｍ２の主題は、それぞれのテナントがネットワークオペレータであることを含む。

【0748】

第４の例（例Ｍ４）では、例Ｍ１～Ｍ３の主題は、作業負荷が、複数のサービスを達成するために、複数の機能の使用を連携させる複数のアプリケーションから構成されることを含む。

【0749】

第５の例（例Ｍ５）では、例Ｍ１～Ｍ４の主題は、クラスタが、それぞれのクラスタ内のリソースから配信すべきサービスのレベルを定めるために、それぞれのサービスレベル合意（service level agreement (SLA)）に関連付けられることを含む。

【0750】

第６の例（例Ｍ６）では、例Ｍ１～Ｍ５の主題は、特定リソースへのアクセスの要求を満たすために、特定リソースへのアクセス権に基づき、エッジコンピューティング環境内の２次関係を識別することを含む。

【0751】

第７の例（例Ｍ７）では、例Ｍ１～Ｍ６の主題は、それぞれのクラスタが、それぞれのテナント又は加入者について、それぞれのテナント又は加入者によりアクセス可能なそれぞれのサービスについて、関係を定めることを含む。

【0752】

第８の例（例Ｍ８）では、例Ｍ１～Ｍ７の主題は、特定リソースへの識別されたアクセス権は、第１クラスタ及び第２クラスタにより提供される対応するリソース種類に対して許可された権利及び許可されたアクセスの共通部分から識別されることを含む。

【0753】

種々の設定で、例Ｍ１～Ｍ８（及びマルチドメイン信頼確立の他の態様）は、定義されたアプリケーションプログラミングインタフェース、又はインタフェース仕様；通信プロトコル、メッセージフォーマット、又は定義の使用；並びにエッジコンピューティング環境内のアクセス制御及び信頼メカニズムのためのポリシ及びロジックの他の使用及び実装、の結果として観察され又は見られてよい。例Ｍ１～Ｍ８及びこれらの信頼及びセキュリティ管理技術の他の態様は、（例えば、ＦａａＳ又はＥａａＳ設定で動作するサービスのセキュリティ拡張を実施するために）サービス動作及びサービス機能の結果としても観察され又は実装されてよい。更に、例Ｍ１～Ｍ８の方法は、実装された命令として（例えば、命令が実行されると方法を実行する機械可読媒体により）、又は実装されたハードウェア構成として（例えば、方法を実行し又は達成するための構成を含む機器により）、エッジコンピューティングシステム内で提供されてよい。従って、例Ｍ１～Ｍ８の特徴（及び信頼及びセキュリティ管理技術の他の特徴）は、システムオーケストレータ又は設計者により連携させられ又は設計されるとき、エッジクラスタ又はエッジクラウドシステムを構成するために、本願明細書に記載の他の例のうちのいずれかと結合されてよい。

【0754】

装置間のセキュアなデータ共有の例

【0755】

一例では、エッジコンピューティングシナリオ（例えば、エッジクラウド１１０、及び図３～２２Ｄに示すエッジコンピューティングシステム構成）は、装置にセキュアなデータ共有交換の種々の形式を可能にする一時的ペアリングを組み入れてよい。セキュアなデータ共有交換は、以下シナリオ：末端装置（例えばクライアント装置）が同じテナントに属す又はそれに関連付けられ、接続に合意し、及びセキュアな通信を確立し及び行うためにエッジクラウド環境を介して認証が生じる、におけるような多くの組み合わせで生じる。このシナリオでは、エッジ基地局（又は他の同等のエッジノード）は、対称暗号化のための一時的秘密鍵を生成する。非対称セキュア接続を用いて、対称鍵を用いてエッジ基地局にあるバッファ位置をセキュアに読み出し及び書き込むために、一時的秘密鍵は、装置へ送信される対称鍵の使用により、それぞれの装置によりアクセス可能な、メモリ、記憶装置、機能、及びエッジ基地局の他のリソースに、セキュアなアクセスが提供される。このようなアプローチは、Ｖ２Ｖ及びＶ２Ｘ通信等の同じ会社の車両間のような装置間及びノード間通信設定（例えば、地図またはファームウェア更新）に広く適用可能であってよい。

【0756】

一例では、セキュアなデータ共有のアーキテクチャは、エッジクライアント及びエッジプラットフォームの両方が、データの動的にセキュアな且つ非同時性の交換を行うことを可能にする。図４５は、エッジクライアントＡ４５１０、エッジクライアントＢ４５２０、及びセキュアエッジサーバ４５３０の間でセキュアなデータ操作４５００を可能にするシナリオを示す。このシナリオでは、エッジクライアント４５１０、４５２０は、以下の要素により拡張される。

【0757】

図示のように、鍵セキュリティ動作シーケンスが実行される（しかしながら、他の動作シーケンス又は変形が可能であってよい）。先ず、エッジクライアント４５１０、４５２０は、クライアントがデータを共有したい他方のエッジクライアント（例えば、相手方クライアント４５１０、４５２０）の公的証明書のセットを所有し及び扱うための構成（例えば、指示、ソフトウェア、ファームウェア、実装されたロジック）を含む。この特徴は、クライアントＩＤ（Client ID）又は組織ＩＤ（Organization ID）（例えば、複数の装置が同じ秘密鍵を共有する場合）、及び公的証明書（Public certificate）を追跡してよい。このデータは、何らかの一時的特性（例えば、Ｎ単位時間のうちにアクセスされなかった場合に終了する）を含み又は関連付けられてよい。

【0758】

次に、エッジクライアント４５１０、４５２０は、それぞれのクライアントが特定エンティティと特定データセットをセキュアに共有することを要求することを許可する構成を含む。インタフェースは、クライアントＩＤ及び共有されるべきペイロードを含み又は追跡してよい。この機能が（例えば、エッジクライアントＡ４５１０で）呼び出されると、以下の動作が実行される。（１）対称鍵（Symmetric Key）を生成する；（２）Ｂ（エッジクライアントＢ４５２０）のために対称鍵を暗号化する；（３）対称鍵を用いてＢのためにコンテンツを暗号化する；（４）対称鍵及び暗号化コンテンツを接続されたエッジサーバ（例えば、基地局であってよいエッジサーバ４５３０）へ送信する。

【0759】

第３に、エッジクライアント４５１０、４５２０は、該特定クライアントのためにエッジサーバ（例えばエッジサーバ４５３０）に格納されたデータが存在する場合に、それぞれのクライアントが要求することを許可する構成関数を含む。関数は、セキュアな方法でエッジサーバに接続し、クライアントにＩＤを提供する。関数は、他のピアにより公開されたデータセットのリストを検索し、秘密鍵を用いてデータを検索し、データセットを解読する。

【0760】

エッジサーバ（例えば、エッジサーバ４５３０）は、発生元のエッジクライアントにより提供されたデータが格納されるメモリのセキュアなピース（Ｉｎｔｅｌ（登録商標）ＳＧＸ（商標）、ＡＲＭ（登録商標）ＴｒｕｓｔＺｏｎｅ（商標）、又は類似のセキュアストレージ／エンクレーブ技術によりセキュアにされる）を含む。エッジサーバは、最終的な宛先（例えば、エッジクライアントＢ４５２０）に情報を更に通信するために、発生元のエッジクライアントと同様の役割で動作可能な命令を更に含む。この方式では、全てが認証されセキュアなチャネルの範囲内にあるエッジ装置－基地局－装置の通信のシーケンスを通じて、エンド間全体のセキュアなデータ交換が可能なる。

【0761】

テナントは、それ自体の目的として、パケット及び通信セキュリティを考慮しない場合が多い（テナントは、主にサービス及びサービスの結果を考慮するので）。更なる例では、本願明細書に記載されるセキュリティメカニズムのいずれかは、Ｘ－ａａＳへのセキュアなアクセスを提供するために使用されてよい。ここで、Ｘは、ＭＥＣ又は他のエッジ計算ノードによりホスティングされているセキュリティ関連サービス又は関数である。エッジ環境内でのセキュリティ関数のホスティングは、循環性問題を導入する可能性がある。例えば、ＴＬＳ－ａａＳは、ＴＬＳ－ａａＳホストへのアクセスを保護し、次にＴＬＳトンネル内で要求されたＴＬＳ関数を実行するために、ＴＬＳを使用する必要を示唆することがある。

【0762】

セキュリティメカニズム及びアプローチは、Ｃｒｙｐｔｏ－ａｓ－ａ－Ｓｅｒｖｉｃｅのようなエッジシステム内で提供される多くの形式の上位セキュリティサービス抽象化統合してよい。このようなセキュリティメカニズム及びセキュリティＸ－ａｓ－ａ－ｓｅｖｉｃｅ抽象化をサポートするために、エッジコンピューティングシステムは、信頼性レベル、信頼、認証局の信頼するエンティティのリスト、等を定めるためにメタデータのセットに関連付けられる、アクセスされるべき関数の発見可能なリストを開示し又はアクセスしてよい。このようなセキュリティＸ－ａａＳコンポーネントの動作は、セキュリティＸ－ａａＳが動作する間、マルチテナント隔離を実施し、テナント間の再度チャネルのリスクを低減するよう構造化されてよい。

【0763】

セキュアなハードウェアメカニズムは、暗号プリミティブを提供するだけでなく、利用可能なハードウェア及び展開の特性に完全にプログラム可能な関連する暗号サービス（例えば、ＴＬＳ－ａａＳ、ＤＴＬＳ－ａａＳ）をサポートするためにも、エッジコンピューティング環境で使用されてよい。Ｉｎｔｅｌ（登録商標）ＳＧＸ（商標）のようなセキュリティ特徴は、これらの作業負荷をエンクレーブ／ドメイン内にホスティングし、及びネットワークインタフェースを使用のために開示することにより、Ｄ／ＴＬＳ－ａａＳのセキュリティを向上するために使用できる。さらに、Ｘ－ａａＳ相互作用に対する要求／応答を保護するために、発呼側がＤ／ＴＬＳを完全に適用することを可能にするために、トンネリング及びホップバイホップ保護が適用されてよい。これは、セキュリティトンネリングを通じて、サービスであって、ＯＳＣＯＲＥはサービスであってよく、ＴＬＳはノードへのアクセスを保護する、サービス、又は、ノードがＴＬＳ／ＯＳＣＯＲＥトンネルを介して汎用暗号／解読を実行するためにスマードカード／ＴＰＭインタフェースを公開する構成、として提供されてよい。

【0764】

更なる例では、セキュアな技術（例えば、Ｉｎｔｅｌ（登録商標）ＭＫＴＭＥ（商標））は、「共有テナントコンテキスト」を生成するために使用され得る。その結果、新しい鍵（例えば、ＭＫＴＭＥ鍵）が、両方の（複数の）テナントに知られている（例えば、Ｄｉｆｆｉｅ－Ｈｅｌｌｍａｎを用いて）交渉される。共有鍵は、共有データを収容する異なるメモリ暗号化コンテキストを生成するために使用される。作業負荷アプリケーションは、従って、他のテナントにより教諭されるので、事実上信頼される「共有」データを扱ってよい。処理ノード（例えば、セルサイト（cell tower））は、共有メモリ、共有ストレージ装置、マルチキャストのための共有ネットワーキングアドレス、等のような共有コンテキストを提供してよい。

【0765】

更に、更なる例では、ピアエンドポイントにおける信頼は、エッジインフラストラクチャとの以前の信頼コンテキストを有するエンドポイントから活用されてよい。インフラストラクチャは、リソース及びユーザがアドホック協力又は連動を促進するために追加可能なドメインを動的に生成してよい。

【0766】

エッジコンピューティング環境における（例えば、エッジクラウド１１０における、システム及び装置を実装する）装置間のセキュアなデータ共有を実装する第１の例示的な方法（例Ｎ１）は、処理回路（例えば、ノード又は装置２２００、２２３２、２２４０、又は２２５０上で又はそれにより実装される）を用いて実行される方法である。当該方法は、第１エッジノードにおいて、第２エッジノードに通信されるべきコンテンツの暗号化のための対称鍵を生成するステップと、第１エッジノードにおいて、対称鍵を暗号化するステップと、第１エッジノードにおいて、対称鍵を用いて第２エッジノードに通信すべきコンテンツを暗号化するステップと、エッジノードサーバへセキュアな暗号化チャネルを介して、暗号化対称鍵及び通信されるべき暗号化コンテンツを通信するステップと、を含み、暗号化対称鍵及び通信されるべき暗号化コンテンツは、第２エッジノードにより、エッジノードサーバから後に取得される。

【0767】

第２の例（例Ｎ２）では、例Ｎ１の主題は、暗号化対称鍵及び通信されるべき暗号化コンテンツが、第２エッジノードによりエッジノードサーバのセキュアストレージから取得されることを含む。

【0768】

第３の例（例Ｎ３）では、例Ｎ２の主題は、暗号化対称鍵及び通信されるべき暗号化コンテンツが、第２エッジノードにより、セキュアストレージにアクセスして、暗号化コンテンツを解読するために対称鍵を使用することにより、エッジノードサーバから取得されることを含む。

【0769】

第４の例（例Ｎ４）では、例Ｎ２～Ｎ３の主題は、セキュアストレージが、エッジノードサーバにより維持されるセキュアエンクレーブ又はセキュアバッファである構成を含む。

【0770】

第５の例（例Ｎ５）では、例Ｎ１～Ｎ４の主題は、エッジノードサーバが基地局であり、第１エッジノード及び第２エッジノードがエンドポイントクライアント装置である構成を含む。

【0771】

第６の例（例Ｎ６）では、例Ｎ１～Ｎ５の主題は、暗号化対称鍵及び通信されるべき暗号化コンテンツが、第２エッジノードにより、非同時性通信セッションを用いてエッジノードサーバから取得されることを含む。

【0772】

第７の例（例Ｎ７）では、例Ｎ１～Ｎ６の主題は、対称鍵を生成し、対称鍵及び通信されるべきコンテンツを暗号化する動作が、第１エッジノードにおいて信頼される機関により保証されたハードウェアを用いて実行されることを含む。

【0773】

第８の例（例Ｎ８）では、例Ｎ７の主題は、暗号化対称鍵及び暗号化コンテンツを解読する動作が、第２エッジノードにおいて信頼される機関により保証されたハードウェアを用いて実行されることを含む。

【0774】

第９の例（例Ｎ９）では、例Ｎ７～Ｎ８の主題は、信頼される機関がハードウェア製造者である構成を含む。

【0775】

第１０の例（例Ｎ１０）では、例Ｎ１～Ｎ９の主題は、第１エッジノードが、コンテンツを教諭するエッジノードの公的証明書のセットを維持する構成であって、該公的証明書のセット第２エッジノードからのは公的証明書を含む、構成を含む。

【0776】

第１１の例（例Ｎ１１）では、例Ｎ１～Ｎ１０の主題は、信頼される暗号動作を生成し確立するための、エッジコンピューティングシステム内でのサービスとしてのセキュリティ関数の使用を含む。

【0777】

種々の設定で、例Ｍ１～Ｍ１１（及びセキュアなデータ共有の他の態様）は、定義されたアプリケーションプログラミングインタフェース、又はインタフェース仕様；通信プロトコル、メッセージフォーマット、又は定義の使用；並びにエッジコンピューティング環境内のセキュアなデータ共有のためのポリシ及びロジックの他の使用及び実装、の結果として観察され又は見られてよい。例Ｍ１～Ｍ１１及びこれらのデータ共有構成の他の態様は、（例えば、ＦａａＳ又はＥａａＳ設定においてサービス又はサービスユーザ間でデータを共有するために）サービス動作及びサービス機能の結果としても観察され又は実装されてよい。更に、例Ｍ１～Ｍ１１の方法は、実装された命令として（例えば、命令が実行されると方法を実行する機械可読媒体により）、又は実装されたハードウェア構成として（例えば、方法を実行し又は達成するための構成を含む機器により）、エッジコンピューティングシステム内で提供されてよい。従って、例Ｍ１～Ｍ１１の特徴（及びセキュアなデータ共有の他の特徴）は、システムオーケストレータ又は設計者により連携させられ又は設計されるとき、エッジクラスタ又はエッジクラウドシステムを構成するために、本願明細書に記載の他の例のうちのいずれかと結合されてよい。

【0778】

グループセキュア通信の例

【0779】

分散型アーキテクチャにおける課題の１つは、作業負荷及び装置がエッジを通じて動的に移動し得る分散型エッジアーキテクチャ内にテナントが有するサービスに関して任意の時間にテナントによりアクセスされ得る分散型エッジアーキテクチャ上で協力する装置の間の通信を処理及びセキュアにする方法である。

【0780】

情報セキュリティ及びプライバシは、今日、ポイントツーポイントベースで取得される。ここでは、装置又はサービスは、以下の共通の状況で提示されるように、エンドツーエンドセキュアチャネルを確立する：ラップトップ又はスマートフォンは、仮想私設ネットワーク（virtual private network (VPN)）セッションをドメイン制御部と確立し、個人用マシン（例えば、スマートフォン、ラップトップ、等）上のブラウザは、ＨＴＴＰＳ（hypertext transfer protocol secure）セッションをウェブサイト（例えば、Ｇｏｏｇｌｅ、Ｂｉｎｇ、等）と確立し、スマートフォンは基地局等に接続し、他方で多数の種類の通信が、会議のような「ウェブのような」グループ通信である。会議内の各人物は、下位レベルにある彼／彼女自身のプライベートチャネル（例えば、かれらの電話接続、彼らのネットワークス宅、等）上にいて、グループ通信経験を実施するのは、「アプリケーション」又は「ソリューション」（ウェブ会議アプリケーション、等）である。

【0781】

多くの他の通信（例えば、スマートフォンと別のスマートフォン、エンドツーエンド通信セッション、等）では、通信の生じるピアツーピアエンドポイントのセットは固定されない。例えば、ジョンは、電車で移動し、彼のスマートフォンを用いてウェブサイトを閲覧してよく、電車が動くと、ジョンと彼のキャリアとの間のセキュアチャネルは多くの異なる基地局を横切ってよい。

【0782】

エッジコンピューティングシナリオにおいて提供される移動性により（例えば、エッジクラウド１１０、及びシステム及び装置を実装する）、セキュア通信チャネルを設定する必要が頻繁に生じる。エッジ通信の中のネットワークチャネルの主な使用が、この必要に起因する有意なボトルネックを経験しないが、新しく出現する使用は、性能及び拡張性の困難を経験する可能性がある。１つの要因は、データ量が増加し、データが危険に晒されない資産と考えられるようになるにつれて、情報セキュリティが重要性を増していることである。第２の要因は、可能になりつつある近接性に基づくアドホックな自動化された協力の継続的に増大する傾向である。

【0783】

多くの場合に、複数のエンティティ及びサーバは、共通の目標を達成するために協力する必要があってよく、協力する／通信するエンティティ（例えば、装置、コンピュータ、スイッチ、ハブ、等）の間の多数のポイントツーポイント仮想セキュアチャネルを生成し及び破棄する必要を回避することは非常に望ましい。更に、全ての装置が専用ハードウェアを用いて暗号化／復号を実行できなくてよく、参加者の数が増加し、それに伴いグループ内でのアツーピア通信で使用される暗号鍵が増加するにつれ、各装置は、グループの各メンバへ送る又は届いたメッセージをそれぞれ暗号化／解読しなければならない。以下のアプローチは、グループ通信を可能にする従来のポイントツーポイント及びアプリケーションに対する拡張可能な代替案を提供する。

【0784】

セキュアなグループ通信のための従来のソリューションは、単一のエンティティにより維持される加速（acceleration）装置又は予めプロビジョニングされた通信シークレットを含んでよい。しかしながら、全ての装置が、加速装置又は予めプロビジョニングされた通信シークレットを含まなくてよく、必ずしも全ての通信サービスプロバイダが電気通信プロバイダエンティティではない。従って、従来のソリューションは、非効率である場合があり、不適合装置（例えば、アクセラレータではなく、又は予めプロビジョニングされたシークレットではない、等）及び他のサービスプロバイダ（例えば、電気通信プロバイダ、等）が通信に関与するとき、機能しない場合がある。専用ハードウェアは、電話又はタブレットのような末端装置では非実用的であり得る。更に、専用ハードウェアは基地局、顧客敷地内設備（customer premise equipment (CPE)）、等に実装されてよいが、スループットは、通信する装置又は設計された新しいアプリケーションの数の増大と共に増大しない。

【0785】

従来のセキュリティは、分散型エッジコンピューティングの出現前の使用における設定で実装されるとき、ポイントツーポイントの概念である。例えば、モバイル装置Ｘは、基地局とセキュアセッションを確立してよく、基地局間で移動するとき、そのエンドツーエンドセッションの基地局から基地局へのハンドオーバが生じ得る。一例では、複数のエンティティ及びサービスが、共通の目標を達成するために協力する必要があってよい。協力に関与するパーティは、協力の目的のために共通のセキュリティ証明書（security credential）を確立してよい。共通のセキュリティ証明書は、複数の基地局間で同時にアクティブであってもよい。

【0786】

本願明細書で議論するシステム及び技術は、エッジコンピューティングノードのクラスタのエッジコンピューティングシナリオにおいてアドホックに動的に署名付きグループ証明書（及び関連する鍵素材）の生成を可能にすることにより、エッジコンピューティングシステム（例えば、エッジクラウド１１０、及び図３～２２Ｄに示すエッジコンピューティングシステム構成）におけるグループ通信を向上する。これは、通信グループの全メンバが、ポイントツーポイントデータ暗号化で使用される鍵と同様に、セッション暗号鍵として共通鍵を使用することを許可する。しかしながら、この共通鍵は、グループセッションに及ぶ。

【0787】

常に、通信グループ内には、グループリーダが存在し、該グループリーダは、グループセッションを終了する必要のある場合、代替のグループリーダをランダムに選択し広告する。分散型システムにおける合意及び選出のためのプロトコルは、現在のグループリーダが切断される場合に、グループリーダの回復力のある（resilient）選出を提供するために使用されてよい。これは例外（例えば希な）条件であり、従って、それを扱う必要は、性能の関心事を導入しない。しかしながら、グループリーダの損失の希なケースでの最適化のように、グループは、（希に）影響を受けるグループセッションについて従来のピアツーピア暗号化方式に戻ってしまう。

【0788】

更なる最適化は、例えば、グループのサイズがポリシの決定した動的閾値に達するまで、ピアツーピアトランスポート暗号鍵の使用を含んでよい。セッションの特定のカテゴリは、情報システムセキュリティ基準に基づき、グループ鍵へと移動されなくてよい。例えば、データローカリゼーション要件に従う地理（geographies）の間で遷移する通信は、地理的領域毎に異なる暗号強度を実施してよく、従って、グループ鍵プロトコルへ遷移しなくてよい。これは、特にマルチキャスト／ブロードキャストチャネルプロトコルに渡る階層構造化された通信で、少ないオーバヘッド、軽快さ、及び拡張性を提供する。

【0789】

以下のシステム及び方法は、タスクの完了において連携する装置が、それらのグループの間でセキュアに通信することを可能にすると同時に、エッジアーキテクチャの役割を、グループメンバの必要に基づきインフラストラクチャへとシフトさせる、動的セキュリティ通信アーキテクチャを提供する。プライベート通信は、非グループ通信について維持され、非グループ通信を別のグループメンバにより傍受されることを防ぐ。

【0790】

図４６は、エッジにおけるグループセキュア通信のためのシステム４６００の一例のブロック図である。装置Ａ４６１０、Ｂ４６１２、Ｃ４６１４、及びＤ４６１６（例えば、図３～２２Ｄで参照したエッジコンピューティング装置）は、共通タスク（例えば、タスクＡ４６１８、等）を完了するために動作していてよい。装置４６１０～４６１６は、異なる基地局２６２０によりサービスされてよい。例えば、Ａ４６１０は基地局Ｓ１のカバレッジエリアにいてよく、Ｂ４６１２及びＣ４６１４は基地局Ｓ２のカバレッジエリアにいてよく、Ｄ４６１６は基地局Ｓ３のカバレッジエリアにいてよい。アプリケーションサービス専用ハブ（例えば、共同ブリッジ、等）を設けるのではなく、ジャストインタイム（just－in－time）で生成されるセキュリティ証明書が、タスクを完了するために動作している全てのパーティの間のリアルタイム情報通信を可能にするために、グループ通信及び役割マネージャ４６０２により生成される。これら及び他の例では、役割マネージャは、例えば役割に基づくアクセスポリシ（Role－Based Access Control (RBAC)）ポリシの適用されるＬＳＭ実施ポイントであり得る。

【0791】

一例では、セキュリティ証明書は、特定のグループセッションについてのみ有効であってよい。従って、グループセッションの外部のそれぞれの装置の全ての他の通信は、プライベートであり、グループセッション内の通信は共有されセキュアである。これは、モバイルであり従って時により異なる地点で異なる物理ネットワークに広がる仮想バスに渡りシームレスに移動するエッジにおいて、アドホックなマルチキャストグループを生成する能力を提供する。

【0792】

一例では，グループは、ＤＡＡ（Direct Anonymous Attestation）、ＥＰＩＤ（Enhanced Privacy Identifier）、又はＰｏｓｔ－Ｑｕａｎｔｕｍ ＥＰＩＤのようなポスト量子セーフグループ方式のようなグループ署名方式を使用して、グループメンバ間のメッセージ交換を認証し、又は共有対称鍵またはペア共有対称鍵のグループ鍵交換４６０４を促進してよい。グループは、グループメンバを管理し、グループ鍵生成方法を用いてメンバをグループに参加させ、メンバの種々の秘密鍵を用いて形成された署名を認証するために使用されてよいグループ証明書を発行するマスタノード（例えば、オーケストレータ等）を指名する。署名付きＤｉｆｆｉｅ－Ｈｅｌｌｍａｎ（ＤＨ）のような対称鍵交換プロトコルは、対称鍵を動的に確立するために使用されてよい。ここで、グループ署名鍵はＤＨメッセージを（例えば、Ｓｉｇｍａプロトコル等を用いて）認証する。

【0793】

リアルタイム又は「ジャストインタイム」のグループ内セキュア通信は、「リアルタイム」又は「ジャストインタイム」動作の前に鍵交換動作を実現することにより達成されてよい。オーケストレータは、ＲＴ及びＪＩＴ協力的作業負荷がこのモードで実行するとき、各メンバの代わりに実行すべきグループ協力サービスをスケジューリングすることにより、連携させ、次にオーケストレータは、グループ協力サービスをＲＴ又はＪＩＴモードに遷移させるためにシグナリングする。オーケストレータは、鍵交換動作を直接実行し又は実行を科技高間管理サービスに委任するので、鍵交換動作が完了するときを知る。

【0794】

メンバノードがモバイルであり、異なる基地局へローミングする場合、ローミングコンテキストは、メンバのグループ署名鍵及びグループ対称鍵を含んでよい。グループ対称鍵は、頻繁に終了し、周期的に再交付を要求してよい。第１対称鍵を用いて保護されるコンテンツは、第２対称鍵が交渉されるとき、輸送中であってよい。満了期間は、第１対称鍵により暗号化されたコンテンツが第２対称鍵を用いて解読され及び再暗号化される重複する時間ウィンドウを含んでよい。鍵終了は、鍵管理トラフィックのために専用のグループコンテキストを用いてグループメンバへのネットワークブロードキャストを通じて動的に通信されてよい。更に、鍵終了は、終了の時間／日付けを含み且つグループリーダ／オーケストレータ／鍵マネージャサービスにより（例えばＫｅｒｖｅｒｏｓ等を用いて）署名されたチケット又はトークン構造を用いて通信されてよい。

【0795】

オーケストレータ、グループリーダ、及び鍵マネージャサービスも基地局間でローミングしてよい。これは、サービス発見レジストリを新しいサービス位置情報で更新することにより促進される。順方向ローミング情報は、アプリケーションコンテキスト情報に基づき、サービスの位置する場所を予測する。このデータは、ローミング管理制御部に、どのサービス発見情報を記録するかに関して知らせる。

【0796】

エッジコンピューティングシステム（例えば、エッジクラウド１１０、及びシステム及び装置を実装する）においてグループセキュア通信を実施する第１の例示的な方法（例Ｏ１）は、処理回路（ノード又は装置２２００、２２３２、２２４０、又は２２５０上に又はそれにより実装される）を用いて実行される方法であり、当該方法は、エッジノードにおいて、エッジコンピューティングノードのクラスタから定義されたグループについて、グループ通信セッションの開始を識別するステップと、グループ通信セッションに参加するグループメンバのセットを決定するステップと、グループ通信セッションのためのセキュアグループ通信チャネルを生成するステップと、セキュアグループ通信チャネルを用いてセキュア通信を実施する際に使用されるべきグループメンバのセットのメンバの鍵を送信するステップと、を含む。

【0797】

第２の例（例Ｏ２）では、例Ｏ１の主題は、通信チャネルを用いてグループメンバのセットにより完了されるべきタスクに関連付けられた役割を決定するステップと、グループメンバのセットについて基地局セットを識別するステップであって、基地局セットは、グループメンバのセットにサービスを提供する基地局を含む、ステップと、基地局セットの１つ以上のメンバにおいて役割を活性化させるステップと、を含む。

【0798】

第３の例（例Ｏ３）では、例Ｏ１～Ｏ２の主題は、役割が、オーケストレータ、グループリーダ、又は鍵マネージャ、を含むグループから選択されることを含む。

【0799】

第４の例（例Ｏ４）では、例Ｏ１～Ｏ３の主題は、グループメンバのセットのそれぞれのメンバと鍵交換を実行することにより、セキュア通信チャネルを生成するステップであって、鍵は鍵交換が成功すると、メンバへ送信される、ステップ、を含む。

【0800】

第５の例（例Ｏ５）では、例Ｏ１～Ｏ４の主題は、グループ通信セッションが終了したことを決定するステップと、鍵を無効にするステップと、セキュアグループ通信チャネルを破棄するステップと、を含む。

【0801】

第６の例（例Ｏ６）では、例Ｏ１～Ｏ５の主題は、協力的作業負荷の開始の指示を受信することにより、グループ通信セッションの開始を識別するステップを含む。

【0802】

第７の例（例Ｏ７）では、例Ｏ６の主題は、協力的作業負荷に協力するよう指定された１つ以上のノードの指示を受信することにより、グループ通信セッションに参加するグループメンバのセットを決定するステップを含む。

【0803】

第８の例（例Ｏ８）では、例Ｏ１～Ｏ７の主題は、グループがエッジコンピューティングシステム内のエンティティの任意のメンバからのメンバシップを含むことを含む。

【0804】

種々の設定で、例Ｏ１～Ｏ８（及びセキュアグループ通信の他の態様）は、定義されたアプリケーションプログラミングインタフェース、又はインタフェース仕様；通信プロトコル、メッセージフォーマット、又は定義の使用；並びにエッジコンピューティング環境内のグループを定義する及びグループ通信を行うためのポリシ及びロジックの他の使用及び実装、の結果として観察され又は見られてよい。例Ｏ１～Ｏ８及びこれらのセキュア通信技術の他の態様は、（例えば、ＦａａＳ又はＥａａＳ設定において開始された又は提供されたサービスのためのデータを通信するために）サービス動作及びサービス機能の結果としても観察され又は実装されてよい。更に、例Ｏ１～Ｏ８の方法は、実装された命令として（例えば、命令が実行されると方法を実行する機械可読媒体により）、又は実装されたハードウェア構成として（例えば、方法を実行し又は達成するための構成を含む機器により）、エッジコンピューティングシステム内で提供されてよい。従って、例Ｏ１～Ｏ８の特徴（及びセキュア通信の他の管理及び構成）は、システムオーケストレータ又は設計者により連携させられ又は設計されるとき、エッジクラスタ又はエッジクラウドシステムを構成するために、本願明細書に記載の他の例のうちのいずれかと結合されてよい。

【0805】

サイドチャネルリスクの最小化の例

【0806】

利害関係（conflict of interest）のあることが知られているテナントは、互いにサイドチャネル攻撃を行うリスクが高い可能性がある。１つの例示的な予防アプローチは、テナントを彼らの関心に従い分類し、次に衝突を発見するために分析を実行することである。環境をホスティングするテナントは、発見した衝突に基づき構造化されて、異なるノードにおいて高度に衝突するテナントを分離してよい（これは、例えば、従来のテナント隔離技術を追加で使用することを含んでよい）。

【0807】

エッジサービスは、テナントにサイドチャネル攻撃を行う機会をもたらし得るマルチテナントサポートのために利用可能であってよい。サービスのより高度な展開を使用することは、サービスクラスを定義することにより、サイドチャネル攻撃リスクを低減し得る。例えば、他のテナントと競合する理由がある、又は利害関係のあることが分かっているテナントは、異なるサービスクラスに保持される（例えば、異なるノードを使用する）。エッジコンピューティングシステム（例えば、エッジクラウド１１０、及び図３～２２Ｄに示したエッジコンピューティングシステム構成）で利用可能な一例では、オーケストレータ、サービスプロバイダ、及びサーバは、利害関係を有するテナントがエッジの同一場所に位置する可能性を回避するために、（例えば、通常のテナント隔離に加えて）サービスクラス境界に沿って区分されてよい。

【0808】

利害関係管理は、エッジ環境内で、作業負荷及びテナントに関するプライバシ保護情報を収集するサービスとして使用されてよく、次に利害関係セキュリティモデルに従いそれを評価する。衝突しているとして発見された作業負荷及びテナントは、衝突する作業負荷がより大きく隔離されたホスティングされるよう、オーケストレータに通知してよい。利害関係サービスは、テナントのプライバシ及び彼らの利益を保護するために、それ自体が信頼できる実行環境にホスティングされてよい。任意のネットワーク、プラットフォーム、又はこの目的のために収集された作業負荷（例えば、状態遷移）テレメトリも、プライバシ保護を受けてよく、信頼できる実行環境（trusted execution environment (TEE)）内から実行されてよい。

【0809】

サイドチャネル攻撃は容易に実装されず、チャネル（例えば、キャッシュ、メモリ、シグナリング方法、等）に不確定性を導入することにより非常に困難になり得るので、本願明細書に記載のインフラストラクチャは、パーティの不明な特性により衝突解析が可能でないとき、任意的に種々の摂動（perturbation）源を導入してよい。つまり、特定の理由で、衝突解析が決定的ではない場合、インフラストラクチャは、希であるが可能なサイドチャネル攻撃を実行するのを困難にするために、ランダムな摂動を導入してよい。更に、このような摂動は、アプリケーションの実行に影響しないことが分かっているリソースに追加されてよい。（例えば、メモリチャネル１が全く利用されていない場合、このチャネルは摂動のために使用されてよい。このようなチャネルの使用は、しかしながら、電力及び他のリソースの観点で、財政上又はリソースコストに対して検討されてよい。）

【0810】

エッジエコシステムは、利害関係を有するテナント又はステークホルダを含んでよい。オーケストレーションの部分としてエッジ／ＭＥＣリソースに渡る衝突解析を利用することにより、エッジは、不正な活動を含むシナリオを検出し得る（及び防ぎ得る）。更に、衝突解析は、どの他のテナントが脅威となる可能性が最も高いかを認識したいテナントに、サービス（ＣＡａａＳ）として、提供されてよく、従って市場ではより強力な軽減ソリューションであってよい。

【0811】

図４７は、サービスとしての衝突解析（Conflict－Analysis－as－a－Service (CAaaS)）プロバイダ４７０２を含むエッジシステム４７００の概略を示すシステム図を示す。利害関係のあることが知られているテナントは、互いにサイドチャネル攻撃を行うリスクが高い可能性がある。テナントの利益に従いテナントを分類し、次に可能な利害関係を識別するために分析を行うことは、利害関係サービスを実施するエッジアーキテクチャ内で使用されてよい。

【0812】

一例では、ＣＡａａＳサービスプロバイダ４７０２は、エッジオーケストレーション（例えば、オーケストレータ４７０４）に、エッジノード４７１１、４７１２内のこれらのテナントインスタンス４７０８、４７１０、４７１４、４７１６の中で、テナント衝突の影響を受けやすいより高度な作業負荷スケジューリング割当を行うよう通知してよい。環境をホスティングするテナントは、通常、テナント隔離能力を有することが期待される。例えば、オーケストレータは、どのテナント隔離技術（例えば、ＳＧＸ、仮想化、ＴｒｕｓｔＺｏｎｅ、ＦＰＧＡ、等）が利用可能であるかを報告するエッジノード証明を要求してよい。しかしながら、これらのテナントは、依然として多くのリソース（例えば、ＣＰＵコア、キャッシュ、ＰＣＩｅバス、等）を共有する。高度に利害関係を有すると分かったテナントは、サイドチャネルの功績の可能性を最小化するために更なる隔離を要求してよい。例えば、オーケストレータは、（例えば、ローカライズされたテナント隔離技術を適用することに加えて）物理的に異なるエッジノード上で実行するよう、衝突するテナントをスケジューリングしてよい。図４７で、テナントＴ１ ４７１０及びテナントＴ３ ４７１４は、高い利害関係を有するが、テナントＴ１ ４７１０及びテナントＴ２ ４７０８は、低い利害関係を有する。Ｔ１ ４７１０及びＴ３ ４７１４の作業負荷は、異なるエッジノード上で実行するようスケジューリングされるが、Ｔ１ ４７１０及びＴ２ ４７０８の作業負荷はローカルにスケジューリングされてよい。

【0813】

一例では、コレクタとＣＡａａＳサービスプロバイダとの間に「プライバシフィルタ」が実装されてよい。一例では、実際のテレメトリデータは、送信されないが、代わりに外部的に観察可能な作業負荷の動作傾向が送信される。テナントコンテナは、ＶＭ、プロセス、作業負荷画像、等を含んでよい。ＣＡａａＳはテナントにプライバシを提供してよい。例えば、データは、任意的に利害関係マップを除いて、ＣＡａａＳの外部に公開されない。これは、追加の詳細を有しないで、制限（例えば、Ｔ１ ４７１０はＴ３ ４７１４と一緒にノード上にない）のみを含んでよい。

【0814】

一例では、ＣＡａａＳは、テナント作業負荷により保護されないネットワークメタデータに関して提供されてよい（例えば、ＩＰヘッダ、ＩＰ ＱｏＳ、トンネル／ＴＬＳ交渉パラメータ、等）。

【0815】

更なる例では、テレメトリコレクタ４７０６は、セキュリティ又はプライバシポリシに従いテレメトリフィルタを調整するＬＳＭ実施点であってよい。ＬＳＭポリシは、テナント固有、ドメイン固有、又はエッジインフラストラクチャ固有であり得る。同様に、図４７のコンテキストでは、オーケストレータ４７０４は、ＬＳＭポリシ／ユーザレベル合意を交渉してよく、テレメトリコレクタ及びテナントホスティング環境のような他の実施点に従いＬＳＭをプロビジョニングしてよい。

【0816】

図４８は、ＣＡａａＳプロバイダコンポーネントを示すシステム４８００を示す。ＣＡａａＳプロバイダ４８１０は、利害関係実行マップに基づき壁（wall）を構築する幾つかの動作を実行する。これらのマップは、また、４８３０のようなオーケストレータにより使用される。オーケストレータは、それらを作業負荷スケジューリング処理（例えば、関連コード、ロジック、又はアルゴリズムを実装する）に適用する。ＣＡａａＳプロバイダ４８１０のコンポーネントは、以下に説明するコンポーネントを含んでよい。

【0817】

機械学習パターン認識エンジン４８１２は、テレメトリ収集コンセントレータ（concentrator）から未加工テレメトリを集める。パターン認識エンジン４８１２は、トレーニングされた機械学習分類器を用いて未加工テレメトリを分析して、潜在的な利害関係実行インテリジェンスアーチファクトを識別する。アーチファクトは、エンティティ主体（entity principal）（例えば、ユーザ、ユーザの接続ネットワークの中にいる人々、組織、グループ、市民、ユーザに関連付けられた連合又は民間企業）又はエンティティ特性（例えば、データ、コンテキスト、トランザクション、メタデータ、又は主体を接続するために使用される他の情報）任意の種類の情報を含んでよい。ＭＬ又はＤＬ分類器は、主体と特性との間の関係を示す関心パターンを生成する。

【0818】

例えば、（例えば、企業連合により識別されるような）６個の主体が与えられた場合：会社Ａ～会社Ｆ、及び５個の特性、例えば特定分野の会社、訴訟歴のある会社、指定数より多くの従業員を有する会社、等、主体を特性にリンクする関係が、マトリクスにより表現されてよい。

【数1】

【0819】

ここで、（＋）は賛成関連付けを表し、（－）は敵対関連付けを表し、（０）は中立関連付けを表す。関連付け及び関係の変形又はレベルを表す他のスケーリングされた値又は数値も追跡されてよい。

【0820】

エッジノードの配置についての追加分析は、テナント起源（origin）又は実際のエッジの場所が基本的にどこに配置されるかに基づき適用されてよい法令の種類を含んでよい。例えば、２種類の検討は以下を含む：

【0821】

（１）プラットフォームの物理的位置。パターン認識エンジン４８１２は、現在の国において適用される可能性のあるルールを識別するために、ジオロケーション（geolocation）を使用してよい。一例では、エッジノードは移動していてよい。

【0822】

（２）サービスを実行しているテナントの起源。同様に、エッジの場所に、テナントは、彼の位置に関わらずテナントに付随し得る国のような場所に基づくポリシを有してよい。

【0823】

一例では、（１）及び（２）により課され得るルールは、パターン認識エンジン４８１２により分析されるパートナーにも依存してよい。例えば、プライバシ又はセキュリティポリシは、特定のバスが複数のテナントにより共有される場合にのみ適用してよい。

【0824】

関心パターンは、衝突解析エンジン４８１６（ＣＡＥ）により使用されてよい。ＣＡＥは、特にＬＳＭが利害関係ポリシを提供する場合にＬＳＭ実施点であり得る。

【0825】

別のシステムコンポーネントは、サービスレベル合意（service level agreement (SLA)）分析エンジン４８１４（ＳＡＥ）である。ＳＡＥは、場合によってはオーケストレータによりＣＡａａＳプロバイダを使用してスケジューリングされたそれぞれのテナントからＳＬＡ入力（例えば、ユーザインテリジェンス４８２２からのユーザコンテキスト）を受け付ける。ＳＡＥは、ＳＡＥが相互関連付けされ得る主体及び特性を探してＳＬＡをスキャンし得るという点で、パターン認識エンジン４８１２と同様の機能を実行する。ＳＡＥは、ＳＬＡ構造をパースし及び作業負荷処理の意味を理解できるので、ＭＬ又はＤＬ分類器を使用する必要がなくてよい。別の例では、ＳＡＥは、プライバシを考慮するために、実際の作業負荷データ及びアルゴリズム内容に精通していなくてよい。ＣＡａａＳシステムは、より正確な関心パターンを構築するために作業負荷画像をより深く分析させるよう、テナントに動機を与えてよい。ＳＡＥは、作業負荷分析のためにＭＬ又はＤＬ分類器を利用してよい。関心パターンは、更なる処理のためにＣＡＥへ配信される。

【0826】

ＳＡＥが相関又は分類を向上させるために使用し得るある態様は、作業負荷自体により利用されるリソースに固有の異なる特性を相関させることである。異なるＣＰＵ及びプラットフォームリソースは、SAEにより分類又はデータフィルタリングを向上するために使用される異なるレベルの隔離又はセキュリティ特性を有してよい。分類は、以下を含んでよい。

【0827】

（１）プラットフォームセキュリティ及びマルチテナント暗号化。これは、衝突の可能性を完全に除去し得るセキュアエンクレーブ又はメモリ暗号化のような特徴を含んでよい。他の例では、ＳＡＥは、システムに衝突のないこと（又は限られた衝突しかないこと）を保証するために、これらの特徴のうちのどれが、特定の作業負荷により実際に利用されるかを検証しなければならい。

【0828】

（２）リソース隔離は、利害関係マッピングを変更してよい。リソース隔離では、異なるリソース又はプラットフォーム特徴は、特定のＳＬＡの見方（perspective）を変えてよい。例えば、ＳＡＥは、リソースがテナント毎にパーティションされたハードウェアであるか否か、それらが複数のテナントに渡り共有される予定がないか否か、を調べてよい。

【0829】

一例では、分析（１）及び（２）の目標は、ＳＬＡが壊され（broken）得るか又はプラットフォーム又はＣＰＵ特徴の異なる結合のために向上され得るかを知ることである。

【0830】

一例では、コンポーネントは、作業負荷レピューテーションプロバイダ４８２０を含んでよい。作業負荷が分散され、それらそれぞれのサブコンポーネントの間で更に通信されると、かなりの量の追加情報がそれらのＩ／Ｏ動作を観察することにより学習できる。例えば、制御、データ、及び管理プレーンのために複数のＦａａＳを伴うｖＰＧＷのようなネットワーキング作業負荷、及び該ＦａａＳ間の相互通信は、全体的な機能を提供する。一例では、ネットワークサービスプロバイダ又はＩＳＶは、プロバイダ４８２０において（例えば、非プライベートデータに基づき）作業負荷レピューテーションプロファイルのデータベースを展開してよい。このようなデータは、今日、マーケットインテリジェンス、製品の価格付け、雇用、等の複数の商業目的で益々使用されている。一例では、作業負荷レピューテーションに関する同様の情報は、一層決定的な及び効果的な結果を支援するために、ＣＡａａＳプロバイダ４８１０への入力として使用されてよい。

【0831】

追加のシステムコンポーネントは、衝突解析エンジン４８１６（ＣＡＥ）を含む。ＣＡＥ４８１６は、衝突関係を更に向上させる必要のあるとき、「ファジー」関心パターンに重みを適用する。ビジネス指向型衝突関係は、ビジネス上の競合他社が比例する利害関係を有すると決定してよい。例えば、以下のチャートは、５個の店舗及び４つのビジネスラインを対応する市場シェア情報と共に示す。他の例では、これらは、任意の規定の定義されたパラメータ（欧州連合（ＥＵ）ＧＤＰＲ（General Data Protection Regulation）のような地理的に特有の規定）、相互に不信感を抱く組織（例えば、銀行、カジノ、監査事務所、等）、知られている衝突、等であってよい。

【数2】

【0832】

重み付け係数が適用されてよく、その結果、衝突はビジネスラインに固有であるが、ビジネス間の関係の観点で表現される。

【数3】

【0833】

衝突関係は、利害関係がいつ重要であると考えられるかの閾値を適用することにより、２値関係に変換されてよい。例えば、４０％市場シェア閾値が選択された場合、ｅｓｈｏｐ１及び３ｓｈｏｐ３のみが、重要な利害関係を有すると認識され得る。衝突関係結果は、隔離ポリシモジュール４８１８（ＩＰＭ）へ入力されてよいＣＩ関係マップとして知られ得る。

【0834】

ＩＰＭコンポーネントは、実施マップと呼ばれる隔離実施ポリシ（例えば、「チャイニーズウォール（Chinese wall）」実施ポリシ）を通知するために、ＣＩマップと共に使用されてよい。実施マップは、原則（Ｐ）のセット、オブジェクト（Ｏ）のセット、ＰをＯに関連付けるマトリクスＮ、及びＲにより示されるアクセスレベルであってＲ（Ｐｉ，Ｏｊ）が許可されたアクセス権であるアクセスレベル、に関連する４タプルを含んでよい。例えば、アクセスは、ＲＥＳＴｆｕｌ ＡＰＩアクセス（生成、読み出し、更新、削除、通知）、又はファイルアクセス許可（読み出し、書き込み、実行）の観点で記述されてよい。更に、アクセスは、ゾーン（Zone）０が隔離の必要ないことを意味する同一位置（co－location）ゾーンの観点で記述されてよい。ゾーン１は、処理隔離が必要であることを意味し、ゾーン２は、仮想マシンを意味し、ゾーン３は、セキュアエンクレーブを意味し（例えば、Intel（登録商標）SGXセキュアエンクレーブにより提供されるような）、及びゾーン４は物理的隔離を意味する。実施マップは、オーケストレータ４８３０又はテナント隔離及びアクセスを実施するタスクを有するエッジエコシステムの中の他のエンティティへ配信される。

【0835】

例えば、アクセスマップは、作業負荷を処理し得る複数のサーバに渡り使用され得るアクセストークンを生成するＯＡｕｔｈサーバに与えられてよい。アクセストークンは、原理の表現、及びそれらそれぞれのアクセス権又は隔離ゾーン（又はこれらの組み合わせ）を含んでよい。一例では、ＯＡｕｔｈトークンは、ＯＡｕｔｈサーバに対して認証された原理のアイデンティティを含む。アイデンティティは、リソースサーバにより、該サーバにおける原理に対して適切なレベルのアクセスを含むローカルアクセス制御ポリシを調べるために使用される。ＩＰＭは、オーケストレータ指針情報を含むよう、ＯＡｕｔｈトークンの意味（semantics）を変更してよい。ＩＰＭは、原理がＯＡｕｔｈトークンを認証し及び取得するとき、ＯＡｕｔｈサーバに提供されてよい。原理は、次に、作業負荷及びＯＡｕｔｈトークンを供給するオーケストレータサービスを要求してよい。オーケストレータは、ＩＰＭコンテンツを見付けるために、トークンをパースする。

【0836】

第２の原理は、第１の原理と同様の動作セットを実行する。オーケストレータは、ＩＰＭポリシが利害関係を明らかにするとき、原理Ｐ１及び原理Ｐ２について、ＩＰＭポリシを観察する。オーケストレータは、それぞれのサービスホスト上でそれらを適切にスケジューリングする。トークンは、ホスティングサービスへ作業負荷と共に転送されてよい。ホスティングサービスは、ホストサーバに関連付けられたリソースの追加アクセス制御権（例えば、ｒ－ｗ－ｘ）を含んでよい。

【0837】

更なる例では、サイドチャネルリスクを最小化するための方法は、テナント間（例えば、ノード上に又はノード若しくは装置２２００、２２３２、２２４０、又は２２５０により実装されるテナントインスタンス）の利害関係を解決する技術を実施してよい。技術は、サービスとしての衝突解析（ＣＡａａＳ）を実行するプロセッサにおいて、テレメトリコレクタから、複数のエッジノードのテレメトリ情報を受信する第１動作を含む。一例では、テレメトリ情報は、プライベート情報を有しない、外部観察可能な作業負荷動作の傾向を含む。

【0838】

技術は、ＣＡａａＳを実行するプロセッサを用いて、テレメトリ情報を用いてアクセスマップを生成する第２動作を含む。アクセスマップの生成は、ユーザデータからの関心パターン、テレメトリ情報、及びテナントのレピューテーションデータを比較して、マップを生成するために、プロセッサを使用して衝突解析エンジンを実装してよい。

【0839】

一例では、アクセスマップは、サービスレベル合意（service－level agreement (SLA)）の特性のようなユーザコンテキストに基づき生成される。別の例では、アクセスマップは、テレメトリ情報を入力として使用する機械学習パターン認識エンジンからの出力に基づき生成される。アクセスマップは、複数の衝突レベル、及び関連する隔離要件を含んでよい。アクセスマップは、ＲＥＳＴｆｕｌ ＡＰＩアクセス、ファイルアクセス許可、又はバイナリアクセスのうちの少なくとも１つについての権利制限を含んでよい。アクセスマップは、隔離無し、プロセス隔離、仮想マシン、エンクレーブ、又は物理的隔離、のうちの少なくとも１つを含む隔離レベルを含んでよい。

【0840】

技術は、アクセスマップに従い複数のエッジノードの間でテナントを割り当てるために、アクセスマップをオーケストレータに提供する第３動作を含む。一例では、オーケストレータは、複数のエッジノードのうちの物理的に異なるエッジノード上で実行するよう衝突するテナントをスケジューリングするよう構成される。

【0841】

第１の例示的な方法（例Ｐ１）であって、エッジコンピューティングシステム（例えば、図７～１２に関連して示され及び説明されたエッジサービス及び機能の中でも、特にエッジクラウド１１０）におけるサイドチャネルリスクを最小化するシステム構成を実施し、処理回路（例えば、ノード又は装置２２００、２２３２、２２４０、又は２２５０上で又はそれにより実装される）を用いて実行され、当該方法は、
サービスとしての衝突解析（ＣＡａａＳ）を実行するプロセッサにおいて、テレメトリコレクタから、複数のエッジノードのテレメトリ情報を受信するステップと、
ＣＡａａＳを実行するプロセッサを用いて、テレメトリ情報を用いてアクセスマップを生成するステップと、
アクセスマップに従い複数のエッジノードの間でテナントを割り当てるために、アクセスマップをオーケストレータに提供するステップと、を含む。

【0842】

第２の例（例Ｐ２）では、例１の主題は、アクセスマップが、サービスレベル合意（ＳＬＡ）の中で定義された特性を含むユーザコンテキストに基づき生成される構成を含む。

【0843】

第３の例（例Ｐ３）では、例Ｐ１～Ｐ２の主題は、アクセスマップが、テレメトリ情報を入力として使用する機械学習パターン認識エンジンからの出力に基づき生成される構成を含む。

【0844】

第４の例（例Ｐ４）では、例Ｐ１～Ｐ３の主題は、プロセッサが、衝突解析エンジンに、ユーザデータからの関心パターン、テレメトリ情報、及びテナントのレピューテーションデータを比較して、マップを生成するために、衝突解析エンジンを実装するプロセッサを含む。

【0845】

第５の例（例Ｐ５）では、例Ｐ１～Ｐ４の主題は、オーケストレータが、複数のエッジノードのうちの物理的に異なるエッジノード上で実行するよう衝突するテナントをスケジューリングするよう構成されることを含む。

【0846】

第６の例（例Ｐ６）では、例Ｐ１～Ｐ５の主題は、アクセスマップが複数レベルの衝突及び関連付けられたかくりようけんを含む構成を含む。

【0847】

第７の例（例Ｐ６）では、例Ｐ１～Ｐ６の主題は、テレメトリ情報が外部から観察可能な作業負荷動作がプライベート情報を有しない傾向であることを含む。

【0848】

第８の例（例Ｐ８）では、例Ｐ１～Ｐ７の主題は、アクセスマップがＲＥＳＴｆｕｌ ＡＰＩアクセス、ファイルアクセス許可、又はバイナリアクセスのうちの少なくとも１つの権利制限を含む構成を含む。

【0849】

第８の例（例Ｐ９）では、例Ｐ１～Ｐ８の主題は、アクセスマップが隔離無し、プロセス隔離、仮想マシン、エンクレーブ、又は物理的隔離のうちの少なくとも１つを含む隔離レベルを含む構成を含む。

【0850】

種々の設定で、例Ｐ１～Ｐ９（及び衝突解析及びオーケストレーションアクセス管理の他の態様）は、通信プロトコル、メッセージフォーマット若しくは定義の使用及び監視；オーケストレーション構成；及びエッジコンピューティング環境の中でのアクセス制御、隔離、及び信頼メカニズムのポリシ及びロジックの他の使用及び実装；の結果として観察され又は監視されてよい。例Ｍ１～Ｍ９及びアクセス管理技術の他の態様は、（例えば、ＦａａＳ又はＥａａＳ設定においてセキュリティ隔離及びポリシを実施するために）サービス動作及びサービス機能の結果としても観察され又は実装されてよい。更に、例Ｐ１～Ｐ９の方法は、実装された命令として（例えば、命令が実行されると方法を実行する機械可読媒体により）、又は実装されたハードウェア構成として（例えば、方法を実行し又は達成するための構成を含む機器により）、エッジコンピューティングシステム内で提供されてよい。従って、例Ｐ１～Ｐ９の特徴（及び衝突解析及びセキュリティポリシ実装の他の特徴）は、システムオーケストレータ又は設計者により連携させられ又は設計されるとき、エッジクラスタ又はエッジクラウドシステムを構成するために、本願明細書に記載の他の例のうちのいずれかと結合されてよい。

【0851】

暗示的証明の例

【0852】

サービスレベル合意（ＳＬＡ）又はテナントＳＬＡのような性能合意は、時に、サービスがどのようにサポートされるか又はテナント（例えば、加入者）データがどのように保護されるかに関する、法的または経済的影響を含み得る要件が生成される前提を含む。マルチステークホルダエッジ環境（例えば、エッジクラウド１１０、及び図３～２２Ｄに示されるエッジコンピューティングシステム構成）は、幾つかの、最終的に遠隔に関連付けられる、関心パーティを有してよい。暗示的証明は、エッジステークホルダにより、これら及び他の関連サービスプロバイダに対してＳＬＡ項目を証明するために使用されてよい。

【0853】

暗示的証明は、以下の例では、装置識別子合成エンジン（Device Identifier Composition Engine (DICE)）アーキテクチャを使用して達成されてよい。ここで、例えば、証明プロファイルの中にＳＬＡ項目を含む作業負荷固有署名鍵が導出されてよい。ＤＩＣＥ署名鍵導出は、特に、エッジ展開を能力においてもマルチテナントホスティングにおいてもスケーリング可能にするのに有用であってよい。ＳＬＡ毎のサービス完了の第三者検証可能証明は、課金、ネットワーク監視、サービス品質（ＱｏＳ）評価、等のようなこれらのマルチパーティ相互作用において重要な要素になり得る。

【0854】

ＳＬＡプロファイルによる暗示的証明を実施するために、作業負荷は、信頼されるコンピューティング基盤（trusted computing base (TCB)）又は他の信頼できるコンピューティングハードウェア構成上に実装され得る、テナントエンクレーブ、コンテナ、又は他のテナント隔離環境において実行されてよい。ホスティング環境は、作業負荷固有証明鍵を導出してよい。この導出の部分は、混合装置アイデンティティ（compound device identity (CDI)）の計算を含む。一例では、ＣＤＩ計算は、ＳＬＡから取り出した期待信頼性パラメータを含む。例えば、エッジコンソーシアム及びテスト設備は、セキュリティ、安全性、又はプライバシ保護能力についてホスティングプラットフォームを検査し、該検査に基づき準拠表明（compliance statement）を発行してよい。ＳＬＡは、作業負荷実行の部分として、指定された準拠レベル、又は準拠レベルが証明又は検証を要求することを要求してよい。作業負荷がテナント環境で実行するとき、テナント環境は、ルートオブトラスト（root－of－trust (RoT)）又はＴＣＢ層から作業負荷固有証明鍵を要求してよい。ＲｏＴ又はＴＣＢは、次の層ｎのために鍵を計算する。ここで、ｎは、作業負荷をホスティングするテナント環境を識別する。一例では、層ｎのＣＤＩは、現在のＴＣＢコンテキスト（current TCB context (CTC)）を、ＳＬＡにより識別された遵守証明書（compliance certificate）によりハッシングすることにより計算される。証明鍵は、作業負荷結果（及び、場合によっては実行からのテレメトリ）に署名するために使用される。それにより、作業負荷実行の遵守状態を暗示的に証明する。

【0855】

図４９は、ＤＩＣＥ層４９０１、４９０２、４９０３、４９０４に関して、ＣＤＩ計算４９００の一例を示す。図示のように、層のＣＴＣ４９１１、４９１２、４９１３、４９１４は、証明層により計算され、ＣＤＩ４９２１、４９２２、４９２３として返される。これは、図５０の示す、非対称鍵５０１２、５０１３、５０１４が各層によりＣＴＣ４９１１、４９１２、４９１３、４９１４について計算される計算５０００と対照的である。図５０では、ＣＴＣの層に跨がる検証は存在しない。

【0856】

図５１は、作業負荷固有証明鍵を生成するためにＤＩＣＥ層を用いてＳＬＡパラメータの暗示的証明を使用しているエッジコンピューティングエンティティ５１１０（例えば、コンソール５１０１、コアサーバ５１０２、オーケストレータ５１０３、基地局５１０４、テナント５１０５）を通じるデータフロー５１００を示す。図５１では、特定のデータフロー動作が示されるが、動作の他の変形及びシーケンスがこの枠組みの中で使用されてよいことが理解される。一例では、コアサーバ５１０２又は基地局５１０４は、汎用プロセッサ又は他のシステムオンチップ（ＳｏＣ）コンポーネントを含んでよい。一例では、これらのエンティティは、アクセラレータハードウェアも含んでよい。一例では、アクセラレータは、プラットフォーム（例えば、ＳｏＣ、マザーボード、等）に直接インストールされ、又はプラットフォームバスを介してアクセス可能である（例えば、暗号化のためのＰＣＩｅ（peripheral component interconnect express）カード、ＡＩ、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）等に追加する）。

【0857】

図５１の状況では、ＤＩＣＥ鍵５１１２は、ＬＳＭ実施点を提供してよい。ＤＩＣＥ鍵生成は、ＬＳＭコンテキストを含み得ので、ＬＳＭ固有鍵のみが存在する。ＬＳＭが変更された場合、ノードは、ＬＳＭ固有鍵を期待している他のノードに参加できなくなる。更に、オーケストレータ（例えば、オーケストレータ５１０３）は、証明検証者に証明ＬＳＭをプロビジョニングでき、証明検証者はＤＩＣＥ－ＬＳＭ鍵又は他の鍵に結び付けられるかにかかわらず、ＬＳＭ実施点として動作する。例えば、ＬＳＭは、許容可能な又は許容できない証明値を記述できる。

【0858】

幾つかのシナリオでは、ＳＬＡの固有属性は秘密又は不明瞭にされてよい。ＳＬＡ値が作業負荷自体により開示されない場合、作業負荷は、自身が例えば３０ギガビット（Ｇｂｐｓ）の入力－出力（Ｉ／Ｏ）イーサネット帯域幅のＳＬＡを有することを開示すべきではない。このようなシナリオでは、署名付きＳＬＡは、記録済みＳＬＡは、に関して正規化された値を提供してよい。例えば、正規化値は、ＳＬＡが満たされたという決定をもたらすメトリック又は指標を報告するのではなく、ＳＬＡが満たされたことを示すだけである。一例では、正規化値は、メトリックを開示しない方法で、メトリックを示してよい。従って、例えば、正規化値は、ＳＬＡが１１０％（例えば、３５Ｇｂｐｓ）又は９０％（例えば、２８Ｇｂｐｓ）だけ満たされることを示すような、ＳＬＡ値のパーセントであってよい。

【0859】

テナント作業負荷が１つ以上のアクセラレータスライス、仮想機能、又は物理機能と共に計算コア上で実行している展開シナリオでは、作業負荷固有証明鍵の導出は、アクセラレータ又は機能の固有ＳＬＡパラメータを含んでよい。例えば、スマートネットワークインタフェース制御部（smart network interface controller (SmartNIC)）では、ＳＬＡパラメータは、提供されるスループット、仮想キューの数、セキュリティ関連付けの数、等を含んでよい。人工知能（artificial intelligence (AI)）アクセラレータでは、ＳＬＡパラメータは、特に、モデル記憶サイズ、実行ユニット、又は専用実行時間メモリを含んでよい。このような場合には、ＣＤＩは、アクセラレータ固有パラメータを用いて導出されてよい。

【0860】

本願明細書に記載の暗示的証明は、特に、広範な使用例に渡り共通である又は適用されるＳＬＡパラメータにとって有用であってよい。この有用性は、パラメータに対する任意の変化が証明鍵を無効にするので、装置又はサービスの再展開又は再オンボーディングの要求をもたらす。従って、コンポーネントサービスプロバイダ（component service provider (CSP)）がオペレータにセキュリティプロトコル（例えば、Cerberus）を実行するよう要求する場合、攻撃者が、ＳＬＡ要件を全部達成しながら、プラットフォームを変更することなくＤＩＣＥ鍵を破壊できない限り、テナント環境へのアクセスは拒否されるだろう。

【0861】

また更なる例では、暗示的証明の例は、異なるドメイン又は種類の信頼のために、又は異なるレベルの要求される信頼のために、適用されてよい。結果として、証明の多くのシナリオが、データ又は派生する特性のために適用されてよい。

【0862】

第１の例示的な方法（例Ｑ１）は、（例えば、エッジクラウド１１０内の、及び実装システム及び装置の間で）エッジノードの暗示的証明を実施し、方法は、処理回路（例えば、ノード又は装置２２００、２２３２、２２４０、又は２２５０上に又はそれにより実装される）を用いて実行され、方法は、サービスレベル合意（service level agreement (SLA)）パラメータにより定義されるテナント作業負荷環境の実行コンテキストを取得するステップと、
実行コンテキストの証明鍵を取得するステップと、
テナント作業負荷環境及び証明鍵を用いてコンポーネント装置アイデンティティ（component device identity (CDI)）を計算するステップと、
テナント作業負荷環境の中で作業負荷を実行して、結果を生成するステップであって、該結果はＳＬＡパラメータの性能メトリックを含む、ステップと、
ＣＤＩにより結果に署名するステップと、
署名付き結果を作業負荷の要求者へ送信するステップと、を含む。

【0863】

第２の例（例Ｑ２）では、例Ｑ１の主題は、ＣＤＩが作業負荷を実行する層と異なる層で計算されることを含む。

【0864】

第３の例（例Ｑ３）では、例Ｑ１～Ｑ２の主題は、ＳＬＡパラメータが受信者により見分けられるのを防ぐために、性能メトリックが正規化されることを含む。

【0865】

第４の例（例Ｑ４）では、例Ｑ１～Ｑ３の主題は、テナント作業負荷環境が信頼されるコンピューティング基盤（trusted computing base (TCB)）である構成を含む。

【0866】

種々の設定で、例Ｑ１～Ｑ４（及び暗示的証明及び実行管理の他の態様）は、定義されたアプリケーションプログラミングインタフェース、又はインタフェース仕様；特定のエッジコンピューティング環境及び作業負荷、エッジコンピューティング環境内の暗示的証明のためのポリシ及びロジックの他の使用及び実装、の結果として観察され又は見られてよい。例Ｑ１～Ｑ４及び暗示的証明及び実行管理の他の態様は、（例えば、ＦａａＳ又はＥａａＳ設定におけるサービスの証明又は管理を提供するために）サービス動作及びサービス機能の協調の結果としても観察され又は実装されてよい。更に、例Ｑ１～Ｑ４の方法は、実装された命令として（例えば、命令が実行されると方法を実行する機械可読媒体により）、又は実装されたハードウェア構成として（例えば、方法を実行し又は達成するための構成を含む機器により）、エッジコンピューティングシステム内で提供されてよい。従って、例Ｑ１～Ｑ４の特徴（及び証明及び実行管理の他の特徴）は、システムオーケストレータ又は設計者により連携させられ又は設計されるとき、エッジクラスタ又はエッジクラウドシステムを構成するために、本願明細書に記載の他の例のうちのいずれかと結合されてよい。

【0867】

証明エッジネームサービスの例

【0868】

エッジクラウドインフラストラクチャは、全世界に渡り証明データをスケーリングするために使用されてよい。証明の従前のアプローチは、ソフトウェアソリューション及び種々のソフトウェアスタックにより開示される発見メカニズムに基づいていた。これらの従前のアプローチに伴う１つの制限は、低待ち時間の発見及びリソース選択メカニズムが必要なとき、何らかの加速又はインフラストラクチャ加速方式が必要であることである。以下の技術は、エッジコンピューティングシステム（例えば、エッジクラウド１１０、及び図３～２２Ｄに示したエッジコンピューティングシステム構成）に適用可能であり、リソースを発見するため又はＳＬＡを提供するために、名前に基づくアクセス（name－based access）を提供する。これらのリソースまたはＳＬＡは、アーキテクチャのレベルに変化が生じたときに、コールバックを受信するために、階層構造ドメインの各々に記録されてよい。それぞれのティア（tier）又はリソース特性は、例えば、ブロックチェーンを用いてエッジのグループにより保証されてよい。

【0869】

各証明は、エッジアーキテクチャの中でサービス展開を発見し信頼する最適な方法を決定するために使用される。エッジ証明ネームサービス（Edge Attestation Name Service (EANS)）技術は、数千ものサービスプロバイダ及び従属リソースがどこに位置するか（例えば、トポロジ的に、地理的に、又は辞書的順序で、例えばＩＣＮ）の全体的概観を構築するために使用されてよい。位置情報は、期待されるアクセス待ち時間を予測するのを助けるために使用されてよい。種々の例では、それぞれのサービスは、エッジの異なるエンティティがどのように信頼の値を検証する又は各サービスに提供するかに依存して、異なるレベルの証明又は信頼に関連付けられてよい。更に、このようなサービスは、サービスに証明のレベルを提供するためにグローバルに信頼されるエンティティに関連付けられてよい。

【0870】

以下の技術は、ドメインネームサービス（Domain Name Service (DNS)）に類似するがエッジアーキテクチャに適用されるよう構成される記録サービスを提供する。例えば、分散型台帳のセットは、それぞれの分散型台帳の中で監視及び証明ソフトウェア要素を展開することを担う。これらの監視要素は、例えば特定のサービスが実行されるとき、サービスを追跡するために使用されてよい。

【0871】

図５２は、エッジ証明ネームサービス（Edge Attestation Name Service (EANS)）アーキテクチャ５２００を提供するシステムを示す。図５２に示されるＥＡＮＳアーキテクチャ５２００は、例示的なノード５２２０、レベル５２２２、５２３４、接続５２４０、及び集約点５５２５２，５２５４、５２５６を有するが、ＥＡＮＳは、他のアーキテクチャ、設定、又はコンポーネント（ノード３０２、３１２、３２２、及び図３～２２Ｄに示したシステム構成から議論された他のシステム実装を含む）と共に使用されてもよい。

【0872】

ＥＡＮＳアーキテクチャ５２００は、ノード、ＥＡＮＳプロバイダ、装置、等を記述してよい。例えば、マスタＥＡＮＳノードは、下位のＥＡＮＳノードの信頼を検証（vetting）するための開始点であってよい。この階層構造は、ＥＡＮＳシステムの動的又は弾力的な展開をサポートするために使用されてよい。

【0873】

ＥＡＮＳは、エッジアクセスネットワークまたはエッジコアネットワークを介してアクセス可能なハードウェア又はソフトウェア計算リソースを監視し及び証明するために、分散型台帳サービスのセットを提供してよい。ＥＡＮＳプロバイダは、エッジネットワーク内で実行する各サービスを追跡することを担ってよい。追跡される情報は、個々の計算リソースの又は計算リソースの特定のセット、計算リソースに展開された又はその上で実行しているファームウェア又はソフトウェア、特定のＳＬＡセットによる作業負荷又はそれらの位置、テナント（例えば、加入者）識別子（例えば、認証するために使用される暗号鍵）又はそれらの位置、被追跡リソースに属する固有の信頼属性、他のポリシ制限、等を含んでよい。

【0874】

ＥＡＮＳ監視要素は、階層構造情報システムへの被監視情報の保証及び伝搬を担ってよい。例えば、階層構造に組織化されたシステムは、エッジアーキテクチャのノース－サウス階層構造に従う。一例では、エッジシステムアーキテクチャで何かを実行したい装置又はエッジシステム（例えば、プラットフォーム５２１０）は、特定の環境下で特定のサービスプロバイダにより提供されてよい特定のサービスについて特定のクエリを生成し、任意的に、エッジシステム全体により証明される実際の期待性能及びサービス品質を検証してよい。特定のクエリは、ＥＡＮＳアドレス又は名称を含んでよい。

【0875】

一例では、ＥＡＮＳアーキテクチャ５２００は、ディレクトリインフラストラクチャ型の情報だけでなく、より多くの情報を含んでよい（例えば、情報は証明可能なクレームも含んでよい）。例えば、ＥＡＮＳアーキテクチャ５２００は、テレメトリ、リソース、ＩＰアドレス、等のようなデータを含んでよい。この情報はクエリに応答して渡されてよく、又は、選択された情報は、例えばクエリのパラメータに従い渡されてよい。

【0876】

一例では、仮想ドメインは、例えば階層構造の中で動的に生成されてよい。別の例では、仮想ドメインは、図５２に示す階層構造以外の異なるトポロジを使用してよい。仮想ドメインは、ドメインにおいて変更された任意のリソースデータ（例えば、新しいリソース、状態の変化、等）を証明し又は検証することを担う信頼されるエンティティのセットを含んでよい。新しいデータが証明されると、データは、現在のドメインへの加入の場合にピアへのコールバックを実行することを担うマスタＥＡＮＳに伝搬されてよい。別の例では、マスタＥＡＮＳは、メタデータのローカルレポジトリを更新してよい。

【0877】

一例では、レポジトリに含まれるデータ又は属性は、証明されたデータであってよい。別の例では、データは、正しいことが知られていてよく、その有効性及び関連を決定するために証明されたデータと比較されてよい。

【0878】

ＥＡＮＳアーキテクチャサポートのための更なる技術は、以下の動作を含んでよい。技術は、例えば、マスタエッジ装置において、装置から、エッジアーキテクチャの中のサービスに関する情報についてのクエリを受信する第１動作を含む。技術は、クエリに応答して、レポジトリ内のエッジ証明ネームサービス（Edge Attestation Name Services (EANS)）データに（例えば、マスタエッジ装置において）アクセスする第２動作を含む。

【0879】

技術は、例えば、マスタエッジ装置から装置へ、クエリに対する応答を送信する第３動作を含む。該応答は、サービスの証明データ、及びサービスを提供するエッジ装置のアドレス若しくは名称のうちの少なくとも１つを含む。応答は、サービスの被監視情報の証明書又は伝搬を含んでよい。応答は、（例えば、待ち時間について）サービスを提供するエッジ装置の位置情報を含んでよい。位置情報は、アドレスを含んでよく、又は追加情報（例えば、最短経路時間）を含んでよい。一例では、証明データは、マスタエッジ装置において、レポジトリに格納される。

【0880】

一例では、装置及びマスタエッジ装置は、エッジアーキテクチャ内のレベルを共有する。一例では、サービスを提供するエッジ装置は、エッジアーキテクチャ内のマスタエッジ装置と異なる仮想ドメインの中にある。本例では、動作は、エッジアーキテクチャのより低いレベルにある第２マスタエッジ装置を識別するステップを含んでよい。技術は、第２マスタエッジ装置から、サービスの証明データ、及びアドレス若しくは名称のうちの少なくとも１つを受信するステップを更に含んでよい。

【0881】

第１の例示的な方法（例Ｒ１）は、（例えば、エッジクラウド１１０、及び実装システム及び装置の中で）エッジ証明ネームサービスを実装し、方法は、（例えば、ノード又は装置２２００、２２３２、２２４０、又は２２５０上で又はそれにより実装される）処理回路を用いて実行され、方法は、マスタエッジ装置において、装置から、エッジアーキテクチャ内のサービスに関する情報についてのクエリを受信するステップと、
該クエリに応答して、マスタエッジ装置において、レポジトリ内のエッジ証明ネームサービス（Edge Attestation Name Services (EANS)）データにアクセスするステップと、
クエリに対する応答を装置へ送信するステップであって、該応答は、サービスの証明データ及びサービスを提供するエッジ装置のアドレス若しくは名称のうちの少なくとも１つを含む、ステップと、を含む。

【0882】

第２の例（例Ｒ２）では、例Ｒ１の主題は、装置及びマスタエッジ装置がエッジアーキテクチャ内のレベルを共有する構成を含む。

【0883】

第３の例（例Ｒ３）では、例Ｒ１～Ｒ２の主題は、サービスを提供するエッジ装置は、エッジアーキテクチャ内のマスタエッジ装置と異なる仮想ドメインの中にある構成を含む。

【0884】

第４の例（例Ｒ４）では、例Ｒ３の主題は、エッジアーキテクチャの下位レベルにある第２マスタエッジ装置を識別することにより、ＥＡＮＳデータにアクセスするステップを含み、第２マスタエッジ装置から、サービスの証明データ並びにアドレス若しくは名称のうちの少なくとも１つを受信するステップを更に含む。

【0885】

第５の例（例Ｒ５）では、例Ｒ１～Ｒ４の主題は、応答がサービスの被監視情報の証明書又は伝搬を含むことを含む。

【0886】

第６の例（例Ｒ６）では、例Ｒ１～Ｒ５の主題は、応答がサービスを提供するエッジ装置の位置情報を含むことを含む。

【0887】

第７の例（例Ｒ７）では、例Ｒ１～Ｒ６の主題は、証明データがマスタエッジ装置においてレポジトリに格納される構成を含む。

【0888】

種々の設定で、例Ｒ１～Ｒ７（及び証明ネームサービスの他の態様）は、定義されたアプリケーションプログラミングインタフェース、又はインタフェース仕様；通信プロトコル、メッセージフォーマット、又は定義の使用；並びにエッジコンピューティング環境内の証明及び信頼メカニズムのためのポリシ及びロジックの他の使用及び実装、の結果として観察され又は見られてよい。例Ｒ１～Ｒ７及びこれらの証明サービス技術の他の態様は、（例えば、ＦａａＳ又はＥａａＳ設定においてサービスの中で名前付与及びアドレス指定をサポートするために）サービス動作及びサービス機能の結果としても観察され又は実装されてよい。更に、例Ｒ１～Ｒ７の方法は、実装された命令として（例えば、命令が実行されると方法を実行する機械可読媒体により）、又は実装されたハードウェア構成として（例えば、方法を実行し又は達成するための構成を含む機器により）、エッジコンピューティングシステム内で提供されてよい。従って、例Ｒ１～Ｒ７の特徴（及び証明サービス及び証明データ管理の他の特徴）は、システムオーケストレータ又は設計者により連携させられ又は設計されるとき、エッジクラスタ又はエッジクラウドシステムを構成するために、本願明細書に記載の他の例のうちのいずれかと結合されてよい。

【0889】

アクセラレーションを用いる証明認識ＳＬＡ

【0890】

分散型アーキテクチャ（例えば、エッジクラウド１１０、及び図３～２２Ｄに示したエッジコンピューティングシステム構成）における課題の１つは、限られたリソースしか有しないことのある変化するハードウェア上で証明及びサービスレベル合意タスクのような管理タスクをどのように実行するかである。例えば、ＦＰＧＡ（field programmable gate array）は、特定の処理タスクを実行するよう構成されてよく、管理タスクを効率的に実行するために伝統的な処理コンポーネントを含まなくてよい。しかしながら、ＦＰＧＡは、管理タスクを実行するのに最適な位置にあり得る。以下の構成および技術は、ＦＰＧＡに、管理タスクを向上した効率でローカルで実行するために必要な命令セットを、（例えば、命令セットアーキテクチャ（instruction set architecture (ISA)）等により）提供する。

【0891】

エッジ設定における（例えば、図７～１２に関して示し及び説明したエッジサービス及び機能の中の）ＳＬＡ及び証明手順は、静的でない、動的機能、又はより一般的には満たされる必要のある実際の制約を定義するために実行されなければならない「コード」であってよい。汎用プロセッサ（例えば、中央処理ユニット（central processing unit (CPU)））では、実行コードはＣＰＵが実行するよう設計されたものではないので、これは問題にならない。通常、ポリシ表現の実行は、ポリシにより支配される機能を実行するのに要する時間全体の小さな部分である。しかしながら、ＦＰＧＡは、特定の処理タスクのために構成されてよく、ＳＬＡ及び証明オーバヘッドは、ＦＰＧＡの負担になり、効率を低下させ得る。ＦＰＧＡに負担をかけるＳＬＡ及び証明タスクの問題と戦うために、マイクロ命令セットアーキテクチャ（instruction set architecture (ISA)）エミュレータが実装されて、ＣＰＵをシミュレートし、ＳＬＡ評価及び証明プロトコルを表すカリー関数の妥当なセットを実行するエミュレータ（例えば、非常に制限された汎用命令実行ユニット）内で任意のＳＬＡ又は証明プロセスを実行してよい。ＳＬＡタスクをＦＰＧＡの主要な処理フローからオフロードするには、とても小さなＩＳＡで十分である。

【0892】

図５３は、（例えば、ビットストリームにより表現される）カリー関数とビットストリームを用いて実行する作業負荷と証明要件を記述するサービスレベル合意（service level agreement (SLA)）とを受け付けるＦＰＧＡ（Field Programmable Gate Array）アクセラレータ５３１０を含むエッジアーキテクチャのためのシステム５３００を示す。他の例では、他の種類のハードウェアアクセラレータがこれらの技術と共に利用されてよい。

【0893】

例示的な処理シーケンスでは、処理（０）で、テナント５３０６は、オーケストレータ５３２０から（例えば、基地局５３３０又は他のエッジノードを介して）作業負荷を要求してよい。処理（１）で、オーケストレータ５３２０は、ＳＬＡ、カリー関数、及び作業負荷を供給してよい。処理（２）で、ＦＰＧＡ５３１０は、ビットストリーム／カリー関数をインストールしてよく、作業負荷５３０２を処理してよい。処理（３）で、ＦＰＧＡ５３１０は、例えば作業負荷５３０３に署名する証明カリー関数を適用してよい。一例では、ＦＰＧＡ５３１０は、ビットストリームを検証し得る信頼されるサーバへの帯域外接続を有してよい。これは、ＦＰＧＡ５３１０がビットストリーム自体を検証できない状況で有用であり得る。処理（４）で、オーケストレータ５３２０は、ＳＬＡ要件に従い、証明５３０４を検証する。処理（５）で、作業負荷結果は、テナント５３０６に返される。更なる例では、ＳＬＡを検証するエンティティは、オーケストレータ５３２０又は別の管理エンティティであってよい。これは、複数のオーケストレータが同じエッジ器具に属する（及び、エッジ器具が複数のテナントのためにパーティションされる）状況で起こり得る。他の例では、処理シーケンス及び動作のシーケンス又は種類は、変化してよい。

【0894】

ＦＰＧＡ５３１０は、許容可能な又は許容できないカリー関数、作業負荷コンテキスト、又はテナントコンテキストを記述するＬＳＭを取得することにより、ＬＳＭ実施点であり得る。同様に、オーケストレータ５３２０は、ＬＳＭをＬＳＭ実施点に動的にプロビジョニングし得る。

【0895】

一例では、証明関数は、ＦＰＧＡ５３１０に埋め込まれてよく、又はビットストリームとして動的にロードされてよい。証明関数が動的にロードされた場合、階層化アーキテクチャ（例えば、装置識別子合成エンジン（Device Identifier Composition Engine (DICE)））が適用されて、ＦＰＧＡ５３１０に埋め込まれた層として予め存在する信頼を動的に拡張し得る。埋め込まれた層が層１である場合、動的証明ビットストリームは層２としてリンクされてよい。層２証明鍵が生成されてよい。カリー関数／ビットストリームは、層３として動的に追加されてよい。層２証明コンポーネントは、層３ビットストリームを、層２装置ＩＤ（例えば、合成装置識別子（composite device identifier (CDI)））計算の部分としてハッシングしてよい。層２は、証明鍵を計算し、層２に渡される層３結果に署名してよい。代替として、層３は、証明鍵を計算し、結果に直接署名してよい。

【0896】

何らかの理由で、ＦＰＧＡ５３１０が証明を実行するための十分な情報を有しない可能性がある。このような場合には、アーキテクチャは、証明を実行し及びカリー関数（例えば、委任された（delegated）カリー関数、等）に結果を提供し得る信頼されるサーバへの帯域外セキュア接続を有することにより、拡張されてよい。従って、証明鍵は、証明ビットストリーム提供者にだけ知られている保護技術を用いて保護されてよい。層３ビットストリーム提供者は、これが追加ライセンス料を含み得るので、証明関数を組み込みたくないかも知れない。

【0897】

ＳＬＡは、ＦＰＧＡ５３１０に処理命令を提供するアプレット又はカリー関数のように機能してよい（例えば、これらのパラメータの範囲内でこのビットストリームを走らせ、結果を出力する、等）。証明認識ＳＬＡは、証明マニフェスト（manifest）を調べてよい。ＳＬＡは、ビットストリームイメージをインストールしてよく、該イメージへのアクセスを必要としてよい。ＳＬＡは、埋め込まれた層１システムに、証明及び作業負荷処理のためのカリー関数にどのように対応するかを説明するために使用されてよい。証明されたビットストリーム又はバイナリがユニークなインスタンスを表すこと及び常に参照できることを保証するために、各ビットストリームは、ＵＵＩＤを含み又はそれに関連付けられてよい。

【0898】

ＳＬＡがカリー関数に対応するために使用される方法は、それ自体が、証明可能な主張（assertion）に貢献してよい。例えば、層１ＣＤＩは、層２に供給されるＳＬＡのハッシュを含んでよい。従って、ＦＰＧＡ５３１０は、汎用処理機能を必要とせずに、証明及びＳＬＡ関連タスクを実行する機能を提供されてよい。

【0899】

更なる例では、証明データは、証明が実行されたときを証明するために使用できるタイムスタンプを含む。これは、証明が偽りでなく又は過去のものの再利用でないことを保証するために、乱数と連結されたタイムスタンプの使用を含んでよい。

【0900】

第１の例（例Ｓ１）は、エッジコンピューティング環境（例えば、エッジクラウド１１０、及び実施システム及び装置）で証明認識ＳＬＡを実施し、方法は処理回路（例えば、ノード又は装置２２００、２２３２、２２４０、又は２２５０上に又はそれにより実装される）を用いて実行され、方法は、
エッジネットワークのオーケストレータから、サービスレベル合意（service level agreement(SLA)）、ビットストリーム、及び作業負荷を受信するステップと、
作業負荷にビットストリームを適用して出力を生成するステップと、
作業負荷に証明関数を適用するステップと、
作業負荷への証明関数の適用に基づき、オーケストレータへ検証要求を送信するステップと、
オーケストレータからの肯定的検証応答の受信に基づき、テナントノードへ出力を送信するステップと、を含む。

【0901】

第２の例（例Ｓ２）では、例Ｓ１の主題は、証明関数を用いて作業負荷に署名するステップを含む。

【0902】

第３の例（例Ｓ３）では、例Ｓ１～Ｓ２の主題は、ビットストリームがカリー関数であることを含む。

【0903】

第４の例（例Ｓ４）では、例Ｓ１～Ｓ３の主題は、証明関数がフィールドプログラマブルゲートアレイに埋め込まれることを含む。

【0904】

第５の例（例Ｓ５）では、例Ｓ１～Ｓ４の主題は、証明関数がビットストリームとして動的にロードされ、フィールドプログラマブルゲートアレイ内の層アーキテクチャを使用することを含む。

【0905】

種々の設定で、例Ｓ１～Ｓ５（及び証明認識ＳＬＡの他の態様）は、定義されたアプリケーションプログラミングインタフェース、又はインタフェース仕様；通信プロトコル、メッセージフォーマット、又は定義の使用；並びにエッジコンピューティング環境内の証明関数のためのポリシ及びロジックの他の使用及び実装、の結果として観察され又は見られてよい。例Ｓ１～Ｓ５及びＳＬＡ証明の他の態様は、（例えば、ＦａａＳ又はＥａａＳ設定においてＳＬＡを実装し又は利用するサービスのために）ＳＬＡを使用するサービス動作及びサービス機能の結果としても観察され又は実装されてよい。更に、例Ｓ１～Ｓ５の方法は、実装された命令として（例えば、命令が実行されると方法を実行する機械可読媒体により）、又は実装されたハードウェア構成として（例えば、方法を実行し又は達成するための構成を含む機器により）、エッジコンピューティングシステム内で提供されてよい。従って、例Ｓ１～Ｓ５の特徴（及び証明サービス合意の他の特徴）は、個別に又は前述の暗示的証明若しくは証明エッジネームサービス機能と組み合わせて、システムオーケストレータ又は設計者により連携させられ又は設計されるとき、エッジクラスタ又はエッジクラウドシステムを構成するために、本願明細書に記載の他の例のうちのいずれかと結合されてよい。

【0906】

ネットワークセキュリティの効率的深層学習解析

【0907】

エッジコンピューティングシステム（例えば、エッジクラウド１１０、及び図３～２２Ｄに示すエッジコンピューティングシステム構成）はトラフィックを消費し及び配信するために展開されるので、全部のトラフィックを解析のために中央ＡＩ計算位置（深層学習（deep learning (DL)）インタフェースサーバ）へ送信することは直ちに不可能になる。しかしながら、ネットワーク動作をサポートするための計算を提供するエッジコンピューティングシステム内では、例えばコンテキストに基づくエッジネットワークセキュリティ解析の使用と共に進行中のネットワーク動作に対してセキュリティ解析を実行するという大きな必要がある。このようなネットワーク設定では、新しいＤＬ及びＡＩメカニズムが利用可能であることが期待され、高度な持続的脅威、マルウェア、ＤＤｏｓ、及び同様の攻撃を検出するのに役立つ。これらのメカニズムは、ネットワークオペレータにとっては基本的な運用セキュリティメカニズムであることが期待されるが、これまで、集中型サーバ処理設定に限定されていた。

【0908】

一例では、ネットワークセキュリティ解析及び監視は、エッジコンピューティングシステムの範囲内で、パケット処理パイプラインの部分として、データプレーン開発キット（data plane development kit (DPDK)）から又はＮＩＣ上で又はこれらの組み合わせで（例えば、部分的オフロードモデル）、展開可能である。例えば、パケット処理パイプラインは、ネットワークトラフィック及びパケット処理パイプラインから直接集められたテレメトリを処理するために、ＤＬネットワークモデルのセットにより、動的にプロビジョニングできる。このようなテレメトリは、ネットワークカードまたは他のネットワーク機器により実行されるＨＷパケット処理に対して参照されてよい。

【0909】

既存のアプローチは、時に、ＩＰＦＩＸを用いる解析システム、その後に続く、（ＮＥＴｃｏｎｆ又は同様のツールを用いて）何らかの再構成を生じるためにより上位の決定を行うネットワーク管理システムへのフローテレメトリメタデータの提供に依存する。パケット処理パイプラインによるネットワークセキュリティ解析及び監視の使用は、エッジプラットフォームパケットパイプライン内に処理「タップ（tap）」（例えば、観察点）を保つが、ＡＩモデル構築、トレーニング、及び推定を、ローカルｓｍａｒｔＮＩＣ／ローカルプラットフォームの能力に移行させる。この改良されたアプローチは、中央ソースにデータを戻すことなく、ローカルプラットフォーム上で複数のＡＬ／ＭＬモデルを同時に実行可能にする。

【0910】

ネットワークセキュリティ解析及び監視モデルは、選択されたトラフィック上で（例えば、教師なし学習を用いて）パターン／例外を検出するために使用でき、補強（reinforcement）方法（例えば、ＭＤＰ、Ｑ－Ｌｅａｒｎｉｎｇ）又は予め構成された報酬関数を用いて、プラットフォームリソースを自動的に適応できる。通常は解析システム／管理システム及びｎｅｔｃｏｎｆ（又は同様のツール）により実行される調整的動作は、それぞれの学習モデル層（Ｌ３～Ｌ７）、ＶＮＦ種類、インタフェース種類、等に基づきどの動作がプラットフォーム上で実行可能かを選択する予め構成されたポリシに基づき、ＡＩ／ＭＬモデルにより動的に実行されてよい。例えば、適用可能なポリシは、ポリシに基づくルーティング（policy－based routing (PBR)）の定義と同様の方法で、ＭＬローカル解析のためのポリシに基づくルールの新しいセットとして表現されてよい。

【0911】

この監視及びトレーニングアプローチの使用により、エッジコンピューティングシステム内から学習された知識は、ピアを渡って動的に伝搬可能である。このようなアプローチは、テナント毎にトレーニングされたモデルの使用を含む、マルチテナントモデルにおいて有意な利益を有し得る。このアプローチは、（トレーニングできないＤＬコンポーネントを扱うために）例外検出のためのＩＤＳ／ＩＰＳのような他のセキュリティ機能、及び（例えば、利用可能ＮＩＣアルゴリズムに基づき）どのトラフィックが解析可能か又は不可能かを決定するための高度なルールと統合されてよい。

【0912】

種々の形式のトレーニング（敵対トレーニング又は階層的学習を含む）は、モデルをトレーニングするためにスケジューリングされ又は連携されてよい。更なる例では、ネットワークセキュリティ解析のために、ローカライズされたタスク固有テレメトリ収集アーキテクチャが利用されてよい。このアーキテクチャでは、それぞれのタスクは明確にトレーニングでき、ＳＷ更新をプロビジョニングするのと同様の方法で、トレーニングされたテンプレートが同じタスクの複数のインスタンスのために利用できる。このようなトレーニングの態様は、システムがパーティションされ得ることを考慮して、関連され又はテナントにより分離されてよい。このような考慮は、異なる学習方式が異なるテナントまたはパーティションオーナに適用されることを可能にし得る。

【0913】

更なる例では、タスクのシーケンスは、個別にトレーニングされ、計算設備の中の異なる層において適用できる。しかしながら、システムがグランドトルースを理解するのに又は有用なトレーニングデータを個々のタスクから取得するのに十分に安定していない場合、タスクの幾つかの特定の組み合わせが利用されてよい。

【0914】

従って、種々の例では、種々の方法及び装置は、ネットワークセキュリティ解析及び監視のためのＡＩ（ＭＬ／ＤＬ）モデルを利用して、このようなモデルを、エッジコンピューティングシステムのそれぞれのノードのネットワーク機器の中のパケット処理パイプラインのデータに対して展開してよい。

【0915】

種々の設定で、前述の深層学習及び解析の例は、定義されたアプリケーションプログラミングインタフェース、又はインタフェース仕様；通信プロトコル、メッセージフォーマット、又は定義の使用；並びにエッジコンピューティング環境内のネットワークセキュリティのためのポリシ及びロジックの他の使用及び実装、の結果として観察され又は見られてよい。

【0916】

Ｖ．マルチステークホルダエッジコンピューティングシステムのためのオーケストレーション／サービスレベル管理
更なる例では、オーケストレーション及びサービスレベル管理は、種々のマルチステークホルダエッジコンピューティング設定へと拡張されてよい。

【0917】

動的基準に基づくマルチテナント電力管理の例

【0918】

本願明細書で適応される任意の数のエッジクラウドアーキテクチャ（例えば、エッジクラウド１１０、及び図３～２２Ｄに示したエッジコンピューティングシステム構成）は、ＴＳＰ又はＣＳＰによるＦａａＳがエンドポイント装置（例えば、スマートフォン又はＩｏＴ装置）において実行しているアプリケーションによりアクセス可能なように、適用されてよい。これらのＦａａＳは、エッジアプリケーション作業負荷を加速化するために使用されてよい。種々の例では、加速化ＦａａＳ（Acceleration FaaS (AFaaS)）－機能がハードウェアアクセラレータ内で実装され実行されるＦａａＳ実装－が、エッジＦａａＳ能力を更に向上するために使用されてよい。

【0919】

低待ち時間ＦａａＳ及びＡＦａａＳを可能にするために、アクセラレータ及び計算（例えばプロセッサ）は、基地局又はゲートウェイ層（例えば、１～５ｍｓの間の待ち時間を達成するために、層１４２０にあるモバイルエッジコンピューティング（mobile edge computing (MEC)）ノード）に置かれてよく、又は中央局に（例えば、６～７ｍｓの待ち時間を達成するためにコアネットワーク層１４６０に）置かれてよい。エッジノードからのＦａａＳ及びＡＦａａＳの実行は、待ち時間の利点を有するが、この目的のためにエッジノードハードウェアを割り当てることは困難な場合がある。この困難は、以下：物理的空間的制約；テナント要求（例えば、関数）を処理するための低待ち時間且つ拡張可能スケジューリングソリューションの欠如；高効率計算密度及び加速化（例えば、ＦａａＳ又はＡＦａａＳのために使用されシステムソフトウェアスタックにより使用されない計算及び加速化）の欠如；又は異なる粒度レベルの自動電力管理及び課金ポリシの欠如；のうちの１つ以上から生じ得る。これらの問題のうち、電力管理は、エッジクラウドアーキテクチャの設計及び課金において重要な側面である。基地局及び中央局が通常動作する電力制限が与えられると、プロバイダ（例えば、オペレータ）は、エッジアーキテクチャを展開し及び運用するためのコストを改善するために、動的且つ知的なテナント毎の電力管理を必要とする。

【0920】

ＦａａＳ及びＡＦａａＳのマルチテナント電力管理を解決するために、インスタンス毎の又はテナント毎の電力管理のためのハードウェアサポートが、エッジノードに追加される。このような、電力管理ポリシのためのハードウェアサポートは、待ち時間を増大し又は空間の制限されたエッジノード等（例えば、基地局）から計算サイクルを奪い得るソフトウェアに基づく電力管理を回避する。代わりに、ハードウェアに基づくポリシ管理は、既存のプラットフォーム又はラック設計を拡張し、その結果、加速化された１つ以上の関数要求がハードウェアプラットフォームにより直接処理されるようにする。ソフトウェアが必要ないので、このソリューションは、少ない保守（例えば、ソフトウェア構成又は更新）しか含まない。これは、展開される多数の装置；オーナにより良好な合計コストをもたらし得るより高効率な計算密度；自動的電力スケーリング；マルチテナントアーキテクチャに基づく計測及び課金；又は加速化された電力及び課金応答時間；の場合に重要であり得る。

【0921】

エッジコンピューティングアーキテクチャでテナント電力管理を実施するために、拡張及びプロトコルのセットが使用されてよい。これらの拡張又はプロトコルは、テナントにより構成されるテナントに対するインタフェースを公開するために基地局／アクセルポイントと共に動作する、基地局内、中央局内、データセンタ内、又は任意の他の種類のエッジアプリケーション又はノード内に置かれてよいゲートウェイに追加されてよい。構成は、電力予算（例えば、ワットの観点で、又は金銭の観点で）を設定することを含んでよい。構成は、特定の電力状態（例えば、Ｘワットより少なくない）、電力状態の範囲、性能－ワット最小値、等のような、時間に渡る電力ポリシを設定することを含んでよい。一例では、電力は時間に渡り異なるコストを有することができる。

【0922】

一例では、ゲートウェイは、テナント要求に対する自動負荷バランサを含んでよい。負荷バランサは、ＦａａＳ又はＡＦａａＳを実行するために電力予算のためのテナント構成の影響を受ける。従って、電力予算構成が、低電力予算を伴う低性能要件を指定する場合、負荷バランサは、高電力計算要素よりも、低電力計算要素を選ぶ。一例では、ゲートウェイは、Ｓｅｒｖｉｃｅ／ＡＦａａＳ／ＦａａＳ、課金、又は他の構成可能な要素を管理するために、オーケストレータコンポーネント（例えば、クラスタヘッドノード）とのインタフェースも含む。

【0923】

ゲートウェイに加えて、ラック及びプラットフォーム電力管理も利用されてよい。ここで、ラック又はプラットフォームは、どれだけ多くの電力がテナント毎に割り当てられるかを構成するためにインタフェースを公開する。性能の弱点（performance glass jaw）（例えば、予期しない障害又は性能低下）を回避するために、プラットフォームは、サービス、ＦａａＳ、又はＡＦａａＳ毎に自動サービス低下予測又は監視を提供する。一例では、低下又はその予測は、オーケストレーション層へと通信される。

【0924】

図５４は、（例えば、図７～１２に関連して示され説明されたようなエッジサービス及び機能を実施するための）動的ＳＬＡ及び課金基準に基づくマルチテナントエッジクラウド電力管理のためのシステムを示す。図示のように、ゲートウェイ５４０５は、（例えば、認証及び課金により）インタフェースを介してテナントへのアクセスを提供する。インタフェースは、テナントが、ソフトウェアスタックを通じることなく基地局５４１０により公開されたＡＦａａＳ又はＦａａＳのセットを発見し直接アクセスできるように構成される。ゲートウェイ５４０５は、どのハードウェアプラットフォームがＦａａＳ、ＡＦａａＳ、又は他のサービスが可能か（例えば、リソースを有するか）を決定するための回路を含む。

【0925】

一例では、ゲートウェイ５４０５は、テナントから来る異なる要求の中でも特に、例えば異なる計算及び加速要素から来るテレメトリを用いて、負荷バランシングを実行するよう構成される。一例では、負荷バランシングは、テナントにより構成される実行電力要件に基づく。一例では、負荷バランシングは、テナントに関連付けられた電力予算に基づく。一例では、負荷バランシングは、エッジノード（例えば、基地局５４１０）の異なるリソース上で利用可能な電力または性能に基づく。一例では、負荷バランシングは、サービスに関連付けられた電力要件に基づく。一例では、期待を超える性能劣化が検出され又は予測された場合、システムソフトウェアスタックは、例えば割り込みにより通知されてよい。

【0926】

一例では、テナント要求は、ペイロード及び実行されるべきサービス（例えば、関数）の識別を含む。一例では、要求はＳＬＡも含む。一例では、ゲートウェイ５４０５は、（例えば、図１９～２１Ｃを参照して議論された利用可能なエッジコンピューティングハードウェア構成に基づき）テナント要求を実行するために、幾つかの利用可能なアクセラレータ又は計算要素（例えば、プロセッサ）のうちの１つを選択するよう構成される。

【0927】

図５４に示すように、ゲートウェイ５４０５は、基地局５４１０に含まれる。ゲートウェイ５４０５は、複数のラック実行インスタンス５４０１Ａ、５４０１Ｂ、５４０１Ｃ（例えば、図２２Ｄに示したサーバラックのインスタンス）の中で、テナント（例えば、ユーザ作業負荷）を認証し（例えば、課金目的で）使用を追跡するよう構成される回路を含む。ゲートウェイ追跡コンポーネントは、要求を認証し、認証した要求を（例えば、帯域外設備を介して）中央局へ送信するよう構成される。この送信は、例えばテナントの指定したＳＬＡレベルの、与えられたサービスの使用に基づきテナントに課金するために中央局により使用され得る情報を含む。追跡コンポーネントは、リソース使用を監視し、時間、電力、金銭、等の観点で定義されたかに関わらずテナントの構成した予算のためにこのような使用を保証するよう構成される。従って、例えば、電力がテナントインスタンスにより消費されるとき、追跡コンポーネントは、特定の時点における電力のコストに従い予算を削減する。

【0928】

一例では、ゲートウェイ５４０５は、（スイッチング、クライアントインタフェースの提供、及び他の図示した機能の中でも特に）リソース管理回路を含む。リソース管理回路は、どのプラットフォーム、例えば（例えば、インスタンス５４０１Ａ、５４０１Ｂ、５４０１Ｃの中の）他のノード、ラック、ブレード、プロセッサ、又はハードウェアアクセラレータが、ＦａａＳ又はＡＦａａＳのセットを提供するかを追跡するよう構成される。リソース管理回路は、これらのプラットフォーム又はプラットフォーム内のリソースのためにどれだけ多くの電力が現在利用可能かを追跡するよう構成される。一例では、リソース管理回路は、（例えば、スケジューラによる使用のために）性能メトリック又は他のメタデータを検出し維持するよう構成される。

【0929】

ゲートウェイ５４０５は、図示のように、オーケストレータのようなシステムソフトウェアスタックにインタフェースを公開するよう構成される管理インタフェースを含む。これらのインタフェースは、ソフトウェアスタックが、ゲートウェイ５４０５の動作又はゲートウェイ５４０５を介したプラットフォームの動作を構成又は管理できるようにする。他の場所に記載したように、構成は、ある時点の電力コスト、顧客当たりの電力データ又はテナント限度、ポリシ、等の設定を含んでよい。一例では、インタフェースは、ソフトウェアスタックが、プラットフォームサービスのテレメトリ（遠隔測定）又は使用を可能にする。

【0930】

ゲートウェイ５４０５はテレメトリ回路を含む。テレメトリ回路は、サービスの実行を追跡するよう構成される。一例では、この追跡は、レベル計算又はアクセラレータ利用を追跡することを含む。テレメトリ回路は、この情報をシステムソフトウェアスタックに開示するためのインタフェースを含んでよい。一例では、テレメトリ回路は、テレメトリモデルを実装するよう構成される。このモデルは、入力としてテレメトリデータを受け付け、例えばゲートウェイ５４０５により受信されている要求の数に起因するサービス劣化を検出し又は予測する。一例では、テレメトリ回路は、現在利用可能な電力又は電力特性に基づき、要求を拒否するよう、テナントインタフェースに通知するよう構成される。一例では、この拒否は、サービス又は関数種類に基づいてもよい。更に、他の形式のデータが、他の基地局により提供されてよく（例えば、ロードデータ等）、更なる低下を予測するためにモデルにより使用されてよい。

【0931】

ゲートウェイ５４０５は、メモリを含む（図示されないが、図２１Ａ～２２Ｄを参照して議論されたメモリコンポーネントに従い実装可能である）。メモリは、ペイロード、状態、メタデータ、等を含む要求を格納するよう構成される。一例では、メモリは、「記述フェッチ（fetch the description）」及び「ペイロードフェッチ（fetch the payload）」呼び出しを含むインタフェースを介してアクセラレータ又は計算要素によりアクセスされる。

【0932】

ゲートウェイ５４０５は、負荷バランサを実装するスイッチを含む。スイッチは、認証された要求を受け付け、認証された要求をアクセラレータ又は計算要素へ発送するよう構成される。発送（dispatch）選択を行うために、スイッチは、テレメトリ回路により提供される情報を使用するよう構成される。一例では、スイッチは、特に、以下：
現在の要求に関連付けられた電力要件、
関連付けられたテナントに利用可能な予算、電力の現在のコスト、サービスを実行するのに適する利用可能なプラットフォームリソース、
利用可能な電力、及び実行のための電力要件を提供するために公開された能力（例えば、電力位相、電力最大－最小、等）、
のうちの１つ以上を発送決定の考慮に入れてもよい。

【0933】

一例では、基地局５４１０の中のゲートウェイ５４０５及び異なるプロセッサ又はアクセラレータは、セキュアな高速リンク又は相互接続を介して接続される。一例では、プロセッサ又はアクセラレータをホスティングするプラットフォームは、ゲートウェイ５４０５により送信された要求を受け付けるよう構成された要求回路を含む。要求回路は、テナントにより提供された電力要件を制御し、サービス実行からの結果を提供するよう構成される。

【0934】

これらのコンポーネントの例示的なデータフローは、以下を含んでよい。要求がゲートウェイ５４０５に到着する。本例では、要求は、ペイロード、関数ＩＤ（function_ID）、テナントＩＤ（tenant_ID）、サービスパラメータ、ＳＬＡ又はサービス品質（quality－of－service (QoS)）要件（例えば、待ち時間最終期限）、認証、及び電力要件を含む。一例では、電力要件は、最大－最小電力、電力位相、電力使用に基づく実行の最大－最小コスト、のうちの１つ以上を含む。

【0935】

一旦受信されると、認証回路は要求を認証する。認証に合格した場合、要求はゲートウェイ５４０５のメモリに格納される。更に、新しいエントリは、ゲートウェイ５４０５により受け付けられた全部の要求を追跡するテーブル内に生成される。テーブルは、要求に対応する状態を追跡するよう更に構成される。状態は、要求がメモリに格納される場所、状態、又はどのプラットフォームが関数を実行しているか等を含んでよい。

【0936】

認証に合格すると、認証された要求は負荷バランシングのためにスイッチへと送信される。ここで、スイッチは、基地局５４１０のどのプラットフォームが要求された関数のインスタンスを公開するかを識別し、以下：
ＡＦａａＳが呼び出された場合、利用可能なこれらの加速化された関数のうちの少なくとも１つを有するアクセラレータのうちの１つを選択する、これは複数のアクセラレータへのアクセスを公開する該複数のアクセラレータが存在する場合にラウンドロビン選択を実施してよい；ＦａａＳが呼び出された場合、少ない負荷を有する関数へのアクセスを提供するプロセッサのうちの１つを選択する；
の基準のうちの１つ以上に基づき、それらのうちの１つを選択する。いずれの場合にも、スケジューラは、どのリソースが選択されるかを決定するために、電力基準を使用する。複数のアクセラレータがＡＦａａＳを提供する場合、又は複数のプロセッサがＦａａＳを提供する場合、スイッチは、提供されたＳＬＡ／ＱｏＳを満たす１つを選択する。

【0937】

スイッチは、次に、選択されたプラットフォームへ要求を送信する。スイッチは、要求ＩＤ及び関数の説明を含むゲートウェイ５４０５メモリへのポインタを送信する。一例では、プラットフォームは、サービス実行を実行するために、メモリから関数定義にアクセスする。関数が終了すると、それは、結果が格納されているメモリ位置へのポインタにより、ゲートウェイ５４０５をコールバックする。

【0938】

ゲートウェイ５４０５は、テナントへ応答を返送し、課金又は他の追跡を実行するために対応する実行により中央局システムに連絡する。ゲートウェイ５４０５は、対応する要求に関連付けられた割り当てられたエンティティを解放する。

【0939】

ＳＬＡは、テナントが時間ウィンドウ及び電力コストに基づく所与の幾つかの選択肢である場合、交渉を含む。更なる例では、ＳＬＡオーケストレータは、幾つかの要因（例えば、作業負荷をスケーリングするための時間、結果を報告するための時間、１日の時間毎のホスト毎のワット毎の電力コスト、ＣＰＵ効率エンベロープに基づく電力コスト、特に、サイクル当たりの電力コストがＧＨｚ変化に対して線形でないとき）に基づき選択肢を計算してよい。テナントは、作業負荷スケーリングにおける種々の調整可能パラメータに基づく多数の「見積もり（quotes）」又は選択肢を与えられる。テナント（又はテナントに関連付けられた人物）は、次に、見積もり（quote）を選択し、ＳＬＡにコミットする。一方で、ＳＬＡオーケストレータは、将来のＳＬＡ交渉でより賢明な見積もりを生成するために、テナントの選択の履歴を保持してよい。

【0940】

第１の例示的な方法（例Ｔ１）は、（例えば、エッジクラウド１１０、及び実装システム及び装置のために）マルチテナントエッジクラウド電力管理のためであり、方法は（例えば、ノード又は装置２２００、２２３２、２２４０、又は２２５０上に又はそれにより実装される）処理回路を用いて実行され、方法は、
ゲートウェイにおいて、テナントからの要求を受信するステップであって、ゲートウェイはスイッチ設備を介してノードのハードウェアプラットフォームに接続される、ステップと、
ゲートウェイにおいて、テナントからの要求のための電力構成を受信するステップと、
要求を完了するために、ハードウェアプラットフォームから１つのハードウェアプラットフォームを選択するステップと、
要求をハードウェアプラットフォームへ発送するステップと、を含む。

【0941】

第２の例（例Ｔ２）では、例Ｔ１の主題は、ゲートウェイが認証回路を含み、テナントからの要求を受信するステップは、要求を認証するステップを含む、ことを含む。

【0942】

第３の例（例Ｔ３）では、例Ｔ１～Ｔ２の主題は、ハードウェアプラットフォームから、ゲートウェイのスイッチを介してハードウェアプラットフォームに渡り負荷バランシング要求を含む１つのハードウェアプラットフォームを選択するステップを含む。

【0943】

第４の例（例Ｔ４）では、例Ｔ３の主題は、スイッチが、要求にサービスするために幾つかのプラットフォームのうちのどれが利用可能かを決定するために、ゲートウェイのテレメトリ回路からのデータを組み込むステップを含む。

【0944】

第５の例（例Ｔ５）では、例Ｔ１～Ｔ４の主題は、電力構成が、最大－最小電力範囲、最大電力消費、又は電力消費に基づく最大瞬間値、のうちの少なくとも１つを含むことを含む。

【0945】

第６の例（例Ｔ６）では、例Ｔ１～Ｔ５の主題は、要求が、サービスレベル合意（service level agreement (SLA)）要件を含み、ハードウェアプラットフォームを選択するステップが、ハードウェアプラットフォームを選択するためにＳＬＡ要件を使用するステップを含むこと、を含む。

【0946】

種々の設定で、例Ｔ１～Ｔ６（及びマルチテナント電力又はリソース使用管理の他の態様）は、定義されたアプリケーションプログラミングインタフェース、又はインタフェース仕様；メッセージフォーマット、テレメトリデータ、又は定義の使用；並びにエッジコンピューティング環境内のリソース使用監視及び管理のためのポリシ及びロジックの他の使用及び実装、の結果として観察され又は見られてよい。例Ｔ１～Ｔ６及びこれらの電力管理技術の他の態様は、（例えば、ＦａａＳ又はＥａａＳ設定においてサービスにより呼び出されるリソースを割り当て及び運用するために）サービス動作及びサービス機能の結果としても観察され又は実装されてよい。更に、例Ｔ１～Ｔ５の方法は、実装された命令として（例えば、命令が実行されると方法を実行する機械可読媒体により）、又は実装されたハードウェア構成として（例えば、方法を実行し又は達成するための構成を含む機器により）、エッジコンピューティングシステム内で提供されてよい。従って、例Ｔ１～Ｔ６の特徴（及び電力及びリソース使用制御の他の特徴）は、システムオーケストレータ又は設計者により連携させられ又は設計されるとき、エッジクラスタ又はエッジクラウドシステムを構成するために、本願明細書に記載の他の例のうちのいずれかと結合されてよい。

【0947】

マルチテナント高スループットバイオメトリの例

【0948】

図５５は、エッジクラウドアーキテクチャ（例えば、エッジクラウド１１０、及び図３～２２Ｄに示したエッジコンピューティングシステム構成）におけるバイオメトリック処理の例示的な使用例を示す。関連する他の場所におけるように、エッジコンピューティングは、幾つかの利点を提供する。例えば、複数のアプリケーション（例えば、オブジェクト追跡、ビデオ監視、車両接続、等）にリアルタイムにサービスし応答する能力、及びこれらのアプリケーションのために超低待ち時間要件を満たす能力、である。１つのこのようなアプリケーション、又は使用例は、バイオメトリである。バイオメトリは、新しいビジネスモデルを可能にする使用例である。エッジにおける分散型の加速化されたコンポーネント、及び関連する低待ち時間使用例は、バイオメトリック検証の拡張可能なアーキテクチャを達成するためにも重要である。バイオメトリのための更なる検討は、しかしながら、これらのセキュリティの重要なアプリケーションのために「正しい」（例えば、承認された、許可された、認証された、等）エッジアクターだけが使用されることを保証している。

【0949】

利用され得るエッジコンピューティングアーキテクチャのシナリオは、ネットワーキング及び計算を含むエンドツーエンドインフラストラクチャを制御するオペレータを含む。このシナリオでは、オペレータは、自身のプラットフォームを使用して、自身のサービスを実行し、場合によっては第三者と予備プラットフォームを共有する（例えば、賃貸する）。これは、オペレータの観点から魅力的である。しかしながら、サービスプロバイダは、セキュリティ、プライバシ、サービス品質（ＱｏＳ）、又は知的財産（intellectual property (IP)）保護に関する関心を有することがある。

【0950】

一例では、３つのレベルのエッジ分割が生じてよい。第１に、インフラストラクチャを制御するオペレータは、計算コンポーネントを複数のパーティションに分割してよい。該複数のパーティションのうちの任意のものは、別のオペレータに賃貸されてよい。このモデルは、小さなオペレータが大きなオペレータからのインフラストラクチャを使用する領域で広く行われ得る。第２に、インフラストラクチャオペレータは、割り当てられたパーティションを、同じ種類（例えばレベル１）の３つの論理的パーティション：賃貸可能な又は第三者サービスプロバイダに利用可能なパーティション；ネットワーク機能（例えば、仮想ブロードバンドネットワークゲートウェイ（virtual broadband network gateway (vBNG)）又は仮想進化型パケットコア（virtual evolved packet core (vEPC)）を実行するためのパーティション；及びオペレータが自信の顧客（例えば、オペレータに加入しているユーザ機器（user equipment (UE)））に提供しているサービスをホスティングするためのパーティション；に分割してよい。

【0951】

一例では、低レベル（例えば、レベル２又は下位レベル）のパーティションは、更に複数のパーティションに分割されてよい。ここでも、幾つかは第三者に利用可能である（例えば、他者に賃貸する）。一例では、これらのパーティションは、サービスプロバイダにより管理され仮想的に所有される。同時に、このパーティションは、２つのパーティションに分割されてよく、１つはクラウドサービスプロバイダ（cloud service provider (CSP)）作業負荷を実行するためである。これは、例えば、第三者がパーティションを賃貸し、自身のサービスを他者による使用のために公開することを可能にしてよい（例えば、レベル３アプリケーション）。

【0952】

バイオメトリでは、エッジクラウドハードウェアに関する信頼問題が、測定を行う装置（例えば、携帯電話機又はセキュアドアロック）上でのバイオメトリ作業負荷を保持する、又はバイオメトリベンダにより制御されるクラウド内で作業負荷を実行する、という選択をもたらした。これらのアプローチの欠点は、ユーザ中心型の制限を含むことである。つまり、装置は、通常、装置がバイオメトリックデータを格納している固定数のユーザを認証することに制限されている。データをクラウドに持ち込むことも、制限を有する。例えば、データはクラウドデータセンタ位置に到着するまでに幾つかのネットワークを渡り移動するので、セキュリティが懸念され得る。また、データがクラウドへ送信され、処理され、応答が生成されるので、待ち時間が懸念され得る。更に、サービス自体に加えて、ネットワーク接続が障害点をもたらすので、信頼性が問題になり得る。

【0953】

エッジクラウド環境では（例えば、エッジクラウド１１０、及び実装システム及び装置の中で）、更なる懸念が含まれ得る。例えば、多くのバイオメトリ技術は、バイオメトリックデータの経験的知識を必要とし、記憶装置及びバイオメトリックハードウェアリソースの他者（例えば、他のテナント）との共有を解決しない。これらの技術は、エッジクラウドコンピューティングアーキテクチャの特性を有する階層構造アーキテクチャのために設計されていない。それらは、それらが実行されるプラットフォーム上の制約を想定していないし、階層構造アーキテクチャを考慮していない。エッジクラウドアーキテクチャのコンテキストでは、より多くの作業がエンド装置へと移行され、より多くの制約が記憶空間、電力、及び作業負荷のための計算に課せられる。更に、これらの技術は、通所、エンドツーエンド物理的セキュリティ要件を想定していない。エッジクラウドの場合には、基地局は、物理的監視が保証されない場所に展開され得る。更に、これらの技術は、通常、エンドツーエンドハードウェア加速化を利用せず、又はマルチティアアーキテクチャで記憶装置を効率的に管理しない。これらの要因は、オーナの合計コスト（total cost of ownership (TCO)）削減が求められるとき、重要になり得る。つまり、マルチティアアーキテクチャが解決されない限り、リソースが効率的な計算に確実に向けられることは難しい。

【0954】

エッジクラウドアーキテクチャのコンテキストにおけるバイオメトリのこれらの問題を解決するために、コンテンツデータネットワーク（content data network (CDN)）と同様にエッジにおいてバイオメトリユーザデータを自動的且つセキュアに管理し得る階層構造バイオメトリ認証アーキテクチャが使用されてよい。これは、３つのレベルのエッジ制御により使用され得る新しいモデルのデータアクセスを含み得る。例えば、テナントのみ、テナント及びテナントをホスティングするＣＳＰ、テナント及びテナントをホスティングするＣＳＰ及びＣＳＰをホスティングするオペレータである。アーキテクチャは、エッジ階層構造の異なるレベルにおける、バイオメトリ認証作業負荷のための、テナントにカスタマイズされたハードウェア加速化を含んでよい。

【0955】

一例では、エッジティア（例えば、中央局、基地局、等）は、１つ以上のテナントにより使用される、１つ以上のバイオメトリックメモリ又は加速化されたバイオメトリックハードウェアを含む。このアーキテクチャは、テナントに以下：バイオメトリックデータを記録し又は削除することを可能にするインタフェース；又はエッジ装置から来るバイオメトリック認証要求を処理するためにインテリジェントネットワークインタフェース制御部（例えば、ｉＮＩＣ）内でビットストリームを処理するレジスタ；のような幾つかのコンポーネントを含んでよい。

【0956】

アーキテクチャは、セキュリティ鍵を管理するための命令（例えば、回路に実装されたロジック又はコード）も含んでよい。一例では、セキュリティ鍵は、帯域外メカニズムにより記録（register）される。命令は、作業負荷が上述の３つのレベルのいずれかにおいて正しいアクターにより実行されることを保証するために、エッジ装置から来る要求を認証するよう構成される。

【0957】

アーキテクチャは、テナント毎に、バイオメトリックユーザデータを管理し、バイオメトリックユーザデータの階層構造キャッシュのレベル間（例えば、基地局レポジトリから中央局レポジトリへの）転送を管理するための命令を実装する制御部を更に含んでよい。これらのバイオメトリックデータ管理ポリシは、テナント基準（例えば、データがどこに格納されるか、信頼されるレベルのハードウェアセキュリティ、等）に基づいてよい。一例では、バイオメトリックデータは、オペレータネットワークのコアにホスティングされ、階層構造の中の残りのティアは中間キャッシュティアとして動作する。エッジ装置に近いほど、キャッシュ能力が少ない可能性が高い。これは、結果として、待ち時間を短縮するために、適正なバイオメトリックデータキャッシングポリシを実装することから得られるより大きな効果をもたらす。更に、上述のように、このようなバイオメトリデータは、テレメトリデータを自動的に不活性化し、立ち退かせ、又は削除するために使用され得る、ある種のタイムスタンプ又は期限データを含んでよい。

【0958】

アーキテクチャは、ラック要素を階層構造の他のレベルにある要素に接続するための設備（例えば、イントラネットワーキング回路）も含んでよい。これは、設備インフラストラクチャにより管理されるテナント要件を満たすために、データを異なる記憶プール、電力ドメイン、又はラックの要素に自動的に複製する信頼性回路と関連してよい。

【0959】

一例では、ｉＮＩＣは、所与のユーザを認証するためにエッジ要求を処理するバイオメトリックスケジューリング回路を含んでよい。これは、要求側エンティティが認証要求を実行する権利を有することの検証により達成されてよい。このようなバイオメトリック認証は、認証されるエッジユーザからバイオメトリック参照データを取得するために、バイオメトリデータキャッシュへのアクセスを含んでよい。一例では、認証が実行できない場合（例えば、障害の場合）、要求は、階層構造のより上位へとルーティングされてよい。

【0960】

ユーザから受信したバイオメトリデータを用いてｉＮＩＣ内で認証バイオメトリックビットストリーム及びエッジクラウド内で参照バイオメトリデータを走らせることは、正確且つ高速なバイオメトリをもたらし得る。つまり、このソリューションは、例えば、システムスタックオーバヘッドを生じることなく非バイオメトリ要求のための計算を用いることにより、超低待ち時間エッジ集合、シームレスな位置エッジ装置集合、より良いシステムＴＣＯをもたらし得る。これらの利点は、バイオメトリック作業負荷のための拡張可能なセキュアな自動化されたカスタマイズされたソリューションをもたらす。

【0961】

図５５は、バイオメトリック階層構造アーキテクチャ５５００の一例を示す。図示のように、アーキテクチャ５５００は、エッジ装置５５０５、スモールセル５５１０、基地局５５１５、及び中央局５５２０（ＣＯ）（テルコ（telco）展開のコンテキストで示されるが、他のネットワークコンテキストに等しく適用可能である）を含む。スモールセル５５１０、基地局５１０４、及びＣＯ５５２０は、それぞれエッジゲートウェイ（５５１１、５５１６、５５２１）を含むことに留意する。このエッジゲートウェイ５５１１、５５１６、５５２１は、所与のバイオメトリペイロードがユーザ識別子（ＩＤ）に対応することを検証するためのインタフェースを公開する。エッジゲートウェイ５５１１、５５１６、５５２１は、特定のユーザＩＤのバイオメトリデータがキャッシュされるか否かを調べるキャッシュ５５１２も含んでよい。一例では、キャッシュ５５１２は、テナント毎に組織化されサイズを定められる。従って、一例では、それぞれのテナントは、期待されるバイオメトリスループット又は容量要件に適合するより多くの又は少ないキャッシュを予約してよい。

【0962】

一例では、エッジゲートウェイ５５１１、５５１６、５５２１は、各時点でどんなバイオメトリデータがエッジにキャッシュされるかを管理するために、ビットストリームを記録することを可能にする回路を含む。この回路は、アーキテクチャ５５００の下位の階層構造からバイオメトリデータを予めフェッチするよう構成されてよい。ここで、最上位レベルはＣＯ５５２０であり、エッジ装置５５０５に向かってレベルは減少する。

【0963】

エッジゲートウェイ（５５１１、５５１６、５５２１）は、認証要求に応答してキャッシュにアクセスするアクセス回路を含んでよい。一例では、キャッシュアクセスは、キャッシュがヒットした場合にバイオメトリデータがローカルディスクから読み出されるように、管理される。一例では、バイオメトリデータは、バイオメトリ認証設備（例えば、ハードウェア又はサービス）に、バイオメトリペイロードと一緒に提供される。これらの設備は、次に、認証を実行し、結果をエッジ装置５５０５へ返送してよい。一例では、バイオメトリデータがローカルにキャッシュされない場合、回路は、要求を次のレベルへと（例えば、基地局５５１５からＣＯ５５２０へ）転送する。この転送メッセージは、認証が成功したか否かを示す応答、及び更なる認証のためにローカルにキャッシュされるべき認証のために使用されるバイオメトリデータにより応答されてよい。一例では、認証要求がＣＯ５５２０（又は階層構造の中の等価な最上位レベル）へとカスケードされた（cascaded）場合、要求はクラウドサービスにより解決されてよい。

【0964】

バイオメトリペイロードが処理される各点は、ＬＳＭ実施点であり得る。これは、エッジインフラストラクチャを通じてプライバシセンシティブなコンテンツに従うユーザプライバシを保護するセキュリティポリシの使用を可能にし得る。

【0965】

一例では、上述のエッジゲートウェイコンポーネントは、ｉＮＩＣ内に実装されてよい。従って、ｉＮＩＣは、バイオメトリデータ及び対応する認証を管理する回路を含む。この認証は、例えばこのようなパーティ間の認証のためにバイオメトリックデータセキュリティを保証するために、テナント間でパーティションされてよい。ここで、ｉＮＩＣは、オーナＩＤ（例えば、テナントソフトウェア）が異なるバイオメトリをサポートする技術を処理するために、ｉＮＩＣ内に処理ビットストリームを記録する又は記録解除することを可能にするインタフェースを有する。この処理の部分として、ｉＮＩＣは、エッジ著者（author）を認証するために使用されるセキュア鍵を記録する又は記録解除するよう構成される。これはまた、エッジユーザを認証してよい。従って、ｉＮＩＣは、プールされた記憶装置又はメモリにデータをセキュアに格納するために、及びデータを上位の又は下位のティアへセキュアな方法で送信するために、入ってくる要求を検証するよう構成される。一例では、セキュリティ鍵を管理するｉＮＩＣ回路は、帯域外記録経路を含む。

【0966】

一例では、エッジゲートウェイコンポーネントは、プールされた記憶装置制御部を含む。プールされた記憶装置制御部は、バイオメトリユーザファイルがプールされた記憶装置にどのように格納されるかを管理するよう、及び階層構造キャッシュ構造を実装するよう、構成される。一例では、階層構造キャッシュ構造は、ホット、ワーム、及びコールドデータのようなデータラベル付けに基づく。一例では、プールされた記憶装置制御部は、２つのインタフェースを含む。第１のインタフェースは、作成者毎に、例えばオーナＩＤ、及び特定のアドレス範囲に関連付けられたファイル又はデータがどのように階層構造内で昇格又は降格されるかを指定する場合によっては異なるアドレス範囲又はファイルのセット毎に、ビットストリームの記録及び記録解除を可能にする。

【0967】

ビットストリーム自体は、キャッシュ階層構造の中でデータの昇格又は降格を支配するために使用される種々の情報を受けてよい。例えば、ビットストリームは、プラットフォームのテレメトリ情報に、及び場合によっては特定のオーナＩＤ又は範囲のリストに関連付けられたリソースに作用してよい。一例では、ビットストリームは、特定のオーナＩＤ又は範囲のリストに関連付けられた、毎秒の入力－出力演算数（input－output operations per second(IOPS)）のような性能情報に作用してよい。一例では、ビットストリームは、特定のデータ又はファイルがアクセスされ及びどんなモードであるかを示す情報に作用してよい。

【0968】

第２の記憶装置制御部インタフェースは、階層構造のより上位のティアが、関連付けられたファイル又はデータをティア＋１から現在のティアへと降格させることを可能にするよう構成される。このインタフェースは、回路が現在のオーナＩＤが要求されたデータをキャッシュするために十分な空間を有するか否かを調べるように、実装される。十分な空間がない場合、回路は、より多くのリソースを追加するよう構成される。利用可能な多くのリソースが存在しない場合、回路は、例えば管理エンティティ又はオーケストレータへと、エラーを上げるよう構成される。余地（例えば、十分なリソース）が存在する場合、インタフェース回路は、データを対応するティア＋１から現在のティアへと移動する。

【0969】

同様の方法で、インタフェースは、データを現在のティアからティア－１へと降格するよう構成される。例えば、インタフェースは、オーナＩＤ及び場合によってはアドレス範囲に関連付けられたデータにアクセスする。キャッシュミスがあると、データマネージャは、データをフェッチするよう、下位のティアへ要求を送信する。ここで、インタフェースは、現在のオーナＩＤが要求されたデータをキャッシュするために十分な空間を有するか否かを調べるよう構成される。十分な空間がない場合、より多くのリソースが追加されてよい。より多くのリソースが存在しない場合、問題は、例えばＰＯＤマネージャへ又はオーケストレータへと上げられる。空間が存在する場合、インタフェース回路は、データをティア－１ノードから現在のノードへと移動するよう構成される。

【0970】

一例では、各オーナＩＤ（例えば、テナント）は、キャッシュ階層構造内でデータを昇格又は降格するかを支配する１つ以上のビットストリームを有してよい。一例では、テナントは、エッジゲートウェイにより提供されるデフォルトキャッシングポリシを選択してよい。従って、各オーナＩＤは、カスタマイズされたビットストリームまたは汎用キャッシュ管理ポリシを実装してよい。

【0971】

更なる例では、プライバシ又は法的検討が、上述の方法でバイオメトリック画像の収集及び分配を妨げてよい。このようなシナリオでは、パーソナルデバイス上に、スマート宝石（smart jewelry）内に、又は暗号鍵を含む何らかの形式の認証されたコンポーネントに、バイオメトリック基準テンプレートを保持するために、設計原理が利用されてよい。鍵は、使用を認証するために使用され、このような鍵はプライバシ規範に違反することなく、必要に応じて伝搬され、キャッシュされ、使用され得る。鍵は、信頼レベルを鍵に関連付けるために鍵を保護するために使用されるセキュア要素、及びユーザの鍵への結合、に関する証明請求を含んでよい。（例えば、ユーザは、名前－鍵結合と共に異なる名前を登録する能力を提供されてよい。その結果、それらは、ユーザによって変更できない彼らのバイオメトリではなく、エイリアス（alias）又はアプリケーション固有の名前又はアカウントにより知ることができる。）

【0972】

第１の例示的な方法（例Ｕ１）は、（例えば、エッジクラウド１１０、及び実装システム及び装置の中の）マルチテナント高スループットエッジバイオメトリ処理のためであり、方法は、（例えば、ノード又は装置２２００、２２３２、２２４０、又は２２５０上に又はそれにより実装される）処理回路を用いて実行され、方法は、
インテリジェントネットワークインタフェース制御部（intelligent network interface controller (iNIC)）において、バイオメトリック認証要求を受信するステップと、
ｉＮＩＣにより、プールされた記憶装置制御部から、要求に血会おうするバイオメトリックデータを読み出すステップと、
ｉＮＩＣにより、バイオメトリックデータを要求の中のデータと比較して、バイオメトリック認証を実行するステップと、
ｉＮＩＣにより、バイオメトリック認証を含む、要求に対する応答を送信するステップと、を含む。

【0973】

第２の例（例Ｕ２）では、例Ｕ１の主題は、プールされた記憶装置制御部からバイオメトリックデータを読み出すステップが、
プールされた記憶装置制御部により、バイオメトリックデータのローカルキャッシュを検索するステップであって、ローカルキャッシュはキャッシュ階層構造の一部であり、該階層構造の下位レベルほどエッジ装置に近い、ステップを含む、ことを含む。

【0974】

第３の例（例Ｕ３）では、例Ｕ２の主題は、バイオメトリックデータが下位レベル装置のローカルキャッシュに存在しないことに応答して、バイオメトリック認証要求が、階層構造の中の該下位レベル装置から受信されることを含む。

【0975】

第４の例（例Ｕ４）では、例Ｕ３の主題は、下位レベル装置にバイオメトリックデータのキャッシングを可能にするために、応答と一緒にバイオメトリックデータを下位レベル装置へ送信するステップ、を含む。

【0976】

種々の設定で、例Ｕ１～Ｕ４（及びマルチテナントバイオメトリック処理の他の態様）は、定義されたアプリケーションプログラミングインタフェース、又はインタフェース仕様；プロトコル、メッセージフォーマット、テレメトリデータ、又は定義の使用；並びにエッジコンピューティング環境内のバイオメトリックサービスのためのポリシ及びロジックの他の使用及び実装、の結果として観察され又は見られてよい。例Ｕ１～Ｕ４のバイオメトリックサービス、及び上述の他の変形は、（例えば、ＦａａＳ又はＥａａＳ設定で使用されるサービスメッセージング及びデータ通信からの）他のサービス動作及びサービス機能と共に呼び出され又はそれと連携させられる結果として観察され又は実装されてもよい。更に、例Ｕ１～Ｕ４の方法は、実装された命令として（例えば、命令が実行されると方法を実行する機械可読媒体により）、又は実装されたハードウェア構成として（例えば、方法を実行し又は達成するための構成を含む機器により）、エッジコンピューティングシステム内で提供されてよい。従って、例Ｕ１～Ｕ４の特徴（及びバイオメトリックデータ処理及び管理の他の特徴）は、システムオーケストレータ又は設計者により連携させられ又は設計されるとき、エッジクラスタ又はエッジクラウドシステムを構成するために、本願明細書に記載の他の例のうちのいずれかと結合されてよい。

【0977】

ＳＬＡの移動、処理、及び適応の例

【0978】

一例では、エッジコンピューティングシナリオは、複数のテナント及びステークホルダの間で適切なＱｏＳ条件を検討し及び適応するために適用されてよい。特にエッジクラウドアーキテクチャは、特定レベルのＱｏＳを維持すること又は特定のＳＬＡを満たすことが可能でありながら、プラットフォーム当たりのサービス密度をどれくらい増大させるか又は最大化させるかに取り組み得る。サービス品質属性又はサービスレベル合意の観点から、３つの可能なモデルが適用できる。（１）該特定のサービスについてサービス品質定義またはサービスレベル合意がない。これは、固定量のプライベート又は共有リソースが付属しないことを意味してよい。（２）ソフトサービスレベル合意。関連サービスは、プライベートリソース量のセット（例えば、コアハードウェアリソース）、共有リソースのセット（例えば、最終レベルキャッシュ又はメモリ）、の割り当てを有する。その結果、サービスは、サービスの量が共有リソースのユーザにより制限される場合でも、プライベート及び共有計算リソースの量に依存して、スループット及び待ち時間をユーザに提供する。従って、本シナリオでは、サービスの量又は複雑性（及びプラットフォームに対する圧力）が増大するとき、９９％保証された待ち時間は可能でなくてよい。（３）ハードサービスレベル合意。ここで、サービスは、プライベートモードで全部のサービスを使用している。この場合、期待されるジッタは最小であると想定される。このＳＬＡを達成するために、２つのアプローチを取ることができる：（ａ）プラットフォームがサービスに完全に割り当てられることを保証する。（ｂ）全部の共有リソースを、ハードパーティションされ個々に割り当てられるよう構成する。

【0979】

いずれかの種類のＳＬＡを達成するために、分散型エッジクラウドアーキテクチャは、作業負荷及びワークフローを複数のエッジノードの間で分散させようとしてよい。しかしながら、エッジコンピューティングシステムは、複数のエッジノードの間でサービス動作を提供するＳＬＡを展開し及び利用しようとするとき、多くの問題に直面し得る。第１に、ＳＬＡを複数の計算位置で適応し及び利用可能にする直ちに使用可能なメカニズムが存在しない。第２に、複数の計算位置が呼び出されるので、及びサービスが異なるノードへと移動するので（例えば、計算がデータに対して移動されるので）、オーケストレータ及びサービスコーディネータは、サービスがどのように知覚されているか、及び追加ノードが呼び出される必要があるか否かを理解する必要がある。第３に、ＳＬＡを満たすために、サービスが複数のエッジノードの間で移動されるので、移動に失敗した場合に、又は新たに参加したノードがＳＬＡを満たすことができない場合に、問題になり得る。

【0980】

図５６は、エッジコンピューティングシステム５６００（例えば、エッジクラウド１１０の一部を実装するために設けられたシステム、又は図３～２２Ｄに示したエッジコンピューティングシステム構成）の複数のエッジノードの間のＳＬＡの移動（migration）のシナリオを示す。このシナリオでは、ＳＬＡ「サービスホスティング」抽象化（abstraction）は、サービス実行について確立される。これは、あるノードから別のノードへ（例えば、ノード１ ５６４１からノード２ ５６４２へノード３ ５６４３へ）の関数作業負荷の転送を支援する。抽象化は呼び出されるべきサービス又は関数を指定しようとしないので、このサービスホスティング抽象化は、（例えば、ＵＰＮＰのようなアプローチにより提供される）「サービスプロバイダ」抽象化と異なる。むしろ、抽象化は、ＳＬＡを満たすために必要なホスティング環境属性及び制約を記述するために使用される。

【0981】

第１の例では、ＳＬＡ５６３０の下で動作する作業負荷５６２０は、エッジノードに跨がり（例えば、ノード１ ５６４１からノード２ ５６４２へノード３ ５６４３へ）移動されてよい。この移動の最中及び後に、作業負荷が獲得された（landed）場所、それぞれのノードの間でこの作業負荷を実行する能力、を知るためにデータトレーサビリティアプローチが使用されて、ＳＬＡ５６３０の充足を保証する。理解されるように、特に、作業負荷及びこのような作業負荷に対するサービス可用性が（例えば、インスタンス５６５１Ａ、５６５１Ｂ、５６５１Ｃにより）インフラストラクチャのあちこちに移動されるとき、サービスのコヒーレント性及び継続性が追跡可能且つ検証可能である必要がある。これは、サービス（及びＳＬＡ５６３０目的地（objective））がクライアント（例えば、ＵＥ５６１０）によりどのように知覚されるかを検証することを含む。更に、セキュリティの観点から、ＳＬＡ５６３０はセキュリティ保護のための値及びそのアプリケーションのための枠組みを確立できるので、ＳＬＡ５６３０は、ＬＳＭ使用の種類及びストラテジを交渉する車両であり得る。

【0982】

異なるサービス（及びサービスインスタンス）を異なるノードで利用するために作業負荷を移動することは、イースト－ウェスト（ノード間）の移動、ノース－サウス（クライアントからサーバへ、又はエンドポイントから更にネットワーク内へ）の移動、又は両方のアプローチの整然とした結合を用いて生じてよい。移動は、エッジノードがＳＬＡ５６３０を満たす問題に直面しており（例えば、リソースの利用可能な近隣ノードからの、サーバ若しくはゲートウェイから更にネットワークへ、等の）助けが必要であるという認識又は予測に基づきトリガされ又は制御されてよい。

【0983】

移動は、モバイルクライアントエンドポイントにより確立されるＳＬＡを使用するために提供されたサービスを動的に適応するために、リソース選択段階の使用を含んでよい。従って、ユーザのＵＥ（例えば、ＵＥ５６１０）は、異なる地理的領域又はサービス領域へ移動し、異なるエッジコンピューティングリソースと連絡するようになり、ＳＬＡ５６３０はＵＥ５６１０と共に移動してよい。

【0984】

生じる特定のＳＬＡ移動動作は、ＳＬＡ５６３０とエッジコンピューティングシステムとの間の依存性、及び呼び出されるサービスの種類、作業負荷の特性、等に基づいてよい。サービスは、２つ以上のカテゴリにグループ化されてよい。高優先度の又はクリティカルサービスは、ＳＬＡ（例えば、あらゆる環境下で保証される最小サービスレベル）を満たすために積極的な移動を必要としてよい。一方で、他のサービスは、ＳＬＡを満たすために、標準的な移動アプローチが与えられる（例えば、メモリ容量の５％又はメモリ帯域幅の１０％が、ビジネス上重要であるが高可用性のために移動可能であるサービスのために、予約され保持されるように移動する）。

【0985】

更なる例では、特定の作業負荷またはサービスのためのＳＬＡ５６３０は、エッジコンピューティング環境の中で、複数の作業負荷を含むグローバル（例えば、システム全体、マルチシステム全体の）ＳＬＡの一部として扱われてよい。従って、計算ノードのうちの１つが特定の作業負荷のためのＳＬＡ５６３０を満たすために使用できないシナリオでは、移動動作は、ＳＬＡ５６３０を満たすために追加リソースを利用させるために呼び出されてよい。このシナリオにおいてＳＬＡの使用は、複数のエッジの間で分割可能な作業負荷（ノードからノードへノードへの計算活動のためのワークフローパイプラインを生じる作業負荷を含む）の使用から利益を享受する。結果として、リソースが作業負荷のうちの任意のアイテムに適合できない場合、作業負荷のためのグローバルＳＬＡは、マーシャル（marshal）リソースに踏み込み、作業負荷処理を達成する。

【0986】

エッジコンピューティングシステムのサービス及びノードの間でＳＬＡ抽象化を定義し移動するためのこれらの概念は、ワークフロー又はサービスの測定可能な目標のために定義された特定のＳＬＯ抽象化と共に使用するのにも適用可能である。また、更なる例では、ＳＬＡ５６３０又はＳＬＯは、（例えば、エッジノード自体の外部にあり、装置にあるものを含む）外部入力、条件、又はデータに基づき複数のエッジノードの間で適応されてよい。結果として、ワークフロー又はサービスのための抽象化された優先度又はＳＬＡ／ＳＬＯは、メトリック又はテレメトリ（例えば、エッジ計算サービスの使用及び連携を示唆するバックホール帯域幅メトリック）を提供可能な他のピア又はエッジ装置からの入力に依存してよい。

【0987】

更なる例では、ＳＬＡ抽象化は、エッジコンピューティングシステム内のＳＬＡ５６３０の適応、修正、及び調整の形式で、ＳＬＡ「ヒーリング（Healing）」の概念に関連付けられてよい。ＳＬＡヒーリングのこのような処理は、潜在的な他のエッジ（例えば、サービスを提出すべき新しい計算位置）を識別するステップ、それ以上作業しないＳＬＡを調整するためにより多くのリソースをどのように追加するかを識別するステップ、又は同様の変更を実施するステップ、を含んでよい。

【0988】

ＳＬＡヒーリングは、作業負荷を解決するために何らかの可能な冗長性を導入することにより、グローバルＳＬＡブリーチ（breach）の発生を低減するために使用されてよい。例えば、全てのホスト又はエッジノードは、全部の作業負荷細分化に関連する命令へのアクセスを与えられてよい。ホストがＳＬＡ要件（例えば、待ち時間要件）を満たすことができない場合、ホストは「実行トークン」を別のホストに渡すことができる。このような連携は、イベント駆動型であってよく、ホスト間／オーケストレータ間通信の使用を通じて可能にされてよい。

【0989】

ＳＬＡ抽象化、ＳＬＡ移動、及びＳＬＡヒーリングの展開は、種々の使用例において生じ、種々のオーケストレータ及びホストの間で提供されてよい。更なる例では、これらの技術（及びＳＬＡ又はシステム動作への他の適応）の使用は、特定の使用例シナリオに依存してよい。例えば、自動車の使用例では、安全関連機能はそれらのＳＬＡを決して妥協しないが、情報娯楽（infotainment）機能は、ＭＥＣ環境（例えば、展開、ロード、等）に適応してよい。従って、分散型エッジコンピューティングシステム内のＳＬＡ適応は、種々の形式を取ってよい。

【0990】

第１の例示的な方法（例Ｖ１）は、エッジコンピューティングシステム（例えば、エッジクラウド１１０、及び実装システム及び装置）においてＳＬＡを管理するためのものであり、方法は、（ノード又は装置２２００、２２３２、２２４０、又は２２５０上に又はそれにより実装される）処理回路を用いて実行され、方法は、
定義されたサービスレベル合意（service level agreement (SLA)）に従い、エッジコンピューティングシステム内の作業負荷を処理するためのエッジ計算リソースの特性を識別するステップと、
ＳＬＡを満たすために必要なホスティング環境属性及び制約を、エッジコンピューティングシステムの利用可能なホスティング環境属性及び制約、作業負荷を処理するために識別された特性から取得した属性及び制約と比較するステップと、
比較に基づき、エッジコンピューティングシステムの第１エッジノードから第２エッジノードへ、作業負荷の移動を実行するステップであって、比較は、第１エッジノードが作業負荷を処理するためのＳＬＡを満たすことができないという認識又は予測を生成し認識又は予測に応答して移動が実行される、ステップと、を含む。

【0991】

第２の例（例Ｖ２）では、例Ｖ１の主題は、移動が、ネットワークのレベルにおける、イースト－ウェスト、ノード間移動に基づき、生じることを含む。

【0992】

第３の例（例Ｖ３）では、例Ｖ１～Ｖ２の主題は、移動が、ネットワークの異なるレベルにおける、ノース－サウス、ノード間移動に基づき、生じることを含む。

【0993】

第４の例（例Ｖ４）では、例Ｖ１～Ｖ３の主題は、第２エッジノードの特性にＳＬＡを動的に適応するステップであって、第２エッジノードは作業負荷のために適用されたＳＬＡを満たすよう構成される、ステップを含む。

【0994】

第５の例（例Ｖ５）では、例Ｖ１～Ｖ４の主題は、ホスティング環境属性及び制約が、作業負荷を利用するクライアントコンピューティング装置の移動性から変更され、クライアントコンピューティング装置は、エッジコンピューティングシステム内のコンピューティングノードの異なる地理的サービス領域の間を移動する、ことを含む。

【0995】

第６の例（例Ｖ６）では、例Ｖ１～Ｖ５の主題は、移動の種類、量、又は速度が、作業負荷により呼び出されるサービスの種類、又は作業負荷の特性に基づくことを含む。

【0996】

第７の例（例Ｖ７）では、例Ｖ１～Ｖ６の主題は、作業負荷のためのＳＬＡが、グローバルＳＬＡのサブセットであり、グローバルＳＬＡは、エッジコンピューティングシステムのノードの間で分散された複数の作業負荷について定義される、ことを含む。

【0997】

第８の例（例Ｖ８）では、例Ｖ１～Ｖ７の主題は、エッジコンピューティングシステム内からの外部入力、条件、メトリック、テレメトリ、又はデータに基づき、ＳＬＡ又はＳＬＡの１つ以上のサービスレベル目標（service level objective (SLO)）を動的に適応するステップを含む。

【0998】

第９の例（例Ｖ９）では、例Ｖ１～Ｖ８の主題は、エッジコンピューティングシステムのそれぞれのエッジノードによる処理のために利用可能な計算リソースに基づき、ＳＬＡの変更、並びにエッジコンピューティングシステムのそれぞれのエッジノードへのＳＬＡ及び作業負荷の追加割り当てを実行するステップを含む。

【0999】

第１０の例（例Ｖ１０）では、例Ｖ１～Ｖ９の主題は、エッジコンピューティングシステムのノード間の作業負荷の実行が、ノード間で通信される実行トークンの使用に基づき、実行トークンは、特定のノードで作業負荷の少なくとも一部を連携させ及び実行するために使用される、ことを含む。

【1000】

種々の設定で、例Ｖ１～Ｖ１０（及びＳＬＡ管理の他の態様）は、定義されたアプリケーションプログラミングインタフェース、又はインタフェース仕様；メッセージング、プロトコル、及び定義の使用；並びにエッジコンピューティング環境内のＳＬＡ及びＳＬＡ値を移動、伝搬、及び適応するためのロジック及びデータ処理の他の使用及び実装、の結果として観察され又は見られてよい。例Ｖ１～Ｖ１０及びこれらのＳＬＡ管理動作の他の態様は、（例えば、ＦａａＳ又はＥａａＳ設定においてサービスの中で提供される作業負荷を有する）サービス動作及びサービス機能の結果としても観察され又は実装されてよい。更に、例Ｖ１～Ｖ１０の方法は、実装された命令として（例えば、命令が実行されると方法を実行する機械可読媒体により）、又は実装されたハードウェア構成として（例えば、方法を実行し又は達成するための構成を含む機器により）、エッジコンピューティングシステム内で提供されてよい。従って、例Ｖ１～Ｖ１０の特徴（及びサービスレベル合意管理の他の例）は、システムオーケストレータ又は設計者により連携させられ又は設計されるとき、エッジクラスタ又はエッジクラウドシステムを構成するために、本願明細書に記載の他の例のうちのいずれかと結合されてよい。

【1001】

サービスレベル目標の変更の例

【1002】

分散型アーキテクチャにおける課題のうちの１つは、様々な処理ユニットが作業負荷を実行するために使用され得る、及び作業負荷が種々の位置へとシフトされ得る分散型エッジアーキテクチャにおけるテナントの有するサービスに関して、サービスレベル合意（service level agreement (SLA)）及び対応するサービスレベル目標（service level objective(SLO)）が、常にテナントに適合していることをどのように保証するかである。

【1003】

本願明細書に記載されるシステム及び方法は、エッジプラットフォーム（例えば、エッジクラウド１１０、及び図３～２２Ｄに示したエッジコンピューティングシステム構成）が、変換ポリシを使用する変換（transform）ＳＬＯ機能、記録（registration）機能、及びサービス品質（quality of service (QoS)）実施ポリシを発行し得る分散型（しかし連携された）アーキテクチャを使用する。エッジテナントは、サービスを取得し、アーキテクチャに渡り分散された作業負荷を実行し又は実施し、その間、ＳＬＡは維持されている。

【1004】

異なるエッジ位置を有する異なるエッジクラウドへの作業負荷の移動は、作業負荷が新しい能力を有する新しいハードウェアへと移動されるとき、新しいＳＬＡをＳＬＯに合うよう自動的に変換する。例えば、ＳＬＡ１は、ＡのＳＬＯを有するエッジ位置１におけるサービスＡのために必要であってよい。作業負荷がエッジ位置２に移動するとき、新しい位置（例えば、エッジ位置２）に基づきＳＬＡを更新する自動的な方法が必要であってよい。

【1005】

図５７は、いくつかの例による、サービスレベル目標に対するエッジ機能ベースの変更のためのシステム５７００を例示している。図５７は、例示的なプラットフォーム５７１０において拡張される異なるコンポーネントの説明を提供する。

【1006】

一例では、プラットフォーム５７１０は、構成を可能にするインタフェースのセット（例えば、インタフェース管理５７１４によって管理される）を含む。インタフェースには、ＳＬＯ機能のために変換を指定できるインタフェースを含んでもよい。指定され得るパラメータ５７２０は、ソースプラットフォームタイプ５７２２、ソースリソースタイプ５７２４、および変換機能５７２６を含んでもよい。ソースプラットフォームタイプ５７２２は、サービスが移行されている元のソースを示すことができる。これは、特定のタイプのプラットフォームモデル、又は特定のタイプの機能性を有するタイプのプラットフォームでもよい。ソースリソースタイプ５７２４は、ソースプラットフォームのＳＬＯが可能性として確立され得るリソースのタイプを示すことができる。変換機能５７２６（例えば、機能５７１２のうちの１つ）は、同じＳＬＯ意味（semantics）を維持するために現在のプラットフォーム内の特定のリソースのための構成を生成するオリジナルプラットフォームのサービスレベル合意のための構成を提供するために実行することができる。例えば、サービスは、１ギガバイトのメモリを有するオリジナルシステムで実行されていてもよく、変換機能５７２６は、それが新しいシステムにおいて同等の１ギガバイトのメモリのＳＬＡを実現するために、新しいシステムのメモリコントローラ内のレジスタＡ１を修正する必要があることを計算してもよい。

【1007】

また、プラットフォーム５７１０は、新しいサービスが既存のＳＬＡを移行することを可能にするインタフェースを含んでもよい。インタフェースは、例えば、システムに移行された新しいサービスを識別するプロセスアドレス空間ＩＤ（Process Address Space ID、ＰＡＳＩＤ）、オリジナルプラットフォーム内のリソースのリスト及び対応するＳＬＡのリスト、オリジナルリソース内のプラットフォームのタイプ、並びにインタフェースを実行する命令又はコードの仕様を可能にすることができる。命令は、変換機能５７２６を実行し、登録機能５７１８を呼び出して必要なプラットフォーム構成オプションを構成する、変換ポリシー５７１６を含んでもよい。ＳＬＯ変換機能５７２６は、インタフェースを使用して登録された機能のデータベースに含まれてもよい。

【1008】

パラメータがインタフェースを介して構成された後、対応するＳＬＡ／ＳＬＯを有する作業負荷が第１のロケーションのハードウェアから第２のロケーションのハードウェアに移動されたという指示を受信することがある。ソースハードウェア情報及び対応するＳＬＡ／ＳＬＯ情報が解析され得、変換機能５７２６が実行のために選択され得る。実行すると、変換機能５７２６は、第２のロケーションのハードウェアをＳＬＡ要件内で動作するか又はＳＬＯに準拠するように構成することができる。したがって、作業負荷がエッジネットワーク全体を移動する間、ＳＬＡが満たされ得る（この作業負荷には、サービスの状態、データ、及び実行に関連し何らかのレベルのＳＬＡを有し得る任意の要素が含まれてよい）。

【1009】

エッジコンピューティング環境（例えば、エッジクラウド１１０、及び実施システム及びデバイス）におけるＳＬＯを変更するためのエッジ機能を実現する第１の例示的な方法（例Ｗ１）は、処理回路（例えば、ノード又はデバイス２２００、２２３２、２２４０、又は２２５０上に、又はこれらにより実現される）を使用して実行される方法であり、当該方法は、エッジネットワーク上で実行される作業負荷のソースプラットフォーム情報を受信するステップと、ソースプラットフォーム情報に基づいて、作業負荷の実行のためのターゲットコンピューティングノードを決定するステップと、エッジネットワークの変換データソースから変換機能を取得するステップと、作業負荷のための変換機能及びサービスレベル合意を使用してターゲットコンピューティングノードのパラメータを構成するステップと、作業負荷を実行のためにターゲットコンピューティングノードに送信するステップを含む。

【1010】

第２の例（例Ｗ２）では、例Ｗ１の主題事項は、ソースプラットフォーム情報がソースプラットフォームグループ又はソースリソースタイプのうち少なくとも１つのメンバを含む構成を含む。

【1011】

第３の例（例Ｗ３）では、例Ｗ１～Ｗ２の主題事項は、サービスレベル合意がサービスレベル目標を含む構成を含み、ターゲットコンピューティングノードのパラメータを構成するステップは、パラメータの値を決定するためにサービスレベル目標に変換機能を適用するステップを含む。

【1012】

第４の例（例Ｗ４）では、例Ｗ１～Ｗ３の主題事項は、ソースコンピューティングノードからターゲットコンピューティングノードへサービスを移行する要求を受信するステップと、サービスのプロセスアドレス識別子を決定するステップと、ソースコンピューティングノードのリソースのリスト及び対応するサービスレベル合意、並びにソースコンピューティングノードのプラットフォームタイプを識別するステップと、ソースコンピューティングノードのプラットフォームタイプ及びサービスレベル合意に基づいてターゲットコンピューティングノードを構成するステップを含む。

【1013】

第５の例（例Ｗ５）では、例Ｗ４の主題事項は、構成されたターゲットノードをサービスに登録するステップを含む。

【1014】

様々な設定において、例Ｗ１～Ｗ５（及び、ＳＬＯ管理の他の態様）は、定義されたアプリケーションプログラミングインタフェース、又はインタフェース仕様；メッセージング、テレメトリデータフォーマット、又はテレメトリ定義の使用；解析；及び、エッジコンピューティング環境内でＳＬＯを移行又は構成するためのポリシー及びロジックの他の使用及び実装の結果として、観察又は監視され得る。例Ｗ１～Ｗ５、及びこれらのサービスレベル変更オプションの他の態様は、（例えば、ＦａａＳ又はＥａａＳ設定でサービスのために定義されたＳＬＯで）サービス動作及びサービス機能の結果として観察又は実施されることもある。さらに、例Ｗ１～Ｗ５の方法は、実装される命令として（例えば、命令が実行されたときに方法を実行する機械読取可能媒体を用いて）、又は実装されるハードウェア構成として（例えば、方法を実行又は達成するための構成を含む装置を用いて）エッジコンピューティングシステムに提供されてもよい。したがって、例Ｗ１～Ｗ５の特徴（及び、例Ｖ１～Ｖ１０で示唆されるものを含むサービスレベル目標又は合意管理の他の特徴を含む）を、本明細書における他の例のいずれかと組み合わせて、システムオーケストレータ又はアーキテクトによって連携され（coordinated）又は設計されるとおりエッジクラスタ又はエッジクラウドシステムを構成してもよい。

【1015】

データ中心調整の例

【1016】

一例では、エッジコンピューティングは、低待ち時間又は高帯域幅を要求するリアルタイムの、一般的に対話型のネットワークエッジ計算に対して適合されたクラウドコンピューティングの一形態として特徴付けることができる。これらの要求を満たすために、エッジコンピューティングノードは、一般に、（例えば、物理的に、少数のネットワークホップなどを介して）エンドデバイス（例えば、エッジデバイス、エッジノード、消費者など）の近くに配置される（リソースが、データにより近くに移動されるため）。このエンドデバイスへの分散近接性は、一般に、限られた電力、計算速度、スケール、又は記憶容量を有するエッジデバイスを結果としてもたらす。一例示的な配備では、エッジノードは、「エッジレット（edgelet）」とも呼ばれることがあるクラウドレット（cloudlet）、「ボックス内のクラウドサービス」のタイプの、特定のエッジベースの分散実行を可能にするように適合されてもよい。

【1017】

この文脈では、クラウドレットは、従来クラウド内で行われているがエッジの近くに移動され、データ消費者又は顧客に対してよりローカルなエッジ環境に配置される、ノード又は機能のグループである。その結果は、エッジレットであり、これは、通常はエッジ機能と考えられるエッジノード又は機能のグループであるが、クラウドハードウェア上で動作し、あるいは従来のクラウド計算要素であろうもの（可能性として、上で論じられたエッジノード配置とは異なる）を使用し得る。したがって、以下の例の多くで、クラウドレットとエッジレットは、同じ要素を参照し、特定のタスクを完了するため又は指定されたサービスを提供するために配置された利用可能な関数の定義されたサブセットであるという同じ一般的な属性を共有する。さらに、グルーピングに対して定義及び達成される機能は、クラウドレット又はエッジレットの間の命名法の選択よりも関連性が高い。

【1018】

一般に、クラウドレットの目的は、高度に対話型のモバイルアプリケーションのサービスにおいて、典型的にはクラウド又はデータセンター環境で、エッジに離散的な計算リソースを提供することである。本明細書で使用される「クラウドレット」及び「エッジレット」への参照は、本明細書で論じられるアーキテクチャ及び構成を使用するエッジコンピューティング設定における（しばしば、ＣＯ又はエッジ計算デバイスにおける）クラウドライクなコンピューティングサービスの限定的なスケールの実装を指す。

【1019】

エッジコンピューティングシステム（例えば、エッジクラウド１１０、及び図３～図２２Ｄに示されるエッジコンピューティングシステム構成）に適用可能な一例では、クラウドレットは、３層の階層の中間層として実行され、最下層がエンドデバイス、次いでクラウドレット、次いでクラウドが階層の最高レベルにある。一般に、モバイルデバイスが移動するとき、計算バックエンドもまた、作業負荷を第１の基地局のクラウドレットから第２の基地局にあり得る別のクラウドレットに転送することによって移動することができる（例えば、より良い局所性（locality）のため）。このシナリオでは、クラウドベースの次層バックエンドは残り、より待ち時間に敏感ではないがより計算集約的な（compute intensive）タスクをサポートし得る。このように、クラウドレットは、従来のクラウドに典型的な通信及び統合スケジューリングによる待ち時間を引き起こすことなく、計算上要求されるタスクを吸収する。モバイルデバイスが第１のエッジノードから第２のエッジノードに（例えば、第１の基地局から第２の基地局に）移動するとき、モバイルアプリケーションをサービスするクラウドレット内にある仮想マシン（ＶＭ）又はコンテナが次のエッジノードの別のクラウドレットに移行される場合がしばしばある。

【1020】

クラウドサービス処理をあるエッジノード又は中央局（central office、ＣＯ）から別のものに移行して、クラウドサービスを移動するユーザ機器（user equipment、ＵＥ）（例えば、モバイルフォン、タブレット、他のエンドデバイス）の近くに維持することは、待ち時間の低減を結果としてもたらす可能性があり、クラウド層内で有意なデータ移動をもたらす可能性もある。データ移動と共に、エッジインフラストラクチャは、特に、データマーシャリング及び入力－出力オーバヘッド、又は段階的な移行（例えば、移行が複数の段階で実行される）の間にデータの分散された一貫性を維持することによって駆動されるオーバヘッドなどの、さらなるペナルティを負う可能性がある。データ及び対応するオーバヘッドの移行はまた、通信インフラストラクチャへの負荷を増大させる場合があり、可能性としてベースラインに負荷を加える。この影響は、移動性が支配的な用途となるとき、及び新しいデータ集約的サービスがエッジエコシステムに登場するときに、通信インフラストラクチャが構築及び拡張にコストのかかることが多いため、有意なものとなる可能性がある。

【1021】

データセンタークラウドと一致して、エッジクラウドは、現代のマイクロサービスアーキテクチャをしばしば包含し、これにおいて、モノリシックアプリケーションロジックは、簡素で緩く結合されたマイクロアプリケーションの集合にリファクタリングされる。ここで、クラウドレットの頻繁な移行は、複数のマイクロサービスにわたって共有され一貫して保持された状態の増幅された移行を結果としてもたらす可能性がある。このような共有がハイパーコンバージドストレージ又は分散データ管理アーキテクチャによって容易にされる、データセンタークラウドとは異なり、エッジインフラストラクチャは、クラウドレット間の比較的限定された帯域幅にわたってより有意でコストのかかる通信トラフィックを負う傾向がある。

【1022】

フォグライクなネットワーク及びサービス設備の出現にもかかわらず、上記の問題は、現在の解決策では一般に対処されていない。基地局間のＵＥ移行は一般的であるが、他の多くは一般に移行されていない。代わりに、多くのネットワークサービスは、サービスを移行する能力を制限するハードウェアアプライアンスによって届けられ、あるいは、ネットワークサービスは、クラウド内でのみ維持され、しばしば待ち時間を増加させる。ビデオストリーミングサービスなどのいくつかのコンテンツデータネットワーク（content data networks、ＣＤＮ）は、デバイスの近くにデータをコロケートする（co-locate）が、これらのエッジサービスは、メディアエンコーディング又はトランスコーディングを越えた相当量の計算を必要とせず、アクティビティは、いくつかの他のアクティビティほど、あるエッジノードから別のエッジノードへの状態転送に依存しない。拡張現実（augmented reality、ＡＲ）や仮想現実（virtual reality、ＶＲ）などの新しい用途は、所与の現在のアーキテクチャより低い働きをする（underperform）可能性がある。

【1023】

ハードウェア集約的な、ネットワークに特化したソリューションは、現在のアーキテクチャではスケーリングせず、エコシステムの他の要素との相互運用性の問題に直面する。イマーシブデータ集約的な計算のプロバイダは、典型的には、エッジ自体をデータ生成又は消費ポイントの近くに移動することを望むが、ユビキタスな配備のためのスケーラブルなインフラストラクチャを作成するための複雑さ及びコストのため、しばしば失敗し、なぜならば、その一般的な使用には、顧客ネットワークの広がりにわたって高い帯域幅の連続的な可用性を必要とするためである。

【1024】

これらの問題のいくつかに対処するために、クラウドレット、又はエッジコンピューティングシステム間で分散された類似のアプリケーション及びサービスの、インテリジェントな調整（orchestration）のための装置及び手法について説明する。これらの要素は、異なるエッジクラウドベースのアプリケーション（例えば、マイクロサービスアプリケーション）の異なる感度に適応する。一例では、クラウドレットは、他のクラウドレットをプロキシして、データ集約的な計算オペレーションをデータグラビティメトリック（data gravity metric）に従って保持しながら、デバイス移動に従って待ち時間に敏感なユーザインタフェース（ＵＩ）インタラクションを移行する。

【1025】

図５８は、最高レベルにクラウド環境（例えば、クラウド５８１０）、中間レベルにクラウドレット（例えば、５８２０又は５８２２）、及び最低レベルにモバイルデバイス（例えば、デバイス５８３０又は５８３２）を有する、３レベル階層５８００を示す。典型的には、クラウドレット５８２０、５８２２は、エンドデバイス５８３０、５８３２からの低（例えば、１ホップ又は２ホップの）待ち時間のために位置決めされる。一例では、クラウドレット５８２０、５８２２は、デバイスが基地局Ａに近いロケーションから基地局Ｂにより近い第２のロケーションに移動する場合、基地局Ａから別の基地局Ｂに移行してもよい。

【1026】

図５９は、クラウドレットサービス移行５９００の一例を示す。図示されるように、基地局Ａのクラウドレット５９１０及び基地局Ｂのクラウドレット５９２０は、バックエンドクラウドインフラストラクチャ５９３０から等距離であると仮定される。これは、任意の基地局におけるクラウドレットがクラウドへのアクセスにおける大きな変動性なしにオペレーション（例えば、計算、データ要求など）をバックエンドクラウド５９３０にエスカレーションし（escalate）得るため、スケーラブルなオペレーションを可能にすることができる。

【1027】

図６０は、部分的なクラウドレットサービス移行６０００の一例を示す。図５９の例を続けると、図６０は、モバイル計算オペレーションのためのデータ量（例えば、データグラビティ）に対する感度を有する移行を示す。したがって、データグラビティが高い場合（例えば、大量のデータ）、クラウドレット５９１０の、基地局Ａから基地局Ｂ（クラウドレット５９２０）への移行、又は基地局Ａからクラウドバックエンド（図示せず）へのデータの移行は、高い帯域幅の使用又は要求を結果としてもたらす可能性があり、一方、可能性として、データ転送のために長い待ち時間を劇的に増加させる。高グラビティデータを転送する代わりに、基地局Ａは、基地局Ｂ上の移行されたクラウドレットがデータとのインタラクションをプロキシするよう機能する間、データを保持してもよい。これは、デバイス移動に従って待ち時間に敏感なＵＩインタラクションの移行を可能にするが、データ集約的な計算オペレーションは、データグラビティに従って基地局で「固定的（sticky）」になる傾向がある。

【1028】

図６１は、クラウドレット６１００内の水平プロキシの一例を示す。ここでは、ピアツーピア（例えば、クラウドレットツークラウドレット）プロキシが、（例えば、クラウドレット５９１０の、基地局Ａからの、基地局Ｂのクラウドレット５９２０への移行のために）水平及び垂直双方のプロキシに拡張される。ここで、水平プロキシは、クラウドレットが一部のオペレーションを参加デバイスにプリインストールされているプロキシにプッシュバックすることを可能にすることによって動作してもよい。このプロキシは、クラウドレットからオペレーションを受け取り、これらをローカル実行するように構成される。例えば、十分に能力のある基地局が、プリインストールされたディープラーニング推論スタックと、ＵＥ６１３０からのデータを有してもよい。ＵＥ６１３０は、ローカル実行のためにＵＥ６１３０にダウンロードされた機能６１３２、又は大量データサブセット６１３４を含んでもよい。ここで、クラウドレットは、様々な推論オペレーションをプロキシにプッシュすることができ、それにより、発話オブジェクト、画像又はビデオオブジェクトなどのデータ集約的入力は、クラウドレット５９１０、５９２０に移動される必要がなくなる。

【1029】

垂直プロキシを用いて、データ集約的なオペレーションは、クラウドレット５９１０、５９２０においてローカル実行される部分に分割されて、例えば、データからキー特徴をローカル抽出し、次いで、キー特徴をクラウドバックエンドに送信することができ、ここで、計算集約的なオペレーションは、抽出された特徴又は過去のコンテキストデータに対して実行されて、精緻化された推論を生成し得る。例えば、クラウドレット５９１０、５９２０は、文字認識、画像特徴認識などを実行するが、次いで、これらの特徴を計算上よりリッチなクラウドレットバックエンドに転送することができ、ここで、特にマルチモーダル推論タスクにおいて、他の処理を実行して、曖昧さを低減し、文字を単語に、文及びそれらの意味にマッピングしてもよい。

【1030】

どのオペレーションをクラウドレット５９１０、５９２０においてプロキシするか、及びどのオペレーションをどのピアクラウドレット５９１０、５９２０において実行するか、又は（例えば、図５８～図６０で上記オフローディング及び移行オペレーションにおいて論じられたように）バックエンドクラウドレットにプッシュするかについての動的判断は、データグラビティポリシーによって駆動されてもよい。これらのデータグラビティポリシーは、動的でもよい。一例では、データグラビティポリシーは、クラウドレット５９１０、５９２０をサポートするハードウェアプラットフォームの記憶容量及びメモリ容量並びにスループットに基づく。一例では、ポリシーは、チャネルセキュリティに基づく。一例では、ポリシーは、スループット又は待ち時間に基づく。一例では、ポリシーは、基地局の所有権、又は計算と通信のコストに基づく。

【1031】

セキュリティの文脈から、図５８～図６０を参照し、インフラストラクチャマネージャが、モバイルデバイス又はテナントＶＭ隔離及び制御のためのＬＳＭ強制ポイント（enforcement point）を提供することができる。クラウドデータキャッシュが、クラウドエンティティ特有のポリシーを含むＬＳＭを伴ってもよい。キャッシュされたクラウドレットコンテンツへのアクセスは、ＯＳ（又は、一方の側がテナント指向のＬＳＭポリシーを適用し、他方の側がクラウド特有のＬＳＭポリシーを適用する二分岐のインフラストラクチャマネージャ）によって強制することができる。移行及びポリシー強制に関与する他のコンポーネントも、ＬＳＭ強制ポイントを提供してもよい。

【1032】

さらなる例において、エッジコンピューティングシステムにおける調整のための様々なタイプの判断が、他のエンティティに委任され、オフロードされてもよく、あるいは、他のエンティティから利用可能な情報に基づいてもよい。例えば、オーケストレータ（Orchestrator）Ａが作業負荷又は他のエッジ処理ジョブ若しくはサービスを調整するために別のシステムを選択したい第１のシナリオについて考える。オーケストレータＡは、システムを選択するために情報を収集するため、エッジオーケストレータシステム（又はサブシステム）のセットとコンタクトする。オーケストレータＡは、次いで、この情報を評価し、調整タスクを委任及びオフロードするための最良の候補を選択することができる。

【1033】

さらに、オーケストレータＡが別のオーケストレータ（オーケストレータＢ）によって管理されるシステム（システムＢ）上のジョブを調整したい第２のシナリオについて考える。ここで、オーケストレータＡは、システムＢのオーケストレータ（オーケストレータＢ）に、特定の調整ポリシー（orchestration policy）に従ってジョブ又はサービスをスケジュールする要求を送信する。オーケストレータＡは、ポリシーに加えて、他の要件（ＳＬＡ、ＳＬＯなど）を提供することができる。

【1034】

このような調整委任は、システムＢのリソースを使用するために、システムＡの権限を移転する方法を使用して実現されてもよい。例えば、この委任は、システムＡが、実行される要求、調整Ａがサービスを実行するためにどんな特権をシステムＢに提供するか、及びサービスを実行するために必要な任意の他の情報に関する証明を提供するシステムＢへの証明された要求を送信したとき、提供されてもよい。

【1035】

さらに別の例では、そのような調整委任は、ＭＥＣシステム配備内で（例えば、ＥＴＳＩ ＭＥＣ仕様と互換性があるように）実現されてもよい。情報は、ＭＥＯツーＭＥＯ（MEO-to-MEO）参照ポイント（例えば、ＥＴＳＩ ＭＥＣ仕様により定義されている）などの様々なＭＥＣ参照ポイント（インタフェース）を使用して識別され、交換される。

【1036】

データ中心調整を実現する第１の例示的な方法（例Ｘ１）は、処理回路（例えば、ノード又はデバイス２２００、２２３２、２２４０、又は２２５０上に、又はこれらにより実現される）を使用してエッジコンピューティングシステム（例えば、エッジクラウド１１０、及び実施システム及びデバイス）において実行される方法であり、当該方法は、第１のクラウドレットにおいてクラウドレット移行信号を受信するステップと、第１のクラウドレットの計算コンポーネントを解析してデータグラビティメトリックを生成するステップと、第１のコンポーネントの第１のデータグラビティ値が閾値を下回ることに応答して、第１のコンポーネントを第２のクラウドレットに移動するステップと、第２のコンポーネントの第２のデータグラビティ値が閾値を上回ることに応答して、第２のコンポーネントを第２のクラウドレットに移動するのを抑制するステップと、第２のクラウドレットに第２のコンポーネントのインタフェースを提供するステップを含む。

【1037】

第２の例（例Ｘ２）では、例Ｘ１の主題事項は、第１のクラウドレットが第１の基地局にあり、第２のクラウドレットが第２の基地局にある構成を含む。

【1038】

第３の例（例Ｘ３）では、例Ｘ２の主題事項は、クラウドレット移行信号の存在が、第１の基地局から第２の基地局へのユーザ機器のハンドオフに応答するものであり、ユーザ機器は、ハンドオフの前に第１のクラウドレットのサービスを使用していることを含む。

【1039】

第４の例（例Ｘ４）では、例Ｘ１～Ｘ３の主題事項は、データグラビティが、第２のコンポーネントによって使用されるデータのサイズに基づくことを含む。

【1040】

第５の例（例Ｘ５）では、例Ｘ４の主題事項は、データグラビティが、データサイズの計算にさらに基づき、計算は、データを第２のクラウドレットに移動するためのリソースのカウント又はデータを第２のクラウドレットに移動するためのコストのうちの少なくとも１つであることを含む。

【1041】

第６の例（例Ｘ６）では、例Ｘ１～Ｘ５の主題事項は、エッジコンピューティングシステム内の調整が、第１のオーケストレータから第２のオーケストレータへの委任に応答して生じることを含む。

【1042】

第７の例（例Ｘ７）では、例Ｘ６の主題事項は、調整が、第１のオーケストレータから第２のオーケストレータに通信される調整ポリシーに従って生じることを含む。

【1043】

様々な設定において、例Ｘ１～Ｘ７（及び、データ中心調整の他の態様）は、定義されたアプリケーションプログラミングインタフェース、又はインタフェース仕様；メッセージフォーマット、テレメトリデータ、又は定義の使用；解析及びテスト；及び、エッジコンピューティング環境内の調整のためのポリシー及びロジックの他の使用の結果として、観察又は監視され得る。例Ｘ１～Ｘ７、及びこれらの調整手法の他の態様は、（例えば、ＦａａＳ又はＥａａＳ設定においてサービスとして提供されるクラウドレットのための）サービス動作及びサービス機能の結果として観察又は実施されることもある。さらに、例Ｘ１～Ｘ７の方法は、実装される命令として（例えば、命令が実行されたときに方法を実行する機械読取可能媒体を用いて）、又は実装されるハードウェア構成として（例えば、方法を実行又は達成するための構成を含む装置を用いて）エッジコンピューティングシステムに提供されてもよい。

【1044】

セキュアなバックエンドデータ共有の例

【1045】

上で論じられたように、エッジコンピューティングシステム（例えば、エッジクラウド１１０、及び図３～２２Ｄに示されるエッジコンピューティングシステム構成）内のエッジコンピューティングノードは、クラウドレット（又はエッジレット）を動作させるように構成することができ、クラウドレットは、高度に対話型のモバイルアプリケーションのサービスにおいてエッジで計算リソースを提供するように適合される。一例では、クラウドレットは、３層階層の中間層として機能し、これにおいて、最低層はエンドデバイス、次いでクラウドレット、次いでクラウドが階層の最高レベルにある。一般に、モバイルデバイスが移動するとき、計算バックエンドもまた、作業負荷を第１の基地局のクラウドレットから第２の基地局にあり得る別のクラウドレットに転送することによって移動することができる（例えば、より良い局所性のため）。このシナリオでは、クラウドレットベースの次層バックエンドは残り、より待ち時間に敏感ではないがより計算集約的なタスクをサポートし得る。このように、クラウドレットは、従来のクラウドに典型的な通信及び統合スケジューリングによる待ち時間を引き起こすことなく、計算上要求されるタスクを吸収する。モバイルデバイスが第１の基地局から第２の基地局に移動するとき、モバイルアプリケーションをサービスするクラウドレット内にある仮想マシン（ＶＭ）又はコンテナが次の基地局の別のクラウドレットに移行される場合がしばしばある。

【1046】

ある基地局から別の基地局への作業負荷（例えば、タスク、アプリケーション、サービス、仮想マシン、コンテナなど）の移行は、一般に、基地局間のデータ（例えば、状態）の転送を伴う。移行データの転送は、常にプライベート通信チャネル（例えば、クラウドレットのオペレータによって制御又は保護されたチャネル）を通じて生じるわけではない可能性がある。これらの場合、暗号化を使用して（例えば、セキュアソケットレイヤ（ＳＳＬ）トンネルなどを介して）データを保護することが一般的である）。

【1047】

一部の作業負荷は、大きい静的データフットプリントを有するが、一層小さい動的データフットプリントを有する。これらの場合、動的データにおけるデータアクセスのパターンは、事前には分からないことがある。これらの条件は、待ち時間の問題につながる可能性がある。例えば、データがバルクで転送される場合、移行中にデータの全てが保護され（例えば、暗号化及び復号され）なければならない。これは、移行作業負荷が継続するのにデータの一部又は多くが必要とされないとき、データの全体に暗号化を行うのがおそらくより効率的である場合でも、移行に関する有意な処理及び時間のオーバヘッドを結果としてもたらす可能性がある。しかしながら、データがオンデマンドで少しずつ転送される場合、各転送は暗号化と復号のさらなる待ち時間を負うが、データが新しい基地局で移行作業負荷処理を継続するために必要とされない場合、一層小さいトータル転送を結果としてもたらす可能性がある。いくつかのインフラストラクチャでは、データの暗号化及び復号は、（例えば、ネットワークインタフェースコントローラ（ＮＩＣ）内の）特化したハードウェアにオフロードされ得るが、このような専用の暗号化ハードウェアは、プロバイダがコストを節約するために高価なハードウェアを回避する可能性があるため、普遍的に利用可能ではない。このことは、さらなるハードウェアがクラウドレットインフラストラクチャにおいてコスト又は電力要件を上げるとき悪化する可能性がある。また、多くのプロバイダは、通信及び暗号化に用いられるネットワークプロトコルが時間とともに変化する可能性があり、特定のハードウェアベースの暗号化スキームの使用が新しいプロトコルの適時の採用を妨げる可能性があるため、特化した復号回路を用いない可能性がある。

【1048】

生じ得るさらなる複雑さには、移動すべきデータがそれ自体、第１のクラウドレット上のストレージに暗号化された状態で存在する状況が含まれる。このことは、それが平文で（例えば、暗号化されずに）記憶されている場合にエッジロケーションがデータ盗難の試みに対してしばしばより脆弱であるため、増加傾向である。これは、物理デバイスが保護されている従来のデータセンターでは、一般に懸念ではない。したがって、データの転送のオーバヘッドは、（例えば、ストレージのための）鍵を用いてストレージインタフェースで復号及び暗号化する必要によって悪化する可能性がある。したがって、ストレージセキュリティと転送セキュリティとの双方に対処するために過剰な暗号化がある可能性がある。

【1049】

上述のシナリオで生じ得る過剰なオーバヘッドに対処するために、作業負荷データはストレージのために暗号化され、ネットワーク転送のためには再暗号化されない。二重暗号化は必要ではなく、本質的に、クラウドレットのストレージ及びネットワークの態様がそれらの労力を連携していない結果である。一例では、ストレージ暗号化鍵をクラウドレットに、可能性として作業負荷の移行ターゲットに配布するために、作業負荷の軌跡が測定される。一例では、データ（例えば、動的データ）も「ホットスポット」を決定するために測定される。ここで、ホットスポットは、作業負荷の実行中にしばしば参照されるデータを指す。ジャストインタイムコンパイラ手法を用いて、ホットスポットを識別してもよい。ひとたび識別されると、ホットスポットは、あり得る移行ターゲットクラウドレットに先取的に（proactively）伝送されてもよい。一例では、データは、待ち時間をさらに低減するために、ターゲットクラウドレットで事前復号される。

【1050】

この解決策は、いくつかの興味深い態様を含み得る。第１に、一例では、伝送データは、ネットワーク伝送のために第２の暗号化－復号オペレーションを使用する代わりに、ストレージのために暗号化される。第２に、一例では、暗号化鍵（例えば、データ記憶に使用される）は、データの共有者間で安全に共有される。第３に、一例では、データのホットサブセクションと、どのホットデータが近い将来に参照される可能性が最も高いかを予測するのに役立つ指標が識別される。このデータは、先取的に移動又は復号されてもよく、待ち時間を低減する。第４に、一例では、クラウドレットプラットフォームは、マルチ鍵完全メモリ暗号化（multi-key total memory encryption）などの暗号化メモリ（例えば、ストレージと対照的にワーキングメモリ）手法を用いる。これは、ブロックストレージ（例えば、ディスク）からワーキングメモリに転送されるときにデータを変換する（例えば、暗号化又は復号する）必要を回避する可能性がある。第５に、一例では、データ集約型である機能に対してデータを移動するのではなく、データに対して該機能を移動する。ここで、データを有するクラウドレットへの可能性として長距離のリモートプロシージャコールの待ち時間は、よりローカルのクラウドレットにデータを転送する必要があることよりも少ない。

【1051】

これらの特徴はいくつかの利点をもたらす。例えば、ＳＳＬトンネル等が回避され、接続待ち時間を低減する。さらに、セキュアなノード間通信のためにデータ静止時（data-at-rest）保護が利用される。再びになるが、これは、セキュリティを犠牲にすることなくクラウドレット間のインタラクションの待ち時間を低減する。

【1052】

図６２は、クラウドレット作業負荷を作業負荷コンポーネントタイプに基づいて複数のフォワードクラウドレット（例えば、クラウドレット６２１５又はクラウドレット６２２０）に移動する一例示的なシナリオ６２００を示す。図示されるように、モバイルデバイス６２０５は、クラウドレット６２１０に作業負荷を有し、モバイルデバイス６２０５をフォワードクラウドレット６２１５及び６２２０に運ぶ軌跡を有する。最終的に、これらのクラウドレット６２１０、６２１５、及び６２２０は、クラウドレット６２２５によって支持されている（backed）。

【1053】

上述のように、図示されたシステムは、クラウドレット間の作業負荷を安全に移行しながら、待ち時間の低減を達成する。したがって、いくつかのアクションは、安全な移行を容易にするために、作業負荷が現在実行されているクラウドレット６２１０によって実行される。この目的のために、クラウドレット６２１０は、作業負荷データをローカルストレージ上に暗号化された形式で維持するように構成される。一例では、この暗号化規律は、クラウドレット６２１０のワーキングメモリに引き継がれる。したがって、この例では、データは、ワーキングメモリ（例えば、存在するプロセッサをサポートするランダムアクセスメモリ（ＲＡＭ）又はキャッシュ）からプロセッサ（例えば、図２１Ａ～図２２Ｄに示される処理リソースの中の）に送信されるときにのみ暗号化されていない。作業負荷データのローカル暗号化の維持を容易にするために、クラウドレット６２１０は、ハードウェア実装のメモリ内暗号化－復号に使用されるメモリ暗号化鍵を交換するインタフェースを実装してもよく、それにより、これらの同じ鍵が、ブロックストレージ内で静止時に暗号化されたデータを維持するために使用されてもよい。この共有は、データ上でのソフトウェア指示の事前暗号化又は事前復号の実行を不要にする。

【1054】

クラウドレット６２１０は、暗号化されていない、但し可能性としてメッセージ完全性で保護されたチャネルを介して、作業負荷のデータをクラウドレット６２１５又は６２２０に送信するように構成される。これは、暗号化及び復号のオーバヘッドをなくす。データがローカルストレージにあるとき暗号化されているため、さらなる暗号化トンネルを生成する必要がない。暗号化又は復号が集約的なオペレーションである可能性があるため、クラウドレット間通信のこの態様を排除することは、有意なリソース節約を結果としてもたらす可能性がある。一例では、データは、データを改変する試みを明らかにするハッシュ（例えば、署名）を送信することによって、転送中に悪意を持って改変されることから保護される。ハッシュは事前計算され、元の（例えば、暗号化されていない、平文など）コンテンツに対するブロック粒度でもよく、それにより、送信されているブロックハッシュに対して第２レベルハッシュを計算することがより効率的にもなり、あるいは、仲介者が改ざんするためにハッシュと暗号化の双方をリバースエンジニアリングする必要があるため、より改ざんされにくくもなる。

【1055】

一例では、クラウドレット６２１０は、クラウドレット（例えば、フォワードクラウドレット６２１５又はクラウドレット６２２０）間でストレージセキュリティ鍵（例えば、ローカルストレージ内の作業負荷データを暗号化又は復号するために使用される鍵）を共有するように構成される。これにより、これらのクラウドレットは、作業負荷の移行中に送信されるストレージ暗号化フォーマットのデータにアクセスすることができる。一例では、鍵転送手法は、ストレージセキュリティ鍵がエッジ範囲の強力に保護されたキーバリューストア（key-value store）（例えば、信頼された実行環境（trusted execution environment、ＴＥＥ））を通して共有され、更新されることを確実にするための規定を備えたアーキテクチャを介して動作する。

【1056】

一例では、クラウドレット６２１０は、作業負荷のコンポーネントを解析して、データのどの要素を事前送信し、事前要求し、又は様々なクラウドレットで事前キャッシュすべきかを識別するように構成される。この解析は、ＪＩＴコンパイラの解析を反映し、作業負荷で頻繁に使用されるホットスポット、データタイプ、実行タイプを識別してもよい。しかしながら、ここでは、コードセクションをコンパイルする代わりに、クラウドレット６２１０は、これらのコンポーネントを先取的に転送する。一例では、これらのコンポーネントは、待ち時間をさらに低減するために、（例えば、メモリ内で）先取的に復号されてもよい。

【1057】

作業負荷コンポーネントのタイプ付けをさらに調べるために、作業負荷における小さい動的フットプリント及び静的フットプリント間の分割について考えてもよい。計算集約的だが小さい動的データフットプリントを有するオペレーション（例えば、より多くのプロセッサ作業を必要とするが、多くの集約データにアクセスする必要はない計算）は、作業負荷（例えば、ＶＭ又はコンテナ）がクラウドレット６２１０から宛先クラウドレット（例えば、クラウドレット６２１５）に移行するとき、宛先クラウドレットで実行される。しかし、大量のデータ上で作業する計算は（例えば、それらのアクセスパターンがランダムであるためか、バイト／ＯＰ比が非常に高い場合）、戻ってソースで処理される。したがって、作業負荷がクラウドレット６２１５に移行した場合、データ集約的なオペレーションはデータと共にクラウドレット６２１０に維持される。そのコンポーネントがクラウドレット６２１５上で呼び出された（例えば、参照された）場合、リモートプロシージャコールなどが、結果を得るためにクラウドレット６２１０に戻される。したがって、一例では、頻繁にアクセスされるデータセットはあまり移動されず、これにより帯域幅と待ち時間の双方を節約する。

【1058】

暗号化鍵の安全な共有と使用に関して、２つの態様が出現する可能性があり、鍵をローカルに（例えば、ワーキングメモリとストレージの間で）、及びクラウドレット間で共有する。一般に、共有の保護には、暗号化鍵がデータの変換のための使用において共有者に直接明らかにされることがないように鍵を共有することを伴う。これは、複製されたキーバリューストア内の名前付きデータの分散ブロック上に暗号化鍵を保持することによって達成することができる。暗号化鍵は、それらの所有者のクレデンシャルによってラップされ（例えば、署名され、暗号化され）てもよい。送信する所有者が、何らかのデータを受信するパーティと共有する必要があるとき、送信する所有者は、署名されたトークンを受信するパーティに提供する。署名トークンにより、受信パーティは、例えば、キーバリューストアからラップされた鍵を取り出し、鍵を復号し、それらをハードウェアメモリ暗号化鍵セットにインストールすることができる。この復号とインストールは、システムサービスによって、セキュアエンクレーブ（例えばＴＥＥ）によって、又はハードウェア命令によって実行されてもよい。これらの方法は、異なるセキュリティ強度を有し得るが、これらの間に明らかな性能差を有するわけではない。

【1059】

鍵を保護するためのこの要素の構成は、使用され得るいくつかの構成の１つである。他の可能性には、暗号化鍵を互いに転送するためのエンティティ間の強力な相互認証ベースのセキュアチャネルを含んでもよい。一般に、これらの転送は小さく、したがって計算上高価ではなく、なぜならば、データが暗号化されておらず、むしろ単にデータを保護する鍵が暗号化されるためである。例えば、複製されたキーバリューストアを実装するノード（例えばクラウドレット）は、暗号化鍵を互いに転送するため、又はセキュアなシステムランタイムを通してメモリ暗号化機能へのそれらのインストールを完了するために、ＳＳＬチャネルによって互いに、及びクラウドレットに接続されてもよい。

【1060】

上記の特徴は、以下のような動作フローに統合されてもよい。１つのクラウドレット（例えば、クラウドレット６２１０）が、作業負荷（例えば、コンテナ又はＶＭ）を別のクラウドレット（例えば、クラウドレット６２１５）に移行するプロセスを開始すると、クラウドレット６２１０は、鍵又はラップされた鍵を、第２のクラウドレット６２１５に送信し、これらは、次いで、宛先クラウドレット６２１５にインストールされる。

【1061】

実行の過程で触れられる可能性が最も高い作業負荷内のデータブロックの転送の要求を開始するために、ヒートマップ又は過去の履歴ベースの予測子を評価するように、予測エンジンを呼び出してもよい。ソースクラウドレットにおけるデータアクセスの最近の履歴と、データに対する長期的な人気（例えば、ヒートマップ）は、どのコンテンツが宛先にストリームされ得るかを決定するために採用され得る２つの手法である。データが必要とするセキュリティのレベルに依存して、ブロックは、多かれ少なかれ強力な（又は異なる）暗号化スキームを使用して暗号化されてもよい。

【1062】

次いで、宛先クラウドレット６２１５は、共有記憶鍵を使用してデータを事前復号してもよく、データに対するデータアクセス要求が発生するまで待つことを選択してもよく、あるいは（利用可能であれば）メモリ暗号化システム復号に依存してもよい。

【1063】

宛先クラウドレット６２１５は、それが実行している作業負荷に関してデータの全てがローカルにキャッシュされていないときを追跡する指標を維持する。したがって、宛先クラウドレット６２１５は、それが実行しようとし得る各タスクについて、そのタスクがそのオペレーションあたりバイト数（bytes-per-operation）のメトリックにおいて高いと識別されるかどうかを調べる。そうである場合、宛先クラウドレット６２１５は、そのようなタスクを実行するために必要なデータを送信するよう起点クラウドレット６２１０に要求する代わりに、起点クラウドレット６２１０にリモート実行メッセージを送信することを選択してもよい。

【1064】

オペレーションあたりバイト数のメトリックが小さい（例えば、閾値より小さい）場合、宛先クラウドレット６２１５は、データが先行予測に基づくプリフェッチ又は事前送信の結果として既に到着していない限り、必要なデータを要求する。一例では、これらのオペレーションの一部又は全部は、データサイドカー（data sidecars）を通して実現することができ、データサイドカーは、データを先取的に又はオンデマンドで透過的に予測及び移動し、必要に応じてデータを先取的に復号又は暗号化する。ここで、データサイドカーは、通信プロキシを拡張して、ソースから宛先へのストレージベースの暗号化データを予測及び移行するタスクを含める。また、データサイドカーは、機能がデータ集約的である場合には、ローカルエンドで機能を実行し、それが必要な取り込むべきデータを要求する代わりに、他方の（例えば、リモート）エンドで機能を透過的に実行してもよい。

【1065】

エッジコンピューティング環境（例えば、エッジクラウド１１０、及び実施システム及びデバイス）でセキュアなバックエンドデータ共有を実現する第１の例示的な方法（例Ｙ１）は、処理回路（ノード又はデバイス２２００、２２３２、２２４０、又は２２５０上に、又はこれらにより実現される）を使用して実行される方法であり、当該方法は、ソースクラウドレット内のローカルデータストア内の作業負荷のために、データを暗号化して暗号化データを作成するステップと、暗号化データの鍵をソースクラウドレットから宛先クラウドレットに転送するステップと、作業負荷移行指示を受信するステップと、作業負荷移行指示に応答して、暗号化データを非セキュアチャネルを通じて宛先クラウドレットに送信するステップを含む。

【1066】

第２の例（例Ｙ２）では、例Ｙ１の主題事項は、暗号化データがローカルデータストアから暗号化データとしてワーキングメモリに転送される構成を含む。

【1067】

第３の例（例Ｙ３）では、例Ｙ２の主題事項は、ソースクラウドレットが、データがワーキングメモリからプロセッサに転送されるときて暗号化データを復号するために完全メモリ暗号化回路を使用する構成を含む。

【1068】

第４の例（例Ｙ４）では、例Ｙ１～Ｙ３の主題事項は、暗号化データの一部分が作業負荷移行の一部として転送されず、該部分は作業負荷によるデータ使用をプロファイリングすることによって決定される構成を含む。

【1069】

第５の例（例Ｙ５）では、例Ｙ１～Ｙ４の主題事項は、例Ｘ１～Ｘ７に従って構成されたクラウドレットと、付随するデータ中心調整の例を含む。

【1070】

様々な設定において、例Ｙ１～Ｙ４（及び、セキュアなデータ共有の他の態様）は、定義されたアプリケーションプログラミングインタフェース、又はクラウドレットインタフェース仕様；データ通信フォーマット又は定義の使用；及び、エッジコンピューティング環境内のデータ通信及び管理のためのポリシー及びロジックの他の使用の結果として、観察又は監視され得る。例Ｙ１～Ｙ４、及びデータ共有の他の態様は、（例えば、ＦａａＳ又はＥａａＳ設定におけるサービス間又はサービス内でのデータ共有のための）連携されたサービス動作及びサービス機能環境の結果として観察又は実施されることもある。さらに、例Ｙ１～Ｙ４の方法は、実装される命令として（例えば、命令が実行されたときに方法を実行する機械読取可能媒体を用いて）、又は実装されるハードウェア構成として（例えば、方法を実行又は達成するための構成を含む装置を用いて）エッジコンピューティングシステムに提供されてもよい。したがって、例Ｙ１～Ｙ４の特徴（及び、データ共有管理及び動作の他の特徴）を、本明細書における他の例のいずれかと組み合わせて、システムオーケストレータ又はアーキテクトによって連携され又は設計されるとおりエッジクラスタ又はエッジクラウドシステムを構成してもよい。

【1071】

エッジテレメトリのデモクラタイゼーション（Democratization）の例

【1072】

分散アーキテクチャにおける課題の１つは、いつでもテナントによりアクセスされ得る分散エッジアーキテクチャでテレメトリを使用する方法である。そのようなテレメトリは、分散エッジアーキテクチャにおいてテナントが有するサービスに関して生成されてもよく、そのテレメトリが、それがどこから来たのかを実際にどのように証明及び検証されるかにおいて、相当なバリエーションを有する。

【1073】

本明細書に記載されるシステム及び方法は、エッジコンピューティングシステム（例えば、エッジクラウド１１０、及び図３～図２２Ｄに示されるエッジコンピューティングシステム構成）における分散された（しかし連携された）テレメトリアーキテクチャを使用し、エッジプラットフォームが、エッジサービスのためのテレメトリを証明された方法で公開することができる。エッジテナントは、アーキテクチャにわたり分散されたこれらのサービスへの監視についてアクセスし、発見し、あるいは追加することができる。テナントは、テレメトリがどのように、いつ生成されるかを検証することができる。以下に説明するテレメトリは、エッジにより認識され、連携される。

【1074】

図６３は、連携エッジシステムにおける分散テレメトリのためのシステム６３００を示す。システム図６３００のエッジシステムは、本明細書に記載されるような任意のエッジシステムであってよい。

【1075】

エッジシステムは、複数のエッジノード６３０６、６３０８、６３１０、プラットフォーム、サービス、センサ、デバイス（例えば、デバイス６３０４）、他のテレメトリサービスなどからデータを受信するためのテレメトリサービス６３０２を含む。一例におけるテレメトリサービス６３０２は、エッジシステムのエッジノード６３０６、６３０８、６３１０上で実行されてもよい。テレメトリサービス６３０２は、エッジノード６３０６、６３０８、６３１０に記憶され得るテレメトリデータを受信する。テレメトリデータの記憶は、エッジノード６３０６、６３０８、６３１０にわたり分散されてもよい。例えば、エッジシステム内のエッジノード６３０６、６３０８、６３１０の一部分が、テレメトリデータ記憶ノードとして作用してもよい。さらに、そのようなテレメトリデータは、マルチテナント及びマルチユーザ情報の態様を含んでもよく、データは、そのようなマルチテナント及びマルチユーザの特性に従って編成又はインデキシングされる。

【1076】

エッジシステム内の分散エッジノード６３０６、６３０８、６３１０のセットは、連携エッジテレメトリインスタンスであってもよく、各分散エッジプラットフォームが、プラットフォーム内で実行されるそれぞれのサービスに関連付けられたテレメトリを公開することができる。異なるエッジロケーションのセット（例えば、１０個の基地局であり、全ての基地局がある同じ領域内にある等）が、それら基地局の各々に関連付けられたテレメトリサービスと、基地局に接続された任意のデバイスを有してもよい。

【1077】

エッジアプライアンスは、特定のサービスのプラットフォームからテレメトリを送信することができる（ＬＬＣミス、メモリＢＷ、テナントサービスデータ、メタデータ、サービスに関連するメトリックなど）。テレメトリは、プラットフォームのローカル証明書で（又は、テレメトリがテナントインスタンスに対してオーケストレータ又は類似のエンティティによって作成される場合にはプラットフォーム証明書及びテナント証明書で）署名することができる。テレメトリは、一例では、テレメトリを検証するサービスのインスタンスによって署名されてもよい。サービスは、サービステレメトリを送信することができる（テレメトリサービス又はエッジノードへのｔｘｔ／ｓなど）。

【1078】

一例では、テナントは、エッジテレメトリサービスに登録されたテレメトリサービスにアクセスすることができる。例えば、テナントは、特定のエッジテレメトリサービスによってどんなサービスが監視されているかを（例えば、特定のエッジテレメトリサービスを維持しているエッジノード６３０６、６３０８、６３１０にディスカバリ要求を送信することによって）発見することができる。また、テナントは、モニタリングサービスを通じて、他のテレメトリサービスのための他のエッジアプライアンスによるホスト情報を発見することもできる。モニタリングサービスは、テレメトリを他のサービスに登録することができる。

【1079】

テナントは、プラットフォーム証明書（例えば、テレメトリを生成するプラットフォーム）に基づいてテレメトリ署名を証明することができる。一例では、テナントは、テレメトリデータのためのサービス署名を使用してテレメトリ署名を証明してもよい。別の例では、サービスは、テナントの問い合わせに応答してテレメトリを検証してもよい。

【1080】

セキュリティの文脈から、テレメトリサービスとエッジホスティング環境は、ＬＳＭ強制ポイントとして機能してもよい。エッジデバイスも、（ユーザがＬＳＭを改ざんできないと想定する場合などに）ＬＳＭ強制ポイントとして機能することができる。ＬＳＭ強制の二分岐が存在し得、エッジインフラストラクチャＬＳＭはデバイスユーザの改ざんから保護され、デバイスユーザＬＳＭはエッジインフラストラクチャの操作から保護される。

【1081】

さらなる例では、分散エッジテレメトリアクセス又は記憶のための手法は、動作の方法又はシーケンスを含んでもよい。この手法は、エッジノードにおいて、複数のプラットフォームからテレメトリデータを受信する第１の動作であって、テレメトリデータは、複数のプラットフォームのうちそれぞれのプラットフォームのローカル証明書で署名される、第１の動作を含む。一例では、テレメトリデータの少なくとも一部は、別のエッジノード６３０６、６３０８、６３１０から受信される。エッジノード６３０６、６３０８、６３１０は、領域に対する複数の分散エッジノードのうちの１つであってもよい。

【1082】

この手法は、エッジノードにテレメトリデータを記憶する動作をさらに含む。この手法は、サービスに対応するテレメトリデータの一部分に対するテナントデバイスからの要求を受信する動作をさらに含む。一例では、サービスに対応するテレメトリデータの部分は、サービスによって署名される。一例では、要求は、テレメトリサービスシステムへのｈｔｔｐｓリクエストを含んでもよい。この要求は、クラウドサーバに送信することができ、そこで、テナントデバイスからの署名が、アクセスを許可するために検証されてもよい。

【1083】

また、この手法は、エッジノード６３０６、６３０８、６３１０からテナントデバイス（例えば、デバイス６３０４）に、対応するローカル証明書を含む、サービスに対応するテレメトリデータの部分を送信する動作を含む。一例では、テレメトリデータの部分を送信する前に、エッジノードは、テナントデバイスがテレメトリデータの部分にアクセスするために適切に認証されている（credentialed）ことを確かめることができる。一例では、テナントデバイスに対する応答は、ＪＳＯＮ応答を含んでもよい。

【1084】

この手法は、テレメトリデータを受信又は管理するためにエッジノード６３０６、６３０８、６３１０においてエッジテレメトリサービス６３０２を実行する動作を含んでもよい。この手法は、テナントデバイス（例えば、６３０４）から、エッジノード６３０６、６３０８、６３１０によって監視されるサービスのディスカバリ要求を受信する動作を含んでもよい。応答において、エッジノード６３０６、６３０８、６３１０は、エッジノード６３０６、６３０８、６３１０によって監視されるサービスのリストを送信することができる。この手法は、サービス６３０２からサービステレメトリデータを受信する動作を含んでもよい。

【1085】

エッジコンピューティングシステム（例えば、エッジクラウド１１０、及び実施システム及びデバイス）においてエッジテレメトリのデモクラタイゼーションを実現する第１の例示的な方法（例Ｚ１）は、処理回路を使用して実行される方法であり、当該方法は、処理及び通信回路（ノード又はデバイス２２００、２２３２、２２４０、又は２２５０上に、又はこれらにより実現される）によって実行され、エッジノードにおいて、複数のプラットフォームからテレメトリデータを受信するステップであって、テレメトリデータは、複数のプラットフォームのうちそれぞれのプラットフォームのローカル証明書で署名される、ステップと、エッジノードにテレメトリデータを記憶するステップと、サービスに対応するテレメトリデータの一部分に対するテナントデバイスからの要求を受信するステップと、エッジノードからテナントデバイスに、対応するローカル証明書を含む、サービスに対応するテレメトリデータの部分を送信するステップを含む。

【1086】

第２の例（例Ｚ２）では、例Ｚ１の主題事項は、テレメトリデータを受信するためにエッジノードでエッジテレメトリサービスを実行するステップを含む。

【1087】

第３の例（例Ｚ３）では、例Ｚ１～Ｚ２の主題事項は、テナントデバイスから、エッジノードによって監視されるサービスのディスカバリ要求を受信するステップと、応答において、エッジノードによって監視されるサービスのリストを送信するステップを含む。

【1088】

第４の例（例Ｚ４）では、例Ｚ１～Ｚ３の主題事項は、サービスに対応するテレメトリデータの部分がサービスによって署名される構成を含む。

【1089】

第５の例（例Ｚ５）では、例Ｚ１～Ｚ４の主題事項は、サービスからサービステレメトリデータを受信するステップを含む。

【1090】

第６の例（例Ｚ６）では、例Ｚ１～Ｚ５の主題事項は、テレメトリデータの少なくとも一部が別のエッジノードから受信される構成を含む。

【1091】

第７の例（例Ｚ７）では、例Ｚ１～Ｚ６の主題事項は、エッジノードが領域に対する複数の分散エッジノードのうちの１つである構成を含む。

【1092】

様々な設定において、例Ｚ１～Ｚ７（及び、エッジテレメトリ連携の他の態様）は、定義されたアプリケーションプログラミングインタフェース、又はインタフェース仕様；テレメトリデータフォーマット、メッセージング、又は定義の使用；及び、エッジコンピューティング環境内でテレメトリデータを収集及び通信するためのポリシー及びロジックの他の使用及び実装の結果として、観察又は監視され得る。例Ｚ１～Ｚ７、及びこれらのエッジテレメトリ使用の他の態様は、（例えば、ＦａａＳ又はＥａａＳ設定で提供されるサービスに関連して生成されるテレメトリのための）サービス動作及びサービス機能の結果として観察又は実装されることもある。さらに、例Ｚ１～Ｚ７の方法は、実装される命令として（例えば、命令が実行されたときに方法を実行する機械読取可能媒体を用いて）、又は実装されるハードウェア構成として（例えば、方法を実行又は達成するための構成を含む装置を用いて）エッジコンピューティングシステムに提供されてもよい。したがって、例Ｚ１～Ｚ７の特徴（及び、エッジテレメトリ収集及び使用の例の他の特徴）を、本明細書における他の例のいずれかと組み合わせて、システムオーケストレータ又はアーキテクトによって連携され又は設計されるとおりエッジクラスタ又はエッジクラウドシステムを構成してもよい。

【1093】

調整された負荷バランシングの例

【1094】

エンタープライズ／データセンタークラウドにおける典型的な負荷バランシングアプローチは、一般に、利用可能な電力、利用可能なＩ／Ｏ又はメモリ帯域幅などの制約の範囲内における均等なプロセッサ利用率を確保するために、作業を分散させるよう試みる。データセンタークラウドでは、待ち時間がクリティカルの、又は高ＱｏＳの作業負荷のステージングも、インフラストラクチャの専用部分内で行うことができる。これらのアプローチは、エッジクラウドインフラストラクチャでは一般に利用できない。エッジクラウドは、比較的基本的なリソースを有し得るだけでなく、より一層複雑で時間変化する需要プロファイルに直面する可能性がある。また、エッジクラウドシステムは、かなり変動する一般に予測不可能な入ってくる作業ストリームを受け取る可能性があり、これは、高い可変性及び広い範囲の入ってくるリクエストのレート、待ち時間又はジッタ許容度の幅広いバリエーション、及びそれらの消費者基盤の、サービスアジリティへの期待感度の広いバリエーションを有する。

【1095】

限られたタイプの負荷バランシングスキームは、階層的負荷バランシングを試行してきたが、純粋なソフトウェア管理の使用を伴っていた。以下の例は、ハードウェア制御における負荷バランシングの態様を規定しながら、複数のエッジノードにわたってＱｏＳポリシーを実装するためにエッジコンピューティングシステムを利用するさらなるアプローチを提供する。このようなタイプの階層的負荷バランシング及び管理は、調整のオーバヘッドを低減し、かつエッジ処理システムのスループットを増加させるのを支援し得る。

【1096】

以下の負荷バランシングスキームは、具体的に、エッジコンピューティングシステム（例えば、エッジクラウド１１０、及び図３～２２図Ｄに示すエッジコンピューティングシステム構成）のインフラストラクチャコンポーネント内のリソースの使用を改善して、データへの計算リソースの移動又は計算リソースへのデータの移動の考慮をバランスさせる。これらのスキームは、低レベルリソース管理の時間変化する適応的な特化によって、エッジクラウドインフラストラクチャ自体を柔軟にすることにより、リソース割り振り問題を簡素化し得る。この特化により、より簡素な、要求ストリーム適応のリソース提供態勢（resourcing postures）をプラットフォームレベルで可能にし、したがって、ロードバランサがそれらの判断を分割統治（divide and conquer）アプローチを通して簡素化することを可能にすることができる。

【1097】

以下の負荷バランシングアプローチでは、各クラウドレット又は他のエッジ作業負荷は、作業負荷要求の全体的なミックスが変化するときエッジコンピューティングノードが動作モードを適合させることができるとしても、所与の時間に処理するように適合され、特定の動作モードに特化され得る。したがって、クラウドレット又は他のエッジ作業負荷は、あるときには、中程度のドロップ率（drop-percentage）で高いスループットに適合することができ、別のときには、作業負荷は、低いドロップ率で、より高いセキュリティ及び機密性のために構成することができる、などする。エッジクラウドは、どれほど多くのクラウドレット又は作業負荷がどの目標のために構成されているかを変更することによって、全体的なサービス態勢を変更することができる。これは、可変数のノード又はこれらノードにおけるクラウドレットが、要求母集団のうち特定の支配的部分を高い効率で処理するように特化されることを意味する。いくつかのリソースが特化されているときでも、ノードは（わずかに低い効率で）他の要求タイプに割り当て可能なままであり、それにより、全体としてトータルサービスキャパシティはサービスの不均等な孤立部に分断されない。

【1098】

一例では、エッジゲートウェイ（又は、エッジクラウドレットノード、他の計算実行ノード）は、複数のモードのうちの１つで動作する。これらのモードには、例えば、標準モード「Ｓ」、スループット最適化モード「Ｔ」、低待ち時間及び低ジッタモード「Ｌ」などを含んでもよい。例えば、このシナリオでは、各モードについて以下の定義が確立され得る。

【1099】

「Ｓ」 標準モード：９５パーセンタイル値の待ち時間≦Ｎｎｓを条件として、スループットを最大化する。

【1100】

「Ｔ」 スループットモード：８０パーセンタイル値の待ち時間≦Ｎｎｓ、及び９５パーセンタイル値の待ち時間≦５Ｎｎｓを条件として、スループットを最大化する。

【1101】

「Ｌ」 低待ち時間／ジッタモード：メジアンの待ち時間≦Ｎ／１０ｎｓ、９５パーセンタイル値の待ち時間≦Ｎｎｓ、９９パーセンタイル値の待ち時間≦２Ｎｎｓを条件として、スループットを最大化する。

【1102】

「Ｘ」 高セキュリティモード：ホワイトリスト掲載作業負荷のメジアンの待ち時間がＮｎｓを下回ることを条件として、ホワイトリスト掲載作業負荷のスループットを最大化する。

【1103】

したがって、各モード定義の使用により、エッジコンピューティングシステムのリソースは、スループット、セキュリティなどをより高い優先順位の目標として管理されるのに対して、速度に対して管理できる。これらの定義の使用は、複数のエッジ処理システムがパケット毎又はフロー毎の再優先順位付け単体のみに応答するのではなく類似の目標に向かって連携することを可能にするように、共鳴を達成するのを支援する。

【1104】

さらなる例では、適切なパラメータ（及び、それらの最適化機能）がそれぞれの作業負荷に使用されることを確保するために、強化深層学習を使用してもよい。

【1105】

図６４は、選択されたモードに従ってそれぞれの計算プラットフォーム内の構成をセットアップするために一緒に連携する（ラック６４２１、６４２２、プラットフォーム６４４１、６４４２、スレッド（sleds）６４６１、６４６２、及びオーケストレータ６４１４における）異なるレベルの構成器６４３１、６４３２、６４５１、６４５２、６４７１、６４７２を有する、エッジコンピューティングシステム６４００における上記アプローチの一実装を示す。オーケストレータ６４１４は、（エッジゲートウェイ６４１０における）モード構成器６４１２に結合され、これは、（上述された要因に基づいて）必要とされるモードを識別し、次いで、ラック６４２１、６４２２、及びラックコンポーネントの間でシステムリソースにモードを伝播する責任を負う。それぞれのトップオブラック（top-of-rack、ＴＯＲ）スイッチは、より高い粒度で必要な変更（アクセラレータの関連付け／関連付け解除など）を実行することができるモード構成器（６４３１、６４３２）を含み、一方で、プラットフォームレベルモード構成器（６４３１、６４３２、６４５１、６４５２）は、より低い粒度アクション（キャッシュ割り振りパラメータ及びコアバインディングの設定など）を実行することができる。

【1106】

一例では、モード（上で列挙されたものなど）は、異なる粒度の範囲に及ぶ構成のセットとして表現することができる。例えば、（構成１）は、計算ノードへの／からの複数のＦＰＧＡの関連付け／関連付け解除であり、プラットフォーム内のサービス密度に影響を与え、（ラックスケールの設計又は構成を含むなどの）構成可能なエッジクラウドインフラストラクチャに適用可能である。（構成２）は、プラットフォーム内のサービスによって消費されるコアの量と、サービスのインスタンス数の変化であり、より多くのサービスインスタンスがサービスごとにより少ないコアを割り振られて、より長い待ち時間を犠牲にしてより高いスループットを狙い（高スループットモード）、一方で、より少ないインスタンスがインスタンスごとにより多くのコアを有して、より少ない待ち時間を支持し得る（低待ち時間モード）。（構成３）は、キャッシュ割り振りパラメータの変更であり、これは、サービスがそのスループット及び待ち時間のレートを調整するために利用できるリソースに影響を与える。

【1107】

オーケストレータ６４１４は、特定のモードにマッピングする異なるシステム構成で構成されてもよい。オーケストレータ６４１４はまた、到着率及びパターン、過去の下流及び上流の情報、キュー長などに基づき得るモード間の切り替えのためのウィンドウを予測するために、機械学習を使用してもよい。

【1108】

さらなる例では、動的モード変化は、必ずしもエッジクラウドシステム全体に適用できない場合がある。エッジクラウドは、異なるモードのパーティション（例えば、標準モードパーティション、高スループットモードパーティションなど）に分割することができ、リソースは、共通のリソースプールからこれらのパーティションに柔軟に移行することができる。これにより、エッジクラウドのうち異なるパーセンテージが、異なるモードであり得る。また、いくつかの場合には、ノードは、現在の動作モードでは高効率で処理できない特定の要求を共通の作業プールにプッシュバックするように設計されてもよい。これは、実行中に特性が明らかになり、低レベル作業リマッパへ戻す再循環を必要とすることが判明したときに生じてもよい。低レベルリマッパは、エッジインフラストラクチャ内の標準モードクラウドレットに向けてこのような再マッピングのラウンドロビン再割り当てを実行することができる。

【1109】

一実装の観点から、これらのモードの使用は、実装方法の１つ又は複数を使用して実装されてもよい。第１の実装方法では、オーケストレータは、異なるモードのためのパラメータ及びシステム構成で構成される。モードが変更される必要があるとき、それは、これらのシステム構成をセットアップするための特定の命令をトリガする。第２の実装方法では、各プラットフォームは、「モード認識」と、（キャッシュ割り振り、コアバインディングなどに関して）各モードにマッピングするパラメータを備える。オーケストレータが、プラットフォームに特定のモードに変わるように指示したとき、プラットフォームは、既知のパラメータを適用し、システムをセットアップする。

【1110】

上記の例から明らかなように、エッジコンピューティングインフラストラクチャは、共有に関してより困難であり、なぜならば、このようなシステムは、他の理由の中でも、大きいデータセンタークラウドの完全な弾力性を有さないからである。これは、エッジクラウド及びサービスプロバイダの、エッジ及び内部ネットワーク処理ノード（ネットワーク内でより深い）の間の「クラウドバースト（cloudburst）」への挑戦を提供する。内部ネットワークロケーションにおけるこのような処理ノードは、一般に、エッジからデータを転送する際に負う待ち時間においてか、又は動的コスト（例えば、交渉された低レートでの計画された先取的なプロビジョニングとは対照的に、ジャストインタイムのプロビジョニングによって引き起こされる）においてかのいずれかで、より一層高いコストを有する可能性がある。

【1111】

一例では、エッジコンピューティングシステムインフラストラクチャは、より低性能のクリティカルサービスを一時的に内部ネットワークノードロケーションに、ネットワークにおいてより深くにシャッフルし、一方で、エッジノードロケーションを使用してこのようなサービスをプロキシすることができる。これにより、システムは、突然発生するより高い優先順位の要求又はより高いクリティカリティのサービスを処理するために、限られたインフラストラクチャをエッジで解放することができる。

【1112】

このような構成において、エッジインフラストラクチャは、要求の突然の増加についての動的なピアツーピアシフティング及びバランシングを実行し、一方で、クラスタ毎に、より高い層へクラウドバーストすべきより低い優先順位のサービスを識別することができる。例えば、エッジノード１は、（待ち時間又は地理的近接性に基づいて）それの近くに位置するエッジノード２に、何らかの作業をシフトすることができ、エッジノード２は同様に、その作業の一部を付近のＣＳＰにシフトして、エッジノード１からそれにシフトされる作業のための余地を作る。このようなシフティング及び適応は、進行中のワークフロー又はアクティビティの文脈で実行することができる。

【1113】

さらなる例では、シフティング及び適応は、ＥＴＳＩ ＭＥＣシステム仕様、又は他の連携アプローチによって示されるような、ネットワークスライシング及び連合エッジオペレーションの文脈において発生し得る。さらに、ＥＴＳＩ ＭＥＣ又は他の連携アプローチの文脈では、共同調整フレームワークが、エッジ－リモートクラウドリソースリース交渉モデルから強化されてもよく、これは同様に、サービスの請求及び課金に影響を与える。

【1114】

エッジコンピューティングシステム（例えば、エッジクラウド１１０、及び実施システム及びデバイス）においてエッジ負荷バランシングスキーム）を実現する第１の例示的な方法（例ＡＡ１）は、（例えば、ノード又はデバイス２２００、２２３２、２２４０、又は２２５０上に、又はこれらにより実現される）処理回路を使用して実行される方法であり、当該方法は、エッジコンピューティングシステムのエッジ計算ノードにおいて、エッジコンピューティングシステム内の負荷バランシングリソースに使用される複数のモードを識別するステップと、エッジコンピューティングノードにおいて、オーケストレータに関連づけられたモード構成器から、負荷バランシングリソースのための複数のモードから選択されたモードの指示を受信するステップと、負荷バランシングリソースのために選択されたモードに基づいて、エッジ計算ノードにおけるリソース使用への変更を実現するステップを含む。

【1115】

第２の例（例ＡＡ２）では、例ＡＡ１の主題事項は、選択されたモードの指示が、エッジ計算ノードの構成を選択されたモードに切り替えるためのコマンドにおいてオーケストレータから受信されることを含む。

【1116】

第３の例（例ＡＡ３）では、例ＡＡ１～ＡＡ２の主題事項は、オーケストレータから、複数のモードのためのそれぞれのパラメータ及びシステム構成を受信するステップを含む。

【1117】

第４の例（例ＡＡ４）では、例ＡＡ１～ＡＡ３の主題事項は、選択されたモードの指示がオーケストレータから決定されることを含み、オーケストレータは、テレメトリデータに対して機械学習を利用して複数のモード間の使用のタイミングを予測する。

【1118】

第５の例（例ＡＡ５）では、例ＡＡ１～４の主題事項は、エッジ計算ノードにおいて、複数の動作モードにマッピングするパラメータ及びシステム構成を識別するステップを含む。

【1119】

第６の例（例ＡＡ６）では、例ＡＡ１～ＡＡ５の主題事項は、エッジ計算ノードを前の動作モードから選択された動作モードに動的に変更するステップを含む。

【1120】

第７の例（例ＡＡ７）では、例ＡＡ６の主題事項は、動的変更に基づいて、エッジコンピューティングシステムの第１の部分が、負荷バランシングリソースのための選択されたモードを利用するように適合され、エッジコンピューティングシステムの第２の部分が、負荷バランシングリソースのための別のモードを利用するように適合される構成を含む。

【1121】

第８の例（例ＡＡ８）では、例ＡＡ１～ＡＡ７の主題事項は、モードが、アクセラレータと計算ノードとの関連付け又は関連付け解除、コアの使用、サービスに提供されるインスタンスの数、又はキャッシュ割り振りパラメータのうちの１つ以上におけるバリエーションを指定する構成を含む。

【1122】

第９の例（例ＡＡ９）では、例ＡＡ１～ＡＡ８の主題事項は、モードが、定義された待ち時間パーセンタイル値に従ってスループットについてのそれぞれの定義を提供する構成を含む。

【1123】

第１０の例（例ＡＡ１０）では、例ＡＡ１～ＡＡ９の主題事項は、負荷バランシングが、スイッチ、プラットフォーム、スレッド、又はオーケストレータシステムで識別される構成情報に基づいてエッジ計算ノード内で実現される構成を含む。

【1124】

第１１の例（例ＡＡ１１）では、例ＡＡ１～ＡＡ１０の主題事項は、作業負荷の優先順位に基づいて作業負荷をエッジノード間で、及びより深いネットワーク層へシフトすることによって、共同的な優先順位ベースの調整を実行するステップを含み、それにより、リソースは、アクセス可能なエッジノード間で解放される。

【1125】

様々な設定において、例ＡＡ１～ＡＡ１１（及び、調整された負荷バランシングの他の態様）は、定義されたアプリケーションプログラミングインタフェース、又はインタフェース仕様；メッセージフォーマット、定義、又は機能の使用；及び、エッジコンピューティング環境内の負荷バランシングの検出及び実装のためのポリシー及びロジックの他の使用及び実装の結果として、観察又は監視され得る。例ＡＡ１～ＡＡ１１、及びこれらの負荷バランシング動作の他の態様は、（例えば、ＦａａＳ又はＥａａＳ設定で提供されるサービス間のリソースの負荷バランシングのための）サービス動作及びサービス機能の結果として観察又は実施されることもある。さらに、例ＡＡ１～ＡＡ１１の方法は、実装される命令として（例えば、命令が実行されたときに方法を実行する機械読取可能媒体を用いて）、又は実装されるハードウェア構成として（例えば、方法を実行又は達成するための構成を含む装置を用いて）エッジコンピューティングシステムに提供されてもよい。したがって、例ＡＡ１～ＡＡ１１の特徴（及び、負荷バランシング及び負荷調整の他の特徴）を、本明細書における他の例のいずれかと組み合わせて、システムオーケストレータ又はアーキテクトによって連携され又は設計されるとおりエッジクラスタ又はエッジクラウドシステムを構成してもよい。

【1126】

ＶＩ．エッジコンピューティング構成のためのコネクティビティユースケース及び構成

以下の例は、ＭＥＣ及び５Ｇネットワーク実装内で提供されるエッジコンピューティング構成に関連する特定の例を提供する。しかしながら、多くの他の標準及びネットワーク実装が、全体を通して論じられるエッジ及びサービス管理の概念に適用可能であることが理解されるであろう。

【1127】

マルチアクセスエッジコンピューティング（ＭＥＣ）ネットワーク内のコネクティビティ、及び５ＧネットワークとＭＥＣネットワークとの間のコネクティビティは、ネットワークのエッジでコンテンツを迅速に処理することにより超応答サービス（ultra-responsive service）体験の提供を可能にする。ＭＥＣは、より少ない待ち時間と増加した帯域幅効率に関する指標を含む、５Ｇネットワークの要求する重要性能指標（Key Performance Indicators、ＫＰＩ）を満たすための重要な柱の一つとして認識されている。しかしながら、電気通信ネットワークにおけるＭＥＣ及び５Ｇのコネクティビティが、要求されるＫＰＩのための技術的なイネーブラであるだけでなく、さらに、ＭＥＣ内及びＭＥＣ－５Ｇのコネクティビティの向上は、電気通信事業の変革に不可欠な役割を果たし、電気通信ネットワークは、産業や他の特定の顧客セグメントのための多用途のサービスプラットフォームに変わっている。

【1128】

ソリューションの観点からは、単一のエッジロケーションを有することは、必要とされる柔軟性を提供せず、コネクティビティの観点で何をユーザに提供できるかと、エッジインフラストラクチャ内の異なるロケーションにどんなソリューション及び製品提供を配備できるかを反映しない。

【1129】

実際のエッジがどこにあるかと、特定のユースケース又は作業負荷に利用できるコネクティビティオプションを定義することは、特定のロケーションがそれに提供する重要性能指標（ＫＰＩ）又はバリュープロポジションに直接関連する。例えば、オペレータインフラストラクチャのコアにモノのインターネット（Internet-of-Things、ＩｏＴ）又は拡張現実（Augmented Reality、ＡＲ）／仮想現実（Virtual Reality、ＶＲ）の作業負荷のエッジインフラストラクチャを定義することは、待ち時間の観点ではそのＫＰＩ要件を満たさない可能性がある。したがって、この作業負荷のエッジは、（基地局又は中央局内の）デバイスにより近くてもよい。一方で、コンテンツデリバリネットワーク（ＣＤＮ）作業負荷のエッジは、基地局、中央局、又はオペレータインフラストラクチャの任意の他の中間集約ポイント（point of aggregation、ＰＯＡ又はＰＯＰ）とすることができる。

【1130】

図６５は、無線ネットワークアーキテクチャにおける異なるエッジコンピューティングノード間の接続を示す。図６５を参照すると、ネットワークアーキテクチャ６５００は、コンピューティングデバイス６５２８（例えば、ユーザデバイス）、エッジコンピューティングノード６５３０～６５４４、及びクラウドネットワーク（又は「クラウド」）６５０８を含む。エッジコンピューティングノード６５３０～６５４４は、個々のノードによって実行されるエッジ層及び機能に基づいてサブ分割され（subdivided）得る。例えば、スモールセル６５３０及びオンプレミス機器（又はエッジレット／クラウドレット）６５３２は、スモールセル／オンプレミスエッジ層６５０２に関連づけられ、スモールセル６５３０は、ＲＡＮ及びネットワーク機能６５１２を実行し、オンプレミス機器６５３２は、ローカルブレイクアウト（local breakout）及びエッジサービス実行機能６５１４を実行する。スモールセル／オンプレミスエッジ層６５０２は、超低待ち時間サービス及びローカルサービスに関連付けることができる。いくつかの態様において、層６５０２は、アクセスエッジ層とすることができる。

【1131】

基地局６５３４、６５３８、及びキャビネット６５３６は、基地局エッジ層６５０４に関連付けられ、基地局６５３４は、ＲＡＮ及びネットワーク機能６５１６を実行し、基地局６５３８は、ローカルブレイクアウト及びエッジサービス実行機能６５１８を実行する。基地局エッジ層６５０４は、田舎の地域又は他のロケーションのための超低待ち時間サービス無線コネクティビティサービスに関連付けることができる。

【1132】

いくつかの態様では、キャビネット６５３６は、コンピューティングデバイス６５２８とローカルＣＯ６５４０との間の有線接続で構成することができる。

【1133】

いくつかの態様では、基地局６５３４は、ネットワーク機能に関連付けられたデータプレーン通信を管理するように構成されたＶＮＦ計算ノードであり、一方で、基地局６５３８は、基地局６５３４からルーティングされるサービス関連要求を処理するように構成されたサービス計算ノードである。いくつかの態様において、基地局６５３４及び６５３８は、同じアンテナ塔にコロケートされ（co-located）てもよい。

【1134】

ローカル中央局（ＣＯ）６５４０と、基地局サービスコンピューティングノード６５４２及び６５４４は、中央局層６５０６に関連づけられ、ローカルＣＯ６５４０は、ネットワーク機能６５２０を実行し、基地局サービスコンピューティングノード６５４２及び６５４４は、ローカルブレイクアウト及びエッジサービス実行６５２２を実行する。いくつかの態様では、層６５０４及び層６５０６は、集約エッジ層とみなすことができる。

【1135】

コンピューティングデバイス６５２８は、ネットワーク機能開始６５１０と、サービス結果提供又はＤ２Ｄ通信６５２４に関連付けられる。クラウド６５０８は、オーバーザトップ（over-the-top、ＯＴＴ）メディアサービスを含むクラウド関連機能６５２６に関連付けられる。

【1136】

図６５はまた、エッジデバイスから要求されたサービスを提供するネットワークノードへのエンドツーエンドフローの技術的分解を示す。いくつかの態様では、エッジロケーション（例えば、層６５０２、６５０４、６５０６）は、インフラストラクチャに接続するために使用される物理媒体に依存する。例えば、無線デバイス（例えば、デバイス６５２８のうちの１つ）のみが、インフラストラクチャがどのように管理及び接続されるかに依存して基地局ロケーション（例えば、６５３４）へのアクセスを有することができる。しかしながら、インフラストラクチャの変化が起きたとき、オペレータは、固定モバイルコンバージェンス（Fixed Mobile Convergence、ＦＭＣ）の傾向をとり、これは、長期的には、潜在的なエッジ層がモバイル及び固定双方のタイプの接続の双方に対して同様に収束することを意味し得る。

【1137】

図６６は、電気通信サービスプロバイダ（ＴＳＰ）とクラウドサービスプロバイダ（ＣＳＰ）との間のエッジ通信相互作用を示す。図６６を参照すると、ネットワークアーキテクチャ６６００は、図６６が通信サービスプロバイダインフラストラクチャ６６５８とクラウドサービスプロバイダインフラストラクチャ６６６０との間のコネクティビティをさらに示していることを除き、ネットワークアーキテクチャ６５００と類似している。６６０２～６６４４として参照される図６６の要素は、それぞれ、図６５において６５０２～６５４４として参照される要素に対応する。

【1138】

図６６に示されるように、ＣＳＰインフラストラクチャ６６６０は、クラウド６６０８に関連づけられたＣＳＰ６６４６の１つ以上のネットワークノードを含むことができる。より具体的には、基地局エッジ層６６０４は、ＣＳＰエッジデータセンター６６５４を含むことができ、これは、エッジデバイス６６２８により近い、基地局エッジ層６６０４内でクラウド６６０８によって通常提供されるクラウド機能を提供することができる。これに関して、ＴＳＰインフラストラクチャ６６５８の基地局エッジ層６６０４からＣＯエッジ層６６０６及びクラウド６６０８に通常転送されるネットワークトラフィックは、基地局エッジ層６６０４内のＣＳＰエッジデータセンター６６５４にルーティングされ、その結果、より高速でより効率的なコネクティビティリンクがもたらされる。

【1139】

同様に、ＣＯエッジ層６６０６は、ＣＳＰ ＣＯ６６５６を含むことができ、これは、エッジデバイス６６２８により近い、ＣＯエッジ層６６０６内でクラウド６６０８によって通常提供されるクラウド機能性を提供することができる。これに関して、ＴＳＰインフラストラクチャ６６５８のＣＯエッジ層６６０６からクラウド６６０８に通常転送されるネットワークトラフィックは、ＣＯエッジ層６６０６内のＣＳＰ ＣＯ６６５６にルーティングされる。

【1140】

潜在的なサービスマッピングが行われると、エッジクラウドに付随する基本的な質問の１つは、誰がそのようなサービスを提供し、誰がそれを実装しているかである。この文脈において、オペレータ（又はＴＳＰ）は、インフラストラクチャ全体（計算を含む）を所有し、自身の加入者に自身のサービスを提供し、他のサービスプロバイダ（例えば、Ｇｏｏｇｌｅ）に、自身のソフトウェアスタックを実行するように潜在的に計算をレンタルすることを望んでいる。一方、クラウドサービスプロバイダ（又はＣＳＰ）は、ＴＳＰにより提供されるハードウェア上で（ＩＰ保護のため、セキュリティのため、サービス品質のために）ソフトウェアスタックを実行することを必ずしも受け入れるわけではない。これらの態様において、ＣＳＰは、図６６に示すように、ＴＳＰを単にネットワークインフラストラクチャプロバイダと見なし、そのエッジロケーション内の、自身のブラックボックス（例えば、クローズドラック）を配置及び実行するためのスペースを求めている。

【1141】

いくつかの態様において、図６６に示されるように、ハードウェアプロビジョニング及びサービスホスティングに関して、３つの潜在的なシナリオを実施することができる。

【1142】

（１）ＴＳＰは、ネットワーキング及び計算リソースを含むエンドツーエンドのネットワークインフラストラクチャを所有する。このシナリオでは、ＴＳＰは、自身のプラットフォームを使用して自身のサービスを実行し、可能性として、予備のプラットフォームを第三者にレンタルする。ＴＳＰは、ネットワークインフラストラクチャを設計するときに（１）セキュリティ、（２）プライバシー、（３）ＱｏＳ、（４）ＩＰ保護に関連する問題を考慮することができる。以下の３つのレベルのリソースレンタルが生じ得る。

【1143】

ａ．インフラストラクチャを所有するオペレータが、計算リソースを複数のパーティションに分割し、これらの各々が、実際には別のオペレータにレンタルされる。このモデルは、小規模オペレータが層１オペレータのためのインフラストラクチャを使用している国で関連する可能性がある。

【1144】

ｂ．特定のオペレータに割り振られたパーティション（もしあれば）は、同じタイプの３つの論理パーティション（レベル）に分割することができる。（１）１つのパーティションは、レンタルされることが意図され、又は第三者のサービスプロバイダ、（２）１つのパーティションは、ネットワーク機能（ｖＢＮＧ又はｖＥＰＣなど）を実行するために使用されることが意図され、（３）１つのパーティションは、オペレータが自身の顧客に提供するサービスをホストするために使用されることが意図される。

【1145】

ｃ．レベル２のパーティション（もしあれば）は、Ａｍａｚｏｎ又はＧｏｏｇｌｅなどのサービスプロバイダ（レベル２）にレンタルされることが意図された複数のパーティションに同時に分割することができる。これらのパーティションの各々は、サービスプロバイダが管理し、実質的に所有することができる。例えば、このパーティションでエンドユーザが自身のサービスを実行できるようにするＡｍａｚｏｎ Ｗｅｂ Ｓｅｒｖｉｃｅｓが含まれ、あるいは自身のサービスを公開できるようにするＡｍａｚｏｎ Ｇｒｅｅｎ Ｇｒａｓｓが含まれる。

【1146】

（２）ＴＳＰは、自身のネットワーク機能及びサービスを配備するために使用されるネットワーキングインフラストラクチャ、データセンター、及び計算リソースを所有する。ＣＳＰは、所望のエッジロケーション（基地局、中央局など）に自身のスペースをレンタルし、自身の計算ソリューションを配備する。この態様では、ＴＳＰは、ＣＳＰへのコネクティビティ及びインフラストラクチャを容易にし、ＣＳＰは、そのサービスを配備及び保護するために、サイズ設定されたソリューション及びアーキテクチャを配備することができる。一部のＣＳＰでは、このオプションは、データプライバシー、ＩＰ保護、及び要求される性能を保証するのにより適する。

【1147】

（３）ＣＳＰは、ＴＳＰネットワークインフラストラクチャの外部に配置又はホストされる自身のデータセンターを管理する。この態様では、特定のエッジロケーション（例えば、基地局）は、その特定のデータセンターへの有線の直接接続を有する。

【1148】

図６７は、５Ｇ－ＭＥＣ相互接続を示す。図６７を参照すると、図表６７００は、様々なエッジクラウド（又は、エッジ層）６７１０、６７１２、及び６７１４を示し、これらは全て、モバイルインターネットネットワークなどの通信ネットワーク６７０２を介して相互接続することができる。いくつかの態様では、エッジコンピューティング（及び、ＭＥＣ）はアクセス非依存（agnostic）であり、通信リンクは、１つ以上の無線アクセス技術（Radio Access Technologies、ＲＡＴ）を介してエッジクラウド内のＭＥＣノードと他の無線ノードとの間で確立することができ、該ＲＡＴは、３ＧＰＰ ＬＴＥ、５Ｇ ＮＲ、Ｗｉ－Ｆｉ、又は他のＲＡＴを含み、また、自動車及び他産業のユースケースのような多くの垂直圏（verticals）をカバーする。

【1149】

例えば、エッジクラウド６７１０は、基地局６７２８を介して、アプリケーション６７１６及びサービス６７２２を、ビッグデータネットワーク６７３４（例えば、データレイク（data lake）又はデータウェアハウスから提供される）に関連付けられた１つ以上のネットワークノードに公開する（expose）ことができる。エッジクラウド６７１２は、基地局６７３０を介して、アプリケーション６７１８及びサービス６７２４を、１つ以上のＩｏＴセンサ及びデバイス６７３６に公開することができる。エッジクラウド６７１４は、基地局６７３２を介して、アプリケーション６７２０及びサービス６７２６を、１つ以上のソーシャル及びインターネットデータソース６７３８に公開することができる。いくつかの態様では、基地局６７２８、６７３０、及び６７３２は、５Ｇ－ＮＲを含む異なるＲＡＴに関連付けることができる。

【1150】

いくつかの態様では、通信ネットワーク６７０２は、エッジクラウド６７１０～６７１４のうち１つ以上におけるアプリケーション及びサービスにアクセスし、構成するために、アプリケーションプログラミングインタフェース（ＡＰＩ）６７４２を開発者又は顧客コミュニティ６７４０に提供することができる。

【1151】

ネットワーク非武装地帯（demilitarized zone、ＤＭＺ）６７０８を介して、エッジクラウド６７１０～６７１４で実行されているアプリケーション又はサービスに関連してこれらのクラウドで受信されたネットワークトラフィックはクラウド６７０４にルーティングすることができ、あるいは、データがクラウド６７０４から要求される場合がある。ＤＭＺ６７０８は、境界ネットワーク（perimeter network）又はスクリーンサブネット（screened subnet）と呼ぶことができ、これは、クラウド６７０４及びプライベートクラウド６７０６に対してさらなるセキュリティ層を追加する物理又は論理サブネットワークである。

【1152】

図６８は、全体的な５Ｇ次世代（next generation、ＮＧ）システムアーキテクチャ６８００の簡略化された図である。図６８を参照すると、ＮＧシステムアーキテクチャ６８００は、ＮＧ－ＲＡＮ６８１０と、５Ｇネットワークコア（５ＧＣ）６８２０を含む。ＮＧ－ＲＡＮ６８１０は、次世代ノードＢ（Next Generation Node-Bs、ｇＮＢ）６８２８及びＮＧ進化型ノードＢ（NG Evolved Node-Bs、ＮＧ－ｅＮＢ）６８３０などの複数のノードを含むことができる。

【1153】

５ＧＣ６８２０は、アクセス及びモビリティ機能（access and mobility function、ＡＭＦ）６８３２及び／又はユーザプレーン機能（user plane function、ＵＰＦ）６８３４を含むことができる。ＡＭＦ６８３２及びＵＰＦ６８３４は、ＮＧインタフェースを介してｇＮＢ６８２８及びＮＧ－ｅＮＢ６８３０に通信上結合することができる。より具体的には、いくつかの態様では、ｇＮＢ６８２８及びＮＧ－ｅＮＢ６８３０は、ＮＧ－ＣインタフェースによってＡＭＦ６８３２に、ＮＧ－ＵインタフェースによってＵＰＦ６８３４に接続することができる。ｇＮＢ６８２８及びＮＧ－ｅＮＢ６８３０は、Ｘｎインタフェースを介して互いに結合することができる。

【1154】

いくつかの態様では、ｇＮＢ６８２８は、ＵＥ６８０２に向けてのニューラジオ（new radio、ＮＲ）ユーザプレーン及び制御プレーンプロトコル終端を提供するノードを含むことができ、ＮＧインタフェースを介して５ＧＣ６８２０に接続される。いくつかの態様では、ＮＧ－ｅＮＢ６８３０は、ＵＥ６８０２に向けての進化型ユニバーサル地上波無線アクセス（evolved universal terrestrial radio access、Ｅ－ＵＴＲＡ）ユーザプレーン及び制御プレーンプロトコル終端を提供するノードを含むことができ、ＮＧインタフェースを介して５ＧＣ６８２０に接続される。

【1155】

いくつかの態様では、ＮＧシステムアーキテクチャ６８００は、３ＧＰＰ技術仕様（ＴＳ）２３．５０１（例えば、Ｖ１５．４．０、２０１８－１２）によって提供されるように、様々なノード間の参照ポイントを使用することができる。

【1156】

いくつかの態様では、ｇＮＢ６８２８及びＮＧ－ｅＮＢ６８３０の各々は、基地局、モバイルエッジサーバ（例えば、ＭＥＣホスト）、スモールセル、ホームｅＮＢなどとして実装することができる。

【1157】

いくつかの態様では、５Ｇアーキテクチャにおいてノード６８２８はマスターノード（master node、ＭＮ）であってもよく、ノード６８３０はセカンダリノード（secondary node、ＳＮ）であってもよい。ＭＮ６８２８は、ＮＧ－Ｃインタフェースを介してＡＭＦ６８３２に、ＸＮ－Ｃインタフェースを介してＳＮ６８３０に接続することができる。ＭＮ６８２８は、ＮＧ－Ｕインタフェースを介してＵＰＦ６８３４に、ＸＮ－Ｕインタフェースを介してＳＮ６８３０に接続することができる。

【1158】

図６９は、非ローミング５Ｇシステムアーキテクチャ６９００を示す。図６９を参照すると、参照ポイント表現における５Ｇシステムアーキテクチャ６９００が示される。より具体的には、ＵＥ６９６６は、ＲＡＮ６９６８及び１つ以上の他の５Ｇコア（５ＧＣ）ネットワークエンティティと通信することができる。５Ｇシステムアーキテクチャ６９００は、アクセス及びモビリティ管理機能（ＡＭＦ）６９６２、セッション管理機能（session management function、ＳＭＦ）６９６０、ポリシー制御機能（policy control function、ＰＣＦ）６９５８、アプリケーション機能（application function、ＡＦ）６９６４、ユーザプレーン機能（ＵＰＦ）６９７０、ネットワークスライス選択機能（network slice selection function、ＮＳＳＦ）６９４２、認証サーバ機能（authentication server function、ＡＵＳＦ）６９４４、及び統合データ管理（unified data management、ＵＤＭ）／ホーム加入者サーバ（home subscriber server、ＨＳＳ）６９４６などの複数のネットワーク機能（ＮＦ）を含む。

【1159】

ＵＰＦ６９７０は、ローカルデータネットワーク（ＤＮ）６９７２への接続を提供することができ、これには、例えば、オペレータサービス、インターネットアクセス、又は第三者サービスを含むことができる。ＡＭＦ６９６２は、アクセス制御及びモビリティを管理するために使用することができ、ネットワークスライス選択機能性も含むことができる。ＳＭＦ６９６０は、ネットワークポリシーに従って様々なセッションをセットアップ及び管理するように構成することができる。ＵＰＦ６９７０は、所望のサービスタイプに従って１つ以上の構成で配備することができる。ＰＣＦ６９５８は、（４Ｇ通信システムのＰＣＲＦと同様に）ネットワークスライシング、モビリティ管理、及びローミングを使用してポリシーフレームワークを提供するように構成することができる。ＵＤＭ６９４６は、（４Ｇ通信システムのＨＳＳと同様に）加入者プロファイル及びデータを記憶するように構成することができる。

【1160】

いくつかの態様では、ＵＰＦ６９７０は、Ｎ６インタフェースを介して中央ＤＮ６９７６に接続された別のＵＰＦ６９７４に、Ｎ９インタフェースを介して接続することができる。

【1161】

いくつかの態様では、５Ｇシステムアーキテクチャ６９００は、ＩＰマルチメディアサブシステム（IP multimedia subsystem、ＩＭＳ）６９５０及び複数のＩＰマルチメディアコアネットワークサブシステムエンティティ、例えば、呼セッション制御機能（call session control functions、ＣＳＣＦ）などを含む。より具体的には、ＩＭＳ６９５０はＣＳＣＦを含み、これは、プロキシＣＳＣＦ（Ｐ－ＣＳＣＦ）６９５６、サービングＣＳＣＦ（Ｓ－ＣＳＣＦ）６９５４、緊急（emergency）ＣＳＣＦ（Ｅ－ＣＳＣＦ）（図６９には図示せず）、又は問い合わせ（interrogating）ＣＳＣＦ（Ｉ－ＣＳＣＦ）６９５２として作用することができる。Ｐ－ＣＳＣＦ６９５６は、ＩＭＳ６９５０内のＵＥ６９６６のための最初のコンタクトポイントとなるように構成することができる。Ｓ－ＣＳＣＦ６９５４は、ネットワーク内のセッション状態を処理するように構成することができ、Ｅ－ＣＳＣＦは、緊急リクエストを正しい緊急センター又はＰＳＡＰにルーティングするなどの、緊急セッションの特定の態様を処理するように構成することができる。Ｉ－ＣＳＣＦ６９５２は、オペレータのネットワーク内で、そのネットワークオペレータの加入者又はそのネットワークオペレータのサービスエリア内に現在位置するローミング加入者に向けられた全てのＩＭＳ接続のためのコンタクトポイントとして機能するように構成することができる。いくつかの態様では、Ｉ－ＣＳＣＦ６９５２は、別のＩＰマルチメディアネットワーク６９７８、例えば、異なるネットワークオペレータによって運用されるＩＭＳに接続することができる。

【1162】

いくつかの態様では、ＵＤＭ／ＨＳＳ６９４６は、アプリケーションサーバ６９４８に結合することができ、これは、電話アプリケーションサーバ（telephony application server、ＴＡＳ）又は別のアプリケーションサーバ（ＡＳ）を含むことができる。ＡＳ６９４８は、Ｓ－ＣＳＣＦ６９５４又はＩ－ＣＳＣＦ６９５２を介してＩＭＳ６９５０に結合することができる。

【1163】

いくつかの態様では、５Ｇシステムアーキテクチャ６９００は、全てのネットワークにわたって共通である、アクセスカテゴリの最低限のデフォルトセットによってカテゴリ分けすることができるアクセスカテゴリに基づいて、５Ｇアクセス制御メカニズム手法を使用するように構成することができる。この機能性は、公衆陸上移動体ネットワーク（public land mobile network、ＰＬＭＮ）例えば訪問（visited）ＰＬＭＮ（ＶＰＬＭＮ）などが異なるタイプの登録試行に対してネットワークを保護することを可能にし、ローミング加入者に対して受け入れ可能なサービスを可能にし、ＶＰＬＭＮが特定の基本サービスを受けることを目的としたアクセス試行を制御することを可能にすることができる。それはまた、オペレータ特有の方法で構成及び使用できるアクセスカテゴリのセットを提供することにより、個々のオペレータにより多くのオプションと柔軟性を提供する。

【1164】

参照ポイント表現は、対応するＮＦサービス間にインタラクションが存在し得ることを示す。例えば、図６９は、以下の参照ポイントを示している。Ｎ１（ＵＥ６９６６とＡＭＦ６９６２との間）、Ｎ２（ＲＡＮ６９６８とＡＭＦ６９６２との間）、Ｎ３（ＲＡＮ６９６８とＵＰＦ６９７０との間）、Ｎ４（ＳＭＦ６９６０とＵＰＦ６９７０との間）、Ｎ５（ＰＣＦ６９５８とＡＦ６９６４との間）、Ｎ６（ＵＰＦ６９７０とＤＮ６９７２との間）、Ｎ７（ＳＭＦ６９６０とＰＣＦ６９５８との間）、Ｎ８（ＵＤＭ６９４６とＡＭＦ６９６２との間）、Ｎ９（ＵＰＦ６９７０とＵＰＦ６９７４との間）、Ｎ１０（ＵＤＭ６９４６とＳＭＦ６９６０との間）、Ｎ１１（ＡＭＦ６９６２とＳＭＦ６９６０との間）、Ｎ１２（ＡＵＳＦ６９４４とＡＭＦ６９６２との間）、Ｎ１３（ＡＵＳＦ６９４４とＵＤＭ６９４６との間）、Ｎ１４（２つのＡＭＦ６９６２の間）、Ｎ１５（非ローミングシナリオの場合にはＰＣＦ６９５８とＡＭＦ６９６２との間、又はローミングシナリオの場合には訪問ネットワークとＡＭＦ６９６２との間）、Ｎ１６（２つのＳＭＦ６９６０の間、図示せず）、及びＮ２２（ＡＭＦ６９６２とＮＳＳＦ６９４２との間）。図６９に示されていない他の参照ポイント表現も使用することができる。

【1165】

図７０は、５Ｇサービスベースのアーキテクチャ７０００及び汎用的なＭＥＣアーキテクチャ７０９０を示す。５Ｇシステムアーキテクチャ７０００は、サービスベースの表現で示され、図６９のシステムアーキテクチャ６９００と実質的に類似（又は同じ）であり得る。例えば、５Ｇシステムアーキテクチャ７０００は、システムアーキテクチャ６９００にも現れる以下のエンティティ、すなわち、ＮＳＳＦ７０１６、ＰＣＦ７０２２、ＵＤＭ７０２４、ＡＦ７０２６、ＡＵＳＦ７０１０、ＡＭＦ７０１２、ＳＭＦ７０１４、ＵＥ７００２、ＲＡＮ７００４、ＵＰＦ７００６、及びＤＮ７００８を含む。これらのネットワークエンティティに追加で、５Ｇシステムアーキテクチャ７０００は、ネットワーク公開機能（network exposure function、ＮＥＦ）７０１８及びネットワークリポジトリ機能（network repository function、ＮＲＦ）７０２０をさらに含む。いくつかの態様では、５Ｇシステムアーキテクチャは、サービスベースとすることができ、ネットワーク機能間のインタラクションは、（図７０に示されるように）対応するポイントツーポイント参照ポイントＮｉによって、又は（図６９に示されるように）サービスベースのインタフェースとして表現することができる。

【1166】

参照ポイント表現は、対応するＮＦサービス間にインタラクションが存在し得ることを示す。例えば、５Ｇシステムアーキテクチャ７０００は、以下の参照ポイントで構成することができる。Ｎ１（ＵＥ７００２とＡＭＦ７０１２との間）、Ｎ２（ＲＡＮ７００４とＡＭＦ７０１２との間）、Ｎ３（ＲＡＮ７００４とＵＰＦ７００６との間）、Ｎ４（ＳＭＦ７０１４とＵＰＦ７００６との間）、Ｎ５（ＰＣＦ７０２２とＡＦ７０２６との間、図示せず）、Ｎ６（ＵＰＦ７００６とＤＮ７００８との間）、Ｎ７（ＳＭＦ７０１４とＰＣＦ７０２２との間、図示せず）、Ｎ８（ＵＤＭ７０２４とＡＭＦ７０１２との間、図示せず）、Ｎ９（２つのＵＰＦ７００６の間）、Ｎ１０（ＵＤＭ７０２４とＳＭＦ７０１４との間、図示せず）、Ｎ１１（ＡＭＦ７０１２とＳＭＦ７０１４との間、図示せず）、Ｎ１２（ＡＵＳＦ７０１０とＡＭＦ７０１２との間、図示せず）、Ｎ１３（ＡＵＳＦ７０１０とＵＤＭ７０２４との間、図示せず）、Ｎ１４（２つのＡＭＦ７０１２の間、図示せず）、Ｎ１５（非ローミングシナリオの場合にはＰＣＦ７０２２とＡＭＦ７０１２の間、又はローミングシナリオの場合には訪問ネットワークのＰＣＦ７０２２とＡＭＦ７０１２との間、図示せず）、Ｎ１６（２つのＳＭＦ７０１４の間、図示せず）、及びＮ２２（ＡＭＦ７０１２とＮＳＳＦ７０１６の間）。図７０に示されていない他の参照ポイント表現も使用することができる。

【1167】

いくつかの態様では、図７０に示すように、サービスベースの表現を使用して、他の許可されたネットワーク機能がそれらのサービスにアクセスすることを可能にする制御プレーン内のネットワーク機能を表現することができる。これに関して、５Ｇシステムアーキテクチャ７０００は、以下のサービスベースのインタフェースを含むことができる。Ｎａｍｆ７０４２（ＡＭＦ７０１２によって提示されるサービスベースのインタフェース）、Ｎｓｍｆ７０４４（ＳＭＦ７０１４によって提示されるサービスベースのインタフェース）、Ｎｎｅｆ７０３０（ＮＥＦ７０１８によって提示されるサービスベースのインタフェース）、Ｎｐｃｆ７０３４（ＰＣＦ７０２２によって提示されるサービスベースのインタフェース）、Ｎｕｄｍ７０３６（ＵＤＭ７０２４によって提示されるサービスベースのインタフェース）、Ｎａｆ７０３８（ＡＦ７０２６によって提示されるサービスベースのインタフェース）、Ｎｎｒｆ７０３２（ＮＲＦ７０２０によって提示されるサービスベースのインタフェース）、Ｎｎｓｓｆ７０２８（ＮＳＳＦ７０１６によって提示されるサービスベースのインタフェース）、Ｎａｕｓｆ７０４０（ＡＵＳＦ７０１０によって提示されるサービスベースのインタフェース）。図７０に示されていない他のサービスベースのインタフェース（例えば、Ｎｕｄｒ、Ｎ５ｇ－ｅｉｒ、及びＮｕｄｓｆ）も使用することができる。

【1168】

いくつかの態様では、ＮＥＦ７０１８は、ＭＥＣシステム７０９０などのＭＥＣシステム内のＭＥＣホストへのインタフェースを提供することができ、これは、ＲＡＮ７００４との無線接続を処理するために使用することができる。

【1169】

ＭＥＣシステム７０９０は、（システムレベルで動作する）ＭＥＣオーケストレータ７０７０と、分散ホストレベルで動作する以下のＭＥＣエンティティ、すなわち、１つ以上のアプリケーション７０７２、１つ以上のサービス７０７４、仮想化インフラストラクチャ７０７６、ＭＥＣプラットフォーム７０７８、ＭＥＣプラットフォームマネージャ７０８０を含むことができる。ＭＥＣシステム７０９０のコンポーネントは、本明細書で以下でより詳細に論じられる。

【1170】

図７１は、５Ｇネットワーク７１００におけるＭＥＣシステム７１９０の統合ＭＥＣ配備を示し、ＭＥＣシステムの機能エンティティのいくつかが、５Ｇネットワークのネットワーク機能と対話する。図７１を参照すると、ＭＥＣシステム７１９０は、図７０のＭＥＣシステム７０９０のコンポーネント７０７０～７０８０に類似するコンポーネント７１７０～７１８０を含む。同様に、５Ｇネットワーク７１００は、図７０の５Ｇネットワーク７０００のコンポーネント７００２～７０４４に類似するコンポーネント７１０２～７１４４を含む。

【1171】

いくつかの態様では、５Ｇネットワーク７１００内の統合ＭＥＣ配備は、以下の手法のうち１つ以上を使用して構成することができる。

【1172】

（１）ローカルルーティング及びトラフィックステアリング：５Ｇネットワーク７１００は、ＭＥＣシステム７１９０の一部であり得るローカルデータネットワーク（例えば、７１０８）内のアプリケーション７１７２にルーティングすべきトラフィックを選択するように構成することができる。プロトコルデータユニット（protocol data unit、ＰＤＵ）セッションが、データネットワーク７１０８に向けての複数のＮ６インタフェースを有し得る。これらのインタフェースを終端させる（terminate）ＵＰＦ（例えば、７１０６）は、ＰＤＵセッションアンカー（Session Anchor）機能性をサポートするように構成することができる。いくつかの態様では、ＵＰＦ７１０６によるトラフィックステアリングは、ステアリングされるトラフィックに一致するトラフィックフィルタのセット上で動作する上りリンク分類器（Uplink Classifiers）によってか、又は代替的に、複数のＩＰｖ６プレフィックスが問題のＰＤＵセッションに関連付けられているＩＰｖ６マルチホーミングによってサポートされる。

【1173】

（２）オペレータのポリシーに依存して、ＰＣＦ７１２２を介して直接、又はＮＥＦ７１１８を介して間接的に、ＵＰＦ７１０６（再）選択及びトラフィックルーティングに影響を与えるＡＦ７１２６の機能。

【1174】

（３）ＵＥ７１０２及びアプリケーションのモビリティシナリオに対するセッション及びサービス継続（Session and Service Continuity、ＳＳＣ）モード。

【1175】

（４）アプリケーション７１７２が配備されている特定のエリアでローカルエリアデータネットワーク（Local Area Data Network、ＬＡＤＮ）（例えば、７１０８）に接続するためのサポートを提供することによる、５Ｇネットワーク７１００によるＬＡＤＮのサポート。ＬＡＤＮ７１０８へのアクセスは、ＵＥのサービングＰＬＭＮ内のトラッキングエリアのセットとして定義される特定のＬＡＤＮサービスエリアで利用可能であってもよい。いくつかの態様では、ＬＡＤＮ７１０８は、ＵＥのサービングＰＬＭＮによって提供されるサービスとして構成することができる。

【1176】

５Ｇネットワーク７１００内のネットワーク機能及びそれらが生成するサービスは、ＮＲＦ７１２０に登録され、一方で、ＭＥＣシステム７１９０では、ＭＥＣアプリケーション７１７２によって生成されるサービスは、ＭＥＣプラットフォーム７１７８のサービスレジストリに登録される。いくつかの態様では、サービス登録は、アプリケーションイネーブルメント（enablement）機能性の一部であり得る。サービスを使用するために、許可されている場合、ネットワーク機能は、サービスを生成するネットワーク機能と直接対話することができる。利用可能なＭＥＣサービスのリストは、ＮＲＦ７１２０から発見することができる。サービスのいくつかは、ＮＥＦ７１１８を介してアクセス可能であり得、これは、サービスにアクセスするために、ドメインの外部にある信頼されていないエンティティも利用可能である。言い換えれば、ＮＥＦ７１１８は、サービス公開のための集中ポイントとして機能することができ、さらに、システムの外部から発信される全てのアクセス要求を許可することにおいて重要な役割を有する。いくつかの態様では、認証に関連する手順は、認証サーバ機能（ＡＵＳＦ）７１１０によってサービスされ得る。

【1177】

いくつかの態様では、５Ｇネットワーク７１００は、ネットワークスライシングを使用することができ、これは、利用可能なネットワーク機能から、異なるサービス又はサービスを使用しているテナントへの、必要な特徴及びリソースの割り振りを可能にする。ネットワークスライス選択機能（ＮＳＳＦ）７１１６は、ユーザのための適切なネットワークスライスインスタンスの選択を、及び必要なＡＭＦ７１１２の割り振りを支援するように構成することができる。ＭＥＣアプリケーション７１７２、例えば、ＭＥＣシステム７１９０の分散クラウド内でホストされるアプリケーションは、５Ｇネットワーク７１００内に構成された１つ以上のネットワークスライスに属することができる。

【1178】

いくつかの態様では、５Ｇネットワーク７１００におけるポリシー及びルールは、ＰＣＦ７１２２によって処理される。ＰＣＦ７１２２はまた、ＭＥＣプラットフォームなどのＡＦがトラフィックステアリングルールに影響を与えるためにそのサービスを要求する機能でもある。ＰＣＦ７１２２は、ＡＦ７１２６が信頼されているとみなされるか否かと、トラフィックステアリングの場合には、対応するＰＤＵセッションが要求時に既知であるか否かに依存して、直接か又はＮＥＦ７１１８を介してかのいずれかでアクセスすることができる。

【1179】

ＵＤＭ機能７１２４は、ユーザ及びサブスクリプションに関連するサービスを担う。例えば、ＵＤＭ７１２４は、３ＧＰＰ認証及び鍵合意（authentication and key agreement、ＡＫＡ）認証クレデンシャルを生成し、ユーザ識別関連情報を処理し、アクセス許可（例えば、ローミング制限）を管理し、ユーザサービングＮＦ（サービングＡＭＦ７１１２、ＳＭＦ７１１４）を登録し、ＳＭＦ／データネットワーク名（Data Network Name、ＤＮＮ）割り当ての記録を保持することによってサービス継続をサポートし、コンタクトポイントとして作用することによってアウトバウンドローミングにおける傍受手順をサポートし、サブスクリプション管理手順を実行するように構成することができる。

【1180】

ＵＰＦ７１０６は、５Ｇネットワーク７１００における統合ＭＥＣ配備を支援するように構成することができる。いくつかの態様では、ＵＰＦは、ＭＥＣシステム７１９０の観点から、分散及び構成可能データプレーンとみなすことができる。トラフィックルール構成などにおけるそのデータプレーンの制御は、ＮＥＦ－ＰＣＦ－ＳＭＦ通信ルートに従ってもよい。その結果、いくつかの態様では、ローカルＵＰＦ７１０６は、（図７１に示されるように）ＭＥＣ実装の一部であり得る。

【1181】

図７１を参照すると、ＭＥＣオーケストレータ７１７０は、ＭＥＣシステムレベルの機能エンティティであり、これは、ＡＦとして作用し、ＮＥＦ７１１８と、又はいくつかのシナリオでは直接ターゲット５Ｇネットワーク機能（又は、ＮＦ）と対話することができる。ＭＥＣホストレベルでは、ＭＥＣプラットフォーム７１７８は、再度ＡＦの役割において、５Ｇ ＮＦと対話するように構成することができる。いくつかの態様では、ＭＥＣホスト、例えば、ホストレベル機能エンティティは、５Ｇシステム内のデータネットワーク（例えば、７１０８）内に配備されてもよい。５Ｇコアネットワーク機能としてのＮＥＦ７１１８は、類似のＮＦと一緒に中央に配備されるシステムレベルエンティティであるが、いくつかの態様では、ＭＥＣホストからの低待ち時間、高スループットのサービスアクセスを可能にするために、ＮＥＦのインスタンスをエッジに配備することもできる。

【1182】

いくつかの態様では、ＭＥＣは、例えば、５Ｇシステム７１００の外部のデータネットワーク（例えば、７１０８）において、ＵＰＦ７１０６のＮ６参照ポイント上に配備することができる。この機能性は、ＵＰＦを配置する際の柔軟性によって可能にすることができる。いくつかの態様では、分散ＭＥＣホストは、ＭＥＣアプリ７１７２を除いて、ＭＥＣプラットフォームサービス７１７４としてのメッセージブローカと、ローカルアクセラレータへのトラフィックをステアリングする別のＭＥＣプラットフォームサービスを収容することができる。ＭＥＣアプリとして、又はプラットフォームサービスとしてサービスを実行する選択は、実装に特有でもよく、サービスにアクセスするために必要な共有及び認証のレベルを考慮に入れることができる。メッセージブローカなどのＭＥＣサービスは、最初はＭＥＣアプリ７１７２として配備され、次いでＭＥＣプラットフォームサービス７１７４として利用可能になってもよい。

【1183】

いくつかの態様では、ＡＭＦ７１１２は、モビリティ関連手順を処理するように構成される。さらに、ＡＭＦ７１１２は、ＲＡＮ制御プレーン及び非アクセス層（Non-Access Stratum、ＮＡＳ）手順の終端、シグナリングの完全性の保護、登録、接続及び到達可能性の管理、アクセス及びモビリティイベントのための任意の傍受機能とのインタフェース、アクセス層の認証及び許可の提供、及びセキュリティアンカー機能性（Security Anchor Functionality、ＳＥＡＦ）のホスティングの責任を負う。いくつかの態様では、ＡＭＦ７１１２は、他のＮＦに対して通信及び到達可能性サービスを提供するように構成することができ、それは、サブスクリプションがモビリティイベントに関する通知を受信することを可能にし得る。

【1184】

いくつかの態様では、ＳＭＦ７１１４は、セッション管理、ＩＰアドレス割り振り及び管理、動的ホスト構成プロトコル（dynamic host configuration protocol、ＤＨＣＰ）サービス、ＵＰＦの選択／再選択及び制御、ＵＰＦのためのトラフィックルールの構成、セッション管理イベントの傍受、課金、及びローミングのサポートを含む機能性を提供するように構成される。ＭＥＣサービスが、集中型及びエッジ双方のクラウドで提供され得るとき、ＳＭＦ７１１４は、ＵＰＦを選択及び制御するように、及びトラフィックステアリングのためのそのルールを構成するように構成することができる。ＳＭＦ７１１４はさらに、サービス動作を公開して、５Ｇ ＡＦとしてのＭＥＣがＰＤＵセッションを管理し、ポリシー設定及びトラフィックルールを制御し、セッション管理イベントに関する通知をサブスクライブすることができるように構成される。

【1185】

いくつかの態様では、ＭＥＣシステム７１９０のＭＥＣホストは、エッジ内又は中央データネットワーク内に配備される。ＵＰＦ７１０６は、データネットワーク内のターゲットＭＥＣアプリケーションに向けてのユーザプレーントラフィックのステアリングを管理するように構成することができる。データネットワークとＵＰＦのロケーションは、ネットワークオペレータの選択であり、ネットワークオペレータは、利用可能なサイト設備、サポートされるアプリケーションとそれらの要件、測定又は推定されたユーザ負荷などの技術及びビジネスパラメータに基づいて、物理的な計算リソースを配置することを選択してもよい。ＭＥＣホスト及びアプリケーションの動作を調整するＭＥＣ管理システムは、ＭＥＣアプリケーション７１７２をどこに配備すべきかを動的に判断することができる。

【1186】

ＭＥＣホストの物理的な配備の観点で、以下のオプションを異なる態様で使用してもよい。（１）ＭＥＣホストとローカルＵＰＦ７１０６が、基地局エッジ層の基地局とコロケートされる、（２）送信ノードとコロケートされたＭＥＣホストが、ローカルＵＰＦ７１０６を含み得る、（３）ＭＥＣホストとローカルＵＰＦ７１０６が、ネットワーク集約ポイントとコロケートされる、及び（４）ＭＥＣホストが、（例えば、同じデータセンター内の）５Ｇコアネットワーク機能とコロケートされる。

【1187】

図７２は、モバイルエッジシステム参照アーキテクチャ（又は、ＭＥＣアーキテクチャ）７２００を示す。図７２は具体的に、ＥＴＳＩ ＧＳ ＭＥＣ－００３仕様に従って機能性を提供するＭＥＣホスト７２０２及び７２０４を備えたＭＥＣアーキテクチャ７２００を示す。いくつかの態様では、ＭＥＣプラットフォーム７２３２及びＭＥＣプラットフォームマネージャ７２０６への強化が、スライス管理、リソース管理、及びＭＥＣアーキテクチャ７２００内のトレーサビリティ機能を提供するために使用されてもよい。これには、１つ以上のネットワークスライスのプロビジョニング、ネットワークスライスによって使用されるリソースの動的管理、及びＭＥＣアーキテクチャ内のリソーストレーサビリティ機能を含んでもよい。

【1188】

図７２を参照すると、ＭＥＣネットワークアーキテクチャ７２００は、ＭＥＣホスト７２０２及び７２０４、仮想化インフラストラクチャマネージャ（virtualization infrastructure manager、ＶＩＭ）７２０８、ＭＥＣプラットフォームマネージャ７２０６、ＭＥＣオーケストレータ７２１０、オペレーションサポートシステム７２１２、ユーザアプリプロキシ７２１４、ＵＥ７２２０上で動作するＵＥアプリ７２１８、及びＣＦＳポータル７２１６を含むことができる。ＭＥＣホスト７２０２は、フィルタリングルール制御コンポーネント７２４０、ＤＮＳ処理コンポーネント７２４２、サービスレジストリ７２３８、及びＭＥＣサービス７２３６を有するＭＥＣプラットフォーム７２３２を含むことができる。ＭＥＣサービス７２３６は、少なくとも１つのスケジューラを含むことができ、これは、仮想化インフラストラクチャ７２２２上でＭＥＣアプリ（又は、ＮＦＶ）７２２６、７２２７、及び７２２８をインスタンス化するためのリソースを選択するために使用することができる。ＭＥＣアプリ７２２６及び７２２８は、サービス７２３０及び７２３１を提供するように構成することができ、これらは、１つ以上の無線接続（例えば、１つ以上のＲＡＮ又はテレコムコアネットワークエンティティへの接続）に関連付けられた異なるタイプのネットワーク通信トラフィックを処理することを含むことができる。ＭＥＣホスト７２０４内でインスタンス化されたＭＥＣアプリ７２０５は、ＭＥＣホスト７２０２内でインスタンス化されたＭＥＣアプリ７２２６～７７２８と同様であり得る。仮想化インフラストラクチャ７２２２は、ＭＰ２インタフェースを介してＭＥＣプラットフォームに結合されたデータプレーン７２２４を含む。ＭＥＣアーキテクチャ７２００の様々なネットワークエンティティ間のさらなるインタフェースが、図７２に示されている。

【1189】

ＭＥＣプラットフォームマネージャ７２０６は、ＭＥＣプラットフォーム要素管理コンポーネント７２４４、ＭＥＣアプリルール及び要件管理コンポーネント７２４６、及びＭＥＣアプリライフサイクル管理コンポーネント７２４８を含むことができる。ＭＥＣアーキテクチャ７２００内の様々なエンティティは、ＥＴＳＩ ＧＳ ＭＥＣ－００３仕様によって開示される機能性を実行することができる。

【1190】

いくつかの態様では、リモートアプリケーション（又は、アプリ）７２５０は、ＭＥＣオーケストレータ７２１０及びＭＥＣプラットフォームマネージャ７２０６を介してＭＥＣホスト７２０２と（例えば、ＭＥＣアプリ７２２６～７７２８と）通信するように構成される。

【1191】

図７３は、異なるエッジレベルのＭＥＣ配備オプションを有するエッジネットワーク７３００を示す。図７３を参照すると、エッジネットワーク７３００は、コンピューティングデバイス７３０２を含み、これは、エッジ層を介してリモートクラウド７３４４に結合することができ、各層は、異なる配備スケール７３１２で構成される。例えば、コンピューティングデバイス７３０２は、アクセスレベルエッジ７３０４（１００００ｘより大きい配備スケールであり得る）、ローカル／地域レベルエッジ７３０６（１００ｘ～１０００ｘの配備スケールであり得る）、及び全国レベルエッジ７３０８（１０ｘ～１００ｘの配備スケールであり得る）を介して、リモートクラウド７３４４（１ｘ～１０ｘの配備スケールでのグローバルレベルエッジ層であり得る）に結合される。

【1192】

アクセスレベルエッジ７３０４は、マクロ基地局７３１４、リモートラジオヘッド（remote radio heads、ＲＲＨ）７３１６、及びマイクロ基地局７３１８を含むことができ、これらは、１つ以上のＡＰＩ７３２２、７３２４、及び７３２６をそれぞれ使用して、ローカル／地域レベルエッジ７３０６と通信することができる。

【1193】

ローカル／地域レベルエッジ７３０６は、全国レベルエッジ７３０８と通信するために対応するアプリケーション７３３２及び７３３４を使用するネットワークノード７３２８及び７３３０を含むことができる。ネットワークノード７３２８及び７３３０は、（例えば、ＣＤＮサービスのための）トランスポートリソース７３３６のセットアップを実行するように構成することができる。

【1194】

全国レベルエッジ７３０８は、ネットワークノード７３３８を含むことができ、これは、グローバルレベルエッジ７３１０内のリモートクラウド７３４４にアクセスするためのアプリケーション７３４２を使用することができる。ネットワークノード７３３８は、垂直セグメント管理及びＳＬＡ準拠７３４０に対して構成することができる。

【1195】

いくつかの態様では、ＭＥＣの配備は、「エッジ」の定義に基づくことができる。モバイルネットワークオペレータ（mobile network operators、ＭＮＯ）に必要な自由度を提供するために、特に、ＮＦＶ環境でＭＥＣを配備するとき（この態様では、ＭＥＣエンティティは仮想化ネットワーク機能（Virtualized Network Functions、ＶＮＦ）としてインスタンス化することができ、したがって、オペレータのための配備の観点で高い柔軟性を有する）、いくつかのオプションがＭＥＣ標準で認められている。

【1196】

いくつかの態様では、ＭＥＣは、ユースケース／垂直セグメント／処理される情報に依存して柔軟に配備することができる。さらに、ＭＥＣシステムのいくつかのコンポーネントは、システムの他の要素とコロケートすることができる。一例として、特定のユースケース（例えば、エンタープライズ）において、ＭＥＣアプリは、ローカルにＭＥＣサービスを消費する必要がある場合があり、必要なＡＰＩセットをローカルに備えたＭＥＣホストを配備することが、効率的であり得る。他の態様では、（アクセスネットワークから離れていてもよい）データセンターにおけるＭＥＣサーバの配備は、無線ネットワーク情報（radio network information、ＲＮＩ）ＡＰＩ（これは、無線基地局から無線ネットワーク情報を収集するために使用できる）のようないくつかのＡＰＩをホストする必要がない場合がある。一方、ＲＮＩ情報は、集約ポイントにおけるクラウドＲＡＮ（ＣＲＡＮ）環境において精緻化され、利用可能にすることができ、したがって、適切な無線認識トラフィック管理アルゴリズムの実行を可能にする。いくつかの他の態様では、帯域幅管理ＡＰＩは、（例えば、コンテンツデリバリネットワーク（ＣＤＮ）ベースのサービスのための）トランスポートネットワークをセットアップするために、アクセスレベルエッジ７３０４と、さらによりリモートのエッジロケーションとの双方に存在してもよい。

【1197】

図７４は、５Ｇシステムアーキテクチャ７４００におけるＭＥＣサポートを示す。図７４を参照すると、５Ｇシステムアーキテクチャ７４００は、図６９の５Ｇシステムアーキテクチャ６９００と類似している（図７４は、図６９の５Ｇシステムアーキテクチャ６９００によって使用されるネットワーク機能のサブセットのみを示している）。より具体的には、５Ｇシステムアーキテクチャ７４００は、無線アクセスネットワーク（radio access network、ＲＡＮ）７４０８に結合されたＵＥ７４０２を含む。５Ｇシステムアーキテクチャ７４００は、ＡＭＦ７４０４、ＳＭＦ７４０６、ＵＰＦ７４１０、７４１２、及び７４１６をさらに含む。ＵＰＦ７４１２はデータネットワーク７４１４に結合され、ＵＰＦ７４１６はデータネットワーク７４１８に結合される。

【1198】

いくつかの態様では、５ＧネットワークにおいてＭＥＣサポートを提供するために、５Ｇネットワークは、ＵＥに近いＵＰＦを選択し、Ｎ６インタフェースを介してＵＰＦからローカルＤＮへのトラフィックステアリングを実行することができる。５Ｇシステムにおけるエッジコンピューティングをサポートする機能性には、ローカルルーティング（５Ｇコアネットワークが、ユーザトラフィックをローカルＤＮにルーティングするためのＵＰＦを選択する）、トラフィックステアリング（５Ｇコアネットワークが、ローカルＤＮ内のアプリケーションにルーティングされるべきトラフィックを選択する）、ＵＥ及びアプリケーションのモビリティを可能にするためのセッション及びサービス継続、ユーザプレーンの選択及び再選択（例えば、ＡＦからの入力に基づく）、ＡＦがＵＰＦ（再）選択及びトラフィックルーティングに影響を与え得ること、ネットワーク能力公開（５ＧコアネットワークとＡＦが、ＮＥＦを介して互いに情報を提供し得る）、サービス品質（ＱｏＳ）及び課金（ＰＣＦが、ローカルＤＮにルーティングされるトラフィックのＱｏＳ制御及び課金のためのルールを提供するように構成され得る）、ローカルエリアデータネットワーク（Local Area Data Network、ＬＡＤＮ）のサポート（５Ｇコアネットワークが、アプリケーションが配備されている特定のエリアでＬＡＤＮに接続するためのサポートを提供する）が含まれる。

【1199】

いくつかの態様では、５Ｇネットワーク７４００内の統合ＭＥＣ配備は、ローカルルーティング及びトラフィックステアリングを使用して構成することができる。いくつかの態様では、ＵＰＦ７４１０は、上りリンク分類器として構成することができ、ＵＰＦ７４１２及び７４１６は、それぞれ、ＤＮ７４１４及び７４１８との通信（例えば、２つのデータネットワークへの同時アクセス）のためのＰＤＵセッションアンカーとして構成することができる。上りリンク分類器７４１０は、異なるＰＤＵセッションアンカー（例えば、７４１２及び７４１６）に向けての上りリンクトラフィックの転送と、ＵＥ７４０２への下りリンクトラフィックのマージ（例えば、ＵＥ７４０２へのリンク上の異なるＰＤＵセッションアンカーからのトラフィックのマージ）を提供するように構成することができる。

【1200】

５Ｇネットワーク７４００は、ＭＥＣシステムの一部であり得るローカルデータネットワーク（例えば、７４１４）内のアプリケーションにルーティングされるべきトラフィックを選択するように構成することができる。ＰＤＵセッションが、１つ以上のデータネットワーク（例えば、７４１４及び７４１８）に向けての複数のＮ６インタフェースを有することがある。これらのインタフェースを終端させるＵＰＦ（例えば、７４１２及び７４１６）は、ＰＤＵセッションアンカー機能性をサポートするように構成することができる。いくつかの態様では、ＵＰＦ７４１０によるトラフィックステアリングは、ステアリングされるトラフィックに一致するトラフィックフィルタのセット上で動作する上りリンク分類器によってか、又は代替的に、複数のＩＰｖ６プレフィックスが問題のＰＤＵセッションに関連付けられているＩＰｖ６マルチホーミングによってサポートされる。

【1201】

図７５、図７６、及び図７７は、例による、５ＧシステムにおけるＭＥＣマッピングを示す。図７５を参照すると、図７２のＭＥＣアーキテクチャ７２００に類似するＭＥＣアーキテクチャ７５００が示されている。より具体的には、ＭＥＣアーキテクチャ７５００のネットワーク要素７５０２～７５４８は、ＭＥＣアーキテクチャ７２００のネットワーク要素７２０２～７７４８に対応する。

【1202】

図７５は、例示的な５Ｇネットワーク（図６９の５Ｇネットワークアーキテクチャ６９００など）のＵＰＦ７５５０と、ＭＥＣアーキテクチャ７５００へのＵＰＦ７５５０のマッピングをさらに示す。ＵＰＦ７５５０は、ＰＤＵセッションのユーザプレーンパスを処理する。さらに、ＵＰＦ７５５０は、データネットワークへのインタフェースを提供し、ＰＤＵセッションアンカーの機能性をサポートする。この点に関し、３ＧＰＰ（例えば、５Ｇ）アーキテクチャにおけるＵＰＦ７５５０は、ＭＥＣデータプレーン７５２４についてＥＴＳＩで定義された機能性に対応し得る。

【1203】

図７６を参照すると、図７２のＭＥＣアーキテクチャ７２００に類似するＭＥＣアーキテクチャ７６００が示されている。より具体的には、ＭＥＣアーキテクチャ７６００のネットワーク要素７６０２～７６４８は、ＭＥＣアーキテクチャ７２００のネットワーク要素７２０２～７７４８に対応する。

【1204】

図７６は、例示的な５Ｇネットワーク（図７１の５Ｇネットワークアーキテクチャ７１００など）のＡＦ７６５０と、ＭＥＣアーキテクチャ７６００へのＡＦ７６５０のマッピングをさらに示す。ＡＦ７６５０は、以下の高レベルの機能性、すなわち、トラフィックルーティングに対するアプリケーションの影響、ネットワーク能力公開へのアクセス、及びポリシー制御のためのポリシーフレームワークとの対話を実行するように構成される。これに関して、３ＧＰＰ（例えば、５Ｇ）アーキテクチャにおけるＡＦ７６５０は、ＭＥＣプラットフォーム７６３２についてＥＴＳＩで定義された機能性に対応し得る。

【1205】

図７７を参照すると、図７０の５Ｇアーキテクチャ７０００に類似する５Ｇアーキテクチャ７７００が示されている。より具体的には、５Ｇアーキテクチャ７７００のネットワーク要素７７０２～７７４４は、５Ｇアーキテクチャ７０００のネットワーク要素７００２～７０４４に対応する。ＭＥＣホスト７７５０は、５ＧアーキテクチャにおいてＡＦ７７２６及びＵＰＦ７７０６に関連付けられ（又は、マッピングされ）得る（ＡＦ及びＵＰＦは、それぞれ、ＭＥＣプラットフォーム及びＭＥＣデータプレーンに対応する）。さらに、３ＧＰＰアーキテクチャでは、ユーザトラフィックはローカルデータネットワークにルーティングされるため、ＭＥＣアプリは、ＤＮ７７０８に位置するように５Ｇアーキテクチャ７７００にマッピングすることができる。

【1206】

図７８は、例による、５ＧシステムにおけるＭＥＣ配備を示す。より具体的には、図７８は、３ＧＰＰベースの５Ｇシステムアーキテクチャ７８００と、５Ｇシステムのコンポーネントの一部（すなわち、ＡＦ及びＵＰＦ）へのＭＥＣエンティティのマッピングの例を示す。アーキテクチャ７８００は、ＥＴＳＩ ＧＳ ＭＥＣ－００３仕様及び／又はＥＴＳＩ ＧＲ ＭＥＣ－０１７仕様に従った機能性を提供するように構成することができる。

【1207】

図７８を参照すると、５Ｇアーキテクチャ７８００は、ＵＥ７８１０、ＲＡＮ７８０６（これは、ＶＮＦに基づく仮想ＲＡＮであってもよい）、ＵＰＦ７８３６及び７８１８、ＳＭＦ７８１６、ＰＣＦ７８１２、ＡＦ７８０２、ローカルＤＮ７８０４、中央ＤＮ７８２０、及びアプリケーションサーバ７８２２を含む。ＵＰＦ７８３６は、ネットワーク機能仮想化インフラストラクチャ（network function virtualization infrastructure、ＮＦＶＩ）７８０８内でＭＥＣデータプレーンとして機能するように構成することができる。ＡＦ７８０２は、ＭＥＣ ＡＰＩ３２４及び７８２６、ＭＥＣアプリケーションイネーブルメント機能性７８２８（例えば、ＥＴＳＩ ＧＳ ＭＥＣ－０１１仕様に従う）、ＡＰＩ原理（principles）機能性７８３０（例えば、ＥＴＳＩ ＧＳ ＭＥＣ－００９仕様に従う）を有するＭＥＣプラットフォームＶＮＦとして構成することができる。ローカルＤＮ７８０４は、ＶＮＦとしてインスタンス化されたＭＥＣアプリ７８３２及び７８３４を含むことができる。

【1208】

本明細書に開示される手法は、５Ｇネットワークスライシングを効率的にサポートするために、ＭＥＣアーキテクチャで使用することができる。検討される５Ｇ通信システム７８００は、ＥＴＳＩ ＧＳ ＭＥＣ－００３にそのアーキテクチャが規定されているＭＥＣシステムコンポーネントを組み込み、該コンポーネントは、３ＧＰＰ ＴＳ ２３．５０１にそのシステムアーキテクチャが規定されている５Ｇネットワークに配備される。その仮定は、全ての論理機能（例えば、ネットワーク機能（ＮＦ）及びアプリケーション機能（ＡＦ））を仮想化したものとみなすことである。ＭＥＣエンティティの５Ｇシステムへのマッピングを図７８に示す。特に、ＭＥＣプラットフォームは、３ＧＰＰにおける特定のアプリケーション機能（ＡＦ）７８０２として実装され、ＭＥＣアーキテクチャにおけるデータプレーンは、３ＧＰＰにおけるユーザプレーン機能（ＵＰＦ）７８３６に対応し、ＭＥＣアプリ７８３２及び７８３４は、３ＧＰＰにおけるローカルＤＮ７８０４にマッピングされる。

【1209】

いくつかの態様では、出発点は、エンドツーエンド（End-to-End、Ｅ２Ｅ）５Ｇシステム性能が、無線アクセスネットワーク（ＲＡＮ）及びテレコムコアネットワーク（ＣＮ）システムコンポーネント単独の性能だけでなく、ＭＥＣ機能エンティティの性能にも依存することを考慮することである。

【1210】

例：Ｅ２Ｅ待ち時間（例えば、ＵＥとＭＥＣアプリケーションの間）は、パケット遅延バジェット（Packet Delay Budget、ＰＤＢ）（ＵＥとＵＰＦの間のＥ２Ｅ遅延として５Ｇで定義され、９８％の信頼度を有する）と、ＵＰＦとローカルＤＮ（ＭＥＣアプリが位置する）の間のさらなる遅延で構成される。この第２の遅延成分は、３ＧＰＰの５Ｇ ＱｏＳクラス識別子（5G QoS Class Identifier、５ＱＩ）特性では考慮されないが、ＭＥＣアプリケーションのインスタンス化と密接に関係するため、性能最適化のために重要である。結果として、ユーザトラフィック終端ポイントは（ＤＮに位置する）ＭＥＣアプリであるため、ネットワークスライス関連の性能メトリック（ＰＤＢなど）は、全体的なＥ２Ｅ性能を記述するには十分でない。代わりに、ＭＥＣアプリケーションのインスタンス化及び関連する仮想マシン（ＶＭ）割り振りが、スライス要件のとおり、トータルのＥ２Ｅ待ち時間を低減するために慎重に考慮される。

【1211】

いくつかの態様では、所与のネットワークスライスについて、ＭＥＣシステム配備を統合する仮想化５ＧシステムのＥ２Ｅ性能は、５Ｇ ＱｏＳクラス識別子（５ＱＩ）特性（３ＧＰＰによって定義されるように、例えばＵＰＦで終端する）によってのみでは十分に記述することはできないが、ユーザトラフィックがＭＥＣアプリインスタンスで終端するのでＭＥＣシステム性能にも依存する。また、ＭＥＣアーキテクチャエンティティは、Ｅ２Ｅシステム性能が各スライスのニーズに準拠するために、ＵＥ及び５Ｇ仮想化ネットワーク機能（ＶＮＦ）の双方に接続される必要があるため、最適なＭＥＣ配備もまた、ネットワークスライス依存である。

【1212】

いくつかの態様では、ＭＥＣシステムは、スライス認識ストラテジに従って、複数のスライスを収容し、ＭＥＣアプリのインスタンス化及びエッジクラウドにわたるＶＭの割り振りを改善するために、（フルに仮想化された）５Ｇシステムに配備することができる。この割り振りの目的は、スライスのＥ２Ｅ性能要件（これは、ネットワークオペレータと垂直産業との間のサービスレベル合意（ＳＬＡ）の一部であることが仮定される）を満たすことである。

【1213】

課題に対処するための従来の技術：５Ｇネットワークのための３ＧＰＰ標準は、パケットがＵＥとＵＰＦの間で遅延され得る時間の上限としてＰＤＢ（パケット遅延バジェット）を規定しており、したがって、ユーザプレーントラフィックパスの最後の部分（例えば、図７８に示すように、ＵＰＦからＭＥＣアプリへのＮ６インタフェース上）を考慮していない。この点に関し、ＭＥＣアプリが３ＧＰＰネットワークの外部のエンティティであるため、実際のトータルＥ２Ｅ性能を確保するための３ＧＰＰにおける標準の手段／パラメータは依然として存在しない。さらに、特定のネットワークスライスをインスタンス化するとき、５Ｇネットワーク内に配備されるＭＥＣシステムと、スライス特有のＶＭ割り振りを実行し、ＭＥＣ及び３ＧＰＰ関連エンティティ上でハンドオフし、スライス性能に準拠したモビリティ管理を適用する５Ｇネットワークオーケストレータとの間の（論理）インタフェースの標準定義は依然として存在しない。

【1214】

図７９は、ネットワークスライシングに関連して制御ユニット制御プレーン（control unit control plane、ＣＵ－ＣＰ）－制御ユニットユーザプレーン（control unit user plane、ＣＵ－ＵＰ）分離を有する一例示的な５Ｇ－ＮＲアーキテクチャのコンポーネントを示す。図７９を参照すると、５Ｇ－ＮＲアーキテクチャ７９００は、５Ｇコア（５ＧＣ）７９０６及びＮＧ－ＲＡＮ７９０４を含むことができる。ＮＧ－ＲＡＮ７９０４は、１つ以上のｇＮＢ、例えば、ｇＮＢ７９０８及び７９１０を含むことができる。いくつかの態様では、ＮＧ－ＲＡＮ７９０４のネットワーク要素は、中央ユニットと分散ユニットに分割されてもよく、異なるプロトコル機能（例えば、プロトコル層の異なるプロトコル機能）を実行するために、異なる中央ユニットと分散ユニット、又は中央ユニットと分散ユニットのコンポーネントが構成されてもよい。

【1215】

いくつかの態様では、ｇＮＢ７９１０は、ｇＮＢ中央ユニット（gNB Central Unit、ｇＮＢ－ＣＵ）７９２２及びｇＮＢ分散ユニット（gNB Distributed Unit、ｇＮＢ－ＤＵ）７９２４、７９２６のうちの１つ以上を含み、あるいはこれらに分割することができる。さらに、ｇＮＢ７９１０は、ｇＮＢ－ＣＵ－制御プレーン（ｇＮＢ－ＣＵ－ＣＰ）７９２８及びｇＮＢ－ＣＵ－ユーザプレーン（ｇＮＢ－ＣＵ－ＵＰ）７９３０のうちの１つ以上を含み、あるいはこれらに分割することができる。ｇＮＢ－ＣＵ７９２２は、ｇＮＢの無線リソース制御（radio resource control、ＲＲＣ）層、サービスデータ適応プロトコル（service data adaptation protocol、ＳＤＡＰ）層、及びパケットデータ収束プロトコル層（packet data convergence protocol、ＰＤＣＰ）、又は１つ以上のｇＮＢ－ＤＵの動作を制御するＥ－ＵＴＲＡ－ＮＲ ｇＮＢ（ｅｎ－ｇＮＢ）のＲＲＣ及びＰＤＣＰプロトコルをホストするように構成された論理ノードである。ｇＮＢ－ＤＵ（例えば、７９２４又は７９２６）は、ｇＮＢの無線リンク制御層（radio link control、ＲＬＣ）、媒体アクセス制御層（medium access control、ＭＡＣ）、及び物理層（physical、ＰＨＹ）のレイヤをホストするように構成された論理ノードであり、その動作は、少なくとも部分的にｇＮＢ－ＣＵ７９２２によって制御される。いくつかの態様では、１つのｇＮＢ－ＤＵ（例えば、７９２４）が、１つ又は複数のセルをサポートすることができる。

【1216】

ｇＮＢ－ＣＵ－ＣＰ７９２８は、ｅｎ－ｇＮＢ又はｇＮＢのためのｇＮＢ－ＣＵ７９２２のＲＲＣ及びＰＤＣＰプロトコルの制御プレーン部分をホストするように構成された論理ノードである。ｇＮＢ－ＣＵ－ＵＰ７９３０は、ｅｎ－ｇＮＢのためのｇＮＢ－ＣＵ７９２２ＥのＰＤＣＰプロトコルのユーザプレーン部分と、ｇＮＢのためのｇＮＢ－ＣＵ７９２２のＰＤＣＰプロトコルのユーザプレーン部分及びＳＤＡＰプロトコルをホストするように構成された論理（又は、物理）ノードである。

【1217】

ｇＮＢ－ＣＵ７９２２及びｇＮＢ－ＤＵ７９２４、７９２６は、Ｆ１インタフェースを介して通信することができ、ｇＮＢ７９０８は、Ｘｎ－Ｃインタフェースを介してｇＮＢ－ＣＵ７９２２と通信することができる。ｇＮＢ－ＣＵ－ＣＰ７９２８及びｇＮＢ－ＣＵ－ＵＰ７９３０は、Ｅ１インタフェースを介して通信することができる。さらに、ｇＮＢ－ＣＵ－ＣＰ７９２８及びｇＮＢ－ＤＵ７９２４、７９２６は、Ｆ１－Ｃインタフェースを介して通信することができ、ｇＮＢ－ＤＵ７９２４、７９２６及びｇＮＢ－ＣＵ－ＵＰ７９３０は、Ｆ１－Ｕインタフェースを介して通信することができる。

【1218】

いくつかの態様では、ｇＮＢ－ＣＵ７９２２は、ｇＮＢ－ＤＵ７９２４、７９２６に接続されたＦ１インタフェースを終端させ、他の態様において、ｇＮＢ－ＤＵ７９２４、７９２６は、ｇＮＢ－ＣＵ７９２２に接続されたＦ１インタフェースを終端させる。いくつかの態様では、ｇＮＢ－ＣＵ－ＣＰ７９２８は、ｇＮＢ－ＣＵ－ＵＰ７９３０に接続されたＥ１インタフェースと、ｇＮＢ－ＤＵ７９２４、７９２６に接続されたＦ１－Ｃインタフェースを終端させる。いくつかの態様では、ｇＮＢ－ＣＵ－ＵＰ７９３０は、ｇＮＢ－ＣＵ－ＣＰ７９２８に接続されたＥ１インタフェースと、ｇＮＢ－ＤＵ７９２４、７９２６に接続されたＦ１－Ｕインタフェースを終端させる。

【1219】

いくつかの態様では、Ｆ１インタフェースは、エンドポイント間のポイントツーポイントインタフェースであり、エンドポイント間のシグナリング情報の交換とそれぞれのエンドポイントへのデータ伝送をサポートする。Ｆ１インタフェースは、制御プレーン及びユーザプレーンの分離をサポートし、無線ネットワーク層とトランスポートネットワーク層とを分離することができる。いくつかの態様では、Ｅ１インタフェースは、ｇＮＢ－ＣＵ－ＣＰとｇＮＢ－ＣＵ－ＵＰの間のポイントツーポイントインタフェースであり、エンドポイント間のシグナリング情報の交換をサポートする。Ｅ１インタフェースは、無線ネットワーク層とトランスポートネットワーク層とを分離することができ、いくつかの態様では、Ｅ１インタフェースは、ユーザデータ転送に使用されない制御インタフェースであってもよい。

【1220】

ＮＧ－ＲＡＮ７９０４を参照すると、ＮＧ－ＲＡＮ７９０４のｇＮＢ７９０８、７９１０は、ＮＧインタフェースを介して５ＧＣ７９０６と通信してもよく、Ｘｎインタフェースを介して他のｇＮＢと相互接続することができる。いくつかの態様では、ｇＮＢ７９０８、７９１０は、ＦＤＤモード、ＴＤＤモード、又はデュアルモード動作をサポートするように構成することができる。いくつかの態様では、ＥＮ－ＤＣでは、ｇＮＢ－ＣＵとｇＮＢ－ＤＵから構成されるｇＮＢのためのＳ１－ＵインタフェースとＸ２インタフェース（例えば、Ｘ２－Ｃインタフェース）は、ｇＮＢ－ＣＵで終端させることができる。

【1221】

いくつかの態様では、ｇＮＢ７９１０は、ＣＰ／ＵＰ分離をサポートし、単一のＣＵ－ＣＰエンティティ７９２８、複数のＣＵ－ＵＰエンティティ７９３０、及び複数のＤＵエンティティ７９２４、．．．、７９２６を含み、全てのエンティティが、ネットワークスライス動作に対して構成される。図７９に示されるように、各ＤＵエンティティ７９２４、．．．、７９２６は、Ｆ１－Ｃインタフェースを介してＣＵ－ＣＰ７９２８との単一の接続を有することができる。各ＤＵエンティティ７９２４、．．．、７９２６は、Ｆ１－Ｕインタフェースを使用して複数のＣＵ－ＵＰエンティティ７９３０に接続することができる。ＣＵ－ＣＰエンティティ７９２８は、Ｅ１インタフェースを介して複数のＣＵ－ＵＰエンティティ７９３０に接続することができる。各ＤＵエンティティ７９２４、．．．、７９２６は、１つ以上のＵＥに接続することができ、ＣＵ－ＵＰエンティティ７９３０は、ユーザプレーン機能（ＵＰＦ）及び５Ｇコア７９０６に接続することができる。

【1222】

いくつかの態様では、ｇＮＢ７９１０内のエンティティは、ＣＰ／ＵＰの分離を伴うＮＧ－ＲＡＮ７９０４内のインタフェース又は無線ベアラに関連付けられた１つ以上の手順を実行することができる。例えば、ＮＧ－ＲＡＮ７９０４は、５Ｇ及びＭＥＣアーキテクチャ内での動作に関連するネットワークスライス構成に関連付けられた以下の手順をサポートすることができる。

【1223】

Ｅ１インタフェースセットアップ：この手順は、Ｅ１インタフェースのセットアップを可能にし、インタフェース動作に必要なパラメータの交換を含む。Ｅ１セットアップは、ＣＵ－ＣＰ７９２８によって開始される。

【1224】

Ｅ１インタフェースリセット：この手順は、構成パラメータの変更を含むＥ１インタフェースのリセットを可能にする。Ｅ１インタフェースリセットは、ＣＵ－ＣＰ７９２８又はＣＵ－ＵＰ７９３０のいずれかによって開始される。

【1225】

Ｅ１エラー指示：この手順は、１つの入ってくるメッセージに検出されたエラーの報告を可能にする。Ｅ１インタフェースリセットは、ＣＵ－ＣＰ７９２８又はＣＵ－ＵＰ７９３０のいずれかによって開始される。

【1226】

Ｅ１負荷情報：この手順は、ＣＵ－ＵＰ７９２８がＣＵ－ＣＰ７９２８に、支配的な負荷条件を周期的に知らせることを可能にする。同じ手順を、過負荷状態を有するＣＵ－ＵＰ７９３０の示す（開始／停止）ために使用することもできる。

【1227】

Ｅ１構成更新：この手順は、キャパシティ変化などのＣＵ－ＵＰ７９３０構成の更新をサポートする。

【1228】

データ無線ベアラ（Data Radio Bearer、ＤＲＢ）セットアップ：この手順は、ＣＵ－ＣＰ７９２８がＣＵ－ＣＰにＤＲＢをセットアップすることを可能にし、セキュリティ鍵構成と、サービス品質（ＱｏＳ）フロー対ＤＲＢマッピング構成が含まれる。

【1229】

ＤＲＢ修正（modification）：この手順は、ＣＵ－ＣＰ７９２８がＣＵ－ＣＰ内のＤＲＢを修正することを可能にし、セキュリティ鍵構成の修正と、ＱｏＳフロー対ＤＲＢマッピング構成の修正が含まれる。

【1230】

ＤＲＢ解放：この手順は、ＣＵ－ＣＰ７９２８がＣＵ－ＣＰ内のＤＲＢを解放することを可能にする。

【1231】

下りリンクデータ通知（Downlink Data Notification、ＤＤＮ）：この手順は、ＣＵ－ＵＰ７９３０が、ＣＵ－ＣＰ７９２８に、ページング手順をトリガしてＲＲＣ非アクティブ（RRC Inactive）状態をサポートするよう要求することを可能にする。

【1232】

いくつかの態様では、ＮＧ－ＲＡＮ７９０４は、ＣＵ－ＵＰ７９３０からのリソース可用性指示、ＣＵ－ＵＰ７９３０内のリソース管理、及びＣＵ－ＵＰ７９３０からの待ち時間指示を含むネットワークスライシングのためのＥ１インタフェース管理手順をサポートするように構成することができる。

【1233】

いくつかの態様では、ＮＧ－ＲＡＮ７９０４は、ＤＵエンティティ７９２４、．．．８４２６からのリソース可用性指示、ＤＵエンティティ７９２４、．．．、７９２６内のリソース管理、及びＤＵエンティティ７９２４、．．．、７９２６からの待ち時間指示を含むネットワークスライシングのためのＦ１－Ｃインタフェース管理手順をサポートするように構成することができる。

【1234】

いくつかの態様では、ＮＧ－ＲＡＮ７９０４は、Ｆ１－Ｕインタフェース上の待ち時間測定をサポートするように構成することができ、それにより、ＤＵエンティティ（８４２４、．．．、７９２６）及びＣＵ－ＵＰエンティティ７９３０を含むＵＰ要素は、他の近隣ＵＰ要素に待ち時間情報を通信することができる。この点に関して、ネットワークスライシングは、ＣＰ／ＵＰの分離と共にＮＧ－ＲＡＮ７９０４でサポートすることができる。いくつかの態様では、スライスレベルの隔離と改善されたリソース利用率を、ＣＵ－ＣＰ７９２８の中央ＲＲＭによって提供することができる。

【1235】

いくつかの態様では、ネットワークスライシングに関連付けられた手順は、Ｅ１インタフェース、Ｆ１－Ｃインタフェース、及びＦ１－Ｕインタフェースを介した動作及び通信を含む。これらの手順で、ＣＵ－ＣＰ７９２８は、特定のサービスレベル合意（ＳＬＡ）に関連付けられた特定のネットワークスライシング要求をサービスするために、適切なＤＵ及びＣＵ－ＵＰエンティティを選択することができる。

【1236】

いくつかの態様では、Ｅ１インタフェースを介する手順は、ＣＵ－ＵＰエンティティ７９３０からの情報収集とＣＵ－ＣＰ７９２８内のリソース管理を含むことができる。具体的には、情報収集は、リソース可用性指示及び待ち時間指示を含むことができ、一方で、リソース管理は、リソース割り振り及びリソース解放を含むことができる。ＣＵ－ＣＰ７９２８は、ＣＵ－ＵＰエンティティ７９３０から情報を周期的に収集し、又はネットワークスライス要求に基づいてオンデマンドのクエリを発行するように構成することができる。いくつかの態様では、リソース可用性指示手順は、ＣＵ－ＵＰエンティティ７９３０がＣＵ－ＣＰ７９２８に、ネットワークスライシング要求を処理するためのリソースの可用性を知らせることを可能にできる。例えば、利用可能なリソースの指示は、特定のＣＵ－ＵＰが特定のＳＬＡに関連付けられた特定のネットワークスライスの要求をサービスすることができるかどうかをＣＵ－ＣＰ７９２８が判定するのを支援することができる。

【1237】

いくつかの態様では、リソース割り振り手順は、ＣＵ－ＣＰ７９２８が特定のスライスに関連付けられたＣＵ－ＵＰ７９３０内のリソースを割り振ることを可能にできる。ネットワークスライス作成の要求を受信すると、ＣＵ－ＣＰ７９２８は、示されたＳＬＡに従うＣＵ－ＵＰ７９３０（例えば、ＣＵ－ＵＰエンティティの１つ）を選択し、選択したＣＵ－ＵＰ内のリソースをネットワークスライスに割り振ることができる。いくつかの態様では、リソース解放手順は、ＣＵ－ＣＰ７９２８が確立されたネットワークスライスに割り当てられたＣＵ－ＵＰ内のリソースを解放することを可能にできる。スライスを除去すると、ＣＵ－ＣＰ７９２８は、除去されたネットワークスライスによって使用されるリソースを解放するために、対応するＣＵ－ＵＰに通知することができる。

【1238】

図８０は、例示的なネットワークスライス８００８及び８０１０を有する図表８０００を示す。ＲＡＮ８００４は、ＵＥ８００２のための事前構成された隔離されたＲＡＮスライス８００８及び８０１０の間のトラフィックの差別化された処理をサポートすることができる。これをどのように行うかは、実装に任せることができる。ＲＡＮスライスの選択は、デバイス又はテレコムコアネットワークによって提供されるＩＤ（これは、上記で定義されるスライスサービスタイプ及びスライス差別化器（differentiator）であり得る）に基づく。ＲＡＮスライスは、所定のロケーションで利用可能であってもそうでなくてもよい。ＲＡＮは、テレコムコアネットワークスライスを選択する。ＲＡＮスライス内のＱｏＳ差別化も同様にサポートされる。

【1239】

本明細書で用いられるとき、用語「ネットワークスライシング」は、物理ネットワークの、多様な垂直要件セットを満たすようにカスタマイズされた複数の仮想ネットワークへのパーティショニングを指す。ネットワークスライシングは、Ｒｅｌ．１５及びそれ以降に関連する可能性があり、関連する３ＧＰＰ仕様には、ＴＳ２３．５０１（５ＧＳアーキテクチャ）、ＴＳ２２．２６１（５Ｇ要件）、及びＴＳ２８．５３１／２８．５３２（５Ｇスライス管理）が含まれる。

【1240】

図８０を参照すると、共通ネットワーク機能８００６内のネットワークスライス選択機能（ＮＳＳＦ）は、ＵＥ８００２にサービスするためのネットワークスライスインスタンスの選択、許可されたネットワークスライス選択支援情報（Network Slice Selection Assistance Information、ＮＳＳＡＩ）の決定、及びＵＥにサービスするために使用されるＡＭＦセットの決定をサポートする。ＮＳＳＦは、ＥＰＣに存在しない新しい機能性として構成することができる。ネットワークスライステンプレート（Network Slice Template、ＮＳＴ）は、ネットワークスライス情報オブジェクトクラス（Information Object Class、ＩＯＣ）のインスタンスの作成に使用される属性値のサブセットとして定義される。ＮＳＴの内容は、モバイルネットワークオペレータ（ＭＮＯ）とベンダによって定義されるなど、３ＧＰＰによって標準化されない可能性がある。

【1241】

いくつかの態様では、スライス選択は、ＵＥによって送信された支援情報（ＮＳＳＡＩ）を有するネットワークスライスポリシーに基づいて、ネットワーク（ＡＭＦ又はＮＳＳＦ）によって決定される。いくつかの態様では、ＵＥあたり最大８個のネットワークスライスが使用され得る。

【1242】

自動車の例：車両は、複数の自動車ユースケースの異なる性能要件をサポートするために、異なるスライス／サービスタイプ（Slice/Service Type、ＳＳＴ）に属し、かつ対応するデータネットワーク８０１２及び８０１４に接続される、複数のスライスインスタンス８００８及び８０１０に同時に接続される必要があり得る。例えば、ソフトウェア更新及び遠隔操作運転（Tele-Operated Driving）のユースケースは、それぞれ、それらのＫＰＩ要件に基づいてｅＭＢＢスライスとＵＲＬＬＣスライスに関連付けられる場合がある。

【1243】

図８１は、スライス管理、リソース管理、及びトレーサビリティ機能をサポートするＭＥＣネットワークアーキテクチャ８１００を示す。図８１は、具体的には、ＥＴＳＩ ＧＳ ＭＥＣ－００３仕様に従って機能性を提供するＭＥＣホスト８１０２及び８１０４を有するＭＥＣアーキテクチャ８１００を示しており、網掛けブロックは、スライス管理、リソース管理、及びトレーサビリティ機能に関連して本明細書に記載されるＭＥＣアーキテクチャ構成の処理態様を示すために用いられている。具体的には、ＭＥＣプラットフォーム８１３２及びＭＥＣプラットフォームマネージャ８１０６への強化が、ＭＥＣアーキテクチャ８１００内のスライス管理、リソース管理、及びトレーサビリティ機能を提供するために使用され得る。これには、１つ以上のネットワークスライスのプロビジョニング、ネットワークスライスによって使用されるリソースの動的管理、及びＭＥＣアーキテクチャ内のリソースのトレーサビリティ機能が含むことができる。限られた数のＭＥＣのコンポーネント（例えば、サービス、アプリケーション、マネージャ）がここで及び他の図面で示されているが、ＭＥＣの配備は、図示よりもはるかに多くのコンポーネントを含む可能性があることが理解されるであろう。

【1244】

さらなる例では、ＭＥＣアーキテクチャのあらゆるエンティティは、ＬＳＭ又は他のセキュリティポリシーをロードするように備えられ（instrumented）、セキュリティ動作のための強制ポイントとすることができる。動作及び管理エンティティは、リソースがユーザ、作業負荷、テナント、ドメイン、ｕＳｅｒｖｉｃｅ、機能、ホスティング環境に割り振られる様々な方法に従ってＬＳＭのプロビジョニングでタスクを課され（tasked）得る。

【1245】

図８１を参照すると、ＭＥＣネットワークアーキテクチャ８１００は、ＭＥＣホスト８１０２及び８１０４、仮想化インフラストラクチャマネージャ（ＶＩＭ）８１０８、ＭＥＣプラットフォームマネージャ８１０６、ＭＥＣオーケストレータ８１１０、オペレーションサポートシステム８１１２、ユーザアプリプロキシ８１１４、ＵＥ８１２０上で動作するＵＥアプリ８１１８、及びＣＦＳポータル８１１６を含むことができる。ＭＥＣホスト８１０２は、フィルタリングルール制御コンポーネント８１４０、ＤＮＳ処理コンポーネント８１４２、サービスレジストリ８１３８、及びＭＥＣサービス８１３６を有するＭＥＣプラットフォーム８１３２を含むことができる。ＭＥＣサービス８１３６は、少なくとも１つのスケジューラ８１３７を含むことができ、これは、仮想化インフラストラクチャ８１２２上でＭＥＣアプリケーション（又は、ＮＦＶ）８１２６及び８１２８をインスタンス化するためのリソースを選択するために使用することができる。ＭＥＣアプリ８１２６及び８１２８は、サービス８１３０及び８１３１を提供するように構成することができ、これらは、１つ以上の無線接続（例えば、１つ以上のＲＡＮ又はテレコムコアネットワークエンティティへの接続）に関連付けられた異なるタイプのネットワーク通信トラフィックを処理することを含むことができる。

【1246】

ＭＥＣプラットフォームマネージャ８１０６は、ＭＥＣプラットフォーム要素管理コンポーネント８１４４、ＭＥＣアプリルール及び要件管理コンポーネント８１４６、及びＭＥＣアプリライフサイクル管理コンポーネント８１４８を含むことができる。ＭＥＣアーキテクチャ８１００内の様々なエンティティは、ＥＴＳＩ ＧＳ ＭＥＣ－００３仕様によって開示される機能性を実行することができる。

【1247】

いくつかの態様では、ＵＥ８１２０は、ネットワークスライス８１８０の１つ以上を介して、電気通信コアネットワーク８１８２の１つ以上に通信するように構成することができる。いくつかの態様では、電気通信コアネットワーク８１８２は、スライス管理機能（例えば、スライス管理モジュール又はＳＭＭ８１３４によって提供される）を使用してスライス８１８０を動的に構成することができ、これには、スライスをＵＥに動的に割り当てること、スライスをＵＥに再割り当てすること、スライス８１８０の１つ以上によって使用されるリソース（ＭＥＣリソースを含む）を動的に割り振ること又は再割り振りすること、又は他のスライス関連の管理機能が含まれる。スライス管理に関連して実行される機能の１つ以上は、（例えば、ＵＥを介した）ユーザ要求又はサービスプロバイダによる要求に基づいて開始することができる。いくつかの態様では、ネットワークスライス８１８０に関連するスライス管理機能は、ＭＥＣホスト８１０２内のＳＭＭ８１３４、又はＭＥＣプラットフォームマネージャ８１０６（又は、別のＭＥＣエンティティ内のもの）によって提供される、ＭＥＣ対応の５Ｇ配備のためのＥ２Ｅマルチスライスサポート機能によって容易にすることができる。

【1248】

いくつかの態様では、ＳＭＭ８１３４は、ＮＦＶオーケストレータ（ＮＦＶＯ）８１３５内とすることができ、これは、ＭＥＣオーケストレータ８１１０及び他のＭＥＣエンティティに結合することができる。

【1249】

図８２は、ネットワーク機能仮想化（ＮＦＶ）環境におけるＭＥＣ参照アーキテクチャ８２００を示す。ＭＥＣアーキテクチャ８２００は、ＥＴＳＩ ＧＲ ＭＥＣ－０１７仕様に従って機能性を提供するように構成することができる。

【1250】

いくつかの態様では、ＥＴＳＩ ＭＥＣは、図８２に示すようにＮＦＶ環境内に配備することができる。

【1251】

ＭＥＣ参照アーキテクチャ８２００は、モバイルエッジプラットフォーム８２０２、モバイルエッジプラットフォームマネージャ８２１４、データプレーン８２０８、ネットワーク機能仮想化インフラストラクチャ（ＮＦＶＩ）８２１０、仮想ネットワーク機能マネージャ（ＶＮＦＭ）８２２０及び８２２２、及びＮＦＶＯ８２２４、モバイルエッジアプリケーションオーケストレータ（ＭＥＡＯ）８２２６、オペレーションサポートシステム８２２８、ユーザアプリＬＣＭプロキシ８２３０、ＵＥアプリ８２３４、及びＣＦＳポータル８２３２を含む。モバイルエッジプラットフォームマネージャ８２１４は、ＭＥＣプラットフォーム要素管理８２１６と、ＭＥＣアプリルール及び要件管理８２１８を含むことができる。いくつかの態様では、モバイルエッジプラットフォーム８２０２は、ＭＰ３インタフェースを介して別のモバイルエッジプラットフォーム８２０６に結合することができる。

【1252】

いくつかの態様では、ＭＥＣプラットフォーム８２０２は、仮想化ネットワーク機能（ＶＮＦ）として配備される。ＭＥＣアプリケーション８２０４は、ＥＴＳＩ ＮＦＶ管理コンポーネント及び調整（Management and Orchestration、ＭＡＮＯ）コンポーネントに対してＶＮＦのように現れることができる。これは、ＥＴＳＩ ＮＦＶ ＭＡＮＯ機能性の再利用を可能にする。いくつかの態様では、ＭＡＮＯ機能性のフルセットは使用されないことがあり、特定のさらなる機能性が必要とされることがある。このような特定のＭＥアプリケーションは、本明細書で論じられるように「ＭＥアプリＶＮＦ（ME app VNF）」という名前で示される。いくつかの態様では、仮想化インフラストラクチャはＮＦＶＩとして配備され、その仮想化リソースは仮想化インフラストラクチャマネージャ（ＶＩＭ）８２１２によって管理される。そのために、ＥＴＳＩ ＮＦＶインフラストラクチャ仕様、例えば、ＥＴＳＩ ＧＳ ＮＦＶ－ＩＮＦ００３、ＥＴＳＩ ＧＳ ＮＦＶ－ＩＮＦ００４、及びＥＴＳＩ ＧＳ ＮＦＶ－ＩＮＦ００５で定義された手順の１つ以上を使用することができる。

【1253】

いくつかの態様では、ＭＥアプリケーション（又は、アプリ）ＶＮＦ８２０４は個々のＶＮＦのように管理され、ＥＴＳＩ ＮＦＶ ＭＡＮＯによって定義されるように、ＭＥＣ－ｉｎ－ＮＦＶの配備が特定の調整及びライフサイクル管理（Life Cycle Management、ＬＣＭ）タスクをＮＦＶＯ８２２４とＶＮＦＭ機能ブロック８２２０及び８２２２に委任できるようにする。

【1254】

いくつかの態様では、モバイルエッジプラットフォームマネージャ（ＭＥＰＭ）８２１４は、ＬＣＭ部分を１つ以上の仮想ネットワーク機能マネージャ（ＶＮＦＭ）８２２０及び８２２２に委任する「モバイルエッジプラットフォームマネージャ－ＮＦＶ（Mobile Edge Platform Manager - NFV）」（ＭＥＰＭ－Ｖ）に変換することができる。モバイルエッジオーケストレータ（ＭＥＯ）は、ＭＥＣ参照アーキテクチャＥＴＳＩ ＧＳ ＭＥＣ－００３に定義されているように、リソース調整のため、及び１つ以上のＮＦＶネットワークサービス（ＮＳ）としてのＭＥアプリＶＮＦセットの調整のためにＮＦＶＯ８２２４を使用する「モバイルエッジアプリケーションオーケストレータ（Mobile Edge Application Orchestrator）」（ＭＥＡＯ）８２２６に変換することができる。

【1255】

いくつかの態様では、モバイルエッジプラットフォームＶＮＦ、ＭＥＰＭ－Ｖ８２１４、及びＶＮＦＭ（ＭＥプラットフォームＬＣＭ）は、３ＧＰＰ ＴＲ３２．８４２のアンサンブルコンセプトのとおり単一パッケージとして配備することができ、あるいは、ＶＮＦＭはＥＴＳＩ ＧＳ ＮＦＶ－ＩＦＡ００９のとおり汎用ＶＮＦＭ（Generic VNFM）であり、モバイルエッジプラットフォームＶＮＦとＭＥＰＭ－Ｖは単一のベンダによって提供される。

【1256】

いくつかの態様では、ＭＥアプリケーションとＭＥプラットフォームとの間のＭｐ１参照ポイントは、それがＭＥサービスを提供及び／又は消費するアプリケーションでない限り、ＭＥアプリケーションに対して任意とすることができる。

【1257】

いくつかの態様では、ＭＥＡＯ８２２６とＭＥＰＭ－Ｖ８２１４との間のＭｍ３＊参照ポイントは、ＥＴＳＩ ＧＳ ＭＥＣ－００３によって定義されるようにＭｍ３参照ポイントに基づく。ＭＥＰＭ－ＶとＶＮＦＭ（ＭＥアプリケーションＬＣＭ）との間の分割をまかなうために、この参照ポイントに対して変更が構成されてもよい。

【1258】

いくつかの態様では、ＭＥアプリＶＮＦの管理をサポートするために、ＥＴＳＩ ＭＥＣアーキテクチャ及びＥＴＳＩ ＮＦＶアーキテクチャの要素間に、以下の新しい参照ポイント（Ｍｖ１、Ｍｖ２、及びＭｖ３）が導入される。以下の参照ポイントは、既存のＮＦＶ参照ポイントに関連しているが、その機能性のサブセットのみがＥＴＳＩ ＭＥＣに使用される場合があり、拡張が必要な場合がある。Ｍｖ１（この参照ポイントは、ＭＥＡＯとＮＦＶＯとを接続する。ＥＴＳＩ ＮＦＶで定義されているように、Ｏｓ－Ｍａ－ｎｆｖｏ参照ポイントに関連している）、Ｍｖ２（この参照ポイントは、ＭＥアプリＶＮＦのＬＣＭを実行するＶＮＦマネージャをＭＥＰＭ－Ｖに接続して、これらのエンティティ間でＬＣＭ関連の通知を交換できるようにする。ＥＴＳＩ ＮＦＶで定義されているように、Ｖｅ－Ｖｎｆｍ－ｅｍ参照ポイントに関連しているが、可能性として追加物を含んでもよく、Ｖｅ－Ｖｎｆｍ－ｅｍにより提供される全ての機能性を使用しなくてもよい）、Ｍｖ３（この参照ポイントは、ＶＮＦマネージャをＭＥアプリＶＮＦインスタンスに接続して、メッセージ（例えば、ＭＥアプリケーションＬＣＭ又は初期配備特有の構成に関連する）の交換を可能にする。ＥＴＳＩ ＮＦＶで定義されているように、Ｖｅ－Ｖｎｆｍ－ｖｎｆ参照ポイントに関連するが、Ｖｅ－Ｖｎｆｍ－ｖｎｆにより提供される全ての機能性を使用しなくてもよい）。

【1259】

いくつかの態様では、以下の参照ポイントは、ＥＴＳＩ ＮＦＶによって定義されるように使用される。Ｎｆ－Ｖｎ（この参照ポイントは、各ＭＥアプリＶＮＦをＮＦＶＩに接続する）、Ｎｆ－Ｖｉ（この参照ポイントは、ＮＦＶＩとＶＩＭとを接続する）、Ｏｓ－Ｍａ－ｎｆｖｏ（この参照ポイントは、ＯＳＳとＮＦＶＯとを接続する。これは主に、ＮＳ、例えば、サービスを届けるために接続及び調整される複数のＶＮＦを管理するために使用される）、Ｏｒ－Ｖｎｆｍ（この参照ポイントは、ＮＦＶＯとＶＮＦＭとを接続する。これは主に、ＮＦＶＯがＶＮＦ ＬＣＭオペレーションを呼び出すために使用される）、Ｖｉ－Ｖｎｆｍ（この参照ポイントは、ＶＩＭとＶＮＦＭとを接続する。これは主に、ＶＮＦにより必要とされるクラウドリソースを管理するために、リソース管理オペレーションを呼び出すためにＶＮＦＭによって使用される。ＮＦＶベースのＭＥＣ配備では、この参照ポイントは、１：１からＭｍ６に対応することが仮定される）、及びＯｒ－Ｖｉ（この参照ポイントは、ＮＦＶＯとＶＩＭとを接続する。これは主に、クラウドリソース容量を管理するためにＮＦＶＯによって使用される）。

【1260】

図８３は、仮想化ネットワーク機能（ＶＮＦ）としてのＭＥＣプラットフォームの管理を示す。図８３を参照すると、図表８３００は、ＮＦＶ環境におけるＭＥＣ参照アーキテクチャ８２００からの管理コンポーネントを示している。より具体的には、図表８３００は、オペレーションサポートシステム８３０８、ＭＥＰＭ－Ｖ８３０６、モバイルエッジプラットフォーム８３０４、ＮＦＶＩ８３０２、ＮＦＶＯ８３１４、ＶＮＦＭ８３１２、及びＶＩＭ８３１０を示す。

【1261】

いくつかの態様では、ＭＥＰＭ－Ｖ８３０６は、ＭＥプラットフォームＶＮＦ８３０４の要素マネージャ（Element Manager、ＥＭ）として機能するように構成することができる。いくつかの態様では、ＶＮＦマネージャ（ＶＮＦＭ）８３１２は、ＥＴＳＩ ＮＦＶ（例えば、特定ＶＮＦＭ（Specific VNFM）、汎用ＶＮＦＭ）に従って、ＭＥプラットフォームＶＮＦ８３０４のＬＣＭを実行するために使用される。

【1262】

図表８３００は、ＥＴＳＩ ＮＦＶによって定義されるように、管理コンポーネント８３０２～８３１４の間の以下の参照ポイント接続をさらに示す。

【1263】

Ｖｅ－Ｖｎｆｍ－ｅｍ：この参照ポイントは、ＭＥプラットフォームのライフサイクルを管理するＶＮＦマネージャ（ＶＮＦＭ）をモバイルエッジプラットフォームマネージャ－ＮＦＶ（ＭＥＰＭ－Ｖ）に接続する。Ｖｅ－Ｖｎｆｍ－ｅｍ参照ポイントは、ＥＴＳＩ ＮＦＶで定義されるとおりとすることができる。モバイルエッジプラットフォームＶＮＦがネットワーク機能と考えられるため、ＥＴＳＩ ＮＦＶで定義されているＶｅ－Ｖｎｆｍ－ｅｍ手順に何らかの影響があることは予期されない。

【1264】

Ｖｅ－Ｖｎｆｍ－ｖｎｆ：この参照ポイントは、ＭＥプラットフォームのライフサイクルを管理するＶＮＦＭをモバイルエッジプラットフォームＶＮＦに接続する。Ｖｅ－Ｖｎｆｍ－ｖｎｆ参照ポイントは、ＥＴＳＩ ＮＦＶで定義されたとおりとすることができる。モバイルエッジプラットフォームＶＮＦがネットワーク機能と考えられるため、ＥＴＳＩ ＮＦＶで定義されているＶｅ－Ｖｎｆｍ－ｖｎｆ手順に何らかの影響があることは予期されない。

【1265】

Ｎｆ－Ｖｎ：この参照ポイントは、モバイルエッジプラットフォームＶＮＦとＮＦＶＩとを接続する。Ｎｆ－Ｖｉ：この参照ポイントは、ＮＦＶＩとＶＩＭとを接続する。Ｏｓ－Ｍａ－ｎｆｖｏ：この参照ポイントは、ＯＳＳとＮＦＶＯとを接続する。これは主に、ＮＳ、例えば、サービスを届けるために接続及び調整される複数のＶＮＦを管理するために使用される。Ｏｒ－Ｖｎｆｍ：この参照ポイントは、ＮＦＶＯとＭＥプラットフォームのライフサイクルを管理するＶＮＦＭとを接続する。これは主に、ＮＦＶＯがＶＮＦ ＬＣＭオペレーションを呼び出すために使用される。Ｖｉ－Ｖｎｆｍ：この参照ポイントは、ＶＩＭとＭＥプラットフォームのライフサイクルを管理するＶＮＦＭとを接続する。これは主に、ＶＮＦにより必要とされるクラウドリソースを管理するために、リソース管理オペレーションを呼び出すためにＶＮＦＭによって使用される。Ｏｒ－Ｖｉ：この参照ポイントは、ＮＦＶＯとＶＩＭとを接続する。これは主に、クラウドリソース容量を管理するためにＮＦＶＯによって使用される。

【1266】

いくつかの態様では、５Ｇの採用は、複数の仮想ネットワークを物理的（無線及び有線）ネットワークインフラストラクチャの共通セット上で提供、管理、調整、及び運用する能力をＴＳＰに提供する能力に依存する。エンドツーエンドの「スライス」は、物理的な計算及びネットワークリソースを使用して仮想論理ネットワークを刻み出す。各スライスは、キャパシティ、セキュリティレベル、地理的カバレッジ、及び待ち時間を含むサポートされるサービスに関連する性能をサポートするように具体的に構成することができる。スライスには、無線アクセスネットワーク（ＲＡＮ）のワイヤレス無線と、進化型パケットコア（Evolded Packet Core、ＥＰＣ）を含む電気通信システムコアインフラストラクチャと、５Ｇモバイルアプリケーション及びコンテンツがホストされ得るスイッチ及びデータセンターサーバのパーティショニングが含まれた。さらに、５Ｇ ＥＤＧＥデバイスが、サービス待ち時間要件に依存してスライスにさらに含まれてもよい。

【1267】

いくつかの態様では、５Ｇネットワークスライスは、最良のセキュリティ／トレーサビリティを必要とする（半）自律的な車両、遠隔ヘルスモニタリング、ファーストレスポンダアプリケーションから、付加的なリソーストレーサビリティなしでＯＫであり得る階層化されたスマートフォンプラン及びＩｏＴデバイスまで、幅広いアプリケーションをサポートする。

【1268】

いくつかの態様では、開示されたインタラクションを実行するために必要とされる情報要素は、複雑かつ動的であり、アクセス制御されなければならない。それは、（例えば、どのＣＰＵ、メモリ、帯域幅、Ｉ／Ｏ、ストレージシステム、ネットワークノードかを視覚化する）リソースグラフ、どのリソースがどのアクターによって所有されているか、特定のサービスインスタンスへの（リソースの）割り振りの状態として可視化されることがある。しかしながら、セキュリティに関しては、この「グラフ」の全ての部分が各アクターに等しく見えるわけではない。要素は異なるスライスに記憶され、スライスと、ゆえにブロックチェーンの間の通信は、ポリシーと権利設定に基づき、これは、本質的に動的である。いくつかの態様では、本明細書に開示されたＡＩ手法は、リソース提供の移転の要求時のリソース提供の価格を含むネットワークオペレータリソース及び企業ＳＬＡへのＳＬＡインパクトを推論／予測するために使用することができる。

【1269】

本明細書に記載されている機能ユニット又は能力は、それらの実装の独立性をより詳細に強調するために、コンポーネント又はモジュールとして参照又はラベル付けされている場合があることを理解されたい。このようなコンポーネントは、任意の数のソフトウェア又はハードウェア形態によって具現化することができる。例えば、部品又はモジュールは、カスタム超大規模集積（ＶＬＳＩ）回路又はゲートアレイ、論理チップ、トランジスタ、又は他のディスクリートコンポーネントなどの既製の半導体を含むハードウェア回路として実装されてもよい。コンポーネント又はモジュールはまた、フィールドプログラマブルゲートアレイ、プログラマブルアレイ論理、プログラマブル論理デバイスなどのプログラマブルハードウェアデバイスにおいて実装されてもよい。コンポーネント又はモジュールはまた、様々なタイプのプロセッサによる実行のためのソフトウェアにおいて実装されてもよい。実行可能コードの識別されたコンポーネント又はモジュールは、例えば、コンピュータ命令の１つ以上の物理又は論理ブロックを含んでもよく、これらは、例えば、オブジェクト、プロシージャ、又は関数として編成され得る。それにもかかわらず、識別されたコンポーネント又はモジュールの実行可能ファイルは、物理的に一緒に配置される必要はなく、論理的に一緒に結合されたときにコンポーネント又はモジュールを含み、かつコンポーネント又はモジュールの記述された目的を達成する、異なる位置に記憶された異なる命令を含むことができる。

【1270】

実際、実行可能コードのコンポーネント又はモジュールは、単一の命令でも多数の命令でもよく、いくつかの異なるコードセグメント上に、異なるプログラム間に、及びいくつかのメモリデバイス又は処理システムにわたって分散されてもよい。特に、記述されたプロセスのいくつかの態様（コード書き換え及びコード解析など）は、コードが配備されている処理システム（例えば、センサ又はロボットに埋め込まれたコンピュータ内）とは異なる処理システム（例えば、データセンター内のコンピュータ内）で実施されてもよい。同様に、オペレーショナルデータは、本明細書では、コンポーネント又はモジュール内で識別及び図示されることがあり、任意の適切な形態で具現化されてもよく、任意の適切なタイプのデータ構造内に編成されてもよい。オペレーショナルデータは、単一のデータセットとして収集されてもよく、あるいは、異なるストレージデバイスにわたることを含め異なる場所にわたって分散されてもよく、少なくとも部分的には、システム又はネットワーク上の単なる電子信号として存在してもよい。コンポーネント又はモジュールは、受動的でも能動的でもよく、所望の機能を実行するように動作可能なエージェントを含む。

【1271】

ＶＩＩ．例示的なＥＤＧＥコンピューティングの実装

本明細書に記載された方法、システム、及びデバイスの実施形態のさらなる例には、以下の非限定的な実装が含まれる。以下の非限定的な例の各々は、自立していてもよく、あるいは、以下で又は本開示全体を通じて提供される他の例のうち任意の１つ以上を用いて任意の順列又は組み合わせで組み合わせられてもよい。

【1272】

一例示的な実装は、例Ａ１～ＡＡ１１又は本明細書に記載される他の主題事項の動作を呼び出し又は実行するためのそれぞれのエッジ処理デバイス及びノードを含む、エッジコンピューティングシステムである。

【1273】

別の例示的な実装は、例Ａ１～ＡＡ１１又は本明細書に記載される他の主題事項の動作を呼び出し又は実行するように動作可能なクライアントエンドポイントノードである。

【1274】

別の例示的な実装は、例Ａ１～ＡＡ１１又は本明細書に記載される他の主題事項の動作を呼び出し又は実行するように動作可能な、エッジコンピューティングシステム内の又はそれに結合された、集約ノード、ネットワークハブノード、ゲートウェイノード、又はコアデータ処理ノードである。

【1275】

別の例示的な実装は、例Ａ１～ＡＡ１１又は本明細書に記載される他の主題事項の動作を呼び出し又は実行するように動作可能な、エッジコンピューティングシステム内の又はそれに結合された、アクセスポイント、基地局、路側器（road-side unit）、ストリートサイドユニット（street-side unit）、又はオンプレミスユニットである。

【1276】

別の例示的な実装は、例Ａ１～ＡＡ１１又は本明細書に記載される他の主題事項の動作を呼び出し又は実行するように動作可能な、エッジコンピューティングシステム内の又はそれに結合された、エッジプロビジョニングノード、サービスオーケストレーションノード、アプリケーションオーケストレーションノード、又はマルチテナント管理ノードである。

【1277】

別の例示的な実装は、例Ａ１～ＡＡ１１又は本明細書に記載される他の主題事項の動作を呼び出し又は実行するように動作可能な、エッジコンピューティングシステム内の又はそれに結合された、エッジプロビジョニングサービス、アプリケーション又はサービス調整サービス、仮想マシン配備、コンテナ配備、機能配備、及び計算管理を運用するエッジノードである。

【1278】

別の例示的な実装は、例Ａ１～ＡＡ１１又は本明細書に記載される他の主題事項の動作を呼び出し又は実行するように動作可能な、エッジメッシュとして、サイドカーローディングを有するエッジメッシュとして、又はメッシュツーメッシュ（mesh-to-mesh）通信を備えて動作可能なエッジコンピューティングシステムである。

【1279】

別の例示的な実装は、例Ａ１～ＡＡ１１又は本明細書に記載される他の主題事項を使用して、本明細書で論じられるユースケースを呼び出し又は実行するように動作可能な、ネットワーク機能、アクセラレーション機能、アクセラレーションハードウェア、ストレージハードウェア、又は計算ハードウェアリソースの態様を含むエッジコンピューティングシステムである。

【1280】

別の例示的な実装は、例Ａ１～ＡＡ１１又は本明細書に記載される他の主題事項を使用して本明細書で論じられるユースケースを呼び出し又は実行するように動作可能な、クライアントモビリティ、車車間（vehicle-to-vehicle、Ｖ２Ｖ）、車両エブリシング間（vehicle-to-everything、Ｖ２Ｘ）、又は車両インフラストラクチャ間（vehicle-to-infrastructure、Ｖ２Ｉ）のシナリオをサポートし、かつ任意でＥＴＳＩ ＭＥＣ仕様に従って動作するように適合されたエッジコンピューティングシステムである。

【1281】

別の例示的な実装は、例Ａ１～ＡＡ１１又は本明細書に記載される他の主題事項を使用して本明細書で論じられるユースケースを呼び出し又は実行するように動作可能な、３ＧＰＰ ４Ｇ／ＬＴＥ又は５Ｇネットワーク能力に従った構成を含むモバイル無線通信に適合されたエッジコンピューティングシステムである。

【1282】

別の例示的な実装は、例Ａ１～ＡＡ１１又は本明細書に記載される他の主題事項を使用して本明細書で論じられるユースケースを呼び出し又は実行するように動作可能な、エッジコンピューティングネットワーク又はエッジコンピューティングシステムのレイヤにおいて集約ノード、ネットワークハブノード、ゲートウェイノード、又はコアデータ処理ノードとして動作可能、近接エッジ、ローカルエッジ、エンタープライズエッジ、オンプレミスエッジ、近傍エッジ、中間エッジ、エッジ、又は遠方エッジネットワーク層で動作可能、又は共通の待ち時間、タイミング、又は距離特性を有するノードのセット内で動作可能なエッジコンピューティングノードである。

【1283】

別の例示的な実装は、例Ａ１～ＡＡ１１又は本明細書に記載される他の主題事項を使用して本明細書で論じられるユースケースを呼び出し又は実行するためのエッジコンピューティングシステムにおいて動作可能な、能力が実装されたネットワーキングハードウェア、アクセラレーションハードウェア、ストレージハードウェア、又は計算ハードウェアである。

【1284】

別の例示的な実装は、例Ａ１～ＡＡ１１又は本明細書に記載される他の主題事項を使用して、計算オフロード、データキャッシング、ビデオ処理、ネットワーク機能仮想化、無線アクセスネットワーク管理、拡張現実、仮想現実、産業自動化、小売サービス、製造オペレーション、スマートビルディング、エネルギー管理、自律運転、車両支援、車両通信、モノのインターネットのオペレーション、オブジェクト検出、音声認識、ヘルスケアアプリケーション、ゲーミングアプリケーション、又は高速コンテンツ処理（accelerated content processing）のうちの１つ以上から提供されるユースケースを実行するように構成されたエッジコンピューティングシステムである。

【1285】

別の例示的な実装は、１つ以上のプロセッサと、命令を含む１つ以上のコンピュータ読取可能媒体と、を含むエッジコンピューティングシステムの装置であり、該命令は、１つ以上のプロセッサによって実行されたときに１つ以上のプロセッサに、例Ａ１～ＡＡ１１又は本明細書に記載される他の主題事項を使用して本明細書で論じられるユースケースを呼び出させ又は実行させる。

【1286】

別の例示的な実装は、命令を含む１つ以上のコンピュータ読取可能記憶媒体であり、該命令は、エッジコンピューティングシステムの電子デバイスの１つ以上のプロセッサにより命令が実行されると電子デバイスに、例Ａ１～ＡＡ１１又は本明細書に記載される他の主題事項を使用して本明細書で論じられるユースケースを呼び出させ又は実行させる。

【1287】

別の実施例は、例Ａ１～ＡＡ１１又は本明細書に記載される他の主題事項を使用して本明細書で論じられるユースケースを呼び出し又は実行するための手段、論理、モジュール、又は回路を含むエッジコンピューティングシステムの装置である。

【1288】

これらの実装は、特定の例示的な態様を参照して説明されたが、本開示のより広い範囲から逸脱することなく、様々な修正及び変更がこれらの態様になされ得ることは明らかであろう。本明細書に記載される構成及びプロセスの多くは、より大きい帯域幅／スループットを提供するため、及びサービスされているエッジシステムに利用可能にすることができるエッジサービス選択をサポートするために、組み合わせて又は並列実装で使用することができる。したがって、明細書及び図面は、限定的な意味ではなく例示的な意味であるものと見なされるべきである。本明細書の一部を構成する添付の図面は、限定でなく例示として、主題事項が実施され得る特定の態様を示している。図示された態様は、当業者が本明細書に開示された教示を実施可能にするのに十分に詳細に説明されている。これらから、本開示の範囲から逸脱することなく構造的及び論理的置換及び変更を行うことができるように、他の態様が利用され、導き出されてもよい。したがって、この詳細な説明は、限定的な意味で解釈されるべきではなく、様々な態様の範囲は、別記の特許請求の範囲と、そのような請求項が権利を有する同等物の全範囲とによってのみ定義される。

【1289】

本発明の主題事項のこのような態様は、単に便宜のために、かつ複数が実際に開示されている場合に本出願の範囲をいずれかの単一の態様又は発明概念に自発的に限定する意図なく、本明細書において個々に及び／又は集合的に参照されることがある。したがって、特定の態様が本明細書で例示され、説明されているが、同じ目的を達成するために計算されたいずれの配置も、示された特定の態様の代わりにされ得ることを理解されたい。本開示は、様々な態様の任意及び全ての適合又はバリエーションをカバーすることを意図している。本明細書に具体的に記載されていない上記の態様及び他の態様の組み合わせは、上記の記載を検討すると当業者に明らかとなろう。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10A】

【図10B】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21A】

【図21B】

【図21C】

【図22A】

【図22B】

【図22C】

【図22D】

【図23】

【図24】

【図25】

【図26】

【図27】

【図28】

【図29】

【図30】

【図31】

【図32】

【図33】

【図34】

【図35】

【図36】

【図37】

【図38】

【図39】

【図40】

【図41】

【図42】

【図43】

【図44】

【図45】

【図46】

【図47】

【図48】

【図49】

【図50】

【図51】

【図52】

【図53】

【図54】

【図55】

【図56】

【図57】

【図58】

【図59】

【図60】

【図61】

【図62】

【図63】

【図64】

【図65】

【図66】

【図67】

【図68】

【図69】

【図70】

【図71】

【図72】

【図73】

【図74】

【図75】

【図76】

【図77】

【図78】

【図79】

【図80】

【図81】

【図82】

【図83】