共創のご相談はこちら
2025年10月 5G以降のモバイルネットワークに向けたNFV基盤の進化（1）

NFVのエコシステム―標準化とオープンソースの連携―

  • ＃5GE&6G
  • ＃ネットワーク
English

Oguz Uelgen
Muhammad Hamza
ドコモ欧州研究所

久野 友也（くの　ゆうや）
中島 佳宏（なかじま　よしひろ）
クラウドデザイン室

あらまし

NFVは，COTSのコンピューティングやネットワークリソース，ソフトウェア化による新しい装置構築手法，リソースおよびサービスのオーケストレーションなど，さまざまな技術分野に関係している．NFVは，従来の通信機器ベンダからWebサービス機器ベンダ，クラウドプロバイダまでの業界のステークホルダーに対して大規模なエコシステムを促進してきた．また，標準化では，NFVソリューションの開発にOpenStackやCNCFといったオープンソースベースのソフトウェアを活用するなど，さまざまな分野の多様なエコシステムと連携し，最善の技術と専門ノウハウを活用することが鍵となってきた．本稿では，NFVが10年以上にわたってさまざまな標準化団体やオープンソースプロジェクトと連携し，長期的なサポートを実現することで，通信事業者のモバイルネットワークにNFVを適用できるようになってきた背景について解説する．

01.まえがき

ネットワーク機能の仮想化（NFV（Network Functions Virtualization）*1）は，通信ネットワークの構築と運用方法に大きな変革をもたらしている．
従来，スイッチング，認証，QoS（Quality of Service）*2，課金，セキュリティ，ハンドオーバ*3などの複雑な機能を備えたモバイルネットワークサービスは，専用ハードウェア機器によって実現されていた．このようなハードウェア中心のアプローチでは，新サービスの提供タイミングがハードウェアの工事に依存するほか，現地での作業が多数必要になり，さらにソフトウェアとハードウェアが一体となった調達・運用を行う必要があるため，通信事業者の設備投資と運用コストが増加し，サービス提供の構成や運用の柔軟性が制限される．
NFVは，ネットワーク機能を物理インフラストラクチャ*4から分離することでこれらの制限に対処することを目的とし，仮想化されソフトウェアとして制御可能なVNF（Virtualized Network Functions）*5をCOTS（Commercial-of-the-Shelf）*6サーバ上で実行できるNFVフレームワークを提案してきた[1]．この進化により，サービス提供の迅速性，VNFのスケーラビリティ，リソースや運用の効率性，ネットワークのサービス品質が大幅に向上し，通信事業者がリアルタイムの需要とハードウェアの障害に応じて，動的にネットワーク機能を提供，拡張，更新，および管理できるようになった．
このようなアーキテクチャは，欧州電気通信標準化機構（ETSI:European Telecommunications Standards Institute）*7によってETSI ISG（Industry Specification Group） NFV*8として開始され，主導されてきた[1]．2012年以降，ETSI ISG NFVは，柔軟でかつリモートから対応可能な，ライフサイクル管理をサポートするための参照となるアーキテクチャと，そのための新規機能部間のインタフェースや情報モデルを定義し，さまざまな標準化団体*9やオープンソースプロジェクトと連携してそのエコシステム*10を進化させてきた．現在，NFVのアーキテクチャと仕様はモバイルネットワークの基盤として重要な役割を果たしており，自動化，クラウドネイティブ*11化，およびマルチベンダ間の相互運用*12性の向上をめざして，他の標準化団体と連携しながら進化を続けている．
本稿では，ETSI ISG NFVと他の標準化団体の関係，オープンソースプロジェクトの役割について述べ，それらが連携したエコシステムについて解説する．

  1. NFV：通信事業者ネットワークのネットワーク機能を，仮想化技術によって汎用ハードウェアから分離する原理．
  2. QoS：ネットワークにおいて，パケットにマーキングして優先的に処理するなどの方法により，通信品質を適切に管理するための技術．音声通話などにおいて通話が途切れないようにデータ転送よりも優先するなどの処理を行う．
  3. ハンドオーバ：通信中の端末が，移動に伴い基地局やセルをまたがる際，通信を継続させながら基地局を切り替える技術．
  4. インフラストラクチャ：アプリケーションを実行するのに必要な物理的もしくは仮想的なデータセンタやサーバ，ネットワークなどの総称．
  5. VNF：仮想化された通信機能（通信システム）．
  6. COTS：汎用サーバ．HWとSW分離が可能になり，安価な汎用サーバを用いることが可能となった．
  7. 欧州電気通信標準化機構（ETSI）：ヨーロッパを拠点とする独立非営利の標準化団体(*9参照)機関．
  8. ETSI ISG NFV：ETSIに属するNFV ISGであり，NFVの標準仕様を推進する団体．
  9. 標準化団体：3GPP（*16参照），ETSI，O-RANなどの業界標準を作成・維持するグループ．
  10. エコシステム：複数の企業が連携して，お互いの技術や資産を活かし，社会を巻き込んで，技術開発から導入へと普及に至る一連の流れを形作る共存共栄の仕組み．
  11. クラウドネイティブ：オンプレミスではなく，クラウド上での構築運用を前提として設計されたシステムやサービスを指す．
  12. 相互運用：複数のサブシステム・装置・機能部などが，標準化やデファクトなどの決められた仕様やインタフェースによって接続し，システム全体として正しく動作すること．モバイルネットワークにおいては，さまざまなベンダの製品やソリューションを組み合わせて呼処理機能部，保守機能部，仮想化基盤などが3GPP（*16参照）やETSI ISG NFVによって規定された仕様に準拠し接続することで，特定のサブシステム・装置・機能部間やモバイルネットワーク全体が機能することを意味する．

