特許 5875581 効率的スケジューリングを支援するためのＢＳＲ情報の送達のための方法およびデバイス

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】5875581

(24)【登録日】2016年1月29日

(45)【発行日】2016年3月2日

(54)【発明の名称】効率的スケジューリングを支援するためのＢＳＲ情報の送達のための方法およびデバイス

(51)【国際特許分類】

   H04W 72/04 20090101AFI20160218BHJP

【ＦＩ】

   H04W72/04 150

【請求項の数】6

【全頁数】22

(21)【出願番号】特願2013-515658(P2013-515658)

(86)(22)【出願日】2010年6月21日

(65)【公表番号】特表2013-531432(P2013-531432A)

(43)【公表日】2013年8月1日

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

(87)【国際公開番号】WO2011160283

(87)【国際公開日】20111229

【審査請求日】2013年1月31日

【審判番号】不服2014-25345(P2014-25345/J1)

【審判請求日】2014年12月11日

(73)【特許権者】

【識別番号】391030332

【氏名又は名称】アルカテル−ルーセント

(74)【代理人】

【識別番号】100094112

【弁理士】

【氏名又は名称】岡部 讓

(74)【代理人】

【識別番号】100106183

【弁理士】

【氏名又は名称】吉澤 弘司

(74)【代理人】

【識別番号】100170601

【弁理士】

【氏名又は名称】川崎 孝

(72)【発明者】

【氏名】ウォレル，チャンドリカ

(72)【発明者】

【氏名】ウェン，ピンピン

【合議体】

【審判長】 近藤 聡

【審判官】 清水 祐樹

【審判官】 吉田 隆之

(56)【参考文献】

【文献】 国際公開第２０１１／１５６９７３（ＷＯ，Ａ１）

【文献】 Ｎｏｋｉａ Ｓｉｅｍｅｎｓ Ｎｅｔｗｏｒｋｓ，Ｎｏｋｉａ Ｃｏｒｐｏｒａｔｉｏｎ，ＢＳＲ ｆｏｒ Ｃａｒｒｉｅｒ Ａｇｇｒｅｇａｔｉｏｎ，３ＧＰＰ ＴＳＧ−ＲＡＮ ＷＧ２ Ｍｅｅｔｉｎｇ ＃７０，Ｒ２−１０２８０５，２０１０年 ５月１４日

【文献】 Ａｌｃａｔｅｌ−Ｌｕｃｅｎｔ Ｓｈａｎｇｈａｉ Ｂｅｌｌ，Ａｌｃａｔｅｌ−Ｌｕｃｅｎｔ，ＢＳＲ ｒｅｐｏｒｔｉｎｇ，３ＧＰＰ ＴＳＧ−ＲＡＮ ＷＧ２ Ｍｅｅｔｉｎｇ ＃７０ｂｉｓ，Ｒ２−１０３６７７，２０１０年 ７月 ２日

(58)【調査した分野】（Int.Cl.，ＤＢ名）

H04W 4/00 - 99/00

(57)【特許請求の範囲】

【請求項1】

ＵＥにおいて、前記ＵＥを支配するｅＮｏｄｅＢにＢＳＲをレポートする方法であって、
Ａ．より大きなバッファ・サイズを有する少なくとも１つのＬＣＧのＢＳＲがレポートされる必要があるかどうかを決定するステップであって、前記より大きなバッファ・サイズを有する前記ＬＣＧは所定の値より大きなバッファ・サイズを有し、前記より大きなバッファ・サイズはレポートのための少なくとも１つの追加の表を必要とし、前記少なくとも１つの追加の表がＲｅｌ．８／９表より大きなバッファ・サイズに対応するバッファ状態を示す、ステップと、
Ｂ．前記より大きなバッファ・サイズを有する前記少なくとも１つのＬＣＧのＢＳＲがレポートされる必要があるときには、前記少なくとも１つの追加の表を参照する索引を有する前記より大きなバッファ・サイズを有する前記少なくとも１つのＬＣＧのＢＳＲを生成するステップと、前記少なくとも１つの追加の表の使用を示すためにＭＡＣサブヘッダ内にＬＣＩＤを割り当てるステップと、
Ｃ．前記ｅＮｏｄｅＢに前記生成されたＢＳＲをレポートするステップとを含み、
前記より大きなバッファ・サイズを有する前記少なくとも１つのＬＣＧのＢＳＲとともに、より小さいバッファ・サイズを有する少なくとも１つのＬＣＧのＢＳＲがレポートされる必要があるときであって、前記より小さいバッファ・サイズを有する前記ＬＣＧは前記所定の値以下のバッファ・サイズを有し、前記より小さいバッファ・サイズが、レポートのためのＲｅｌ．８／９表を必要とするときには、前記ステップＢが、
前記少なくとも１つの追加の表を参照する前記索引を有する前記より大きなバッファ・サイズを有する前記少なくとも１つのＬＣＧのＢＳＲ、および、前記Ｒｅｌ．８／９表を参照する索引を有する前記より小さいバッファ・サイズを有する前記少なくとも１つのＬＣＧのＢＳＲを生成するステップをさらに含み、
少なくとも２つのＭＡＣ制御要素が前記ＢＳＲのレポーティングに使用されるときには、前記方法は、前記ステップＢの前に、
前記より大きなバッファ・サイズを有する前記少なくとも１つのＬＣＧの量を取得するステップをさらに含み、前記ステップＢが、
− 前記より大きなバッファ・サイズを有する前記少なくとも１つのＬＣＧの前記量にしたがってＢＳＲの順序を決定するステップを含み、前記ステップＣが、
− そのＢＳＲの前記順序にしたがって、前記少なくとも１つの追加の表を参照する前記索引を有する前記より大きなバッファ・サイズを有する前記少なくとも１つのＬＣＧのＢＳＲ、および、前記Ｒｅｌ．８／９表を参照する前記索引を有する前記より小さいバッファ・サイズを有する前記少なくとも１つのＬＣＧのＢＳＲを送信するステップとをさらに含む、方法。

【請求項2】

ＵＥにおいて、前記ＵＥを支配するｅＮｏｄｅＢにＢＳＲをレポートする方法であって、
Ａ’．より大きなバッファ・サイズを有する少なくとも１つのＬＣＧのＢＳＲがレポートされる必要があるかどうかを決定するステップであって、前記より大きなバッファ・サイズを有する前記ＬＣＧは所定の値より大きなバッファ・サイズを有し、前記より大きなバッファ・サイズはレポートのための少なくとも１つの追加の表を必要とし、前記少なくとも１つの追加の表がＲｅｌ．８／９表より大きなバッファ・サイズに対応するバッファ状態を示す、ステップと、
Ｂ’．前記より大きなバッファ・サイズを有する前記少なくとも１つのＬＣＧのＢＳＲがレポートされる必要があるときには、前記少なくとも１つの追加の表を参照する索引を有する前記より大きなバッファ・サイズを有する前記少なくとも１つのＬＣＧのＢＳＲを生成するステップと、前記少なくとも１つの追加の表の使用を示すためにＭＡＣサブヘッダ内にＬＣＩＤを割り当てるステップと、
Ｃ’．前記ｅＮｏｄｅＢに前記生成されたＢＳＲをレポートするステップとを含み、
前記より大きなバッファ・サイズを有する前記少なくとも１つのＬＣＧのＢＳＲとともに、より小さいバッファ・サイズを有する少なくとも１つのＬＣＧのＢＳＲがレポートされる必要があるときであって、前記より小さいバッファ・サイズを有する前記ＬＣＧは前記所定の値以下のバッファ・サイズを有し、前記より小さいバッファ・サイズが、レポートのためのＲｅｌ．８／９表を必要とするときには、前記ステップＢ’が、
前記少なくとも１つの追加の表を参照する前記索引を有する前記より大きなバッファ・サイズを有する前記少なくとも１つのＬＣＧのＢＳＲ、および、前記Ｒｅｌ．８／９表を参照する索引を有する前記より小さいバッファ・サイズを有する前記少なくとも１つのＬＣＧのＢＳＲを生成するステップをさらに含み、
１つのＭＡＣ制御要素のみが前記ＢＳＲのレポーティングに使用され、前記ＭＡＣ制御要素の長さが可変であるときには、前記方法は、前記ステップＢ’の前に、
前記より大きなバッファ・サイズを有する前記少なくとも１つのＬＣＧの量を取得するステップをさらに含み、前記ステップＢ’が、
Ｂ１’．前記より大きなバッファ・サイズを有する前記少なくとも１つのＬＣＧの前記量にしたがって前記ＭＡＣ制御要素の長さを決定するステップと、
Ｂ２’．ＭＡＣサブヘッダ内の予約されたビットまたはＭＡＣサブヘッダのＬフィールドを使用して、前記ＭＡＣ制御要素の前記長さを示すステップとをさらに含む、方法。

