5G（第5世代移動通信システム）時代のモバイルネットワークでは、高速・大容量、低遅延、多数端末同時接続など、さまざまな要求条件を満たすサービスの提供が期待されています。このような高度なサービス要求に対応するため、オペレータはRAN（Radio Access Network）機能の高度化やネットワーク規模拡大を継続的に実施していますが、その結果として、RANの設計や運用が複雑化しています。そこで、これまで3GPP（3rd Generation Partnership Project）において、オペレータのRAN構築・運用の負担軽減のため、ネットワーク構築、エリアや運用パラメータの最適化、障害復旧を自動で行う技術としてSON（Self Organizing Network）＊1の標準化が行われてきましたが、ビッグデータやAI/ML（機械学習）を活用したインテリジェントな方式によるオペレーションの自動化が求められています。RAN制御の観点でも、AI/MLの活用によりプロアクティブな制御が可能となりRANパフォーマンスや顧客満足度の向上が期待できます。
O-RAN ALLIANCE＊2では、RANインテリジェント化を目的として、ビッグデータやAI/MLを活用した運用・制御を実現するためのアーキテクチャや各種制御インタフェースの標準化が行われており、NTTドコモにおいても技術検討を積極的に進めています。
本稿では、O-RAN ALLIANCEで標準仕様化が検討されている、RANインテリジェント化のためのアーキテクチャや各種インタフェースが提供する機能や制御手順について解説し、NTTドコモにおけるRANインテリジェント化のロードマップについて紹介します。

＊1　SON：eNB設置時の自動設定やパラメータの自動最適化などを含む、無線ネットワーク自己最適化機能の通称。
＊2　O-RAN ALLIANCE：次世代の無線アクセスネットワークの拡張性をより高く、オープンでインテリジェントにすることを目的に活動している電気通信事業者および通信機器サプライヤによる団体。

O-RAN ALLIANCEのRANアーキテクチャでは、基地局のパラメータ設計と設定、および運用の自動化・最適化を行う論理ノードとしてRIC（RAN Intelligent Controller）が定義されています。
図1に示すとおり、RICは、Non-RT（Real Time）RICとNear-RT RICの2種類が定義され、それらのうちNon-RT RICは、RANの監視・保守やオーケストレーションを行うSMO（Service Management and Orchestration）の内部に配置されます。Non-RT RICはA1インタフェースを介してNear-RT RICと接続し、さらにNear-RT RICはE2インタフェースを介してO-CU（O-RAN Central Unit）やO-DU（O-RAN Distributed Unit）といったE2ノード＊3と接続します。また、E2ノードやNear-RT RICはO1インタフェースによってSMOと接続しています。O-RAN ALLIANCEにおいて検討されているRANアーキテクチャに基づいて、使用する制御インタフェース、AI/MLの機能配置を組み合わせることにより、さまざまな形態のインテリジェントな制御が実現可能となります。
（1）Non-RT RIC
Non-RT RICはSMO内部のOAM（Operation Administration and Maintenance）サービスを提供する機能部と連携することで、E2ノードからO1インタフェースを通じて、PM counter（Performance Management counter）、FM data（Fault Management data）、TM data（Trace Management data）といったE2ノード内で蓄積された各種データを収集します。Non-RT RICは、AI/MLを活用して無線環境やトラフィック負荷に合わせて最適化した設定パラメータを、O1インタフェースを介してE2ノードに反映することができます。また、RAN制御にかかわるポリシーの生成を行い、A1インタフェースを通じてNear-RT RICにポリシーを通知することができます。これらの制御は1秒以上の比較的長い制御周期で実施されます。
（2）Near-RT RIC
Near-RT RICはE2ノードからE2インタフェースを用いて、E2ノードの情報を収集し、また内部で分析した結果をNon-RT RICから通知されたポリシーに従ってE2ノードの制御に反映することが可能です。Near-RT RICはE2インタフェースを介してE2ノードと直接接続することで、制御周期が数10m秒〜1秒程度の高速な制御を行います。
（3）rApp
Non-RT RICでは、各種情報の分析やポリシーの生成を行うため、rApp（Non-RT RIC Application）と呼ばれるアプリケーションが用いられます。rAppはNon-RT RICフレームワークから独立したアーキテクチャとなっており、R1インタフェースによりNon-RT RICフレームワークと接続されます。
（4）xApp
Near-RT RICのフレームワーク上で各種情報の分析や制御を実行するアプリケーションはxApp（Near-RT RIC Application）と呼ばれます。Near-RT RICにおいても、フレームワークとアプリケーションは分離されており、O-RAN ALLIANCEが仕様化するNear-RT RIC API（Application Programming Interface）により接続されます。