02.ETSI ISG NFVと他の標準化団体の関係

NFVがモバイルネットワークの基盤として普及した背景には，複数の標準化団体との連携によってNFVの仕様化が推進されたことが大きな理由である．後述する標準化団体はETSI ISG NFVの補完的な役割をもち，それぞれが独自の技術フレームワークを提供することによって，NFVベースのモバイルネットワークにおけるアーキテクチャを確立した．図1は，NFVアーキテクチャと標準化団体の関係をまとめたものである．

図1　NFVアーキテクチャにかかわる標準化団体のスコープ

2.1 ETSI ISG NFV

ETSI ISG NFVは，NFV標準化を推進している主要な標準化団体であり，ネットワークサービスの仮想化とオーケストレーション*13に必要なリファレンスアーキテクチャ*14，機能コンポーネント*15，インタフェース，および情報モデルを定義している．ETSI ISG NFVの取組みは，ドコモを含む世界中の通信事業者が利用可能なさまざまな装置間で相互運用性を維持し，ベンダニュートラルなNFVアーキテクチャの基礎を築いてきた[2]．

2.2 3GPP SA5

3GPP（3rd Generation Partnership Project）*16 SA（Service and System Aspects）*175は，既存の通信機器の運用システムである，NFV-MANO（Management and Orchestration）*18を利用した仮想化されたモバイルネットワークの運用およびオーケストレーションの標準化に重要な役割を果たしてきた．3GPP SA5は，NFVの基本概念をコアネットワーク*19およびRAN（Radio Access Network）*20のドメイン*21に組み込み，仮想化されたネットワーク機能のFCAPS（Fault，Configuration，Accounting，Performance，Security）*22に関するキャリアグレードの標準[3]を提供してきた．ETSI ISG NFVが仮想リソース管理に重点を置いているのに対し，3GPP SA5は仮想化技術導入時の3GPPのモバイルネットワーク機能のアプリケーション部の管理に重点を置き，両者が連携することでモバイルネットワーク機能のアプリケーション部の実装や運用への影響を最小限に抑えることに成功している．その結果，非仮想化時代から利用しているドコモの既存のオペレーションサポートシステム（OSS：Operation Support System）*23をNFV-MANOに接続することが実現できている．

2.3 O-RAN

O-RAN ALLIANCE*24は，NFVの基本概念を基に，クラウドネイティブな分散型RANアーキテクチャの実現を推進している．その代表例が，ETSI ISG NFVおよび3GPP SA5アーキテクチャとの整合性を保ちながら，NFVの概念を組み込んだO-RAN SMO（Service Management and Orchestration）*25フレームワークである[4]．この取組みにより，ドコモは，O-RU（O-RAN Radio Unit）*26直接接続，高分散クラウドアーキテクチャ，高精度タイミングプロトコル（PTP：Precision Time Protocol）*27の実現など，無線固有の特性への対応を行いながら，RAN側でNFVフレームワークを再利用することができている．

