仮想化技術を利用し経済的な基地局を実現するvRANの標準化動向

01.まえがき

無線基地局装置は，従来，リアルタイム性など無線処理特有の要求から専用装置を用いていた．一方，近年の急速な技術進歩により，汎用サーバを利用して無線基地局装置の要求条件である高性能・高信頼性・低消費電力化を実現することが可能となってきた[1]．汎用装置は，専用装置に比べて調達が容易で安価であることから，汎用仮想化技術を基地局に適用することで，より経済的な基地局vRAN（virtualized Radio Access Network）*1を実現できるようになった．特に，従来は専用装置でしか実現できなかった多量の信号の同時符号化などの低遅延が要求される処理の汎用装置での対応における，アクセラレータ*2の進化や，基地局などの特殊装置を汎用装置で実現するO-RANアーキテクチャの成熟化は，vRANの実現に大きく貢献した．
ドコモは，AT&Tとドコモが中心となって設立したO-RAN Alliance*3において，基地局を汎用装置で実現するアーキテクチャをO-RAN仕様として採用している．基地局市場は大規模なエコシステム*4であり，O-RAN Allianceには，ETSI（European Telecommunications Standards Institute）*5 NFV（Network Functions Virtualisation）*6やO-RAN SC（O-RAN Software Community）*7など，さまざまな標準化団体*8がかかわっている．
本稿では，O-RAN Allianceの現状を紹介するとともに，O-RAN Allianceがリードし提唱するアーキテクチャやそれを実現するO-RANエコシステムについて解説する．

02.O-RAN Alliance

2.1 O-RANの概要

O-RANとは無線基地局装置のオープン化をめざし，さまざまなRAN*9装置を組み合わせたり，ハードウェアとソフトウェアを分離したりすることが可能となるアーキテクチャである．O-RANでは，文献[2]での活動内容に基づき，3GPP（3rd Generation Partnership Project）*10仕様に準拠しつつ，3GPPの仕様の範囲外である，無線基地局装置の実装や運用の自動化に関する以下の仕様が定められている（図1）．
①RU（Radio Unit）*11およびDU（Distributed Unit）*12をマルチベンダで接続する「Open Front haul」
②無線パラメータを自動調整する「RIC（RAN Intelligent Controller）*13」およびその「E2インタフェース*14」
③DUおよびCU（Central Unit）*15の仮想化とその基盤である「O-Cloud」および「O2インタフェース*16」
④①～③の実装に向けて策定された標準インタフェース仕様やオープンソースの実装
　
2025年時点のO-RAN Allianceの各WG（WorkGroup）の所轄範囲（図2）と状況を表1に示す．

2.2 WG1におけるO-RANアーキテクチャとユースケース

