特許 5931171 信号送受信方法及びそのための装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5931171

(24)【登録日】2016年5月13日

(45)【発行日】2016年6月8日

(54)【発明の名称】信号送受信方法及びそのための装置

(51)【国際特許分類】

   H04W 28/06 20090101AFI20160526BHJP

   H04W 28/04 20090101ALI20160526BHJP

   H04W 72/04 20090101ALI20160526BHJP

   H04W 72/12 20090101ALI20160526BHJP

   H04J 1/00 20060101ALI20160526BHJP

   H04J 11/00 20060101ALI20160526BHJP

   H04L 27/01 20060101ALI20160526BHJP

   H04L 1/16 20060101ALI20160526BHJP

【ＦＩ】

   H04W28/06 110

   H04W28/04 110

   H04W72/04 131

   H04W72/12

   H04J1/00

   H04J11/00 Z

   H04L27/00 K

   H04L1/16

【請求項の数】10

【全頁数】46

(21)【出願番号】特願2014-501018(P2014-501018)

(86)(22)【出願日】2012年3月26日

(65)【公表番号】特表2014-514812(P2014-514812A)

(43)【公表日】2014年6月19日

(86)【国際出願番号】KR2012002184

(87)【国際公開番号】WO2012128599

(87)【国際公開日】20120927

【審査請求日】2015年1月8日

(31)【優先権主張番号】61/466,939

(32)【優先日】2011年3月24日

(33)【優先権主張国】US

(31)【優先権主張番号】61/473,163

(32)【優先日】2011年4月8日

(33)【優先権主張国】US

(31)【優先権主張番号】61/473,162

(32)【優先日】2011年4月8日

(33)【優先権主張国】US

(31)【優先権主張番号】61/554,477

(32)【優先日】2011年11月1日

(33)【優先権主張国】US

(31)【優先権主張番号】61/560,792

(32)【優先日】2011年11月16日

(33)【優先権主張国】US

(31)【優先権主張番号】61/588,662

(32)【優先日】2012年1月20日

(33)【優先権主張国】US

(31)【優先権主張番号】61/596,208

(32)【優先日】2012年2月7日

(33)【優先権主張国】US

(31)【優先権主張番号】61/597,111

(32)【優先日】2012年2月9日

(33)【優先権主張国】US

(31)【優先権主張番号】61/603,888

(32)【優先日】2012年2月27日

(33)【優先権主張国】US

(31)【優先権主張番号】61/603,954

(32)【優先日】2012年2月28日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】502032105

【氏名又は名称】エルジー エレクトロニクス インコーポレイティド

(74)【代理人】

【識別番号】100099759

【弁理士】

【氏名又は名称】青木 篤

(74)【代理人】

【識別番号】100092624

【弁理士】

【氏名又は名称】鶴田 準一

(74)【代理人】

【識別番号】100114018

【弁理士】

【氏名又は名称】南山 知広

(74)【代理人】

【識別番号】100165191

【弁理士】

【氏名又は名称】河合 章

(74)【代理人】

【識別番号】100151459

【弁理士】

【氏名又は名称】中村 健一

(72)【発明者】

【氏名】ヤン スクチェル

(72)【発明者】

【氏名】キム ミンギュ

(72)【発明者】

【氏名】アン ジュンキ

(72)【発明者】

【氏名】ソ ドンヨン

【審査官】 遠山 敬彦

(56)【参考文献】

【文献】 MediaTek Inc，HARQ Feedback Mechanism in CA with Different TDD Configurations， 3GPP TSG-RAN WG1#66 R1-112349，２０１１年 ８月２６日，＜URL:http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_66/Docs/R1-112349.zip＞

【文献】 Qualcomm Incorporated，On ACK/NAK codebook size determination with respect to special subframes in TDD， 3GPP TSG-RAN WG1#64 R1-110913，２０１１年 ２月２５日，＜URL:http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_64/Docs/R1-110913.zip＞

【文献】 Email Rapporteur (CMCC)，Email summary on inter-band TDD CA， 3GPP TSG-RAN WG1#69 R1-122708，＜URL:http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_69/Docs/R1-122708.zip＞，２０１２年 ５月２５日，p.12-29

【文献】 LG Electronics，Overall structure for full-duplex operation based TDD CA with different UL-DL configurations， 3GPP TSG-RAN WG1#68 R1-120420，２０１２年 ２月１０日，＜URL:http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_68/Docs/R1-120420.zip＞

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｂ ７／２４− ７／２６

Ｈ０４Ｊ １／００

Ｈ０４Ｊ １１／００

Ｈ０４Ｌ １／１６

Ｈ０４Ｌ ２７／０１

Ｈ０４Ｗ ４／００−９９／００

３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１−４

ＳＡ ＷＧ１−２

ＣＴ ＷＧ１

(57)【特許請求の範囲】

【請求項1】

搬送波集約をサポートする無線通信システムでアップリンク信号を送信する方法であって、
第１の時分割２重通信（ＴＤＤ）アップリンク−ダウンリンク（ＵＬ−ＤＬ）構成の第１セルと前記第１のＴＤＤ ＵＬ−ＤＬ構成とは異なる第２のＴＤＤ ＵＬ−ＤＬ構成の第２セルとを設定するステップと、
前記第１セルのサブフレーム＃ｎ−ｋ（ｋ∈Ｋ）を通じてデータを受信するステップと、
前記第２セルのサブフレーム＃ｎを通じて前記データに対する受信応答情報を送信するステップと、を有し、
ＴＤＤ ＵＬ−ＤＬ構成は次のように定義され、ここで、Ｄはダウンリンクサブフレームを示し、Ｓは特別サブフレームを示し、Ｕはアップリンクサブフレームを示し、

【表1】

ここで、Ｋ：｛ｋ₀，ｋ₁，...，ｋ_M-1｝はＴＤＤ ＵＬ−ＤＬ構成によって以下の表のように定義され、Ｍは１以上の整数であり、

【表2】

前記第１のＴＤＤ ＵＬ−ＤＬ構成と前記第２のＴＤＤ ＵＬ−ＤＬ構成との組合せが、次の組合せ
−ＴＤＤ ＵＬ−ＤＬ構成＃１とＴＤＤ ＵＬ−ＤＬ構成＃３
−ＴＤＤ ＵＬ−ＤＬ構成＃２とＴＤＤ ＵＬ−ＤＬ構成＃３、及び
−ＴＤＤ ＵＬ−ＤＬ構成＃２とＴＤＤ ＵＬ−ＤＬ構成＃４、
のうちの一つに対応するとき、
前記受信応答情報の送信のために、第３のＴＤＤ ＵＬ−ＤＬ構成のＫ：｛ｋ₀，ｋ₁，...，ｋ_M-1｝を使用し、前記第３のＴＤＤ ＵＬ−ＤＬ構成は、１つ以上のＴＤＤ ＵＬ−ＤＬ構成の中のＤ及びＳサブフレームの最小の数を持つＴＤＤ ＵＬ−ＤＬ構成であり、前記第１又は前記第２ＴＤＤ ＵＬ−ＤＬ構成のいずれにおいてもＤ又はＳとして構成されたサブフレームは全てＤ又はＳとして構成される、方法。

【請求項2】

前記第１のＴＤＤ ＵＬ−ＤＬ構成と前記第２のＴＤＤ ＵＬ−ＤＬ構成との組合せが、次の組合せ
−ＴＤＤ ＵＬ−ＤＬ構成＃１とＴＤＤ ＵＬ−ＤＬ構成＃３
−ＴＤＤ ＵＬ−ＤＬ構成＃２とＴＤＤ ＵＬ−ＤＬ構成＃３、及び
−ＴＤＤ ＵＬ−ＤＬ構成＃２とＴＤＤ ＵＬ−ＤＬ構成＃４、
のうちの一つに対応しないとき、
前記受信応答情報の送信のために、Ｄ及びＳの最大の数を有する前記第１のＴＤＤ ＵＬ−ＤＬ構成又は前記第２のＴＤＤ ＵＬ−ＤＬ構成のうち一つのＫ：｛ｋ₀，ｋ₁，...，ｋ_M-1｝が利用される、請求項１に記載の方法。

【請求項3】

（前記第１のＴＤＤ ＵＬ−ＤＬ構成、前記第２のＴＤＤ ＵＬ−ＤＬ構成）が（＃１、＃３）又は（＃３、＃１）に対応するとき、前記第３のＴＤＤ ＵＬ−ＤＬ構成はＴＤＤ ＵＬ−ＤＬ構成＃４であり、
（前記第１のＴＤＤ ＵＬ−ＤＬ構成、前記第２のＴＤＤ ＵＬ−ＤＬ構成）が（＃２、＃３）、（＃３、＃２）、（＃２、＃４）又は（＃４、＃２）に対応するとき、前記第３のＴＤＤ ＵＬ−ＤＬ構成はＴＤＤ ＵＬ−ＤＬ構成＃５である、請求項１に記載の方法。

【請求項4】

前記第１セルは２次セルであり、前記第２セルは１次セルである、請求項１に記載の方法。

【請求項5】

前記受信応答情報は物理アップリンク制御チャネル（ＰＵＣＣＨ）を介して送信される、請求項１に記載の方法。

【請求項6】

搬送波集約をサポートする無線通信システムでアップリンク信号を送信するように構成された通信装置であって、
無線周波（ＲＦ）ユニットと、
プロセッサと、を備え、
前記プロセッサは、第１の時分割２重通信（ＴＤＤ）アップリンク−ダウンリンク（ＵＬ−ＤＬ）構成の第１セルと前記第１のＴＤＤ ＵＬ−ＤＬ構成とは異なる第２のＴＤＤ ＵＬ−ＤＬ構成の第２セルとを設定し、前記第１セルのサブフレーム＃ｎ−ｋ（ｋ∈Ｋ）を通じてデータを受信し、前記第２セルのサブフレーム＃ｎを通じて前記データに対する受信応答情報を送信するように構成され、
ＴＤＤ ＵＬ−ＤＬ構成は次のように定義され、ここで、Ｄはダウンリンクサブフレームを示し、Ｓは特別サブフレームを示し、Ｕはアップリンクサブフレームを示し、

【表3】

ここで、Ｋ：｛ｋ₀，ｋ₁，...，ｋ_M-1｝はＴＤＤ ＵＬ−ＤＬ構成によって以下の表のように定義され、Ｍは１以上の整数であり、

【表4】

前記第１のＴＤＤ ＵＬ−ＤＬ構成と前記第２のＴＤＤ ＵＬ−ＤＬ構成との組合せが、次の組合せ
−ＴＤＤ ＵＬ−ＤＬ構成＃１とＴＤＤ ＵＬ−ＤＬ構成＃３
−ＴＤＤ ＵＬ−ＤＬ構成＃２とＴＤＤ ＵＬ−ＤＬ構成＃３、及び
−ＴＤＤ ＵＬ−ＤＬ構成＃２とＴＤＤ ＵＬ−ＤＬ構成＃４、
のうちの一つに対応するとき、
前記受信応答情報の送信のために、第３のＴＤＤ ＵＬ−ＤＬ構成のＫ：｛ｋ₀，ｋ₁，...，ｋ_M-1｝を使用し、前記第３のＴＤＤ ＵＬ−ＤＬ構成は、１つ以上のＴＤＤ ＵＬ−ＤＬ構成の中のＤ及びＳサブフレームの最小の数を持つＴＤＤ ＵＬ−ＤＬ構成であり、前記第１又は前記第２ＴＤＤ ＵＬ−ＤＬ構成のいずれにおいてもＤ又はＳとして構成されたサブフレームは全てＤ又はＳとして構成される、通信装置。

【請求項7】

前記第１のＴＤＤ ＵＬ−ＤＬ構成と前記第２のＴＤＤ ＵＬ−ＤＬ構成との組合せが、次の組合せ
−ＴＤＤ ＵＬ−ＤＬ構成＃１とＴＤＤ ＵＬ−ＤＬ構成＃３
−ＴＤＤ ＵＬ−ＤＬ構成＃２とＴＤＤ ＵＬ−ＤＬ構成＃３、及び
−ＴＤＤ ＵＬ−ＤＬ構成＃２とＴＤＤ ＵＬ−ＤＬ構成＃４、
のうちの一つに対応しないとき、
前記受信応答情報の送信のために、
Ｄ及びＳの最大の数を有する前記第１のＴＤＤ ＵＬ−ＤＬ構成又は前記第２のＴＤＤ ＵＬ−ＤＬ構成のうち一つのＫ：｛ｋ₀，ｋ₁，...，ｋ_M-1｝が利用される、請求項６に記載の通信装置。

【請求項8】

（前記第１のＴＤＤ ＵＬ−ＤＬ構成、前記第２のＴＤＤ ＵＬ−ＤＬ構成）が（＃１、＃３）又は（＃３、＃１）に対応するとき、前記第３のＴＤＤ ＵＬ−ＤＬ構成はＴＤＤ ＵＬ−ＤＬ構成＃４であり、
（前記第１のＴＤＤ ＵＬ−ＤＬ構成、前記第２のＴＤＤ ＵＬ−ＤＬ構成）が（＃２、＃３）、（＃３、＃２）、（＃２、＃４）又は（＃４、＃２）に対応するとき、前記第３のＴＤＤ ＵＬ−ＤＬ構成はＴＤＤ ＵＬ−ＤＬ構成＃５である、請求項７に記載の通信装置。

【請求項9】

前記第１セルは２次セルであり、前記第２セルは１次セルである、請求項６に記載の通信装置。

【請求項10】

前記受信応答情報は物理アップリンク制御チャネル（ＰＵＣＣＨ）を介して送信される、請求項６に記載の通信装置。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、無線通信システムに係り、具体的には、時分割２重通信（ＴＤＤ）をサポートする複数搬送波システムにおいて信号を送受信する方法及びそのための装置に関する。

【背景技術】

【0002】

無線通信システムは、音声又はデータ等のような多様な種類の通信サービスを提供するために広範囲に展開されている。一般に、無線通信システムは、利用可能なシステムリソース（帯域幅、送信電力など）を共有して複数ユーザとの通信をサポートすることができる多元接続システムである。多元接続システムの例としては、符号分割多元接続（ＣＤＭＡ）システム、周波数分割多元接続（ＦＤＭＡ）システム、時分割多元接続（ＴＤＭＡ）システム、直交周波数分割多元接続（ＯＦＤＭＡ）システム、単一搬送波周波数分割多元接続（ＳＣ−ＦＤＭＡ）システムなどがある。

【発明の概要】

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

【0003】

本発明の目的は、無線通信システムにおいて信号を効率的に送受信する方法及びそのための装置を提供することにある。本発明の他の目的は、ＴＤＤをサポートする複数搬送波システムにおいて信号を効率的に送受信する方法及びそのための装置を提供することにある。本発明の更に他の目的は、ＴＤＤをサポートする複数搬送波システムにおいて信号送受信タイミングを設定するときに、既存の信号送受信タイミングを再利用する方法及びそのための装置を提供することにある。

【0004】

本発明で達成しようとする技術的課題は、上述した技術的課題に制限されず、言及していない他の技術的課題は、下記の記載から、本発明の属する技術分野における通常の知識を有する者には明確に理解されるであろう。

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

【0005】

本発明の一様相として、搬送波集約（Ｃａｒｒｉｅｒ Ａｇｇｒｅｇａｔｉｏｎ）をサポートする無線通信システムにおいてアップリンク信号を送信する方法において、第１の時分割２重通信（ＴＤＤ）アップリンク−ダウンリンク（ＵＬ−ＤＬ）構成の第１セルと第２のＴＤＤ ＵＬ−ＤＬ構成の第２セルとを設定するステップと、第１セルのＤＬサブフレームを通じてデータを受信するステップと、第２セルのＵＬサブフレームを通じてデータに対する受信応答情報を送信するステップと、を含み、ＤＬサブフレームとＵＬサブフレームとの関係は、ＴＤＤ ＵＬ−ＤＬ構成セット内の特定ＴＤＤ ＵＬ−ＤＬ構成に設定されたパラメータ値によって決定され、特定ＴＤＤ ＵＬ−ＤＬ構成は、第１セル又は第２セルでＤＬに設定されたサブフレームがすべてＤＬに設定された一つ以上のＴＤＤ ＵＬ−ＤＬ構成のうち、ＤＬサブフレームの個数が最も少ないＴＤＤ ＵＬ−ＤＬ構成である方法が提供される。

【0006】

本発明の他の様相として、搬送波集約をサポートする無線通信システムでアップリンク信号を送信するように構成された通信装置において、無線周波（ＲＦ）ユニットと、プロセッサと、を含み、プロセッサは、第１のＴＤＤ ＵＬ−ＤＬ構成の第１セルと第２のＴＤＤ ＵＬ−ＤＬ構成の第２セルとを設定し、第１セルのＤＬサブフレームを通じてデータを受信し、第２セルのＵＬサブフレームを通じてデータに対する受信応答情報を送信するように構成され、ＤＬサブフレームとＵＬサブフレームとの関係は、ＴＤＤ ＵＬ−ＤＬ構成セット内の特定ＴＤＤ ＵＬ−ＤＬ構成に設定されたパラメータ値によって決定され、特定ＴＤＤ ＵＬ−ＤＬ構成は、第１セル又は第２セルでＤＬに設定されたサブフレームがすべてＤＬに設定された一つ以上のＴＤＤ ＵＬ−ＤＬ構成のうち、ＤＬサブフレームの個数が最も少ないＴＤＤ ＵＬ−ＤＬ構成である通信装置が提供される。

【0007】

好ましくは、ＴＤＤ ＵＬ−ＤＬ構成セットは、下記の表に規定された複数のＴＤＤ ＵＬ−ＤＬ構成を含むことができる。

【0008】

【表1】

【0009】

ここで、Ｄはダウンリンクサブフレームを示し、Ｓは特別サブフレームを示し、Ｕはアップリンクサブフレームを示す。

【0010】

好ましくは、ＤＬサブフレームはサブフレーム＃ｎ−ｋ（ｋ∈Ｋ）であり、ＵＬサブフレームはサブフレーム＃ｎであり、Ｋ：｛ｋ₀，ｋ₁，...，ｋ_M-1｝は、ＴＤＤ ＵＬ−ＤＬ構成によって下記の表のように規定され、Ｍは１以上の整数であってもよい。

【0011】

【表2】

【0012】

好ましくは、第１のＴＤＤ ＵＬ−ＤＬ構成と第２のＴＤＤ ＵＬ−ＤＬ構成との組合せは、次の組合せのうち一つであってもよい。

【0013】

−ＴＤＤ ＵＬ−ＤＬ構成＃１とＴＤＤ ＵＬ−ＤＬ構成＃３

【0014】

−ＴＤＤ ＵＬ−ＤＬ構成＃２とＴＤＤ ＵＬ−ＤＬ構成＃３、及び

【0015】

−ＴＤＤ ＵＬ−ＤＬ構成＃２とＴＤＤ ＵＬ−ＤＬ構成＃４。

【0016】

好ましくは、第１セルは２次セルで、第２セルは１次セルであってもよい。

【発明の効果】

【0017】

本発明によれば、無線通信システムにおいて信号を効率的に送受信することができる。また、ＴＤＤをサポートする複数搬送波システムにおいて信号を効率的に送受信することができる。また、ＴＤＤをサポートする複数搬送波システムにおいて信号送受信タイミングを設定するときに、既存の信号送受信タイミングを再利用することができる。

