JP6844853B2

JP6844853B2 - 端末及び無線通信方法

Info

Publication number: JP6844853B2
Application number: JP2017517999A
Authority: JP
Inventors: 一樹武田; 聡永田; リフェワン; リューリュー; ホイリンジャン
Original assignee: NTT Docomo Inc
Current assignee: NTT Docomo Inc
Priority date: 2015-05-14
Filing date: 2016-05-13
Publication date: 2021-03-17
Anticipated expiration: 2036-05-13
Also published as: HUE063148T2; JPWO2016182048A1; WO2016182048A1; EP3297355B1; ES2951761T3; US10833820B2; EP3297355A4; US20180139020A1; EP3297355A1

Description

本発明は、次世代移動通信システムにおけるユーザ端末、無線基地局、無線通信方法及び無線通信システムに関する。

ＵＭＴＳ（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 ＣＡ）、Ｒｅｌ．１３ＣＡなどと呼ばれてもよい。

しかしながら、ユーザ端末に設定可能なＣＣ数が６個以上（例えば、３２個）に拡張される場合、既存システム（Ｒｅｌ．１０〜１２）におけるＢＳＲをそのまま利用することが困難となる。例えば、既存システムでは、ＢＳＲで示されるバッファサイズは５ＣＣ以下のＣＡを前提としているため、６ＣＣ以上のＣＡを適用する場合、バッファサイズを適切に示すことができない場合がある。このため、無線基地局がユーザ端末の上り無線リソースの割り当てを適切に制御することができず、拡張ＣＡによるスループット向上効果が好適に達成されなくなるおそれがある。

本発明はかかる点に鑑みてなされたものであり、ユーザ端末に設定可能なコンポーネントキャリア数が既存システムより拡張される場合であっても、通信を適切に行うことができるユーザ端末及び無線通信方法を提供することを目的とする。

本発明の一態様に係る端末は、最大Logical Channel Group（ＬＣＧ）数が４より大きい数に規定されるＬＣＧのバッファサイズと、インデックスと、の関連付けに基づいて、Buffer Status Report Medium Access Control Control Element（ＢＳＲＭＡＣＣＥ）を生成し、前記ＢＳＲＭＡＣＣＥを含むＭＡＣ Protocol Data Unit（ＰＤＵ）に、ＬＴＥＲｅｌ．１２で利用されていないLogical Channel Identifier（ＬＣＩＤ）を含める生成部と、前記ＢＳＲＭＡＣＣＥを送信する送信部と、を有し、前記ＢＳＲＭＡＣＣＥは、前記ＬＣＧの前記バッファサイズに対応する前記インデックスを示すバッファサイズフィールドと、前記ＬＣＧを示す３ビットのＬＣＧＩＤフィールドと、を含むことを特徴とする。

本発明によれば、ユーザ端末に設定可能なコンポーネントキャリア数が既存システムより拡張される場合であっても、通信を適切に行うことができる。

既存のＬＴＥシステムにおけるＢＳＲＭＡＣＣＥの構成を示す図である。既存のＬＴＥシステムにおける上り共有チャネルに用いられるＬＣＩＤ値の一例を示す図である。既存のＬＴＥシステムにおけるＢＳＲテーブルを示す図である。Ｒｅｌ．１３ＣＡの一例を示す図である。第１の実施形態の方法１に係るＢＳＲテーブルの一例を示す図である。第１の実施形態の方法２に係るＢＳＲテーブルの一例を示す図である。第１の実施形態の方法２に係るＢＳＲＭＡＣＣＥの構成の一例を示す図である。第１の実施形態の方法３に係るＢＳＲテーブルの一例を示す図である。第１の実施形態の方法３に係るＭＡＣＰＤＵの一例を示す図である。第１の実施形態の変形例における上り共有チャネルに用いられるＬＣＩＤ値の一例を示す図である。第２の実施形態に係るＢＳＲＭＡＣＣＥの構成の一例を示す図である。第２の実施形態で実現されるＬＣＧ構成の一例を示す図である。本発明の一実施形態に係る無線通信システムの概略構成の一例を示す図である。本発明の一実施形態に係る無線基地局の全体構成の一例を示す図である。本発明の一実施形態に係る無線基地局の機能構成の一例を示す図である。本発明の一実施形態に係るユーザ端末の全体構成の一例を示す図である。本発明の一実施形態に係るユーザ端末の機能構成の一例を示す図である。

