JP6027130B2 - ベースバンド信号処理クラスタ - Google Patents

Description

本発明の実施形態は、一般的にワイヤレス通信に関し、より具体的には、無線アクセス・ネットワークにおける分散された負荷バランシングまたはベースバンド・リソースの分散に関する。

モバイル・サービスにおいて、より高いデータ転送速度に対する需要が着実に増加している。同時に、第３世代（３Ｇ）システムおよび第４世代（４Ｇ）システムなど現在の移動通信システムは、より高いスペクトルの効率を実現し、より高いデータ転送速度およびセル容量を可能にする拡張された技術を提供する。変化が増えつつある高速サービスに対する需要がセル容量より速く増大しているため、オペレータは、ネットワーク内のセルの数を増加させることを促される。つまり、基地局の密度が高くなる。基地局送受信装置は、移動通信システムまたはネットワークの全体的な電力消費に大きな影響を与えており、それと同時に、オペレータが直面する運用経費（ＯＰＥＸ）にも大きな影響を与えている。１つの省電力戦略としては、基地局送受信装置から処理容量を取り除き、複数の基地局送受信装置のために処理機能を提供する集中処理ユニットに移すことである。基地局送受信装置の処理装置は、基地局送受信装置の合計電力のかなりの部分を消費するが、基地局送受信装置の処理機能は、高負荷条件のみで完全に利用される。それは永続的に発生するものではなく、ピーク時だけのものである。無線アクセス・システムにおける異なるセルは、時間の経過に伴うそれらのトラフィック負荷に関して、相互に非常に不均一である。これが意味するのは、セルのクラスタにおいて、異なるセルはピーク最繁時が同時ではないということである。

現在、モバイル・ネットワークの無線アクセス（ＲＡＮ）では、たとえば、最新技術であるＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）に関して、たとえばｅＮｏｄｅＢなどの基地局または基地局送受信装置を使用して、すべての無線ベースバンドおよび制御機能に対応している。

したがって、全体的なＲＡＮの資本的支出（ＣＡＰＥＸ）およびＯＰＥＸの多くは、たとえば、サイトの賃貸料、インフラストラクチャ、処理ハードウェア、メンテナンスなど、各サイトの個々の処理ユニットの影響を受ける。これらのコスト要素の少なくとも大部分を削減するために、複数の手法が最近の研究活動の対象になっている。一部のソリューションでは、放射される電力および処理の複雑性を減らし、それと同時に必要な量を減らすが、これらのソリューションでは、必要なサイトの数を増やすという犠牲がある。

無線フロントエンドから処理機能を取り除き、処理機能としてクラウド・コンピューティングまたは負荷分散された処理ユニットを使用することによって、無線アクセス・ネットワークのコスト効率を改善できることは本発明の発見の１つである。そのような処理機能は、多くの無線フロントエンドに割り当てることができ、それによって、全体的な処理機能をより効率的に利用することができる。したがって、実施形態は、より少ない全体的な処理容量を用いる概念を提供することができ、それと同時に、移動通信システムの全体的な電力消費、ＯＰＥＸ、およびＣＡＰＥＸを減らすことができる。

クラウド・コンピューティングは、プールとして大規模な設置されたリソースを共有して使用することによって運用コストを下げることができる。さらに、ハードウェアの拡張効果（ｓｃａｌｉｎｇ ｅｆｆｅｃｔ）ならびに高価な周辺装置およびハードウェアに対する（ユーザごとの）要件の低下によって、設置コストを下げることができる。設置された処理リソースの高度な負荷分散によって、屋内（企業または住居）または屋外の用途のために時間の経過とともに異なる負荷プロファイルを考慮することで、サイトおよび必要なハードウェアの大幅な減少を達成することができる。これは、オペレータにとってＯＰＥＸおよびＣＡＰＥＸの削減につながる。負荷バランシング／処理リソースの分散に加えて、本発明の実施形態は、また、一般的な負荷管理の状況において、低トラフィック領域から高トラフィック領域に処理リソースを割り当てることを可能にすることができる。

個々の処理要素が、所定の時に１つの無線標準または無線アクセス技術（ＲＡＴ）しか運用できない場合でも、ソフトウェア（ＳＷ）の交換によって半静的な方法で、複数標準の構成を調整できることはもう１つの発見である。これにより、オペレータは、ハードウェア（ＨＷ）を変更する必要なく、複数標準のシステムをより柔軟に展開することができる。

よって、本発明の実施形態は、クラウド・コンピューティング要素を統合する非集中化された負荷バランシング／分散手法を提供することによって、次世代のモバイル無線アクセス・ネットワーク（ＲＡＮ）のために現在のＲＡＮアーキテクチャを更新することを目的としている。

実施形態では、ＲＡＮアーキテクチャは、無線フロントエンドと見なすことができる、つまり実際の無線信号を受信して送信し、少なくとも１つの無線セルを確立する、リモート・ラジオ・ヘッド（ＲＲＨ）から構成することができる。以下において、２方向の送信が考えられる。第１の方向は、ダウンリンクまたは順方向リンクと呼ばれる。これは、ＲＡＮ、つまりＲＲＨから通信領域内のモバイル端末またはユーザ機器（ＵＥ）への送信を表す。第２の方向は、アップリンクまたは逆方向リンクと呼ばれる。これは、モバイル端末からＲＡＮ、つまりＲＲＨへの送信を表す。アップリンクでは、ＲＲＨは、受信された無線信号を伝送帯域からベースバンド受信信号に変換し、クラウド・コンピューティング・ネットワークの分散された負荷バランシング／分散アーキテクチャにベースバンド受信信号を提供することができる。ダウンリンクでは、ＲＲＨは、クラウド・ネットワークで処理された、ベースバンド送信信号を伝送帯域に変換し、１つまたは複数のアンテナを使用して、信号を送信することができる。

以下において、システム帯域幅および搬送周波数を持つシステム周波数帯域として伝送帯域を表すだろう。伝送帯域は、たとえば、周波数分割双方向（ＦＤＤ）システムのように、無線信号のダウンリンク送信のためのサブバンドおよびアップリンク受信のためのサブバンドを含むことができる。一部の実施形態では、時分割二重通信（ＴＤＤ）システムのように、同じ伝送帯域をダウンリンクおよびアップリンクに使用することができる。

従来のソリューションでは、ベースバンド処理ユニットとＲＲＨとの間に１：１の関係があり、ここでベースバンド処理容量は、ピーク・トラフィックによって分けられる（ｄｉｍｅｎｓｉｏｎ）。一部の実施形態では、ＲＲＨは、送信（Ｔｘ）、受信（Ｒｘ）、およびアンテナの機能を提供することができる。ＲＲＨは、従来のベースバンド処理要素のプールとして、関連するベースバンド処理ユニットまたはベースバンド・ユニット（ＢＢＵ）から空間的に分離できるため、後者は、複数のＢＢＵのＢＢＵ間クラウド・コンピューティング・クラスタ内で組み合わせることができる。これにより、クラウド・コンピューティングの技術を適用し（ＢＢＵ内およびＢＢＵ間）、分散化または非集中化された負荷バランシング／分散を確立し、必要な処理サイトの数と同時に関連する設置コスト、メンテナンスおよび電力消費を直接的に減らすための道が開かれる。

言い換えると、実施形態は、クラウド・コンピューティング・アーキテクチャのノードを形成するＲＲＨおよびベースバンド（信号）処理ユニットを用いるＲＡＮアーキテクチャを提供することができる。そのため、各個々のネットワーク・ノード、つまりＢＢＵは、処理リソース割り当てエンティティを装備するため、ネットワーク・ノードの個々の相互に連結された負荷バランシング／分散エンティティはともに、分散化または非集中化された負荷分散装置を形成し、これは、また、非集中化されたクラウド・コントローラ（ＤＣＣ）と呼ばれる。そのため、ＤＣＣは、クラウド・コンピューティング・ネットワークの他のＤＣＣと協力して、ＲＲＨからネットワークの他のノードまたはＢＢＵに、その関連するＢＢＵによって受信された負荷を分散またはルーティングすることができる。これにより、オペレータにとってトラフィック分散の柔軟性が高まる。

本発明の第１の態様によると、ワイヤレス通信ネットワークのベースバンド信号処理クラスタが提供される。ベースバンド信号処理クラスタは、複数のベースバンド信号処理ユニットを含み、ベースバンド信号処理ユニットの少なくとも１つ（具体的にはそれぞれ）は、ワイヤレス通信ネットワークの少なくとも１つのリモート・ラジオ・ヘッド（ＲＲＨ）に結合される。そのため、ＲＲＨは、ワイヤレス通信ネットワークの少なくとも１つの無線セルにサービスを提供することができる。よって、ベースバンド信号処理クラスタは、ワイヤレス通信ネットワークの第１の無線セル・クラスタに関連させられる。また、ベースバンド信号処理ユニットの少なくとも１つ（具体的にはそれぞれ）は、その関連するベースバンド信号処理ユニット内、またはその（ベースバンド）信号処理リソース割り当てを管理するように動作可能なユニット特有の（信号）処理リソース管理エンティティに結合されるか、またはそれを含む。ベースバンド信号処理クラスタのベースバンド信号処理ユニットは、また、後にベースバンド・ユニット（ＢＢＵ）と呼ぶことができる。そのため、そのようなベースバンド信号処理ユニットは、ワイヤレス通信ネットワークの１人または複数のユーザのベースバンド信号を処理するためにサービスを提供することができる。ベースバンド信号処理クラスタは、少なくとも１つの（具体的にはそれぞれの）ユニット特有の処理リソース管理エンティティに結合され、クラスタの複数のベースバンド信号処理ユニットの間で信号処理リソース割り当てを管理またはバランス／分散するように動作可能であるクラスタ内（信号）処理リソース管理エンティティを含む。クラスタ内処理リソース管理エンティティに、場合によっては信号処理クラスタの（信号）処理負荷を示す情報を交換するように動作可能であるクラスタ間（信号）処理リソース管理エンティティが結合され、リモート処理割り当てを達成または管理するために、少なくとも１つのリモート・ベースバンド信号処理クラスタの少なくとも１つのリモート・クラスタ間処理リソース管理エンティティは、ワイヤレス通信ネットワークの第２の（異なる）無線セル・クラスタに関連する。すなわち、ベースバンド信号処理クラスタの利用可能な処理リソースが、クラスタのユーザに関係する特定のユーザまたはベアラ特有のベースバンド信号処理要求を扱うのに十分でない場合、加えて、または代わりに、リモート・クラスタのリモート・ベースバンド信号処理リソースを割り当てることができる。

