近年、汎用ハードウェア・アクセラレータの性能向上や仮想化技術の進歩により、世界的に仮想化された無線アクセスネットワーク（vRAN：virtualized Radio Access Network）の製品開発が加速しています。これらは、汎用ハードウェア導入による設備コストの削減、仮想化技術やAI（人工知能）技術を活用した構築・保守業務のインテリジェント化によるオペレーションコストの削減や、通信サービスの信頼性向上につながるものと期待されます^（1）。
NTTドコモでは、O-RAN＊1サービスブランドであるOREX（Open RAN Ecosystem Experience）＊2を海外展開するとともに、日本国内においては、2025年にvRANの商用サービスを開始しています。
vRANの国内導入においては、仮想化された通信ソフトウェアであるVNF（Virtualized Network Function）、ならびにVNFを配備する分散型コンテナ仮想化基盤O-Cloudを全国規模で展開していきますが、このような大規模運用を実現するためには、建設・保守業務の自動化が必須です。そこでドコモでは、O-RANのコンポーネントであるSMO（Service Management and Orchestration）を開発・導入することによる建設・保守業務の自動化を実現しました。
本稿では、ドコモが開発・導入したSMOを概観するとともに、開発方針、課題とその対策、システム構成技術、コンポーネント間連携による高度な自動化方式について解説し、海外販売を見据えたSMOの将来展望について述べます。

＊1 O-RAN：O-RAN Allianceにおける標準化において、3GPPの仕様の範囲外である基地局の実装や運用の自動化に関する仕様を定めたもの。
＊2 OREX：ドコモが提供する、O-RANを活用した通信インフラ構築支援サービス。

SMOには、vRANの仮想化による費用・運用メリットを最大化するための効率的かつ統一的な制御が求められています。さらに、保守効率の抜本的な向上に向けて、ZTO（Zero-Touch Operation）＊3の実現やAI技術を活用した動的なパラメータチューニングとの連携が行えるアーキテクチャの実現が期待されています。
SMOは、VNFとO-Cloudを制御するためのFOCOM（Federated O-Cloud Orchestration and Management）とNFO（NF Orchestration）、スライス管理のためのNSMF（Network Slice Management Function）、VNFのFM（Fault Management）・PM（Performance Management）・CM（Configuration Management）のためのNFMF(Network Function Management Function)、自動制御・最適化のためのRIC（Ran Intelligent Controller）の論理機能から構成されます（図1）。
FOCOMは、O-CloudのInventory管理・FM・PMを行い、NFOはO-Cloudと連携してVNF Deploymentのライフサイクル管理・FM・PMを行います。NFMF/NSMFは、VNF・スライスのInventory管理・FM・PMを行います。RICはAI/ML（Artificial Intelligence/Machine Learning）を利用し、収集したvRANアプリケーション情報に応じた最適化とCM制御を行います。

＊3 ZTO：人手の介在無く、オペレータの通信システムの運用が実現できる思想。

VNFは、多くの通信ソフトウェア開発ベンダにより製品化されており、各VNFの製品特性やベンダ戦略により、対応する仮想化プラットフォームが選定されています。近年、VNFはベアメタルコンテナ方式を採用する製品が多いため、O-Cloudは、Kubernetes＊4をベースとした製品が主流です。ドコモへの導入については、vRANアプリケーション・O-Cloudともマルチベンダ構成となることを想定して、どのような組合せでも対応できるvRAN開発を進めてきました。ドコモにおいては、VNFは数十万インスタンス、O-Cloudは数百クラスタに及ぶものと想定されます。このような全国規模のプラットフォームに対して安定した通信サービスを提供するために、SMOは効率的かつ統一的な構築・保守手段を提供します。
マルチベンダのVNF、O-Cloudが混在するネットワーク環境においても、効率的な運用を実現するためには統一された建設・保守業務の提供が必要になります。このような統一された建設・保守操作の提供、ならびにマルチベンダ間の差分の吸収には柔軟な開発を伴うため、ドコモでは、NTTの研究開発成果であるコグニティブ・ファウンデーション（CF）連携基盤技術を活用しSMOを自社開発しました。NTTの研究開発成果については参考文献（2）を参照してください。なお、国内導入におけるFOCOM、ならびにFOCOMにより制御されるIMS（Infrastructure Management Service）については、標準仕様と製品の成熟状況をかんがみ、現時点では自社開発を見送り、O-Cloudベンダ製品の提供機能を利用しました。FOCOM、IMSの詳細仕様については、参考文献（3）を参照してください。また、RICは自社開発していますが、詳細仕様については参考文献（4）を参照してください。

＊4 Kubernetes：CNCF（Cloud Native Computing Foundation）にて管理されている複数サーバで構成される大規模環境向けのコンテナ管理を目的としたオープンソースのコンテナオーケストレーションツール。

