説明

LTE−Aにおけるアップリンク制御情報のシグナリング

LTE進化型システムにおいてアップリンク制御情報を送信するための方法およびシステムが、開示される。ユーザデバイスは、アップリンク制御情報および/または使用可能なチャネルが、ある種の判断基準を満たすかどうかを決定し、そしてアップリンク制御情報が、その判断基準に基づいて物理的アップリンク制御チャネル、物理的アップリンク共用チャネル、またはそれらの両方の上で送信されるべきかどうかを決定することができる。判断基準は、アップリンク制御情報のサイズ(チャネル上で使用可能な空間またはしきい値に対する絶対的なサイズまたは相対値)と、制御情報ビットのタイプと、使用可能な(すなわち、アクティブな、または構成された)コンポーネントキャリアの数と、複数のチャネルの上でアップリンク制御情報を送信するために必要とされる可能性があるパワーの量とを含むことができる。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は、LTE−Aにおけるアップリンク制御情報のシグナリングに関する。
【0002】
(関連出願の相互参照)
本出願は、それらの全体が、両方共に参照によって本明細書に組み込まれている2009年6月19日に出願された米国仮出願第61/218,782号明細書と、2009年6月24日に出願された米国仮出願第61/220,017号明細書との利益を主張するものである。
【背景技術】
【0003】
より高速なデータレートとスペクトル効率とをサポートするために、3GPP(Third Generation Partnership Project)LTE(Long Term Evolution)システムが、3GPPリリース8(R8)の中に導入されている(LTEリリース8は、本明細書においてLTE R8またはR8−LTEと称されることもある)。LTEにおいては、アップリンク上の伝送は、SC−FDMA(Single Carrier Frequency Division Multiple Access)を使用して実行される。特に、LTEアップリンクにおいて使用されるSC−FDMAは、DFT−S−OFDM(Discrete Fourier Transform Spread Orthogonal Frequency Division Multiplexing)技術に基づいている。以降で使用されるように、用語SC−FDMAとDFT−S−OFDMとは、交換可能に使用される。
【0004】
LTEにおいては、WTRU(wireless transmit/receive unit、無線送信/受信ユニット)(あるいはUE(user equipment、ユーザ装置)とも称される)は、FDMA(Frequency Division Multiple Access)構成において、割り当てられたサブキャリアの限られた隣接するセットだけを使用してアップリンク上で送信する。例えば、アップリンクにおける全体のOFDM(Orthogonal Frequency Division Multiplexing)信号またはシステムの帯域幅が、1から100と番号づけられた有用なサブキャリアからなる場合、第1の与えられたWTRUは、サブキャリア1〜12の上で送信するように割り当てられることが可能になり、第2のWTRUは、サブキャリア13〜24の上で送信するように割り当てられることが可能になる、等のようになる。異なるWTRUは、おのおの、使用可能な伝送帯域幅のサブセットの中だけへ送信することができるが、WTRUをサーブする(serving)eNodeB(evolved Node−B、進化型ノードB)は、全体の伝送帯域幅を通して複合アップリンク信号を受信することができる。
【0005】
LTE進化型(これは、LTEリリース10(R10)と、リリース11など、将来のリリースを含む任意のものとを含んでおり、本明細書においてはLTE−A、LTE R10、またはR10−LTEと称されることもある)は、LTEと3Gネットワークとについての完全に準拠した4Gアップグレード経路を提供するLTE規格の機能強化である。LTEとLTE−Aとの両方においては、ある種の関連するレイヤ1/レイヤ2(L1/2)アップリンク制御情報(uplink control information、UCI)が、UL(アップリンク)伝送、DL(ダウンリンク)伝送、スケジューリング、MIMO(multiple-input multiple-output)などをサポートする必要性が存在する。LTE−Aにおいては、それぞれのアップリンクチャネルについてのパワー設定が、独立に行われることが可能である。当技術分野において必要なことは、アップリンク制御情報を提供し、そして複数のアップリンクチャネルを使用するときに起こり得るパワーの問題に対処するためのシステムおよび方法である。
【発明の概要】
【0006】
LTE進化型システムにおいてアップリンク制御情報(UCI)を送信するための方法およびシステムが、開示される。ユーザ装置デバイス(UE)は、UCIの中のビットの数がUEに対して提供され得るしきい値以下であるかどうかに基づいて、アップリンク制御情報が、PUCCHとPUSCHと(PUCCHの上で送信されるビットとPUSCHの上で送信される残りのビットとのサブセット)を通して送信されるべきかどうかを決定することができる。UCIビットの数が、しきい値以下である場合、UCIビットは、PUCCHの上で送信されることが可能であるのに対して、UCIビットの数がしきい値よりも上にある場合、UCIビットは、同じサブフレームにおいてPUSCHとPUCCHとの両方の上で送信されることが可能である。別の実施形態においては、UCIビットの数は、第2のもっと高いしきい値と比較されることが可能であり、そしてUCIビットの数が、第2のもっと高いしきい値を超過する場合、すべてのUCIビットは、PUSCHの上で送信されることが可能である。別の実施形態においては、すべてのUCIビットがPUCCH上に適合することになる場合、それらは、PUCCHの上で送信されることが可能である。すべてのビットが、PUCCH上に適合しないことになる場合、それらは、同じサブフレームにおいてPUCCHとPUSCHとの両方の上で送信されることが可能である。別の実施形態においては、UCIの相対的サイズ(すなわち、共用チャネル、例えば、PUSCHの容量のサイズと比べたUCIペイロードのサイズ)が、決定されることが可能であり、そして相対的サイズが、しきい値よりも下にある場合、UCIビットは、PUSCHだけの上で送信されることが可能である。
【0007】
別の実施形態においては、UCIビットのタイプが決定されることが可能であり、そしてある種のタイプのビット(例えば、ACK/NACKビット)が存在する場合、ある種のタイプのビットは、PUCCHなど、1つのチャネルの上で送信されることが可能であるが、残りのビットは、PUSCHなど、第2のチャネルの上で送信されることが可能である。あるいは、アクティブであり、またはあるいは、構成されたDL CC(downlink component carriers、ダウンリンクコンポーネントキャリア)の数と、LTEリリース8においてサポートされる伝送モードの使用とが、考慮に入れられることが可能である。DL CCの数が、1ではない、またはLTEリリース8においてサポートされる伝送モードが、使用されない場合、UCIビットのサブセットが、PUCCHの上で送信されることが可能であるが、同じサブフレームにおいて、残りのビットは、PUSCHの上で送信されることが可能である。DL CCの数が、1であり、LTEリリース8においてサポートされる伝送モードが使用される場合、UCIは、内容が、ある種のタイプのUCIビット(例えば、ACK/NACK、CQI/PMI、RI)を含むかどうかを決定するために評価されることが可能であり、そしてどのチャネル(単数または複数)をそのようなビットを送信するために使用すべきかについての決定が行われることが可能である。優先順位または主要なDL CCは、複数のDL CCが使用可能である(アクティブ、あるいは、構成されている)ときに評価されることも可能であり、そして主要な、または最高優先順位のDL CCに関連するUCIビットは、PUCCHの上で送信されることが可能であり、残りのビットは、PUSCHの上で送信されている。
【0008】
複数のチャネルの上でアップリンク制御情報を送信するのに必要とされ得るパワーの量もまた、評価されることが可能である。UEが、PUSCHとPUCCHとの両方を通してUCIビットを送信することが最大パワーしきい値を超過することになることを決定する場合、UEは、PUSCHとPUCCHとのうちの一方だけの上でUCIビットを送信し、あるいはPUSCHおよび/またはPUCCHのパワーをスケールダウンすることができる。複数のPUSCHが使用可能である場合の実施形態においては、様々な手段を使用して、UCIペイロードサイズ、PUSCHデータペイロードサイズ、またはUCIペイロードサイズと使用可能なPUSCHの搬送容量との間の関係に基づいて適切なPUSCHを決定することを含めて、どのPUSCHを使用してUCIビットを送信すべきかを決定することができる。現在の開示のこれらおよび追加の態様は、以下でさらに詳細に述べられている。
【図面の簡単な説明】
【0009】
開示された実施形態の以下の詳細な説明は、添付図面と併せて読まれるときに、よりよく理解される。例証の目的のために、図面の中に例示の実施形態が示されているが、主題は、開示される特定の要素と手段とだけには限定されない。図面には以下がある。
【0010】
【図1】本明細書に開示されるようなアップリンク制御情報のシグナリングのための方法およびシステムが実装され得る非限定的な例示のユーザ装置と、eNodeBと、MME/S−GWとを示す図である。
【図2】本明細書に開示されるようなアップリンク制御情報のシグナリングのための方法およびシステムが実装され得る非限定的な例示のネットワーク環境を示す図である。
【図3】異なるダウンリンクキャリアについてのACK/NACKビットを送信するための非限定的な例示のシステムを示す図である。
【図4】UCI伝送についてのPUCCH領域の中の複数のPUCCH RBリソースを使用するための非限定的な例示の手段を示す図である。
【図5】DL COMP(downlink coordinated multi-point transmission)を利用したシステムにおいてUEからPUCCHとPUSCHとの両方の上でUCIを送信するための非限定的な例示の手段を示す図である。
【図6】どのようにしてUCIをシグナリングするべきかを決定する非限定的な例示の方法を示す図である。
【図7】どのようにしてUCIをシグナリングするべきかを決定する別の非限定的な例示の方法を示す図である。
【図8】どのようにしてUCIをシグナリングするべきかを決定する別の非限定的な例示の方法を示す図である。
【図9】どのようにしてUCIをシグナリングするべきかを決定する別の非限定的な例示の方法を示す図である。
【図10】どのようにしてUCIをシグナリングするべきかを決定する別の非限定的な例示の方法を示す図である。
【図11】どのようにしてUCIをシグナリングするべきかを決定する別の非限定的な例示の方法を示す図である。
【図12】どのようにしてUCIをシグナリングするべきかを決定する別の非限定的な例示の方法を示す図である。
【図13】どのようにしてUCIをシグナリングするべきかを決定する別の非限定的な例示の方法を示す図である。
【図14】どのようにしてUCIをシグナリングするべきかを決定する別の非限定的な例示の方法を示す図である。
【図15】どのようにしてUCIをシグナリングするべきかを決定する別の非限定的な例示の方法を示す図である。
【図16】どのようにしてUCIをシグナリングするべきかを決定する別の非限定的な例示の方法を示す図である。
【発明を実施するための形態】
【0011】
図1は、LTE−Aの本主題と特徴とを実装することができる非限定的な例示のUE101を示すものである。UE101は、1つまたは複数の他のデバイスまたはネットワークと無線で通信することができる、モバイル電話、スマートフォン、PDA(personal data assistant)、ラップトップ、または他の任意のデバイスを含む、任意のタイプのWTRUとすることができる。いくつかの実施形態においては、UE101は、LTE−Aのネットワークまたはシステムと通信するように構成されていることが可能である。UE101は、プロセッサ140を用いて構成されていることが可能であり、プロセッサは、メモリ150と通信するように接続されることが可能であり、そしてバッテリ160などの電源からパワーを引き出すことができ、電源は、UE101の他のコンポーネントのうちのどれかまたはすべてに対してパワーを供給することもできる。プロセッサ140は、本明細書に開示されるようなUCIシグナリングおよび関連した機能、ならびに本明細書に開示された他の任意の機能および/またはUEの中で構成されるプロセッサによって実行され得る他の任意の機能を実行するように構成されていることが可能である。メモリ150は、本明細書において説明される任意の機能、またはUEによって実行され得る他の任意の機能を実行するコンピュータ実行可能命令を含む、データを記憶するように構成されていることが可能である。UE101は、1つまたは複数のアンテナ110a〜dを用いて構成されていることもでき、これらのアンテナは、1つまたは複数のトランシーバ120a〜dから受信されたデータを基地局、eNodeB、または他のネットワークデバイスに対して送信することができ、そしてそのようなデバイスからのデータを1つまたは複数のトランシーバ120a〜dに対して供給することができる。
【0012】
トランシーバ120a〜dおよび/またはアンテナ110a〜dは、アンテナマッピング/プリコーディングモジュール(antenna mapping/precoding module)130に通信するように接続されることが可能である。アンテナマッピング/プリコーディングモジュール130は、プロセッサ140に通信するように接続されることが可能である。図1に示されるコンポーネントのうちのどれかまたはすべては、物理的に同じコンポーネントであっても、または単一の物理ユニットへと組み合わせられてもよく、またはあるいは、物理的に別々のものであってもよいことに注意すべきである。例えば、アンテナマッピング/プリコーディングモジュール130と、プロセッサ140と、トランシーバ120a〜dとは、単一のマイクロチップの上で物理的に構成されていてもよく、またはおのおの個々のマイクロチップの上に構成されていてもよい。そのような構成の任意の変形は、本開示の範囲内にあるものと考えられる。
【0013】
UE101は、eNodeB170と無線で通信するように構成されていることが可能である。典型的なeNodeBにおいて見出され得るコンポーネントに加えて、eNodeB170は、プロセッサ173を含むことができ、このプロセッサは、eNodeB機能および/または本明細書に開示される主題を実行するように構成され得る任意の1つまたは複数のプロセッサとすることができる。プロセッサ173は、メモリ174に通信するように接続されることが可能であり、このメモリは、揮発性メモリおよび不揮発性メモリを含めて任意のタイプのメモリ、またはメモリタイプの組合せとすることができる。eNodeB170は、トランシーバ172a〜dを用いて構成されていることも可能であり、これらのトランシーバは、アンテナ171a〜dに通信するように接続され、例えば、LTEシステムまたはLTE−AシステムにおけるUE101との無線通信を容易にするように構成されていることが可能である。複数の送信および/または受信アンテナは、eNodeB170の上で構成され、それは、そのような複数のアンテナを利用することができるMIMO技術および/または他の技術を容易にするためである。
【0014】
eNodeB170は、1つまたは複数の無線または有線の通信接続を経由してMME/S−GW(Mobility Management Entity/Serving Gateway)180に通信するように接続されることが可能である。MME/S−GW180は、MME/S−GW機能および/または本明細書に開示される主題を実行するように構成され得る任意の1つまたは複数のプロセッサとすることができるプロセッサ181を用いて構成されていることが可能である。プロセッサ181は、メモリ182に通信するように接続されることが可能であり、このメモリは、揮発性メモリおよび不揮発性メモリを含めて、任意のタイプのメモリまたはメモリタイプの組合せとすることができる。一実施形態においては、UE101、eNodeB170、および/またはMME/S−GW180は、本明細書に開示されるようなLTE−AシステムにおいてUCIシグナリングを実装するように構成されている。
【0015】
DFT−S−OFDMは、UE101からeNodeB170への(すなわち、アップリンクにおける)通信手段として使用され得る。DFT−S−OFDMは、UEに割り当てられる時間−周波数リソースが、周波数連続サブキャリアのセットから成るという追加の制約条件を有するOFDM伝送の一形式である。LTEアップリンクは、直流(DC)サブキャリアを含まない可能性がある。LTEアップリンクは、1モードのオペレーションを含むことができ、そこでは周波数ホッピングは、UEによって伝送に対して適用されることが可能である。LTEリリース8(R8)のアップリンク(UL)においては、ある種の関連するレイヤ1/レイヤ2(L1/2)のアップリンク制御情報(UCI)が、アップリンク(UL)伝送、ダウンリンク(DL)伝送、スケジューリング、MIMOなどをサポートする必要性が存在する。例えば、UE101は、eNodeB170に対して定期的に、および/または非定期的にUCIを供給するように構成されていることが可能である。UCIは、1ビットまたは2ビットとすることができるHARQ(hybrid automatic repeat request)ACK/NACK(肯定応答/否定応答)、CQI(channel quality indicator、チャネル品質インジケータ)を含むチャネルステータス報告、PMI(precoding matrix indicator、プリコーディングマトリクスインジケータ)、および/またはPUCCHの上で送信されるときに4〜11ビットとすることができるRI(rank indicator、ランクインジケータ)、および1ビットとすることができるSR(scheduling request、スケジューリングリクエスト)から成ることができる。これらのタイプのUCIについてのビットの数のこれらの例は、LTEリリース8におけるこれらのタイプについてのビットの数に対応する。これらのタイプについてのビットの数は、これらの値だけに限定されず、そして他の実施形態が、本開示の範囲内にあるものと考えられる。
【0016】
特に、CQI、PMI、およびRIのビットタイプについて言及する、本明細書において説明される実施形態および例においては、これらの実施形態は、UEによってサポートされ、そして定期的に、または非定期的に報告され得る追加のUCIビットタイプを含むように簡単に拡張されることが可能である。これらの実施形態および例は、CQI、PMI、およびRIのビットタイプのうちの任意の1つまたは複数をUEによってサポートされ、そして定期的に、または非定期的に報告され得る他のタイプのUCIビットと置換するように簡単に拡張されることも可能である。
【0017】
LTEリリース8においては、UCIは、2つのやり方のうちの一方で、例えば、UE101によって送信されることが可能である。サブフレームの中に、割り当てられたPUSCH(Physical UL Shared Channel)リソースのない場合に、UE101は、PUCCH(Physical UL Control Channel)リソースを使用してUCIを送信することができる。ULデータが、存在し、またはUEが、その他の方法でPUSCHの上でデータを送信しているときに、UCIシグナリングは、PUSCHの上で起こることができ、そしてPUSCHの上のデータと多重化されることが可能である。しかしながら、リリース8においては、PUCCHとPUSCHとの同時伝送は、サポートされない。さらに、UEによるACK/NACKとCQIとの同時伝送は、UE特有のより高いレイヤのシグナリングによって可能にされないこともある。この場合には、CQIは、脱落(drop)され、そしてACK/NACKだけが、PUCCHを使用して送信され、これは、スケジューリングおよびレート適合化の精度における何らかの悪化をもたらす可能性がある。
【0018】
3GPPリリース10(R10)に導入されたLTE−進化型(LTE−A)においては、例えばUE101によるPUSCHとPUCCHとの同時伝送が、サポートされることが可能であり、そしてUL波形に対する単一キャリア制約条件が、緩和される。リリース10においては、各ULコンポーネントキャリアに対する周波数連続リソースと周波数非連続リソースとの両方の割付けが、サポートされる。
【0019】
LTE−Aにおいては、UCIサイズ(UCIビットの数)は、COMP(coordinated multipoint)伝送、より高次のDL MIMO、帯域幅拡張、およびリレーを含めて、新しい特徴を考慮に入れて、LTEに比べて、増大されることになることが期待される。例えば、高次のMIMO(例えば、8×8のMIMO)および/またはCOMPをサポートするために、大量のチャネルステータス報告(CQI/PMI/RI)が、サービングeNodeB(およびもしかするとCOMP実装における隣接するeNodeB(単数または複数))に対してフィードバックされることが可能である。UCIオーバーヘッドは、非対称帯域幅拡張の使用によってさらに増大されることになる。したがって、リリース8のLTE PUCCHのペイロードサイズは、LTE−Aにおいて(単一DLコンポーネントキャリアの場合でさえも)増大されたUCIオーバーヘッドを搬送するのに十分でないこともある。LTE−AにおけるUCIシグナリングは、LTEにおけるUCIシグナリングよりも柔軟とすることができ、LTE−AにおけるUCIシグナリングにおけるより多くの構成を可能にする。これに起因して、そしてUCIサイズ(UCIビットの数)が、LTE−Aにおいてより大きいこともあるので、増大されたUCIサイズをサポートする新しい構成が必要とされる可能性がある。本開示のいくつかの実施形態においては、PUSCHとPUCCHとの同時伝送の能力は、LTE−Aシステム、または他の任意のシステムにおいて生成され得るUCIシグナリングを送信するために利用される。
【0020】
さらに、PUSCHとPUCCHとについてのパワー設定は、それぞれ独立に行われるので、PUSCHとPUCCHとのパワーレベルの合計が、与えられた最大送信パワーに到達し、またはそれを超過する状況の場合に、サブフレームにおいてPUCCHとPUSCHとの同時伝送をうまく利用する実施形態について、LTE−A UCIシグナリングについてのいくつかのルールが、本明細書において説明される。
【0021】
本明細書において使用されるように、PUCCHは、LTEまたはLTE−AのPUCCHとすることができ、このPUCCHは、アップリンク制御情報を搬送するアップリンクチャネルであることに注意すべきである。あるいは、本明細書において使用されるようなPUCCHは、アップリンクについての制御情報を送信するために排他的に、または非排他的に使用されることが可能な任意の1つもしくは複数のチャネル、または他の無線通信手段とすることもできる。本明細書において使用されるように、PUSCHは、LTEまたはLTE−AのPUSCHとすることができ、このPUSCHは、ユーザデータ(すなわち、SCHデータ)を搬送するアップリンクチャネルである。あるいは、本明細書において使用されるようなPUSCHは、アップリンクの上でユーザデータを送信するために排他的に、または非排他的に使用されることが可能な任意の1つもしくは複数のチャネル、または他の無線通信手段とすることもできる。本明細書において使用されるようなPUSCHは、制御情報を搬送することもできる。本明細書において使用されるようなアップリンク制御情報(UCI)は、特定のLTEまたはLTE−Aの制御情報とすることができ、またはUCIは、任意のタイプのチャネルまたは無線通信手段の上で搬送される、任意の無線システムにおいて使用される任意の制御情報とすることができる。すべてのそのような実施形態は、本開示の範囲内にあるものと考えられる。
【0022】
図2は、LTEシステムまたはLTE−Aシステムの一部、または全部として構成されていることが可能な無線通信システム/アクセスネットワーク200を示すものである。ネットワーク200は、E−UTRAN(Evolved-Universal Terrestrial Radio Access Network)250を含むことができる。E−UTRAN250は、図1のUE101を含めて、任意のタイプのUEまたはWTRUとすることができるUE210と、図1のeNodeB170などのeNodeBの機能を実行するように構成された任意のデバイスとすることができる1つまたは複数のeNodeB220a、220b、および220cとを含むことができる。図2に示されるように、UE210は、eNodeB220aと通信することができる。eNodeB220a、220b、および220cは、X2インターフェースを使用して互いにインターフェースすることができる。eNodeB220a、220b、および220cは、S1インターフェースを通してMME/S−GW230aおよび/または230bに接続されることも可能である。MME/S−GW230aおよび230bは、図1のMME/S−GW180などのMME/S−GWの機能を実行するように構成された任意のデバイスとすることができる。単一のUE210と3つのeNodeB220a、220b、および220cが、図2に示されているが、任意の数の無線デバイスと有線デバイスとそれらの組合せが、ネットワーク200に含まれ得ることが企図される。
【0023】
LTE−Aシステムにおいて実装されるいくつかの実施形態においては、UEからeNodeBへとUL制御情報(UCI)を送信することが望ましいこともあり、それはULユーザデータ伝送および他のUL伝送、DLユーザデータ伝送および他のDL伝送、スケジューリングデータ、MIMOデータなどをサポートするためである。UCIは、それだけには限定されないが、HARQ ACK/NACK(単数または複数)、チャネルステータス報告、CQI/PMI/RI、および/またはSR(スケジューリングリクエスト(単数または複数))を含むことができる。本明細書において使用されるような「ユーザデータ」という用語は、「SCH(shared channel、共用チャネル)データ」と交換可能とすることができることに注意すべきである。UEは、PUCCHまたはPUSCHの上でUCIを送信することができる。表1は、いくつかの実施形態で使用され得るLTEについて定義されたPUCCHフォーマットと、対応するUCIの内容とを示すものである。フォーマット2aおよび2bは、通常の巡回プレフィックスだけについてサポートされる。いくつかの実施形態においては、PUSCHの上でUCIを送信するときに、同じフォーマットが使用されることが可能である。
【0024】
【表1】