本発明の実施形態は、原則的に、様々な現在および将来のワイヤレス通信システムで用いることができる。たとえば、グローバル・システム・フォー・モバイル・コミュニケーションズ（ＧＳＭ）、Ｅｎｈａｎｃｅｄ Ｄａｔａ ｒａｔｅｓ ｆｏｒ ＧＳＭ Ｅｖｏｌｕｔｉｏｎ（ＥＤＧＥ）、ＧＳＭ／ＥＤＧＥ無線アクセス・ネットワーク（ＧＥＲＡＮ）、Ｕｎｉｖｅｒｓａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ（ＵＴＲＡＮ）もしくはＥｖｏｌｖｅｄ ＵＴＲＡＮ（Ｅ−ＵＴＲＡＮ）、Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ（ＬＴＥ）もしくはＬＴＥ−Ａｄｖａｎｃｅｄ（ＬＴＥ−Ａ）、など、３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ（３ＧＰＰ）によって標準化されたワイヤレス通信システム、またはたとえば、ワールドワイド・インターオペラビリティ・フォー・マイクロウェーブ・アクセス（ＷＩＭＡＸ）ＩＥＥＥ８０２．１６もしくはワイヤレス・ローカル・エリア・ネットワーク（ＷＬＡＮ）ＩＥＥＥ８０２．１１、一般的に時分割多元接続（ＴＤＭＡ）に基づく任意のシステム、周波数分割多元接続（ＦＤＭＡ）、直交周波数分割多元接続（ＯＦＤＭＡ）、符号分割多元接続（ＣＤＭＡ）など、異なる標準を用いるワイヤレス通信システムなどである。以下において、ワイヤレス通信システムおよびモバイル通信ネットワークという用語は、同義的に使用することができる。本発明の概念は、前述のワイヤレス通信システムに限定されず、将来的なワイヤレス通信システム標準だけでなく他のものに適用可能であることに注意されたい。

したがって、少なくとも１つのＲＲＨは、たとえば、ＧＳＭ、ＥＤＧＥ、ＵＭＴＳ、ＬＴＥ、またはＬＴＥ−Ａセルラ方式の無線送受信装置を含むことができる。もちろん、ＲＲＨは、また、将来のワイヤレス通信システムの少なくとも１つのセルにサービスを提供することができる。少なくとも１つのＲＲＨは、ベースバンド処理ユニットと少なくとも１つのＲＲＨとの間で複雑な値のデジタル・ベースバンド・データを交換するためにベースバンド処理ユニットに結合することができる。その目的のために、たとえば、共通公開無線インターフェース（ＣＰＲＩ：ｃｏｍｍｏｎ ｐｕｂｌｉｃ ｒａｄｉｏ ｉｎｔｅｒｆａｃｅ）として知られているインターフェースを使用することができる。

ベースバンド信号処理ユニットまたはＢＢＵは、ベースバンド（信号）処理クラスタの処理ノードとして理解することができる。個々のベースバンド処理ユニット（ＢＢＵ）およびベースバンド処理クラスタの両方は、複数のそのようなベースバンド処理クラスタを含むクラウド・コンピューティング・ネットワークの一部でもよい。ベースバンド処理クラスタまたはＢＢＵクラスタ内のＢＢＵの中でデータを交換するために、ＢＢＵは、ＢＢＵクラスタの第２の信号処理ノードとしてサービスを提供する第２のＢＢＵに第１のＢＢＵを接続するインターフェースを含むことができる。前述のインターフェースは、信号処理ユニット（ＢＢＵ）間でデジタル・ベースバンド・データを交換するように適応させることができる。ＢＢＵクラスタの個々のＢＢＵの間のそのようなデータ交換は、よって、クラスタ内負荷バランシング／分散エンティティと見なすことができる、クラスタ内処理リソース管理エンティティによって管理することができる。インターフェースは、たとえば、ＬＴＥの３ＧＰＰ規格の一部として拡張されたＸ２インターフェースなど、相互に接続されたＢＢＵの間で制御情報を交換するためにさらにサービスを提供することができる。

クラウド・コンピューティングまたはクラウド・コンピューティング・ネットワークは、サービスを伝達するシステムまたはネットワークの物理的な位置および構成についてエンド・ユーザが知ることを必要としない、計算、ソフトウェア、データ・アクセス、および保管サービスを提供できる技術として理解することができる。よって、クラウド・コンピューティングは、たとえば、インターネット・プロトコル（ＩＰ）に基づいて、ＩＴサービスの補足、消費、および伝達モデルを表すものであり、典型的には、動的に拡張可能で、多くの場合、仮想化されたリソースの供給を含む。よって、ＢＢＵクラウド・コンピューティング・ネットワークには、ＢＢＵハードウェアまたはベースバンド処理ユニットのクラスタのプールがある。各ＢＢＵは、クラウド・コンピューティング・ネットワークのネットワーク・ノードと見なすことができ、ここで各ノードは、そのようなコンピュータ・リソースまたは信号処理リソースの１つまたは複数を収容する。実施形態によると、ベースバンド信号処理タスクは、特定のネットワーク・ノードに必ずしも関連しておらず、本発明の実施形態の分散型負荷管理および分散手法を使用して、同じＢＢＵクラスタの任意の他のネットワーク・ノードまたはさらに他のリモートＢＢＵクラスタのネットワーク・ノードに動的に割り当てることができる。よって、利用可能な分散型ハードウェア・リソースの効率的な使用を達成することができる。ワイヤレス通信システムの遅延要件が準拠されている場合、これはすべて実施することができる。

各ＢＢＵは、複数の専用ユーザ・データ・プロセッサを含むことができ、ここで専用ユーザ・データ・プロセッサのそれぞれは、Ｓ１終端から、それぞれのＢＢＵに結合された少なくとも１つのＲＲＨによってサービスを提供される無線セルに関連する物理レイヤのユーザ部分までユーザ特有のデータをすべて処理するように動作可能である。セルの物理レイヤとしてのＢＢＵの専用ユーザ・データ・プロセッサの間の信号処理タスクは、ユニット特有の信号処理リソース管理エンティティによって管理することができる。

実施形態では、ユーザ特有のデータは、また、ベアラ特有のデータとして理解することができる。すなわち、ユーザ特有のデータまたはデータ・ストリームは、異なる無線ベアラを表すことができ、無線ベアラは、ユーザのデータ・サービスについてプロトコルの状況による。言い換えると、ユーザは、異なる無線ベアラを使用して提供される、複数のサービスを利用することができる。より詳細については、たとえば、無線インターフェース・プロトコル・アーキテクチャ３ＧＰＰ ＴＳ２５．３０１、Ｖ１０．０．０など、３ＧＰＰ規格を参照すること。ＵＭＴＳまたはＬＴＥでは、物理レイヤ（レイヤ１またはＰＨＹ）、メディア・アクセス制御レイヤ（レイヤ２またはＭＡＣ）、ＲＬＣレイヤ、およびＲＲＣを含めることができる。これらのプロトコルはすべて３ＧＰＰによって標準化され、それぞれの規格が公開されており、本明細書の続きにおいて知られているものと考えられる。

処理クラスタのＢＢＵに関連するユーザのユーザ特有のデータ（パケットまたはストリーム）の信号処理は、クラスタの特定の信号処理負荷につながる。ＢＢＵクラスタは、クラスタ間インターフェースを介して少なくとも第２のリモートＢＢＵクラスタのリモート・クラスタ間処理リソース管理エンティティと負荷情報を交換し、したがって、交換された負荷情報に応じて、第１のクラスタおよびリモートの第２のクラスタの複数のＢＢＵの間で処理タスクを分散するように動作可能なクラスタ間処理リソース管理エンティティを含む。クラウド・コンピューティング・ネットワークにおける異なるＢＢＵクラスタのＢＢＵの中での処理タスクの分散は、負荷バランシングまたは負荷分散基準により実施することができる。そのような負荷分散／分散基準は、たとえば、個々のＢＢＵクラスタおよび／またはＢＢＵの間で均等に共有された負荷の分散でもよい。他の基準は、ＢＢＵクラスタおよび／またはＢＢＵの電力消費を最適化することでもよい。たとえば、他のアクティブなＢＢＵが負荷を扱うことができる限り、一部のＢＢＵまたはその部分はオフにすることができる。

よって、実施形態は、ベースバンドまたはベアラの信号処理は、たとえば、空間的に分割されたＢＢＵクラスタに配置できる処理ノードとして複数の異なる相互に接続されたＢＢＵによって実行できるため、分散型またはクラウドのような方法で、ベースバンドまたはベアラの信号処理方式を提供することができる。これは、特定のＢＢＵクラスタにトラフィックのホット・ゾーンがある場合、ＢＢＵクラスタおよび／またはＢＢＵの分散ネットワークの利用を通じて、より多くの処理能力を利用可能にできるという利点を提供することができる。

さらに、実施形態は、無線セルのサービスをサービスまたはユーザに特有のデータ・パケットへと多重分離することができ、次に、クラウドの異なる処理ノードにルーティングできるため、無線セルごとに拡張可能な処理能力を利用可能にできるという利点を提供することができる。言い換えると、ユーザまたはベアラに特有のデータの処理を所与の負荷バランシング／分散基準により、様々なネットワーク・ノードの間で分散することができる。それが意味するのは、ＲＲＨによって処理されたユーザまたはベアラに特有の信号は、必ずしも、物理的に接続されたＢＢＵによって前処理または後処理しなくてもよいため、所与のＲＲＨと、ＲＲＨが物理的に接続されたＢＢＵとの間のユーザ処理に固定された関連はないということである。実施形態の分散された負荷バランシングおよび／または負荷分散アーキテクチャのために、ＢＢＵクラウド・ネットワークは、どの信号処理ノードが、負荷バランシング／分散基準に基づいて、所与のユーザのベースバンドまたはベアラ処理を実行するべきかを決定する。

特定の負荷状況では、クラスタ内処理リソース管理エンティティは、クラスタ内のＢＢＵの中で負荷バランシング／分散状況を改善するために、ユーザ特有のデータのベースバンドまたはベアラ処理をクラスタの第１のＢＢＵから同じ信号処理クラスタの他の第２のＢＢＵにシフトことを決定することができる。よって、信号処理クラスタの第２のＢＢＵは、第１のＢＢＵに結合されたＲＲＨまたはセルに実際に関連するユーザからユーザ特有のデータを処理することができる。

ＢＢＵクラスタのＢＢＵの制限された利用可能な信号処理機能のみが、ユーザまたはベアラに特有のデータを処理するためにＢＢＵクラスタのＢＢＵの割り当てを許可しない場合、クラスタ間処理リソース管理エンティティは、第１のＢＢＵクラスタから要求されたユーザまたはベアラに特有の信号処理タスクを引き継ぐために利用可能である十分な信号処理機能を持つリモートＢＢＵクラスタを割り当てるために、１つまたは複数のリモートＢＢＵクラスタと通信することができる。よって、次に、リモートの第２のクラスタのＢＢＵは、第１のクラスタのＢＢＵに実際に関連するユーザのユーザ特有のデータを処理することができる。ＢＢＵのこの階層構造、クラスタ内処理リソース管理エンティティ、およびクラスタ間処理リソース管理エンティティは、異なるクラスタ間のわずかな相互通信のみを用いて分散された負荷バランシング／分散を可能にする。

