JP7842889B2

JP7842889B2 - リアルタイムｒａｎインテリジェントコントローラアーキテクチャ

Info

Publication number: JP7842889B2
Application number: JP2024557984A
Authority: JP
Inventors: チャウハン，アンクール; フォレンザ，アントニオ; パディ，マナシ; バスカラン，シュリダール
Original assignee: Rakuten Symphony Inc
Current assignee: Rakuten Symphony Inc
Priority date: 2022-03-31
Filing date: 2022-10-07
Publication date: 2026-04-08
Anticipated expiration: 2042-10-07
Also published as: US20240214833A1; KR20240129028A; US20240276298A1; EP4500924A1; CN119183672A; EP4500969A4; EP4500924A4; JP2025512887A; US12532193B2; CN118786699A; WO2023191823A1; AU2022450361A1; JP2025504874A; JP7771418B2; WO2023191853A1; KR20240167068A; EP4500969A1; WO2023191823A8

Description

関連出願の相互参照
本出願は、２０２２年３月３１日に出願された米国仮特許出願第６３／３２５８８６号及び２０２２年４月２２日に出願された国際出願ＰＣＴ／ＵＳ２０２２／０２５８６８号の優先権を主張し、各々の内容全体が参照により本明細書に完全に組み込まれる。

ある例示的な実施形態では、本明細書の主題は、一般に、無線アクセスネットワーク（ＲＡＮ）（Ｏ－ＲＡＮ）ワイヤレス通信に関し、より詳細には、オープン無線アクセスネットワーク（Ｏ－ＲＡＮ）及びＲＡＮインテリジェントコントローラ（ＲＩＣ）に関する。

ＲＡＮは、ワイヤレス通信システムの一部である。ＲＡＮは、エンドユーザとワイヤレス通信システムのコアネットワーク（ＣＮ）との間に存在する無線アクセス技術（ＲＡＴ）を実行する。ＲＡＮは、エンドユーザをＣＮに接続する種々のネットワーク要素の組合せを含む。従来、所与のＲＡＮのハードウェア及びソフトウェア要素はベンダ固有である。

オープンＲＡＮアーキテクチャを可能にするためにＯ－ＲＡＮ技術が登場した。Ｏ－ＲＡＮアーキテクチャは、競合、ネットワークの柔軟性、及びコストを改善することを意図している。Ｏ－ＲＡＮの主な目的は、オープンインターフェース及び仮想化を用いてハードウェアプラットフォームとソフトウェアプラットフォームとの間でＲＡＮ機能を分離又は分解するマルチベンダソリューションを作成することである。

したがって、Ｏ－ＲＡＮは、ＲＡＮ機能を集中ユニット（ＣＵ）、分散ユニット（ＤＵ）、及び無線ユニット（ＲＵ）に分解する。ＣＵは、ＲＡＮの無線リソース制御（ＲＲＣ）、サービスデータ適応プロトコル（ＳｅｒｖｉｃｅＤａｔａＡｄａｐｔｉｏｎＰｒｏｔｏｃｏｌ：ＳＤＡＰ）、及び／又はパケットデータコンバージェンスプロトコル（ＰＤＣＰ）サブレイヤをホストするための論理ノードである。ＤＵは、ＲＡＮの無線リンク制御（ＲＬＣ）、媒体アクセス制御（ＭＡＣ）、及び物理（ＰＨＹ）サブレイヤをホストする論理ノードである。ＲＵは、送受信される無線信号を、フロントホールを介してＤＵに送受信されるデジタル信号に変換する物理ノードである。Ｏ－ＲＡＮでは、これらのＲＡＮ機能／要素はオープンプロトコル及びインターフェースを有し、したがって異なるベンダによって提供され得る。

Ｏ－ＲＡＮアーキテクチャにおけるＲＡＮ機能は、ＲＡＮインテリジェントコントローラ（ＲＩＣ）によって制御される。ＲＩＣは、Ｏ－ＲＡＮアーキテクチャのソフトウェア定義構成要素である。ＲＩＣは、革新的なユースケースをサポートしながら、ＲＡＮ動作を大規模に自動化及び最適化するサードパーティアプリケーションのオンボーディングを可能にする。

現在のＯ－ＲＡＮアーキテクチャでは、ＲＩＣは、非リアルタイムＲＩＣ（Ｎｏｎ－ＲＴＲＩＣ）及び近リアルタイムのＲＩＣ（Ｎｅａｒ－ＲＴＲＩＣ）の２つのタイプに分けられる。一般に、Ｎｏｎ－ＲＴＲＩＣは、ＲＡＮ最適化を実行するためにＮｅａｒ－ＲＴＲＩＣによって施行及び使用されるポリシー、データ、及び人工知能（ＡＩ）モデルを提供する。

Ｎｏｎ－ＲＴＲＩＣは、非リアルタイム制御ループの制御点であり、サービス管理オーケストレーション（ＳＭＯ）フレームワーク内で１秒を超える時間スケールで動作する。Ｎｅａｒ－ＲＴＲＩＣは、１０ｍｓ～１秒の間のタイムスケールで動作し、Ｏ－ＤＵ、Ｏ－ＣＵ、及びＯｐｅｎｅｖｏｌｖｅｄＮｏｄｅＢ（Ｏ－ｅＮＢ）に接続する。したがって、Ｎｅａｒ－ＲＴＲＩＣと接続ノードとの間の最小レイテンシ（最小待ち時間）は１０ｍｓである。

例えば１０ｍｓ以上の高いレイテンシループは、リアルタイム動作のためのＡＩモデル及びマルチベンダインテリジェントな管理及び制御の使用を妨げる。したがって、リアルタイムでＯ－ＲＡＮインテリジェント管理を実行するリアルタイム（ＲＴ）ＲＩＣの必要性が存在する。

１つの一般的な態様では、リアルタイム（ＲＴ）ＲＡＮインテリジェントコントローラ（ＲＩＣ）を実行する装置が提供される。ＲＴＲＩＣを実行する装置は、複数の命令を記憶するように構成されたメモリを含み得る。装置はまた、メモリに接続され、複数の命令を実行して、インターフェースを介して少なくとも１つのＯ－ＲＡＮ分散ユニット（Ｏ－ＤＵ）に接続し、インターフェースを介して１０ミリ秒（ｍｓ）未満のレイテンシでリアルタイム制御ループを介して少なくとも１つのＯ－ＤＵを制御する少なくとも１つのアプリケーションをホストするように構成されている、プロセッサ回路を含み得る。この態様の他の実施形態は、各々がＲＴＲＩＣを実行する装置のアクションを実行するように構成された、対応するコンピュータシステム、装置、及び１つ又は複数のコンピュータ記憶デバイス上に記録されたコンピュータプログラムを含む。