まず、既存のＬＴＥシステム（Ｒｅｌ．１０〜１２）におけるＢＳＲについて説明する。

ＢＳＲで報告されるバッファサイズは、データが存在する論理チャネルグループ（ＬＣＧ：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）、最大ＣＣ数は５、上りＭＩＭＯは最大２レイヤであることから、最大バッファサイズとして、（１４９７７６＊１６＊５＊２）／８＝２９９５５２０バイトが必要であると求められる。したがって、図３に示すように、Ｒｅｌ．１０のＢＳＲテーブルでは、２９９５５２０バイトを超える３ＭＢ（３００００００バイト）がＢ_ｍａｘとして規定されている。

また、ＢＳＲテーブルにおいて、ＢＳレベルｋに対応するバッファサイズＢ_ｋは、以下の式１で導出される。なお、ｋは（インデックス−１）に相当する。

ところで、ＬＴＥＲｅｌ．１３では、６個以上のＣＣ（５個を超えるＣＣ）を設定するＣＡ（拡張ＣＡ、Ｒｅｌ．１３ＣＡ）が検討されている。例えば、Ｒｅｌ．１３ＣＡでは、最大３２個までのＣＣを束ねることが検討されている。

このような多数のＣＣを用いるＲｅｌ．１３ＣＡは、同じくＲｅｌ．１３で検討されているＬＡＡ（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）を除くＳＣｅｌｌは、タイマまたは基地局からのシグナリングに応じて非活性化（すなわちＤｅ−ａｃｔｉｖｅ化）される。ＡｃｔｉｖｅなＣＣが５以下の場合、新規ＢＳＲテーブルを用いる必要は無い。したがって、ＵＥはＡｃｔｉｖｅなＣＣ数に応じて、ＢＳＲの計算に用いるテーブルを選択するようにすることができる。

これにより、方法１においては、ＡｃｔｉｖｅなＣＣ数が多い場合には、新たなＢＳＲテーブルを用いることで、ステップサイズは大きくなるが最大バッファサイズを拡大することができ、ＡｃｔｉｖｅなＣＣ数が少ない場合には冗長な最大バッファサイズを取らず、ステップサイズを細かくとるようにすることができる。

また、方法２においては、ＡｃｔｉｖｅなＣＣ数が多い場合には、新たなＢＳＲテーブルを用いることで、ＭＡＣＣＥのサイズを増やして最大バッファサイズを拡大することができ、ＡｃｔｉｖｅなＣＣ数が少ない場合には冗長な最大バッファサイズを取らず、ＭＡＣＣＥのオーバーヘッドを減らすようにすることができる。

以上述べたように、方法２では、ＢＳフィールドを拡張することにより、ステップサイズの増大を抑制しつつ、Ｒｅｌ．１３ＣＡのバッファサイズに対応することができる。

＜方法３＞
第１の実施形態の方法３では、複数のテーブルを切り替えて用いることで、ＢＳＲテーブルを拡張し、Ｒｅｌ．１３のＢ_ｍａｘまでの値を表せるように構成する。複数のテーブルのうち、１つのテーブルは他のテーブルの最大バッファサイズより大きなバッファサイズに関する情報を含む。

複数のテーブルの１つとしては、既存システム（例えば、Ｒｅｌ．１０）のＢＳＲテーブルを用いることができる。この場合、別のテーブルとしてＲｅｌ．１０のＢ_ｍａｘより大きくＲｅｌ．１３のＢ_ｍａｘまでのＢＳを表すテーブルを規定する。

