半導体技術および仮想化技術の進化により、テレコム向けの要件の厳しい通信ソフトウェア（SW）を汎用ハードウェア（HW）上の仮想化レイヤで動作させることが可能になりました。これにより、従来のHW/SW一体型の装置の場合と比較して、設備の低コスト化やSWアップデートだけによる新機能追加が可能となり、新機能追加やサービス開始までのリードタイムの迅速化を図ることができます^（1）。NTTドコモでは、2015年度から商用ネットワーク（NW）におけるコアNW＊1装置へ仮想化技術の適用を開始し、2025年度時点で仮想化適用率は100％に達しています。一方、無線アクセスネットワーク（RAN：Radio Access Network）では、無線レイヤのベースバンド処理などでリアルタイム性が求められるため仮想化技術の適用が難しかったところを、近年のIT仮想化技術、汎用HW、HWアクセラレータの進歩により、RAN領域にも仮想化技術が適用できるようになりました。このため、国内外のオペレータでは、RAN領域に対する仮想化技術vRAN（virtualized RAN）の導入を進めています。
ドコモでは、O-RAN（Open RAN）＊2とETSI（European Telecommunications Standards Institute） NFV（Network Functions Virtualization）に準拠した、vRANを収容する分散型コンテナ仮想化基盤（O-Cloud）を開発し、2025年より商用導入を開始しました。コアNW仮想化と異なり、vRANは処理性能の観点でアンテナサイトに近接したEdgeサイトに機能配備する必要があるため、数千の分散拠点に仮想化基盤を迅速かつ簡易に展開し、運用することが新たに課題となっています。O-Cloudの開発では、クラウドネイティブや仮想化技術を活用した構築、および運用の自動化を促進するワークフローを設計・実装することにより、それを可能としました。本稿では、具体的にどのようにアプローチすることで、技術課題を解決したか解説します。

＊1 コアNW：ゲートウェイ装置、位置管理装置、加入者情報管理装置などで構成されるNW。移動通信システムを構成するNWのコア部分。移動機は無線基地局などで構成されるRANを経由してコアNWとの通信を行います。
＊2 O-RAN：O-RAN Allianceにおいて、3GPPの仕様の範囲外である基地局の実装や運用の自動化に関する仕様を定めたもの。

NW仮想化技術とは、汎用HW上に仮想化レイヤを導入し通信SWを仮想資源上で動作させることにより、これまで専用HWと専用SWとで提供してきた高信頼・高性能のキャリアグレードの通信サービスを汎用HW上で実現させる技術、およびオーケストレーション技術＊3を組み合わせたものです。NW仮想化技術により、HWとSWの分離が可能になり、安価な汎用HW利用によるコスト低減やベンダロックインの回避、最先端のHWの早期導入、SWのアップデートだけによる新規機能の提供や、オープンソースの適用や効率的な開発手法によるサービス開始までのリードタイムを短縮できます。

＊3 オーケストレーション技術：アプリケーションやサービスの運用管理を自動化するために、必要となるリソースやNWの接続性の管理・調停を実現する技術。

ドコモでは、2010年代前半よりNW仮想化技術の研究開発と標準化を進め、2015年度から商用NWへの適用を開始しました。2021年度導入の5G（第5世代移動通信システム）のコアNWも仮想化され、2023年6月には全国7地域23拠点に仮想化設備が設置され、約1万台以上の COTS（Commercial Off-The-Shelf）サーバ群と数千台のNW機器群、25万以上の仮想マシン（VM：Virtual Machine）群を保守しています。2025年度内にすべての商用コアNWの仮想化を完了する予定です。

従来、RAN仮想化には、無線信号処理やデータ暗号化で行われる高次の計算が可能なHWが必要とされ、これを安価かつ容易に導入できないことがボトルネックでした。しかし、昨今の汎用HWの性能向上や、高次の計算に特化したHWアクセラレータの登場により、RAN仮想化が可能になってきました。この背景から国内外のオペレータはvRANの取り組み、導入を進めています。

O-Cloudの構築、大規模展開には、以下（1）～（3）の課題があります。
（1）　O-Cloudコンポーネント設計
ドコモのコアNWの仮想化装置は、全国7地域23拠点のオンプレミス環境で構築されています。一方、vRANでは全国の数千に分散した拠点で大規模展開していくことから、従来のコアNWのアーキテクチャを踏襲すると設備コストが増大します。そのため、仮想化基盤展開に必要な所要時間・工数を最小化するためのワークフローを考慮し、仮想資源の管理制御機能部やHWの物理レイヤの監視制御機能部など、仮想化基盤のどの機能部をパブリッククラウド・オンプレミス環境に配置すると効率的に基盤展開できるか、十分な検討が必要です。
（2）　自動化と遠隔保守の促進による構築・保守作業の効率化
vRANでは、オンプレミス設置環境がCentralサイト（東京・大阪）、Regionalサイト（各都道府県）、Edgeサイト（アンテナサイトに近接した全国数千の分散拠点）の大きく3つに分類されます。具体的には、Central・Regionalサイトは、データセンタ相当のドコモビルが該当し、Edgeサイトは、全国各地のNTT局舎やアンテナサイト、民間ビルなどに近接する収容函が該当します。特にEdgeサイトについては設置環境に起因する制約条件（限られた設置スペースや空調など）に対応した機器・物理配備構成の検討、構築時の工事や構築後の保守運用の遠隔実施、自動化によるZero Touch化および作業の最小化が求められます。
（3）　NW・セキュリティ設計
名前解決やCA（Certificate Authority）　構成などさまざまな設置形態へ柔軟に対応できるように、コンポーネント間のNWや疎通・暗号方式を設計する必要があります。
ドコモでは、これまでのコアNW仮想化の開発・運用の知見を踏まえ、進歩した技術を取り入れつつ、上記の課題解決とともにvRANの実現をめざしています。