【請求項3】

前記ステップＢ’が、
− 前記より大きなバッファ・サイズを有する前記少なくとも１つのＬＣＧの前記量にしたがってＢＳＲの順序を決定するステップを含み、前記ステップＣ’が、
− そのＢＳＲの前記順序にしたがって、前記少なくとも１つの追加の表を参照する前記索引を有する前記より大きなバッファ・サイズを有する前記少なくとも１つのＬＣＧのＢＳＲ、および、前記Ｒｅｌ．８／９表を参照する前記索引を有する前記より小さいバッファ・サイズを有する前記少なくとも１つのＬＣＧのＢＳＲを送信するステップとをさらに含む、請求項２に記載の方法。

【請求項4】

ＵＥを支配するｅＮｏｄｅＢにＢＳＲをレポートする前記ＵＥ内の第１のデバイスであって、
より大きなバッファ・サイズを有する少なくとも１つのＬＣＧのＢＳＲがレポートされる必要があるかどうかを決定するように構成された第１の決定手段であって、前記より大きなバッファ・サイズを有する前記ＬＣＧは所定の値より大きなバッファ・サイズを有し、前記より大きなバッファ・サイズは、レポートのための少なくとも１つの追加の表を必要とし、前記少なくとも１つの追加の表がＲｅｌ．８／９表より大きなバッファ・サイズに対応するバッファ状態を示す、第１の決定手段と、
前記より大きなバッファ・サイズを有する前記少なくとも１つのＬＣＧのＢＳＲがレポートされる必要があるときには、前記少なくとも１つの追加の表を参照する索引を有する前記より大きなバッファ・サイズを有する前記少なくとも１つのＬＣＧのＢＳＲを生成し、前記少なくとも１つの追加の表の使用を示すためにＭＡＣサブヘッダ内のＬＣＩＤを割り当てるように構成された生成手段と、
前記ｅＮｏｄｅＢに前記生成されたＢＳＲをレポートするように構成されたレポーティング手段とを備え、
前記より大きなバッファ・サイズを有する前記少なくとも１つのＬＣＧのＢＳＲとともに、より小さいバッファ・サイズを有する少なくとも１つのＬＣＧのＢＳＲがレポートされる必要があるときであって、前記より小さいバッファ・サイズを有する前記ＬＣＧは前記所定の値以下のバッファ・サイズを有し、前記より小さいバッファ・サイズは、レポートのためのＲｅｌ．８／９表を必要とするときには、前記生成手段が、
前記少なくとも１つの追加の表を参照する前記索引を有する前記より大きなバッファ・サイズを有する前記少なくとも１つのＬＣＧのＢＳＲ、および、前記Ｒｅｌ．８／９表を参照する索引を有する前記より小さいバッファ・サイズを有する前記少なくとも１つのＬＣＧのＢＳＲを生成するようにさらに構成され、
少なくとも２つのＭＡＣ制御要素が前記ＢＳＲをレポートするために使用されるときには、第１のデバイスが
前記より大きなバッファ・サイズを有する前記少なくとも１つのＬＣＧの量を取得するように構成された取得手段をさらに備え、
前記生成手段が、
− 前記より大きなバッファ・サイズを有する前記少なくとも１つのＬＣＧの前記量にしたがってＢＳＲの順序を決定するように構成され、そして、前記レポーティング手段が、
− 前記ＢＳＲの順序にしたがって、前記少なくとも１つの追加の表を参照する前記索引を有する前記より大きなバッファ・サイズを有する前記少なくとも１つのＬＣＧのＢＳＲ、および、前記Ｒｅｌ．８／９表を参照する前記索引を有する前記より小さいバッファ・サイズを有する前記少なくとも１つのＬＣＧのＢＳＲを送信する、ようにさらに構成された、第１のデバイス。

【請求項5】

ＵＥを支配するｅＮｏｄｅＢにＢＳＲをレポートする前記ＵＥ内の第１のデバイスであって、
より大きなバッファ・サイズを有する少なくとも１つのＬＣＧのＢＳＲがレポートされる必要があるかどうかを決定するように構成された第１の決定手段であって、前記より大きなバッファ・サイズを有する前記ＬＣＧは所定の値より大きなバッファ・サイズを有し、前記より大きなバッファ・サイズは、レポートのための少なくとも１つの追加の表を必要とし、前記少なくとも１つの追加の表がＲｅｌ．８／９表より大きなバッファ・サイズに対応するバッファ状態を示す、第１の決定手段と、
前記より大きなバッファ・サイズを有する前記少なくとも１つのＬＣＧのＢＳＲがレポートされる必要があるときには、前記少なくとも１つの追加の表を参照する索引を有する前記より大きなバッファ・サイズを有する前記少なくとも１つのＬＣＧのＢＳＲを生成し、前記少なくとも１つの追加の表の使用を示すためにＭＡＣサブヘッダ内のＬＣＩＤを割り当てるように構成された生成手段と、
前記ｅＮｏｄｅＢに前記生成されたＢＳＲをレポートするように構成されたレポーティング手段とを備え、
前記より大きなバッファ・サイズを有する前記少なくとも１つのＬＣＧのＢＳＲとともに、より小さいバッファ・サイズを有する少なくとも１つのＬＣＧのＢＳＲがレポートされる必要があるときであって、前記より小さいバッファ・サイズを有する前記ＬＣＧは前記所定の値以下のバッファ・サイズを有し、前記より小さいバッファ・サイズは、レポートのためのＲｅｌ．８／９表を必要とするときには、前記生成手段が、
前記少なくとも１つの追加の表を参照する前記索引を有する前記より大きなバッファ・サイズを有する前記少なくとも１つのＬＣＧのＢＳＲ、および、前記Ｒｅｌ．８／９表を参照する索引を有する前記より小さいバッファ・サイズを有する前記少なくとも１つのＬＣＧのＢＳＲを生成するようにさらに構成され、
１つのＭＡＣ制御要素のみが前記ＢＳＲをレポートするために使用され、前記ＭＡＣ制御要素の長さが可変であるときには、第１のデバイスが、
前記より大きなバッファ・サイズを有する前記少なくとも１つのＬＣＧの量を取得するように構成された取得手段をさらに備え、
前記生成手段が、
− 前記より大きなバッファ・サイズを有する前記少なくとも１つのＬＣＧの前記量にしたがって前記ＭＡＣ制御要素の長さを決定し、そして、
− ＭＡＣサブヘッダ内の予約されたビットまたはＭＡＣサブヘッダ内のＬフィールドを使用して前記ＭＡＣ制御要素の前記長さを示す、ようにさらに構成された、第１のデバイス。

【請求項6】

前記生成手段が、
前記より大きなバッファ・サイズを有する前記少なくとも１つのＬＣＧの前記量にしたがってＢＳＲの順序を決定するように構成され、そして、前記レポーティング手段が、
そのＢＳＲの前記順序にしたがって、前記少なくとも１つの追加の表を参照する前記索引を有する前記より大きなバッファ・サイズを有する前記少なくとも１つのＬＣＧのＢＳＲ、および、前記Ｒｅｌ．８／９表を参照する前記索引を有する前記より小さいバッファ・サイズを有する前記少なくとも１つのＬＣＧのＢＳＲを送信する、ようにさらに構成された、請求項５に記載の第１のデバイス。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ワイヤレス電気通信の分野のｅＮｏｄｅＢおよびＵＥに関し、詳細には、効率的スケジューリングを支援するためのＢＳＲ情報の送達のための方法およびデバイスに関する。

【背景技術】

【0002】

ロングターム・エボリューション・アドバンスト（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ−Ａｄｖａｎｃｅｄ、ＬＴＥ−ＡｄｖａｎｃｅｄまたはＬＴＥ−Ａ、Ｒｅｌ．１０）でのキャリア・アグリゲーション（ＣＡ）の導入で、Ｒｅｌ．８／９（ＬＴＥ）でサポートされる１つのみのＭＡＣ ＰＤＵに比べて１移送時間間隔（ＴＴＩ）内に多数のメディア・アクセス制御パケット・データ・ユニット（ＭＡＣ ＰＤＵ）が存在し、結果として、Ｒｅｌ．１０ユーザ機器（ＵＥ）は、非常に大きなデータ・スループットをサポートすることができることになる。

