特許 6408103 無線通信システムにおいて受信確認応答送信方法及び装置

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

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

(11)【特許番号】6408103

(24)【登録日】2018年9月28日

(45)【発行日】2018年10月17日

(54)【発明の名称】無線通信システムにおいて受信確認応答送信方法及び装置

(51)【国際特許分類】

   H04W 28/04 20090101AFI20181004BHJP

   H04W 72/04 20090101ALI20181004BHJP

   H04W 72/12 20090101ALI20181004BHJP

   H04L 29/08 20060101ALI20181004BHJP

   H04L 27/26 20060101ALI20181004BHJP

【ＦＩ】

   H04W28/04 110

   H04W72/04 136

   H04W72/12 150

   H04W72/04 131

   H04L13/00 307Z

   H04L27/26 113

【請求項の数】8

【全頁数】46

(21)【出願番号】特願2017-195141(P2017-195141)

(22)【出願日】2017年10月5日

(62)【分割の表示】特願2016-175427(P2016-175427)の分割

【原出願日】2014年1月9日

(65)【公開番号】特開2018-33153(P2018-33153A)

(43)【公開日】2018年3月1日

【審査請求日】2017年11月2日

(31)【優先権主張番号】61/750,801

(32)【優先日】2013年1月9日

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

(31)【優先権主張番号】61/818,922

(32)【優先日】2013年5月3日

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

(31)【優先権主張番号】61/823,930

(32)【優先日】2013年5月16日

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

(31)【優先権主張番号】61/834,886

(32)【優先日】2013年6月14日

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

(73)【特許権者】

【識別番号】502032105

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

(74)【代理人】

【識別番号】100099759

【弁理士】

【氏名又は名称】青木 篤

(74)【代理人】

【識別番号】100123582

【弁理士】

【氏名又は名称】三橋 真二

(74)【代理人】

【識別番号】100165191

【弁理士】

【氏名又は名称】河合 章

(74)【代理人】

【識別番号】100114018

【弁理士】

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

(74)【代理人】

【識別番号】100159259

【弁理士】

【氏名又は名称】竹本 実

(72)【発明者】

【氏名】チェ ヒョクチン

(72)【発明者】

【氏名】ソ ハンピョル

(72)【発明者】

【氏名】リ スンミン

【審査官】 望月 章俊

(56)【参考文献】

【文献】 MediaTek Inc.，Discussion on HARQ-ACK PUCCH resource for TDD eIMTA[online]，3GPP TSG-RAN WG1#75 R1-135421，インターネット＜URL:http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_75/Docs/R1-135421.zip＞，２０１３年１０月 ７日

【文献】 LG Electronics，Remaining HARQ Details for TDD eIMTA[online]，3GPP TSG-RAN WG1#75 R1-135455，インターネット＜URL:http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_75/Docs/R1-135455.zip＞，２０１３年１１月１１日

【文献】 Qualcomm Incorporated，eIMTA PUCCH Resource Allocation[online]，3GPP TSG-RAN WG1#75 R1-135291，インターネット＜URL:http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_75/Docs/R1-135291.zip＞，２０１３年１１月１１日

【文献】 LG Electronics，TDD DL-UL Reconfiguration Methods for eIMTA，3GPP TSG RAN WG1 Meeting #69 R1-122318，3GPP，２０１２年 ５月２１日

【文献】 Alcatel-Lucent Shanghai Bell et al.，Discussion on timing issues with dynamic TDD UL-DL configuration，3GPP TSG RAN WG1 Meeting #69 R1-122510，3GPP，２０１２年 ５月２１日

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

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

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

Ｈ０４Ｌ２９／０８

Ｈ０４Ｌ２７／２６

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

ＳＡ ＷＧ１−４

ＣＴ ＷＧ１、４

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

【請求項1】

無線通信システムにおいて端末が上りリンクＨＡＲＱ−ＡＣＫを送信する方法であって、
システム情報ブロックを介して第１の上りリンク（ＵＬ）−下りリンク（ＤＬ） ｃｏｎｆｉｇｕｒａｔｉｏｎを受信するステップと、
サブフレームｎ−ｋでＤＬ信号を受信するステップと、
サブフレームｎで前記ＤＬ信号を含むＤＬ信号に対するＨＡＲＱ−ＡＣＫを送信するステップと、
を有し、
前記サブフレームｎにおける前記ＨＡＲＱ−ＡＣＫに対するＰＵＣＣＨリソースは、以下の優先順位
１）前記第１のＵＬ−ＤＬ ｃｏｎｆｉｇｕｒａｔｉｏｎと第２のＵＬ−ＤＬ ｃｏｎｆｉｇｕｒａｔｉｏｎとの間の１つ以上の共通ＤＬサブフレーム、
２）ＵＬサブフレームとして使用されることを許可されない１つ以上のＤＬサブフレーム、
３）ＵＬサブフレームに対して使用されることを許可される１つ以上のＤＬサブフレーム、
で割り当てられる、ＨＡＲＱ−ＡＣＫ送信方法。

【請求項2】

前記ＤＬ信号がＰＤＣＣＨにより示される場合、前記第１のＵＬ−ＤＬ ｃｏｎｆｉｇｕｒａｔｉｏｎと前記第２のＵＬ−ＤＬ ｃｏｎｆｉｇｕｒａｔｉｏｎとの間の共通しないサブフレームのＨＡＲＱ−ＡＣＫに対するＰＵＣＣＨリソースの位置は、上位層シグナリングにより示される、請求項１に記載のＨＡＲＱ−ＡＣＫ送信方法。

【請求項3】

前記ＨＡＲＱ−ＡＣＫが前記第２のＵＬ−ＤＬ ｃｏｎｆｉｇｕｒａｔｉｏｎに従い前記サブフレームｎで送信されるＤＬサブフレームのＨＡＲＱ−ＡＣＫに対するＰＵＣＣＨリソースを決定する際に、前記第１のＵＬ−ＤＬ ｃｏｎｆｉｇｕｒａｔｉｏｎに含まれて、前記第２のＵＬ−ＤＬ ｃｏｎｆｉｇｕｒａｔｉｏｎにない前記ＤＬサブフレームが使用される、請求項１に記載のＨＡＲＱ−ＡＣＫ送信方法。

【請求項4】

前記ＤＬ信号がＥＰＤＣＣＨにより示される場合、前記ＵＬサブフレームとして使用されることを許可されない１つ以上のＤＬサブフレームと前記ＵＬサブフレームに対して使用されることを許可される１つ以上のＤＬサブフレームのＨＡＲＱ−ＡＣＫに対するＰＵＣＣＨリソースは、前記第１のＵＬ−ＤＬ ｃｏｎｆｉｇｕｒａｔｉｏｎと前記第２のＵＬ−ＤＬ ｃｏｎｆｉｇｕｒａｔｉｏｎとの間の前記１つ以上の共通ＤＬサブフレームのＨＡＲＱ−ＡＣＫに対するＰＵＣＣＨリソースに連続する、請求項１に記載のＨＡＲＱ−ＡＣＫ送信方法。

【請求項5】

無線通信システムにおいて複数の上りリンクＨＡＲＱ−ＡＣＫを送信する端末であって、
受信モジュールと、
プロセッサと、を備え、
前記プロセッサは、
システム情報ブロックを介して第１の上りリンク（ＵＬ）−下りリンク（ＤＬ） ｃｏｎｆｉｇｕｒａｔｉｏｎを受信し、
サブフレームｎ−ｋでＤＬ信号を受信し、
サブフレームｎで前記ＤＬ信号を含むＤＬ信号に対するＨＡＲＱ−ＡＣＫを送信するよう構成され、
前記サブフレームｎにおける前記ＨＡＲＱ−ＡＣＫに対するＰＵＣＣＨリソースは、以下の優先順位
１）前記第１のＵＬ−ＤＬ ｃｏｎｆｉｇｕｒａｔｉｏｎと第２のＵＬ−ＤＬ ｃｏｎｆｉｇｕｒａｔｉｏｎとの間の１つ以上の共通ＤＬサブフレーム、
２）ＵＬサブフレームとして使用されることを許可されない１つ以上のＤＬサブフレーム、
３）ＵＬサブフレームに対して使用されることを許可される１つ以上のＤＬサブフレーム、
で割り当てられる、端末。

【請求項6】

前記ＤＬ信号がＰＤＣＣＨにより示される場合、前記第１のＵＬ−ＤＬ ｃｏｎｆｉｇｕｒａｔｉｏｎと前記第２のＵＬ−ＤＬ ｃｏｎｆｉｇｕｒａｔｉｏｎとの間の共通しないサブフレームのＨＡＲＱ−ＡＣＫに対するＰＵＣＣＨリソースの位置は、上位層シグナリングにより示される、請求項５に記載の端末。

【請求項7】

前記ＨＡＲＱ−ＡＣＫが前記第２のＵＬ−ＤＬ ｃｏｎｆｉｇｕｒａｔｉｏｎに従い前記サブフレームｎで送信されるＤＬサブフレームのＨＡＲＱ−ＡＣＫに対するＰＵＣＣＨリソースを決定する際に、前記第１のＵＬ−ＤＬ ｃｏｎｆｉｇｕｒａｔｉｏｎに含まれて、前記第２のＵＬ−ＤＬ ｃｏｎｆｉｇｕｒａｔｉｏｎにない前記ＤＬサブフレームが使用される、請求項５に記載の端末。

【請求項8】

前記ＤＬ信号がＥＰＤＣＣＨにより示される場合、前記ＵＬサブフレームとして使用されることを許可されない１つ以上のＤＬサブフレームと前記ＵＬサブフレームに対して使用されることを許可される１つ以上のＤＬサブフレームのＨＡＲＱ−ＡＣＫに対するＰＵＣＣＨリソースは、前記第１のＵＬ−ＤＬ ｃｏｎｆｉｇｕｒａｔｉｏｎと前記第２のＵＬ−ＤＬ ｃｏｎｆｉｇｕｒａｔｉｏｎとの間の前記１つ以上の共通ＤＬサブフレームのＨＡＲＱ−ＡＣＫに対するＰＵＣＣＨリソースに連続する、請求項５に記載の端末。

【発明の詳細な説明】

【技術分野】

【0001】

以下の説明は、無線通信システムに関し、特に、上りリンクサブフレームを下りリンクサブフレームへと用途変更して用いる場合における受信確認応答送信方法及び装置に関する。

【背景技術】

【0002】

無線通信システムが音声やデータなどのような様々な通信サービスを提供するために広範囲に展開されている。一般に、無線通信システムは、可用のシステムリソース（帯域幅、送信電力など）を共有して複数ユーザとの通信を支援できる多元接続（ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ）システムである。多元接続システムの例には、ＣＤＭＡ（ｃｏｄｅ ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ）システム、ＦＤＭＡ（ｆｒｅｑｕｅｎｃｙ ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ）システム、ＴＤＭＡ（ｔｉｍｅ ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ）システム、ＯＦＤＭＡ（ｏｒｔｈｏｇｏｎａｌ ｆｒｅｑｕｅｎｃｙ ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ）システム、ＳＣ−ＦＤＭＡ（ｓｉｎｇｌｅ ｃａｒｒｉｅｒ ｆｒｅｑｕｅｎｃｙ ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ）システム、ＭＣ−ＦＤＭＡ（ｍｕｌｔｉ ｃａｒｒｉｅｒ ｆｒｅｑｕｅｎｃｙ ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ）システムなどがある。

【発明の概要】

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

【0003】

本発明では、ＴＤＤ（Ｔｉｍｅ Ｄｉｖｉｓｉｏｎ Ｄｕｐｌｅｘ）において上りリンクサブフレームを下りリンクサブフレームへと用途変更して用いる場合に受信確認応答を送信する方法を技術的課題とする。

【0004】

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

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

【0005】

本発明の第１技術的側面は、無線通信システムにおいて端末が上りリンク受信確認応答を送信する方法であって、サブフレームｎで下りリンク信号を受信するステップと、前記下りリンク信号に対する受信確認応答を、前記下りリンク信号が受信されたサブフレームからｋ番目のサブフレームで送信するステップとを有し、前記ｋ番目のサブフレームで受信確認応答のためのリソースは、第１タイムラインに従う場合に前記ｋ番目のサブフレームで受信確認応答を送信すべき下りリンクサブフレーム及び第２タイムラインに従う場合に前記ｋ番目のサブフレームで受信確認応答を送信すべき下りリンクサブフレームのうち共通する、第１グループのサブフレームに優先的に割り当てられる、受信確認応答送信方法である。

【0006】

本発明の第２技術的側面は、無線通信システムにおいて上りリンク受信確認応答を送信する端末装置であって、受信モジュールと、プロセッサとを備え、前記プロセッサは、サブフレームｎで下りリンク信号を受信し、前記下りリンク信号に対する受信確認応答を、前記下りリンク信号が受信されたサブフレームからｋ番目のサブフレームで送信し、前記ｋ番目のサブフレームで受信確認応答のためのリソースは、第１タイムラインに従う場合に前記ｋ番目のサブフレームで受信確認応答を送信すべき下りリンクサブフレーム及び第２タイムラインに従う場合に前記ｋ番目のサブフレームで受信確認応答を送信すべき下りリンクサブフレームのうち共通する、第１グループのサブフレームに優先的に割り当てられる、端末装置である。

【0007】

本発明の第１及び第２技術的側面は、次の事項を含むことができる。

【0008】

前記第１タイムラインは、前記端末がシステム情報によって受信したものであり、前記第２タイムラインは、上りリンクサブフレームを下りリンクサブフレームに切り替えて用いる場合に適用されるものであってもよい。

【0009】

前記受信確認応答のためのリソースのうち、前記第１グループに割り当てられたリソース以外の残りリソースの少なくとも一部は、前記第２タイムラインに従う場合に前記サブフレームで受信確認応答を送信すべきサブフレームのうち、前記共通するサブフレームを除いた、第２グループのサブフレームに割り当てられてもよい。

【0010】

