知財求人 - 知財ポータルサイト「IP Force」
▶ パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカの特許一覧
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】6667532
(24)【登録日】2020年2月27日
(45)【発行日】2020年3月18日
(54)【発明の名称】端末、基地局、送信方法及び受信方法
(51)【国際特許分類】
H04W 72/04 20090101AFI20200309BHJP
H04W 28/06 20090101ALI20200309BHJP
【ＦＩ】
H04W72/04 136
H04W28/06 110
【請求項の数】7
【全頁数】30
(21)【出願番号】特願2017-534096(P2017-534096)
(86)(22)【出願日】2016年7月14日
(86)【国際出願番号】JP2016003324
(87)【国際公開番号】WO2017026091
(87)【国際公開日】20170216
【審査請求日】2019年1月25日
(31)【優先権主張番号】特願2015-159141(P2015-159141)
(32)【優先日】2015年8月11日
(33)【優先権主張国】JP
(73)【特許権者】
【識別番号】514136668
【氏名又は名称】パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ
【氏名又は名称原語表記】Ｐａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ
(74)【代理人】
【識別番号】110002952
【氏名又は名称】特許業務法人鷲田国際特許事務所
(72)【発明者】
【氏名】山本 哲矢
(72)【発明者】
【氏名】鈴木 秀俊
(72)【発明者】
【氏名】堀内 綾子
【審査官】
深津 始
(56)【参考文献】
【文献】
特開２０１５−１６４２７９（ＪＰ，Ａ）
【文献】
MediaTek Inc.，Discussion on PUCCH resource allocation for Rel-13 MTC，3GPP TSG-RAN WG1#81 R1-153317，２０１５年 ５月１６日，インターネット＜URL:http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_81/Docs/R1-153317.zip＞
【文献】
LG Electronics，HARQ-ACK feedback for MTC UE，3GPP TSG-RAN WG1#81 R1-152704，２０１５年 ５月１６日，インターネット＜URL:http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_81/Docs/R1-152704.zip＞
【文献】
Panasonic，Discussion and evaluation on PUCCH for MTC[online]，3GPP TSG-RAN WG1#82 R1-153970，２０１５年 ８月１４日，インターネット＜URL:http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_82/Docs/R1-153970.zip＞
(58)【調査した分野】（Int.Cl.，ＤＢ名）
Ｈ０４Ｂ ７／２４ −Ｈ０４Ｂ ７／２６
Ｈ０４Ｗ ４／００ −Ｈ０４Ｗ ９９／００
３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１−４
ＳＡ ＷＧ１−４
ＣＴ ＷＧ１、４
(57)【特許請求の範囲】
【請求項1】
MTC端末向けの狭帯域内の下りリソースを用いて、同一の下りリンクデータを１つ又は複数のサブフレームに渡って受信する受信部と、
前記下りリンクデータに対する応答信号を生成する生成部と、
前記１つ又は複数のサブフレームの最後尾サブフレームにおいて前記下りリンクデータが割り当てられた下りリソースの番号に１対１で対応付けられた上りリソースを用いて、前記最後尾サブフレームから所定数のサブフレーム後に前記応答信号を送信する送信部と、
を具備し、
前記下りリンクデータの送信に用いられるサブフレーム数が所定数未満である第１のMTC端末に対して前記狭帯域を構成するPRB（Physical Resource Block）単位で前記下りリンクデータが割り当てられ、前記下りリソースの番号は、割り当てられた前記PRBの番号であり、
前記サブフレーム数が前記所定数以上である第２のMTC端末に対して前記狭帯域の単位で前記下りリンクデータが割り当てられ、前記下りリソースの番号は、割り当てられた前記狭帯域の番号である、
端末。
前記下りリンクデータに対する応答信号を生成する生成部と、
前記１つ又は複数のサブフレームの最後尾サブフレームにおいて前記下りリンクデータが割り当てられた下りリソースの番号に１対１で対応付けられた上りリソースを用いて、前記最後尾サブフレームから所定数のサブフレーム後に前記応答信号を送信する送信部と、
を具備し、
前記下りリンクデータの送信に用いられるサブフレーム数が所定数未満である第１のMTC端末に対して前記狭帯域を構成するPRB（Physical Resource Block）単位で前記下りリンクデータが割り当てられ、前記下りリソースの番号は、割り当てられた前記PRBの番号であり、
前記サブフレーム数が前記所定数以上である第２のMTC端末に対して前記狭帯域の単位で前記下りリンクデータが割り当てられ、前記下りリソースの番号は、割り当てられた前記狭帯域の番号である、
端末。
【請求項2】
前記第１のMTC端末に対して複数の前記狭帯域が設定され、
前記複数の狭帯域それぞれに割り当てられた前記下りリンクデータに対する前記応答信号が送信される前記上りリソースの番号は、前記複数の狭帯域それぞれの番号と、前記複数の狭帯域それぞれを構成するPRBの数と、前記複数の狭帯域それぞれにおいて割り当てられた前記PRBの番号とに基づいて算出される、
請求項１に記載の端末。
前記複数の狭帯域それぞれに割り当てられた前記下りリンクデータに対する前記応答信号が送信される前記上りリソースの番号は、前記複数の狭帯域それぞれの番号と、前記複数の狭帯域それぞれを構成するPRBの数と、前記複数の狭帯域それぞれにおいて割り当てられた前記PRBの番号とに基づいて算出される、
請求項１に記載の端末。
【請求項3】
前記第１のMTC端末に対して複数の前記狭帯域が設定され、
前記複数の狭帯域それぞれに割り当てられた前記下りリンクデータに対する前記応答信号が送信される前記上りリソースの番号は、前記複数の狭帯域それぞれにおいて割り当てられた前記PRBの番号と、前記複数の狭帯域それぞれに対応するオフセットとに基づいて算出される、
請求項１に記載の端末。
前記複数の狭帯域それぞれに割り当てられた前記下りリンクデータに対する前記応答信号が送信される前記上りリソースの番号は、前記複数の狭帯域それぞれにおいて割り当てられた前記PRBの番号と、前記複数の狭帯域それぞれに対応するオフセットとに基づいて算出される、
請求項１に記載の端末。
【請求項4】
前記第１のMTC端末と、前記第２のMTC端末との間で、前記応答信号の送信に用いられる前記上りリソースの領域は異なる、
請求項１に記載の端末。
請求項１に記載の端末。
【請求項5】
MTC端末向けの狭帯域内の下りリソースを用いて、１つ又は複数のサブフレームに渡って同一の下りリンクデータを送信する送信部と、
前記１つ又は複数のサブフレームの最後尾サブフレームにおいて前記下りリンクデータが割り当てられた下りリソースの番号に１対１で対応付けられた上りリソースを用いて、前記最後尾サブフレームから所定数のサブフレーム後に、前記下りリンクデータに対する応答信号を受信する受信部と、
を具備し、
前記下りリンクデータの送信に用いられるサブフレーム数が所定数未満である第１のMTC端末に対して前記狭帯域を構成するPRB（Physical Resource Block）単位で前記下りリンクデータが割り当てられ、前記下りリソースの番号は、割り当てられた前記PRBの番号であり、
前記サブフレーム数が前記所定数以上である第２のMTC端末に対して前記狭帯域の単位で前記下りリンクデータが割り当てられ、前記下りリソースの番号は、割り当てられた前記狭帯域の番号である、
基地局。
前記１つ又は複数のサブフレームの最後尾サブフレームにおいて前記下りリンクデータが割り当てられた下りリソースの番号に１対１で対応付けられた上りリソースを用いて、前記最後尾サブフレームから所定数のサブフレーム後に、前記下りリンクデータに対する応答信号を受信する受信部と、
を具備し、
前記下りリンクデータの送信に用いられるサブフレーム数が所定数未満である第１のMTC端末に対して前記狭帯域を構成するPRB（Physical Resource Block）単位で前記下りリンクデータが割り当てられ、前記下りリソースの番号は、割り当てられた前記PRBの番号であり、
前記サブフレーム数が前記所定数以上である第２のMTC端末に対して前記狭帯域の単位で前記下りリンクデータが割り当てられ、前記下りリソースの番号は、割り当てられた前記狭帯域の番号である、
基地局。
【請求項6】
MTC端末向けの狭帯域内の下りリソースを用いて、同一の下りリンクデータを１つ又は複数のサブフレームに渡って受信し、
前記下りリンクデータに対する応答信号を生成し、
前記１つ又は複数のサブフレームの最後尾サブフレームにおいて前記下りリンクデータが割り当てられた下りリソースの番号に１対１で対応付けられた上りリソースを用いて、前記最後尾サブフレームから所定数のサブフレーム後に前記応答信号を送信し、
前記下りリンクデータの送信に用いられるサブフレーム数が所定数未満である第１のMTC端末に対して前記狭帯域を構成するPRB（Physical Resource Block）単位で前記下りリンクデータが割り当てられ、前記下りリソースの番号は、割り当てられた前記PRBの番号であり、
前記サブフレーム数が前記所定数以上である第２のMTC端末に対して前記狭帯域の単位で前記下りリンクデータが割り当てられ、前記下りリソースの番号は、割り当てられた前記狭帯域の番号である、
送信方法。
前記下りリンクデータに対する応答信号を生成し、
前記１つ又は複数のサブフレームの最後尾サブフレームにおいて前記下りリンクデータが割り当てられた下りリソースの番号に１対１で対応付けられた上りリソースを用いて、前記最後尾サブフレームから所定数のサブフレーム後に前記応答信号を送信し、
前記下りリンクデータの送信に用いられるサブフレーム数が所定数未満である第１のMTC端末に対して前記狭帯域を構成するPRB（Physical Resource Block）単位で前記下りリンクデータが割り当てられ、前記下りリソースの番号は、割り当てられた前記PRBの番号であり、
前記サブフレーム数が前記所定数以上である第２のMTC端末に対して前記狭帯域の単位で前記下りリンクデータが割り当てられ、前記下りリソースの番号は、割り当てられた前記狭帯域の番号である、
送信方法。
【請求項7】
MTC端末向けの狭帯域内の下りリソースを用いて、１つ又は複数のサブフレームに渡って同一の下りリンクデータを送信し、
前記１つ又は複数のサブフレームの最後尾サブフレームにおいて前記下りリンクデータが割り当てられた下りリソースの番号に１対１で対応付けられた上りリソースを用いて、前記最後尾サブフレームから所定数のサブフレーム後に、前記下りリンクデータに対する応答信号を受信し、
前記下りリンクデータの送信に用いられるサブフレーム数が所定数未満である第１のMTC端末に対して前記狭帯域を構成するPRB（Physical Resource Block）単位で前記下りリンクデータが割り当てられ、前記下りリソースの番号は、割り当てられた前記PRBの番号であり、
前記サブフレーム数が前記所定数以上である第２のMTC端末に対して前記狭帯域の単位で前記下りリンクデータが割り当てられ、前記下りリソースの番号は、割り当てられた前記狭帯域の番号である、
受信方法。
前記１つ又は複数のサブフレームの最後尾サブフレームにおいて前記下りリンクデータが割り当てられた下りリソースの番号に１対１で対応付けられた上りリソースを用いて、前記最後尾サブフレームから所定数のサブフレーム後に、前記下りリンクデータに対する応答信号を受信し、
前記下りリンクデータの送信に用いられるサブフレーム数が所定数未満である第１のMTC端末に対して前記狭帯域を構成するPRB（Physical Resource Block）単位で前記下りリンクデータが割り当てられ、前記下りリソースの番号は、割り当てられた前記PRBの番号であり、
前記サブフレーム数が前記所定数以上である第２のMTC端末に対して前記狭帯域の単位で前記下りリンクデータが割り当てられ、前記下りリソースの番号は、割り当てられた前記狭帯域の番号である、
受信方法。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、端末、基地局、送信方法及び受信方法に関する。【背景技術】
【0002】
3GPP LTE（3rd Generation Partnership Project Long Term Evolution）では、基地局（eNBと呼ぶこともある）から端末（UE（User Equipment）と呼ぶこともある）への下りリンクの通信方式としてOFDMA（Orthogonal Frequency Division Multiple Access）が採用され、端末から基地局への上りリンクの通信方式としてSC-FDMA（Single Carrier-Frequency Division Multiple Access）が採用されている（例えば、非特許文献１−３を参照）。【0003】
LTEでは、基地局は、システム帯域内のリソースブロック（RB:Resource Block）をサブフレームと呼ばれる時間単位毎に端末に対して割り当てることにより通信を行う。また、基地局は、下りリンク制御チャネル（PDCCH: Physical Downlink Control Channel）を用いて、端末がデータを送受信するための制御情報を送信する。また、LTE Release 11では、基地局は、PDCCHの拡張であるEPDCCH（Enhanced PDCCH）を用いて制御情報を送信することもできる。端末は、受信したPDCCH信号又はEPDCCH信号によって自端末に送信された制御情報を復号し、データの送受信に必要な周波数割当又は適応制御などに関する情報を得る。【0004】
また、LTEでは、下りリンクデータに対してHARQ（Hybrid Automatic Repeat Request）が適用される。つまり、端末は、下りリンクデータの誤り検出結果を示す応答信号を基地局へフィードバックする。端末は、下りリンクデータに対してCRC（Cyclic Redundancy Check）を行って、CRCの演算結果に誤りがなければ肯定応答（ACK: Acknowledgement）を、CRC演算結果に誤りがあれば否定応答（NACK: Negative Acknowledgement）を応答信号として基地局へフィードバックする。この応答信号（つまり、ACK/NACK信号）のフィードバックには、PUCCH（Physical Uplink Control Channel）等の上りリンク制御チャネルが用いられる。【0005】
LTEでは、複数の端末から送信される複数のACK/NACK信号は、図１に示すように、時間軸上においてZero Auto-correlation特性を持つZAC（Zero Auto-correlation）系列によって拡散され（ZAC系列を乗算し）、PUCCH内においてコード多重されている。図１において、（W(0), W(1), W(2), W(3)）は系列長４のウォルシュ（Walsh）系列を表し、（F(0),F(1),F(2)）は系列長３のDFT（Discrete Fourier Transform）系列を表す。【0006】
図１に示すように、端末ではACK/NACK信号は、まず周波数軸上においてZAC系列（系列長１２）によって１SC-FDMAシンボルに対応する周波数成分へ１次拡散される。つまり、系列長１２のZAC系列に対して、複素数で表されるACK/NACK信号成分が乗算される。次に、１次拡散後のACK/NACK信号、及び、参照信号としてのZAC系列は、それぞれWalsh系列（系列長４: W(0)〜W(3)）及びDFT系列（系列長３: F(0)〜F(2)）によって２次拡散される。つまり、系列長１２の信号（１次拡散後のACK/NACK信号、又は、参照信号としてのZAC系列）のそれぞれの成分に対して、直交符号系列（OCC：Orthogonal Cover Code， ウォルシュ系列又はDFT系列）の各成分が乗算される。さらに、２次拡散された信号は、逆離散フーリエ変換（IDFT: Inverse Discrete Fourier Transform、又はIFFT： Inverse Fast Fourier Transform）によって時間軸上の系列長１２の信号に変換される。そして、IFFT後の信号のそれぞれに対して、サイクリックプリフィックス（CP：Cyclic Prefix）が付加され、７つのSC-FDMAシンボルからなる１スロットの信号が形成される。【0007】
また、PUCCHは、図２に示すように、サブフレーム単位で各端末に割り当てられる。【0008】
異なる端末からのACK/NACK信号同士は、異なる巡回シフト量（Cyclic Shift Index）で定義されるZAC系列、又は、異なる系列番号（OC Index: Orthogonal Cover Index）に対応する直交符号系列を用いて拡散（乗算）されている。直交符号系列は、ウォルシュ系列とDFT系列との組である。また、直交符号系列は、ブロックワイズ拡散コード系列（Block-wise spreading code）と称されることもある。したがって、基地局は、従来の逆拡散及び相関処理を用いることにより、これらのコード多重された複数のACK/NACK信号を分離することができる（例えば、非特許文献４を参照）。なお、周波数リソースブロック（RB）あたりに符号多重及び巡回シフト多重できるACK/NACK信号の数は限りがあるため、端末の数が多くなると異なるRBに周波数多重される。以下、ACK/NACK信号が送信される符号及び周波数リソースをPUCCHリソースと呼ぶ。PUCCHリソースの番号（index）は、ACK/NACK信号を送信するRB番号と、そのRBにおけるOC Index及び巡回シフト量により決定される。ZAC系列の巡回シフトによる多重も一種の符号多重とみなせることから、以降では、直交符号及び巡回シフトを併せて符号と記す場合がある。【0009】
LTEでは、ACK/NACK信号を送信するPUCCHリソースを特定する方法として、PDCCH又はEPDCCHの制御情報マッピング結果に基づく割り当てを採用している。【0010】
PDCCHの場合、制御情報は複数の端末間で同一のリソースにマッピングされないことを利用し、PDCCHのリソースとPUCCHリソースとを１対１に対応付けている。PDCCHは１つ又は複数のL1/L2 CCH（L1/L2 Control Channel）から構成される。各L1/L2 CCHは、１つ又は複数CCE（Control Channel Element）から構成される。すなわち、CCEは、制御情報をPDCCHにマッピングするときの基本単位である。また、１つのL1/L2 CCHが複数（2, 4, 8個）のCCEから構成される場合には、そのL1/L2 CCHには偶数のインデックスを持つCCEを起点とする連続する複数のCCEが割り当てられる。基地局は、リソース割当対象端末に対する制御情報の通知に必要なCCE数に従って、そのリソース割当対象端末に対してL1/L2 CCHを割り当てる。そして、基地局は、このL1/L2 CCHのCCEに対応する物理リソースに制御情報をマッピングして送信する。また、ここで、各CCEはACK/NACK信号を送信するPUCCHリソースと１対１に対応付けられている。従って、L1/L2 CCHを受信した端末は、このL1/L2 CCHを構成するCCEに対応するPUCCHリソースを特定し、このリソース（つまり符号及び周波数）を用いてACK/NACK信号を基地局へ送信する。ただし、L1/L2 CCHが連続する複数のCCEを占有する場合には、端末は、複数のCCEにそれぞれ対応する複数のPUCCH構成リソースのうちインデックスが最も小さいCCEに対応するPUCCHリソースを利用して、ACK/NACK信号を基地局へ送信する。具体的には、次式（数１）に基づきPUCCHリソース番号nPUCCHが定まる（例えば、非特許文献３参照）。【0011】
【数1】
【0012】
ここで、nPUCCHは前述のACK/NACK信号を送信するPUCCHリソース番号である。NPUCCHはセル内共通に与えられるPUCCHリソースオフセット値を表し、nCCEは当該端末に対するPDCCHがマッピングされたCCEのうち、インデックスが最も小さいCCE番号を表す。【0013】
EPDCCHの場合、EPDCCHで割り当てられた下りリンクデータチャネル（PDSCH：Physical Downlink Shared Channel）に対するACK/NACK信号のリソース決定には、EPDCCH set毎に上位レイヤから与えられるPUCCHリソースオフセットと、それぞれのEPDCCHを構成する要素単位である拡張制御チャネル要素（ECCE：Enhanced CCE）のインデックスとを用いる。すなわち、EPDCCHに対応するPUCCHリソース番号は、上記PUCCHリソースオフセットの値と、EPDCCHがマッピングされていたECCEの番号のうちインデックスが最も小さいECCE番号とを用いて決定される。EPDCCH毎に対応するPUCCHリソースオフセットを適切に設定することにより、PDCCH、及び、１つ又は複数のEPDCCH setが運用される環境においても、端末が送信するACK/NACK信号を適切に割り当てることができる。【0014】
PUCCHリソースオフセットを十分大きな値とすることで複数のEPDCCH setに対応するPUCCH領域がそれぞれ重複しないよう運用できる一方で、使用するEPDCCH setの数に応じて確保するPUCCHリソース総量が増え、PUCCHオーバヘッドが増加してしまう。【0015】
反対に、PUCCHリソースオフセットを調節し、複数のPUCCH領域が重複するよう運用することもできる。この場合、確保すべきPUCCHリソース総量を低減できる。ただし、PUCCH領域が重複するEPDCCH set間で使用するPUCCHリソースが衝突する可能性がある。このようなPUCCHリソースの衝突が起こる場合、何れか１つのEPDCCH setのみしか割り当てできないため、下りスループットが劣化してしまう。そこで、複数のPUCCH領域を重複して運用しつつ、PUCCHリソースの衝突を回避する方法として、EPDCCHの制御情報内に更なるオフセットを通知するARO（ACK/NACK Resource Offset）と呼ばれる制御ビットが追加されている。具体的には、次式（数２）に基づいてPUCCHリソースが定まる（例えば、非特許文献３を参照）。【0016】
【数2】
【0017】
ここで、nPUCCH,EPDCCHはPUCCHリソース番号である。NEPDCCH(n)はn番目のEPDCCH set(n)に対応するPUCCHリソースオフセットであり、ΔAROはオフセット値、nECCE(n)はEPDCCH set(n)の中で定義されるECCE番号のうち、実際にEPDCCHの送信に使用されたECCEの中でインデックスが最も小さいECCE番号である。なお、NEPDCCH(n)は端末固有の上位レイヤにより通知される値である。【0018】
ところで、今後の情報社会を支える仕組みとして、近年、ユーザの判断を介することなく機器間の自律的な通信によりサービスを実現するM2M（Machine-to-Machine）通信が期待されている。M2Mシステムの具体的な応用事例としてスマートグリッドがある。スマートグリッドは、電気又はガスなどのライフラインを効率的に供給するインフラシステムであり、各家庭又はビルに配備されるスマートメータと中央サーバとの間でM2M通信を実施して、自律的かつ効果的に資源の需要バランスを調整する。M2M通信システムの他の応用事例として、物品管理、環境センシング又は遠隔医療などのためのモニタリングシステム、自動販売機の在庫又は課金の遠隔管理などが挙げられる。【0019】
M2M通信システムにおいては、特に広範な通信エリアを有するセルラシステムの利用が着目されている。3GPPでは、LTE及びLTE-Advancedの規格化において、マシンタイプ通信（MTC: Machine Type Communication）と呼ばれるM2M向けのセルラネットワーク高度化の標準化が行われており（例えば、非特許文献５）、端末の低コスト化、消費電力削減、及びカバレッジ拡張（Coverage Enhancement）を要求条件として仕様検討が進められている。【0020】
端末の低コスト化を実現するために、LTE Release 13のMTCに対応する端末（以下、MTC端末と呼ぶこともある）は1.4MHzの周波数帯域幅（以下、MTC狭帯域と呼ぶこともある）しかサポートしない。また、通信エリアを更に拡大するためのMTCカバレッジ拡張では、同一の信号を複数回に渡って繰り返し送信し、受信側でそれらを合成することによって、受信信号電力を向上させ、カバレッジを拡張するレピティション技術が採用される。【先行技術文献】
【非特許文献】
【0021】
【非特許文献1】3GPP TS 36.211 V12.5.0, “Evolved Universal Terrestrial Radio Access (E-UTRA); Physical channels and modulation (Release 12),” March 2015.
【非特許文献2】3GPP TS 36.212 V12.4.0, “Evolved Universal Terrestrial Radio Access (E-UTRA); Multiplexing and channel coding (Release 12),” March 2015.
【非特許文献3】3GPP TS 36.213 V12.5.0, “Evolved Universal Terrestrial Radio Access (E-UTRA); Physical layer procedures (Release 12),” March 2015.
【非特許文献4】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.
【非特許文献5】RP-141660, Ericsson, Nokia Networks, “New WI proposal: Further LTE Physical Layer Enhancements for MTC,” September 2014
【発明の概要】
【0022】
MTC端末は既存のLTEシステムに対応する端末（以下、LTE端末と呼ぶこともある）と比較して狭い周波数帯域（MTC狭帯域）のみに対応する。そのため、MTC端末は、既存のLTEシステムがサポートする周波数帯域に渡って配置される既存のLTEシステムのPDCCHに割り当てられた制御情報を復調することはできない。そこで、MTC端末に対して制御情報を送信する下りリンク制御チャネル（MPDCCH：Physical Downlink Control Channel for MTC）としてEPDCCHを用いることが検討されている。しかしながら、既存のLTEシステムと同様の方法（数式２）をそのまま用いて、MTC端末が下りリンクデータに対するACK/NACK信号を送信するPUCCHリソースを適切に特定することは困難である。【0023】
本開示の一態様は、MTC端末において適切にPUCCHリソースを特定することができる端末、基地局、送信方法及び受信方法を提供する。【0024】
本開示の一態様に係る端末は、MTC端末向けの狭帯域内の下りリソースを用いて、同一の下りリンクデータを１つ又は複数のサブフレームに渡って受信する受信部と、前記下りリンクデータに対する応答信号を生成する生成部と、前記１つ又は複数のサブフレームの最後尾サブフレームにおいて前記下りリンクデータが割り当てられた下りリソースの番号に１対１で対応付けられた上りリソースを用いて、前記最後尾サブフレームから所定数のサブフレーム後に前記応答信号を送信する送信部と、を具備する。【0025】
なお、これらの包括的または具体的な態様は、システム、装置、方法、集積回路、コンピュータプログラム、または、記録媒体で実現されてもよく、システム、装置、方法、集積回路、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。【0026】
本開示の一態様によれば、MTC端末において適切にPUCCHリソースを特定することができる。【0027】
本開示の一態様における更なる利点および効果は、明細書および図面から明らかにされる。かかる利点および／または効果は、いくつかの実施形態並びに明細書および図面に記載された特徴によってそれぞれ提供されるが、１つまたはそれ以上の同一の特徴を得るために必ずしも全てが提供される必要はない。【図面の簡単な説明】
【0028】
【図1】PUCCHにおける応答信号生成処理の一例を示す図
【図2】PUCCHのサブフレーム構成の一例を示す図
【図3】カバレッジ拡張レベルに起因して発生するPUCCHリソースの衝突の一例を示す図
【図4A】スケジューリング方法に起因して発生するPUCCHリソースの衝突の一例を示す図
【図4B】同一サブフレームスケジューリング及びクロスサブフレームスケジューリングの一例を示す図
【図5】実施の形態１に係る基地局の要部構成を示すブロック図
【図6】実施の形態１に係る端末の要部構成を示すブロック図
【図7】実施の形態１に係る基地局の構成を示すブロック図
【図8】実施の形態１に係る端末の構成を示すブロック図
【図9】LTEシステム帯域内のMTC狭帯域の一例を示す図
【図10】実施の形態１に係るPUCCHリソースの特定方法の一例を示す図
【図11A】実施の形態１に係るMPDCCH、PDSCH及びPUCCHの割当の一例を示す図
【図11B】同一サブフレームスケジューリング又クロスサブフレームスケジューリングの一例を示す図
【図12】LTEシステム帯域内のMTC狭帯域の一例を示す図
【図13】実施の形態１のバリエーション１に係るPRBとPUCCHリソースとの対応付けの一例を示す図
【図14】実施の形態１のバリエーション２に係るPRBとPUCCHリソースとの対応付けの一例を示す図
【図15】実施の形態２に係るMTC狭帯域とPUCCHリソースとの対応付けの一例を示す図
【発明を実施するための形態】
【0029】
以下、本開示の実施の形態について図面を参照して詳細に説明する。【0030】
[本開示の基礎となった一知見]MTCでは、複数のカバレッジ拡張レベルが定義されることが検討されており、各カバレッジ拡張レベルにおいて必要となるレピティションの回数は異なる。異なるカバレッジ拡張レベルの端末が共存する場合、同一のサブフレームにおいて複数の端末でACK/NACK信号の送信に用いるPUCCHリソースが、端末間で同一のEPDCCH set及びECCEに対応付けられている場合がある。このため、基地局がPUCCHリソースを、EPDCCHに使用されるECCEに１対１に対応付けてImplicitに通知する場合、複数の端末の各々においてACK/NACK信号の送信に用いるPUCCHリソースが衝突する場合がある。これに対して（数式２）におけるAROによってPUCCHリソースの衝突を回避することが考えられる。しかし、EPDCCH set間でPUCCH領域が重複するように運用している場合には、EPDDCH set間でのPUCCH領域の重複に加えて、異なるカバレッジ拡張レベルの端末間でのPUCCHリソースの衝突も考慮する必要が生じるため、スケジューリングが複雑になったり、既存のAROオフセット値だけでは不十分になったりすることも考えられる。
【0031】
図３は、端末１に対して、MPDCCHのレピティション回数=4、MPDSCHのレピティション回数=4、PUCCHのレピティション回数=4であり、端末２に対して、MPDCCHのレピティション回数=2、MPDSCHのレピティション回数=2、PUCCHのレピティション回数=2である場合のリソース割当の一例を示す。【0032】
図３において、基地局は、端末１及び端末２の各々に対して異なるサブフレームを用いてMPDCCHを送信できる。このため、基地局は、MPDCCHにおいて、端末１及び端末２に対して、同一のEPDCCH set及びECCEを用いて制御情報を送信することができる。この場合、端末１及び端末２には、同一のEPDCCH set及びECCEに対応付けられた同一のPUCCHリソースがImplicitに割り当てられる。ただし、端末１及び端末２は、図３に示すように、同一サブフレームにおいてACK/NACK信号を送信する場合にはPUCCHリソースの衝突を考慮する必要がある。【0033】
また、LTE Release13のMTCでは、基地局は、レピティション送信の必要ない（カバレッジ拡張の必要がない）MTC端末に対して、MPDCCHで割り当てるPDSCHを当該MPDCCHと同一のサブフレームに割り当てる同一サブフレームスケジューリング（same subframe scheduling）又はMPDCCHで割り当てるPDSCHを当該MPDCCHと異なるサブフレームに割り当てるクロスサブフレームスケジューリング（cross subframe scheduling）を行うことができる。【0034】
この場合も、同一のサブフレームにおいて複数の端末でACK/NACK信号の送信に用いるPUCCHリソースが、端末間で同一のEPDCCH set及びECCEに対応付けられている場合がある。このため、基地局がPUCCHリソースを、EPDCCHに使用されるECCEに１対１に対応付けてImplicitに通知する場合、複数の端末の各々においてACK/NACK信号の送信に用いるPUCCHリソースが衝突する場合がある。これに対して、上記同様、（数式２）におけるAROによってPUCCHリソースの衝突を回避することが考えられる。しかし、EPDDCH set間のPUCCH領域の重複、及び、異なるカバレッジ拡張レベルの端末間でのPUCCHリソースの衝突に加えて、同一サブフレームスケジューリングとクロスサブフレームスケジューリングの影響も考慮する必要が生じるため、スケジューリングが複雑になったり、既存のAROオフセット値だけでは不十分になったりすることも考えられる。【0035】
図４Ａ及び図４Ｂは、端末１に対してクロスサブフレームスケジューリングが適用され、端末２に対して同一サブフレームスケジューリングが適用される場合のリソース割当の一例を示す。図４Ａに示すように、基地局は、端末１及び端末２に対して、それぞれ異なるサブフレームを用いてMPDCCHを送信できる。このため、基地局は、MPDCCHにおいて、端末１及び端末２に対して、同一のEPDCCH set及びECCEを用いて制御情報を送信することができる。この場合、端末１及び端末２には、同一のEPDCCH set及びECCEに対応付けられた同一のPUCCHリソースがImplicitに割り当てられる。ただし、端末１及び端末２は、図４Ａ又は図４Ｂに示すように、同一サブフレームにおいてACK/NACK信号を送信する場合にはPUCCHリソースの衝突を考慮する必要がある。【0036】
以上のように、MTCでは、下りリンクデータ信号に対するACK/NACK信号を送信するPUCCHリソースの特定方法に関して、既存のPUCCHリソース領域の重複に加えて、複数のMTC端末が異なるサブフレームで同一のEPDCCH set及びECCEを用いて制御情報を送信した場合のPUCCHリソースの衝突も考慮しなければならない。このため、既存のLTEシステムと同様の方法（数式２）を用いてPUCCHリソースを決定するのでは、MPDCCHのブロッキング確率が増加し、スループットが劣化してしまう恐れがある。【0037】
また、上述したように、MTC端末は既存のLTE端末と比較して狭い周波数帯域のみに対応する。そのため、既存のLTEシステムがサポートする周波数帯域に渡って配置される既存のLTEシステムのPDCCHに割り当てられた制御情報を復調することはできない。ここで、既存のLTEシステムにおけるEPDCCHでは、基地局がPDCCHを用いてLTE端末と初期接続を行った後に、端末固有の上位レイヤ通知を用いてEPDCCHのパラメータ（例えば、EPDCCH set(n)に対応するPUCCHリソースオフセット等）が設定される。そのため、EPDCCHを用いる場合であっても、LTE端末がPDCCHを用いて初期接続処理を行う必要があった。【0038】
一方、MTC端末は、PDCCHに割り当てられた制御情報を復調できないため、既存のLTEシステムと同様のEPDCCHに基づいたPUCCHリソースの特性方法では、初期接続処理の過程において基地局がPDSCHで端末に送信するMsg4に対するACK/NACK信号の送信に用いるPUCCHリソースを特性することができない。下りリンクデータに対するACK/NACKの送信に用いるPUCCHリソースの特性方法として、Msg4とその他の下りリンクデータ信号とで異ならせることも考えられるが規格をシンプルにするためには望ましくない。そこで、発明者らは、MTC端末において適切にPUCCHリソースを特定することができる端末、基地局、送信方法及び受信方法を検討した。【0039】
［通信システムの概要］本開示の各実施の形態に係る通信システムは、例えば、LTE-Advancedシステムに対応する基地局１００及び複数の端末２００（MTC端末）を備える。
【0040】
また、基地局１００のセル内には、異なるカバレッジ拡張レベルの端末２００が共存している場合を想定する。また、MTC端末は、既存のLTEシステムの帯域幅と比較して、より狭い帯域幅（MTC帯域幅。例えば、1.4MHz）をサポートする。【0041】
図５は、本開示の実施の形態に係る基地局１００の要部構成を示すブロック図である。図５に示す基地局１００において、送信部１１１は、MTC端末向けの狭帯域（MTC狭帯域）内の下りリソースを用いて、１つ又は複数のサブフレームに渡って同一の下りリンクデータを送信する。受信部１１３は、１つ又は複数のサブフレームの最後尾サブフレームにおいて下りリンクデータが割り当てられた下りリソースの番号に１対１で対応付けられた上りリソースを用いて、最後尾のサブフレームから所定数のサブフレーム後に、下りリンクデータに対する応答信号（ACK/NACK信号）を受信する。【0042】
また、図６は、本開示の各実施の形態に係る端末２００の要部構成を示すブロック図である。図６に示す端末２００において、受信部２０２は、MTC端末向けの狭帯域（MTC狭帯域）内の下りリソースを用いて、同一の下りリンクデータを１つ又は複数のサブフレームに渡って受信する。応答信号生成部２１０は、下りリンクデータに対する応答信号（ACK/NACK信号）を生成する。送信部２１７は、１つ又は複数のサブフレームの最後尾サブフレームにおいて下りリンクデータが割り当てられた下りリソースの番号に１対１で対応付けられた上りリソースを用いて、最後尾サブフレームから所定数のサブフレーム後に応答信号を送信する。【0044】
基地局１００は、下りリンクにてMPDCCH及びPDSCH（下りリンクデータ）を送信する。また、基地局１００は、上りリンクにてACK/NACK信号を運ぶPUCCHを受信する。ここでは、説明が煩雑になることを避けるために、本実施の形態の特徴と密接に関連する下りリンクのMPDCCH、PDSCHの送信及びその下りリンクデータに対するPUCCHの上りリンクでの受信に係わる構成部を主に示している。【0045】
また、基地局１００において生成される下りリンクの制御信号（リソース割当情報）とデータ信号（送信データ）は、後述するように、それぞれ個別に符号化及び変調される。【0046】
図７において、基地局１００は、制御部１０１と、制御信号生成部１０２と、制御信号符号化部１０３と、制御信号変調部１０４と、データ符号化部１０５と、再送制御部１０６と、データ変調部１０７と、信号割当部１０８と、IFFT（Inverse Fast Fourier Transform）部１０９と、CP（Cyclic Prefix）付加部１１０と、送信部１１１と、アンテナ１１２と、受信部１１３と、CP除去部１１４と、PUCCH抽出部１１５と、合成部１１６と、デマッピング部１１７と、チャネル推定部１１８と、等化部１１９と、逆拡散部１２０と、相関処理部１２１と、判定部１２２と、を有する。【0047】
制御部１０１は、MTC端末に対してPDSCHの割当を決定する。このとき、制御部１０１は、MTC端末に対して指示する周波数割当リソース及び変調・符号化方法などを決定し、決定したパラメータに関する情報を制御信号生成部１０２に出力する。【0048】
また、制御部１０１は、制御信号に対する符号化レベルを決定し、決定した符号化レベルを制御信号符号化部１０３に出力する。また、制御部１０１は、制御信号及び下りリンクデータをマッピングする無線リソース（下りリソース）を決定し、決定した無線リソースに関する情報を信号割当部１０８に出力する。また、制御部１０１は、リソース割当対象端末２００に対して、下りリンクデータ（送信データ）を送信する際に用いる符号化率を決定し、決定した符号化率をデータ符号化部１０５へ出力する。【0049】
また、制御部１０１は、MTC端末のカバレッジ拡張レベル（又はレピティション回数）を決定し、決定したカバレッジ拡張レベルに関する情報を、制御信号生成部１０２及び合成部１１６に出力する。【0050】
また、制御部１０１は、端末２００がPUCCHを送信するPUCCHリソース（巡回シフト、直交符号系列、周波数）を決定する。例えば、制御部１０１は、PDSCHが送信される１つ又は複数のサブフレームの最後尾サブフレームにおいて当該PDSCHが割り当てられたPRBの番号に１対１で対応付けられたPUCCHリソースを特定する。制御部１０１は、PUCCH送信に用いられている可能性がある巡回シフト量（つまり、ZAC系列）及び直交符号系列を、逆拡散部１２０及び相関処理部１２１へそれぞれ出力し、PUCCH送信に使用される周波数リソースに関する情報をPUCCH抽出部１１５へ出力する。【0051】
制御信号生成部１０２は、MTC端末向けの制御信号を生成する。制御信号には、セル固有の上位レイヤの信号、端末固有の上位レイヤの信号、又は、MPDCCHを用いてPDSCHの割当を指示する下りリンク割当情報が含まれる。下りリンク割当情報は、複数のビットから構成されており、周波数割当リソース、変調・符号化方式などを指示する情報を含む。また、下りリンク割当情報には、カバレッジ拡張レベルに関する情報も含まれてもよい。【0052】
制御信号生成部１０２は、制御部１０１から入力される制御情報を用いて、制御情報ビット列を生成し、生成した制御情報ビット列（制御信号）を制御信号符号化部１０３へ出力する。なお、制御情報が複数の端末２００向けに送信されることもあるため、制御信号生成部１０２は、各端末２００向けの制御情報に、各端末２００の端末IDを含めてビット列を生成する。例えば、制御情報には、宛先端末の端末IDによってマスキングされたCRC（Cyclic Redundancy Check）ビットが付加される。【0053】
また、カバレッジ拡張レベルに関する情報は、端末固有の上位レイヤのシグナリングによりMTCカバレッジ拡張端末へ通知されてもよく、上述したようにMPDCCHを用いて通知されてもよい。【0054】
制御信号符号化部１０３は、制御部１０１から指示された符号化レベルに従って、制御信号生成部１０２から受け取る制御信号（制御情報ビット列）を符号化し、符号化後の制御信号を制御信号変調部１０４へ出力する。【0055】
制御信号変調部１０４は、制御信号符号化部１０３から受け取る制御信号を変調し、変調後の制御信号（シンボル列）を信号割当部１０８へ出力する。【0056】
データ符号化部１０５は、制御部１０１から受け取る符号化率に従って、送信データ（下りリンクデータ）に対してターボ符号などの誤り訂正符号化を施し、符号化後のデータ信号を再送制御部１０６へ出力する。【0057】
再送制御部１０６は、初回送信時には、データ符号化部１０５から受け取る符号化後のデータ信号を保持するとともにデータ変調部１０７へ出力する。再送制御部１０６は、符号化後のデータ信号を宛先端末毎に保持する。また、再送制御部１０６は、送信したデータ信号に対するNACKを判定部１２２から受け取ると、対応する保持データをデータ変調部１０７へ出力する。再送制御部１０６は、送信したデータ信号に対するACKを判定部１２２から受け取ると、対応する保持データを削除する。【0058】
データ変調部１０７は、再送制御部１０６から受け取るデータ信号を変調して、データ変調信号を信号割当部１０８へ出力する。【0059】
信号割当部１０８は、制御信号変調部１０４から受け取る制御信号（シンボル列）及びデータ変調部１０７から受け取るデータ変調信号を、制御部１０１から指示される無線リソースにマッピングする。なお、制御信号がマッピングされる対象となる制御チャネルはMPDCCHである。信号割当部１０８は、制御信号又はデータ変調信号がマッピングされた下りリンクサブフレームの信号をIFFT部１０９に出力する。【0060】
IFFT部１０９は、信号割当部１０８から受け取る信号に対してIFFT処理を行うことにより、周波数領域信号を時間領域信号に変換する。IFFT部１０９は、時間領域信号をCP付加部１１０へ出力する。【0061】
CP付加部１１０は、IFFT部１０９から受け取る信号に対してCPを付加し、CP付加後の信号（OFDM信号）を送信部１１１へ出力する。【0062】
送信部１１１は、CP付加部１１０から受け取るOFDM信号に対してD/A（Digital-to-Analog）変換、アップコンバート等のRF（Radio Frequency）処理を行い、アンテナ１１２を介して端末２００に無線信号を送信する。【0063】
受信部１１３は、アンテナ１１２を介して受信された端末２００からの上りリンク信号（PUCCH）に対して、ダウンコンバート又はA/D（Analog-to-Digital）変換などのRF処理を行い、得られる受信信号をCP除去部１１４に出力する。例えば、端末２００から送信される上りリンク信号（PUCCH）には、複数のサブフレームに渡るレピティション処理された信号が含まれる。【0064】
CP除去部１１４は、受信部１１３から受け取る受信信号に付加されているCPを除去し、CP除去後の信号をPUCCH抽出部１１５へ出力する。【0065】
PUCCH抽出部１１５は、制御部１０１から受け取るPUCCHリソースに関する情報に基づいて、CP除去部１１４から受け取る信号に対してFFT処理を適用し、周波数領域の信号系列に分解して、PUCCHに対応する信号を抽出し、抽出したPUCCH信号を合成部１１６へ出力する。【0066】
合成部１１６は、制御部１０１から入力される、カバレッジ拡張レベルに関する情報（又はレピティション回数に関する情報）を用いて、レピティション送信された複数サブフレームに渡るPUCCHを合成し、合成後の信号をデマッピング部１１７へ出力する。【0067】
デマッピング部１１７は、合成部１１６から受け取る信号（PUCCHのサブフレーム部分）を、参照信号と応答信号とに分解し、参照信号をチャネル推定部１１８に出力し、応答信号を等化部１１９に出力する。【0068】
チャネル推定部１１８は、デマッピング部１１７から入力される参照信号を用いてチャネル推定を行う。チャネル推定部１１８は、得られたチャネル推定値を等化部１１９に出力する。【0069】
等化部１１９は、チャネル推定部１１８から入力されるチャネル推定値を用いて、デマッピング部１１７から入力される応答信号の等化を行う。等化部１１９は、等化後の応答信号を逆拡散部１２０へ出力する。【0070】
逆拡散部１２０は、制御部１０１から受け取る直交符号系列（端末２００が用いるべき直交符号系列）を用いて、等化部１１９から受け取る信号のうち応答信号に相当する部分の信号を逆拡散し、逆拡散後の信号を相関処理部１２１に出力する。【0071】
相関処理部１２１は、制御部１０１から入力されるZAC系列（端末２００が用いる可能性のあるZAC系列。巡回シフト量）と、逆拡散部１２０から入力される信号との相関値を求めて、相関値を判定部１２２に出力する。【0072】
判定部１２２は、相関処理部１２１から受け取る相関値に基づいて、端末２００から送信された応答信号が、送信されたデータに対してACK又はNACKのいずれかを示しているかを判定する。判定部１２２は、判定結果を再送制御部１０６に出力する。【0074】
端末２００は、下りリンクにてMPDCCH及びPDSCH（下りリンクデータ）を受信する。また、端末２００は、上りリンクにてACK/NACK信号を運ぶPUCCHを送信する。ここでは、説明が煩雑になることを避けるために、本実施の形態の特徴と密接に関連する下りリンクのMPDCCH、PDSCHの受信及びその下りリンクデータに対するPUCCHの上りリンクでの送信に係わる構成部を主に示している。【0075】
また、端末２００が受信する下りリンクの制御信号（リソース割当情報）とデータ信号（送信データ）は、それぞれ個別に符号化及び変調が施されている。【0076】
図８において、端末２００は、アンテナ２０１と、受信部２０２と、CP除去部２０３と、FFT部２０４と、抽出部２０５と、データ復調部２０６と、データ復号部２０７と、CRC部２０８と、制御部２０９と、応答信号生成部２１０と、変調部２１１と、拡散部２１２と、レピティション部２１３と、信号割当部２１４と、IFFT部２１５と、CP付加部２１６と、送信部２１７と、を有する。【0077】
受信部２０２は、アンテナ２０１を介して受信された、基地局１００からの無線信号（MPDCCH又EPDCCH）に対してダウンコンバート又はAD変換などのRF処理を行い、ベースバンドのOFDM信号を得る。受信部２０２は、OFDM信号をCP除去部２０３へ出力する。【0078】
CP除去部２０３は、受信部２０２から受け取るOFDM信号に付加されているCPを除去し、CP除去後の信号をFFT部２０４へ出力する。【0079】
FFT部２０４は、CP除去部２０３から受け取る信号に対してFFT処理を行うことにより、時間領域信号を周波数領域信号に変換する。FFT部２０４は、周波数領域信号を抽出部２０５へ出力する。【0080】
抽出部２０５は、FFT部２０４から受け取る周波数領域信号からMPDCCHを抽出する。抽出部２０５は、MPDCCHに対してブラインド復号を行い、自機宛ての制御信号の復号を試みる。端末２００宛ての制御信号には、端末２００の端末IDによってマスキングされたCRCが付加されている。したがって、抽出部２０５は、ブラインド復号した結果、CRC判定がOKであればその制御情報を抽出して制御部２０９へ出力する。また、抽出部２０５は、FFT部２０４から受け取る信号から、下りリンクデータ（PDSCH信号）を抽出してデータ復調部２０６へ出力する。【0081】
データ復調部２０６は、抽出部２０５から受け取る下りリンクデータを復調し、復調後の下りリンクデータをデータ復号部２０７へ出力する。【0082】
データ復号部２０７は、データ復調部２０６から受け取る下りリンクデータを復号し、復号後の下りリンクデータをCRC部２０８へ出力する。【0083】
CRC部２０８は、データ復号部２０７から受け取る下りリンクデータに対して、CRCを用いて誤り検出を行い、誤り検出結果を応答信号生成部２１０へ出力する。また、CRC部２０８は、誤り検出の結果、誤りなしと判定した下りリンクデータを受信データとして出力する。【0084】
制御部２０９は、抽出部２０５から入力される制御信号に基づいて、PUCCH送信の制御を行う。具体的には、制御部２０９は、PUCCHリソースの特定に必要な情報を用いて、PUCCHリソース（周波数、巡回シフト量及び直交符号系列）を特定し、特定した情報を拡散部２１２及び信号割当部２１４へ出力する。例えば、制御部２０９は、PDSCHを受信した１つ又は複数のサブフレームの最後尾サブフレームにおいて当該PDSCHが割り当てられたPRBの番号に１対１で対応付けられたPUCCHリソースを特定する。【0085】
また、制御部２０９は、カバレッジ拡張レベルに関する情報に関する情報が制御信号に含まれる場合、その情報に基づいて、PUCCHレピティション送信時のレピティション回数を決定し、決定したレピティション回数を示す情報を、レピティション部２１３に指示する。【0086】
また、制御部２０９は、カバレッジ拡張レベルに関する情報が上位レイヤで基地局１００から通知される場合、通知された情報に基づいてPUCCHレピティション送信時のレピティション回数を決定し、決定した情報をレピティション部２１３に指示する。【0087】
応答信号生成部２１０は、CRC部２０８から受け取る誤り検出結果に基づいて、受信した下りリンクデータ（PDSCH信号）に対するACK/NACK信号（応答信号）を生成する。具体的には、応答信号生成部２１０は、誤りが検出された場合にはNACKを生成し、誤りが検出されない場合にはACKを生成する。応答信号生成部２１０は、生成したACK/NACK信号を変調部２１１へ出力する。【0088】
変調部２１１は、応答信号生成部２１０から受け取るACK/NACK信号を変調して、変調後のACK/NACK信号を拡散部２１２へ出力する。【0089】
拡散部２１２は、制御部２０９によって設定された巡回シフト量で定義されるZAC系列を用いて、参照信号、及び、変調部２１１から受け取るACK/NACK信号を１次拡散する。また、拡散部２１２は、制御部２０９によって設定された直交符号系列を用いてACK/NACK信号及び参照信号を２次拡散し、２次拡散後の信号をレピティション部２１３へ出力する。【0090】
レピティション部２１３は、自端末がMTCカバレッジ拡張モードの場合、制御部２０９から指示されたレピティション回数に基づいて、拡散部２１２から入力される信号を複数のサブフレームに渡ってレピティションし、レピティション信号を生成する。レピティション部２１３は、レピティション信号を信号割当部２１４へ出力する。【0091】
信号割当部２１４は、レピティション部２１３から受け取る信号を、制御部２０９から指示されるPUCCHの時間・周波数リソースに基づいてマッピングする。信号割当部２１４は、信号がマッピングされたPUCCHの信号をIFFT部２１５に出力する。【0092】
IFFT部２１５は、信号割当部２１４から入力される周波数領域のPUCCH信号に対してIFFT処理を行うことにより時間領域信号を生成する。IFFT部２１５は、生成した信号をCP付加部２１６へ出力する。【0093】
CP付加部２１６は、IFFT部２１５から受け取る時間領域信号に対してCPを付加し、CP付加後の信号を送信部２１７へ出力する。【0094】
送信部２１７は、CP付加部２１６から受け取る信号に対してD/A変換、アップコンバート等のRF処理を行い、アンテナ２０１を介して基地局１００に無線信号を送信する。【0095】
［基地局１００及び端末２００の動作］以上の構成を有する基地局１００及び端末２００の動作について詳細に説明する。
【0096】
以下の説明では、基地局１００は、既存のLTEシステム帯域（例えば20MHz）で既存のLTE端末と通信を行うとともに、図９に示すようにMTC端末向けのMTC狭帯域（例えば1.4MHz）を用いてMTC端末（端末２００）と通信を行う場合を例に挙げて説明する。なお、MTC狭帯域は、システム帯域内において、サブフレーム毎に同一の位置に配置されてもよく、サブフレーム毎に異なる位置に配置されてもよい。【0097】
基地局１００は、MTC狭帯域内の所定の周波数領域にMPDCCHを配置する。基地局１００は、報知信号を介してMTC端末にMPDCCHが配置されるMTC狭帯域の位置を通知してもよい。また、MPDCCHが配置されるMTC狭帯域の位置が予め定められた構成でもよく、この場合、基地局１００からMTC端末へMPDCCHが配置されるMTC狭帯域の位置に関する情報を通知する処理を省略することができる。【0098】
基地局１００は、各サブフレームにおいてデータを割り当てる端末２００を決定し、MTC狭帯域内のPDSCHにスケジューリングする。基地局１００は、スケジューリング結果を含む制御情報を各端末２００宛に生成し、制御情報をMPDCCHにマッピングする。その後、基地局１００は、MTC端末に対してMPDCCHの制御情報、及び、PDSCHの下りリンクデータを送信する。【0099】
また、以下の説明では、各端末２００（MTC端末）に対して設定されたカバレッジ拡張レベルに基づいて各チャネル（MPDCCH、PDSCH、及び、PUCCH）の信号のレピティション送信が行われる。【0100】
また、各端末２００に対して、MPDCCHとPDSCHとが同一サブフレームにマッピングされる同一サブフレームスケジューリング又はMPDCCHとPDSCHとが異なるサブフレームにマッピングされるクロスサブフレームスケジューリングの何れかが適用される。【0101】
端末２００は、MPDCCHのブラインド復号によって得られた制御情報に基づいて、PDSCHに割り当てられたデータ信号の抽出及び復号を行う。また、端末２００は、制御情報に含まれるPDSCHのスケジューリング結果（PDSCHの割当リソース）に基づいて、受信データ（PDSCH）に対応するACK/NACK信号を送信するPUCCHリソース（符号及び周波数リソース）を特定する。そして、端末２００は、特定したPUCCHリソースを用いてPUCCH（ACK/NACK信号）を送信する。【0102】
ここでは、ACK/NACK信号が送信される送信タイミングは、端末２００がPDSCH信号を受信したサブフレームから、KMTCサブフレーム後（例えば、KMTC＝４サブフレーム）とする。なお、PDSCHがレピティション送信される場合には、PDSCHがレピティション送信される複数のサブフレームのうち最後尾のサブフレームから、KMTCサブフレーム後にACK/NACK信号が送信されるものとする。【0103】
上述したように、複数のMTC端末に対するカバレッジ拡張レベル（MPDCCH又はPDSCHに対するレピティション回数）が異なる場合（例えば、図３を参照）、又は、各MTC端末に適用されるスケジューリング方法（同一サブフレームスケジューリング又はクロスサブフレームスケジューリング）が異なる場合（例えば、図４Ａを参照）には、同一サブフレームで送信されるPUCCHに対応するMPDCCHの送信タイミングがMTC端末間で異なる場合がある。このため、従来のようにMPDCCHにおいてリソース割当情報の送信に用いられたリソース（ECCE）とPUCCHリソースとを１対１で対応付ける方法では、MTC端末間においてPUCCHリソースが衝突する場合があった。【0104】
これに対して、本実施の形態では、MTC端末においてACK/NACK信号の送信に用いられるPUCCHリソースは、当該ACK/NACK信号に対する下りリンクデータ（PDSCH）の送信に用いられた下りリソース（PRB）と１対１で対応付けられる。より具体的には、本実施の形態では、MTC端末においてACK/NACK信号の送信に用いられるPUCCHリソースは、当該ACK/NACK信号に対するPDSCHのレピティションが行われる複数のサブフレームのうちの最後尾のサブフレームにおいてPDSCHが割り当てられたPRBのPRB番号と１対１で対応付けられる。【0105】
例えば、本実施の形態では、端末２００は、次式（数３）に従って、PUCCHリソースを特定する。【0106】
【数3】
【0107】
ここで、nPUCCH,MTCはACK/NACK信号の送信に用いられるPUCCHリソース番号である。NPUCCH,MTCはセル内のMTC端末に共通に与えられるPUCCHリソースオフセット値を表し、nPRBは、MTC狭帯域を構成するPRBにおける、当該MTC端末に対するPDSCHレピティションの最後尾のサブフレームにおいてPDSCHがマッピングされたPRBのうち、インデックスが最も小さいPRB番号を表す。【0108】
このようにして端末２００は、データ信号の判定結果に応じてACK又はNACKを特定し、上記のように特定したPUCCHリソースを用いてACK/NACK信号を送信する。つまり、端末２００は、１つ又は複数のサブフレームの最後尾サブフレームにおいてPDSCHが割り当てられたPRBのPRB番号（インデックスが最も小さいPRB番号）に１対１で対応付けられたPUCCHリソースを用いて、上記最後尾サブフレームから所定数のサブフレーム後にACK/NACK信号を送信する。【0109】
一方、基地局１００は、MTC端末に対してレピティション送信したPDSCHがマッピングされた複数のサブフレームのうちの最後尾のサブフレームにおいて当該PDSCHが割り当てられたPRBのPRB番号から、当該PDSCHに対するACK/NACK信号がMTC端末から送信されるPUCCHリソースを特定する。そして、基地局１００は、特定したPUCCHリソースを用いて、端末２００から送信されるACK/NACK信号を受信する。つまり、基地局１００は、PDSCHを送信した１つ又は複数のサブフレームの最後尾サブフレームにおいて当該PDSCHが割り当てられたPRBのPRB番号（インデックスが最も小さいPRB番号）に１対１で対応付けられたPUCCHリソースを用いて、上記最後尾のサブフレームから所定数のサブフレーム後に、PDSCHに対するACK/NACK信号を受信する。【0110】
上述したように、PUCCHにマッピングされるACK/NACK信号は、PDSCHが送信される１つ又は複数のサブフレームのうち最後尾のサブフレームから、KMTCサブフレーム後のサブフレームで送信される。つまり、同一サブフレームでPUCCHを送信する複数のMTC端末間では、PDSCHが送信される最後尾のサブフレームは同じである。換言すると、同一サブフレームでPUCCHを送信する複数のMTC端末間では、PUCCHの送信タイミングとPDSCHの最後尾のサブフレームとの差（タイミング差）は同じである（つまり、KMTCサブフレーム）。【0111】
ここで、同一サブフレームにおいて各MTC端末に対するPDSCHのリソースが重複してスケジューリングされることはない。つまり、同一サブフレームでスケジューリングされる各MTC端末に対するPDSCHのリソース（PRB）は必ず異なる。よって、複数のMTC端末に対して送信されるPDSCHがマッピングされたサブフレームのうちの最後尾のサブフレームが同一タイミングである場合には、当該サブフレームにおいて各MTC端末に対してPDSCHに割り当てられるPRBのPRB番号は必ず異なる。【0112】
以上より、PDSCHの最後尾のサブフレームにおいてPDSCHに割り当てられたPRBのPRB番号と、当該PDSCHに対するACK/NACK信号の送信に用いられるPUCCHリソースとを１対１で対応付けることにより、カバレッジ拡張レベル又はスケジューリング方法がMTC端末間で異なる場合でも、同一サブフレームにおいてPUCCHリソースが衝突することを回避することができる。【0114】
まず、図１０は、端末１に対して、MPDCCHのレピティション回数=4、MPDSCHのレピティション回数=4、PUCCHのレピティション回数=4であり、端末２に対して、MPDCCHのレピティション回数=2、MPDSCHのレピティション回数=2、PUCCHのレピティション回数=2である場合の一例を示す。つまり、図１０では、端末１と端末２とでカバレッジ拡張レベルが異なる。【0115】
図１０では、図３と同様、基地局１００は、端末１及び端末２（端末２００）の各々に対して異なるサブフレームを用いてMPDCCHを送信している。その際、基地局１００は、MPDCCHにおいて、端末１及び端末２に対して同一のEPDCCH set及びECCEを用いて制御情報を送信している。【0116】
また、図１０に示すように、端末１及び端末２に対して割り当てられたPDSCHの最後尾のサブフレームは同一である。つまり、端末１及び端末２がACK/NACK信号を送信するタイミング（PDSCHの送信タイミングのKMTCサブフレーム後）は同一である。【0117】
ただし、図１０では、端末１及び端末２がACK/NACK信号の送信に用いるPUCCHリソースは、端末１及び端末２に対して割り当てられたPDSCHの最後尾のサブフレームに割り当てられたPRBのPRB番号に１対１で対応付けられている。そして、図１０に示すように、端末１及び端末２のPDSCHの最後尾のサブフレームが同一であるので、当該最後尾のサブフレームでは、端末１及び端末２に対して異なるPRBが割り当てられている。よって、図１０では、端末１及び端末２がACK/NACK信号の送信に用いるPUCCHリソースは、異なるPRBに対応付けられた異なるリソースである。【0118】
これにより、図１０では、端末１及び端末２は、異なるサブフレームにおいて同一のEPDCCH set及びECCEを用いてMPDCCH（制御情報）を受信し、かつ、同一タイミングにおいてPUCCHを送信するものの、端末１及び端末２の各々が用いるPUCCHリソースの衝突は発生しない。【0119】
次に、図１１Ａ及び図１１Ｂは、端末１に対してクロスサブフレームスケジューリングが適用され、端末２に対して同一サブフレームスケジューリングが適用される場合のリソース割当の一例を示す。つまり、図１１Ａ及び図１１Ｂでは、端末１と端末２とでスケジューリング方法が異なる。【0120】
図１１Ａでは、図４Ａと同様、基地局１００は、端末１及び端末２に対して、それぞれ異なるサブフレームを用いてMPDCCHを送信している。その際、基地局１００は、MPDSCCHにおいて、端末１及び端末２に対して同一のEPDCCH set及びECCEを用いて制御情報を送信している。【0121】
また、図１１Ａに示すように、端末１及び端末２に対して割り当てられたPDSCHの最後尾のサブフレームは同一である。つまり、端末１及び端末２がACK/NACK信号を送信するタイミング（PDSCHの送信タイミングのKMTCサブフレーム後）は同一である。【0122】
ただし、図１１Ａでは、図１０と同様、端末１及び端末２がACK/NACK信号の送信に用いるPUCCHリソースは、端末１及び端末２に対して割り当てられたPDSCHの最後尾のサブフレームに割り当てられたPRBのPRB番号に１対１で対応付けられている。そして、図１１Ａに示すように、端末１及び端末２のPDSCHの最後尾のサブフレームが同一であるので、当該最後尾のサブフレームでは、端末１及び端末２に対して異なるPRBが割り当てられている。よって、図１１Ａでは、端末１及び端末２がACK/NACK信号の送信に用いるPUCCHリソースは、異なるPRBに対応付けられた異なるリソースである。【0123】
これにより、図１１Ａでは、端末１及び端末２は、異なるサブフレームにおいて同一のEPDCCH set及びECCEを用いてMPDCCH（制御情報）を受信し、かつ、同一タイミングにおいてPUCCHを送信するものの、端末１及び端末２の各々が用いるPUCCHリソースの衝突は発生しない。【0124】
以上のように、本実施の形態では、PDSCHレピティションの最後尾のサブフレームにおいてPDSCH（PDSCHレピティションが適用されない場合には単純にPDSCH）がマッピングされるPRBのPRB番号と、当該PDSCHに対するACK/NACK信号がマッピングされるPUCCHリソースとが１対１で対応付けられる。これにより、複数のMTC端末における、カバレッジ拡張レベルの違い又はスケジューリング方法（同一サブフレームスケジューリング又クロスサブフレームスケジューリング）の違いによるPUCCHリソースの衝突を回避することができる。【0125】
よって、本実施の形態によれば、MTCにおけるACK/NACK信号を送信するPUCCHリソースの特定方法に関して、複数のMTC端末が異なるサブフレームで同一のEPDCCH set及びECCEを用いて制御情報を送信した場合のPUCCHリソースの衝突の影響を低減できるので、MPDCCHのブロッキング確率の増加を抑え、スループットの劣化を防ぐことができる。【0126】
また、（数式３）におけるPUCCHリソースオフセット値（NPUCCH,MTC）はMTC用の報知信号（MTC SIBなど）を用いて基地局１００からMTC端末に通知される情報である。よって、端末２００は、既存のLTEシステムのPDCCHに割り当てられた制御情報を復調できないものの、PUCCHリソースの特定に必要なパラメータを初期接続処理前に得ることができる。そのため、端末２００は、初期接続処理の過程で基地局１００がPDSCHを用いて端末２００に送信するMsg4に対するACK/NACK信号を送信するPUCCHリソースについても特定することができる。【0127】
以上のように、本実施の形態によれば、MTC端末において適切にPUCCHリソースを特定することができる。【0128】
（バリエーション１）上記実施の形態では、図９に示すようにシステム帯域内に１つのMTC狭帯域が存在する場合について説明した。しかし、システム帯域（例えば、20MHz）内に配置されるMTC狭帯域は２つ以上であってもよい。
【0129】
MTC狭帯域が２つ以上設定される場合、複数のMTC狭帯域においてPRB番号がそれぞれ独立に定義されることがある。この場合、異なるMTC狭帯域間で同一のPRB番号を用いてPDSCHが送信されると、当該PDSCHの送信に用いられたPRB番号に対応付けられたPUCCHリソースが衝突してしまう。【0130】
このように、複数のMTC狭帯域間のPUCCHリソースの衝突も考慮する必要がある。そこで、バリエーション１では、システム帯域内に配置されるMTC狭帯域が複数存在する場合のPUCCHリソースの割当方法について説明する。【0131】
例えば、基地局１００は、既存のLTEシステム周波数帯域（例えば20MHz）で既存のLTE端末と通信を行うとともに、図１２に示すように２つのMTC狭帯域（例えば1.4MHz）を用いて、２つのMTC端末（端末２００）とそれぞれ通信を行う場合を例に挙げて説明する。なお、MTC狭帯域の数は２個に限定されず、３個以上でもよい。また、各MTC狭帯域は、システム帯域内において、サブフレーム毎に同一の位置に配置されてもよく、サブフレーム毎に異なる位置に配置されてもよい。【0132】
例えば、バリエーション１では、端末２００は、PRB番号に加えて、MTC狭帯域番号を用いて、次式（数４）に従って、PUCCHリソースを特定する。【0133】
【数4】
【0134】
ここで、nPUCCH,MTCはACK/NACK信号の送信に用いられるPUCCHリソース番号である。NPUCCH,MTCはセル内のMTC端末に共通に与えられるPUCCHリソースオフセット値を表し、nPRBはMTC狭帯域を構成するPRBにおける、当該MTC端末に対するPDSCHレピティションの最後尾のサブフレームにおいてPDSCHがマッピングされたPRBのうち、インデックスが最も小さいPRB番号を表す。nPRBは複数のMTC狭帯域の各々において同一の値を採りうる。【0135】
また、nNBは当該端末に対するPDSCHレピティションの最後尾のサブフレームにおいてPDSCHがマッピングされたMTC狭帯域の番号を表す。【0136】
また、式（４）に示す数値「6」は各MTC狭帯域を構成するPRB数を示す。この数値は、MTC狭帯域を構成するPRB数に応じて変更されてもよい。【0137】
図１３は、バリエーション１におけるPDSCHリソース（PRB）とPUCCHリソースとの対応付けの一例を示している。図１３では、NPUCCH,MTC=4としている。また、MTC狭帯域#0（nNB＝0）、MTC狭帯域#1（nNB＝1）には、それぞれ個別にPRB番号#0〜#5が設定されている。【0138】
例えば、式（４）に従って、MTC狭帯域#0のPRB#0には、nPUCCH,MTC=4（＝(0+6・0)+4）のPUCCHリソースが対応付けられる。同様に、MTC狭帯域#0のPRB#1〜#5には、nPUCCH,MTC=5〜9のPUCCHリソースが対応付けられる。【0139】
また、式（４）に従って、MTC狭帯域#1のPRB#0には、nPUCCH,MTC=10（＝(0+6・1)+4）のPUCCHリソースが対応付けられる。同様に、MTC狭帯域#1のPRB#1〜#5には、nPUCCH,MTC=11〜15のPUCCHリソースが対応付けられる。【0140】
このように、バリエーション１では、PDSCHのPRB番号とMTC狭帯域番号とからImplicitにPUCCHリソースを特定することができ、かつ、複数のMTC狭帯域にそれぞれマッピングされるPDSCHリソースに対応付けられるPUCCHリソースの衝突を回避することができる。【0141】
（バリエーション２）バリエーション２では、システム帯域内に配置されるMTC狭帯域が複数存在する場合において、バリエーション１と異なるPUCCHリソースの割当方法について説明する。
【0142】
例えば、基地局１００は、既存のLTEシステム周波数帯域（例えば20MHz）で既存のLTE端末と通信を行うとともに、図１２に示すように２つのMTC狭帯域（例えば1.4MHz）を用いて、２つのMTC端末（端末２００）とそれぞれ通信を行う場合を例に挙げて説明する。なお、MTC狭帯域の数は２個に限定されず、３個以上でもよい。また、各MTC狭帯域は、システム帯域内において、サブフレーム毎に同一の位置に配置されてもよく、サブフレーム毎に異なる位置に配置されてもよい。【0143】
例えば、バリエーション２では、端末２００は、PRB番号に加えて、MTC狭帯域毎のPUCCHリソースオフセットを用いて、次式（数５）に従って、PUCCHリソースを特定する。【0144】
【数5】
【0145】
ここで、nPUCCH,MTCはACK/NACK信号の送信に用いられるPUCCHリソース番号である。nPRBはMTC狭帯域を構成するPRBにおける、当該MTC端末に対するPDSCHレピティションの最後尾のサブフレームにおいてPDSCHがマッピングされたPRBのうち、インデックスが最も小さいPRB番号を表す。nPRBは複数のMTC狭帯域の各々において同一の値を採りうる。【0146】
また、NPUCCH,NB(n)はn番目のMTC狭帯域に対応するPUCCHリソースオフセット値を表す。このPUCCHリソースオフセット値は、例えば、MTC用の報知信号(MTC SIBなど)を用いて基地局１００からMTC端末に通知される情報である。【0147】
図１４は、バリエーション２におけるPDSCHリソース（PRB）とPUCCHリソースとの対応付けの一例を示している。図１４では、第１番目（n=1）のMTC狭帯域に対応するPUCCHリソースオフセット値NPUCCH,NB(0)=4とし、第２番目（n=2）のMTC狭帯域に対応するPUCCHリソースオフセット値NPUCCH,NB(1)=8とする。【0148】
例えば、（数式５）に従って、MTC狭帯域#0のPRB#0には、nPUCCH,MTC=4（＝0+4）のPUCCHリソースが対応付けられる。同様に、MTC狭帯域#0のPRB#1〜#5には、nPUCCH,MTC=5〜9のPUCCHリソースが対応付けられる。【0149】
また、（数式５）に従って、MTC狭帯域#1のPRB#0には、nPUCCH,MTC=8（＝0+8）のPUCCHリソースが対応付けられる。同様に、MTC狭帯域#1のPRB#1〜#5には、nPUCCH,MTC=9〜13のPUCCHリソースが対応付けられる。【0150】
このように、バリエーション２では、MTC狭帯域に対するPUCCHリソースオフセット値をMTC狭帯域毎に調整することができる。また、バリエーション１では、MTC狭帯域を構成するPRB数をMTC狭帯域間で同じ値にする必要があったが、バリエーション２では、MTC狭帯域を構成するPRB数をMTC狭帯域毎に異なる値にしてもよい。【0151】
なお、PUCCHリソースオフセットを十分大きな値とすることで複数のMTC狭帯域に対応するPUCCH領域がそれぞれ重複しないよう運用できる一方で、使用するMTC狭帯域の数に応じて確保するPUCCHリソース総量が増え、PUCCHオーバヘッドが増加してしまう。反対に、PUCCHリソースオフセットを調節し、複数のPUCCH領域が重複するよう運用することもできる（例えば、図１４を参照）。この場合、確保すべきPUCCHリソース総量を低減できる。ただし、PUCCH領域が重複するMTC狭帯域間で使用するPUCCHリソースが衝突する可能性がある。このようなPUCCHリソースの衝突が起こる場合には、何れか１つのMTC狭帯域のみしか割り当てできないため、下りスループットが劣化してしまう。そこで、複数のPUCCH領域を重複して運用しつつ、PUCCHリソースの衝突を回避する方法として、MPDCCHの制御情報内に更なるオフセットを通知するAROを追加することもできる。【0153】
本実施の形態に係る通信システムは、セル内の１つの基地局１００と複数の端末２００（MTC端末）とから構成される。【0154】
セル内のMTC端末は、非常に多くのレピティション送信を必要とする（カバレッジ拡張レベルの大きい）MTC端末であることを想定する。なお、MTC端末は、既存のLTEシステムの帯域幅と比較して、より狭いMTC帯域幅（例えば、1.4MHZ）をサポートする。【0155】
ここで、カバレッジ拡張レベルの大きいMTC端末に対する下りリンク送信では、所要のレピティション回数を削減するために、基地局１００は、MTC狭帯域内の6PRBの全てを用いて制御信号又はデータ信号を送信することが考えられる。【0156】
このため、実施の形態１のようにPRB番号に１対１で対応付けたPUCCHリソースの特定方法では、PUCCHリソースを効率良く用いることができない。例えば、実施の形態１の式（４）において、MTC狭帯域#0のPRB#0〜#5に対しては、PUCCHリソース#0〜#5が対応付けられる（ただし、NPUCCH,MTC=0とする）。しかし、カバレッジ拡張レベルの大きい１つのMTC端末に対しては、MTC狭帯域#0のPRB#0〜#5の全てを占有することが想定されるため、PUCCHリソース#0（最小のPRB#0に対応付けられたPUCCHリソース）のみが使用され、他のPUCCH#1〜#5が使用されることはない。【0157】
以上から、カバレッジ拡張レベルの大きい（例えば、レピティション回数が所定数以上の）MTC端末に対しては、PRB番号単位でPUCCHリソースを対応付けて確保することはリソース利用効率の観点から非効率と言える。そこで、本実施の形態では、カバレッジ拡張レベルの大きいMTC端末に対しては、MTC狭帯域単位でPUCCHリソースを対応付けて確保する。【0158】
例えば、本実施の形態では、端末２００は、MTC狭帯域番号を用いて、次式（数６）に従って、PUCCHリソースを特定する。【0159】
【数6】
【0160】
ここで、nPUCCH,MTCはACK/NACK信号の送信に用いられるPUCCHリソース番号である。NPUCCH,MTCはセル内のMTC端末に共通に与えられるPUCCHリソースオフセット値を表す。また、nNBは当該端末に対するPDSCHレピティションの最後尾のサブフレームにおいてPDCCHがマッピングされたMTC狭帯域の番号を表す。【0161】
図１５は、本実施の形態におけるPDSCHリソース（PRB）とPUCCHリソースとの対応付けの一例を示している。図１５では、NPUCCH,MTC=0としている。また、MTC狭帯域#0（nNB＝0）、MTC狭帯域#1（nNB＝1）には、それぞれ個別にPRB番号#0〜#5が設定されている。【0162】
例えば、式（６）に従って、MTC狭帯域#0には、nPUCCH,MTC=0（＝0+0）のPUCCHリソースが対応付けられ、MTC狭帯域#1には、nPUCCH,MTC=1（=1+0）のPUCCHリソースが対応付けられる。【0163】
以上のように、本実施の形態では、PDSCHレピティションの最後尾のサブフレームにおいてPDSCHがマッピングされるMTC狭帯域のMTC狭帯域番号と、当該PDSCHに対するACK/NACK信号がマッピングされるPUCCHリソースとが１対１で対応付けられる。同一サブフレームで送信されるPUCCHに対応するPDSCHの最後尾のサブフレームにおいてPDSCHがマッピングされるMTC狭帯域は複数のMTC端末間で重複することは無いので、各MTC狭帯域に対応付けられたPUCCHリソースも重複しない。【0164】
これにより、本実施の形態では、実施の形態１と同様、複数のMTC端末における、カバレッジ拡張レベルの違い又はスケジューリング方法（同一サブフレームスケジューリング又クロスサブフレームスケジューリング）の違いによるPUCCHリソースの衝突を回避することができる。【0165】
更に、本実施の形態によれば、カバレッジ拡張レベルの大きいMTC端末に対しては、MTC狭帯域の6PRBの全てを占有してPDSCHが送信されることを考慮して、MTC狭帯域単位でPUCCHリソースがImplicitに割り当てられることで、PUCCHリソースを効率良く用いることができる。【0166】
また、式（６）におけるPUCCHリソースオフセット値（NPUCCH,MTC）はMTC用の報知信号（MTC SIBなど）を用いて基地局１００からMTC端末に通知される情報である。よって、端末２００は、既存のLTEシステムのPDCCHに割り当てられた制御情報を復調できないものの、PUCCHリソースの特定に必要なパラメータを初期接続処理前に得ることができる。そのため、端末２００は、初期接続処理の過程で基地局１００がPDSCHを用いて端末２００に送信するMsg4に対するACK/NACK信号を送信するPUCCHリソースについても特定することができる。【0168】
本実施の形態に係る通信システムは、セル内の１つの基地局１００と複数の端末２００（MTC端末）とから構成される。【0169】
セル内には、異なるカバレッジ拡張レベルのMTC端末が共存している場合を想定する。つまり、セル内には、レピティションを必要としない（カバレッジ拡張の必要がない）MTC端末又はレピティション回数の少ない（カバレッジ拡張レベルの小さい）MTC端末、及び、非常に多くのレピティション送信を必要とする（カバレッジ拡張レベルの大きい）MTC端末が共存している。【0170】
各MTC端末は自端末に設定されたレピティション回数分の信号の送信によって所要の品質を満たすことができるため、MTC端末間でレピティション回数が異なる場合には、サブフレーム単位でみると、MTC端末間で基地局における受信信号電力に差が生じる。つまり、サブフレーム単位でみると、一般的には、レピティション回数の少ない（カバレッジ拡張の必要のない又はカバレッジ拡張レベルの小さい）MTC端末の受信信号電力の方が、レピティション回数の多い（カバレッジ拡張レベルの大きい）MTC端末の受信信号電力よりも大きい。【0171】
MTC端末間の受信信号電力の差が大きい場合、受信信号電力の大きい信号が受信信号電力の小さい信号に与える符号間干渉の影響が大きくなる。このため、カバレッジ拡張の必要のない又はカバレッジ拡張レベルの小さいMTC端末と、カバレッジ拡張レベルの大きいMTC端末との間で、同じPUCCHリソースを共有することは困難である。【0172】
そこで、本実施の形態では、カバレッジ拡張の必要のない又はカバレッジ拡張レベルの小さいMTC端末が使用するPDSCHのリソースと、カバレッジ拡張レベルの大きいMTC端末が使用するPDSCHのリソースとで、それぞれに対応付けられるPUCCH領域（PUCCHリソース）を異ならせる。換言すると、PDSCHの送信に用いられるサブフレーム数が所定数未満であるMTC端末と、PDSCHの送信に用いられるサブフレーム数が所定数以上であるMTC端末との間で、ACK/NACK信号の送信に用いられるPUCCHリソースの領域を異ならせる。【0173】
これにより、カバレッジ拡張の必要のない又はカバレッジ拡張レベルの小さいMTC端末と、カバレッジ拡張レベルの大きいMTC端末との間においてPUCCHリソースの衝突を考慮する必要がなくなる。よって、それぞれのMTC端末に対して最適なPUCCHリソース特定方法を適用することができる。【0174】
また、基地局１００は、カバレッジ拡張の必要のない又はカバレッジ拡張レベルの小さい複数のMTC端末向けのPDSCHに対して、MTC狭帯域内の6PRBをそれぞれ個別に割り当てることができる。このため、カバレッジ拡張の必要のない又はカバレッジ拡張レベルの小さいMTC端末（レピティション回数所定数未満のMTC端末）に対しては、実施の形態１で説明したように、PRB番号単位でPUCCHリソースを対応付けて確保する方法が適している。つまり、PDSCHレピティションの最後尾のサブフレームにおいてPDSCHがマッピングされるMTC狭帯域のPRB番号と、当該PDSCHに対するACK/NACK信号がマッピングされるPUCCHリソースとが１対１で対応付けられる。【0175】
一方、基地局１００は、カバレッジ拡張レベルの大きいMTC端末向けのPDSCHの各々に対して、MTC狭帯域内の6PRBを全て割り当てて送信する。このため、カバレッジ拡張レベルの大きいMTC端末（レピティション回数が所定数以上のMTC端末）に対しては、実施の形態２で説明したように、MTC狭帯域単位でPUCCHリソースを対応付けて確保する方法が適している。つまり、PDSCHレピティションの最後尾のサブフレームにおいてPDSCHがマッピングされるMTC狭帯域のMTC狭帯域番号と、当該PDSCHに対するACK/NACK信号がマッピングされるPUCCHリソースとが１対１で対応付けられる。【0176】
以上のように、本実施の形態では、カバレッジ拡張の必要のない又はカバレッジ拡張レベルの小さいMTC端末と、カバレッジ拡張レベルの大きいMTC端末とで、異なる（互いに重複しない）PUCCH領域をそれぞれ確保し、かつ、各MTC端末のカバレッジ拡張レベルに適したPDSCHのリソースとPUCCHリソースとの対応付け（PRB単位又はMTC狭帯域単位の対応付け）が適用される。【0177】
これにより、本実施の形態では、カバレッジ拡張レベルの違いによるMTC端末間の受信信号電力の差に起因する符号間干渉の影響を低減することができる。また、本実施の形態によれば、実施の形態２と同様、カバレッジ拡張レベルに応じてPUCCHリソースを効率良く用いることができる。【0178】
以上、本開示の各実施の形態について説明した。【0179】
なお、上記実施の形態では、PDSCH（下りリンクデータ）に対するACK/NACK信号の送信に用いるPUCCHリソースの特定方法について説明した。一方で、SPS（Semi-Persistent Scheduling）のリリース(SPSの終了)を指示したMPDCCHに対するACK/NACK信号の送信に用いるPUCCHリソースの特定方法についても上記実施の形態を適用してもよい。この場合、上記実施の形態におけるPDSCHをMPDCCHに置き換えることにより同様の効果を得ることができる。【0180】
また、上記実施の形態において、端末は、基地局がPDSCHにおいて送信した全てのレピティション信号を受信する前に復号に成功することがある。この場合、端末は消費電力を削減するために、残りのレピティション信号を受信しないことも考えられる。一方で、基地局は、端末がレピティション信号のどの時点でPDSCHを復号できたかを知ることはできない。このため、端末が受信したレピティション信号の最後尾のサブフレームにおけるPDSCHリソースに対応付けられたPUCCHリソースを使用すると、基地局が想定しているPUCCHリソースとは異なるPUCCHリソースでACK/NACK信号が送信されてしまう恐れがある。そこで、端末は、基地局がPDSCHにおいて送信した全てのレピティション信号を受信する前に復号に成功し、消費電力を削減するために残りのレピティション信号を受信しない場合でも、端末が受信するはずであったレピティション信号の最後尾のサブフレームにおけるPDSCHリソースに対応付けられたPUCCHリソースを用いてACK/NACK信号を送信する。端末は、端末が受信するはずであったレピティション信号の最後尾サブフレームにおけるPDSCHリソースを、MPDCCHに含まれる制御情報又は予め定められた設定から知りうる。これにより、端末が残りのレピティション信号を受信しない場合でも、基地局と端末とにおいて同一のPUCCHリソースを特定してACK/NACK信号の送受信が可能となる。【0181】
また、上記実施の形態では、本開示の一態様をハードウェアで構成する場合を例にとって説明したが、本開示はハードウェアとの連携においてソフトウェアで実現することも可能である。【0182】
また、上記実施の形態の説明に用いた各機能ブロックは、典型的には集積回路であるＬＳＩとして実現される。集積回路は、上記実施の形態の説明に用いた各機能ブロックを制御し、入力と出力を備えてもよい。これらは個別に１チップ化されてもよいし、一部または全てを含むように１チップ化されてもよい。ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。【0183】
また、集積回路化の手法はＬＳＩに限るものではなく、専用回路または汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。【0184】
さらには、半導体技術の進歩または派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。【0185】
本開示の端末は、MTC端末向けの狭帯域内の下りリソースを用いて、同一の下りリンクデータを１つ又は複数のサブフレームに渡って受信する受信部と、前記下りリンクデータに対する応答信号を生成する生成部と、前記１つ又は複数のサブフレームの最後尾サブフレームにおいて前記下りリンクデータが割り当てられた下りリソースの番号に１対１で対応付けられた上りリソースを用いて、前記最後尾サブフレームから所定数のサブフレーム後に前記応答信号を送信する送信部と、を具備する構成を採る。【0186】
本開示の端末において、前記下りリソースの番号は、前記狭帯域を構成するPRB（Physical Resource Block）の番号である。【0187】
本開示の端末において、前記下りリソースの番号は、前記狭帯域の番号である。【0188】
本開示の端末において、前記下りリンクデータの送信に用いられるサブフレーム数が所定数未満である第１のMTC端末と、前記下りリンクデータの送信に用いられるサブフレーム数が前記所定数以上である第２のMTC端末との間で、前記応答信号の送信に用いられる前記上りリソースの領域は異なる。【0189】
本開示の端末において、前記第１のMTC端末に用いられる前記上りリソースの領域において前記上りリソースと１対１で対応付けられる前記下りリソースの番号は、前記狭帯域を構成するPRB（Physical Resource Block）の番号であり、前記第２のMTC端末に用いられる前記上りリソースの領域において前記上りリソースと１対１で対応付けられる前記下りリソースの番号は、前記狭帯域の番号である。【0190】
本開示の基地局は、MTC端末向けの狭帯域内の下りリソースを用いて、１つ又は複数のサブフレームに渡って同一の下りリンクデータを送信する送信部と、前記１つ又は複数のサブフレームの最後尾サブフレームにおいて前記下りリンクデータが割り当てられた下りリソースの番号に１対１で対応付けられた上りリソースを用いて、前記最後尾のサブフレームから所定数のサブフレーム後に、前記下りリンクデータに対する応答信号を受信する受信部と、を具備する構成を採る。【0191】
本開示の送信方法は、MTC端末向けの狭帯域内の下りリソースを用いて、同一の下りリンクデータを１つ又は複数のサブフレームに渡って受信し、前記下りリンクデータに対する応答信号を生成し、前記１つ又は複数のサブフレームの最後尾サブフレームにおいて前記下りリンクデータが割り当てられた下りリソースの番号に１対１で対応付けられた上りリソースを用いて、前記最後尾サブフレームから所定数のサブフレーム後に前記応答信号を送信する。【0192】
本開示の受信方法は、MTC端末向けの狭帯域内の下りリソースを用いて、１つ又は複数のサブフレームに渡って同一の下りリンクデータを送信し、前記１つ又は複数のサブフレームの最後尾サブフレームにおいて前記下りリンクデータが割り当てられた下りリソースの番号に１対１で対応付けられた上りリソースを用いて、前記最後尾のサブフレームから所定数のサブフレーム後に、前記下りリンクデータに対する応答信号を受信する。【産業上の利用可能性】
【0193】
本開示の一態様は、移動通信システムに有用である。【符号の説明】
【0194】
１００ 基地局２００ 端末
１０１，２０９ 制御部
１０２ 制御信号生成部
１０３ 制御信号符号化部
１０４ 制御信号変調部
１０５ データ符号化部
１０６ 再送制御部
１０７ データ変調部
１０８，２１４ 信号割当部
１０９，２１５ IFFT部
１１０，２１６ CP付加部
１１１，２１７ 送信部
１１２，２０１ アンテナ
１１３，２０２ 受信部
１１４，２０３ CP除去部
１１５ PUCCH抽出部
１１６ 合成部
１１７ デマッピング部
１１８ チャネル推定部
１１９ 等化部
１２０ 逆拡散部
１２１ 相関処理部
１２２ 判定部
２０４ FFT部
２０５ 抽出部
２０６ データ復調部
２０７ データ復号部
２０８ CRC部
２１０ 応答信号生成部
２１１ 変調部
２１２ 拡散部
２１３ レピティション部