(1)SMO（Service Management and Orchestration）*17の分離
WG1では，各コンポーネントのマルチベンダ化とその相互運用性の強化，および3GPPなどで標準仕様化された既存の機能とO-RAN Allianceで定義された新しい機能の統合のために，SMOアーキテクチャの分離化を推進している．SMOは複数のSMOS（SMO Service）に分離され，SMOSはvRANをよりオープンで柔軟かつ管理の容易なものにする上で重要な役割を果たす．これにより，高度で拡張性の高いRANアーキテクチャへSMOを進化させている．文献[3]の技術レポートは，既存のSMOSと外部の相互接続を分析し，ユースケースとして，「RAN NF（Network Function）*18のOAM（Operations, Administration, Maintenance）*19に関するSMOS」「Non-RT（Real Time） RIC関連のSMOS」「トポロジ*20とインベントリ*21関連のSMOS」「SME（Service Management and Exposure services）のためのSMOS」「データ管理と公開SMOS」「O-Cloudリソース管理とオーケストレーション*22関連のSMOS」「RANネットワークスライス*23サブネット*24管理SMOS」「RAN分析SMOS」「サービス保証SMOS」「ソフトウェアパッケージオンボーディング*25SMOS」「AI/ML（Artificial Intelligence / Markup Language）*26ワークフローSMOS」「ポリシー管理と情報SMOS」を例示している．
文献[3]のレポートでは，SMOSにSBA（Service Based Architecture）*27のフレームワークを適用させている．このアプローチは，マルチベンダSMO展開における相互運用性を促進する．SMO機能を個々のサービスとして構造化することで，オペレータはO-CU（O-RAN Centralized Unit）*28やO-DU（O-RAN Distributed Unit）*29などのさまざまなvRANコンポーネントの管理とオーケストレーションを合理化できる．
(2)インテントドリブン管理
WG1では，インテントドリブン*30アプローチによるSMO管理の簡素化も大きな進歩を遂げている．文献[4]のレポートでは，高レベルのインテントを使用してRANサービスを管理するという概念が導入されており，オペレータは具体的なインスタンス*31数や接続条件などのネットワークの作成手順を記述することなく，必要となる最終形態のネットワークをインテントとして指定しただけでネットワークを構築できる．インテントドリブン管理は，高いサービス品質を維持しながら，vRANデプロイ*32の自動化，柔軟性の向上，AI駆動のスケーリング*33と最適化を実現し，オペレータの期待（Expectation）に応えることができるため，vRANの運用において非常に重要である．文献[4]のレポートでは，インテントモデルは規定されていないが，TM Forum*34仕様[5]および3GPP仕様[6]を参照している．今後は，これらのインテントモデルがO-RANユースケースの特定の要件を満たすことができるかどうかをさらに理解するために，これらの仕様[5][6]を分析することがWG1において検討されている．
(3)ユースケースの仕様化
WG1では，ユースケースの目的，必要となるリソース，関連する手順，およびデータ要件を記述したWG横断での全体的なユースケースの仕様化が進められている．文献[7]で概説されているさまざまなユースケースの中で，動的スペクトル共有（DSS：Dynamic Spectrum Sharing）*35は，LTEデバイスとNRデバイスがQoE（Quality of Experience）*36を損なうことなく既存のスペクトルリソースを共有できるため，特に重要視されている．これは，CUとDUが異なるベンダから提供されるvRANのデプロイに必要となる．インテリジェントな制御機能をサポートし，L3（Layer 3）*37，L2*38，およびL1*39の制御機能を強化することにより，マルチベンダ環境でもシームレスで効率的なスペクトル使用を実現しながらDSSを実装している．

2.3 WG6のvRAN仕様

文献[1]のとおり，WG6は，O-Cloudの機能要件とO2インタフェース仕様要件をGA&P（General Aspects & Principles）*40（一般的な側面と原則）に規定し，それをベースにユースケースの仕様化を推進することに重点を置いている．
O-Cloudには，①NFデプロイメントとしてのvCU（virtualized CU）*41/vDU*42のリソースとリソースプール*43，②NFデプロイメントを管理するDMS（Deployment Management Service）*44，③リソースとDMSを管理するIMS（Infrastructure Management Service）*45，④アクセラレータであるAAL（Acceleration Abstraction Layer）*46の4つの要素がある．
O-Cloudは，VM（Virtual Machine）*47やコンテナ*48技術で仮想化されたvCU/vDUにワークロード*49を提供し，NFデプロイメントとして管理している．この管理のために，O-Cloudは4つの要素を具備した以下の機能を備えている．
・DMSによるNFデプロイメントの設計自動化とライフサイクル管理．
・IMSによるコンピュート*50リソース，ネットワークリソース，およびストレージリソースの提供と管理．
・DMSとIMSによるNFデプロイメントとリソースのFM（Fault Management）*51．
・DMSとIMSによるNFデプロイメントとリソースのPM（Performance Management）*52．
・AALによるアクセラレータ機能

2.4 WG10のSMO仕様