2.4 IETF/IEEE

IETF（Internet Engineering Task Force）*28は，IPアドレス*29，時刻，URI（Uniform Resource Identifier）*30などの共通データモデルをもつRESTful API*31を含む，NFVフレームワークを補完する基本的なプロトコル仕様をETSI ISG NFVに提供してきた．また，ETSI ISG NFVとIETFは，トランスポートプロトコル*32の最適化やネットワーク構成モデルの標準化などにおいて緊密に連携し，ネットワークサービスの新しい運用形態の仕様化に貢献してきた．これらのプロトコル仕様は，分散ネットワーク環境全体でのシームレスな相互接続，オーケストレーション，および仮想化された機能の運用を可能にした[5]．
IEEE（The Institute of Electrical and Electronics Engineers）*33もVLAN（Virtual LAN）*34やEthernetのフレームなど通信に必須なデータモデルや仕様を提供しており，NFV仕様の基礎を担ってきた．
これらの重要なプロトコルなどの仕様と緊密な連携により，ドコモのような通信事業者は，シームレスな相互運用性，より高いリソース利用効率，および迅速な仮想化装置のデプロイ*35を実現できるようになった．

2.5 TM Forum

TM Forum*36は，保守機能のフレームワーク，ベストプラクティス，APIの包括的なセットを提供することで，通信事業者のデジタルビジネス変革を実現する上で重要な役割を果たしてきた．その中のODA（Open Digital Architecture）*37とOpen APIにおいては，ビジネスプロセスの自動化，サービスライフサイクル管理，および既存のOSS/BSS（Business Support System）*38システムとNFVのシームレスな統合に重点を置いてきた．そのためTM Forumは，ETSI ISG NFVによって規定されてきた標準仕様を，よりビジネスの観点から補完してきたといえる．

2.6 OASIS

OASIS（Organization for the Advancement of Structured Information Standards）*39 TOSCA（Topology and Orchestration Specification for Cloud Applications）*40標準は，NFVにおけるVNFの特徴や必要な要件を記述するテンプレートであるDescriptorの基本仕様を提供し，VNF用のDescriptorであるVNFD（Virtual Network Function Descriptor）*41とネットワークサービス用のDescriptorであるNSD（Network Service Descriptor）*42の基礎となっている．OASIS TOSCAはYAML（YAML Ain’t Markup Language）*43ベースのモデリング言語であり，さまざまなクラウド環境*44間で移植可能なテンプレートを目標に作られている．ETSI ISG NFVにおいては，ETSI GS NFV SOL001[6]を通じてDescriptorにVNFやネットワークサービスの要件を指定できるようにしている．
その結果，OASIS TOSCAは，標準化されたNFVモデリング要素*45，相互運用可能なサービスチェーンモデル*46，およびマルチクラウドデプロイ機能を備えた実装フレームワークを提供し，通信事業者においてNFV仕様を維持しながら，クラウドに依存せずベンダ仕様に左右されない標準的なテンプレートをETSI ISG NFVが提供することに大きく寄与している．

このように複数の標準化団体との連携を通じて，NFVは，コアからエッジまでの多様なネットワークドメイン間で堅牢で相互運用可能なデプロイを実現してきた．表1は，前述の標準化団体をまとめたものである．

