NFVの現在とvRAN/5GCに向けた機能拡張

01.まえがき

非仮想化時代のネットワーク装置は，新しい機能を提供するごとに追加の専用装置が必要となる．このため，調達から工事までのコストの増大や，装置間の接続・設置における設計の複雑化，通信設備ビル内の電力やマシンスペースの消費増加などにより，イノベーションが制限されていた．NFV（Network Functions Virtualization）*1は，専用ハードウェアを汎用サーバ上で動作するソフトウェアベースのネットワーク機能に置き換えることで，これらの課題を解決する．NFV技術を用いることで通信事業者は，EPC（Evolved Packet Core）*2をはじめとする4Gのコアネットワーク*3の仮想化*4に成功した[1]．
しかしながら，ETSI（European Telecommunications Standards Institute）*5 GR（Group Report） NFV 001[2]に記載されているように，NFVのユースケースの範囲はモバイルコアネットワークだけでなく，基地局，CDN（Content Delivery Network）*6，CPE（Customer Premises Equipment）*7など多岐にわたり，その手法も仮想マシン（VM：Virtual Machine）*8ベースのコアネットワークに制限されるものではない．NFVをすべてのネットワークドメインに適用し，通信事業者にとってNFV技術のメリットを最大化するためには，NFVアーキテクチャと関連技術のさらなる進化が必要であった．
本稿では，より多くのネットワークドメインへNFVを適用するために進化したNFVの概要と，5GC（5G Core network）*9やRAN（Radio Access Network）*10のサポートに対処するための具体的な拡張機能について解説する．

02.初期のNFVと課題

NFVの初期段階では，以下のさまざまな理由からモバイルコアネットワークがNFVの対象となった．
・4Gサービスの導入からの通信需要拡大時期で4Gの容量拡大が必要とされていた
・aTCA（advanced Telecom Computing Architecture）*11などのハードウェア機器がEOL（End Of Life）*12に差し掛かっていた
・NFV関連の技術がEPCを実現できるまでに成熟した
・回線交換やPOI（Point Of Interface）*13のような運用上の特殊な要件が少なかった

その結果，EPC，IMS（IP Multimedia Subsystem）*14，PCRF（Policy and Charging Rules Function）*15，HSS（Home Subscriber Server）*16と順次コアネットワーク装置が仮想化されてきた[3]．
当時のETSI ISG NFVによって考案されたNFVアーキテクチャ[4]に基づき，モバイルコアネットワークにNFVを適用する例を図1に示す．
図1に示すように，色分けされた各VNF（Virtualized Network Functions）*17は，対応するVNFM（Virtual Network Function Manager）*18によって管理される．この初期のNFVの構成は，VNF専用のVNFMがそれぞれのVNFの特殊制御を担うことができるので，ハードウェアや装置の制御方法がそれぞれ異なる，サービス提供中の多数の非仮想化通信ネットワーク装置を，サービスを止めることなく1つずつ順番に仮想化しNFVへマイグレーションする手法に適していた．しかし，VNF専用のVNFMを必要とする構成では，複数のインタフェースでのインテグレーション*19や，異なるライフサイクルのワークフローに起因する運用の差異により，OAM（Operations, Administration, Maintenance）*20装置や運用のフラグメンテーションにつながるおそれがあった．その結果，NFVを拡張してモバイルネットワーク全体を仮想化しようとしたときに，プラットフォームが統一しきれず，装置のコスト削減や運用の統一化などのNFV化の効果が半減する可能性があった．
初期段階のNFVには，その他にも以下のとおり，いくつかの課題があった．
・NFV-MANO（NFV-Management And Orchestration）*21，NFVI（NFV Infrastructure）*22，さらにはVNFなどのNFVコンポーネント*23をアップグレードする運用の難易度が上がることで，NFV-MANOが新規ハードウェアをサポートしきれなかったり，VNFの機能変更が加えられなかったりして，新規ハードウェアや機能の導入ができなくなり，構築されたネットワーク機能の長期的なサポートに影響を与える．
・同一サーバ上の別仮想リソースが過負荷になり，他の仮想リソースに影響を与える「ノイジーネイバー」と呼ばれる現象を回避するために，専用の仮想化インフラリソースが必要となり，複数種類のVNFインスタンス*24間のリソース共有による効率化ができなくなる．
・VNFのデプロイタイミングとは無関係に，事前にNFVIによるリソースプールを構築しておくことで，NFV上にVNFをデプロイ*25する時間は大きく改善されたが，開発からネットワークの設計，商用デプロイ後の試験など，人手による作業が必要なプロセスが残る．

