JP2013536643A - Ｐｕｃｃｈフォーマット３リソースを特定するための装置及び方法 - Google Patents

Abstract

本会時は、無線通信システムのためのユーザ端末に関し、また、物理上りリンク制御チャネル（ＰＵＣＣＨ）フォーマット３において制御情報の伝送に使用するリソースを特定するための関連する方法に関する。本方法は、サービング無線基地局からリソースインデックスを受信すること（６１０）と、受信したリソースインデックスに基づいてサブフレームにおいて制御情報の伝送に使用するリソースを特定すること（６２０）とを含み、特定されるリソースは、そのサブフレームにおいて通常のＰＵＣＣＨフォーマット３が使用されるか、短縮化されたＰＵＣＣＨフォーマット３が使用されるかによらず、同一の制限された物理リソースのセットの範囲内にある。
【選択図】 図６ａ

Description

本開示は、物理上りリンク制御チャネル（ＰＵＣＣＨ）フォーマット３に関する。より具体的には、本開示は、ＰＵＣＣＨフォーマット３において制御情報の送信のために使用するリソースを特定する、ユーザ装置、及びユーザ装置における方法に関する。

第３世代パートナーシッププロジェクト（３ＧＰＰ）のロング・ターム・エボリューション（ＬＴＥ）は、より高いデータレート、効率の改善、及びコストの低減のようなサービスの改善に関しての将来の要求を取り扱う、ユニバーサル移動体通信システム（ＵＭＴＳ）標準を改善するためのプロジェクトである。ユニバーサル地上無線アクセスネットワーク（ＵＴＲＡＮ）は、ＵＭＴＳの無線アクセスネットワークであり、拡張型ＵＴＲＡＮ（Ｅ−ＵＴＲＡＮ）は、ＬＴＥシステムの無線アクセスネットワークである。Ｅ−ＵＴＲＡＮにおいては、図１に図解するように、ユーザ端末（ＵＥ）１５０は、一般にｅＮｏｄｅＢ又はｅＮＢ（拡張型ＮｏｄｅＢ）と呼ばれる無線基地局（ＲＢＳ）１１０ａに、無線で接続される。Ｅ−ＵＴＲＡＮにおいては、ｅＮｏｄｅＢ１１０ａ−ｃは、コアネットワーク（ＣＮ）１９０に直接接続される。ＬＴＥシステムは、拡張型ユニバーサル地上無線アクセス（Ｅ−ＵＴＲＡ）通信システムと呼ばれることもある。ＬＴＥシステムでは、直交周波数分割多重（ＯＦＤＭ）が、下りリンク、すなわち、ｅＮｏｄｅＢからＵＥへの伝送において使用され、離散フーリエ変換拡散（ＤＦＴＳ）ＯＦＤＭが、上りリンク、すなわち、ＵＥからｅＮｏｄｅＢへの伝送において使用される。

最小限のＬＴＥ下りリンク物理リソースは、図２ａに図解するように、時間−周波数グリッドとして見られうる。ここで、各リソースエレメントは１つのＯＦＤＭシンボル時間における１つのサブキャリアに対応する。図２ｂに示すように、時間領域において、ＬＴＥ下りリンク伝送は、それぞれが長さＴ_subframe＝１ｍｓの等サイズのサブフレームからなる、１０ｍｓの無線フレームに編成される。さらに、ＬＴＥにおけるリソース割り当ては、典型的には、物理リソースブロック（ＰＲＢ）とも呼ばれる、リソースブロックの観点で説明され、１つのリソースブロックは、図３ａに示すように、時間領域における０．５ｍｓの１つのスロットと周波数領域における１２の連続するサブキャリアとに対応する。リソースブロックは、周波数領域において、システム帯域幅の１つの端から０で始まる番号を付される。

下りリンク伝送は、動的にスケジューリングされる。すなわち、各サブフレームにおいて、基地局又はｅＮｏｄｅＢは、どのＵＥ又は端末のデータが送信されるか、及び、現在の下りリンクのサブフレームにおいて、どのリソースブロックでそのデータが送信されるか、についての情報を含む制御情報を送信する。この制御シグナリングは、典型的には、各サブフレームの最初の１、２、３または４つのＯＦＤＭシンボルにおいて送信される。制御信号のために３つのＯＦＤＭシンボルを有する下りリンクシステムを図２ｃに図解する。

ＬＴＥは、複合自動再送要求（ＨＡＲＱ）を使用する。あるサブフレームにおいて下りリンクデータを受信した後、ＵＥは、それの復号を試行し、その復号が成功したか否かをｅＮｏｄｅＢに報告する。その確認応答は、復号が成功した場合にはＡＣＫの形式で、復号が失敗した場合にはＮＡＣＫの形式で送信される。復号の試行が失敗した場合、ｅＮｏｄｅＢは、その誤ったデータを再送信してもよい。

ＵＥからｅＮｏｄｅＢへの上りリンク制御シグナリングは、受信した下りリンクのデータに対するＨＡＲＱの確認応答に加えて、
− ＵＥが上りリンクのデータ伝送のための上りリンクリソースを要求することを示すスケジューリング要求と、
− 典型的にはチャネル状態報告と呼ばれ、ｅＮｏｄｅＢの下りリンクスケジューリングの支援として使用される下りリンクのチャネル状態に関するＵＥの報告と、
を含む。

このような上りリンクの制御情報は、レイヤ１及びレイヤ２（Ｌ１／Ｌ２）制御情報と呼ばれる。ＵＥがすでにデータ伝送のための上りリンクのリソースを割り当てられているわけではない場合、物理上りリンク制御チャネル（ＰＵＣＣＨ）において特に上りリンクのＬ１／Ｌ２制御のために割り当てられた、上りリンクのリソースにおいて、Ｌ１／Ｌ２制御情報が送信される。図３ａに図解するように、これらのリソースは、全体の利用可能なセルの帯域幅の端に配置されうる。このようなリソースのそれぞれは、上りリンクのサブフレームの２つのスロット、すなわち、１組のリソースブロック又はＰＲＢのそれぞれの内部において、１２のサブキャリアで構成される。周波数ダイバーシティを提供するために、これらの周波数リソースは、スロットの境界において周波数ホッピングする。すなわち、１つのリソースは、サブフレームの最初のスロットの内部で周波数の一番低い部分において、また、等サイズのリソースが、サブフレームの２番目のスロットの間、周波数のより上の部分において、１２サブキャリアからなり、これは逆であってもよい。上りリンクのＬ１／Ｌ２制御シグナリングのためにより多くのリソースが要求される場合、例えば、多数のユーザに対応する非常に大きな全体の送信帯域幅の場合、周波数領域において先に割り当てられたリソースブロックに隣接して追加のリソースブロックを割り当ててもよい。

ＰＵＣＣＨリソースを全体の利用可能な周波数の端に配置する理由は、２つの要素からなる。
１． 上述の周波数ホッピングと共に、周波数端におけるＰＵＣＣＨリソースは、制御シグナリングによって経験される周波数ダイバーシティを最大化する。
２． 周波数の範囲内の他の位置、すなわち端ではない位置においてＰＵＣＣＨのために上りリンクのリソースを割り当てることは、上りリンクの周波数を断片化し、非常に広範な帯域幅を単一のユーザに割り当て、それでも上りリンク伝送のシングルキャリアの特性を保つことを不可能とするだろう。

しかしながら、１つのサブフレームの間の１つのリソースブロックの帯域幅は、単一のＵＥの制御シグナリングの要求に対しては大きすぎる。したがって、制御シグナリングのためにとっておかれたリソースを有効に活用するために、複数の端末が同一のリソースブロックのペアを共用しうる。これは、異なるＵＥに、セルに固有の長さ−１２の周波数領域系列の異なる直交する位相回転と、スロット又はサブフレームの範囲内でシンボルを覆う異なる直交する時間領域カバー符号（cover code）との少なくともいずれかを割り当てることによりなされる。

異なるタイプの上りリンク制御シグナリングを取り扱うため、３ＧＰＰのＬＴＥ標準において定義される様々なＰＵＣＣＨフォーマットがある。ＬＴＥ Ｒｅｌ−８において、ＰＵＣＣＨフォーマット１リソースが定義され、ＨＡＲＱ確認応答又はスケジューリング要求のために使用されている。ＰＵＣＣＨフォーマット１は、サブフレームごとに多くとも２ビットの情報の能力がある。チャネル状態報告がサブフレームごとに多数のビットからなるため、ＰＵＣＣＨフォーマット１は、明らかにチャネル状態報告をシグナリングするのには使用されないかもしれない。ＰＵＣＣＨ上でのチャネル状態報告の伝送は、代わりに、サブフレームごとに多数の情報ビットの能力がある、ＰＵＣＣＨフォーマット２により取り扱われる。実際には、このＰＵＣＣＨフォーマットには、ＰＵＣＣＨフォーマット２、ＰＵＣＣＨフォーマット２ａ、ＰＵＣＣＨフォーマット２ｂの３つの変異形がある。以下では、簡単のために、これらの全てをＰＵＣＣＨフォーマット２と呼ぶ。

また一方で、ＬＴＥ Ｒｅｌ−１０におけるキャリアアグリゲーション（ＣＡ）の導入に伴って、新しいＰＵＣＣＨが要求されている。ＬＴＥ Ｒｅｌ−１０では、全体の利用可能な周波数がＲｅｌ−８で利用可能な全体の周波数に対応する最大の２０ＭＨｚのＬＴＥのキャリアより広くなってもよく、ＬＴＥ Ｒｅｌ−８のＵＥに対して多数のＬＴＥキャリアとして現れうる。そのようなキャリアのそれぞれは、要素キャリア（ＣＣ）又はセルと呼ばれうる。レガシーのＵＥに対しても広いキャリアの効率的な使用を保証するために、ＣＡが使用され、これはＬＴＥ Ｒｅｌ−１０のＵＥが、Ｒｅｌ−８のキャリアと同一の構造を有する又は少なくとも有することができる多数のＣＣを受信しうることを意味する。５つの２０ＭＨｚのＣＣが全体として統合された１００ＭＨｚの帯域幅を提供する場合のＣＡを図４に概略的に示す。また一方で、ＣＡの別のユースケースは、オペレータが異なる周波数帯において又は同一の周波数帯の範囲内で、１つのより広い統合された帯域幅を得るために、帯域幅のより小さい複数の部分を使用する場合である。ＣＡを用いて、多数のＣＣに対応する多数のＨＡＲＱビットのフィードバックを可能とするＰＵＣＣＨフォーマットが要求される。このようなＰＵＣＣＨフォーマットを、以下では、ＰＵＣＣＨフォーマット３と呼ぶ。一方で、ＰＵＣＣＨフォーマット３は、ＣＡ ＰＵＣＣＨフォーマット又はＤＦＴＳ−ＯＦＤＭ ＰＵＣＣＨフォーマットとも呼ばれてもよい。

