特許 5788971 無線ネットワーク内でバッファ・ステータス・レポートを送信するための方法および装置

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

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

(11)【特許番号】5788971

(24)【登録日】2015年8月7日

(45)【発行日】2015年10月7日

(54)【発明の名称】無線ネットワーク内でバッファ・ステータス・レポートを送信するための方法および装置

(51)【国際特許分類】

   H04W 72/02 20090101AFI20150917BHJP

   H04W 72/04 20090101ALI20150917BHJP

【ＦＩ】

   H04W72/02

   H04W72/04 136

【請求項の数】15

【全頁数】19

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

(86)(22)【出願日】2010年5月3日

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

(43)【公表日】2013年6月20日

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

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

(87)【国際公開日】20111110

【審査請求日】2012年12月19日

(73)【特許権者】

【識別番号】391030332

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

(74)【代理人】

【識別番号】100094112

【弁理士】

【氏名又は名称】岡部 讓

(74)【代理人】

【識別番号】100106183

【弁理士】

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

(74)【代理人】

【識別番号】100128657

【弁理士】

【氏名又は名称】三山 勝巳

(74)【代理人】

【識別番号】100160967

【弁理士】

【氏名又は名称】▲濱▼口 岳久

(74)【代理人】

【識別番号】100170601

【弁理士】

【氏名又は名称】川崎 孝

(72)【発明者】

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

(72)【発明者】

【氏名】ヤン，タオ

【審査官】 古市 徹

(56)【参考文献】

【文献】 Samsung，On BSR for REL-10， 3GPP TSG-RAN WG2♯69bis R2-102459，２０１０年 ４月１６日

【文献】 MediaTek，Scheduling mechanism for carrier aggregation， 3GPP TSG-RAN WG2♯69bis R2-102109，２０１０年 ４月 ２日

【文献】 Nokia Siemens Networks, Nokia Corporation，BSR for Carrier Aggregation， 3GPP TSG-RAN WG2♯69bis R2-102164，２０１０年 ４月１６日

【文献】 Alcatel-Lucent Shanghai Bell, Alcatel-Lucent，BSR reporting in Carrier Aggregation， 3GPP TSG-RAN WG2♯70 R2-103277，２０１０年 ５月１４日

【文献】 Alcatel-Lucent Shanghai Bell, Alcatel-Lucent，BSR reporting in Carrier Aggregation， 3GPP TSG-RAN WG2♯70 R2-102880，２０１０年 ５月 ４日

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

Ｈ０４Ｂ ７／２４ − ７／２６

Ｈ０４Ｗ ４／００ − ９９／００

３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１−４

ＳＡ ＷＧ１−２

ＣＴ ＷＧ１

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

【請求項1】

複数のコンポーネント・キャリアで構成されたユーザ装置におけるアップリンク・バッファ・ステータス・レポート・メッセージを報告する方法であって、
Ａ．前記それぞれのコンポーネント・キャリアに対応するそれぞれのメディア・アクセス・レイヤ・プロトコル・データ・ユニットが生成された後、送信されるべきデータの量を取得するステップと、
Ｂ．送信されるべきデータの前記量に従って前記アップリンク・バッファ・ステータス・レポート・メッセージを生成するステップであって、前記ユーザ装置が、標準または定期的バッファ・ステータス・レポート（ＢＳＲ）について、送信時間間隔（ＴＴＩ）ごとに１つのバッファ・ステータス・レポートだけを報告し、該生成するステップは前記アップリンク・バッファ・ステータス・レポート・メッセージおよび最高優先権を有する前記論理チャネルに対応するデータをメディア・アクセス・レイヤ・プロトコル・データ・ユニットにカプセル化するステップをさらに備え、
Ｃ．前記ユーザ装置にサービスしている基地局に前記アップリンク・バッファ・ステータス・レポート・メッセージを報告するステップとを備える、方法。

【請求項2】

前記ステップＣが、
−前記複数のコンポーネント・キャリアのうちの１つを介して前記ユーザ装置にサービスしている前記基地局に前記アップリンク・バッファ・ステータス・レポート・メッセージを送信するステップをさらに備える、請求項１に記載の方法。

【請求項3】

前記それぞれのメディア・アクセス・レイヤ・プロトコル・データ・ユニットが、異なる優先権を有する論理チャネルに対応し、
前記ステップＣが、
前記ユーザ装置にサービスしている前記基地局に、前記アップリンク・バッファ・ステータス・レポート・メッセージがカプセル化されている前記メディア・アクセス・レイヤ・プロトコル・データ・ユニットを送信するステップをさらに備える、請求項２に記載の方法。

【請求項4】