一部の実施形態によると、ＢＢＵクラスタの複数のＢＢＵは、たとえばＵＭＴＳのＣＤＭＡなど、第１の無線アクセス技術（ＲＡＴ）により、ユーザ特有のデータを処理するように動作可能なＢＢＵの第１のグループを含むことができる。さらに、ＢＢＵクラスタの複数のＢＢＵは、また、たとえばＬＴＥのＯＦＤＭＡなど、第２のＲＡＴにより、ユーザ特有のデータを処理するように動作可能なＢＢＵの第２のグループを含むことができる。ＢＢＵの異なるグループは、場合によっては、同じＲＡＴをサポートするそれぞれのセル物理層プロセッサとともに、チャネル要素モジュール（ＣＥＭ）と呼ぶことができる、１つまたは複数の異なるプリント回路基板（ＰＣＢ）に実装することができる。すなわち、第１のＲＡＴおよび信号処理ユニットの第１のグループをサポートする第１のセル物理レイヤ・プロセッサは、第１の共通のＣＥＭに統合することができ、第２のＲＡＴおよび信号処理ユニットの第２のグループをサポートする第２のセル物理レイヤ・プロセッサは、同じＢＢＵの第２の共通のＣＥＭに統合することができる。よって、ＢＢＵクラスタは、また、マルチサイト・マルチ標準（ＭＳＳ：ＭｕｌｔｉＳｉｔｅ ＭｕｌｔｉＳｔａｎｄａｒｄ）ＢＢＵクラスタと呼ぶことができる。

本発明の他の態様によると、クラウド・コンピューティング・ネットワークの異なるネットワーク・ノード・クラスタとして、実施形態による、少なくとも２つのベースバンド信号処理クラスタを含むクラウド・コンピューティング・ネットワークが提供される。それと同時に、非集中化された負荷バランシング／分散は、非集中化された負荷分散装置として可能になり、それぞれ第１および第２のクラスタのクラスタ内処理リソース管理エンティティおよびクラスタ間処理リソース管理エンティティは、第１のクラスタと第２のクラスタと間のインターフェースを介して負荷情報を交換し、クラウド・コンピューティング・ネットワークの異なるＢＢＵクラスタの間で信号処理負荷を分散するために、交換された負荷情報に応じて、第１のクラスタおよび第２のクラスタの複数のＢＢＵの間のベースバンド信号処理タスクを分散するように動作可能である。

本発明のさらに他の態様によると、ワイヤレス通信ネットワークのベースバンド信号処理クラスタ（ＢＢＵクラスタ）のための方法が提供され、ベースバンド信号処理クラスタは、複数のベースバンド信号処理ユニット（ＢＢＵ）を含み、ベースバンド信号処理ユニットの少なくとも１つ（具体的にはそれぞれ）は、ワイヤレス通信ネットワークの第１の無線セル・クラスタにサービスを提供する少なくとも１つのＲＲＨに結合される。方法は、ＢＢＵクラスタの複数のＢＢＵの利用可能な（信号）処理機能についての情報を提供するステップを含む。クラスタのＢＢＵに結合されたリモート・ラジオ・ヘッドに関連するユーザに対するユーザまたはベアラに特有の信号処理要求に応じて、方法は、ＢＢＵクラスタ内の利用可能な信号処理機能についての情報が、ユーザまたはベアラに特有の信号処理要求に対して十分な利用可能な処理リソースを示す場合、ＢＢＵクラスタの複数のＢＢＵの中で処理リソースを割り当てるステップを含む。しかしながら、ＢＢＵクラスタ内の利用可能な信号処理機能が、ユーザまたはベアラに特有の信号処理要求に対して十分に利用可能な信号処理リソースがないことを示している場合、方法は、クラスタのクラスタ間処理リソース管理エンティティを介して、異なる第２の無線セル・クラスタに関連する少なくとも１つのリモートＢＢＵクラスタにリモート処理リソース要求を送信するステップを含む。

一部の実施形態は、方法を実行するために装置または信号処理クラスタ内に設置された１つまたは複数のプログラム可能なデジタル制御回路を含む。そのようなプログラム可能なデジタル制御回路、たとえば、デジタル信号プロセッサ（ＤＳＰ）、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、またはハードウェア・アクセラレータを備えた汎用プロセッサは、それに応じてプログラムする必要がある。よって、さらに他の実施形態では、また、コンピュータ・プログラムがプログラム可能なハードウェア・デバイスで実行されたときに、方法の実施形態を実行するためのプログラム・コードを持つコンピュータ・プログラムを提供する。

実施形態の利点の１つは、分散された負荷バランシング／分散のために、多くの基地局サイトおよび／または基地局処理容量を減らすことができることであり、このために、次にＯＰＥＸ／ＣＡＰＥＸの低減につながる。さらに、半静的なマルチＲＡＴ無線アクセス・ネットワークをＣＥＭソフトウェア交換によって提供することができる。これにより、扱いにくいハードウェアの変更なく、無線標準の展開を追求することが可能になる。

装置および／または方法の一部の実施形態について、例示のみを目的として、添付の図面に関して以下に記述する。

本発明の実施形態によるワイヤレス通信ネットワークの複数の相互に接続されたベースバンド処理クラスタを示す図である。 一実施形態によるベースバンド処理ユニット特有の処理リソース管理エンティティを示す図である。 一実施形態によるクラスタ内処理リソース管理エンティティを示す図である。 一実施形態によるクラスタ間信号処理リソース管理エンティティを示す図である。 一実施形態による方法を図式的に示す流れ図である。 時間の経過に伴うクラスタ内の利用可能な信号処理リソースの変化を示す図である。 第１の実施形態のメッセージ・シーケンス・チャート（ＭＳＣ）を示す図である。 第２の実施形態のＭＳＣを示す図である。

ここで、様々な例示的実施形態について、一部の例示的実施形態を示した添付図面に関してより完全に記述する。図において、線の太さ、レイヤ、および／または領域は、明瞭さのために誇張している場合がある。

したがって、例示的実施形態は、様々な変更および代替形式が可能であり、その実施形態は、一例として図面に示され、本明細書に詳細に記述されるだろう。しかし、例示的実施形態を開示された特定の形式に制限する意図はなく、それとは反対に、例示的実施形態は、本発明の範囲内にある変更、等価物、および代替案をすべて包含することを理解するべきである。同様の番号は、図の記述の全体にわたって類似または同様の要素を表している。

要素が他の要素に「接続される（ｃｏｎｎｅｃｔｅｄ）」または「結合される（ｃｏｕｐｌｅｄ）」と言及された場合、他の要素に直接的に接続または結合することが可能であり、または介在する要素が存在する場合があることを理解されるだろう。これとは対照的に、要素が他の要素に「直接的に接続される（ｄｉｒｅｃｔｌｙ ｃｏｎｎｅｃｔｅｄ）」または「直接的に結合される（ｄｉｒｅｃｔｌｙ ｃｏｕｐｌｅｄ）」と言及された場合、介在する要素は存在しない。要素間の関係を記述するために使用される他の言葉は、同様に解釈されるべきである（たとえば、「の間（ｂｅｔｗｅｅｎ）」と「直接的に間に（ｄｉｒｅｃｔｌｙ ｂｅｔｗｅｅｎ）」、「隣接する（ａｄｊａｃｅｎｔ）」と「直接的に隣接する（ｄｉｒｅｃｔｌｙ ａｄｊａｃｅｎｔ）」など）。

本明細書に使用する用語は、特定の実施形態についてのみ記述することを目的とするものであり、例示的実施形態に限定することを意図するものではない。本明細書に使用する場合に、単数形の「ａ（１つの）」「ａｎ（１つの）」、および「ｔｈｅ（その）」は、そうでないことが文脈に明白に示されていない限り、複数形も含むことが意図される。本明細書に使用する場合、「ｃｏｍｐｒｉｓｅ（含む）」、「ｃｏｍｐｒｉｓｉｎｇ（含んでいる）」、および／または「ｉｎｃｌｕｄｉｎｇ（含む）」という用語は、記述された機能、整数、ステップ、動作、要素、および／または構成要素の存在を示すものであるが、１つまたは複数の他の機能、整数、ステップ、動作、要素、構成要素、および／またはそれらのグループの存在や追加を排除するものではないことをさらに理解されるだろう。

特に定義しない限り、本明細書に使用するすべての用語（技術用語および科学用語を含む）は、例示的実施形態が属する当業者によって一般的に理解されるものと同じ意味を持っている。用語、たとえば一般に使用される辞書に規定されているものは、関連する技術分野の文脈における意味に一致する意味を持つものと解釈するべきであり、特に本明細書に規定されていない限り、理想化された、または過度に形式的な意味で解釈されるものではないことをさらに理解されるだろう。

図１は、複数の相互に接続されたベースバンド信号処理クラスタ（ＭＳＳ−ＢＢＵクラスタ）１００−１、１００−２・・・１００−Ｎを含むクラウド・ネットワークを概略的に示しており、ここでＮは、２以上の正の整数を示している。複数のベースバンド処理クラスタ１００−１から１００−Ｎは、ＵＭＴＳネットワーク、ＬＴＥ−もしくはＬＴＥ−Ａネットワーク、または他の現在もしくは将来のワイヤレス通信ネットワークなど、ワイヤレス通信ネットワークのアップリンクおよび／またはダウンリンクのデータを処理するためにサービスを提供する。信号処理クラスタ１００−１から１００−Ｎのそれぞれは、複数のベースバンド信号処理ユニット（ＢＢＵ）１１０を含み、ＢＢＵ１１０のそれぞれは、ワイヤレス通信ネットワークの少なくとも１つのＲＲＨ（図１に図示せず）に結合することができる。さらに、ＢＢＵ１１０のそれぞれは、関連するＢＢＵ１１０の信号処理リソース割り当てを管理するように動作可能なユニット特有の処理リソース管理エンティティ１２０を含むことも、またはそれに結合することもできる。ユニット特有の処理リソース管理エンティティ１２０は、また、各ＢＢＵ１１０のローカル・リソース・マネージャ（ＬＲＭ）と呼ぶことができる。さらに、ＭＳＳ−ＢＢＵクラスタ１００−１から１００−Ｎのそれぞれは、ＢＢＵ１１０のそれぞれおよび／またはそのユニット特有の処理リソース管理エンティティ１２０のそれぞれに結合できるクラスタ内処理リソース管理エンティティ１３０を含むことができる。クラスタ内（信号）処理リソース管理エンティティ１３０は、また、クラスタ内リソース・マネージャ（イントラＲＭ）と呼ぶこともできる。イントラＲＭ１３０は、ＭＳＳ−ＢＢＵクラスタ１００−１、１００−２・・・１００−Ｎ内の複数のＢＢＵ１１０の中でユーザまたはベアラに特有のデータ処理のために処理リソース割り当てを管理するように動作可能である。ＭＳＳ−ＢＢＵクラスタ１００−１から１００−Ｎのそれぞれは、また、イントラＲＭ１３０に結合することができ、その関連するＭＳＳ−ＢＢＵクラスタで利用可能な（信号）処理機能または負荷を場合によっては示す情報を交換するように動作可能であるクラスタ間処理リソース管理エンティティ１４０と、リモート・ベースバンド信号処理のリソース割り当てを管理するためのワイヤレス通信ネットワークのリモートＭＳＳ−ＢＢＵクラスタの少なくとも１つの他のリモート・クラスタ間処理リソース管理エンティティ１４０とを含む。クラスタ間処理リソース管理エンティティ１４０は、また、ＭＳＳ−ＢＢＵ間リソース・マネージャ（インターＲＭ）と呼ぶことができる。異なるＭＳＳ−ＢＢＵクラスタ１００−１から１００−ＮのインターＲＭ１４０は、クラスタ間信号インターフェース１５０を介して互いに通信することができる。クラスタ間信号インターフェース１５０は、たとえば、イーサネットの拡張されたＸ２（ｅＸ２）インターフェースでもよい。イントラＲＭ１３０およびインターＲＭ１４０の両方は、それぞれのＭＳＳ−ＢＢＵクラスタ１００−１から１００−Ｎで利用可能である、いわゆる非集中化されたクラウド・コントローラ（ＤＣＣ）１６０を形成する。

