JP5438822B2 - バッファ状態報告を報告する方法、端末及びネットワークシステム - Google Patents

Description

本発明は、無線通信技術分野に関し、特に、無線ネットワークにおいて、バッファ状態報告を報告する方法、端末及びネットワークシステムに関する。

第３世代移動通信ロングタームエボリューション（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ：ＬＴＥと略称する）システムの進化型ユニバーサル地上無線アクセスネットワーク（Ｅｖｏｌｖｅｄ Ｕｎｉｖｅｒｓａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ：Ｅ−ＵＴＲＡＮと略称する）において、アップリンクのデータは、物理アップリンク共有チャネル（Ｐｈｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ：ＰＵＳＣＨと略称する）を介して伝送される。進化型基地局（Ｅｖｏｌｖｅｄ ＮｏｄｅＢ：ｅＮＢと略称する）によって、アップリンク無線リソースは、各ユーザ端末装置（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ：ＵＥと略称する）に割当てられる。Ｅ−ＵＴＲＡＮシステムに採用されたアクセス技術は、直交周波数分割多重（Ｏｒｔｈｏｇｏｎａｌ Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅｘｉｎｇ：ＯＦＤＭと略称する）技術である。Ｅ−ＵＴＲＡＮシステムの無線リソース管理は、第２世代移動通信システムに比べて、帯域幅が大きく、タイムコースが多いという特徴を有する。Ｅ−ＵＴＲＡＮシステムの無線リソースは、２次元の時間周波数リソースであり、搬送されるユーザの数が大いに増加した。

ＬＴＥシステムの無線リソース制御（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ：ＲＲＣと略称する）層は、ＲＲＣメッセージを送信することによって、ＵＥとｅＮＢとの間にＲＲＣ層リンクの確立、システムパラメータの設定、ＵＥの能力パレメータの伝達などの多くの処理を実現する。ダウンリンクのＲＲＣメッセージは、物理ダウンリンク共有チャネル（Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ：ＰＤＳＣＨと略称する）において送信される。システムに関する共通パラメータ、例えば、セル周波数ポイントとセルシステム帯域幅などの情報は、ｅＮＢにより、物理放送チャネル（Ｐｈｙｓｉｃａｌ Ｂｒｏａｄｃａｓｔ Ｃｈａｎｎｅｌ：ＰＢＣＨと略称する）において送信される放送メッセージにおいて全てのセル内のＵＥへ送信される。

各ＵＥにリソースを割当ててサービスを提供するため、アップリンク伝送において良い多重性能を実現し、十分で柔軟で効率的にシステムの帯域幅を利用するという各ＵＥの要求に応じて、ＬＴＥシステムでは、ユーザのアップリンク伝送リソースの割当に専用の制御メッセージが作成される。ＰＵＳＣＨに対するリソース割り当てを行うことに用いられる専用の制御メッセージは、ｅＮＢによってＵＥに送信されるものであり、当該リソース割当制御メッセージが、アップリンクグラント（ＵｐＬｉｎｋ Ｇｒａｎｔ：ＵＬ Ｇｒａｎｔと略称する）とも称され、ＵＬ Ｇｒａｎｔが、物理ダウンリンク制御チャネル（Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ：ＰＤＣＣＨと略称する）において送信される。

各ＵＥに合理的に無線リソースを割当てることを保証するために、ＬＴＥシステムは、ＵＥに、自身のバッファ内に記憶されたデータ量の状態を報告することを要求し、当該報告は、バッファ状態報告（Ｂｕｆｆｅｒ Ｓｔａｔｕｓ Ｒｅｐｏｒｔ：ＢＳＲと略称する）の形式で、ｅＮＢへ報告される。ＬＴＥシステムにおいて、ＵＥの論理チャネル（Ｌｏｇｉｃａｌ ＣＨａｎｎｅｌ：ＬＣＨと略称する）は、４つの論理チャネルグループ（Ｌｏｇｉｃａｌ Ｃｈａｎｎｅｌ Ｇｒｏｕｐ：ＬＣＧと略称する）に分けられる。ＢＳＲが、各ＬＣＧのグループ番号とクループにおける全てのＬＣＨの送信待ちデータ量の情報とを報告する。ＢＳＲは、物理アップリンク共有チャネル（Ｐｈｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ：ＰＵＳＣＨと略称する）により搬送される。

ＬＴＥシステムにおいて、無線リンクのデータ伝送の時間間隔は、送信時間間隔（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｔｉｍｅ Ｉｎｔｅｒｖａｌ：ＴＴＩと略称する）と称される。

ＢＳＲは、ｅＮＢがＵＥに対して合理的に無線リソーススケジューリングを行うための重要な参照情報であるため、ＬＴＥシステムは、多種のＢＳＲのタイプと送信基準を規定する。ＢＳＲをトリガーするイベントに応じて、ＢＳＲは、レギュラーバッファ状態報告（レギュラーＢＳＲ）、周期的バッファ状態報告（周期的ＢＳＲ）、パディング型バッファ状態報告（パディング型ＢＳＲ）という３つのタイプに分けられる。

レギュラーＢＳＲのトリガー条件は、
高い優先順位の論理チャネルの上位層伝送可能なデータが到達し、当該データの優先順位がＵＥバッファにおける既存のＬＣＨデータより高いこと、
サービングセルが変わったこと、
再送ＢＳＲタイマー（ＲＥＴＸ＿ＢＳＲ＿ＴＩＭＥＲ）がタイムアウトし、かつ、ＵＥバッファに伝送可能なデータがあること、
を含む。

周期的ＢＳＲのトリガー条件は、周期的ＢＳＲタイマーのタイムアウトである。

パディング型ＢＳＲのトリガー条件は、送信待ちのレギュラーＢＳＲも送信待ちの周期的ＢＳＲもなく、かつ、割当てられたアップリンクＰＵＳＣＨリソースにおけるパディング用ビット数がＢＳＲ ＭＡＣ ＣＥと前記ＢＳＲ ＭＡＣ ＣＥのＭＡＣサブヘッダ（ｓｕｂｈｅａｄｅｒ）の大きさとの合計以上であることである。

パディング型ＢＳＲは、埋め草型のＢＳＲであり、レギュラーＢＳＲと周期的ＢＳＲを補充するものである。それに対応して、レギュラーＢＳＲと周期的ＢＳＲは、埋め草型でないＢＳＲである。アップリンクがレギュラーＢＳＲと周期的ＢＳＲを送信しない場合に、パディング型ＢＳＲによって、より早速にｅＮＢがＵＥバッファＬＣＧデータ変化の状況を取得するようになる。

レギュラーＢＳＲ、周期的ＢＳＲ及びパディング型ＢＳＲの搬送方法は異なり、レギュラーＢＳＲと周期的ＢＳＲはそれぞれ、媒体アクセス制御プロトコルデータユニット（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ：ＭＡＣ ＰＤＵと略称する）におけるＭＡＣ制御要素（Ｃｏｎｔｒｏｌ Ｅｌｅｍｅｎｔ：ＣＥと略称する）としてカプセル化される。パディング型ＢＳＲは、ＭＡＣ ＰＤＵのパディングビットに搬送され、ＭＡＣ ＣＥとしてもカプセル化される。この３種類のＢＳＲの搬送方法における唯一の相違点は、パディングビットを使用するかどうかにある。ＭＡＣ ＰＤＵは、ＰＵＳＣＨにおいて送信される。

現在のＬＴＥ ＭＡＣ層のプロトコル規格（３Ｇｐｐ ＴＳ３６．３２１）の定義によって、上記ＭＡＣ ＰＤＵの構造は、図１に示すようになる。１つのＭＡＣ ＰＤＵが、ＭＡＣヘッダと、０、１つ又は複数のＭＡＣ ＣＥと、０、１つ又は複数のＭＡＣサービスデータユニット（Ｓｅｒｖｉｃｅ Ｄａｔａ Ｕｎｉｔ：ＳＤＵと略称する）と、選択可能なパディングビット（Ｐａｄｄｉｎｇ）を含む。ＭＡＣヘッダは、複数のＭＡＣサブヘッダを含み、各ＭＡＣサブヘッダは、順に、ＭＡＣヘッダの後に配置されたＭＡＣ ＣＥ、ＭＡＣ ＳＤＵまたはＰａｄｄｉｎｇに対応する。ＭＡＣサブヘッダは、前記ＭＡＣサブヘッダに対応するＭＡＣ ＣＥ、ＭＡＣ ＳＤＵ、またはＰａｄｄｉｎｇの長さとフォーマットなどの情報を含む。１つのＭＡＣ ＳＤＵは、多くて１つのＢＳＲ ＭＡＣ ＣＥを含む。

ＢＳＲを送信する時に採用されるフォーマットに応じて、ＢＳＲには、ショートＢＳＲ、短縮（Ｔｒｕｎｃａｔｅｄ）ＢＳＲ、ロングＢＳＲという３つのタイプがある。ＬＴＥ ＭＡＣ層のプロトコル規格の定義に応じて、図２と図３に示すように、図２に示すＢＳＲフォーマットが、ショートＢＳＲまたは短縮（Ｔｒｕｎｃａｔｅｄ）ＢＳＲと称され、図３に示すＢＳＲフォーマットが、ロングＢＳＲと称される。ＵＥにトリガーされたＢＳＲが、レギュラーＢＳＲまたは周期的ＢＳＲであり、かつ、ＢＳＲを送信しようとするＴＴＩにおいて、ＵＥにおいて１つのＬＣＧにのみ送信待ちデータがある場合、ＵＥは、ショートＢＳＲ形式を採用してＢＳＲを送信する。ＵＥにトリガーされたＢＳＲが、レギュラーＢＳＲまたは周期的ＢＳＲであり、かつ、ＢＳＲを送信しようとするＴＴＩにおいて、ＵＥにおいて複数のＬＣＧに送信待ちデータがある場合、ＵＥは、ロングＢＳＲ形式を採用してＢＳＲを送信する。ＵＥにトリガーされたＢＳＲが、パディング型ＢＳＲであり、かつ、ＢＳＲを送信しようとするＴＴＩにおいて、ＵＥにおいて複数のＬＣＧに送信待ちデータがあり、かつ、ＭＡＣ ＰＤＵのパディングビットの長さが、ロングＢＳＲ及び対応するＭＡＣサブヘッダを送信するには足りない場合、ＵＥは、短縮ＢＳＲ形式を採用してＢＳＲを報告する。ＵＥにトリガーされたＢＳＲが、パディング型ＢＳＲであり、かつ、ＢＳＲを送信しようとするＴＴＩにおいて、ＵＥにおいて１つのＬＣＧにのみ送信待ちデータがある場合、ＵＥは、ショートＢＳＲ形式を採用してＢＳＲを報告する。なお、ショートＢＳＲと短縮ＢＳＲは、図２に示すフォーマットを採用するが、異なる意味をもつ。

ＵＥがレギュラーＢＳＲをトリガーした後に、当該ＢＳＲをトリガーするイベントが、いずれも重要イベントであるため、ＢＳＲを送信するための現在のＴＴＩにおいて、ＵＥにＰＵＳＣＨリソースがないと、ＵＥは、スケジューリングリクエスト（Ｓｃｈｅｄｕｌｉｎｇ Ｒｅｑｕｅｓｔ：ＳＲと略称する）をトリガーする必要がある。ＢＳＲを送信するための次のＴＴＩにおいて、ＵＥに使用可能なＰＵＳＣＨリソースがある場合に、当該ＳＲがキャンセルされる。ＢＳＲを送信するための次のＴＴＩにおいて、ＵＥに使用可能なＰＵＳＣＨリソースがない場合に、当該ＳＲは、物理アップリンク制御チャネル（Ｐｈｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ：ＰＵＣＣＨと略称する）リソースにおいてｅＮＢへ送信され、ｅＮＢに当該ＵＥにＰＵＳＣＨリソースの割り当てを要求する。

現行のＬＴＥ ＭＡＣ層のプロトコル規格（３Ｇｐｐ ＴＳ３６．３２１）の定義によって、ＢＳＲのトリガーとＢＳＲの送信との基本的なフローは、以下のとおりである。
各ＴＴＩにおいて、ＵＥが、前記ＢＳＲトリガー条件によって、ＢＳＲをトリガーするかどうかを判断する。
各ＴＴＩにおいて、ＵＥが、トリガーされたＢＳＲがあるかどうかを判断し、トリガーされたＢＳＲがある場合、ＵＥは、現在のＴＴＩに使用可能なＰＵＳＣＨリソースがあるかどうかを判断し、現在のＴＴＩに使用可能なＰＵＳＣＨリソースがある場合、適切なＢＳＲフォーマットが選択され、かつＭＡＣ ＣＥにカプセル化される。トリガーされたＢＳＲがない場合、ＵＥはパディング型ＢＳＲをトリガーするかどうかを判断し、パディング型ＢＳＲをトリガーする場合、適切なＢＳＲフォーマットが選択され、かつＭＡＣ ＣＥにカプセル化される。ＭＡＣ ＰＤＵのパッケージングが完了した後に、アップリンク送信が実施される。