実装形態は、以下の特徴のうちの１つ又は複数を含んでもよい。ＲＴＲＩＣが少なくとも１つのＯ－ＤＵと同一場所に配置されている装置。ＲＴＲＩＣが少なくとも１つのＯ－ＤＵの外部にある装置。ＲＴＲＩＣがフロントホールマルチプレクサ（ＦＨＭ）と接続されている装置。ＲＴＲＩＣが、第１のインターフェースを介してサービス管理及びオーケストレーション（ＳＭＯ）プラットフォームに、第２のインターフェースを介して非リアルタイムＲＩＣ（Ｎｏｎ－ＲＴＲＩＣ）に、第３のインターフェースを介して近リアルタイムのＲＩＣ（Ｎｅａｒ－ＲＴＲＩＣ）に、第４のインターフェースを介してネットワーク構成要素に、及び第５のインターフェースを介してＯ－ＲＡＮ無線ユニット（Ｏ－ＲＵ）に接続されており、ＲＴＲＩＣが、ＳＭＯプラットフォーム、Ｎｏｎ－ＲＴＲＩＣ、Ｎｅａｒ－ＲＴＲＩＣ、ネットワーク要素、及びＯ－ＲＵに単独で、又はいずれかの組合せで接続されている、ＲＴＲＩＣを実行する装置。装置は、複数のオープンなアプリケーションプログラミングインターフェース（ＡＰＩ）をさらに有し得、複数のオープンなＡＰＩの各々が、メッセージングインフラストラクチャ回路を介してＲＴＲＩＣの複数のサブモジュールのうちの少なくとも１つとの通信を可能にする少なくとも１つのアプリケーションをホストする。ＲＴＲＩＣの複数のサブモジュールが、競合管理回路、サブスクリプション管理回路、セキュリティ回路、人工知能（ＡＩ）モデル、センサ管理回路、ハードウェア回路、データ公開回路、及び共有データレイクのうちの少なくとも１つを含む、装置。共有データレイクが、ＡＩモデルの情報アーキテクチャ（ＩＡ）の一部である装置。ＡＩモジュールは、機械学習及び深層学習技術に基づき得る。ＲＴＲＩＣが、キャリアアグリゲーションを行うときにプライマリＯ－ＤＵ及びセカンダリＯ－ＤＵと接続するように構成されている、装置。記載された技術の実装形態は、ハードウェア、方法若しくはプロセス、又はコンピュータ有形媒体を含み得る。

別の一般的な態様では、オープン無線アクセスネットワーク（Ｏ－ＲＡＮ）ワイヤレス通信システムが提供される。Ｏ－ＲＡＮワイヤレス通信システムは、Ｏ－ＲＡＮ集中ユニット（Ｏ－ＣＵ）と、少なくとも１つのＯ－ＲＡＮ分散ユニット（Ｏ－ＤＵ）と、少なくとも１つのＯ－ＲＡＮ無線ユニット（Ｏ－ＲＵ）と、インターフェースを介して少なくともＯ－ＤＵに接続され、１０ｍｓ未満のレイテンシでリアルタイム制御ループを介して少なくとも１つのＯ－ＤＵを制御するための少なくとも１つのアプリケーションをホストするように構成されたリアルタイム（ＲＴ）ＲＡＮインテリジェントコントローラ（ＲＩＣ）とを有し得る。Ｏ－ＲＡＮワイヤレス通信システムは、１秒以上のレイテンシを有するリソース及びイベントを管理するように構成された非リアルタイム（Ｎｏｎ－ＲＴ）ＲＩＣと、１０ｍｓ～１秒のレイテンシを有するリソース及びイベントを管理するように構成されたＮｅａｒ－ＲＴＲＩＣと、サービス管理及びオーケストレータ（ＳＭＯ）プラットフォームとをさらに有し得、ＲＴＲＩＣは、第１のインターフェースを介してＳＭＯプラットフォーム、第２のインターフェースを介してＮｏｎ－ＲＴＲＩＣ、第３のインターフェースを介してＮｅａｒ－ＲＴＲＩＣ、第４のインターフェースを介してＲＡＮネットワーク要素、及び第５のインターフェースを介してＯ－ＲＵに接続されている。

Ｏ－ＲＡＮワイヤレス通信システムの実装形態は、以下の特徴のうちの１つ又は複数を含み得る。ＲＴＲＩＣが少なくとも１つのＯ－ＤＵと同一場所に配置されているＯ－ＲＡＮワイヤレス通信システム。ＲＴＲＩＣが少なくとも１つのＯ－ＤＵの外部にあるＯ－ＲＡＮワイヤレス通信システム。ＲＴＲＩＣがフロントホールマルチプレクサ（ＦＨＭ）と接続されているＯ－ＲＡＮワイヤレス通信システム。ＲＴＲＩＣが、複数のオープンなアプリケーションプログラミングインターフェース（ＡＰＩ）を有するように構成され、複数のオープンなＡＰＩの各々が、メッセージングインフラストラクチャ回路を介してＲＴＲＩＣの複数のサブモジュールのうちの少なくとも１つとの通信を可能にする少なくとも１つのアプリケーションをホストする、Ｏ－ＲＡＮワイヤレス通信システム。ＲＴＲＩＣの複数のサブモジュールが、競合管理回路、サブスクリプション管理回路、セキュリティ回路、人工知能（ＡＩ）モデル、センサ管理回路、ハードウェア回路、データ公開回路、及び共有データレイクのうちの少なくとも１つを含む、Ｏ－ＲＡＮワイヤレス通信システム。共有データレイクが、ＡＩモデルの情報アーキテクチャ（ＩＡ）の一部であるＯ－ＲＡＮワイヤレス通信システム。ＲＴＲＩＣが、キャリアアグリゲーションを行うときにプライマリＯ－ＤＵ及びセカンダリＯ－ＤＵと接続するように構成されているＯ－ＲＡＮワイヤレス通信システム。記載された技術の実装形態は、ハードウェア、方法若しくはプロセス、又はコンピュータ有形媒体を含み得る。

別の一般的な態様では、オープン無線アクセスネットワーク（Ｏ－ＲＡＮ）においてリアルタイム（ＲＴ）ＲＡＮインテリジェントコントローラ（ＲＩＣ）を実行するための方法が提供される。本方法は、インターフェースを介してＲＴＲＩＣを少なくとも１つのＯ－ＲＡＮ分散ユニット（Ｏ－ＤＵ）に接続することを有し得る。本方法はまた、インターフェースを介して１０ｍｓ未満のレイテンシでリアルタイム制御ループを介して少なくとも１つのＯ－ＤＵを制御する少なくとも１つのアプリケーションをＲＴＲＩＣによってホストすることを有し得る。

本方法の実装形態は、以下の特徴のうちの１つ又は複数を含んでもよい。本方法は、複数のオープンなアプリケーションプログラミングインターフェース（ＡＰＩ）のうちの少なくとも１つによってＲＴＲＩＣの複数のサブモジュールの各々と通信することをさらに有し得、複数のオープンなＡＰＩの各々が、メッセージングインフラストラクチャを介してＲＴＲＩＣの複数のサブモジュールのうちの少なくとも１つとの通信を可能にする少なくとも１つのアプリケーションをホストし、ＲＴＲＩＣの複数のサブモジュールが、競合管理回路、サブスクリプション管理回路、セキュリティ回路、人工知能（ＡＩ）モデル、センサ管理回路、ハードウェア回路、データ公開回路、及び共有データレイクのうちの少なくとも１つを含む。