図８は、第１の実施形態の方法３に係るＢＳＲテーブルの一例を示す図である。本例では、図８Ａ及び図８Ｂのテーブルを切り替えて用いる。図８Ａのテーブルは、図３で示したＲｅｌ．１０のテーブルであり、３ＭＢ以下のバッファサイズを表すために用いる。一方、図８Ｂのテーブルは、図８Ａの最大バッファサイズである３ＭＢ（３０００ＫＢ）超かつＲｅｌ．１３の最大バッファサイズである２０ＭＢ以下のバッファサイズを表すために用いる。図８Ｂのテーブルにおいて、各バッファサイズは、例えば式２を用いて算出してもよい。

図８Ｂのテーブルについては、全てのインデックスに、それぞれ対応するバッファサイズを規定する必要はない。つまり、Ｎは２^Ｘ−２に限られない。図８Ｂの場合、Ｎ＝１７である。表現されるバッファサイズの粒度は、図８Ｂの場合約１１％となる。なお、式２におけるｋは（インデックス＋１）としているが、これに限られない。

一部のインデックスは、更なる拡張用途に用いるために「予約」と設定されてもよい。「予約」のバッファサイズ値は、例えば上位レイヤシグナリングによって設定可能に構成されてもよい。図８Ｂでは、１７以上のインデックス値は予約と規定されている。

図８Ａ及び図８Ｂのいずれのテーブルを用いるかに関する情報（Ｒｅｌ．１３ＣＡ向けのＢＳＲテーブルを用いるか否かに関する情報）は、ユーザ端末に上位レイヤシグナリング（例えば、ＲＲＣシグナリング）、ＤＣＩなどで通知されてもよい。また、ユーザ端末は、Ｒｅｌ．１３ＣＡ（例えば、６ＣＣ以上のＣＡ）を設定された場合、図８Ｂのテーブルを用いることを暗黙的に決定する構成としてもよい。

また、ユーザ端末は、通知の有無によらず、図８Ａ及び図８Ｂのいずれのテーブルを用いるかを、動的に変更できる構成としてもよい。この場合、ＢＳＲＭＡＣＣＥに対応するＭＡＣＰＤＵサブヘッダに、当該ＢＳＲＭＡＣＣＥの生成に用いたＢＳＲテーブルを特定する情報（特定情報）を含めて無線基地局に通知する。

例えば、ＢＳＲＭＡＣＣＥの種類を既存システムと同じＬＣＩＤを用いて表す場合、ＢＳＲテーブルを特定する情報は、ＭＡＣＰＤＵサブヘッダのＲフィールドに含める。図９は、第１の実施形態の方法３に係るＭＡＣＰＤＵの一例を示す図である。なお、図９においてＭＡＣＰＤＵサブヘッダに含まれる「Ｅ」、「Ｆ」、「Ｌ」などのフィールドは、既存システムの各フィールドと同じであってもよい。また、ＭＡＣＰＤＵサブヘッダの構成はこれに限られない。

図９においては、ＭＡＣＰＤＵサブヘッダの１つにより、ＭＡＣＣＥ２がＳｈｏｒｔＢＳＲであること（ＬＣＩＤ＝１１１０１）が示されている。また、当該サブヘッダの最初のＲフィールドで、ＭＡＣＣＥ２で利用するＢＳＲテーブルが特定されている。本例では、当該Ｒフィールドが‘０’の場合、図８Ａに示したＲｅｌ．１０のテーブルを示し、‘１’の場合、図８Ｂに示した３ＭＢ超を規定したテーブルを示す。

なお、ＭＡＣＰＤＵに複数のＢＳＲＭＡＣＣＥを含む場合、各ＢＳＲＭＡＣＣＥで用いるテーブルは同じであってもよいし、異なっていてもよい。

以上述べたように、方法３では、複数のＢＳＲテーブルを用いることにより、既存システムとの互換性の維持と、通知できるバッファサイズの高粒度化を両立しつつ、Ｒｅｌ．１３ＣＡのバッファサイズに対応することができる。

以上、第１の実施形態によれば、５ＣＣより多いＣＣのＣＡを適用する場合であっても、大きなバッファサイズに対応したＢＳＲを無線基地局に通知することができる。

