(57)【特許請求の範囲】
【請求項１】
方法であって、
アップリンク接続でユーザ装置のためのリソースブロック負荷を計算することであって、前記リソースブロック負荷が、前記ユーザ装置のための待ち行列サイズを設定し、前記ユーザ装置の変調符号化方式のためのリソースブロックの数を電力レベルから決定し、前記変調符号化方式のためのリソースブロックの数を使用して前記待ち行列サイズに対するリソースブロックの数を決定することによって計算され、かつリソースブロックが未割り当ての他のユーザ装置に対して同じ計算を行うことによって計算される、前記リソースブロック負荷を計算すること、
前記ユーザ装置のための前記計算されたリソースブロック負荷に基づいて利用可能なリソースブロックを割り当てること、
を含む方法。
【請求項２】
前記変調符号化方式のためのリソースブロックの数が、リソースブロックのための最大電力および前記ユーザ装置の経路損失に応じたリソースブロックの電力を使用して決定される、請求項１に記載の方法。
【請求項３】
前記変調符号化方式のためのリソースブロックの数が、リソースブロック毎の前記電力を維持するリソースブロックの数である、請求項１に記載の方法。
【請求項４】
アップリンクチャネルのスペクトル効率を最大限にするためのリソースブロック目標の数を設定することをさらに含む、請求項１に記載の方法。
【請求項５】
アップリンクチャネル上の利用可能なリソースブロックの数を決定すること、
前記アップリンクチャネル上の、近接する未割り当ての数のリソースブロックの最大数を決定すること、
前記アップリンクチャネル上の少なくとも１つのユーザ装置のための前記アップリンクチャネルのリソースブロック負荷を計算することであって、前記リソースブロック負荷が、前記ユーザ装置のための待ち行列においてビットを使い尽くすために必要とされる前記リソースブロックと、前記アップリンクチャネル上の前記ユーザ装置のための前記近接する未割り当ての数のリソースブロックの最大数とのうちの小さい方の合計である、前記リソースブロック負荷を計算すること、
前記リソースブロック負荷が利用可能なリソースブロックの数以上であるときに、前記ユーザ装置のための前記待ち行列における前記リソースブロックと前記近接する未割り当ての数のリソースブロックの最大数とのうちの小さい方を割り当てること、
前記リソースブロック負荷が利用可能なリソースブロックの数未満であるときに、前記近接する未割り当ての数のリソースブロックの最大数の全体で待ち行列におけるリソースブロックの数を割り当てること
をさらに含む、請求項１に記載の方法。
【請求項６】
方法であって、
アップリンクチャネル上の利用可能なリソースブロックの数を決定すること、
前記アップリンクチャネル上の近接する未割り当ての数のリソースブロックの最大数を決定すること、
前記アップリンクチャネル上の少なくとも１つのユーザ装置のために前記アップリンクチャネルのリソースブロック負荷を計算することであって、前記リソースブロック負荷が、前記ユーザ装置のための待ち行列におけるリソースブロックと、前記アップリンクチャネル上の前記ユーザ装置のための前記近接する未割り当ての数のリソースブロックの最大数とのうちの小さい方の合計である、前記リソースブロック負荷を計算すること、
前記リソースブロック負荷に基づいて前記ユーザ装置が重負荷であるか、または低負荷であるかを判定すること、
前記ユーザ装置が重負荷であると判定されたときに、前記ユーザ装置のための待ち行列におけるリソースブロックと、前記近接する未割り当ての数のリソースブロックの最大数とのうちの小さい方を割り当てること、
前記ユーザ装置が低負荷であると判定されたときに、前記近接する未割り当ての数のリソースブロックの最大数の全体で待ち行列におけるリソースブロックの数を割り当てること、
を含む方法。
【請求項７】
アップリンク接続でユーザ装置のためにリソースブロック負荷を計算することをさらに含み、前記リソースブロック負荷が、前記ユーザ装置のための待ち行列サイズを設定し、前記ユーザ装置の変調符号化方式のためのリソースブロックの数を電力レベルから決定し、前記変調符号化方式のための前記リソースブロックの数を使用して前記待ち行列サイズに対するリソースブロックの数を決定することによって計算される、請求項６に記載の方法。
【請求項８】
前記ユーザ装置のために前記計算されたリソースブロック負荷に基づいて利用可能なリソースブロックを割り当てることをさらに含む、請求項６に記載の方法。
【請求項９】
前記割り当てられた数のリソースブロックに利用可能な前記アップリンク上の最小セットの近接するリソースブロックをサーチすることをさらに含む、請求項６に記載の方法。
【請求項１０】
前記待ち行列におけるリソースブロックの数を決定することが、送信ブロックサイズとリソースブロックサイズの組の全ての実現可能な組の中で前記ユーザ装置の待ち行列サイズに対応するリソースブロックの最小数を決定することを含む、請求項６に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概して無線通信ネットワークにおいてリソースブロックを割り当てることに関し、詳細には、直交周波数分割多重（ＯＦＤＭ）無線通信ネットワークのアップリンクでのリソースブロックのスケジューリングおよびリソース割り当ての方法に関する。
【背景技術】
【０００２】
ＯＦＤＭ無線通信ネットワークでは、移動局、またはユーザ装置は、ネットワーク内のスタンドアロン装置であるか、または別のネットワークエンティティの一部であるアップリンクスケジューラを使用して、いくつかの異なる因子を用いるアップリンク上でスケジュールされる。これらの要素は、アップリンク上でユーザ装置が利用可能な電力、ユーザ装置の経路損失、利用可能なリソースブロック数、およびセルサイトで測定される雑音および干渉を含む。スケジューラは、どの移動局またはユーザ装置が次にアップリンクにスケジュールされるのかを決定する。スケジューラは、次いで、どのリソースブロックが移動局に割り当てられことになるのか、どの変調符号化方式が使用されるのか、およびリソースブロックごとの電力はどのくらいになるのかを決定する。 
【０００３】
各種の無線通信システムの規格が、アップリンク上でリソースブロックを割り当てるために多様なスケジューリング技法を使用している。一実施形態では、変調符号化方式（ＭＣＳ）およびリソースブロック毎の電力が一定に保たれる。これは高いスペクトル効率（ビット／リソースブロック）を提供できるが、いくつかのケースでは、システムが低負荷であるとリソースの無駄を引き起こし得る。別の実施形態では、各ユーザ装置はその最も低いＭＣＳでスケジュールすることができる。これは、最大送信電力で多数のリソースをユーザ装置毎に割り当てることができることを暗示する。つまり、低負荷でリソースが無駄にされない状態での低スペクトル効率を意味する。したがって、最適の動作が達成されるように上記の手法を組み合わせた、リソースを割り当てるスケジューラに対するニーズがある。
【図面の簡単な説明】
【０００４】
【図１】本発明のいくつかの実施形態に説明される原理を活用し、その実施形態による無線通信システム例である。
【図２】アップリンクスケジューリングのフロー図である。
【図３】本発明の実施形態に係るリソースブロック負荷の計算のフロー図である。
【図４】本発明の実施形態に係るリソースブロックの割り当てのフロー図である。
【図５】本発明の実施形態に係る変調符号化方式のためのリソースブロック数を決定するために使用する送信ブロックサイズ表の図である。
【発明を実施するための形態】
【０００５】
添付の図では、類似する参照番号は、別々の図を通して同一のまたは機能上類似した要素を指している。また、下記の発明を実施するための形態とともに本明細書に組み込まれ、本明細書の一部を形成する。さらに本添付の図は、多様な実施形態を示し、すべて本発明に係る多様な原理および優位点を説明するために役立つ。当業者は、図中の要素は、簡単および明瞭に説明するために示されており、必ずしも原寸に比例して描かれていないことを理解する。例えば、図中の要素のうちのいくつかの寸法は、本発明の実施形態の理解を高めるために役立つように他の要素に対して誇張されている場合もある。
【０００６】
本発明に係る実施形態を詳しく説明する前に、実施形態がおもに無線通信ネットワークにおいてリソースブロックを割り当てるために関連する方法ステップおよび装置構成要素の組み合わせにあることに留意されたい。したがって、装置構成要素および方法ステップは、適切な場合には、図面中で従来の記号によって表され、本明細書の説明の利点を有する当業者にとって容易に明らかになるであろう詳細で本開示を分かりにくくしないように、本発明の実施形態の理解に関するそれらの特定の詳細だけを示す。
【０００７】
本書では、第１のおよび第２の、上部および下部等の関係語は、あるエンティティまたはアクションを別のエンティティまたはアクションと区別するためだけに使用され、かかるエンティティまたはアクションの間のかかるどのような実際の関係性または順序も必ずしも要求または暗示しない場合もある。用語「含む」、「含んでいる」またはそのどのような他の変形物も、非排他的包含を対象とすることを意図しており、したがって要素のリストを含むプロセス、方法、製品、または装置は、それらの要素だけを含むのではなく、かかるプロセス、方法、製品、または装置に明示的に示されているまたはそれらに固有の他の要素を含み得る。「含む」の前に来る要素は、より多くの制限なしに、その要素を含むプロセス、方法、製品、または装置うちの追加の同一の諸要素の存在を排除しない。
【０００８】
本明細書に説明される本発明の実施形態は、１台または複数の従来のプロセッサ、およびその１台または複数のプロセッサを制御し、本明細書で説明される無線通信ネットワーク内でリソースブロックを割り当てる機能のいくつか、大多数またはすべてを、特定の非プロセッサ回路と連動して具体化される一意の記憶されているプログラム命令から構成されることがあることが理解される。非プロセッサ回路は、無線受信機、無線送信機、信号ドライバ、クロック回路、電源回路、およびユーザ入力装置を含むことがあるが、これらに限定されない。このように、これらの機能はリソースブロック割り当てを実行するための方法のステップとして解釈し得る。別法として、いくつかの機能またはすべての機能は、記憶されたプログラム命令を有さないステートマシンによって、もしくは各機能または特定の機能の組み合わせのいくつかがカスタム論理回路として具体化される１つまたは複数の特定用途向け集積回路（ＡＳＩＣ）において具体化できるだろう。言うまでもなく、２つの手法の組み合わせも使用できるだろう。したがって、これらの機能のための方法および手段が、本明細書に説明されている。さらに、おそらくは多大な努力、ならびに本明細書に開示される概念および原理によって導かれるときの、例えば利用可能時間、現在の技術、および経済的な検討事項を動機とする多くの設計の選択肢にも関わらず、当業者が最小の実験でかかるソフトウェア命令およびソフトウェアプログラムならびにＩＣを容易に生成できることが期待される。
【０００９】
ある実施形態では、アップリンク接続時にユーザ装置のためにリソースブロック負荷を計算する方法が実行される。リソースブロック負荷は、ユーザ装置のための待ち行列サイズを設定し、ユーザ装置の変調符号化方式のためのリソースブロック数を電力レベルから決定し、変調符号化方式のためのリソースブロック数を使用して待ち行列サイズに対するリソースブロック数を決定することによって計算される。さらに、方法は、ユーザ装置のための計算されたリソースブロック負荷を割り当てることも含む。
【００１０】
別の実施形態では、方法は、リソースブロックを割り当てる。この方法は、アップリンクチャネル上で利用可能なリソースブロック数を決定すること、およびアップリンクチャネル上の近接する未割り当てのリソースブロックの最大数を決定することを含む。さらに、方法は、アップリンクチャネル上の少なくとも１つのユーザ装置のアップリンクチャネルのリソースブロック負荷を計算することを含み、リソースブロック負荷は、ユーザ装置のための待ち行列におけるリソースブロックと、アップリンクチャネル上のユーザ装置のための近接する未割り当てのリソースブロックの最大数とのうちの小さい方の合計である。この負荷の決定に基づき、リソースブロック割り当ては、重負荷があるのか、それとも低負荷があるのかに応じて行われる。また、方法は、リソースブロック負荷が利用可能なリソースブロック数以上であるときに、ユーザ装置のための待ち行列におけるリソースブロックと、近接する未割り当てのリソースブロックの最大数とのうちの小さい方を割り当てることも含む。重負荷状況下での待ち行列におけるリソースブロック数は、以下に定義されるようにＮＭＣSおよびＮＱの最小値である。さらに、方法は、リソースブロック負荷が利用可能なリソースブロック数未満であるときに、近接する未割り当ての数のリソースブロックの最大数の全体で待ち行列におけるリソースブロックの数を割り当てることを含む。したがって、低負荷状況では、以下に定められるように、待ち行列におけるリソースブロックは、ＮＱＬＬおよびＮＴＢＳの最小値であり、高負荷状況での値とは異なる値である。
【００１１】
本発明は、図を参照するとより完全に理解され得る。図１は、本発明の実施形態に係る無線通信システム１００のブロック図である。通信システム１００は、無線通信のために装備される、セル式電話、無線電話、スマートフォン、パーソナルデジタルアシスタント（ＰＤＡ）、パーソナルコンピュータ（ＰＣ）、またはラップトップコンピュータ等のユーザ装置（ＵＥ）１２０を含むが、これらに限定されない。通信システム１００は、無線リンクを介して無線アクセスネットワーク（ＲＡＮ）のカバレージエリア内に常駐するＵＥ１２０等のユーザ装置に通信サービスを提供する基地局（ＢＳ）１１０をさらに含む。無線リンクは、アップリンク１３０およびダウンリンク（不図示）を含み、アップリンク１３０およびダウンリンクのそれぞれが、複数のトラフィックチャネルおよび複数の信号チャネルを含む複数の物理通信チャネルおよび論理通信チャネルを含む。アップリンク１３０のための複数のチャネルは、物理アップリンク制御チャネル（ＰＵＣＣＨ：Ｐｈｙｓｉｃａｌ  Ｕｐｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ）および物理アップリンク共有チャネル（ＰＵＳＣＨ：Ｐｈｙｓｉｃａｌ  Ｕｐｌｉｎｋ  Ｓｈａｒｅｄ  Ｃｈａｎｎｅｌ）を含む。
【００１２】
ＢＳ１１０およびＵＥ１２０のそれぞれは、１台または複数のマイクロプロセッサ、マイクロコントローラ、デジタル信号プロセッサ（ＤＳＰ）、その組み合わせ等の、プロセッサ１１２、１２２または当業者にとって既知のかかる他の装置を含み、プロセッサはそれぞれＢＳおよびＵＥによって実行されているとして本明細書中で説明される機能を実行するように構成される。ＢＳ１１０およびＵＥ１２０は関連するプロセッサによって実行され得、ＢＳおよびＵＥが通信システム１００内で動作するために必要な全機能を実行できるようにするデータおよびプログラムを保持する、ランダムアクセスメモリ（ＲＡＭ）、ダイナミックＲＡＭ（ＤＲＡＭ）、および／または読み出し専用記憶装置（ＲＯＭ）もしくはその同等物を含み得るそれぞれ少なくとも１つの記憶装置１１４、１２４をそれぞれ、さらに含む。また、ＢＳ１１０およびＵＥ１２０のそれぞれは、無線リンク１３０で信号を送信するためのそれぞれの無線周波数（ＲＦ）送信機１１８、１２８、および無線リンク１３０を介して信号を受信するためのＲＦ受信機１１６、１２６もそれぞれ含む。送信機１１８、１２８、および受信機１１６、１２６は、多くの場合、集合的にトランシーバと呼ばれる。
【００１３】
通信システム１００は、ＢＳ１１０に連結され、本明細書に説明されるスケジューリング機能を実行するスケジューラ１０２をさらに含む。スケジューラ１０２は、１台または複数のマイクロプロセッサ、マイクロコントローラ、デジタルシグナルプロセッサ（ＤＳＰ）、それらの組み合わせ、または当業者に既知のかかる他の装置等のプロセッサ１０４を含む。このプロセッサ１０４は、スケジューラによって実行されるとして本明細書中で説明される機能を実行するように構成される。スケジューラ１０２は、関連するプロセッサによって実行され得るデータおよびプログラムを保持し、スケジューラが通信システム１００内で動作するために必要な全機能を実行できるようにする少なくとも１つの記憶装置１０６をさらに含む。この記憶装置１０６は、ランダムアクセスメモリ（ＲＡＭ）、ダイナミックＲＡＭ（ＤＲＡＭ）、および／または読み出し専用記憶装置（ＲＯＭ）もしくはその同等物を含む場合もある。スケジューラ１０２は、ＢＳ１１０とは別個の要素として示されているが、本発明の他の実施形態では、スケジューラ１０２は、ＢＳ内に具体化されてもよく、さらに詳細には、ＢＳに含まれる少なくとも１つの記憶装置１１４によって保持されるプログラムに基づいて、ＢＳのプロセッサ１１２によって実施されてよい。
【００１４】
スケジューラ１０２、ＢＳ１１０、およびＵＥ１２０によって実行されるとして本明細書中に説明される機能性は、スケジューラ、ＢＳ、およびＵＥと関連づけられた各少なくとも１つの記憶装置１０６、１１４、１２４に記憶され、スケジューラ、ＢＳ、およびＵＥと関連づけられたプロセッサ１０４、１１２、１２２によって実行されるソフトウェアプログラムおよび命令により実施されるか、またはかかるソフトウェアプログラムおよび命令において具体化される。しかしながら、当業者には、本発明の実施形態が、ハードウェア、例えば、スケジューラ、ＢＳ、およびＵＥのうちの１つまたは複数に具体化される特定用途向け集積回路（ＡＳＩＣ）等の、集積回路（ＩＣ）、ＡＳＩＣ等に具体化され得ることが理解される。本開示に基づき、当業者は、やり直すことなく、かかるソフトウェアおよび／またはハードウェアを容易に作成し、具体化することができるだろう。
【００１５】
ＢＳ１１０およびＵＥ１２０が通信セッションに従事する際には、ＢＳ１１０およびＵＥ１２０は、それぞれ既知の無線電気通信規格に従って動作する。好ましくは、通信システム１００は、３ＧＰＰ、ＬＴＥ（第三世代携帯電話標準仕様策定プロジェクトのロングタームエボリューション：Ｔｈｉｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ  Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）規格に従って動作する３ＧＰＰ、ＬＴＥ通信システムである。互換性を保証するために、無線システムパラメータおよび呼処理手順は、かかる規格によって指定され、ＢＳおよびＵＥによって実行される呼処理ステップを含む。しかしながら、当業者は、通信システム１００が、３ＧＰＰ、ＵＭＴＳ（ユニバーサル・モバイル・テレコミュニケーションシステム：Ｕｎｉｖｅｒｓａｌ  Ｍｏｂｉｌｅ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｓｙｓｔｅｍ）通信システム、ＣＤＭＡ（符号分割多重接続）通信システム、ＣＤＭＡ２０００通信システム、周波数分割多重接続（ＦＤＭＡ）通信システム、時分割多重接続（ＴＤＭＡ）通信システム、もしくはワイマックス（ＷｉＭＡＸ）通信システムなど、多様なＯＦＤＭ技術のうちの任意の１つに従って動作する通信システム、または例えば８０２．１１規格、８０２．１５規格、８０２．１６規格、８０２．２０規格等のＩＥＥＥ（電気電子技術者協会）８０２．ｘｘ規格のうちのどれか１つに従って動作する通信システム等の、無線リンクリソースを割り当てる任意の無線通信システムであってよいことを理解している。
【００１６】
図２を参照すると、ＯＦＤＭ内でのアップリンクのためのスケジューリングおよびリソース割り当てを説明するフローチャート２００が示されている。特に、フローチャート２００は、本明細書に説明されるプロセスおよび手順に従って割り当てられるユーザ装置の決定を示す。図示されているプロセスはスケジューラ１０２に関して説明されるが、スケジューラ１０２がアップリンクチャネル、つまりＰＵＳＣＨのためのリソースブロックを割り当てる際には、説明されるステップおよび手順のいくつかが、ＲＡＮの内部の他のエンティティおよびスケジューラ１０２に提供される関連データおよび情報によって実行され得ることは理解されよう。まず、アップリンクスケジューリングは、チャネル１３０にスケジュールされる、チャネルのおよびユーザ装置の雑音値および干渉値を計算すること（２０２）によって開始する。ユーザ装置の適格なセットが定義され（２０４）、ユーザ装置の適格なセットの各メンバは、ゼロより大きい待ち行列サイズを有し、それによってユーザ装置がチャネルの使用を必要とすることを指定する。さらに、ユーザ装置の適格なセットは、なんらかの理由からアップリンクチャネル１３０でのデータの再送を必要とするすべてのユーザ装置を含む。再送を必要とするユーザ装置には、他のユーザ装置の割り当てに優る優先順位が与えられる。したがって、再送を必要とするユーザ装置のために、リソースブロックを含むリソースが確保される（２０８）。特定のケースでは、新たな送信中に使用される同じセットのリソースブロックが現在のサブフレームでは使用できないために、割り当てが優先されていても再送がブロックされることがある。かかるケースでは、ブロックされた再送は以前に未割り当てのユーザ装置の送信とともに配置される。
【００１７】
新しい送信およびブロックされた再送について、チャネル測定値が計算される（２０８）。これらのチャネル測定値は、経路損失推定値、受信信号対雑音干渉比（ＳＩＮＲ）推定値、ＳＩＮＲ補正値、リソースブロックあたりのスループット、フィルタスループット、および比例公平（ＰＦ）メトリック計算を含むことができる。他の測定および計算も決定できる。これらの測定基準を使用すると、スケジュールされ、割り当てられることになるユーザ装置は、最初にブロックのために再送を必要とするユーザ装置をリストし、次いでＰＦ測定基準に従った降順でリストすることによって並べ替えられる（２１０）。並べ替えられた各ユーザ装置について、物理下り制御チャネル（ＰＤＣＣＨ：Ｐｈｙｓｉｃａｌ  Ｄｏｗｎｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ）ハッシュが計算される（２１２）。次いで、ＰＤＣＣＨハッシュが計算されたユーザ装置に対してリソースブロックの割り当ておよびスケジューリングを行うことができる（２１４）。プロセスは、ステップ２１６で終了する。
【００１８】
リソースブロック割り当ておよびスケジューリングの一部として、リソースブロック負荷が必要とされる。リソースブロック負荷は、ステップ２１６を通過したすべての適格なユーザ装置（つまり、ＰＤＣＣＨハッシュが計算されたすべての適格なユーザ装置）のリソースブロック負荷の合計として計算される。図３は、２１６を通過したユーザ装置のリソースブロック負荷を計算することを説明するフローチャート３００を示す。
【００１９】
ステップ２１６を通過した各ユーザ装置について、変調符号化方式（ＭＣＳ）インデックスが決定される（３０４）。ＭＣＳインデックスは、上述されたＳＩＮＲ計算、および通信規格に従って提供されるＳＮＲ表からＭＣＳ表までを使用して決定される。ＭＣＳインデックスから、送信ブロックサイズインデックス（ＴＢＳ）Ｔが、通信規格に従って提供される表を使用して決定される（３０６）。二次元配列は、ＴＢＳを第１の次元として、リソース数を第２の次元として決定される。かかる二次元配列の例は、図５に示され、以下にさらに詳細に説明される。
【００２０】
リソースブロック数が次いで決定される（３１０）。実施形態では、ユーザ装置に対する待ち行列サイズＱが決定される。ＮＭＣＳは、リソースブロック毎の電力ＷＲＢを、そのユーザ装置に割り当てられるすべてのリソースブロックについて維持できるリソースブロックの数である。理解されるように、ＷＲＢは、リソースブロック毎の送信電力をとりわけユーザ装置の経路損失の関数として特定する通信ネットワーク規格の一部であるフラクショナル電力制御規則（Ｆｒａｃｔｉｏｎａｌ  Ｐｏｗｅｒ  Ｃｏｎｔｒｏｌ  Ｒｕｌｅ）から取得される。さらに、ユーザ装置待ち行列サイズＱを使い果たすことがあるリソースブロック数ＮＱが決定される。数ＮＭＣＳは、利用可能なリソースブロックの電力を超えるユーザ装置の最大送信電力ＰＭＡＸの下限を計算することによって計算される。指摘されるように、ＮＭＣＳは、ユーザ装置が、リソースブロック毎の送信電力をＷＲＢに保ち、且つＰＭＡＸ未満の総送信電力も有する一方で、ユーザ装置が使用することができるリソースの最大数を表す。ＮＱは、最大限でＮＭＣＳに等しくなるリソースブロック数である。ＮＱは、ユーザがその待ち行列サイズＱを使い果たすために必要とするリソースブロック数として定義でき、リソースブロック数は所定の値ＮＭＣＳを超えることができないという制限がある。正式には、ＮＱは、１以上でＮＭＣＳ以下であるリソースブロックの最小値ｊと、待ち行列サイズＱ以上であるリソースブロックｊのＴＢＳ値Ｔとから決定される。実施形態では、ＮＭＣＳのためのＴＢＳ値ＴがＱ未満である場合には、ＮＱはＮＭＣＳに等しい。
【００２１】
ＮＭＣＳおよびＮＱを提供するこれらの方法は、チャネルのＦＰＣスペクトル効率を最大限にするためにリソースブロックの目標数を設定する方法を提供する。したがって、リソースブロック数ＮＭＣＳは、リソースブロックの目標数として設定できる。通常、アルゴリズムは、値ＮＭＣＳを超えるより多くのリソースブロックを割り当て、より多くのビットを送信しようと模索する。これは、より少ない数のビットがリソースブロック毎に送信されるので、スペクトル的に非効率であると判断されてきた。リソースブロック数をＮＭＣＳ以下に設定すると、リソースブロック毎の送信電力即ち、ＭＣＳが一定に保たれるので、リソースブロック毎に割り当てられるリソースビットの数は一定となる。リソースブロック数がＮＭＣＳよりも大きいとき、リソースブロック毎に割り当てられるリソースビット数は、リソースブロック毎の送信電力の減少のために減少し始め、これがより低いスペクトル効率、つまりビット／Ｈｚにつながる。アップリンクでの負荷が増加するにつれ、アップリンク上での総帯域幅を最適化するためにはより高いスペクトル効率が所望される。
【００２２】
まだリソースが未割り当てのユーザ装置のそれぞれのリソースブロック負荷により、残りの利用可能なリソースブロックを割り当てることが可能である。図４は、並べ替えられた待ち行列においてユーザ装置にリソースブロックを割り当てることを説明するフローチャート４００を示す。プロセスは、割り当てられることになる次のユーザ装置をＰＦ測定基準に従って降順でリストから選択することによって開始する（４０２）。ＰＦ測定基準が１つの考えられる測定基準であり、他の測定基準も説明される原理の枠組みの中にあることに留意されたい。さらに、ＰＵＳＣＨで割り当てのために利用可能であるリソースブロック数ＮＡＶＬが決定される（４０４）。利用可能なリソースブロックがない場合、処理は停止される（４０６）。それ以外の場合、ＰＵＳＣＨ上の近接する未割り当てのリソースブロックの最大数ＮＲＢ＿ＭＡＸが決定される（４０８）。さらに、まだリソースが割り当てられていなかった全てのユーザ装置のリソースブロック負荷ＲＢＬＯＡＤが決定される。ＲＢＬＯＡＤは、それらの全てのユーザ装置についてのＮＱおよびＮＲＢ＿ＭＡＸのうちの小さい方を合計することによって決定される（４１０）。その際、ＮＱは図３に示されるように演算される。ＲＢＬＯＡＤは、唯一の制限がＮＲＢ＿ＭＡＸだけであったならば、待ち行列における未決の未割り当てのユーザ装置が占有できるリソースブロック数の基準である。
【００２３】
次のステップで、ＲＢＬＯＡＤは、アップリンクチャネルの負荷を考慮するためにＮＡＶＬと比較される（４１２）。ここで、ＮＡＶＬはユーザ装置のリソース割り当てに利用可能なリソースブロックの総数である。ＲＢＬＯＡＤがＮＡＶＬよりも大きい場合、利用可能であるよりも多くのリソースブロックを充填するため、アップリンクチャネルおよびユーザ装置は、重負荷状態にあると見なされる。重負荷状態では、割り当てられるリソースブロック数であるＮＲＢ＊は、ＮＱおよびＮＲＢ＿ＭＡＸのうちの小さい方であると見なされる。したがって、重負荷状態では、割り当てられているユーザ装置に提供されるリソースブロック数は、スペクトル的に効率的なリソースブロック割り当てに基づいており、リソースブロック毎の電力は、利用可能な近接するリソースブロックの最大数ＮＲＢ＿ＭＡＸを条件に、フラクショナル電力制御規則に従って最大限にされる。これは、利用可能なリソースブロック数ＮＲＢ＿ＭＡＸ、または必要とされるリソースブロック数ＮＱのどちらかである。
【００２４】
低負荷状況では、未決のユーザ装置は、利用可能なリソースブロック総数よりも少ないリソースブロックを必要としている。どのくらいの数のリソースブロックが必要とされるのか、また、リソースブロックのそれぞれに割り当てられる電力が決定される。そのために、すべての実現可能なリソースブロックの中でＴＢＳを最大限にするリソースブロック数ＮＴＢＳの数が決定される。実現可能なリソースブロックは、ユーザ装置に対する目標ＳＩＮＲよりも大きい推定ＳＩＮＲを有するすべてのそれらのリソースブロックである。さらに、ＴＢＳに対するすべての利用可能なリソースブロックの中でユーザ装置の待ち行列サイズに対応できるリソースブロックの最小数ＮＱＬＬが決定される。換言すると、目標ＳＩＮＲよりも大きい推定ＳＩＮＲを有するリソースブロックの数が決定される。したがって、低負荷状況での割り当てでは、最大ＴＢＳと同等となるまでなど、リソースブロックの数を増加することによって割り当てられるリソースブロック数をサーチし続ける。低負荷状況では、ＮＲＢ＊は、決定されたＮＱＬＬおよびＮＲＢ＿ＭＡＸのうちの小さい方に決定される。
【００２５】
電力は、次いで、この数のリソースブロック全体で拡散され、したがって、一定の電力がリソースブロック全体で維持できる。また、これはこのユーザ装置から送信できるビット総数の最大数  ＴＢＳに達するために可能な限り多くのリソースを提供する。さらに、リソースブロック数はＮＭＣＳを超えて増加するが、ユーザ装置のＳＮＲは減少する。これによって、ＭＣＳレベルは低下するが、ユーザ装置によって必要とされる最小ＭＣＳレベル以下には低下しない。最小ＭＣＳレベルに達すると、リソース数はそれ以上は増加されない。したがって、容量は帯域幅に線形比例し、ＳＮＲには対数的に比例するため、低負荷状況ではさらに多くの帯域幅がユーザ装置に提供される。これらの状態では、ユーザ装置での固定された送信電力予算を仮定して、ＳＮＲに比較して帯域幅を最大限にすることがよりよいと決定される。したがって、送信可能なビット数（ＴＢＳ）が増加する限り、同じ量の総電力を使用して、リソースブロック数はＮＭＣＳを超えて増加できると判定される。
【００２６】
重負荷状況または低負荷状況のどちらかでＮＲＢ＊が決定された後、プロセスは、割り当てられるリソースブロックをサーチする（４１４）。プロセスは、ＮＲＢ＊よりも大きい、アップリンクチャネルにおいて利用可能な近接リソースブロックの最小セットをサーチする。リソースブロックがユーザ装置に割り当てられた後、そのユーザ装置はリストから削除される（４１６）。セットが空である場合、プロセスは停止する（４１８）。それ以外の場合、次のユーザ装置が選択され、割り当てプロセスは説明されたように続行する。
【００２７】
図５は、アップリンクで割り当てられるリソースブロック数を決定するために使用されるＴＢＳ表５００の図である。横軸では、リソースブロック数ｊが示される。縦軸では、リソースブロックとＭＣＳの組のＴＢＳ  Ｔが示される。推定ＳＩＮＲは、ユーザ装置の目標ＳＩＮＲ未満であるため、特定の組［ｔ］［ｊ］は検討に利用できないことが理解される。これらの正方形には陰影が付けられている。決定された値は、ＮＭＣＳおよびＮＱＬＬを含み横軸に示されている。陰影領域に接している正方形は、それぞれ、対応する数のリソースブロックのＴＢＳインデックスを最大限にするための候補であることが留意される。正方形５０２は、重負荷状況での最高の実現可能ＴＢＳインデックスＴで考えられるリソースブロック最大数  ＮＭＣＳに相当する。したがって、待ち行列のサイズが制限ではない場合、ＮＲＢ＊はＮＭＣＳに等しくなり、それ以外の場合、スケジューラはリソースを無駄にしないので、待ち行列サイズはＮＭＣＳよりも小さくなるようにリソース数を決定できる。低負荷状況では、リソースブロックサイズは、Ｔ“およびＴ‘を考慮することによってＮＭＣＳを越えて増加することができる。正方形５０６は、同じ総ＵＥ電力のための最大ＴＢＳサイズに相当する。正方形５０４は、アップリンクチャネルのための待ち行列サイズを使い果たすリソースブロックの最小数に相当する。
【００２８】
実施形態では、コードは、図５に示される原理を使用して最適化できる。低負荷状況では、ＴＢＳ  Ｔ毎に割り当てることができるリソースブロック最大数は、リソースブロック５０２から５０８の数、および推定ＳＩＮＲが目標ＳＩＮＲよりも大きい他の正方形として示される。これらの正方形のそれぞれは、正方形５０８で開始することによってサーチされる。正方形５０８では、リソースブロック数は、近接して利用可能なリソースブロック最大数を使用することによって、あるいはリソースブロック数をさらに増加することでＭＣＳを最低の利用可能なＭＣＳのレベル以下に削減することから、最大限になる。リソースブロック数の計算後５０８、分析は、例えば５０２、５０４、５０６等の他の利用可能な［ｔ］［ｊ］組を見続け、送信できるビット数、つまり割り当てのためのトランスポートブロックサイズが、その時点でサーチを停止し、リソースを割り当てられるような正方形５０８での数以上であるかどうかを判定する。
【００２９】
説明される原則は、リソースブロックの関連の例において理解できる。ユーザ装置のセットが決定される。ユーザ装置のセットは、再送が必要とされるそれらのユーザ装置、および新たな送信を有するユーザ装置を含む。これらのユーザ装置は、再送が先に優先される優先順位測定基準に従って順序付けられる。リソースの数およびＭＣＳが所定である可能性があるので、いくつかのケースでは、再送は簡略化されたサーチを有するだろう。再送に所定数のリソースブロックを割り当てることができない場合、スケジューラは、同じＴＢＳ値のより少ない数のリソースブロックをサーチする可能性がある。再送の後には、優先順位測定基準の降順での新たな再送が続く。さらに、アップリンク上の近接するリソースブロックの最大数だけではなく、アップリンク上の利用可能なリソースブロック数も決定される。次いで、選択されたユーザ装置について、ユーザ装置が、上述されたように重負荷所状況で処理されるべきか、それとも低負荷状況で処理されるべきかが決定される。重負荷状況での場合には、ユーザ装置にはＮＱ、ＮＭＣＳおよびＮＲＢ＿ＭＡＸから最小値のリソースブロックＮＲＢ＊が割り当てられる。図５を使用すると、重負荷状況では、ＮＭＣＳと関連付けられ、したがって正方形５０２はリソースブロック数および対応するＴＢＳ  Ｔであると決定される。これらの値を用いて、アップリンクチャネルが、選択されたユーザ装置に適切な数の近接リソースブロックを割り当てるために見直される。セットの次のユーザ装置が次いで選択される。
【００３０】
次のユーザ装置に対して、同じプロセスが実行される。低負荷状況では、ＮＲＢ＊は、説明されたようにＮＱＬＬ、ＮＴＢＳおよびＮＲＢ＿ＭＡＸの間で決定される。図５を使用すると、リソースブロック数は増加することができ、したがって電力はより多くのリソースブロック全体で拡散し、トランスポートブロックサイズおよびユーザスループットを増加できる。したがって、正方形５０４、５０６または５０８を選択することができ、ユーザ装置に対して適切な数のリソースブロックを割り当てることができる。
【００３１】
いくつかのスケジューラでは、個々のリソースグループまたはリソースブロックのグループのチャネルの質等の追加情報が既知である可能性がある。（周波数選択スケジューラと呼ばれる）それらのスケジューラはこの情報を活用して、リソースブロック内のユーザ装置をスケジュールする。これはそれらのスケジューラにとって最良であり、システムの全体的な容量を最適化することとなる。ここに説明されるシステムにおいてと同様に、すべてのユーザ装置がリソースブロック毎のこの詳細なチャネル情報を有さないことも可能である。それらのユーザに対して、我々は上述されたような同じリソース割り当て方針を使用するだろう。
【００３２】
上述されたように、低負荷でのリソース割り当ての手法は、ＮＭＣＳまでのリソースを用いるよりも、低いスペクトル効率で割り当てられたより多くのリソースを使用してより大きなＴＢＳ割り当てを提供しようとする。いくつかのケースでは、限られた送信電力および（特定の閾値を超える）高い経路損失のために、（閾値を下回る）低いスループットを経験しているセル端ユーザには、そのスループットをブーストするために実際の測定されたリソース負荷が高い場合にも低い負荷規則に従ってリソースが割り当てられる。これらのケースでのＮＭＣＳを超えるリソースブロックの増加は、リソースブロックの閾値数によって制限できるだろう。
【００３３】
上記明細書では、本発明の特定の実施形態が説明されてきた。しかしながら、当業者は、以下の特許請求の範囲に述べられる本発明の範囲を逸脱することなく、多様な修正および変更を加えることができることを理解する。したがって、明細書および図は、制限的な意味ではなく例示的な意味で考慮されるべきであり、すべてのかかる修正形態は本発明の範囲内に含まれることが意図される。利点、優位点、問題の解決策、およびどのような利点、優位点または解決策も引き起こすまたはより顕著とするどのような要素（複数の場合がある）も、任意のまたはすべての請求項の重大な特長または要素、必要とされる特長または要素、または必須の特長または要素と見なされるべきではない。本発明は、本願の係属の間に加えられるあらゆる補正、および発行されるそれらの請求項のすべての均等物を含む、添付特許請求の範囲によってだけ定められる。
【図５】
0005541411.tif 000002
【図１】
0005541411.tif 000003
【図２】
0005541411.tif 000004
【図３】
0005541411.tif 000005
【図４】
0005541411.tif 000006