表1　標準化団体の概要
  1. オーケストレーション：アプリケーションやサービスの運用・管理を自動化するために，必要なリソースやネットワークの接続を管理・仲介する技術．
  2. リファレンスアーキテクチャ：標準化やオープンソースなどの効率的な設計や実装のために，業界のベストプラクティスに基づいて考案されたシステムの構成やモデルの参照となるアーキテクチャのこと．
  3. コンポーネント：システム全体を構成する上でのサブシステムや部品．
  4. 3GPP：移動通信システムの規格策定を行う標準化団体．
  5. 3GPP SA：3GPPにおける，サービス要件，アーキテクチャ，セキュリティ，コーデック，ネットワーク管理を規定するワーキンググループ．
  6. MANO：欧州電気通信標準化機構によって定められた仮想資源マネジメント機能の総称．仮想化環境におけるHWリソース，SWリソースなどのVNF管理機能とオーケストレーション機能を提供する仕組み．
  7. コアネットワーク：パケット転送装置や加入者情報管理装置などで構成されるネットワークで，通常は他のネットワークと相互に接続される．移動端末はRAN（*20参照）を介してコアネットワークと通信する．
  8. RAN：コアネットワークと移動端末の間に無線基地局などを配置し，無線レイヤを制御するネットワーク．
  9. ドメイン：事業や技術の特定の領域．ここではモバイルネットワークの中のコアネットワーク，トランスポート，RANなどの特性の異なる領域を指す．
  10. FCAPS：通信事業者のネットワークの管理・監視項目である，障害（Fault），設定（Configuration），課金管理（Accounting），性能（Performance），セキュリティ（Security）を指す．
  11. オペレーションサポートシステム（OSS）：移動体通信ネットワークの障害や輻輳を発見し，制御や対策を行う事業者向けの運用支援システム．OSSは，通信事業者が提供するサービスを利用できるように，ネットワークやシステムの障害管理，構成管理，課金管理，性能管理，セキュリティ管理などを行う．
  12. O-RAN ALLIANCE：ドコモと海外の主要事業者が2018年2月に設立した，5G時代のオープンでインテリジェントなRANの実現をめざす業界・標準化団体．
  13. SMO：O-RANにおけるRANコンポーネントの管理，自動化，オーケストレーションを行うシステム．
  14. O-RU：O-RANにて規定されている，無線基地局の無線部．
  15. 高精度タイミングプロトコル（PTP）：ネットワークに接続された装置間で高精度な時刻同期をするためのプロトコル．時刻情報を配信する装置（Master Clock）がGPSに同期し，基地局がMaster Clockに同期することで，GPS時間を基準とした基地局間の同期を行う．
  16. IETF：インターネット技術標準の開発，推進を行っている標準化団体．ここで策定された技術仕様はRFC（Request For Comment）として公開される．
  17. IPアドレス：インターネットやイントラネットなどのIPネットワークに接続されたコンピュータや通信機器1台1台に割り振られた識別番号．
  18. URI：Webで利用できるリソースを示す識別子．RFC3986（Request For Comments 3986）にて規定．
  19. RESTful API：通信先の機能やデータをすべてリソースとして定義し，そのリソースに対してHTTPメソッド（GET，POST，PUT，PATCH，DELETE）で操作することを設計指針としたAPI．各リクエストは独立しており，サーバはクライアントの状態を保持しないことからステートレスな設計が可能となる．
  20. トランスポートプロトコル：トランスポート層で用いるプロトコル．インターネットにおける主なトランスポートプロトコルとしては，コネクション型のTCP（Transmission Control Protocol）と，コネクション・レス型のUDP（User Datagram Protocol）がある．
  21. IEEE：電気情報工学分野の技術を発展させることを目的とした世界最大の技術専門組織（国際学会）．
  22. VLAN：物理的な接続構成に依存せず，論理的なネットワークを構築することが可能な技術．通信ソフトウェアはさまざまなネットワークと接続されるので，それらを適切に分離するためにVLANを利用している．
  23. デプロイ：アプリケーションとその実行環境を配置・展開し，利用可能な状態にすること．
  24. TM Forum：電気通信分野のオペレーション業務における標準仕様を策定する非営利団体．
  25. ODA：TM Forumがビジネスのアジリティと顧客満足度の向上のために規定したアーキテクチャ．通信事業者に対してシステム構築から保全，顧客管理までの機能提供とそれらの自動化を提供する思想となっている．
  26. BSS：ビジネス支援システム．通信事業者における顧客管理やオーダ管理などに利用される．
  27. OASIS：情報社会のためのオープンな標準の開発を行う非営利のコンソーシアム．1993年にアメリカで設立された．
  28. TOSCA：OASISが定義するクラウド上で動作するシステムの構成を定義するための標準仕様．NFVではVNFD（*41参照）やNSD（*42参照）を記述するための言語仕様として利用している．
  29. VNFD：VNFの機能や振舞いを定義するテンプレート．
  30. NSD：VNFとの接続性やネットワークトポロジなどのネットワーク全体の機能や振舞いを定義するテンプレート．
  31. YAML：すべてのプログラミング言語で利用可能な，人間にとって読み書きしやすいデータ構造の記述記法およびフォーマット．
  32. クラウド環境：仮想化を実現するための仮想化プラットフォーム．VMware，OpenStack（*47参照），Kubernetes（*51参照）などが挙げられる．
  33. モデリング要素：管理対象を抽象化し表現した時の要素．NFVではVNFが利用するリソースや接続性，ライフサイクル管理に必要な設定情報などを簡略化し統一化しており，それらをVNFDに記述することでさまざまなオーケストレータで同一の制御が可能となる．
  34. サービスチェーンモデル：さまざまなネットワーク機能が相互作用して適切な順番にパケットを渡していく経路制御の技術とその表現手法