03.NFVの進化

3.1 ETSI ISG NFVのRelease

商用環境におけるモバイルネットワークのNFV化が進むにつれ，通信事業者のNFVへの新機能のニーズは増え，モバイルネットワークの進化と並行して，標準化も発展していた．ETSI ISG（Industry Specification Group） NFVは「Release」という概念によって，図2のように継続的に仕様を進化させてきた．
NFVでは当初，Release 2において，データセンタ内の仮想化リソース（VMなど）の制御と管理を中心とした仕様化が行われ，それらはモバイルコアネットワークの仮想化に利用されてきた．その後，Release 3では仕様化の対象を拡張し，データセンタ内の仮想ネットワークに追加してトランスポートネットワーク関連の仕様が策定された．そしてRelease 4において，仮想化技術としてコンテナ*26技術を導入するという大きな変化が発生し，新たに制御対象となったコンテナベースのVNFの特徴に合わせてOAMなどの汎用的なプラットフォーム機能の共通化が行われた．これによりRelease 4仕様では，5GCのデプロイが可能となった．Release 5では，RANの仮想化を実現するために必要な機能が大幅に追加され，また，エッジ*27とRANのような超分散環境のNFV基盤やそれに接続する膨大なネットワークに対処するための自動化の仕様が拡張された．
ETSI ISG NFVによって開発された各Releaseの仕様は，過去にリリースされた機能を継承しつつ仕様の互換性を維持し，NFVフレームワークの機能と仕様を拡張してきた．

3.2 5GCのサポートに向けたネットワークスライス（Release 3）

5GCでは動的なスケーリング*28，イノベーションの促進，迅速なサービス提供といった新しい運用上の要件が求められ，クラウドネイティブ*29のコンセプトとサービスベースのアーキテクチャを利用したネットワークアーキテクチャの変革が必要となった．3GPP（3rd Generation Partnership Project）*30を中心として5GCの要件抽出と仕様化は進められているが，ETSI ISG NFVにおいても5GCの収容に必要なギャップや要件が，以下の観点でETSI GR NFV-IFA（InterFaces and Architecture） 037[5]において分析され，課題が抽出された．
・ネットワークスライシング*31
・コンテナベースのVNFのデプロイ
・汎用的なPaaS（Platform-as-a-Service）*32

NFVの5GCサポートを改善するための主要な拡張機能の1つとして，ネットワークスライス*33がある．3GPP TS（Technical Specification）23.501[6]によると，ネットワークスライスインスタンス*34はPLMN（Public Land Mobile Network）*35内で定義され，①コアネットワークコントロールプレーン*36とユーザプレーン*37NF，②サービングPLMN*38で少なくとも次のいずれかを含む．
・5G NG（Next Generation）-RAN*39
・Non-3GPP InterWorking Function*40またはNon-3GPP AN（Access Network）*41向けのTrusted Non-3GPP Gateway Function*42
・Wireline AN*43向けのWireline Access Gateway Function*44

NFVにおいては，ネットワークサービス（NS：Network Service）として，NFVでの構築機能を利用したネットワークスライスの概念がRelease2からすでにサポートされていた．ETSI GR NFV 003[7]で定義されているように，NSはネットワーク機能とその接続先や運用機能を再帰的に定義したネットワークの構成を管理することが可能であり，ネットワークスライスを実現するための基礎技術となる．そのため，NFVにおける5GCのサポート作業は最小限であり，図3に示すように，3GPPとNFV間のマッピングが可能であった．
この例では，ネットワークスライスサブネット*45のそれぞれがNFV NSに1:1でマッピングされているが，複数のネットワークスライスサブネットが1つのNSによって実現されるなど，他のマッピングも可能である．

3.3 5GCのサポートに向けたコンテナ対応（Release 4）

