無線通信システムのユーザ端末において、物理上りリンク制御チャネルPUCCHフォーマット3において制御情報を伝送するために使用するリソースを特定する方法であって、サービング無線基地局からリソースインデックスを受信し610、受信した前記リソースインデックスに基づいて、サブフレームにおける前記制御情報の前記伝送のために使用する前記リソースを特定し620、特定される前記リソースは、前記サブフレームにおいて通常のPUCCHフォーマット3が使用されるか短縮化されたPUCCHフォーマット3が使用されるかによらず、同一の限定された物理リソースブロックのセットの範囲内にある、ことを特徴とする方法。前記リソースの特定620は、受信した前記リソースインデックスに基づいて、物理リソースブロックを特定する621ことを含み、特定される前記物理リソースブロックは、前記サブフレームにおいて通常のPUCCHフォーマット3が使用されるか短縮化されたPUCCHフォーマット3が使用されるかによらず、同一である、ことを特徴とする請求項1に記載の方法。前記物理リソースブロックは、nPUCCHが受信した前記リソースインデックスであり、NSF0PUCCHが前記サブフレームの第1のタイムスロットにおける物理リソースブロックのために利用可能な直交系列の数である場合に、数式により与えられるnPRBに基づいて特定される、ことを特徴とする請求項2に記載の方法。前記リソースの特定620は、nPUCCHが受信した前記リソースインデックスであり、NSF1PUCCHが前記サブフレームの第2のタイムスロットにおける物理リソースブロックのために利用可能な直交系列の数である場合に、数式により与えられる直交系列インデックスnocに基づいて、直交系列を特定する622ことを含む、ことを特徴とする請求項1から3のいずれか1項に記載の方法。前記リソースの特定620は、受信した前記リソースインデックスとPUCCHフォーマット3のために利用可能な物理リソースブロックの総数とに基づいて、変形されたリソースインデックスを計算し623、前記変形されたリソースインデックスに基づいて前記リソースを特定する624ことを含み、特定される前記リソースは、前記サブフレームにおいて通常のPUCCHフォーマット3が使用されるか短縮化されたPUCCHフォーマット3が使用されるかによらず、同一の限定された物理リソースブロックのセットの範囲内にある、ことを特徴とする請求項1に記載の方法。前記変形されたリソースインデックスは、受信された前記リソースインデックスを被除数として、PUCCHフォーマット3のために利用可能な物理リソースブロックの前記総数を除数として用いた剰余演算として計算される、ことを特徴とする請求項5に記載の方法。前記変形されたリソースインデックスに基づく前記リソースの特定624は、が前記変形されたリソースインデックスであり、NSF1PUCCHが前記サブフレームの第2のタイムスロットにおける物理リソースブロックのために利用可能な直交系列の数であり、Nstartが前記限定された物理リソースブロックのセットの開始点である場合に、数式により与えられるnPRBに基づいて物理リソースブロックを特定することを含む、ことを特徴とする請求項5又は6に記載の方法。前記変形されたリソースインデックスに基づく前記リソースの特定624は、が前記変形されたリソースインデックスであり、NSF1PUCCHが前記サブフレームの第2のタイムスロットにおける物理リソースブロックのために利用可能な直交系列の数である場合に、数式により与えられる直交系列インデックスnocに基づいて、直交系列を特定することを含む、ことを特徴とする請求項5から7のいずれか1項に記載の方法。物理上りリンク制御チャネルPUCCHフォーマット3において制御情報の伝送に使用するリソースを特定するように構成される無線通信システムのためのユーザ端末800であって、サービング無線基地局からリソースインデックスを受信するように適合される受信部810と、受信した前記リソースインデックスに基づいて、サブフレームにおける前記制御情報の前記伝送のために使用する前記リソースを特定するように適合される特定部820とを有し、特定される前記リソースは、前記サブフレームにおいて通常のPUCCHフォーマット3が使用されるか短縮化されたPUCCHフォーマット3が使用されるかによらず、同一の限定された物理リソースブロックのセットの範囲内にある、ことを特徴とするユーザ端末。前記特定部820は、受信した前記リソースインデックスに基づいて、物理リソースブロックを特定するように適合され、特定される前記物理リソースブロックは、前記サブフレームにおいて通常のPUCCHフォーマット3が使用されるか短縮化されたPUCCHフォーマット3が使用されるかによらず、同一である、ことを特徴とする請求項9に記載のユーザ端末。前記特定部820は、nPUCCHが受信した前記リソースインデックスであり、NSF0PUCCHが前記サブフレームの第1のタイムスロットにおける物理リソースブロックのために利用可能な直交系列の数である場合に、数式により与えられるnPRBに基づいて、前記物理リソースブロックを特定するように適合される、ことを特徴とする請求項10に記載のユーザ端末。前記特定部820は、nPUCCHが受信した前記リソースインデックスであり、NSF1PUCCHが前記サブフレームの第2のタイムスロットにおける物理リソースブロックのために利用可能な直交系列の数である場合に、数式により与えられる直交系列インデックスnocに基づいて、直交系列を特定するように適合される、ことを特徴とする請求項9から11のいずれか1項に記載のユーザ端末。前記特定部820は、さらに、受信した前記リソースインデックスとPUCCHフォーマット3のために利用可能な物理リソースブロックの総数とに基づいて、変形されたリソースインデックスを計算し、前記変形されたリソースインデックスに基づいて前記リソースを特定するように適合され、特定される前記リソースは、前記サブフレームにおいて通常のPUCCHフォーマット3が使用されるか短縮化されたPUCCHフォーマット3が使用されるかによらず、同一の限定された物理リソースブロックのセットの範囲内にある、ことを特徴とする請求項9に記載のユーザ端末。前記特定部820は、さらに、受信された前記リソースインデックスを被除数として、PUCCHフォーマット3のために利用可能な物理リソースブロックの前記総数を除数として用いた剰余演算として、前記変形されたリソースインデックスを計算するように適合される、ことを特徴とする請求項13に記載のユーザ端末。前記特定部820は、が前記変形されたリソースインデックスであり、NSF1PUCCHが前記サブフレームの第2のタイムスロットにおける物理リソースブロックのために利用可能な直交系列の数であり、Nstartが前記限定された物理リソースブロックのセットの開始点である場合に、数式により与えられるnPRBに基づいて物理リソースブロックを特定するように適合される、ことを特徴とする請求項13又は14に記載のユーザ端末。前記特定部820は、が前記変形されたリソースインデックスであり、NSF1PUCCHが前記サブフレームの第2のタイムスロットにおける物理リソースブロックのために利用可能な直交系列の数である場合に、数式により与えられる直交系列インデックスnocに基づいて、直交系列を特定するように適合される、ことを特徴とする請求項13から15のいずれか1項に記載のユーザ端末。ネットワーク構成の観点から、全てのサブフレームにおいてPUCCHフォーマット3のために利用されるリソースの量を同一とすることが興味深い。PUCCHフォーマット3のリソースは、PUCCHフォーマット2及びPUCCHフォーマット1と共に帯域の端に割り当てられる可能性が最も高い。しかしながら、SRSが送信されると共に短縮化されたPUCCHフォーマット3が使用されるサブフレームにおいて、より少ないUEがPUCCHフォーマット3リソースを共有するかもしれない事実は、PUCCHとして同一のサブフレームにおいてSRSが送信されるときに、SRSが送信されない場合と比較して、より多くのリソースブロックがPUCCHフォーマット3に割り当てられるという効果を生じるだろう。リソース要求の変化というその問題に対する従来の解決策は、他の伝送との衝突の危険を冒すことなく、短縮化されたPUCCHフォーマット3が使用されるサブフレームの場合にPUCCHフォーマット3がより多くのリソースブロックに拡張しうるように、過剰にPUCCHフォーマット3のリソースを供給することだろう。しかしながら、システム容量やスループットに影響を与える準最適なリソース利用となってしまうことが欠点である。別のアプローチは、PUCCHフォーマット2とPUCCHフォーマット1が、拡張されたサイズの、短縮化されたPUCCHフォーマット3と衝突しないように、PUCCHフォーマット3のリソースを過剰に供給するのに代えて、PUCCHフォーマット2とPUCCHフォーマット1とにリソースを割り当てることだろう。しかしながら、これは、PUCCHフォーマット2及びPUCCHフォーマット1のリソースに使用される周期性がSRSの伝送のために予約されているサブフレームの周期性の偶数倍である限りにおいてのみ可能である。したがって、上に概略が説明された問題及び不利点のいくつかを扱うこと、そして、通常のPUCCHフォーマット3を使用するサブフレームで使用されているだろうリソースブロックと同一のセットの範囲内で、短縮化されたPUCCHを使用するサブフレームのためのリソースの割り当てを提供することが目的である。この目的などは、独立請求項に従う方法及びユーザ端末により、そして、従属請求項に従う実施形態により、達成される。1つの実施形態によれば、無線通信システムのためのユーザ端末における、物理上りリンク制御チャネルPUCCHフォーマット3で制御情報を送信するのに使用するリソースを特定する方法が提供される。本方法は、サービング無線基地局からリソースインデックスを受信することと、受信したリソースインデックスに基づいてサブフレームにおいて制御情報の伝送に使用するリソースを特定することとを含む。特定されたリソースは、サブフレームにおいて通常のPUCCHフォーマット3が使用されるか、短縮化されたPUCCHフォーマット3が使用されるかによらず、PRBの同一の限定されたセットの範囲内にある。もう1つの実施形態によれば、無線通信システムのための、物理上りリンク制御チャネルPUCCHフォーマット3で制御情報を送信するのに使用するリソースを特定するように構成されるユーザ端末が提供される。本ユーザ端末は、サービング無線基地局からリソースインデックスを受信する受信部と、受信したリソースインデックスに基づいてサブフレームにおいて制御情報の伝送に使用するリソースを特定する特定部とを含む。特定されたリソースは、サブフレームにおいて通常のPUCCHフォーマット3が使用されるか、短縮化されたPUCCHフォーマット3が使用されるかによらず、PRBの同一の限定されたセットの範囲内にある。実施形態の利点は、PUCCHフォーマット3のリソースを過剰に供給する必要がないためリソース利用が改善することである。これは、より高いシステム容量及びスループットをもたらすだろう。別の利点は、他のPUCCHフォーマット及び他のチャネルのためのリソースの構成を簡素化することが可能となることである。実施形態の他の目的、利点及び特徴は、添付の図面及び請求項と併せて考えられるときに、以下の詳細な説明において説明されるだろう。以下では、様々な態様について、所定の実施形態と添付の図面を参照してより詳細に説明する。説明の目的であって限定の目的でなく、様々な実施形態の完全な理解を提供するために、具体的なシナリオ及び技術のような特定の詳細について説明する。しかしながら、これらの特定の詳細から離れた他の実施形態があってもよい。さらに、当業者は、複数の実施形態が主として方法及びUEの形式で説明されるところ、それらがコンピュータプログラム媒体、及びコンピュータプロセッサと、プロセッサに接続され、ここで開示される方法の工程を実行しうる1以上のプログラムで符号化されたメモリとを備えるシステムにおいて具現化されてもよいことを理解するだろう。ここでは、具体的な例示のシナリオへの参照を用いて複数の実施形態について説明する。特定の態様が、非制限的で一般的なコンテキストにおいて、LTERel-10システムに関して説明される。しかしながら、その実施形態は、PUCCHフォーマット3を使用する他の種類の無線通信システムにも適用されてもよいことに留意すべきである。その実施形態におけるUEは、例えば、移動電話、ページャ、ヘッドセット、ラップトップコンピュータ、及び他の移動体端末を含む。本開示は、無線通信システムのUEにおいて、PUCCHフォーマット3で制御情報を伝送するのに使用するリソースを特定するための方法に関する。以下の文章では、背景について詳述する。PUCCHフォーマット1下りリンクにおいて、1つの伝送ブロックの受信を確認するために、HARQの確認応答が使用される。空間多重の場合、2つの伝送ブロックの受信が確認されてもよい。上ですでに説明したように、HARQの確認応答はPUCCHで送信される。上りリンクのデータ伝送のためのリソースを要求するために、スケジューリング要求が使用される。明らかに、スケジューリング要求は、UEがリソースを要求するときに送信されるべきであって、そうでなければ、UEは、バッテリ資源を節約し、不要な干渉を生み出さないように黙っているべきである。それ故に、HARQの確認応答とは異なり、スケジューリングリクエストにおいて明示的な情報ビットは送信されず、代わりに対応するPUCCHでのエネルギーの存在又は不存在により情報が伝達される。しかしながら、完全に異なる目的で使用されるにも関わらず、スケジューリング要求は、HARQ肯定応答と同一のPUCCHフォーマットを共有する。このフォーマットは、3GPPのLTE規格においてPUCCHフォーマット1と呼ばれる。HARQの肯定応答又はスケジューリング要求のために使用されるPUCCHフォーマット1のリソースは、単一のスカラーのリソースインデックスにより表される。UEは、PUCCHのために構成されるのがどの物理リソースであるかを知らず、リソースインデックスを知っているのみである。インデックスから、位相回転及び直交カバー符号が導出される。HARQ伝送に対して、HARQ確認応答の伝送に使用するリソースインデックスは、UEへの下りリンク伝送のスケジューリングをするのに使用される物理下りリンク制御チャネル上PDCCHでの下りリンク制御シグナリングにより、暗示的に与えられる。したがって、上りリンクHARQの確認応答のために使用するリソースは、動的に変動し、各サブフレームにおいてUEへのスケジューリングに使用される下りリンク制御チャネルに依存する。PDCCHを用いることによる動的スケジューリングに加え、特定のパターンに従ってUEに準永続的なスケジューリングを行う可能性もある。この場合、準永続的なスケジューリングパターンの構成は、HARQ確認応答のために使用するPUCCHリソースインデックスでの情報を含む。これは、スケジューリング要求に対しても当てはまり、構成情報は、UEに、どのPUCCHリソースをスケジューリング要求の伝送に使用するかを通知する。したがって、まとめると、PUCCHフォーマット1リソースは、2つの部分に分けられる。1.準永続的にスケジューリングされたUEからのスケジューリング要求とHARQ確認応答とのために使用される準静的部分。PUCCHフォーマット1のリソースの準静的部分に使用されるリソースの量は動的には変動しない。2.動的にスケジューリングされるUEのために使用される動的部分。動的にスケジューリングされる端末の数が変動すると、動的PUCCHに使用されるリソースの量は変動する。PUCCHフォーマット2チャネル依存のスケジューリングに対応するために、UEにおけるチャネル特性の推定値をeNodeBに供給するようにチャネル状態報告が使用される。1つのチャネル状態報告は、サブフレームごとに多数のビットからなる。サブフレームあたり最大で2ビットの情報の能力を有するPUCCHフォーマット1は、明らかにこの目的に使用することはできない。PUCCHでのチャネル状態報告の伝送は、代わりに、サブフレームあたりに多数の情報ビットの能力を有するPUCCHフォーマット2により取り扱われる。PUCCHフォーマット2は、PUCCHフォーマット1と同じセル固有の系列の位相回転に基づく。PUCCHフォーマット1と同様に、PUCCHフォーマット2のリソースは、リソースインデックスにより表され、リソースインデックスから位相回転と他の必要な量が導出されてもよい。PUCCHフォーマット2のリソースは、準静的に構成される。PUCCHに対するリソースブロックマッピングPUCCHフォーマット1及び2の両方のための上述のL1/L2制御信号は、すでに説明したように、各スロットにおいて1つのリソースブロックを用いて、リソースブロックのペアにおいて送信される。使用するリソースブロックのペアは、PUCCHリソースインデックスから決定される。サブフレームの第1のスロット及び第2のスロットで使用するリソースブロック番号は、RBnumber=fは、いずれのリソースブロックのペアにおいて、PUCCHフォーマット1のマッピングが開始するかを制御する。-NPUCCHは、PUCCHフォーマット1の準静的部分と動的部分との間の分割を制御する。-Ncsは、1つのリソースブロックにおけるPUCCHフォーマット1とフォーマット2との混合を制御する。ほとんどの場合、2つのPUCCHフォーマットがリソースブロックの別個のセットにマップされるように構成がなされるが、1つのリソースブロック内にフォーマット1及び2の間の境界を有する可能性もある。キャリアアグリゲーション20MHzまでの帯域幅に対応するLTERel-8標準が、近年3GPPにおいて標準化されている。しかしながら、国際電気通信連合ITUのコンセプト、国際移動体通信IMT-アドバンストに対する要求を満足させるために、3GPPは、LTERel-10への取り組みを開始している。LTERel-10の1つの部分は、20MHzより広い帯域幅に対応することである。LTERel-10の1つの重要な要求はLTERel-8との後方互換性を確保することである。これは、周波数互換性をも含むべきである。それは、LTERel-10の20MHzより広い1つのキャリアが、LTERel-8のUEに対して多数のLTEキャリアとして見えるべきことを意味するだろう。このようなキャリアのそれぞれは、要素キャリアCCと呼ばれうる。早期のLTERel-10展開に対して特に、LTERel-10の能力を有するUEの数が、多くのLTEレガシーのUEと比べて数が少ないだろうことが予想されうる。したがって、レガシーのUEに対しても広いキャリアの効率的な使用を保証すること、すなわち、広帯域のLTERel-10のキャリアの全ての部分においてレガシーのUEがスケジュールされうるキャリアを実現可能であることが必要である。これを得るための直接的な方法は、キャリアアグリゲーションCAを使用することである。CAは、LTERel-10のUEが、複数のRel-8と同じ構成を有する又は有することができるCCを受信しうることを意味する。図4に、5つの20MHzのCCが全体として統合された100MHzの帯域幅を提供するCAを概略的に示す。統合されるCCの数及び個別のCCの帯域幅は、上りリンクと下りリンクとで異なっていてもよい。対称構成は、下りリンクと上りリンクとにおいてCCの数が同じ場合を指す一方で、非対称構成は、CCの数が異なる場合を指す。セルにおいて構成されるCCの数は、UEから見えるCCの数とは異なり得ることに注意することは重要である。UEは、セルが同数の上りリンクと下りリンクのCCを有して構成される場合であっても、例えば、上りリンクのCCより多くの下りリンクのCCに対応してもよい。元は、LTERel-10のUEは、LTERel-8のUEと同様に振る舞い、初期的なランダムアクセスを行う1つのUL/DLのCCのペアを用いて構成されるだろう。これらのCCは、プライマリ要素キャリアPCCと呼ばれる。上りリンクUL/下りリンクDLのPCCのペアに加えて、eNBは、UEの能力とネットワークとに依存して、必要に応じて、追加のCC、いわゆるセカンダリ要素キャリアSCCを用いてUEを設定してもよい。この設定は、無線リソース設定RRCに基づく。RRCシグナリングの大きなシグナリングとだいぶ低い速度に起因して、複数のCCの全てを現在は使用しなくても、UEをその複数のCCを用いて設定してもよい。PDCCHと物理下りリンク共有チャネルPDSCHのために設定された全てのDLのCCをUEが監視しなければならないこと、この結果として高い電力消費を招くことを防ぐために、LTERel-10は設定に加えてCCの起動に対応する。起動は-RRCシグナリングより高速な-媒体アクセス制御MACシグナリングに基づくため、起動と無効化とは現在のデータレートの要求を満足させるために必要なCCの数に従う。大きなデータ量が届くとすぐに、多数のCCが起動され、データ伝送に使用され、そして、もはや必要でなくなった場合に無効化される。全てのしかし1つのCC-下りリンクのPCC-が、無効化されてもよい。したがって、起動は多数のCCを設定するが、要求に基づいてのみCCを起動するようにする可能性を提供する。ほとんど常に、UEは1つ又は極めて少数のCCを起動し、その結果、受信帯域幅が小さくなり、従って、バッテリ消費も少なくなるだろう。CCのスケジューリングは、PDCCHにおいて、下りリンク割り当てを介して行われる。PDCCHにおける制御情報は、下りリンク制御情報DCIメッセージとしてフォーマットされる。Rel-8において、UEは、1つのDL及び1つのULのCCを用いて動作するのみであり、したがって、DL割り当てとUL許可と対応するDL及びULのCCとの間の関連付けは明らかである。Rel-10では、CAの2つのモードが区別される必要がある。第1の動作モードは多数のRel-8端末の動作と極めて類似し、CC上で送信されたDCIメッセージに含まれるDL割り当てまたはUL許可は、セル固有の対応付け又はUE固有の対応付けを介して関連付けられる、DLのCC自体に対して、又は関連するULのCCに対して有効である。第2の動作モードは、キャリア表示フィールドCIFを用いてDCIメッセージを補強する。CIFを伴うDL割り当てを含むDCIは、CIFで指示されたDLのCCに対して有効であり、CIFを伴うUL許可を含むDCIは、指示されたULのCCに対して有効である。下りリンク割り当てのためのDCIメッセージは、とりわけ、リソースブロック割り当て、変調及び符号化手法に関するパラメータ、及びHARQ冗長バージョンを含む。実際の下りリンク伝送に関するパラメータに加えて、ほとんどの下りリンク割り当てのためのDCIフォーマットは、また、送信電力制御TPCコマンドのためのビットフィールドを含む。これらのTPCコマンドは、HARQフィードバックを送信するのに使用される対応するPUCCHの、ULの電力制御の挙動を制御するのに使用される。キャリアアグリゲーションを伴うPUCCH伝送CAへの対応がLTERel-10で導入されるときに、後に説明するように、多数のCCに対応する多数のHARQビットのフィードバックを可能とするPUCCHフォーマットが要求されている。このようなPUCCHフォーマットは、以下では、PUCCHフォーマット3と呼ばれており、これは、3GPP標準において使用される専門用語である。同義語はCAPUCCHフォーマット、及びDFTS-OFDMPUCCHフォーマットである。PUCCHフォーマット1は、Rel-8PUCCHとも呼ばれうる。UEの観点から、対称又は非対称のUL/DLのCC構成の両方に対応する。いくつかの構成に対して、UL制御情報を多数のPUCCH又は多数のULのCC上で送信する可能性が考えられる。しかしながら、このオプションは、より高いUEの電力消費と特定のUEの能力への依存をもたらす可能性が高い。また、相互変調積intermodulationproductsに起因する実装問題を生み出すかもしれず、一般により高い実装と試験の複雑性につながるだろう。したがって、PUCCHの伝送は、UL/DLのCCの設定へ依存せず、すなわち、設計原理として、1つのULのための全てのULの制御情報は準静的に1つの特定のULCC、アンカーキャリアとも呼ばれるULのPCCにマップされる。さらに、ULPCCとDLPCCとの間のセル固有の対応付けが存在する。すなわち、同一のDLPCCを共有する全ての端末は、同一のULPCCを有するだろう。非対称配置のシナリオにおいては、複数のDLのCCが同一のULのPCCに対応付けられることも可能でありうる。DLのPCC及びULのPCCのみを用いて設定されるUEは、Rel-8規格に従うPUCCH上で、すなわち、先に説明したPUCCHフォーマット1のリソース上で動的なACK/NACKを操作している。DL割り当てのためにPDCCHを伝送するのに使用される第1の制御チャネルエレメントCCEは、PUCCHフォーマット1上の動的ACK/NACKを判定し、又は特定する。1つのDLのCCのみが、ULのPCCとセル固有に対応付けられている場合、全てのPDCCHが異なる第1のCCEを用いて送信されるため、PUCCHの衝突は起きない。セル非対称CAシナリオにおいては、多数のDLのCCが同一のULのCCに、セル固有に対応付けられうる。同一のULのCCを用いるが異なるDLのCCを用いて設定された異なるUEは、異なるDLのPCCを有するが、同一のULのPCCを共有する。複数のUEのDLの割り当てを受信する当該複数のUEは、当該UEのHARQフィードバックを同一のULのCC上で送信するだろう。この場合、PUCCHの衝突が起きないことを保証するのはeNBのスケジューリングである。このコンセプトを多数の設定されたDLのCCを有するUEにまで拡張するのは当然であるかもしれない。DLのPCC上で送信される各PDCCHは、Rel-8に従って、ULのPCC上で予約されるPUCCHリソースを有する。UEが多数のDLのCCを用いて設定されるが、1つのDLのPCC割り当てを受信するのみである場合、UEはなおもULのPCC上のPUCCHフォーマット1のリソースを使用することができるだろう。代わりの方法は、単一のDLのPCC割り当てに対しても多数の設定されたCCに対応する複数のHARQビットのフィードバックを可能とするPUCCHフォーマット3を使用することだろう。しかしながら、設定が多少低速なプロセスであり、DLのPCCのみが起動され使用されるにしても、UEは多くの場合に多数のCCを用いて設定されうるため、これは、PUCCHフォーマット3のリソースの非効率的な使用の原因となるだろう。単一のSCC上でのDL割り当ての受信または多数のDL割り当ての受信においては、PUCCHフォーマット3が使用されるべきである。後者の場合、PUCCHフォーマット3が多数のCCのHARQビットのフィードバックに対応する唯一のフォーマットであるため、PUCCHフォーマット3を使用することは明らかである一方で、最初のケースではPUCCHフォーマット3を使用することは比較的明らかではない。しかしながら、単体でのDLのSCC割り当ては典型的ではない。eNBのスケジューラは、DLのPCC上で単一のDLのCCの割り当てをスケジュールしようとすべきであり、必要でなければSCCを無効化しようとすべきである。もう1つの問題は、CIFが設定されないとすれば、DLのSCCの割り当てのためのPDCCHがSCC上で送信され、従って、この場合、ULのPCC上で自動で予約されるPUCCHフォーマット1のリソースがないことである。独立したDLのSCC割り当てに対してもPUCCHフォーマット1のリソースを使用することは、ULのPCCを使用する任意のUEにより設定されるDLの任意のCCのために、PUCCHフォーマット1のリソースをこのULのPCC上に予約することを要求するだろう。独立したSCCの割り当てが典型的ではないため、これは、ULのPCC上で、PUCCHフォーマット1のリソースを不要かつ過剰に供給することを招来するだろう。起こり得る可能性のある誤ったケースは、eNBが、UEに、PCCを含む多数のDLのCC上でスケジューリングすることである。UEがDLのPCC割り当てを除く全てを復号できない場合、UEは、PUCCHフォーマット3の代わりにPUCCHフォーマット1を使用するだろう。この誤ったケースを検出するために、eNBは、PUCCHフォーマット1及びPUCCHフォーマット3の両方を監視しなければならない。実際に受信されるDL割り当ての数によって、UEは対応する数のHARQフィードバックビットを準備しなければならない。第1の場合では、UEは受信した割り当ての数に従ってPUCCHフォーマット3に適合することができ、したがってフィードバックを与えることができるだろう。しかしながら、DL割り当てに伴うPDCCHが失われるかもしれず、したがって、受信したDLの割り当てによってPUCCHフォーマット3に適合するかが不明りょうとなり、eNBにおいて多くの異なる仮説を検証することが必要となるだろう。代わりに、PUCCHフォーマットを起動メッセージによって設定または起動メッセージに含めることができるだろう。各CCの起動と無効化は、MAC制御要素を用いて行われる。MACシグナリングと特に起動コマンドが成功裏に受信されたかを示すHARQフィードバックシグナリングはエラーが生じやすいため、このアプローチも、eNBにおける多数の仮設の検証を要求する。したがって、PUCCHフォーマットが設定されたCCの数に基づくことが最も安全な選択の様であり、3GPPのLTE標準において、周波数分割複信を用いるシステムに適合されている。CCの設定は、すでに上述したように、RRCシグナリングに基づく。受信の成功と新しい構成の適用との後、確認メッセージが返送され、したがって、RRCシグナリングに基づいて極めて安全に設定を行われる。RRCシグナリングの欠点は、比較的低速で、実際に使用されるCCの数が設定されたCCの数より少ない場合に現在使用しているCCの数を追跡できずに性能劣化が生じることである。PUCCHフォーマット3図5aは、4つより多くのACK/NACKビットに対応するUEのためのDFTS-OFDMに基づく通常のPUCCHフォーマット3に対する送信手法の1つの実施形態のブロック図を示す。スケジューリング要求情報ビットとチャネル状態情報ビットとの少なくともいずれかをも含みうる多数のACK/NACKビットが、48の符号化ビットを形成するように符号化501、502される。符号化ビットは、その後、セル固有のそして場合によってはDFTS-OFDMシンボル依存の系列を用いてスクランブリング503される。24ビットが各DFTS-OFDMシンボルの第1のスロット内で送信され、他の24ビットが各DFTS-OFDMシンボルの第2のスロット内で送信される。各DFTS-OFDMシンボルごとに24ビットが12個のQPSKシンボルに変換504され、5つのDFTS-OFDMシンボルにわたって直交時間領域カバー系列[w...w]が乗じられ、離散フーリエ変換DFTで符号化され、周波数領域における1つのリソースブロック及び時間領域の5つのシンボル内で送信される。直交時間領域カバー系列はUEに固有であり、同一のリソースブロック内で5つまでのUEの多重化を可能とする。使用されうる直交系列の例を表1に示す。表1では、各直交系列が直交系列インデックスnocにより特定される。NSF0PUCCHは、サブフレームの第1のタイムスロット、すなわちタイムスロット0においてPRBに利用可能な直交系列の数に対応する。この実施形態では、NSF0PUCCHは5に等しい。参照信号シンボルのために、周期的にシフトされた定振幅ゼロ自己相関CAZAC系列を使用してもよい。参照信号間の直交製をさらに改善するために、長さ2の直交カバー符号を、参照信号シンボルに適用してもよい。表1NSF0PUCCH=5に対する直交系列[w...w]SRSがサブフレームにおいて設定されるとき、SRSはそのサブフレームの最後のDFTSーOFDMシンボルにおいて送信される。これは、SRSを運ぶサブフレームの最後のDFTS-OFDMシンボルにおいて無音となる、特別な短縮化されたPUCCHフォーマット3が要求されることを意味する。この無音化は、SRS及びPUCCHが同一のサブフレーム内で送信される場合に、他のUEからのSRS伝送と衝突することを防ぐために行われる。このような短縮化されたPUCCHフォーマット3の送信手法の一例を図5bのブロック図に示す。図5bと図5aとの違いは、UEが、PUCCHフォーマット3が送信されるのと同じリソースブロックでSRSを送信している他のUEの邪魔をしないように、最後のDFTS-OFDMシンボルがパンクチャされていることである。短縮化されたPUCCHフォーマット3の利点は、PUCCHを送信するUEが複数のクラスタを送信することなくそのサブフレームの最後のDFTS-OFDMシンボルにおいてSRSを送信する可能性を有することである。しかしながら、サブフレームの第2のスロットの最後のDFTS-OFDMシンボルが送信されると、この実施形態では、同一のリソースブロック内で4つのユーザを多重化することのみが可能となるだろう。使用されうる4点の直交系列の例を表2に示す。NSF1PUCCHは、第2のタイムスロット、すなわちタイムスロット1におけるPRBに利用可能な直交系列の数に対応する。この実施形態では、短縮化されたPUCCHフォーマット3が使用されるため、NSF1PUCCHは4に等しい。結果として、特定のサブフレームおける通常のPUCCHフォーマット3又は短縮化されたPUCCHフォーマット3のUEの選択は、主として、eNBがセル固有のSRSパターンをそのサブフレームにおいて割り当てたか否かに依存する。表2NSF1PUCCH=4に対する直交系列[w...w]PUCCHフォーマット3を送信するために割り当てられたリソースは、明示的なシグナリング、例えばRRCシグナリングにより、または、1つ若しくはいくつかのDCIメッセージにおいて動的かつ明示的なシグナリングを用いて、またはその両方により、与えられうるだろう。そのリソースは、黙示的なシグナリング、例えばいずれのCCEにより対応するPDCCHメッセージが送信されたかにより、与えられてもよい。また、そのリソースは、明示的なシグナリングと黙示的なシグナリングとの組み合わせにより与えられてもよい。ネットワークの観点から、典型的には、リソースブロックのセットがPUCCHフォーマット3を処理するために確保される。そのリソースブロックのセットは、スロットの境界で周波数ホッピングさせるときに最大の周波数ダイバーシティを達成するために、ほとんどの場合、全体のシステム帯域幅の2つの端に、PUCCHフォーマット2若しくはPUCCHフォーマット1に隣接するリソースブロック上に、又はその両方に、割り当てられるだろう。以下の例では、15個のPUCCHフォーマット3のリソースブロック又はPRBが設定される。SRSが送信されず通常のPUCCHフォーマット3が使用されるサブフレームにおいては、表3に与えられるPRBの位置及び直交カバー符号OCC系列インデックスを用いて、15個のPUCCHフォーマット3リソースが編成されうる。表3SRSが送信されると共に短縮化されたPUCCHフォーマット3が使用されるサブフレームにおいては、5つではなく、4つのUEのみが同一のPRBを共有しうる。したがって、従来のPUCCHのためのリソースブロックマッピングが使用される場合、表4に与えられるPRBの位置及び直交カバー符号OCC系列インデックスを用いて、15個のPUCCHフォーマット3リソースが編成されうる。表4したがって、15個のPUCCHフォーマット3リソースは、PRBの同一のセットに収まらないだろう。PUCCHフォーマット3に使用されるリソースは、さらにもう1つのPRBに拡張されるだろう。この、必要なリソースブロックの変動は、その結果、通常のPUCCHフォーマット3を使用するサブフレームにおいて、PUCCHフォーマット3が短縮化されたPUCCHフォーマット3を使用するサブフレームにおけるより多くのリソースブロックに拡張するだろうことに対応するために、サブフレームでネットワークがPUCCHフォーマットリソースを過剰に供給することを要求するため、問題である。別のアプローチは、PUCCHフォーマット2及びPUCCHフォーマット1が拡張されたサイズの短縮化されたPUCCHフォーマット3と衝突しないように、PUCCHフォーマット2及びPUCCHフォーマット1のためのリソースを割り当てることであろう。しかしながら、これは、PUCCHフォーマット2及びPUCCHフォーマット1リソースに使用される周期がSRS送信のために予約されるサブフレームの周期の偶数倍である限りにおいてのみ可能である。したがって、通常のPUCCHフォーマット3と短縮化されたPUCCHフォーマット3とのいずれが使用されるかによらず、全てのUEからのPUCCHフォーマット3のために利用されるリソースの量を同じにすることが興味深い。本発明の実施形態においては、通常のPUCCHフォーマット3を使用するか、短縮化されたPUCCHフォーマット3を使用するかによって、PUCCHフォーマット3に割り当てられたリソース数が変動する問題に、UEが基地局から受信したリソースインデックスに基づいて制御情報の伝送のために使用するリソースを特定し、サブフレームにおいて通常のPUCCHフォーマット3と短縮化されたPUCCHフォーマット3のいずれが使用されるかによらず、特定されたリソースが同一の限定されたPRBのセットの範囲内にあるようにする解決法により対処する。したがって、UEによりPUCCHフォーマット3を送信するのに使用されるリソースは、限定された量のシグナリングされたリソースの範囲内になるように設定される。第1の実施形態において、PUCCHフォーマット3を使用するのにUEが使用するリソースは、シグナリングされた値のセットの範囲内に、またPRB単位ベースで、限定される。これは、UEが、通常のPUCCHフォーマット3と短縮化されたPUCCHフォーマット3のいずれが使用されるかによらず、PUCCHフォーマット3の伝送のために、同一のPRBを特定することを意味する。この第1の実施形態の例について、以下説明する。この例においては、15個のPUCCHフォーマット3リソースが設定される。通常のPUCCHフォーマット3が使用されるサブフレームにおいては、15個のPUCCHフォーマット3リソースは、表3に示すように編成される。一方で、短縮化されたPUCCHフォーマット3が使用されるサブフレームにおいては、表5に与えられるPRBの位置及び直交カバー符号OCC系列インデックスを用いて、15個のPUCCHフォーマット3リソースが編成される。表5例えば、PUCCHフォーマット3のリソースのインデックス0及び4は、同一の物理無線リソースPRBを利用することが観測されるかもしれない。それ故に、短縮化されたPUCCHフォーマット3を用いるこのサブフレームにおいて、これらの2つの無線リソースを、2つのUEが使用することはできない。このような衝突を防ぐため、ネットワークは、一方のみがPUCCHフォーマット3を送信するように、これらのUEのためにPUSCHをスケジューリングしてもよい。UEがPUSCHデータを送信するようにスケジューリングされると、通常PUCCH上で送信される制御情報は、代わりにPUSCHデータと共に送信されるかもしれず、したがって、そのUEに対してはPUCCHフォーマット3のリソースは必要でなくなる。しかしながら、この第1の実施形態は、4つより多くのリソースが設定されたPRBのいずれをも占有しないようにPUCCHフォーマット3のリソースが割り当てられている場合、このようなスケジューリングの制約を導入しない。この第1の実施形態において、UEがPUCCHフォーマット3のリソースを特定するために使用するリソースインデックスは、以下の等式によって与えられる。ここで、nstaticresourceは、例えばRRCシグナリングを用いることにより明示的かつ静的に割り当てられたリソースインデックスであり、ndynamicresouceは、1つまたはいくつかのDLの割り当てにおいて示される動的リソース表示であり、nimplicitは、例えば、1つ又はいくつかのDLの割り当てのCCEの位置に対して導出される黙示的リソース表示であり、Nstartは、帯域端からのPRBの数で与えられうるPUCCHフォーマット3のリソースの開始点であり、NSF0PUCCH=5であり、NDFTSOFDMは、例えばリソースブロックの点で、存在するPUCCHフォーマット3のリソースの総数である。リソースインデックス又は表示nstaticresource、ndynamicresouce、nimplicitのいずれかが存在しない場合、それらは式1においてゼロに設定される。PUCCHフォーマット3によって使用されるべきリソースブロックは、実施形態において、により与えられる。実施形態においてPUCCHフォーマット3に使用される直交系列インデックスは、により与えられる。ここで、通常のPUCCHフォーマット3が使用される場合はNSF1PUCCH=5であり、短縮化されたPUCCHフォーマット3が使用される場合はNSF1PUCCH=4である。第2の実施形態において、UEがPUCCHフォーマット3を送信するのに使用するリソースは、限定された値の範囲内にあるように制限される。この第2の実施形態の例について、以下説明する。本実施形態においては、先の例と同様に、15個のPUCCHフォーマット3のリソースが設定される。通常のPUCCHフォーマット3が使用されるサブフレームにおいては、15個のPUCCHフォーマット3リソースは、表3に示すように編成される。短縮化されたPUCCHフォーマット3が使用されるサブフレームにおいては、表6に与えられるPRBの位置及びOCC系列インデックスを用いて、15個のPUCCHフォーマット3のリソースが編成される。表6例えば、PUCCHフォーマット3のリソースのインデックス0及び12は、同一の物理無線リソースを利用することが観測されるかもしれない。それ故に、短縮化されたPUCCHフォーマット3を用いるサブフレームにおいて、これらの2つのPUCCHフォーマット3のリソースを、2つのUEが使用することはできない。このような衝突を防ぐため、ネットワークは、その2つのUEの1つのみがPUCCHフォーマット3を送信するように、この2つのUEのためにPUSCHをスケジューリングしてもよい。この第2の実施形態において、UEがPUCCHフォーマット3のリソースを特定するために使用するリソースインデックスは、以下の等式によって与えられる。ここで、nstaticresourceは、例えばRRCシグナリングを用いることにより明示的かつ静的に割り当てられたリソースインデックスであり、ndynamicresouceは、1つまたはいくつかのDLの割り当てにおいて示される動的リソース表示であり、nimplicitは、例えば、1つ又はいくつかのDLの割り当てのCCEの位置に対して導出される黙示的リソース表示であり、通常のPUCCHフォーマット3が使用される場合はNSF1PUCCH=5であると共に短縮化されたPUCCHフォーマット3が使用される場合はNSF1PUCCH=4である。リソースインデックス又は表示nstaticresource、ndynamicresouce、nimplicitのいずれかが存在しない場合、すなわち、リソースインデックスをシグナリングするのに使用されない場合、それらは式4においてゼロに設定される。一般に、NSF1PUCCHは多重化容量、又は所与のサブフレームの第2のスロットにおけるリソースブロックで利用できる直交系列の数を与え、NDFTSOFDMは、例えばリソースブロックの点で、存在するPUCCHフォーマット3のリソースの総数である。PUCCHフォーマット3により使用されるべきリソースブロックは、1つの実施形態において、により与えられる。ここで、Nstartは、帯域端からのPRBの数で与えられうるPUCCHフォーマット3のリソースの開始点である。1つの実施形態においてPUCCHフォーマット3に使用される直交系列インデックスは、により与えられる。より一般的に、この第2の実施形態の1つのとりうる実装は、シグナリングされたPUCCHリソースインデックス又は導出されたPUCCHリソースインデックスに対して剰余モジュロ演算を適用することである。すなわち、であり、ここで、nPUCCHsigは、サブフレームにおいて使用されるべき、シグナリングされたリソースインデックス、又は、例えば黙示的及び明示的にシグナリングされたインデックスの和nstaticresourcendynamicresoucenimplicitとして、導出されたリソースインデックスであり、NDFTSOFDMPUCCHは、所与のサブフレームにおいて使用可能なPUCCHフォーマット3のリソースの総数である。関数f1及びf2は、所与のリソースインデックスnをPRB及びOCCのそれぞれにマップする。図6aは、実施形態に係る、無線通信システムのUEにおける方法のフローチャートである。本方法は、PUCCHフォーマット3条で制御情報の送信に使用するリソースを特定するに使用される。本方法は、以下を含む。-610:サービングRBSからリソースインデックスを受信する。-620:受信したリソースに基づき、サブフレームにおける制御情報の伝送に使用するリソースを特定する。特定されるリソースは、そのサブフレームにおいて通常のPUCCHフォーマット3が使用されるか短縮化されたPUCCHフォーマット3が使用されるかによらず、同一の制限されたPRBのセットの範囲内にある。図6bは、上述の第1の実施形態に係るUEにおける方法のフローチャートである。本方法は、サービングRBSからリソースインデックスを受信する初期ステップ610を含む。受信したリソースインデックスに基づいて、サブフレームにおける制御情報の伝送に使用するリソースを特定するステップ620は、以下を含む。-621:受信したリソースインデックスに基づいてPRBを特定する。ここで、特定されるPRBは、通常のPUCCHフォーマット3が使用されるか、短縮化されたPUCCHフォーマット3が使用されるかによらず、同一である。そのPRBは、1つの実施形態において、上の式2により与えられるnPRBに基づいて特定されてもよい。-622:上の式3により与えられる直交系列インデックスnocに基づいて、直交系列を特定する。図6cは、上述の第2の実施形態に係るUEにおける方法のフローチャートである。本方法は、サービングRBSからリソースインデックスを受信する初期ステップ610を含む。受信したリソースインデックスに基づいて、サブフレームにおける制御情報の伝送に使用するリソースを特定するステップ620は、以下を含む。-623:受信したリソースインデックスとPUCCHフォーマット3に利用可能なPRBの総数とに基づいて、変形したリソースインデックスを計算する。-624:変形されたリソースインデックスに基づいて、リソースを特定する。ここで、特定されるPRBは、通常のPUCCHフォーマット3が使用されるか、短縮化されたPUCCHフォーマット3が使用されるかによらず、同一である。変形されたリソースインデックスは、受信したリソースインデックスを被除数として、PUCCHフォーマット3に利用可能なPRBの総数を除数として用いた剰余演算として計算されうる。変形されたリソースインデックスに基づいて、上の式5により与えられるnPRBに基づいて、PRBが特定されてもよい。さらに、上の式6により与えられる直交系列インデックスnocに基づいて、直交系列が特定されうる。実施形態にしたがって、UE800を図8aに概略的に示す。UE800は、無線通信システムにおいて使用されるように構成されると共に、PUCCHフォーマット3上で制御情報の伝送に使用するリソースを特定するように構成される。UEは、サービングRBSからリソースインデックスを受信するように適合される受信部810と、受信したリソースインデックスに基づいて、サブフレームにおける制御情報の伝送に使用するリソースを特定するように適合される特定部820とを有する。ここで、特定されるリソースは、そのサブフレームにおいて通常のPUCCHフォーマット3が使用されるか短縮化されたPUCCHフォーマット3が使用されるかによらず、同一の制限されたPRBのセットの範囲内にある。上述の第1の実施形態では、特定部820は、受信したリソースインデックスに基づいてPRBを特定するように適合され、特定されるPRBは、そのサブフレームにおいて通常のPUCCHフォーマット3が使用されるか短縮化されたPUCCHフォーマット3が使用されるかによらず、同一である。特定部820は、上の式2により与えられるnPRBに基づいてそのPRBを特定するように適合されてもよい。特定部820は、また、上の式3により与えられる直交系列インデックスnocに基づいて、直交系列を特定するように適合されてもよい。上述の第2の実施形態において、特定部820は、受信したリソースインデックスとPUCCHフォーマット3に利用可能なPRBの総数とに基づいて、変形したリソースインデックスを計算するように適合されると共に、変形されたリソースインデックスに基づいて、リソースを特定するように適合される。この実施形態において、特定されるリソースは、通常のPUCCHフォーマット3が使用されるか、短縮化されたPUCCHフォーマット3が使用されるかによらず、同一の制限されたPRBのセットの範囲内にある。特定部820は、受信したリソースインデックスを被除数として、PUCCHフォーマット3に利用可能なPRBの総数を除数として用いた剰余演算として、変形されたリソースインデックスを計算するように適合されてもよい。特定部820は、上の式5により与えられるnPRBに基づいて、PRBを特定するように適合されてもよい。さらに、特定部820は、上の式6により与えられる直交系列インデックスnocに基づいて、直交系列を特定するように適合されてもよい。図8aを参照して上述した各部は論理ユニットであり、必ずしも別個の物理ユニットに対応しない。図8bは、図8aに図解された実施形態の開示の別の方法である、UE800の実施形態を概略的に図解している。UE800は、サービングRBSからリソースインデックスを受信するための受信部810を有する。UE800は、また、単一のユニット又は複数のユニットでありうる処理部854を有する。さらに、UE800は、不揮発メモリ、例えば、EEPROM電気的消去可能プログラム可能読み出し専用メモリ、フラッシュメモリ又はディスクドライブの形式で、少なくとも1つのコンピュータプログラム媒体855を有する。コンピュータプログラム媒体855は、UE上で動作するときに、図6a~cと共に先に説明した手順の工程をUE800の処理部854に実行させるコード手段を備えるコンピュータプログラム856を含む。したがって、説明した実施形態において、UE800のコンピュータプログラム856におけるコード手段は、受信したリソースインデックスに基づいてサブフレームにおける制御情報の伝送に使用するリソースを特定するための特定モジュール856aを有する。ここで、特定されるリソースは、そのサブフレームにおいて通常のPUCCHフォーマット3が使用されるか短縮化されたPUCCHフォーマット3が使用されるかによらず、同一の制限されたPRBのセットの範囲内にある。コード手段は、このように、コンピュータプログラムモジュールにおいて構造化されたコンピュータプログラムコードとして実装されうる。モジュール856aは、基本的に、図8aで説明したネットワークノードをエミュレートするために図6aのフローのステップ620を実行する。換言すれば、モジュール856aが処理部854で実行されるとき、それは、図8aのユニット820に対応する。図8bと共に上で開示した実施形態におけるコード手段は、UE800上で実行されるときにUEに図6aとともに上述したステップを実行させるコンピュータプログラムとして実装されるが、1つ以上の当該コード手段は、別の実施形態において、少なくとも部分的にハードウェアの回路として実装されてもよい。図7は、上述の方法を実行しうるUEにおける装置700のブロック図である。図7に示される機能ブロックは、様々な透過的な手法で組み合わされても再構成されてもよく、その機能の多くは1つ以上の適切なプログラムされたデジタルシグナルプロセッサにより実行されてもよいことが理解されるだろう。さらに、図7に示される機能ブロック間の接続及び機能ブロックにより提供又は交換される情報は、UEの動作に含まれる他の方法をUEが実行することができるように様々な方法で変更されてもよい。図7に描かれるように、UEは、アンテナ702を介して、DLの無線信号を受信し、典型的にはフロントエンド受信機FeRX704において受信した無線信号をアナログベースバンド信号へとダウンコンバートする。ベースバンド信号は、帯域幅BW0を有するアナログフィルタ706によりスペクトル整形され、フィルタ706により生成された、整形されたベースバンド信号は、アナログ-デジタル変換機ADC708により、アナログからデジタル形式へと変換される。デジタル化されたベースバンド信号は、さらに、同期信号又はDL信号に含まれるシンボルの帯域幅に対応する帯域幅BWsyncを有するデジタルフィルタ710により、スペクトル整形される。フィルタ710により生成された、整形された信号は、特定の通信システム、例えば3GLTEのために規定されるように、セルをサーチする1つ以上の方法を実行するセルサーチ部712へ供給される。典型的には、このような方法は、受信信号において、所定のプライマリ同期チャネルとセカンダリ同期チャネルとの少なくともいずれかP/S-SCHの信号を検出することを含む。デジタル化されたベースバンド信号は、ADC708によって、帯域幅BW0を有するデジタルフィルタ714にも供給され、フィルタリングされたデジタルベースバンド信号は、高速フーリエ変換FFT、又はそのベースバンド信号の周波数領域スペクトル表現を生成する他の適切なアルゴリズムを実行するプロセッサ716に供給される。チャネル推定部718はプロセッサ716から信号を受信し、制御部720により供給される制御及びタイミング信号に基づいて、サブキャリアi及びセルjのそれぞれに対するチャネル推定値Hijを生成する。制御部720は、そのような制御及びタイミング情報をプロセッサ716にも供給する。推定部718は、チャネル推定値Hiを復号器722及び信号電力推定部724へ供給する。プロセッサ716からも信号を受信する復号器722は、上述のようなRRC又は他のメッセージから情報を抽出するように適切に構成され、典型的には、UEにおけるさらなる処理不図示の対象となる信号を生成する。推定部724は、受信信号電力測定値例えば、参照信号受信電力RSRP、受信サブキャリア電力Si、信号対干渉比SIRなどの推定値を生成する。推定部724は、RSRPの推定値、参照信号受信品質RSRQ、受信信号強度表示RSSI、受信サブキャリア電力Si、SIR、及び他の関連する測定値を、制御部720が供給した制御信号に応答して様々な方法で生成してもよい。推定部724が生成した電力推定値は、典型的には、UEでの更なる信号処理において使用される。推定部724又は、さらに言うなら、サーチ部712は、適切な信号相関器を含むように構成される。図7に描画した構成では、制御部720は、サーチ部712、プロセッサ716、推定部718、及び推定部724を設定するのに要求される実質的に全ての形跡を保持する。推定部718に対しては、これは、参照信号抽出及び参照信号のセル固有のスクランブリングのための方法とセル識別子の両方を含む。サーチ部712と制御部720との間の通信は、セル識別子と、例えば、サイクリックプリフィックスの設定とを含む。制御部720は、検出された1つ又は複数のセルでの測定のために、いくつかのとりうる推定方法のうちいずれが、推定部718と推定部724との少なくともいずれかにより使用されるかを決定してもよい。また、典型的には相関器を含むか、相関器の機能を実行しうる制御部720は、ネットワークによりシグナリングされた情報を受信してもよく、FeRX704のオン/オフ時間を制御してもよい。制御部720は、送信器フロントエンドFETX728へ供給される変調シンボル又は同様の情報を生成する符号化器726へ、適切な情報を供給する。送信器フロントエンドFETX728は、通信システムに適した送信信号を生成する。図7に示すように、送信信号はアンテナ702に供給される。制御部720は、符号化器726と共に、上述のように、UEによりネットワークへ送信されるRRC及び他のメッセージを生成するのに適して構成される。UEの制御部及び他のブロックは、1つ以上のメモリに記憶された情報を処理する、1つ以上の適切なプログラムされた電子プロセッサ、一群の論理ゲート等により実装されてもよい。上述のとおり、UEは、制御部及び制御部により実行可能なソフトウェアと協働して、方法を実行し、上述の信号を受信し生成するのに適したメモリ又は他の情報記憶機能を含む。記憶される情報は、制御部が上述の方法を実行することを可能とするプログラム命令及びデータを含んでもよい。制御部は、典型的には、その動作を促進するタイマなどを含むことが理解されるだろう。上で言及され説明された実施形態は、例示のためだけに与えられたものであり、限定するものではない。添付の特許請求の範囲の範囲内の他の解決法、使用、目的、及び機能も考えられてもよい。略語3GPP第3世代パートナーシッププロジェクトACK肯定応答CAキャリアアグリゲーションCAZAC定振幅ゼロ自己相関CC要素キャリアCCE制御チャネルエレメントCIFキャリア表示フィールドCNコアネットワークDCI下りリンク制御情報DFT離散フーリエ変換DFTSDFT拡散DL下りリンクeNB、eNodeBエボルブドノードBE-UTRANエボルブドUTRANUTRANユニバーサル地上無線アクセスネットワークFDD周波数分割複信HARQ複合自動再送要求LTEロングタームエボリューションMAC媒体アクセス制御MHzメガヘルツNACK非肯定応答OCC直交カバー符号OFDM直交周波数分割多重PCCプライマリ要素キャリアPDCCH物理下りリンク制御チャネルPDSCH物理下りリンク共有チャネルPRB物理リソースブロックPUCCH物理上りリンク制御チャネルREリソースエレメントRel-10リリース10Rel-8リリース8RRC無線リソース設定SCCセカンダリ要素キャリアSRSサウンディング参照信号TPC送信電力制御UEユーザ端末UL上りリンクUMTSユニバーサル移動通信システム