【0003】

ＵＥからｅＮｏｄｅＢへのバッファ状態レポート（ＢＳＲ）は、ｅＮｏｄｅＢの、アップリンク無線リソースの割当てを支援するために使用される。ＬＴＥでのスケジューリングの基礎を成す基本前提は、データが送信または受信するために使用可能である場合、無線リソースはＵＥへの、またはＵＥからの送信のために割り当てられるのみであることである。ダウンリンク方向では、ｅＮｏｄｅＢ内のスケジューラは、各ＵＥに送達されることになるデータの量をはっきりと認識しているが、アップリンク方向では、スケジューリング決定はｅＮｏｄｅＢで実行され、データのバッファはＵＥ内に置かれているので、ＢＳＲをＵＥからｅＮｏｄｅＢに送り、ＵＬ−ＳＣＨを介して送信される必要があるＵＥ内のデータの量を示さなければならない。

【0004】

２つのタイプのＢＳＲ、すなわち長いＢＳＲおよび短いＢＳＲ、がＬＴＥにおいて定義され、そのうちの１つが、ＢＳＲを送信するための利用可能なアップリンク送信リソースの量、いくつの論理チャネル・グループ（ＬＣＧ）が非空のバッファを有するか、および、特定のイベントがＵＥでトリガされているかどうかに応じて、送信される。長いＢＳＲは４つの論理チャネル・グループのデータの量をレポートするのに対して、短いＢＳＲは１つのみの論理チャネル・グループのデータの量をレポートする。ＵＥには実際には４つを超える論理チャネルが設定される可能性があるが、ＵＥ内のデータの量が個々にあらゆる論理チャネルについてレポートされる場合、そのオーバヘッドは大きくなることになる。したがって、レポーティングの目的で論理チャネルを４つのグループに分けることが、効率と正確さの折衷案を表す。

【0005】

ＢＳＲは、ＵＥバッファ内で待っているデータの量を含み、それは、ＭＡＣ層信号伝達（ＭＡＣ ＣＥまたはＭＡＣ制御要素）を使用して送信される。許容される最大バッファ・サイズ、すなわちＲｅｌ．８／９レポーティングにおける１５００００バイト、は、より高いデータ・レートの信号送出には十分ではなく、したがって、Ｒｅｌ．８／９方法の使用で正確にＵＥバッファ・サイズをｅＮｏｄｅＢに知らせることはできない。

【発明の概要】

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

【0006】

したがって、より高いデータ・レートがｅＮｏｄｅＢに伝達可能な方法および対応するシステムを設計することが必要である。しかし、Ｒｅｌ．８／９ ＵＥはまた、Ｒｅｌ．１０ネットワーク内のＲｅｌ．１０ ＵＥとともに存在することになるので、その設計はＲｅｌ．８／９の方法の後方互換性もまた保証すべきである。

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

【0007】

後方互換性が順守される必要があるので、本発明は、既存の表（Ｒｅｌ．８／９表とも呼ばれる、たとえば以下の表２：ＢＳＲのバッファ・サイズ・レベル）よりも高いデータ・レートに対応するバッファ像を示す少なくとも１つの追加の表（拡張表とも呼ばれる）を紹介する。その少なくとも１つの追加の表の使用は、１つまたは複数の新しい識別、より詳細には１つまたは複数の論理チャネルＩＤ（略してＬＣＩＤ）、によって識別される。その信号伝達は、Ｒｅｌ．８／９でのＭＡＣ層信号伝達を使用する。本発明の一実施形態では、新しいＭＡＣ ＣＥは、低いまたは高いデータ・レートに応じたＲｅｌ．８／９およびＲｅｌ．１０バッファ状態レポーティングの共存を保証するように設計される。

【0008】

バッファ状態の情報は、１つまたは２つのＭＡＣ ＣＥのいずれかを使用することによって、ｅＮｏｄｅＢに提供される。１つのＭＡＣ ＣＥがＢＳＲの信号伝達に十分である場合、ＭＡＣ ＣＥヘッダで使用されるＬＣＩＤは、どのＢＳＲ表が使用されたか（Ｒｅｌ．８／９ ＢＳＲ表あるいは１つまたは複数の追加のＢＳＲ表のいずれか）を示す。２つのＭＡＣ ＣＥがＢＳＲの信号伝達に必要である場合、第１のＭＡＣ ＣＥ内容内のデータは、第２のＭＡＣ ＣＥの送信を示す。

【0009】

本発明の一態様によれば、前記ＵＥを支配するｅＮｏｄｅＢにＢＳＲをレポートするＵＥにおける方法であって、Ａ．より高いバッファ・サイズを有するＬＣＧは所定の値より大きなバッファ・サイズを有し、より大きなバッファ・サイズを有する少なくとも１つの前記ＬＣＧのＢＳＲが少なくとも１つの追加の表がレポートされることを必要とするかどうかを判定するステップと、Ｂ．より大きなバッファ・サイズを有する前記少なくとも１つのＬＣＧのＢＳＲがレポートされる必要がある場合に、Ｒｅｌ．８／９表よりも高いデータ・レートに対応するバッファ状態を示す前記少なくとも１つの追加の表を参照する索引を有するより高いバッファ・サイズを有する前記少なくとも１つのＬＣＧのＢＳＲを生成するステップと、Ｃ．前記ｅＮｏｄｅＢに前記生成されたＢＳＲをレポートするステップとを備える方法が提供される。

【0010】

本発明の第２の態様によれば、前記ＵＥからのＢＳＲを処理するＵＥを支配するｅＮｏｄｅＢにおける方法であって、Ｉ．前記ＵＥからＢＳＲを受信するステップと、ＩＩ．前記受信されたＢＳＲから導出されたＬＣＩＤにしたがって、前記受信されたＢＳＲがより大きなバッファ・サイズを有する少なくとも１つのＬＣＧのＢＳＲであるかどうかを判定するステップであって、より大きなバッファ・サイズを有する前記ＬＣＧは所定の値より大きなバッファ・サイズを有する、ステップと、ＩＩＩ．より大きなバッファ・サイズを有する少なくとも１つのＬＣＧの前記ＢＳＲが使用される場合に、前記ＢＳＲおよび少なくとも１つの追加の表にしたがってそのバッファ・サイズを取得し、前記バッファ・サイズにしたがって前記ＵＥのＵＬリソースをスケジュールするステップであって、前記少なくとも１つの追加の表はＲｅｌ．８／９表よりも高いデータ・レートに対応するバッファ状態を示す、ステップとを備える方法が提供される。

【0011】

本発明は、高いデータ・レートのより正確なバッファ状態の送信を可能にし、それによって、スケジューラ効率を改善する。いくつかの好ましい実施形態によれば、電波インターフェースでの信号伝達オーバヘッドは低減される。

【0012】

本発明の他の特徴、態様および利点は、添付の図面を参照して、非限定的実施形態の以下の説明を読むことによって、明らかとなろう。

【図面の簡単な説明】

【0013】

【図1A】Ｒｅｌ．８／９の短いＢＳＲおよび短縮されたＢＳＲ ＭＡＣ制御要素を示す図である。

【図1B】長いＢＳＲ ＭＡＣ制御要素を示す図である。

【図1C】Ｒ／Ｒ／Ｅ／ＬＣＩＤ ＭＡＣサブヘッダを示す図である。

【図2A】Ｒｅｌ．８／９フォーマットと同じ長いＢＳＲを示した、追加の表を有するＢＳＲレポートを示す図である。

【図2B】ＬＣＧ＃１の追加のＢＳＲ表を使用する短いＢＳＲを示した、追加の表を有するＢＳＲレポートを示す図である。

【図2C】ＬＣＧ＃２の追加のＢＳＲ表を使用する短いＢＳＲを示した、追加の表を有するＢＳＲレポートを示す図である。

【図3】追加の長いＢＳＲ表の使用を示す図である。

【図4A】追加の長いＢＳＲ表の使用を示した、拡張された長いＢＳＲおよびＲｅｌ．８／９の短いＢＳＲの使用を示す図である。

【図4B】Ｒｅｌ．８／９フォーマットと同じ短いＢＳＲを示した、拡張された長いＢＳＲおよびＲｅｌ．８／９の短いＢＳＲの使用を示す図である。

【図5】ＢＳＲの新しいフォーマットのユーザを示す図である。

