従来のクラウドコンピューティングと比べて低遅延であることやコアネットワーク上を流れるパケットの量を減らすことが期待されている MEC (Mobile Edge Computing) 。より一般にはエッジコンピューティングと呼ばれています。
（図の引用元: https://link.springer.com/chapter/10.1007/978-3-319-47617-9_9）
端末の近くにサーバを設置するというコンセプト自体は理解できるのですが、実際に端末の近くにエッジサーバを設置していてもうまく有効活用できるのか？と自分の中で疑問に思っているところがありました。が、最近5G標準仕様の策定が完了し (2018年6月) 、少しずつですが具体的な方法が見えてきたようです。
MECサーバの設置場所
（図の引用元: https://www.etsi.org/images/files/ETSIWhitePapers/etsi_wp28_mec_in_5G_FINAL.pdf）
欧州電気通信標準化機構 (ETSI) が出している資料で、 MEC を 5G ネットワークに導入するときのネットワーク構造が示されています。
携帯通信のネットワークはアルファベットで略された装置が多く登場するので覚えていない人にとっては結構わかりにくいのですが、とりあえず
- UE: スマホとかの端末
- RAN: 端末が無線を通して接続する基地局の機能
- UPF: 基地局からインターネットへ接続するまでの部分
と捉えてもらえればと思います。動画や音声・画像などのコンテンツは UE-RAN-UPF の3つを結ぶ経路を流れます。ちなみにそれ以外の装置は Control Plane と呼ばれ、 UE-RAN-UPF の間の通信の認証など、通信の管理を司ります（参考）。
さて、それでは 5G における MEC の実装ですが上図のようになっており
- MEC Orchestrator は Control Plane と接続
- MEC の仮想化環境などは UPF と接続
となっています。
UPF, MEC の具体的な場所は割と自由に決められる
UPF はトポロジ的には先程の図のように RAN の次に来るのですが、物理的な位置は比較的自由に決められます。そのため UPF に接続される MEC の場所についても、 UPF に応じていろいろな場所に置かれます。下図のように、基地局にかなり近いところ（図の1番）からコアネットワークレベル（図の4番）まで、いろいろな場所に置くことが可能です。
（図の引用元: https://www.etsi.org/images/files/ETSIWhitePapers/etsi_wp28_mec_in_5G_FINAL.pdf ）
Uplink Classifier (UL CL)
MEC は UPF に接続されていますが、当然のことながらすべての通信が MEC を通過するわけではありません。あくまでも MEC サービスを利用するときだけ UPF から MEC へデータが転送されます。それ以外のときは MEC ではなく外部のインターネットなどへデータが転送されます。
このように MEC を使うときだけ転送先を切り替えることを実現する技術は Uplink Classifier (UL CL) と呼ばれています。
（図の引用元: http://4g5gworld.com/blog/session-and-service-continuity-evolution-5g-networks ）
2018/11/26 追記:
パケットの転送の分岐方法についてはこの UL CL だけでなく、__IPv6 Multihoming による方法__も3GPPの仕様では定められていました。
Session and Service Continuity (SSC)
MEC で問題とされているものの1つに挙げられていたのが、端末の移動への対応です。 MEC は端末の近くのエッジサーバで処理をすることに意味があるので、端末が移動したら利用するエッジサーバの切り替えが必要です。とは言っても、エッジサーバで処理が進行中の場合など、様々な条件を想定すると切り替えは簡単ではありません。
プロセスマイグレーションは使われず
この端末の移動への対応方法として1つ考えられていたのが、プロセスマイグレーションです。これは OS 上で動くプロセスをそのまま別の OS へ転送するというものです。しかしながら「プロセス」という OS や実行環境に依存しているものを移動させるのは容易なことではありません。代わりにコンテナ仮想化や仮想マシンの移動という方法もなくはありませんが、転送データ量は格段に大きくなるというデメリットがあります。
そのためか、今回読んだ資料ではプロセスマイグレーションは特に採用していませんでした。その代わりに、端末が移動した際に新たな接続が確立される一方で、それまで保持していた接続も残すことが可能になる技術が提案されていました。それが Session and Service Continuity (SSC) です。
SSC Mode
SSC は厳密には MEC のために開発されたわけではなく、移動する端末の接続性の切り替えを従来よりスムーズに行うための技術として提案されました。5G の SSC では、アプリケーションの要件に応じて移動する端末の接続性を3段階で用意しています。
（図の引用元: http://4g5gworld.com/blog/session-and-service-continuity-evolution-5g-networks ）
- SSC Mode 1
- 4Gのときと同じで、端末が移動しても最終的には同じネットワークの経路を辿る
- 通常のインターネット接続ではこれで問題ない
- SSC Mode 2
- 端末が移動したら、それまで持っていた接続を一旦切り、移動先で再接続を行う
- IPアドレスの継続性はなくなり、無通信になるタイミングも存在する
- SSC Mode 3
- 端末が移動したら移動先で接続を確立するが、それまで持っていた接続も保持する （つまり2つの接続を持つ）
- 無通信にならない
SSC と MEC
先程の UL-CL で述べた通り、 MEC のエッジサーバは UPF から横に流れる形で利用されます。 SSC Mode 3 では端末が移動してもそれまで保持していた UPF との接続性が保持されるため、エッジサーバで処理が実行中でもとりあえずその処理が終了するまで待つことが可能になります。
このようにして MEC システムを導入したときに生じる端末の移動の課題を解決しているそうです。
最後に
参考文献にあげている ETSI の資料にはユースケースについても書かれているのですが、 MEC のエッジサーバをサードパーティが提供するストーリーなどが紹介されていていよいよ新たなエコシステムが生まれそうだな、と感じました。エッジサーバの設置場所に関する具体的な話が出てきたのでこれからだなーと思います。