前記ステップＢが、前記アップリンク・バッファ・ステータス・レポート・メッセージを第１メディア・アクセス・レイヤ・プロトコル・データ・ユニットに配置するステップと、前記パディング・ビットを有する少なくとも１つの他のメディア・アクセス・レイヤ・プロトコル・データ・ユニットのパディング・ビット内の前記アップリンク・バッファ・ステータス・レポート・メッセージのコンテンツの少なくとも一部を繰り返し配置するステップとをさらに備え、
前記ステップＣが、前記第１メディア・アクセス・レイヤ・プロトコル・データ・ユニットに対応する第１コンポーネント・キャリアを介して前記基地局に前記アップリンク・バッファ・ステータス・レポート・メッセージを報告するステップと、その間に前記少なくとも１つの他のメディア・アクセス・レイヤ・プロトコル・データ・ユニットに対応する少なくとも１つの他のコンポーネント・キャリアを介して前記基地局に前記アップリンク・バッファ・ステータス・レポート・メッセージの前記コンテンツの前記少なくとも一部を報告するステップとをさらに備える、請求項１に記載の方法。

【請求項5】

繰り返し配置する前記ステップが、
Ｉ．前記パディング・ビットのサイズを取得するステップと、
ＩＩ．前記パディング・ビットが前記アップリンク・バッファ・ステータス・レポート・メッセージのすべての前記コンテンツを含むために十分である場合、前記パディング・ビットを有する前記少なくとも１つの他のメディア・アクセス・レイヤ・プロトコル・データ・ユニットの前記パディング・ビット内の前記アップリンク・バッファ・ステータス・レポート・メッセージのすべての前記コンテンツを繰り返し配置するステップとをさらに備え、
ＩＩ’．十分ではない場合、前記パディング・ビットを有する前記少なくとも１つの他のメディア・アクセス・レイヤ・プロトコル・データ・ユニットの前記パディング・ビット内の前記アップリンク・バッファ・ステータス・レポート・メッセージの前記コンテンツの一部を繰り返し配置する、請求項４に記載の方法。

【請求項6】

前記アップリンク・バッファ・ステータス・レポート・メッセージが異なる優先権を有する論理チャネル・グループのそれぞれのアップリンク・バッファ・ステータス情報を含み、前記ステップＩＩ’が、
−前記アップリンク・バッファ・ステータス・レポート・メッセージが、前記パディング・ビットを有する前記少なくとも１つの他のメディア・アクセス・レイヤ・プロトコル・データ・ユニットの前記パディング・ビット内に繰り返す配置される場合、前記論理チャネル・グループの前記優先権によって、前記対応するアップリンク・バッファ・ステータス情報を満たすステップをさらに備える、請求項５に記載の方法。

【請求項7】

前記それぞれのコンポーネント・キャリアを介する前記メディア・アクセス・レイヤ・プロトコル・データ・ユニットがシリアルに生成され、前記アップリンク・バッファ・ステータス・レポート・メッセージがコンポーネント・キャリアを介する第２メディア・アクセス・レイヤ・プロトコル・データ・ユニットを介して送信されるようにもともとスケジューリングされていた場合、前記ステップＢが、
前記第２メディア・アクセス・レイヤ・プロトコル・データ・ユニットより前にカプセル化されている、少なくとも１つの先行するメディア・アクセス・レイヤ・プロトコル・データ・ユニットのパディング・ビット内の前記アップリンク・バッファ・ステータス・レポート・メッセージの少なくとも一部を含むステップをさらに備え、
前記ステップＢの後に、
−前記全体的なアップリンク・バッファ・ステータス・レポート・メッセージ、または前記アップリンク・バッファ・ステータス・レポート・メッセージの一部が、前記少なくとも１つの先行するメディア・アクセス・レイヤ・プロトコル・データ・ユニットの前記パディング・ビット内に含まれるかどうかを決定するステップと、
−前記全体的なアップリンク・バッファ・ステータス・レポート・メッセージが前記少なくとも１つの先行するメディア・アクセス・レイヤ・プロトコル・データ・ユニットの前記パディング・ビット内に含まれる場合、前記アップリンク・バッファ・ステータス・レポート・メッセージを送信するようにもともとスケジューリングされている、前記第２メディア・アクセス・レイヤ・プロトコル・データ・ユニットの一部内のデータ・コンテンツをカプセル化するステップ、または、
前記アップリンク・バッファ・ステータス・レポート・メッセージの前記一部が前記少なくとも１つの先行するメディア・アクセス・レイヤ・プロトコル・データ・ユニットの前記パディング・ビット内に含まれる場合、前記残りのアップリンク・バッファ・ステータス・レポート・メッセージを前記第２メディア・アクセス・レイヤ・プロトコル・データ・ユニットにカプセル化して、予備の部分内のデータ・コンテンツをカプセル化するステップとをさらに備える、請求項１に記載の方法。

【請求項8】

前記ステップＢが、
−送信されるべきデータの前記量に従って、標準または定期的アップリンク・バッファ・ステータス・レポート・メッセージ、およびパディング・アップリンク・バッファ・ステータス・レポート・メッセージをそれぞれ生成するステップをさらに備え、前記標準または定期的アップリンク・バッファ・ステータス・レポート・メッセージが、送信されるべきデータの前記量が位置する第１の値の範囲を表すために使用され、前記パディング・アップリンク・バッファ・ステータス・レポート・メッセージが、送信されるべきデータの前記量と前記第１の値の範囲の下限との間の差が位置する第２の値の範囲を表すために使用される、請求項１に記載の方法。

