特表 2024-533919 自己組織化ネットワークのモビリティ負荷バランシングを可能にするシステムおよび方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-09-18

(54)【発明の名称】自己組織化ネットワークのモビリティ負荷バランシングを可能にするシステムおよび方法

(51)【国際特許分類】

   H04W 28/086 20230101AFI20240910BHJP

   H04W 36/22 20090101ALI20240910BHJP

   H04W 24/02 20090101ALI20240910BHJP

   H04W 88/12 20090101ALI20240910BHJP

【ＦＩ】

H04W28/086

H04W36/22

H04W24/02

H04W88/12

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2023520004

(86)(22)【出願日】2022-08-26

(85)【翻訳文提出日】2023-05-23

(86)【国際出願番号】 IB2022058001

(87)【国際公開番号】W WO2023031744

(87)【国際公開日】2023-03-09

(31)【優先権主張番号】202121039244

(32)【優先日】2021-08-30

(33)【優先権主張国・地域又は機関】IN

(81)【指定国・地域】

(71)【出願人】

【識別番号】523112747

【氏名又は名称】ジェイアイオー・プラットフォームズ・リミテッド

(74)【代理人】

【識別番号】100108453

【弁理士】

【氏名又は名称】村山 靖彦

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広 信哉

(74)【代理人】

【識別番号】100133400

【弁理士】

【氏名又は名称】阿部 達彦

(72)【発明者】

【氏名】サティシュ・ナンジュンダ・スワミー・ジャマダニ

(72)【発明者】

【氏名】マヘシュ・ナヤカ・マイソレ・アナイア

(72)【発明者】

【氏名】マシュー・オーメン

【テーマコード（参考）】

5K067

【Ｆターム（参考）】

5K067AA12

5K067EE02

5K067EE10

5K067EE16

5K067FF02

5K067JJ35

(57)【要約】

本発明は、O-RANアーキテクチャにおいてSONの命令の第1のセット(交換可能にモビリティ負荷バランシング(MLB)と呼ばれる)を実現するための、またそのデータ収集インターワーキング方法を実現するための、効率的かつ高信頼のシステムを提供する。O-RANアーキテクチャは、ニアリアルタイム無線インテリジェントコントローラ(Near RT RIC)(124)およびノンリアルタイム無線インテリジェントコントローラ(Non-RT RIC)(122)と呼ばれる少なくとも2つのエンティティを有する。方法はさらに、この少なくとも2つのエンティティ間でのMLBおよび関連機能フローの機能分割を可能にすることができる。方法はさらに、gNB(O-RANアーキテクチャでは交換可能にE2ノードと呼ばれる)と、Non-RT RICと、Near-RT RICとの間の可能な分割を含む、MLBの実行の局所性を確実なものにすることができる。方法およびシステムはさらに、Near-RT RICエンティティおよびNon-RT RICエンティティ内でのMLB機能実行を容易にするためのデータ収集を可能にすることができる。

【特許請求の範囲】

【請求項1】

オープン無線アクセスネットワーク(O-RAN)内のセルに対して自己組織化ネットワーク(SON)のモビリティ負荷バランシング(MLB)機能を実現するためのシステム(110)であって、
ノンリアルタイム無線アクセスネットワークインテリジェントコントローラ(Non-RT RIC)(122)
を備え、前記Non-RT RICが、
プロセッサと、
前記プロセッサに結合されたメモリと
を備え、前記メモリが、プロセッサ実行可能命令を備え、前記プロセッサ実行可能命令が、実行時に、前記プロセッサに、
リソースステータス要求を1つまたは複数のE2ノードに送信することであって、E2インターフェースの前記1つまたは複数のE2ノードが前記Non-RT RICと通信状態にある、送信することと、
前記送信されたリソースステータス要求に基づいて、前記1つまたは複数のE2ノードから前記セルの負荷情報を受信することと、
収集された負荷情報に基づいて、前記1つまたは複数のE2ノードからレポートを取得することと、
前記取得したレポートをニアリアルタイム無線アクセスネットワークインテリジェントコントローラ(Near-RT RIC)(124)に送信することと、
前記レポートに基づいて、前記Near-RT RICからハンドオーバ(HO)トリガ値を受信することと、
修正されたHOトリガ値に基づいて、前記セルの負荷を低減させることと
を行わせる、システム。

【請求項2】

前記リソースステータス要求が、前記1つまたは複数のE2ノードにE2インターフェースを介して送信される、請求項1に記載のシステム。

【請求項3】

前記1つまたは複数のE2ノードから取得した前記レポートが、Radio Resource status(RR)、Composite Available Capacity Group(CACG)、Slice Available Capacity(SliAC)、および前記セルに関連付けられたアクティブユーザ機器(UE)の数を含む、請求項1に記載のシステム。

【請求項4】

前記1つまたは複数のE2ノードから取得した前記レポートが、前記負荷情報の測定値をさらに含む、請求項1に記載のシステム。

【請求項5】

前記負荷情報の測定が、1つまたは複数のE2ノードによって実施される、請求項4に記載のシステム。

【請求項6】

前記レポートが前記Near-RT RICに、F1AP Resource Status Initiation手順を介して周期的に伝達される、請求項1に記載のシステム。

【請求項7】

前記HOトリガ値が、前記Near-RT RICからE2インターフェースを介して受信される、請求項1に記載のシステム。

【請求項8】

前記セルの前記負荷が所与の時間内に平均負荷未満になるとき、前記セルの前記負荷が前記Near-RT RICによって復旧される、請求項1に記載のシステム。

【請求項9】

前記Near-RT RICが、
前記セルの負荷情報に基づくレポートを受信することと、
前記受信したレポートに基づいて、前記セルを1つまたは複数の隣接セルにオフロードすることと、
前記1つまたは複数の隣接セルから負荷情報を取得することと、
前記取得した負荷情報に基づいて、前記1つまたは複数の隣接セルについてのハンドオーバ(HO)トリガ値を生成することと、
前記セルに関連付けられた1つまたは複数のユーザ機器の再構成のために、前記生成したハンドオーバ(HO)トリガ値をO-CU-CPに送信することと
を行うように構成されている、請求項1に記載のシステム。

【請求項10】

前記1つまたは複数の隣接セルが、所与の期間内に平均負荷未満のセル負荷を有する、請求項9に記載のシステム。

【請求項11】

オープン無線アクセスネットワーク(O-RAN)内のセルに対して自己組織化ネットワーク(SON)のモビリティ負荷バランシング(MLB)機能を実現するための方法であって、
プロセッサによって、リソースステータス要求を、Non-RT RIC(122)と通信状態にあるE2インターフェースの1つまたは複数のE2ノードに送信するステップと、
前記プロセッサによって、前記送信されたリソースステータス要求に基づいて、前記1つまたは複数のE2ノードから前記セルの負荷情報を受信するステップと、
前記プロセッサによって、収集された負荷情報に基づいて、前記1つまたは複数のE2ノードからレポートを取得するステップと、
前記プロセッサによって、前記取得したレポートをニアリアルタイム無線アクセスネットワークインテリジェントコントローラ(Near-RT RIC)(124)に伝達するステップと、
前記プロセッサによって、前記レポートに基づいて、前記Near-RT RICからハンドオーバ(HO)トリガ値を受信するステップと、
前記プロセッサによって、修正されたHOトリガ値に基づいて、前記セルの負荷を低減させるステップと
を含む、方法。

【請求項12】

前記リソースステータス要求が、前記1つまたは複数のE2ノードにE2インターフェースを介して送信される、請求項11に記載の方法。

【請求項13】

前記1つまたは複数のE2ノードから取得した前記レポートが、Radio Resource status(RR)、Composite Available Capacity Group(CACG)、Slice Available Capacity(SliAC)、および前記セルに関連付けられたアクティブユーザ機器(UE)の数を含む、請求項11に記載の方法。

【請求項14】

前記1つまたは複数のE2ノードから取得した前記レポートが、前記負荷情報の測定値をさらに含む、請求項11に記載の方法。

【請求項15】

前記負荷情報の測定が、1つまたは複数のE2ノードによって実施される、請求項14に記載の方法。

【請求項16】

前記レポートが前記Near-RT RICに、F1AP Resource Status Initiation手順を介して周期的に伝達される、請求項11に記載の方法。

【請求項17】

前記HOトリガ値が、前記Near-RT RICからE2インターフェースを介して受信される、請求項11に記載の方法。

【請求項18】

前記セルの前記負荷が所与の時間内に平均負荷未満になるとき、前記セルの前記負荷が前記Near-RT RICによって復旧される、請求項11に記載の方法。

【請求項19】

前記Near-RT RICが、
前記セルの負荷情報に基づくレポートを受信することと、
前記受信したレポートに基づいて、前記セルを1つまたは複数の隣接セルにオフロードすることと、
前記1つまたは複数の隣接セルから負荷情報を取得することと、
前記取得した負荷情報に基づいて、前記1つまたは複数の隣接セルについてのハンドオーバ(HO)トリガ値を生成することと、
前記セルに関連付けられた1つまたは複数のユーザ機器の再構成のために、前記生成したハンドオーバ(HO)トリガ値をO-CU-CPに送信することと
を行うように構成されている、請求項11に記載の方法。

【請求項20】

前記1つまたは複数の隣接セルが、所与の時間内に平均負荷未満のセル負荷を有する、請求項19に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

本開示の実施形態は、一般に、電気通信配備に関する。より詳細には、本開示は、オープン無線アクセスネットワーク(O-RAN)において自己組織化ネットワークのモビリティ負荷バランシングを可能にするためのシステムおよび方法に関する。

【背景技術】

【0002】

