コンピューティングがネットワークに溶け込む未来〜Multi-access Edge Computing(MEC)の標準化動向概要(2022年1月時点)〜

2024年2月23日追記

Release-18のエンハンスメントで、EDGEAPPのローミングシナリオとEdge Node Sharing（ENS）とい拡張が入りました。

GSMAのOP（Operator Group）で規定されているFederationという仕組みを使っています。

簡単に言ってしまうと、ローミングシナリオでは、各キャリアのECS間の情報交換のインタフェースが、ENSシナリオでは、UEがEASをディスカバリする際に、EESがパートナーのMECサービスプロバイダ上のEAS情報をもてる様な拡張がされています。

以下の記事がシンプルに概要を書いてくれていて参考になります。

2022年2月22日追記
2022年2月22日のOpen Mobile Network Infra Meetup #6にて本記事の内容を発表しました。少し加筆していたりしますので、発表スライドを添付します。

以下、Youtubeです。

1. はじめに

みなさん、こんちには。

本稿では、主に通信キャリアによって提供されるMEC(Multi-access Edge Computing）の
2022年1月時点の標準化動向と関連するオープンソースをご紹介します。

全ての情報を完全に網羅できていないと思いますが、重要そうなトピックのみを纏めてみました。また、オープンソースについてはあえてKubernetesなどの固有のソフトウェアの動向は記載せず、標準化に関係しそうなもののみピックアップしています。特にオープンソースに関して情報が乏しく粒度が荒い箇所が多々ありますので、詳しい方いらっしゃいましたら是非ご連絡頂きたいです！（Updateしていきたいと思います）

尚、本稿では、標準化の最新の仕様書やホワイトペーパーを参考にしています。あえてMandatoryとOptionalの区別をつけずに記載している所があり、記載されている内容が全て商用へ実装されるとは限りませんのでご注意くださいませ。

2. エッジコンピューティングの俯瞰(MECとは)

標準化の話をする前に、簡単にエッジコンピューティングの全体像を俯瞰してみます。

エッジコンピューティングとは、可能な限りデータの生成場所の近くでデータの取得と処理を行う思想を指します。

データ生成場所にコンピューティングを配置することで、

• 帯域幅の増加
• バックホール トラフィックの減少
• 低遅延
• クラウド環境と比較した新しいサービスの見通し、など

が期待されています。

また、現存するソリューション形態として以下のようなさまざまな形態が存在します。

• 1boxソリューション(HWと専用ソフトウェアをbox型で提供)
• システムインテグレーション
• フルマネージド・オンプレミス
• IaaS/PaaS/SaaS…

本稿で記載しているMECとは、通信キャリアのネットワーク上(ネットワークエッジ)に設置されるコンピューティング環境を指します。

MECの他にも、店舗やビル、工場などに設置されるオンプレミス環境であるCustomer EdgeやEnterprise Edge、スマートフォンや車の中に搭載されているECU(electronic control unit)などのデバイスそのもので処理を行うDevice Edgeなど、様々なエッジ環境が存在します。

エッジ環境は配置環境の制約や場所・電源・空調などのファシリティ制約が大きい環境が想定されるため、クラウドを置き換えるものにはならないと考えます。そのため、この様な多様なエッジ環境を、ユースケースや顧客に応じて、クラウドを補完する環境として使い分けていく、という将来像かと思います。

尚、エッジ関連の言葉の定義については、Linux FoundationのLF EdgeのState of Edgeというプロジェクトにて、Open Glossary Projectという形でエッジコンピューティング関連の用語集がまとめられていますので参考にして下さい。

3. MEC関連の標準化団体

MEC関連の標準化団体は以下の3団体が著名です。

ETSI(European Telecommunications Standards Institute)やGSMA(GSM Associate)、3GPP(3rd Generation Partnership Project)は、主に通信キャリアやモバイルネットワークに関連するベンダー企業が主導してMECに関する仕様策定を行い、オープンソースコミュニティにて実装や検証を行う分担で推進されています。

オープンソースはLinux Foundationのエッジコンピューティング関連のプロジェクトをまとめるLF Edgeや、ネットワーク関連のオープンソースを検討するLF Networking、Kubernetes等で著名なCNCF(Cloud Native Computing Foundation)等、様々なコミュニティと連携して標準化仕様を参考にした実装や検証が行われています。

尚、Kubernetesのエッジ関連のプロジェクトであるKubeEdgeなどは必ずしも標準化を意識したものではありませんが、KubeEdgeのユースケースの1つがMEC、という様な感じでしょうか。

4. ETSI MECリファレンスアーキテクチャ¹

ETSIの規定したMECのリファレンスアーキテクチャを以下に示します。

MECのリファレンスアーキテクチャは、MEC自体が通信キャリアのモバイルネットワーク内へ張り出されるコンピューティング環境をコンセプトとして検討されていた点と、当時モバイルネットワーク機能の仮想化を実現するNFV(Network Function Virtualization)が推進されていた背景から、かなりNFVのリファレンスアーキテクチャに似たものになっています。

以下、それぞれのコンポーネントの概要を簡単に記載します。

ME(Mobile Edge) host

• 各通信キャリアのネットワークに接続される仮想化基盤
• ME host上にME(Mobile Edge) appが実行される

VIM(Virtualization Infrastructure manager)

• 仮想化基盤であるME hostを管理する
• 具体的には、ME hostのハードウェアリソースやME host上のアプリケーションのライフサイクルマネジメントなど

MEP(Mobile edge platform)

• ME hostへdeployされるプラットフォーム機能
• ME appへのトラフィック制御、DNSの制御(ローカルDNS等)、APIなどを提供
• APIには、無線のコンテキスト情報を提供するRNIS(Radio Network Information Service) APIや端末の位置情報を提供するLocation API等が規定

MEPM(Mobile edge platform manager)

• ME appのライフサイクルマネジメントや構成管理などを担当
• ME app関連のイベントをMobile edge orchestratorへ通知して、ME appをdeployする、等
• ME appのルールと要件の管理（認可、トラフィックルール、DNS設定、など）
• VIMから仮想化基盤の障害レポートやパフォーマンス値を受信し、何かしら処理する、等

※NFVにおけるVNFM(Virtual Network Function Manager)的なポジション？

Mobile Edge orchestrator

• モバイルネットワーク上に分散配置されたME hostやME appを管理する単一のコントロールプレーン
• MEC全体のリソースの管理、User app LCM proxyを介して端末上のアプリケーションからAPIリクエストを受信し、端末の位置情報などに基づいてME appの再配置等を実施
• OSS(Operations Support System)へのAPIも提供

5. GSMA OP(Operator Platform)²

GSMAは、OP(Operator Platform)という、5G時代のアプリケーション開発者をターゲットとした通信キャリア(Operator)の提供するMECやスライスなどの通信プラットフォームの相互接続に関する仕様を検討しています。

OPの主目的は、通信キャリアがAmazonやGoogle等のハイパースケーラーやサービスプロバイダーとコラボレーションしやすくするための共通のFederation Interfaceの標準化です。つまり、例えば、アプリケーション開発者が通信キャリア横断でMECを単一プラットフォームとして利用できるようにするための枠組みを検討しています。

さらに、TEC(Telco Edge Cloud) Forum Initiativeが、主要な通信キャリアやアプリケーション開発者によるOPのトライアルやPOCをサポートしています。

この背景には、例えば、欧州等の地続きの環境でコネクテッドカーなどのV2X(Vehicle 2 X)を提供した際、国を跨ぐと通信キャリアが変わってしまい、適切な経路でME appを提供できない、という課題があります。
MECが通信キャリアごとに提供されると、V2Xだけでなく、例えばコンシューマユーザ向けに提供されるARやVR、ゲームなどのアプリケーション開発者にとっては、通信キャリアごとにMECを契約して通信キャリア横断のアプリケーションサービスを提供する必要が出てきます。その煩雑さを解消するためのプラットフォームとしてOPがあり、OPによるグローバルの通信キャリア間のMECのFederationによって形成されるクラウドをTelco Edge Cloudとして推進しています。

OPの実装としては、通信キャリアのMECのFederationを実現するSaaSとして、ドイツテレコムの立ち上げたスタートアップであるMobiledgeXが知られています。

MobiledgeXは、各通信キャリアのMECのVIMのAPI(Openstack API, vSphere API, Anthos APIなど)を抽象化し、アプリケーション開発者がMobiledgeXの提供する単一のAPIで各通信キャリアのMECを利用可能とするCRM(Cloudlet Resource Manager)と、iOS/Android SDKとして提供され、端末側のGPSで測位した位置情報を元に近いME appの宛先URLを返却するDME(Distributed Matching Engine)を提供しています。GSMAやETSIなどの標準化、LF EdgeやCNCFなどのオープンソースコミュニティへも活発に参加し、アプリケーション開発者、通信キャリア、デバイスメーカー、クラウドプロバイダーとのエンゲージメントを高めています。

国内においても、下記のプレスリリースにあるようにNTTドコモやKDDI、ソフトバンクがMobiledgeXと連携したPoCを実施しています。

KDDIは上述のGSMA TEC Forum Initiative傘下のTECトライアルにて開発したAPIを以下のサイトにて公開しています。

MobiledgeXは2024年2月現在、Googleに買収され、オープンソース化と言う名の元で会社自体がなくなりました。以下のGitにコードが公開されています。

6. 3GPP　5GC Architecture³

3GPPでは主にモバイル端末がMECへ接続する際のアクセス制御に関する標準化が行われていましたが、Release.17にて5GCの提供するAPIとエッジアプリケーションの連携により端末のモビリティに対応したアプリケーションの提供をサポートしています。

3GPPのMECの標準化について紹介する前に、まずは5GCのアーキテクチャを以下に示します。

そもそも5GCって？という方は以下の記事が参考になりますのでご参照ください。

MEC観点での5GCの最大の特徴は、通信制御を担うControl Planeとデータ転送を担うUser Planeが分離したCU分離のアーキテクチャである点です。つまり、User Planeが完全にControl Planeと分離したアーキテクチャにより、User Planeの配置場所を柔軟に設計でき、トポロジ変更の柔軟性の向上がMEC観点で大きな進歩であると考えます。

一方、Control PlaneはSBA(Service-Based Architecture)で規定され、Control Planeの機能間の連携インタフェースについても従来3GPPで使用されていたDiameterなど重たいプロトコルでなく、HTTPが使用されます。一部のネットワーク機能はNEF(Network Exposure Function)によりAPIとして公開され、ITアプリケーションが5GCのAPIを実行して通信制御を行う、といったユースケースを考えやすくなりました。

５GCのAPIは以下のGitHubにて公開されていますので参考にして下さい。

５GCをオープンソース実装するプロジェクトも存在しています。
標準化された仕様がどの様な実装になるのか学習する上で有益ですので、リンクを張っておきます。

6-1. MECを配置する場所

5GCのアーキテクチャにおいて、MECはUser Plane処理を担うUPF(User Plane Function)のリア側のDN(Data Network)に配置されます。DNとは端末が接続するネットワークを指し、例えばInternetや閉域網など様々です。

5GCでは従来の4GにおけるPGWに該当するUPFを以下の図のように多段配置し、特定の通信を抜き出し(ローカルブレイクアウト)して、異なるDNへ接続制御する、といったことが可能になりました。

7. 端末が移動した時のPDUセッションの扱いの課題

モバイル端末がMECへアクセスする際に課題となるのが、端末とUPFとの間で張られるセッションの扱いです。

4Gまでは、サーバアプリケーションがクラウドなどの環境に集約されている構成を基本として、端末が移動してもセッションを維持しする仕様としていました。

この仕様のままMECへ適用しようとすると、仮にMECを分散配置したとしても、端末移動時のトラフィックルートが最適化できません。
例えば東京・福岡にそれぞれMECが存在し、東京に在圏していた端末が新幹線や飛行機で福岡に移動した時に、福岡から福岡のMEC宛に接続しようとしても、東京経由で迂回して接続する経路になってしまいます。

8. SSC(Session and Service Continuity)

そこで、3GPP Release.15にてSSC(Session and Service Continuity)という端末-UPF間のセッションとサービスの継続性に関する仕様が標準化されました。

SSCには3種類のモードがあり、端末がセッション確立する際に指定されます。
詳細な情報は以下の記事が参考になります。

9. その他MEC関連の技術

9-1. ULCL(Uplink Classifier)

ULCL(Uplink Classifier)とは、特定の条件に合致した通信のみを抜き出して異なるDNへ接続させる技術です。
端末とUPFとのセッション間に、分岐点となるUPF(I-UPF: Intermediate UPF　とも呼びます)を挿入し、5-tuple(送信元/宛先IPアドレスやポート番号など)情報をもとにフィルタリングしてLocal DNに接続するUPFへ接続制御します。

PDUセッションはSMF(Session Management Function)が管理し、端末上のアプリケーションがどのPDUセッションを使用するか、どのDNに接続するかを、取得したDNAI(Data Network Access Identifer)を元に制御します。また、SMFは分岐点となるUPFを挿入・削除・変更し、ルーティング制御を行います。

尚、同じ目的の方式として、IPv6 Multihomingによる方式も規定されています。(IPv6 Multihomingの場合は端末へ新しいIPv6プレフィックスを付与し、端末IPアドレスを元に接続先を振り分けるイメージになります)

9-2. AF Influence on traffic routing⁴

上述のNEFが公開するAPIとしてTraffic InfluenceAPIというものが存在します。このAPIを使用するとサーバアプリケーションに相当するAF(Application Function)からULCLの制御に必要なプロビジョニングを行うことができます。

例えば、端末が移動して近いLocal DNが変わった時に、そのDN上にあるMECへ新規アプリケーションをdeployして、ULCLを実行する、という様なネットワークと連動したアプリケーションのライフサイクル管理などが考えられます。

9-3. Local Area Data Network(LADN)

LADNとは、基地局の管理IDであるCellIDや端末のハンドオーバを制御するために使われるTAI(Tracking Area Identifier)などの端末の在圏情報を元に、端末とUPFとの間のPDUセッションの接続制御を行う技術です。
端末が予め指定されたLADN Service Area内へ移動すると事前に定められた通信ポリシーに応じてセッションを確立し、LADN Service Area外へ移動するとモバイルネットワーク側からセッション切断を行います。

例えば、スマートシティ内のロボット、スタジアムでの配信イベントなど、特定地域限定でQoSを変えて通信サービスを提供する、みたいなユースケースが想定されます。

10. MECが分散配置された時の課題

3GPPでは、端末が移動した時にどのように適切なDNへ接続させるか、という技術を標準化してきました。
これは、MECが特定の地域１箇所に存在し、端末の移動範囲がその地域を超えない、という前提のユースケースなら良いのですが、端末が広域に移動し、MECも広域に分散配置されている環境下を想定すると、適切なMECの選択が難しくなってきます。

例えば、端末上のアプリケーションはDNSを用いて接続先のFQDNからIPアドレスを解決し、サーバへ接続します。
端末に近い、適切なMECをどの様に判断して、IPアドレスをどの様に解決するか、という課題の検討が必要です。

この課題についてのStudyが、ETSIより出されています。⁵

例えば、端末IPアドレスを地理情報に基づいて管理し、DNSが端末IPアドレスを元に宛先IPアドレスを判断する方法が考えられます。
しかし、端末IPアドレス・ドメイン・宛先IPアドレスのペアでレコード管理が必要となる事で管理が煩雑化しそうですし、DNSへ送信元IPアドレスとドメインの複数の情報を元に適切な宛先IPアドレスを決定するロジックが必要となり、ISPサービスとして提供される大規模なDNSへ適用しようとなると性能影響等が懸念されます。

一方、IP anycastを用いて、「MEC上のアプリケーションは全て同一のIPアドレスをVIP(Virtual IP)サービスとして提供する！」というサービスを提供する場合、DNSベースよりも導入障壁が低そうです。
しかし、IP anycastは最短ASパスとなる経路で宛先IPアドレスへルーティングする技術ですので、通信の状況変化で接続先のMECが変わったり、サービス提供者もエリア毎に適切なパスでMECへ接続できるようネットワークインフラの設計の再考が必要になる可能性があります。設計変更となったら非常にインパクトが大きい話ですので、実現までかなり時間がかかるでしょう。

緯度・経度ベースの方式は、MobiledgeXのDME(Distributed Matching Engine)にて提供されているものです。端末上のアプリケーションが、端末のGPS測位結果をクエリとしてAPIを実行します。APIサーバは緯度・経度の情報に対応するMEC上のアプリケーションを管理しておき、端末上のアプリケーションからのAPI実行の都度、APIサーバが宛先URLを判断する、というソリューションです。
比較的容易に実装できそうですが、ビジネス観点ではSDKを広めていくのにどれだけ労力をかけられるか、が課題になりそうですし、技術的にはGPS測位が出来る屋外エリアに限定されたり、端末の電池持ちの課題があります。

また、これらの方式で仮に適切に名前解決が行えるようになったとしても、全ての案に共通して、端末移動時に端末-サーバアプリケーション間のセッションが切れてしまうことをどこまで許容できるのか、という新たな課題が発生してきます。

この様に、端末のモビリティを考慮して適切にアプリケーション通信をハンドリングするのは非常に難易度が高いです。

11. 3GPP Release.17 Edge Enabler Layer(EDGEAPP)⁶

そこで、3GPP Release.17では、エッジアプリケーションの実現に向けたStudyが行われ、Edge Enabler Layerというレイヤが整理されました。このEdge Enabler Layerは、端末のモビリティを考慮したエッジアプリケーションの実現をサポートするレイヤとして、様々な機能が標準化されています。また、アプリケーション層のアーキテクチャとしてEDGEAPPというアーキテクチャが規定されました。

Edge Enabler Layerでは以下の様な機能が規定されています。

Service provisioning

• 端末上のアプリケーションがエッジサーバ上のエッジアプリケーションにアクセスするための端末が必要とする情報を規定
• DNN、端末のロケーション、KPI、など

Registration

• Edge Enable Layerで定義される機能間の連携を規定

EAS(Edge Application Server) discovery

• 端末の接続先となるEAS(Edge Application Server)をディスカバリする方法を規定

Capability exposure to EAS

• EAS に向けて公開されるサービスを規定
• 公開されるサービスはEdge Enabler Layerのサービスと、5GCの機能の再公開・拡張などが含まれる

Support for service continuity

• 端末が新しい場所に移動した時にサービスの継続性を維持するためのサポート機能を規定
• アプリケーションセッションコンテキストの引き継ぎなど

Security

• Edge Enabler Layerのコンポーネント間のセキュアな通信をサポート

Dynamic EAS instantiation triggering

• EASの管理システムと連携して、アプリケーションのニーズに応じて適切なEASのインスタンス化をトリガーできる機能をサポート

Edge Enabler Layerを実現するコンポーネントのアーキテクチャ(EDGEAPP)を以下の図に示します。
ざっくり言うと、EECと、EECに対応するEASを管理しておき、端末の在圏エリアが変わった時などの予め指定されたトリガーに応じてEASをディスカバリし接続できる機能が標準化されています。

EDGEAPPの各コンポーネントの概要を以下に記載します。

EES(Edge Enabler Server)

• EAS、EECのサポート機能を提供
  • EECへの設定情報のプロビジョニング
  • EASとのアプリケーションデータ トラフィックの開通のためのプロビジョニング
  • 5GC APIとの連携や5GC APIの公開
  • アプリケーションセッション等のApplication Context管理、転送、再割り当てなどの制御・サポート機能
  • EEC、EAS の登録の機能(登録、更新、登録解除)
  • オンデマンドで EAS のインスタンス化をトリガーする機能

EEC(Edge Enabler Client)

• ACのサポート機能を提供
  • AC-EAS間と通信できるようにするための構成情報の取得・プロビジョニング
  • EASのディスカバリ

ECS(Edge Configuration Server)

• EEC-EES連携のサポート機能を提供
  • Service Area内のEDN情報やEASのURIなど、EAS接続に必要な設定情報をEEC にプロビジョニング
  • ECSは、通信キャリアがdeployしても良いし、サービスプロバイダがサードパーティのドメイン上にdeployしても良い
  • EESの登録、更新、登録解除の機能をサポート
  • 5GC APIなどの実行

AC(Application Client)

• 端末上のクライアントアプリケーション

EAS(Edge Application Server)

• EDN上のサーバアプリケーション
• ACはEASに接続し、エッジコンピューティングサービスを提供
• EASが5GCによって信頼されるサーバの場合、5GC API を直接呼び出すことも出来る
• あるいは、EESやNEFなどを通じて5GC APIを実行

11-1. EDGEAPPのFunction間の連携イメージ

各Functionの連携イメージを以下の図にまとめてみました。

Edge Enabler Layerの中核はEESであり、EESがEECとEASを管理し、端末のモビリティを考慮したエッジアプリケーションの実現をサポートします。ECSは、EECの接続先となるEESをディスカバリします。

EASとEESは同じEDN上で実行されることから、分散配置されるMEC毎にEESが存在することになります。

また、⑦で記載しているACR(Application Context Rellocation)は、端末が移動したことで接続先のEASの切り替えが必要になった際に、アプリケーションセッションなどのコンテキスト情報を引き継ぐ機能です。EAS自身が新旧EAS間でコンテキスト転送を行う方法の他、EESがEASのコンテキスト情報をストアし切り替わりをサポートするEELManagedACRという機能についても規定されています。

11-2. 端末移動時の連携イメージ

参考までに、端末移動時の連携イメージを以下に示します。

• 端末が移動した際に、端末とUPFとの間のPDUセッションが例えば上述のSSC mode2で適用されている場合、PDUセッションの切り替わりが発生します。
• PDUセッションの切り替わりをEESがU-Plane Path Management APIというAPIを用いて検知し、EASのセッション切り替えを実行します。
• EESは切り替わり先のEAS(T-EAS)をECSと連携することで特定し、セッションコンテキストの引き継ぎを行います。
• 端末は切り替わり先のエリアでEASディスカバリを行い、EASに再接続します。

この様に、Edge Enabler Layerの規定により、モバイルネットワークのハンドオーバなどの制御にトリガーして、端末からMECへのアクセスやMEC上のアプリケーションセッションの切り替え等を制御できます。まるで、MEC上のアプリケーションがモバイルネットワークに溶け込んだ様な実装が実現できます。

11-3. 指定できるService Area

端末がEASへ接続できるエリアをService Areaというポリシーで事前設定できます。
ここでは例として、Topological Service AreaとGeographical Service Areaについて記載します。

Topological Service Area

• CellID(CellIDリスト)、TAI、PLMN等と端末のネットワーク接続ポイントとの関係で定義

Geographical Service Area

• 建物、公園、アリーナ、住所、郵便番号等の情報と緯度・経度等の地理情報をマッピングして管理し提供

11-4. EDN(Edge Data Network)の種類

MECが接続されるEDNは、以下の３つの選択肢があります。

Non-dedicated DN

• 例えばInternetアクセスなどの他のサービスとの共通のDNを介してEASに接続するオプション
• 各EDNはDNN(Data Network Name。APN的なもの)と1つ以上のDNAI(Data Network Access Identifer)によって識別される
• 一つの端末がエッジ上で提供されるサービスとクラウド上で提供されるサービスそれぞれに接続する形になり、DNNやスライス情報も同じ
• つまり、端末がEASやEESへアクセスする際は、ULCLなどでローカルブレイクアウトする形で接続するイメージ

Edge-dedicated DN

• エッジ専用のDNを使用するオプション
• 固有のDNNを設定できる
• 各EDNはエッジ専用のDNに対応するDNNと1つ以上のDNAI によって識別される

LADN

• LADNとして展開されたエッジ専用のDNを使用するオプション
• LADNのService AreaとEDNのService Areaが等しくなる

12. オープンソース動向

12-1. LF Edge Akraino Brue Print ー 5G MEC System⁷

Linux FoundationのLF Edge配下のAkrainoでは、様々なコンセプトに基づくBrue Printと呼ばれるプロジェクトを公開しています。Brue Printでは、様々なオープンソースを組み合わせてコンセプトの実現検討、アーキテクチャ策定、インストールとテスト、を行い、確立したハードウェアやソフトウェアのConfigを公開しています。

その中の一プロジェクトである5G MEC System Brue Printでは、Intel®　Smart Edge Openというオープンソースを活用して5GCとMECの連携したアーキテクチャを検討しています。

Edge ConnectorとEdge GWというコンポーネントがこのBrue Printの中核です。
これらのコンポーネントはIntel® Smart Edge Openにおける、Edge ControllerとEdge Application Agent(EAA)に該当し、Edge Connectorにて5GC APIと連携、Edge GWにてエッジアプリケーションの管理やDNSハンドリングなどを行います。

AkrainoのBrue PrintはAkraino Wikiを参照するか、以下のAPIポータルが分かりやすいので参考にして下さい。

12-2. LF Edge Akraino Brue Print ー PCEI(Public Cloud Edge Interface) ⁸

GSMA OPの実装に向けたAkraino Brue Printとして、PCEIというプロジェクトが進行しています。

このプロジェクトは、モバイルエッジとパブリッククラウド間のマルチドメインの環境におけるインターワーキングを可能にするオープンなAPIセットを実装することを目的に、コア機能としてAPI GWなどを提供し、以下のユースケースや機能をスコープとしてモバイルコアやMEC、クラウドの制御インタフェースの抽象化・統一化を検討しています。

• トラフィック制御やUPF分散など
• ローカルブレイクアウト機能
• ロケーションサービス
• E2EのQoS提供
• ネットワークスライシングのプロビジョニングと管理
• 分散型オンライン/クラウドゲーム
• 認証
• セキュリティ

12-3. EDGE GALLERY⁹

EDGE GALLERYはAkraino　5G MEC System Brue Printのプロジェクトの一つであるEnterprise Applications on Lightweight 5G Telco Edgeにてリファーされています。このオープンソースは、ETSI MECリファレンスアーキテクチャに準拠したMECのオープンソース実装を目的に、China Mobileを中心とした中国企業メインのメンバー構成で推進されています。

12-4. XGVela¹⁰

XGVelaもChina Mobileが中心となり主導しているコミュニティで、Telco PaaS(Platform as a Service)というコンセプトの元、スライスによるNaaS(Network as a Service)のオープンソース実装を行っています。（情報があまりなく、実装はこれからの模様）

1. ETSI, Multi-access Edge Computing Framework and Reference Architecture V2.1.1, Jan 2019 ↩

2. GSMA, Operator Platform Telco Edge Proposal v1.0, Oct 2020 ↩

3. 3GPP, TS 23.501 V15.10.0, “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; System Architecture for the 5G System(5GS); Stage 2 (Release 15)”, Jul.2020. ↩

4. 3GPP, TS 23.502 V17.3.0, “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Procedures for the 5G System (5GS); Stage 2 (Release 17)”, Dec.2021. ↩

5. ETSI, White Paper No.39, Enhanced DNS Support towards Distributed MEC Environment, Sep 2020 ↩

6. 3GPP, TS 23.558 v17.1.0, Architecture for enabling Edge Applications(Release 17), Sep 2021 ↩

7. Akraino, 5G MEC/Slice System to Support Cloud Gaming, HD Video and Live Broadcasting Blueprint
   https://wiki.akraino.org/display/AK/R3+-+Architecture+Documentation
   https://smart-edge-open.github.io/ ↩

8. https://wiki.akraino.org/display/AK/PCEI+Release+5+Documentation ↩

9. http://docs.edgegallery.org/en/latest/Architecture/Architecture.html
   https://www.edgegallery.org/en/ ↩

10. https://xgvela.org/
    https://github.com/XGVela/XGVela ↩