5gにおけるエッジコンピューティングのリソース...

５Ｇにおけるエッジコンピューティングのリソース活用に向けた制御手法

２０１８年３月２０日ＫＤＤＩ総合研究所柚木克夫、新保宏之

KDDI Research, Inc. All rights reserved.

5Gにおけるエッジコンピューティングのリソースを効率的に活用するため、その制御を実現するための課題と解決方針を紹介

目次

1. エッジコンピューティングとは？

2. 5GへのMECの適用シナリオ

3. 想定される課題と解決方針

4. 今後の検討

5. まとめ

本講演の内容

KDDI Research, Inc. All rights reserved. 2

1. エッジコンピューティングとは？：５Ｇ要求条件

Enhanced Mobile Broadband

Massive Machine Type Communications

Ultra-reliable and Low Latency Communications

3D video, UHD screens

Smart City

Industry automation

Gigabytes in a second

Self Driving Car

Augmented reality

Smart Home/Building

Work and play in the cloud

Voice Mission critical application,

e.g. e-health

Future IMT

参考：Recommendation of ITU-R M.2083-0, Sep. 2015

5Gの利用シナリオ利用シナリオ毎の通信性能の重要性

多様化する利用シナリオに対する様々な異なる通信性能の要求条件を満たすことを、単一のネットワークインフラで実現するコンセプト。

超広帯域

超信頼性・低遅延大規模マシンタイプ通信（多接続）


1. エッジコンピューティングとは？：MEC（モバイルエッジコンピューティング）

超低遅延、超広帯域のモバイル通信を実現する候補技術として検討されている。ユーザ端末により近い場所（エッジ）からサービス・コンテンツを提供する。

クラウドコンピューティングモバイルエッジコンピューティング

モバイル事業者ネットワーク

処理時間＋

数100ミリ秒の往復遅延

処理時間＋

数ミリ秒の往復遅延

ネットワークの使用帯域を節約する効果もモバイル事業者

ネットワーク

インターネット

MECサーバ

ユーザ端末に近い場所から提供

コンテンツ、サービスはインターネット上のサーバから提供いくつかのコンテンツ、サービスはエッジホストから提供


1. エッジコンピューティングとは？：エッジコンピューティングへの期待

期待する特徴として以下のようなことが言われている。

１．アプリケーション実行の応答性の改善２．ユーザ体験の向上

３．地域性のある通信、計算の局所化４．サービスの中間処理の実施

クラウドサーバ

数100ms

MECサーバ

数ms

タスクのオフロード

能力の低い端末のタスクをMECで処理

通信の往復遅延の削減

軽い処理

スタジアム必要データだけをクラウドにアップ

自動運転での例（ダイナミックマップ）

局所化可能な計算はエッジで処理

トラフィックシェイピング画質変更、データ処理・集約

50

車の撮影した映像アップロード

自動運転用マップ生成

最新マップデータの提供


1. エッジコンピューティングとは？：5GとMECの標準化機関

MEC

ETSI ISG MECで標準化

ETSI = European Telecommunications Standards InstituteISG = Industry Specification Group

5G（モバイル通信）

3GPPで標準化

3GPP = Third Generation Partnership Project

LTE LTEadvanced

5G

モバイル通信でMECを活用するには、２つの仕組みを組合わせて動作するように考える必要がある。


2. 5GへのMECの適用シナリオ：5GネットワークとMEC

AMF SMF

UE (R)AN UPF DN

N8

N11

N3 N6

N2 N4N1

AFN7

DN

N6

UPF

N4

N9

PCF N5

AUSF N13 UDM

N10N12

N15

NSSF

N22

参考：3GPP TS23.501, System architecture for the 5G system

システム構成として、ユーザに近いところからデータネットワーク (DN)に分岐ルーティングするためのノードを定義（UPF：User Plane Function)

ユーザ端末

無線基地局

データネットワーク（ローカル）

データネットワーク（クラウド）

MECサーバ

AF (Application Function),PCF (Policy Control Function),SMF (Session Management Function)を介してUPFにルーティングルールを設定

MECサーバの構成概念

仮想化PF

MEC PF

PF: Platform

App.

App.

App.


2. 5GへのMECの適用シナリオ：MECの物理的な設置場所

・街路灯等に設置したスモールセル（イメージ）

MECサーバ内蔵のスモールセル装置

ユーザに近いところ基地局アンテナの場所に

MECサーバを設置

耐候性の課題（雨、温度、湿度等）装置コストUP壊れやすい

みなさんの想像

ANT+RF部

ベースバンド＋制御部

光ファイバー等

離れた場所

Function split

基地局を機能分割して設置していく傾向共通機能を共用ANT側の設備を小型化

IPレイヤでないので、MECサーバは設置

できない

CU CU

UPF MEC

5G コア(センター局)

マクロセルスモールセル

分散局

: データ

: 制御信号

Dual connectivity

CU：基地局のCentral Unit

実際にはもう少しコア設備に近い空調がある屋内に設置される。

現実解

・理由① ・理由②

制御信号：低い周波数帯（マクロセル）

データ：高い周波数帯（主にスモールセル）

特性の異なる周波数帯のセルを組合わせて活用


2. 5GへのMECの適用シナリオ：段階的なMEC展開シナリオ

●MECが必要なサービス開発の状況、マーケットニーズ等を鑑みて徐々にユーザに近い場所にMECを展開していく。（最初からたくさんの場所にMEC展開するのはコストが掛かる）

※2023年以降と想像

注）KDDIの具体的な展開計画を示している訳ではありません。

●2020年頃（オリンピックなど）は、場所を限定してサービスを提供するための設備展開。