関連技術についての以下の説明は、本開示の分野に属する背景情報を提供することが意図されている。本セクションは、本開示のさまざまな特徴に関係することのある、当技術分野のいくつかの態様を含むことがある。しかし、本セクションは、従来技術を認めるものとして使用されるのではなく、読者の本開示に対する理解を高めるために使用されるにすぎないことを理解されたい。

【0003】

負荷バランシングは、サーバファーム内の複数のサーバにわたる、ネットワークトラフィックまたはアプリケーショントラフィックの組織的かつ効率的な分散である。各負荷バランサが、さまざまなタイプのセル組合せ間に位置し、到来する要求を受信し、それらの要求を満たすことの可能な利用可能な任意のサーバにそれらの要求を分散させる。現代のモバイル通信ネットワークは、さまざまなセルタイプとさまざまなアクセス技術との組合せを備える。セルラーネットワークが第4世代(4G)から、第5世代(5G)、次いで第6世代(6G)に、ワイヤレスフィディリティ(WiFi)などの他の無線アクセス技術とともに発展するにつれて、モバイル加入件数も指数関数的に増加する。ますます増加する加入者の需要を満たすために、非常に高密度のヘテロジニアスネットワーク(HetNet)の配備および負荷バランシングも増加する。HetNetは一般に、マルチポートフォリオおよびマルチベンダベースのソリューションによって構築される。

【0004】

オペレータは、HetNetのグリーンフィールドまたはブラウンフィールド配備時に、複数の課題に直面する。課題の1つは、配備されたネットワークの性能および健全性の継続的なモニタリングをカバーする、高品質の設置が求められることである。さらに、変化する環境に動的に適応し、プロアクティブな調整および最適化を行うことも、モバイルオペレータにとって難題である。

【0005】

これらの課題には非常に高度な手作業が求められ、また非常に莫大な運用コスト(OPEX)を招く定期的な/頻繁な現地訪問による大幅な遅延が生じる。これらの欠点を克服し、OPEXを激減させるには、自己組織化ネットワーク(SON)がソリューションとなる。SONは、自己組織化ネットワークとすることもでき、自己最適化ネットワークとすることもできる。SONは、ネットワークが、それ自体をセットアップすること、ならびに最適な性能を達成するようにリソースおよび構成を自己管理することを可能にすることのできる、自動化技術とすることができる。SONは、3つのカテゴリの下で機能することができる。第1のカテゴリは、自動構成(self-configuration)である。自動構成は、キーパラメータの自動的な構成を通じたネットワークへのシームレスな統合に役立つことができる。自動構成は、初期ネットワーク配備時に最も有用である。自動構成には、プラグアンドプレイ機能(PnP)、自動隣接関係(Automatic Neighbour Relation)機能(ANR)、ならびに物理レイヤセル識別子(PCI)の選択および衝突解決機能など、いくつかの機能がある。

【0006】

第2のカテゴリは、自動最適化(self-optimization)である。自動最適化は、無線およびネットワークの構成のニアリアルタイム最適化を通じたネットワーク性能の向上に役立つ。自動最適化は、ネットワークのライフタイム全体を通して有用である。自動最適化には、モビリティ負荷バランシング(MLB)、モビリティロバストネス最適化(Mobility Robustness Optimization)(MRO)、ランダムアクセスチャネル(RACH)最適化、省電力化(Energy Saving)(ES)、無線リンク障害レポーティング、カバレッジおよび容量の最適化(Coverage and Capacity Optimization)(CCO)、データリンク(DL)電力制御、リモート電気チルト(RET)、フォワードハンドオーバ、高頻度ハンドオーバ軽減(Frequent Handover Mitigation)(FHM)、ならびに干渉軽減(セル間、セル内、無線アクセス技術内(RAT内(Intra-RAT))、無線アクセス技術間(RAT間(Inter-RAT)))など、さまざまな機能がある。

【0007】

第3のカテゴリは、自動修復(self-healing)である。自動修復は、万一セル/セクタが機能停止した場合には隣接セルがネットワーク品質を維持し、それによって、予期せぬアウテージ状態に直面してもレジリエンス(信頼性)を提供することを可能にするものである。自動修復は、ネットワークのライフタイム全体を通して有用である。自動修復には、セルアウテージ検出(Cell Outage Detection)(デッド(Dead)/シック(Sick)/スリーピング状態の、セル/セクタ/ビーム)、セルアウテージ回復(Cell Outage Recovery)、セルアウテージ補償(Cell Outage Compensation)、およびセルアウテージ補償回復(Cell Outage Compensation Recovery)など、さまざまな機能がある。

【0008】

上記のSON機能は、SONアルゴリズム個々によって、またはSONアルゴリズムのグループによってハンドリングされる。SONアルゴリズムは、管理データ解析サービス(Management Data Analytics Services)(MDAS)データを含む管理データを収集することによってネットワークをモニタリングすること、管理データを解析して、解決する必要のある問題がネットワーク内にあるかどうかを判定すること、問題を解決するためのSONアクションを決定すること、SONアクションを実行し、問題が解決されたかどうかを、管理データを解析することによって評価すること、のような機能を実施する。SONアルゴリズムのロケーションに基づいて、SONは、さまざまなSONユースケースの実装にとって可能である4つの異なるソリューションに分類され、ソリューションは、SONユースケースの必要性に応じて選択される。

【0009】

ドライブテストの最小化(MDT)機能は、SONとは独立して動作するように設計されてきた可能性があるが、その機能は可能な限りいかなる場合でも再利用される。上記のSON機能は、SONアルゴリズム個々によって、またはSONアルゴリズムのグループによってハンドリングすることができる。SONアルゴリズムは、MDASデータを含む管理データを収集することによってネットワークをモニタリングすること、および管理データを解析して、解決する必要のある問題がネットワーク内にあるかどうかを判定すること、のような機能を実施することができる。SONアルゴリズムは、問題を解決するためのSONアクションを決定すること、および解決のためにSONアクションを実行することもできる。さらに、SONアルゴリズムは、問題が解決されたかどうかを、管理データを解析することによって評価することができる。

【0010】

SONアルゴリズムのロケーションに基づいて、SONは、さまざまなSONユースケースの実装にとって可能であり得る4つの異なるソリューションに分類することができる。ソリューションは、SONユースケースの必要性に応じて選択することができる。集中型SON(Centralized SON)(C-SON)は、SONアルゴリズムが管理システム内で実行する機能を含むことができる。クロスドメイン集中型SON(Cross Domain-Centralized SON)(CD C-SON)は、SONアルゴリズムがクロスドメイン(CD)レイヤ内で実行することのできる機能を含むことができる。さらに、ドメイン集中型SON(Domain-Centralized SON)(D C-SON)は、ドメインレイヤ内で実行することのできるSONアルゴリズムとすることができる。さらに、分散型SON(Distributed SON)(D-SON)は、NF内のSONアルゴリズムとすることができる。

【0011】

以後、ハイブリッドSON(Hybrid SON)(H-SON)は、ネットワーク機能(NF)レイヤ、ドメインレイヤ、またはクロスドメイン(CD)レイヤのような2つ以上のレベルにおいて実行することのできるSONアルゴリズムとすることができる。SONアルゴリズムは実装に従うので、異なるベンダがそれらのSONソリューションに異なる手法を選択することがある。一部のベンダは、C-SON手法ベースのソリューションを選択することがあり、一部のベンダは、D-SON手法ベースのソリューションを選択することがあり、他のベンダは、H-SON手法ベースのソリューションを選択することがある。オペレータは、HetNetを配備する際にマルチベンダソリューションの使用を余儀なくされることがある。

【0012】

SON機能に関する3GPP(登録商標)仕様では、その機能の説明はなされているものの、それをどのように実装しなければならないかについては言及されていない。これが、マルチベンダ統合問題を招き、オペレータにそれらのネットワーク内にSONを実装することを思いとどまらせている。O-RANアライアンスは、これらのマルチベンダ相互運用性問題を軽減することを目指すコンソーシアムであるが、O-RANアーキテクチャにおいてSON機能はこれまで対処されていない。さらに、SONアルゴリズムは実装に委ねられるため、異なるベンダがそれらのSONソリューションに異なる手法を選択することがある。一部のベンダは、集中型SON(C-SON)手法ベースのソリューションを考案することがあり、一部のベンダは、分散型SON(D-SON)手法ベースのソリューションを考案することがあり、他のベンダは、ヘテロジーニアスSON手法ベースのソリューションを考案することがある。オペレータは、HetNetを配備する際にマルチベンダソリューションの使用を余儀なくされる。

【0013】

図2Aは、典型的な5G HetNet配備シナリオを示し、ここにおいて、異なるベンダからのネットワーク管理システム(NMS)のような管理エンティティ、異なる1組のベンダからの1組の要素管理システム(EMS)、異なる1組のベンダからの次世代ノードB(gNB)-制御ユニット(CU)のような無線アクセスネットワーク(RAN)ノード、および異なる1組のベンダからのgNB-分散ユニット(DU)。オペレータは、図2Aの配備されたHetNetにおいて問題に直面することがある。問題の1つは、gNB-CU-1(116)とgNB-CU-2(124)のD-SONが、オープンXnインターフェースを介して互いに通信するが、どちらも異なるベンダからのものであるため十分に協調できないことである。

【0014】

別の問題は、gNB-CU-2(124)のD-SONとgNB-CU-n(130)のハイブリッドSON(D-SON+D C-SON)が、オープンXnインターフェースを介して互いに通信するが、どちらも異なるベンダからのものであるため十分に協調できないことである。重要な問題は、C-SONを、(EMSやNMSなどの)管理エンティティと共置されるものとして実現することもでき、あるいはスタンドアロンエンティティとして実現することもできる、ということである。スタンドアロンエンティティとしてのC-SONをRANノードと統合することは極めて困難であり、というのも、インターフェースが実装に委ねられるためである。さらに、NMS(106)内のCD C-SONは、マルチベンダ環境内で動作するとき、D C-SON機能およびD-SON機能の性能に影響を及ぼすことがある。

