(57)【特許請求の範囲】
【請求項１】
基地局装置から追加又は削除された単位キャリアを示す設定情報を受信し、前記設定情報は新たに追加される単位キャリアの単位キャリア識別情報に割り当てられたＣＩＦ値と前記追加される単位キャリアの識別情報とを含むものであり、前記基地局装置において、１以上の単位キャリアに対して新たな単位キャリアの追加が行われる場合に、前記１以上の単位キャリアの各単位キャリアのラベルとして用いられるＣＩＦ値と単位キャリア識別情報との対応関係を維持したまま、前記新たに追加される単位キャリアの識別情報に対して、未設定のＣＩＦ値が割り当てられる、受信部と、
前記設定情報に基づいて、既に保持している前記ＣＩＦ値と前記単位キャリア識別情報との対応関係を修正する設定部と、
を具備する端末装置。
【請求項２】
前記受信部は、自端末に割り当てられた単位キャリアに対応するＣＩＦ値を含むリソース割当情報を受信する、
請求項１記載の端末装置。
【請求項３】
データを受信する際に使用される単位キャリアに対してのみ、前記ＣＩＦ値が割り当てられている、
請求項１又は２記載の端末装置。
【請求項４】
前記ＣＩＦ値と前記単位キャリアの識別情報との対応関係は、端末装置毎に設定される、
請求項１から３いずれか一項に記載の端末装置。
【請求項５】
基地局装置から追加又は削除された単位キャリアを示す設定情報を受信し、前記設定情報は新たに追加される単位キャリアの単位キャリア識別情報に割り当てられたＣＩＦ値と前記追加される単位キャリアの識別情報とを含み、前記基地局装置において、１以上の単位キャリアに対して新たな単位キャリアの追加が行われる場合に、前記１以上の単位キャリアの各単位キャリアのラベルとして用いられるＣＩＦ値と単位キャリア識別情報との対応関係を維持したまま、前記新たに追加される単位キャリアの識別情報に対して、未設定のＣＩＦ値が割り当てられ、
前記設定情報に基づいて、既に保持している前記ＣＩＦ値と前記単位キャリア識別情報との対応関係を修正する、
通信方法。
【請求項６】
前記設定情報の受信において、自端末に割り当てられたリソース割当情報を受信する、
請求項５記載の通信方法。
【請求項７】
データを受信する際に使用される単位キャリアに対してのみ、前記ＣＩＦ値が割り当てられている、
請求項５又は６記載の通信方法。
【請求項８】
前記ＣＩＦ値と前記単位キャリアの識別情報との対応関係は、端末装置毎に設定される、
請求項５から７いずれか一項に記載の通信方法。
【請求項９】
基地局装置から追加又は削除された単位キャリアを示す設定情報を受信する処理と、前記基地局装置において、１以上の単位キャリアに対して新たな単位キャリアの追加が行われる場合に、前記１以上の単位キャリアの各単位キャリアのラベルとして用いられるＣＩＦ値と単位キャリア識別情報との対応関係を維持したまま、前記追加される単位キャリアの識別情報に対して、未設定のＣＩＦ値が割り当てられ、前記設定情報は前記追加される単位キャリアに割り当てられたＣＩＦ値と前記追加される単位キャリアの識別情報とを含むものであり、
前記設定情報に基づいて、既に保持している前記ＣＩＦ値と前記単位キャリア識別情報との対応関係を修正する処理と、
を制御する集積回路。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、端末装置、通信方法及び集積回路に関する。
【背景技術】
【０００２】
３ＧＰＰ−ＬＴＥ(3rd Generation Partnership Project Radio Access Network Long Term Evolution、以下、ＬＴＥという)では、下り回線の通信方式としてＯＦＤＭＡ（Orthogonal Frequency Division Multiple Access）が採用され、上り回線の通信方式としてＳＣ−ＦＤＭＡ（Single Carrier Frequency Division Multiple Access）が採用されている（例えば、非特許文献１、２、３参照）。
【０００３】
ＬＴＥでは、無線通信基地局装置（以下、基地局と省略する）はシステム帯域内のリソースブロック（Resource Block：ＲＢ）を、サブフレームと呼ばれる時間単位毎に無線通信端末装置（以下、端末と省略する）に割り当てることにより通信を行う。また、基地局は下り回線データおよび上り回線データのリソース割当結果を通知するための制御情報（リソース割当情報）を端末へ送信する。この制御情報は例えばＰＤＣＣＨ（Physical Downlink Control Channel）等の下り回線制御チャネルを用いて端末へ送信される。ここで、基地局は、端末の割当数等に応じて、ＰＤＣＣＨの送信に用いるリソース量、つまり、ＯＦＤＭシンボル数をサブフレーム単位で制御する。具体的には、基地局は、各サブフレームの先頭のＯＦＤＭシンボルでＰＤＣＣＨの送信に使用可能なＯＦＤＭシンボル数を示す情報であるＣＦＩ（Control Format Indicator）を、ＰＣＦＩＣＨ（Physical Control Format Indicator Channel）を用いて端末へ送信する。端末は、受信したＰＣＦＩＣＨから検出したＣＦＩに従ってＰＤＣＣＨを受信する。なお、各ＰＤＣＣＨは１つまたは連続する複数のＣＣＥ（Control Channel Element）で構成されるリソースを占有する。ＬＴＥでは、ＰＤＣＣＨが占有するＣＣＥ数（ＣＣＥ連結数：CCE aggregation level）は、制御情報の情報ビット数または端末の伝搬路状態に応じて、１，２，４，８の中の１つが選択される。なお、ＬＴＥでは、システム帯域幅として最大２０ＭＨｚの幅を持つ周波数帯域がサポートされる。
【０００４】
また、基地局は１サブフレームに複数の端末を割り当てるため、複数のＰＤＣＣＨを同時に送信する。このとき、基地局は、各ＰＤＣＣＨの送信先の端末を識別するために、送信先の端末ＩＤでマスキング（または、スクランブリング）したＣＲＣビットをＰＤＣＣＨに含めて送信する。そして、端末は、自端末宛ての可能性がある複数のＰＤＣＣＨにおいて、自端末の端末ＩＤでＣＲＣビットをデマスキング（または、デスクランブリング）することによりＰＤＣＣＨをブラインド復号して自端末宛のＰＤＣＣＨを検出する。
【０００５】
また、端末でのブラインド復号の回数を削減することを目的として、ブラインド復号の対象となるＣＣＥを、端末毎に限定する方法が検討されている。この方法では、端末毎に、ブラインド復号対象となるＣＣＥ領域（以下、サーチスペース（Search Space）という）を限定する。ＬＴＥでは、サーチスペースは端末毎にランダムに設定され、サーチスペースを構成するＣＣＥ数はＰＤＣＣＨのＣＣＥ連結数毎に定義される。例えば、ＣＣＥ連結数１，２，４，８それぞれに対して、サーチスペースを構成するＣＣＥ数、つまり、ブラインド復号対象となるＣＣＥは６候補（６（＝１×６）ＣＣＥ），６候補（１２（＝２×６）ＣＣＥ），２候補（８（＝４×２）ＣＣＥ），２候補（１６（＝８×２）ＣＣＥ）にそれぞれ限定される。これにより、各端末は、自端末に割り当てられたサーチスペース内のＣＣＥに対してのみ、ブラインド復号を行えばよいため、ブラインド復号の回数を削減することができる。ここで、各端末のサーチスペースは、各端末の端末ＩＤと、ランダム化を行う関数であるハッシュ（ｈａｓｈ）関数とを用いて設定される。
【０００６】
また、ＬＴＥでは、基地局から端末への下り回線データに対してＡＲＱ（Automatic Repeat Request）が適用される。つまり、端末は下り回線データの誤り検出結果を示す応答信号を基地局へフィードバックする。端末は下り回線データに対しＣＲＣを行って、ＣＲＣ＝ＯＫ（誤り無し）であればＡＣＫ（Acknowledgment）を、ＣＲＣ＝ＮＧ（誤り有り）であればＮＡＣＫ（Negative Acknowledgment）を応答信号（つまり、ＡＣＫ／ＮＡＣＫ信号）として基地局へフィードバックする。そして、基地局は、フィードバックされた応答信号がＮＡＣＫを示す場合には、端末に対して再送データを送信する。また、ＬＴＥでは、誤り訂正符号化とＡＲＱとを組合せたＨＡＲＱ（Hybrid ARQ）と呼ばれるデータ再送制御が検討されている。ＨＡＲＱでは、端末は、再送されるデータを受信するときに、再送データと前回受信した誤りの含まれるデータとを合成することにより、端末側での受信品質を高めることができる。
【０００７】
また、ＬＴＥよりも更なる通信の高速化を実現する３ＧＰＰ  ＬＴＥ−Ａｄｖａｎｃｅｄ（以下、ＬＴＥ−Ａという）の標準化が開始された。ＬＴＥ−Ａでは、最大１Ｇｂｐｓ以上の下り伝送速度および最大５００Ｍｂｐｓ以上の上り伝送速度を実現するために、４０ＭＨｚ以上の広帯域周波数で通信可能な基地局および端末（以下、ＬＴＥ−Ａ端末という）が導入される見込みである。また、ＬＴＥ−Ａシステムは、ＬＴＥ−Ａ端末のみでなく、ＬＴＥシステムに対応する端末（以下、ＬＴＥ端末という）を収容することが要求されている。
【０００８】
そして、ＬＴＥ−Ａでは、４０ＭＨｚ以上の広帯域通信を実現するために、複数の周波数帯域を連結して通信するキャリアキャリア連結（Carrier aggregation）方式が提案されている（例えば、非特許文献１参照）。例えば、２０ＭＨｚの幅を持つ周波数帯域が通信帯域の基本単位(以下、単位キャリア（component carrier: CC）という)とされている。よって、ＬＴＥ−Ａでは、例えば、２つの単位キャリアを連結することにより４０ＭＨｚのシステム帯域幅を実現する。また、１つの単位キャリアには、ＬＴＥ端末およびＬＴＥ−Ａ端末の双方が収容される。なお、以下の説明では、上り回線における単位キャリアを上り単位キャリアと呼び、下り回線における単位キャリアを下り単位キャリアと呼ぶ。
【０００９】
ＬＴＥ−Ａではシステムとして少なくとも５つのＣＣによるキャリア連結をサポートすることが検討されているが、各端末のＣＣ数の受信能力や要求される伝送レートなどによって実際に使われるＣＣ数は端末ごとに異なる。そこで、どのＣＣを用いるのかは端末ごとに設定(Configure)される。設定されたＣＣを「UE CC set」と呼ぶ。また、UE CC setは端末の要求伝送レートによりsemi-staticに制御される。
【００１０】
また、ＬＴＥ−Ａでは各単位キャリアのリソース割当情報を基地局から端末へ通知する方法として、ある単位キャリアで送信されるＰＤＣＣＨで異なる単位キャリアのデータを割り当てることが議論されている（例えば、非特許文献４）。具体的にはＰＤＣＣＨ内のCarrier Indicator(CI)を用いてそのＰＤＣＣＨが割当対象とする単位キャリアを指示することが検討されている。すなわち、ＣＩによって、各単位キャリアがラベリングされる。ＣＩはＣＩＦ(Carrier Indicator Field)と呼ばれるＰＤＣＣＨ内のフィールドで送信される。
【００１１】
また、ＣＩＦ内でＣＩに加えて割当対象の単位キャリアのＣＩＦ値を合わせて通知することも検討されている（非特許文献５）。
【００１２】
また、上記した非特許文献４には、ＣＩの値(つまり、コードポイント)とそれが示すＣＣ番号との対応付けに関して、開示がある。すなわち、ＰＤＣＣＨが送信されたＣＣと同一のＣＣを割り当てる場合には、ＣＩ＝１(ＣＩが１から始まる場合)を割り当てる。その他のＣＣに関しては、周波数の低いＣＣから順にＣＩの値が対応付けられる。例えば、図１Ｂのように、３つのＣＣ(周波数の低い順にCC1,CC2,CC3)が存在し、３つ全てのＣＣが端末に設定されている場合(つまり、UE CC setがCC1,CC2,CC3の場合)には、ＣＣ２で送信されるＰＤＣＣＨではＣＩ＝１でＣＣ２のデータ割当を示し、ＣＩ＝２でＣＣ１のデータ割当を示し、ＣＩ＝３でＣＣ３のデータ割当を示す。一方、図１Ａのように、３つのうち２つのＣＣが設定されている場合（例えば、UE CC setがCC2，CC3の場合）には、ＣＩ＝１でＣＣ２のデータ割当を示し、ＣＩ＝２でＣＣ３のデータ割当を示す。この場合、各端末のＣＣの設定(つまり、UE CC set)が変更される度に、同一ＣＣを割り当てるＣＩ以外は、ＣＩとＣＣ番号との対応付けが変化する。上記の例では、ＣＣ１とＣＣ２とが設定されている端末に対して、ＣＣ１をUE CC Setに追加する場合には、ＣＣ３を割り当てるＣＩのコードポイントがＣＣ追加の前後で変化する。
【００１３】
ここで、UE CC setの変更（つまり、ＣＣの追加及び削除）は例えば非特許文献６記載のＲＲＣシグナリングで行うことが検討されている。より具体的にはRRC connection reconfiguration procedureにより行う。UE CC setの変更の際には、基地局はまずRRC connection reconfiguration messageを端末に変更の旨を通知する。このメッセージを受信した端末は設定を変更し、変更が完了したらRRC connection reconfiguration complete messageを基地局に報告する。基地局はRRC connection reconfiguration complete messageを受信することにより端末で設定変更が正常に完了したことを知ることができる。ここで、これらのメッセージのやり取りには通常数10ms〜100msの時間がかかる。
【先行技術文献】
【非特許文献】
【００１４】
【非特許文献１】3GPP TS 36.211 V8.3.0, “Physical Channels and Modulation (Release 8),” May 2008
【非特許文献２】3GPP TS 36.212 V8.3.0, “Multiplexing and channel coding (Release 8),” May 2008
【非特許文献３】3GPP TS 36.213 V8.3.0, “Physical layer procedures (Release 8),” May 2008
【非特許文献４】3GPP TSG RAN WG1 meeting, R1-100041, “Mapping of CIF to component carrier” January 2010
【非特許文献５】3GPP TSG RAN WG1 meeting, R1-100360, “PCFICH in cross carrier operation” January 2010
【非特許文献６】3GPP TS 36.331 V8.7.0 ”Radio Resource Control (RRC)”, (2009-09)
【発明の概要】
【発明が解決しようとする課題】
【００１５】
しかしながら、上記した非特許文献４におけるＣＩとＣＣ番号との対応付けによれば、ＣＣを追加したときに、ＣＩのコードポイントとＣＣとの対応関係が変化する。このため、上記のRRC connection reconfiguration procedureにかかる時間（つまり、基地局がRRC connection reconfiguration messageを送信してからRRC connection reconfiguration complete messageを受信するまでの間）では、基地局は、ＰＤＣＣＨを送信するＣＣ（上記例ではＣＣ２）以外のＣＣを割り当てることができない。つまり、送信すべきデータの量が増加するなどの理由でＣＣを追加したにもかかわらず、上記Reconfigurationが完了するまでの間、新規追加するＣＣ(上記例ではＣＣ２)のみならず、これまで使用していたＣＣ(ＣＣ３)にもデータを割り当てることができない。従って、データ送信の遅延を招くことになる。
【００１６】
一方で、ＣＩとＣＣとの対応付けを固定的にすると、上記したデータ送信の遅延という課題は生じない。例えば、ＣＣ１にはＣＩ＝１を、ＣＣ２にはＣＩ＝２を、ＣＣ３にはＣＩ＝３を、固定的に対応付けることにより、対応関係に変化が生じない。しかしながら、この場合には、端末へ設定したＣＣ数によらず、システムの総ＣＣ数に対応するコードポイント数(例えば、８ＣＣのシステムでは３ビット)を、ＣＣの通知に必要となる。このため、ＣＩＦのビット数の増大を招くことになる。例えば、１端末当たりに高々4つのＣＣ(２ビットで表現可能)を割り当てることができれば良い場合でも、常に３ビットでの通知が必要となる。言い換えれば、この場合には、システムがサポート可能なＣＣ数が、ＣＩＦのビット数によって限定されてしまう。
【００１７】
本発明の目的は、Carrier aggregationの通信時に使用されるＣＣが追加される場合に、使用ＣＣに関する通知に必要なビット数の増加を抑えると共に、データ送信に関する遅延を防止することができる端末装置、通信方法及び集積回路を提供することである。
【課題を解決するための手段】
【００１８】
本発明の一態様の端末装置は、基地局装置から追加又は削除された単位キャリアを示す設定情報を受信し、前記設定情報は新たに追加される単位キャリアの単位キャリア識別情報に割り当てられたＣＩＦ値と前記追加される単位キャリアの識別情報とを含むものであり、前記基地局装置において、１以上の単位キャリアに対して新たな単位キャリアの追加が行われる場合に、前記１以上の単位キャリアの各単位キャリアのラベルとして用いられるＣＩＦ値と単位キャリア識別情報との対応関係を維持したまま、前記新たに追加される単位キャリアの識別情報に対して、未設定のＣＩＦ値が割り当てられる、受信部と、前記設定情報に基づいて、既に保持している前記ＣＩＦ値と前記単位キャリア識別情報との対応関係を修正する設定部と、を具備する。
【００１９】
本発明の一態様の通信方法は、基地局装置から追加又は削除された単位キャリアを示す設定情報を受信し、前記設定情報は新たに追加される単位キャリアの単位キャリア識別情報に割り当てられたＣＩＦ値と前記追加される単位キャリアの識別情報とを含み、前記基地局装置において、１以上の単位キャリアに対して新たな単位キャリアの追加が行われる場合に、前記１以上の単位キャリアの各単位キャリアのラベルとして用いられるＣＩＦ値と単位キャリア識別情報との対応関係を維持したまま、前記新たに追加される単位キャリアの識別情報に対して、未設定のＣＩＦ値が割り当てられ、前記設定情報に基づいて、既に保持している前記ＣＩＦ値と前記単位キャリア識別情報との対応関係を修正する。
【発明の効果】
【００２０】
本発明によれば、Carrier aggregationの通信時に使用されるＣＣが追加される場合に、使用ＣＣに関する通知に必要なビット数の増加を抑えると共に、データ送信に関する遅延を防止することができる。
【図面の簡単な説明】
【００２１】
【図１】従来のラベリング方法の説明に供する図
【図２】本発明の実施の形態１に係る基地局の構成を示すブロック図
【図３】本発明の実施の形態１に係る端末の構成を示すブロック図
【図４】基地局及び端末の動作説明に供する図
【図５】基地局及び端末の動作説明に供する図
【図６】本発明の実施の形態２に係る基地局及び端末の動作説明に供する図
【図７】通知フォーマットの説明に供する図
【図８】変形例１の説明に供する図
【図９】本発明の実施の形態３に係るＣＩＦテーブルフォーマットの説明に供する図
【図１０】本発明の実施の形態３に係るＣＩＦテーブルフォーマットの説明に供する図
【発明を実施するための形態】
【００２２】
以下、本発明の実施の形態について図面を参照して詳細に説明する。なお、実施の形態において、同一の構成要素には同一の符号を付し、その説明は重複するので省略する。
【００２３】
［実施の形態１］
［基地局の構成］
図２は、本発明の実施の形態１に係る基地局１００の構成を示すブロック図である。図２において、基地局１００は、設定部１０１と、メモリ１０２と、制御部１０３と、ＰＤＣＣＨ生成部１０４と、符号化部１０５，１０６，１０７と、変調部１０８，１０９，１１０と、割当部１１１と、ＰＣＦＩＣＨ生成部１１２と、多重部１１３と、ＩＦＦＴ（Inverse Fast Fourier Transform）部１１４と、ＣＰ（Cyclic Prefix）付加部１１５と、送信ＲＦ部１１６と、受信ＲＦ部１１７と、ＣＰ除去部１１８と、ＦＦＴ（Fast Fourier Transform）部１１９と、抽出部１２０と、ＩＤＦＴ（Inverse Discrete Fourier transform）部１２１と、データ受信部１２２とを有する。
【００２４】
設定部１０１は、端末毎に上り回線および下り回線にそれぞれ使用する１つまたは複数のＣＣを設定（configure）、つまり、UE CC setを設定する。このUE CC setは、例えば、各端末の所要伝送レート、送信バッファ内の送信すべきデータ量、許容遅延量、QoS（Quality of Service）などに従って、設定される。また、設定部１０１は、一度設定したUE CC setの変更も行う。
【００２５】
設定部１０１は、UE CC setの初期設定時及びUE CC setの変更の都度、メモリ１０２に記憶されているＣＩＦテーブル（つまり、ラベリングルール）を修正（更新）する。このメモリ１０２に記憶されているＣＩＦテーブルでは、UE CC setを構成するＣＣ群のそれぞれが、ＣＩＦのコードポイントと対応付けられている。
【００２６】
具体的には、設定部１０１は、UE CC setに新たにＣＣを追加する場合には、現在設定されているUE CC setを構成するＣＣ群を維持したまま、新たなＣＣを追加する。また、設定部１０１は、ＣＩＦテーブルの修正に関しても、現在設定されているUE CC setを構成するＣＣ群とＣＩＦコードポイントとの関係は維持したまま、追加されたＣＣに対して、現在使われていないＣＩＦコードポイントを割り当てる。さらに、設定部１０１は、追加されたＣＣで送信されるデータに関するリソース割当情報を含むＰＤＣＣＨ信号を送信するＣＣの番号（以下では、この番号は、単に「ＰＤＣＣＨ  ＣＣ番号」と呼ばれることがある）も割り当てる。また、設定部１０１は、UE CC setを構成する一部のＣＣを削除する場合にも、削除されないＣＣとＣＩＦコードポイントとの対応関係は維持したまま、その一部のＣＣのみを削除する。このＣＩＦテーブル及びＣＩＦテーブルの修正処理の詳細については、後に詳しく説明する。
【００２７】
また、設定部１０１は、UE CC setに変更がある場合には、次の情報を、符号化部１０６を経由する処理系統を介して後述する端末２００へ通知する。すなわち、ＣＣを追加する場合には、設定部１０１は、追加されるＣＣの番号、ＰＤＣＣＨ  ＣＣ番号、及び、追加されるＣＣに割り当てられたＣＩＦコードポイントが、端末２００へ通知される。一方、ＣＣを削除する場合には、設定部１０１は、削除されるＣＣの番号が、端末２００へ通知される。これらの設定は、比較的長いスパンで用いられる。つまり、設定変更はサブフレーム単位では行われない。
【００２８】
また、設定部１０１は、UE CC setの初期設定時及びUE CC setの変更の都度、UE CC setを構成するＣＣの番号及びＰＤＣＣＨ  ＣＣ番号を、制御部１０３及びＰＤＣＣＨ生成部１０４に出力する。なお、以下では、設定部１０１から出力される情報を総称して、「設定情報」と呼ぶことがある。
【００２９】
制御部１０３は、リソース割当情報（つまり、上りリソース割当情報及び下りリソース割当情報）を生成する。上りリソース割当情報は、割当対象端末２００の上り回線データを割り当てる上りリソース（例えば、ＰＵＳＣＨ）を示す。一方、下りリソース割当情報は、割当対象端末２００宛ての下り回線データを割り当てる下りリソース（例えば、ＰＤＳＣＨ）を示す。ここで、リソース割当情報には、リソースブロック（ＲＢ：Resource Block）の割当情報、データのＭＣＳ情報、データが新規データであるか再送データであるかを示す情報（ＮＤＩ：New Data Indicator）またはＲＶ（Redundancy version）情報等のＨＡＲＱ再送に関する情報、及びそのリソース割り当ての対象とするＣＣの情報（ＣＩ：Carrier Indicator）及び割当対象のＣＣのＣＦＩ情報も含まれる。
【００３０】
そして、制御部１０３は、リソース割当情報をＰＤＣＣＨ生成部１０４および多重部１１３に出力する。
【００３１】
ここで、制御部１０３は、設定部１０１から受け取る設定情報に基づいて、割当対象端末２００に対するリソース割当情報を、その端末２００に設定した下り単位キャリアに配置されたＰＤＣＣＨに割り当てる。この割当処理は、サブフレーム単位で行われる。具体的には、制御部１０３は、割当対象端末２００に対するリソース割当情報を、その端末２００に設定されたＰＤＣＣＨ  ＣＣ番号の示す下り単位キャリアに配置されたＰＤＣＣＨに割り当てる。また、制御部１０３は、設定部１０１によって更新されているＣＩＦテーブルに従って、リソース割当対象である各ＣＣに対してＣＩＦコードポイントを割り当てる。なお、ＰＤＣＣＨは、１つまたは複数のＣＣＥで構成される。また、基地局１００が使用するＣＣＥ数は、割当対象端末２００の伝搬路品質（ＣＱＩ：Channel Quality Indicator）および制御情報サイズに基づいて設定される。これにより、端末２００は、必要十分な誤り率で制御情報を受信できる。
【００３２】
また、制御部１０３は、ＰＤＣＣＨの送信に使用されるＯＦＤＭシンボル数を、下り単位キャリア毎に決定する。この決定は、ＰＤＣＣＨに使用されるＣＣＥ数に基づいて行われる。制御部１０３は、決定したＯＦＤＭシンボル数を示すＣＦＩ情報を生成する。そして、制御部１０３は、下り単位キャリア毎のＣＦＩ情報を、ＰＣＦＩＣＨ生成部１１２および多重部１１３に出力する。
【００３３】
ＰＤＣＣＨ生成部１０４は、設定部１０１から受け取る設定情報（特に、ＰＤＣＣＨ  ＣＣ番号）の示す下り単位キャリアで送信するＰＤＣＣＨ信号を、生成する。このＰＤＣＣＨ信号には、制御部１０３から出力された、上りリソース割当情報および下りリソース割当情報が含まれる。また、ＰＤＣＣＨ生成部１０４は、ＰＤＣＣＨ信号にＣＲＣビットを付加し、さらにＣＲＣビットを端末ＩＤでマスキング（または、スクランブリング）する。そして、ＰＤＣＣＨ生成部１０４は、マスキング後のＰＤＣＣＨ信号を、符号化部１０５に出力する。
【００３４】
以上で説明した処理は、処理対象端末２００毎に行われる。
【００３５】
符号化部１０５は、ＰＤＣＣＨ生成部１０４から入力される各単位キャリアのＰＤＣＣＨ信号に対してチャネル符号化を行い、符号化後のＰＤＣＣＨ信号を変調部１０８に出力する。
【００３６】
変調部１０８は、符号化部１０５から入力されるＰＤＣＣＨ信号を変調して、変調後のＰＤＣＣＨ信号を割当部１１１に出力する。
【００３７】
割当部１１１は、変調部１０８から入力される各端末のＰＤＣＣＨ信号を、各下り単位キャリアにおける端末毎のサーチスペース内のＣＣＥにそれぞれ割り当てる。そして、割当部１１１は、ＣＣＥに割り当てたＰＤＣＣＨ信号を多重部１１３に出力する。
【００３８】
ＰＣＦＩＣＨ生成部１１２は、制御部１０３から入力される下り単位キャリア毎のＣＦＩ情報に基づいて、下り単位キャリア毎に送信されるＰＣＦＩＣＨ信号を生成する。そして、ＰＣＦＩＣＨ生成部１１２は、生成したＰＣＦＩＣＨ信号を多重部１１３に出力する。
【００３９】
符号化部１０６は、設定部１０１から入力される設定情報を符号化して、符号化後の設定情報を変調部１０９に出力する。
【００４０】
変調部１０９は、符号化後の設定情報を変調して、変調後の設定情報を多重部１１３に出力する。
【００４１】
符号化部１０７は、入力される送信データ（下り回線データ）をチャネル符号化して、チャネル符号化後の送信データ信号を変調部１１０に出力する。
【００４２】
変調部１１０は、チャネル符号化後の送信データ信号を変調して、変調後の送信データ信号を多重部１１３に出力する。
【００４３】
多重部１１３は、割当部１１１から入力されるＰＤＣＣＨ信号、ＰＣＦＩＣＨ生成部１１２から入力されるＰＣＦＩＣＨ信号、変調部１０９から入力される設定情報および変調部１１０から入力されるデータ信号（つまり、ＰＤＳＣＨ信号）を多重する。ここで、多重部１１３は、制御部１０３から入力される各下り単位キャリアのＣＦＩ情報に基づいて、ＰＤＣＣＨを配置するＯＦＤＭシンボル数を下り単位キャリア毎に決定する。また、多重部１１３は、制御部１０３から入力される下りリソース割当情報に基づいて、ＰＤＣＣＨ信号およびデータ信号（ＰＤＳＣＨ信号）を各下り単位キャリアにマッピングする。なお、多重部１１３は、設定情報をＰＤＳＣＨにマッピングしてもよい。そして、多重部１１３は、多重信号をＩＦＦＴ部１１４に出力する。
【００４４】
ＩＦＦＴ部１１４は、多重部１１３から入力される多重信号を時間波形に変換し、ＣＰ付加部１１５は、この時間波形にＣＰを付加することによりＯＦＤＭ信号を得る。
【００４５】
送信ＲＦ部１１６は、ＣＰ付加部１１５から入力されるＯＦＤＭ信号に対して無線送信処理（アップコンバート、Ｄ／Ａ変換等）を施し、アンテナを介して送信する。
【００４６】
一方、受信ＲＦ部１１７は、アンテナを介して受信帯域で受信した受信無線信号に対して無線受信処理（ダウンコンバート、Ａ／Ｄ変換等）を施し、得られた受信信号をＣＰ除去部１１８に出力する。
【００４７】
ＣＰ除去部１１８は、受信信号からＣＰを除去し、ＦＦＴ部１１９は、ＣＰ除去後の受信信号を周波数領域信号に変換する。
【００４８】
抽出部１２０は、制御部１０３から入力される上りリソース割当情報（例えば、４サブフレーム前の上りリソース割当情報）に基づいて、ＦＦＴ部１１９から入力される周波数領域信号から、各端末の上り回線データおよびＰＵＣＣＨ信号（例えば、ＡＣＫ／ＮＡＣＫ信号）を抽出する。ＩＤＦＴ部１２１は抽出部１２０で抽出された信号を時間領域信号に変換し、その時間領域信号をデータ受信部１２２に出力する。
【００４９】
データ受信部１２２は、ＩＤＦＴ部１２１から入力される時間領域信号のうち、上り回線データを復号する。そして、データ受信部１２２は、復号後の上り回線データを受信データとして出力する。
【００５０】
［端末の構成］
図３は、本発明の実施の形態１に係る端末２００の構成を示すブロック図である。端末２００は、複数の下り単位キャリアを使用して基地局１００と通信する。また、端末２００は、受信データに誤りがある場合には、ＨＡＲＱバッファに受信データを格納し、再送時に再送データと、ＨＡＲＱバッファに格納している受信済データとを合成して、得られる合成信号を復号する。
【００５１】
図３において、端末２００は、受信ＲＦ部２０１と、ＣＰ除去部２０２と、ＦＦＴ部２０３と、分離部２０４と、設定情報受信部２０５と、ＰＣＦＩＣＨ受信部２０６と、ＣＩＦテーブル設定部２０７と、ＰＤＣＣＨ受信部２０８と、ＰＤＳＣＨ受信部２０９と、変調部２１０，２１１と、ＤＦＴ（Discrete Fourier transform）部２１２と、マッピング部２１３と、ＩＦＦＴ部２１４と、ＣＰ付加部２１５と、送信ＲＦ部２１６とを有する。
【００５２】
受信ＲＦ部２０１は、受信帯域を変更可能に構成されており、設定情報受信部２０５から入力される帯域情報に基づいて、受信帯域を変更する。そして、受信ＲＦ部２０１は、アンテナを介して受信帯域で受信した受信無線信号（ここでは、ＯＦＤＭ信号）に対して無線受信処理（ダウンコンバート、Ａ／Ｄ変換等）を施し、得られた受信信号をＣＰ除去部２０２に出力する。
【００５３】
ＣＰ除去部２０２は、受信信号からＣＰを除去し、ＦＦＴ部２０３は、ＣＰ除去後の受信信号を周波数領域信号に変換する。この周波数領域信号は、分離部２０４に出力される。
【００５４】
分離部２０４は、ＦＦＴ部２０３から受け取る信号を、設定情報を含む上位レイヤの制御信号（例えば、ＲＲＣシグナリング等）と、ＰＣＦＩＣＨ信号と、ＰＤＣＣＨ信号と、データ信号（つまり、ＰＤＳＣＨ信号）とに分離する。そして、分離部２０４は、制御信号を設定情報受信部２０５に出力し、ＰＣＦＩＣＨ信号をＰＣＦＩＣＨ受信部２０６に出力し、ＰＤＣＣＨ信号をＰＤＣＣＨ受信部２０８に出力し、ＰＤＳＣＨ信号をＰＤＳＣＨ受信部２０９に出力する。
【００５５】
設定情報受信部２０５は、分離部２０４から受け取る制御信号から、次の情報を読み取る。すなわち、この読み取られる情報は、自端末に設定された、データ送信に用いる上り単位キャリアおよび下り単位キャリア、各単位キャリアのリソース割当情報が割り当てられたＰＤＣＣＨ信号の送信に使用される下り単位キャリアを示す情報、並びに、追加又は削除されたＣＣに対応するＣＩＦコードポイントを読み取る。
【００５６】
そして、設定情報受信部２０５は、読み取った情報を、ＣＩＦテーブル設定部２０７、ＰＤＣＣＨ受信部２０８、受信ＲＦ部２０１、および送信ＲＦ部２１６に出力する。また、設定情報受信部２０５は、分離部２０４から受け取る制御信号から、自端末に設定された端末ＩＤを読み取り、読み取った端末ＩＤ情報をＰＤＣＣＨ受信部２０８に出力する。
【００５７】
ＰＣＦＩＣＨ受信部２０６は、分離部２０４から受け取るＰＣＦＩＣＨ信号からＣＦＩ情報を抽出する。すなわち、ＰＣＦＩＣＨ受信部２０６は、リソース割当情報が割り当てられたＰＤＣＣＨに使用されるＯＦＤＭシンボル数を示すＣＦＩ情報を、自端末に設定された複数の下り単位キャリア毎に得る。そして、ＰＣＦＩＣＨ受信部２０６は、抽出したＣＦＩ情報をＰＤＣＣＨ受信部２０８およびＰＤＳＣＨ受信部２０９に出力する。
【００５８】
ＣＩＦテーブル設定部２０７は、設定情報受信部２０５から受け取る追加又は削除されたＣＣの番号、及び、当該ＣＣに割り当てられたＣＩＦコードポイントに基づいて、ＰＤＣＣＨ受信部２０８が保持しているＣＩＦテーブルを修正（更新）する。この修正処理は、基地局１００における修正処理と一致する。
【００５９】
ＰＤＣＣＨ受信部２０８は、分離部２０４から受け取るＰＤＣＣＨ信号をブラインド復号して、自端末宛てのＰＤＣＣＨ信号（リソース割当情報）を得る。ここで、ＰＤＣＣＨ信号は、設定情報受信部２０５から受け取る情報に示される、自端末に設定された下り単位キャリアに配置されたＣＣＥ（すなわち、ＰＤＣＣＨ）にそれぞれ割り当てられている。
【００６０】
具体的には、ＰＤＣＣＨ受信部２０８は、ＰＣＦＩＣＨ受信部２０６から受け取るＣＦＩ情報に基づいて、ＰＤＣＣＨが配置されたＯＦＤＭシンボル数を下り単位キャリア毎に特定する。また、ＰＤＣＣＨ受信部２０８は、設定情報受信部２０５から受け取る端末ＩＤを用いて自端末のサーチスペースを算出する。
【００６１】
そして、ＰＤＣＣＨ受信部２０８は、算出したサーチスペース内の各ＣＣＥに割り当てられたＰＤＣＣＨ信号を復調および復号する。
【００６２】
ここで、ＰＤＣＣＨ受信部２０８は、各単位キャリアのデータのリソース割当を行うＰＤＣＣＨそれぞれに対してブラインド復号する。例えば、２つの単位キャリア（下り単位キャリア１および下り単位キャリア２）が存在し、両ＣＣについてＰＤＣＣＨ信号がＣＣ１から送信される場合、ＰＤＣＣＨ受信部２０８は、下り単位キャリア１のデータ割当を行うＰＤＣＣＨに対するブラインド復号、および、下り単位キャリア２のデータ割当を行うＰＤＣＣＨに対するブラインド復号を、ＣＣ１上でそれぞれ行う。
【００６３】
そして、ＰＤＣＣＨ受信部２０８は、復号後のＰＤＣＣＨ信号に対して、端末ＩＤ情報に示される自端末の端末ＩＤでＣＲＣビットをデマスキングすることによりＣＲＣ＝ＯＫ（誤り無し）となったＰＤＣＣＨ信号を自端末宛てのＰＤＣＣＨ信号であると判定する。
【００６４】
そして、ＰＤＣＣＨ受信部２０８は、自端末宛てのＰＤＣＣＨ信号に含まれる下りリソース割当情報をＰＤＳＣＨ受信部２０９に出力し、上りリソース割当情報をマッピング部２１３に出力する。一方、ＣＲＣ＝ＯＫとなるＰＤＣＣＨ信号が検出されなかった場合には、ＰＤＣＣＨ受信部２０８は、現在のサブフレームでは自端末宛のデータ割当が無かったものと判断し、次のサブフレームまで待機する。
【００６５】
ここで、ＰＤＣＣＨ信号に含まれる下りリソース割当情報では、下りデータの送信に用いられるＣＣがＣＩＦコードポイントによって示されている。従って、ＰＤＣＣＨ受信部２０８は、ＣＩＦテーブル設定部２０７によって更新されたＣＩＦテーブルを参照して、下りリソース割当情報に含まれるＣＩＦコードポイントをＣＣ番号に変換した後に、下りリソース割当情報をＰＤＳＣＨ受信部２０９に出力する。なお、ＣＩＦテーブルは、ＰＤＣＣＨ受信部２０８が有するメモリ（図示せず）に記憶されている。
【００６６】
ＰＤＳＣＨ受信部２０９は、ＰＤＣＣＨ受信部２０８から受け取る、複数の下り単位キャリアの下りリソース割当情報及びＣＦＩ情報、並びに、ＰＣＦＩＣＨ受信部２０６から受け取る、ＰＤＣＣＨが送信されたＣＣのＣＦＩ情報に基づいて、分離部２０４から受け取るＰＤＳＣＨ信号から受信データ（下り回線データ）を抽出する。また、ＰＤＣＣＨ送信されるＣＣとＰＤＳＣＨ送信されるＣＣとが異なる場合には、ＣＦＩ情報は、復号後のＰＤＣＣＨ信号から得られる。
【００６７】
また、ＰＤＳＣＨ受信部２０９は、抽出した受信データ（下り回線データ）に対して誤り検出を行う。そして、ＰＤＳＣＨ受信部２０９は、誤り検出の結果、受信データに誤りがある場合にはＡＣＫ／ＮＡＣＫ信号としてＮＡＣＫ信号を生成し、受信データに誤りが無い場合にはＡＣＫ／ＮＡＣＫ信号としてＡＣＫ信号を生成し、ＡＣＫ／ＮＡＣＫ信号を変調部２１０に出力する。また、ＰＤＳＣＨ受信部２０９は、受信データに誤りがある場合には、抽出した受信データをＨＡＱＲバッファ（図示せず）に格納する。そして、ＰＤＳＣＨ受信部２０９は、再送データを受信した場合には、ＨＡＲＱバッファに格納している受信済データと、再送データとを合成し、得られる合成信号に対して誤り検出を行う。なお、基地局１００がＰＤＳＣＨ送信をＭＩＭＯ（Multiple-Input Multiple Output）等により空間多重して、２つのデータブロック（Transport Block）を送信している場合には、ＰＤＳＣＨ受信部２０９は、それぞれのデータブロックに対してＡＣＫ／ＮＡＣＫ信号を生成する。
【００６８】
変調部２１０は、ＰＤＳＣＨ受信部２０９から受け取るＡＣＫ／ＮＡＣＫ信号を変調する。なお、基地局１００が各下り単位キャリアでＰＤＳＣＨ信号を空間多重して、２つのデータブロックを送信している場合には、変調部２１０は、ＡＣＫ／ＮＡＣＫ信号に対してＱＰＳＫ変調を施す。一方、基地局１００が１つのデータブロックを送信している場合には、変調部２１０は、ＡＣＫ／ＮＡＣＫ信号に対してＢＰＳＫ変調を施す。つまり、変調部２１０は、各下り単位キャリアのＡＣＫ／ＮＡＣＫ信号として、１つのＱＰＳＫ信号またはＢＰＳＫ信号を生成する。そして、変調部２１０は、変調後のＡＣＫ／ＮＡＣＫ信号をマッピング部２１３に出力する。
【００６９】
変調部２１１は、送信データ（上り回線データ）を変調し、変調後のデータ信号をＤＦＴ部２１２に出力する。
【００７０】
ＤＦＴ部２１２は、変調部２１１から入力されるデータ信号を周波数領域に変換し、得られる複数の周波数成分をマッピング部２１３に出力する。
【００７１】
マッピング部２１３は、ＰＤＣＣＨ受信部２０８から入力される上りリソース割当情報に従って、ＤＦＴ部２１２から入力されるデータ信号を、上り単位キャリアに配置されたＰＵＳＣＨにマッピングする。また、マッピング部２１３は、変調部２１０から入力されるＡＣＫ／ＮＡＣＫ信号を、上り単位キャリアに配置されたＰＵＣＣＨにマッピングする。
【００７２】
なお、変調部２１０、変調部２１１、ＤＦＴ部２１２およびマッピング部２１３は上り単位キャリア毎に設けられてもよい。
【００７３】
ＩＦＦＴ部２１４は、ＰＵＳＣＨにマッピングされた複数の周波数成分を時間領域波形に変換し、ＣＰ付加部２１５は、その時間領域波形にＣＰを付加する。
【００７４】
送信ＲＦ部２１６は、送信帯域を変更可能に構成されており、設定情報受信部２０５から受け取る情報に基づいて、送信帯域を設定する。そして、送信ＲＦ部２１６は、ＣＰが付加された信号に送信無線処理（アップコンバート、Ｄ／Ａ変換等）を施してアンテナを介して送信する。
【００７５】
［基地局１００及び端末２００の動作］
以上の構成を有する基地局１００及び端末２００の動作について説明する。ここでは、特に、UE CC setの変更に伴う、ＣＩＦテーブルの修正処理について説明する。
【００７６】
図４には、UE CC setを構成するＣＣが時間と共に変化する様子が示されている。図５には、図４に示される各時間区間における、ＣＩＦテーブルの状況が示されている。ここで、ＣＩＦは２ビットの場合、４個のコードポイントが存在し、ビット列００、０１、１０、１１で表現される。ここでは、ＣＩ＝１、２、３、４がそれぞれビット列００、０１、１０、１１に対応するものとして説明する。
【００７７】
図４に示すように、端末２００の電源導入時には、ＬＴＥと同様のセルサーチ、ランダムアクセスなどの動作によって、基地局１００との間の通信は、１つのＣＣ（図４では、ＣＣ２）で開始される。
【００７８】
そして、基地局１００は、例えばデータ量の増加を要因として、端末２００に対してＣＣの追加を行う。このとき、基地局１００において、設定部１０１は、メモリ１０２に記憶されているＣＩＦテーブルを修正（更新）する。具体的には、UE CC setに新たにＣＣを追加する場合には、現在設定されているUE CC setを構成するＣＣ群を維持したまま、新たなＣＣを追加する。また、設定部１０１は、ＣＩＦテーブルの修正に関しても、現在設定されているUE CC setを構成するＣＣ群とＣＩＦコードポイントとの関係は維持したまま、追加されたＣＣに対して、現在使われていないＣＩＦコードポイントを割り当てる。さらに、設定部１０１は、「ＰＤＣＣＨ  ＣＣ番号」も割り当てる。
【００７９】
例えば、図４では、区間Ｂの先頭タイミング、区間Ｃの先頭タイミング、及び区間Ｅの先頭タイミングで、ＣＣの追加が行われている。区間Ｂ、Ｃ、ＥにおけるＣＩＦテーブルの状況は、図５Ｂ、Ｃ、Ｅにそれぞれ示されている。例えば、図５Ｂと図５Ｃとの間でＣＣ１が追加されている。図５Ｃでは、図５ＢにおけるUE CC setを構成するＣＣ群とＣＩＦコードポイントとの関係が維持されたまま、図５Ｂでは使用されていないＣＩＦコードポイント３に対してＣＣ１が対応付けられている。
【００８０】
また、図４に示すように、区間Ｃでは、ＣＣ２のＰＤＣＣＨによって、ＣＣ１，２，３におけるデータ(PDSCH)割り当てに関する情報が、端末２００に通知されている。すなわち、このときの「ＰＤＣＣＨ  ＣＣ番号」は、２となる。
【００８１】
また、設定部１０１は、UE CC setを構成する一部のＣＣを削除する場合にも、削除されないＣＣとＣＩＦコードポイントとの対応関係は維持したまま、その一部のＣＣのみを削除する。
【００８２】
例えば、図５Ｃと図５Ｄとの間ではＣＣ１の削除が行われている。図５Ｄでは、図５Ｃにおける、ＣＣ１以外のＣＣ２，３とＣＩＦコードポイントとの対応関係は維持されている。
【００８３】
なお、端末２００のＣＩＦテーブル設定部２０７による修正処理は、基地局１００における修正処理と一致する。
【００８４】
以上のように、UE CC setの変更（つまり、ＣＣの追加又は削除）に伴い、ＣＩＦテーブルが変更される場合でも、変更に関係ないＣＣとＣＩＦコードポイントとの対応関係が維持される。すなわち、UE CC setの変更時に必要となるRRC connection reconfiguration procedureが実行されている最中にも、変更に関係ないＣＣに対しては、既に割り当てられているコードポイントをそのまま用いて、データを割り当てることができる。これにより、データ送信に関する遅延を防止することができる。また、より多くのＣＣを使うことができるため、データスループットを向上することができる。
【００８５】
また、実際に端末２００に設定されているＣＣに対してのみ、ＣＩＦコードポイントが割り当てられるので、基地局１００から端末２００に対するＣＣの通知に必要なビット数は、端末２００がサポートするＣＣ数分だけで良い。例えば、システムのサポートするＣＣ数が８個の場合でも、端末２００のサポートするＣＣ数が４の場合には、基地局１００から端末２００に対するＣＣの通知に必要なビット数は、２ビットだけで良い。つまり、システム全体のＣＣ数を増やした場合でも、ＣＩＦビット数を増やす必要はなく、制御情報量の低減が可能である。
【００８６】
以上のように本実施の形態によれば、基地局１００において、設定部１０１が、単位キャリアセット（UE CC set）に対して単位キャリアの追加が行われる場合に、単位キャリアセットに含まれる単位キャリアのラベルとして用いられるコードポイントと単位キャリアの識別情報とが対応付けられたＣＩＦテーブルを修正し、修正前のＣＩＦテーブルにおけるコードポイントと単位キャリア識別情報との対応関係を維持したまま、追加される単位キャリアに対して、空いているコードポイントを割り当てる。そして、制御部１０３が、複数の単位キャリアのそれぞれでのデータ送信に関する制御信号（ＰＤＣＣＨ）を形成し、各単位キャリアの制御信号が、設定部１０１によって修正されたＣＩＦテーブルに従ったコードポイントによってラベリングされている。また、設定部１０１、符号化部１０６、変調部１０９を含む送信手段が、ＣＩＦテーブルの修正に関する情報を含む通知信号を端末２００へ送信する。
【００８７】
こうすることで、使用ＣＣに関する通知に必要なビット数の増加を抑えると共に、データ送信に関する遅延を防止することができる。
【００８８】
なお、メモリ１０２におけるＣＩＦテーブルは、ＰＤＣＣＨを送信するＣＣ毎に保持するようにしても良い。つまり、ＣＣ追加時には、割り当てたＰＤＣＣＨ  ＣＣのＣＩＦテーブルが修正される。例えば、上記の例の場合には、ＰＤＣＣＨ  ＣＣとしてＣＣ２を割り当てているため、ＣＣ２のＣＩＦテーブルが修正される。他の例として、UE CC setのＣＣ２，ＣＣ３でどちらのＣＣに対してもＣＣ２がＰＤＣＣＨ  ＣＣとして設定されている場合（つまり、図４のＢの状態）に、ＣＣ１とＣＣ４とを追加する際に、ＣＣ１をＰＤＣＣＨ  ＣＣとして設定し、ＣＣ１及びＣＣ４に対してＣＩＦコードポイント１、２を割り当てるようにしても良い。この場合、ＣＣ１のＣＩＦテーブルが修正される。このようにＣＩＦテーブルをＣＣごとに保持することにより、ＰＤＣＣＨ  ＣＣが異なれば同じＣＩＦコードポイントを割り当てることができるため、ＣＣ通知に必要なＣＩＦビット数の低減が可能である。
【００８９】
［実施の形態２］
実施の形態２では、ＣＩＦコードポイントによって、データ割当対象のＣＣ番号に加えて、ＣＦＩ値も通知する。すなわち、ＣＩＦテーブルでは、ＣＩＦコードポイントに対して、ＣＣ番号とＣＦＩ値との組が対応付けられる。ここで、ＣＦＩ値は、サブフレームの先頭で、ＰＣＦＩＣＨ(Physical Control Format Indicator Channel)によって、全端末向けに各ＣＣから送信されている。マクロセルとフェムトセルとが存在するようなヘテロジニアスネットワーク環境においては、十分高い信頼度でＰＣＦＩＣＨを受信することができない場合がある。このため、或るＣＣに関するＣＦＩ値を、他のＣＣから送信されるＰＤＣＣＨ信号に含めて通知することにより、ＣＦＩ通知の信頼度を向上できる。
【００９０】
実施の形態２に係る基地局及び端末の基本構成は、実施の形態１と共通するので、図２、３を援用して説明する。
【００９１】
実施の形態２に係る基地局１００の設定部１０１は、ＣＣを追加する場合には、基本的には、追加されるＣＣと全てのＣＩＦ値のそれぞれとのペア群を、それぞれ異なるＣＩＦコードポイントに割り当てる。実施の形態２においても、設定部１０１は、基本的には、現在設定されているUE CC setを構成するＣＣ群とＣＩＦコードポイントとの関係は維持したまま、追加されたＣＣに対して、現在使われていないＣＩＦコードポイントを割り当てる。また、設定部１０１は、UE CC setを構成する一部のＣＣを削除する場合にも、削除されないＣＣとＣＩＦコードポイントとの対応関係は維持したまま、その一部のＣＣのみを削除する。このとき、その一部のＣＣに関する対応付けは、すべて削除される。
【００９２】
また、端末２００のＣＩＦテーブル設定部２０７は、設定情報受信部２０５から受け取る追加又は削除されたＣＣの番号、当該ＣＣに割り当てられたＣＩＦコードポイント、及びＣＦＩ値に基づいて、ＰＤＣＣＨ受信部２０８が保持しているＣＩＦテーブルを修正（更新）する。
【００９３】
以上の構成を有する基地局１００及び端末２００の動作について説明する。
【００９４】
本実施の形態では、CIFコードポイントとＣＣ番号とＣＦＩ値との関係を示すテーブルが基地局１００と端末２００との間で共有される。ＣＣ追加時には、ＣＦＩ＝１,２,３に対応する最大３つのＣＩＦコードポイントが割り当てられ、割り当てられたＣＩＦコードポイントに関する情報が、基地局１００から端末２００へ通知される。また、設定されたＣＣ数が多い場合には、追加のＣＣに対して通知可能なＣＦＩ値は２つまたは１つとなることがある。従って、ＣＣ追加時にＣＣに関する情報を通知する際には、割り当てたコードポイントの数も、基地局１００から端末２００へ通知される。この通知フォーマットは、図７に示されている。
【００９５】
図６は、ＣＣを追加した場合のＣＩＦテーブルの変化の様子を示す図である。図６では、特に、ＣＣ２及びＣＣ３で通信中の端末２００に対して、ＣＣ１及びＣＣ４を順次追加した場合のＣＩＦテーブルの変化の様子が示されている。また、ここでは、ＰＤＣＣＨを送信するＣＣは、ＣＣ２であるとする。
【００９６】
図６に示すように、ＣＣ１追加時には、設定部１０１は、追加されるＣＣと全てのＣＩＦ値のそれぞれとのペア群を、それぞれ異なるＣＩＦコードポイントに割り当てる。すなわち、ここでは、ＣＦＩ＝１,２,３が用意されているので、ＣＣ１と、ＣＦＩ＝１,２,３のそれぞれとの３つのペアに対して、それぞれ異なるＣＩＦコードポイントが割り当てられる。また、図６Ａの状態では、ＣＩＦコードポイント５〜８が空いているので、この内の３つのＣＩＦコードポイントが、ＣＣ１とＣＦＩ＝１,２,３のそれぞれとの３つのペアに対して割り当てられている。ここでは、特に、小さい番号のＣＩＦコードポイントから優先的に割り当てられている。
【００９７】
また、図６に示すように、ＣＣ４追加時には、設定部１０１は、追加されるＣＣと一部のＣＩＦ値のそれぞれとのペア群を、それぞれ異なるＣＩＦコードポイントに割り当ている。ここでは、ＣＣ４とＣＦＩ＝２とのペアは、空いているＣＩＦコードポイント８に割り当てられている。一方、ＣＣとＣＦＩ＝１とのペアは、既にＣＣ３とＣＦＩ＝３とのペアに割り当てられていたＣＩＦコードポイント４に対して、ＣＣ３とＣＦＩ＝３とのペアの代わりに割り当てられる。つまり、ＣＣ３とＣＦＩ＝３とのペアは、ＣＣとＣＦＩ＝１とのペアによって上書きされる。
【００９８】
すなわち、設定部１０１は、状況によっては、追加されるＣＣと一部のＣＩＦ値のそれぞれとのペア群を、それぞれ異なるＣＩＦコードポイントに割り当てることもできる。
【００９９】
また、設定部１０１は、任意のＣＣに割り当てられている複数のＣＩＦコードポイントの内、どのＣＦＩ値に対応するＣＩＦコードポイントを上書きするかを選択することができる。すなわち、図６Ｃでは、ＣＣ３とＣＦＩ＝３とのペアが上書きされているが、この代わりに、ＣＣ３とＣＦＩ＝１とのペア、又は、ＣＣ３とＣＦＩ＝２とのペアが上書きされても良い。
【０１００】
また、設定部１０１は、追加されるＣＣと全てのＣＩＦ値のそれぞれとのペア群の内、どのペアをＣＩＦコードポイントに割り当てるかについても選択できる。すなわち、図６Ｃでは、ＣＣ１とＣＦＩ＝１,２,３のそれぞれとの３つのペアの内、ＣＣ１とＣＦＩ＝１,２のそれぞれとの２つのペアが選択されているが、この代わりに、ＣＣ１とＣＦＩ＝２，３のそれぞれとの２つのペアが選択されても良いし、ＣＣ１とＣＦＩ＝１,３のそれぞれとの２つのペアが選択されても良い。ＣＩＦコードポイントに実際に割り当てられるペアは、セル環境などに応じて選択される。例えば、セル半径の大きなセル(例えば，マクロセル)では収容する端末数が多いので、多くのＰＤＣＣＨリソースが必要となる場合が多い。このため、ＰＤＣＣＨリソース領域を表すＣＦＩ値として、大きな値(例えば、２，３)が好ましい。逆に、セル半径の小さなセル(例えば、ピコセル、フェムトセル)などでは収容する端末数が少ないので、ＰＤＣＣＨリソース領域を表すＣＦＩ値は小さくても良い。従って、この場合、ＣＦＩ値としては、例えば１，２が選択される。また、ホットスポットなど端末数の増減が激しいようなセルでは、ＣＦＩ値として１，３が選択されても良い。そして、選択されたペアに関する情報は、別途通知される。
【０１０１】
図７は、ＣＩＦコードポイントの通知用フォーマットを示す図である。図７における、上段には、３つのＣＩＦコードポイントを通知するためのフォーマットが示され、中段には、２つのＣＩＦコードポイントを通知するためのフォーマットが示され、下段には、１つのＣＩＦコードポイントを通知するためのフォーマットが示されている。
【０１０２】
図７に示すように、各フォーマットでは、通知する必要のあるＣＦＩ値の数と同じ数だけ、ＣＩＦコードポイントを格納する領域が設けられている。さらに、各格納領域は、それぞれ異なるＣＦＩ値と対応付けられている。この格納領域は、「通知フィールド」と呼ばれることもある。
【０１０３】
以上のように、UE CC setの変更（つまり、ＣＣの追加又は削除）に伴い、ＣＩＦテーブルが変更される場合でも、変更に関係ないＣＣとＣＩＦコードポイントとの対応関係が維持される。また、既に割り当てられているＣＣに関するペアが上書きされる場合でも、そのＣＣに関するペア群の内の一部のみが上書きされるので、上書きされないペアについては、ＣＩＦコードポイントがそのまま維持される。
【０１０４】
従って、UE CC setの変更時に必要となるRRC connection reconfiguration procedureが実行されている最中にも、変更に関係ないペアに対しては、既に割り当てられているコードポイントをそのまま用いて、データを割り当てることができる。これにより、データ送信に関する遅延を防止することができる。
【０１０５】
また、必要なＣＦＩ値に応じて上書きするコードポイントを選択することにより、セル環境などに応じて使われやすいＣＦＩ値を選択することができる。また、ＣＣ追加時に当該ＣＣと対応付けてＣＦＩ値を設定することにより、セル環境などに応じたＣＦＩ値の設定が可能となる。
【０１０６】
なお、図６Ｃの状態からＣＣ４を削除した場合には、別途ＣＩＦコードポイント４をＣＣ３とＣＦＩ＝３とのペアに割り当てても良い。又は、自動的にその前の状態である図６Ｂのテーブルに戻るようにしても良い。これにより、UE CC setに含まれるＣＣ数が少なくなった場合に、別途ＣＩＦコードポイントを通知することなく、３つのＣＦＩ値を通知可能な状態にすることができる。
【０１０７】
ここで、追加されるＣＣと一部のＣＩＦ値とのペア群のみをＣＩＦコードポイントに割り当てる場合に、端末２００に対してそのペア群を通知する方法には、いくつかの変形例がある。
【０１０８】
〈変形例１〉
変形例１では、ＣＩＦテーブルにおいて、ＣＩＦコードポイントとＣＦＩ値とを予め１対１に対応づけておく。すなわち、図８の例では、ＣＩＦコードポイント２〜８のそれぞれに対して、ＣＦＩ値が固定的に割り振られている。
【０１０９】
従って、使用したいＣＦＩ値が決まれば、使用可能なＣＩＦコードポイントの候補が絞られるので、設定部１０１の選択処理を簡略化することができる。また、ＣＩＦコードポイントが基地局１００から端末２００へ通知されれば、ＣＦＩ値が自ずと特定される。このため、基地局１００は、ＣＦＩ値を端末２００へ別途通知する必要がない。
【０１１０】
〈変形例２〉
変形例２では、実際に必要なＣＦＩ値の個数よりも多い数のＣＩＦコードポイントを格納可能な通知フォーマットが用いられる。ここでは、説明を簡単にするために、図７の上段の通知フォーマットが用いられる場合について説明する。
【０１１１】
ここで、３個のＣＦＩ値の内、２つのＣＦＩ値のみを、追加のＣＣに割り当てる場合には、次のような方法で通知がなされる。
【０１１２】
すなわち、通知フォーマットに含まれる３つの通知フィールドでＣＩＦコードポイント＝２，２，３がそれぞれ通知された場合には、ＣＩＦコードポイント＝２，３に対応するＣＦＩ値が、それぞれ１，３であることを意味する。また、３つの通知フィールドでＣＩＦコードポイント＝２，３，３がそれぞれ通知された場合には、ＣＩＦコードポイント＝２，３に対応するＣＦＩ値が、それぞれ１，２であることを意味する。また、３つの通知フィールドでＣＩＦコードポイント＝２，３，２がそれぞれ通知された場合には、ＣＩＦコードポイント＝２，３に対応するＣＦＩ値が、それぞれ２，３であることを意味する。つまり、ＣＩＦコードポイントの複数の通知フィールドに対するマッピングパタンと、複数のＣＦＩ値の組み合わせとを対応付けている。
【０１１３】
これにより、どのＣＦＩ値を使用するかについての、追加のシグナリングなしで、実際に使用されるＣＦＩ値を通知することができる。
【０１１４】
〈変形例３〉
変形例３では、ＣＦＩ値の個数に関する最大数と同じ数だけＣＩＦコードポイントを格納可能な通知フォーマットが用いられる。ここでは、説明を簡単にするために、図７の上段の通知フォーマットが用いられる場合について説明する。
【０１１５】
ここで、３個のＣＦＩ値の内、２つのＣＦＩ値のみを、追加のＣＣに割り当てる場合には、次のような方法で通知がなされる。
【０１１６】
例えば、２つのＣＩＦコードポイント６，８とＣＦＩ＝２，３とをそれぞれ対応づけたい場合には、３つの通知フィールドに、ＣＩＦコードポイント＝１，６，８をそれぞれ格納する。ここで、追加したＣＣとＰＤＣＣＨを送信するＣＣとが同一の場合には、ＣＩＦコードポイントの通知内容によらず、ＣＩＦ＝１を用いるというルールで運用される。こうすると、通知フォーマット内にＣＩＦ＝１が格納された場合には、このＣＩＦコードポイントは、無効として扱うことができる。従って、上記のように、３つの通知フィールドに、ＣＩＦコードポイント＝１，６，８をそれぞれ格納された場合には、ＣＩＦコードポイント６，８のみが有効であり、それぞれが格納されたフィールドと対応するＣＦＩ値＝２，３の通知が可能となる。
【０１１７】
これにより、どのＣＦＩ値を使用するかについての、追加のシグナリングなしで、実際に使用されるＣＦＩ値を通知することができる。
【０１１８】
［実施の形態３］
実施の形態３では、１つのＣＣ当たりの使用可能なコードポイント数が異なる複数のＣＩＦテーブルを定義しておき、どのテーブルを使用するかを端末毎にあらかじめ設定する。これにより、各端末の受信能力(UE capability)、各端末の通信状況、又はセル環境に適したＣＩＦテーブルを使用することができる。
【０１１９】
実施の形態３に係る基地局及び端末の基本構成は、実施の形態１と共通するので、図２、３を援用して説明する。
【０１２０】
実施の形態３に係る基地局１００のメモリ１０２は、ＣＩＦテーブルフォーマット群を記憶している。このＣＩＦテーブルフォーマット群の例が、図９に示されている。図９に示すように、ＣＩＦテーブルフォーマットは、複数のサブセットを有する。このサブセットは、１つのＣＣに割り当てる単位である。各サブセットは、１つ又は複数のＣＩＦコードポイントを含んでいる。そして、ＣＩＦテーブルフォーマットは、互いに、サブセットに含まれるＣＩＦコードポイントの数（つまり、有しているサブセットの数）、及び、サブセットに含まれるＣＦＩ値の組み合わせの少なくとも一方が異なっている。
【０１２１】
設定部１０１は、各端末２００に対して、メモリ１０２に記憶されている複数のＣＩＦテーブルフォーマットの内、どのテーブルフォーマットを使うかを設定する。この設定されたＣＩＦテーブルフォーマットに関する情報は、設定情報として端末２００に通知される。このテーブルフォーマットの設定及び通知は、端末２００の通信開始のためにアイドルモードからアクティブモードへ遷移したとき、又は、無線ベアラが張られたときに、行われる。つまり、テーブルフォーマットの設定及び通知は、UE CC setの変更よりも長い区間で設定される。
【０１２２】
また、設定部１０１は、各端末２００に対してＣＣを追加する場合、予め端末２００ごとに設定されているＣＩＦテーブルフォーマットのサブセット番号であって、追加のＣＣに割り当てられるサブセット番号を端末２００へ通知する。これにより、端末２００は、通知されたサブセット番号に含まれる全てのＣＩＦコードポイントに対して追加のＣＣを対応付けることができる。
【０１２３】
実施の形態３に係る端末２００のＣＩＦテーブル設定部２０７は、基地局から通知されたテーブルフォーマットをＰＤＣＣＨ受信部２０８に設定する。また、ＣＩＦテーブル設定部２０７は、ＣＣ追加時に通知されるサブセット番号によって、ＣＩＦテーブルを更新する。
【０１２４】
以上の構成を有する基地局１００及び端末２００の動作について図９を用いて説明する。
【０１２５】
図９に示すように、ＣＩＦテーブルフォーマットは、複数のサブセットを有する。１つ又は複数のＣＩＦコードポイントを振り分け単位として、ＣＩＦコードポイントが、サブセットに振り分けられている。テーブルフォーマット１では、各サブセットは、３つのＣＩＦコードポイントを含んでいる。また、テーブルフォーマット２〜４のそれぞれでは、各サブセットは、基本的に、２つのＣＩＦコードポイントを含んでいる。
【０１２６】
そして、ＣＩＦテーブルフォーマットは、互いに、サブセットに含まれるＣＩＦコードポイントの数（つまり、有しているサブセットの数）、及び、サブセットに含まれるＣＦＩ値の組み合わせの少なくとも一方が異なっている。すなわち、テーブルフォーマット１と、テーブルフォーマット２〜４とでは、サブセットに含まれるＣＩＦコードポイントの数が異なっている。また、デーブルフォーマット２〜４は、互いに、サブセットに含まれるＣＦＩ値の組み合わせが異なっている。すなわち、テーブルフォーマット２では、サブセットに含まれるＣＦＩ値の組み合わせは、１，２であり、テーブルフォーマット３では、２，３であり、テーブルフォーマット４では、１，３である。
【０１２７】
また、各テーブルフォーマットにおいて、ＣＩＦ＝８を含むサブセットは、１つのＣＩＦのみを含んでいる。そして、ＣＩＦ＝８には、各テーブルフォーマットで割り当て可能なＣＦＩ値の内、最も大きな値が設定される。すなわち、テーブルフォーマット２では、ＣＦＩ値として２が設定され、テーブルフォーマット３では、３が設定され、テーブルフォーマット４では、３が設定されている。このようにする理由は、以下の通りである。すなわち、或るＣＣの制御チャネル領域のＯＦＤＭシンボル数が、或る端末２００に設定されたテーブルフォーマットで通知可能なＣＦＩ値よりも少ない場合でも、その端末２００宛のデータ信号（ＰＤＳＣＨ)がマッピングされる先頭のＯＦＤＭシンボルが、ＣＦＩで通知されたものとなっていれば良い。このため、このようにすることで、制御チャネルとデータ信号とが重なることがない。一方、ＣＩＦ＝８に小さなＣＦＩ値を設定する場合には、或るＣＣの制御チャネル領域のＯＦＤＭシンボル数が、ＣＩＦ＝８に設定されたＣＦＩ値よりも多い場合が発生し、この場合には、制御チャネルとデータ信号とが重なってしまう。このため、いずれかのチャネルを送信できなくなる事態が生じる。以上のことから、ＣＩＦ＝８には、各テーブルフォーマットで割り当て可能なＣＦＩ値の内、最も大きな値が設定される。
【０１２８】
設定部１０１は、各端末２００に対して、メモリ１０２に記憶されている複数のＣＩＦテーブルフォーマットの内、どのテーブルフォーマットを使うかを設定し、設定情報を各端末２００へ通知する。
【０１２９】
設定部１０１は、受信可能なＣＣの数が３までの能力である端末には、テーブルフォーマット１を設定し、４以上の能力である端末には、テーブルフォーマット２〜４を設定する。又は、設定部１０１は、高速伝送が要求される端末には、設定可能なＣＣの数（つまり、有しているサブセットの数）が多いテーブルフォーマット２〜４を設定し、そうでない端末には、テーブル１を設定する。
【０１３０】
また、設定部１０１は、テーブルフォーマットを、セル単位で設定することもできる。例えば、設定部１０１は、他のＣＣでデータ割当通知が行われるＣＣの数が多いような運用が為されているセルでは、テーブルフォーマット２〜４を各端末に設定し、そのようなＣＣの数が少ないような運用が為されているセルでは、テーブルフォーマット１を設定する。
【０１３１】
また、設定部１０１は、セル半径の大きなセルでは、各サブセットに大きな値のＣＦＩ値が割り当てられているテーブルフォーマットを設定する。すなわち、セル半径の大きなセル(例えば，マクロセル)では、収容する端末の数が多い。このため、多くのＰＤＣＣＨリソースが必要となる場合が多い。このため、各サブセットに大きな値のＣＦＩ値（例えば、２，３）が割り当てられているテーブルフォーマットが設定される。
【０１３２】
逆に、設定部１０１は、セル半径の小さなセルでは、各サブセットに小さな値のＣＦＩ値が割り当てられているテーブルフォーマットを設定する。すなわち、セル半径の小さなセル(例えば，ピコセル，フェムトセル)では、収容する端末の数が少ない。このため、必要なＰＤＣＣＨリソース領域が少ない場合が多い。このため、各サブセットに小さな値のＣＦＩ値（例えば、１，２）が割り当てられているテーブルフォーマットが設定される。
【０１３３】
また、設定部１０１は、端末の数の増減が激しいようなセル（ホットスポットなど）では、各サブセットに大きな値のＣＦＩ値及び小さな値のＣＦＩ値の両方（例えば、１，３）が割り当てられているテーブルフォーマットを設定する。
【０１３４】
以上のように、設定部１０１は、各端末２００に対して、メモリ１０２に記憶されている複数のＣＩＦテーブルフォーマットの内、どのテーブルフォーマットを使うかを設定する。そして、メモリ１０２に記憶されている複数のＣＩＦテーブルフォーマットは、互いに、サブセットに含まれるＣＩＦコードポイントの数（つまり、有しているサブセットの数）、及び、サブセットに含まれるＣＦＩ値の組み合わせの少なくとも一方が異なっている。
【０１３５】
こうすることで、CC追加時には、設定部１０１は各端末２００に対してサブセット番号を通知するだけで良い。これにより、通知にかかるビット数を低減できる。また、テーブルフォーマットを予め定義することにより、或るＣＣを割り当てるのに用いられる複数のＣＩＦコードポイントの組み合わせが限定される。このため、システム及び端末を簡素化できると共に、それらのテスト工数を低減できる。
【０１３６】
なお、メモリ１０２には、図１０に示すようなテーブルフォーマット５を予め定義しておいても良い。すなわち、この種のテーブルフォーマットでは、サブセット毎にＣＦＩ値の組み合わせが異なっている。この種のテーブルフォーマットは、４ＣＣ又は５ＣＣを割り当てることができるテーブルフォーマットとして有用である。
【０１３７】
また、図９のテーブルフォーマット１は３ＣＣ向け、テーブルフォーマット２〜４は４、５ＣＣ向けとして説明したが、４ＣＣ向けのテーブルフォーマットとして、ＣＩＦ＝２，３，４がサブセット１、ＣＩＦ＝５、６がサブセット２、ＣＩＦ＝７、８がサブセット３というテーブルフォーマットを別途定義してもよい。こうすることで、通知可能なＣＦＩ数をＣＣごとに最大にすることが可能である。
【０１３８】
［他の実施の形態］
（１）上記各実施の形態では、或るＣＣのＰＤＣＣＨで他のＣＣにおけるＣＦＩを通知するだけでなく、各ＣＣのＰＤＣＣＨでもそのＣＣにおけるＣＦＩを通知するものとして説明を行った。しかしながら、これに限定されるものではなく、各ＣＣのＰＤＣＣＨでは、そのＣＣにおけるＣＦＩを通知しなくても良い。すなわち、或るＣＣのＰＤＣＣＨだけで他のＣＣにおけるＣＦＩを通知する構成としても良い。この場合、端末２００は、ＣＣ追加時にその追加されるＣＣに関する情報を含むＰＤＣＣＨを送信するＣＣがその追加されるＣＣと同じ場合には、そのＰＤＣＣＨにはＣＩＦが含まれない解釈し、ＣＩＦコードポイントが通知されていないと判断するか、又は、ＣＩＦコードポイントが通知されたとしてもその割り当てが無効であると判断する。一方、ＣＣ追加時にその追加されるＣＣに関する情報を含むＰＤＣＣＨを送信するＣＣがその追加されるＣＣと異なる場合には、そのＰＤＣＣＨにはＣＩＦが含まれていると解釈し、ＣＩＦコードポイントが通知されていると判断する。この場合、ＰＤＣＣＨ毎にＣＩＦのあり／なしに関する情報の通知を別途行う必要がない。また、ＣＣ毎にＣＩＦありの運用とＣＩＦなしの運用を行うようなシステムであっても、端末２００は、UE CC setにＣＣが追加されるときに、その追加されるＣＣからＣＩＦによる通知が為されるのか又はその追加のＣＣと異なるＣＣからＣＩＦによる通知がなされるのかを判断すれば良い。従って、そのどちらの場合でも、端末２００は共通の動作を行えば良いので、システム及び端末を簡素化することができる。
【０１３９】
（２）上記各実施の形態では、UE CC setの追加又は削除時に、RRCシグナリングで通知が行われるものとして説明を行った。しかしながら、これに限定されるものではなく、それよりダイナミックな制御が行われる場合にも、本発明は、適用可能である。例えば、ＭＡＣヘッダ又はＰＤＣＣＨによって、ＣＣの追加又は削除（つまり、CC activation/deactivation）が通知される場合にも、ＣＩＦコードポイントを指定するようにしても良い。
【０１４０】
（３）上記各実施の形態では、１つのＣＣ当たりに、１つのＰＤＣＣＨが送信されるものとして説明を行った。しかしながら、これに限定されるものではなく、１つのＣＣ当たりに、２つ以上のＰＤＣＣＨが送信されても良い。この設定の場合には、ＣＣ追加時に、１つのＣＣに含まれる２つ以上のＰＤＣＣＨ  ＣＣのそれぞれに対して、ＣＩＦコードポイントを割り当てる。
【０１４１】
（４）上記各実施の形態では、ＣＦＩは制御チャネル領域を示すものとして説明した。しかしながら、これに限定されるものではなく、ＣＦＩはデータがマッピングされる先頭のＯＦＤＭシンボルを示す情報であっても良い。例えば、或るＣＣでは、ＣＦＩ＝２である（つまり、２ＯＦＤＭシンボル目までが、制御チャネルに使われる）が、或る端末２００にとってのデータがマッピングされる先頭のＯＦＤＭシンボルの番号が４であるケースがあっても良い。また、例えば、或るＣＣにおいて、或る端末２００に対してＣＦＩ＝３のみを通知可能な状態であっても、そのＣＣの制御チャネル量が少ない場合には、少ない制御チャネル領域(例えば、２ＯＦＤＭシンボル)を設定することが可能である。
【０１４２】
（５）上記説明では、ＣＩＦのビット数が２ビット及び３ビットの場合を説明したが、その他のビット数の場合でもよい。また、セルごとあるいは端末ごとに異なるビット数であってもよい。
【０１４３】
（６）上記説明では、ＣＩＦにおいて、ＣＩ及びＣＦＩを通知する例を説明したが、ＣＦＩ以外の情報を通知する場合でも、本発明を適用することができる。
【０１４４】
（７）上記各実施の形態では、下り回線のＣＣが割り当てられる場合について説明を行ったが、各実施の形態で説明した技術は、上り回線のＣＣが割り当てられる場合にも適用可能である。また、上り回線と下り回線とのペアでＣＣの追加又は削除が行われても良いし、又は、上り回線と下り回線とで独立に行われても良い。
【０１４５】
（８）上記したUE CC setは、下り回線のＣＣに対してUE DL CC set、上り回線のＣＣに対してUE UL CC setと呼ばれることもある。
【０１４６】
（９）上記したＰＤＣＣＨフォーマットは、ＤＣＩ(Downlink Control Information)フォーマットと呼ばれることもある。
【０１４７】
（１０）上記したcarrier aggregationは、band aggregationと呼ばれることもある。また、carrier aggregationでは、非連続の帯域が連結されても良い。
【０１４８】
（１１）上記した「単位キャリア」は、最大２０ＭＨｚの幅を持つ帯域であって、通信帯域の基本単位として定義したが、次のように定義されることもある。下り回線における「単位キャリア」（以下、「下り単位キャリア」という）は基地局から報知されるＢＣＨの中の下り周波数帯域情報によって区切られた帯域、または、下り制御チャネル（Physical Downlink Control Channel：ＰＤＣＣＨ）が周波数領域に分散配置される場合の分散幅によって定義される帯域として定義されることもある。また、上り回線における「単位キャリア」（以下、「上り単位キャリア」という）は、基地局から報知されるＢＣＨの中の上り周波数帯域情報によって区切られた帯域、または、中心付近にＰＵＳＣＨを含み、両端部にＰＵＣＣＨを含む２０ＭＨｚ以下の通信帯域の基本単位として定義されることもある。また、「単位キャリア」は、３ＧＰＰ  ＬＴＥにおいて、英語でＣｏｍｐｏｎｅｎｔ  Ｃａｒｒｉｅｒ（ｓ）と表記されることがある。また、単位帯域と呼ばれることもある。さらに、Ｃｏｍｐｏｎｅｎｔ  Ｃａｒｒｉｅｒは物理セル番号とキャリア周波数番号で定義されてもよく、セルと呼ばれることもある。
【０１４９】
（１２）ＰＤＣＣＨは、必ず主単位キャリアで送信されるようにしても良い。また、主単位キャリアは、システムで決められた単位キャリア（例えば、ＳＣＨ又はＰＢＣＨが送信される単位キャリア）としても良いし、又は、セル毎に、端末２００間で共通のものが設定されても良いし端末２００毎に設定されても良い。
【０１５０】
（１３）上記各実施の形態では、本発明をハードウェアで構成する場合を例にとって説明したが、本発明はソフトウェアで実現することも可能である。
【０１５１】
また、上記各実施の形態の説明に用いた各機能ブロックは、典型的には集積回路であるＬＳＩとして実現される。これらは個別に１チップ化されてもよいし、一部または全てを含むように１チップ化されてもよい。ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。
【０１５２】
また、集積回路化の手法はＬＳＩに限るものではなく、専用回路または汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサーを利用してもよい。
【０１５３】
さらには、半導体技術の進歩または派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。
【０１５４】
２０１０年２月１５日出願の特願２０１０−０３０２６７の日本出願に含まれる明細書、図面および要約書の開示内容は、すべて本願に援用される。
【産業上の利用可能性】
【０１５５】
本発明は、Carrier aggregationの通信時に使用されるCCが追加される場合に、使用ＣＣに関する通知に必要なビット数の増加を抑えると共に、データ送信に関する遅延を防止することができるものとして有用である。
【符号の説明】
【０１５６】
１００  基地局
１０１  設定部
１０２  メモリ
１０３  制御部
１０４  ＰＤＣＣＨ生成部
１０５，１０６，１０７  符号化部
１０８，１０９，１１０，２１０，２１１  変調部
１１１  割当部
１１２  ＰＣＦＩＣＨ生成部
１１３  多重部
１１４，２１４  ＩＦＦＴ部
１１５，２１５  ＣＰ付加部
１１６，２１６  送信ＲＦ部
１１７，２０１  受信ＲＦ部
１１８，２０２  ＣＰ除去部
１１９，２０３  ＦＦＴ部
１２０  抽出部
１２１  ＩＤＦＴ部
１２２  データ受信部
２００  端末
２０４  分離部
２０５  設定情報受信部
２０６  ＰＣＦＩＣＨ受信部
２０７  ＣＩＦテーブル設定部
２０８  ＰＤＣＣＨ受信部
２０９  ＰＤＳＣＨ受信部
２１２  ＤＦＴ部
２１３  マッピング部
【図１】
0005501512.tif 000002
【図２】
0005501512.tif 000003
【図３】
0005501512.tif 000004
【図４】
0005501512.tif 000005
【図５】
0005501512.tif 000006
【図６】
0005501512.tif 000007
【図７】
0005501512.tif 000008
【図８】
0005501512.tif 000009
【図９】
0005501512.tif 000010
【図１０】
0005501512.tif 000011