前記第２グループに割り当てられるリソースは、前記第１グループに割り当てられたリソースに連続するものであってもよい。

【0011】

前記第２グループに割り当てられるリソースは、前記第１グループに割り当てられたリソースから所定のオフセットだけ離隔しているものであってもよい。

【0012】

前記第２グループに割り当てられるリソースは、常にＰＵＣＣＨ（Ｐｈｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｃｏｎｔｒｏｌ ＣＨａｎｎｅｌ）フォーマット３のためのリソースに含まれてもよい。

【0013】

前記第２グループに割り当てられるリソースは、前記第２グループのサブフレームのうち、前記第１タイムラインに従う場合、下りリンクサブフレーム又はスペシャルサブフレームのいずれか一つに該当するサブフレームに優先的に割り当てられてもよい。

【0014】

前記第２グループのサブフレームのうち、前記第１タイムラインに従う場合に上りリンクサブフレームに該当するサブフレームに割り当てられる受信確認応答のためのリソースは、インターリービングされてもよい。

【0015】

前記下りリンク信号は、ＰＤＣＣＨ（Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ ＣＨａｎｎｅｌ）によって指示されてもよい。

【0016】

反復的に送信されるべき受信確認応答のためのリソースは、前記第１及び第２タイムラインとして可能なタイムラインのうち、上りリンクサブフレームの個数が最も小さいタイムラインにおける上りリンクサブフレームにのみ含まれてもよい。

【0017】

前記端末が前記第２タイムラインに対する再設定（ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ）メッセージの検出に失敗した場合、前記端末は、前記第１及び第２タイムラインとして可能なタイムラインのうち、下りリンクサブフレームの個数が最も小さいタイムラインにおける下りリンクサブフレームでのみモニタリングを行うことができる。

【0018】

前記端末は、前記再設定メッセージの検出に失敗した無線フレームに対しては受信確認応答を送信しなくてもよい。

【0019】

前記端末は、前記モニタリングを行ったサブフレームに対してのみ受信確認応答を送信してもよい。

【発明の効果】

【0020】

本発明によれば、上りリンクサブフレームを下りリンクサブフレームへと用途変更して使用する場合に発生しうる、受信確認応答のためのリソースの衝突問題を解決することができる。

【0021】

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

【0022】

本明細書に添付される図面は、本発明に関する理解を提供するためのもので、本発明の様々な実施の形態を示し、明細書の記載と共に本発明の原理を説明するためのものである。

【図面の簡単な説明】

【0023】

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

【図2】下りリンクスロットにおけるリソースグリッド（ｒｅｓｏｕｒｃｅ ｇｒｉｄ）を示す図である。

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

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

【図5】上りリンク物理リソースブロックにおいてＰＵＣＣＨフォーマットがマップされる形態を示す図である。

【図6】ＡＣＫ／ＮＡＣＫのためのＰＵＣＣＨリソースを決定する例を示す図である。

【図7】一般ＣＰの場合にＡＣＫ／ＮＡＣＫチャネルの構造を示す図である。

【図8】一般ＣＰの場合にＣＱＩチャネルの構造を示す図である。

【図9】ブロック拡散を用いたＰＵＣＣＨチャネル構造を示す図である。

【図10】上りリンク制御情報をＰＵＳＣＨを介して送信する方式を説明するための図である。

【図11】ＴＤＤにおいて受信確認応答を説明するための図である。

【図12】ＴＤＤにおいて受信確認応答を説明するための図である。

【図13】ＴＤＤにおいて受信確認応答を説明するための図である。

【図14】本発明の実施例を説明するための図である。

【図15】本発明の実施例を説明するための図である。

【図16】本発明の実施例を説明するための図である。

【図17】本発明の実施例を説明するための図である。

【図18】送受信装置の構成を示す図である。

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

【0024】

以下の実施例は、本発明の構成要素及び特徴を所定の形態で結合したものである。各構成要素又は特徴は、別に明示しない限り、選択的なものとして考慮されてもよい。各構成要素又は特徴は、他の構成要素や特徴と結合しない形態で実施されてもよく、また、一部の構成要素及び／又は特徴は結合されて本発明の実施例を構成してもよい。本発明の実施例で説明される動作の順序は変更されてもよい。ある実施例の一部の構成や特徴は、他の実施例に含まれてもよく、他の実施例の対応する構成又は特徴に代えてもよい。

【0025】

本明細書では、本発明の実施例を、基地局と端末間におけるデータ送受信の関係を中心に説明する。ここで、基地局は、端末と直接に通信を行うネットワークの終端ノード（ｔｅｒｍｉｎａｌ ｎｏｄｅ）としての意味を有する。本文書で、基地局により行われるとした特定動作は、場合によっては、基地局の上位ノード（ｕｐｐｅｒ ｎｏｄｅ）により行われてもよい。

【0026】

すなわち、基地局を含む複数のネットワークノード（ｎｅｔｗｏｒｋ ｎｏｄｅｓ）で構成されるネットワークにおいて、端末との通信のために行われる様々な動作は、基地局、又は基地局以外の他のネットワークノードにより行われるということは明らかである。「基地局（ＢＳ：Ｂａｓｅ Ｓｔａｔｉｏｎ）」は、固定局（ｆｉｘｅｄ ｓｔａｔｉｏｎ）、Ｎｏｄｅ Ｂ、ｅＮｏｄｅ Ｂ（ｅＮＢ）、アクセスポイント（ＡＰ：Ａｃｃｅｓｓ Ｐｏｉｎｔ）などの用語に代えてもよい。中継機は、Ｒｅｌａｙ Ｎｏｄｅ（ＲＮ）、Ｒｅｌａｙ Ｓｔａｔｉｏｎ（ＲＳ）などの用語に代えてもよい。また、「端末（Ｔｅｒｍｉｎａｌ）」は、ＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）、ＭＳ（Ｍｏｂｉｌｅ Ｓｔａｔｉｏｎ）、ＭＳＳ（Ｍｏｂｉｌｅ Ｓｕｂｓｃｒｉｂｅｒ Ｓｔａｔｉｏｎ）、ＳＳ（Ｓｕｂｓｃｒｉｂｅｒ Ｓｔａｔｉｏｎ）などの用語に代えてもよい。

【0027】

以下の説明で使われる特定用語は、本発明の理解を助けるために提供されたもので、これらの特定用語の使用は、本発明の技術的思想から逸脱することなく他の形態に変更されてもよい。

【0028】

場合によっては、本発明の概念が曖昧になることを避けるために、公知の構造及び装置を省略したり、各構造及び装置の核心機能を中心にしたブロック図の形式で示すこともできる。また、本明細書全体を通じて同一の構成要素には同一の図面符号を付して説明する。

【0029】

本発明の実施例は、無線接続システムであるＩＥＥＥ ８０２システム、３ＧＰＰシステム、３ＧＰＰ ＬＴＥ及びＬＴＥ−Ａ（ＬＴＥ−Ａｄｖａｎｃｅｄ）システム、及び３ＧＰＰ２システムの少なくとも一つに開示された標準文書でサポートすることができる。すなわち、本発明の実施例において本発明の技術的思想を明確にするために説明していない段階又は部分は、上記の標準文書でサーポートすることができる。なお、本文書で開示している全ての用語は、上記の標準文書によって説明することができる。

【0030】

以下の技術は、ＣＤＭＡ（Ｃｏｄｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）、ＦＤＭＡ（Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）、ＴＤＭＡ（Ｔｉｍｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）、ＯＦＤＭＡ（Ｏｒｔｈｏｇｏｎａｌ Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）、ＳＣ−ＦＤＭＡ（Ｓｉｎｇｌｅ Ｃａｒｒｉｅｒ Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）などのような種々の無線接続システムに用いることができる。ＣＤＭＡは、ＵＴＲＡ（Ｕｎｉｖｅｒｓａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ）やＣＤＭＡ２０００のような無線技術（ｒａｄｉｏ ｔｅｃｈｎｏｌｏｇｙ）によって具現することができる。ＴＤＭＡは、ＧＳＭ（Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）／ＧＰＲＳ（Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ）／ＥＤＧＥ（Ｅｎｈａｎｃｅｄ Ｄａｔａ Ｒａｔｅｓ ｆｏｒ ＧＳＭ Ｅｖｏｌｕｔｉｏｎ）のような無線技術によって具現することができる。ＯＦＤＭＡは、ＩＥＥＥ ８０２．１１（Ｗｉ−Ｆｉ）、ＩＥＥＥ ８０２．１６（ＷｉＭＡＸ）、ＩＥＥＥ ８０２−２０、Ｅ−ＵＴＲＡ（Ｅｖｏｌｖｅｄ ＵＴＲＡ）などのような無線技術によって具現することができる。ＵＴＲＡは、ＵＭＴＳ（Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｙｓｔｅｍ）の一部である。３ＧＰＰ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ） ＬＴＥ（ｌｏｎｇ ｔｅｒｍ ｅｖｏｌｕｔｉｏｎ）は、Ｅ−ＵＴＲＡを用いるＥ−ＵＭＴＳ（Ｅｖｏｌｖｅｄ ＵＭＴＳ）の一部であり、下りリンクでＯＦＤＭＡを採用し、上りリンクでＳＣ−ＦＤＭＡを採用する。ＬＴＥ−Ａ（Ａｄｖａｎｃｅｄ）は、３ＧＰＰ ＬＴＥの進展である。ＷｉＭＡＸは、ＩＥＥＥ ８０２．１６ｅ規格（ＷｉｒｅｌｅｓｓＭＡＮ−ＯＦＤＭＡ Ｒｅｆｅｒｅｎｃｅ Ｓｙｓｔｅｍ）及び進展したＩＥＥＥ ８０２．１６ｍ規格（ＷｉｒｅｌｅｓｓＭＡＮ−ＯＦＤＭＡ Ａｄｖａｎｃｅｄ ｓｙｓｔｅｍ）によって説明することができる。明確性のために、以下では、３ＧＰＰ ＬＴＥ及びＬＴＥ−Ａシステムを中心に説明するが、本発明の技術的思想はこれに制限されない。

【0031】

ＬＴＡ／ＬＴＡ−Ａリソース構造／チャネル
図１を参照して無線フレームの構造について説明する。

【0032】

セルラーＯＦＤＭ無線パケット通信システムにおいて、上り／下りリンク信号パケット送信はサブフレーム（ｓｕｂｆｒａｍｅ）単位に行われ、１サブフレームは、複数のＯＦＤＭシンボルを含む一定の時間区間と定義される。３ＧＰＰ ＬＴＥ標準では、ＦＤＤ（Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｄｕｐｌｅｘ）に適用可能なタイプ１無線フレーム（ｒａｄｉｏ ｆｒａｍｅ）構造と、ＴＤＤ（Ｔｉｍｅ Ｄｉｖｉｓｉｏｎ Ｄｕｐｌｅｘ）に適用可能なタイプ２無線フレーム構造を支援する。

【0033】

図１（ａ）は、タイプ１無線フレームの構造を例示する図である。下りリンク無線フレームは１０個のサブフレームで構成され、１個のサブフレームは時間領域（ｔｉｍｅ ｄｏｍａｉｎ）において２個のスロット（ｓｌｏｔ）で構成される。１個のサブフレームを送信するためにかかる時間をＴＴＩ（ｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｅ ｉｎｔｅｒｖａｌ）という。例えば、１サブフレームの長さは１ｍｓであり、１スロットの長さは０．５ｍｓであってよい。１スロットは時間領域において複数のＯＦＤＭシンボルを含み、周波数領域において複数のリソースブロック（Ｒｅｓｏｕｒｃｅ Ｂｌｏｃｋ；ＲＢ）を含む。３ＧＰＰ ＬＴＥシステムでは、下りリンクでＯＦＤＭＡを用いているため、ＯＦＤＭシンボルが１シンボル区間を表す。ＯＦＤＭシンボルは、ＳＣ−ＦＤＭＡシンボル又はシンボル区間と呼ぶこともできる。リソースブロック（ＲＢ）はリソース割り当て単位であり、１スロットにおいて複数個の連続した副搬送波（ｓｕｂｃａｒｒｉｅｒ）を含むことができる。

【0034】

１スロットに含まれるＯＦＤＭシンボルの数は、ＣＰ（Ｃｙｃｌｉｃ Ｐｒｅｆｉｘ）の構成（ｃｏｎｆｉｇｕｒａｔｉｏｎ）によって異なってもよい。ＣＰには、拡張ＣＰ（ｅｘｔｅｎｄｅｄ ＣＰ）及び一般ＣＰ（ｎｏｒｍａｌ ＣＰ）がある。例えば、ＯＦＤＭシンボルが一般ＣＰによって構成された場合、１スロットに含まれるＯＦＤＭシンボルの数は７個であってよい。ＯＦＤＭシンボルが拡張ＣＰによって構成された場合、１ ＯＦＤＭシンボルの長さが増加するため、１スロットに含まれるＯＦＤＭシンボルの数は、一般ＣＰの場合に比べて少ない。拡張ＣＰの場合に、例えば、１スロットに含まれるＯＦＤＭシンボルの数は６個であってもよい。端末が速い速度で移動する場合などのようにチャネル状態が不安定な場合は、シンボル間干渉をより減らすために、拡張ＣＰを用いることができる。

【0035】

一般ＣＰが用いられる場合、１スロットは７個のＯＦＤＭシンボルを含み、１サブフレームは１４個のＯＦＤＭシンボルを含む。このとき、各サブフレームにおける先頭２個又は３個のＯＦＤＭシンボルはＰＤＣＣＨ（ｐｈｙｓｉｃａｌ ｄｏｗｎｌｉｎｋ ｃｏｎｔｒｏｌ ｃｈａｎｎｅｌ）に割り当て、残りのＯＦＤＭシンボルはＰＤＳＣＨ（ｐｈｙｓｉｃａｌ ｄｏｗｎｌｉｎｋ ｓｈａｒｅｄ ｃｈａｎｎｅｌ）に割り当てることができる。

【0036】