5GCでは最新の技術の1つであるコンテナを利用したアプリケーションのデプロイが想定されており，そこにはソフトウェアを効率的かつ大規模に提供するためのさまざまな方法が含まれている．コンテナのデプロイは，物理マシンやVMに1つずつソフトウェアをインストールする従来の手法に比べ，柔軟で他の環境へ容易に移行できるソリューションであり，コンテナのデプロイ手法は，依存関係をもつアプリケーションがさまざまなクラウド環境*46間で同じように動作するための軽量なパッケージである．
図4は，サーバ環境にアプリケーションをデプロイする3つの方法[8]を示している．
（1）従来のVM
各アプリケーションは個別のVM内で実行される．VMには，それぞれゲストOS*47，ミドルウェア*48，およびアプリケーション本体が含まれる．これらのVMは，ホストOS*49の上にあるハイパーバイザー*50によって実行される．
（2）VM内のコンテナ
各VM内にコンテナを制御できるコンテナエンジンとそのコンテナ基盤をインストールし，VM内のコンテナ基盤上にコンテナの形式のアプリケーションをデプロイする方法である．各コンテナは，アプリケーションとミドルウェアなどの依存関係を保持しながらカーネル*51を共有してコンテナエンジン上で実行される．
（3）ベアメタルコンテナ
コンテナエンジン（例：Docker*52やContainerd*53）を使用してホストOS上でコンテナを直接実行する方法である．ハイパーバイザーとゲストOSレイヤが不要で，オーバヘッド*54が少ない．

コンテナ化は，5GCアーキテクチャにおける基本的な実現手段である．これは，5GCに軽量なフットプリント*55，高速な起動，および広く使用されているオープンソースベースのオーケストレーション*56システムによる管理性が求められ，VMに比べて軽量で，Kubernetes®*57をはじめとしたオープンソースによるエコシステムが充実しているコンテナが最も適していたからである．5GCの登場によって，NFVがコンテナ化されたリソースのオーケストレーション機能を提供し，コンテナベースのVNFをデプロイできるように仕様を拡張するきっかけとなった．
従来のVMベースのVNFとコンテナの両方をサポートするためには，NFVのコンセプトを拡張する必要があった．NFVは，コンテナのワークロード*58のオーケストレーションとライフサイクル管理のためにKubernetesなどのソリューションと連携することによって，コンテナベースのVNFに対応できるように進化した．NFVが従来のVMベースの仮想リソースのオーケストレーションをサポートしつつ，その仕様を拡張してコンテナベースのオーケストレーションもサポートしたことで，通信事業者とアプリケーションベンダは，5GCのそれぞれの機能部の実装に合わせてVMとコンテナを自由に選択できるようになった．
5GCのサポートにあたって最も重要なことは，Web系サービスで普及しつつあったコンテナ関連の技術を利用しつつ，NFVは5GCに関するユースケースと要件に対処可能な「パッケージ化」を行ったことである．NFVではVMとコンテナのハイブリッドなインフラストラクチャ*59上で，前述した多様なVNFを収容する方法が考案され，VMとコンテナ間で統一された仕様によって相互運用*60性と標準化された制御を行えるように仕様化がなされた．その結果，コンテナとKubernetesによって実現可能なSBA（Service Based Architecture）*61とマイクロサービス*62のアプローチを採用しつつ，コンテナでは難しかった通信固有のデータ接続プロトコル（SCTP（Stream Control Transmission Protocol）*63など）のサポートや，VNFごとに複数のポートやインタフェースを利用した，Kubernetesの原則とは異なる特有の要件をVMで実現することなどが可能となった．これにより，通信事業者はNFVアーキテクチャ内でコンテナ化された5GCを効率的に構築および管理できるようになった．

3.4 クラウドネイティブ化に向けたPaaS（Release 4）