＜変形例＞
なお、第１の実施形態に示した例は一例に過ぎず、ＢＳＲテーブルの構成、ＭＡＣＰＤＵの構成などはこれに限られない。上記例では、Ｒｅｌ．１３のＢ_ｍａｘを２０ＭＢ（最大３２ＣＣまで対応）としたが、当該値はユーザ端末に設定される最大のＣＣ数に基づいて算出されればよく、他の値であってもよい。Ｒｅｌ．１３向けの新たなＢＳＲテーブルでは、例えば、最大８ＣＣ、１２ＣＣ、１６ＣＣ、２０ＣＣ、２４ＣＣ、２８ＣＣまで設定可能なユーザ端末に対し、それぞれＢ_ｍａｘを５ＭＢ、８ＭＢ、１０ＭＢ、１２ＭＢ、１５ＭＢ、１７ＭＢなどに設定できるようにしてもよい。また、Ｂ_ｍａｘ＝４０ＭＢ（例えば、最大６４ＣＣ）まで、Ｂ_ｍａｘ＝８０ＭＢまでなどのバッファサイズを特定することができるように、バッファサイズ及びインデックスが関連付けられてもよい。

図８では２つのＢＳＲテーブルを切り替えて用いる場合を示したが、テーブルの数は３以上であってもよい。また、この場合、ＢＳＲテーブルは、ＭＡＣＰＤＵサブヘッダの複数のＲフィールドを用いて特定されてもよい。つまり、特定情報は３つ以上のＢＳＲテーブルのいずれかを特定する情報であってもよい。

また、図８では、２つのＢＳＲテーブルのインデックスサイズは同じ６ビットとしたが、これに限られない。例えば、図８Ｂに示した３ＭＢ超を規定したテーブルは、方法２で示したように、６ビットより大きいインデックスを用いる構成としてもよい。

また、ＢＳＲテーブルは、Ｒフィールドではなく既存システム（Ｒｅｌ．１０〜１２）で利用されていないＬＣＩＤが指定されることにより特定されてもよい。つまり、ＭＡＣＰＤＵがＭＡＣヘッダに所定のＬＣＩＤを含むことで、当該ＭＡＣＰＤＵが第１の実施形態におけるＢＳＲＭＡＣＣＥを含むことを示してもよい。

図１０は、第１の実施形態の変形例における上り共有チャネルに用いられるＬＣＩＤ値の一例を示す図である。図１０において、インデックス「１０１０１」、「１０１１０」、「１０１１１」が、上述の方法３で示した３ＭＢ（３０００ＫＢ）超のＢＳＲを指定できるＢＳＲＭＡＣＣＥに対応している。なお、これらのＢＳＲＭＡＣＣＥを示すＬＣＩＤは、図１０の構成に限られず、例えば別のインデックスに割り当てられてもよい。

また、無線基地局及び／又はユーザ端末に、ＢＳＲテーブルの構成情報が通知されてもよい。例えば、ＢＳＲテーブルの構成情報は、所定のインデックスに対応するバッファサイズを規定する情報を含んでもよく、無線基地局及び／又はユーザ端末は、当該構成情報に基づいて所定のＢＳＲテーブルに含まれる情報を更新してもよい。

また、方法３におけるユーザ端末も、新規ＢＳＲを設定できることを示す端末能力情報を無線基地局に通知してもよい。この場合、無線基地局及び／又はユーザ端末は、方法１及び２について上述したような制御（設定、選択、通知など）を行う構成としてもよいし、別の制御を行ってもよい。また、各方法におけるＲｅｌ．１３ＣＡ向けのＢＳＲテーブルを用いるか否かに関する情報は、テーブル切り替え情報、バッファサイズ切り替え情報などと呼ばれてもよい。

（第２の実施形態：ＬＣＧ数の拡張）
本発明者らは、Ｒｅｌ．１３ＣＡ向けのＢＳＲ構成を検討するなかで、ＬＡＡのライセンスキャリア／アンライセンスキャリアのように異なる特性を有するベアラをサポートするには、現状の最大ＬＣＧ数（＝４）は不十分なおそれがあることを発見した。例えば、図４のように多数のＣＣが設定される場合、ＬＣＧ数４の環境では、品質の良いキャリアと悪いキャリアが同じＬＣＧで構成されてしまい、スループットが劣化することが考えられる。

