図面 (/)

技術 基地局、通信方法及び集積回路

出願人 サンパテントトラスト
発明者 山本哲矢ガオチー鈴木秀俊中尾正悟
出願日 2020年11月2日 (7ヶ月経過) 出願番号 2020-183709
公開日 2021年2月12日 (3ヶ月経過) 公開番号 2021-016188
状態 未査定
技術分野 移動無線通信システム
主要キーワード 占有数 使用確率 最小インデックス タイプ通信 次拡散 ブロックワイズ インフラシステム 同一系列
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2021年2月12日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (19)

課題

通常モードの端末MTCカバレッジエンハンスメントモードの端末との間のPUCCHリソース衝突を回避する。

解決手段

受信部202は、下りリンクデータ割当を示す制御情報、及び、前記下りリンクデータを受信し、送信部は、自端末が、レピティション送信が適用される第1の端末である場合には第1のリソース群の中のリソースを用いて応答信号を送信し、自端末が、レピティション送信が適用されない第2の端末である場合には第1のリソース群とは異なる第2のリソース群の中のリソースを用いて応答信号を送信する。

概要

背景

3GPPLTE(3rd Generation Partnership Project Long Term Evolution)では、下りリンク通信方式として直交周波数分割マルチアクセス(OFDMA:Orthogonal Frequency Division Multiple Access)が採用されている。

3GPPLTEが適用された無線通信システムでは、基地局(eNBと呼ぶこともある)は、予め定められた通信リソースを用いて、同期信号(SCH: Synchronization Channel)及び報知信号(PBCH: Physical Broadcast Channel)を送信する。そして、端末(UE(User Equipment)と呼ぶこともある)は、まずSCHを捕まえることによって基地局との同期を確保する。その後、端末は、BCH情報を読むことにより基地局独自のパラメータ(例えば、周波数帯域幅など)を取得する(例えば、非特許文献1〜3を参照)。

また、端末は、基地局独自のパラメータの取得が完了した後、基地局に対して接続要求を行うことにより、基地局との通信確立する。基地局は、通信が確立された端末に対して、必要に応じてPDCCH(Physical Downlink Control Channel)等の制御チャネルを介して制御情報を送信する。そして、端末は、受信したPDCCH信号に含まれる複数の制御情報をそれぞれ「ブラインド判定」する。すなわち、制御情報は、CRC(Cyclic Redundancy Check)部分を含み、このCRC部分は、基地局において、送信対象端末の端末IDによってマスクされる。従って、端末は、受信した制御情報のCRC部分を自機の端末IDによってデマスクしてみるまでは、自機宛の制御情報であるか否かを判定できない。このブラインド判定では、デマスクした結果、CRC演算がOKとなれば、その制御情報が自機宛であると判定される。

また、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は、1つ又は複数のL1/L2 CCH(L1/L2 Control Channel)から構成される。各L1/L2 CCHは、1つ又は複数のCCE(Control Channel Element)から構成される。すなわち、CCEは、制御情報をPDCCHにマッピングするときの基本単位である。また、1つのL1/L2 CCHが複数のCCEから構成される場合には、そのL1/L2 CCHには連続する複数のCCEが割り当てられる。基地局は、リソース割当対象端末に対する制御情報の通知に必要なCCE数に従って、そのリソース割当対象端末に対してL1/L2 CCHを割り当てる。そして、基地局は、このL1/L2 CCHのCCEに対応する物理リソースに制御情報をマッピングして送信する。

また、各CCEは、PUCCHの構成リソース(以下、PUCCHリソースと呼ぶ)と1対1に対応付けられている。したがって、L1/L2 CCHを受信した端末は、このL1/L2 CCHを構成するCCEに対応するPUCCHリソースを特定し、このPUCCHリソースを用いてACK/NACK信号を基地局へ送信する。ただし、L1/L2 CCHが連続する複数のCCEを占有する場合には、端末は、複数のCCEにそれぞれ対応する複数のPUCCHリソースのうち1つのリソース(例えば、インデックスが最も小さいCCEに対応するPUCCHリソース)を利用して、ACK/NACK信号を基地局へ送信する。

また、図1に示すように、端末におけるPUCCHでのACK/NACK信号の送信タイミングは、受信したPDCCH信号及びそのPDDCH信号によりデータが割り当てられたPDSCH(Physical Downlink Shared Channel)信号を受信したサブフレーム(図1ではサブフレームn)から、Kサブフレーム後(例えばFDD(Frequency Division Duplex)ではK=4)のサブフレーム(図1ではサブフレームn+K)となる。

複数の端末から送信される複数のACK/NACK信号は、図2に示すように、時間軸上においてZero Auto-correlation特性を持つZAC(Zero Auto-correlation)系列ウォルシュ(Walsh)系列及びDFT(Discrete Fourier Transform)系列によって拡散され、PUCCH内においてコード多重されている。図2において、(W(0), W(1), W(2), W(3))は系列長4のウォルシュ系列を表し、(F(0),F(1),F(2))は系列長3のDFT系列を表す。

図2に示すように、端末ではACK/NACK信号は、まず周波数軸上においてZAC系列(系列長12)によって1SC-FDMA(Single-Carrier Frequency Division Multiple Access)シンボルに対応する周波数成分へ1次拡散される。つまり、系列長12のZAC系列に対して、複素数で表されるACK/NACK信号成分が乗算される。次に、1次拡散後のACK/NACK信号、及び、参照信号としてのZAC系列は、それぞれウォルシュ系列(系列長4: W(0)〜W(3))及びDFT系列(系列長3: F(0)〜F(2))によって2次拡散される。つまり、系列長12の信号(1次拡散後のACK/NACK信号、又は、参照信号としてのZAC系列)のそれぞれの成分に対して、直交符号系列(Orthogonal sequence: ウォルシュ系列又はDFT系列)の各成分が乗算される。さらに、2次拡散された信号は、逆離散フーリエ変換(IDFT: Inverse Discrete Fourier Transform。又はIFFT: Inverse Fast Fourier Transform)によって時間軸上の系列長12の信号に変換される。そして、IFFT後の信号のそれぞれに対して、サイクリックプリフィックス(CP:Cyclic Prefix)が付加され、7つのSC-FDMAシンボルからなる1スロットの信号が形成される。

PUCCHは、周波数軸においてシステム帯域両端に配置される。また、PUCCHでは、サブフレーム単位で各端末に無線リソースが割り当てられる。また、1サブフレームは2スロットで構成され、PUCCHは前半スロットと後半スロットとで周波数ホッピングスロット間周波数ホッピング)される。

異なる端末からのACK/NACK信号同士は、異なる巡回シフト量(Cyclic Shift Index)に対応するZAC系列、又は、異なる系列番号(OC Index: Orthogonal Cover Index)に対応する直交符号系列を用いて拡散されている。直交符号系列は、ウォルシュ系列とDFT系列との組である。また、直交符号系列は、ブロックワイズ拡散コード系列(Block-wise spreading code)と称されることもある。したがって、基地局は、従来の逆拡散及び相関処理を用いることにより、これらのコード多重された複数のACK/NACK信号を分離することができる(例えば、非特許文献4を参照)。図3は、直交符号系列の系列番号(OC index:0〜2)及びZAC系列の巡回シフト量(Cyclic shift Index:0〜11)によって定義されるPUCCHリソースを示す。系列長4のウォルシュ系列及び系列長3のDFT系列を用いた場合、同一サブキャリアには最大で3*12=36個のPUCCHリソースがある。ただし、36個のPUCCHリソースをすべて利用可能とするとは限らない。例えば、図3では18個のPUCCHリソース(#0〜#17)を利用可能とした場合を示す。

ところで、今後の情報社会支え仕組みとして、近年、ユーザの判断を介することなく機器間自律的な通信によりサービスを実現するM2M(Machine-to-Machine)通信が期待されている。M2Mシステムの具体的な応用事例としてスマートグリッドがある。スマートグリッドは、電気又はガスなどのライフラインを効率的に供給するインフラシステムであり、各家庭又はビル配備されるスマートメータ中央サーバとの間でM2M通信を実施して、自律的かつ効果的に資源需要バランスを調整する。M2M通信システムの他の応用事例として、物品管理又は遠隔医療などのためのモニタリングシステム自動販売機在庫又は課金遠隔管理などが挙げられる。

M2M通信システムにおいては、特に広範な通信エリアを有するセルラシステムの利用が着目されている。3GPPでは、LTE及びLTE-Advancedの規格化においてセルラネットワーク前提としたM2Mの検討が、マシンタイプ通信MTC: Machine Type Communication)という名称で進められている。特に、ビルの地下などにあるスマートメータなどMTC通信機器が既存の通信エリアにおいて利用できない場所に配置されている場合に対応するため、通信エリアをさらに拡大する「カバレッジエンハンスメント(Coverage Enhancement)」が検討されている(例えば、非特許文献5を参照)。

特に、MTCカバレッジエンハンスメントでは、同一信号を複数回繰り返して送信するレピティションが通信エリア拡大の重要な技術であると考えられている。具体的には、PDCCH、PDSCH及びPUCCH等の各チャネルにおいてレピティション送信を行うことが想定されている。

概要

通常モードの端末とMTCカバレッジエンハンスメントモードの端末との間のPUCCHリソースの衝突を回避する。受信部202は、下りリンクデータの割当を示す制御情報、及び、前記下りリンクデータを受信し、送信部は、自端末が、レピティション送信が適用される第1の端末である場合には第1のリソース群の中のリソースを用いて応答信号を送信し、自端末が、レピティション送信が適用されない第2の端末である場合には第1のリソース群とは異なる第2のリソース群の中のリソースを用いて応答信号を送信する。

目的

本開示の一態様は、PDCCHリソースの周波数利用効率の低下及びスケジューリング複雑度の増加をさせることなく、通常モードの端末とMTCカバレッジエンハンスメントモードの端末との間のPUCCHリソースの衝突を回避することができる端末、通信方法及び集積回路を提供する

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

下り制御情報、及び、下りデータを、端末に送信する送信部と、前記制御情報に基づいて決定された上り制御チャネルリソースとの対応付けから特定される、複数の直交符号系列のうちの一つ及び複数の巡回シフト量のうちの一つの組合せを用いて前記端末から送信された、前記下りデータに対する応答信号を受信する受信部と、を具備し、前記対応付けは、一つの直交符号系列に組み合わされる隣接する巡回シフト量の差に基づき、前記応答信号を複数のサブフレームに渡ってレピティション送信することが可能なカバレッジエンハンスメントモードが前記端末に設定されている場合の前記巡回シフト量の差は、前記カバレッジエンハンスメントモードが前記端末に設定されていない場合の前記巡回シフト量の差とは独立に設定される、基地局。

請求項2

下り制御情報、及び、下りデータを、端末に送信する送信部と、前記制御情報に基づいて決定された上り制御チャネルリソースとの対応付けから特定される、複数の直交符号系列のうちの一つ及び複数の巡回シフト量のうちの一つの組合せを用いて前記端末から送信された、前記下りデータに対する応答信号を受信する受信部と、を具備し、前記対応付けは、一つの直交符号系列に組み合わされる隣接する巡回シフト量の差に基づき、カバレッジエンハンスメントモードが設定された複数のサブフレームに渡ってレピティション送信が可能な前記下り制御情報を前記端末に送信した場合の前記巡回シフト量の差は、前記カバレッジエンハンスメントモードが設定されていない場合の前記巡回シフト量の差とは独立に設定される、基地局。

請求項3

前記カバレッジエンハンスメントモードにおいて、前記送信部は、複数のサブフレームに渡って、前記下り制御情報をリピティション送信する、請求項1又は2に記載の基地局。

請求項4

前記カバレッジエンハンスメントモードにおける前記対応付けが、前記カバレッジエンハンスメントモードが設定されていない場合の前記対応付けと異なる、請求項1から3のいずれかに記載の基地局。

請求項5

前記カバレッジエンハンスメントモードにおける前記巡回シフト量の差は、前記カバレッジエンハンスメントモードが設定されていない場合の前記巡回シフト量の差とは異なる、請求項1から4のいずれかに記載の基地局。

請求項6

前記カバレッジエンハンスメントモードにおいて、前記受信部は、前記端末から複数のサブフレームに渡ってリピティション送信された前記応答信号を受信する、請求項1から5のいずれかに記載の基地局。

請求項7

前記カバレッジエンハンスメントモードにおいて、前記受信部は、前記端末が前記下りデータを受信したサブフレームから所定数のサブフレーム後に、前記応答信号を受信する、請求項1から6のいずれかに記載の基地局。

請求項8

前記カバレッジエンハンスメントモードにおいて、前記送信部は、複数のサブフレームに渡って、前記下りデータをリピティション送信する、請求項1から7のいずれかに記載の基地局。

請求項9

基地局が、下り制御情報、及び、下りデータを、端末に送信する送信工程と、前記制御情報に基づいて決定された上り制御チャネルリソースとの対応付けから特定される、複数の直交符号系列のうちの一つ及び複数の巡回シフト量のうちの一つの組合せを用いて前記端末から送信された、前記下りデータに対する応答信号を受信する受信工程と、を具備し、前記対応付けは、一つの直交符号系列に組み合わされる隣接する巡回シフト量の差に基づき、前記応答信号を複数のサブフレームに渡ってレピティション送信することが可能なカバレッジエンハンスメントモードが前記端末に設定されている場合の前記巡回シフト量の差は、前記カバレッジエンハンスメントモードが前記端末に設定されていない場合の前記巡回シフト量の差とは独立に設定される、通信方法

