SDN に基づくマルチアクセス エッジ コンピューティング (MEC) について話す

データ生成とデータ処理の発展は、基盤となるインフラストラクチャ ネットワークのニーズと進化に大きな影響を与えます。 5G ネットワークは、データ需要を満たすユビキタスな高速接続の先駆けとしてよく見られています。そうは言っても、5G ネットワークはこの約束を果たす上で依然として多くの重大な課題に直面しています。

[[241681]]

ETSI は、これらの課題の一部に対処するために、マルチアクセス エッジ コンピューティング (MEC) を提案しました。この記事では、これらの課題と、MEC にネットワーク プログラマビリティを追加して全体的な MEC ソリューションを改善する方法について説明します。

チャレンジ

IoT デバイスの成長をサポートするには、5G ワイヤレス インフラストラクチャで多数の接続デバイスと複雑なアプリケーションをサポートする必要があります。これには、ネットワークが高スケーラビリティ、超低レイテンシ、高スループット、信頼性の高いデータ転送をサポートする必要があります。これらの重要なレイテンシと帯域幅の要件により、ETSI は、サービスをエッジにプッシュし、エンドユーザーの近くに配置するための実行可能なソリューションとして、マルチアクセス エッジ コンピューティングを提案しました。しかし、このアプローチには独自の課題も伴います。

• クラウド内のハイエンド サーバーと比較すると、MEC サーバーではコンピューティング リソースが制限されています。
• エンドデバイスからの要求の異質性を処理する必要があります。高い計算能力を必要とするものもあれば、より厳しいレイテンシ要件を必要とするものもあります。
• MEC サーバー間の負荷分散が必要になる場合があります。他のサーバーがアイドル状態のときに少数の MEC サーバーの計算能力を消費すると、サービス時間が長くなる可能性があります。

提案された解決策

上記の課題のいくつかに対処するための 1 つの解決策は、システムに MEC コーディネーターを導入することです。 MEC コーディネーターは、利用可能な MEC サーバーと、それらが提供するリソースおよびサービスに関する機能を認識しています。つまり、MEC コーディネーターは、アプリケーションを適切な MEC サーバーに接続する一種のプロキシとして機能します。

MEC コーディネータは、次のようなネットワークの決定からオペレータを分離します。

• MEC サーバーには異なるハードウェア機能がある場合があります。 MEC アプリケーションの特定のインスタンスはどこで実行できますか?
• MEC サーバーには、異なるコンピューティング機能と異なる MEC アプリケーションがある場合があります。特定のクライアント/デバイス要求にはどの MEC サーバーを使用する必要がありますか?

MEC コーディネータは、サーバーの機能、現在の負荷、場所などのさまざまな要素に基づいてこれらの決定を行うことができます。

さらに、MEC コーディネータは、MEC サービスのサービス検出 (サービスのインスタンスを追跡する) とオーケストレーション (サービスのインスタンス化と管理) のニーズに SDN の概念を活用できます。

集中型 SDN コントローラーはネットワークのグローバルビューを持ちます。 MEC コーディネーターを SDN コントローラーと統合して、ネットワークから情報を収集できます。

MEC コーディネータは、MEC サーバーで利用可能なサービスのデータベースを内部的に管理する場合があります。 SDN コントローラを使用して、アプリケーション要求に適切な MEC サーバーを接続できます。たとえば、エンドユーザーは、サービス名を言うだけで顔認識サービスをリクエストできます。 MEC コーディネータは、このサービスを提供する MEC サーバーを識別し、それに応じてネットワークにフローを追加します。

レイテンシー問題の解決

MEC システムの概念の背後にある 2 つの主な動機は、計算のオフロードとレイテンシの削減です。集中型データセンターやパブリッククラウドのレイテンシは非常に高くなります。このため、MEC サーバーはエッジの非常に近くに展開されます。リクエストを処理する場所を決定する前に、MEC コーディネータは、クライアント リクエストのレイテンシ、エネルギー、帯域幅の要件に基づいてインテリジェントな決定を行う必要があります。

レイテンシを削減しようとするときに考慮する必要がある主な考慮事項が 2 つあります。

• このクライアント要求を処理できるクライアントと MEC サーバー間の距離を考慮する必要があります。クライアントと MEC サーバー間の距離は重要な決定要因です。
• 伝送コストをローカル計算コストと比較する必要があります。これは、計算を MEC サーバーに移動するべきか、クライアント上でローカルに処理するべきかを判断するのに役立ちます。

MEC コーディネータは、デバイスのエネルギー消費を最小限に抑え、クライアント要求またはアプリケーションの実行レイテンシ制約 (レイテンシ要件) を満たすソリューションを考案する必要があります。

さらに、アプリケーションの性質、つまり、レイテンシに敏感かどうか（高い応答性が求められるかどうか）や、コンピューティング集約型かどうかも考慮する必要があります。レイテンシに敏感なリクエストは、クライアントに近い MEC サーバー (リソースが少ない場合でも) に移動する必要がありますが、計算集約型のリクエストは、より強力な MEC サーバー (クライアント デバイスから遠い場合でも) をターゲットにします。したがって、同じデバイスからの異なるネットワーク スライスは異なるパスを持ち、異なる MEC サーバーによって処理される可能性があります。

SDNコントローラとMECの統合