図１（ｂ）は、タイプ２無線フレームの構造を示す図である。タイプ２無線フレームは、２ハーフフレーム（ｈａｌｆ ｆｒａｍｅ）で構成される。各ハーフフレームは、５サブフレーム、ＤｗＰＴＳ（Ｄｏｗｎｌｉｎｋ Ｐｉｌｏｔ Ｔｉｍｅ Ｓｌｏｔ）、保護区間（Ｇｕａｒｄ Ｐｅｒｉｏｄ；ＧＰ）、及びＵｐＰＴＳ（Ｕｐｌｉｎｋ Ｐｉｌｏｔ Ｔｉｍｅ Ｓｌｏｔ）で構成され、ここで、１サブフレームは２スロットで構成される。ＤｗＰＴＳは、端末での初期セル探索、同期化又はチャネル推定に用いられる。ＵｐＰＴＳは、基地局でのチャネル推定と端末の上り送信同期を取るために用いられる。保護区間は、上りリンク及び下りリンク間に下りリンク信号の多重経路遅延によって上りリンクで生じる干渉を除去するための区間である。一方、無線フレームのタイプにかかわらず、１個のサブフレームは２個のスロットで構成される。
無線フレームの構造は例示に過ぎず、無線フレームに含まれるサブフレームの数、サブフレームに含まれるスロットの数、又はスロットに含まれるシンボルの数は様々に変更されてもよい。

【0037】

図２は、下りリンクスロットにおけるリソースグリッド（ｒｅｓｏｕｒｃｅ ｇｒｉｄ）を示す図である。同図で、１下りリンクスロットは時間領域で７個のＯＦＤＭシンボルを含み、１リソースブロック（ＲＢ）は周波数領域で１２個の副搬送波を含むとしたが、本発明はこれに制限されない。例えば、一般ＣＰ（ｎｏｒｍａｌ−Ｃｙｃｌｉｃ Ｐｒｅｆｉｘ）では１スロットが７ ＯＦＤＭシンボルを含むが、拡張ＣＰ（ｅｘｔｅｎｄｅｄ−ＣＰ）では１スロットが６ ＯＦＤＭシンボルを含んでもよい。リソースグリッド上のそれぞれの要素をリソース要素（ｒｅｓｏｕｒｃｅ ｅｌｅｍｅｎｔ）と呼ぶ。１リソースブロックは１２×７個のリソース要素を含む。下りリンクスロットに含まれるリソースブロックの個数Ｎ^DLは、下り送信帯域幅による。上りリンクスロットは下りリンクスロットと同一の構造を有することができる。

【0038】

図３は、下りリンクサブフレームの構造を示す図である。１サブフレーム内で第１のスロットにおける先頭部の最大３個のＯＦＤＭシンボルは、制御チャネルが割り当てられる制御領域に該当する。残りのＯＦＤＭシンボルは、物理下り共有チャネル（Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｓｈａｒｅｄ Ｃｈａｎｃｅｌ；ＰＤＳＣＨ）が割り当てられるデータ領域に該当する。３ＧＰＰ ＬＴＥシステムで用いられる下り制御チャネルには、例えば、物理制御フォーマット指示子チャネル（Ｐｈｙｓｉｃａｌ Ｃｏｎｔｒｏｌ Ｆｏｒｍａｔ ＩｎｄｉｃａｔｏｒＣｈａｎｎｅｌ；ＰＣＦＩＣＨ）、物理下り制御チャネル（Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ；ＰＤＣＣＨ）、物理ＨＡＲＱ指示子チャネル（Ｐｈｙｓｉｃａｌ Ｈｙｂｒｉｄ ａｕｔｏｍａｔｉｃ ｒｅｐｅａｔ ｒｅｑｕｅｓｔ Ｉｎｄｉｃａｔｏｒ Ｃｈａｎｅｌ；ＰＨＩＣＨ）などがある。ＰＣＦＩＣＨは、サブフレームの最初のＯＦＤＭシンボルで送信され、サブフレーム内の制御チャネル送信に用いられるＯＦＤＭシンボルの個数に関する情報を含む。ＰＨＩＣＨは、上り送信の応答としてＨＡＲＱ ＡＣＫ／ＮＡＣＫ信号を含む。ＰＤＣＣＨで送信される制御情報を、下りリンク制御情報（Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ；ＤＣＩ）という。ＤＣＩは、上りリンク又は下りリンクスケジューリング情報を含んだり、任意の端末グループに対する上り送信電力制御命令を含む。ＰＤＣＣＨは、下り共有チャネル（ＤＬ−ＳＣＨ）のリソース割り当て及び送信フォーマット、上り共有チャネル（ＵＬ−ＳＣＨ）のリソース割り当て情報、ページングチャネル（ＰＣＨ）のページング情報、ＤＬ−ＳＣＨ上のシステム情報、ＰＤＳＣＨ上で送信されるランダムアクセス応答（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｒｅｓｐｏｎｓｅ）のような上位層制御メッセージのリソース割り当て、任意の端末グループ内の個別端末に対する送信電力制御命令のセット、送信電力制御情報、ＶｏＩＰ（Ｖｏｉｃｅ ｏｖｅｒ ＩＰ）の活性化などを含むことができる。複数のＰＤＣＣＨが制御領域内で送信されてもよく、端末は複数のＰＤＣＣＨをモニタすることができる。ＰＤＣＣＨは一つ以上の連続する制御チャネル要素（Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ Ｅｌｅｍｅｎｔ；ＣＣＥ）の組み合わせ（ａｇｇｒｅｇａｔｉｏｎ）で送信される。ＣＣＥは、無線チャネルの状態に基づくコーディングレートでＰＤＣＣＨを提供するために用いられる論理割り当て単位である。ＣＣＥは、複数個のリソース要素グループに対応する。ＰＤＣＣＨのフォーマットと利用可能なビット数は、ＣＣＥの個数とＣＣＥによって提供されるコーディングレート間の相関関係によって決定される。基地局は、端末に送信されるＤＣＩによってＰＤＣＣＨフォーマットを決定し、制御情報に巡回冗長検査（Ｃｙｃｌｉｃ Ｒｅｄｕｎｄａｎｃｙ Ｃｈｅｃｋ；ＣＲＣ）を付加する。ＣＲＣは、ＰＤＣＣＨの所有者又は用途によって無線ネットワーク臨時識別子（Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｔｅｍｐｏｒａｒｙ Ｉｄｅｎｔｉｆｉｅｒ；ＲＮＴＩ）という識別子でマスクされる。ＰＤＣＣＨが特定端末に対するものであれば、端末のｃｅｌｌ−ＲＮＴＩ（Ｃ−ＲＮＴＩ）識別子をＣＲＣにマスクすることができる。又は、ＰＤＣＣＨがページングメッセージに対するものであれば、ページング指示子識別子（Ｐａｇｉｎｇ Ｉｎｄｉｃａｔｏｒ Ｉｄｅｎｔｉｆｉｅｒ；Ｐ−ＲＮＴＩ）をＣＲＣにマスクすることができる。ＰＤＣＣＨがシステム情報（より具体的に、システム情報ブロック（ＳＩＢ））に対するものであれば、システム情報識別子及びシステム情報ＲＮＴＩ（ＳＩ−ＲＮＴＩ）をＣＲＣにマスクすることができる。端末のランダムアクセスプリアンブルの送信に対する応答であるランダムアクセス応答を示すために、ランダムアクセス−ＲＮＴＩ（ＲＡ−ＲＮＴＩ）をＣＲＣにマスクすることができる。

【0039】

図４は、上りリンクサブフレームの構造を示す図である。上りリンクサブフレームは、周波数領域で制御領域とデータ領域とに区別できる。制御領域には上りリンク制御情報を含む物理上り制御チャネル（Ｐｈｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ；ＰＵＣＣＨ）が割り当てられる。データ領域には、ユーザーデータを含む物理上り共有チャネル（Ｐｈｙｓｉｃａｌ ｕｐｌｉｎｋ ｓｈａｒｅｄ ｃｈａｎｎｅｌ；ＰＵＳＣＨ）が割り当てられる。単一搬送波特性を維持するために、一つの端末はＰＵＣＣＨとＰＵＳＣＨを同時に送信しない。一つの端末のＰＵＣＣＨは、サブフレームにおいてリソースブロック対（ＲＢ ｐａｉｒ）に割り当てられる。リソースブロック対に属するリソースブロックは、２スロットに対して互いに異なった副搬送波を占める。これを、ＰＵＣＣＨに割り当てられるリソースブロック対がスロット境界で周波数−ホップ（ｆｒｅｑｕｅｎｃｙ−ｈｏｐｐｅｄ）するという。

【0040】

物理上り制御チャネル（ＰＵＣＣＨ）
ＰＵＣＣＨを介して送信される上りリンク制御情報（ＵＣＩ）は、スケジューリング要請（Ｓｃｈｅｄｕｌｉｎｇ Ｒｅｑｕｅｓｔ；ＳＲ）、ＨＡＲＱ ＡＣＫ／ＮＡＣＫ情報、及び下りリンクチャネル測定情報を含むことができる。

【0041】

ＨＡＲＱ ＡＣＫ／ＮＡＣＫ情報は、ＰＤＳＣＨ上の下りリンクデータパケットのデコーティングに成功したか否かによって生成することができる。既存の無線通信システムにおいて、下り単一コードワード（ｃｏｄｅｗｏｒｄ）送信に対してはＡＣＫ／ＮＡＣＫ情報として１ビットが送信され、下り２コードワード送信に対してはＡＣＫ／ＮＡＣＫ情報として２ビットが送信される。

【0042】

チャネル測定情報は、多重入出力（Ｍｕｌｔｉｐｌｅ Ｉｎｐｕｔ Ｍｕｌｔｉｐｌｅ Ｏｕｔｐｕｔ；ＭＩＭＯ）技法に関連するフィードバック情報のことをいい、チャネル品質指示子（Ｃｈａｎｎｅｌ Ｑｕａｌｉｔｙ Ｉｎｄｉｃａｔｏｒ；ＣＱＩ）、プリコーディング行列インデックス（Ｐｒｅｃｏｄｉｎｇ Ｍａｔｒｉｘ Ｉｎｄｅｘ；ＰＭＩ）及びランク指示子（Ｒａｎｋ Ｉｎｄｉｃａｔｏｒ；ＲＩ）を含むことができる。これらのチャネル測定情報をＣＱＩと総称することもできる。ＣＱＩの送信のためにサブフレーム当たりに２０ビットを用いることができる。

【0043】

ＰＵＣＣＨは、ＢＰＳＫ（Ｂｉｎａｒｙ Ｐｈａｓｅ Ｓｈｉｆｔ Ｋｅｙｉｎｇ）とＱＰＳＫ（Ｑｕａｄｒａｔｕｒｅ Ｐｈａｓｅ Ｓｈｉｆｔ Ｋｅｙｉｎｇ）技法を用いて変調することができる。ＰＵＣＣＨを介して複数端末の制御情報を送信することができ、各端末の信号を区別するためにコード分割多重化（Ｃｏｄｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅｘｉｎｇ；ＣＤＭ）を行う場合に、長さ１２のＣＡＺＡＣ（Ｃｏｎｓｔａｎｔ Ａｍｐｌｉｔｕｄｅ Ｚｅｒｏ Ａｕｔｏｃｏｒｒｅｌａｔｉｏｎ）シーケンスを主に使用する。ＣＡＺＡＣシーケンスは、時間領域（ｔｉｍｅ ｄｏｍａｉｎ）及び周波数領域（ｆｒｅｑｕｅｎｃｙ ｄｏｍａｉｎ）で一定の大きさ（ａｍｐｌｉｔｕｄｅ）を維持する特性を有しているため、端末のＰＡＰＲ（Ｐｅａｋ−ｔｏ−Ａｖｅｒａｇｅ Ｐｏｗｅｒ Ｒａｔｉｏ）又はＣＭ（Ｃｕｂｉｃ Ｍｅｔｒｉｃ）を下げてカバレッジを増加させることに適している。また、ＰＵＣＣＨを介して送信される下りデータ送信に対するＡＣＫ／ＮＡＣＫ情報は、直交シーケンス（ｏｒｔｈｇｏｎａｌ ｓｅｑｕｅｎｃｅ）又は直交カバー（ｏｒｔｈｏｇｏｎａｌ ｃｏｖｅｒ；ＯＣ）を用いてカバリングされる。

【0044】

また、ＰＵＣＣＨ上で送信される制御情報は、互いに異なる循環シフト（ｃｙｃｌｉｃ ｓｈｉｆｔ；ＣＳ）値を持つ循環シフトされたシーケンス（ｃｙｃｌｉｃａｌｌｙ ｓｈｉｆｔｅｄ ｓｅｑｕｅｎｃｅ）を用いて区別することができる。循環シフトされたシーケンスは、基本シーケンス（ｂａｓｅ ｓｅｑｕｅｎｃｅ）を特定ＣＳ量（ｃｙｃｌｉｃ ｓｈｉｆｔ ａｍｏｕｎｔ）だけ循環シフトさせて生成することができる。特定ＣＳ量は、循環シフトインデックス（ＣＳ ｉｎｄｅｘ）によって示される。チャネルの遅延拡散（ｄｅｌａｙ ｓｐｒｅａｄ）によって使用可能な循環シフトの数は可変してもよい。種々のシーケンスを基本シーケンスとして用いることができ、前述のＣＡＺＡＣシーケンスがその一例である。

【0045】

また、端末が一つのサブフレームで送信可能な制御情報の量は、制御情報の送信に利用可能なＳＣ−ＦＤＭＡシンボルの個数（すなわち、ＰＵＣＣＨのコヒーレント（ｃｏｈｅｒｅｎｔ）な検出のための参照信号（ＲＳ）送信に用いられるＳＣ−ＦＤＭＡシンボルを除くＳＣ−ＦＤＭＡシンボル）によって決定することができる。

【0046】