03.オープンソースのエコシステム

オープンソースのソフトウェアは，NFVの実装の基礎的な部品として機能し，標準と実際の開発の橋渡しをすることで，商用で利用可能なソリューションの構築に大きな役割を果たしてきた．過去10年間で，オープンソースによる基礎技術の発展は，ベンダによる商用製品化やデファクトスタンダードの確立，通信事業者によるさまざまなプロダクトやソリューションの採用を通じて，NFVフレームワークの成熟を推進してきた．インフラストラクチャの仮想化からモバイルネットワークサービスのオーケストレーションまで，オープンソースのエコシステムは，イノベーションを通じて開発コストを削減しつつ品質を維持し，NFVの普及を加速してきた．図2は，NFVのアーキテクチャとオープンソースのソフトウェアを提供する各プロジェクトの関係をまとめたものである．

図2　オープンソースのスコープ

3.1 OpenStack

OpenStack®*47は，NFVの業界標準のVIM（Virtualized Infrastructure Manager）*48として登場以来，コアネットワークを動作させる大規模なNFVI（Network Function Virtualization Infrastructure）*49を管理できるようにしてきた．OpenStackはNFVIから供給されるリソースを仮想リソースとしてさまざまな形態で提供可能であり，そのためのプロジェクトが多数存在している．特に主要な仮想リソースとしては，コンピューティング，ストレージ，およびネットワーキングサービスがあり，これらを管理する機能はキャリアグレードの仮想化のために必要であり，OpenStackの中でもコアな機能である[8]．OpenStackは通信事業者に広く採用され，NFVフレームワークの基本的な部品となるオープンソースの1つとして長期間にわたって発展してきた．

3.2 CNCF/Kubernetes

CNCF（Cloud Native Computing Foundation）*50は，NFVのクラウドネイティブ化へのマイグレーションにおいて重要な役割を果たしてきた．CNCFの代表オープンソースであるKubernetes®*51は，コンテナ*52用の業界標準のオーケストレーションプラットフォームとして認識されている．CNCF技術は，仮想化によってソフトウェア化されたモバイルネットワークサービスを，より先進的なネットワークとその運用へと変革を促進している[9]．

3.3 O-RAN SC

O-RAN準拠のオープンソースを提供するO-RAN SC（O-RAN Software Community）*53は，NFV Profile*54を通してNFVアーキテクチャの一部を採用している．特にSMOと，O-RANの仮想化基盤であるO-Cloudの接続においては，OpenStack Tacker*55を介してETSI ISG NFVで定義されたAPIを利用している．

3.4　ONAP

NFV仕様に対応したオーケストレーションと自動化を提供するONAP（Open Network Automation Platform）*56は，ETSI ISG NFVのMANOアーキテクチャとの緊密な連携を維持している．最近では，リアルタイムオーケストレーションやクローズドループ*57の実現に向けて，ONAPの中の一部のコンポーネントは進化しつつある[10]．

3.5　ETSI OSM

ETSIの配下で開発されたOSM（Open Source MANO）*58は，VNFオンボーディング*59用に最適化された軽量のNFV-MANOを提供している．OSMはNFV標準に準拠し，仮想化ネットワークサービスのライフサイクルを管理するための簡素化されたモジュラー型プラットフォームを提供している[11]．OSMの設計は，OSS，NFV-MANO，NFVIなどのインテグレーションの複雑さを最小限に抑えた軽量なオーケストレーションを指向しており，ETSI準拠のオーケストレーションを必要とする通信事業者の，PoC（Proof of Concept）*60や小規模な商用化に最適であった．これらの取組みを通して，小規模なモバイルネットワークを提供する通信事業者がNFV-MANOへ挑戦するきっかけを作ってきた[11]．

3.6　DPDK