(1)OAMアーキテクチャおよびO1インタフェース*53
WG10は，OAMアーキテクチャ，OAMの要件，およびO1インタフェース仕様の開発に重点を置いている．OAMアーキテクチャは，文献[8]で規定されており，SMOの包括的なフレームワークを提供している．これにより，vRANコンポーネントを含むO-RANネットワーク機能を効果的に管理できる
O-RANにおいて，O-RU*54の管理は2つの方法が提案されている．1つ目の方法は，SMOなどの管理機能部からO-DUを経由してO-RUを管理する階層型運用モデル*55と呼ばれており，文献[8]に詳しく説明されている．このモデルでは，1つ以上のO-DUがOpen Front haul M-plane（Management plane）*56を介してO-RUを管理し，また，O-DUはO1インタフェースを介してSMOにO-RUの管理情報を提供している．O-RANネットワーク機能をSMOに接続するO1インタフェースは，3GPP準拠のMnS（Management Service）*57を提供している．ただし，O-RUはO1の代わりにOpen Front haul M-planeインタフェースを使用するため，SMOなどの管理機能部からは3GPP準拠のMnSで管理されるDUの管理オブジェクト*58の拡張として扱われ，O-RANではO-RUに相当する3GPP準拠のMnSは新規に仕様化されていない．また，O-RUは物理ネットワーク機能（PNF：Physical Network Function）*59としてのみ配置可能であり，論理機能としては展開できない．
O1インタフェースは，O-RANネットワーク機能のファイルおよびソフトウェア管理機能とともに，FCAPS（Fault，Configuration，Accounting，Performance，Security）*60機能の実装をサポートしている．O1でサポートされるこれらの管理サービスについては，文献[9]を参照されたい．
(2)パフォーマンス測定とO1 Alarms
現在，WG10は，ドコモ主導の下，O-CU-CP（Control Plane），O-CU-UP（User Plane），O-DUなどのO-RANネットワーク機能ごとに5Gネットワークのパフォーマンス測定を規定しており，オペレータがマルチベンダのO-RANネットワーク機能全体で測定値を収集できるようにしている．また，同じくドコモ主導の下，WG10はO1 Alarmsの新しい仕様も開発している．これは，O1インタフェースを介して報告されるO-RANネットワーク機能に関連するアラーム*61の詳細を定義している．この新しい仕様により，オペレータはマルチベンダのO-RANネットワーク機能全体で障害管理*62とトラブルシューティングを実行できるようになる予定である．
(3)クラウド環境*63での運用
WG10は，従来のOAM機能が基地局と一体になったアーキテクチャから，クラウド環境の機能を利用してOAMを実現する新しいアーキテクチャを指向しており，vRANコンポーネントの管理への影響分析に取り組んでいる．クラウド環境の機能の利用における要件とユースケースの検討（ステージ1），新しい要件に基づいたアーキテクチャやインタフェースや情報モデルの検討（ステージ2），新しいインタフェースに対応したプロトコルとトランスポートメカニズムの作成（ステージ3）を技術レポートとして検討している．
(4)O-RANネットワーク機能のリカバリ
また，WG10は，O-RANネットワーク機能のリカバリについても検討している．これは，マルチベンダネットワーク展開における障害シナリオとそれに対応するリカバリメカニズムを包括的に評価し，特にOAMの側面に焦点を当てている．さまざまな展開シナリオでの回復性戦略*64を検討し，エンド・ツー・エンドのネットワークの回復性を維持することの重要性を踏まえ検討を加速している．

03.O-RANエコシステム

3.1 O-RAN関連プロジェクトの概要

O-RAN Allianceは，オープンで仮想化されたRANの相互運用性とイノベーションを実現するために，他の標準化団体と緊密に連携することで，大規模で協調的なエコシステムの開発を主導している．特にRANとコアネットワーク*65の接続については3GPP仕様で規定されているため，3GPPはO-RAN Allianceにとって最も重要な標準化団体である．O-RAN Allianceは，前述のように，O-RANアーキテクチャを3GPP仕様に準拠させつつ，RANのオープン性やクラウドネイティブ*66の展開などの分野における3GPPなどの他標準化団体の仕様とのギャップに対処することで，不足する仕様を追加し3GPP仕様を拡張したO-RANアーキテクチャの仕様を規定している．
O-RAN Allianceは，vRANの実現のためのクラウド技術を利用した仮想化基盤であるO-Cloudに対する要件とインタフェースを定義するにあたって，ETSI NFV仕様やCNCF（Cloud Native Computing Foundation）*67仕様を参照することで，複数の標準化団体で仮想化基盤の仕様が矛盾しないようにしている．また，WG2には，ETSI ZSM（Zero-touch network and Service Management）*68の概念が組み込まれており，自動化と運用効率向上が実現している．
O-RAN SC内では，O-RAN仕様に従ってSMOとO-Cloudの実装が開発されており，将来のモバイルネットワークのためのオープンで柔軟かつ相互運用可能なエコシステムをめざしている．この目標を達成するために，O-RAN SCのアーキテクチャはいくつかの主要なコンポーネントで構成されており，それぞれがオープンで仮想化されたRANを実現する上で重要な役割を果たしている．以下では，オーケストレーションのためのSMO，インフラストラクチャ*69管理のためのO-Cloud，RAN処理のためのO-DUなど，O-RAN SCの主要なコンポーネントについて解説する．