【0015】

別の問題は、サードパーティSONソリューションを部分的にHetNet内に統合することにあり、この統合により全体的な主要性能指標(KPI)が劣化する。さらに、隣接gNB-CU(116、124、130)にわたるL3無線リソース管理(RRM)協調は、同一ベンダシナリオまたはマルチベンダシナリオにかかわらず欠如していることがあり、それが全体的なKPI性能に影響を及ぼすことになる。マルチベンダのgNB-CU(116、124、130)およびgNB-DU(118、120、122、126、128、132)にわたるL3-RRMおよびL2-RRMの協調は、動的なリソース共有および割り振りに影響を及ぼすことがある。

【0016】

SONと無線リソース管理(RRM)は、プロプライエタリな実装であるとき、複数のベンダがXnインターフェースにわたって互いに協調しても、全体的な性能に著しい影響を及ぼす。各アルゴリズムは別様に振る舞い、それ自体の制限を有する。たとえベンダがサードパーティソリューション[SONおよび/またはRRM]と統合する準備が整っていても、ベンダは、主としてベンダのソリューションのため、出力性能を決定的に定量化/確認することができない。そのような状況は、合意したベンダ間の衝突に終わるのが常である。

【0017】

これらの問題または制限を解決するための可能な1つのソリューションは、SONソリューションと、相互作用するRANノードとの間のインターフェースを、可能な限りオープンインターフェースにすることである。O-RANアライアンスは、無線アクセスネットワーク(RAN)業界において活動するモバイルネットワークのオペレータ、ベンダ、ならびに研究および学術機関からなる、世界的コミュニティである。O-RANアライアンスの使命は、より知的な、オープンな、仮想化された、完全に相互運用可能なモバイルネットワークに向けて、RAN業界を再構築することである。新たなO-RAN標準により、より競争力のある活気に満ちたRANサプライヤエコシステムと、ユーザエクスペリエンスを向上させるためのより迅速な革新が可能になる。O-RANベースのモバイルネットワークは、それと同時に、モバイルオペレータによるRANの配備ならびに運用の効率を向上させる。

【0018】

図2Bは、O-RANによって定義された論理アーキテクチャを示す。O-RANの論理アーキテクチャ内では、図2Bに示すように、無線側が、ニアリアルタイム(RT)RANインテリジェントコントローラ(RIC)(224)機能、O-RAN集約ユニット制御プレーン(O-CU-CP)(228)機能、O-RAN集約ユニット-ユーザプレーン(O-CU-UP)(230)機能、O-RAN分散ユニット(O-DU)(232-1)機能、およびO-RAN無線ユニット(O-RU)(232-2)機能を含む。E2インターフェースが、発展型ノードB(O-eNB)をニアリアルタイムRANインテリジェントコントローラ(Near-RT RIC)に接続する。この図には示されていないが、O-eNBは、O-DU機能およびO-RU機能を、それらの間にオープンフロントホールインターフェースがある状態でサポートする。管理側は、ノンリアルタイムRANインテリジェントコントローラ(Non-RT RIC)機能を含んだサービス管理およびオーケストレーション(SMO)フレームワークを含む。一方、ORAN-Cloud(O-Cloud)(234)は、(Near-RT RIC、O-CU-CP、O-CU-UP、およびO-DUなどの)該当するO-RAN機能、(オペレーティングシステム、仮想マシンモニタ、コンテナランタイムなどの)サポートソフトウェアコンポーネント、ならびに適切な管理およびオーケストレーション機能をホストするためのO-RAN要件を満たす物理的インフラストラクチャノードの集まりを含む、クラウドコンピューティングプラットフォームである。図2Bに示すように、O-RUは、オープンフロントホールM-プレーン(236)インターフェースをO-DUおよびSMOに対して終端する。

【0019】

したがって、以上のように、従来の手法には多くの制限がある。モバイル加入件数が指数関数的に増加しつつあるにつれて、各加入者についてデータ需要が非常に高くなりつつある。セルラーヘテロジニアスネットワークの配備の爆発的増加とともに、莫大なデータスループット要件を満たすために、Wi-Fiアクセスポイント(AP)の配備の需要が非常に高まっている。結果として、オペレータは、2.4GHz、5GHz、さらにはより高い周波数でも動作することのあるWi-Fiアクセスポイントを密に配備している。また、オペレータは、キャリアグレードWi-Fi、エンタープライズWi-Fi、Mi-Fi、家庭用Wi-Fiなどのようなシナリオのためにそのネットワーク内に配備すべきマルチベンダソリューションを、使用せざるを得ない。膨大な数のAPが配備された状態で、干渉が、対処すべき極めて重要な問題になりつつある。将来的なネットワークは、この干渉管理問題に、APの組織化および最適化のためのSON/RRM機能を通じて対処しなければならない。APは、協調なしに密に配置される場合、チャネル/スペクトルの不十分な再利用を呈することがある。さらに、APおよびクライアントの間での著しい競合が生じることがあり、その結果、スループットが低下し、エンドユーザエクスペリエンスが劣化する。

【0020】

さらに、従来技術は、O-RANアーキテクチャにおいてモビリティ負荷バランシング機能を実現するための任意のメカニズムを提供しておらず、O-RANアーキテクチャにおけるさまざまなエンティティ間での任意の機能分割メカニズム、および関連するデータ/制御フローメカニズムも開示していない。

【発明の概要】

【発明が解決しようとする課題】

【0021】

したがって、既存の従来技術の欠点を克服することのできるシステムおよび方法を提供することが、かなり切実に必要とされている。

【0022】

本明細書における少なくとも1つの実施形態が満足させる本開示の目的のいくつかは、本明細書において以下に列挙する通りである。

【0023】

本開示の一目的は、O-RANアーキテクチャにおいてSONのモビリティ負荷バランシング(MLB)機能を実現するためのシステムおよび方法を提供することである。

【0024】

本開示の一目的は、そのデータ収集およびインターワーキング方法を可能にするためのシステムおよび方法を提供することである。

【0025】

本開示の一目的は、ニアリアルタイム無線インテリジェントコントローラ(Near-RT RIC)とノンリアルタイム無線インテリジェントコントローラ(Non-RT RIC)との間でのMLBおよび関連機能フローの機能分割を容易にするためのシステムおよび方法を提供することである。

【0026】

本開示の一目的は、gNB(O-RANアーキテクチャではE2ノードと呼ばれる)と、Non-RT RICと、Near RT RICとの間の可能な分割を含む、MLB機能の実行の局所性をカバーするシステムおよび方法を提供することである。

【0027】

本開示の一目的は、Near-RT RICエンティティおよびNon-RT RICエンティティ内でのMLB機能実行を容易にするためのデータ収集の特定のメカニズムを容易にするシステムおよび方法を提供することである。

【課題を解決するための手段】

【0028】

本セクションは、下で、発明を実施するための形態の中でさらに説明する、本発明のいくつかの目的および態様を、簡略化した形で紹介するために提供されるものである。本概要は、重要な特徴または特許請求される主題の範囲を特定することは意図されていない。

【0029】

一態様では、本開示は、オープン無線アクセスネットワーク(O-RAN)内のセルに対して自己組織化ネットワーク(SON)のモビリティ負荷バランシング(MLB)機能を実現するためのシステムを提供する。システムは、ノンリアルタイム無線アクセスネットワークインテリジェントコントローラ(non-RT RIC)を備え、このノンリアルタイム無線アクセスネットワークインテリジェントコントローラ(non-RT RIC)は、リソースステータス要求(resource status request)を1つまたは複数のE2ノードに送信することであって、E2インターフェースの1つまたは複数のE2ノードがNon-RT RICと通信状態にある、送信することを行うように構成されている。リソースステータス要求は、1つまたは複数のE2ノードにE2インターフェースを介して送信される。さらに、システムのNon-RT RICは、送信されたリソースステータス要求に基づいて、1つまたは複数のE2ノードから当該セルの負荷情報を受信する。

【0030】

さらに、システムのNon-RT RICは、収集された負荷情報に基づいて、1つまたは複数のE2ノードからレポートを取得する。1つまたは複数のE2ノードから取得したレポートは、Radio Resource status(RR)、Composite Available Capacity Group(CACG)、Slice Available Capacity(SliAC)、および当該セルに関連付けられたアクティブユーザ機器(UE)の数を含む。1つまたは複数のE2ノードから取得したレポートは、負荷情報の測定値をさらに含む。負荷情報の測定は、1つまたは複数のE2ノードによって実施される。さらに、システムのNon-RT RICは、取得したレポートをニアリアルタイム無線アクセスネットワークインテリジェントコントローラ(Near-RT RIC)に送信する。レポートはNear-RT RICに、F1AP Resource Status Initiation手順を介して周期的に伝達される。

【0031】

さらに、システムのNon-RT RICは、レポートに基づいて、Near-RT RICからハンドオーバ(HO)トリガ値を受信する。HOトリガ値は、Near-RT RICからE2インターフェースを介して受信される。さらに、システムのNon-RT RICは、修正されたHOトリガ値に基づいて、当該セルの負荷を低減させる。当該セルの負荷が所与の時間内に平均負荷未満になるとき、当該セルの負荷がNear-RT RICによって復旧される。Near-RT RICは、当該セルの負荷情報に基づくレポートを受信するように構成されている。さらに、Near-RT RICは、受信したレポートに基づいて、当該セルを1つまたは複数の隣接セルにオフロードする。

【0032】

