共創のご相談はこちら
2025年10月 RAN仮想化（vRAN）特集（2）

大規模仮想化ネットワークを統合制御するSMOの実用化

  • ＃5GE&6G
  • ＃無線通信
  • ＃ネットワーク
English

谷口 航介（たにぐち こうすけ）
相馬 悠人（そうま ゆうと）
クラウドデザイン室

田辺 賢史（たなべ　けんし）
福田 太（ふくだ ふとし）†
RAN技術推進室

鈴木 吉行（すずき よしゆき）
駒嵜 雅則（こまざき まさのり）
ドコモ・テクノロジ株式会社　コアNW事業部

†　現在，NTT株式会社

あらまし

ドコモでは，2023年より無線アクセスネットワーク装置の仮想化を推進している．大規模導入する仮想化された無線アクセスネットワーク装置（VNF）の迅速かつ効率的な構築・運用を実現するため，O-RAN標準仕様に準拠したSMOシステムを開発し，導入した．本稿では，SMOの実用化開発について解説するとともに，海外展開を視野に入れた将来展望を示す．

01.まえがき

近年，汎用ハードウェア・アクセラレータ*1の性能向上や仮想化*2技術の進歩により，世界的に仮想化された無線アクセスネットワーク（vRAN：virtualized Radio Access Network）*3の製品開発が加速している．これらは，汎用ハードウェア導入による設備コストの削減，仮想化技術やAI技術を活用した構築・保守業務のインテリジェント化によるオペレーションコストの削減や，通信サービスの信頼性向上に繋がるものと期待される[1]．
ドコモでは，2021年2月より5GオープンRANエコシステム（OREC：Open RAN ECosystem）*4の協創プログラムを立ち上げ，多くの参画ベンダとともに，O-RAN（Open RAN）*5とETSI（European Telecommunications Standards Institute）*6 NFV（Network Functions Virtualization）*7に準拠したオープンvRANエコシステムを評価・開発することで，技術的な課題を解消してきた．また，O-RANサービスブランドであるOREX（Open RAN Ecosystem Experience）*8を海外展開するとともに，日本国内においては，2025年にvRANの商用導入を開始している．
vRANの国内導入においては，仮想化された通信ソフトウェアであるVNF（Virtual Network Function）*9，ならびにVNFを配備する分散型コンテナ仮想化基盤O-Cloud*10を全国規模で展開していくが，このような大規模運用を実現するためには，建設・保守業務の自動化が必須である．そこでドコモでは，O-RANのコンポーネント*11であるSMO（Service Management and Orchestration）*12を開発・導入することによる建設・保守業務の自動化を実現した．
本稿では，ドコモが開発・導入したSMOを概観するとともに，SMOに関する要求条件を明らかにする．また，SMOを構成する各システムコンポーネントの開発方針，課題とその対策，システム構成技術を解説した上で，システムコンポーネント間の効率的な連携による高度な自動化の実現方式について解説し，海外販売を見据えたSMOの将来展望について述べる．

  1. アクセラレータ：CPUや，画像表示などの処理性能を向上させるための周辺機器や付加装置のこと．本稿では，通信用CPUの処理速度を向上させるために追加したLSIをいう．
  2. 仮想化：CPUやメモリなどのハードウェアリソースをソフトウェアによって論理的に分割，または，それらの動作を再現することで，仮想的な計算機環境やハードウェアリソースを作り出す技術．仮想化により物理リソースを論理的に分けて利用することができる．
  3. 仮想化された無線アクセスネットワーク（vRAN）：無線アクセスネットワークに対して，汎用プロセッサやアクセラレータなどを用いた仮想化技術を活用することで，よりオープンで柔軟性が高い形で実装する無線アクセスシステム．
  4. 5GオープンRANエコシステム（OREC）：多様なニーズに応えられる柔軟なネットワークの構築を可能とする，オープンな無線アクセスネットワークの海外展開を目的としたドコモとパートナー会社の取組み．
  5. O-RAN：O-RAN Allianceにおける標準化において，3GPP（*73参照）の仕様の範囲外である基地局の実装や運用の自動化に関する仕様を定めたもの．
  6. ETSI：欧州の電気通信技術に関する標準化団体．
  7. NFV：通信キャリアのネットワークを仮想化技術により汎用ハードウェア上で実現すること．
  8. OREX：ドコモが提供する，O-RANを活用した通信インフラ構築支援サービス．
  9. VNF：VM上で動作し，ソフトウェアで実装された通信機能を指す．
  10. O-Cloud：O-RAN仕様にて規定されている，O-CU/O-DUを配備するための仮想化基盤とその関連コンポーネント（*11参照）の集合体．
  11. コンポーネント：本稿では，O-Cloudに必要な機能を提供する機能部をいう．
  12. SMO：O-RAN仕様にて規定されているvRANにおいて，NF/O-Cloudの管理とオーケストレーション（*71参照）を行うシステム．