3.2 3GPP

WG10は，O1管理サービスを可能な限り既存の3GPP標準に合わせており，どちらもSBAアプローチに従っている．
WG10の検討および仕様化の主な目的は，3GPP標準に準拠するユースケースを特定し，そのユースケースとO-RANに固有の管理サービスのギャップを検出し，このギャップに対して必要な拡張をO-RANの仕様に定義することで，O-RANと3GPPの仕様の整合性を確保することである．3GPP標準に変更を加えない場合，WG10拡張は，3GPP標準との互換性を最大限に維持し，ギャップを最小限に抑えるように設計されている．また，仕様化された拡張がない場合，管理サービスのプロデューサー*70とコンシューマ*71の両方が3GPP仕様に準拠することが可能となる．

3.3 ETSI NFV

ETSI NFVが仕様化しているETSI NFVフレームワークは，ネットワーク機能を仮想化し，クラウドベースの通信インフラストラクチャを管理するための標準化されたアプローチを提供している．O-RAN AllianceおよびO-RAN SCのアーキテクチャは，クラウドネイティブで仮想化されたRANアプローチのため，相互運用性，スケーラビリティ，および効率的なリソース管理を実現するために，それらをETSI NFV標準に合わせることが重要である．
この調整に対処するために，ETSI NFVは，ETSI GR NFV-IFA 046[10]に記載されているETSI NFV仕様とO-RANアーキテクチャ間のギャップに関する調査を実施した．この調査では，さまざまなO-RANコンポーネントがETSI NFV機能にどのように対応しているかを分析し，さらなる仕様拡張や一致化が必要な領域を特定している．調査から得られた主要なマッピングは次のとおりである．
・SMOは，ETSI NFVフレームワークのOSS（Operations Support System）*72，EM（Element Management）*73，およびNFVO（Network Functions Virtualization Orchestrator）*74相当の機能を実現している．これは，SMOが仮想ネットワーク環境でRANコンポーネントの管理や自動化の主要コンポーネントとして機能することを意味する．
・O-Cloudは，ETSI NFVフレームワークのNFVI（Network Functions Virtualization Infrastructure）*75，およびCIS（Cloud Infrastructure Software）*76クラスタに対応している．これらの要素は，O-RAN機能を収容するために必要なコンピューティング，ストレージ，およびネットワークリソースを提供している．
・DMSは，VIM（Virtualized Infrastructure Manager）*77，CISM（Cloud Infrastructure and Service Management）*78，およびVNFM（Virtual Network Function Manager）*79に該当する．これは，仮想化されたRANコンポーネントへのリソース割当て，リソースオーケストレーション，およびライフサイクル管理の機能を提供することを意味する．
・IMSは，仮想化基盤の構成，監視，および全体的な制御を行うPIM（Physical Infrastructure Manager）*80とCCM（CIS Cluster Manager）*81にマップされる．
・AALは，ETSI NFVフレームワークに不足しているコンポーネントである．現在のETSI NFV標準仕様では，O-RANデプロイにおけるハードウェアアクセラレーション管理に直接対応するものは定義されていない．

