(57)【要約】【課題】通常モードの端末とMTCカバレッジエンハンスメントモードの端末との間のPUCCHリソースの衝突を回避する。【解決手段】受信部２０２は、下りリンクデータの割当を示す制御情報、及び、前記下りリンクデータを受信し、送信部は、自端末が、レピティション送信が適用される第１の端末である場合には第１のリソース群の中のリソースを用いて応答信号を送信し、自端末が、レピティション送信が適用されない第２の端末である場合には第１のリソース群とは異なる第２のリソース群の中のリソースを用いて応答信号を送信する。【選択図】図９
2020005292.tif 000002
【特許請求の範囲】
【請求項１】
下り制御情報、及び、下りデータを受信する受信部と、
前記下り制御情報に基づいて、前記下りデータに対する応答信号に使用される上り制御チャネルリソースを決定する制御部と、
前記決定された上り制御チャネルリソースとの対応付けから特定される、複数の直交符号系列のうちの一つ及び複数の巡回シフト量のうちの一つの組合せを用いて、前記応答信号を送信する送信部と、
を具備し、
前記対応付けは、一つの直交符号系列に組み合わされる隣接する巡回シフト量の差に基づき、
前記応答信号を複数のサブフレームに渡ってレピティション送信することが可能なカバレッジエンハンスメントモードが設定されている場合の前記巡回シフト量の差は、前記カバレッジエンハンスメントモードが設定されていない場合の前記巡回シフト量の差とは独立に設定される、
端末。
【請求項２】
下り制御情報、及び、下りデータを受信する受信部と、
前記下り制御情報に基づいて、前記下りデータに対する応答信号に使用される上り制御チャネルリソースを決定する制御部と、
前記決定された上り制御チャネルリソースとの対応付けから特定される、複数の直交符号系列のうちの一つ及び複数の巡回シフト量のうちの一つの組合せを用いて、前記応答信号を送信する送信部と、
を具備し、
前記対応付けは、一つの直交符号系列に組み合わされる隣接する巡回シフト量の差に基づき、
カバレッジエンハンスメントモードが設定された複数のサブフレームに渡ってレピティション送信が可能な前記下り制御情報を受信した場合の前記巡回シフト量の差は、前記カバレッジエンハンスメントモードが設定されていない場合の前記巡回シフト量の差とは独立に設定される、
端末。
【請求項３】
前記カバレッジエンハンスメントモードにおいて、前記受信部は、複数のサブフレームに渡ってリピティション送信された前記下り制御情報を受信する、
請求項１又は２に記載の端末。
【請求項４】
前記カバレッジエンハンスメントモードにおける前記対応付けが、前記カバレッジエンハンスメントモードが設定されていない場合の前記対応付けと異なる、
請求項１から３のいずれかに記載の端末。
【請求項５】
前記カバレッジエンハンスメントモードにおける前記巡回シフト量の差は、前記カバレッジエンハンスメントモードが設定されていない場合の前記巡回シフト量の差とは異なる、
請求項１から４のいずれかに記載の端末。
【請求項６】
前記カバレッジエンハンスメントモードにおいて、前記送信部は、前記応答信号を複数のサブフレームに渡ってリピティション送信する、
請求項１から５のいずれかに記載の端末。
【請求項７】
前記カバレッジエンハンスメントモードにおいて、前記送信部は、前記下りデータを受信したサブフレームから所定数のサブフレーム後に、前記応答信号を送信する、
請求項１から６のいずれかに記載の端末。
【請求項８】
前記カバレッジエンハンスメントモードにおいて、前記受信部は、複数のサブフレームに渡ってリピティション送信された前記下りデータを受信する、
請求項１から７のいずれかに記載の端末。
【請求項９】
端末が、
下り制御情報、及び、下りデータを受信する工程と、
前記下り制御情報に基づいて、前記下りデータに対する応答信号に使用される上り制御チャネルリソースを決定する工程と、
前記決定された上り制御チャネルリソースとの対応付けから特定される、複数の直交符号系列のうちの一つ及び複数の巡回シフト量のうちの一つの組合せを用いて、前記応答信号を送信する工程と、
を具備し、
前記対応付けは、一つの直交符号系列に組み合わされる隣接する巡回シフト量の差に基づき、
前記応答信号を複数のサブフレームに渡ってレピティション送信することが可能なカバレッジエンハンスメントモードが設定されている場合の前記巡回シフト量の差は、前記カバレッジエンハンスメントモードが設定されていない場合の前記巡回シフト量の差とは独立に設定される、
通信方法。
【請求項１０】
端末が、
下り制御情報、及び、下りデータを受信する工程と、
前記下り制御情報に基づいて、前記下りデータに対する応答信号に使用される上り制御チャネルリソースを決定する工程と、
前記決定された上り制御チャネルリソースとの対応付けから特定される、複数の直交符号系列のうちの一つ及び複数の巡回シフト量のうちの一つの組合せを用いて、前記応答信号を送信する工程と、
を具備し、
前記対応付けは、一つの直交符号系列に組み合わされる隣接する巡回シフト量の差に基づき、
カバレッジエンハンスメントモードが設定された複数のサブフレームに渡ってレピティション送信が可能な前記下り制御情報を受信した場合の前記巡回シフト量の差は、前記カバレッジエンハンスメントモードが設定されていない場合の前記巡回シフト量の差とは独立に設定される、
通信方法。
【請求項１１】
下り制御情報、及び、下りデータを受信する処理と、
前記下り制御情報に基づいて、前記下りデータに対する応答信号に使用される上り制御チャネルリソースを決定する処理と、
前記決定された上り制御チャネルリソースとの対応付けから特定される、複数の直交符号系列のうちの一つ及び複数の巡回シフト量のうちの一つの組合せを用いて、前記応答信号を送信する処理と、
を制御し、
前記対応付けは、一つの直交符号系列に組み合わされる隣接する巡回シフト量の差に基づき、
前記応答信号を複数のサブフレームに渡ってレピティション送信することが可能なカバレッジエンハンスメントモードが設定されている場合の前記巡回シフト量の差は、前記カバレッジエンハンスメントモードが設定されていない場合の前記巡回シフト量の差とは独立に設定される、
集積回路。
【請求項１２】
下り制御情報、及び、下りデータを受信する処理と、
前記下り制御情報に基づいて、前記下りデータに対する応答信号に使用される上り制御チャネルリソースを決定する処理と、
前記決定された上り制御チャネルリソースとの対応付けから特定される、複数の直交符号系列のうちの一つ及び複数の巡回シフト量のうちの一つの組合せを用いて、前記応答信号を送信する処理と、
を制御し、
前記対応付けは、一つの直交符号系列に組み合わされる隣接する巡回シフト量の差に基づき、
カバレッジエンハンスメントモードが設定された複数のサブフレームに渡ってレピティション送信が可能な前記下り制御情報を受信した場合の前記巡回シフト量の差は、前記カバレッジエンハンスメントモードが設定されていない場合の前記巡回シフト量の差とは独立に設定される、
集積回路。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、端末、通信方法及び集積回路に関する。
【背景技術】
【０００２】
3GPP LTE（3rd Generation Partnership Project Long Term Evolution）では、下りリンクの通信方式として直交周波数分割マルチアクセス（OFDMA：Orthogonal Frequency Division Multiple Access）が採用されている。
【０００３】
3GPP LTEが適用された無線通信システムでは、基地局（eNBと呼ぶこともある）は、予め定められた通信リソースを用いて、同期信号（SCH: Synchronization Channel）及び報知信号（PBCH: Physical Broadcast Channel）を送信する。そして、端末（UE（User Equipment）と呼ぶこともある）は、まずSCHを捕まえることによって基地局との同期を確保する。その後、端末は、BCH情報を読むことにより基地局独自のパラメータ（例えば、周波数帯域幅など）を取得する（例えば、非特許文献１〜３を参照）。
【０００４】
また、端末は、基地局独自のパラメータの取得が完了した後、基地局に対して接続要求を行うことにより、基地局との通信を確立する。基地局は、通信が確立された端末に対して、必要に応じてPDCCH（Physical Downlink Control Channel）等の制御チャネルを介して制御情報を送信する。そして、端末は、受信したPDCCH信号に含まれる複数の制御情報をそれぞれ「ブラインド判定」する。すなわち、制御情報は、CRC（Cyclic Redundancy Check）部分を含み、このCRC部分は、基地局において、送信対象端末の端末IDによってマスクされる。従って、端末は、受信した制御情報のCRC部分を自機の端末IDによってデマスクしてみるまでは、自機宛の制御情報であるか否かを判定できない。このブラインド判定では、デマスクした結果、CRC演算がＯＫとなれば、その制御情報が自機宛であると判定される。
【０００５】
また、LTEでは、基地局から端末への下りリンクデータに対してHARQ（Hybrid Automatic Repeat Request）が適用される。つまり、端末は、下りリンクデータの誤り検出結果を示す応答信号を基地局へフィードバックする。端末は、下りリンクデータに対してCRCを行って、CRC=OK（誤りなし）であれば肯定応答（ACK: Acknowledgement）を、CRC=NG（誤りあり）であれば否定応答（NACK: Negative Acknowledgement）を応答信号として基地局へフィードバックする。この応答信号（つまり、ACK/NACK信号）のフィードバックには、PUCCH（Physical Uplink Control Channel）等の上りリンク制御チャネルが用いられる。
【０００６】
ここで、基地局から送信される上記制御情報には，基地局が端末に対して割り当てたリソース情報等を含むリソース割当情報が含まれる。この制御情報の送信には、前述のとおりPDCCHが用いられる。PDCCHは、１つ又は複数のL1/L2 CCH（L1/L2 Control Channel）から構成される。各L1/L2 CCHは、１つ又は複数のCCE（Control Channel Element）から構成される。すなわち、CCEは、制御情報をPDCCHにマッピングするときの基本単位である。また、１つのL1/L2 CCHが複数のCCEから構成される場合には、そのL1/L2 CCHには連続する複数のCCEが割り当てられる。基地局は、リソース割当対象端末に対する制御情報の通知に必要なCCE数に従って、そのリソース割当対象端末に対してL1/L2 CCHを割り当てる。そして、基地局は、このL1/L2 CCHのCCEに対応する物理リソースに制御情報をマッピングして送信する。
【０００７】
また、各CCEは、PUCCHの構成リソース（以下、PUCCHリソースと呼ぶ）と１対１に対応付けられている。したがって、L1/L2 CCHを受信した端末は、このL1/L2 CCHを構成するCCEに対応するPUCCHリソースを特定し、このPUCCHリソースを用いてACK/NACK信号を基地局へ送信する。ただし、L1/L2 CCHが連続する複数のCCEを占有する場合には、端末は、複数のCCEにそれぞれ対応する複数のPUCCHリソースのうち１つのリソース（例えば、インデックスが最も小さいCCEに対応するPUCCHリソース）を利用して、ACK/NACK信号を基地局へ送信する。
【０００８】
また、図１に示すように、端末におけるPUCCHでのACK/NACK信号の送信タイミングは、受信したPDCCH信号及びそのPDDCH信号によりデータが割り当てられたPDSCH（Physical Downlink Shared Channel）信号を受信したサブフレーム（図１ではサブフレームｎ）から、Ｋサブフレーム後（例えばFDD（Frequency Division Duplex）ではK=4）のサブフレーム（図１ではサブフレームｎ＋Ｋ）となる。
【０００９】
複数の端末から送信される複数のACK/NACK信号は、図２に示すように、時間軸上においてZero Auto-correlation特性を持つZAC（Zero Auto-correlation）系列、ウォルシュ（Walsh）系列及びDFT（Discrete Fourier Transform）系列によって拡散され、PUCCH内においてコード多重されている。図２において、（W(0), W(1), W(2), W(3)）は系列長４のウォルシュ系列を表し、（F(0),F(1),F(2)）は系列長３のDFT系列を表す。
【００１０】
図２に示すように、端末ではACK/NACK信号は、まず周波数軸上においてZAC系列（系列長１２）によって１SC-FDMA（Single-Carrier Frequency Division Multiple Access）シンボルに対応する周波数成分へ１次拡散される。つまり、系列長１２のZAC系列に対して、複素数で表されるACK/NACK信号成分が乗算される。次に、１次拡散後のACK/NACK信号、及び、参照信号としてのZAC系列は、それぞれウォルシュ系列（系列長４: W(0)〜W(3)）及びDFT系列（系列長３: F(0)〜F(2)）によって２次拡散される。つまり、系列長１２の信号（１次拡散後のACK/NACK信号、又は、参照信号としてのZAC系列）のそれぞれの成分に対して、直交符号系列（Orthogonal sequence: ウォルシュ系列又はDFT系列）の各成分が乗算される。さらに、２次拡散された信号は、逆離散フーリエ変換（IDFT: Inverse Discrete Fourier Transform。又はIFFT： Inverse Fast Fourier Transform）によって時間軸上の系列長１２の信号に変換される。そして、IFFT後の信号のそれぞれに対して、サイクリックプリフィックス（CP：Cyclic Prefix）が付加され、７つのSC-FDMAシンボルからなる１スロットの信号が形成される。
【００１１】
PUCCHは、周波数軸においてシステム帯域両端に配置される。また、PUCCHでは、サブフレーム単位で各端末に無線リソースが割り当てられる。また、１サブフレームは２スロットで構成され、PUCCHは前半スロットと後半スロットとで周波数ホッピング（スロット間周波数ホッピング）される。
【００１２】
異なる端末からのACK/NACK信号同士は、異なる巡回シフト量（Cyclic Shift Index）に対応するZAC系列、又は、異なる系列番号（OC Index: Orthogonal Cover Index）に対応する直交符号系列を用いて拡散されている。直交符号系列は、ウォルシュ系列とDFT系列との組である。また、直交符号系列は、ブロックワイズ拡散コード系列（Block-wise spreading code）と称されることもある。したがって、基地局は、従来の逆拡散及び相関処理を用いることにより、これらのコード多重された複数のACK/NACK信号を分離することができる（例えば、非特許文献４を参照）。図３は、直交符号系列の系列番号（OC index：０〜２）及びZAC系列の巡回シフト量（Cyclic shift Index：０〜１１）によって定義されるPUCCHリソースを示す。系列長４のウォルシュ系列及び系列長３のDFT系列を用いた場合、同一サブキャリアには最大で3*12=36個のPUCCHリソースがある。ただし、36個のPUCCHリソースをすべて利用可能とするとは限らない。例えば、図３では１８個のPUCCHリソース（#0〜#17）を利用可能とした場合を示す。
【００１３】
ところで、今後の情報社会を支える仕組みとして、近年、ユーザの判断を介することなく機器間の自律的な通信によりサービスを実現するM2M（Machine-to-Machine）通信が期待されている。M2Mシステムの具体的な応用事例としてスマートグリッドがある。スマートグリッドは、電気又はガスなどのライフラインを効率的に供給するインフラシステムであり、各家庭又はビルに配備されるスマートメータと中央サーバとの間でM2M通信を実施して、自律的かつ効果的に資源の需要バランスを調整する。M2M通信システムの他の応用事例として、物品管理又は遠隔医療などのためのモニタリングシステム、自動販売機の在庫又は課金の遠隔管理などが挙げられる。
【００１４】
M2M通信システムにおいては、特に広範な通信エリアを有するセルラシステムの利用が着目されている。3GPPでは、LTE及びLTE-Advancedの規格化においてセルラネットワークを前提としたM2Mの検討が、マシンタイプ通信（MTC: Machine Type Communication）という名称で進められている。特に、ビルの地下などにあるスマートメータなどMTC通信機器が既存の通信エリアにおいて利用できない場所に配置されている場合に対応するため、通信エリアをさらに拡大する「カバレッジエンハンスメント（Coverage Enhancement）」が検討されている（例えば、非特許文献５を参照）。
【００１５】
特に、MTCカバレッジエンハンスメントでは、同一信号を複数回繰り返して送信するレピティションが通信エリア拡大の重要な技術であると考えられている。具体的には、PDCCH、PDSCH及びPUCCH等の各チャネルにおいてレピティション送信を行うことが想定されている。
【先行技術文献】
【非特許文献】
【００１６】
【非特許文献１】3GPP TS 36.211 V11.5.0, “Physical channels and modulation (Release 11),” December 2013.
【非特許文献２】3GPP TS 36.212 V11.4.0, “Multiplexing and channel coding (Release 11),” December 2013.
【非特許文献３】3GPP TS 36.213 V11.5.0, “Physical layer procedures (Release 11),” December 2013.
【非特許文献４】Seigo Nakao, Tomofumi Takata, Daichi Imamura, and Katsuhiko Hiramatsu, “Performance enhancement of E-UTRA uplink control channel in fast fading environments,” Proceeding of 2009 IEEE 69th Vehicular Technology Conference (VTC2009-Spring), April 2009.
【非特許文献５】3GPP TR 36.888 V12.0.0, “Study on provision of low-cost Machine-Type Communications (MTC) User Equipments (UEs) based on LTE、” June 2013.
【発明の概要】
【発明が解決しようとする課題】
【００１７】
しかしながら、MTCカバレッジエンハンスメントモードの端末（レピティション送信を行う端末）がACK/NACK信号を送信するPUCCHリソースについては、未だ十分な検討がなされていない。特に、MTCカバレッジエンハンスメントモードの端末と通常モードの端末（レピティション送信を行わない端末）とが共存している場合には、MTCカバレッジエンハンスメントモードの端末が使用するPUCCHリソースを、通常モードの端末が使用するPUCCHリソースと衝突しないように設計することが必要である。
【００１８】
本開示の一態様は、PDCCHリソースの周波数利用効率の低下及びスケジューリングの複雑度の増加をさせることなく、通常モードの端末とMTCカバレッジエンハンスメントモードの端末との間のPUCCHリソースの衝突を回避することができる端末、通信方法及び集積回路を提供することである。
【課題を解決するための手段】
【００１９】
本開示の一態様に係る端末は、下り制御情報、及び、下りデータを受信する受信部と、前記下り制御情報に基づいて、前記下りデータに対する応答信号に使用される上り制御チャネルリソースを決定する制御部と、前記決定された上り制御チャネルリソースとの対応付けから特定される、複数の直交符号系列のうちの一つ及び複数の巡回シフト量のうちの一つの組合せを用いて、前記応答信号を送信する送信部と、を具備し、前記対応付けは、一つの直交符号系列に組み合わされる隣接する巡回シフト量の差に基づき、前記応答信号を複数のサブフレームに渡ってレピティション送信することが可能なカバレッジエンハンスメントモードが設定されている場合の前記巡回シフト量の差は、前記カバレッジエンハンスメントモードが設定されていない場合の前記巡回シフト量の差とは独立に設定される。
【００２０】
本開示の一態様に係る端末は、下り制御情報、及び、下りデータを受信する受信部と、前記下り制御情報に基づいて、前記下りデータに対する応答信号に使用される上り制御チャネルリソースを決定する制御部と、前記決定された上り制御チャネルリソースとの対応付けから特定される、複数の直交符号系列のうちの一つ及び複数の巡回シフト量のうちの一つの組合せを用いて、前記応答信号を送信する送信部と、を具備し、前記対応付けは、一つの直交符号系列に組み合わされる隣接する巡回シフト量の差に基づき、カバレッジエンハンスメントモードが設定された複数のサブフレームに渡ってレピティション送信が可能な前記下り制御情報を受信した場合の前記巡回シフト量の差は、前記カバレッジエンハンスメントモードが設定されていない場合の前記巡回シフト量の差とは独立に設定される。
【００２１】
本開示の一態様に係る通信方法は、端末が、下り制御情報、及び、下りデータを受信する工程と、前記下り制御情報に基づいて、前記下りデータに対する応答信号に使用される上り制御チャネルリソースを決定する工程と、前記決定された上り制御チャネルリソースとの対応付けから特定される、複数の直交符号系列のうちの一つ及び複数の巡回シフト量のうちの一つの組合せを用いて、前記応答信号を送信する工程と、を具備し、前記対応付けは、一つの直交符号系列に組み合わされる隣接する巡回シフト量の差に基づき、前記応答信号を複数のサブフレームに渡ってレピティション送信することが可能なカバレッジエンハンスメントモードが設定されている場合の前記巡回シフト量の差は、前記カバレッジエンハンスメントモードが設定されていない場合の前記巡回シフト量の差とは独立に設定される。
【００２２】
本開示の一態様に係る通信方法は、端末が、下り制御情報、及び、下りデータを受信する工程と、前記下り制御情報に基づいて、前記下りデータに対する応答信号に使用される上り制御チャネルリソースを決定する工程と、前記決定された上り制御チャネルリソースとの対応付けから特定される、複数の直交符号系列のうちの一つ及び複数の巡回シフト量のうちの一つの組合せを用いて、前記応答信号を送信する工程と、を具備し、前記対応付けは、一つの直交符号系列に組み合わされる隣接する巡回シフト量の差に基づき、カバレッジエンハンスメントモードが設定された複数のサブフレームに渡ってレピティション送信が可能な前記下り制御情報を受信した場合の前記巡回シフト量の差は、前記カバレッジエンハンスメントモードが設定されていない場合の前記巡回シフト量の差とは独立に設定される。
【００２３】
本開示の一態様に係る集積回路は、下り制御情報、及び、下りデータを受信する処理と、前記下り制御情報に基づいて、前記下りデータに対する応答信号に使用される上り制御チャネルリソースを決定する処理と、前記決定された上り制御チャネルリソースとの対応付けから特定される、複数の直交符号系列のうちの一つ及び複数の巡回シフト量のうちの一つの組合せを用いて、前記応答信号を送信する処理と、を制御し、前記対応付けは、一つの直交符号系列に組み合わされる隣接する巡回シフト量の差に基づき、前記応答信号を複数のサブフレームに渡ってレピティション送信することが可能なカバレッジエンハンスメントモードが設定されている場合の前記巡回シフト量の差は、前記カバレッジエンハンスメントモードが設定されていない場合の前記巡回シフト量の差とは独立に設定される。
【００２４】
本開示の一態様に係る集積回路は、下り制御情報、及び、下りデータを受信する処理と、前記下り制御情報に基づいて、前記下りデータに対する応答信号に使用される上り制御チャネルリソースを決定する処理と、前記決定された上り制御チャネルリソースとの対応付けから特定される、複数の直交符号系列のうちの一つ及び複数の巡回シフト量のうちの一つの組合せを用いて、前記応答信号を送信する処理と、を制御し、前記対応付けは、一つの直交符号系列に組み合わされる隣接する巡回シフト量の差に基づき、カバレッジエンハンスメントモードが設定された複数のサブフレームに渡ってレピティション送信が可能な前記下り制御情報を受信した場合の前記巡回シフト量の差は、前記カバレッジエンハンスメントモードが設定されていない場合の前記巡回シフト量の差とは独立に設定される。
【発明の効果】
【００２５】
本開示の一態様によれば、PDCCHリソースの周波数利用効率の低下及びスケジューリングの複雑度の増加をさせることなく、通常モードの端末とMTCカバレッジエンハンスメントモードの端末との間のPUCCHリソースの衝突を回避することができる。
【図面の簡単な説明】
【００２６】
【図１】各チャネルの送信タイミングを示す図
【図２】応答信号及び参照信号の拡散方法を示す図
【図３】PUCCHリソースの一例を示す図
【図４】レピティション送信時の各チャネルの送信タイミングを示す図
【図５】PUCCHリソースの衝突の一例を示す図
【図６】実施の形態１に係る基地局の要部構成を示すブロック図
【図７】実施の形態１に係る端末の要部構成を示すブロック図
【図８】実施の形態１に係る基地局の構成を示すブロック図
【図９】実施の形態１に係る端末の構成を示すブロック図
【図１０】実施の形態１に係るPUCCHリソースを示す図
【図１１】実施の形態２に係るPUCCHリソースを示す図
【図１２】実施の形態３に係るPUCCHリソースを示す図
【図１３】実施の形態４に係るCCEとPUCCHリソースとの対応付けを示す図
【図１４】実施の形態４に係るCCEとPUCCHリソースとの対応付けを示す図
【図１５】実施の形態５に係るPUCCHリソースの衝突の一例を示す図
【図１６】実施の形態５に係る各チャネルの送信タイミングを示す図
【図１７】実施の形態６に係るPUCCHリソースの衝突の一例を示す図
【図１８】実施の形態６に係る各チャネルの送信タイミングを示す図
【発明を実施するための形態】
【００２７】
図４は、本開示の一態様として想定したMTCカバレッジエンハンスメントにおける各チャネルの送信タイミングを示す。図４では、PDCCHのレピティションレベル（レピティション回数、又は、レピティションファクタ）をNPDCCHとし、PDSCHのレピティションレベルをNPDSCHとし、PUCCHのレピティションレベルをNPUCCHとする。また、図４に示すように、MTCカバレッジエンハンスメントでは、PDCCHのレピティション送信後に、当該PDCCHによってデータが割り当てられたPDSCHのレピティション送信が行われる。端末でのACK/NACK信号（PUCCH）の送信タイミングは、PDSCHの受信を終えたサブフレームから、KMTCサブフレーム後となる。
【００２８】
同一基地局がカバーするエリアに、MTCカバレッジエンハンスメントモードの端末（レピティション送信を行う端末）と通常モードの端末（レピティション送信を行わない端末）とが共存している場合、下りリンク制御信号用の制御チャネルを別々に設けると、周波数利用効率が低下してしまう。そこで、通常モードの端末及びMTCカバレッジエンハンスメントモードの端末に対して同一周波数を用いて下りリンク制御チャネル（PDCCH）を設定することが考えられる。
【００２９】
このとき、通常モードの端末とMTCカバレッジエンハンスメントモードの端末とでは、ACK/NACK信号が送信されるサブフレーム（PUCCHのレピティション送信が行われる最初のサブフレーム）と、ACK/NACK信号の送信に用いるPUCCHリソースと関連付けられているCCEを含むPDCCHが送信されるサブフレーム（PDCCHのレピティション送信が行われる最後のサブフレーム）との時間間隔が異なる。そのため、両方の端末が同一サブフレームにおいてACK/NACK信号を送信する場合に、通常モードの端末がACK/NACK信号を送信するPUCCHリソースに関連付けられたCCE番号と、MTCカバレッジエンハンスメントモードの端末がACK/NACK信号を送信するPUCCHリソースに関連付けられたCCE番号とが重なってしまう可能性がある。この場合、双方の端末において同一PUCCHリソースを用いてACK/NACK信号が送信されてしまう。
【００３０】
図５は、通常モードの端末のPUCCHリソースとMTCカバレッジエンハンスメントモードの端末のPUCCHリソースとが衝突する場合の一例を示す。図５において、PUCCHリソースの衝突が発生するサブフレームをnとする。
【００３１】
この場合、通常モードの端末に対しては、サブフレームn-KにおいてPDCCHが送信され、また同一サブフレームn-KにおいてそのPDCCHにより割り当てられたPDSCHが送信される。一方、MTCカバレッジエンハンスメントモードの端末に対しては、サブフレームn-KMTC-NPDSCH-NPDCCH〜n-KMTC-NPDSCH-1においてPDCCHが送信される。また、そのPDCCHにより割り当てられたPDSCHは、サブフレームn-KMTC-NPDSCH〜n-KMTC-1において送信される。
【００３２】
通常モードの端末がPDCCHを送信するサブフレームと、MTCカバレッジエンハンスメントモードの端末がPDCCHを送信するサブフレームとが重なっている場合には、両方の端末が同一のCCEを用いてPDCCHが送信されないようにスケジューリングされる。しかし、それ以外の場合（例えば、図５の場合）、通常モードの端末に対するPDCCH送信とMTCカバレッジエンハンスメントモードの端末に対するPDCCHレピティション送信とに対して同一のCCEを用いることができる。例えば、図５では、MTCカバレッジエンハンスメントモードの端末に対するPDCCHにはCCE#0〜CCE#3が使用され、当該端末は、CCE#0（CCE#0〜CCE#3のうち最小のインデックス）に対応するPUCCHリソースを用いる。また、図５では、通常モードの端末に対するPDCCHにはCCE#0,CCE#1が使用され、当該端末は、CCE#0（CCE#0、CCE#1のうち小さいインデックス）に対応するPUCCHリソースを用いる。
【００３３】
この結果、通常モードの端末とMTCカバレッジエンハンスメントモードの端末との間においてACK/NACK信号を送信するPUCCHリソースの衝突が起こってしまう。
【００３４】
通常モードの端末がACK/NACK信号を送信するPUCCHリソースとMTCカバレッジエンハンスメントモードの端末がACK/NACK信号を送信するPUCCHリソースとが衝突しないように、基地局側において通常モードの端末のPDCCH割当を制御する（過去のサブフレームにおいてMTCカバレッジエンハンスメントモードの端末に対して用いられたCCEを通常モードの端末に割り当てない）ことも可能である。しかし、この場合、PDCCHリソースの利用効率の低下又はスケジューリングの複雑度が増加するなどの問題がある。
【００３５】
以下、本開示の実施の形態について図面を参照して詳細に説明する。
【００３６】
［通信システムの概要］
以下の説明では、FDD（Frequency Division Duplex）システムを例に説明する。
【００３７】
また、本開示の各実施の形態に係る通信システムは、例えば、LTE-Advancedに対応するシステムであって、基地局１００及び端末２００を備える。
【００３８】
端末２００には、通常モード又はMTCカバレッジエンハンスメントモードが設定される。端末２００は、例えば、MTCカバレッジエンハンスメントモードが適用される場合、PDCCH、PDSCH又はPUCCHの送信の際、複数のサブフレームに渡ってレピティション送信を適用する。すなわち、端末２００は、所定のレピティションレベル分の連続するサブフレームにおいて同一の信号を繰り返し送信する。
【００３９】
図６は本開示の実施の形態に係る基地局１００の要部構成を示すブロック図である。図６に示す基地局１００において、送信部１１２は、下りリンクデータの割当を示す制御情報（PDCCH信号）、及び、下りリンクデータ（PDSCH信号）を送信し、制御部１０１は、上記制御情報に基づいて、上記下りリンクデータに対するACK/NACK信号に使用されるリソースを決定し、ACK/NACK信号の受信部（PUCCH抽出部１１６、逆拡散部１１８、相関処理部１１９）は、決定されたリソースを用いてACK/NACK信号を受信する。ここで、上記受信部は、上記制御情報、下りリンクデータ及びACK/NACK信号に対してレピティション送信が適用される第１の端末から送信されるACK/NACK信号を、第１のリソース群（PUCCHリソース領域）の中のリソースを用いて受信し、レピティション送信が適用されない第２の端末から送信されるACK/NACK信号を、第１のリソース群とは異なる第２のリソース群（PUCCHリソース領域）の中のリソースを用いて受信する。
【００４０】
また、図７は、本開示の各実施の形態に係る端末２００の要部構成を示すブロック図である。図７に示す端末２００において、受信部２０２は、下りリンクデータの割当を示す制御情報、及び、下りリンクデータを受信し、制御部２１３は、上記制御情報に基づいて、下りリンクデータに対するACK/NACK信号に使用されるリソースを決定し、ACK/NACK信号の送信部（１次拡散部２１６、２次拡散部２１７、IFFT部２１８）は、決定されたリソースを用いてACK/NACK信号を送信する。ここで、上記送信部は、自端末が、制御情報、下りリンクデータ及びACK/NACK信号に対してレピティション送信が適用される第１の端末である場合には第１のリソース群の中のリソースを用いてACK/NACK信号を送信し、自端末が、レピティション送信が適用されない第２の端末である場合には第１のリソース群とは異なる第２のリソース群の中のリソースを用いてACK/NACK信号を送信する。
【００４１】
（実施の形態１）
［基地局の構成］
図８は、本開示の実施の形態１に係る基地局１００の構成を示すブロック図である。図８において、基地局１００は、制御部１０１と、制御信号生成部１０２と、制御信号符号化部１０３と、制御信号変調部１０４と、報知信号生成部１０５と、データ符号化部１０６と、再送制御部１０７と、データ変調部１０８と、信号割当部１０９と、IFFT部１１０と、CP付加部１１１と、送信部１１２と、アンテナ１１３と、受信部１１４と、CP除去部１１５と、PUCCH抽出部１１６と、系列制御部１１７と、逆拡散部１１８と、相関処理部１１９と、判定部１２０とを有する。
【００４２】
制御部１０１は、リソース割当対象端末２００に対して、制御情報を送信するための下りリソース（下り制御情報割当リソース）、及び、当該制御情報に含まれる、下りリンクデータ（送信データ）を送信するための下りリソース（下りデータ割当リソース）を割り当てる。下り制御情報割当リソースは、PDCCH又はEPDCCH（Enhanced PDCCH）に対応するリソース内で選択される。また、下りデータ割当リソースは、PDSCHに対応するリソース内で選択される。また、同一サブフレーム内にリソース割当対象端末２００が複数有る場合には、制御部１０１は、リソース割当対象端末２００のそれぞれに異なるリソースを割り当てる。下り制御情報割当リソースは、上述したL1/L2 CCHと同等である。すなわち、下り制御情報割当リソースは、１つ又は複数のCCEから構成される。また、上述したようにPUCCHがCCEを用いてImplicitに通知される場合、各CCEは、上りリンク制御チャネル領域（PUCCH領域）のPUCCHリソースと対応付けられている。
【００４３】
制御部１０１は、制御情報を含むPDCCHが占有するCCEに対応するPUCCHリソース（周波数、及び、１次拡散／２次拡散に用いる符号）を特定する。制御部１０１は、端末２００から送信されるPUCCH信号（ACK/NACK信号及び参照信号）の拡散に用いられる可能性があるZAC系列及び直交符号系列（つまり、PUCCHリソース）に関する情報を、系列制御部１１７へ出力し、周波数に関する情報をPUCCH抽出部１１６へ出力する。
【００４４】
また、制御部１０１は、リソース割当対象端末２００に対して、制御情報を送信する際に用いる符号化率を決定し、決定した符号化率を制御信号符号化部１０３へ出力する。また、制御部１０１は、リソース割当対象端末２００に対して、下りリンクデータを送信する際に用いる符号化率を決定し、決定した符号化率をデータ符号化部１０６へ出力する。
【００４５】
なお、決定される符号化率に応じて制御情報のデータ量が異なるので、制御部１０１は、このデータ量の制御情報をマッピング可能なCCEを含む下り制御情報割当リソースを割り当てる。制御部１０１は、制御信号生成部１０２に対して、下りデータ割当リソースに関する情報を出力する。また、制御部１０１は、下りデータ割当リソース及び下り制御情報割当リソースに関する情報を信号割当部１０９に出力する。
【００４６】
また、制御部１０１は、リソース割当対象端末２００に対してMTCカバレッジエンハンスメントモードが設定される場合、当該端末２００の各チャネル（PDCCH、PDSCH又はPUCCH）に対するレピティションレベル（レピティション回数）に関する情報を、制御信号生成部１０２及びデータ符号化部１０６に出力する。
【００４７】
また、制御部１０１は、報知信号生成部１０５に対して、予め基地局毎に決められたパラメータに基づいて報知信号を生成するように指示する。
【００４８】
また、制御部１０１は、PUCCHリソースに関する情報を生成し、制御信号生成部１０２へ出力する。PUCCHリソースに関する情報とは、例えば、通常モードの端末及びMTCカバレッジエンハンスメントモードの端末において使用されるPUCCHリソースを特定するためのパラメータである。なお、PUCCHリソースに関する情報は、セル固有の値として報知情報として端末２００へ通知されてもよく、上位レイヤのシグナリングとして端末２００へ通知されてもよい。
【００４９】
制御信号生成部１０２は、制御部１０１から受け取る情報（下りデータ割当リソースに関する情報、PUCCHのレピティションレベルに関する情報又はPUCCHリソースに関する情報）を用いて制御信号を生成し、制御信号を制御信号符号化部１０３に出力する。リソース割当対象端末２００が複数ある場合、リソース割当対象端末２００同士を区別するために、制御信号には、宛先端末の端末IDが含まれる。例えば、制御信号には、宛先端末の端末IDによってマスキングされたCRCビットが含まれる。また、制御信号生成部１０２は、リソース割当対象端末２００に対してMTCカバレッジエンハンスメントモードが設定される場合、制御部１０１から受け取るレピティションレベルに関する情報に従って、レピティション信号を生成する。すなわち、PDCCHのレピティションレベルが１より大きい場合には、制御信号生成部１０２は、レピティションレベルに対応した連続する複数のサブフレームに渡って、同一の制御信号を制御信号符号化部１０３へ出力する。
【００５０】
制御信号符号化部１０３は、制御部１０１から受け取る符号化率に従って、制御信号生成部１０２から受け取る制御信号を符号化し、符号化後の制御信号を制御信号変調部１０４へ出力する。
【００５１】
制御信号変調部１０４は、制御信号符号化部１０３から受け取る制御信号を変調し、変調後の制御信号を信号割当部１０９へ出力する。
【００５２】
報知信号生成部１０５は、制御部１０１からの指示に従って、報知信号を生成し、報知信号を信号割当部１０９へ出力する。なお、報知信号には、例えば、システム帯域幅、又は、PUCCHリソースに関する信号等が含まれている。また、報知信号には、符号化処理及び変調処理が施されてもよい。
【００５３】
データ符号化部１０６は、制御部１０１から受け取る符号化率に従って、宛先端末毎の送信データ（ビット系列。つまり、下りリンクデータ）を符号化し、符号化後のデータ信号を再送制御部１０７へ出力する。また、データ符号化部１０６は、リソース割当対象端末２００に対してMTCカバレッジエンハンスメントモードが設定される場合、制御部１０１から受け取るレピティションレベルに関する情報に従って、レピティション信号を生成する。すなわち、PDSCHのレピティションレベルが１より大きい場合には、データ符号化部１０６は、レピティションレベルに対応した連続する複数のサブフレームに渡って、同一のデータ信号を再送制御部１０７へ出力する。
【００５４】
再送制御部１０７は、初回送信時には、データ符号化部１０６から受け取る符号化後のデータ信号を保持するとともにデータ変調部１０８へ出力する。再送制御部１０７は、符号化後のデータ信号を、宛先端末毎に保持する。また、再送制御部１０７は、後述する判定部１２０から、送信したデータ信号に対するNACKを受け取ると、対応する保持データをデータ変調部１０８へ出力する。再送制御部１０７は、送信したデータ信号に対するACKを受け取ると、対応する保持データを削除する。
【００５５】
データ変調部１０８は、再送制御部１０７から受け取るデータ信号を変調して、データ変調信号を信号割当部１０９へ出力する。
【００５６】
信号割当部１０９は、制御信号変調部１０４から受け取る制御信号、報知信号生成部１０５から受け取る報知信号、及び、データ変調部１０６から受け取るデータ変調信号を、下りリソース（下りリンクデータ信号割当リソース、下りリンク制御情報割当リソース等）にマッピングし、マッピングした信号をIFFT部１１０へ出力する。具体的には、信号割当部１０９は、制御部１０１から受け取る下り制御情報割当リソースに示されるリソースに制御信号をマッピングし、制御部１０１から受け取る下りデータ割当リソースに示されるリソースにデータ変調信号をマッピングする。また、信号割当部１０９は、予め設定された時間・周波数リソースに報知信号をマッピングする。
【００５７】
IFFT部１１０は、信号割当部１０９から受け取る信号に対してIFFT処理を行うことにより、周波数領域信号を時間領域信号に変換する。IFFT部１１０は、時間領域信号をCP付加部１１１へ出力する。
【００５８】
CP付加部１１１は、IFFT部１１０から受け取る信号に対してCPを付加し、CP付加後の信号（OFDM信号）を送信部１１２へ出力する。
【００５９】
送信部１１２は、CP付加部１１１から受け取るOFDM信号に対してD/A（Digital-to-Analog）変換、アップコンバート等のRF（Radio Frequency）処理を行い、アンテナ１１３を介して端末２００に無線信号を送信する。
【００６０】
受信部１１４は、アンテナ１１３を介して受信された端末２００からの無線信号に対して、ダウンコンバート又はA/D（Analog-to-Digital）変換などのRF処理を行い、得られる受信信号をCP除去部１１５に出力する。
【００６１】
CP除去部１１５は、受信部１１４から受け取る受信信号に付加されているCPを除去し、CP除去後の信号をPUCCH抽出部１１６へ出力する。
【００６２】
PUCCH抽出部１１６は、制御部１０１から受け取る情報に基づいて、CP除去部１１５から受け取る信号から上り制御チャネル信号（PUCCH）を抽出し、抽出したPUCCHを逆拡散部１１８へ出力する。また、PUCCH抽出部１１６は、MTCカバレッジエンハンスメントモードの端末２００が存在する場合、複数サブフレームに渡ってレピティション送信されたPUCCHに対して、同相合成を施してPUCCH（合成信号）を抽出する。
【００６３】
系列制御部１１７は、制御部１０１から受け取るＺＡＣ系列及び直交符号系列に関する情報に基づいて、端末２００から送信されるACK/NACK信号及び参照信号の拡散に用いられる可能性があるZAC系列、及び、直交符号系列を生成する。系列制御部１１７は、直交符号系列を逆拡散部１１８へ出力し、ZAC系列を相関処理部１１９へ出力する。
【００６４】
逆拡散部１１８は、系列制御部１１７から受け取る直交符号系列（端末２００が２次拡散で用いるべき直交符号系列）を用いて、PUCCH抽出部１１６から受け取る信号のうちACK/NACK信号に相当する部分の信号を逆拡散し、逆拡散後の信号を相関処理部１１９に出力する。
【００６５】
相関処理部１１９は、系列制御部１１７から入力されるZAC系列（端末２００が１次拡散で用いる可能性のあるZAC系列）と、逆拡散部１１８から入力される信号との相関値を求めて、相関値を判定部１２０に出力する。
【００６６】
判定部１２０は、相関処理部１１９から受け取る相関値に基づいて、端末２００から送信されたACK/NACK信号が、送信されたデータに対してACK又はNACKのいずれかを示しているかを判定する。判定部１２０は、判定結果を再送制御部１０７に出力する。
【００６７】
［端末の構成］
図９は、本開示の実施の形態１に係る端末２００の構成を示すブロック図である。図９において、端末２００は、アンテナ２０１と、受信部２０２と、CP除去部２０３と、FFT（Fast Fourier Transform）部２０４と、抽出部２０５と、報知信号受信部２０６と、制御信号復調部２０７と、制御信号復号部２０８と、判定部２０９と、データ復調部２１０と、データ復号部２１１と、CRC部２１２と、制御部２１３と、ACK/NACK生成部２１４と、変調部２１５と、１次拡散部２１６と、２次拡散部２１７と、IFFT部２１８と、CP付加部２１９と、送信部２２０とを有する。
【００６８】
受信部２０２は、アンテナ２０１を介して受信された、基地局１００からの無線信号に対してダウンコンバート又はAD変換などのRF処理を行い、ベースバンドのOFDM信号を得る。受信部２０２は、OFDM信号をCP除去部２０３へ出力する。
【００６９】
CP除去部２０３は、受信部２０２から受け取るOFDM信号に付加されているCPを除去し、CP除去後の信号をFFT部２０４へ出力する。
【００７０】
FFT部２０４は、CP除去部２０３から受け取る信号に対してFFT処理を行うことにより、時間領域信号を周波数領域信号に変換する。FFT部２０４は、周波数領域信号を抽出部２０５へ出力する。
【００７１】
抽出部２０５は、FFT部２０４から受け取る信号から報知信号を抽出して、報知信号受信部２０６へ出力する。ここで、報知信号がマッピングされるリソースは予め決まっているので、抽出部２０５は、そのリソースにマッピングされている情報を抽出することにより、報知信号を得る。抽出された報知信号には、例えば、システム帯域幅、又は、PUCCHリソースに関する信号等が含まれている。
【００７２】
また、抽出部２０５は、FFT部２０４から受け取る信号から、下り制御チャネル信号（PDCCH信号）を抽出し、制御信号復調部２０７へ出力する。また、抽出部２０５は、判定部２０９から受け取る、自端末宛の下りデータ割当リソースに関する情報に基づいて、FFT部２０４から受け取る信号から下りリンクデータ（PDSCH信号）を抽出し、データ復調部２１０へ出力する。PDCCH信号には、例えば、下りデータ割当リソースに関する情報、PUCCHのレピティションレベルに関する情報、又は、PUCCHリソースに関する情報などが含まれている。
【００７３】
また、抽出部２０５は、自装置に対してMTCカバレッジエンハンスメントモードが設定され、PDCCH信号がレピティション送信されている場合、複数のサブフレームに渡ってレピティション送信されたPDCCH信号に対して同相合成して、PDCCH信号を抽出する。同様に、抽出部２０５は、下りリンクデータ（PDSCH信号）がレピティション送信されている場合には、複数のサブフレームに渡ってレピティション送信されたPDSCH信号に対して同相合成して、下りリンクデータを抽出する。
【００７４】
報知信号受信部２０６は、抽出部２０５から受け取る報知信号から、システム帯域幅、又は、PUCCHリソースに関する情報などを得る。報知信号受信部２０６は、報知信号に符号化処理及び変調処理が施されている場合、復調処理及び復号処理を施す。報知信号受信部２０６は、得られた報知信号を判定部２０９又は制御部２１３へ出力する。
【００７５】
制御信号復調部２０７は、抽出部２０５から受け取るPDCCH信号を復調し、復調後のPDCCH信号を制御信号復号部２０８へ出力する。
【００７６】
制御信号復号部２０８は、制御信号復調部２０７から受け取るPDCCH信号を復号して、復号結果を判定部２０９に出力する。
【００７７】
判定部２０９は、制御信号復号部２０８から受け取る復号結果に含まれる制御情報が自端末宛ての制御情報であるか否かをブラインド判定する。例えば、判定部２０９は、自端末の端末IDによってCRCビットをデマスキングし、CRC＝OK（誤りなし）となる制御情報を、自端末宛ての制御情報であると判定する。そして、判定部２０９は、自装置宛の制御情報に含まれる下りデータ割当リソースに関する情報を抽出部２０５へ出力する。また、判定部２０９は、自装置宛の制御情報がマッピングされていたCCEを特定し、特定したCCEの識別情報を制御部２１３へ出力する。
【００７８】
データ復調部２１０は、抽出部２０５から受け取る下りリンクデータを復調し、復調後の下りリンクデータをデータ復号部２１１へ出力する。
【００７９】
データ復号部２１１は、データ復調部２１０から受け取る下りリンクデータを復号し、復号後の下りリンクデータをCRC部２１２へ出力する。
【００８０】
CRC部２１２は、データ復号部２１１から受け取る下りリンクデータに対して、CRCを用いて誤り検出を行い、誤り検出結果をACK/NACK生成部２１４へ出力する。また、CRC部２１２は、誤り検出の結果、誤りなしと判定した下りリンクデータを受信データとして出力する。
【００８１】
制御部２１３は、報知信号、PDCCH信号又は上位レイヤシグナリングによって基地局１００から端末２００に対して通知されたPUCCHリソースに関する情報、及び、レピティションレベルに関する情報を予め保持する。
【００８２】
制御部２１３は、PUCCHリソースに関する情報、及び、判定部２０９から受け取るCCEの識別情報を用いて、CCEの識別情報に示されるCCEに対応するPUCCHリソース（周波数、及び、１次拡散／２次拡散に用いる符号）を特定する。すなわち、制御部２１３は、CCEの識別情報に基づいて上り制御チャネルのPUCCHリソースを特定する。
【００８３】
具体的には、制御部２１３は、使用すべきPUCCHリソースに対応するZAC系列を生成すると共に、設定された巡回シフト量に基づいて、使用すべき巡回シフト量を決定し、１次拡散部２１６へ出力する。また、制御部２１３は、使用すべきPUCCHリソースに対応する直交符号系列を２次拡散部２１７へ出力する。また、制御部２１３は、使用すべきPUCCHリソースに対応する周波数リソース（サブキャリア）をIFFT部２１８へ出力する。
【００８４】
また、制御部２１３は、自端末がMTCカバレッジエンハンスメントモードである場合、PUCCHのレピティションレベルに関する情報をACK/NACK生成部２１４へ出力する。
【００８５】
ACK/NACK生成部２１４は、CRC部２１２から受け取る誤り検出結果に基づいてACK/NACK信号を生成する。具体的には、ACK/NACK生成部２１４は、誤りが検出された場合にはNACKを生成し、誤りが検出されない場合にはACKを生成する。ACK/NACK生成部２１４は、生成したACK/NACK信号を変調部２１５へ出力する。また、ACK/NACK生成部２１４は、自端末がMTCカバレッジエンハンスメントモードである場合、制御部２１３から受け取るレピティションレベルに関する情報に従って、レピティション信号を送信する。すなわち、PUCCHのレピティションレベルが１より大きい場合には、ACK/NACK生成部２１４は、レピティションレベルに対応した連続する複数のサブフレームに渡って、同一のACK/NACK信号を変調部２１５へ出力する。
【００８６】
変調部２１５は、ACK/NACK生成部２１４から受け取るACK/NACK信号を変調して、変調後のACK/NACK信号を１次拡散部２１６へ出力する。
【００８７】
１次拡散部２１６は、制御部２１３によって設定されたZAC系列及び巡回シフト量を用いて、参照信号、及び、変調部２１５から受け取るACK/NACK信号を１次拡散し、１次拡散後のACK/NACK信号及び参照信号を２次拡散部２１７へ出力する。
【００８８】
２次拡散部２１７は、制御部２１３によって設定された直交符号系列を用いてACK/NACK信号及び参照信号を２次拡散し、２次拡散後の信号をIFFT部２１８へ出力する。
【００８９】
IFFT部２１８は、制御部２１３によって設定された周波数リソースを用いて、２次拡散部２１７から受け取るACK/NACK信号及び参照信号に対してサブキャリアへのマッピング、及び、IFFT処理を行うことにより時間領域信号を生成する。IFFT部２１８は、生成した信号をCP付加部２１９へ出力する。
【００９０】
CP付加部２１９は、IFFT部２１８から受け取る信号に対してCPを付加し、CP付加後の信号を送信部２２０へ出力する。
【００９１】
送信部２２０は、CP付加部２１９から受け取る信号に対してD/A変換、アップコンバート等のRF処理を行い、アンテナ２０１を介して基地局１００に無線信号を送信する。
【００９２】
［基地局１００及び端末２００の動作］
以上の構成を有する基地局１００及び端末２００の動作について説明する。
【００９３】
以下では、通常モードの端末と、MTCカバレッジエンハンスメントモードの端末とが基地局１００のセル内に共存する場合について説明する。
【００９４】
本実施の形態に係る基地局１００は、各端末２００に対して、PUCCHリソースに関する情報を予め通知する。PUCCHリソースに関する情報は、例えば、CCE番号からPUCCH番号を特定する際に使用されるオフセット値、及び、各PUCCH領域に配置される１リソースブロック（RB：Resource Block）あたりに符号多重されるPUCCHリソースの最大数に関する情報である。
【００９５】
本実施の形態では、通常モードの端末及びMTCカバレッジエンハンスメントモードの端末に対して上記オフセット値が独立に設定される。
【００９６】
具体的には、通常モードの端末は、下りリンク割当制御情報（PDCCH又はEPDCCH）を受信した場合、対応する割当制御情報に示される下りリンクデータ（PDSCH）に対するACK/NACK信号を送信するPUCCHリソースのリソース番号nPUCCHを次式に従って決定する。
nPUCCH=nCCE+NPUCCH(1)                                          （１）
【００９７】
式（１）において、nCCEは、PDCCHが占有するCCE番号（０以上の整数）を示す。具体的には、PDCCHが１つのCCEのみを占有していた場合には、nCCEは当該CCEの番号である。また、PUCCHが複数のCCEを占有していた場合には、nCCEは最小のCCEの番号である。
【００９８】
また、式（１）において、NPUCCH(1)は、CCE番号からPUCCHリソース番号を特定するためのオフセット値を示す。例えば、3GPP Release 11では、NPUCCH(1)は、SPS/SR（Semi-Persistent Scheduling/Scheduling Request）用リソース向けに確保されたPUCCHリソース数を示す。NPUCCH(1)は、例えば、セル内で共通（common）の値であって、基地局１００から端末２００へ報知信号又は上位レイヤシグナリングによって通知される。
【００９９】
通常モードの端末は、決定したPUCCHリソース番号nPUCCHに基づいて、実際に使用するOC index及び巡回シフト量を決定する。
【０１００】
一方、MTCカバレッジエンハンスメントモードの端末は、下りリンク割当制御情報（PDCCH又はEPDCCH）を受信した場合、対応する割当制御情報に示される下りリンクデータ（PDSCH）に対するACK/NACK信号を送信するPUCCHリソースのリソース番号nPUCCH_MTCを次式に従って決定する。
nPUCCH_MTC=nCCE+NPUCCH_MTC(1)                                          （２）
【０１０１】
式（２）において、NPUCCH_MTC(1)は、MTCカバレッジエンハンスメントモードの端末に対する、CCE番号からPUCCHリソース番号を特定するためのオフセット値を示す。すなわち、MTCカバレッジエンハンスメントモードの端末に対して、通常モードの端末のオフセットNPUCCH(1)とは異なる独立のオフセット値NPUCCH_MTC(1)が設定される。NPUCCH_MTC(1)は、例えば、端末２００に依存する個別（UE specific）の値であってもよく、MTCカバレッジエンハンスメントモードの端末に共通の値でもよい。
【０１０２】
MTCカバレッジエンハンスメントモードの端末は、決定したPUCCHリソース番号nPUCCH_MTCに基づいて、実際に使用するOC index及び巡回シフト量を決定する。
【０１０３】
図１０は、通常モードの端末及びMTCカバレッジエンハンスメントモードの端末に対するPUCCHリソースの一例を示す。
【０１０４】
図１０では、図３と同様、１RB（PRB（Physical RB））毎に最大３６個のPUCCHリソースのうち、１８個のPUCCHリソースが利用可能である。図１０では、３個のRBに渡って、利用可能な５４個のPUCCHリソースに対してPUCCHリソース番号（#0〜#53）がそれぞれ付されている。
【０１０５】
図１０では、通常モードの端末に対するオフセット値NPUCCH(1)＝６であり、MTCカバレッジエンハンスメントモードの端末に対するオフセット値NPUCCH_MTC(1)＝３０である。
【０１０６】
すなわち、通常モードの端末は、PUCCHリソース番号nPUCCH=nCCE+６のPUCCHリソースを用いてACK/NACK信号を送信する。一方、MTCカバレッジエンハンスメントモードの端末は、PUCCHリソース番号nPUCCH_MTC=nCCE+３０のPUCCHリソースを用いてACK/NACK信号を送信する。
【０１０７】
つまり、端末２００は、自端末が通常モードの端末である場合には、通常モードの端末用のPUCCHリソース群の中のPUCCHリソースを用いてACK/NACK信号を送信し、自端末が、MTCカバレッジエンハンスメントモードの端末である場合には、通常モードの端末用のPUCCHリソース群とは異なるMTCカバレッジエンハンスメントモードの端末用のPUCCHリソース群の中のPUCCHリソースを用いてACK/NACK信号を送信する。
【０１０８】
また、同様にして、基地局１００は、通常モードの端末から送信されるACK/NACK信号を、通常モードの端末用のPUCCHリソース群の中のリソースを用いて受信し、MTCカバレッジエンハンスメントモードの端末から送信されるACK/NACK信号を、通常モードの端末用のPUCCHリソース群とは異なるMTCカバレッジエンハンスメントモードの端末用のPUCCHリソース群の中のリソースを用いて受信する。
【０１０９】
これにより、図１０に示すように、PDCCH信号、PDSCH信号及びACK/NACK信号に対してレピティション送信が適用されるMTCカバレッジエンハンスメントモードの端末がACK/NACK信号の送信に使用可能なPUCCHリソース群と、レピティション送信が適用されない通常モードの端末がACK/NACK信号の送信に使用可能なPUCCHリソース群とは異なる。すなわち、通常モードの端末とMTCカバレッジエンハンスメントモードの端末との間において、CCE番号からPUCCHリソース番号を特定するためのオフセット値を異ならせることにより、双方の端末に対するPUCCHリソース領域が分割される。
【０１１０】
なお、図１０では、各モードの端末２００に対して使用可能なCCE数を２４個とする場合について示している。ただし、各モードの端末２００に対して使用可能なCCE数は２４個に限らず、他の値でもよく、使用可能なCCE数に応じて、各モードの端末２００に対するPUCCHリソース領域が分割されるように、オフセット値NPUCCH(1)及びNPUCCH_MTC(1)が設定されればよい。
【０１１１】
ここで、一例として、図５に示すように、同一サブフレームにおいて送信されるACK/NACK信号に使用されるPUCCHリソースに対応するCCE番号がCCE#0である場合（つまり、nCCE＝０）について説明する。
【０１１２】
この場合、通常モードの端末は、式（１）に従って、PUCCHリソース番号nPUCCH＝６（＝０＋６）のPUCCHリソースを用いる。
【０１１３】
一方、MTCカバレッジエンハンスメントモードの端末は、式（２）に従って、PUCCHリソース番号nPUCCH_MTC＝３０（＝０＋３０）のPUCCHリソースを用いる。
【０１１４】
すなわち、端末２００（制御部２１３）は、自端末が通常モードの端末である場合には、PDCCHに使用されるCCEのインデックスnCCEにオフセット値NPUCCH(1)を加算して、実際にACK/NACK信号に使用されるPUCCHリソースを算出する。また、端末２００は、自端末がMTCカバレッジエンハンスメントモードの端末である場合には、PDCCHに使用されるCCEのインデックスnCCEにオフセット値NPUCCH_MTC(1)を加算して、実際にACK/NACK信号に使用されるPUCCHリソースを算出する。ただし、オフセット値NPUCCH(1)とオフセット値NPUCCH_MTC(1)とは異なる。
【０１１５】
よって、両方の端末が同一サブフレームにおいてACK/NACK信号を送信する場合に、通常モードの端末がACK/NACK信号を送信するPUCCHリソースに関連付けられたCCE番号と、MTCカバレッジエンハンスメントモードの端末がACK/NACK信号を送信するPUCCHリソースに関連付けられたCCE番号とが同一のCCE#0であっても、双方において使用されるPUCCHリソースは異なる。
【０１１６】
つまり、双方の端末が同一サブフレームにおいてACK/NACK信号を送信する場合に、対応するPDCCHに使用されたCCE番号（最小のインデックス）が同一であっても、通常モードの端末とMTCカバレッジエンハンスメントモードの端末との間においてPUCCHリソースの衝突を回避することができる。
【０１１７】
このように、本実施の形態によれば、通常モードの端末とMTCカバレッジエンハンスメントモードの端末とに対してそれぞれ異なるオフセット値を用いてPUCCHリソースを決定する。こうすることで、通常モードの端末が使用可能なPUCCHリソースと、MTCカバレッジエンハンスメントモードの端末が使用可能なPUCCHリソースと、が分離される。これにより、同一サブフレームにおいて送信されるACK/NACK信号に対応する下りリンクデータの割当に使用されたPDCCHが占有するCCEが同一であっても、ACK/NACK信号に使用されるPUCCHリソースを異ならせることができる。よって、ACK/NACK信号を送信するPUCCHリソースの衝突を回避できる。
【０１１８】
また、上述したように、通常モードの端末とMTCカバレッジエンハンスメントモードの端末との間においてPUCCHリソース番号を特定するためのオフセット値を異ならせることにより、PUCCHリソースの衝突を回避するので、PDCCHリソースの割当に関して何ら制限を追加する必要はない。このため、本実施の形態によれば、PDCCHリソースの利用効率の低下又はスケジューリングの複雑度が増加することはない。
【０１１９】
よって、本実施の形態によれば、PDCCHリソースの周波数利用効率の低下及びスケジューリングの複雑度の増加をさせることなく、通常モードの端末とMTCカバレッジエンハンスメントモードの端末との間のPUCCHリソースの衝突を回避することができる。
【０１２０】
さらに、通常モードの端末に対するPUCCHリソースの割当（例えば、式（１）を参照）はLTEシステムにおいて既に行われている。よって、本実施の形態では、MTCカバレッジエンハンスメントモードの端末に対するPUCCHリソースの割当時に独立して使用されるオフセット値NPUCCH_MTC(1)のみが基地局１００から端末２００へ新たに通知されればよい。よって、既存のシステムの動作に与える影響は少ない。
【０１２１】
（実施の形態２）
本実施の形態に係る基地局及び端末の基本構成は、実施の形態１と同様であるので、図８（基地局１００）と図９（端末２００）を援用して説明する。
【０１２２】
以下では、実施の形態１と同様、通常モードの端末と、MTCカバレッジエンハンスメントモードの端末とが基地局１００のセル内に共存する場合について説明する。
【０１２３】
本実施の形態に係る基地局１００は、各端末２００に対して、PUCCHリソースに関する情報を予め通知する。PUCCHリソースに関する情報は、例えば、CCE番号からPUCCH番号を特定する際に使用されるオフセット値、及び、各PUCCH領域に配置される１リソースブロック（RB：Resource Block）あたりに符号多重されるPUCCHリソースの最大数に関する情報である。
【０１２４】
本実施の形態では、通常モードの端末及びMTCカバレッジエンハンスメントモードの端末に対して上記オフセット値が共通に設定される。ただし、通常モードの端末と、MTCカバレッジエンハンスメントモードの端末とでは、CCE番号とPUCCHリソース番号との対応付けが異なる。
【０１２５】
具体的には、通常モードの端末は、実施の形態１と同様、ACK/NACK信号を送信するPUCCHリソースのリソース番号nPUCCHを式（１）に従って決定し、実際に使用するOC index及び巡回シフト量を決定する。
【０１２６】
一方、MTCカバレッジエンハンスメントモードの端末は、下りリンク割当制御情報（PDCCH又はEPDCCH）を受信した場合、対応する割当制御情報に示される下りリンクデータ（PDSCH）に対するACK/NACK信号を送信するPUCCHリソースのリソース番号nPUCCH_MTCを次式に従って決定する。
nPUCCH_MTC=NPUCCH(1)-1-nCCE                                          （３）
【０１２７】
式（３）において、NPUCCH(1)は、CCE番号からPUCCHリソース番号を特定するためのオフセット値であって、式（１）にも含まれる値である。すなわち、MTCカバレッジエンハンスメントモードの端末に対して、通常モードの端末のオフセットNPUCCH(1)と同一のオフセット値NPUCCH(1)が設定される。NPUCCH(1)は、例えば、基地局１００から端末２００へ報知信号又は上位レイヤシグナリングによって通知されてもよい。
【０１２８】
MTCカバレッジエンハンスメントモードの端末は、決定したPUCCHリソース番号nPUCCH_MTCに基づいて、実際に使用するOC index及び巡回シフト量を決定する。
【０１２９】
すなわち、端末２００（制御部２１３）は、自端末が通常モードの端末である場合には、PDCCHに使用されるCCEのインデックスnCCEにオフセット値NPUCCH(1)を加算して、実際にACK/NACK信号に使用されるPUCCHリソースを算出する。一方、端末２００は、自端末がMTCカバレッジエンハンスメントモードの端末である場合には、オフセット値NPUCCH_MTC(1)から、PDCCHに使用されるCCEのインデックスnCCEを減算して、実際にACK/NACK信号に使用されるPUCCHリソースを算出する。
【０１３０】
図１１は、通常モードの端末及びMTCカバレッジエンハンスメントモードの端末に対するPUCCHリソースの一例を示す。
【０１３１】
図１１では、図１０と同様、１RB毎に最大３６個のPUCCHリソースのうち、１８個のPUCCHリソースが利用可能である。図１１では、３個のRBに渡って、利用可能な５４個のPUCCHリソースに対してPUCCHリソース番号（#0〜#53）がそれぞれ付されている。
【０１３２】
また、図１１では、各端末２００に対するオフセット値NPUCCH(1)＝３０である。
【０１３３】
すなわち、通常モードの端末は、PUCCHリソース番号nPUCCH=nCCE+３０のPUCCHリソースを用いてACK/NACK信号を送信する。一方、MTCカバレッジエンハンスメントモードの端末は、PUCCHリソース番号nPUCCH_MTC=３０−１−nCCE（＝２９−nCCE）のPUCCHリソースを用いてACK/NACK信号を送信する。
【０１３４】
つまり、図１１に示すように、PUCCHリソース番号#29と#30との間を境界として、#30以上の番号のPUCCHリソースは通常モードの端末用PUCCHリソース領域に設定され、#29以下の番号のPUCCHリソースはMTCカバレッジエンハンスメントモードの端末用PUCCHリソース領域に設定される。
【０１３５】
これにより、図１１に示すように、通常モードの端末及びMTCカバレッジエンハンスメントモードの端末の各々に対して異なるPUCCHリソース領域が設定される。すなわち、通常モードの端末とMTCカバレッジエンハンスメントモードの端末との間において、CCE番号からPUCCHリソース番号を特定するための対応付け（式（１）及び式（３））を異ならせることにより、双方の端末に対するPUCCHリソース領域が分割される。
【０１３６】
ここで、一例として、図５に示すように、同一サブフレームにおいて送信されるACK/NACK信号に使用されるPUCCHリソースに対応するCCE番号がCCE#0である場合（つまり、nCCE＝０）について説明する。
【０１３７】
この場合、通常モードの端末は、式（１）に従って、PUCCHリソース番号nPUCCH＝３０（＝０＋３０）のPUCCHリソースを用いる。
【０１３８】
一方、MTCカバレッジエンハンスメントモードの端末は、式（３）に従って、PUCCHリソース番号nPUCCH_MTC＝２９（＝２９−０）のPUCCHリソースを用いる。
【０１３９】
つまり、両方の端末が同一サブフレームにおいてACK/NACK信号を送信する場合に、通常モードの端末がACK/NACK信号を送信するPUCCHリソースに関連付けられたCCE番号と、MTCカバレッジエンハンスメントモードの端末がACK/NACK信号を送信するPUCCHリソースに関連付けられたCCE番号とが同一のCCE#0であっても、双方において使用されるPUCCHリソースは異なる。
【０１４０】
つまり、双方の端末が同一サブフレームにおいてACK/NACK信号を送信する場合に、対応するPDCCHに使用されたCCE番号（最小のインデックス）が同一であっても、通常モードの端末とMTCカバレッジエンハンスメントモードの端末との間においてPUCCHリソースの衝突を回避することができる。
【０１４１】
このように、本実施の形態によれば、通常モードの端末とMTCカバレッジエンハンスメントモードの端末とに対して、それぞれ異なるCCEとの対応付けを用いてPUCCHリソースを決定する。こうすることで、通常モードの端末が使用可能なPUCCHリソースと、MTCカバレッジエンハンスメントモードの端末が使用可能なPUCCHリソースと、が分離される。これにより、同一サブフレームにおいて送信されるACK/NACK信号に対応する下りリンクデータの割当に使用されたPDCCHが占有するCCEが同一であっても、ACK/NACK信号に使用されるPUCCHリソースを異ならせることができる。よって、ACK/NACK信号を送信するPUCCHリソースの衝突を回避できる。
【０１４２】
また、上述したように、通常モードの端末とMTCカバレッジエンハンスメントモードの端末との間においてPUCCHリソース番号を特定するための対応付けを異ならせることにより、PUCCHリソースの衝突を回避するので、PDCCHリソースの割当に関して何ら制限を追加する必要はない。このため、本実施の形態によれば、PDCCHリソースの利用効率の低下又はスケジューリングの複雑度が増加することはない。
【０１４３】
よって、本実施の形態によれば、PDCCHリソースの周波数利用効率の低下及びスケジューリングの複雑度の増加をさせることなく、通常モードの端末とMTCカバレッジエンハンスメントモードの端末との間のPUCCHリソースの衝突を回避することができる。
【０１４４】
さらに、通常モードの端末に対するPUCCHリソースの割当（例えば、式（１）を参照）はLTEシステムにおいて既に行われている。また、MTCカバレッジエンハンスメントモードの端末に対するPUCCHリソースの割当時にも、通常モードの端末と同一のパラメータ（オフセット値NPUCCH(1)）が用いられる。よって、MTCカバレッジエンハンスメントモードの端末に対して新たに追加すべきパラメータはない。よって、既存のシステムの動作に影響を与えない。
【０１４５】
なお、CCE番号からPUCCHリソース番号を特定する対応付けを、通常モードとMTCカバレッジエンハンスメントモードとで逆にしてもよい。つまり、通常モードの端末が式（３）を用いてPUCCHリソース番号を決定し、MTCカバレッジエンハンスメントモードの端末が式（１）を用いてPUCCHリソース番号を決定してもよい。MTCでは端末はそれほど頻繁に通信を行わないことが想定されることから、MTCカバレッジエンハンスメントモードの端末のPUCCH領域の使用頻度は少ないことが想定される。また、上りリンクでは、システム帯域の中心にPUSCH領域（Physical Downlink Shared Channel）が配置され、両端にPUCCH領域が配置され、PUCCHリソース（例えば、図１１を参照）には上記PUCCH領域の外側から内側へ向かってPUCCHリソース番号が昇順に付されている。よって、式（１）によって対応付けられた、使用頻度が少ないMTCカバレッジエンハンスメントモードの端末のPUCCH領域は、上りリンクの内側の周波数帯域に配置されるので、上りリンクデータ用の周波数帯域と連続させることができる。このようにすることで、MTCカバレッジエンハンスメントモードの端末がPUCCHリソースを使用していない場合に、そのリソースを上りリンクデータ(PUSCH)に用いることができる。また、MTCカバレッジエンハンスメントモードの端末のPUCCH領域がPUSCH領域と連続していることで、連続する複数のサブキャリアをまとめて特定の端末に割り当てて、ピーク対送信電力比(PAPR: Peak-to-Average Power Ratio)の増加を抑えることができる。
【０１４６】
（実施の形態３）
本実施の形態に係る基地局及び端末の基本構成は、実施の形態１と同様であるので、図８（基地局１００）と図９（端末２００）を援用して説明する。
【０１４７】
以下では、通常モードの端末と、MTCカバレッジエンハンスメントモードの端末とが基地局１００のセル内に共存する場合について説明する。
【０１４８】
本実施の形態に係る基地局１００は、各端末２００に対して、PUCCHリソースに関する情報を予め通知する。PUCCHリソースに関する情報は、例えば、PUCCHリソース（例えば、図３を参照）の１直交系列において隣接する利用可能なPUCCHリソース間の巡回シフト量の差、及び、各PUCCH領域に配置される１RBあたりに符号多重されるPUCCHリソースの最大数に関する情報を含む。
【０１４９】
また、通常モードの端末及びMTCカバレッジエンハンスメントモードの端末の各々に対して異なるPUCCHリソース領域が設定される。以下の説明では、MTCカバレッジエンハンスメントモードの端末に対するPUCCHリソースの割当として、CCE番号に対応付けてImplicitに通知する場合について説明する。例えば、通常モードの端末及びMTCカバレッジエンハンスメントモードの端末に対するPUCCHリソースは、実施の形態１又は実施の形態２と同様の方法により設定されてもよい。ただし、本実施の形態では、MTCカバレッジエンハンスメントモードの端末に対するPUCCHリソースの割当として、上位レイヤシグナリングなどを用いて、基地局１００から端末２００へExplicitに通知されてもよい。
【０１５０】
本実施の形態では、通常モードの端末及びMTCカバレッジエンハンスメントモードの端末に対して上記巡回シフト量の差が独立に設定される。
【０１５１】
図１２は、本実施の形態に係る、通常モードの端末及びMTCカバレッジエンハンスメントモードの端末に対するPUCCHリソースの一例を示す。図１２では、２個のRBの合計７２個のPUCCHリソースのうち、１２個のPUCCHリソースはSPS/SR用に確保され、４８個のPUCCHリソースは通常モードの端末に対して確保され、残りの１２個のPUCCHリソースはMTCカバレッジエンハンスメントモードの端末に対して確保されている。
【０１５２】
上述したように、図１２に示すPUCCHリソースは、直交符号系列（OC index）とZAC系列の巡回シフト量（Cyclic shift Index）との組合せによって定義される。
【０１５３】
通常モードの端末には、PUCCHリソースを定義する１直交符号系列において隣接する利用可能なリソース間の巡回シフト量の差ΔshiftPUCCHが設定される。例えば、図１２では、ΔshiftPUCCH＝２が設定されている。すなわち、１つの直交符号系列に対して採りうる１２個の巡回シフト量（Cyclic Shift Index=0〜11）について１個おきの巡回シフト量に対応するPUCCHリソースが利用可能となる。よって、通常モードの端末に対しては、１RB（PRB（Physical RB））毎に最大３６個のPUCCHリソースのうち、１８個のPUCCHリソースが利用可能となる。
【０１５４】
図１２では、通常モードの端末は、下りリンク割当制御情報を受信した場合、対応する割当制御情報に示される下りリンクデータに対するACK/NACK信号を送信するPUCCHリソースのリソース番号nPUCCHを式（１）に従って決定してもよい（ただし、NPUCCH(1)＝６）。
【０１５５】
図１２では、PUCCHリソース#0を始点として、各直交符号系列において１個おきの巡回シフト量に対応するリソースに対して番号が付与されたPUCCHリソースのうち、PUCCHリソース番号#6〜#29の２４個のPUCCHリソースが通常モードの端末が利用可能なPUCCHリソースとなる。
【０１５６】
一方、MTCカバレッジエンハンスメントモードの端末には、PUCCHリソースを定義する１直交符号系列において隣接する利用可能なリソース間の巡回シフト量の差ΔshiftPUCCH_MTCが設定される。例えば、図１２では、ΔshiftPUCCH_MTC＝１が設定されている。すなわち、利用可能なPUCCHリソース間の巡回シフト量の差として、通常モードの端末とMTCカバレッジエンハンスメントモードの端末とでは互いに異なるパラメータが設定されている。具体的には、ΔshiftPUCCH_MTCは、ΔshiftPUCCHよりも小さい。
【０１５７】
すなわち、MTCカバレッジエンハンスメントモードの端末では、１つの直交符号系列に対して採りうる１２個の巡回シフト量（Cyclic Shift Index=0〜11）について連続する全ての巡回シフト量に対応するPUCCHリソースが利用可能となる。
【０１５８】
図１２では、MTCカバレッジエンハンスメントモードの端末は、下りリンク割当制御情報を受信した場合、対応する割当制御情報に示される下りリンクデータに対するACK/NACK信号を送信するPUCCHリソースのリソース番号nPUCCH_MTCを式（２）に従って決定してもよい（ただし、NPUCCH_MTC(1)＝６０）。
【０１５９】
図１２では、PUCCHリソース#0を始点として、各直交符号系列において連続する巡回シフト量に対応するリソースに対して番号が付与されたPUCCHリソースのうち、PUCCHリソース番号#60〜#71の１２個のPUCCHリソースがMTCカバレッジエンハンスメントモードの端末が利用可能なPUCCHリソースとなる。
【０１６０】
なお、端末２００は、PUCCHリソース番号に基づいて、実際に使用するOC index及び巡回シフト量を決定する。PUCCHリソース番号と、OC index及び巡回シフト量と、の対応付けは、隣接する巡回シフト量の差に依存する。したがって、本実施の形態では、PUCCHリソース番号から実際に使用するOC index及び巡回シフト量を特定する対応付けが、通常モードの端末とMTCカバレッジエンハンスメントモードの端末とで異なる。具体的には、MTCカバレッジエンハンスメントモードの端末は、既存のシステムにおけるPUCCHリソース番号から実際に使用するOC index及び巡回シフト量を特定する対応付けを示す数式（示さず）におけるΔshiftPUCCHをΔshiftPUCCH_MTCに置き換えて動作すればよい。
【０１６１】
既存のシステム（例えば、3GPP Release 11）では、上述した通常モードの端末に対するPUCCHリソースは確保されていた。これに対して、図１２に示すように、MTCカバレッジエンハンスメントモードの端末が存在する場合、通常モードの端末用のPUCCHリソースに加えて、MTCカバレッジエンハンスメントモードの端末用のPUCCHリソースが追加的に設定される。
【０１６２】
ここで、図１２に示すように、各RB内での最大符号多重可能数は、採りうる巡回シフト量のうちの利用可能な巡回シフト量の数により特定される。具体的には、最大符号多重可能数は、PUCCHリソースとして巡回シフト量をいくつおきに利用可能か（つまり、ΔshiftPUCCH及びΔshiftPUCCH_MTC）によって特定される。
【０１６３】
本実施の形態では、通常モードの端末及びMTCカバレッジエンハンスメントモードの端末の各々に対して最大符号多重可能数（巡回シフト量の差）が独立に設定される。具体的には、MTCカバレッジエンハンスメントモードの端末用のPUCCHリソース群の各リソースとして定義された、直交符号系列と巡回シフト量との組合せのうち、同一直交符号系列において隣接する巡回シフト量の差ΔshiftPUCCH_MTCは、通常モードの端末用のPUCCHリソース群の各リソースとして定義された、直交符号系列と巡回シフト量との組合せのうち、同一直交符号系列において隣接する巡回シフト量の差ΔshiftPUCCHよりも小さい。
【０１６４】
このため、MTCカバレッジエンハンスメントモードの端末用のPUCCHリソース領域では、通常モードの端末用のPUCCHリソース領域と比較して、各PUCCHリソース領域全体に対する利用可能なPUCCHリソースの割合が高くなる。具体的には、図１２に示すように、通常モードの端末用PUCCHリソース領域では、４８個のPUCCHリソースのうち、２４個のPUCCHリソースが利用可能となる。これに対して、MTCカバレッジエンハンスメントモードの端末用PUCCHリソース領域では、１２個のPUCCHリソースの全てが利用可能となる。すなわち、MTCカバレッジエンハンスメントモードの端末に対して最大符号多重可能数が最大限となる。
【０１６５】
つまり、本実施の形態では、上述したようにMTCカバレッジエンハンスメントモードの端末用のPUCCHリソースにおける最大符号多重可能数を、通常モードの端末用PUCCHリソースにおける最大符号多重可能数よりも多くすることにより、利用可能なPUCCHリソース数を多くして、PUCCHリソースのオーバーヘッドを最小限に抑えることができる。
【０１６６】
例えば、１２個のPUCCHリソースを利用可能とするためには、ΔshiftPUCCH_MTC＝２の場合には２４個のPUCCHリソースを確保する必要があるのに対して、ΔshiftPUCCH_MTC＝１の場合には図１２に示すように１２個のPUCCHリソースを確保するだけで済む。よって、ΔshiftPUCCH_MTCをΔshiftPUCCHよりも小さくすることにより、通常モードの端末に設定される巡回シフト量の差ΔshiftPUCCHと同一とする場合と比較して、PUCCHリソースのオーバーヘッドを最小限に抑えることができる。
【０１６７】
ところで、同一RB内のPUCCHリソースにおいて、符号多重に用いられなかったPUCCHリソースは、符号拡散による符号間干渉低減効果により符号間干渉の低減に寄与する。例えば、図１２に示すように、通常モードの端末用PUCCHリソースでは、利用可能なPUCCHリソース#6〜#29の隣接するリソースの間に利用されないPUCCHリソース（符号多重に用いられないPUCCHリソース）が存在し、当該PUCCHリソースが符号間干渉の低減に寄与する。
【０１６８】
これに対して、図１２に示すように、MTCカバレッジエンハンスメントモードの端末用PUCCHリソースでは、符号多重に用いられないPUCCHリソースは存在しない。
【０１６９】
しかし、MTCでのトラフィック特性を考慮すると、MTCでの端末は頻繁に通信を行わないことが想定される。すなわち、MTCカバレッジエンハンスメントモードの端末用PUCCHリソースの使用頻度は確率的に低くなる。よって、MTCカバレッジエンハンスメントモードの端末用PUCCHリソースにおいて、同一RB内の最大符号多重可能数を増加させたとしても、同時に符号多重される端末数が少ないので、同一系列の隣接する巡回シフト量に対応するリソースが同時に使用される可能性は低くなる。すなわち、隣接する巡回シフト量に対応するリソースが同時に使用されることによる符号間干渉の発生の可能性が低いので、ACK/NACK信号の伝送特性の劣化は生じにくい。
【０１７０】
また、MTCでの通信環境を考慮すると、MTCカバレッジエンハンスメントモードの端末に対する制御情報の符号化率が低く設定され、PDCCHを構成するL1/L2 CCHのCCEの占有数が比較的多くなることが想定される。このため、例えば、上述したように、MTCカバレッジエンハンスメントモードの端末に対して、CCE番号によりPUCCHリソース番号がImplicitに通知される場合、番号が隣接するCCEは同一の端末に使用される可能性が高くなる。よって、番号が隣接するPUCCHリソース（隣接する巡回シフト量に対応するリソース）が同時に使用される可能性は低くなる。
【０１７１】
このように、MTCカバレッジエンハンスメントモードの端末に対して、隣接する巡回シフト量の差を通常モードの場合と比較して小さく設定しても、同一RB内の最大符号多重可能数を増加させたPUCCHリソース領域での実際の使用確率が低いため、最大符号多重可能数を増加させたことに起因するACK/NACK信号の性能劣化は実質的に発生しない。
【０１７２】
このようにして、本実施の形態によれば、通常モードの端末とMTCカバレッジエンハンスメントモードの端末とに対してそれぞれ異なる、巡回シフト量の差（つまり、最大符号多重可能数）を用いてPUCCHリソースが設定される。これにより、通常モードの端末とMTCカバレッジエンハンスメントモードの端末とが共存するシステムにおいて、PUCCHリソースのオーバーヘッドの増加を最小限に抑えることができる。
【０１７３】
さらに、通常モードの端末に対するPUCCHリソースの割当はLTEシステムにおいて既に行われている。よって、本実施の形態では、MTCカバレッジエンハンスメントモードの端末に対するPUCCHリソースの割当時に独立して使用される巡回シフト量の差ΔshiftPUCCH_MTCが基地局１００から端末２００へ新たに通知されればよい。よって、既存のシステムの動作に与える影響は少ない。
【０１７４】
また、本実施の形態によれば、通常モードの端末とMTCカバレッジエンハンスメントモードの端末とに対してACK/NACK信号に使用されるPUCCHリソースを異ならせることにより、ACK/NACK信号を送信するPUCCHリソースの衝突を回避できる。
【０１７５】
なお、本実施の形態は、通常モードの端末(レピティションを行わない端末)とMTCカバレッジエンハンスメントモードの端末(レピティションを行う端末)とに対して、それぞれ異なる、巡回シフト量の差（つまり、最大符号多重可能数）を用いてPUCCHリソースが設定される場合について説明した。しかし、本実施の形態では、それに限らず同一セル内の端末グループ毎(例えば、同一セル内のマクロ基地局配下の端末とリモートアンテナ局配下の端末など)にそれぞれ異なる、巡回シフト量の差（つまり、最大符号多重可能数）を用いてPUCCHリソースが設定されてもよい。
【０１７６】
（実施の形態４）
前述したように、既存システムでは、CCE番号とPUCCHリソース番号とは１対１に対応付けられている。つまり、Ｍ個のCCEに対して、CCE数と同数のＭ個のPUCCHリソースがそれぞれ対応付けられている。例えば、図１２では、MTCカバレッジエンハンスメントモードの端末に対して、CCE#0とPUCCH#60、CCE#1とPUCCH#61、CCE#2とPUCCH#62、…がそれぞれ対応付けられている。
【０１７７】
また、MTCカバレッジエンハンスメントモードの端末に対して、制御情報の誤り率特性の劣化を抑えるために、制御情報の符号化率が低く設定されることが想定される。つまり、MTCカバレッジエンハンスメントモードの端末に対するPDCCHを構成するL1/L2 CCHのCCEの占有数は比較的多くなることが想定される。例えば、MTCカバレッジエンハンスメントモードの端末に対して、CCEの占有数（アグリゲーションレベルと呼ぶこともある）として採りうる値（例えば、１，２，４，８）のうち、より大きい値（４，８）が設定されることが想定される。
【０１７８】
前述したように、MTCカバレッジエンハンスメントモードの端末に対するPDCCHにおいてL1/L2 CCHが複数のCCEを占有する場合、端末は、複数のCCEのうち、１つのCCE（最小のインデックスのCCE）に対応するPUCCHリソースを用いてACK/NACK信号を送信する。よって、ACK/NACK信号の送信に使用されるPUCCHリソースに対応するCCE以外の他のCCEに対応するPUCCHリソースは使用されずに無駄となる。例えば、図１２では、MTCカバレッジエンハンスメントモードの端末に対するPDCCHを構成するL1/L2 CCHがCCE#0〜CCE#3の４つのCCEを占有する場合、当該端末は、４つのCCEのうち最小インデックスのCCE#0に対応するPUCCH#60のみを用いてACK/NACK信号を送信する。つまり、CCE#1〜CCE#3に対応するPUCCH#61〜PUCCH#63の物理リソースは使用されず無駄となる。
【０１７９】
また、MTCでのトラフィック特性を考慮すると、MTCでの端末は頻繁に通信を行わないことが想定される。すなわち、MTCカバレッジエンハンスメントモードの端末用PUCCHリソースの使用頻度は確率的に低い。
【０１８０】
そこで、本実施の形態では、MTCカバレッジエンハンスメントモードの端末に対して、M個のCCEに対してM個のPUCCHリソースを１対１で対応付けるのではなく、M個のCCEに対して、M個より少ないPUCCHリソースを対応付ける。換言すると、MTCカバレッジエンハンスメントモードの端末に対して、１個のPUCCHリソースに対して複数のCCEを関連付ける。
【０１８１】
本実施の形態に係る基地局及び端末の基本構成は、実施の形態１と同様であるので、図８（基地局１００）と図９（端末２００）を援用して説明する。
【０１８２】
基地局１００及び端末２００は、本実施の形態に係るCCEとPUCCHリソースとの対応付けを予め保持する。
【０１８３】
以下、本実施の形態に係るCCEとPUCCHリソースとの対応付けに関する方法１及び方法２についてそれぞれ説明する。
【０１８４】
なお、本実施の形態では、例えば、図１２に示すように、通常モードの端末及びMTCカバレッジエンハンスメントモードの端末の各々に対して異なるPUCCHリソース領域が設定される。例えば、通常モードの端末及びMTCカバレッジエンハンスメントモードの端末に対するPUCCHリソースは、実施の形態１又は実施の形態２と同様の方法により設定されてもよい。ただし、本実施の形態では、MTCカバレッジエンハンスメントモードの端末に対するPUCCHリソースの割当として、上位レイヤシグナリングなどを用いて、基地局１００から端末２００へExplicitに通知されてもよい。また、MTCカバレッジエンハンスメントモードの端末が利用可能なPUCCHリソース間の巡回シフト量の差は、実施の形態３と同様１とする（ΔshiftPUCCH_MTC=1）。
【０１８５】
以下では、MTCカバレッジエンハンスメントモードの端末用のPUCCHリソース（#60〜#71）に着目する。
【０１８６】
＜方法１（図１３）＞
方法１は、CCE番号とPUCCHリソースとの対応付けをＮ対１とする方法である。
【０１８７】
例えば、図１３は、Ｎ＝４とした場合のCCE番号とPUCCHリソース番号との対応付けの一例を示す。
【０１８８】
図１３に示すように、CCE#0〜CCE#3の４個のCCEは、PUCCH#60に対応付けられ、CCE#4〜CCE#7の４個のCCEは、PUCCH#61に対応付けられ、CCE#8〜CCE#11の４個のCCEは、PUCCH#62に対応付けられている。
【０１８９】
例えば、MTCカバレッジエンハンスメントモードの端末は、自端末宛てのPDCCHを構成するL1/L2 CCHを占有するCCEのうち、最も小さいインデックスのCCEがCCE#0〜CCE#3のいずれかである場合、PUCCHリソース#60を用いてACK/NACK信号を送信する。同様に、MTCカバレッジエンハンスメントモードの端末に対して割り当てられるCCEのうち最も小さいインデックスのCCEが、CCE#4〜CCE#7の場合にはACK/NACK信号の送信にPUCCHリソース#61が使用され、CCE#8〜CCE#11の場合にはACK/NACK信号の送信にPUCCHリソース#62が使用される。
【０１９０】
例えば、MTCカバレッジエンハンスメントモードの端末が使用するPUCCHリソース番号nPUCCH_MTCは次式に従って決定される。
nPUCCH_MTC=floor(nCCE/N)+NPUCCH_MTC(1)                            （４）
【０１９１】
式（４）において、関数「floor(X)」は、X以下の最大の整数を返す床関数を表す。また、nCCEは、PDCCHが占有するCCEのうち最も小さいCCEの番号を示し、Nは、１つのPUCCHリソースに対応付けられるCCE数（図１３ではN=4）を示す。また、NPUCCH_MTC(1)は、MTCカバレッジエンハスメントモードの端末に対するオフセット値を示す。例えば、図１３では、NPUCCH_MTC(1)=60である。
【０１９２】
方法１によれば、MTCカバレッジエンハスメントモードの端末用に確保するPUCCHリソース領域は、CCE番号とPUCCH番号とを１対１で対応付ける場合と比較して、1/Nに削減される。具体的には、CCE番号とPUCCH番号とを１対１で対応付ける場合には、１２個のCCEに対して１２個のPUCCHリソースを確保する必要があったのに対して、方法１では、図１３の場合（N=4の場合）、１２個のCCEに対して３個のPUCCHリソースのみを確保すればよい。
【０１９３】
＜方法２＞
方法２は、１つのPUCCHリソースに対応付けられるCCE数を、CCEの占有数（アグリゲーションレベル）として採りうる値とする方法である。
【０１９４】
例えば、方法２では、MTCカバレッジエンハンスメントモードの端末に対してCCE占有数Ｎ（＞１）が設定されるとする。
【０１９５】
例えば、図１４は、Ｎ＝４とした場合のCCE番号とPUCCHリソース番号との対応付けの一例を示す。
【０１９６】
図１４に示すように、CCE#0〜CCE#3の４個のCCEは、PUCCH#60に対応付けられ、CCE#4〜CCE#7の４個のCCEは、PUCCH#61に対応付けられ、CCE#8〜CCE#11の４個のCCEは、PUCCH#62に対応付けられている。つまり、CCE占有数Ｎ個のCCE毎に１つのPUCCHリソースが対応付けられる。
【０１９７】
MTCカバレッジエンハンスメントモードの端末には、図１４に示す４個のCCE単位でCCEが割り当てられる。例えば、MTCカバレッジエンハンスメントモードの端末は、自端末宛てのPDCCHを構成するL1/L2 CCHを占有するCCEがCCE#0〜CCE#3である場合、PUCCHリソース#60を用いてACK/NACK信号を送信する。同様に、MTCカバレッジエンハンスメントモードの端末に対して、CCE#4〜CCE#7が割り当てられる場合には、ACK/NACK信号の送信にPUCCHリソース#61が使用され、CCE#8〜CCE#11が割り当てられる場合には、ACK/NACK信号の送信にPUCCHリソース#62が使用される。
【０１９８】
例えば、MTCカバレッジエンハンスメントモードの端末が使用するPUCCHリソース番号nPUCCH_MTCは次式に従って決定される。
nPUCCH_MTC=nCCE/N+NPUCCH_MTC(1)                     （５）
【０１９９】
式（５）においてnCCEは、PDCCHが占有するCCEのうち最も小さいCCEの番号を示し、Nは、MTCカバレッジエンハンスメントモードの端末に対するCCE占有数（図１３ではN=4）を示す。また、NPUCCH_MTC(1)は、MTCカバレッジエンハスメントモードの端末に対するオフセット値を示す。例えば、図１４では、NPUCCH_MTC(1)=60である。
【０２００】
方法２によれば、MTCカバレッジエンハスメントモードの端末用に確保するPUCCHリソース領域は、CCE番号とPUCCH番号とを１対１で対応付ける場合と比較して、1/Nに削減される。具体的には、CCE番号とPUCCH番号とを１対１で対応付ける場合には、１２個のCCEに対して１２個のPUCCHリソースを確保する必要があったのに対して、方法２では、図１４の場合（N=4の場合）、１２個のCCEに対して３個のPUCCHリソースのみを確保すればよい。
【０２０１】
また、各PUCCHリソースは、各端末が占有するCCE数の単位でCCEに対応付けられているので、１つのPUCCHリソースに対応付けられたＮ個のCCEが複数の端末間で同時に使用されることはない。
【０２０２】
以上、方法１及び方法２について説明した。
【０２０３】
このように、本実施の形態では、MTCカバレッジエンハンスメントモードの端末に対して、複数のCCEを１個のPUCCHリソースに関連付ける。これにより、MTCカバレッジエンハンスメントモードの端末用のPUCCHリソースとして確保するリソースの増加を抑えることができる。よって、MTCカバレッジエンハンスメントモードの端末が存在するシステム（MTCカバレッジエンハンスメントモードの端末用のPUCCHリソースが追加的に設定される場合）でも、PUCCHリソースのオーバーヘッドの増加を抑えることができる。
【０２０４】
また、本実施の形態によれば、通常モードの端末とMTCカバレッジエンハンスメントモードの端末とに対してACK/NACK信号に使用されるPUCCHリソースを異ならせることにより、ACK/NACK信号を送信するPUCCHリソースの衝突を回避できる。
【０２０５】
（実施の形態５）
MTCカバレッジエンハンスメントモードの端末間において、既存のシステムと同様にしてCCE番号と対応付けてPUCCHリソース番号をImplicitに通知するのでは、PDCCH及びPUCCHのレピティションレベルが異なる端末が存在すると、同一PUCCHリソースを用いてACK/NACK信号が同時に送信され、PUCCHリソースの衝突が発生する場合がある。
【０２０６】
図１５は、MTCカバレッジエンハンスメントモードの端末間のPUCCHリソースが衝突する場合の一例を示す。図１５では、端末１（UE#1）及び端末２（UE#2）のPDCCH及びPDSCHのレピティションレベルをそれぞれNPDCCH、NPDSCHとする。また、端末１のPUCCHのレピティションレベルをNPUCCH+αPUCCHとし、端末２のPUCCHのレピティションレベルをNPUCCHとする。つまり、端末１では、端末２と比較して、NPDCCH、NPDSCHが同一であり、PUCCHのレピティションレベルがαPUCCHだけ大きい。
【０２０７】
また、図１５では、端末１がCCE#0からCCE#3を用いてPDCCHを送信する。一方、端末２は、端末１のPDCCHが送信完了した次のサブフレームから、CCE#0からCCE#3を用いてPDCCHを送信する。つまり、端末１及び端末２の双方は、CCE#0に対応付けられたPUCCHリソースを用いてACK/NACK信号を送信する。
【０２０８】
図１５に示すように、端末１は、NPUCCH+αPUCCHサブフレームに渡ってACK/NACK信号を送信し、端末２は、端末１がACK/NACK信号をNPUCCHサブフレーム送信した次のサブフレームからNPUCCHに渡ってACK/NACK信号を送信する。このため、図１５に示すように、端末１のPUCCHレピティション後半のαPUCCHサブフレーム、及び、端末２のPUCCHレピティション前半のαPUCCHサブフレームに相当するサブフレームにおいてPUCCHリソースが端末間で衝突してしまう。
【０２０９】
そこで、本実施の形態では、MTCカバレッジエンハンスメントモードの端末間のACK/NACK信号を送信するPUCCHリソースの衝突を回避する方法について説明する。
【０２１０】
本実施の形態に係る基地局及び端末の基本構成は、実施の形態１と同様であるので、図８（基地局１００）と図９（端末２００）を援用して説明する。
【０２１１】
具体的には、端末２００（MTCカバレッジエンハンスメントモードの端末）は、PDCCHとPUCCHとのレピティションレベルが異なる場合、PUCCHレピティションにおいて、PDCCHのレピティションレベルと同数のサブフレームまでは、CCE番号（つまり、最小のCCE番号）に対応付けてImplicitに通知されるPUCCHリソースを用いて、ACK/NACK信号を送信する。
【０２１２】
一方、端末２００は、PDCCHのレピティションレベルを超えるサブフレームでは、Explicitに割り当てられたPUCCHリソースを用いてACK/NACK信号を送信する。当該PUCCHリソースは、基地局１００から端末２００に対して予め通知される。
【０２１３】
図１６は、本実施の形態に係る各チャネルの送信タイミングを示す。図１６では、図１５と同様、端末１（UE#1）及び端末２（UE#2）のPDCCH及びPDSCHのレピティションレベルをそれぞれNPDCCH、NPDSCHとする。また、端末１のPUCCHのレピティションレベルをNPUCCH+αPUCCHとし、端末２のPUCCHのレピティションレベルをNPUCCHとする。また、図１６では、NPUCCHはNPDCCHと同一である。
【０２１４】
また、図１６では、端末１がCCE#0からCCE#3を用いてPDCCHを送信する。一方、端末２は、端末１のPDCCHが送信完了した次のサブフレームから、CCE#0からCCE#3を用いてPDCCHを送信する。
【０２１５】
この場合、図１６に示すように、端末１は、PUCCHレピティションにおいて、NPUCCH+αPUCCHサブフレームのうち、NPDCCHと同数のNPUCCHサブフレームまでは、PDCCHに使用されたCCEのうち最小のインデックスを有するCCE#0に対応付けられたPUCCHリソースを用いてACK/NACK信号を送信する。
【０２１６】
一方、端末１は、NPUCCH+αPUCCHサブフレームのうち、NPUCCHサブフレームを超えたαPUCCHサブフレーム以降では、Explicitに通知されたPUCCHリソースを用いてACK/NACK信号を送信する。
【０２１７】
また、図１６に示すように、端末２は、PUCCHレピティションにおいて、端末１がACK/NACK信号をNPUCCHサブフレーム送信した次のサブフレームからNPUCCHサブフレームに渡って、PDCCHに使用されたCCEのうち最小のインデックスを有するCCE#0に対応付けられたPUCCHリソースを用いてACK/NACK信号を送信する。
【０２１８】
つまり、図１６では、端末１のPUCCHレピティション後半のαPUCCHサブフレーム、及び、端末２のPUCCHレピティション前半のαPUCCHサブフレームに該当するサブフレームでは、端末１及び端末２の双方において互いに異なるPUCCHリソースが用いられる。よって、端末１と端末２との間でのPUCCHリソースの衝突は発生しない。
【０２１９】
このように、端末２００は、ACK/NACK信号のレピティション送信が行われる複数のサブフレームのうち、PDCCHのレピティションレベル以下のサブフレームでは、MTCカバレッジエンハンスメントモードの端末用のPUCCHリソースのうち、PDCCHに使用されるCCEに対応付けられたPUCCHリソースを用いて、ACK/NACK信号を送信し、PDCCHのレピティションレベルを超えるサブフレームでは、予め設定されたPUCCHリソースのいずれかを用いて、ACK/NACK信号を送信する。
【０２２０】
こうすることで，PDCCHとPUCCHのレピティションレベルが異なるMTCカバレッジエンハンスメントモードの端末が存在する場合に、同一のCCEを用いてPDCCHを送信したMTCカバレッジエンハンスメントモードの端末間においてACK/NACK信号を同時に送信するサブフレームが発生しても、ACK/NACK信号を送信するPUCCHリソースが端末間で衝突することを回避することができる。
【０２２１】
なお、本実施の形態は、実施の形態１〜４の動作と組み合わせてもよい。つまり、MTCカバレッジエンハンスメントモードの端末同士のPUCCHリソースの衝突を回避する方法について本実施の形態を適用し、MTCカバレッジエンハンスメントモードの端末と通常モードの端末との間のPUCCHリソースの衝突を回避する方法について、実施の形態１〜４のいずれかを適用すればよい。
【０２２２】
（実施の形態６）
実施の形態５では、PDCCHとPUCCHのレピティションレベルが異なる端末について説明した。これに対し、本実施の形態では、各端末でのPDCCHとPUCCHのレピティションレベルは同一であるが、端末間のレピティションレベルが異なる場合について説明する。
【０２２３】
この場合、MTCカバレッジエンハンスメントモードの端末間において、既存のシステムと同様にしてCCE番号と対応付けてPUCCHリソース番号をImplicitに通知するのでは、端末間において同一PUCCHリソースを用いてACK/NACK信号が同時に送信され、PUCCHリソースの衝突が発生する場合がある。
【０２２４】
図１７は、MTCカバレッジエンハンスメントモードの端末間のPUCCHリソースが衝突する場合の一例を示す。図１７では、端末１（UE#1）のPDCCH、PDSCH、PUCCHのレピティションレベルが８であり、端末２（UE#2）のPDCCH、PDSCH、PUCCHのレピティションレベルが４である。
【０２２５】
また、図１７では、端末１がCCE#0からCCE#3を用いてPDCCHを送信する。一方、端末２は、端末１のPDCCHが送信完了した次のサブフレームから、CCE#0からCCE#3を用いてPDCCHを送信する。つまり、端末１及び端末２の双方は、CCE#0に対応付けられたPUCCHリソースを用いてACK/NACK信号を送信する。
【０２２６】
図１７に示すように、端末１は、８サブフレームに渡ってPDCCHを受信し、次の８サブフレームに渡ってPDSCHを受信する。一方、端末２は、端末１がPDCCHの受信を完了した次のサブフレームから４サブフレームに渡ってPDCCHを受信し、次の４サブフレームに渡ってPDSCHを受信する。つまり、端末１と端末２とは、PDSCHの受信完了のタイミング（又はACK/NACK信号の送信開始タイミング）が同一となる。
【０２２７】
この場合、同一タイミングにおいて、端末１は、８サブフレームに渡ってACK/NACK信号を送信し、端末２は、４サブフレームに渡ってACK/NACK信号を送信する。このため、図１７に示すように、端末１のPUCCHレピティション前半の４サブフレーム、及び、端末２のPUCCHレピティションの全４サブフレームに相当するサブフレームにおいてPUCCHリソースが端末間で衝突してしまう。
【０２２８】
そこで、本実施の形態では、レピティションレベルが互いに異なるMTCカバレッジエンハンスメントモードの端末間のACK/NACK信号を送信するPUCCHリソースの衝突を回避する方法について説明する。
【０２２９】
本実施の形態に係る基地局及び端末の基本構成は、実施の形態１と同様であるので、図８（基地局１００）と図９（端末２００）を援用して説明する。
【０２３０】
具体的には、端末２００（MTCカバレッジエンハンスメントモードの端末）は、PUCCHレピティションにおいて、PDCCHの送信に使用されたCCE番号（つまり、最小のCCE番号）に対応付けてImplicitに通知されるPUCCHリソースを用いて、ACK/NACK信号を送信する。ただし、端末２００は、設定されるレピティションレベル毎に異なるオフセット値を用いて特定されるPUCCHリソースを用いてACK/NACK信号を送信する。
【０２３１】
例えば、レピティションレベルが４の場合のPUCCHリソース番号nPUCCH_MTC_4、及び、レピティションレベルが８の場合のPUCCHリソース番号nPUCCH_MTC_8は、次式に従って決定される。
nPUCCH_MTC_4=nCCE+NPUCCH_MTC_4(1)                        （６）
nPUCCH_MTC_8=nCCE+NPUCCH_MTC_8(1)                        （７）
【０２３２】
式（６）、（７）において、nCCEは、PDCCHが占有するCCE番号（０以上の整数）を示す。また、式（６）、（７）において、NPUCCH_MTC_4(1)は、レピティションレベルが４の場合にCCE番号からPUCCHリソース番号を特定するためのオフセット値を示し、NPUCCH_MTC_8(1)は、レピティションレベルが８の場合にCCE番号からPUCCHリソース番号を特定するためのオフセット値を示す。
【０２３３】
NPUCCH_MTC_4(1)とNPUCCH_MTC_8(1)は、異なる値が設定される。換言すると、端末２００が利用可能なPUCCHリソースは、少なくとも、レピティションレベルが４の場合のPUCCHリソースと、レピティションレベルが８の場合のPUCCHリソースとに分割される。つまり、端末２００が利用可能なPUCCHリソース群は、ACK/NACK信号のレピティションレベル毎の複数のサブリソース群から構成される。
【０２３４】
なお、ここでは、レピティションレベルが４、８の場合について説明するが、レピティションレベルは４，８に限定されず、他の値を採り得る場合にはその値についても同様にしてオフセット値が設定される。
【０２３５】
図１８は、本実施の形態に係る各チャネルの送信タイミングを示す。図１８では、図１７と同様、端末１（UE#1）のPDCCH、PDSCH、PUCCHのレピティションレベルが８であり、端末２（UE#2）のPDCCH、PDSCH、PUCCHのレピティションレベルが４である。また、図１８では、端末１がCCE#0からCCE#3を用いてPDCCHを送信する。一方、端末２は、端末１のPDCCHが送信完了した次のサブフレームから、CCE#0からCCE#3を用いてPDCCHを送信する。
【０２３６】
この場合、図１８に示すように、端末１は、PUCCHレピティションにおいて、式（６）に従って、NPUCCH_MTC_8(1)+nCCE=NPUCCH_MTC_8(1)のPUCCHリソースを用いてACK/NACK信号を送信する。一方、端末２は、PUCCHレピティションにおいて、式（７）に従って、NPUCCH_MTC_4(1)+nCCE=NPUCCH_MTC_4(1)のPUCCHリソースを用いてACK/NACK信号を送信する。
【０２３７】
上述したように、NPUCCH_MTC_4(1)とNPUCCH_MTC_8(1)とは互いに異なる。よって、図１８に示すように、端末１のPUCCHレピティション前半の４サブフレーム、及び、端末２のPUCCHレピティションの全４サブフレームに該当するサブフレームでは、端末１及び端末２の双方において互いに異なるPUCCHリソースが用いられる。このため、端末１と端末２との間でのPUCCHリソースの衝突は発生しない。
【０２３８】
このようにすることで，レピティションレベルが異なるMTCカバレッジエンハンスメントモードの端末間において、同一のCCEを用いてPDCCHを送信し、ACK/NACK信号を同時に送信するサブフレームが発生しても、ACK/NACK信号を送信するPUCCHリソースが端末間で衝突することを回避することができる。
【０２３９】
なお、本実施の形態は、実施の形態１〜４の動作と組み合わせて実施してもよい。つまり、MTCカバレッジエンハンスメントモードの端末同士のPUCCHリソースの衝突を回避する方法について本実施の形態を適用し、MTCカバレッジエンハンスメントモードの端末と通常モードの端末との間のPUCCHリソースの衝突を回避する方法について、実施の形態１〜４のいずれかを適用すればよい。
【０２４０】
以上、本開示の各実施の形態について説明した。
【０２４１】
なお、上記各実施の形態では、本開示の一態様をハードウェアで構成する場合を例にとって説明したが、本開示はソフトウェアで実現することも可能である。
【０２４２】
また、上記各実施の形態の説明に用いた各機能ブロックは、典型的には集積回路であるＬＳＩとして実現される。これらは個別に１チップ化されてもよいし、一部または全てを含むように１チップ化されてもよい。ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。
【０２４３】
また、集積回路化の手法はＬＳＩに限るものではなく、専用回路または汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサーを利用してもよい。
【０２４４】
さらには、半導体技術の進歩または派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。
【０２４５】
本開示の端末は、下りリンクデータの割当を示す制御情報、及び、前記下りリンクデータを受信する受信部と、前記制御情報に基づいて、前記下りリンクデータに対する応答信号に使用されるリソースを決定する制御部と、前記決定されたリソースを用いて前記応答信号を送信する送信部と、を具備し、前記送信部は、自端末が、前記制御情報、前記下りリンクデータ及び前記応答信号に対してレピティション送信が適用される第１の端末である場合には第１のリソース群の中のリソースを用いて前記応答信号を送信し、自端末が、前記レピティション送信が適用されない第２の端末である場合には前記第１のリソース群とは異なる第２のリソース群の中のリソースを用いて前記応答信号を送信する構成を採る。
【０２４６】
本開示の端末において、前記制御部は、前記制御情報に使用されるコントロール・チャネル・エレメント（ＣＣＥ）のインデックスに第１のオフセット値を加算して、前記第１のリソース群において前記応答信号に使用されるリソースを算出し、前記制御情報に使用される前記ＣＣＥのインデックスに第２のオフセット値を加算して、前記第２のリソース群において前記応答信号に使用されるリソースを算出し、前記第１のオフセット値と前記第２のオフセット値とは異なる。
【０２４７】
本開示の端末において、前記制御部は、前記制御情報に使用されるコントロール・チャネル・エレメント（ＣＣＥ）のインデックスにオフセット値を加算して、前記第１のリソース群において前記応答信号に使用されるリソースを算出し、前記オフセット値から、前記制御情報に使用される前記ＣＣＥのインデックスを減算して、前記第２のリソース群において前記応答信号に使用されるリソースを算出する。
【０２４８】
本開示の端末において、前記第１のリソース群及び前記第２のリソース群の各リソースは、直交符号系列と巡回シフト量との組合せによってそれぞれ定義され、前記第１のリソース群の各リソースとして定義された前記組合せのうち、同一直交符号系列において隣接する巡回シフト量の差は、前記第２のリソース群の各リソースとして定義された前記組合せのうち、同一直交符号系列において隣接する巡回シフト量の差よりも小さい。
【０２４９】
本開示の端末において、前記制御情報に使用されるコントロール・チャネル・エレメント（ＣＣＥ）の複数個に対して、前記第１のリソース群の１つのリソースが対応付けられる。
【０２５０】
本開示の端末において、前記複数個は、前記割当情報が占有するＣＣＥの個数である。
【０２５１】
本開示の端末において、前記送信部は、前記応答信号の前記レピティション送信が行われる複数のサブフレームのうち、前記制御情報のレピティション回数以下のサブフレームでは、前記第１のリソース群のうち、前記制御情報に使用されるコントロール・チャネル・エレメント（ＣＣＥ）に対応付けられたリソースを用いて、前記応答信号を送信し、前記制御情報のレピティション回数を超えるサブフレームでは、予め設定されたリソースを用いて、前記応答信号を送信する。
【０２５２】
本開示の端末において、前記第１のリソース群は、前記応答信号のレピティション回数毎の複数のサブリソース群から構成される。
【０２５３】
本開示の基地局は、下りリンクデータの割当を示す制御情報、及び、前記下りリンクデータを送信する送信部と、前記制御情報に基づいて、前記下りリンクデータに対する応答信号に使用されるリソースを決定する制御部と、前記決定されたリソースを用いて前記応答信号を受信する受信部と、を具備し、前記受信部は、前記制御情報、前記下りリンクデータ及び前記応答信号に対してレピティション送信が適用される第１の端末から送信される前記応答信号を、第１のリソース群の中のリソースを用いて受信し、前記レピティション送信が適用されない第２の端末から送信される前記応答信号を、前記第１のリソース群とは異なる第２のリソース群の中のリソースを用いて受信する。
【０２５４】
本開示の送信方法は、下りリンクデータの割当を示す制御情報、及び、前記下りリンクデータを受信する受信工程と、前記制御情報に基づいて、前記下りリンクデータに対する応答信号に使用されるリソースを決定する制御工程と、前記決定されたリソースを用いて前記応答信号を送信する送信工程と、を具備し、前記送信工程は、前記制御情報、前記下りリンクデータ及び前記応答信号に対してレピティション送信が適用される第１の端末では第１のリソース群の中のリソースを用いて前記応答信号を送信し、前記レピティション送信が適用されない第２の端末では前記第１のリソース群とは異なる第２のリソース群の中のリソースを用いて前記応答信号を送信する。
【０２５５】
本開示の受信方法は、下りリンクデータの割当を示す制御情報、及び、前記下りリンクデータを送信する送信工程と、前記制御情報に基づいて、前記下りリンクデータに対する応答信号に使用されるリソースを決定する制御工程と、前記決定されたリソースを用いて前記応答信号を受信する受信工程と、を具備し、前記受信工程は、前記制御情報、前記下りリンクデータ及び前記応答信号に対してレピティション送信が適用される第１の端末から送信される前記応答信号を、第１のリソース群の中のリソースを用いて受信し、前記レピティション送信が適用されない第２の端末から送信される前記応答信号を、前記第１のリソース群とは異なる第２のリソース群の中のリソースを用いて受信する。
【産業上の利用可能性】
【０２５６】
本開示の一態様は、移動通信システムに有用である。
【符号の説明】
【０２５７】
１００  基地局
２００  端末
１０１，２１３  制御部
１０２  制御信号生成部
１０３  制御信号符号化部
１０４  制御信号変調部
１０５  報知信号生成部
１０６  データ符号化部
１０７  再送制御部
１０８  データ変調部
１０９  信号割当部
１１０，２１８  IFFT部
１１１，２１９  CP付加部
１１２，２２０  送信部
１１３  アンテナ
１１４，２０２  受信部
１１５，２０３  CP除去部
１１６  PUCCH抽出部
１１７  系列制御部
１１８  逆拡散部
１１９  相関処理部
１２０，２０９  判定部
２０４  FFT部
２０５  抽出部
２０６  報知信号受信部
２０７  制御信号復調部
２０８  制御信号復号部
２１０  データ復調部
２１１  データ復号部
２１２  CRC部
２１４  ACK/NACK生成部
２１５  変調部
２１６  １次拡散部
２１７  ２次拡散部
【図１】
2020005292.tif 000003
【図２】
2020005292.tif 000004
【図３】
2020005292.tif 000005
【図４】
2020005292.tif 000006
【図５】
2020005292.tif 000007
【図６】
2020005292.tif 000008
【図７】
2020005292.tif 000009
【図８】
2020005292.tif 000010
【図９】
2020005292.tif 000011
【図１０】
2020005292.tif 000012
【図１１】
2020005292.tif 000013
【図１２】
2020005292.tif 000014
【図１３】
2020005292.tif 000015
【図１４】
2020005292.tif 000016
【図１５】
2020005292.tif 000017
【図１６】
2020005292.tif 000018
【図１７】
2020005292.tif 000019
【図１８】
2020005292.tif 000020