ＵＥにより送信されたサウンディング参照信号（ＳＲＳ）は、特定のＵＥに割り当てられた範囲の外側の広い帯域幅に対する上りリンクチャネルの品質を推定するために、基地局によって使用されうる。ＳＲＳは、１つのサブフレームにおいて周期的に設定され、そのサブフレームの最後のＤＦＴＳ−ＯＦＤＭシンボルにおいて伝送される。これは、ＳＲＳがそのサブフレームで送信されない場合に使用するための通常のＰＵＣＣＨフォーマット３と、そのサブフレームでＳＲＳが送信される場合にＳＲＳ伝送との衝突を避けるための、そのサブフレームの最後のＤＦＴＳ−ＯＦＤＭシンボルにおいて弱められた短縮化されたＰＵＣＣＨフォーマット３との両方が要求されることを意味する。したがって、ＰＵＣＣＨフォーマット３リソースを共有しうるＵＥの量は、短縮化されたＰＵＣＣＨが使用されるか又は通常のＰＵＣＣＨフォーマット３が使用されるかに依存して変動しうる。

ネットワーク構成の観点から、全てのサブフレームにおいてＰＵＣＣＨフォーマット３のために利用されるリソースの量を同一とすることが興味深い。ＰＵＣＣＨフォーマット３のリソースは、ＰＵＣＣＨフォーマット２及びＰＵＣＣＨフォーマット１と共に帯域の端に割り当てられる可能性が最も高い。しかしながら、ＳＲＳが送信されると共に短縮化されたＰＵＣＣＨフォーマット３が使用されるサブフレームにおいて、より少ないＵＥがＰＵＣＣＨフォーマット３リソースを共有するかもしれない事実は、ＰＵＣＣＨとして同一のサブフレームにおいてＳＲＳが送信されるときに、ＳＲＳが送信されない場合と比較して、より多くのリソースブロックがＰＵＣＣＨフォーマット３に割り当てられるという効果を生じるだろう。リソース要求の変化というその問題に対する従来の解決策は、他の伝送との衝突の危険を冒すことなく、短縮化されたＰＵＣＣＨフォーマット３が使用されるサブフレームの場合にＰＵＣＣＨフォーマット３がより多くのリソースブロックに拡張しうるように、過剰にＰＵＣＣＨフォーマット３のリソースを供給することだろう。しかしながら、システム容量やスループットに影響を与える準最適なリソース利用となってしまうことが欠点である。

別のアプローチは、ＰＵＣＣＨフォーマット２とＰＵＣＣＨフォーマット１が、拡張されたサイズの、短縮化されたＰＵＣＣＨフォーマット３と衝突しないように、ＰＵＣＣＨフォーマット３のリソースを過剰に供給するのに代えて、ＰＵＣＣＨフォーマット２とＰＵＣＣＨフォーマット１とにリソースを割り当てることだろう。しかしながら、これは、ＰＵＣＣＨフォーマット２及びＰＵＣＣＨフォーマット１のリソースに使用される周期性がＳＲＳの伝送のために予約されているサブフレームの周期性の偶数倍である限りにおいてのみ可能である。

したがって、上に概略が説明された問題及び不利点のいくつかを扱うこと、そして、通常のＰＵＣＣＨフォーマット３を使用するサブフレームで使用されているだろうリソースブロックと同一のセットの範囲内で、短縮化されたＰＵＣＣＨを使用するサブフレームのためのリソースの割り当てを提供することが目的である。この目的などは、独立請求項に従う方法及びユーザ端末により、そして、従属請求項に従う実施形態により、達成される。

１つの実施形態によれば、無線通信システムのためのユーザ端末における、物理上りリンク制御チャネル（ＰＵＣＣＨ）フォーマット３で制御情報を送信するのに使用するリソースを特定する方法が提供される。本方法は、サービング無線基地局からリソースインデックスを受信することと、受信したリソースインデックスに基づいてサブフレームにおいて制御情報の伝送に使用するリソースを特定することとを含む。特定されたリソースは、サブフレームにおいて通常のＰＵＣＣＨフォーマット３が使用されるか、短縮化されたＰＵＣＣＨフォーマット３が使用されるかによらず、ＰＲＢの同一の限定されたセットの範囲内にある。

もう１つの実施形態によれば、無線通信システムのための、物理上りリンク制御チャネル（ＰＵＣＣＨ）フォーマット３で制御情報を送信するのに使用するリソースを特定するように構成されるユーザ端末が提供される。本ユーザ端末は、サービング無線基地局からリソースインデックスを受信する受信部と、受信したリソースインデックスに基づいてサブフレームにおいて制御情報の伝送に使用するリソースを特定する特定部とを含む。特定されたリソースは、サブフレームにおいて通常のＰＵＣＣＨフォーマット３が使用されるか、短縮化されたＰＵＣＣＨフォーマット３が使用されるかによらず、ＰＲＢの同一の限定されたセットの範囲内にある。

実施形態の利点は、ＰＵＣＣＨフォーマット３のリソースを過剰に供給する必要がないためリソース利用が改善することである。これは、より高いシステム容量及びスループットをもたらすだろう。別の利点は、他のＰＵＣＣＨフォーマット及び他のチャネルのためのリソースの構成を簡素化することが可能となることである。

実施形態の他の目的、利点及び特徴は、添付の図面及び請求項と併せて考えられるときに、以下の詳細な説明において説明されるだろう。

実施形態が実装されうるＬＴＥネットワークを図解するブロック図。 ＬＴＥの下りリンク物理リソースを示す図。 ＬＴＥの時間領域の構成を示す図。 ＬＴＥの下りリンクのサブフレームを示す図。 ＰＵＣＣＨリソースのためのスロット境界における周波数ホッピングを示す図。 異なるＰＵＣＣＨフォーマットに対するリソースブロックの割り当て例を示す図。 ５つの２０ＭＨｚ要素キャリアのキャリアアグリゲーションを示す図。 通常のＰＵＣＣＨフォーマット３及び短縮化されたＰＵＣＣＨフォーマット３のそれぞれの伝送手法を示す図。 通常のＰＵＣＣＨフォーマット３及び短縮化されたＰＵＣＣＨフォーマット３のそれぞれの伝送手法を示す図。 実施形態に係るＵＥにより実行される方法のフローチャート。 実施形態に係るＵＥにより実行される方法のフローチャート。 実施形態に係るＵＥにより実行される方法のフローチャート。 図６ａ〜ｃのフローチャートに示される方法を実装しうるＵＥにおける装置を示す図。 実施形態に係るＵＥを示すブロック図。 実施形態に係るＵＥを示すブロック図。

以下では、様々な態様について、所定の実施形態と添付の図面を参照してより詳細に説明する。説明の目的であって限定の目的でなく、様々な実施形態の完全な理解を提供するために、具体的なシナリオ及び技術のような特定の詳細について説明する。しかしながら、これらの特定の詳細から離れた他の実施形態があってもよい。

さらに、当業者は、複数の実施形態が主として方法及びＵＥの形式で説明されるところ、それらがコンピュータプログラム媒体、及びコンピュータプロセッサと、プロセッサに接続され、ここで開示される方法の工程を実行しうる１以上のプログラムで符号化されたメモリとを備えるシステムにおいて具現化されてもよいことを理解するだろう。

ここでは、具体的な例示のシナリオへの参照を用いて複数の実施形態について説明する。特定の態様が、非制限的で一般的なコンテキストにおいて、ＬＴＥ Ｒｅｌ−１０システムに関して説明される。しかしながら、その実施形態は、ＰＵＣＣＨフォーマット３を使用する他の種類の無線通信システムにも適用されてもよいことに留意すべきである。その実施形態におけるＵＥは、例えば、移動電話、ページャ、ヘッドセット、ラップトップコンピュータ、及び他の移動体端末を含む。

本開示は、無線通信システムのＵＥにおいて、ＰＵＣＣＨフォーマット３で制御情報を伝送するのに使用するリソースを特定するための方法に関する。以下の文章では、背景について詳述する。

（ＰＵＣＣＨフォーマット１）
下りリンクにおいて、１つの伝送ブロックの受信を確認するために、ＨＡＲＱの確認応答が使用される。空間多重の場合、２つの伝送ブロックの受信が確認されてもよい。上ですでに説明したように、ＨＡＲＱの確認応答はＰＵＣＣＨで送信される。

上りリンクのデータ伝送のためのリソースを要求するために、スケジューリング要求が使用される。明らかに、スケジューリング要求は、ＵＥがリソースを要求するときに送信されるべきであって、そうでなければ、ＵＥは、バッテリ資源を節約し、不要な干渉を生み出さないように黙っているべきである。それ故に、ＨＡＲＱの確認応答とは異なり、スケジューリングリクエストにおいて明示的な情報ビットは送信されず、代わりに対応するＰＵＣＣＨでのエネルギーの存在又は不存在により情報が伝達される。しかしながら、完全に異なる目的で使用されるにも関わらず、スケジューリング要求は、ＨＡＲＱ肯定応答と同一のＰＵＣＣＨフォーマットを共有する。このフォーマットは、３ＧＰＰのＬＴＥ規格においてＰＵＣＣＨフォーマット１と呼ばれる。