これまで、通信ソフトウェアの仮想化は、VM（Virtual Machine）方式が主流であり、ドコモのコアネットワークにおいても、OpenStackベースの仮想化プラットフォーム上で各種VNFの仮想化を実現してきました。
一方、近年、ベアメタルコンテナ方式の仮想化通信ソフトウェアが増加傾向にあり、同一ネットワーク内にVMとコンテナが混在するようになってきています。このためNFO機能部は、同一ネットワークに混在するVM・コンテナ方式のVNFに対しても、統合的なライフサイクル制御を実現する必要があります。そこで、ETSI NFVのMANO（Management and Orchestration）＊5仕様に準拠したNFOの機能開発を行うことで、NFOに求められるVNFライフサイクル機能を提供しつつ、コア・無線ネットワークの両方に対応できる汎用性の高い機能実装をめざしました。

＊5 MANO：ETSI NFV ISGにて標準化されている、VNFへのライフサイクル機能を提供する論理機能部。

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

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

＊6 NFVO：ETSI NFVにて定義される、各種通信ソフトウェアの生成から削除までの管理を行い、システム全体の運用管理を行うためのコンポーネント。複数の仮想化プラットフォーム上に展開されるVNFのリソース調停を行います。
＊7 VNFM：ETSI NFVにて定義される、仮想化された通信機能や通信システム（VNF）のライフサイクル制御として起動や停止などVNFの制御を担うコンポーネント。
＊8 VNFD：VNFの仮想リソース構成、機能や振舞いを定義するテンプレート。

OSSの主な機能部はNSMFと、NFMFに分けられます。vRAN監視のOSSの場合、RAN-NSSMF（RAN Network Slice Subnet Management Function）機能部が、NSMFで管理するE2E（End-to-End） Network Sliceの一部であるRANドメインのSlice Subnetの管理を行い、スライスごとの監視（FM、PM）や構成情報管理（CM）を行います。また、NFMF/EM（Element Manager）＊9機能部が、vRANアプリ〔vCU（virtualized Central Unit）、vDU（virtualized Distributed Unit）〕の、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のロードマップにおいては、O1-IF標準化が進んだ際にGenericEM機能をOSSで具備したベンダEMを介さず監視・制御する対応と、オープンで相互接続性の高いIFを採用し、さまざまなベンダEMの対応をめざします。
なお、マルチベンダのvRANをOSSで収容する場合、SA5-IF上でプロトコルやデータフォーマット、データモデルは規定されていますが、ベンダごとに保持するCMデータのパラメータ項目の有無や、共通パラメータの中でもデータ配列の差分など、共通化が実現できていない個所が存在しています。OSSがvRAN開発ごとにベンダ差分の対応をすることは影響が大きいため、すべてのパラメータからユーザが選択して編集・登録可能なUIにする対応としました。
（2）　OSSとNon-RT（Real Time） RIC＊10間IF
OSS-Non-RT RIC間のIFは規定されておらず、OSSとNon-RT RICはそれぞれ独立で海外導入を見据えているため、他製品との接続を見越して一般的なREST（REpresentational State Transfer）＊11-IFで対応しました。
（3）　OSSと外部システム間IF
OSSが保持するFM/PM情報の取得やvRANに対するCM制御を外部システム向けに開放し、海外のオペレータが保持する外部システムからも取得、制御が可能です。外部システム側が簡易に実装可能となるよう、開放するプロトコルはSFTP（SSH File Transfer Protocol）/RESTとしています。

＊9 EM：個々のネットワーク装置に対する障害（Fault）・設定（Configuration）・課金（Accounting）・性能（Performance）・セキュリティ（Security）（通例FCAPSと呼ばれる）の管理・監視を担う機能ブロック。
＊10 Non-RT RIC：O-RAN Allianceにおいて、リアルタイム性が求められないことに対してインテリジェンスな制御を行うシステム。
＊11 REST：APIの1つで、各リソース（URL）に対してGET、POST、PUT、DELETEでリクエストを送信し、レスポンスをXML（eXtensible Markup Language）やjsonなどで受け取る形式。