DPDK（Data Plane Development Kit）*61は，NFVアーキテクチャにおけるパケット処理を高速化する基盤となるオープンソースフレームワークであり，カーネル空間*62をバイパスし，ユーザ空間*63からネットワークインタフェースへの直接アクセスを可能にすることで，伝送遅延を大幅に削減し，スループットを向上させている．これはキャリアグレードのNFV導入における重要な要件であり，従来のカーネルベースのネットワークスタックのようにDPDKが無ければ，パケット処理のオーバヘッドによりVNFのパフォーマンスを低下させるため，商用環境でのNFVにおいて必要なパフォーマンスを達成することが困難となる．DPDKは，OpenStackやKubernetesなどのNFVプラットフォームに包含されているため，高速データプレーン*64運用とオーケストレーション，そしてスケーラビリティの共存が可能であり，現代の通信事業者向けクラウドやエッジコンピューティング*65に不可欠な存在となっている．

これらオープンソースプロジェクトの詳細を表2に示す．これらのプロジェクトは，NFVの普及を推進し，通信事業者やベンダの商用開発によるイノベーションを引き起こし，大規模なエコシステムの形成に貢献している．
最後に，Linux Foundation*66のLFN（LF Networking）イニシアティブは，NFVの採用に貢献する複数の共同オープンソースプロジェクト（ONAPやOpenDaylight*67など）をホストおよび運営している．LFNは，オープンソース開発を業界標準に整合させるための環境を提供している[12]．

表2　主なオープンソースプロジェクトとその説明
  1. OpenStack®：サーバ仮想化技術を用いて，1台の物理サーバ上で複数の仮想サーバを稼働させるクラウドインフラソフトウェアである．仮想サーバを異なるユーザのクラウドサービスに割り当てることができる．OpenStack®はオープンソースソフトウェアである．
  2. VIM：物理コンピュータ，物理ストレージ，物理ネットワークからなる仮想化プラットフォーム上の物理リソースを管理するシステム．
  3. NFVI：ETSI ISG NFVで定義された，VNFが展開される環境を構築するすべてのハードウェアおよびソフトウェアコンポーネントの総称．クラウドプラットフォームを構成する汎用サーバ，ストレージデバイス，ネットワークデバイス，およびそれらの物理リソースを仮想化するための仮想化レイヤ上のソフトウェアの総称．
  4. CNCF：Linux Foundation（*66参照）のプロジェクトで，コンテナ（*52参照）技術の発展と，その進化に関連する技術業界の連携を支援するために2015年に創設された団体．
  5. Kubernetes®：複数のサーバで構成される大規模環境に向けて，コンテナ（*52参照）を管理するコンテナオーケストレーションツール．Kubernetes®はオープンソースソフトウェアである．
  6. コンテナ：ホストOS上に専用領域（コンテナ）を作成し，その中で必要なアプリケーションソフトウェアを動作させるコンピュータ仮想化技術．
  7. O-RAN SC：Linux Foundation（*66参照）の下で，O-RANアーキテクチャ用のソフトウェアを開発するオープンソースイニシアティブ．
  8. NFV Profile：O-RANにおける標準仕様のProfileの1つ．SMOとO-Cloudを接続するインタフェース（O2）において，NFV仕様を利用するNFV Profileと，Kubernetes APIを利用するK8s Profileがある．
  9. Tacker：OpenStackの一プロジェクトであり，ETSI ISG NFVの仕様に従ってVNFやCNF（Cloud native Network Function）のデプロイや制御を行うオープンソースソフトウェア．
  10. ONAP：ネットワークサービスやライフサイクル管理を自動化するオープンソースプラットフォーム．
  11. クローズドループ：運用の自動化を実現するもので，人手を介さずにネットワークや装置の状態変更に対応し，自動で制御し続ける仕組み．
  12. OSM：ETSIが主導するオープンソースのMANOを実装する団体およびその団体が開発したソフトウェア．現状はYANG model（*73参照）ベースのDescriptorを利用したNFVOとVNFMの機能をもつ．
  13. オンボーディング：VNF PackageをMANOシステムへ登録すること．
  14. PoC：新しいコンセプトやアイデアの意義や実現性を，簡易的に実現しデモンストレーションすること．
  15. DPDK：仮想スイッチにおけるネットワーク処理を高速化するための技術とそれを実装したソフトウェア．ユーザ空間（*63参照）で高速なパケット処理を実現するためのライブラリとドライバのセットで，カーネルのオーバヘッドを削減し，高スループットと低レイテンシを実現する．
  16. カーネル空間：メモリは仮想的に2つの領域に分けられており，OSのうちの基本機能が動作する部分をカーネル空間と呼び，通常のソフトウェアが動作するユーザ空間（*63参照）と分けて管理している．
  17. ユーザ空間：仮想的に分けられたメモリのうち，通常のソフトウェアが動作するメモリ領域．
  18. データプレーン：制御情報とデータの伝送路が分かれているような機器やネットワークで通信データの転送処理を行う伝送経路．
  19. エッジコンピューティング：端末に近い場所で計算処理を行うサービスの形態．通信における遅延の短縮や，ネットワーク負荷の分散などの効果が期待される．
  20. Linux Foundation：Linuxを標準化し，商用利用を促進するために設立された非営利の技術コンソーシアムであり，さまざまなオープンソースのプロジェクトが活動している．
  21. OpenDaylight：SDN（Software Defined Network）のコンセプトに基づいて，ネットワーク装置を外部から制御する機能を提供するソフトウェアの1つ．オープンソースソフトウェアとして提供されている．