上記ＢＳＲのフォーマット及び送信基準の定義は、いずれも従来のＬＴＥ ｒｅｌｅａｓｅ ８の規格によって定義される。現在及び将来的に急増する無線サービスの需要に対応するために、次の進化型ＬＴＥ ｒｅｌｅａｓｅ ８規格、すなわち、ロングタームエボリューションアドバンスト（ＬＴＥ−Ａｄｖａｎｃｅｄ）規格も策定されつつある。

ＬＴＥ−Ａｄｖａｎｃｅｄは、第３世代移動体通信システムの規格化プロジェクト（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒ Ｐｒｏｊｅｃｔ：３ＧＰＰと略称する）組織が、国際電気通信連合（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｕｎｉｏｎ：ＩＴＵと略称する）における第四世代移動通信システム（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ−Ａｄｖａｎｃｅｄ：ＩＭＴ−Ａｄｖａｎｃｅｄと略称する）の要求を満たすために導入された規格である。ＬＴＥ−Ａｄｖａｎｃｅｄシステムは、ＬＴＥ ｒｅｌｅａｓｅ ８システムの進化版である。ＬＴＥ−Ａｄｖａｎｃｅｄシステムは、多数の新しい技術を導入してＩＭＴ−Ａｄｖａｎｃｅｄの基本的な要求を満たすものであり、最も重要な技術はキャリアアグリゲーションである。

無線周波数スペクトルリソース及び世界で各移動体通信事業者の持つ周波数スペクトルリソースの不足が相対的に分散しているため、ＩＭＴ−Ａｄｖａｎｃｅｄはより高いピークレートを要求する（高速移動環境で、１００Ｍｂｐｓをサポートし、低速移動環境で、１Ｇｂｐｓをサポートする）。現在のＬＴＥ規格の最大帯域幅である２０ＭＨｚは、ＩＭＴ−Ａｄｖａｎｃｅｄの要求を満たさないため、帯域幅を例えば、４０ＭＨｚ、６０ＭＨｚ、さらにより高い帯域幅に拡張させる必要がある。帯域幅とピークレートとを向上させる方法の１つは、周波数領域を拡張することであり、すなわち、「キャリアアグリゲーション」方式によって、複数の周波帯を結合して帯域幅拡張を行うことである。これは、キャリアアグリゲーション技術の本質である。

キャリアアグリゲーション技術を応用したＬＴＥ−Ａｄｖａｎｃｅｄシステムにおいて、アグリゲーションに関与するキャリアは、コンポーネントキャリアと称される。ＵＥは、複数の周波数帯域においてｅＮＢとの間で送信、受信、及び伝送を同時に行うことができ、単一の周波数帯域において、依然として、ＬＴＥ ｒｅｌｅａｓｅ８の特性を維持する。つまり、ＬＴＥ−Ａｄｖａｎｃｅｄは、複数のＬＴＥシステムが「結合」されたことによって生成されると考えることができる。

キャリアアグリゲーション技術を導入した後に、ＬＴＥ−Ａｄｖａｎｃｅｄシステムにおける使用可能なリソースが大いに拡張され、かつ、アップリンクスケジューリングの柔軟性が大いに改善され、ｅＮＢが、各コンポーネントキャリア周波数帯域において、ＵＥにリソースを割り当てられるようになった。

ＬＴＥ−Ａｄｖａｎｃｅｄシステムは、最大１００ＭＨｚのアップリンク伝送帯域幅及び最大層数４層のアップリンク空間分割多重伝送をサポートできる（ＬＴＥ ｒｅｌｅａｓｅ８システムにおいてサポートされるアップリンク空間分割多重伝送の層数は最大で２層である）。これにより、ＬＴＥ−ＡｄｖａｎｃｅｄのＵＥにサポートされる最大バッファデータ量の大きさは、理論的には、ＬＴＥシステムのＵＥの１０倍となる。したがって、ＬＴＥ−Ａｄｖａｎｃｅｄは、ＢＳＲを報告するためにより多くのバイト数が必要となる。加えて、ＬＴＥ−ＡｄｖａｎｃｅｄのＵＥには、同時に使用可能なアップリンクのコンポーネントキャリアが複数ある可能性がある。複数のコンポーネントキャリアにおいてＢＳＲを送信する特定のルールや方法は規定されていない。現在のＬＴＥシステムのＢＳＲ送信メカニズムは、単一キャリアシステムのみに適用できるが、ＬＴＥ−Ａｄｖａｎｃｅｄシステムの要求には適応できない。ＬＴＥ−Ａｄｖａｎｃｅｄシステムが、ＬＴＥシステムのＢＳＲ送信メカニズムに従うと、ＢＳＲは、１つのコンポーネントキャリアにおいてのみ送信される。異なるコンポーネントキャリアの間にはチャネルの品質に差異が存在するため、１つのコンポーネントキャリアにおいてのみＢＳＲを送信すると、ＢＳＲの送信正確率がＬＴＥ−Ａｄｖａｎｃｅｄシステムの要求を満たすことができない。加えて、全てのコンポーネントキャリアにおいてＢＳＲを送信すると、システムオーバーヘッドが大きくなる。このため、ＬＴＥ−ＡｄｖａｎｃｅｄシステムにおけるＢＳＲの設計と送信メカニズムは、送信正確率とオーバーヘッドを併せて考慮しなければならない。

現行のＬＴＥシステムにおいて、ＵＥへｅＮＢに送信された、チャネル品質の差異に関する情報は、変調符号化方式（Ｍｏｄｕｌａｔｉｏｎ ａｎｄ Ｃｏｄｉｎｇ Ｓｃｈｅｍｅ：ＭＣＳと略称する）だけである。各ＭＣＳレベルが、変調モードと符号化レートとのユニークな組合せに対応する。ＭＣＳレベルが高いほど、対応する変調モードまたは符号化レートが高い。高い変調モードまたは高い符号化レートが、よい品質の無線チャネルにおいて採用されなければ、よい通信品質を取得できない。このため、一般的に、ｅＮＢは、高いチャネル品質のコンポーネントキャリア無線リソースにおいて、高いＭＣＳレベルを採用する。ＬＴＥ−Ａｄｖａｎｃｅｄシステムにおいて、ｅＮＢによりＵＥに送信された、チャネル品質の差異に関する情報が多くなる可能性がある。

加えて、ＬＴＥ−ＡｄｖａｎｃｅｄシステムにおけるＵＥにサポートされた最大バッファデータ量の大きさがＬＴＥシステムのＵＥより数倍拡張されるため、従来のＬＴＥシステムのＢＳＲ設計がすでにＬＴＥ−Ａｄｖａｎｃｅｄシステムの要求をサポートできず、ＬＴＥ−Ａｄｖａｎｃｅｄシステムの特徴に対して、新しいＢＳＲタイプを設計しなければならない。さらに、ＬＴＥ−Ａｄｖａｎｃｅｄシステムが、ＬＴＥ ＵＥに対する下位互換性を維持する必要があるので、ＬＴＥ−Ａｄｖａｎｃｅｄシステムには、ＬＴＥ ＵＥとＬＴＥ−Ａｄｖａｎｃｅｄ ＵＥとが存在し、同時に、ＬＴＥのＢＳＲタイプと新しいＢＳＲタイプとが存在する。したがって、ネットワーク側が、どのようにＵＥに送信されたＢＳＲがＬＴＥのＢＳＲタイプであるか、新しいＢＳＲタイプかを区別することも解決しなければならない問題の１つである。

そのため、上記問題については、バッファ状態報告の送信正確率を向上させると同時にアップリンク無線リソースを節約するように、キャリアアグリゲーション技術を採用するシステムを適用して前記バッファ状態報告を報告する方法、当該方法に対応するシステム、及び端末が必要とされる。

本発明が解決しようとする課題は、キャリアアグリゲーション技術をサポートする無線ネットワークにおいて、端末はコンポーネントキャリアが割り当てられた無線リソースにおいてどのようにバッファ状態報告を報告するかの問題を解決することによって、バッファ状態報告の送信正確率を保証し、アップリンク無線リソースを節約するように、前記バッファ状態報告を報告する方法、端末及びネットワークシステムが提供される。

上記問題を解決するために、本発明は、以下の技術的解決法を提供する。
本発明に係るバッファ状態報告を報告する方法は、
端末がバッファ状態報告（ＢＳＲ）をトリガーし、無線ネットワークにおけるアップリンクコンポーネントキャリアの無線リソース情報を取得し、
バッファ送信待ちデータ量情報に応じて、１つまたは複数のＢＳＲデータユニットを構成し、
使用可能な無線リソースを有する前記アップリンクコンポーネントキャリアから、１つまたは複数のアップリンクコンポーネントキャリアを選択し、選択されたアップリンクコンポーネントキャリアの無線リソースにおいて前記ＢＳＲデータユニットをネットワーク側に送信する。

前記端末がＢＳＲをトリガーするトリガー条件は、
少なくとも１つのアップリンクコンポーネントキャリアにおいて、前記端末の使用可能な無線リソースにおいてパディング用ビット数が、１つの論理チャネルグループ（ＬＣＧ）または１つの論理チャネル（ＬＣＨ）のバッファステータス情報の構成方法に必要なビットの長さとパディングビットに対応する媒体アクセス制御（ＭＡＣ）サブヘッダのヒットの長さとの合計以上であることを含んでもよい。

前記方法には、
前記端末が、バッファ送信待ちデータ量情報に応じてＢＳＲデータユニットを構成する場合に、ＢＳＲデータユニットの内容構成に応じて、構成された前記ＢＳＲデータユニットを異なるタイプに分けるステップをさらに含んでもよい。

前記端末が複数のアップリンクコンポーネントキャリアの無線リソースにおいて前記ＢＳＲデータユニットを送信することを選択する場合に、複数のＢＳＲデータユニットを送信する場合、前記複数のデータユニットは、同じＢＳＲタイプまたは異なるＢＳＲタイプである。

前記端末がＢＳＲデータユニットの内容構成に応じて、前記ＢＳＲデータユニットを異なるタイプに分ける場合に、前記ＢＳＲデータユニットの内容構成は、
ＢＳＲデータユニットに含まれるバッファステータス情報に対応するオブジェクトがＬＣＧまたはＬＣＨのバッファステータス情報であること、
ＢＳＲデータユニットが前記端末の１つのＬＣＧまたは１つのＬＣＨのバッファステータス情報のみを含むこと、
ＢＳＲデータユニットが前記端末の一部のＬＣＧまたは一部のＬＣＨのバッファステータス情報を含むこと、または、
ＢＳＲデータユニットが前記端末の全てのＬＣＧまたは全てのＬＣＨのバッファステータス情報を含むことを含んでもよい。

ＢＳＲデータユニットが前記端末の１つのＬＣＧまたは１つのＬＣＨのバッファステータス情報のみを含む場合、当該ＢＳＲは、前記ＬＣＧまたはＬＣＨの番号情報を含み、前記ＬＣＧまたはＬＣＨのバッファ送信待ちデータ量情報をさらに含んでもよく、当該バッファ送信待ちデータ量の情報の長さが６ビット以上である。

ＢＳＲデータユニットが前記端末の一部のＬＣＧまたは一部のＬＣＨのバッファステータス情報を含む場合、
当該ＢＳＲデータユニットは、ＬＣＧまたはＬＣＨの番号情報を含み、当該番号情報はＬＣＧまたはＬＣＨの番号順に応じて配列されるすべてのＬＣＧまたはＬＣＨのビットマップを表し、当該番号情報の長さがＮビットであり、ＮがＬＣＧまたはＬＣＨの総数であり、ＬＣＧまたはＬＣＨのビットマップにおいてあるビットが１または０であることは、当該ビットに対応するＬＣＧまたはＬＣＨのバッファ送信待ちデータ量情報が当該ＢＳＲデータユニット内に含まれるかどうかを表し、当該ＢＳＲデータユニットは、ビットマップにおけるＬＣＧまたはＬＣＨに対応するバッファ送信待ちデータ量情報をさらに含み、当該バッファ送信待ちデータ量情報の長さが６ビット以上であり、ＬＣＧまたはＬＣＨのバッファ送信待ちデータ量情報がビットマップにおけるＬＣＧまたはＬＣＨの順序によって順次に配列されてもよい。

ＢＳＲデータユニットが前記端末の全てのＬＣＧまたは全てのＬＣＨのバッファステータス情報を含むと、当該ＢＳＲデータユニットは、前記端末の全てのＬＣＧまたは全てのＬＣＨのバッファ送信待ちデータ量情報を含み、当該バッファ送信待ちデータ量情報の長さが６ビット以上であり、ＬＣＧまたはＬＣＨのバッファ送信待ちデータ量情報がＬＣＧまたはＬＣＨの番号順によって順次に配列されてもよい。