その後、ＭＳＳ−ＢＢＵクラスタ１００−１は、説明のために、関連する無線セルのクラスタのホームＭＳＳ−ＢＢＵクラスタと見なすことができる。ユーザのホームＭＳＳ−ＢＢＵクラスタ１００−１は、ユーザごとの論理機能と見なすことができ、ユーザが位置する無線セルにサービスを提供するＲＲＨに接続されたその制御エンド・セル機能を備えたホームＢＢＵ１１０を含む。リモートＭＳＳ−ＢＢＵクラスタ１００−２から１００−Ｎは、ユーザごとの論理機能と見なされ、クラウドへのリモート・ユーザ機能を持つＢＢＵ１１０を含む。

各信号処理ユニットまたはＢＢＵ１１０は、また、無線ベアラのセットアップ手順の間にホームＭＳＳ−ＢＢＵクラスタ１００−１でアクティブな役割を演じる無線ベアラ制御機能（ＲＢＣ）１７０を含むか、またはそれに結合される。ＲＢＣ１７０は、また、イントラＲＭ１３０に対して直接的なインターフェースを持つことができる。ＲＢＣ１７０が、各ＭＳＳ−ＢＢＵクラスタ１００−１から１００−Ｎの各ＢＢＵ１１０に存在できる場合でも、図１は、リモートＭＳＳ−ＢＢＵクラスタ１００−２から１００−Ｎに対するＲＢＣ１７０を示していない。よって、ＭＳＳ−ＢＢＵクラスタ１００の各ＢＢＵ１１０は、前述のＢＢＵに結合された少なくとも１つのＲＲＨ（または無線セル）に関連するユーザ専用であるユーザ特有のデータ処理を初期化するように動作可能な無線ベアラ制御エンティティを含む。

各ＭＳＳ−ＢＢＵクラスタ１００−１から１００−Ｎは、多数のＢＢＵ１１０を含むことができる。各ＢＢＵ１１０は、少なくとも１つのＲＲＨを扱い、たとえば、ＭＡＣアドレスまたはＩＰアドレスなど個々のネットワーク識別子を持つことができる。ＢＢＵ１１０に関連するＲＲＨは、たとえば、ＣＰＲＩなど光インターフェースを介してそれぞれの関連するＢＢＵ１１０と通信することができる。１つのＢＢＵクラスタ１００−１から１００−Ｎの様々なＢＢＵ１１０は、内部的な高速クラスタ内バス（図１に明示的に図示せず）を介して互いに相互連結することができる。クラスタ１００の個々のＢＢＵ１１０への信号処理リソース割り当ては、各ＢＢＵ１１０のＬＲＭ１２０へのインターフェースを持つイントラＲＭ１３０によって管理され、ＬＲＭ１２０は、各ＢＢＵ１１０内で処理リソースを管理し、たとえば、ハードウェア・アクセラレータ・モジュール、ＤＳＰ、ＦＰＧＡ、など、占有されている、または占有されていない処理リソースを報告する。

各ＭＳＳ−ＢＢＵクラスタ１００−１から１００−ＮのイントラＲＭ１３０に結合されたネットワーク・ルータ・エンティティ１８０がある。そのため、ルータ・エンティティ１８０は、たとえば、イーサネット・プロトコルを介してＭＳＳ−ＢＢＵ内または間のレベルで、ユーザ特有の信号処理のために割り当てられたＢＢＵ１１０との間でＳ１データをルーティングするためにタスクを持つ。さらに、ルータ・エンティティ１８０は、イーサネットを介してＭＳＳ−ＢＢＵ内または間のレベルで、セルの物理レイヤ処理機能との間でユーザ特有のデータをルーティングすることができる。ＭＳＳ−ＢＢＵクラスタ１００の各ＢＢＵ１１０は、イーサネットにそれ自身のＩＰアドレスおよびＭＡＣアドレスを持つと想定されることに注意されたい。

信号処理クラスタ１００のインターＲＭ１４０は、クラスタ１００−１から１００−Ｎによって含まれるＭＳＳ−ＢＢＵ間の処理リソース・プールの信号処理リソース・クラスタを選択する。その目的のために、異なるインターＲＭ１４０は、よく知られているＸ２インターフェースの高速な変形形態を含むイーサネットの拡張されたＸ２（ｅＸ２）インターフェースでもよい、クラスタ間インターフェース１５０を介して互いに通信することができる。ＤＣＣ１６０のイントラＲＭ１３０とインターＲＭ１４０との間の通信は、たとえば、共通の共有メモリを介して行うことができる。ＭＳＳ−ＢＢＵクラスタ１００−１・・・１００−ＮのＤＣＣエンティティ１６０は、実施形態によるそれ自身のイーサネットＭＡＣアドレスを持てることに注意されたい。

図１に関して以前の項でクラウド・システムの概要を提示した後、ホームまたはリモートのＭＳＳ−ＢＢＵクラスタ１００−１・・・１００−Ｎの個々の階層的エンティティについて、以下により詳細に記述する。

ＬＲＭ１２０、イントラＲＭ１３０、およびインターＲＭ１４０はそれぞれ、１つまたは複数エンティティを含む：
・情報収集、監視、および報告を担当する、情報管理エンティティ（ＩＥ）、
・決定アルゴリズムが実装され、リソース・マネージャの決定を行うため、および他のユニットと通信するために必要なエンティティをすべて所有する、意思決定エンティティ（ＤＥ）、および
・意思決定エンティティの決定を実装する、実行エンティティ（ＥＥ）。

図２ａを見ると、ユニット特有の処理リソース管理エンティティ（ＬＲＭ）１２０を示しており、ＬＲＭ１２０は、情報管理エンティティ（ＩＥ）１２２および実行エンティティ（ＥＥ）１２４を含むことができる。ＩＥ１２２は、関連するＢＢＵ１１０の処理リソース・ステータスを監視し、監視された処理リソースおよび／または負荷状態を示す情報をイントラＲＭ１３０に提供すように動作可能でもよい。言い換えると、ＩＥ１２２は、関連するＢＢＵ１１０の使用済みおよび／または未使用の信号処理機能を監視／報告するように動作可能、または適応可能でもよい。ＥＥ１２４は、イントラＲＭ１３０から受信または転送された（ホームまたはリモート）信号処理要求に応じて、その関連するＢＢＵ１１０の信号処理リソースを割り当て、または指定するように動作可能、または構成可能でもよい。そのため、信号処理要求は、同じ（ホーム）クラスタのＢＢＵ１１０に関連するユーザまたはリモートＭＳＳ−ＢＢＵクラスタ１００−２から１００−ＮのＢＢＵに関連するユーザのユーザまたはベアラに特有の信号処理に関係することができる（リモート信号処理要求）。言い換えると、ＥＥ１２４は、関連するイントラＲＭ１３０の命令の実行に責任を負うものと見なすことができる。

ここで図２ｂを見ると、イントラＲＭ１３０は、ＭＳＳ−ＢＢＵクラスタ１００−１・・・１００−Ｎの主な処理リソース・マネージャと見なすことができる。それは、複数のベースバンド信号処理ユニットまたはＢＢＵ１１０を含むＭＳＳ−ＢＢＵクラスタのベースバンド信号処理リソース全体を管理することができる。イントラＲＭ１３０は、クラスタの複数のＢＢＵ１１０のＬＲＭ１２０から提供される監視および報告された信号処理リソース・ステータス情報に基づいて、その関連するＭＳＳ−ＢＢＵクラスタの利用可能なベースバンド処理リソースを決定するように動作可能な可能性がある情報管理エンティティ（ＩＥ）１３２を含むことができる。すなわち、イントラＲＭ１３０のＩＥ１３２は、各ＬＲＭ１２０から未加工のリソース情報を取得し、量子化されたリソース状態を処理することができる。さらに、イントラＲＭ１３０は、ＬＲＭ１２０によって提供されるユニット特有のリソースまたは負荷状態情報に基づいて、内部的に（＝ホーム）要求された信号処理タスクまたは外部的に（＝リモート）要求された信号処理タスクをＢＢＵ１１０の１つまたは複数に指定するように動作可能な決定エンティティ（ＤＥ）１３４を含むことができる。言い換えると、イントラＲＭ１３０のＤＥ１３４はリソース要求の指定を担当することができ、リソース要求またはそれぞれの要求された処理リソース容量をユニット特有の負荷状態情報と比較することによって、適切なＢＢＵ１１０を選択することができる。リソース割り当て要求が関連するＭＳＳ−ＢＢＵクラスタ１００−１の容量を超える場合、イントラＲＭ１３０のＤＥ１３４は、リモートＭＳＳ−ＢＢＵクラスタ１００−２から１００−Ｎの少なくとも１つで処理リソースのリモート割り当てを開始するためにインターＲＭ１４０に要求を転送することを決定することができる。言い換えると、自身（ホーム）のクラスタ１００−１の利用可能な処理リソースが処理要求に十分でない場合、インターＲＭ１３０は、少なくとも１つのリモート処理クラスタ１００−２から１００−Ｎ内のリモート・ベースバンド信号処理リソース割り当てを初期化するためにクラスタのインターＲＭ１４０にＢＢＵ１１０から信号処理要求を転送するように動作可能でもよい。