このマッピングは，ETSI NFVとO-RAN SCの相互運用性，スケーラビリティ，および効率的なリソース管理における相乗効果とその間のギャップを表している．多くの要素は整合性が取れているが，AALのような領域ではO-RANの固有の要件を，より広範なNFVエコシステムに完全に統合するために，さらなる標準化が必要である．ETSI NFV仕様の将来の機能強化は，これらのギャップを埋めるのに役立ち，O-RAN SCとNFVベースの通信クラウドインフラストラクチャの間のシームレスな相互運用性を確保することができる．

3.4 O-RAN SC

O-RAN SCは，O-RAN Allianceの実現のために設立された，Linux Foundation*82配下のオープンソース団体である．O-RAN SCの目標は，従来のRANアーキテクチャを進化させ，5Gおよび将来の無線ネットワークにおけるさまざまなユースケースに対応可能な相互運用性，柔軟性，およびインテリジェンスな制御による効率性を可能にするオープンなソフトウェアエコシステムを構築することである．これを達成するために，O-RAN SCはさまざまなオープンソースプロジェクトのソフトウェアコンポーネントの統合および開発を行っており，そのソフトウェアコンポーネントの一部は外部コミュニティからO-RAN SCにダウンストリーム*83が実施されている．以下では，O-RAN仕様に基づいてO-RAN SCが開発した，各ソフトウェアコンポーネントの実装について述べる．
（1）SMO
O-RAN SCは，ネットワーク機能のオーケストレーション，自動化，およびモニタリングを含むRANコンポーネントのライフサイクルの管理を担当するSMOフレームワークを開発している．SMOは主にONAP（Open Network Automation Platform）*84コンポーネントを利用しており，以下のようなソフトウェアコンポーネントから構成されている（図3）．
・AI主導のポリシー制御*85と最適化を行うNon-RT RIC*86相当のCCSDK（Common Controller Software Development Kit）*87．
・O1インタフェースを収容し，RANコンポーネントからパフォーマンスとテレメトリデータ*88を収集するためのVES（Virtual Event Streaming）*89．
・SMOフレームワーク内におけるイベント駆動型通信のメッセージバス*90としてのプラットフォーム機能であるKafka．
・OAM向けのKubernetes*91ベースの自動化ツールであるNephio．
・オーケストレーション機能を強化するために，ネットワーク機能オーケストレータ（NFO：Network Function Orchestrator*92）としての役割を果たすOpenMSA（Open Multi-Service Architecture）*93．
（2）O-Cloud
O-RAN SCは，O-RANアーキテクチャでVMベースのネットワーク機能（VNF（Virtual Network Function）*94）およびコンテナベースのネットワーク機能（CNF（Cloud native Network Function）*95）を収容する仮想化基盤としてO-Cloudを実装している．
O-Cloudの現在の実装には，次のものが含まれる（図3）．
・低遅延，高可用性，およびリアルタイム処理機能を備えたキャリアグレードのクラウドプラットフォームを提供するためのIMSおよびDMSとして機能するStarlingX*96．
・WG6仕様に従って，VNF LCM（Life-Cycle Management）などのインタフェースを提供しつつVNFおよびCNFを調整・管理するためのDMSとして機能するOpenStack*97 Tacker*98（以下，Tacker）．
（3）O-DU
O-DUは，細分化されたRANアーキテクチャの重要なコンポーネントであり，無線信号のリアルタイム処理とタスクのスケジューリングを担当している．O-RAN SCは現在，O-DUの基本実装としてOAI（OpenAirInterface）*99をベースに検討しており，これによりオープンで柔軟なソフトウェアドリブン*100のRAN機能を可能にする．O-DUは，O-Cloud内のTackerを介して制御される仮想化（vCU，vDU）仕様と統合されることが期待されている．

O-RAN SCは現在進行中のプロジェクトであり，コンポーネントは段階的に開発されている．StarlingXとTackerをベースに構築されたO-Cloudインフラストラクチャについては，WG6の要件との整合に向けて検討が進められており，O-RAN SCのリリースサイクルに従ってO-CloudやSMOのさまざまなコンポーネントが随時提供されている（図4）．しかし，ハードウェアAALは依然として検討が不足しているコンポーネントである．また，SMOフレームワークは初期段階にあり，障害，構成，パフォーマンス管理*101のためのFOCOM（Federated O-Cloud Orchestration and Management）*102など，多くの重要なモジュールがまだ開発中である．
O-RAN SCは，将来のワイヤレスネットワークのために，完全にオープンで，クラウドネイティブで，AI主導のRANエコシステムを構築することをめざしている．