ＨＡＲＱの肯定応答又はスケジューリング要求のために使用されるＰＵＣＣＨフォーマット１のリソースは、単一のスカラーのリソースインデックスにより表される。ＵＥは、ＰＵＣＣＨのために構成されるのがどの物理リソースであるかを知らず、リソースインデックスを知っているのみである。インデックスから、位相回転及び直交カバー符号が導出される。ＨＡＲＱ伝送に対して、ＨＡＲＱ確認応答の伝送に使用するリソースインデックスは、ＵＥへの下りリンク伝送のスケジューリングをするのに使用される物理下りリンク制御チャネル上（ＰＤＣＣＨ）での下りリンク制御シグナリングにより、暗示的に与えられる。したがって、上りリンクＨＡＲＱの確認応答のために使用するリソースは、動的に変動し、各サブフレームにおいてＵＥへのスケジューリングに使用される下りリンク制御チャネルに依存する。

ＰＤＣＣＨを用いることによる動的スケジューリングに加え、特定のパターンに従ってＵＥに準永続的なスケジューリングを行う可能性もある。この場合、準永続的なスケジューリングパターンの構成は、ＨＡＲＱ確認応答のために使用するＰＵＣＣＨリソースインデックスでの情報を含む。これは、スケジューリング要求に対しても当てはまり、構成情報は、ＵＥに、どのＰＵＣＣＨリソースをスケジューリング要求の伝送に使用するかを通知する。

したがって、まとめると、ＰＵＣＣＨフォーマット１リソースは、２つの部分に分けられる。
１．準永続的にスケジューリングされたＵＥからのスケジューリング要求とＨＡＲＱ確認応答とのために使用される準静的部分。ＰＵＣＣＨフォーマット１のリソースの準静的部分に使用されるリソースの量は動的には変動しない。
２．動的にスケジューリングされるＵＥのために使用される動的部分。動的にスケジューリングされる端末の数が変動すると、動的ＰＵＣＣＨに使用されるリソースの量は変動する。

（ＰＵＣＣＨフォーマット２）
チャネル依存のスケジューリングに対応するために、ＵＥにおけるチャネル特性の推定値をｅＮｏｄｅＢに供給するようにチャネル状態報告が使用される。１つのチャネル状態報告は、サブフレームごとに多数のビットからなる。サブフレームあたり最大で２ビットの情報の能力を有するＰＵＣＣＨフォーマット１は、明らかにこの目的に使用することはできない。ＰＵＣＣＨでのチャネル状態報告の伝送は、代わりに、サブフレームあたりに多数の情報ビットの能力を有するＰＵＣＣＨフォーマット２により取り扱われる。

ＰＵＣＣＨフォーマット２は、ＰＵＣＣＨフォーマット１と同じセル固有の系列の位相回転に基づく。ＰＵＣＣＨフォーマット１と同様に、ＰＵＣＣＨフォーマット２のリソースは、リソースインデックスにより表され、リソースインデックスから位相回転と他の必要な量が導出されてもよい。ＰＵＣＣＨフォーマット２のリソースは、準静的に構成される。