【請求項9】

複数のコンポーネント・キャリアで構成されたユーザ装置におけるアップリンク・バッファ・ステータス・レポート・メッセージを報告するための装置であって、
前記それぞれのコンポーネント・キャリアに対応するそれぞれのメディア・アクセス・レイヤ・プロトコル・データ・ユニットが生成された後、送信されるべきデータの量を取得するように構成された第１取得デバイスと、
送信されるべきデータの前記量に従って前記アップリンク・バッファ・ステータス・レポート・メッセージを生成するように構成された生成デバイスであって、標準または定期的バッファ・ステータス・レポート（ＢＳＲ）について、送信時間間隔（ＴＴＩ）ごとに１つのバッファ・ステータス・レポートだけが報告され、前記生成デバイスが、前記アップリンク・バッファ・ステータス・レポート・メッセージおよび最高優先権を有する前記論理チャネルに対応するデータをメディア・アクセス・レイヤ・プロトコル・データ・ユニットにカプセル化するようにさらに構成され、
前記ユーザ装置にサービスしている基地局に前記アップリンク・バッファ・ステータス・レポート・メッセージを報告するように構成された報告デバイスとを備える、装置。

【請求項10】

前記報告デバイスが、
−前記複数のコンポーネント・キャリアのうちの１つを介して前記ユーザ装置にサービスしている前記基地局に前記アップリンク・バッファ・ステータス・レポート・メッセージを送信するようにさらに構成される、請求項９に記載の装置。

【請求項11】

前記それぞれのメディア・アクセス・レイヤ・プロトコル・データ・ユニットが、異なる優先権を有する論理チャネルに対応し、
前記報告デバイスが、
前記ユーザ装置にサービスしている前記基地局に、前記アップリンク・バッファ・ステータス・レポート・メッセージがカプセル化されている前記メディア・アクセス・レイヤ・プロトコル・データ・ユニットを送信するようにさらに構成される、請求項１０に記載の装置。

【請求項12】

前記生成ユニットが、第１メディア・アクセス・レイヤ・プロトコル・データ・ユニット内の前記アップリンク・バッファ・ステータス・レポート・メッセージを生成して、前記パディング・ビットを有する少なくとも１つの他のメディア・アクセス・レイヤ・プロトコル・データ・ユニットのパディング・ビット内の前記アップリンク・バッファ・ステータス・レポート・メッセージのコンテンツの少なくとも一部を繰り返し満たすようにさらに構成され、
前記報告デバイスが、前記第１メディア・アクセス・レイヤ・プロトコル・データ・ユニットに対応する第１コンポーネント・キャリアを介して前記基地局に前記アップリンク・バッファ・ステータス・レポート・メッセージを報告して、その間に前記少なくとも１つの他のメディア・アクセス・レイヤ・プロトコル・データ・ユニットに対応する少なくとも１つの他のコンポーネント・キャリアを介して前記基地局に前記アップリンク・バッファ・ステータス・レポート・メッセージの前記コンテンツの前記少なくとも一部を報告するようにさらに構成される、請求項９に記載の装置。

【請求項13】

前記生成デバイスが、
前記パディング・ビットのサイズを取得するように構成された第２取得デバイスと、
前記パディング・ビットが前記アップリンク・バッファ・ステータス・レポート・メッセージのすべての前記コンテンツを含むために十分である場合、前記パディング・ビットを有する前記少なくとも１つの他のメディア・アクセス・レイヤ・プロトコル・データ・ユニットの前記パディング・ビット内の前記アップリンク・バッファ・ステータス・レポート・メッセージのすべての前記コンテンツを繰り返し満たすようにさらに構成された前記生成デバイスとさらに備え、
十分ではない場合、前記生成デバイスが、前記パディング・ビットを有する前記少なくとも１つの他のメディア・アクセス・レイヤ・プロトコル・データ・ユニットの前記パディング・ビット内の前記アップリンク・バッファ・ステータス・レポート・メッセージの前記コンテンツの一部を繰り返し満たすようにさらに構成される、請求項１２に記載の装置。

【請求項14】

