(57)【要約】【課題】ＬＴＥ進化型システムにおいてアップリンク制御情報を送信するための方法およびシステムを提供する。【解決手段】アップリンク制御情報を送信する方法は、アップリンク制御情報がクライテリアを満たすことを決定することであって、クライテリアは、あるタイプのアップリンク制御情報ビットを備える、ことと、アップリンク制御情報がクライテリアを満たすことを決定することに応答して、第１のサブフレームにおいて物理的アップリンク制御チャネル上でアップリンク制御情報ビットの第１のサブセットを送信することと、第１のサブフレームにおいて物理的アップリンク共用チャネル上でアップリンク制御情報ビットの第２のサブセットを送信することと、を備える。【選択図】図６
2014209806.tif 000002
【特許請求の範囲】
【請求項１】
アップリンク制御情報を送信する方法であって、
前記アップリンク制御情報がクライテリアを満たすことを決定することであって、前記クライテリアは、あるタイプのアップリンク制御情報ビットを備える、ことと、
前記アップリンク制御情報が前記クライテリアを満たすことを決定することに応答して、第１のサブフレームにおいて物理的アップリンク制御チャネル上でアップリンク制御情報ビットの第１のサブセットを送信することと、前記第１のサブフレームにおいて物理的アップリンク共用チャネル上でアップリンク制御情報ビットの第２のサブセットを送信することと
を備えることを特徴とする方法。
【請求項２】
前記あるタイプのアップリンク制御情報ビットは、ＨＡＲＱ（hybrid automatic repeat request）  ＡＣＫ／ＮＡＣＫ（肯定応答／否定応答）、ＳＲ（scheduling request）、ＣＱＩ（channel quality indicator）、ＰＭＩ（precoding matrix indicator）およびＲＩ（rank indicator）のうちの少なくとも一つを備えることを特徴とする請求項１に記載の方法。
【請求項３】
アップリンク制御情報ビットの前記第１のサブセットは、ＨＡＲＱ  ＡＣＫおよびＳＲのうちの少なくとも一つを備えることを特徴とする請求項２に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＬＴＥ−Ａにおけるアップリンク制御情報のシグナリングに関する。
【０００２】
（関連出願の相互参照）
本出願は、それらの全体が、両方共に参照によって本明細書に組み込まれている2009年6月19日に出願された米国仮出願第61/218,782号明細書と、2009年6月24日に出願された米国仮出願第61/220,017号明細書との利益を主張するものである。
【背景技術】
【０００３】
より高速なデータレートとスペクトル効率とをサポートするために、３ＧＰＰ（Third Generation Partnership Project）ＬＴＥ（Long Term Evolution）システムが、３ＧＰＰリリース８（Ｒ８）の中に導入されている（ＬＴＥリリース８は、本明細書においてＬＴＥ  Ｒ８またはＲ８−ＬＴＥと称されることもある）。ＬＴＥにおいては、アップリンク上の伝送は、ＳＣ−ＦＤＭＡ（Single Carrier Frequency Division Multiple Access）を使用して実行される。特に、ＬＴＥアップリンクにおいて使用されるＳＣ−ＦＤＭＡは、ＤＦＴ−Ｓ−ＯＦＤＭ（Discrete Fourier Transform Spread Orthogonal Frequency Division Multiplexing）技術に基づいている。以降で使用されるように、用語ＳＣ−ＦＤＭＡとＤＦＴ−Ｓ−ＯＦＤＭとは、交換可能に使用される。
【０００４】
ＬＴＥにおいては、ＷＴＲＵ（wireless transmit/receive unit、無線送信／受信ユニット）（あるいはＵＥ（user equipment、ユーザ装置）とも称される）は、ＦＤＭＡ（Frequency Division Multiple Access）構成において、割り当てられたサブキャリアの限られた隣接するセットだけを使用してアップリンク上で送信する。例えば、アップリンクにおける全体のＯＦＤＭ（Orthogonal Frequency Division Multiplexing）信号またはシステムの帯域幅が、１から１００と番号づけられた有用なサブキャリアからなる場合、第１の与えられたＷＴＲＵは、サブキャリア１〜１２の上で送信するように割り当てられることが可能になり、第２のＷＴＲＵは、サブキャリア１３〜２４の上で送信するように割り当てられることが可能になる、等のようになる。異なるＷＴＲＵは、おのおの、使用可能な伝送帯域幅のサブセットの中だけへ送信することができるが、ＷＴＲＵをサーブする（serving）ｅＮｏｄｅＢ（evolved Ｎｏｄｅ−Ｂ、進化型ノードＢ）は、全体の伝送帯域幅を通して複合アップリンク信号を受信することができる。
【０００５】
ＬＴＥ進化型（これは、ＬＴＥリリース１０（Ｒ１０）と、リリース１１など、将来のリリースを含む任意のものとを含んでおり、本明細書においてはＬＴＥ−Ａ、ＬＴＥ  Ｒ１０、またはＲ１０−ＬＴＥと称されることもある）は、ＬＴＥと３Ｇネットワークとについての完全に準拠した４Ｇアップグレード経路を提供するＬＴＥ規格の機能強化である。ＬＴＥとＬＴＥ−Ａとの両方においては、ある種の関連するレイヤ１／レイヤ２（Ｌ１／２）アップリンク制御情報（uplink control information、ＵＣＩ）が、ＵＬ（アップリンク）伝送、ＤＬ（ダウンリンク）伝送、スケジューリング、ＭＩＭＯ（multiple-input multiple-output）などをサポートする必要性が存在する。ＬＴＥ−Ａにおいては、それぞれのアップリンクチャネルについてのパワー設定が、独立に行われることが可能である。当技術分野において必要なことは、アップリンク制御情報を提供し、そして複数のアップリンクチャネルを使用するときに起こり得るパワーの問題に対処するためのシステムおよび方法である。
【発明の概要】
【０００６】
ＬＴＥ進化型システムにおいてアップリンク制御情報（ＵＣＩ）を送信するための方法およびシステムが、開示される。ユーザ装置デバイス（ＵＥ）は、ＵＣＩの中のビットの数がＵＥに対して提供され得るしきい値以下であるかどうかに基づいて、アップリンク制御情報が、ＰＵＣＣＨとＰＵＳＣＨと（ＰＵＣＣＨの上で送信されるビットとＰＵＳＣＨの上で送信される残りのビットとのサブセット）を通して送信されるべきかどうかを決定することができる。ＵＣＩビットの数が、しきい値以下である場合、ＵＣＩビットは、ＰＵＣＣＨの上で送信されることが可能であるのに対して、ＵＣＩビットの数がしきい値よりも上にある場合、ＵＣＩビットは、同じサブフレームにおいてＰＵＳＣＨとＰＵＣＣＨとの両方の上で送信されることが可能である。別の実施形態においては、ＵＣＩビットの数は、第２のもっと高いしきい値と比較されることが可能であり、そしてＵＣＩビットの数が、第２のもっと高いしきい値を超過する場合、すべてのＵＣＩビットは、ＰＵＳＣＨの上で送信されることが可能である。別の実施形態においては、すべてのＵＣＩビットがＰＵＣＣＨ上に適合することになる場合、それらは、ＰＵＣＣＨの上で送信されることが可能である。すべてのビットが、ＰＵＣＣＨ上に適合しないことになる場合、それらは、同じサブフレームにおいてＰＵＣＣＨとＰＵＳＣＨとの両方の上で送信されることが可能である。別の実施形態においては、ＵＣＩの相対的サイズ（すなわち、共用チャネル、例えば、ＰＵＳＣＨの容量のサイズと比べたＵＣＩペイロードのサイズ）が、決定されることが可能であり、そして相対的サイズが、しきい値よりも下にある場合、ＵＣＩビットは、ＰＵＳＣＨだけの上で送信されることが可能である。
【０００７】
別の実施形態においては、ＵＣＩビットのタイプが決定されることが可能であり、そしてある種のタイプのビット（例えば、ＡＣＫ／ＮＡＣＫビット）が存在する場合、ある種のタイプのビットは、ＰＵＣＣＨなど、１つのチャネルの上で送信されることが可能であるが、残りのビットは、ＰＵＳＣＨなど、第２のチャネルの上で送信されることが可能である。あるいは、アクティブであり、またはあるいは、構成されたＤＬ  ＣＣ（downlink component carriers、ダウンリンクコンポーネントキャリア）の数と、ＬＴＥリリース８においてサポートされる伝送モードの使用とが、考慮に入れられることが可能である。ＤＬ  ＣＣの数が、１ではない、またはＬＴＥリリース８においてサポートされる伝送モードが、使用されない場合、ＵＣＩビットのサブセットが、ＰＵＣＣＨの上で送信されることが可能であるが、同じサブフレームにおいて、残りのビットは、ＰＵＳＣＨの上で送信されることが可能である。ＤＬ  ＣＣの数が、１であり、ＬＴＥリリース８においてサポートされる伝送モードが使用される場合、ＵＣＩは、内容が、ある種のタイプのＵＣＩビット（例えば、ＡＣＫ／ＮＡＣＫ、ＣＱＩ／ＰＭＩ、ＲＩ）を含むかどうかを決定するために評価されることが可能であり、そしてどのチャネル（単数または複数）をそのようなビットを送信するために使用すべきかについての決定が行われることが可能である。優先順位または主要なＤＬ  ＣＣは、複数のＤＬ  ＣＣが使用可能である（アクティブ、あるいは、構成されている）ときに評価されることも可能であり、そして主要な、または最高優先順位のＤＬ  ＣＣに関連するＵＣＩビットは、ＰＵＣＣＨの上で送信されることが可能であり、残りのビットは、ＰＵＳＣＨの上で送信されている。
【０００８】
複数のチャネルの上でアップリンク制御情報を送信するのに必要とされ得るパワーの量もまた、評価されることが可能である。ＵＥが、ＰＵＳＣＨとＰＵＣＣＨとの両方を通してＵＣＩビットを送信することが最大パワーしきい値を超過することになることを決定する場合、ＵＥは、ＰＵＳＣＨとＰＵＣＣＨとのうちの一方だけの上でＵＣＩビットを送信し、あるいはＰＵＳＣＨおよび／またはＰＵＣＣＨのパワーをスケールダウンすることができる。複数のＰＵＳＣＨが使用可能である場合の実施形態においては、様々な手段を使用して、ＵＣＩペイロードサイズ、ＰＵＳＣＨデータペイロードサイズ、またはＵＣＩペイロードサイズと使用可能なＰＵＳＣＨの搬送容量との間の関係に基づいて適切なＰＵＳＣＨを決定することを含めて、どのＰＵＳＣＨを使用してＵＣＩビットを送信すべきかを決定することができる。現在の開示のこれらおよび追加の態様は、以下でさらに詳細に述べられている。
【図面の簡単な説明】
【０００９】
開示された実施形態の以下の詳細な説明は、添付図面と併せて読まれるときに、よりよく理解される。例証の目的のために、図面の中に例示の実施形態が示されているが、主題は、開示される特定の要素と手段とだけには限定されない。図面には以下がある。
【００１０】
【図１】本明細書に開示されるようなアップリンク制御情報のシグナリングのための方法およびシステムが実装され得る非限定的な例示のユーザ装置と、ｅＮｏｄｅＢと、ＭＭＥ／Ｓ−ＧＷとを示す図である。
【図２】本明細書に開示されるようなアップリンク制御情報のシグナリングのための方法およびシステムが実装され得る非限定的な例示のネットワーク環境を示す図である。
【図３】異なるダウンリンクキャリアについてのＡＣＫ／ＮＡＣＫビットを送信するための非限定的な例示のシステムを示す図である。
【図４】ＵＣＩ伝送についてのＰＵＣＣＨ領域の中の複数のＰＵＣＣＨ  ＲＢリソースを使用するための非限定的な例示の手段を示す図である。
【図５】ＤＬ  ＣＯＭＰ（downlink coordinated multi-point transmission）を利用したシステムにおいてＵＥからＰＵＣＣＨとＰＵＳＣＨとの両方の上でＵＣＩを送信するための非限定的な例示の手段を示す図である。
【図６】どのようにしてＵＣＩをシグナリングするべきかを決定する非限定的な例示の方法を示す図である。
【図７】どのようにしてＵＣＩをシグナリングするべきかを決定する別の非限定的な例示の方法を示す図である。
【図８】どのようにしてＵＣＩをシグナリングするべきかを決定する別の非限定的な例示の方法を示す図である。
【図９】どのようにしてＵＣＩをシグナリングするべきかを決定する別の非限定的な例示の方法を示す図である。
【図１０】どのようにしてＵＣＩをシグナリングするべきかを決定する別の非限定的な例示の方法を示す図である。
【図１１】どのようにしてＵＣＩをシグナリングするべきかを決定する別の非限定的な例示の方法を示す図である。
【図１２】どのようにしてＵＣＩをシグナリングするべきかを決定する別の非限定的な例示の方法を示す図である。
【図１３】どのようにしてＵＣＩをシグナリングするべきかを決定する別の非限定的な例示の方法を示す図である。
【図１４】どのようにしてＵＣＩをシグナリングするべきかを決定する別の非限定的な例示の方法を示す図である。
【図１５】どのようにしてＵＣＩをシグナリングするべきかを決定する別の非限定的な例示の方法を示す図である。
【図１６】どのようにしてＵＣＩをシグナリングするべきかを決定する別の非限定的な例示の方法を示す図である。
【発明を実施するための形態】
【００１１】
図１は、ＬＴＥ−Ａの本主題と特徴とを実装することができる非限定的な例示のＵＥ１０１を示すものである。ＵＥ１０１は、１つまたは複数の他のデバイスまたはネットワークと無線で通信することができる、モバイル電話、スマートフォン、ＰＤＡ（personal data assistant）、ラップトップ、または他の任意のデバイスを含む、任意のタイプのＷＴＲＵとすることができる。いくつかの実施形態においては、ＵＥ１０１は、ＬＴＥ−Ａのネットワークまたはシステムと通信するように構成されていることが可能である。ＵＥ１０１は、プロセッサ１４０を用いて構成されていることが可能であり、プロセッサは、メモリ１５０と通信するように接続されることが可能であり、そしてバッテリ１６０などの電源からパワーを引き出すことができ、電源は、ＵＥ１０１の他のコンポーネントのうちのどれかまたはすべてに対してパワーを供給することもできる。プロセッサ１４０は、本明細書に開示されるようなＵＣＩシグナリングおよび関連した機能、ならびに本明細書に開示された他の任意の機能および／またはＵＥの中で構成されるプロセッサによって実行され得る他の任意の機能を実行するように構成されていることが可能である。メモリ１５０は、本明細書において説明される任意の機能、またはＵＥによって実行され得る他の任意の機能を実行するコンピュータ実行可能命令を含む、データを記憶するように構成されていることが可能である。ＵＥ１０１は、１つまたは複数のアンテナ１１０ａ〜ｄを用いて構成されていることもでき、これらのアンテナは、１つまたは複数のトランシーバ１２０ａ〜ｄから受信されたデータを基地局、ｅＮｏｄｅＢ、または他のネットワークデバイスに対して送信することができ、そしてそのようなデバイスからのデータを１つまたは複数のトランシーバ１２０ａ〜ｄに対して供給することができる。
【００１２】
トランシーバ１２０ａ〜ｄおよび／またはアンテナ１１０ａ〜ｄは、アンテナマッピング／プリコーディングモジュール（antenna mapping/precoding module）１３０に通信するように接続されることが可能である。アンテナマッピング／プリコーディングモジュール１３０は、プロセッサ１４０に通信するように接続されることが可能である。図１に示されるコンポーネントのうちのどれかまたはすべては、物理的に同じコンポーネントであっても、または単一の物理ユニットへと組み合わせられてもよく、またはあるいは、物理的に別々のものであってもよいことに注意すべきである。例えば、アンテナマッピング／プリコーディングモジュール１３０と、プロセッサ１４０と、トランシーバ１２０ａ〜ｄとは、単一のマイクロチップの上で物理的に構成されていてもよく、またはおのおの個々のマイクロチップの上に構成されていてもよい。そのような構成の任意の変形は、本開示の範囲内にあるものと考えられる。
【００１３】
ＵＥ１０１は、ｅＮｏｄｅＢ１７０と無線で通信するように構成されていることが可能である。典型的なｅＮｏｄｅＢにおいて見出され得るコンポーネントに加えて、ｅＮｏｄｅＢ１７０は、プロセッサ１７３を含むことができ、このプロセッサは、ｅＮｏｄｅＢ機能および／または本明細書に開示される主題を実行するように構成され得る任意の１つまたは複数のプロセッサとすることができる。プロセッサ１７３は、メモリ１７４に通信するように接続されることが可能であり、このメモリは、揮発性メモリおよび不揮発性メモリを含めて任意のタイプのメモリ、またはメモリタイプの組合せとすることができる。ｅＮｏｄｅＢ１７０は、トランシーバ１７２ａ〜ｄを用いて構成されていることも可能であり、これらのトランシーバは、アンテナ１７１ａ〜ｄに通信するように接続され、例えば、ＬＴＥシステムまたはＬＴＥ−ＡシステムにおけるＵＥ１０１との無線通信を容易にするように構成されていることが可能である。複数の送信および／または受信アンテナは、ｅＮｏｄｅＢ１７０の上で構成され、それは、そのような複数のアンテナを利用することができるＭＩＭＯ技術および／または他の技術を容易にするためである。
【００１４】
ｅＮｏｄｅＢ１７０は、１つまたは複数の無線または有線の通信接続を経由してＭＭＥ／Ｓ−ＧＷ（Mobility Management Entity/Serving Gateway）１８０に通信するように接続されることが可能である。ＭＭＥ／Ｓ−ＧＷ１８０は、ＭＭＥ／Ｓ−ＧＷ機能および／または本明細書に開示される主題を実行するように構成され得る任意の１つまたは複数のプロセッサとすることができるプロセッサ１８１を用いて構成されていることが可能である。プロセッサ１８１は、メモリ１８２に通信するように接続されることが可能であり、このメモリは、揮発性メモリおよび不揮発性メモリを含めて、任意のタイプのメモリまたはメモリタイプの組合せとすることができる。一実施形態においては、ＵＥ１０１、ｅＮｏｄｅＢ１７０、および／またはＭＭＥ／Ｓ−ＧＷ１８０は、本明細書に開示されるようなＬＴＥ−ＡシステムにおいてＵＣＩシグナリングを実装するように構成されている。
【００１５】
ＤＦＴ−Ｓ−ＯＦＤＭは、ＵＥ１０１からｅＮｏｄｅＢ１７０への（すなわち、アップリンクにおける）通信手段として使用され得る。ＤＦＴ−Ｓ−ＯＦＤＭは、ＵＥに割り当てられる時間−周波数リソースが、周波数連続サブキャリアのセットから成るという追加の制約条件を有するＯＦＤＭ伝送の一形式である。ＬＴＥアップリンクは、直流（ＤＣ）サブキャリアを含まない可能性がある。ＬＴＥアップリンクは、１モードのオペレーションを含むことができ、そこでは周波数ホッピングは、ＵＥによって伝送に対して適用されることが可能である。ＬＴＥリリース８（Ｒ８）のアップリンク（ＵＬ）においては、ある種の関連するレイヤ１／レイヤ２（Ｌ１／２）のアップリンク制御情報（ＵＣＩ）が、アップリンク（ＵＬ）伝送、ダウンリンク（ＤＬ）伝送、スケジューリング、ＭＩＭＯなどをサポートする必要性が存在する。例えば、ＵＥ１０１は、ｅＮｏｄｅＢ１７０に対して定期的に、および／または非定期的にＵＣＩを供給するように構成されていることが可能である。ＵＣＩは、１ビットまたは２ビットとすることができるＨＡＲＱ（hybrid automatic repeat request）ＡＣＫ／ＮＡＣＫ（肯定応答／否定応答）、ＣＱＩ（channel quality indicator、チャネル品質インジケータ）を含むチャネルステータス報告、ＰＭＩ（precoding matrix indicator、プリコーディングマトリクスインジケータ）、および／またはＰＵＣＣＨの上で送信されるときに４〜１１ビットとすることができるＲＩ（rank indicator、ランクインジケータ）、および１ビットとすることができるＳＲ（scheduling request、スケジューリングリクエスト）から成ることができる。これらのタイプのＵＣＩについてのビットの数のこれらの例は、ＬＴＥリリース８におけるこれらのタイプについてのビットの数に対応する。これらのタイプについてのビットの数は、これらの値だけに限定されず、そして他の実施形態が、本開示の範囲内にあるものと考えられる。
【００１６】
特に、ＣＱＩ、ＰＭＩ、およびＲＩのビットタイプについて言及する、本明細書において説明される実施形態および例においては、これらの実施形態は、ＵＥによってサポートされ、そして定期的に、または非定期的に報告され得る追加のＵＣＩビットタイプを含むように簡単に拡張されることが可能である。これらの実施形態および例は、ＣＱＩ、ＰＭＩ、およびＲＩのビットタイプのうちの任意の１つまたは複数をＵＥによってサポートされ、そして定期的に、または非定期的に報告され得る他のタイプのＵＣＩビットと置換するように簡単に拡張されることも可能である。
【００１７】
ＬＴＥリリース８においては、ＵＣＩは、２つのやり方のうちの一方で、例えば、ＵＥ１０１によって送信されることが可能である。サブフレームの中に、割り当てられたＰＵＳＣＨ（Physical UL Shared Channel）リソースのない場合に、ＵＥ１０１は、ＰＵＣＣＨ（Physical UL Control Channel）リソースを使用してＵＣＩを送信することができる。ＵＬデータが、存在し、またはＵＥが、その他の方法でＰＵＳＣＨの上でデータを送信しているときに、ＵＣＩシグナリングは、ＰＵＳＣＨの上で起こることができ、そしてＰＵＳＣＨの上のデータと多重化されることが可能である。しかしながら、リリース８においては、ＰＵＣＣＨとＰＵＳＣＨとの同時伝送は、サポートされない。さらに、ＵＥによるＡＣＫ／ＮＡＣＫとＣＱＩとの同時伝送は、ＵＥ特有のより高いレイヤのシグナリングによって可能にされないこともある。この場合には、ＣＱＩは、脱落（drop）され、そしてＡＣＫ／ＮＡＣＫだけが、ＰＵＣＣＨを使用して送信され、これは、スケジューリングおよびレート適合化の精度における何らかの悪化をもたらす可能性がある。
【００１８】
３ＧＰＰリリース１０（Ｒ１０）に導入されたＬＴＥ−進化型（ＬＴＥ−Ａ）においては、例えばＵＥ１０１によるＰＵＳＣＨとＰＵＣＣＨとの同時伝送が、サポートされることが可能であり、そしてＵＬ波形に対する単一キャリア制約条件が、緩和される。リリース１０においては、各ＵＬコンポーネントキャリアに対する周波数連続リソースと周波数非連続リソースとの両方の割付けが、サポートされる。
【００１９】
ＬＴＥ−Ａにおいては、ＵＣＩサイズ（ＵＣＩビットの数）は、ＣＯＭＰ(coordinated multipoint）伝送、より高次のＤＬ  ＭＩＭＯ、帯域幅拡張、およびリレーを含めて、新しい特徴を考慮に入れて、ＬＴＥに比べて、増大されることになることが期待される。例えば、高次のＭＩＭＯ（例えば、８×８のＭＩＭＯ）および／またはＣＯＭＰをサポートするために、大量のチャネルステータス報告（ＣＱＩ／ＰＭＩ／ＲＩ）が、サービングｅＮｏｄｅＢ（およびもしかするとＣＯＭＰ実装における隣接するｅＮｏｄｅＢ（単数または複数））に対してフィードバックされることが可能である。ＵＣＩオーバーヘッドは、非対称帯域幅拡張の使用によってさらに増大されることになる。したがって、リリース８のＬＴＥ  ＰＵＣＣＨのペイロードサイズは、ＬＴＥ−Ａにおいて（単一ＤＬコンポーネントキャリアの場合でさえも）増大されたＵＣＩオーバーヘッドを搬送するのに十分でないこともある。ＬＴＥ−ＡにおけるＵＣＩシグナリングは、ＬＴＥにおけるＵＣＩシグナリングよりも柔軟とすることができ、ＬＴＥ−ＡにおけるＵＣＩシグナリングにおけるより多くの構成を可能にする。これに起因して、そしてＵＣＩサイズ（ＵＣＩビットの数）が、ＬＴＥ−Ａにおいてより大きいこともあるので、増大されたＵＣＩサイズをサポートする新しい構成が必要とされる可能性がある。本開示のいくつかの実施形態においては、ＰＵＳＣＨとＰＵＣＣＨとの同時伝送の能力は、ＬＴＥ−Ａシステム、または他の任意のシステムにおいて生成され得るＵＣＩシグナリングを送信するために利用される。
【００２０】
さらに、ＰＵＳＣＨとＰＵＣＣＨとについてのパワー設定は、それぞれ独立に行われるので、ＰＵＳＣＨとＰＵＣＣＨとのパワーレベルの合計が、与えられた最大送信パワーに到達し、またはそれを超過する状況の場合に、サブフレームにおいてＰＵＣＣＨとＰＵＳＣＨとの同時伝送をうまく利用する実施形態について、ＬＴＥ−Ａ  ＵＣＩシグナリングについてのいくつかのルールが、本明細書において説明される。
【００２１】
本明細書において使用されるように、ＰＵＣＣＨは、ＬＴＥまたはＬＴＥ−ＡのＰＵＣＣＨとすることができ、このＰＵＣＣＨは、アップリンク制御情報を搬送するアップリンクチャネルであることに注意すべきである。あるいは、本明細書において使用されるようなＰＵＣＣＨは、アップリンクについての制御情報を送信するために排他的に、または非排他的に使用されることが可能な任意の１つもしくは複数のチャネル、または他の無線通信手段とすることもできる。本明細書において使用されるように、ＰＵＳＣＨは、ＬＴＥまたはＬＴＥ−ＡのＰＵＳＣＨとすることができ、このＰＵＳＣＨは、ユーザデータ（すなわち、ＳＣＨデータ）を搬送するアップリンクチャネルである。あるいは、本明細書において使用されるようなＰＵＳＣＨは、アップリンクの上でユーザデータを送信するために排他的に、または非排他的に使用されることが可能な任意の１つもしくは複数のチャネル、または他の無線通信手段とすることもできる。本明細書において使用されるようなＰＵＳＣＨは、制御情報を搬送することもできる。本明細書において使用されるようなアップリンク制御情報（ＵＣＩ）は、特定のＬＴＥまたはＬＴＥ−Ａの制御情報とすることができ、またはＵＣＩは、任意のタイプのチャネルまたは無線通信手段の上で搬送される、任意の無線システムにおいて使用される任意の制御情報とすることができる。すべてのそのような実施形態は、本開示の範囲内にあるものと考えられる。
【００２２】
図２は、ＬＴＥシステムまたはＬＴＥ−Ａシステムの一部、または全部として構成されていることが可能な無線通信システム／アクセスネットワーク２００を示すものである。ネットワーク２００は、Ｅ−ＵＴＲＡＮ（Evolved-Universal Terrestrial Radio Access Network）２５０を含むことができる。Ｅ−ＵＴＲＡＮ２５０は、図１のＵＥ１０１を含めて、任意のタイプのＵＥまたはＷＴＲＵとすることができるＵＥ２１０と、図１のｅＮｏｄｅＢ１７０などのｅＮｏｄｅＢの機能を実行するように構成された任意のデバイスとすることができる１つまたは複数のｅＮｏｄｅＢ２２０ａ、２２０ｂ、および２２０ｃとを含むことができる。図２に示されるように、ＵＥ２１０は、ｅＮｏｄｅＢ２２０ａと通信することができる。ｅＮｏｄｅＢ２２０ａ、２２０ｂ、および２２０ｃは、Ｘ２インターフェースを使用して互いにインターフェースすることができる。ｅＮｏｄｅＢ２２０ａ、２２０ｂ、および２２０ｃは、Ｓ１インターフェースを通してＭＭＥ／Ｓ−ＧＷ２３０ａおよび／または２３０ｂに接続されることも可能である。ＭＭＥ／Ｓ−ＧＷ２３０ａおよび２３０ｂは、図１のＭＭＥ／Ｓ−ＧＷ１８０などのＭＭＥ／Ｓ−ＧＷの機能を実行するように構成された任意のデバイスとすることができる。単一のＵＥ２１０と３つのｅＮｏｄｅＢ２２０ａ、２２０ｂ、および２２０ｃが、図２に示されているが、任意の数の無線デバイスと有線デバイスとそれらの組合せが、ネットワーク２００に含まれ得ることが企図される。
【００２３】
ＬＴＥ−Ａシステムにおいて実装されるいくつかの実施形態においては、ＵＥからｅＮｏｄｅＢへとＵＬ制御情報（ＵＣＩ）を送信することが望ましいこともあり、それはＵＬユーザデータ伝送および他のＵＬ伝送、ＤＬユーザデータ伝送および他のＤＬ伝送、スケジューリングデータ、ＭＩＭＯデータなどをサポートするためである。ＵＣＩは、それだけには限定されないが、ＨＡＲＱ  ＡＣＫ／ＮＡＣＫ（単数または複数）、チャネルステータス報告、ＣＱＩ／ＰＭＩ／ＲＩ、および／またはＳＲ（スケジューリングリクエスト（単数または複数））を含むことができる。本明細書において使用されるような「ユーザデータ」という用語は、「ＳＣＨ（shared channel、共用チャネル）データ」と交換可能とすることができることに注意すべきである。ＵＥは、ＰＵＣＣＨまたはＰＵＳＣＨの上でＵＣＩを送信することができる。表１は、いくつかの実施形態で使用され得るＬＴＥについて定義されたＰＵＣＣＨフォーマットと、対応するＵＣＩの内容とを示すものである。フォーマット２ａおよび２ｂは、通常の巡回プレフィックスだけについてサポートされる。いくつかの実施形態においては、ＰＵＳＣＨの上でＵＣＩを送信するときに、同じフォーマットが使用されることが可能である。
【００２４】
【表１】
2014209806.tif 000003
【００２５】
ＵＣＩを報告するためにＵＥによって使用され得る時間リソースと周波数リソースとは、ｅＮｏｄｅＢによって制御されることが可能である。ＣＱＩ、ＰＭＩ、およびＲＩの報告などの何らかのＵＣＩは、定期的または非定期的とすることができる。いくつかの実施形態においては、非定期的報告は、定期的報告によって提供されるデータと類似したデータ、ならびに追加のデータを提供することができる。そのような実施形態においては、定期的報告と非定期的報告との両方が、同じサブフレームにおいて起こることになる場合、ＵＥは、そのサブフレームにおいて非定期的報告を送信するだけのように構成されていることが可能である。
【００２６】
各ＰＵＣＣＨ報告モードのＣＱＩおよびＰＭＩのペイロードサイズは、あらかじめ決定され、例えば、３ＧＰＰ規格仕様によって提供されることが可能である。各ＰＵＣＣＨ報告モードの他のＵＣＩタイプのペイロードサイズは、あらかじめ決定され、例えば、３ＧＰＰ規格仕様によって提供されることが可能である。
【００２７】
ＬＴＥ−Ａシステムにおいて起こり得るアップリンク制御情報（ＵＣＩ）の増大されたＵＣＩサイズとより高いボリュームとを取り扱うために、本開示によって導入されるいくつかの実施形態が、使用されることが可能である。本明細書に開示される実施形態のいくつかは、ＬＴＥ−ＡのＰＵＳＣＨとＰＵＣＣＨとの同時伝送能力をうまく利用する。
【００２８】
一実施形態においては、ＬＴＥ−ＡシステムにおいてＵＥからＵＣＩをシグナリングするための代替的構成が、ＬＴＥ  ＵＣＩシグナリング方法に加えて使用されることが可能である。第１のそのような実施形態においては、複数のＰＵＣＣＨ伝送が、複数のＵＣＩのフィールドまたは報告のために使用されることが可能である。複数のＵＣＩフィールド／報告を多重化するための複数のＰＵＣＣＨ伝送（またはリソース）は、複数のＰＵＣＣＨ伝送が、符号多重化、または周波数多重化のいずれかであるように実装されることが可能である。例えば、ＬＴＥにおいては、チャネル品質インジケータ（ＣＱＩ）の伝送が、同じサブフレームにおいてスケジューリングリクエスト（ＳＲ）伝送と衝突するときに、ＣＱＩは、脱落（drop）される。しかしながら、ＬＴＥ−Ａにおいては、符号分割多重（ＣＤＭ）（すなわち、セル特有のシーケンスの異なる直交位相回転を使用したもの）、または周波数分割多重（ＦＤＭ）（すなわち、異なるリソースブロック（ＲＢ）を使用したもの）を使用して、同じサブフレームの中で同時に送信されるＣＱＩとＳＲとを有することが可能である。したがって、ＵＥは、ＰＵＣＣＨフォーマット１（もしかすると１ａ／１ｂを有する）と、フォーマット２（もしかすると２ａ／２ｂを有する）とを多重化してそれらを複数のＰＵＣＣＨリソース上で同時に送信することができる。あるいは、複数のＰＵＣＣＨ伝送は、ＵＥから高ボリュームのＬＴＥ−Ａ  ＵＣＩを送信するようにも考えられ得る。
【００２９】
複数のＰＵＣＣＨリソース上でのＵＣＩシグナリングを実装する実施形態においては、ＣＤＭ、ＦＤＭ、もしくは時分割多重（ＴＤＭ）、またはそれらの任意の組合せを使用して、ＵＣＩをシグナリングすることができる。一実施形態においては、高ボリュームＵＣＩが必要とされるときに、ＵＣＩは、ＣＤＭ（すなわち、セル特有のシーケンスの異なる位相回転）を使用して複数のＰＵＣＣＨリソース上でＵＥから送信されることが可能である。そのような実施形態においては、セル特有の長さ−１２の周波数ドメイン（またはタイムドメイン）シーケンスの異なる直交位相回転（等価的な巡回シフト）が、ＵＣＩの各ビット（または１グループのビット、または異なる制御フィールド）について適用されることが可能である。例えば、非対称帯域幅拡張（２つのＤＬコンポーネントキャリアと１つのＵＬコンポーネントキャリアとなど）の場合には、異なるＤＬコンポーネントキャリアについてのＨＡＲＱ  ＡＣＫ／ＮＡＣＫビットが、セル特有のシーケンスの異なる位相回転を使用して単一のＵＬキャリアにおいて送信されることが可能である。あるいは、または追加して、図３に示されるように、異なるＤＬキャリアについてのＡＣＫ／ＮＡＣＫビット（ＡＣＫ／ＮＡＣＫビット３１０および３２０）が、同じ位相回転シーケンスを使用して、ただしキャリア−１およびキャリア−２についてそれぞれ異なる直交カバーシーケンス（orthogonal cover sequence）ｗ1およびｗ2を使用して、（同じ時間−周波数リソースの上で）送信されることが可能である。
【００３０】
ｅＮｏｄｅＢは、レイヤ１もしくは２（Ｌ１／２）のシグナリング、またはより高いレイヤのシグナリングにより、サブフレームにおいて複数のＵＣＩフィールド／報告を多重化するようにＵＥを構成することができる。複数のＰＵＣＣＨ伝送を使用する実施形態においては、複数のＰＵＣＣＨの総送信パワーが、Ｐｍａｘ（またはＰｍａｘ＋Ｐ＿しきい値、ここでＰ＿しきい値は、しきい値である）として示されるＵＥの最大送信パワーを超過する場合、そのときにはＵＥは、ＬＴＥ  ＵＥプロシージャに対して（すなわち、ＣＱＩ／ＰＭＩなどの低優先順位フィードバック報告を脱落（drop）させることによって）ピギーバックする（piggyback）ことができる。
【００３１】
ｅＮｏｄｅＢは、複数のＰＵＣＣＨ伝送についてのブラインド検出（blind detection）を使用して、どのＰＵＣＣＨ伝送（ＵＣＩフィールド）が、サブフレームにおいて適用されるかを決定することができる。あるいは、その全体が参照によって本明細書によって組み込まれている「APPARATUS AND METHOD FOR UPLINK POWER CONTROL FOR A WIRELESS TRANSMITTER/RECEIVER UNIT UTILIZING MULTIPLE CARRIERS」という名称の2010年2月9日に出願された米国特許出願第12/703,092号明細書に開示されたパワー低減／バックオフアプローチのいくつかが、何らかの修正を有するいくつかの実施形態において使用されることが可能である。例えば、各ＰＵＣＣＨについてパワーレベルを計算した後に、パワーの合計が、Ｐｍａｘを超過する場合、そのときにはそれぞれの送信パワーは、最大パワー制限に準拠するように同等パワーまたは相対的パワーを用いて（個別のチャネルの優先順位に応じて）調整されることが可能である。複数のＰＵＣＣＨについてのパワー設定のための別のオプションは、個別のＰＵＣＣＨについてのパワーオフセットを導入することなど、ＬＴＥ  ＰＵＣＣＨパワー制御を修正することである。最大許容ＣＣ送信パワー（単数または複数）を超過することは、これらの決定のために、Ｐｍａｘを超過することの代わりに、またはＰｍａｘを超過することに追加して、考慮されることが可能である。
【００３２】
代替的実施形態においては、複数のＰＵＣＣＨリソース上のＵＣＩシグナリングが、ＦＤＭを使用して実装されることが可能である。そのような実施形態においては、ＵＣＩの各ビット（あるいはＡＣＫ／ＮＡＣＫビットおよびＣＱＩビットのような１グループのビット、または異なる制御フィールド）は、あらかじめ構成されたＰＵＣＣＨ領域内の異なるＲＢペア（すなわち、ＰＵＣＣＨリソース）を使用して送信されることが可能である。図４は、ＡＣＫ／ＮＡＣＫが、ｍ＝０に対応するＲＢ４２０上で送信されるが、同じサブフレームにおいて、ＣＱＩ／ＰＭＩ／ＲＩが、ｍ＝２に対応するＲＢ４３０など、異なるＲＢ上で送信されるように、ＰＵＣＣＨ領域４１０において複数のＰＵＣＣＨ  ＲＢリソース（ＦＤＭベースの）を使用して高ボリュームＵＣＩ（例えば、複数のＵＣＩ報告）を送信する一例を示すものである。あるいは、または追加して、非対称帯域幅拡張（２つのＤＬコンポーネントキャリアと１つのＵＬコンポーネントキャリアとなど）の場合には、異なるＤＬコンポーネントキャリアについてのＵＣＩビット（単数または複数）は、キャリア−１およびキャリア−２についてそれぞれｍ＝０，２など、異なるＲＢペア上で送信されることが可能である。
【００３３】
別の実施形態においては、複数のＰＵＣＣＨリソース上のＵＣＩシグナリングが、ＴＤＭを使用して実装されることが可能である。そのような実施形態においては、ＵＣＩの各ビット（あるいはＡＣＫ／ＮＡＣＫビットおよびＣＱＩビットのような１グループのビット、または異なる制御フィールド）は、ＯＦＤＭシンボルに基づいて、スロットに基づいて、またはサブフレームに基づいて時分割ベース（ＴＤＢ）で送信されることが可能である。
【００３４】
複数のＰＵＣＣＨリソースの実施形態上の上記ＵＣＩシグナリングにおいては、ＵＥは、どのＰＵＣＣＨリソース（時間／周波数／符号）がＵＥに対して割り付けられるかに関して、より高いレイヤのシグナリング（またはＬ１シグナリング）を通して、ｅＮｏｄｅＢによって構成され得ることに注意すべきである。これらの実施形態においては、Ｒ８  ＬＴＥ  ＰＵＣＣＨフォーマットは、３ＧＰＰ規格仕様において指定されるように保持されることが可能であり、すなわちＲ８  ＬＴＥに対する後方互換性を保持している。さらに、ＣＤＭ（およびＦＤＭ）の場合には、ＣＭ（cubic metric、キュービックメトリック）は、使用中のリソース（符号／位相回転、またはＲＢ）の数に応じて増大させられることが可能である。したがって、ＰＵＣＣＨについてのパワー設定に対するＣＭの影響が、考慮に入れられることが可能であり、すなわち、もしあれば、ＣＭの増大の量によるパワーバックオフを適用する。
【００３５】
別の実施形態においては、同じサブフレームの中のＰＵＣＣＨとＰＵＳＣＨとの両方の上でのＵＣＩシグナリング（ＵＥから、ＰＵＳＣＨとＰＵＣＣＨ（単数または複数）との両方の上でＵＣＩ、例えば、高ボリュームＵＣＩを送信する）が、例えば、非対称キャリアアグリゲーションのより高次のＤＬ  ＭＩＭＯ、および／またはＣＯＭＰが、使用中であるときに、実装されることが可能である。同じサブフレームにおいてＰＵＣＣＨ（単数または複数）とＰＵＳＣＨとの両方の上でＵＣＩをシグナリング（ＵＣＩについてのＰＵＣＣＨとＰＵＳＣＨとの同時伝送）するために、ＡＣＫ／ＮＡＣＫおよび／またはＳＲは、ＡＣＫ／ＮＡＣＫおよび／またはＳＲが、ＰＵＣＣＨの上で送信され得るが、同じサブフレームにおいて（定期的な、または非定期的な）ＣＱＩ／ＰＭＩ／ＲＩシグナリングが、ＰＵＳＣＨ上で実行され得るように（または逆もまた同様である）、ＣＱＩ／ＰＭＩ／ＲＩと多重化されることが可能である。いくつかの実施形態においては、送信すべきユーザデータのないＵＥは、ＵＬデータなしにＰＵＳＣＨの上でＵＣＩを送信するように構成されていることが可能である。例えば、ＤＬ  ＣＯＭＰにおけるＵＥは、サービングセルのために意図されたＰＵＳＣＨ上のサービング（アンカー）セルに関連するＵＣＩ（ＡＣＫ／ＮＡＣＫ、ＣＱＩ／ＰＭＩ／ＲＩ、およびＳＲを含む）を送信することができるが、同じサブフレームにおいて、ＵＥは、その受信側セル（単数または複数）についてのあらかじめ指定されたＰＵＣＣＨ（単数または複数）上の非サービング（アンカー）セルを対象とする他の制御情報（例えば、ＣＱＩ／ＰＭＩ）を送信することができ、または逆もまた同様である。
【００３６】
図５は、ＤＬ  ＣＯＭＰにおいて、ＵＥからＰＵＣＣＨ（単数または複数）とＰＵＳＣＨとの両方の上でＵＣＩを送信する一例を示すものである。この例においては、ＵＥは、サブフレームにおいて送信されるＵＬ共用チャネル（ＵＬ−ＳＣＨ）データを有することが仮定される。ＵＥが、そのときに送信されるべきどのようなデータも有していない場合、ＵＣＩは、ＵＬデータなしにＰＵＳＣＨの上で送信される。あるいは、または追加して、非対称ＣＡ（例えば、１つのＵＬキャリアと、Ｎ個のＤＬキャリアとがあり、ここでＮ＞１）の場合、ＵＥは、ＰＵＳＣＨまたはＰＵＣＣＨ（単数または複数）のいずれかの上でＤＬアンカーキャリアに関連するＵＣＩを送信することもできる。同時に、ＵＥは、他の物理チャネル（例えば、ＤＬアンカーキャリアのために使用されていない）の上でＤＬ非アンカーキャリア（単数または複数）についてのＵＣＩを送信することができる。あるいは、ＵＥは、異なるＵＬコンポーネントキャリア（ＣＣ）の上でＰＵＳＣＨ上のＤＬ非アンカーキャリア（単数または複数）についてのＵＣＩを送信することもできる。
【００３７】
ＬＴＥ−Ａシステムの実施形態においては、ＰＵＳＣＨとＰＵＣＣＨとについてのパワー設定は、それぞれ、独立して行われることが可能である。同じサブフレームにおいてＰＵＳＣＨとＰＵＣＣＨ（単数または複数）との両方の上でＵＣＩを送信する場合に、Ｐｍａｘが、到達されるとき（すなわち、負のパワーヘッドルーム（negative power headroom）の場合）には、最大パワー制限に準拠するために、同等パワー低減、相対的パワー低減、チャネル（および／またはＵＣＩタイプ）に基づいた優先順位を使用したパワー低減など、本明細書において参照される米国特許出願第12/703,092号に説明されるアプローチを含めて、パワーバックオフアプローチがある。あるいは、または追加して、Ｐｍａｘが到達されることを検出する、ＰＵＳＣＨとＰＵＣＣＨとの両方を使用してＵＣＩを送信するＵＥは、本明細書に開示されるような複数のＰＵＣＣＨリソースを使用してＵＣＩを送信する方法に切り替わることができる。別の代替案においては、そのようなＵＥは、ＰＵＳＣＨだけを使用してＵＣＩを送信することができる。あるいは、ＵＥは、ＰＵＣＣＨだけを使用して、もしかすると、もしあれば、ＣＱＩ／ＰＭＩのような低優先順位のＵＣＩフィールドを脱落（drop）させて、ＵＣＩを送信することができる。最大許容ＣＣ送信パワー（単数または複数）を超過することは、Ｐｍａｘを超過することの代わりに、またはＰｍａｘを超過することに追加して、これらの決定のために考慮されることが可能である。
【００３８】
別の実施形態においては、ＵＣＩについての定期的なＰＵＣＣＨと非定期的なＰＵＳＣＨとの同時伝送が、実装されることが可能である。レガシーＬＴＥ（Ｒ８）システムにおいては、定期的なＣＱＩ／ＰＭＩ／ＲＩ報告と非定期的なＣＱＩ／ＰＭＩ／ＲＩとの間の衝突の場合には、定期的なＣＱＩ／ＰＭＩ／ＲＩ報告が、そのサブフレームにおいて脱落（drop）される。しかしながら、ＵＥは、必要な場合、同じサブフレームにおいて非定期的報告と定期的報告との両方を送信するように構成されていることが可能である。例えば、非対称ＣＡにおいて、ＵＥは、ＰＵＣＣＨを使用してＤＬアンカーキャリアに関連する定期的なＣＱＩ／ＰＭＩ／ＲＩ報告を実行するように、そして同じサブフレームにおいて、ＰＵＳＣＨを使用してＤＬ非アンカーキャリア（単数または複数）に関連する非定期的ＣＱＩ／ＰＭＩ／ＲＩ報告を実行するように構成されていることが可能であり、または逆もまた同様である。Ｐｍａｘが、到達されるとき（すなわち、負のパワーヘッドルームの場合）に、ＵＥは、ＰＵＳＣＨの上の非定期的ＣＱＩ／ＰＭＩ／ＲＩ報告を脱落（drop）させることができる。あるいは、ＵＥは、ＰＵＣＣＨの上の定期的ＣＱＩ／ＰＭＩ／ＲＩ報告を脱落（drop）させることができる。最大許容ＣＣ送信パワー（単数または複数）を超過することは、Ｐｍａｘを超過することの代わりに、またはＰｍａｘを超過することに追加して、これらの決定のために考慮されることが可能である。
【００３９】
別の実施形態においては、高ボリュームＵＣＩは、ＰＵＳＣＨの上で送信されることが可能である。ＵＣＩペイロードサイズが、あまりにも大きすぎる（ＨＡＲＱ  ＡＣＫ／ＮＡＣＫビットの数と、ＣＱＩ／ＰＭＩ／ＲＩについてのペイロードビットの数との合計が、しきい値よりも大きいなど）ので、それが、ＰＵＣＣＨリソースに適合することができないときに、ＵＣＩは、ＵＥがＰＵＳＣＨの上のデータ伝送についてスケジューリングされているときのＰＵＳＣＨの上のＬＴＥ  ＵＣＩシグナリングと同様に、ＵＬ−ＳＣＨデータを用いて、またはＵＬ−ＳＣＨデータなしで（ＵＥがデータ伝送についてスケジューリングされているか否かに応じて）ＰＵＳＣＨの上で送信されることが可能である。本実施形態においては、ＵＥが、ＵＣＩを搬送するためにＰＵＳＣＨの上のデータ伝送のためにスケジューリングされることが必要でない可能性がある。もっと正確に言えば、ＵＥは、ＵＣＩがＰＵＳＣＨの上で搬送されるべきときにより高いレイヤのシグナリングまたはＬ１／２シグナリングによって構成されていることが可能である。
【００４０】
ｅＮｏｄｅＢは、例えば、ＵＥの能力、ＤＬ／ＵＬ構成／サービス、チャネル状態、ＰＵＳＣＨ／ＰＵＣＣＨのリソース使用可能性、および／またはＵＥ送信パワーの使用可能性に応じて、ＰＵＣＣＨとＰＵＳＣＨとの両方の上でＵＣＩを送信するようにＵＥを構成し、またはＰＵＣＣＨとＰＵＳＣＨとの両方の上でＵＣＩを送信しないようにＵＥを構成することができる。構成は、Ｌ１／２シグナリングまたはより高いレイヤのシグナリングを通してＵＥに対して与えられることが可能である。同じサブフレームにおけるＰＵＣＣＨ（単数または複数）とＰＵＳＣＨとの両方の上でＵＣＩを送信する場合には、ＰＵＣＣＨとＰＵＳＣＨとについてのパワーレベルをそれぞれ計算した後に、パワーの合計が、Ｐｍａｘを超過する場合、それぞれのチャネル送信パワーが、最大パワー制限に準拠するために同等パワーもしくは相対的パワー（個別のチャネルの優先順位に応じて）、またはあらかじめ定義されたオフセットを用いて調整され／低減されることが可能であるような、(本明細書において参照される米国特許出願第12/703,092号明細書に説明されるものを含む)パワーバックオフアプローチを使用することができる。さらに別の代替案においては、ＵＥは、もしかするとＣＱＩ／ＰＭＩのような低優先順位のＵＣＩフィールドを脱落（drop）させてＰＵＣＣＨの上だけでＵＣＩを送信することができる。さらに別の実施形態においては、ＵＥは、ＵＥがデータ伝送についてスケジューリングされているか否かに応じてアップリンク共用チャネル（ＵＬ−ＳＣＨ）データを用いて、またはアップリンク共用チャネル（ＵＬ−ＳＣＨ）データなしでＰＵＳＣＨの上だけですべての必要とされるＵＣＩフィールドを送信することができる。これらの実施形態のうちのどれかで、ｅＮｏｄｅＢは、個別の物理チャネル（すなわち、ＰＵＣＣＨとＰＵＳＣＨと）についてのブラインド検出を使用して、どの物理チャネル（単数または複数）（またはＵＣＩフィールド）が、サブフレームにおいて送信されるかを決定することができる。最大許容ＣＣ送信パワー（単数または複数）を超過することは、Ｐｍａｘを超過することの代わりに、またはＰｍａｘを超過することに追加して、これらの決定のために考慮されることが可能である。
【００４１】
代替的実施形態においては、レガシーＬＴＥ  ＵＣＩシグナリングは、ＬＴＥに似たＤＬ／ＵＬ構成（ワンツーワンＤＬ／ＵＬスペクトルマッピングや無ＣＯＭＰなど）を用いてＵＥによって実行されることが可能である。ＵＣＩオーバーヘッドは、ＬＴＥ  Ｒ８と類似したものにすることができる。しかしながら、ＬＴＥ  Ｒ８とは違って、ＵＥは、同じサブフレームにおいてＰＵＳＣＨの上で非定期的ＣＱＩ／ＰＭＩ／ＲＩを送信しながら、ＰＵＣＣＨの上で（一実施形態において、ＡＣＫ／ＮＡＣＫの信頼性を改善するために）ＨＡＲＱ  ＡＣＫ／ＮＡＣＫを送信することができる。
【００４２】
別の代替案においては、より高次の変調（１６ＱＡＭ）を有する新しいＰＵＣＣＨフォーマットを使用して、より大きなＵＣＩサイズをサポートすることができる。これらの新しいＰＵＣＣＨフォーマットは、より高次の変調を使用して定義されることが可能である。表２に示されるように、新しいＰＵＣＣＨフォーマットは、１６ＱＡＭ（フォーマット３、４／４ａ／４ｂ／４ｃ）を使用して導入される。ＰＤＣＣＨフォーマット３は、４ビットのＡＣＫ／ＮＡＣＫ（もしかするとＳＲを伴う）を搬送するために使用されることが可能である。例えば、４ビットのＡＣＫ／ＮＡＣＫは、キャリアアグリゲーション（例えば、ＳＭ  ＭＩＭＯを有する２つのＤＬキャリアと、１つのＵＬキャリアと）の中で使用されることが可能である。ＰＵＣＣＨフォーマット４／４ａ／４ｂ／４ｃが使用されて、ＬＴＥ−ＡにおいてＣＱＩ／ＰＭＩ／ＲＩビットの４０個の符号化ビット（４ａ／４ｂ／４ｃにおいてＡＣＫ／ＮＡＣＫを伴う）をフィードバックすることができる。本明細書に開示される新しいフォーマットでは、ＰＵＣＣＨについてのパワー設定は、より高次の変調、１６ＱＡＭの使用を受け入れる（すなわち、異なるＳＩＮＲが、異なる変調スキームについて必要とされることを反映する）パワーオフセットを含むことができる。
【００４３】
【表２】
2014209806.tif 000004
【００４４】
ＬＴＥ−Ａ  ＵＣＩシグナリングを使用して上記に説明される実施形態のすべてにおいては、ｅＮｏｄｅＢは、Ｌ１／２シグナリングまたはより高いレイヤのシグナリングによってＵＣＩを送信するようにＵＥを構成することができる。
【００４５】
代替的実施形態においては、ＰＵＣＣＨとＳＲＳとの同時伝送は、ＳＲＳシンボルロケーション（最後のＯＦＤＭシンボル）におけるＰＵＣＣＨ（単数または複数）（およびＰＵＳＣＨ）とＳＲＳとの同時伝送をサポートするＬＴＥ−Ａシステムにおいて使用されることが可能である。そのような実施形態においては、ＵＥは、ＳＲＳを、たとえＳＲＳとＰＵＣＣＨのフォーマット１／１ａ／１ｂ（通常のＰＵＣＣＨフォーマット１／１ａ／１ｂを含む）および／または２／２ａ／２ｂ（およびもしかすると本明細書において説明されるようなフォーマット３／４／４ａ／４ｂ／４ｃ）とでも、送信することができ、そしてその伝送は、ＬＴＥ−Ａシステムにおいてそのような伝送を簡略化する同じサブフレームにおいて起こる。
【００４６】
別の実施形態においては、ＵＣＩシグナリングは、ＵＬ  ＭＩＭＯを実装するＬＴＥ−Ａシステムにおいて実行されることが可能である。ＰＵＳＣＨについてのいくつかのＭＩＭＯモードは、ＳＭ（spatial multiplexing、空間多重）ＭＩＭＯ（開ループや閉ループのＳＭ  ＭＩＭＯなど）と、ビーム形成（ＢＦ）と、送信ダイバーシティ（ＣＤＤ（cyclic delay diversity、巡回遅延ダイバーシティ）、ＳＴＢＣ（space-time block coding、空間−時間ブロックコーディング）、ＳＦＢＣ（space-frequency block coding、空間−周波数ブロックコーディング）、ＳＯＲＴＤ（spatial-orthogonal resource transmit diversity、空間的−直交リソース送信ダイバーシティ）など）とを含めて、使用されることが可能である。本開示に応じて構成されたＬＴＥ−Ａシステムは、ＵＣＩシグナリングについての以下のＭＩＭＯモードのうちのどれでも使用することができる。ＰＵＣＣＨの上のＵＣＩ伝送では、以下のＭＩＭＯオプションのうちのどれかが実装されることが可能である。
【００４７】
−１つのレイヤを有するビーム形成（この場合には、ｅＮｏｄｅＢは、ＵＥについてのコードブックまたはＰＭＩフィードバックを提供する）。
−ＣＤＤ伝送（ｔｘ）ダイバーシティ。
−ＳＴＢＣ／ＳＦＢＣ／ＳＯＲＴＤ。
−アンテナスイッチング（この場合には、アンテナスイッチングは、ＯＦＤＭシンボルに基づいて、またはスロットに基づいて行われることが可能である）。
−ＵＬ  ＭＩＭＯにおけるＰＵＳＣＨとＰＵＣＣＨとの同時伝送が、実装され、ここでＵＣＩが、ＰＵＣＣＨの上で送信されるときに、上記のＭＩＭＯオプションのうちの任意の１つが、ＰＵＳＣＨについてのＭＩＭＯモードに関係なくＰＵＣＣＨについて使用されることが可能である。
【００４８】
ＰＵＳＣＨの上のＵＣＩ伝送では、一実施形態において、ＰＵＳＣＨにおけるＵＣＩ部についてのＵＬ  ＭＩＭＯスキームは、データ部についてのＵＬ  ＭＩＭＯと独立に適用されることが可能であり、ここでＵＣＩ部についてのＭＩＭＯスキームは、以下のうちの任意の１つとすることができる。
【００４９】
−１つのレイヤを有するビーム形成。
−ＣＤＤ  ｔｘダイバーシティ。
−ＳＴＢＣ／ＳＦＢＣ。
−アンテナスイッチング（この場合には、アンテナスイッチングは、ＯＦＤＭシンボルに基づいて、またはスロットに基づいて行われることが可能である）。
−アンテナ選択。
−ＰＵＳＣＨのデータ部と同じＭＩＭＯモードが、ＵＣＩ部について適用されることが可能である。
【００５０】
別の実施形態においては、ＵＥは、ＰＵＳＣＨの上だけですべてのＵＣＩビットを送信することができ、ここでは大きなＵＣＩサイズが、ＬＴＥ−Ａ  ＵＣＩ伝送について使用されることが可能である。
【００５１】
同時ＰＵＣＣＨ／ＰＵＳＣＨ  ＵＣＩ伝送のより詳細な実施形態を提供する方法およびシステムが、次に説明される。ＵＥが、もしあれば、ＵＣＩビットのうちのどれをＰＵＣＣＨの上で送信すべきかと、もしあれば、どれをＰＵＳＣＨの上で送信すべきかとを決定することを可能にする方法およびシステムが、提供される。ＰＵＳＣＨの上で送信すべきユーザデータを有するＵＥでは、ＰＵＳＣＨの上で送信されるＵＣＩは、データと一緒に送信されることが可能である。ユーザデータのないＰＵＳＣＨ伝送では、ＵＣＩだけが、ＰＵＳＣＨの上で送信されることが可能である。以下の実施形態においては、ＵＣＩビットは、アクティブな（または構成された）ダウンリンクコンポーネントキャリア（ＤＬ  ＣＣ）のすべてについて与えられたサブフレームについてＵＣＩを含むことができる。スケジューリング、ｅＮｏｄｅＢ要求、ＤＬ伝送など、様々なファクタに基づいて、与えられたＤＬ  ＣＣについてのＵＣＩビットは、１つまたは複数のＡＣＫ／ＮＡＣＫビット（実際のビット、またはたとえ送信されないとしてもＡＣＫ／ＮＡＣＫのために予約されたビット）と、ＣＱＩビットと、ＰＭＩビットと、ＲＩビットと、他のタイプのフィードバックビット（長期（アウターループ（outerloop）とも呼ばれる）ＰＭＩや短期（インナーループ（innerloop）とも呼ばれる）ＰＭＩなど）と、ＵＥが無線ネットワークに対して送信することができる他の任意の制御ビットとを含むことができる。異なるＤＬ  ＣＣは、与えられたサブフレームの中に送信されるべき異なるＵＣＩビットタイプを有することができる。任意の１つまたは複数のＤＬ  ＣＣは、与えられたサブフレームの中で送信されるべきＵＣＩビットを有さない可能性がある。ＵＣＩビットは、ＤＬ  ＣＣに特に関連していない制御ビットのタイプを含むこともできる。
【００５２】
ＣＱＩ報告とＰＭＩ報告とは、一般的に一緒に報告され、そして本明細書においてはＣＱＩ／ＰＭＩ報告と称されることに注意すべきである。しかしながら、そのような報告は、別々に報告されることも可能であり、本明細書における実施形態は、そのような実施形態へと簡単に拡張されることが可能である。本明細書において説明される方法および実施形態のおのおのに対する変形として、複数のＰＵＣＣＨが、与えられたサブフレームに割り付けられ、そしてＵＣＩを搬送することが許可される場合に、ＰＵＣＣＨは、複数のＰＵＣＣＨを意味するように拡張されることが可能である。
【００５３】
一実施形態においては、どのようにしてＵＣＩが、サブフレーム内で送信すべきＵＣＩビットの数（これは、ＵＣＩペイロードサイズとも称され得る）に基づいて送信されるべきかについての決定が行われることが可能である。図６は、そのような実施形態を実装する方法を示すものである。ブロック６１０において、送信されるべきＵＣＩビットの数についての決定が行われる。一実施形態においては、この決定は、任意の非定期的ＣＱＩ／ＰＭＩ／ＲＩ報告ビットと、任意の他の非定期的報告ビットとを除外することができる。他の実施形態は、そのような非定期的報告ビットを含むことができる。
【００５４】
ブロック６２０において、ＵＣＩビットの数が何らかの数Ｎ以下であるかどうかについての決定が行われることが可能である。Ｎは、ＵＥの上であらかじめ構成されてもよく、またはｅＮｏｄｅＢによってＵＥに対して信号伝達されてもよい。Ｎの値は、各ＰＵＣＣＨフォーマットについてＮの異なる値が存在することができるように、ＰＵＣＣＨフォーマットの関数とすることができる。ＵＣＩビットの数が、Ｎ以下である場合、ＵＥは、ブロック６３０においてＰＵＣＣＨの上ですべてのＵＣＩビットを送信する準備をすることができる。ＵＣＩビットの数が、Ｎよりも大きい場合、ＵＥは、ブロック６４０においてＰＵＣＣＨの上のＵＣＩビットのサブセットと、ＰＵＳＣＨの上のＵＣＩビットの残りとを送信する準備をすることができる。例えば、ＵＥは、ＰＵＣＣＨの上のＡＣＫ／ＮＡＣＫビットと、ＰＵＳＣＨの上の残りのＵＣＩビット（ＣＱＩ、ＰＭＩ、ＲＩなど）とを送信する準備をすることができる。あるいは、ブロック６５０において、ＵＣＩビットの数が、Ｎ’よりも大きいかどうかについての決定が行われることも可能であり、ここでＮ’＞Ｎである。Ｎ’は、ＵＥの上であらかじめ構成されてもよく、またはｅＮｏｄｅＢによってＵＥに対して信号伝達されてもよい。Ｎ’の値は、各ＰＵＣＣＨフォーマットについてＮ’の異なる値が存在することができるように、ＰＵＣＣＨフォーマットの関数とすることができる。この実施形態においては、ＵＣＩビットの数が、Ｎ’よりも大きい場合、そのときにはブロック６６０において、ＵＥは、ＰＵＳＣＨの上ではすべてのＵＣＩビットを送信するように、そしてＰＵＣＣＨの上では何も送信しないように準備することができる。ＵＣＩビットの数がＮよりも大きいが、Ｎ’以下である場合、ＵＥは、ブロック６４０において、ＰＵＣＣＨの上のＵＣＩビットのサブセットと、ＰＵＳＣＨの上のＵＣＩビットの残りとを送信する準備をすることができる。別の代替案においては、ＵＣＩビットの数が、ブロック６２０においてＮよりも大きいと決定される場合、そのときにはＵＥは、ブロック６６０においてＰＵＳＣＨの上ではすべてのＵＣＩビットを送信するように、そしてＰＵＣＣＨの上では何も送信しないように準備することができる。
【００５５】
行われる必要があるかもしれない他の変更または決定がなければ、そのようなＵＣＩビットは、さらなる調整なしに送信され得ることに注意すべきである。本開示の全体を通して、ＵＥは、ＵＣＩビットの伝送の前に、追加の調整の可能性を可能とするようにそのようなビットを単に送信するのでなくて、ＵＣＩビットを「送信する準備をする」ように説明されることが可能である。例えば、ＵＥは、ＰＵＣＣＨとＰＵＳＣＨとの両方を使用してＵＣＩビットを送信する準備をすることができるが、パワーしきい値が、（以下でより詳細に説明されるように）そのような伝送によって到達されることになることを後になって決定することができ、そしてそれ故にＰＵＣＣＨとＰＵＳＣＨとのうちの一方だけを使用してＵＣＩビットを実際に送信することができる。
【００５６】
代替的実施形態においては、ＵＥは、ＵＣＩペイロードが、割り付けられたＰＵＣＣＨの上に適合するかどうかを決定して、どのようにしてＵＥがＵＣＩを送信することになるかを決定することができる。図７は、そのような一実施形態を実装する方法を示すものである。ブロック７１０において、送信されるべきＵＣＩビットの数（ＵＣＩペイロードのサイズとも称される）についての決定が行われる。一実施形態においては、この決定は、任意の非定期的ＣＱＩ／ＰＭＩ／ＲＩ報告ビットと、任意の他の非定期的報告ビットとを除外することができる。他の実施形態は、そのような非定期的報告ビットを含むことができる。
【００５７】
ブロック７２０において、ＵＣＩビットのすべてが、割り付けられたＰＵＣＣＨに適合することになるかどうかについての決定が行われる。ＵＣＩビットのすべてが、割り付けられたＰＵＣＣＨに適合することになる場合、ブロック７３０において、ＵＥは、ＰＵＣＣＨの上ではすべてのＵＣＩビットを送信するように、そしてＰＵＳＣＨの上では何も送信しないように準備することができる。ＵＣＩビットの数がＰＵＣＣＨに適合しない場合、ブロック７４０において、ＵＥは、ＰＵＣＣＨの上のビットのサブセットと、ＰＵＳＣＨの上の残りとを送信する準備をすることができる。例えば、ＵＥは、ＰＵＣＣＨの上のＡＣＫ／ＮＡＣＫビットと、ＰＵＳＣＨの上の残りのＵＣＩビット（ＣＱＩビット、ＰＭＩビット、ＲＩビットなど）とを送信する準備をすることができる。別の例として、ＵＥは、すべてのＤＬ  ＣＣについてのＡＣＫ／ＮＡＣＫビットと、ＰＵＣＣＨに適合することになる同じ数のＤＬ  ＣＣについてのすべての非ＡＣＫ／ＮＡＣＫビット（ＣＱＩビット、ＰＭＩビット、ＲＩビットなど）と、ＰＵＳＣＨの上の他のＤＬ  ＣＣについての非ＡＣＫ／ＮＡＣＫビット（ＣＱＩビット、ＰＭＩビット、ＲＩビットなど）とを送信する準備をすることができる。ＵＣＩビットが、割り付けられたＰＵＣＣＨに適合することになるかどうかを決定するときに、ＵＥは、そのＰＵＣＣＨについてのすべての許容されたＰＵＣＣＨフォーマットを考慮することができる。
【００５８】
別の実施形態においては、ＵＥは、ＵＣＩペイロードサイズを１つもしくは複数のデータペイロードサイズまたはＰＵＳＣＨサイズ（これは、ＰＵＳＣＨ搬送容量と呼ばれることもある）と比較して、どのようにしてＵＥがＵＣＩを送信することになるかを決定することができる。ＰＵＳＣＨサイズは、ＲＢの数、ＯＦＤＭシンボルの数、物理的符号化ビットの数などの１つまたは複数のファクタ、またはこれらもしくは他のファクタの何らかの組合せを使用して測定されることが可能である。図８は、そのような実施形態を実装する方法を示すものである。ブロック８１０において、送信されるべきＵＣＩのペイロードサイズ（ビットの数）についての決定が行われる。一実施形態においては、この決定は、任意の非定期的ＣＱＩ／ＰＭＩ／ＲＩ報告ビットと、任意の他の非定期的報告ビットとを除外することができる。他の実施形態は、そのような非定期的報告ビットを含むことができる。
【００５９】
ブロック８２０において、ＵＥは、ＵＣＩペイロードサイズと、１つまたは複数のデータペイロードサイズとＰＵＳＣＨサイズとの間の関係を決定することができる。例えば、ＵＥは、しきい値Ｎと、ＰＵＳＣＨサイズに対するＵＣＩペイロードの相対的サイズ（例えば、パーセンテージ）、またはデータペイロードに対するＵＣＩペイロードの相対的サイズ（例えば、パーセンテージ）とを比較して、どのようにしてＵＣＩを送信すべきかを決定することができる。Ｎは、ＵＥの上であらかじめ構成されてもよく、またはｅＮｏｄｅＢによってＵＥに対して信号伝達されてもよい。例えば、ＰＵＳＣＨサイズについてのＵＣＩペイロードサイズのパーセンテージ、またはデータペイロードサイズについてのＵＣＩペイロードサイズのパーセンテージが、しきい値Ｎよりも小さい場合、ＵＥは、ブロック８３０においてＰＵＳＣＨの上のすべてのＵＣＩを送信する準備をすることができる。ＰＵＳＣＨサイズについてのＵＣＩペイロードサイズのパーセンテージ、またはデータペイロードサイズについてのＵＣＩペイロードサイズのパーセンテージが、しきい値Ｎ以上である場合、ＵＥは、ブロック８４０において、ＰＵＣＣＨの上のいくつかのＵＣＩビットと、ＰＵＳＣＨの上の他のＵＣＩビットとを送信する準備をすることができ、またはブロック８５０において、ＰＵＣＣＨの上のすべてのＵＣＩビットを送信する準備をすることができる。
【００６０】
代替的実施形態においては、ＵＥは、ＰＵＳＣＨサイズをしきい値と比較して、どのようにしてＵＥがＵＣＩを送信することになるかを決定することができる。ＰＵＳＣＨサイズは、ＲＢの数、ＯＦＤＭシンボルの数、物理的符号化ビットの数などの１つまたは複数のファクタ、またはこれらまたは他のファクタの何らかの組合せを使用して測定されることが可能である。この決定は、ＵＣＩペイロードサイズとは独立であるので、ブロック８１０は、スキップされてもよい。ブロック８２０において、ＰＵＳＣＨのサイズは、しきい値Ｎと比較されることが可能である。Ｎは、ＵＥの上であらかじめ構成されてもよく、またはｅＮｏｄｅＢによってＵＥに対して信号伝達されてもよい。ＰＵＳＣＨの搬送容量が、与えられたしきい値Ｎよりも大きい場合、そのときにはＵＥは、ブロック８３０において、ＰＵＳＣＨの上のすべてのＵＣＩを送信する準備をすることができる。大きなＰＵＳＣＨの場合には、ＰＵＳＣＨの上のデータとＵＣＩとを組み合わせるための性能ペナルティは、低減されることが可能であり、それでこの場合においてＰＵＳＣＨの上のＵＣＩのすべてを送信することと、最大パワー低減（ＭＰＲ）効果に起因した同時のＰＵＳＣＨ−ＰＵＣＣＨの可能性のあるパワー制限を回避することとが、望ましい可能性がある。ＰＵＳＣＨの容量が、Ｎ以下である場合、ＵＥは、ブロック８４０においてＰＵＣＣＨの上のいくつかのＵＣＩビットと、ＰＵＳＣＨの上の他のＵＣＩビットとを送信する準備をすることができる。あるいは、ＵＥは、ブロック８５０において、ＰＵＣＣＨの上ですべてのＵＣＩビットを送信する準備をすることができる。
【００６１】
他の実施形態においては、ＵＥが、ＰＵＳＣＨを割り付けられ、そして送信すべきユーザデータを持たない場合、ＵＥは、ＵＣＩペイロードサイズに応じて、ＰＵＳＣＨまたはＰＵＣＣＨとＰＵＳＣＨとの組合せの上でＵＣＩを送信する準備をすることができる。図９は、そのような実施形態を実装する方法を示すものである。ブロック９１０において、ユーザデータが伝送のために使用可能でないという決定が、行われる。ブロック９２０において、送信されるべきＵＣＩビットの数についての決定が行われる。ブロック９３０において、すべてのＵＣＩビットがＰＵＳＣＨに適合することになるかどうかについての決定が、行われる。そうである場合、ブロック９４０において、ＵＥは、ＰＵＳＣＨの上ですべてのＵＣＩを送信する準備をすることができる。ＵＣＩビットの数が、ＰＵＳＣＨに適合しない場合、ブロック９５０において、ＵＥは、ＡＣＫ／ＮＡＣＫビットなど、ＰＵＣＣＨの上のＵＣＩのサブセットと、ＰＵＳＣＨの上のＵＣＩビットの残りとを送信する準備をすることができる。あるいは、ＵＣＩビットの数が、ＰＵＳＣＨに適合しないときには、ブロック９５０において、ＵＥは、ＰＵＣＣＨの上ですべてのＵＣＩビットを送信する準備をすることができる。ＰＵＣＣＨの搬送容量が、ＰＵＳＣＨの搬送容量よりも大きい場合に、これは可能性があるにすぎないことに注意すべきである。これらの実施形態においては、ＵＥが送信すべきデータを持たないときに、ＰＵＳＣＨの上でＵＣＩを送信することは、ＰＵＳＣＨの上の性能に影響を与えないので、ＰＵＳＣＨは、ＵＣＩビットが適合することになるときに、ＰＵＣＣＨよりも好ましい可能性がある。
【００６２】
これらの実施形態のうちのどれかの変形として、送信されるべきＵＣＩビットが、非定期的なＣＱＩ／ＰＭＩまたはＲＩの報告に関連するＣＱＩビット、ＰＭＩビット、またはＲＩビットを含む場合、ＵＥは、送信されるべきＵＣＩビットの数を決定するときに、および／またはどのビットがＰＵＣＣＨの上を進むことができるかを決定するときに、そのようなビットを除外することができる。そのような実施形態においては、ＵＥは、ＰＵＳＣＨの上の非定期的なＣＱＩ／ＰＭＩおよびＲＩの報告に関連するＣＱＩビット、ＰＭＩビット、およびＲＩビットを常に送信することになる。そのような実施形態は、非定期的報告が、定期的報告よりもずっと大きく、そしてＰＵＣＣＨに適合しそうにないときに、望ましい可能性がある。追加の非定期的報告タイプが、Ｒ１０について、または将来において定義される場合、ＵＥは、このようにして、これらの報告についてのビットを同様に除外するように、そしてＰＵＳＣＨの上で常にこれらのビットを送信するように構成されていることが可能である。
【００６３】
例えば、任意の非定期的なＣＱＩ／ＰＭＩおよびＲＩの報告ビットを除外したＵＣＩビットの数が、ある数Ｎ以下であり、またはあるいはＰＵＣＣＨの搬送容量以下である場合、そのときにはＵＥは、任意の非定期的なＣＱＩ／ＰＭＩおよびＲＩの報告ビットを除いてＰＵＣＣＨの上ですべてのＵＣＩビットを送信する準備をすることができ、そしてＰＵＳＣＨの上の非定期的なＣＱＩ／ＰＭＩおよびＲＩの報告ビットを送信する準備をすることができる。任意の非定期的なＣＱＩ／ＰＭＩおよびＲＩの報告ビットを除外したＵＣＩビットの数が、Ｎよりも大きく、またはあるいはＰＵＣＣＨの搬送容量よりも大きい場合、そのときにはＵＥは、ＰＵＣＣＨの上のビットのサブセットと、ＰＵＳＣＨの上の残りとを送信する準備をすることができる。例えば、一実施形態においては、ＵＥは、ＰＵＣＣＨの上のＡＣＫ／ＮＡＣＫビットと、ＰＵＳＣＨの上のすべてのＣＱＩビット、ＰＭＩビット、およびＲＩビット（定期的報告と非定期的報告とについての）とを送信する準備をすることができる。あるいは、任意の非定期的なＣＱＩ／ＰＭＩおよびＲＩの報告ビットを除外したＵＣＩビットの数が、Ｎ’よりも大きい（ここでＮ’＞Ｎ）場合、そのときにはＵＥは、ＰＵＳＣＨの上ではすべてのＵＣＩビットを送信するように、そしてＰＵＣＣＨの上では何も送信しないように準備することができる。別の代替案においては、任意の非定期的なＣＱＩ／ＰＭＩおよびＲＩの報告ビットを除外したＵＣＩビットの数が、Ｎよりも大きい場合、そのときにはＵＥは、ＰＵＳＣＨの上ではＵＣＩビットのすべてを送信するように、そしてＰＵＣＣＨの上では何も送信しないように準備することができる。ＮおよびＮ’は、おのおの、ＵＥの上であらかじめ構成されてもよく、またはｅＮｏｄｅＢによってＵＥに対して信号伝達されてもよい。ＮおよびＮ’の値は、おのおの、各ＰＵＣＣＨフォーマットについて異なる値のＮおよび／またはＮ’が存在することができるように、ＰＵＣＣＨフォーマットの関数とすることができる。
【００６４】
本明細書に開示される実施形態のどれかでは、ＰＵＣＣＨの搬送容量を決定するときに、ＵＥは、割り付けられたＰＵＣＣＨについてのすべての許容されたＰＵＣＣＨフォーマットを考慮することができることに注意すべきである。実施形態のおのおのにおいては、スケジューリングが、同じタイプの定期的なＵＣＩ報告と非定期的なＵＣＩ報告とが、与えられたＤＬ  ＣＣについて同時に送信されることになるようである場合、ＵＥは、ＵＣＩペイロードサイズの伝送から、そしてＵＣＩペイロードサイズの決定から、そのＣＣについてのそのタイプの定期的報告を省略することができる。
【００６５】
他の実施形態においては、ＵＥは、どのようにしてＵＥが、送信することが必要なＵＣＩビットのタイプに基づいてＵＣＩを送信することになるかを決定することができ、そしてそのような決定は、ＵＣＩタイプの優先順位に基づいたものとすることができる。図１０に示される、そのような一実施形態においては、ＵＣＩの中のビットのタイプが、ブロック１０１０において決定されることが可能である。ブロック１０２０において、送信されるべきＵＣＩビットのうちのどれかが、ＡＣＫ／ＮＡＣＫビットであるかどうかについての決定が行われることが可能である。送信されるべきＵＣＩビットが、ＡＣＫ／ＮＡＣＫビットを含む場合、ＵＥは、ブロック１０３０において、ＰＵＣＣＨの上のＡＣＫ／ＮＡＣＫビットと、ＰＵＳＣＨの上のすべての他のタイプのＵＣＩビットとを送信する準備をすることができる。ＡＣＫ／ＮＡＣＫビットは、最も重要なビットである可能性があるので、それらは、よりよい性能のために、ＰＵＳＣＨの上よりもＰＵＣＣＨの上で送信される可能性がある。
【００６６】
あるいは、図１１に示されるように、ＵＥは、どのタイプのＵＣＩビットが、ＰＵＣＣＨフォーマットのおのおのの中でＰＵＣＣＨに整合するかを知るように、そしてその知識に基づいてどのようにしてＵＣＩを送信すべきかを決定するように構成されていることが可能である。ブロック１１１０において、送信されるべきＵＣＩにおけるビットのタイプが、ＵＥによって決定されることが可能である。ブロック１１２０において、ＵＥは、一実施形態においてＰＵＣＣＨの上で送信されることになる高優先順位ビットの数が、最大にされるように、整合する最高優先順位タイプの組合せを選択することができる。ブロック１１３０において、ＵＥは、適切なＰＵＣＣＨフォーマットを使用してＰＵＣＣＨに整合する最高優先順位タイプの組合せを送信する準備をすることができる。多数の実施形態においては、ＡＣＫ／ＮＡＣＫは、最高優先順位を有し、ＲＩ（または同等物）は、第２の最高優先順位を有し、そしてＣＱＩ／ＰＭＩ（または同等物）は、優先順位において続いていることに注意すべきである。ＵＥは、ＰＵＳＣＨの上ですべての他のタイプのＵＣＩを送信することができる。
【００６７】
さらなる実施形態においては、ＵＥは、例えば、マルチアンテナ技法の使用など、いくつかのアクティブな（または構成された）ＤＬ  ＣＣおよび／またはＤＬ伝送モードを含めて、ダウンリンク（ＤＬ）構成に基づいてどのようにしてＵＥがＵＣＩビットを送信することになるかを決定することができる。そのような一実施形態においては、ＵＥが、ＤＬ  ＣＣの数が１であり、そしてＤＬ伝送モードがＲ８においてサポートされる伝送モードであることを決定する場合、ＵＥは、ＰＵＳＣＨの上ではＵＣＩのすべてを送信するように、そしてＰＵＣＣＨの上では何も送信しないように準備することができる。ＤＬ構成を使用した代替的実施形態が、図１２に示されている。ブロック１２１０において、ＤＬ  ＣＣの数が、１であるかどうか、そしてＤＬ伝送モードが、Ｒ８−ＬＴＥにおいてサポートされる伝送モードであるかどうかについての決定が行われることが可能である。そうでない場合、例えば、ＤＬ  ＣＣの数が、１よりも大きい場合、ＵＥは、ブロック１２１５においてＰＵＣＣＨの上の（集約された）ＵＣＩビットのサブセットと、ＰＵＳＣＨの上のＵＣＩビットの残りとを送信する準備をすることができる。ＵＥは、本明細書において説明される他の方法と実施形態とに従って、ＰＵＣＣＨの上でどのビットを送信すべきかと、ＰＵＳＣＨの上でどのビットを送信すべきかとを決定することができる。
【００６８】
ただ１つのＤＬ  ＣＣが存在し、そしてＤＬ伝送モードが、Ｒ８−ＬＴＥにおいてサポートされる伝送モードである場合、ブロック１２２０において、ＵＣＩが、ＡＣＫ／ＮＡＣＫビットを含むかどうかについての決定が行われることが可能である。そうである場合、ブロック１２３０において、ＵＥは、ＰＵＣＣＨの上でＡＣＫ／ＮＡＣＫビットを送信する準備をすることができる。ブロック１２４０において、ＵＣＩの中に定期的なＣＱＩ／ＰＭＩビットと定期的なＲＩビットとが存在するかどうかについての決定が行われることが可能である。そうである場合、ＵＥは、ブロック１２５０においてＰＵＣＣＨの上の定期的なＲＩビットと、ＰＵＳＣＨの上の定期的なＣＱＩ／ＰＭＩビットとを送信する準備をすることができる。ブロック１２６０において、定期的なＣＱＩ／ＰＭＩビットが存在し、そして定期的なＲＩビットが存在していないかどうかについての決定が行われることが可能である。そうである場合、ＵＥは、ブロック１２７０においてＰＵＣＣＨの上で定期的なＣＱＩ／ＰＭＩビットを送信する準備をすることができる。ブロック１２８０において、定期的なＲＩビットが存在し、そして定期的なＣＱＩ／ＰＭＩビットが存在していないかどうかについての決定が行われることが可能である。そうである場合、ＵＥは、ブロック１２９０においてＰＵＣＣＨの上で定期的なＲＩビットを送信する準備をすることができる。ＵＥが、非定期的なＵＣＩ報告ビットが存在することを決定する場合、ＵＥは、ＰＵＳＣＨの上でこれらを送信する準備をする。
【００６９】
いくつかの実施形態においては、ＵＥは、送信アンテナポートの数などのＵＬ伝送モード、および／または連続的なＰＵＳＣＨ  ＲＢ割付けに対する非連続的なＰＵＳＣＨ  ＲＢ割付けを含めたＰＵＳＣＨ構成に基づいて、どのようにしてＵＥがＵＣＩを送信することになるかを決定することができる。そのような一実施形態においては、ＵＥが、サブフレームにおいて複数のアンテナポートを用いてＰＵＳＣＨ（２つのコードワードを搬送する）を送信するように構成されている場合、そのときにはＵＥは、ＰＵＳＣＨの上のＣＱＩ／ＰＭＩビットと、ＰＵＣＣＨの上のＵＣＩビットの残り（例えば、ＡＣＫ／ＮＡＣＫビットおよび／またはＲＩビット）とを送信する準備をすることができる。あるいは、ＵＥは、ＰＵＳＣＨの上ではＵＣＩビットのすべてを送信するように、そしてＰＵＣＣＨの上では何も送信しないように準備することもできる。
【００７０】
他の実施形態においては、非連続的なＰＵＳＣＨ  ＲＢ割付けの許可がＵＥに対して与えられる場合、そのときにはＵＥは、ＰＵＳＣＨの上ではＵＣＩのすべてを送信するように、そしてＰＵＣＣＨの上では何も送信しないように準備することができる。そうでない場合（すなわち、連続的なＰＵＳＣＨ  ＲＢ割付けの場合）には、ＵＥは、本明細書に開示される１つまたは複数の方法を使用してＵＣＩビットを送信する準備をすることができる。
【００７１】
いくつかの実施形態においては、同じサブフレームにおいてＤＬ  ＣＣについて同じタイプの定期的ＵＣＩ報告と、非定期的ＵＣＩ報告との両方が要求されている（または伝送のためにスケジューリングされている）可能性がある。この場合には、ＵＥは、ＰＵＳＣＨの上でそのＣＣについての非定期的ＵＣＩ報告ビットを送信する（または送信する準備をする）ことができ、そしてＵＥは、そのＣＣについてのそのタイプについての定期的報告を脱落させる（送信しない）ことができる。図１３は、そのような一実施形態を実装する一方法を示すものである。ブロック１３１０において、同じサブフレームにおいてＤＬ  ＣＣについて同じタイプの定期的報告と非定期的報告との両方が要求されている（または伝送のためにスケジューリングされている）という決定が行われることが可能である。ブロック１３２０において、ＵＥは、そのＣＣについてそのタイプについての定期的報告を脱落させる（送信しない）ことができる。ブロック１３３０において、本明細書に開示される１つまたは複数の方法を使用したいくつかの実施形態において、残りのＵＣＩの内容が送信され、または伝送のために準備されることが可能である。
【００７２】
いくつかの実施形態においては、同じサブフレームにおいて異なるＤＬ  ＣＣについて定期的ＵＣＩ報告と、非定期的ＵＣＩ報告との両方が要求されている可能性がある。例えば、１つのＤＬ  ＣＣについて定期的ＵＣＩ報告が要求されている可能性があるが、別のＤＬ  ＣＣについて非定期的ＵＣＩ報告が要求されている可能性がある。この場合には、ＵＥは、ＰＵＣＣＨの上の定期的ＵＣＩ報告ビットと、ＰＵＳＣＨの上の非定期的ＵＣＩ報告ビットとを送信する（または送信する準備をする）ことができ、または逆もまた同様である。
【００７３】
他の実施形態においては、ＵＥは、ＤＬ  ＣＣ優先順位を使用して、どのようにしてＵＥがＵＣＩを送信することになるかを決定することができ、ここで主要なＤＬ  ＣＣは、最高の優先順位を有する。図１４は、そのような一実施形態を実装する一方法を示すものである。ブロック１４１０において、ＵＥは、ＵＣＩビットのうちのどれかが、主要なＤＬ  ＣＣについてのものであるかどうかを決定することができる。そうでない場合、ブロック１４２０において、ＵＥは、ＰＵＳＣＨの上でＵＣＩのすべてを送信する準備をすることができる。主要なＤＬ  ＣＣについてのものであるＵＣＩのビットが存在する場合、そのときにはブロック１４３０において、主要なＤＬ  ＣＣに関連するビットが、ＰＵＣＣＨの上のＵＥによる伝送のために準備されることが可能であるが、ＵＣＩの残りのビットは、同じサブフレームにおいてＰＵＳＣＨの上の伝送のために準備されることが可能である。例えば、ＵＣＩが、与えられたサブフレームにおいて送信されるべき複数の定期的ＣＱＩ／ＰＭＩ報告から成り、そしてそれらの報告のうちの１つが主要なＤＬ  ＣＣについてのものである場合、そのときにはブロック１４３０において、ＵＥは、ＰＵＣＣＨの上の主要なＤＬ  ＣＣについてのＣＱＩ／ＰＭＩ報告と、ＰＵＳＣＨの上の他の報告とを送信する準備をすることができる。報告のどれもが主要なＤＬ  ＣＣについてのものでない場合、ＵＥは、ブロック１４２０においてＰＵＳＣＨの上ですべての報告を送信する準備をすることができる。
【００７４】
ブロック１４１０において、主要なＤＬ  ＣＣについて送信されるべきビットが存在しないことが決定される場合、ブロック１４２０においてＰＵＳＣＨの上ですべてのＵＣＩビットを送信する代わりに、ＵＥは、ブロック１４４０において、ＰＵＣＣＨの上の、次の最高優先順位のＤＬ  ＣＣについてのＵＣＩビット（例えば、構成順序、ＤＬ  ＣＣのインデックスまたはＩＤ、あるいはＵＥおよび／またはｅＮｏｄｅＢに知られている他の任意の手段によって決定されるような）と、ＰＵＳＣＨの上の他のＤＬ  ＣＣについてのＵＣＩとを送信する準備をすることができることに注意すべきである。例えば、ＵＣＩが、与えられたサブフレームにおいて送信されるべき複数の定期的ＣＱＩ／ＰＭＩ報告から成り、そして報告のどれもが、主要なＤＬ  ＣＣについてのものでない場合、そのときにはＵＥは、ＰＵＣＣＨの上の、次の最高優先順位のＤＬ  ＣＣについてのＣＱＩ／ＰＭＩ報告と、ＰＵＳＣＨの上の他の報告とを送信する準備をすることができる。この次の優先順位のＤＬ  ＣＣについてのオプションと代替案とは、主要なＤＬ  ＣＣについて本明細書において説明されるようなものである。
【００７５】
あるいは、ＵＥが、割り付けられたＰＵＣＣＨについての許容されたＰＵＣＣＨフォーマットを使用するときに、ＵＣＩタイプのある種の組合せだけがＰＵＣＣＨに適合することになることを知るように構成されている場合、そのときにはＵＥは、ブロック１４３０において、ＰＵＣＣＨの上の主要なＤＬ  ＣＣについての最高優先順位のＵＣＩタイプの組合せ（例えば、定期的なＲＩが送信されるべき場合のＡＣＫ／ＮＡＣＫおよび定期的ＲＩ、そうでない場合のＡＣＫ／ＮＡＣＫおよび定期的ＣＱＩ／ＰＭＩ）と、ＰＵＳＣＨの上の主要なＤＬ  ＣＣについての他のＵＣＩタイプとを送信する準備をすることができる。あるいは、ＵＥは、主要なＤＬ  ＣＣについての他のＵＣＩタイプについてのビットを脱落（drop）させることもできる。主要なＤＬ  ＣＣについてのＵＣＩビットが存在しない場合、同じ原理は、ブロック１４４０においてＵＣＩが存在するための最高優先順位のＤＬ  ＣＣに対して適用されることが可能である。
【００７６】
別の代替案においては、与えられたサブフレームにおいて送信されるべきＵＣＩが、主要なＤＬ  ＣＣについてのＡＣＫ／ＮＡＣＫおよび定期的ＣＱＩ／ＰＭＩ報告を含む場合、そのときにはＵＥは、ブロック１４３０においてＰＵＣＣＨの上の主要なＤＬ  ＣＣについてのＡＣＫ／ＮＡＣＫおよび定期的ＣＱＩ／ＰＭＩ報告と、ＰＵＳＣＨの上の他のＵＣＩビットとを送信する準備をすることができる。主要なＤＬ  ＣＣについてのＵＣＩビットが存在しない場合、同じ原理は、ブロック１４４０においてＵＣＩが存在するための最高優先順位のＤＬ  ＣＣに対して適用されることが可能である。
【００７７】
いくつかの実施形態においては、ＵＥは、どのようにしてＵＥが、ＵＣＩについての明示的な許可に基づいて（例えば、定期的ＣＱＩ／ＰＭＩ／ＲＩ報告についての）ＵＣＩビットを送信することになるかを決定することができる。そのような実施形態においては、ｅＮｏｄｅＢは、ＵＥに対してＵＬ許可を明示的に供給して、例えば、新しい、または修正されたＤＣＩフォーマットを経由して、あるいはより高レイヤのシグナリングを経由して、ユーザデータなしにＵＣＩを送信することができる。例えば、ｅＮｏｄｅＢは、それが、ＵＥが送信すべきデータを持たず、そしてスケジューリングされたＵＣＩ報告がＰＵＣＣＨに適合しないことになることを知っているときに、ＵＥに対してＵＬ許可を供給して、ＣＱＩ／ＰＭＩビットやＲＩビットなどについての定期的報告を送信することができる。一実施形態においては、ＵＥが、そのような許可を受信する場合、ＵＥは、その許可に従って、ＰＵＳＣＨの上だけでＵＣＩを送信する準備をすることができる。別の実施形態においては、本明細書において説明される１つまたは複数の他の実施形態に従って、ＵＥはＰＵＣＣＨとＰＵＳＣＨとの間でＵＣＩを分割することができる。
【００７８】
本明細書に開示される方法および実施形態のうちのどれかにおいて、どのようにしてＵＣＩビットが送信されるべきかについてのさらなる決定は、最大パワーしきい値が、満たされているか、または超過されているか、あるいは満たされることになるか、または超過されることになるか否かに基づいて、ＵＥおよび／またはｅＮｏｄｅＢによって行われ得ることに注意すべきである。図１５は、そのような一実施形態を実装する方法を示すものである。ブロック１５１０において、ＵＥは、どのようにしてＵＣＩを送信すべきかについての決定を行うことができる。ＵＣＩを送信する任意の手段または方法は、ブロック１５１０において、例えば、本明細書に開示される他の実施形態のうちのどれかに従って、同じサブフレームにおいてＰＵＣＣＨとＰＵＳＣＨとの間でＵＣＩを分割することを含めて、決定されることが可能である。ブロック１５２０において、ＵＥは、ブロック１５１０において決定される手段を使用してＵＣＩの伝送のために必要とされるパワーを決定することができる。ブロック１５３０において、ＵＥは、伝送のために必要とされるパワーが、最大許容パワーを超過することになるかどうかを決定することができる。最大パワーが超過されないことになる場合、ブロック１５４０において、ＵＣＩビットは、ブロック１５１０において決定された好ましい方法に応じて送信されることになる。最大パワーが超過されることになるかどうかに関する決定は、ＣＣ最大送信パワー（単数または複数）やＵＥ最大送信パワーなど、構成され、またはそれ以外の方法でＵＥに知られている１つまたは複数のパワー制限を含むことができる。
【００７９】
ブロック１５３０において、最大許容パワーが、超過されることになることが決定される場合、ＵＥは、アクションの１つまたは複数の代替的コースを取ることができる。一実施形態においては、ＵＥは、ブロック１５５０において１つまたは複数のＰＵＣＣＨおよびＰＵＳＣＨのパワーをスケールする（scale）ことができる。使用され得るスケールする方法および手段は、それだけには限定されないが、本明細書において参照される米国特許出願第12/703,092号明細書において説明される方法および手段を含んでいることに注意すべきである。
【００８０】
あるいは、ブロック１５３０において、最大許容パワーが、超過されることになることが決定される場合、ＵＥは、ブロック１５６０においてＰＵＳＣＨの上ですべてのＵＣＩを送信することができる。ＰＵＳＣＨの上ですべてのＵＣＩを送信することは、最大許容パワーを低減することができる同時ＰＵＳＣＨ−ＰＵＣＣＨ伝送からもたらされるＭＰＲ効果を取り除く。
【００８１】
別の代替案において、ブロック１５３０においてＵＥが、最大許容パワーが超過されることになることを決定する場合、ブロック１５７０において、ＵＥは、ＰＵＳＣＨの上ですべてのＵＣＩを送信することが、最大許容パワーレベルを超過するかどうかを決定することができる。ＰＵＳＣＨの上ですべてのＵＣＩを送信することが、最大許容パワーレベルを超過しない場合、ＰＵＳＣＨの上ですべてのＵＣＩを送信することは、伝送の前にパワーをスケールするべき必要性を取り除くことになる。ＰＵＳＣＨの上でＵＣＩを送信することが、パワーをスケールするべき必要性を取り除くことになる場合、ＵＥは、ブロック１５６０において、ＰＵＳＣＨの上ですべてのＵＣＩを送信することができる。ＰＵＳＣＨの上ですべてのＵＣＩを送信することが、パワーをスケールする必要性を取り除かないことになる場合、ＵＥは、例えば、同じサブフレームにおいてＰＵＣＣＨとＰＵＳＣＨとを通してＵＣＩを分割して、ＵＣＩ伝送方法に対するその最初の決定を保持し、そしてブロック１５８０においてチャネルの優先順位などに基づいてブロック１５５０について説明されるような任意の方法でＰＵＣＣＨとＰＵＳＣＨとの上のパワーをスケールすることができる。そのような実施形態においては、ＰＵＣＣＨが最高優先順位を有することができるので、ＰＵＣＣＨの上のＵＣＩは、維持されることが可能である。
【００８２】
本明細書に開示される方法および実施形態のどれかでは、ＰＵＣＣＨとＰＵＳＣＨとは、同じＵＬ  ＣＣまたは異なるＵＬ  ＣＣの上で送信され得ることに注意すべきである。これらの方法および実施形態は、両方の場合に適用可能である。異なるＵＬ  ＣＣの上の伝送についての一例は、ＰＵＣＣＨが、主要なＵＬ  ＣＣの上で送信され得るが、ＰＵＳＣＨが、他のＵＬ  ＣＣの上で送信され得るというものである。
【００８３】
いくつかのＬＴＥ−Ａシステムおよび実装において、複数のＰＵＳＣＨが、サブフレームごとに使用され得る。そのような実施形態においては、任意のＵＣＩビットが、ＰＵＣＣＨの上ではなくて、またはＰＵＣＣＨの上に追加してＰＵＳＣＨの上で送信されるべきであることが決定されているときに、ＵＥは、どのＰＵＳＣＨの上でＵＣＩビットを送信すべきかを決定する必要がある可能性がある。そのようなビットは、本明細書において「ＰＵＳＣＨのためのＵＣＩビット」と称される。
【００８４】
図１６の中に示される、そのような一実施形態においては、ＵＥは、ブロック１６１０において複数のＰＵＳＣＨが、使用中であり、または使用可能であるかどうかを先ず決定することができる。そうでない場合、そのときにはブロック１６２０において、ＵＥは、使用可能なＰＵＳＣＨの上で、ＰＵＳＣＨの上の伝送のために意図される任意のＵＣＩビットを送信する準備をすることができる。使用可能な複数のＰＵＳＣＨが存在する場合、ＵＥは、ブロック１６３０において、ＰＵＳＣＨサイズ（搬送容量）に基づいてＵＣＩの伝送のためにＰＵＳＣＨを選択することができる。一実施形態においては、ＵＥは、最大のサイズ（または搬送容量）を有するＰＵＳＣＨの上でＰＵＳＣＨについてのＵＣＩビットを送信する準備をすることができる。ＰＵＳＣＨサイズは、ＲＢの数、ＯＦＤＭシンボルの数、物理的符号化ビットの数などの１つもしくは複数のファクタ、またはこれらもしくは他のファクタの何らかの組合せを使用して測定されることが可能である。あるいは、ブロック１６３０において、ＵＥは、２つ以上のＵＣＩペイロードサイズと、ＰＵＳＣＨデータペイロードサイズおよびＰＵＳＣＨ搬送容量との間の関係に基づいてＰＵＳＣＨを選択することができる。例えば、ＵＥは、総ペイロードサイズに対するＵＣＩペイロードサイズ（例えば、そのパーセンテージ）、またはデータペイロードに対するＵＣＩペイロードサイズ（例えば、そのパーセンテージ）が、最小となるＰＵＳＣＨの上のＰＵＳＣＨについてのＵＣＩビットを送信することができる。これらの実施形態のおのおのは、ＰＵＳＣＨの上のデータを伴うＵＣＩを含むことについての性能の影響を低減させることができる。ブロック１６４０において、ＵＥは、ブロック１６３０において選択されたＰＵＳＣＨの上でＰＵＳＣＨについてのＵＣＩビットを送信する準備をすることができる。
【００８５】
代替的実施形態においては、ブロック１６１０において、複数のＰＵＳＣＨが存在することを決定するとすぐに、ＵＥは、ブロック１６５０においてＰＵＳＣＨを有する主要なＵＬ  ＣＣが存在するかどうかを決定することができる。そうである場合、ＵＥは、ブロック１６６０において主要なＵＬ  ＣＣのＰＵＳＣＨの上でＰＵＳＣＨについてのＵＣＩビットを送信する準備をすることができる。主要なＵＬ  ＣＣは、主要なＤＬ  ＣＣとペアにされているＵＬ  ＣＣとすることができる。主要なＵＬ  ＣＣの上にＰＵＳＣＨが存在しない場合、ＰＵＳＣＨは、ブロック１６３０の手段、または他の任意の手段または方法を使用して選択されることが可能である。代替的実施形態においては、ＵＥは、ＵＥがその上でＡＣＫ／ＮＡＣＫビットを送信すべき、ｅＮｏｄｅＢによって何らかのやり方で構成され、または指定されるＵＬ  ＣＣの上のＰＵＳＣＨとなるように、ＵＣＩビットの伝送のためのＰＵＳＣＨを選択することができる。
【００８６】
いくつかの実施形態においては、ＵＥは、明示的なシグナリング、または非定期的ＵＣＩ報告要求についての許可などの許可に基づいて、伝送のためのＰＵＳＣＨを選択することができる。そのような一実施形態においては、ＵＥは、Ｌ１またはより高いレイヤのシグナリングを経由して、ｅＮｏｄｅＢによって明示的に指定されるＰＵＳＣＨの上でＰＵＳＣＨについてのＵＣＩビットを送信する準備をすることができる。一代替案においては、ｅＮｏｄｅＢが、ＵＣＩ専用のＵＬ許可を提供する場合、ＵＥは、割り付けられたＰＵＳＣＨの上でＰＵＳＣＨについてのＵＣＩを送信する準備をすることができる。別の代替案においては、ＵＥが、非定期的ＵＣＩ要求ビット（または「１」に設定された非定期的要求ビット）を有するＰＤＣＣＨを受信する場合、ＵＥは、ＰＤＣＣＨによってこの要求に関連するＰＵＳＣＨの上でＰＵＳＣＨについてのＵＣＩビットを送信する準備をすることができる。そのようなＵＣＩビットは、ＰＵＳＣＨの上で送信されるべき非定期的ＵＣＩ報告ビットと、すべての他のＵＣＩビットとを含むことができる。
【００８７】
本明細書に開示される実施形態および方法の特徴および要素は、上記では特定の組合せの形で説明されるが、おのおのの特徴または要素は、他の特徴および要素なしに単独で、あるいは他の特徴および要素を有し、または有さない様々な組合せの形で使用されることが可能である。本明細書において提供される方法またはフローチャートは、汎用コンピュータまたはプロセッサによる実行のためのコンピュータ読取り可能ストレージ媒体の形で組み込まれたコンピュータプログラム、ソフトウェア、またはファームウェアの形で実装されることが可能である。コンピュータ読取り可能ストレージ媒体の例は、ＲＯＭ（read only memory）と、ＲＡＭ（random access memory）と、レジスタと、キャッシュメモリと、半導体メモリデバイスと、内部ハードディスクや着脱可能ディスクなどの磁気媒体と、磁気−光媒体と、ＣＤ−ＲＯＭディスクやＤＶＤ（digital versatile disks）などの光媒体とを含む。
【００８８】
適切なプロセッサは、例として、汎用プロセッサ、専用プロセッサ、従来型プロセッサ、ＤＳＰ（digital signal processor）、複数のマイクロプロセッサ、ＤＳＰコアと関連した１つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、ＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field Programmable Gate Array）回路、他の任意のタイプのＩＣ（Integrated Circuit）、および／または状態機械を含む。
【００８９】
ソフトウェアに関連したプロセッサを使用して、無線送信受信ユニット（ＷＴＲＵ）、ユーザ装置（ＵＥ）、端末、基地局、無線ネットワークコントローラ（ＲＮＣ）、または任意のホストコンピュータの中で使用するための無線周波数トランシーバを実装することができる。ＵＥは、カメラ、ビデオカメラモジュール、ビデオ電話、スピーカーフォン、振動デバイス、スピーカー、マイクロフォン、テレビジョントランシーバ、ハンズフリーヘッドセット、キーボード、ブルートゥース（Bluetooth（登録商標））モジュール、ＦＭ（周波数変調）無線ユニット、ＬＣＤ（液晶ディスプレイ）ディスプレイユニット、ＯＬＥＤ（有機発光ダイオード）ディスプレイユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザ、および／または任意のＷＬＡＮ（無線ローカルエリアネットワーク）またはＵＷＢ（Ultra Wide Band）モジュールなど、ハードウェアおよび／またはソフトウェアの形で実装されたモジュールと連動して使用されることが可能である。
【図１】
2014209806.tif 000005
【図２】
2014209806.tif 000006
【図３】
2014209806.tif 000007
【図４】
2014209806.tif 000008
【図５】
2014209806.tif 000009
【図６】
2014209806.tif 000010
【図７】
2014209806.tif 000011
【図８】
2014209806.tif 000012
【図９】
2014209806.tif 000013
【図１０】
2014209806.tif 000014
【図１１】
2014209806.tif 000015
【図１２】
2014209806.tif 000016
【図１３】
2014209806.tif 000017
【図１４】
2014209806.tif 000018
【図１５】
2014209806.tif 000019
【図１６】
2014209806.tif 000020