ここで図２ｃを見ると、インターＲＭ１４０の略ブロック図が示されている。インターＲＭ１４０は、ＭＳＳ−ＢＢＵクラスタ・プールの異なる処理クラスタ１００−１・・・１００−Ｎの中の処理リソースの割り当てを担当すると見なすことができる。その目的のために、クラスタ間処理リソース管理エンティティまたはインターＲＭ１４０は、その関連するＭＳＳ−ＢＢＵクラスタのリソース状態として、利用可能な処理リソースについての情報にアクセスするように動作可能な情報管理エンティティ（ＩＥ）１４２を含むことができる。そのため、利用可能な処理リソースについての情報は、たとえば、イントラＲＭ１３０とインターＲＭ１４０との間で共有されるメモリ・デバイス（＝共有メモリ）を介して、イントラＲＭ１３０によって提供することができる。さらに、ホームＭＳＳ−ＢＢＵクラスタ１００−１の利用可能な処理リソースが前述の信号処理要求に十分でない場合、インターＲＭ１４０は、利用可能な信号処理リソースについての情報に基づいて、自身（ホーム）の関連するＭＳＳ−ＢＢＵクラスタ１００−１からの信号処理要求により、利用可能な十分な信号処理リソースを持つリモートＭＳＳ−ＢＢＵクラスタ１００−２・・・１００−Ｎを決定するように動作可能な決定エンティティ（ＤＥ）１４４を含むことができる。クラスタ間リソース割り当てがイントラＲＭ１３０によってトリガーされると、インターＲＭ１４０のＤＥ１４４は、他の相互に接続されたＭＳＳ−ＢＢＵクラスタに相互リソース割り当て要求をリモートで所有するために適切な信号処理リソースを見つける必要がある。それは、したがって、２つのクラスタ間の信号処理プロセスを転送するためにリソース報告からターゲットＭＳＳ−ＢＢＵクラスタの決定まですべての必要な処理リソース共有メカニズムに参加する。インターＲＭ１４０のＩＥ１４２は、リソース状態としてイントラＲＭ１３０とインターＲＭ１４０との間の共有メモリから未加工のリソース情報を取得することができる。

本発明の実施形態は、また、ワイヤレス通信ネットワークのベースバンド処理クラスタ１００−１・・・１００−Ｎのための方法を含み、処理クラスタは、複数のベースバンド処理ユニットまたはＢＢＵ１１０を含み、ＢＢＵ１１０のそれぞれは、ワイヤレス通信ネットワークの少なくとも１つのリモート・ラジオ・ヘッドに結合される。図３は、そのような方法３００の一実施形態の図式的な流れ図を示している。

方法３００は、ＭＳＳ−ＢＢＵクラスタの複数のＢＢＵ１１０の中、またはその利用可能な信号処理機能についての情報を提供するステップ３１０を含む。既に説明したように、ＭＳＳ−ＢＢＵクラスタの利用可能な信号処理機能についての情報の準備は、ＭＳＳ−ＢＢＵクラスタの各ＢＢＵ１１０の個々の信号処理リソースを監視するサブステップと、ＢＢＵ１１０またはそのＬＲＭ１２０のそれぞれに結合されたイントラＲＭ１３０に監視された個々の信号処理リソースを報告するサブステップとを含むことができる。利用可能な信号処理機能についての情報をさらに提供するステップ３１０は、報告された個々の信号処理リソースに基づいている。方法３００は、クラスタ１００−１のＢＢＵ１１０に結合されたセルまたはＲＲＨに関連するユーザの信号処理要求を（たとえばユーザ特有の無線ベアラ要求に応じて）受信するステップ３２０をさらに含むことができる。方法３００の他のステップ３３０では、ＭＳＳ−ＢＢＵクラスタ１００−１の利用可能な信号処理機能についての情報が、受信された信号処理要求に対して十分な利用可能な信号処理リソースを示すかどうかをチェックすることができる。該当する場合、すなわち、クラスタ１００−１の利用可能な信号処理機能についての情報が、十分な利用可能な信号処理リソースを示している場合、クラスタ１００−１の複数のＢＢＵ１１０の中の信号処理リソースは、要求を処理するために割り当てることができる（ステップ３４０）。しかし、クラスタ１００−１内の利用可能な信号処理機能が、ベースバンド処理または無線ベアラ要求に対して十分に利用可能な信号処理リソースがないことを示している場合、方法３００は、少なくとも１つのリモートＭＳＳ−ＢＢＵクラスタ１００−２から１００−Ｎにリモート処理リソース要求を送信するステップ３５０を含む。言い換えると、ステップ３４０は、ホーム・クラスタ・ベースバンド処理につながり、要求によるベースバンド処理は、ホーム・クラスタ１００−１の１つまたは複数のＢＢＵ１１０により実行され、ステップ３５０は、リモートＭＳＳ−ＢＢＵクラスタ１００−２から１００−ＮのリモートＢＢＵのリソースを使用する要求の（リモート）処理につながる。ここで、図３の両方の分岐について、図４から図６を参照してより詳細に説明する。

いずれの場合にも、方法３００の情報管理は、２つの部分に分割することができる。ステップ３１０は、イントラＲＭ１３０およびインターＲＭ１４０の両方に対するリソース・ビュー（ｒｅｓｏｕｒｃｅ ｖｉｅｗ）を処理するための準備段階を示している。ステップ３４０は、続くクラスタ内処理リソース割り当てを示し、ステップ３５０は、リモートのクラスタ間処理リソース割り当てを示している。処理プール管理は、Ｓ１終端からＰＨＹユーザ部分（ユーザ関連のベースバンド処理）またはその一部までのユーザ機能に対処する。セルおよび制御の機能（セルの物理プロセッサ）は、ホームＢＢＵ１１０に位置することができ、対象のセルを持つＲＲＨが接続される。以下において、一般性を失うことなく、肯定応答（ＡＣＫ：ＡＣＫｎｏｗｌｅｄｇｅ）を用いる誤差のないケースのみについて記述する。

図５の代表的なメッセージ・シーケンス・チャート（ＭＳＣ）から見ることができるように、分散型ＲＡＮのリアル・タイム制約において階層制御プレーンにおける高パフォーマンス・リソース情報交換のためのシナリオを示しており、準備段階の間に、ホームＭＳＳ−ＢＢＵクラスタ１００−１の各ＢＢＵ１１０に関連するＬＲＭ１２０は、ＢＢＵ１１０のリソース・ステータスを継続的に監視し、たとえば、重要な変更の場合には、直接的に関連する（ホーム）イントラＲＭ１３０にそれを報告することができる。参照番号５０２を参照すること。ステップ５０２で個々のＢＢＵ１１０の監視されたリソース・ステータスを使って、イントラＲＭ１３０は、すべてのＬＲＭ１２０のリソース・ステータスを取得し、たとえば、最大の利用可能な処理リソースを持つＢＢＵ１１０からのリソース・ステータスを含むリソース状態を処理する（５０４を参照）。イントラＲＭ１３０は、ホームＭＳＳ−ＢＢＵクラスタ１００−１のＢＢＵ１１０の中で最大容量を検出し、共有メモリへの過去の経験（たとえば最大値の変動）に基づいて、最大値のエンベロープを構築することができる。この点において、図４は、処理クラスタ１００の個々のＢＢＵ１１０の使用された処理リソースの変形形態４０２を描写している。第１の時間間隔Ｔ_１では、クラスタ１００のＢＢＵの最大処理負荷４０４が検出される。この最大値４０４に基づいて、イントラＲＭ１３０は、クラスタの他のＢＢＵ１１０の過去の最大値の変動および／または追加的な処理能力に基づいてマージン（ｍａｒｇｉｎ）としてエンベロープ４０６を導き出すことができる。続く時間間隔Ｔ_２に対して同じことを実行することができる。エンベロープ４０６は、ＢＢＵの空またはまだ利用可能な処理リソースを決定するために、ＢＢＵの最大の利用可能な処理リソース４０８に関して設定することができる。

共有メモリにホームＭＳＳ−ＢＢＵクラスタ１００−１の処理リソース状態を持っているため、他のリモートＭＳＳ−ＢＢＵクラスタ１００−２・・・１００−ＮのインターＲＭ１４０から到着する信号処理リソース要求または需要の場合には、各ＭＳＳ−ＢＢＵ１００−１から１００−ＮのインターＲＭ１４０は、共有メモリから前述のリソース状態を取得することができる。ホーム・インターＲＭ１４０は、よって、リモートＭＳＳ−ＢＢＵクラスタ１００−２・・・１００−Ｎのそのピア・インターＲＭ１４０と、要求に応じて、クラスタ特有のリソース状態情報を交換することができる。

ホームＭＳＳ−ＢＢＵクラスタ１００−１のＢＢＵ１１０内において、無線ベアラ要求が（サービスの品質パラメータから得た容量記述とともに）、ＢＢＵ１１０に関連する発信元のＲＢＣ１７０からＬＲＭ１２０に到着した場合（ステップ５０６）、イントラＲＭ１３０は、たとえば、フィリング・アルゴリズム（ｆｉｌｌｉｎｇ ａｌｇｏｒｉｔｈｍ）に基づいて、ホームＭＳＳ−ＢＢＵクラスタ１００−１内のこの要求のＢＢＵ割り当てを決定することができる（ステップ５０８、５１０を参照）。ステップ５１２でＬＲＭ１２０による肯定応答（ＡＣＫ）の後に、イントラＲＭ１３０は、割り当てられたＢＢＵ１１０のＩＰアドレスをホームＭＳＳ−ＢＢＵクラスタ１００−１のルータ・エンティティ１８０に送信することができる（ステップ５１４を参照）。ルータ・エンティティ１８０の肯定応答５１６の後に、イントラＲＭ１３０は、発信元のＲＢＣ１７０に肯定応答を送信することができ、また、要求された無線ベアラを設定することができる。よって、イントラＲＭ１３０は、ルータ１８０のＭＳＳ−ＢＢＵクラスタ１００−１に関連する無線セルのユーザ専用であるユーザ特有の信号処理を実行するために十分な利用可能な信号処理能力を持つ割り当てられた、または指定されたＢＢＵ１１０のネットワーク・アドレス（たとえば、ＩＰアドレスを含む）を提供するように動作可能でもよい。このようにして、データは、ユーザのセルが関連する発信元のＢＢＵ１１０からホーム・クラスタＭＳＳ−ＢＢＵ１００−１の他のベースバンド処理ユニット１１０にルーティングすることができる。

ここで図６を参照して、分散型ＲＡＮのリアル・タイム制約において階層制御プレーンにおける高パフォーマンス・リソース情報交換のための他のシナリオについて記述する。図６の場合には、ホームＭＳＳ−ＢＢＵクラスタ１００−１内には、他の処理リソースは利用可能ではない。ここでも、情報管理は、２つの部分に分割することができる。すなわち、各ＭＳＳ−ＢＢＵクラスタ内のイントラＲＭ１３０およびインターＲＭ１４０に対するリソース・ビューを処理するための準備段階３１０、ならびにステップ３５０のクラスタ間処理リソース割り当てである。リモート処理プール管理は、ここで、Ｓ１終端からＰＨＹユーザ部分（ユーザ関連のベースバンド処理）またはその一部までのユーザ機能に対処する。セルおよび制御の機能は、ホームＭＳＳ−ＢＢＵクラスタ１００−１に位置し、対象の無線セルに結合されたＲＲＨが接続される。説明のために、誤差なしのケースだけを記述する。