02.SMO概要

2.1 SMOの構成と期待される役割

SMOは，VNFとO-Cloudを制御するためのFOCOM（Federated O-Cloud Orchestration and Management）*13とNFO（NF Orchestration）*14，スライス管理のためのNSMF（Network Slice Management Function）*15，VNFのFM（Fault Management）*16・PM（Performance Management）*17・CM（Configuration Management）*18のためのNFMF*19，自動制御／最適化のためのRIC（Ran Intelligent Controller）*20の論理機能から構成される（図1）．
FOCOMは，O-CloudのInventory管理*21・FM・PMを行い，NFOはO-Cloudと連携してVNF Deploymentのライフサイクル管理・FM・PMを行う．NFMF/NSMFは，VNF／スライスのInventory管理・FM・PMを行う．RICはAI/ML（Artificial Intelligence/Machine Learning）*22を利用して収集したvRANアプリケーション情報に応じた最適化とCM制御を行う．
vRANには，従来の専用装置で構成されたRAN*23に比べ，可用性・拡張性の向上と同時に，安価なハードウェアの利用・仮想リソースの共有による設備投資の削減，建設・保守業務の効率化など，コスト構造改革に寄与することが期待されている．SMOには，これらのメリットを最大化する効率的かつ統一的な制御の提供が求められている．さらに，保守効率の抜本的な向上に向けて，ZTO（Zero-Touch Operation）*24の実現やAI技術を活用した動的なパラメータチューニングとの連携が行えるようなアーキテクチャの実現が期待されている．

図1　vRANアーキテクチャにおけるSMOの位置付け

2.2 ドコモのSMO開発方針

VNFは，多くの通信ソフトウェア開発ベンダにより製品化されており，各VNFの製品特性やベンダ戦略により，対応する仮想化プラットフォームが選定されている．近年，VNFはベアメタルコンテナ方式*25を採用する製品が多いため，O-Cloudは，Kubernetes*26をベースとした製品が主流であり，該当する仮想化プラットフォーム製品として，RedHatOCP*27，Windriver CP*28，EKS-Anywhere*29，VMWareTanzu*30などが挙げられる．ドコモ導入については，vRANアプリケーション／O-Cloudともマルチベンダ構成となることを想定して，どのような組合せでも対応できるvRAN開発を進めてきた．ドコモにおける仮想化プラットフォームの国内導入においては，VNFは数十万インスタンス*31，O-Cloudは数百クラスタ*32に及ぶものと想定される．このような全国規模のプラットフォームに対して安定した通信サービスを提供するために，SMOは効率的かつ統一的な構築・保守手段を提供する．
vRANにおけるVNFとO-Cloudはそれぞれマルチベンダ構成となることが前提となるが，そのような構成における，建設・保守業務の統一や自動化に向けた柔軟な開発を行うため，SMOを自社開発することとした．なお，国内導入におけるFOCOM，ならびにFOCOMからの制御を受けるIMS（Infrastructure Management Service）*33については，標準仕様と製品の成熟状況をかんがみ，現時点では自社開発を見送り，O-Cloudベンダ製品の提供機能を利用することとした．FOCOM，IMSの詳細仕様については，本誌過去記事を参照されたい[2]．また，RICは自社開発を選択しているが，詳細仕様については本特集別記事を参照されたい[3]．

  1. FOCOM：ネットワーク障害，構成，パフォーマンスを監視・管理するシステム．
  2. NFO：仮想およびクラウドネイティブのネットワーク機能を調整・管理するシステム．
  3. NSMF：ネットワークスライス単位で監視・制御する機能部．
  4. FM：管理オブジェクトのアラーム一覧取得，アラーム通知，削除などの故障管理のこと．
  5. PM：管理オブジェクトの性能測定情報の登録，取得，通知などの測定項目管理のこと．
  6. CM：管理オブジェクトの通信設定などの構成管理情報のこと．
  7. NFMF：1つ以上のNFに対して，マネジメントサービスを提供する機能部．
  8. RIC：RAN（*23参照）のインテリジェント化を担う制御部．
  9. Inventory管理：物理装置や仮想化されたネットワーク装置などのリソースの状態や使用状況を管理すること．
  10. AI/ML：モデルを用いて推論すること，および，推論に用いるモデルを機械学習により生成すること．
  11. RAN：3GPP（*73参照）において，コアネットワーク（*39参照）と端末の間に位置する，無線レイヤの制御を行う基地局などで構成されるネットワーク．
  12. ZTO：人手の介在無く，オペレータ（*67参照）の通信システムの運用が実現できる思想．
  13. ベアメタルコンテナ方式：VM（*38参照）を介さず，物理サーバ（ベアメタル）上に直接ホストOSとコンテナランタイム（*79参照）を構築し，コンテナアプリケーションを実行するアーキテクチャ．仮想化オーバヘッドを排除しつつ，コンテナ技術の軽量性と高速性を最大限に活用する方式．
  14. Kubernetes：CNCF（Cloud Native Computing Foundation）にて管理されている複数サーバで構成される大規模環境向けのコンテナ管理を目的としたオープンソースのコンテナオーケストレーションツール．
  15. RedHatOCP：Redhat社のエンタープライズ向けKubernetes統合プラットフォーム製品．
  16. Windriver CP：Windriver社のエンタープライズ向けKubernetes統合プラットフォーム製品．
  17. EKS-Anywhere：AWS社提供のエンタープライズ向けのオンプレミス用Kubernetes統合プラットフォーム製品．
  18. VMWareTanzu：VMWare社のエンタープライズ向けKubernetes統合プラットフォーム製品．
  19. インスタンス：共通的なテンプレートから生成される，VNFの個別に展開された実行環境または稼働中のユニット．
  20. クラスタ：Kubernetesにおける最も基本的な論理・物理的な実行単位であり，コンテナ化されたアプリケーションのデプロイ（*45参照），スケーリング（*52参照），可用性確保，運用管理を統合的に行うためのノード（*80参照）群（Node set）と制御プレーン（*69参照）から構成される集合体．
  21. IMS：クラウドリソースのライフサイクル管理を提供する機能部．