従来のコアNWの仮想化基盤はVM方式で構築され、5Gコアではコンテナ on VM方式＊4が採用されています（図1）。一方、O-Cloudではベアメタルコンテナ方式を採用しています。コンテナ方式は軽量であるため、数千の分散拠点に迅速かつ簡易に展開することが可能となります。
CU（Central Unit）・DU（Distributed Unit）機能を仮想化したvRANアプリケーション〔vCU（virtualized CU）・vDU〕をコンテナ化し、O-Cloud上にデプロイすることで、RAN仮想化を実現します。

＊4 コンテナ on VM方式：VM上にコンテナランタイム環境を配置し、その上でコンテナアプリケーションを実行するアーキテクチャ。従来の仮想化インフラストラクチャとコンテナ技術の統合を目的として使用します。

O-Cloudは、アプリケーションの起動、停止、復旧などの制御機能、HWの障害・輻輳の監視・通知機能、コンテナの動作・処理に必要なコンテナ監視・NW機能、およびコンテナのイメージ作成・構築に必要な資材格納機能を具備します。また、全国への大規模展開のため、事前にシナリオを設定し構築を自動化することにより、省力化を実現しています。

（1）　コンポーネントの役割
数千の分散拠点に展開するため、基盤構築作業はCCM（CIS Cluster Management）＊5により自動化されています。事前作成シナリオに応じてBIOS・OS・ファームウェア（FW）などをHWに自動設定し、そのHW上にDMS（Deployment Management Services）＊6・LFS（Large File Server）＊7・CIR（Container Image Repository）＊8・CIS（Container Infrastructure Service）＊9・PaaS（Platform as a Service）＊10など、各コンポーネントを構築し、コンテナ向け仮想化基盤を形成します（図2）。
vRANアプリケーション（コンテナイメージ）はCIRに格納され、その他構築資材はLFSに格納されます。vRANアプリケーションは、SMO（Service Management and Orchestration）＊11の指示に基づき、DMSによりCIS上にデプロイされ、起動・停止・復旧も同様にDMSが制御します。
運用においては、PIM（Physical Infrastructure Manager）＊12が物理サーバの障害・輻輳を監視し、PaaSがNW機能、時刻同期、名前解決、監視などコンテナの動作・処理に必要な機能を提供します。
オンプレミス環境の物理リソースは、主にCOTSサーバで構成されますが、vDUが動作するCOTSサーバは、物理レイヤを処理する専用HWアクセラレータが搭載されています。CIR/LFSの実データやvCU/O-Cloudログの保管には、冗長構成の大容量ストレージを設置します。
（2）　O-Cloudのサイト構成
各コンポーネントは、パブリッククラウド・オンプレミス環境に配置されます（図3）。パブリッククラウドには、監視・自動化機能を集約しIMS、PaaSが配置されます。オンプレミスは、商用呼の処理、構築資材の保管、パブリッククラウドがダウンした際の監視（予備系）を行い、規模に応じてCentral・Regional・Edgeサイトに区分されます。Centralサイトは、全国東西2拠点に設置され、構築用資材の保管やパブリッククラウドがダウンした際の監視（予備系）を行うため、PaaS、LFSが配置されます。Regionalサイトは47都道府県単位に設置され、CUの呼処理を行うため、CIR、DMS（vCU/vDU）、CIS（vCU）が配置されます。Edgeサイトは、5Gの低遅延通信を実現するためCIS（vDU）が全国数千の拠点に分散設置されます。
オンプレミスでは、Central・Regionalサイトへの機能集約、低廉なCOTSサーバの採用、自動化による省力化でコストを最適化し、かつCIS（vDU）の分散設置により低遅延NWを構築しています。一方で、クラウドでは既存のOSS（Open Source Software）資産を活用し、開発を効率化・高速化しています。低コストのオンプレミス設備と急速に進化するクラウド技術とが連携したハイブリッド構成を採用することで、最適なソリューションを実現しました。