【図6】バイトで可変ＢＳＲ ＭＡＣ ＣＥの長さを示すＬフィールドを示す図である。

【図7】ＭＡＣ ＣＥ内容の最初の２ビットがＢＳＲ表を示すために使用されることを示す図である。

【図8】ＢＳＲのもう１つの新しいフォーマットの使用を示す図である。

【図9】本発明のネットワーク接続形態を示す図である。

【図10】本発明の一実施形態による方法の系統的流れ図を示す図である。

【図11】本発明の一実施形態によるデバイスのブロック図である。

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

【0014】

これらの図に置いて、同じまたは同様の参照番号は、同じまたは同様のステップまたは手段を指す。

【0015】

添付の図面とともに詳細に本発明の実施形態の例示的説明が与えられる。

【0016】

ＬＴＥ Ｒｅｌ．８／９では、バッファ状態はＬＣＧで測定される。４つまでのＬＣＧが定義されてある。

【0017】

バッファ状態レポート（ＢＳＲ）ＭＡＣ制御要素は、以下の何れかから成る。すなわち
− 短いＢＳＲおよび短縮されたＢＳＲフォーマット：図１Ａに示すような１つのＬＣＧ ＩＤフィールドおよび１つの対応するバッファ・サイズ・フィールド、または、
− 長いＢＳＲフォーマット：図１Ｂに示すようなＬＣＧ ＩＤ＃０から＃３までに対応する、４つのバッファ・サイズ・フィールド。

【0018】

論理チャネル・グループの数がアクティブであり、すべてのＬＣＧについてＢＳＲを送信する必要がある場合、長いＢＳＲが使用される。ただ１つのＬＣＧについてＢＳＲが送信されることになる場合、短いＢＳＲが使用される。

【0019】

図１Ａおよび１Ｂに示すフィールドＬＣＧ ＩＤおよびバッファ・サイズは、以下のように定義される。すなわち
− ＬＣＧ ＩＤ：論理チャネル・グループＩＤフィールドは、バッファ状態がレポートされている１つまたは複数の論理チャネルのグループを識別する。そのフィールドの長さは２ビットであり、長いＢＳＲが送信されるとき、ＬＣＧ ＩＤは、ＭＡＣ制御要素には含まれず、代わりに、ＭＡＣ制御要素内のＢＳＲの順番がＬＣＧを定義し、短いＢＳＲが送信される場合、ＬＣＧ ＩＤはＭＡＣ ＣＥの内容に含まれてＬＣＧを識別する。
− バッファ・サイズ：バッファ・サイズ・フィールドは、ＭＡＣ ＰＤＵが構築された後に、論理チャネル・グループのすべての論理チャネルに亘って利用可能なデータの総量を識別する。そのデータの量は、バイト数で示される。それは、ＲＬＣ層内およびＰＤＣＰ層内の送信に利用可能なすべてのデータを含むことになる。このフィールドの長さは６ビットである。バッファ・サイズ・フィールドによって取られる値は、表２に示される。

【0020】

ＢＳＲフォーマットは、表１に指定されるようなＬＣＩＤを有するＭＡＣ ＰＤＵサブヘッダによって識別される。

【0021】

【表1】

【0022】

ＭＡＣ ＰＤＵヘッダは１つまたは複数のＭＡＣ ＰＤＵサブヘッダから成り、各サブヘッダはＭＡＣ ＳＤＵ、ＭＡＣ制御要素またはパディングに相当する。

【0023】

ＭＡＣヘッダは、可変サイズであり、以下のフィールドから成る。すなわち
− ＬＣＩＤ：論理チャネルＩＤフィールドは、ＵＬ−ＳＣＨについて表１に記載するように、対応するＭＡＣ ＳＤＵの論理チャネル・インスタンスまたは対応するＭＡＣ制御要素もしくはパディングのタイプを識別する。各ＭＡＣ ＳＤＵ、ＭＡＣ制御要素、またはＭＡＣ ＰＤＵに含まれるパディングには１つのＬＣＩＤフィールドがある。そのＬＣＩＤフィールド・サイズは５ビットである、
− Ｌ：長さフィールドは、図７にも示すように、対応するＭＡＣ ＳＤＵの長さをバイトで示す。最後のサブヘッダおよび固定サイズのＭＡＣ制御要素に対応するサブヘッダを除いて、ＭＡＣ ＰＤＵサブヘッダ毎に１つのＬフィールドがある。Ｌフィールドのサイズは、Ｆフィールドによって示される、
− Ｆ：フォーマットフィールドは、長さフィールドのサイズを示す。最後のサブヘッダおよび固定サイズのＭＡＣ制御要素に対応するサブヘッダを除いてＭＡＣ ＰＤＵサブヘッダ毎に１つのＦフィールドがある。Ｆフィールドのサイズは１ビットである。ＭＡＣ ＳＤＵまたは可変サイズのＭＡＣ制御要素のサイズが１２８バイトよりも小さい場合、Ｆフィールドの値は０にセットされ、そうでない場合には、それは１にセットされる、
− Ｅ：拡張フィールドは、より多くのフィールドがＭＡＣヘッダ内に存在するかしないかを示すフラグである。Ｅフィールドは、「１」に設定されて、少なくともＲ／Ｒ／Ｅ／ＬＣＩＤフィールドのもう１つのセットを示す。Ｅフィールドは、「０」に設定されて、ＭＡＣ ＳＤＵ、ＭＡＣ制御要素またはパディングの何れかが次のバイトで開始することを示す、
− Ｒ：予約されたビット、「０」に設定される。

【0024】

ＭＡＣ ＰＤＵサブヘッダは、ＭＡＣ ＰＤＵ内の最後のサブヘッダおよび固定サイズのＭＡＣ制御要素を別にすると、６つのヘッダ・フィールドＲ／Ｒ／Ｅ／ＬＣＩＤ／Ｆ／Ｌで構成される。ＭＡＣ ＰＤＵ内の最後のサブヘッダおよび固定サイズのＭＡＣ制御要素のサブヘッダは、４つのヘッダ・フィールドＲ／Ｒ／Ｅ／ＬＣＩＤだけで構成される。パディングに対応するＭＡＣ ＰＤＵサブヘッダは、４つのヘッダ・フィールドＲ／Ｒ／Ｅ／ＬＣＩＤで構成される。

【0025】

表２は、Ｒｅｌ．８／９で使用されるＢＳＲ表を示す。表索引は、ＢＳＲ ＭＡＣ ＣＥで信号送出され、６ビットがＢＳＲ索引に使用される。本表の索引６３は、バッファ状態が１５００００バイトより大きいが、１５００００バイトより高いデータ・レートに対応するバッファのバッファ・サイズの細分性表現は与えられないことを示す。

【0026】

本発明では、４つのＬＣＧが、Ｒｅｌ．８／９におけるのと同じように、Ｒｅｌ．１０で使用されると仮定される。同様に６ビットのインディケータもＲｅｌ．８／９ ＢＳＲ索引に使用される。１つまたは複数の追加の表は、スケジューラにより高いレートのより粒度の細かいＢＳＲ情報を提供することができる。１つまたは複数の追加のＢＳＲ表はＲｅｌ．８／９ ＢＳＲ表と並行して使用されることになると仮定される。

【0027】

より高いビット・レートの信号伝達に必要とされる１つまたは複数の表の数は、より高いＢＳＲ値の必要とされる細分性に依存する。ＬＴＥ−Ａの最大許容ＵＬデータ・レートは、Ｒｅｌ．８／９ＵＬデータ・レートのそれに比べて６〜７という因数により増えた（すなわち、ＬＴＥ−Ａについては５００ＭｂｐｓＵＬレートであり、一方、ＬＴＥについては７５Ｍｂｐｓレートである）。ＬＴＥ−Ａの最大バッファ・サイズの増加はＵＬビット・レートの増加率に比例すると仮定するのが論理的である。１つまたはいくつかの追加の表が、高いデータ・レートの信号伝達に必要とされると仮定される。１つまたは複数の追加の表は、１５００００バイトを超えるデータに使用される、すなわち、第１の追加の表の索引０はＢＳ＜１５００００バイトに対応する。必要とされる追加の表の数は、ＢＳレポーティングの細分性によって定義される。以下の例では、１つのみの追加の表が十分であると仮定されるが、ＢＳＲの細分性が表現のために複数の追加の表を必要とする場合には複数の追加の表が使用され得ることが、当業者には理解され、同時に使用される異なる追加の表はそれら自体の固有の拡張ＢＳＲ表ＩＤを有する。Ｒｅｌ．８／９ ＢＳＲ表およびレポーティング・フォーマットは、追加の表と並行して使用される。新しい拡張ＬＣＩＤは、拡張表を示すために、使用される。新しい拡張ＬＣＩＤは、前述の表１で既に使用された値とは異なる予約された値を使用すべきである。