図面を参照して説明する。

例示的な実施形態による、ＲＴＲＩＣが２つ以上のＯ－ＤＵとインターフェース接続される一般的なアーキテクチャを示す図である。

１つ又は複数の例示的な実施形態によるＲＴＲＩＣのブロック図である。

例示的な実施形態による、ＲＡＮマイクロサービスを有するＲＴＲＩＣのアーキテクチャを示す図である。

ＲＴＲＩＣが他のＲＡＮマイクロサービスと共にｖＤＵでホストされるアーキテクチャを示す図である。

キャリアアグリゲーションのユースケースのためのプライマリＯ－ＤＵ及びセカンダリＯ－ＤＵを備えた構成を示す図である。

複数のＯ－ＤＵ、Ｏ－ＲＵ、キャビネット、及びセンサからなるセルサイトの論理図である。

図１は、２つ以上の物理的に同一場所に配置されたＯ－ＤＵ（１０４）とのインターフェースを有するＲＴＲＩＣ（１０２）の一般的なアーキテクチャを示し、このアーキテクチャでは、ＲＴＲＩＣ（１０２）は、Ｏ－ＤＵ（１０４）のいずれか１つ又は外部ユニット上でホストされ得る。ＲＴＲＩＣ（１０２）は、Ｏ－ＤＵ（１０４）と同じプロセッサ（例えば、ＣＰＵ、ＧＰＵ、又はいずれかのハードウェアアクセラレータ）内に実装されてもよく、或いは同じマザーボード内の異なるプロセッサ内に、又は同じエンクロージャ内の異なるマザーボード上に、又は同じラック内の別個のエンクロージャ上に、又は同じデータセンタ内の別個のラック上に、又は別個のユニット上に実装されてもよい。ＤＵ（１０４）は、ＦＨＭ（１０６）を介して１つ又は複数のＲＵ（１０８）との通信を確立することができる。

図２は、２つ以上の物理的に同一場所に配置されたＦＨＭ（１０６）とのインターフェースを有するＲＴＲＩＣ（１０２）の一般的なアーキテクチャを示す。各ＦＨＭは、１つ又は複数のＤＵ（１０４）に接続又は統合することができる。このアーキテクチャでは、ＲＴＲＩＣは、ＦＨＭと同じプロセッサ（例えば、ＣＰＵ、ＧＰＵ、又はいずれかのハードウェアアクセラレータ）、又は同じマザーボード内の異なるプロセッサ、又は同じエンクロージャ内の異なるマザーボード、又は同じラック内の別個のエンクロージャ、又は同じデータセンタ内の別個のラック内に実装されてもよい。ＦＨＭは、１つ又は複数のＯ－ＲＵとＲＴＲＩＣとの間でデータ又は制御情報（例えば、ＳＲＳ信号）を集約するように構成され得る。

図３は、１つ又は複数の例示的な実施形態によるＲＴＲＩＣのブロック図である。ＲＴＲＩＣ３０２は、ＲＴＲＩＣ３０２をＳＭＯ３０４に接続する第１のインターフェース（非限定的な例として、Ｋ１インターフェースとラベル付けされる）を含み得る。第１のインターフェースは、ネットワーク構成プロトコル（ＮＥＴＣＯＮＦ）又はいずれかの他のネットワーク管理プロトコルを使用する標準又は独自のインターフェースを介して実行される運用及び保守インターフェースであり得る。一実施形態では、ネットワーク管理プロトコルは、管理オブジェクトインスタンスを作成する、管理オブジェクトインスタンスを削除する、管理オブジェクトインスタンス属性を変更する、及び／又は管理オブジェクトインスタンス属性を読み取るための管理サービスをプロビジョニングするために使用される。別の実施形態では、第１のインターフェースは、故障監視管理、性能保証管理、トレース管理、ファイル管理、ハートビート管理、物理ネットワーク機能（ＰＮＦ）の起動及び登録管理、並びに／又はＰＮＦソフトウェア管理を含む複数のサービスのうちの少なくとも１つを実行する。別の実施形態では、Ｋ１インターフェースは、ＲＴＲＩＣ３０２からＳＭＯ３０４に性能管理（ＰＭ）カウンタ又は故障管理（ＦＭ）アラームを報告することを含む。

ＲＴＲＩＣ３０２は、ＲＴＲＩＣ３０２をＮｏｎ－ＲＴＲＩＣ３０６に接続する、非限定的な例としてＫ２インターフェースとラベル付けされる第２のインターフェースを含み得る。第２のインターフェースは、Ｎｏｎ－ＲＴＲＩＣ３０６がＲＡＮを最適化するためにＲＴＲＩＣ３０２にポリシーベースのガイダンス、機械学習（ＭＬ）モデル管理、及び強化情報を提供することを可能にする。一実施形態では、第２のインターフェースのプロトコルスタックは、インターネットプロトコル（ＩＰ）、伝送制御プロトコル（ＴＣＰ）、ハイパーテキスト転送プロトコルセキュア（ＨＴＴＰＳ）、ＪａｖａＳｃｒｉｐｔオブジェクト表記法（ＪＳＯＮ）、及び／又はいずれかの他の独自のレイヤ若しくは標準レイヤなどの１つ又は複数のレイヤを含む。

ＲＴＲＩＣ３０２は、ＲＴＲＩＣ３０２をＮｅａｒ－ＲＴＲＩＣ３０８に接続する、非限定的な例としてＫ３インターフェースとラベル付けされる第３のインターフェースを含み得る。第３のインターフェースは、Ｎｅａｒ－ＲＴＲＩＣ３０８がＲＡＮを最適化するためにＲＴＲＩＣ３０２にポリシーベースのガイダンス、ＭＬモデル管理、及び強化情報を提供することを可能にする。一実施形態では、第３のインターフェースのプロトコルスタックは、ＩＰ、ＴＣＰ、ＨＴＴＰＳ、ＪＳＯＮ、及び／又はいずれかの他の独自のレイヤ若しくは標準レイヤを含む複数のレイヤのうちの少なくとも１つを含み得る。別の実施形態では、Ｋ３インターフェースは、Ｏ－ＲＡＮ規格準拠のＥ２インターフェース（すなわち、ＳＣＴＰ上のＥ２ＡＰ）としてモデル化される。Ｎｅａｒ－ＲＴＲＩＣ３０８は、非限定的な例として、Ｅ２インターフェースを介してＯ－ＣＵ３１４及びＯ－ＤＵ３１０に接続する。