前記バッファ送信待ちデータ量情報の長さは、進化型基地局（ｅＮＢ）と前記端末側に固定的に設定され、または、前記ｅＮＢにより設定され、かつ、放送チャネル又は専用に設定される無線リソース制御（ＲＲＣ）メッセージを介して端末に通知され、または、前記端末により、設定される全てのアップリンクコンポーネントキャリアの総帯域幅に応じて選択されるものであり、総帯域幅が大きいほど、長いバッファ送信待ちデータ量情報長さが選択されてもよい。

前記ＢＳＲにおけるＬＣＧまたはＬＣＨのバッファ送信待ちデータ量情報は、ＬＣＧまたはＬＣＨの実際のバッファ送信待ちデータ量のレベル情報を表し、当該レベル情報とＬＣＧまたはＬＣＨの実際のバッファ送信待ちデータ量との対応関係は、各レベルが１つのデータ量範囲に対応し、隣接レベルに対応するデータ量範囲が連続的であり、各レベルに対応するデータ量範囲の大きさが固定値であって、または、レベルの増加に伴い増加する増加値であって、または、固定値と増加値との組合せであることを含んでもよい。
前記対応関係は、単一キャリア技術において定義される対応関係に新規対応関係を追加することにより生成され、または、従来の単一キャリア技術に定義される対応関係を変更することにより生成され、または、新規な対応関係を設定することにより生成されてもよい。

ＢＳＲデータユニットの内容構成によって、構成された前記ＢＳＲデータユニットを異なるタイプに分ける前記ステップは、２つのＢＳＲデータユニットの内容構成の全ての特徴及び構成方法が完全に同じである場合、前記２つのＢＳＲデータユニットの内容構成が同じであると判定し、２つのＢＳＲデータユニットの内容構成の全ての特徴及び構成方法が完全には同じでない場合、前記２つのＢＳＲデータユニットの内容構成が同じではないと判定してもよい。

前記端末に複数のＬＣＧまたはＬＣＨのバッファステータス情報がある場合に、前記端末が選択して送信するＢＳＲデータユニットの内容構成の原則は、
同時に、前記端末ができるだけ多くのＬＣＧまたはＬＣＨのバッファステータス情報を選択して前記ｅＮＢに送信すること、または、
同時に、前記端末が高い優先度のＬＣＨを含むＬＣＧや高い優先度のＬＣＨのバッファステータス情報を優先的に送信すること、または、
同時に、前記端末の１つまたは複数のＢＳＲデータユニットが既に全てのバッファ送信待ちデータを有するＬＣＧまたはＬＣＨのバッファステータス情報を含む場合、前記端末のほかのＢＳＲデータユニットが、バッファ送信待ちデータを有する一部のＬＣＧまたはＬＣＨのバッファステータス情報のみを含むことを含んでもよい。

前記端末が使用可能な無線リソースを有する前記アップリンクコンポーネントキャリアから、１つまたは複数のアップリンクコンポーネントキャリアを選択するステップは、
前記端末が１つのアップリンクコンポーネントキャリアにおいて使用可能な無線リソースを有する場合に、前記端末が当該コンポーネントキャリアのみを選択し、
前記端末が複数のアップリンクコンポーネントキャリアにおいて使用可能な無線リソースを有する場合に、前記端末が複数のコンポーネントキャリアから１つまたは複数のアップリンクコンポーネントキャリアを選択してもよい。

前記端末が複数のアップリンクコンポーネントキャリアにおいて使用可能な無線リソースを有する場合に、前記端末が前記複数のコンポーネントキャリアから１つまたは複数のアップリンクコンポーネントキャリアを選択するステップは、選択されるアップリンクコンポーネントキャリアの数を確定することを含んでもよく、
前記選択されるアップリンクコンポーネントキャリアの数を確定するステップは、
１４Ａ：前記端末が使用可能な無線リソースを有するアップリンクコンポーネントキャリアを１つのみ選択し、または、
１４Ｂ：前記端末が使用可能な無線リソースを有するアップリンクコンポーネントキャリアを全て選択し、または、
１４Ｃ：前記端末が1つの絶対数量値に応じて、選択されるアップリンクコンポーネントキャリアの数を確定し、または、
１４Ｄ：前記端末が使用可能な無線リソースを有するアップリンクコンポーネントキャリアの数に1つの比率値をかけることにより得られた数値に応じて、選択されるアップリンクコンポーネントキャリアの数を確定する。

前記端末が複数のアップリンクコンポーネントキャリアにおいて使用可能な無線リソースを有する場合に、前記端末が前記複数のコンポーネントキャリアから１つまたは複数のアップリンクコンポーネントキャリアを選択するステップは、
前記端末が、ネットワーク側の前記ｅＮＢにより送信されたアップリンクコンポーネントキャリアの無線リソースのチャネル品質に関する情報及び／又は前記ｅＮＢに設定されたチャネル品質に関する閾値情報に応じて、前記チャネル品質に関する閾値情報よりも高い優先度のチャネル品質に関する情報をもつアップリンクコンポーネントキャリアを選択してもよい。

前記ステップ１４Ｃにおける前記絶対数量値、及び前記ステップ１４Ｄにおける前記使用可能な無線リソースを有するアップリンクコンポーネントキャリアの数量に1つの比率値をかけることによって得られた前記数値は、いずれも１以上の数値である。

前記チャネル品質に関する情報は、
変調符号化レベル情報、信号対干渉雑音電力比情報、信号対雑音比情報、パケット誤り率情報、ブロック誤り率情報、または、ビット誤り率情報を含んでもよい。

前記比率値と前記絶対数量値は、
前記端末側において予め設定されたもの、または、
前記ｅＮＢにより設定され、かつ、放送メッセージを介して前記端末へ送信されるもの、または、
前記ｅＮＢにより設定され、かつ、ＲＲＣメッセージを介して前記端末へ送信されるもの、または、
前記ｅＮＢにより設定され、かつ、アップリンクグラントメッセージを介して前記端末へ送信されるもの、または、
前記ｅＮＢにより設定され、かつ、特定の媒体アクセス制御（ＭＡＣ）制御要素を介して前記端末へ送信されるものであってもよい。

前記端末が複数のアップリンクコンポーネントキャリアにおいて使用可能な無線リソースを有する場合に、選択されるアップリンクコンポーネントキャリアの数量を確定した後に、前記複数のアップリンクコンポーネントキャリアから１つまたは複数のアップリンクコンポーネントキャリアを選択するステップは、
使用可能な無線リソースを有する複数のアップリンクコンポーネントキャリアにおいて、確定された数のアップリンクコンポーネントキャリアをランダムに選択すること、または、
前記ｅＮＢに予め設定された、当該端末の使用中のアップリンクコンポーネントキャリアの番号順によって、小さい番号の確定された数のアップリンクコンポーネントキャリアを選択すること、または、
前記ｅＮＢに送信された、アップリンクコンポーネントキャリアの無線リソースのチャネル品質に関する情報によって、確定された数の高いチャネル品質のアップリンクコンポーネントキャリアを優先的に選択することをさらに含んでもよい。

前記端末が複数のアップリンクコンポーネントキャリアの無線リソースにおいて送信したＢＳＲデータユニットは、単一キャリアシステムに定義されたＢＳＲデータユニットタイプ、または、キャリアアグリゲーション技術をサポートする新規なＢＳＲデータユニットタイプであり、
キャリアアグリゲーション技術をサポートする前記ＢＳＲデータユニットが、一部のＬＣＧのバッファステータス情報を含む短縮ＢＳＲデータユニット、１つのＬＣＧのバッファステータス情報を含むショートＢＳＲデータユニット、または、全てのＬＣＧのバッファステータス情報を含むロングＢＳＲデータユニットを含んでもよい。

前記端末が同一伝送時刻において、複数のアップリンクコンポーネントキャリアの無線リソースにおいて送信したＢＳＲデータユニットは、単一キャリアシステムに定義されたＢＳＲデータユニットタイプ、または、キャリアアグリゲーション技術をサポートする新規なＢＳＲデータユニットタイプであり、
キャリアアグリゲーション技術をサポートする前記ＢＳＲデータユニットタイプは、一部のＬＣＧのバッファステータス情報を含む短縮ＢＳＲデータユニット、１つのＬＣＧのバッファステータス情報を含むショートＢＳＲデータユニット、または、全てのＬＣＧのバッファステータス情報を含むロングＢＳＲデータユニットを含んでもよい。

前記端末が、ＭＡＣサブヘッダにＢＳＲタイプに対応する識別情報を追加し、ネットワーク側のｅＮＢが、前記端末により送信された媒体アクセス制御プロトコルデータユニット（ＭＡＣ ＰＤＵ）を受信した後に、ＭＡＣサブヘッダにおける前記識別情報に応じて、前記ＭＡＣ ＰＤＵに前記ＢＳＲ及び当該ＢＳＲのタイプが含まれることを取得し、または、
前記端末が、ＭＡＣサブヘッダにおける既存の１つまたは複数の識別情報の対応関係を変更してキャリアアグリゲーション技術をサポートする新規なＢＳＲデータユニットタイプに対応させ、前記端末がネットワーク側の前記ｅＮＢへ端末能力情報を含むＲＲＣ層メッセージを報告した後に、前記ｅＮＢが、端末能力情報によって、これから前記端末により送信されたＭＡＣ ＰＤＵにおけるＭＡＣサブヘッダが、前記識別情報の対応関係が変更されたＭＡＣサブヘッダであるかどうかを判断し、または、
前記端末が、ＭＡＣサブヘッダにおける既存の１つまたは複数の識別情報の対応関係を変更してキャリアアグリゲーション技術をサポートする新規なＢＳＲデータユニットタイプに対応させ、前記端末がネット側の前記ｅＮＢと無線リソース制御ＲＲＣ層リンクを確立した後に、前記ｅＮＢが特定のＲＲＣ専用メッセージを送信して、前記識別情報の対応関係が変更されたＭＡＣサブヘッダを使用するかどうかを前記端末に通知してもよい。

前記端末が既にレギュラーバッファ状態報告をトリガーし、かつ、前記端末が現在の送信時間間隔（ＴＴＩ）において新しいデータを送信するための物理アップリンク共有チャネル（ＰＵＳＣＨ）リソースを有しない場合、前記端末がスケジューリングリクエスト（ＳＲ）をトリガーし、
前記端末が既にＳＲをトリガーし、かつ、任意のアップリンクコンポーネントキャリアにも使用可能なＰＵＳＣＨリソースがない場合、前記端末が使用可能な物理アップリンク制御チャネル（ＰＵＣＣＨ）リソースを有するＴＴＩにおいてＳＲを送信して、ｅＮＢに当該端末にＰＵＳＣＨリソースの割り当てを要求してもよい。

本発明に係るバッファ状態報告（ＢＳＲ）を報告するネットワークシステムは、進化型基地局（ｅＮＢ）と、端末とを備える。
前記端末は、基地局から無線ネットワークのアップリンクコンポーネントキャリアの無線リソース情報を取得し、バッファ送信待ちデータ量情報によって、１つまたは複数のＢＳＲデータユニットを構成し、無線リソースを有する前記アップリンクコンポーネントキャリアから、１つまたは複数のアップリンクコンポーネントキャリアを選択し、選択されたアップリンクコンポーネントキャリアの無線リソースにおいて前記ＢＳＲデータユニットを前記ｅＮＢに送信するように設定される。
前記ｅＮＢは、前記端末にコンポーネントキャリア無線リソースを割り当て、アップリンクコンポーネントキャリアの無線リソースを介して前記端末に報告されたＢＳＲデータユニットを受信し、前記ＢＳＲデータユニットを解析して前記端末のバッファステータスを認知するように設定される。

本発明に係るバッファ状態報告（ＢＳＲ）を報告する実施端末は、
基地局により端末に割り当てたアップリンクコンポーネントキャリアの無線リソースを取得し、かつ、無線リソース情報を無線リソース選択モジュールに通知するように設定されるコンポーネントキャリア無線リソース取得モジュールと、
前記端末のバッファ送信待ちデータ量情報を監視して取得し、かつ、当該送信待ちデータ量情報をバッファ状態報告生成モジュールに通知するように設定されるバッファ情報監視モジュールと、
バッファ送信待ちデータ量情報に応じて、１つまたは複数のＢＳＲデータユニットを構成するように設定されるバッファ状態報告生成モジュールと、
前記コンポーネントキャリア無線リソース取得モジュールから取得された前記無線リソースから、１つまたは複数の前記ＢＳＲデータユニットを送信するための１つまたは複数のアップリンクコンポーネントキャリアを選択し、かつ、選択結果をＢＳＲ送信モジュールに送信するように設定される無線リソース選択モジュールと、
無線リソース選択モジュールで選択された無線リソースにおいて、バッファ状態報告生成モジュールにより生成された１つまたは複数の前記ＢＳＲデータユニットをネットワーク側の進化型基地局（ｅＮＢ）に送信するように設定されるＢＳＲ送信モジュールと、を含む。