請求項10

基地局が、下り制御情報、及び、下りデータを、端末に送信する送信工程と、前記制御情報に基づいて決定された上り制御チャネルリソースとの対応付けから特定される、複数の直交符号系列のうちの一つ及び複数の巡回シフト量のうちの一つの組合せを用いて前記端末から送信された、前記下りデータに対する応答信号を受信する受信工程と、を具備し、前記対応付けは、一つの直交符号系列に組み合わされる隣接する巡回シフト量の差に基づき、カバレッジエンハンスメントモードが設定された複数のサブフレームに渡ってレピティション送信が可能な前記下り制御情報を前記端末に送信した場合の前記巡回シフト量の差は、前記カバレッジエンハンスメントモードが設定されていない場合の前記巡回シフト量の差とは独立に設定される、通信方法。

請求項11

下り制御情報、及び、下りデータを、端末に送信する送信処理と、前記制御情報に基づいて決定された上り制御チャネルリソースとの対応付けから特定される、複数の直交符号系列のうちの一つ及び複数の巡回シフト量のうちの一つの組合せを用いて前記端末から送信された、前記下りデータに対する応答信号を受信する受信処理と、を制御し、前記対応付けは、一つの直交符号系列に組み合わされる隣接する巡回シフト量の差に基づき、前記応答信号を複数のサブフレームに渡ってレピティション送信することが可能なカバレッジエンハンスメントモードが前記端末に設定されている場合の前記巡回シフト量の差は、前記カバレッジエンハンスメントモードが前記端末に設定されていない場合の前記巡回シフト量の差とは独立に設定される、集積回路

請求項12

下り制御情報、及び、下りデータを、端末に送信する送信処理と、前記制御情報に基づいて決定された上り制御チャネルリソースとの対応付けから特定される、複数の直交符号系列のうちの一つ及び複数の巡回シフト量のうちの一つの組合せを用いて前記端末から送信された、前記下りデータに対する応答信号を受信する受信処理と、を制御し、前記対応付けは、一つの直交符号系列に組み合わされる隣接する巡回シフト量の差に基づき、カバレッジエンハンスメントモードが設定された複数のサブフレームに渡ってレピティション送信が可能な前記下り制御情報を前記端末に送信した場合の前記巡回シフト量の差は、前記カバレッジエンハンスメントモードが設定されていない場合の前記巡回シフト量の差とは独立に設定される、集積回路。

技術分野

0001

本開示は、基地局、通信方法及び集積回路に関する。

背景技術

0002

3GPPLTE(3rd Generation Partnership Project Long Term Evolution)では、下りリンク通信方式として直交周波数分割マルチアクセス(OFDMA:Orthogonal Frequency Division Multiple Access)が採用されている。

0003

3GPPLTEが適用された無線通信システムでは、基地局(eNBと呼ぶこともある)は、予め定められた通信リソースを用いて、同期信号(SCH: Synchronization Channel)及び報知信号(PBCH: Physical Broadcast Channel)を送信する。そして、端末(UE(User Equipment)と呼ぶこともある)は、まずSCHを捕まえることによって基地局との同期を確保する。その後、端末は、BCH情報を読むことにより基地局独自のパラメータ(例えば、周波数帯域幅など)を取得する(例えば、非特許文献1〜3を参照)。

0004

また、端末は、基地局独自のパラメータの取得が完了した後、基地局に対して接続要求を行うことにより、基地局との通信確立する。基地局は、通信が確立された端末に対して、必要に応じてPDCCH(Physical Downlink Control Channel)等の制御チャネルを介して制御情報を送信する。そして、端末は、受信したPDCCH信号に含まれる複数の制御情報をそれぞれ「ブラインド判定」する。すなわち、制御情報は、CRC(Cyclic Redundancy Check)部分を含み、このCRC部分は、基地局において、送信対象端末の端末IDによってマスクされる。従って、端末は、受信した制御情報のCRC部分を自機の端末IDによってデマスクしてみるまでは、自機宛の制御情報であるか否かを判定できない。このブラインド判定では、デマスクした結果、CRC演算がOKとなれば、その制御情報が自機宛であると判定される。

0005

また、LTEでは、基地局から端末への下りリンクデータに対してHARQ(Hybrid Automatic Repeat Request)が適用される。つまり、端末は、下りリンクデータの誤り検出結果を示す応答信号を基地局へフィードバックする。端末は、下りリンクデータに対してCRCを行って、CRC=OK(誤りなし)であれば肯定応答ACK: Acknowledgement)を、CRC=NG(誤りあり)であれば否定応答(NACK: Negative Acknowledgement)を応答信号として基地局へフィードバックする。この応答信号(つまり、ACK/NACK信号)のフィードバックには、PUCCH(Physical Uplink Control Channel)等の上りリンク制御チャネルが用いられる。

0006

ここで、基地局から送信される上記制御情報には,基地局が端末に対して割り当てたリソース情報等を含むリソース割当情報が含まれる。この制御情報の送信には、前述のとおりPDCCHが用いられる。PDCCHは、1つ又は複数のL1/L2 CCH(L1/L2 Control Channel)から構成される。各L1/L2 CCHは、1つ又は複数のCCE(Control Channel Element)から構成される。すなわち、CCEは、制御情報をPDCCHにマッピングするときの基本単位である。また、1つのL1/L2 CCHが複数のCCEから構成される場合には、そのL1/L2 CCHには連続する複数のCCEが割り当てられる。基地局は、リソース割当対象端末に対する制御情報の通知に必要なCCE数に従って、そのリソース割当対象端末に対してL1/L2 CCHを割り当てる。そして、基地局は、このL1/L2 CCHのCCEに対応する物理リソースに制御情報をマッピングして送信する。

0007

また、各CCEは、PUCCHの構成リソース(以下、PUCCHリソースと呼ぶ)と1対1に対応付けられている。したがって、L1/L2 CCHを受信した端末は、このL1/L2 CCHを構成するCCEに対応するPUCCHリソースを特定し、このPUCCHリソースを用いてACK/NACK信号を基地局へ送信する。ただし、L1/L2 CCHが連続する複数のCCEを占有する場合には、端末は、複数のCCEにそれぞれ対応する複数のPUCCHリソースのうち1つのリソース(例えば、インデックスが最も小さいCCEに対応するPUCCHリソース)を利用して、ACK/NACK信号を基地局へ送信する。

0008

また、図1に示すように、端末におけるPUCCHでのACK/NACK信号の送信タイミングは、受信したPDCCH信号及びそのPDDCH信号によりデータが割り当てられたPDSCH(Physical Downlink Shared Channel)信号を受信したサブフレーム図1ではサブフレームn)から、Kサブフレーム後(例えばFDD(Frequency Division Duplex)ではK=4)のサブフレーム(図1ではサブフレームn+K)となる。

0009

複数の端末から送信される複数のACK/NACK信号は、図2に示すように、時間軸上においてZero Auto-correlation特性を持つZAC(Zero Auto-correlation)系列ウォルシュ(Walsh)系列及びDFT(Discrete Fourier Transform)系列によって拡散され、PUCCH内においてコード多重されている。図2において、(W(0), W(1), W(2), W(3))は系列長4のウォルシュ系列を表し、(F(0),F(1),F(2))は系列長3のDFT系列を表す。

0010

図2に示すように、端末ではACK/NACK信号は、まず周波数軸上においてZAC系列(系列長12)によって1SC-FDMA(Single-Carrier Frequency Division Multiple Access)シンボルに対応する周波数成分へ1次拡散される。つまり、系列長12のZAC系列に対して、複素数で表されるACK/NACK信号成分が乗算される。次に、1次拡散後のACK/NACK信号、及び、参照信号としてのZAC系列は、それぞれウォルシュ系列(系列長4: W(0)〜W(3))及びDFT系列(系列長3: F(0)〜F(2))によって2次拡散される。つまり、系列長12の信号(1次拡散後のACK/NACK信号、又は、参照信号としてのZAC系列)のそれぞれの成分に対して、直交符号系列(Orthogonal sequence: ウォルシュ系列又はDFT系列)の各成分が乗算される。さらに、2次拡散された信号は、逆離散フーリエ変換(IDFT: Inverse Discrete Fourier Transform。又はIFFT: Inverse Fast Fourier Transform)によって時間軸上の系列長12の信号に変換される。そして、IFFT後の信号のそれぞれに対して、サイクリックプリフィックス(CP:Cyclic Prefix)が付加され、7つのSC-FDMAシンボルからなる1スロットの信号が形成される。

0011

PUCCHは、周波数軸においてシステム帯域両端に配置される。また、PUCCHでは、サブフレーム単位で各端末に無線リソースが割り当てられる。また、1サブフレームは2スロットで構成され、PUCCHは前半スロットと後半スロットとで周波数ホッピングスロット間周波数ホッピング)される。

0012

異なる端末からのACK/NACK信号同士は、異なる巡回シフト量(Cyclic Shift Index)に対応するZAC系列、又は、異なる系列番号(OC Index: Orthogonal Cover Index)に対応する直交符号系列を用いて拡散されている。直交符号系列は、ウォルシュ系列とDFT系列との組である。また、直交符号系列は、ブロックワイズ拡散コード系列(Block-wise spreading code)と称されることもある。したがって、基地局は、従来の逆拡散及び相関処理を用いることにより、これらのコード多重された複数のACK/NACK信号を分離することができる(例えば、非特許文献4を参照)。図3は、直交符号系列の系列番号(OC index:0〜2)及びZAC系列の巡回シフト量(Cyclic shift Index:0〜11)によって定義されるPUCCHリソースを示す。系列長4のウォルシュ系列及び系列長3のDFT系列を用いた場合、同一サブキャリアには最大で3*12=36個のPUCCHリソースがある。ただし、36個のPUCCHリソースをすべて利用可能とするとは限らない。例えば、図3では18個のPUCCHリソース(#0〜#17)を利用可能とした場合を示す。

0013

ところで、今後の情報社会支え仕組みとして、近年、ユーザの判断を介することなく機器間自律的な通信によりサービスを実現するM2M(Machine-to-Machine)通信が期待されている。M2Mシステムの具体的な応用事例としてスマートグリッドがある。スマートグリッドは、電気又はガスなどのライフラインを効率的に供給するインフラシステムであり、各家庭又はビル配備されるスマートメータ中央サーバとの間でM2M通信を実施して、自律的かつ効果的に資源需要バランスを調整する。M2M通信システムの他の応用事例として、物品管理又は遠隔医療などのためのモニタリングシステム自動販売機在庫又は課金遠隔管理などが挙げられる。

0014

M2M通信システムにおいては、特に広範な通信エリアを有するセルラシステムの利用が着目されている。3GPPでは、LTE及びLTE-Advancedの規格化においてセルラネットワーク前提としたM2Mの検討が、マシンタイプ通信MTC: Machine Type Communication)という名称で進められている。特に、ビルの地下などにあるスマートメータなどMTC通信機器が既存の通信エリアにおいて利用できない場所に配置されている場合に対応するため、通信エリアをさらに拡大する「カバレッジエンハンスメント(Coverage Enhancement)」が検討されている(例えば、非特許文献5を参照)。

0015

特に、MTCカバレッジエンハンスメントでは、同一信号を複数回繰り返して送信するレピティションが通信エリア拡大の重要な技術であると考えられている。具体的には、PDCCH、PDSCH及びPUCCH等の各チャネルにおいてレピティション送信を行うことが想定されている。

先行技術

0016

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 2009IEEE 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 onLTE、” June 2013.

発明が解決しようとする課題

0017

しかしながら、MTCカバレッジエンハンスメントモードの端末(レピティション送信を行う端末)がACK/NACK信号を送信するPUCCHリソースについては、未だ十分な検討がなされていない。特に、MTCカバレッジエンハンスメントモードの端末と通常モードの端末(レピティション送信を行わない端末)とが共存している場合には、MTCカバレッジエンハンスメントモードの端末が使用するPUCCHリソースを、通常モードの端末が使用するPUCCHリソースと衝突しないように設計することが必要である。

0018

本開示の一態様は、PDCCHリソースの周波数利用効率の低下及びスケジューリング複雑度の増加をさせることなく、通常モードの端末とMTCカバレッジエンハンスメントモードの端末との間のPUCCHリソースの衝突を回避することができる端末、通信方法及び集積回路を提供することである。

課題を解決するための手段

0019

本開示の一態様に係る基地局は、下り制御情報、及び、下りデータを、端末に送信する送信部と、前記制御情報に基づいて決定された上り制御チャネルリソースとの対応付けから特定される、複数の直交符号系列のうちの一つ及び複数の巡回シフト量のうちの一つの組合せを用いて前記端末から送信された、前記下りデータに対する応答信号を受信する受信部と、を具備し、前記対応付けは、一つの直交符号系列に組み合わされる隣接する巡回シフト量の差に基づき、前記応答信号を複数のサブフレームに渡ってレピティション送信することが可能なカバレッジエンハンスメントモードが前記端末に設定されている場合の前記巡回シフト量の差は、前記カバレッジエンハンスメントモードが前記端末に設定されていない場合の前記巡回シフト量の差とは独立に設定される。

0020