3.5 Tacker

Tackerは，さまざまな業界標準とオープンソース実装の間のギャップを埋める重要な役割を果たし，通信エコシステムにおける整合性と相互運用性を確保している．これは，ETSI NFV標準仕様，WG6標準仕様，OpenStackオープンソースインフラストラクチャ，およびO-RAN SCオープンソース実装の間の仕様・実装の橋渡しとしての役割を担っている．これにより，Tackerはテレコム業界の仕様や実装の断片化を回避し，さまざまな利害関係者がNFVオーケストレーションとO-RANデプロイに対して統一されたアプローチを採用できるようになる（図5）．
Tackerは，SOL 001（VNFD（Virtual Network Function Descriptor）*103記述子テンプレート），SOL 002/003（NFVライフサイクル管理API）などのETSI SOL（ETSI Service Orchestration Layer）*104標準に準拠することで，ETSI NFV ISG（Industry Specification Group）*105仕様を具体化しているオープンソースである．Tackerが利用しているETSI NFVによって標準化されたAPIは，特にO-Cloud環境で，ETSI NFV準拠のネットワーク機能とO-RANコンポーネント間の相互運用性を可能にする．
O-RAN SC内では，TackerはO-CloudにデプロイされたVNFとCNFのオーケストレーションと管理を担当する汎用VNFMとして機能する．TackerはSMOフレームワークに統合され，OSS，RIC，NFVOと連携する．さらに，TackerはO-CloudのCISM，VIM，NFVIと連携し，ネットワーク機能のシームレスなデプロイとライフサイクル管理を促進する．
Tackerは，標準に準拠したオープンソースのVNFMとして機能することで，ETSI NFVとO-RAN SCの両方の実装の相互運用性を維持し，ベンダロックイン*106を減らし，オープンで協調的な通信エコシステムを促進する．この促進により，通信事業者やベンダは，NFVのベストプラクティスを活用して自動化とスケーラビリティを実現しながら，クラウドネイティブのRANコンポーネントを効率的にデプロイできる．

04.ドコモのvRAN実現に向けた標準化活動