前記それぞれのコンポーネント・キャリアを介する前記メディア・アクセス・レイヤ・プロトコル・データ・ユニットがシリアルに生成され、前記アップリンク・バッファ・ステータス・レポート・メッセージがコンポーネント・キャリアを介する第１メディア・アクセス・レイヤ・プロトコル・データ・ユニットを介して送信されるようにもともとスケジューリングされていた場合、前記生成デバイスが、
前記第２メディア・アクセス・レイヤ・プロトコル・データ・ユニットより前にカプセル化されている、少なくとも１つの先行するメディア・アクセス・レイヤ・プロトコル・データ・ユニットのパディング・ビット内の前記アップリンク・バッファ・ステータス・レポート・メッセージの少なくとも一部を含むようにさらに構成され、
前記装置が、
−前記全体的なアップリンク・バッファ・ステータス・レポート・メッセージ、または前記アップリンク・バッファ・ステータス・レポート・メッセージの一部が、前記少なくとも１つの先行するメディア・アクセス・レイヤ・プロトコル・データ・ユニットの前記パディング・ビット内に含まれるかどうかを決定するように構成された決定デバイスをさらに備え、
前記生成デバイスが、
−前記全体的なアップリンク・バッファ・ステータス・レポート・メッセージが前記少なくとも１つの先行するメディア・アクセス・レイヤ・プロトコル・データ・ユニットの前記パディング・ビット内に含まれる場合、前記アップリンク・バッファ・ステータス・レポート・メッセージを送信するようにもともとスケジューリングされている、前記第２メディア・アクセス・レイヤ・プロトコル・データ・ユニットの一部内のデータ・コンテンツをカプセル化する、または、
前記アップリンク・バッファ・ステータス・レポート・メッセージの前記一部が前記少なくとも１つの先行するメディア・アクセス・レイヤ・プロトコル・データ・ユニットの前記パディング・ビット内に含まれる場合、前記残りのアップリンク・バッファ・ステータス・レポート・メッセージを前記第２メディア・アクセス・レイヤ・プロトコル・データ・ユニットにカプセル化して、予備の部分内のデータ・コンテンツをカプセル化するようにさらに構成される、請求項９に記載の装置。

【請求項15】

前記生成デバイスが、
−送信されるべきデータの前記量に従って、標準または定期的アップリンク・バッファ・ステータス・レポート・メッセージ、およびパディング・アップリンク・バッファ・ステータス・レポート・メッセージをそれぞれ生成するようにさらに構成され、前記標準または定期的アップリンク・バッファ・ステータス・レポート・メッセージが、送信されるべきデータの前記量が位置する第１の値の範囲を表すために使用され、前記パディング・アップリンク・バッファ・ステータス・レポート・メッセージが、送信されるべきデータの前記量と前記第１の値の範囲の下限との間の差が位置する第２の値の範囲を表すために使用される、請求項９に記載の装置。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は無線通信に関し、詳細には、ＬＴＥ−Ａにおけるキャリア・アグリゲーションに基づく基地局およびユーザ装置に関する。

【背景技術】

【0002】

バッファ・ステータス・レポート（ＢＳＲ）は、基地局（進化型ノードＢ、すなわちｅＮＢ）でのスケジューリングに必要なユーザ装置（ＵＥ）側の情報を提供するため、アップリンク・システムにおいて非常に重要である。ロング・ターム・エボリューション・アドバンスト（ＬＴＥ−Ａ）リリース８／９では、バッファ・ステータス・レポートは、それぞれの送信時間間隔（ＴＴＩ）内に１つのメディア・アクセス制御・プロトコル・データ・ユニット（ＭＡＣ ＰＤＵ）しかないので、比較的単純である。しかし、ＬＴＥ−Ａリリース１０では、キャリア・アグリゲーション（ＣＡ）、すなわち複数のコンポーネント・キャリア（ＣＣ）の導入により１つのＴＴＩ内で複数のＭＡＣ ＰＤＵを送信できる。したがって、バッファ・ステータス・レポートで発生するいくつかの新たな問題に対処することが望ましい。

【発明の概要】

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

【0003】

本発明は、バッファ・ステータス・レポートのルールを確立するために、ＬＴＥ−Ａにおける新たな特徴を考慮する。本発明は、キャリア・アグリゲーションを有する通信システムにバッファ・ステータス・レポート・メカニズムを提供する。

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

【0004】

本発明の第１の態様によれば、複数のコンポーネント・キャリアで構成されたユーザ装置におけるアップリンク・バッファ・ステータス・レポート・メッセージを報告する方法が提供され、本方法は、Ａ．それぞれのコンポーネント・キャリアに対応するそれぞれのメディア・アクセス・レイヤ・プロトコル・データ・ユニットが生成された後、送信されるべきデータの量を取得するステップと、Ｂ．送信されるべきデータの量に従ってアップリンク・バッファ・ステータス・レポート・メッセージを生成するステップと、Ｃ．ユーザ装置にサービスしている基地局にアップリンク・バッファ・ステータス・レポート・メッセージを報告するステップとを含む。

【0005】

本発明の第２の態様によれば、複数のコンポーネント・キャリアで構成されたユーザ装置におけるアップリンク・バッファ・ステータス・レポート・メッセージを報告するための装置が提供され、本装置は、それぞれのコンポーネント・キャリアに対応するそれぞれのメディア・アクセス・レイヤ・プロトコル・データ・ユニットが生成された後、送信されるべきデータの量を取得するように構成された第１取得デバイスと、送信されるべきデータの量に従ってアップリンク・バッファ・ステータス・レポート・メッセージを生成するように構成された生成デバイスと、ユーザ装置にサービスしている基地局にアップリンク・バッファ・ステータス・レポート・メッセージを報告するように構成された報告デバイスとを含む。