（ＰＵＣＣＨに対するリソースブロックマッピング）
ＰＵＣＣＨフォーマット１及び２の両方のための上述のＬ１／Ｌ２制御信号は、すでに説明したように、各スロットにおいて１つのリソースブロックを用いて、リソースブロックのペアにおいて送信される。使用するリソースブロックのペアは、ＰＵＣＣＨリソースインデックスから決定される。サブフレームの第１のスロット及び第２のスロットで使用するリソースブロック番号は、
ＲＢｎｕｍｂｅｒ(ｉ)＝ｆ(ＰＵＣＣＨ ｉｎｄｅｘ，ｉ）
のように表されうる。ここで、ｉはサブフレーム内でのスロット番号（０又は１）であり、ｆは３ＧＰＰ規格に見られる関数である。

多数のリソースブロックのペアが、制御シグナリングの容量を増やすために使用されうる。１つのリソースブロックのペアが埋まっている場合、次のＰＵＣＣＨリソースインデックスが次のリソースブロックのペアに順々にマップされる。原理的には、図３ｂに示すように、チャネル状態報告に使用されるＰＵＣＣＨフォーマット２が上りリンクのセル帯域幅の端に最も近くで送信され、次にＰＵＣＣＨフォーマット１の準静的部分が、最後にＰＵＣＣＨフォーマット１の動的部分が帯域幅の最も内側の部分で送信されるように、マッピングがなされる。

様々なＰＵＣＣＨフォーマットのために使用するリソースを決定するために、３つの準静的パラメータが使用される。
−システム情報の部分として提供されるＮ_RB ⁽²⁾は、いずれのリソースブロックのペアにおいて、ＰＵＣＣＨフォーマット１のマッピングが開始するかを制御する。
−Ｎ_PUCCH ⁽¹⁾は、ＰＵＣＣＨフォーマット１の準静的部分と動的部分との間の分割を制御する。
−Ｎ_cs ⁽¹⁾は、１つのリソースブロックにおけるＰＵＣＣＨフォーマット１とフォーマット２との混合を制御する。ほとんどの場合、２つのＰＵＣＣＨフォーマットがリソースブロックの別個のセットにマップされるように構成がなされるが、１つのリソースブロック内にフォーマット１及び２の間の境界を有する可能性もある。

（キャリアアグリゲーション）
２０ＭＨｚまでの帯域幅に対応するＬＴＥ Ｒｅｌ−８標準が、近年３ＧＰＰにおいて標準化されている。しかしながら、国際電気通信連合（ＩＴＵ）のコンセプト、国際移動体通信（ＩＭＴ）−アドバンストに対する要求を満足させるために、３ＧＰＰは、ＬＴＥ Ｒｅｌ−１０への取り組みを開始している。ＬＴＥ Ｒｅｌ−１０の１つの部分は、２０ＭＨｚより広い帯域幅に対応することである。ＬＴＥ Ｒｅｌ−１０の１つの重要な要求はＬＴＥ Ｒｅｌ−８との後方互換性を確保することである。これは、周波数互換性をも含むべきである。それは、ＬＴＥ Ｒｅｌ−１０の２０ＭＨｚより広い１つのキャリアが、ＬＴＥ Ｒｅｌ−８のＵＥに対して多数のＬＴＥキャリアとして見えるべきことを意味するだろう。このようなキャリアのそれぞれは、要素キャリア（ＣＣ）と呼ばれうる。早期のＬＴＥ Ｒｅｌ−１０展開に対して特に、ＬＴＥ Ｒｅｌ−１０の能力を有するＵＥの数が、多くのＬＴＥレガシーのＵＥと比べて数が少ないだろうことが予想されうる。したがって、レガシーのＵＥに対しても広いキャリアの効率的な使用を保証すること、すなわち、広帯域のＬＴＥ Ｒｅｌ−１０のキャリアの全ての部分においてレガシーのＵＥがスケジュールされうるキャリアを実現可能であることが必要である。これを得るための直接的な方法は、キャリアアグリゲーション（ＣＡ）を使用することである。ＣＡは、ＬＴＥ Ｒｅｌ−１０のＵＥが、複数のＲｅｌ−８と同じ構成を有する又は有することができるＣＣを受信しうることを意味する。図４に、５つの２０ＭＨｚのＣＣが全体として統合された１００ＭＨｚの帯域幅を提供するＣＡを概略的に示す。

統合されるＣＣの数及び個別のＣＣの帯域幅は、上りリンクと下りリンクとで異なっていてもよい。対称構成は、下りリンクと上りリンクとにおいてＣＣの数が同じ場合を指す一方で、非対称構成は、ＣＣの数が異なる場合を指す。セルにおいて構成されるＣＣの数は、ＵＥから見えるＣＣの数とは異なり得ることに注意することは重要である。ＵＥは、セルが同数の上りリンクと下りリンクのＣＣを有して構成される場合であっても、例えば、上りリンクのＣＣより多くの下りリンクのＣＣに対応してもよい。

元は、ＬＴＥ Ｒｅｌ−１０のＵＥは、ＬＴＥ Ｒｅｌ−８のＵＥと同様に振る舞い、初期的なランダムアクセスを行う１つのＵＬ／ＤＬのＣＣのペアを用いて構成されるだろう。これらのＣＣは、プライマリ要素キャリア（ＰＣＣ）と呼ばれる。上りリンク（ＵＬ）／下りリンク（ＤＬ）のＰＣＣのペアに加えて、ｅＮＢは、ＵＥの能力とネットワークとに依存して、必要に応じて、追加のＣＣ、いわゆるセカンダリ要素キャリア（ＳＣＣ）を用いてＵＥを設定してもよい。この設定は、無線リソース設定（ＲＲＣ）に基づく。ＲＲＣシグナリングの大きなシグナリングとだいぶ低い速度に起因して、複数のＣＣの全てを現在は使用しなくても、ＵＥをその複数のＣＣを用いて設定してもよい。ＰＤＣＣＨと物理下りリンク共有チャネル（ＰＤＳＣＨ）のために設定された全てのＤＬのＣＣをＵＥが監視しなければならないこと、この結果として高い電力消費を招くことを防ぐために、ＬＴＥ Ｒｅｌ−１０は設定に加えてＣＣの起動に対応する。起動は−ＲＲＣシグナリングより高速な−媒体アクセス制御（ＭＡＣ）シグナリングに基づくため、起動と無効化とは現在のデータレートの要求を満足させるために必要なＣＣの数に従う。大きなデータ量が届くとすぐに、多数のＣＣが起動され、データ伝送に使用され、そして、もはや必要でなくなった場合に無効化される。全てのしかし１つのＣＣ−下りリンクのＰＣＣ−が、無効化されてもよい。したがって、起動は多数のＣＣを設定するが、要求に基づいてのみＣＣを起動するようにする可能性を提供する。ほとんど常に、ＵＥは１つ又は極めて少数のＣＣを起動し、その結果、受信帯域幅が小さくなり、従って、バッテリ消費も少なくなるだろう。

ＣＣのスケジューリングは、ＰＤＣＣＨにおいて、下りリンク割り当てを介して行われる。ＰＤＣＣＨにおける制御情報は、下りリンク制御情報（ＤＣＩ）メッセージとしてフォーマットされる。Ｒｅｌ−８において、ＵＥは、１つのＤＬ及び１つのＵＬのＣＣを用いて動作するのみであり、したがって、ＤＬ割り当てとＵＬ許可と対応するＤＬ及びＵＬのＣＣとの間の関連付けは明らかである。Ｒｅｌ−１０では、ＣＡの２つのモードが区別される必要がある。第１の動作モードは多数のＲｅｌ−８端末の動作と極めて類似し、ＣＣ上で送信されたＤＣＩメッセージに含まれるＤＬ割り当てまたはＵＬ許可は、セル固有の対応付け又はＵＥ固有の対応付けを介して関連付けられる、ＤＬのＣＣ自体に対して、又は関連するＵＬのＣＣに対して有効である。第２の動作モードは、キャリア表示フィールド（ＣＩＦ）を用いてＤＣＩメッセージを補強する。ＣＩＦを伴うＤＬ割り当てを含むＤＣＩは、ＣＩＦで指示されたＤＬのＣＣに対して有効であり、ＣＩＦを伴うＵＬ許可を含むＤＣＩは、指示されたＵＬのＣＣに対して有効である。

下りリンク割り当てのためのＤＣＩメッセージは、とりわけ、リソースブロック割り当て、変調及び符号化手法に関するパラメータ、及びＨＡＲＱ冗長バージョンを含む。実際の下りリンク伝送に関するパラメータに加えて、ほとんどの下りリンク割り当てのためのＤＣＩフォーマットは、また、送信電力制御（ＴＰＣ）コマンドのためのビットフィールドを含む。これらのＴＰＣコマンドは、ＨＡＲＱフィードバックを送信するのに使用される対応するＰＵＣＣＨの、ＵＬの電力制御の挙動を制御するのに使用される。

（キャリアアグリゲーションを伴うＰＵＣＣＨ伝送）
ＣＡへの対応がＬＴＥ Ｒｅｌ−１０で導入されるときに、後に説明するように、多数のＣＣに対応する多数のＨＡＲＱビットのフィードバックを可能とするＰＵＣＣＨフォーマットが要求されている。このようなＰＵＣＣＨフォーマットは、以下では、ＰＵＣＣＨフォーマット３と呼ばれており、これは、３ＧＰＰ標準において使用される専門用語である。同義語はＣＡ ＰＵＣＣＨフォーマット、及びＤＦＴＳ−ＯＦＤＭ ＰＵＣＣＨフォーマットである。ＰＵＣＣＨフォーマット１は、Ｒｅｌ−８ ＰＵＣＣＨとも呼ばれうる。

ＵＥの観点から、対称又は非対称のＵＬ／ＤＬのＣＣ構成の両方に対応する。いくつかの構成に対して、ＵＬ制御情報を多数のＰＵＣＣＨ又は多数のＵＬのＣＣ上で送信する可能性が考えられる。しかしながら、このオプションは、より高いＵＥの電力消費と特定のＵＥの能力への依存をもたらす可能性が高い。また、相互変調積（inter-modulation products）に起因する実装問題を生み出すかもしれず、一般により高い実装と試験の複雑性につながるだろう。

したがって、ＰＵＣＣＨの伝送は、ＵＬ／ＤＬのＣＣの設定へ依存せず、すなわち、設計原理として、１つのＵＬのための全てのＵＬの制御情報は準静的に１つの特定のＵＬ ＣＣ、アンカーキャリアとも呼ばれるＵＬのＰＣＣにマップされる。さらに、ＵＬ ＰＣＣとＤＬ ＰＣＣとの間のセル固有の対応付けが存在する。すなわち、同一のＤＬ ＰＣＣを共有する全ての端末は、同一のＵＬ ＰＣＣを有するだろう。非対称配置のシナリオにおいては、複数のＤＬのＣＣが同一のＵＬのＰＣＣに対応付けられることも可能でありうる。

ＤＬのＰＣＣ及びＵＬのＰＣＣのみを用いて設定されるＵＥは、Ｒｅｌ−８規格に従うＰＵＣＣＨ上で、すなわち、先に説明したＰＵＣＣＨフォーマット１のリソース上で動的なＡＣＫ／ＮＡＣＫを操作している。ＤＬ割り当てのためにＰＤＣＣＨを伝送するのに使用される第１の制御チャネルエレメント（ＣＣＥ）は、ＰＵＣＣＨフォーマット１上の動的ＡＣＫ／ＮＡＣＫを判定し、又は特定する。１つのＤＬのＣＣのみが、ＵＬのＰＣＣとセル固有に対応付けられている場合、全てのＰＤＣＣＨが異なる第１のＣＣＥを用いて送信されるため、ＰＵＣＣＨの衝突は起きない。

セル非対称ＣＡシナリオにおいては、多数のＤＬのＣＣが同一のＵＬのＣＣに、セル固有に対応付けられうる。同一のＵＬのＣＣを用いるが異なるＤＬのＣＣを用いて設定された異なるＵＥは、異なるＤＬのＰＣＣを有するが、同一のＵＬのＰＣＣを共有する。複数のＵＥのＤＬの割り当てを受信する当該複数のＵＥは、当該ＵＥのＨＡＲＱフィードバックを同一のＵＬのＣＣ上で送信するだろう。この場合、ＰＵＣＣＨの衝突が起きないことを保証するのはｅＮＢのスケジューリングである。

このコンセプトを多数の設定されたＤＬのＣＣを有するＵＥにまで拡張するのは当然であるかもしれない。ＤＬのＰＣＣ上で送信される各ＰＤＣＣＨは、Ｒｅｌ−８に従って、ＵＬのＰＣＣ上で予約されるＰＵＣＣＨリソースを有する。ＵＥが多数のＤＬのＣＣを用いて設定されるが、１つのＤＬのＰＣＣ割り当てを受信するのみである場合、ＵＥはなおもＵＬのＰＣＣ上のＰＵＣＣＨフォーマット１のリソースを使用することができるだろう。代わりの方法は、単一のＤＬのＰＣＣ割り当てに対しても多数の設定されたＣＣに対応する複数のＨＡＲＱビットのフィードバックを可能とするＰＵＣＣＨフォーマット３を使用することだろう。しかしながら、設定が多少低速なプロセスであり、ＤＬのＰＣＣのみが起動され使用されるにしても、ＵＥは多くの場合に多数のＣＣを用いて設定されうるため、これは、ＰＵＣＣＨフォーマット３のリソースの非効率的な使用の原因となるだろう。

単一のＳＣＣ上でのＤＬ割り当ての受信または多数のＤＬ割り当ての受信においては、ＰＵＣＣＨフォーマット３が使用されるべきである。後者の場合、ＰＵＣＣＨフォーマット３が多数のＣＣのＨＡＲＱビットのフィードバックに対応する唯一のフォーマットであるため、ＰＵＣＣＨフォーマット３を使用することは明らかである一方で、最初のケースではＰＵＣＣＨフォーマット３を使用することは比較的明らかではない。しかしながら、単体でのＤＬのＳＣＣ割り当ては典型的ではない。ｅＮＢのスケジューラは、ＤＬのＰＣＣ上で単一のＤＬのＣＣの割り当てをスケジュールしようとすべきであり、必要でなければＳＣＣを無効化しようとすべきである。もう１つの問題は、ＣＩＦが設定されないとすれば、ＤＬのＳＣＣの割り当てのためのＰＤＣＣＨがＳＣＣ上で送信され、従って、この場合、ＵＬのＰＣＣ上で自動で予約されるＰＵＣＣＨフォーマット１のリソースがないことである。独立したＤＬのＳＣＣ割り当てに対してもＰＵＣＣＨフォーマット１のリソースを使用することは、ＵＬのＰＣＣを使用する任意のＵＥにより設定されるＤＬの任意のＣＣのために、ＰＵＣＣＨフォーマット１のリソースをこのＵＬのＰＣＣ上に予約することを要求するだろう。独立したＳＣＣの割り当てが典型的ではないため、これは、ＵＬのＰＣＣ上で、ＰＵＣＣＨフォーマット１のリソースを不要かつ過剰に供給することを招来するだろう。

起こり得る可能性のある誤ったケースは、ｅＮＢが、ＵＥに、ＰＣＣを含む多数のＤＬのＣＣ上でスケジューリングすることである。ＵＥがＤＬのＰＣＣ割り当てを除く全てを復号できない場合、ＵＥは、ＰＵＣＣＨフォーマット３の代わりにＰＵＣＣＨフォーマット１を使用するだろう。この誤ったケースを検出するために、ｅＮＢは、ＰＵＣＣＨフォーマット１及びＰＵＣＣＨフォーマット３の両方を監視しなければならない。

実際に受信されるＤＬ割り当ての数によって、ＵＥは対応する数のＨＡＲＱフィードバックビットを準備しなければならない。第１の場合では、ＵＥは受信した割り当ての数に従ってＰＵＣＣＨフォーマット３に適合することができ、したがってフィードバックを与えることができるだろう。しかしながら、ＤＬ割り当てに伴うＰＤＣＣＨが失われるかもしれず、したがって、受信したＤＬの割り当てによってＰＵＣＣＨフォーマット３に適合するかが不明りょうとなり、ｅＮＢにおいて多くの異なる仮説を検証することが必要となるだろう。

代わりに、ＰＵＣＣＨフォーマットを起動メッセージによって設定または起動メッセージに含めることができるだろう。各ＣＣの起動と無効化は、ＭＡＣ制御要素を用いて行われる。ＭＡＣシグナリングと特に起動コマンドが成功裏に受信されたかを示すＨＡＲＱフィードバックシグナリングはエラーが生じやすいため、このアプローチも、ｅＮＢにおける多数の仮設の検証を要求する。

したがって、ＰＵＣＣＨフォーマットが設定されたＣＣの数に基づくことが最も安全な選択の様であり、３ＧＰＰのＬＴＥ標準において、周波数分割複信を用いるシステムに適合されている。ＣＣの設定は、すでに上述したように、ＲＲＣシグナリングに基づく。受信の成功と新しい構成の適用との後、確認メッセージが返送され、したがって、ＲＲＣシグナリングに基づいて極めて安全に設定を行われる。ＲＲＣシグナリングの欠点は、比較的低速で、実際に使用されるＣＣの数が設定されたＣＣの数より少ない場合に現在使用しているＣＣの数を追跡できずに性能劣化が生じることである。

（ＰＵＣＣＨフォーマット３）
図５ａは、４つより多くのＡＣＫ／ＮＡＣＫビットに対応するＵＥのためのＤＦＴＳ−ＯＦＤＭに基づく通常のＰＵＣＣＨフォーマット３に対する送信手法の１つの実施形態のブロック図を示す。スケジューリング要求情報ビットとチャネル状態情報ビットとの少なくともいずれかをも含みうる多数のＡＣＫ／ＮＡＣＫビットが、４８の符号化ビットを形成するように符号化５０１、５０２される。符号化ビットは、その後、セル固有のそして場合によってはＤＦＴＳ−ＯＦＤＭシンボル依存の系列を用いてスクランブリング５０３される。２４ビットが各ＤＦＴＳ−ＯＦＤＭシンボルの第１のスロット内で送信され、他の２４ビットが各ＤＦＴＳ−ＯＦＤＭシンボルの第２のスロット内で送信される。各ＤＦＴＳ−ＯＦＤＭシンボルごとに２４ビットが１２個のＱＰＳＫシンボルに変換５０４され、５つのＤＦＴＳ−ＯＦＤＭシンボルにわたって直交時間領域カバー系列［ｗ(０)．．．ｗ(４)］が乗じられ、離散フーリエ変換（ＤＦＴ）で符号化され、周波数領域における１つのリソースブロック及び時間領域の５つのシンボル内で送信される。直交時間領域カバー系列はＵＥに固有であり、同一のリソースブロック内で５つまでのＵＥの多重化を可能とする。使用されうる直交系列の例を表１に示す。表１では、各直交系列が直交系列インデックスｎ_ocにより特定される。Ｎ_SF,0 ^PUCCHは、サブフレームの第１のタイムスロット、すなわちタイムスロット０においてＰＲＢに利用可能な直交系列の数に対応する。この実施形態では、Ｎ_SF,0 ^PUCCHは５に等しい。

参照信号シンボルのために、周期的にシフトされた定振幅ゼロ自己相関（ＣＡＺＡＣ）系列を使用してもよい。参照信号間の直交製をさらに改善するために、長さ２の直交カバー符号

を、参照信号シンボルに適用してもよい。

（表１）Ｎ_SF,0 ^PUCCH＝５に対する直交系列［ｗ(０)．．．ｗ(Ｎ_SF,0 ^PUCCH−１)］

ＳＲＳがサブフレームにおいて設定されるとき、ＳＲＳはそのサブフレームの最後のＤＦＴＳーＯＦＤＭシンボルにおいて送信される。これは、ＳＲＳを運ぶサブフレームの最後のＤＦＴＳ−ＯＦＤＭシンボルにおいて無音となる、特別な短縮化されたＰＵＣＣＨフォーマット３が要求されることを意味する。この無音化は、ＳＲＳ及びＰＵＣＣＨが同一のサブフレーム内で送信される場合に、他のＵＥからのＳＲＳ伝送と衝突することを防ぐために行われる。

このような短縮化されたＰＵＣＣＨフォーマット３の送信手法の一例を図５ｂのブロック図に示す。図５ｂと図５ａとの違いは、ＵＥが、ＰＵＣＣＨフォーマット３が送信されるのと同じリソースブロックでＳＲＳを送信している他のＵＥの邪魔をしないように、最後のＤＦＴＳ−ＯＦＤＭシンボルがパンクチャされていることである。短縮化されたＰＵＣＣＨフォーマット３の利点は、ＰＵＣＣＨを送信するＵＥが複数のクラスタを送信することなくそのサブフレームの最後のＤＦＴＳ−ＯＦＤＭシンボルにおいてＳＲＳを送信する可能性を有することである。しかしながら、サブフレームの第２のスロットの最後のＤＦＴＳ−ＯＦＤＭシンボルが送信されると、この実施形態では、同一のリソースブロック内で４つのユーザを多重化することのみが可能となるだろう。使用されうる４点の直交系列
の例を表２に示す。Ｎ_SF,1 ^PUCCHは、第２のタイムスロット、すなわちタイムスロット１におけるＰＲＢに利用可能な直交系列の数に対応する。この実施形態では、短縮化されたＰＵＣＣＨフォーマット３が使用されるため、Ｎ_SF,1 ^PUCCHは４に等しい。

結果として、特定のサブフレームおける通常のＰＵＣＣＨフォーマット３又は短縮化されたＰＵＣＣＨフォーマット３のＵＥの選択は、主として、ｅＮＢがセル固有のＳＲＳパターンをそのサブフレームにおいて割り当てたか否かに依存する。

（表２）Ｎ_SF,1 ^PUCCH＝４に対する直交系列［ｗ(０)．．．ｗ(Ｎ_SF,1 ^PUCCH−１)］

ＰＵＣＣＨフォーマット３を送信するために割り当てられたリソースは、明示的なシグナリング、例えばＲＲＣシグナリングにより、または、１つ若しくはいくつかのＤＣＩメッセージにおいて動的かつ明示的なシグナリングを用いて、またはその両方により、与えられうるだろう。そのリソースは、黙示的なシグナリング、例えばいずれのＣＣＥにより対応するＰＤＣＣＨメッセージが送信されたかにより、与えられてもよい。また、そのリソースは、明示的なシグナリングと黙示的なシグナリングとの組み合わせにより与えられてもよい。

ネットワークの観点から、典型的には、リソースブロックのセットがＰＵＣＣＨフォーマット３を処理するために確保される。そのリソースブロックのセットは、スロットの境界で周波数ホッピングさせるときに最大の周波数ダイバーシティを達成するために、ほとんどの場合、全体のシステム帯域幅の２つの端に、ＰＵＣＣＨフォーマット２若しくはＰＵＣＣＨフォーマット１に隣接するリソースブロック上に、又はその両方に、割り当てられるだろう。

以下の例では、１５個のＰＵＣＣＨフォーマット３のリソースブロック又はＰＲＢが設定される。ＳＲＳが送信されず通常のＰＵＣＣＨフォーマット３が使用されるサブフレームにおいては、表３に与えられるＰＲＢの位置及び直交カバー符号（ＯＣＣ）系列インデックスを用いて、１５個のＰＵＣＣＨフォーマット３リソースが編成されうる。

（表３）

ＳＲＳが送信されると共に短縮化されたＰＵＣＣＨフォーマット３が使用されるサブフレームにおいては、５つではなく、４つのＵＥのみが同一のＰＲＢを共有しうる。したがって、従来のＰＵＣＣＨのためのリソースブロックマッピングが使用される場合、表４に与えられるＰＲＢの位置及び直交カバー符号（ＯＣＣ）系列インデックスを用いて、１５個のＰＵＣＣＨフォーマット３リソースが編成されうる。

（表４）

したがって、１５個のＰＵＣＣＨフォーマット３リソースは、ＰＲＢの同一のセットに収まらないだろう。ＰＵＣＣＨフォーマット３に使用されるリソースは、さらにもう１つのＰＲＢに拡張されるだろう。この、必要なリソースブロックの変動は、その結果、通常のＰＵＣＣＨフォーマット３を使用するサブフレームにおいて、ＰＵＣＣＨフォーマット３が短縮化されたＰＵＣＣＨフォーマット３を使用するサブフレームにおけるより多くのリソースブロックに拡張するだろうことに対応するために、サブフレームでネットワークがＰＵＣＣＨフォーマットリソースを過剰に供給することを要求するため、問題である。別のアプローチは、ＰＵＣＣＨフォーマット２及びＰＵＣＣＨフォーマット１が拡張されたサイズの短縮化されたＰＵＣＣＨフォーマット３と衝突しないように、ＰＵＣＣＨフォーマット２及びＰＵＣＣＨフォーマット１のためのリソースを割り当てることであろう。しかしながら、これは、ＰＵＣＣＨフォーマット２及びＰＵＣＣＨフォーマット１リソースに使用される周期がＳＲＳ送信のために予約されるサブフレームの周期の偶数倍である限りにおいてのみ可能である。

したがって、通常のＰＵＣＣＨフォーマット３と短縮化されたＰＵＣＣＨフォーマット３とのいずれが使用されるかによらず、全てのＵＥからのＰＵＣＣＨフォーマット３のために利用されるリソースの量を同じにすることが興味深い。

本発明の実施形態においては、通常のＰＵＣＣＨフォーマット３を使用するか、短縮化されたＰＵＣＣＨフォーマット３を使用するかによって、ＰＵＣＣＨフォーマット３に割り当てられたリソース数が変動する問題に、ＵＥが基地局から受信したリソースインデックスに基づいて制御情報の伝送のために使用するリソースを特定し、サブフレームにおいて通常のＰＵＣＣＨフォーマット３と短縮化されたＰＵＣＣＨフォーマット３のいずれが使用されるかによらず、特定されたリソースが同一の限定されたＰＲＢのセットの範囲内にあるようにする解決法により対処する。したがって、ＵＥによりＰＵＣＣＨフォーマット３を送信するのに使用されるリソースは、限定された量のシグナリングされたリソースの範囲内になるように設定される。

第１の実施形態において、ＰＵＣＣＨフォーマット３を使用するのにＵＥが使用するリソースは、シグナリングされた値のセットの範囲内に、またＰＲＢ単位ベースで、限定される。これは、ＵＥが、通常のＰＵＣＣＨフォーマット３と短縮化されたＰＵＣＣＨフォーマット３のいずれが使用されるかによらず、ＰＵＣＣＨフォーマット３の伝送のために、同一のＰＲＢを特定することを意味する。この第１の実施形態の例について、以下説明する。

この例においては、１５個のＰＵＣＣＨフォーマット３リソースが設定される。通常のＰＵＣＣＨフォーマット３が使用されるサブフレームにおいては、１５個のＰＵＣＣＨフォーマット３リソースは、表３に示すように編成される。

一方で、短縮化されたＰＵＣＣＨフォーマット３が使用されるサブフレームにおいては、表５に与えられるＰＲＢの位置及び直交カバー符号（ＯＣＣ）系列インデックスを用いて、１５個のＰＵＣＣＨフォーマット３リソースが編成される。

（表５）

例えば、ＰＵＣＣＨフォーマット３のリソースのインデックス０及び４は、同一の物理無線リソース（ＰＲＢ）を利用することが観測されるかもしれない。それ故に、短縮化されたＰＵＣＣＨフォーマット３を用いるこのサブフレームにおいて、これらの２つの無線リソースを、２つのＵＥが使用することはできない。このような衝突を防ぐため、ネットワークは、一方のみがＰＵＣＣＨフォーマット３を送信するように、これらのＵＥのためにＰＵＳＣＨをスケジューリングしてもよい。ＵＥがＰＵＳＣＨデータを送信するようにスケジューリングされると、通常ＰＵＣＣＨ上で送信される制御情報は、代わりにＰＵＳＣＨデータと共に送信されるかもしれず、したがって、そのＵＥに対してはＰＵＣＣＨフォーマット３のリソースは必要でなくなる。しかしながら、この第１の実施形態は、４つより多くのリソースが設定されたＰＲＢのいずれをも占有しないようにＰＵＣＣＨフォーマット３のリソースが割り当てられている場合、このようなスケジューリングの制約を導入しない。

この第１の実施形態において、ＵＥがＰＵＣＣＨフォーマット３のリソースを特定するために使用するリソースインデックスは、以下の等式によって与えられる。

ここで、ｎ_{static_resource}は、例えばＲＲＣシグナリングを用いることにより明示的かつ静的に割り当てられたリソースインデックスであり、ｎ_{dynamic_resouce}は、１つまたはいくつかのＤＬの割り当てにおいて示される動的リソース表示であり、ｎ_implicitは、例えば、１つ又はいくつかのＤＬの割り当てのＣＣＥの位置に対して導出される黙示的リソース表示であり、Ｎ_startは、帯域端からのＰＲＢの数で与えられうるＰＵＣＣＨフォーマット３のリソースの開始点であり、Ｎ_SF,0 ^PUCCH＝５であり、Ｎ_DFTS-OFDMは、例えばリソースブロックの点で、存在するＰＵＣＣＨフォーマット３のリソースの総数である。リソースインデックス又は表示ｎ_{static_resource}、ｎ_{dynamic_resouce}、ｎ_implicitのいずれかが存在しない場合、それらは式（１）においてゼロに設定される。

ＰＵＣＣＨフォーマット３によって使用されるべきリソースブロックは、実施形態において、

により与えられる。実施形態においてＰＵＣＣＨフォーマット３に使用される直交系列インデックスは、

により与えられる。ここで、通常のＰＵＣＣＨフォーマット３が使用される場合はＮ_SF,1 ^PUCCH＝５であり、短縮化されたＰＵＣＣＨフォーマット３が使用される場合はＮ_SF,1 ^PUCCH＝４である。

第２の実施形態において、ＵＥがＰＵＣＣＨフォーマット３を送信するのに使用するリソースは、限定された値の範囲内にあるように制限される。この第２の実施形態の例について、以下説明する。

本実施形態においては、先の例と同様に、１５個のＰＵＣＣＨフォーマット３のリソースが設定される。通常のＰＵＣＣＨフォーマット３が使用されるサブフレームにおいては、１５個のＰＵＣＣＨフォーマット３リソースは、表３に示すように編成される。

短縮化されたＰＵＣＣＨフォーマット３が使用されるサブフレームにおいては、表６に与えられるＰＲＢの位置及びＯＣＣ系列インデックスを用いて、１５個のＰＵＣＣＨフォーマット３のリソースが編成される。

（表６）

例えば、ＰＵＣＣＨフォーマット３のリソースのインデックス０及び１２は、同一の物理無線リソースを利用することが観測されるかもしれない。それ故に、短縮化されたＰＵＣＣＨフォーマット３を用いるサブフレームにおいて、これらの２つのＰＵＣＣＨフォーマット３のリソースを、２つのＵＥが使用することはできない。このような衝突を防ぐため、ネットワークは、その２つのＵＥの１つのみがＰＵＣＣＨフォーマット３を送信するように、この２つのＵＥのためにＰＵＳＣＨをスケジューリングしてもよい。

この第２の実施形態において、ＵＥがＰＵＣＣＨフォーマット３のリソースを特定するために使用するリソースインデックスは、以下の等式によって与えられる。

ここで、ｎ_{static_resource}は、例えばＲＲＣシグナリングを用いることにより明示的かつ静的に割り当てられたリソースインデックスであり、ｎ_{dynamic_resouce}は、１つまたはいくつかのＤＬの割り当てにおいて示される動的リソース表示であり、ｎ_implicitは、例えば、１つ又はいくつかのＤＬの割り当てのＣＣＥの位置に対して導出される黙示的リソース表示であり、通常のＰＵＣＣＨフォーマット３が使用される場合はＮ_SF,1 ^PUCCH＝５であると共に短縮化されたＰＵＣＣＨフォーマット３が使用される場合はＮ_SF,1 ^PUCCH＝４である。リソースインデックス又は表示ｎ_{static_resource}、ｎ_{dynamic_resouce}、ｎ_implicitのいずれかが存在しない場合、すなわち、リソースインデックスをシグナリングするのに使用されない場合、それらは式（４）においてゼロに設定される。一般に、Ｎ_SF,1 ^PUCCHは多重化容量、又は所与のサブフレームの第２のスロットにおけるリソースブロックで利用できる直交系列の数を与え、Ｎ_DFTS-OFDMは、例えばリソースブロックの点で、存在するＰＵＣＣＨフォーマット３のリソースの総数である。

ＰＵＣＣＨフォーマット３により使用されるべきリソースブロックは、１つの実施形態において、

により与えられる。ここで、Ｎ_startは、帯域端からのＰＲＢの数で与えられうるＰＵＣＣＨフォーマット３のリソースの開始点である。１つの実施形態においてＰＵＣＣＨフォーマット３に使用される直交系列インデックスは、

により与えられる。より一般的に、この第２の実施形態の１つのとりうる実装は、シグナリングされたＰＵＣＣＨリソースインデックス又は導出されたＰＵＣＣＨリソースインデックスに対して剰余（モジュロ）演算を適用することである。すなわち、

であり、ここで、ｎ_PUCCH-sigは、サブフレームにおいて使用されるべき、シグナリングされたリソースインデックス、又は、例えば黙示的及び明示的にシグナリングされたインデックスの和（ｎ_{static_resource}＋ｎ_{dynamic_resouce}＋ｎ_implicit）として、導出されたリソースインデックスであり、Ｎ_{DFTS-OFDM-PUCCH}は、所与のサブフレームにおいて使用可能なＰＵＣＣＨフォーマット３のリソースの総数である。関数ｆ₁及びｆ₂は、所与のリソースインデックスｎをＰＲＢ及びＯＣＣのそれぞれにマップする。

図６ａは、実施形態に係る、無線通信システムのＵＥにおける方法のフローチャートである。本方法は、ＰＵＣＣＨフォーマット３条で制御情報の送信に使用するリソースを特定するに使用される。本方法は、以下を含む。
−６１０：サービングＲＢＳからリソースインデックスを受信する。
−６２０：受信したリソースに基づき、サブフレームにおける制御情報の伝送に使用するリソースを特定する。特定されるリソースは、そのサブフレームにおいて通常のＰＵＣＣＨフォーマット３が使用されるか短縮化されたＰＵＣＣＨフォーマット３が使用されるかによらず、同一の制限されたＰＲＢのセットの範囲内にある。

図６ｂは、上述の第１の実施形態に係るＵＥにおける方法のフローチャートである。本方法は、サービングＲＢＳからリソースインデックスを受信する初期ステップ６１０を含む。受信したリソースインデックスに基づいて、サブフレームにおける制御情報の伝送に使用するリソースを特定するステップ６２０は、以下を含む。
−６２１：受信したリソースインデックスに基づいてＰＲＢを特定する。ここで、特定されるＰＲＢは、通常のＰＵＣＣＨフォーマット３が使用されるか、短縮化されたＰＵＣＣＨフォーマット３が使用されるかによらず、同一である。そのＰＲＢは、１つの実施形態において、上の式（２）により与えられるｎ_PRBに基づいて特定されてもよい。
−６２２：上の式（３）により与えられる直交系列インデックスｎ_ocに基づいて、直交系列を特定する。

図６ｃは、上述の第２の実施形態に係るＵＥにおける方法のフローチャートである。本方法は、サービングＲＢＳからリソースインデックスを受信する初期ステップ６１０を含む。受信したリソースインデックスに基づいて、サブフレームにおける制御情報の伝送に使用するリソースを特定するステップ６２０は、以下を含む。
−６２３：受信したリソースインデックスとＰＵＣＣＨフォーマット３に利用可能なＰＲＢの総数とに基づいて、変形したリソースインデックスを計算する。
−６２４：変形されたリソースインデックスに基づいて、リソースを特定する。ここで、特定されるＰＲＢは、通常のＰＵＣＣＨフォーマット３が使用されるか、短縮化されたＰＵＣＣＨフォーマット３が使用されるかによらず、同一である。変形されたリソースインデックスは、受信したリソースインデックスを被除数として、ＰＵＣＣＨフォーマット３に利用可能なＰＲＢの総数を除数として用いた剰余演算として計算されうる。変形されたリソースインデックスに基づいて、上の式（５）により与えられるｎ_PRBに基づいて、ＰＲＢが特定されてもよい。さらに、上の式（６）により与えられる直交系列インデックスｎ_ocに基づいて、直交系列が特定されうる。

実施形態にしたがって、ＵＥ８００を図８ａに概略的に示す。ＵＥ８００は、無線通信システムにおいて使用されるように構成されると共に、ＰＵＣＣＨフォーマット３上で制御情報の伝送に使用するリソースを特定するように構成される。ＵＥは、サービングＲＢＳからリソースインデックスを受信するように適合される受信部８１０と、受信したリソースインデックスに基づいて、サブフレームにおける制御情報の伝送に使用するリソースを特定するように適合される特定部８２０とを有する。ここで、特定されるリソースは、そのサブフレームにおいて通常のＰＵＣＣＨフォーマット３が使用されるか短縮化されたＰＵＣＣＨフォーマット３が使用されるかによらず、同一の制限されたＰＲＢのセットの範囲内にある。

上述の第１の実施形態では、特定部８２０は、受信したリソースインデックスに基づいてＰＲＢを特定するように適合され、特定されるＰＲＢは、そのサブフレームにおいて通常のＰＵＣＣＨフォーマット３が使用されるか短縮化されたＰＵＣＣＨフォーマット３が使用されるかによらず、同一である。特定部８２０は、上の式（２）により与えられるｎ_PRBに基づいてそのＰＲＢを特定するように適合されてもよい。特定部８２０は、また、上の式（３）により与えられる直交系列インデックスｎ_ocに基づいて、直交系列を特定するように適合されてもよい。

上述の第２の実施形態において、特定部８２０は、受信したリソースインデックスとＰＵＣＣＨフォーマット３に利用可能なＰＲＢの総数とに基づいて、変形したリソースインデックスを計算するように適合されると共に、変形されたリソースインデックスに基づいて、リソースを特定するように適合される。この実施形態において、特定されるリソースは、通常のＰＵＣＣＨフォーマット３が使用されるか、短縮化されたＰＵＣＣＨフォーマット３が使用されるかによらず、同一の制限されたＰＲＢのセットの範囲内にある。特定部８２０は、受信したリソースインデックスを被除数として、ＰＵＣＣＨフォーマット３に利用可能なＰＲＢの総数を除数として用いた剰余演算として、変形されたリソースインデックスを計算するように適合されてもよい。特定部８２０は、上の式（５）により与えられるｎ_PRBに基づいて、ＰＲＢを特定するように適合されてもよい。さらに、特定部８２０は、上の式（６）により与えられる直交系列インデックスｎ_ocに基づいて、直交系列を特定するように適合されてもよい。

図８ａを参照して上述した各部は論理ユニットであり、必ずしも別個の物理ユニットに対応しない。

図８ｂは、図８ａに図解された実施形態の開示の別の方法である、ＵＥ８００の実施形態を概略的に図解している。ＵＥ８００は、サービングＲＢＳからリソースインデックスを受信するための受信部８１０を有する。ＵＥ８００は、また、単一のユニット又は複数のユニットでありうる処理部８５４を有する。さらに、ＵＥ８００は、不揮発メモリ、例えば、ＥＥＰＲＯＭ（電気的消去可能プログラム可能読み出し専用メモリ）、フラッシュメモリ又はディスクドライブの形式で、少なくとも１つのコンピュータプログラム媒体８５５を有する。コンピュータプログラム媒体８５５は、ＵＥ上で動作するときに、図６ａ〜ｃと共に先に説明した手順の工程をＵＥ８００の処理部８５４に実行させるコード手段を備えるコンピュータプログラム８５６を含む。

したがって、説明した実施形態において、ＵＥ８００のコンピュータプログラム８５６におけるコード手段は、受信したリソースインデックスに基づいてサブフレームにおける制御情報の伝送に使用するリソースを特定するための特定モジュール８５６ａを有する。ここで、特定されるリソースは、そのサブフレームにおいて通常のＰＵＣＣＨフォーマット３が使用されるか短縮化されたＰＵＣＣＨフォーマット３が使用されるかによらず、同一の制限されたＰＲＢのセットの範囲内にある。コード手段は、このように、コンピュータプログラムモジュールにおいて構造化されたコンピュータプログラムコードとして実装されうる。モジュール８５６ａは、基本的に、図８ａで説明したネットワークノードをエミュレートするために図６ａのフローのステップ６２０を実行する。換言すれば、モジュール８５６ａが処理部８５４で実行されるとき、それは、図８ａのユニット８２０に対応する。

図８ｂと共に上で開示した実施形態におけるコード手段は、ＵＥ８００上で実行されるときにＵＥに図６ａとともに上述したステップを実行させるコンピュータプログラムとして実装されるが、１つ以上の当該コード手段は、別の実施形態において、少なくとも部分的にハードウェアの回路として実装されてもよい。

図７は、上述の方法を実行しうるＵＥにおける装置７００のブロック図である。図７に示される機能ブロックは、様々な透過的な手法で組み合わされても再構成されてもよく、その機能の多くは１つ以上の適切なプログラムされたデジタルシグナルプロセッサにより実行されてもよいことが理解されるだろう。さらに、図７に示される機能ブロック間の接続及び機能ブロックにより提供又は交換される情報は、ＵＥの動作に含まれる他の方法をＵＥが実行することができるように様々な方法で変更されてもよい。

図７に描かれるように、ＵＥは、アンテナ７０２を介して、ＤＬの無線信号を受信し、典型的にはフロントエンド受信機（Ｆｅ ＲＸ）７０４において受信した無線信号をアナログベースバンド信号へとダウンコンバートする。ベースバンド信号は、帯域幅ＢＷ₀を有するアナログフィルタ７０６によりスペクトル整形され、フィルタ７０６により生成された、整形されたベースバンド信号は、アナログ−デジタル変換機（ＡＤＣ）７０８により、アナログからデジタル形式へと変換される。デジタル化されたベースバンド信号は、さらに、同期信号又はＤＬ信号に含まれるシンボルの帯域幅に対応する帯域幅ＢＷ_syncを有するデジタルフィルタ７１０により、スペクトル整形される。フィルタ７１０により生成された、整形された信号は、特定の通信システム、例えば３Ｇ ＬＴＥのために規定されるように、セルをサーチする１つ以上の方法を実行するセルサーチ部７１２へ供給される。典型的には、このような方法は、受信信号において、所定のプライマリ同期チャネルとセカンダリ同期チャネルとの少なくともいずれか（Ｐ／Ｓ−ＳＣＨ）の信号を検出することを含む。

デジタル化されたベースバンド信号は、ＡＤＣ７０８によって、帯域幅ＢＷ₀を有するデジタルフィルタ７１４にも供給され、フィルタリングされたデジタルベースバンド信号は、高速フーリエ変換（ＦＦＴ）、又はそのベースバンド信号の周波数領域（スペクトル）表現を生成する他の適切なアルゴリズムを実行するプロセッサ７１６に供給される。チャネル推定部７１８はプロセッサ７１６から信号を受信し、制御部７２０により供給される制御及びタイミング信号に基づいて、サブキャリアｉ及びセルｊのそれぞれに対するチャネル推定値Ｈ_i,jを生成する。制御部７２０は、そのような制御及びタイミング情報をプロセッサ７１６にも供給する。

推定部７１８は、チャネル推定値Ｈ_iを復号器７２２及び信号電力推定部７２４へ供給する。プロセッサ７１６からも信号を受信する復号器７２２は、上述のようなＲＲＣ又は他のメッセージから情報を抽出するように適切に構成され、典型的には、ＵＥにおけるさらなる処理（不図示）の対象となる信号を生成する。推定部７２４は、受信信号電力測定値（例えば、参照信号受信電力（ＲＳＲＰ）、受信サブキャリア電力Ｓ_i、信号対干渉比（ＳＩＲ）などの推定値）を生成する。推定部７２４は、ＲＳＲＰの推定値、参照信号受信品質（ＲＳＲＱ）、受信信号強度表示（ＲＳＳＩ）、受信サブキャリア電力Ｓ_i、ＳＩＲ、及び他の関連する測定値を、制御部７２０が供給した制御信号に応答して様々な方法で生成してもよい。推定部７２４が生成した電力推定値は、典型的には、ＵＥでの更なる信号処理において使用される。推定部７２４（又は、さらに言うなら、サーチ部７１２）は、適切な信号相関器を含むように構成される。

図７に描画した構成では、制御部７２０は、サーチ部７１２、プロセッサ７１６、推定部７１８、及び推定部７２４を設定するのに要求される実質的に全ての形跡を保持する。推定部７１８に対しては、これは、（参照信号抽出及び参照信号のセル固有のスクランブリングのための）方法とセル識別子の両方を含む。サーチ部７１２と制御部７２０との間の通信は、セル識別子と、例えば、サイクリックプリフィックスの設定とを含む。制御部７２０は、検出された１つ又は複数のセルでの測定のために、いくつかのとりうる推定方法のうちいずれが、推定部７１８と推定部７２４との少なくともいずれかにより使用されるかを決定してもよい。また、典型的には相関器を含むか、相関器の機能を実行しうる制御部７２０は、ネットワークによりシグナリングされた情報を受信してもよく、Ｆｅ ＲＸ７０４のオン／オフ時間を制御してもよい。

制御部７２０は、送信器フロントエンド（ＦＥ ＴＸ）７２８へ供給される変調シンボル又は同様の情報を生成する符号化器７２６へ、適切な情報を供給する。送信器フロントエンド（ＦＥ ＴＸ）７２８は、通信システムに適した送信信号を生成する。図７に示すように、送信信号はアンテナ７０２に供給される。制御部７２０は、符号化器７２６と共に、上述のように、ＵＥによりネットワークへ送信されるＲＲＣ及び他のメッセージを生成するのに適して構成される。

ＵＥの制御部及び他のブロックは、１つ以上のメモリに記憶された情報を処理する、１つ以上の適切なプログラムされた電子プロセッサ、一群の論理ゲート等により実装されてもよい。上述のとおり、ＵＥは、制御部及び制御部により実行可能なソフトウェアと協働して、方法を実行し、上述の信号を受信し生成するのに適したメモリ又は他の情報記憶機能を含む。記憶される情報は、制御部が上述の方法を実行することを可能とするプログラム命令及びデータを含んでもよい。制御部は、典型的には、その動作を促進するタイマなどを含むことが理解されるだろう。

上で言及され説明された実施形態は、例示のためだけに与えられたものであり、限定するものではない。添付の特許請求の範囲の範囲内の他の解決法、使用、目的、及び機能も考えられてもよい。

（略語）
３ＧＰＰ 第３世代パートナーシッププロジェクト
ＡＣＫ 肯定応答
ＣＡ キャリアアグリゲーション
ＣＡＺＡＣ 定振幅ゼロ自己相関
ＣＣ 要素キャリア
ＣＣＥ 制御チャネルエレメント
ＣＩＦ キャリア表示フィールド
ＣＮ コアネットワーク
ＤＣＩ 下りリンク制御情報
ＤＦＴ 離散フーリエ変換
ＤＦＴＳ ＤＦＴ拡散
ＤＬ 下りリンク
ｅＮＢ、ｅＮｏｄｅＢ エボルブドノードＢ
Ｅ−ＵＴＲＡＮ エボルブドＵＴＲＡＮ
ＵＴＲＡＮ ユニバーサル地上無線アクセスネットワーク
ＦＤＤ 周波数分割複信
ＨＡＲＱ 複合自動再送要求
ＬＴＥ ロング・ターム・エボリューション
ＭＡＣ 媒体アクセス制御
ＭＨｚ メガヘルツ
ＮＡＣＫ 非肯定応答
ＯＣＣ 直交カバー符号
ＯＦＤＭ 直交周波数分割多重
ＰＣＣ プライマリ要素キャリア
ＰＤＣＣＨ 物理下りリンク制御チャネル
ＰＤＳＣＨ 物理下りリンク共有チャネル
ＰＲＢ 物理リソースブロック
ＰＵＣＣＨ 物理上りリンク制御チャネル
ＲＥ リソースエレメント
Ｒｅｌ−１０ リリース１０
Ｒｅｌ−８ リリース８
ＲＲＣ 無線リソース設定
ＳＣＣ セカンダリ要素キャリア
ＳＲＳ サウンディング参照信号
ＴＰＣ 送信電力制御
ＵＥ ユーザ端末
ＵＬ 上りリンク
ＵＭＴＳ ユニバーサル移動通信システム

Claims (16)

1. 無線通信システムのユーザ端末において、物理上りリンク制御チャネル（ＰＵＣＣＨ）フォーマット３において制御情報を伝送するために使用するリソースを特定する方法であって、
   サービング無線基地局からリソースインデックスを受信し（６１０）、
   受信した前記リソースインデックスに基づいて、サブフレームにおける前記制御情報の前記伝送のために使用する前記リソースを特定し（６２０）、
   特定される前記リソースは、前記サブフレームにおいて通常のＰＵＣＣＨフォーマット３が使用されるか短縮化されたＰＵＣＣＨフォーマット３が使用されるかによらず、同一の限定された物理リソースブロックのセットの範囲内にある、
   ことを特徴とする方法。
2. 前記リソースの特定（６２０）は、受信した前記リソースインデックスに基づいて、物理リソースブロックを特定する（６２１）ことを含み、
   特定される前記物理リソースブロックは、前記サブフレームにおいて通常のＰＵＣＣＨフォーマット３が使用されるか短縮化されたＰＵＣＣＨフォーマット３が使用されるかによらず、同一である、
   ことを特徴とする請求項１に記載の方法。
3. 前記物理リソースブロックは、ｎ_PUCCHが受信した前記リソースインデックスであり、Ｎ_SF,0 ^PUCCHが前記サブフレームの第１のタイムスロットにおける物理リソースブロックのために利用可能な直交系列の数である場合に、数式
   

   

   により与えられるｎ_PRBに基づいて特定される、
   ことを特徴とする請求項２に記載の方法。
4. 前記リソースの特定（６２０）は、ｎ_PUCCHが受信した前記リソースインデックスであり、Ｎ_SF,1 ^PUCCHが前記サブフレームの第２のタイムスロットにおける物理リソースブロックのために利用可能な直交系列の数である場合に、数式
   

   

   により与えられる直交系列インデックスｎ_ocに基づいて、直交系列を特定する（６２２）ことを含む、
   ことを特徴とする請求項１から３のいずれか１項に記載の方法。
5. 前記リソースの特定（６２０）は、
   受信した前記リソースインデックスとＰＵＣＣＨフォーマット３のために利用可能な物理リソースブロックの総数とに基づいて、変形されたリソースインデックスを計算し（６２３）、
   前記変形されたリソースインデックスに基づいて前記リソースを特定する（６２４）ことを含み、
   特定される前記リソースは、前記サブフレームにおいて通常のＰＵＣＣＨフォーマット３が使用されるか短縮化されたＰＵＣＣＨフォーマット３が使用されるかによらず、同一の限定された物理リソースブロックのセットの範囲内にある、
   ことを特徴とする請求項１に記載の方法。
6. 前記変形されたリソースインデックスは、受信された前記リソースインデックスを被除数として、ＰＵＣＣＨフォーマット３のために利用可能な物理リソースブロックの前記総数を除数として用いた剰余演算として計算される、
   ことを特徴とする請求項５に記載の方法。
7. 前記変形されたリソースインデックスに基づく前記リソースの特定（６２４）は、
   

   

   が前記変形されたリソースインデックスであり、Ｎ_SF,1 ^PUCCHが前記サブフレームの第２のタイムスロットにおける物理リソースブロックのために利用可能な直交系列の数であり、Ｎ_startが前記限定された物理リソースブロックのセットの開始点である場合に、数式
   

   

   により与えられるｎ_PRBに基づいて物理リソースブロックを特定することを含む、
   ことを特徴とする請求項５又は６に記載の方法。
8. 前記変形されたリソースインデックスに基づく前記リソースの特定（６２４）は、
   

   

   が前記変形されたリソースインデックスであり、Ｎ_SF,1 ^PUCCHが前記サブフレームの第２のタイムスロットにおける物理リソースブロックのために利用可能な直交系列の数である場合に、数式
   

   

   により与えられる直交系列インデックスｎ_ocに基づいて、直交系列を特定することを含む、
   ことを特徴とする請求項５から７のいずれか１項に記載の方法。
9. 物理上りリンク制御チャネル（ＰＵＣＣＨ）フォーマット３において制御情報の伝送に使用するリソースを特定するように構成される無線通信システムのためのユーザ端末（８００）であって、
   サービング無線基地局からリソースインデックスを受信するように適合される受信部（８１０）と、
   受信した前記リソースインデックスに基づいて、サブフレームにおける前記制御情報の前記伝送のために使用する前記リソースを特定するように適合される特定部（８２０）とを有し、
   特定される前記リソースは、前記サブフレームにおいて通常のＰＵＣＣＨフォーマット３が使用されるか短縮化されたＰＵＣＣＨフォーマット３が使用されるかによらず、同一の限定された物理リソースブロックのセットの範囲内にある、
   ことを特徴とするユーザ端末。
10. 前記特定部（８２０）は、受信した前記リソースインデックスに基づいて、物理リソースブロックを特定するように適合され、
    特定される前記物理リソースブロックは、前記サブフレームにおいて通常のＰＵＣＣＨフォーマット３が使用されるか短縮化されたＰＵＣＣＨフォーマット３が使用されるかによらず、同一である、
    ことを特徴とする請求項９に記載のユーザ端末。
11. 前記特定部（８２０）は、ｎ_PUCCHが受信した前記リソースインデックスであり、Ｎ_SF,0 ^PUCCHが前記サブフレームの第１のタイムスロットにおける物理リソースブロックのために利用可能な直交系列の数である場合に、数式
    

    

    により与えられるｎ_PRBに基づいて、前記物理リソースブロックを特定するように適合される、
    ことを特徴とする請求項１０に記載のユーザ端末。
12. 前記特定部（８２０）は、ｎ_PUCCHが受信した前記リソースインデックスであり、Ｎ_SF,1 ^PUCCHが前記サブフレームの第２のタイムスロットにおける物理リソースブロックのために利用可能な直交系列の数である場合に、数式
    

    

    により与えられる直交系列インデックスｎ_ocに基づいて、直交系列を特定するように適合される、
    ことを特徴とする請求項９から１１のいずれか１項に記載のユーザ端末。
13. 前記特定部（８２０）は、さらに、受信した前記リソースインデックスとＰＵＣＣＨフォーマット３のために利用可能な物理リソースブロックの総数とに基づいて、変形されたリソースインデックスを計算し、前記変形されたリソースインデックスに基づいて前記リソースを特定するように適合され、
    特定される前記リソースは、前記サブフレームにおいて通常のＰＵＣＣＨフォーマット３が使用されるか短縮化されたＰＵＣＣＨフォーマット３が使用されるかによらず、同一の限定された物理リソースブロックのセットの範囲内にある、
    ことを特徴とする請求項９に記載のユーザ端末。
14. 前記特定部（８２０）は、さらに、受信された前記リソースインデックスを被除数として、ＰＵＣＣＨフォーマット３のために利用可能な物理リソースブロックの前記総数を除数として用いた剰余演算として、前記変形されたリソースインデックスを計算するように適合される、
    ことを特徴とする請求項１３に記載のユーザ端末。
15. 前記特定部（８２０）は、
    

    

    が前記変形されたリソースインデックスであり、Ｎ_SF,1 ^PUCCHが前記サブフレームの第２のタイムスロットにおける物理リソースブロックのために利用可能な直交系列の数であり、Ｎ_startが前記限定された物理リソースブロックのセットの開始点である場合に、数式
    

    

    により与えられるｎ_PRBに基づいて物理リソースブロックを特定するように適合される、
    ことを特徴とする請求項１３又は１４に記載のユーザ端末。
16. 前記特定部（８２０）は、
    

    

    が前記変形されたリソースインデックスであり、Ｎ_SF,1 ^PUCCHが前記サブフレームの第２のタイムスロットにおける物理リソースブロックのために利用可能な直交系列の数である場合に、数式
    

    

    により与えられる直交系列インデックスｎ_ocに基づいて、直交系列を特定するように適合される、
    ことを特徴とする請求項１３から１５のいずれか１項に記載のユーザ端末。

Images