加えて、非限定的な例として、Ｎｅａｒ－ＲＴＲＩＣ３０８は、Ｏ１インターフェースを介してＳＭＯ３０２と接続し、Ａ１インターフェースを介してＮｏｎ－ＲＴＲＩＣ３０６と接続する。

第４のインターフェース（非限定的な例として、Ｋ４インターフェースとラベル付けされている）は、ＲＴＲＩＣ３０２を論理ネットワーク要素３１０に接続する。当業者であれば、図３に示す論理ネットワーク要素はＯ－ＤＵ３１０であり、ＲＴＲＩＣ３０２は、Ｏ－ＤＵ、Ｏ－ＣＵ－ＣＰ、Ｏ－ＣＵ－ＵＰ、又はＯ－ｅＮＢのうちの少なくとも１つを含む複数のネットワーク要素のうちの少なくとも１つに論理的に接続され得ることを理解するであろう。

第４のインターフェースは、ＲＴＲＩＣ３０２の異なるサービス（例えば、報告、挿入、制御、及びポリシー）及びサポート機能（例えば、インターフェース管理、サービス更新など）を可能にする。

ＲＴＲＩＣ３０２は、Ｏ－ＲＵ３１２に接続する、非限定的な例としてＫ５インターフェースとラベル付けされる第５のインターフェースを含み得る。第５のインターフェースは、制御、ユーザ及び同期プレーンを実装することによって、ＲＴＲＩＣ３０２と複数のＯ－ＲＵ３１２のうちの少なくとも１つとの間でデータ及び／又は制御情報を交換するために使用される直接論理チャネル又はインターフェースである。

図４は、例示的な実施形態による、ＲＡＮマイクロサービスを有するＲＴＲＩＣ３０２のアーキテクチャのブロック図である。図４に示すオープンＡＰＩ４０２は、ＲＴＲＩＣ３０２と対話し、ＲＴＲＩＣ３０２からサービスを取得することができるｚＡｐｐ４０４を使用してＲＴＲＩＣ３０２プラットフォームによって公開されるＡＰＩのセットを指す。ｚＡｐｐ４０４は、Ｎｏｎ－ＲＴＲＩＣで実装され得るｒＡｐｐ及びＮｅａｒ－ＲＴＲＩＣで実装され得るｘＡｐｐと同様に見ることができる。ただし、ｚＡｐｐはＲＴＲＩＣアプリケーションである。

図３を参照すると、ＲＴＲＩＣ３０２は、ＳＭＯ３０４（Ｋ１終端）、Ｎｏｎ－ＲＴＲＩＣ（Ｋ２終端）、Ｎｅａｒ－ＲＴＲＩＣ３０８（Ｋ３終端）、ネットワーク要素（Ｋ４終端）、及びＯ－ＲＵ３１２（Ｋ５終端）で終端する接続を含むことが理解される。

メッセージングインフラストラクチャ４０６は、ｚＡｐｐ４０４がＲＴＲＩＣ３０２の内部サブモジュールと通信することを可能にするメッセージングフレームワークであり、場合によっては複数の方法で実行される。

競合管理サブモジュール４０８は、異なるｚＡｐｐによって開始された異なる要求によって引き起こされる競合を解決する構成要素を指す。競合は部分的又は完全であり得る。競合を解決している間、競合管理モジュール４０８は、ｚサブスクリプション管理モジュール４１０にコンタクトし得、競合を解決している間、サブスクリプション及び優先度情報を利用し得る。

サブスクリプション管理サブモジュール４１０は、ｚＡｐｐ４０４がオンボードされている間にサブスクリプション時間情報を記憶し、サブスクリプション情報は、オープンＡＰＩのアクセス許可（アプリケーション優先度）を保持することを含むことができるが、これに限定されない。

セキュリティサブモジュール４１２は、ＲＴＲＩＣのセキュリティ及び安定性を保証し、サードパーティｚＡｐｐ４０４はＲＴＲＩＣで有効化されたセキュリティフレームワークに準拠する必要があり、セキュリティフレームワークはデータ保護を可能にし、オンボードされたいずれかのｚＡｐｐ４０４に対するゼロトラストプロビジョニングを可能にする。

ＡＩ／ＭＬエンジンサブモジュール４１４は、共有データレイク４２０に存在するデータを処理し、ポリシー／構成をはるかに高速に作成する。ＡＩエンジン４１４は、機械学習（ＭＬ）及び／又は深層学習技法を含み得ることを理解されたい。共有データレイク４２０は、ＡＩモデルの情報アーキテクチャ（ＩＡ）の一部である。

ＭＬは、訓練及び推論という２つの段階で機能し得る。訓練段階では、分析されるデータのタイプに関して可能なすべてを学習することができるように、データはモデルに供給される。推論段階では、モデルは、リアルタイムデータに基づいて予測を行い、実施可能な結果を生成することができる。深層学習では、深層ニューラルネットワーク（ＤＮＮ）は、データセットを分析してデータに関する予測を行う方法を学習することができる。深層学習は、システムが誤った結論から学習するようにフィードバックに依存する。

サービスと称されることがあるデータ公開サブモジュール４２２は、アプリケーション、例えばｚＡＰＰへのデータの公開を制御及び保証する。Ｏ－ＲＵ（Ｋ５終端３１２）から来るあるデータは、低優先度のアプリケーションが、より高い優先度のアプリケーションが登録されるまでこのデータがそれにアクセスすることができないことがあるというアクセス許可を有していても、単一のアプリケーション又は高優先度のアプリケーションによって公開／アクセスされることがある。データ公開サブモジュール４２２は、このアクセスを制御し得る。さらに、データ公開サブモジュール４２２は、ＲＴＲＩＣ３０２が特定のデータセットをどれほどの長さ記憶しなければならないかを制御することができ、データ公開サブモジュール４２２は、データ共有技術、例えばプッシュ及びプル動作を実施することができる。

センサ管理サブモジュール４１６は、セルサイトに存在するすべてのセンサからの入力を取得し、センサは、キャビネット温度、風負荷、アンテナ傾斜、クラッタ画像などを測定することができる。

ハードウェア管理サブモジュール４２４は、セルサイトに存在するハードウェアから情報を取得することができ、これは、フロントホールインターフェースの平均／ピークＣＰＵ／メモリ利用率、平均／ピーク利用率などを含み得る。ＡＰＩ拡張は、ＡＰＩ拡張モジュール４２６を介して実行されてもよい。

図５は、ＲＴＲＩＣが他のＲＡＮマイクロサービス５０４と共に仮想ＤＵ（ｖＤＵ）５０２でホストされるアーキテクチャを示す。ｖＤＵは、クラウドネイティブアーキテクチャで実行することができる。これは、Ｋ８ｓノードとして実行されてもよい。Ｋ８ｓノードは、コンテナ化されたアプリケーションを実行するノードの論理的な集合又はグループ化を提供する、Ｋｕｂｅｒｎｅｔｅｓノードとも称され得る。マイクロサービス５０４の機能は、制御及びデータプレーン機能、並びにベースバンド機能を含み得る。