さらに、Near-RT RICは、1つまたは複数の隣接セルから負荷情報を取得する。さらに、Near-RT RICは、取得した負荷情報に基づいて、1つまたは複数の隣接セルについてのハンドオーバ(HO)トリガ値を生成する。さらに、Near-RT RICは、当該セルに関連付けられた1つまたは複数のユーザ機器の再構成のために、生成したハンドオーバ(HO)トリガ値をO-CU-CPに送信する。1つまたは複数の隣接セルは、所与の期間内に平均負荷未満のセル負荷を有する。

【0033】

一態様では、本開示は、オープン無線アクセスネットワーク(O-RAN)内のセルに対して自己組織化ネットワーク(SON)のモビリティ負荷バランシング(MLB)機能を実現するための方法を提供する。方法は、リソースステータス要求を1つまたは複数のE2ノードに送信することであって、E2インターフェースの1つまたは複数のE2ノードがNon-RT RICと通信状態にある、送信することを含む。リソースステータス要求は、1つまたは複数のE2ノードにE2インターフェースを介して送信される。さらに、方法は、送信されたリソースステータス要求に基づいて、1つまたは複数のE2ノードから当該セルの負荷情報を受信することを含む。さらに、方法は、収集された負荷情報に基づいて、1つまたは複数のE2ノードからレポートを取得することを含む。1つまたは複数のE2ノードから取得したレポートは、Radio Resource status(RR)、Composite Available Capacity Group(CACG)、Slice Available Capacity(SliAC)、および当該セルに関連付けられたアクティブユーザ機器(UE)の数を含む。

【0034】

1つまたは複数のE2ノードから取得したレポートは、負荷情報の測定値をさらに含む。負荷情報の測定は、1つまたは複数のE2ノードによって実施される。さらに、方法は、取得したレポートをニアリアルタイム無線アクセスネットワークインテリジェントコントローラ(Near-RT RIC)に送信することを含む。レポートはNear-RT RICに、F1AP Resource Status Initiation手順を介して周期的に伝達される。さらに、方法は、レポートに基づいて、Near-RT RICからハンドオーバ(HO)トリガ値を受信することを含む。HOトリガ値は、Near-RT RICからE2インターフェースを介して受信される。さらに、方法は、修正されたHOトリガ値に基づいて、当該セルの負荷を低減させることを含む。当該セルの負荷が所与の時間内に平均負荷未満になるとき、当該セルの負荷がNear-RT RICによって復旧される。

【0035】

Near-RT RICは、当該セルの負荷情報に基づくレポートを受信するように構成されている。さらに、Near-RT RICは、受信したレポートに基づいて、当該セルを1つまたは複数の隣接セルにオフロードする。さらに、Near-RT RICは、1つまたは複数の隣接セルから負荷情報を取得する。さらに、Near-RT RICは、取得した負荷情報に基づいて、1つまたは複数の隣接セルについてのハンドオーバ(HO)トリガ値を生成する。さらに、Near-RT RICは、当該セルに関連付けられた1つまたは複数のユーザ機器の再構成のために、生成したハンドオーバ(HO)トリガ値をO-CU-CPに送信する。1つまたは複数の隣接セルは、所与の期間内に平均負荷未満のセル負荷を有する。

【0036】

本明細書に組み込まれ、本発明の一部をなす添付の図面は、開示される方法およびシステムの例示的な実施形態を示し、図面では、同様の参照番号がさまざまな図面全体を通して同じ部分を指す。図面中のコンポーネントの縮尺は必ずしも一定であるとは限らず、その代わりに、本発明の原理を明確に示すことに重点が置かれている。いくつかの図面は、ブロック図を使用してコンポーネントを示していることがあり、各コンポーネントの内部回路を表していないことがある。そのような図面の発明は、そのようなコンポーネントを実装するために一般に使用される電気部品、電子部品、または回路の発明を含むことが、当業者には理解されよう。

【図面の簡単な説明】

【0037】

【図1】本開示の一実施形態による、本開示の提案されるシステムをその中で、またはそれとともに実装することのできる、例示的なネットワークアーキテクチャ(100)を示す図である。

【図2A】本開示の一実施形態による、既存のHetNet配備およびそれに関連するコンポーネントの例示的な表現(200)を示す図である。

【図2B】本開示の一実施形態による、既存のHetNet配備およびそれに関連するコンポーネントの例示的な表現(220)を示す図である。

【図3】本開示の一実施形態による、システムアーキテクチャの例示的なブロック図表現(300)を示す図である。

【図4】本開示の一実施形態による、サービングセルについての負荷情報を関連するE2ノードから収集するための暫定的シーケンスフローをハイライトした例示的なMLB xApp[UC-1]表現(400)を示す図である。

【図5】本開示の一実施形態による、関連するE2ノードから受信したサービングセルについての負荷情報に対して処理するためのフローをハイライトした例示的なMLB xApp[UC-1]表現(500)を示す図である。

【図6】本開示の一実施形態による、MLBオフロード後に通常状態に復帰するための暫定的シーケンスフローの例示的なMLB xApp[UC-1]表現(600)を示す図である。

【図7】本開示の一実施形態による、O-RANアーキテクチャと統合したMLBのための代替配備シナリオの一例示実施形態(700)を示す図である。

【図8】本開示の一実施形態による、Xnインターフェースにわたる負荷情報収集を構成するための暫定的シーケンスフローの例示的なMLB xApp[UC-2]表現(800)を示す図である。

【図9】本開示の一実施形態による、Xnインターフェースにわたる受信した負荷情報の収集および後処理のための暫定的シーケンスフローの例示的なMLB xApp[UC-2]表現(900)を示す図である。

【図10】本開示の一実施形態による、Non-RT RICにおけるMLBサポートについての機能ブロック図(1000)の一例示実施形態を示す図である。

【図11】本開示の一実施形態による、MLBサポートについてのさまざまなO-RANエンティティにわたるデータのシーケンスフローの例示的な表現(1100)を示す図である。

【図12】本開示の一実施形態による、SMOおよびE2ノードのみにわたるMLBサポートについての機能アーキテクチャの一例示実施形態(1200)を示す図である。

【図13】本開示の一実施形態による、SMOおよびE2ノードのみにわたりNon-RT RICを除外したMLBサポートについての機能アーキテクチャの一例示実施形態(1300)を示す図である。

【図14】本開示の実施形態による、本発明の実施形態をその中で、またはそれとともに利用することのできる、例示的なコンピュータシステム(1400)を示す図である。

【発明を実施するための形態】

【0038】

前述の内容は、本発明の以下のより詳細な説明からより明らかとなろう。

【0039】

以下の説明では、説明を目的として、本開示の実施形態の完全な理解をもたらすためにさまざまな具体的詳細が記載される。しかし、本開示の実施形態はこれらの具体的詳細がなくても実践できることが、明らかとなろう。以後説明するいくつかの特徴をそれぞれ、互いに独立して使用することもでき、あるいは他の特徴との任意の併用で使用することもできる。個々の特徴は、上で論じた課題の全てに対処するとは限らないこともあり、上で論じた課題のいくつかのみに対処することもある。上で論じた課題のいくつかは、本明細書において説明する特徴のいずれかによって完全に対処されるとは限らないことがある。

【0040】

続く説明は、例示的な実施形態を提供するにすぎず、本開示の範囲、適用可能性、または構成を限定することは意図されていない。そうではなく、例示的な実施形態についての続く説明は、例示的な実施形態を実装するための実施可能な説明を当業者に提供するものである。記載された本発明の趣旨および範囲から逸脱することなく、要素の機能および配置にさまざまな変更を加えることができることを理解されたい。

【0041】

実施形態の完全な理解をもたらすために、以下の説明の中で具体的詳細が与えられる。しかし、実施形態はこれらの具体的詳細がなくても実践できることが、当業者には理解されよう。例えば、実施形態を不必要に詳細にして不明瞭にしないために、回路、システム、ネットワーク、プロセス、および他のコンポーネントが、ブロック図の形をとるコンポーネントとして示されることがある。他の場合には、実施形態を不明瞭にすることを避けるために、よく知られている回路、プロセス、アルゴリズム、構造、および技法が、不必要な詳細なしで示されることがある。

【0042】

また、個々の実施形態については、フローチャート、フロー図、データフロー図、構造図、またはブロック図として描かれるプロセスとして説明されることがあることに留意されよう。フローチャートは、動作を逐次プロセスとして説明することができるが、動作の多くは並列または同時に実施することができる。それに加えて、動作の順序は並べ替えることができる。プロセスは、その動作が完了したときに終了するが、図中に含まれていない追加のステップを有することができる。プロセスは、メソッド、関数、プロシージャ、サブルーチン、サブプログラムなどに対応することができる。プロセスが関数に対応するとき、その終了は、その関数の、呼び出し側関数またはメイン関数への戻り値に対応することができる。

【0043】

「例示的な」かつ/または「例証的な」という語は、本明細書では、例、実例、または例示としての役割を果たすことを意味するために使用される。誤解を避けるために記すと、本明細書において開示する本主題はそのような例によって限定されない。それに加えて、「例示的な」かつ/または「例証的な」として本明細書において説明する任意の態様または設計は、必ずしも他の態様または設計よりも好ましいまたは有利であると解釈すべきであるとは限らず、当業者に知られる等価な例示的な構造および技法を排除するためのものでもない。さらに、「含む(includes)」、「有する(has)」、「含む(contains)」という用語、および他の類似の語が、発明を実施するための形態または特許請求の範囲において使用される限りにおいて、そのような用語は、任意の追加の要素または他の要素を排除することなく、オープンな移行語としての「備える(comprising)」という用語と同様に、包括的であることが意図されている。

【0044】

本明細書全体を通して、「1つの実施形態」、または「一実施形態」、または「一実例」、または「1つの実例」と言及される場合、実施形態に関して説明される特定の特徴、構造、または特性が本発明の少なくとも1つの実施形態に含まれることを意味する。したがって、「1つの実施形態では」または「一実施形態では」という句が、本明細書全体を通してさまざまな場所に出現する場合、必ずしも全てが、同じ実施形態に言及しているとは限らない。さらに、特定の特徴、構造、または特性を、1つまたは複数の実施形態において、任意の適切な様式で組み合わせることができる。