【0028】

図９は、本発明のネットワーク接続形態を示す。図９で、ＵＥ１は、ｅＮｏｄｅＢ２によって支配され、ｅＮｏｄｅＢ２内のスケジューラがｅＮｏｄｅＢ２によってレポートされるバッファ状態にしたがってＵＥ１のアップリンク伝送リソースをスケジュールすることができるように、ＵＥ１はそのバッファ状態をｅＮｏｄｅＢ２にレポートする。

【0029】

図１０は、本発明の一実施形態による方法の系統的流れ図を示す。

【0030】

第１に、ステップＳ１００で、ＵＥ１が、より大きなバッファ・サイズを有する少なくとも１つのＬＣＧのＢＳＲが少なくとも１つの追加の表がレポートされることを必要とするかどうかを判定し、そのより高いバッファ・サイズを有するＬＣＧは所定の値より大きなバッファ・サイズを有する。

【0031】

ＵＥ１が、レポートされる必要がある論理チャネル・グループのバッファ・サイズを測定し、より大きなバッファ・サイズを有する少なくとも１つのＬＣＧが少なくとも１つの追加の表がレポートされることを必要とするかどうかを判定する。Ｒｅｌ．８／９のＢＳＲのバッファ・サイズ・レベルの最も大きい索引６３がＢＳ＞１５００００を表すことがＬＴＥ Ｒｅｌ．８／９に既に規定されているので、第１の追加の表の所定の値は１５００００に設定することができることが、当業者には理解され得る。もちろん、必要に応じて第２のまたは他の１つのもしくは複数の追加の表の所定の値が、ＵＥの実際のＵＬデータ・レートに基づいて、電気通信ネットワーク・オペレータおよびサービス・プロバイダによって設定され得る。そのような１つまたは複数の追加の表は、より正確な細分性のみならずより高いデータ量もまた提供するために、使用される。

【0032】

次いで、ステップＳ１０１で、より大きなバッファ・サイズを有する少なくとも１つのＬＣＧのＢＳＲがレポートされる必要がある場合、ＵＥ１が少なくとも１つの追加の表を参照する索引を有するより高いバッファ・サイズを有するその少なくとも１つのＬＣＧのＢＳＲを生成し、そして、その少なくとも１つの追加の表は、Ｒｅｌ．８／９表よりも高いデータ・レートに対応するバッファ状態を示す。ステップＳ１０１の詳細は、以下の例とともに以下に説明される。

【0033】

本発明では、既存のＲｅｌ．８／９ ＢＳＲ表のみが表２に示され、追加の１つまたは複数のＢＳＲ表は示されない。しかし、追加のＢＳＲ表の特定の設計、たとえば値およびマッピング関係、は、本発明の核となる概念とは無関係であり、したがって、簡単にするために省略されることが、当業者には理解され得る。

【0034】

【表2】

【0035】

例１
たとえば、４つのＬＣＧの中から、２つのＬＣＧがＲｅｌ．８／９ ＢＳＲ表で信号送出され得る低いデータを有すると仮定される。他の２つのＬＣＧは、ＢＳＲを送信するために追加の表を必要とする高いデータを有する。ＢＳＲ情報は、２つのＭＡＣ ＣＥ、Ｒｅｌ．８／９の長いＢＳＲおよび拡張された短いＢＳＲ、を使用してｅＮｏｄｅＢに送信される。

【0036】

このフォーマットは図２に示される。先ず、Ｒｅｌ．８／９の長いＢＳＲフォーマットが、ｅＮｏｄｅＢに長いＢＳＲを知らせるために、使用される。高いデータ・レートを有するＬＣＧは、ＭＡＣ ＣＥ内で索引６３（ＢＳ＞１５００００バイト）を示し、たとえば、＃２および＃３ＬＣＧは１５００００バイトより大きなバッファ・サイズを有し、そのため、バッファ・サイズ＃２およびバッファ・サイズ＃３の索引は両方とも６３である。第２に、ＵＥが、追加のＢＳＲ表を使用して高いデータを有する２つのＬＣＧのＢＳＲを送信する。たとえば、図２Ｂの短いＢＳＲでは、ＬＣＧ ＩＤは＃２でもよく、そして、そのバッファ・サイズは、追加のＢＳＲ表を参照する索引を使用し、一方、図２Ｃの短いＢＳＲ内のＬＣＧ ＩＤは＃３でもよく、そのバッファ・サイズは、追加のＢＳＲ表を参照する索引を使用する。追加のＢＳＲ表が使用されることを示すために、新しいＬＣＩＤ拡張された短いＢＳＲ−ＬＣＩＤが使用されることに留意されたい。そのＬＣＧ ＩＤ（Ｒｅｌ．８／９におけるような）は、拡張された短いＢＳＲ ＭＡＣ ＣＥにおいて対応する論理チャネル・グループを識別するために使用される。第１のＭＡＣ ＣＥ（Ｒｅｌ．８／９の長いＢＳＲ）内の索引６３は、長いＢＳＲに続いて送信される追加のＢＳＲ情報を信号送出される。すべての３つのＢＳＲ、具体的には１つの長いＢＳＲおよび２つの短いＢＳＲ、は、同じＭＡＣ ＰＤＵ内で結合および送信され得ることに留意されたい。

【0037】

たとえば、Ｒｅｌ．８／９表を参照する１つのＬＣＧのＢＳＲが送信される必要があり、追加のＢＳＲ表を参照する３つのＬＣＧのＢＳＲが送信される必要があるなど、そのようなＢＳＲフォーマットはすべての状況に適用することが、当業者には理解され得る。

【0038】

例２
たとえば、すべての４つのＬＣＧが追加のＢＳＲ表を必要とする高いデータを有すると仮定する。この場合、４つの拡張された短いＢＳＲとともにＲｅｌ．８／９の長いＢＳＲを送信することが効率的である。したがって、新しいＬＣＩＤは、図３に示すように、拡張された長いＢＳＲを示すように割り当てられる。具体的には、すべての４つのＬＣＧ＃０、＃１、＃２および＃３のバッファ・サイズは、そのバッファ・サイズを示すために、追加のＢＳＲ表を参照する索引を使用する。

【0039】

例３
４つのＬＣＧのうちの３つは拡張ＢＳＲの送信を必要とすると仮定する。この場合、拡張された長いＢＳＲが第１に送信され、そして、低いデータを有するＬＣＧは追加のＢＳＲ表の最下の索引、たとえば０、によって示され、ＢＳ＜１５００００である。これは、Ｒｅｌ．８／９の短いＢＳＲを使用する以下のＢＳＲを信号送出するために使用される。これは、ＢＳＲの効率的送信を可能にすることになる。このフォーマットは図４に示される。

【0040】

本発明の好ましい一実施形態では、オーバヘッドを考慮して、より大きなバッファ・サイズを有する１つまたは複数のＬＣＧの量が、拡張ＢＳＲまたはＲｅｌ．８／９ ＢＳＲの送信の順序、すなわち、拡張（Ｒｅｌ．１０）ＢＳＲまたはＲｅｌ．８／９ ＢＳＲが最初に送信されるべきかどうかを判定するために、使用され得る。

【0041】

たとえば、より小さいバッファ・サイズを有するＬＣＧの量がより大きなバッファ・サイズを有するＬＣＧのそれよりも大きいとき、より小さいバッファ・サイズを有するＬＣＧのＢＳＲがＲｅｌ．８／９の長いＢＳＲで第１に送信され、そして、より大きなバッファ・サイズを有するＬＣＧのＢＳＲが、次いで、新しいＬＣＩＤを有する短いＢＳＲで送信され（すなわち、図２Ａ〜２Ｃに示す実施例１）、そうして、ＭＡＣサブヘッダのオーバヘッドは実施例３の場合に比べて減らすことができ、より大きなバッファ・サイズを有するＬＣＧの量がより小さいバッファ・サイズを有するＬＣＧの量より大きいとき、より大きなバッファ・サイズを有するＬＣＧのＢＳＲが、新しいＬＣＩＤを有する長いＢＳＲで第１に送信され（すなわち、図４Ａ〜４Ｂに示す実施例３）、そして、より小さいバッファ・サイズを有するＬＣＧのＢＳＲが、次いで、Ｒｅｌ．８／９の短いＢＳＲで送信される。