【0025】
UCIを報告するためにUEによって使用され得る時間リソースと周波数リソースとは、eNodeBによって制御されることが可能である。CQI、PMI、およびRIの報告などの何らかのUCIは、定期的または非定期的とすることができる。いくつかの実施形態においては、非定期的報告は、定期的報告によって提供されるデータと類似したデータ、ならびに追加のデータを提供することができる。そのような実施形態においては、定期的報告と非定期的報告との両方が、同じサブフレームにおいて起こることになる場合、UEは、そのサブフレームにおいて非定期的報告を送信するだけのように構成されていることが可能である。
【0026】
各PUCCH報告モードのCQIおよびPMIのペイロードサイズは、あらかじめ決定され、例えば、3GPP規格仕様によって提供されることが可能である。各PUCCH報告モードの他のUCIタイプのペイロードサイズは、あらかじめ決定され、例えば、3GPP規格仕様によって提供されることが可能である。
【0027】
LTE−Aシステムにおいて起こり得るアップリンク制御情報(UCI)の増大されたUCIサイズとより高いボリュームとを取り扱うために、本開示によって導入されるいくつかの実施形態が、使用されることが可能である。本明細書に開示される実施形態のいくつかは、LTE−AのPUSCHとPUCCHとの同時伝送能力をうまく利用する。
【0028】
一実施形態においては、LTE−AシステムにおいてUEからUCIをシグナリングするための代替的構成が、LTE UCIシグナリング方法に加えて使用されることが可能である。第1のそのような実施形態においては、複数のPUCCH伝送が、複数のUCIのフィールドまたは報告のために使用されることが可能である。複数のUCIフィールド/報告を多重化するための複数のPUCCH伝送(またはリソース)は、複数のPUCCH伝送が、符号多重化、または周波数多重化のいずれかであるように実装されることが可能である。例えば、LTEにおいては、チャネル品質インジケータ(CQI)の伝送が、同じサブフレームにおいてスケジューリングリクエスト(SR)伝送と衝突するときに、CQIは、脱落(drop)される。しかしながら、LTE−Aにおいては、符号分割多重(CDM)(すなわち、セル特有のシーケンスの異なる直交位相回転を使用したもの)、または周波数分割多重(FDM)(すなわち、異なるリソースブロック(RB)を使用したもの)を使用して、同じサブフレームの中で同時に送信されるCQIとSRとを有することが可能である。したがって、UEは、PUCCHフォーマット1(もしかすると1a/1bを有する)と、フォーマット2(もしかすると2a/2bを有する)とを多重化してそれらを複数のPUCCHリソース上で同時に送信することができる。あるいは、複数のPUCCH伝送は、UEから高ボリュームのLTE−A UCIを送信するようにも考えられ得る。
【0029】
複数のPUCCHリソース上でのUCIシグナリングを実装する実施形態においては、CDM、FDM、もしくは時分割多重(TDM)、またはそれらの任意の組合せを使用して、UCIをシグナリングすることができる。一実施形態においては、高ボリュームUCIが必要とされるときに、UCIは、CDM(すなわち、セル特有のシーケンスの異なる位相回転)を使用して複数のPUCCHリソース上でUEから送信されることが可能である。そのような実施形態においては、セル特有の長さ−12の周波数ドメイン(またはタイムドメイン)シーケンスの異なる直交位相回転(等価的な巡回シフト)が、UCIの各ビット(または1グループのビット、または異なる制御フィールド)について適用されることが可能である。例えば、非対称帯域幅拡張(2つのDLコンポーネントキャリアと1つのULコンポーネントキャリアとなど)の場合には、異なるDLコンポーネントキャリアについてのHARQ ACK/NACKビットが、セル特有のシーケンスの異なる位相回転を使用して単一のULキャリアにおいて送信されることが可能である。あるいは、または追加して、図3に示されるように、異なるDLキャリアについてのACK/NACKビット(ACK/NACKビット310および320)が、同じ位相回転シーケンスを使用して、ただしキャリア−1およびキャリア−2についてそれぞれ異なる直交カバーシーケンス(orthogonal cover sequence)w1およびw2を使用して、(同じ時間−周波数リソースの上で)送信されることが可能である。
【0030】
eNodeBは、レイヤ1もしくは2(L1/2)のシグナリング、またはより高いレイヤのシグナリングにより、サブフレームにおいて複数のUCIフィールド/報告を多重化するようにUEを構成することができる。複数のPUCCH伝送を使用する実施形態においては、複数のPUCCHの総送信パワーが、Pmax(またはPmax+P_しきい値、ここでP_しきい値は、しきい値である)として示されるUEの最大送信パワーを超過する場合、そのときにはUEは、LTE UEプロシージャに対して(すなわち、CQI/PMIなどの低優先順位フィードバック報告を脱落(drop)させることによって)ピギーバックする(piggyback)ことができる。
【0031】
eNodeBは、複数のPUCCH伝送についてのブラインド検出(blind detection)を使用して、どのPUCCH伝送(UCIフィールド)が、サブフレームにおいて適用されるかを決定することができる。あるいは、その全体が参照によって本明細書によって組み込まれている「APPARATUS AND METHOD FOR UPLINK POWER CONTROL FOR A WIRELESS TRANSMITTER/RECEIVER UNIT UTILIZING MULTIPLE CARRIERS」という名称の2010年2月9日に出願された米国特許出願第12/703,092号明細書に開示されたパワー低減/バックオフアプローチのいくつかが、何らかの修正を有するいくつかの実施形態において使用されることが可能である。例えば、各PUCCHについてパワーレベルを計算した後に、パワーの合計が、Pmaxを超過する場合、そのときにはそれぞれの送信パワーは、最大パワー制限に準拠するように同等パワーまたは相対的パワーを用いて(個別のチャネルの優先順位に応じて)調整されることが可能である。複数のPUCCHについてのパワー設定のための別のオプションは、個別のPUCCHについてのパワーオフセットを導入することなど、LTE PUCCHパワー制御を修正することである。最大許容CC送信パワー(単数または複数)を超過することは、これらの決定のために、Pmaxを超過することの代わりに、またはPmaxを超過することに追加して、考慮されることが可能である。
【0032】
代替的実施形態においては、複数のPUCCHリソース上のUCIシグナリングが、FDMを使用して実装されることが可能である。そのような実施形態においては、UCIの各ビット(あるいはACK/NACKビットおよびCQIビットのような1グループのビット、または異なる制御フィールド)は、あらかじめ構成されたPUCCH領域内の異なるRBペア(すなわち、PUCCHリソース)を使用して送信されることが可能である。図4は、ACK/NACKが、m=0に対応するRB420上で送信されるが、同じサブフレームにおいて、CQI/PMI/RIが、m=2に対応するRB430など、異なるRB上で送信されるように、PUCCH領域410において複数のPUCCH RBリソース(FDMベースの)を使用して高ボリュームUCI(例えば、複数のUCI報告)を送信する一例を示すものである。あるいは、または追加して、非対称帯域幅拡張(2つのDLコンポーネントキャリアと1つのULコンポーネントキャリアとなど)の場合には、異なるDLコンポーネントキャリアについてのUCIビット(単数または複数)は、キャリア−1およびキャリア−2についてそれぞれm=0,2など、異なるRBペア上で送信されることが可能である。
【0033】
別の実施形態においては、複数のPUCCHリソース上のUCIシグナリングが、TDMを使用して実装されることが可能である。そのような実施形態においては、UCIの各ビット(あるいはACK/NACKビットおよびCQIビットのような1グループのビット、または異なる制御フィールド)は、OFDMシンボルに基づいて、スロットに基づいて、またはサブフレームに基づいて時分割ベース(TDB)で送信されることが可能である。
【0034】
複数のPUCCHリソースの実施形態上の上記UCIシグナリングにおいては、UEは、どのPUCCHリソース(時間/周波数/符号)がUEに対して割り付けられるかに関して、より高いレイヤのシグナリング(またはL1シグナリング)を通して、eNodeBによって構成され得ることに注意すべきである。これらの実施形態においては、R8 LTE PUCCHフォーマットは、3GPP規格仕様において指定されるように保持されることが可能であり、すなわちR8 LTEに対する後方互換性を保持している。さらに、CDM(およびFDM)の場合には、CM(cubic metric、キュービックメトリック)は、使用中のリソース(符号/位相回転、またはRB)の数に応じて増大させられることが可能である。したがって、PUCCHについてのパワー設定に対するCMの影響が、考慮に入れられることが可能であり、すなわち、もしあれば、CMの増大の量によるパワーバックオフを適用する。
【0035】
別の実施形態においては、同じサブフレームの中のPUCCHとPUSCHとの両方の上でのUCIシグナリング(UEから、PUSCHとPUCCH(単数または複数)との両方の上でUCI、例えば、高ボリュームUCIを送信する)が、例えば、非対称キャリアアグリゲーションのより高次のDL MIMO、および/またはCOMPが、使用中であるときに、実装されることが可能である。同じサブフレームにおいてPUCCH(単数または複数)とPUSCHとの両方の上でUCIをシグナリング(UCIについてのPUCCHとPUSCHとの同時伝送)するために、ACK/NACKおよび/またはSRは、ACK/NACKおよび/またはSRが、PUCCHの上で送信され得るが、同じサブフレームにおいて(定期的な、または非定期的な)CQI/PMI/RIシグナリングが、PUSCH上で実行され得るように(または逆もまた同様である)、CQI/PMI/RIと多重化されることが可能である。いくつかの実施形態においては、送信すべきユーザデータのないUEは、ULデータなしにPUSCHの上でUCIを送信するように構成されていることが可能である。例えば、DL COMPにおけるUEは、サービングセルのために意図されたPUSCH上のサービング(アンカー)セルに関連するUCI(ACK/NACK、CQI/PMI/RI、およびSRを含む)を送信することができるが、同じサブフレームにおいて、UEは、その受信側セル(単数または複数)についてのあらかじめ指定されたPUCCH(単数または複数)上の非サービング(アンカー)セルを対象とする他の制御情報(例えば、CQI/PMI)を送信することができ、または逆もまた同様である。
【0036】
図5は、DL COMPにおいて、UEからPUCCH(単数または複数)とPUSCHとの両方の上でUCIを送信する一例を示すものである。この例においては、UEは、サブフレームにおいて送信されるUL共用チャネル(UL−SCH)データを有することが仮定される。UEが、そのときに送信されるべきどのようなデータも有していない場合、UCIは、ULデータなしにPUSCHの上で送信される。あるいは、または追加して、非対称CA(例えば、1つのULキャリアと、N個のDLキャリアとがあり、ここでN>1)の場合、UEは、PUSCHまたはPUCCH(単数または複数)のいずれかの上でDLアンカーキャリアに関連するUCIを送信することもできる。同時に、UEは、他の物理チャネル(例えば、DLアンカーキャリアのために使用されていない)の上でDL非アンカーキャリア(単数または複数)についてのUCIを送信することができる。あるいは、UEは、異なるULコンポーネントキャリア(CC)の上でPUSCH上のDL非アンカーキャリア(単数または複数)についてのUCIを送信することもできる。
【0037】
LTE−Aシステムの実施形態においては、PUSCHとPUCCHとについてのパワー設定は、それぞれ、独立して行われることが可能である。同じサブフレームにおいてPUSCHとPUCCH(単数または複数)との両方の上でUCIを送信する場合に、Pmaxが、到達されるとき(すなわち、負のパワーヘッドルーム(negative power headroom)の場合)には、最大パワー制限に準拠するために、同等パワー低減、相対的パワー低減、チャネル(および/またはUCIタイプ)に基づいた優先順位を使用したパワー低減など、本明細書において参照される米国特許出願第12/703,092号に説明されるアプローチを含めて、パワーバックオフアプローチがある。あるいは、または追加して、Pmaxが到達されることを検出する、PUSCHとPUCCHとの両方を使用してUCIを送信するUEは、本明細書に開示されるような複数のPUCCHリソースを使用してUCIを送信する方法に切り替わることができる。別の代替案においては、そのようなUEは、PUSCHだけを使用してUCIを送信することができる。あるいは、UEは、PUCCHだけを使用して、もしかすると、もしあれば、CQI/PMIのような低優先順位のUCIフィールドを脱落(drop)させて、UCIを送信することができる。最大許容CC送信パワー(単数または複数)を超過することは、Pmaxを超過することの代わりに、またはPmaxを超過することに追加して、これらの決定のために考慮されることが可能である。
【0038】
別の実施形態においては、UCIについての定期的なPUCCHと非定期的なPUSCHとの同時伝送が、実装されることが可能である。レガシーLTE(R8)システムにおいては、定期的なCQI/PMI/RI報告と非定期的なCQI/PMI/RIとの間の衝突の場合には、定期的なCQI/PMI/RI報告が、そのサブフレームにおいて脱落(drop)される。しかしながら、UEは、必要な場合、同じサブフレームにおいて非定期的報告と定期的報告との両方を送信するように構成されていることが可能である。例えば、非対称CAにおいて、UEは、PUCCHを使用してDLアンカーキャリアに関連する定期的なCQI/PMI/RI報告を実行するように、そして同じサブフレームにおいて、PUSCHを使用してDL非アンカーキャリア(単数または複数)に関連する非定期的CQI/PMI/RI報告を実行するように構成されていることが可能であり、または逆もまた同様である。Pmaxが、到達されるとき(すなわち、負のパワーヘッドルームの場合)に、UEは、PUSCHの上の非定期的CQI/PMI/RI報告を脱落(drop)させることができる。あるいは、UEは、PUCCHの上の定期的CQI/PMI/RI報告を脱落(drop)させることができる。最大許容CC送信パワー(単数または複数)を超過することは、Pmaxを超過することの代わりに、またはPmaxを超過することに追加して、これらの決定のために考慮されることが可能である。
【0039】
別の実施形態においては、高ボリュームUCIは、PUSCHの上で送信されることが可能である。UCIペイロードサイズが、あまりにも大きすぎる(HARQ ACK/NACKビットの数と、CQI/PMI/RIについてのペイロードビットの数との合計が、しきい値よりも大きいなど)ので、それが、PUCCHリソースに適合することができないときに、UCIは、UEがPUSCHの上のデータ伝送についてスケジューリングされているときのPUSCHの上のLTE UCIシグナリングと同様に、UL−SCHデータを用いて、またはUL−SCHデータなしで(UEがデータ伝送についてスケジューリングされているか否かに応じて)PUSCHの上で送信されることが可能である。本実施形態においては、UEが、UCIを搬送するためにPUSCHの上のデータ伝送のためにスケジューリングされることが必要でない可能性がある。もっと正確に言えば、UEは、UCIがPUSCHの上で搬送されるべきときにより高いレイヤのシグナリングまたはL1/2シグナリングによって構成されていることが可能である。
【0040】
eNodeBは、例えば、UEの能力、DL/UL構成/サービス、チャネル状態、PUSCH/PUCCHのリソース使用可能性、および/またはUE送信パワーの使用可能性に応じて、PUCCHとPUSCHとの両方の上でUCIを送信するようにUEを構成し、またはPUCCHとPUSCHとの両方の上でUCIを送信しないようにUEを構成することができる。構成は、L1/2シグナリングまたはより高いレイヤのシグナリングを通してUEに対して与えられることが可能である。同じサブフレームにおけるPUCCH(単数または複数)とPUSCHとの両方の上でUCIを送信する場合には、PUCCHとPUSCHとについてのパワーレベルをそれぞれ計算した後に、パワーの合計が、Pmaxを超過する場合、それぞれのチャネル送信パワーが、最大パワー制限に準拠するために同等パワーもしくは相対的パワー(個別のチャネルの優先順位に応じて)、またはあらかじめ定義されたオフセットを用いて調整され/低減されることが可能であるような、(本明細書において参照される米国特許出願第12/703,092号明細書に説明されるものを含む)パワーバックオフアプローチを使用することができる。さらに別の代替案においては、UEは、もしかするとCQI/PMIのような低優先順位のUCIフィールドを脱落(drop)させてPUCCHの上だけでUCIを送信することができる。さらに別の実施形態においては、UEは、UEがデータ伝送についてスケジューリングされているか否かに応じてアップリンク共用チャネル(UL−SCH)データを用いて、またはアップリンク共用チャネル(UL−SCH)データなしでPUSCHの上だけですべての必要とされるUCIフィールドを送信することができる。これらの実施形態のうちのどれかで、eNodeBは、個別の物理チャネル(すなわち、PUCCHとPUSCHと)についてのブラインド検出を使用して、どの物理チャネル(単数または複数)(またはUCIフィールド)が、サブフレームにおいて送信されるかを決定することができる。最大許容CC送信パワー(単数または複数)を超過することは、Pmaxを超過することの代わりに、またはPmaxを超過することに追加して、これらの決定のために考慮されることが可能である。
【0041】
代替的実施形態においては、レガシーLTE UCIシグナリングは、LTEに似たDL/UL構成(ワンツーワンDL/ULスペクトルマッピングや無COMPなど)を用いてUEによって実行されることが可能である。UCIオーバーヘッドは、LTE R8と類似したものにすることができる。しかしながら、LTE R8とは違って、UEは、同じサブフレームにおいてPUSCHの上で非定期的CQI/PMI/RIを送信しながら、PUCCHの上で(一実施形態において、ACK/NACKの信頼性を改善するために)HARQ ACK/NACKを送信することができる。
【0042】
別の代替案においては、より高次の変調(16QAM)を有する新しいPUCCHフォーマットを使用して、より大きなUCIサイズをサポートすることができる。これらの新しいPUCCHフォーマットは、より高次の変調を使用して定義されることが可能である。表2に示されるように、新しいPUCCHフォーマットは、16QAM(フォーマット3、4/4a/4b/4c)を使用して導入される。PDCCHフォーマット3は、4ビットのACK/NACK(もしかするとSRを伴う)を搬送するために使用されることが可能である。例えば、4ビットのACK/NACKは、キャリアアグリゲーション(例えば、SM MIMOを有する2つのDLキャリアと、1つのULキャリアと)の中で使用されることが可能である。PUCCHフォーマット4/4a/4b/4cが使用されて、LTE−AにおいてCQI/PMI/RIビットの40個の符号化ビット(4a/4b/4cにおいてACK/NACKを伴う)をフィードバックすることができる。本明細書に開示される新しいフォーマットでは、PUCCHについてのパワー設定は、より高次の変調、16QAMの使用を受け入れる(すなわち、異なるSINRが、異なる変調スキームについて必要とされることを反映する)パワーオフセットを含むことができる。
【0043】
【表2】