03.VNFの統合ライフサイクル制御を実現するNFOの実用化開発

3.1 コア／無線ネットワークの統合仮想化ライフサイクル制御

これまで，通信ソフトウェアの仮想化は，OpenStack*34，VMWare vSphere*35，AWS EC2（Amazon Web Services Elastic Compute Cloud）*36などを利用した仮想化プラットフォーム上の仮想サーバにGuestOS*37を含むアプリケーションを展開するVM（Virtual Machine）*38方式が主流であり，ドコモのコアネットワーク*39においても，OpenStackベースの仮想化プラットフォーム上で各種VNFの仮想化を実現してきた．
一方，近年，ベアメタルコンテナ方式の仮想化通信ソフトウェアが増加傾向にあり，同一ネットワーク内にVMとコンテナが混在するようになってきている．以前から仮想化が進んでいたコアネットワークにおいては現在もVMが多く運用されているものの，新たな仮想化対象領域である無線装置の通信ソフトウェアや，コアネットワーク内においても比較的新しい通信ソフトウェアに関しては，コンテナを活用した仮想化通信ソフトウェアも主流化してきている．このためNFO機能部は，同一ネットワークに混在するVM・コンテナ方式のVNFに対しても，統合的なライフサイクル制御を実現する必要がある．そこで，ETSI NFVのMANO（Management and Orchestration）*40仕様に準拠したNFOの機能開発を行うことで，NFOに求められるVNFライフサイクル機能を提供しつつ，コア／無線ネットワークの両方に対応できる汎用性の高い機能実装，ならびに，既存の技術資産の流用をめざした．

3.2 オープンソースソフトウェアを活用した経済的なシステム開発

ドコモは，ETSI NFVにおける標準仕様の策定実績やコアネットワークの仮想化運用の経験を基に，MANOのオープンソースソフトウェア*41開発コミュニティである，OpenStack Tackerプロジェクトに参画し，MANOソフトウェアの発展を牽引している．OpenStack Tackerの発展は，MANO領域のスタンダード化とソフトウェアの経済化をもたらすものと期待される．OpenStack TackerはETSI NFVに準拠した，VM・コンテナ型VNFのライフサイクル制御をサポートしているため，NFOのシステム開発にあたっては，このソフトウェアを積極的に利用することで，ドコモでの実装範囲を限定，ならびに標準仕様準拠のIF対応によるVNFのインテグレーション工数を削減し，経済的なシステム開発を中長期的に行うこととした．このシステム開発に伴い，多くの仮想化プラットフォーム製品との接続性を確認しており，仮想化プラットフォームのマルチベンダ化を実現できる．

3.3 NFO機能部概要