04.標準化とオープンソースによるエコシステムの構築

標準化とオープンソースソフトウェアの相乗効果によるNFVのエコシステムの構築は，NFVがモバイルネットワークサービスの基礎として，さまざまな種類の装置の仮想化を支えていくための重要な取組みであった．標準化はアーキテクチャのビジョンやコンセプトを提供し，オープンソースプロジェクトはこれらの概念を実現可能な技術として実装してきた．

4.1 標準化からオープンソースへの実装

ETSI ISG NFVの標準仕様とオープンソースの関係は，OpenStackやKubernetesをテレコムで利用するところから始まり，ONAPやOSMなどのプロジェクトがETSI ISG NFV仕様を採用し，さまざまなプロジェクトが相互に補完しながら1つずつキーとなる技術が実現され，モバイルネットワークという広大なシステムを仮想化技術で実現するところまで至っている．このような歴史の中から必要技術が抽出され，それがソリューションやプロダクトとして実装・供給され，実際の通信事業者のモバイルネットワークに組み込まれて運用されるという持続可能な一連の流れが標準化とオープンソースが築いたエコシステムである．
このエコシステムは，通信事業者やベンダがモバイルネットワークの仮想化と，それによる開発や運用の効率化やハードウェアリソースの有効活用化をめざし，多くのオープンソースプラットフォームがNFVフレームワークの影響を受けてきたことで実現されてきた．DPDKやOVS（Open vSwitch）*68，Cilium*69のように仮想ネットワークリソースをVNFに提供しVNFを実現するために必要な機能，OpenStackやKubernetesのような，仮想化されたVNFを運用するために必要な機能，Prometheus*70やOpenTelemetry*71のようにVNFを監視する機能など，さまざまなコア技術をもつオープンソースが実用化されたことで，NFVのエコシステムは実現されてきた．
また近年では，O-RAN ALLIANCEのSMOフレームワークやONAPのオープンソースNFVプラットフォームをrApp*72ライフサイクルと連携して，さらに高度にオーケストレーション機能を発展させる取組みもみられる．

4.2 課題と対応

標準化とオープンソースの連携における大きな課題は，標準化がオープンソースの実装の後追いになることがあり得ることと，標準仕様とオープンソースの実装間のバージョンの不一致である．特に変化の激しいオープンソースは，標準仕様と整合が取れても次のバージョンでその仕様を維持するとは限らない．また，オープンソースと，標準仕様と，さらにオープンソース同士もそれぞれ独自の進化をするため，仕様として一貫性を保持できるバージョンを特定し，かつそのバージョンを通信事業者とベンダにとって最適な開発タイミングに合わせることは非常に困難である．特にマルチベンダの構成において，これらのバージョンの不一致や仕様の不整合は相互運用性のリスクを引き起こす可能性を高めることになる．
そこで，ETSI ISG NFVが主導して，標準化とオープンソースが連携した標準化準拠のテスト，共同作業グループを通したギャップ分析，PoC検証を通じた仕様や実装の改善を行ってきた．これによりイノベーションのスピードを維持しながら，これらのギャップを埋めることができた．

4.3 エコシステムのさらなる発展