体育館・プールイベント会場繁華街

など

スタジアム

MEC

VR, AR映像自由視点映像リプレイなどの提供

基地局

センター局

集約局

中間局

MECサーバ

導入当初は上流のみに設置し、ニーズに応じて徐々にユーザに近い場所に設置


MECサーバがネットワーク内に多く展開されたときの課題として以下を想定：

3. 想定される課題と解決方針：課題

ユーザに近い場所のMECサーバほど使用可能リソースが小さい。処理するサービスの取捨選択が必要。

(1)MECリソース量の課題

(2)サービスハンドオーバーの課題

ユーザ移動により基地局間ハンドオーバーが発生した際、移動先の基地局の経路からサービス提供を継続する必要がある。


3. 想定される課題と解決方針：(1)MECリソース量の課題

課題：MECサーバのリソース量(処理能力、メモリ、ストレージなど)は有限。

理由：ユーザに近い場所のMECサーバほど、その設置スペースの制限から設置可能なリソース量が小さくなる。

解決方針：サービス優先度(許容遅延など)、処理負荷、通信頻度、等を考慮して、サービスを最適配置もしくはサービス要求を他MECに転送する。

方法①優先度の低いサービスを追い出しリソースを確保

方法②余裕のある他MECに処理を転送(許容遅延を満たす場合)

通常：

混雑：

サービスＡ優先度：高

サービスＢ優先度：低

：使用リソースイメージ

サービスＡ

サービスＡ

Full

緑サービスの処理を他MECに追い出し

あふれた赤サービスの処理を他MECに転送

基地局

センター局

集約局

中間局

大

小

リソース量

転送


3. 想定される課題と解決方針：(1)処理MECを決定するシグナリング方法

(1) 中央制御型 (2) 自律分散型

サービス要求

サービス要求を受けたMECサーバが処理のためのリソースを有しないとき、どうやって要求を転送するMECを決めるのが良いか？

Busy

MEC-A

管理サーバ

サービス要求

誰にお願いすれば？

MEC-B

MEC-Bに依頼して

要求転送

MEC-A MEC-B

次の依頼、代わりにやっていいよ

MEC-A MEC-B

端末1

端末1

端末2

よろしく

サービス要求

要求転送

自律分散的に処理して中央へのシグナリングを削減しつつ、ボトルネックを把握してリソース配分を管理サーバで制御。（下記の両方を組み合わせたハイブリッド）

サービス提供

サービス提供


3. 想定される課題と解決方針：(2)サービスハンドオーバーの課題

課題：ユーザの移動に伴い、サービスのMEC間ハンドオーバーが必要。

理由：ユーザ移動により基地局間移動が発生した時、移動先基地局の後方にサービスを提供していたMECサーバが存在しない可能性がある。

解決方針：サービスの要求条件とハンドオーバーに要する中断時間を考慮し、引継ぎ先のMECサーバを決定。

基地局間移動

提供元MEC

■中断時間として考慮する要素・ハンドオーバー先MECの決定遅延

課題(1)のMECの可能リソースも考慮

・サービス提供状態の引継ぎ遅延提供状態だけ引き継ぐ方法サービスの提供環境ごと転送する方法

基地局Ａ基地局Ｂ

MEC間の接続構成を考慮して遅延を計算

引継ぎ

サービス提供の継続

引継先MEC


3. 想定される課題と解決方針：(2)サービス再開方法の分類（例）

サービス再開にいくつかの実装パターンが考えられる。必要となる制御シグナリングを今後具体的に検討。

分類①セッション状態を

引き継がない(管理しない)②セッション状態のみを

引き継ぐ③セッション状態を含む

サービス提供環境を引き継ぐ④MEC間のサービス

ハンドオーバーをしない

説明

基地局間ハンドオーバーした端末が、サービスの続きを新たに要求。

当該端末のセッション情報を引渡すことで、サービスを続きから再開。

当該端末に関連するサービス提供環境そのものを引き継ぎ、セッション状態に基づきサービスを続きから提供再開。

元のMECからサービス提供を継続(再開)。

イメージ

考慮事項

・移動先でもサービス提供可能なMECが居る前提

・セッション転送に要する遅延（引継ぎ先MECの決定を含む）

・環境転送に要する遅延（引継ぎ先MECの決定を含む）

・環境転送に要するバックホール帯域

・サービス提供に要するバックホール帯域、制御遅延

注）サービス実装の具体化は他の研究開発に任せる。

続きを要求

要求に基づき提供

続きを要求

セッション状態に基づき再開

セッション状態の引継ぎ

続きを要求

セッション状態に基づき再開

提供環境の転送

サービスサービス

続きを要求

元のMECから提供を再開

残り


リソース制限や端末移動を考慮したサービス提供・継続の制御方法を具体化。

考案した制御方法の効率をシミュレーションにより評価。

制御のためのシグナリング量

提供サービスの要求条件の充足率など

4. 今後の検討


エッジコンピューティング(MEC)は、モバイル端末にコンテンツ、サービスを低遅延で提供するための候補技術である。

モバイルネットワークにMECを適用する際には、そのリソース量に制限があるかもしれないことを考慮する必要がある。

以下について制御手法を具体化し、効率評価を行う。

処理MECの決定手順（中央制御型 or 自律分散型）

MEC間のサービスハンドオーバーのための制御手順

5. まとめ


【謝辞】本研究開発は、総務省受託研究「第５世代セルラネットワークを実現するミリ波エッジクラウドの研究開発（5G MiEdge）」の成果の一部である。

ありがとうございました。


5gにおけるエッジコンピューティングの リソース...

Documents

5gにおけるエッジコンピューティングのリソース...