【0018】

本発明で得られる効果は、以上に言及した効果に制限されず、言及していない他の効果は、下記の記載から、本発明の属する技術分野における通常の知識を有する者には明確に理解されるであろう。

【図面の簡単な説明】

【0019】

本発明に関する理解を助けるために詳細な説明の一部として含まれる添付図面は、本発明に係る実施例を提供し、詳細な説明と共に本発明の技術的思想を説明する。

【図1】無線フレームの構造を例示する図である。

【図2】ダウンリンクスロットのリソースグリッドを例示する図である。

【図3】ダウンリンクサブフレームの構造を示す図である。

【図4】アップリンクサブフレームの構造を示す図である。

【図5】単一セルの状況でＴＤＤ ＵＬ ＡＣＫ／ＮＡＣＫ送信タイミングを示す図である。

【図6】単一セルの状況でＴＤＤ ＵＬ ＡＣＫ／ＮＡＣＫ送信タイミングを示す図である。

【図7】単一セルの状況でＴＤＤ ＰＵＳＣＨ送信タイミングを示す図である。

【図8】単一セルの状況でＴＤＤ ＰＵＳＣＨ送信タイミングを示す図である。

【図9】単一セルの状況でＴＤＤ ＤＬ ＡＣＫ／ＮＡＣＫ送信タイミングを示す図である。

【図10】単一セルの状況でＴＤＤ ＤＬ ＡＣＫ／ＮＡＣＫ送信タイミングを示す図である。

【図11】単一セルの状況でＴＤＤ ＨＡＲＱプロセスを示す図である。

【図12】搬送波集約通信システムを例示する図である。

【図13】複数の搬送波が集約された場合のスケジュールを例示する図である。

【図14】実施例１に係るＡＣＫ／ＮＡＣＫタイミング設定及び送信方法を例示する図である。

【図15】実施例１に係るＡＣＫ／ＮＡＣＫタイミング設定及び送信方法を例示する図である。

【図16】実施例１に係るＡＣＫ／ＮＡＣＫタイミング設定及び送信方法を例示する図である。

【図17】実施例１に係るＵＬ許可／ＰＨＩＣＨタイミング設定方法を例示する図である。

【図18】実施例１に係るＵＬ許可／ＰＨＩＣＨタイミング設定方法を例示する図である。

【図19】実施例１，２のＡＣＫ／ＮＡＣＫタイミングが適用されるＣＡ組合せを例示する図である。

【図20】ＵＬ ＨＡＲＱタイミング設定に問題が発生するＣＡ組合せを例示する図である。

【図21】実施例３によってＳＣＣ Ｕに対するＵＧ又はＰＨＩＣＨタイミングを設定する方法を例示する図である。

【図22】実施例３によってＳＣＣ Ｕに対するＵＧ又はＰＨＩＣＨタイミングを設定する方法を例示する図である。

【図23】実施例３によってＳＣＣ Ｕに対するＵＧ又はＰＨＩＣＨタイミングを設定する方法を例示する図である。

【図24】実施例３によってＳＣＣ Ｕに対するＵＧ又はＰＨＩＣＨタイミングを設定する方法を例示する図である。

【図25】実施例３によってＳＣＣ Ｕに対するＵＧ又はＰＨＩＣＨタイミングを設定する方法を例示する図である。

【図26】実施例４によってＳＣＣ Ｕに対するＵＧ又はＰＨＩＣＨタイミングを設定する方法を例示する図である。

【図27】実施例４によってＳＣＣ Ｕに対するＵＧ又はＰＨＩＣＨタイミングを設定する方法を例示する図である。

【図28】実施例４によってＳＣＣ Ｕに対するＵＧ又はＰＨＩＣＨタイミングを設定する方法を例示する図である。

【図29】実施例４によってＳＣＣ Ｕに対するＵＧ又はＰＨＩＣＨタイミングを設定する方法を例示する図である。

【図30】本発明の一実施例に適用可能な基地局及び端末を例示する図である。

【発明を実施するための形態】

【0020】

以下の技術は、ＣＤＭＡ、ＦＤＭＡ、ＴＤＭＡ、ＯＦＤＭＡ、ＳＣ−ＦＤＭＡなどのような様々な無線接続システムに使用することができる。ＣＤＭＡは、はん用地上無線接続（ＵＴＲＡ）又はＣＤＭＡ２０００のような無線技術で具現することができる。ＴＤＭＡは、ＧＳＭ（登録商標）／一般パケット無線サービス（ＧＰＲＳ）／ＧＳＭ（登録商標）進化用強化データ速度（ＥＤＧＥ）のような無線技術で具現することができる。ＯＦＤＭＡは、ＩＥＥＥ ８０２．１１（Ｗｉ−Ｆｉ）、ＩＥＥＥ ８０２．１６（ＷｉＭＡＸ）、ＩＥＥＥ ８０２−２０、進化ＵＴＲＡ（Ｅ−ＵＴＲＡ）などのような無線技術で具現することができる。ＵＴＲＡは、はん用移動体通信システム（ＵＭＴＳ）の一部である。第３世代パートナシッププロジェクト（３ＧＰＰ）長期進化システム（ＬＴＥ）は、Ｅ−ＵＴＲＡを使用する進化ＵＭＴＳ（Ｅ−ＵＭＴＳ）の一部であって、ダウンリンクでＯＦＤＭＡを採用し、アップリンクでＳＣ−ＦＤＭＡを採用する。高度ＬＴＥ（ＬＴＥ−Ａ）は、３ＧＰＰ ＬＴＥの進展したバージョンである。

【0021】

説明を明確にするために、３ＧＰＰ ＬＴＥ／ＬＴＥ−Ａを中心に記述するが、本発明の技術的思想がこれに制限されるものではない。また、以下の説明で使用される特定用語は、本発明の理解を助けるために提供されるものであり、このような特定用語の使用は、本発明の技術的思想を逸脱しない範囲で他の形態に変更可能である。

【0022】

図１は、無線フレームの構造を例示する。

【0023】

図１を参照すると、３ＧＰＰ ＬＴＥ（−Ａ）で用いられる無線フレームは、１０ｍｓ（３０７２００Ｔｓ）の長さを有し、１０個の均等なサイズのサブフレームで構成される。無線フレーム内の１０個のサブフレームにはそれぞれ番号を付与することができる。ここで、Ｔｓはサンプリング時間を示し、Ｔｓ＝１／（２０４８＊１５ｋＨｚ）で表示される。それぞれのサブフレームは、１ｍｓの長さを有し、２個のスロットで構成される。無線フレーム内で２０個のスロットは、０から１９まで順次に番号付けすることができる。それぞれのスロットは、０．５ｍｓの長さを有する。サブフレームを送信するための時間は、送信時間間隔（ＴＴＩ）で規定される。時間リソースは、無線フレーム番号（又は無線フレームインデクスともいう）、サブフレーム番号（又はサブフレーム番号ともいう）と、スロット番号（又はスロットインデクス）などによって区分できる。

【0024】

無線フレームは、２重通信モードに応じて異なるように構成することができる。周波数分割２重通信（ＦＤＤ）モードにおいては、ダウンリンク送信及びアップリンク送信は周波数によって区分されるため、無線フレームは、特定周波数帯域においてダウンリンクサブフレーム又はアップリンクサブフレームのいずれか一つだけを含む。ＴＤＤモードにおいては、ダウンリンク送信及びアップリンク送信は時間によって区分されるため、無線フレームは、特定周波数帯域に対してダウンリンクサブフレーム及びアップリンクサブフレームの両方を含む。

【0025】

特に、図１は、３ＧＰＰ ＬＴＥ（−Ａ）で用いられるＴＤＤ用無線フレーム構造を示す。表１は、ＴＤＤモードにおいて、無線フレーム内のサブフレームのＵＬ−ＤＬ構成（ＵＤ−ｃｆｇ）を例示する。

【0026】

【表3】

【0027】

表１で、Ｄはダウンリンクサブフレームを、Ｕはアップリンクサブフレームを、Ｓは特別サブフレームを示す。特別サブフレームは、ダウンリンクパイロット時間スロット（ＤｗＰＴＳ）、ガード期間（ＧＰ）、アップリンクパイロット時間スロット（ＵｐＰＴＳ）を含む。ＤｗＰＴＳは、ダウンリンク送信用に留保された時間区間であり、ＵｐＰＴＳは、アップリンク送信用に留保された時間区間である。表２は、特別サブフレームの構成を例示する。

【0028】

【表4】

【0029】

図２は、ダウンリンクスロットのリソースグリッドを例示する。

【0030】

図２を参照すると、ダウンリンクスロットは、時間ドメインにおいて複数のＯＦＤＭシンボルを含む。１ダウンリンクスロットは、７（６）個のＯＦＤＭシンボルを含み、リソースブロックは、周波数ドメインにおいて１２個の副搬送波を含むことができる。リソースグリッド上の各要素は、リソース要素（ＲＥ）と呼ばれる。１個のＲＢは、１２×７（６）個のＲＥを含む。ダウンリンクスロットに含まれるＲＢの個数Ｎ_RBは、ダウンリンク送信帯域に依存する。アップリンクスロットの構造は、ダウンリンクスロットの構造と同一であり、ＯＦＤＭシンボルがＳＣ−ＦＤＭＡシンボルに代替される。

【0031】

図３は、ダウンリンクサブフレームの構造を例示する。

【0032】

図３を参照すると、サブフレームの１番目のスロットにおいて前部に位置した最大３（４）個のＯＦＤＭシンボルは、制御チャネルが割り当てられる制御領域に対応する。残りのＯＦＤＭシンボルは、物理ダウンリンク共有チャネル（ＰＤＳＣＨ）が割り当てられるデータ領域に該当する。ＰＤＳＣＨは、伝送ブロック（Ｔｒａｎｓｐｏｒｔ Ｂｌｏｃｋ、ＴＢ）、又はそれに対応する符号語（ＣＷ）を搬送するために使用される。伝送ブロックは、伝送チャネルを介して媒体接続制御（ＭＡＣ）層から物理（ＰＨＹ）層に伝達されたデータブロックを意味する。符号語は、伝送ブロックの符号化されたバージョンに該当する。伝送ブロックと符号語との対応関係は、スワップによって異なってよい。本明細書において、ＰＤＳＣＨ、伝送ブロック、符号語は互いに混用される。ＬＴＥ（−Ａ）で用いられるダウンリンク制御チャネルの例は、物理制御フォーマット指示子チャネル（ＰＣＦＩＣＨ）、物理ダウンリンク制御チャネル（ＰＤＣＣＨ）、物理ハイブリッド自動再送要求（ＨＡＲＱ）指示子チャネル（ＰＨＩＣＨ）などを含む。ＰＣＦＩＣＨは、サブフレームの１番目ＯＦＤＭシンボルで送信され、サブフレーム内において制御チャネルの送信に使われるＯＦＤＭシンボルの個数に関する情報を搬送する。ＰＨＩＣＨは、アップリンク送信に対する応答としてＨＡＲＱ応答（ＨＡＲＱ−ＡＣＫ）信号を搬送する。ＨＡＲＱ−ＡＣＫは、肯定ＡＣＫ（簡単に、ＡＣＫ）、否定ＡＣＫ（ＮＡＣＫ）、不連続送信（ＤＴＸ）、又はＮＡＣＫ／ＤＴＸを含む。ここで、ＨＡＲＱ−ＡＣＫは、ＨＡＲＱ ＡＣＫ／ＮＡＣＫ、ＡＣＫ／ＮＡＣＫと混用される。

【0033】

ＰＤＣＣＨを介して送信される制御情報をダウンリンク制御情報（ＤＣＩ）と呼ぶ。ＤＣＩは、端末又は端末グループのためのリソース割当情報及び他の制御情報を含む。例えば、ＤＣＩは、アップリンク／ダウンリンクスケジュール情報、アップリンク送信（Ｔｘ）電力制御命令などを含む。複数アンテナ技術を構成するための送信モード及びＤＣＩフォーマットの情報コンテンツは、次のとおりである。

【0034】

送信モード（ＴＭ）

【0035】

・送信モード１：Ｔｒａｎｓｍｉｓｓｉｏｎ ｆｒｏｍ ａ ｓｉｎｇｌｅ ｂａｓｅ ｓｔａｔｉｏｎ ａｎｔｅｎｎａ ｐｏｒｔ

【0036】

・送信モード２：Ｔｒａｎｓｍｉｔ ｄｉｖｅｒｓｉｔｙ

【0037】

・送信モード３：Ｏｐｅｎ−ｌｏｏｐ ｓｐａｔｉａｌ Ｍｕｌｔｉｐｌｅｘｉｎｇ

【0038】

・送信モード４：Ｃｌｏｓｅｄ−ｌｏｏｐ ｓｐａｔｉａｌ Ｍｕｌｔｉｐｌｅｘｉｎｇ

【0039】

・送信モード５：Ｍｕｌｔｉ−ｕｓｅｒ ＭＩＭＯ（Ｍｕｌｔｉｐｌｅ Ｉｎｐｕｔ Ｍｕｌｔｉｐｌｅ Ｏｕｔｐｕｔ）

【0040】

・送信モード６：Ｃｌｏｓｅｄ−ｌｏｏｐ ｒａｎｋ−１ ｐｒｅｃｏｄｉｎｇ

【0041】

・送信モード７：Ｔｒａｎｓｍｉｓｓｉｏｎ ｕｓｉｎｇ ＵＥ−ｓｐｅｃｉｆｉｃ ｒｅｆｅｒｅｎｃｅ ｓｉｇｎａｌｓ

【0042】

ＤＣＩフォーマット

【0043】

・フォーマット０：Ｒｅｓｏｕｒｃｅ ｇｒａｎｔｓ ｆｏｒ ｔｈｅ ＰＵＳＣＨ（Ｐｈｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ）ｔｒａｎｓｍｉｓｓｉｏｎｓ（ｕｐｌｉｎｋ）

【0044】

・フォーマット１：Ｒｅｓｏｕｒｃｅ ａｓｓｉｇｎｍｅｎｔｓ ｆｏｒ ｓｉｎｇｌｅ ｃｏｄｅｗｏｒｄ ＰＤＳＣＨ（Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ）ｔｒａｎｓｍｉｓｓｉｏｎｓ（ｔｒａｎｓｍｉｓｓｉｏｎ ｍｏｄｅｓ １、２ ａｎｄ ７）

【0045】

・フォーマット１Ａ：Ｃｏｍｐａｃｔ ｓｉｇｎａｌｉｎｇ ｏｆ ｒｅｓｏｕｒｃｅ ａｓｓｉｇｎｍｅｎｔｓ ｆｏｒ ｓｉｎｇｌｅ ｃｏｄｅｗｏｒｄ ＰＤＳＣＨ（ａｌｌ ｍｏｄｅｓ）

【0046】

・フォーマット１Ｂ：Ｃｏｍｐａｃｔ ｒｅｓｏｕｒｃｅ ａｓｓｉｇｎｍｅｎｔｓ ｆｏｒ ＰＤＳＣＨ ｕｓｉｎｇ ｒａｎｋ−１ ｃｌｏｓｅｄ ｌｏｏｐ ｐｒｅｃｏｄｉｎｇ（ｍｏｄｅ ６）

【0047】

・フォーマット１Ｃ：Ｖｅｒｙ ｃｏｍｐａｃｔｒｅ ｓｏｕｒｃｅ ａｓｓｉｇｎｍｅｎｔｓ ｆｏｒ ＰＤＳＣＨ（ｅ．ｇ．ｐａｇｉｎｇ／ｂｒｏａｄｃａｓｔ ｓｙｓｔｅｍ ｉｎｆｏｒｍａｔｉｏｎ）

【0048】

・フォーマット１Ｄ：Ｃｏｍｐａｃｔ ｒｅｓｏｕｒｃｅ ａｓｓｉｇｎｍｅｎｔｓ ｆｏｒ ＰＤＳＣＨ ｕｓｉｎｇ ｍｕｌｔｉ−ｕｓｅｒ ＭＩＭＯ（ｍｏｄｅ ５）

【0049】

・フォーマット２：Ｒｅｓｏｕｒｃｅ ａｓｓｉｇｎｍｅｎｔｓ ｆｏｒ ＰＤＳＣＨ ｆｏｒ ｃｌｏｓｅｄ−ｌｏｏｐ ＭＩＭＯ ｏｐｅｒａｔｉｏｎ（ｍｏｄｅ ４）

【0050】

・フォーマット２Ａ：Ｒｅｓｏｕｒｃｅ ａｓｓｉｇｎｍｅｎｔｓ ｆｏｒ ＰＤＳＣＨ ｆｏｒ ｏｐｅｎ−ｌｏｏｐ ＭＩＭＯ ｏｐｅｒａｔｉｏｎ（ｍｏｄｅ ３）

【0051】

・フォーマット３／３Ａ：Ｐｏｗｅｒ ｃｏｎｔｒｏｌ ｃｏｍｍａｎｄｓ ｆｏｒ ＰＵＣＣＨ（Ｐｈｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）ａｎｄ ＰＵＳＣＨ ｗｉｔｈ２−ｂｉｔ／１−ｂｉｔ ｐｏｗｅｒ ａｄｊｕｓｔｍｅｎｔｓ

【0052】

上述したように、ＰＤＣＣＨは、ダウンリンク共有チャネル（ＤＬ−ＳＣＨ）の送信フォーマット及びリソース割当情報、アップリンク共有チャネル（ＵＬ−ＳＣＨ）の送信フォーマット及びリソース割当情報、呼出しチャネル（ＰＣＨ）上の呼出し情報、ＤＬ−ＳＣＨ上のシステム情報、ＰＤＳＣＨ上で送信されるランダムアクセス応答のような上位層制御メッセージのリソース割当情報、端末グループ内の個別端末に対するＴｘ電力制御命令セット、Ｔｘ電力制御命令、ＩＰ電話（ＶｏＩＰ）の活性化指示情報などを搬送する。複数のＰＤＣＣＨが制御領域内で送信することができる。端末は、複数のＰＤＣＣＨを監視することができる。ＰＤＣＣＨは、一つ又は複数の連続した制御チャネル要素（ＣＣＥ）の集合（ａｇｇｒｅｇａｔｉｏｎ）上で送信される。ＣＣＥは、ＰＤＣＣＨに、無線チャネル状態に基づく符号化速度を提供するために使用される論理的割当ユニットである。ＣＣＥは、複数のリソース要素グループ（ＲＥＧ）に対応する。ＰＤＣＣＨのフォーマット及びＰＤＣＣＨビットの個数は、ＣＣＥの個数によって決定される。基地局は、端末に送信されるＤＣＩによってＰＤＣＣＨフォーマットを決定し、制御情報に巡回冗長検査ビット（ＣＲＣ）を付加する。ＣＲＣは、ＰＤＣＣＨの所有者又は使用目的によって識別子（例えば、無線ネットワーク一時識別子（ＲＮＴＩ））でマスクされる。例えば、ＰＤＣＣＨが特定端末のためのものである場合、該当の端末の識別子（例えば、セルＲＮＴＩ（Ｃ−ＲＮＴＩ））をＣＲＣにマスクすることができる。ＰＤＣＣＨが呼出しメッセージのためのものである場合、呼出し識別子（例えば、呼出しＲＮＴＩ（Ｐ−ＲＮＴＩ））をＣＲＣにマスクすることができる。ＰＤＣＣＨがシステム情報（より具体的には、システム情報ブロック（ＳＩＣ））のためのものである場合、システム情報ＲＮＴＩ（ＳＩ−ＲＮＴＩ）をＣＲＣにマスクすることができる。ＰＤＣＣＨがランダムアクセス応答のためのものである場合、ランダムアクセスＲＮＴＩ（ＲＡ−ＲＮＴＩ）をＣＲＣにマスクすることができる。