【0042】

例４
− 解決法Ａ：
本シナリオは、実施例１と同じである。拡張された短いＢＳＲの追加のサブヘッダの送信によるオーバヘッドを減らすために、本方法は、結合されたＲｅｌ．８／９ ＢＳＲ表および追加のＢＳＲ表情報の送信のための新しいＭＡＣ ＣＥフォーマットを提案する。１つの新しいＬＣＩＤが、その新しいＭＡＣ ＣＥフォーマットを識別するために使用される。このフォーマットは、図５に示される。第１に、Ｒｅｌ．８／９ ＢＳＲ表および長いＢＳＲ順序にしたがってバッファ状態が定義される。次いで、必要とされるＬＣＧの拡張ＢＳＲが、その短いＢＳＲフォーマットを使用し、定義される。この解決法では、１つのみのＢＳＲ ＭＡＣ ＣＥが送信される。

【0043】

言い換えれば、図５で、ＭＡＣサブヘッダ内の拡張された長いＢＳＲ−ＬＣＩＤが新しいＢＳＲフォーマットが使用されることを示し、そして、Ｒｅｌ．８／９ ＢＳＲ表を参照する長いＢＳＲ内のバッファ・サイズ索引が第１に送信され、一方で、追加のＢＳＲ表を参照する長いＢＳＲに続く短いＢＳＲ内のバッファ・サイズ索引が第２に送信される。

【0044】

さらに、ＭＡＣ ＣＥの長さは可変であり、それは、拡張ＢＳＲ送信を必要とするＬＣＧの数に依存する。ＭＡＣ ＣＥの長さは、ＭＡＣサブヘッダの２つの予約ビット（Ｒ）によって示され得る。または、別法として、ＭＡＣ ＣＥの長さは、図６に示すようにＭＡＣサブヘッダのＬフィールドで示され得る。図６に示すＭＡＣサブヘッダは、制御要素の送信のためではなく、Ｒｅｌ．８／９データ伝送におけるＭＡＣ ＳＤＵのサイズを示すために使用され、一方、Ｒｅｌ．１０におけるＭＡＣ ＣＥの長さは可変でもよいので、Ｒｅｌ．１０では、ＭＡＣサブヘッダは、ＭＡＣ ＣＥの長さを示すために使用されるＬフィールドを有するＭＡＣ ＣＥに使用され得る。

【0045】

− 解決法Ｂ：
この解決法のもう１つの代替が、以下に説明される。本方法は、結合されたＲｅｌ．８／９ ＢＳＲ表および追加のＢＳＲ表情報の送信のための新しいＭＡＣ ＣＥフォーマットを提案する。１つの新しいＬＣＩＤが、新しいＭＡＣ ＣＥフォーマットを識別するために使用される。このフォーマットは、図８に示される。第１に、追加のＢＳＲ表および長いＢＳＲ順序にしたがってバッファ状態が定義される。次いで、必要とされるＬＣＧのＲｅｌ．８／９ ＢＳＲが、その短いＢＳＲフォーマットを使用し、定義される。この解決法では、１つのみのＢＳＲ ＭＡＣ ＣＥが送信される。

【0046】

言い換えれば、図８で、ＭＡＣサブヘッダ内の拡張された長いＢＳＲ−ＬＣＩＤは新しいＢＳＲフォーマットが使用されることを示し、そして、追加のＢＳＲ表を参照する長いＢＳＲ内のバッファ・サイズ索引が第１に送信され、一方、Ｒｅｌ．８／９ ＢＳＲを参照する長いＢＳＲに続く短いＢＳＲ内のバッファ・サイズ索引は第２に送信される。

【0047】

本発明の好ましい一実施形態では、ＭＡＣ ＣＥの全バイトを考慮し、より大きなバッファ・サイズを有する１つまたは複数のＬＣＧの量が、拡張ＢＳＲまたはＲｅｌ．８／９ ＢＳＲの送信の順序、すなわち、拡張（Ｒｅｌ．１０）ＢＳＲまたはＲｅｌ．８／９ ＢＳＲが最初に送信されるべきかどうか、を判定するために使用され得る。

【0048】

たとえば、より小さいバッファ・サイズを有するＬＣＧの量がより大きなバッファ・サイズを有するＬＣＧの量よりも大きいとき、より小さいバッファ・サイズを有するＬＣＧのＢＳＲがＲｅｌ．８／９の長いＢＳＲで第１に送信され、より大きなバッファ・サイズを有するＬＣＧのＢＳＲが次いで、短いＢＳＲで送信され（すなわち、図５に示す解決法Ａ）、そうして、ＭＡＣ ＣＥの全バイトは図８に示す解決法Ｂに比べて減らすことができ、より大きなバッファ・サイズを有するＬＣＧの量がより小さいバッファ・サイズを有するＬＣＧの量より大きいとき、より大きなバッファ・サイズを有するＬＣＧのＢＳＲが、第１に長いＢＳＲで送信され（すなわち、図８に示す解決法Ｂ）、そして、より小さいバッファ・サイズを有するＬＣＧのＢＳＲが、次いで、Ｒｅｌ．８／９の短いＢＳＲで送信される（すなわち、図５に示す解決法Ａ）。

【0049】

− 解決法Ｃ：
新しい長いＢＳＲ ＭＡＣ ＣＥフォーマットのもう１つの代替が図７に示される。ここでは、サブヘッダ内の新しいＬＣＩＤは、新しい長いＢＳＲフォーマットを示す。ＢＳＲが属するＬＣＧが、ＭＡＣ ＣＥ内容内の順序によって識別される。６ビットが、バッファ・サイズを示すために、使用される。各バイトの最初の２ビットは、ＢＳＲ表を示す。たとえば、００はＲｅｌ．８／９ ＢＳＲ表を示し、一方、０１は追加のＢＳＲ表を示す。

【0050】

短いＢＳＲについて、本方法はまた使用され得る。表索引は、ＭＡＣサブヘッダの予約ビット（２つの表につき１ビット）によって示され得る。

【0051】

加えて、すべてのＬＣＧがレポートする必要があるＢＳＲが所定の値よりも小さいバッファ・サイズを有する場合には、Ｒｅｌ．８／９ ＢＳＲ表は十分であり、それは先行技術の範囲内にあり、そのような状況は簡単にするために詳細に記載されない。

【0052】

次いで、ステップＳ１０２で、ＵＥ１が、生成されたＢＳＲをｅＮｏｄｅＢ２にレポートする。

【0053】

次いで、ステップＳ１０３で、ｅＮｏｄｅＢ２が、ＵＥ１からＢＳＲを受信する。

【0054】

ステップＳ１０４で、ｅＮｏｄｅＢ２は、受信されたＢＳＲから導出された、ＭＡＣ制御要素内のＬＣＩＤまたは関連ビット、たとえば図７に示すシナリオに示された表ＩＤ、にしたがって、受信されたＢＳＲがより大きなバッファ・サイズを有する少なくとも１つのＬＣＧのＢＳＲであるかどうかを判定し、より大きなバッファを有する前記ＬＣＧは所定の値より大きなバッファ・サイズを有する。

【0055】

ステップＳ１０５で、拡張ＢＳＲが使用される場合、ｅＮｏｄｅＢ２は、ＢＳＲおよび少なくとも１つの追加の表にしたがってバッファ・サイズを取得し、そのバッファ・サイズにしたがってＵＥ１のＵＬリソースをスケジュールし、その少なくとも１つの追加の表は、Ｒｅｌ．８／９表よりも高いデータ・レートに対応するバッファ状態を示す。

【0056】

図１１は、本発明の一実施形態によるデバイスのブロック図を示す。

【0057】

図１１に示す第１のデバイス１０は、図９および図１０に示すＵＥ１内で構成可能であり、一方、図１２に示す第２のデバイス２０は、図９および図１０に示すｅＮｏｄｅＢ２内に構成可能である。

【0058】

第１のデバイス１０は、第１の判定手段１００、生成手段１０１およびレポーティング手段１０２を備え、第２のデバイス２０は、受信機２００、第２の判定手段２０１およびスケジューラ２０２を備える。

【0059】