実用化したNFO機能部のシステム構成を図2に示す．NFOはNFVO（NFV Orchestrator）*42機能部とVNFM（VNF Manager）*43機能部で構成される．
（1）NFVO機能部
NFVO機能部は，仮想化プラットフォーム上の仮想リソースのキャパシティ管理，コンテナイメージ管理やVNF Packageの管理ならびにVNFM機能部への流通機能を具備している．VNF Packageは，VNFのテンプレートとなる資材をパッケージ化したものであり，VNFの構成や必要リソースを定義するVNFD（VNF Descripter）*44と仮想化プラットフォームにアプリケーションをデプロイ*45するためのHOT（Heat Orchestration Template）*46やHelmchart*47，Imageファイル*48で構成される．VNF Packageの仕様はETSI NFV SOL001/004にて定義され，VM・コンテナから構成される仮想リソースの定義情報（HOT，Helmchart）が格納可能であることから，VM・コンテナ方式を統合したVNFライフサイクル制御が可能となる．
（2）VNFM機能部
VNFM機能部は，仮想化プラットフォームと接続し，VNFのライフサイクル制御のための，仮想リソースの制御を行う．ライフサイクル制御とは，VNFのインスタンシエーション*49，ターミネーション*50，ヒーリング*51，スケーリング*52，アップデートを指す．本機能を提供するソフトウェアがOpenStack Tackerそのものである．OpenStack Tackerは，内部にHOT生成機構とHelm Client*53機構を具備していることに加えて，各製品の仕様差分を吸収するためのアダプタ機構を有するため，前述したさまざまな仮想化プラットフォーム製品に対しても，接続が容易となっている．
OpenStack Tackerのソースコードは，VNFのライフサイクル制御のためのワークフローの実装とETSI NFVに準拠したAPI（Application Programming Interface）*54の提供を行っており，NFVO機能部，OSS（Operation Support System）*55と連携した高度なVNFのライフサイクル制御が可能となっている．ただし，商用化に向けては，Tackerが提供する機能に加えて，商用運用のためのO&M（Operation & Maintenance）機能，拡張性向上のための処理分散機構，可用性向上のための冗長構成，データベース管理機構の実装が必要となる．また，NFOは数十万インスタンスのvRANを収容することから，VNFライフサイクルの数百以上の同時実行制御や各機能部の拡張性，ライフサイクル制御の自動化のためのZTOやインテリジェント化の実現も求められる．ドコモ網への導入を見据えたこれらの拡張開発に高い同時実行制御の実現が必要であるため，制御要求のキューイング*56処理の実装やTacker機能部のスケーリングによる処理性能の向上が可能な構造とした．ZTOに関しては，NBI（NorthBound Interface）*57をZTOに向けて開放することで，VNFライフサイクル制御のZTOの実現を可能としている．

図2　NFOのシステム構成と統合ライフサイクル制御
  1. OpenStack：OpenInfra Foundationで管理されている，複数サーバで構成される大規模環境向けのVM（*38参照）管理を目的としたオープンソースのVMオーケストレーションツール．
  2. VMWare vSphere：VMWare社が提供する仮想化ソリューション．
  3. AWS EC2：AWS社が提供するパブリッククラウドサービス．
  4. GuestOS：VM（*38参照）上で動作するOS．
  5. VM：物理的なコンピュータ上で動作する仮想的なコンピュータ．
  6. コアネットワーク：ゲートウェイ装置，位置管理装置，加入者情報管理装置などで構成されるネットワーク．移動通信システムを構成するネットワークのコア部分．移動機は無線基地局などで構成される無線アクセスネットワークを経由してコアネットワークとの通信を行う．
  7. MANO：ETSI NFV ISGにて標準化されている，VNFへのライフサイクル機能を提供する論理機能部．
  8. オープンソースソフトウェア：ソースコードが無償で公開されており，誰でも再利用や改変が行えるソフトウェア．ただし，原作者の著作権自体は放棄されておらず，派生物を作成した場合や再配布を行った場合にも，元の著作権表示を保持することが求められる．
  9. NFVO：ETSI NFVにて定義される，各種通信ソフトウェアの生成から削除までの管理を行い，システム全体の運用管理を行うためのコンポーネント．複数の仮想化プラットフォーム上に展開されるVNFのリソース調停を行う．
  10. VNFM：ETSI NFVにて定義される，仮想化された通信機能や通信システム（VNF）のライフサイクル制御として起動や停止などVNFの制御を担うコンポーネント．
  11. VNFD：VNFの仮想リソース構成，機能や振舞いを定義するテンプレート．
  12. デプロイ：アプリケーションやコンテナ，VMなどをそれらの実行環境に配置して展開すること．
  13. HOT：OpenStackにおいて，オーケストレーション（*71参照）サービス「Heat」で使用されるテンプレートファイル．
  14. Helmchart：Kubernetesにおけるリソースの集合体をパッケージとしてHelmが管理するテンプレートファイル．
  15. Imageファイル：コンテナやVMのソフトウェアの実体となる実行ファイル．
  16. インスタンシエーション：VMを生成することを意味する．物理マシンへのVMのインストール，仮想ネットワーク設定，VM起動，その他各種設定の投入を経てソフトウェアが起動され，利用できる状態にする一連の動作を指す．
  17. ターミネーション：VNFを停止し，仮想化基盤上から削除すること．
  18. ヒーリング：ハードウェア障害やVM障害が発生した際に，正常なハードウェア上にVMを移動または再生成することで通信ソフトウェアとして正常な状態に復旧する手続き．
  19. スケーリング：ハードウェアやVMの負荷状況に応じて通信ソフトウェアとしての処理能力が不足，あるいは余剰になった際に，通信ソフトウェアを構成するVMを増減することにより処理能力を最適化すること．
  20. Helm Client：Kubernetes環境において，Helmパッケージマネージャのユーザ側の操作IFを提供するコンポーネントであり，Helmコマンドを通じてチャートの管理・操作を行うためのツール．
  21. API：ネットワークを構成するコンポーネントが提供するソフトウェアの機能を他のプログラム，システムから利用できるように切り出したIF．
  22. OSS：移動体通信ネットワークの障害や輻輳を発見し，制御や対策を行う事業者向けの運用支援システム．OSSは，通信事業者が提供するサービスを利用できるように，ネットワークやシステムの障害管理，構成管理，課金管理，性能管理，セキュリティ管理などを行う．
  23. キューイング：待ち行列を作成し，処理する順番や処理する内容を一時的に保存しておくこと．
  24. NBI：特定のソフトウェアコンポーネントがより上位・抽象化されたコンポーネントに対して提供するIFのこと．