グリーンフィールド５Ｇネットワークは、スタンドアロンアーキテクチャ（ＳＡ）と称される５Ｇネットワークコアに配備され得る。しかしながら、４Ｇから５Ｇへの移行は、既存の４ＧＬＴＥネットワークコア上に新しい５ＧＲＡＮをオーバーレイすることを必要とする。これは、非スタンドアロンアーキテクチャ（ＮＳＡ）と称される。

ＮＳＡで配備されたネットワークは、４ＧＯ－ＤＵへのソフトウェアアップグレードを実施することによって５ＧＳＡネットワークにアップグレードすることができる。同一場所に配置されたＯ－ＤＵからキャリアアグリゲーションを実行するには、Ｏ－ＤＵ間のリアルタイム調整が必要である。

図６は、トラフィックの集約を担当するＯ－ＤＵであるプライマリＯ－ＤＵ６０６と、キャリアアグリゲーションのためにセカンダリキャリアデータをプライマリＯ－ＤＵと共有するセカンダリＯ－ＤＵ６０８とに接続されたＲＴＲＩＣ６０２を示す。ＵＥのモバイルデバイスはただ１つのＲＬＣに関連付けられているので、ＲＬＣはＤＵのうちの１つに固定される。一実施形態では、プライマリＯ－ＤＵ６０６のＲＬＣは、セカンダリＯ－ＤＵ６０８のＭＡＣとリアルタイム通信を有する。別の実施形態では、２つのＯ－ＤＵにわたってＲＬＣバッファを保持するために共有メモリが使用される。一実施形態では、２つのＤＵは、同じ計算又は非均一メモリアクセス（ＮＵＭＡ）ノード及び共有メモリ上にあってもよい。別の実施形態では、２つのＤＵは別々のマシン上にあり、サブ送信時間間隔（ＴＴＩ）リアルタイム粒度で同期し、メモリ競合を回避する分散共有メモリを使用する。ＲＴＲＩＣ６０２及び／又はｚＡｐｐは、ＲＬＣ自体をホストする。次いで、ＣＵ－ＵＰ６０４は、ダウンリンクパケットをｚＡｐｐに直接送る。次に、ｚＡｐｐ内のＲＬＣバッファは、どのセルのＭＡＣにパケットを送るか（すなわち、プライマリＯ－ＤＵ対セカンダリＯ－ＤＵ）、並びにＭＡＣ及びデータパス６１４を介してどのＯ－ＤＵをアクティブ化するかを決定する。データパス６１４は、Ｏ－ＣＵ６０４、プライマリＯ－ＤＵ６０６、セカンダリＯ－ＤＵ６０８、Ｏ－ＲＵ６１０、及びＯ－ＲＵ６１２の間の接続を提供する。

キャリアアグリゲーションは、関連する規格に現在既存である／存在する技術に基づいて、ＴＤＤキャリア及び／又はＦＤＤキャリアのいずれかの組合せで実行され得る。さらに、ＲＴＲＩＣ６０２でホストされているキャリアアグリゲーションアプリケーションは、物理的に別個のＯ－ＤＵ上で動作しているＭＡＣエンティティに起因する遅延に関するデータを収集することができる。ＲＴＲＩＣ６０２でホストされるｚＡｐｐは、キャリアアグリゲーションを行うＭＡＣエンティティを決定することができ、決定は、観察された遅延、構成された現在のスケジューラポリシー、チャネル条件、関連するキャリアのＲＬＣにおけるバッファ状態、及びベアラ優先度に基づくことができる。

ＲＴＲＩＣ６０２上で動作するｚＡｐｐは、Ｏ－ＤＵの物理的分離に起因する遅延の影響を最小限に抑えるために、プライマリＯ－ＤＵ６０６上で動作するＭＡＣスケジューラを構成することができ、このアプローチは、以下のうちの少なくとも１つを含む：
ａ）Ｏ－ＤＵの物理的分離に起因して生じる遅延の影響を最小限に抑えるために、事前にセカンダリキャリア上でデータをスケジュールする、
ｂ）Ｏ－ＤＵの物理的分離に起因する遅延の影響を最小限に抑えるためのＨＡＲＱ構成の最適化、並びに
ｃ）チャネル条件及び／又は遅延に基づいてセカンダリキャリア上のＨＡＲＱプロセス結果を予測する。

上記のプロセスは、単独で、又はｚＡｐｐに従っていずれかの組合せで実施することができる。これらのｚＡｐｐ構成は、Ｏ－ＤＵ（６０６及び／又は６０８）及び／又はＯ－ＲＵ（６１０及び／又は６１２）のＲＴ－ＲＩＣ６０２ポリシーを形成する。キャリアアグリゲーションのためのＲＴＲＩＣ６０２ポリシーは、サービス品質及びネットワークスライス構成に基づいて、異なるキャリアごとに異なり得る。

オペレータごとのカバレッジ及び容量要件は著しく異なることがあり、典型的なＮＳＡの配備では、ＬＴＥレイヤ（典型的にはＦＤＤ）はカバレッジレイヤとして機能することができる一方で、５Ｇレイヤは容量を提供し、ネットワークをＳＡアーキテクチャにアップグレードする場合、オペレータの一部は、キャリアアグリゲーションを行うことによってＳＡアーキテクチャに移行した後でさえも体験を損なわないことが望ましいことがある。これには、リソース割当てポリシー、公平性属性の変更、及び他の構成でスケジューラを更新する必要がある。

ＮｅａｒＲＴＲＩＣからのＯ－ＤＵ及びＲＴＲＩＣからのＯ－ＤＵにおいて構成が競合する場合、ＲＴＲＩＣ６０２からの構成が優先され得る。さらに、ＲＴＲＩＣ６０２は、競合を低減するために、Ｎｅａｒ－ＲＴＲＩＣ及び／又はＮｏｎ－ＲＴＲＩＣからの構成／ポリシーを記憶することができる。

各キャリアが物理的に別個のＯ－ＤＵ上で動作しているキャリアアグリゲーションのユースケースでは、ＲＴＲＩＣ６０２上で動作しているｚＡｐｐは、少なくとも以下の動作を担当することができる。
ａ）ｚＡｐｐが存在しない場合、キャリアアグリゲーションは先行技術に記載されているように機能する。
ｂ）ＲＴＲＩＣ６０２は、ｚＡｐｐがＮｅａｒ－ＲＴＲＩＣ、Ｎｏｎ－ＲＴＲＩＣ、ＳＭＯ及び／又はＯ－ＤＵ自体から構成情報を取得することを可能にすることができ、この情報はＲＴＲＩＣ６０２に現在の構成ポリシーを認識させる。
ｃ）ＲＴＲＩＣ６０２及びＮｅａｒ－ＲＴＲＩＣから受信した構成からＯ－ＤＵ（６０６及び６０８）において構成が競合する場合、ＲＴＲＩＣ６０２からの構成が優先される。一般に、ＲＴＲＩＣ６０２はリアルタイムループで動作し、主にＭＡＣ／ＰＨＹレイヤ構成で動作し得るため、この競合の可能性は低くなり得る。
ｄ）キャリアアグリゲーションを担当するｚＡｐｐは、カバレッジ及び容量拡張に関連するポリシーと共にＯ－ＤＵを構成しながら、この場合、プライマリキャリア及びセカンダリキャリアが動作している物理的に別個のＯ－ＤＵ（６０６／６０８）に起因して引き起こされ得る遅延を考慮に入れる。ＲＴＲＩＣ６０２は、Ｏ－ＤＵ（６０６／６０８）で動作するＭＡＣ、ＭＡＣスケジューラ、及び他の構成要素への構成を可能にすることができる。