前記バッファ状態報告生成モジュールは、バッファ送信待ちデータ量情報に応じて異なるＢＳＲタイプを構成し、すなわち、ＢＳＲデータユニットの内容構成に応じて前記ＢＳＲデータユニットを異なるタイプに分けるように設定される。前記ＢＳＲデータユニットの内容構成は、
ＢＳＲデータユニットが前記端末の１つの論理チャネルグループ（ＬＣＧ）または論理チャネル（ＬＣＨ）のバッファステータス情報のみを含むことと、
ＢＳＲデータユニットが前記端末の一部の論理チャネルグループ（ＬＣＧ）または一部の論理チャネル（ＬＣＨ）のバッファステータス情報を含み、または、
ＢＳＲデータユニットが前記端末の全ての論理チャネルグループ（ＬＣＧ）または全ての論理チャネル（ＬＣＨ）のバッファステータス情報を含むことと、を含んでもよい。

本発明は、従来のＬＴＥにおけるＢＳＲデータユニットの定義を基にして、ＬＴＥ−ＡｄｖａｎｃｅｄシステムのＢＳＲデータユニットの新規で実用的な形式を追加定義し、特に、ＬＴＥ−Ａｄｖａｎｃｅｄの大容量性に適用するデータ量レベル情報確定メカニズムを提供し、データ量レベル情報の長さが６ビット以上になるようにしてもよい。本発明は、ＬＴＥ−Ａｄｖａｎｃｅｄに適用するＢＳＲの送信のトリガー条件を新たに追加する。さらに、端末に複数の使用可能なコンポーネントキャリアの無線リソース情報がある場合に対しては、具体的に、１つまたは複数のコンポーネントキャリアを選択して、特定の形式のＢＳＲデータユニットを送信する。

本発明に係るマルチキャリアシステム、端末、及びＢＳＲ報告方法によれば、バッファ状態報告の送信正確率を保証するとともにアップリンク無線リソースを節約する目的を達成するために、ＵＥに割り当てられたコンポーネントキャリアリソースの状況に応じて、１つまたは複数の形式のＢＳＲを柔軟に生成し、かつ、適切なコンポーネントキャリアを選択してＢＳＲを送信することを実現できる。本発明は、ＬＴＥ−Ａｄｖａｎｃｅｄシステムの広帯域幅性を十分に利用した上で、ＢＳＲデータユニットの送信の高効率化及び高品質化も実現できる。

ＬＴＥ規格によって定義されるＭＡＣ ＰＤＵを示す図である。 ＬＴＥ規格によって定義されるショートＢＳＲと短縮ＢＳＲを示す図である。 ＬＴＥ規格によって定義されるロングＢＳＲを示す図である。 本発明に係るキャリアアグリゲーションを採用したマルチキャリアネットワークシステムを示す図である。 本発明に係るマルチキャリアネットワークシステムにおける端末の構造を示す図である。 本発明に係る１つのＬＣＧのバッファステータス情報のみを含むＢＳＲデータユニットを示す図である。 本発明に係る１つのＬＣＧのバッファステータス情報のみを含むＢＳＲデータユニットを示す第２の図である。 本発明に係る１つのＬＣＧのバッファステータス情報のみを含むＢＳＲデータユニットを示す第３の図である。 本発明に係るバッファ送信待ちデータ量のレベルと実際のバッファ送信待ちデータ量との対応表である。 本発明に係るバッファ送信待ちデータ量のレベルと実際のバッファ送信待ちデータ量との第２の対応表である。 本発明に係るバッファ送信待ちデータ量のレベルと実際のバッファ送信待ちデータ量との第３の対応表である。 本発明に係る一部のＬＣＧのバッファステータス情報を含むＢＳＲデータユニットを示す図である。 本発明に係る全てのＬＣＧのバッファステータス情報を含むＢＳＲデータユニットを示す図である。 本発明に係るＢＳＲデータユニットを構成及び送信するフローチャートである。 本発明に係る１つのアップリンクコンポーネントキャリアの無線リソースにおいてＢＳＲデータユニットを送信することを示す図である。 本発明に係る一部のアップリンクコンポーネントキャリアの無線リソースにおいてＢＳＲデータユニットを送信することを示す図である。 本発明に係る全てのアップリンクコンポーネントキャリアの無線リソースにおいてＢＳＲデータユニットを送信することを示す図である。 本発明に係る複数のコンポーネントキャリアにおいて送信されたＢＳＲデータユニットの構成方法を示す第１の図である。 本発明に係る複数のコンポーネントキャリアにおいて送信されたＢＳＲデータユニットの構成方法を示す第２の図である。 本発明に係る複数のコンポーネントキャリアにおいて送信されたＢＳＲデータユニットの構成方法を示す第３の図である。 本発明に係る複数のコンポーネントキャリアにおいてパディング型ＢＳＲデータユニットを送信することを示す第１の図である。 本発明に係る複数のコンポーネントキャリアにおいてパディング型ＢＳＲデータユニットを送信することを示す第２の図である。 本発明に係る複数のコンポーネントキャリアにおいてパディング型ＢＳＲデータユニットを送信することを示す第３の図である。

本発明の目的、技術的解決法、及び利点をより明確にするため、以下、実施形態を挙げて、図面を参照して、本発明をさらに詳しく説明する。

本発明は、従来のＬＴＥにおけるＢＳＲデータユニットの定義を基にして、ＬＴＥ−Ａｄｖａｎｃｅｄシステムにおける実用的なＢＳＲデータユニットのフォーマットを新たに定義し、特に、ＬＴＥ−Ａｄｖａｎｃｅｄの大容量性に適用可能なデータ量レベル情報確定メカニズムを提供し、これによりデータ量レベル情報の長さを６ビット以上とすることを可能とする。加えて、本発明は、ＬＴＥ−ＡｄｖａｎｃｅｄにおけるＢＳＲの送信に適用可能なトリガー条件を新たに追加する。さらに、本発明は、端末に複数の使用可能なコンポーネントキャリアの無線リソースがある場合、１つまたは複数のコンポーネントキャリアを選択して、ＢＳＲデータユニットを送信する具体的な形式を提供する。本発明は、ＬＴＥ−Ａｄｖａｎｃｅｄシステムの広帯域幅性を十分に生かした上で、ＢＳＲデータユニットの送信の高効率及び高品質を実現する。

図４は、本発明に係るバッファ状態報告を報告するネットワークシステムを示す図である。ネットワークシステム４００は、ＵＥ４０１と、ｅＮＢ４０２とを備える。

ＵＥ４０１は、無線ネットワークのアップリンクコンポーネントキャリアの無線リソース情報を取得し、バッファ送信待ちデータ量情報によって１つまたは複数のＢＳＲデータユニットを構成し、使用可能な無線リソースを有する前記アップリンクコンポーネントキャリアから、１つまたは複数のアップリンクコンポーネントキャリアを選択し、選択されたアップリンクコンポーネントキャリアの無線リソースにおいてＢＳＲデータユニットをｅＮＢに送信することに用いられる。

ｅＮＢ４０２は、ＵＥにコンポーネントキャリア無線リソースを割当て、アップリンクコンポーネントキャリアの無線リソースによってＵＥに報告されたＢＳＲデータユニットを受信し、前記ＢＳＲデータユニットを解析してＵＥのバッファステータスを取得することに用いられる。

図５に示すように、本発明に係るバッファ状態報告を報告するＵＥ４０１は、
前記基地局によりＵＥに割り当てられたアップリンクコンポーネントキャリアの無線リソースを取得し、無線リソース情報を無線リソース選択モジュール５０４に通知するコンポーネントキャリア無線リソース取得モジュール５０１と、
ＵＥのバッファ送信待ちデータ量情報を監視し、当該送信待ちデータ量情報をバッファ状態報告生成モジュール５０３に通知するバッファ情報監視モジュール５０２と、
バッファ送信待ちデータ量情報によって、１つまたは複数のＢＳＲデータユニットを構成するバッファ状態報告生成モジュール５０３と、
前記コンポーネントキャリア無線リソース取得モジュール５０１から取得された前記無線リソースにおいて、１つまたは複数の前記ＢＳＲデータユニットを送信するための１つまたは複数のアップリンクコンポーネントキャリアを選択し、選択結果をＢＳＲ送信モジュール５０５に送信する無線リソース選択モジュール５０４と、
無線リソース選択モジュール５０４で選択された無線リソースにおいて、バッファ状態報告生成モジュール５０３により生成された１つまたは複数の前記ＢＳＲデータユニットをネットワーク側のｅＮＢ４０２に送信するＢＳＲ送信モジュール５０５とを含む。

以下の実施形態におけるｅＮＢとＵＥは、いずれもＬＴＥ−Ａｄｖａｎｃｅｄシステムに属し、キャリアアグリゲーション技術をサポートし、周波数分割多重（ＦＤＤ）モードを採用する。ＢＳＲデータユニットの内容構成の設計は以下の通りである。

ＢＳＲデータユニットに含まれるバッファステータス情報に対応するオブジェクトは、ＬＣＧであってもよいし、ＬＣＨであってもよい。以下の実施形態において、ＬＣＧを例とする。ＬＴＥ Ｒｅｌｅａｓｅ８システムには４つのＬＣＧがある。ＬＴＥ Ｒｅｌｅａｓｅ８システムとの互換性をとるために、以下の実施形態においても４つのＬＣＧがあるものとして設計される。ｅＮＢは、ＬＣＨをどのように各ＬＣＧに割り当てるかの設定を行い、その設定方法は本発明に係る実施形態の技術的な内容に影響を与えない。したがって、本発明に係る実施形態においては、ＬＣＨバッファステータス情報を含むＢＳＲを特に例示しない。

ＢＳＲデータユニットに含まれるバッファステータス情報は、１つのＬＣＧのものでもよいし、全部のＬＣＧのものでもよいし、一部のＬＣＧのものでもよい。

実施形態１
１つのＬＣＧのバッファステータス情報を含むＢＳＲデータユニットの構成方法の特徴は、下記のようなものである。ＬＣＧの番号情報を含み、この情報の長さはｌｏｇ２Ｎビットであり、ＮはＬＣＧの総数である。当該ＢＳＲは前記番号に対応するＬＣＧのバッファ送信待ちデータ量のレベル情報をさらに含む。各ＬＣＧのバッファ送信待ちデータ量のレベル情報の長さは、どのようにＬＣＧのバッファ送信待ちデータ量の範囲を分類するかによって決まる。現在のＬＴＥ Ｒｅｌｅａｓｅ８スタンダードにおいて、バッファ送信待ちデータ量範囲は６４レベルに分けられ（すなわち、データ量レベル情報の長さは６ビットである）、正確に表示可能な実際のバッファデータ量の最大量は１５００００バイトである。本発明において、サポートしようとする正確な実際のバッファデータ量の最大量がＬＴＥ Ｒｅｌｅａｓｅ８スタンダードの１０倍、すなわち、１５０００００バイト（背景技術に記載されたＬＴＥ−Ａｄｖａｎｃｅｄシステムに関する説明を参照）とすると、データ量レベル情報の長さは少なくとも６ビット以上である。７ビットを採用する実施形態は、図６に示すように、ＬＣＧ ＢＳがＬＣＧ番号に対応するＬＣＧのバッファ送信待ちデータ量レベルを表し、８ビットを採用する実施形態は、図７に示すようなものであり、９ビットを採用する実施形態は、図８に示すようなものである。さらに多くのビットを採用する実施形態は、上記した実施形態の方法を参照できるため、ここで、重複して例を挙げない。

実施形態２
バッファ送信待ちデータ量のレベルと実際のバッファ送信待ちデータ量との対応をとる方法は、以下のとおりである。各レベルは１つのデータ量の範囲に対応し、隣接レベルに対応するデータ量の範囲は連続的であり、各レベルに対応するデータ量の範囲の大きさは固定値であってよいし、レベルの増加に伴い増加する増加値であってもよいし、以上の２種の方法の組合せであってもよい。本発明に記載されるＢＳＲのバッファ送信待ちデータ量レベルと実際のバッファ送信待ちデータ量との対応関係は、従来技術（ＬＴＥ Ｒｅｌｅａｓｅ８）に定義される対応関係に新しい対応関係を付加することで生成してもよいし、従来技術に定義される対応関係を変更することにで生成してもよいし、新規な対応関係が設定されてもよい。

レベル長さが７ビットであり、各レベルに対応するデータ量の範囲がレベルの増加に伴い増加することを例に挙げると、バッファ送信待ちデータ量のレベルとＬＣＧの実際のバッファ送信待ちデータ量との対応関係の実施形態は、図９の表に示すようになる。この表において、各レベルに表されたバッファ送信待ちデータ量の範囲の上限は下限を基から１７％累増したものであり、合計７９レベルであり、７ビットで表示する必要がある。最大レベルに表された正確なバッファ送信待ちデータ量は１５０００００バイトである。