SBAの原則と，クラウドネイティブのマイクロサービスベースのコンセプトを使用する5GCをより効果的に構築し運用するためには，追加のプラットフォームサービスを提供することが必要になった．このようなプラットフォームサービスは，PaaSと呼ばれ，VNFと容易に結合でき，VNFからPaaSを容易に使用できる必要がある．
ETSI GS NFV-IFA 049[9]では，VNFの汎用OAM機能とそれ以外のPaaSをPaaSフレームワークとして，NFVアーキテクチャを拡張している．このフレームワークはVMベースおよびコンテナベースの両環境で利用可能であり，次世代モバイルネットワークの要件をサポートする統一的なOAMを実現し，ベンダに依存しない統合プラットフォームを構築している．測定項目の収集（metrics aggregation*64），測定項目の分析（metrics analysis*65），ログ収集（log aggregation*66），ログ分析（log analysis*67），設定情報管理（configuration management*68）などのこれら機能は，個々のVNFから分離された汎用PaaSプラットフォームとして実装される．汎用PaaSプラットフォームは，ライフサイクル管理，OAM，トラフィック制御，サービスメッシュ*69，ポリシー，コンフィグ管理などを，さまざまなコンテナ間で統一して運用することが可能となる．また，汎用PaaSプラットフォームは，VNFをより軽量化し，基盤となるインフラストラクチャからVNFをさらに分離することができ，VNFの移植性も向上する．
この汎用PaaSプラットフォームは，5GCだけでなく，より優れた可観測性，低遅延パフォーマンス，および高いスケーラビリティを必要とするRANの管理コンテキスト*70と特に関連している．例えば，VNF Metrics AggregatorとLog Analyzerはユーザプレーン機能（UPF：User Plane Function）*71またはDU（Distributed Unit）*72のテレメトリデータ*73を有効にし，ポリシーエージェント機能*74はClosed loop*75の実現に大きく貢献する．図5は，ETSI GS NFV-IFA 049[9]で指定された汎用PaaSプラットフォームを示しており，CNCF（Cloud Native Computing Foundation）*76によって提供されるオープンソースソリューションが考慮されている．
赤枠で強調表示された「汎用PaaSプラットフォーム」の各ブロックは，特定のPaaSに対応しており，図中のロゴは各PaaS機能の仕様化にあたって参照されているオープンソースソリューションに対応している．また図4では，VNFインスタンスがより柔軟で，拡張性が高く，自動化された運用を実現するために必要なPaaSのモジュール構成が示され，また，CNCFで利用可能な最先端のオープンソースソリューションの実施形態がロゴによって示されており，これらを利用して開発コストを抑制し導入を容易化することで，ドコモのような通信事業者にプラスの効果をもたらしている．

3.5 RAN仮想化の実現（Release 5）

NFVは当初，コアネットワーク機能の変革に重点を置いていたが，近年，その役割は無線アクセスネットワーク（RAN）へ急速に拡大している[10]．RANの仮想化は，5Gアーキテクチャの原則に沿った，柔軟で細分化されたクラウドネイティブなデプロイという5GCの仮想化と同じ要件をもっていた．
仮想化されたO-RAN（Open RAN）*77アーキテクチャでは，DUやCU（Central Unit）*78などの主要なRAN機能が分離および仮想化され，オーケストレーションフレームワークの下で，商用オフザシェルフ（COTS：Commercial-Off-The-Shelf）*79ハードウェアで実行できるようになる．NFVは，この変換に必要な基本インフラストラクチャ，ライフサイクル管理，およびリソースの抽象化を提供している．その中で，RAN装置の複雑さ，処理遅延に関する厳しい要求，および超分散された仮想化基盤の実現のために，NFVには追加の拡張が必要だった．
RANの管理は，大規模なネットワークに加えて，数百万ものユーザ端末に最適な接続とカバレッジ*80を提供するための多数の構成パラメータがあるため，非常に複雑であった．このような規模の管理には，新しいレベルの自動化とインテリジェンスが必要となった．これらのニーズに対処するために，O-RAN Alliance*81は，以下の主要な要素で構成されるO-RANアーキテクチャフレームワーク[11]を仕様化した．
①O-RU（Radio Unit）*82およびO-DU*83をマルチベンダで接続する「Open Front haul」
②無線パラメータを自動調整する「RIC（RAN Intelligent Controller）*84」およびその「E2インタフェース*85」
③O-DUおよびO-CUの仮想化とその基盤である「O-Cloud」および「O2インタフェース*86」
④O-RU/O-DU/O-CUおよびO-Cloudを管理する「SMO（Service Management and Orchestration）*87」