そこで、本発明者らは、ＬＣＧ数を４より大きくすることを検討し、本発明の第２の実施形態を見出した。第２の実施形態では、設定可能なＬＣＧ数を既存システムに比べて増加させる。具体的には、最大ＬＣＧ数をＹ（Ｙ＞４）とし、４つより多いＬＣＧに対応したＢＳＲを表せるように構成する。

第２の実施形態では、ＢＳＲＭＡＣＣＥのＬＣＧＩＤフィールドのサイズが既存システムより大きくなるか、又はＢＳフィールドの数が既存システムより増えるため、ＢＳＲＭＡＣＣＥの構成を変更することが必要となる。ユーザ端末は、４より大きいＬＣＧ数を用いることを判断した場合、以下のようなＢＳＲＭＡＣＣＥを用いる。

図１１は、第２の実施形態に係るＢＳＲＭＡＣＣＥの構成の一例を示す図である。図１１では、Ｘ（ＢＳフィールドのサイズ）＝８とし、Ｙ（最大ＬＣＧ数）＝５とした例が示されている。この場合、１ＬＣＧに対応するＢＳＲ（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）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、その他の適切なシステムを利用するシステム及び／又はこれらに基づいて拡張された次世代システムに適用されてもよい。

本明細書で示した各態様／実施形態の処理手順、シーケンス、フローチャートなどは、矛盾の無い限り、順序を入れ替えてもよい。例えば、本明細書で示した方法については、例示的な順序で様々なステップの要素を提示しており、提示した特定の順序に限定されない。

以上、本発明について詳細に説明したが、当業者にとっては、本発明が本明細書中に説明した実施形態に限定されるものではないということは明らかである。本発明は、特許請求の範囲の記載により定まる本発明の趣旨及び範囲を逸脱することなく修正及び変更態様として実施することができる。したがって、本明細書の記載は、例示説明を目的とするものであり、本発明に対して何ら制限的な意味を有するものではない。

本出願は、２０１５年５月１４日出願の特願２０１５−０９９４９１に基づく。この内容は、全てここに含めておく。

Claims

最大Logical Channel Group（ＬＣＧ）数が４より大きい数に規定されるＬＣＧのバッファサイズと、インデックスと、の関連付けに基づいて、Buffer Status Report Medium Access Control Control Element（ＢＳＲＭＡＣＣＥ）を生成し、前記ＢＳＲＭＡＣＣＥを含むＭＡＣ Protocol Data Unit（ＰＤＵ）に、ＬＴＥＲｅｌ．１２で利用されていないLogical Channel Identifier（ＬＣＩＤ）を含める生成部と、
前記ＢＳＲＭＡＣＣＥを送信する送信部と、を有し、
前記ＢＳＲＭＡＣＣＥは、前記ＬＣＧの前記バッファサイズに対応する前記インデックスを示すバッファサイズフィールドと、前記ＬＣＧを示す３ビットのＬＣＧＩＤフィールドと、を含むことを特徴とする端末。
最大Logical Channel Group（ＬＣＧ）数が４より大きい数に規定されるＬＣＧのバッファサイズと、インデックスと、の関連付けに基づいて、Buffer Status Report Medium Access Control Control Element（ＢＳＲＭＡＣＣＥ）を生成し、前記ＢＳＲＭＡＣＣＥを含むＭＡＣ Protocol Data Unit（ＰＤＵ）に、ＬＴＥＲｅｌ．１２で利用されていないLogical Channel Identifier（ＬＣＩＤ）を含めるステップと、
前記ＢＳＲＭＡＣＣＥを送信するステップと、を有し、
前記ＢＳＲＭＡＣＣＥは、前記ＬＣＧの前記バッファサイズに対応する前記インデックスを示すバッファサイズフィールドと、前記ＬＣＧを示す３ビットのＬＣＧＩＤフィールドと、を含むことを特徴とする端末の無線通信方法。