【0045】

本明細書において使用される用語は、特定の実施形態について説明するためのものにすぎず、本発明を限定することは意図されていない。本明細書では、単数形「1つの(a)」、「1つの(an)」、および「その(the)」は、文脈上別段明らかに示していない限り、複数形も含むことが意図されている。「備える(comprises)」および/または「備える(comprising)」という用語は、本明細書において使用されるとき、述べられた特徴、整数、ステップ、動作、要素、および/またはコンポーネントの存在を指定するが、1つまたは複数の他の特徴、整数、ステップ、動作、要素、コンポーネント、および/またはそれらのグループの存在または追加を排除しないことがさらに理解されよう。本明細書では、「および/または」という用語は、列挙された関連する項目のうちの1つまたは複数の項目のありとあらゆる組合せを含む。

【0046】

本発明は、O-RANアーキテクチャにおいてSONの命令の第1のセット(交換可能にモビリティ負荷バランシング(MLB)機能と呼ばれる)を実現するための、またそのデータ収集インターワーキング方法を実現するためのシステムを提供する。O-RANアーキテクチャは、ニアリアルタイム無線インテリジェントコントローラ(Near-RT RIC)およびノンリアルタイム無線インテリジェントコントローラ(Non-RT RIC)と呼ばれる少なくとも2つのエンティティを有する。方法はさらに、少なくとも2つのエンティティ間でのMLBおよび関連機能フローの機能分割を可能にすることができる。方法はさらに、gNB(O-RANアーキテクチャでは交換可能にE2ノードと呼ばれる)と、Non-RT RICと、Near-RT RICとの間の可能な分割を含む、MLBの実行の局所性を確実なものにすることができる。方法およびシステムはさらに、Near-RT RICエンティティおよびNon-RT RICエンティティ内でのMLB機能実行を容易にするためのデータ収集を可能にすることができる。

【0047】

図1を参照すると、図1は、本開示の一実施形態による、サービス管理およびオーケストレーション(SMO)システム(110)(または単に本開示のシステム(110)とも呼ばれる)をその中で、またはそれとともに実装することのできる、自己組織化ネットワークの例示的なネットワークアーキテクチャ(100)(ネットワークアーキテクチャ(100)とも呼ばれる)を示す。図示のように、例示的なネットワークアーキテクチャ(100)には、SMOシステム(110)に関連付けられたノンリアルタイム無線インテリジェントコントローラ(Non-RT RIC)(122)、およびSMOシステム(110)に通信可能に結合されたニアリアルタイム無線インテリジェントコントローラ(Near-RT RIC)(124)が、SONのために装備されていてよい。

【0048】

SMOシステム(110)は、複数の第1のコンピューティングデバイス(102-1、102-2、102-3...102-N)(交換可能にユーザ機器(102-1、102-2、102-3...102-N)と呼ばれ、個々にユーザ機器(UE)(124)と呼ばれ、まとめてUE(102)と呼ばれる)に、第2のコンピューティングデバイス(104-1、104-2、...104-N)(交換可能に基地局(104-1、104-2、...104-N)と呼ばれ、個々に基地局(104)と呼ばれ、まとめて基地局(104)と呼ばれる)を通じて通信可能に結合されてよく、SMOシステム(110)はさらに、基地局(104)に、オープン無線アクセスネットワーク無線ユニット(O-RU)(114)を介して動作可能に結合されてよい。SMO(110)はさらに、1つまたは複数の第3のコンピューティングデバイス(106)(交換可能にgNB分散ユニット(DU)またはgNB DU106と呼ばれる)、および1つまたは複数の第4のコンピューティングデバイス(116)(交換可能にgNB制御ユニット(CU)またはgNB CU116と呼ばれる)に通信可能に結合されてよい。1つまたは複数の第4のコンピューティングデバイス(116)は、複数の第5のコンピューティングデバイス(118)(以後交換可能に第1のノード(118)と呼ばれる)に通信可能に結合されてよい。

【0049】

例示的な一実施形態では、第1の、第2の、第3の、第4の、および第5のコンピューティングデバイスは、複数の隣接セル、またはサービングセルに関連してよい。

【0050】

例示的な一実施形態では、サービングセルおよび複数の隣接セルは、複数のCU(116)および複数のDU(106)にわたって広がっていてよい。第1のインターフェース(以後Xnインターフェースとも呼ばれる)を、MLBのためのデータ収集に使用することができる。

【0051】

SMO(110)は、命令の第1のセット(以後交換可能にモビリティ負荷バランシングまたはMLBと呼ばれる)を実行するように構成することができる。MLBは、実行されると、Near-RT RIC(124)に関連付けられた複数の第1の、第2の、第3の、第4の、および第5のコンピューティングデバイスからのデータ取得を管理することができる。一実施形態では、複数の隣接セルが同じNear-RT RIC(124)にわたるとき、Near-RT RIC(124)内でのMLBの実施が、データ収集メカニズムをアーキテクチャ的にカバーすることができる。

【0052】

さらに別の実施形態では、サービングセルおよび隣接セルは、異なるNear-RT RIC下にあってよく、その際、各セルは異なるnear RT RICに関連付けられ、また各セルは異なるCU(116)および異なるO-DU(106)にわたって広がっていてよい。Xnインターフェースはこの場合、データを収集するために使用することはできない。

【0053】

一実施形態では、SMOシステム(110)とNear-RT RIC(124)を、そのようなものに限定はしないがシステムオンチップ(SoC)システムとすることができる。別の実施形態では、オンサイトのデータ取り込み、記憶、照合、処理、意思決定、およびアクチュエーションの論理を、それに限定はしないがマイクロサービスアーキテクチャ(MSA)を使用してコード化することができる。移植性をサポートするために、複数のマイクロサービスをコンテナ化することができ、イベントベースとすることができる。

【0054】

一実施形態では、ネットワークアーキテクチャ(100)は、SMOシステム(110)およびNear-RT RIC(124)のどんな類の変化にも対応するために、モジュール式で柔軟性のあるものとすることができる。SMOシステム(110)およびNear-RT RIC(124)の構成の詳細は、オンザフライで修正することができる。

【0055】

一実施形態では、SMOシステム(110)をリモートでモニタリングすることができ、SMOシステム(110)のデータ、アプリケーション、および物理的セキュリティを、十分に確保することができる。一実施形態では、データを精細に収集し、クラウドベースのデータレイク内に置いて、実施可能な知見(actionable insight)を抽出するように処理することができる。したがって、予知保全の態様を達成することができる。

【0056】

さらに別の実施形態では、MLBを、Near-RT RICとNon-RT RICとの間で分割することができ、SMOは、MLB SON機能サポートにとって重要な役割を果たすことができる。

【0057】

さらに別の実施形態では、MLBを、オープンな第2のインターフェース(以後交換可能にO1インターフェースと呼ばれる)にわたってSMOとgNBノード(図1には図示しておらず、以後交換可能にE2ノードと呼ばれる)との間で分割することができる。

【0058】

例示的な一実施形態では、通信ネットワーク(108)は、限定ではなく例として、1つまたは複数のメッセージ、パケット、信号、波、電圧レベルまたは電流レベル、それらの何らかの組合せなどを送信し、受信し、転送し、生成し、バッファリングし、記憶し、経路指定し、切り替え、処理し、またはそれらの組合せなどをする1つまたは複数のノードを有する、1つまたは複数のネットワークの少なくとも一部分を含むことができる。ネットワークは、限定ではなく例として、ワイヤレスネットワーク、有線ネットワーク、インターネット、イントラネット、公衆網、私設網、パケット交換網、回路交換網、アドホックネットワーク、インフラストラクチャネットワーク、公衆交換電話網(PSTN)、ケーブルネットワーク、セルラーネットワーク、衛星ネットワーク、光ファイバネットワーク、それらの何らかの組合せのうちの1つまたは複数を含むことができる。

【0059】

別の例示的な実施形態では、アーキテクチャ(100)内に集中型サーバ(112)を含めることができる。集中型サーバ(112)は、限定ではなく例として、スタンドアロンサーバ、サーバブレード、サーバラック、サーババンク、サーバファーム、クラウドサービスまたはクラウドシステムの一部をサポートするハードウェア、ホームサーバ、仮想化されたサーバを実行するハードウェア、コードを実行してサーバとして機能する1つまたは複数のプロセッサ、本明細書において説明するサーバ側機能を実施する1つまたは複数のマシン、上記のいずれかの少なくとも一部分、それらの何らかの組合せのうちの1つまたは複数を、含むまたは備えることができる。

【0060】

一実施形態では、1つまたは複数の第1のコンピューティングデバイス(124)、1つまたは複数のモバイルデバイス(図1に図示せず)はSMOシステム(108)と、限定はしないが、Android(商標)、iOS(商標)、Kai OS(商標)などを含む任意のオペレーティングシステム上に常駐する実行可能命令のセットを介して通信することができる。一実施形態では、1つまたは複数の第1のコンピューティングデバイス(124)および1つまたは複数のモバイルデバイスは、限定はしないが、任意の電気機器、電子機器、電気機械機器、またはモバイル電話、スマートフォン、仮想現実(VR)デバイス、拡張現実(AR)デバイス、ラップトップ機、汎用コンピュータ、デスクトップ機、パーソナルデジタルアシスタント、タブレットコンピュータ、メインフレームコンピュータ、もしくは他の任意のコンピューティングデバイスなど、上記のデバイスのうちの1つもしくは複数のデバイスの組合せを含むことができ、ここで、コンピューティングデバイスは、限定はしないが、カメラなどの視覚補助デバイス、聴覚補助器具(audio aid)、マイクロホン、キーボード、ユーザからの入力を受けるための、タッチパッド、タッチ対応スクリーン、電子ペンなどの入力デバイス、任意の周波数範囲内の任意の聴覚信号(audio signal)または視覚信号を受信するための受信デバイス、および任意の周波数範囲内の任意の聴覚信号または視覚信号を送信することのできる送信デバイスを含む、1つまたは複数の内蔵のまたは外部から結合されたアクセサリを含むことができる。1つまたは複数の第1のコンピューティングデバイス(124)、および1つまたは複数のモバイルデバイスが、言及したデバイスに限定され得ないこと、およびさまざまな他のデバイスを使用できることが、理解できよう。スマートコンピューティングデバイスが、データおよび他のプライベート情報/機密情報を記憶するのに適切なシステムのうちの1つとなり得る。

