未来のオフローディング: 現在のユースケースとシナリオ

自律型の空中配送ドローンが静止した障害物と予測不可能な危険の両方を回避して都市部を移動するためにはどうすればいいのでしょう。人間が直接制御せずにこのような機能を実行するには、画像認識、経路計画、環境マッピングなど、非常に複雑で電力を大量に消費する計算が必要です。安価で軽量になるよう設計された車両でこのような一連のタスクを実行できるものでしょうか。このような車両の特性と要件を考慮したとき、一般的なデスクトップコンピューターを比較対象とすれば、効率をよくするために空中に持ち上げなければならない重量を制限することは明らかです。ドローンは処理能力が高いほど重くなり、運べるペイロードは少なくなります。またここでは処理用の情報を収集するために必要な一連のセンサー、特にカメラやLiDAR（Light Detection and Ranging）は考慮されていません。ドローンのバッテリーとペイロードの限界を考えると、通常はクラウド内のデータセンターのリソースを必要とするほどの計算をどうやって実行しているのでしょうか。

オフローディングシナリオの一例として、都市環境では移動ロボット、自動車や、防犯カメラなどのインフラが計算をクラウドにオフロードし、情報を共有できるようになります。

上述の問いへの回答は、ネットワーク接続とIoT（Internet of Things）の両方に関わります。ドローンから少し離れてみると、建物や電柱に多数のカメラが取り付けられていることがわかります。空を見上げると遠くに小さく見える建物に5Gアンテナが立っているのが見えます。かつてこのようなドローンは、すべてのセンサーと処理を機体上に維持する必要があり、結果として重量、経済的コスト、電力消費が負担となっていましたが、ドローンが利用できるリソースがネットワークに拡張されたことで、デバイス自体の処理負荷は軽減されています。地域の画像を取得したカメラは、最適な性能を得るためにネットワーク経由でそれをドローンに物理的に近い場所にあるローカルエッジのデータセンターに送り、そこで画像が処理されて環境とそこを通過するオブジェクトのモデルが構築されます。ドローンが従来のGPS機器で得た固有の位置データと方向データを送ると、それらが外部カメラから構築された地図と組み合わされます。エッジで走るナビゲーションソフトウェアは、これによって配送先への安全な経路を計算できます。次にその情報が限られた時間内にドローンに送り返され、制御命令に変換されます。

計算負荷の高いタスクをドローンのようなリソースに制約のある車両から移せば、ドローンの移動に合わせてリソースの可用性やネットワーク品質などの要素に応じてエッジロケーション間を移動しつつ、最も効率的な場所でこれらのタスクを実行できます。また事業者は、展開の変更が必要になったときにオフローディングのフレームワークに通知する方法として、単純なSLAs（Service Level Agreements）を必要な性能メトリックに従って柔軟に定義できます。タスクがドローンからリモートで実行されるということは、デバイスを呼び戻さずに機能をその場で調整できることを意味します。しかしこうした処理のすべては、ネットワークが十分に速く応答し、また増加したトラフィックをサポートするのに十分なデータを伝送できる場合にのみ可能となります。厳しい制約がある工場や研究所などの環境ではなく現実世界におけるサービスの計算オフローディングが、5Gと今後の6Gの導入によって現実味を帯びてきた理由がここにあります。

ネットワークの機能が向上するにつれて、ますます多くの計算とセンシングのタスクが車両から移され、配達ドローンが専門の特注車両ではなくサービスドリブンの商品に変わることが予想されます。ソフトウェアドリブンのアプリケーションは車両を超え、ネットワークを中核とするエッジとクラウドに及びます。

オフローディングのユースケース

オフローディングは自律型空中配送ドローンのユースケースで明らかに有益です。しかしオフローディングが他のさまざまなユースケースにも使えるという点にも注目すべきでしょう。

タスクオフローディングの最も有望なユースケース