04.vRANアプリケーションの高度な制御・運用を提供するNSMF/NFMFの実用化開発

OSSの主な機能部はスライス監視機能（NSMF）と，NF監視機能（NFMF）に分けられる．vRAN監視のOSSの場合，RAN-NSSMF（RAN Network Slice Subnet Management Function）*58機能部が，NSMFで管理するE2E（End-to-End） Network Slice*59の一部であるRANドメイン*60のSlice Subnetの管理を行い，スライスごとの監視（FM，PM）や構成情報管理（CM）を行う．またNFMF/EM（Element Manager）*61機能部が，vRANアプリ（vCU（virtualized Central Unit）*62，vDU（virtualized Distributed Unit）*63）の，VNFごとの監視（FM，PM）や，構成情報管理（CM）を行う．
OSS構成と接続する各コンポーネント間のIFについて，以下に記載する（図3）．
（1）OSSとベンダEM間IF
vRANアプリ監視については，FM，PM，CMともにベンダEMを経由してOSSで実施する．OSSがベンダEMからFM，CM通知を受信．もしくはベンダEMからFM，PM，CM情報を取得することで監視を行う．
本機能を実現するためのOSSとベンダEMのIFについて，OSSの開発段階では，SA5-IFとO1-IFを比較し，完成度が高いSA5-IFを採用した．今後のOSSのロードマップにおいても，OSSとベンダEM間のIFをSA5-IFで続け，O1-IF標準化が進んだ際にGenericEM機能*64をOSSで具備し，ベンダEMを介さず監視・制御する対応をめざす．
なお，マルチベンダのvRANをOSSで収容する場合，SA5-IF上でプロトコルやデータフォーマット，データモデルは規定されているが，ベンダごとに保持するCMデータのパラメータ項目の有無や，共通パラメータの中でもデータ配列の差分など，共通化が実現できていない箇所が存在している．OSSがvRAN開発ごとにベンダ差分の対応をすることは影響が大きいため，すべてのパラメータからユーザが選択して編集・登録可能なUIとする対応とした．
（2）OSSとNon-RT（Real Time） RIC*65間IF
OSS-Non-RT RIC間のIFは規定されておらず，OSSとNon-RT RICはそれぞれ独立での海外導入を見据えているため，他製品との接続を見越して一般的なREST（REpresentational State Transfer）*66-IFで対応した．
（3）OSSと外部システム間IF
OSSが保持するFM/PM情報取得および，vRANに対するCM制御を，外部システム向けに開放し，海外のオペレータ*67が保持する外部システムからも取得，制御可能とする．外部システム側が簡易に実装可能となるよう，開放するプロトコルはSFTP（SSH File Transfer Protocol）*68/RESTとしている．