本開示の一態様に係る基地局は、下り制御情報、及び、下りデータを、端末に送信する送信部と、前記制御情報に基づいて決定された上り制御チャネルリソースとの対応付けから特定される、複数の直交符号系列のうちの一つ及び複数の巡回シフト量のうちの一つの組合せを用いて前記端末から送信された、前記下りデータに対する応答信号を受信する受信部と、を具備し、前記対応付けは、一つの直交符号系列に組み合わされる隣接する巡回シフト量の差に基づき、カバレッジエンハンスメントモードが設定された複数のサブフレームに渡ってレピティション送信が可能な前記下り制御情報を前記端末に送信した場合の前記巡回シフト量の差は、前記カバレッジエンハンスメントモードが設定されていない場合の前記巡回シフト量の差とは独立に設定される。

0021

本開示の一態様に係る通信方法は、基地局が、下り制御情報、及び、下りデータを、端末に送信する送信工程と、前記制御情報に基づいて決定された上り制御チャネルリソースとの対応付けから特定される、複数の直交符号系列のうちの一つ及び複数の巡回シフト量のうちの一つの組合せを用いて前記端末から送信された、前記下りデータに対する応答信号を受信する受信工程と、を具備し、前記対応付けは、一つの直交符号系列に組み合わされる隣接する巡回シフト量の差に基づき、前記応答信号を複数のサブフレームに渡ってレピティション送信することが可能なカバレッジエンハンスメントモードが前記端末に設定されている場合の前記巡回シフト量の差は、前記カバレッジエンハンスメントモードが前記端末に設定されていない場合の前記巡回シフト量の差とは独立に設定される。

0022

本開示の一態様に係る通信方法は、基地局が、下り制御情報、及び、下りデータを、端末に送信する送信工程と、前記制御情報に基づいて決定された上り制御チャネルリソースとの対応付けから特定される、複数の直交符号系列のうちの一つ及び複数の巡回シフト量のうちの一つの組合せを用いて前記端末から送信された、前記下りデータに対する応答信号を受信する受信工程と、を具備し、前記対応付けは、一つの直交符号系列に組み合わされる隣接する巡回シフト量の差に基づき、カバレッジエンハンスメントモードが設定された複数のサブフレームに渡ってレピティション送信が可能な前記下り制御情報を前記端末に送信した場合の前記巡回シフト量の差は、前記カバレッジエンハンスメントモードが設定されていない場合の前記巡回シフト量の差とは独立に設定される。

0023

本開示の一態様に係る集積回路は、下り制御情報、及び、下りデータを、端末に送信する送信処理と、前記制御情報に基づいて決定された上り制御チャネルリソースとの対応付けから特定される、複数の直交符号系列のうちの一つ及び複数の巡回シフト量のうちの一つの組合せを用いて前記端末から送信された、前記下りデータに対する応答信号を受信する受信処理と、を制御し、前記対応付けは、一つの直交符号系列に組み合わされる隣接する巡回シフト量の差に基づき、前記応答信号を複数のサブフレームに渡ってレピティション送信することが可能なカバレッジエンハンスメントモードが前記端末に設定されている場合の前記巡回シフト量の差は、前記カバレッジエンハンスメントモードが前記端末に設定されていない場合の前記巡回シフト量の差とは独立に設定される。

0024

本開示の一態様に係る集積回路は、下り制御情報、及び、下りデータを、端末に送信する送信処理と、前記制御情報に基づいて決定された上り制御チャネルリソースとの対応付けから特定される、複数の直交符号系列のうちの一つ及び複数の巡回シフト量のうちの一つの組合せを用いて前記端末から送信された、前記下りデータに対する応答信号を受信する受信処理と、を制御し、前記対応付けは、一つの直交符号系列に組み合わされる隣接する巡回シフト量の差に基づき、カバレッジエンハンスメントモードが設定された複数のサブフレームに渡ってレピティション送信が可能な前記下り制御情報を前記端末に送信した場合の前記巡回シフト量の差は、前記カバレッジエンハンスメントモードが設定されていない場合の前記巡回シフト量の差とは独立に設定される。

発明の効果

0025

本開示の一態様によれば、PDCCHリソースの周波数利用効率の低下及びスケジューリングの複雑度の増加をさせることなく、通常モードの端末とMTCカバレッジエンハンスメントモードの端末との間のPUCCHリソースの衝突を回避することができる。

図面の簡単な説明

0026

各チャネルの送信タイミングを示す図
応答信号及び参照信号の拡散方法を示す図
PUCCHリソースの一例を示す図
レピティション送信時の各チャネルの送信タイミングを示す図
PUCCHリソースの衝突の一例を示す図
実施の形態1に係る基地局の要部構成を示すブロック図
実施の形態1に係る端末の要部構成を示すブロック図
実施の形態1に係る基地局の構成を示すブロック図
実施の形態1に係る端末の構成を示すブロック図
実施の形態1に係るPUCCHリソースを示す図
実施の形態2に係るPUCCHリソースを示す図
実施の形態3に係るPUCCHリソースを示す図
実施の形態4に係るCCEとPUCCHリソースとの対応付けを示す図
実施の形態4に係るCCEとPUCCHリソースとの対応付けを示す図
実施の形態5に係るPUCCHリソースの衝突の一例を示す図
実施の形態5に係る各チャネルの送信タイミングを示す図
実施の形態6に係るPUCCHリソースの衝突の一例を示す図
実施の形態6に係る各チャネルの送信タイミングを示す図

実施例

0027

図4は、本開示の一態様として想定したMTCカバレッジエンハンスメントにおける各チャネルの送信タイミングを示す。図4では、PDCCHのレピティションレベル(レピティション回数、又は、レピティションファクタ)をNPDCCHとし、PDSCHのレピティションレベルをNPDSCHとし、PUCCHのレピティションレベルをNPUCCHとする。また、図4に示すように、MTCカバレッジエンハンスメントでは、PDCCHのレピティション送信後に、当該PDCCHによってデータが割り当てられたPDSCHのレピティション送信が行われる。端末でのACK/NACK信号(PUCCH)の送信タイミングは、PDSCHの受信を終えたサブフレームから、KMTCサブフレーム後となる。

0028

同一基地局カバーするエリアに、MTCカバレッジエンハンスメントモードの端末(レピティション送信を行う端末)と通常モードの端末(レピティション送信を行わない端末)とが共存している場合、下りリンク制御信号用の制御チャネルを別々に設けると、周波数利用効率が低下してしまう。そこで、通常モードの端末及びMTCカバレッジエンハンスメントモードの端末に対して同一周波数を用いて下りリンク制御チャネル(PDCCH)を設定することが考えられる。

0029

このとき、通常モードの端末とMTCカバレッジエンハンスメントモードの端末とでは、ACK/NACK信号が送信されるサブフレーム(PUCCHのレピティション送信が行われる最初のサブフレーム)と、ACK/NACK信号の送信に用いるPUCCHリソースと関連付けられているCCEを含むPDCCHが送信されるサブフレーム(PDCCHのレピティション送信が行われる最後のサブフレーム)との時間間隔が異なる。そのため、両方の端末が同一サブフレームにおいてACK/NACK信号を送信する場合に、通常モードの端末がACK/NACK信号を送信するPUCCHリソースに関連付けられたCCE番号と、MTCカバレッジエンハンスメントモードの端末がACK/NACK信号を送信するPUCCHリソースに関連付けられたCCE番号とが重なってしまう可能性がある。この場合、双方の端末において同一PUCCHリソースを用いてACK/NACK信号が送信されてしまう。

0030

図5は、通常モードの端末のPUCCHリソースとMTCカバレッジエンハンスメントモードの端末のPUCCHリソースとが衝突する場合の一例を示す。図5において、PUCCHリソースの衝突が発生するサブフレームをnとする。

0031

この場合、通常モードの端末に対しては、サブフレーム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において送信される。

0032

通常モードの端末が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リソースを用いる。

0033

この結果、通常モードの端末とMTCカバレッジエンハンスメントモードの端末との間においてACK/NACK信号を送信するPUCCHリソースの衝突が起こってしまう。

0034

通常モードの端末がACK/NACK信号を送信するPUCCHリソースとMTCカバレッジエンハンスメントモードの端末がACK/NACK信号を送信するPUCCHリソースとが衝突しないように、基地局側において通常モードの端末のPDCCH割当を制御する(過去のサブフレームにおいてMTCカバレッジエンハンスメントモードの端末に対して用いられたCCEを通常モードの端末に割り当てない)ことも可能である。しかし、この場合、PDCCHリソースの利用効率の低下又はスケジューリングの複雑度が増加するなどの問題がある。

0035

以下、本開示の実施の形態について図面を参照して詳細に説明する。

0036

[通信システムの概要
以下の説明では、FDD(Frequency Division Duplex)システムを例に説明する。

0037

また、本開示の各実施の形態に係る通信システムは、例えば、LTE-Advancedに対応するシステムであって、基地局100及び端末200を備える。

0038

端末200には、通常モード又はMTCカバレッジエンハンスメントモードが設定される。端末200は、例えば、MTCカバレッジエンハンスメントモードが適用される場合、PDCCH、PDSCH又はPUCCHの送信の際、複数のサブフレームに渡ってレピティション送信を適用する。すなわち、端末200は、所定のレピティションレベル分の連続するサブフレームにおいて同一の信号を繰り返し送信する。

0039

図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リソース領域)の中のリソースを用いて受信する。

0040

また、図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信号を送信する。

0041

