MECとは？vRANやNFVとの関係は？

 O-RAN/vRAN (virtual Radio Access Network)と並んで、最近注目を集めている技術にMEC (Multi-access Edge Computing)がある。AWSやGoogleなどのHyperscalerと呼ばれる巨大なパブリッククラウドビジネスがある中で、小規模分散型のMECが騒がれている理由について見てみたい。

MECが想定するビジネス

iGillottResearchの『小売業界におけるMECのビジネスユースケース』や、NECの『ユースケースによるMEC導入効果とメリット』に想定されるビジネスが記載され始めているが、これらのユースケースによれば各企業のシステムを自社(オンプレミス)〜ネットワーク(MEC)〜クラウドのどこに置くかによって“企業のコスト構造の変更によるコスト削減“に見える。

一般的にビジネス性と言えば、「(収入ーコスト)×ビジネス継続期間」となるので、①新規収入(収入UP)、②コスト削減、③SLA/品質/安全性向上(ビジネス継続)のいずれかとなる。MECにおいては各企業のシステムを構築する環境(クラウド)の提供形態となるので、ITとモバイルの保守の違いとは？での説明の通り本来物理装置を集約することでコストを極限まで下げることで成り立つビジネスのはずである。しかし、MECは分散することで②のコスト削減や③の品質や安全性の向上を狙っているので、分散クラウドによる維持コスト増加とのバランスにおいてビジネス性のあるユースケースがなかなか出てきていない。総務省の『ネットワーク設備委員会』においても、この分散クラウドとパブリッククラウドの効果とコストのトレードオフの関係は議論されているようだ。

交換機に近い場所では、モバイルオペレータ観点では設備の効率化は可能だが必要となるリソースのパブリッククラウドとの差が小さくなるため、大きな費用構造の差は無いだろう。パブリッククラウドの場合ネットワーク帯域の使用料が比較的高額なケースが多いため、そのような高額なリソースの種類によってはMECが競合相手になる可能性がある。

一方で、中継局や基地局のような箇所にMECを置くことが出来れば、ネットワークリソースなどを省略し、費用構造を変えることができるだろう。ただし、MECを基地局サイドに近付けるほどアーキテクチャ上の課題や、モバイルオペレータの設備や保全費用の増加、MECシステム間の連携など様々な課題が発生する。これらのコスト構造の変化がビジネス性があるかどうかがポイントとなるであろう。

MECのアーキテクチャと課題

JANOGの『MECについて』やOno氏の『コンピューティングがネットワークに溶け込む未来』によって、RAN (Radio Access Network)やCN (Core Network)における呼処理のアーキテクチャや課題が説明されている。本来モバイル網は、利用する端末(UE)が移動しても通信が継続できるように専用線を提供することがミッションなので、専用線の途中で接続先を切り替える(ブレイクアウト)ためには様々な技術的課題があるようだ。

一方で、オペレータのモバイル網で企業のシステム(お客様アプリケーション)を動作させるためのインフラ目線での課題もある。分散クラウドにおける維持コスト増加を緩和させるためには、一番典型的な方法はモバイル網の中に少しだけ余剰リソースを用意し、そこでMECを提供することであろう。これによって、モバイル網の維持とMECの維持を共通化できるため、分散クラウドの維持コストを軽減できるかもしれない。ETSI NFVでも同様の考えは議論されているようで、NFVNOC(21)000016、O-RANの仕様、ETSI GS MEC 003を踏まえるとこのような構成になるのかもしれない。

特にMECとNFVの関係については、ETSI GS MEC 003 6.2章や、ETSI NFV&MEC IOP Plugtest report 8.3.5章で、NFV基盤上でMEC PlatformやMEC Applicationを動作させるアーキテクチャが仕様化・実装され始めている。

このようにNFVのPlatform上にMEC PlatformとMEC ApplicationがVNFとして動作し、NFVOとはMEAO (MEC Application Orchestrator)が接続し、MEAOがCFS (Customer Facing Service)PortalやOSSと連携するアーキテクチャとなっている。

