(57)【特許請求の範囲】
【請求項１】
通信装置であって、
複数の時間及び周波数リソースブロックを用いて無線通信リンクを介して複数の通信機器と通信するように動作可能な送受信機回路と、
それぞれが通信機器に関連付けられる無線ベアラに、前記送受信機回路と前記関連付けされた通信機器との間でデータを通信するためのリソースブロックを配分するように動作可能なスケジューラーと、
少なくとも１つのベアラについて、該ベアラに関連付けられる規定のサービス品質を満たすために必要とされるリソースブロックを推定するように動作可能な負荷推定器と、
を備え、
前記スケジューラーは、前記送受信機回路と前記関連付けされた通信機器との間の無線状況と共に変化する前記少なくとも１つのベアラの測定データを前記負荷推定器に与えるように動作可能であり、前記負荷推定器は、前記少なくとも１つのベアラについて、前記スケジューラーから受けた前記測定データに基づいて、前記規定のサービス品質を満たすために必要とされるリソースブロックを推定するように動作可能である、通信装置。
【請求項２】
前記負荷推定器は、前記少なくとも１つのベアラについて、前記スケジューラーから受けた前記測定データ及び前記ベアラのために必要とされるデータレートに基づいて、前記規定のサービス品質を満たすために必要とされる前記リソースブロックを推定するように動作可能である、請求項１に記載の通信装置。
【請求項３】
前記少なくとも１つのベアラの前記測定データは、前記ベアラが前記スケジューリングされたリソースブロックのそれぞれにおいて達成することができるビットレートの指標を含む、請求項１又は２に記載の通信装置。
【請求項４】
前記負荷推定器は、前記少なくとも１つのベアラについて、前記関連付けされた通信機器のスペクトル効率に基づいて、前記規定のサービス品質を満たすために必要とされる前記リソースブロックを推定するように動作可能である、請求項１〜３のいずれか一項に記載の通信装置。
【請求項５】
前記負荷推定器は、以下の式を用いて前記少なくとも１つのベアラの負荷（ρ）を推定するように動作可能であり、
【数１】
0005413631.tif 000064
ただし、
【数２】
0005413631.tif 000065
は前記ベアラのアクティビティ係数であり、
Ｋは利用可能なリソースブロックの全数であり、
Ｒｒｅｑは前記ベアラのために必要とされるビットレートであり、
【数３】
0005413631.tif 000066
は前記関連付けされた通信機器のスペクトル効率である、請求項４に記載の通信装置。
【請求項６】
前記負荷推定器は、以下の項を用いて前記関連付けされた通信機器の前記スペクトル効率を求めるように動作可能であり、
【数４】
0005413631.tif 000067
ただし、ｒｋは、前記ベアラがリソースブロック番号ｋにおいて達成することができる瞬時ビットレートである、請求項５に記載の通信装置。
【請求項７】
前記負荷推定器は、以下の項を用いて前記関連付けされた通信機器の前記スペクトル効率を求めるように動作可能であり、
【数５】
0005413631.tif 000068
ただし、ｒｋは、前記ベアラがリソースブロック番号ｋにおいて達成することができる瞬時ビットレートであり、Ｓは瞬時ビットレート要件を満たすのに十分であるリソースブロックの最も小さな集合である、請求項５に記載の通信装置。
【請求項８】
前記負荷推定器は、以下の項を用いて前記関連付けされた通信機器の前記スペクトル効率を求めるように動作可能であり、
【数６】
0005413631.tif 000069
ただし、ｒｋは、前記ベアラがリソースブロック番号ｋにおいて達成することができる瞬時ビットレートであり、Ａは前記スケジューラーによって前記ベアラに割り当てられるリソースブロックの集合であり、Ｎは集合Ａ内のリソースブロックの数である、請求項５に記載の通信装置。
【請求項９】
前記負荷推定器は、以下の式を用いて前記少なくとも１つのベアラの負荷（ρ）を推定するように動作可能であり、
【数７】
0005413631.tif 000070
ただし、
【数８】
0005413631.tif 000071
はアクティブである期間中に前記ベアラに与えられるスループットを表し、
Ｋは利用可能なリソースブロックの全数であり、
Ｒｒｅｑは前記ベアラのために必要とされるビットレートであり、
【数９】
0005413631.tif 000072
は前記スケジューラーが前記ベアラに割り当てるリソースブロックの代表的な数である、請求項１〜３のいずれか一項に記載の通信装置。
【請求項１０】
前記負荷推定器は、以下の項を用いて前記ベアラに与えられるスループットを求めるように動作可能であり、
【数１０】
0005413631.tif 000073
ただし、ｒｋは、前記ベアラがリソースブロック番号ｋにおいて達成することができる瞬時ビットレートであり、Ａは前記スケジューラーによって前記ベアラに割り当てられるリソースブロックの集合である、請求項９に記載の通信装置。
【請求項１１】
前記負荷推定器は、前記ベアラのために規定される遅延制約に基づいて、前記ベアラのために必要とされるビットレートを推定するように動作可能である、請求項５〜１０のいずれか一項に記載の通信装置。
【請求項１２】
前記負荷推定器は、以下の式を用いて前記ベアラのために必要とされるビットレートを推定するように動作可能であり、
【数１１】
0005413631.tif 000074
ただし、Ｓ（ｔ）は時刻ｔにおける前記ベアラのバッファー内の最も古いパケットのサイズ（ビット単位）であり、
ｔ（ａｒｒ）は、この最も古いパケットが前記バッファー内に到着した時刻であり、
ｔｍ（ＤＢ）は、前記ベアラのために規定される遅延制約である、請求項１１に記載の通信装置。
【請求項１３】
新たなベアラを確立するための要求を受信するように動作可能であり、前記負荷推定器は、前記新たなベアラのための負荷を推定するように動作可能である、請求項１〜１２のいずれか一項に記載の通信装置。
【請求項１４】
前記新たなベアラの推定された負荷及び既存のベアラの推定された負荷に基づいて、前記新たなベアラを許可するか否かを判断するように動作可能なアドミッションコントローラーをさらに備える、請求項１３に記載の通信装置。
【請求項１５】
前記新たなベアラが、既にベアラが存在している通信機器に関連付けられる場合には、前記負荷推定器は、同じ通信機器に関連付けられた既存のベアラのために前記スケジューラーによって与えられた測定値に基づいて、前記新たなベアラの前記負荷を推定するように動作可能である、請求項１３又は１４に記載の通信装置。
【請求項１６】
前記負荷推定器は、前記通信装置と前記関連付けされた通信機器との間のチャネル状況に基づいて前記新たなベアラの前記負荷を推定するように動作可能である、請求項１５に記載の通信装置。
【請求項１７】
前記負荷推定器は、以下の式を用いて前記少なくとも１つのベアラの負荷（Δρ）を推定するように動作可能であり、
【数１２】
0005413631.tif 000075
ただし、
【数１３】
0005413631.tif 000076
は前記ベアラのアクティビティ係数であり、
Ｋは利用可能なリソースブロックの全数であり、
Ｒｒｅｑは前記ベアラのために必要とされるビットレートであり、
【数１４】
0005413631.tif 000077
は前記関連付けされた通信機器のスペクトル効率である、請求項１３〜１６のいずれか一項に記載の通信装置。
【請求項１８】
前記関連付けされた通信機器の前記スペクトル効率は、同じ通信機器に関連付けられる１つ以上の他のベアラから求められる、請求項１７に記載の通信装置。
【請求項１９】
前記負荷推定器は、以下の式を用いて前記新たなベアラの負荷（Δρ）を推定するように動作可能であり、
【数１５】
0005413631.tif 000078
ただし、
【数１６】
0005413631.tif 000079
はスループットを表し、
Ｋは利用可能なリソースブロックの全数であり、
Ｒｒｅｑは前記ベアラのために必要とされるビットレートであり、
【数１７】
0005413631.tif 000080
は前記スケジューラーが同様のベアラに割り当てるリソースブロックの代表的な数である、請求項１３〜１６のいずれか一項に記載の通信装置。
【請求項２０】
前記スケジューラーは、各時点において前記少なくとも１つのベアラに割り当てられる前記リソースブロックの数を特定する測定データを与えるように動作可能であり、前記負荷推定器は、前記少なくとも１つのベアラについて、個々の前記ベアラに割り当てられる前記リソースブロックの数の移動平均を保持するように、かつ前記ベアラの前記負荷を推定するときに、前記ベアラの該移動平均を用いるように動作可能である、請求項１に記載の通信装置。
【請求項２１】
請求項１〜２０のいずれ一項に記載の通信装置と、１つ以上の通信機器とを含み、前記通信機器は、該通信機器と前記通信装置との間でデータを通信するために、前記通信装置とのベアラを確立するように動作可能である、通信システム。
【請求項２２】
通信方法であって、
複数の時間及び周波数リソースブロックを用いる無線通信リンクを介して複数の通信機器と通信するために送受信機回路を用いること、
それぞれが通信機器に関連付けられる無線ベアラに、前記送受信機回路と前記関連付けされた通信機器との間でデータを通信するためのリソースブロックを配分すること、
少なくとも１つのベアラについて、該ベアラに関連付けられる規定のサービス品質を満たすために必要とされるリソースブロックを推定すること、及び
前記送受信機回路と前記関連付けされた通信機器との間の無線状況と共に変化する、前記少なくとも１つのベアラの測定データを与えることを含み、前記推定することは、前記少なくとも１つのベアラについて、前記与えられた測定データに基づいて、前記規定のサービス品質を満たすために必要とされるリソースブロックを推定する、通信方法。
【請求項２３】
１つ以上のプログラマブルコンピューター装置が請求項１〜２０のいずれか一項に記載の通信装置として構成されるようにするためのコンピューター実施可能命令を含むプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信装置、限定はしないが、特にＯＦＤＭＡ通信技術を用いて動作する装置によって実行される負荷推定に関する。本発明は、限定はしないが、アドミッション制御、輻輳制御及び（セル間）負荷均衡に用いるための、３ＧＰＰ（第三世代パートナーシッププロジェクト）によって規定される、通信装置における負荷推定に特に関連する。
【背景技術】
【０００２】
負荷推定は、必要とされるサービス品質（ＱｏＳ）を満たすために、各ユーザーが必要とするセルの利用可能な物理的な無線リソースの部分を推定するという問題である。これは、現時点で消費しているリソースの量とは異なる場合がある。負荷推定は、コールアドミッション制御、輻輳制御及び（セル間）負荷均衡を含む多くの無線リソース管理機能のための必要条件である。たとえば、或るセルにおいて新たなベアラを許可するか否かを判断するとき、基地局（又はＬＴＥ（ロングタームエボリューション）用語を使用するｅＮＢ（発展型ＮｏｄｅＢ））は、そのセルの現在の負荷、及び新たなベアラによって引き起こされる負荷の増加を推定し、それから、利用可能なシステムリソースに応じて、新たなベアラを許可するか否かを判断する。現在の負荷及び負荷の増加を推定する作業は些細なことではなく、とりわけ、既存の無線ベアラの数及びそれらのサービスクラス（保証されるビットレート等）、要求される新たなベアラのタイプ、並びに基地局と個々のユーザー装置（ＵＥ）との間のチャネル状況に依存する。
【０００３】
同様の要件が、ＷＣＤＭＡ（広帯域符号分割多元接続）通信システムのアドミッション制御に関して規定された。しかしながら、ＷＣＤＭＡのためのアドミッション制御の難しさの１つは、リソースが干渉を基にすることであり、それは、新たなベアラの導入に起因する干渉が他のベアラの品質に影響を及ぼす可能性があることを意味する。結果として、他のベアラの電力レベルが上昇しなければならない場合があり、それにより、さらに別の１組のベアラ等においてさらに干渉を引き起こす場合がある。このように、新たなベアラの影響を推定することは反復過程であり、干渉レベルが収束する（すなわち、全てのベアラの所望の品質が達成される）か、又は１つ若しくは複数のベアラが切断されるまで続けられる。ＷＣＤＭＡシステムにおいて用いられる技法は、ＯＦＤＭＡシステムには一般的に適用することはできない。
【０００４】
特許文献１は、アドミッション制御のために、ＯＦＤＭＡシステム内の負荷を推定するために用いることができる技法を記述する。そのシステムは、サービスクラス毎に、そのクラスのための平均ブロック要件を保持する。新たなベアラが要求されるとき、そのシステムは、要求されるベアラのクラスを特定し、それから、格納されたデータから、必要とされるリソースブロックの数を求め、それから、必要とされるリソースブロックの数が利用可能なリソースブロックの数未満であるか否かによって、その新たなベアラを許可するか否かを判断する。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】米国特許出願公開第２００８／００８０３７８号
【発明の概要】
【発明が解決しようとする課題】
【０００６】
本発明は、負荷、すなわち、既存の負荷、若しくは要求される新たなベアラに起因して増加する負荷、又はその両方を推定するための代替的な技法を提供する。
【課題を解決するための手段】
【０００７】
本発明の一態様は、通信装置であって、
複数の周波数リソースブロックを用いて無線通信リンクを介して複数の通信機器と通信するように動作可能な送受信機回路と、それぞれが通信機器に関連付けられる無線ベアラに、前記送受信機回路と前記関連付けされた通信機器との間でデータを通信するためのリソースブロックを配分するように動作可能なスケジューラと、少なくとも１つのベアラについて、該ベアラに関連付けられる規定のサービス品質を満たすために必要とされるリソースブロックを推定するように動作可能な負荷推定器と、を備え、前記スケジューラーは、前記少なくとも１つのベアラの負荷を推定するのに用いるために、前記送受信機回路と前記関連付けされた通信機器との間の無線状況と共に変化する前記少なくとも１つのベアラの測定データを前記負荷推定器に与えるように動作可能である、通信装置を提供する。
【０００８】
前記負荷推定器は、少なくとも１つのベアラについて、スケジューラーから受けた測定データ及び前記ベアラのために必要とされるデータレートに基づいて、かつ／又は関連付けされた通信機器のスペクトル効率に基づいて、規定のサービス品質を満たすために必要とされるリソースブロックを推定することができる。
【０００９】
前記少なくとも１つのベアラの測定データは、前記ベアラがスケジューリングされたリソースブロックのそれぞれにおいて達成することができるビットレートの指標を含むことができる。
【００１０】
前記負荷推定器は、以下の式を用いて前記少なくとも１つのベアラの負荷（ρ）を推定することができる。
【００１１】
【数１】
0005413631.tif 000002
【００１２】
ただし、
【００１３】
【数２】
0005413631.tif 000003
【００１４】
は前記ベアラのアクティビティを表し、
Ｋは利用可能なリソースブロックの全数であり、
Ｒｒｅｑは前記ベアラのために必要とされるビットレートであり、
【００１５】
【数３】
0005413631.tif 000004
【００１６】
は前記関連付けされた通信機器のスペクトル効率である。これは、たとえば時間平均値又は百分率値である。
【００１７】
前記負荷推定器は、以下の項を用いて前記関連付けされた通信機器の前記スペクトル効率を求めることができる。
【００１８】
【数４】
0005413631.tif 000005
【００１９】
ただし、ｒｋは、前記ベアラがリソースブロック番号ｋにおいて達成することができる瞬時ビットレートである。
【００２０】
代替的に、前記負荷推定器は、以下の項から前記関連付けされた通信機器の前記スペクトル効率を求めることができる。
【００２１】
【数５】
0005413631.tif 000006
【００２２】
ただし、ｒｋは、前記ベアラがリソースブロック番号ｋにおいて達成することができる瞬時ビットレートであり、Ｓは瞬時ビットレート要件を満たすのに十分であるリソースブロックの最も小さな集合である。
【００２３】
代替的に、前記負荷推定器は、以下の項から前記関連付けされた通信機器の前記スペクトル効率を求めることができる。
【００２４】
【数６】
0005413631.tif 000007
【００２５】
ただし、ｒｋは、前記ベアラがリソースブロック番号ｋにおいて達成することができる瞬時ビットレートであり、Ａは前記スケジューラーによって前記ベアラに割り当てられるリソースブロックの集合であり、Ｎは集合Ａ内のリソースブロックの数である。
【００２６】
前記負荷推定器は、以下の式を用いて前記少なくとも１つのベアラの負荷（ρ）を推定することができる。
【００２７】
【数７】
0005413631.tif 000008
【００２８】
ただし、
【００２９】
【数８】
0005413631.tif 000009
【００３０】
はアクティブである期間中に前記ベアラに与えられるスループットを表し、
Ｋは利用可能なリソースブロックの全数であり、
Ｒｒｅｑは前記ベアラのために必要とされるビットレートであり、
【００３１】
【数９】
0005413631.tif 000010
【００３２】
は前記スケジューラーが前記ベアラに割り当てるリソースブロックの代表的な数（たとえば時間平均数）である。
【００３３】
前記負荷推定器は、以下の項からベアラに与えられるスループットを求めることができる。
【００３４】
【数１０】
0005413631.tif 000011
【００３５】
ただし、ｒｋは、前記ベアラがリソースブロック番号ｋにおいて達成することができる瞬時ビットレートであり、Ａは前記スケジューラーによって前記ベアラに割り当てられるリソースブロックの集合である。
【００３６】
前記負荷推定器は、たとえば以下の式を用いて、前記ベアラのために規定される遅延制約に基づき、前記ベアラのために必要とされるビットレートを推定することができる。
【００３７】
【数１１】
0005413631.tif 000012
【００３８】
ただし、Ｓ（ｔ）は時刻ｔにおける前記ベアラのバッファー内の最も古いパケットのサイズ（ビット単位）であり、
ｔ（ａｒｒ）は、この最も古いパケットが前記バッファー内に到着した時刻であり、
ｔｍ（ＤＢ）は、前記ベアラのために規定される遅延制約である。
【００３９】
前記通信装置は、新たなベアラを確立するための要求を受信することができ、前記負荷推定器は、該新たなベアラのための負荷を推定することができる。この場合、前記通信装置は好ましくは、前記新たなベアラの推定された負荷及び既存のベアラの推定された負荷に基づいて、前記新たなベアラを許可するか否かを判断するためのアドミッションコントローラーをさらに備える。
【００４０】
前記新たなベアラが、既にベアラが存在している通信機器に関連付けられる場合には、前記負荷推定器は、同じ通信機器に関連付けられた既存のベアラのために前記スケジューラーによって与えられた測定値に基づいて、前記新たなベアラの負荷を推定することができる。たとえば、前記負荷推定器は、前記通信装置と前記関連付けされた通信機器との間のチャネル状況に基づいて前記新たなベアラの負荷を推定することができる。
【００４１】
前記負荷推定器は、以下の式を用いて前記新たなベアラの負荷（Δρ）を推定することができる。
【００４２】
【数１２】
0005413631.tif 000013
【００４３】
ただし、
【００４４】
【数１３】
0005413631.tif 000014
【００４５】
は前記ベアラのアクティビティ係数であり、
Ｋは利用可能なリソースブロックの全数であり、
Ｒｒｅｑは前記ベアラのために必要とされるビットレートであり、
【００４６】
【数１４】
0005413631.tif 000015
【００４７】
は前記関連付けされた通信機器のスペクトル効率である。
【００４８】
前記関連付けされた通信機器の前記スペクトル効率は、同じ通信機器に関連付けられる１つ以上の他のベアラから求めることができる。
【００４９】
代替的に、前記負荷推定器は、以下の式を用いて前記新たなベアラの負荷（Δρ）を推定することができる。
【００５０】
【数１５】
0005413631.tif 000016
【００５１】
ただし、
【００５２】
【数１６】
0005413631.tif 000017
【００５３】
は、たとえば、前記スケジューラーが同様のベアラに与えるスループットから求めることができるスループットを表し、
Ｋは利用可能なリソースブロックの全数であり、
Ｒｒｅｑは前記ベアラのために必要とされるビットレートであり、
【００５４】
【数１７】
0005413631.tif 000018
【００５５】
は前記スケジューラーが同様のベアラに割り当てるリソースブロックの代表的な数である。
【００５６】
１つの実施の形態では、前記スケジューラーは、各時点において前記少なくとも１つのベアラに割り当てられる前記リソースブロックの数を特定する測定データを与え、前記負荷推定器は、前記少なくとも１つのベアラについて、個々の前記ベアラに割り当てられる前記リソースブロックの数の移動平均を保持し、前記ベアラの前記負荷を推定するときに、前記ベアラのための該移動平均を用いる。
【００５７】
本発明は、上記の通信装置と、１つ以上の通信機器（たとえば移動電話）とを含み、前記通信機器は、該通信機器と該通信装置との間でデータを通信するために、該通信装置とのベアラを確立するように動作可能である、通信システムも提供する。
【００５８】
本発明は、通信方法であって、複数の時間及び周波数リソースブロックを用いる無線通信リンクを介して複数の通信機器と通信するために送受信機回路を用いること、それぞれが通信機器に関連付けられる無線ベアラに、前記送受信機回路と前記関連付けされた通信機器との間でデータを通信するためのリソースブロックを配分すること、少なくとも１つのベアラについて、該ベアラに関連付けられる規定のサービス品質を満たすために必要とされるリソースブロックを推定すること、及び前記送受信機回路と前記関連付けされた通信機器との間の無線状況と共に変化する、前記少なくとも１つのベアラの測定データを与えることを含み、前記推定することは、前記少なくとも１つのベアラについて、前記与えられた測定データに基づいて、前記規定のサービス品質を満たすために必要とされるリソースブロックを推定する、通信方法も提供する。
【００５９】
本発明は、開示される全ての方法の場合に、対応する装置において実行するための対応するコンピュータープログラム又はコンピュータープログラム製品、装置自体（ユーザー装置、ノード又はその構成要素）及び装置を更新する方法を提供する。
【００６０】
ここで、本発明の例示的な実施の形態を、例として、添付の図面を参照しながら説明する。
【図面の簡単な説明】
【００６１】
【図１】本発明が適用可能であるタイプの移動通信システムを示す概略図である。
【図２ａ】図１に示されるシステムの無線リンクを介する通信に用いられる一般的なフレーム構造を示す概略図である。
【図２ｂ】周波数サブキャリアがリソースブロックに分割される方法及びタイムスロットが複数のＯＦＤＭシンボルに分割される方法を示す概略図である。
【図３】図１に示されるシステムの一部を形成する基地局を示す概略図である。
【発明を実施するための形態】
【００６２】
概要
図１は移動（セルラー）通信システム１を概略的に示しており、その通信システムでは、移動電話（ＭＴ）３−０、３−１及び３−２のユーザーが基地局５−１又は５−２のうちの１つ及び電話網７を介して他のユーザー（図示せず）と通信することができる。移動電話３と基地局５との間の無線リンクのために、複数のアップリンク及びダウンリンク通信リソース（サブキャリア、タイムスロット等）が利用可能である。この例示的な実施形態では、基地局５は、移動電話３に送信されることになるデータ量に応じて、各移動端末３にダウンリンクリソースを配分する。同様に、基地局５は、移動端末３が基地局５に送信しなければならないデータの量及びタイプに応じて、各移動電話３にアップリンクリソースを配分する。
【００６３】
基地局は一般的に、要求されるサービス毎に無線ベアラを確立することによって、移動電話にサービスを提供する。たとえば、ビデオデータを搬送するために１つの無線ベアラが規定される場合があり、オーディオデータを搬送するために１つの無線ベアラが規定される場合があり、バースト状のウエブトラフィックを搬送するために１つの無線ベアラが規定される場合がある等である。無線ベアラによって搬送されるデータのタイプに関連付けられるサービス品質に応じて、種々のタイプの無線ベアラが規定される。たとえば、ビデオ又はオーディオトラフィックのために用いられる無線ベアラは、インターネットトラフィックに用いられる無線ベアラよりも高いクラスにおいて提供される場合がある。なぜなら、ユーザーは、インターネットトラフィックに伴う遅延を許容することはできても、ビデオデータの配信における遅延を許容することはできないからである。新たな接続を確立する時点で、所望のサービス品質で要求されるサービスを提供するであろう無線ベアラが確立される。新たな接続が確立されることになるとき、基地局５は、所望のサービスを提供できるようにするためのリソースを有することを確認しなくてはならず、かつ既存の接続のサービスに影響を及ぼすことなく、サービスを提供できるようにしなければならない。これを果たすことができるように、基地局５は、基地局５の既存の負荷、及び新たな接続によって引き起こされると予想される負荷を推定しなければならない。
【００６４】
ＬＴＥサブフレームデータ構造
基地局５が負荷推定値を求めることができる具体的な方法を述べる前に、ＬＴＥ  Ｒｅｌ８のために合意されたアクセス方式及び一般的なフレーム構造を説明する。移動電話３が、基地局５との電波インターフェースを介してデータを受信できるようにするために、ダウンリンクに対して直交周波数分割多元接続（ＯＦＤＭＡ）技法が用いられる。移動電話３に送信されることになるデータ量に応じて、基地局５によって（所定の時間量のために）各移動電話３に異なるサブキャリアが配分される。これらのサブキャリア及び時間の配分は、ＬＴＥ仕様書において物理リソースブロック（ＰＲＢ）として規定される。それゆえ、ＰＲＢは時間及び周波数次元を有する。基地局５は、該基地局５がサービス提供している機器毎にＰＲＢを動的に配分し、制御チャネルにおいて、サブフレーム（ＴＴＩ）毎の配分を、スケジューリングされた移動電話３のそれぞれに送信する。
【００６５】
図２ａは、基地局５との電波インターフェースを介したＬＴＥ  Ｒｅｌ８通信に関して合意された一般的なフレーム構造を示す。図に示されるように、１つのフレーム１３は１０ｍｓｅｃ長であり、１ｍｓｅｃの持続時間（送信時間間隔（ＴＴＩ）として知られている）の１０個のサブフレーム１５を含む。各サブフレーム又はＴＴＩは０．５ｍｓｅｃの持続時間の２つのスロット１７を含む。各スロット１７は、標準サイクリックプレフィックスが用いられるか、拡張サイクリックプレフィックス（ＣＰ）が用いられるかに応じて、６つ又は７つのＯＦＤＭシンボル１９を含む。利用可能なサブキャリアの全数は、システムの全送信帯域幅に依存する。ＬＴＥ仕様書は、１．４ＭＨｚ〜２０ＭＨｚのシステム帯域幅のためのパラメータを規定し、１つのＰＲＢは現在、１つのスロット１７の１２個の連続サブキャリアを含むように規定されている。また、ＬＴＥ仕様書によって、基地局スケジューラーによって割り当てられるリソース配分の最も小さな要素として、２スロットにわたるＰＲＢも規定されている。そして、これらのサブキャリアはコンポーネントキャリア上に変調され、その信号は所望の送信帯域幅にアップコンバートされる。こうして、送信されたダウンリンク信号は、Ｎｓｙｍｂ個のＯＦＤＭシンボルの持続時間の間にＮＢＷ個のサブキャリアを含む。これは、図２ｂに示されるように、リソースグリッドによって表すことができる。グリッド内の各枠は１シンボル周期の単一のサブキャリアを表し、リソース要素と呼ばれる。図に示されるように、各ＰＲＢ２１は、１２個の連続するサブキャリア、及び（この場合において）サブキャリアあたり７個のシンボルから形成される。しかし、実際には、各サブフレーム１５の第２のスロット１７においても同じ配分が行なわれる。
【００６６】
各サブフレーム１５の開始時に、基地局５は、最初の３つのシンボルにわたって、ＰＤＣＣＨ（物理ダウンリンク制御チャネル）を送信する。残りのシンボルは、移動電話３のためのダウンリンクユーザーデータを搬送するために用いられるＰＤＳＣＨ（物理ダウンリンク共有チャネル）を形成する。ＰＤＣＣＨチャネルは、とりわけ、各移動電話３のために、移動電話３がそのサブフレームにおいてダウンリンクデータを受信するためにスケジューリングされるか、又はそのサブフレームにおいてアップリンク送信のためにスケジューリングされるかを指示するデータを含み、それに合わせて、ダウンリンクデータを受信するために、又はアップリンクデータを送信するために使用されるべきＰＲＢを特定するデータを含む。
【００６７】
基地局
図３は、図１に示される各基地局５の主要構成要素を示すブロック図である。図に示されるように、各基地局５は送受信機回路３１を備え、送受信機回路３１は、１つ以上のアンテナ３３を介して、移動電話３に対し信号を送受信するように動作可能であり、かつ、ネットワークインターフェース３５を介して、電話網７に対し信号を送受信するように動作することができる。コントローラー３７は、メモリ３９に格納されるソフトウエアに従って、送受信機回路３１の動作を制御する。ソフトウエアは、とりわけ、オペレーティングシステム４１と、通信制御モジュール４３と、スケジューラーモジュール４５と、負荷推定器モジュール４６と、アドミッション制御モジュール４７とを含む。オペレーティングシステム４１は、移動電話３から／へアップリンクデータ又はダウンリンクデータが送信される異なるサブバンドにおけるサブフレームの生成を制御するように動作可能である。スケジューラーモジュール４５は、移動電話３へダウンリンクデータを送信するための時刻、及び移動電話３が基地局５にそれらのアップリンクデータを送信するための時刻をスケジューリングするように動作可能である。負荷推定器モジュール４６は、既存の無線ベアラ及び新たに要求される無線ベアラのための負荷推定値を求め、これらの負荷推定値をアドミッション制御モジュール４７に報告するための役割を果たす。アドミッション制御モジュール４７は、負荷推定器モジュール４６によって求められた負荷推定値を用いて、要求された新たな無線ベアラを許可するか否かを判断するか、輻輳制御するか、又はセル間で移動端末３を負荷均衡させるための役割を果たす。
【００６８】
上記の説明において、基地局５は、理解を容易にするために、複数の別々のモジュール（スケジューラーモジュール、負荷推定器モジュール、アドミッション制御モジュール等）を有するものとして説明される。これらのモジュールは、或る特定の応用例、たとえば、本発明を実施するために既存のシステムが変更された場合には、そのようにして設けられてもよいが、他の応用例、たとえば、最初から本発明の特徴を念頭において設計されるシステムでは、これらのモジュールはオペレーティングシステム又はコードの全体の中に組み込まれてよい。その場合、これらのモジュールは別々の実体として区別できない場合もある。
【００６９】
既存の負荷の推定
ＬＴＥのために規定された３ＧＰＰ標準規格では、物理的な無線リソースは、物理リソースブロック（ＰＲＢ）の観点から測定されるのが最も好都合であるが、以下に記述される方法は、任意の他のＯＦＤＭベースのシステムに等しく適用可能である。それらの方法はアップリンク及びダウンリンクの両方に適用可能である。
【００７０】
以下の説明は単一のユーザー（１人のユーザーが２つ以上のベアラを有することができ、またベアラ毎に負荷推定値が必要とされる場合もあるので、より厳密には、単一のベアラ）に関する。用語「ＴＴＩ」が、時間単位として用いられる。ＬＴＥでは、これは１つのサブフレームに対応する。
【００７１】
時間平均された量を表すために、オーバーバーが一般的に用いられる。たとえば、
【００７２】
【数１８】
0005413631.tif 000019
【００７３】
は量ｘの時間平均である。平均値を求める持続時間は通常、数百〜数千ＴＴＩであると理解されたい。その時間は、無線チャネル品質の短期変動（フェージング）の影響を平均するのに十分に長いが、平均無線チャネル状況の変化に応答するのに十分に短い。適切な平均期間は、量によって異なる場合がある。任意の時間平均法を用いることができるが、実際には、指数重み付け平均（「忘却係数」）法を用いて、
【００７４】
【数１９】
0005413631.tif 000020
【００７５】
が推定されることが好ましく、その方法では、推定値は、以下の式に従って、時刻ｔ毎に更新される。
【００７６】
【数２０】
0005413631.tif 000021
【００７７】
ただし、βは１よりわずかに小さい定数である（収束を速めるため、最初の数サンプルの間、さらに小さなβ値を用いることができる）。
【００７８】
例示的な実施形態の以下の説明は、以下の定義を参照する。
Ｋ    システム帯域幅内のＰＲＢの全数（又は代替的には、ユーザーデータのために利用可能なＰＲＢの全数であり、すなわち、制御チャネル等のために割り当てられるＰＲＢは除外する）。
ρ    ベアラの推定される負荷。すなわち、ベアラのＱｏＳ要件を満たすために、そのベアラが必要とする物理的な無線リソース。これは、全セルリソースの割合として表されるが、代わりに、単にＫで乗算することによって、ＰＲＢの数として表すこともできる。
ａ    所与のＴＴＩにおいてベアラがアクティブである場合に、この値は１であり、そうでない場合には０である。その待ち行列内に送信待ちのデータが存在する場合には（すなわち、そのベアラがスケジューラーから無線リソースを要求している場合には）、そのベアラはアクティブである。それゆえ、時間平均された値
【００７９】
【数２１】
0005413631.tif 000022
【００８０】
はベアラの平均アクティビティ、すなわち、ベアラがスケジューラーからリソースを要求している時間の割合である。
Ｒｒｅｑ    ベアラのために必要とされるビットレート、すなわち、そのベアラのＱｏＳ要件を満たすために、そのベアラが必要とするレートである（以下では、全てのビットレートはビット／ＴＴＩとして表されるが、当然、その代わりに、ビット／秒として表すこともできる）。保証ビットレート（ＧＢＲ）サービスの場合、ＲｒｅｑはＧＢＲそのものである。パケット送信遅延に関して具体的な制約があるサービスの場合、Ｒｒｅｑは、パケット遅延要件を満たすのに十分なビットレートを表す。この場合、Ｒｒｅｑは、実際のパケットからリアルタイムに推定することができるか、又は当該サービスのための通常のパケット統計量の演繹的知識に基づいて予め設定することができる。特定のビットレート又は遅延要件がないベストエフォートサービスの場合、Ｒｒｅｑは、そのサービスタイプのための或る最小限のＱｏＳを保証するために、運営者によって設定される値とすることができる（それは実質的に、ベストエフォートサービスをＧＢＲサービスに変える）。
ｒｋ    このベアラがＰＲＢ番号ｋにおいて達成することができる瞬時ビットレートであり、すなわち、そのＰＲＢが現在のＴＴＩにおいてユーザーに配分された場合に、このユーザーがＰＲＢ番号ｋにおいて送信することができるビット数である。これは移動電話３から受信されるチャネル測定値から、基地局５が当然に知っていると思われる瞬時無線チャネル品質に依存する。
Ｎ    スケジューラーモジュール４５が所与のＴＴＩにおいてこのベアラに実際に割り当てるＰＲＢの数（ＨＡＲＱ（ハイブリッド自動再送要求）再送のために配分されるＰＲＢを含む）。
【００８１】
【数２２】
0005413631.tif 000023
【００８２】
全てのＴＴＩにわたるＮの時間平均であり、ベアラがスケジューリングされないＴＴＩ（すなわち、Ｎが０であるＴＴＩ）を含む。
【００８３】
ここで、単一のベアラの負荷を推定するための３つの方法を説明する。
【００８４】
方法Ａ
この方法では、負荷推定値は、ベアラの実際のＰＲＢ使用量に基づく。すなわち、以下の通りである。
【００８５】
【数２３】
0005413631.tif 000024
【００８６】
したがって、この方法を実施するために、スケジューラーモジュール４５は、負荷推定器モジュール４６に、各ＴＴＩ中に各ベアラに配分されるＰＲＢ数を通知し、負荷推定器４６は、ベアラ毎に、各ＴＴＩにおいてそのベアラに割り当てられるＰＲＢ数の移動平均を保持し、その後、この値をＫで割って、そのベアラのための推定される負荷を生成する。この方法は、簡単であるという利点を有する。ベアラが、該ベアラの必要とされるレートＲｒｅｑに近いレートで概ね安定してデータを生成すれば十分であり、この条件は、ストリーミングタイプのサービス（ビデオ又はオーディオストリーミング等）の場合に一般に満たされる。しかしながら、ベストエフォートサービスの場合、ベアラが大量の送信データを有し、セル内に空いている無線リソースがある場合には、スケジューラーは、そのベアラに、該ベアラのＱｏＳ要件を満たすのに実際に必要とするＰＲＢよりも多くのＰＲＢを割り当てる場合がある。この場合、この方法によって生成される推定値は、そのベアラによって必要とされる実際のリソースの適切な表示ではない。この問題は、以下の代替的な方法に委ねられる。
【００８７】
方法Ｂ
この方法では、負荷は、以下のように、ユーザーの平均無線チャネル状況から、必要とされるＰＲＢ数を予測することによって推定される。
【００８８】
【数２４】
0005413631.tif 000025
【００８９】
ここで、
【００９０】
【数２５】
0005413631.tif 000026
【００９１】
はユーザーの平均スペクトル効率（ＡＳＥ）を表し、それは１ＰＲＢ／ＴＴＩ当たりに該ユーザーが送信することができるビット数の推定値である。
【００９２】
【数２６】
0005413631.tif 000027
【００９３】
は量ωの時間平均であり、それは、以下の３つの代替的な方法のうちの１つを用いて計算される。
【００９４】
方法Ｂ１
方法Ｂ１では、ωは単に、システム帯域幅内のすべてのＰＲＢにわたるｒｋの平均である。
【００９５】
【数２７】
0005413631.tif 000028
【００９６】
この方法によれば、ユーザー毎の負荷測定は、ユーザーのチャネル品質（すなわち、ユーザーの移動電話３と基地局５との間のチャネルの品質）のみに依存し、セル内の他のユーザーには依存しない。また、この方法は、ユーザーがそのサブフレーム内にスケジューリングされるか否かにかかわらず、かつ送信するデータを有するか否かにかかわらず、サブフレーム毎のωの更新を許容する。これは、負荷推定値ρが、ユーザーの必要とされるレートＲ（ｒｅｑ）及び平均チャネル状況のみに依存し、ユーザーのトラフィックアクティビティ又はスケジューリング判断には依存しないことを意味する。しかしながら、この方法での主な問題は、ベアラによって要求されるリソースを実際よりも多く見積もる傾向があることである。ベアラによって要求されるリソースが全てのＰＲＢにわたる平均チャネル品質に基づくのに対して、移動電話３は通例、その最良のＰＲＢにおいてのみスケジューリングされることになるからである。
【００９７】
方法Ｂ２
方法Ｂ２では、ωはＰＲＢの集合Ｓにわたるｒｋの平均である。ただし、Ｓは、瞬時ビットレート要件を満たすのに十分であるＰＲＢの最も小さな集合（すなわち、条件
【００９８】
【数２８】
0005413631.tif 000029
【００９９】
が当てはまる最も小さな集合）である。
【０１００】
【数２９】
0005413631.tif 000030
【０１０１】
方法Ｂ２はユーザーの最良のＰＲＢにわたってｒｋを平均するので、方法Ｂ１よりも高いω値（それゆえ、低いρ値）を生成する傾向がある。さらに、スケジューラーモジュール４５は一般的に、各ユーザーを最良のＰＲＢにスケジューリングする傾向があるので、方法Ｂ２は、必要とされるレートＲｒｅｑを達成するために、スケジューラーモジュール４５がベアラに割り当てる必要があるＰＲＢの数に関して、方法Ｂ１よりも正確な予測を与えるはずである。しかしながら、方法Ｂ２はまた計算コストも高くなる。この方法は、上記の条件を満たすことになる最も小さな集合を算出できるように、負荷推定器モジュール４６に、ｒｋに基づいて全てのＰＲＢを分類するように要求するためである。
【０１０２】
方法Ｂ３
方法Ｂ３では、ωは、ユーザーが実際にスケジューリングされるＰＲＢのみを用いて計算される。
【０１０３】
【数３０】
0005413631.tif 000031
【０１０４】
ただし、Ａは割り当てられるＰＲＢの集合である。
【０１０５】
この方法では、移動電話３毎の負荷は、セル内の移動電話３の数に依存するであろう（これが、ベアラがスケジューリングされる時点を規定することになるので）。方法Ｂ３では、
【０１０６】
【数３１】
0005413631.tif 000032
【０１０７】
は、ベアラがスケジューリングされるＴＴＩ（ＨＡＲＱ再送を含む）のみにわたってωを平均することによって求められ、それは、データが非アクティブの期間中に負荷測定値を更新する方法に関して問題を引き起こすことに留意されたい。しかしながら、方法Ｂ１及び方法Ｂ２ではいずれも、ベアラがスケジューリングされるか否かにかかわらず、ωはＴＴＩ毎に計算され、
【０１０８】
【数３２】
0005413631.tif 000033
【０１０９】
は全てのＴＴＩにわたって平均することによって求められる。
【０１１０】
ωを計算する３つの方法のうち、方法Ｂ３は、最も正確な推定値を与える。スケジューラーモジュール４５によって実際に行なわれるリソース割当てに基づいているからである。また、方法Ｂ３の計算は複雑ではない。ωの計算はスケジューリングされたベアラ（それは通例、任意の所与のセル内の全ベアラ数の小さな部分集合である）に対してしか実行する必要がないからであるしかしながら、方法Ｂ３の不都合な点は、ベアラが非アクティブである（すなわち、送信待ちのデータを有しない）のでベアラがスケジューリングされていない期間中に負荷推定値を更新できないことである。これは、非アクティブである期間が長い場合には、平均無線状況が変化することに起因して、負荷推定値を不正確にする可能性がある。
【０１１１】
方法Ｃ
この方法では、負荷は、以下のように、ベアラの実際のＰＲＢ使用量及びスループットに基づいて推定される。
【０１１２】
【数３３】
0005413631.tif 000034
【０１１３】
ここで、
【０１１４】
【数３４】
0005413631.tif 000035
【０１１５】
は、アクティブである時間中にベアラに与えられる平均スループットを表す。より具体的には、それは、ＨＡＲＱ再送の場合に送信されるビットを含まない、ａ＝１である全てのＴＴＩにわたってベアラによって送信される平均ビット数である。
【０１１６】
ベアラがスケジューリングされるＴＴＩにおいて、Ｔを計算する１つの方法は、全てのスケジューリングされたＰＲＢにわたってｒｋを合計することである。
【０１１７】
【数３５】
0005413631.tif 000036
【０１１８】
明らかに、これは、係数Ｎを除いて、方法Ｂ３におけるωの計算と同一である。しかしながら、
【０１１９】
【数３６】
0005413631.tif 000037
【０１２０】
が、ベアラがスケジューリングされるＴＴＩのみにわたって平均することによって得られるのに対して、
【０１２１】
【数３７】
0005413631.tif 000038
【０１２２】
は、ベアラがアクティブである全てのＴＴＩにわたって平均することによって得られる。（ベアラがアクティブであるが、スケジューリングされないか、又はＨＡＲＱ再送のためにスケジューリングされるＴＴＩでは、Ｔ＝０）。
【０１２３】
さらに、Ｔは上記の方法を用いてｒｋから計算することができるが、実際には、スケジューラーによって選択されるトランスポートフォーマットに基づいて、スケジューリングされたＴＴＩにおけるベアラによって送信される実際のビット数を用いる方が簡単であり、正確である。
【０１２４】
アクティビティは平均ＰＲＢ使用量
【０１２５】
【数３８】
0005413631.tif 000039
【０１２６】
において考慮に入れられるので、アクティビティ項
【０１２７】
【数３９】
0005413631.tif 000040
【０１２８】
は方法Ｃにおいて必要とされないことに留意。
【０１２９】
方法Ｃは方法Ｂ３と本質的に同じ有利な点及び不利な点を有する。方法Ｃは、ベアラがアクティブでない場合であっても更新することができるが、ベアラがスケジューリングされていない期間中に無線状況が変化する場合には、これは、負荷には反映されないであろう。
【０１３０】
Ｒｒｅｑの計算
上記の方法Ｂ及びＣではともに、負荷推定器モジュール４６は、ベアラのための負荷を求めるときに、そのベアラのために必要とされるビットのための値（Ｒｒｅｑ）を使用した。保証ビットレート（ＧＢＲ）ベアラの場合、Ｒｒｅｑは単にベアラの必要とされるＧＢＲに設定することができる。すなわち、以下の通りである。
【０１３１】
【数４０】
0005413631.tif 000041
【０１３２】
遅延に制約があるベアラの場合、２つのオプションがある。最も簡単な手法は、Ｒｒｅｑを、遅延バジェット要件を満たすのに十分であるはずの固定ビットレートに設定することである。これは、ＱｏＳクラスインジケーター（ＱＣＩ）クラス（又はサービス）毎に予め計算し、ルックアップテーブルに格納することができる。このレートは等価ＧＢＲと呼ぶことができる。
【０１３３】
より精巧な手法は、遅延バジェットを満たすのに必要とされるビットレートを直に推定しようと試みることである。或る遅延バジェットを有するＱＣＩクラスｍの場合、以下の式は、或るベアラのための遅延バジェット要件を満たすのに必要とされるビットレートの推定値である。
【０１３４】
【数４１】
0005413631.tif 000042
【０１３５】
ただし、Ｓ（ｔ）は時刻ｔにおけるベアラのＲＬＣ（無線リンク制御）バッファー内の最も古いパケットのサイズ（ビット単位）であり、
ｔ（ａｒｒ）は、この（最も古い）パケットが到着した時刻（すなわち、それがＭＡＣ（媒体アクセス制御）スケジューラーで確認された時刻）であり、
ｔｍ（ＤＢ）は、ＱＣＩクラスｍの場合の（ＭＡＣスケジューラーの）遅延バジェットである。
【０１３６】
その際、負荷推定器モジュール４６は以下の式を設定する。
【０１３７】
【数４２】
0005413631.tif 000043
【０１３８】
ただし、
【０１３９】
【数４３】
0005413631.tif 000044
【０１４０】
はＴｒｅｑ（ｔ）の時間平均であり、その平均の計算は、ベアラが送信すべきデータを有する全てのＴＴＩにわたって実行される。
【０１４１】
ベアラがＧＢＲ及び遅延バジェット制約の両方を有する場合には、負荷推定器モジュール４６は、以下の式を設定する。
【０１４２】
【数４４】
0005413631.tif 000045
【０１４３】
状況によっては、ＲＬＣバッファーへのパケットの正確な到着時刻を容易に推定できない場合がある。たとえば、アップリンクの場合、移動電話ＲＬＣバッファーに新たなパケットが到着しても、基地局５がパケット到着時刻を正確に推定できるようにする情報を、移動電話３からシグナリングすることはできない。しかしながら、ベアラの平均パケットサイズ
【０１４４】
【数４５】
0005413631.tif 000046
【０１４５】
及びパケット到着レートλがわかっている場合には、負荷推定器モジュール４６は、必要とされるビットレート（又は等価ＧＢＲ）を以下のように概算することができる。
【０１４６】
【数４６】
0005413631.tif 000047
ＧＢＲベアラの場合
非ＧＢＲベアラの場合
【０１４７】
アドミッション制御
アドミッション制御（及び他の機能）のためには、セルの全負荷を計算する必要がある。これは、最初に、上記の方法のうちの１つを用いて各ベアラの負荷を計算し、その後、全てのベアラの負荷寄与を合計することによって行なうことができる。
【０１４８】
また、ベアラのクラス（すなわち、サービスタイプ）毎に負荷推定値を与えることが必要とされる場合もある。これは、所与のベアラクラスに属する全てのベアラの負荷寄与を合計することによってなされ得る。代替的には、上記の方法を、個々のベアラの代わりに、ベアラクラスに適用することができる。たとえば、方法Ｂの場合、量
【０１４９】
【数４７】
0005413631.tif 000048
【０１５０】
及び
【０１５１】
【数４８】
0005413631.tif 000049
【０１５２】
をそのクラスに属する全てのベアラに関して計算することができ、その後、それを用いて、そのクラスのための単一の負荷値を計算することができる。
【０１５３】
負荷増加推定
前節は、負荷推定器モジュール４６が既存のベアラの負荷寄与をいかに測定したかを説明した。この節は、新たなベアラが許可される前に、負荷推定器モジュール４６がこれらの新たなベアラの負荷寄与をいかに推定できるかを説明する。この推定値は、アドミッション制御モジュール４７によって、新たなベアラが許可されるべきであるか否かを判断するために用いることができる。
【０１５４】
上記の方法Ｂの公式に従って、新たなベアラの追加によって引き起こされる負荷の増加は、以下のように推定することができる。
【０１５５】
【数４９】
0005413631.tif 000050
【０１５６】
ここで、Ｒｒｅｑは、新たなベアラによって要求されるビットレートを表す。
【０１５７】
【数５０】
0005413631.tif 000051
【０１５８】
を計算するために、考慮されるべきいくつかのオプション及びシナリオがある。
・新たなベアラが１つ以上のアクティブなベアラを既に有する移動電話３に属する（又は実際には既存のベアラのビットレートの変更である）場合には、
【０１５９】
【数５１】
0005413631.tif 000052
【０１６０】
の測定値は、（上記の方法Ｂ１〜Ｂ３のうちのいずれかを用いて）その移動電話３について既に利用可能である場合があり、その場合、この測定値を直に適用することができる。
・さらに、上記の場合に、
【０１６１】
【数５２】
0005413631.tif 000053
【０１６２】
のために推定されたωの平均値を用いる代わりに、負荷推定器モジュール４６は、その推定された確率分布上の任意の点を代用することができる。たとえば、平均の代わりに、５パーセンタイル点（すなわち、その時間の９５％にわたってωが上回る値）を用いることによって、より高いΔρ値が生成されることになり、結果として、より控えめなアドミッション制御ポリシーになる。代替的には、固定のパーセンタイル点を用いる代わりに、推定された平均±推定された標準偏差の或る倍数に等しい値を用いることができる。
・負荷推定器モジュール４６が新たなベアラを要求している移動電話３について利用可能な
【０１６３】
【数５３】
0005413631.tif 000054
【０１６４】
の測定値を有しない場合、負荷推定器モジュール４６は、
・そのセル内の既存の全ての移動電話３にわたる
【０１６５】
【数５４】
0005413631.tif 000055
【０１６６】
の平均値を用いるか、又は
・運営者によって設定される固定値（おそらくサービスタイプ又はＱｏＳクラスに依存する）を用いることができる。
【０１６７】
アクティビティ係数
【０１６８】
【数５５】
0005413631.tif 000056
【０１６９】
はベアラ特有であり、サービスタイプに依存する可能性が高い。したがって、要求している移動電話３が既に既存のベアラを有する場合であっても、アドミッション制御のためにそれらのベアラのアクティビティ測定値を用いることが適切でない場合もある。なぜなら、同じ移動電話３に属していても、異なるベアラは異なるサービスに関連する可能性が高いためである。代わりに、負荷推定器モジュール４６は、
・要求しているベアラに「類似している」（すなわち、同じサービスタイプ又はＱｏＳクラス等の）、そのセル内の既存の全てのベアラにわたる
【０１７０】
【数５６】
0005413631.tif 000057
【０１７１】
の平均値を用いるか、又は
・運営者によって設定される固定値（おそらくサービスタイプ又はＱｏＳクラスに依存する）を用いることができる。
【０１７２】
代替的には、上記の方法Ｃの公式に従って、新たなベアラの追加によって引き起こされる負荷の増加を以下のように推定することができる。
【０１７３】
【数５７】
0005413631.tif 000058
【０１７４】
項
【０１７５】
【数５８】
0005413631.tif 000059
【０１７６】
は上記の方法Ｂの公式における
【０１７７】
【数５９】
0005413631.tif 000060
【０１７８】
に等価であり、したがって、アクティビティ（それはベアラタイプ特有である）及び平均スペクトル効率（ＡＳＥ、それは移動電話特有である）の両方を含むことに留意されたい。
【０１７９】
【数６０】
0005413631.tif 000061
【０１８０】
のための値を得るために、負荷推定器モジュール４６は
・セル内の既存の全てのベアラにわたる
【０１８１】
【数６１】
0005413631.tif 000062
【０１８２】
の平均値を用いるか、又は
・要求しているベアラに「類似している」（すなわち、同じサービスタイプ又はＱｏＳクラス等の）、そのセル内の既存の全てのベアラにわたる
【０１８３】
【数６２】
0005413631.tif 000063
【０１８４】
の平均値を用いるか、又は
・運営者によって設定される固定値（おそらくサービスタイプ又はＱｏＳクラスに依存する）を用いることができる。
【０１８５】
変更及び代替
これまで、いくつかの詳細な例示的な実施形態が説明されてきた。当業者であれば理解するように、それら実施形態に例示される本発明から依然として利益を享受しながら、上記の例示的な実施形態に対して複数の変更及び代替が実施できる。例示としてのみ、ここで、これらの変更及び代替のうちのいくつかを説明する。
【０１８６】
上記の例示的な実施形態では、移動電話ベースの通信システムが説明されてきた。当業者であれば理解するように、本出願において記述される負荷推定技法は、任意のＯＦＤＭＡ通信システムにおいて利用できる。一般的な場合には、基地局及び移動電話は、互いに通信する通信ノード又は機器と見なすことができる。他の通信ノード又は機器は、アクセスポイント、及び、たとえば、携帯情報端末、ラップトップコンピューター、ウエブブラウザ等のユーザー装置を含むこともできる。
【０１８７】
上記の例示的な実施形態では、複数のソフトウエアモジュールが説明された。当業者であれば理解するように、それらのソフトウエアモジュールは、コンパイル済みの形式又は未コンパイルの形式で提供でき、コンピューターネットワークを介した信号として、又は記録媒体上の信号として基地局に供給することもできる。さらに、このソフトウエアの一部又は全部によって実行される機能は、１つ以上の専用のハードウエア回路を用いて実現され得る。しかしながら、ソフトウエアモジュールの使用は、その機能を更新するために基地局５を更新することを容易にするので、好ましい。同様に、上記の例示的な実施形態は送受信機回路部を利用したが、送受信機回路部の機能のうちの少なくともいくつかはソフトウエアによって実行することができる。
【０１８８】
上記の例示的な実施形態では、負荷及び負荷増加推定値を計算するのにいくつかの異なる技法が説明された。負荷推定器は上記の技法のうちのいずれかを用いるように構成することができ、スケジューラーによって提供される情報／測定値（それは供給元特有の場合がある）に応じて、使用すべき方法を選択することができる。
【０１８９】
上記の例示的な実施形態では、負荷推定器は、ベアラのための推定される負荷を計算するときに、いくつかの時間平均を使用した。当業者であれば理解するように、そのような時間平均値を使用することは不可欠ではない。他の代表的な値を用いることもできる。
【０１９０】
上記の例示的な実施形態では、基地局が負荷推定を実行した。他の例示的な実施形態では、他の通信ノードが負荷推定を実行することもでき、おそらくアドミッション制御も実行することができる。そのような他の通信ノードは、コアネットワークの一部を形成することもでき、基地局とコアネットワークとの間のゲートウエイ装置内に配置することもできる。そのような例示的な実施形態では、基地局スケジューラーは、必要とされる測定値を負荷推定装置に供給し、その装置が負荷推定値を求められるようにする。
【０１９１】
種々の他の変更は当業者には明らかであり、ここでは、これ以上詳しくは説明しない。
【０１９２】
本出願は、２００９年５月８日に出願された英国特許出願第０９０７４９２３．７号を基礎としており、該英国特許出願の優先権の利益を主張する。該英国特許出願の開示は、参照によりその全体が本明細書に組み入れられる。
【図１】
0005413631.tif 000081
【図２ａ】
0005413631.tif 000082
【図２ｂ】
0005413631.tif 000083
【図３】
0005413631.tif 000084