(57)【特許請求の範囲】
【請求項１】
無線リソースの用途変更をサポートする無線通信システムにおいて端末の上りリンク制御チャネルを送信する方法であって、
第１タイプのサブフレームのための第１物理上りリンク制御チャネル（ＰＵＣＣＨ）リソース領域に基づいて設定された第２ＰＵＣＣＨリソース領域のためのオフセット情報を受信するステップであって、該第２ＰＵＣＣＨリソース領域は第２タイプのサブフレーム及び第３タイプのサブフレームと関連付けられる、ステップと、
前記オフセット情報によって指定された前記第２ＰＵＣＣＨリソース領域を用いて、少なくとも一つの下りリンクサブフレームに対するＡＣＫ／ＮＡＣＫを基地局に送信するステップと、
を有し、
前記第１タイプのサブフレームは、ｅＩＭＴＡ端末及びｎｏｎ−ｅＩＭＴＡ端末に対して同じＨＡＲＱタイミングを有して、前記無線リソースの用途が固定され、
前記第２タイプのサブフレームは、ｅＩＭＴＡ端末及びｎｏｎ−ｅＩＭＴＡ端末に対して別個のＨＡＲＱタイミングを有して、前記無線リソースの用途が固定され、
前記第３タイプのサブフレームは、前記無線リソースの用途が変更可能であり、
前記オフセット情報は、前記第２ＰＵＣＣＨリソース領域のためのオフセットが上位層シグナリングで指示されるか否か、或いは前記第２ＰＵＣＣＨリソース領域があらかじめ決定された設定によって定義されるか否かを示し、
前記オフセット情報は、１ビット指示子で表される、上りリンク制御チャネル送信方法。
【請求項２】
前記オフセット情報は、選択的情報要素で定義されたオフセットを含み、
前記オフセットが定義された場合、前記第２ＰＵＣＣＨリソース領域は上位層シグナリングで指示され、前記オフセットが定義されていない場合、前記第２ＰＵＣＣＨリソース領域は、あらかじめ決定された値によって決定される、請求項１に記載の上りリンク制御チャネル送信方法。
【請求項３】
前記オフセット情報は、前記第２ＰＵＣＣＨリソース領域のためにあらかじめ定義された基本値を含み、
前記第２ＰＵＣＣＨリソース領域のためのオフセットが上位層シグナリングで指示されない場合、前記第２ＰＵＣＣＨリソース領域のためのオフセットは、前記基本値と定義される、請求項１に記載の上りリンク制御チャネル送信方法。
【請求項４】
前記基本値は、前記第１ＰＵＣＣＨリソース領域と連動された前記第１タイプのサブフレームのうち、下りリンクサブフレーム及び特別サブフレームのための制御チャネル要素の総和と定義される、請求項３に記載の上りリンク制御チャネル送信方法。
【請求項５】
無線リソースの用途変更をサポートする無線通信システムにおいて上りリンク制御チャネルを送信する端末であって、
無線周波数ユニットと、
プロセッサと、
を備え、
前記プロセッサは、第１タイプのサブフレームのための第１物理上りリンク制御チャネル（ＰＵＣＣＨ）リソース領域に基づいて設定され、第２タイプのサブフレーム及び第３タイプのサブフレームと関連付けられた第２ＰＵＣＣＨリソース領域のためのオフセット情報を受信し、
前記オフセット情報によって指定された前記第２ＰＵＣＣＨリソース領域を用いて、少なくとも一つの下りリンクサブフレームに対するＡＣＫ／ＮＡＣＫを基地局に送信するように構成され、
前記第１タイプのサブフレームは、ｅＩＭＴＡ端末及びｎｏｎ−ｅＩＭＴＡ端末に対して同じＨＡＲＱタイミングを有して、前記無線リソースの用途が固定され、
前記第２タイプのサブフレームは、ｅＩＭＴＡ端末及びｎｏｎ−ｅＩＭＴＡ端末に対して別個のＨＡＲＱタイミングを有して、前記無線リソースの用途が固定され、
前記第３タイプのサブフレームは、前記無線リソースの用途が変更可能であり、
前記オフセット情報は、前記第２ＰＵＣＣＨリソース領域のためのオフセットが上位層シグナリングで指示されるか否か、或いは前記第２ＰＵＣＣＨリソース領域があらかじめ決定された設定によって定義されるか否かを示し、
前記オフセット情報は、１ビット指示子で表される、端末。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線通信システムに関し、特に、無線リソースの用途変更をサポートする無線通信システムで上りリンク制御チャネルの送信方法及びそのための装置に関する。
【背景技術】
【０００２】
本発明を適用できる無線通信システムの一例として、３ＧＰＰＬＴＥ（３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ  Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ；以下、「ＬＴＥ」という。）通信システムについて概略的に説明する。
【０００３】
図１は、無線通信システムの一例としてＥ−ＵＭＴＳネットワーク構造を概略的に示す図である。Ｅ−ＵＭＴＳ（Ｅｖｏｌｖｅｄ  Ｕｎｉｖｅｒｓａｌ  Ｍｏｂｉｌｅ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｓｙｓｔｅｍ）は、既存のＵＭＴＳ（Ｕｎｉｖｅｒｓａｌ  Ｍｏｂｉｌｅ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｓｙｓｔｅｍ）から進展したシステムであり、現在３ＧＰＰで基礎的な標準化作業が進行中である。一般に、Ｅ−ＵＭＴＳをＬＴＥ（Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）システムと呼ぶこともできる。ＵＭＴＳ及びＥ−ＵＭＴＳの技術規格（ｔｅｃｈｎｉｃａｌ  ｓｐｅｃｉｆｉｃａｔｉｏｎ）の詳細な内容はそれぞれ、「３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ；Ｔｅｃｈｎｉｃａｌ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ  Ｇｒｏｕｐ  Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ」のＲｅｌｅａｓｅ７及びＲｅｌｅａｓｅ８を参照することができる。
【０００４】
図１を参照すると、Ｅ−ＵＭＴＳは、端末（Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ；ＵＥ）、基地局（ｅＮｏｄｅＢ；ｅＮＢ）、及びネットワーク（Ｅ−ＵＴＲＡＮ）の終端に位置して外部ネットワークに接続するアクセスゲートウェイ（Ａｃｃｅｓｓ  Ｇａｔｅｗａｙ；ＡＧ）を含んでいる。基地局は、ブロードキャストサービス、マルチキャストサービス及び／又はユニキャストサービスのために多重データストリームを同時に送信することができる。
【０００５】
一つの基地局には一つ以上のセルが存在する。セルは、１．４４、３、５、１０、１５、２０ＭＨｚなどの帯域幅のいずれか一つに設定され、複数の端末に下り又は上り送信サービスを提供する。異なったセルは、互いに異なった帯域幅を提供するように設定することができる。基地局は、複数の端末に関するデータ送受信を制御する。下りリンク（Ｄｏｗｎｌｉｎｋ；ＤＬ）データについて、基地局は、下りリンクスケジューリング情報を送信し、該当の端末にデータが送信される時間／周波数領域、符号化、データサイズ、ＨＡＲＱ（Ｈｙｂｒｉｄ  Ａｕｔｏｍａｔｉｃ  Ｒｅｐｅａｔ  ａｎｄ  ｒｅＱｕｅｓｔ）関連情報などを知らせる。また、上りリンク（Ｕｐｌｉｎｋ；ＵＬ）データについて、基地局は、上りリンクスケジューリング情報を該当の端末に送信し、該当の端末が使用可能な時間／周波数領域、符号化、データサイズ、ＨＡＲＱ関連情報などを知らせる。基地局同士の間には、ユーザトラフィック又は制御トラフィックの送信のためのインターフェースを用いることができる。コアネットワーク（Ｃｏｒｅ  Ｎｅｔｗｏｒｋ；ＣＮ）は、ＡＧ、及び端末のユーザ登録などのためのネットワークノードなどで構成することができる。ＡＧは、複数のセルで構成されるＴＡ（Ｔｒａｃｋｉｎｇ  Ａｒｅａ）単位に端末の移動性を管理する。
【０００６】
無線通信技術は、ＷＣＤＭＡに基づいてＬＴＥまで開発されているが、ユーザと事業者の要求と期待は増す一方である。その上、他の無線接続技術の開発が続いており、将来、競争力を持つためには新しい技術進化が要求される。ビット当たりのコストの削減、サービス可用性の増大、柔軟な周波数バンドの使用、単純構造と開放型インターフェース、端末の適度な電力消耗などが要求される。
【０００７】
端末は、基地局の無線通信システムの効率的な運用を補助するために、現在チャネルの状態情報を基地局に周期的及び／又は非周期的に報告する。このように報告されるチャネルの状態情報は、様々な状況を考慮して計算された結果を含み得ることから、より効率的な報告方法が要求されている実情である。
【発明の概要】
【発明が解決しようとする課題】
【０００８】
上述したような議論に基づき、以下では、無線リソースの用途変更をサポートする無線通信システムで上りリンク制御チャネルの送信方法及びそのための装置を提案する。
【０００９】
本発明で遂げようとする技術的課題は、上記の技術的課題に制限されず、言及していない他の技術的課題は、以下の記載から、本発明の属する技術の分野における通常の知識を有する者には明確に理解されるであろう。
【課題を解決するための手段】
【００１０】
上述した問題点を解決するための本発明の一態様である、無線リソースの用途変更をサポートする無線通信システムにおいて端末の上りリンク制御チャネルを送信する方法は、第１タイプのサブフレームのための第１物理上りリンク制御チャネル（Ｐｈｙｓｉｃａｌ  Ｕｐｌｉｎｋ  Ｃｏｎｔｒｏｌ  ＣＨａｎｎｅｌ；ＰＵＣＣＨ）リソース領域に基づいて設定された、第２タイプのサブフレーム及び第３タイプのサブフレームと関連付いた第２ＰＵＣＣＨリソース領域のためのオフセット情報を受信するステップと、前記オフセット情報によって指定された前記第２ＰＵＣＣＨリソース領域を用いて、少なくとも一つの下りリンクサブフレームに対するＡＣＫ／ＮＡＣＫ（Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ／Ｎｅｇａｔｉｖｅ−ＡＣＫ）を基地局に送信するステップとを有し、前記第１タイプのサブフレームは、ｅＩＭＴＡ（ｅｎｈａｎｃｅｄ  ｉｎｔｅｒｆｅｒｅｎｃｅ  ｍａｎａｇｅｍｅｎｔ  ａｎｄ  ｔｒａｆｆｉｃ  ａｄａｐｔａｔｉｏｎ）端末及びｎｏｎ−ｅＩＭＴＡ（ｎｏｎ−ｅｎｈａｎｃｅｄ  ｉｎｔｅｒｆｅｒｅｎｃｅ  ｍａｎａｇｅｍｅｎｔ  ａｎｄ  ｔｒａｆｆｉｃ  ａｄａｐｔａｔｉｏｎ）端末に対して同じＨＡＲＱタイミングを有する、無線リソースの用途が固定されたサブフレームであり、前記第２タイプのサブフレームは、ｅＩＭＴＡ端末及びｎｏｎ−ｅＩＭＴＡ端末に対して別個のＨＡＲＱタイミングを有する、無線リソースの用途が固定されたサブフレームであり、前記第３タイプのサブフレームは、無線リソースの用途が変更可能なサブフレームであることを特徴とする。
【００１１】
また、前記オフセット情報は、前記第２ＰＵＣＣＨリソース領域のためのオフセットが上位層シグナリングで指示されるか否か、或いは前記第２ＰＵＣＣＨリソース領域があらかじめ決定された設定によって定義されるか否かを示すことを特徴とする。また、前記オフセット情報は１ビット指示子で表されることを特徴とする。
【００１２】
また、前記オフセット情報は、選択的情報要素（選択的情報要素）で定義されたオフセットを含み、前記オフセットが定義された場合、前記第２ＰＵＣＣＨリソース領域は上位層シグナリングで指示され、前記オフセットが定義されていない場合、前記第２ＰＵＣＣＨリソース領域は、あらかじめ決定された値によって決定されることを特徴とする。
【００１３】
また、前記オフセット情報は、前記第２ＰＵＣＣＨリソース領域のためにあらかじめ定義された基本値を含み、前記第２ＰＵＣＣＨリソース領域のためのオフセットが上位層シグナリングで指示されない場合、前記第２ＰＵＣＣＨリソース領域のためのオフセットは前記基本値と定義されることを特徴とする。また、前記あらかじめ定義された基本値は、前記第１ＰＵＣＣＨリソース領域と連動された前記第１タイプのサブフレームのうち、下りリンクサブフレーム及び特別サブフレームのための制御チャネル要素（Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ  Ｅｌｅｍｅｎｔ）の総和と定義されることを特徴とする。
【００１４】
上述した問題点を解決するための本発明の他の態様である、搬送波集成（Ｃａｒｒｉｅｒ  ａｇｇｒｅｇａｔｉｏｎ）及び無線リソースの用途変更をサポートする無線通信システムにおいて端末の上りリンク制御チャネルを送信する方法は、プライマリセル（ｐｒｉｍａｒｙ  ｃｅｌｌ）及びセカンダリセル（ｓｅｃｏｎｄａｒｙ  ｃｅｌｌ）に対するｅＩＭＴＡ（ｅｎｈａｎｃｅｄ  ｉｎｔｅｒｆｅｒｅｎｃｅ  ｍａｎａｇｅｍｅｎｔ  ａｎｄ  ｔｒａｆｆｉｃ  ａｄａｐｔａｔｉｏｎ）設定に基づいて、前記セカンダリセルのＰＵＣＣＨリソース割り当て方式を判断するステップと、前記ＰＵＣＣＨリソース割り当て方式によって決定されたＰＵＣＣＨリソースを用いて上りリンク制御チャネルを送信するステップとを有することができる。
【００１５】
上述した問題点を解決するための本発明の更に他の態様である、無線リソースの用途変更をサポートする無線通信システムにおいて上りリンク制御チャネルを送信する端末は、無線周波数ユニットと、プロセッサとを備え、前記プロセッサは、第１タイプのサブフレームのための第１物理上りリンク制御チャネル（Ｐｈｙｓｉｃａｌ  Ｕｐｌｉｎｋ  Ｃｏｎｔｒｏｌ  ＣＨａｎｎｅｌ；ＰＵＣＣＨ）リソース領域に基づいて設定された、第２タイプのサブフレーム及び第３タイプのサブフレームと関連付いた第２ＰＵＣＣＨリソース領域のためのオフセット情報を受信し、前記オフセット情報によって指定された前記第２ＰＵＣＣＨリソース領域を用いて、少なくとも一つの下りリンクサブフレームに対するＡＣＫ／ＮＡＣＫ（Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ／Ｎｅｇａｔｉｖｅ−ＡＣＫ）を基地局に送信するように構成され、前記第１タイプのサブフレームは、ｅＩＭＴＡ（ｅｎｈａｎｃｅｄ  ｉｎｔｅｒｆｅｒｅｎｃｅ  ｍａｎａｇｅｍｅｎｔ  ａｎｄ  ｔｒａｆｆｉｃ  ａｄａｐｔａｔｉｏｎ）端末及びｎｏｎ−ｅＩＭＴＡ（ｎｏｎ−ｅｎｈａｎｃｅｄ  ｉｎｔｅｒｆｅｒｅｎｃｅ  ｍａｎａｇｅｍｅｎｔ  ａｎｄ  ｔｒａｆｆｉｃ  ａｄａｐｔａｔｉｏｎ）端末に対して同じＨＡＲＱタイミングを有する、無線リソースの用途が固定されたサブフレームであり、前記第２タイプのサブフレームは、ｅＩＭＴＡ端末及びｎｏｎ−ｅＩＭＴＡ端末に対して別個のＨＡＲＱタイミングを有する、無線リソースの用途が固定されたサブフレームであり、前記第３タイプのサブフレームは、無線リソースの用途が変更可能なサブフレームであることを特徴とする。
【発明の効果】
【００１６】
本発明の実施例によれば、無線リソースの用途変更をサポートする無線通信システムで上りリンク制御チャネル送信を効率的に行うことができる。
【００１７】
本発明で得られる効果は、以上で言及した効果に制限されず、言及していない他の効果は、以下の記載から、本発明の属する技術の分野における通常の知識を有する者に明らかになるであろう。
【図面の簡単な説明】
【００１８】
本発明に関する理解を助けるために詳細な説明の一部として含まれる添付の図面は、本発明に関する実施例を提供し、詳細な説明と共に本発明の技術的思想を説明する。
【００１９】
【図１】無線通信システムの一例としてＥ−ＵＭＴＳネットワーク構造を概略的に示す図である。
【図２】３ＧＰＰ無線接続網規格に基づく端末とＥ−ＵＴＲＡＮ間の無線インターフェースプロトコル（Ｒａｄｉｏ  Ｉｎｔｅｒｆａｃｅ  Ｐｒｏｔｏｃｏｌ）のコントロールプレーン（Ｃｏｎｔｒｏｌ  Ｐｌａｎｅ）及びユーザプレーン（Ｕｓｅｒ  Ｐｌａｎｅ）の構造を示す図である。
【図３】３ＧＰＰシステムに用いられる物理チャネル及びこれらのチャネルを用いた一般的な信号送信方法を示す図である。
【図４】ＬＴＥシステムで用いられる無線フレームの構造を示す図である。
【図５】下りリンクスロットに対するリソースグリッド（ｒｅｓｏｕｒｃｅ  ｇｒｉｄ）を示す図である。
【図６】下りリンクサブフレームの構造を示す図である。
【図７】上りリンクサブフレームの構造を示す図である。
【図８】キャリア併合（Ｃａｒｒｉｅｒ  Ａｇｇｒｅｇａｔｉｏｎ；ＣＡ）通信システムを示す図である。
【図９】複数のキャリアが併合された場合のスケジューリングを示す図である。
【図１０】ＥＰＤＣＣＨ、及びＥＰＤＣＣＨによってスケジュールされるＰＤＳＣＨを示す図である。
【図１１】ＴＤＤシステム環境下で既存（Ｌｅｇａｃｙ）サブフレームを静的サブフレーム集合と流動サブフレーム集合とに分割した場合を示す図である。
【図１２】ＰＤＣＣＨのリソース割り当てを説明するための参考図である。
【図１３】本発明の一実施例に適用可能な基地局及び端末を示す図である。
【発明を実施するための形態】
【００２０】
以下の技術は、ＣＤＭＡ（ｃｏｄｅ  ｄｉｖｉｓｉｏｎ  ｍｕｌｔｉｐｌｅ  ａｃｃｅｓｓ）、ＦＤＭＡ（ｆｒｅｑｕｅｎｃｙ  ｄｉｖｉｓｉｏｎ  ｍｕｌｔｉｐｌｅ  ａｃｃｅｓｓ）、ＴＤＭＡ（ｔｉｍｅ  ｄｉｖｉｓｉｏｎ  ｍｕｌｔｉｐｌｅ  ａｃｃｅｓｓ）、ＯＦＤＭＡ（ｏｒｔｈｏｇｏｎａｌ  ｆｒｅｑｕｅｎｃｙ  ｄｉｖｉｓｉｏｎ  ｍｕｌｔｉｐｌｅ  ａｃｃｅｓｓ）、ＳＣ−ＦＤＭＡ（ｓｉｎｇｌｅ  ｃａｒｒｉｅｒ  ｆｒｅｑｕｅｎｃｙ  ｄｉｖｉｓｉｏｎ  ｍｕｌｔｉｐｌｅ  ａｃｃｅｓｓ）などのような様々な無線接続システムに用いることができる。ＣＤＭＡは、ＵＴＲＡ（Ｕｎｉｖｅｒｓａｌ  Ｔｅｒｒｅｓｔｒｉａｌ  Ｒａｄｉｏ  Ａｃｃｅｓｓ）やＣＤＭＡ２０００のような無線技術（ｒａｄｉｏ  ｔｅｃｈｎｏｌｏｇｙ）によって具現することができる。ＴＤＭＡは、ＧＳＭ（Ｇｌｏｂａｌ  Ｓｙｓｔｅｍ  ｆｏｒ  Ｍｏｂｉｌｅ  ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）／ＧＰＲＳ（Ｇｅｎｅｒａｌ  Ｐａｃｋｅｔ  Ｒａｄｉｏ  Ｓｅｒｖｉｃｅ）／ＥＤＧＥ（Ｅｎｈａｎｃｅｄ  Ｄａｔａ  Ｒａｔｅｓ  ｆｏｒ  ＧＳＭ  Ｅｖｏｌｕｔｉｏｎ）のような無線技術によって具現することができる。ＯＦＤＭＡは、ＩＥＥＥ ８０２．１１（Ｗｉ−Ｆｉ）、ＩＥＥＥ ８０２．１６（ＷｉＭＡＸ）、ＩＥＥＥ ８０２−２０、Ｅ−ＵＴＲＡ（Ｅｖｏｌｖｅｄ  ＵＴＲＡ）などのような無線技術によって具現することができる。ＵＴＲＡは、ＵＭＴＳ（Ｕｎｉｖｅｒｓａｌ  Ｍｏｂｉｌｅ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｓｙｓｔｅｍ）の一部である。３ＧＰＰ（３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ）ＬＴＥ（ｌｏｎｇ  ｔｅｒｍ  ｅｖｏｌｕｔｉｏｎ）は、Ｅ−ＵＴＲＡを用いるＥ−ＵＭＴＳ（Ｅｖｏｌｖｅｄ  ＵＭＴＳ）の一部であり、下りリンクでＯＦＤＭＡを採用し、上りリンクでＳＣ−ＦＤＭＡを採用する。ＬＴＥ−Ａ（Ａｄｖａｎｃｅｄ）は、３ＧＰＰ ＬＴＥの進化したバージョンである。
【００２１】
説明を明確にするために、３ＧＰＰ ＬＴＥ／ＬＴＥ−Ａを中心に記述するが、本発明の技術的思想がこれに制限されるわけではない。また、以下の説明で使われる特定用語は、本発明の理解を助けるために提供されるものであり、このような特定用語の使用は、本発明の技術的思想から逸脱しない範囲で他の形態に変更することもできる。
【００２２】
図２は、３ＧＰＰ無線接続網規格に基づく端末とＥ−ＵＴＲＡＮ間の無線インターフェースプロトコル（Ｒａｄｉｏ  Ｉｎｔｅｒｆａｃｅ  Ｐｒｏｔｏｃｏｌ）のコントロールプレーン（Ｃｏｎｔｒｏｌ  Ｐｌａｎｅ）及びユーザプレーン（Ｕｓｅｒ  Ｐｌａｎｅ）の構造を示す図である。コントロールプレーンは、端末（Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ；ＵＥ）とネットワークが呼を管理するために用いる制御メッセージが送信される通路を意味する。ユーザプレーンは、アプリケーション層で生成されたデータ、例えば、音声データ又はインターネットパケットデータなどが送信される通路を意味する。
【００２３】
第１層である物理層は、物理チャネル（Ｐｈｙｓｉｃａｌ  Ｃｈａｎｎｅｌ）を用いて上位層に情報伝送サービス（Ｉｎｆｏｒｍａｔｉｏｎ  Ｔｒａｎｓｆｅｒ  Ｓｅｒｖｉｃｅ）を提供する。物理層は上位にある媒体接続制御（Ｍｅｄｉｕｍ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ）層とは伝送チャネル（Ｔｒａｎｓｐｏｒｔ  Ｃｈａｎｎｅｌ）を介して接続されている。この伝送チャネルを介して媒体接続制御層と物理層間にデータが移動する。送信側の物理層と受信側の物理層間は、物理チャネルを介してデータが移動する。この物理チャネルは、時間と周波数を無線リソースとして用いる。具体的に、物理チャネルは、下りリンクでＯＦＤＭＡ（Ｏｒｔｈｏｇｏｎａｌ  Ｆｒｅｑｕｅｎｃｙ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓ）方式で変調され、上りリンクでＳＣ−ＦＤＭＡ（Ｓｉｎｇｌｅ  Ｃａｒｒｉｅｒ  Ｆｒｅｑｕｅｎｃｙ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓ）方式で変調される。
【００２４】
第２層の媒体接続制御（Ｍｅｄｉｕｍ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ；ＭＡＣ）層は、論理チャネル（Ｌｏｇｉｃａｌ  Ｃｈａｎｎｅｌ）を介して上位層である無線リンク制御（Ｒａｄｉｏ  Ｌｉｎｋ  Ｃｏｎｔｒｏｌ；ＲＬＣ）層にサービスを提供する。第２層のＲＬＣ層は、信頼性あるデータ送信を支援する。ＲＬＣ層の機能は、ＭＡＣ内部の機能ブロックとして具現することもできる。第２層のＰＤＣＰ（Ｐａｃｋｅｔ  Ｄａｔａ  Ｃｏｎｖｅｒｇｅｎｃｅ  Ｐｒｏｔｏｃｏｌ）層は、帯域幅の狭い無線インターフェースでＩＰｖ４やＩＰｖ６のようなＩＰパケットを效率的に送信するために不要の制御情報を減らすヘッダー圧縮（Ｈｅａｄｅｒ  Ｃｏｍｐｒｅｓｓｉｏｎ）機能を果たす。
【００２５】
第３層の最下部に位置している無線リソース制御（Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ；ＲＲＣ）層は、コントロールプレーンでのみ定義される。ＲＲＣ層は、無線ベアラー（Ｒａｄｉｏ  Ｂｅａｒｅｒ；ＲＢ）の設定（Ｃｏｎｆｉｇｕｒａｔｉｏｎ）、再設定（Ｒｅ−ｃｏｎｆｉｇｕｒａｔｉｏｎ）及び解除（Ｒｅｌｅａｓｅ）と関連して論理チャネル、伝送チャネル及び物理チャネルの制御を担当する。ＲＢは、端末とネットワーク間のデータ伝達のために第２層によって提供されるサービスを意味する。そのために、端末とネットワークのＲＲＣ層は互いにＲＲＣメッセージを交換する。端末とネットワークのＲＲＣ層間にＲＲＣ接続（ＲＲＣ  Ｃｏｎｎｅｃｔｅｄ）がある場合、端末はＲＲＣ接続状態（Ｃｏｎｎｅｃｔｅｄ  Ｍｏｄｅ）であり、そうでない場合、ＲＲＣ休止状態（Ｉｄｌｅ  Ｍｏｄｅ）である。ＲＲＣ層の上位にあるＮＡＳ（Ｎｏｎ−Ａｃｃｅｓｓ  Ｓｔｒａｔｕｍ）層は、セッション管理（Ｓｅｓｓｉｏｎ  Ｍａｎａｇｅｍｅｎｔ）と移動性管理（Ｍｏｂｉｌｉｔｙ  Ｍａｎａｇｅｍｅｎｔ）などの機能を果たす。
【００２６】
基地局（ｅＮＢ）を構成する一つのセルは、１．４、３、５、１０、１５、２０ＭＨｚなどの帯域幅のいずれか一つに設定され、複数の端末に下り又は上り送信サービスを提供する。異なったセルは異なった帯域幅を提供するように設定することができる。
【００２７】
ネットワークから端末にデータを送信する下り伝送チャネルは、システム情報を送信するＢＣＨ（Ｂｒｏａｄｃａｓｔ  Ｃｈａｎｎｅｌ）、ページングメッセージを送信するＰＣＨ（Ｐａｇｉｎｇ  Ｃｈａｎｎｅｌ）、ユーザトラフィックや制御メッセージを送信する下りＳＣＨ（Ｓｈａｒｅｄ  Ｃｈａｎｎｅｌ）などがある。下りマルチキャスト又は放送サービスのトラフィック又は制御メッセージの場合、下りＳＣＨを介して送信されてもよく、又は別の下りＭＣＨ（Ｍｕｌｔｉｃａｓｔ  Ｃｈａｎｎｅｌ）を介して送信されてもよい。一方、端末からネットワークにデータを送信する上り伝送チャネルには、初期制御メッセージを送信するＲＡＣＨ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｃｈａｎｎｅｌ）、ユーザトラフィックや制御メッセージを送信する上りＳＣＨ（Ｓｈａｒｅｄ  Ｃｈａｎｎｅｌ）がある。伝送チャネルの上位に位置しており、伝送チャネルにマップされる論理チャネル（Ｌｏｇｉｃａｌ  Ｃｈａｎｎｅｌ）には、ＢＣＣＨ（Ｂｒｏａｄｃａｓｔ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ）、ＰＣＣＨ（Ｐａｇｉｎｇ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ）、ＣＣＣＨ（Ｃｏｍｍｏｎ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ）、ＭＣＣＨ（Ｍｕｌｔｉｃａｓｔ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ）、ＭＴＣＨ（Ｍｕｌｔｉｃａｓｔ  Ｔｒａｆｆｉｃ  Ｃｈａｎｎｅｌ）などがある。
【００２８】
図３は、３ＧＰＰ ＬＴＥシステムに用いられる物理チャネル及びそれらを用いた一般的な信号送信方法を説明するための図である。
【００２９】
電源が消えた状態で電源がついたり、新しくセルに進入したりしたユーザ機器は、段階Ｓ３０１で、基地局と同期を取るなどの初期セル探索（Ｉｎｉｔｉａｌ  ｃｅｌｌ  ｓｅａｒｃｈ）作業を行う。そのために、ユーザ機器は基地局から１次同期チャネル（Ｐｒｉｍａｒｙ  Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ  Ｃｈａｎｎｅｌ、Ｐ−ＳＣＨ）及び２次同期チャネル（Ｓｅｃｏｎｄａｒｙ  Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ  Ｃｈａｎｎｅｌ、Ｓ−ＳＣＨ）を受信して基地局と同期を取り、セルＩＤなどの情報を取得する。その後、ユーザ機器は、基地局から物理放送チャネル（Ｐｈｙｓｉｃａｌ  Ｂｒｏａｄｃａｓｔ  Ｃｈａｎｎｅｌ）を受信してセル内放送情報を取得することができる。一方、ユーザ機器は、初期セル探索段階で下りリンク参照信号（Ｄｏｗｎｌｉｎｋ  Ｒｅｆｅｒｅｎｃｅ  Ｓｉｇｎａｌ、ＤＬ ＲＳ）を受信して下りリンクチャネル状態を確認することができる。
【００３０】
初期セル探索を終えたユーザ機器は、段階Ｓ３０２で、物理下りリンク制御チャネル（Ｐｈｙｓｉｃａｌ  Ｄｏｗｎｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ、ＰＤＣＣＨ）、及び物理下りリンク制御チャネル情報に基づく物理下りリンク共有チャネル（Ｐｈｙｓｉｃａｌ  Ｄｏｗｎｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ、ＰＤＳＣＨ）を受信し、より具体的なシステム情報を取得することができる。
【００３１】
その後、ユーザ機器は、基地局への接続を完了するために、段階Ｓ３０３乃至段階Ｓ３０６のようなランダムアクセス手順（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｐｒｏｃｅｄｕｒｅ）を行うことができる。そのために、ユーザ機器は、物理ランダムアクセスチャネル（Ｐｈｙｓｉｃａｌ  Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｃｈａｎｎｅｌ、ＰＲＡＣＨ）を介してプリアンブル（ｐｒｅａｍｂｌｅ）を送信し（Ｓ３０３）、物理下りリンク制御チャネル及びこれに対応する物理下りリンク共有チャネルを介して、プリアンブルに対する応答メッセージを受信することができる（Ｓ３０４）。競合ベースランダムアクセスの場合、更なる物理ランダムアクセスチャネルの送信（Ｓ３０５）、及び物理下りリンク制御チャネル及びこれに対応する物理下りリンク共有チャネルの受信（Ｓ３０６）のような衝突解決手順（Ｃｏｎｔｅｎｔｉｏｎ  Ｒｅｓｏｌｕｔｉｏｎ  Ｐｒｏｃｅｄｕｒｅ）を行うことができる。
【００３２】
上述したような手順を行ったユーザ機器は、その後、一般的な上りリンク／下りリンク信号送信手順として、物理下りリンク制御チャネル／物理下りリンク共有チャネルの受信（Ｓ３０７）及び物理上りリンク共有チャネル（Ｐｈｙｓｉｃａｌ  Ｕｐｌｉｎｋ  Ｓｈａｒｅｄ  Ｃｈａｎｎｅｌ、ＰＵＳＣＨ）／物理上りリンク制御チャネル（Ｐｈｙｓｉｃａｌ  Ｕｐｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ、ＰＵＣＣＨ）の送信（Ｓ３０８）を行うことができる。ユーザ機器が基地局に送信する制御情報を総称して上りリンク制御情報（Ｕｐｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｉｎｆｏｒｍａｔｉｏｎ、ＵＣＩ）という。ＵＣＩは、ＨＡＲＱ ＡＣＫ／ＮＡＣＫ（Ｈｙｂｒｉｄ  Ａｕｔｏｍａｔｉｃ  Ｒｅｐｅａｔ  ａｎｄ  ｒｅＱｕｅｓｔ  Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ／Ｎｅｇａｔｉｖｅ−ＡＣＫ）、ＳＲ（Ｓｃｈｅｄｕｌｉｎｇ  Ｒｅｑｕｅｓｔ）、ＣＳＩ（Ｃｈａｎｎｅｌ  Ｓｔａｔｅ  Ｉｎｆｏｒｍａｔｉｏｎ）などを含む。本明細書で、ＨＡＲＱ ＡＣＫ／ＮＡＣＫは簡単に、ＨＡＲＱ−ＡＣＫ或いはＡＣＫ／ＮＡＣＫ（Ａ／Ｎ）と呼ぶ。ＨＡＲＱ−ＡＣＫは、ポジティブＡＣＫ（簡単に、ＡＣＫ）、ネガティブＡＣＫ（ＮＡＣＫ）、ＤＴＸ及びＮＡＣＫ／ＤＴＸのうち少なくとも一つを含む。ＣＳＩは、ＣＱＩ（Ｃｈａｎｎｅｌ  Ｑｕａｌｉｔｙ  Ｉｎｄｉｃａｔｏｒ）、ＰＭＩ（Ｐｒｅｃｏｄｉｎｇ  Ｍａｔｒｉｘ  Ｉｎｄｉｃａｔｏｒ）、ＲＩ（Ｒａｎｋ  Ｉｎｄｉｃａｔｉｏｎ）などを含む。ＵＣＩは、一般にはＰＵＣＣＨを介して送信されるが、制御情報とトラフィックデータとが同時に送信されるべき場合にはＰＵＳＣＨを介して送信されてもよい。また、ネットワークの要請／指示に応じて、ＰＵＳＣＨを介してＵＣＩを非周期的に送信することもできる。
【００３３】
図４は、ＬＴＥシステムで用いられる無線フレームの構造を例示する図である。
【００３４】
図４を参照すると、セルラーＯＦＤＭ無線パケット通信システムにおいて、上りリンク／下りリンクデータパケット送信はサブフレーム（ｓｕｂｆｒａｍｅ）単位になされ、１サブフレームは、複数のＯＦＤＭシンボルを含む一定時間区間と定義される。３ＧＰＰ ＬＴＥ標準では、ＦＤＤ（Ｆｒｅｑｕｅｎｃｙ  Ｄｉｖｉｓｉｏｎ  Ｄｕｐｌｅｘ）に適用可能なタイプ１無線フレーム（ｒａｄｉｏ  ｆｒａｍｅ）構造、及びＴＤＤ（Ｔｉｍｅ  Ｄｉｖｉｓｉｏｎ  Ｄｕｐｌｅｘ）に適用可能なタイプ２の無線フレーム構造を支援する。
【００３５】
図４の（ａ）は、タイプ１無線フレームの構造を例示する。下りリンク無線フレーム（ｒａｄｉｏ  ｆｒａｍｅ）は、１０個のサブフレーム（ｓｕｂｆｒａｍｅ）で構成され、１サブフレームは、時間領域（ｔｉｍｅ  ｄｏｍａｉｎ）で２個のスロット（ｓｌｏｔ）で構成される。１サブフレーム）を送信するためにかかる時間をＴＴＩ（ｔｒａｎｓｍｉｓｓｉｏｎ  ｔｉｍｅ  ｉｎｔｅｒｖａｌ）という。例えば、１サブフレームの長さを１ｍｓ、１スロットの長さを０．５ｍｓとすることができる。１スロットは時間領域で複数のＯＦＤＭシンボルを含み、周波数領域で複数のリソースブロック（Ｒｅｓｏｕｒｃｅ  Ｂｌｏｃｋ；ＲＢ）を含む。３ＧＰＰ ＬＴＥシステムでは下りリンクでＯＦＤＭＡが用いられるため、ＯＦＤＭシンボルが１シンボル区間を表す。ＯＦＤＭシンボルは、ＳＣ−ＦＤＭＡシンボル又はシンボル区間と呼ぶこともできる。リソース割当て単位としてのリソースブロック（ＲＢ）は、１スロットで複数個の連続した副搬送波（ｓｕｂｃａｒｒｉｅｒ）を含むことができる。
【００３６】
１スロットに含まれるＯＦＤＭシンボルの数は、ＣＰ（Ｃｙｃｌｉｃ  Ｐｒｅｆｉｘ）の構成（ｃｏｎｆｉｇｕｒａｔｉｏｎ）によって可変することができる。ＣＰには、拡張されたＣＰ（ｅｘｔｅｎｄｅｄ  ＣＰ）と標準ＣＰ（ｎｏｒｍａｌ  ＣＰ）がある。例えば、ＯＦＤＭシンボルが標準ＣＰによって構成された場合、１スロットに含まれるＯＦＤＭシンボルの数は７個であってよい。ＯＦＤＭシンボルが拡張されたＣＰによって構成された場合、１ ＯＦＤＭシンボルの長さが増加することから、１スロットに含まれるＯＦＤＭシンボルの数は、標準ＣＰの場合に比べて少ない。拡張されたＣＰの場合、例えば、１スロットに含まれるＯＦＤＭシンボルの数は６個であってもよい。ユーザ機器が速い速度で移動するなどしてチャネル状態が不安定な場合、シンボル間干渉をより減らすために、拡張されたＣＰを用いることができる。
【００３７】
標準ＣＰが用いられる場合、１スロットは７ ＯＦＤＭシンボルを含むため、１サブフレームは１４ ＯＦＤＭシンボルを含む。このとき、各サブフレームの先頭における最大３個のＯＦＤＭシンボルは、ＰＤＣＣＨ（ｐｈｙｓｉｃａｌ  ｄｏｗｎｌｉｎｋ  ｃｏｎｔｒｏｌ  ｃｈａｎｎｅｌ）に割り当て、残りのＯＦＤＭシンボルは、ＰＤＳＣＨ（ｐｈｙｓｉｃａｌ  ｄｏｗｎｌｉｎｋ  ｓｈａｒｅｄ  ｃｈａｎｎｅｌ）に割り当てることができる。
【００３８】
図４の（ｂ）は、タイプ２無線フレームの構造を例示する。タイプ２無線フレームは、２個のハーフフレーム（ｈａｌｆ  ｆｒａｍｅ）で構成され、各ハーフフレームは、２個のスロットを含む４個の一般サブフレームと、ＤｗＰＴＳ（Ｄｏｗｎｌｉｎｋ  Ｐｉｌｏｔ  Ｔｉｍｅ  Ｓｌｏｔ）、保護区間（Ｇｕａｒｄ  Ｐｅｒｉｏｄ、ＧＰ）及びＵｐＰＴＳ（Ｕｐｌｉｎｋ  Ｐｉｌｏｔ  Ｔｉｍｅ  Ｓｌｏｔ）を含む特別サブフレーム（ｓｐｅｃｉａｌ  ｓｕｂｆｒａｍｅ）とで構成される。
【００３９】
特別サブフレームにおいて、ＤｗＰＴＳは、ユーザ機器における初期セル探索、同期化又はチャネル推定に用いられる。ＵｐＰＴＳは、基地局におけるチャネル推定とユーザ機器の上りリンク送信同期の獲得に用いられる。すなわち、ＤｗＰＴＳは下りリンク送信に、ＵｐＰＴＳは上りリンク送信に用いられ、特に、ＵｐＰＴＳはＰＲＡＣＨプリアンブルやＳＲＳ送信のために用いられる。また、保護区間は、上りリンクと下りリンクの間に下りリンク信号の多重経路遅延によって上りリンクで生じる干渉を除去するための区間である。
【００４０】
上記の特別サブフレームに関して現在３ＧＰＰ標準文書では下記の表１のように設定を定義している。表１で、
【数１】
0006321201.tif 000002
の場合に、ＤｗＰＴＳとＵｐＰＴＳを示しており、残りの領域が保護区間として設定される。
【表１】
0006321201.tif 000003
【００４１】
一方、タイプ２無線フレームの構造、すなわち、ＴＤＤシステムにおいて上りリンク／下りリンクサブフレーム設定（ＵＬ／ＤＬ  ｃｏｎｆｉｇｕｒａｔｉｏｎ）は、下記の表２のとおりである。
【表２】
0006321201.tif 000004
【００４２】
上記の表２で、Ｄは下りリンクサブフレーム、Ｕは上りリンクサブフレームを表し、Ｓは特別サブフレームを意味する。また、上記の表２では、それぞれの上りリンク／下りリンクサブフレーム設定において下りリンク−上りリンクスイッチング周期も表している。
【００４３】
上述した無線フレームの構造は例示に過ぎず、無線フレームに含まれるサブフレームの数、サブフレームに含まれるスロットの数、又はスロットに含まれるシンボルの数は様々に変更されてもよい。
【００４４】
図５には、下りリンクスロットにおけるリソースグリッド（ｒｅｓｏｕｒｃｅ  ｇｒｉｄ）を例示する。
【００４５】
【数２】
0006321201.tif 000005
図５は、下りリンクスロットが７個のＯＦＤＭシンボルを含み、リソースブロックが１２個の副搬送波を含むとしているが、必ずしもこれに制限されない。例えば、下りリンクスロットに含まれるＯＦＤＭシンボルの個数は、サイクリックプレフィックス（Ｃｙｃｌｉｃ  Ｐｒｅｆｉｘ；ＣＰ）の長さによって変形されてもよい。
【００４６】
リソースグリッド上の各要素をリソース要素（Ｒｅｓｏｕｒｃｅ  Ｅｌｅｍｅｎｔ；ＲＥ）とし、１つのリソース要素は、１つのＯＦＤＭシンボルインデックス及び１つの副搬送波インデックスで示される。
【数３】
0006321201.tif 000006
【００４７】
図６には、下りリンクサブフレームの構造を例示する。
【００４８】
図６を参照すると、サブフレームの一番目のスロットで先頭部に位置している最大３（４）個のＯＦＤＭシンボルは、制御チャネルが割り当てられる制御領域に該当する。残りのＯＦＤＭシンボルは、ＰＤＳＣＨ（Ｐｈｙｓｉｃａｌ  Ｄｏｗｎｌｉｎｋ  Ｓｈａｒｅｄ  Ｃｈａｎｎｅｌ）が割り当てられるデータ領域に該当する。ＬＴＥで用いられる下りリンク制御チャネルの例には、ＰＣＦＩＣＨ（Ｐｈｙｓｉｃａｌ  Ｃｏｎｔｒｏｌ  Ｆｏｒｍａｔ  Ｉｎｄｉｃａｔｏｒ  Ｃｈａｎｎｅｌ）、ＰＤＣＣＨ（Ｐｈｙｓｉｃａｌ  Ｄｏｗｎｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ）、ＰＨＩＣＨ（Ｐｈｙｓｉｃａｌ  ｈｙｂｒｉｄ  ＡＲＱ  ｉｎｄｉｃａｔｏｒ  Ｃｈａｎｎｅｌ）などがある。ＰＣＦＩＣＨは、サブフレームの最初のＯＦＤＭシンボルで送信され、サブフレーム内で制御チャネルの送信に用いられるＯＦＤＭシンボルの個数に関する情報を搬送する。ＰＨＩＣＨは、上りリンク送信に対する応答としてＨＡＲＱ  ＡＣＫ／ＮＡＣＫ（Ｈｙｂｒｉｄ  Ａｕｔｏｍａｔｉｃ  Ｒｅｐｅａｔ  ｒｅｑｕｅｓｔａｃｋｎｏｗｌｅｄｇｍｅｎｔ／ｎｅｇａｔｉｖｅ−ａｃｋｎｏｗｌｅｄｇｍｅｎｔ）信号を搬送する。
【００４９】
ＰＤＣＣＨで送信される制御情報をＤＣＩ（Ｄｏｗｎｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｉｎｆｏｒｍａｔｉｏｎ）と称する。ＤＣＩは、ユーザ機器又はユーザ機器グループのためのリソース割り当て情報及び他の制御情報を含む。例えば、ＤＣＩは、上りリンク／下りリンクスケジューリング情報、上りリンク送信（Ｔｘ）電力制御命令などを含む。
【００５０】
ＰＤＣＣＨは、下りリンク共有チャネル（ｄｏｗｎｌｉｎｋ  ｓｈａｒｅｄ  ｃｈａｎｎｅｌ；ＤＬ−ＳＣＨ）の送信フォーマット及びリソース割り当て情報、上りリンク共有チャネル（ｕｐｌｉｎｋ  ｓｈａｒｅｄ  ｃｈａｎｎｅｌ；ＵＬ−ＳＣＨ）の送信フォーマット及びリソース割り当て情報、ページングチャネル（ｐａｇｉｎｇ  ｃｈａｎｎｅｌ；ＰＣＨ）上のページング情報、ＤＬ−ＳＣＨ上のシステム情報、ＰＤＳＣＨ上で送信されるランダムアクセス応答のような上位層制御メッセージのリソース割り当て情報、ユーザ機器グループ内の個別ユーザ機器に対する送信電力制御命令セット、送信電力制御命令、ＶｏＩＰ（Ｖｏｉｃｅ  ｏｖｅｒ  ＩＰ）の活性化指示情報などを搬送する。複数のＰＤＣＣＨが制御領域内で送信されてもよく、ユーザ機器は、複数のＰＤＣＣＨを監視することができる。ＰＤＣＣＨは、一つ又は複数の連続した制御チャネル要素（ｃｏｎｔｒｏｌ  ｃｈａｎｎｅｌ  ｅｌｅｍｅｎｔ；ＣＣＥ）の集合（ａｇｇｒｅｇａｔｉｏｎ）上で送信される。ＣＣＥは、ＰＤＣＣＨに無線チャネル状態に基づくコーディングレートを提供するために用いられる論理的割り当てユニットである。ＣＣＥは、複数のリソース要素グループ（ｒｅｓｏｕｒｃｅ  ｅｌｅｍｅｎｔ  ｇｒｏｕｐ；ＲＥＧ）に対応する。ＰＤＣＣＨのフォーマット及びＰＤＣＣＨビットの個数は、ＣＣＥの個数によって決定される。基地局は、ユーザ機器に送信されるＤＣＩによってＰＤＣＣＨフォーマットを決定し、制御情報にＣＲＣ（ｃｙｃｌｉｃ  ｒｅｄｕｎｄａｎｃｙ  ｃｈｅｃｋ）を付加する。ＣＲＣは、ＰＤＣＣＨの所有者又は使用目的によって識別子（例、ＲＮＴＩ（ｒａｄｉｏ  ｎｅｔｗｏｒｋ  ｔｅｍｐｏｒａｒｙ  ｉｄｅｎｔｉｆｉｅｒ））でマスクされる。例えば、ＰＤＣＣＨが特定ユーザ機器のためのものである場合、該当のユーザ機器の識別子（例、ｃｅｌｌ−ＲＮＴＩ（Ｃ−ＲＮＴＩ））をＣＲＣにマスクすることができる。ＰＤＣＣＨがページングメッセージのためのものである場合、ページング識別子（例、ｐａｇｉｎｇ−ＲＮＴＩ（Ｐ−ＲＮＴＩ））がＣＲＣにマスクされてもよい。ＰＤＣＣＨがシステム情報（より詳しくは、システム情報ブロック（ｓｙｓｔｅｍ  Ｉｎｆｏｒｍａｔｉｏｎ  ｂｌｏｃｋ；ＳＩＣ））のためのものである場合、ＳＩ−ＲＮＴＩ（ｓｙｓｔｅｍ  Ｉｎｆｏｒｍａｔｉｏｎ  ＲＮＴＩ）がＣＲＣにマスクされてもよい。ＰＤＣＣＨがランダムアクセス応答のためのものである場合、ＲＡ−ＲＮＴＩ（ｒａｎｄｏｍ  ａｃｃｅｓｓ−ＲＮＴＩ）がＣＲＣにマスクされてもよい。
【００５１】
図７は、ＬＴＥで用いられる上りリンクサブフレームの構造を例示する。
【００５２】
図７を参照すると、上りリンクサブフレームは、複数（例、２個）のスロットを含む。スロットは、ＣＰ長によって異なる個数のＳＣ−ＦＤＭＡシンボルを含むことができる。上りリンクサブフレームは、周波数領域でデータ領域と制御領域とに区別される。データ領域は、ＰＵＳＣＨを含み、音声などのデータ信号を送信するために用いられる。制御領域は、ＰＵＣＣＨを含み、上りリンク制御情報（Ｕｐｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｉｎｆｏｒｍａｔｉｏｎ;ＵＣＩ）を送信するために用いられる。ＰＵＣＣＨは、周波数軸でデータ領域の両端部に位置しているＲＢ対（ＲＢ  ｐａｉｒ）を含み、スロットを境界でホップする。
【００５３】
ＰＵＣＣＨは、次の制御情報を送信するために用いることができる。
【００５４】
−  ＳＲ（Ｓｃｈｅｄｕｌｉｎｇ  Ｒｅｑｕｅｓｔ）：上りリンクＵＬ−ＳＣＨリソースを要求するために用いる情報である。ＯＯＫ（Ｏｎ−Ｏｆｆ  Ｋｅｙｉｎｇ）方式で送信する。
【００５５】
−  ＨＡＲＱ  ＡＣＫ／ＮＡＣＫ：ＰＤＳＣＨ上の下りリンクデータパケットに対する応答信号である。下りリンクデータパケットの受信に成功したか否かを示す。単一の下りリンクコードワードに対する応答として１ビットのＡＣＫ／ＮＡＣＫを送信し、２つの下りリンクコードワードに対する応答として２ビットのＡＣＫ／ＮＡＣＫを送信する。
【００５６】
−  ＣＳＩ（Ｃｈａｎｎｅｌ  Ｓｔａｔｅ  Ｉｎｆｏｒｍａｔｉｏｎ）：下りリンクチャネルに対するフィードバック情報である。ＣＳＩは、ＣＱＩ（Ｃｈａｎｎｅｌ  Ｑｕａｌｉｔｙ  Ｉｎｄｉｃａｔｏｒ）を含み、ＭＩＭＯ（Ｍｕｌｔｉｐｌｅ  Ｉｎｐｕｔ  Ｍｕｌｔｉｐｌｅ  Ｏｕｔｐｕｔ）関連フィードバック情報は、ＲＩ（Ｒａｎｋ  Ｉｎｄｉｃａｔｏｒ）、ＰＭＩ（Ｐｒｅｃｏｄｉｎｇ  Ｍａｔｒｉｘ  Ｉｎｄｉｃａｔｏｒ）、ＰＴＩ（Ｐｒｅｃｏｄｉｎｇ  Ｔｙｐｅ  Ｉｎｄｉｃａｔｏｒ）などを含む。サブフレーム当たりに２０ビットが用いられる。
【００５７】
ユーザ機器がサブフレームで送信可能な制御情報（ＵＣＩ）の量は、制御情報送信に可用なＳＣ−ＦＤＭＡの個数に依存する。制御情報送信に可用なＳＣ−ＦＤＭＡは、サブフレームにおいて参照信号の送信のためのＳＣ−ＦＤＭＡシンボルを除いた残りのＳＣ−ＦＤＭＡシンボルを意味し、ＳＲＳ（Ｓｏｕｎｄｉｎｇ  Ｒｅｆｅｒｅｎｃｅ  Ｓｉｇｎａｌ）が設定されたサブフレームでは、サブフレームの最後のＳＣ−ＦＤＭＡシンボルも除く。参照信号はＰＵＣＣＨのコヒーレント検出に用いられる。
【００５８】
図８には、キャリア併合（Ｃａｒｒｉｅｒ  Ａｇｇｒｅｇａｔｉｏｎ；ＣＡ）通信システムを例示する。
【００５９】
図８を参照すると、複数の上りリンク／下りリンクコンポーネント搬送波（Ｃｏｍｐｏｎｅｎｔ  Ｃａｒｒｉｅｒ；ＣＣ）を束ねてより広い上りリンク／下りリンク帯域幅をサポートすることができる。用語「コンポーネント搬送波（ＣＣ）」は、等価の他の用語（例、キャリア、セルなど）に言い換えてもよい。各ＣＣは周波数領域で互いに隣接しても非隣接してもよい。各コンポーネント搬送波の帯域幅は、独立して定められてもよい。ＵＬ  ＣＣの個数とＤＬ  ＣＣの個数とが異なる非対称の搬送波集成も可能である。一方、制御情報は、特定ＣＣでのみ送受信されるように設定されてもよい。このような特定のＣＣをプライマリＣＣ（又はアンカーＣＣ）とし、残りのＣＣをセカンダリＣＣとすることができる。
【００６０】
クロス−キャリアスケジューリング（又は、クロス−ＣＣスケジューリング）が適用される場合、下りリンク割り当てのためのＰＤＣＣＨはＤＬ  ＣＣ＃０で送信され、該当のＰＤＳＣＨはＤＬ  ＣＣ＃２で送信されてもよい。クロス−ＣＣスケジューリングのために、キャリア指示フィールド（ｃａｒｒｉｅｒ  ｉｎｄｉｃａｔｏｒ  ｆｉｅｌｄ；ＣＩＦ）の導入を考慮することができる。ＰＤＣＣＨ内でＣＩＦが存在するか否かは、上位層シグナリング（例、ＲＲＣシグナリング）によって半−静的及び端末−特定（又は端末グループ−特定）方式で設定されてもよい。ＰＤＣＣＨ送信のベースラインを要約すると、次のとおりである。
【００６１】
□  ＣＩＦディセーブルド（ｄｉｓａｂｌｅｄ）：ＤＬ  ＣＣ上のＰＤＣＣＨは、同じＤＬ  ＣＣ上のＰＤＳＣＨリソースを割り当てたり、一つのリンクされたＵＬ  ＣＣ上のＰＵＳＣＨリソースを割り当てる
【００６２】
●  Ｎｏ  ＣＩＦ
【００６３】
●  ＬＴＥ  ＰＤＣＣＨ構造（同じ符号化、同じＣＣＥベースのリソースマッピング）及びＤＣＩフォーマットと同一である
【００６４】
□  ＣＩＦイネーブルド（ｅｎａｂｌｅｄ）：ＤＬ  ＣＣ上のＰＤＣＣＨはＣＩＦを用いて、複数の併合されたＤＬ／ＵＬ  ＣＣのうち特定のＤＬ／ＵＬ  ＣＣ上のＰＤＳＣＨ又はＰＵＳＣＨリソースを割り当てることができる
【００６５】
●  ＣＩＦを有する拡張されたＬＴＥ  ＤＣＩフォーマット
−  ＣＩＦ（設定される場合）は、固定されたｘ−ビットフィールド（例、ｘ＝３）
−  ＣＩＦ（設定される場合）位置は、ＤＣＩフォーマットサイズに関係なく固定される
【００６６】
●  ＬＴＥ  ＰＤＣＣＨ構造を再使用（同じ符号化、同じＣＣＥベースのリソースマッピング）
【００６７】
ＣＩＦが存在する場合、基地局は、端末側のＢＤ複雑度を下げるために、ＰＤＣＣＨモニタリングＤＬ  ＣＣセットを割り当てることができる。ＰＤＣＣＨモニタリングＤＬ  ＣＣセットは、併合された全ＤＬ  ＣＣの一部であって、一つ以上のＤＬ  ＣＣを含み、端末は、該当のＤＬ  ＣＣ上でＰＤＣＣＨの検出／復号化を行う。すなわち、基地局が端末にＰＤＳＣＨ／ＰＵＳＣＨをスケジュールする場合、ＰＤＣＣＨは、ＰＤＣＣＨモニタリングＤＬ  ＣＣセットでのみ送信される。ＰＤＣＣＨモニタリングＤＬ  ＣＣセットは、端末−特定（ＵＥ−ｓｐｅｃｉｆｉｃ）、端末−グループ−特定、又はセル−特定（ｃｅｌｌ−ｓｐｅｃｉｆｉｃ）の方式で設定されてもよい。用語「ＰＤＣＣＨモニタリングＤＬ  ＣＣ」は、モニタリングキャリア、モニタリングセルなどの等価の用語に代えてもよい。また、端末のために併合されたＣＣは、サービングＣＣ、サービングキャリア、サービングセルなどの等価の用語に代えてもよい。
【００６８】
図９には、複数のキャリアが併合された場合のスケジューリングを例示する。３個のＤＬ  ＣＣが併合されたと仮定する。ＤＬ  ＣＣ  ＡがＰＤＣＣＨモニタリングＤＬ  ＣＣとして設定されたと仮定する。ＤＬ  ＣＣ  Ａ〜Ｃを、サービングＣＣ、サービングキャリア、サービングセルなどと呼ぶことができる。ＣＩＦがディセーブルされた場合、各ＤＬ  ＣＣは、ＬＴＥ  ＰＤＣＣＨ設定によって、ＣＩＦ無しで、自身のＰＤＳＣＨをスケジュールするＰＤＣＣＨだけを送信することができる。一方、端末−特定（又は端末−グループ−特定又はセル−特定）上位層シグナリングによってＣＩＦがイネーブルされた場合、ＤＬ  ＣＣ  Ａ（モニタリングＤＬ  ＣＣ）は、ＣＩＦを用いて、ＤＬ  ＣＣ  ＡのＰＤＳＣＨをスケジュールするＰＤＣＣＨの他、別のＣＣのＰＤＳＣＨをスケジュールするＰＤＣＣＨも送信することができる。この場合、ＰＤＣＣＨモニタリングＤＬ  ＣＣとして設定されていないＤＬ  ＣＣ  Ｂ／Ｃでは、ＰＤＣＣＨが送信されない。したがって、ＤＬ  ＣＣ  Ａ（モニタリングＤＬ  ＣＣ）は、ＤＬ  ＣＣ  Ａと関連付いたＰＤＣＣＨ検索領域、ＤＬ  ＣＣ  Ｂと関連付いたＰＤＣＣＨ検索領域、及びＤＬ  ＣＣ  Ｃと関連付いたＰＤＣＣＨ検索領域を全て含まなければならない。本明細書で、ＰＤＣＣＨ検索領域はキャリア別に定義されると仮定する。
【００６９】
上述したように、ＬＴＥ−Ａは、クロス−ＣＣスケジューリングのためにＰＤＣＣＨ内でＣＩＦの使用を考慮している。ＣＩＦを使用するか否か（すなわち、クロス−ＣＣスケジューリングモード又はノン−クロス−ＣＣスケジューリングモードのサポート）及びモード間切換は、ＲＲＣシグナリングで半−静的／端末−特定に設定することができ、当該ＲＲＣシグナリング過程を経た後、端末は、自身にスケジュールされるＰＤＣＣＨ内にＣＩＦが用いられるか否かを認識することができる。
【００７０】
図１０は、ＥＰＤＣＣＨ、及びＥＰＤＣＣＨによってスケジュールされるＰＤＳＣＨを示す図である。
【００７１】
図１０を参照すると、ＥＰＤＣＣＨは一般に、データを送信するＰＤＳＣＨ領域の一部分を定義して使用することができ、端末は、自身へのＥＰＤＣＣＨの有無を検出するためのブラインドデコーディング（ｂｌｉｎｄ  ｄｅｃｏｄｉｎｇ）過程を行わなければならない。ＥＰＤＣＣＨは、既存のレガシーＰＤＣＣＨと同じスケジューリング動作（すなわち、ＰＤＳＣＨ、ＰＵＳＣＨの制御）を行うが、ＲＲＨのようなノードに接続した端末の個数が増えると、ＰＤＳＣＨ領域内に一層多数のＥＰＤＣＣＨが割り当てられるため、端末の行うべきブラインドデコーディングの回数も増加し、複雑度の増加につながるという短所はある。
【００７２】
図１１には、ＴＤＤシステム環境下で既存（Ｌｅｇａｃｙ）サブフレームを静的サブフレーム集合と流動サブフレーム集合とに分割した場合を示す。図８で、ＳＩＢ（Ｓｙｓｔｅｍ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｂｌｏｃｋ）シグナルで設定された既存の上りリンク−下りリンク設定を上りリンク−下りリンク設定＃１（すなわち、ＤＳＵＵＤＤＳＵＵＤ）と仮定しており、基地局は端末に、事前に定義されたシグナルで無線リソースの用途の再設定情報を知らせると仮定している。
【００７３】
無線リソース用途変更メッセージ（Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｍｅｓｓａｇｅ）は、事前に定義された規則によって、ｉ）当該用途変更メッセージ受信時点を含めて後に現れたり、或いはｉｉ）当該用途変更メッセージ受信時点を含めないで後に現れたり、或いはｉｉｉ）当該用途変更メッセージ受信時点から事前に定義された時間（すなわち、サブフレームオフセット（Ｓｕｂｆｒａｍｅ  Ｏｆｆｓｅｔ）以降）に現れる無線リソースの用途を知らせる目的で用いられる。
【００７４】
前述した内容に基づいて、本発明では、特定セル上の無線リソース用途が負荷状態によって動的に変更（すなわち、ｅＩＭＴＡ（ｅｎｈａｎｃｅｄ  ｉｎｔｅｒｆｅｒｅｎｃｅ  ｍａｎａｇｅｍｅｎｔ  ａｎｄ  ｔｒａｆｆｉｃ  ａｄａｐｔａｔｉｏｎ）セル）される場合に、ｅＩＭＴＡ  ＵＥ（例、Ｒｅｌ−１２  ＵＥ）とレガシー（Ｌｅｇａｃｙ）ＵＥ（例、Ｒｅｌ−１１ＵＥ或いはＮｏｎ−ｅＩＭＴＡ（ｅｎｈａｎｃｅｄ  ｉｎｔｅｒｆｅｒｅｎｃｅ  ｍａｎａｇｅｍｅｎｔ  ａｎｄ  ｔｒａｆｆｉｃ  ａｄａｐｔａｔｉｏｎ）ＵＥ）との間に発生する、ＤＬ  ＨＡＲＱ−ＡＣＫと関連して暗黙的ＰＵＣＣＨリソース衝突（Ｉｍｐｌｉｃｉｔ  ＰＵＣＣＨ  Ｒｅｓｏｕｒｃｅ  Ｃｏｌｌｉｓｉｏｎ）の問題を解決するための方法を提案する。
【００７５】
本発明で、用途変更メッセージ（Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｍｅｓｓａｇｅ）は、事前に定義されたセル（例、プライマリＣｅｌｌ、ＰＣｅｌｌ）上で上位層シグナル形態（例、ＳＩＢ／ＰＢＣＨ／ＭＡＣ／ＲＲＣ）或いは物理層シグナル形態（例、ＰＤＣＣＨ／ＥＰＤＣＣＨ／ＰＤＳＣＨ）で送信される。また、当該用途変更メッセージは、端末特定的な（ＵＥ−Ｓｐｅｃｉｆｉｃ）特性、セル特定的な（Ｃｅｌｌ−Ｓｐｅｃｉｆｉｃ）特性、端末グループ特定的な（ＵＥ−Ｇｒｏｕｐ−Ｓｐｅｃｉｆｉｃ）特性、或いは端末グループ共通の（ＵＥ−Ｇｒｏｕｐ−Ｃｏｍｍｏｎ）特性を有することができる。さらに、用途変更メッセージは、事前に定義されたセル（例、ＰＣｅｌｌ）上でＵＳＳ（ＵＥ−Ｓｐｅｃｉｆｉｃ  Ｓｅａｒｃｈ  Ｓｐａｃｅ）或いはＣＳＳ（Ｃｏｍｍｏｎ  Ｓｅａｒｃｈ  Ｓｐａｃｅ）で送信されてもよい。
【００７６】
以下では、説明の便宜のために、３ＧＰＰ  ＬＴＥシステムに基づいて本発明を説明する。しかし、本発明が適用されるシステムの範囲は、３ＧＰＰ  ＬＴＥシステムだけでなく、他のシステムにも拡張可能である。また、本発明の実施例は、ｉ）ＴＤＤセルが搬送波集成技法（ＣＡ）で用いられ、集成されたセルの少なくとも一つ（すなわち、一部或いは全て）が無線リソース用途変更モードで動作す場合、及び／又はｉｉ）ＴＤＤセルとＦＤＤセルとの組合せが搬送波集成技法（例えば、ＴＤＤ  ＰＣｅｌｌとＦＤＤ  ＳＣｅｌｌの場合、或いはＦＤＤ  ＰＣｅｌｌとＴＤＤ  ＳＣｅｌｌの場合）で用いられ、集成されたＴＤＤセルの少なくとも一つ（すなわち、一部或いは全て）が無線リソース用途変更モードで動作する場合などでも拡張して適用可能である。
【００７７】
本発明に関する具体的な説明に先立ち、ｅＩＭＴＡ  ＵＥの観点では、表３の形態でＰＵＣＣＨリソース割り当て（ＰＵＣＣＨ  ＲＥＳＯＵＲＣＥ  ＡＬＬＯＣＡＴＩＯＮ）が行われていてもよい。言い換えると、ｅＩＭＴＡ  ＵＥと既存（Ｌｅｇａｃｙ）ＵＥ（或いはＮｏｎ−ｅＩＭＴＡ  ＵＥ）間に発生するＤＬ  ＨＡＲＱ−ＡＣＫ関連暗黙的ＰＵＣＣＨリソース衝突（Ｉｍｐｌｉｃｉｔ  ＰＵＣＣＨ  Ｒｅｓｏｕｒｃｅ  Ｃｏｌｌｉｓｉｏｎ）の問題を解決するために、表３のように定義されている。
【表３−１】
0006321201.tif 000007
【表３−２】
0006321201.tif 000008
【表３−３】
0006321201.tif 000009
【表３−４】
0006321201.tif 000010
【００７８】
図１２は、表３によるサブフレームインデクシングの一例を説明するための参考図である。
【００７９】
図１２で、ＳＩＢ−１上りリンク−下りリンク設定（ＳＩＢ−１ＵＬ−ＤＬ  ｃｏｎｆｉｇ）＃０であり、下りリンクＨＡＲＱ参照設定（ＤＬ  ＨＡＲＱ  ｒｅｆ  ｃｏｎｆｉｇ）＃４であり、上りリンクサブフレーム（ＵＬ  ｓｕｂｆｒａｍｅ  ＃２）である場合、第１タイプサブフレームに対しては上りリンクサブフレーム＃２で下りリンクサブフレーム＃６のＡＣＫの送信が定義されており、第２タイプサブフレームに対しては上りリンクサブフレーム＃２で下りリンクサブフレーム＃０，＃５，＃１のＡＣＫの送信が定義されており、第３タイプサブフレームに対しては上りリンクサブフレーム＃２で下りリンクサブフレーム＃４のＡＣＫの送信が定義されている。また、図１２の（ｘ−ｙ）表記で、ｘは上りリンクサブフレーム＃２でＡＣＫが送信される下りリンクサブフレームインデックスを表し、ｙは、下りリンクサブフレームｘ上の（ＰＤＣＣＨ領域内の）ＯＦＤＭシンボルインデックスを示す。
【００８０】
このように、第２タイプ及び／又は第３タイプサブフレームの暗黙的ＰＵＣＣＨリソース領域（Ｉｍｐｌｉｃｉｔ  ＰＵＣＣＨ  Ｒｅｓｏｕｒｃｅ  Ｒｅｇｉｏｎ）を第１タイプ（すなわち、「Ｆｉｘｅｄ  ｓｕｂｆｒａｍｅｓ  ｈａｖｉｎｇ  ｔｈｅ  ｓａｍｅ  ＨＡＲＱ  ｔｉｍｉｎｇ  ｆｏｒ  ｂｏｔｈ  ｅＩＭＴＡ  ａｎｄ  ｎｏｎ−ｅＩＭＴＡ  ＵＥｓ」）サブフレーム関連暗黙的ＰＵＣＣＨリソース領域（Ｉｍｐｌｉｃｉｔ  ＰＵＣＣＨ  Ｒｅｓｏｕｒｃｅ  Ｒｅｇｉｏｎ）と重ならないように指定するために、上述したよに、第１タイプサブフレーム関連暗黙的ＰＵＣＣＨリソース領域（Ｉｍｐｌｉｃｉｔ  ＰＵＣＣＨ  Ｒｅｓｏｕｒｃｅ  Ｒｅｇｉｏｎ）にＮoffsetを加えた領域位置を、第２タイプ及び／又は第３タイプ  ＳＦの暗黙的ＰＵＣＣＨリソース領域（Ｉｍｐｌｉｃｉｔ  ＰＵＣＣＨ  Ｒｅｓｏｕｒｃｅ  Ｒｅｇｉｏｎ）の開始点（Ｓｔａｒｔｉｎｇ  Ｐｏｉｎｔ）として定義することができる。ここで、Ｎoffsetは、大きく、２つの方法で定義することができる。
【００８１】
第一の方法は、ｅＮＢがｅＩＭＴＡ  ＵＥにＮoffset値を事前に定義されたシグナル（例、ＲＲＣ  Ｓｉｇｎａｌｉｎｇ）で知らせる方法である。このような方法は、一例として、ｅＮＢが、残っているＰＵＣＣＨリソースをＲＲＣシグナリングタイムスケール（ＲＲＣ  Ｓｉｇｎａｌｉｎｇ  Ｔｉｍｅ  Ｓｃａｌｅ）で柔軟に（Ｆｌｅｘｉｂｌｅ）運営できるという長所がある。しかし、該当のＮoffset値が、少なくともＲＲＣシグナリングタイムスケール（ＲＲＣ  Ｓｉｇｎａｌｉｎｇ  Ｔｉｍｅ  Ｓｃａｌｅ）の間には、異なる個数の第１タイプＤＬ／特別（Ｓｐｅｃｉａｌ）ＳＦが連動された別個の位置のＵＬ  ＳＦ上で共通して適用されるため、相対的に少ない個数の第１タイプＤＬ／特別ＳＦが連動されたＵＬ  ＳＦのためにはＮoffset値を最適化することができない（すなわち、ＰＵＣＣＨリソースの浪費、過度なＰＵＣＣＨリソースフラグメンテーションの発生）。
【００８２】
また、第一の方法は、特定ＵＬ  ＳＦと連動された第１タイプＤＬ／特別ＳＦ上の全ＣＣＥの個数が、時間によって変更（すなわち、ＤＬ／特別ＳＦ別にＰＣＦＩＣＨの値が動的に変更）されうるにもかかわらず、少なくともＲＲＣシグナリングタイムスケールの間にはそれを考慮／反映して特定ＵＬ  ＳＦ上に最適化されたＮoffset値を設定することができない（すなわち、ＰＵＣＣＨリソースブロックインターリーバ動作によるＰＵＣＣＨリソース節約（Ｒｅｓｏｕｒｃｅ  Ｓａｖｉｎｇ）効果を得ることができない）。以下では、説明の便宜のために、このような第一の方法を「［ＯＰＴＩＯＮ  ＃１］」と命名する。
【００８３】
第二の方法は、Ｎoffset値が（追加のシグナリング無しで）事前に定義された数式（Ｅｑｕａｔｉｏｎ）／設定／規則によって暗黙的に定義されるようにする方法である。例えば、Ｎoffset値は、
【数４】
0006321201.tif 000011
（すなわち、特定ＵＬ  ＳＦと連動された第１タイプＤＬ／特別ＳＦの全ＣＣＥの個数）で定義されてもよい。ここで、ＮCCE,mは、特定ＵＬ  ＳＦと連動された総Ｍ個のＳＦ（すなわち、表３のＴａｂｌｅ  ３−Ａを参照）のうち、（ｍ＋１）番目にＰＵＣＣＨリソースパッキング（Ｒｅｓｏｕｒｃｅ  Ｐａｃｋｉｎｇ）動作が適用されるＤＬ／特別ＳＦ上の全ＣＣＥの個数を意味する。
【００８４】
第二の方法は、上記の第一の方法に比べて、特定ＵＬ  ＳＦと連動された第１タイプＤＬ／特別ＳＦ上の全ＣＣＥの個数が時間によって変更されることを反映してＮoffset値を設定できるという長所がある。しかし、ｅＮＢが（残っている）ＰＵＣＣＨリソース（ＰＵＣＣＨ  Ｒｅｓｏｕｒｃｅ）を柔軟に運営できる余地が減る。以下では、説明の便宜のために、このような第二の方法を「［ＯＰＴＩＯＮ  ＃２］」と命名する。
【００８５】
なお、以下に説明する本発明の実施例は、第２タイプ（すなわち、「Ｆｉｘｅｄ  ｓｕｂｆｒａｍｅｓ  ｈａｖｉｎｇ  ｄｉｆｆｅｒｅｎｔ  ＨＡＲＱ  ｔｉｍｉｎｇ  ｆｏｒ  ｅＩＭＴＡ  ａｎｄ  ｎｏｎ−ｅＩＭＴＡ  ＵＥｓ」）及び／又は第３タイプ（すなわち、「Ｆｌｅｘｉｂｌｅ  ｓｕｂｆｒａｍｅｓ」）ＳＦの暗黙的ＰＵＣＣＨリソース領域（Ｉｍｐｌｉｃｉｔ  ＰＵＣＣＨ  Ｒｅｓｏｕｒｃｅ  Ｒｅｇｉｏｎ）を効率的に指定するための方法を提案する。また、本発明に関する説明の便宜のために、上述した方法（すなわち、［ＯＰＴＩＯＮ  ＃１］、［ＯＰＴＩＯＮ  ＃２］）を中心に本発明を説明する。しかし、本発明の実施例は、Ｎoffset設定のために、上述した方法ではなく他の方法が適用される場合にも拡張して適用することができる。
【００８６】
１．  第１方案
第１方案で、ｅＮＢがｅＩＭＴＡ  ＵＥに、事前に定義されたシグナル（例、物理層シグナル或いは上位層シグナル）を用いて、いかなるＮoffset設定方法が適用されるべきかを知らせるように（すなわち、Ｃｏｎｆｉｇｕｒａｂｉｌｉｔｙ）設定することができる。
【００８７】
例えば、ｅＮＢはｅＩＭＴＡ  ＵＥに、事前に定義された２つののＮoffset設定方法（すなわち、［ＯＰＴＩＯＮ＃１］、［ＯＰＴＩＯＮ＃２］）のいずれが適用されるかを、ＲＲＣシグナリング（例、１ビット）で知らせることができる。また、仮にｅＩＭＴＡ  ＵＥがｅＮＢからこのようなＲＲＣシグナリング（すなわち、いかなる種類のＮoffset設定方法が選択されたかを知らせるシグナル）を受信できないか、或いは仮にこのようなＲＲＣパラメータ（或いはＲＲＣシグナリング）が存在しないと、ｅＩＭＴＡ  ＵＥは、事前に定義されたデフォルト（Ｄｅｆａｕｌｔ）方法（例、［ＯＰＴＩＯＮ＃１］或いは［ＯＰＴＩＯＮ＃２］）が適用されると仮定することができる。
【００８８】
このような動作は、該当のＲＲＣシグナリングが選択的情報要素（Ｏｐｔｉｏｎａｌ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｅｌｅｍｅｎｔ（ＩＥ））（或いは、選択的パラメータ（Ｏｐｔｉｏｎａｌ  Ｐａｒａｍｅｔｅｒ））（すなわち、該当のパラメータが存在してもよく存在しなくてもよい。）と定義されたものと判断されてもよく、或いは該当のＲＲＣシグナリングのデフォルト値（Ｄｅｆａｕｌｔ  Ｖａｌｕｅ）が特定のＮoffset設定方法（例、［ＯＰＴＩＯＮ＃１］或いは［ＯＰＴＩＯＮ＃２］）を示す値に設定されたものと判断されてもよい。
【００８９】
２．  第２方案
第２方案で、基本的に、ＲＲＣシグナリングでＮoffset値を設定する方法［ＯＰＴＩＯＮ＃１］でｅＮＢがｅＩＭＴＡ  ＵＥにＮoffset値を知らせるが、当該ＲＲＣシグナリングを選択的情報要素（ＩＥ）（或いは選択的パラメータ）（すなわち、当該パラメータが存在してもよく、存在しなくてもよい。）と定義することができる。ここで、仮にｅＩＭＴＡ  ＵＥがｅＮＢから、ｉ）このようなＲＲＣシグナリング或いはＲＲＣパラメータを受信できなかったか、或いはｉｉ）仮に当該ＲＲＣパラメータ或いはＲＲＣシグナリングが存在しないと、ｅＩＭＴＡ  ＵＥは、事前に定義されたデフォルト（Ｄｅｆａｕｌｔ）方法（例、［ＯＰＴＩＯＮ＃２］）で計算されたＮoffset値が適用されると判断することができる。
【００９０】
他の例として、事前に該当ＲＲＣシグナリング或いはＲＲＣパラメータのデフォルト値（Ｄｅｆａｕｌｔ  Ｖａｌｕｅ）が、特定Ｎoffset設定方法（例、［ＯＰＴＩＯＮ＃２］）で計算される値として定義されてもよく、仮にｅＩＭＴＡ  ＵＥがｅＮＢから、ｉ）このようなＲＲＣシグナリング或いはＲＲＣパラメータを受信できないか、或いはｉｉ）仮に該当ＲＲＣパラメータ或いはＲＲＣシグナリングが存在しないと、該当のデフォルト値（Ｄｅｆａｕｌｔ  Ｖａｌｕｅ）を適用するように設定されてもよい。
【００９１】
さらに、この第２方案は、事前に定義されたＮoffset設定方法（すなわち、［ＯＰＴＩＯＮ  ＃１］、［ＯＰＴＩＯＮ  ＃２］）の一つを（ｅＮＢが）選択できる特性（すなわち、Ｃｏｎｆｉｇｕｒａｂｉｌｉｔｙ）を有すると判断してもよい。
【００９２】
３．  第３方案
第３方案で、基本的にＲＲＣシグナリングでＮoffset値を設定する方法（すなわち、ＯＰＴＩＯＮ  ＃１）の方法でｅＮＢがｅＩＭＴＡ  ＵＥにＮoffset値を知らせるが、仮にｅＩＭＴＡ  ＵＥがｅＮＢから、ｉ）このようなＲＲＣシグナリング或いはＲＲＣパラメータを受信できなかったか、或いはｉｉ）仮に当該ＲＲＣパラメータ或いはＲＲＣシグナリングが存在しないと、ｅＩＭＴＡ  ＵＥは、事前に定義されたデフォルト（Ｄｅｆａｕｌｔ）方法（例、ＯＰＴＩＯＮ  ＃２）で計算されたＮoffset値が適用されると判断することができる。
【００９３】
例えば、事前に当該ＲＲＣシグナリング或いはＲＲＣパラメータのデフォルト値（Ｄｅｆａｕｌｔ  Ｖａｌｕｅ）が、特定Ｎoffset設定方法（例、ＯＰＴＩＯＮ  ＃２）で計算される値として定義されたと判断することができ、したがって、仮にｅＩＭＴＡ  ＵＥがｅＮＢから、ｉ）このようなＲＲＣシグナリング或いはＲＲＣパラメータを受信できないか、或いはｉｉ）仮に当該ＲＲＣパラメータ或いはＲＲＣシグナリングが存在しないと、該当のデフォルト値（Ｄｅｆａｕｌｔ  Ｖａｌｕｅ）を適用すると判断することができる。
【００９４】
さらに、この第３方案は、事前に定義されたＮoffset設定方法（すなわち、ＯＰＴＩＯＮ  ＃１、ＯＰＴＩＯＮ  ＃２）の一つを（ｅＮＢが）選択できる（すなわち、Ｃｏｎｆｉｇｕｒａｂｉｌｉｔｙ）特性を有すると判断してもよい。
【００９５】
４．  第４方案
本発明の第４方案によれば、搬送波集成技法（ＣＡ）が適用された状況下で、少なくとも一つのセル（或いは、全てのセル）が無線リソース動的変更モード（すなわち、ｅＩＭＴＡ−ｅｎａｂｌｅｄ  Ｃｅｌｌ）で動作する場合に、特定セル関連「ＨＡＲＱ−ＡＣＫ  ＢＩＴＳ  ＯＲＤＥＲＩＮＧ（ｆｏｒ  ＰＵＣＣＨ  ＦＯＲＭＡＴ  １ｂ  ＷＩＴＨ  ＣＨＡＮＮＥＬ  ＳＥＬＥＣＴＩＯＮ）（すなわち、上記の表３を参照）」と「ＰＵＣＣＨリソース割り当て（ＰＵＣＣＨ  ＲＥＳＯＵＲＣＥ  ＡＬＬＯＣＡＴＩＯＮ）」は、以下に記述する、規則＃１−１乃至規則＃２−３の少なくとも一つ（すなわち、一部或いは全て）の規則に従うように設定することができる。
【００９６】
以下では、説明の便宜のために、２個のセル（或いはコンポーネントキャリア）が搬送波集成技法で用いられる状況を仮定したが、本発明の実施例を、３個以上のセル（或いはコンポーネントキャリア）が搬送波集成技法で用いられる状況でも拡張して適用可能であることは明らかである。また、以下では説明の便宜のために、２個のセルをそれぞれＰＣｅｌｌ（Ｐｒｉｍａｒｙ  Ｃｅｌｌ）、ＳＣｅｌｌ（Ｓｅｃｏｎｄａｒｙ  Ｃｅｌｌ）と命名する。また、以下の規則は、ＰＣｅｌｌ或いはＳＣｅｌｌのｉ）ＰＵＣＣＨ  ＦＯＲＭＡＴ  １ｂ  ＷＩＴＨ  ＣＨＡＮＮＥＬ  ＳＥＬＥＣＴＩＯＮ関連バンドリングウィンドウ（ＢＵＮＤＬＩＮＧ  ＷＩＮＤＯＷ）サイズが４である場合、及び／又はｉｉ）搬送波集成技法（ＣＡ）が適用された場合に限って適用されるように設定されてもよい。
【００９７】
まず、セルフスケジューリング（Ｓｅｌｆ−Ｓｃｈｅｄｕｌｉｎｇ）の場合を中心に規則＃１−１乃至規則＃１−３を説明する。
【００９８】
４−１．  規則＃１−１：ｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＰＣｅｌｌとＮｏｎ  ｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＳＣｅｌｌ
まず、ｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＰＣｅｌｌの場合（実施例＃１−１−Ａ）、ＰＵＣＣＨリソース割り当て（ＰＵＣＣＨ  ＲＥＳＯＵＲＣＥ  ＡＬＬＯＣＡＴＩＯＮ）に対して、最終決定されたＰＣｅｌｌの下りリンクＨＡＲＱ参照設定（ＤＬ  ＨＡＲＱ  ＲＥＦＥＲＥＮＣＥ  ＣＯＮＦＩＧＵＲＡＴＩＯＮ）によってＨＡＲＱ−ＡＣＫを送信するが、暗黙的ＰＵＣＣＨリソーススタッキング（ＩＭＰＬＩＣＩＴ  ＰＵＣＣＨ  ＲＥＳＯＵＲＣＥ  ＳＴＡＣＫＩＮＧ）、ブロックインターリービング（ＢＬＯＣＫ  ＩＮＴＥＲＬＥＡＶＩＮＧ）、及びＮoffsetシグナリングは、上記の表３にしたがって行われるように定義することができる。
【００９９】
また、ｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＰＣｅｌｌの場合、ＨＡＲＱ−ＡＣＫビットオーダリング（ＨＡＲＱ−ＡＣＫ  ＢＩＴＳ  ＯＲＤＥＲＩＮＧ）に対して、上記の表３で説明されたＰＣｅｌｌ下りリンクＨＡＲＱ参照設定（ＤＬ  ＨＡＲＱ  ＲＥＦＥＲＥＮＣＥ  ＣＯＮＦＩＧＵＲＡＴＩＯＮ）にマッチされる暗黙的ＰＵＣＣＨリソーススタッキング（ＩＭＰＬＩＣＩＴ  ＰＵＣＣＨ  ＲＥＳＯＵＲＣＥ  ＳＴＡＣＫＩＮＧ）関連サブフレームインデックス順序（すなわち、Ｔａｂｌｅ３−Ａ、Ｔａｂｌｅ３−Ｂ）によってＨＡＲＱ−ＡＣＫビットオーダリングが行われるように定義されてもよい。
【０１００】
次に、Ｎｏｎ  ｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＳＣｅｌｌの場合（実施例＃１−１−Ｂ）、ＰＵＣＣＨリソース割り当てに対して、最終決定されたＳＣｅｌｌの下りリンクＨＡＲＱ参照設定によってＨＡＲＱ−ＡＣＫを送信するが、ＰＵＣＣＨリソースは事前にＲＲＣシグナルされたリソースを用いるように定義される（例えば、ＡＲＩ（ＡＣＫ／ＮＡＣＫ  ｒｅｓｏｕｒｃｅ  ｉｎｄｉｃａｔｏｒ）フィールドを用いる）。
【０１０１】
さらに、Ｎｏｎ  ｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＳＣｅｌｌの場合、ＨＡＲＱ−ＡＣＫビットオーダリングは、上記の表３で説明されたＳＣｅｌｌの下りリンクＨＡＲＱ参照設定にマッチされる暗黙的ＰＵＣＣＨリソーススタッキング（ＩＭＰＬＩＣＩＴ  ＰＵＣＣＨ  ＲＥＳＯＵＲＣＥ  ＳＴＡＣＫＩＮＧ）関連サブフレームインデックス順序（すなわち、Ｔａｂｌｅ３−Ａ、Ｔａｂｌｅ３−Ｂ）によってＨＡＲＱ−ＡＣＫビットオーダリングが行われるように設定されてもよい。
【０１０２】
また、Ｎｏｎ  ｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＳＣｅｌｌの場合（実施例＃１−１−Ｃ）、ＰＵＣＣＨリソース割り当てに対して、最終決定されたＳＣｅｌｌの下りリンクＨＡＲＱ参照設定によってＨＡＲＱ−ＡＣＫを送信するが、ＰＵＣＣＨリソースは、事前にＲＲＣシグナルされたリソースを用いるように定義されてもよい（例えば、ＡＲＩフィールドを用いる）。
【０１０３】
さらに、Ｎｏｎ  ｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＳＣｅｌｌの場合、ＨＡＲＱ−ＡＣＫビットオーダリングは、最終決定されたＳＣｅｌｌの下りリンクＨＡＲＱ参照設定にマッチされる既存（例えば、Ｒｅｌ−１１）サブフレームインデックス順でＨＡＲＱ−ＡＣＫビットオーダリングが行われるように定義されてもよい。
【０１０４】
４−２．  規則＃１−２：ｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＰＣｅｌｌとｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＳＣｅｌｌ
まず、ｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＰＣｅｌｌの場合（実施例＃１−２−Ｄ）、ＰＵＣＣＨリソース割り当ては、最終決定されたＰＣｅｌｌ下りリンクＨＡＲＱ参照設定によってＨＡＲＱ−ＡＣＫを送信するが、暗黙的ＰＵＣＣＨリソーススタッキング（ＩＭＰＬＩＣＩＴ  ＰＵＣＣＨ  ＲＥＳＯＵＲＣＥ  ＳＴＡＣＫＩＮＧ）、ブロックインターリービング、及びＮoffsetシグナリングは上記の表３によって行われるように定義することができる。
【０１０５】
また、ｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＰＣｅｌｌの場合におけるＨＡＲＱ−ＡＣＫビットオーダリングは、上記の表３で説明されたＰＣｅｌｌの下りリンクＨＡＲＱ参照設定にマッチされる暗黙的ＰＵＣＣＨリソーススタッキング（ＩＭＰＬＩＣＩＴ  ＰＵＣＣＨ  ＲＥＳＯＵＲＣＥ  ＳＴＡＣＫＩＮＧ）関連サブフレームインデックス順序（すなわち、Ｔａｂｌｅ３−Ａ、Ｔａｂｌｅ３−Ｂ）によってＨＡＲＱ−ＡＣＫビットオーダリングが行われるように定義されてもよい。
【０１０６】
また、ｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＳＣｅｌｌの場合（実施例＃１−２−Ｅ）において、ＰＵＣＣＨリソース割り当ては、最終決定されたＳＣｅｌｌの下りリンクＨＡＲＱ参照設定によってＨＡＲＱ−ＡＣＫを送信するが、ＰＵＣＣＨリソースは、事前にＲＲＣシグナルされたリソースを用いるように定義されてもよい（例えば、ＡＲＩフィールドを用いる）。
【０１０７】
さらに、ｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＳＣｅｌｌの場合、ＨＡＲＱ−ＡＣＫビットオーダリングは、上記の表３で説明されたＳＣｅｌｌの下りリンクＨＡＲＱ参照設定にマッチされる暗黙的ＰＵＣＣＨリソーススタッキング（ＩＭＰＬＩＣＩＴ  ＰＵＣＣＨ  ＲＥＳＯＵＲＣＥ  ＳＴＡＣＫＩＮＧ）関連サブフレームインデックス順序（すなわち、Ｔａｂｌｅ３−Ａ、Ｔａｂｌｅ３−Ｂ）によってＨＡＲＱ−ＡＣＫビットオーダリング（ＨＡＲＱ−ＡＣＫ  ＢＩＴＳ  ＯＲＤＥＲＩＮＧ）が行われるように定義されてもよい。
【０１０８】
また、ｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＳＣｅｌｌの場合（実施例＃１−２−Ｆ）と関連して、ＰＵＣＣＨリソース割り当ては、最終決定されたＳＣｅｌｌの下りリンクＨＡＲＱ参照設定によってＨＡＲＱ−ＡＣＫを送信するが、ＰＵＣＣＨリソースは、事前にＲＲＣシグナルされたリソースを用いるように定義されてもよい（例えば、ＡＲＩフィールドを用いる）。
【０１０９】
さらに、ｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＳＣｅｌｌの場合、ＨＡＲＱ−ＡＣＫビットオーダリングは、最終決定されたＳＣｅｌｌの下りリンクＨＡＲＱ参照設定にマッチされる既存（例えば、Ｒｅｌ−１１）サブフレームインデックス順でＨＡＲＱ−ＡＣＫビットオーダリングが行われるように定義されてもよい。
【０１１０】
４−３．  規則＃１−３：Ｎｏｎ  ｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＰＣｅｌｌとｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＳＣｅｌｌ
まず、Ｎｏｎ  ｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＰＣｅｌｌの場合（実施例＃１−３−Ｇ）と関連して、ＰＵＣＣＨリソース割り当ては、最終決定されたＰＣｅｌｌ下りリンクＨＡＲＱ参照設定によってＨＡＲＱ−ＡＣＫを送信するが、暗黙的ＰＵＣＣＨリソーススタッキング（ＩＭＰＬＩＣＩＴ  ＰＵＣＣＨ  ＲＥＳＯＵＲＣＥ  ＳＴＡＣＫＩＮＧ）関連全てのパラメータ及び動作は、既存（例えば、Ｒｅｌ−１１）動作に従うように定義することができる。すなわち、上記の表３で説明された暗黙的ＰＵＣＣＨリソーススタッキング（ＩＭＰＬＩＣＩＴ  ＰＵＣＣＨ  ＲＥＳＯＵＲＣＥ  ＳＴＡＣＫＩＮＧ）、ブロックインターリービング、及びＮoffsetシグナリングは適用されないように定義することができる。
【０１１１】
さらに、Ｎｏｎ  ｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＰＣｅｌｌの場合、ＨＡＲＱ−ＡＣＫビットオーダリングは、最終決定されたＰＣｅｌｌ下りリンクＨＡＲＱ参照設定にマッチされる既存（例えば、Ｒｅｌ−１１）サブフレームインデックス順でＨＡＲＱ−ＡＣＫビットオーダリングが行われるように定義されてもよい。
【０１１２】
次に、ｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＳＣｅｌｌの場合（実施例＃１−３−Ｈ）、ＰＵＣＣＨリソース割り当ては、最終決定されたＳＣｅｌｌ下りリンクＨＡＲＱ参照設定によってＨＡＲＱ−ＡＣＫを送信するが、ＰＵＣＣＨリソースは、事前にＲＲＣシグナルされたリソースを用いるように定義されてもよい（例えば、ＡＲＩフィールドを用いる）。
【０１１３】
さらに、ｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＳＣｅｌｌの場合、ＨＡＲＱ−ＡＣＫビットオーダリングは、上記の表３で説明されたＳＣｅｌｌ下りリンクＨＡＲＱ参照設定にマッチされる暗黙的ＰＵＣＣＨリソーススタッキング（ＩＭＰＬＩＣＩＴ  ＰＵＣＣＨ  ＲＥＳＯＵＲＣＥ  ＳＴＡＣＫＩＮＧ）関連サブフレームインデックス順序（すなわち、Ｔａｂｌｅ３−Ａ、Ｔａｂｌｅ３−Ｂ）によってＨＡＲＱ−ＡＣＫビットオーダリングが行われるように定義されてもよい。
【０１１４】
また、ｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＳＣｅｌｌの場合（実施例＃１−３−Ｉ）、ＰＵＣＣＨリソース割り当ては、最終決定されたＳＣｅｌｌ下りリンクＨＡＲＱ参照設定によってＨＡＲＱ−ＡＣＫを送信するが、ＰＵＣＣＨリソースは、事前にＲＲＣシグナルされたリソースを用いるように定義されてもよい（例えば、ＡＲＩフィールドを用いる）。
【０１１５】
さらに、ｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＳＣｅｌｌの場合、ＨＡＲＱ−ＡＣＫビットオーダリングは、最終決定されたＳＣｅｌｌの下りリンクＨＡＲＱ参照設定にマッチされる既存（例えば、Ｒｅｌ−１１）サブフレームインデックス順でＨＡＲＱ−ＡＣＫビットオーダリングが行われるように定義されてもよい。
【０１１６】
次に、クロスキャリアスケジューリング（Ｃｒｏｓｓ  Ｃａｒｒｉｅｒ  Ｓｃｈｅｄｕｌｉｎｇ）の場合を中心に規則＃２−１乃至規則＃２−３を説明する。
【０１１７】
４−４．  規則＃２−１：ｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＰＣｅｌｌとＮｏｎ  ｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＳＣｅｌｌ
まず、ｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＰＣｅｌｌの場合（実施例＃２−１−Ｊ）、ＰＵＣＣＨリソース割り当ては、最終決定されたＰＣｅｌｌ下りリンクＨＡＲＱ参照設定によってＨＡＲＱ−ＡＣＫを送信するが、暗黙的ＰＵＣＣＨリソーススタッキング（ＩＭＰＬＩＣＩＴ  ＰＵＣＣＨ  ＲＥＳＯＵＲＣＥ  ＳＴＡＣＫＩＮＧ）、ブロックインターリービング、及びＮoffsetシグナリングは、上記の表３によって行われるように定義されてもよい。
【０１１８】
さらに、ｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＰＣｅｌｌの場合、ＨＡＲＱ−ＡＣＫビットオーダリングは、上記の表３で説明されたＰＣｅｌｌ下りリンクＨＡＲＱ参照設定にマッチされる暗黙的ＰＵＣＣＨリソーススタッキング（ＩＭＰＬＩＣＩＴ  ＰＵＣＣＨ  ＲＥＳＯＵＲＣＥ  ＳＴＡＣＫＩＮＧ）関連サブフレームインデックス順序（すなわち、Ｔａｂｌｅ３−Ａ、Ｔａｂｌｅ３−Ｂ）によってＨＡＲＱ−ＡＣＫビットオーダリングが行われるように定義されてもよい。
【０１１９】
また、Ｎｏｎ  ｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＳＣｅｌｌの場合（実施例＃２−１−Ｋ）、ＰＵＣＣＨリソース割り当てと関連して、最終決定されたＳＣｅｌｌ下りリンクＨＡＲＱ参照設定によってＨＡＲＱ−ＡＣＫを送信するが、ＳＣｅｌｌ下りリンクＨＡＲＱ参照設定にマッチされる暗黙的ＰＵＣＣＨリソーススタッキング（ＩＭＰＬＩＣＩＴ  ＰＵＣＣＨ  ＲＥＳＯＵＲＣＥ  ＳＴＡＣＫＩＮＧ）、ブロックインターリービング、及びＮoffsetシグナリングは、上記の表３によって行われるように定義されてもよい。
【０１２０】
さらに、Ｎｏｎ  ｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＳＣｅｌｌの場合、ＨＡＲＱ−ＡＣＫビットオーダリングは、上記の表３で説明されたＳＣｅｌｌ下りリンクＨＡＲＱ参照設定にマッチされる暗黙的ＰＵＣＣＨリソーススタッキング（ＩＭＰＬＩＣＩＴ  ＰＵＣＣＨ  ＲＥＳＯＵＲＣＥ  ＳＴＡＣＫＩＮＧ）関連サブフレームインデックス順序（すなわち、Ｔａｂｌｅ３−Ａ、Ｔａｂｌｅ３−Ｂ）によってＨＡＲＱ−ＡＣＫビットオーダリングが行われるように定義されてもよい。
【０１２１】
また、Ｎｏｎ  ｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＳＣｅｌｌの場合（実施例＃Ｌ）、ＰＵＣＣＨリソース割り当ては、最終決定されたＳＣｅｌｌ下りリンクＨＡＲＱ参照設定によってＨＡＲＱ−ＡＣＫを送信するが、ＳＣｅｌｌ下りリンクＨＡＲＱ参照設定にマッチされる暗黙的ＰＵＣＣＨリソーススタッキング（ＩＭＰＬＩＣＩＴ  ＰＵＣＣＨ  ＲＥＳＯＵＲＣＥ  ＳＴＡＣＫＩＮＧ）、ブロックインターリービング、及びＮoffsetシグナリングは、上記の表３によって行われるように定義されてもよい。
【０１２２】
さらに、Ｎｏｎ  ｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＳＣｅｌｌの場合、ＨＡＲＱ−ＡＣＫビットオーダリングは、最終決定されたＳＣｅｌｌの下りリンクＨＡＲＱ参照設定にマッチされる既存（例えば、Ｒｅｌ−１１）サブフレームインデックス順でＨＡＲＱ−ＡＣＫビットオーダリング（ＨＡＲＱ−ＡＣＫ  ＢＩＴＳ  ＯＲＤＥＲＩＮＧ）が行われるように定義されてもよい。
【０１２３】
４−５．  規則＃２−２：ｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＰＣｅｌｌとｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＳＣｅｌｌ
まず、ｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＰＣｅｌｌの場合（実施例＃２−２−Ｍ）、ＰＵＣＣＨリソース割り当ては、最終決定されたＰＣｅｌｌ下りリンクＨＡＲＱ参照設定によってＨＡＲＱ−ＡＣＫを送信するが、暗黙的ＰＵＣＣＨリソーススタッキング（ＩＭＰＬＩＣＩＴ  ＰＵＣＣＨ  ＲＥＳＯＵＲＣＥ  ＳＴＡＣＫＩＮＧ）、ブロックインターリービング、及びＮoffsetシグナリングは、上記の表３によって行われるように定義することができる。
【０１２４】
さらに、ｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＰＣｅｌｌの場合、ＨＡＲＱ−ＡＣＫビットオーダリングは、上記の表３で説明されたＰＣｅｌｌ下りリンクＨＡＲＱ参照設定にマッチされる暗黙的ＰＵＣＣＨリソーススタッキング（ＩＭＰＬＩＣＩＴ  ＰＵＣＣＨ  ＲＥＳＯＵＲＣＥ  ＳＴＡＣＫＩＮＧ）関連サブフレームインデックス順序（すなわち、Ｔａｂｌｅ３−Ａ、Ｔａｂｌｅ３−Ｂ）によってＨＡＲＱ−ＡＣＫビットオーダリング（ＨＡＲＱ−ＡＣＫ  ＢＩＴＳ  ＯＲＤＥＲＩＮＧ）が行われるように定義されてもよい。
【０１２５】
また、ｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＳＣｅｌｌの場合（実施例＃２−２−Ｎ）、ＰＵＣＣＨリソース割り当ては、最終決定されたＳＣｅｌｌ下りリンクＨＡＲＱ参照設定によってＨＡＲＱ−ＡＣＫを送信するが、ＳＣｅｌｌ下りリンクＨＡＲＱ参照設定にマッチされる暗黙的ＰＵＣＣＨリソーススタッキング（ＩＭＰＬＩＣＩＴ  ＰＵＣＣＨ  ＲＥＳＯＵＲＣＥ  ＳＴＡＣＫＩＮＧ）、ブロックインターリービング、及びＮoffsetシグナリングは、上記の表３によって行われるように定義されてもよい。
【０１２６】
さらに、ｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＳＣｅｌｌの場合、ＨＡＲＱ−ＡＣＫビットオーダリングは、上記の表３で説明されたＳＣｅｌｌ下りリンクＨＡＲＱ参照設定にマッチされる暗黙的ＰＵＣＣＨリソーススタッキング（ＩＭＰＬＩＣＩＴ  ＰＵＣＣＨ  ＲＥＳＯＵＲＣＥ  ＳＴＡＣＫＩＮＧ）関連サブフレームインデックス順序（すなわち、Ｔａｂｌｅ３−Ａ、Ｔａｂｌｅ３−Ｂ）によってＨＡＲＱ−ＡＣＫビットオーダリングが行われるように定義されてもよい。
【０１２７】
次に、ｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＳＣｅｌｌの場合（実施例＃２−２−Ｏ）、ＰＵＣＣＨリソース割り当ては、最終決定されたＳＣｅｌｌ下りリンクＨＡＲＱ参照設定によってＨＡＲＱ−ＡＣＫを送信するが、ＳＣｅｌｌ下りリンクＨＡＲＱ参照設定にマッチされる暗黙的ＰＵＣＣＨリソーススタッキング（ＩＭＰＬＩＣＩＴ  ＰＵＣＣＨ  ＲＥＳＯＵＲＣＥ  ＳＴＡＣＫＩＮＧ）、ブロックインターリービング、及びＮoffsetシグナリングは、上記の表３によって行われるように定義されてもよい。
【０１２８】
さらに、ＨＡＲＱ−ＡＣＫビットオーダリングは、最終決定されたＳＣｅｌｌの下りリンクＨＡＲＱ参照設定にマッチされる既存（例えば、Ｒｅｌ−１１）サブフレームインデックス順でＨＡＲＱ−ＡＣＫビットオーダリングが行われるように定義されてもよい。
【０１２９】
４−６．  規則＃２−３：Ｎｏｎ  ｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＰＣｅｌｌとｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＳＣｅｌｌ
まず、Ｎｏｎ  ｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＰＣｅｌｌの場合（実施例＃２−３−Ｐ）、ＰＵＣＣＨリソース割り当ては、最終決定されたＰＣｅｌｌ下りリンクＨＡＲＱ参照設定によってＨＡＲＱ−ＡＣＫを送信するが、暗黙的ＰＵＣＣＨリソーススタッキング（ＩＭＰＬＩＣＩＴ  ＰＵＣＣＨ  ＲＥＳＯＵＲＣＥ  ＳＴＡＣＫＩＮＧ）関連全てのパラメータ及び動作は、既存（ｌｅｇａｃｙ）ＬＴＥ（例えば、Ｒｅｌ−１１）動作に従うように定義することができる。すなわち、上記の表３で説明された暗黙的ＰＵＣＣＨリソーススタッキング（ＩＭＰＬＩＣＩＴ  ＰＵＣＣＨ  ＲＥＳＯＵＲＣＥ  ＳＴＡＣＫＩＮＧ）、ブロックインターリービング、及びＮoffsetシグナリングが適用されない。
【０１３０】
さらに、Ｎｏｎ  ｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＰＣｅｌｌの場合、ＨＡＲＱ−ＡＣＫビットオーダリングは、最終決定されたＰＣｅｌｌ下りリンクＨＡＲＱ参照設定にマッチされる既存（例えば、Ｒｅｌ−１１）サブフレームインデックス順でＨＡＲＱ−ＡＣＫビットオーダリングが行われるように定義されてもよい。
【０１３１】
次に、ｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＳＣｅｌｌ（実施例＃２−３−Ｑ）の場合、ＰＵＣＣＨリソース割り当ては、最終決定されたＳＣｅｌｌ下りリンクＨＡＲＱ参照設定によってＨＡＲＱ−ＡＣＫを送信するが、暗黙的ＰＵＣＣＨリソーススタッキング（ＩＭＰＬＩＣＩＴ  ＰＵＣＣＨ  ＲＥＳＯＵＲＣＥ  ＳＴＡＣＫＩＮＧ）関連全てのパラメータ及び動作は、既存（ｌｅｇａｃｙ）ＬＴＥ（例えば、Ｒｅｌ−１１）動作に従うように定義されてもよい。すなわち、上記の表３で説明された暗黙的ＰＵＣＣＨリソーススタッキング（ＩＭＰＬＩＣＩＴ  ＰＵＣＣＨ  ＲＥＳＯＵＲＣＥ  ＳＴＡＣＫＩＮＧ）、ブロックインターリービング、及びＮoffsetシグナリングが適用されなくてもよい。
【０１３２】
さらに、ｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＳＣｅｌｌの場合、ＨＡＲＱ−ＡＣＫビットオーダリングは、上記の表３で説明されたＳＣｅｌｌ下りリンクＨＡＲＱ参照設定にマッチされる暗黙的ＰＵＣＣＨリソーススタッキング（ＩＭＰＬＩＣＩＴ  ＰＵＣＣＨ  ＲＥＳＯＵＲＣＥ  ＳＴＡＣＫＩＮＧ）関連サブフレームインデックス順序（すなわち、Ｔａｂｌｅ３−Ａ、Ｔａｂｌｅ３−Ｂ）によってＨＡＲＱ−ＡＣＫビットオーダリングが行われるように定義されてもよい。
【０１３３】
また、ｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＳＣｅｌｌの場合（実施例＃２−３−Ｒ）、ＰＵＣＣＨリソース割り当ては、最終決定されたＳＣｅｌｌ下りリンクＨＡＲＱ参照設定によってＨＡＲＱ−ＡＣＫを送信するが、暗黙的ＰＵＣＣＨリソーススタッキング（ＩＭＰＬＩＣＩＴ  ＰＵＣＣＨ  ＲＥＳＯＵＲＣＥ  ＳＴＡＣＫＩＮＧ）関連全てのパラメータ及び動作は、既存（ｌｅｇａｃｙ）ＬＴＥ（例えば、Ｒｅｌ−１１）動作に従うように定義されてもよい。すなわち、上記の表３で説明された暗黙的ＰＵＣＣＨリソーススタッキング（ＩＭＰＬＩＣＩＴ  ＰＵＣＣＨ  ＲＥＳＯＵＲＣＥ  ＳＴＡＣＫＩＮＧ）、ブロックインターリービング、及びＮoffsetシグナリングが適用されない。
【０１３４】
さらに、ｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＳＣｅｌｌの場合、ＨＡＲＱ−ＡＣＫビットオーダリングは、最終決定されたＳＣｅｌｌの下りリンクＨＡＲＱ参照設定にマッチされる既存（ｌｅｇａｃｙ）ＬＴＥ（例えば、Ｒｅｌ−１１）サブフレームインデックス順でＨＡＲＱ−ＡＣＫビットオーダリングが行われるように定義されてもよい。
【０１３５】
また、ｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＳＣｅｌｌの場合（実施例＃２−３−Ｓ）、ＰＵＣＣＨリソース割り当ては、最終決定されたＳＣｅｌｌ下りリンクＨＡＲＱ参照設定によってＨＡＲＱ−ＡＣＫを送信するが、暗黙的ＰＵＣＣＨリソーススタッキング（ＩＭＰＬＩＣＩＴ  ＰＵＣＣＨ  ＲＥＳＯＵＲＣＥ  ＳＴＡＣＫＩＮＧ）関連全てのパラメータ及び動作は、既存（ｌｅｇａｃｙ）ＬＴＥ（例えば、Ｒｅｌ−１１）動作に従うように定義されてもよい。すなわち、上記の表３で説明された暗黙的ＰＵＣＣＨリソーススタッキング（ＩＭＰＬＩＣＩＴ  ＰＵＣＣＨ  ＲＥＳＯＵＲＣＥ  ＳＴＡＣＫＩＮＧ）、ブロックインターリービング、及びＮoffsetシグナリングが適用されない。
【０１３６】
さらに、ｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＳＣｅｌｌの場合、ＨＡＲＱ−ＡＣＫビットオーダリングは、最終決定されたＳＣｅｌｌの下りリンクＨＡＲＱ参照設定にマッチされる既存（ｌｅｇａｃｙ）ＬＴＥ（例えば、Ｒｅｌ−１１）サブフレームインデックス順でＨＡＲＱ−ＡＣＫビットオーダリングが行われるように定義されてもよい。
【０１３７】
特徴的に、セル（或いはコンポーネントキャリア）別ｅｉｍｔａ−モード設定（ｅｉｍｔａ−ｍｏｄｅ  ｃｏｎｆｉｇｕｒａｔｉｏｎ）の有無及びセルフ／クロースキャリアスケジューリング（Ｓｅｌｆ／Ｃｒｏｓｓ  Ｃａｒｒｉｅｒ  Ｓｃｈｅｄｕｌｉｎｇ）設定の有無によって、以下の規則を組み合わせて、ＳＣｅｌｌに対するＰＵＣＣＨリソース割り当て及びＨＡＲＱ−ＡＣＫビットオーダリングを適用することができる。
−  セルフスケジューリング（Ｓｅｌｆ−Ｓｃｈｅｄｕｌｉｎｇ）の場合：
・ ｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＰＣｅｌｌとＮｏｎ  ｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＳＣｅｌｌの場合：（実施例＃１−１−Ｃ）
・ ｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＰＣｅｌｌとｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＳＣｅｌｌの場合：（実施例＃１−２−Ｅ）
・ Ｎｏｎ  ｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＰＣｅｌｌとｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＳＣｅｌｌの場合：（実施例＃１−３−Ｈ）
−  クロス−キャリアスケジューリング（Ｃｒｏｓｓ  Ｃａｒｒｉｅｒ  Ｓｃｈｅｄｕｌｉｎｇ）の場合、
・ ｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＰＣｅｌｌとＮｏｎ  ｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＳＣｅｌｌの場合：（実施例＃２−１−Ｌ）
・ ｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＰＣｅｌｌとｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＳＣｅｌｌの場合：（実施例＃２−２−Ｎ）
・ Ｎｏｎ  ｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＰＣｅｌｌとｅＩＭＴＡ−ｅｎａｂｌｅｄ  ＳＣｅｌｌの場合：（実施例＃２−３−Ｓ）
【０１３８】
以上、上述した本発明の実施例は、搬送波集成技法（ＣＡ）が適用された状況下で、ｉ）少なくとも一つの特定セルの無線リソース用途が負荷状態によって動的に変更される場合、或いはｉｉ）少なくとも一つの特定セルの送信モード（ＴＭ）が事前に定義された送信モードに指定される場合、或いはｉｉｉ）少なくとも一つの特定セル（例えば、ＴＤＤ  ｅＩＭＴＡ  Ｃｅｌｌ）の上りリンク−下りリンク設定（ＵＬ−ＤＬ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ）が特定値に（再）設定された場合、或いはｉｖ）クロスキャリアスケジューリング（Ｃｒｏｓｓ  Ｃａｒｒｉｅｒ  Ｓｃｈｅｄｕｌｉｎｇ）が設定された場合、或いはｖ）セルフスケジューリング（Ｓｅｌｆ−Ｓｃｈｅｄｕｌｉｎｇ）が設定された場合、の少なくとも一つの場合に限って適用されるように設定することができる。
【０１３９】
上述した本発明の実施例／設定／規則も本発明の具現方法の一として含まれてもよいため、一種の独立した方案として見なされてもよいことは明らかである。また、上述した実施例／設定／規則／方案は、独立して具現されてもよいが、一部の実施例の組合せ或いは併合の形態で具現されてもよい。
【０１４０】
さらに、上述した本発明の実施例／設定／規則／方案に関する情報、或いは当該実施例／設定／規則／方案を適用するか否かに関する情報などは、基地局が端末に事前に定義されたシグナル（例えば、物理層或いは上位層シグナル）で知らせることができる。
【０１４１】
さらに、上述した本発明の実施例は、別個のＴＤＤ上りリンク−下りリンク設定（ｄｉｆｆｅｒｅｎｔ  ＴＤＤ  ＵＬ−ＤＬ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ（例えば、ＳＩＢ１  ＵＬ−ＤＬ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ（ＰＣｅｌｌ）、ＲａｄｉｏＲｅｓｏｕｒｃｅＣｏｎｆｉｇＣｏｍｍｏｎＳＣｅｌｌ  ＩＥ（ＳＣｅｌｌ））を有するセルが搬送波集成技法（ＣＡ）で用いられ、これらのセルのうち少なくとも一つのセルの無線リソース用途が負荷状態によって動的に変更される場合にも拡張して適用可能である。
【０１４２】
図１３には、本発明の一実施例に適用可能な基地局及び端末を例示する。
【０１４３】
無線通信システムにリレーが含まれる場合、バックホールリンクで通信は基地局とリレーとの間に行われ、アクセスリンクで通信はリレーと端末との間に行われる。したがって、図面に例示された基地局又は端末は状況によってリレーに置き換わってよい。
【０１４４】
図１３を参照すると、無線通信システムは、基地局（ＢＳ）１１０及び端末（ＵＥ）１２０を含んでいる。基地局１１０は、プロセッサ１１２、メモリ１１４及び無線周波数（Ｒａｄｉｏ  Ｆｒｅｑｕｅｎｃｙ；ＲＦ）ユニット１１６を含む。プロセッサ１１２は本発明で提案した手順及び／又は方法を具現するように構成することができる。メモリ１１４は、プロセッサ１１２に接続し、プロセッサ１１２の動作と関連した様々な情報を保存する。ＲＦユニット１１６は、プロセッサ１１２に接続し、無線信号を送信及び／又は受信する。端末１２０は、プロセッサ１２２、メモリ１２４及びＲＦユニット１２６を含んでいる。プロセッサ１２２は本発明で提案した手順及び／又は方法を具現するように構成することができる。メモリ１２４は、プロセッサ１２２に接続し、プロセッサ１２２の動作と関連した様々な情報を保存する。ＲＦユニット１２６は、プロセッサ１２２に接続し、無線信号を送信及び／又は受信する。基地局１１０及び／又は端末１２０は、単一アンテナ又は多重アンテナを有することができる。
【０１４５】
以上説明した実施例は、本発明の構成要素及び特徴を所定の形態で結合したものである。各構成要素又は特徴は、別の明示的言及がない限り、選択的なものとして考慮しなければならない。各構成要素又は特徴は、他の構成要素又は特徴と結合しない形態で実施してもよく、一部の構成要素及び／又は特徴を結合して本発明の実施例を構成してもよい。本発明の実施例で説明する動作の順序は、変更してもよい。ある実施例の一部の構成又は特徴を、他の実施例に含めてもよく、又は他の実施例の対応する構成又は特徴に置き換えてもよい。特許請求の範囲で明示的な引用関係にない請求項を結合して実施例を構成したり、出願後の補正によって新しい請求項として含めてもよいことは自明である。
【０１４６】
本文書で基地局によって行われるとした特定の動作は、場合によっては、その上位ノード（ｕｐｐｅｒ  ｎｏｄｅ）によって行われてもよい。すなわち、基地局を含む複数のネットワークノード（ｎｅｔｗｏｒｋ  ｎｏｄｅｓ）からなるネットワークで端末との通信のために行われる様々な動作は、基地局又はその他のネットワークノードで行うことができることは自明である。基地局を、固定局（ｆｉｘｅｄ  ｓｔａｔｉｏｎ）、Ｎｏｄｅ  Ｂ、ｅＮｏｄｅＢ（ｅＮＢ）、アクセスポイント（ａｃｃｅｓｓ  ｐｏｉｎｔ）などの用語に代えてもよい。
【０１４７】
本発明に係る実施例は、様々な手段、例えば、ハードウェア、ファームウェア（ｆｉｒｍｗａｒｅ）、ソフトウェア又はそれらの結合などによって具現することができる。ハードウェアによる具現の場合、本発明の一実施例は、１つ又はそれ以上のＡＳＩＣｓ（ａｐｐｌｉｃａｔｉｏｎ  ｓｐｅｃｉｆｉｃ  ｉｎｔｅｇｒａｔｅｄ  ｃｉｒｃｕｉｔｓ）、ＤＳＰｓ（ｄｉｇｉｔａｌ  ｓｉｇｎａｌ  ｐｒｏｃｅｓｓｏｒｓ）、ＤＳＰＤｓ（ｄｉｇｉｔａｌ  ｓｉｇｎａｌ  ｐｒｏｃｅｓｓｉｎｇ  ｄｅｖｉｃｅｓ）、ＰＬＤｓ（ｐｒｏｇｒａｍｍａｂｌｅ  ｌｏｇｉｃ  ｄｅｖｉｃｅｓ）、ＦＰＧＡｓ（ｆｉｅｌｄ  ｐｒｏｇｒａｍｍａｂｌｅ  ｇａｔｅ  ａｒｒａｙｓ）、プロセッサ、コントローラ、マイクロコントローラ、マイクロプロセッサなどによって具現することができる。
【０１４８】
ファームウェア又はソフトウェアによる具現の場合、本発明の一実施例は、以上で説明した機能又は動作を実行するモジュール、手順、関数などの形態で具現することができる。ソフトウェアコードはメモリユニットに格納され、プロセッサによって駆動されてもよい。
【０１４９】
メモリユニットは、プロセッサの内部又は外部に設けられ、既に公知である様々な手段によってプロセッサとデータを交換することができる。
【０１５０】
本発明は、本発明の特徴から逸脱しない範囲で他の特定の形態で具体化されてもよいことが当業者には自明である。したがって、上記の詳細な説明をいずれの面においても制限的に解釈してはならず、例示的なものとして考慮しなければならない。本発明の範囲は、添付する請求項の合理的解釈によって決定しなければならず、本発明の等価的範囲内における変更はいずれも本発明の範囲に含まれる。
【産業上の利用可能性】
【０１５１】
上述したような無線リソースの用途変更をサポートする無線通信システムにおいて上りリンク制御チャネルの送信方法及びそのための装置は、３ＧＰＰ  ＬＴＥシステムに適用される例を中心に説明したが、３ＧＰＰ  ＬＴＥシステムの他、様々な無線通信システムにも適用可能である。
【図１】
0006321201.tif 000012
【図２】
0006321201.tif 000013
【図３】
0006321201.tif 000014
【図４】
0006321201.tif 000015
【図５】
0006321201.tif 000016
【図６】
0006321201.tif 000017
【図７】
0006321201.tif 000018
【図８】
0006321201.tif 000019
【図９】
0006321201.tif 000020
【図１０】
0006321201.tif 000021
【図１１】
0006321201.tif 000022
【図１２】
0006321201.tif 000023
【図１３】
0006321201.tif 000024