準備段階３１０の間に、図５、およびそこに描写したステップ５０２、５０４に関して記述したのと同じ手順が実行されている。ホームＭＳＳ−ＢＢＵクラスタ１００−１の複数のＢＢＵ１１０の中で利用可能な信号処理能力についての情報を提供した後に、ホームＭＳＳ−ＢＢＵクラスタ１００−１のＢＢＵ１１０に結合されたセルに関連するユーザの無線ベアラ要求は、サービスの品質パラメータから得た容量記述とともに、ステップ５０６で開始することができる。よって、ホームＢＢＵ１１０内で、容量記述を持つ無線ベアラ要求が、ＢＢＵのＲＢＣ１７０からＢＢＵのＬＲＭ１２０に到着する場合、およびホームＭＳＳ−ＢＢＵクラスタ１００−１の利用可能な処理リソースが、対応する処理リソース要求を満たすのに十分でない場合、ホームＭＳＳ−ＢＢＵクラスタ１００−１のイントラＲＭ１３０は、容量記述を満たすリモート・リソース割り当てについて、ステップ６０８で、その関連するインターＲＭ１４０にリソース要求または需要を転送することができる。すなわち、ホームＭＳＳ−ＢＢＵクラスタ１００−１の利用可能な処理リソースが、関連するホームＢＢＵ１１０からの受信された信号処理要求に十分でない場合、イントラＲＭ１３０は、少なくとも１つのリモートＭＳＳ−ＢＢＵクラスタ１００−２・・・１００Ｎ内において、リモート信号処理リソース割り当てを初期化するために、関連するホームＢＢＵ１１０からインターＲＭ１４０に、ベースバンド処理要求を転送するように動作可能な場合がある。

ステップ６０８の転送された信号処理要求に応じて、ホーム・インターＲＭ１４０は、ステップ６１０で、隣接する、つまりリモートのＭＳＳ−ＢＢＵクラスタ１００−２から１００−Ｎのリストを取得またはアクセスすることができる。次に、ホームＭＳＳ−ＢＢＵ１００−１のインターＲＭ１４０は、ステップ６１２で遅延初期化手順の結果として、その隣接リストのＭＳＳ−ＢＢＵクラスタへの実際の遅延測定をトリガーすることができる。すなわち、インターＲＭ１４０は、その関連するホームＭＳＳ−ＢＢＵクラスタ１００−１と、少なくとも１つのリモートＭＳＳ−ＢＢＵクラスタ１００−２から１００−Ｎとの間の信号伝播遅延を決定するために、時間遅延測定を開始するように動作可能でもよい。ステップ６１２の遅延測定に応じて、ホームＭＳＳ−ＢＢＵクラスタ１００−１のインターＲＭ１４０は、１つまたは複数のリモートＭＳＳ−ＢＢＵクラスタ１００−２から１００−Ｎから、ステップ６１４で実際の遅延応答を受信することができる。潜在的なリモートＭＳＳ−ＢＢＵクラスタ１００−２から１００−Ｎによる応答の後に、ホームＭＳＳ−ＢＢＵクラスタ１００−１のインターＲＭ１４０は、必要な遅延要件を満たすｅＸ２インターフェース１５０で許可された最大時間遅延との新しい比較の後に、ステップ６１６でその隣接リストを更新することができる。言い換えると、クラスタ間処理リソース管理エンティティ１４０は、ステップ６１２の時間遅延測定に応じて、ステップ６１６で、適切なリモートＭＳＳ−ＢＢＵクラスタ１００−２・・・１００−Ｎのリストを更新するように動作可能な場合があり、最大の許可された時間遅延を下回るリモート信号処理の信号伝播遅延につながる。

ステップ６１６で隣接リストを更新した後、ホーム・インターＲＭ１４０は、更新された隣接リストにより、その関連するイントラＲＭ１３０から潜在的なリモートＭＳＳ−ＢＢＵクラスタのすべてのリモート・インターＲＭに、容量記述を含む「リソース需要」メッセージを転送することができる（参照番号６１８を参照）。よって、インターＲＭ１４０は、その関連する（ホーム）ＭＳＳ−ＢＢＵクラスタ１００−１から、更新された隣接リストの潜在的なリモートＭＳＳ−ＢＢＵクラスタ１００−２・・・１００−Ｎのすべてのリモート・クラスタ間処理リソース管理エンティティ１４０に、信号処理要求を転送するように動作可能でもよい。

ステップ６１８のそのような「リソース需要」メッセージを受信する各リモート・インターＲＭ１４０は、ここで、そのそれぞれの関連するイントラＲＭ１３０を用いて共有メモリからリソース状態を読み込むことができる。ステップ６２０を参照すること。たとえば、リモートＭＳＳ−ＢＢＵクラスタ１００−２・・・１００−Ｎの最大かつ自由な信号処理容量を持つリモートＢＢＵ１１０に関係する、読み込まれたリソース状態が、ホーム・インターＲＭ１４０によって要求された処理容量を満たす場合、潜在的なリモートＭＳＳ−ＢＢＵクラスタ１００−２・・・１００−Ｎ（つまりリモート・インターＲＭ１４０）は、ステップ６２２で、場合によっては、リソース・ステータスを含む肯定応答（ＡＣＫ）で応答することができる。しかし、ステップ６２０で取得されるリソース状態が要件を満たさない場合、リモート・インターＲＭ１４０は、代わりにＮＡＣＫで応答することができる。ステップ６２２の肯定応答を受信した後、ホーム・インターＲＭ１４０は、ステップ６２４でリモート処理割り当てに関する決定を行うことができる。この決定に対して、２つのオプションがあってもよい。つまり、ホーム・インターＲＭ１４０は、ステップ６２２で最初に肯定メッセージで応答したリモートＭＳＳ−ＢＢＵクラスタに決定するか、またはホーム・インターＲＭ１４０は、実際の隣接リストにより、それぞれのリソース状態を含む潜在的なリモートＭＳＳ−ＢＢＵクラスタのすべてのリモート・インターＲＭの応答を待つことができる。次に、それは、ステップ６２２で肯定メッセージで応答した潜在的なリモート処理クラスタの中から、そのリソース状態で示された最大の処理マージンを持つ１つのリモートＭＳＳ−ＢＢＵクラスタ１００−２・・・１００−Ｎを選択することができる。これが意味するのは、一実施形態によると、ホーム処理クラスタのインターＲＭ１４０は、ホーム・クラスタに関連するユーザの無線ベアラ要求５０６に関係するリモート信号処理について、最大の利用可能なリモート信号処理能力を示す、リモートＭＳＳ−ＢＢＵクラスタ１００−２・・・１００−Ｎを選択するように動作可能な場合がある。他の実施形態によると、ホーム処理クラスタ１００−１のインターＲＭ１４０は、また、無線ベアラ要求５０６に関係するリモート信号処理について、ホーム・インターＲＭ１４０から関係するリモート信号処理リソース要求６１８を肯定する最初のリモートＭＳＳ−ＢＢＵクラスタである、リモートＭＳＳ−ＢＢＵクラスタ１００−２・・・１００−Ｎを選択するように動作可能でもよい。

ステップ６２４の決定の後に、ホーム処理クラスタ１００−１のインターＲＭ１４０は、「ＭＳＳ−ＢＢＵのリモート割り当て」メッセージ６２６を送信することができる。これは、たとえば、オリジナル無線ベアラ要求５０６が関係するユーザ専用のホームＢＢＵ１１０のイーサネットＭＡＣアドレスを含むことができる。さらに、「ＭＳＳ−ＢＢＵのリモート割り当て」メッセージ６２６は、前述のユーザのユーザＩＤを含むことができる。すなわち、ホーム処理クラスタ１００−１のインターＲＭ１４０は、前述のユーザに関連する無線ベアラ・データのリモート信号処理について、ホーム・クラスタに属するＢＢＵ１１０のネットワーク・アドレス（イーサネットＭＡＣアドレスおよび／またはＩＰアドレス）および前述のＢＢＵ１１０に対応する無線セルに関連するユーザの識別子を選択されたリモート処理クラスタ１００−２・・・１００−Ｎに転送するように動作可能でもよい。

リモートＭＳＳ−ＢＢＵクラスタのインターＲＭ１４０は、ここで、ステップ６２８でその関連する（リモート）イントラＲＭ１３０に「リソース要求」メッセージを送信することができ、ここで「リソース要求」メッセージは、「リソース需要」メッセージ６１８、ホームＢＢＵのイーサネットＭＡＣアドレス、および対応するユーザＩＤとともに既に受信されている可能性がある容量記述を含むことができる。リモート・インターＲＭ１４０の観点から見て、リモート信号処理クラスタ（つまりホーム・クラスタ１００−１）のリモート信号処理ユニット（つまりホームＢＢＵ）に関連するユーザに関係するユーザ特有の信号処理を実行するために、十分な利用可能な信号処理能力を持つＭＳＳ−ＢＢＵクラスタ１００−２・・・１００−Ｎの少なくとも１つのＢＢＵ１１０の割り当てを初期化するために、リモート（つまりホーム）クラスタから受信された信号処理リソース要求をその関連するイントラＲＭ１３０に転送するように動作可能でもよく、ここで信号処理リソース要求は、前述のリモートＢＢＵ１１０（つまりホームＢＢＵ）のネットワーク・アドレスおよび前述のユーザの識別子を含む。

選択されたリモートＭＳＳ−ＢＢＵクラスタ１００−２・・・１００−Ｎのリモート・イントラＲＭ１３０は、ここで、そのフィリング・アルゴリズムにより、ジョブを処理するためにリモートＢＢＵ１１０を決定できるため、リモートＭＳＳ−ＢＢＵクラスタ１００−２・・・１００−Ｎの複数のリモート処理ユニット１１０の間で利用可能な信号処理能力についての情報を考慮することができる。ステップ６３０を参照すること。リモート・イントラＲＭ１３０の観点から見ると、それは、リモート処理クラスタ（つまりホーム処理クラスタ）１００−１のリモートＢＢＵ１１０（つまりホームＢＢＵ）に関連するユーザのユーザ特有の信号処理を実行するために十分な利用可能な信号処理能力を持つ１つまたは複数の関連するＢＢＵ１１０（つまり、リモートＢＢＵ）の割り当てを初期化するために、その関連するイントラＲＭ１４０から信号処理要求を受信するように動作可能でもよい。