【0044】
LTE−A UCIシグナリングを使用して上記に説明される実施形態のすべてにおいては、eNodeBは、L1/2シグナリングまたはより高いレイヤのシグナリングによってUCIを送信するようにUEを構成することができる。
【0045】
代替的実施形態においては、PUCCHとSRSとの同時伝送は、SRSシンボルロケーション(最後のOFDMシンボル)におけるPUCCH(単数または複数)(およびPUSCH)とSRSとの同時伝送をサポートするLTE−Aシステムにおいて使用されることが可能である。そのような実施形態においては、UEは、SRSを、たとえSRSとPUCCHのフォーマット1/1a/1b(通常のPUCCHフォーマット1/1a/1bを含む)および/または2/2a/2b(およびもしかすると本明細書において説明されるようなフォーマット3/4/4a/4b/4c)とでも、送信することができ、そしてその伝送は、LTE−Aシステムにおいてそのような伝送を簡略化する同じサブフレームにおいて起こる。
【0046】
別の実施形態においては、UCIシグナリングは、UL MIMOを実装するLTE−Aシステムにおいて実行されることが可能である。PUSCHについてのいくつかのMIMOモードは、SM(spatial multiplexing、空間多重)MIMO(開ループや閉ループのSM MIMOなど)と、ビーム形成(BF)と、送信ダイバーシティ(CDD(cyclic delay diversity、巡回遅延ダイバーシティ)、STBC(space-time block coding、空間−時間ブロックコーディング)、SFBC(space-frequency block coding、空間−周波数ブロックコーディング)、SORTD(spatial-orthogonal resource transmit diversity、空間的−直交リソース送信ダイバーシティ)など)とを含めて、使用されることが可能である。本開示に応じて構成されたLTE−Aシステムは、UCIシグナリングについての以下のMIMOモードのうちのどれでも使用することができる。PUCCHの上のUCI伝送では、以下のMIMOオプションのうちのどれかが実装されることが可能である。
【0047】
−1つのレイヤを有するビーム形成(この場合には、eNodeBは、UEについてのコードブックまたはPMIフィードバックを提供する)。
−CDD伝送(tx)ダイバーシティ。
−STBC/SFBC/SORTD。
−アンテナスイッチング(この場合には、アンテナスイッチングは、OFDMシンボルに基づいて、またはスロットに基づいて行われることが可能である)。
−UL MIMOにおけるPUSCHとPUCCHとの同時伝送が、実装され、ここでUCIが、PUCCHの上で送信されるときに、上記のMIMOオプションのうちの任意の1つが、PUSCHについてのMIMOモードに関係なくPUCCHについて使用されることが可能である。
【0048】
PUSCHの上のUCI伝送では、一実施形態において、PUSCHにおけるUCI部についてのUL MIMOスキームは、データ部についてのUL MIMOと独立に適用されることが可能であり、ここでUCI部についてのMIMOスキームは、以下のうちの任意の1つとすることができる。
【0049】
−1つのレイヤを有するビーム形成。
−CDD txダイバーシティ。
−STBC/SFBC。
−アンテナスイッチング(この場合には、アンテナスイッチングは、OFDMシンボルに基づいて、またはスロットに基づいて行われることが可能である)。
−アンテナ選択。
−PUSCHのデータ部と同じMIMOモードが、UCI部について適用されることが可能である。
【0050】
別の実施形態においては、UEは、PUSCHの上だけですべてのUCIビットを送信することができ、ここでは大きなUCIサイズが、LTE−A UCI伝送について使用されることが可能である。
【0051】
同時PUCCH/PUSCH UCI伝送のより詳細な実施形態を提供する方法およびシステムが、次に説明される。UEが、もしあれば、UCIビットのうちのどれをPUCCHの上で送信すべきかと、もしあれば、どれをPUSCHの上で送信すべきかとを決定することを可能にする方法およびシステムが、提供される。PUSCHの上で送信すべきユーザデータを有するUEでは、PUSCHの上で送信されるUCIは、データと一緒に送信されることが可能である。ユーザデータのないPUSCH伝送では、UCIだけが、PUSCHの上で送信されることが可能である。以下の実施形態においては、UCIビットは、アクティブな(または構成された)ダウンリンクコンポーネントキャリア(DL CC)のすべてについて与えられたサブフレームについてUCIを含むことができる。スケジューリング、eNodeB要求、DL伝送など、様々なファクタに基づいて、与えられたDL CCについてのUCIビットは、1つまたは複数のACK/NACKビット(実際のビット、またはたとえ送信されないとしてもACK/NACKのために予約されたビット)と、CQIビットと、PMIビットと、RIビットと、他のタイプのフィードバックビット(長期(アウターループ(outerloop)とも呼ばれる)PMIや短期(インナーループ(innerloop)とも呼ばれる)PMIなど)と、UEが無線ネットワークに対して送信することができる他の任意の制御ビットとを含むことができる。異なるDL CCは、与えられたサブフレームの中に送信されるべき異なるUCIビットタイプを有することができる。任意の1つまたは複数のDL CCは、与えられたサブフレームの中で送信されるべきUCIビットを有さない可能性がある。UCIビットは、DL CCに特に関連していない制御ビットのタイプを含むこともできる。
【0052】
CQI報告とPMI報告とは、一般的に一緒に報告され、そして本明細書においてはCQI/PMI報告と称されることに注意すべきである。しかしながら、そのような報告は、別々に報告されることも可能であり、本明細書における実施形態は、そのような実施形態へと簡単に拡張されることが可能である。本明細書において説明される方法および実施形態のおのおのに対する変形として、複数のPUCCHが、与えられたサブフレームに割り付けられ、そしてUCIを搬送することが許可される場合に、PUCCHは、複数のPUCCHを意味するように拡張されることが可能である。
【0053】
一実施形態においては、どのようにしてUCIが、サブフレーム内で送信すべきUCIビットの数(これは、UCIペイロードサイズとも称され得る)に基づいて送信されるべきかについての決定が行われることが可能である。図6は、そのような実施形態を実装する方法を示すものである。ブロック610において、送信されるべきUCIビットの数についての決定が行われる。一実施形態においては、この決定は、任意の非定期的CQI/PMI/RI報告ビットと、任意の他の非定期的報告ビットとを除外することができる。他の実施形態は、そのような非定期的報告ビットを含むことができる。
【0054】
ブロック620において、UCIビットの数が何らかの数N以下であるかどうかについての決定が行われることが可能である。Nは、UEの上であらかじめ構成されてもよく、またはeNodeBによってUEに対して信号伝達されてもよい。Nの値は、各PUCCHフォーマットについてNの異なる値が存在することができるように、PUCCHフォーマットの関数とすることができる。UCIビットの数が、N以下である場合、UEは、ブロック630においてPUCCHの上ですべてのUCIビットを送信する準備をすることができる。UCIビットの数が、Nよりも大きい場合、UEは、ブロック640においてPUCCHの上のUCIビットのサブセットと、PUSCHの上のUCIビットの残りとを送信する準備をすることができる。例えば、UEは、PUCCHの上のACK/NACKビットと、PUSCHの上の残りのUCIビット(CQI、PMI、RIなど)とを送信する準備をすることができる。あるいは、ブロック650において、UCIビットの数が、N’よりも大きいかどうかについての決定が行われることも可能であり、ここでN’>Nである。N’は、UEの上であらかじめ構成されてもよく、またはeNodeBによってUEに対して信号伝達されてもよい。N’の値は、各PUCCHフォーマットについてN’の異なる値が存在することができるように、PUCCHフォーマットの関数とすることができる。この実施形態においては、UCIビットの数が、N’よりも大きい場合、そのときにはブロック660において、UEは、PUSCHの上ではすべてのUCIビットを送信するように、そしてPUCCHの上では何も送信しないように準備することができる。UCIビットの数がNよりも大きいが、N’以下である場合、UEは、ブロック640において、PUCCHの上のUCIビットのサブセットと、PUSCHの上のUCIビットの残りとを送信する準備をすることができる。別の代替案においては、UCIビットの数が、ブロック620においてNよりも大きいと決定される場合、そのときにはUEは、ブロック660においてPUSCHの上ではすべてのUCIビットを送信するように、そしてPUCCHの上では何も送信しないように準備することができる。
【0055】
行われる必要があるかもしれない他の変更または決定がなければ、そのようなUCIビットは、さらなる調整なしに送信され得ることに注意すべきである。本開示の全体を通して、UEは、UCIビットの伝送の前に、追加の調整の可能性を可能とするようにそのようなビットを単に送信するのでなくて、UCIビットを「送信する準備をする」ように説明されることが可能である。例えば、UEは、PUCCHとPUSCHとの両方を使用してUCIビットを送信する準備をすることができるが、パワーしきい値が、(以下でより詳細に説明されるように)そのような伝送によって到達されることになることを後になって決定することができ、そしてそれ故にPUCCHとPUSCHとのうちの一方だけを使用してUCIビットを実際に送信することができる。
【0056】
代替的実施形態においては、UEは、UCIペイロードが、割り付けられたPUCCHの上に適合するかどうかを決定して、どのようにしてUEがUCIを送信することになるかを決定することができる。図7は、そのような一実施形態を実装する方法を示すものである。ブロック710において、送信されるべきUCIビットの数(UCIペイロードのサイズとも称される)についての決定が行われる。一実施形態においては、この決定は、任意の非定期的CQI/PMI/RI報告ビットと、任意の他の非定期的報告ビットとを除外することができる。他の実施形態は、そのような非定期的報告ビットを含むことができる。
【0057】
ブロック720において、UCIビットのすべてが、割り付けられたPUCCHに適合することになるかどうかについての決定が行われる。UCIビットのすべてが、割り付けられたPUCCHに適合することになる場合、ブロック730において、UEは、PUCCHの上ではすべてのUCIビットを送信するように、そしてPUSCHの上では何も送信しないように準備することができる。UCIビットの数がPUCCHに適合しない場合、ブロック740において、UEは、PUCCHの上のビットのサブセットと、PUSCHの上の残りとを送信する準備をすることができる。例えば、UEは、PUCCHの上のACK/NACKビットと、PUSCHの上の残りのUCIビット(CQIビット、PMIビット、RIビットなど)とを送信する準備をすることができる。別の例として、UEは、すべてのDL CCについてのACK/NACKビットと、PUCCHに適合することになる同じ数のDL CCについてのすべての非ACK/NACKビット(CQIビット、PMIビット、RIビットなど)と、PUSCHの上の他のDL CCについての非ACK/NACKビット(CQIビット、PMIビット、RIビットなど)とを送信する準備をすることができる。UCIビットが、割り付けられたPUCCHに適合することになるかどうかを決定するときに、UEは、そのPUCCHについてのすべての許容されたPUCCHフォーマットを考慮することができる。
【0058】
別の実施形態においては、UEは、UCIペイロードサイズを1つもしくは複数のデータペイロードサイズまたはPUSCHサイズ(これは、PUSCH搬送容量と呼ばれることもある)と比較して、どのようにしてUEがUCIを送信することになるかを決定することができる。PUSCHサイズは、RBの数、OFDMシンボルの数、物理的符号化ビットの数などの1つまたは複数のファクタ、またはこれらもしくは他のファクタの何らかの組合せを使用して測定されることが可能である。図8は、そのような実施形態を実装する方法を示すものである。ブロック810において、送信されるべきUCIのペイロードサイズ(ビットの数)についての決定が行われる。一実施形態においては、この決定は、任意の非定期的CQI/PMI/RI報告ビットと、任意の他の非定期的報告ビットとを除外することができる。他の実施形態は、そのような非定期的報告ビットを含むことができる。
【0059】
ブロック820において、UEは、UCIペイロードサイズと、1つまたは複数のデータペイロードサイズとPUSCHサイズとの間の関係を決定することができる。例えば、UEは、しきい値Nと、PUSCHサイズに対するUCIペイロードの相対的サイズ(例えば、パーセンテージ)、またはデータペイロードに対するUCIペイロードの相対的サイズ(例えば、パーセンテージ)とを比較して、どのようにしてUCIを送信すべきかを決定することができる。Nは、UEの上であらかじめ構成されてもよく、またはeNodeBによってUEに対して信号伝達されてもよい。例えば、PUSCHサイズについてのUCIペイロードサイズのパーセンテージ、またはデータペイロードサイズについてのUCIペイロードサイズのパーセンテージが、しきい値Nよりも小さい場合、UEは、ブロック830においてPUSCHの上のすべてのUCIを送信する準備をすることができる。PUSCHサイズについてのUCIペイロードサイズのパーセンテージ、またはデータペイロードサイズについてのUCIペイロードサイズのパーセンテージが、しきい値N以上である場合、UEは、ブロック840において、PUCCHの上のいくつかのUCIビットと、PUSCHの上の他のUCIビットとを送信する準備をすることができ、またはブロック850において、PUCCHの上のすべてのUCIビットを送信する準備をすることができる。
【0060】
代替的実施形態においては、UEは、PUSCHサイズをしきい値と比較して、どのようにしてUEがUCIを送信することになるかを決定することができる。PUSCHサイズは、RBの数、OFDMシンボルの数、物理的符号化ビットの数などの1つまたは複数のファクタ、またはこれらまたは他のファクタの何らかの組合せを使用して測定されることが可能である。この決定は、UCIペイロードサイズとは独立であるので、ブロック810は、スキップされてもよい。ブロック820において、PUSCHのサイズは、しきい値Nと比較されることが可能である。Nは、UEの上であらかじめ構成されてもよく、またはeNodeBによってUEに対して信号伝達されてもよい。PUSCHの搬送容量が、与えられたしきい値Nよりも大きい場合、そのときにはUEは、ブロック830において、PUSCHの上のすべてのUCIを送信する準備をすることができる。大きなPUSCHの場合には、PUSCHの上のデータとUCIとを組み合わせるための性能ペナルティは、低減されることが可能であり、それでこの場合においてPUSCHの上のUCIのすべてを送信することと、最大パワー低減(MPR)効果に起因した同時のPUSCH−PUCCHの可能性のあるパワー制限を回避することとが、望ましい可能性がある。PUSCHの容量が、N以下である場合、UEは、ブロック840においてPUCCHの上のいくつかのUCIビットと、PUSCHの上の他のUCIビットとを送信する準備をすることができる。あるいは、UEは、ブロック850において、PUCCHの上ですべてのUCIビットを送信する準備をすることができる。
【0061】
他の実施形態においては、UEが、PUSCHを割り付けられ、そして送信すべきユーザデータを持たない場合、UEは、UCIペイロードサイズに応じて、PUSCHまたはPUCCHとPUSCHとの組合せの上でUCIを送信する準備をすることができる。図9は、そのような実施形態を実装する方法を示すものである。ブロック910において、ユーザデータが伝送のために使用可能でないという決定が、行われる。ブロック920において、送信されるべきUCIビットの数についての決定が行われる。ブロック930において、すべてのUCIビットがPUSCHに適合することになるかどうかについての決定が、行われる。そうである場合、ブロック940において、UEは、PUSCHの上ですべてのUCIを送信する準備をすることができる。UCIビットの数が、PUSCHに適合しない場合、ブロック950において、UEは、ACK/NACKビットなど、PUCCHの上のUCIのサブセットと、PUSCHの上のUCIビットの残りとを送信する準備をすることができる。あるいは、UCIビットの数が、PUSCHに適合しないときには、ブロック950において、UEは、PUCCHの上ですべてのUCIビットを送信する準備をすることができる。PUCCHの搬送容量が、PUSCHの搬送容量よりも大きい場合に、これは可能性があるにすぎないことに注意すべきである。これらの実施形態においては、UEが送信すべきデータを持たないときに、PUSCHの上でUCIを送信することは、PUSCHの上の性能に影響を与えないので、PUSCHは、UCIビットが適合することになるときに、PUCCHよりも好ましい可能性がある。
【0062】
これらの実施形態のうちのどれかの変形として、送信されるべきUCIビットが、非定期的なCQI/PMIまたはRIの報告に関連するCQIビット、PMIビット、またはRIビットを含む場合、UEは、送信されるべきUCIビットの数を決定するときに、および/またはどのビットがPUCCHの上を進むことができるかを決定するときに、そのようなビットを除外することができる。そのような実施形態においては、UEは、PUSCHの上の非定期的なCQI/PMIおよびRIの報告に関連するCQIビット、PMIビット、およびRIビットを常に送信することになる。そのような実施形態は、非定期的報告が、定期的報告よりもずっと大きく、そしてPUCCHに適合しそうにないときに、望ましい可能性がある。追加の非定期的報告タイプが、R10について、または将来において定義される場合、UEは、このようにして、これらの報告についてのビットを同様に除外するように、そしてPUSCHの上で常にこれらのビットを送信するように構成されていることが可能である。
【0063】
例えば、任意の非定期的なCQI/PMIおよびRIの報告ビットを除外したUCIビットの数が、ある数N以下であり、またはあるいはPUCCHの搬送容量以下である場合、そのときにはUEは、任意の非定期的なCQI/PMIおよびRIの報告ビットを除いてPUCCHの上ですべてのUCIビットを送信する準備をすることができ、そしてPUSCHの上の非定期的なCQI/PMIおよびRIの報告ビットを送信する準備をすることができる。任意の非定期的なCQI/PMIおよびRIの報告ビットを除外したUCIビットの数が、Nよりも大きく、またはあるいはPUCCHの搬送容量よりも大きい場合、そのときにはUEは、PUCCHの上のビットのサブセットと、PUSCHの上の残りとを送信する準備をすることができる。例えば、一実施形態においては、UEは、PUCCHの上のACK/NACKビットと、PUSCHの上のすべてのCQIビット、PMIビット、およびRIビット(定期的報告と非定期的報告とについての)とを送信する準備をすることができる。あるいは、任意の非定期的なCQI/PMIおよびRIの報告ビットを除外したUCIビットの数が、N’よりも大きい(ここでN’>N)場合、そのときにはUEは、PUSCHの上ではすべてのUCIビットを送信するように、そしてPUCCHの上では何も送信しないように準備することができる。別の代替案においては、任意の非定期的なCQI/PMIおよびRIの報告ビットを除外したUCIビットの数が、Nよりも大きい場合、そのときにはUEは、PUSCHの上ではUCIビットのすべてを送信するように、そしてPUCCHの上では何も送信しないように準備することができる。NおよびN’は、おのおの、UEの上であらかじめ構成されてもよく、またはeNodeBによってUEに対して信号伝達されてもよい。NおよびN’の値は、おのおの、各PUCCHフォーマットについて異なる値のNおよび/またはN’が存在することができるように、PUCCHフォーマットの関数とすることができる。
【0064】
本明細書に開示される実施形態のどれかでは、PUCCHの搬送容量を決定するときに、UEは、割り付けられたPUCCHについてのすべての許容されたPUCCHフォーマットを考慮することができることに注意すべきである。実施形態のおのおのにおいては、スケジューリングが、同じタイプの定期的なUCI報告と非定期的なUCI報告とが、与えられたDL CCについて同時に送信されることになるようである場合、UEは、UCIペイロードサイズの伝送から、そしてUCIペイロードサイズの決定から、そのCCについてのそのタイプの定期的報告を省略することができる。
【0065】
他の実施形態においては、UEは、どのようにしてUEが、送信することが必要なUCIビットのタイプに基づいてUCIを送信することになるかを決定することができ、そしてそのような決定は、UCIタイプの優先順位に基づいたものとすることができる。図10に示される、そのような一実施形態においては、UCIの中のビットのタイプが、ブロック1010において決定されることが可能である。ブロック1020において、送信されるべきUCIビットのうちのどれかが、ACK/NACKビットであるかどうかについての決定が行われることが可能である。送信されるべきUCIビットが、ACK/NACKビットを含む場合、UEは、ブロック1030において、PUCCHの上のACK/NACKビットと、PUSCHの上のすべての他のタイプのUCIビットとを送信する準備をすることができる。ACK/NACKビットは、最も重要なビットである可能性があるので、それらは、よりよい性能のために、PUSCHの上よりもPUCCHの上で送信される可能性がある。
【0066】
あるいは、図11に示されるように、UEは、どのタイプのUCIビットが、PUCCHフォーマットのおのおのの中でPUCCHに整合するかを知るように、そしてその知識に基づいてどのようにしてUCIを送信すべきかを決定するように構成されていることが可能である。ブロック1110において、送信されるべきUCIにおけるビットのタイプが、UEによって決定されることが可能である。ブロック1120において、UEは、一実施形態においてPUCCHの上で送信されることになる高優先順位ビットの数が、最大にされるように、整合する最高優先順位タイプの組合せを選択することができる。ブロック1130において、UEは、適切なPUCCHフォーマットを使用してPUCCHに整合する最高優先順位タイプの組合せを送信する準備をすることができる。多数の実施形態においては、ACK/NACKは、最高優先順位を有し、RI(または同等物)は、第2の最高優先順位を有し、そしてCQI/PMI(または同等物)は、優先順位において続いていることに注意すべきである。UEは、PUSCHの上ですべての他のタイプのUCIを送信することができる。
【0067】
さらなる実施形態においては、UEは、例えば、マルチアンテナ技法の使用など、いくつかのアクティブな(または構成された)DL CCおよび/またはDL伝送モードを含めて、ダウンリンク(DL)構成に基づいてどのようにしてUEがUCIビットを送信することになるかを決定することができる。そのような一実施形態においては、UEが、DL CCの数が1であり、そしてDL伝送モードがR8においてサポートされる伝送モードであることを決定する場合、UEは、PUSCHの上ではUCIのすべてを送信するように、そしてPUCCHの上では何も送信しないように準備することができる。DL構成を使用した代替的実施形態が、図12に示されている。ブロック1210において、DL CCの数が、1であるかどうか、そしてDL伝送モードが、R8−LTEにおいてサポートされる伝送モードであるかどうかについての決定が行われることが可能である。そうでない場合、例えば、DL CCの数が、1よりも大きい場合、UEは、ブロック1215においてPUCCHの上の(集約された)UCIビットのサブセットと、PUSCHの上のUCIビットの残りとを送信する準備をすることができる。UEは、本明細書において説明される他の方法と実施形態とに従って、PUCCHの上でどのビットを送信すべきかと、PUSCHの上でどのビットを送信すべきかとを決定することができる。
【0068】
ただ1つのDL CCが存在し、そしてDL伝送モードが、R8−LTEにおいてサポートされる伝送モードである場合、ブロック1220において、UCIが、ACK/NACKビットを含むかどうかについての決定が行われることが可能である。そうである場合、ブロック1230において、UEは、PUCCHの上でACK/NACKビットを送信する準備をすることができる。ブロック1240において、UCIの中に定期的なCQI/PMIビットと定期的なRIビットとが存在するかどうかについての決定が行われることが可能である。そうである場合、UEは、ブロック1250においてPUCCHの上の定期的なRIビットと、PUSCHの上の定期的なCQI/PMIビットとを送信する準備をすることができる。ブロック1260において、定期的なCQI/PMIビットが存在し、そして定期的なRIビットが存在していないかどうかについての決定が行われることが可能である。そうである場合、UEは、ブロック1270においてPUCCHの上で定期的なCQI/PMIビットを送信する準備をすることができる。ブロック1280において、定期的なRIビットが存在し、そして定期的なCQI/PMIビットが存在していないかどうかについての決定が行われることが可能である。そうである場合、UEは、ブロック1290においてPUCCHの上で定期的なRIビットを送信する準備をすることができる。UEが、非定期的なUCI報告ビットが存在することを決定する場合、UEは、PUSCHの上でこれらを送信する準備をする。
【0069】
いくつかの実施形態においては、UEは、送信アンテナポートの数などのUL伝送モード、および/または連続的なPUSCH RB割付けに対する非連続的なPUSCH RB割付けを含めたPUSCH構成に基づいて、どのようにしてUEがUCIを送信することになるかを決定することができる。そのような一実施形態においては、UEが、サブフレームにおいて複数のアンテナポートを用いてPUSCH(2つのコードワードを搬送する)を送信するように構成されている場合、そのときにはUEは、PUSCHの上のCQI/PMIビットと、PUCCHの上のUCIビットの残り(例えば、ACK/NACKビットおよび/またはRIビット)とを送信する準備をすることができる。あるいは、UEは、PUSCHの上ではUCIビットのすべてを送信するように、そしてPUCCHの上では何も送信しないように準備することもできる。
【0070】
他の実施形態においては、非連続的なPUSCH RB割付けの許可がUEに対して与えられる場合、そのときにはUEは、PUSCHの上ではUCIのすべてを送信するように、そしてPUCCHの上では何も送信しないように準備することができる。そうでない場合(すなわち、連続的なPUSCH RB割付けの場合)には、UEは、本明細書に開示される1つまたは複数の方法を使用してUCIビットを送信する準備をすることができる。
【0071】
いくつかの実施形態においては、同じサブフレームにおいてDL CCについて同じタイプの定期的UCI報告と、非定期的UCI報告との両方が要求されている(または伝送のためにスケジューリングされている)可能性がある。この場合には、UEは、PUSCHの上でそのCCについての非定期的UCI報告ビットを送信する(または送信する準備をする)ことができ、そしてUEは、そのCCについてのそのタイプについての定期的報告を脱落させる(送信しない)ことができる。図13は、そのような一実施形態を実装する一方法を示すものである。ブロック1310において、同じサブフレームにおいてDL CCについて同じタイプの定期的報告と非定期的報告との両方が要求されている(または伝送のためにスケジューリングされている)という決定が行われることが可能である。ブロック1320において、UEは、そのCCについてそのタイプについての定期的報告を脱落させる(送信しない)ことができる。ブロック1330において、本明細書に開示される1つまたは複数の方法を使用したいくつかの実施形態において、残りのUCIの内容が送信され、または伝送のために準備されることが可能である。
【0072】
いくつかの実施形態においては、同じサブフレームにおいて異なるDL CCについて定期的UCI報告と、非定期的UCI報告との両方が要求されている可能性がある。例えば、1つのDL CCについて定期的UCI報告が要求されている可能性があるが、別のDL CCについて非定期的UCI報告が要求されている可能性がある。この場合には、UEは、PUCCHの上の定期的UCI報告ビットと、PUSCHの上の非定期的UCI報告ビットとを送信する(または送信する準備をする)ことができ、または逆もまた同様である。
【0073】
他の実施形態においては、UEは、DL CC優先順位を使用して、どのようにしてUEがUCIを送信することになるかを決定することができ、ここで主要なDL CCは、最高の優先順位を有する。図14は、そのような一実施形態を実装する一方法を示すものである。ブロック1410において、UEは、UCIビットのうちのどれかが、主要なDL CCについてのものであるかどうかを決定することができる。そうでない場合、ブロック1420において、UEは、PUSCHの上でUCIのすべてを送信する準備をすることができる。主要なDL CCについてのものであるUCIのビットが存在する場合、そのときにはブロック1430において、主要なDL CCに関連するビットが、PUCCHの上のUEによる伝送のために準備されることが可能であるが、UCIの残りのビットは、同じサブフレームにおいてPUSCHの上の伝送のために準備されることが可能である。例えば、UCIが、与えられたサブフレームにおいて送信されるべき複数の定期的CQI/PMI報告から成り、そしてそれらの報告のうちの1つが主要なDL CCについてのものである場合、そのときにはブロック1430において、UEは、PUCCHの上の主要なDL CCについてのCQI/PMI報告と、PUSCHの上の他の報告とを送信する準備をすることができる。報告のどれもが主要なDL CCについてのものでない場合、UEは、ブロック1420においてPUSCHの上ですべての報告を送信する準備をすることができる。
【0074】
ブロック1410において、主要なDL CCについて送信されるべきビットが存在しないことが決定される場合、ブロック1420においてPUSCHの上ですべてのUCIビットを送信する代わりに、UEは、ブロック1440において、PUCCHの上の、次の最高優先順位のDL CCについてのUCIビット(例えば、構成順序、DL CCのインデックスまたはID、あるいはUEおよび/またはeNodeBに知られている他の任意の手段によって決定されるような)と、PUSCHの上の他のDL CCについてのUCIとを送信する準備をすることができることに注意すべきである。例えば、UCIが、与えられたサブフレームにおいて送信されるべき複数の定期的CQI/PMI報告から成り、そして報告のどれもが、主要なDL CCについてのものでない場合、そのときにはUEは、PUCCHの上の、次の最高優先順位のDL CCについてのCQI/PMI報告と、PUSCHの上の他の報告とを送信する準備をすることができる。この次の優先順位のDL CCについてのオプションと代替案とは、主要なDL CCについて本明細書において説明されるようなものである。
【0075】
あるいは、UEが、割り付けられたPUCCHについての許容されたPUCCHフォーマットを使用するときに、UCIタイプのある種の組合せだけがPUCCHに適合することになることを知るように構成されている場合、そのときにはUEは、ブロック1430において、PUCCHの上の主要なDL CCについての最高優先順位のUCIタイプの組合せ(例えば、定期的なRIが送信されるべき場合のACK/NACKおよび定期的RI、そうでない場合のACK/NACKおよび定期的CQI/PMI)と、PUSCHの上の主要なDL CCについての他のUCIタイプとを送信する準備をすることができる。あるいは、UEは、主要なDL CCについての他のUCIタイプについてのビットを脱落(drop)させることもできる。主要なDL CCについてのUCIビットが存在しない場合、同じ原理は、ブロック1440においてUCIが存在するための最高優先順位のDL CCに対して適用されることが可能である。
【0076】
別の代替案においては、与えられたサブフレームにおいて送信されるべきUCIが、主要なDL CCについてのACK/NACKおよび定期的CQI/PMI報告を含む場合、そのときにはUEは、ブロック1430においてPUCCHの上の主要なDL CCについてのACK/NACKおよび定期的CQI/PMI報告と、PUSCHの上の他のUCIビットとを送信する準備をすることができる。主要なDL CCについてのUCIビットが存在しない場合、同じ原理は、ブロック1440においてUCIが存在するための最高優先順位のDL CCに対して適用されることが可能である。
【0077】
いくつかの実施形態においては、UEは、どのようにしてUEが、UCIについての明示的な許可に基づいて(例えば、定期的CQI/PMI/RI報告についての)UCIビットを送信することになるかを決定することができる。そのような実施形態においては、eNodeBは、UEに対してUL許可を明示的に供給して、例えば、新しい、または修正されたDCIフォーマットを経由して、あるいはより高レイヤのシグナリングを経由して、ユーザデータなしにUCIを送信することができる。例えば、eNodeBは、それが、UEが送信すべきデータを持たず、そしてスケジューリングされたUCI報告がPUCCHに適合しないことになることを知っているときに、UEに対してUL許可を供給して、CQI/PMIビットやRIビットなどについての定期的報告を送信することができる。一実施形態においては、UEが、そのような許可を受信する場合、UEは、その許可に従って、PUSCHの上だけでUCIを送信する準備をすることができる。別の実施形態においては、本明細書において説明される1つまたは複数の他の実施形態に従って、UEはPUCCHとPUSCHとの間でUCIを分割することができる。
【0078】
本明細書に開示される方法および実施形態のうちのどれかにおいて、どのようにしてUCIビットが送信されるべきかについてのさらなる決定は、最大パワーしきい値が、満たされているか、または超過されているか、あるいは満たされることになるか、または超過されることになるか否かに基づいて、UEおよび/またはeNodeBによって行われ得ることに注意すべきである。図15は、そのような一実施形態を実装する方法を示すものである。ブロック1510において、UEは、どのようにしてUCIを送信すべきかについての決定を行うことができる。UCIを送信する任意の手段または方法は、ブロック1510において、例えば、本明細書に開示される他の実施形態のうちのどれかに従って、同じサブフレームにおいてPUCCHとPUSCHとの間でUCIを分割することを含めて、決定されることが可能である。ブロック1520において、UEは、ブロック1510において決定される手段を使用してUCIの伝送のために必要とされるパワーを決定することができる。ブロック1530において、UEは、伝送のために必要とされるパワーが、最大許容パワーを超過することになるかどうかを決定することができる。最大パワーが超過されないことになる場合、ブロック1540において、UCIビットは、ブロック1510において決定された好ましい方法に応じて送信されることになる。最大パワーが超過されることになるかどうかに関する決定は、CC最大送信パワー(単数または複数)やUE最大送信パワーなど、構成され、またはそれ以外の方法でUEに知られている1つまたは複数のパワー制限を含むことができる。
【0079】
ブロック1530において、最大許容パワーが、超過されることになることが決定される場合、UEは、アクションの1つまたは複数の代替的コースを取ることができる。一実施形態においては、UEは、ブロック1550において1つまたは複数のPUCCHおよびPUSCHのパワーをスケールする(scale)ことができる。使用され得るスケールする方法および手段は、それだけには限定されないが、本明細書において参照される米国特許出願第12/703,092号明細書において説明される方法および手段を含んでいることに注意すべきである。
【0080】
あるいは、ブロック1530において、最大許容パワーが、超過されることになることが決定される場合、UEは、ブロック1560においてPUSCHの上ですべてのUCIを送信することができる。PUSCHの上ですべてのUCIを送信することは、最大許容パワーを低減することができる同時PUSCH−PUCCH伝送からもたらされるMPR効果を取り除く。
【0081】
別の代替案において、ブロック1530においてUEが、最大許容パワーが超過されることになることを決定する場合、ブロック1570において、UEは、PUSCHの上ですべてのUCIを送信することが、最大許容パワーレベルを超過するかどうかを決定することができる。PUSCHの上ですべてのUCIを送信することが、最大許容パワーレベルを超過しない場合、PUSCHの上ですべてのUCIを送信することは、伝送の前にパワーをスケールするべき必要性を取り除くことになる。PUSCHの上でUCIを送信することが、パワーをスケールするべき必要性を取り除くことになる場合、UEは、ブロック1560において、PUSCHの上ですべてのUCIを送信することができる。PUSCHの上ですべてのUCIを送信することが、パワーをスケールする必要性を取り除かないことになる場合、UEは、例えば、同じサブフレームにおいてPUCCHとPUSCHとを通してUCIを分割して、UCI伝送方法に対するその最初の決定を保持し、そしてブロック1580においてチャネルの優先順位などに基づいてブロック1550について説明されるような任意の方法でPUCCHとPUSCHとの上のパワーをスケールすることができる。そのような実施形態においては、PUCCHが最高優先順位を有することができるので、PUCCHの上のUCIは、維持されることが可能である。
【0082】
本明細書に開示される方法および実施形態のどれかでは、PUCCHとPUSCHとは、同じUL CCまたは異なるUL CCの上で送信され得ることに注意すべきである。これらの方法および実施形態は、両方の場合に適用可能である。異なるUL CCの上の伝送についての一例は、PUCCHが、主要なUL CCの上で送信され得るが、PUSCHが、他のUL CCの上で送信され得るというものである。
【0083】
いくつかのLTE−Aシステムおよび実装において、複数のPUSCHが、サブフレームごとに使用され得る。そのような実施形態においては、任意のUCIビットが、PUCCHの上ではなくて、またはPUCCHの上に追加してPUSCHの上で送信されるべきであることが決定されているときに、UEは、どのPUSCHの上でUCIビットを送信すべきかを決定する必要がある可能性がある。そのようなビットは、本明細書において「PUSCHのためのUCIビット」と称される。
【0084】
図16の中に示される、そのような一実施形態においては、UEは、ブロック1610において複数のPUSCHが、使用中であり、または使用可能であるかどうかを先ず決定することができる。そうでない場合、そのときにはブロック1620において、UEは、使用可能なPUSCHの上で、PUSCHの上の伝送のために意図される任意のUCIビットを送信する準備をすることができる。使用可能な複数のPUSCHが存在する場合、UEは、ブロック1630において、PUSCHサイズ(搬送容量)に基づいてUCIの伝送のためにPUSCHを選択することができる。一実施形態においては、UEは、最大のサイズ(または搬送容量)を有するPUSCHの上でPUSCHについてのUCIビットを送信する準備をすることができる。PUSCHサイズは、RBの数、OFDMシンボルの数、物理的符号化ビットの数などの1つもしくは複数のファクタ、またはこれらもしくは他のファクタの何らかの組合せを使用して測定されることが可能である。あるいは、ブロック1630において、UEは、2つ以上のUCIペイロードサイズと、PUSCHデータペイロードサイズおよびPUSCH搬送容量との間の関係に基づいてPUSCHを選択することができる。例えば、UEは、総ペイロードサイズに対するUCIペイロードサイズ(例えば、そのパーセンテージ)、またはデータペイロードに対するUCIペイロードサイズ(例えば、そのパーセンテージ)が、最小となるPUSCHの上のPUSCHについてのUCIビットを送信することができる。これらの実施形態のおのおのは、PUSCHの上のデータを伴うUCIを含むことについての性能の影響を低減させることができる。ブロック1640において、UEは、ブロック1630において選択されたPUSCHの上でPUSCHについてのUCIビットを送信する準備をすることができる。
【0085】
代替的実施形態においては、ブロック1610において、複数のPUSCHが存在することを決定するとすぐに、UEは、ブロック1650においてPUSCHを有する主要なUL CCが存在するかどうかを決定することができる。そうである場合、UEは、ブロック1660において主要なUL CCのPUSCHの上でPUSCHについてのUCIビットを送信する準備をすることができる。主要なUL CCは、主要なDL CCとペアにされているUL CCとすることができる。主要なUL CCの上にPUSCHが存在しない場合、PUSCHは、ブロック1630の手段、または他の任意の手段または方法を使用して選択されることが可能である。代替的実施形態においては、UEは、UEがその上でACK/NACKビットを送信すべき、eNodeBによって何らかのやり方で構成され、または指定されるUL CCの上のPUSCHとなるように、UCIビットの伝送のためのPUSCHを選択することができる。
【0086】
いくつかの実施形態においては、UEは、明示的なシグナリング、または非定期的UCI報告要求についての許可などの許可に基づいて、伝送のためのPUSCHを選択することができる。そのような一実施形態においては、UEは、L1またはより高いレイヤのシグナリングを経由して、eNodeBによって明示的に指定されるPUSCHの上でPUSCHについてのUCIビットを送信する準備をすることができる。一代替案においては、eNodeBが、UCI専用のUL許可を提供する場合、UEは、割り付けられたPUSCHの上でPUSCHについてのUCIを送信する準備をすることができる。別の代替案においては、UEが、非定期的UCI要求ビット(または「1」に設定された非定期的要求ビット)を有するPDCCHを受信する場合、UEは、PDCCHによってこの要求に関連するPUSCHの上でPUSCHについてのUCIビットを送信する準備をすることができる。そのようなUCIビットは、PUSCHの上で送信されるべき非定期的UCI報告ビットと、すべての他のUCIビットとを含むことができる。
【0087】
本明細書に開示される実施形態および方法の特徴および要素は、上記では特定の組合せの形で説明されるが、おのおのの特徴または要素は、他の特徴および要素なしに単独で、あるいは他の特徴および要素を有し、または有さない様々な組合せの形で使用されることが可能である。本明細書において提供される方法またはフローチャートは、汎用コンピュータまたはプロセッサによる実行のためのコンピュータ読取り可能ストレージ媒体の形で組み込まれたコンピュータプログラム、ソフトウェア、またはファームウェアの形で実装されることが可能である。コンピュータ読取り可能ストレージ媒体の例は、ROM(read only memory)と、RAM(random access memory)と、レジスタと、キャッシュメモリと、半導体メモリデバイスと、内部ハードディスクや着脱可能ディスクなどの磁気媒体と、磁気−光媒体と、CD−ROMディスクやDVD(digital versatile disks)などの光媒体とを含む。
【0088】
適切なプロセッサは、例として、汎用プロセッサ、専用プロセッサ、従来型プロセッサ、DSP(digital signal processor)、複数のマイクロプロセッサ、DSPコアと関連した1つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、ASIC(Application Specific Integrated Circuit)、FPGA(Field Programmable Gate Array)回路、他の任意のタイプのIC(Integrated Circuit)、および/または状態機械を含む。
【0089】
ソフトウェアに関連したプロセッサを使用して、無線送信受信ユニット(WTRU)、ユーザ装置(UE)、端末、基地局、無線ネットワークコントローラ(RNC)、または任意のホストコンピュータの中で使用するための無線周波数トランシーバを実装することができる。UEは、カメラ、ビデオカメラモジュール、ビデオ電話、スピーカーフォン、振動デバイス、スピーカー、マイクロフォン、テレビジョントランシーバ、ハンズフリーヘッドセット、キーボード、ブルートゥース(Bluetooth)(商標)モジュール、FM(周波数変調)無線ユニット、LCD(液晶ディスプレイ)ディスプレイユニット、OLED(有機発光ダイオード)ディスプレイユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザ、および/または任意のWLAN(無線ローカルエリアネットワーク)またはUWB(Ultra Wide Band)モジュールなど、ハードウェアおよび/またはソフトウェアの形で実装されたモジュールと連動して使用されることが可能である。