レベル長さが８ビットであり、各レベルに対応するデータ量の範囲が固定値と増加値との２種の方法の組合せを採用することを例に挙げると、バッファ送信待ちデータ量のレベルとＬＣＧの実際のバッファ送信待ちデータ量との対応関係の実施形態は、図１０の表に示すようになる。この表において、前半の６３レベルは図９と同じ方法によって設定され、後半のレベルに表されたデータ量の範囲はいずれも固定の１００００バイトである。合計１３１レベルがあり、８ビットで表示される。最大レベルに表された正確なバッファ送信待ちデータ量は１５０００００バイトである。

従来のＬＴＥ Ｒｅｌｅａｓｅ８のＬＣＧバッファレベルとデータ量範囲との対応関係表には６４レベルしかなく、正確に表示可能なバッファデータ量の最大量は１５００００バイトしかない。上記２つの実施形態は、従来のＬＴＥ Ｒｅｌｅａｓｅ８のレベルとデータ量範囲との対応関係表に新しいレベル定義が追加されたものである。すなわち、上記２つの例における前半の６４レベルの定義はＬＴＥ Ｒｅｌｅａｓｅ８の定義と同じである。

もちろん、６４レベルの設定を採用してもよいが（６ビットレベル長さのみを必要とする）、新規対応関係を設定すると、例えば、各レベルに表されたバッファデータ量範囲の上限がすべて下限から１７０％累増し、これによって、６４レベルの対応関係表は最大で１５０００００バイトの実際のバッファデータ量を表示できる。当該実施形態の実施方法は、図９の実施形態を参照できるため、ここでは表を示さない。

他の８ビット、９ビットまたはさらに多くのビット長さのレベルの設定方法については、７ビットと６ビットの例を参照できるため、重複して例を挙げない。

前記実施形態と同じ方法を採用すれば、より小さいバッファデータ量をサポートすることできるだけではなく、より大きいバッファデータ量をサポートすることもできるため、重複して例を挙げない。

実施形態３
加えて、ＬＴＥ Ｒｅｌｅａｓｅ８に定義されるＬＣＧバッファデータ量レベルとデータ量範囲との対応表を使用してもよいが、当該表の対応関係の定義を変更して、当該表が正確に最大７５００００バイトの実際のＬＣＧバッファデータ量を表示できるようにする。例えば、本実施形態において、ＬＴＥ Ｒｅｌｅａｓｅ８に定義されるＬＣＧバッファレベルとデータ量範囲との対応関係表を再び使用する。図１１に示すように、本実施形態におけるＢＳＲデータユニットの構成方法は、図８に示す方法を採用する（ＬＣＧバッファデータ量レベル長さが９ビットで表示される）。図１１に示す対応関係表には、６４レベルしかないが、正確に最大で１５００００バイトを表示できる。これによって、本実施形態にて追加される新しい定義関係式は下記のようである。

ここで、Ｍは、対応関係表の最大レベル６３であり、Ｆは、ＬＣＧの実際のバッファ送信待ちデータ量であり、Ｇは、レベルＭに表されるデータ量範囲の下限であり、Ｌ字形状の記号（左下限）及びそのＬ字形状と対をなす逆Ｌ字形状の記号（右下限）は、端数を切り捨てて最も値の近い整数にする演算であり、「％」は、モジュラ計算であり、ｆ（）は、ルックアップテーブル演算であり、すなわち、前記対応関係表によって、データ量「Ｆ％Ｇ」に対応するレベルを検索することである。

ｅＮＢは、当該レベル情報を受信した後に、下記の公式によって当該レベル情報に対応する実際データ量を計算する。

ここで、Ｈは、当該ＬＣＧのバッファ送信待ちデータ量レベルであり、ｆ'（）は、ルックアップテーブル演算であり、すなわち、前記対応関係表によって、レベル「Ｈ％Ｍ」に対応する実際のバッファ送信待ちデータ量範囲を検索することである。バッファデータ量レベルと実際のバッファデータ量との対応関係を上記公式に変更すると、現在の６４レベルのみを有する対応関係表が１５０００００バイトの実際のバッファデータ量を表示できるようになり、前記実際のバッファデータ量に対応するバッファデータ量レベルが６４０レベルに達することができる。本実施形態における対応関係公式を採用すれば、より大きいレベル及びより大きい実際のバッファデータ量であってもサポートできる。

以下、具体的な数値を取って例として上記公式の変数に代入して、上記公式の意味をさらに説明する。

ＵＥのあるＬＣＧに７０００００バイトの送信待ちデータ量があると仮定すると、ＵＥにより報告されたＢＳＲにおいて、当該ＬＣＧのデータ量レベルは、以下の式により３１６となる。

逆に、ｅＮＢは、当該ＬＣＧのバッファ送信待ちデータ量レベルを受信した後に、当該ＬＣＧのバッファ送信待ちデータ量レベルに代表される実際のデータ量範囲は、以下の式により算出することができる。

７０００００バイトは、当該範囲に含まれる。ＵＥのＬＣＧにはより大きい送信待ちデータ量があると仮定しても、上記公式が前記より大きい送信待ちデータ量に相応するレベルの対応関係をサポートできることを検証しやすい。本実施形態の方法を採用する利点は、バッファデータ量レベルとデータ量範囲との新規対応関係表を再設定する必要がないし、ＬＴＥ ｒｅｌｅａｓｅ８スタンダードとの互換性がよいことにある。本実施形態におけるバッファデータ量レベル情報のビット長さは１０ビットである（６４０レベルを表示する必要がある）。もちろん、サポートしようとする最大バッファデータ量がより小さいと、当該バッファデータ量に相応するバッファデータ量レベル情報のビット長さが低減しうる。サポートしようとする最大バッファデータ量がさらに大きいと、当該バッファデータ量に相応するバッファデータ量レベル情報のビット長さを増加する必要がある。

実施形態４
ＵＥの一部のＬＣＧのバッファステータス情報を含む構成方法は、以下の特徴を有する。ＢＳＲはＬＣＧの番号情報を含み、当該情報はＬＣＧの順によって配列される全てのＬＣＧのビットマップを表し、当該情報の長さはＮビットであり、ＮはＬＣＧの総数である。ＬＣＧのビットマップにおけるあるビットが１（または０）であると、当該ビットに対応するＬＣＧのバッファ送信待ちデータ量情報が当該ＢＳＲに含まれることを表す。ＬＣＧのビットマップにおけるあるビットが０（または１）であると、当該ビットに対応するＬＣＧのバッファ送信待ちデータ量情報が当該ＢＳＲに含まれないことを表す。当該ＢＳＲは前記ビットマップにおける対応するＬＣＧのバッファ送信待ちデータ量レベル情報をさらに含み、ＬＣＧのバッファ送信待ちデータ量レベル情報はそのビットマップでの順によって、順次に配列される。

バッファ送信待ちデータ量レベル情報長さが７ビットであることを例に挙げると、ＢＳＲデータユニットの設計の一実施形態は、図１２に示すように、ＬＣＧのビットマップが「１０１０」である場合に、ＢＳＲがＬＣＧ０とＬＣＧ２とのバッファ送信待ちデータ量レベルを含むことを表し、その時、ＢＳＲの長さは合計３バイトである。ビットマップが「０００１」であると、ＢＳＲがＬＣＧ３のバッファ送信待ちデータ量レベルのみを含むことを表し、その時、ＢＳＲの長さは合計２バイトである。全てのＬＣＧのバッファ送信待ちデータ量レベルは、ＬＣＧの番号順によって順次に配列される。バッファ送信待ちデータ量レベル情報長さが異なるほかの実施形態の設計方法に対して本実施形態を参照できるため、ここで、重複して例を挙げない。バッファ送信待ちデータ量レベルと実際のバッファ送信待ちデータ量との対応関係の設計は上記実施形態と同じであるため、ここで重複して例を挙げない。

実施形態５
ＵＥの全てのＬＣＧのバッファステータス情報を含む構成方法は、以下の特徴を有する。ＢＳＲはＵＥの全てのＬＣＧのバッファ送信待ちデータ量レベル情報を含み、ＬＣＧのバッファ送信待ちデータ量レベル情報がＬＣＧの番号順によって、順次に配列される。

バッファ送信待ちデータ量レベル情報長さが９ビットであることを例に挙げると、ＢＳＲデータユニットの設計の一実施形態は、図１３に示すようになる。ＢＳＲデータユニットが既に全てのＬＣＧのバッファデータ量レベル情報を含むため、ＬＣＧの番号情報を必要としない。全ての４つのＬＣＧのバッファデータ量レベル情報がＬＣＧの番号順によって、順次に配列される。当該ＢＳＲデータユニットの総長さが固定の５バイトである。全てのＬＣＧにバッファ送信待ちデータがあるわけではないとしても、当該ＢＳＲデータユニットは全てのＬＣＧのバッファデータ量レベル情報を含む必要がある（バッファ送信待ちデータを有しないＬＣＧのバッファデータ量レベル情報は０である）。バッファ送信待ちデータ量レベル情報長さが異なるほかの実施形態の設計方法に対して本実施形態を参照できるため、ここで、重複して例を挙げない。バッファ送信待ちデータ量レベルと実際のバッファ送信待ちデータ量との対応関係の設計は上記実施形態と同じであるため、ここでは重複して例を挙げない。

実施形態６
ＢＳＲデータユニットに含まれるバッファステータス情報に対応するオブジェクトがＬＣＨである場合の設計方法については、上記したＬＣＧの実施形態を参照できる。相違点は、ＬＣＨの数がＬＣＧの数より多く、すなわち、オブジェクトがＬＣＨである場合に、ＢＳＲデータユニットに含まれるＬＣＨの番号情報の長さがより長いことだけである。ＢＳＲデータユニットに含まれるＬＣＨのバッファ送信待ちデータ量レベル情報の長さの設計方法はＬＣＧのものと同じであるので、ＬＣＨの方法について重複して例を挙げない。

実施形態７
ＵＥによってＢＳＲデータユニットを構成し送信する基本的なフローは図１４に示すようなものであり、当該プロセスは各ＴＴＩにおいて実行され、当該プロセスのステップは下記のようなものである。

ステップ１４０１：現在のＴＴＩにおいて、ＵＥに使用可能なアップリンク無線リソースがあるかどうかを判断し、ＵＥに使用可能なアップリンク無線リソースがある場合、次のステップ１４０２に進み、ＵＥに使用可能なアップリンク無線リソースがない場合、ＵＥは現在のＴＴＩにおいてアップリンク送信をしない。

ステップ１４０２：ＵＥにトリガーされたＢＳＲがあるかどうかを判断し、ＵＥにトリガーされたＢＳＲがある場合、次のステップ１４０３に進み、ＵＥにトリガーされたＢＳＲがない場合、ステップ１４０５に進む。

ステップ１４０３：ＵＥは、アップリンクコンポーネントキャリアの無線リソース状況に応じて、ＢＳＲデータユニットを送信するためのアップリンクコンポーネントキャリアの無線リソースを選択し送信する。ＵＥは、１つのアップリンクコンポーネントキャリアにおいて使用可能な無線リソースを有する場合に、当該コンポーネントキャリアの無線リソースにおいて、ＢＳＲデータユニットを送信する。ＵＥは、複数のアップリンクコンポーネントキャリアにおいて使用可能な無線リソースを有する場合に、例えば、図１５に示すように、１つのアップリンクコンポーネントキャリアの無線リソースにおいてＢＳＲデータユニットを送信してもよいし、例えば、図１６と図１７に示すように、複数のアップリンクコンポーネントキャリアの無線リソースにおいてＢＳＲデータユニットを送信してもよい。ステップ１４０３には、多種の実施形態があり、具体的には、下記のようなものである。

ＵＥは、複数の使用可能な無線リソースを有するコンポーネントキャリアがある場合に、そのうちの１つだけのコンポーネントキャリアにおいてＢＳＲデータユニットを送信してもよいし、全てのコンポーネントキャリアにおいてＢＳＲデータユニットを送信してもよいし、１つの絶対数量値によって、ＢＳＲデータユニットを送信するためのコンポーネントキャリアの数を選択してもよいし、使用可能な無線リソースを有するアップリンクコンポーネントキャリアの数に比率値をかけることによって得られた数値によって、ＢＳＲデータユニットを送信するためのアップリンクコンポーネントキャリアの数を選択してもよいし、ｅＮＢに送信されたアップリンクコンポーネントキャリアの無線リソースのチャネル品質に関する情報、及びｅＮＢにより設定されたチャネル品質に関する閾値情報によって、チャネルの品質が前記閾値に優れるアップリンクコンポーネントキャリアの無線リソースを選択してＢＳＲデータユニットを送信してもよい。

前記絶対数量値、比率値または閾値情報は、ＵＥ側に予め設定されるものであってもよいし、ｅＮＢにより設定され、かつ、放送メッセージ、ＲＲＣメッセージ、アップリンクグラントメッセージまたは専用に設定される媒体アクセス制御ＭＡＣ制御要素を介してＵＥへ送信されるものであってもよい。