３ＧＰＰ ＬＴＥシステムにおいてＰＵＣＣＨは、送信される制御情報、変調技法、制御情報の量などによって総７種の互いに異なるフォーマットと定義され、それぞれのＰＵＣＣＨフォーマットによって送信される上りリンク制御情報（ｕｐｌｉｎｋ ｃｏｎｔｒｏｌ ｉｎｆｏｒｍａｔｉｏｎ；ＵＣＩ）の属性は、下記の表１のようにまとめることができる。

【表1】

【0047】

ＰＵＣＣＨフォーマット１は、ＳＲの単独送信に用いられる。ＳＲ単独送信の場合には、変調されていない波形が適用されるが、その詳細については後述する。

【0048】

ＰＵＣＣＨフォーマット１ａ又は１ｂは、ＨＡＲＱ ＡＣＫ／ＮＡＣＫの送信に用いられる。任意のサブフレームでＨＡＲＱ ＡＣＫ／ＮＡＣＫが単独に送信される場合にはＰＵＣＣＨフォーマット１ａ又は１ｂを用いることができる。又は、ＰＵＣＣＨフォーマット１ａ又は１ｂを用いてＨＡＲＱ ＡＣＫ／ＮＡＣＫ及びＳＲを同一サブフレームで送信することもできる。

【0049】

ＰＵＣＣＨフォーマット２はＣＱＩの送信に用いられ、ＰＵＣＣＨフォーマット２ａ又は２ｂはＣＱＩ及びＨＡＲＱ ＡＣＫ／ＮＡＣＫの送信に用いられる。拡張されたＣＰの場合は、ＰＵＣＣＨフォーマット２がＣＱＩ及びＨＡＲＱ ＡＣＫ／ＮＡＣＫの送信に用いられてもよい。

【0050】

【数1】

【0051】

ＰＵＣＣＨリソース
ＵＥに対しては、上りリンク制御情報（ＵＣＩ）の送信のためのＰＵＣＣＨリソースが、上位（ｈｉｇｈｅｒ）レイヤシグナリングを用いた明示的（ｅｘｐｌｉｃｉｔ）方式或いは暗黙的（ｉｍｐｌｉｃｉｔ）な方式によって基地局（ＢＳ）から割り当てられる。

【0052】

ＡＣＫ／ＮＡＣＫの場合に、端末に対して上位層で複数個のＰＵＣＣＨリソース候補を設定することができ、それらの候補の中でどのＰＵＣＣＨリソースを使用するかは暗黙的な方式で決定することができる。例えば、ＵＥはＢＳからＰＤＳＣＨを受信し、該ＰＤＳＣＨに関するスケジューリング情報を運ぶＰＤＣＣＨリソースによって暗黙的に決定されたＰＵＣＣＨリソースを用いて、該当のデータユニットに対するＡＣＫ／ＮＡＣＫを送信することができる。

【0053】

図６に、ＡＣＫ／ＮＡＣＫのためのＰＵＣＣＨリソースを決定する例を示す。

【0054】

ＬＴＥシステムにおいてＡＣＫ／ＮＡＣＫのためのＰＵＣＣＨリソースは各ＵＥにあらかじめ割り当てられておらず、複数のＰＵＣＣＨリソースをセル内の複数のＵＥが毎時点ごとに分けて使用する。具体的に、ＵＥがＡＣＫ／ＮＡＣＫを送信するために使用するＰＵＣＣＨリソースは、該当の下りリンクデータを運ぶＰＤＳＣＨに関するスケジューリング情報を運ぶＰＤＣＣＨに基づいて暗黙的な方式で決定される。それぞれのＤＬサブフレームにおいてＰＤＣＣＨが送信される全体領域は複数のＣＣＥ（Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ Ｅｌｅｍｅｎｔ）で構成され、ＵＥに送信されるＰＤＣＣＨは一つ以上のＣＣＥで構成される。ＣＣＥは複数（例えば、９個）のＲＥＧ（Ｒｅｓｏｕｒｃｅ Ｅｌｅｍｅｎｔ Ｇｒｏｕｐ）を含む。１個のＲＥＧは、参照信号（Ｒｅｆｅｒｅｎｃｅ Ｓｉｇｎａｌ：ＲＳ）を除いた状態で隣り合う４個のＲＥ（Ｒｅｓｏｕｒｃｅ Ｅｌｅｍｅｎｔ）で構成される。ＵＥは、自身が受信したＰＤＣＣＨを構成するＣＣＥのインデックスのうちの特定ＣＣＥインデックス（例えば、最初或いは最低のＣＣＥインデックス）の関数によって誘導（ｄｅｒｉｖｅ）或いは計算（ｃａｌｃｕｌａｔｅ）される暗黙的ＰＵＣＣＨリソースを用いてＡＣＫ／ＮＡＣＫを送信する。

【0055】

図６を参照すると、それぞれのＰＵＣＣＨリソースインデックスは、ＡＣＫ／ＮＡＣＫのためのＰＵＣＣＨリソースに対応する。図６のように、４〜６番のＣＣＥで構成されたＰＤＣＣＨを介してＰＤＳＣＨに関するスケジューリング情報がＵＥに送信されると仮定する場合、該ＵＥは、上記ＰＤＣＣＨを構成する最低のＣＣＥである４番ＣＣＥのインデックスから誘導或いは計算されたＰＵＣＣＨ、例えば、４番ＰＵＣＣＨを介してＡＣＫ／ＮＡＣＫをＢＳに送信する。図６は、ＤＬに最大Ｍ’個のＣＣＥが存在し、ＵＬに最大Ｍ個のＰＵＣＣＨが存在する場合を例示する。Ｍ’＝Ｍであってもよいが、Ｍ’値とＭ値とが異なるように設計され、ＣＣＥとＰＵＣＣＨリソースのマッピングが重なるようにしてもよい。

【0056】

例えば、ＰＵＣＣＨリソースインデックスを次のように決定することができる。

【数2】

【0057】

【数3】

【0058】

ＰＵＣＣＨチャネル構造
ＰＵＣＣＨフォーマット１ａ及び１ｂについてまず説明する。

【0059】

ＰＵＣＣＨフォーマット１ａ／１ｂにおいてＢＰＳＫ又はＱＰＳＫ変調方式を用いて変調されたシンボルは、長さ１２のＣＡＺＡＣシーケンスで乗算（ｍｕｌｔｉｐｌｙ）される。例えば、変調シンボルｄ（０）に長さＮのＣＡＺＡＣシーケンスｒ（ｎ）（ｎ＝０，１，２，…，Ｎ−１）が乗算された結果は、ｙ（０），ｙ（１），ｙ（２），…，ｙ（Ｎ−１）となる。ｙ（０），…，ｙ（Ｎ−１）シンボルをシンボルブロック（ｂｌｏｃｋ ｏｆ ｓｙｍｂｏｌ）と呼ぶことができる。変調シンボルにＣＡＺＡＣシーケンスを乗算した後に、直交シーケンスを用いたブロック−単位（ｂｌｏｃｋ−ｗｉｓｅ）拡散が適用される。

【0060】

一般ＡＣＫ／ＮＡＣＫ情報に対しては長さ４のアダマール（Ｈａｄａｍａｒｄ）シーケンスが用いられ、短い（ｓｈｏｒｔｅｎｅｄ）ＡＣＫ／ＮＡＣＫ情報及び参照信号（Ｒｅｆｅｒｅｎｃｅ Ｓｉｇｎａｌ）に対しては長さ３のＤＦＴ（Ｄｉｓｃｒｅｔｅ Ｆｏｕｒｉｅｒ Ｔｒａｎｓｆｏｒｍ）シーケンスが用いられる。拡張されたＣＰの場合の参照信号に対しては長さ２のアダマールシーケンスが用いられる。

【0061】

図７は、一般ＣＰの場合にＡＣＫ／ＮＡＣＫチャネルの構造を示す図である。図７では、ＣＱＩ無しでＨＡＲＱ ＡＣＫ／ＮＡＣＫを送信するためのＰＵＣＣＨチャネル構造を例示する。１個のスロットに含まれる７個のＳＣ−ＦＤＭＡシンボルのうち、中間部分における３個の連続したＳＣ−ＦＤＭＡシンボルに参照信号（ＲＳ）を乗せ、残り４個のＳＣ−ＦＤＭＡシンボルにはＡＣＫ／ＮＡＣＫ信号を乗せる。一方、拡張されたＣＰの場合には、中間部分における２個の連続したシンボルにＲＳを乗せることができる。ＲＳに用いられるシンボルの個数及び位置は、制御チャネルによって可変してもよく、それに関連したＡＣＫ／ＮＡＣＫ信号に用いられるシンボルの個数及び位置もそれに応じて変更されてもよい。

【0062】

１ビット及び２ビットの確認応答情報（スクランブルされていない状態）はそれぞれＢＰＳＫ及びＱＰＳＫ変調技法を用いて一つのＨＡＲＱ ＡＣＫ／ＮＡＣＫ変調シンボルで表現することができる。肯定確認応答（ＡＣＫ）は「１」にエンコードし、否定確認応答（ＮＡＣＫ）は「０」にエンコードすることができる。

【0063】

割り当てられる帯域内で制御信号を送信するとき、多重化容量を高めるために２次元拡散を適用する。すなわち、多重可能な端末の数又は制御チャネルの数を増大するために周波数領域拡散と時間領域拡散を同時に適用する。ＡＣＫ／ＮＡＣＫ信号を周波数領域で拡散させるために周波数領域シーケンスを基本シーケンスとして用いる。周波数領域シーケンスとしては、ＣＡＺＡＣシーケンスの一つであるＺａｄｏｆｆ−Ｃｈｕ（ＺＣ）シーケンスを用いることができる。例えば、基本シーケンスであるＺＣシーケンスに互いに異なる循環シフト（Ｃｙｃｌｉｃ Ｓｈｉｆｔ；ＣＳ）を適用することによって、互いに異なる端末又は互いに異なる制御チャネルの多重化を適用することができる。

【数4】

【0064】

周波数領域拡散されたＡＣＫ／ＮＡＣＫ信号を直交拡散（ｓｐｒｅａｄｉｎｇ）コードを用いて時間領域で拡散する。直交拡散コードとしてはウォルシュ−アダマール（Ｗａｌｓｈ−Ｈａｄａｍａｒｄ）シーケンス又はＤＦＴシーケンスを用いることができる。例えば、ＡＣＫ／ＮＡＣＫ信号は４シンボルに対して長さ４の直交シーケンス（ｗ０、ｗ１、ｗ２、ｗ３）を用いて拡散することができる。また、ＲＳも、長さ３又は長さ２の直交シーケンスを用いて拡散する。これを直交カバリング（Ｏｒｔｈｏｇｏｎａｌ Ｃｏｖｅｒｉｎｇ；ＯＣ）という。

【0065】

前述したような周波数領域でのＣＳリソース及び時間領域でのＯＣリソースを用いて複数の端末をコード分割多重化（Ｃｏｄｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅｘ、ＣＤＭ）方式で多重化することができる。すなわち、同一のＰＵＣＣＨ ＲＢ上で複数端末のＡＣＫ／ＮＡＣＫ情報及びＲＳを多重化することができる。

【0066】

このような時間領域拡散ＣＤＭにおいて、ＡＣＫ／ＮＡＣＫ情報に対して支援される拡散コードの個数はＲＳシンボルの個数によって制限される。すなわち、ＲＳ送信ＳＣ−ＦＤＭＡシンボルの個数は、ＡＣＫ／ＮＡＣＫ情報送信ＳＣ−ＦＤＭＡシンボルの個数よりも少ないため、ＲＳの多重化容量（ｃａｐａｃｉｔｙ）がＡＣＫ／ＮＡＣＫ情報の多重化容量に比べて少なくなる。例えば、一般ＣＰの場合、４個のシンボルでＡＣＫ／ＮＡＣＫ情報を送信できるが、ＡＣＫ／ＮＡＣＫ情報のために４個ではなく３個の直交拡散コードを用いる。これは、ＲＳ送信シンボルの個数が３個に制限され、ＲＳのために３個の直交拡散コードしか用いることができないためである。

【0067】

ＡＣＫ／ＮＡＣＫ情報の拡散に用いられる直交シーケンスの一例は、表２及び表３の通りである。表２は、長さ４シンボルに対するシーケンスを示し、表３は、長さ３シンボルに対するシーケンスを示す。長さ４シンボルに対するシーケンスは、一般的なサブフレーム構成のＰＵＣＣＨフォーマット１／１ａ／１ｂで用いられる。サブフレーム構成において、第２のスロットの最後のシンボルでＳＲＳ（Ｓｏｕｎｄｉｎｇ Ｒｅｆｅｒｅｎｃｅ Ｓｉｇｎａｌ）が送信されるなどの場合を考慮して、第１のスロットでは長さ４シンボルに対するシーケンスが適用され、第２のスロットでは長さ３シンボルに対するシーケンスの短い（ｓｈｏｒｔｅｎｅｄ）ＰＵＣＣＨフォーマット１／１ａ／１ｂが適用されてもよい。

【表2】

【表3】

【0068】

一般ＣＰのサブフレームにおいて１スロットで３個のシンボルがＲＳ送信のために用いられ、４個のシンボルがＡＣＫ／ＮＡＣＫ情報送信のために用いられる場合に、例えば、周波数領域で６個の循環シフト（ＣＳ）及び時間領域で３個の直交カバー（ＯＣ）リソースを用いることができるとすれば、総１８個の互いに異なる端末からのＨＡＲＱ確認応答を一つのＰＵＣＣＨ ＲＢ内で多重化することができる。もし、拡張されたＣＰのサブフレームにおいて１スロットで２個のシンボルがＲＳ送信のために用いられ、４個のシンボルがＡＣＫ／ＮＡＣＫ情報送信のために用いられる場合に、例えば、周波数領域で６個の循環シフト（ＣＳ）及び時間領域で２個の直交カバー（ＯＣ）リソースを用いることができるとすれば、総１２個の互いに異なる端末からのＨＡＲＱ確認応答を一つのＰＵＣＣＨ ＲＢ内で多重化することができる。