(実施の形態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とを有する。

0042

制御部101は、リソース割当対象端末200に対して、制御情報を送信するための下りリソース(下り制御情報割当リソース)、及び、当該制御情報に含まれる、下りリンクデータ(送信データ)を送信するための下りリソース(下りデータ割当リソース)を割り当てる。下り制御情報割当リソースは、PDCCH又はEPDCCH(Enhanced PDCCH)に対応するリソース内で選択される。また、下りデータ割当リソースは、PDSCHに対応するリソース内で選択される。また、同一サブフレーム内にリソース割当対象端末200が複数有る場合には、制御部101は、リソース割当対象端末200のそれぞれに異なるリソースを割り当てる。下り制御情報割当リソースは、上述したL1/L2 CCHと同等である。すなわち、下り制御情報割当リソースは、1つ又は複数のCCEから構成される。また、上述したようにPUCCHがCCEを用いてImplicitに通知される場合、各CCEは、上りリンク制御チャネル領域(PUCCH領域)のPUCCHリソースと対応付けられている。

0043

制御部101は、制御情報を含むPDCCHが占有するCCEに対応するPUCCHリソース(周波数、及び、1次拡散/2次拡散に用いる符号)を特定する。制御部101は、端末200から送信されるPUCCH信号(ACK/NACK信号及び参照信号)の拡散に用いられる可能性があるZAC系列及び直交符号系列(つまり、PUCCHリソース)に関する情報を、系列制御部117へ出力し、周波数に関する情報をPUCCH抽出部116へ出力する。

0044

また、制御部101は、リソース割当対象端末200に対して、制御情報を送信する際に用いる符号化率を決定し、決定した符号化率を制御信号符号化部103へ出力する。また、制御部101は、リソース割当対象端末200に対して、下りリンクデータを送信する際に用いる符号化率を決定し、決定した符号化率をデータ符号化部106へ出力する。

0045

なお、決定される符号化率に応じて制御情報のデータ量が異なるので、制御部101は、このデータ量の制御情報をマッピング可能なCCEを含む下り制御情報割当リソースを割り当てる。制御部101は、制御信号生成部102に対して、下りデータ割当リソースに関する情報を出力する。また、制御部101は、下りデータ割当リソース及び下り制御情報割当リソースに関する情報を信号割当部109に出力する。

0046

また、制御部101は、リソース割当対象端末200に対してMTCカバレッジエンハンスメントモードが設定される場合、当該端末200の各チャネル(PDCCH、PDSCH又はPUCCH)に対するレピティションレベル(レピティション回数)に関する情報を、制御信号生成部102及びデータ符号化部106に出力する。

0047

また、制御部101は、報知信号生成部105に対して、予め基地局毎に決められたパラメータに基づいて報知信号を生成するように指示する。

0048

また、制御部101は、PUCCHリソースに関する情報を生成し、制御信号生成部102へ出力する。PUCCHリソースに関する情報とは、例えば、通常モードの端末及びMTCカバレッジエンハンスメントモードの端末において使用されるPUCCHリソースを特定するためのパラメータである。なお、PUCCHリソースに関する情報は、セル固有の値として報知情報として端末200へ通知されてもよく、上位レイヤシグナリングとして端末200へ通知されてもよい。

0049

制御信号生成部102は、制御部101から受け取る情報(下りデータ割当リソースに関する情報、PUCCHのレピティションレベルに関する情報又はPUCCHリソースに関する情報)を用いて制御信号を生成し、制御信号を制御信号符号化部103に出力する。リソース割当対象端末200が複数ある場合、リソース割当対象端末200同士を区別するために、制御信号には、宛先端末の端末IDが含まれる。例えば、制御信号には、宛先端末の端末IDによってマスキングされたCRCビットが含まれる。また、制御信号生成部102は、リソース割当対象端末200に対してMTCカバレッジエンハンスメントモードが設定される場合、制御部101から受け取るレピティションレベルに関する情報に従って、レピティション信号を生成する。すなわち、PDCCHのレピティションレベルが1より大きい場合には、制御信号生成部102は、レピティションレベルに対応した連続する複数のサブフレームに渡って、同一の制御信号を制御信号符号化部103へ出力する。

0050

制御信号符号化部103は、制御部101から受け取る符号化率に従って、制御信号生成部102から受け取る制御信号を符号化し、符号化後の制御信号を制御信号変調部104へ出力する。

0051

制御信号変調部104は、制御信号符号化部103から受け取る制御信号を変調し、変調後の制御信号を信号割当部109へ出力する。

0052

報知信号生成部105は、制御部101からの指示に従って、報知信号を生成し、報知信号を信号割当部109へ出力する。なお、報知信号には、例えば、システム帯域幅、又は、PUCCHリソースに関する信号等が含まれている。また、報知信号には、符号化処理及び変調処理が施されてもよい。

0053

データ符号化部106は、制御部101から受け取る符号化率に従って、宛先端末毎の送信データ(ビット系列。つまり、下りリンクデータ)を符号化し、符号化後のデータ信号を再送制御部107へ出力する。また、データ符号化部106は、リソース割当対象端末200に対してMTCカバレッジエンハンスメントモードが設定される場合、制御部101から受け取るレピティションレベルに関する情報に従って、レピティション信号を生成する。すなわち、PDSCHのレピティションレベルが1より大きい場合には、データ符号化部106は、レピティションレベルに対応した連続する複数のサブフレームに渡って、同一のデータ信号を再送制御部107へ出力する。

0054

再送制御部107は、初回送信時には、データ符号化部106から受け取る符号化後のデータ信号を保持するとともにデータ変調部108へ出力する。再送制御部107は、符号化後のデータ信号を、宛先端末毎に保持する。また、再送制御部107は、後述する判定部120から、送信したデータ信号に対するNACKを受け取ると、対応する保持データをデータ変調部108へ出力する。再送制御部107は、送信したデータ信号に対するACKを受け取ると、対応する保持データを削除する。

0055

データ変調部108は、再送制御部107から受け取るデータ信号を変調して、データ変調信号を信号割当部109へ出力する。

0056

信号割当部109は、制御信号変調部104から受け取る制御信号、報知信号生成部105から受け取る報知信号、及び、データ変調部106から受け取るデータ変調信号を、下りリソース(下りリンクデータ信号割当リソース、下りリンク制御情報割当リソース等)にマッピングし、マッピングした信号をIFFT部110へ出力する。具体的には、信号割当部109は、制御部101から受け取る下り制御情報割当リソースに示されるリソースに制御信号をマッピングし、制御部101から受け取る下りデータ割当リソースに示されるリソースにデータ変調信号をマッピングする。また、信号割当部109は、予め設定された時間・周波数リソースに報知信号をマッピングする。

0057

IFFT部110は、信号割当部109から受け取る信号に対してIFFT処理を行うことにより、周波数領域信号を時間領域信号に変換する。IFFT部110は、時間領域信号をCP付加部111へ出力する。

0058

CP付加部111は、IFFT部110から受け取る信号に対してCPを付加し、CP付加後の信号(OFDM信号)を送信部112へ出力する。

0059

送信部112は、CP付加部111から受け取るOFDM信号に対してD/A(Digital-to-Analog)変換、アップコンバート等のRF(Radio Frequency)処理を行い、アンテナ113を介して端末200に無線信号を送信する。

0060

受信部114は、アンテナ113を介して受信された端末200からの無線信号に対して、ダウンコンバート又はA/D(Analog-to-Digital)変換などのRF処理を行い、得られる受信信号をCP除去部115に出力する。

0061

CP除去部115は、受信部114から受け取る受信信号に付加されているCPを除去し、CP除去後の信号をPUCCH抽出部116へ出力する。

0062

PUCCH抽出部116は、制御部101から受け取る情報に基づいて、CP除去部115から受け取る信号から上り制御チャネル信号(PUCCH)を抽出し、抽出したPUCCHを逆拡散部118へ出力する。また、PUCCH抽出部116は、MTCカバレッジエンハンスメントモードの端末200が存在する場合、複数サブフレームに渡ってレピティション送信されたPUCCHに対して、同相合成を施してPUCCH(合成信号)を抽出する。

0063

系列制御部117は、制御部101から受け取るZAC系列及び直交符号系列に関する情報に基づいて、端末200から送信されるACK/NACK信号及び参照信号の拡散に用いられる可能性があるZAC系列、及び、直交符号系列を生成する。系列制御部117は、直交符号系列を逆拡散部118へ出力し、ZAC系列を相関処理部119へ出力する。

0064

逆拡散部118は、系列制御部117から受け取る直交符号系列(端末200が2次拡散で用いるべき直交符号系列)を用いて、PUCCH抽出部116から受け取る信号のうちACK/NACK信号に相当する部分の信号を逆拡散し、逆拡散後の信号を相関処理部119に出力する。

0065

相関処理部119は、系列制御部117から入力されるZAC系列(端末200が1次拡散で用いる可能性のあるZAC系列)と、逆拡散部118から入力される信号との相関値を求めて、相関値を判定部120に出力する。

0066

判定部120は、相関処理部119から受け取る相関値に基づいて、端末200から送信されたACK/NACK信号が、送信されたデータに対してACK又はNACKのいずれかを示しているかを判定する。判定部120は、判定結果を再送制御部107に出力する。

0067

[端末の構成]
図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とを有する。

0068

受信部202は、アンテナ201を介して受信された、基地局100からの無線信号に対してダウンコンバート又はAD変換などのRF処理を行い、ベースバンドのOFDM信号を得る。受信部202は、OFDM信号をCP除去部203へ出力する。

0069

CP除去部203は、受信部202から受け取るOFDM信号に付加されているCPを除去し、CP除去後の信号をFFT部204へ出力する。

0070

FFT部204は、CP除去部203から受け取る信号に対してFFT処理を行うことにより、時間領域信号を周波数領域信号に変換する。FFT部204は、周波数領域信号を抽出部205へ出力する。

0071

抽出部205は、FFT部204から受け取る信号から報知信号を抽出して、報知信号受信部206へ出力する。ここで、報知信号がマッピングされるリソースは予め決まっているので、抽出部205は、そのリソースにマッピングされている情報を抽出することにより、報知信号を得る。抽出された報知信号には、例えば、システム帯域幅、又は、PUCCHリソースに関する信号等が含まれている。

0072

また、抽出部205は、FFT部204から受け取る信号から、下り制御チャネル信号(PDCCH信号)を抽出し、制御信号復調部207へ出力する。また、抽出部205は、判定部209から受け取る、自端末宛の下りデータ割当リソースに関する情報に基づいて、FFT部204から受け取る信号から下りリンクデータ(PDSCH信号)を抽出し、データ復調部210へ出力する。PDCCH信号には、例えば、下りデータ割当リソースに関する情報、PUCCHのレピティションレベルに関する情報、又は、PUCCHリソースに関する情報などが含まれている。

0073

また、抽出部205は、自装置に対してMTCカバレッジエンハンスメントモードが設定され、PDCCH信号がレピティション送信されている場合、複数のサブフレームに渡ってレピティション送信されたPDCCH信号に対して同相合成して、PDCCH信号を抽出する。同様に、抽出部205は、下りリンクデータ(PDSCH信号)がレピティション送信されている場合には、複数のサブフレームに渡ってレピティション送信されたPDSCH信号に対して同相合成して、下りリンクデータを抽出する。

0074

報知信号受信部206は、抽出部205から受け取る報知信号から、システム帯域幅、又は、PUCCHリソースに関する情報などを得る。報知信号受信部206は、報知信号に符号化処理及び変調処理が施されている場合、復調処理及び復号処理を施す。報知信号受信部206は、得られた報知信号を判定部209又は制御部213へ出力する。

0075

制御信号復調部207は、抽出部205から受け取るPDCCH信号を復調し、復調後のPDCCH信号を制御信号復号部208へ出力する。

0076

制御信号復号部208は、制御信号復調部207から受け取るPDCCH信号を復号して、復号結果を判定部209に出力する。

0077

判定部209は、制御信号復号部208から受け取る復号結果に含まれる制御情報が自端末宛ての制御情報であるか否かをブラインド判定する。例えば、判定部209は、自端末の端末IDによってCRCビットをデマスキングし、CRC=OK(誤りなし)となる制御情報を、自端末宛ての制御情報であると判定する。そして、判定部209は、自装置宛の制御情報に含まれる下りデータ割当リソースに関する情報を抽出部205へ出力する。また、判定部209は、自装置宛の制御情報がマッピングされていたCCEを特定し、特定したCCEの識別情報を制御部213へ出力する。

0078

データ復調部210は、抽出部205から受け取る下りリンクデータを復調し、復調後の下りリンクデータをデータ復号部211へ出力する。

0079

データ復号部211は、データ復調部210から受け取る下りリンクデータを復号し、復号後の下りリンクデータをCRC部212へ出力する。

0080

CRC部212は、データ復号部211から受け取る下りリンクデータに対して、CRCを用いて誤り検出を行い、誤り検出結果をACK/NACK生成部214へ出力する。また、CRC部212は、誤り検出の結果、誤りなしと判定した下りリンクデータを受信データとして出力する。

0081

制御部213は、報知信号、PDCCH信号又は上位レイヤシグナリングによって基地局100から端末200に対して通知されたPUCCHリソースに関する情報、及び、レピティションレベルに関する情報を予め保持する。

0082

制御部213は、PUCCHリソースに関する情報、及び、判定部209から受け取るCCEの識別情報を用いて、CCEの識別情報に示されるCCEに対応するPUCCHリソース(周波数、及び、1次拡散/2次拡散に用いる符号)を特定する。すなわち、制御部213は、CCEの識別情報に基づいて上り制御チャネルのPUCCHリソースを特定する。

0083

具体的には、制御部213は、使用すべきPUCCHリソースに対応するZAC系列を生成すると共に、設定された巡回シフト量に基づいて、使用すべき巡回シフト量を決定し、1次拡散部216へ出力する。また、制御部213は、使用すべきPUCCHリソースに対応する直交符号系列を2次拡散部217へ出力する。また、制御部213は、使用すべきPUCCHリソースに対応する周波数リソース(サブキャリア)をIFFT部218へ出力する。

0084

また、制御部213は、自端末がMTCカバレッジエンハンスメントモードである場合、PUCCHのレピティションレベルに関する情報をACK/NACK生成部214へ出力する。

0085

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へ出力する。

0086

変調部215は、ACK/NACK生成部214から受け取るACK/NACK信号を変調して、変調後のACK/NACK信号を1次拡散部216へ出力する。

0087

1次拡散部216は、制御部213によって設定されたZAC系列及び巡回シフト量を用いて、参照信号、及び、変調部215から受け取るACK/NACK信号を1次拡散し、1次拡散後のACK/NACK信号及び参照信号を2次拡散部217へ出力する。

0088

2次拡散部217は、制御部213によって設定された直交符号系列を用いてACK/NACK信号及び参照信号を2次拡散し、2次拡散後の信号をIFFT部218へ出力する。

0089

IFFT部218は、制御部213によって設定された周波数リソースを用いて、2次拡散部217から受け取るACK/NACK信号及び参照信号に対してサブキャリアへのマッピング、及び、IFFT処理を行うことにより時間領域信号を生成する。IFFT部218は、生成した信号をCP付加部219へ出力する。

0090

CP付加部219は、IFFT部218から受け取る信号に対してCPを付加し、CP付加後の信号を送信部220へ出力する。

0091

送信部220は、CP付加部219から受け取る信号に対してD/A変換、アップコンバート等のRF処理を行い、アンテナ201を介して基地局100に無線信号を送信する。

0092

[基地局100及び端末200の動作]
以上の構成を有する基地局100及び端末200の動作について説明する。

0093

以下では、通常モードの端末と、MTCカバレッジエンハンスメントモードの端末とが基地局100のセル内に共存する場合について説明する。

0094

本実施の形態に係る基地局100は、各端末200に対して、PUCCHリソースに関する情報を予め通知する。PUCCHリソースに関する情報は、例えば、CCE番号からPUCCH番号を特定する際に使用されるオフセット値、及び、各PUCCH領域に配置される1リソースブロック(RB:Resource Block)あたりに符号多重されるPUCCHリソースの最大数に関する情報である。

0095

本実施の形態では、通常モードの端末及びMTCカバレッジエンハンスメントモードの端末に対して上記オフセット値が独立に設定される。

0096

具体的には、通常モードの端末は、下りリンク割当制御情報(PDCCH又はEPDCCH)を受信した場合、対応する割当制御情報に示される下りリンクデータ(PDSCH)に対するACK/NACK信号を送信するPUCCHリソースのリソース番号nPUCCHを次式に従って決定する。
nPUCCH=nCCE+NPUCCH(1) (1)

0097

式(1)において、nCCEは、PDCCHが占有するCCE番号(0以上の整数)を示す。具体的には、PDCCHが1つのCCEのみを占有していた場合には、nCCEは当該CCEの番号である。また、PUCCHが複数のCCEを占有していた場合には、nCCEは最小のCCEの番号である。

0098

また、式(1)において、NPUCCH(1)は、CCE番号からPUCCHリソース番号を特定するためのオフセット値を示す。例えば、3GPP Release 11では、NPUCCH(1)は、SPS/SR(Semi-Persistent Scheduling/Scheduling Request)用リソース向けに確保されたPUCCHリソース数を示す。NPUCCH(1)は、例えば、セル内で共通(common)の値であって、基地局100から端末200へ報知信号又は上位レイヤシグナリングによって通知される。

0099

通常モードの端末は、決定したPUCCHリソース番号nPUCCHに基づいて、実際に使用するOC index及び巡回シフト量を決定する。

0100

一方、MTCカバレッジエンハンスメントモードの端末は、下りリンク割当制御情報(PDCCH又はEPDCCH)を受信した場合、対応する割当制御情報に示される下りリンクデータ(PDSCH)に対するACK/NACK信号を送信するPUCCHリソースのリソース番号nPUCCH_MTCを次式に従って決定する。
nPUCCH_MTC=nCCE+NPUCCH_MTC(1) (2)

0101

式(2)において、NPUCCH_MTC(1)は、MTCカバレッジエンハンスメントモードの端末に対する、CCE番号からPUCCHリソース番号を特定するためのオフセット値を示す。すなわち、MTCカバレッジエンハンスメントモードの端末に対して、通常モードの端末のオフセットNPUCCH(1)とは異なる独立のオフセット値NPUCCH_MTC(1)が設定される。NPUCCH_MTC(1)は、例えば、端末200に依存する個別(UE specific)の値であってもよく、MTCカバレッジエンハンスメントモードの端末に共通の値でもよい。

0102

MTCカバレッジエンハンスメントモードの端末は、決定したPUCCHリソース番号nPUCCH_MTCに基づいて、実際に使用するOC index及び巡回シフト量を決定する。

0103

図10は、通常モードの端末及びMTCカバレッジエンハンスメントモードの端末に対するPUCCHリソースの一例を示す。

0104

図10では、図3と同様、1RB(PRB(Physical RB))毎に最大36個のPUCCHリソースのうち、18個のPUCCHリソースが利用可能である。図10では、3個のRBに渡って、利用可能な54個のPUCCHリソースに対してPUCCHリソース番号(#0〜#53)がそれぞれ付されている。

0105

図10では、通常モードの端末に対するオフセット値NPUCCH(1)=6であり、MTCカバレッジエンハンスメントモードの端末に対するオフセット値NPUCCH_MTC(1)=30である。

0106

すなわち、通常モードの端末は、PUCCHリソース番号nPUCCH=nCCE+6のPUCCHリソースを用いてACK/NACK信号を送信する。一方、MTCカバレッジエンハンスメントモードの端末は、PUCCHリソース番号nPUCCH_MTC=nCCE+30のPUCCHリソースを用いてACK/NACK信号を送信する。

0107

つまり、端末200は、自端末が通常モードの端末である場合には、通常モードの端末用のPUCCHリソース群の中のPUCCHリソースを用いてACK/NACK信号を送信し、自端末が、MTCカバレッジエンハンスメントモードの端末である場合には、通常モードの端末用のPUCCHリソース群とは異なるMTCカバレッジエンハンスメントモードの端末用のPUCCHリソース群の中のPUCCHリソースを用いてACK/NACK信号を送信する。

0108

また、同様にして、基地局100は、通常モードの端末から送信されるACK/NACK信号を、通常モードの端末用のPUCCHリソース群の中のリソースを用いて受信し、MTCカバレッジエンハンスメントモードの端末から送信されるACK/NACK信号を、通常モードの端末用のPUCCHリソース群とは異なるMTCカバレッジエンハンスメントモードの端末用のPUCCHリソース群の中のリソースを用いて受信する。

0109

これにより、図10に示すように、PDCCH信号、PDSCH信号及びACK/NACK信号に対してレピティション送信が適用されるMTCカバレッジエンハンスメントモードの端末がACK/NACK信号の送信に使用可能なPUCCHリソース群と、レピティション送信が適用されない通常モードの端末がACK/NACK信号の送信に使用可能なPUCCHリソース群とは異なる。すなわち、通常モードの端末とMTCカバレッジエンハンスメントモードの端末との間において、CCE番号からPUCCHリソース番号を特定するためのオフセット値を異ならせることにより、双方の端末に対するPUCCHリソース領域が分割される。

0110

なお、図10では、各モードの端末200に対して使用可能なCCE数を24個とする場合について示している。ただし、各モードの端末200に対して使用可能なCCE数は24個に限らず、他の値でもよく、使用可能なCCE数に応じて、各モードの端末200に対するPUCCHリソース領域が分割されるように、オフセット値NPUCCH(1)及びNPUCCH_MTC(1)が設定されればよい。

0111

ここで、一例として、図5に示すように、同一サブフレームにおいて送信されるACK/NACK信号に使用されるPUCCHリソースに対応するCCE番号がCCE#0である場合(つまり、nCCE=0)について説明する。

0112

この場合、通常モードの端末は、式(1)に従って、PUCCHリソース番号nPUCCH=6(=0+6)のPUCCHリソースを用いる。

0113

一方、MTCカバレッジエンハンスメントモードの端末は、式(2)に従って、PUCCHリソース番号nPUCCH_MTC=30(=0+30)のPUCCHリソースを用いる。

0114

すなわち、端末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)とは異なる。

0115

よって、両方の端末が同一サブフレームにおいてACK/NACK信号を送信する場合に、通常モードの端末がACK/NACK信号を送信するPUCCHリソースに関連付けられたCCE番号と、MTCカバレッジエンハンスメントモードの端末がACK/NACK信号を送信するPUCCHリソースに関連付けられたCCE番号とが同一のCCE#0であっても、双方において使用されるPUCCHリソースは異なる。

0116

つまり、双方の端末が同一サブフレームにおいてACK/NACK信号を送信する場合に、対応するPDCCHに使用されたCCE番号(最小のインデックス)が同一であっても、通常モードの端末とMTCカバレッジエンハンスメントモードの端末との間においてPUCCHリソースの衝突を回避することができる。

0117

このように、本実施の形態によれば、通常モードの端末とMTCカバレッジエンハンスメントモードの端末とに対してそれぞれ異なるオフセット値を用いてPUCCHリソースを決定する。こうすることで、通常モードの端末が使用可能なPUCCHリソースと、MTCカバレッジエンハンスメントモードの端末が使用可能なPUCCHリソースと、が分離される。これにより、同一サブフレームにおいて送信されるACK/NACK信号に対応する下りリンクデータの割当に使用されたPDCCHが占有するCCEが同一であっても、ACK/NACK信号に使用されるPUCCHリソースを異ならせることができる。よって、ACK/NACK信号を送信するPUCCHリソースの衝突を回避できる。

0118

また、上述したように、通常モードの端末とMTCカバレッジエンハンスメントモードの端末との間においてPUCCHリソース番号を特定するためのオフセット値を異ならせることにより、PUCCHリソースの衝突を回避するので、PDCCHリソースの割当に関して何ら制限を追加する必要はない。このため、本実施の形態によれば、PDCCHリソースの利用効率の低下又はスケジューリングの複雑度が増加することはない。

0119

よって、本実施の形態によれば、PDCCHリソースの周波数利用効率の低下及びスケジューリングの複雑度の増加をさせることなく、通常モードの端末とMTCカバレッジエンハンスメントモードの端末との間のPUCCHリソースの衝突を回避することができる。

0120

さらに、通常モードの端末に対するPUCCHリソースの割当(例えば、式(1)を参照)はLTEシステムにおいて既に行われている。よって、本実施の形態では、MTCカバレッジエンハンスメントモードの端末に対するPUCCHリソースの割当時に独立して使用されるオフセット値NPUCCH_MTC(1)のみが基地局100から端末200へ新たに通知されればよい。よって、既存のシステムの動作に与える影響は少ない。

0121

(実施の形態2)
本実施の形態に係る基地局及び端末の基本構成は、実施の形態1と同様であるので、図8(基地局100)と図9(端末200)を援用して説明する。

0122

以下では、実施の形態1と同様、通常モードの端末と、MTCカバレッジエンハンスメントモードの端末とが基地局100のセル内に共存する場合について説明する。

0123

本実施の形態に係る基地局100は、各端末200に対して、PUCCHリソースに関する情報を予め通知する。PUCCHリソースに関する情報は、例えば、CCE番号からPUCCH番号を特定する際に使用されるオフセット値、及び、各PUCCH領域に配置される1リソースブロック(RB:Resource Block)あたりに符号多重されるPUCCHリソースの最大数に関する情報である。

0124

本実施の形態では、通常モードの端末及びMTCカバレッジエンハンスメントモードの端末に対して上記オフセット値が共通に設定される。ただし、通常モードの端末と、MTCカバレッジエンハンスメントモードの端末とでは、CCE番号とPUCCHリソース番号との対応付けが異なる。

0125

具体的には、通常モードの端末は、実施の形態1と同様、ACK/NACK信号を送信するPUCCHリソースのリソース番号nPUCCHを式(1)に従って決定し、実際に使用するOC index及び巡回シフト量を決定する。

0126

一方、MTCカバレッジエンハンスメントモードの端末は、下りリンク割当制御情報(PDCCH又はEPDCCH)を受信した場合、対応する割当制御情報に示される下りリンクデータ(PDSCH)に対するACK/NACK信号を送信するPUCCHリソースのリソース番号nPUCCH_MTCを次式に従って決定する。
nPUCCH_MTC=NPUCCH(1)-1-nCCE (3)

0127

式(3)において、NPUCCH(1)は、CCE番号からPUCCHリソース番号を特定するためのオフセット値であって、式(1)にも含まれる値である。すなわち、MTCカバレッジエンハンスメントモードの端末に対して、通常モードの端末のオフセットNPUCCH(1)と同一のオフセット値NPUCCH(1)が設定される。NPUCCH(1)は、例えば、基地局100から端末200へ報知信号又は上位レイヤシグナリングによって通知されてもよい。

0128

MTCカバレッジエンハンスメントモードの端末は、決定したPUCCHリソース番号nPUCCH_MTCに基づいて、実際に使用するOC index及び巡回シフト量を決定する。

0129

すなわち、端末200(制御部213)は、自端末が通常モードの端末である場合には、PDCCHに使用されるCCEのインデックスnCCEにオフセット値NPUCCH(1)を加算して、実際にACK/NACK信号に使用されるPUCCHリソースを算出する。一方、端末200は、自端末がMTCカバレッジエンハンスメントモードの端末である場合には、オフセット値NPUCCH_MTC(1)から、PDCCHに使用されるCCEのインデックスnCCEを減算して、実際にACK/NACK信号に使用されるPUCCHリソースを算出する。

0130

図11は、通常モードの端末及びMTCカバレッジエンハンスメントモードの端末に対するPUCCHリソースの一例を示す。

0131

図11では、図10と同様、1RB毎に最大36個のPUCCHリソースのうち、18個のPUCCHリソースが利用可能である。図11では、3個のRBに渡って、利用可能な54個のPUCCHリソースに対してPUCCHリソース番号(#0〜#53)がそれぞれ付されている。

0132

また、図11では、各端末200に対するオフセット値NPUCCH(1)=30である。

0133

すなわち、通常モードの端末は、PUCCHリソース番号nPUCCH=nCCE+30のPUCCHリソースを用いてACK/NACK信号を送信する。一方、MTCカバレッジエンハンスメントモードの端末は、PUCCHリソース番号nPUCCH_MTC=30−1−nCCE(=29−nCCE)のPUCCHリソースを用いてACK/NACK信号を送信する。

0134

つまり、図11に示すように、PUCCHリソース番号#29と#30との間を境界として、#30以上の番号のPUCCHリソースは通常モードの端末用PUCCHリソース領域に設定され、#29以下の番号のPUCCHリソースはMTCカバレッジエンハンスメントモードの端末用PUCCHリソース領域に設定される。

0135

これにより、図11に示すように、通常モードの端末及びMTCカバレッジエンハンスメントモードの端末の各々に対して異なるPUCCHリソース領域が設定される。すなわち、通常モードの端末とMTCカバレッジエンハンスメントモードの端末との間において、CCE番号からPUCCHリソース番号を特定するための対応付け(式(1)及び式(3))を異ならせることにより、双方の端末に対するPUCCHリソース領域が分割される。

0136

ここで、一例として、図5に示すように、同一サブフレームにおいて送信されるACK/NACK信号に使用されるPUCCHリソースに対応するCCE番号がCCE#0である場合(つまり、nCCE=0)について説明する。

0137

この場合、通常モードの端末は、式(1)に従って、PUCCHリソース番号nPUCCH=30(=0+30)のPUCCHリソースを用いる。

0138

一方、MTCカバレッジエンハンスメントモードの端末は、式(3)に従って、PUCCHリソース番号nPUCCH_MTC=29(=29−0)のPUCCHリソースを用いる。

0139

つまり、両方の端末が同一サブフレームにおいてACK/NACK信号を送信する場合に、通常モードの端末がACK/NACK信号を送信するPUCCHリソースに関連付けられたCCE番号と、MTCカバレッジエンハンスメントモードの端末がACK/NACK信号を送信するPUCCHリソースに関連付けられたCCE番号とが同一のCCE#0であっても、双方において使用されるPUCCHリソースは異なる。

0140

つまり、双方の端末が同一サブフレームにおいてACK/NACK信号を送信する場合に、対応するPDCCHに使用されたCCE番号(最小のインデックス)が同一であっても、通常モードの端末とMTCカバレッジエンハンスメントモードの端末との間においてPUCCHリソースの衝突を回避することができる。

0141

このように、本実施の形態によれば、通常モードの端末とMTCカバレッジエンハンスメントモードの端末とに対して、それぞれ異なるCCEとの対応付けを用いてPUCCHリソースを決定する。こうすることで、通常モードの端末が使用可能なPUCCHリソースと、MTCカバレッジエンハンスメントモードの端末が使用可能なPUCCHリソースと、が分離される。これにより、同一サブフレームにおいて送信されるACK/NACK信号に対応する下りリンクデータの割当に使用されたPDCCHが占有するCCEが同一であっても、ACK/NACK信号に使用されるPUCCHリソースを異ならせることができる。よって、ACK/NACK信号を送信するPUCCHリソースの衝突を回避できる。

0142

また、上述したように、通常モードの端末とMTCカバレッジエンハンスメントモードの端末との間においてPUCCHリソース番号を特定するための対応付けを異ならせることにより、PUCCHリソースの衝突を回避するので、PDCCHリソースの割当に関して何ら制限を追加する必要はない。このため、本実施の形態によれば、PDCCHリソースの利用効率の低下又はスケジューリングの複雑度が増加することはない。

0143

よって、本実施の形態によれば、PDCCHリソースの周波数利用効率の低下及びスケジューリングの複雑度の増加をさせることなく、通常モードの端末とMTCカバレッジエンハンスメントモードの端末との間のPUCCHリソースの衝突を回避することができる。

0144

さらに、通常モードの端末に対するPUCCHリソースの割当(例えば、式(1)を参照)はLTEシステムにおいて既に行われている。また、MTCカバレッジエンハンスメントモードの端末に対するPUCCHリソースの割当時にも、通常モードの端末と同一のパラメータ(オフセット値NPUCCH(1))が用いられる。よって、MTCカバレッジエンハンスメントモードの端末に対して新たに追加すべきパラメータはない。よって、既存のシステムの動作に影響を与えない。

0145

なお、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)の増加を抑えることができる。

0146

(実施の形態3)
本実施の形態に係る基地局及び端末の基本構成は、実施の形態1と同様であるので、図8(基地局100)と図9(端末200)を援用して説明する。

0147

以下では、通常モードの端末と、MTCカバレッジエンハンスメントモードの端末とが基地局100のセル内に共存する場合について説明する。

0148

本実施の形態に係る基地局100は、各端末200に対して、PUCCHリソースに関する情報を予め通知する。PUCCHリソースに関する情報は、例えば、PUCCHリソース(例えば、図3を参照)の1直交系列において隣接する利用可能なPUCCHリソース間の巡回シフト量の差、及び、各PUCCH領域に配置される1RBあたりに符号多重されるPUCCHリソースの最大数に関する情報を含む。

0149

また、通常モードの端末及びMTCカバレッジエンハンスメントモードの端末の各々に対して異なるPUCCHリソース領域が設定される。以下の説明では、MTCカバレッジエンハンスメントモードの端末に対するPUCCHリソースの割当として、CCE番号に対応付けてImplicitに通知する場合について説明する。例えば、通常モードの端末及びMTCカバレッジエンハンスメントモードの端末に対するPUCCHリソースは、実施の形態1又は実施の形態2と同様の方法により設定されてもよい。ただし、本実施の形態では、MTCカバレッジエンハンスメントモードの端末に対するPUCCHリソースの割当として、上位レイヤシグナリングなどを用いて、基地局100から端末200へExplicitに通知されてもよい。

0150

本実施の形態では、通常モードの端末及びMTCカバレッジエンハンスメントモードの端末に対して上記巡回シフト量の差が独立に設定される。

0151

図12は、本実施の形態に係る、通常モードの端末及びMTCカバレッジエンハンスメントモードの端末に対するPUCCHリソースの一例を示す。図12では、2個のRBの合計72個のPUCCHリソースのうち、12個のPUCCHリソースはSPS/SR用に確保され、48個のPUCCHリソースは通常モードの端末に対して確保され、残りの12個のPUCCHリソースはMTCカバレッジエンハンスメントモードの端末に対して確保されている。

0152

上述したように、図12に示すPUCCHリソースは、直交符号系列(OC index)とZAC系列の巡回シフト量(Cyclic shift Index)との組合せによって定義される。

0153

通常モードの端末には、PUCCHリソースを定義する1直交符号系列において隣接する利用可能なリソース間の巡回シフト量の差ΔshiftPUCCHが設定される。例えば、図12では、ΔshiftPUCCH=2が設定されている。すなわち、1つの直交符号系列に対して採りうる12個の巡回シフト量(Cyclic Shift Index=0〜11)について1個おきの巡回シフト量に対応するPUCCHリソースが利用可能となる。よって、通常モードの端末に対しては、1RB(PRB(Physical RB))毎に最大36個のPUCCHリソースのうち、18個のPUCCHリソースが利用可能となる。

0154

図12では、通常モードの端末は、下りリンク割当制御情報を受信した場合、対応する割当制御情報に示される下りリンクデータに対するACK/NACK信号を送信するPUCCHリソースのリソース番号nPUCCHを式(1)に従って決定してもよい(ただし、NPUCCH(1)=6)。

0155

図12では、PUCCHリソース#0を始点として、各直交符号系列において1個おきの巡回シフト量に対応するリソースに対して番号が付与されたPUCCHリソースのうち、PUCCHリソース番号#6〜#29の24個のPUCCHリソースが通常モードの端末が利用可能なPUCCHリソースとなる。

0156

一方、MTCカバレッジエンハンスメントモードの端末には、PUCCHリソースを定義する1直交符号系列において隣接する利用可能なリソース間の巡回シフト量の差ΔshiftPUCCH_MTCが設定される。例えば、図12では、ΔshiftPUCCH_MTC=1が設定されている。すなわち、利用可能なPUCCHリソース間の巡回シフト量の差として、通常モードの端末とMTCカバレッジエンハンスメントモードの端末とでは互いに異なるパラメータが設定されている。具体的には、ΔshiftPUCCH_MTCは、ΔshiftPUCCHよりも小さい。

0157

すなわち、MTCカバレッジエンハンスメントモードの端末では、1つの直交符号系列に対して採りうる12個の巡回シフト量(Cyclic Shift Index=0〜11)について連続する全ての巡回シフト量に対応するPUCCHリソースが利用可能となる。

0158

図12では、MTCカバレッジエンハンスメントモードの端末は、下りリンク割当制御情報を受信した場合、対応する割当制御情報に示される下りリンクデータに対するACK/NACK信号を送信するPUCCHリソースのリソース番号nPUCCH_MTCを式(2)に従って決定してもよい(ただし、NPUCCH_MTC(1)=60)。

0159

図12では、PUCCHリソース#0を始点として、各直交符号系列において連続する巡回シフト量に対応するリソースに対して番号が付与されたPUCCHリソースのうち、PUCCHリソース番号#60〜#71の12個のPUCCHリソースがMTCカバレッジエンハンスメントモードの端末が利用可能なPUCCHリソースとなる。

0160

なお、端末200は、PUCCHリソース番号に基づいて、実際に使用するOC index及び巡回シフト量を決定する。PUCCHリソース番号と、OC index及び巡回シフト量と、の対応付けは、隣接する巡回シフト量の差に依存する。したがって、本実施の形態では、PUCCHリソース番号から実際に使用するOC index及び巡回シフト量を特定する対応付けが、通常モードの端末とMTCカバレッジエンハンスメントモードの端末とで異なる。具体的には、MTCカバレッジエンハンスメントモードの端末は、既存のシステムにおけるPUCCHリソース番号から実際に使用するOC index及び巡回シフト量を特定する対応付けを示す数式(示さず)におけるΔshiftPUCCHをΔshiftPUCCH_MTCに置き換えて動作すればよい。

0161

既存のシステム(例えば、3GPP Release 11)では、上述した通常モードの端末に対するPUCCHリソースは確保されていた。これに対して、図12に示すように、MTCカバレッジエンハンスメントモードの端末が存在する場合、通常モードの端末用のPUCCHリソースに加えて、MTCカバレッジエンハンスメントモードの端末用のPUCCHリソースが追加的に設定される。

0162

ここで、図12に示すように、各RB内での最大符号多重可能数は、採りうる巡回シフト量のうちの利用可能な巡回シフト量の数により特定される。具体的には、最大符号多重可能数は、PUCCHリソースとして巡回シフト量をいくつおきに利用可能か(つまり、ΔshiftPUCCH及びΔshiftPUCCH_MTC)によって特定される。

0163

本実施の形態では、通常モードの端末及びMTCカバレッジエンハンスメントモードの端末の各々に対して最大符号多重可能数(巡回シフト量の差)が独立に設定される。具体的には、MTCカバレッジエンハンスメントモードの端末用のPUCCHリソース群の各リソースとして定義された、直交符号系列と巡回シフト量との組合せのうち、同一直交符号系列において隣接する巡回シフト量の差ΔshiftPUCCH_MTCは、通常モードの端末用のPUCCHリソース群の各リソースとして定義された、直交符号系列と巡回シフト量との組合せのうち、同一直交符号系列において隣接する巡回シフト量の差ΔshiftPUCCHよりも小さい。

0164

このため、MTCカバレッジエンハンスメントモードの端末用のPUCCHリソース領域では、通常モードの端末用のPUCCHリソース領域と比較して、各PUCCHリソース領域全体に対する利用可能なPUCCHリソースの割合が高くなる。具体的には、図12に示すように、通常モードの端末用PUCCHリソース領域では、48個のPUCCHリソースのうち、24個のPUCCHリソースが利用可能となる。これに対して、MTCカバレッジエンハンスメントモードの端末用PUCCHリソース領域では、12個のPUCCHリソースの全てが利用可能となる。すなわち、MTCカバレッジエンハンスメントモードの端末に対して最大符号多重可能数が最大限となる。

0165

つまり、本実施の形態では、上述したようにMTCカバレッジエンハンスメントモードの端末用のPUCCHリソースにおける最大符号多重可能数を、通常モードの端末用PUCCHリソースにおける最大符号多重可能数よりも多くすることにより、利用可能なPUCCHリソース数を多くして、PUCCHリソースのオーバーヘッドを最小限に抑えることができる。

0166

例えば、12個のPUCCHリソースを利用可能とするためには、ΔshiftPUCCH_MTC=2の場合には24個のPUCCHリソースを確保する必要があるのに対して、ΔshiftPUCCH_MTC=1の場合には図12に示すように12個のPUCCHリソースを確保するだけで済む。よって、ΔshiftPUCCH_MTCをΔshiftPUCCHよりも小さくすることにより、通常モードの端末に設定される巡回シフト量の差ΔshiftPUCCHと同一とする場合と比較して、PUCCHリソースのオーバーヘッドを最小限に抑えることができる。

0167

ところで、同一RB内のPUCCHリソースにおいて、符号多重に用いられなかったPUCCHリソースは、符号拡散による符号間干渉低減効果により符号間干渉の低減に寄与する。例えば、図12に示すように、通常モードの端末用PUCCHリソースでは、利用可能なPUCCHリソース#6〜#29の隣接するリソースの間に利用されないPUCCHリソース(符号多重に用いられないPUCCHリソース)が存在し、当該PUCCHリソースが符号間干渉の低減に寄与する。

0168

これに対して、図12に示すように、MTCカバレッジエンハンスメントモードの端末用PUCCHリソースでは、符号多重に用いられないPUCCHリソースは存在しない。

0169

しかし、MTCでのトラフィック特性を考慮すると、MTCでの端末は頻繁に通信を行わないことが想定される。すなわち、MTCカバレッジエンハンスメントモードの端末用PUCCHリソースの使用頻度は確率的に低くなる。よって、MTCカバレッジエンハンスメントモードの端末用PUCCHリソースにおいて、同一RB内の最大符号多重可能数を増加させたとしても、同時に符号多重される端末数が少ないので、同一系列の隣接する巡回シフト量に対応するリソースが同時に使用される可能性は低くなる。すなわち、隣接する巡回シフト量に対応するリソースが同時に使用されることによる符号間干渉の発生の可能性が低いので、ACK/NACK信号の伝送特性劣化は生じにくい。

0170

また、MTCでの通信環境を考慮すると、MTCカバレッジエンハンスメントモードの端末に対する制御情報の符号化率が低く設定され、PDCCHを構成するL1/L2 CCHのCCEの占有数が比較的多くなることが想定される。このため、例えば、上述したように、MTCカバレッジエンハンスメントモードの端末に対して、CCE番号によりPUCCHリソース番号がImplicitに通知される場合、番号が隣接するCCEは同一の端末に使用される可能性が高くなる。よって、番号が隣接するPUCCHリソース(隣接する巡回シフト量に対応するリソース)が同時に使用される可能性は低くなる。

0171

このように、MTCカバレッジエンハンスメントモードの端末に対して、隣接する巡回シフト量の差を通常モードの場合と比較して小さく設定しても、同一RB内の最大符号多重可能数を増加させたPUCCHリソース領域での実際の使用確率が低いため、最大符号多重可能数を増加させたことに起因するACK/NACK信号の性能劣化は実質的に発生しない。

0172

このようにして、本実施の形態によれば、通常モードの端末とMTCカバレッジエンハンスメントモードの端末とに対してそれぞれ異なる、巡回シフト量の差(つまり、最大符号多重可能数)を用いてPUCCHリソースが設定される。これにより、通常モードの端末とMTCカバレッジエンハンスメントモードの端末とが共存するシステムにおいて、PUCCHリソースのオーバーヘッドの増加を最小限に抑えることができる。

0173

さらに、通常モードの端末に対するPUCCHリソースの割当はLTEシステムにおいて既に行われている。よって、本実施の形態では、MTCカバレッジエンハンスメントモードの端末に対するPUCCHリソースの割当時に独立して使用される巡回シフト量の差ΔshiftPUCCH_MTCが基地局100から端末200へ新たに通知されればよい。よって、既存のシステムの動作に与える影響は少ない。

0174

また、本実施の形態によれば、通常モードの端末とMTCカバレッジエンハンスメントモードの端末とに対してACK/NACK信号に使用されるPUCCHリソースを異ならせることにより、ACK/NACK信号を送信するPUCCHリソースの衝突を回避できる。

0175

なお、本実施の形態は、通常モードの端末(レピティションを行わない端末)とMTCカバレッジエンハンスメントモードの端末(レピティションを行う端末)とに対して、それぞれ異なる、巡回シフト量の差(つまり、最大符号多重可能数)を用いてPUCCHリソースが設定される場合について説明した。しかし、本実施の形態では、それに限らず同一セル内の端末グループ毎(例えば、同一セル内のマクロ基地局配下の端末とリモートアンテナ局配下の端末など)にそれぞれ異なる、巡回シフト量の差(つまり、最大符号多重可能数)を用いてPUCCHリソースが設定されてもよい。

0176

(実施の形態4)
前述したように、既存システムでは、CCE番号とPUCCHリソース番号とは1対1に対応付けられている。つまり、M個のCCEに対して、CCE数と同数のM個のPUCCHリソースがそれぞれ対応付けられている。例えば、図12では、MTCカバレッジエンハンスメントモードの端末に対して、CCE#0とPUCCH#60、CCE#1とPUCCH#61、CCE#2とPUCCH#62、…がそれぞれ対応付けられている。

0177

また、MTCカバレッジエンハンスメントモードの端末に対して、制御情報の誤り率特性の劣化を抑えるために、制御情報の符号化率が低く設定されることが想定される。つまり、MTCカバレッジエンハンスメントモードの端末に対するPDCCHを構成するL1/L2 CCHのCCEの占有数は比較的多くなることが想定される。例えば、MTCカバレッジエンハンスメントモードの端末に対して、CCEの占有数(アグリゲーションレベルと呼ぶこともある)として採りうる値(例えば、1,2,4,8)のうち、より大きい値(4,8)が設定されることが想定される。

0178

前述したように、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の物理リソースは使用されず無駄となる。

0179

また、MTCでのトラフィック特性を考慮すると、MTCでの端末は頻繁に通信を行わないことが想定される。すなわち、MTCカバレッジエンハンスメントモードの端末用PUCCHリソースの使用頻度は確率的に低い。

0180

そこで、本実施の形態では、MTCカバレッジエンハンスメントモードの端末に対して、M個のCCEに対してM個のPUCCHリソースを1対1で対応付けるのではなく、M個のCCEに対して、M個より少ないPUCCHリソースを対応付ける。換言すると、MTCカバレッジエンハンスメントモードの端末に対して、1個のPUCCHリソースに対して複数のCCEを関連付ける。

0181

本実施の形態に係る基地局及び端末の基本構成は、実施の形態1と同様であるので、図8(基地局100)と図9(端末200)を援用して説明する。

0182

基地局100及び端末200は、本実施の形態に係るCCEとPUCCHリソースとの対応付けを予め保持する。

0183

以下、本実施の形態に係るCCEとPUCCHリソースとの対応付けに関する方法1及び方法2についてそれぞれ説明する。

0184

なお、本実施の形態では、例えば、図12に示すように、通常モードの端末及びMTCカバレッジエンハンスメントモードの端末の各々に対して異なるPUCCHリソース領域が設定される。例えば、通常モードの端末及びMTCカバレッジエンハンスメントモードの端末に対するPUCCHリソースは、実施の形態1又は実施の形態2と同様の方法により設定されてもよい。ただし、本実施の形態では、MTCカバレッジエンハンスメントモードの端末に対するPUCCHリソースの割当として、上位レイヤシグナリングなどを用いて、基地局100から端末200へExplicitに通知されてもよい。また、MTCカバレッジエンハンスメントモードの端末が利用可能なPUCCHリソース間の巡回シフト量の差は、実施の形態3と同様1とする(ΔshiftPUCCH_MTC=1)。

0185

以下では、MTCカバレッジエンハンスメントモードの端末用のPUCCHリソース(#60〜#71)に着目する。

0186

<方法1(図13)>
方法1は、CCE番号とPUCCHリソースとの対応付けをN対1とする方法である。

0187

例えば、図13は、N=4とした場合のCCE番号とPUCCHリソース番号との対応付けの一例を示す。

0188

図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に対応付けられている。

0189

例えば、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が使用される。

0190

例えば、MTCカバレッジエンハンスメントモードの端末が使用するPUCCHリソース番号nPUCCH_MTCは次式に従って決定される。
nPUCCH_MTC=floor(nCCE/N)+NPUCCH_MTC(1) (4)

0191

式(4)において、関数「floor(X)」は、X以下の最大の整数を返す床関数を表す。また、nCCEは、PDCCHが占有するCCEのうち最も小さいCCEの番号を示し、Nは、1つのPUCCHリソースに対応付けられるCCE数(図13ではN=4)を示す。また、NPUCCH_MTC(1)は、MTCカバレッジエンハスメントモードの端末に対するオフセット値を示す。例えば、図13では、NPUCCH_MTC(1)=60である。

0192

方法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リソースのみを確保すればよい。

0193

<方法2>
方法2は、1つのPUCCHリソースに対応付けられるCCE数を、CCEの占有数(アグリゲーションレベル)として採りうる値とする方法である。

0194

例えば、方法2では、MTCカバレッジエンハンスメントモードの端末に対してCCE占有数N(>1)が設定されるとする。

0195

例えば、図14は、N=4とした場合のCCE番号とPUCCHリソース番号との対応付けの一例を示す。

0196

図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リソースが対応付けられる。

0197

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が使用される。

0198

例えば、MTCカバレッジエンハンスメントモードの端末が使用するPUCCHリソース番号nPUCCH_MTCは次式に従って決定される。
nPUCCH_MTC=nCCE/N+NPUCCH_MTC(1) (5)

0199

式(5)においてnCCEは、PDCCHが占有するCCEのうち最も小さいCCEの番号を示し、Nは、MTCカバレッジエンハンスメントモードの端末に対するCCE占有数(図13ではN=4)を示す。また、NPUCCH_MTC(1)は、MTCカバレッジエンハスメントモードの端末に対するオフセット値を示す。例えば、図14では、NPUCCH_MTC(1)=60である。

0200

方法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リソースのみを確保すればよい。

0201

また、各PUCCHリソースは、各端末が占有するCCE数の単位でCCEに対応付けられているので、1つのPUCCHリソースに対応付けられたN個のCCEが複数の端末間で同時に使用されることはない。

0202

以上、方法1及び方法2について説明した。

0203

このように、本実施の形態では、MTCカバレッジエンハンスメントモードの端末に対して、複数のCCEを1個のPUCCHリソースに関連付ける。これにより、MTCカバレッジエンハンスメントモードの端末用のPUCCHリソースとして確保するリソースの増加を抑えることができる。よって、MTCカバレッジエンハンスメントモードの端末が存在するシステム(MTCカバレッジエンハンスメントモードの端末用のPUCCHリソースが追加的に設定される場合)でも、PUCCHリソースのオーバーヘッドの増加を抑えることができる。

0204

また、本実施の形態によれば、通常モードの端末とMTCカバレッジエンハンスメントモードの端末とに対してACK/NACK信号に使用されるPUCCHリソースを異ならせることにより、ACK/NACK信号を送信するPUCCHリソースの衝突を回避できる。

0205

(実施の形態5)
MTCカバレッジエンハンスメントモードの端末間において、既存のシステムと同様にしてCCE番号と対応付けてPUCCHリソース番号をImplicitに通知するのでは、PDCCH及びPUCCHのレピティションレベルが異なる端末が存在すると、同一PUCCHリソースを用いてACK/NACK信号が同時に送信され、PUCCHリソースの衝突が発生する場合がある。

0206

図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だけ大きい。

0207

また、図15では、端末1がCCE#0からCCE#3を用いてPDCCHを送信する。一方、端末2は、端末1のPDCCHが送信完了した次のサブフレームから、CCE#0からCCE#3を用いてPDCCHを送信する。つまり、端末1及び端末2の双方は、CCE#0に対応付けられたPUCCHリソースを用いてACK/NACK信号を送信する。

0208

図15に示すように、端末1は、NPUCCH+αPUCCHサブフレームに渡ってACK/NACK信号を送信し、端末2は、端末1がACK/NACK信号をNPUCCHサブフレーム送信した次のサブフレームからNPUCCHに渡ってACK/NACK信号を送信する。このため、図15に示すように、端末1のPUCCHレピティション後半のαPUCCHサブフレーム、及び、端末2のPUCCHレピティション前半のαPUCCHサブフレームに相当するサブフレームにおいてPUCCHリソースが端末間で衝突してしまう。

0209

そこで、本実施の形態では、MTCカバレッジエンハンスメントモードの端末間のACK/NACK信号を送信するPUCCHリソースの衝突を回避する方法について説明する。

0210

本実施の形態に係る基地局及び端末の基本構成は、実施の形態1と同様であるので、図8(基地局100)と図9(端末200)を援用して説明する。

0211

具体的には、端末200(MTCカバレッジエンハンスメントモードの端末)は、PDCCHとPUCCHとのレピティションレベルが異なる場合、PUCCHレピティションにおいて、PDCCHのレピティションレベルと同数のサブフレームまでは、CCE番号(つまり、最小のCCE番号)に対応付けてImplicitに通知されるPUCCHリソースを用いて、ACK/NACK信号を送信する。

0212

一方、端末200は、PDCCHのレピティションレベルを超えるサブフレームでは、Explicitに割り当てられたPUCCHリソースを用いてACK/NACK信号を送信する。当該PUCCHリソースは、基地局100から端末200に対して予め通知される。

0213

図16は、本実施の形態に係る各チャネルの送信タイミングを示す。図16では、図15と同様、端末1(UE#1)及び端末2(UE#2)のPDCCH及びPDSCHのレピティションレベルをそれぞれNPDCCH、NPDSCHとする。また、端末1のPUCCHのレピティションレベルをNPUCCH+αPUCCHとし、端末2のPUCCHのレピティションレベルをNPUCCHとする。また、図16では、NPUCCHはNPDCCHと同一である。

0214

また、図16では、端末1がCCE#0からCCE#3を用いてPDCCHを送信する。一方、端末2は、端末1のPDCCHが送信完了した次のサブフレームから、CCE#0からCCE#3を用いてPDCCHを送信する。

0215

この場合、図16に示すように、端末1は、PUCCHレピティションにおいて、NPUCCH+αPUCCHサブフレームのうち、NPDCCHと同数のNPUCCHサブフレームまでは、PDCCHに使用されたCCEのうち最小のインデックスを有するCCE#0に対応付けられたPUCCHリソースを用いてACK/NACK信号を送信する。

0216

一方、端末1は、NPUCCH+αPUCCHサブフレームのうち、NPUCCHサブフレームを超えたαPUCCHサブフレーム以降では、Explicitに通知されたPUCCHリソースを用いてACK/NACK信号を送信する。

0217

また、図16に示すように、端末2は、PUCCHレピティションにおいて、端末1がACK/NACK信号をNPUCCHサブフレーム送信した次のサブフレームからNPUCCHサブフレームに渡って、PDCCHに使用されたCCEのうち最小のインデックスを有するCCE#0に対応付けられたPUCCHリソースを用いてACK/NACK信号を送信する。

0218

つまり、図16では、端末1のPUCCHレピティション後半のαPUCCHサブフレーム、及び、端末2のPUCCHレピティション前半のαPUCCHサブフレームに該当するサブフレームでは、端末1及び端末2の双方において互いに異なるPUCCHリソースが用いられる。よって、端末1と端末2との間でのPUCCHリソースの衝突は発生しない。

0219

このように、端末200は、ACK/NACK信号のレピティション送信が行われる複数のサブフレームのうち、PDCCHのレピティションレベル以下のサブフレームでは、MTCカバレッジエンハンスメントモードの端末用のPUCCHリソースのうち、PDCCHに使用されるCCEに対応付けられたPUCCHリソースを用いて、ACK/NACK信号を送信し、PDCCHのレピティションレベルを超えるサブフレームでは、予め設定されたPUCCHリソースのいずれかを用いて、ACK/NACK信号を送信する。

0220

こうすることで,PDCCHとPUCCHのレピティションレベルが異なるMTCカバレッジエンハンスメントモードの端末が存在する場合に、同一のCCEを用いてPDCCHを送信したMTCカバレッジエンハンスメントモードの端末間においてACK/NACK信号を同時に送信するサブフレームが発生しても、ACK/NACK信号を送信するPUCCHリソースが端末間で衝突することを回避することができる。

0221

なお、本実施の形態は、実施の形態1〜4の動作と組み合わせてもよい。つまり、MTCカバレッジエンハンスメントモードの端末同士のPUCCHリソースの衝突を回避する方法について本実施の形態を適用し、MTCカバレッジエンハンスメントモードの端末と通常モードの端末との間のPUCCHリソースの衝突を回避する方法について、実施の形態1〜4のいずれかを適用すればよい。

0222

(実施の形態6)
実施の形態5では、PDCCHとPUCCHのレピティションレベルが異なる端末について説明した。これに対し、本実施の形態では、各端末でのPDCCHとPUCCHのレピティションレベルは同一であるが、端末間のレピティションレベルが異なる場合について説明する。

0223

この場合、MTCカバレッジエンハンスメントモードの端末間において、既存のシステムと同様にしてCCE番号と対応付けてPUCCHリソース番号をImplicitに通知するのでは、端末間において同一PUCCHリソースを用いてACK/NACK信号が同時に送信され、PUCCHリソースの衝突が発生する場合がある。

0224

図17は、MTCカバレッジエンハンスメントモードの端末間のPUCCHリソースが衝突する場合の一例を示す。図17では、端末1(UE#1)のPDCCH、PDSCH、PUCCHのレピティションレベルが8であり、端末2(UE#2)のPDCCH、PDSCH、PUCCHのレピティションレベルが4である。

0225

また、図17では、端末1がCCE#0からCCE#3を用いてPDCCHを送信する。一方、端末2は、端末1のPDCCHが送信完了した次のサブフレームから、CCE#0からCCE#3を用いてPDCCHを送信する。つまり、端末1及び端末2の双方は、CCE#0に対応付けられたPUCCHリソースを用いてACK/NACK信号を送信する。

0226

図17に示すように、端末1は、8サブフレームに渡ってPDCCHを受信し、次の8サブフレームに渡ってPDSCHを受信する。一方、端末2は、端末1がPDCCHの受信を完了した次のサブフレームから4サブフレームに渡ってPDCCHを受信し、次の4サブフレームに渡ってPDSCHを受信する。つまり、端末1と端末2とは、PDSCHの受信完了のタイミング(又はACK/NACK信号の送信開始タイミング)が同一となる。

0227

この場合、同一タイミングにおいて、端末1は、8サブフレームに渡ってACK/NACK信号を送信し、端末2は、4サブフレームに渡ってACK/NACK信号を送信する。このため、図17に示すように、端末1のPUCCHレピティション前半の4サブフレーム、及び、端末2のPUCCHレピティションの全4サブフレームに相当するサブフレームにおいてPUCCHリソースが端末間で衝突してしまう。

0228

そこで、本実施の形態では、レピティションレベルが互いに異なるMTCカバレッジエンハンスメントモードの端末間のACK/NACK信号を送信するPUCCHリソースの衝突を回避する方法について説明する。

0229

本実施の形態に係る基地局及び端末の基本構成は、実施の形態1と同様であるので、図8(基地局100)と図9(端末200)を援用して説明する。

0230

具体的には、端末200(MTCカバレッジエンハンスメントモードの端末)は、PUCCHレピティションにおいて、PDCCHの送信に使用されたCCE番号(つまり、最小のCCE番号)に対応付けてImplicitに通知されるPUCCHリソースを用いて、ACK/NACK信号を送信する。ただし、端末200は、設定されるレピティションレベル毎に異なるオフセット値を用いて特定されるPUCCHリソースを用いてACK/NACK信号を送信する。

0231

例えば、レピティションレベルが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)

0232

式(6)、(7)において、nCCEは、PDCCHが占有するCCE番号(0以上の整数)を示す。また、式(6)、(7)において、NPUCCH_MTC_4(1)は、レピティションレベルが4の場合にCCE番号からPUCCHリソース番号を特定するためのオフセット値を示し、NPUCCH_MTC_8(1)は、レピティションレベルが8の場合にCCE番号からPUCCHリソース番号を特定するためのオフセット値を示す。

0233

NPUCCH_MTC_4(1)とNPUCCH_MTC_8(1)は、異なる値が設定される。換言すると、端末200が利用可能なPUCCHリソースは、少なくとも、レピティションレベルが4の場合のPUCCHリソースと、レピティションレベルが8の場合のPUCCHリソースとに分割される。つまり、端末200が利用可能なPUCCHリソース群は、ACK/NACK信号のレピティションレベル毎の複数のサブリソース群から構成される。

0234

なお、ここでは、レピティションレベルが4、8の場合について説明するが、レピティションレベルは4,8に限定されず、他の値を採り得る場合にはその値についても同様にしてオフセット値が設定される。

0235

図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を送信する。

0236

この場合、図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信号を送信する。

0237

上述したように、NPUCCH_MTC_4(1)とNPUCCH_MTC_8(1)とは互いに異なる。よって、図18に示すように、端末1のPUCCHレピティション前半の4サブフレーム、及び、端末2のPUCCHレピティションの全4サブフレームに該当するサブフレームでは、端末1及び端末2の双方において互いに異なるPUCCHリソースが用いられる。このため、端末1と端末2との間でのPUCCHリソースの衝突は発生しない。

0238

このようにすることで,レピティションレベルが異なるMTCカバレッジエンハンスメントモードの端末間において、同一のCCEを用いてPDCCHを送信し、ACK/NACK信号を同時に送信するサブフレームが発生しても、ACK/NACK信号を送信するPUCCHリソースが端末間で衝突することを回避することができる。

0239

なお、本実施の形態は、実施の形態1〜4の動作と組み合わせて実施してもよい。つまり、MTCカバレッジエンハンスメントモードの端末同士のPUCCHリソースの衝突を回避する方法について本実施の形態を適用し、MTCカバレッジエンハンスメントモードの端末と通常モードの端末との間のPUCCHリソースの衝突を回避する方法について、実施の形態1〜4のいずれかを適用すればよい。

0240

以上、本開示の各実施の形態について説明した。

0241

なお、上記各実施の形態では、本開示の一態様をハードウェアで構成する場合を例にとって説明したが、本開示はソフトウェアで実現することも可能である。

0242

また、上記各実施の形態の説明に用いた各機能ブロックは、典型的には集積回路であるLSIとして実現される。これらは個別に1チップ化されてもよいし、一部または全てを含むように1チップ化されてもよい。ここでは、LSIとしたが、集積度の違いにより、IC、システムLSIスーパーLSI、ウルトラLSIと呼称されることもある。

0243

また、集積回路化の手法はLSIに限るものではなく、専用回路または汎用プロセッサで実現してもよい。LSI製造後に、プログラムすることが可能なFPGA(Field Programmable Gate Array)や、LSI内部の回路セルの接続や設定を再構成可能なリコンフィギュラブルプロセッサーを利用してもよい。

0244

さらには、半導体技術の進歩または派生する別技術によりLSIに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。

0245

本開示の端末は、下りリンクデータの割当を示す制御情報、及び、前記下りリンクデータを受信する受信部と、前記制御情報に基づいて、前記下りリンクデータに対する応答信号に使用されるリソースを決定する制御部と、前記決定されたリソースを用いて前記応答信号を送信する送信部と、を具備し、前記送信部は、自端末が、前記制御情報、前記下りリンクデータ及び前記応答信号に対してレピティション送信が適用される第1の端末である場合には第1のリソース群の中のリソースを用いて前記応答信号を送信し、自端末が、前記レピティション送信が適用されない第2の端末である場合には前記第1のリソース群とは異なる第2のリソース群の中のリソースを用いて前記応答信号を送信する構成を採る。

0246

本開示の端末において、前記制御部は、前記制御情報に使用されるコントロール・チャネル・エレメント(CCE)のインデックスに第1のオフセット値を加算して、前記第1のリソース群において前記応答信号に使用されるリソースを算出し、前記制御情報に使用される前記CCEのインデックスに第2のオフセット値を加算して、前記第2のリソース群において前記応答信号に使用されるリソースを算出し、前記第1のオフセット値と前記第2のオフセット値とは異なる。

0247

本開示の端末において、前記制御部は、前記制御情報に使用されるコントロール・チャネル・エレメント(CCE)のインデックスにオフセット値を加算して、前記第1のリソース群において前記応答信号に使用されるリソースを算出し、前記オフセット値から、前記制御情報に使用される前記CCEのインデックスを減算して、前記第2のリソース群において前記応答信号に使用されるリソースを算出する。

0248

本開示の端末において、前記第1のリソース群及び前記第2のリソース群の各リソースは、直交符号系列と巡回シフト量との組合せによってそれぞれ定義され、前記第1のリソース群の各リソースとして定義された前記組合せのうち、同一直交符号系列において隣接する巡回シフト量の差は、前記第2のリソース群の各リソースとして定義された前記組合せのうち、同一直交符号系列において隣接する巡回シフト量の差よりも小さい。

0249

本開示の端末において、前記制御情報に使用されるコントロール・チャネル・エレメント(CCE)の複数個に対して、前記第1のリソース群の1つのリソースが対応付けられる。

0250

本開示の端末において、前記複数個は、前記割当情報が占有するCCEの個数である。

0251

本開示の端末において、前記送信部は、前記応答信号の前記レピティション送信が行われる複数のサブフレームのうち、前記制御情報のレピティション回数以下のサブフレームでは、前記第1のリソース群のうち、前記制御情報に使用されるコントロール・チャネル・エレメント(CCE)に対応付けられたリソースを用いて、前記応答信号を送信し、前記制御情報のレピティション回数を超えるサブフレームでは、予め設定されたリソースを用いて、前記応答信号を送信する。

0252

本開示の端末において、前記第1のリソース群は、前記応答信号のレピティション回数毎の複数のサブリソース群から構成される。

0253

本開示の基地局は、下りリンクデータの割当を示す制御情報、及び、前記下りリンクデータを送信する送信部と、前記制御情報に基づいて、前記下りリンクデータに対する応答信号に使用されるリソースを決定する制御部と、前記決定されたリソースを用いて前記応答信号を受信する受信部と、を具備し、前記受信部は、前記制御情報、前記下りリンクデータ及び前記応答信号に対してレピティション送信が適用される第1の端末から送信される前記応答信号を、第1のリソース群の中のリソースを用いて受信し、前記レピティション送信が適用されない第2の端末から送信される前記応答信号を、前記第1のリソース群とは異なる第2のリソース群の中のリソースを用いて受信する。

0254

本開示の送信方法は、下りリンクデータの割当を示す制御情報、及び、前記下りリンクデータを受信する受信工程と、前記制御情報に基づいて、前記下りリンクデータに対する応答信号に使用されるリソースを決定する制御工程と、前記決定されたリソースを用いて前記応答信号を送信する送信工程と、を具備し、前記送信工程は、前記制御情報、前記下りリンクデータ及び前記応答信号に対してレピティション送信が適用される第1の端末では第1のリソース群の中のリソースを用いて前記応答信号を送信し、前記レピティション送信が適用されない第2の端末では前記第1のリソース群とは異なる第2のリソース群の中のリソースを用いて前記応答信号を送信する。

0255

本開示の受信方法は、下りリンクデータの割当を示す制御情報、及び、前記下りリンクデータを送信する送信工程と、前記制御情報に基づいて、前記下りリンクデータに対する応答信号に使用されるリソースを決定する制御工程と、前記決定されたリソースを用いて前記応答信号を受信する受信工程と、を具備し、前記受信工程は、前記制御情報、前記下りリンクデータ及び前記応答信号に対してレピティション送信が適用される第1の端末から送信される前記応答信号を、第1のリソース群の中のリソースを用いて受信し、前記レピティション送信が適用されない第2の端末から送信される前記応答信号を、前記第1のリソース群とは異なる第2のリソース群の中のリソースを用いて受信する。

0256

本開示の一態様は、移動通信システムに有用である。

0257

100基地局
200端末
101,213 制御部
102制御信号生成部
103 制御信号符号化部
104 制御信号変調部
105報知信号生成部
106データ符号化部
107再送制御部
108データ変調部
109 信号割当部
110,218IFFT部
111,219 CP付加部
112,220 送信部
113アンテナ
114,202 受信部
115,203 CP除去部
116 PUCCH抽出部
117系列制御部
118逆拡散部
119相関処理部
120,209 判定部
204FFT部
205 抽出部
206 報知信号受信部
207 制御信号復調部
208 制御信号復号部
210データ復調部
211データ復号部
212CRC部
214ACK/NACK生成部
215 変調部
216 1次拡散部
217 2次拡散部

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

  • 株式会社ジゴワッツの「 認証システム」が 公開されました。( 2021/04/01)

    【課題】不正行為に対して十分な安全性を確保できる認証システムを提供する。【解決手段】認証システム10は、認証サーバ(A社サーバ1、B社サーバ2、スマートフォンサービスC社サーバ3)と、ユーザ端末(スマ... 詳細

  • 株式会社NTTドコモの「 ユーザ端末及び無線基地局」が 公開されました。( 2021/04/01)

    【課題・解決手段】本開示の一態様に係るユーザ端末は、上り共有チャネルの送信を指示する下り制御情報(DCI:Downlink Control Information)を受信する受信部と、前記DCIに... 詳細

  • 株式会社NTTドコモの「 ユーザ端末及び無線基地局」が 公開されました。( 2021/04/01)

    【課題・解決手段】ユーザ端末は、下り制御チャネルを受信する受信部と、前記下り制御チャネルに基づいて前記上り制御チャネル用の初期巡回シフトインデックスを決定する制御部であって、異なる下り制御チャネルに基... 詳細

この 技術と関連性が強い技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