チャネルの品質に関する情報は、ＭＣＳ、信号対干渉雑音電力比情報、信号対雑音比情報、パケット誤り率情報、ブロック誤り率情報、またはビット誤り率情報であってよい。

例えば、ＵＥには、現在のＴＴＩにおいて、使用可能なリソースを有するアップリンクコンポーネントキャリアが３つあり、ＵＥの使用可能なリソースのＭＣＳがそれぞれ、１０、１５及び２１であり、ｅＮＢがＲＲＣメッセージを送信してＵＥに通知し、ＭＣＳの閾値が１２であるとすると、ＵＥは、後の２つのコンポーネントキャリアを選択してＢＳＲデータユニットを搬送する。

また、例えば、ＵＥには、現在のＴＴＩにおいて、使用可能なリソースを有するアップリンクコンポーネントキャリアが３つあり、ＵＥが１つのアップリンクコンポーネントキャリアを介してＢＳＲを送信することをシステムにより設定されるとすると、ＵＥが１つのアップリンクコンポーネントキャリアをランダムに選択してＢＳＲデータユニットを搬送する。

また、例えば、ＵＥに現在のＴＴＩにおいて、使用可能なリソースを有するアップリンクコンポーネントキャリアが３つあり、ｅＮＢが放送メッセージを送信して、１：３の比率に応じてＢＳＲを送信するためのアップリンクコンポーネントキャリアを選択することをＵＥに通知し、アップリンクグラントを介してｅＮＢに送信された各アップリンクコンポーネントキャリアの信号対干渉雑音電力比が、それぞれ１５ｄＢ、１２ｄＢ、及び１０ｄＢであるとすると、ＵＥは、そのうちの最も高い信号対干渉雑音電力比のアップリンクコンポーネントキャリアを選択してＢＳＲデータユニットを送信する。ｅＮＢが信号対雑音比情報、パケット誤り率情報、ブロック誤り率情報、またはビット誤り率情報を送信してもよいが、その方法は上記の例と同じであるため、重複して例を挙げない。

また、例えば、ＵＥには、現在のＴＴＩにおいて、使用可能なリソースを有するアップリンクコンポーネントキャリアが３つあり、ＵＥが全ての使用可能なリソースを有するアップリンクコンポーネントキャリアにおいてＢＳＲを送信できることをシステムにて設定されると、ＵＥは、全てのコンポーネントキャリアを選択してＢＳＲデータユニットを搬送する。

ＵＥがＢＳＲデータユニットを送信するためのコンポーネントキャリアの数を確定した後に、複数のコンポーネントキャリアにおいて、ＢＳＲデータユニットを送信するためのコンポーネントキャリアにおけるリソースを選択する方法は、以下の方法を含む。

ランダムに選択する方法、コンポーネントキャリアの番号順に応じて選択する方法、または、よいチャネル品質のアップリンクコンポーネントキャリアの無線リソースを優先的に選択してＢＳＲを送信する方法である。上記した方法における第１の方法と第３の方法が上記の例に採用され、第２の方法も上記の例に適用できるため、別途例を挙げない。

ステップ１４０４：各アップリンクコンポーネントキャリアにおいて送信されるＢＳＲデータユニットのＢＳＲタイプを選択する。複数のアップリンクコンポーネントキャリアの無線リソースにおいて送信される複数のＢＳＲデータユニットは、同じＢＳＲタイプであってもよいし、異なるＢＳＲタイプであってもよい。

例えば、ステップ１４０３において、ＵＥが３つのアップリンクコンポーネントキャリアを選択してＢＳＲデータユニットを送信し、かつ、ＵＥのＬＣＧ０、ＬＣＧ１及びＬＣＧ３にはバッファ送信待ちデータがあるとすると、この３つのコンポーネントキャリアにおけるＢＳＲデータユニットの構成方法は、図１８に示すように選択されてよく、すなわち、各ＢＳＲデータユニットが全てのＬＣＧバッファステータス情報を含む。あるいは図１９に示すように選択されてもよく、すなわち、各ＢＳＲデータユニットが１つだけのＬＣＧバッファステータス情報を含み、３つのキャリアのＢＳＲデータユニットが合わせて全てのバッファ送信待ちデータを有するＬＣＧバッファステータス情報を含む。あるいは図２０に示すように選択されてもよく、すなわち、そのうちの１つのキャリアが全てのＬＣＧバッファステータス情報を含むＢＳＲデータユニットを送信し、他の２つのキャリアが一部または１つのＬＣＧバッファステータス情報を含むＢＳＲデータユニットを送信する。

上記した３つの例におけるＬＣＧバッファ送信待ちデータ量レベル情報の長さはいずれも９ビットであり、ほかの長さに設定されてもよい。当該レベル情報の長さの設定方法は、ｅＮＢとＵＥ側で固定的に設定される方法であってもよいし、または、ｅＮＢに設定され、かつ、放送チャネルまたは専用に設定されるＲＲＣメッセージを介してＵＥに通知する方法であってもよいし、または、ＵＥによりシステムに設定された当該ＵＥの全てのアップリンクコンポーネントキャリアの総帯域幅に応じて選択され、総帯域幅が大きいほど、より長いバッファ送信待ちデータ量の情報長さを選択する方法であってもよい。

例えば、ｅＮＢによってＵＥに設定された全てのアップリンクコンポーネントキャリアの総帯域幅が２０ＭＨｚ未満であると、ＵＥに選択されたＢＳＲデータユニットのＬＣＧバッファ送信待ちデータ量レベル情報の長さは６ビットである。ｅＮＢによってＵＥに設定された全てのアップリンクコンポーネントキャリアの総帯域幅が２０ＭＨｚから４０ＭＨｚまでの間であると、ＬＣＧバッファ送信待ちデータ量レベル情報の長さは７ビットである。ｅＮＢによってＵＥに設定された全てのアップリンクコンポーネントキャリアの総帯域幅が６０ＭＨｚから８０ＭＨｚまでの間であると、ＬＣＧバッファ送信待ちデータ量レベル情報の長さは８ビットである。上記した例は、バッファ送信待ちデータ量レベル情報長さを選択する絶対的な方法ではない。バッファ送信待ちデータ量レベルと実際データ量との対応関係が異なるように設定されると、適切なレベル情報長さも異なり、例えば、各送信待ちデータ量レベルに対応する実際データ量範囲が相対的に小さく設定されると、必要なレベル情報の長さが相対的に長くなる。

レベル情報の長さのほかの設定方法については、例を挙げない。

ステップ１４０５：ＵＥは、バッファ送信待ちデータとステップ１４０３において生成されたＢＳＲデータユニットとをＭＡＣ ＰＤＵにカプセル化する。すなわち、ＵＥは、各コンポーネントキャリアにおける使用可能なリソースの量に応じて、バッファ送信待ちデータを各コンポーネントキャリアのＭＡＣ ＰＤＵにおけるＳＤＵとしてカプセル化し、ステップ１４０３において選択されたＢＳＲデータユニットをＭＡＣ ＰＤＵにおけるＣＥとしてカプセル化する。

ステップ１４０６：ＭＡＣ ＰＤＵのパディングビットを介して搬送されるＢＳＲであるパディング型ＢＳＲをトリガーする必要があるかどうかを判断する。判断条件は、以下のとおりである。少なくとも１つのアップリンクコンポーネントキャリアにおいて、パディング用ビット数が１つのＬＣＧのバッファステータス情報を含む前記構成方法に必要なビット長さとパディングビットに対応するＭＡＣサブヘッダのビット長さとの合計以上である。パディング型ＢＳＲをトリガーする必要があると、ステップ１４０７に進み、パディング型ＢＳＲをトリガーする必要がないと、アップリンク送信を直接に実施する。

パディング型ＢＳＲは、他のタイプのＢＳＲを補充するものであり、１つのＭＡＣ ＰＤＵが、既に非パディング型のＢＳＲを含む場合、パディング型ＢＳＲをさらに含むことができない。

本発明の内容によれば、非パディング型のＢＳＲデータユニットを搬送したコンポーネントキャリアに加えて、パディング型ＢＳＲのトリガー条件を満足するほかのコンポーネントキャリアがある場合、パディング型ＢＳＲをトリガーする必要があるかどうかを判断する方法は、以下の1つを含む。

パディング型ＢＳＲのトリガー条件を満足するコンポーネントキャリアがあり、かつ、現在のＴＴＩにおいて非パディング型のＢＳＲが送信されない場合、パディング型ＢＳＲをトリガーし、非パディング型のＢＳＲが送信される場合、パディング型ＢＳＲをトリガーしない。

あるいは、パディング型ＢＳＲのトリガー条件を満足するコンポーネントキャリアがあり、かつ、現在のＴＴＩにおいて非パディング型のＢＳＲが送信されても、依然としてパディング型ＢＳＲをトリガーする。

第１の方法については、例えば、図２１に示すように、現在のＴＴＩにおいて、ＵＥには、使用可能なリソースを有するアップリンクコンポーネントキャリアが３つあり、かつトリガーされた非パディング型のＢＳＲがないと、ＵＥは、全ての３つの使用可能なコンポーネントキャリアを選択してパディング型ＢＳＲを送信する。

また、例えば、図２２に示すように、現在のＴＴＩにおいて、ＵＥには、使用可能なリソースを有するアップリンクコンポーネントキャリアが３つあり、かつ、ＵＥが１つのコンポーネントキャリアにおいて非パディング型のＢＳＲのデータユニットを搬送し、他の２つのコンポーネントキャリアがパディング型ＢＳＲのトリガー条件を満足しても、ＵＥは、相変わらずパディング型ＢＳＲをトリガーしない、

第２の方法については、例えば、図２３に示すように、現在のＴＴＩにおいて、ＵＥには、使用可能なリソースを有するアップリンクコンポーネントキャリアが３つあり、かつ、ＵＥが１つのコンポーネントキャリアにおいて非パディング型のＢＳＲのデータユニットを搬送し、ほかの２つのコンポーネントキャリアがパディング型ＢＳＲのトリガー条件を満足すると、ＵＥはパディング型ＢＳＲをトリガーし、且つほかの２つの使用可能なコンポーネントキャリアを選択してパディング型ＢＳＲを搬送する。

ステップ１４０７：パディング型ＢＳＲを搬送できる各コンポーネントキャリアにおけるＢＳＲデータユニットのＢＳＲタイプを選択する。パディング型ＢＳＲデータユニットのタイプの選択方法は、非パディング型のＢＳＲデータユニットのタイプの選択方法と同じである。唯一の相違点は、パディング型ＢＳＲデータユニットの構成方法の選択が、当該ＢＳＲデータユニットがあるＭＡＣ ＰＤＵのパディングビットの数に基づいて決まなければならないことである。パディングビットの数が全ての４つのＬＣＧのバッファステータス情報を搬送するために十分である場合、ＢＳＲデータユニットは図１３に示すように構成することができる。パディングビットの数が１つのＬＣＧのバッファステータス情報を搬送できる場合、ＢＳＲデータユニットは図６、図７、図８に示すように構成することができる。パディングビットの数が一部のＬＣＧのバッファステータス情報を搬送できると、図１２に示すように構成することができる。上記において複数の実施形態を挙げたため、ここで、重複して例を挙げない。

ステップ１４０８：ＵＥは、ステップ１４０７において生成されたＢＳＲデータユニットをＭＡＣ ＰＤＵにカプセル化する。

ＵＥは、全てのデータとＢＳＲデータユニットとのカプセル化及びパッケージ化を完了した後に、アップリンク送信を行う。

実施形態８
本発明にて設計されるＢＳＲデータユニットはキャリアアグリゲーション技術をサポートするＬＴＥ−Ａｄｖａｎｃｅｄシステムに適用することができ、従来のＬＴＥ Ｒｅｌｅａｓｅ８スタンダードのＢＳＲのタイプと異なる。したがって、あるＵＥがＬＴＥ−ＡｄｖａｎｃｅｄシステムのｅＮＢと接続を確立した後に、ｅＮＢにより、当該ＵＥにより送信されたＢＳＲデータユニットがＬＴＥ Ｒｅｌｅａｓｅ８スタンダードに定義されるタイプを採用しているか、本発明により新たに追加されたタイプを採用しているかを判断する方法は、下記方法のいずれかを含む。

ＭＡＣサブヘッダにおいて、ＢＳＲタイプに対応する識別情報を追加する。ｅＮＢが、ＵＥに送信されたＭＡＣ ＰＤＵを受信した後に、ＭＡＣサブヘッダにおける前記識別情報に応じて、ＭＡＣ ＰＤＵに前記ＢＳＲを含むことを取得する。例えば、アップリンクＭＡＣ ＰＤＵのＭＡＣサブヘッダにおける論理チャネルＩＤフィールドに下記の表に示すような定義を追加する。