【0069】

次に、ＰＵＣＣＨフォーマット１について説明する。スケジューリング要請（ＳＲ）は、端末が、スケジュールされることを要請したり又は要請しない方式で送信される。ＳＲチャネルは、ＰＵＣＣＨフォーマット１ａ／１ｂにおけるＡＣＫ／ＮＡＣＫチャネル構造を再利用し、ＡＣＫ／ＮＡＣＫチャネル設計に基づいてＯＯＫ（Ｏｎ−Ｏｆｆ Ｋｅｙｉｎｇ）方式で構成される。ＳＲチャネルでは参照信号が送信されない。したがって、一般ＣＰの場合には、長さ７のシーケンスが用いられ、拡張されたＣＰの場合には長さ６のシーケンスが用いられる。ＳＲ及びＡＣＫ／ＮＡＣＫに対して互いに異なる循環シフト又は直交カバーを割り当てることができる。すなわち、肯定（ｐｏｓｉｔｉｖｅ）ＳＲ送信のために、端末は、ＳＲ用に割り当てられたリソースを通じてＨＡＲＱ ＡＣＫ／ＮＡＣＫを送信する。否定（ｎｅｇａｔｉｖｅ）ＳＲ送信のためには、端末は、ＡＣＫ／ＮＡＣＫ用に割り当てられたリソースを通じてＨＡＲＱ ＡＣＫ／ＮＡＣＫを送信する。

【0070】

次に、ＰＵＣＣＨフォーマット２／２ａ／２ｂについて説明する。ＰＵＣＣＨフォーマット２／２ａ／２ｂは、チャネル測定フィードバック（ＣＱＩ、ＰＭＩ、ＲＩ）を送信するための制御チャネルである。

【0071】

チャネル測定フィードバック（以下では、「ＣＱＩ情報」と総称する）の報告周期及び測定対象となる周波数単位（又は、周波数解像度（ｒｅｓｏｌｕｔｉｏｎ））は基地局で制御することができる。時間領域において周期的及び非周期的ＣＱＩ報告を支援することができる。ＰＵＣＣＨフォーマット２は、周期的報告にのみ用いられ、非周期的報告のためにはＰＵＳＣＨを用いることができる。非周期的報告の場合に、基地局は端末に、上りリンクデータ送信のためにスケジュールされたリソースに個別ＣＱＩ報告を乗せて送信することを指示することができる。

【0072】

図８は、一般ＣＰの場合に、ＣＱＩチャネルの構造を示す。１スロットのＳＣ−ＦＤＭＡシンボル０乃至６のうち、ＳＣ−ＦＤＭＡシンボル１及び５（２番目及び６番目のシンボル）を復調参照信号（Ｄｅｍｏｄｕｌａｔｉｏｎ Ｒｅｆｅｒｅｎｃｅ Ｓｉｇｎａｌ、ＤＭＲＳ）送信に用い、残りＳＣ−ＦＤＭＡシンボルでＣＱＩ情報を送信することができる。一方、拡張されたＣＰの場合には、一つのＳＣ−ＦＤＭＡシンボル（ＳＣ−ＦＤＭＡシンボル３）をＤＭＲＳ送信に用いる。

【0073】

ＰＵＣＣＨフォーマット２／２ａ／２ｂではＣＡＺＡＣシーケンスによる変調を支援し、ＱＰＳＫ変調されたシンボルが長さ１２のＣＡＺＡＣシーケンスで乗算される。シーケンスの循環シフト（ＣＳ）はシンボル及びスロット間に変更される。ＤＭＲＳに対して直交カバリングが用いられる。

【0074】

１個のスロットに含まれる７個のＳＣ−ＦＤＭＡシンボルのうち、３個のＳＣ−ＦＤＭＡシンボル間隔で離れた２個のＳＣ−ＦＤＭＡシンボルには参照信号（ＤＭＲＳ）が乗せられ、残り５個のＳＣ−ＦＤＭＡシンボルにはＣＱＩ情報が乗せられる。１スロット中に２個のＲＳが用いられることは、高速端末を支援するためである。また、循環シフト（ＣＳ）シーケンスを用いて各端末を区別する。ＣＱＩ情報シンボルはＳＣ−ＦＤＭＡシンボル全体に変調されて伝達され、ＳＣ−ＦＤＭＡシンボルは一つのシーケンスで構成されている。すなわち、端末は各シーケンスにＣＱＩを変調して送信する。

【0075】

一つのＴＴＩに送信可能なシンボル数は１０個であり、ＣＱＩ情報の変調はＱＰＳＫまで定められている。ＳＣ−ＦＤＭＡシンボルに対してＱＰＳＫマッピングを用いる場合、２ビットのＣＱＩ値を乗せ得るため、１スロットに１０ビットのＣＱＩ値を乗せることができる。したがって、１サブフレームに最大２０ビットのＣＱＩ値を乗せることができる。ＣＱＩ情報を周波数領域において拡散するために周波数領域拡散符号を用いる。

【0076】

周波数領域拡散符号としては長さ１２のＣＡＺＡＣシーケンス（例えば、ＺＣシーケンス）を用いることができる。各制御チャネルは、互いに異なる循環シフト（ｃｙｃｌｉｃ ｓｈｉｆｔ）値を持つＣＡＺＡＣシーケンスを適用して区別することができる。周波数領域で拡散されたＣＱＩ情報にＩＦＦＴを行う。

【0077】

１２個の等間隔を持つ循環シフトによって１２個の互いに異なる端末を同一ＰＵＣＣＨ ＲＢ上で直交多重化することができる。一般ＣＰ場合に、ＳＣ−ＦＤＭＡシンボル１及び５上の（拡張されたＣＰ場合はＳＣ−ＦＤＭＡシンボル３上の）ＤＭＲＳシーケンスは、周波数領域上のＣＱＩ信号シーケンスに類似するが、ＣＱＩ情報のような変調が適用されない。

【数5】

【0078】

次に、改善された−ＰＵＣＣＨ（ｅ−ＰＵＣＣＨ）フォーマットについて説明する。ｅ−ＰＵＣＣＨはＬＴＥ−ＡシステムのＰＵＣＣＨフォーマット３に対応し得る。ＰＵＣＣＨフォーマット３を用いたＡＣＫ／ＮＡＣＫ送信にはブロック拡散（ｂｌｏｃｋ ｓｐｒｅａｄｉｎｇ）技法を適用することができる。

【0079】

ブロック拡散技法は、既存のＰＵＣＣＨフォーマット１系列又は２系列とは違い、制御信号送信をＳＣ−ＦＤＭＡ方式を用いて変調する方式である。図９に示すように、シンボルシーケンスをＯＣＣ（Ｏｒｔｈｏｇｏｎａｌ Ｃｏｖｅｒ Ｃｏｄｅ）を用いて時間領域（ｄｏｍａｉｎ）上で拡散して送信することができる。ＯＣＣを用いることによって同一ＲＢ上に複数個の端末の制御信号を多重化することができる。前述したＰＵＣＣＨフォーマット２の場合には一つのシンボルシーケンスを時間領域にわたって送信し、ＣＡＺＡＣシーケンスのＣＳ（ｃｙｃｌｉｃ ｓｈｉｆｔ）を用いて複数個の端末の制御信号を多重化するのに対し、ブロック拡散ベースのＰＵＣＣＨフォーマット（例えば、ＰＵＣＣＨフォーマット３）の場合には、一つのシンボルシーケンスを周波数領域にわたって送信し、ＯＣＣによる時間領域拡散を用いて複数個の端末の制御信号を多重化する。

【0080】

図９（ａ）では、１スロットの間に１シンボルシーケンスに長さ＝４（又は、拡散因子（ｓｐｒｅａｄｉｎｇ ｆａｃｔｏｒ、ＳＦ）＝４）のＯＣＣを用いて４個のＳＣ−ＦＤＭＡシンボル（すなわち、データ部分）を生成して送信する例示を示す。この場合、１スロットの間に３個のＲＳシンボル（すなわち、ＲＳ部分）を用いることができる。

【0081】

又は、図９（ｂ）では、１スロットの間に１シンボルシーケンスに長さ＝５（又は、ＳＦ＝５）のＯＣＣを用いて５個のＳＣ−ＦＤＭＡシンボル（すなわち、データ部分）を生成して送信する例示を示す。この場合、１スロットの間に２個のＲＳシンボルを用いることができる。

【0082】

図９の例示では、ＲＳシンボルを、特定循環シフト値が適用されたＣＡＺＡＣシーケンスから生成することができ、複数個のＲＳシンボルにわたって所定のＯＣＣが適用された（又は、乗算された）形態で送信することができる。また、図９の例示で、それぞれのＯＦＤＭシンボル（又は、ＳＣ−ＦＤＭＡシンボル）別に１２個の変調シンボルが用いられ、それぞれの変調シンボルはＱＰＳＫによって生成されるとすれば、１スロットで送信可能な最大ビット数は１２×２＝２４ビットとなる。したがって、２スロットで送信可能なビット数は総４８ビットとなる。このようにブロック拡散方式のＰＵＣＣＨチャネル構造を用いると、既存のＰＵＣＣＨフォーマット１系列及び２系列に比べて拡張された大きさの制御情報の送信が可能となる。

【0083】

ＡＣＫ／ＮＡＣＫ多重化方案
ＡＣＫ／ＮＡＣＫ多重化の場合に、複数個のデータユニットに対するＡＣＫ／ＮＡＣＫ応答の内容（ｃｏｎｔｅｎｔｓ）を、実際ＡＣＫ／ＮＡＣＫ送信で用いられるＡＣＫ／ＮＡＣＫユニットとＱＰＳＫ変調されたシンボルのうちの一つとの組合せ（ｃｏｍｂｉｎａｔｉｏｎ）によって識別することができる。例えば、一つのＡＣＫ／ＮＡＣＫユニットが２ビットサイズの情報を運ぶと仮定し、最大２個のデータユニットを受信すると仮定する。ここで、受信されたそれぞれのデータユニットに対するＨＡＲＱ確認応答は一つのＡＣＫ／ＮＡＣＫビットによって表現されると仮定する。このような場合、データを送信した送信端は、ＡＣＫ／ＮＡＣＫ結果を、下記の表４に示すように識別することができる。

【表4】

【0084】

上記表４で、ＨＡＲＱ−ＡＣＫ（ｉ）（ｉ＝０，１）は、データユニットｉに対するＡＣＫ／ＮＡＣＫ結果を示す。前述したように、最大２個のデータユニット（データユニット０及びデータユニット１）が受信されると仮定したため、上記表４では、データユニット０に対するＡＣＫ／ＮＡＣＫ結果はＨＡＲＱ−ＡＣＫ（０）で表示し、データユニット１に対するＡＣＫ／ＮＡＣＫ結果はＨＡＲＱ−ＡＣＫ（１）で表示する。上記表４で、ＤＴＸ（Ｄｉｓｃｏｎｔｉｎｕｏｕｓ Ｔｒａｎｓｍｉｓｓｉｏｎ）は、ＨＡＲＱ−ＡＣＫ（ｉ）に対応するデータユニットが送信されないことを示したり、又は受信端がＨＡＲＱ−ＡＣＫ（ｉ）に対応するデータユニットの存在を検出できないことを示す。

【数6】

【0085】

【数7】

【0086】

【数8】

【0087】

このようなＡＣＫ／ＮＡＣＫ多重化方式において基本的に全てのデータユニットに対して少なくとも一つのＡＣＫが存在する場合には、ＮＡＣＫとＤＴＸとを区別しなくてもよい（すなわち、上記表４でＮＡＣＫ／ＤＴＸと表現するように、ＮＡＣＫとＤＴＸとを結合（ｃｏｕｐｌｅ）してもよい）。なぜなら、ＮＡＣＫとＤＴＸとを区別して表現しようとする場合に発生し得る全てのＡＣＫ／ＮＡＣＫ状態（すなわち、ＡＣＫ／ＮＡＣＫ仮設（ｈｙｐｏｔｈｅｓｅｓ））を、ＡＣＫ／ＮＡＣＫユニットとＱＰＳＫ変調されたシンボルとの組合せだけでは反映することができないためである。一方、全てのデータユニットに対してＡＣＫが存在しない場合（すなわち、全てのデータユニットに対してＮＡＣＫ又はＤＴＸのみが存在する場合）には、ＨＡＲＱ−ＡＣＫ（ｉ）の中で一つのみが確実にＮＡＣＫ（すなわち、ＤＴＸと区別されるＮＡＣＫ）であることを示す一つの確実なＮＡＣＫの場合を定義することができる。このような場合、一つの確実なＮＡＣＫに該当するデータユニットに対応するＡＣＫ／ＮＡＣＫユニットは、複数個のＡＣＫ／ＮＡＣＫの信号を送信するために留保（ｒｅｓｅｒｖｅｄ）されてもよい。

【0088】

ＰＵＣＣＨピギーバック
既存の３ＧＰＰ ＬＴＥシステム（例えば、リリース−８）システムの上りリンク送信では、端末機のパワーアンプの効率的な活用のために、パワーアンプの性能に影響を及ぼすＰＡＰＲ（Ｐｅａｋ−ｔｏ−Ａｖｅｒａｇｅ Ｐｏｗｅｒ Ｒａｔｉｏ）特性やＣＭ（Ｃｕｂｉｃ Ｍｅｔｒｉｃ）特性に優れた単一搬送波送信を維持するようになっている。すなわち、既存のＬＴＥシステムのＰＵＳＣＨ送信の場合は、送信しようとするデータをＤＦＴ−プリコーディング（ｐｒｅｃｏｄｉｎｇ）して単一搬送波特性を維持し、ＰＵＣＣＨ送信の場合は、単一搬送波特性を有するシーケンスに情報を乗せて送信することによって単一搬送波特性を維持することができる。しかし、ＤＦＴ−プリコーディングをしたデータを周波数軸に不連続して割り当てたり、ＰＵＳＣＨとＰＵＣＣＨを同時に送信する場合には、このような単一搬送波特性が損なわれる。