＊3　E2ノード：E2が接続する装置のことであり、具体的にはO-CU-CP、O-CU-UP、O-DU、O-eNBのことを指します。

（1）O1インタフェース
O1インタフェースは、SMOがE2ノードやNear-RT RICに対して、FCAPS（Fault、Configuration、Accounting、Performance and Security）、ソフトウェア管理、ファイル管理といったOAM機能を提供するインタフェースです。Non-RT RICは、SMO内のOAMサービスを提供する機能部と連携して、E2ノードが生成するPM counterを、O1インタフェースを用いて取得し、またNon-RT RIC内のrAppが最適化したConfiguration設定値をE2ノードへ反映することができます。さらに、Near-RT RICにおいてMLを適用するケースでは、MLモデルのデプロイにもO1インタフェースを利用することが想定されています。
（2）A1インタフェース
A1インタフェースは、Non-RT RICとNear-RT RIC間のインタフェースです。A1インタフェースには、①A1 Policy Management Service（A1-P）と②A1 Enrichment Information Service（A1-EI）と③A1 ML Model Management Service（A1-ML）の3つの機能が規定されています。
（3）E2インタフェース
E2インタフェースは、Near-RT RICとE2ノード間のインタフェースです。E2インタフェースが提供する機能は、E2ノードの制御機能情報や制御履歴情報のNear-RT RICへの公開 とE2ノードに対する制御コマンドの通知です。E2ノードに対しては、RRC（Radio Resource Control）のHO（Hand Over）制御や、S1/X2/NG/Xn/F1/ E1プロシージャーの制御を行うことができます。また、制御はセル単位、スライス単位、またはUE単位で指定できます。
（4）R1インタフェース
R1インタフェースは、rAppとNon-RT RICフレームワーク間のインタフェースです。機能はrAppとNon-RT RICフレームワーク間でデータや制御情報を送受信することです。R1インタフェースの主要な機能に、サービスの管理公開機能としてSME（Service Management and Exposure）services、データの管理公開機能としてDME（Data Management and Exposure）servicesがあり、その他にA1-related services、O1-related services、O2-related services、A1/ML workflow servicesが規定されています。
SMEには、Non-RT RICフレームワークが提供する各種サービスのエンドポイントを伝えるBootStrap、rAppが提供するサービスの登録を行うRegistration、Non-RT RICフレームワークやrAppが提供するサービスを探すDiscovery、rAppの状態監視を行うHeartbeat、rAppが提供するサービスの認証・認可を行うAuthenticationとAuthorizationといった機能があります。
DMEには、Non-RT RICフレームワークやrAppが提供可能なデータを登録するData registration、登録済みのデータ（データカタログ）を取得するData discovery、データを要求するData request/subscription、データを収集するData Collection、データを送信するData deliveryといった機能があります。
O1-relatedは、SMOが取得できるNF（Network Function）のコンフィグやステータスなどを取得するNetwork Information service、FMとPM情報をそれぞれ取得するFM/PM serviceが現状では規定されています。A1-relatedとO2-relatedとAI/ML Workflowの機能詳細は未規定です。なお、R1インタフェースはO-RAN ALLIANCEでも標準化を開始したばかりで、詳細は未規定のため、今後機能の更新や変更が入ることが想定されます。
（5）Near-RT RIC APIs
Near-RT RIC APIsは、xAppとNear-RT RICフレームワークの間のAPIです。A1 related APIs、E2 related APIsのほか、xAppとAI/MLモデルの管理（登録、更新、削除、コンフィグ）、ロギング、トレース、メトリクス収集を扱うManagement APIs、SDL（Shared Data layer）関連機能へのアクセス機能であるSDL APIs、xAppがAPIを使用するための認証や登録などを行うEnablement APIsが規定されています。

Non-RT RIC、Near-RT RIC上で動作する制御アルゴリズムは、前述のとおりそれぞれrApp、xAppによって実装され、これによりオペレータは、Non-RT RICフレームワークを提供するベンダのrAppだけでなく、第三者が提供するrAppを採用することも可能となります。また、オペレータがRANの運用経験やノウハウに基づいて、RANの制御ポリシーをrAppのアルゴリズムに反映し、さまざまな要求条件を満たすサービス提供を実現していくことも可能になります。
rAppはDMEを介して他のrAppとデータ共有することが可能であり、例えば、データの集計・分析に特化したrApp、その結果を受け取ってMLモデルを生成するrApp、MLモデルを利用して推論を行い、その結果に基づいてE2ノードに対する制御コマンドや制御ポリシーの生成を行うrApp、といった異なる機能を持つrAppが連携して1つのユースケースを実現することも考えられます。
さらに、自動化・最適化の目的（ユースケース）ごとに異なるrAppまたはxApp（App）を複数適用し、例えば、App_AとApp_Bを並列して動作させる（図2①）など、柔軟な自動化サービスの適用が可能です。また、エリアごとに異なるAppを適用したり（図2②）、同一のAppであってもコンフィグ設定を変更して自動化や最適化の動作を変更したりする（図2③）ことも可能です。

