Deprecated: The each() function is deprecated. This message will be suppressed on further calls in /home/zhenxiangba/zhenxiangba.com/public_html/phproxy-improved-master/index.php on line 456
JP6410112B2 - 端末、通信方法及び集積回路 - Google Patents
[go: Go Back, main page]

JP6410112B2 - 端末、通信方法及び集積回路 - Google Patents

端末、通信方法及び集積回路 Download PDF

Info

Publication number
JP6410112B2
JP6410112B2 JP2016542242A JP2016542242A JP6410112B2 JP 6410112 B2 JP6410112 B2 JP 6410112B2 JP 2016542242 A JP2016542242 A JP 2016542242A JP 2016542242 A JP2016542242 A JP 2016542242A JP 6410112 B2 JP6410112 B2 JP 6410112B2
Authority
JP
Japan
Prior art keywords
terminal
pucch
coverage enhancement
enhancement mode
resource
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2016542242A
Other languages
English (en)
Other versions
JP2017520129A (ja
Inventor
哲矢 山本
哲矢 山本
ガオチー
鈴木　秀俊
秀俊 鈴木
中尾　正悟
正悟 中尾
Original Assignee
サン パテント トラスト
サン パテント トラスト
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by サン パテント トラスト, サン パテント トラスト filed Critical サン パテント トラスト
Publication of JP2017520129A publication Critical patent/JP2017520129A/ja
Application granted granted Critical
Publication of JP6410112B2 publication Critical patent/JP6410112B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/04—Wireless resource allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L5/00—Arrangements affording multiple use of the transmission path
    • H04L5/003—Arrangements for allocating sub-channels of the transmission path
    • H04L5/0053—Allocation of signalling, i.e. of overhead other than pilot signals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/20—Control channels or signalling for resource management
    • H04W72/23—Control channels or signalling for resource management in the downlink direction of a wireless link, i.e. towards a terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L5/00—Arrangements affording multiple use of the transmission path
    • H04L5/003—Arrangements for allocating sub-channels of the transmission path
    • H04L5/0053—Allocation of signalling, i.e. of overhead other than pilot signals
    • H04L5/0055—Physical resource allocation for ACK/NACK
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L5/00—Arrangements affording multiple use of the transmission path
    • H04L5/0091—Signalling for the administration of the divided path, e.g. signalling of configuration information
    • H04L5/0092—Indication of how the channel is divided
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/04—Wireless resource allocation
    • H04W72/044—Wireless resource allocation based on the type of the allocated resource
    • H04W72/0446—Resources in time domain, e.g. slots or frames
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/50—Allocation or scheduling criteria for wireless resources
    • H04W72/51—Allocation or scheduling criteria for wireless resources based on terminal or device properties

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Mobile Radio Communication Systems (AREA)

Description

本開示は、端末、通信方法及び集積回路に関する。
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リソースを定義する１直交符号系列において隣接する利用可能なリソース間の巡回シフト量の差Δshift PUCCHが設定される。例えば、図１２では、Δshift PUCCH＝２が設定されている。すなわち、１つの直交符号系列に対して採りうる１２個の巡回シフト量（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リソースを定義する１直交符号系列において隣接する利用可能なリソース間の巡回シフト量の差Δshift PUCCH_MTCが設定される。例えば、図１２では、Δshift PUCCH_MTC＝１が設定されている。すなわち、利用可能なPUCCHリソース間の巡回シフト量の差として、通常モードの端末とMTCカバレッジエンハンスメントモードの端末とでは互いに異なるパラメータが設定されている。具体的には、Δshift PUCCH_MTCは、Δshift PUCCHよりも小さい。
すなわち、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及び巡回シフト量を特定する対応付けを示す数式（示さず）におけるΔshift PUCCHをΔshift PUCCH_MTCに置き換えて動作すればよい。
既存のシステム（例えば、3GPP Release 11）では、上述した通常モードの端末に対するPUCCHリソースは確保されていた。これに対して、図１２に示すように、MTCカバレッジエンハンスメントモードの端末が存在する場合、通常モードの端末用のPUCCHリソースに加えて、MTCカバレッジエンハンスメントモードの端末用のPUCCHリソースが追加的に設定される。
ここで、図１２に示すように、各RB内での最大符号多重可能数は、採りうる巡回シフト量のうちの利用可能な巡回シフト量の数により特定される。具体的には、最大符号多重可能数は、PUCCHリソースとして巡回シフト量をいくつおきに利用可能か（つまり、Δshift PUCCH及びΔshift PUCCH_MTC）によって特定される。
本実施の形態では、通常モードの端末及びMTCカバレッジエンハンスメントモードの端末の各々に対して最大符号多重可能数（巡回シフト量の差）が独立に設定される。具体的には、MTCカバレッジエンハンスメントモードの端末用のPUCCHリソース群の各リソースとして定義された、直交符号系列と巡回シフト量との組合せのうち、同一直交符号系列において隣接する巡回シフト量の差Δshift PUCCH_MTCは、通常モードの端末用のPUCCHリソース群の各リソースとして定義された、直交符号系列と巡回シフト量との組合せのうち、同一直交符号系列において隣接する巡回シフト量の差Δshift PUCCHよりも小さい。
このため、MTCカバレッジエンハンスメントモードの端末用のPUCCHリソース領域では、通常モードの端末用のPUCCHリソース領域と比較して、各PUCCHリソース領域全体に対する利用可能なPUCCHリソースの割合が高くなる。具体的には、図１２に示すように、通常モードの端末用PUCCHリソース領域では、４８個のPUCCHリソースのうち、２４個のPUCCHリソースが利用可能となる。これに対して、MTCカバレッジエンハンスメントモードの端末用PUCCHリソース領域では、１２個のPUCCHリソースの全てが利用可能となる。すなわち、MTCカバレッジエンハンスメントモードの端末に対して最大符号多重可能数が最大限となる。
つまり、本実施の形態では、上述したようにMTCカバレッジエンハンスメントモードの端末用のPUCCHリソースにおける最大符号多重可能数を、通常モードの端末用PUCCHリソースにおける最大符号多重可能数よりも多くすることにより、利用可能なPUCCHリソース数を多くして、PUCCHリソースのオーバーヘッドを最小限に抑えることができる。
例えば、１２個のPUCCHリソースを利用可能とするためには、Δshift PUCCH_MTC＝２の場合には２４個のPUCCHリソースを確保する必要があるのに対して、Δshift PUCCH_MTC＝１の場合には図１２に示すように１２個のPUCCHリソースを確保するだけで済む。よって、Δshift PUCCH_MTCをΔshift PUCCHよりも小さくすることにより、通常モードの端末に設定される巡回シフト量の差Δshift PUCCHと同一とする場合と比較して、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リソースの割当時に独立して使用される巡回シフト量の差Δshift PUCCH_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リソース間の巡回シフト量の差は、実施の形態３と同様１とする（Δshift PUCCH_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生成部
２１５ 変調部
２１６ １次拡散部
２１７ ２次拡散部

Claims (15)

  1. 下り制御情報、及び、下りデータを受信する受信部と、
    前記下り制御情報に基づいて、前記下りデータに対する応答信号に使用される上り制御チャネルリソースを決定する制御部と、
    前記決定された上り制御チャネルリソースを用いて前記応答信号を送信する送信部と、
    を具備し、
    前記制御部は、前記応答信号を複数のサブフレームに渡ってレピティション送信することが可能なカバレッジエンハンスメントモードが設定されている場合、第１のオフセットを用いて前記上り制御チャネルリソースを決定し、
    前記第１のオフセットは、前記カバレッジエンハンスメントモードが設定されていない場合に用いる第２のオフセットとは異なり、前記応答信号をレピティション送信するレピティションレベル毎に設定される、
    端末。
  2. 下り制御情報、及び、下りデータを受信する受信部と、
    前記下り制御情報に基づいて、前記下りデータに対する応答信号に使用される上り制御チャネルリソースを決定する制御部と、
    前記決定された上り制御チャネルリソースを用いて前記応答信号を送信する送信部と、
    を具備し、
    前記制御部は、カバレッジエンハンスメントモードが設定された複数のサブフレームに渡ってレピティション送信が可能な前記下り制御情報を受信した場合、第１のオフセットを用いて前記上り制御チャネルリソースを決定し、
    前記第１のオフセットは、前記カバレッジエンハンスメントモードが設定されていない場合に用いる第２のオフセットとは異なり、前記応答信号をレピティション送信するレピティションレベル毎に設定される、
    端末。
  3. 前記カバレッジエンハンスメントモードにおいて、前記受信部は、複数のサブフレームに渡ってレピティション送信された前記下り制御情報を受信する、
    請求項１又は２に記載の端末。
  4. 複数の直交符号系列のうちの一つ及び複数の巡回シフト量のうちの一つの組合せが、前記上り制御チャネルリソースとの対応付けから特定され、
    前記カバレッジエンハンスメントモードにおける前記対応付けが、前記カバレッジエンハンスメントモードが設定されていない場合の前記対応付けと異なる、
    請求項１から３のいずれかに記載の端末。
  5. 前記対応付けは、一つの直交符号系列に組み合わされる隣接する巡回シフト量の差に基づき、
    前記カバレッジエンハンスメントモードにおける前記巡回シフト量の差は、前記カバレッジエンハンスメントモードが設定されていない場合の前記巡回シフト量の差とは独立に設定される、
    請求項４に記載の端末。
  6. 前記カバレッジエンハンスメントモードにおいて、前記送信部は、前記応答信号を複数のサブフレームに渡ってレピティション送信する、
    請求項１から５のいずれかに記載の端末。
  7. 前記カバレッジエンハンスメントモードにおいて、前記送信部は、前記下りデータを受信したサブフレームから所定数のサブフレーム後に、前記応答信号を送信する、
    請求項１から６のいずれかに記載の端末。
  8. 前記第１のオフセットは、端末に固有であり、前記第２のオフセットは、セル内で共通である、
    請求項１から７のいずれかに記載の端末。
  9. 前記第１のオフセットは、前記カバレッジエンハンスメントモードが設定された端末に共通である、
    請求項１から７のいずれかに記載の端末。
  10. 前記受信部は、上位レイヤによってシグナリングされた前記第１のオフセット及び前記第２のオフセットの少なくとも一つを、受信する、
    請求項１から９のいずれかに記載の端末。
  11. 前記カバレッジエンハンスメントモードにおいて、前記受信部は、複数のサブフレームに渡ってレピティション送信された前記下りデータを受信する、
    請求項１から１０のいずれかに記載の端末。
  12. 端末が、
    下り制御情報、及び、下りデータを受信する工程と、
    前記下り制御情報に基づいて、前記下りデータに対する応答信号に使用される上り制御チャネルリソースを決定する工程と、
    前記決定された上り制御チャネルリソースを用いて前記応答信号を送信する工程と、
    を具備し、
    前記決定する工程は、前記応答信号を複数のサブフレームに渡ってレピティション送信することが可能なカバレッジエンハンスメントモードが設定されている場合、第１のオフセットを用いて前記上り制御チャネルリソースを決定し、
    前記第１のオフセットは、前記カバレッジエンハンスメントモードが設定されていない場合に用いる第２のオフセットとは異なり、前記応答信号をレピティション送信するレピティションレベル毎に設定される、
    通信方法。
  13. 端末が、
    下り制御情報、及び、下りデータを受信する工程と、
    前記下り制御情報に基づいて、前記下りデータに対する応答信号に使用される上り制御チャネルリソースを決定する工程と、
    前記決定された上り制御チャネルリソースを用いて前記応答信号を送信する工程と、
    を具備し、
    前記決定する工程は、カバレッジエンハンスメントモードが設定された複数のサブフレームに渡ってレピティション送信が可能な前記下り制御情報を受信した場合、第１のオフセットを用いて前記上り制御チャネルリソースを決定し、
    前記第１のオフセットは、前記カバレッジエンハンスメントモードが設定されていない場合に用いる第２のオフセットとは異なり、前記応答信号をレピティション送信するレピティションレベル毎に設定される、
    通信方法。
  14. 下り制御情報、及び、下りデータを受信する処理と、
    前記下り制御情報に基づいて、前記下りデータに対する応答信号に使用される上り制御チャネルリソースを決定する処理と、
    前記決定された上り制御チャネルリソースを用いて前記応答信号を送信する処理と、
    を制御し、
    前記決定する処理は、前記応答信号を複数のサブフレームに渡ってレピティション送信することが可能なカバレッジエンハンスメントモードが設定されている場合、第１のオフセットを用いて前記上り制御チャネルリソースを決定し、
    前記第１のオフセットは、前記カバレッジエンハンスメントモードが設定されていない場合に用いる第２のオフセットとは異なり、前記応答信号をレピティション送信するレピティションレベル毎に設定される、
    集積回路。
  15. 下り制御情報、及び、下りデータを受信する処理と、
    前記下り制御情報に基づいて、前記下りデータに対する応答信号に使用される上り制御チャネルリソースを決定する処理と、
    前記決定された上り制御チャネルリソースを用いて前記応答信号を送信する処理と、
    を制御し、
    前記決定する処理は、カバレッジエンハンスメントモードが設定された複数のサブフレームに渡ってレピティション送信が可能な前記下り制御情報を受信した場合、第１のオフセットを用いて前記上り制御チャネルリソースを決定し、
    前記第１のオフセットは、前記カバレッジエンハンスメントモードが設定されていない場合に用いる第２のオフセットとは異なり、前記応答信号をレピティション送信するレピティションレベル毎に設定される、
    集積回路。
JP2016542242A 2014-06-24 2014-06-24 端末、通信方法及び集積回路 Active JP6410112B2 (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2014/080628 WO2015196368A1 (en) 2014-06-24 2014-06-24 Terminal, base station, transmission method, and reception method

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2018169668A Division JP6590267B2 (ja) 2018-09-11 2018-09-11 基地局、通信方法及び集積回路

Publications (2)

Publication Number Publication Date
JP2017520129A JP2017520129A (ja) 2017-07-20
JP6410112B2 true JP6410112B2 (ja) 2018-10-24

Family

ID=54936442

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2016542242A Active JP6410112B2 (ja) 2014-06-24 2014-06-24 端末、通信方法及び集積回路

Country Status (12)

Country Link
US (6) US10652871B2 (ja)
EP (3) EP3637920B1 (ja)
JP (1) JP6410112B2 (ja)
KR (1) KR102180646B1 (ja)
CN (3) CN106465355B (ja)
CA (1) CA2950636C (ja)
ES (3) ES2787896T3 (ja)
MX (1) MX359734B (ja)
MY (1) MY191807A (ja)
PL (3) PL3162139T3 (ja)
RU (1) RU2670775C9 (ja)
WO (1) WO2015196368A1 (ja)

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10064164B2 (en) * 2014-08-18 2018-08-28 Apple Inc. Radio access technology with non-continuous and periodic PUSCH transmission
WO2016047012A1 (ja) * 2014-09-25 2016-03-31 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 通信装置、送信方法及び受信方法
JP2017534193A (ja) 2014-10-30 2017-11-16 エルジー エレクトロニクス インコーポレイティド Ｍｔｃ機器のｐｕｃｃｈ転送方法
WO2016144075A1 (en) 2015-03-06 2016-09-15 Lg Electronics Inc. Method and apparatus for handling starting subframe of control channel for mtc ue in wireless communication system
WO2016159656A1 (en) * 2015-03-30 2016-10-06 Lg Electronics Inc. Method and apparatus for designing downlink control information in wireless communication system
US10728914B2 (en) 2015-05-15 2020-07-28 Qualcomm Incorporated Physical uplink control chanel (PUCCH) configuration for machine type communications (MTC)
TWI803947B (zh) 2015-11-04 2023-06-01 美商內數位專利控股公司 無線傳輸/接收單元及由其實施的方法
EP4287547A3 (en) * 2016-02-05 2024-01-03 Sony Group Corporation Communications devices, infrastructure equipment and methods
CN106357372A (zh) * 2016-11-15 2017-01-25 珠海市魅族科技有限公司 避免反馈消息资源冲突的方法、装置、基站及终端
CN106507493B (zh) * 2016-11-22 2020-01-21 珠海市魅族科技有限公司 避免上行资源冲突的方法、装置、基站及终端
US11166262B2 (en) * 2017-01-05 2021-11-02 FG Innovation Company Limited Long physical uplink control channel (PUCCH) design for 5th generation (5G) new radio (NR)
EP4557648A3 (en) 2017-05-03 2025-09-03 InterDigital Patent Holdings, Inc. Methods, systems, and apparatus for transmitting uplink control information
CN107317656A (zh) * 2017-06-22 2017-11-03 珠海市魅族科技有限公司 数据传输方法及数据传输装置、网络侧设备和终端
US11503609B2 (en) * 2019-09-27 2022-11-15 Qualcomm Incorporated PUCCH repetition before RRC connection setup
US20220124702A1 (en) * 2020-10-16 2022-04-21 Qualcomm Incorporated Dynamic repetition for a control channel
US20240340870A1 (en) * 2021-08-05 2024-10-10 Panasonic Intellectual Property Corporation Of America Terminal, base station, and communication method

Family Cites Families (38)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8422532B2 (en) 2007-09-25 2013-04-16 Panasonic Corporation Radio communication device and response signal spreading method
WO2010050153A1 (ja) * 2008-10-30 2010-05-06 パナソニック株式会社 無線通信装置及び無線通信方法
BRPI1009318B1 (pt) 2009-03-16 2021-04-20 Sun Patent Trust dispositivo de terminal de comunicação sem fio, dispositivo de estação base de comunicação sem fio e método de ajuste de região de recurso
CN101902782B (zh) * 2009-05-27 2012-08-29 中国移动通信集团公司 一种持续传送新传包的方法与装置
WO2011077743A1 (ja) * 2009-12-25 2011-06-30 パナソニック株式会社 端末装置及び送信方法
US8964658B2 (en) * 2010-03-31 2015-02-24 Mediatek Inc. Methods of contention-based transmission
JP5622840B2 (ja) * 2010-04-05 2014-11-12 パナソニックインテレクチュアル プロパティ コーポレーション オブアメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ 送信装置、送信電力制御方法及び送信判定方法
KR20110120808A (ko) 2010-04-29 2011-11-04 엘지전자 주식회사 하향링크 ａｃｋ/ｎａｃｋ 신호 전송방법 및 기지국과, 하향링크 ａｃｋ/ｎａｃｋ 신호 수신방법 및 사용자기기
DK2605434T3 (da) * 2010-08-13 2019-05-27 Sun Patent Trust Terminalindretning, basisstationsindretning, genoverførselsfremgangsmåde og ressourceallokeringsfremgangsmåde
WO2012044135A2 (ko) * 2010-10-01 2012-04-05 엘지전자 주식회사 제어 정보를 전송하는 방법 및 이를 위한 장치
JP2012080416A (ja) 2010-10-04 2012-04-19 Sony Corp 基地局、無線通信方法、プログラム、無線通信システム、および無線端末
WO2012098827A1 (ja) 2011-01-21 2012-07-26 パナソニック株式会社 基地局、端末、送信方法、及び受信方法
GB2493143A (en) 2011-07-21 2013-01-30 Sca Ipla Holdings Inc Time multiplexed additional carrier for LTE carrier aggregation and machine-type communication (MTC)
WO2013027963A2 (ko) 2011-08-19 2013-02-28 엘지전자 주식회사 상향링크 제어정보 전송방법 및 사용자기기와, 상향링크 제어정보 수신방법 및 기지국
CN103095395B (zh) 2011-11-02 2017-09-22 中兴通讯股份有限公司 Pucch的资源配置方法、传输方法、装置和系统
EP2603030B1 (en) * 2011-12-09 2014-12-24 Fujitsu Limited Interference management in wireless communication networks
JP2013197891A (ja) 2012-03-19 2013-09-30 Ntt Docomo Inc 無線通信システム、無線基地局装置、ユーザ端末及び無線リソース割当て方法
WO2013157772A1 (ko) 2012-04-15 2013-10-24 엘지전자 주식회사 상향링크 자원 결정 방법 및 이를 이용한 상향링크 제어 신호 전송 방법, 그리고 이들을 위한 장치
PT3261400T (pt) 2012-05-10 2019-02-01 Sun Patent Trust Alocação dinâmica de recursos ack/nack
US9055569B2 (en) 2012-06-29 2015-06-09 Samsung Electronics Co., Ltd. Uplink hybrid acknowledgement signaling in wireless communications systems
TWI469718B (zh) * 2012-07-09 2015-01-11 Aopen Inc 電子裝置及其線材固定機構
US9807740B2 (en) 2012-08-02 2017-10-31 Sun Patent Trust Terminal device, base station device, and uplink response signal transmission method
CN109327822B (zh) * 2012-10-05 2022-10-25 交互数字专利控股公司 增强机器类型通信（mtc）设备覆盖的方法和装置
CN103873215B (zh) * 2012-12-17 2017-12-05 中兴通讯股份有限公司 增强物理混合自动重传请求指示信道传输方法及装置
CN103188051A (zh) * 2013-03-15 2013-07-03 北京创毅讯联科技股份有限公司 Mtc中业务数据的传输方法及系统、基站、用户设备
WO2014168336A1 (ko) * 2013-04-11 2014-10-16 엘지전자 주식회사 상향링크 신호 전송 방법 및 사용자기기
US9974068B2 (en) * 2013-05-16 2018-05-15 Lg Electronics Inc. Method for transmitting signal for improving coverage and apparatus for same
WO2015012665A1 (ko) * 2013-07-26 2015-01-29 엘지전자 주식회사 Mtc를 위한 신호 전송 방법 및 이를 위한 장치
US10142064B2 (en) * 2013-09-17 2018-11-27 Intel IP Corporation Techniques and configurations associated with machine type communication in enhanced coverage mode
ES2741750T3 (es) * 2013-09-27 2020-02-12 Alcatel Lucent Métodos y dispositivos para acceso aleatorio
CN104601276B (zh) * 2013-10-31 2019-06-25 宏达国际电子股份有限公司 在无线通信系统中处理覆盖率增强的方法
US9667386B2 (en) * 2013-11-13 2017-05-30 Samsung Electronics Co., Ltd Transmission of control channel and data channels for coverage enhancements
EP3076577B1 (en) * 2013-12-04 2019-11-06 LG Electronics Inc. Methods and apparatuses for performing hybrid automatic retransmission request in wireless access system supporting machine-type communication
CN104767595A (zh) * 2014-01-07 2015-07-08 中兴通讯股份有限公司 Harq-ack反馈信息的传输方法、系统及终端和基站
EP3675566B1 (en) 2014-01-29 2022-07-06 InterDigital Patent Holdings, Inc. Method and apparatus of access and link adaptation for coverage enhanced wireless transmissions
JP6159672B2 (ja) 2014-01-30 2017-07-05 株式会社Ｎｔｔドコモ 基地局、送信方法、移動局及び再送制御方法
JP6368028B2 (ja) * 2014-03-28 2018-08-01 華為技術有限公司Ｈｕａｗｅｉ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｃｏ．，Ｌｔｄ． ダウンリンク制御チャネルの繰り返し回数を決定するための方法および装置
EP2943016A1 (en) * 2014-05-08 2015-11-11 Fujitsu Limited Coverage extension in wireless communication

Also Published As

Publication number Publication date
US20230180257A1 (en) 2023-06-08
BR112016028073A2 (pt) 2017-08-22
RU2016148175A (ru) 2018-07-24
EP3162139A4 (en) 2017-07-05
WO2015196368A1 (en) 2015-12-30
EP3637920B1 (en) 2022-02-23
MY191807A (en) 2022-07-16
US20220086813A1 (en) 2022-03-17
KR20170020340A (ko) 2017-02-22
CN110730061B (zh) 2022-04-19
ES2914358T3 (es) 2022-06-09
US20170164335A1 (en) 2017-06-08
CN110932834B (zh) 2022-03-15
CA2950636A1 (en) 2015-12-30
US11219012B2 (en) 2022-01-04
US10652871B2 (en) 2020-05-12
US12114333B2 (en) 2024-10-08
CN106465355A (zh) 2017-02-22
BR112016028073A8 (pt) 2017-12-26
PL3637920T3 (pl) 2022-06-20
ES2992763T3 (en) 2024-12-17
PL3162139T3 (pl) 2020-10-19
EP3162139B1 (en) 2020-02-12
JP2017520129A (ja) 2017-07-20
MX2016015879A (es) 2017-03-20
KR102180646B1 (ko) 2020-11-19
CN110730061A (zh) 2020-01-24
MX359734B (es) 2018-10-09
EP3998819B1 (en) 2024-04-24
EP3162139A1 (en) 2017-05-03
RU2016148175A3 (ja) 2018-07-24
PL3998819T3 (pl) 2024-08-26
US20200236663A1 (en) 2020-07-23
CN110932834A (zh) 2020-03-27
WO2015196368A8 (en) 2016-02-18
ES2787896T3 (es) 2020-10-19
EP3998819A1 (en) 2022-05-18
US11838927B2 (en) 2023-12-05
RU2670775C2 (ru) 2018-10-25
US20240049247A1 (en) 2024-02-08
EP3637920A1 (en) 2020-04-15
US20240422793A1 (en) 2024-12-19
CA2950636C (en) 2021-03-02
CN106465355B (zh) 2019-12-31
RU2670775C9 (ru) 2018-12-19
US11606785B2 (en) 2023-03-14

Similar Documents

Publication Publication Date Title
JP6410112B2 (ja) 端末、通信方法及び集積回路
JP6691248B2 (ja) 端末及び送信方法
JP6667532B2 (ja) 端末、基地局、送信方法及び受信方法
JP6590267B2 (ja) 基地局、通信方法及び集積回路
JP7016047B2 (ja) 基地局、通信方法及び集積回路
JP6799787B2 (ja) 端末、通信方法及び集積回路

Legal Events

Date Code Title Description
A711 Notification of change in applicant

Free format text: JAPANESE INTERMEDIATE CODE: A711

Effective date: 20161130

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170419

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20170419

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20180426

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20180515

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20180719

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20180828

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20180912

R150 Certificate of patent or registration of utility model

Ref document number: 6410112

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R150 Certificate of patent or registration of utility model

Ref document number: 6410112

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250