【0089】

したがって、図１０のようにＰＵＣＣＨ送信と同一のサブフレームにＰＵＳＣＨ送信があ る場合、単一搬送波特性を維持するために、ＰＵＣＣＨで送信するＵＣＩ（ｕｐｌｉｎｋ ｃｏｎｔｒｏｌ ｉｎｆｏｒｍａｔｉｏｎ）情報をＰＵＳＣＨに乗せてデータと共に送信（Ｐｉｇｇｙｂａｃｋ）するようになっている。

【0090】

前述したとおり、既存のＬＴＥ端末は、ＰＵＣＣＨとＰＵＳＣＨを同時に送信できないことから、ＰＵＳＣＨが送信されるサブフレームではＵＣＩ（ＣＱＩ／ＰＭＩ、ＨＡＲＱ−ＡＣＫ、ＲＩなど）をＰＵＳＣＨ領域に多重化する方法を用いる。一例として、ＰＵＳＣＨを送信するように割り当てられたサブフレームでＣＱＩ及び／又はＰＭＩを送信しなければならない場合、ＵＬ−ＳＣＨデータとＣＱＩ／ＰＭＩとをＤＦＴ−拡散の前に多重化して、制御情報とデータを共に送信することができる。この場合、ＵＬ−ＳＣＨデータは、ＣＱＩ／ＰＭＩリソースを考慮してレート−マッチングを行う。また、ＵＬ−ＳＣＨデータをパンクチャリングしてＨＡＲＱ ＡＣＫ、ＲＩなどの制御情報をＰＵＳＣＨ領域に多重化することができる。

【0091】

Ｅｎｈａｎｃｅｄ−ＰＤＣＣＨ（ＥＰＤＣＣＨ）
リリース１１以降のＬＴＥシステムでは、ＣｏＭＰ（Ｃｏｏｒｄｉｎａｔｅ Ｍｕｌｔｉ Ｐｏｉｎｔ）、ＭＵ−ＭＩＭＯ（Ｍｕｌｔｉ Ｕｓｅｒ−Ｍｕｌｔｉｐｌｅ Ｉｎｐｕｔ Ｍｕｌｔｉｐｌｅ Ｏｕｔｐｕｔ）などによるＰＤＣＣＨの容量不足、及びセル間干渉（ｉｎｔｅｒ−ｃｅｌｌ ｉｎｔｅｒｆｅｒｅｎｃｅ）によるＰＤＣＣＨ性能減少などに対する解決策として、従来のＰＤＳＣＨ領域で送信され得るＥｎｈａｎｃｅｄ−ＰＤＣＣＨ（ＥＰＤＣＣＨ）が考慮されている。また、ＥＰＤＣＣＨでは、プリコーディング（ｐｒｅ−ｃｏｄｉｎｇ）利得などを得るために、既存のＣＲＳベースのＰＤＣＣＨと違い、ＤＭＲＳに基づいてチャネル推定を行うことができる。

【0092】

ＥＰＤＣＣＨ送信は、ＥＰＤＣＣＨ送信に用いられるＰＲＢ（Ｐｈｙｓｉｃａｌ Ｒｅｓｏｕｒｃｅ Ｂｌｏｃｋ）ペアの構成によって、局部型（ｌｏｃａｌｉｚｅｄ）ＥＰＤＣＣＨ送信と分散型（ｄｉｓｔｒｉｂｕｔｅｄ）ＥＰＤＣＣＨ送信とに分類できる。局部型ＥＰＤＣＣＨ送信は、一つのＤＣＩ送信に用いられるＥＣＣＥが周波数ドメインで隣接している場合を意味し、ビームフォーミング利得を得るために特定プリコーディングを適用することができる。例えば、局部型ＥＰＤＣＣＨ送信は、集合レベルに該当する個数の連続したＥＣＣＥに基盤することができる。一方、分散型ＥＰＤＣＣＨ送信は、一つのＥＰＤＣＣＨが周波数ドメインで分離されたＰＲＢペアで送信されることを意味し、周波数ダイバーシティ側面の利得がある。例えば、分散型ＥＰＤＣＣＨ送信は、周波数ドメインで分離されたＰＲＢペアのそれぞれに含まれた４個のＥＲＥＧからなるＥＣＣＥに基盤することができる。端末には、１つ又は２つのＥＰＤＣＣＨ ＰＲＢセットが上位層シグナリングなどによって設定（ｃｏｎｆｉｇｕｒｅｄ）されてもよく、各ＥＰＤＣＣＨ ＰＲＢセットは、局部型ＥＤＰＣＣＨ送信又は分散型ＥＰＤＣＣＨ送信のいずれかのためのものであってもよい。

【0093】

端末は、ＥＰＤＣＣＨを介して制御情報（ＤＣＩ）を受信／取得するために、既存ＬＴＥ／ＬＴＥ−Ａシステムにおけると類似の方法でブラインド復号を行うことができる。より詳しくは、端末は、設定された送信モードに該当するＤＣＩフォーマットのために、集合レベル別にＥＰＤＣＣＨ候補のセットに対して復号を試みる（モニタする）ことができる。ここで、モニタリングの対象となるＥＰＤＣＣＨ候補のセットをＥＰＤＣＣＨ端末特定探索空間と呼ぶことができ、この探索空間は集合レベル別に設定／構成されうる。また、集合レベルは、前述した既存ＬＴＥ／ＬＴＥ−Ａシステムとはやや異なり、サブフレームタイプ、ＣＰ長、ＰＲＢペアにおける可用リソース量などによって｛１，２，４，８，１６，３２｝が可能である。

【0094】

ＥＰＤＣＣＨが設定（ｃｏｎｆｉｇｕｒｅｄ）された端末の場合、ＰＲＢペアセットに含まれたＲＥはＥＲＥＧにインデクシングし、このＥＲＥＧをさらにＥＣＣＥ単位にインデクシングする。このインデクシングされたＥＣＣＥに基づいて探索空間を構成するＥＰＤＣＣＨ候補を決定し、ブラインド復号を行うことによって、制御情報を受信することができる。ここで、ＥＲＥＧは、既存ＬＴＥ／ＬＴＥ−ＡのＲＥＧに、ＥＣＣＥはＣＣＥに対応する概念であり、一つのＰＲＢペアは１６個のＥＲＥＧを含むことができる。

【0095】

ＥＰＤＣＣＨを受信した端末は、ＥＰＤＣＣＨに対する受信確認応答（ＡＣＫ／ＮＡＣＫ）をＰＵＣＣＨ上で送信することができる。このときに用いられるリソース、すなわち、ＰＵＣＣＨリソースのインデックスは、前述した式１と同様に、ＥＰＤＣＣＨ送信に用いられたＥＣＣＥのうちの最低ＥＣＣＥインデックスによって決定することができる。すなわち、次の式２で表現することができる。

【数9】

【0096】

【数10】

【0097】

ただし、上述した式２によって一律的にＰＵＣＣＨリソースインデックスを決定する場合にはリソース衝突の問題が発生しうる。例えば、２つのＥＰＤＣＣＨ ＰＲＢセットが設定される場合、各ＥＰＤＣＣＨ ＰＲＢセットにおけるＥＣＣＥインデクシングは独立しているため、各ＥＰＤＣＣＨ ＰＲＢセットにおける最低のＥＣＣＥインデックスが同一である場合がありうる。このような場合、ユーザ別にＰＵＣＣＨリソースの開始点を別にすることによって解決することもできるが、全てのユーザ別にＰＵＣＣＨリソースの開始点を別にすると、多いＰＵＣＣＨリソースを予約することにつながるため、非効率的である。また、ＥＰＤＣＣＨでは、ＭＵ−ＭＩＭＯのように、同一のＥＣＣＥ位置で複数ユーザのＤＣＩが送信されてもよいため、この点を考慮するＰＵＣＣＨリソース割り当て方法も必要である。このような問題を解決するために、ＡＲＯ（ＨＡＲＱ−ＡＣＫ Ｒｅｓｏｕｒｃｅ Ｏｆｆｓｅｔ）を導入している。ＡＲＯは、ＥＰＤＣＣＨを構成するＥＣＣＥインデックスのうちの最低ＥＣＣＥインデックス、及び上位層シグナリングで伝達されるＰＵＣＣＨリソースの開始オフセットに基づいて決定されるＰＵＣＣＨリソースを所定程度シフトさせることによって、ＰＵＣＣＨリソースの衝突を回避可能にさせる。ＡＲＯは、ＥＰＤＣＣＨを介して送信されるＤＣＩフォーマット１Ａ／１Ｂ／１Ｄ／１／２Ａ／２／２Ｂ／２Ｃ／２Ｄの２ビットで次の表５のように指示される。

【表5】

【0098】

基地局は、特定端末のために、上記の表５におけるＡＲＯ値のいずれかを指定した後、ＤＣＩフォーマットを用いて、当該特定端末に、ＰＵＣＣＨリソース決定時に使用するＡＲＯを知らせることができる。端末は、自身のＤＣＩフォーマットからＡＲＯフィールドを検出し、この値に基づいて決定されたＰＵＣＣＨリソースで受信確認応答を送信することができる。

【0099】

ＴＤＤにおいて受信確認応答の送信
一方、ＦＤＤの場合とは違い、ＴＤＤは、上りリンク（ＵＬ）と下りリンク（ＤＬ）とが周波数帯域上で分離されていないことから、一つの上りリンクサブフレームで複数個の下りリンクサブフレーム（のＰＤＳＣＨ）に対する受信確認応答を送信しなければならない場合が発生しうる。これについて、図１１を参照して説明する。図１１（ａ）には、ＴＤＤにおいて用いられる上りリンク−下りリンク構成（Ｕｐｌｉｎｋ−ｄｏｗｎｌｉｎｋ ｃｏｎｆｉｇｕｒａｔｉｏｎ）が、図１１（ｂ）には、ＴＤＤ上りリンク−下りリンク構成２における受信確認応答を示している。図１１を参照すると、ＴＤＤ上りリンク−下りリンク構成２では、上りリンクとして使用可能なサブフレームが２番、７番サブフレームに制限される。このため、８個の下りリンクサブフレーム（スペシャルサブフレームを含む）に対する受信確認応答を、２個の上りリンクサブフレーム（２番サブフレーム、７番サブフレーム）で送信する必要がある。そのために、次の表６のように、下りリンク関連セットインデックスが定義されている。

【表6】

【0100】

下りリンク関連セットＫは、各上りリンクサブフレームで

【数11】

の要素で構成され、Ｍ（ｂｕｎｄｌｉｎｇ ｗｉｎｄｏｗ ｓｉｚｅ）は、関連セットＫで受信確認応答を送信すべき下りリンクサブフレームの個数を意味する。上記の表６の各上りリンク−下りリンク構成において、第１行の数字は、現在の上りリンクサブフレームから何サブフレーム以前の下りリンクサブフレームであるかを指示する。例えば、上りリンク−下りリンク構成２の場合、図１１（ｂ）に示すように、２番サブフレームは、２番サブフレームから８，７，４，６番目以前のサブフレーム（すなわち、以前無線フレームの４番、５番、８番、６番）の受信確認応答を送信する。理解の便宜のために、各上りリンク−下りリンク構成における第２行には、第１行の数字によって指示されるサブフレームの番号を表示している。上りリンク−下りリンク構成２では、第２行には４，５，８，６が表示されているが、これは、２番サブフレームで受信確認応答を送信すべき下りリンクサブフレームの番号である。また、表６で、括弧（ ）は、以前無線フレームのサブフレームであることを、括弧［ ］は、現在無線フレームのサブフレームであることを、そして括弧無しの数字は、二番目以前の無線フレームのサーフフレームであることを意味する。

【0101】

制御情報がＰＤＣＣＨで送信される場合、ＴＤＤにおいて受信確認応答の送信のためのＰＵＣＣＨリソースは、次の式３によって割り当てることができる。

【数12】

【0102】

【数13】

【0103】

図１２には、上記の式に基づくＰＵＣＣＨリソース割り当ての例示を示す。図１２では、３個の下りリンクサブフレーム（１ｓｔ ｓ．ｆ、２ｎｄ ｓ．ｆ、３ｒｄ ｓ．ｆ）に対する受信確認応答のためのリソースを割り当て、３個のＣＣＥグループ（ＣＣＥ ｇｒｏｕｐ １〜３、およそグループ当たり１個のＯＦＤＭシンボル）が存在すると仮定した。図１２に示すように、上りリンクサブフレームにおいて各下りリンクサブフレームのためのＰＵＣＣＨリソース割り当ては、一番目のＣＣＥグループ（ＣＣＥ ｇｒｏｕｐ １）において３個の下りリンクサブフレームのためのＰＵＣＣＨリソースを順次に割り当て／スタック（ｓｔａｃｋ）／パッキング（ｐａｃｋｉｎｇ）する。そして、二番目、三番目のＣＣＥグループに対しても、同様の方法でＰＵＣＣＨリソースを割り当てる。このため、下りリンクサブフレームが異なると、ＣＣＥインデックスが同一であっても、互いに異なるＰＵＣＣＨリソースを有し、衝突が発生しない。また、一つの下りリンクサブフレームでは互いに異なる端末に同一のＣＣＥインデックスのＰＤＣＣＨを送信せず、衝突は発生しない。

【0104】

【数14】

【0105】

【数15】

【0106】

