(57)【要約】      （修正有）【課題】ユーザ端末に設定可能なコンポーネントキャリア数が既存システムより拡張される場合であっても、通信を適切に行う。【解決手段】複数のコンポーネントキャリア（ＣＣ）を利用して通信するユーザ端末であって、下り共有チャネルの受信の指示情報に対応する下り共有チャネルの受信に関する上り制御情報を送信する送信部と、検出した指示情報及び／又は上位レイヤシグナリングで設定されたＣＣ数に基づいて、既存システムで規定される第１のＰＵＣＣＨ（Physical  Uplink  Control  Channel）フォーマットに比べて容量の大きな第２のＰＵＣＣＨフォーマットを含む複数のＰＵＣＣＨフォーマットから、上り制御情報を送信するＰＵＣＣＨフォーマットを決定する制御部と、を有する。制御部は、検出した指示情報に基づいて、第２のＰＵＣＣＨフォーマットで送信するＰＵＣＣＨリソースを決定する。【選択図】図１１
2017017372.tif 000002
【特許請求の範囲】
【請求項１】
複数のコンポーネントキャリア（ＣＣ：Component  Carrier）を利用して通信するユーザ端末であって、
下り共有チャネルの受信の指示情報を、下り制御チャネルで検出する受信部と、
前記指示情報に対応する下り共有チャネルの受信に関する上り制御情報を送信する送信部と、
検出した指示情報及び／又は上位レイヤシグナリングで設定されたＣＣ数に基づいて、既存システムで規定される第１のＰＵＣＣＨ（Physical  Uplink  Control  Channel）フォーマットに比べて容量の大きな第２のＰＵＣＣＨフォーマットを含む複数のＰＵＣＣＨフォーマットから、前記上り制御情報を送信するＰＵＣＣＨフォーマットを決定する制御部と、を有し、
前記制御部は、検出した指示情報に基づいて、前記第２のＰＵＣＣＨフォーマットで送信するＰＵＣＣＨリソースを決定することを特徴とするユーザ端末。
【請求項２】
前記指示情報は、ＡＲＩ（Acknowledgement  Resource  Indicator）を含み、
前記制御部は、当該ＡＲＩと、ＰＵＣＣＨリソースとＡＲＩとの対応関係と、に基づいて、前記第２のＰＵＣＣＨフォーマットで送信するＰＵＣＣＨリソースを決定することを特徴とする請求項１に記載のユーザ端末。
【請求項３】
前記受信部は、ＰＵＣＣＨリソースとＡＲＩとの対応関係に関する情報として、前記第１のＰＵＣＣＨフォーマットに関するＰＵＣＣＨリソースとＡＲＩとの第１の対応関係に関する情報と、前記第２のＰＵＣＣＨフォーマットに関するＰＵＣＣＨリソースとＡＲＩとの第２の対応関係に関する情報と、を受信し、
前記制御部は、前記ＡＲＩと、前記第２の対応関係と、に基づいて、前記第２のＰＵＣＣＨフォーマットで送信するＰＵＣＣＨリソースを決定することを特徴とする請求項１に記載のユーザ端末。
【請求項４】
前記指示情報は、前記第１の対応関係用のＡＲＩと、前記第２の対応関係用のＡＲＩと、を含み、
前記制御部は、前記指示情報に含まれる一方のＡＲＩと、前記第２の対応関係と、に基づいて、前記第２のＰＵＣＣＨフォーマットで送信するＰＵＣＣＨリソースを決定することを特徴とする請求項３に記載のユーザ端末。
【請求項５】
前記制御部は、前記一方のＡＲＩが所定の値でない場合、前記一方のＡＲＩを用いて前記第２のＰＵＣＣＨフォーマットで送信するＰＵＣＣＨリソースを決定し、前記一方のＡＲＩが所定の値である場合、他方のＡＲＩを用いて前記第１のＰＵＣＣＨフォーマットで送信するＰＵＣＣＨリソースを決定することを特徴とする請求項４に記載のユーザ端末。
【請求項６】
前記指示情報は、スケジュールされる総ＣＣ数に関する情報を含み、
前記制御部は、前記総ＣＣ数が所定の値である場合、前記ＡＲＩと、前記第２の対応関係と、に基づいて、前記第２のＰＵＣＣＨフォーマットで送信するＰＵＣＣＨリソースを決定することを特徴とする請求項３に記載のユーザ端末。
【請求項７】
前記指示情報は、スケジュールされるＣＣを特定するビット列を含み、
前記制御部は、前記ビット列が所定数より多い‘１’を含む場合、前記ＡＲＩと、前記第２の対応関係と、に基づいて、前記第２のＰＵＣＣＨフォーマットで送信するＰＵＣＣＨリソースを決定することを特徴とする請求項３に記載のユーザ端末。
【請求項８】
複数のコンポーネントキャリア（ＣＣ：Component  Carrier）を利用するユーザ端末と通信する無線基地局であって、
下り共有チャネルの受信の指示情報を、下り制御チャネルで送信する送信部と、
前記指示情報に対応する下り共有チャネルの受信に関する上り制御情報を受信する受信部と、
前記上り制御情報を送信するＰＵＣＣＨリソースを制御する制御部と、を有し、
前記ＰＵＣＣＨリソースは、既存システムで規定される第１のＰＵＣＣＨ（Physical  Uplink  Control  Channel）フォーマットに比べて容量の大きな第２のＰＵＣＣＨフォーマットで送信されるＰＵＣＣＨリソースを含み、
前記指示情報は、前記ユーザ端末において、前記第２のＰＵＣＣＨフォーマットで送信するＰＵＣＣＨリソースの決定に用いられることを特徴とする無線基地局。
【請求項９】
複数のコンポーネントキャリア（ＣＣ：Component  Carrier）を利用して通信するユーザ端末に関する無線通信方法であって、
下り共有チャネルの受信の指示情報を、下り制御チャネルで検出する工程と、
前記指示情報に対応する下り共有チャネルの受信に関する上り制御情報を送信する工程と、
検出した指示情報及び／又は上位レイヤシグナリングで設定されたＣＣ数に基づいて、既存システムで規定される第１のＰＵＣＣＨ（Physical  Uplink  Control  Channel）フォーマットに比べて容量の大きな第２のＰＵＣＣＨフォーマットを含む複数のＰＵＣＣＨフォーマットから、前記上り制御情報を送信するＰＵＣＣＨフォーマットを決定する工程と、を有し、
前記第２のＰＵＣＣＨフォーマットで送信するＰＵＣＣＨリソースは、検出した指示情報に基づいて決定されることを特徴とする無線通信方法。
【請求項１０】
複数のコンポーネントキャリア（ＣＣ：Component  Carrier）を利用して通信するユーザ端末を含む無線通信システムであって、
前記ユーザ端末は、下り共有チャネルの受信の指示情報を、下り制御チャネルで検出する受信部と、
前記指示情報に対応する下り共有チャネルの受信に関する上り制御情報を送信する送信部と、
検出した指示情報及び／又は上位レイヤシグナリングで設定されたＣＣ数に基づいて、既存システムで規定される第１のＰＵＣＣＨ（Physical  Uplink  Control  Channel）フォーマットに比べて容量の大きな第２のＰＵＣＣＨフォーマットを含む複数のＰＵＣＣＨフォーマットから、前記上り制御情報を送信するＰＵＣＣＨフォーマットを決定する制御部と、を有し、
前記制御部は、検出した指示情報に基づいて、前記第２のＰＵＣＣＨフォーマットで送信するＰＵＣＣＨリソースを決定することを特徴とする無線通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、次世代移動通信システムにおけるユーザ端末、無線基地局、無線通信方法及び無線通信システムに関する。
【背景技術】
【０００２】
ＵＭＴＳ（Universal  Mobile  Telecommunications  System）ネットワークにおいて、さらなる高速データレート、低遅延などを目的としてロングタームエボリューション（ＬＴＥ：Long  Term  Evolution）が仕様化された（非特許文献１）。また、ＬＴＥからの更なる広帯域化及び高速化を目的として、ＬＴＥの後継システム（例えば、ＬＴＥ−Ａ（LTE-Advanced）、ＦＲＡ（Future  Radio  Access）などと呼ばれる）も検討されている。
【０００３】
ＬＴＥ−Ａ（ＬＴＥ  Ｒｅｌ．１０−１２）の広帯域化技術の１つは、キャリアアグリゲーション（ＣＡ：Carrier  Aggregation）である。ＣＡによれば、複数の基本周波数ブロックを一体として通信に用いることができる。ＣＡにおける基本周波数ブロックは、コンポーネントキャリア（ＣＣ：Component  Carrier）と呼ばれ、ＬＴＥ  Ｒｅｌ．８のシステム帯域に相当する。
【０００４】
また、ＬＴＥ／ＬＴＥ−Ａでは、再送制御にＨＡＲＱ（Hybrid  Automatic  Repeat  reQuest）が利用されている。ＨＡＲＱでは、データの受信を割り当てられた（スケジューリングされた、スケジュールされた）ユーザ端末（ＵＥ：User  Equipment）が、当該データに関する送達確認信号（ＨＡＲＱ−ＡＣＫ）をネットワーク側の装置（例えば、無線基地局（ｅＮＢ））に対して通知する。無線基地局は、ＨＡＲＱ−ＡＣＫに基づいて、データの再送を行うべきか判断する。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】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）を利用して通信するユーザ端末であって、下り共有チャネルの受信の指示情報を、下り制御チャネルで検出する受信部と、前記指示情報に対応する下り共有チャネルの受信に関する上り制御情報を送信する送信部と、検出した指示情報及び／又は上位レイヤシグナリングで設定されたＣＣ数に基づいて、既存システムで規定される第１のＰＵＣＣＨ（Physical  Uplink  Control  Channel）フォーマットに比べて容量の大きな第２のＰＵＣＣＨフォーマットを含む複数のＰＵＣＣＨフォーマットから、前記上り制御情報を送信するＰＵＣＣＨフォーマットを決定する制御部と、を有し、前記制御部は、検出した指示情報に基づいて、前記第２のＰＵＣＣＨフォーマットで送信するＰＵＣＣＨリソースを決定する。
【発明の効果】
【００１０】
本発明によれば、ユーザ端末に設定可能なコンポーネントキャリア数が既存システムより拡張される場合であっても、通信を適切に行うことができる。
【図面の簡単な説明】
【００１１】
【図１】第１の実施形態に係るＰＵＣＣＨフォーマットの切り替えの一例を示す図である。
【図２】実施形態１．３と実施形態２．１とを組み合わせて用いる場合の一例を示す。
【図３】実施形態１．１又は１．２と実施形態２．１とを組み合わせて用いる場合の一例を示す。
【図４】実施形態２．２の一例を示す。
【図５】実施形態２．３の一例を示す。
【図６】スケジューリングされたＣＣの数とＴｏｔａｌ  ＤＡＩとの関係の一例を示す図である。
【図７】第３の実施形態の一例を示す図である。
【図８】スケジューリングされたＣＣの数とビットマップとの関係の一例を示す図である。
【図９】第４の実施形態の一例を示す図である。
【図１０】本発明の一実施形態に係る無線通信システムの概略構成の一例を示す図である。
【図１１】本発明の一実施形態に係る無線基地局の全体構成の一例を示す図である。
【図１２】本発明の一実施形態に係る無線基地局の機能構成の一例を示す図である。
【図１３】本発明の一実施形態に係るユーザ端末の全体構成の一例を示す図である。
【図１４】本発明の一実施形態に係るユーザ端末の機能構成の一例を示す図である。
【発明を実施するための形態】
【００１２】
まず、既存のＬＴＥシステム（Ｒｅｌ．１０−１２）におけるＨＡＲＱ−ＡＣＫについて説明する。Ｒｅｌ．１０−１２では、最大５ＣＣまでのＣＡが導入されている。最大５ＣＣのＨＡＲＱフィードバックを可能とするため、ＨＡＲＱ−ＡＣＫについて多くのビット（ＦＤＤ（Frequency  Division  Duplex）では最大１０ビット、ＴＤＤ（Time  Division  Duplex）では最大２１ビット）送信可能なＰＵＣＣＨフォーマット３が規定された。
【００１３】
ＰＵＣＣＨフォーマット１ａ／１ｂが設定されたユーザ端末は、下り共有チャネル（ＰＤＳＣＨ：Physical  Downlink  Shared  Channel）をスケジューリングする下り制御チャネル（ＰＤＣＣＨ（Physical  Downlink  Control  Channel）／ＥＰＤＣＣＨ（Enhanced  PDCCH））のＣＣＥ／ＥＣＣＥ（Control  Channel  Element／Enhanced  CCE）インデックスに対応するＰＵＣＣＨリソース（例えば、周波数及び／又は符号リソース）で、ＨＡＲＱ−ＡＣＫを送信する。
【００１４】
また、ＰＵＣＣＨフォーマット３が設定されたユーザ端末は、ＳＣｅｌｌ（Secondary  Cell）をスケジューリングするＰＤＣＣＨ／ＥＰＤＣＣＨのＤＣＩ（Downlink  Control  Information）に含まれるＴＰＣ（Transmit  Power  Control）コマンドビットを、ＡＲＩ（ACK/NACK  Resource  Indicator）として読み替え、上位レイヤシグナリング（例えば、ＲＲＣシグナリング）で設定された４つのリソースのうち、ＡＲＩが指定するいずれか１つのＰＵＣＣＨリソースで、ＨＡＲＱ−ＡＣＫを送信する。
【００１５】
ＡＲＩの値は、異なるＣＣのＰＤＳＣＨをスケジューリングするＰＤＣＣＨ／ＥＰＤＣＣＨで同一とすることが好ましい。また、ＳＣｅｌｌのＰＤＳＣＨをスケジューリングするＰＤＣＣＨ／ＥＰＤＣＣＨが検出されない（ＰＣｅｌｌ（Primary  Cell）のスケジューリングのみが検出された）場合には、ＰＣｅｌｌのＰＤＳＣＨをスケジューリングするＰＤＣＣＨ／ＥＰＤＣＣＨのＣＣＥ／ＥＣＣＥインデックスに一対一対応するＰＵＣＣＨリソースで、ＨＡＲＱ−ＡＣＫを送信する。
【００１６】
ところで、ＬＴＥ  Ｒｅｌ．１３では、６個以上のＣＣ（５個を超えるＣＣ）を設定するＣＡ（拡張ＣＡ、Ｒｅｌ．１３  ＣＡなどともいう）が検討されている。例えば、Ｒｅｌ．１３  ＣＡでは、最大３２個までのＣＣを束ねることが検討されている。
【００１７】
既存のＰＵＣＣＨフォーマット（例えば、ＰＵＣＣＨフォーマット３）では、３２ＣＣ分のＨＡＲＱ−ＡＣＫを送信することはできない。そこで、Ｒｅｌ．１３では、送信可能なビット数が大きい新規ＰＵＣＣＨフォーマット（new  PUCCH  format）を規定することが検討されている。なお、新規ＰＵＣＣＨフォーマットは、ＰＵＣＣＨフォーマット４、大容量ＰＵＣＣＨフォーマット、拡張ＰＵＣＣＨフォーマット、新フォーマットなどと呼ばれてもよい。
【００１８】
新規ＰＵＣＣＨフォーマットでは、例えば、（１）最大で所定のビット数（例えば、１２８ビット）以上のＨＡＲＱ−ＡＣＫを格納すること、（２）ＨＡＲＱ−ＡＣＫビットが所定のビット数（例えば、２２ビット）以上のとき、ＣＲＣを付加すること、（３）ＨＡＲＱ−ＡＣＫビットが所定のビット数（例えば、２２ビット）以上のとき、ＴＢＣＣ（Tail-Biting  Convolutional  Code）とレートマッチングを適用すること、などが検討されている。
【００１９】
しかしながら、どのような場合に新規ＰＵＣＣＨフォーマットを用いて送信するか、新規ＰＵＣＣＨフォーマットのリソース割り当てをどのようにユーザ端末が判断するか、などについては、これまで検討されていない。このため、巨大な新規ＰＵＣＣＨフォーマットを利用する場合には、適切な制御を行わなければ、周波数利用効率が劣化し、拡張ＣＡによるスループット向上効果が好適に達成されなくなるおそれがある。
【００２０】
そこで、本発明者らは、ＬＴＥ  Ｒｅｌ．１３以降において、６個以上のＣＣ（例えば、３２個のＣＣ）を用いるＣＡに適したＨＡＲＱ−ＡＣＫフィードバックを可能とするために、既存システムのＰＵＣＣＨフォーマットより送信可能なビット数の大きい新規ＰＵＣＣＨフォーマットについて、利用可否の判断方法やリソース指定方法を見出した。
【００２１】
以下、本発明に係る実施形態について説明する。各実施形態ではユーザ端末が最大３２ＣＣを用いるＣＡを設定される場合の例について説明するが、本発明の適用はこれに限られるものではない。例えば、５個以下のＣＣを用いるＣＡを設定される場合であっても、各実施形態で説明する方法を適用することができる。
【００２２】
（第１の実施形態：Ｒｅｌ．１３  ＣＡ向けＰＵＣＣＨフォーマット切り替え方法）
本発明の第１の実施形態では、Ｒｅｌ．１３  ＣＡ向けのＰＵＣＣＨフォーマット切り替え方法について説明する。
【００２３】
本発明者らは、新規ＰＵＣＣＨフォーマットはペイロードが大きいことから、既存ＰＵＣＣＨフォーマットと比べて、ＣＤＭ（Code  Division  Multiplexing）によるユーザ多重数が少ない、所要ＳＩＮＲ（Signal-to-Interference  plus  Noise  Ratio）が大きい、所要ＰＲＢ（Physical  Resource  Block）数が多い、などといった制約が発生する可能性が高いことに着目した。このため、データが少ないＵＥは、できるだけ既存ＰＵＣＣＨフォーマットで送信させる方が望ましく、データがスケジューリングされるＣＣ数が多いときにペイロードの大きなフォーマットで送信されるように切り替えを行うことを着想し、本実施形態を見出した。ただし、切り替えの方針はこれに限られるものではない。
【００２４】
具体的には、本発明者らは、ＰＤＳＣＨを割り当てるＰＤＣＣＨ／ＥＰＤＣＣＨの検出状況（数）に応じて、送信するＰＵＣＣＨフォーマットを決定することを見出した。例えば、ＰＤＳＣＨを割り当てるＰＤＣＣＨ／ＥＰＤＣＣＨの数に基づく制御（実施形態１．１）と、ＰＤＳＣＨが割り当てられるＣＣのＣＣ番号に基づく制御（実施形態１．２）と、を見出した。また、本発明者らは、上位レイヤで設定されたＣＣ数に応じて、送信するＰＵＣＣＨフォーマットを決定することを見出した（実施形態１．３）。
【００２５】
図１は、第１の実施形態に係るＰＵＣＣＨフォーマットの切り替えの一例を示す図である。図１Ａ−図１Ｃは、それぞれ実施形態１．１−１．３に対応する。本例では、無線基地局（単に基地局ともいう）は、ＵＥに６ＣＣを設定（configure）し、ＣＣ＃０−＃５の少なくとも１つにＰＤＳＣＨのスケジューリングを行っている。以下では、図１を適宜参照して、第１の実施形態を詳細に説明する。
【００２６】
＜実施形態１．１＞
実施形態１．１では、ＰＤＳＣＨを割り当てるＰＤＣＣＨ／ＥＰＤＣＣＨの検出数に応じて、送信するＰＵＣＣＨフォーマットを制御する。ＰＤＳＣＨを割り当てるＰＤＣＣＨ／ＥＰＤＣＣＨの検出数として、検出したＰＤＣＣＨ／ＥＰＤＣＣＨによりスケジューリングされたＣＣ数が用いられてもよい。例えば、図１Ａに示すように、ＳＣｅｌｌを含む２ＣＣ以上５ＣＣ以下のスケジューリングが検出されたならば、ＰＵＣＣＨフォーマット３を用いて、それ以上のスケジューリングが検出されたならば、新規ＰＵＣＣＨフォーマットを用いる。
【００２７】
具体的には、ＵＥは、ＰＣｅｌｌのみのスケジューリングを検出した場合、ＰＵＣＣＨフォーマット１ａ／１ｂで送信する（既存と同じ動作）。また、ＵＥは、ＳＣｅｌｌを含む任意の５ＣＣ以下のスケジューリングを検出した場合、ＰＵＣＣＨフォーマット３で送信する。さらに、ＵＥは、ＳＣｅｌｌを含む任意の６ＣＣ以上のスケジューリングを検出した場合、新規ＰＵＣＣＨフォーマットで送信する。
【００２８】
＜実施形態１．２＞
実施形態１．２では、スケジューリングされたＣＣに応じて、送信するＰＵＣＣＨフォーマットを制御する。図１Ｂに示すように、ＣＣ数に基づくのではなく、スケジューリングされたＣＣがどのＣＣかに基づく点が、実施形態１．１と異なる。なお、ＣＣは、例えば、スケジューリングされたＣＣのＣＣ番号や、ＳＣｅｌｌ番号（SCell  index）などにより、特定することができる。
【００２９】
具体的には、ＵＥは、ＰＣｅｌｌ（ＣＣ＃０）のみのスケジューリングを検出した場合、ＰＵＣＣＨフォーマット１ａ／１ｂで送信する（既存と同じ動作）。また、ＵＥは、ＣＣ＃０−ＣＣ＃４のみに対するスケジューリングを検出した場合、ＰＵＣＣＨフォーマット３で送信する。さらに、ＵＥは、ＣＣ＃５以上に対するスケジューリングを検出した場合、新規ＰＵＣＣＨフォーマットで送信する。
【００３０】
＜実施形態１．３＞
実施形態１．３では、設定されたＣＣ数に応じて、送信するＰＵＣＣＨフォーマットを制御する。図１Ｃに示すように、ＵＥは、上位レイヤシグナリング（例えば、ＲＲＣシグナリング）などで準静的に通知されたＣＣ数に基づいて、ＵＥはＰＵＣＣＨフォーマットを判断する。例えば、ＵＥは、上位レイヤシグナリングで３２ＣＣを設定された場合、新規ＰＵＣＣＨフォーマットを用いることができると判断してもよい。
【００３１】
具体的には、ＵＥは、ＰＣｅｌｌのみのスケジューリングを検出した場合、ＰＵＣＣＨフォーマット１ａ／１ｂで送信する（既存と同じ動作）。また、任意のＳＣｅｌｌでスケジューリングを検出した場合、新規ＰＵＣＣＨフォーマットで送信する。つまり、実施形態１．３では、ＰＵＣＣＨフォーマット３では送信を行わない。
【００３２】
なお、実施形態１．３において、ＣＣ数の代わりに、上位レイヤシグナリングで通知される新規ＰＵＣＣＨフォーマットの使用可否に関する情報（例えば、１ビットで表現され、‘１’が新規ＰＵＣＣＨフォーマットを使用可能を表す、または、ＨＡＲＱ−ＡＣＫの送信に新規ＰＵＣＣＨフォーマットを用いることを明示する情報）に基づいて、ＵＥは新規ＰＵＣＣＨフォーマットを用いることができると判断してもよい。当該上位レイヤシグナリングには、新規ＰＵＣＣＨフォーマットを送信する帯域幅（例えば、ＰＲＢ数）、変調方式、符号化方式などが含まれていてもよい。
【００３３】
以上、第１の実施形態によれば、５ＣＣより多いＣＣのＣＡを適用する場合であっても、ＵＥが適切なＰＵＣＣＨフォーマットを動的に選択してＨＡＲＱ−ＡＣＫを送信することができる。
【００３４】
なお、第１の実施形態において、ＰＤＳＣＨを割り当てるＰＤＣＣＨ／ＥＰＤＣＣＨの検出状況（数）や設定されたＣＣ数に応じて、ＰＵＣＣＨフォーマットを切り替えるとともに／切り替える代わりに、ＨＡＲＱ−ＡＣＫのコードブック（Ａ／Ｎビット列）サイズを切り替えてもよい。
【００３５】
さて、本発明者らは、上述の第１の実施形態を検討するなかで、新規ＰＵＣＣＨフォーマットを用いるときのＰＵＣＣＨリソース指定方法にさらに着目した。本発明者らは、第１の実施形態のような、ＵＥがＰＵＣＣＨフォーマットを動的に切り替えて用いる場合に、ＰＤＣＣＨ／ＥＰＤＣＣＨ検出ミスが発生すると、無線基地局とＵＥとの間で、ＰＵＣＣＨフォーマット、Ａ／Ｎビット数などの認識がずれる可能性があることを発見した。ＵＥはＡ／Ｎビット列に対して符号化を行い、無線基地局は復号を行うところ、上記の認識がずれると復号を正しく行うことが出来なくなり、Ａ／Ｎ性能が著しく劣化するという問題が発生する。
【００３６】
以上の着目に基づいて、本発明者らは、上記Ｒｅｌ．１３  ＣＡ向けのＰＵＣＣＨフォーマット切り替え方法に適したＰＵＣＣＨリソース指定方法を見出した。以下の実施形態では、ＰＵＣＣＨリソース指定方法について詳細に説明する。
【００３７】
（第２の実施形態：ＡＲＩによるＲｅｌ．１３  ＣＡ向けＰＵＣＣＨリソース指定方法）
第２の実施形態では、Ｒｅｌ．１３  ＣＡ向けＰＵＣＣＨリソースの割り当てについて説明する。第２の実施形態はいくつかの方法を含むが、ＳＣｅｌｌのＰＤＳＣＨをスケジューリングするＰＤＣＣＨ／ＥＰＤＣＣＨに含まれる所定のビット列（例えば、ＴＰＣコマンド）をＡＲＩと解釈する点はいずれの方法でも共通している。
【００３８】
また、上位レイヤシグナリングで設定される、ＡＲＩとＰＵＣＣＨリソースとの対応関係（ＡＲＩリソーステーブル、ＡＲＩテーブル、ＰＵＣＣＨテーブルなどと呼ばれてもよい）に基づいて、ＡＲＩが指定するいずれかのＰＵＣＣＨリソースを選択する点も共通している。ここで、当該対応関係では、１つ又は複数（例えば、４つ）のリソースが別々のＡＲＩに対応している。
【００３９】
第２の実施形態には、ＰＤＣＣＨ／ＥＰＤＣＣＨに１つのＡＲＩを含み、当該ＡＲＩと、所定のＡＲＩテーブルと、を用いて新規ＰＵＣＣＨフォーマットのリソースを決定する方法がある（実施形態２．１）。
【００４０】
また、第２の実施形態には、ＰＤＣＣＨ／ＥＰＤＣＣＨに１つのＡＲＩを含み、当該ＡＲＩと、他のＰＵＣＣＨフォーマット（例えば、ＰＵＣＣＨフォーマット３）と独立して設定されるＡＲＩテーブルと、を用いて新規ＰＵＣＣＨフォーマットのリソースを決定する方法がある（実施形態２．２）。
【００４１】
また、第２の実施形態には、ＰＤＣＣＨ／ＥＰＤＣＣＨに複数のＡＲＩを含み、いずれかのＡＲＩと、他のＰＵＣＣＨフォーマット（例えば、ＰＵＣＣＨフォーマット３）と独立して設定されるＡＲＩテーブルと、を用いて新規ＰＵＣＣＨフォーマットのリソースを決定する方法がある（実施形態２．３）。
【００４２】
＜実施形態２．１＞
実施形態２．１では、ＵＥは、ＳＣｅｌｌのＰＤＳＣＨをスケジューリングするＰＤＣＣＨ／ＥＰＤＣＣＨに含まれる所定のビット列（例えば、ＴＰＣコマンド）をＡＲＩと解釈し、ＡＲＩテーブルに基づいて当該ＡＲＩが指定するＰＵＣＣＨリソースを選択して、新規ＰＵＣＣＨフォーマットで送信を行う。なお、当該ＡＲＩテーブルは、他のＰＵＣＣＨフォーマット（例えば、ＰＵＣＣＨフォーマット３）と共通で用いられるＡＲＩテーブルとしてもよい。
【００４３】
実施形態１．３に実施形態２．１を適用すると、既存ＣＡでＰＵＣＣＨフォーマット３が設定された場合と同様の制御動作となるため、ＵＥの制御が過度に複雑化することを防止することができる。しかしながら、実際には、ＵＥはＰＤＣＣＨ／ＥＰＤＣＣＨの検出をミスすることがある。検出ミスが生じた場合のＵＥの挙動について、図２を参照して説明する。
【００４４】
図２は、実施形態１．３と実施形態２．１とを組み合わせて用いる場合の一例を示す。本例では、基地局は６ＣＣを設定し、ＣＣ＃０／＃１／＃２にスケジューリングを行っている。ＣＣ＃０／＃１／＃２の各ＰＤＳＣＨに対応するＰＤＣＣＨ／ＥＰＤＣＣＨを正常に検出した場合は、ＣＣ＃１及び＃２をスケジューリングするＤＣＩのＴＰＣフィールドをＡＲＩと認識して、当該ＡＲＩが指定するＰＵＣＣＨリソースを用いて新規ＰＵＣＣＨフォーマットで送信が行われる。
【００４５】
しかしながら、ＵＥがＰＣｅｌｌに対するＰＤＣＣＨ／ＥＰＤＣＣＨしか検出できない場合（ＣＣ＃１及びＣＣ＃２に対するＰＤＣＣＨ／ＥＰＤＣＣＨを検出ミスした場合）、ＰＣｅｌｌでＰＵＣＣＨフォーマット１ａ／１ｂが送信される。
【００４６】
したがって、基地局は、ＵＥに対してＳＣｅｌｌにＰＤＳＣＨを割り当てる場合には、ＰＵＣＣＨが送信される可能性のある複数のＰＵＣＣＨリソースの検出動作を試みることが好ましい。具体的には、基地局は、ＡＲＩで指定する新規ＰＵＣＣＨフォーマットのＰＵＣＣＨリソースと、ＰＣｅｌｌのＰＤＳＣＨを割り当てるＰＤＣＣＨのＣＣＥインデックス／ＥＰＤＣＣＨのＥＣＣＥインデックスに対応するＰＵＣＣＨフォーマット１ａ／１ｂのＰＵＣＣＨリソース両方を当該ＵＥ用に予約しておき、両方で検出動作を行うことが望ましい。
【００４７】
なお、ＡＲＩは、ＴＰＣコマンド以外のフィールドで表されてもよい。例えば、ＡＲＩは、既存システムのＤＣＩで規定される任意のフィールドの全部又は一部で表されてもよいし、新たなフィールドで表されてもよい。また、ＤＣＩのどのフィールドがＡＲＩを示すかに関する情報は、上位レイヤシグナリング（例えば、ＲＲＣシグナリング、報知情報）などでユーザ端末に通知されてもよい。
【００４８】
実施形態１．１又は１．２に実施形態２．１を適用すると、ＡＲＩが複数のＰＵＣＣＨフォーマットに解釈され得る。本発明者らは、この場合、ＵＥがＡＲＩに基づいて適切にＰＵＣＣＨリソースを判断できない問題があることに着目した。当該問題について、図３を参照して説明する。
【００４９】
図３は、実施形態１．１又は１．２と実施形態２．１とを組み合わせて用いる場合の一例を示す。本例では、基地局は６ＣＣを設定し、ＣＣ＃０−＃５全てにスケジューリングを行っている。ＣＣ＃０−＃５の各ＰＤＳＣＨに対応するＰＤＣＣＨ／ＥＰＤＣＣＨを正常に検出した場合は、ＵＥはＣＣ＃１−＃５をスケジューリングするＤＣＩが含むＡＲＩに基づいて、当該ＡＲＩが指定するＰＵＣＣＨリソースを用いて新規ＰＵＣＣＨフォーマットで送信を行う。
【００５０】
しかしながら、ＵＥがＣＣ＃５を検出ミスした場合、ＵＥはＣＣ＃１−＃４をスケジューリングするＤＣＩが含むＡＲＩに基づいて、当該ＡＲＩが指定するＰＵＣＣＨリソースを用いてＰＵＣＣＨフォーマット３で送信を行う。また、ＵＥは、ＰＣｅｌｌをスケジューリングするＤＣＩしか検出できない場合（ＣＣ＃１−＃５に対するＤＣＩを検出ミスした場合）、ＰＣｅｌｌでＰＵＣＣＨフォーマット１ａ／１ｂを送信する。
【００５１】
したがって、ＵＥはＡＲＩを受信した場合であっても、当該ＡＲＩがＰＵＣＣＨフォーマット３のＡＲＩなのか、新規ＰＵＣＣＨフォーマットのＡＲＩなのか、を認識（区別）することができない。
【００５２】
そこで、本発明者らは、ＡＲＩとＰＵＣＣＨリソースとの対応関係を、ＰＵＣＣＨフォーマットごとに設定することを着想し、ＵＥがＰＵＣＣＨフォーマットに応じて、利用する対応関係を特定する形態（実施形態２．２）と、無線基地局がＵＥに複数のＡＲＩを通知して、利用する対応関係を指定する形態（実施形態２．３）と、を見出した。
【００５３】
実施形態２．２及び２．３では、ＵＥは、ＰＵＣＣＨフォーマット３で送信する場合と、新規ＰＵＣＣＨフォーマットで送信する場合とで、それぞれ異なるＡＲＩテーブルに基づいてＰＵＣＣＨリソースを決定する。各ＡＲＩテーブルは、それぞれ上位レイヤシグナリング（例えば、ＲＲＣシグナリング）によって独立に設定することができる。
【００５４】
ＵＥは、新規ＰＵＣＣＨフォーマットで送信する場合、一方のテーブル（例えば、Ｔａｂｌｅ  Ｘ）とＡＲＩの値とに基づき新規ＰＵＣＣＨフォーマットで送信するリソースを決定する。また、ＵＥは、ＰＵＣＣＨフォーマット３で送信する場合、別のテーブル（例えば、Ｔａｂｌｅ  Ｘと異なるＴａｂｌｅ  Ｙ）とＡＲＩの値とに基づきＰＵＣＣＨフォーマット３で送信するリソースを決定する。
【００５５】
＜実施形態２．２＞
実施形態２．２においては、ＵＥは、送信に用いるＰＵＣＣＨフォーマットを所定の方法に基づいて選択する。例えば、ＵＥは、第１の実施形態の方法１に従って、利用するフォーマットを判断してもよい。実施形態２．２では、検出したＰＤＣＣＨ／ＥＰＤＣＣＨの数やスケジューリングされるＣＣ、ＰＵＣＣＨフォーマットの種類などによって、異なるテーブルを参照して、ＡＲＩに対応したリソースを決定する。
【００５６】
図４は、実施形態２．２の一例を示す。本例では、図４Ａのように、基地局は６ＣＣを設定し、ＣＣ＃０−＃５全てにスケジューリングを行っている。ＣＣ＃０−＃５の各ＰＤＳＣＨに対応するＰＤＣＣＨ／ＥＰＤＣＣＨを正常に検出した場合は、ＵＥはＣＣ＃１−＃５をスケジューリングするＤＣＩが含むＡＲＩに基づいて、当該ＡＲＩが指定するＰＵＣＣＨリソースを用いて新規ＰＵＣＣＨフォーマットで送信を行う。
【００５７】
図４Ｂの左側の表は、ＰＵＣＣＨフォーマット３に関するＰＵＣＣＨリソースとＡＲＩとの対応関係（ＰＵＣＣＨフォーマット３用のＡＲＩテーブル）を示し、図４Ｂの右側の表は、新規ＰＵＣＣＨフォーマットに関するＰＵＣＣＨリソースとＡＲＩとの対応関係（新規ＰＵＣＣＨフォーマット用のＡＲＩテーブル）を示している。各ＡＲＩテーブルでは、上位レイヤシグナリングにより各ＡＲＩに対応するＰＵＣＣＨリソースを設定可能である。ここで、両ＡＲＩテーブルで同じＡＲＩに対応するＰＵＣＣＨリソースであっても、異なるリソースを設定してもよい。
【００５８】
図４においては、ＵＥは、６ＣＣに対応するＰＤＣＣＨ／ＥＰＤＣＣＨを正常に検出すると、利用するＰＵＣＣＨフォーマットが新規ＰＵＣＣＨフォーマットであると決定し、ＤＣＩに含まれるＡＲＩに対応したＰＵＣＣＨリソースを用いて、新規ＰＵＣＣＨフォーマットで送信する。例えば、ＡＲＩが“０１”である場合、新規ＰＵＣＣＨフォーマットで送信するＰＵＣＣＨリソースを、図４Ｂの新規ＰＵＣＣＨフォーマット用のＡＲＩテーブルにおける第２のＰＵＣＣＨリソースであると判断することができる。
【００５９】
実施形態２．２では、基地局は、ＵＥがＰＵＣＣＨフォーマット３と新規ＰＵＣＣＨフォーマットのいずれで送信を行うかを事前に判断できないため、２つのＡＲＩテーブルにおいて、ＤＣＩで通知するＡＲＩに対応する各リソースを当該ＵＥに予約した上で、これらのリソースの受信検出を試みることが好ましい。また、上記２つのリソースだけではなく、ＰＵＣＣＨフォーマット１ａ／１ｂのＰＵＣＣＨリソースで受信検出を試みてもよい。
【００６０】
以上説明したように、実施形態２．２によれば、複数のＰＵＣＣＨフォーマット（フォーマット３及び新規フォーマット）のリソースを、別々の独立な上位レイヤシグナリングで設定できるため、基地局の設定自由度を高くすることができる（スケジューリングが容易となる）。
【００６１】
＜実施形態２．３＞
実施形態２．３では、ＰＤＳＣＨを指示するＤＣＩに、複数（例えば、２つ）のＡＲＩを含める。この場合、ＵＥは、送信するＰＵＣＣＨフォーマットを複数のＡＲＩのいずれか又は全てに基づいて選択することができる。
【００６２】
例えば、ＤＣＩに２つのＡＲＩ（新規ＰＵＣＣＨフォーマット用のＡＲＩ及びＰＵＣＣＨフォーマット３用のＡＲＩ）を含める場合、新規ＰＵＣＣＨフォーマット用のＡＲＩは、所定の値（例えば“００”）が「新規ＰＵＣＣＨフォーマットで送信しない」ことを指示するように設定されてもよい。新規ＰＵＣＣＨフォーマットで送信しないことを指示できるようにすることで、基地局が５ＣＣ以下にしかスケジューリングしていないにもかかわらず、端末が実際には送信されていないＰＤＣＣＨ／ＥＰＤＣＣＨを誤検出し、新規ＰＵＣＣＨフォーマットの送信を行うケースを防止できる。
【００６３】
換言すれば、基地局は、スケジューリングするＣＣが５ＣＣ以下の場合には、当該ＡＲＩにより「新規ＰＵＣＣＨフォーマットで送信しない」よう指示することで複数のＰＵＣＣＨフォーマットの送信可能性をなくすことができ、受信処理を簡易化することが可能となる。このように、新規ＰＵＣＣＨフォーマット用のＡＲＩ及びＰＵＣＣＨフォーマット３用のＡＲＩとしては、異なる値をＤＣＩに含めることができる。
【００６４】
基地局は、所定のＵＥに新規ＰＵＣＣＨフォーマット用のリソースを割り当てる場合、新規ＰＵＣＣＨフォーマット用のＡＲＩを、割り当てるリソースに対応した値（所定の値（例えば“００”）以外の値）に設定する。この場合、基地局は、ＰＵＣＣＨフォーマット３用のＡＲＩは任意の値に設定してもよい。
【００６５】
基地局は、所定のＵＥにＰＵＣＣＨフォーマット３用のリソースを割り当てる場合、ＰＵＣＣＨフォーマット３用のＡＲＩを、割り当てるリソースに対応した値に設定する。また、基地局は、新規ＰＵＣＣＨフォーマット用のＡＲＩを、所定の値（例えば“００”）とする。
【００６６】
また、基地局は、所定のＵＥに割り当てるリソースの受信検出を試みる。この場合、割り当てていないフォーマットのリソースは受信検出を試みなくてよい。また、所定のＵＥに割り当てるリソースに加えて、ＰＵＣＣＨフォーマット１ａ／１ｂに対応するＰＵＣＣＨリソースで受信検出を試みてもよい。
【００６７】
ＵＥは、ＳＣｅｌｌをスケジューリングするＤＣＩを検出すると、新規ＰＵＣＣＨフォーマット用のＡＲＩを参照し、所定の値か否かを判断する。ＵＥは、受信したＤＣＩに含まれる新規ＰＵＣＣＨフォーマット用のＡＲＩが、所定の値（例えば、“００”）以外であれば、当該ＡＲＩが指示するＰＵＣＣＨリソースを用いて新規ＰＵＣＣＨフォーマットで送信し、新規ＰＵＣＣＨフォーマット用のＡＲＩが、所定の値であれば、ＰＵＣＣＨフォーマット３用のＡＲＩが指示するＰＵＣＣＨリソースを用いてＰＵＣＣＨフォーマット３で送信する。
【００６８】
図５は、実施形態２．３の一例を示す。本例では、図５Ａのように、基地局は６ＣＣを設定し、ＣＣ＃０−＃５全てにスケジューリングを行っている。ＳＣｅｌｌ（ＣＣ＃１−＃５）をスケジューリングするＤＣＩには、それぞれ２つのＡＲＩが含まれる。図５Ａでは、ＰＵＣＣＨフォーマット３用のＡＲＩ（１ｓｔ  ＡＲＩ）として“０１”が設定され、新規ＰＵＣＣＨフォーマット用のＡＲＩ（２ｎｄ  ＡＲＩ）として“１０”が設定されている。なお、各ＤＣＩに含まれるＡＲＩは、ＣＣが異なっても同じＡＲＩである。
【００６９】
図５Ｂの左側の表は、ＰＵＣＣＨフォーマット３用のＡＲＩテーブルを示し、図５Ｂの右側の表は、新規ＰＵＣＣＨフォーマット用のＡＲＩテーブルを示している。各ＡＲＩテーブルでは、上位レイヤシグナリングにより各ＡＲＩに対応するＰＵＣＣＨリソースを設定可能である。ここで、両ＡＲＩテーブルで同じＡＲＩに対応するＰＵＣＣＨリソースには、異なるリソースを設定してもよいし、同じリソースを設定してもよい。
【００７０】
図５Ｂでは、新規ＰＵＣＣＨフォーマット用のＡＲＩテーブルにおいて、ＡＲＩ＝“００”が「新規ＰＵＣＣＨフォーマットで送信しない」ことを示すように設定され、ＡＲＩ＝“００”以外は、新規ＰＵＣＣＨフォーマット用の無線リソースを示すように設定されている。
【００７１】
ＵＥは、少なくとも１つのＳＣｅｌｌ（ＣＣ＃１−ＣＣ＃５）をスケジューリングするＤＣＩを検出した場合、当該ＤＣＩに含まれる２つのＡＲＩを抽出する。図５では、新規ＰＵＣＣＨフォーマット用のＡＲＩが“１０”であるため、新規ＰＵＣＣＨフォーマットのＡＲＩ＝“１０”に対応するリソース（新規ＰＵＣＣＨフォーマット用のＡＲＩテーブルにおける第３のＰＵＣＣＨリソース）で、新規ＰＵＣＣＨフォーマットで送信する。
【００７２】
以上説明したように、実施形態２．３では、基地局は、ＵＥがＰＵＣＣＨフォーマット３と新規ＰＵＣＣＨフォーマットのいずれで送信を行うかを事前に判断できるため、ＵＥに利用させるリソースのみを割り当てればよく、周波数利用効率を向上することができる。また、ＵＥが、ＡＲＩを含む少なくとも１つのＤＣＩ（ＰＤＣＣＨ／ＥＰＤＣＣＨ）の検出に成功すれば、基地局が指定したリソースを使用することができる。
【００７３】
なお、図５の例では新規ＰＵＣＣＨフォーマット用のＡＲＩ及びＰＵＣＣＨフォーマット３用のＡＲＩの両方が２ビットである構成を示したが、これに限られない。２つのＡＲＩを構成するビット数は異なっていてもよく、例えばＰＵＣＣＨフォーマット３用のＡＲＩを２ビットとし、新規ＰＵＣＣＨフォーマット用のＡＲＩを１ビットとしてもよい。このようにすることで、ＤＣＩの情報量の増大及びこれに伴うスループットの低減を抑制することができる。
【００７４】
また、新規ＰＵＣＣＨフォーマット用のＡＲＩを１ビットとする場合、新規フォーマットで送信するか否かを当該ビットで表現し、他の情報に基づいて新規フォーマット用のリソースを判断してもよい。この場合、新規ＰＵＣＣＨフォーマット用のリソースは、上位レイヤシグナリング（例えば、ＲＲＣシグナリング）で通知されてもよいし、予め設定されていてもよい。
【００７５】
また、実施形態２．３では、新規フォーマット用のテーブルに「新規ＰＵＣＣＨフォーマットで送信しない」ことに対応するＡＲＩを規定するとともに又は規定する代わりに、ＰＵＣＣＨフォーマット３用のテーブルに「ＰＵＣＣＨフォーマット３で送信しない」ことに対応するＡＲＩ（例えば、“００”）を規定してもよい。この場合、ＵＥは、ＤＣＩを検出すると、ＰＵＣＣＨフォーマット３用のＡＲＩを参照し、所定の値か否かを判断し、受信したＤＣＩに含まれるＰＵＣＣＨフォーマット３用のＡＲＩが、所定の値（例えば、“００”）以外であれば、当該ＡＲＩが指示するＰＵＣＣＨリソースを用いてＰＵＣＣＨフォーマット３で送信し、ＰＵＣＣＨフォーマット３用のＡＲＩが、所定の値であれば、新規ＰＵＣＣＨフォーマット用のＡＲＩが指示するＰＵＣＣＨリソースを用いて新規ＰＵＣＣＨフォーマットで送信してもよい。
【００７６】
（第３の実施形態：ＡＲＩとＴｏｔａｌ  ＤＡＩによるＰＵＣＣＨリソース指定方法）
本発明者らは、ＰＤＣＣＨ／ＥＰＤＣＣＨ検出ミスが発生すると、無線基地局とＵＥとの間でＰＵＣＣＨフォーマット、Ａ／Ｎビット数などの認識がずれる可能性があるという問題に対して、さらに検討を行った。そして、本発明者らは、フィードバックすべきＡ／Ｎビット数を特定するために利用可能な情報を通知することで認識のずれを防止することを着想し、第３及び第４の実施形態を見出した。
【００７７】
第３の実施形態では、フィードバックすべきＡ／Ｎビット数を特定するために利用可能な情報として、スケジュールされる総ＣＣ数に関する情報を、ＰＤＣＣＨ／ＥＰＤＣＣＨ（例えば、ＤＣＩ）に含めて通知する。スケジュールされる総ＣＣ数に関する情報は、例えば、所定の期間（例えば、所定のサブフレーム）においてＵＥにスケジュールされるＰＤＳＣＨの数（＝当該期間に関してＵＥがフィードバックすべきＡ／Ｎビット数）又はＣＣの数である。当該情報は、例えばＴｏｔａｌ  ＤＡＩ（ＴＤＡＩ：Total  Downlink  Assignment  Index）と呼ばれてもよいし、単にＤＡＩと呼ばれてもよいし、他の呼称をされてもよい。
【００７８】
例えば、無線基地局は、ＰＤＳＣＨのスケジューリングに用いるＰＤＣＣＨ／ＥＰＤＣＣＨ全てに（ＰＣｅｌｌ、ＳＣｅｌｌに関わらず）、ＴＤＡＩを含めて送信する。ＵＥは、検出したＰＤＣＣＨ／ＥＰＤＣＣＨに含まれるＴＤＡＩの値に基づいて、フィードバックするＡ／Ｎビット数を決定し、Ａ／Ｎビット列を生成する。ここで、ＵＥは、ＴＤＡＩの値と自身が検出したＰＤＣＣＨ／ＥＰＤＣＣＨの数が合わない場合には、ＴＤＡＩが指示する値に対応する個数のＮＡＣＫビット列（例えば、ビット列の長さ＝ＴＤＡＩが示す数）を報告する。
【００７９】
なお、ＮＡＣＫビット列の長さは、ＴＤＡＩが指示する値に加え、上位レイヤシグナリングを考慮して決定してもよい。例えば、ＴＤＡＩがＰＤＳＣＨがスケジューリングされたＣＣ数を表し、各ＣＣにＭＩＭＯ（Multi  Input  Multi  Output）が設定され、ＰＤＳＣＨにつき２ＴＢ（Transport  Block）のスケジューリングが行われる場合、ＮＡＣＫビット列の長さは、ＴＤＡＩが示す数×２となる。
【００８０】
図６は、スケジューリングされたＣＣの数とＴｏｔａｌ  ＤＡＩとの関係の一例を示す図である。本例では、基地局は６ＣＣを設定し、スケジュールするＣＣ数を６、３、そして５と変化させている。ＵＥは、ＴＤＡＩを含むＰＤＣＣＨ／ＥＰＤＣＣＨを少なくとも１つ検出すれば、Ａ／Ｎビット数を適切に設定することができる。
【００８１】
具体的には、ＵＥがＰＤＳＣＨを割り当てるいずれかのＰＤＣＣＨ／ＥＰＤＣＣＨを検出ミスしている場合（ＴＤＡＩ＞検出数）、どのＣＣのＰＤＣＣＨ／ＥＰＤＣＣＨを検出ミスしたか不明であれば、ＴＤＡＩが指示する値に対応するビット数のＮＡＣＫをフィードバックする。
【００８２】
また、ＵＥが割り当ての無いＣＣに対するＰＤＣＣＨ／ＥＰＤＣＣＨを誤検出している場合（ＴＤＡＩ＜検出数）、どのＣＣのＰＤＣＣＨ／ＥＰＤＣＣＨを誤検出したか不明であれば、ＴＤＡＩが指示する値に対応するビット数のＮＡＣＫをフィードバックする。
【００８３】
以上説明したように、ＴＤＡＩを利用することで、無線基地局とユーザ端末との間でＡ／Ｎビット数の認識がずれることがなくなり、大きな劣化の要因となるＮＡＣＫ−ｔｏ−ＡＣＫ誤り（本来ＮＡＣＫであるのに、ＡＣＫだと誤って認識すること）を回避できる。
【００８４】
第３の実施形態では、ＰＵＣＣＨリソースの判断のため、ＴＤＡＩとＡＲＩの両方をＰＤＣＣＨ／ＥＰＤＣＣＨに含める。そして、ＵＥは、ＴＤＡＩの値が所定の値（例えば、所定の範囲に含まれる値、所定値以下の値など）を示していたら、受信したＡＲＩをＰＵＣＣＨフォーマット３用のＡＲＩとみなし、そうでなければ、受信したＡＲＩを新規ＰＵＣＣＨフォーマット用のＡＲＩとみなす。
【００８５】
ＵＥは、受信したＡＲＩをＰＵＣＣＨフォーマット３用のＡＲＩとみなした場合、ＰＵＣＣＨフォーマット３用のＡＲＩテーブルに基づいてＰＵＣＣＨリソースを決定し、新規ＰＵＣＣＨフォーマット用のＡＲＩとみなした場合、新規ＰＵＣＣＨフォーマット用のＡＲＩテーブルに基づいてＰＵＣＣＨリソースを決定する。ここで、ＵＥには、第２の実施形態で説明したように、ＰＵＣＣＨフォーマット３用のＡＲＩテーブルと新規ＰＵＣＣＨフォーマット用のＡＲＩテーブルが独立に設定されるものとしてもよいし、同じＡＲＩテーブルが利用されてもよい。
【００８６】
なお、ＡＲＩの判断に用いる所定の値は、上位レイヤシグナリング（例えば、ＲＲＣシグナリング）、ＤＣＩなど又はこれらの組み合わせで通知されてもよいし、予め設定されていてもよい。
【００８７】
図７は、第３の実施形態の一例を示す図である。本例では、基地局は６ＣＣを設定している。本例では、ＵＥは、ＴＤＡＩが６以上の場合に新規ＰＵＣＣＨフォーマットを用いるように設定されているものとする。
【００８８】
図７Ａでは、基地局はＣＣ＃０−＃５全てにスケジューリングを行っており、各スケジューリングに対応するＰＤＣＣＨ／ＥＰＤＣＣＨには、６ＣＣの割り当てを示すＴＤＡＩ＝６が含まれている。また、ＳＣｅｌｌ（ＣＣ＃１−＃５）をスケジューリングするＤＣＩではＡＲＩが通知される。
【００８９】
この場合、ＴＤＡＩが６ＣＣ分の割り当てを示しているため、ＵＥは新規ＰＵＣＣＨフォーマットで送信を行うと判断する。このとき、ＵＥは、通知されたＡＲＩの値を、新規ＰＵＣＣＨフォーマット向けのＡＲＩとして解釈し、当該ＡＲＩが指定するＰＵＣＣＨリソースを新規ＰＵＣＣＨフォーマット用のＡＲＩテーブルに基づいて選択し、当該リソースを用いて新規ＰＵＣＣＨフォーマットでＨＡＲＱ−ＡＣＫの送信を行う。
【００９０】
図７Ｂでは、基地局はＣＣ＃１−＃５にスケジューリングを行っており、各スケジューリングに対応するＰＤＣＣＨ／ＥＰＤＣＣＨには、５ＣＣの割り当てを示すＴＤＡＩ＝５が含まれている。また、ＳＣｅｌｌをスケジューリングするＤＣＩではＡＲＩが通知される。
【００９１】
この場合、ＴＤＡＩが５ＣＣ分の割り当てを示しているため、ＵＥはＰＵＣＣＨフォーマット３で送信を行うと判断する。このとき、ＵＥは、通知されたＡＲＩの値を、ＰＵＣＣＨフォーマット３向けのＡＲＩとして解釈し、当該ＡＲＩが指定するＰＵＣＣＨリソースを用いてＰＵＣＣＨフォーマット３用のＡＲＩテーブルに基づいて選択し、当該リソースを用いてＨＡＲＱ−ＡＣＫの送信を行う。
【００９２】
なお、ＵＥがいずれかのＣＣのＰＤＳＣＨを割り当てるＰＤＣＣＨ／ＥＰＤＣＣＨを検出ミスしている場合、ＴＤＡＩの示す値とＵＥが検出したＰＤＣＣＨ／ＥＰＤＣＣＨの数が対応しなくなる。この場合、ＵＥは、ＴＤＡＩの示す値が所定の値（例えば、所定の範囲に含まれる値、所定値以下の値など）を示していたら、受信したＡＲＩをＰＵＣＣＨフォーマット３用のＡＲＩとみなし、ＴＤＡＩの示す値に対応する数のＮＡＣＫビット列をＰＵＣＣＨフォーマット３で送信し、そうでなければ、受信したＡＲＩを新規ＰＵＣＣＨフォーマット用のＡＲＩとみなし、ＴＤＡＩの示す値に対応する数のＮＡＣＫビット列を新規ＰＵＣＣＨフォーマットで送信することができる。
【００９３】
以上、第３の実施形態によれば、無線基地局とユーザ端末との間で、Ａ／Ｎビット数及びＰＵＣＣＨフォーマットの認識がずれることがなくなり、スループットの低下を抑制することができる。
【００９４】
（第４の実施形態：ＡＲＩとビットマップによるＰＵＣＣＨリソース指定方法）
第４の実施形態では、フィードバックすべきＡ／Ｎビット数を特定するために利用可能な情報として、スケジュールされるＣＣを特定するための情報を、ＰＤＣＣＨ／ＥＰＤＣＣＨ（例えば、ＤＣＩ）に含めて通知する。スケジュールされるＣＣを特定するための情報は、例えば、所定の期間（例えば、所定のサブフレーム）においてＵＥに対してＰＤＳＣＨがスケジュールされたＣＣ（＝当該期間に関してＵＥがＡ／ＮをフィードバックすべきＣＣ）又はＰＤＳＣＨに対応したビットを含むビットマップ（ビットマップフィールド、ビット列と呼ばれてもよい）である。当該情報は、例えばスケジュールＣＣ特定情報、スケジューリング有無を示すビットマップなどと呼ばれてもよいし、他の呼称をされてもよい。
【００９５】
例えば、無線基地局は、ＰＤＳＣＨのスケジューリングに用いるＰＤＣＣＨ／ＥＰＤＣＣＨ全てに（ＰＣｅｌｌ、ＳＣｅｌｌに関わらず）、ビットマップを含めて送信する。ＵＥは、検出したＰＤＣＣＨ／ＥＰＤＣＣＨに含まれるビットマップに基づいて、スケジュールされたＣＣを認識し、それに応じてフィードバックするＡ／Ｎビット数を決定し、Ａ／Ｎビット列を生成する。ここで、ＵＥは、ビットマップを用いて決定されるＡ／Ｎビット数（例えば、スケジュールされるＣＣ数）と自身が検出したＰＤＣＣＨ／ＥＰＤＣＣＨの数が合わない場合には、ビットマップを用いて決定されるＡ／Ｎビット数のＮＡＣＫビット列（例えば、ビット列の長さ＝ビットマップフィールドにおける‘１’の個数）を報告する。
【００９６】
図８は、スケジューリングされたＣＣの数とビットマップとの関係の一例を示す図である。本例では、基地局は６ＣＣを設定し、ＣＣ＃０−＃２、＃４及び＃５の計５ＣＣにスケジューリングを行っている。この場合、第４の実施形態におけるビットマップは、‘１’がスケジュールされるＣＣを示すとすると、“１１１０１１”となる。この場合、スケジューリングされるＣＣ数＝５である。
【００９７】
図８Ａは、各ＣＣに対するＰＤＣＣＨ／ＥＰＤＣＣＨ全てにビットマップを含める例を示している。このようにすることで、ビットマップを含むＰＤＣＣＨ／ＥＰＤＣＣＨを少なくとも１つ検出すれば、Ａ／Ｎビット数を適切に設定することができる。
【００９８】
図８Ｂは、特定のＣＣで送受信されるＰＤＣＣＨ／ＥＰＤＣＣＨに、当該ＣＣのＰＤＣＣＨ／ＥＰＤＣＣＨにより割り当てられる各ＣＣに対するスケジューリング有無を示すビットマップを含める例を示す。図８Ｂでは、ＵＥは、ＰＣｅｌｌで受信するＰＤＣＣＨ／ＥＰＤＣＣＨにより、複数のＣＣ（ＣＣ＃０−＃２、＃４及び＃５）のスケジューリングを判断する。この場合、当該特定のＣＣにおけるＰＤＣＣＨ／ＥＰＤＣＣＨを検出すれば、Ａ／Ｎビット数を適切に設定することができる。なお、ＰＣｅｌｌではなく、ＳＣｅｌｌのＣＣを上記特定のＣＣとしてもよい。
【００９９】
具体的には、ＵＥがＰＤＳＣＨを割り当てるいずれかのＰＤＣＣＨ／ＥＰＤＣＣＨを検出ミスしている場合（例えば、ビットマップフィールドにおける‘１’の個数＞検出数）、ビットマップに基づいて、検出ミスしたＣＣを特定して当該ＣＣのフィードバック情報をＮＡＣＫとし、ビットマップフィールドにおける‘１’の個数に等しいビット数のＡＣＫ／ＮＡＣＫをフィードバックする。
【０１００】
また、ＵＥが割り当ての無いＣＣに対するＰＤＣＣＨ／ＥＰＤＣＣＨを誤検出している場合（例えば、ビットマップフィールドにおける‘１’の個数＜検出数）、誤検出したＣＣを特定して、当該ＣＣがスケジュールされていない場合には当該ＣＣのフィードバック情報を生成せず、スケジュールされた各ＣＣについて、ビットマップフィールドにおける‘１’の個数に等しいビット数のＡＣＫ／ＮＡＣＫをフィードバックする。
【０１０１】
以上説明したように、ビットマップを利用することで、スケジュールされたＣＣがどれであるかという情報が基地局とＵＥで共有されるため、無線基地局とユーザ端末との間でＡ／Ｎビット数の認識がずれることがなくなり、大きな劣化の要因となるＮＡＣＫ−ｔｏ−ＡＣＫ誤りを回避できる。
【０１０２】
第４の実施形態では、ＰＵＣＣＨリソースの判断のため、上記のビットマップとＡＲＩの両方をＰＤＣＣＨ／ＥＰＤＣＣＨに含める。そして、ＵＥは、ビットマップに‘１’が所定の数（例えば、所定の範囲に含まれる数、所定値以下の数など）含まれる場合、受信したＡＲＩをＰＵＣＣＨフォーマット３用のＡＲＩとみなし、そうでなければ、受信したＡＲＩを新規ＰＵＣＣＨフォーマット用のＡＲＩとみなす。
【０１０３】
ＵＥは、受信したＡＲＩをＰＵＣＣＨフォーマット３用のＡＲＩとみなした場合、ＰＵＣＣＨフォーマット３用のＡＲＩテーブルに基づいてＰＵＣＣＨリソースを決定し、新規ＰＵＣＣＨフォーマット用のＡＲＩとみなした場合、新規ＰＵＣＣＨフォーマット用のＡＲＩテーブルに基づいてＰＵＣＣＨリソースを決定する。ここで、ＵＥには、第２の実施形態で説明したように、ＰＵＣＣＨフォーマット３用のＡＲＩテーブルと新規ＰＵＣＣＨフォーマット用のＡＲＩテーブルが独立に設定されるものとしてもよいし、同じＡＲＩテーブルが利用されてもよい。
【０１０４】
なお、ＡＲＩの判断に用いる所定の値は、上位レイヤシグナリング（例えば、ＲＲＣシグナリング）、ＤＣＩなど又はこれらの組み合わせで通知されてもよいし、予め設定されていてもよい。また、所定の値は、ビットマップに含まれる‘１’の数でなく、‘０’の数と比較されることにより、ＡＲＩの判断が行われてもよい。
【０１０５】
図９は、第４の実施形態の一例を示す図である。本例では、基地局は６ＣＣを設定している。本例では、ＵＥは、ビットマップに‘１’が６以上含まれる場合に新規ＰＵＣＣＨフォーマットを用いるように設定されているものとする。
【０１０６】
図９Ａでは、基地局はＣＣ＃０−＃５全てにスケジューリングを行っており、各スケジューリングに対応するＰＤＣＣＨ／ＥＰＤＣＣＨには、６ＣＣの割り当てを示すビットマップ＝“１１１１１１”が含まれている。また、ＳＣｅｌｌ（ＣＣ＃１−＃５）をスケジューリングするＤＣＩではＡＲＩが通知される。
【０１０７】
この場合、ビットマップが６ＣＣ分の割り当てを示しているため、ＵＥは新規ＰＵＣＣＨフォーマットで送信を行うと判断する。このとき、ＵＥは、通知されたＡＲＩの値を、新規ＰＵＣＣＨフォーマット向けのＡＲＩとして解釈し、当該ＡＲＩが指定するＰＵＣＣＨリソースを新規ＰＵＣＣＨフォーマット用テーブルに基づいて選択し、当該リソースを用いて新規ＰＵＣＣＨフォーマットで送信を行う。
【０１０８】
図９Ｂでは、基地局はＣＣ＃１−＃５にスケジューリングを行っており、各スケジューリングに対応するＰＤＣＣＨ／ＥＰＤＣＣＨには、ＣＣ＃０以外の５ＣＣの割り当てを示すビットマップ＝“０１１１１１”が含まれている。また、ＳＣｅｌｌ（ＣＣ＃１−＃５）をスケジューリングするＤＣＩではＡＲＩが通知される。
【０１０９】
この場合、ビットマップが５ＣＣ分の割り当てを示しているため、ＵＥはＰＵＣＣＨフォーマット３で送信を行うと判断する。このとき、ＵＥは、通知されたＡＲＩの値を、ＰＵＣＣＨフォーマット３向けのＡＲＩとして解釈し、当該ＡＲＩが指定するＰＵＣＣＨリソースを用いてＰＵＣＣＨフォーマット３用テーブルに基づいて選択し、当該リソースを用いて送信を行う。
【０１１０】
以上、第４の実施形態によれば、無線基地局とユーザ端末との間で、Ａ／Ｎビット数及びＰＵＣＣＨフォーマットの認識がずれることがなくなり、スループットの低下を抑制することができる。
【０１１１】
＜変形例＞
なお、上述の各実施形態に示した例は一例に過ぎず、これに限られない。例えば、上述の各実施形態では、物理レイヤシグナリング（ＰＤＣＣＨ／ＥＰＤＣＣＨ）又は上位レイヤシグナリング（ＲＲＣ）に基づいて、既存のＰＵＣＣＨフォーマット３と、新規ＰＵＣＣＨフォーマットとを切り替え、ＰＵＣＣＨリソースを適切に決定する方法を示したが、切り替え対象となるＰＵＣＣＨフォーマットは、これら２つに限られない。
【０１１２】
本発明は、複数の新規ＰＵＣＣＨフォーマットが規定されるならば、これら複数の新規ＰＵＣＣＨフォーマット間の切り替えに適用されてもよいし、既存ＰＵＣＣＨフォーマット３と複数の新規ＰＵＣＣＨフォーマット間など、３つ以上（３種類以上）のＰＵＣＣＨフォーマット間の切り替えに適用されてもよい。
【０１１３】
また、第３及び第４の実施形態では、物理レイヤシグナリング（ＤＣＩ）に、ＴＤＡＩ又はビットマップを含める構成を示したが、これに限られない。例えば、ＴＤＡＩ及び／又はビットマップは、ＤＬ  ＭＡＣ  ＣＥ（Downlink  Medium  Access  Control  Control  Element）に含めるものとしてもよい。具体的には、複数のＤＬ−ＣＣでスケジューリングされる場合に、全て又は一部のＤＬ−ＣＣのＭＡＣ  ＣＥに、ＴＤＡＩ及び／又はビットマップを含める構成としてもよい。
【０１１４】
第３及び第４の実施形態では、スケジュールされる全ＣＣについての情報（スケジュールされる総ＣＣ数に関する情報又はビットマップ）が、各ＰＤＣＣＨ／ＥＰＤＣＣＨに含まれるものとしたが、これに限られない。例えば、特定のＣＣにおけるＰＤＣＣＨ／ＥＰＤＣＣＨには、当該特定のＣＣからスケジューリングされるＣＣのみについての上記情報（スケジュールされるＣＣ数に関する情報又はビットマップ）が含まれるように構成されてもよい。
【０１１５】
この場合、スケジュールされるＣＣ数に関する情報（例えば、全ＣＣのうち、どのＣＣに対応したＣＣ数か）又はビットマップの構成に関する情報（例えば、どのビットがどのＣＣを示すか）が上位レイヤシグナリング、ＤＣＩなど又はこれらの組み合わせにより通知されてもよい。ＵＥは、これらの情報により、一部のＣＣ群についてのＡＣＫ／ＮＡＣＫのビット数を適切に設定することができる。
【０１１６】
また、複数のＣＣのＰＤＣＣＨ／ＥＰＤＣＣＨにＴＤＡＩやビットマップが含まれる場合、ＵＥは、異なるＴＤＡＩやビットマップを含む複数のＰＤＣＣＨ／ＥＰＤＣＣＨを検出する可能性があるが、このうちいずれかのＰＤＣＣＨ／ＥＰＤＣＣＨは、誤検出である可能性が高い。
【０１１７】
このため、複数のＴＤＡＩ及び／又はビットマップが得られた場合、ＵＥは、以下のいずれかの方法でＴＤＡＩ及び／又はビットマップを選択し、ＰＵＣＣＨフォーマット及び／又はＰＵＣＣＨリソースを決定してもよい：
（１）多数決で選択（最も多く検出されたＴＤＡＩ及び／又はビットマップを選択）、
（２）スケジューリングされたＣＣ数が最も多いものを選択（最も大きいＴＤＡＩ及び／又は最も‘１’の数が多いビットマップを選択）、
（３）スケジューリングされたＣＣ数が最も少ないものを選択（最も小さいＴＤＡＩ及び／又は最も‘１’の数が少ないビットマップを選択）。
このようにすることで、無線基地局とＵＥとの間で、Ａ／Ｎビット数やＰＵＣＣＨフォーマット、ＰＵＣＣＨリソースなどの認識がずれる可能性を低減することができる。
【０１１８】
また、所定のＰＤＳＣＨを受信するＣＣと、当該ＰＤＳＣＨを割り当てるＰＤＣＣＨ／ＥＰＤＣＣＨを受信するＣＣと、が同じ場合であっても、異なる場合（クロスキャリアスケジューリング）であっても、各実施形態で説明した方法を適用することができる。
【０１１９】
また、複数のＣＣのＰＤＳＣＨをスケジューリングするＰＤＣＣＨ／ＥＰＤＣＣＨが、１つのＣＣで受信される場合であっても、各実施形態で説明する方法を適用することができる。
【０１２０】
なお、上記各実施形態では、ＨＡＲＱ−ＡＣＫを送信するためのＰＵＣＣＨフォーマット／ＰＵＣＣＨリソースを制御する例を示したが、制御されるＰＵＣＣＨフォーマット／ＰＵＣＣＨリソースでは他の信号が送信されてもよい。ＨＡＲＱ−ＡＣＫを送信するＰＵＣＣＨフォーマット／ＰＵＣＣＨリソースとして決定されたＰＵＣＣＨフォーマット／ＰＵＣＣＨリソースを用いて、他の上り制御信号（ＵＣＩ：Uplink  Control  Information）が送信されてもよい。例えば、新規ＰＵＣＣＨフォーマット及び／又は新規ＰＵＣＣＨフォーマット用のＰＵＣＣＨリソースを用いて、スケジューリング要求（ＳＲ：Scheduling  Request）や、ＣＱＩ（Channel  Quality  Indicator）、ＰＭＩ（Precoding  Matrix  Indicator）及びＲＩ（Rank  Indicator）などのチャネル状態情報（ＣＳＩ：Channel  State  Information）が送信されてもよい。または、ＨＡＲＱ−ＡＣＫと上記他の上り制御信号の一部又は全てが多重され、制御されるＰＵＣＣＨフォーマット／ＰＵＣＣＨリソースで送信されてもよい。
【０１２１】
Ｒｅｌ．１３  ＣＡにおいて、多数のＣＣを設定する動機として、端末スループットを大幅に高めることのほか、多数の周波数キャリアの中で、実際にスケジューリングするキャリアを動的に切り替えられるようにし、干渉や周波数の混み具合に応じて利用するキャリアを柔軟に変更する、という利用法が検討されている。前者の動機を達成するためには、多数のＣＣを設定し、それらに同時にスケジューリングすることが必須であるから、新規ＰＵＣＣＨフォーマットを利用することが必要となる。一方で、後者の動機は、多くのＣＣに同時にスケジューリングを行わなくても達成できる。
【０１２２】
したがって、新規ＰＵＣＣＨフォーマットを設定できることを示す端末能力情報（UE  capability）を導入することにより、新規ＰＵＣＣＨフォーマットは実装していないが多数のＣＣによるＵＬ−ＣＡは実装している端末実装を、基地局側で認識できるようになる。換言すれば、ＵＥに対し、新規ＰＵＣＣＨフォーマットを必要とする高い端末スループット達成の実装を省き、後者の動機を達成する目的でのみＵＬ−ＣＡを実装することができるようになるため、より簡易な実装で多数のＣＣを設定するＵＬ−ＣＡを実装し、後者の動機を達成できるようになる。
【０１２３】
このため、無線基地局は、新規ＰＵＣＣＨフォーマットを設定できることを示す端末能力情報を通知してきたユーザ端末に対して、新規ＰＵＣＣＨフォーマットを設定（又は新たな新規ＰＵＣＣＨフォーマットを用いるか否かに関する情報を通知）する構成としてもよい。例えば、５個より多いＣＣのＣＡを設定可能な端末能力情報と、新規ＰＵＣＣＨフォーマットを設定できることを示す端末能力情報と、を両方通知してきたユーザ端末に対して、新規ＰＵＣＣＨフォーマットを設定する。
【０１２４】
なお、上記各実施形態、各変形例に係る無線通信方法は、それぞれ単独で適用されてもよいし、組み合わせて適用されてもよい。
【０１２５】
（無線通信システム）
以下、本発明の一実施形態に係る無線通信システムの構成について説明する。この無線通信システムでは、本発明の上記各実施形態に係る無線通信方法が適用される。なお、上記各実施形態に係る無線通信方法は、それぞれ単独で適用されてもよいし、組み合わせて適用されてもよい。
【０１２６】
図１０は、本発明の一実施形態に係る無線通信システムの概略構成の一例を示す図である。無線通信システム１では、ＬＴＥシステムのシステム帯域幅（例えば、２０ＭＨｚ）を１単位とする複数の基本周波数ブロック（コンポーネントキャリア）を一体としたキャリアアグリゲーション（ＣＡ）及び／又はデュアルコネクティビティ（ＤＣ）を適用することができる。なお、無線通信システム１は、ＳＵＰＥＲ  ３Ｇ、ＬＴＥ−Ａ（LTE-Advanced）、ＩＭＴ−Ａｄｖａｎｃｅｄ、４Ｇ、５Ｇ、ＦＲＡ（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）、送達確認信号（ＡＣＫ／ＮＡＣＫ）などが伝送される。ＰＲＡＣＨにより、セルとの接続確立のためのランダムアクセスプリアンブルが伝送される。
【０１３８】
無線通信システム１では、下り参照信号として、セル固有参照信号（ＣＲＳ：Cell-specific  Reference  Signal）、チャネル状態情報参照信号（ＣＳＩ−ＲＳ：Channel  State  Information-Reference  Signal）、復調用参照信号（ＤＭＲＳ：DeModulation  Reference  Signal）などが伝送される。また、無線通信システム１では、上り参照信号として、測定用参照信号（ＳＲＳ：Sounding  Reference  Signal）、復調用参照信号（ＤＭＲＳ：DeModulation  Reference  Signal）などが伝送される。なお、ＤＭＲＳはユーザ端末固有参照信号（UE-specific  Reference  Signal）と呼ばれてもよい。また、伝送される参照信号は、これらに限られない。
【０１３９】
＜無線基地局＞
図１１は、本発明の一実施形態に係る無線基地局の全体構成の一例を示す図である。無線基地局１０は、複数の送受信アンテナ１０１と、アンプ部１０２と、送受信部１０３と、ベースバンド信号処理部１０４と、呼処理部１０５と、伝送路インターフェース１０６とを備えている。なお、送受信アンテナ１０１、アンプ部１０２、送受信部１０３は、それぞれ１つ以上を含むように構成されればよい。
【０１４０】
下りリンクにより無線基地局１０からユーザ端末２０に送信されるユーザデータは、上位局装置３０から伝送路インターフェース１０６を介してベースバンド信号処理部１０４に入力される。
【０１４１】
ベースバンド信号処理部１０４では、ユーザデータに関して、ＰＤＣＰ（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）に準拠した光ファイバ、Ｘ２インターフェース）を介して他の無線基地局１０と信号を送受信（バックホールシグナリング）してもよい。
【０１４６】
なお、送受信部１０３は、ユーザ端末２０に対して、所定のＣＣに対する下り共有チャネルの受信の指示情報（ＤＣＩ）を送信する。当該指示情報は、ＤＬアサインメント（Downlink  assignment）やスケジューリング情報と呼ばれてもよい。また、当該ＤＣＩには、１つ又は複数のＡＲＩ、ＴＤＡＩ、スケジュールされたＣＣに対応したビットを含むビットマップなどが含まれてもよい。また、送受信部１０３は、ＡＲＩテーブル（ＰＵＣＣＨフォーマット３用のＡＲＩテーブル、新規ＰＵＣＣＨフォーマット用のＡＲＩテーブル）に関する情報を送信してもよい。
【０１４７】
また、送受信部１０３は、ユーザ端末２０から、所定のＰＵＣＣＨフォーマットで送信されたＨＡＲＱ−ＡＣＫを受信する。当該所定のＰＵＣＣＨフォーマットには、既存のＰＵＣＣＨフォーマット（例えば、ＰＵＣＣＨフォーマット１ａ／１ｂ、ＰＵＣＣＨフォーマット３）より送信可能なビット数が大きい新規ＰＵＣＣＨフォーマットが含まれる。
【０１４８】
図１２は、本実施形態に係る無線基地局の機能構成の一例を示す図である。なお、図１２では、本実施形態における特徴部分の機能ブロックを主に示しており、無線基地局１０は、無線通信に必要な他の機能ブロックも有しているものとする。図１２に示すように、ベースバンド信号処理部１０４は、制御部（スケジューラ）３０１と、送信信号生成部３０２と、マッピング部３０３と、受信信号処理部３０４と、測定部３０５と、を少なくとも備えている。
【０１４９】
制御部（スケジューラ）３０１は、無線基地局１０全体の制御を実施する。制御部３０１は、本発明に係る技術分野での共通認識に基づいて説明されるコントローラ、制御回路又は制御装置から構成することができる。
【０１５０】
制御部３０１は、例えば、送信信号生成部３０２による信号の生成や、マッピング部３０３による信号の割り当てを制御する。また、制御部３０１は、受信信号処理部３０４による信号の受信処理や、測定部３０５による信号の測定を制御する。
【０１５１】
制御部３０１は、システム情報、ＰＤＳＣＨで送信される下りデータ信号、ＰＤＣＣＨ及び／又はＥＰＤＣＣＨで伝送される下り制御信号のスケジューリング（例えば、リソース割り当て）を制御する。また、同期信号（ＰＳＳ（Primary  Synchronization  Signal）／ＳＳＳ（Secondary  Synchronization  Signal））や、ＣＲＳ、ＣＳＩ−ＲＳ、ＤＭＲＳなどの下り参照信号のスケジューリングの制御を行う。
【０１５２】
また、制御部３０１は、ＰＵＳＣＨで送信される上りデータ信号、ＰＵＣＣＨ及び／又はＰＵＳＣＨで送信される上り制御信号（例えば、送達確認信号（ＨＡＲＱ−ＡＣＫ））、ＰＲＡＣＨで送信されるランダムアクセスプリアンブルや、上り参照信号などのスケジューリングを制御する。
【０１５３】
具体的には、制御部３０１は、複数のＣＣのＰＤＳＣＨのスケジューリングを制御し、各ＰＤＳＣＨで利用する無線リソースを指示するための指示情報（ＤＣＩ）を、ＰＤＣＣＨ／ＥＰＤＣＣＨで所定のユーザ端末２０に送信するように、送信信号生成部３０２及びマッピング部３０３を制御する。
【０１５４】
また、制御部３０１は、ユーザ端末２０が利用するＰＵＣＣＨリソースを制御（確保）する。例えば、制御部３０１は、所定のユーザ端末２０がＰＤＳＣＨの受信に応じて利用し得るＨＡＲＱ−ＡＣＫのためのＰＵＣＣＨリソースを制御（確保）する。制御部３０１は、当該ＰＵＣＣＨリソースに対応したＡＲＩを、ＳＣｅｌｌのスケジューリング用のＤＣＩに含めるように制御してもよい。また、制御部３０１は、フィードバックのタイミングで当該ＰＵＣＣＨリソースを監視するように、受信信号処理部３０４を制御する。
【０１５５】
ここで、制御部３０１は、新規ＰＵＣＣＨフォーマットのＰＵＣＣＨリソースを、他のＰＵＣＣＨフォーマットと同じＡＲＩテーブルに基づいて決定してもよいし（実施形態２．１）、異なるＡＲＩテーブルに基づいて決定してもよい（実施形態２．２、２．３）。複数のＡＲＩテーブルを用いる場合、各ＡＲＩテーブル用のＡＲＩをそれぞれＤＣＩに含めてもよい（実施形態２．３）。この場合、ＡＲＩによりＨＡＲＱ−ＡＣＫのフィードバックに用いるＰＵＣＣＨフォーマットをユーザ端末２０に指定することができるため、制御部３０１は、当該ＰＵＣＣＨフォーマットで利用されるＰＵＣＣＨリソース（及び／又はＰＵＣＣＨフォーマット１ａ／１ｂ用のＰＵＣＣＨリソース）のみを監視するように制御してもよい。
【０１５６】
また、制御部３０１は、各スケジューリング用のＤＣＩに、ＴＤＡＩ及び／又はスケジュールされたＣＣに対応したビットを含むビットマップを含むように制御してもよい（第３、第４の実施形態）。
【０１５７】
また、制御部３０１は、１つ又は複数のＡＲＩテーブル（例えば、ＰＵＣＣＨフォーマット３用のＡＲＩテーブル、新規ＰＵＣＣＨフォーマット用のＡＲＩテーブル）に関する情報を、上位レイヤシグナリング（例えば、ＲＲＣシグナリング）でユーザ端末２０に送信するように制御してもよい。
【０１５８】
制御部３０１は、ユーザ端末２０からのＨＡＲＱ−ＡＣＫを受信信号処理部３０４から取得すると、当該ユーザ端末２０に対する再送が必要か否かを判断し、必要な場合には再送処理を行うように制御する。
【０１５９】
送信信号生成部３０２は、制御部３０１からの指示に基づいて、下り信号（下り制御信号、下りデータ信号、下り参照信号など）を生成して、マッピング部３０３に出力する。送信信号生成部３０２は、本発明に係る技術分野での共通認識に基づいて説明される信号生成器、信号生成回路又は信号生成装置から構成することができる。
【０１６０】
送信信号生成部３０２は、例えば、制御部３０１からの指示に基づいて、下り信号の割り当て情報を通知するＤＬアサインメント及び上り信号の割り当て情報を通知するＵＬグラントを生成する。また、下りデータ信号には、各ユーザ端末２０からのチャネル状態情報（ＣＳＩ：Channel  State  Information）などに基づいて決定された符号化率、変調方式などに従って符号化処理、変調処理が行われる。
【０１６１】
マッピング部３０３は、制御部３０１からの指示に基づいて、送信信号生成部３０２で生成された下り信号を、所定の無線リソースにマッピングして、送受信部１０３に出力する。マッピング部３０３は、本発明に係る技術分野での共通認識に基づいて説明されるマッパー、マッピング回路又はマッピング装置から構成することができる。
【０１６２】
受信信号処理部３０４は、送受信部１０３から入力された受信信号に対して、受信処理（例えば、デマッピング、復調、復号など）を行う。ここで、受信信号は、例えば、ユーザ端末２０から送信される上り信号（上り制御信号、上りデータ信号、上り参照信号など）である。受信信号処理部３０４は、本発明に係る技術分野での共通認識に基づいて説明される信号処理器、信号処理回路又は信号処理装置から構成することができる。
【０１６３】
受信信号処理部３０４は、受信処理により復号された情報を制御部３０１に出力する。例えば、ＨＡＲＱ−ＡＣＫを含むＰＵＣＣＨを受信した場合、ＨＡＲＱ−ＡＣＫを制御部３０１に出力する。また、受信信号処理部３０４は、受信信号や、受信処理後の信号を、測定部３０５に出力する。
【０１６４】
測定部３０５は、受信した信号に関する測定を実施する。測定部３０５は、本発明に係る技術分野での共通認識に基づいて説明される測定器、測定回路又は測定装置から構成することができる。
【０１６５】
測定部３０５は、例えば、受信した信号の受信電力（例えば、ＲＳＲＰ（Reference  Signal  Received  Power））、受信品質（例えば、ＲＳＲＱ（Reference  Signal  Received  Quality））やチャネル状態などについて測定してもよい。測定結果は、制御部３０１に出力されてもよい。
【０１６６】
＜ユーザ端末＞
図１３は、本実施形態に係るユーザ端末の全体構成の一例を示す図である。ユーザ端末２０は、複数の送受信アンテナ２０１と、アンプ部２０２と、送受信部２０３と、ベースバンド信号処理部２０４と、アプリケーション部２０５と、を備えている。なお、送受信アンテナ２０１、アンプ部２０２、送受信部２０３は、それぞれ１つ以上を含むように構成されればよい。
【０１６７】
送受信アンテナ２０１で受信された無線周波数信号は、アンプ部２０２で増幅される。送受信部２０３は、アンプ部２０２で増幅された下り信号を受信する。送受信部２０３は、受信信号をベースバンド信号に周波数変換して、ベースバンド信号処理部２０４に出力する。送受信部２０３は、本発明に係る技術分野での共通認識に基づいて説明されるトランスミッター／レシーバー、送受信回路又は送受信装置から構成することができる。なお、送受信部２０３は、一体の送受信部として構成されてもよいし、送信部及び受信部から構成されてもよい。
【０１６８】
ベースバンド信号処理部２０４は、入力されたベースバンド信号に対して、ＦＦＴ処理や、誤り訂正復号、再送制御の受信処理などを行う。下りリンクのユーザデータは、アプリケーション部２０５に転送される。アプリケーション部２０５は、物理レイヤやＭＡＣレイヤより上位のレイヤに関する処理などを行う。また、下りリンクのデータのうち、報知情報もアプリケーション部２０５に転送される。
【０１６９】
一方、上りリンクのユーザデータについては、アプリケーション部２０５からベースバンド信号処理部２０４に入力される。ベースバンド信号処理部２０４では、再送制御の送信処理（例えば、ＨＡＲＱの送信処理）や、チャネル符号化、プリコーディング、離散フーリエ変換（ＤＦＴ：Discrete  Fourier  Transform）処理、ＩＦＦＴ処理などが行われて送受信部２０３に転送される。送受信部２０３は、ベースバンド信号処理部２０４から出力されたベースバンド信号を無線周波数帯に変換して送信する。送受信部２０３で周波数変換された無線周波数信号は、アンプ部２０２により増幅され、送受信アンテナ２０１から送信される。
【０１７０】
なお、送受信部２０３は、無線基地局１０から、所定のＣＣに対する下り共有チャネルの受信の指示情報（ＤＣＩ）を受信する。また、当該ＤＣＩには、１つ又は複数のＡＲＩ、ＴＤＡＩ、スケジュールされたＣＣに対応したビットを含むビットマップなどが含まれてもよい。また、送受信部２０３は、ＡＲＩテーブル（ＰＵＣＣＨフォーマット３用のＡＲＩテーブル、新規ＰＵＣＣＨフォーマット用のＡＲＩテーブル）に関する情報を受信してもよい。
【０１７１】
また、送受信部２０３は、無線基地局１０に、所定のＰＵＣＣＨフォーマットを用いてＨＡＲＱ−ＡＣＫを送信する。当該所定のＰＵＣＣＨフォーマットには、既存のＰＵＣＣＨフォーマット（例えば、ＰＵＣＣＨフォーマット１ａ／１ｂ、ＰＵＣＣＨフォーマット３）より送信可能なビット数が大きい新規ＰＵＣＣＨフォーマットが含まれる。
【０１７２】
図１４は、本実施形態に係るユーザ端末の機能構成の一例を示す図である。なお、図１４においては、本実施形態における特徴部分の機能ブロックを主に示しており、ユーザ端末２０は、無線通信に必要な他の機能ブロックも有しているものとする。図１４に示すように、ユーザ端末２０が有するベースバンド信号処理部２０４は、制御部４０１と、送信信号生成部４０２と、マッピング部４０３と、受信信号処理部４０４と、測定部４０５と、を少なくとも備えている。
【０１７３】
制御部４０１は、ユーザ端末２０全体の制御を実施する。制御部４０１は、本発明に係る技術分野での共通認識に基づいて説明されるコントローラ、制御回路又は制御装置から構成することができる。
【０１７４】
制御部４０１は、例えば、送信信号生成部４０２による信号の生成や、マッピング部４０３による信号の割り当てを制御する。また、制御部４０１は、受信信号処理部４０４による信号の受信処理や、測定部４０５による信号の測定を制御する。
【０１７５】
制御部４０１は、無線基地局１０から送信された下り制御信号（ＰＤＣＣＨ／ＥＰＤＣＣＨで送信された信号）及び下りデータ信号（ＰＤＳＣＨで送信された信号）を、受信信号処理部４０４から取得する。制御部４０１は、下り制御信号や、下りデータ信号に対する再送制御の要否を判定した結果などに基づいて、上り制御信号（例えば、送達確認信号（ＨＡＲＱ−ＡＣＫ）など）や上りデータ信号の生成を制御する。
【０１７６】
具体的には、制御部４０１は、ＰＤＳＣＨをスケジューリングする指示情報（ＤＣＩ）を取得すると、所定のタイミングで指示されたＰＤＳＣＨの受信処理を行うように受信信号処理部４０４を制御し、当該ＰＤＳＣＨの受信に成功したか否かを示すＨＡＲＱ−ＡＣＫを、所定のＰＵＣＣＨフォーマット及び所定のＰＵＣＣＨリソースで送信するように送信信号生成部４０２及びマッピング部４０３を制御する。
【０１７７】
制御部４０１は、ＨＡＲＱ−ＡＣＫの送信に用いる所定のＰＵＣＣＨフォーマットを決定する。制御部４０１は、当該ＰＵＣＣＨフォーマットを、ＰＤＳＣＨを割り当てるＰＤＣＣＨ／ＥＰＤＣＣＨの数に基づいて判断してもよいし（実施形態１．１）と、ＰＤＳＣＨが割り当てられるＣＣのＣＣ番号に基づいて判断してもよいし（実施形態１．２）、上位レイヤシグナリングで設定されたＣＣ数に基づいて判断してもよいし（実施形態１．３）、ＤＣＩに含まれるＡＲＩに基づいて判断してもよい（実施形態２．３）。
【０１７８】
制御部４０１は、ＨＡＲＱ−ＡＣＫの送信に用いる所定のＰＵＣＣＨリソースを決定する。制御部４０１は、新規ＰＵＣＣＨフォーマットを用いることを決定した場合、ＳＣｅｌｌをスケジューリングするＤＣＩに含まれるＡＲＩと、所定のＡＲＩテーブルと、に基づいて、新規ＰＵＣＣＨフォーマット用のＰＵＣＣＨリソースを決定する。
【０１７９】
ここで、制御部４０１は、新規ＰＵＣＣＨフォーマットのＰＵＣＣＨリソースを、他のＰＵＣＣＨフォーマットと同じＡＲＩテーブルに基づいて決定してもよいし（実施形態２．１）、異なるＡＲＩテーブルに基づいて決定してもよい（実施形態２．２、２．３）。
【０１８０】
制御部４０１は、受信したＤＣＩに含まれるＡＲＩを、新規ＰＵＣＣＨフォーマットを用いる場合には新規ＰＵＣＣＨフォーマット用のＡＲＩとして解釈してもよい（実施形態２．１）。また、制御部４０１は、受信したＤＣＩに含まれるＡＲＩを、検出したＰＤＣＣＨ／ＥＰＤＣＣＨの数やスケジューリングされるＣＣ、利用するＰＵＣＣＨフォーマットの種類などによって、新規ＰＵＣＣＨフォーマット用のＡＲＩとして解釈してもよい（実施形態２．２）。
【０１８１】
また、制御部４０１は、受信したＤＣＩに複数のＡＲＩ（例えば、ＰＵＣＣＨフォーマット３用のＡＲＩ、新規ＰＵＣＣＨフォーマット用のＡＲＩ）が含まれる場合には、一方のＡＲＩを新規ＰＵＣＣＨフォーマット用のＡＲＩとして解釈してもよい（実施形態２．３）。
【０１８２】
例えば、制御部４０１は、新規ＰＵＣＣＨフォーマット用のＡＲＩが所定の値でない場合、当該ＡＲＩを用いて新規ＰＵＣＣＨフォーマット用のＰＵＣＣＨリソースを決定し、新規ＰＵＣＣＨフォーマット用のＡＲＩが所定の値である場合、ＰＵＣＣＨフォーマット３用のＡＲＩを用いてＰＵＣＣＨフォーマット３用のＰＵＣＣＨリソースを決定してもよい。なお、「所定の値である／ない」は逆であってもよい。
【０１８３】
また、制御部４０１は、受信したＤＣＩにＴＤＡＩ及び／又はスケジュールされたＣＣに対応したビットを含むビットマップ（ビット列）が含まれる場合には、これらの少なくとも１つに基づいて、受信したＤＣＩに含まれるＡＲＩが新規ＰＵＣＣＨフォーマット用のＡＲＩであるか否かを判断し、新規ＰＵＣＣＨフォーマット用のリソースを決定してもよい（第３、第４の実施形態）。
【０１８４】
例えば、制御部４０１は、ＴＤＡＩが所定の値である場合、当該ＡＲＩを用いて新規ＰＵＣＣＨフォーマット用のＰＵＣＣＨリソースを決定し、ＴＤＡＩが所定の値でない場合、ＰＵＣＣＨフォーマット３用のＡＲＩを用いてＰＵＣＣＨフォーマット３用のＰＵＣＣＨリソースを決定してもよい。なお、「所定の値である／ない」は逆であってもよいし、「所定の値」は「所定の範囲の値」であってもよい。
【０１８５】
例えば、制御部４０１は、ビットマップが所定数より多い‘１’を含む場合、当該ＡＲＩを用いて新規ＰＵＣＣＨフォーマット用のＰＵＣＣＨリソースを決定し、ビットマップが所定数以下の‘１’を含む場合、ＰＵＣＣＨフォーマット３用のＡＲＩを用いてＰＵＣＣＨフォーマット３用のＰＵＣＣＨリソースを決定してもよい。なお、「所定数より多い／以下の」は逆であってもよいし、「より多い」は「以上」であってもよいし、「以下の」は「より少ない」であってもよい。
【０１８６】
また、制御部４０１は、１つ又は複数のＡＲＩテーブル（例えば、ＰＵＣＣＨフォーマット３用のＡＲＩテーブル、新規ＰＵＣＣＨフォーマット用のＡＲＩテーブル）に関する情報を受信信号処理部４０４から入力された場合には、対応するＡＲＩテーブルの内容を更新してもよい。
【０１８７】
送信信号生成部４０２は、制御部４０１からの指示に基づいて、上り信号（上り制御信号、上りデータ信号、上り参照信号など）を生成して、マッピング部４０３に出力する。送信信号生成部４０２は、本発明に係る技術分野での共通認識に基づいて説明される信号生成器、信号生成回路又は信号生成装置から構成することができる。
【０１８８】
送信信号生成部４０２は、例えば、制御部４０１からの指示に基づいて、送達確認信号（ＨＡＲＱ−ＡＣＫ）やチャネル状態情報（ＣＳＩ）に関する上り制御信号を生成する。また、送信信号生成部４０２は、制御部４０１からの指示に基づいて上りデータ信号を生成する。例えば、送信信号生成部４０２は、無線基地局１０から通知される下り制御信号にＵＬグラントが含まれている場合に、制御部４０１から上りデータ信号の生成を指示される。
【０１８９】
マッピング部４０３は、制御部４０１からの指示に基づいて、送信信号生成部４０２で生成された上り信号を無線リソースにマッピングして、送受信部２０３へ出力する。マッピング部４０３は、本発明に係る技術分野での共通認識に基づいて説明されるマッパー、マッピング回路又はマッピング装置から構成することができる。
【０１９０】
受信信号処理部４０４は、送受信部２０３から入力された受信信号に対して、受信処理（例えば、デマッピング、復調、復号など）を行う。ここで、受信信号は、例えば、無線基地局１０から送信される下り信号（下り制御信号、下りデータ信号、下り参照信号など）である。受信信号処理部４０４は、本発明に係る技術分野での共通認識に基づいて説明される信号処理器、信号処理回路又は信号処理装置から構成することができる。また、受信信号処理部４０４は、本発明に係る受信部を構成することができる。
【０１９１】
受信信号処理部４０４は、受信処理により復号された情報を制御部４０１に出力する。受信信号処理部４０４は、例えば、報知情報、システム情報、ＲＲＣシグナリング、ＤＣＩなどを、制御部４０１に出力する。また、受信信号処理部４０４は、受信信号や、受信処理後の信号を、測定部４０５に出力する。
【０１９２】
測定部４０５は、受信した信号に関する測定を実施する。測定部４０５は、本発明に係る技術分野での共通認識に基づいて説明される測定器、測定回路又は測定装置から構成することができる。
【０１９３】
測定部４０５は、例えば、受信した信号の受信電力（例えば、ＲＳＲＰ）、受信品質（例えば、ＲＳＲＱ）やチャネル状態などについて測定してもよい。測定結果は、制御部４０１に出力されてもよい。
【０１９４】
なお、上記実施形態の説明に用いたブロック図は、機能単位のブロックを示している。これらの機能ブロック（構成部）は、ハードウェア及びソフトウェアの任意の組み合わせによって実現される。また、各機能ブロックの実現手段は特に限定されない。すなわち、各機能ブロックは、物理的に結合した１つの装置により実現されてもよいし、物理的に分離した２つ以上の装置を有線又は無線で接続し、これら複数の装置により実現されてもよい。
【０１９５】
例えば、無線基地局１０やユーザ端末２０の各機能の一部又は全ては、ＡＳＩＣ（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）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、その他の適切なシステムを利用するシステム及び／又はこれらに基づいて拡張された次世代システムに適用されてもよい。
【０２０６】
本明細書で説明した各態様／実施形態の処理手順、シーケンス、フローチャートなどは、矛盾の無い限り、順序を入れ替えてもよい。例えば、本明細書で説明した方法については、例示的な順序で様々なステップの要素を提示しており、提示した特定の順序に限定されない。
【０２０７】
以上、本発明について詳細に説明したが、当業者にとっては、本発明が本明細書中に説明した実施形態に限定されるものではないということは明らかである。本発明は、特許請求の範囲の記載により定まる本発明の趣旨及び範囲を逸脱することなく修正及び変更態様として実施することができる。したがって、本明細書の記載は、例示説明を目的とするものであり、本発明に対して何ら制限的な意味を有するものではない。
【符号の説明】
【０２０８】
１  無線通信システム
１０  無線基地局
２０  ユーザ端末
１０１、２０１  送受信アンテナ
１０２、２０２  アンプ部
１０３、２０３  送受信部
１０４、２０４  ベースバンド信号処理部
１０５  呼処理部
１０６  伝送路インターフェース
２０５  アプリケーション部
３０１、４０１  制御部
３０２、４０２  送信信号生成部
３０３、４０３  マッピング部
３０４、４０４  受信信号処理部
３０５、４０５  測定部
【図１】
2017017372.tif 000003
【図２】
2017017372.tif 000004
【図３】
2017017372.tif 000005
【図４】
2017017372.tif 000006
【図５】
2017017372.tif 000007
【図６】
2017017372.tif 000008
【図７】
2017017372.tif 000009
【図８】
2017017372.tif 000010
【図９】
2017017372.tif 000011
【図１０】
2017017372.tif 000012
【図１１】
2017017372.tif 000013
【図１２】
2017017372.tif 000014
【図１３】
2017017372.tif 000015
【図１４】
2017017372.tif 000016
【手続補正書】
【提出日】平成28年6月24日(2016.6.24)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
下り共有チャネルの受信の指示情報を、下り制御チャネルで検出する受信部と、
前記指示情報に対応する下り共有チャネルの受信に関する上り制御情報を送信する送信部と、
ＰＵＣＣＨ（Physical  Uplink  Control  Channel）フォーマット３に比べて容量の大きな大容量ＰＵＣＣＨフォーマットを含む複数のＰＵＣＣＨフォーマットから、前記上り制御情報を送信するＰＵＣＣＨフォーマットを決定する制御部と、を有し、
前記制御部は、前記指示情報に基づいて、大容量ＰＵＣＣＨフォーマットで送信するＰＵＣＣＨリソースを決定することを特徴とするユーザ端末。
【請求項２】
前記指示情報は、ＡＲＩ（Acknowledgement  Resource  Indicator）を含み、
前記制御部は、当該ＡＲＩと、上位レイヤシグナリングでＰＵＣＣＨフォーマットごとに独立に設定される、ＰＵＣＣＨリソースとＡＲＩとの対応関係と、に基づいて、大容量ＰＵＣＣＨフォーマットで送信するＰＵＣＣＨリソースを決定することを特徴とする請求項１に記載のユーザ端末。
【請求項３】
前記受信部は、前記ＰＵＣＣＨリソースとＡＲＩとの対応関係に関する情報として、ＰＵＣＣＨフォーマット３に関するＰＵＣＣＨリソースとＡＲＩとの第１の対応関係に関する情報と、大容量ＰＵＣＣＨフォーマットに関するＰＵＣＣＨリソースとＡＲＩとの第２の対応関係に関する情報と、を受信し、
前記制御部は、前記上り制御情報をＰＵＣＣＨフォーマット３で送信すると判断する場合には、前記ＡＲＩ及び前記第１の対応関係に基づいて、ＰＵＣＣＨフォーマット３で送信するＰＵＣＣＨリソースを決定し、前記上り制御情報を大容量ＰＵＣＣＨフォーマットで送信すると判断する場合には、前記ＡＲＩ及び前記第２の対応関係に基づいて、大容量ＰＵＣＣＨフォーマットで送信するＰＵＣＣＨリソースを決定することを特徴とする請求項２に記載のユーザ端末。
【請求項４】
前記制御部は、前記指示情報に含まれるＴＰＣ（Transmit  Power  Control）フィールドを、前記ＡＲＩとして解釈することを特徴とする請求項２又は請求項３に記載のユーザ端末。
【請求項５】
前記送信部は、大容量ＰＵＣＣＨフォーマットを設定できることを示す端末能力情報を送信し、
前記受信部は、前記端末能力情報に応じて送信された、大容量ＰＵＣＣＨフォーマットを用いるか否かに関する情報を受信することを特徴とする請求項１から請求項４のいずれかに記載のユーザ端末。
【請求項６】
前記大容量ＰＵＣＣＨフォーマットを設定できることを示す端末能力情報は、５個より多いコンポーネントキャリアのキャリアアグリゲーションを設定できることを示す端末能力情報とは別の情報であることを特徴とする請求項５に記載のユーザ端末。
【請求項７】
下り共有チャネルの受信の指示情報を、下り制御チャネルで送信する送信部と、
前記指示情報に対応する下り共有チャネルの受信に関する上り制御情報を受信する受信部と、
前記上り制御情報を送信するＰＵＣＣＨリソースを制御する制御部と、を有し、
前記制御部は、ＰＵＣＣＨ（Physical  Uplink  Control  Channel）フォーマット３に比べて容量の大きな大容量ＰＵＣＣＨフォーマットで送信されるＰＵＣＣＨリソースを制御し、
前記制御部は、前記指示情報に、大容量ＰＵＣＣＨフォーマットで送信するＰＵＣＣＨリソースの決定に用いる情報を含めるように制御することを特徴とする無線基地局。
【請求項８】
下り共有チャネルの受信の指示情報を、下り制御チャネルで検出する工程と、
前記指示情報に対応する下り共有チャネルの受信に関する上り制御情報を送信する工程と、
ＰＵＣＣＨ（Physical  Uplink  Control  Channel）フォーマット３に比べて容量の大きな大容量ＰＵＣＣＨフォーマットを含む複数のＰＵＣＣＨフォーマットから、前記上り制御情報を送信するＰＵＣＣＨフォーマットを決定する工程と、
前記指示情報に基づいて、大容量ＰＵＣＣＨフォーマットで送信するＰＵＣＣＨリソースを決定する工程と、を有することを特徴とする無線通信方法。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】０００１
【補正方法】変更
【補正の内容】
【０００１】
本発明は、次世代移動通信システムにおけるユーザ端末、無線基地局及び無線通信方法に関する。
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】０００８
【補正方法】変更
【補正の内容】
【０００８】
本発明はかかる点に鑑みてなされたものであり、ユーザ端末に設定可能なコンポーネントキャリア数が既存システムより拡張される場合であっても、通信を適切に行うことができるユーザ端末、無線基地局及び無線通信方法を提供することを目的とする。
【手続補正５】
【補正対象書類名】明細書
【補正対象項目名】０００９
【補正方法】変更
【補正の内容】
【０００９】
本発明の一態様に係るユーザ端末は、下り共有チャネルの受信の指示情報を、下り制御チャネルで検出する受信部と、前記指示情報に対応する下り共有チャネルの受信に関する上り制御情報を送信する送信部と、ＰＵＣＣＨ（Physical  Uplink  Control  Channel）フォーマット３に比べて容量の大きな大容量ＰＵＣＣＨフォーマットを含む複数のＰＵＣＣＨフォーマットから、前記上り制御情報を送信するＰＵＣＣＨフォーマットを決定する制御部と、を有し、前記制御部は、前記指示情報に基づいて、大容量ＰＵＣＣＨフォーマットで送信するＰＵＣＣＨリソースを決定する。
【手続補正書】
【提出日】平成28年10月20日(2016.10.20)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
下り共有チャネルの受信の指示情報を、下り制御チャネルで検出する受信部と、
前記指示情報に対応する下り共有チャネルの受信に関する上り制御情報を送信する送信部と、
ＰＵＣＣＨ（Physical  Uplink  Control  Channel）フォーマット３に比べて容量の大きな大容量ＰＵＣＣＨフォーマットを含む複数のＰＵＣＣＨフォーマットから、前記上り制御情報を送信するＰＵＣＣＨフォーマットを決定する制御部と、を有し、
前記制御部は、前記指示情報に基づいて、大容量ＰＵＣＣＨフォーマットで送信するＰＵＣＣＨリソースを決定し、
前記指示情報は、ＡＲＩ（Acknowledgement  Resource  Indicator）を含み、
前記制御部は、当該ＡＲＩと、上位レイヤシグナリングでＰＵＣＣＨフォーマットごとに独立に設定される、ＰＵＣＣＨリソースとＡＲＩとの対応関係と、に基づいて、大容量ＰＵＣＣＨフォーマットで送信するＰＵＣＣＨリソースを決定し、
前記受信部は、前記ＰＵＣＣＨリソースとＡＲＩとの対応関係に関する情報として、ＰＵＣＣＨフォーマット３に関するＰＵＣＣＨリソースとＡＲＩとの第１の対応関係に関する情報と、大容量ＰＵＣＣＨフォーマットに関するＰＵＣＣＨリソースとＡＲＩとの第２の対応関係に関する情報と、を受信し、
前記制御部は、前記上り制御情報をＰＵＣＣＨフォーマット３で送信すると判断する場合には、前記ＡＲＩ及び前記第１の対応関係に基づいて、ＰＵＣＣＨフォーマット３で送信するＰＵＣＣＨリソースを決定し、前記上り制御情報を大容量ＰＵＣＣＨフォーマットで送信すると判断する場合には、前記ＡＲＩ及び前記第２の対応関係に基づいて、大容量ＰＵＣＣＨフォーマットで送信するＰＵＣＣＨリソースを決定することを特徴とするユーザ端末。
【請求項２】
前記制御部は、前記指示情報に含まれるＴＰＣ（Transmit  Power  Control）フィールドを、前記ＡＲＩとして解釈することを特徴とする請求項１に記載のユーザ端末。
【請求項３】
前記送信部は、大容量ＰＵＣＣＨフォーマットを設定できることを示す端末能力情報を送信し、
前記受信部は、前記端末能力情報に応じて送信された、大容量ＰＵＣＣＨフォーマットを用いるか否かに関する情報を受信することを特徴とする請求項１又は請求項２に記載のユーザ端末。
【請求項４】
前記大容量ＰＵＣＣＨフォーマットを設定できることを示す端末能力情報は、５個より多いコンポーネントキャリアのキャリアアグリゲーションを設定できることを示す端末能力情報とは別の情報であることを特徴とする請求項３に記載のユーザ端末。
【請求項５】
下り共有チャネルの受信の指示情報を、下り制御チャネルで送信する送信部と、
前記指示情報に対応する下り共有チャネルの受信に関する上り制御情報を受信する受信部と、
前記上り制御情報を送信するＰＵＣＣＨリソースを制御する制御部と、を有し、
前記制御部は、ＰＵＣＣＨ（Physical  Uplink  Control  Channel）フォーマット３に比べて容量の大きな大容量ＰＵＣＣＨフォーマットで送信されるＰＵＣＣＨリソースを制御し、
前記制御部は、前記指示情報に、大容量ＰＵＣＣＨフォーマットで送信するＰＵＣＣＨリソースの決定に用いる情報を含めるように制御し、
前記指示情報は、ＡＲＩ（Acknowledgement  Resource  Indicator）を含み、
前記制御部は、当該ＡＲＩと、上位レイヤシグナリングでＰＵＣＣＨフォーマットごとに独立に設定する、ＰＵＣＣＨリソースとＡＲＩとの対応関係と、に基づいて、大容量ＰＵＣＣＨフォーマットで送信されるＰＵＣＣＨリソースを制御し、
前記送信部は、前記ＰＵＣＣＨリソースとＡＲＩとの対応関係に関する情報として、ＰＵＣＣＨフォーマット３に関するＰＵＣＣＨリソースとＡＲＩとの第１の対応関係に関する情報と、大容量ＰＵＣＣＨフォーマットに関するＰＵＣＣＨリソースとＡＲＩとの第２の対応関係に関する情報と、を送信し、
前記受信部は、前記上り制御情報がＰＵＣＣＨフォーマット３で送信される場合には、前記ＡＲＩ及び前記第１の対応関係に基づいて決定されるＰＵＣＣＨリソースで、前記上り制御情報を受信し、前記上り制御情報が大容量ＰＵＣＣＨフォーマットで送信される場合には、前記ＡＲＩ及び前記第２の対応関係に基づいて決定されるＰＵＣＣＨリソースで、前記上り制御情報を受信することを特徴とする無線基地局。
【請求項６】
ユーザ端末の無線通信方法であって、
下り共有チャネルの受信の指示情報を、下り制御チャネルで検出する工程と、
前記指示情報に対応する下り共有チャネルの受信に関する上り制御情報を送信する工程と、
ＰＵＣＣＨ（Physical  Uplink  Control  Channel）フォーマット３に比べて容量の大きな大容量ＰＵＣＣＨフォーマットを含む複数のＰＵＣＣＨフォーマットから、前記上り制御情報を送信するＰＵＣＣＨフォーマットを決定する工程と、
前記指示情報に基づいて、大容量ＰＵＣＣＨフォーマットで送信するＰＵＣＣＨリソースを決定する工程と、を有し、
前記指示情報は、ＡＲＩ（Acknowledgement  Resource  Indicator）を含み、
当該ＡＲＩと、上位レイヤシグナリングでＰＵＣＣＨフォーマットごとに独立に設定される、ＰＵＣＣＨリソースとＡＲＩとの対応関係と、に基づいて、大容量ＰＵＣＣＨフォーマットで送信するＰＵＣＣＨリソースを決定する工程と、
前記ＰＵＣＣＨリソースとＡＲＩとの対応関係に関する情報として、ＰＵＣＣＨフォーマット３に関するＰＵＣＣＨリソースとＡＲＩとの第１の対応関係に関する情報と、大容量ＰＵＣＣＨフォーマットに関するＰＵＣＣＨリソースとＡＲＩとの第２の対応関係に関する情報と、を受信する工程と、
前記上り制御情報をＰＵＣＣＨフォーマット３で送信すると判断する場合には、前記ＡＲＩ及び前記第１の対応関係に基づいて、ＰＵＣＣＨフォーマット３で送信するＰＵＣＣＨリソースを決定し、前記上り制御情報を大容量ＰＵＣＣＨフォーマットで送信すると判断する場合には、前記ＡＲＩ及び前記第２の対応関係に基づいて、大容量ＰＵＣＣＨフォーマットで送信するＰＵＣＣＨリソースを決定する工程と、を有することを特徴とする無線通信方法。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】０００９
【補正方法】変更
【補正の内容】
【０００９】
本発明の一態様に係るユーザ端末は、下り共有チャネルの受信の指示情報を、下り制御チャネルで検出する受信部と、前記指示情報に対応する下り共有チャネルの受信に関する上り制御情報を送信する送信部と、ＰＵＣＣＨ（Physical  Uplink  Control  Channel）フォーマット３に比べて容量の大きな大容量ＰＵＣＣＨフォーマットを含む複数のＰＵＣＣＨフォーマットから、前記上り制御情報を送信するＰＵＣＣＨフォーマットを決定する制御部と、を有し、前記制御部は、前記指示情報に基づいて、大容量ＰＵＣＣＨフォーマットで送信するＰＵＣＣＨリソースを決定し、前記指示情報は、ＡＲＩ（Acknowledgement  Resource  Indicator）を含み、前記制御部は、当該ＡＲＩと、上位レイヤシグナリングでＰＵＣＣＨフォーマットごとに独立に設定される、ＰＵＣＣＨリソースとＡＲＩとの対応関係と、に基づいて、大容量ＰＵＣＣＨフォーマットで送信するＰＵＣＣＨリソースを決定し、前記受信部は、前記ＰＵＣＣＨリソースとＡＲＩとの対応関係に関する情報として、ＰＵＣＣＨフォーマット３に関するＰＵＣＣＨリソースとＡＲＩとの第１の対応関係に関する情報と、大容量ＰＵＣＣＨフォーマットに関するＰＵＣＣＨリソースとＡＲＩとの第２の対応関係に関する情報と、を受信し、前記制御部は、前記上り制御情報をＰＵＣＣＨフォーマット３で送信すると判断する場合には、前記ＡＲＩ及び前記第１の対応関係に基づいて、ＰＵＣＣＨフォーマット３で送信するＰＵＣＣＨリソースを決定し、前記上り制御情報を大容量ＰＵＣＣＨフォーマットで送信すると判断する場合には、前記ＡＲＩ及び前記第２の対応関係に基づいて、大容量ＰＵＣＣＨフォーマットで送信するＰＵＣＣＨリソースを決定する。