当該論理チャネルＩＤフィールドは、ＭＡＣ ＰＤＵにおいて、当該ＭＡＣサブヘッダに対応するＭＡＣ ＣＥが搬送するＢＳＲのタイプをｅＮＢに知らせることに用いられる。ｅＮＢが当該ＭＡＣサブヘッダを受信した後に、ｅＮＢは、ＵＥに送信されたＢＳＲタイプがＬＴＥ ｒｅｌｅａｓｅ８スタンダードのタイプであるか、本発明のタイプであるかを認知する。番号１０１１１、１１０００及び１１００１は、論理チャネルＩＤフィールドの保留ビットであり、新しい定義として用いることができる。

または、ＭＡＣサブヘッダにおける既存の１つまたは複数の識別情報の対応関係を変更して、変更された対応関係の前記識別情報を本発明のＢＳＲタイプに対応させる。ＵＥがＵＥ能力情報を含むＲＲＣメッセージをｅＮＢへ報告した後に、ｅＮＢは、ＵＥに送信されたＭＡＣ ＰＤＵにおけるＭＡＣサブヘッダが、変更された対応関係の識別情報の前記ＭＡＣ サブヘッダであるかどうかを、ＵＥ能力情報に応じて判断する。例えば、アップリンクＭＡＣ ＰＤＵのＭＡＣサブヘッダにおける従来の論理チャネルＩＤフィールドの定義を下記の表に示すような定義に変更する。

番号１１１００、１１１０１、１１１１０は、ＬＴＥ ｒｅｌｅａｓｅ８スタンダードにおいて、Ｔｒｕｎｃａｔｅｄ ＢＳＲ、ショートＢＳＲ、ロングＢＳＲを識別することに用いられる。本例において、この３つの番号に新しい定義（すなわち、括弧に示すような定義）を付与する。ｅＮＢは、ＵＥ能力情報を含むメッセージを受信した後に、当該ＵＥがＬＴＥ ＵＥに属することを認知すると、これから当該ＵＥに送信されたＢＳＲがすべてＬＴＥ ｒｅｌｅａｓｅ８スタンダードの定義を適用すると判断し、当該ＵＥがＬＴＥ ａｄｖａｎｃｅｄ ＵＥに属することを認知すると、これから当該ＵＥに送信されたＢＳＲがすべて括弧内に示される定義を適用すると判断する。

または、ＭＡＣサブヘッダにおける１つまたは複数の識別情報の既存の対応関係を変更して、変更された対応関係の前記識別情報を本発明のＢＳＲタイプに対応させる。ここで、当該方法は前記方法と同じであり、上記の表に係る例を参照してよい。ＵＥがｅＮＢとＲＲＣ層リンクを確立した後に、ｅＮＢは、ＲＲＣ専用メッセージを送信して、変更された対応関係の識別情報のＭＡＣサブヘッダを使用するかどうかをＵＥに通知する。例えば、ｅＮＢがＵＥがＬＴＥ Ａｄｖａｎｃｅｄ ＵＥであることを認知し、かつ、ＵＥに複数のアップリンクコンポーネントキャリアを設定した場合、ｅＮＢは、ＲＲＣメッセージを介して、上記の表における括弧に示される定義を使用することをＵＥに通知する。ｅＮＢが当該ＵＥに１つのアップリンクコンポーネントキャリアを設定した場合、ｅＮＢは、ＲＲＣメッセージを介して、上記の表における括弧に示される定義を使用することをＵＥに通知してもよいし、ＬＴＥ ｒｅｌｅａｓｅ８スタンダードの定義を使用することをＵＥに通知してもよい。

本発明は、ＬＴＥ−Ａｄｖａｎｃｅｄのバッファ状態報告ＢＳＲデータユニットの新規かつ実際的なフォーマットを追加定義し、特に、ＬＴＥ−Ａｄｖａｎｃｅｄの大容量性に適用するデータ量レベル情報確定メカニズムを提供し、データ量レベルの長さが６ビット以上になるようにする。

本発明は、また、ＬＴＥ−ＡｄｖａｎｃｅｄシステムにおけるＢＳＲ送信のトリガー条件を新たに追加する。さらに、端末には複数の使用可能なコンポーネントキャリアの無線リソース情報を有する場合に対して、具体的に、１つまたは複数のコンポーネントキャリアを選択して前記ＢＳＲデータユニットの具体的なタイプを送信する。本発明は、ＬＴＥ−Ａｄｖａｎｃｅｄシステムの広帯域幅性を十分に利用した上で、ＢＳＲデータユニットの送信の高効率化及び高品質化も実現できる。

上記の説明は、本発明の好ましい実施形態にすぎず、本発明の特許請求の範囲を限定することに用いられるものではない。本発明の要旨と実質を逸脱しない範囲で、当業者にとっては、本発明に応じて様々な相応する変更と変形を実施することができる。本発明の要旨と原則にのっとる様々の修正、等同交替、改良などが本発明の特許請求の範囲に含まれるべきである。

本発明に係るマルチキャリアシステム、端末、及びＢＳＲ報告方法によれば、ＵＥに割り当てられたコンポーネントキャリアリソースの状況によって、１つまたは多種のＢＳＲを柔軟に生成し、かつ、適切なコンポーネントキャリアを選択してＢＳＲを送信することにより、バッファ状態報告の送信正確率を保証するとともにアップリンク無線リソースを節約する。本発明は、ＬＴＥ−Ａｄｖａｎｃｅｄシステムの広帯域幅性を十分に利用した上で、ＢＳＲデータユニットの送信の高効率及び高品質も実現できる。

Claims (24)

1. 端末がバッファ状態報告（Ｂｕｆｆｅｒ Ｓｔａｔｕｓ Ｒｅｐｏｒｔ、ＢＳＲ）をトリガーし、無線ネットワークにおけるアップリンクコンポーネントキャリアの無線リソース情報を取得し、
   バッファ送信待ちデータ量情報に応じて、１つまたは複数のＢＳＲデータユニットを構成し、
   使用可能な無線リソースを有する前記アップリンクコンポーネントキャリアから、１つまたは複数のアップリンクコンポーネントキャリアを選択し、選択されたアップリンクコンポーネントキャリアの無線リソースにおいて前記ＢＳＲデータユニットをネットワーク側に送信し、
   前記端末がバッファ送信待ちデータ量情報に応じてＢＳＲデータユニットを構成する場合に、ＢＳＲデータユニットの内容構成に応じて、構成された前記ＢＳＲデータユニットを異なるタイプに分ける
   バッファ状態報告を報告する方法。
2. 前記端末がＢＳＲをトリガーするトリガー条件は、
   少なくとも１つのアップリンクコンポーネントキャリアにおいて、前記端末の使用可能な無線リソースにおいてパディング用ビット数が、１つの論理チャネルグループ（Ｌｏｇｉｃａｌ Ｃｈａｎｎｅｌ Ｇｒｏｕｐ、ＬＣＧ）または１つの論理チャネル（Ｌｏｇｉｃａｌ Ｃｈａｎｎｅｌ、ＬＣＨ）のバッファステータス情報の構成方法に必要なビットの長さとパディングビットに対応する媒体アクセス制御（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ、ＭＡＣ）サブヘッダのビットの長さとの合計以上であることを含む請求項１に記載の方法。
3. 前記端末が複数のアップリンクコンポーネントキャリアの無線リソースにおいて前記ＢＳＲデータユニットを送信することを選択する場合に、複数のＢＳＲデータユニットを送信する場合、前記複数のＢＳＲデータユニットは、同じＢＳＲタイプまたは異なるＢＳＲタイプである請求項１に記載の方法。
4. 前記端末がＢＳＲデータユニットの内容構成に応じて、前記ＢＳＲデータユニットを異なるタイプに分ける場合に、前記ＢＳＲデータユニットの内容構成は、
   ＢＳＲデータユニットに含まれるバッファステータス情報に対応するオブジェクトがＬＣＧまたはＬＣＨのバッファステータス情報であること、
   ＢＳＲデータユニットが前記端末の１つのＬＣＧまたは１つのＬＣＨのバッファステータス情報のみを含むこと、
   ＢＳＲデータユニットが前記端末の一部のＬＣＧまたは一部のＬＣＨのバッファステータス情報を含むこと、または、
   ＢＳＲデータユニットが前記端末の全てのＬＣＧまたは全てのＬＣＨのバッファステータス情報を含むこと、を含む請求項１に記載の方法。
5. ＢＳＲデータユニットが前記端末の１つのＬＣＧまたは１つのＬＣＨのバッファステータス情報のみを含む場合、当該ＢＳＲは、前記ＬＣＧまたはＬＣＨの番号情報を含み、前記ＬＣＧまたはＬＣＨのバッファ送信待ちデータ量情報をさらに含み、当該バッファ送信待ちデータ量情報の長さが６ビット以上である請求項４に記載の方法。
6. ＢＳＲデータユニットが前記端末の一部のＬＣＧまたは一部のＬＣＨのバッファステータス情報を含む場合、当該ＢＳＲデータユニットは、ＬＣＧまたはＬＣＨの番号情報を含み、当該番号情報はＬＣＧまたはＬＣＨの番号順に応じて配列されるすべてのＬＣＧまたはＬＣＨのビットマップを表し、当該番号情報の長さがＮビットであり、ＮがＬＣＧまたはＬＣＨの総数であり、ＬＣＧまたはＬＣＨのビットマップにおいてあるビットが１または０であることは、当該ビットに対応するＬＣＧまたはＬＣＨのバッファ送信待ちデータ量情報が当該ＢＳＲデータユニット内に含まれるかどうかを表し、当該ＢＳＲデータユニットは、ビットマップにおけるＬＣＧまたはＬＣＨに対応するバッファ送信待ちデータ量情報をさらに含み、当該バッファ送信待ちデータ量情報の長さが６ビット以上であり、ＬＣＧまたはＬＣＨのバッファ送信待ちデータ量情報がビットマップにおけるＬＣＧまたはＬＣＨの順序によって順次に配列される請求項４に記載の方法。
7. ＢＳＲデータユニットが前記端末の全てのＬＣＧまたは全てのＬＣＨのバッファステータス情報を含む場合、当該ＢＳＲデータユニットは、前記端末の全てのＬＣＧまたは全てのＬＣＨのバッファ送信待ちデータ量情報を含み、当該バッファ送信待ちデータ量情報の長さが６ビット以上であり、ＬＣＧまたはＬＣＨのバッファ送信待ちデータ量情報がＬＣＧまたはＬＣＨの番号順によって順次に配列される請求項４に記載の方法。
8. 前記バッファ送信待ちデータ量情報の長さは、
   進化型基地局（ｅｖｏｌｖｅｄ Ｂａｓｅ Ｓｔａｔｉｏｎ，ｅＮＢ）と前記端末側に固定的に設定され、または、
   前記ｅＮＢにより設定され、かつ、放送チャネル又は専用に設定される無線リソース制御（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ、ＲＲＣ）メッセージを介して前記端末に通知され、または、
   前記端末により、設定される全てのアップリンクコンポーネントキャリアの総帯域幅に応じて選択されるものであり、総帯域幅が大きいほど、長いバッファ送信待ちデータ量情報長さが選択される請求項５〜７のいずれか１項に記載の方法。
9. 前記ＢＳＲにおけるＬＣＧまたはＬＣＨのバッファ送信待ちデータ量情報は、ＬＣＧまたはＬＣＨの実際のバッファ送信待ちデータ量のレベル情報を表し、当該レベル情報とＬＣＧまたはＬＣＨの実際のバッファ送信待ちデータ量との対応関係は、各レベルが１つのデータ量範囲に対応し、隣接レベルに対応するデータ量範囲が連続的であり、各レベルに対応するデータ量範囲の大きさが固定値であり、または、レベルの増加に伴い増加する増加値であり、または、固定値と増加値との組合せであることを含み、
   前記対応関係は、単一キャリア技術において定義される対応関係に新規対応関係を追加することにより生成され、または、従来の単一キャリア技術に定義される対応関係を変更することにより生成され、または、新規な対応関係を設定することにより生成される請求項５〜７のいずれか１項に記載の方法。
10. ＢＳＲデータユニットの内容構成によって、構成された前記ＢＳＲデータユニットを異なるタイプに分ける前記ステップは、２つのＢＳＲデータユニットの内容構成の全ての特徴及び構成方法が完全に同じである場合、前記２つのＢＳＲデータユニットの内容構成が同じであると判定し、２つのＢＳＲデータユニットの内容構成の全ての特徴及び構成方法が完全には同じでない場合、前記２つのＢＳＲデータユニットの内容構成が同じではないと判定する請求項１又は３に記載の方法。
11. 前記端末に複数のＬＣＧまたはＬＣＨのバッファステータス情報がある場合に、前記端末が選択して送信するＢＳＲデータユニットの内容構成の原則は、
    同時に、前記端末ができるだけ多くのＬＣＧまたはＬＣＨのバッファステータス情報を選択してｅＮＢに送信すること、または、
    同時に、前記端末が高い優先度のＬＣＨを含むＬＣＧや高い優先度のＬＣＨのバッファステータス情報を優先的に送信すること、または、
    同時に、前記端末の１つまたは複数のＢＳＲデータユニットが既に全てのバッファ送信待ちデータを有するＬＣＧまたはＬＣＨのバッファステータス情報を含む場合、前記端末のほかのＢＳＲデータユニットが、バッファ送信待ちデータを有する一部のＬＣＧまたはＬＣＨのバッファステータス情報のみを含むこと、を含む請求項１０に記載の方法。