近年、クラウドにより大量のデータ蓄積が容易となったことから、さまざまな分野へのMLの適用が注目されています。インテリジェントRANの実現をめざすO-RAN ALLIANCEにおいても、RAN分野へのMLの適用によるネットワークパフォーマンスの向上が期待されており、それを実現するアーキテクチャが用意されています。
MLの適用には、学習および推論のプロセスが必要となります。学習プロセスでは、データレイクに格納されているネットワークパフォーマンスデータを用いて、RICアーキテクチャの内部、もしくは外部に配置されるML Training HostsがMLモデルを学習し、RIC上に保存します。推論プロセスでは、MLモデルをRIC上のrAppもしくはxApp上にロードし、RICアーキテクチャの内部、もしくは外部に配置されるML Inference Hostsが対象パラメータの最適値を推論します。最適化されたパラメータは、A1インタフェースやE2インタフェースを介してO-CU、O-DUに設定されます。

RICによるRANインテリジェンスの導入に際しては、採用するユースケースによって、必要となる機能や制御インタフェース、最適化のための分析に必要なデータ収集項目が異なり、また、RAN装置（gNB：next generation NodeB＊4）においても対応が必要なインタフェースや機能が異なります。したがって、これらを考慮した導入計画の策定が重要となります。さらに、O-RAN ALLIANCEにおけるユースケースに関連する仕様策定の進捗状況や成熟の見通しも考慮したうえで、段階的にRANインテリジェンスの高度化を図っていく必要があります。
図3に示すとおり、NTTドコモでは、初期のユースケースとして、従来のRAN運用システムで保守者を介して実施していた業務の自動化をターゲットと考え、運用コストの削減を図ることを考えています（図3①）。具体的には、基地局運用パラメータやアンテナ指向方向の自動最適化、トラフィック負荷の予測に基づく省電力化のための基地局スリープ制御などが想定されます。無線環境の変化やトラフィック負荷の変動に応じて数時間〜数日の制御周期で適応的にネットワークの設定を最適化することにより、ユーザ観点でも快適なネットワークの提供をめざします。また、これらのユースケースは、Non-RT RICによるO1インタフェースを用いた制御によって実現でき、RAN装置（gNB）側の機能対応のインパクトも比較的小さいと想定され、導入時のコストを低く抑えられます。さらにAI/MLなどの適用領域を段階的に増加していき、RANの運用におけるより高度なインテリジェンスを実現します（図3②）。
次の段階では、制御スキームの強化（例えば、低速制御から高速制御へ、セルごとの制御からユーザごとの制御へ）によってRANパフォーマンスと顧客満足度の向上につながるユースケースをターゲットとします。具体的には、ユーザやネットワークスライスごとにサービス要件に応じたリソース制御の最適化を行う「トラフィックステアリング」や「QoS/QoE最適化」などを想定しています（図3③）。これらのユースケースの実現には、Near-RT RICの導入に加えA1/E2インタフェースの対応が必要となり、RAN装置（gNB）においてもO-RAN ALLIANCEのWG3が仕様化するE2SM-RC（E2 Service Model RAN Control）で規定される各種機能の対応が必要になるため、RAN装置の機能追加、または、更改も視野に入れた中長期的なマイグレーションが必要になります。さらに、将来的には外部システムとの連携や予測技術の適用も視野に入れ、モバイルネットワークによる新たな価値創造をめざすことを考えています（図3④）。

＊4　gNB：NRのスタンドアローン向けのRANにおいてNR無線を提供する無線基地局。