一実施形態では、ｚＡｐｐはＲＬＣバッファを管理する。別の実施形態では、プライマリＯ－ＤＵ６０６はＲＬＤバッファを管理する。

本明細書で説明されるシステム及び／又は方法は、異なる形態のハードウェア、ファームウェア、又はハードウェアとソフトウェアとの組合せで実行され得ることが明らかであろう。これらのシステム及び／又は方法を実行するために使用される実際の専用制御ハードウェア又はソフトウェアコードは、実装形態を限定するものではない。したがって、システム及び／又は方法の動作及び挙動は、特定のソフトウェアコードを参照することなく本明細書で説明されており、ソフトウェア及びハードウェアは、本明細書の説明に基づいてシステム及び／又は方法を実行するように設計され得ることが理解される。

電話がスマートフォンに変換された後、同様の変換が現在ネットワーク側で見られており、セルサイトのインテリジェンスが改善しており、セルサイトに存在するＨＷセンサによって電力供給されて、温度、湿度、風負荷、タワー負荷、カメラのクラッタ画像の取り込み、ケーブル配線画像に関連する態様を監視する。この情報の一部は、リアルタイム応答を必要とする。

図７はセルサイトの論理図を示す。セルサイト７０４は、複数のＯ－ＤＵ７０６、Ｏ－ＲＵ７０８、キャビネット７１０、複数のセンサ７１２、フロントホール（ＦＨ）ゲートウェイ／スイッチ７１４、及びＧＰＳ７１６から構成され得る。

一態様では、ＲＴＲＩＣ７０２は、風負荷を含むセルサイト７０４の構成要素が面する現在の負荷を測定することができる。セルサイト７０４の様々な構成要素が面する現在の負荷がセルサイト７０４のタワー又は他の構成要素の負荷容量に近づくと、ＲＴＲＩＣ７０２でホストされるｚＡｐｐは、セルサイト７０４の構成要素が面する損傷を回避するか又は一時的な歪みを低減するために防止措置をとることができる。さらに、この現象がいずれかの特定のサイトで頻繁に発生する場合、ＲＴＲＩＣ７０２は、推奨事項をオペレーショナルサポートシステム（ＯＳＳ）／ビジネスサポートシステム（ＢＳＳ）モジュールに渡すことができる。ＲＴＲＩＣ７０４からのリアルタイム応答が非常に重要であり得るシナリオは、以下である。
ａ）サイト負荷の急増：
ｉ）解決策は、アンテナの傾斜及び／又は方向を変更することによって風負荷を低減することを含む。さらに、これらの解決策では、ＲＴＲＩＣ７０２／ｚＡｐｐは、セルサイト７０４の設置時に決定することができるサイト／タワー負荷容量情報を既に有していてもよく、ＲＴＲＩＣ７０２でホストされるｚＡｐｐは、ＡＩ／ＭＬ技術及びサイトの現在の年齢を使用してサイトの現在の容量を計算することができる、
ｉｉ）上記の解決策に加えて、サイトの現在の負荷がセルサイト７０４の容量に近づくと、ＲＴＲＩＣ７０２でホストされるＡＩ／ＭＬアルゴリズムｚＡｐｐは、サイトの現在の負荷が低減されている間に、ユーザ体験に対する影響が最小限になるアンテナ／Ｏ－ＲＵ７０８の傾斜及び方向の有効な変化を計算することができる、並びに
ｉｉｉ）上記の閾値は異なっていてもよく、アンテナのパネルサイズ及び大規模ＭＩＭＯ（ｍＭＩＭＯ）構成に基づく。
ｂ）キャビネット温度の上昇：
ｉ）解決策は、システムの故障を防ぐためのＣＰＵ処理負荷の低減を含む。ＲＴＲＩＣ７０２でホストされるｚＡｐｐのうちの１つは、温度の現在の状態、ＣＰＵの構成、及び各ＣＰＵに対する負荷を監視することができる、
ｉｉ）解決策は、データを含むシステム性能に対するＣＰＵ負荷低減の影響と共に、温度低下におけるＣＰＵ負荷の低減の分析をさらに含む。ＲＴＲＩＣ７０２でホストされるＡＩ／ＭＬアルゴリズムは、ｚＡｐｐがこの相関関係を計算するのを助けることができる、並びに
ｉｉｉ）上記の解決策に加えて、ｚＡｐｐは、システム性能に対する影響を最小限に抑えながら特定の量の温度低下をもたらし得る特定のアクションを決定することができる。
このアクションは、以下を含み得る、
ａ）例えば６４Ｔ６４Ｒから８Ｔ８ＲへのｍＭＩＭＯ構成の縮小、
ｂ）物理セクタ数の削減、例えば３つの物理４Ｔ４Ｒセクタが２つの物理２^＊２Ｔ２Ｒセクタに変更される、及び
ｃ）ｍＭＩＭＯのための空間レイヤ数の削減。
ｃ）バックアップ電源：
ｉ）典型的なサイト配備では、主電源があり、主電源が利用できない場合にサイトに継続的な電力を供給するために１つ又は複数のバックアップ電源が設けられる。しかしながら、バックアップ電源のコストは通常高く、限られた時間量の間利用可能である。ＲＴＲＩＣ７０２でホストされるｚＡｐｐは、主電源が利用できないときのパターン及びバックアップ電源が使用される期間を監視する。ＲＴＲＩＣ７０２におけるＡＩ／ＭＬアルゴリズムは、ｚＡｐｐがバックアップ電源の使用量を予測するのを助けることができる。一態様において、ｚＡｐｐは、主電源が故障したとき又は故障しようとしているときにＳＭＯに警報を発する。別の実施形態では、ＳＭＯは、ｚＡｐｐ／ＲＴＲＩＣ７０２にエネルギー節約アクションをとるよう命令するか、又はサイトで特定のＲＵ／キャリアをシャットダウンするアクションをとることができる。
ｉｉ）上記で提供された解決策に加えて、ｚＡｐｐは、ユーザに対して最も影響を与えない、容量、カバレッジ、及び消費電力の間のトレードオフを行う。このトレードオフは、本質的に動的であり、セルサイト７０４に特異的である。ＲＴＲＩＣ７０２は、このアプリケーションをホストするように配置される。