【0061】

図3は、本開示の一実施形態による、システムアーキテクチャの例示的なブロック図表現(300)を示す。図示のように、一態様(ユースケース-1またはオプション1とも呼ばれる)では、サービングセル(304-1)および複数の隣接セル(304-m、304-m2、304-p2、304-q1)が、同じNear-RT RIC(302)の下にある。サービングセル(304-1)および複数の隣接セル(304-m、304-m2、304-p2、304-q1)は、異なるO-CU-CP(308-1、308-2、308-n)および異なるO-DU(314-1、314-2、...314-n)にわたって広がっていてよい。MLBサポートのための負荷情報収集にXnインターフェースを使用することはできない。例えば、セル-1(301-1)を、上しきい値[Th-U]を上回る負荷がかかっているサービングセルとする。複数の隣接セルのサブセットを、下しきい値[Th-L]を下回るセル負荷を有すると仮定することができ、これらの隣接セルは、オフロードする対象の候補セルである。

【0062】

図4は、本開示の一実施形態による、サービングセルについての負荷情報を関連するE2ノードから収集するための暫定定シーケンスフローをハイライトした例示的なMLB xApp[UC-1]表現(400)を示す。図示のように、Near-RT RIC(406)におけるセルコンテキスト作成のための暫定的シーケンスフロー、ここで、セル-1が正常にコミッションされてよい(408)。当該セルは、関連するE2ノードにE2インターフェースを介してリソースステータス要求(414)をトリガすることによって、それらのE2ノードから負荷情報を収集することができる。E2ノードは、測定(422)を実施することができ、測定された負荷情報(424)を、構成された周期に基づいて、E2インターフェースを介してNear-RT RIC(406)にレポートすることができる。

【0063】

一実施形態では、セルは、配備されコミッションされると(408)、Near-RT RIC[RIC](406)とのE2リンクを確立することができる(410)。RIC(406)は、当該セルについてのセルコンテキストを作成することができる(412)。次に、RIC(406)は、このセルについての測定を開始し(418)かつ周期的なレポートを開始するために、RIC Subscription Request(414)をO-CU-CP-1(404)に送信することができる。次に、O-CU-CP-1(404)は、F1AP Resource Status Initiation手順(424)を介して、当該セルについてのO-DU-1(402)内での測定(422)を構成することができる。さらに、O-DU-1(402)は、当該セルについての測定を開始し(422)、O-CU-CPに、構成された周期で、Radio Resource status(RR)、Composite Available Capacity Group(CACG)、Slice Available Capacity(SliAC)、アクティブUEの数などについてレポートを開始することができる(424)。さらに、O-CU-CP-1(404)は、リソースステータス更新(resource status update)(426および428)をRRC接続数(430および434)とともにNear-RT RIC(406)に転送する。次に、Near-RT RIC(406)は、全てのリソースステータス更新(426および428)をチェックし、リソースステータス更新(426および428)を当該セルに対して記憶する。この手順シーケンスは、Near-RT RIC(406)の下でコミッションされ得るあらゆるセルについてなぞられてよい。

【0064】

図5は、本開示の一実施形態による、関連するE2ノードから受信したサービングセルについての負荷情報に対して処理するためのフローをハイライトした、例示的なMLB xApp[UC-1]表現(500)を示す。図示のように、受信したセル負荷情報を処理するための暫定的シーケンスフローが示されており、このフローは、負荷状況によりUEを選択された隣接セルに対してオフロードするように求められる場合、必要なステップをさらに必要とする。

【0065】

一実施形態では、Near-RT RIC(508)においてRIC Indication(510)が受信され得るとき、かつ何らかの持続時間「T1」にわたってセル負荷が>Th-Uである場合、セルは、その負荷の一部を複数の隣接セルに対してオフロードすることを決定することができる(512)。次に、Near-RT RIC(508)は、ローカルのANR xAppから、負荷がかかっているセルの複数の隣接セルのリストを収集することができる(514)。複数の隣接セルのリストから、サービングセルと複数の隣接セルはどちらも、同じNear-RT RIC(508)に属しているように見えてよい(516)。さらに、Near-RT RIC(508)は、複数の隣接セルのこのリストについての負荷情報を、MLB xApp内の該当するセルコンテキストから収集することができる(518)。さらに、Near-RT RIC(508)は、負荷情報を解析し、何らかの持続時間「T」にわたってそのセル負荷が<Th-Lであるセルのサブセットを識別することができる(520)。何らかの持続時間「T」にわたってそのセル負荷が<Th-Lであるセルは、オフロードの候補セルとなることができる。

【0066】

さらに、Near-RT RIC(508)は、可能なAI/MLアルゴリズムに基づいて、サブセットセルにとって適切なHOトリガパラメータの値を動的に選択することができる(522)。この場合、MLB xAppはMRO xAppと協調して、適切なHOトリガパラメータを決定することができる。Near-RT RIC(508)はE2インターフェースを介してO-CU-CP-1(506)に、RIC Subscription Request(524)を介して、修正されたHOトリガ値の使用を開始せよと要求することができる。O-CU-CP-1(506)は、これらのセルのUE(502)を、新たな測定構成を用いて再構成することができる(528)。その結果、負荷がかかっているセル内のUE(502)は、早期測定レポートを送出して、複数の隣接セルに対するHOをトリガすることができる。したがって、複数の隣接セルに対してHOがトリガされることが可能となり、それにより、サービングセルの負荷が低減し得る(530)。

【0067】

図6は、本開示の一実施形態による、MLBオフロード後に通常状態に復帰するための暫定的シーケンスフローの例示的なMLB xApp[UC-1]表現(600)を示す。正常なMLBオフロード後に当該セルの通常動作状態に復帰するための暫定的シーケンスフローについて、本明細書により説明する。隣接セルに対してハンドオーバが生じつつある限り、当該セルにかかる負荷は低減され始めることが可能である。何らかの持続時間「T」にわたってサービングセルの負荷が<平均負荷であるとき、Near-RT RIC(608)は、それらのセルについてのHOトリガパラメータに対して行った変更を元に戻すことを決定することができる(610)。

【0068】

Near-RT RIC(608)は、AI/MLに基づいて、隣接セルおよびサービングセルにとって適切なHOトリガパラメータの値を動的に選択することができる(612)。この場合、MLB xAppは、必要ならMRO xAppと協調して、適切なHOトリガパラメータを決定することができる。Near-RT RIC(608)はE2インターフェースを介してO-CU-CP-1(606)に、RIC Subscription Request(614)を介して、修正されたHOトリガ値の使用を開始せよと要求することができる。O-CU-CP-1(606)は、これらのセルのUE(602)を、新たな測定構成を用いて再構成することができ(618)、動作は通常に移行し始める。

【0069】

図7は、本開示の一実施形態による、O-RANアーキテクチャと統合したMLBのための代替配備シナリオ表現(700)の一例示実施形態である。図示のように、この配備シナリオは、代替実施形態(ユースケース2(UC-2)またはオプション2でもある)をハイライトするものである。図示のように、サービングセル(304-1)および複数の隣接セル(304-m、304-m2、304-p2、304-q1)は、異なるNear-RT RICエンティティ(302-1および302-2)の下にあってよい。図7に示すように、サービングセル(304-1)および複数の隣接セル(304-m、304-m2、304-p2、304-q1)は、異なるO-CU-CP(308-1および308-n)ならびに異なるO-DU(314-1)にわたって広がっていてよい。この場合は、Xnインターフェースを使用して、MLBサポートに必要となる、異なるNear-RT RICエンティティ(302-1および302-2)の下にある複数の隣接セル(304-m、304-m2、304-p2、304-q1)についての負荷情報を収集することができる。セル-1が、上しきい値[Th-U]を上回る負荷がかかっているサービングセルである。セル-1の複数の隣接セルは、ANRテーブルに従って影付きボックスによって識別されてよい。複数の隣接セルのサブセットを、下しきい値[Th-L]を下回るセル負荷を有すると仮定することができ、このサブセットを、オフロードする対象の候補セルとすることができる。

【0070】

図8は、本開示の一実施形態による、Xnインターフェースにわたる負荷情報収集を構成するための暫定的シーケンスフローの例示的なMLB xApp[UC-2]表現(800)を示す。この暫定的シーケンスフローは、複数のNear-RT RICにわたって広がっていてよい関連するE2ノードにE2インターフェースを介してリソースステータス要求をトリガすることによってそれらのE2ノードから負荷情報を収集する様子を示す。例示的な一実施形態では、E2ノードは、Xnインターフェースを使用して、負荷情報を要求およびフェッチすることができる。E2ノードは、測定を実施することができ、測定された負荷情報を、本明細書により説明する方法で構成された周期に基づいて、Xnインターフェースを介して要求側E2ノードにレポートすることができる。Near-RT RIC(808)が、同じRICに属する複数の隣接セルについての負荷情報をMLB xApp内でローカルに収集することができる(810)。異なるNear-RT RICに属する複数の隣接セルについては、Near-RT RIC(808)はO-CU-CP-1(806)に、負荷情報を収集せよと要求することができる(814)。次いで、O-CU-CP-1(806)は、別のRICに属するO-CU-CP-n(836)に、XnAP Resource Status Initiation手順(818)を介して、セルのリストについての負荷情報を提供せよと要求することができる(816)。O-CU-CP-n(836)は、F1AP Resource Status Initiation手順(826)を介して、O-DU(804)からそれらの全てのセルについての負荷情報を収集し始めることができる。

