HTML5 Webook
109/116

モバイルが基本となるIoTにおいてはバッテリーの持続時間は長いことが望ましく、消費電力は小さくしたい。また、例えば他端末との位置関係を表示する必要がある場合、全ての処理が端末のみでは完結しない。こうした場合、処理全体あるいは一部を端末上ではなくクラウド上で実行する形態を取ることになる。このとき、まず、デバイスが生成するデータをクラウドに送信する際に生じるトラヒックが課題となる。大量数のセンサーを利用した広域のデータ分析が必要なアプリケーションでは、一つひとつのデータ量は小さくとも、クラウドにデータを収集する際、トラヒックの集中により、ネットワーク帯域の不足が生じ得る。また、例えば自動車で映像を取得し、分析するアプリケーションでは、上流ネットワークが無線公衆網となり、取得された映像を全て送信するには通信帯域が足りない場合があり得る。一方、ネットワーク帯域の問題のみならず、クラウドへのデータ送信そのものが問題となることもある。例えば、パーソナルデータを扱うアプリケーションでは、プライバシーポリシー上、統計処理を行わねば組織の外へ送信することが許可されないことがある。この場合、クラウドへセンサーデータをそのまま送信できない。もう1つの大きな課題は、モノとクラウドとの間の物理的距離が長いことに起因する応答遅延の課題である。例えば、ARでは40 ms以内の応答時間が望ましいとされているが、一般にクラウドでは、国内では100 ms以内、国外では通常100〜200 ms程度の伝搬遅延があり、処理遅延を含まない通信遅延だけでも要求される応答時間を超えてしまう。物理的な制御が関わるActuationやAutomationのアプリケーションでは、イベントの発生から実際の制御までの遅延によって、致命的な事故も発生し得る。また、伝搬遅延が大きいと、TCPのように送受信確認がある通信プロトコルでは通信帯域が減少する。こうした課題を解決可能とする方策として、端末上、あるいは、端末に物理的に近いネットワーク装置周辺(エッジ)に、計算処理やデータ保存等を行うリソースを設置し、クラウド上の処理の一部を実行する「階層化クラウドアーキテクチャ」(以下、階層化クラウド)が提唱され、様々な要素技術の研究開発が進められている。図2 は、階層化クラウドのモデルを示している。このようにエッジで計算処理を行うコンピューティング形態はエッジコンピューティング(またはフォグコンピューティング)と呼ばれる。エッジコンピューティングにより、フィルタリング処理や統計処理等を端末に近い位置で行うことが可能となり、クラウドに至る経路で生じるトラヒックの選別や削減が可能となる。また、端末に近い位置にあるストレージや計算リソースを利用できれば、伝搬遅延が削減され、通信帯域や応答性能が向上する。 ETSI(European Telecommunications Standards Institute)ではMEC(Multi-access Edge Computing)の標準化が進められており、公衆無線の基地局に計算処理を行うサーバ等を設置する設計がなされている。2021年には米国で16万以上の5G向けMEC設備が配備され、2026年にはその数は3倍以上に増加するとの予測もある[1]。国内では、NTT未来ねっと研究所がEAWエンジン(Edge Accelerated Web Engine)河川水門河川水門Wide area NW既存のクラウド河川水門河川水門エッジクラウドWide area NWモバイルクラウド階層化クラウドアーキテクチャクラウドクラウド図2 階層化クラウドアーキテクチャ1056-3 IoTエッジコンピューティング技術

元のページ  ../index.html#109

このブックを見る