12. 前記端末が使用可能な無線リソースを有する前記アップリンクコンポーネントキャリアから、１つまたは複数のアップリンクコンポーネントキャリアを選択するステップは、
    前記端末が１つのアップリンクコンポーネントキャリアにおいて使用可能な無線リソースを有する場合に、前記端末が当該コンポーネントキャリアのみを選択し、
    前記端末が複数のアップリンクコンポーネントキャリアにおいて使用可能な無線リソースを有する場合に、前記端末が複数のコンポーネントキャリアから１つまたは複数のアップリンクコンポーネントキャリアを選択する請求項１に記載の方法。
13. 前記端末が複数のアップリンクコンポーネントキャリアにおいて使用可能な無線リソースを有する場合に、前記端末が前記複数のコンポーネントキャリアから１つまたは複数のアップリンクコンポーネントキャリアを選択するステップは、選択されるアップリンクコンポーネントキャリアの数を確定することを含み、
    前記選択されるアップリンクコンポーネントキャリアの数を確定するステップは、
    １４Ａ：前記端末が使用可能な無線リソースを有するアップリンクコンポーネントキャリアを１つのみ選択し、または、
    １４Ｂ：前記端末が使用可能な無線リソースを有するアップリンクコンポーネントキャリアを全て選択し、または、
    １４Ｃ：前記端末が１つの絶対数量値に応じて、選択されるアップリンクコンポーネントキャリアの数を確定し、または、
    １４Ｄ：前記端末が使用可能な無線リソースを有するアップリンクコンポーネントキャリアの数に１つの比率値をかけることにより得られた数値に応じて、選択されるアップリンクコンポーネントキャリアの数を確定する請求項１２に記載の方法。
14. 前記端末が複数のアップリンクコンポーネントキャリアにおいて使用可能な無線リソースを有する場合に、前記端末が前記複数のコンポーネントキャリアから１つまたは複数のアップリンクコンポーネントキャリアを選択するステップは、
    前記端末が、ネットワーク側のｅＮＢにより送信されたアップリンクコンポーネントキャリアの無線リソースのチャネル品質に関する情報及び／又は前記ｅＮＢに設定されたチャネル品質に関する閾値情報に応じて、前記チャネル品質に関する閾値情報よりも高い優先度のチャネル品質に関する情報をもつアップリンクコンポーネントキャリアを選択する請求項１２に記載の方法。
15. 前記ステップ１４Ｃにおける前記絶対数量値、及び前記ステップ１４Ｄにおける前記使用可能な無線リソースを有するアップリンクコンポーネントキャリアの数量に１つの比率値をかけることによって得られた前記数値は、いずれも１以上の数値である請求項１３に記載の方法。
16. 前記チャネル品質に関する情報は、変調符号化レベル情報、信号対干渉雑音電力比情報、信号対雑音比情報、パケット誤り率情報、ブロック誤り率情報、または、ビット誤り率情報を含む請求項１４に記載の方法。
17. 前記比率値と前記絶対数量値は、
    前記端末側において予め設定されたもの、または、
    ｅＮＢにより設定され、かつ、放送メッセージを介して前記端末へ送信されるもの、または
    前記ｅＮＢにより設定され、かつ、ＲＲＣメッセージを介して前記端末へ送信されるもの、または、前記ｅＮＢにより設定され、かつ、アップリンクグラントメッセージを介して前記端末へ送信されるもの、または、
    前記ｅＮＢにより設定され、かつ、特定の媒体アクセス制御（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ、ＭＡＣ）制御要素を介して前記端末へ送信されるものである請求項１３に記載の方法。
18. 前記端末が複数のアップリンクコンポーネントキャリアにおいて使用可能な無線リソースを有する場合に、選択されるアップリンクコンポーネントキャリアの数量を確定した後に、前記複数のアップリンクコンポーネントキャリアから１つまたは複数のアップリンクコンポーネントキャリアを選択するステップは、
    使用可能な無線リソースを有する複数のアップリンクコンポーネントキャリアにおいて、確定された数のアップリンクコンポーネントキャリアをランダムに選択すること、または、
    ｅＮＢに予め設定された、当該端末の使用中のアップリンクコンポーネントキャリアの番号順によって、小さい番号の確定された数のアップリンクコンポーネントキャリアを選択すること、または、
    前記ｅＮＢに送信された、アップリンクコンポーネントキャリアの無線リソースのチャネルの品質に関する情報によって、確定された数の高いチャネル品質のアップリンクコンポーネントキャリアを優先的に選択することをさらに含む請求項１３に記載の方法。
19. 前記端末が複数のアップリンクコンポーネントキャリアの無線リソースにおいて送信したＢＳＲデータユニットは、単一キャリアシステムに定義されたＢＳＲデータユニットタイプ、または、キャリアアグリゲーション技術をサポートする新規なＢＳＲデータユニットタイプであり、
    キャリアアグリゲーション技術をサポートする前記ＢＳＲデータユニットが、一部のＬＣＧのバッファステータス情報を含む短縮ＢＳＲデータユニット、１つのＬＣＧのバッファステータス情報を含むショートＢＳＲデータユニット、または、全てのＬＣＧのバッファステータス情報を含むロングＢＳＲデータユニットを含む請求項１又は４に記載の方法。
20. 前記端末が同一伝送時刻において、複数のアップリンクコンポーネントキャリアの無線リソースにおいて送信したＢＳＲデータユニットは、単一キャリアシステムに定義されたＢＳＲデータユニットタイプ、または、キャリアアグリゲーション技術をサポートする新規なＢＳＲデータユニットタイプであり、
    キャリアアグリゲーション技術をサポートする前記ＢＳＲデータユニットタイプは、一部のＬＣＧのバッファステータス情報を含む短縮ＢＳＲデータユニット、１つのＬＣＧのバッファステータス情報を含むショートＢＳＲデータユニット、または、全てのＬＣＧのバッファステータス情報を含むロングＢＳＲデータユニットを含む請求項１に記載の方法。
21. 前記端末が、ＭＡＣサブヘッダにＢＳＲタイプに対応する識別情報を追加し、ネットワーク側のｅＮＢが、前記端末により送信された媒体アクセス制御プロトコルデータユニット（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ Ｄａｔａ、ＭＡＣ ＰＤＵ）を受信した後に、ＭＡＣサブヘッダにおける前記識別情報に応じて、前記ＭＡＣ ＰＤＵに前記ＢＳＲ及び当該ＢＳＲのタイプが含まれることを取得し、または
    前記端末が、ＭＡＣサブヘッダにおける既存の１つまたは複数の識別情報の対応関係を変更してキャリアアグリゲーション技術をサポートする新規なＢＳＲデータユニットタイプに対応させ、前記端末がネットワーク側の前記ｅＮＢへ端末能力情報を含むＲＲＣ層メッセージを報告した後に、前記ｅＮＢが、端末能力情報によって、これから前記端末により送信されたＭＡＣ ＰＤＵにおけるＭＡＣサブヘッダが、前記識別情報の対応関係が変更されたＭＡＣサブヘッダであるかどうかを判断し、または、
    前記端末が、ＭＡＣサブヘッダにおける既存の１つまたは複数の識別情報の対応関係を変更してキャリアアグリゲーション技術をサポートする新規なＢＳＲデータユニットタイプに対応させ、前記端末がネット側の前記ｅＮＢと無線リソース制御（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ、ＲＲＣ）層リンクを確立した後に、前記ｅＮＢが、特定のＲＲＣ専用メッセージを送信して、前記識別情報の対応関係が変更されたＭＡＣサブヘッダを使用するかどうかを前記端末に通知する請求項１に記載の方法。
22. 前記端末が既にレギュラーバッファ状態報告をトリガーし、かつ、前記端末が現在の送信時間間隔（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｔｉｍｅ Ｉｎｔｅｒｖａｌ、ＴＴＩ）において新しいデータを送信するための物理アップリンク共有チャネル（Ｐｈｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ、ＰＵＳＣＨ）リソースを有しない場合、前記端末がスケジューリングリクエスト（Ｓｃｈｅｄｕｌｉｎｇ Ｒｅｑｕｅｓｔ、ＳＲ）をトリガーし、
    前記端末が既にＳＲをトリガーし、かつ、任意のアップリンクコンポーネントキャリアにおいても使用可能なＰＵＳＣＨリソースを有しない場合、前記端末が使用可能な物理アップリンク制御チャネル（Ｐｈｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｃｈａｎｎｅｌ、ＰＵＣＣＨ）リソースを有するＴＴＩにおいてＳＲを送信して、ｅＮＢに当該端末にＰＵＳＣＨリソースの割り当てを要求する請求項１に記載の方法。
23. 進化型基地局（ｅｖｏｌｖｅｄ Ｂａｓｅ Ｓｔａｔｉｏｎ、ｅＮＢ）と、端末とを備え、
    前記端末は、基地局から無線ネットワークのアップリンクコンポーネントキャリアの無線リソース情報を取得し、バッファ送信待ちデータ量情報によって、１つまたは複数のＢＳＲデータユニットを構成し、無線リソースを有する前記アップリンクコンポーネントキャリアから、１つまたは複数のアップリンクコンポーネントキャリアを選択し、選択されたアップリンクコンポーネントキャリアの無線リソースにおいて前記ＢＳＲデータユニットを前記ｅＮＢに送信し、バッファ送信待ちデータ量情報に応じてＢＳＲデータユニットを構成する場合に、ＢＳＲデータユニットの内容構成に応じて、構成された前記ＢＳＲデータユニットを異なるタイプに分けるように設定され、
    前記ｅＮＢは、前記端末にコンポーネントキャリア無線リソースを割り当て、アップリンクコンポーネントキャリアの無線リソースを介して前記端末により報告されたＢＳＲデータユニットを受信し、前記ＢＳＲデータユニットを解析して前記端末のバッファステータスを認知するように設定される
    バッファ状態報告（Ｂｕｆｆｅｒ Ｓｔａｔｕｓ Ｒｅｐｏｒｔ、ＢＳＲ）を報告するネットワークシステム。
24. 基地局により端末に割り当てたアップリンクコンポーネントキャリアの無線リソースを取得し、かつ、無線リソース情報を無線リソース選択モジュールに通知するように設定されるコンポーネントキャリア無線リソース取得モジュールと、
    前記端末のバッファ送信待ちデータ量情報を監視して取得し、かつ、当該送信待ちデータ量情報をバッファ状態報告生成モジュールに通知するように設定されるバッファ情報監視モジュールと、
    バッファ送信待ちデータ量情報に応じて、１つまたは複数のＢＳＲデータユニットを構成するように設定されるバッファ状態報告生成モジュールと、
    前記コンポーネントキャリア無線リソース取得モジュールから取得された前記無線リソースから、１つまたは複数の前記ＢＳＲデータユニットを送信するための１つまたは複数のアップリンクコンポーネントキャリアを選択し、かつ、選択結果をＢＳＲ送信モジュールに送信するように設定される無線リソース選択モジュールと、
    無線リソース選択モジュールで選択された無線リソースにおいて、バッファ状態報告生成モジュールにより生成された１つまたは複数の前記ＢＳＲデータユニットをネットワーク側の進化型基地局（ｅｖｏｌｖｅｄ Ｂａｓｅ Ｓｔａｔｉｏｎ、ｅＮＢ）に送信するように設定されるＢＳＲ送信モジュールとを含み、
    前記バッファ状態報告生成モジュールは、バッファ送信待ちデータ量情報に応じて異なるＢＳＲタイプを構成し、すなわち、ＢＳＲデータユニットの内容構成に応じて前記ＢＳＲデータユニットを異なるタイプに分けるように設定され、
    前記ＢＳＲデータユニットの内容構成は、
    ＢＳＲデータユニットが前記端末の１つの論理チャネルグループ（Ｌｏｇｉｃａｌ Ｃｈａｎｎｅｌ Ｇｒｏｕｐ、ＬＣＧ）または１つの論理チャネル（Ｌｏｇｉｃａｌ Ｃｈａｎｎｅｌ Ｇｒｏｕｐ、ＬＣＨ）のバッファステータス情報のみを含むこと、
    ＢＳＲデータユニットが前記端末の一部のＬＣＧまたは一部のＬＣＨのバッファステータス情報を含むこと、または、
    ＢＳＲデータユニットが前記端末の全てのＬＣＧまたは全てのＬＣＨのバッファステータス情報を含むことを含む
    バッファ状態報告（Ｂｕｆｆｅｒ Ｓｔａｔｕｓ Ｒｅｐｏｒｔ、ＢＳＲ）を報告する実施端末。

Images