ドコモは，O-RAN，3GPP，ETSI NFV，ETSI ZSM，OpenStack，O-RAN SCをサポートすることで，5G以降のオープンでインテリジェントなRANの実現と，柔軟かつ相互運用可能な通信エコシステム構築に向けて積極的に貢献している（図6）．この取組みでは，O-RAN，3GPP，ETSI NFV，ETSI ZSMを含む主要な業界標準を連携させることで，経済的で信頼性の高い自動化されたvRAN実装の実現をめざしている．
(1)インテントドリブン管理への貢献
モバイルネットワークが次世代に向けて進化する中で，デプロイや管理の自動化はvRANの効率的な導入，運用，最適化を可能にする重要な要素となっている．一方で，従来のRANアーキテクチャとは異なり，vRANはリソース利用効率と運用効率の向上のためにオープンで仮想化されたクラウドネイティブなアーキテクチャが導入されており，増大する複雑さ，動的なトラフィックパターン，および厳しいパフォーマンス要件に対応するためのよりインテリジェントな管理が必要となる．
現在，O-RAN AllianceのWG1において，ドコモはSMO Intent-Driven Managementの発展に重要な貢献をしている．本機能は，SMOがルールベースからインテントのような高レベルの結果駆動型に移行することによって，O-RANネットワークの運用における自動化，インテリジェンス，および効率性を向上させることを目的としている．このようなインテントドリブン管理を実現するためにIntent Handler*107を使用することで，オペレータは，具体的な方法（エネルギー効率（EE：Energy Efficiency）の向上，QoS（Quality of Service）*108の最適化など）を手動で定義するのではなく，達成したい「意図（インテント）」を指定できるようになる．次に，Intent Handlerは，自身の中の機械学習*109モデルがリアルタイムデータに基づいてネットワークの動作を予測，最適化，適応できるようにすることによって，これらの「意図」を自動化されたワークフローやネットワーク設定情報に変換する．
ドコモは，WG1に加えて，ETSI ZSMや3GPP SA（Service and System Aspects）*1105などの複数の標準化団体におけるネットワーク管理の自動化にも注力している．3GPP SA5は，Closed loop*111，ネットワークデジタルツイン*112，AI/ML管理などのインテントドリブン管理に加えて，自動化イネーブラ*113を標準化している．
(2)電力消費の課題解決への貢献
さらに，RANの進化に伴い，EEはオペレータにとって重要な優先事項となっている．従来のRANとは異なり，vRANは仮想化のオーバヘッド*114と動的なリソーススケーリングによって電力消費に新たな課題をもたらしている．現在，O-RAN Alliance内の複数のWGにおいて，ドコモはEEと省エネルギー（ES：Energy Saving）の2つの側面からこの課題解決に向けた重要な役割を果たしている．
WG1のユースケース仕様書[7]「Network Energy Savingユースケース」では，特にAI/MLベースの自動化によるEEの最適化とESメカニズムの実装に焦点を当てている．
RANはモバイルネットワークのエネルギーの大部分を消費するため，EEの改善は運用コスト（OPEX（OPerating Expense）*115）と環境への影響の両方を削減するために不可欠である．
ESの手法は，キャリア，RF（Radio Frequency）チャネル，ネットワークコンポーネントの停止からリソース割当ての最適化まで，制御対象の範囲と時間スケールが異なる．ES戦略はO-Cloudコンポーネントにも適用され，O-Cloudリソースのエネルギー管理，エネルギー節約を可能にするアーキテクチャオプション，詳細なエネルギー節約O-CloudユースケースがWG6内でさらに検討されている[11]．
ドコモは，EEの高いvRANを実現するために，3GPP SA5などの他の標準化団体においても大きく貢献している．3GPP TS28.310[12]で規定されているように，3GPP SA5では，エネルギー使用を最小限に抑えながらネットワークパフォーマンスを評価するためのEE KPI（Key Performance Indicator）*116，EEやESを実現する方法論やKPIの取得方法，およびそれら取得したKPIの通知手順を詳細に記述することによって，電力を最適化するためのエネルギー管理とオーケストレーションメカニズムに焦点を当てている．

ドコモはオープンソースの取組みとベンダコラボレーションを，モバイル業界のイノベーションと進化の主要な原動力として重視している．

05.あとがき

ドコモは，ネットワーク全体での効率的な運用を可能にする，経済的で信頼性の高い全国的な展開をめざしたvRANの開発に成功した．この成果は，O-RAN，3GPP，ETSI NFVの業界標準によって支えられており，これらの連携を踏まえた標準化を受け，2024年度に開発され2025年度以降，順次商用デプロイを実施中のvRANシステムは，相互運用性と拡張性を確保している．ドコモは，これらの標準化団体に2千件以上の提案貢献を行い，オープンで仮想化されたネットワークを形作る上で重要な役割を果たしてきている．
また，ドコモは，5G以降に積極的に貢献するために，O-RAN，3GPP，ETSI NFV，ETSI ZSM，OpenStack，およびO-RAN SCをサポートし，より相互運用可能で柔軟な通信エコシステムを推進している．これらの取組みは，O-RAN，3GPP，ETSI NFV，ETSI ZSMを含む業界標準をリードすることによって，経済的で信頼性の高い自動化されたvRAN実装を実現し，将来のモバイルネットワークのシームレスな統合と拡張性を確保することに焦点を当てている．
今後ドコモは，vRANの課題を解決し，次世代モバイルネットワークをさらに前進させるために，Beyond 5G*117および6Gの研究開発を積極的に行っている．今後も新たな技術開発やグローバル標準への貢献を通じてイノベーションを推進し，より効率的で柔軟かつインテリジェントなネットワーク基盤の実現をめざす．

文献