図3　OSS構成と接続する各コンポーネント間のIF
  1. RAN-NSSMF：RANドメイン（*60参照）におけるスライスのライフサイクル管理（作成，変更，削除）を担うコンポーネント．
  2. E2E Network Slice：5Gネットワークにおいて，ユーザまたはサービスの要求に応じて，複数のドメイン（*60参照）を横断して構成される仮想的なネットワークの論理的区分．
  3. ドメイン：ネットワーク全体を構成する複数の技術領域（例：無線アクセスネットワーク，トランスポート，コアネットワークなど）を論理的に分割した管理単位．
  4. EM：個々のネットワーク装置に対する障害（Fault）・設定（Configuration）・課金（Accounting）・性能（Performance）・セキュリティ（Security）（通例FCAPSと呼ばれる）の管理・監視を担う機能ブロック．
  5. vCU：仮想化環境で上位層の処理機能を管理するソフトウェアベースのRANコンポーネント．
  6. vDU：リアルタイムの信号処理を行い，クラウド基盤上で動作するソフトウェアベースのRANコンポーネント．
  7. GenericEM機能：特定の通信装置ベンダの仕様や装置種別の仕様に依存せず，共通的なFCAPSを提供できるEM．
  8. Non-RT RIC：O-RAN Allianceにおいて，リアルタイム性が求められないことに対してインテリジェンスな制御を行うシステム．
  9. REST：APIの1つで，各リソース（URL）に対してGET，POST，PUT，DELETEでリクエストを送信し，レスポンスをXML（eXtensible Markup Language）やjsonなどで受け取る形式．
  10. オペレータ：移動通信システムのインフラストラクチャを構築・保有し，エンドユーザに対して通信サービスを提供する通信事業体．
  11. SFTP：SSH（Secure Shell）プロトコル上で動作する安全なファイル転送プロトコル．

05.システム間連携によるシンプルかつインテリジェントな保守・運用の実現

5.1 SMOを構成するシステム間連携

仮想化によりソフトウェアとハードウェアの分離がなされた環境においては，従来の保守・操作とは異なり，ソフトウェア制御と仮想リソース制御を連携させつつ，制御システム（NSMF/NFMF/FOCOM/NFO/O-Cloud）が保持する管理情報の整合性を常に維持するシステム間の連携の仕組みが必要である．さらに，NFOが提供する仮想リソースの制御においては，O-CloudのKubernetes層の制御プレーン*69と連携し，適切な機能分担の下で行う必要がある．
ここで注意すべきは，開発システムの運用を担う保守者が，仮想化技術に関する高度な専門知識を有していない点である．そのため，仮想リソースの複雑な運用管理は保守者向けに適切に抽象化・隠蔽され，従来の保守手法を踏襲した操作性を維持することが開発システムに求められる．
以下では，これらの要求事項を満たすためのシステム間連携方式について解説する．なお，NFOは前述のとおりVM／コンテナの両技術に対応可能だが，今回はvRANにおいて主流のコンテナ技術を用いた場合に着目して解説する．
（1）O-CloudとNFOの機能分担と連携方式
O-CloudはKubernetesをベースに構成されており，宣言型定義*70に基づいた仮想リソースのオーケストレーション*71機能を具備している．他の業界においては通常，Helmchartなどで定義されたリソース単位やPod*72単位で保守・監視が行われることが多いが，通信事業者においては，アプリケーション調達単位や構成情報の管理単位，保守のシンプル化の観点からの3GPP（3rd Generation Partnership Project）*73定義のNF*74単位／ETSI NFV定義のVNF/VNFc（VNF components） Instance*75単位で管理が行われることが一般的である．そこで，O-Cloudを構成するKubernetesの提供するオーケストレーション機能を活用しつつ，VNF/VNFc Instance単位での抽象化を実現するために，VNF/VNFc定義とKubernetesリソースのマッピング，VNFM機能部の仮想リソースのポーリング*76機能を開発した．以下にその詳細を述べる．
①VNF/VNFc定義とHelmchart管理のKubernetesリソースのマッピング方式
前述したとおり，NFOが利用するVNF Packageは，VNFDとHelmchartの両方を含むパッケージ構成となっている．
VNFDにおいては，VNF Instance*77とその構成単位であるVDU（Virtual Deployment Unit）*78の定義やVNFライフサイクル関連情報などの，保守者が日常運用において意識するようなネットワーク全体の制御層（OSS，MANOなど）における管理単位の情報を定義し，Helmchart上には，各VDUを構成するKubernetesリソース情報（Pod/Deployment/Serviceほか）とその要求計算資源などのO-Cloudのコンテナランタイム*79に要求する具体的な情報の定義を行う．
これらのテンプレートの定義情報をVDU・リソース名称の統一により共通化する（図4）．VNFM機能部は，この共通化された定義に基づき，VNFレベルと仮想リソースレベルの情報を管理・解釈することができ，OSSや保守者からのVNFライフサイクル指示を，O-Cloudに対するKubernetesのオーケストレーション操作へ変換・連携することができる．
②Kubernetesの動的なリソース制御とのリアルタイムな情報連携方式
O-Cloudに配備されたVNFを構成するKubernetesリソースは，O-Cloud内のノード*80障害などにより，動的に再構築・再配置される．その際，O-Cloudが管理するPod名／Kubernetesリソース名は動的に変更されるが，VNFM機能部はこれらの変更においてもVNF/VNFc Instance情報と最新のリソース情報を紐づけする必要がある．
この課題を解決するためVNFM機能部は，O-Cloudに対して仮想リソース管理情報を定期的にポーリングし，VNFM内部の管理情報と動的に紐づけを行う機能を具備することで，O-Cloud内の動的なリソース更新に追従できるようにした．
（2）OSSとNFO間の機能連携方式
仮想化環境では，OSSで監視・収集したVNFのアプリケーションのFM・PM情報を基に，保守操作自体はVNFアプリケーションと仮想リソースの両方に対して行うユースケースが多く存在する．VNFアプリケーションとVNFを構成する仮想リソースを一意に特定し，それらが連動した保守操作を提供するには，それぞれの監視・制御装置であるOSSとNFO間でリアルタイムな情報連携が必要となる．
本開発では，両機能部が同様の対象を常に認識するため，それぞれの標準定義上のVNFの識別子などをキー情報としてOSS/NFOの名称を統一する方式を採用した．具体的には，3GPP SA（Service & Systems Aspects）5*81で規定されているOSSが扱うManagement Element ID[4]と，NFO管理のETSI NFV SOL001準拠のVNF Instance nameを，VNFのインスタンス名称固有の文字列として共通化した．これより，OSS・NFO間にてETSI NFV SOL002準拠のIF経由で，共通化したキー情報を用いたVNFライフサイクルの実現と情報連携を可能としている．