【0006】

本発明は、１つの送信時間間隔内に複数の送信ブロック、すなわち複数のメディア・アクセス・レイヤ・プロトコル・データ・ユニットがある場合の、バッファ・ステータス情報の報告の仕方の問題に対処する。

【0007】

本発明のソリューションを用いれば、基地局は、より効率的なスケジューリングを保証するために、ユーザ装置にいくつのアップリンク・リソースを割り当てられることができるかを決定的に知ることができる。

【0008】

本発明は、信頼性、効率性、正確さなどの異なる視点から、パディング・バッファ・ステータス・レポート・メッセージを利用でき、それによってバッファ・ステータス・レポート・メッセージの信頼性を向上させ、データ送信の効率性を向上させ、またはバッファ・ステータス・レポート・メッセージの正確さを向上させることができる。

【0009】

本発明の実施形態は、正確さをさらに向上させるために、粗い粒度でバッファ・サイズ・テーブルについてのインクリメント情報をさらに提供することが好ましい。

【0010】

本発明の上述および他の特徴、目的、および利点は、図面を参照して与えられる非限定的実施形態の以下の詳細な説明を検討することにより明らかになるであろう。

【図面の簡単な説明】

【0011】

【図1】本発明の実施形態によるネットワーク・トポロジの概略図である。

【図2】本発明の実施形態によるシステム方法の流れ図である。

【図3】本発明の実施形態による、ＭＡＣ ＰＤＵ内に標準／定期的ＢＳＲとして含まれる長いＢＳＲの例である。

【図4】本発明の実施形態による、第１優先権を有する論理チャネル・グループに対応する短いＢＳＲの例である。

【図5】本発明の実施形態による、第２優先権を有する論理チャネル・グループに対応する短いＢＳＲの例である。

【図6】本発明の実施形態による装置のブロック図である。

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

【0012】

図面を通じて、同一または同様の参照番号は、同一または同様のコンポーネントを指している。

【0013】

まず、本発明の技術的ソリューションを読んで理解することを容易にするために、この説明ではＢＳＲとトリガ手順の種類の簡単な紹介を行う。

【0014】

基地局でのスケジューリングの基本的な考え方は、無線リソースがＵＥだけに割り当てられるか、送信または受信が可能なデータがある場合はＵＥから送信されることにある。ダウンリンクでは、それぞれのＵＥに送信されるべきデータの量は、基地局のスケジューラに明らかに知られている。しかしアップリンク方向では、スケジューリング決定は基地局で行われ、データ・バッファはＵＥに配置されるので、全部でいくつのＵＥのデータが送信されるべきアップリンク・バッファ・エリアに格納されているかの情報を基地局に提供して、基地局がＵＥからのアップリンク・リソース・バッファ情報によってリソースを割り当ててスケジューリングできるようにして、それによって、普通ならリソースの浪費につながるＵＥへの無駄なリソース割当てまたはスケジューリングを回避するために、ＵＥがＢＳＲメッセージを基地局に報告する必要がある。

【0015】

定期的なＢＳＲタイマー（定期的ＢＳＲタイマー）および標準ＢＳＲタイマー（ｒｅｔｘＢＳＲタイマー）を含む２つの構成されたタイマー、ならび論理チャネルにごとに任意のシグナリング論理チャネル・グループがあれば、無線リソース制御（ＲＲＣ）はこの論理チャネルがどの論理チャネル・グループ（ＬＣＧ）に属しているかを示す。

【0016】

ＢＳＲメッセージは、以下の状況が発生するとトリガされうる。
−特定の論理チャネル・グループに属し、ＲＬＣまたはＰＤＣＰエンティティに存在して送信されるべきアップリンクデータ（たとえば、ＲＬＣ／ＰＤＣＰ制御情報、サービス・データなど）を有する論理チャネルがある、または特定の論理チャネル・グループに属する任意の論理チャネルよりも高い優先権を有し、送信されるべきデータを有する論理チャネルがある、あるいは特定の論理チャネル・グループに属する論理チャネルのいずれも送信されるべきいかなるデータも有していない（すなわち、バッファ・エリア・サイズが０のＢＳＲが、ｅＮＢとＵＥとの間のバッファ・エリア情報の同期のために送信される可能性がある）。また、これらの状況においてトリガされるＢＳＲは、「標準ＢＳＲ」と呼ばれる。
−アップリンク・リソースが割り当てられ、パディング・ビットの数が、ＢＳＲ ＭＡＣ制御要素プラスそのサブヘッダ以上であり、この時にトリガされるＢＳＲは「パディングＢＳＲ」に属する。
−ｒｅｔｘＢＳＲタイマーが切れて、特定の論理チャネル・グループに属する任意の論理チャネルが送信されるべきデータを有し、この時にトリガされるＢＳＲは「標準ＢＳＲ」に属する。および、
−定期的ＢＳＲタイマーが切れ、この時にトリガされるＢＳＲは「定期的ＢＳＲ」に属する。

【0017】