第１に、ステップＳ１００で、第１の判定手段１００が、より大きなバッファ・サイズを有する少なくとも１つのＬＣＧのＢＳＲが少なくとも１つの追加の表がレポートされることを必要とするかどうかを判定し、より高いバッファ・サイズを有するそのＬＣＧは所定の値より大きなバッファ・サイズを有する。

【0060】

ＵＥ１が、レポートされる必要がある論理チャネル・グループのバッファ・サイズを測定し、第１の判定手段１００が、より大きなバッファ・サイズを有する少なくとも１つのＬＣＧが少なくとも１つの追加の表がレポートされることを必要とするかどうかを判定する。ＬＴＥ Ｒｅｌ．８／９では、Ｒｅｌ．８／９内のＢＳＲのバッファ・サイズ・レベルの最も大きい索引６３はＢＳ＞１５００００を表すと既に規定されているので、第１の追加の表の所定の値は１５００００に設定することができることが、当業者には理解され得る。もちろん、必定に応じて第２のまたは他の１つもしくは複数の追加の表の所定の値は、ＵＥの実際のＵＬデータ・レートに基づいて電気通信ネットワーク・オペレータおよびサービス・プロバイダによって設定可能である。そのような１つまたは複数の追加の表は、より正確な細分性のみならずより高いデータ量を提供するために使用される。

【0061】

次いで、より大きなバッファ・サイズを有する少なくとも１つのＬＣＧのＢＳＲがレポートされる必要がある場合、生成手段１０１が、少なくとも１つの追加の表を参照する索引を有するより高いバッファ・サイズを有する少なくとも１つのＬＣＧのＢＳＲを生成し、そして、少なくとも１つの追加の表が、Ｒｅｌ．８／９表よりも高いデータ・レートに対応するバッファ状態を示す。生成手段１０１によって実行されるプロセスの詳細は、以下の例とともに以下に説明される。

【0062】

本発明では、既存のＲｅｌ．８／９ ＢＳＲ表のみが表２の上に示され、１つまたは複数の追加のＢＳＲ表は示されない。しかし、追加のＢＳＲ表の特定の設計、たとえば値およびマッピング関係、は、本発明の核となる概念とは無関係であり、したがって、簡単にするために省略されることが、当業者には理解され得る。

【0063】

例１
たとえば、４つのＬＣＧのうち、２つのＬＣＧが、Ｒｅｌ．８／９ ＢＳＲ表で信号送出され得る低いデータを有すると仮定する。他の２つのＬＣＧは、追加の表がＢＳＲを送信することを要求する高いデータを有する。ＢＳＲ情報は、２つのＭＡＣ ＣＥ、Ｒｅｌ．８／９の長いＢＳＲおよび拡張された短いＢＳＲ、を使用し、ｅＮｏｄｅＢに送信される。

【0064】

このフォーマットは図２に示される。第１に、Ｒｅｌ．８／９の長いＢＳＲフォーマットが、ｅＮｏｄｅＢに長いＢＳＲを知らせるために、使用される。バッファ・サイズ＃２およびバッファ・サイズ＃３の索引は両方とも６３であるように、高いデータ・レートを有するＬＣＧは、ＭＡＣ ＣＥ内の索引６３（ＢＳ＞１５００００バイト）を示す、たとえば、＃２および＃３ＬＣＧは１５００００バイトより大きなバッファ・サイズを有する。第２に、レポーティング手段１０２が、追加のＢＳＲ表を使用し、高いデータを有する２つのＬＣＧのＢＳＲをレポートする。たとえば、図２Ｂの短いＢＳＲでは、ＬＣＧ ＩＤは＃２でもよく、そのバッファ・サイズは、追加のＢＳＲ表を参照する索引を使用し、一方、図２Ｃの短いＢＳＲ内のＬＣＧ ＩＤは＃３でもよく、そのバッファ・サイズは追加のＢＳＲ表を参照する索引を使用する。新しいＬＣＩＤ拡張された短いＢＳＲ−ＬＣＩＤは、追加のＢＳＲ表が使用されることを示すために使用されることに留意されたい。ＬＣＧ ＩＤ（Ｒｅｌ．８／９でのような）は、拡張された短いＢＳＲ ＭＡＣ ＣＥ内の対応する論理チャネル・グループを識別するために使用される。第１のＭＡＣ ＣＥ（Ｒｅｌ．８／９の長いＢＳＲ）内の索引６３は、長いＢＳＲに続いて送信される追加のＢＳＲ情報を信号送出される。すべての３つのＢＳＲ、具体的には１つの長いＢＳＲおよび２つの短いＢＳＲ、は、同じＭＡＣ ＰＤＵ内に結合および送信可能であることに留意されたい。

【0065】

そのようなＢＳＲフォーマットは、Ｒｅｌ．８／９表を参照する１つのＬＣＧのＢＳＲが送信される必要があり、追加のＢＳＲ表を参照する３つのＬＣＧのＢＳＲが送信される必要があるなど、すべての状況に適用することが、当業者には理解され得る。

【0066】

例２
たとえば、すべての４つのＬＣＧが追加のＢＳＲ表を必要とする高いデータを有すると仮定する。この場合、４つの拡張された短いＢＳＲとともにＲｅｌ．８／９の長いＢＳＲを送信することは非効率的である。したがって、新しいＬＣＩＤは、図３に示すような拡張された長いＢＳＲを示すように割り当てられる。具体的には、すべての４つのＬＣＧ＃０、＃１、＃２および＃３についてバッファ・サイズは、追加のＢＳＲ表を参照する索引を使用してそのバッファ・サイズを示す。

【0067】

例３
４つのＬＣＧのうちの３つは拡張ＢＳＲの送信を必要とすると仮定する。この場合、拡張された長いＢＳＲが第１に送信され、低いデータを有するＬＣＧは追加のＢＳＲ表の最下の索引、たとえば０、によって示され、ＢＳ＜１５００００である。これは、Ｒｅｌ．８／９の短いＢＳＲを使用する以下のＢＳＲを信号送出するために使用される。これは、ＢＳＲの効率的伝送を可能にすることになる。このフォーマットは図４に示される。

【0068】

本発明の好ましい一実施形態では、オーバヘッドを考慮して、より大きなバッファ・サイズを有する１つまたは複数のＬＣＧの量が、拡張ＢＳＲまたはＲｅｌ．８／９ ＢＳＲの送信の順序、すなわち、拡張（Ｒｅｌ．１０）ＢＳＲまたはＲｅｌ．８／９ ＢＳＲが最初に送信されるべきかどうか、を判定するために使用され得る。

【0069】

たとえば、より小さいバッファ・サイズを有するＬＣＧの量がより大きなバッファ・サイズを有するＬＣＧの量よりも大きいとき、より小さいバッファ・サイズを有するＬＣＧのＢＳＲがＲｅｌ．８／９の長いＢＳＲを有するレポーティング手段１０２によって第１に送信され、そして、より大きなバッファ・サイズを有するＬＣＧのＢＳＲが、次いで、新しいＬＣＩＤを有する短いＢＳＲで送信され（すなわち、図２Ａ〜２Ｃに示す実施例１）、そうして、ＭＡＣサブヘッダのオーバヘッドは実施例３の場合に比べて減らすことができ、より大きなバッファ・サイズを有するＬＣＧの量がより小さいバッファ・サイズを有するＬＣＧの量より大きいとき、大きなバッファ・サイズを有するＬＣＧのＢＳＲは、新しいＬＣＩＤを有する長いＢＳＲで第１に送信され（すなわち、図４Ａ〜４Ｂに示す実施例３）、そして、より小さいバッファ・サイズを有するＬＣＧのＢＳＲが、次いで、Ｒｅｌ．８／９の短いＢＳＲで送信される。

【0070】

例４
− 解決法Ａ：
本シナリオは実施例１と同じである。拡張された短いＢＳＲの追加のサブヘッダの送信によるオーバヘッドを減らすために、本方法は、結合されたＲｅｌ．８／９ ＢＳＲ表および追加のＢＳＲ表情報の送信のための新しいＭＡＣ ＣＥフォーマットを提案する。１つの新しいＬＣＩＤが、その新しいＭＡＣ ＣＥフォーマットを識別するために使用される。このフォーマットは、図５に示される。第１に、Ｒｅｌ．８／９ ＢＳＲ表および長いＢＳＲ順序にしたがってバッファ状態が定義される。次いで、必要とされるＬＣＧの拡張ＢＳＲが、その短いＢＳＲフォーマットを使用し、定義される。この解決法では、１つのみのＢＳＲ ＭＡＣ ＣＥが送信される。