図4　VNF Packageの構成と関連付け方法

5.2 システム間連携を活用したユースケース

前述したシステム間連携の仕組みを活用することで実現した，通信ソフトウェア・仮想リソースが連動した高度な業務ユースケースについて解説する．保守者作業効率の向上，ならびに作業ミスの防止，復旧時間の短縮が図られている．
（1）局建設（インスタンシエーション）
局建設工程は，局建設用データ作成・投入工程と，以降のVNF立上げ工程に分類される．これらの工程は，SMO機能部間，ならびにO-Cloudの連携により自動化されている．
vRANアプリケーション構築時に必要な局建設用のデータ作成・投入は，膨大な設計データに関してOSSとRICが連携することで実現している．Management Element IDや，IPアドレス*82などの局固有の必要最低限のパラメータをOSSに投入すると，OSSはRICとデータ連携し，RICは収容するRU（Radio Unit）*83の型番，セル*84の位置などの基地局の諸元情報や置局情報に応じてパラメータを設計・補完し，OSSにvRANアプリケーション構築時に必要な局構成データとしてそれらを通知・投入する．
VNFの立上げは，NFVO機能部に対するインスタンシエーション指示によりトリガされる．NFVO機能部，VNFM機能部，O-Cloudの連携の下でVNFが起動した後は，局構成データに基づいて，VNFは必要とする設定データをEMから自動的に取得する．共通化したキー情報を基にNFOはインスタンシエーションの結果をOSSに通知し，OSSは管理するVNFの情報を局建済としてステータス管理する．本連携により，VNFがサービス可能でかつ監視されている状態となる．
（2）障害復旧動作（ヒーリング）
①Kubernetes層における自動仮想リソース復旧
Kubernetes層で仮想リソース障害が発生した場合，宣言型定義に従って，O-CloudによるPod/Kubernetesリソースの再構築が行われる．本プロセスにおいて，前述したVNFMからO-Cloudに対する仮想リソース情報の定期的なポーリングによって，VNFMは再構築後の情報を最新の管理情報として更新する．また，再構築後のPod/Kubernetesリソース情報は，VNFM経由でOSSに対しても通知される．これらの動作はシステム間の情報連携により自動的に行われるため，保守者操作は要求されず，Kubernetes層のオーケストレーションを保守者に対し隠蔽できていると考えられる．
②ソフトウェア障害の手動・自動復旧（OSS契機の手動・自動ヒーリング）
Kubernetesリソースとしては正常に動作しているが，アプリケーションの不具合によりVNFの動作異常が発生している場合がある（例：Pod StatusはRunningだが，アプリケーション状態異常によりUE Attach*85が失敗しているなど）．当該事象への対応策として，OSSトリガでの手動・自動ヒーリングにより，状態異常を回復する機能がSMOに具備されている．
具体的なフローとしては，EMがVNFの障害・パフォーマンス情報を収集し，OSS経由で保守者画面／RICに障害情報を通知することで，保守者／RICによる復旧判断を促す．保守者／RICの判断に基づき，OSSはVNFMに対してヒーリング要求を実施，VNFMはO-Cloudに対して，対象VNF Instanceの構成Podが再構築されるよう，既存リソースを削除する指示を行う．本操作の実行結果はO-CloudからVNFMを経由してOSSへ通知され，保守者は結果を確認することができる．
このように，Kubernetesレイヤで監視・救済できない異常に対しても，自動／半自動の復旧手段が確立されているため，安定したサービス提供を実現できる．

  1. 制御プレーン：Kubernetesクラスタの状態管理とオーケストレーション（*71参照）を担う中枢機能群であり，クラスタ内のノード（*80参照），ポッド，サービスなどのリソースを監視・制御・調整する役割をもつコンポーネント．
  2. 宣言型定義：システムやリソースの望ましい状態（Desired State）を記述する方式であり，「何を実現したいか」を記述することに重点を置き，「どのように実現するか」はシステムに委ねるアプローチ．
  3. オーケストレーション：アプリケーションやサービスの運用・管理を自動化するために，必要なリソースやネットワークの接続を管理・仲介する技術．
  4. Pod：Kubernetesにおいて管理される仮想リソースの最小単位．1つまたは複数のコンテナから構成される．
  5. 3GPP：各国の標準化機関により設立された移動通信の仕様を検討，策定するプロジェクト．
  6. NF：3GPP仕様において定義されている，モバイルネットワークを実現する通信ソフトウェアの論理的な機能単位．
  7. VNFc Instance：ETSI NFVにて定義されているMANOが管理するVNF Instance（*77参照）を構成するコンポーネントの実体．
  8. ポーリング：端末からサーバに対して，送信するデータがないか問合せをすること．
  9. VNF Instance：MANOシステムによって仮想化基盤上に構築（インスタンシエーション）されたVNFの実体．
  10. VDU：ETSI NFVにて定義されているMANOが管理する仮想リソースの実行単位．
  11. コンテナランタイム：Docker，Containerdなどに代表されるコンテナの実行環境を提供するソフトウェア．
  12. ノード：Kubernetesクラスタ内でコンテナ化されたアプリケーションの実行を担う物理または仮想マシンであり，Podのホスティング，リソース提供，ローカル管理機能の実行を行う基本的な構成単位．
  13. 3GPP SA5：3GPPは，移動通信システムに関する標準化機関である．SA5は，3GPPにてOSS/BSS（Business Support System）について議論する作業部会のこと．
  14. IPアドレス：IPネットワークに接続されたコンピュータや通信機器1台1台に割り振られた識別番号．
  15. RU：基地局を構成する装置の1つとして，送信するデジタル信号を無線信号に，受信する無線信号をデジタル信号に変換する．また，送信電力の増幅，アンテナ素子での無線信号の送受信，大規模MIMOでのビーム生成に必要な処理を実行する．
  16. セル：セルラ方式の移動通信ネットワークと移動端末との間で無線信号の送受信を行う最小のエリア単位．
  17. Attach：端末の電源投入時などにおいて，端末をネットワークに登録する処理および状態．