標準および定期的ＢＳＲについて、
−複数の論理チャネル・グループ（ＬＣＧ）が、ＢＳＲが送信される現在のＴＴＩ内に送信されるべきデータを有する場合、長いＢＳＲが報告される。
−そうでない場合は、短いＢＳＲが報告される。

【0018】

パディングＢＳＲについて、
−パディング・ビットの数が、短いＢＳＲ制御要素プラスそのサブヘッダ以上であるが、長いＢＳＲ制御要素プラスそのサブヘッダよりも少ない場合は、
−複数の論理チャネル・グループ（ＬＣＧ）が、ＢＳＲが送信される現在のＴＴＩ内に送信されるべきデータを有する場合は切り捨てられたＢＳＲが報告され、このＢＳＲは、送信されるべきデータを有する最高優先権論理チャネルが属する論理チャネル・グループを搬送する。
−そうでない場合は、短いＢＳＲが報告される。
−パディング・ビットの数が、長いＢＳＲ制御要素プラスそのサブヘッダ以上の場合、長いＢＳＲが報告される。

【0019】

したがって、長いＢＳＲを送信する場合、短いＢＳＲまたは切り捨てられたＢＳＲは、ＢＳＲの送信のための有効なアップリンク送信リソースの総数、空ではないバッファのための論理信号の数、および特定のイベントがＵＥにおいてトリガされるかどうかによって決定される。長いＢＳＲは４つの論理チャネル・グループについてのバッファ・データの量を報告し、短いＢＳＲは１つの論理チャネル・グループについてのアップリンク・バッファ・データの量を報告する。

【0020】

図１は、本発明の実施形態によるネットワーク・トポロジの図を示しており、基地局２はユーザ装置１にサービスしており、ユーザ装置１は基地局２にＢＳＲを報告する。

【0021】

図２は、本発明の実施形態によるシステム方法の流れ図を示している。

【0022】

まず、ステップＳ２０で、ユーザ装置１が少なくとも１つのコンポーネント・キャリアで構成されており、ユーザ装置１は、それぞれのコンポーネント・キャリアに対応するそれぞれのメディア・アクセス・レイヤ・プロトコル・データ・ユニットが生成された後、送信されるべきデータの量を取得する。ＬＴＥ−Ａでは、１つのＴＴＩ内で複数のＣＣが同時に送信され、１つのＭＡＣ ＰＤＵが１つのＣＣを介してカプセル化され、ＣＣはＭＡＣ ＰＤＵに１対１で対応する。したがって、ＣＡシナリオでは、１つのＴＴＩ内で複数のＭＡＣ ＰＤＵが同時に送信されうる。ユーザ装置１から基地局２に送信されたＢＳＲは、基地局２に、送信に適したユーザ装置１のアップリンク・バッファ内のデータの量、特にそれぞれのコンポーネント・キャリアを介するすべてのＭＡＣ ＰＤＵが作成された後に送信されるべきバッファ内のデータの量を提供するために使用される。

【0023】

さらに、バッファ・ステータス・レポートＭＡＣ制御要素は、長いＢＳＲフォーマットと短いＢＳＲ／切り捨てられたＢＳＲフォーマットとを含むことができる。

【0024】

次いで、ステップＳ２１で、ユーザ装置１は、送信されるべきデータの量に従ってアップリンク・バッファ・ステータス・レポート・メッセージを生成する。次いで、ステップＳ２２で、ユーザ装置１は、ユーザ装置１にサービスしている基地局２にアップリンク・バッファ・ステータス・レポート・メッセージを報告する。

【0025】

ＣＡシナリオでＢＳＲを生成するステップＳ２１とＢＳＲを報告するステップＳ２２は、それぞれ標準／定期的ＢＳＲおよびパディングＢＳＲについて以下で詳細に説明する。

【0026】

標準／定期的ＢＳＲ
標準／定期的ＢＳＲは、ＣＣ特定情報の代わりにユーザ特定情報を提供するので、すなわち標準／定期的ＢＳＲはＣＣと無関係なので、１つのＴＴＩ内で異なるＣＣを介して複数のＢＳＲを報告する必要はない。したがって、ステップＳ２１で、たとえ１つのＴＴＩ内に異なるＣＣを介して複数のＭＡＣ ＰＤＵがあっても、ユーザ装置１は１つのＣＣのＭＡＣ ＰＤＵ内の１つの標準／定期的ＢＳＲだけを単にカプセル化できる。言い換えると、標準／定期的ＢＳＲについて、ユーザ装置１は、キャリア・アグリゲーション・シナリオではＴＴＩごとに１つのＢＳＲだけ報告する。

【0027】

ユーザ装置１が、どのＭＡＣ ＰＤＵ内にＢＳＲが含まれるべきかを決定する方法は、以下で実施形態において説明する。

【0028】