上りリンクサブフレームの下りリンクサブフレームへの切替え（ｅｎｈａｎｃｅｄ Ｉｎｔｅｒｆｅｒｅｎｃｅ Ｍａｎａｇｅｍｅｎｔ ａｎｄ Ｔｒａｆｆｉｃ Ａｄａｐｔａｔｉｏｎ、ｅＩＭＴＡ）
ＴＤＤの場合、各サブフレーム（上りリンク−下りリンク間の切替えのための特殊サブフレームを除く）は、それぞれが上りリンク又は下りリンクのいずれかのために用いられるようにあらかじめ設定されている。具体的に、例えば、下記の表７を参照すると、上りリンク−下りリンク構成（Ｕｐｌｉｎｋ−Ｄｏｗｎｌｉｎｋ ｃｏｎｆｉｇｕｒａｔｉｏｎ）０の場合、一つの無線フレームにおいて、０，５番サブフレームは下りリンクのために用いられるように、２，３，４，７，８，９番サブフレームは上りリンクのために用いられるようにあらかじめ設定されている。ある特定基地局が用いる上りリンク−下りリンク構成は、システム情報（例えば、ＳＩＢ １）の一部として端末に提供することができる。そして、隣接した基地局には、干渉などの理由から、同一のＴＤＤ構成、すなわち、上りリンク−下りリンク構成を用いるように強制することができる。

【表7】

【0107】

上記の表７のように、上りリンク−下りリンク設定によってシステムが運営される場合にも、各セルにおいて上りリンク又は下りリンクで送信されるデータの量が急増する場合、このようなデータの円滑な送信のために、上りリンクと設定された一つ以上のサブフレームを下りリンクのためのものに変更して使用したり、逆に、下りリンクと設定された一つ以上のサブフレームを上りリンクのためのものに変更／切替えして使用することによって、効率性を上げることができる。

【0108】

上りリンクサブフレームから下りリンクサブフレームへの切替えは、次の表８中の陰影で表示されたサブフレームで可能である。ただし、表８ではスイッチング区間（ｓｗｉｔｃｈｉｎｇ ｐｅｒｉｏｄ）の変更を許容する場合を示しており、スイッチング区間の変更が不可能な場合、下りリンクに切り替えて使用可能なサブフレームは、表９に陰影で表示されている。

【表8】

【表9】

【0109】

また、上りリンクサブフレームの下りリンクサブフレームへの切替えは、既存のＴＤＤ構成を満たすものとなるように設定することができる。言い換えると、動的にサブフレームの用途を切り替えると、切り替えた後のＴＤＤ上りリンク−下りリンク構成が、表７の構成のいずれか一つでなければならないことを意味する。例えば、上りリンク−下りリンク構成０において４番サブフレームを下りリンクサブフレームに切り替える場合、９番サブフレームも同時に下りリンクサブフレームに切り替えなければならないということを意味する。この場合、上りリンク−下りリンク構成の変更有無を１ビットで知らせることができるという利点がある。

【0110】

上述したように、ＳＩＢなどで受信した上りリンク−下りリンク構成において、上りリンクサブフレームを下りリンクサブフレームに切り替えて（逆の場合も含む）用いる場合、ＨＡＲＱタイムラインは、既存ＴＤＤにおける上りリンク−下りリンク構成のいずれか一つを用いることができる。すなわち、動的にリソースが変更されるサブフレームが存在するシステムにおいてＨＡＲＱ（参照）タイムライン（ＨＡＲＱ ｒｅｆｅｒｅｎｃｅ ｔｉｍｅｌｉｎｅ、ＤＬ ｒｅｆｅｒｅｎｃｅ ＨＡＲＱ ｔｉｍｅｌｉｎｅ、又はＤＬ ｒｅｆｅｒｅｎｃｅ ＵＬ／ＤＬ ｃｏｎｆｉｇｕｒａｔｉｏｎと呼ぶこともできる。以下、ＤＬ参照ＨＡＲＱタイムラインという。）を定義することができる。ＨＡＲＱ参照タイムラインは、動的にリソースが変更される場合にも、それにかかわらずに動作するＨＡＲＱタイミングのためのＴＤＤ構成であってもよく、又は、現在動的にリソースが変更された状況のＴＤＤ構成であってもよい。

【0111】

すなわち、端末には次のようなタイムラインを設定することができる。ｉ）ＳＩＢで指示した上りリンク−下りリンク構成に対するＨＡＲＱタイムライン、ii）特定時点で受信したＰＤＳＣＨ／ＰＤＣＣＨ ｆｏｒ ＳＰＳ ｒｅｌｅａｓｅに対するＨＡＲＱ−ＡＣＫをいつ送信するかに関するＤＬ参照ＨＡＲＱタイムライン（互いに異なるＴＤＤ構成に対する搬送波併合ではＤＬ参照ＨＡＲＱタイムラインを定義している。２つの構成搬送波（ＣＣ）に対して共通に受信確認応答を送信するためのＨＡＲＱタイムラインを設定し、両ＣＣのＨＡＲＱ−ＡＣＫを効果的に送信するためである。動的にリソース用途が変更されるシステムに対しても、これと類似の特徴を用いることができる。特定サブフレームが動的に用途が変更される場合、相対的に静的（ｓｔａｔｉｃ）な用途に用いられる上りリンクサブフレームに対してＨＡＲＱタイムラインを設定することによって、サブフレームの用途が動的に変更するシステムでも安定してＨＡＲＱ ＡＣＫを送信することができる）、iii ）特定時点で受信したＵＬ ｇｒａｎｔに対するＰＵＳＣＨをいつ送信するか、そして特定時点で送信したＰＵＳＣＨに対するＰＨＩＣＨをいつ受信するかに関連したＵＬ参照ＨＡＲＱタイムライン（安定したＰＨＩＣＨ（ＰＵＳＣＨ Ａ／Ｎ）の送受信のためには、上りリンクサブフレームが最も多い場合のＴＤＤ ｃｏｎｆｉｇｕｒａｔｉｏｎに対してＵＬ参照ＨＡＲＱタイムラインを設定することができる）、iv）別途のシグナリングで設定した下りリンクサブフレーム別の独立したＨＡＲＱタイムライン（動的リソース用途変更が上位レイヤ信号によって指示され、その用途変更が実際に実行される時点との間には遅延が存在する。遅延区間内の特定ＳＦは、ＨＡＲＱタイムラインに対する曖昧さが発生しうる。このような例外的なＳＦは、上述したＨＡＲＱタイムライン以外の別に指示されたサブフレームでＨＡＲＱ ＡＣＫを送信する。このような動作がいずれの端末には指示されない可能性があり、このような端末が存在する場合、ＰＵＣＣＨリソース割り当て方式が決定されなければならない）

【0112】

一つのセル内で端末は、ｉ）いずれも同一の、ＳＩＢ基準のタイムラインに従うこともでき、ii）第１属性の端末（例えば、ｅＩＭＴＡ能力（ｃａｐａｂｉｌｉｔｙ）のない端末又はＬｅｇａｃｙ ＵＥ、以下、Ｌ−ＵＥと称する）は、ＳＩＢ基準のタイムラインを、第２属性の端末（例えば、ｅＩＭＴＡ能力（ｃａｐａｂｉｌｉｔｙ）のある端末又はａｄｖａｎｃｅｄ ＵＥ、以下、Ａ−ＵＥと称する）は、新しく定義されるＨＡＲＱタイムラインに従うこともできる。また、iii ）全ての端末が、ＳＩＢ以外の新しく定義されるＨＡＲＱタイムラインに従うこともできる。これらの場合のうち、Ｌ−ＵＥとＡ−ＵＥとが異なったタイムラインを用いる場合、ＰＵＣＣＨリソースに衝突が発生しうる。

【0113】

上述したように、一つの上りリンクサブフレームで受信確認応答を送信しなければならない下りリンクサブフレームのためにＰＵＣＣＨリソースがあらかじめ予約されているため、一つのタイムラインのみを用いる場合には衝突が発生しない。しかし、上記の例示のように、Ｌ−ＵＥとＡ−ＵＥとが異なったＨＡＲＱタイムラインを用いると、衝突が発生しうる。例えば、次の表１０のように、Ｌ−ＵＥが上りリンク−下りリンク構成１をＨＡＲＱタイムライン（第１タイムライン）として、Ａ−ＵＥが上りリンク−下りリンク構成２をＨＡＲＱタイムライン（第２タイムライン）として用いる場合、２番上りリンクサブフレームで受信確認応答を送信しなければならない下りリンクサブフレーム（Ｌ−ＵＥは５，６番下りリンクサブフレームの受信確認応答を、Ａ−ＵＥは４，５，８，６番下りリンクサブフレームの受信確認応答を送信しなければならない）が互いに異なる。このため、図１４に示すように、互いに異なる下りリンクサブフレームに対するＣＣＥ／ＥＣＣＥインデックスを同一のＰＵＣＣＨリソース領域で用いることになり、ＰＵＣＣＨリソースに衝突が発生しうる。

【表10】

【0114】

そこで、以下、このようなＰＵＣＣＨリソース衝突を防止するための方法について説明する。

【0115】

実施例１−１
ＴＤＤシステムにおいて、端末がサブフレームｎで下りリンク信号を受信した場合、該下りリンクサブフレームからｋ番目のサブフレームで、下りリンク信号に対する受信確認応答を送信しなければならない。ここで、ｅＩＭＴＡが適用され、Ｌ−ＵＥとＡ−ＵＥに互いに異なるタイムラインが設定される場合、ｋ番目のサブフレームで受信確認応答のためのリソースは、第１タイムライン（Ｌ−ＵＥのためのタイムラインであってもよい。ＳＩＢ１で伝達することができる）と第２タイムライン（Ａ−ＵＥのためのタイムラインであってもよい）に共通するサブフレームに優先的に割り当て／スタッキング（ｓｔａｃｋｉｎｇ）／パッキング（ｐａｃｋｉｎｇ）することができる。言い換えると、ｋ番目のサブフレームで受信確認応答のためのリソースは、第１タイムラインに従う場合に上記ｋ番目のサブフレームで受信確認応答を送信すべき下りリンクサブフレーム、及び第２タイムラインに従う場合に上記ｋ番目のサブフレームで受信確認応答を送信すべき下りリンクサブフレームのうち共通する、第１グループのサブフレームに優先的に割り当てられる。

【0116】

例えば、表１１及び図１５を参照すると、第１タイムラインとして上りリンク−下りリンク構成０、第２タイムラインとして上りリンク−下りリンク構成２を用い、２番上りリンクサブフレームで受信確認応答を送信するとすれば、第１タイムラインに従う場合に２番上りリンクサブフレームで受信確認応答を送信すべき６番下りリンクサブフレーム及び第２タイムラインに従う場合に２番上りリンクサブフレームで受信確認応答を送信すべき４，５，８，６番下りリンクサブフレームのうち共通する６番下りリンクサブフレームのためのＰＵＣＣＨリソースを、優先的に割り当てることができる。図１５を参照すると、共通する６番下りリンクサブフレームのためのＰＵＣＣＨリソースが優先して割り当てられていることがわかる。参考として、図１５（ａ）はＰＤＣＣＨによって下りリンク信号を受信した場合を、図１５（ｂ）はＥＰＤＣＣＨによって下りリンク信号を受信した場合を示す。

【表11】

【0117】

その後、残ったリソースの少なくとも一部は、第２タイムラインに従う場合、サブフレームで受信確認応答を送信すべきサブフレームのうち、共通するサブフレーム以外の第２グループのサブフレームに割り当てることができる。このとき、第２グループのサブフレームに割り当てられるリソースは、第１グループのサブフレームに割り当てられたリソースに連続してもよく、一定のオフセットだけ離隔してもよい。又は、第２グループのサブフレームに割り当てられるリソースは、第１グループのサブフレームの受信確認応答を送信するＰＵＣＣＨフォーマットと異なるＰＵＣＣＨフォーマットのためのリソースに含まれてもよい。例えば、第２グループのサブフレームのためのＰＵＣＣＨリソースは、（常に）ＰＵＣＣＨフォーマット３で送信されてもよい。

【0118】

上記第２グループのサブフレームをより細分化し、下りリンクサブフレームの性質（固定（ｆｉｘｅｄ）／静的（ｓｔａｔｉｃ）又はフレキシブル（ｆｌｅｘｉｂｌｅ））によってリソースを順次に割り当ててもよい。ここで、固定／静的サブフレームとは、上記第１タイムラインに従う場合、下りリンクサブフレーム又はスペシャルサブフレームの一つに該当するサブフレームであってもよい。又は、Ａ−ＵＥのＤＬ参照ＨＡＲＱタイムラインとは違い、該当の上りリンクサブフレームでＡ／Ｎを送信しないＳＦと解釈することもできる。そして、フレキシブルサブフレームは、第１タイムラインにおいても下りリンクサブフレーム又はスペシャルサブフレームと指示されないサブフレームを意味することができる。また、ｆｌｅｘｉｂｉｌｉｔｙが大きいということは、連続した上りリンクサブフレームのうち、サブフレーム番号がより大きいサブフレームを意味する。ＰＵＣＣＨリソースを、２つのグループのサブフレームのうち、固定／静的サブフレームに優先的に割り当てた後、フレキシブルサブフレームに順次に割り当てることができる。また、フレキシブルサブフレームのうち、ｆｌｅｘｉｂｉｌｉｔｙが小さいサブフレームに、ｆｌｅｘｉｂｉｌｉｔｙが大きいサブフレームよりも優先してＰＵＣＣＨリソースを割り当てることができる。この場合、同じ性質を有し、ＰＤＣＣＨで設定されたサブフレームのＰＵＣＣＨリソースは、ＯＦＤＭシンボル別にインターリービングされてもよい。

【0119】

例えば、再び表１１及び図１５を参照すると、第１タイムラインと第２タイムラインに共通する６番下りリンクサブフレームに、受信確認応答のためのリソースを優先的に割り当てた後、残りの４，５，８番下りリンクサブフレームに、受信確認応答のためのリソースを割り当てることができる。ここで、４，５，８番下りリンクサブフレームのうち、固定／静的サブフレームである５番サブフレームにまずＰＵＣＣＨリソースを割り当て、続いてフレキシブルサブフレームである４，８番下りリンクサブフレームにＰＵＣＣＨリソースを割り当てることができる。前述したように、ＰＤＣＣＨで設定されたサブフレームのＰＵＣＣＨリソースは、図１５（ａ）に示すようにインターリービングされてもよい。

【0120】