このユースケースは、より強いＨＷ要件を有することによって代替的に処理されてもよい。しかしながら、これは指数関数的にコストを増加させ、最悪の場合でも、シナリオはハリケーン中の風負荷の増加のような比較的短い期間に対するものであり得る。ＲＴＲＩＣ７０２で実行されたＳＷ及びＡＩ／ＭＬベースのアプローチを使用することは、効率的で費用効果が高い。

Ｎｏｎ－ＲＴ及びＮｅａｒ－ＲＴＲＩＣ上で動作するアプリケーションは、４０００を超える主要性能指標（ＫＰＩ）を利用してＲＡＮからデータを収集し、データを分析してそのアルゴリズムを調整し、ＲＵとＵＥとの間のワイヤレスアクセスリンクの性能を改善することができる。ＫＰＩを更新する周期性の業界標準は１５分である。これは、Ｎｅａｒ－ＲＴＲＩＣが１０ｍｓｅｃ～１ｓｅｃの間の時間スケールで動作することを考慮すると、大きな遅延数である。ＲＩＣのリアルタイム成分に対応するために、ＫＰＩ周期性を低減することができる。非限定的な例として、異なるアプリケーション及びＫＰＩの典型的な周期性値は、以下である。
１．４Ｇ－ＬＴＥにおけるｅＳＯＮ
ａ．干渉管理
ｉ．ＵＥスループット：２ｓｅｃ
ｉｉ．ＵＥ測定報告：５ｓｅｃ
ｉｉｉ．ＵＥＳＩＮＲ報告：２ｓｅｃ
ｂ．負荷分散
ｉ．負荷情報（容量）：１０ｓｅｃ
２．５Ｇ－ＮＲのｘＡｐｐ。
ａ．ｘＡｐｐｓ
ｉ．ＰＲＢ利用率：５ｓｅｃ
ｉｉ．ＨＡＲＱＡＣＫ－ＮＡＣＫ：５ｓｅｃ

ＫＰＩの周期性を低減することにより、より高い性能向上が得られるより高い粒度が可能になるが、これは、トランスポートを介し、具体的にはフロントホール及びＦ１、Ｅ２、Ａ１、Ｏ１インターフェースを介し、特にＫＰＩの周期性が１ｓｅｃ未満であるときに、より高いオーバーヘッドという犠牲を伴う。トランスポートのための大きなオーバーヘッドを回避する１つの方法は、リアルタイムアプリケーションに使用されるＫＰＩのすべて又は大部分をＤＵに可能な限り近くに保つことである。
Ｎｏｎ－ＲＴＲＩＣ及びＮｅａｒ－ＲＴＲＩＣは、すべてのそれらのＫＰＩを処理するために低レイテンシ制御ループでＤＵの近くに実装されないので、トランスポートのための大きなオーバーヘッドを回避することができない。

ＲＴＲＩＣを可能な限りＤＵ／ＲＵの近くに定義することは、ワイヤレスアクセスに関連するすべてのＫＰＩを収集及び分析し、ＫＰＩに基づいてＡＩ／ＭＬモデルを訓練し、ＭＬ推論を実行するために必要である。一実施形態では、図４に示すように、１つ又は複数のＫＰＩが共有データレイク４２０に送られる。別の態様では、データレイクのＫＰＩは、図４に示すＡＩ／ＭＬエンジン４１４内のＡＩ／ＭＬモデルを訓練するために使用され、ＡＩ／ＭＬエンジン４１４は推論を実行する。別の態様では、ＡＩ／ＭＬ訓練は、図３に示すようにＥ２、Ａ１、及びＯ１インターフェースを介してＫＰＩを単独で又は組合せで送ることによってＮｏｎ－ＲＴＲＩＣ３０６で実行され、ＡＩ／ＭＬ推論はＲＴＲＩＣで実行される。

開示された実施形態に対する他の変形形態は、図面、開示、及び添付の特許請求の範囲の研究から、特許請求された特徴を実施する際に当業者によって理解及び達成されることができる。

特許請求の範囲において、「～を備える（ｃｏｍｐｒｉｓｉｎｇ）」という語は、他の要素又はステップを排除するものではなく、不定冠詞「ａ」又は「ａｎ」は、複数を排除するものではない。

単一のプロセッサ、デバイス、又は他のユニットは、特許請求の範囲に列挙されたいくつかの項目の機能を果たし得る。ある特定の手段が相互に異なる従属請求項に列挙されているという単なる事実は、これらの手段の組合せが有利に使用できないということを示すものではない。

獲得、アクセス、分析、キャプチャ、比較、決定、表示、入力、取得、出力、提供、記憶又は記憶すること、計算、シミュレート、受信、警告、及び停止などの動作は、コンピュータプログラムのプログラムコード手段として、及び／又は専用ハードウェアとして実行することができる。

コンピュータプログラムは、他のハードウェアと一緒に、又は他のハードウェアの一部として供給される光記憶媒体又はソリッドステート媒体などの好適な媒体上に記憶及び／又は分配され得るが、インターネット又は他の有線若しくはワイヤレス電気通信システムを介してなど、他の形態で分配されることもある。

Claims