初期段階のユースケース例として、（1）HO制御パラメータの最適化と、次段階のユースケース例として、（2）トラフィックステアリングをそれぞれ紹介します。
（1）　HO制御パラメータの最適化
基地局とUEの間でHOの実施が早すぎる場合や遅すぎる場合、HOの失敗となり、UEは一時的にネットワークから切断されてしまいます。このようなHOの失敗を防ぐために、Non-RT RICはセル環境の情報や切断事象の情報を分析することで、HO制御に用いるしきい値やタイミングを調整します。Non-RT RICによるHO制御パラメータの最適化の手順を図4に示します。セル単位や時間単位で図4の①〜⑤を自律的かつ自動的に繰り返すことで、常に最適なHO環境をUEに提供します。
（2）　トラフィックステアリング
5Gでは、NRやLTE、Wi-Fiなどのさまざまなアクセスネットワークの組合せをサポートすることができます。それらには複数の周波数帯域での無線環境と、多様なユーザアプリケーションによるトラフィックの変化があり、安定した商用ネットワークを提供するため、以下に示すような高度なトラフィック管理が必要とされます。
・これまでのセル単位から多様な要件を持つUE単位の無線リソース管理（RRM：Radio Resource Management）
・マルチアクセスのネットワークとUEのパフォーマンス予測による負荷分散
・適切なタイミングでのトラフィック制御の適用
RICによりオペレータは、上記内容の実現を目的とした、ネットワーク運用の目的に応じた最適化ポリシーを柔軟に構成し、リアルタイムでのネットワークやUEの適切なパフォーマンス測定を行い、プロアクティブなトラフィック管理を行っていきます。Non-RT RICとNear-RT RICによるトラフィックステアリングの手順を図5に示します。図5の①〜⑨を自律的かつ自動的に繰り返すことで、負荷分散された快適なネットワークを常に提供します。

今後の課題として、マルチベンダオペレーションの実現に向けた以下の課題があると考えています。
O-RAN ALLIANCEのWG5でRAN装置インタフェースを対象に、マルチベンダでの相互接続の実現を目的とした活動が進められてきましたが、RICインタフェース（R1インタフェース、A1インタフェース、E2インタフェース、Near-RT RIC APIs、外部サービス・アプリケーション間の外部インタフェース）も対象に相互接続性が求められます。これらのインタフェースは、WG2、WG3で仕様化が進められていますが、ベンダ間でパラメータ解釈が異なることがないよう、ユースケースごとにE2ノードに対する制御や動作を明確化していく必要があると考えています。
また、オペレーションの課題としては、Apps（rApp、xApp）で提供するAI/MLモデル管理、Apps間での競合管理、システム導入時のRIC機能の適用・非適用エリアの運用管理などが挙げられます。これらの運用管理は、初期導入段階においては保守者が判断して手動で運用することを想定していますが、RIC機能に組み込んで自動化する検討も必要になると考えています。

将来的には、RANドメイン以外のデータを活用してのRANのパラメータ最適化も考えられます。
一例として高速道路でのモビリティ最適化に関して、高速道路付近の基地局のデータだけでなく高速道路管理会社のリアルタイム渋滞情報や渋滞予測データも用いて、端末の移動速度や密集度に応じた基地局パラメータの最適化をRICで行うことが考えられます。さらには、車載センサで取得したデータをスマートフォンなどの車載インテリジェント端末からインターネット経由でRICが取得することで、状況に合わせた最適化も可能になります。具体的には、局所的なモバイルネットワークの混雑を予測して混雑解消のための対策を行ったり、ユーザ端末の移動速度や移動先の予測に基づくハンドオーバ制御の最適化や移動先のリソースを確保したりすることが考えられます。
また、電力供給が不安定な国や地域、状況において、電力供給量に見合ったネットワーク運用を行うために、電力事業者などの停電・通電予定のデータを活用し、停電エリアの基地局の停止と通電エリアの基地局のカバレッジ拡大を自動的に実現することが考えられます。電力供給が安定していても、複数の電力小売り事業者や基地局付属の太陽光発電装置、蓄電池などの電力供給源を選択できる場合、各電源の電力供給量とコストのデータを活用し通信品質を維持したまま電力費用の最小化を行うこともできます。
さらに、大規模なスポーツイベント、音楽フェス、花火大会などの集客イベントがある場合、インターネット上のSNSの投稿などから判明した開催場所と時刻をRICに通知し、あらかじめ当該基地局のパラメータを調整することで同時接続数の拡大を行い、基地局の混雑によるつながりにくさの解消といった対応をとることも可能になります。
こうした都市インフラ関連のデータの公開が進めば、RANインテリジェント化を通じたスマートシティの実現に向けて貢献できることになります。

NTTドコモは、今後も継続してO-RAN ALLIANCEにおけるRANインテリジェント化に向けた仕様策定に寄与していきます。また、現在推進している「5GオープンRANエコシステム（OREC：Open RAN ECosystem）」の取り組みにおいても、RANインテリジェンスの高度化やマルチベンダでの相互接続の実現に向けた検討を牽引していきます。

＊本特集は「NTT DOCOMOテクニカル・ジャーナル」（Vol.30、No.1、2022年4月）に掲載された内容を編集したものです。