MEC ETSI 仕様の最初のバージョンは、仮想化プラットフォーム上の「ネットワーク サービス」として MEC サービスを提供することに重点が置かれているようです。これらのサービスは基本的に、ネットワーク ミドルボックス機能に関連するソフトウェアを実行する VNF の組み合わせです。 NFV プラットフォーム上にソリューションを構築することで、これらの MEC サービスのライフサイクル全体 (インスタンス化、終了、スケーリングなど) を管理できます。 NFV プラットフォームは、MEC サービス上で VNF のサービス チェーンを実装するための VNF 転送グラフもサポートします。

プラットフォームに SDN を追加すると、ネットワークの柔軟性と動的性が向上します。 SDN を使用すると、基盤となるネットワークのグローバル ビューが可能になり、トラフィック ステアリング ルールを適用して複雑なサービス チェーン シナリオを実装できるようになります。相互接続された分散 MEC サーバーのネットワークを管理するために使用できます。

SDN コントローラは、さまざまなシナリオを処理するようにプログラムできる「MEC コーディネーター ノースバウンド アプリケーション」をホストできます。

• MEC サーバー上で実行されているサービス インスタンスを監視して、コンピューティング能力、ストレージ領域、または特定のサービス タイプの観点から、エンド デバイス上のクライアント アプリケーションからの要求を処理するためにどの MEC サーバーを使用できるのかを判断します。
• MEC サーバーの容量と使用率を監視して、サービス インスタンスをインスタンス化するためにどの MEC サーバーを使用するかを決定します。
• 同じサービスのインスタンスを実行している MEC サーバーが複数ある場合、このサービスのエンド デバイス要求を処理するためにどれを選択する必要がありますか?理想的には、リクエストは負荷の少ないサーバーに移動される必要があります。

したがって、MEC コーディネータは、カスタマイズされたノースバウンド アプリケーションがネットワークの動作を定義する SDN アーキテクチャを再利用できます。 SDN コントローラは、これらのアプリケーションがコマンドをトリガーするためのノースバウンド API を提供します。コントローラには、管理対象デバイス (ネットワーク内の OpenFlow スイッチを使用) と通信するサウスバウンド インターフェイス (通常は OpenFlow ベース) もあります。

MEC コーディネータのノースバウンド アプリケーションからのコマンドは、SDN コントローラによって OpenFlow ベースの低層トラフィック制御ルールに変換され、ネットワーク内の MEC サーバーに接続されているか、MEC サーバーの一部として使用されている OpenFlow デバイスに送信されます。これらの OpenFlow ルールは、MEC サーバー上で実行されている「トラフィック オフロード サービス」のルールと統合できます。 「トラフィック オフロード サービス」は、MEC アプリケーションまたは MEC アプリケーションへのトラフィックのルーティングを担当する MEC プラットフォーム サービスです。

***、OpenFlow デバイスのステータスと統計は、SDN コントローラによって MEC コーディネーター アプリケーションに返送できます。これにより、MEC コーディネータはネットワークの全体的なビューと、リンク/MEC サーバーの使用率/負荷を把握できるようになります。

実装の課題

ETSI は、MEC サービスのライフサイクル管理を開始する役割を果たす MEAO (Mobile Edge Application Orchestrator) の概念を導入しました。 SDN コントローラーは、カスタム決定/アルゴリズムに基づいて MEC サーバー上で MEC サービスをトリガーするために、MEAO と統合する必要があります。

SDN コントローラは、MEC サーバー上で実行されるエージェントと統合して、次の機能を実現する必要があります。MEC サーバーの機能を報告する。最新の MEC サーバーを取得するためのクライアント アプリケーション要求を報告します。

UE モビリティを処理すると、設計がより複雑になります。場所が変わると、SDN コントローラはユーザーと MEC サーバー間のルーティング/フロー情報を変更する必要があります。 MEC サーバー上で実行される位置情報サービスは、アクティブなデバイスの位置追跡に使用でき、デバイスの位置情報を送信して SDN コントローラーからのフロー更新をトリガーできます。

MEC サーバー上でさまざまなワークロードを処理する場合、デバイスのサービス継続性を考慮しながら、SDN コントローラーが最適なパスの再計算を試行する必要があるかどうかを判断する必要があります。 SDN コントローラは定期的に MEC サーバーをリロードし、それに応じてフローを更新する場合があります。しかし、デバイスは MEC サーバーの存在を認識しません。デバイスの計算は新しい MEC サーバーに移動されるため、デバイスの運用トラフィックへの影響は許容されません。

結論は

要約すると、SDN は MEC ベースのインフラストラクチャにいくつかの方法で役立ちます。

• 計算負荷分散: OpenFlow 互換サーバーのサウスバウンド インターフェイスを使用して、OpenFlow ベースの統計情報を定期的に収集します。
• よりシンプルなエンド デバイス: ホスト中心のアクセスではなくサービス中心のアクセスをサポートすることで、すべてのサービス インスタンスを SDN コントローラーに登録できます。
• ネットワーク エッジ デバイスの簡単なプラグ アンド プレイ機能: SDN は OpenFlow に大きく依存しており、LLDP/OFDP を使用して新しいデバイスを簡単に検出でき、トラフィック ルールを簡単に更新できます。
• 計算オフロードの意思決定: 集中型 SDN コントローラーは、チャネルの状態、サーバーの負荷などに関する情報をデバイスに提供できます。

したがって、SDN の概念を MEC で使用すると、統合されたコントロール プレーン インターフェイスを提供し、ネットワーク コンテキストまたはデバイス情報を取得し、その後、この情報をネットワーク全体のインテリジェントなトラフィック制御に使用することができます。

元のリンク:

https://www.sdxcentral.com/articles/contributed/enabling-sdn-based-multi-access-edge-computing-systems/2018/08/