＊5 CCM：事前に設定されたシナリオに応じてCIS・DMSの構築と、COTSサーバに対するBIOS、OS、ファームウェアなどの設定を、それぞれ自動で行うコンポーネント。
＊6 DMS：vRANアプリケーションの配置・起動、停止、復旧などの制御機能を提供するコンポーネント。
＊7 LFS：構築に必要な資材を格納・保管する機能を提供する大容量ファイルサーバ。
＊8 CIR：コンテナイメージを格納・保管する機能を提供するコンポーネント。
＊9 CIS：コンテナ化されたvRANアプリケーションを実行するためのリソースを提供するコンポーネント。
＊10 PaaS：コンテナの動作・処理に必要なNW機能、時刻同期、名前解決、ログ機能などを提供するコンポーネント。
＊11 SMO：vRANにおいてNWの管理とオーケストレーションを行うシステム。
＊12 PIM：HW障害・輻輳の監視・通知を行うコンポーネント。

図4のとおり、O-Cloudの構築後にRANアプリケーション構築を行うことで、基地局機能の提供が開始されます。ここでは、O-Cloudの構築に焦点を当てて解説します。
図4に示すとおり、O-Cloudの構築は①ラックやサーバ、NW機器の物理工事、②各種インベントリ＊13への登録と③クラスタの構築の3段階で行われます。①では、サプライヤが事前にキッティングしたサーバを利用することにより、現地作業をラッキングや配線だけとし、SW設定をパブリッククラウド上からの投入とします。②では、IMSに存在する作業者向けインタフェースから必要情報をインベントリに登録し、③でCentral、Regional、Edgeサイトに対する作業シナリオをトリガします。以下では、インベントリの種類および登録内容、クラスタ構築作業の流れを解説します。

＊13 インベントリ：本稿では、関連する情報が保持されるテーブル型のデータ構造のこと。

O-Cloudのインベントリは、サイトインベントリ、サーバインベントリ、クラスタインベントリの3種類です。
サイトインベントリは、サーバを設置する拠点の住所、GatewayのIPアドレス、利用可能なクラスタのタイプなど、拠点ごとの固有情報が登録されます。
サーバインベントリは、IPアドレスや管理画面への認証情報など、物理サーバの固有情報が登録され、各サーバはいずれかのサイトに紐付いています。
クラスタインベントリは、NF（Network Function）が動作するKubernetes＊14クラスタに紐付くインベントリであり、紐付けるサイトおよびPaaS用クラスタ、vCU用クラスタ、vDU用クラスタなどのクラスタ種別ごとに共通的な設定値（CCD：CIS Cluster Descriptor）が登録されます。CCDの活用により、大規模展開時における設定投入、および運用工程における設定管理を簡易化しています。

＊14 Kubernetes：複数サーバで構成される大規模環境向けのコンテナ管理を目的としたコンテナオーケストレーションツール。

vRANでは数千の分散拠点（サイト）を構築する必要があり、サーバ単位ではさらに多くのレコードを登録する必要があるため、効率化が求められます。そこで、UI（User Interface）から1レコードずつインベントリ登録するほかに、レコードのエクスポート・インポートに対応しています。これによりレコードが流用可能となり、かつ多数のレコ―ドを一括登録できるため、作業を効率化させます。

クラスタ構築はシナリオ化されており、必要な設定値を登録し、シナリオをトリガすれば、作業は自動実行されます。
各インベントリへの登録完了時点で、各サイト・サーバには必要情報が、クラスタにはCCDが登録されるため、クラスタ構築時に必要な設定は、C-Plane（Control Plane）＊15の冗長数や、物理リソースの論理的なグルーピングなど、クラスタ個別の設定値だけです。

＊15 C-Plane：本稿では、Kubernetesクラスタ全体のpodのスケジューリングや、イベントの検出応答を行うコンポーネントを指します。KubernetesではC-Plane、ETSI NFVではCISMと呼称。

O-Cloudでは、保守作業をサイト・サーバ・クラスタ単位で効率的に実行できます。実施可能な作業は、ヘルスチェック、再起動、FW更新、BIOS設定更新などであり、例えばサーバ単位での再起動、サイト単位でのFW更新、クラスタ単位でのヘルスチェックなど、保守のユースケースに応じて効率的に使い分けることができます。
このように、O-Cloudではインベントリ、および構築・保守作業のシナリオ化により、大規模な展開が可能となっています。

NTTドコモでは、vRANを収容するO-Cloudを開発し、2025年から商用導入を開始しました。コアNW仮想化と異なり、数千の分散拠点に仮想化基盤を迅速かつ簡易に大規模展開することが新たな課題でしたが、クラウド技術を活用したアーキテクチャ設計や、構築・運用作業のシナリオ化による自動化機能により、本格的に商用導入できました。今後は、コンテナ仮想化基盤の展開領域や自動化適用領域の拡大・高度化の実現に取り組んでいきます。

■参考文献
（1）　水田・ウメシュ・中島・久野:“RAN仮想化（vRAN）に向けた取組み，”NTT DOCOMOテクニカル・ジャーナル，Vol.30，No.1，pp.14-26，2022．