仮想化によりソフトウェアとハードウェアが分離された環境においては、従来の保守・操作とは異なり、ソフトウェア制御と仮想リソース制御を連携させつつ、制御システム（NSMF/NFMF/FOCOM/NFO/O-Cloud）が保持する管理情報の整合性を常に維持するシステム間の連携が必要です。さらに、NFOが提供する仮想リソースの制御においては、O-CloudのKubernetes層の制御プレーンと連携し、適切な機能分担の下で行う必要があります。
O-CloudはKubernetesをベースに構成されており、宣言型定義に基づいた仮想リソースのオーケストレーション機能を具備しています。他の業界においては通常、Helmchartなどで定義されたリソース単位やPod単位で保守・監視が行われることが一般的です。一方、通信事業者においては、アプリケーション調達単位や構成情報の管理単位、保守のシンプル化の観点からの3GPP（3rd Generation Partnership Project）定義のNF単位/ETSI NFV定義のVNF/VNFc（VNF components） Instance単位で管理が行われることが一般的です。そこで、O-Cloudを構成するKubernetesの提供するオーケストレーション機能を活用しつつ、VNF/VNFc Instance単位での抽象化を実現するために、これらをマッピングできる、ETSI NFV準拠のVNF PackageをNFOに登録、利用することとしました。
VNF Package はNF単位/VNF/VNFc単位を定義するVDU(Virtual Deployment Unit)＊12 と、O-Cloudに対して要求する仮想リソース情報を定義するHelmchart内で定義する仮想リソース名をマッピングする構成（図4）としました。この仕組みにより、OSSや保守者からの従来の管理単位であるVNF単位の制御指示をKubernetesのオーケストレーションに変換でき、高度な専門知識を持たない保守者にも、仮想リソースの複雑な運用管理を実現できる仕組みとしました。以降に本仕組みにより実現したユースケースと動作について解説します。
（1）　局建設（インスタンシエーション）
局建設は、局建設用データ作成・投入工程と、以降のVNF立上げ工程に分類され、自動化されています。
vRANアプリケーション構築時に必要な局建設用のデータ作成・投入は、膨大な設計データに関してOSSとRICが連携することで実現しています。局固有の必要最低限のパラメータをOSSに投入すると、OSSはRICとデータ連携し、RICは収容するRU（Radio Unit）＊13の型番、セルの位置などの基地局の諸元情報や置局情報に応じてパラメータを設計・補完し、OSSにvRANアプリケーション構築時に必要な局構成データとしてそれらを通知・投入します。
VNFの立上げについて、NFOからの指示のもとO-CloudがVNF起動した後は、局構成データに基づいて、VNFは必要とする設定データをEMから自動的に取得します。共通化したキー情報を基にNFOはインスタンシエーションの結果をOSSに通知し、OSSは管理するVNFの情報を局建済としてステータス管理します。本連携により、VNFがサービス可能でかつ監視されている状態となります。
（2）　障害復旧動作（ヒーリング）
①　Kubernetes層における自動仮想リソース復旧： 仮想リソース障害が発生した場合、宣言型定義に従って、O-CloudによるPod/Kubernetesリソースの再構築が行われます。NFO内のVNFMからO-Cloudに対する仮想リソース情報の定期的なポーリングによって、NFOは再構築後の情報を最新の管理情報として更新します。また、再構築後のPod/Kubernetesリソース情報は、VNFM経由でOSSに対しても通知されます。これらの動作はシステム間の情報連携により自動的に行われるため、保守者による操作は要求されず、Kubernetes層のオーケストレーションを保守者に対し隠蔽できています。
②　ソフトウェア障害の手動・自動復旧（OSS契機の手動・自動ヒーリング）：Kubernetesリソースとしては正常に動作していますが、アプリケーションの不具合が発生している場合があります。当該事象への対応策として、OSSが検知した障害に対してNFOに手動・自動ヒーリングの指示を出し、仮想リソース生成結果を得る流れにより、状態異常を回復する機能がNFOに具備されています。このように、Kubernetesレイヤで監視・救済できない異常に対しても、自動・半自動の復旧手段が確立されているため、安定したサービス提供を実現できます。

＊12 VDU：ETSI NFVにて定義されているMANOが管理する仮想リソースの実行単位。
＊13 RU：基地局を構成する装置の1つとして、送信するデジタル信号を無線信号に、受信する無線信号をデジタル信号に変換します。また、送信電力の増幅、アンテナ素子での無線信号の送受信、大規模MIMOでのビーム生成に必要な処理を実行します。

SMOにおいては、NTTグループのグローバルビジネス展開に向けてオープンソースソフトウェアを活用し、5GのvRANアプリケーションと仮想化基盤とを連携可能とする一元的な運用制御を実現しています。今後も海外販売を見据え、海外オペレータの要求に従った以下の機能などへ柔軟に対応していきます。
・4G/5Gの両世代のvRANアプリケーション対応。
・複数のオープンソースソフトウェアに関する一元的なユーザ管理。
・RANシェアリングによる事業者間共用に対応した監視制御機能。
・海外オペレータの規模に応じて、柔軟に収容を変更可能化。

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

■参考文献
（1）　https://www.docomo.ne.jp/binary/pdf/corporate/technology/rd/technical_journal/bn/vol30_1/vol30_1_004jp.pdf
（2）　https://journal.ntt.co.jp/article/30138
（3）　https://www.docomo.ne.jp/corporate/technology/rd/technical_journal/bn/vol33_2/005.html
（4）　https://www.docomo.ne.jp/corporate/technology/rd/technical_journal/bn/vol33_3/003.html