図4は、本開示の一態様として想定したMTCカバレッジエンハンスメントにおける各チャネルの送信タイミングを示す。図4では、PDCCHのレピティションレベル(レピティション回数、又は、レピティションファクタ)をNPDCCHとし、PDSCHのレピティションレベルをNPDSCHとし、PUCCHのレピティションレベルをNPUCCHとする。また、図4に示すように、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信号が送信されてしまう。
図5は、通常モードの端末のPUCCHリソースとMTCカバレッジエンハンスメントモードの端末のPUCCHリソースとが衝突する場合の一例を示す。図5において、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が送信されないようにスケジューリングされる。しかし、それ以外の場合(例えば、図5の場合)、通常モードの端末に対するPDCCH送信とMTCカバレッジエンハンスメントモードの端末に対するPDCCHレピティション送信とに対して同一のCCEを用いることができる。例えば、図5では、MTCカバレッジエンハンスメントモードの端末に対するPDCCHにはCCE#0〜CCE#3が使用され、当該端末は、CCE#0(CCE#0〜CCE#3のうち最小のインデックス)に対応するPUCCHリソースを用いる。また、図5では、通常モードの端末に対する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に対応するシステムであって、基地局100及び端末200を備える。
端末200には、通常モード又はMTCカバレッジエンハンスメントモードが設定される。端末200は、例えば、MTCカバレッジエンハンスメントモードが適用される場合、PDCCH、PDSCH又はPUCCHの送信の際、複数のサブフレームに渡ってレピティション送信を適用する。すなわち、端末200は、所定のレピティションレベル分の連続するサブフレームにおいて同一の信号を繰り返し送信する。
図6は本開示の実施の形態に係る基地局100の要部構成を示すブロック図である。図6に示す基地局100において、送信部112は、下りリンクデータの割当を示す制御情報(PDCCH信号)、及び、下りリンクデータ(PDSCH信号)を送信し、制御部101は、上記制御情報に基づいて、上記下りリンクデータに対するACK/NACK信号に使用されるリソースを決定し、ACK/NACK信号の受信部(PUCCH抽出部116、逆拡散部118、相関処理部119)は、決定されたリソースを用いてACK/NACK信号を受信する。ここで、上記受信部は、上記制御情報、下りリンクデータ及びACK/NACK信号に対してレピティション送信が適用される第1の端末から送信されるACK/NACK信号を、第1のリソース群(PUCCHリソース領域)の中のリソースを用いて受信し、レピティション送信が適用されない第2の端末から送信されるACK/NACK信号を、第1のリソース群とは異なる第2のリソース群(PUCCHリソース領域)の中のリソースを用いて受信する。
また、図7は、本開示の各実施の形態に係る端末200の要部構成を示すブロック図である。図7に示す端末200において、受信部202は、下りリンクデータの割当を示す制御情報、及び、下りリンクデータを受信し、制御部213は、上記制御情報に基づいて、下りリンクデータに対するACK/NACK信号に使用されるリソースを決定し、ACK/NACK信号の送信部(1次拡散部216、2次拡散部217、IFFT部218)は、決定されたリソースを用いてACK/NACK信号を送信する。ここで、上記送信部は、自端末が、制御情報、下りリンクデータ及びACK/NACK信号に対してレピティション送信が適用される第1の端末である場合には第1のリソース群の中のリソースを用いてACK/NACK信号を送信し、自端末が、レピティション送信が適用されない第2の端末である場合には第1のリソース群とは異なる第2のリソース群の中のリソースを用いてACK/NACK信号を送信する。
(実施の形態1)
[基地局の構成]
図8は、本開示の実施の形態1に係る基地局100の構成を示すブロック図である。図8において、基地局100は、制御部101と、制御信号生成部102と、制御信号符号化部103と、制御信号変調部104と、報知信号生成部105と、データ符号化部106と、再送制御部107と、データ変調部108と、信号割当部109と、IFFT部110と、CP付加部111と、送信部112と、アンテナ113と、受信部114と、CP除去部115と、PUCCH抽出部116と、系列制御部117と、逆拡散部118と、相関処理部119と、判定部120とを有する。
制御部101は、リソース割当対象端末200に対して、制御情報を送信するための下りリソース(下り制御情報割当リソース)、及び、当該制御情報に含まれる、下りリンクデータ(送信データ)を送信するための下りリソース(下りデータ割当リソース)を割り当てる。下り制御情報割当リソースは、PDCCH又はEPDCCH(Enhanced PDCCH)に対応するリソース内で選択される。また、下りデータ割当リソースは、PDSCHに対応するリソース内で選択される。また、同一サブフレーム内にリソース割当対象端末200が複数有る場合には、制御部101は、リソース割当対象端末200のそれぞれに異なるリソースを割り当てる。下り制御情報割当リソースは、上述したL1/L2 CCHと同等である。すなわち、下り制御情報割当リソースは、1つ又は複数のCCEから構成される。また、上述したようにPUCCHがCCEを用いてImplicitに通知される場合、各CCEは、上りリンク制御チャネル領域(PUCCH領域)のPUCCHリソースと対応付けられている。
制御部101は、制御情報を含むPDCCHが占有するCCEに対応するPUCCHリソース(周波数、及び、1次拡散/2次拡散に用いる符号)を特定する。制御部101は、端末200から送信されるPUCCH信号(ACK/NACK信号及び参照信号)の拡散に用いられる可能性があるZAC系列及び直交符号系列(つまり、PUCCHリソース)に関する情報を、系列制御部117へ出力し、周波数に関する情報をPUCCH抽出部116へ出力する。
また、制御部101は、リソース割当対象端末200に対して、制御情報を送信する際に用いる符号化率を決定し、決定した符号化率を制御信号符号化部103へ出力する。また、制御部101は、リソース割当対象端末200に対して、下りリンクデータを送信する際に用いる符号化率を決定し、決定した符号化率をデータ符号化部106へ出力する。
なお、決定される符号化率に応じて制御情報のデータ量が異なるので、制御部101は、このデータ量の制御情報をマッピング可能なCCEを含む下り制御情報割当リソースを割り当てる。制御部101は、制御信号生成部102に対して、下りデータ割当リソースに関する情報を出力する。また、制御部101は、下りデータ割当リソース及び下り制御情報割当リソースに関する情報を信号割当部109に出力する。
また、制御部101は、リソース割当対象端末200に対してMTCカバレッジエンハンスメントモードが設定される場合、当該端末200の各チャネル(PDCCH、PDSCH又はPUCCH)に対するレピティションレベル(レピティション回数)に関する情報を、制御信号生成部102及びデータ符号化部106に出力する。
また、制御部101は、報知信号生成部105に対して、予め基地局毎に決められたパラメータに基づいて報知信号を生成するように指示する。
また、制御部101は、PUCCHリソースに関する情報を生成し、制御信号生成部102へ出力する。PUCCHリソースに関する情報とは、例えば、通常モードの端末及びMTCカバレッジエンハンスメントモードの端末において使用されるPUCCHリソースを特定するためのパラメータである。なお、PUCCHリソースに関する情報は、セル固有の値として報知情報として端末200へ通知されてもよく、上位レイヤのシグナリングとして端末200へ通知されてもよい。
制御信号生成部102は、制御部101から受け取る情報(下りデータ割当リソースに関する情報、PUCCHのレピティションレベルに関する情報又はPUCCHリソースに関する情報)を用いて制御信号を生成し、制御信号を制御信号符号化部103に出力する。リソース割当対象端末200が複数ある場合、リソース割当対象端末200同士を区別するために、制御信号には、宛先端末の端末IDが含まれる。例えば、制御信号には、宛先端末の端末IDによってマスキングされたCRCビットが含まれる。また、制御信号生成部102は、リソース割当対象端末200に対してMTCカバレッジエンハンスメントモードが設定される場合、制御部101から受け取るレピティションレベルに関する情報に従って、レピティション信号を生成する。すなわち、PDCCHのレピティションレベルが1より大きい場合には、制御信号生成部102は、レピティションレベルに対応した連続する複数のサブフレームに渡って、同一の制御信号を制御信号符号化部103へ出力する。
制御信号符号化部103は、制御部101から受け取る符号化率に従って、制御信号生成部102から受け取る制御信号を符号化し、符号化後の制御信号を制御信号変調部104へ出力する。
制御信号変調部104は、制御信号符号化部103から受け取る制御信号を変調し、変調後の制御信号を信号割当部109へ出力する。
報知信号生成部105は、制御部101からの指示に従って、報知信号を生成し、報知信号を信号割当部109へ出力する。なお、報知信号には、例えば、システム帯域幅、又は、PUCCHリソースに関する信号等が含まれている。また、報知信号には、符号化処理及び変調処理が施されてもよい。
データ符号化部106は、制御部101から受け取る符号化率に従って、宛先端末毎の送信データ(ビット系列。つまり、下りリンクデータ)を符号化し、符号化後のデータ信号を再送制御部107へ出力する。また、データ符号化部106は、リソース割当対象端末200に対してMTCカバレッジエンハンスメントモードが設定される場合、制御部101から受け取るレピティションレベルに関する情報に従って、レピティション信号を生成する。すなわち、PDSCHのレピティションレベルが1より大きい場合には、データ符号化部106は、レピティションレベルに対応した連続する複数のサブフレームに渡って、同一のデータ信号を再送制御部107へ出力する。
再送制御部107は、初回送信時には、データ符号化部106から受け取る符号化後のデータ信号を保持するとともにデータ変調部108へ出力する。再送制御部107は、符号化後のデータ信号を、宛先端末毎に保持する。また、再送制御部107は、後述する判定部120から、送信したデータ信号に対するNACKを受け取ると、対応する保持データをデータ変調部108へ出力する。再送制御部107は、送信したデータ信号に対するACKを受け取ると、対応する保持データを削除する。
データ変調部108は、再送制御部107から受け取るデータ信号を変調して、データ変調信号を信号割当部109へ出力する。
信号割当部109は、制御信号変調部104から受け取る制御信号、報知信号生成部105から受け取る報知信号、及び、データ変調部106から受け取るデータ変調信号を、下りリソース(下りリンクデータ信号割当リソース、下りリンク制御情報割当リソース等)にマッピングし、マッピングした信号をIFFT部110へ出力する。具体的には、信号割当部109は、制御部101から受け取る下り制御情報割当リソースに示されるリソースに制御信号をマッピングし、制御部101から受け取る下りデータ割当リソースに示されるリソースにデータ変調信号をマッピングする。また、信号割当部109は、予め設定された時間・周波数リソースに報知信号をマッピングする。
IFFT部110は、信号割当部109から受け取る信号に対してIFFT処理を行うことにより、周波数領域信号を時間領域信号に変換する。IFFT部110は、時間領域信号をCP付加部111へ出力する。
CP付加部111は、IFFT部110から受け取る信号に対してCPを付加し、CP付加後の信号(OFDM信号)を送信部112へ出力する。
送信部112は、CP付加部111から受け取るOFDM信号に対してD/A(Digital-to-Analog)変換、アップコンバート等のRF(Radio Frequency)処理を行い、アンテナ113を介して端末200に無線信号を送信する。
受信部114は、アンテナ113を介して受信された端末200からの無線信号に対して、ダウンコンバート又はA/D(Analog-to-Digital)変換などのRF処理を行い、得られる受信信号をCP除去部115に出力する。
CP除去部115は、受信部114から受け取る受信信号に付加されているCPを除去し、CP除去後の信号をPUCCH抽出部116へ出力する。
PUCCH抽出部116は、制御部101から受け取る情報に基づいて、CP除去部115から受け取る信号から上り制御チャネル信号(PUCCH)を抽出し、抽出したPUCCHを逆拡散部118へ出力する。また、PUCCH抽出部116は、MTCカバレッジエンハンスメントモードの端末200が存在する場合、複数サブフレームに渡ってレピティション送信されたPUCCHに対して、同相合成を施してPUCCH(合成信号)を抽出する。
系列制御部117は、制御部101から受け取るZAC系列及び直交符号系列に関する情報に基づいて、端末200から送信されるACK/NACK信号及び参照信号の拡散に用いられる可能性があるZAC系列、及び、直交符号系列を生成する。系列制御部117は、直交符号系列を逆拡散部118へ出力し、ZAC系列を相関処理部119へ出力する。
逆拡散部118は、系列制御部117から受け取る直交符号系列(端末200が2次拡散で用いるべき直交符号系列)を用いて、PUCCH抽出部116から受け取る信号のうちACK/NACK信号に相当する部分の信号を逆拡散し、逆拡散後の信号を相関処理部119に出力する。
相関処理部119は、系列制御部117から入力されるZAC系列(端末200が1次拡散で用いる可能性のあるZAC系列)と、逆拡散部118から入力される信号との相関値を求めて、相関値を判定部120に出力する。
判定部120は、相関処理部119から受け取る相関値に基づいて、端末200から送信されたACK/NACK信号が、送信されたデータに対してACK又はNACKのいずれかを示しているかを判定する。判定部120は、判定結果を再送制御部107に出力する。
[端末の構成]
図9は、本開示の実施の形態1に係る端末200の構成を示すブロック図である。図9において、端末200は、アンテナ201と、受信部202と、CP除去部203と、FFT(Fast Fourier Transform)部204と、抽出部205と、報知信号受信部206と、制御信号復調部207と、制御信号復号部208と、判定部209と、データ復調部210と、データ復号部211と、CRC部212と、制御部213と、ACK/NACK生成部214と、変調部215と、1次拡散部216と、2次拡散部217と、IFFT部218と、CP付加部219と、送信部220とを有する。
受信部202は、アンテナ201を介して受信された、基地局100からの無線信号に対してダウンコンバート又はAD変換などのRF処理を行い、ベースバンドのOFDM信号を得る。受信部202は、OFDM信号をCP除去部203へ出力する。
CP除去部203は、受信部202から受け取るOFDM信号に付加されているCPを除去し、CP除去後の信号をFFT部204へ出力する。
FFT部204は、CP除去部203から受け取る信号に対してFFT処理を行うことにより、時間領域信号を周波数領域信号に変換する。FFT部204は、周波数領域信号を抽出部205へ出力する。
抽出部205は、FFT部204から受け取る信号から報知信号を抽出して、報知信号受信部206へ出力する。ここで、報知信号がマッピングされるリソースは予め決まっているので、抽出部205は、そのリソースにマッピングされている情報を抽出することにより、報知信号を得る。抽出された報知信号には、例えば、システム帯域幅、又は、PUCCHリソースに関する信号等が含まれている。
また、抽出部205は、FFT部204から受け取る信号から、下り制御チャネル信号(PDCCH信号)を抽出し、制御信号復調部207へ出力する。また、抽出部205は、判定部209から受け取る、自端末宛の下りデータ割当リソースに関する情報に基づいて、FFT部204から受け取る信号から下りリンクデータ(PDSCH信号)を抽出し、データ復調部210へ出力する。PDCCH信号には、例えば、下りデータ割当リソースに関する情報、PUCCHのレピティションレベルに関する情報、又は、PUCCHリソースに関する情報などが含まれている。
また、抽出部205は、自装置に対してMTCカバレッジエンハンスメントモードが設定され、PDCCH信号がレピティション送信されている場合、複数のサブフレームに渡ってレピティション送信されたPDCCH信号に対して同相合成して、PDCCH信号を抽出する。同様に、抽出部205は、下りリンクデータ(PDSCH信号)がレピティション送信されている場合には、複数のサブフレームに渡ってレピティション送信されたPDSCH信号に対して同相合成して、下りリンクデータを抽出する。
報知信号受信部206は、抽出部205から受け取る報知信号から、システム帯域幅、又は、PUCCHリソースに関する情報などを得る。報知信号受信部206は、報知信号に符号化処理及び変調処理が施されている場合、復調処理及び復号処理を施す。報知信号受信部206は、得られた報知信号を判定部209又は制御部213へ出力する。
制御信号復調部207は、抽出部205から受け取るPDCCH信号を復調し、復調後のPDCCH信号を制御信号復号部208へ出力する。
制御信号復号部208は、制御信号復調部207から受け取るPDCCH信号を復号して、復号結果を判定部209に出力する。
判定部209は、制御信号復号部208から受け取る復号結果に含まれる制御情報が自端末宛ての制御情報であるか否かをブラインド判定する。例えば、判定部209は、自端末の端末IDによってCRCビットをデマスキングし、CRC=OK(誤りなし)となる制御情報を、自端末宛ての制御情報であると判定する。そして、判定部209は、自装置宛の制御情報に含まれる下りデータ割当リソースに関する情報を抽出部205へ出力する。また、判定部209は、自装置宛の制御情報がマッピングされていたCCEを特定し、特定したCCEの識別情報を制御部213へ出力する。
データ復調部210は、抽出部205から受け取る下りリンクデータを復調し、復調後の下りリンクデータをデータ復号部211へ出力する。
データ復号部211は、データ復調部210から受け取る下りリンクデータを復号し、復号後の下りリンクデータをCRC部212へ出力する。
CRC部212は、データ復号部211から受け取る下りリンクデータに対して、CRCを用いて誤り検出を行い、誤り検出結果をACK/NACK生成部214へ出力する。また、CRC部212は、誤り検出の結果、誤りなしと判定した下りリンクデータを受信データとして出力する。
制御部213は、報知信号、PDCCH信号又は上位レイヤシグナリングによって基地局100から端末200に対して通知されたPUCCHリソースに関する情報、及び、レピティションレベルに関する情報を予め保持する。
制御部213は、PUCCHリソースに関する情報、及び、判定部209から受け取るCCEの識別情報を用いて、CCEの識別情報に示されるCCEに対応するPUCCHリソース(周波数、及び、1次拡散/2次拡散に用いる符号)を特定する。すなわち、制御部213は、CCEの識別情報に基づいて上り制御チャネルのPUCCHリソースを特定する。
具体的には、制御部213は、使用すべきPUCCHリソースに対応するZAC系列を生成すると共に、設定された巡回シフト量に基づいて、使用すべき巡回シフト量を決定し、1次拡散部216へ出力する。また、制御部213は、使用すべきPUCCHリソースに対応する直交符号系列を2次拡散部217へ出力する。また、制御部213は、使用すべきPUCCHリソースに対応する周波数リソース(サブキャリア)をIFFT部218へ出力する。
また、制御部213は、自端末がMTCカバレッジエンハンスメントモードである場合、PUCCHのレピティションレベルに関する情報をACK/NACK生成部214へ出力する。
ACK/NACK生成部214は、CRC部212から受け取る誤り検出結果に基づいてACK/NACK信号を生成する。具体的には、ACK/NACK生成部214は、誤りが検出された場合にはNACKを生成し、誤りが検出されない場合にはACKを生成する。ACK/NACK生成部214は、生成したACK/NACK信号を変調部215へ出力する。また、ACK/NACK生成部214は、自端末がMTCカバレッジエンハンスメントモードである場合、制御部213から受け取るレピティションレベルに関する情報に従って、レピティション信号を送信する。すなわち、PUCCHのレピティションレベルが1より大きい場合には、ACK/NACK生成部214は、レピティションレベルに対応した連続する複数のサブフレームに渡って、同一のACK/NACK信号を変調部215へ出力する。
変調部215は、ACK/NACK生成部214から受け取るACK/NACK信号を変調して、変調後のACK/NACK信号を1次拡散部216へ出力する。
1次拡散部216は、制御部213によって設定されたZAC系列及び巡回シフト量を用いて、参照信号、及び、変調部215から受け取るACK/NACK信号を1次拡散し、1次拡散後のACK/NACK信号及び参照信号を2次拡散部217へ出力する。
2次拡散部217は、制御部213によって設定された直交符号系列を用いてACK/NACK信号及び参照信号を2次拡散し、2次拡散後の信号をIFFT部218へ出力する。
IFFT部218は、制御部213によって設定された周波数リソースを用いて、2次拡散部217から受け取るACK/NACK信号及び参照信号に対してサブキャリアへのマッピング、及び、IFFT処理を行うことにより時間領域信号を生成する。IFFT部218は、生成した信号をCP付加部219へ出力する。
CP付加部219は、IFFT部218から受け取る信号に対してCPを付加し、CP付加後の信号を送信部220へ出力する。
送信部220は、CP付加部219から受け取る信号に対してD/A変換、アップコンバート等のRF処理を行い、アンテナ201を介して基地局100に無線信号を送信する。
[基地局100及び端末200の動作]
以上の構成を有する基地局100及び端末200の動作について説明する。
以下では、通常モードの端末と、MTCカバレッジエンハンスメントモードの端末とが基地局100のセル内に共存する場合について説明する。
本実施の形態に係る基地局100は、各端末200に対して、PUCCHリソースに関する情報を予め通知する。PUCCHリソースに関する情報は、例えば、CCE番号からPUCCH番号を特定する際に使用されるオフセット値、及び、各PUCCH領域に配置される1リソースブロック(RB:Resource Block)あたりに符号多重されるPUCCHリソースの最大数に関する情報である。
本実施の形態では、通常モードの端末及びMTCカバレッジエンハンスメントモードの端末に対して上記オフセット値が独立に設定される。
具体的には、通常モードの端末は、下りリンク割当制御情報(PDCCH又はEPDCCH)を受信した場合、対応する割当制御情報に示される下りリンクデータ(PDSCH)に対するACK/NACK信号を送信するPUCCHリソースのリソース番号nPUCCHを次式に従って決定する。
nPUCCH=nCCE+NPUCCH (1) (1)
式(1)において、nCCEは、PDCCHが占有するCCE番号(0以上の整数)を示す。具体的には、PDCCHが1つのCCEのみを占有していた場合には、nCCEは当該CCEの番号である。また、PUCCHが複数のCCEを占有していた場合には、nCCEは最小のCCEの番号である。
また、式(1)において、NPUCCH (1)は、CCE番号からPUCCHリソース番号を特定するためのオフセット値を示す。例えば、3GPP Release 11では、NPUCCH (1)は、SPS/SR(Semi-Persistent Scheduling/Scheduling Request)用リソース向けに確保されたPUCCHリソース数を示す。NPUCCH (1)は、例えば、セル内で共通(common)の値であって、基地局100から端末200へ報知信号又は上位レイヤシグナリングによって通知される。
通常モードの端末は、決定したPUCCHリソース番号nPUCCHに基づいて、実際に使用するOC index及び巡回シフト量を決定する。
一方、MTCカバレッジエンハンスメントモードの端末は、下りリンク割当制御情報(PDCCH又はEPDCCH)を受信した場合、対応する割当制御情報に示される下りリンクデータ(PDSCH)に対するACK/NACK信号を送信するPUCCHリソースのリソース番号nPUCCH_MTCを次式に従って決定する。
nPUCCH_MTC=nCCE+NPUCCH_MTC (1) (2)
式(2)において、NPUCCH_MTC (1)は、MTCカバレッジエンハンスメントモードの端末に対する、CCE番号からPUCCHリソース番号を特定するためのオフセット値を示す。すなわち、MTCカバレッジエンハンスメントモードの端末に対して、通常モードの端末のオフセットNPUCCH (1)とは異なる独立のオフセット値NPUCCH_MTC (1)が設定される。NPUCCH_MTC (1)は、例えば、端末200に依存する個別(UE specific)の値であってもよく、MTCカバレッジエンハンスメントモードの端末に共通の値でもよい。
MTCカバレッジエンハンスメントモードの端末は、決定したPUCCHリソース番号nPUCCH_MTCに基づいて、実際に使用するOC index及び巡回シフト量を決定する。
図10は、通常モードの端末及びMTCカバレッジエンハンスメントモードの端末に対するPUCCHリソースの一例を示す。
図10では、図3と同様、1RB(PRB(Physical RB))毎に最大36個のPUCCHリソースのうち、18個のPUCCHリソースが利用可能である。図10では、3個のRBに渡って、利用可能な54個のPUCCHリソースに対してPUCCHリソース番号(#0〜#53)がそれぞれ付されている。
図10では、通常モードの端末に対するオフセット値NPUCCH (1)=6であり、MTCカバレッジエンハンスメントモードの端末に対するオフセット値NPUCCH_MTC (1)=30である。
すなわち、通常モードの端末は、PUCCHリソース番号nPUCCH=nCCE+6のPUCCHリソースを用いてACK/NACK信号を送信する。一方、MTCカバレッジエンハンスメントモードの端末は、PUCCHリソース番号nPUCCH_MTC=nCCE+30のPUCCHリソースを用いてACK/NACK信号を送信する。
つまり、端末200は、自端末が通常モードの端末である場合には、通常モードの端末用のPUCCHリソース群の中のPUCCHリソースを用いてACK/NACK信号を送信し、自端末が、MTCカバレッジエンハンスメントモードの端末である場合には、通常モードの端末用のPUCCHリソース群とは異なるMTCカバレッジエンハンスメントモードの端末用のPUCCHリソース群の中のPUCCHリソースを用いてACK/NACK信号を送信する。
また、同様にして、基地局100は、通常モードの端末から送信されるACK/NACK信号を、通常モードの端末用のPUCCHリソース群の中のリソースを用いて受信し、MTCカバレッジエンハンスメントモードの端末から送信されるACK/NACK信号を、通常モードの端末用のPUCCHリソース群とは異なるMTCカバレッジエンハンスメントモードの端末用のPUCCHリソース群の中のリソースを用いて受信する。
これにより、図10に示すように、PDCCH信号、PDSCH信号及びACK/NACK信号に対してレピティション送信が適用されるMTCカバレッジエンハンスメントモードの端末がACK/NACK信号の送信に使用可能なPUCCHリソース群と、レピティション送信が適用されない通常モードの端末がACK/NACK信号の送信に使用可能なPUCCHリソース群とは異なる。すなわち、通常モードの端末とMTCカバレッジエンハンスメントモードの端末との間において、CCE番号からPUCCHリソース番号を特定するためのオフセット値を異ならせることにより、双方の端末に対するPUCCHリソース領域が分割される。
なお、図10では、各モードの端末200に対して使用可能なCCE数を24個とする場合について示している。ただし、各モードの端末200に対して使用可能なCCE数は24個に限らず、他の値でもよく、使用可能なCCE数に応じて、各モードの端末200に対するPUCCHリソース領域が分割されるように、オフセット値NPUCCH (1)及びNPUCCH_MTC (1)が設定されればよい。
ここで、一例として、図5に示すように、同一サブフレームにおいて送信されるACK/NACK信号に使用されるPUCCHリソースに対応するCCE番号がCCE#0である場合(つまり、nCCE=0)について説明する。
この場合、通常モードの端末は、式(1)に従って、PUCCHリソース番号nPUCCH=6(=0+6)のPUCCHリソースを用いる。
一方、MTCカバレッジエンハンスメントモードの端末は、式(2)に従って、PUCCHリソース番号nPUCCH_MTC=30(=0+30)のPUCCHリソースを用いる。
すなわち、端末200(制御部213)は、自端末が通常モードの端末である場合には、PDCCHに使用されるCCEのインデックスnCCEにオフセット値NPUCCH (1)を加算して、実際にACK/NACK信号に使用されるPUCCHリソースを算出する。また、端末200は、自端末が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リソースの割当(例えば、式(1)を参照)はLTEシステムにおいて既に行われている。よって、本実施の形態では、MTCカバレッジエンハンスメントモードの端末に対するPUCCHリソースの割当時に独立して使用されるオフセット値NPUCCH_MTC (1)のみが基地局100から端末200へ新たに通知されればよい。よって、既存のシステムの動作に与える影響は少ない。
(実施の形態2)
本実施の形態に係る基地局及び端末の基本構成は、実施の形態1と同様であるので、図8(基地局100)と図9(端末200)を援用して説明する。
以下では、実施の形態1と同様、通常モードの端末と、MTCカバレッジエンハンスメントモードの端末とが基地局100のセル内に共存する場合について説明する。
本実施の形態に係る基地局100は、各端末200に対して、PUCCHリソースに関する情報を予め通知する。PUCCHリソースに関する情報は、例えば、CCE番号からPUCCH番号を特定する際に使用されるオフセット値、及び、各PUCCH領域に配置される1リソースブロック(RB:Resource Block)あたりに符号多重されるPUCCHリソースの最大数に関する情報である。
本実施の形態では、通常モードの端末及びMTCカバレッジエンハンスメントモードの端末に対して上記オフセット値が共通に設定される。ただし、通常モードの端末と、MTCカバレッジエンハンスメントモードの端末とでは、CCE番号とPUCCHリソース番号との対応付けが異なる。
具体的には、通常モードの端末は、実施の形態1と同様、ACK/NACK信号を送信するPUCCHリソースのリソース番号nPUCCHを式(1)に従って決定し、実際に使用するOC index及び巡回シフト量を決定する。
一方、MTCカバレッジエンハンスメントモードの端末は、下りリンク割当制御情報(PDCCH又はEPDCCH)を受信した場合、対応する割当制御情報に示される下りリンクデータ(PDSCH)に対するACK/NACK信号を送信するPUCCHリソースのリソース番号nPUCCH_MTCを次式に従って決定する。
nPUCCH_MTC=NPUCCH (1)-1-nCCE (3)
式(3)において、NPUCCH (1)は、CCE番号からPUCCHリソース番号を特定するためのオフセット値であって、式(1)にも含まれる値である。すなわち、MTCカバレッジエンハンスメントモードの端末に対して、通常モードの端末のオフセットNPUCCH (1)と同一のオフセット値NPUCCH (1)が設定される。NPUCCH (1)は、例えば、基地局100から端末200へ報知信号又は上位レイヤシグナリングによって通知されてもよい。
MTCカバレッジエンハンスメントモードの端末は、決定したPUCCHリソース番号nPUCCH_MTCに基づいて、実際に使用するOC index及び巡回シフト量を決定する。
すなわち、端末200(制御部213)は、自端末が通常モードの端末である場合には、PDCCHに使用されるCCEのインデックスnCCEにオフセット値NPUCCH (1)を加算して、実際にACK/NACK信号に使用されるPUCCHリソースを算出する。一方、端末200は、自端末がMTCカバレッジエンハンスメントモードの端末である場合には、オフセット値NPUCCH_MTC (1)から、PDCCHに使用されるCCEのインデックスnCCEを減算して、実際にACK/NACK信号に使用されるPUCCHリソースを算出する。
図11は、通常モードの端末及びMTCカバレッジエンハンスメントモードの端末に対するPUCCHリソースの一例を示す。
図11では、図10と同様、1RB毎に最大36個のPUCCHリソースのうち、18個のPUCCHリソースが利用可能である。図11では、3個のRBに渡って、利用可能な54個のPUCCHリソースに対してPUCCHリソース番号(#0〜#53)がそれぞれ付されている。
また、図11では、各端末200に対するオフセット値NPUCCH (1)=30である。
すなわち、通常モードの端末は、PUCCHリソース番号nPUCCH=nCCE+30のPUCCHリソースを用いてACK/NACK信号を送信する。一方、MTCカバレッジエンハンスメントモードの端末は、PUCCHリソース番号nPUCCH_MTC=30−1−nCCE(=29−nCCE)のPUCCHリソースを用いてACK/NACK信号を送信する。
つまり、図11に示すように、PUCCHリソース番号#29と#30との間を境界として、#30以上の番号のPUCCHリソースは通常モードの端末用PUCCHリソース領域に設定され、#29以下の番号のPUCCHリソースはMTCカバレッジエンハンスメントモードの端末用PUCCHリソース領域に設定される。
これにより、図11に示すように、通常モードの端末及びMTCカバレッジエンハンスメントモードの端末の各々に対して異なるPUCCHリソース領域が設定される。すなわち、通常モードの端末とMTCカバレッジエンハンスメントモードの端末との間において、CCE番号からPUCCHリソース番号を特定するための対応付け(式(1)及び式(3))を異ならせることにより、双方の端末に対するPUCCHリソース領域が分割される。
ここで、一例として、図5に示すように、同一サブフレームにおいて送信されるACK/NACK信号に使用されるPUCCHリソースに対応するCCE番号がCCE#0である場合(つまり、nCCE=0)について説明する。
この場合、通常モードの端末は、式(1)に従って、PUCCHリソース番号nPUCCH=30(=0+30)のPUCCHリソースを用いる。
一方、MTCカバレッジエンハンスメントモードの端末は、式(3)に従って、PUCCHリソース番号nPUCCH_MTC=29(=29−0)の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リソースの割当(例えば、式(1)を参照)はLTEシステムにおいて既に行われている。また、MTCカバレッジエンハンスメントモードの端末に対するPUCCHリソースの割当時にも、通常モードの端末と同一のパラメータ(オフセット値NPUCCH (1))が用いられる。よって、MTCカバレッジエンハンスメントモードの端末に対して新たに追加すべきパラメータはない。よって、既存のシステムの動作に影響を与えない。
なお、CCE番号からPUCCHリソース番号を特定する対応付けを、通常モードとMTCカバレッジエンハンスメントモードとで逆にしてもよい。つまり、通常モードの端末が式(3)を用いてPUCCHリソース番号を決定し、MTCカバレッジエンハンスメントモードの端末が式(1)を用いてPUCCHリソース番号を決定してもよい。MTCでは端末はそれほど頻繁に通信を行わないことが想定されることから、MTCカバレッジエンハンスメントモードの端末のPUCCH領域の使用頻度は少ないことが想定される。また、上りリンクでは、システム帯域の中心にPUSCH領域(Physical Downlink Shared Channel)が配置され、両端にPUCCH領域が配置され、PUCCHリソース(例えば、図11を参照)には上記PUCCH領域の外側から内側へ向かってPUCCHリソース番号が昇順に付されている。よって、式(1)によって対応付けられた、使用頻度が少ないMTCカバレッジエンハンスメントモードの端末のPUCCH領域は、上りリンクの内側の周波数帯域に配置されるので、上りリンクデータ用の周波数帯域と連続させることができる。このようにすることで、MTCカバレッジエンハンスメントモードの端末がPUCCHリソースを使用していない場合に、そのリソースを上りリンクデータ(PUSCH)に用いることができる。また、MTCカバレッジエンハンスメントモードの端末のPUCCH領域がPUSCH領域と連続していることで、連続する複数のサブキャリアをまとめて特定の端末に割り当てて、ピーク対送信電力比(PAPR: Peak-to-Average Power Ratio)の増加を抑えることができる。
(実施の形態3)
本実施の形態に係る基地局及び端末の基本構成は、実施の形態1と同様であるので、図8(基地局100)と図9(端末200)を援用して説明する。
以下では、通常モードの端末と、MTCカバレッジエンハンスメントモードの端末とが基地局100のセル内に共存する場合について説明する。
本実施の形態に係る基地局100は、各端末200に対して、PUCCHリソースに関する情報を予め通知する。PUCCHリソースに関する情報は、例えば、PUCCHリソース(例えば、図3を参照)の1直交系列において隣接する利用可能なPUCCHリソース間の巡回シフト量の差、及び、各PUCCH領域に配置される1RBあたりに符号多重されるPUCCHリソースの最大数に関する情報を含む。
また、通常モードの端末及びMTCカバレッジエンハンスメントモードの端末の各々に対して異なるPUCCHリソース領域が設定される。以下の説明では、MTCカバレッジエンハンスメントモードの端末に対するPUCCHリソースの割当として、CCE番号に対応付けてImplicitに通知する場合について説明する。例えば、通常モードの端末及びMTCカバレッジエンハンスメントモードの端末に対するPUCCHリソースは、実施の形態1又は実施の形態2と同様の方法により設定されてもよい。ただし、本実施の形態では、MTCカバレッジエンハンスメントモードの端末に対するPUCCHリソースの割当として、上位レイヤシグナリングなどを用いて、基地局100から端末200へExplicitに通知されてもよい。
本実施の形態では、通常モードの端末及びMTCカバレッジエンハンスメントモードの端末に対して上記巡回シフト量の差が独立に設定される。
図12は、本実施の形態に係る、通常モードの端末及びMTCカバレッジエンハンスメントモードの端末に対するPUCCHリソースの一例を示す。図12では、2個のRBの合計72個のPUCCHリソースのうち、12個のPUCCHリソースはSPS/SR用に確保され、48個のPUCCHリソースは通常モードの端末に対して確保され、残りの12個のPUCCHリソースはMTCカバレッジエンハンスメントモードの端末に対して確保されている。
上述したように、図12に示すPUCCHリソースは、直交符号系列(OC index)とZAC系列の巡回シフト量(Cyclic shift Index)との組合せによって定義される。
通常モードの端末には、PUCCHリソースを定義する1直交符号系列において隣接する利用可能なリソース間の巡回シフト量の差Δshift PUCCHが設定される。例えば、図12では、Δshift PUCCH=2が設定されている。すなわち、1つの直交符号系列に対して採りうる12個の巡回シフト量(Cyclic Shift Index=0〜11)について1個おきの巡回シフト量に対応するPUCCHリソースが利用可能となる。よって、通常モードの端末に対しては、1RB(PRB(Physical RB))毎に最大36個のPUCCHリソースのうち、18個のPUCCHリソースが利用可能となる。
図12では、通常モードの端末は、下りリンク割当制御情報を受信した場合、対応する割当制御情報に示される下りリンクデータに対するACK/NACK信号を送信するPUCCHリソースのリソース番号nPUCCHを式(1)に従って決定してもよい(ただし、NPUCCH (1)=6)。
図12では、PUCCHリソース#0を始点として、各直交符号系列において1個おきの巡回シフト量に対応するリソースに対して番号が付与されたPUCCHリソースのうち、PUCCHリソース番号#6〜#29の24個のPUCCHリソースが通常モードの端末が利用可能なPUCCHリソースとなる。
一方、MTCカバレッジエンハンスメントモードの端末には、PUCCHリソースを定義する1直交符号系列において隣接する利用可能なリソース間の巡回シフト量の差Δshift PUCCH_MTCが設定される。例えば、図12では、Δshift PUCCH_MTC=1が設定されている。すなわち、利用可能なPUCCHリソース間の巡回シフト量の差として、通常モードの端末とMTCカバレッジエンハンスメントモードの端末とでは互いに異なるパラメータが設定されている。具体的には、Δshift PUCCH_MTCは、Δshift PUCCHよりも小さい。
すなわち、MTCカバレッジエンハンスメントモードの端末では、1つの直交符号系列に対して採りうる12個の巡回シフト量(Cyclic Shift Index=0〜11)について連続する全ての巡回シフト量に対応するPUCCHリソースが利用可能となる。
図12では、MTCカバレッジエンハンスメントモードの端末は、下りリンク割当制御情報を受信した場合、対応する割当制御情報に示される下りリンクデータに対するACK/NACK信号を送信するPUCCHリソースのリソース番号nPUCCH_MTCを式(2)に従って決定してもよい(ただし、NPUCCH_MTC (1)=60)。
図12では、PUCCHリソース#0を始点として、各直交符号系列において連続する巡回シフト量に対応するリソースに対して番号が付与されたPUCCHリソースのうち、PUCCHリソース番号#60〜#71の12個のPUCCHリソースがMTCカバレッジエンハンスメントモードの端末が利用可能なPUCCHリソースとなる。
なお、端末200は、PUCCHリソース番号に基づいて、実際に使用するOC index及び巡回シフト量を決定する。PUCCHリソース番号と、OC index及び巡回シフト量と、の対応付けは、隣接する巡回シフト量の差に依存する。したがって、本実施の形態では、PUCCHリソース番号から実際に使用するOC index及び巡回シフト量を特定する対応付けが、通常モードの端末とMTCカバレッジエンハンスメントモードの端末とで異なる。具体的には、MTCカバレッジエンハンスメントモードの端末は、既存のシステムにおけるPUCCHリソース番号から実際に使用するOC index及び巡回シフト量を特定する対応付けを示す数式(示さず)におけるΔshift PUCCHをΔshift PUCCH_MTCに置き換えて動作すればよい。
既存のシステム(例えば、3GPP Release 11)では、上述した通常モードの端末に対するPUCCHリソースは確保されていた。これに対して、図12に示すように、MTCカバレッジエンハンスメントモードの端末が存在する場合、通常モードの端末用のPUCCHリソースに加えて、MTCカバレッジエンハンスメントモードの端末用のPUCCHリソースが追加的に設定される。
ここで、図12に示すように、各RB内での最大符号多重可能数は、採りうる巡回シフト量のうちの利用可能な巡回シフト量の数により特定される。具体的には、最大符号多重可能数は、PUCCHリソースとして巡回シフト量をいくつおきに利用可能か(つまり、Δshift PUCCH及びΔshift PUCCH_MTC)によって特定される。
本実施の形態では、通常モードの端末及びMTCカバレッジエンハンスメントモードの端末の各々に対して最大符号多重可能数(巡回シフト量の差)が独立に設定される。具体的には、MTCカバレッジエンハンスメントモードの端末用のPUCCHリソース群の各リソースとして定義された、直交符号系列と巡回シフト量との組合せのうち、同一直交符号系列において隣接する巡回シフト量の差Δshift PUCCH_MTCは、通常モードの端末用のPUCCHリソース群の各リソースとして定義された、直交符号系列と巡回シフト量との組合せのうち、同一直交符号系列において隣接する巡回シフト量の差Δshift PUCCHよりも小さい。
このため、MTCカバレッジエンハンスメントモードの端末用のPUCCHリソース領域では、通常モードの端末用のPUCCHリソース領域と比較して、各PUCCHリソース領域全体に対する利用可能なPUCCHリソースの割合が高くなる。具体的には、図12に示すように、通常モードの端末用PUCCHリソース領域では、48個のPUCCHリソースのうち、24個のPUCCHリソースが利用可能となる。これに対して、MTCカバレッジエンハンスメントモードの端末用PUCCHリソース領域では、12個のPUCCHリソースの全てが利用可能となる。すなわち、MTCカバレッジエンハンスメントモードの端末に対して最大符号多重可能数が最大限となる。
つまり、本実施の形態では、上述したようにMTCカバレッジエンハンスメントモードの端末用のPUCCHリソースにおける最大符号多重可能数を、通常モードの端末用PUCCHリソースにおける最大符号多重可能数よりも多くすることにより、利用可能なPUCCHリソース数を多くして、PUCCHリソースのオーバーヘッドを最小限に抑えることができる。
例えば、12個のPUCCHリソースを利用可能とするためには、Δshift PUCCH_MTC=2の場合には24個のPUCCHリソースを確保する必要があるのに対して、Δshift PUCCH_MTC=1の場合には図12に示すように12個のPUCCHリソースを確保するだけで済む。よって、Δshift PUCCH_MTCをΔshift PUCCHよりも小さくすることにより、通常モードの端末に設定される巡回シフト量の差Δshift PUCCHと同一とする場合と比較して、PUCCHリソースのオーバーヘッドを最小限に抑えることができる。
ところで、同一RB内のPUCCHリソースにおいて、符号多重に用いられなかったPUCCHリソースは、符号拡散による符号間干渉低減効果により符号間干渉の低減に寄与する。例えば、図12に示すように、通常モードの端末用PUCCHリソースでは、利用可能なPUCCHリソース#6〜#29の隣接するリソースの間に利用されないPUCCHリソース(符号多重に用いられないPUCCHリソース)が存在し、当該PUCCHリソースが符号間干渉の低減に寄与する。
これに対して、図12に示すように、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が基地局100から端末200へ新たに通知されればよい。よって、既存のシステムの動作に与える影響は少ない。
また、本実施の形態によれば、通常モードの端末とMTCカバレッジエンハンスメントモードの端末とに対してACK/NACK信号に使用されるPUCCHリソースを異ならせることにより、ACK/NACK信号を送信するPUCCHリソースの衝突を回避できる。
なお、本実施の形態は、通常モードの端末(レピティションを行わない端末)とMTCカバレッジエンハンスメントモードの端末(レピティションを行う端末)とに対して、それぞれ異なる、巡回シフト量の差(つまり、最大符号多重可能数)を用いてPUCCHリソースが設定される場合について説明した。しかし、本実施の形態では、それに限らず同一セル内の端末グループ毎(例えば、同一セル内のマクロ基地局配下の端末とリモートアンテナ局配下の端末など)にそれぞれ異なる、巡回シフト量の差(つまり、最大符号多重可能数)を用いてPUCCHリソースが設定されてもよい。
(実施の形態4)
前述したように、既存システムでは、CCE番号とPUCCHリソース番号とは1対1に対応付けられている。つまり、M個のCCEに対して、CCE数と同数のM個のPUCCHリソースがそれぞれ対応付けられている。例えば、図12では、MTCカバレッジエンハンスメントモードの端末に対して、CCE#0とPUCCH#60、CCE#1とPUCCH#61、CCE#2とPUCCH#62、…がそれぞれ対応付けられている。
また、MTCカバレッジエンハンスメントモードの端末に対して、制御情報の誤り率特性の劣化を抑えるために、制御情報の符号化率が低く設定されることが想定される。つまり、MTCカバレッジエンハンスメントモードの端末に対するPDCCHを構成するL1/L2 CCHのCCEの占有数は比較的多くなることが想定される。例えば、MTCカバレッジエンハンスメントモードの端末に対して、CCEの占有数(アグリゲーションレベルと呼ぶこともある)として採りうる値(例えば、1,2,4,8)のうち、より大きい値(4,8)が設定されることが想定される。
前述したように、MTCカバレッジエンハンスメントモードの端末に対するPDCCHにおいてL1/L2 CCHが複数のCCEを占有する場合、端末は、複数のCCEのうち、1つのCCE(最小のインデックスのCCE)に対応するPUCCHリソースを用いてACK/NACK信号を送信する。よって、ACK/NACK信号の送信に使用されるPUCCHリソースに対応するCCE以外の他のCCEに対応するPUCCHリソースは使用されずに無駄となる。例えば、図12では、MTCカバレッジエンハンスメントモードの端末に対するPDCCHを構成するL1/L2 CCHがCCE#0〜CCE#3の4つのCCEを占有する場合、当該端末は、4つのCCEのうち最小インデックスのCCE#0に対応するPUCCH#60のみを用いてACK/NACK信号を送信する。つまり、CCE#1〜CCE#3に対応するPUCCH#61〜PUCCH#63の物理リソースは使用されず無駄となる。
また、MTCでのトラフィック特性を考慮すると、MTCでの端末は頻繁に通信を行わないことが想定される。すなわち、MTCカバレッジエンハンスメントモードの端末用PUCCHリソースの使用頻度は確率的に低い。
そこで、本実施の形態では、MTCカバレッジエンハンスメントモードの端末に対して、M個のCCEに対してM個のPUCCHリソースを1対1で対応付けるのではなく、M個のCCEに対して、M個より少ないPUCCHリソースを対応付ける。換言すると、MTCカバレッジエンハンスメントモードの端末に対して、1個のPUCCHリソースに対して複数のCCEを関連付ける。
本実施の形態に係る基地局及び端末の基本構成は、実施の形態1と同様であるので、図8(基地局100)と図9(端末200)を援用して説明する。
基地局100及び端末200は、本実施の形態に係るCCEとPUCCHリソースとの対応付けを予め保持する。
以下、本実施の形態に係るCCEとPUCCHリソースとの対応付けに関する方法1及び方法2についてそれぞれ説明する。
なお、本実施の形態では、例えば、図12に示すように、通常モードの端末及びMTCカバレッジエンハンスメントモードの端末の各々に対して異なるPUCCHリソース領域が設定される。例えば、通常モードの端末及びMTCカバレッジエンハンスメントモードの端末に対するPUCCHリソースは、実施の形態1又は実施の形態2と同様の方法により設定されてもよい。ただし、本実施の形態では、MTCカバレッジエンハンスメントモードの端末に対するPUCCHリソースの割当として、上位レイヤシグナリングなどを用いて、基地局100から端末200へExplicitに通知されてもよい。また、MTCカバレッジエンハンスメントモードの端末が利用可能なPUCCHリソース間の巡回シフト量の差は、実施の形態3と同様1とする(Δshift PUCCH_MTC=1)。
以下では、MTCカバレッジエンハンスメントモードの端末用のPUCCHリソース(#60〜#71)に着目する。
<方法1(図13)>
方法1は、CCE番号とPUCCHリソースとの対応付けをN対1とする方法である。
例えば、図13は、N=4とした場合のCCE番号とPUCCHリソース番号との対応付けの一例を示す。
図13に示すように、CCE#0〜CCE#3の4個のCCEは、PUCCH#60に対応付けられ、CCE#4〜CCE#7の4個のCCEは、PUCCH#61に対応付けられ、CCE#8〜CCE#11の4個の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) (4)
式(4)において、関数「floor(X)」は、X以下の最大の整数を返す床関数を表す。また、nCCEは、PDCCHが占有するCCEのうち最も小さいCCEの番号を示し、Nは、1つのPUCCHリソースに対応付けられるCCE数(図13ではN=4)を示す。また、NPUCCH_MTC (1)は、MTCカバレッジエンハスメントモードの端末に対するオフセット値を示す。例えば、図13では、NPUCCH_MTC (1)=60である。
方法1によれば、MTCカバレッジエンハスメントモードの端末用に確保するPUCCHリソース領域は、CCE番号とPUCCH番号とを1対1で対応付ける場合と比較して、1/Nに削減される。具体的には、CCE番号とPUCCH番号とを1対1で対応付ける場合には、12個のCCEに対して12個のPUCCHリソースを確保する必要があったのに対して、方法1では、図13の場合(N=4の場合)、12個のCCEに対して3個のPUCCHリソースのみを確保すればよい。
<方法2>
方法2は、1つのPUCCHリソースに対応付けられるCCE数を、CCEの占有数(アグリゲーションレベル)として採りうる値とする方法である。
例えば、方法2では、MTCカバレッジエンハンスメントモードの端末に対してCCE占有数N(>1)が設定されるとする。
例えば、図14は、N=4とした場合のCCE番号とPUCCHリソース番号との対応付けの一例を示す。
図14に示すように、CCE#0〜CCE#3の4個のCCEは、PUCCH#60に対応付けられ、CCE#4〜CCE#7の4個のCCEは、PUCCH#61に対応付けられ、CCE#8〜CCE#11の4個のCCEは、PUCCH#62に対応付けられている。つまり、CCE占有数N個のCCE毎に1つのPUCCHリソースが対応付けられる。
MTCカバレッジエンハンスメントモードの端末には、図14に示す4個の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) (5)
式(5)においてnCCEは、PDCCHが占有するCCEのうち最も小さいCCEの番号を示し、Nは、MTCカバレッジエンハンスメントモードの端末に対するCCE占有数(図13ではN=4)を示す。また、NPUCCH_MTC (1)は、MTCカバレッジエンハスメントモードの端末に対するオフセット値を示す。例えば、図14では、NPUCCH_MTC (1)=60である。
方法2によれば、MTCカバレッジエンハスメントモードの端末用に確保するPUCCHリソース領域は、CCE番号とPUCCH番号とを1対1で対応付ける場合と比較して、1/Nに削減される。具体的には、CCE番号とPUCCH番号とを1対1で対応付ける場合には、12個のCCEに対して12個のPUCCHリソースを確保する必要があったのに対して、方法2では、図14の場合(N=4の場合)、12個のCCEに対して3個のPUCCHリソースのみを確保すればよい。
また、各PUCCHリソースは、各端末が占有するCCE数の単位でCCEに対応付けられているので、1つのPUCCHリソースに対応付けられたN個のCCEが複数の端末間で同時に使用されることはない。
以上、方法1及び方法2について説明した。
このように、本実施の形態では、MTCカバレッジエンハンスメントモードの端末に対して、複数のCCEを1個のPUCCHリソースに関連付ける。これにより、MTCカバレッジエンハンスメントモードの端末用のPUCCHリソースとして確保するリソースの増加を抑えることができる。よって、MTCカバレッジエンハンスメントモードの端末が存在するシステム(MTCカバレッジエンハンスメントモードの端末用のPUCCHリソースが追加的に設定される場合)でも、PUCCHリソースのオーバーヘッドの増加を抑えることができる。
また、本実施の形態によれば、通常モードの端末とMTCカバレッジエンハンスメントモードの端末とに対してACK/NACK信号に使用されるPUCCHリソースを異ならせることにより、ACK/NACK信号を送信するPUCCHリソースの衝突を回避できる。
(実施の形態5)
MTCカバレッジエンハンスメントモードの端末間において、既存のシステムと同様にしてCCE番号と対応付けてPUCCHリソース番号をImplicitに通知するのでは、PDCCH及びPUCCHのレピティションレベルが異なる端末が存在すると、同一PUCCHリソースを用いてACK/NACK信号が同時に送信され、PUCCHリソースの衝突が発生する場合がある。
図15は、MTCカバレッジエンハンスメントモードの端末間のPUCCHリソースが衝突する場合の一例を示す。図15では、端末1(UE#1)及び端末2(UE#2)のPDCCH及びPDSCHのレピティションレベルをそれぞれNPDCCH、NPDSCHとする。また、端末1のPUCCHのレピティションレベルをNPUCCH+αPUCCHとし、端末2のPUCCHのレピティションレベルをNPUCCHとする。つまり、端末1では、端末2と比較して、NPDCCH、NPDSCHが同一であり、PUCCHのレピティションレベルがαPUCCHだけ大きい。
また、図15では、端末1がCCE#0からCCE#3を用いてPDCCHを送信する。一方、端末2は、端末1のPDCCHが送信完了した次のサブフレームから、CCE#0からCCE#3を用いてPDCCHを送信する。つまり、端末1及び端末2の双方は、CCE#0に対応付けられたPUCCHリソースを用いてACK/NACK信号を送信する。
図15に示すように、端末1は、NPUCCH+αPUCCHサブフレームに渡ってACK/NACK信号を送信し、端末2は、端末1がACK/NACK信号をNPUCCHサブフレーム送信した次のサブフレームからNPUCCHに渡ってACK/NACK信号を送信する。このため、図15に示すように、端末1のPUCCHレピティション後半のαPUCCHサブフレーム、及び、端末2のPUCCHレピティション前半のαPUCCHサブフレームに相当するサブフレームにおいてPUCCHリソースが端末間で衝突してしまう。
そこで、本実施の形態では、MTCカバレッジエンハンスメントモードの端末間のACK/NACK信号を送信するPUCCHリソースの衝突を回避する方法について説明する。
本実施の形態に係る基地局及び端末の基本構成は、実施の形態1と同様であるので、図8(基地局100)と図9(端末200)を援用して説明する。
具体的には、端末200(MTCカバレッジエンハンスメントモードの端末)は、PDCCHとPUCCHとのレピティションレベルが異なる場合、PUCCHレピティションにおいて、PDCCHのレピティションレベルと同数のサブフレームまでは、CCE番号(つまり、最小のCCE番号)に対応付けてImplicitに通知されるPUCCHリソースを用いて、ACK/NACK信号を送信する。
一方、端末200は、PDCCHのレピティションレベルを超えるサブフレームでは、Explicitに割り当てられたPUCCHリソースを用いてACK/NACK信号を送信する。当該PUCCHリソースは、基地局100から端末200に対して予め通知される。
図16は、本実施の形態に係る各チャネルの送信タイミングを示す。図16では、図15と同様、端末1(UE#1)及び端末2(UE#2)のPDCCH及びPDSCHのレピティションレベルをそれぞれNPDCCH、NPDSCHとする。また、端末1のPUCCHのレピティションレベルをNPUCCH+αPUCCHとし、端末2のPUCCHのレピティションレベルをNPUCCHとする。また、図16では、NPUCCHはNPDCCHと同一である。
また、図16では、端末1がCCE#0からCCE#3を用いてPDCCHを送信する。一方、端末2は、端末1のPDCCHが送信完了した次のサブフレームから、CCE#0からCCE#3を用いてPDCCHを送信する。
この場合、図16に示すように、端末1は、PUCCHレピティションにおいて、NPUCCH+αPUCCHサブフレームのうち、NPDCCHと同数のNPUCCHサブフレームまでは、PDCCHに使用されたCCEのうち最小のインデックスを有するCCE#0に対応付けられたPUCCHリソースを用いてACK/NACK信号を送信する。
一方、端末1は、NPUCCH+αPUCCHサブフレームのうち、NPUCCHサブフレームを超えたαPUCCHサブフレーム以降では、Explicitに通知されたPUCCHリソースを用いてACK/NACK信号を送信する。
また、図16に示すように、端末2は、PUCCHレピティションにおいて、端末1がACK/NACK信号をNPUCCHサブフレーム送信した次のサブフレームからNPUCCHサブフレームに渡って、PDCCHに使用されたCCEのうち最小のインデックスを有するCCE#0に対応付けられたPUCCHリソースを用いてACK/NACK信号を送信する。
つまり、図16では、端末1のPUCCHレピティション後半のαPUCCHサブフレーム、及び、端末2のPUCCHレピティション前半のαPUCCHサブフレームに該当するサブフレームでは、端末1及び端末2の双方において互いに異なるPUCCHリソースが用いられる。よって、端末1と端末2との間でのPUCCHリソースの衝突は発生しない。
このように、端末200は、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リソースが端末間で衝突することを回避することができる。
なお、本実施の形態は、実施の形態1〜4の動作と組み合わせてもよい。つまり、MTCカバレッジエンハンスメントモードの端末同士のPUCCHリソースの衝突を回避する方法について本実施の形態を適用し、MTCカバレッジエンハンスメントモードの端末と通常モードの端末との間のPUCCHリソースの衝突を回避する方法について、実施の形態1〜4のいずれかを適用すればよい。
(実施の形態6)
実施の形態5では、PDCCHとPUCCHのレピティションレベルが異なる端末について説明した。これに対し、本実施の形態では、各端末でのPDCCHとPUCCHのレピティションレベルは同一であるが、端末間のレピティションレベルが異なる場合について説明する。
この場合、MTCカバレッジエンハンスメントモードの端末間において、既存のシステムと同様にしてCCE番号と対応付けてPUCCHリソース番号をImplicitに通知するのでは、端末間において同一PUCCHリソースを用いてACK/NACK信号が同時に送信され、PUCCHリソースの衝突が発生する場合がある。
図17は、MTCカバレッジエンハンスメントモードの端末間のPUCCHリソースが衝突する場合の一例を示す。図17では、端末1(UE#1)のPDCCH、PDSCH、PUCCHのレピティションレベルが8であり、端末2(UE#2)のPDCCH、PDSCH、PUCCHのレピティションレベルが4である。
また、図17では、端末1がCCE#0からCCE#3を用いてPDCCHを送信する。一方、端末2は、端末1のPDCCHが送信完了した次のサブフレームから、CCE#0からCCE#3を用いてPDCCHを送信する。つまり、端末1及び端末2の双方は、CCE#0に対応付けられたPUCCHリソースを用いてACK/NACK信号を送信する。
図17に示すように、端末1は、8サブフレームに渡ってPDCCHを受信し、次の8サブフレームに渡ってPDSCHを受信する。一方、端末2は、端末1がPDCCHの受信を完了した次のサブフレームから4サブフレームに渡ってPDCCHを受信し、次の4サブフレームに渡ってPDSCHを受信する。つまり、端末1と端末2とは、PDSCHの受信完了のタイミング(又はACK/NACK信号の送信開始タイミング)が同一となる。
この場合、同一タイミングにおいて、端末1は、8サブフレームに渡ってACK/NACK信号を送信し、端末2は、4サブフレームに渡ってACK/NACK信号を送信する。このため、図17に示すように、端末1のPUCCHレピティション前半の4サブフレーム、及び、端末2のPUCCHレピティションの全4サブフレームに相当するサブフレームにおいてPUCCHリソースが端末間で衝突してしまう。
そこで、本実施の形態では、レピティションレベルが互いに異なるMTCカバレッジエンハンスメントモードの端末間のACK/NACK信号を送信するPUCCHリソースの衝突を回避する方法について説明する。
本実施の形態に係る基地局及び端末の基本構成は、実施の形態1と同様であるので、図8(基地局100)と図9(端末200)を援用して説明する。
具体的には、端末200(MTCカバレッジエンハンスメントモードの端末)は、PUCCHレピティションにおいて、PDCCHの送信に使用されたCCE番号(つまり、最小のCCE番号)に対応付けてImplicitに通知されるPUCCHリソースを用いて、ACK/NACK信号を送信する。ただし、端末200は、設定されるレピティションレベル毎に異なるオフセット値を用いて特定されるPUCCHリソースを用いてACK/NACK信号を送信する。
例えば、レピティションレベルが4の場合のPUCCHリソース番号nPUCCH_MTC_4、及び、レピティションレベルが8の場合のPUCCHリソース番号nPUCCH_MTC_8は、次式に従って決定される。
nPUCCH_MTC_4=nCCE+NPUCCH_MTC_4 (1) (6)
nPUCCH_MTC_8=nCCE+NPUCCH_MTC_8 (1) (7)
式(6)、(7)において、nCCEは、PDCCHが占有するCCE番号(0以上の整数)を示す。また、式(6)、(7)において、NPUCCH_MTC_4 (1)は、レピティションレベルが4の場合にCCE番号からPUCCHリソース番号を特定するためのオフセット値を示し、NPUCCH_MTC_8 (1)は、レピティションレベルが8の場合にCCE番号からPUCCHリソース番号を特定するためのオフセット値を示す。
NPUCCH_MTC_4 (1)とNPUCCH_MTC_8 (1)は、異なる値が設定される。換言すると、端末200が利用可能なPUCCHリソースは、少なくとも、レピティションレベルが4の場合のPUCCHリソースと、レピティションレベルが8の場合のPUCCHリソースとに分割される。つまり、端末200が利用可能なPUCCHリソース群は、ACK/NACK信号のレピティションレベル毎の複数のサブリソース群から構成される。
なお、ここでは、レピティションレベルが4、8の場合について説明するが、レピティションレベルは4,8に限定されず、他の値を採り得る場合にはその値についても同様にしてオフセット値が設定される。
図18は、本実施の形態に係る各チャネルの送信タイミングを示す。図18では、図17と同様、端末1(UE#1)のPDCCH、PDSCH、PUCCHのレピティションレベルが8であり、端末2(UE#2)のPDCCH、PDSCH、PUCCHのレピティションレベルが4である。また、図18では、端末1がCCE#0からCCE#3を用いてPDCCHを送信する。一方、端末2は、端末1のPDCCHが送信完了した次のサブフレームから、CCE#0からCCE#3を用いてPDCCHを送信する。
この場合、図18に示すように、端末1は、PUCCHレピティションにおいて、式(6)に従って、NPUCCH_MTC_8 (1)+nCCE=NPUCCH_MTC_8 (1)のPUCCHリソースを用いてACK/NACK信号を送信する。一方、端末2は、PUCCHレピティションにおいて、式(7)に従って、NPUCCH_MTC_4 (1)+nCCE=NPUCCH_MTC_4 (1)のPUCCHリソースを用いてACK/NACK信号を送信する。
上述したように、NPUCCH_MTC_4 (1)とNPUCCH_MTC_8 (1)とは互いに異なる。よって、図18に示すように、端末1のPUCCHレピティション前半の4サブフレーム、及び、端末2のPUCCHレピティションの全4サブフレームに該当するサブフレームでは、端末1及び端末2の双方において互いに異なるPUCCHリソースが用いられる。このため、端末1と端末2との間でのPUCCHリソースの衝突は発生しない。
このようにすることで,レピティションレベルが異なるMTCカバレッジエンハンスメントモードの端末間において、同一のCCEを用いてPDCCHを送信し、ACK/NACK信号を同時に送信するサブフレームが発生しても、ACK/NACK信号を送信するPUCCHリソースが端末間で衝突することを回避することができる。
なお、本実施の形態は、実施の形態1〜4の動作と組み合わせて実施してもよい。つまり、MTCカバレッジエンハンスメントモードの端末同士のPUCCHリソースの衝突を回避する方法について本実施の形態を適用し、MTCカバレッジエンハンスメントモードの端末と通常モードの端末との間のPUCCHリソースの衝突を回避する方法について、実施の形態1〜4のいずれかを適用すればよい。
以上、本開示の各実施の形態について説明した。
なお、上記各実施の形態では、本開示の一態様をハードウェアで構成する場合を例にとって説明したが、本開示はソフトウェアで実現することも可能である。
また、上記各実施の形態の説明に用いた各機能ブロックは、典型的には集積回路であるLSIとして実現される。これらは個別に1チップ化されてもよいし、一部または全てを含むように1チップ化されてもよい。ここでは、LSIとしたが、集積度の違いにより、IC、システムLSI、スーパーLSI、ウルトラLSIと呼称されることもある。
また、集積回路化の手法はLSIに限るものではなく、専用回路または汎用プロセッサで実現してもよい。LSI製造後に、プログラムすることが可能なFPGA(Field Programmable Gate Array)や、LSI内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサーを利用してもよい。
さらには、半導体技術の進歩または派生する別技術によりLSIに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。
本開示の端末は、下りリンクデータの割当を示す制御情報、及び、前記下りリンクデータを受信する受信部と、前記制御情報に基づいて、前記下りリンクデータに対する応答信号に使用されるリソースを決定する制御部と、前記決定されたリソースを用いて前記応答信号を送信する送信部と、を具備し、前記送信部は、自端末が、前記制御情報、前記下りリンクデータ及び前記応答信号に対してレピティション送信が適用される第1の端末である場合には第1のリソース群の中のリソースを用いて前記応答信号を送信し、自端末が、前記レピティション送信が適用されない第2の端末である場合には前記第1のリソース群とは異なる第2のリソース群の中のリソースを用いて前記応答信号を送信する構成を採る。
本開示の端末において、前記制御部は、前記制御情報に使用されるコントロール・チャネル・エレメント(CCE)のインデックスに第1のオフセット値を加算して、前記第1のリソース群において前記応答信号に使用されるリソースを算出し、前記制御情報に使用される前記CCEのインデックスに第2のオフセット値を加算して、前記第2のリソース群において前記応答信号に使用されるリソースを算出し、前記第1のオフセット値と前記第2のオフセット値とは異なる。
本開示の端末において、前記制御部は、前記制御情報に使用されるコントロール・チャネル・エレメント(CCE)のインデックスにオフセット値を加算して、前記第1のリソース群において前記応答信号に使用されるリソースを算出し、前記オフセット値から、前記制御情報に使用される前記CCEのインデックスを減算して、前記第2のリソース群において前記応答信号に使用されるリソースを算出する。
本開示の端末において、前記第1のリソース群及び前記第2のリソース群の各リソースは、直交符号系列と巡回シフト量との組合せによってそれぞれ定義され、前記第1のリソース群の各リソースとして定義された前記組合せのうち、同一直交符号系列において隣接する巡回シフト量の差は、前記第2のリソース群の各リソースとして定義された前記組合せのうち、同一直交符号系列において隣接する巡回シフト量の差よりも小さい。
本開示の端末において、前記制御情報に使用されるコントロール・チャネル・エレメント(CCE)の複数個に対して、前記第1のリソース群の1つのリソースが対応付けられる。
本開示の端末において、前記複数個は、前記割当情報が占有するCCEの個数である。
本開示の端末において、前記送信部は、前記応答信号の前記レピティション送信が行われる複数のサブフレームのうち、前記制御情報のレピティション回数以下のサブフレームでは、前記第1のリソース群のうち、前記制御情報に使用されるコントロール・チャネル・エレメント(CCE)に対応付けられたリソースを用いて、前記応答信号を送信し、前記制御情報のレピティション回数を超えるサブフレームでは、予め設定されたリソースを用いて、前記応答信号を送信する。
本開示の端末において、前記第1のリソース群は、前記応答信号のレピティション回数毎の複数のサブリソース群から構成される。
本開示の基地局は、下りリンクデータの割当を示す制御情報、及び、前記下りリンクデータを送信する送信部と、前記制御情報に基づいて、前記下りリンクデータに対する応答信号に使用されるリソースを決定する制御部と、前記決定されたリソースを用いて前記応答信号を受信する受信部と、を具備し、前記受信部は、前記制御情報、前記下りリンクデータ及び前記応答信号に対してレピティション送信が適用される第1の端末から送信される前記応答信号を、第1のリソース群の中のリソースを用いて受信し、前記レピティション送信が適用されない第2の端末から送信される前記応答信号を、前記第1のリソース群とは異なる第2のリソース群の中のリソースを用いて受信する。
本開示の送信方法は、下りリンクデータの割当を示す制御情報、及び、前記下りリンクデータを受信する受信工程と、前記制御情報に基づいて、前記下りリンクデータに対する応答信号に使用されるリソースを決定する制御工程と、前記決定されたリソースを用いて前記応答信号を送信する送信工程と、を具備し、前記送信工程は、前記制御情報、前記下りリンクデータ及び前記応答信号に対してレピティション送信が適用される第1の端末では第1のリソース群の中のリソースを用いて前記応答信号を送信し、前記レピティション送信が適用されない第2の端末では前記第1のリソース群とは異なる第2のリソース群の中のリソースを用いて前記応答信号を送信する。
本開示の受信方法は、下りリンクデータの割当を示す制御情報、及び、前記下りリンクデータを送信する送信工程と、前記制御情報に基づいて、前記下りリンクデータに対する応答信号に使用されるリソースを決定する制御工程と、前記決定されたリソースを用いて前記応答信号を受信する受信工程と、を具備し、前記受信工程は、前記制御情報、前記下りリンクデータ及び前記応答信号に対してレピティション送信が適用される第1の端末から送信される前記応答信号を、第1のリソース群の中のリソースを用いて受信し、前記レピティション送信が適用されない第2の端末から送信される前記応答信号を、前記第1のリソース群とは異なる第2のリソース群の中のリソースを用いて受信する。
本開示の一態様は、PDCCHリソースの周波数利用効率の低下及びスケジューリングの複雑度の増加をさせることなく、通常モードの端末とMTCカバレッジエンハンスメントモードの端末との間のPUCCHリソースの衝突を回避することができる端末、通信方法及び集積回路を提供することである。