【0071】

図9は、本開示の一実施形態による、Xnインターフェースにわたる受信した負荷情報の収集および後処理のための暫定的シーケンスフローの例示的なMLB xApp[UC-2]表現(900)を示す。O-CU-CP-n(910)によってそれらのそれぞれのO-DU(904)から負荷情報を収集し、リソースステータスを転送するためのこの暫定的シーケンスは、構成された周期による要求側O-CU-CP-1(906)へのレポートと、要求側O-CU-CP-1(906)が次にそれらのレポートをNear-RT RIC(908)に転送する様子を示す。Near-RT RIC(908)は、受信した負荷情報を、ローカルに収集した負荷情報とともに処理し、本明細書により説明したユースケース1実施形態において説明したのと同様の方法で、必要なアクションをとることができる。O-CU-CP-n(910)がO-DU(904)からF1AP Resource Status Reporting手順(922)を介して負荷情報を受信し始めることができるとき、O-CU-CP-n(910)は、F1AP: Resource Status Updateレポート(922)をXnAP Resource Status Reporting手順(924)を介してO-CU-CP-1(906)に転送することができる。

【0072】

サービングセルの負荷状態がオフロードの基準を満たし得るとき、ユースケース-1シナリオにおいて述べたように、Near-RT RIC(908)は、AI/MLに基づいて、複数の隣接セルのそれぞれにとって適切なHOトリガパラメータの値を動的に選択することができる。Near-RT RIC(908)はO-CU-CP-1(906)に、複数の隣接セルについての修正されたHOトリガ値の使用を開始せよと要求することができる。O-CU-CP-1(906)は、Near-RT RIC(908)に属するセルのUE(902)を、新たな測定構成を用いて再構成することができる(928)。

【0073】

異なるNear-RT RICに属するセルについては、O-CP-CU-1(906)は、修正されたHOトリガ値をXnAP Mobility Settings Change手順(930)を介してO-CU-CP-n(910)に転送することができる。O-CU-CP-n(910)は、Near-RT RIC(908)に属するセルの全てのUE(902)を、新たな測定構成を用いて再構成することができる(928)。残りの手順は、先の実施形態においてユースケース-1について説明したのと変わらない。

【0074】

図10は、本開示の一実施形態による、Non-RT RICにおけるMLBサポートについての機能ブロック図の一例示実施形態(1000)である。図示のように、E2ノード(1022)は、測定を実施し、PMデータを取り込み、それをローカルに記憶することができる。PMデータレポーティング構成(T)に基づいて、E2ノード(1022)は、PMデータ、イベント/アラーム、ログなどを、O1インターフェースを介してSMO(1002)にレポートすることができる。

【0075】

限定ではなく例として、レポーティング構成は、例えばT[5分、10分、15分、20分、25分、30分、45分、60分、90分など]とすることができる。

【0076】

例示的な一実施形態では、SMO(1002)内のEMS(1012)が、データをMDAS(1006)およびNMS(1004)に内部的に転送することができる。MDAS(1006)は、データを記憶し、そのストレージ内にその時までに蓄積されたデータ全体を考慮したビッグデータ解析を実行することができる。さらに、MDAS(1006)は、当該の各セルについて、関連する負荷パターンを生成することができる。データの蓄積量は、数日または数カ月または数年のデータとして想定することができる。データ蓄積持続時間が大きくなることが可能なので、生成されたパターンの精度および現実性との近さもまた非常に高くなることが可能である。負荷パターン、持続時間パターンなどのような、生成されたパターンは、Non-RT RIC(1008)と共有することができる。

【0077】

Non-RT RIC[rApp](1008)は、パターンを解析し、特定のピークセル負荷パターンおよび特定の低セル負荷パターンが、周期的となり得るかそれとも非周期的となり得るか、そのようなパターンの持続時間、およびそのようなパターンの将来的な発生の可能性を得ようと試みることができる。Non-RT RIC[rApp](1008)はまた、複数の隣接セルについての同様のパターンも解析することができる。この解析から、Non-RT RIC(1008)は、セルのピーク負荷の次の直近の発生とその持続時間を予測することができ、またその持続時間について、Non-RT RIC(1008)は、全ての隣接セルの振る舞いを分析することもできる。さらに、Non-RT RIC(1008)は、オフロードの候補隣接セルとすることのできる確実な(sure-shot)隣接セルのサブセットを最終選考することができる。予測された負荷状態、予測された発生の持続時間、オフロードのための隣接セルの暫定リストなどは、第3のインターフェース(以後A1インターフェースとも呼ばれる)にわたってNear-RT RIC(1014)と共有することができる。

【0078】

図11は、本開示の一実施形態による、MLBサポートについてのさまざまなO-RANエンティティにわたるデータのシーケンスフローの例示的な表現(1100)を示す。図示のように、一態様では、Non-RT RIC(1106)が、予測されたデータを使用して、Near-RT RIC(1108)をそれに応じてガイドすることができる。例えば、予測された負荷が、構成されたある持続時間にわたって低いとき、Non-RT RIC(1106)は、その構成された持続時間に適用可能な、キャリアアグリゲーションの使用を低減させること、デュアルコネクティビティの使用を低減させること、動作帯域幅を低減させること、MIMO構成を可能な限り最小限に低減させること、より低い変調クラスに切り替えること、より多くの到来するハンドオーバを引き寄せられるようにすることなどを行うように、Near-RT RIC(1108)をガイドすることができる。同様に、予測された負荷が、特定の持続時間にわたって非常に高いとき、Non-RT RIC(1106)は、上の前記機能を適宜可能な限り最大限に使用できるようにする態勢が整うように、Near-RT RIC(1108)をガイドすることができる。具体的には、Non-RT RIC(1106)は、ポリシーの形をとるガイダンスを提供することができ、一方Near-RT RIC(1108)は、受信したガイダンスおよびそれ自体のリアルタイム解析に基づいて、現在の状況を評価することができ、それに応じて決定を行う。

【0079】

図12は、本開示の一実施形態による、SMO(1002)およびE2ノード(1022)のみにわたるMLBサポートについての機能アーキテクチャの一例示実施形態表現(1200)である。図示のように、一態様では、MLB機能が、オープンO1インターフェース(1018)にわたってSMO(1002)とE2ノード(1022)との間で分割される。例示的な一実施形態では、管理エンティティ[例えばEMSコンテキスト(1012)]におけるMLBコントローラ(1204)およびE2ノード(1022)におけるMLBエージェント(1202)。

【0080】

Non-RT RICにおけるMLB rApp(1010)の機能は、得られたMLBポリシーをMLB rApp(1010)がMLBコントローラ(1204)にローカルに提供できることを除き、先の実施形態において説明したのと同じである。管理エンティティ(1012)におけるMLBコントローラ(1204)は、E2ノード(1022)から受信したPMデータに対して直接、データ解析を行い、負荷バランシングの適切な決定を行うことができる。MLBコントローラ(1204)は、蓄積されたPMデータに対してMDAS(1006)によって生成された負荷/時間パターンを利用して、MLB決定を行うこともできる。MLBエージェント(1202)は、MLBコントローラ(1204)からオープンO1インターフェース(1018)にわたって受信したMLB決定/コマンドを実行することができる。

【0081】

MLBエージェント(1202)は、E2ノード(1022)内でnear-RT PMデータにローカルにアクセスし、それに対してリアルタイム解析を実施することができ、負荷バランシングに関する決定をローカルに行うことができる。MLB決定は、MLBコントローラ(1204)から受信した決定/コマンドと整合していてよい。MLBエージェント(1202)は、E2ノード(1022)に固有であってよく、かつ実装固有であってよい。しかし、オープンO1インターフェース(1018)にわたって受信したMLBガイドラインに準拠することにより、MLB機能が引き続きベンダ非依存になることが可能である。

【0082】

図13は、本開示の一実施形態による、SMO(1002)およびE2ノード(1022)のみにわたりNon-RT RICを除外したMLBサポートについての機能アーキテクチャの一例示表現(1300)である。図示のように、一態様では、Non-RT RICには、MLB機能に関して果たすべきどんな役割もなく、MLBコントローラ(1204)自体が、先の実施形態の下でNon-RT RIC内のMLB rAppについて説明した全ての機能を引き受ける。残りの機能は、上で説明したのと同様である。

【0083】

図14は、本開示の実施形態による、本発明の実施形態をその中で、またはそれとともに利用することのできる、例示的なコンピュータシステム(1400)を示す。図14に示すように、コンピュータシステム(1400)は、外部ストレージデバイス(1410)、バス(1420)、主メモリ(1430)、読出し専用メモリ(1440)、大容量ストレージデバイス(1450)、通信ポート(1460)、およびプロセッサ(1470)を含むことができる。コンピュータシステムは2つ以上のプロセッサおよび通信ポートを含むことができることを、当業者なら理解するであろう。プロセッサ(1470)の例としては、限定はしないが、Intel(登録商標) Itanium(登録商標)もしくはItanium 2プロセッサ、またはAMD(登録商標) Opteron(登録商標)もしくはAthlon MP(登録商標)プロセッサ、Motorola(登録商標)プロセッサ系列、FortiSOC(商標)システムオンチッププロセッサ、あるいは他の将来的なプロセッサがある。