実施例１は、バンドリングウィンドウ内で、Ａ−ＵＥの下りリンクサブフレームのうち、Ｌ−ＵＥと共通する下りリンクサブフレームは暗黙的ＰＵＣＣＨリソースマッピング（ｉｍｐｌｉｃｉｔ ＰＵＣＣＨ ｒｅｓｏｕｒｃｅ ｍａｐｐｉｎｇ）方式（ＣＣＥ／ＥＣＣＥ ｉｎｄｅｘ）を用い、Ａ−ＵＥにのみＰＤＳＣＨがスケジュールされるか又はＳＰＳリリースのためのＰＤＣＣＨが送信される下りリンクサブフレームに対して（すなわち、Ｌ−ＵＥと共通しない下りリンクサブフレームに対して）、ＰＵＣＣＨリソースは明示的（ｅｘｐｌｉｃｉｔ）な方式（上位レイヤ信号で指示された領域のＰＵＣＣＨリソース：これは、ＰＵＣＣＨ ｆｏｒｍａｔ ３を用いることを意味してもよく、上位レイヤでＡ−ＵＥにＬ−ＵＥと共通のＰＵＣＣＨリソース開始オフセットの他、追加のＰＵＣＣＨリソース開始オフセットを割り当てた場合を意味してもよい。）を用いてＰＵＣＣＨリソース位置を指定することと理解することもできる。

【0121】

実施例１によってＰＵＣＣＨリソースを次のように割り当てることができる。ここで、Ａ−ＵＥとＬ−ＵＥ間のＰＵＣＣＨリソース衝突を防止するために、Ｌ−ＵＥは既存の方式でＰＵＣＣＨリソースをパッキングする。Ａ−ＵＥは、Ｌ−ＵＥとｉ）共通の下りリンクサブフレームに対してまずパッキングを行った後、Ａ−ＵＥのみをモニタリングする下りリンクサブフレームをＬ−ＵＥのパッキングウィンドウに連接してパックキングする。ii）このとき、Ａ−ＵＥのＳＦに固定下りリンクサブフレームとフレキシブル下りリンクサブフレームとが混在する場合、フレキシブルサブフレームは固定下りリンクサブフレームのＰＵＣＣＨ領域の後にパックキングすることが好ましい。iii ）また、フレキシブルＳＦのうち、サブフレーム番号が大きいＳＦがよりフレキシブルであるため（連続した上りリンクサブフレームがあるとき、前のＵＬのみを単独でＤＬに変更することができないためである。ＵＵＵ→ＵＵＤは可能、ＵＵＵ→ＤＵＵは不可能）、ｆｌｅｘｉｂｉｌｉｔｙがより大きいサブフレーム（例えば、連続した上りリンクサブフレームのうち、サブフレーム番号がより大きいサブフレーム）を、ＰＵＣＣＨ領域のパッキング時に後順位として配置する。iv）同じ性質（ｆｌｅｘｉｂｌｅ ｏｒ ｓｔａｔｉｃ）を有するサブフレームであり、ＰＤＣＣＨで設定されたサブフレームのＰＵＣＣＨリソースは、ＯＦＤＭシンボル別にインターリービングすることができる。ただし、これはＰＤＣＣＨに限定されてもよい。例えば、Ａ−ＵＥのみがパックキングするサブフレームのうち、固定下りリンクサブフレーム同士或いはフレキシブルサブフレーム同士をＰＤＣＣＨシンボル別に優先してパッキングすることができる。このようなルールを有すると、Ａ−ＵＥとＬ−ＵＥ間のＰＵＣＣＨリソース衝突を防止することができ、Ａ−ＵＥがフレキシブルＳＦを後に配置することによって、フレキシブルサブフレームをモニタリングしなかったとき、ＰＵＣＣＨ領域を減らすことができる。上記の説明において一部（特定ｓｕｂｓｅｔ）のみが選択的にＡ−ＵＥに適用されてもよい。或いは、ＰＤＣＣＨとＥＰＤＣＣＨが適用する規則は互いに異なってもよい。例えば、上記の説明のうちｉ）のみがＡ−ＵＥに適用されてもよい。

【0122】

実施例１−２
この実施例は、ＤＡＩ（Ｄｏｗｎｌｉｎｋ Ａｌｌｏｃａｔｉｏｎ Ｉｎｄｅｘ）を用いて、上りリンクサブフレームの下りリンクサブフレームへの変更があることを知らせ、Ｌ−ＵＥは、Ａ−ＵＥと同一の数の下りリンクサブフレームが割り当てられると仮定してＰＵＣＣＨリソースを割り当てる。さらにいうと、基地局は、Ｌ−ＵＥがスケジュールされるＰＤＣＣＨ／ＥＰＤＣＣＨにおいてＤＡＩを、Ａ−ＵＥと同一のＴＤＤ上りリンク−下りリンク構成を基準に割り当てる。この場合、Ｌ−ＵＥは、用途変更されたサブフレームを、逃したサブフレームと判断するようになり、ＰＵＣＣＨリソースの割り当ては、Ｌ−ＵＥ及びＡ−ＵＥが同一の上りリンク−下りリンク構成を用いる。この方式は、Ｌ−ＵＥ、Ａ−ＵＥ両方とも第２タイムラインに対してＨＡＲＱ動作を行うようにし、ＰＵＣＣＨリソース衝突を一部避けることができる。この方式はすなわち、ＰＵＣＣＨ ｆｏｒｍａｔ１ｂ ｗｉｔｈ ｃｈａｎｎｅｌ ｓｅｌｅｃｔｉｏｎにおいてＬ−ＵＥが第２タイムラインを基準にｃｈａｎｎｅｌ ｓｅｌｅｃｔｉｏｎ ｔａｂｌｅを適用することを意味する。ただし、Ｌ−ＵＥが余分のＤＴＸを送信するか、一つの上りリンクサブフレームに連動した下りリンクサブフレームの個数が実際に４を越えていないにもかかわらず、ＰＵＣＣＨフォーマット３を用いたりＡ／Ｎバンドリングを行うといった短所がある。例えば、表１２の例示で、２番上りリンクサブフレームにおいてＬ−ＵＥ、Ａ−ＵＥ両方とも、同じＭ＝４のときのＡ／Ｎテーブルを用いるが、Ｌ−ＵＥは、下りリンクサブフレームのうち４と８を常にＤＴＸと処理し、表１３で陰影処理された部分は使用しなくてもよい。

【表12】

【表13】

【0123】

実施例１−３
この実施例は、ＰＵＣＣＨリソース割り当て時に、Ａ−ＵＥとＬ−ＵＥにＰＵＣＣＨ開始オフセット（ＰＵＣＣＨ ｓｔａｒｔｉｎｇ ｏｆｆｓｅｔ）を別々に割り当てる。このとき、ＰＵＣＣＨ開始オフセットは、上位層シグナリングなどで伝達することができる。

【0124】

実施例１−４
この実施例は、特定上りリンクサブフレームで、Ｌ−ＵＥが受信確認応答を送信すべき下りリンクサブフレームが、Ａ−ＵＥが受信確認応答を送信すべき下りリンクサブフレームにおいて連続したサブセットである場合に関する。この場合、Ａ−ＵＥとＬ−ＵＥにＰＵＣＣＨ開始オフセットは同一に割り当てるが、Ａ−ＵＥのうち、サブフレームの用途変更指示を検出した端末は、該当の上りリンクサブフレームと連動した下りリンクサブフレームの個数（すなわち、上りリンクサブフレームで受信確認応答を送信すべき下りリンクサブフレームの個数）がＬ−ＵＥと異なる場合、その差によるＣＣＥインデックスを演算し、追加のオフセット（ＰＵＣＣＨ ｒｅｓｏｕｒｃｅ ｓｔａｃｋｉｎｇ ｏｆｆｓｅｔ）を適用することができる。Ａ−ＵＥにさらに割り当てられた下りリンクサブフレームに含まれたＣＣＥ／ＥＣＣＥ個数の分をオフセットとして適用することができ、上位層で伝達されたサブフレーム用途変更指示を、このオフセットのインジケータ（ｉｎｄｉｃａｔｏｒ）として用いることができる。

【0125】

【数16】

【0126】

実施例１−４は、実施例１−３と比較して、基本的にＡ−ＵＥとＬ−ＵＥのＰＵＣＣＨオフセットを異なるように割り当ててＰＵＣＣＨリソース衝突を避けるという点では一致するが、Ａ−ＵＥがサブフレームの用途変更動作を検出できない場合にもＰＵＣＣＨリソース衝突を避けることができるという長所がある。

【0127】

実施例１−５
Ａ−ＵＥが、第１タイムラインと第２タイムラインで共通していない下りリンクサブフレームに対してタイムバンドリング（ｔｉｍｅ ｂｕｎｄｌｉｎｇ）を行うことによって、ＰＵＣＣＨリソース衝突を解決することもできる。すなわち、Ａ−ＵＥは、常にＡ／Ｎタイムバンドリングを行ってＬ−ＵＥの下りリンクサブフレーム個数と一致させ、Ａ−ＵＥの下りリンクサブフレームのうち、Ｌ−ＵＥと重なる下りリンクサブフレームに対するＣＣＥ／ＥＣＣＥインデックスを用いて、受信確認応答のためのリソースを割り当てることができる。このとき、ＰＵＣＣＨリソースインデックスは、Ｌ−ＵＥの下りリンクサブフレームを基準に定めることができる。タイムバンドリングはｌｏｇｉｃａｌ ＡＮＤ動作であってもよい。

【0128】

表１２を取り上げて説明すると、Ａ−ＵＥは、２番上りリンクサブフレームにおいてＬ−ＵＥのタイムライン上で受信確認応答を送信しなければならない５，６番下りリンクサブフレームと重ならない、４，８番下りリンクサブフレームのための受信確認応答をバンドリングすることができる。すなわち、４，５番下りリンクサブフレームの受信確認応答と６，８番下りリンクサブフレームの受信確認応答に対してバンドリングを行い、４，５番下りリンクサブフレームのバンドリングされた値は、５番ＳＦのＣＣＥ／ＥＣＣＥインデックス位置に、６，８番下りリンクサブフレームのバンドリングされた値は、６番ＳＦのＣＣＥ／ＥＣＣＥインデックス位置に割り当てることができる。

【0129】

実施例１−６
Ａ−ＵＥとＬ−ＵＥには、分離されたＰＵＣＣＨ領域が割り当てられてもよい。Ｌ−ＵＥ（又は、Ａ−ＵＥ）にはＰＵＣＣＨフォーマット３を割り当て、Ａ−ＵＥ（又はＬ−ＵＥ）にはＰＵＣＣＨフォーマット１／２／１ａ／１ｂ／２ａ／２ｂを割り当てることができる。又は、同じＰＵＣＣＨフォーマットにおいて開始オフセットのみを異なるように設定することもできる。この動作では、一つの上りリンクサブフレームにおいて連動した下りリンクサブフレームの個数は、Ａ−ＵＥとＬ−ＵＥにおいて別々に解釈され、ＰＤＣＣＨ／ＥＰＤＣＣＨのＤＡＩも、Ａ−ＵＥ及びＬ−ＵＥにそれぞれ割り当てられた下りリンクサブフレームに対してのみ指示される。

【0130】

実施例１−７
ＰＤＣＣＨで割り当てられた下りリンクサブフレームは、実施例１−１乃至１−６のいずれか一つを用いるが、ＥＰＤＣＣＨで割り当てられたＰＤＳＣＨに対する受信確認応答のためのリソースの決定にはＡＲＯを適用する。互いに異なる個数の下りリンクサブフレームがスタッキング（ｓｔａｃｋｉｎｇ）されても、ＰＵＣＣＨリソースの衝突をある程度避けることができる。

【0131】

実施例１−８
Ａ−ＵＥがフレキシブルサブフレームと指定したサブフレームに対する受信確認応答のためのリソースは、Ｌ−ＵＥのパッキングウィンドウの後に位置させる。言い換えると、Ｌ−ＵＥの第１タイムラインに従って上りリンクサブフレームで送信すべき下りリンクサブフレームのためのリソースをまず割り当て、その後、Ａ−ＵＥの第２タイムラインにのみ該当する下りリンクサブフレームのためのリソースを割り当てる。

【0132】

例えば、表１２を再び参照すると、Ａ−ＵＥは、４，５，８，６番下りリンクサブフレームに関連した受信確認応答のためのリソース割り当て時に、５，６，４，８番下りリンクサブフレームの順に受信確認応答のためのリソースを割り当てることができる。この場合、Ａ−ＵＥとＬ−ＵＥのＰＵＣＣＨリソース開始オフセットは同一に設定されても（されたものであっても）よい。

【0133】

実施例１−９
Ａ−ＵＥがフレキシブルサブフレームと指定したサブフレームは、ＡＣＫ／ＮＡＣＫパッキング時に、Ｌ−ＵＥのパッキングウィンドウの前に位置させることができる。例えば、表１２で、Ａ−ＵＥは、４，８，５，６番サブフレームの順序で受信確認応答のためのリソースを割り当て、Ｌ−ＵＥは５，６番サブフレームの順序で受信確認応答のためのリソースを割り当てることができる。このとき、Ａ−ＵＥのＰＵＣＣＨリソース開始オフセットは、Ｌ−ＵＥのそれよりも４，８番下りリンクサブフレームのＣＣＥ／ＥＣＣＥの個数分だけ前に位置する。

【0134】

実施例１−１０
Ａ−ＵＥは、Ｌ−ＵＥのタイムラインに従って受信確認応答のためのリソースをパックキングするが、このとき、Ｌ−ＵＥのタイムラインでは指示されるがＡ−ＵＥのタイムラインには存在しない下りリンクサブフレームに対するリソースを空にすることができる。その後、Ａ−ＵＥのタイムラインでのみ指示される下りリンクサブフレームの受信確認応答のためのリソースは、Ｌ−ＵＥのバンドリングウィンドウの後に位置させることができる。

【表14】

【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】

上述したような本発明の実施形態は、様々な移動通信システムに適用可能である。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】