【0053】

図４は、ＬＴＥで用いられるアップリンクサブフレームの構造を例示する。

【0054】

図４を参照すると、アップリンクサブフレームは、複数（例えば、２個）のスロットを含む。スロットは、循環プレフィクス（ＣＰ）長に応じて異なる数のＳＣ−ＦＤＭＡシンボルを含むことができる。アップリンクサブフレームは、周波数領域においてデータ領域と制御領域とに区分される。データ領域は、ＰＵＳＣＨを含み、音声などのデータ信号を送信するために使用される。制御領域は、ＰＵＣＣＨを含み、アップリンク制御情報（ＵＣＩ）を送信するために使用される。ＰＵＣＣＨは、周波数軸においてデータ領域の両端部に位置したＲＢ対（ＲＢ ｐａｉｒ）を含み、スロットを境界にしてホップする。

【0055】

ＰＵＣＣＨは、次の制御情報を送信するために使用することができる。

【0056】

−スケジュール要求（ＳＲ）：アップリンクＵＬ−ＳＣＨリソースを要求するために使用される情報である。オンオフ変調（ＯＯＫ）方式を用いて送信される。

【0057】

−ＨＡＲＱ−ＡＣＫ：ＰＤＳＣＨ上のダウンリンクデータパケット（例えば、符号語）に対した応答である。ダウンリンクデータパケットが成功裏に受信されたか否かを示す。単一ダウンリンク符号語に対する応答として、ＨＡＲＱ−ＡＣＫ １ビットが送信され、二つのダウンリンク符号語に対する応答として、ＨＡＲＱ−ＡＣＫ ２ビットが送信される。ＨＡＲＱ−ＡＣＫは、肯定ＡＣＫ（簡単に、ＡＣＫ）、否定ＡＣＫ（ＮＡＣＫ）、ＤＴＸ又はＮＡＣＫ／ＤＴＸを含む。ここで、ＨＡＲＱ−ＡＣＫは、ＨＡＲＱ ＡＣＫ／ＮＡＣＫ、ＡＣＫ／ＮＡＣＫと混用される。

【0058】

−チャネル状態情報（ＣＳＩ）：ダウンリンクチャネルに関するフィードバック情報である。多入力多出力（ＭＩＭＯ）関連フィードバック情報は、ランク指示子（ＲＩ）及びプリコーディング行列指示子（ＰＭＩ）を含む。サブフレーム当たり２０ビットが使用される。

【0059】

端末がサブフレームで送信することができる制御情報（ＵＣＩ）の量は、制御情報の送信に利用可能なＳＣ−ＦＤＭＡの個数に依存する。制御情報の送信に利用可能なＳＣ−ＦＤＭＡは、サブフレームにおいて参照信号送信のためのＳＣ−ＦＤＭＡシンボルを除いた残りのＳＣ−ＦＤＭＡシンボルを意味し、測定基準信号（ＳＲＳ）が設定されたサブフレームの場合、サブフレームの最後のＳＣ−ＦＤＭＡシンボルも除外される。参照信号は、ＰＵＣＣＨのコヒーレント検出に使用される。ＰＵＣＣＨは、送信される情報に応じて様々なフォーマットをサポートする。

【0060】

表３は、ＬＴＥ(−Ａ)でＰＵＣＣＨフォーマットとＵＣＩとのマップ関係を示す。

【0061】

【表5】

【0062】

以下、図５乃至図１１を参照して、単一搬送波（又はセル）状況でＴＤＤ信号送信タイミングについて説明する。

【0063】

図５及び図６は、ＰＤＳＣＨ−ＵＬ ＡＣＫ／ＮＡＣＫタイミングを示す。ここで、ＵＬ ＡＣＫ／ＮＡＣＫは、ＤＬデータ（例えば、ＰＤＳＣＨ）に対する応答であって、アップリンクで送信されるＡＣＫ／ＮＡＣＫを意味する。

【0064】

図５を参照すると、端末は、Ｍ個のＤＬサブフレーム（Ｓｕｂｆｒａｍｅ、ＳＦ）上で一つ以上のＰＤＳＣＨ信号を受信することができる（Ｓ５０２_０〜Ｓ５０２_Ｍ−１）。それぞれのＰＤＳＣＨ信号は、送信モードに応じて、一つ又は複数（例えば、二つ）の送信ブロック（ＴＢ）を送信するために使用される。また、図示してはいないが、ステップＳ５０２_０〜Ｓ５０２_Ｍ−１で半永続スケジュール解除（ＳＰＳ解除）を指示するＰＤＣＣＨ信号も受信され得る。Ｍ個のＤＬサブフレームにＰＤＳＣＨ信号及び／又はＳＰＳ解除ＰＤＣＣＨ信号が存在すると、端末は、ＡＣＫ／ＮＡＣＫを送信するための過程（例えば、ＡＣＫ／ＮＡＣＫ（ペイロード）生成、ＡＣＫ／ＮＡＣＫリソース割当など）を経て、Ｍ個のＤＬサブフレームに対応する一つのＵＬサブフレームを通じてＡＣＫ／ＮＡＣＫを送信する（Ｓ５０４）。ＡＣＫ／ＮＡＣＫは、ステップＳ５０２_０〜Ｓ５０２_Ｍ−１のＰＤＳＣＨ信号及び／又はＳＰＳ解除ＰＤＣＣＨ信号に関する受信応答情報を含む。ＡＣＫ／ＮＡＣＫは、基本的にＰＵＣＣＨを介して送信されるが、ＡＣＫ／ＮＡＣＫ送信時点にＰＵＳＣＨ送信がある場合、ＡＣＫ／ＮＡＣＫはＰＵＳＣＨを介して送信される。ＡＣＫ／ＮＡＣＫ送信のために、表３の様々なＰＵＣＣＨフォーマットを用いることができる。また、ＰＵＣＣＨフォーマットを通じて送信されるＡＣＫ／ＮＡＣＫビット数を減らすために、ＡＣＫ／ＮＡＣＫバンドル、ＡＣＫ／ＮＡＣＫチャネル選択のような様々な方法を用いることができる。

【0065】

上述したように、ＴＤＤでは、Ｍ個のＤＬサブフレームで受信したデータに対するＡＣＫ／ＮＡＣＫが、一つのＵＬサブフレームを通じて送信され（すなわち、Ｍ ＤＬ ＳＦ（ｓ）：１ ＵＬ ＳＦ）、これらの関係は、ダウンリンクアソシエーションセットインデクス（ＤＡＳＩ）によって与えられる。

【0066】