NFVの進化は，標準化団体とオープンソースコミュニティの連携を通じた，相互運用性の維持と仕様の持続的な改善により実現している．
重要な機会の1つはデータモデルの調和にある．ETSI ISG NFVは他の標準化団体の仕様であるYANG（Yet Another Next Generation） model*73/TOSCAベースのモデルを規定しており，ETSI ISG NFVとして一貫したこれらのモデリングを行うことで，オープンソースをベースとした複数の装置やソリューションの結合の問題を減らすことができている．さらに標準化団体（ETSI，3GPP，O-RAN）とオープンソースプロジェクト（OpenStack，Kubernetes）との連携は，よりスケーラブルかつシンプルなアーキテクチャを実現し，仕様としても実装としても商用環境で持続可能的に利用できる，より良いアーキテクチャのエコシステムに進化させることに貢献している．また，オープンソースと標準化が連携したプロトタイピング*74やPoC，Plugtest*75などの取組みは，標準仕様を検証しつつ，仕様の洗練化を支援することにも繋がる．
もう1つは，Releaseの同期と技術的前提の一致化にある．標準化と実装の間でスケジュールと抽象化レベルが異なると，マルチベンダシナリオでの展開が不十分になるリスクがあり，これらを橋渡しするために，共同ワーキンググループ，共有リファレンス実装，実環境でのテストベッド*76による標準仕様とオープンソースの双方向でのコミュニケーションが必要となる．これらを行うことでマルチベンダシナリオでの展開が不十分になるリスクを避けることができる．

  1. OVS：仮想化環境において，仮想マシン間を接続するスイッチを実現するソフトウェアの1つ．オープンソースとして提供されている．
  2. Cilium：クラウド環境におけるネットワークを制御するソフトウェア．Side carが不要でLinuxカーネル機能のeBPF（extended Berkeley Packet Filter）で制御している．
  3. Prometheus：システムやアプリケーションのメトリクスを収集するモニタリングツール．ExporterというAgentをインストールすることで監視可能になるため，クラウドネイティブな環境やマイクロサービスアーキテクチャなどで利用されることが多い．
  4. OpenTelemetry：分散システムにおいて可観測性を向上させるためのオープンソースプロジェクトおよびソフトウェア．
  5. rApp：O-RANにおけるSMOの中のNon-Real Time RIC上で動作する自動化のためのソフトウェア．
  6. YANG model：RFC 6020に基づいてネットワーク機器の機能や接続をモデリング化した言語．
  7. プロトタイピング：検証・フィードバックのため，検討早期に実働モデルを製作する手法．
  8. Plugtest：NFVの導入と相互運用性を加速させるため，ETSI ISG NFVで実行されているさまざまな組織間（プロダクトベンダなど）での共同テストプログラム．
  9. テストベッド：技術方式の実現性確認や性能評価などを行うための実証検証設備．

05.あとがき

本稿では，ETSI ISG NFVを中心としたさまざまな標準化団体とオープンソースの連携，およびモバイルネットワークの基礎を支えるエコシステムの背景について解説した．
NFVは，動的でスケーラブルかつプログラマブルなネットワークを構築するための基盤技術に進化してきた．ETSI ISG NFV，3GPP SA5，O-RAN Alliance，IETFなどの標準化団体は，信頼性の高い仮想化インフラの展開を可能にするアーキテクチャを確立しており，オープンソースエコシステム（OSM，ONAP，OpenStack，Kubernetes）は，これらの標準を実現可能なソリューションに変換して革新的なプラットフォームを提供することと，標準仕様を検証することの両方の役割を果たしている．しかし，NFVの可能性を最大化するには，データモデル，インタフェース，リリースサイクルにおける標準化とオープンソースのさらなる緊密な整合性が必要である．これは，実装の共有と通信事業者からのフィードバックによって達成でき，ドコモは，業界のリーダーとして，標準化団体（ETSI，3GPP，O-RAN）とオープンソースプロジェクト（OpenStack Tacker，Kubernetes）の両方に対し積極的に貢献することで，標準仕様とオープンソースの緊密な関係の維持を実現してきた．ドコモは今後も，これらの取組みにより，クラウドネイティブネットワークのイノベーションの最前線に立ち，エコシステム全体での相互運用性を推進していく．

文献

Vol.33 No.3 表紙に戻る
NTTドコモ テクニカル・ジャーナルTOP
このページのトップへ