オープン無線アクセスネットワーク（Ｏ－ＲＡＮ）においてリアルタイム（ＲＴ）無線インターフェースコントローラ（ＲＩＣ）を実行する装置であって、
インターフェースを介して少なくとも１つのＯ－ＲＡＮ分散ユニット（Ｏ－ＤＵ）に接続し、
前記インターフェースを介して１０ミリ秒（ｍｓ）未満のレイテンシでリアルタイム制御ループを介して前記少なくとも１つのＯ－ＤＵを制御する少なくとも１つのアプリケーションをホストする
ように構成されており、
前記ＲＴＲＩＣは、前記ＲＴＲＩＣと近リアルタイムの（Ｎｅａｒ－ＲＴ）ＲＩＣで終端する第３のインターフェースを介して、前記Ｎｅａｒ－ＲＴＲＩＣに接続され、前記第３のインターフェースはＥ２インターフェースとは異なる
装置。
前記ＲＴＲＩＣが前記少なくとも１つのＯ－ＤＵと同一場所に配置されている、請求項１に記載の装置。
前記ＲＴＲＩＣが前記少なくとも１つのＯ－ＤＵの外部にある、請求項１に記載の装置。
前記ＲＴＲＩＣがフロントホールマルチプレクサ（ＦＨＭ）と接続されている、請求項１に記載の装置。
前記ＲＴＲＩＣが、
第１のインターフェースを介してサービス管理及びオーケストレーション（ＳＭＯ）プラットフォームに、
第２のインターフェースを介して非リアルタイム（Ｎｏｎ－ＲＴ）ＲＩＣに、
第４のインターフェースを介してネットワーク構成要素に、及び
第５のインターフェースを介してＯ－ＲＡＮ無線ユニット（Ｏ－ＲＵ）に接続されており、前記ＲＴＲＩＣが、前記ＳＭＯプラットフォーム、Ｎｏｎ－ＲＴＲＩＣ、Ｎｅａｒ－ＲＴＲＩＣ、ネットワーク要素、及びＯ－ＲＵに単独で、又はいずれかの組合せで接続されている、請求項１に記載の装置。
前記装置が、複数のオープンなアプリケーションプログラミングインターフェース（ＡＰＩ）をさらに備え、前記複数のオープンなＡＰＩの各々が、メッセージングインフラストラクチャ回路を介して前記ＲＴＲＩＣの複数のサブモジュールのうちの少なくとも１つとの通信を可能にする少なくとも１つのアプリケーションをホストする、請求項１に記載の装置。
前記ＲＴＲＩＣの前記複数のサブモジュールが、競合管理回路、サブスクリプション管理回路、セキュリティ回路、人工知能（ＡＩ）モデル、センサ管理回路、ハードウェア回路、データ公開回路、及び共有データレイクのうちの少なくとも１つを含む、請求項６に記載の装置。
前記共有データレイクが、前記ＡＩモデルの情報アーキテクチャ（ＩＡ）の一部である、請求項７に記載の装置。
前記ＲＴＲＩＣが、キャリアアグリゲーションを行うときにプライマリＯ－ＤＵ及びセカンダリＯ－ＤＵと接続するように構成されている、請求項６に記載の装置。
オープン無線アクセスネットワーク（Ｏ－ＲＡＮ）ワイヤレス通信システムであって、
Ｏ－ＲＡＮ集中ユニット（Ｏ－ＣＵ）と、
少なくとも１つのＯ－ＲＡＮ分散ユニット（Ｏ－ＤＵ）と、
少なくとも１つのＯ－ＲＡＮ無線ユニット（Ｏ－ＲＵ）と、
インターフェースを介して前記少なくともＯ－ＤＵに接続され、１０ｍｓ未満のレイテンシでリアルタイム制御ループを介して前記少なくとも１つのＯ－ＤＵを制御するための少なくとも１つのアプリケーションをホストするように構成されたリアルタイム（ＲＴ）ＲＡＮインテリジェントコントローラ（ＲＩＣ）と、
１秒以上のレイテンシを有するリソース及びイベントを管理するように構成された非リアルタイム（Ｎｏｎ－ＲＴ）ＲＩＣと、
１０ｍｓ～１秒のレイテンシを有するリソース及びイベントを管理するように構成されたＮｅａｒ－ＲＴＲＩＣと、
サービス管理及びオーケストレータ（ＳＭＯ）プラットフォームと
を備え、
前記ＲＴＲＩＣが、前記ＲＴＲＩＣで終端する第１のインターフェースを介して前記ＳＭＯプラットフォーム、前記ＲＴＲＩＣで終端する第２のインターフェースを介して前記Ｎｏｎ－ＲＴＲＩＣ、前記ＲＴＲＩＣで終端する第３のインターフェースを介して前記Ｎｅａｒ－ＲＴＲＩＣ、前記ＲＴＲＩＣで終端する第４のインターフェースを介してＲＡＮネットワーク要素、又は前記ＲＴＲＩＣで終端する第５のインターフェースを介して前記Ｏ－ＲＵのうちの少なくとも１つに単独で又はいずれかの組合せで接続されている、オープン無線アクセスネットワーク（Ｏ－ＲＡＮ）ワイヤレス通信システム。
前記ＲＴＲＩＣが前記少なくとも１つのＯ－ＤＵと同一場所に配置されている、請求項１０に記載のＯ－ＲＡＮワイヤレス通信システム。
前記ＲＴＲＩＣが前記少なくとも１つのＯ－ＤＵの外部にある、請求項１０に記載のＯ－ＲＡＮワイヤレス通信システム。
前記ＲＴＲＩＣがフロントホールマルチプレクサ（ＦＨＭ）と接続されている、請求項１０に記載のＯ－ＲＡＮワイヤレス通信システム。
前記ＲＴＲＩＣが、複数のオープンなアプリケーションプログラミングインターフェース（ＡＰＩ）を有するように構成され、前記複数のオープンなＡＰＩの各々が、メッセージングインフラストラクチャ回路を介して前記ＲＴＲＩＣの複数のサブモジュールのうちの少なくとも１つとの通信を可能にする少なくとも１つのアプリケーションをホストする、請求項１３に記載のＯ－ＲＡＮワイヤレス通信システム。
前記ＲＴＲＩＣの前記複数のサブモジュールが、競合管理回路、サブスクリプション管理回路、セキュリティ回路、人工知能（ＡＩ）モデル、センサ管理回路、ハードウェア回路、データ公開回路、及び共有データレイクのうちの少なくとも１つを含む、請求項１４に記載のＯ－ＲＡＮワイヤレス通信システム。
前記共有データレイクが、前記ＡＩモデルの情報アーキテクチャ（ＩＡ）の一部である、請求項１５に記載のＯ－ＲＡＮワイヤレス通信システム。
前記ＲＴＲＩＣが、キャリアアグリゲーションを行うときにプライマリＯ－ＤＵ及びセカンダリＯ－ＤＵと接続するように構成されている、請求項１４に記載のＯ－ＲＡＮワイヤレス通信システム。
オープン無線アクセスネットワーク（Ｏ－ＲＡＮ）においてリアルタイム（ＲＴ）無線インターフェースコントローラ（ＲＩＣ）を実行するための方法であって、
インターフェースを介して前記ＲＴＲＩＣを少なくとも１つのＯ－ＲＡＮ分散ユニット（Ｏ－ＤＵ）に接続することと、
前記インターフェースを介して１０ｍｓ未満のレイテンシでリアルタイム制御ループを介して前記少なくとも１つのＯ－ＤＵを制御する少なくとも１つのアプリケーションを前記ＲＴＲＩＣによってホストすることと
を含み、
前記ＲＴＲＩＣは、前記ＲＴＲＩＣと近リアルタイムの（Ｎｅａｒ－ＲＴ）ＲＩＣで終端する第３のインターフェースを介して、前記Ｎｅａｒ－ＲＴＲＩＣに接続され、前記第３のインターフェースはＥ２インターフェースとは異なる
方法。
複数のオープンなアプリケーションプログラミングインターフェース（ＡＰＩ）のうちの少なくとも１つによって、前記ＲＴＲＩＣの複数のサブモジュールの各々と通信することをさらに含み、前記複数のオープンなＡＰＩの各々が、メッセージングインフラストラクチャを介して前記ＲＴＲＩＣの前記複数のサブモジュールのうちの少なくとも１つとの通信を可能にする少なくとも１つのアプリケーションをホストする、請求項１８に記載の方法。
前記ＲＴＲＩＣの前記複数のサブモジュールが、競合管理回路、サブスクリプション管理回路、セキュリティ回路、人工知能（ＡＩ）モデル、センサ管理回路、ハードウェア回路、データ公開回路、及び共有データレイクのうちの少なくとも１つを含む、請求項１９に記載の方法。