表４は、ＬＴＥ(−Ａ)に規定されたＤＡＳＩ(Ｋ：｛ｋ₀，ｋ₁，...，ｋ_M-1｝)を示す。表４は、ＡＣＫ／ＮＡＣＫを送信するＵＬサブフレームの立場で、自身と関連するＤＬサブフレームとの間隔を示す。具体的に、サブフレームｎ−ｋ(ｋ∈Ｋ）にＰＤＳＣＨ送信及び／又はＳＰＳ解除を指示するＰＤＣＣＨがある場合、端末は、サブフレームｎでＡＣＫ／ＮＡＣＫを送信する。

【0067】

【表6】

【0068】

図６は、ＵＬ−ＤＬ構成＃１が設定された場合のＵＬ ＡＣＫ／ＮＡＣＫ送信タイミングを例示する。同図で、ＳＦ＃０〜＃９及びＳＦ＃１０〜＃１９は、それぞれ無線フレームに対応する。同図で、ボックス内の数字は、ＤＬサブフレームの観点で、自身と関連するＵＬサブフレームを示す。例えば、ＳＦ＃５のＰＤＳＣＨに対するＡＣＫ／ＮＡＣＫは、ＳＦ＃５＋７(＝ＳＦ＃１２）で送信され、ＳＦ＃６のＰＤＳＣＨに対するＡＣＫ／ＮＡＣＫはＳＦ＃６＋６(＝ＳＦ＃１２）で送信される。したがって、ＳＦ＃５／ＳＦ＃６のダウンリンク信号に対するＡＣＫ／ＮＡＣＫは、すべてＳＦ＃１２で送信される。同様に、ＳＦ＃１４のＰＤＳＣＨに対するＡＣＫ／ＮＡＣＫは、ＳＦ＃１４＋４(＝ＳＦ＃１８)で送信される。

【0069】

図７及び図８は、ＰＨＩＣＨ／ＵＬ許可（ＵＧ）−ＰＵＳＣＨタイミングを示す。ＰＵＳＣＨは、ＰＤＣＣＨ（ＵＬ許可）及び／又はＰＨＩＣＨ（ＮＡＣＫ）に対応して送信することができる。

【0070】

図７を参照すると、端末は、ＰＤＣＣＨ（ＵＬ許可）及び／又はＰＨＩＣＨ（ＮＡＣＫ）を受信することができる（Ｓ７０２）。ここで、ＮＡＣＫは、前のＰＵＳＣＨ送信に対するＡＣＫ／ＮＡＣＫ応答に該当する。この場合、端末は、ＰＵＳＣＨ送信のための過程（例えば、ＴＢ符号化、ＴＢ−ＣＷスワップ、ＰＵＳＣＨリソース割当など）を経て、ｋサブフレームの後にＰＵＳＣＨを介して一つ又は複数の送信ブロック（ＴＢ）を初期／再送信することができる（Ｓ７０４）。本例は、ＰＵＳＣＨが一回送信される普通（ｎｏｒｍａｌ）のＨＡＲＱ動作を仮定する。この場合、ＰＵＳＣＨ送信に対応するＰＨＩＣＨ／ＵＬ許可は、同一のサブフレームに存在する。ただし、ＰＵＳＣＨが、複数のサブフレームを通じて複数回送信されるサブフレームバンドルの場合、ＰＵＳＣＨ送信に対応するＰＨＩＣＨ／ＵＬ許可は、別個のサブフレームに存在することができる。

【0071】

表５は、ＬＴＥ(−Ａ）にＰＵＳＣＨ送信のためのアップリンクアソシエーションインデクス（ＵＡＩ）（ｋ）を示す。表５は、ＰＨＩＣＨ／ＵＬ許可が検出されたＤＬサブフレームの立場で、自身と関連するＵＬサブフレームとの間隔を示す。具体的に、サブフレームｎでＰＨＩＣＨ／ＵＬ許可が検出されると、端末は、サブフレームｎ＋ｋでＰＵＳＣＨを送信することができる。

【0072】

【表7】

【0073】

図８は、ＵＬ−ＤＬ構成＃１が設定された場合のＰＵＳＣＨ送信タイミングを例示する。同図で、ＳＦ＃０〜＃９及びＳＦ＃１０〜＃１９は、それぞれ無線フレームに対応する。同図で、ボックス内の数字は、ＤＬサブフレームの観点で、自身と関連するＵＬサブフレームを示す。例えば、ＳＦ＃６のＰＨＩＣＨ／ＵＬ許可に対するＰＵＳＣＨはＳＦ＃６＋６(＝ＳＦ＃１２)で送信され、ＳＦ＃１４のＰＨＩＣＨ／ＵＬ許可に対するＰＵＳＣＨはＳＦ＃１４＋４(＝ＳＦ＃１８)で送信される。

【0074】

図９及び図１０は、ＰＵＳＣＨ−ＰＨＩＣＨ／ＵＬ許可タイミングを示す。ＰＨＩＣＨは、ＤＬ ＡＣＫ／ＮＡＣＫを送信するために使用される。ここで、ＤＬ ＡＣＫ／ＮＡＣＫは、ＵＬデータ（例えば、ＰＵＳＣＨ）に対する応答であって、ダウンリンクで送信されるＡＣＫ／ＮＡＣＫを意味する。

【0075】

図９を参照すると、端末は、基地局にＰＵＳＣＨ信号を送信する（Ｓ９０２）。ここで、ＰＵＳＣＨ信号は、送信モードに応じて、一つ又は複数（例えば、二つ）の送信ブロック(ＴＢ）を送信するために使用される。ＰＵＳＣＨ送信に対する応答として、基地局は、ＡＣＫ／ＮＡＣＫを送信するための過程（例えば、ＡＣＫ／ＮＡＣＫ生成、ＡＣＫ／ＮＡＣＫリソース割当など）を経て、ｋサブフレームの後にＰＨＩＣＨを介してＡＣＫ／ＮＡＣＫを端末に送信することができる（Ｓ９０４）。ＡＣＫ／ＮＡＣＫは、ステップＳ９０２のＰＵＳＣＨ信号に関する受信応答情報を含む。また、ＰＵＳＣＨ送信に対する応答がＮＡＣＫである場合、基地局は、ｋサブフレームの後にＰＵＳＣＨ再送信のためのＵＬ許可ＰＤＣＣＨを端末に送信することができる（Ｓ９０４）。本例は、ＰＵＳＣＨが一回送信される普通のＨＡＲＱ動作を仮定する。この場合、ＰＵＳＣＨ送信に対応するＰＨＩＣＨ／ＵＬ許可は、同一のサブフレームで送信され得る。ただし、サブフレームバンドルの場合、ＰＵＳＣＨ送信に対応するＰＨＩＣＨ／ＵＬ許可は、互いに異なるサブフレームで送信され得る。

【0076】

表６は、ＬＴＥ(−Ａ)にＰＨＩＣＨ／ＵＬ許可送信のためのＵＡＩ（ｋ）を示す。表６は、ＰＨＩＣＨ／ＵＬ許可が存在するＤＬサブフレームの立場で、自身と関連するＵＬサブフレームとの間隔を示す。具体的に、サブフレームｉのＰＨＩＣＨ／ＵＬ許可は、サブフレームｉ−ｋのＰＵＳＣＨ送信に対応する。

【0077】

【表8】

【0078】

図１０は、ＵＬ−ＤＬ構成＃１が設定された場合のＰＨＩＣＨ／ＵＬ許可送信タイミングを例示する。同図で、ＳＦ＃０〜＃９及びＳＦ＃１０〜＃１９は、それぞれ無線フレームに対応する。同図で、ボックス内の数字は、ＵＬサブフレームの観点で、自身と関連するＤＬサブフレームを示す。例えば、ＳＦ＃２のＰＵＳＣＨに対するＰＨＩＣＨ／ＵＬ許可は、ＳＦ＃２＋４(＝ＳＦ＃６）で送信され、ＳＦ＃８のＰＵＳＣＨに対するＰＨＩＣＨ／ＵＬ許可は、ＳＦ＃８＋６(＝ＳＦ＃１４）で送信される。

【0079】

次に、ＰＨＩＣＨリソース割当について説明する。サブフレーム＃ｎでＰＵＳＣＨ送信があると、端末は、サブフレーム＃（ｎ＋ｋ_PHICH）で、対応するＰＣＨＩＨリソースを決定する。ＦＤＤにおいてｋ_PHICHは、固定された値（例えば、４）を有する。ＴＤＤにおいてｋ_PHICHは、ＵＬ−ＤＬ構成に応じて異なる値を有する。表７は、ＴＤＤのためのｋ_PHICH値を示し、表６と等価である。

【0080】

【表9】

【0081】

ＰＨＩＣＨリソースは、［ＰＨＩＣＨグループインデクス、直交シーケンスインデクス］によって与えられる。ＰＨＩＣＨグループインデクス及び直交シーケンスインデクスは、（ｉ）ＰＵＳＣＨ送信に用いられる最も小さいＰＲＢインデクスと、（ii）復調基準信号（ＤＭＲＳ）の循環シフトのための３ビットフィールドの値を用いて決定される。（ｉ）（ii）は、ＵＬ許可ＰＤＣＣＨによって指示される。

【0082】

次に、ＨＡＲＱプロセスについて説明する。端末には、ＵＬ送信のために、複数の並列ＨＡＲＱプロセスが存在する。複数の並列ＨＡＲＱプロセスは、以前のＵＬ送信に対する成功又は失敗の受信に対するＨＡＲＱフィードバックを待つ間に、ＵＬ送信が連続的に行われるようにする。それぞれのＨＡＲＱプロセスは、ＭＡＣ層のＨＡＲＱバッファと関連する。それぞれのＨＡＲＱプロセスは、バッファ内のＭＡＣ ＰＤＵ（物理データブロック）の送信回数、バッファ内のＭＡＣ ＰＤＵに対するＨＡＲＱフィードバック、現在の冗長バージョンなどに関する状態変数を管理する。

【0083】

ＬＴＥ（−Ａ） ＦＤＤの場合、非サブフレームバンドル動作（すなわち、普通のＨＡＲＱ動作）のためのＵＬ ＨＡＲＱプロセスの個数は８個である。一方、ＬＴＥ（−Ａ） ＴＤＤの場合には、ＵＬ−ＤＬ構成に応じてＵＬサブフレームの個数が異なるため、ＵＬ ＨＡＲＱプロセスの個数及びＨＡＲＱ往復時間（ＲＴＴ）もＵＬ−ＤＬ構成ごとに異なるように設定される。ここで、ＨＡＲＱ ＲＴＴは、ＵＬ許可を受信した時点から（これに対応する）、ＰＵＳＣＨ送信を経て（これに対応する）、ＰＨＩＣＨが受信される時点までの時間間隔（例えば、ＳＦ又はｍｓ単位）、又はＰＵＳＣＨ送信時点から、これに対応する再送信時点までの時間間隔を意味することができる。

【0084】

ＵＬ ＨＡＲＱプロセスの個数が変わる。サブフレームバンドルが適用されると、ＦＤＤ及びＴＤＤにおいて４個の連続するＵＬサブフレームで構成された一束のＰＵＳＣＨ送信がなされる。したがって、サブフレームバンドルが適用される場合のＨＡＲＱ動作／プロセスは、上述した普通のＨＡＲＱ動作／プロセスとは異なる。

【0085】

表８は、ＴＤＤにおいて同期式ＵＬ ＨＡＲＱプロセスの個数及びＨＡＲＱ ＲＴＴを示す。ＵＬ ＨＡＲＱ ＲＴＴが１０［ＳＦｓ又はｍｓ］である場合（ＵＬ−ＤＬ構成＃１、＃２、＃３、＃４、＃５）、一つのＵＬ ＨＡＲＱプロセスは、一つの固定されたＵＬ ＳＦタイミングを使用する。反面、ＵＬ ＨＡＲＱ ＲＴＴが１０［ＳＦｓ又はｍｓ］ではない場合（ＵＬ−ＤＬ構成＃０、＃６）、一つのＵＬ ＨＡＲＱプロセスは（一つの固定されたＵＬ ＳＦタイミングではない）、複数のＵＬ ＳＦタイミングを（ホップしながら）使用する。例えば、ＵＬ−ＤＬ構成＃６の場合、一つのＵＬ ＨＡＲＱプロセスにおいてＰＵＳＣＨ送信タイミングは、次のとおりである：ＳＦ＃２：ＰＵＳＣＨ⇒ＳＦ＃１３：ＰＵＳＣＨ（ＲＴＴ：１１ＳＦｓ）⇒ＳＦ＃２４：ＰＵＳＣＨ（ＲＴＴ：１１ＳＦｓ）⇒ＳＦ＃３７：ＰＵＳＣＨ（ＲＴＴ：１３ＳＦｓ）⇒ＳＦ＃４８：ＰＵＳＣＨ（ＲＴＴ：１１ＳＦｓ）⇒ＳＦ＃５２：ＰＵＳＣＨ（ＲＴＴ：１４ＳＦｓ）。

【0086】

【表10】

【0087】

ＴＤＤ ＵＬ−ＤＬ構成が＃１〜６であり、普通のＨＡＲＱ動作時、ＵＬ許可ＰＤＣＣＨ及び／又はＰＨＩＣＨがサブフレームｎで検出されると、端末は、ＰＤＣＣＨ及び／又はＰＨＩＣＨ情報によって、サブフレームｎ＋ｋ（表５参照）で、対応するＰＵＳＣＨ信号を送信する。

【0088】

ＴＤＤ ＵＬ−ＤＬ構成が＃０であり、普通のＨＡＲＱ動作時、ＵＬ ＤＣＩ許可ＰＤＣＣＨ及び／又はＰＨＩＣＨがサブフレームｎで検出される場合、端末のＰＵＳＣＨ送信タイミングは条件によって変わる。まず、ＤＣＩ内のＵＬインデクスのＭＳＢ（Ｍｏｓｔ Ｓｉｇｎｉｆｉｃａｎｔ Ｂｉｔ）が１であったり、又はＰＨＩＣＨがサブフレーム＃０又は＃５でＩ_PHICH＝０に対応するリソースを通じて受信されたりした場合に、端末は、サブフレームｎ＋ｋ（表５参照）で、対応するＰＵＳＣＨ信号を送信する。次に、ＤＣＩ内のＵＬインデクスの最小ビット（ＬＳＢ）が１であったり、又はＰＨＩＣＨがサブフレーム＃０又は＃５でＩ_PHICH＝１に対応するリソースを通じて受信されたり、又はＰＨＩＣＨがサブフレーム＃１又は＃６で受信されたりした場合に、端末は、サブフレームｎ＋７で、対応するＰＵＳＣＨ信号を送信する。次に、ＤＣＩ内のＭＳＢとＬＳＢがすべてセッティングされた場合、端末は、サブフレームｎ＋ｋ（表５参照）及びサブフレームｎ＋７で、対応するＰＵＳＣＨ信号を送信する。

【0089】

図１１は、ＵＬ−ＤＬ構成＃１が設定された場合の同期式ＵＬ ＨＡＲＱプロセスを例示する。ボックス内の数字はＵＬ ＨＡＲＱプロセス番号を例示する。本例は、普通のＵＬ ＨＡＲＱプロセスを示す。図１１を参照すると、ＨＡＲＱプロセス＃１は、ＳＦ＃２、ＳＦ＃６、ＳＦ＃１２、ＳＦ＃１６に関与する。例えば、初期ＰＵＳＣＨ信号（例えば、ＲＶ＝０）がＳＦ＃２で送信された場合、対応するＵＬ許可ＰＤＣＣＨ及び／又はＰＨＩＣＨはＳＦ＃６で受信され、対応する（再送信）ＰＵＳＣＨ信号（例えば、ＲＶ＝２）がＳＦ＃１２で送信することができる。したがって、ＵＬ−ＤＬ構成＃１の場合、ＲＴＴが１０ＳＦｓ（又は１０ｍｓ）である４個のＵＬ ＨＡＲＱプロセスが存在する。

【0090】

図１２は、搬送波集約（ＣＡ）通信システムを例示する。ＬＴＥ−Ａシステムは、より広い周波数帯域のために複数のアップ／ダウンリンク周波数ブロックを束ねて、より大きいアップ／ダウンリンク帯域幅を使用する搬送波集約（又は帯域幅集約）技術を用いる。各周波数ブロックは、成分搬送波（ＣＣ）を用いて送信される。成分搬送波は、該当の周波数ブロックのための搬送波周波数（又は中心搬送波、中心周波数）と理解してもよい。

【0091】

図１２を参照すると、複数のアップ／ダウンリンク成分搬送波を束ねて、より広いアップ／ダウンリンク帯域幅をサポートすることができる。それぞれのＣＣは、周波数領域において互いに隣接してもよいし、隣接しなくてもよい。各成分搬送波の帯域幅は、独立して定めてもよい。ＵＬ ＣＣの個数とＤＬ ＣＣの個数とが異なる非対称搬送波集約も可能である。例えば、２個のＤＬ ＣＣ、１個のＵＬ ＣＣの場合には、２：１で対応するように構成することができる。ＤＬ ＣＣ／ＵＬ ＣＣリンクは、システムに固定されていてもよく、半静的に構成されてもよい。また、システム全体帯域がＮ個のＣＣで構成されていても、特定端末が監視／受信することができる周波数帯域をＭ（＜Ｎ）個のＣＣに限定し得る。搬送波集約に関する様々なパラメータは、セル特定（ｃｅｌｌ−ｓｐｅｃｉｆｉｃ）、端末グループ特定（ＵＥ ｇｒｏｕｐ−ｓｐｅｃｉｆｉｃ）又は端末特定（ＵＥ−ｓｐｅｃｉｆｉｃ）方式で設定することができる。一方、制御情報は、特定ＣＣを通じてだけ送受信されるように設定することができる。このような特定ＣＣを１次ＣＣ（Ｐｒｉｍａｒｙ ＣＣ、ＰＣＣ）と称し、残りのＣＣを２次ＣＣ（Ｓｅｃｏｎｄａｒｙ ＣＣ、ＳＣＣ）と称することができる。

【0092】

ＬＴＥ−Ａは、無線リソースを管理するためにセルの概念を使用する。セルは、ダウンリンクリソースとアップリンクリソースとの組合せで規定され、アップリンクリソースは必修要素ではない。したがって、セルは、ダウンリンクリソース単独で、又はダウンリンクリソースとアップリンクリソースとで構成してもよい。搬送波集約がサポートされる場合に、ダウンリンクリソースの搬送波周波数（又は、ＤＬ ＣＣ）とアップリンクリソースの搬送波周波数（又は、ＵＬ ＣＣ）との間の結合（ｌｉｎｋａｇｅ）はシステム情報によって指示可能である。１次周波数（又はＰＣＣ）上で動作するセルを１次セル（ＰＣｅｌｌ）と称し、２次周波数（又はＳＣＣ）上で動作するセルを２次セル（ＳＣｅｌｌ）と称することができる。ＰＣｅｌｌは、端末が初期接続設定過程を行ったり、接続再設定過程を行ったりするために使用される。ＰＣｅｌｌは、制御信号が送信されるＵＬ ＣＣとＳＩＢ２リンクされたＤＬ ＣＣ上で動作するセルを意味することがある。また、ＰＣｅｌｌは、ハンドオーバ過程で指示されたセルを意味することもある。ＳＣｅｌｌは、ＲＲＣ接続が設定された後に構成可能であり、追加の無線リソースを提供するために使用することができる。ＰＣｅｌｌ及びＳＣｅｌｌは、サービス提供セルと総称することができる。したがって、ＲＲＣ_ＣＯＮＮＥＣＴＥＤ状態にあるが、搬送波集約が設定されていないか、搬送波集約をサポートしない端末の場合は、ＰＣｅｌｌだけで構成されたサービス提供セルが一つだけ存在する。反面、ＲＲＣ_ＣＯＮＮＥＣＴＥＤ状態にあり、搬送波集約が設定された端末の場合は、一つ以上のサービス提供セルが存在し、全体サービス提供セルにはＰＣｅｌｌ及び全体ＳＣｅｌｌが含まれる。搬送波集約のために、ネットワークは、初期保安活性化（ｉｎｉｔｉａｌ ｓｅｃｕｒｉｔｙ ａｃｔｉｖａｔｉｏｎ）過程が開始された後、接続設定過程で初期に構成されるＰＣｅｌｌに加えて、一つ以上のＳＣｅｌｌを、搬送波集約をサポートする端末のために構成することができる。

【0093】

図１３は、複数の搬送波が集約された場合のスケジュールを例示する。３個のＤＬ ＣＣが集約されたと仮定する。ＤＬ ＣＣ ＡがＰＤＣＣＨ ＣＣに設定されたと仮定する。ＤＬ ＣＣＡ〜Ｃは、サービス提供ＣＣ、サービス提供搬送波、サービス提供セルなどと呼ぶことができる。搬送波指示子フィールド（ＣＩＦ）が無効化されると、それぞれのＤＬ ＣＣは、ＬＴＥ ＰＤＣＣＨ規則に従ってＣＩＦなしに自身のＰＤＳＣＨをスケジュールするＰＤＣＣＨだけを送信することができる（非相互ＣＣスケジュール）。反面、端末特定（又は端末グループ特定、又はセル特定）上位層信号通知によってＣＩＦが有効化されると、特定ＣＣ（例えば、ＤＬ ＣＣ Ａ）は、ＣＩＦを用いて、ＤＬ ＣＣ ＡのＰＤＳＣＨをスケジュールするＰＤＣＣＨだけでなく、他のＣＣのＰＤＳＣＨをスケジュールするＰＤＣＣＨも送信することができる（クロスＣＣスケジュール）。反面、ＤＬ ＣＣ Ｂ／ＣではＰＤＣＣＨが送信されない。

【0094】

ＰＤＣＣＨ送信に使用される特定ＣＣ（又はセル）をスケジュールＣＣ（又はセル）と呼ぶ。スケジュールＣＣ（又はセル）は、監視ＣＣ（ＭＣＣ）（又はセル）と混用することができる。逆に、他のＣＣのＰＤＣＣＨによってＰＤＳＣＨ／ＰＵＳＣＨがスケジュールされるＣＣ（又は、セル）を、被スケジュール（ｓｃｈｅｄｕｌｅｄ）ＣＣ（又はセル）と呼ぶ。一つの端末に一つ以上のスケジュールＣＣを設定することができ、このうち一つのスケジュールＣＣがＤＬ制御信号通知及びＵＬ ＰＵＣＣＨ送信を専担するように設定することができる。すなわち、スケジュールＣＣはＰＣＣを含み、スケジュールＣＣが一つだけ存在する場合、スケジュールＣＣはＰＣＣと等価である。便宜上、以下、スケジュールＣＣ／被スケジュールＣＣは、ＭＣＣ／ＳＣＣと呼ぶことがある。

【0095】

現在、クロスＣＣスケジュールが設定された場合、信号が送信されるＣＣは、信号の種類によって、次のように規定されている。

【0096】

−ＰＤＣＣＨ（ＵＬ／ＤＬ許可）：スケジュールＣＣ（又はＭＣＣ）

【0097】

−ＰＤＳＣＨ／ＰＵＳＣＨ：スケジュールＣＣで検出されたＰＤＣＣＨのＣＩＦが指示するＣＣ

【0098】

-ＤＬ ＡＣＫ／ＮＡＣＫ（例えば、ＰＨＩＣＨ）：スケジュールＣＣ（又はＭＣＣ）（例えば、ＤＬ ＰＣＣ）

【0099】

-ＵＬ ＡＣＫ／ＮＡＣＫ（例えば、ＰＵＣＣＨ）：ＵＬ ＰＣＣ

【0100】

従来のＣＡ ＴＤＤシステムでは、集約されたＣＣがすべて同一のＵＬ−ＤＬ構成を有する場合だけを考慮している。この場合、すべてのＣＣにおいてＤＬ／ＵＬサブフレームタイミングが同一であるので、図５乃至図１０を参照して説明した単一セル状況でのＴＤＤ信号送信タイミングをそのまま活用することができる。しかし、最近、ＣＣ別ＵＬ／ＤＬ負荷の違い及びＣＣ別チャネル状態の違いを考慮して、ＣＣ別にＵＬ−ＤＬ構成を独立して設定する方法が議論中にある。しかし、クロスＣＣスケジュールが適用される状況で、複数のＣＣが互いに異なるＵＬ−ＤＬ構成を有する場合、ＣＣごとに利用可能なＤＬ／ＵＬサブフレームの位置が異なるため、信号送受信において問題が生じ得る。また、そのため、未だ規定されていない新しいＵＬ／ＤＬ ＡＣＫ／ＮＡＣＫタイミング及び／又はＵＬ／ＤＬ許可タイミングなどを規定しなければならないことがある。

【0101】

上述した問題を解決するために、以下、図面を参照して、ＣＡ及びＴＤＤをサポートするシステムにおいて信号送信タイミング（例えば、ＵＬ ＡＣＫ／ＮＡＣＫ送信タイミング、ＵＬ許可送信タイミング、ＤＬ ＡＣＫ／ＮＡＣＫ送信タイミング）の設定方法について提案する。また、信号送信タイミングの設定によるＵＬ ＨＡＲＱプロセスの構成方法について提案する。便宜上、以下、ＵＬ ＡＣＫ／ＮＡＣＫを簡単にＡＣＫ／ＮＡＣＫと呼び、ＵＬ許可をＵＧと呼び、ＤＬ ＡＣＫ／ＮＡＣＫをＰＨＩＣＨと呼ぶことがある。

【0102】

ここで、ＡＣＫ／ＮＡＣＫタイミングは、特定Ｄを通じて受信されたＤＬデータ（例えば、ＰＤＳＣＨ）に対するＡＣＫ／ＮＡＣＫを送信できるように設定されたＵを意味したり、ＤＬデータが受信されたＤとＡＣＫ／ＮＡＣＫが送信されるＵとの間の時間間隔を意味したりすることができる。ＵＧタイミングは、特定Ｕを通じて送信されるＵＬデータ（例えば、ＰＵＳＣＨ）をスケジュールするＵＧが受信され得るように設定されたＤを意味したり、ＵＧが受信されたＤとＵＬデータが送信されるＵとの間の時間間隔を意味したりすることができる。ＰＨＩＣＨタイミングは、特定Ｕを通じて送信されたＵＬデータ（例えば、ＰＵＳＣＨ）に対するＡＣＫ／ＮＡＣＫ（例えば、ＰＨＩＣＨ）を受信できるように設定されたＤを意味したり、ＵＬデータが送信されたＵとＡＣＫ／ＮＡＣＫが受信されるＤとの間の時間間隔を意味したりすることができる。また、特定ＣＣ又は特定ＵＤ−ｃｆｇに設定されたＡＣＫ／ＮＡＣＫタイミングは、例えば、表４のタイミングを意味する。特定ＣＣ又は特定ＵＤ−ｃｆｇに設定されたＵＧタイミングは、例えば、表５のタイミングを意味する。特定ＣＣ又は特定ＵＤ−ｃｆｇに設定されたＰＨＩＣＨタイミングは、例えば、表６〜７のタイミングを意味する。

【0103】

ＡＣＫ／ＮＡＣＫの場合、以下の提案方法を、非クロスＣＣスケジュール及びクロスＣＣにかかわらず適用することができる。反面、ＵＧ又はＰＨＩＣＨの場合、以下の提案方法は、クロスＣＣスケジュールモードが設定された場合、又は実際にクロスＣＣスケジュールが行われる場合に限って適用することができる。例えば、クロスＣＣスケジュールモードが設定されても、スケジュールＣＣが自身だけをスケジュールしている場合（すなわち、非クロスＣＣスケジュール）には、以下の提案方法が適用されないことがある。この場合、スケジュールＣＣに設定された既存のＴＤＤ信号送信タイミングを適用することができる。

【0104】

以下では、発明の理解を助けるために、ＡＣＫ／ＮＡＣＫタイミング設定の場合には、互いに異なるＵＬ−ＤＬ構成を有する１個のＰＣＣと１個のＳＣＣとの搬送波集約を仮定する。また、ＵＧ又はＰＨＩＣＨタイミング設定の場合には、互いに異なるＵＬ−ＤＬ構成を有する１個のＭＣＣと１個のＳＣＣとの搬送波集約を仮定する。しかし、下記の提案方法は、互いに異なるＵＬ−ＤＬ構成を有する複数のＳＣＣのそれぞれを対象として適用可能である。例えば、ＰＣＣ（ＡＣＫ／ＮＡＣＫタイミング設定の場合）又はＭＣＣ（ＵＧ又はＰＨＩＣＨタイミング設定の場合）と異なるＵＬ−ＤＬ構成を有する複数のＳＣＣがある場合、各ＳＣＣ及びＰＣＣ、又は各ＳＣＣ及びＭＣＣに対して個別的に下記の提案方式を適用することができる。

【0105】

以下では、ＤはＤＬ ＳＦ、Ｓは特別ＳＦ、ＵはＵＬ ＳＦを意味する。Ｓは、Ｄ又はＵとして使用され、別に言及しない限りＤとして使用されると仮定する。また、ＳＦ又はｍｓ単位は、送信時間間隔（ＴＴＩ）と総称することができる。また、ＣＣはセル（又はサービス提供セル）と混用し、ＰＣＣはＰＣｅｌｌと混用し、ＳＣＣはＳＣｅｌｌと混用できる。

【0106】

以下の説明で、信号送受信過程は、実施主体が端末である場合を中心に記述する。実施主体が基地局（又はリレー）として与えられる場合には、以下の説明で、信号送受信の方向だけが変わるだけで、同一の内容を適用することができる。

【0107】

実施例１：信号送受信タイミング設定

【0108】

ＡＣＫ／ＮＡＣＫタイミング−方法１−１

【0109】

異なるＵＬ−ＤＬ構成を有するＰＣＣとＳＣＣとが集約された場合、ＡＣＫ／ＮＡＣＫタイミング設定規則を次のように考慮することができる。本方法は、クロスＣＣスケジュール時に、クロスＳＦスケジュール動作を含むことができる。ここで、クロスＳＦスケジュールは、ＤＬ ＳＦ＃ｎで、ＤＬ ＳＦ＃（ｎ＋ｋ）（ｋ＞０）を通じて送信されるＤＬデータをスケジュールすることを意味する。

【0110】

・ＰＣＣを通じて受信されるＤＬデータに対するＡＣＫ／ＮＡＣＫ

【0111】

ＰＣＣのＡＣＫ／ＮＡＣＫタイミングを適用することができる。

【0112】

−複数ＣＣ⇒単一ＣＣへの（又は、逆に）再設定（ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ）のときに、少なくともＰＣＣのＡＣＫ／ＮＡＣＫタイミングに対しては基地局と端末との間の不一致（ｍｉｓａｌｉｇｎｍｅｎｔ）を防止することができる。

【0113】

・ＳＣＣを通じて受信されるＤＬデータに対するＡＣＫ／ＮＡＣＫ

【0114】

まず、全体ＵＬ−ＤＬ構成（例えば、表１）のうち、ＰＣＣ及びＳＣＣがすべてＵであるＳＦ（ｓ）がすべてＵに設定されたＵＬ−ＤＬ構成を選択することができる。次に、該当のＵＬ−ＤＬ構成のうち、Ｕの個数が最も少ない（等価的に、Ｄの個数が最も多い）ＵＬ−ＤＬ構成を選択し、ここに、設定されたＡＣＫ／ＮＡＣＫタイミングを適用することができる。等価的に、全体ＵＬ−ＤＬ構成のうち、ＰＣＣ又はＳＣＣがＤであるＳＦ（ｓ）がすべてＤに設定されたＵＬ−ＤＬ構成を選択することができる。次に、該当のＵＬ−ＤＬ構成のうち、Ｄの個数が最も少ない（等価的に、Ｕの個数が最も多い）ＵＬ−ＤＬ構成（以下、“ＤＬユニオン”）を選択し、ここに、設定されたＡＣＫ／ＮＡＣＫタイミング（以下、“共通のＡＣＫ／ＮＡＣＫタイミング”）を適用することができる。

【0115】

−ＤＬユニオンの場合、ＳＣＣのすべてのＤに対するＡＣＫ／ＮＡＣＫタイミングが、ＰＣＣのＵに設定され得るようにＤ／Ｕが設定されている。

【0116】

−好ましくは、ＤＬユニオンにおいて、ＳＣＣのＤとＳＦタイミングが一致するＤに対するＡＣＫ／ＮＡＣＫタイミングだけを選んで適用することができる。

【0117】

・ＰＣＣ及びＳＣＣを通じて受信されるすべてのＤＬデータに対して共通のＡＣＫ／ＮＡＣＫタイミングを適用することができる。

【0118】

図１４及び図１５は、本実施例に係るＡＣＫ／ＮＡＣＫタイミングの設定方法を例示する。便宜上、ＰＣＣとＭＣＣが同一のＣＣであると仮定し、これらをすべてＰＣＣと表示する。また、ＵＬ−ＤＬ構成をＵＤ−ｃｆｇと表示する。

【0119】

図１４は、ＰＣＣとＳＣＣがそれぞれＵＤ−ｃｆｇ＃３，＃６である場合を示す。この場合、方法１−１を適用すると、次のとおりである。

【0120】

・ＣＣを通じて受信されるＤＬデータに対するＡＣＫ／ＮＡＣＫ

【0121】

ＰＣＣ（すなわち、ＵＤ−ｃｆｇ＃３）のＡＣＫ／ＮＡＣＫタイミングを適用することができる。

【0122】

・ＳＣＣを通じて受信されるＤＬデータに対するＡＣＫ／ＮＡＣＫ

【0123】

ＰＣＣとＳＣＣがすべてＵであるＳＦ（すなわち、ＳＦ＃２、３、４）がすべてＵに設定されているＵＤ−ｃｆｇ（すなわち、ＵＤ−ｃｆｇ＃０、＃３、＃６）のうち、Ｕの個数が最も少ないＵＤ−ｃｆｇ（すなわち、ＵＤ−ｃｆｇ＃３）（＊）に設定されたＡＣＫ／ＮＡＣＫタイミングを適用することができる（図１４（ａ））。等価で、ＰＣＣ又はＳＣＣがＤであるＳＦ（ｓ）（すなわち、ＳＦ＃０、１、５、６、７、８、９）がすべてＤに設定されているＵＤ−ｃｆｇ（すなわち、ＵＤ−ｃｆｇ＃３、＃４、＃５）のうち、Ｄの個数が最も少ないＵＤ−ｃｆｇ（すなわち、ＵＤ−ｃｆｇ＃３）（*）に設定されたＡＣＫ／ＮＡＣＫタイミングを適用することができる（図１４（ｂ））。

【0124】

図１５は、ＰＣＣとＳＣＣがそれぞれＵＤ−ｃｆｇ＃２，＃４である場合を示し、この場合、方法１−１を適用すると、次のとおりである。

【0125】

・ＰＣＣを通じて受信されるＤＬデータに対するＡＣＫ／ＮＡＣＫ

【0126】

ＰＣＣ（すなわち、ＵＤ−ｃｆｇ＃２）のＡＣＫ／ＮＡＣＫタイミングを適用することができる。

【0127】

・ＳＣＣを通じて受信されるＤＬデータに対するＡＣＫ／ＮＡＣＫ

【0128】

ＰＣＣとＳＣＣがすべてＵであるＳＦ（ｓ）（すなわち、ＳＦ＃２）がすべてＵに設定されたＵＤ−ｃｆｇ（すなわち、ＵＤ−ｃｆｇ＃０〜６）のうち、Ｕの個数が最も少ないＵＤ−ｃｆｇ（すなわち、ＵＤ−ｃｆｇ＃５）（＊）に設定されたＡＣＫ／ＮＡＣＫタイミングを適用することができる（図１５（ａ））。等価で、ＰＣＣ又はＳＣＣがＤであるＳＦ（ｓ）（すなわち、ＳＦ＃０、１、３〜９）がすべてＤに設定されているＵＤ−ｃｆｇ（すなわち、ＵＤ−ｃｆｇ＃５）のうち、Ｄの個数が最も少ないＵＤ−ｃｆｇ（すなわち、ＵＤ−ｃｆｇ＃５）（＊）に設定されたＡＣＫ／ＮＡＣＫタイミングを適用することができる（図１５（ｂ））。

【0129】

ＡＣＫ／ＮＡＣＫタイミング−方法１−２

【0130】

互いに異なるＴＤＤ ＵＬ−ＤＬ構成を有する複数のＣＣ（例えば、ＰＣＣ、ＭＣＣ、ＳＣＣ、ＰＣＣ（＝ＭＣＣ）、ＳＣＣ）が集約された場合、クロスＣＣスケジュール時に、追加のクロスＳＦスケジュール動作を導入しないために、次のようなＡＣＫ／ＮＡＣＫタイミング設定規則を考慮することができる。

【0131】

［Ａｌｔ ０］

【0132】

・ＰＣＣを通じて受信されるＤＬデータに対するＡＣＫ／ＮＡＣＫ

【0133】

ＰＣＣのＡＣＫ／ＮＡＣＫタイミングを適用することができる。

【0134】

・ＳＣＣを通じて受信されるＤＬデータに対するＡＣＫ／ＮＡＣＫ

【0135】

非クロスＣＣスケジュール：ＰＣＣとＳＣＣのＤＬユニオン（方法１−１）に設定されたＡＣＫ／ＮＡＣＫタイミングを適用することができる。

【0136】

クロスＣＣスケジュール：ＳＣＣ又は該当のＳＣＣをクロス−ＣＣスケジュールするように設定されたＭＣＣがＵに設定されたＳＦがすべてＵであり、これを除いた残りのＳＦ（すなわち、該当の２個のＣＣがすべてＤに設定されたＳＦ）がすべてＤに設定される仮想のＵＬ−ＤＬ構成を“ＵＬＵ−ｃｆｇ”と定義する。最終的に、ＰＣＣと該当のＵＬＵ−ｃｆｇのＤＬユニオンに設定されたＡＣＫ／ＮＡＣＫタイミングを適用することができる。

【0137】

・ＳＣＣをクロス−ＣＣスケジュールするように設定されたＭＣＣがＵで、該当のＳＣＣがＤであるＳＦ（以下、衝突ＳＦ）では、該当のＳＣＣのＤに対するスケジュールをあきらめることができる。この場合、端末は、衝突ＳＦでＳＣＣに対するＤＬ許可ＤＣＩフォーマットを受信するための過程（例えば、探索空間監視、ＰＤＣＣＨ候補に対するブラインド復号）を省略できる。

【0138】

［Ａｌｔ １］

【0139】

・ＰＣＣを通じて受信されるＤＬデータに対するＡＣＫ／ＮＡＣＫ

【0140】

ＰＣＣのＡＣＫ／ＮＡＣＫタイミングを適用することができる。

【0141】

・ＳＣＣを通じて受信されるＤＬデータに対するＡＣＫ／ＮＡＣＫ

【0142】

非クロスＣＣスケジュール：ＰＣＣとＳＣＣのＤＬユニオンに設定されたＡＣＫ／ＮＡＣＫタイミングを適用することができる。

【0143】

クロスＣＣスケジュール：ＳＣＣをクロスＣＣスケジュールするように設定されたＭＣＣとＰＣＣのＤＬユニオンに設定されたＡＣＫ／ＮＡＣＫタイミングを適用することができる。

【0144】

・該当のＳＣＣをクロスＣＣスケジュールするように設定されたＭＣＣがＵで、該当のＳＣＣがＤである衝突ＳＦで、該当のＳＣＣのＤに対するスケジュールをあきらめることができる。この場合、端末は、衝突ＳＦで、ＳＣＣに対するＤＬ許可ＤＣＩフォーマットを受信するための過程（例えば、探索空間監視、ＰＤＣＣＨ候補に対するブラインド復号）を省略できる。

【0145】

[Ａｌｔ ２]

【0146】

・ＰＣＣを通じて送信されるＤＬデータに対するＡＣＫ／ＮＡＣＫ

【0147】

ＰＣＣのＡＣＫ／ＮＡＣＫタイミングを適用することができる。

【0148】

・ＳＣＣを通じて送信されるＤＬデータに対するＡＣＫ／ＮＡＣＫ

【0149】

非クロスＣＣスケジュール：ＰＣＣとＳＣＣのＤＬユニオンに設定されたＡＣＫ／ＮＡＣＫタイミングを適用することができる。

【0150】

クロスＣＣスケジュール：ＰＣＣのＡＣＫ／ＮＡＣＫタイミングを適用することができる。

【0151】

・ＰＣＣ又はＳＣＣをクロス−ＣＣスケジュールするように設定されたＭＣＣがＵで、該当のＳＣＣがＤである衝突ＳＦで、該当のＳＣＣのＤに対するスケジュールをあきらめることができる。この場合、端末は、衝突ＳＦで、ＳＣＣに対するＤＬ許可ＤＣＩフォーマットを受信するための過程（例えば、探索空間監視、ＰＤＣＣＨ候補に対するブラインド復号）を省略できる。

【0152】

上述した方法１−１、１−２（又は、その他の方式）を適用してＡＣＫ／ＮＡＣＫタイミングを設定する場合、送信対象になるＡＣＫ／ＮＡＣＫビット／数がＰＣＣのＵ別に互いに異なるように設定され得る。この場合、効率的なＡＣＫ／ＮＡＣＫ送信リソースの使用のために、ＰＣＣの各Ｕを通じて送信されるＡＣＫ／ＮＡＣＫに対して、互いに異なるＰＵＣＣＨリソース／フォーマット（例えば、ＰＵＣＣＨフォーマット１ａ／１ｂ、ＰＵＣＣＨフォーマット３）及び／又は互いに異なる送信方式（例えば、マルチ−ビットＡＣＫ／ＮＡＣＫ符号化、ＡＣＫ／ＮＡＣＫ選択）を設定／適用することを考慮することができる。

【0153】

例えば、ＰＣＣの特定Ｕ（例えば、ＰＣＣ−Ｕ１）を通じてはＰＣＣ及びＳＣＣの両方に対するＡＣＫ／ＮＡＣＫが同時に送信されるように設定される一方、ＰＣＣの他の特定Ｕ（例えば、ＰＣＣ−Ｕ２）を通じてはＰＣＣに対するＡＣＫ／ＮＡＣＫだけが送信されるように設定され得る。このとき、ＰＣＣ-Ｕ１及びＰＣＣ-Ｕ２を通じて送信されるＡＣＫ／ＮＡＣＫに対して、互いに異なるＰＵＣＣＨリソース及び／又は互いに異なる送信方式（例えば、ＰＵＣＣＨフォーマット）を適用することを考慮することができる。具体的には、ＰＣＣ−Ｕ１を通じて送信されるＡＣＫ／ＮＡＣＫに対しては、明示的ＰＵＣＣＨリソース（例えば、ＰＵＣＣＨフォーマット３）を使用するマルチ−ビットＡＣＫ／ＮＡＣＫ符号化方式を適用し、ＰＣＣ−Ｕ２を通じて送信されるＡＣＫ／ＮＡＣＫに対しては、暗黙ＰＵＣＣＨリソース（例えば、ＰＵＣＣＨフォーマット１ａ／１ｂ）を使用するＡＣＫ／ＮＡＣＫ選択方式を適用することができる。すなわち、ＰＣＣの特定Ｕを通じてＮ個（例えば、Ｎ＝２）以上のＣＣに対するＡＣＫ／ＮＡＣＫが送信されるように設定される場合と、Ｎ個未満のＣＣに対するＡＣＫ／ＮＡＣＫが送信されるように設定される場合とに分けて、ＡＣＫ／ＮＡＣＫの送信のためのＰＵＣＣＨフォーマット、リソース割当方式を変更することができる。

【0154】

図１６は、上記の提案方式によるＡＣＫ／ＮＡＣＫを送信する過程を例示する。図１６を参照すると、端末は、ＤＬデータ（例えば、ＰＤＳＣＨ）を受信した後に、ＡＣＫ／ＮＡＣＫ情報を生成する（Ｓ１６０２）。その後、端末は、サブフレーム＃ｎでＡＣＫ／ＮＡＣＫ情報を送信するためにＰＵＣＣＨリソース割当過程を行う（Ｓ１６０４）。ここで、ＰＵＣＣＨリソース割当過程は、サブフレーム＃ｎで何個（Ｎ）のＣＣに対するＡＣＫ／ＮＡＣＫ情報が送信されるように設定されているかを考慮して決定される。例えば、Ｎが１である場合、ＡＣＫ／ＮＡＣＫ情報は、ＰＵＣＣＨフォーマット１ａ／１ｂ（暗黙的リソース）を通じて送信できる（Ｓ１６０６）。一方、Ｎが２以上である場合、ＡＣＫ／ＮＡＣＫ情報は、ＰＵＣＣＨフォーマット３（明示的リソース）を通じて送信できる（Ｓ１６０６）。

【0155】

ＵＬ許可（ＵＧ）又はＰＨＩＣＨタイミング−方法１−３

【0156】

互いに異なるＵＬ−ＤＬ構成を有するＭＣＣとＳＣＣとが集約された場合、ＵＧ又はＰＨＩＣＨタイミングの設定規則を、次のように考慮することができる。

【0157】

・ＭＣＣを通じて送信されるＵＬデータに対するＵＧ又はＰＨＩＣＨ

【0158】

ＭＣＣのＵＧ又はＰＨＩＣＨタイミングを適用することができる。

【0159】

クロスＣＣスケジュールモードから非クロスＣＣスケジュールモードへの（又は、逆に）再設定時に、少なくともＭＣＣのＵＧ又はＰＨＩＣＨタイミングに対しては基地局と端末間に不一致を防止することができる。

【0160】

・ＳＣＣを通じて送信されるＵＬデータに対するＵＧ又はＰＨＩＣＨ

【0161】

まず、全体ＵＬ−ＤＬ構成のうち、ＭＣＣ又はＳＣＣがＵであるＳＦ（ｓ）がすべてＵに設定されたＵＬ−ＤＬ構成を選択することができる。次に、該当のＵＬ−ＤＬ構成のうち、Ｕの個数が最も少ない（等価的に、Ｄの個数が最も多い）ＵＬ−ＤＬ構成（以下、“ＵＬユニオン”）を選択し、ここに、設定されたＵＧ又はＰＨＩＣＨタイミング（以下、“共通ＵＧ又はＰＨＩＣＨタイミング”）を適用することができる。

【0162】

−ＵＬユニオンの場合、ＳＣＣのすべてのＵに対するＵＧ又はＰＨＩＣＨタイミングがＭＣＣのＤに設定可能なようににＤ／Ｕが設定されている。

【0163】

−好ましくは、ＵＬユニオンにおいて、ＳＣＣのＵとＳＦタイミングが一致するＵに対するＵＧ又はＰＨＩＣＨタイミングだけを選んで適用することができる。

【0164】

・ＭＣＣ及びＳＣＣを通じて送信されるすべてのＵＬデータに対して、共通のＵＧ又はＰＨＩＣＨタイミングを適用することができる。

【0165】

方法１−３（又は、その他の方式）を適用してＵＧ又はＰＨＩＣＨタイミングを設定する場合、ＭＣＣ単独で動作するときにはＵＧ又はＰＨＩＣＨを送信できるように設定されていないＭＣＣの特定Ｄ（例えば、ＭＣＣ−Ｄ１）を、ＭＣＣ／ＳＣＣの特定ＵでのＰＵＳＣＨ送信に対するＵＧ又はＰＨＩＣＨタイミングに設定することができる。便宜上、ＭＣＣ−Ｄ１にＵＧ又はＰＨＩＣＨタイミングが設定されたＭＣＣ／ＳＣＣのＵを、孤児Ｕと呼ぶ。ここで、ＭＣＣ−Ｄ１は、表１、表６及び表７を参照して確認することができる。この場合、孤児Ｕ（又は、孤児Ｕを含むＣＣに設定されたすべてのＵ）は（ＰＨＩＣＨベースのＨＡＲＱプロセスを伴わずに）一時的なＵＧにだけ依存する一過性のＰＵＳＣＨスケジュール／送信の用途に使用することができる。ここで、一過性のＰＵＳＣＨ送信は、ＰＨＩＣＨはいなくてもＨＡＲＱプロセスは伴われるが、非適応的再送信なしに、ＵＬ許可ベースの（適応的）再送信だけを運用することを意味する。例えば、一過性のＰＵＳＣＨ送信は（ＰＨＩＣＨベースのＨＡＲＱプロセスを伴わない）ＵＬデータ、及び／又はＵＣＩ（例えば、ＡＣＫ／ＮＡＣＫ及び／又はＣＱＩ／ＰＭＩ／ＲＩなど）を搬送するために使用することができる。又は、孤児Ｕ（又は、孤児Ｕを含むＣＣに設定されたすべてのＵ）に対してはＰＵＳＣＨスケジュール／送信を制限し、他の用途（例えば、ＰＵＣＣＨ及び／又はＳＲＳ及び／又はＰＲＡＣＨ送信だけ許容）に使用する方法を考慮することができる。この場合、端末は、孤児Ｕに対応するＭＣＣのＤ（すなわち、ＭＣＣ−Ｄ１）でＵＬ許可ＤＣＩフォーマットを受信するための過程（例えば、探索空間監視、ＰＤＣＣＨ候補に対するブラインド復号）を省略できる。

【0166】

図１７及び図１８は、本実施例に係るＵＧ／ＰＨＩＣＨタイミングの設定方法を例示する。便宜上、ＰＣＣとＭＣＣが同一のＣＣであると仮定し、これらをすべてＰＣＣと表示する。また、ＵＬ−ＤＬ構成をＵＤ−ｃｆｇと表示する。

【0167】

図１７は、ＰＣＣとＳＣＣがそれぞれＵＤ−ｃｆｇ＃３、＃６である場合を示す。この場合、前記提案方法を適用すると、次のとおりである。

【0168】

・ＰＣＣを通じて送信されるＵＬデータに対するＵＧ又はＰＨＩＣＨ

【0169】

ＰＣＣ（すなわち、ＵＤ−ｃｆｇ＃３）のＵＧ又はＰＨＩＣＨタイミングを適用することができる。

【0170】

・ＳＣＣを通じて送信されるＵＬデータに対するＵＧ又はＰＨＩＣＨ

【0171】

ＰＣＣ又はＳＣＣがＵであるＳＦ（ｓ）（すなわち、ＳＦ＃２、＃３、＃４、＃７、＃８）がすべてＵに設定されたＵＤ−ｃｆｇ（すなわち、ＵＤ−ｃｆｇ＃０、＃６）のうち、Ｕの個数が最も少ないＵＤ−ｃｆｇ（すなわち、ＵＤ−ｃｆｇ＃６）（*）に設定されたＵＧ又はＰＨＩＣＨタイミングを適用することができる。

【0172】

図１８は、ＰＣＣとＳＣＣがそれぞれＵＤ−ｃｆｇ＃２、＃４である場合を示し、この場合、上記の提案方法を適用すると、次のとおりである。

【0173】

・ＰＣＣを通じて送信されるＵＬデータに対するＵＧ又はＰＨＩＣＨ

【0174】

ＰＣＣ（すなわち、ＵＤ−ｃｆｇ＃２）のＵＧ又はＰＨＩＣＨタイミングを適用することができる。

【0175】

・ＳＣＣを通じて送信されるＵＬデータに対するＵＧ又はＰＨＩＣＨ

【0176】

ＰＣＣ又はＳＣＣがＵであるＳＦ（ｓ）（すなわち、ＳＦ＃２、３、７）がすべてＵに設定されたＵＤ−ｃｆｇ（すなわち、ＵＤ−ｃｆｇ＃０、＃１、＃６）のうち、Ｕの個数が最も少ないＵＤ−ｃｆｇ（すなわち、ＵＤ−ｃｆｇ＃１）（＊）に設定されたＵＧ又はＰＨＩＣＨタイミングを適用することができる。

【0177】

実施例２：信号送受信タイミング設定

【0178】

実施例１の方法を適用すると、ＡＣＫ／ＮＡＣＫタイミング、ＵＧタイミング、ＰＨＩＣＨタイミングは、集約されたＣＣ（例えば、ＰＣＣ及びＳＣＣ）に設定されていない他のＵＤ−ｃｆｇによって決定可能である。しかし、Ｄ又はＵを基準に、ＰＣＣのＵＤ−ｃｆｇとＳＣＣのＵＤ−ｃｆｇのいずれか一方が他方に含まれる場合（すなわち、入れ子（ｎｅｓｔｅｄ）構造）に、実施例１の方法を適用すると、ＡＣＫ／ＮＡＣＫタイミング、ＵＧタイミング、ＰＨＩＣＨタイミングは、ＰＣＣ又はＳＣＣのＵＤ−ｃｆｇに設定されたタイミングに従うようになる。したがって、複数のＣＣが集約され、これらのＵＤ−ｃｆｇが入れ子関係にある場合、実施例１のタイミング設定過程をより単純化することができる。

【0179】

具体的に、図１９で陰影部分に該当するＣＡ組合せ（ＵＤ−ｃｆｇ＃１と＃３のＣＡ、ＵＤ−ｃｆｇ＃２と＃３のＣＡ、ＵＤ−ｃｆｇ＃２と＃４のＣＡ）に対してだけ実施例１を適用し、残りのＣＡ組合せに対しては、下記の提案方法を適用することができる。

【0180】

ＡＣＫ／ＮＡＣＫタイミング−方法２−１

【0181】

・ＰＣＣを通じて受信されるＤＬデータに対するＡＣＫ／ＮＡＣＫ

【0182】

ＰＣＣに設定されているＡＣＫ／ＮＡＣＫタイミングをそのまま適用することができる。

【0183】

・ＳＣＣを通じて受信されるＤＬデータに対するＡＣＫ／ＮＡＣＫ

【0184】

ＰＣＣとＳＣＣのうち、Ｕの個数が更に少ない（等価的に、Ｄの個数が更に多い）ＣＣに設定されたＡＣＫ／ＮＡＣＫタイミング（すなわち、“共通のＡＣＫ／ＮＡＣＫタイミング”）を適用することができる。

【0185】

−好ましくは、前記選択されたＣＣのＵＤ−ｃｆｇにおいて、ＳＣＣのＤとＳＦタイミングが一致するＤに対するＡＣＫ／ＮＡＣＫタイミングだけを選んで適用することができる。

【0186】

・ＰＣＣ及びＳＣＣを通じて受信されるすべてのＤＬデータに共通して、前記決定された共通のＡＣＫ／ＮＡＣＫタイミングを適用することができる。

【0187】

ＵＧ又はＰＨＩＣＨタイミング−方法２−２

【0188】

・ＭＣＣを通じて送信されたＵＬデータに対するＵＧ又はＰＨＩＣＨ

【0189】

ＭＣＣのＵＧ又はＰＨＩＣＨタイミングを適用することができる。

【0190】

・ＳＣＣを通じて送信されたＵＬデータに対するＵＧ又はＰＨＩＣＨ

【0191】

ＭＣＣ及びＳＣＣのうち、Ｕの個数が更に多い（等価的に、Ｄの個数が更に少ない）ＣＣに設定されたＵＧ又はＰＨＩＣＨタイミング（すなわち、“共通のＵＧ又はＰＨＩＣＨタイミング”）を適用することができる。

【0192】

−好ましくは、前記選択されたＣＣのＵＤ−ｃｆｇにおいて、ＳＣＣのＵとＳＦタイミングが一致するＵに対するＵＧ又はＰＨＩＣＨタイミングだけを選んで適用することができる。

【0193】

・ＭＣＣ及びＳＣＣでのすべてのＵＬデータ送信に共通して、前記決定された共通のＵＧ又はＰＨＩＣＨタイミングを適用することができる。

【0194】

実施例３：信号送受信タイミング及びＵＬ ＨＡＲＱプロセス

【0195】

表８を参照して説明したように、ＴＤＤの場合、ＵＬ−ＤＬ構成別にＵＬ ＳＦの数が異なるように規定されており、これに基づくＵＬ ＨＡＲＱプロセスの個数及びＵＬ ＨＡＲＱ ＲＴＴもＵＬ−ＤＬ構成によって異なるように設定可能である。

【0196】

一方、実施例１、２のＵＧ又はＰＨＩＣＨタイミング割当方式を適用する場合、特定ＭＣＣ／ＳＣＣの組合せでは、ＭＣＣ／ＳＣＣ自体に設定されているＵＬ ＨＡＲＱ ＲＴＴとは異なるＵＬ ＨＡＲＱ ＲＴＴを有するＵＤ−ｃｆｇのＵＧ又はＰＨＩＣＨタイミングを適用する場合が発生し得る。例えば、ＭＣＣがＵＤ−ｃｆｇ＃６で、ＳＣＣが（１０ＳＦｓ又は１０ｍｓのＵＬ ＨＡＲＱ ＲＴＴを有する）ＵＤ−ｃｆｇ＃１であると仮定する。この場合、実施例１、２の提案方式を適用すると、ＳＣＣ Ｕに対して、ＵＤ−ｃｆｇ＃６に設定されたＵＧ又はＰＨＩＣＨタイミング及び（１０ＳＦｓ又は１０ｍｓではない）ＵＬ ＨＡＲＱ ＲＴＴが適用されるので、全体ＵＬ ＨＡＲＱタイミング設定に問題が発生することがある。

【0197】

図２０は、実施例１、２のＵＧ又はＰＨＩＣＨタイミング割当方式を適用するときに、ＵＬ ＨＡＲＱタイミング設定に問題が発生するＣＡ組合せを例示する。同図において陰影部分がＵＬ ＨＡＲＱタイミング設定に問題が発生するＣＡ組合せを示す。便宜上、陰影に該当するＭＣＣ／ＳＣＣの組合せを適用不能ＭＳコーム（ｎｏｎ−ａｐｐｌｉｃａｂｌｅ ＭＣＣ／ＳＣＣ−ｃｏｍｂ）と呼び、残りのＭＣＣ／ＳＣＣの組合せを適用可能ＭＳコームと呼ぶ。図２０（ａ）は、ＭＣＣにＭＣＣのＵＧ又はＰＨＩＣＨタイミングを適用し、ＳＣＣに共通のＵＧ又はＰＨＩＣＨタイミングを適用する場合を示す。図２０（ｂ）は、ＭＣＣとＳＣＣの両方に共通のＵＧ又はＰＨＩＣＨタイミングを適用する場合を示す。

【0198】

したがって、適用可能ＭＳコームに対しては、前記提案のＵＧ又はＰＨＩＣＨタイミング設定方法をそのまま適用し、適用不能ＭＳコームに対して、次の方法を考慮することができる。

【0199】

０）実施例１、２のＵＧ又はＰＨＩＣＨタイミング設定方法を適用し、共通のＵＧ又はＰＨＩＣＨタイミングが適用されるＣＣに限って、下記の方法３−０又は方法３−０−１に基づいてＵＬ ＨＡＲＱ ＲＴＴをＮ＊１０ＳＦｓ又はＮ＊１０ｍｓ（Ｎは１以上の整数で、好ましくは、１又は２である）に転換して運営したり、

【0200】

１）（ＤＬ／ＵＬの両方に対して、又はＵＬに対してだけ）クロス−ＣＣスケジュール設定を許容しなかったり、

【0201】

２）（ＤＬ／ＵＬの両方に対して、又はＵＬに対してだけ）搬送波集約を許容しなかったり、

【0202】

３）クロス−ＣＣスケジュールが設定された場合、該当のＳＣＣに対するＵＬデータスケジュール／送信をあきらめたり、

【0203】

４）下記の方法３−１に基づくＵＧ又はＰＨＩＣＨタイミング設定方法を適用したり、

【0204】

５）下記の方法３−２に基づくＵＧ又はＰＨＩＣＨタイミング設定方法を適用したりすることができる。

【0205】

ＨＡＲＱプロセス構成−方法３−０

【0206】

・ＵＧ／ＰＨＩＣＨ⇒ＰＵＳＣＨタイミング関係（便宜上、これらの時間差をＫ ＳＦｓ又はＫ ｍｓと呼ぶ）は、実施例１、２の共通のＵＧ又はＰＨＩＣＨタイミングを順守することができる。

【0207】

・ＰＵＳＣＨ⇒ＰＨＩＣＨ／ＵＧ間のタイミング関係（便宜上、これらの時間差をＬ ＳＦｓ又はＬ ｍｓと呼ぶ）は、ＵＧ／ＰＨＩＣＨ⇒ＰＵＳＣＨ⇒ＵＧ／ＰＨＩＣＨの所要時間がＮ＊１０ＳＦｓ又はＮ＊１０ｍｓになるように設定することができる。Ｎは１以上の整数で、好ましくは、１又は２である。

【0208】

すなわち、Ｌ＝Ｎ＊１０−Ｋになるように設定することができる。

【0209】

ＨＡＲＱプロセス構成−方法３−０−１

【0210】

・ＳＦ＃ｎでのＰＵＳＣＨ送信に対して、実施例１、２の共通のＵＧ又はＰＨＩＣＨタイミングを適用して、ＵＧ⇒ＰＵＳＣＨタイミング関係（便宜上、これらの時間差をＫ ＳＦｓ又はＫ ｍｓと呼ぶ）を設定することができる。

【0211】

・ＳＦ＃ｎでのＰＵＳＣＨ送信に対して、実施例１、２の共通のＵＧ又はＰＨＩＣＨタイミングを適用して、ＰＵＳＣＨ⇒ＰＨＩＣＨタイミング関係（便宜上、これらの時間差をＬ ＳＦｓ又はＬ ｍｓと呼ぶ）を設定することができる。

【0212】

・最終的に、Ｎ＊１０ＳＦｓ又はＮ＊１０ｍｓ間隔のＰＵＳＣＨ送信が同一のＰＵＳＣＨ ＨＡＲＱプロセスを構成するように、ＰＨＩＣＨ⇒ＵＧ間のタイミング関係を設定することができる。すなわち、ＰＨＩＣＨとＵＧの時間差を（０ではない）Ｈ＝Ｎ＊１０−Ｋ−Ｌに設定することができる。

【0213】

例えば、ＳＦ＃ｎでのＰＵＳＣＨ、ＳＦ＃（ｎ＋Ｌ）でのＰＨＩＣＨ、ＳＦ＃（ｎ＋Ｌ＋（Ｎ＊１０−Ｋ−Ｌ））＝ＳＦ＃（ｎ＋Ｎ＊１０−Ｋ）でのＵＧ、ＳＦ＃（ｎ＋Ｎ＊１０−Ｋ＋Ｋ）＝ＳＦ＃（ｎ＋Ｎ＊１０）でのＰＵＳＣＨが同一の一つのＰＵＳＣＨ ＨＡＲＱプロセスを構成するように割り当て可能である。

【0214】

したがって、ＰＵＳＣＨ送信の観点から見ると、端末は、ＳＦ＃（ｎ−Ｋ−（Ｎ＊１０−Ｋ−Ｌ））=＃（ｎ−Ｋ−Ｈ）＝＃（ｎ−Ｌ）＝＃（ｎ−（Ｎ＊１０−Ｌ））のＭＣＣでＰＨＩＣＨを受信したり／受信し、ＳＦ＃（ｎ−Ｋ）のＭＣＣでＵＬ許可を受信したりした場合、ＳＦ＃ｎのＳＣＣでＰＵＳＣＨを送信することができる。ＰＵＳＣＨが初期送信であるか、再送信であるかは、ＰＨＩＣＨが受信されたか否か、ＵＬ許可の内容（例えば、新規データ指示子（ＮＤＩ）がトグルされたか否か）によって定められる。

【0215】

参考に、提案方法３−０−１を適用した例を挙げると、次のとおりである。実施例１、２ベースのＵＧ又はＰＨＩＣＨタイミング設定方式によってＵＬユニオンがＤＵ−ｃｆｇ＃６に決定された状況で、ＳＦ＃３でのＰＵＳＣＨ送信に対する２０［ＴＴＩ］ＵＬ ＨＡＲＱ ＲＴＴベースのＵＬ許可／ＰＨＩＣＨタイミングは、表５、６、７を参照して、下記のように設定することができる。ＴＴＩ単位はＳＦ又はｍｓであってもよい。

【0216】

・ＳＦ＃３でのＰＵＳＣＨ送信に対してＵＬユニオンタイミング、すなわち、ＵＤ−ｃｆｇ＃６に設定されているＵＬ許可／ＰＨＩＣＨタイミングを適用して、ＵＬ許可⇒ＰＵＳＣＨ間のタイミング関係、すなわち、時間間隔Ｋ［ＴＴＩ］を決定することができる。

【0217】

表５を参照すると、ＳＦ＃６でのＵＬ許可⇒ＳＦ＃（１０＋３）でのＰＵＳＣＨ間のタイミングの差は、Ｋ＝７［ＴＴＩ］となる。

【0218】

・ＳＦ＃３でのＰＵＳＣＨ送信に対してＵＬユニオンタイミング、すなわち、ＵＤ−ｃｆｇ＃６に設定されているＵＬ許可／ＰＨＩＣＨタイミングを適用して、ＰＵＳＣＨ⇒ＰＨＩＣＨ間のタイミング関係、すなわち、時間間隔Ｌ［ＴＴＩ］を決定することができる。

【0219】

表７を参照すると、ＳＦ＃３でのＰＨＩＣＨ⇒ＳＦ＃９でのＰＨＩＣＨ間のタイミングの差は、Ｌ＝６［ＴＴＩ］となる。

【0220】

・２０［ＴＴＩ］間隔を有するＳＦ＃３でのＰＵＳＣＨ送信が同一の一つのＰＵＳＣＨ ＨＡＲＱプロセスを構成するように、ＰＨＩＣＨ⇒ＵＬ許可間のタイミング関係、すなわち、時間間隔２０−Ｋ−Ｌ［ＴＴＩ］を決定することができる。

【0221】

上記の結果を適用すると、ＰＨＩＣＨ⇒ＵＬ許可間のタイミングの差は、２０−Ｋ−Ｌ＝２０−７−６＝７［ＴＴＩ］となる。

【0222】

・結果的に、ＳＦ＃３でのＰＵＳＣＨ、ＳＦ＃（３＋Ｌ）＝ＳＦ＃９でのＰＨＩＣＨ、ＳＦ＃（９＋（２０−Ｋ−Ｌ））＝ＳＦ＃１６でのＵＬ許可、ＳＦ＃（１６＋Ｋ）＝ＳＦ＃２３でのＰＵＳＣＨが同一の一つのＰＵＳＣＨ ＨＡＲＱプロセスを構成するように割り当て可能である。

【0223】

ＨＡＲＱプロセス構成−方法３−１

【0224】

・ＭＣＣ ＵでのＰＵＳＣＨ送信に対するＵＧ又はＰＨＩＣＨ

【0225】

ＭＣＣのＵＧ又はＰＨＩＣＨタイミングを適用することができる。

【0226】

・ＳＣＣ Ｕ（すなわち、ＳＦ＃ｎ）でのＰＵＳＣＨ送信に対するＵＧ又はＰＨＩＣＨ

【0227】

ＵＧタイミング（以下、ＳＦ＃ＵＧ）：ＳＦ＃（ｎ−ｐ）又はその前に存在する、ＳＦ＃ｎと最も近いＭＣＣのＤに設定することができる。ここで、ｐは１以上の整数で、好ましくは、４である。

【0228】

ＰＨＩＣＨタイミング（以下、ＳＦ＃ＰＨ）：ＵＧタイミングでＮ＊１０ＳＦｓ又はＮ＊１０ｍｓの後の時点、すなわち、ＳＦ＃（ＵＧ＋Ｎ＊１０）でのＭＣＣのＤに設定することができる。

【0229】

ｎ−ＵＧ＞１０−ｐ（例えば、６）の場合：ＰＨ−ｎ＜ｐ（例えば、４）になるので、ＳＦ＃ｎのＳＣＣ Ｕに対しては、１０ＳＦｓ又は１０ｍｓのＨＡＲＱ ＲＴＴを有する同期式ＨＡＲＱをサポートできない。したがって、該当のＳＣＣ Ｕに対して、次のような方法を考慮することができる。

【0230】

Ａｌｔ ０）方法３−０、３−０−１又は３−２を適用することができる。

【0231】

Ａｌｔ １）ＵＧ及びＰＨＩＣＨタイミングをそれぞれＳＦ＃ＵＧ、ＳＦ＃（ＵＧ＋２０）に設定して、２０ＳＦｓ又は２０ｍｓのＨＡＲＱ ＲＴＴを有する同期式ＨＡＲＱをサポートすることができる。

【0232】

Ａｌｔ ２）ＵＧタイミングだけをＳＦ＃ＵＧに設定し（すなわち、ＰＨＩＣＨタイミング設定なし）、ＳＦ＃ｎは（ＰＨＩＣＨベースのＨＡＲＱプロセスを伴わずに）一時的なＵＧにだけ依存する一過性のＰＵＳＣＨスケジュール／送信の用途に使用することができる。ここで、一過性のＰＵＳＣＨ送信は、ＰＨＩＣＨはなくても、ＨＡＲＱプロセスは伴うが、非適応的再送信なしに、ＵＬ許可ベースの（適応的）再送信だけを運用することを意味する。例えば、一過性のＰＵＳＣＨ送信は（ＰＨＩＣＨベースのＨＡＲＱプロセスを伴わない）ＵＬデータ、及び／又はＵＣＩ（例えば、ＡＣＫ／ＮＡＣＫ及び／又はＣＱＩ／ＰＭＩ／ＲＩなど）を搬送するために使用することができる。

【0233】

Ａｌｔ ３）ＳＦ＃ｎのＳＣＣ Ｕに対するＰＵＳＣＨスケジュール／送信を制限し、ＳＦ＃ｎのＳＣＣ Ｕを他の用途（例えば、ＰＵＣＣＨ及び／又はＳＲＳ及び／又はＰＲＡＣＨ送信だけ許容）に使用することができる。

【0234】

ＨＡＲＱプロセス構成−方法３−２

【0235】

実施例１、２のＵＧ又はＰＨＩＣＨタイミング設定方法（例えば、ＵＬユニオン）を適用し、共通のＵＧ又はＰＨＩＣＨタイミングが適用されるＣＣ（例えば、ＳＣＣ）に限って、一つのＵＬ ＨＡＲＱプロセスが（ホップしながら）使用する複数のＵＬ ＳＦタイミングにＳＣＣ Ｄ又はＳが含まれる場合に、該当のＳＣＣ Ｄ又はＳでＵＬデータ送信をスキップすることができる。そのために、該当のＳＣＣ Ｄ又はＳに対応する（すなわち、該当のＳＦタイミングでのＰＵＳＣＨをスケジュールするＵＧ、及び該当のＳＦタイミングでのＰＵＳＣＨに対するＡＣＫ／ＮＡＣＫ（ＰＨＩＣＨ）を送信する）ＭＣＣ ＤＬ ＳＦで、ＵＬデータ送信のためのＵＧ（及び／又はＰＨＩＣＨ）スケジュール／受信を省略できる。

【0236】

すなわち、ＵＬユニオンタイミングに基づいて、一つのＵＬ ＨＡＲＱプロセスが（ホップしながら）使用する複数のＳＣＣ ＵＬタイミングを連結し、ＳＣＣにいないＵＬタイミングでのデータ（例えば、ＰＵＳＣＨ）送信及びこれに関連する制御情報（例えば、ＰＨＩＣＨ／ＵＧ）の送受信は（ＵＬユニオンタイミング上で）スキップすることができる。制御情報のスキップの時に、ＵＬ ＨＡＲＱプロセス内でＳＣＣ ＵＬ間の連結は、先行ＳＣＣ ＵＬに対応するＵＬユニオンＰＨＩＣＨタイミング、後行ＳＣＣ ＵＬに対応するＵＬユニオンＵＧタイミングを用いて行うことができる（ここで、該当の先後行ＵＬは、ＵＬユニオン（ＨＡＲＱ）タイミング上で隣接していないＵＬであってもよい）。例えば、先行ＳＣＣ ＵＬでＳＣＣ ＰＵＳＣＨ送信⇒先行ＳＣＣ ＵＬに対応するＵＬユニオンＰＨＩＣＨタイミングでＰＨＩＣＨ受信（ＭＣＣ）⇒後行ＳＣＣ ＵＬに対応するＵＬユニオンＵＬ許可タイミングでＵＬ許可受信（ＭＣＣ）⇒後行ＳＣＣ ＵＬでＳＣＣ ＰＵＳＣＨ送信の順にＨＡＲＱプロセスを連結することができる（ここで、先行ＳＣＣ ＵＬ及び後行ＳＣＣ ＵＬ間にあるＵＬユニオン上のＵＬに対するＰＨＩＣＨ／ＵＬ許可スケジュール／受信は省略される）。その他の場合（すなわち、上記のようなスキップがない場合）、ＵＬ ＨＡＲＱプロセス内でＳＣＣ ＵＬ間の連結は、ＵＬユニオン上の先行ＵＬに対するＰＨＩＣＨタイミング、ＵＬユニオン上の後行ＵＬをスケジュールするＵＧタイミングを用いて行うことができ、このとき、該当の先行後行ＵＬは、ＵＬユニオン（ＨＡＲＱ）タイミング上で隣接しているＵＬであってもよい。例えば、ＵＬユニオン上の先行ＵＬでＳＣＣ ＰＵＳＣＨ送信⇒ＵＬユニオン上の先行ＵＬに対するＰＨＩＣＨタイミングでＰＨＩＣＨ受信（ＭＣＣ）⇒ＵＬユニオン上の後行ＵＬに対するＵＬ許可タイミングでＵＬ許可受信（ＭＣＣ）⇒ＵＬユニオン上の後行ＵＬでＳＣＣ ＰＵＳＣＨ送信の順にＨＡＲＱプロセスを連結することができ、ここで、該当の先後行ＳＣＣ ＵＬは、ＵＬユニオン（ＨＡＲＱ）タイミング上で隣接したＵＬ関係にあるため、これに関連するＰＨＩＣＨ／ＵＬ許可スケジュール／受信に対する省略はない。

【0237】

整理すると、ＭＣＣとＳＣＣのＵＬユニオンであるＵＤ−ｃｆｇに規定されているＵＬ許可又はＰＨＩＣＨタイミング（すなわち、ＵＬユニオンタイミング）を適用して、ＳＣＣの特定ＰＵＳＣＨ ＨＡＲＱプロセスに関連したＰＵＳＣＨ送信（及びＰＨＩＣＨ／ＵＬ許可送信）を時間順に行うことができる。ただし、ＵＬユニオンであるＵＤ−ｃｆｇに規定された特定ＰＵＳＣＨ送信タイミング（Ｕ１）がＳＣＣにＵＬ ＳＦで規定されていない場合、Ｕ１の後の利用可能な最初のＳＣＣ ＵＬ ＳＦ（Ｕ２）を通じて、Ｕ１を通じて送信しなければならないＰＵＳＣＨ送信を行うことができる。ここで、該当のＵＬユニオンタイミングに基づいて、Ｕ１直前の、ＰＵＳＣＨ送信を行うことができる（ＳＣＣに対してＵＬ ＳＦである）ＵＬ ＳＦをＵ０と仮定する。この場合、Ｕ０でのＰＵＳＣＨ送信、Ｕ０でのＰＵＳＣＨ送信に対する（すなわち、該当のＰＵＳＣＨに対するＡＣＫ／ＮＡＣＫが送信される）ＰＨＩＣＨタイミング（Ｄ０）でのＰＨＩＣＨ受信、Ｕ２でのＰＵＳＣＨをスケジュールするＵＬ許可タイミング（Ｄ２）でのＵＬ許可受信、Ｕ２でのＰＵＳＣＨ送信の順にＰＵＳＣＨ ＨＡＲＱに関連する動作を行うことができる。このとき、Ｄ０及びＤ２は、ＵＬユニオンタイミングによって同一又は異なるＳＦタイミングであってもよい。ここで、Ｄ２は、Ｄ０を含んで、Ｄ０の後にＤ０から最も近い（ＵＬユニオンタイミング上の有効な（ｖａｌｉｄ））Ｄ２ ＳＦタイミング（例えば、ＵＧタイミング）で規定することができる。

【0238】

本方法を、例を挙げて説明すると、次のとおりである。ＵＤ−ｃｆｇ＃６がＭＣＣで、ＵＤ−ｃｆｇ＃１がＳＣＣである場合を仮定すると、ＭＣＣの場合、ＳＦ＃２、３、４、７、８がＵＬ ＳＦであり、ＳＣＣの場合、ＳＦ＃２、３、７、８がＵＬ ＳＦである。ここで、ＵＬユニオン方法を適用すると、ＳＣＣでのＰＵＳＣＨ ＨＡＲＱプロセス（すなわち、ＵＬ許可／ＰＵＳＣＨ／ＰＨＩＣＨ送信）は、ＵＤ−ｃｆｇ＃６（ＭＣＣ）に規定されているＵＬ許可又はＰＨＩＣＨタイミングに合せて行うことができる。ＳＣＣのＳＦ＃２での初期ＰＵＳＣＨ送信によって開始される特定ＰＵＳＣＨ ＨＡＲＱプロセスに対して方法３−２を適用する場合、端末は、ＵＤ−ｃｆｇ＃６（ＭＣＣ）に合せて、次のような動作を行うことができる。

【0239】

１）ＳＦ＃２でのＰＵＳＣＨをスケジュールするＵＬ許可タイミング（Ｄ０）でＵＬ許可受信

【0240】

２）ＳＦ＃２でＰＵＳＣＨ送信（初期送信）

【0241】

３）ＳＦ＃２でのＰＵＳＣＨ送信に対するＰＨＩＣＨタイミング（Ｄ１）でＰＨＩＣＨ受信

【0242】

ＳＦ＃１３（＝＃２＋１１（ＲＴＴ））でのＰＵＳＣＨをスケジュールするＵＬ許可タイミング（Ｄ２）でＵＬ許可受信

【0243】

このとき、Ｄ１及びＤ２は、同一のＳＦタイミングであってもよい

【0244】

４）ＳＦ＃１３でＰＵＳＣＨ送信（第１の再送信）

【0245】

５）ＳＦ＃１３でのＰＵＳＣＨ送信に対するＰＨＩＣＨタイミング（Ｄ３）でＰＨＩＣＨ受信

【0246】

６）ＳＦ＃２７（＝＃１３＋１４（ＲＴＴ））でのＰＵＳＣＨをスケジュールするＵＬ許可タイミング（Ｄ４）でＵＬ許可受信

【0247】

このとき、Ｄ３とＤ４は、同一又は互いに異なるＳＦタイミングであってもよく、Ｄ４は、Ｄ３を含んで、Ｄ３の後のＤ３から最も近い（ＵＬユニオンタイミング上で有効な（ｖａｌｉｄ））Ｄ４ ＳＦタイミングに設定することができる

【0248】

一方、ＵＬユニオンであるＵＤ−ｃｆｇ＃６に規定されているタイミングが適用される場合、ＳＦ＃１３でのＰＵＳＣＨに対する再送信はＳＦ＃２４で行うことができる。しかし、ＳＦ＃２４の場合、ＳＣＣでは、ＵＬ ＳＦではないＤＬ又はＳ ＳＦで規定されているので、提案の方式を通じて該当のＳＦ＃２４でのＰＵＳＣＨ送信及びこれをスケジュールするＵＬ許可受信、これに対するＰＨＩＣＨ受信を省略し、該当のＳＦ＃２４の後に利用可能な最初のＳＣＣのＵＬ ＳＦであるＳＦ＃２７を通じて、ＳＦ＃１３でのＰＵＳＣＨに対する再送信を行うように設定することができる

【0249】

７）ＳＦ＃２７（＝＃１３＋１４（ＲＴＴ））でＰＵＳＣＨ送信（第２の再送信）

【0250】

８）ＳＦ＃２７でのＰＵＳＣＨ送信に対するＰＨＩＣＨタイミング（Ｄ５）でＰＨＩＣＨ受信

【0251】

ＳＦ＃３８（＝＃２７＋１１（ＲＴＴ））でのＰＵＳＣＨをスケジュールするＵＬ許可タイミング（Ｄ６）でＵＬ許可受信

【0252】

このとき、Ｄ５とＤ６は、同一のＳＦタイミングであってもよい

【0253】

９）ＳＦ＃３８でＰＵＳＣＨ送信（第３の再送信）

【0254】

１０）ＳＦ＃３８でのＰＵＳＣＨ送信に対するＰＨＩＣＨタイミング（Ｄ７）でＰＨＩＣＨ受信

【0255】

ＳＦ＃５２（＝＃３８＋１４（ＲＴＴ））でのＰＵＳＣＨをスケジュールするＵＬ許可タイミング（Ｄ８）でＵＬ許可受信

【0256】

このとき、Ｄ７とＤ８とＤ０は、同一のＳＦタイミングであってもよい

【0257】

上記の例を時間順により詳しく説明すると、次のとおりである。

【0258】

・ＵＬユニオンであるＵＤ−ｃｆｇ＃６に規定されたＵＬ ＨＡＲＱタイミングをＳＣＣに適用する場合、ＳＣＣ ＰＵＳＣＨのために、次のようなＵＬ ＨＡＲＱ過程が予想される。

【0259】

ＳＦ＃２：ＰＵＳＣＨ⇒ＳＦ＃６：ＰＨＩＣＨ＋ＵＧ⇒ＳＦ＃１３：ＰＵＳＣＨ⇒ＳＦ＃１９：ＰＨＩＣＨ＋ＵＧ⇒ＳＦ＃２４：ＰＵＳＣＨ（ｉｎｖａｌｉｄ ｏｎ ＳＣＣ）⇒ＳＦ＃３０：ＰＨＩＣＨ＋ＵＧ⇒ＳＦ＃３７：ＰＵＳＣＨ⇒ＳＦ＃４１：ＰＨＩＣＨ＋ＵＧ⇒ＳＦ＃４８：ＰＵＳＣＨ⇒ＳＦ＃５５：ＰＨＩＣＨ＋ＵＧ⇒ＳＦ＃６２：ＰＵＳＣＨ

【0260】

・しかし、ＳＦ＃２４は、ＳＣＣ（ＵＤ−ｃｆｇ＃１）がＤＬであるため、ＳＣＣ ＰＵＳＣＨ送信に使用することができない。したがって、ＳＣＣに方法３−２を適用する場合、ＵＬ ＨＡＲＱタイミングは、次のように与えられることができる。

【0261】

ＳＦ＃２：ＰＵＳＣＨ⇒ＳＦ＃６：ＰＨＩＣＨ＋ＵＧ⇒ＳＦ＃１３：ＰＵＳＣＨ⇒ＳＦ＃１９：ＰＨＩＣＨ⇒ＳＦ＃２０：ＵＧ⇒ＳＦ＃２７：ＰＵＳＣＨ⇒ＳＦ＃３１：ＰＨＩＣＨ＋ＵＧ⇒ＳＦ＃３８：ＰＵＳＣＨ⇒ＳＦ＃４５：ＰＨＩＣＨ＋ＵＧ⇒ＳＦ＃５２：ＰＵＳＣＨ

【0262】

図２１乃至図２５は、ＭＣＣのＵＤ−ｃｆｇとＳＣＣのＵＤ−ｃｆｇによって方法３−１を通じて算出された（１０−ＳＦｓ同期式ＨＡＲＱサポートが可能な）ＳＣＣ Ｕに対するＵＧ／ＰＨＩＣＨタイミングを例示する。図２１乃至図２５は、それぞれ、ＭＣＣのＵＤ−ｃｆｇが＃０、＃１、＃２、＃３、＃６である場合を示す。同図で、ＳＦ＃ｍに設定された数字ｋは、ＳＦ＃（ｍ＋ｋ）でＳＣＣ Ｕを通じて送信されるＰＵＳＣＨに対するＵＧ／ＰＨＩＣＨタイミングが、ＳＦ＃ｍでのＭＣＣのＤに設定されることを意味する。

【0263】

図２１乃至図２５に関する説明は、同一／類似しているので、図２１及び図２４についてだけ代表的に説明する。図２１を参照すると、ＭＣＣがＵＤ−ｃｆｇ＃０で、ＳＣＣがＵＤ−ｃｆｇ＃６（ＳＦ＃２、３、４、７、８に５個のＵが存在）である場合、（ＳＦ＃０、１、６のＭＣＣ ＤをＵＧ又はＰＨＩＣＨタイミングに設定して）ＳＦ＃２、４、７のＳＣＣ Ｕ（ｎ−ＵＧ≦６）に対してだけ１０ＳＦｓ ＲＴＴ同期式ＨＡＲＱをサポートし、ＳＦ＃３、８のＳＣＣ Ｕ（ｎ−ＵＧ＞６）に対してはＡｌｔ ０〜３を適用することができる。また、図２４を参照すると、ＭＣＣがＵＤ−ｃｆｇ＃３で、ＳＣＣがＵＤ−ｃｆｇ＃１（ＳＦ＃２、３、７、８に４個のＵが存在）である場合、（ＳＦ＃１、８、９でのＭＣＣのＤをＵＧ又はＰＨＩＣＨタイミングに設定して）ＳＦ＃２、３、７のＳＣＣ Ｕ（ｎ−ＵＧ≦６）に対してだけ１０ＳＦｓ ＲＴＴ同期式ＨＡＲＱをサポートし、ＳＦ＃８のＳＣＣ Ｕ（ｎ−ＵＧ＞６）に対してはＡｌｔ ０〜３を適用することができる。

【0264】

上記の方法３−０、３−０−１、３−１又は３−２（又は、その他の方式）を適用して、ＵＧ又はＰＨＩＣＨタイミングを設定する場合、ＭＣＣ単独で動作するときには、ＵＧ又はＰＨＩＣＨを送信できるように設定されていないＭＣＣの特定Ｄ（例えば、ＭＣＣ−Ｄ１）を、ＭＣＣ／ＳＣＣの特定ＵでのＰＵＳＣＨ送信に対するＵＧ又はＰＨＩＣＨタイミングに設定することができる。便宜上、ＭＣＣ−Ｄ１にＵＧ又はＰＨＩＣＨタイミングが設定されたＭＣＣ／ＳＣＣのＵを孤児Ｕと呼ぶ。ここで、ＭＣＣ−Ｄ１は、表１、表６及び表７を参照して確認することができる。この場合、孤児Ｕ（又は、孤児Ｕを含むＣＣに設定されたすべてのＵ）は（ＰＨＩＣＨベースのＨＡＲＱプロセスを伴わずに）一時的なＵＧにだけ依存する一過性のＰＵＳＣＨスケジュール／送信の用途に使用することができる。ここで、一過性のＰＵＳＣＨ送信は、ＰＨＩＣＨはなくてもＨＡＲＱプロセスは伴うが、非適応的（ｎｏｎ−ａｄａｐｔｉｖｅ）再送信なしに、ＵＬ許可ベースの（適応的）再送信だけを運用することを意味する。例えば、一過性のＰＵＳＣＨ送信は（ＰＨＩＣＨベースのＨＡＲＱプロセスを伴わない）ＵＬデータ、及び／又はＵＣＩ（例えば、ＡＣＫ／ＮＡＣＫ及び／又はＣＱＩ／ＰＭＩ／ＲＩなど）を搬送するために使用することができる。又は、孤児Ｕ（又は、孤児Ｕを含むＣＣに設定されたすべてのＵ）に対してはＰＵＳＣＨスケジュール／送信を制限し、他の用途（例えば、ＰＵＣＣＨ及び／又はＳＲＳ及び／又はＰＲＡＣＨ送信だけ許容）に使用する方法を考慮することができる。この場合、端末は、孤児Ｕに対応するＭＣＣのＤでＵＬ許可ＤＣＩフォーマットを受信するための過程（例えば、探索空間監視、ＰＤＣＣＨ候補に対するブラインド復号）を省略できる。

【0265】

実施例４：信号送受信タイミング及びＵＬ ＨＡＲＱプロセス

【0266】

実施例３のＵＬ ＨＡＲＱプロセスの構成方法は、実施例１、２が適用されるという前提下で、非−適用可能ＭＳ−コームに関する内容を扱っている。本実施例では、ＣＣ組合せ（すなわち、ＵＤ−ｃｆｇ）にかかわらずに適用可能な一般化されたＵＬ ＨＡＲＱプロセスの構成方法について説明する。次のような方法を考慮することができる。

【0267】

ＨＡＲＱプロセス構成−方法４−１

【0268】

・ＭＣＣ ＵでのＰＵＳＣＨ送信に対するＵＧ又はＰＨＩＣＨ

【0269】

ＭＣＣのＵＧ又はＰＨＩＣＨタイミングを適用することができる。

【0270】

・ＳＣＣ Ｕ（すなわち、ＳＦ＃ｎ）でのＰＵＳＣＨ送信に対するＵＧ又はＰＨＩＣＨ

【0271】

ＵＧタイミング（以下、ＳＦ＃ＵＧ）：ＳＦ＃（ｎ−ｐ）又はその前に存在する、ＳＦ＃ｎと最も近いＭＣＣのＤに設定することができる。ここで、ｐは１以上の整数で、好ましくは、４である。

【0272】

ＰＨＩＣＨタイミング（以下、ＳＦ＃ＰＨ）：ＵＧタイミングでＮ＊１０ＳＦｓ又はＮ＊１０ｍｓの後の時点、すなわち、ＳＦ＃（ＵＧ＋Ｎ＊１０）でのＭＣＣのＤに設定することができる。ここで、Ｎは１以上の整数である。例えば、Ｎは１であってもよい。

【0273】

ｎ−ＵＧ＞１０−ｐ（例えば、６）の場合：ＰＨ−ｎ＜ｐ（例えば、４）になるので、該当のＳＦ＃ｎのＳＣＣ Ｕに対しては、１０ＳＦｓ又は１０ｍｓのＨＡＲＱ ＲＴＴを有する同期式ＨＡＲＱをサポートできない。したがって、該当のＳＣＣ Ｕについて、次のような方法を考慮することができる。

【0274】

Ａｌｔ １）ＵＧ又はＰＨＩＣＨタイミングを、それぞれ、ＳＦ＃ＵＧ、ＳＦ＃（ＵＧ＋２０）に設定して、２０ＳＦｓ又は２０ｍｓのＨＡＲＱ ＲＴＴを有する同期式ＨＡＲＱをサポートすることができる。

【0275】

Ａｌｔ ２）ＵＧタイミングだけをＳＦ＃ＵＧに設定し（すなわち、ＰＨＩＣＨタイミング設定なし）、ＳＦ＃ｎは（ＰＨＩＣＨベースのＨＡＲＱプロセスを伴わずに）一時的なＵＧにだけ依存する一過性のＰＵＳＣＨスケジュール／送信の用途に使用することができる。ここで、一過性のＰＵＳＣＨ送信は、ＰＨＩＣＨはなくてもＨＡＲＱプロセスは伴うが、非適応的再送信なしに、ＵＬ許可ベースの（適応的）再送信だけを運用することを意味する。例えば、一過性のＰＵＳＣＨ送信は（ＰＨＩＣＨベースのＨＡＲＱプロセスを伴わない）ＵＬデータ、及び／又はＵＣＩ（例えば、ＡＣＫ／ＮＡＣＫ及び／又はＣＱＩ／ＰＭＩ／ＲＩなど）を搬送するために使用することができる。

【0276】

Ａｌｔ ３）ＳＦ＃ｎのＳＣＣ Ｕに対するＰＵＳＣＨスケジュール／送信を制限し、ＳＦ＃ｎのＳＣＣ Ｕを他の用途（例えば、ＰＵＣＣＨ及び／又はＳＲＳ及び／又はＰＲＡＣＨ送信だけ許容）に使用することができる。

【0277】

一方、ＵＤ−ｃｆｇ＃０、＃６のＨＡＲＱ ＲＴＴが１０ＳＦｓ又は１０ｍｓではない点を考慮して、上記規則について、次の例外を規定することができる。

【0278】

・ＭＣＣがＵＤ−ｃｆｇ＃１〜＃６で、ＳＣＣがＵＤ−ｃｆｇ＃０である場合には、ＳＣＣに設定されたＵＧ又はＰＨＩＣＨタイミング及びＵＬ ＨＡＲＱ ＲＴＴをそのまま適用することができる。

【0279】

・ＭＣＣがＵＤ−ｃｆｇ＃１〜＃５で、ＳＣＣがＵＤ−ｃｆｇ＃６である場合には、ＳＣＣに設定されたＵＧ又はＰＨＩＣＨタイミング及びＵＬ ＨＡＲＱ ＲＴＴをそのまま適用することができる。

【0280】

図２６は、ＭＣＣのＵＤ−ｃｆｇとＳＣＣのＵＤ−ｃｆｇによって前記方法４−１を通じて算出されたＳＣＣ Ｕに対するＵＧ／ＰＨＩＣＨタイミングを例示する。図２６で、ＳＦ＃ｍに設定された数字ｋは、ＳＦ＃（ｍ＋ｋ）でＳＣＣ Ｕを通じて送信されるＰＵＳＣＨに対するＵＧ／ＰＨＩＣＨタイミングが、ＳＦ＃ｍでのＭＣＣのＤに設定されることを意味する。図２７は、図２６のＵＧ／ＰＨＩＣＨタイミングによる場合に、１０−ＳＦｓ同期式ＨＡＲＱのサポートが可能なＳＣＣ Ｕ（図面で、“０”で表示）を示す。

【0281】

図２６及び図２７を参照すると、ＭＣＣがＵＤ−ｃｆｇ＃３で、ＳＣＣがＵＤ−ｃｆｇ＃１（ＳＦ＃２、３、７、８に４個のＵが存在）である場合、（ＳＦ＃１、８、９のＭＣＣ ＤをＵＧ又はＰＨＩＣＨタイミングに設定して）ＳＦ＃２、３、７のＳＣＣ Ｕに対してだけ１０−ＳＦｓ同期式ＨＡＲＱをサポートし、ＳＦ＃８のＳＣＣ Ｕに対しては前記Ａｌｔ １〜３を適用することができる。他の例として、ＭＣＣがＵＤ−ｃｆｇ＃３で、ＳＣＣがＵＤ−ｃｆｇ＃０又は＃６である場合には、ＳＣＣ Ｕに対して、ＳＣＣに設定されたＵＧ又はＰＨＩＣＨタイミング及びＵＬ ＨＡＲＱ ＲＴＴをそのまま適用することができる。更に他の例として、ＭＣＣがＵＤ−ｃｆｇ＃０で、ＳＣＣがＵＤ−ｃｆｇ＃６（ＳＦ＃２、３、４、７、８に５個のＵが存在）である場合、（ＳＦ＃０、１、６のＭＣＣ ＤをＵＧ又はＰＨＩＣＨタイミングに設定して）ＳＦ＃２、４、７のＳＣＣ Ｕに対してだけ１０−ＳＦｓ同期式ＨＡＲＱをサポートし、ＳＦ＃３、８のＳＣＣ Ｕに対しては前記Ａｌｔ １〜３を適用することができる。

【0282】

ＨＡＲＱプロセス構成−方法４−２

【0283】

本方法は、ＭＣＣにかかわらずにすべてのＳＣＣに対してＵＬ ＨＡＲＱ ＲＴＴをＮ＊１０ＳＦｓ又はＮ＊１０ｍｓで運営することを仮定する。ここで、Ｎは、１以上の整数である。したがって、ＳＣＣがＵＤ−ｃｆｇ＃０、＃６である場合にも、ＭＣＣにかかわらずにＳＣＣのＵＬ ＨＡＲＱ ＲＴＴをＮ＊１０ＳＦｓ又はＮ＊１０ｍｓに転換して運営すると仮定する。この場合、次のような方法を考慮することができる。

【0284】

・ＭＣＣ ＵでのＰＵＳＣＨ送信に対するＵＧ又はＰＨＩＣＨ

【0285】

ＭＣＣのＵＧ又はＰＨＩＣＨタイミングを適用することができる。

【0286】

・ＳＣＣ Ｕ（すなわち、ＳＦ＃ｎ）でのＰＵＳＣＨ送信に対するＵＧ又はＰＨＩＣＨ

【0287】

ＵＧタイミング（すなわち、ＳＦ＃ＵＧ）：ＳＦ＃（ｎ−ｐ）又はその前に存在する、ＳＦ＃ｎと最も近いＭＣＣのＤに設定することができる。ここで、ｐは、１以上の整数で、好ましくは、４である。

【0288】

ＰＨＩＣＨタイミング（すなわち、ＳＦ＃ＰＨ）：ＵＧタイミングでＮ＊１０ＳＦｓ又はＮ＊１０ｍｓの後の時点、すなわち、ＳＦ＃（ＵＧ＋Ｎ＊１０）でのＭＣＣのＤに設定することができる。ここで、Ｎは、１以上の整数である。例えば、Ｎは１であってもよい。

【0289】

ｎ−ＵＧ＞１０−ｐ（例えば、６）の場合：ＰＨ−ｎ＜ｐ（例えば、４）になるので、該当のＳＦ＃ｎのＳＣＣ Ｕに対しては、１０ＳＦｓ又は１０ｍｓのＨＡＲＱ ＲＴＴを有する同期式ＨＡＲＱをサポートできない。したがって、該当のＳＣＣ Ｕに対して、次のような方法を考慮することができる。

【0290】

Ａｌｔ １）ＵＧ又はＰＨＩＣＨタイミングをそれぞれＳＦ＃ＵＧ、ＳＦ＃（ＵＧ＋２０）に設定して、２０ＳＦｓ又は２０ｍｓのＨＡＲＱ ＲＴＴを有する同期式ＨＡＲＱをサポートできる。

【0291】

Ａｌｔ ２）ＵＧタイミングだけをＳＦ＃ＵＧに設定し（すなわち、ＰＨＩＣＨタイミング設定なし）、ＳＦ＃ｎは（ＰＨＩＣＨベースのＨＡＲＱプロセスを伴わずに）一時的なＵＧにだけ依存する一過性のＰＵＳＣＨスケジュール／送信の用途に使用することができる。ここで、一過性のＰＵＳＣＨ送信は、ＰＨＩＣＨはなくてもＨＡＲＱプロセスは伴うが、非適応的再送信なしに、ＵＬ許可ベースの（適応的）再送信だけを運用することを意味する。例えば、一過性のＰＵＳＣＨ送信は（ＰＨＩＣＨベースのＨＡＲＱプロセスを伴わない）ＵＬデータ、及び／又はＵＣＩ（例えば、ＡＣＫ／ＮＡＣＫ及び／又はＣＱＩ／ＰＭＩ／ＲＩなど）を搬送するために使用することができる。

【0292】

Ａｌｔ ３）ＳＦ＃ｎのＳＣＣ Ｕに対するＰＵＳＣＨスケジュール／送信を制限し、ＳＦ＃ｎのＳＣＣ Ｕを他の用途（例えば、ＰＵＣＣＨ及び／又はＳＲＳ及び／又はＰＲＡＣＨ送信だけを許容）に使用することができる。

【0293】

図２８は、ＭＣＣのＵＤ−ｃｆｇとＳＣＣのＵＤ−ｃｆｇによって前記方法４−２を通じて算出されたＳＣＣ Ｕに対するＵＧ／ＰＨＩＣＨタイミングを例示する。図２８で、ＳＦ＃ｍに設定された数字ｋは、ＳＦ＃（ｍ＋ｋ）でＳＣＣ Ｕを通じて送信されるＰＵＳＣＨに対するＵＧ／ＰＨＩＣＨタイミングがＳＦ＃ｍでのＭＣＣのＤに設定されることを意味する。図２９は、図２８のＵＧ／ＰＨＩＣＨタイミングによる場合に、１０−ＳＦｓ同期式ＨＡＲＱのサポートが可能なＳＣＣ Ｕ（図面で、“０”で表示）を示す。

【0294】

図２８及び図２９を参照すると、ＭＣＣがＵＤ−ｃｆｇ＃１で、ＳＣＣがＵＤ−ｃｆｇ＃６（ＳＦ＃２、３、４、７、８に５個のＵが存在）である場合、（ＳＦ＃０、１、４、５、６のＭＣＣ ＤをＵＧ又はＰＨＩＣＨタイミングに設定して）すべてのＳＣＣ Ｕに対して１０−ＳＦｓ同期式ＨＡＲＱをサポートできる。他の例として、ＭＣＣがＵＤ−ｃｆｇ＃６で、ＳＣＣがＵＤ−ｃｆｇ＃０（ＳＦ＃２、３、４、７、８、９に６個のＵが存在）である場合、（ＳＦ＃０、１、５、６、９のＭＣＣ ＤをＵＧ又はＰＨＩＣＨタイミングに設定して）ＳＦ＃２、３、４、７、９のＳＣＣ Ｕに対してだけ１０−ＳＦｓ同期式ＨＡＲＱをサポートし、ＳＦ＃８のＳＣＣのＵに対しては前記Ａｌｔ １〜３を適用することができる。

【0295】

上記の提案方法（又は、その他の方式）を適用してＵＧ又はＰＨＩＣＨタイミングを設定する場合、ＭＣＣ単独で動作するときには、ＵＧ又はＰＨＩＣＨを送信できるように設定されていないＭＣＣの特定Ｄ（例えば、ＭＣＣ−Ｄ１）を、ＭＣＣ／ＳＣＣの特定ＵでのＰＵＳＣＨ送信に対するＵＧ又はＰＨＩＣＨタイミングに設定することができる。便宜上、ＭＣＣ−Ｄ１にＵＧ又はＰＨＩＣＨタイミングが設定されたＭＣＣ／ＳＣＣのＵを孤児Ｕと呼ぶ。ここで、ＭＣＣ−Ｄ１は、表１、表６及び表７を参照して確認することができる。この場合、孤児Ｕ（又は、孤児Ｕを含むＣＣに設定されたすべてのＵ）は（ＰＨＩＣＨベースのＨＡＲＱプロセスを伴わずに）一時的なＵＧにだけ依存する一過性のＰＵＳＣＨスケジュール／送信の用途に使用することができる。ここで、一過性のＰＵＳＣＨ送信は、ＰＨＩＣＨはなくてもＨＡＲＱプロセスは伴うが、非適応的再送信なしに、ＵＬ許可ベースの（適応的）再送信だけを運用することを意味する。例えば、一過性のＰＵＳＣＨ送信は（ＰＨＩＣＨベースのＨＡＲＱプロセスを伴わない）ＵＬデータ、及び／又はＵＣＩ（例えば、ＡＣＫ／ＮＡＣＫ及び／又はＣＱＩ／ＰＭＩ／ＲＩなど）を搬送するために使用することができる。又は、孤児Ｕ（又は、孤児Ｕを含むＣＣに設定されたすべてのＵ）に対してはＰＵＳＣＨスケジュール／送信を制限し、他の用途（例えば、ＰＵＣＣＨ及び／又はＳＲＳ及び／又はＰＲＡＣＨ送信だけを許容）に使用する方法を考慮することができる。この場合、端末は、孤児Ｕに対応するＭＣＣのＤでＵＬ許可ＤＣＩフォーマットを受信するための過程（例えば、探索空間監視、ＰＤＣＣＨ候補に対するブラインド復号）を省略できる。

【0296】

図３０は、本発明に適用可能な基地局及び端末を例示する。無線通信システムにリレーが含まれる場合に、バックホールリンクにおいて通信は基地局とリレーとの間で行われ、アクセスリンクにおいて通信はリレーと端末との間で行われる。したがって、図面に例示された基地局又は端末は状況によってリレーに代替してもよい。

【0297】

図３０を参照すると、無線通信システムは、基地局（ＢＳ）１１０及び端末（ＵＥ）１２０を含む。基地局１１０は、プロセッサ１１２、メモリ１１４及び無線周波（ＲＦ）ユニット１１６を含む。プロセッサ１１２は、本発明で提案した手順及び／又は方法を具現するように構成することができる。メモリ１１４は、プロセッサ１１２に接続され、プロセッサ１１２の動作に関連する様々な情報を記憶する。ＲＦユニット１１６は、プロセッサ１１２に接続され、無線信号を送信及び／又は受信する。端末１２０は、プロセッサ１２２、メモリ１２４及びＲＦユニット１２６を含む。プロセッサ１２２は、本発明で提案した手順及び／又は方法を具現するように構成することができる。メモリ１２４は、プロセッサ１２２に接続され、プロセッサ１２２の動作に関連する様々な情報を記憶する。ＲＦユニット１２６は、プロセッサ１２２に接続され、無線信号を送信及び／又は受信する。基地局１１０及び／又は端末１２０は、単一アンテナ又は複数アンテナを有することができる。

【0298】

以上で説明した各実施例は、本発明の構成要素及び特徴が所定の形態で結合されたものである。各構成要素又は特徴は、別の明示的な言及がない限り、選択的なものとして考慮しなければならない。各構成要素又は特徴は、他の構成要素や特徴と結合されない形態で実施することができる。また、一部の構成要素及び／又は特徴を結合して本発明の実施例を構成することも可能である。本発明の実施例で説明した動作の順序は変更可能である。ある実施例の一部構成や特徴は、他の実施例に含めてもよいし、又は、他の実施例に対応する構成又は特徴と入れ替えてもよい。特許請求の範囲において明示的な引用関係のない請求項を結合して実施例を構成したり、出願後の補正によって新しい請求項として含めたりできることは自明である。

【0299】

本明細書においては、本発明の各実施例を主に端末と基地局との間のデータ送受信関係を中心に説明した。本明細書において基地局によって行われると説明された特定動作は、場合によっては、その上位ノードによって行ってもよい。すなわち、基地局を含む複数のネットワークノードからなるネットワークにおいて、端末との通信のために行う多様な動作は、基地局又は基地局以外の他のネットワークノードによって行えることは自明である。基地局は、固定局、ノードＢ、進化ノードＢ（ｅＮＢ）、アクセスポイントなどの用語に代替可能である。また、端末は、ユーザ装置（ＵＥ）、移動機（ＭＳ）、移動加入者局（ＭＳＳ）などの用語に代替可能である。

【0300】

本発明に係る実施例は、様々な手段、例えば、ハードウェア、ファームウエア、ソフトウェア又はそれらの結合などによって具現することができる。ハードウェアによる具現の場合、本発明の一実施例は、一つ又はそれ以上の特定用途集積回路（ＡＳＩＣ）、デジタル信号プロセッサ（ＤＳＰ）、デジタル信号処理デバイス（ＤＳＰＤ）、プログラム可能論理デバイス（ＰＬＤ）、フィールドプログラム可能ゲートアレイ（ＦＰＧＡ）、プロセッサ、コントローラ、マイクロコントローラ、マイクロプロセッサなどによって具現することができる。

【0301】

ファームウエア又はソフトウェアによる具現の場合、本発明の一実施例は、以上説明した機能又は動作を行うモジュール、手順、関数などの形態で具現することができる。ソフトウェアコードは、メモリユニットに記憶されて、プロセッサによって駆動可能である。メモリユニットは、前記プロセッサの内部又は外部に位置し、既に公知となった多様な手段によってプロセッサとデータを交換することができる。

【0302】

本発明は、本発明の特徴を逸脱しない範囲で他の特定の形態に具体化できることは、当業者にとって自明である。したがって、上記の詳細な説明は、すべての面において制限的に解釈してはならず、例示的なものとして考慮しなければならない。本発明の範囲は、添付の請求項の合理的な解釈によって決定しなければならず、本発明の均等範囲内でのすべての変更は本発明の範囲に含まれる。

【産業上の利用可能性】

【0303】

本発明は、端末、リレー、基地局などのような無線通信装置に使用可能である。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14(a)】

【図14(b)】

【図15(a)】

【図15(b)】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】

【図25】

【図26】

【図27】

【図28】

【図29】

【図30】