このMEC〜NFVの連携にあたっては

  • MEAO〜NFVO(SOL005ベース): MEC AppやMEC PlatformのOnboardingやLCM
  • MEC Platform〜VNFM(SOL002ベース): VNF LCM Notification
  • MEC App〜VNFM(SOL002ベース): VNF Configuration
が接続されている。ETSI NFVではFEAT12 Enhancement Support for MEC in NFV deploymentsとしてMEC対応をしているが、その中でVNF Pkgの拡張とCoordinateLCMoperationの拡張が行われている。MEC〜NFVの連携における技術上の課題は

  • モバイルオペレータが試験していない3rd partyのAPLを、モバイル網内のPlatform上で動作させて良いか？
  • 現在のNFV仕様ではマルチテナント対応が済んでいない中で、どのような仕様でMECと呼処理のVNFのテナントを分離するか？
  •  (法人システムはコンテナベースの実装が多い中で)どのような技術でVMベースのVNFとコンテナベースのMECを混在させるか？
  • NFVIやMANOを更新やメンテナンスする場合に法人システムにどのように影響を与えずに実施するか？
  • (MECとして複数の基地局にシステムが分散した場合)MEC間の同期や連携はどうするか？その間のNW等は誰の責任でどう構築するか？

というものがある。

ETSI NFV&MEC IOPにおいては、MANOからのLCMやStart/Stop、MEC AppのActivate/Deactivateなどの試験が行われたようだ。Instantiate VNFなどは動作しているようだが、Activate/Deactivateなど、試験未実施項目がまだまだ多数あるので、MEC Platformのプロダクトが出てくると、今後NFVとの連携も成熟していくかもしれない。


まだまだMECはビジネス性が不透明であるため、基地局などの分散している環境に法人システムを構築する場合の技術的課題の大きさを考えると、MECが本格化するためには、この辺のトレンドの変化が必要かもしれない。

  1. (低遅延以外の)コスト構造の変化を最大限享受できるキラーコンテンツ
  2. 消費リソースの最適化踏まえた価格設定
  3. 分散システムを簡易に構築できるPlatformの技術的進化
  4. 基地局サイドのメンテナンス性の向上と自動化

コメント

コメントを投稿

このブログの人気の投稿

CISMとは？CCMとは？NFVでコンテナ管理はどうやるの？

イメージ
ETSI-NFV仕様の各Release機能 の通り、ETSI-NFVのRelease4ではコンテナの制御が追加される。Release4は IFA039のSBA の影響でService Baseの仕様が入っており、ETSI-NFVにおけるコンテナ管理は様々なバリエーションがある。そのため、どのように各仕様を使うかを理解するのは非常に難易度が高いだろう。なお、コンテナとは何か？については こちら を参照して頂きたい。 Kubernetesによるクラウド管理 Kubernetesは、コンテナという技術と各種管理機能を使ってプログラム(APL)を抽象化し、クラウド上でAPLを制御するフレームワークとそれを支える管理機能群である。ここでのクラウドとは、APLを抽象化することでインフラの制御を含む様々な資源を共通機能化し、それらをAPIでソフトウェア的に制御できるようにしていることだが、それを仮想化とクラウドの違いから図でまとめてみた。 仮想化だけした場合(単純仮想化)は、基本的にはAPLは物理装置自体と同じ構造であり、それをインストールしたり故障時の修理をしたりする作業も物理装置と同じ手順が必要だった。しかし、せっかくAPLを仮想化によりソフトウェア化し、HWとの依存関係を無くしている(抽象化している)ので、例えば初期構築やHW故障時の対応をAPI化したい。これがIaaS(Infrastructure As A Service)と呼ばれ、サーバやNW機能の一部を管理機能(ETSI-NFVの場合はVIM)で制御できるようにしている。これにより、物理装置の変更に伴う各種作業は削減され、VMだけ考慮すればよくなった。さらに一歩進んで、LBやDBなどの共通機能をインフラの一部として提供する(PaaS)ことで、HWに依存しない新しいタイプのAPLとプラットフォームへ進化することができ、この“何か分らない雲のようなところにリクエストを出すとサービスを得られる“というものがクラウドである。 Kubernetesは、このクラウドの効果を最大化するために、APLの範囲を最小限化している。 Kubernetesの世界では、APLはDataを持たず、Logicのみをコンテナとしてカプセル化しPodという単位で管理することで、外部から容易かつ高速に起動/停止が可能となっている。そのため、APLの冗長...
続きを読む

