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

<font color=red><b> 2024年2月23日追記 </b></font>

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

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

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

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

https://www.3gpp.org/technologies/edge-app

<font color=red><b> 2022年2月22日追記 </b></font>
2022年2月22日の[Open Mobile Network Infra Meetup #6](https://omni-jp.connpass.com/event/233917/)にて本記事の内容を発表しました。少し加筆していたりしますので、発表スライドを添付します。

<script async class="speakerdeck-embed" data-id="4212141baa5342f284ec701c4c04d9e4" data-ratio="1.77725118483412" src="//speakerdeck.com/assets/embed.js"></script>


以下、Youtubeです。

<iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/YcwqJwee16Y?start=1988" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

# 1. はじめに

みなさん、こんちには。

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

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

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

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

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

![エッジコンピューティングの全体像](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/559968/49a508ba-6fd6-8be8-ae98-86056b7c5cbd.png)

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

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

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

が期待されています。

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

- 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`という形でエッジコンピューティング関連の用語集がまとめられていますので参考にして下さい。

https://github.com/State-of-the-Edge/glossary

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

![標準化団体](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/559968/e8dc8190-55f3-2492-a29e-f19cf5a89162.png)


`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](https://kubeedge.io/en/)などは必ずしも標準化を意識したものではありませんが、KubeEdgeの`ユースケースの1つがMEC`、という様な感じでしょうか。

# 4. ETSI MECリファレンスアーキテクチャ[^1]

[^1]: ETSI, Multi-access Edge Computing Framework and Reference Architecture V2.1.1, Jan 2019

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

![ETSI MECリファレンスアーキテクチャ](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/559968/234674d0-9a33-55ed-7622-9ca35b2d5eeb.png)


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

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

### `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)[^2]

[^2]: GSMA, Operator Platform Telco Edge Proposal v1.0, Oct 2020

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

![GSMA Operator Platform](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/559968/6b26d9fc-3897-d680-7f74-7726ed424b3a.png)


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`として推進しています。

![MEC Federation](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/559968/b4ef14f7-5aef-4bb6-34a0-b14f478091c3.png)

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

![MobiledgeX](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/559968/96ab2b7a-20d5-af96-9ff2-42f0dae5dd7d.png)


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を実施しています。

https://www.nttdocomo.co.jp/binary/pdf/corporate/technology/rd/topics/2019/topics_200108_00.pdf

https://news.kddi.com/kddi/corporate/newsrelease/2021/06/29/5212.html

https://www.softbank.jp/corp/news/press/sbkk/2020/20200902_02/


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

https://developers.apis.kddi.com/documents/xr?file=top.yaml

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

https://github.com/mobiledgex

# 6. 3GPP　5GC Architecture[^3]

[^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. 

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

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

![5GC Architecture](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/559968/f8e42898-2b22-e5a2-d9c4-238e4b5f0e0f.png)

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

https://qiita.com/kuro227/items/9613052cf55468a12163

https://qiita.com/kuro227/items/f3b7b5d27dfc41849d58

https://qiita.com/kuro227/items/bf2e63a16355ecec5257

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を実行して通信制御を行う、といったユースケースを考えやすくなりました。


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

https://github.com/jdegre/5GC_APIs

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

https://www.free5gc.org/

https://open5gs.org/

https://www.magmacore.org/


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

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

![DN](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/559968/631f6cc3-5e3a-4b09-c932-565d6d313fc3.png)

# 7. 端末が移動した時のPDUセッションの扱いの課題
モバイル端末がMECへアクセスする際に課題となるのが、`端末とUPFとの間で張られるセッションの扱い`です。

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

![PDU](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/559968/8450cdfb-44b7-e586-bca7-2645fd959fe7.png)

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

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

![SSC](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/559968/b9d1534c-336f-5886-dfe5-e15fdea84c95.png)

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

https://qiita.com/kuro227/items/bf2e63a16355ecec5257

# 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を挿入・削除・変更し、ルーティング制御を行います。

![ULCL](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/559968/4378cebc-69fd-1987-9cc8-1d711356172f.png)

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

## 9-2. AF Influence on traffic routing[^4]

[^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. 

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

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

![Traffic Influence API](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/559968/94ed95be-32c4-32cc-a203-ffaa44a68420.png)

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

![LADN](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/559968/5c346ff2-e6fd-741b-12f1-40ae7d337231.png)

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

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

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

![DNS問題](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/559968/58ffe4b2-4528-7e82-e285-f2a9e99a5147.png)

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

[^5]: ETSI, White Paper No.39, Enhanced DNS Support towards Distributed MEC Environment, Sep 2020

![ETSI DNS Study](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/559968/00e0c089-5894-7972-b498-5ead2ff337be.png)

例えば、端末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)[^6]

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

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

![Edge Enabler Layer](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/559968/ac5615ae-c831-5b5c-d917-d381bfa78bb5.png)

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](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/559968/47c42d79-8f3b-e183-0ff3-6029d874eecf.png)

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の連携イメージを以下の図にまとめてみました。

![EDGEAPP連携イメージ](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/559968/fd9c1d1f-8107-80de-c1b8-26c6f9ef8eda.png)

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. 端末移動時の連携イメージ
参考までに、端末移動時の連携イメージを以下に示します。

![端末移動時の動作イメージ](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/559968/c49d3d9f-2265-052a-4459-d816172552fa.png)

- 端末が移動した際に、端末と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`について記載します。

![Service Area](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/559968/e2ae62b5-6670-736c-2695-ac607d22b220.png)


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

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

# 11-4. `EDN(Edge Data Network)`の種類
MECが接続される`EDN`は、以下の３つの選択肢があります。

![EDN](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/559968/2bd660db-2fc1-10aa-5f5f-e47f2b44f696.png)

### `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[^7]

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

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

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

![Akraino 5G MEC](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/559968/12d6ab8d-01b1-841a-31bd-c05fbffb1405.png)

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

https://smart-edge-open.github.io/

AkrainoのBrue Printは[Akraino Wiki](https://wiki.akraino.org/)を参照するか、以下のAPIポータルが分かりやすいので参考にして下さい。

https://apiportal.akraino.org/apimap.html

## 12-2. LF Edge Akraino Brue Print ー PCEI(Public Cloud Edge Interface) [^8]

[^8]: https://wiki.akraino.org/display/AK/PCEI+Release+5+Documentation

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

![PCEI](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/559968/38c2a195-c206-e489-4a5a-f347625c5dce.png)

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

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

## 12-3. EDGE GALLERY[^9]

[^9]: http://docs.edgegallery.org/en/latest/Architecture/Architecture.html<br>https://www.edgegallery.org/en/

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

![EDGE GALLERY](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/559968/bec1ed63-b962-8ef1-f78b-0ba11c521460.png)

## 12-4. XGVela[^10]

[^10]: https://xgvela.org/<br>https://github.com/XGVela/XGVela

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

![XGVela](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/559968/f2c77b22-beb4-fdf0-b4a7-c500cd1aaf61.png)