(57)【要約】【課題】ＰＤＳＣＨと当該ＰＤＳＣＨを受信するために必要な割り当て情報を通知するＰＤＣＣＨとが異なるサブフレームで送信される場合、端末間でのＰＵＣＣＨの衝突を回避又は低減することを目的とする。【解決手段】物理下りリンク共有チャネルと、当該物理下りリンク共有チャネルを受信するために必要な割り当て情報を通知する物理下りリンク制御チャネルとを異なるサブフレームで送信する基地局は、物理上りリンク制御チャネルのリソース割り当て情報又は物理下りリンク制御チャネルのリソース割り当て情報を格納するリソース割り当て情報記憶部と、前記リソース割り当て情報記憶部を参照して、複数の移動局からの物理上りリンク制御チャネルの間で衝突が生じないように物理下りリンク制御チャネルのリソースを割り当てるリソース割り当て部と、物理下りリンク制御チャネル及び物理下りリンク共有チャネルを送信する送信部とを有する。【選択図】図５
2015164279.tif 000002
【特許請求の範囲】
【請求項１】
物理下りリンク共有チャネルと、当該物理下りリンク共有チャネルを受信するために必要な割り当て情報を通知する物理下りリンク制御チャネルとを異なるサブフレームで送信する基地局であって、
物理上りリンク制御チャネルのリソース割り当て情報又は物理下りリンク制御チャネルのリソース割り当て情報を格納するリソース割り当て情報記憶部と、
前記リソース割り当て情報記憶部を参照して、複数の移動局からの物理上りリンク制御チャネルの間で衝突が生じないように物理下りリンク制御チャネルのリソースを割り当てるリソース割り当て部と、
物理下りリンク制御チャネル及び物理下りリンク共有チャネルを送信する送信部と、
を有する基地局。
【請求項２】
物理下りリンク共有チャネルと、当該物理下りリンク共有チャネルを受信するために必要な割り当て情報を通知する物理下りリンク制御チャネルとを異なるサブフレームで送信する基地局における送信方法であって、
物理上りリンク制御チャネルのリソース割り当て情報又は物理下りリンク制御チャネルのリソース割り当て情報を参照して、複数の移動局からの物理上りリンク制御チャネルの間で衝突が生じないように物理下りリンク制御チャネルのリソースを割り当てるステップと、
物理下りリンク制御チャネル及び物理下りリンク共有チャネルを送信するステップと、
を有する送信方法。
【請求項３】
物理下りリンク共有チャネルと、当該物理下りリンク共有チャネルを受信するために必要な割り当て情報を通知する物理下りリンク制御チャネルとを異なるサブフレームで受信する移動局であって、
物理下りリンク共有チャネルに対する再送判定を行う判定部と、
物理下りリンク共有チャネルの再送が必要ない場合、物理上りリンク制御チャネルを送信せず、物理下りリンク共有チャネルの再送が必要である場合、再送を要求するための送達確認情報を物理上りリンク制御チャネルで送信する送信部と、
を有する移動局。
【請求項４】
物理下りリンク共有チャネルと、当該物理下りリンク共有チャネルを受信するために必要な割り当て情報を通知する物理下りリンク制御チャネルとを異なるサブフレームで受信する移動局における再送制御方法であって、
物理下りリンク共有チャネルに対する再送判定を行うステップと、
物理下りリンク共有チャネルの再送が必要ない場合、物理上りリンク制御チャネルを送信せず、物理下りリンク共有チャネルの再送が必要である場合、再送を要求するための送達確認情報を物理上りリンク制御チャネルで送信するステップと、
を有する再送制御方法。
【請求項５】
物理下りリンク共有チャネルと、当該物理下りリンク共有チャネルを受信するために必要な割り当て情報を通知する物理下りリンク制御チャネルとを異なるサブフレームで送信する基地局であって、
物理上りリンク制御チャネルのリソース割り当て情報又は物理下りリンク制御チャネルのリソース割り当て情報を格納するリソース割り当て情報記憶部と、
前記リソース割り当て情報記憶部を参照して、物理上りリンク制御チャネルのリソースを決定するリソース割り当て部と、
移動局に使用させる物理上りリンク制御チャネルのリソースを決定するためのインジケータを送信する送信部と、
を有する基地局。
【請求項６】
前記送信部は、予め通知した物理上りリンク制御チャネルのリソースの候補の中から、移動局に使用させる物理上りリンク制御チャネルのリソースを決定するためのインジケータを送信する、請求項５に記載の基地局。
【請求項７】
物理下りリンク共有チャネルと、当該物理下りリンク共有チャネルを受信するために必要な割り当て情報を通知する物理下りリンク制御チャネルとを異なるサブフレームで送信する基地局における送信方法であって、
物理上りリンク制御チャネルのリソース割り当て情報又は物理下りリンク制御チャネルのリソース割り当て情報を参照して、物理上りリンク制御チャネルのリソースを決定するステップと、
移動局に使用させる物理上りリンク制御チャネルのリソースを決定するためのインジケータを送信するステップと、
を有する送信方法。
【請求項８】
物理下りリンク共有チャネルと、当該物理下りリンク共有チャネルを受信するために必要な割り当て情報を通知する物理下りリンク制御チャネルとを異なるサブフレームで受信する移動局であって、
物理上りリンク制御チャネルのリソースを決定するためのインジケータを受信する受信部と、
物理下りリンク共有チャネルに対する再送判定を行う判定部と、
受信したインジケータに従って決定された物理上りリンク制御チャネルのリソースを用いて、再送判定の結果を示す送達確認情報を物理上りリンク制御チャネルで送信する送信部と、
を有する移動局。
【請求項９】
物理下りリンク共有チャネルと、当該物理下りリンク共有チャネルを受信するために必要な割り当て情報を通知する物理下りリンク制御チャネルとを異なるサブフレームで受信する移動局における再送制御方法であって、
物理上りリンク制御チャネルのリソースを決定するためのインジケータを受信するステップと、
物理下りリンク共有チャネルに対する再送判定を行うステップと、
受信したインジケータに従って決定された物理上りリンク制御チャネルのリソースを用いて、再送判定の結果を示す送達確認情報を物理上りリンク制御チャネルで送信するステップと、
を有する再送制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、基地局、送信方法、移動局及び再送制御方法に関する。
【背景技術】
【０００２】
近年、ＭＴＣ（Machine Type Communication）端末の需要が高まっている。ＭＴＣ端末とは、例えば、電気メーター、ガスメータ、自動販売機、車両、その他産業機器等に搭載される通信端末である。このようなＭＴＣ端末は、移動しないという特性、定期的に少量のデータを送信するという特性等のため、通常の端末（ＵＥ：User Equipment）とは異なる仕様が検討されている（非特許文献１参照）。
【０００３】
ＭＴＣ端末では、上述したような利用形態を鑑み、低コストなＭＴＣ端末を実現するための技術が求められている。また、ＭＴＣ端末は、屋内の制御ボックス内のように、伝搬ロスが非常に大きい場所での利用も考えられる。従って、ＭＴＣ端末のカバレッジを拡張する技術が求められている。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】3GPP TR36.888 V12.0.0 (2013-06)
【非特許文献２】3GPP TS36.213 V12.0.0 (2013-12)
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ＭＴＣ端末に関して、ローコストモード（low cost mode）とカバレッジ拡張モード（enhanced coverage mode）を含むいくつかのモードが検討されている。
【０００６】
ローコストモードは、ＭＴＣ端末を低コスト化を図るためのモードである。例えば、ローコストモードのＭＴＣ端末では、送信データレートを抑えたり、あるいはデータ信号のベースバンドの受信帯域幅を小さくすることによってＭＴＣ端末のバッファの小サイズ化が図られる。また、通常の端末では２つのアンテナが備えられる一方、ＭＴＣ端末では１つのアンテナが備えられ、低コスト化が図られている。
【０００７】
他方、カバレッジ拡張モードは、ＭＴＣ端末のカバレッジを拡張するためのモードである。カバレッジ拡張モードのＭＴＣ端末では、通信品質を向上させるための各種機能が備えられている。。
【０００８】
ＬＴＥ（Long Term Evolution）システムの通常の端末とＭＴＣ端末とでは、異なる通信仕様が利用される。一例として、ＬＴＥシステムの通常の端末では、下りリンクデータを送信するための物理下りリンク共有チャネル（ＰＤＳＣＨ：Physical Downlink Shared Channel）と、ＰＤＳＣＨを受信するために必要な割り当て情報（DL assignment）を通知する物理下りリンク制御チャネル（ＰＤＣＣＨ：Physical Downlink Control Channel）とは、同一のサブフレームで送信される。一方、ＭＴＣ端末では、ＰＤＳＣＨとＰＤＣＣＨとは、異なるサブフレームで送信される。特に、ＭＴＣ端末用のカバレッジ拡張モードでは、ＭＴＣ端末の受信品質を向上させるため、異なるサブフレームにおいてＰＤＣＣＨ及びＰＤＳＣＨが繰り返し送信される。
【０００９】
図１に、カバレッジ拡張モードにおけるＰＤＣＣＨとＰＤＳＣＨとの関係を示す。カバレッジ拡張モードにおける割り当て情報を通知するＰＤＣＣＨとＰＤＳＣＨとのタイミング関係は予め決められており、図１に示すように、ＰＤＣＣＨとＰＤＳＣＨとは同一のサブフレームで送信されず、複数のサブフレームでＰＤＣＣＨが送信された後に、複数のサブフレームでＰＤＳＣＨが送信される。すなわち、ＰＤＣＣＨが送信される最後のサブフレームを第ｎサブフレームとすると、第（ｎ＋ｋ）サブフレーム（ｋ＞０）からＰＤＳＣＨの送信が始まる。他方、ローコストモードでは、典型的には、このような繰り返しの送信は行われず、あるサブフレームでＰＤＣＣＨが送信された後に、他のサブフレームでＰＤＳＣＨが送信される。
【００１０】
ローコストモード及びカバレッジ拡張モードにおいても、送達確認情報（ＡＣＫ／ＮＡＣＫ）が物理上りリンク制御チャネル（ＰＵＣＣＨ：Physical Uplink Shared Channel）で送信される。ＬＴＥシステムでは、ＰＵＣＣＨのリソースは、以下の式（１）によって割り当てられる（非特許文献２参照）。
【００１１】
nPUCCH=nCCE+NPUCCH      （１）
ただし、nPUCCHはＰＵＣＣＨのリソースを表す番号であり、nCCEはＰＵＣＣＨに対応するＰＤＣＣＨの最初のＣＣＥ（Control Channel Element）インデックスであり、NPUCCHは、上位レイヤのシグナリングにより設定されるインデックスである。すなわち、ＰＵＣＣＨのリソースは、ＰＤＣＣＨのリソース割り当て位置により求められる。
【００１２】
端末は、ＰＤＳＣＨを受信して一定の時間後（例えば4ms後）に、式（１）により求められたリソースを用いてＰＵＣＣＨを送信する。式（１）は、ＰＤＣＣＨとＰＤＳＣＨとが同一のサブフレームで送信されることを前提として、ＰＵＣＣＨのリソースを求めているため、ＰＤＣＣＨとＰＤＳＣＨとが異なるサブフレームで送信される場合、端末間でＰＵＣＣＨのリソースが衝突する可能性がある。
【００１３】
このようなＰＵＣＣＨのリソースの衝突は、ＰＤＣＣＨが送信されるサブフレームとＰＤＳＣＨが送信されるサブフレームとの関係が異なるユーザが混在する場合に生じる。特に、カバレッジ拡張モードのＭＴＣ端末のようにＰＤＣＣＨとＰＤＳＣＨとが繰り返し送信される場合には、ＰＵＣＣＨのリソースが衝突する確率は更に増加することが予想される。
【００１４】
本発明は、ＰＤＳＣＨと当該ＰＤＳＣＨを受信するために必要な割り当て情報を通知するＰＤＣＣＨとが異なるサブフレームで送信される場合、端末間でのＰＵＣＣＨの衝突を回避又は低減することを目的とする。
【課題を解決するための手段】
【００１５】
本発明の一形態に係る基地局は、
物理下りリンク共有チャネルと、当該物理下りリンク共有チャネルを受信するために必要な割り当て情報を通知する物理下りリンク制御チャネルとを異なるサブフレームで送信する基地局であって、
物理上りリンク制御チャネルのリソース割り当て情報又は物理下りリンク制御チャネルのリソース割り当て情報を格納するリソース割り当て情報記憶部と、
前記リソース割り当て情報記憶部を参照して、複数の移動局からの物理上りリンク制御チャネルの間で衝突が生じないように物理下りリンク制御チャネルのリソースを割り当てるリソース割り当て部と、
物理下りリンク制御チャネル及び物理下りリンク共有チャネルを送信する送信部と、
を有する。
【００１６】
また、本発明の一形態に係る送信方法は、
物理下りリンク共有チャネルと、当該物理下りリンク共有チャネルを受信するために必要な割り当て情報を通知する物理下りリンク制御チャネルとを異なるサブフレームで送信する基地局における送信方法であって、
物理上りリンク制御チャネルのリソース割り当て情報又は物理下りリンク制御チャネルのリソース割り当て情報を参照して、複数の移動局からの物理上りリンク制御チャネルの間で衝突が生じないように物理下りリンク制御チャネルのリソースを割り当てるステップと、
物理下りリンク制御チャネル及び物理下りリンク共有チャネルを送信するステップと、
を有する。
【００１７】
また、本発明の一形態に係る移動局は、
物理下りリンク共有チャネルと、当該物理下りリンク共有チャネルを受信するために必要な割り当て情報を通知する物理下りリンク制御チャネルとを異なるサブフレームで受信する移動局であって、
物理下りリンク共有チャネルに対する再送判定を行う判定部と、
物理下りリンク共有チャネルの再送が必要ない場合、物理上りリンク制御チャネルを送信せず、物理下りリンク共有チャネルの再送が必要である場合、再送を要求するための送達確認情報を物理上りリンク制御チャネルで送信する送信部と、
を有する。
【００１８】
また、本発明の一形態に係る再送制御方法は、
物理下りリンク共有チャネルと、当該物理下りリンク共有チャネルを受信するために必要な割り当て情報を通知する物理下りリンク制御チャネルとを異なるサブフレームで受信する移動局における再送制御方法であって、
物理下りリンク共有チャネルに対する再送判定を行うステップと、
物理下りリンク共有チャネルの再送が必要ない場合、物理上りリンク制御チャネルを送信せず、物理下りリンク共有チャネルの再送が必要である場合、再送を要求するための送達確認情報を物理上りリンク制御チャネルで送信するステップと、
を有する。
【００１９】
また、本発明の一形態に係る基地局は、
物理下りリンク共有チャネルと、当該物理下りリンク共有チャネルを受信するために必要な割り当て情報を通知する物理下りリンク制御チャネルとを異なるサブフレームで送信する基地局であって、
物理上りリンク制御チャネルのリソース割り当て情報又は物理下りリンク制御チャネルのリソース割り当て情報を格納するリソース割り当て情報記憶部と、
前記リソース割り当て情報記憶部を参照して、物理上りリンク制御チャネルのリソースを決定するリソース割り当て部と、
移動局に使用させる物理上りリンク制御チャネルのリソースを決定するためのインジケータを送信する送信部と、
を有する。
【００２０】
また、本発明の一形態に係る送信方法は、
物理下りリンク共有チャネルと、当該物理下りリンク共有チャネルを受信するために必要な割り当て情報を通知する物理下りリンク制御チャネルとを異なるサブフレームで送信する基地局における送信方法であって、
物理上りリンク制御チャネルのリソース割り当て情報又は物理下りリンク制御チャネルのリソース割り当て情報を参照して、物理上りリンク制御チャネルのリソースを決定するステップと、
移動局に使用させる物理上りリンク制御チャネルのリソースを決定するためのインジケータを送信するステップと、
を有する。
【００２１】
また、本発明の一形態に係る移動局は、
物理下りリンク共有チャネルと、当該物理下りリンク共有チャネルを受信するために必要な割り当て情報を通知する物理下りリンク制御チャネルとを異なるサブフレームで受信する移動局であって、
物理上りリンク制御チャネルのリソースを決定するためのインジケータを受信する受信部と、
物理下りリンク共有チャネルに対する再送判定を行う判定部と、
受信したインジケータに従って決定された物理上りリンク制御チャネルのリソースを用いて、再送判定の結果を示す送達確認情報を物理上りリンク制御チャネルで送信する送信部と、
を有する。
【００２２】
また、本発明の一形態に係る再送制御方法は、
物理下りリンク共有チャネルと、当該物理下りリンク共有チャネルを受信するために必要な割り当て情報を通知する物理下りリンク制御チャネルとを異なるサブフレームで受信する移動局における再送制御方法であって、
物理上りリンク制御チャネルのリソースを決定するためのインジケータを受信するステップと、
物理下りリンク共有チャネルに対する再送判定を行うステップと、
受信したインジケータに従って決定された物理上りリンク制御チャネルのリソースを用いて、再送判定の結果を示す送達確認情報を物理上りリンク制御チャネルで送信するステップと、
を有する。
【発明の効果】
【００２３】
本発明によれば、ＰＤＳＣＨと当該ＰＤＳＣＨを受信するために必要な割り当て情報を通知するＰＤＣＣＨとが異なるサブフレームで送信される場合、端末間でのＰＵＣＣＨの衝突を回避又は低減することが可能になる。
【図面の簡単な説明】
【００２４】
【図１】カバレッジ拡張モードにおけるＰＤＣＣＨとＰＤＳＣＨとの関係を示す図
【図２】ＭＴＣ端末のＰＵＣＣＨの繰り返し送信によるＰＵＣＣＨの衝突を示す図（その１）
【図３】ＭＴＣ端末のＰＵＣＣＨの繰り返し送信によるＰＵＣＣＨの衝突を示す図（その２）
【図４】ＰＵＣＣＨの衝突確率を示す図
【図５】本発明の実施例の第１の手法に従ってＰＵＣＣＨの衝突を回避する様子を示す図（その１）
【図６】本発明の実施例の第１の手法に従ってＰＵＣＣＨの衝突を回避する様子を示す図（その２）
【図７Ａ】本発明の実施例に係る基地局の構成図
【図７Ｂ】本発明の実施例に係る基地局におけるベースバンド信号処理部の構成図
【図８Ａ】本発明の実施例に係る移動局の構成図
【図８Ｂ】本発明の実施例に係る移動局におけるベースバンド信号処理部の構成図
【図９】本発明の実施例の第１の手法による基地局における送信方法のフローチャート
【図１０】本発明の実施例の第２の手法に従ってＰＵＣＣＨの衝突を低減する様子を示す図（その１）
【図１１】本発明の実施例の第２の手法に従ってＰＵＣＣＨの衝突を低減する様子を示す図（その２）
【図１２】本発明の実施例の第２の手法による移動局における再送制御方法のフローチャート
【図１３】本発明の実施例の第３の手法に従ってＰＵＣＣＨの衝突を回避する様子を示す図（その１）
【図１４】本発明の実施例の第３の手法に従ってＰＵＣＣＨの衝突を回避する様子を示す図（その２）
【図１５】本発明の実施例の第３の手法による基地局における送信方法のフローチャート
【図１６】本発明の実施例の第３の手法による移動局における再送制御方法のフローチャート
【図１７】本発明の実施例によるＰＵＣＣＨの衝突確率及びＰＤＣＣＨの送信制限確率を示す図
【発明を実施するための形態】
【００２５】
以下、本発明の実施例について図面を参照して説明する。
【００２６】
本発明の実施例では、ＭＴＣ端末のように、ＰＤＣＣＨ及びＰＤＳＣＨを異なるサブフレームで受信する端末が存在する場合、端末間でのＰＵＣＣＨの衝突を回避するための手法について説明する。端末は、移動局又はユーザ装置（ＵＥ：User  Equipment）とも呼ばれる。以下の説明では、ＰＵＣＣＨ及びＰＤＳＣＨを異なるサブフレームで受信する端末をＭＴＣ端末と呼び、ＰＵＣＣＨ及びＰＤＳＣＨを同一のサブフレームで受信する端末をＬＴＥ端末と呼ぶ。
【００２７】
なお、ＬＴＥ−Ａｄｖａｎｃｅｄシステムでは、ＰＤＣＣＨを拡張した（Ｅ）ＰＤＣＣＨ（enhanced Physical Downlink Control Channel）が用いられることがあるが、以下の説明では、ＰＤＣＣＨと（Ｅ）ＰＤＣＣＨとを併せてＰＤＣＣＨと呼ぶこととする。また、以下の説明では、主としてカバレッジ拡張モードのＭＴＣ端末を例示するが、本発明はこれに限定されず、ローコストモードにも適用可能である。すなわち、カバレッジ拡張モードの繰り返し回数が１回であるケースがローコストモードに相当することは容易に理解されるであろう。
【００２８】
まず、端末間でのＰＵＣＣＨの衝突が生じる場合について詳細に説明する。
【００２９】
図２は、ＭＴＣ端末のＰＵＣＣＨの繰り返し送信によるＰＵＣＣＨの衝突を示す図である。上記のように、ＭＴＣ端末のカバレッジを拡張するために、カバレッジ拡張モードのＭＴＣ端末に対して、ＰＤＣＣＨ及びＰＤＳＣＨが繰り返し送信される。
【００３０】
ＬＴＥシステム及びＬＴＥ−Ａｄｖａｎｃｅｄシステムでは、再送技術としてＨＡＲＱ（Hybrid ARQ）が使用される。送達確認情報（ＡＣＫ／ＮＡＣＫ）を含むＨＡＲＱフィードバックは、ＰＵＣＣＨで送信される。ＰＤＳＣＨの繰り返し送信に対応して、ＰＵＣＣＨも繰り返し送信される。なお、ＰＤＣＣＨ、ＰＤＳＣＨ、ＰＵＣＣＨのいずれかのみが繰り返し送信される場合もある。ＰＵＣＣＨは、ＰＤＳＣＨの繰り返し送信が終了した後の一定の時間後（例えば4ms後）に送信される。
【００３１】
図２において、ＭＴＣ端末０のＰＵＣＣＨのリソースは、nPUCCH0=nCCEi+NPUCCHにより求まる。nCCEiはＰＵＣＣＨに対応するＰＤＣＣＨの最初のＣＣＥインデックスであり、ＭＴＣ端末０に対しては、数フレーム前のＰＤＣＣＨの繰り返し送信において使用されたＣＣＥインデックスnCCEiが使用される。
【００３２】
一方、通常のＬＴＥ端末も同じカバレッジ内に存在し、ＭＴＣ端末と同じ基地局（ｅＮＢ：enhanced Node B）と通信する。ＬＴＥ端末は、同一フレームで送信されたＰＤＣＣＨ及びＰＤＳＣＨを受信して一定の時間（例えば4ms）後にＰＵＣＣＨを送信する。ＬＴＥ端末１のＰＵＣＣＨのリソースは、nPUCCH1=nCCEi+NPUCCHにより求まる。nCCEiはＰＵＣＣＨに対応するＰＤＣＣＨの最初のＣＣＥインデックスであり、ＬＴＥ端末１に対しては、例えばＦＤＤ（Frequency Division Duplex）では4ms前のサブフレームのＰＤＣＣＨにおいて使用されたＣＣＥインデックスnCCEiが使用される。図２に示すように、ＭＴＣ端末０のnCCEiとＬＴＥ端末１のnCCEiは同じになる可能性があり、この場合、ＰＵＣＣＨの衝突が生じる。同様に、ＭＴＣ端末０によるＰＵＣＣＨの繰り返し送信の間に、ＬＴＥ端末２との間でＰＵＣＣＨの衝突が生じる可能性がある。
【００３３】
図３は、ＭＴＣ端末のＰＵＣＣＨの繰り返し送信によるＰＵＣＣＨの衝突を示す図である。図３では、ＭＴＣ端末同士がＰＵＣＣＨを繰り返し送信した場合のＰＵＣＣＨの衝突の様子を示している。特に、カバレッジ拡張モードのＭＴＣ端末は、ＰＵＣＣＨを送信する回数が増えるため、ＰＵＣＣＨの衝突の可能性は図２の場合に比べて高くなる。
【００３４】
図２及び図３では、ＭＴＣ端末によるＰＵＣＣＨの繰り返し送信によるＰＵＣＣＨが衝突する様子を示しているが、このようなＰＵＣＣＨの衝突は、ＰＵＣＣＨが繰り返し送信される場合に生じるだけでなく、ＰＤＣＣＨとＰＤＳＣＨの送信タイミングが異なるユーザが混在することによっても生じる。
【００３５】
図４に、ＰＵＣＣＨの衝突確率を示す。図４は、同じカバレッジ内に１６個の端末が存在し、ＰＤＣＣＨ、ＰＤＳＣＨ及びＰＵＣＣＨが同じ繰り返し回数（１０回）を用いて送信される場合のシミュレーション結果を示している。ＭＴＣ端末の数が増えるほど、ＰＵＣＣＨの衝突確率は高くなる。
【００３６】
このようなＰＵＣＣＨの衝突を回避又は低減するため、本発明の実施例では、以下の３つの手法を用いる。３つの手法のうちいずれかを組み合わせて適用してもよい。
【００３７】
（１）第１の手法
第１の手法では、ＰＵＣＣＨの衝突を回避するため、基地局において、ＰＵＣＣＨの衝突が生じないように、ＰＤＣＣＨのリソースを割り当てる。上記のように、ＰＵＣＣＨのリソースは、ＰＤＣＣＨのリソース割り当て位置（nCCEi）及び上位レイヤのシグナリングにより設定されるＰＵＣＣＨリソースのスタートインデックス（NPUCCH）により求められる。ＰＤＣＣＨのリソース割り当て位置（nCCEi）に基づく調整では、基地局は、過去のＰＤＣＣＨのリソース割り当て情報を考慮して、ＨＡＲＱフィードバックを送信するサブフレームが同一となるＰＤＣＣＨ間で同じnCCEが用いられないように、ＰＤＣＣＨのリソースを割り当てる。あるいは、予約されたＰＵＣＣＨのリソース割り当て情報を考慮して、同一サブフレーム内で異なる端末用のＰＵＣＣＨに対して同一のリソースを重複して割り当てないようＰＤＣＣＨのリソースを割り当てる。また、上位レイヤのシグナリングにより設定されるＰＵＣＣＨリソースのスタートインデックス（NPUCCH）に基づく調整では、基地局は、ＭＴＣ端末に固有のNPUCCHを設定し、同一サブフレーム内で異なる端末用のＰＵＣＣＨに対して同一のリソースを重複して割り当てないようＰＤＣＣＨのリソースを割り当てる。
【００３８】
（２）第２の手法
第２の手法では、ＰＵＣＣＨの衝突を低減するため、ＭＴＣ端末は、ＰＤＳＣＨに対する再送判定を行い、再送が必要ない場合、ＰＵＣＣＨではＡＣＫを送信せず、再送が必要な場合、ＮＡＣＫを送信する。すなわち、送達確認情報（ＡＣＫ／ＮＡＣＫ）のうちＮＡＣＫのみを送信する。受信環境のよいＭＴＣ端末は、ＰＵＣＣＨを送信しないため、ＰＵＣＣＨの衝突が低減される。
【００３９】
（３）第３の手法
第３の手法では、ＰＵＣＣＨの衝突を回避するため、基地局は、ＭＴＣ端末に使用させるＰＵＣＣＨのリソースを明示的又は非明示的に通知する。一実施例では、基地局は、ＰＵＣＣＨのリソースの複数の候補を端末に予めシグナリングする。基地局は、予めシグナリングしたＰＵＣＣＨのリソースの候補の中でＭＴＣ端末に使用させるＰＵＣＣＨのリソースを決定し、これを明示的に通知するため、ＰＵＣＣＨのリソースを決定するためのインジケータ（ＡＲＩ：ACK Indicator field）をＭＴＣ端末に送信する。ＭＴＣ端末は、ＰＵＣＣＨのリソースを決定するためのインジケータを受信し、受信したインジケータに従ってＰＵＣＣＨを送信する。また、基地局は、上述した式（１）にオフセットを追加し、当該オフセットを通知するという非明示的な通知によって、ＭＴＣ端末に使用させるＰＵＣＣＨのリソースをＭＴＣ端末に通知してもよい。
【００４０】
それぞれの手法について、以下に詳細に説明する。
【００４１】
＜第１の手法＞
図５に、本発明の実施例の第１の手法に従ってＰＵＣＣＨの衝突を回避する様子を示す。基地局は、基地局と通信する端末に対してＰＤＣＣＨ及びＰＤＳＣＨのリソースを割り当てるため、基地局は、どのリソースにＰＤＣＣＨを割り当てたか（ＰＤＣＣＨのリソース割り当て情報）を認識しており、その結果、どのリソースでＰＵＣＣＨを受信するか（ＰＵＣＣＨのリソース割り当て情報）も認識している。
【００４２】
従って、ＭＴＣ端末が異なるサブフレームによりＰＤＳＣＨとＰＤＣＣＨとを受信する場合、基地局は、ＰＤＣＣＨのリソース割り当て情報又はＰＵＣＣＨのリソース割り当て情報を用いて、ＰＵＣＣＨの衝突が生じないようにＰＤＣＣＨのリソースを割り当てる。例えば、ＭＴＣ端末に対して複数サブフレームにＰＤＣＣＨ及びＰＤＳＣＨを割り当てており、複数のサブフレームでＰＵＣＣＨを受信することになっているものとする。このときにＬＴＥ端末が通信する場合、ＬＴＥ端末には、ＭＴＣ端末が送信するＰＵＣＣＨとは異なるリソースでＰＵＣＣＨを送信するように、ＰＤＣＣＨのリソースを割り当てる。
【００４３】
例えば、図５において、ＭＴＣ端末が複数のサブフレームでnPUCCH0=nCCEi+NPUCCHにより示されるリソースを用いてＰＵＣＣＨを送信する場合、ＭＴＣ端末がＰＵＣＣＨを送信するサブフレームで同じnCCEiが用いられないように、ＬＴＥ端末１には、異なるnCCEjで示されるＰＤＣＣＨのリソースを割り当て、ＬＴＥ端末２には、異なるnCCEkで示されるＰＤＣＣＨのリソースを割り当てる。
【００４４】
図６は、複数のＭＴＣ端末が通信する場合のＰＵＣＣＨの衝突を回避する様子を示す。この場合も、図５で説明したのと同様に、基地局は、ＰＤＣＣＨのリソース割り当て情報又はＰＵＣＣＨのリソース割り当て情報を用いて、ＰＵＣＣＨの衝突が生じないようにＰＤＣＣＨのリソースを割り当てる。
【００４５】
例えば、図６において、ＭＴＣ端末０が複数のサブフレームでnPUCCH0=nCCEi+NPUCCHにより示されるリソースを用いてＰＵＣＣＨを送信する場合、ＭＴＣ端末がＰＵＣＣＨを送信するサブフレームで同じnCCEiが用いられないように、ＭＴＣ端末１には、異なるnCCEjを用いてnPUCCH1=nCCEj+NPUCCHで示されるＰＤＣＣＨのリソースを割り当て、ＬＴＥ端末２には、異なるnCCEkを用いてnPUCCH2=nCCEk+NPUCCH示されるＰＤＣＣＨのリソースを割り当てる。
【００４６】
また、ＭＴＣ端末が複数のサブフレームでnPUCCH0=nCCEi+NPUCCHにより示されるリソースを用いてＰＵＣＣＨを送信する場合、ＭＴＣ端末がＰＵＣＣＨを送信するサブフレームで同じNPUCCHが用いられないように、ＬＴＥ端末には、異なるNPUCCHで示されるＰＤＣＣＨのリソースを割り当てる。当該NPUCCHは、ＭＴＣ端末に固有の値に設定されてもよい。また、ＭＴＣ端末間のＰＵＣＣＨの衝突については、例えば、モード種別に固有の値（NPUCCHlowcostMCE, NPUCCHenhancedcoverageMCE）がNPUCCHに設定されてもよい。  図７Ａは、本発明の実施例に係る基地局（ｅＮＢ）１０の構成図である。基地局１０は、伝送路インタフェース１０１と、ベースバンド信号処理部１０３と、呼処理部１０５と、送受信部１０７と、アンプ部１０９とを有する。
【００４７】
下りリンクにより基地局１０から移動局に送信されるデータは、上位局装置から伝送路インターフェース１０１を介してベースバンド信号処理部１０３に入力される。
【００４８】
ベースバンド信号処理部１０３は、ＰＤＣＰ（Packet Data Convergence Protocol）レイヤの処理、データの分割・結合、ＲＬＣ（Radio Link Control）再送制御の送信処理などのＲＬＣレイヤの送信処理、ＭＡＣ（Medium Access Control）再送制御、例えば、ＨＡＲＱ（Hybrid Automatic Repeat reQuest）の送信処理、スケジューリング、伝送フォーマット選択、チャネル符号化、逆高速フーリエ変換（ＩＦＦＴ：Inverse Fast Fourier Transform）処理、プリコーディング処理が行われる。また、下りリンク制御チャネルである物理下りリンク制御チャネルの信号に関しても、チャネル符号化や逆高速フーリエ変換等の送信処理が行われる。
【００４９】
呼処理部１０５は、通信チャネルの設定や解放等の呼処理や、基地局１０の状態管理や、無線リソースの管理を行う。
【００５０】
送受信部１０７は、ベースバンド信号処理部１０３から出力されたベースバンド信号を無線周波数帯に周波数変換する。アンプ部１０９は周波数変換された送信信号を増幅して送受信アンテナへ出力する。なお、複数の送受信アンテナが用いられる場合、複数の送受信部１０７及びアンプ部１０９が存在してもよい。
【００５１】
一方、上りリンクにより移動局から基地局１０に送信される信号については、送受信アンテナで受信された無線周波数信号がアンプ部１０９で増幅され、送受信部１０７で周波数変換されてベースバンド信号に変換され、ベースバンド信号処理部１０３に入力される。
【００５２】
ベースバンド信号処理部１０３は、上りリンクで受信したベースバンド信号に含まれるデータに対して、ＦＦＴ処理、ＩＤＦＴ処理、誤り訂正復号、ＭＡＣ再送制御の受信処理、ＲＬＣレイヤ、ＰＤＣＰレイヤの受信処理を行う。復号された信号は伝送路インターフェース１０１を介して上位局装置に転送される。
【００５３】
図７Ｂは、本発明の実施例に係る基地局１０におけるベースバンド信号処理部１０３の構成図である。ベースバンド信号処理部１０３は、制御部１０３１と、下りリンク（ＤＬ）信号生成部１０３２と、マッピング部１０３３と、スケジューリング部１０３４と、下りリンク制御リソース決定部１０３５と、上りリンク制御リソース決定部１０３６と、リソース割り当て情報記憶部１０３７と、上りリンク（ＵＬ）信号復号部１０３８と、判定部１０３９とを有する。
【００５４】
制御部１０３１は、ベースバンド信号処理部１０３の全体の管理を行う。下りリンクにより移動局に送信する信号については、伝送路インタフェース１０１から入力されたデータをＤＬ信号生成部１０３２に入力する。上りリンクにより移動局から受信した信号については、ＵＬ信号復号部１０３８で復号されたデータを伝送路インタフェース１０１に入力する。また、制御部１０３１は、ＨＡＲＱ等の再送処理を行う。
【００５５】
ＤＬ信号生成部１０３２は、移動局に送信する信号を生成する。移動局に送信する信号には、データ及び制御情報が含まれ、データは主にＰＤＳＣＨで送信され、ＰＤＳＣＨを受信するために必要な割り当て情報は、ＰＤＣＣＨで送信される。
【００５６】
マッピング部１０３３は、ＰＤＳＣＨで送信するデータ及びＰＤＣＣＨで送信する制御情報をスケジューリング部１０３４及び下りリンク制御リソース決定部１０３５で決定されたリソースに配置する。
【００５７】
スケジューリング部１０３４は、ＰＤＳＣＨで移動局に送信するデータのスケジューリングを行う。例えば、スケジューリング部１０３４は、送達確認情報、チャネル推定値及びチャネル品質等を考慮しながら、ＰＤＳＣＨにて送信するデータをスケジューリングする。
【００５８】
下りリンク制御リソース決定部１０３５は、ＰＤＣＣＨに対するリソースを割り当てる。ＰＤＣＣＨに割り当て可能なリソースは予め決められており、下りリンク制御リソース決定部１０３５は、予め決められたリソースの中からＰＤＣＣＨのリソースを割り当てる。
【００５９】
上りリンク制御リソース決定部１０３６は、ＰＵＣＣＨに対するリソースを割り当てる。前述のように、ＰＵＣＣＨのリソースは、以下の式（１）により求められる。
【００６０】
nPUCCH=nCCE+NPUCCH      （１）
リソース割り当て情報記憶部１０３７は、各種のチャネルのリソース割り当て情報を格納する。具体的には、リソース割り当て情報記憶部１０５は、スケジューリング部１０３４でスケジューリングされたＰＤＳＣＨのリソース割り当て情報を記憶すると共に、下りリンク制御リソース決定部１０３５で決定されたＰＤＣＣＨのリソース割り当て情報を記憶する。また、リソース割り当て情報記憶部１０３７は、上りリンク制御リソース決定部１０３６で決定されたＰＵＣＣＨのリソース割り当て情報も記憶する。
【００６１】
ＵＬ信号復号部１０３８は、上りリンクにより移動局から受信した信号を復号する。ＰＵＳＣＨ（Physical Uplink Shared Channel）で受信したデータは、伝送路インタフェース１０１に提供するために制御部１０３１に入力し、ＰＵＣＣＨで受信した送達確認情報（ＡＣＫ／ＮＡＣＫ）も、ＨＡＲＱ等の再送処理のために制御部１０３１に入力する。
【００６２】
判定部１０３９は、ＰＵＳＣＨで受信した信号の再送判定を行う。ＰＵＳＣＨの受信に成功した場合、再送の必要がないことを示す送達確認情報（ＡＣＫ）を生成し、ＰＵＳＣＨの受信に失敗した場合、再送の必要があることを示す送達確認情報（ＮＡＣＫ）を生成する。
【００６３】
本発明の実施例の第１の手法における基地局１０の各機能部の動作については、以下に図９を参照して説明する。
【００６４】
図８Ａは、本発明の実施例に係る移動局（ＭＴＣ端末及びＬＴＥ端末）２０の構成図である。移動局２０は、アプリケーション部２０１と、ベースバンド信号処理部２０３と、送受信部２０５と、アンプ部２０７とを有する。
【００６５】
下りリンクのデータについては、送受信アンテナで受信された無線周波数信号がアンプ部２０７で増幅され、送受信部２０５で周波数変換されてベースバンド信号に変換される。このベースバンド信号は、ベースバンド信号処理部２０３でＦＦＴ処理や、誤り訂正復号、再送制御の受信処理等がなされる。この下りリンクのデータのうち、下りリンクのデータは、アプリケーション部２０１に転送される。アプリケーション部２０１は、物理レイヤやＭＡＣレイヤより上位のレイヤに関する処理等を行う。
【００６６】
一方、上りリンクのデータは、アプリケーション部２０１からベースバンド信号処理部２０３に入力される。ベースバンド信号処理部２０３においては、再送制御の送信処理や、チャネル符号化、ＤＦＴ処理、ＩＦＦＴ処理を行う。送受信部２０５は、ベースバンド信号処理部２０３から出力されたベースバンド信号を無線周波数帯に変換する。その後、アンプ部２０７で増幅されて送受信アンテナより送信される。
【００６７】
図８Ｂは、本発明の実施例に係る移動局２０におけるベースバンド信号処理部２０３の構成図である。ベースバンド信号処理部２０３は、制御部２０３１と、上りリンク（ＵＬ）信号生成部２０３２と、マッピング部２０３３と、下りリンク（ＤＬ）信号生成部２３４と、判定部２０３５とを有する。
【００６８】
制御部２０３１は、ベースバンド信号処理部２０３の全体の管理を行う。上りリンクにより基地局に送信する信号については、アプリケーション部２０１から入力されたデータをＵＬ信号生成部２０３２に入力する。下りリンクにより基地局から受信した信号については、ＤＬ信号復号部２０３４で受信処理されたデータをアプリケーション部２０１に入力する。また、制御部２０３１は、ＨＡＲＱ等の再送処理を行う。
【００６９】
ＵＬ信号生成部２０３２は、基地局に送信する信号を生成する。基地局に送信する信号には、データ及び制御情報が含まれ、データは主にＰＵＳＣＨで送信される。また、基地局からＰＤＳＣＨで受信したデータの送達確認情報（ＡＣＫ／ＮＡＣＫ）はＰＵＣＣＨで送信される。
【００７０】
マッピング部２０３３は、ＰＵＳＣＨで送信するデータを基地局のスケジューリング部１０３４で決定されたリソースに配置する。また、送達確認情報（ＡＣＫ／ＮＡＣＫ）が配置されるＰＵＣＣＨのリソースは、前述のように、対応するＰＤＣＣＨのリソースから以下の式（１）により求められる。
【００７１】
nPUCCH=nCCE+NPUCCH      （１）
ＤＬ信号復号部２０３４は、下りリンクにより基地局から受信した信号を復号し、ＰＤＳＣＨで受信したデータは、アプリケーション部２０１に提供するために制御部２０３１に入力する。
【００７２】
判定部２０３５は、ＰＤＳＣＨで受信した信号の再送判定を行う。ＰＤＳＣＨの受信に成功した場合、再送の必要がないことを示す送達確認情報（ＡＣＫ）を生成し、ＰＵＳＣＨの受信に失敗した場合、再送の必要があることを示す送達確認情報（ＮＡＣＫ）を生成する。
【００７３】
なお、本発明の実施例の第１の手法では、基地局においてＰＵＣＣＨの衝突が生じないようにＰＤＣＣＨのリソースを割り当てる、すなわち、ＰＵＣＣＨの衝突が生じないように式（１）のnCCE及びNPUCCHを設定するため、移動局２０の各機能部には、上記の動作以外に特別な動作は必要ない。
【００７４】
図９は、本発明の実施例の第１の手法による基地局１０における送信方法のフローチャートである。
【００７５】
リソース割り当て情報記憶部１０３７は、ＰＤＣＣＨのリソース割り当て情報又はＰＵＣＣＨのリソース割り当て情報を格納している。ＰＤＣＣＨのリソース割り当て情報は、上記の式（１）のnCCEでもよく、他のＰＤＣＣＨのリソース割り当て位置を示す値でもよい。また、ＰＵＣＣＨのリソース割り当て情報は、上記の式（１）のnPUCCH及び／又はNPUCCHでもよく、他のＰＵＣＣＨのリソース割り当て位置を示す値でもよい。
【００７６】
下りリンク制御リソース決定部１０３５は、リソース割り当て情報記憶部１０３７からＰＤＣＣＨ又はＰＵＣＣＨのリソース割り当て情報を取得する（ステップＳ１０１）。例えば、あるサブフレームにおいて移動局にデータを送信する場合、そのサブフレームに対応するＰＵＣＣＨでＭＴＣ端末がＰＵＣＣＨを送信するか否かを確認し、ＭＴＣ端末がＰＵＣＣＨを送信する場合、ＭＴＣ端末のＰＵＣＣＨのリソース割り当て情報を取得する。
【００７７】
下りリンク制御リソース決定部１０３５は、取得されたリソース割り当て情報を参照して、ＰＵＣＣＨの衝突が生じないようにＰＤＣＣＨのリソースを割り当てる（ステップＳ１０３）。例えば、あるサブフレームに対応するＰＵＣＣＨでＭＴＣ端末がＰＵＣＣＨを送信する場合、ＰＵＣＣＨのリソース割り当て位置が重複しないように、ＰＤＣＣＨのリソースを割り当てる。
【００７８】
ＰＤＣＣＨ及びＰＵＳＣＨは、マッピング部１０３３においてリソースブロックにマッピングされて移動局に送信される（ステップＳ１０５）。
【００７９】
このようにすることで、端末間でのＰＵＣＣＨの衝突が回避できる。
【００８０】
＜第２の手法＞
図１０に、本発明の実施例の第２の手法に従ってＰＵＣＣＨの衝突を低減する様子を示す。ＬＴＥ端末及びＭＴＣ端末は、受信品質を向上させるために再送技術を使用する。ＬＴＥシステム及びＬＴＥ−Ａｄｖａｎｃｅｄシステムでは、再送技術としてＨＡＲＱが使用される。ＨＡＲＱでは、再送判定の結果を示す送達確認情報として、ＡＣＫとＮＡＣＫとが規定されているが、第２の手法では、ＬＴＥ端末は、ＰＤＳＣＨの再送判定の結果を示す送達確認情報（ＡＣＫ／ＮＡＣＫ）を送信する。一方、ＭＴＣ端末は、送達確認情報（ＡＣＫ／ＮＡＣＫ）のうちＮＡＣＫのみを送信する。
【００８１】
図１０において、カバレッジ拡張モードのＭＴＣ端末０は、受信環境のよい位置に在圏するものとする。この場合、ＭＴＣ端末０はＰＤＳＣＨの繰り返し送信の受信に成功するため、ＰＵＣＣＨ（ＡＣＫ）を送信しない。
【００８２】
ＭＴＣ端末０はＰＵＣＣＨを送信しないため、ＬＴＥ端末１がnPUCCH1=nCCEi+NPUCCHにより示されるリソースを用いてＰＵＣＣＨを送信するときにＰＵＣＣＨの衝突は生じない。同様に、ＬＴＥ端末２がnPUCCH2=nCCEi+NPUCCHにより示されるリソースを用いてＰＵＣＣＨを送信するときにＰＵＣＣＨの衝突は生じない。ただし、ＭＴＣ端末０の受信環境が悪く、ＭＴＣ端末０がＮＡＣＫを送信する可能性がある場合、ＰＵＣＣＨの衝突を完全に回避することはできない。
【００８３】
図１１は、複数のＭＴＣ端末が通信する場合のＰＵＣＣＨの衝突を低減する様子を示す。この場合も、図１０で説明したのと同様に、ＭＴＣ端末は、送達確認情報（ＡＣＫ／ＮＡＣＫ）のうちＮＡＣＫのみを送信する。例えば、図１１において、ＭＴＣ端末０及びＭＴＣ端末２が受信環境のよい位置に在圏し、ＭＴＣ端末１が受信環境の悪い位置い在圏するものとする。この場合、カバレッジ拡張モードのＭＴＣ端末０及びＭＴＣ端末２は、ＰＵＣＣＨを送信しないため、ＭＴＣ端末１がnPUCCH1=nCCEi+NPUCCHにより示されるリソースを用いてＰＵＣＣＨを送信するときにＰＵＣＣＨの衝突は生じない。
【００８４】
本発明の実施例の第２の手法における基地局１０及び移動局２０は、図７Ａ、図７Ｂ、図８Ａ及び図８Ｂと同様に構成される。本発明の実施例の第２の手法における基地局１０及び移動局２０の各機能部の動作については、以下に図１２を参照して説明する。
【００８５】
図１２は、本発明の実施例の第２の手法による移動局２０における再送制御方法のフローチャートである。
【００８６】
ＤＬ信号復号部２０３４は、ＰＤＣＣＨで通知された制御情報を復号し、割り当て情報を取得する。また、ＤＬ信号復号部２０３４は、ＰＤＣＣＨで通知された割り当て情報に基づいて、ＰＤＳＣＨで送信されたデータを復号する。（ステップＳ２０１）。
【００８７】
判定部２０３５は、ＰＤＳＣＨに対して再送が必要であるか否かを判定する（ステップＳ２０３）。ＰＤＳＣＨの受信に失敗した場合、再送の必要があることを示す送達確認情報（ＮＡＣＫ）を生成する。
【００８８】
再送の必要がある場合、再送の必要があることを示す送達確認情報（ＮＡＣＫ）は、チャネル符号化、変調等の処理を施され、以下の式（１）により求められるリソースを用いてＰＵＣＣＨで送信される（ステップＳ２０５）。
【００８９】
nPUCCH=nCCE+NPUCCH      （１）
なお、ＰＤＳＣＨの受信に成功した場合、ＰＵＣＣＨでは再送の必要がないことを示す送達確認情報（ＡＣＫ）は送信されない（ステップＳ２０７）ため、判定部２０３５は、送達確認情報（ＡＣＫ）を生成せずに処理を終了してもよい。本発明の実施例の第２の手法では、移動局２０においてＡＣＫを送信しないため、基地局１０は、移動局が再送プロセスにおいて応答なしの状態（ＤＴＸ）であるか、受信が成功した状態（ＡＣＫ）であるかを把握することができない。従って、基地局１０において、移動局の再送を制御する制御部１０３１は、ＰＵＣＣＨの応答がない場合、移動局２０がＰＤＳＣＨの受信に成功したものとみなす（ＡＣＫとみなす）。
【００９０】
なお、ＭＴＣ端末は、ＰＵＣＣＨを送信するサブフレームにおいてＰＵＳＣＨがスケジューリングされており、ＵＣＩ（Uplink Control Information）がＰＵＳＣＨにより送信される場合は再送の必要がないことを示す送達確認情報（ＡＣＫ）を送信すると仮定してもよいし、ＰＵＣＣＨと共通の動作として再送の必要があることを示す送達確認情報（ＮＡＣＫ）のみ送信するとしてもよい。
【００９１】
このようにすることで、端末間でのＰＵＣＣＨの衝突が低減できる。
【００９２】
＜第３の手法＞
図１３に、本発明の実施例の第３の手法に従ってＰＵＣＣＨの衝突を回避する様子を示す。
【００９３】
基地局は、端末に使用させるＰＵＣＣＨのリソース又はＰＵＣＣＨのリソースの複数の候補を端末に予め上位レイヤのシグナリング（例えばＲＲＣ（Radio Resource Control）シグナリング）により通知する。基地局は、基地局と通信する端末に対してＰＤＣＣＨ及びＰＤＳＣＨのリソースを割り当てるため、基地局は、どのリソースにＰＤＣＣＨを割り当てたか（ＰＤＣＣＨのリソース割り当て情報）を認識しており、その結果、どのリソースでＰＵＣＣＨを受信するか（ＰＵＣＣＨのリソース割り当て情報）も認識している。
【００９４】
ＭＴＣ端末が通信することによりＰＵＣＣＨの衝突が生じる可能性がある場合、基地局は、ＰＤＣＣＨ及びＰＵＣＣＨのリソース割り当て情報に基づき、ＭＴＣ端末に使用させるＰＵＣＣＨのリソースをＭＴＣ端末に通知する。当該通知は、ＲＲＣシグナリングにより送信され、各ＭＴＣ端末に対して具体的なＰＵＣＣＨのリソースを通知してもよい。あるいは、ＤＣＩ（Downlink Control Information）内のあるフィールドによって、具体的なＰＵＣＣＨのリソースを通知してもよい。当該フィールドは新たに定義されてもよいし、既存のフィールドを利用してもよい。当該通知を受信すると、ＭＴＣ端末は、通知されたリソースを使用してＰＵＣＣＨを送信する。
【００９５】
あるいは、基地局は、予めシグナリングしたＰＵＣＣＨのリソースの候補の中でＭＴＣ端末に使用させるＰＵＣＣＨのリソースを決定し、ＰＵＣＣＨのリソースを決定するためのインジケータ（ＡＲＩ）をＭＴＣ端末に送信する。ＭＴＣ端末に送信されるＡＲＩは、予めシグナリングにより通知されたＰＵＣＣＨのリソースの候補の中でどれを用いるかを示す。  例えば、４パターンのＰＵＣＣＨのリソースの候補が存在する場合、４パターンのうちどれを用いるかは２ビットの情報量で定義することができる。２ビットの情報量は、既存の仕様で定義されているＤＣＩ（Downlink Control Information）の中のＡＲＩ（ACK Indicator field）を使用してＭＴＣ端末に通知されてもよい。ＭＴＣ端末はあらかじめどのＤＣＩによりＡＲＩが通知されるかを知っているものとする。例えば、ＡＲＩは割り当て情報（DL assignment）を送信するＤＣＩの一部を使用してＭＴＣ端末に通知されてもよい。
【００９６】
ＭＴＣ端末は、ＰＵＣＣＨのリソースを決定するためのインジケータを受信し、受信したインジケータに従ってＰＵＣＣＨを送信する。
【００９７】
例えば、図１３において、カバレッジ拡張モードのＭＴＣ端末０が複数のサブフレームでＰＵＣＣＨを送信する場合、基地局は、ＰＵＣＣＨの衝突が生じないように、ＰＵＣＣＨのための具体的なリソースを通知するか、あるいは、予めシグナリングにより通知されたＰＵＣＣＨのリソースの候補の中でどれを用いるかを示すＡＲＩをＭＴＣ端末０に通知する。ＭＴＣ端末０は、式（１）により求められたＰＵＣＣＨのリソースではなく、通知された具体的なリソースを使用してＰＵＣＣＨを送信するか、あるいは、ＡＲＩにより通知された情報を用いて、ＰＵＣＣＨのリソースを判定し、ＰＵＣＣＨを送信する。
【００９８】
図１４は、複数のＭＴＣ端末が通信する場合のＰＵＣＣＨの衝突を回避する様子を示す。この場合も、図１３で説明したのと同様に、基地局は、ＰＵＣＣＨの衝突が生じないように、ＰＤＣＣＨ及びＰＵＣＣＨのリソース割り当て情報に基づき決定されたＰＵＣＣＨのリソースをＭＴＣ端末に通知するか、あるいは、予めシグナリングにより通知されたＰＵＣＣＨのリソースの候補の中でどれを用いるかを示すＡＲＩをＭＴＣ端末に通知する。このため、複数のＭＴＣ端末が同時に通信する場合であっても、ＰＵＣＣＨの衝突が回避できる。
【００９９】
本発明の実施例の第３の手法における基地局１０及び移動局２０は、図７Ａ、図７Ｂ、図８Ａ及び図８Ｂと同様に構成される。本発明の実施例の第３の手法における基地局１０及び移動局２０の各機能部の動作については、以下に図１５及び図１６を参照して説明する。
【０１００】
図１５は、本発明の実施例の第３の手法による基地局１０における送信方法のフローチャートである。  基地局１０は、ＰＵＣＣＨのリソースの複数の候補を端末に予め上位レイヤのシグナリングにより通知する（ステップＳ３０１）。
【０１０１】
リソース割り当て情報記憶部１０３７は、ＰＤＣＣＨのリソース割り当て情報又はＰＵＣＣＨのリソース割り当て情報を格納している。ＰＤＣＣＨのリソース割り当て情報は、上記の式（１）のnCCEでもよく、他のＰＤＣＣＨのリソース割り当て位置を示す値でもよい。また、ＰＵＣＣＨのリソース割り当て情報は、上記の式（１）のnPUCCHでもよく、他のＰＵＣＣＨのリソース割り当て位置を示す値でもよい。
【０１０２】
下りリンク制御リソース決定部１０３５は、リソース割り当て情報記憶部１０３７からＰＤＣＣＨ又はＰＵＣＣＨのリソース割り当て情報を取得する（ステップＳ３０３）。例えば、複数のサブフレームにおいてＭＴＣ端末にデータを送信する場合、複数のサブフレームにそれぞれ対応するＰＵＣＣＨで他の端末がＰＵＣＣＨを送信するか否かを確認し、他の端末がＰＵＣＣＨを送信する場合、ＰＵＣＣＨのリソース割り当て情報を取得する。
【０１０３】
下りリンク制御リソース決定部１０３５は、取得されたリソース割り当て情報を参照して、ＭＴＣ端末へのＰＤＣＣＨの割り当てに伴い、ＰＵＣＣＨの衝突が生じ得るか否かを確認する。下りリンク制御リソース決定部１０３５は、ＰＵＣＣＨの衝突が生じないように、ＭＴＣ端末のＰＵＣＣＨのリソースを決定する（ステップＳ３０７）。決定されたＰＵＣＣＨのリソースをＭＴＣ端末に通知するか、あるいは、ＰＵＣＣＨのリソースを決定するためのインジケータは、ＤＬ信号生成部１０３２において制御情報として生成され、ＰＤＣＣＨでＭＴＣ端末に送信される（ステップＳ３０９）。上記のように、ＰＵＣＣＨのリソースを決定するためのインジケータは、予め上位レイヤのシグナリングにより通知されたＰＵＣＣＨのリソースの候補のうちどれを用いるかを示す値である。
【０１０４】
図１６は、本発明の実施例の第３の手法による移動局２０における再送制御方法のフローチャートである。
【０１０５】
移動局２０は、ＰＵＣＣＨのリソースの複数の候補を予め上位レイヤのシグナリングにより受信しているものとする。ＤＬ信号復号部２０３４は、このＰＵＣＣＨのリソースの候補の中でＰＵＣＣＨのリソースを決定するためのインジケータを受信して復号するか、使用すべきＰＵＣＣＨのリソースを基地局から通知される（ステップＳ４０１）。
【０１０６】
また、ＤＬ信号復号部２０３４は、基地局からＰＤＳＣＨで送信されたデータを受信する（ステップＳ４０３）。
【０１０７】
なお、ステップＳ４０１及びステップＳ４０３の順序に関して特に制限はなく、ステップＳ４０１の後にステップＳ４０３が実行されてもよく、ステップＳ４０３の前にステップＳ４０３が実行されてもよく、ステップＳ４０１とステップＳ４０３とが同時に（同一のサブフレームで）実行されてもよい。
【０１０８】
判定部２０３５は、ＰＤＳＣＨに対して再送が必要であるか否かを判定する（ステップＳ４０５）。ＰＤＳＣＨの受信に失敗した場合、再送の必要があることを示す送達確認情報（ＮＡＣＫ）を生成する。ＰＤＳＣＨの受信に成功した場合、再送の必要がないことを示す送達確認情報（ＡＣＫ）を生成する。
【０１０９】
送達確認情報（ＡＣＫ／ＮＡＣＫ）は、マッピング部２０３３で通知されたＰＵＣＣＨのリソースを割り当てられるか、あるいは、受信したインジケータに従ってマッピング部２０３３でＰＵＣＣＨのリソースを割り当てられ、ＰＵＣＣＨで送信される（ステップＳ４０７）。
【０１１０】
このようにすることで、端末間でのＰＵＣＣＨの衝突が回避できる。
【０１１１】
なお、上記の説明では、ＡＲＩにより、予め上位レイヤのシグナリングにより通知されたＰＵＣＣＨのリソースの候補のうちどれを用いるかを移動局に明示的に通知しているが、基地局は、後述する何れかの通知方法によりＰＵＣＣＨのリソースをずらすためのオフセット値を通知してもよい（非明示的な通知）。この場合、ＰＵＣＣＨのリソースを示す式（１）は以下の式（２）のように表されてもよい。
【０１１２】
nPUCCH=nCCE+NPUCCH＋Δoffset      （２）
ＰＵＣＣＨのリソースをずらすためのΔoffsetは、ＭＣＴ端末に使用させるＰＵＣＣＨのリソースに対応する値となるよう基地局により決定される。当該オフセット値Δoffsetは、i) 固定値、ii) ＲＲＣにより通知された値、iii) ＤＣＩ、又はiv) ＰＤＳＣＨサブフレームのＰＣＦＩＣＨ（Physical Control Format Indicator Channel）の値により設定されてもよい。
【０１１３】
すなわち、Δoffsetの値は、固定値に設定されてもよく、例えば、ＣＣＥの最大数などに設定されてもよい。また、Δoffsetの値は、基地局からＲＲＣにより通知されてもよい。また、Δoffsetの値は、基地局からＤＣＩ内のフィールド（ＡＲＩなど）により通知されてもよい。この場合、通知される当該フィールドのビット値とΔoffsetとの関係性は別途シグナリングするか、あるいはあらかじめユーザ端末に組み込んまれている。当該フィールドは新たに定義されてもよいし、既存のフィールドを利用してもよい。さらに、Δoffsetの値は、ＰＤＳＣＨのサブフレームにおけるＰＣＦＩＣＨの値に基づき設定されてもよい。ＰＣＦＩＣＨは、当該サブフレームにおいて占有されるＰＤＣＣＨのシンボル数を示すものである。Δoffsetの値は、当該ＰＣＦＩＣＨの値に基づき導出されるＰＤＳＣＨのサブフレームにおけるＣＦＩ（Control Format Indicator）の個数に基づき設定されてもよい。
【０１１４】
移動局は、式（２）により求められたリソースを用いてＰＵＣＣＨを送信する。なお、オフセット値が用いられる場合、ＰＵＣＣＨのリソースの複数の候補を予め端末に通知する必要はない。
【０１１５】
また、ＰＵＣＣＨのリソースを決定するためのインジケータは、ＤＣＩの中のＡＲＩではなく、他の情報項目を使用してもよい。例えば、既存または新たなＤＣＩの中に新たなビットを定義してもよい。新たなビットを定義することで、ＰＵＣＣＨの候補の数が自由に定義可能となる。
【０１１６】
その他に、２ビットのＴＰＣ（Transmit Power Control）フィールドを、ＰＵＣＣＨのリソースを決定するためのインジケータとして利用してもよい。この場合、カバレッジ拡張モードのＭＴＣ端末は、ＴＰＣコマンドに基づいた送信電力制御ができなくなるため、このユーザ端末は最大の送信電力で送信すると仮定してもよいし、ＴＰＣコマンドによる補正値を0 dBと解釈し、開ループ型制御の送信電力制御と組み合わせて送信電力を決定してもよい。
【０１１７】
また、２ビットのＲＶ（Redundancy Version）フィールドを、ＰＵＣＣＨのリソースを決定するためのインジケータとして利用してもよい。ＲＶビットは、再送時の冗長ビットのパターンを決めるために使用される。この場合、カバレッジ拡張モードのＭＴＣ端末は、常に同じＲＶのパターンが用いられると仮定してもよく、予め決められた順序で（例えば、ＲＶ０→ＲＶ１→ＲＶ２→ＲＶ３）ＲＶのパターンが切り替えられると仮定してもよい。
【０１１８】
また、再送のプロセス番号を示すＨＰＮ（HARQ Process Number）フィールドの一部を、ＰＵＣＣＨのリソースを決定するためのインジケータとして利用してもよい。この場合、ＨＰＮフィールドのうち何ビットをインジケータとして用いるかにより、再送の最大プロセス番号が制限される。
【０１１９】
更に、上記のＴＰＣフィールド、ＲＶフィールド、ＨＰＮフィールドを組み合わせて、ＰＵＣＣＨのリソースを決定するためのインジケータに利用してもよい。
【０１２０】
＜本発明の実施例の効果＞
上記のように、本発明の実施例によれば、ＰＤＳＣＨと当該ＰＤＳＣＨを受信するために必要な割り当て情報を通知するＰＤＣＣＨとが異なるサブフレームで送信される場合、端末間でのＰＵＣＣＨの衝突を回避又は低減することが可能になる。
【０１２１】
第１の手法によれば、基地局において衝突が生じないようにＰＤＳＣＨのリソースを割り当てるため、完全にＰＵＣＣＨの衝突を回避することができる。また、基地局におけるリソースの割り当てで実現でき、端末には影響を及ぼさない。
【０１２２】
一方、ＰＤＣＣＨのリソースの割り当てが複雑になり、ＰＤＣＣＨが送信できない確率が増加する。
【０１２３】
第２の手法によれば、移動局においてＰＵＣＣＨによりＡＣＫを送信しないようにするため、基地局でのＰＤＣＣＨのリソースの割り当てに影響を及ぼさない。また、ＰＤＣＣＨが送信できない確率の増加を防ぐことができる。
【０１２４】
一方、完全にはＰＵＣＣＨの衝突を回避することはできず、また、基地局においてＤＴＸとＡＣＫとの判定を行うこともできない。
【０１２５】
第３の手法によれば、既存のＬＴＥ端末に対する基地局でのＰＤＣＣＨのリソースの割り当てに影響を及ぼさない。また、ＰＤＣＣＨが送信できない確率の増加を防ぐこともできる。更に、ＰＵＣＣＨの衝突も回避できる。
【０１２６】
図１７に、本発明の実施例によるＰＵＣＣＨの衝突確率及びＰＤＣＣＨの送信制限確率（ＰＤＣＣＨが送信できない確率）を示す。
【０１２７】
図１７のシミュレーション結果は、図４と同じ条件で求められている。図４で説明したように、従来の手法によれば、ＭＴＣ端末の数が増えるほど、ＰＵＣＣＨの衝突確率は高くなる。一方、本発明の実施例の第１の手法及び第３の手法によれば、ＰＵＣＣＨの衝突確率はＭＴＣ端末が増えても０となる。本発明の第２の手法によれば、完全にＰＵＣＣＨの衝突確率を０にすることはできないが、従来の手法に比べてＰＵＣＣＨの衝突確率を低減できる。
【０１２８】
また、従来の手法では、ＭＴＣ端末の数が増えるほど、ＰＤＣＣＨの送信制限確率は高くなる。一方、本発明の実施例の第１の手法によれば、従来の手法に比べてＰＤＣＣＨの送信制限確率は約１０％高くなる。本発明の第２の手法及び第３の手法によれば、ＰＤＣＣＨの送信制限確率の増加を防ぐことができ、実質的に従来の手法と同程度となる。
【０１２９】
説明の便宜上、本発明の実施例に係る基地局及び移動局は機能的なブロック図を用いて説明しているが、本発明の実施例に係る基地局及び移動局は、ハードウェア、ソフトウェアまたはそれらの組み合わせで実現されてもよい。また、各機能部が必要に応じて組み合わせて使用されてもよい。また、本発明の実施例に係る方法は、実施例に示す順序と異なる順序で実施されてもよい。
【０１３０】
以上、ＰＤＳＣＨと当該ＰＤＳＣＨを受信するために必要な割り当て情報を通知するＰＤＣＣＨとが異なるサブフレームで送信される場合、端末間でのＰＵＣＣＨの衝突を回避又は低減するための手法について説明したが、本発明は、上記の実施例に限定されることなく、特許請求の範囲内において、種々の変更・応用が可能である。
【符号の説明】
【０１３１】
１０      基地局
１０１    伝送路インタフェース
１０３    ベースバンド信号処理部
１０５    呼処理部
１０７    送受信部
１０９    アンプ部
１０３１  制御部
１０３２  ＤＬ信号生成部
１０３３  マッピング部
１０３４  スケジューリング部
１０３５  下りリンク制御リソース決定部
１０３６  上りリンク制御リソース決定部
１０３７  リソース割り当て情報記憶部
１０３８  ＵＬ信号復号部
１０３９  判定部
２０      移動局
２０１    アプリケーション部
２０３    ベースバンド信号処理部
２０５    送受信部
２０７    アンプ部
２０３１  制御部
２０３２  ＵＬ信号生成部
２０３３  マッピング部
２０３４  ＤＬ信号復号部
２０３５  判定部
【図１】
2015164279.tif 000003
【図２】
2015164279.tif 000004
【図３】
2015164279.tif 000005
【図４】
2015164279.tif 000006
【図５】
2015164279.tif 000007
【図６】
2015164279.tif 000008
【図７Ａ】
2015164279.tif 000009
【図７Ｂ】
2015164279.tif 000010
【図８Ａ】
2015164279.tif 000011
【図８Ｂ】
2015164279.tif 000012
【図９】
2015164279.tif 000013
【図１０】
2015164279.tif 000014
【図１１】
2015164279.tif 000015
【図１２】
2015164279.tif 000016
【図１３】
2015164279.tif 000017
【図１４】
2015164279.tif 000018
【図１５】
2015164279.tif 000019
【図１６】
2015164279.tif 000020
【図１７】
2015164279.tif 000021