06.海外販売を見据えた将来展望

SMOにおいては，NTTグループのグローバルビジネス展開に向けてオープンソースソフトウェアを活用し，5GのvRANアプリケーションと仮想化基盤を連携可能とする一元的な運用制御を実現している．今後も海外販売を見据え，海外オペレータの要求に従った以下の機能などに柔軟に対応していく．
・多様な通信サービス提供に対応するため，4G/5Gの両世代のvRANアプリケーションに対応する．
・複数のオープンソースソフトウェアに関する認証について，海外オペレータが保持するアカウント情報と連携し，一元的なユーザ管理を実現する．
・RANシェアリングによる事業者間共用に対応した監視制御機能を実現する．
・SMO内のOSS/Non-RT RIC/MANOは独立で販売できるように，疎結合の設計を実現する．
・海外オペレータの規模に応じて，柔軟に収容を変更可能とする．

07.あとがき

ドコモでは，2025年からvRANの商用導入において，VNFならびにO-Cloudを収容するSMOを自社開発し，導入した．保守者に対する統一的かつ効率的な保守手段の提供に向けて，NFO/NSMF/NFMFのシステム開発に加えて，システム間の動的な情報連携の仕組みを開発した．今後は，vRANの展開規模の拡大や，後続の仮想化ユースケースに合わせて，さらなるインテリジェントな運用に向けたシステム機能・システム間連携の高度化を実現していく．

文献

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