【0084】

プロセッサ(1470)は、本発明の実施形態に関連するさまざまなモジュールを含むことができる。通信ポート(1460)は、モデムベースのダイヤルアップ接続で使用するRS-232ポート、10/100イーサネットポート、銅もしくはファイバを使用した1ギガビットもしくは10ギガビットポート、シリアルポート、パラレルポート、または他の既存のもしくは将来的なポートのいずれかとすることができる。通信ポート(1460)は、ローカルエリアネットワーク(LAN)、広域ネットワーク(WAN)、またはこのコンピュータシステムが接続する任意のネットワークなどのネットワークに応じて選択することができる。メモリ(1430)は、ランダムアクセスメモリ(RAM)、または当技術分野において一般に知られる他の任意のダイナミックストレージデバイスとすることができる。読出し専用メモリ(1440)は、任意のスタティックストレージデバイス、例えば、限定はしないが、スタティック情報、例えばプロセッサ(1470)用の起動命令またはBIOS命令を記憶するためのプログラマブル読出し専用メモリ(PROM)チップとすることができる。

【0085】

大容量ストレージ(1450)は、情報および/または命令を記憶するために使用することのできる、任意の現在のまたは将来的な大容量ストレージソリューションとすることができる。例示的な大容量ストレージソリューションとしては、限定はしないが、(内蔵の、または外付けの、例えばユニバーサルシリアルバス(USB)インターフェースおよび/またはファイアワイヤインターフェースを有する)パラレルアドバンストテクノロジアタッチメント(PATA)またはシリアルアドバンストテクノロジアタッチメント(SATA)のハードディスクドライブまたはソリッドステートドライブ、例えばSeagateから入手可能なもの(例えばSeagate Barracuda 782ファミリ)またはHitachiから入手可能なもの(例えばHitachi Deskstar 13K800)、1つまたは複数の光学ディスク、リダンダントアレイオブインディペンデントディスクス(RAID)ストレージ、例えばさまざまなベンダから入手可能なディスクのアレイ(例えばSATAアレイ)がある。

【0086】

バス(1420)は、プロセッサ(1470)を他のメモリブロック、ストレージブロック、および通信ブロックと通信可能に結合する。バス(1420)は、例えば、拡張カード、ドライブ、および他のサブシステムを接続するためのペリフェラルコンポーネントインターコネクト(PCI)/PCI拡張(PCI-X)バス、小型コンピュータシステムインターフェース(SCSI)、USBなど、ならびにプロセッサ(1470)をソフトウェアシステムに接続するフロントサイドバス(FSB)などの他のバスとすることができる。

【0087】

任意選択で、コンピュータシステムとの直接的なオペレータ対話をサポートするために、オペレータインターフェースおよび管理用インターフェース、例えば、ディスプレイ、キーボード、およびカーソル制御デバイスをバス(1420)に結合することもできる。通信ポート(1460)を通じて接続されたネットワーク接続を通じて、他のオペレータインターフェースおよび管理用インターフェースを提供することができる。外部ストレージデバイス(1410)は、任意の種類の外付けのハードドライブ、フロッピードライブ、IOMEGA(登録商標) Zipドライブ、コンパクトディスク-読出し専用メモリ(CD-ROM)、コンパクトディスク-リライタブル(CD-RW)、デジタルビデオディスク-読出し専用メモリ(DVD-ROM)とすることができる。上述したコンポーネントは、さまざまな可能性を例示するためのものにすぎない。前述の例示的なコンピュータシステムは、本開示の範囲を決して限定すべきではない。

【0088】

以上、本明細書において好ましい実施形態に大きな重点を置いてきたが、多くの実施形態を作成できること、また本発明の原理から逸脱することなく、好ましい実施形態に多くの変更を加えることができることが理解されよう。本発明の好ましい実施形態の上記および他の変更は、本明細書の開示から当業者に明らかとなろう。それにより、前述の説明事項は、限定としてではなく単に本発明の例示として実装されるべきであることを明確に理解されたい。

【0089】

本開示の利点
本開示は、オープン無線アクセスネットワーク(O-RAN)を使用した電気通信ネットワーク内のセルのモビリティ負荷バランシングのためのシステムおよび方法を提供する。

【0090】

本開示は、O-RANアーキテクチャにおいて自己組織化ネットワーク(SON)のモビリティ負荷バランシング(MLB)機能を実現するためのシステムおよび方法を提供する。

【0091】

本開示は、O-RANアーキテクチャにおけるさまざまなエンティティ間での機能分割、および関連するデータ/制御フローメカニズムのための、システムおよび方法を提供する。

【0092】

本開示は、Near RT RICエンティティ、Non-RT RICエンティティ内でのMLBの実施や、管理エンティティおよびNear RT RIC内でのMLBの実施など、O-RANアーキテクチャにおいてMLB機能を実現するための2つのメカニズムのシステムおよび方法を提供する。

【0093】

本開示は、Near-RT RICエンティティおよびNon-RT RICエンティティ内でのMLB機能実行を容易にするためのデータを収集するシステムおよび方法を提供する。

【0094】

本開示は、O-RANアーキテクチャにおいて、電気通信ネットワーク内でセルを隣接セルにオフロードし、それにより、ネットワーク効率を向上させるシステムおよび方法を提供する。

【0095】

権利の留保
本特許文献の開示の一部は、限定はしないが、Jio Platforms Limited(JPL)またはその関連会社(以後所有者と呼ばれる)に属する著作権、意匠、商標、ICレイアウト設計、および/またはトレードドレス保護などの知的財産権の対象となる事項を含む。所有者は、特許商標庁の特許ファイルまたは記録に現れるとおりの、本特許文献または本特許開示の何人による複製にも異議はないが、そうでない場合は、全ての権利を何であれ留保する。そのような知的財産に対するあらゆる権利は、所有者によって完全に留保される。本開示は、3GPP(登録商標) TR 21.905[1]内に与えられるO-RAN仕様に関連することがある。

【符号の説明】

【0096】

100 自己組織化ネットワークの例示的なネットワークアーキテクチャ
102 UE
102-1 第1のコンピューティングデバイス、ユーザ機器
102-2 第1のコンピューティングデバイス、ユーザ機器
102-3 第1のコンピューティングデバイス、ユーザ機器
102-N 第1のコンピューティングデバイス、ユーザ機器
104 基地局
104-1 第2のコンピューティングデバイス、基地局
104-2 第2のコンピューティングデバイス、基地局
104-N 第2のコンピューティングデバイス、基地局
106 NMS、第3のコンピューティングデバイス、gNB分散ユニット(DU)、gNB DU、O-DU
108 通信ネットワーク、SMOシステム
110 サービス管理およびオーケストレーション(SMO)システム、SMO
112 集中型サーバ
114 オープン無線アクセスネットワーク無線ユニット(O-RU)
116 gNB-CU-1、隣接gNB-CU、第4のコンピューティングデバイス、gNB制御ユニット(CU)、gNB CU
118 gNB-DU、第5のコンピューティングデバイス、第1のノード
120 gNB-DU
122 gNB-DU、ノンリアルタイム無線インテリジェントコントローラ(Non-RT RIC)
124 gNB-CU-2、隣接gNB-CU、ニアリアルタイム無線インテリジェントコントローラ(Near-RT RIC)、ユーザ機器(UE)、第1のコンピューティングデバイス
200 表現
220 表現
224 ニアリアルタイム(RT)RANインテリジェントコントローラ(RIC)
228 O-RAN集約ユニット制御プレーン(O-CU-CP)
230 O-RAN集約ユニット-ユーザプレーン(O-CU-UP)
232-1 O-RAN分散ユニット(O-DU)
232-2 O-RAN無線ユニット(O-RU)
234 ORAN-Cloud(O-Cloud)
236 オープンフロントホールM-プレーン
300 ブロック図表現
302 Near-RT RIC
302-1 Near-RT RICエンティティ
302-2 Near-RT RICエンティティ
304-1 サービングセル
304-m 隣接セル
304-m2 隣接セル
304-p2 隣接セル
304-q1 隣接セル
308-1 O-CU-CP
308-2 O-CU-CP
308-n O-CU-CP
314-1 O-DU
314-2 O-DU
314-n O-DU
400 MLB xApp[UC-1]表現
402 O-DU-1
404 O-CU-CP-1
406 Near-RT RIC
500 MLB xApp[UC-1]表現
502 UE
506 O-CU-CP-1
508 Near-RT RIC
600 MLB xApp[UC-1]表現
602 UE
606 O-CU-CP-1
608 Near-RT RIC
700 一例示実施形態、代替配備シナリオ表現
800 MLB xApp[UC-2]表現
804 O-DU
806 O-CU-CP-1
808 Near-RT RIC
836 O-CU-CP-n
900 MLB xApp[UC-2]表現
902 UE
904 O-DU
906 要求側O-CU-CP-1
908 Near-RT RIC
910 O-CU-CP-n
1000 機能ブロック図、一例示実施形態
1002 SMO
1004 NMS
1006 MDAS
1008 Non-RT RIC、Non-RT RIC[rApp]
1010 MLB rApp
1012 EMS、EMSコンテキスト、管理エンティティ
1014 Near-RT RIC
1018 オープンO1インターフェース
1022 E2ノード
1100 表現
1106 Non-RT RIC
1108 Near-RT RIC
1200 一例示実施形態、一例示実施形態表現
1202 MLBエージェント
1204 MLBコントローラ
1300 一例示実施形態、一例示表現
1400 コンピュータシステム
1410 外部ストレージデバイス
1420 バス
1430 主メモリ
1440 読出し専用メモリ
1450 大容量ストレージデバイス、大容量ストレージ
1460 通信ポート
1470 プロセッサ

【図1】

【図2A】

【図2B】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【国際調査報告】