(57)【要約】  ユーザ端末に設定可能なコンポーネントキャリア数が既存システムより拡張される場合であっても、通信を適切に行うこと。本発明の一態様に係るユーザ端末は、複数のコンポーネントキャリア（ＣＣ：Component  Carrier）を利用して通信するユーザ端末であって、上りデータを蓄積するデータバッファリング部と、蓄積される上りデータの量（バッファサイズ）とインデックスとを関連付けたＢＳＲ（Buffer  Status  Report）テーブルに基づいて、前記バッファサイズに対応する所定のインデックスを含むＢＳＲ  ＭＡＣ  ＣＥ（Medium  Access  Control  Control  Element）を生成する生成部と、前記ＢＳＲ  ＭＡＣ  ＣＥを送信する送信部と、を有し、前記ＢＳＲテーブルの１つは、当該ユーザ端末が５個より多いＣＣを設定された場合に用いる第１のＢＳＲテーブルであることを特徴とする。
2016182048.tif 000002
【特許請求の範囲】
【請求項１】
複数のコンポーネントキャリア（ＣＣ：Component  Carrier）を利用して通信するユーザ端末であって、
上りデータを蓄積するデータバッファリング部と、
蓄積される上りデータの量（バッファサイズ）とインデックスとを関連付けたＢＳＲ（Buffer  Status  Report）テーブルに基づいて、前記バッファサイズに対応する所定のインデックスを含むＢＳＲ  ＭＡＣ  ＣＥ（Medium  Access  Control  Control  Element）を生成する生成部と、
前記ＢＳＲ  ＭＡＣ  ＣＥを送信する送信部と、を有し、
前記ＢＳＲテーブルの１つは、当該ユーザ端末が５個より多いＣＣを設定された場合に用いる第１のＢＳＲテーブルであることを特徴とするユーザ端末。
【請求項２】
前記第１のＢＳＲテーブルは、インデックスが６ビット、かつＬＴＥ  Ｒｅｌ．１０のＢＳＲテーブルより大きなステップサイズで構成され、
前記生成部は、前記ＢＳＲ  ＭＡＣ  ＣＥを、ＬＴＥ  Ｒｅｌ．１０のＢＳＲ  ＭＡＣ  ＣＥと同じサイズで生成することを特徴とする請求項１に記載のユーザ端末。
【請求項３】
前記第１のＢＳＲテーブルは、インデックスがＸビット（Ｘ＞６）、かつＬＴＥ  Ｒｅｌ．１０のＢＳＲテーブル以下のステップサイズで構成され、
前記生成部は、前記ＢＳＲ  ＭＡＣ  ＣＥを、ＬＴＥ  Ｒｅｌ．１０のＢＳＲ  ＭＡＣ  ＣＥより大きなサイズで生成することを特徴とする請求項１に記載のユーザ端末。
【請求項４】
前記ＢＳＲテーブルの別の１つは、前記第１のＢＳＲテーブルと異なる第２のＢＳＲテーブルであり、
前記第１のＢＳＲテーブルは、３ＭＢより大きいバッファサイズに関するＢＳＲの生成に用いられ、
前記第２のＢＳＲテーブルは、３ＭＢ以下のバッファサイズに関するＢＳＲの生成に用いられることを特徴とする請求項１に記載のユーザ端末。
【請求項５】
前記送信部は、前記ＢＳＲと、前記ＢＳＲの生成に用いた前記第１のＢＳＲテーブル及び前記第２のＢＳＲテーブルのいずれかを特定する特定情報と、を含むＭＡＣシグナリングを送信することを特徴とする請求項４に記載のユーザ端末。
【請求項６】
前記特定情報は、ＬＴＥ  Ｒｅｌ．１０のＭＡＣ  ＰＤＵ（Protocol  Data  Unit）サブヘッダにおける予約（Ｒ：Reserved）フィールドで通知されることを特徴とする請求項５に記載のユーザ端末。
【請求項７】
前記第１のＢＳＲテーブルにおいては、前記ユーザ端末に設定される最大のＣＣ数に基づいて算出されたバッファサイズが、最大バッファサイズとして規定されることを特徴とする請求項１から請求項６のいずれかに記載のユーザ端末。
【請求項８】
前記所定のインデックスは、４個より多い数規定されるＬＣＧ（Logical  Channel  Group）のうち、いずれかのＬＣＧのバッファサイズに対応することを特徴とする請求項１から請求項７のいずれかに記載のユーザ端末。
【請求項９】
前記送信部は、５個より多いＣＣのキャリアアグリゲーションを設定可能な端末能力情報（ＵＥ  ｃａｐａｂｉｌｉｔｙ）とは別に、第１のＢＳＲテーブルを利用可能な端末能力情報を送信することを特徴とする請求項１から請求項８のいずれかに記載のユーザ端末。
【請求項１０】
複数のコンポーネントキャリア（ＣＣ：Component  Carrier）を利用するユーザ端末と通信する無線基地局であって、
所定のインデックスを含むＢＳＲ  ＭＡＣ  ＣＥ（Buffer  Status  Report  Medium  Access  Control  Control  Element）を受信する受信部と、
蓄積される上りデータの量（バッファサイズ）とインデックスとを関連付けたＢＳＲテーブルに基づいて、前記所定のインデックスを用いて前記ユーザ端末のバッファサイズを判断する制御部と、を有し、
前記ＢＳＲテーブルの１つは、当該ユーザ端末が５個より多いＣＣを設定された場合に用いる第１のＢＳＲテーブルであることを特徴とする無線基地局。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、次世代移動通信システムにおけるユーザ端末、無線基地局、無線通信方法及び無線通信システムに関する。
【背景技術】
【０００２】
ＵＭＴＳ（Universal  Mobile  Telecommunications  System）ネットワークにおいて、さらなる高速データレート、低遅延などを目的としてロングタームエボリューション（ＬＴＥ：Long  Term  Evolution）が仕様化された（非特許文献１）。また、ＬＴＥからの更なる広帯域化及び高速化を目的として、ＬＴＥの後継システム（例えば、ＬＴＥ−Ａ（LTE-Advanced）、ＦＲＡ（Future  Radio  Access）などと呼ばれる）も検討されている。【０００３】
ＬＴＥ−Ａ（ＬＴＥ  Ｒｅｌ．１０〜１２）の広帯域化技術の１つは、キャリアアグリゲーション（ＣＡ：Carrier  Aggregation）である。ＣＡによれば、複数の基本周波数ブロックを一体として通信に用いることができる。ＣＡにおける基本周波数ブロックは、コンポーネントキャリア（ＣＣ：Component  Carrier）と呼ばれ、ＬＴＥ  Ｒｅｌ．８のシステム帯域に相当する。【０００４】
また、ＬＴＥ／ＬＴＥ−Ａでは、ユーザ端末（ＵＥ）は送信すべき上りデータが発生した場合に、当該上りデータのバッファ量（バッファサイズ）を示すバッファ状態報告（ＢＳＲ：Buffer  Status  Report）を、ネットワーク側の装置（例えば、無線基地局（ｅＮＢ））に対して通知する。無線基地局は、ＢＳＲに基づいて上り無線リソースの割り当てを適切に制御することができる。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】3GPP  TS  36.300  “Evolved  Universal  Terrestrial  Radio  Access  (E-UTRA)  and  Evolved  Universal  Terrestrial  Radio  Access  Network  (E-UTRAN);  Overall  description;  Stage  2”
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ＬＴＥ  Ｒｅｌ．１０〜１２におけるＣＡでは、ユーザ端末あたりの設定可能なＣＣ数が最大５個に制限されている。一方、ＬＴＥ  Ｒｅｌ．１３以降では、より柔軟かつ高速な無線通信を実現するために、ユーザ端末に設定可能なＣＣ数の制限を緩和し、６個以上のＣＣ（５個を超えるＣＣ）を設定することが検討されている。ここで、設定可能なＣＣ数が６個以上であるキャリアアグリゲーションは、例えば、拡張ＣＡ（enhanced  ＣＡ）、Ｒｅｌ．１３  ＣＡなどと呼ばれてもよい。【０００７】
しかしながら、ユーザ端末に設定可能なＣＣ数が６個以上（例えば、３２個）に拡張される場合、既存システム（Ｒｅｌ．１０〜１２）におけるＢＳＲをそのまま利用することが困難となる。例えば、既存システムでは、ＢＳＲで示されるバッファサイズは５ＣＣ以下のＣＡを前提としているため、６ＣＣ以上のＣＡを適用する場合、バッファサイズを適切に示すことができない場合がある。このため、無線基地局がユーザ端末の上り無線リソースの割り当てを適切に制御することができず、拡張ＣＡによるスループット向上効果が好適に達成されなくなるおそれがある。【０００８】
本発明はかかる点に鑑みてなされたものであり、ユーザ端末に設定可能なコンポーネントキャリア数が既存システムより拡張される場合であっても、通信を適切に行うことができるユーザ端末及び無線基地局を提供することを目的とする。
【課題を解決するための手段】
【０００９】
本発明の一態様に係るユーザ端末は、複数のコンポーネントキャリア（ＣＣ：Component  Carrier）を利用して通信するユーザ端末であって、上りデータを蓄積するデータバッファリング部と、蓄積される上りデータの量（バッファサイズ）とインデックスとを関連付けたＢＳＲ（Buffer  Status  Report）テーブルに基づいて、前記バッファサイズに対応する所定のインデックスを含むＢＳＲ  ＭＡＣ  ＣＥ（Medium  Access  Control  Control  Element）を生成する生成部と、前記ＢＳＲ  ＭＡＣ  ＣＥを送信する送信部と、を有し、前記ＢＳＲテーブルの１つは、当該ユーザ端末が５個より多いＣＣを設定された場合に用いる第１のＢＳＲテーブルであることを特徴とする。
【発明の効果】
【００１０】
本発明によれば、ユーザ端末に設定可能なコンポーネントキャリア数が既存システムより拡張される場合であっても、通信を適切に行うことができる。
【図面の簡単な説明】
【００１１】
【図１】既存のＬＴＥシステムにおけるＢＳＲ  ＭＡＣ  ＣＥの構成を示す図である。
【図２】既存のＬＴＥシステムにおける上り共有チャネルに用いられるＬＣＩＤ値の一例を示す図である。
【図３】既存のＬＴＥシステムにおけるＢＳＲテーブルを示す図である。
【図４】Ｒｅｌ．１３  ＣＡの一例を示す図である。
【図５】第１の実施形態の方法１に係るＢＳＲテーブルの一例を示す図である。
【図６】第１の実施形態の方法２に係るＢＳＲテーブルの一例を示す図である。
【図７】第１の実施形態の方法２に係るＢＳＲ  ＭＡＣ  ＣＥの構成の一例を示す図である。
【図８】第１の実施形態の方法３に係るＢＳＲテーブルの一例を示す図である。
【図９】第１の実施形態の方法３に係るＭＡＣ  ＰＤＵの一例を示す図である。
【図１０】第１の実施形態の変形例における上り共有チャネルに用いられるＬＣＩＤ値の一例を示す図である。
【図１１】第２の実施形態に係るＢＳＲ  ＭＡＣ  ＣＥの構成の一例を示す図である。
【図１２】第２の実施形態で実現されるＬＣＧ構成の一例を示す図である。
【図１３】本発明の一実施形態に係る無線通信システムの概略構成の一例を示す図である。
【図１４】本発明の一実施形態に係る無線基地局の全体構成の一例を示す図である。
【図１５】本発明の一実施形態に係る無線基地局の機能構成の一例を示す図である。
【図１６】本発明の一実施形態に係るユーザ端末の全体構成の一例を示す図である。
【図１７】本発明の一実施形態に係るユーザ端末の機能構成の一例を示す図である。
【発明を実施するための形態】
【００１２】
まず、既存のＬＴＥシステム（Ｒｅｌ．１０〜１２）におけるＢＳＲについて説明する。
【００１３】
ＢＳＲで報告されるバッファサイズは、データが存在する論理チャネルグループ（ＬＣＧ：Logical  Channel  Group）毎に算出される。各ＬＣＧは、１つ以上の論理チャネル（ＬＣＨ：Logical  Channel）で構成され、最大ＬＣＧ数は４である。なお、ＬＣＨとＬＣＧとの対応関係に関する情報は、上位レイヤシグナリング（例えば、ＲＲＣ（Radio  Resource  Control）シグナリング、報知信号（例えば、ＭＩＢ（Master  Information  Block）、ＳＩＢ（System  Information  Block）））などにより、ユーザ端末に通知されてもよい。
【００１４】
ＢＳＲは、ＰＵＳＣＨ（Physical  Uplink  Shared  Channel）を用いてＭＡＣ（Medium  Access  Control）シグナリングにより送信される。例えば、ユーザ端末は、ＬＣＧに属するいずれかのＬＣＨに送信可能なデータがあり、所定のタイマが満了した場合などに、ＢＳＲを送信する。ＢＳＲは、ＭＡＣ  ＰＤＵ（Protocol  Data  Unit）に含まれるＢＳＲ  ＭＡＣ  ＣＥ（Control  Element）により構成される。
【００１５】
図１は、既存のＬＴＥシステムにおけるＢＳＲ  ＭＡＣ  ＣＥの構成を示す図である。図１に示すように、Ｒｅｌ．１０〜１２では、１つのＬＣＧ（ＬＣＧ  ＩＤフィールドで特定）のバッファサイズに関する情報を含むＢＳＲ（Short  BSR/Truncated  BSR）と、全てのＬＣＧ（ＬＣＧ  ＩＤ  ＃０〜＃３に対応）のバッファサイズに関する情報を含むＢＳＲ（Long  BSR）と、が規定されている。
【００１６】
また、ＭＡＣ  ＰＤＵのＭＡＣヘッダに含むＬＣＩＤ（Logical  Channel  Identifier）には、各ＢＳＲ  ＭＡＣ  ＣＥに対応した値が規定されている。図２は、既存のＬＴＥシステムにおける上り共有チャネルに用いられるＬＣＩＤ値の一例を示す図である。図２において、インデックス「１１１００」、「１１１０１」、「１１１１０」が、それぞれ異なるＢＳＲ  ＭＡＣ  ＣＥに対応している。
【００１７】
図１に示したバッファサイズ（ＢＳ：Buffer  Size）フィールドは、６ビットのインデックスであり、当該インデックスとバッファサイズとの対応関係（ＢＳＲテーブル、ＢＳテーブルなどともいう）が規定されている。図３は、既存のＬＴＥシステムにおけるＢＳＲテーブルを示す図である。図３のＢＳＲテーブルは、Ｒｅｌ．１０で規定されるテーブルである。なお、図３のバッファサイズは拡張バッファサイズと呼ばれてもよい。
【００１８】
ＢＳＲテーブルにおいて、インデックス「００００００」及び「１１１１１１」はそれぞれバッファが空であること及び最大であることを示している。バッファサイズの最大値Ｂｍａｘは、最大の上りトランスポートブロックサイズ（ＴＢＳ）、ＲＴＴ（Round  Trip  Time）の応答時間、ＣＣ数、上りＭＩＭＯ（Multi-Input  Multi-Output）などに基づいて算出される。
【００１９】
例えば、Ｒｅｌ．１０の場合、最大の上りＴＢＳは１４９７７６ビット、２ＲＴＴの応答時間は１６ＴＴＩ（Transmission  Time  Interval）、最大ＣＣ数は５、上りＭＩＭＯは最大２レイヤであることから、最大バッファサイズとして、（１４９７７６＊１６＊５＊２）／８＝２９９５５２０バイトが必要であると求められる。したがって、図３に示すように、Ｒｅｌ．１０のＢＳＲテーブルでは、２９９５５２０バイトを超える３ＭＢ（３００００００バイト）がＢｍａｘとして規定されている。
【００２０】
また、ＢＳＲテーブルにおいて、ＢＳレベルｋに対応するバッファサイズＢｋは、以下の式１で導出される。なお、ｋは（インデックス−１）に相当する。
【００２１】
【数１】
2016182048.tif 000003
【００２２】
ところで、ＬＴＥ  Ｒｅｌ．１３では、６個以上のＣＣ（５個を超えるＣＣ）を設定するＣＡ（拡張ＣＡ、Ｒｅｌ．１３  ＣＡ）が検討されている。例えば、Ｒｅｌ．１３  ＣＡでは、最大３２個までのＣＣを束ねることが検討されている。
【００２３】
このような多数のＣＣを用いるＲｅｌ．１３  ＣＡは、同じくＲｅｌ．１３で検討されているＬＡＡ（Licensed-Assisted  Access）の動作に密接に関連することが想定される。ＬＡＡは、ライセンスバンドＬＴＥ（Licensed  LTE）との連携を前提とした、ライセンス不要の周波数帯域（アンライセンスバンド（Unlicensed  band））を利用するＬＴＥシステムの一形態（ＬＴＥ−Ｕ：LTE  Unlicensed）である。
【００２４】
ライセンスバンドは、特定の事業者が独占的に使用することを許可された帯域である一方、アンライセンスバンドは、特定事業者に限定せずに無線局を設置可能な帯域である。アンライセンスバンドとしては、例えば、Ｗｉ−ＦｉやＢｌｕｅｔｏｏｔｈ（登録商標）を使用可能な２．４ＧＨｚ帯や５ＧＨｚ帯、ミリ波レーダーを使用可能な６０ＧＨｚ帯などの利用が検討されている。
【００２５】
また、ＬＡＡシステムの上り送信については、ベアラ／論理チャネルごとに、ＬＡＡのＳＣｅｌｌ（Secondary  Cell）にオフロードするか又はライセンスキャリアによってのみサービスされるかを設定することが検討されている。
【００２６】
図４は、Ｒｅｌ．１３  ＣＡの一例を示す図である。図４には、ＬＡＡのライセンスＣＣを既存システムの最大ＣＣ数である５ＣＣで構成し、アンライセンスＣＣを２７ＣＣで構成した計３２ＣＣのＣＡが示されている。Ｒｅｌ．１３  ＣＡを用いることにより、通信スループットの更なる向上が期待されている。
【００２７】
しかしながら、上述のように、既存システム（Ｒｅｌ．１０〜１２）のＢＳＲは５ＣＣ以下のＣＡを前提としているため、６ＣＣ以上のＣＡを適用する場合、大きなバッファサイズを適切に示すことができず、拡張ＣＡによるスループット向上効果が好適に達成されないおそれがある。
【００２８】
そこで、本発明者らは、ＬＴＥ  Ｒｅｌ．１３以降において、６個以上のＣＣ（例えば、３２個のＣＣ）を用いるＣＡに適したＢＳＲ報告を可能とするために、既存システムと異なるＢＳＲテーブルやＢＳＲ  ＭＡＣ  ＣＥ及び／又はＭＡＣヘッダの構成を導入することを着想した。
【００２９】
以下、本発明に係る実施形態について説明する。各実施形態では、ユーザ端末が最大３２ＣＣを用いるＣＡを設定される場合の例について説明するが、本発明の適用はこれに限られるものではない。例えば、５個以下のＣＣを用いるＣＡを設定される場合であっても、各実施形態で説明するＢＳＲを用いることができる。
【００３０】
また、各実施形態では、Ｒｅｌ．１０と同様の計算方法に基づいて、最大３２ＣＣを想定してＲｅｌ．１３のバッファサイズの最大値Ｂｍａｘを決定する。つまり、各実施形態では、Ｂｍａｘ＝２０ＭＢ（≒（１４９７７６＊１６＊３２＊２）／８）として説明するが、これに限られず、Ｒｅｌ．１３  ＣＡを好適に行うことができる値であればＢｍａｘは他の値でもよい。
【００３１】
（第１の実施形態：Ｒｅｌ．１３  ＣＡ向けＢＳＲテーブル）
本発明の第１の実施形態では、Ｒｅｌ．１３  ＣＡ向けの新たなＢＳＲテーブルを規定して用いる。当該テーブルは、例えばユーザ端末が５個より多いＣＣを設定された場合において、ＢＳＲの生成の際に参照される。また、５個以内のＣＣであっても、Ｒｅｌ．１２  ＣＡまででは対応していないＣＣ数に対して、当該新たなＢＳＲテーブルが用いられるものとしてもよい。例えば、ＰＣｅｌｌ（Primary  Cell）がＴＤＤ（Time  Division  Duplex）を設定され、かつそのＤＬ：ＵＬリソース比率が９：１となるＵＬ−ＤＬ  ｃｏｎｆｉｇｕｒａｔｉｏｎの場合、Ｒｅｌ．１２  ＣＡまでではＣＣ数が最大２個しか対応できない。したがって、このようなケースでは、ＣＣ数が３個以上の任意のＣＡで、当該新たなＢＳＲテーブルが用いられる。
【００３２】
＜方法１＞
第１の実施形態の方法１では、インデックス（ＢＳフィールド）を既存システムと同様の６ビットのままとする一方、ＢＳＲテーブルの各バッファサイズをより大きな値としてＲｅｌ．１３のＢｍａｘまでの値を表すように構成する。各バッファサイズは、例えば式１を用いて算出してもよい。図５は、第１の実施形態の方法１に係るＢＳＲテーブルの一例を示す図である。表現されるバッファサイズの粒度（ステップサイズ）は、図５の場合約２１％となる。
【００３３】
つまり、方法１では、ステップサイズをＬＴＥ  Ｒｅｌ．１０のＢＳＲテーブルより大きくすることで、既存のＢＳＲテーブルと同じインデックスサイズ（６ビット）を実現している。なお、ステップサイズとは、上述したように、ＢＳＲテーブルにおいて、インデックスの増加に伴うバッファサイズの増加率に相当する。
【００３４】
図３及び図５のいずれのテーブルを用いるかに関する情報（Ｒｅｌ．１３  ＣＡ向けのＢＳＲテーブルを用いるか否かに関する情報）は、ユーザ端末に上位レイヤシグナリング（例えば、ＲＲＣシグナリング）、ＤＣＩなどで通知されてもよい。また、ユーザ端末は、Ｒｅｌ．１３  ＣＡ（例えば、５ＣＣより多いＣＣのＣＡ）を設定された場合、図５のテーブルを用いることを暗黙的に決定する構成としてもよい。
【００３５】
方法１においては、既存システムと同じＬＣＩＤを用いて、各ＬＣＧのバッファサイズを報告することができる。また、ＢＳフィールドのサイズも既存システムと同じ６ビットであるため、ＢＳＲ  ＭＡＣ  ＣＥは、図１に示した構成とすることができる。つまり、ＢＳＲ  ＭＡＣ  ＣＥを、ＬＴＥ  Ｒｅｌ．１０のＢＳＲ  ＭＡＣ  ＣＥと同じ構成（同じサイズ）とすることができる。
【００３６】
以上述べたように、方法１では、バッファサイズを増加させた新たなＢＳＲテーブルを導入すればよく、ＭＡＣ  ＰＤＵを変更する必要がないため、既存システムとの互換性を維持したままＲｅｌ．１３  ＣＡのバッファサイズに対応することができる。
【００３７】
＜方法２＞
第１の実施形態の方法２では、インデックス（ＢＳフィールド）のビット数を既存システムより増加させる。具体的には、ＢＳフィールドのビット数をＸ（Ｘ＞６）とすることでＢＳＲテーブルを拡張し、Ｒｅｌ．１３のＢｍａｘまでの値を表せるように構成する。各バッファサイズは、例えば式１を用いて算出してもよい。
【００３８】
図６は、第１の実施形態の方法２に係るＢＳＲテーブルの一例を示す図である。図６では、Ｘ＝７とした例が示されている。ここで、図６では、式１におけるＮは１２６であり、Ｒｅｌ．１０までと同様に、Ｎ＝２Ｘ−２で算出されている。表現されるバッファサイズの粒度は、図６の場合約１１％となる。
【００３９】
つまり、方法２では、インデックスがＸビット（Ｘ＞６）で構成され、ステップサイズをＬＴＥ  Ｒｅｌ．１０のＢＳＲテーブル以下（又は未満）とすることで、より細やかなＢＳＲ報告を可能としている。
【００４０】
図３及び図６のいずれのテーブルを用いるかに関する情報（Ｒｅｌ．１３  ＣＡ向けのＢＳＲテーブルを用いるか否かに関する情報）は、ユーザ端末に上位レイヤシグナリング（例えば、ＲＲＣシグナリング）、ＤＣＩなどで通知されてもよい。また、ユーザ端末は、Ｒｅｌ．１３  ＣＡ（例えば、６ＣＣ以上のＣＡ）を設定された場合、図６のテーブルを用いることを暗黙的に決定する構成としてもよい。
【００４１】
方法２においては、既存システムと同じＬＣＩＤを用いて、各ＬＣＧのバッファサイズを報告することができる。一方、ＢＳフィールドのサイズが既存システムより大きいため、ＢＳＲ  ＭＡＣ  ＣＥの構成を変更することが必要となる。ユーザ端末は、インデックス数が増加したテーブル（例えば、図６）を用いることを判断した場合、以下のようなＢＳＲ  ＭＡＣ  ＣＥを用いる。
【００４２】
図７は、第１の実施形態の方法２に係るＢＳＲ  ＭＡＣ  ＣＥの構成の一例を示す図である。図７では、Ｘ＝７とした例が示されている。この場合、１ＬＣＧに対応するＢＳＲ（Short  BSR/Truncated  BSR）は最低でも９ビット、全てのＬＣＧに対応するＢＳＲ（Long  BSR）は最低でも２８ビットを要する。ただし、ＭＡＣ  ＣＥはオクテット（バイト）単位で構成する必要があるため、本例では前者は２オクテット、後者は４オクテットで構成されている。
【００４３】
なお、「Ｒ」は予約ビットを示しており、特に情報の通知に利用されなくてもよいし、自由に利用されてもよい。規格上、所定の値（例えば０）に固定されていてもよい。所定の値に固定されている場合、誤り訂正復号の段階で、当該ビットを仮想的な誤り判定ビットとして考慮することが可能である（すなわち、当該ビットが所定の値になっていなかった場合、当該ＭＡＣ  ＣＥ全体を誤りと判断し、再送要求を行うことができる）。
【００４４】
このように、方法２では、ＢＳＲ  ＭＡＣ  ＣＥを、ＬＴＥ  Ｒｅｌ．１０のＢＳＲ  ＭＡＣ  ＣＥと異なる構成（大きなサイズ）とする。
【００４５】
なお、方法１及び２では、５個より多いＣＣのＣＡを設定可能な端末能力情報（ＵＥ  ｃａｐａｂｉｌｉｔｙ）とは別に、新規ＢＳＲを設定できる（新たなＢＳＲテーブルを用いることができる）ことを示す端末能力情報（ＵＥ  ｃａｐａｂｉｌｉｔｙ）を規定し、予め端末が基地局に上位レイヤシグナリングなどで報告するものとしてもよい。当該端末能力情報の利用法について、以下で説明する。
【００４６】
Ｒｅｌ．１３  ＣＡにおいて、多数のＣＣを設定する動機として、端末スループットを大幅に高めることのほか、多数の周波数キャリアの中で、実際にスケジューリングするキャリアを動的に切り替えられるようにし、干渉や周波数の混み具合に応じて利用するキャリアを柔軟に変更する、という利用法が検討されている。前者の動機を達成するためには、多数のＣＣを設定し、それらに同時にスケジューリングすることが必須であるから、新規ＢＳＲテーブルを利用することが必要となる。一方で、後者の動機は、多くのＣＣに同時にスケジューリングを行わなくても達成できる。
【００４７】
したがって、新規ＢＳＲを設定できることを示す端末能力情報（ＵＥ  ｃａｐａｂｉｌｉｔｙ）を導入することにより、新規ＢＳＲは実装していないが多数のＣＣによるＵＬ−ＣＡは実装している端末実装を、基地局側で認識できるようになる。換言すれば、端末に対し、新規ＢＳＲを必要とする高い端末スループット達成の実装を省き、後者の動機を達成する目的でのみＵＬ−ＣＡを実装することができるようになるため、より簡易な実装で多数のＣＣを設定するＵＬ−ＣＡを実装し、後者の動機を達成できるようになる。
【００４８】
このため、無線基地局は、新規ＢＳＲを設定できることを示す端末能力情報を通知してきたユーザ端末に対して、新規ＢＳＲを設定（又は新たなＢＳＲテーブルを用いるか否かに関する情報を通知）する構成としてもよい。例えば、５個より多いＣＣのＣＡを設定可能な端末能力情報と、新規ＢＳＲを設定できることを示す端末能力情報と、を両方通知してきたユーザ端末に対して、新規ＢＳＲを設定する。
【００４９】
また、方法１及び２において、ＵＥは、どちらのＢＳＲテーブルを用いるかを、活性化されている（すなわちＡｃｔｉｖｅ化された）ＣＣの数に応じて選択してもよい。ＰＣｅｌｌまたはＰＳＣｅｌｌ（Primary  Secondary  Cell）を除くＳＣｅｌｌは、タイマまたは基地局からのシグナリングに応じて非活性化（すなわちＤｅ−ａｃｔｉｖｅ化）される。ＡｃｔｉｖｅなＣＣが５以下の場合、新規ＢＳＲテーブルを用いる必要は無い。したがって、ＵＥはＡｃｔｉｖｅなＣＣ数に応じて、ＢＳＲの計算に用いるテーブルを選択するようにすることができる。
【００５０】
これにより、方法１においては、ＡｃｔｉｖｅなＣＣ数が多い場合には、新たなＢＳＲテーブルを用いることで、ステップサイズは大きくなるが最大バッファサイズを拡大することができ、ＡｃｔｉｖｅなＣＣ数が少ない場合には冗長な最大バッファサイズを取らず、ステップサイズを細かくとるようにすることができる。
【００５１】
また、方法２においては、ＡｃｔｉｖｅなＣＣ数が多い場合には、新たなＢＳＲテーブルを用いることで、ＭＡＣ  ＣＥのサイズを増やして最大バッファサイズを拡大することができ、ＡｃｔｉｖｅなＣＣ数が少ない場合には冗長な最大バッファサイズを取らず、ＭＡＣ  ＣＥのオーバーヘッドを減らすようにすることができる。
【００５２】
以上述べたように、方法２では、ＢＳフィールドを拡張することにより、ステップサイズの増大を抑制しつつ、Ｒｅｌ．１３  ＣＡのバッファサイズに対応することができる。
【００５３】
＜方法３＞
第１の実施形態の方法３では、複数のテーブルを切り替えて用いることで、ＢＳＲテーブルを拡張し、Ｒｅｌ．１３のＢｍａｘまでの値を表せるように構成する。複数のテーブルのうち、１つのテーブルは他のテーブルの最大バッファサイズより大きなバッファサイズに関する情報を含む。
【００５４】
複数のテーブルの１つとしては、既存システム（例えば、Ｒｅｌ．１０）のＢＳＲテーブルを用いることができる。この場合、別のテーブルとしてＲｅｌ．１０のＢｍａｘより大きくＲｅｌ．１３のＢｍａｘまでのＢＳを表すテーブルを規定する。
【００５５】
図８は、第１の実施形態の方法３に係るＢＳＲテーブルの一例を示す図である。本例では、図８Ａ及び図８Ｂのテーブルを切り替えて用いる。図８Ａのテーブルは、図３で示したＲｅｌ．１０のテーブルであり、３ＭＢ以下のバッファサイズを表すために用いる。一方、図８Ｂのテーブルは、図８Ａの最大バッファサイズである３ＭＢ（３０００ＫＢ）超かつＲｅｌ．１３の最大バッファサイズである２０ＭＢ以下のバッファサイズを表すために用いる。図８Ｂのテーブルにおいて、各バッファサイズは、例えば式２を用いて算出してもよい。
【００５６】
【数２】
2016182048.tif 000004
【００５７】
図８Ｂのテーブルについては、全てのインデックスに、それぞれ対応するバッファサイズを規定する必要はない。つまり、Ｎは２Ｘ−２に限られない。図８Ｂの場合、Ｎ＝１７である。表現されるバッファサイズの粒度は、図８Ｂの場合約１１％となる。なお、式２におけるｋは（インデックス＋１）としているが、これに限られない。
【００５８】
一部のインデックスは、更なる拡張用途に用いるために「予約」と設定されてもよい。「予約」のバッファサイズ値は、例えば上位レイヤシグナリングによって設定可能に構成されてもよい。図８Ｂでは、１７以上のインデックス値は予約と規定されている。
【００５９】
図８Ａ及び図８Ｂのいずれのテーブルを用いるかに関する情報（Ｒｅｌ．１３  ＣＡ向けのＢＳＲテーブルを用いるか否かに関する情報）は、ユーザ端末に上位レイヤシグナリング（例えば、ＲＲＣシグナリング）、ＤＣＩなどで通知されてもよい。また、ユーザ端末は、Ｒｅｌ．１３  ＣＡ（例えば、６ＣＣ以上のＣＡ）を設定された場合、図８Ｂのテーブルを用いることを暗黙的に決定する構成としてもよい。
【００６０】
また、ユーザ端末は、通知の有無によらず、図８Ａ及び図８Ｂのいずれのテーブルを用いるかを、動的に変更できる構成としてもよい。この場合、ＢＳＲ  ＭＡＣ  ＣＥに対応するＭＡＣ  ＰＤＵサブヘッダに、当該ＢＳＲ  ＭＡＣ  ＣＥの生成に用いたＢＳＲテーブルを特定する情報（特定情報）を含めて無線基地局に通知する。
【００６１】
例えば、ＢＳＲ  ＭＡＣ  ＣＥの種類を既存システムと同じＬＣＩＤを用いて表す場合、ＢＳＲテーブルを特定する情報は、ＭＡＣ  ＰＤＵサブヘッダのＲフィールドに含める。図９は、第１の実施形態の方法３に係るＭＡＣ  ＰＤＵの一例を示す図である。なお、図９においてＭＡＣ  ＰＤＵサブヘッダに含まれる「Ｅ」、「Ｆ」、「Ｌ」などのフィールドは、既存システムの各フィールドと同じであってもよい。また、ＭＡＣ  ＰＤＵサブヘッダの構成はこれに限られない。
【００６２】
図９においては、ＭＡＣ  ＰＤＵサブヘッダの１つにより、ＭＡＣ  ＣＥ  ２がＳｈｏｒｔ  ＢＳＲであること（ＬＣＩＤ＝１１１０１）が示されている。また、当該サブヘッダの最初のＲフィールドで、ＭＡＣ  ＣＥ  ２で利用するＢＳＲテーブルが特定されている。本例では、当該Ｒフィールドが‘０’の場合、図８Ａに示したＲｅｌ．１０のテーブルを示し、‘１’の場合、図８Ｂに示した３ＭＢ超を規定したテーブルを示す。
【００６３】
なお、ＭＡＣ  ＰＤＵに複数のＢＳＲ  ＭＡＣ  ＣＥを含む場合、各ＢＳＲ  ＭＡＣ  ＣＥで用いるテーブルは同じであってもよいし、異なっていてもよい。
【００６４】
以上述べたように、方法３では、複数のＢＳＲテーブルを用いることにより、既存システムとの互換性の維持と、通知できるバッファサイズの高粒度化を両立しつつ、Ｒｅｌ．１３  ＣＡのバッファサイズに対応することができる。
【００６５】
以上、第１の実施形態によれば、５ＣＣより多いＣＣのＣＡを適用する場合であっても、大きなバッファサイズに対応したＢＳＲを無線基地局に通知することができる。
【００６６】
＜変形例＞
なお、第１の実施形態に示した例は一例に過ぎず、ＢＳＲテーブルの構成、ＭＡＣ  ＰＤＵの構成などはこれに限られない。上記例では、Ｒｅｌ．１３のＢｍａｘを２０ＭＢ（最大３２ＣＣまで対応）としたが、当該値はユーザ端末に設定される最大のＣＣ数に基づいて算出されればよく、他の値であってもよい。Ｒｅｌ．１３向けの新たなＢＳＲテーブルでは、例えば、最大８ＣＣ、１２ＣＣ、１６ＣＣ、２０ＣＣ、２４ＣＣ、２８ＣＣまで設定可能なユーザ端末に対し、それぞれＢｍａｘを５ＭＢ、８ＭＢ、１０ＭＢ、１２ＭＢ、１５ＭＢ、１７ＭＢなどに設定できるようにしてもよい。また、Ｂｍａｘ＝４０ＭＢ（例えば、最大６４ＣＣ）まで、Ｂｍａｘ＝８０ＭＢまでなどのバッファサイズを特定することができるように、バッファサイズ及びインデックスが関連付けられてもよい。
【００６７】
図８では２つのＢＳＲテーブルを切り替えて用いる場合を示したが、テーブルの数は３以上であってもよい。また、この場合、ＢＳＲテーブルは、ＭＡＣ  ＰＤＵサブヘッダの複数のＲフィールドを用いて特定されてもよい。つまり、特定情報は３つ以上のＢＳＲテーブルのいずれかを特定する情報であってもよい。
【００６８】
また、図８では、２つのＢＳＲテーブルのインデックスサイズは同じ６ビットとしたが、これに限られない。例えば、図８Ｂに示した３ＭＢ超を規定したテーブルは、方法２で示したように、６ビットより大きいインデックスを用いる構成としてもよい。
【００６９】
また、ＢＳＲテーブルは、Ｒフィールドではなく既存システム（Ｒｅｌ．１０〜１２）で利用されていないＬＣＩＤが指定されることにより特定されてもよい。つまり、ＭＡＣ  ＰＤＵがＭＡＣヘッダに所定のＬＣＩＤを含むことで、当該ＭＡＣ  ＰＤＵが第１の実施形態におけるＢＳＲ  ＭＡＣ  ＣＥを含むことを示してもよい。
【００７０】
図１０は、第１の実施形態の変形例における上り共有チャネルに用いられるＬＣＩＤ値の一例を示す図である。図１０において、インデックス「１０１０１」、「１０１１０」、「１０１１１」が、上述の方法３で示した３ＭＢ（３０００ＫＢ）超のＢＳＲを指定できるＢＳＲ  ＭＡＣ  ＣＥに対応している。なお、これらのＢＳＲ  ＭＡＣ  ＣＥを示すＬＣＩＤは、図１０の構成に限られず、例えば別のインデックスに割り当てられてもよい。
【００７１】
また、無線基地局及び／又はユーザ端末に、ＢＳＲテーブルの構成情報が通知されてもよい。例えば、ＢＳＲテーブルの構成情報は、所定のインデックスに対応するバッファサイズを規定する情報を含んでもよく、無線基地局及び／又はユーザ端末は、当該構成情報に基づいて所定のＢＳＲテーブルに含まれる情報を更新してもよい。
【００７２】
また、方法３におけるユーザ端末も、新規ＢＳＲを設定できることを示す端末能力情報を無線基地局に通知してもよい。この場合、無線基地局及び／又はユーザ端末は、方法１及び２について上述したような制御（設定、選択、通知など）を行う構成としてもよいし、別の制御を行ってもよい。また、各方法におけるＲｅｌ．１３  ＣＡ向けのＢＳＲテーブルを用いるか否かに関する情報は、テーブル切り替え情報、バッファサイズ切り替え情報などと呼ばれてもよい。
【００７３】
（第２の実施形態：ＬＣＧ数の拡張）
本発明者らは、Ｒｅｌ．１３  ＣＡ向けのＢＳＲ構成を検討するなかで、ＬＡＡのライセンスキャリア／アンライセンスキャリアのように異なる特性を有するベアラをサポートするには、現状の最大ＬＣＧ数（＝４）は不十分なおそれがあることを発見した。例えば、図４のように多数のＣＣが設定される場合、ＬＣＧ数４の環境では、品質の良いキャリアと悪いキャリアが同じＬＣＧで構成されてしまい、スループットが劣化することが考えられる。
【００７４】
そこで、本発明者らは、ＬＣＧ数を４より大きくすることを検討し、本発明の第２の実施形態を見出した。第２の実施形態では、設定可能なＬＣＧ数を既存システムに比べて増加させる。具体的には、最大ＬＣＧ数をＹ（Ｙ＞４）とし、４つより多いＬＣＧに対応したＢＳＲを表せるように構成する。
【００７５】
第２の実施形態では、ＢＳＲ  ＭＡＣ  ＣＥのＬＣＧ  ＩＤフィールドのサイズが既存システムより大きくなるか、又はＢＳフィールドの数が既存システムより増えるため、ＢＳＲ  ＭＡＣ  ＣＥの構成を変更することが必要となる。ユーザ端末は、４より大きいＬＣＧ数を用いることを判断した場合、以下のようなＢＳＲ  ＭＡＣ  ＣＥを用いる。
【００７６】
図１１は、第２の実施形態に係るＢＳＲ  ＭＡＣ  ＣＥの構成の一例を示す図である。図１１では、Ｘ（ＢＳフィールドのサイズ）＝８とし、Ｙ（最大ＬＣＧ数）＝５とした例が示されている。この場合、１ＬＣＧに対応するＢＳＲ（Short  BSR/Truncated  BSR）は最低でも１１ビット、全てのＬＣＧ（ＬＣＧ  ＩＤ  ＃０〜＃４に対応）に対応するＢＳＲ（Long  BSR）は最低でも４０ビットを要する。ただし、ＭＡＣ  ＣＥはオクテット（バイト）単位で構成する必要があるため、本例では前者は２オクテット（図１１Ａ）、後者は５オクテット（図１１Ｂ）で構成されている。図１１Ａでは、ＬＣＧ  ＩＤフィールドは、Ｙ個のＬＣＧ  ＩＤを表すことができるビット数（３ビット）に拡張されている。
【００７７】
各ＬＣＧで利用するＢＳＲテーブルは、図３に示したようなＲｅｌ．１０のＢＳＲテーブルを用いてもよいし、第１の実施形態で示した各方法のＢＳＲテーブルを用いてもよい。
【００７８】
４より大きいＬＣＧ数を用いるか否かに関する情報は、ユーザ端末に上位レイヤシグナリング（例えば、ＲＲＣシグナリング）、ＤＣＩなどで通知されてもよい。また、ユーザ端末は、Ｒｅｌ．１３  ＣＡ（例えば、６ＣＣ以上のＣＡ）が設定された場合、アンライセンスバンドを含むＣＡが設定された場合、キャリアセンスが必要なＣＣを含むＣＡが設定された場合、４以上のＬＣＧとＬＣＨとの対応関係が設定された場合などに、４より大きいＬＣＧ数を用いることを暗黙的に決定する構成としてもよい。
【００７９】
図１２は、第２の実施形態で実現されるＬＣＧ構成の一例を示す図である。図１２では７つのＲＢ（Radio  Bearer）及び６つのＬＣＧが示されている。ＲＢ１〜５はライセンスキャリアであり、ＲＢ６及び７はアンライセンスキャリアである。本例では、ＲＢ１及び２は同様のＱＣＩ（QoS  Class  Identifier）が割り当てられているため、同じＬＣＧ（ＬＣＧ１）を構成している。また、他のＲＢはそれぞれ個別のＬＣＧを構成している。
【００８０】
本例では、既存システムの４つのＬＣＧに相当するＬＣＧ１〜４がライセンスキャリアに割り当てられ、新たに規定される２つのＬＣＧであるＬＣＧ５及び６がアンライセンスキャリアに割り当てられる。
【００８１】
このように、第２の実施形態によれば、ＬＣＧ数を４より大きくすることができるため、ＲＢ数が４より大きくても、ＲＢごとの細かな制御が可能となる。また、ライセンスキャリアとアンライセンスキャリアとを同じＬＣＧに設定する事態を低減することができ、スループットの低下を抑制することが可能となる。
【００８２】
なお、上記各実施形態に係る無線通信方法は、それぞれ単独で適用されてもよいし、組み合わせて適用されてもよい。例えば、第２の実施形態のように４より大きいＬＣＧ数を用いる場合に、各ＬＣＧについて第１の実施形態で規定したＲｅｌ．１３  ＣＡ向けＢＳＲテーブルに基づいてＢＳＲを通知する構成としてもよい。
【００８３】
（無線通信システム）
以下、本発明の一実施形態に係る無線通信システムの構成について説明する。この無線通信システムでは、本発明の上記各実施形態に係る無線通信方法が適用される。なお、上記各実施形態に係る無線通信方法は、それぞれ単独で適用されてもよいし、組み合わせて適用されてもよい。
【００８４】
図１３は、本発明の一実施形態に係る無線通信システムの概略構成の一例を示す図である。無線通信システム１では、ＬＴＥシステムのシステム帯域幅（例えば、２０ＭＨｚ）を１単位とする複数の基本周波数ブロック（コンポーネントキャリア）を一体としたキャリアアグリゲーション（ＣＡ）及び／又はデュアルコネクティビティ（ＤＣ）を適用することができる。なお、無線通信システム１は、ＳＵＰＥＲ  ３Ｇ、ＬＴＥ−Ａ（ＬＴＥ−Ａｄｖａｎｃｅｄ）、ＩＭＴ−Ａｄｖａｎｃｅｄ、４Ｇ、５Ｇ、ＦＲＡ（Future  Radio  Access）などと呼ばれても良い。
【００８５】
図１３に示す無線通信システム１は、マクロセルＣ１を形成する無線基地局１１と、マクロセルＣ１内に配置され、マクロセルＣ１よりも狭いスモールセルＣ２を形成する無線基地局１２（１２ａ〜１２ｃ）と、を備えている。また、マクロセルＣ１及び各スモールセルＣ２には、ユーザ端末２０が配置されている。
【００８６】
ユーザ端末２０は、無線基地局１１及び無線基地局１２の双方に接続することができる。ユーザ端末２０は、マクロセルＣ１及びスモールセルＣ２を、ＣＡ又はＤＣにより同時に使用することが想定される。また、ユーザ端末２０は、複数のセル（ＣＣ）（例えば、６個以上のＣＣ）を用いてＣＡ又はＤＣを適用することができる。
【００８７】
ユーザ端末２０と無線基地局１１との間は、相対的に低い周波数帯域（例えば、２ＧＨｚ）で帯域幅が狭いキャリア（既存キャリア、Legacy  carrierなどと呼ばれる）を用いて通信を行うことができる。一方、ユーザ端末２０と無線基地局１２との間は、相対的に高い周波数帯域（例えば、３．５ＧＨｚ、５ＧＨｚなど）で帯域幅が広いキャリアが用いられてもよいし、無線基地局１１との間と同じキャリアが用いられてもよい。なお、各無線基地局が利用する周波数帯域の構成はこれに限られない。
【００８８】
無線基地局１１と無線基地局１２との間（又は、２つの無線基地局１２間）は、有線接続（例えば、ＣＰＲＩ（Common  Public  Radio  Interface）に準拠した光ファイバ、Ｘ２インターフェースなど）又は無線接続する構成とすることができる。
【００８９】
無線基地局１１及び各無線基地局１２は、それぞれ上位局装置３０に接続され、上位局装置３０を介してコアネットワーク４０に接続される。なお、上位局装置３０には、例えば、アクセスゲートウェイ装置、無線ネットワークコントローラ（ＲＮＣ）、モビリティマネジメントエンティティ（ＭＭＥ）などが含まれるが、これに限定されるものではない。また、各無線基地局１２は、無線基地局１１を介して上位局装置３０に接続されてもよい。
【００９０】
なお、無線基地局１１は、相対的に広いカバレッジを有する無線基地局であり、マクロ基地局、集約ノード、ｅＮＢ（eNodeB）、送受信ポイント、などと呼ばれてもよい。また、無線基地局１２は、局所的なカバレッジを有する無線基地局であり、スモール基地局、マイクロ基地局、ピコ基地局、フェムト基地局、ＨｅＮＢ（Home  eNodeB）、ＲＲＨ（Remote  Radio  Head）、送受信ポイントなどと呼ばれてもよい。以下、無線基地局１１及び１２を区別しない場合は、無線基地局１０と総称する。
【００９１】
各ユーザ端末２０は、ＬＴＥ、ＬＴＥ−Ａなどの各種通信方式に対応した端末であり、移動通信端末だけでなく固定通信端末を含んでもよい。
【００９２】
無線通信システム１においては、無線アクセス方式として、下りリンクにＯＦＤＭＡ（直交周波数分割多元接続）が適用され、上りリンクにＳＣ−ＦＤＭＡ（シングルキャリア−周波数分割多元接続）が適用される。ＯＦＤＭＡは、周波数帯域を複数の狭い周波数帯域（サブキャリア）に分割し、各サブキャリアにデータをマッピングして通信を行うマルチキャリア伝送方式である。ＳＣ−ＦＤＭＡは、システム帯域幅を端末毎に１つ又は連続したリソースブロックからなる帯域に分割し、複数の端末が互いに異なる帯域を用いることで、端末間の干渉を低減するシングルキャリア伝送方式である。なお、上り及び下りの無線アクセス方式は、これらの組み合わせに限られない。
【００９３】
無線通信システム１では、下りリンクのチャネルとして、各ユーザ端末２０で共有される下り共有チャネル（ＰＤＳＣＨ：Physical  Downlink  Shared  Channel）、報知チャネル（ＰＢＣＨ：Physical  Broadcast  Channel）、下りＬ１／Ｌ２制御チャネルなどが用いられる。ＰＤＳＣＨにより、ユーザデータや上位レイヤ制御情報、ＳＩＢ（System  Information  Block）などが伝送される。また、ＰＢＣＨにより、ＭＩＢ（Master  Information  Block）が伝送される。
【００９４】
下りＬ１／Ｌ２制御チャネルは、ＰＤＣＣＨ（Physical  Downlink  Control  Channel）、ＥＰＤＣＣＨ（Enhanced  Physical  Downlink  Control  Channel）、ＰＣＦＩＣＨ（Physical  Control  Format  Indicator  Channel）、ＰＨＩＣＨ（Physical  Hybrid-ARQ  Indicator  Channel）などを含む。ＰＤＣＣＨにより、ＰＤＳＣＨ及びＰＵＳＣＨのスケジューリング情報を含む下り制御情報（ＤＣＩ：Downlink  Control  Information）などが伝送される。ＰＣＦＩＣＨにより、ＰＤＣＣＨに用いるＯＦＤＭシンボル数が伝送される。ＰＨＩＣＨにより、ＰＵＳＣＨに対するＨＡＲＱの送達確認信号（ＡＣＫ／ＮＡＣＫ）が伝送される。ＥＰＤＣＣＨは、ＰＤＳＣＨ（下り共有データチャネル）と周波数分割多重され、ＰＤＣＣＨと同様にＤＣＩなどの伝送に用いられる。
【００９５】
無線通信システム１では、上りリンクのチャネルとして、各ユーザ端末２０で共有される上り共有チャネル（ＰＵＳＣＨ：Physical  Uplink  Shared  Channel）、上り制御チャネル（ＰＵＣＣＨ：Physical  Uplink  Control  Channel）、ランダムアクセスチャネル（ＰＲＡＣＨ：Physical  Random  Access  Channel）などが用いられる。ＰＵＳＣＨにより、ユーザデータや上位レイヤ制御情報が伝送される。また、ＰＵＣＣＨにより、下りリンクの無線品質情報（ＣＱＩ：Channel  Quality  Indicator）、送達確認信号（ＡＣＫ／ＮＡＣＫ）などが伝送される。ＰＲＡＣＨにより、セルとの接続確立のためのランダムアクセスプリアンブルが伝送される。
【００９６】
＜無線基地局＞
図１４は、本発明の一実施形態に係る無線基地局の全体構成の一例を示す図である。無線基地局１０は、複数の送受信アンテナ１０１と、アンプ部１０２と、送受信部１０３と、ベースバンド信号処理部１０４と、呼処理部１０５と、伝送路インターフェース１０６とを備えている。なお、送受信アンテナ１０１、アンプ部１０２、送受信部１０３は、それぞれ１つ以上を含むように構成されればよい。
【００９７】
下りリンクにより無線基地局１０からユーザ端末２０に送信されるユーザデータは、上位局装置３０から伝送路インターフェース１０６を介してベースバンド信号処理部１０４に入力される。
【００９８】
ベースバンド信号処理部１０４では、ユーザデータに関して、ＰＤＣＰ（Packet  Data  Convergence  Protocol）レイヤの処理、ユーザデータの分割・結合、ＲＬＣ（Radio  Link  Control）再送制御などのＲＬＣレイヤの送信処理、ＭＡＣ（Medium  Access  Control）再送制御（例えば、ＨＡＲＱ（Hybrid  Automatic  Repeat  reQuest）の送信処理）、スケジューリング、伝送フォーマット選択、チャネル符号化、逆高速フーリエ変換（ＩＦＦＴ：Inverse  Fast  Fourier  Transform）処理、プリコーディング処理などの送信処理が行われて送受信部１０３に転送される。また、下り制御信号に関しても、チャネル符号化や逆高速フーリエ変換などの送信処理が行われて、送受信部１０３に転送される。
【００９９】
送受信部１０３は、ベースバンド信号処理部１０４からアンテナ毎にプリコーディングして出力されたベースバンド信号を無線周波数帯に変換して送信する。送受信部１０３で周波数変換された無線周波数信号は、アンプ部１０２により増幅され、送受信アンテナ１０１から送信される。送受信部１０３は、本発明に係る技術分野での共通認識に基づいて説明されるトランスミッター／レシーバー、送受信回路又は送受信装置から構成することができる。なお、送受信部１０３は、一体の送受信部として構成されてもよいし、送信部及び受信部から構成されてもよい。
【０１００】
一方、上り信号については、送受信アンテナ１０１で受信された無線周波数信号がアンプ部１０２で増幅される。送受信部１０３はアンプ部１０２で増幅された上り信号を受信する。送受信部１０３は、受信信号をベースバンド信号に周波数変換して、ベースバンド信号処理部１０４に出力する。
【０１０１】
ベースバンド信号処理部１０４では、入力された上り信号に含まれるユーザデータに対して、高速フーリエ変換（ＦＦＴ：Fast  Fourier  Transform）処理、逆離散フーリエ変換（ＩＤＦＴ：Inverse  Discrete  Fourier  Transform）処理、誤り訂正復号、ＭＡＣ再送制御の受信処理、ＲＬＣレイヤ及びＰＤＣＰレイヤの受信処理がなされ、伝送路インターフェース１０６を介して上位局装置３０に転送される。呼処理部１０５は、通信チャネルの設定や解放などの呼処理や、無線基地局１０の状態管理や、無線リソースの管理を行う。
【０１０２】
伝送路インターフェース１０６は、所定のインターフェースを介して、上位局装置３０と信号を送受信する。また、伝送路インターフェース１０６は、基地局間インターフェース（例えば、ＣＰＲＩ（Common  Public  Radio  Interface）に準拠した光ファイバ、Ｘ２インターフェース）を介して他の無線基地局１０と信号を送受信（バックホールシグナリング）してもよい。
【０１０３】
なお、送受信部１０３は、ユーザ端末２０に対して、後述の送信信号生成部３０２によって生成された、ＬＣＨとＬＣＧとの対応関係に関する情報、Ｒｅｌ．１３  ＣＡ向けのＢＳＲテーブルを用いるか否かに関する情報、４より大きいＬＣＧ数を用いるか否かに関する情報、Ｒｅｌ．１３  ＣＡの設定情報（Rel.13  CA  Configuration）などを含む下り信号を送信する。
【０１０４】
また、送受信部１０３は、ユーザ端末２０から、ＢＳＲ（ＢＳＲ  ＭＡＣ  ＣＥ）を含む上り信号（例えば、ＭＡＣシグナリング）を受信する。
【０１０５】
図１５は、本実施形態に係る無線基地局の機能構成の一例を示す図である。なお、図１５では、本実施形態における特徴部分の機能ブロックを主に示しており、無線基地局１０は、無線通信に必要な他の機能ブロックも有しているものとする。図１５に示すように、ベースバンド信号処理部１０４は、制御部（スケジューラ）３０１と、送信信号生成部３０２と、マッピング部３０３と、受信信号処理部３０４と、測定部３０５と、を少なくとも備えている。
【０１０６】
制御部（スケジューラ）３０１は、無線基地局１０全体の制御を実施する。制御部３０１は、本発明に係る技術分野での共通認識に基づいて説明されるコントローラ、制御回路又は制御装置から構成することができる。
【０１０７】
制御部３０１は、例えば、送信信号生成部３０２による信号の生成や、マッピング部３０３による信号の割り当てを制御する。また、制御部３０１は、受信信号処理部３０４による信号の受信処理や、測定部３０５による信号の測定を制御する。
【０１０８】
制御部３０１は、システム情報、ＰＤＳＣＨで送信される下りデータ信号、ＰＤＣＣＨ及び／又はＥＰＤＣＣＨで伝送される下り制御信号のスケジューリング（例えば、リソース割り当て）を制御する。また、同期信号や、ＣＲＳ（Cell-specific  Reference  Signal）、ＣＳＩ−ＲＳ（Channel  State  Information  Reference  Signal）、ＤＭ−ＲＳ（Demodulation  Reference  Signal）などの下り参照信号のスケジューリングの制御を行う。
【０１０９】
また、制御部３０１は、ＰＵＳＣＨで送信される上りデータ信号、ＰＵＣＣＨ及び／又はＰＵＳＣＨで送信される上り制御信号（例えば、送達確認信号（ＨＡＲＱ−ＡＣＫ））、ＰＲＡＣＨで送信されるランダムアクセスプリアンブルや、上り参照信号などのスケジューリングを制御する。
【０１１０】
制御部３０１は、受信信号処理部３０４から入力されるＢＳＲに基づいて、ユーザ端末２０の所定のＬＣＧ（又は全ＬＣＧ）に関するバッファサイズを判断する。ここで、バッファサイズの判断には、バッファサイズとインデックスとを関連付けた対応関係（ＢＳＲテーブル）が用いられる。
【０１１１】
制御部３０１は、１つ以上のＢＳＲテーブルを利用することができる。制御部３０１は、所定のユーザ端末２０が５個より多いＣＣを設定された場合に、当該ユーザ端末２０のバッファサイズの判断に用いるテーブルを有する（第１の実施形態）。当該テーブルは、Ｒｅｌ．１３  ＣＡ向けＢＳＲテーブル（Ｒｅｌ．１３テーブル）と呼ばれてもよい。
【０１１２】
Ｒｅｌ．１３テーブルは、既存システムと同様の６ビットでインデックスを表し、Ｒｅｌ．１３のＢｍａｘ（例えば、２０ＭＢ）までのバッファサイズを表すように構成されてもよい（第１の実施形態の方法１）。また、Ｒｅｌ．１３テーブルは、既存システムより多いＸビット（Ｘ＞６）でインデックスを表し、Ｒｅｌ．１３のＢｍａｘまでのバッファサイズを表すように構成されてもよい（第１の実施形態の方法２）。
【０１１３】
また、Ｒｅｌ．１３テーブルは、Ｒｅｌ．１０のＢｍａｘ（３ＭＢ）より大きくＲｅｌ．１３のＢｍａｘまでのバッファサイズを表すように構成されてもよい（第１の実施形態の方法３）。この場合、制御部３０１は、３ＭＢ以下のバッファサイズを表す別のＢＳＲテーブル（例えば、Ｒｅｌ．１０テーブル）を利用できるように構成されてもよい。また、制御部３０１は、バッファサイズの判断に用いるテーブルを、ＢＳＲ  ＭＡＣ  ＣＥを含むＭＡＣシグナリングに含まれる特定情報に基づいて決定することができる。当該特定情報は、例えば、ＭＡＣ  ＰＤＵサブヘッダにおいて、ＬＴＥ  Ｒｅｌ．１０で予約（Ｒ：Reserved）フィールドとされていたビットで表現されてもよい。
【０１１４】
また、制御部３０１は、４より大きいＬＣＧ数に関するバッファサイズを判断することができる（第２の実施形態）。制御部３０１は、ＢＳＲ  ＭＡＣ  ＣＥに対応するＬＣＧ（例えば、ＬＣＧ  ＩＤ  ＃４以上）について、当該ＢＳＲ  ＭＡＣ  ＣＥの３ビット以上に拡張されたＬＣＧ  ＩＤフィールド及び／又はＭＡＣ  ＰＤＵサブヘッダのＬＣＩＤフィールドに基づいて決定することができる。
【０１１５】
制御部３０１は、所定のユーザ端末２０のバッファサイズの特定に用いるテーブルを決定し、当該ユーザ端末２０に対して、ＢＳＲテーブルの構成情報や、ＢＳＲ生成に用いるテーブルを特定する情報（Ｒｅｌ．１３  ＣＡ向けのＢＳＲテーブルを用いるか否かに関する情報）などを送信するように、送信信号生成部３０２及びマッピング部３０３を制御する。
【０１１６】
また、制御部３０１は、ユーザ端末２０のバッファサイズに基づいて、上り無線リソースの割り当てを制御（スケジューリング）することができる。例えば、制御部３０１は、バッファサイズに基づいてＵＬグラントを生成して送信するように制御する。
【０１１７】
送信信号生成部３０２は、制御部３０１からの指示に基づいて、下り信号（下り制御信号、下りデータ信号、下り参照信号など）を生成して、マッピング部３０３に出力する。送信信号生成部３０２は、本発明に係る技術分野での共通認識に基づいて説明される信号生成器、信号生成回路又は信号生成装置から構成することができる。
【０１１８】
送信信号生成部３０２は、例えば、制御部３０１からの指示に基づいて、下り信号の割り当て情報を通知するＤＬアサインメント及び上り信号の割り当て情報を通知するＵＬグラントを生成する。また、下りデータ信号には、各ユーザ端末２０からのチャネル状態情報（ＣＳＩ：Channel  State  Information）などに基づいて決定された符号化率、変調方式などに従って符号化処理、変調処理が行われる。
【０１１９】
また、送信信号生成部３０２は、上述したように、ＢＳＲテーブルの構成情報や、ＢＳＲ生成に用いるテーブルを特定する情報（Ｒｅｌ．１３  ＣＡ向けのＢＳＲテーブルを用いるか否かに関する情報）などを含む下り信号を生成する。
【０１２０】
マッピング部３０３は、制御部３０１からの指示に基づいて、送信信号生成部３０２で生成された下り信号を、所定の無線リソースにマッピングして、送受信部１０３に出力する。マッピング部３０３は、本発明に係る技術分野での共通認識に基づいて説明されるマッパー、マッピング回路又はマッピング装置から構成することができる。
【０１２１】
受信信号処理部３０４は、送受信部１０３から入力された受信信号に対して、受信処理（例えば、デマッピング、復調、復号など）を行う。ここで、受信信号は、例えば、ユーザ端末２０から送信される上り信号（上り制御信号、上りデータ信号、上り参照信号など）である。受信信号処理部３０４は、本発明に係る技術分野での共通認識に基づいて説明される信号処理器、信号処理回路又は信号処理装置から構成することができる。
【０１２２】
受信信号処理部３０４は、受信処理により復号された情報を制御部３０１に出力する。また、受信信号処理部３０４は、受信信号や、受信処理後の信号を、測定部３０５に出力する。
【０１２３】
測定部３０５は、受信した信号に関する測定を実施する。測定部３０５は、本発明に係る技術分野での共通認識に基づいて説明される測定器、測定回路又は測定装置から構成することができる。
【０１２４】
測定部３０５は、例えば、受信した信号の受信電力（例えば、ＲＳＲＰ（Reference  Signal  Received  Power））、受信品質（例えば、ＲＳＲＱ（Reference  Signal  Received  Quality））やチャネル状態などについて測定してもよい。測定結果は、制御部３０１に出力されてもよい。
【０１２５】
＜ユーザ端末＞
図１６は、本実施形態に係るユーザ端末の全体構成の一例を示す図である。ユーザ端末２０は、複数の送受信アンテナ２０１と、アンプ部２０２と、送受信部２０３と、ベースバンド信号処理部２０４と、アプリケーション部２０５と、を備えている。なお、送受信アンテナ２０１、アンプ部２０２、送受信部２０３は、それぞれ１つ以上を含むように構成されればよい。
【０１２６】
送受信アンテナ２０１で受信された無線周波数信号は、アンプ部２０２で増幅される。送受信部２０３は、アンプ部２０２で増幅された下り信号を受信する。送受信部２０３は、受信信号をベースバンド信号に周波数変換して、ベースバンド信号処理部２０４に出力する。送受信部２０３は、本発明に係る技術分野での共通認識に基づいて説明されるトランスミッター／レシーバー、送受信回路又は送受信装置から構成することができる。なお、送受信部２０３は、一体の送受信部として構成されてもよいし、送信部及び受信部から構成されてもよい。
【０１２７】
ベースバンド信号処理部２０４は、入力されたベースバンド信号に対して、ＦＦＴ処理や、誤り訂正復号、再送制御の受信処理などを行う。下りリンクのユーザデータは、アプリケーション部２０５に転送される。アプリケーション部２０５は、物理レイヤやＭＡＣレイヤより上位のレイヤに関する処理などを行う。また、下りリンクのデータのうち、報知情報もアプリケーション部２０５に転送される。
【０１２８】
一方、上りリンクのユーザデータについては、アプリケーション部２０５からベースバンド信号処理部２０４に入力される。ベースバンド信号処理部２０４では、再送制御の送信処理（例えば、ＨＡＲＱの送信処理）や、チャネル符号化、プリコーディング、離散フーリエ変換（ＤＦＴ：Discrete  Fourier  Transform）処理、ＩＦＦＴ処理などが行われて送受信部２０３に転送される。送受信部２０３は、ベースバンド信号処理部２０４から出力されたベースバンド信号を無線周波数帯に変換して送信する。送受信部２０３で周波数変換された無線周波数信号は、アンプ部２０２により増幅され、送受信アンテナ２０１から送信される。
【０１２９】
なお、送受信部２０３は、無線基地局１０から、ＬＣＨとＬＣＧとの対応関係に関する情報、Ｒｅｌ．１３  ＣＡ向けのＢＳＲテーブルを用いるか否かに関する情報、４より大きいＬＣＧ数を用いるか否かに関する情報、Ｒｅｌ．１３  ＣＡの設定情報（Rel.13  CA  Configuration）などを含む下り信号を受信する。また、送受信部２０３は、リソース割り当て情報を含むＵＬグラントを受信する。
【０１３０】
また、送受信部２０３は、無線基地局１０に、ＢＳＲ（ＢＳＲ  ＭＡＣ  ＣＥ）を含む上り信号（例えば、ＭＡＣシグナリング）を送信する。
【０１３１】
図１７は、本実施形態に係るユーザ端末の機能構成の一例を示す図である。なお、図１７においては、本実施形態における特徴部分の機能ブロックを主に示しており、ユーザ端末２０は、無線通信に必要な他の機能ブロックも有しているものとする。図１７に示すように、ユーザ端末２０が有するベースバンド信号処理部２０４は、制御部４０１と、送信信号生成部４０２と、マッピング部４０３と、受信信号処理部４０４と、測定部４０５と、データバッファリング部４０６と、を少なくとも備えている。
【０１３２】
制御部４０１は、ユーザ端末２０全体の制御を実施する。制御部４０１は、本発明に係る技術分野での共通認識に基づいて説明されるコントローラ、制御回路又は制御装置から構成することができる。
【０１３３】
制御部４０１は、例えば、送信信号生成部４０２による信号の生成や、マッピング部４０３による信号の割り当てを制御する。また、制御部４０１は、受信信号処理部４０４による信号の受信処理や、測定部４０５による信号の測定を制御する。
【０１３４】
制御部４０１は、無線基地局１０から送信された下り制御信号（ＰＤＣＣＨ／ＥＰＤＣＣＨで送信された信号）及び下りデータ信号（ＰＤＳＣＨで送信された信号）を、受信信号処理部４０４から取得する。制御部４０１は、下り制御信号や、下りデータ信号に対する再送制御の要否を判定した結果などに基づいて、上り制御信号（例えば、送達確認信号（ＨＡＲＱ−ＡＣＫ）など）や上りデータ信号の生成を制御する。
【０１３５】
制御部４０１は、データバッファリング部４０６に蓄積されているＬＣＧごとのデータ量（バッファサイズ）を無線基地局１０に報告するための制御を行う。まず、制御部４０１は、データバッファリング部４０６から、各ＬＣＧのバッファサイズを取得する。そして、制御部４０１は、バッファサイズに対応する所定のインデックスを含むＢＳＲを生成して送信するように、送信信号生成部４０２及びマッピング部４０３を制御する。
【０１３６】
ここで、バッファサイズの判断には、バッファサイズとインデックスとを関連付けた対応関係（ＢＳＲテーブル）が用いられる。制御部４０１は、１つ以上のＢＳＲテーブルを利用することができる。制御部４０１は、当該ユーザ端末２０が５個より多いＣＣを設定された場合に、当該ユーザ端末２０のバッファサイズの判断に用いるテーブル（Ｒｅｌ．１３テーブル）を有する（第１の実施形態）。
【０１３７】
なお、制御部４０１は、受信信号処理部４０４から入力された、ＬＣＨとＬＣＧとの対応関係に関する情報、Ｒｅｌ．１３  ＣＡ向けのＢＳＲテーブルを用いるか否かに関する情報、４より大きいＬＣＧ数を用いるか否かに関する情報、Ｒｅｌ．１３  ＣＡの設定情報（Rel.13  CA  Configuration）、ＣＣ数に関する情報などに基づいて、５個より多いＣＣを設定されたか否かを判断することができる。
【０１３８】
制御部４０１は、無線基地局１０からの通知（例えば、ＲＲＣシグナリング）及び／又は各ＬＣＧのバッファサイズに基づいて、ＢＳＲ生成に用いるＢＳＲテーブルを決定する（第１の実施形態）。ここで、制御部４０１は、Ｒｅｌ．１０のＢｍａｘ（３ＭＢ）より大きくＲｅｌ．１３のＢｍａｘまでのバッファサイズに関するＢＳＲの生成に、Ｒｅｌ．１３テーブルを用いてもよい（第１の実施形態の方法３）。この場合、制御部４０１は、３ＭＢ以下のバッファサイズを表す別のＢＳＲテーブル（例えば、Ｒｅｌ．１０テーブル）を利用できるように構成されてもよい。また、制御部４０１は、バッファサイズの判断に用いるテーブルを特定するための特定情報を、ＭＡＣシグナリングに含むように制御することができる。
【０１３９】
また、制御部４０１は、４より大きいＬＣＧ数に関するバッファサイズに対応するＢＳＲを生成するように制御することができる（第２の実施形態）。制御部４０１は、ＢＳＲ  ＭＡＣ  ＣＥに対応するＬＣＧ（例えば、ＬＣＧ  ＩＤ  ＃４以上）を、当該ＢＳＲ  ＭＡＣ  ＣＥの３ビット以上に拡張されたＬＣＧ  ＩＤフィールド及び／又はＭＡＣ  ＰＤＵサブヘッダのＬＣＩＤフィールドで特定できるようにＭＡＣシグナリングを構成するように制御することができる。
【０１４０】
また、制御部４０１は、ユーザ端末２０がＢＳＲを送信するタイミングの基準となるタイマを管理することができる。例えば、制御部４０１は、周期的なＢＳＲタイマ（periodicBSR-Timer）や、retxBSR-Timerを管理し、これらのタイマの起動、再起動、停止などの処理を実施する。
【０１４１】
また、制御部４０１は、受信信号処理部４０４から上りリソース割り当てに関する情報（例えば、ＵＬグラントに含まれるリソース割り当て情報）を取得した場合は、割り当てられたリソースを用いて上りデータを送信するように制御を実施する。具体的には、制御部４０１は、データバッファリング部４０６が所定のデータ量分のデータを送信信号生成部４０２に出力し、送信信号生成部４０２が入力されたデータを上りデータ信号（ＰＵＳＣＨ信号）として生成してマッピング部４０３に出力し、マッピング部４０３が入力された上りデータ信号を上りリソースにマッピングして出力するように、制御を実施する。
【０１４２】
送信信号生成部４０２は、制御部４０１からの指示に基づいて、上り信号（上り制御信号、上りデータ信号、上り参照信号など）を生成して、マッピング部４０３に出力する。送信信号生成部４０２は、本発明に係る技術分野での共通認識に基づいて説明される信号生成器、信号生成回路又は信号生成装置から構成することができる。
【０１４３】
送信信号生成部４０２は、例えば、制御部４０１からの指示に基づいて、送達確認信号（ＨＡＲＱ−ＡＣＫ）やチャネル状態情報（ＣＳＩ）に関する上り制御信号を生成する。また、送信信号生成部４０２は、制御部４０１からの指示に基づいて上りデータ信号を生成する。例えば、送信信号生成部４０２は、無線基地局１０から通知される下り制御信号にＵＬグラントが含まれている場合に、制御部４０１から上りデータ信号の生成を指示される。
【０１４４】
また、送信信号生成部４０２は、制御部４０１からの指示に基づいて、データバッファリング部４０６から入力されたデータを用いて上りデータ信号を生成する。また、送信信号生成部４０２は、制御部４０１からの指示に基づいて、ＢＳＲ  ＭＡＣ  ＣＥを生成して、ＭＡＣ  ＰＤＵを構成し、送信信号に含めてマッピング部４０３に出力する。
【０１４５】
具体的には、送信信号生成部４０２は、ＢＳＲ  ＭＡＣ  ＣＥのＢＳフィールドを６ビットで構成してもよいし（第１の実施形態の方法１）、既存システムより多いＸビット（Ｘ＞６）で構成してもよい（第１の実施形態の方法２）。この場合、送信信号生成部４０２は、ＭＡＣ  ＰＤＵのサブヘッダに、ＢＳＲ  ＭＡＣ  ＣＥのタイプ（Short  BSR/Truncated  BSR、Long  BSR）を特定するための情報（ＬＣＩＤ）を含める。
【０１４６】
また、送信信号生成部４０２は、ＭＡＣ  ＰＤＵのサブヘッダに、ＢＳＲの生成に用いたＢＳＲテーブル（又はＢＳＲテーブルの種類）を特定する特定情報を含めてもよい（第１の実施形態の方法３）。当該特定情報は、例えば、ＭＡＣ  ＰＤＵサブヘッダにおいて、ＬＴＥ  Ｒｅｌ．１０で予約（Ｒ：Reserved）フィールドとされていたビットで表現されてもよい。
【０１４７】
また、送信信号生成部４０２は、ＭＡＣ  ＰＤＵのサブヘッダに、ＬＣＧ  ＩＤ  ＃４以上を示すＬＣＩＤフィールドを含めてもよいし、ＢＳＲ  ＭＡＣ  ＣＥのＬＣＧ  ＩＤフィールドを３ビット以上で構成してもよい（第２の実施形態）。
【０１４８】
マッピング部４０３は、制御部４０１からの指示に基づいて、送信信号生成部４０２で生成された上り信号を無線リソースにマッピングして、送受信部２０３へ出力する。マッピング部４０３は、本発明に係る技術分野での共通認識に基づいて説明されるマッパー、マッピング回路又はマッピング装置から構成することができる。
【０１４９】
受信信号処理部４０４は、送受信部２０３から入力された受信信号に対して、受信処理（例えば、デマッピング、復調、復号など）を行う。ここで、受信信号は、例えば、無線基地局１０から送信される下り信号（下り制御信号、下りデータ信号、下り参照信号など）である。受信信号処理部４０４は、本発明に係る技術分野での共通認識に基づいて説明される信号処理器、信号処理回路又は信号処理装置から構成することができる。また、受信信号処理部４０４は、本発明に係る受信部を構成することができる。
【０１５０】
受信信号処理部４０４は、受信処理により復号された情報を制御部４０１に出力する。受信信号処理部４０４は、例えば、報知情報、システム情報、ＲＲＣシグナリング、ＤＣＩなどを、制御部４０１に出力する。また、受信信号処理部４０４は、受信信号や、受信処理後の信号を、測定部４０５に出力する。
【０１５１】
測定部４０５は、受信した信号に関する測定を実施する。測定部４０５は、本発明に係る技術分野での共通認識に基づいて説明される測定器、測定回路又は測定装置から構成することができる。
【０１５２】
測定部４０５は、例えば、受信した信号の受信電力（例えば、ＲＳＲＰ）、受信品質（例えば、ＲＳＲＱ）やチャネル状態などについて測定してもよい。測定結果は、制御部４０１に出力されてもよい。
【０１５３】
データバッファリング部４０６は、アプリケーション部２０５から入力されるユーザデータ（上りデータ）を蓄積（バッファリング）する。データバッファリング部４０６は、制御部４０１からの指示に基づいて、蓄積したデータのうち所定の量のデータを送信信号生成部４０２に出力する。データバッファリング部４０６は、本発明に係る技術分野での共通認識に基づいて説明されるバッファ、バッファ回路又はバッファ装置から構成することができる。
【０１５４】
なお、上記実施形態の説明に用いたブロック図は、機能単位のブロックを示している。これらの機能ブロック（構成部）は、ハードウェア及びソフトウェアの任意の組み合わせによって実現される。また、各機能ブロックの実現手段は特に限定されない。すなわち、各機能ブロックは、物理的に結合した１つの装置により実現されてもよいし、物理的に分離した２つ以上の装置を有線又は無線で接続し、これら複数の装置により実現されてもよい。
【０１５５】
例えば、無線基地局１０やユーザ端末２０の各機能の一部又は全ては、ＡＳＩＣ（Application  Specific  Integrated  Circuit）、ＰＬＤ（Programmable  Logic  Device）、ＦＰＧＡ（Field  Programmable  Gate  Array）などのハードウェアを用いて実現されても良い。また、無線基地局１０やユーザ端末２０は、プロセッサ（ＣＰＵ：Central  Processing  Unit）と、ネットワーク接続用の通信インターフェースと、メモリと、プログラムを保持したコンピュータ読み取り可能な記憶媒体と、を含むコンピュータ装置によって実現されてもよい。つまり、本発明の一実施形態に係る無線基地局、ユーザ端末などは、本発明に係る無線通信方法の処理を行うコンピュータとして機能してもよい。
【０１５６】
ここで、プロセッサやメモリなどは情報を通信するためのバスで接続される。また、コンピュータ読み取り可能な記録媒体は、例えば、フレキシブルディスク、光磁気ディスク、ＲＯＭ（Read  Only  Memory）、ＥＰＲＯＭ（Erasable  Programmable  ＲＯＭ）、ＣＤ−ＲＯＭ（Compact  Disc−ＲＯＭ）、ＲＡＭ（Random  Access  Memory）、ハードディスクなどの記憶媒体である。また、プログラムは、電気通信回線を介してネットワークから送信されても良い。また、無線基地局１０やユーザ端末２０は、入力キーなどの入力装置や、ディスプレイなどの出力装置を含んでいてもよい。
【０１５７】
無線基地局１０及びユーザ端末２０の機能構成は、上述のハードウェアによって実現されてもよいし、プロセッサによって実行されるソフトウェアモジュールによって実現されてもよいし、両者の組み合わせによって実現されてもよい。プロセッサは、オペレーティングシステムを動作させてユーザ端末の全体を制御する。また、プロセッサは、記憶媒体からプログラム、ソフトウェアモジュールやデータをメモリに読み出し、これらに従って各種の処理を実行する。
【０１５８】
ここで、当該プログラムは、上記の各実施形態で説明した各動作を、コンピュータに実行させるプログラムであれば良い。例えば、ユーザ端末２０の制御部４０１は、メモリに格納され、プロセッサで動作する制御プログラムによって実現されてもよく、他の機能ブロックについても同様に実現されてもよい。
【０１５９】
また、ソフトウェア、命令などは、伝送媒体を介して送受信されてもよい。例えば、ソフトウェアが、同軸ケーブル、光ファイバケーブル、ツイストペア及びデジタル加入者回線（ＤＳＬ）などの有線技術及び／又は赤外線、無線及びマイクロ波などの無線技術を使用してウェブサイト、サーバ、又は他のリモートソースから送信される場合、これらの有線技術及び／又は無線技術は、伝送媒体の定義内に含まれる。
【０１６０】
なお、本明細書中で説明した及び／又は本明細書の理解に必要な各用語については、同一の又は類似する意味を有する用語と置き換えてもよい。例えば、無線リソースはインデックスで指示されるものであってもよい。また、チャネル及び／又はシンボルは信号（シグナリング）であってもよい。また、信号はメッセージであってもよい。また、コンポーネントキャリア（ＣＣ）は、キャリア周波数、セルなどと呼ばれてもよい。
【０１６１】
本明細書で示した各態様／実施形態は単独で用いてもよいし、組み合わせて用いてもよいし、実行に伴って切り替えて用いてもよい。また、所定の情報の通知（例えば、「Ｘであること」の通知）は、明示的に行うものに限られず、暗黙的（例えば、当該所定の情報の通知を行わない）ことによって行われてもよい。
【０１６２】
情報の通知は、本明細書で示した態様／実施形態に限られず、他の方法で行われてもよい。例えば、情報の通知は、物理レイヤシグナリング（例えば、ＤＣＩ（Downlink  Control  Information）、ＵＣＩ（Uplink  Control  Information））、上位レイヤシグナリング（例えば、ＲＲＣ（Radio  Resource  Control）シグナリング、ＭＡＣ（Medium  Access  Control）シグナリング、報知情報（ＭＩＢ（Master  Information  Block）、ＳＩＢ（System  Information  Block）））、その他の信号又はこれらの組み合わせによって実施されてもよい。また、ＲＲＣシグナリングは、例えば、ＲＲＣ接続セットアップ（RRCConnectionSetup）メッセージ、ＲＲＣ接続再構成（RRCConnectionReconfiguration）メッセージなどであってもよい。
【０１６３】
本明細書で示した情報、信号などは、様々な異なる技術のいずれかを使用して表されてもよい。例えば、上記の説明全体に渡って言及され得るデータ、命令、コマンド、情報、信号、ビット、シンボル、チップなどは、電圧、電流、電磁波、磁界若しくは磁性粒子、光場若しくは光子、又はこれらの任意の組み合わせによって表されてもよい。
【０１６４】
本明細書で示した各態様／実施形態は、ＬＴＥ（Long  Term  Evolution）、ＬＴＥ−Ａ（LTE-Advanced）、ＳＵＰＥＲ  ３Ｇ、ＩＭＴ−Ａｄｖａｎｃｅｄ、４Ｇ、５Ｇ、ＦＲＡ（Future  Radio  Access）、ＣＤＭＡ２０００、ＵＭＢ（Ultra  Mobile  Broadband）、ＩＥＥＥ  ８０２．１１（Ｗｉ−Ｆｉ）、ＩＥＥＥ  ８０２．１６（ＷｉＭＡＸ）、ＩＥＥＥ  ８０２．２０、ＵＷＢ（Ultra-WideBand）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、その他の適切なシステムを利用するシステム及び／又はこれらに基づいて拡張された次世代システムに適用されてもよい。
【０１６５】
本明細書で示した各態様／実施形態の処理手順、シーケンス、フローチャートなどは、矛盾の無い限り、順序を入れ替えてもよい。例えば、本明細書で示した方法については、例示的な順序で様々なステップの要素を提示しており、提示した特定の順序に限定されない。
【０１６６】
以上、本発明について詳細に説明したが、当業者にとっては、本発明が本明細書中に説明した実施形態に限定されるものではないということは明らかである。本発明は、特許請求の範囲の記載により定まる本発明の趣旨及び範囲を逸脱することなく修正及び変更態様として実施することができる。したがって、本明細書の記載は、例示説明を目的とするものであり、本発明に対して何ら制限的な意味を有するものではない。
【０１６７】
本出願は、２０１５年５月１４日出願の特願２０１５−０９９４９１に基づく。この内容は、全てここに含めておく。
【図１】
2016182048.tif 000005
【図２】
2016182048.tif 000006
【図３】
2016182048.tif 000007
【図４】
2016182048.tif 000008
【図５】
2016182048.tif 000009
【図６】
2016182048.tif 000010
【図７】
2016182048.tif 000011
【図８】
2016182048.tif 000012
【図９】
2016182048.tif 000013
【図１０】
2016182048.tif 000014
【図１１】
2016182048.tif 000015
【図１２】
2016182048.tif 000016
【図１３】
2016182048.tif 000017
【図１４】
2016182048.tif 000018
【図１５】
2016182048.tif 000019
【図１６】
2016182048.tif 000020
【図１７】
2016182048.tif 000021
【国際調査報告】
2016182048.tif 000022
2016182048.tif 000023
2016182048.tif 000024