当業者は、少なくとも１つの論理チャネルを介するサービス・データが１つのＭＡＣ ＰＤＵにおいて多重化され、異なる論理チャネルは異なる優先権を有することが理解できるであろう。サービス品質（ＱｏＳ）を保証するために、まず、アップリンク制御情報（ＵＣＩ）を搬送する物理アップリンク共有チャネル（ＰＵＳＣＨ）を介して送信される信号の送信電力を維持しながら、ＵＣＩを搬送せずにＰＵＳＣＨを介して送信される信号の送信電力を低下させることによって電力が調整され、ＵＣＩはＢＳＲ、電力剰余などを含み、すなわち、ＵＣＩを搬送するＰＵＳＣＨはＵＣＩを搬送しないＰＵＳＣＨよりも高い優先権を有し、すなわち、ＭＡＣ制御要素を搬送するＰＵＳＣＨはより高い優先権を有する。すなわち、ＢＳＲはより高い優先権を有する。したがって、ＢＳＲは、最高優先権を有するチャネルに属するデータを搬送する同じＭＡＣ ＰＤＵ内に含まれるべきであり、すなわち、ステップＳ２１で、ユーザ装置１は最高優先権を有する論理チャネルからのデータとともに、標準／定期的ＢＳＲを同じＭＡＣ ＰＤＵにカプセル化し、たとえば、ユーザ装置は最高ＱｏＳ要求を有するデータ、たとえばＶｏＩＰサービス・データとともに、標準／定期的ＢＳＲを同じＭＡＣ ＰＤＵにカプセル化して、基地局２にＭＡＣ ＰＤＵを送信する。次いで、ステップＳ２２で、ユーザ装置１は、標準／定期的ＢＳＲがカプセル化されているＭＡＣ ＰＤＵを基地局２に報告する。

【0029】

パディングＢＳＲ
ＬＴＥ−Ａリリース８では、上述のように、短いＢＳＲ／切り捨てられたＢＳＲ、または長いＢＳＲをサポートするために十分なパディング・ビットがある場合、パディングＢＳＲがトリガされることになる。リリース８では、１つのＴＴＩ内で１つのＭＡＣ ＰＤＵだけが送信されるので、複数のパディング・ビットで構成されるパディングＢＳＲは最大で１つである。キャリア・アグリゲーション・シナリオでは、複数のＭＡＣ ＰＤＵがあるので、複数のパディングＢＳＲが可能である。

【0030】

現在、ＣＡシナリオにはＭＡＣ ＰＤＵを作成するための２つの代替ソリューションがあり、すなわち、１つは、対応するデータがそれぞれのＭＡＣ ＰＤＵにカプセル化されるまで、１つのＭＡＣ ＰＤＵを生成して、次いで送信されるべき残りのデータの少なくとも一部を次のＭＡＣ ＰＤＵにカプセル化し、以下同様に行うことによって、ＭＡＣ ＰＤＵを特定の順序で連続的にカプセル化することであり、もう１つは、それぞれのコンポーネント・キャリアを介してパラレルに送信されたＭＡＣ ＰＤＵをカプセル化することである。したがって、以下にシリアルおよびパラレルなカプセル化のこれらの２つの状況の考察をそれぞれ行い、まずそれぞれのＣＣを介するＭＡＣ ＰＤＵのシリアル生成について論じる。

【0031】

（１）異なるＣＣを介するＭＡＣ ＰＤＵは、特定の順序でシリアルにカプセル化される。

【0032】

標準／定期的ＢＳＲがトリガされると、次いでＢＳＲ（長いＢＳＲ、または短いＢＳＲ）が１つのＣＣを介して送信され、さらに他のＣＣの他のＭＡＣ ＰＤＵ内のパディング・ビットがパディングＢＳＲの送信のために許可されうる。これらのパディングＢＳＲの異なる使用ソリューションについて論じる。

【0033】

ソリューションＡ：パディング・ビット内のＢＳＲが繰り返し送信される。

【0034】

ユーザ装置１は、１つのコンポーネント・キャリアに対応するＭＡＣ ＰＤＵ内のアップリンク・バッファ・ステータス・レポート・メッセージを生成し、ユーザ装置は、パディング・ビットを有する少なくとも１つの他のＭＡＣ ＰＤＵのパディング・ビット内のアップリンク・バッファ・ステータス・レポート・メッセージのコンテンツの少なくとも一部を繰り返し配置し、すなわちユーザ装置１は全体的な標準／定期的ＢＳＲまたはその一部のコピーを、許可されたパディング・ビットに基づいて長いＢＳＲまたは短い／切り捨てられたＢＳＲの形式で送信する。

【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】

【表1】

【0063】

ある実施形態では、生成ユニット１０１は、第１メディア・アクセス・レイヤ・プロトコル・データ・ユニット内にアップリンク・バッファ・ステータス・レポート・メッセージを生成して、パディング・ビットを有する少なくとも１つの他のメディア・アクセス・レイヤ・プロトコル・データ・ユニットのパディング・ビット内のアップリンク・バッファ・ステータス・レポート・メッセージのコンテンツの少なくとも一部を繰り返し満たすようにさらに構成される。

【0064】