モバイルネットワークの保守運用の基礎

イメージ
O-RANや Sliceの管理 によって、最近モバイルネットワークの保守運用が脚光を浴びるようになってきた。しかし、運用方法や保守系装置は“オペレータやベンダ毎に異なる領域“というイメージであり、なかなかまとまったドキュメントや資料が見つからない。 保守運用の基本 これまでネットワークの保守運用のデファクトや標準仕様と言えばTM Forumの eTOM 程度しか無かったと思う。eTOMや各種標準化機能やOpen Sourceを踏まえると、大きく以下のような考え方がありそうだ。 保守運用のプロセス strategy： 新サービス導入やユーザの利用状況を踏まえた設備計画 保守運用の観点から見るとfulfillmentのInput情報 fulfilment(fulfillment)：設備計画に基づいたネットワーク装置(NF)や、それらを接続するネットワーク(NW)の設計・工事 assurance：運用しているNFやサービスの監視や復旧、更新作業 4Gまでの保守運用というと、assuranceを指すことが billing：利用状況に基づいた課金 保守運用の観点から見ると運用結果のOutput 保守運用レイヤ Business Management System (BMS)： 顧客の契約情報を管理 一般的にBusiness Support System (BSS)を利用 Service Management System (SMS)： 提供サービスの管理運用 Network Management System (NMS)： (サービスを実現する)NFの接続性の管理運用 4GまでのOperation Support System (OSS)と言うとNMSのことを指すことが多かったようだ Element Management System (EMS)： NF自体の管理運用 NFのFCAPSと言えば、EMSのことを指すことが多い 一般的にネットワークの保守運用というと、EMSまたはNMSのレイヤのfulfilment＋assuranceを指すことが多いように感じる。しかしながら、システムによる実装と人手での運用という観点では、4GまではEMSのassuranceまでを実装し、残りは手作業ということも多かったようだ。規模が大きな企業では、NMSやSMSの一部を取り入れてOSSを導入し...
続きを読む

VNFとは？CNFとは？

イメージ
これまでNFVをベースとした仮想化の説明をしてきたが、肝心のVNFについて説明していなかったことに気づいた。今日はそもそも”VNFとは何か？“について解説してみる。 Network Functionを仮想化した“VNF“ 『 電気通信のつながるしくみと設備構成 』(NTT東日本)や『 結局モバイルNWのお仕事って何？ 』の通り、テレコムやモバイルのNWは加入者設備・加入者線(・基地局)・伝送路・交換機によって構成されており、これらの設備(のいくつか)をNetwork Functionと呼んでいる。 VNF (Virtual Network Function)とは、このNetwork Functionを仮想化したものであり、主にVM型とコンテナ型がある。ETSI-NFVの仕様としては特定のタイプのNetwork Functionに限定している訳ではないが、NFVは元々 aTCA の有力な後継機として始まったこともあり、暗黙的にモバイルコア(交換機)を最初のターゲットして検討している。 上記図の通り、aTCAとNFVの関係をまとめると、概ね1 Chassisが1VNFインスタンスであり、1 Baldeが1VNFC (VNF component)となっている。もちろん、APLの性質によっては1VNF = 1VNFCとして設計することも可能である。 components aTCA NFV blade APL APL APL MW MW MW OS CGL Guest OS HW aTCA VM NW segment VLAN + L2SW Virtual Link (VL) port port Connection Point (CP) + Top Of Rack (TOR) HW manager HW OAM Charssis manager VIM HW control Charssis manager N/A ...
続きを読む