【0071】

言い換えれば、図５では、ＭＡＣサブヘッダ内の拡張された長いＢＳＲ−ＬＣＩＤは新しいＢＳＲフォーマットが使用されることを示し、そして、Ｒｅｌ．８／９ ＢＳＲ表を参照する長いＢＳＲ内のバッファ・サイズ索引が第１に送信され、一方、追加のＢＳＲ表を参照する長いＢＳＲに続く短いＢＳＲ内のバッファ・サイズ索引が第２に送信される。

【0072】

さらに、ＭＡＣ ＣＥの長さは可変であり、それは拡張ＢＳＲ伝送を必要とするＬＣＧの数に依存する。ＭＡＣ ＣＥの長さは、ＭＡＣサブヘッダの２つの予約ビット（Ｒ）によって示され得る。または、別法として、ＭＡＣ ＣＥの長さは、図６に示すようにＭＡＣサブヘッダのＬフィールドで示され得る。図６に示すＭＡＣサブヘッダはＲｅｌ．８／９データ伝送内のＭＡＣ ＳＤＵのサイズを示すために使用されるが、制御要素の伝送についてではなく、一方、Ｒｅｌ．１０におけるＭＡＣ ＣＥの長さは可変でもよいので、Ｒｅｌ．１０では、ＭＡＣサブヘッダは、ＭＡＣ ＣＥの長さを示すために使用されるＬフィールドでＭＡＣ ＣＥのために使用され得る。

【0073】

− 解決法Ｂ：
本解決方法のもう１つの代替が、以下に説明される。本方法は、結合されたＲｅｌ．８／９ ＢＳＲ表および追加のＢＳＲ表情報の送信のための新しいＭＡＣ ＣＥフォーマットを提案する。１つの新しいＬＣＩＤが、新しいＭＡＣ ＣＥフォーマットを識別するために使用される。このフォーマットは、図８に示される。第１に、追加のＢＳＲ表および長いＢＳＲ順序にしたがってバッファ状態が定義される。次いで、必要とされるＬＣＧのＲｅｌ．８／９ ＢＳＲが、その短いＢＳＲフォーマットを使用し、定義される。この解決法では、１つのみのＢＳＲ ＭＡＣ ＣＥが送信される。

【0074】

言い換えれば、図８において、ＭＡＣサブヘッダ内の拡張された長いＢＳＲ−ＬＣＩＤが新しいＢＳＲフォーマットが使用されることを示し、そして、追加のＢＳＲ表を参照する長いＢＳＲ内のバッファ・サイズ索引が第１に送信され、一方、Ｒｅｌ．８／９ ＢＳＲを参照する長いＢＳＲに続く短いＢＳＲ内のバッファ・サイズ索引が第２に送信される。

【0075】

本発明の好ましい一実施形態では、ＭＡＣ ＣＥの全バイトを考慮し、より大きなバッファ・サイズを有する１つまたは複数のＬＣＧの量が、拡張ＢＳＲまたはＲｅｌ．８／９ ＢＳＲの送信の順序、すなわち、拡張（Ｒｅｌ．１０）ＢＳＲまたはＲｅｌ．８／９ ＢＳＲが最初に送信されるべきかどうかを判定するために使用され得る。

【0076】

たとえば、より小さいバッファ・サイズを有するＬＣＧの量がより大きなバッファ・サイズを有するＬＣＧの量よりも大きいとき、より小さいバッファ・サイズを有するＬＣＧのＢＳＲがＲｅｌ．８／９の長いＢＳＲで第１に送信され、そして、より大きなバッファ・サイズを有するＬＣＧのＢＳＲが、次いで、短いＢＳＲで送信され（すなわち、図５に示す解決法Ａ）、そうして、ＭＡＣ ＣＥの全バイトは図８に示す解決法Ｂに比べて減らすことができ、より大きなバッファ・サイズを有するＬＣＧの量がより小さいバッファ・サイズを有するＬＣＧの量より大きいとき、より大きなバッファ・サイズを有するＬＣＧのＢＳＲが第１に長いＢＳＲで送信され（すなわち、図８に示す解決法Ｂ）そして、より小さいバッファ・サイズを有するＬＣＧのＢＳＲが、次いで、Ｒｅｌ．８／９の短いＢＳＲで送信される（すなわち、図５に示す解決法Ａ）。

【0077】

− 解決法Ｃ：
新しい長いＢＳＲ ＭＡＣ ＣＥフォーマットのもう１つの代替が、図７に示される。ここでは、サブヘッダ内の新しいＬＣＩＤは、新しい長いＢＳＲフォーマットを示す。ＢＳＲが属するＬＣＧが、ＭＡＣ ＣＥ内容内の順序によって識別される。６ビットが、バッファ・サイズを示すために使用される。各バイトの最初の２ビットが、ＢＳＲ表を示す。たとえば、００は、Ｒｅｌ．８／９ ＢＳＲ表を示し、一方、０１は、追加のＢＳＲ表を示す。

【0078】

短いＢＳＲについて、本方法はやはり使用され得る。その表索引は、ＭＡＣサブヘッダの予約ビット（２つの表につき１ビット）によって示され得る。

【0079】

加えて、レポートするのに必要なすべてのＬＣＧのＢＳＲが所定の値よりも小さいバッファ・サイズを有する場合には、Ｒｅｌ．８／９ ＢＳＲ表は十分であり、これは先行技術の範囲内にあり、そのような状況は簡単にするために与えられていない。

【0080】

次いで、レポーティング手段１０２が、生成されたＢＳＲをｅＮｏｄｅＢ２にレポートする。

【0081】

次いで、ｅＮｏｄｅＢ２内の受信機２００が、ＵＥ１からＢＳＲを受信する。

【0082】

次いで、第２の判定手段２０１が、受信されたＢＳＲから導出された、ＭＡＣ制御要素内のＬＣＩＤまたは関連ビット、たとえば図７に示すシナリオに示された表ＩＤ、にしたがって、受信されたＢＳＲがより大きなバッファ・サイズを有する少なくとも１つのＬＣＧのＢＳＲであるかどうかを判定し、より大きなバッファを有する前記ＬＣＧは所定の値より大きなバッファ・サイズを有する。

【0083】

拡張ＢＳＲが使用される場合、スケジューラ２０２は、ＢＳＲおよび少なくとも１つの追加の表にしたがってバッファ・サイズを取得し、そのバッファ・サイズにしたがってＵＥ１のＵＬリソースをスケジュールし、その少なくとも１つの追加の表は、Ｒｅｌ．８／９表よりも高いデータ・レートに対応するバッファ状態を示す。

【0084】

Ｒｅｌ．８／９表および追加の表はネットワーク構成段階中にＵＥ１およびｅＮｏｄｅＢ２の両方の側で同期されることが、当業者には理解され得る。たとえば、Ｒｅｌ．８／９表および追加の表は、層３信号伝達でＵＥ１およびｅＮｏｄｅＢ２の両方に送信され、そうして、ｅＮｏｄｅＢ２は、ＵＥ１のそれと同じＢＳＲ ＭＡＣ制御要素内の索引が表すものの解釈を有する。

【0085】

本発明の実施形態が、前述された。本発明は特定のシステム、デバイスまたはプロトコルに限定されず、様々な変更または修正が添付の特許請求の範囲の範囲および趣旨を逸脱することなしに行われ得ることが、当業者には理解されよう。

【0086】

前述の実施形態は例示のみを目的とし、本発明の制限として解釈されないことが、当業者には理解され得る。本発明は、これらの実施形態に限定されない。本発明の趣旨を逸脱しないすべての技術的解決法が、添付の特許請求の範囲に含まれるものとする。加えて、特許請求の範囲では、丸括弧の間に置かれたいかなる参照記号も、特許請求の範囲を限定するものとして解釈されない。「備える」という言葉は、特許請求の範囲にまたは本明細書に記載されていない要素またはステップの存在を排除しない。要素の前の「１つの」という言葉は、そのような要素の複数の存在を排除しない。複数の手段を含むデバイスにおいて、それらの複数の手段の１つまたは複数の機能は、１つのハードウェアまたはソフトウェアモジュールによって実装可能であり、「第１の」、「第２の」および「第３の」の言葉は単に名を表し、特定の順番を意味しない。

【図1A】

【図1B】

【図1C】

【図2A】

【図2B】

【図2C】

【図3】

【図4A】

【図4B】

【図5】

【図6】

【図7】

【図8】

【図11】

【図9】

【図10】