【特許請求の範囲】
【請求項1】
アップリンク制御情報を送信するための方法であって、
前記アップリンク制御情報が、判断基準を満たすことを決定することと、
前記アップリンク制御情報が、前記判断基準を満たすことを決定することに応じて、第1のサブフレームにおいて物理的アップリンク制御チャネルの上でアップリンク制御情報ビットの第1のサブセットを送信することと、前記第1のサブフレームにおいて物理的アップリンク共用チャネルの上でアップリンク制御情報ビットの第2のサブセットを送信することと
を含むことを特徴とする方法。
【請求項2】
前記アップリンク制御情報が、前記判断基準を満たすことを決定することは、アップリンク制御情報ビットの数が、第1のしきい値より上にあることを決定することを含むことを特徴とする請求項1に記載の方法。
【請求項3】
アップリンク制御情報ビットの前記数は、第2のしきい値より下にあることを決定することをさらに含むことを特徴とする請求項2に記載の方法。
【請求項4】
前記アップリンク制御情報が、前記判断基準を満たすことを決定するステップは、アップリンク制御情報ビットの数が、前記物理的アップリンク制御チャネルに適合しないことになることを決定することを含むことを特徴とする請求項1に記載の方法。
【請求項5】
前記アップリンク制御情報が、前記判断基準を満たすことを決定することは、
相対的アップリンク制御情報ペイロードサイズを決定することと、
前記相対的アップリンク制御情報ペイロードサイズが、第1のしきい値より小さいことを決定することと
を含むことを特徴とする請求項1に記載の方法。
【請求項6】
前記アップリンク制御情報が、前記判断基準を満たすことを決定することは、送信すべきユーザデータが存在しないこと、およびアップリンク制御情報ビットの数が前記物理的アップリンク共用チャネルに適合しないことになることを決定することを含むことを特徴とする請求項1に記載の方法。
【請求項7】
前記アップリンク制御情報が、前記判断基準を満たすことを決定することは、前記アップリンク制御情報が、肯定応答ビットと否定応答ビットとのうちの少なくとも一方を含むことを決定することを含むことを特徴とする請求項1に記載の方法。
【請求項8】
アップリンク制御情報ビットの前記第1のサブセットは、前記肯定応答ビットと前記否定応答ビットとのうちの少なくとも一方を含み、アップリンク制御情報ビットの前記第2のサブセットは、すべての他のアップリンク制御情報ビットを含むことを特徴とする請求項7に記載の方法。
【請求項9】
前記アップリンク制御情報が、前記判断基準を満たすことを決定することは、単一のダウンリンクコンポーネントキャリアが存在することを決定することを含むことを特徴とする請求項1に記載の方法。
【請求項10】
前記アップリンク制御情報が、チャネル品質インジケータビットと、プリコーディングマトリクスインジケータビットと、ランクインジケータビットとのおのおののうちの少なくとも1つを含むことを決定することをさらに含むことを特徴とする請求項9に記載の方法。
【請求項11】
アップリンク制御情報を送信するように構成された無線送信受信ユニットであって、
前記アップリンク制御情報が、判断基準を満たすことを決定するように、および、
前記アップリンク制御情報が、前記判断基準を満たすことを決定することに応じて、アップリンク制御情報ビットの第1のサブセットと、アップリンク制御情報ビットの第2のサブセットとを決定するように
構成されたプロセッサと、
第1のサブフレームにおいて物理的アップリンク制御チャネルの上でアップリンク制御情報ビットの前記第1のサブセットを送信するように、および、
前記第1のサブフレームにおいて物理的アップリンク共用チャネルの上でアップリンク制御情報ビットの前記第2のサブセットを送信するように
構成されたトランシーバと
を備えたことを特徴とする無線送信受信ユニット。
【請求項12】
前記アップリンク制御情報が、前記判断基準を満たすことを決定するように構成された前記プロセッサは、少なくとも1つのアップリンク制御情報ビットが、主要なダウンリンクコンポーネントキャリアに関連づけられることを決定するように構成された前記プロセッサを備えたことを特徴とする請求項11に記載の無線送信受信ユニット。
【請求項13】
前記プロセッサは、さらに、前記物理的アップリンク制御チャネルの上でアップリンク制御情報ビットの前記第1のサブセットを送信するために、および前記物理的アップリンク共用チャネルの上でアップリンク制御情報ビットの前記第2のサブセットを送信するために必要とされるパワーが、最大パワーしきい値よりも小さいことを決定するように構成されていることを特徴とする請求項11に記載の無線送信受信ユニット。
【請求項14】
前記プロセッサは、さらに、
前記物理的アップリンク制御チャネルの上でアップリンク制御情報ビットの前記第1のサブセットを送信するために、および前記物理的アップリンク共用チャネルの上でアップリンク制御情報ビットの前記第2のサブセットを送信するために必要とされるパワーが、最大パワーしきい値よりも大きいことを決定するように、および、
PUCCHパワーレベルとPUSCHパワーレベルとのうちの少なくとも一方をスケールダウンするように
構成されていることを特徴とする請求項11に記載の無線送信受信ユニット。
【請求項15】
前記プロセッサは、さらに、複数の物理的アップリンク共用チャネルから前記物理的アップリンク共用チャネルを選択するように構成されていることを特徴とする請求項11に記載の無線送信受信ユニット。
【請求項16】
前記プロセッサは、アップリンク制御情報ペイロードサイズに基づいて前記複数の物理的アップリンク共用チャネルから前記物理的アップリンク共用チャネルを選択するように構成されていることを特徴とする請求項15に記載の無線送信受信ユニット。
【請求項17】
前記プロセッサは、アップリンク制御情報ペイロードサイズと、物理的アップリンク共用チャネルデータペイロードサイズおよび物理的アップリンク共用チャネル搬送容量のうちの少なくとも一方との間の関係に基づいて前記複数の物理的アップリンク共用チャネルから前記物理的アップリンク共用チャネルを選択するように構成されていることを特徴とする請求項15に記載の無線送信受信ユニット。
【請求項18】
前記プロセッサは、前記複数の物理的アップリンク共用チャネルのうちの1つが、主要なアップリンクコンポーネントキャリアの上にあるかどうかに基づいて前記複数の物理的アップリンク共用チャネルから前記物理的アップリンク共用チャネルを選択するように構成されていることを特徴とする請求項15に記載の無線送信受信ユニット。
【請求項19】
前記アップリンク制御情報が、前記判断基準を満たすことを決定するように構成された前記プロセッサは、ダウンリンクコンポーネントキャリアの数が、1であること、および前記アップリンク制御情報が、チャネル品質インジケータビットと、プリコーディングマトリクスインジケータビットと、ランクインジケータビットとのおのおののうちの少なくとも1つを含むことを決定するように構成された前記プロセッサを備えたことを特徴とする請求項11に記載の無線送信受信ユニット。
【請求項20】
前記プロセッサは、さらに、
前記アップリンク制御情報が、定期的報告データと、非定期的報告データとを含むことを決定するように、および、
前記定期的報告データを切り捨てるように
構成されていることを特徴とする請求項11に記載の無線送信受信ユニット。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate

【図8】
image rotate

【図9】
image rotate

【図10】
image rotate

【図11】
image rotate

【図12】
image rotate

【図13】
image rotate

【図14】
image rotate

【図15】
image rotate

【図16】
image rotate


【公表番号】特表2012−531114(P2012−531114A)
【公表日】平成24年12月6日(2012.12.6)
【国際特許分類】
【出願番号】特願2012−516341(P2012−516341)
【出願日】平成22年6月18日(2010.6.18)
【国際出願番号】PCT/US2010/039203
【国際公開番号】WO2010/148319
【国際公開日】平成22年12月23日(2010.12.23)
【出願人】(510030995)インターデイジタル パテント ホールディングス インコーポレイテッド (229)
【Fターム(参考)】