次いで、送信デバイス１０２は、第１コンポーネント・キャリアを介して基地局２にアップリンク・バッファ・ステータス・レポート・メッセージを報告して、その間に少なくとも１つの他のコンポーネント・キャリアを介して基地局２にアップリンク・バッファ・ステータス・レポート・メッセージのコンテンツの少なくとも一部を報告するようにさらに構成される。

【0065】

たとえば、生成デバイス１０１は以下をさらに含む。

【0066】

パディング・ビットのサイズを取得するように構成された第２取得デバイス。また、

【0067】

生成デバイス１０１は、パディング・ビットがアップリンク・バッファ・ステータス・レポート・メッセージのすべてのコンテンツを含むために十分である場合、パディング・ビットを有する少なくとも１つの他のメディア・アクセス・レイヤ・プロトコル・データ・ユニットのパディング・ビット内のアップリンク・バッファ・ステータス・レポート・メッセージのすべてのコンテンツを繰り返し満たすようにさらに構成される。

【0068】

あるいは、生成デバイス１０１は、パディング・ビットを有する少なくとも１つの他のメディア・アクセス・レイヤ・プロトコル・データ・ユニットのパディング・ビット内のアップリンク・バッファ・ステータス・レポート・メッセージのコンテンツの一部を繰り返し満たすようにさらに構成される。

【0069】

他の実施形態では、それぞれのコンポーネント・キャリアを介するメディア・アクセス・レイヤ・プロトコル・データ・ユニットがシリアルに生成され、アップリンク・バッファ・ステータス・レポート・メッセージがコンポーネント・キャリアを介する第１メディア・アクセス・レイヤ・プロトコル・データ・ユニットを介して送信されるようにもともとスケジューリングされている場合、生成デバイス１０１は、第１メディア・アクセス・レイヤ・プロトコル・データ・ユニットより前にカプセル化された、少なくとも１つの以先行するメディア・アクセス・レイヤ・プロトコル・データ・ユニットのパディング・ビット内のアップリンク・バッファ・ステータス・レポート・メッセージの少なくとも一部を含むようにさらに構成され、したがって、装置１０は全体的なアップリンク・バッファ・ステータス・レポート・メッセージまたはアップリンク・バッファ・ステータス・レポート・メッセージの一部が、少なくとも１つの以先行するメディア・アクセス・レイヤ・プロトコル・データ・ユニットのパディング・ビット内に含まれるかどうかを決定するように構成された決定デバイス（図示せず）をさらに含み、生成デバイス１０１は、
−全体的なアップリンク・バッファ・ステータス・レポート・メッセージが少なくとも１つの第１メディア・アクセス・レイヤ・プロトコル・データ・ユニットのパディング・ビット内に含まれる場合、アップリンク・バッファ・ステータス・レポート・メッセージを送信するようにもともとスケジューリングされている、第１メディア・アクセス・レイヤ・プロトコル・データ・ユニットの一部内のデータ・コンテンツをカプセル化するか、
−アップリンク・バッファ・ステータス・レポート・メッセージの一部が少なくとも１つの第１メディア・アクセス・レイヤ・プロトコル・データ・ユニットのパディング・ビット内に含まれる場合、第１メディア・アクセス・レイヤ・プロトコル・データ・ユニット内の残りのアップリンク・バッファ・ステータス・レポート・メッセージをカプセル化して、予備の部分内のデータ・コンテンツをカプセル化するようにさらに構成される。

【0070】

さらに、他の実施形態では、生成デバイス１０１は、
−送信されるべきデータの量に従って、標準または定期的アップリンク・バッファ・ステータス・レポート・メッセージ、およびパディング・アップリンク・バッファ・ステータス・レポート・メッセージをそれぞれ生成するようにさらに構成され、標準または定期的アップリンク・バッファ・ステータス・レポート・メッセージが、送信されるべきデータの量が位置する第１の値の範囲を表すために使用され、パディング・アップリンク・バッファ・ステータス・レポート・メッセージが、送信されるべきデータの量と第１の値の範囲の下限との間の差が位置する第２の値の範囲を表すために使用される。（請求項８，１５）

【0071】

上述の実施形態は例示的なものであり、本発明を限定するものではない点に留意されたい。本発明の趣旨から逸脱しない任意の技術的ソリューションは本発明の範囲内であり、これらは異なる実施形態に現れる異なる技術的特徴の使用、ならびに有利な効果を達成するためのスケジューリング方法の可能な組み合わせを包含する。さらに、特許請求の範囲における任意の参照番号は当該の特許請求の範囲を限定するものと見なされるべきではなく、「備える（ｃｏｍｐｒｉｓｉｎｇ）」という用語は他の特許請求または記述にリストアップされた（されない）デバイスまたはステップを排除せず、デバイスに先行する「ａ／ａｎ」は複数のこのようなデバイスの存在を排除せず、装置に含まれる複数のデバイスの１つまたは複数の機能はハードウェアまたはソフトウェア内の同じモジュールによって実行でき、「第１」、「第２」などの用語は単に名称を示すことを意図しており、何らかの特定の順序を表すものではない。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】