（リモート）ＢＢＵ１１０に関する決定の後に、（リモート）イントラＲＭ１３０は、選択された（リモート）ＢＢＵ１１０のＬＲＭ１２０に「ＢＢＵ割り当て」メッセージを送信することができる。参照番号６３２を参照すること。次に、ステップ６３４でこのＬＲＭ１２０からＡＣＫを受信した後、（リモート）イントラＲＭ１３０は、Ｓ１／ｅＸ２インターフェースで、「ホーム／リモートＢＢＵへのルーティング情報」メッセージ６３６をリモートＭＳＳ−ＢＢＵクラスタ１００−２・・・１００−Ｎのルータ１８０に送信することができる。このメッセージは、対応する（発信側）ユーザＩＤだけでなく、ホーム（つまり発信側）およびリモートＢＢＵのイーサネットＭＡＣアドレスを含むことができる。よって、リモート・イントラＲＭ１３０の観点から見ると、リモートＢＢＵ（つまり発信元のホームＢＢＵ）に関連するユーザのユーザ特有の信号処理を実行するために十分な利用可能な処理能力を持つ割り当てられた、または指定されたベースバンド処理ユニット１１０のネットワーク・アドレス、前述のリモートＢＢＵのネットワーク・アドレス、および前述の（発信側）ユーザの識別子をその関連するＭＳＳ−ＢＢＵクラスタ１００−２・・・１００−Ｎのネットワーク・ルータおよび／またはインターＲＭ１４０に提供するように動作可能でもよい。ステップ６３８のルータ１８０のＡＣＫの後に、リモートＭＳＳ−ＢＢＵクラスタ１００−２・・・１００−ＮのイントラＲＭ１３０は、ステップ６４０でその関連する（リモート）インターＲＭ１４０にＡＣＫメッセージを送信することができる。このＡＣＫメッセージ６４０は、リモート処理クラスタの（リモート）処理ユニット１１０のＩＰアドレスおよびイーサネットＭＡＣアドレスを含むことができる。

次に、リモートＭＳＳ−ＢＢＵクラスタ１００−２・・・１００−ＮのインターＲＭ１４０は、ホームＭＳＳ−ＢＢＵクラスタ１００−１のインターＲＭ１４０に、選択されたリモートＭＳＳ−ＢＢＵクラスタ１００−２・・・１００−ＮのリモートＢＢＵへの完全なルーティング情報を含む、このＡＣＫメッセージ６４０を転送することができる。よって、ここでも、リモート・インターＲＭ１４０は、ホームＭＳＳ−ＢＢＵクラスタ１００−１にリモートＢＢＵのネットワーク・アドレスを転送するように動作可能でもよい。リモート・インターＲＭ１４０の観点から見ると、関連するＢＢＵのネットワーク・アドレスをリモートＭＳＳ−ＢＢＵクラスタ１００−１に転送するように動作可能でもよい。

ホームＭＳＳ−ＢＢＵクラスタ１００−１のインターＲＭ１４０によるこのＡＣＫメッセージ６４２の受信により、リモート割り当て手順は終了と見なすことができる。ホームＭＳＳ−ＢＢＵクラスタ１００−１のインターＲＭ１４０は、ここで、その関連する（ホーム）イントラＲＭ１３０に、リモートＢＢＵへの完全なルーティング情報を含む、この受信されたＡＣＫメッセージを転送することができる。ステップ６４４を参照すること。次に、ホームＭＳＳ−ＢＢＵクラスタ１００−１のイントラＲＭ１３０は、Ｓ１／ｅＸ２−インターフェースで、その関連するルータ・エンティティ１８０に「ホーム／リモートＢＢＵへのルーティング情報」メッセージを送信することができる。これは、次の情報要素を含む：リモートＢＢＵのＩＰアドレス、リモートＢＢＵのイーサネットＭＡＣアドレス、ホームＢＢＵのイーサネットＭＡＣアドレス、およびユーザＩＤ。よって、イントラＲＭ１３０は、十分な利用可能な信号処理能力を持つ割り当てられたリモートＢＢＵのネットワーク・アドレス、前述のリモートＢＢＵのネットワーク・アドレス、およびＭＳＳ−ＢＢＵクラスタ１００−１のネットワーク・ルータ１８０および／またはインターＲＭ１４０へのユーザの識別子を提供するように動作可能でもよい。ルータ１８０からＡＣＫメッセージを受信した後（参照番号６４８を参照すること）、ホーム処理クラスタ１００−１のイントラＲＭ１３０は、ホームＢＢＵ１１０に含まれる発信元のＲＢＣモジュール１７０に無線ベアラ要求ＡＣＫメッセージを送信することができ、ここでセルおよび制御の機能が割り当てられる。これにより、図６に描写した無線ベアラ要求手順を終了することができる。

最小の１つのアクティブなリモートで割り当てられた無線ベアラ処理を用いる各リモートＭＳＳ−ＢＢＵクラスタへの実際の遅延測定は、時々繰り返すことができることに注意されたい。測定期間は、初期化の間、または１つのＭＳＳ−ＢＢＵセル・クラスタ内のユーザのハンドオーバーの後に測定された、拡張されたＸ２インターフェース１５０での許可された最大遅延への遅延変動および利用可能なマージンに応じることができる。同じＭＳＳ−ＢＢＵセル・クラスタ内のセルへのユーザのハンドオーバーの場合には、ユーザが、ＭＳＳ−ＢＢＵクラスタにより近い、またはより離れたＲＲＨに属するセルに移動する場合、拡張されたＸ２インターフェースで許可された遅延は変更する場合がある。この場合、新しい潜在的な隣接リストは、ホームＭＳＳ−ＢＢＵクラスタ１００−１のインターＲＭ１４０によって処理および適用することができる。

要約すると、本発明の実施形態は、プールでリモート・ラジオ・ヘッドの異なるクラスタのベースバンド処理を管理する複数の協調するマルチサイト・マルチ標準ベースバンド・ユニット（ＭＳＳ−ＢＢＵ）を含むクラウドＲＡＮに環境に関し、各ＲＲＨクラスタは、ＭＳＳ−ＢＢＵクラスタに接続される。各ＭＳＳ−ＢＢＵクラスタは、多数のベースバンド処理ユニット（ＢＢＵ）を含む。ＭＳＳ−ＢＢＵクラスタは、低トラフィック領域から高トラフィック領域にベースバンド処理を移すためにリソース・プーリングおよび能力において高度な柔軟性を達成するためにさらにともに接続される。２レベルの抽象化におけるリソース、すなわちイントラＭＳＳ−ＢＢＵクラスタおよびインターＭＳＳ−ＢＢＵクラスタのリソース・プーリングを含むモバイル・クラウドの全体的なリソース管理に対処する新しいアーキテクチャが提案される。そのようなプーリング概念の目的の１つは、セル・クラスタ内において時間を通じて不均一な低プロファイルから生じる、統計的多重化による利得（ＣＡＰＥＸ低減）から利益を得ることである。さらに、従来の展開（ＯＰＥＸ低減）と比較して、ＢＢＵサイトが大幅に減る。これはすべて、たとえばＬＴＥ／ＵＭＴＳ（ＨＳＰＡ）など、複数標準の状況に適用することができる。

実施形態は、階層的リソース管理システムに基づくモバイル・クラウドのためのコントロール・プレーン・アーキテクチャに関する。モバイル・クラウドは、２つの抽象化レベルに多数のリソースを含む。したがって、ネットワーク全体のリソースの管理は、大きな課題と見なすことができる。実施形態では、処理リソース管理は、クラスタ内の部分およびクラスタ間の部分に分割される。これらの部分は、異なるリソース管理ユニットによって別々に管理される。さらに、実施形態は、クラスタ内およびクラスタ間のレベルで含まれるすべてのリソース管理ユニットの通信シナリオを処理する。

記述および図面は、単に本発明の原理を示すものである。本明細書に明示的に記述して示していないが、本発明の原理を具体化し、その精神および範囲に含まれる様々な配置を当業者であれば考案できることを理解されるだろう。さらに、本明細書に詳述したすべての例は、原則として、読者が本発明の原理、およびその技術を推進する発明者（ら）によって提供された概念を理解するのを支援するために、教育のみを目的とすることを明確に意図するものであり、そのような具体的に詳述された例および条件に限定しないものとして解釈するべきである。さらに、本明細書において、本発明の原理、態様、および実施形態を詳述するすべての記述、およびその特定の例は、その等価物を包含することを意図するものである。

（特定の機能を実行する）「・・・ための手段」として示された機能ブロックは、それぞれ特定の機能を実行するために適応された回路を含む、機能ブロックとして理解するものとする。よって、「何かのための手段」は、「何かのために適応された、または適している手段」として理解するべきである。よって、特定の機能を実行するために適応された手段は、そのような手段が前述の機能を（所定の瞬間に）必ずしも実行していることを意味しない。

任意の機能ブロックを含む、図に示す様々な要素の機能は、プロセッサなどの専用ハードウェア、および適切なソフトウェアと連携してソフトウェアを実行する機能を持つハードウェアの利用を通じて提供することができる。プロセッサによって提供される場合、プロセッサによって提供される場合、機能は、単一の専用プロセッサによって、単一の共有プロセッサによって、またはその一部を共有できる、複数の個々のプロセッサによって提供することができる。さらに、「プロセッサ」または「コントローラ」という用語の明示的な使用は、ソフトウェアを実行できるハードウェアを排他的に指すものと解釈するべきではなく、デジタル・シグナル・プロセッサ（ＤＳＰ）ハードウェア、ネットワーク・プロセッサ、特定用途向けＩＣ（ＡＳＩＣ）、フィールド・プログラマブル・ゲートアレイ（ＦＰＧＡ）、ソフトウェアを格納するための読み取り専用メモリ（ＲＯＭ）、ランダム・アクセス・メモリ（ＲＡＭ）、および不揮発性記憶装置を限定することなく、暗黙的に含むことができる。従来型および／またはカスタムの他のハードウェアも含むことができる。

本明細書に示すブロック図は、本発明の原理を具体化する実例となる回路についての概念的な視点を表していることは当業者には自明であろう。同様に、そのようなコンピュータまたはプロセッサが明示的に示されているかどうかに関わりなく、任意のフローチャート、流れ図、状態遷移図、擬似コードなどは、コンピュータ可読媒体において本質的に表され、したがって、コンピュータまたはプロセッサによって実行できる様々なプロセスを表していることを理解されるだろう。

さらに、以下の請求項は、これによって詳細な説明に組み込まれ、各請求項は、それ自体で個別の実施形態として有効である。各請求項が個別の実施形態として有効であるが、特許請求の範囲において、従属請求項は１つまたは複数の他の請求項との特定の組み合わせを言及する場合があるが、他の実施形態は、また、他の各従属請求項の主題との従属請求項の組み合わせを含むことができることに注意されたい。特定の組み合わせを意図しないと述べられていない限り、そのような組み合わせは本明細書で提案されている。さらに、この請求項が独立請求項に直接的に依存しない場合でも、他の独立請求項に請求項の主張の特徴を含めることを意図する。

明細書または特許請求の範囲に開示された方法は、これらの方法のそれぞれのステップのそれぞれを実行するための手段を持つデバイスによって実装できることに注意されたい。

さらに、明細書または請求項で開示された複数のステップまたは機能の開示は、特定の順序であるものと解釈されないことを理解されるだろう。したがって、そのようなステップまたは機能が技術的な理由から交換可能ではない限り、複数のステップまたは機能の開示によって、これらを特定の順序に制限するものではない。さらに、一部の実施形態では、単一のステップは、複数のサブステップを含むことも、または複数のサブステップに分解することもできる。そのようなサブステップは、明示的に除外されていない限り、この単一のステップの開示に含めることができ、またその一部となることができる。