これらの主要な4つの要素を図6に示す．
①Open Front haulでは，O-RUとO-DUがO-RANで規定されたインタフェースによって接続される．Open Front haulは，UE（User Equipment）のユーザデータを転送するU-Plane，U-Planeの接続に必要な制御信号を転送するC-Plane（Control Plane），O-RUの制御信号を転送するM-Plane（Management Plane），装置間の同期に利用するS-Plane（Synchronization Plane）によって構成されている．
②Non-RT（Real Time） RIC*88には，A1インタフェースを介したRANコンポーネントとのインタフェースが含まれている．またNon-RT RICは，非リアルタイムな無線パラメータの最適化処理と制御を実行するモジュールアプリケーションであるrApps*89を収容している．これらのrAppsはSMOおよび外部コンシューマと連携し，RANドメインに対して自動的な制御を行う．
③O-RANのコンポーネントの一部は仮想化され，図6に示すオレンジ点線のVNFのとおり，仮想化RAN（vRAN：virtual RAN）*90コンポーネント（O-DU，vCU*91-CP，vCU-UP）と，xApps*92を収容するNear-RT RIC*93がNFデプロイ[12]としてエッジサイト上のO-Cloud上にデプロイされる．
④SMOは，標準化されたインタフェースを活用して，モジュール化されたO-RANコンポーネントのライフサイクルとポリシーベースの管理を提供しており，ネットワーク機能のオンボーディング*94，NSとスライスのオーケストレーション，ネットワークの監視，RAN分析，トポロジ*95／インベントリ*96管理，AI/ML（Artificial Intelligence/Machine Learning）*97ワークフローなど，さまざまな管理機能とオーケストレーション機能を保持している．

O1*98，O2，A1などのオープンインタフェースを活用することで，このアーキテクチャは，コンポーネントを個別に構築，運用，および最適化できる，非常に柔軟でベンダに依存しないアーキテクチャを提供している．
ETSI ISG NFVとO-RAN SMOフレームワークの融合は，vRANデプロイを管理および自動化する強力な基盤を提供するため，真の「Open vRAN」を実現している．例えば，SMOは，厳密な待機時間と同期の要件など，RAN固有の要件に合わせて最適化されたオーケストレーションを提供している．ETSI ISG NFVにて仕様化されたNFVの基盤と汎用PaaSプラットフォーム（ログ集約，メトリック*99分析，VNF設定など）によって提供されるVNFの管理とオーケストレーションに関する機能は，O-RANの仕様に追加されることで，これらの機能をRANコンポーネント全体で活用して，可観測性を向上させ，ライフサイクル操作を簡素化させることができる．これにより，拡張性が高く，インテリジェントで，クラウドネイティブなRANアーキテクチャへ進化することができた．

04.統一プラットフォームの利点

ドコモのシナリオでは，NFVを全ネットワークドメインに展開することで，NFVのメリットを最大化することを戦略としている．
以下に，統一プラットフォームの主な利点を挙げる．
（1）コスト削減
複数のネットワークドメインにNFVの技術を活用することで，ドコモを含む通信事業者はインフラ，プラットフォーム，NFV-MANOなどの資産を再利用してコストを削減できる．
（2）ドメイン固有の要件に対する迅速な対応
NFVに統合されたさまざまな仮想化およびクラウド化技術を採用することで，ドコモはそれぞれのネットワークドメインに固有のパフォーマンス，信頼性，セキュリティ要件を考慮することができる．ドメイン固有の要件は，例えば，RANではリアルタイムなネットワーク通信と無線チャネル変調において非常に高い処理能力が要求され，それに対応できる性能が重要である．一方，コアネットワークでは，集約されたトラフィックがサービスを中断することなく処理できるようにすることであり，信頼性が重要となる．
（3）運用の統一化
ネットワーク機能ごとに仮想化およびクラウド化技術を活用し，統一された運用方法を適用することで，ドコモはよりダイナミックに変更されるクラウドネイティブなネットワーク機能の導入による運用の複雑さを軽減し，全国規模のNFVの運用を実現している．

05.あとがき

NFVは，専用ハードウェアを柔軟なソフトウェアベースのネットワーク機能に置き換えることで，より迅速でコスト効率の高いサービス展開を可能にし，通信ネットワークを変革してきた．当初はEPCに焦点を当てていたNFVは，5GCのダイナミックで高性能な要件を実現するために，コンテナ化とクラウドネイティブ設計によって進化してきた．仮想化がRANへと拡大する中，NFVのPaaSプラットフォームをO-RANで活用することで，vRANを管理するための統合的かつスケーラブルな基盤を提供した．NFVとO-RAN SMOの統合による相乗効果で，マルチベンダ環境全体における効率的なライフサイクル管理，可観測性，自動化が可能になり，アクセスからエッジ，そしてコアまで，クラウドネイティブでインテリジェントな5Gネットワークへの道を開くことができた．NFVは今後も最新の技術やユースケースを取り入れ，さまざまな種類のアプリケーションやさまざまなタイプのインフラストラクチャを利用し，6Gに向かって進化を続けていく．

文献