最も有望なユースケースのカテゴリーには、上の図に示した自動運転車による鉱山検査、工場施設の移動ロボット、公共環境でのサービスロボットなどがあります。これらのユースケースの車両は、現時点では公道ではない場所や工場施設などの限られたエリアで稼働しています。通常これらの動きは非常に遅いため、公道上で自動運転車が直面するような重大な安全上の課題はありません。このようなユースケースで主に考えられているのは、重いコンピューティングの多くをオフロードしてハードウェアのコストとサイズを削減し、バッテリーの寿命を延ばし、保守を容易にすることです。乗用車の運転支援サービス（上の図にも示しています）の場合、安全性の要件により、オフローディングはインフォテインメントアプリケーションでのみ可能です。自律型農機は移動ロボットの場合と同様に、重いコンピューティングの多くをオフローディングすることでより安価な機械を製造する可能性をもたらします。たとえばトラクター自体ではなくエッジまたはクラウド上のソフトウェアを更新するようにすれば、トラクターをより安く製造して長期間使えるようにできます。

二番目の一連のユースケースはXR（eXtended Reality）テクノロジーを使うものです。ドローンや同様の自動ナビゲーション車両の場合、デバイスの移動性がオフローディングの重要な推進要因であることについてはすでに説明しましたが、他の分野のアプリケーションでも、軽量のユーザーデバイスからの計算負荷の移動を活用できます。画像がオーバーレイされたメガネでユーザーデバイスを構成するXRはその顕著な例です。これは一般にきわめて計算集約的な活動です。快適性を確保するためにメガネをできるだけ軽くする必要があることを考えなくてはなりません。ストレージ、計算機能、大容量バッテリーなどあらゆる種類の搭載されたコンピューティングリソースが、着用者に不快感を与えます。

XRデバイスの場合、オンボードセンサーはカメラと場合によってはGPS及び方向を測定するジャイロスコープで構成されます。主なオンボードタスクはネットワーク内で発生する動画ストリーミング、画像レンダリングのデコーディング、ゲームエンジンの処理で構成されます。XRアプリケーションは許容できるユーザーQoE（Quality of Experience）を提供するための遅延要件にきわめて敏感なので、最も論理的なオフローディングサイトは近くのエッジロケーションになります。

XRゲームのオフローディングシナリオの例。XRグラスからクラウドや他のデバイスに計算をオフロードすることでレンダリング機能と操作性を向上できる。

オフローディングは柔軟なメカニズムであり、その実装はユースケースや状況によって異なる場合があります。上記ではオフローディングのコンセプトを自律型空中配送ドローンとXRの二つのユースケースで説明しました。

オフローディングの分類

多種多様なユースケースを考えれば、さまざまなオフローディング構成が可能だと結論付けるのは論理的で、実際にそのとおりです。オフローディングは、特にオフローディングの程度、アーキテクチャー、スケジューリングの観点から、ユースケースの要件を満たすように調整できます。

オフローディングの程度、アーキテクチャー、スケジューリングなどのタスクオフローディング構成

オフローディングの程度とは、アプリケーション内で別のマシンにオフロードされる処理の部分を指します。オフローディングなし、部分オフローディング、完全オフローディングの選択肢があります。アーキテクチャーとは、エッジ、クラウド、エッジとクラウド両方など、処理のオフローディングに利用可能なマシンの性質と場所を指します。スケジューリングとは、オフローディングするタイミングの判断を指します。これは静的に実行でき、オフラインの性能予測とプロファイリングに基づいて事前に定義された設定に従ってシステムが動作します。スケジューリングは、システムがオンライン監視機能を備え、実行するオフローディング設定をその場で決定できる場合、動的に実行することもできます。このためには、アプリケーションがオフローディング処理と非オフローディング処理の両方が実行されている変化する環境を検査し、より最適な方法で実行できる場所に処理を移すサービスにアクセスできなくてはなりません。

結論

私たちの日常生活に存在するさまざまなテクノロジーをオフローディングすることの重要性は明らかです。またユーザー側のハードウェアは単純なもので十分になるので、オフローディングによりユーザー体験が向上し、デバイス関連のコストを削減できます。これらすべてを実現するには、低遅延性と高スループットを提供する安定した通信が必要であることを覚えておくことは重要です。特定のユースケースの通信要件を満たす必要があります。そうでないとタスクがデバイス上で実行され続けることになってしまいます。したがって6Gなどの通信技術の進歩が、オフローディングの可能性を最大限に引き出すための基盤となることでしょう。