Claims (14)

1. ベースバンド・クラウド・コンピューティング・アーキテクチャを用いるワイヤレス通信ネットワークの第１の無線セル・クラスタに関連する第１のベースバンド信号処理クラスタ（１００）であって、
   前記ワイヤレス通信ネットワークの前記第１の無線セル・クラスタにサービスを提供する第１の複数のラジオ・ヘッドとインターフェース接続されるように構成された複数のベースバンド信号処理ユニット（１１０）であって、関連するベースバンド信号処理ユニット（１１０）内の第１の処理リソース割り当てを管理するように動作可能な少なくとも１つのユニット特有の処理リソース管理エンティティ（１２０）をそれぞれが備える、複数のベースバンド信号処理ユニット（１１０）と、
   前記少なくとも１つのユニット特有の処理リソース管理エンティティ（１２０）のそれぞれに結合され、前記複数のベースバンド信号処理ユニット（１１０）間での第２の処理リソース割り当てを管理するように動作可能なクラスタ内処理リソース管理エンティティ（１３０）と、
   クラスタ内処理リソース管理エンティティ（１３０）に結合された第１のクラスタ間処理リソース管理エンティティ（１４０）であり、前記ワイヤレス通信ネットワークの第２の無線セル・クラスタにサービスを提供する第２の複数のラジオ・ヘッドとインターフェース接続された第２のベースバンド信号処理クラスタと前記第１のベースバンド信号処理クラスタとの間での第３の処理リソース割り当ての管理を達成するために、該第２のベースバンド信号処理クラスタの第２のクラスタ間処理リソース管理エンティティと協同して該第２のクラスタ間処理リソース管理エンティティと情報を交換するように動作可能である、第１のクラスタ間処理リソース管理エンティティ（１４０）と、
   を含む、第１のベースバンド信号処理クラスタ（１００）。
2. 前記クラスタ内処理リソース管理エンティティ（１３０）は、
   前記複数のベースバンド信号処理ユニット（１１０）の前記少なくとも１つのユニット特有の処理リソース管理エンティティ（１２０）から提供されるユニット特有の負荷状態情報（５０２）に基づいて、前記第１のベースバンド信号処理クラスタ（１００）の利用可能なベースバンド信号処理リソースを決定するように動作可能な情報管理エンティティ（１３２）と、
   ユーザ特有のベースバンド信号処理タスクに対する必要な処理リソース容量と前記ユニット特有の負荷状態情報（５０２）との比較に基づいて、前記第１のベースバンド信号処理クラスタ（１００）の１つまたは複数のベースバンド信号処理ユニット（１１０）に、前記ユーザ特有のベースバンド信号処理タスクを割り当てるように動作可能な決定エンティティ（１３４）と、
   を含む、請求項１に記載の第１のベースバンド信号処理クラスタ（１００）。
3. 前記クラスタ内処理リソース管理エンティティ（１３０）は、前記第１のベースバンド信号処理クラスタ（１００）の利用可能な処理リソースが、前記ユーザ特有の特定のベースバンド信号処理要求（５０６）に対して十分でない場合、前記第１のベースバンド信号処理クラスタと前記第２のベースバンド信号処理クラスタとの間での特定の第３の処理リソース割り当てを初期化するために、前記複数のベースバンド信号処理ユニット（１１０）の内の少なくとも一つから前記第１のクラスタ間処理リソース管理エンティティ（１４０）に、ユーザ特有のベースバンド信号処理要求（５０６）を転送するように動作可能である、請求項１に記載の第１のベースバンド信号処理クラスタ（１００）。
4. 前記クラスタ内処理リソース管理エンティティ（１３０）は、前記第２のベースバンド信号処理クラスタのリモート・ベースバンド信号処理ユニットに関連するユーザのユーザ特有のベースバンド信号処理を実行するために十分な利用可能な処理能力を持つ１つまたは複数のベースバンド信号処理ユニット（１１０）の特定の第２の処理リソース割り当てを初期化するために、前記第１のクラスタ間処理リソース管理エンティティ（１４０）を介して、ユーザ特有の特定のベースバンド信号処理要求（６２８）を受信するように動作可能である、請求項１に記載の第１のベースバンド信号処理クラスタ（１００）。
5. 前記クラスタ内処理リソース管理エンティティ（１３０）は、前記第２のベースバンド信号処理クラスタのリモート・ベースバンド信号処理ユニットに関連するユーザのユーザ特有のベースバンド信号処理を実行するために十分な利用可能な処理能力を持つ割り当てられたベースバンド信号処理ユニット（１１０）のネットワーク・アドレス、前記リモート・ベースバンド信号処理ユニットのネットワーク・アドレス、および前記第１のベースバンド信号処理クラスタ（１００）のネットワーク・ルータ（１８０）および／または前記第１のクラスタ間処理リソース管理エンティティ（１４０）の前記ユーザの識別子を提供するように動作可能である、請求項１に記載の第１のベースバンド信号処理クラスタ（１００）。
6. 前記第１のクラスタ間処理リソース管理エンティティ（１４０）は、
   前記第１のベースバンド信号処理クラスタ（１００）の利用可能な処理リソースについての情報にアクセスするように動作可能な情報管理エンティティ（１４２）であって、前記情報は、前記複数のベースバンド信号処理ユニットの内で前記第１のベースバンド信号処理クラスタ（１００）の最大利用可能な処理容量を持つベースバンド信号処理ユニット（１１０）についての情報を含む情報管理エンティティ（１４２）と、
   前記第１のベースバンド信号処理クラスタ（１００）の利用可能な処理リソースが前記ユーザ特有のベースバンド信号処理要求（５０６；５０８）に十分でない場合、前記利用可能な処理リソース（５０４）についての情報に基づいて、前記第１のベースバンド信号処理クラスタ（１００）からユーザ特有のベースバンド信号処理要求（５０６；５０８）により利用可能な十分な処理リソースを持つリモート・ベースバンド信号処理クラスタを決定するように動作可能な決定エンティティ（１４４）と、
   を含む、請求項１に記載の第１のベースバンド信号処理クラスタ（１００）。
7. 前記第１のクラスタ間処理リソース管理エンティティ（１４０）は、前記第２のリモート・ベースバンド信号処理クラスタからの受信されたユーザ特有のベースバンド信号処理要求（６１８）に応じて、前記第１のベースバンド信号処理クラスタ（１００）の利用可能な処理リソースの情報（６２０）にアクセスし、十分な利用可能な処理リソースの場合には前記受信されたユーザ特有のベースバンド信号処理要求（６１８）を肯定し（６４２）、またはそうでない場合は、前記受信されたユーザ特有のベースバンド信号処理要求（６１８）を拒否するように動作可能である、請求項１に記載の第１のベースバンド信号処理クラスタ（１００）。
8. 前記第１のクラスタ間処理リソース管理エンティティ（１４０）は、オリジナル無線ベアラ要求（５０６）のサービスの品質パラメータから得た関連する処理容量記述とともに前記第２のリモート・ベースバンド信号処理クラスタから、前記第１のベースバンド信号処理クラスタ（１００）の前記クラスタ内処理リソース管理エンティティ（１３０）に、受信されたユーザ特有のベースバンド信号処理要求（６１８）を転送する（６２８）ように動作可能である、請求項１に記載の第１のベースバンド信号処理クラスタ（１００）。
9. 前記第１のクラスタ間処理リソース管理エンティティ（１４０）は、前記ベースバンド信号処理クラスタ（１００）と、前記少なくとも１つのリモート・ベースバンド信号処理クラスタとの間の信号伝播遅延を決定するために時間遅延測定（６１２）を開始するように動作可能である、請求項１に記載の第１のベースバンド信号処理クラスタ（１００）。
10. 前記第１のクラスタ間処理リソース管理エンティティ（１４０）は、前記時間遅延測定（６１２）に応じて、可能な隣接として適切なリモート・ベースバンド信号処理クラスタの隣接リストを更新する（６１６）ように動作可能であり、最大の許可された時間遅延を下回るリモート処理の信号伝播遅延につながる、請求項９に記載の第１のベースバンド信号処理クラスタ（１００）。
11. 前記第１のクラスタ間処理リソース管理エンティティ（１４０）は、前記第１のベースバンド信号処理クラスタ（１００）から、前記更新された隣接リストの潜在的な前記リモート・ベースバンド信号処理クラスタのすべてのリモート・クラスタ間処理リソース管理エンティティに、ユーザ特有のベースバンド信号処理要求（５０６；５０８）を転送する（６１８）ように動作可能である、請求項１０に記載の第１のベースバンド信号処理クラスタ（１００）。
12. 前記第１のクラスタ間処理リソース管理エンティティ（１４０）は、無線ベアラ要求（５０６）に関係するリモート処理について、前記第２のベースバンド信号処理クラスタを含む他のベースバンド信号処理クラスタからリモート・ベースバンド信号処理クラスタを選択するように動作可能であり、選択された該リモート・ベースバンド信号処理クラスタは、前記第１のクラスタ間処理リソース管理エンティティ（１４０）から転送された処理リソース要求（６１８）を肯定するためのリモート・ベースバンド信号処理クラスタであり、または前記第１のクラスタ間処理リソース管理エンティティ（１４０）は、前記最大の利用可能な処理能力を示す、リモート・ベースバンド信号処理クラスタを選択するように動作可能である、請求項１に記載の第１のベースバンド信号処理クラスタ（１００）。
13. 前記第１のクラスタ間処理リソース管理エンティティ（１４０）は、前記ユーザに関連する無線ベアラ・データのリモート処理のために、ベースバンド信号処理ユニット（１１０）のネットワーク・アドレス、および前記ベースバンド信号処理ユニット（１１０）の少なくとも１つのリモート・ラジオ・ヘッドに関連するユーザの識別子を選択されたリモート・ベースバンド信号処理クラスタに転送するように動作可能である、請求項１に記載の第１のベースバンド信号処理クラスタ（１００）。
14. 前記第１のクラスタ間処理リソース管理エンティティ（１４０）は、前記第２のリモート・ベースバンド信号処理クラスタのリモート・ベースバンド信号処理ユニットに関連するユーザのユーザ特有のベースバンド信号処理を実行するために十分な利用可能な処理能力を持つ少なくとも１つのベースバンド信号処理ユニット（１１０）の割り当てを初期化するために、該第２のリモート・ベースバンド信号処理クラスタから受信されたユーザ特有のベースバンド信号処理要求（６２８）を前記クラスタ内処理リソース管理エンティティ（１３０）に転送するように動作可能であり、前記ユーザ特有のベースバンド信号処理要求（６２８）は、前記リモート・ベースバンド信号処理ユニットのネットワーク・アドレスおよび前記ユーザの識別子を含む、請求項１に記載の第１のベースバンド信号処理クラスタ（１００）。

Images