JP2018534823A - キャリアアグリゲーションにおけるアップリンクコントロール情報送信方法および装置 - Google Patents

Abstract

本発明の実施形態は、キャリアアグリゲーションにおけるアップリンクコントロール情報送信方法および装置を提供する。基地局が、第１の表示情報をユーザ機器ＵＥへ送信して、その第１の表示情報に従ってアップリンクコントロール情報ＵＣＩを動的に決定するようＵＥに指示し、基地局は、ＵＣＩを送信するためにＰＵＣＣＨリソースをＵＥへ割り振る。本発明の実施形態は、キャリアアグリゲーションシナリオにおけるＵＣＩ情報のフィードバックを実施し、それによって、有効なＵＣＩ情報を送信することのパフォーマンスを改善するために使用され得る。

Description

本発明の実施形態は、通信技術に関し、詳細には、キャリアアグリゲーションにおけるアップリンクコントロール情報送信方法および装置に関する。

ロングタームエボリューション（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ、略してＬＴＥ）システムにおいては、ユーザ機器（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ、略してＵＥ）が、物理アップリンクコントロールチャネル（Ｐｈｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ、略してＰＵＣＣＨ）を使用することによって、アップリンクコントロール情報（Ｕｐｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ、略してＵＣＩ）を基地局へ送信する。ＵＣＩは、スケジューリング要求インジケータ（ｓｃｈｅｄｕｌｉｎｇ ｒｅｑｕｅｓｔ、ＳＲ）、ハイブリッド自動再送要求肯定応答／否定応答（Ｈｙｂｒｉｄ Ａｕｔｏｍａｔｉｃ Ｒｅｐｅａｔ ｒｅＱｕｅｓｔ ＡＣＫｎｏｗｌｅｄｇｅｍｅｎｔ ｏｒ Ｎｅｇａｔｉｖｅ ＡＣＫｎｏｗｌｅｄｇｅｍｅｎｔ、略してＨＡＲＱ−ＡＣＫ／ＮＡＣＫ）情報、すなわち、ＨＡＲＱフィードバック情報、およびチャネル状態情報（Ｃｈａｎｎｅｌ Ｓｔａｔｅ Ｉｎｆｏｒｍａｔｉｏｎ、略してＣＳＩ）を含む。ＳＲは、アップリンクスケジューリングを基地局に適用するためにＵＥによって使用される。ダウンリンクＨＡＲＱ−ＡＣＫ／ＮＡＣＫは、ダウンリンク送信されたデータのデコーディング結果を示して、ＰＤＳＣＨ上で送信されたダウンリンクデータに対してＨＡＲＱ肯定応答を実行するために使用される。ＣＳＩは、ダウンリンクスケジューリングをｅＮｏｄｅＢが実行するのを手助けする目的で、ダウンリンクチャネル品質に関連した情報をフィードバックするために使用される。

ロングタームエボリューションアドバンスト（ＬＴＥ−Ａｄｖａｎｃｅｄ、略してＬＴＥ−Ａ）システムにおいては、より高い送信帯域幅をサポートするために、キャリアアグリゲーション（Ｃａｒｒｉｅｒ Ａｇｇｒｅｇａｔｉｏｎ、略してＣＡ）技術が提供される。ＣＡとは、より高い送信帯域幅をサポートするために複数のコンポーネントキャリア（Ｃｏｍｐｏｎｅｎｔ Ｃａｒｒｉｅｒ、略してＣＣ）をアグリゲート（Ａｇｇｒｅｇａｔｅ：集合）することを意味する。ダウンリンクＣＡシナリオにおいては、基地局は、同じＵＥへ複数のＣＣ上でダウンリンクデータを送信する。それに応じて、ＵＥは、複数のダウンリンクＣＣ上でのＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報のフィードバックをサポートする必要がある。

ハイブリッド自動再送要求（Ｈｙｂｒｉｄ Ａｕｔｏｍａｔｉｃ Ｒｅｐｅａｔ ｒｅＱｕｅｓｔ、略してＨＡＲＱ）は、前方エラー訂正（Ｆｏｒｗａｒｄ Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｏｎ、略してＦＥＣ）方法と、自動再送要求（Ａｕｔｏｍａｔｉｃ Ｒｅｐｅａｔ ｒｅＱｕｅｓｔ、略してＡＲＱ）方法とを組み合わせる技術である。ＦＥＣを用いて訂正されることが不可能であるエラーに関しては、受信端が、ＡＲＱメカニズムを使用することによって、データを再送信するよう送信端に要求する。受信端は通常、受信されたデータパケット上でエラーが発生しているかどうかを検知するためにＣＲＣチェックコードを使用する。受信されたデータパケット上でエラーが発生していない場合には、受信端は、肯定応答（ＡＣＫｎｏｗｌｅｄｇｅｍｅｎｔ、略してＡＣＫ）を送信端へ送信する。受信されたデータパケット上でエラーが発生している場合には、受信端は、そのデータパケットを破棄し、否定応答（Ｎｅｇａｔｉｖｅ ＡＣＫｎｏｗｌｅｄｇｅｍｅｎｔ、略してＮＡＣＫ）を送信端へ送信し、送信端は、そのＮＡＣＫを受信した後に同じデータを再送信する。

標準化されている既存のＣＡにおいては、最大でも５つだけのキャリアのアグリゲーションがサポートされ、プロトコルにおいては、準静的な方法を使用することによってＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報が決定される。この準静的な方法においては、構成されているキャリアの数量が５以下である場合には、構成されているキャリアの数量、ならびにそれぞれの構成されているキャリアの送信モード（ｔｒａｎｓｍｉｓｓｉｏｎ ｍｏｄｅ、略してＴＭ）およびキャリア番号に従ってＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報のコードブックが決定される。この方法においては、構成されているがスケジュールされていない（すなわち、データ送信のために実際には使用されていない）キャリアがある場合、またはキャリア上で送信されるコードワードの数量が最大構成に達していない場合には、ＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報は、いくつかの無用なビットを埋め込まれる。

アグリゲートされることが可能であるキャリアの数量を大幅に増大させるために、第３世代パートナーシッププロジェクト（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ、略して３ＧＰＰ）が、ＬＴＥキャリアアグリゲーションエンハンスメントビヨンド５キャリア、略してｅＣＡ）を提供している。ｅＣＡは、最大で３２個のキャリアがアグリゲートされ、および複数のキャリアのＣＳＩ情報が１つのサブフレームにおいてフィードバック可能であることを必要とする。したがって、ＰＵＣＣＨを使用してフィードバックされるＵＣＩ情報が、大幅に増大される。もしＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報が既存のプロトコルの方法に従って決定される場合には、より多くのビットがフィードバックされる必要がある。したがって、データ送信負荷が増大し、有効なＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報を送信するパフォーマンスに影響して、そのＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報が正しく送信されることさえ不可能となる。したがって、ｅＣＡシナリオにおいて大量のＵＣＩ情報をどのようにしてフィードバックするかが、解決されるべき差し迫った問題になっている。

本発明の実施形態は、キャリアアグリゲーションにおけるアップリンクコントロール情報送信方法および装置を提供し、キャリアアグリゲーションシナリオにおけるＵＣＩ情報のフィードバックを実施するために使用され得る。

第１の態様によれば、キャリアアグリゲーションにおけるアップリンクコントロール情報送信方法であって、
基地局によって、第１の表示情報をユーザ機器ＵＥへ送信するステップであって、第１の表示情報は、その第１の表示情報に従ってアップリンクコントロール情報ＵＣＩを動的に決定するようＵＥに指示するために使用される、ステップと、
基地局によって、ＰＵＣＣＨリソースをＵＥへ割り振るステップであって、そのＰＵＣＣＨリソースは、ＵＣＩを送信するために使用される、ステップとを含む方法が提供される。

第１の態様の実装形態を参照して、第１の態様の第１の可能な実装形態においては、第１の表示情報は、第１のタイプの表示情報または第２のタイプの表示情報であり、第１のタイプの表示情報は、スケジュールされているキャリアの数量に従って基地局がダウンリンク割り当てインデックスＤＡＩ情報を生成する場合に、第１のタイプの表示情報に従ってＵＣＩを決定するようＵＥに指示するために使用され、第２のタイプの表示情報は、スケジュールされているコードワードの数量に従って基地局がＤＡＩ情報を生成する場合に、第２のタイプの表示情報に従ってＵＣＩを決定するようＵＥに指示するために使用される。

第１の態様、または第１の態様の第１の可能な実装形態を参照して、第１の態様の第２の可能な実装形態においては、基地局によって、第１の表示情報をＵＥへ送信するステップは、
基地局によって、第１の構成情報をＵＥへ送信するステップであって、第１の構成情報は、第１の表示情報を含む、ステップを含む。

第１の態様、または第１の態様の第１もしくは第２の可能な実装形態のうちのいずれか１つを参照して、第１の態様の第３の可能な実装形態においては、基地局によって、第１の表示情報をＵＥへ送信するステップは、基地局によって、ダウンリンクコントロール情報ＤＣＩをＵＥへ送信するステップであって、ＤＣＩは、第１の表示情報を含む、ステップを含む。

第１の態様、または第１の態様の第１乃至第３の可能な実装形態のうちのいずれか１つを参照して、第１の態様の第４の可能な実装形態においては、基地局によって、第１の表示情報をＵＥへ送信するステップは、
基地局によって、第１の様式でエンコードされているＤＣＩをＵＥへ送信するステップであって、第１の様式は、第１のタイプの表示情報に対応し、第１の様式においては、ＤＣＩエンコーディング中に生成される巡回冗長検査ＣＲＣコードにスクランブリングコードが付加されない、ステップ、または基地局によって、第２の様式でエンコードされているＤＣＩをＵＥへ送信するステップであって、第２の様式は、第２のタイプの表示情報に対応し、第２の様式においては、ＤＣＩエンコーディング中に生成されるＣＲＣコードにスクランブリングコードが付加される、ステップを含む。

第１の態様、または第１の態様の第１乃至第４の可能な実装形態のうちのいずれか１つを参照して、第１の態様の第５の可能な実装形態においては、基地局によって、ＰＵＣＣＨリソースをＵＥへ割り振るステップは、基地局によって、第２の構成情報をＵＥへ送信するステップであって、第２の構成情報は、ＵＥ用のリソースリストを構成するために使用され、そのリソースリストは、複数のリソース情報グループを含む、ステップと、基地局によって、第２の表示情報をＵＥへ送信するステップであって、第２の表示情報は、リソースリスト内の１つのリソース情報グループに対応するＰＵＣＣＨリソースをＵＥに示すために使用される、ステップとを含む。

第１の態様、または第１の態様の第１乃至第５の可能な実装形態のうちのいずれか１つを参照して、第１の態様の第６の可能な実装形態においては、複数のリソース情報グループは、別々のＰＵＣＣＨフォーマットに従ってアレンジされており、それぞれのＰＵＣＣＨフォーマットは、少なくとも１つのリソース情報グループに対応し、それぞれのリソース情報グループは、１つのＰＵＣＣＨリソースの開始アドレス表示情報およびサイズ表示情報を含み、第２の表示情報は、リソースインデックスＲＩを含み、ＲＩは、そのＲＩに対応する第１のリソース情報グループをＵＥに示すために使用される。

第１の態様、または第１の態様の第１乃至第６の可能な実装形態のうちのいずれか１つを参照して、第１の態様の第７の可能な実装形態においては、基地局によって、第２の表示情報をＵＥへ送信するステップは、基地局によって、送信電力コントロールＴＰＣフィールドを使用することによって第２の表示情報、すなわち、第１のリソース情報グループに対応するＲＩを送信するステップを含む。

第１の態様、または第１の態様の第１乃至第７の可能な実装形態のうちのいずれか１つを参照して、第１の態様の第８の可能な実装形態においては、複数のリソース情報グループは、別々のＰＵＣＣＨフォーマットに従ってアレンジされており、それぞれのＰＵＣＣＨフォーマットは、少なくとも１つのリソース情報グループに対応し、それぞれのリソース情報グループは、１つのＰＵＣＣＨリソースの開始アドレス表示情報を含み、第２の表示情報は、ＲＩを含み、ＲＩは、そのＲＩに対応する第２のリソース情報グループをＵＥに示すために使用され、第２の表示情報は、長さインデックスＬＩをさらに含み、ＬＩは、第２のリソース情報グループに対応するＰＵＣＣＨリソースのサイズをＵＥに示すために使用される。

第１の態様、または第１の態様の第１乃至第８の可能な実装形態のうちのいずれか１つを参照して、第１の態様の第９の可能な実装形態においては、基地局によって、第２の表示情報をＵＥへ送信するステップは、基地局によって、スケジュールされているキャリアに従ってＴＰＣフィールドの２つのグループを決定するステップであって、一方のグループは、第２のリソース情報グループに対応するＲＩを送信するために使用され、他方のグループは、第２のリソース情報グループに対応するＰＵＣＣＨリソースのサイズをＵＥに示すＬＩを送信するために使用される、ステップ、または基地局によって、拡張ＴＰＣフィールドを使用することによってＲＩおよびＬＩを送信するステップであって、その拡張ＴＰＣフィールドは、３ビット以上を含む、ステップを含む。

第１の態様、または第１の態様の第１乃至第９の可能な実装形態のうちのいずれか１つを参照して、第１の態様の第１０の可能な実装形態においては、リソースリスト内のそれぞれのリソース情報グループは、１つのＰＵＣＣＨリソースの開始アドレス表示情報およびサイズ表示情報を含み、第２の表示情報は、ＲＩを含み、ＲＩは、そのＲＩに対応する第３のリソース情報グループをＵＥに示すために使用され、第２の表示情報は、フォーマットインデックスＦＩをさらに含み、ＦＩは、第３のリソース情報グループに対応するＰＵＣＣＨリソースのＰＵＣＣＨフォーマットをＵＥに示すために使用される。

第１の態様、または第１の態様の第１乃至第１０の可能な実装形態のうちのいずれか１つを参照して、第１の態様の第１１の可能な実装形態においては、基地局によって、第２の表示情報をＵＥへ送信するステップは、基地局によって、スケジュールされているキャリアに従ってＴＰＣフィールドの２つのグループを決定するステップであって、一方のグループは、第３のリソース情報グループに対応するＲＩを送信するために使用され、他方のグループは、第３のリソース情報グループに対応するＰＵＣＣＨリソースのＰＵＣＣＨフォーマットをＵＥに示すＦＩを送信するために使用される、ステップ、または基地局によって、拡張ＴＰＣフィールドを使用することによってＲＩおよびＦＩを送信するステップであって、その拡張ＴＰＣフィールドは、３ビット以上を含む、ステップを含む。

第１の態様、または第１の態様の第１乃至第１１の可能な実装形態のうちのいずれか１つを参照して、第１の態様の第１２の可能な実装形態においては、リソースリスト内のそれぞれのリソース情報グループは、１つのＰＵＣＣＨリソースの開始アドレス表示情報を含み、第２の表示情報は、ＲＩを含み、ＲＩは、そのＲＩに対応する第４のリソース情報グループをＵＥに示すために使用され、第２の表示情報は、ＦＩおよびＬＩをさらに含み、ＦＩは、第４のリソース情報グループに対応するＰＵＣＣＨリソースのＰＵＣＣＨフォーマットをＵＥに示すために使用され、ＬＩは、第４のリソース情報グループに対応するＰＵＣＣＨリソースのサイズをＵＥに示すために使用される。

第１の態様、または第１の態様の第１乃至第１２の可能な実装形態のうちのいずれか１つを参照して、第１の態様の第１３の可能な実装形態においては、リソースリストは、２つのリソース情報グループを含み、基地局によって、第２の表示情報をＵＥへ送信するステップは、基地局によって、スケジュールされているキャリアに従ってＴＰＣフィールドの２つのグループを決定するステップであって、一方のグループは、第４のリソース情報グループに対応するＲＩと、第４のリソース情報グループに対応するＰＵＣＣＨリソースのＰＵＣＣＨフォーマットをＵＥに示すＦＩとを送信するために使用され、他方のグループは、第４のリソース情報グループに対応するＰＵＣＣＨリソースのサイズをＵＥに示すＬＩを送信するために使用される、ステップを含む。

第１の態様、または第１の態様の第１乃至第１３の可能な実装形態のうちのいずれか１つを参照して、第１の態様の第１４の可能な実装形態においては、基地局によって、スケジュールされているキャリアに従ってＴＰＣフィールドの２つのグループを決定するステップは、基地局によって、スケジュールされているキャリアの識別番号の順序に従って、スケジュールされているキャリアを２つのグループへとグループ化するステップと、スケジュールされているキャリアの２つのグループのそれぞれの上のＴＰＣフィールドをＴＰＣフィールドの一方のグループとして決定するステップとを含む。

第１の態様、または第１の態様の第１乃至第１４の可能な実装形態のうちのいずれか１つを参照して、第１の態様の第１５の可能な実装形態においては、スケジュールされているキャリアは、奇数である識別番号を有するスケジュールされているキャリアと、偶数である識別番号を有するスケジュールされているキャリアとを含み、基地局によって、スケジュールされているキャリアに従ってＴＰＣフィールドの２つのグループを決定するステップは、スケジュールされているキャリアのうちで奇数である識別番号を有するスケジュールされているキャリア上のＴＰＣフィールドをＴＰＣフィールドの一方のグループとして決定するステップと、スケジュールされているキャリアのうちで偶数である識別番号を有するスケジュールされているキャリア上のＴＰＣフィールドをＴＰＣフィールドの他方のグループとして決定するステップとを含む。

第２の態様によれば、キャリアアグリゲーションにおけるアップリンクコントロール情報送信装置であって、
第１の表示情報をユーザ機器ＵＥへ送信するステップであって、第１の表示情報は、その第１の表示情報に従ってアップリンクコントロール情報ＵＣＩを動的に決定するようＵＥに指示するために使用される、ステップを行うように構成されている第１の送信モジュールと、
ＰＵＣＣＨリソースをＵＥへ割り振るステップであって、そのＰＵＣＣＨリソースは、ＵＣＩを送信するために使用される、ステップを行うように構成されているリソース割り振りモジュールとを含む装置が提供される。

第２の態様の実装形態を参照して、第２の態様の第１の可能な実装形態においては、第１の表示情報は、第１のタイプの表示情報または第２のタイプの表示情報であり、第１のタイプの表示情報は、スケジュールされているキャリアの数量に従って基地局がダウンリンク割り当てインデックスＤＡＩ情報を生成する場合に、第１のタイプの表示情報に従ってＵＣＩを決定するようＵＥに指示するために使用され、第２のタイプの表示情報は、スケジュールされているコードワードの数量に従って基地局がＤＡＩ情報を生成する場合に、第２のタイプの表示情報に従ってＵＣＩを決定するようＵＥに指示するために使用される。

第２の態様、または第２の態様の第１の可能な実装形態を参照して、第２の態様の第２の可能な実装形態においては、第１の送信モジュールは、第１の構成情報をＵＥへ送信するステップであって、第１の構成情報は、第１の表示情報を含む、ステップを行うように特に構成されている。

第２の態様、または第２の態様の第１もしくは第２の可能な実装形態のうちのいずれか１つを参照して、第２の態様の第３の可能な実装形態においては、第１の送信モジュールは、ダウンリンクコントロール情報ＤＣＩをＵＥへ送信するステップであって、ＤＣＩは、第１の表示情報を含む、ステップを行うように特に構成されている。

第２の態様、または第２の態様の第１乃至第３の可能な実装形態のうちのいずれか１つを参照して、第２の態様の第４の可能な実装形態においては、第１の送信モジュールは、第１の様式でエンコードされているＤＣＩをＵＥへ送信するステップであって、第１の様式は、第１のタイプの表示情報に対応し、第１の様式においては、ＤＣＩエンコーディング中に生成される巡回冗長検査ＣＲＣコードにスクランブリングコードが付加されない、ステップ、または第２の様式でエンコードされているＤＣＩをＵＥへ送信するステップであって、第２の様式は、第２のタイプの表示情報に対応し、第２の様式においては、ＤＣＩエンコーディング中に生成されるＣＲＣコードにスクランブリングコードが付加される、ステップを行うように特に構成されている。

第２の態様、または第２の態様の第１乃至第４の可能な実装形態のうちのいずれか１つを参照して、第２の態様の第５の可能な実装形態においては、リソース割り振りモジュールは、構成モジュール、表示モジュール、および第２の送信モジュールを含み、構成モジュールは、第２の構成情報を生成するように構成されており、第２の構成情報は、ＵＥ用のリソースリストを構成するために使用され、そのリソースリストは、複数のリソース情報グループを含み、表示モジュールは、第２の表示情報を生成するように構成されており、第２の表示情報は、リソースリスト内の１つのリソース情報グループに対応するＰＵＣＣＨリソースをＵＥに示すために使用され、第２の送信モジュールは、第２の構成情報および第２の表示情報をＵＥへ送信するように構成されている。

第２の態様、または第２の態様の第１乃至第５の可能な実装形態のうちのいずれか１つを参照して、第２の態様の第６の可能な実装形態においては、複数のリソース情報グループは、別々のＰＵＣＣＨフォーマットに従ってアレンジされており、それぞれのＰＵＣＣＨフォーマットは、少なくとも１つのリソース情報グループに対応し、それぞれのリソース情報グループは、１つのＰＵＣＣＨリソースの開始アドレス表示情報およびサイズ表示情報を含み、第２の表示情報は、リソースインデックスＲＩを含み、ＲＩは、そのＲＩに対応する第１のリソース情報グループをＵＥに示すために使用される。

第２の態様、または第２の態様の第１乃至第６の可能な実装形態のうちのいずれか１つを参照して、第２の態様の第７の可能な実装形態においては、第２の送信モジュールは、送信電力コントロールＴＰＣフィールドを使用することによって第２の表示情報、すなわち、第１のリソース情報グループに対応するＲＩを送信するステップを行うように特に構成されている。

第２の態様、または第２の態様の第１乃至第７の可能な実装形態のうちのいずれか１つを参照して、第２の態様の第８の可能な実装形態においては、複数のリソース情報グループは、別々のＰＵＣＣＨフォーマットに従ってアレンジされており、それぞれのＰＵＣＣＨフォーマットは、少なくとも１つのリソース情報グループに対応し、それぞれのリソース情報グループは、１つのＰＵＣＣＨリソースの開始アドレス表示情報を含み、第２の表示情報は、ＲＩを含み、ＲＩは、そのＲＩに対応する第２のリソース情報グループをＵＥに示すために使用され、第２の表示情報は、長さインデックスＬＩをさらに含み、ＬＩは、第２のリソース情報グループに対応するＰＵＣＣＨリソースのサイズをＵＥに示すために使用される。

第２の態様、または第２の態様の第１乃至第８の可能な実装形態のうちのいずれか１つを参照して、第２の態様の第９の可能な実装形態においては、第２の送信モジュールは、スケジュールされているキャリアに従ってＴＰＣフィールドの２つのグループを決定するステップであって、一方のグループは、第２のリソース情報グループに対応するＲＩを送信するために使用され、他方のグループは、第２のリソース情報グループに対応するＰＵＣＣＨリソースのサイズをＵＥに示すＬＩを送信するために使用される、ステップ、または拡張ＴＰＣフィールドを使用することによってＲＩおよびＬＩを送信するステップであって、その拡張ＴＰＣフィールドは、３ビット以上を含む、ステップを行うように特に構成されている。

第２の態様、または第２の態様の第１乃至第９の可能な実装形態のうちのいずれか１つを参照して、第２の態様の第１０の可能な実装形態においては、リソースリスト内のそれぞれのリソース情報グループは、１つのＰＵＣＣＨリソースの開始アドレス表示情報およびサイズ表示情報を含み、第２の表示情報は、ＲＩを含み、ＲＩは、そのＲＩに対応する第３のリソース情報グループをＵＥに示すために使用され、第２の表示情報は、フォーマットインデックスＦＩをさらに含み、ＦＩは、第３のリソース情報グループに対応するＰＵＣＣＨリソースのＰＵＣＣＨフォーマットをＵＥに示すために使用される。

第２の態様、または第２の態様の第１乃至第１０の可能な実装形態のうちのいずれか１つを参照して、第２の態様の第１１の可能な実装形態においては、第２の送信モジュールは、スケジュールされているキャリアに従ってＴＰＣフィールドの２つのグループを決定するステップであって、一方のグループは、第３のリソース情報グループに対応するＲＩを送信するために使用され、他方のグループは、第３のリソース情報グループに対応するＰＵＣＣＨリソースのＰＵＣＣＨフォーマットをＵＥに示すＦＩを送信するために使用される、ステップ、または拡張ＴＰＣフィールドを使用することによってＲＩおよびＦＩを送信するステップであって、その拡張ＴＰＣフィールドは、３ビット以上を含む、ステップを行うように特に構成されている。

第２の態様、または第２の態様の第１乃至第１１の可能な実装形態のうちのいずれか１つを参照して、第２の態様の第１２の可能な実装形態においては、リソースリスト内のそれぞれのリソース情報グループは、１つのＰＵＣＣＨリソースの開始アドレス表示情報を含み、第２の表示情報は、ＲＩを含み、ＲＩは、そのＲＩに対応する第４のリソース情報グループをＵＥに示すために使用され、第２の表示情報は、ＦＩおよびＬＩをさらに含み、ＦＩは、第４のリソース情報グループに対応するＰＵＣＣＨリソースのＰＵＣＣＨフォーマットをＵＥに示すために使用され、ＬＩは、第４のリソース情報グループに対応するＰＵＣＣＨリソースのサイズをＵＥに示すために使用される。

第２の態様、または第２の態様の第１乃至第１２の可能な実装形態のうちのいずれか１つを参照して、第２の態様の第１３の可能な実装形態においては、リソースリストは、２つのリソース情報グループを含み、第２の送信モジュールは、スケジュールされているキャリアに従ってＴＰＣフィールドの２つのグループを決定するステップであって、一方のグループは、第４のリソース情報グループに対応するＲＩと、第４のリソース情報グループに対応するＰＵＣＣＨリソースのＰＵＣＣＨフォーマットをＵＥに示すＦＩとを送信するために使用され、他方のグループは、第４のリソース情報グループに対応するＰＵＣＣＨリソースのサイズをＵＥに示すＬＩを送信するために使用される、ステップを行うように特に構成されている。

第２の態様、または第２の態様の第１乃至第１３の可能な実装形態のうちのいずれか１つを参照して、第２の態様の第１４の可能な実装形態においては、第２の送信モジュールは、スケジュールされているキャリアの識別番号の順序に従って、スケジュールされているキャリアを２つのグループへとグループ化するステップと、スケジュールされているキャリアの２つのグループのそれぞれの上のＴＰＣフィールドをＴＰＣフィールドの一方のグループとして決定するステップとを行うように特に構成されている。

第２の態様、または第２の態様の第１乃至第１４の可能な実装形態のうちのいずれか１つを参照して、第２の態様の第１５の可能な実装形態においては、スケジュールされているキャリアは、奇数である識別番号を有するスケジュールされているキャリアと、偶数である識別番号を有するスケジュールされているキャリアとを含み、第２の送信モジュールは、スケジュールされているキャリアのうちで奇数である識別番号を有するスケジュールされているキャリア上のＴＰＣフィールドをＴＰＣフィールドの一方のグループとして決定するステップと、スケジュールされているキャリアのうちで偶数である識別番号を有するスケジュールされているキャリア上のＴＰＣフィールドをＴＰＣフィールドの他方のグループとして決定するステップとを行うように特に構成されている。

本発明の実施形態において提供されているキャリアアグリゲーションにおけるアップリンクコントロール情報送信方法および装置によれば、基地局は、第１の表示情報をユーザ機器ＵＥへ送信して、その第１の表示情報に従ってアップリンクコントロール情報ＵＣＩを動的に決定するようＵＥに指示し、基地局は、ＵＣＩを送信するためにＰＵＣＣＨリソースをＵＥへ割り振る。本発明の実施形態は、キャリアアグリゲーションシナリオにおけるＵＣＩ情報のフィードバックを実施し、それによって、有効なＵＣＩ情報を送信することのパフォーマンスを改善するために使用され得る。

本発明の実施形態における、または従来技術における技術的なソリューションについてより明確に記述するために、以降では、それらの実施形態または従来技術について記述するために必要とされる添付の図面について簡単に記述する。明らかに、以降の説明における添付の図面は、本発明のいくつかの実施形態を示しているにすぎず、当技術分野における標準的な技術者なら、それでもなお、創造的な取り組みを伴わずにこれらの添付の図面からその他の図面を導き出し得る。
関連した技術によるＬＴＥ−ＡシステムにおけるＦＤＤモードでのＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報のコードブックを決定することの概略図である。 スケジュールされているキャリアの数量に従ってＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報のコードブックを動的に決定することの概略図である。 スケジュールされているＣＷの数量に従ってＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報のコードブックを動的に決定することの概略図である。 図３において示されているソリューションに従って空間バンドリング処理を実行することの概略図である。 図３において示されているソリューションに従って空間バンドリング処理を実行することの概略図である。 本発明の実施形態による、キャリアアグリゲーションにおけるアップリンクコントロール情報送信方法のフローチャートである。 関連した技術によるＬＴＥ−ＡシステムにおけるＦＤＤモードでのＡＲＩインジケータの概略図である。 関連した技術によるＬＴＥ−ＡシステムにおけるＴＤＤモードでのＡＲＩインジケータの概略図である。 本発明の実施形態による、キャリアアグリゲーションにおけるＰＵＣＣＨリソース割り振り方法のフローチャートである。 ＲＲＣ構成シグナリングを使用することによってＵＥ用に構成されている第１のＰＵＣＣＨリソースリストの概略図である。 ＲＲＣ構成シグナリングを使用することによってＵＥ用に構成されている第２のＰＵＣＣＨリソースリストの概略図である。 ＲＲＣ構成シグナリングを使用することによってＵＥ用に構成されている第３のＰＵＣＣＨリソースリストの概略図である。 ＲＲＣ構成シグナリングを使用することによってＵＥ用に構成されている第４のＰＵＣＣＨリソースリストの概略図である。 ＲＲＣ構成シグナリングを使用することによってＵＥ用に構成されている第５のＰＵＣＣＨリソースリストの概略図である。 ＦＤＤモードにおけるキャリアスケジューリングの概略図である。 ＴＤＤモードにおけるキャリアスケジューリングの概略図である。 本発明の実施形態による、キャリアアグリゲーションにおけるアップリンクコントロール情報送信装置の概略図である。 本発明の実施形態による、キャリアアグリゲーションにおける別のアップリンクコントロール情報送信装置の概略図である。 本発明の実施形態による基地局の概略図である。

以降では、本発明の実施形態における添付の図面を参照しながら、本発明の実施形態における技術的なソリューションについて明確にかつ完全に記述する。明らかに、記述されている実施形態は、本発明の実施形態のうちのいくつかにすぎず、すべてではない。当技術分野における標準的な技術者によって本発明の実施形態に基づいて創造的な取り組みを伴わずに入手されるその他のすべての実施形態は、本発明の保護範囲内に収まるものとする。

本発明の実施形態においては、「第１の」、「第２の」などの用語は、類似しているオブジェクトどうしの間において区別を行うことを意図されているが、必ずしも特定の順序を示しているとは限らない。そのような方法で呼ばれているデータは、適切な状況において交換可能であり、それによって、本明細書において記述されている本発明の実施形態は、本明細書において示されているまたは記述されている順序以外の順序で実施されることが可能であるということを理解されたい。

本発明の実施形態は、ＬＴＥ−ＡにおけるＣＡまたはｅＣＡシナリオにおけるＵＣＩ情報のフィードバックに適用される。ＬＴＥ−Ａにおいては、基地局が、より高いレイヤのシグナリング、たとえば、無線リソースコントロール（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ、略してＲＲＣ）シグナリングを使用することによって、複数のＣＣ上でダウンリンクデータを受信するようにＵＥを構成する。それに対応して、ＵＥは、複数のＣＣ上で送信されたダウンリンクデータのＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報をフィードバックする必要がある。より高いレイヤのシグナリングを使用することによって基地局によって構成されている複数のダウンリンクＣＣのうちの１つが、プライマリーＣＣ（Ｐｒｉｍａｒｙ ＣＣ、略してＰＣＣ）であり、またはプライマリーセルＰｒｉｍａｒｙ ｃｅｌｌ、略してＰＣｅｌｌと呼ばれることがあり、別のＣＣが、セカンダリーＣＣ（Ｓｅｃｏｎｄａｒｙ ＣＣ、略してＳＣＣ）と呼ばれ、またはセカンダリーセルＳｅｃｏｎｄａｒｙ ｃｅｌｌ、略してＳＣｅｌｌと呼ばれることがある。ＵＥは、基地局によって割り振られたＰＵＣＣＨリソースを使用することによって、複数のＣＣのＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報をフィードバックする。

ＣＡシナリオにおいては、ＰＤＳＣＨデータがＳＣＣ上で送信される場合には、ＰＵＣＣＨフォーマット３を使用することによってＰＵＣＣＨ送信が実行される。準静的な構成と動的な表示とのハイブリッド方法を使用することによって、ＰＵＣＣＨリソースが割り振られる。すなわち、いくつかのＰＵＣＣＨフォーマット３リソースが、ＲＲＣ構成シグナリングを使用することによってＵＥ用に明示的に構成されることがあり、次いで、複数のＳＣＣ（少なくとも１つのＳＣＣ）の物理ダウンリンクコントロールチャネル（Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ、略してＰＤＣＣＨ）上で送信されるダウンリンクコントロール情報（Ｄｏｗｎｌｉｎｋ ｃｏｎｔｒｏｌ ｉｎｆｏｒｍａｔｉｏｎ、略してＤＣＩ）内の送信電力コントロール（Ｔｒａｎｓｍｉｔ Ｐｏｗｅｒ Ｃｏｎｔｒｏｌ、略してＴＰＣ）フィールドの値が、実際に使用されるＰＵＣＣＨフォーマット３リソースを示すために使用される（このケースにおいては、表示情報は、ＨＡＲＱ−ＡＣＫ／ＮＡＣＫ Ｒｅｓｏｕｒｃｅ Ｉｎｄｉｃａｔｏｒ、略してＡＲＩと呼ばれる）。表示情報は、ＲＲＣを使用することによって構成されているそれらのいくつかのリソースのうちの１つをユーザ機器に示す。本発明の実施形態において解決されることになる技術的な問題をより明確に理解するために、以降では、下記の例を使用することによって、既存のプロトコルにおけるキャリアアグリゲーションシナリオにおけるＵＣＩ情報のフィードバックについて記述する。

図１は、関連した技術によるＬＴＥ−ＡシステムにおけるＦＤＤモードでのＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報のコードブックを決定することの概略図である。図１を参照すると、基地局が、より高いレイヤのシグナリングを使用することによってＵＥ用に５つのキャリアを構成しており、それらの５つのキャリアに対応する送信モード（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｍｏｄｅ、略してＴＭ）によってサポートされる最大の送信されるコードワード（Ｃｏｄｅｗｏｒｄ、略してＣＷ）の数量は、順に２、１、２、２、および１である。スケジュールされているキャリアは、ＣＣ１、ＣＣ３、およびＣＣ５である。ＵＥは、ＣＣ１およびＣＣ３上でＤＣＩ情報を正しく受信しており、ＣＣ１上で送信された２つのＣＷ、およびＣＣ３上で送信された１つのＣＷを正しくデコードしているが、ＣＣ５上で送信されたＤＣＩ情報を正しく受信していない。したがってＵＥは、ＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報のコードブックが「１１０１００００」であるということを決定することができ、「１」に対応する情報はＡＣＫであり、「０」に対応する情報はＮＡＣＫである。既存のプロトコルにおけるＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報のサイズおよびランキングが、構成されているキャリアの数量、ならびにそれぞれの構成されているキャリアのＴＭに対応する最大コードワード数量およびキャリア番号に従って決定されるということが知られ得る。この方法においては、スケジュールされていない（すなわち、データ送信のために実際に使用されていない）構成されているキャリアがある場合、またはキャリア上で送信されるコードワードの数量が最大構成に達していない場合には、ＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報は、やはりいくつかの無用なビットを埋め込まれる。

ｅＣＡは、２０１５年１月に３ＧＰＰによって提供されたワイヤレスＬＴＥキャリアアグリゲーションエンハンスメントビヨンド５キャリア（ＷＩ ＬＴＥ Ｃａｒｒｉｅｒ Ａｇｇｒｅｇａｔｉｏｎ Ｅｎｈａｎｃｅｍｅｎｔ Ｂｅｙｏｎｄ ５ Ｃａｒｒｉｅｒｓ）の略称であり、アグリゲートされることが可能であるキャリアの数量が大幅に増大されるということを示し、最大で３２個のキャリアがアグリゲートされることを必要とする。ｅＣＡシナリオにおいては、より多くの構成されているキャリアがあり、最大で３２個の構成されているキャリアが存在し得る。既存のプロトコルにおける方法に従ってＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報が決定される場合には、ＨＡＲＱフィードバック情報の必要とされるコードブックがきわめて大きくなり得る。たとえば、３２個の構成されているキャリアに関しては、最大で６３８ビットがフィードバックされることになる。加えて、ｅＣＡシナリオにおいては、複数のＣＣのＣＳＩ情報が１つのサブフレームにおいてフィードバックされることが可能であることがさらに必要とされる。ＣＳＩ情報およびＨＡＲＱフィードバック情報が、同じサブフレームにおいて送信される必要がある場合には、ＵＣＩ情報のサイズがさらに増大される。簡単にするために、本発明の実施形態においては、ＨＡＲＱフィードバック情報のみが、例として使用されている。

ＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報のコードブックを決定した後に、ＵＥは、基地局によって割り振られたＰＵＣＣＨリソースを使用することによって、ＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報を基地局へ送信する必要がある。

現在のＬＴＥプロトコルは、３つのタイプの合計で７つのＰＵＣＣＨフォーマットを定義しており、別々のＰＵＣＣＨフォーマットは、別々のＵＣＩ情報コンテンツを搬送し、ＵＥは、送信される必要がある情報に従ってＰＵＣＣＨフォーマットを選ぶ。第１のタイプは、フォーマットｌｘであり、フォーマットｌ、フォーマットｌａ、およびフォーマットｌｂを含み、ＳＲ情報、またはＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報、またはＳＲ情報およびＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報を搬送する。第２のタイプは、フォーマット２ｘであり、フォーマット２、フォーマット２ａ、およびフォーマット２ｂを含み、ＣＳＩ、またはＣＳＩおよびＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報を搬送する。第３のタイプは、フォーマット３であり、キャリアアグリゲーション（Ｃａｒｒｉｅｒ Ａｇｇｒｅｇａｔｉｏｎ、略してＣＡ）におけるマルチＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報、および任意選択のＳＲ情報またはＣＳＩ情報を搬送するために使用される。前述の７つのＰＵＣＣＨフォーマットのうちでそのＰＵＣＣＨフォーマットによって搬送されることが可能であるビットの数量が最も多く、最大で２２である。最大で３２個のキャリアが構成されている場合にフィードバックされる必要があり得る６３９ビットのＨＡＲＱフィードバック情報の要件を満たすことは不可能である。

これを考慮して、標準についての現在の論議のさなかに、新たなＰＵＣＣＨフォーマットのための複数の候補が提供されている。新たなＰＵＣＣＨフォーマットのための候補は、ＰＵＳＣＨベースのフォーマット、マルチＰＲＢ ＰＦ３（ＰＵＣＣＨフォーマット３）、リデューストＯＣＣ ＰＦ３、およびマルチリソースＰＦ３を含む。しかしながら、現在では、新たな利用可能なＰＵＣＣＨフォーマットによってサポートされる必要がある最大の搬送されるビットの数量は、１２８、２５６、３１９、または６３８であり得る。最終的に選択された新たなＰＵＣＣＨフォーマットによって搬送されることが可能であるビットの最大数量が６３８未満である場合には、そのフォーマットは依然として、すべてのＨＡＲＱフィードバック情報を送信するために搬送される必要があるビットの数量の要件を満たすことができない。ＨＡＲＱフィードバック情報のコードブックを決定するための方法が変更されていない場合には、たとえ新たなＰＵＣＣＨフォーマットを使用することによってＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報が送信されても、データ送信負荷が低減されることは不可能であり、有効な情報をフィードバックすることの送信パフォーマンスに影響を与える。

ＰＵＣＣＨフォーマットによって搬送されることが可能であるビットの数量は、制限されている。したがって既存のプロトコルは、ＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報のビットの数量を減らすためにＨＡＲＱフィードバック情報をバンドルするための処理方法を提供している。具体的には、２つのコードワードが送信されるＣＣに関しては、そのＣＣ上で同じダウンリンクサブフレームにおいて送信されるそれらの２つのＣＷに対応するＡＣＫ／ＮＡＣＫ情報に対してＡＮＤ論理演算が実行されて１ビットのＡＣＫ／ＮＡＣＫ情報を入手し得る。このプロトコルにおいては、これは、「空間ＨＡＲＱ−ＡＣＫ／ＮＡＣＫバンドリング」処理、すなわち、ＨＡＲＱフィードバック情報の空間バンドリングと呼ばれる。

標準についての現在の論議においては、ｅＣＡにおけるＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報のコードブックは、スケジュールされているキャリアに従って動的に決定されるということが合意されている。すなわち、ＨＡＲＱ情報をフィードバックするための、サブフレームにおけるＨＡＲＱコードブック（サイズおよびランキングを含む）は、スケジューリングケースに従ってさまざまであり得る。

図２は、スケジュールされているキャリアの数量に従ってＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報のコードブックを動的に決定することの概略図である。これは、以降では第１のソリューションと呼ばれる。このソリューションにおいては、キャリア上のＤＣＩ情報は、スケジュールされているキャリアの数（スケジュールされているキャリアの累積された数量とも呼ばれる）を示すために使用されるカウンタＣＣ（ｃｏｕｎｔｅｒ ＣＣ）値を含む。スケジュールされているキャリアの数量は、送信されるダウンリンクＤＣＩの断片の数量、およびダウンリンクＰＤＳＣＨの数量と整合している。したがってカウンタＣＣ値は、ＤＣＩの断片の累積された数量、またはＰＤＳＣＨの累積された数量も表し得る。カウンタＣＣ値に関する情報は、ダウンリンク割り当てのために使用されるＤＣＩ情報内に含まれる。加えて、合計ＣＣ（ｔｏｔａｌ ＣＣ）値が、サブフレームにおけるすべてのスケジュールされているキャリアの合計数量を表す。この値は、ダウンリンク割り当てのために使用されるＤＣＩ情報内に含まれることがあり、または別の様式で示されることがある。本明細書においては、この値が、ダウンリンク割り当てのために使用されるＤＣＩ内に含まれることは、限定ではなく、例として使用されているにすぎない。図において示されている例においては、基地局が、より高いレイヤのシグナリングを使用することによってＵＥ用に１０個のキャリアを構成しており、ＣＣ１、ＣＣ３、ＣＣ６、およびＣＣ１０が、スケジュールされているキャリアである。加えて、ＵＥは、ＣＣ１およびＣＣ６上でＤＣＩ情報を正しく受信しており、ＣＣ１のカウンタＣＣ値が１であるということ、およびＣＣ６のカウンタＣＣ値が３であるということを知り、ＣＣ１およびＣＣ６の両方の合計ＣＣ値が４であるということを知り、スケジュールされているＰＤＳＣＨから、ＣＣ１およびＣＣ６のそれぞれの上で送信された２つのＣＷを正しくデコードしているが、ＣＣ３およびＣＣ１０上でＤＣＩ情報を正しく受信していない。このソリューションにおいては、ＤＣＩ情報が失われているキャリア上でフィードバックされるＨＡＲＱビットの数量と、ＤＣＩ情報が失われていないキャリア上でフィードバックされるＨＡＲＱビットの数量との間における整合性を保つために、それぞれのＣＣ上で２つのコードワードが送信されるすべてのＣＣ上のＨＡＲＱフィードバック情報に対して空間バンドリングが実行される。ＣＣ１およびＣＣ６の両方のキャリア上のＨＡＱＲフィードバック情報のバンドリング結果が１である場合には、ＵＥは、ＣＣ１およびＣＣ６のカウンタ値に従って、２片のバンドルされたＨＡＲＱフィードバック情報がそれぞれ第１のビットロケーションおよび第３のビットロケーション上に配置されるということを決定することがあり、合計ＣＣ値４に従って、ＨＡＲＱフィードバック情報の合計長さが４ビットであるということを知ることがあり、それによって、ＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報のコードブックが「１０１０」であるということを決定する。

図２において示されている第１のソリューションにおいては、スケジュールされているＣＷの累積された数量が、ＤＣＩ内のカウンタＣＣ値に関する情報を使用することによって知られることが不可能であり、ＤＣＩが失われているＣＣ上で送信されるＣＷの数量が決定されることが不可能であるので、２つのＣＷを含むスケジュールされているキャリア上のＨＡＲＱフィードバック情報に対してデフォルトで空間バンドリングが実行されるということが知られ得る。スケジュールされているキャリア上で送信された２つのＣＷのどちらかがＵＥによって成功裏にデコードされそこなった場合には、ＵＥは、ＮＡＣＫ情報を基地局へフィードバックする。ＵＥによってフィードバックされたＮＡＣＫ情報を受信した後に、基地局は、ダウンリンクサブフレームにおいてＣＷのうちの両方が送信されそこなったとみなし、ダウンリンクサブフレームにおいてそれらの２つのＣＷを再送信する。これは、いくつかの不要な再送信をもたらし、ダウンリンクスループットパフォーマンスに影響を与える。

図３は、スケジュールされているＣＷの数量に従ってＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報のコードブックを動的に決定することの概略図である。これは、以降では第２のソリューションと呼ばれる。このソリューションにおいては、キャリア上のＤＣＩ情報は、スケジュールされているＣＷの数（スケジュールされているＣＷの累積された数量とも呼ばれる）を示すために使用されるカウンタＣＷ（ｃｏｕｎｔｅｒ ＣＷ）値に関する情報を含む。２つのＣＷがスケジュールされているキャリアに関しては、そのキャリアのカウンタＣＷ値が、第２のスケジュールされているＣＷの数を反映し、その数がＵＥによって正しく受信された後に、第１のＣＷの数もデフォルトで正しく受信されるということに留意されたい。カウンタＣＷ値に関する情報は、ダウンリンク割り当てのために使用されるＤＣＩ情報内に含まれる。加えて、合計ＣＷ（ｔｏｔａｌ ＣＷ）値に関する情報が、サブフレームにおけるすべてのスケジュールされているＣＷの合計数量を表す。この値は、ダウンリンク割り当てのために使用されるＤＣＩ情報内に含まれることがあり、または別の様式で示されることがある。本明細書においては、この値が、ダウンリンク割り当てのために使用されるＤＣＩ内に含まれることは、限定ではなく、例として使用されているにすぎない。図において示されている例においては、基地局が、より高いレイヤのシグナリングを使用することによってＵＥ用に１０個のキャリアを構成しており、ＣＣ１、ＣＣ３、ＣＣ６、およびＣＣ１０が、スケジュールされているキャリアである。加えて、ＵＥは、ＣＣ１およびＣＣ６上でＤＣＩ情報を正しく受信しており、ＣＣ１のカウンタＣＷ値が２であり、ＣＣ６のカウンタＣＷ値が５であるということを知り、ＣＣ１およびＣＣ６の両方の合計ＣＣ値が６であるということを知り、スケジュールされているＰＤＳＣＨから、ＣＣ１上で送信された２つのＣＷおよびＣＣ６上で送信された第１のＣＷを正しくデコードしているが、ＣＣ３およびＣＣ１０上でＤＣＩ情報を正しく受信していない。このケースにおいては、ＣＣ１のカウンタＣＷ値２と、ＤＣＩを復調することによって入手された、そのキャリア上で２つのＣＷがスケジュールされているという情報とに従って、ＵＥは、ＣＣ１がさらに、カウンタＣＣ値が１であるＨＡＲＱフィードバック情報に対応するということを推測することができる。次いで、ＨＡＲＱフィードバックコードブック全体の中でのＣＣ１上のＨＡＲＱフィードバック情報のロケーション（ランキングとも呼ばれる）が、第１のビットロケーションおよび第２のビットロケーションであり、コードワードのうちの両方が正しくデコードされているので、ＨＡＲＱフィードバック情報は「１１」である。同様に、ＨＡＲＱフィードバックコードブック全体の中でのＣＣ６上のＨＡＲＱフィードバック情報のロケーション（ランキングとも呼ばれる）が、第４のビットロケーションおよび第５のビットロケーションであり、第１のＣＷのみが正しくデコードされており、第２のＣＷがデコードされそこなっているので、ＨＡＲＱフィードバック情報は「１０」であることが知られ得る。加えてＵＥは、受信された合計ＣＷ値６に従って、ＨＡＲＱフィードバックコードブックのビットの合計数量が６であるということを決定し得る。したがってＵＥは、ＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報のコードブックが「１１０１００」であるということを最終的に決定する。

最後に、第１のソリューションにおけるカウンタＣＣ値および合計ＣＣ値、ならびに第２のソリューションにおけるカウンタＣＷ値および合計ＣＷ値は、キャリアドメイン（ｃｅｌｌ−ｄｏｍａｉｎ）または周波数ドメイン（ｆｒｅｑｕｅｎｃｙ−ｄｏｍａｉｎ）におけるダウンリンク割り当てインデックス（Ｄｏｗｎｌｉｎｋ Ａｓｓｉｇｎｍｅｎｔ Ｉｎｄｅｘ、略してＤＡＩ）情報と呼ばれることがある。第１のソリューションにおいては、基地局は、スケジュールされているキャリアを使用することによってＤＡＩ情報を生成する。第２のソリューションにおいては、基地局は、スケジュールされているコードワードを使用することによってＤＡＩ情報を生成する。

図３において示されている第２のソリューションにおいては、空間バンドリング処理がさらにＨＡＲＱフィードバック情報に対して実行される必要がある場合には、ＵＥは、ＨＡＲＱフィードバック情報のコードブックサイズに関して不確かであることがあり、したがって基地局およびＵＥは、ＨＡＲＱフィードバックコードブックについての不整合な理解を有する。詳細に関しては、図４Ａおよび図４Ｂにおいて示されている２つのケースを参照されたい。複数のコードワードが失われている場合には、ＵＥは、ＣＣ１およびＣＣ６のカウンタＣＷ値に関する受信された情報を使用することによって、２つのキャリアのそれぞれの上の１つのＣＷ（すなわち、図４ＡにおけるＣＣ２およびＣＣ３のそれぞれの上の１つのＣＷ）が失われているのか、または１つのキャリア上の２つのＣＷ（すなわち、図４ＢにおけるＣＣ４上の２つのＣＷ）が失われているのかを決定することができない。したがって、第２のソリューションにおける空間バンドリング中に、バンドルされるビットの数量が決定されることが不可能であり、５ビット（図４Ａ）または４ビット（図４Ｂ）があり得る。しかしながら、このケースにおいては、基地局はスケジューリングケースを明確に知る。ＵＥは、バンドルされるＨＡＲＱフィードバック情報のビットの数量に関して不確かであるので、フィードバックビットの数量が実際のケースと不整合であることがあり、すなわち、基地局およびＵＥは、ＨＡＲＱフィードバックコードブックについての不整合な理解を有し、ＵＥは、ＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報を正確に送信することができない。

これを考慮して、本発明の実施形態は、キャリアアグリゲーションにおけるＵＣＩ送信方法を提供する。基地局が、表示情報をＵＥへ送信し、それによってＵＥは、その表示情報に従って、ＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報のコードブックを決定する様式を選択する。

本発明の下記の実施形態において提供されている、キャリアアグリゲーションにおけるアップリンクコントロール情報送信方法は、基地局によって実行される。

図５は、本発明の実施形態による、キャリアアグリゲーションにおけるアップリンクコントロール情報送信方法のフローチャートである。図５において示されているように、この実施形態において提供されている、キャリアアグリゲーションにおけるアップリンクコントロール情報送信方法は、下記のステップを含み得る。

Ｓ５１． 基地局が、第１の表示情報をＵＥへ送信し、第１の表示情報は、その第１の表示情報に従ってＵＣＩを動的に決定するようＵＥに指示するために使用される。

本明細書における動的な決定は、ＵＣＩをフィードバックするための、それぞれのサブフレームにおけるＵＣＩ情報、特にＨＡＲＱフィードバック情報のコードブックが、実際にスケジュールされているキャリアまたはコードワードのケースに従ってさまざまであり得るということを意味する。

Ｓ５２． 基地局は、ＰＵＣＣＨリソースをＵＥへ割り振り、そのＰＵＣＣＨリソースは、ＵＣＩを送信するために使用される。

この実施形態においては、第１の表示情報は、特に第１のタイプの表示情報または第２のタイプの表示情報であり得る。第１の表示情報が第１のタイプの表示情報である場合には、ＵＥは、スケジュールされているキャリアの数量に従って基地局がＤＡＩ情報を生成する場合に、第１のタイプの表示情報に従ってＵＣＩを決定する。第１の表示情報が第２のタイプの表示情報である場合には、ＵＥは、スケジュールされているコードワードの数量に従って基地局がＤＡＩ情報を生成する場合に、第２のタイプの表示情報に従ってＵＣＩを決定する。本明細書におけるＤＡＩ情報は、図２において示されている第１のソリューションにおけるカウンタＣＣ値および図３において示されている第２のソリューションにおけるカウンタＣＷ値に関する情報を含むということに留意されたい。加えて、ＤＡＩ情報は、第１のソリューションにおける合計ＣＣ値に関する情報、および図３において示されている第２のソリューションにおける合計ＣＷ値に関する情報をさらに含み得る。これは、本明細書においては限定されない。

基地局は、現在のスケジューリングケースに従って生成されるべきＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報のビットの数量を明確に知り、ＰＵＣＣＨ送信のために使用される新たなＰＵＣＣＨフォーマットによって搬送されるビットの表示されることになる最大数量を明確に知るということに留意されたい。したがって基地局は、現在のスケジューリングに関して実際にフィードバックされる必要があるＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報のビットの数量と、新たなＰＵＣＣＨフォーマットによって搬送されるビットの最大数量との間における関係に従って、ダウンリンク割り当てインデックス（Ｄｏｗｎｌｉｎｋ Ａｓｓｉｇｎｍｅｎｔ Ｉｎｄｅｘ、略してＤＡＩ）情報の送信様式を選択し得る。

具体的には、フィードバックされる必要があるＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報のビットの数量が、ＰＵＣＣＨ送信のために使用される新たなＰＵＣＣＨフォーマットによって搬送されるビットの最大数量よりも多い場合には、基地局は、スケジュールされているキャリアの数量に従ってＤＡＩ情報を生成し、表示情報（第１のタイプの表示情報と呼ばれることがある）を使用することによってＤＡＩの生成様式をＵＥに通知し、ＵＥは、基地局によって送信される表示情報に従って、ＨＡＲＱフィードバック情報に対して空間バンドリング処理を実行することを決定する。フィードバックされる必要があるＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報のビットの数量が、ＰＵＣＣＨ送信のために使用される新たなＰＵＣＣＨフォーマットによって搬送されるビットの最大数量以下である場合には、基地局は、スケジュールされているコードワードの数量に従ってＤＡＩ情報を生成し、表示情報（第２のタイプの表示情報と呼ばれることがある）を使用することによってＤＡＩの生成様式をＵＥに通知し、ＵＥは、基地局によって送信される表示情報に従って、ＨＡＲＱフィードバック情報に対して空間バンドリング処理を実行しないことを決定する。したがって、基地局によってＵＥへ送信される表示情報はさらに、スケジュールされているキャリアのＨＡＲＱ情報に対して空間バンドリングを実行するようＵＥに基地局が指示しているかどうかを示す表示情報と理解され得る。基地局によってＵＥへ送信される表示情報は、第１の表示情報と呼ばれる。

任意選択で、基地局は、ＲＲＣ構成シグナリングを使用することによってＵＥへ第１の表示情報を送信し得るか、または第１の表示情報を送信するための新たなデータフィールドをダウンリンクコントロール情報（Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ、略してＤＣＩ）に付加し得る。代替として、基地局は、第１の表示情報を送信するためにＤＣＩ内の元のデータフィールドを再利用し得る。

別の任意選択の実装形態においては、基地局は代替として、その基地局が、スケジュールされているキャリアの数量に従ってＤＡＩ情報を生成するか、またはスケジュールされているコードワードの数量に従ってＤＡＩ情報を生成するかを別々のＤＣＩエンコーディングモードでＵＥに示すことがあり、すなわち、別々のエンコーディングモードは、別々のタイプの表示情報に対応する。

たとえば、基地局がＤＣＩをエンコードする際に、ＤＣＩエンコーディング中に生成される巡回冗長検査（Ｃｙｃｌｉｃ Ｒｅｄｕｎｄａｎｃｙ Ｃｈｅｃｋ、ＣＲＣ）コード、および固定されたシーケンス（たとえば、８ビットのＣＲＣに関しては、固定されたシーケンスは、２進数での「１０１１０１１０」であり得る）に対して排他的ＯＲ演算が実行されることがあり、またはＣＲＣに対して何の処理も実行されないことがある（これは、２進数での固定されたシーケンス「００００００００」を使用することによって排他的ＯＲ演算を実行することと同等である）。すなわち、基地局は、ＣＲＣコードにスクランブリングコードを付加するか、またはＣＲＣコードにスクランブリングコードを付加しない（これは、別々の固定されたシーケンスを使用することによってＣＲＣをスクランブルすることと同等であり得る）。ＵＥがＤＣＩをデコードする際に、ＵＥがＤＣＩを直接デコードすることができる場合には、それは、ＤＣＩエンコーディング中に生成されるＣＲＣコードに基地局がスクランブリングコードを付加していないということを示し、したがってＵＥは、スケジュールされているキャリアの数量に従って基地局がＤＡＩ情報を生成しているということを知ることができる。それとは逆に、ＵＥがＤＣＩを直接デコードすることができないが、既知の固定されたシーケンス「１０１１０１１０」を使用することによってＤＣＩを正しくデコードすることができる場合には、それは、ＤＣＩエンコーディング中に生成されるＣＲＣコードに基地局がスクランブリングコードを付加しているということを示し、したがってＵＥは、スケジュールされているコードワードの数量に従って基地局がＤＡＩ情報を生成しているということを知ることができる。

この実施形態において提供されている、キャリアアグリゲーションにおけるアップリンクコントロール情報送信方法によれば、基地局は、表示情報をＵＥへ送信し、ＵＥは、その表示情報に従ってＵＣＩのコードブック（すなわち、ＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報）を動的に決定し、それによって、有効なＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報を送信することのパフォーマンスを改善する。

上述のように、基地局は現在、ＰＵＣＣＨリソースをＵＥへ割り振っている。ＣＡシナリオにおいては、基地局は、ＲＲＣ構成シグナリングを使用することによってＵＥ用にいくつかのリソースを明示的に構成し、次いで、ＲＲＣを使用することによって構成されているいくつかのリソースのうちの１つを、ＨＡＲＱ−ＡＣＫ／ＮＡＣＫリソースインジケータ（ＨＡＲＱ−ＡＣＫ／ＮＡＣＫ Ｒｅｓｏｕｒｃｅ Ｉｎｄｉｃａｔｏｒ、略してＡＲＩ）情報を使用することによってユーザ機器に示し得る。

既存のＬＴＥ−ＡシステムにおけるＣＡシナリオにおいては、最大で５つのキャリアが構成され、ＰＵＣＣＨリソースが、ＲＲＣを使用することによって構成され、またはＲＲＣおよびＡＲＩインジケータを一緒に使用することによって構成される。既存のプロトコルにおいては、リソース構成のために使用されるＲＲＣシグナリングユニットは、下記のとおりである。

ＣＨＯＩＣＥは、フォーマット３およびｃｈａｎｎｅｌＳｅｌｅｃｔｉｏｎのどちらかがＰＵＣＣＨフォーマットとして選択されるということを示す。たとえば、フォーマット３が選択される。４つのリソース（ＳＥＱＵＥＮＣＥ（ＳＩＺＥ（１．．４））ＯＦ ＩＮＴＥＧＥＲ（０．．５４９））が構成され、それぞれのリソースは、１つのＩＮＴＥＧＥＲ値によって表される。

既存のプロトコルにおいては、ＡＲＩ情報は、ＬＴＥ−Ａにおけるダウンリンクコントロール情報（Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ、略してＤＣＩ）内のＴＰＣフィールドを再利用することによって送信される。具体的には、ＤＣＩ内のＴＰＣフィールドを再利用することは、ＳＣＣ上のＤＣＩ内のＴＰＣフィールド内のＡＲＩ情報を送信することを意味し、その一方で、ＰＣＣ上のＤＣＩ内のＴＰＣフィールド内の電力コントロールコマンドが依然として送信されて、ＵＥのＰＵＣＣＨ送信電力を基地局がコントロールすることができるということを確実にする。

現在、ＬＴＥ−Ａシステムにおいては、プロトコルはさらに、周波数分割複信（Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｄｕｐｌｅｘ、略してＦＤＤ）モードおよび時分割複信（Ｔｉｍｅ Ｄｉｖｉｓｉｏｎ Ｄｕｐｌｅｘ、略してＴＤＤ）モードという両方の複信モードがＬＴＥ−Ａシステムにおいてサポートされる必要があるということを指定している。具体的には、ＬＴＥ−ＡシステムにおけるＦＤＤモードにおいては、１つだけのダウンリンクサブフレームのＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報をフィードバックするために１つのアップリンクサブフレームが使用され、ＬＴＥ−ＡシステムにおけるＴＤＤモードにおいては、複数のダウンリンクサブフレームのＨＡＲＱ−ＡＣＫ情報をフィードバックするためにいくつかのアップリンクサブフレームのそれぞれが使用される必要がある。

図６Ａは、関連した技術によるＬＴＥ−ＡシステムにおけるＦＤＤモードでのＡＲＩインジケータの概略図である。この図においては、Ｎ−４およびＮは、フレーム番号を表しており、ＦＤＤでのダウンリンクＰＤＳＣＨデータとアップリンクフィードバックとの間におけるタイムインターバルは、４つのサブフレームである。図６Ａにおいて示されているように、ＦＤＤモードにおいては、ＰＣＣ上で受信されるダウンリンクコントロール情報（Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ、略してＤＣＩ）内のすべてのＰＵＣＣＨ ＴＰＣ（ＰＵＣＣＨ用のＴＰＣコマンド）フィールドは、ＰＵＣＣＨ電力コントロールのために使用され、すべてのＳＣＣ上で受信されるダウンリンクＤＣＩ内のすべてのＰＵＣＣＨ ＴＰＣフィールドは、特定のＰＵＣＣＨフォーマット３リソースを選択するよう指示するために使用される。加えて、同じサブフレームにおけるすべてのＳＣＣ上でＵＥによって受信されるＰＵＣＣＨ ＴＰＣフィールド値は同じである必要がある。ＰＵＣＣＨ ＴＰＣフィールド値に関しては、表１において示されているＴＰＣフィールド値の意味を参照されたい。

図６Ｂは、関連した技術によるＬＴＥ−ＡシステムにおけるＴＤＤモードでのＡＲＩインジケータの概略図である。図６Ｂにおいて示されているように、ＴＤＤモードにおいては、１に等しいダウンリンク割り当てインデックス（Ｄｏｗｎｌｉｎｋ Ａｓｓｉｇｎｍｅｎｔ Ｉｎｄｅｘ、略してＤＡＩ）を有する、ＰＣＣ上で受信されるダウンリンクＤＣＩ内のすべてのＰＵＣＣＨ ＴＰＣフィールドは、ＰＵＣＣＨ電力コントロールのために使用され、１よりも大きいＤＡＩを有する、ＰＣＣ上で受信されるダウンリンクＤＣＩ内のすべてのＰＵＣＣＨ ＴＰＣフィールド、およびすべてのＳＣＣ上で受信されるダウンリンクＤＣＩ内のすべてのＰＵＣＣＨ ＴＰＣフィールドは、特定のＰＵＣＣＨフォーマット３リソースを選択するよう指示するために使用される。加えて、１よりも大きいＤＡＩを有する、ＰＣＣ上でＵＥによって受信されるダウンリンクＤＣＩ内のすべてのＰＵＣＣＨ ＴＰＣフィールドは、ＳＣＣ上で受信されるＰＵＣＣＨ ＴＰＣフィールドと同じである必要がある。サブフレームＳは、ＴＤＤモードにおける特別なサブフレームであり、ダウンリンクコントロール情報を送信するためにも使用され得る。

既存のプロトコルにおいては、ＡＲＩインジケータのために使用される、それぞれのキャリア上のＴＰＣフィールドが、２ビットのみを含み、４つの利用可能なリソースがあるということに留意されたい。ＡＲＩインジケータは、ＵＣＩを送信するためのリソースとして、４つの利用可能なリソースから１つのリソースを選択するために使用される。

上述のように、既存のプロトコルにおいて定義されている７つのＰＵＣＣＨフォーマットのうちでＰＵＣＣＨフォーマット３によって搬送されることが可能であるＵＣＩ情報ビットの数量が最も多く、最大で２２ビットが搬送される。ＰＵＣＣＨフォーマット３送信フォーマットにおいては、エンコードされた後に、２２ビットの元の情報が、１つのみの物理リソースブロック（Ｐｈｙｚｉｃａｌ Ｒｅｓｏｕｒｃｅ Ｂｌｏｃｋ、略してＰＲＢ）ペア上で搬送される必要がある。したがって、最大で５つのキャリアが構成される既存のＣＡシナリオにおいては、それぞれのＰＵＣＣＨフォーマットが、１つのＰＲＢペアのリソースを占める。ｅＣＡシナリオにおいては、最大で３２個のＣＣが構成されることが可能であり、それぞれのサブフレームが、複数のＣＣのＣＳＩ情報をフィードバックするために使用されることが可能である。したがって、ＰＵＣＣＨを使用することによってフィードバックされるＵＣＩ情報が大幅に増大され、複数のＰＲＢペアのリソースを占め得る。

本発明の図５において示されている実施形態において提供されている、ＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報をフィードバックするための方法においては、ＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報のコードブックが、スケジュールされているキャリアの数量、またはスケジュールされているコードワードの数量に従って動的に決定され得る。これが意味するのは、それぞれのサブフレームにおいてＨＡＲＱ−ＡＣＫ／ＮＡＣＫ送信のために使用されるＰＵＣＣＨによって占められるリソースが変わり、異なるＰＵＣＣＨフォーマットが選択され得るということである。

本発明の図５において示されている実施形態において提供されている、ＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報をフィードバックするための方法をサポートするためには、基地局がさらに、ＰＵＣＣＨリソースをＵＥへ割り振る必要があり、そのＰＵＣＣＨリソースを使用することによってＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報が送信される。

これを考慮して、本発明の実施形態はさらに、ｅＣＡ用に設計されている新たなＰＵＣＣＨフォーマットのリソース割り振りおよびＰＵＣＣＨフォーマット表示を提供する。この実施形態において提供されている、キャリアアグリゲーションにおけるＰＵＣＣＨリソース割り振り方法はまた、最大で５つのキャリアがアグリゲートされる既存のシナリオに適用可能であるということが理解され得る。この実施形態において提供されている、キャリアアグリゲーションにおけるＰＵＣＣＨリソース割り振り方法は、基地局によって実行される。

図７は、本発明の実施形態による、キャリアアグリゲーションにおけるＰＵＣＣＨリソース割り振り方法のフローチャートである。図７において示されているように、この方法は、下記のステップを含み得る。

Ｓ７１． 基地局が、第２の構成情報をＵＥへ送信し、第２の構成情報は、ＵＥ用のリソースリストを構成するために使用され、そのリソースリストは、複数のリソース情報グループを含む。

Ｓ７２． 基地局は、第２の表示情報をＵＥへ送信し、第２の表示情報は、リソースリスト内の１つのリソース情報グループに対応するＰＵＣＣＨリソースをＵＥに示すために使用される。

この実施形態においては、基地局は、ＲＲＣ構成シグナリングを使用することによってＵＥ用にいくつかのリソースを構成することがあり、すなわち、基地局は、ＲＲＣ構成シグナリングを使用することによってＵＥ用のＰＵＣＣＨリソースリストを構成することがある。そのリソースリストは、複数のリソース情報グループを含み、それぞれのリソース情報グループは、１つのＰＵＣＣＨリソースに対応する。

加えて、この実施形態においては、基地局は、ＵＥによって送信されるＨＡＲＱフィードバック情報のコードブックサイズを、スケジュールされているキャリアに従って動的に決定することができる。したがって、さまざまな無線チャネル状況におけるさまざまなコードブックサイズに従って、さまざまなＰＵＣＣＨリソースサイズまたはさまざまなＰＵＣＣＨフォーマットのＰＵＣＣＨリソースが、ＵＥ用に基地局によって構成されているＰＵＣＣＨリソースリストから、使用のために選択され得る。本明細書におけるＰＵＣＣＨリソースサイズは、ＰＲＢペアの数量を指し、この実施形態における割り振られるリソースどうしは連続しているので、ＰＵＣＣＨリソースサイズはまた、ＰＲＢペアの長さと呼ばれ得るということに留意されたい。具体的には、第２の表示情報は、リソースリスト内のリソース情報グループに対応するＰＵＣＣＨリソースをＵＥに示すために使用され得る。具体的には、第２の表示情報はＡＲＩ情報であり得る。

ＰＵＣＣＨ上で搬送されるＵＣＩ情報のコードブックサイズを決定するための方法は、リソース割り振り様式上に比較的大きなインパクトを及ぼし、そのコードブックサイズは、ＵＣＩ情報ビットの数量であるということに留意されたい。本明細書においては、ＨＡＲＱ−ＡＣＫ／ＮＡＣＫコードブックサイズを決定することは、この実施形態の適用シナリオについて記述するための例として使用される。既存のプロトコルにおいては、ＨＡＲＱ−ＡＣＫ／ＮＡＣＫコードブックサイズは、構成されているキャリアの数量、およびそれぞれのキャリアの送信モード（Ｔｒａｎｓｍｉｔ Ｍｏｄｅｌ、略してＴＭ）に依存する。これらのパラメータは、準静的に構成される。したがって、ＨＡＲＱ−ＡＣＫ／ＮＡＣＫコードブックサイズも準静的に構成されるとみなされ得る。構成が変更されない場合には、すべてのサブフレームにおけるユーザのコードブックサイズは同じである。しかしながら、別々のＰＵＣＣＨフォーマットは、別々のコードブックサイズに関して別々のパフォーマンスを有する。これが意味するのは、複数のＰＵＣＣＨフォーマットが使用のために考慮される場合には、パフォーマンスを最適化するために別々のサブフレームに関して別々のＰＵＣＣＨフォーマットが使用され得るということである。

基地局は、スケジュールされているキャリアの数量、またはスケジュールされているコードワードの数量に従ってＵＣＩ情報のコードブックサイズを決定し、次いで現在のチャネル環境および別のパラメータを参照して、ＵＥによって必要とされるＰＵＣＣＨリソースのサイズ情報およびフォーマット情報を決定し得るということが理解され得る。これは、この実施形態においては特に限定されない。

この実施形態において提供されている、キャリアアグリゲーションにおけるＰＵＣＣＨリソース割り振り方法によれば、基地局は、ＲＲＣ構成シグナリングを使用することによってＵＥ用に複数のＰＵＣＣＨリソースを構成し、スケジュールされているキャリアの数量、またはスケジュールされているコードワードの数量に従ってＵＣＩ情報のコードブックサイズを決定し、次いで現在のチャネル環境を参照してＵＥの実際の要件を決定し、固定されたサイズおよび固定されたフォーマットのＰＵＣＣＨリソースをＵＥへ割り振る代わりに、第２の表示の表示を使用することによって、ＰＵＣＣＨリソースの選択、ならびにＰＵＣＣＨリソースサイズおよびＰＵＣＣＨフォーマットの動的でフレキシブルな決定を完遂する。これは、ＰＵＣＣＨを使用することによってＵＥによってフィードバックされるＵＣＩが複数のＰＲＢペアのリソースを占め得るｅＣＡシナリオの要件を満たすことができるだけでなく、ＰＵＣＣＨリソースの利用を改善することもできる。

加えて、関連した技術においては、キャリアアグリゲーションにおいてＰＵＣＣＨフォーマットが準静的に構成されることのみが可能である。しかしながら、この実施形態において提供されている、キャリアアグリゲーションにおけるリソース割り振り方法によれば、別々のサブフレームに関して別々のＰＵＣＣＨフォーマットが使用されることがあり、新たなＰＵＣＣＨフォーマットのための複数の可変候補がサポートされることが可能であり、それによってシステムパフォーマンスが最適化される。

この実施形態においては、基地局は、ＲＲＣ構成シグナリングを使用することによってＵＥ用のリソースリストを事前に構成し、別々のリソース情報グループが、同じＰＵＣＣＨフォーマットに対応することがあり、または別々のリソース情報グループが、別々のＰＵＣＣＨフォーマットに対応することがある。さらに、以降では、具体的な例を使用することによって詳細な説明を提供する。

図８は、ＲＲＣ構成シグナリングを使用することによってＵＥ用に構成されている第１のＰＵＣＣＨリソースリストの概略図である。リソースリスト内の複数のリソース情報グループが、２つの異なるＰＵＣＣＨフォーマットに従ってアレンジされている。それぞれのＰＵＣＣＨフォーマットは、２つのリソース情報グループに対応し、それぞれのリソース情報グループは、１つのＰＵＣＣＨリソースの開始アドレス表示情報およびサイズ表示情報を含む。ＲＲＣ構成シグナリングは、特に下記の形式で書かれ得る。明らかに、下記のシグナリングコンテンツは、本発明に対する限定ではなく、本発明について記述するための例として使用されているにすぎない。

たとえば、ＰＵＣＣＨリソースリストは、下記のＲＲＣ構成情報要素を使用することによってＵＥ用に構成され得る。

さらに、ＵＥによって必要とされるＰＵＣＣＨリソースのサイズ情報およびフォーマット情報を決定した後に、基地局が、ＵＥによって必要とされるＰＵＣＣＨリソースのサイズ情報およびフォーマット情報と同じであるサイズ表示情報およびＰＵＣＣＨフォーマットを有する第１のリソース情報グループをＰＵＣＣＨリソースリストから選択し、次いで第２の表示情報を使用することによって、第１のリソース情報グループに対応するリソースインデックス（Ｒｅｓｏｕｒｃｅ Ｉｎｄｅｘ、略してＲＩ）をＵＥへ送信することがあり、ＵＥは、第２の表示の表示に従って、第１のリソース情報グループに対応するＰＵＣＣＨリソースを入手する。

たとえば、ＵＥによって必要とされるＰＵＣＣＨリソースが、マルチＰＲＢ ＰＦ３フォーマットのものであり、２つのＰＲＢペアを占めるということを基地局が決定した場合には、基地局は、第２の表示情報を使用することによって、図８において示されているリソース情報グループ１に対応するＲＩをＵＥへ送信し得る。ＵＥは、第２の表示情報の表示に従って、リソース情報グループ１に対応するＰＵＣＣＨリソースを入手する。

第２の表示情報をＵＥへ送信するために、関連した技術におけるＡＲＩ情報送信方法が使用され得るということに留意されたい。たとえば、第２の表示情報を送信するために、ＬＴＥにおけるＤＣＩ内のＴＰＣフィールドが使用され得る。既存のプロトコルにおいては、ＡＲＩインジケータのために使用される、それぞれのキャリア上のＴＰＣフィールドが、２ビットを含み、４つのリソースのうちの１つを選択することが実施されることが可能であるということが理解され得る。

図９は、ＲＲＣ構成シグナリングを使用することによってＵＥ用に構成されている第２のＰＵＣＣＨリソースリストの概略図である。リソースリスト内の複数のリソース情報グループが、２つの異なるＰＵＣＣＨフォーマットに従ってアレンジされている。それぞれのＰＵＣＣＨフォーマットは、４つのリソース情報グループに対応し、それぞれのリソース情報グループは、１つのＰＵＣＣＨリソースの開始アドレス表示情報およびサイズ表示情報を含む。

さらに、ＵＥによって必要とされるＰＵＣＣＨリソースのサイズ情報およびフォーマット情報を決定した後に、基地局が、ＵＥによって必要とされるＰＵＣＣＨリソースのサイズ情報およびフォーマット情報と同じであるサイズ表示情報およびＰＵＣＣＨフォーマットを有する第２のリソース情報グループをＰＵＣＣＨリソースリストから選択し、次いで第２の表示情報を使用することによって、第２のリソース情報グループに対応するリソースインデックス（Ｒｅｓｏｕｒｃｅ Ｉｎｄｅｘ、略してＲＩ）をＵＥへ送信することがあり、ＵＥは、第２の表示の表示に従って、第２のリソース情報グループに対応するＰＵＣＣＨリソースを入手する。

図９において示されているケースにおいては、８つのリソース情報グループのうちの１つのリソース情報グループに対応するＰＵＣＣＨリソースが選択される必要がある。しかしながら、既存のプロトコルにおいては、ＡＲＩインジケータのために使用される、それぞれのキャリア上のＴＰＣフィールドが、２ビットのみを含み、４つのリソースのうちの１つを選択することのみが実施されることが可能である。したがって、ＡＲＩインジケータのために使用される既存のＴＰＣフィールドが、第２の表示情報を送信するために使用される場合には、８つのリソース情報グループのうちの１つのリソース情報グループに対応するＰＵＣＣＨリソースの選択が実施されることは不可能である。

好ましい実装形態においては、第２の表示情報を送信するために、ＴＰＣフィールドの２つのグループが使用され得る。ＴＰＣフィールドの一方のグループは、第２のリソース情報グループに対応するＲＩを送信するために使用され、ＰＵＣＣＨ ＴＰＣフィールド値に関しては、表２において示されているＴＰＣフィールド値の第１のグループの意味を参照されたい。ＴＰＣフィールドの他方のグループは、第２のリソース情報グループに対応するＰＵＣＣＨフォーマットインデックス（Ｆｏｒｍａｔ Ｉｎｄｅｘ、略してＦＩ）を送信するために使用され、ＰＵＣＣＨ ＴＰＣ要求フィールド値に関しては、表３において示されているＴＰＣフィールド値の第２のグループの意味を参照されたい。明らかに、表２および表３においてリストアップされているＴＰＣフィールド値の意味は、本発明に対する限定ではなく、本発明について記述するための例として使用されているにすぎない。

別の任意選択の実装形態においては、基地局は代替として、拡張ＴＰＣフィールドを使用することによって、第２のリソース情報グループに対応するＲＩおよびＦＩを送信し得る。たとえば、少なくとも１ビットが既存のＴＰＣフィールドに付加されて、拡張ＴＰＣフィールドを入手することがあり、第２のリソース情報グループに対応するＲＩを送信するために、元の２ビットが使用され、第２のリソース情報グループに対応するＦＩを送信するために、新たに付加されたビットが使用される。特定の拡張ＰＵＣＣＨ ＴＰＣフィールド値に関しては、表４において示されている拡張ＴＰＣフィールド値の意味を参照されたい。表４において示されている、第１のタイプの拡張ＴＰＣフィールドが３ビットを含む場合のＴＰＣフィールド値の意味によれば、ＰＵＣＣＨリソースの２つの異なるフォーマットを示すために、新たに付加された１ビットが使用され得るということが知られ得る。明らかに、拡張ＴＰＣフィールドが４ビットを含む場合のＴＰＣフィールド値の意味はさらに、表４において示されている、第１のタイプの拡張ＴＰＣフィールドが３ビットを含む場合のＴＰＣフィールド値の意味に従って入手され得る。すなわち、ＰＵＣＣＨリソースの４つの異なるフォーマットを示すために、新たに付加された２ビットが使用され得る。

図１０は、ＲＲＣ構成シグナリングを使用することによってＵＥ用に構成されている第３のＰＵＣＣＨリソースリストの概略図である。リソースリスト内の４つのリソース情報グループが、別々のＰＵＣＣＨフォーマットに従ってアレンジされている。それぞれのＰＵＣＣＨフォーマットは、２つのリソース情報グループに対応し、それぞれのリソース情報グループは、１つのＰＵＣＣＨリソースの開始アドレス表示情報を含む。同様に、この実施形態において示されていないＰＵＣＣＨリソースリストの概略図においては、代替として、それぞれのＰＵＣＣＨフォーマットは、４つのリソース情報グループに対応することがあり、それぞれのリソース情報グループは、１つのＰＵＣＣＨリソースの開始アドレス表示情報を含む。

さらに、ＵＥによって必要とされるＰＵＣＣＨリソースのサイズ情報およびフォーマット情報を決定した後に、基地局が、ＵＥによって必要とされるＰＵＣＣＨリソースのフォーマット情報と同じであるＰＵＣＣＨフォーマットを有する第３のリソース情報グループをＰＵＣＣＨリソースリストから選択し、次いで第２の表示情報を使用することによって、第２のリソース情報グループに対応するＲＩをＵＥへ送信することがあり、ＵＥは、第２の表示情報の表示に従って、第３のリソース情報グループに対応するＰＵＣＣＨリソースを入手する。加えて、基地局はさらに、第２の表示情報を使用することによって、ＵＥによって必要とされるＰＵＣＣＨリソースのサイズ情報に対応するＰＵＣＣＨリソースの長さインデックス（Ｌｅｎｇｔｈ Ｉｎｄｅｘ、略してＬＩ）をＵＥへ送信して、第３のリソース情報グループに対応するＰＵＣＣＨリソースのサイズをＵＥに示す。

同様に、第２の表示情報をＵＥへ送信するために、関連した技術におけるＡＲＩ情報送信方法が使用され得るということに留意されたい。たとえば、第２の表示情報を送信するために、ＬＴＥにおけるＤＣＩ内のＴＰＣフィールドが使用され得る。図１０において示されているケースにおいては、第３のリソース情報グループに対応するＲＩと、第３のリソース情報グループに対応するＬＩとの両方が、第２の表示情報を使用することによってＵＥに示される必要がある。

好ましい実装形態においては、第２の表示情報を送信するために、ＴＰＣフィールドの２つのグループが使用され得る。ＴＰＣフィールドの一方のグループは、第３のリソース情報グループに対応するＲＩを送信するために使用され、ＴＰＣ要求ＰＵＣＣＨフィールド値に関しては、表２において示されているＴＰＣフィールド値の第１のグループの意味を参照されたい。ＴＰＣフィールドの他方のグループは、第３のリソース情報グループに対応するＰＵＣＣＨリソースのサイズをＵＥに示すＬＩを送信するために使用され、ＴＰＣ要求ＰＵＣＣＨフィールド値に関しては、表５において示されているＴＰＣフィールド値の第３のグループの意味を参照されたい。

別の任意選択の実装形態においては、基地局は代替として、拡張ＴＰＣフィールドを使用することによって、第２のリソース情報グループに対応するＲＩと、第２のリソース情報グループに対応するＰＵＣＣＨリソースのサイズをＵＥに示すＬＩとを送信し得る。たとえば、少なくとも１ビットが既存のＴＰＣフィールドに付加されて、拡張ＴＰＣフィールドを入手することがあり、第２のリソース情報グループに対応するＲＩを送信するために、元の２ビットが使用され、第２のリソース情報グループに対応するＰＵＣＣＨリソースのサイズをＵＥに示すＬＩを送信するために、新たに付加されたビットが使用される。特定の拡張ＴＰＣ要求ＰＵＣＣＨフィールド値に関しては、表６において示されている第２のタイプの拡張ＴＰＣフィールド値の意味を参照されたい。表６において示されている、第２のタイプの拡張ＴＰＣフィールドが３ビットを含む場合のＴＰＣフィールド値の意味によれば、ＰＵＣＣＨリソースの２つの異なるサイズを示すために、新たに付加された１ビットが使用され得るということが知られ得る。明らかに、拡張ＴＰＣフィールドが４ビットを含む場合のＴＰＣフィールド値の意味はさらに、表６において示されている、第２のタイプの拡張ＴＰＣフィールドが３ビットを含む場合のＴＰＣフィールド値の意味に従って入手され得る。すなわち、ＰＵＣＣＨリソースの４つの異なるサイズを示すために、新たに付加された２ビットが使用され得る。

図１１は、ＲＲＣ構成シグナリングを使用することによってＵＥ用に構成されている第４のＰＵＣＣＨリソースリストの概略図である。リソースリスト内のそれぞれのリソース情報グループが、１つのＰＵＣＣＨリソースの開始アドレス表示情報およびサイズ表示情報を含む。ＲＲＣ構成シグナリングは、特に下記の形式で書かれ得る。明らかに、下記のシグナリングコンテンツは、本発明に対する限定ではなく、本発明について記述するための例として使用されているにすぎない。

たとえば、ＰＵＣＣＨリソースリストは、下記のＲＲＣ構成シグナリングを使用することによってＵＥ用に構成され得る。

図１１において示されているように、ＲＲＣ構成シグナリングを使用することによってＵＥ用に構成されているＰＵＣＣＨリソースリストは、４つのリソース情報グループを含む。それぞれのリソース情報グループは、１つのＰＵＣＣＨリソースの開始表示情報（ＲｅｓｏｕｒｃｅＳｔａｒｔ ＩＮＴＥＧＥＲ（０．．５４９））、およびそのＰＵＣＣＨリソースのサイズ情報（ＲｅｓｏｕｒｃｅＬｅｎ ＩＮＴＥＧＥＲ（０．．５））を含む。したがって、４つのリソース情報グループのＰＵＣＣＨフォーマットはさらに、動的に示されることが必要である。すなわち、ＲＲＣ構成シグナリングを使用することによってＵＥ用に構成されているＰＵＣＣＨリソースリスト内のそれぞれのリソース情報グループは、１つのＰＵＣＣＨリソースの開始アドレス表示情報およびサイズ表示情報を含む。

さらに、ＵＥによって必要とされるＰＵＣＣＨリソースのサイズ情報およびフォーマット情報を決定した後に、基地局が、ＵＥによって必要とされるＰＵＣＣＨリソースのサイズ情報と同じであるサイズ表示情報を有する第４のリソース情報グループをＰＵＣＣＨリソースリストから選択し、次いで第２の表示情報を使用することによって、第４のリソース情報グループに対応するＲＩをＵＥへ送信することがあり、ＵＥは、第２の表示情報の表示に従って、第４のリソース情報グループに対応するＰＵＣＣＨリソースを入手する。加えて、基地局はさらに、第２の表示情報を使用することによって、ＵＥによって必要とされるＰＵＣＣＨリソースのフォーマット情報に対応するＰＵＣＣＨリソースのフォーマットインデックスＦＩをＵＥへ送信して、第４のリソース情報グループに対応するＰＵＣＣＨリソースのＰＵＣＣＨフォーマットをＵＥに示す。

同様に、第２の表示情報をＵＥへ送信するために、関連した技術におけるＡＲＩ情報送信方法が使用され得るということに留意されたい。たとえば、第２の表示情報を送信するために、ＬＴＥにおけるＤＣＩ内のＴＰＣフィールドが使用され得る。図１１において示されているケースにおいては、第４のリソース情報グループに対応するＲＩと、第４のリソース情報グループに対応するＦＩとの両方が、第２の表示情報を使用することによってＵＥに示される必要がある。

好ましい実装形態においては、第２の表示情報を送信するために、ＴＰＣフィールドの２つのグループが使用され得る。ＴＰＣフィールドの一方のグループは、第４のリソース情報グループに対応するＲＩを送信するために使用され、ＴＰＣ要求ＰＵＣＣＨフィールド値に関しては、表２において示されているＴＰＣフィールド値の第１のグループの意味を参照されたい。ＴＰＣフィールドの他方のグループは、第４のリソース情報グループに対応するＰＵＣＣＨリソースをＵＥに示すＦＩを送信するために使用され、ＴＰＣ要求ＰＵＣＣＨフィールド値に関しては、表３において示されているＴＰＣフィールド値の第２のグループの意味を参照されたい。

別の任意選択の実装形態においては、基地局は代替として、拡張ＴＰＣフィールドを使用することによって、第４のリソース情報グループに対応するＲＩと、第４のリソース情報グループに対応するＰＵＣＣＨリソースのフォーマットをＵＥに示すＦＩとを送信し得る。たとえば、少なくとも１ビットが既存のＴＰＣフィールドに付加されて、拡張ＴＰＣフィールドを入手することがあり、第４のリソース情報グループに対応するＲＩを送信するために、元の２ビットが使用され、第４のリソース情報グループに対応するＰＵＣＣＨリソースのフォーマットをＵＥに示すＦＩを送信するために、新たに付加されたビットが使用される。特定の拡張ＴＰＣ要求ＰＵＣＣＨフィールド値に関しては、表７において示されている第３のタイプの拡張ＴＰＣフィールド値の意味を参照されたい。表７において示されている、第３のタイプの拡張ＴＰＣフィールドが３ビットを含む場合のＴＰＣフィールド値の意味によれば、ＰＵＣＣＨリソースの２つの異なるフォーマットを示すために、新たに付加された１ビットが使用され得るということが知られ得る。明らかに、拡張ＴＰＣフィールドが４ビットを含む場合のＴＰＣフィールド値の意味はさらに、表６において示されている、第２のタイプの拡張ＴＰＣフィールドが３ビットを含む場合のＴＰＣフィールド値の意味に従って入手され得る。すなわち、ＰＵＣＣＨリソースの４つの異なるサイズを示すために、新たに付加された２ビットが使用され得る。

図１２は、ＲＲＣ構成シグナリングを使用することによってＵＥ用に構成されている第５のＰＵＣＣＨリソースリストの概略図である。リソースリスト内のそれぞれのリソース情報グループが、１つのＰＵＣＣＨリソースの開始アドレス表示情報を含む。たとえば、ＰＵＣＣＨリソースリストは、下記のＲＲＣ構成シグナリングを使用することによってＵＥ用に構成され得る。

さらに、基地局が、第２の表示情報を使用することによって、第５のリソース情報グループに対応するＲＩをＵＥへ送信する必要があり、ＵＥは、第２の表示情報の表示に従って、第５のリソース情報グループに対応するＰＵＣＣＨリソースを入手する。加えて、基地局はさらに、第２の表示情報を使用することによって、ＵＥによって必要とされるＰＵＣＣＨリソースのフォーマット情報に対応するＰＵＣＣＨリソースのＦＩをＵＥへ送信して、第５のリソース情報グループに対応するＰＵＣＣＨリソースのフォーマットをＵＥに示す必要がある。基地局はさらに、第２の表示情報を使用することによって、ＵＥによって必要とされるＰＵＣＣＨリソースのサイズ情報に対応するＰＵＣＣＨリソースのＬＩをＵＥへ送信して、第５のリソース情報グループに対応するＰＵＣＣＨリソースのサイズをＵＥに示す必要がある。

同様に、第２の表示情報をＵＥへ送信するために、関連した技術におけるＡＲＩ情報送信方法が使用され得るということに留意されたい。たとえば、第２の表示情報を送信するために、ＬＴＥにおけるＤＣＩ内のＴＰＣフィールドが使用され得る。図１１において示されているケースにおいては、第５のリソース情報グループに対応するＲＩと、第５のリソース情報グループに対応するＦＩおよびＬＩとの両方が、第２の表示情報を使用することによってＵＥに示される必要がある。

好ましい実装形態においては、第２の表示情報を送信するために、ＴＰＣフィールドの３つのグループが使用され得る。ＴＰＣフィールドの第１のグループは、第５のリソース情報グループに対応するＲＩを送信するために使用され、ＴＰＣ要求ＰＵＣＣＨフィールド値に関しては、表２において示されているＴＰＣフィールド値の第１のグループの意味を参照されたい。ＴＰＣフィールドの第２のグループは、第５のリソース情報グループに対応するＰＵＣＣＨリソースのフォーマットをＵＥに示すＦＩを送信するために使用され、ＴＰＣ要求ＰＵＣＣＨフィールド値に関しては、表３において示されているＴＰＣフィールド値の第２のグループの意味を参照されたい。ＴＰＣフィールドの第３のグループは、第５のリソース情報グループに対応するＰＵＣＣＨリソースのサイズをＵＥに示すＬＩを送信するために使用され、ＴＰＣ要求ＰＵＣＣＨフィールド値に関しては、表５において示されているＴＰＣフィールド値の第３のグループの意味を参照されたい。

別の任意選択の実装形態においては、基地局は代替として、拡張ＴＰＣフィールドを使用することによって、第５のリソース情報グループに対応するＲＩと、第５のリソース情報グループに対応するＰＵＣＣＨリソースのフォーマットをＵＥに示すＦＩと、第５のリソース情報グループに対応するＰＵＣＣＨリソースのサイズをＵＥに示すＬＩとを送信し得る。たとえば、少なくとも２ビットが既存のＴＰＣフィールドに付加されて、拡張ＴＰＣフィールドを入手することがあり、第５のリソース情報グループに対応するＲＩを送信するために、元の２ビットが使用され、第５のリソース情報グループに対応するＰＵＣＣＨリソースのフォーマットおよびサイズをＵＥに示すＦＩおよびＬＩを送信するために、新たに付加されたビットが使用される。

できるだけ少ないビットをＴＰＣフィールドに付加するために、好ましい実装形態においては、ＲＲＣ構成シグナリングを使用することによってＵＥ用に構成されているリソースリストは、代替として２つのリソース情報グループのみを含み得る。明らかに、これは、リソース選択の柔軟性を犠牲にしている。この方法においては、第２の表示情報を送信するために、ＴＰＣフィールドの２つのグループが使用されることが可能である。ＴＰＣフィールドの一方のグループは、第６のリソース情報グループに対応するＲＩおよびＦＩを送信するために使用され、ＴＰＣフィールドの他方のグループは、第６のリソース情報グループに対応するＰＵＣＣＨリソースをＵＥに示すＬＩを送信するために使用される。

同様に、ＲＲＣ構成シグナリングを使用することによってＵＥ用に構成されているリソースリストが、２つのリソース情報グループのみを含む場合には、代替として、１ビットのみが既存のＴＰＣフィールドに付加されて、拡張ＴＰＣフィールドを入手することがあり、第２のリソース情報グループに対応するＲＩと、第６のリソース情報グループに対応するＰＵＣＣＨリソースのフォーマットをＵＥに示すＦＩとを送信するために、元の２ビットが使用され、第６のリソース情報グループに対応するＰＵＣＣＨリソースのサイズをＵＥに示すＬＩを送信するために、新たに付加されたビットが使用されるということが理解され得る。

本発明の別の実施形態においては、ＴＰＣフィールドの２つのグループか、または３つのグループかをどのようにして決定するかがさらに、例を使用することによって記述される。

図６Ａおよび図６Ｂにおいて示されているように、ＬＴＥ−Ａシステムにおいては、ＦＤＤモードにおけるＡＲＩ情報送信メカニズムと、ＴＤＤモードにおけるＡＲＩ情報送信メカニズムとは異なる。以降では、ＴＰＣフィールドをどのようにしてグループ化するかについて記述するための例として図１３Ａおよび図１３Ｂを別々に使用する。

図１３Ａは、ＦＤＤモードにおけるキャリアスケジューリングの概略図である。図１３Ａにおいて示されているように、たとえば、スケジュールされているキャリアセットが｛０，３，５，６，８，９｝であり、キャリア０がＰＣＣである。ＬＴＥ−ＡシステムにおけるＦＤＤモードにおいては、ＰＣＣ上で受信されるＤＣＩ内のすべてのＴＰＣ要求ＰＵＣＣＨフィールドが、ＰＵＣＣＨ電力コントロールのために使用される。このケースにおいては、ＡＲＩ情報を送信するために使用されることが可能であるキャリアは、５つのＳＣＣ、すなわち、｛３，５，６，８，９｝である。それらの５つのスケジュールされているキャリアは、２つのグループへとグループ化される。

任意選択の実装形態においては、ＴＰＣフィールドの２つのグループを決定するために、順次的なグループ化様式が使用され得る。具体的には、別々のスケジュールされているキャリア上のＴＰＣフィールドが、２つのグループへとグループ化され得る。

たとえば、ＴＰＣフィールドの２つのグループのそれぞれに対応するキャリアの数量が、スケジュールされているキャリアに従って決定され得る。たとえば、第１のグループが、３つのキャリアに対応することがあり、第２のグループが、２つのキャリアに対応することがあり、または第１のグループが、１つのキャリアに対応することがあり、第２のグループが、４つのキャリアに対応することがある。次いで、スケジュールされているキャリアは、それらのスケジュールされているキャリアの識別番号の配列順に従って、およびＴＰＣフィールドのそれぞれのグループに対応するキャリアの数量に従って２つのグループへと順次グループ化され、キャリアの２つの対応するグループは、Ｇ１＝｛３，５，６｝およびＧ２＝｛８，９｝、またはＧ１＝｛３｝およびＧ２＝｛５，６，８，９｝である。キャリアは通常、できるだけ均等にグループ化される。たとえば、第１のグループにおけるキャリアの数量は、［Ｎ／２］に等しく、第２のグループにおけるキャリアの数量は、Ｎ−［Ｎ／２］に等しい。Ｎは、グループ化に関与しているキャリアの合計数量を表し、［］は、切り上げ計算を表す。キャリアがグループ化された後に、スケジュールされているキャリアの２つのグループのそれぞれの上のＴＰＣフィールドが、ＴＰＣフィールドの一方のグループとして決定される。

別の任意選択の実装形態においては、ＴＰＣフィールドの２つのグループを決定するために、代替としてパリティグループ化様式が使用され得る。具体的には、スケジュールされているキャリアのうちで奇数である識別番号を有するスケジュールされているキャリア上のＴＰＣフィールドが、ＴＰＣフィールドの一方のグループとして決定されることがあり、スケジュールされているキャリアのうちで偶数である識別番号を有するスケジュールされているキャリア上のＴＰＣフィールドが、ＴＰＣフィールドの他方のグループとして決定されることがある。それに対応して、Ｇ１＝｛３，５，９｝上のＴＰＣフィールドが、ＴＰＣフィールドの一方のグループとして決定され、Ｇ２＝｛６，８｝上のＴＰＣフィールドが、ＴＰＣフィールドの他方のグループとして決定される。

パリティグループ化様式は、スケジュールされているＳＣＣの中に、奇数の識別番号および偶数の識別番号を伴うＳＣＣが存在する場合にのみ、ＴＰＣフィールドの２つのグループを決定するために使用されることが可能であるということに留意されたい。そうでない場合には、ＴＰＣフィールドの２つのグループを決定するために、順次的なグループ化様式のみが使用されることが可能である。

図１３Ｂは、ＴＤＤモードにおけるｅＣＡスケジューリングの概略図である。図１３Ｂにおいて示されているように、たとえば、スケジュールされているキャリアセットが｛０，２，３，６，９｝であり、キャリア０がＰＣＣである。ＬＴＥ−ＡシステムにおけるＴＤＤモードにおいては、ＰＣＣ上で１よりも大きいＤＡＩを有するダウンリンクＤＣＩ内のＴＰＣ要求ＰＵＣＣＨフィールド、およびすべてのＳＣＣ上で受信されるダウンリンクＤＣＩ内のすべてのＴＰＣ要求ＰＵＣＣＨフィールドが、ＡＲＩ情報を送信するために使用され得る。このケースにおいては、５つのキャリア、すなわち、｛０，２，３，６，９｝が、ＡＲＩ情報を送信するために使用され得る。それらの５つのスケジュールされているキャリアは、２つのグループへとグループ化される。

同様に、スケジュールされているキャリアの２つのグループを決定するために、順次的なグループ化様式が使用され得る。たとえば、Ｇ１＝｛０（ｓｕｂｆｒａｍｅ ８）， ２（ｓｕｂｆｒａｍｅ ４）， ３（ｓｕｂｆｒａｍｅ ４， ｓｕｂｆｒａｍｅ ５）｝上のＴＰＣフィールドが、ＴＰＣフィールドの一方のグループとして決定され、Ｇ２＝｛６（ｓｕｂｆｒａｍｅ ４， ｓｕｂｆｒａｍｅ ８）， ９（ｓｕｂｆｒａｍｅ ５， ｓｕｂｆｒａｍｅ ６）｝上のＴＰＣフィールドが、ＴＰＣフィールドの他方のグループとして決定される。

代替として、ＴＰＣフィールドの２つのグループを決定するために、パリティグループ化様式が使用され得る。たとえば、Ｇ１＝｛０（ｓｕｂｆｒａｍｅ ８），２（ｓｕｂｆｒａｍｅ ４）， ６（ｓｕｂｆｒａｍｅ ４， ｓｕｂｆｒａｍｅ ８）｝上のＴＰＣフィールドが、ＴＰＣフィールドの一方のグループとして決定され、Ｇ２＝｛３（ｓｕｂｆｒａｍｅ ４， ｓｕｂｆｒａｍｅ ５）， ９（ｓｕｂｆｒａｍｅ ５， ｓｕｂｆｒａｍｅ ６）｝上のＴＰＣフィールドが、ＴＰＣフィールドの他方のグループとして決定される。

同様に、ＰＣＣの識別番号が偶数であるので、パリティグループ化様式は、スケジュールされているＳＣＣの中に、奇数の識別番号を伴うＳＣＣが存在する場合にのみ、ＴＰＣフィールドの２つのグループを決定するために使用されることが可能であるということに留意されたい。

さらに、ＴＰＣフィールドの３つのグループを決定する特定の様式に関しては、前述の実施形態における順次的なグループ化様式を参照されたい。それらの原理は同じである。したがって、詳細がここで再び記述されることはない。複数のＴＰＣグループ化様式があり、本発明は、特定のグループ化様式に制限を課すことはないということに留意されたい。

本発明の前述の実施形態において提供されている、キャリアアグリゲーションにおけるリソース割り振り様式によれば、基地局は、ＲＲＣ構成シグナリングを使用することによってＵＥ用に複数のＰＵＣＣＨリソースを構成し、次いでＡＲＩの表示を使用することによってＵＥの実際の要件に従って、ＰＵＣＣＨリソースの選択、ならびにＰＵＣＣＨリソースサイズおよびＰＵＣＣＨフォーマットの動的でフレキシブルな決定を完遂する。これは、ＰＵＣＣＨを使用することによってＵＥによってフィードバックされるＵＣＩが複数のＰＲＢペアのリソースを占め得るｅＣＡシナリオの要件を満たすことができるだけでなく、ＰＵＣＣＨリソースの利用を改善することもできる。加えて、本発明の実施形態においては、別々のサブフレームに関して別々のＰＵＣＣＨフォーマットが使用されることがあり、新たなＰＵＣＣＨフォーマットのための複数の可変候補がサポートされることが可能であり、それによってシステムパフォーマンスが最適化される。

図１４は、本発明の実施形態による、キャリアアグリゲーションにおけるアップリンクコントロール情報送信装置の概略図である。装置Ａは、特に基地局内に配置されることがあり、本発明の図５において示されている実施形態において提供されている、キャリアアグリゲーションにおけるアップリンクコントロール情報送信方法を実施するために使用され得る。詳細がここで再び記述されることはない。図１４において示されているように、この実施形態において提供されている、キャリアアグリゲーションにおけるアップリンクコントロール情報送信装置Ａは、第１の送信モジュール１４１およびリソース割り振りモジュール１４２を含む。

第１の送信モジュール１４１は、第１の表示情報をユーザ機器ＵＥへ送信するように構成されることがあり、第１の表示情報は、その第１の表示情報に従ってアップリンクコントロール情報ＵＣＩを動的に決定するようＵＥに指示するために使用される。リソース割り振りモジュール１４２は、ＰＵＣＣＨリソースをＵＥへ割り振るように構成されることがあり、そのＰＵＣＣＨリソースは、ＵＣＩを送信するために使用される。

この実施形態においては、第１の表示情報は、特に第１のタイプの表示情報または第２のタイプの表示情報であり得る。第１の表示情報が第１のタイプの表示情報である場合には、ＵＥは、スケジュールされているキャリアの数量に従って基地局がＤＡＩ情報を生成する場合に、第１のタイプの表示情報に従ってＵＣＩを決定する。第１の表示情報が第２のタイプの表示情報である場合には、ＵＥは、スケジュールされているコードワードの数量に従って基地局がＤＡＩ情報を生成する場合に、第２のタイプの表示情報に従ってＵＣＩを決定する。

任意選択の実装形態においては、第１の送信モジュールは、第１の構成情報をＵＥへ送信するように特に構成され得る。第１の構成情報は、第１の表示情報を含む。

別の任意選択の実装形態においては、第１の送信モジュールはさらに、ダウンリンクコントロール情報ＤＣＩをＵＥへ送信するように特に構成され得る。ＤＣＩは、第１の表示情報を含む。

さらに別の任意選択の実装形態においては、第１の送信モジュールはさらに、第１の様式でエンコードされているＤＣＩをＵＥへ送信するステップであって、第１の様式は、第１のタイプの表示情報に対応し、第１の様式においては、ＤＣＩエンコーディング中に生成される巡回冗長検査ＣＲＣにスクランブリングコードが付加されない、ステップ、または第２の様式でエンコードされているＤＣＩをＵＥへ送信するステップであって、第２の様式は、第２のタイプの表示情報に対応し、第２の様式においては、ＤＣＩエンコーディング中に生成されるＣＲＣコードにスクランブリングコードが付加される、ステップを行うように特に構成され得る。

この実施形態において提供されている、キャリアアグリゲーションにおけるアップリンクコントロール情報送信装置は、特に基地局内に配置されることがあり、本発明の図５において示されている実施形態において提供されている、キャリアアグリゲーションにおけるアップリンクコントロール情報送信方法を実施するために使用され得る。それらの実施原理および技術的な効果は同様である。詳細がここで再び記述されることはない。

図１５は、本発明の実施形態による、キャリアアグリゲーションにおける別のアップリンクコントロール情報送信装置の概略図である。装置Ｂは、特に基地局内に配置されることがあり、本発明の、図５において示されている実施形態において提供されている、キャリアアグリゲーションにおけるアップリンクコントロール情報送信方法、および図７において示されている実施形態において提供されている、キャリアアグリゲーションにおけるＰＵＣＣＨリソース割り振り方法を実施するために使用され得る。詳細がここで再び記述されることはない。図１５において示されているように、図１４において示されている実施形態に基づいて、この実施形態においては、リソース割り振りモジュール１４２はさらに、構成モジュール１４２１、表示モジュール１４２２、および第２の送信モジュール１４２３を特に含み得る。

構成モジュール１４２１は、第２の構成情報を生成するように構成されることがあり、第２の構成情報は、ＵＥ用のリソースリストを構成するために使用され、そのリソースリストは、複数のリソース情報グループを含む。表示モジュール１４２２は、第２の表示情報を生成するように構成されることがあり、第２の表示情報は、リソースリスト内の１つのリソース情報グループに対応するＰＵＣＣＨリソースをＵＥに示すために使用される。第２の送信モジュール１４２３は、第２の構成情報および第２の表示情報をＵＥへ送信するように構成され得る。

第１の可能な実装形態においては、構成モジュール１４２１によってＵＥ用に構成されている複数のリソース情報グループが、別々のＰＵＣＣＨフォーマットに従ってアレンジされている場合には、それぞれのＰＵＣＣＨフォーマットは、少なくとも１つのリソース情報グループに対応し、それぞれのリソース情報グループは、１つのＰＵＣＣＨリソースの開始アドレス表示情報およびサイズ表示情報を含み、表示モジュール１４２２によって生成される第２の表示情報は、リソースインデックスＲＩを含むことがあり、ＲＩは、そのＲＩに対応する第１のリソース情報グループをＵＥに示すために使用される。

さらに、第２の送信モジュール１４２３は、送信電力コントロールＴＰＣフィールドを使用することによって第２の表示情報、すなわち、第１のリソース情報グループに対応するＲＩを送信するように特に構成され得る。

第２の可能な実装形態においては、構成モジュール１４２１によってＵＥ用に構成されている複数のリソース情報グループが、別々のＰＵＣＣＨフォーマットに従ってアレンジされている場合には、それぞれのＰＵＣＣＨフォーマットは、少なくとも１つのリソース情報グループに対応し、それぞれのリソース情報グループは、１つのＰＵＣＣＨリソースの開始アドレス表示情報を含み、表示モジュール１４２２によって生成される第２の表示情報は、リソースインデックスＲＩおよび長さインデックスＬＩを含み得る。ＲＩは、そのＲＩに対応する第２のリソース情報グループをＵＥに示すために使用され、ＬＩは、第２のリソース情報グループに対応するＰＵＣＣＨリソースのサイズをＵＥに示すために使用される。

さらに、第２の送信モジュール１４２３は、スケジュールされているキャリアに従ってＴＰＣフィールドの２つのグループを決定するステップであって、一方のグループは、第２のリソース情報グループに対応するＲＩを送信するために使用され、他方のグループは、第２のリソース情報グループに対応するＰＵＣＣＨリソースのサイズをＵＥに示すＬＩを送信するために使用される、ステップ、または拡張ＴＰＣフィールドを使用することによってＲＩおよびＬＩを送信するステップであって、その拡張ＴＰＣフィールドは、３ビット以上を含む、ステップを行うように特に構成され得る。

第３の可能な実装形態においては、構成モジュール１４２１によってＵＥ用に構成されているリソースリスト内のそれぞれのリソース情報グループが、１つのＰＵＣＣＨリソースの開始アドレス表示情報およびサイズ表示情報を含む場合には、表示モジュール１４２２によって生成される第２の表示情報は、リソースインデックスＲＩおよびフォーマットインデックスＦＩを含み得る。ＲＩは、そのＲＩに対応する第３のリソース情報グループをＵＥに示すために使用され、ＦＩは、第３のリソース情報グループに対応するＰＵＣＣＨリソースのフォーマットをＵＥに示すために使用される。

さらに、第２の送信モジュール１４２３は、スケジュールされているキャリアに従ってＴＰＣフィールドの２つのグループを決定するステップであって、一方のグループは、第３のリソース情報グループに対応するＲＩを送信するために使用され、他方のグループは、第３のリソース情報グループに対応するＰＵＣＣＨリソースのフォーマットをＵＥに示すＦＩを送信するために使用される、ステップ、または拡張ＴＰＣフィールドを使用することによってＲＩおよびＦＩを送信するステップであって、その拡張ＴＰＣフィールドは、３ビット以上を含む、ステップを行うように特に構成され得る。

第４の可能な実装形態においては、構成モジュール１４２１によってＵＥ用に構成されているリソースリスト内のそれぞれのリソース情報グループが、１つのＰＵＣＣＨリソースの開始アドレス表示情報を含む場合には、表示モジュール１４２２によって生成される第２の表示情報は、リソースインデックスＲＩ、フォーマットインデックスＦＩ、および長さインデックスＬＩを含み得る。ＲＩは、そのＲＩに対応する第４のリソース情報グループをＵＥに示すために使用され、ＦＩは、第４のリソース情報グループに対応するＰＵＣＣＨリソースのフォーマットをＵＥに示すために使用され、ＬＩは、第４のリソース情報グループに対応するＰＵＣＣＨリソースのサイズをＵＥに示すために使用される。

さらに、第２の送信モジュール１４２３は、スケジュールされているキャリアに従ってＴＰＣフィールドの３つのグループを決定するステップであって、第１のグループは、第４のリソース情報グループに対応するＲＩを送信するために使用され、第２のグループは、第４のリソース情報グループに対応するＰＵＣＣＨリソースのフォーマットをＵＥに示すＦＩを送信するために使用され、第３のグループは、第４のリソース情報グループに対応するＰＵＣＣＨリソースのサイズをＵＥに示すＬＩを送信するために使用される、ステップ、または拡張ＴＰＣフィールドを使用することによってＲＩ、ＦＩ、およびＬＩを送信するステップであって、その拡張ＴＰＣフィールドは、３ビット以上を含む、ステップを行うように特に構成され得る。

たとえば、第４の可能な実装形態においては、構成モジュール１４２１によってＵＥ用に構成されているリソースリストが、２つのリソース情報グループを含む場合には、第２の送信モジュール１４２３は、スケジュールされているキャリアに従ってＴＰＣフィールドの２つのグループを決定するステップであって、一方のグループは、第４のリソース情報グループに対応するＲＩと、第４のリソース情報グループに対応するＰＵＣＣＨリソースのフォーマットをＵＥに示すＦＩとを送信するために使用され、他方のグループは、第４のリソース情報グループに対応するＰＵＣＣＨリソースのサイズをＵＥに示すＬＩを送信するために使用される、ステップを行うように特に構成され得る。

この実施形態においては、第２の送信モジュール１４２３が、ＴＰＣフィールドの２つのグループを使用することによって、ＲＩ、ＦＩ、およびＬＩの対応する可能な組合せを送信する場合には、任意選択の実装形態においては、第２の送信モジュール１４２３は、スケジュールされているキャリアの識別番号の順序に従って、スケジュールされているキャリアを２つのグループへとグループ化するステップと、次いで、スケジュールされているキャリアの２つのグループのそれぞれの上のＴＰＣフィールドをＴＰＣフィールドの一方のグループとして決定するステップとを行うように特に構成されることがあり、別の任意選択の実装形態においては、スケジュールされているキャリアが、奇数である識別番号を有するスケジュールされているキャリアと、偶数である識別番号を有するスケジュールされているキャリアとを含む場合には、第２の送信モジュール１４２３はさらに、スケジュールされているキャリアのうちで奇数である識別番号を有するスケジュールされているキャリア上のＴＰＣフィールドをＴＰＣフィールドの一方のグループとして決定するステップと、スケジュールされているキャリアのうちで偶数である識別番号を有するスケジュールされているキャリア上のＴＰＣフィールドをＴＰＣフィールドの他方のグループとして決定するステップとを行うように特に構成され得る。

この実施形態において提供されている、キャリアアグリゲーションにおけるアップリンクコントロール情報送信装置は、特に基地局内に配置されることがあり、本発明の、図５において示されている実施形態において提供されている、キャリアアグリゲーションにおけるアップリンクコントロール情報送信方法、および図７において示されている実施形態において提供されている、キャリアアグリゲーションにおけるＰＵＣＣＨリソース割り振り方法を実施するために使用され得る。それらの実施原理および技術的な効果は同様である。詳細がここで再び記述されることはない。

図１６は、本発明の実施形態による基地局の概略図である。この基地局は、本発明の、図５において示されている実施形態において提供されている、キャリアアグリゲーションにおけるアップリンクコントロール情報送信方法、および図７において示されている実施形態において提供されている、キャリアアグリゲーションにおけるＰＵＣＣＨリソース割り振り方法を実施するために使用され得る。詳細がここで再び記述されることはない。図１６において示されているように、この実施形態において提供されている基地局は、トランシーバ１６１、メモリ１６２、およびプロセッサ１６３を含む。プロセッサ１６３は、メモリ１６２に結合されている。

具体的には、トランシーバ１６１は、第１の表示情報をユーザ機器ＵＥへ送信するステップであって、第１の表示情報は、その第１の表示情報に従ってアップリンクコントロール情報ＵＣＩを動的に決定するようＵＥに指示するために使用される、ステップを行うように構成され得る。プロセッサ１６３は、ＰＵＣＣＨリソースをＵＥへ割り振るステップであって、そのＰＵＣＣＨリソースは、ＵＣＩを送信するために使用される、ステップを行うように構成され得る。

この実施形態においては、第１の表示情報は、特に第１のタイプの表示情報または第２のタイプの表示情報であり得る。第１の表示情報が第１のタイプの表示情報である場合には、ＵＥは、スケジュールされているキャリアの数量に従って基地局がＤＡＩ情報を生成する場合に、第１のタイプの表示情報に従ってＵＣＩを決定する。第１の表示情報が第２のタイプの表示情報である場合には、ＵＥは、スケジュールされているコードワードの数量に従って基地局がＤＡＩ情報を生成する場合に、第２のタイプの表示情報に従ってＵＣＩを決定する。

実際の適用においては、トランシーバ１６１は、第１の構成情報をＵＥへ送信するステップであって、第１の構成情報は、第１の表示情報を含む、ステップを行うように特に構成され得る。トランシーバ１６１はさらに、ダウンリンクコントロール情報ＤＣＩをＵＥへ送信するステップであって、ＤＣＩは、第１の表示情報を含む、ステップを行うように特に構成され得る。代替として、トランシーバ１６１は、第１の様式でエンコードされているＤＣＩをＵＥへ送信するステップであって、第１の様式は、第１のタイプの表示情報に対応し、第１の様式においては、ＤＣＩエンコーディング中に生成される巡回冗長検査ＣＲＣコードにスクランブリングコードが付加されない、ステップ、または第２の様式でエンコードされているＤＣＩをＵＥへ送信するステップであって、第２の様式は、第２のタイプの表示情報に対応し、第２の様式においては、ＤＣＩエンコーディング中に生成されるＣＲＣコードにスクランブリングコードが付加される、ステップを行うように特に構成され得る。

実際の適用においては、プロセッサ１６２は、第２の構成情報および第２の表示情報を生成するように特に構成され得る。第２の構成情報は、ＵＥ用のリソースリストを構成するために使用され、そのリソースリストは、複数のリソース情報グループを含む。第２の表示情報は、リソースリスト内の１つのリソース情報グループに対応するＰＵＣＣＨリソースをＵＥに示すために使用される。さらに、トランシーバ１６１はさらに、第２の構成情報および第２の表示情報をＵＥへ送信するように構成され得る。

第１の可能な実装形態においては、複数のリソース情報グループが、別々のＰＵＣＣＨフォーマットに従ってアレンジされている場合には、それぞれのＰＵＣＣＨフォーマットは、少なくとも１つのリソース情報グループに対応し、それぞれのリソース情報グループは、１つのＰＵＣＣＨリソースの開始アドレス表示情報およびサイズ表示情報を含み、第２の表示情報は、リソースインデックスＲＩを含み、ＲＩは、そのＲＩに対応する第１のリソース情報グループをＵＥに示すために使用される。

さらに、トランシーバ１６１は、送信電力コントロールＴＰＣフィールドを使用することによって第２の表示情報、すなわち、第１のリソース情報グループに対応するＲＩを送信するように特に構成され得る。

第２の可能な実装形態においては、複数のリソース情報グループが、別々のＰＵＣＣＨフォーマットに従ってアレンジされている場合には、それぞれのＰＵＣＣＨフォーマットは、少なくとも１つのリソース情報グループに対応し、それぞれのリソース情報グループは、１つのＰＵＣＣＨリソースの開始アドレス表示情報を含み、第２の表示情報は、ＲＩを含み、ＲＩは、そのＲＩに対応する第２のリソース情報グループをＵＥに示すために使用される。加えて、第２の表示情報は、長さインデックスＬＩをさらに含み、ＬＩは、第２のリソース情報グループに対応するＰＵＣＣＨリソースのサイズをＵＥに示すために使用される。

さらに、トランシーバ１６１は、スケジュールされているキャリアに従ってＴＰＣフィールドの２つのグループを決定するステップであって、一方のグループは、第２のリソース情報グループに対応するＲＩを送信するために使用され、他方のグループは、第２のリソース情報グループに対応するＰＵＣＣＨリソースのサイズをＵＥに示すＬＩを送信するために使用される、ステップ、または拡張ＴＰＣフィールドを使用することによってＲＩおよびＬＩを送信するステップであって、その拡張ＴＰＣフィールドは、３ビット以上を含む、ステップを行うように特に構成され得る。

第３の可能な実装形態においては、リソースリスト内のそれぞれのリソース情報グループが、１つのＰＵＣＣＨリソースの開始アドレス表示情報およびサイズ表示情報を含む場合には、第２の表示情報は、ＲＩを含み、ＲＩは、そのＲＩに対応する第３のリソース情報グループをＵＥに示すために使用される。加えて、第２の表示情報は、フォーマットインデックスＦＩをさらに含み、ＦＩは、第３のリソース情報グループに対応するＰＵＣＣＨリソースのＰＵＣＣＨフォーマットをＵＥに示すために使用される。

さらに、トランシーバ１６１は、スケジュールされているキャリアに従ってＴＰＣフィールドの２つのグループを決定するステップであって、一方のグループは、第２のリソース情報グループに対応するＲＩを送信するために使用され、他方のグループは、第２のリソース情報グループに対応するＰＵＣＣＨリソースのフォーマットをＵＥに示すＦＩを送信するために使用される、ステップ、または拡張ＴＰＣフィールドを使用することによってＲＩおよびＦＩを送信するステップであって、その拡張ＴＰＣフィールドは、３ビット以上を含む、ステップを行うように特に構成され得る。

第４の可能な実装形態においては、リソースリスト内のそれぞれのリソース情報グループが、１つのＰＵＣＣＨリソースの開始アドレス表示情報を含む場合には、第２の表示情報は、ＲＩを含み、ＲＩは、そのＲＩに対応する第４のリソース情報グループをＵＥに示すために使用される。加えて、第２の表示情報は、ＦＩおよびＬＩをさらに含み、ＦＩは、第４のリソース情報グループに対応するＰＵＣＣＨリソースのＰＵＣＣＨフォーマットをＵＥに示すために使用され、ＬＩは、第４のリソース情報グループに対応するＰＵＣＣＨリソースのサイズをＵＥに示すために使用される。

さらに、トランシーバ１６１は、スケジュールされているキャリアに従ってＴＰＣフィールドの３つのグループを決定するステップであって、第１のグループは、第４のリソース情報グループに対応するＲＩを送信するために使用され、第２のグループは、第４のリソース情報グループに対応するＰＵＣＣＨリソースのフォーマットをＵＥに示すＦＩを送信するために使用され、第３のグループは、第４のリソース情報グループに対応するＰＵＣＣＨリソースのサイズをＵＥに示すＬＩを送信するために使用される、ステップ、または拡張ＴＰＣフィールドを使用することによってＲＩ、ＦＩ、およびＬＩを送信するステップであって、その拡張ＴＰＣフィールドは、３ビット以上を含む、ステップを行うように特に構成され得る。

たとえば、第４の可能な実装形態においては、リソースリストが、２つのリソース情報グループを含む（それぞれのリソース情報グループは、１つのＰＵＣＣＨリソースの開始アドレス表示情報を含む）場合には、トランシーバ１６１は、スケジュールされているキャリアに従ってＴＰＣフィールドの２つのグループを決定するステップであって、一方のグループは、第４のリソース情報グループに対応するＲＩと、第４のリソース情報グループに対応するＰＵＣＣＨリソースのフォーマットをＵＥに示すＦＩとを送信するために使用され、他方のグループは、第４のリソース情報グループに対応するＰＵＣＣＨリソースのサイズをＵＥに示すＬＩを送信するために使用される、ステップを行うように特に構成され得る。

この実施形態においては、トランシーバ１６１が、ＴＰＣフィールドの２つのグループを使用することによって、ＲＩ、ＦＩ、およびＬＩの対応する可能な組合せを送信する場合には、任意選択の実装形態においては、トランシーバ１６１は、スケジュールされているキャリアの識別番号の順序に従って、スケジュールされているキャリアを２つのグループへとグループ化するステップと、次いで、スケジュールされているキャリアの２つのグループのそれぞれの上のＴＰＣフィールドをＴＰＣフィールドの一方のグループとして決定するステップとを行うように特に構成されることがあり、別の任意選択の実装形態においては、スケジュールされているキャリアが、奇数である識別番号を有するスケジュールされているキャリアと、偶数である識別番号を有するスケジュールされているキャリアとを含む場合には、トランシーバ１６１はさらに、スケジュールされているキャリアのうちで奇数である識別番号を有するスケジュールされているキャリア上のＴＰＣフィールドをＴＰＣフィールドの一方のグループとして決定するステップと、スケジュールされているキャリアのうちで偶数である識別番号を有するスケジュールされているキャリア上のＴＰＣフィールドをＴＰＣフィールドの他方のグループとして決定するステップとを行うように特に構成され得る。

この実施形態において提供されている基地局は、本発明の、図５において示されている実施形態において提供されている、キャリアアグリゲーションにおけるアップリンクコントロール情報送信方法、および図７において示されている実施形態において提供されている、キャリアアグリゲーションにおけるＰＵＣＣＨリソース割り振り方法を実施するために使用され得る。実施原理および技術的な効果は同様である。詳細がここで再び記述されることはない。

本発明の実施形態はさらに、ＵＥと、図１４もしくは図１５において示されている実施形態において提供されている、キャリアアグリゲーションにおけるアップリンクコントロール情報送信装置を含む基地局とを含む、またはＵＥと、図１６において示されている実施形態において提供されている基地局とを含む複数の通信システムを提供する。

方法実施形態のステップのうちのすべてまたはいくつかは、関連するハードウェアに指示するプログラムによって実施され得るということを当技術分野における標準的な技術者なら理解し得る。そのプログラムは、コンピュータ可読ストレージメディア内に格納され得る。そのプログラムが作動したときに、方法実施形態のステップが実行される。前述のストレージメディアは、プログラムコードを格納することができる任意のメディア、たとえば、ＲＯＭ、ＲＡＭ、磁気ディスク、または光ディスクを含む。

最後に、前述の実施形態は、本発明の技術的なソリューションについて記述することを意図されているにすぎず、本発明を限定することを意図されているものではないということに留意されたい。前述の実施形態を参照しながら本発明が詳細に記述されているが、当技術分野における標準的な技術者なら、彼らが、それでもなお、本発明の実施形態の技術的なソリューションの範囲から逸脱することなく、前述の実施形態において記述されている技術的なソリューションに対する修正形態を作成し得る、またはそれらの技術的な特徴のいくつかまたはすべてに対する均等な代替形態を作成し得るということを理解するはずである。

本発明の実施形態は、通信技術に関し、詳細には、キャリアアグリゲーションにおけるアップリンクコントロール情報送信方法および装置に関する。

ロングタームエボリューション（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ、略してＬＴＥ）システムにおいては、ユーザ機器（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ、略してＵＥ）が、物理アップリンクコントロールチャネル（Ｐｈｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ、略してＰＵＣＣＨ）を使用することによって、アップリンクコントロール情報（Ｕｐｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ、略してＵＣＩ）を基地局へ送信する。ＵＣＩは、スケジューリング要求インジケータ（ｓｃｈｅｄｕｌｉｎｇ ｒｅｑｕｅｓｔ、ＳＲ）、ハイブリッド自動再送要求肯定応答／否定応答（Ｈｙｂｒｉｄ Ａｕｔｏｍａｔｉｃ Ｒｅｐｅａｔ ｒｅＱｕｅｓｔ ＡＣＫｎｏｗｌｅｄｇｅｍｅｎｔ ｏｒ Ｎｅｇａｔｉｖｅ ＡＣＫｎｏｗｌｅｄｇｅｍｅｎｔ、略してＨＡＲＱ−ＡＣＫ／ＮＡＣＫ）情報、すなわち、ＨＡＲＱフィードバック情報、およびチャネル状態情報（Ｃｈａｎｎｅｌ Ｓｔａｔｅ Ｉｎｆｏｒｍａｔｉｏｎ、略してＣＳＩ）を含む。ＳＲは、アップリンクスケジューリングを基地局に適用するためにＵＥによって使用される。ダウンリンクＨＡＲＱ−ＡＣＫ／ＮＡＣＫは、ダウンリンク送信されたデータのデコーディング結果を示して、ＰＤＳＣＨ上で送信されたダウンリンクデータに対してＨＡＲＱ肯定応答を実行するために使用される。ＣＳＩは、ダウンリンクスケジューリングをｅＮｏｄｅＢが実行するのを手助けする目的で、ダウンリンクチャネル品質に関連した情報をフィードバックするために使用される。

ロングタームエボリューションアドバンスト（ＬＴＥ−Ａｄｖａｎｃｅｄ、略してＬＴＥ−Ａ）システムにおいては、より高い送信帯域幅をサポートするために、キャリアアグリゲーション（Ｃａｒｒｉｅｒ Ａｇｇｒｅｇａｔｉｏｎ、略してＣＡ）技術が提供される。ＣＡとは、より高い送信帯域幅をサポートするために複数のコンポーネントキャリア（Ｃｏｍｐｏｎｅｎｔ Ｃａｒｒｉｅｒ、略してＣＣ）をアグリゲート（Ａｇｇｒｅｇａｔｅ：集合）することを意味する。ダウンリンクＣＡシナリオにおいては、基地局は、同じＵＥへ複数のＣＣ上でダウンリンクデータを送信する。それに応じて、ＵＥは、複数のダウンリンクＣＣ上でのＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報のフィードバックをサポートする必要がある。

ハイブリッド自動再送要求（Ｈｙｂｒｉｄ Ａｕｔｏｍａｔｉｃ Ｒｅｐｅａｔ ｒｅＱｕｅｓｔ、略してＨＡＲＱ）は、前方エラー訂正（Ｆｏｒｗａｒｄ Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｏｎ、略してＦＥＣ）方法と、自動再送要求（Ａｕｔｏｍａｔｉｃ Ｒｅｐｅａｔ ｒｅＱｕｅｓｔ、略してＡＲＱ）方法とを組み合わせる技術である。ＦＥＣを用いて訂正されることが不可能であるエラーに関しては、受信端が、ＡＲＱメカニズムを使用することによって、データを再送信するよう送信端に要求する。受信端は通常、受信されたデータパケット上でエラーが発生しているかどうかを検知するためにＣＲＣチェックコードを使用する。受信されたデータパケット上でエラーが発生していない場合には、受信端は、肯定応答（ＡＣＫｎｏｗｌｅｄｇｅｍｅｎｔ、略してＡＣＫ）を送信端へ送信する。受信されたデータパケット上でエラーが発生している場合には、受信端は、そのデータパケットを破棄し、否定応答（Ｎｅｇａｔｉｖｅ ＡＣＫｎｏｗｌｅｄｇｅｍｅｎｔ、略してＮＡＣＫ）を送信端へ送信し、送信端は、そのＮＡＣＫを受信した後に同じデータを再送信する。

標準化されている既存のＣＡにおいては、最大でも５つだけのキャリアのアグリゲーションがサポートされ、プロトコルにおいては、準静的な方法を使用することによってＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報が決定される。この準静的な方法においては、構成されているキャリアの数量が５以下である場合には、構成されているキャリアの数量、ならびにそれぞれの構成されているキャリアの送信モード（ｔｒａｎｓｍｉｓｓｉｏｎ ｍｏｄｅ、略してＴＭ）およびキャリア番号に従ってＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報のコードブックが決定される。この方法においては、構成されているがスケジュールされていない（すなわち、データ送信のために実際には使用されていない）キャリアがある場合、またはキャリア上で送信されるコードワードの数量が最大構成に達していない場合には、ＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報は、いくつかの無用なビットを埋め込まれる。

アグリゲートされることが可能であるキャリアの数量を大幅に増大させるために、第３世代パートナーシッププロジェクト（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ、略して３ＧＰＰ）が、ＬＴＥキャリアアグリゲーションエンハンスメントビヨンド５キャリア（略してｅＣＡ）を提供している。ｅＣＡは、最大で３２個のキャリアがアグリゲートされ、および複数のキャリアのＣＳＩ情報が１つのサブフレームにおいてフィードバック可能であることを必要とする。したがって、ＰＵＣＣＨを使用してフィードバックされるＵＣＩ情報が、大幅に増大される。もしＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報が既存のプロトコルの方法に従って決定される場合には、より多くのビットがフィードバックされる必要がある。したがって、データ送信負荷が増大し、有効なＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報を送信するパフォーマンスに影響して、そのＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報が正しく送信されることさえ不可能となる。したがって、ｅＣＡシナリオにおいて大量のＵＣＩ情報をどのようにしてフィードバックするかが、解決されるべき差し迫った問題になっている。

本発明の実施形態は、キャリアアグリゲーションにおけるアップリンクコントロール情報送信方法および装置を提供し、キャリアアグリゲーションシナリオにおけるＵＣＩ情報のフィードバックを実施するために使用され得る。

第１の態様によれば、キャリアアグリゲーションにおけるアップリンクコントロール情報送信方法であって、
基地局によって、第１の表示情報をユーザ機器ＵＥへ送信するステップであって、第１の表示情報は、その第１の表示情報に従ってアップリンクコントロール情報ＵＣＩを動的に決定するようＵＥに指示するために使用される、ステップと、
基地局によって、ＰＵＣＣＨリソースをＵＥへ割り振るステップであって、そのＰＵＣＣＨリソースは、ＵＣＩを送信するために使用される、ステップとを含む方法が提供される。

第１の態様の実装形態を参照して、第１の態様の第１の可能な実装形態においては、第１の表示情報は、第１のタイプの表示情報または第２のタイプの表示情報であり、第１のタイプの表示情報は、スケジュールされているキャリアの数量に従って基地局がダウンリンク割り当てインデックスＤＡＩ情報を生成する場合に、第１のタイプの表示情報に従ってＵＣＩを決定するようＵＥに指示するために使用され、第２のタイプの表示情報は、スケジュールされているコードワードの数量に従って基地局がＤＡＩ情報を生成する場合に、第２のタイプの表示情報に従ってＵＣＩを決定するようＵＥに指示するために使用される。

第１の態様、または第１の態様の第１の可能な実装形態を参照して、第１の態様の第２の可能な実装形態においては、基地局によって、第１の表示情報をＵＥへ送信するステップは、
基地局によって、第１の構成情報をＵＥへ送信するステップであって、第１の構成情報は、第１の表示情報を含む、ステップを含む。

第１の態様、または第１の態様の第１もしくは第２の可能な実装形態のうちのいずれか１つを参照して、第１の態様の第３の可能な実装形態においては、基地局によって、第１の表示情報をＵＥへ送信するステップは、基地局によって、ダウンリンクコントロール情報ＤＣＩをＵＥへ送信するステップであって、ＤＣＩは、第１の表示情報を含む、ステップを含む。

第１の態様、または第１の態様の第１乃至第３の可能な実装形態のうちのいずれか１つを参照して、第１の態様の第４の可能な実装形態においては、基地局によって、第１の表示情報をＵＥへ送信するステップは、
基地局によって、第１の様式でエンコードされているＤＣＩをＵＥへ送信するステップであって、第１の様式は、第１のタイプの表示情報に対応し、第１の様式においては、ＤＣＩエンコーディング中に生成される巡回冗長検査ＣＲＣコードにスクランブリングコードが付加されない、ステップ、または基地局によって、第２の様式でエンコードされているＤＣＩをＵＥへ送信するステップであって、第２の様式は、第２のタイプの表示情報に対応し、第２の様式においては、ＤＣＩエンコーディング中に生成されるＣＲＣコードにスクランブリングコードが付加される、ステップを含む。

第１の態様、または第１の態様の第１乃至第４の可能な実装形態のうちのいずれか１つを参照して、第１の態様の第５の可能な実装形態においては、基地局によって、ＰＵＣＣＨリソースをＵＥへ割り振るステップは、基地局によって、第２の構成情報をＵＥへ送信するステップであって、第２の構成情報は、ＵＥ用のリソースリストを構成するために使用され、そのリソースリストは、複数のリソース情報グループを含む、ステップと、基地局によって、第２の表示情報をＵＥへ送信するステップであって、第２の表示情報は、リソースリスト内の１つのリソース情報グループに対応するＰＵＣＣＨリソースをＵＥに示すために使用される、ステップとを含む。

第１の態様、または第１の態様の第１乃至第５の可能な実装形態のうちのいずれか１つを参照して、第１の態様の第６の可能な実装形態においては、複数のリソース情報グループは、別々のＰＵＣＣＨフォーマットに従ってアレンジされており、それぞれのＰＵＣＣＨフォーマットは、少なくとも１つのリソース情報グループに対応し、それぞれのリソース情報グループは、１つのＰＵＣＣＨリソースの開始アドレス表示情報およびサイズ表示情報を含み、第２の表示情報は、リソースインデックスＲＩを含み、ＲＩは、そのＲＩに対応する第１のリソース情報グループをＵＥに示すために使用される。

第１の態様、または第１の態様の第１乃至第６の可能な実装形態のうちのいずれか１つを参照して、第１の態様の第７の可能な実装形態においては、基地局によって、第２の表示情報をＵＥへ送信するステップは、基地局によって、送信電力コントロールＴＰＣフィールドを使用することによって第２の表示情報、すなわち、第１のリソース情報グループに対応するＲＩを送信するステップを含む。

第１の態様、または第１の態様の第１乃至第７の可能な実装形態のうちのいずれか１つを参照して、第１の態様の第８の可能な実装形態においては、複数のリソース情報グループは、別々のＰＵＣＣＨフォーマットに従ってアレンジされており、それぞれのＰＵＣＣＨフォーマットは、少なくとも１つのリソース情報グループに対応し、それぞれのリソース情報グループは、１つのＰＵＣＣＨリソースの開始アドレス表示情報を含み、第２の表示情報は、ＲＩを含み、ＲＩは、そのＲＩに対応する第２のリソース情報グループをＵＥに示すために使用され、第２の表示情報は、長さインデックスＬＩをさらに含み、ＬＩは、第２のリソース情報グループに対応するＰＵＣＣＨリソースのサイズをＵＥに示すために使用される。

第１の態様、または第１の態様の第１乃至第８の可能な実装形態のうちのいずれか１つを参照して、第１の態様の第９の可能な実装形態においては、基地局によって、第２の表示情報をＵＥへ送信するステップは、基地局によって、スケジュールされているキャリアに従ってＴＰＣフィールドの２つのグループを決定するステップであって、一方のグループは、第２のリソース情報グループに対応するＲＩを送信するために使用され、他方のグループは、第２のリソース情報グループに対応するＰＵＣＣＨリソースのサイズをＵＥに示すＬＩを送信するために使用される、ステップ、または基地局によって、拡張ＴＰＣフィールドを使用することによってＲＩおよびＬＩを送信するステップであって、その拡張ＴＰＣフィールドは、３ビット以上を含む、ステップを含む。

第１の態様、または第１の態様の第１乃至第９の可能な実装形態のうちのいずれか１つを参照して、第１の態様の第１０の可能な実装形態においては、リソースリスト内のそれぞれのリソース情報グループは、１つのＰＵＣＣＨリソースの開始アドレス表示情報およびサイズ表示情報を含み、第２の表示情報は、ＲＩを含み、ＲＩは、そのＲＩに対応する第３のリソース情報グループをＵＥに示すために使用され、第２の表示情報は、フォーマットインデックスＦＩをさらに含み、ＦＩは、第３のリソース情報グループに対応するＰＵＣＣＨリソースのＰＵＣＣＨフォーマットをＵＥに示すために使用される。

第１の態様、または第１の態様の第１乃至第１０の可能な実装形態のうちのいずれか１つを参照して、第１の態様の第１１の可能な実装形態においては、基地局によって、第２の表示情報をＵＥへ送信するステップは、基地局によって、スケジュールされているキャリアに従ってＴＰＣフィールドの２つのグループを決定するステップであって、一方のグループは、第３のリソース情報グループに対応するＲＩを送信するために使用され、他方のグループは、第３のリソース情報グループに対応するＰＵＣＣＨリソースのＰＵＣＣＨフォーマットをＵＥに示すＦＩを送信するために使用される、ステップ、または基地局によって、拡張ＴＰＣフィールドを使用することによってＲＩおよびＦＩを送信するステップであって、その拡張ＴＰＣフィールドは、３ビット以上を含む、ステップを含む。

第１の態様、または第１の態様の第１乃至第１１の可能な実装形態のうちのいずれか１つを参照して、第１の態様の第１２の可能な実装形態においては、リソースリスト内のそれぞれのリソース情報グループは、１つのＰＵＣＣＨリソースの開始アドレス表示情報を含み、第２の表示情報は、ＲＩを含み、ＲＩは、そのＲＩに対応する第４のリソース情報グループをＵＥに示すために使用され、第２の表示情報は、ＦＩおよびＬＩをさらに含み、ＦＩは、第４のリソース情報グループに対応するＰＵＣＣＨリソースのＰＵＣＣＨフォーマットをＵＥに示すために使用され、ＬＩは、第４のリソース情報グループに対応するＰＵＣＣＨリソースのサイズをＵＥに示すために使用される。

第１の態様、または第１の態様の第１乃至第１２の可能な実装形態のうちのいずれか１つを参照して、第１の態様の第１３の可能な実装形態においては、リソースリストは、２つのリソース情報グループを含み、基地局によって、第２の表示情報をＵＥへ送信するステップは、基地局によって、スケジュールされているキャリアに従ってＴＰＣフィールドの２つのグループを決定するステップであって、一方のグループは、第４のリソース情報グループに対応するＲＩと、第４のリソース情報グループに対応するＰＵＣＣＨリソースのＰＵＣＣＨフォーマットをＵＥに示すＦＩとを送信するために使用され、他方のグループは、第４のリソース情報グループに対応するＰＵＣＣＨリソースのサイズをＵＥに示すＬＩを送信するために使用される、ステップを含む。

第１の態様、または第１の態様の第１乃至第１３の可能な実装形態のうちのいずれか１つを参照して、第１の態様の第１４の可能な実装形態においては、基地局によって、スケジュールされているキャリアに従ってＴＰＣフィールドの２つのグループを決定するステップは、基地局によって、スケジュールされているキャリアの識別番号の順序に従って、スケジュールされているキャリアを２つのグループへとグループ化するステップと、スケジュールされているキャリアの２つのグループのそれぞれの上のＴＰＣフィールドをＴＰＣフィールドの一方のグループとして決定するステップとを含む。

第１の態様、または第１の態様の第１乃至第１４の可能な実装形態のうちのいずれか１つを参照して、第１の態様の第１５の可能な実装形態においては、スケジュールされているキャリアは、奇数である識別番号を有するスケジュールされているキャリアと、偶数である識別番号を有するスケジュールされているキャリアとを含み、基地局によって、スケジュールされているキャリアに従ってＴＰＣフィールドの２つのグループを決定するステップは、スケジュールされているキャリアのうちで奇数である識別番号を有するスケジュールされているキャリア上のＴＰＣフィールドをＴＰＣフィールドの一方のグループとして決定するステップと、スケジュールされているキャリアのうちで偶数である識別番号を有するスケジュールされているキャリア上のＴＰＣフィールドをＴＰＣフィールドの他方のグループとして決定するステップとを含む。

第２の態様によれば、キャリアアグリゲーションにおけるアップリンクコントロール情報送信装置であって、
第１の表示情報をユーザ機器ＵＥへ送信するステップであって、第１の表示情報は、その第１の表示情報に従ってアップリンクコントロール情報ＵＣＩを動的に決定するようＵＥに指示するために使用される、ステップを行うように構成されている第１の送信モジュールと、
ＰＵＣＣＨリソースをＵＥへ割り振るステップであって、そのＰＵＣＣＨリソースは、ＵＣＩを送信するために使用される、ステップを行うように構成されているリソース割り振りモジュールとを含む装置が提供される。

第２の態様の実装形態を参照して、第２の態様の第１の可能な実装形態においては、第１の表示情報は、第１のタイプの表示情報または第２のタイプの表示情報であり、第１のタイプの表示情報は、スケジュールされているキャリアの数量に従って基地局がダウンリンク割り当てインデックスＤＡＩ情報を生成する場合に、第１のタイプの表示情報に従ってＵＣＩを決定するようＵＥに指示するために使用され、第２のタイプの表示情報は、スケジュールされているコードワードの数量に従って基地局がＤＡＩ情報を生成する場合に、第２のタイプの表示情報に従ってＵＣＩを決定するようＵＥに指示するために使用される。

第２の態様、または第２の態様の第１の可能な実装形態を参照して、第２の態様の第２の可能な実装形態においては、第１の送信モジュールは、第１の構成情報をＵＥへ送信するステップであって、第１の構成情報は、第１の表示情報を含む、ステップを行うように特に構成されている。

第２の態様、または第２の態様の第１もしくは第２の可能な実装形態のうちのいずれか１つを参照して、第２の態様の第３の可能な実装形態においては、第１の送信モジュールは、ダウンリンクコントロール情報ＤＣＩをＵＥへ送信するステップであって、ＤＣＩは、第１の表示情報を含む、ステップを行うように特に構成されている。

第２の態様、または第２の態様の第１乃至第３の可能な実装形態のうちのいずれか１つを参照して、第２の態様の第４の可能な実装形態においては、第１の送信モジュールは、第１の様式でエンコードされているＤＣＩをＵＥへ送信するステップであって、第１の様式は、第１のタイプの表示情報に対応し、第１の様式においては、ＤＣＩエンコーディング中に生成される巡回冗長検査ＣＲＣコードにスクランブリングコードが付加されない、ステップ、または第２の様式でエンコードされているＤＣＩをＵＥへ送信するステップであって、第２の様式は、第２のタイプの表示情報に対応し、第２の様式においては、ＤＣＩエンコーディング中に生成されるＣＲＣコードにスクランブリングコードが付加される、ステップを行うように特に構成されている。

第２の態様、または第２の態様の第１乃至第４の可能な実装形態のうちのいずれか１つを参照して、第２の態様の第５の可能な実装形態においては、リソース割り振りモジュールは、構成モジュール、表示モジュール、および第２の送信モジュールを含み、構成モジュールは、第２の構成情報を生成するように構成されており、第２の構成情報は、ＵＥ用のリソースリストを構成するために使用され、そのリソースリストは、複数のリソース情報グループを含み、表示モジュールは、第２の表示情報を生成するように構成されており、第２の表示情報は、リソースリスト内の１つのリソース情報グループに対応するＰＵＣＣＨリソースをＵＥに示すために使用され、第２の送信モジュールは、第２の構成情報および第２の表示情報をＵＥへ送信するように構成されている。

第２の態様、または第２の態様の第１乃至第５の可能な実装形態のうちのいずれか１つを参照して、第２の態様の第６の可能な実装形態においては、複数のリソース情報グループは、別々のＰＵＣＣＨフォーマットに従ってアレンジされており、それぞれのＰＵＣＣＨフォーマットは、少なくとも１つのリソース情報グループに対応し、それぞれのリソース情報グループは、１つのＰＵＣＣＨリソースの開始アドレス表示情報およびサイズ表示情報を含み、第２の表示情報は、リソースインデックスＲＩを含み、ＲＩは、そのＲＩに対応する第１のリソース情報グループをＵＥに示すために使用される。

第２の態様、または第２の態様の第１乃至第６の可能な実装形態のうちのいずれか１つを参照して、第２の態様の第７の可能な実装形態においては、第２の送信モジュールは、送信電力コントロールＴＰＣフィールドを使用することによって第２の表示情報、すなわち、第１のリソース情報グループに対応するＲＩを送信するステップを行うように特に構成されている。

第２の態様、または第２の態様の第１乃至第７の可能な実装形態のうちのいずれか１つを参照して、第２の態様の第８の可能な実装形態においては、複数のリソース情報グループは、別々のＰＵＣＣＨフォーマットに従ってアレンジされており、それぞれのＰＵＣＣＨフォーマットは、少なくとも１つのリソース情報グループに対応し、それぞれのリソース情報グループは、１つのＰＵＣＣＨリソースの開始アドレス表示情報を含み、第２の表示情報は、ＲＩを含み、ＲＩは、そのＲＩに対応する第２のリソース情報グループをＵＥに示すために使用され、第２の表示情報は、長さインデックスＬＩをさらに含み、ＬＩは、第２のリソース情報グループに対応するＰＵＣＣＨリソースのサイズをＵＥに示すために使用される。

第２の態様、または第２の態様の第１乃至第８の可能な実装形態のうちのいずれか１つを参照して、第２の態様の第９の可能な実装形態においては、第２の送信モジュールは、スケジュールされているキャリアに従ってＴＰＣフィールドの２つのグループを決定するステップであって、一方のグループは、第２のリソース情報グループに対応するＲＩを送信するために使用され、他方のグループは、第２のリソース情報グループに対応するＰＵＣＣＨリソースのサイズをＵＥに示すＬＩを送信するために使用される、ステップ、または拡張ＴＰＣフィールドを使用することによってＲＩおよびＬＩを送信するステップであって、その拡張ＴＰＣフィールドは、３ビット以上を含む、ステップを行うように特に構成されている。

第２の態様、または第２の態様の第１乃至第９の可能な実装形態のうちのいずれか１つを参照して、第２の態様の第１０の可能な実装形態においては、リソースリスト内のそれぞれのリソース情報グループは、１つのＰＵＣＣＨリソースの開始アドレス表示情報およびサイズ表示情報を含み、第２の表示情報は、ＲＩを含み、ＲＩは、そのＲＩに対応する第３のリソース情報グループをＵＥに示すために使用され、第２の表示情報は、フォーマットインデックスＦＩをさらに含み、ＦＩは、第３のリソース情報グループに対応するＰＵＣＣＨリソースのＰＵＣＣＨフォーマットをＵＥに示すために使用される。

第２の態様、または第２の態様の第１乃至第１０の可能な実装形態のうちのいずれか１つを参照して、第２の態様の第１１の可能な実装形態においては、第２の送信モジュールは、スケジュールされているキャリアに従ってＴＰＣフィールドの２つのグループを決定するステップであって、一方のグループは、第３のリソース情報グループに対応するＲＩを送信するために使用され、他方のグループは、第３のリソース情報グループに対応するＰＵＣＣＨリソースのＰＵＣＣＨフォーマットをＵＥに示すＦＩを送信するために使用される、ステップ、または拡張ＴＰＣフィールドを使用することによってＲＩおよびＦＩを送信するステップであって、その拡張ＴＰＣフィールドは、３ビット以上を含む、ステップを行うように特に構成されている。

第２の態様、または第２の態様の第１乃至第１１の可能な実装形態のうちのいずれか１つを参照して、第２の態様の第１２の可能な実装形態においては、リソースリスト内のそれぞれのリソース情報グループは、１つのＰＵＣＣＨリソースの開始アドレス表示情報を含み、第２の表示情報は、ＲＩを含み、ＲＩは、そのＲＩに対応する第４のリソース情報グループをＵＥに示すために使用され、第２の表示情報は、ＦＩおよびＬＩをさらに含み、ＦＩは、第４のリソース情報グループに対応するＰＵＣＣＨリソースのＰＵＣＣＨフォーマットをＵＥに示すために使用され、ＬＩは、第４のリソース情報グループに対応するＰＵＣＣＨリソースのサイズをＵＥに示すために使用される。

第２の態様、または第２の態様の第１乃至第１２の可能な実装形態のうちのいずれか１つを参照して、第２の態様の第１３の可能な実装形態においては、リソースリストは、２つのリソース情報グループを含み、第２の送信モジュールは、スケジュールされているキャリアに従ってＴＰＣフィールドの２つのグループを決定するステップであって、一方のグループは、第４のリソース情報グループに対応するＲＩと、第４のリソース情報グループに対応するＰＵＣＣＨリソースのＰＵＣＣＨフォーマットをＵＥに示すＦＩとを送信するために使用され、他方のグループは、第４のリソース情報グループに対応するＰＵＣＣＨリソースのサイズをＵＥに示すＬＩを送信するために使用される、ステップを行うように特に構成されている。

第２の態様、または第２の態様の第１乃至第１３の可能な実装形態のうちのいずれか１つを参照して、第２の態様の第１４の可能な実装形態においては、第２の送信モジュールは、スケジュールされているキャリアの識別番号の順序に従って、スケジュールされているキャリアを２つのグループへとグループ化するステップと、スケジュールされているキャリアの２つのグループのそれぞれの上のＴＰＣフィールドをＴＰＣフィールドの一方のグループとして決定するステップとを行うように特に構成されている。

第２の態様、または第２の態様の第１乃至第１４の可能な実装形態のうちのいずれか１つを参照して、第２の態様の第１５の可能な実装形態においては、スケジュールされているキャリアは、奇数である識別番号を有するスケジュールされているキャリアと、偶数である識別番号を有するスケジュールされているキャリアとを含み、第２の送信モジュールは、スケジュールされているキャリアのうちで奇数である識別番号を有するスケジュールされているキャリア上のＴＰＣフィールドをＴＰＣフィールドの一方のグループとして決定するステップと、スケジュールされているキャリアのうちで偶数である識別番号を有するスケジュールされているキャリア上のＴＰＣフィールドをＴＰＣフィールドの他方のグループとして決定するステップとを行うように特に構成されている。

本発明の実施形態において提供されているキャリアアグリゲーションにおけるアップリンクコントロール情報送信方法および装置によれば、基地局は、第１の表示情報をユーザ機器ＵＥへ送信して、その第１の表示情報に従ってアップリンクコントロール情報ＵＣＩを動的に決定するようＵＥに指示し、基地局は、ＵＣＩを送信するためにＰＵＣＣＨリソースをＵＥへ割り振る。本発明の実施形態は、キャリアアグリゲーションシナリオにおけるＵＣＩ情報のフィードバックを実施し、それによって、有効なＵＣＩ情報を送信することのパフォーマンスを改善するために使用され得る。

本発明の実施形態における、または従来技術における技術的なソリューションについてより明確に記述するために、以降では、それらの実施形態または従来技術について記述するために必要とされる添付の図面について簡単に記述する。明らかに、以降の説明における添付の図面は、本発明のいくつかの実施形態を示しているにすぎず、当技術分野における標準的な技術者なら、それでもなお、創造的な取り組みを伴わずにこれらの添付の図面からその他の図面を導き出し得る。
関連した技術によるＬＴＥ−ＡシステムにおけるＦＤＤモードでのＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報のコードブックを決定することの概略図である。 スケジュールされているキャリアの数量に従ってＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報のコードブックを動的に決定することの概略図である。 スケジュールされているＣＷの数量に従ってＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報のコードブックを動的に決定することの概略図である。 図３において示されているソリューションに従って空間バンドリング処理を実行することの概略図である。 図３において示されているソリューションに従って空間バンドリング処理を実行することの概略図である。 本発明の実施形態による、キャリアアグリゲーションにおけるアップリンクコントロール情報送信方法のフローチャートである。 関連した技術によるＬＴＥ−ＡシステムにおけるＦＤＤモードでのＡＲＩインジケータの概略図である。 関連した技術によるＬＴＥ−ＡシステムにおけるＴＤＤモードでのＡＲＩインジケータの概略図である。 本発明の実施形態による、キャリアアグリゲーションにおけるＰＵＣＣＨリソース割り振り方法のフローチャートである。 ＲＲＣ構成シグナリングを使用することによってＵＥ用に構成されている第１のＰＵＣＣＨリソースリストの概略図である。 ＲＲＣ構成シグナリングを使用することによってＵＥ用に構成されている第２のＰＵＣＣＨリソースリストの概略図である。 ＲＲＣ構成シグナリングを使用することによってＵＥ用に構成されている第３のＰＵＣＣＨリソースリストの概略図である。 ＲＲＣ構成シグナリングを使用することによってＵＥ用に構成されている第４のＰＵＣＣＨリソースリストの概略図である。 ＲＲＣ構成シグナリングを使用することによってＵＥ用に構成されている第５のＰＵＣＣＨリソースリストの概略図である。 ＦＤＤモードにおけるキャリアスケジューリングの概略図である。 ＴＤＤモードにおけるキャリアスケジューリングの概略図である。 本発明の実施形態による、キャリアアグリゲーションにおけるアップリンクコントロール情報送信装置の概略図である。 本発明の実施形態による、キャリアアグリゲーションにおける別のアップリンクコントロール情報送信装置の概略図である。 本発明の実施形態による基地局の概略図である。

以降では、本発明の実施形態における添付の図面を参照しながら、本発明の実施形態における技術的なソリューションについて明確に記述する。明らかに、記述されている実施形態は、本発明の実施形態のうちのいくつかにすぎず、すべてではない。当技術分野における標準的な技術者によって本発明の実施形態に基づいて創造的な取り組みを伴わずに入手されるその他のすべての実施形態は、本発明の保護範囲内に収まるものとする。

本発明の実施形態においては、「第１の」、「第２の」などの用語は、類似しているオブジェクトどうしの間において区別を行うことを意図されているが、必ずしも特定の順序を示しているとは限らない。そのような方法で呼ばれているデータは、適切な状況において交換可能であり、それによって、本明細書において記述されている本発明の実施形態は、本明細書において示されているまたは記述されている順序以外の順序で実施されることが可能であるということを理解されたい。

本発明の実施形態は、ＬＴＥ−ＡにおけるＣＡまたはｅＣＡシナリオにおけるＵＣＩ情報のフィードバックに適用される。ＬＴＥ−Ａにおいては、基地局が、より高いレイヤのシグナリング、たとえば、無線リソースコントロール（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ、略してＲＲＣ）シグナリングを使用することによって、複数のＣＣ上でダウンリンクデータを受信するようにＵＥを構成する。それに対応して、ＵＥは、複数のＣＣ上で送信されたダウンリンクデータのＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報をフィードバックする必要がある。より高いレイヤのシグナリングを使用することによって基地局によって構成されている複数のダウンリンクＣＣのうちの１つが、プライマリーＣＣ（Ｐｒｉｍａｒｙ ＣＣ、略してＰＣＣ）であり、またはプライマリーセルＰｒｉｍａｒｙ ｃｅｌｌ、略してＰＣｅｌｌと呼ばれることがあり、別のＣＣが、セカンダリーＣＣ（Ｓｅｃｏｎｄａｒｙ ＣＣ、略してＳＣＣ）と呼ばれ、またはセカンダリーセルＳｅｃｏｎｄａｒｙ ｃｅｌｌ、略してＳＣｅｌｌと呼ばれることがある。ＵＥは、基地局によって割り振られたＰＵＣＣＨリソースを使用することによって、複数のＣＣのＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報をフィードバックする。

ＣＡシナリオにおいては、ＰＤＳＣＨデータがＳＣＣ上で送信される場合には、ＰＵＣＣＨフォーマット３を使用することによってＰＵＣＣＨ送信が実行される。準静的な構成と動的な表示とのハイブリッド方法を使用することによって、ＰＵＣＣＨリソースが割り振られる。すなわち、いくつかのＰＵＣＣＨフォーマット３リソースが、ＲＲＣ構成シグナリングを使用することによってＵＥ用に明示的に構成されることがあり、次いで、複数のＳＣＣ（少なくとも１つのＳＣＣ）の物理ダウンリンクコントロールチャネル（Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ、略してＰＤＣＣＨ）上で送信されるダウンリンクコントロール情報（Ｄｏｗｎｌｉｎｋ ｃｏｎｔｒｏｌ ｉｎｆｏｒｍａｔｉｏｎ、略してＤＣＩ）内の送信電力コントロール（Ｔｒａｎｓｍｉｔ Ｐｏｗｅｒ Ｃｏｎｔｒｏｌ、略してＴＰＣ）フィールドの値が、実際に使用されるＰＵＣＣＨフォーマット３リソースを示すために使用される（このケースにおいては、表示情報は、ＨＡＲＱ−ＡＣＫ／ＮＡＣＫ Ｒｅｓｏｕｒｃｅ Ｉｎｄｉｃａｔｏｒ、略してＡＲＩと呼ばれる）。表示情報は、ＲＲＣを使用することによって構成されているそれらのいくつかのリソースのうちの１つをユーザ機器に示す。本発明の実施形態において解決されることになる技術的な問題をより明確に理解するために、以降では、下記の例を使用することによって、既存のプロトコルにおけるキャリアアグリゲーションシナリオにおけるＵＣＩ情報のフィードバックについて記述する。

図１は、関連した技術によるＬＴＥ−ＡシステムにおけるＦＤＤモードでのＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報のコードブックを決定することの概略図である。図１を参照すると、基地局が、より高いレイヤのシグナリングを使用することによってＵＥ用に５つのキャリアを構成しており、それらの５つのキャリアに対応する送信モード（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｍｏｄｅ、略してＴＭ）によってサポートされる最大の送信されるコードワード（Ｃｏｄｅｗｏｒｄ、略してＣＷ）の数量は、順に２、１、２、２、および１である。スケジュールされているキャリアは、ＣＣ１、ＣＣ３、およびＣＣ５である。ＵＥは、ＣＣ１およびＣＣ３上でＤＣＩ情報を正しく受信しており、ＣＣ１上で送信された２つのＣＷ、およびＣＣ３上で送信された１つのＣＷを正しくデコードしているが、ＣＣ５上で送信されたＤＣＩ情報を正しく受信していない。したがってＵＥは、ＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報のコードブックが「１１０１００００」であるということを決定することができ、「１」に対応する情報はＡＣＫであり、「０」に対応する情報はＮＡＣＫである。既存のプロトコルにおけるＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報のサイズおよびランキングが、構成されているキャリアの数量、ならびにそれぞれの構成されているキャリアのＴＭに対応する最大コードワード数量およびキャリア番号に従って決定されるということが知られ得る。この方法においては、スケジュールされていない（すなわち、データ送信のために実際に使用されていない）構成されているキャリアがある場合、またはキャリア上で送信されるコードワードの数量が最大構成に達していない場合には、ＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報は、やはりいくつかの無用なビットを埋め込まれる。

ｅＣＡは、２０１５年１月に３ＧＰＰによって提供されたワイヤレスＬＴＥキャリアアグリゲーションエンハンスメントビヨンド５キャリア（ＷＩ ＬＴＥ Ｃａｒｒｉｅｒ Ａｇｇｒｅｇａｔｉｏｎ Ｅｎｈａｎｃｅｍｅｎｔ Ｂｅｙｏｎｄ ５ Ｃａｒｒｉｅｒｓ）の略称であり、アグリゲートされることが可能であるキャリアの数量が大幅に増大されるということを示し、最大で３２個のキャリアがアグリゲートされることを必要とする。ｅＣＡシナリオにおいては、より多くの構成されているキャリアがあり、最大で３２個の構成されているキャリアが存在し得る。既存のプロトコルにおける方法に従ってＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報が決定される場合には、ＨＡＲＱフィードバック情報の必要とされるコードブックがきわめて大きくなり得る。たとえば、３２個の構成されているキャリアに関しては、最大で６３８ビットがフィードバックされることになる。加えて、ｅＣＡシナリオにおいては、複数のＣＣのＣＳＩ情報が１つのサブフレームにおいてフィードバックされることが可能であることがさらに必要とされる。ＣＳＩ情報およびＨＡＲＱフィードバック情報が、同じサブフレームにおいて送信される必要がある場合には、ＵＣＩ情報のサイズがさらに増大される。簡単にするために、本発明の実施形態においては、ＨＡＲＱフィードバック情報のみが、例として使用されている。

ＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報のコードブックを決定した後に、ＵＥは、基地局によって割り振られたＰＵＣＣＨリソースを使用することによって、ＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報を基地局へ送信する必要がある。

現在のＬＴＥプロトコルは、３つのタイプの合計で７つのＰＵＣＣＨフォーマットを定義しており、別々のＰＵＣＣＨフォーマットは、別々のＵＣＩ情報コンテンツを搬送し、ＵＥは、送信される必要がある情報に従ってＰＵＣＣＨフォーマットを選ぶ。第１のタイプは、フォーマットｌｘであり、フォーマットｌ、フォーマットｌａ、およびフォーマットｌｂを含み、ＳＲ情報、またはＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報、またはＳＲ情報およびＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報を搬送する。第２のタイプは、フォーマット２ｘであり、フォーマット２、フォーマット２ａ、およびフォーマット２ｂを含み、ＣＳＩ、またはＣＳＩおよびＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報を搬送する。第３のタイプは、フォーマット３であり、キャリアアグリゲーション（Ｃａｒｒｉｅｒ Ａｇｇｒｅｇａｔｉｏｎ、略してＣＡ）におけるマルチＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報、および任意選択のＳＲ情報またはＣＳＩ情報を搬送するために使用される。前述の７つのＰＵＣＣＨフォーマットのうちでそのＰＵＣＣＨフォーマット３によって搬送されることが可能であるビットの数量が最も多く、最大で２２である。最大で３２個のキャリアが構成されている場合にフィードバックされる必要があり得る６３９ビットのＨＡＲＱフィードバック情報の要件を満たすことは不可能である。

これを考慮して、標準についての現在の論議のさなかに、新たなＰＵＣＣＨフォーマットのための複数の候補が提供されている。新たなＰＵＣＣＨフォーマットのための候補は、ＰＵＳＣＨベースのフォーマット、マルチＰＲＢ ＰＦ３（ＰＵＣＣＨフォーマット３）、リデューストＯＣＣ ＰＦ３、およびマルチリソースＰＦ３を含む。しかしながら、現在では、新たな利用可能なＰＵＣＣＨフォーマットによってサポートされる必要がある最大の搬送されるビットの数量は、１２８、２５６、３１９、または６３８であり得る。最終的に選択された新たなＰＵＣＣＨフォーマットによって搬送されることが可能であるビットの最大数量が６３８未満である場合には、そのフォーマットは依然として、すべてのＨＡＲＱフィードバック情報を送信するために搬送される必要があるビットの数量の要件を満たすことができない。ＨＡＲＱフィードバック情報のコードブックを決定するための方法が変更されていない場合には、たとえ新たなＰＵＣＣＨフォーマットを使用することによってＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報が送信されても、データ送信負荷が低減されることは不可能であり、有効な情報をフィードバックすることの送信パフォーマンスに影響を与える。

ＰＵＣＣＨフォーマットによって搬送されることが可能であるビットの数量は、制限されている。したがって既存のプロトコルは、ＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報のビットの数量を減らすためにＨＡＲＱフィードバック情報をバンドルするための処理方法を提供している。具体的には、２つのコードワードが送信されるＣＣに関しては、そのＣＣ上で同じダウンリンクサブフレームにおいて送信されるそれらの２つのＣＷに対応するＡＣＫ／ＮＡＣＫ情報に対してＡＮＤ論理演算が実行されて１ビットのＡＣＫ／ＮＡＣＫ情報を入手し得る。このプロトコルにおいては、これは、「空間ＨＡＲＱ−ＡＣＫ／ＮＡＣＫバンドリング」処理、すなわち、ＨＡＲＱフィードバック情報の空間バンドリングと呼ばれる。

標準についての現在の論議においては、ｅＣＡにおけるＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報のコードブックは、スケジュールされているキャリアに従って動的に決定されるということが合意されている。すなわち、ＨＡＲＱ情報をフィードバックするための、サブフレームにおけるＨＡＲＱコードブック（サイズおよびランキングを含む）は、スケジューリングケースに従ってさまざまであり得る。

図２は、スケジュールされているキャリアの数量に従ってＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報のコードブックを動的に決定することの概略図である。これは、以降では第１のソリューションと呼ばれる。このソリューションにおいては、キャリア上のＤＣＩ情報は、スケジュールされているキャリアの数（スケジュールされているキャリアの累積された数量とも呼ばれる）を示すために使用されるカウンタＣＣ（ｃｏｕｎｔｅｒ ＣＣ）値を含む。スケジュールされているキャリアの数量は、送信されるダウンリンクＤＣＩの断片の数量、およびダウンリンクＰＤＳＣＨの数量と整合している。したがってカウンタＣＣ値は、ＤＣＩの断片の累積された数量、またはＰＤＳＣＨの累積された数量も表し得る。カウンタＣＣ値に関する情報は、ダウンリンク割り当てのために使用されるＤＣＩ情報内に含まれる。加えて、合計ＣＣ（ｔｏｔａｌ ＣＣ）値が、サブフレームにおけるすべてのスケジュールされているキャリアの合計数量を表す。この値は、ダウンリンク割り当てのために使用されるＤＣＩ情報内に含まれることがあり、または別の様式で示されることがある。本明細書においては、この値が、ダウンリンク割り当てのために使用されるＤＣＩ内に含まれることは、限定ではなく、例として使用されているにすぎない。図において示されている例においては、基地局が、より高いレイヤのシグナリングを使用することによってＵＥ用に１０個のキャリアを構成しており、ＣＣ１、ＣＣ３、ＣＣ６、およびＣＣ１０が、スケジュールされているキャリアである。加えて、ＵＥは、ＣＣ１およびＣＣ６上でＤＣＩ情報を正しく受信しており、ＣＣ１のカウンタＣＣ値が１であるということ、およびＣＣ６のカウンタＣＣ値が３であるということを知り、ＣＣ１およびＣＣ６の両方の合計ＣＣ値が４であるということを知り、スケジュールされているＰＤＳＣＨから、ＣＣ１およびＣＣ６のそれぞれの上で送信された２つのＣＷを正しくデコードしているが、ＣＣ３およびＣＣ１０上でＤＣＩ情報を正しく受信していない。このソリューションにおいては、ＤＣＩ情報が失われているキャリア上でフィードバックされるＨＡＲＱビットの数量と、ＤＣＩ情報が失われていないキャリア上でフィードバックされるＨＡＲＱビットの数量との間における整合性を保つために、それぞれのＣＣ上で２つのコードワードが送信されるすべてのＣＣ上のＨＡＲＱフィードバック情報に対して空間バンドリングが実行される。ＣＣ１およびＣＣ６の両方のキャリア上のＨＡＲＱフィードバック情報のバンドリング結果が１である場合には、ＵＥは、ＣＣ１およびＣＣ６のカウンタ値に従って、２片のバンドルされたＨＡＲＱフィードバック情報がそれぞれ第１のビットロケーションおよび第３のビットロケーション上に配置されるということを決定することがあり、合計ＣＣ値４に従って、ＨＡＲＱフィードバック情報の合計長さが４ビットであるということを知ることがあり、それによって、ＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報のコードブックが「１０１０」であるということを決定する。

図２において示されている第１のソリューションにおいては、スケジュールされているＣＷの累積された数量が、ＤＣＩ内のカウンタＣＣ値に関する情報を使用することによって知られることが不可能であり、ＤＣＩが失われているＣＣ上で送信されるＣＷの数量が決定されることが不可能であるので、２つのＣＷを含むスケジュールされているキャリア上のＨＡＲＱフィードバック情報に対してデフォルトで空間バンドリングが実行されるということが知られ得る。スケジュールされているキャリア上で送信された２つのＣＷのどちらかがＵＥによって成功裏にデコードされそこなった場合には、ＵＥは、ＮＡＣＫ情報を基地局へフィードバックする。ＵＥによってフィードバックされたＮＡＣＫ情報を受信した後に、基地局は、ダウンリンクサブフレームにおいてＣＷのうちの両方が送信されそこなったとみなし、ダウンリンクサブフレームにおいてそれらの２つのＣＷを再送信する。これは、いくつかの不要な再送信をもたらし、ダウンリンクスループットパフォーマンスに影響を与える。

図３は、スケジュールされているＣＷの数量に従ってＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報のコードブックを動的に決定することの概略図である。これは、以降では第２のソリューションと呼ばれる。このソリューションにおいては、キャリア上のＤＣＩ情報は、スケジュールされているＣＷの数（スケジュールされているＣＷの累積された数量とも呼ばれる）を示すために使用されるカウンタＣＷ（ｃｏｕｎｔｅｒ ＣＷ）値に関する情報を含む。２つのＣＷがスケジュールされているキャリアに関しては、そのキャリアのカウンタＣＷ値が、第２のスケジュールされているＣＷの数を反映し、その数がＵＥによって正しく受信された後に、第１のＣＷの数もデフォルトで正しく受信されるということに留意されたい。カウンタＣＷ値に関する情報は、ダウンリンク割り当てのために使用されるＤＣＩ情報内に含まれる。加えて、合計ＣＷ（ｔｏｔａｌ ＣＷ）値に関する情報が、サブフレームにおけるすべてのスケジュールされているＣＷの合計数量を表す。この値は、ダウンリンク割り当てのために使用されるＤＣＩ情報内に含まれることがあり、または別の様式で示されることがある。本明細書においては、この値が、ダウンリンク割り当てのために使用されるＤＣＩ内に含まれることは、限定ではなく、例として使用されているにすぎない。図において示されている例においては、基地局が、より高いレイヤのシグナリングを使用することによってＵＥ用に１０個のキャリアを構成しており、ＣＣ１、ＣＣ３、ＣＣ６、およびＣＣ１０が、スケジュールされているキャリアである。加えて、ＵＥは、ＣＣ１およびＣＣ６上でＤＣＩ情報を正しく受信しており、ＣＣ１のカウンタＣＷ値が２であり、ＣＣ６のカウンタＣＷ値が５であるということを知り、ＣＣ１およびＣＣ６の両方の合計ＣＣ値が６であるということを知り、スケジュールされているＰＤＳＣＨから、ＣＣ１上で送信された２つのＣＷおよびＣＣ６上で送信された第１のＣＷを正しくデコードしているが、ＣＣ３およびＣＣ１０上でＤＣＩ情報を正しく受信していない。このケースにおいては、ＣＣ１のカウンタＣＷ値２と、ＤＣＩを復調することによって入手された、そのキャリア上で２つのＣＷがスケジュールされているという情報とに従って、ＵＥは、ＣＣ１がさらに、カウンタＣＣ値が１であるＨＡＲＱフィードバック情報に対応するということを推測することができる。次いで、ＨＡＲＱフィードバックコードブック全体の中でのＣＣ１上のＨＡＲＱフィードバック情報のロケーション（ランキングとも呼ばれる）が、第１のビットロケーションおよび第２のビットロケーションであり、コードワードのうちの両方が正しくデコードされているので、ＨＡＲＱフィードバック情報は「１１」である。同様に、ＨＡＲＱフィードバックコードブック全体の中でのＣＣ６上のＨＡＲＱフィードバック情報のロケーション（ランキングとも呼ばれる）が、第４のビットロケーションおよび第５のビットロケーションであり、第１のＣＷのみが正しくデコードされており、第２のＣＷがデコードされそこなっているので、ＨＡＲＱフィードバック情報は「１０」であることが知られ得る。加えてＵＥは、受信された合計ＣＷ値６に従って、ＨＡＲＱフィードバックコードブックのビットの合計数量が６であるということを決定し得る。したがってＵＥは、ＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報のコードブックが「１１０１００」であるということを最終的に決定する。

最後に、第１のソリューションにおけるカウンタＣＣ値および合計ＣＣ値、ならびに第２のソリューションにおけるカウンタＣＷ値および合計ＣＷ値は、キャリアドメイン（ｃｅｌｌ−ｄｏｍａｉｎ）または周波数ドメイン（ｆｒｅｑｕｅｎｃｙ−ｄｏｍａｉｎ）におけるダウンリンク割り当てインデックス（Ｄｏｗｎｌｉｎｋ Ａｓｓｉｇｎｍｅｎｔ Ｉｎｄｅｘ、略してＤＡＩ）情報と呼ばれることがある。第１のソリューションにおいては、基地局は、スケジュールされているキャリアを使用することによってＤＡＩ情報を生成する。第２のソリューションにおいては、基地局は、スケジュールされているコードワードを使用することによってＤＡＩ情報を生成する。

図３において示されている第２のソリューションにおいては、空間バンドリング処理がさらにＨＡＲＱフィードバック情報に対して実行される必要がある場合には、ＵＥは、ＨＡＲＱフィードバック情報のコードブックサイズに関して不確かであることがあり、したがって基地局およびＵＥは、ＨＡＲＱフィードバックコードブックについての不整合な理解を有する。詳細に関しては、図４Ａおよび図４Ｂにおいて示されている２つのケースを参照されたい。複数のコードワードが失われている場合には、ＵＥは、ＣＣ１およびＣＣ６のカウンタＣＷ値に関する受信された情報を使用することによって、２つのキャリアのそれぞれの上の１つのＣＷ（すなわち、図４ＡにおけるＣＣ２およびＣＣ３のそれぞれの上の１つのＣＷ）が失われているのか、または１つのキャリア上の２つのＣＷ（すなわち、図４ＢにおけるＣＣ４上の２つのＣＷ）が失われているのかを決定することができない。したがって、第２のソリューションにおける空間バンドリング中に、バンドルされるビットの数量が決定されることが不可能であり、５ビット（図４Ａ）または４ビット（図４Ｂ）があり得る。しかしながら、このケースにおいては、基地局はスケジューリングケースを明確に知る。ＵＥは、バンドルされるＨＡＲＱフィードバック情報のビットの数量に関して不確かであるので、フィードバックビットの数量が実際のケースと不整合であることがあり、すなわち、基地局およびＵＥは、ＨＡＲＱフィードバックコードブックについての不整合な理解を有し、ＵＥは、ＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報を正確に送信することができない。

これを考慮して、本発明の実施形態は、キャリアアグリゲーションにおけるＵＣＩ送信方法を提供する。基地局が、表示情報をＵＥへ送信し、それによってＵＥは、その表示情報に従って、ＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報のコードブックを決定する様式を選択する。

本発明の下記の実施形態において提供されている、キャリアアグリゲーションにおけるアップリンクコントロール情報送信方法は、基地局によって実行される。

図５は、本発明の実施形態による、キャリアアグリゲーションにおけるアップリンクコントロール情報送信方法のフローチャートである。図５において示されているように、この実施形態において提供されている、キャリアアグリゲーションにおけるアップリンクコントロール情報送信方法は、下記のステップを含み得る。

Ｓ５１． 基地局が、第１の表示情報をＵＥへ送信し、第１の表示情報は、その第１の表示情報に従ってＵＣＩを動的に決定するようＵＥに指示するために使用される。

本明細書における動的な決定は、ＵＣＩをフィードバックするための、それぞれのサブフレームにおけるＵＣＩ情報、特にＨＡＲＱフィードバック情報のコードブックが、実際にスケジュールされているキャリアまたはコードワードのケースに従ってさまざまであり得るということを意味する。

Ｓ５２． 基地局は、ＰＵＣＣＨリソースをＵＥへ割り振り、そのＰＵＣＣＨリソースは、ＵＣＩを送信するために使用される。

この実施形態においては、第１の表示情報は、特に第１のタイプの表示情報または第２のタイプの表示情報であり得る。第１の表示情報が第１のタイプの表示情報である場合には、ＵＥは、スケジュールされているキャリアの数量に従って基地局がＤＡＩ情報を生成する場合に、第１のタイプの表示情報に従ってＵＣＩを決定する。第１の表示情報が第２のタイプの表示情報である場合には、ＵＥは、スケジュールされているコードワードの数量に従って基地局がＤＡＩ情報を生成する場合に、第２のタイプの表示情報に従ってＵＣＩを決定する。本明細書におけるＤＡＩ情報は、図２において示されている第１のソリューションにおけるカウンタＣＣ値および図３において示されている第２のソリューションにおけるカウンタＣＷ値に関する情報を含むということに留意されたい。加えて、ＤＡＩ情報は、第１のソリューションにおける合計ＣＣ値に関する情報、および図３において示されている第２のソリューションにおける合計ＣＷ値に関する情報をさらに含み得る。これは、本明細書においては限定されない。

基地局は、現在のスケジューリングケースに従って生成されるべきＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報のビットの数量を明確に知り、ＰＵＣＣＨ送信のために使用される新たなＰＵＣＣＨフォーマットによって搬送されるビットの表示されることになる最大数量を明確に知るということに留意されたい。したがって基地局は、現在のスケジューリングに関して実際にフィードバックされる必要があるＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報のビットの数量と、新たなＰＵＣＣＨフォーマットによって搬送されるビットの最大数量との間における関係に従って、ダウンリンク割り当てインデックス（Ｄｏｗｎｌｉｎｋ Ａｓｓｉｇｎｍｅｎｔ Ｉｎｄｅｘ、略してＤＡＩ）情報の送信様式を選択し得る。

具体的には、フィードバックされる必要があるＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報のビットの数量が、ＰＵＣＣＨ送信のために使用される新たなＰＵＣＣＨフォーマットによって搬送されるビットの最大数量よりも多い場合には、基地局は、スケジュールされているキャリアの数量に従ってＤＡＩ情報を生成し、表示情報（第１のタイプの表示情報と呼ばれることがある）を使用することによってＤＡＩの生成様式をＵＥに通知し、ＵＥは、基地局によって送信される表示情報に従って、ＨＡＲＱフィードバック情報に対して空間バンドリング処理を実行することを決定する。フィードバックされる必要があるＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報のビットの数量が、ＰＵＣＣＨ送信のために使用される新たなＰＵＣＣＨフォーマットによって搬送されるビットの最大数量以下である場合には、基地局は、スケジュールされているコードワードの数量に従ってＤＡＩ情報を生成し、表示情報（第２のタイプの表示情報と呼ばれることがある）を使用することによってＤＡＩの生成様式をＵＥに通知し、ＵＥは、基地局によって送信される表示情報に従って、ＨＡＲＱフィードバック情報に対して空間バンドリング処理を実行しないことを決定する。したがって、基地局によってＵＥへ送信される表示情報はさらに、スケジュールされているキャリアのＨＡＲＱ情報に対して空間バンドリングを実行するようＵＥに基地局が指示しているかどうかを示す表示情報と理解され得る。基地局によってＵＥへ送信される表示情報は、第１の表示情報と呼ばれる。

任意選択で、基地局は、ＲＲＣ構成シグナリングを使用することによってＵＥへ第１の表示情報を送信し得るか、または第１の表示情報を送信するための新たなデータフィールドをダウンリンクコントロール情報（Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ、略してＤＣＩ）に付加し得る。代替として、基地局は、第１の表示情報を送信するためにＤＣＩ内の元のデータフィールドを再利用し得る。

別の任意選択の実装形態においては、基地局は代替として、その基地局が、スケジュールされているキャリアの数量に従ってＤＡＩ情報を生成するか、またはスケジュールされているコードワードの数量に従ってＤＡＩ情報を生成するかを別々のＤＣＩエンコーディングモードでＵＥに示すことがあり、すなわち、別々のエンコーディングモードは、別々のタイプの表示情報に対応する。

たとえば、基地局がＤＣＩをエンコードする際に、ＤＣＩエンコーディング中に生成される巡回冗長検査（Ｃｙｃｌｉｃ Ｒｅｄｕｎｄａｎｃｙ Ｃｈｅｃｋ、ＣＲＣ）コード、および固定されたシーケンス（たとえば、８ビットのＣＲＣに関しては、固定されたシーケンスは、２進数での「１０１１０１１０」であり得る）に対して排他的ＯＲ演算が実行されることがあり、またはＣＲＣに対して何の処理も実行されないことがある（これは、２進数での固定されたシーケンス「００００００００」を使用することによって排他的ＯＲ演算を実行することと同等である）。すなわち、基地局は、ＣＲＣコードにスクランブリングコードを付加するか、またはＣＲＣコードにスクランブリングコードを付加しない（これは、別々の固定されたシーケンスを使用することによってＣＲＣをスクランブルすることと同等であり得る）。ＵＥがＤＣＩをデコードする際に、ＵＥがＤＣＩを直接デコードすることができる場合には、それは、ＤＣＩエンコーディング中に生成されるＣＲＣコードに基地局がスクランブリングコードを付加していないということを示し、したがってＵＥは、スケジュールされているキャリアの数量に従って基地局がＤＡＩ情報を生成しているということを知ることができる。それとは逆に、ＵＥがＤＣＩを直接デコードすることができないが、既知の固定されたシーケンス「１０１１０１１０」を使用することによってＤＣＩを正しくデコードすることができる場合には、それは、ＤＣＩエンコーディング中に生成されるＣＲＣコードに基地局がスクランブリングコードを付加しているということを示し、したがってＵＥは、スケジュールされているコードワードの数量に従って基地局がＤＡＩ情報を生成しているということを知ることができる。

この実施形態において提供されている、キャリアアグリゲーションにおけるアップリンクコントロール情報送信方法によれば、基地局は、表示情報をＵＥへ送信し、ＵＥは、その表示情報に従ってＵＣＩのコードブック（すなわち、ＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報）を動的に決定し、それによって、有効なＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報を送信することのパフォーマンスを改善する。

上述のように、基地局は現在、ＰＵＣＣＨリソースをＵＥへ割り振っている。ＣＡシナリオにおいては、基地局は、ＲＲＣ構成シグナリングを使用することによってＵＥ用にいくつかのリソースを明示的に構成し、次いで、ＲＲＣを使用することによって構成されているいくつかのリソースのうちの１つを、ＨＡＲＱ−ＡＣＫ／ＮＡＣＫリソースインジケータ（ＨＡＲＱ−ＡＣＫ／ＮＡＣＫ Ｒｅｓｏｕｒｃｅ Ｉｎｄｉｃａｔｏｒ、略してＡＲＩ）情報を使用することによってユーザ機器に示し得る。

既存のＬＴＥ−ＡシステムにおけるＣＡシナリオにおいては、最大で５つのキャリアが構成され、ＰＵＣＣＨリソースが、ＲＲＣを使用することによって構成され、またはＲＲＣおよびＡＲＩインジケータを一緒に使用することによって構成される。既存のプロトコルにおいては、リソース構成のために使用されるＲＲＣシグナリングユニットは、下記のとおりである。

ＣＨＯＩＣＥは、フォーマット３およびｃｈａｎｎｅｌＳｅｌｅｃｔｉｏｎのどちらかがＰＵＣＣＨフォーマットとして選択されるということを示す。たとえば、フォーマット３が選択される。４つのリソース（ＳＥＱＵＥＮＣＥ（ＳＩＺＥ（１．．４））ＯＦ ＩＮＴＥＧＥＲ（０．．５４９））が構成され、それぞれのリソースは、１つのＩＮＴＥＧＥＲ値によって表される。

既存のプロトコルにおいては、ＡＲＩ情報は、ＬＴＥ−Ａにおけるダウンリンクコントロール情報（Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ、略してＤＣＩ）内のＴＰＣフィールドを再利用することによって送信される。具体的には、ＤＣＩ内のＴＰＣフィールドを再利用することは、ＳＣＣ上のＤＣＩ内のＴＰＣフィールド内のＡＲＩ情報を送信することを意味し、その一方で、ＰＣＣ上のＤＣＩ内のＴＰＣフィールド内の電力コントロールコマンドが依然として送信されて、ＵＥのＰＵＣＣＨ送信電力を基地局がコントロールすることができるということを確実にする。

現在、ＬＴＥ−Ａシステムにおいては、プロトコルはさらに、周波数分割複信（Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｄｕｐｌｅｘ、略してＦＤＤ）モードおよび時分割複信（Ｔｉｍｅ Ｄｉｖｉｓｉｏｎ Ｄｕｐｌｅｘ、略してＴＤＤ）モードという両方の複信モードがＬＴＥ−Ａシステムにおいてサポートされる必要があるということを指定している。具体的には、ＬＴＥ−ＡシステムにおけるＦＤＤモードにおいては、１つだけのダウンリンクサブフレームのＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報をフィードバックするために１つのアップリンクサブフレームが使用され、ＬＴＥ−ＡシステムにおけるＴＤＤモードにおいては、複数のダウンリンクサブフレームのＨＡＲＱ−ＡＣＫ情報をフィードバックするためにいくつかのアップリンクサブフレームのそれぞれが使用される必要がある。

図６Ａは、関連した技術によるＬＴＥ−ＡシステムにおけるＦＤＤモードでのＡＲＩインジケータの概略図である。この図においては、Ｎ−４およびＮは、フレーム番号を表しており、ＦＤＤでのダウンリンクＰＤＳＣＨデータとアップリンクフィードバックとの間におけるタイムインターバルは、４つのサブフレームである。図６Ａにおいて示されているように、ＦＤＤモードにおいては、ＰＣＣ上で受信されるダウンリンクコントロール情報（Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ、略してＤＣＩ）内のすべてのＰＵＣＣＨ ＴＰＣ（ＰＵＣＣＨ用のＴＰＣコマンド）フィールドは、ＰＵＣＣＨ電力コントロールのために使用され、すべてのＳＣＣ上で受信されるダウンリンクＤＣＩ内のすべてのＰＵＣＣＨ ＴＰＣフィールドは、特定のＰＵＣＣＨフォーマット３リソースを選択するよう指示するために使用される。加えて、同じサブフレームにおけるすべてのＳＣＣ上でＵＥによって受信されるＰＵＣＣＨ ＴＰＣフィールド値は同じである必要がある。ＰＵＣＣＨ ＴＰＣフィールド値に関しては、表１において示されているＴＰＣフィールド値の意味を参照されたい。

図６Ｂは、関連した技術によるＬＴＥ−ＡシステムにおけるＴＤＤモードでのＡＲＩインジケータの概略図である。図６Ｂにおいて示されているように、ＴＤＤモードにおいては、１に等しいダウンリンク割り当てインデックス（Ｄｏｗｎｌｉｎｋ Ａｓｓｉｇｎｍｅｎｔ Ｉｎｄｅｘ、略してＤＡＩ）を有する、ＰＣＣ上で受信されるダウンリンクＤＣＩ内のすべてのＰＵＣＣＨ ＴＰＣフィールドは、ＰＵＣＣＨ電力コントロールのために使用され、１よりも大きいＤＡＩを有する、ＰＣＣ上で受信されるダウンリンクＤＣＩ内のすべてのＰＵＣＣＨ ＴＰＣフィールド、およびすべてのＳＣＣ上で受信されるダウンリンクＤＣＩ内のすべてのＰＵＣＣＨ ＴＰＣフィールドは、特定のＰＵＣＣＨフォーマット３リソースを選択するよう指示するために使用される。加えて、１よりも大きいＤＡＩを有する、ＰＣＣ上でＵＥによって受信されるダウンリンクＤＣＩ内のすべてのＰＵＣＣＨ ＴＰＣフィールドは、ＳＣＣ上で受信されるＰＵＣＣＨ ＴＰＣフィールドと同じである必要がある。サブフレームＳは、ＴＤＤモードにおける特別なサブフレームであり、ダウンリンクコントロール情報を送信するためにも使用され得る。

既存のプロトコルにおいては、ＡＲＩインジケータのために使用される、それぞれのキャリア上のＴＰＣフィールドが、２ビットのみを含み、４つの利用可能なリソースがあるということに留意されたい。ＡＲＩインジケータは、ＵＣＩを送信するためのリソースとして、４つの利用可能なリソースから１つのリソースを選択するために使用される。

上述のように、既存のプロトコルにおいて定義されている７つのＰＵＣＣＨフォーマットのうちでＰＵＣＣＨフォーマット３によって搬送されることが可能であるＵＣＩ情報ビットの数量が最も多く、最大で２２ビットが搬送される。ＰＵＣＣＨフォーマット３送信フォーマットにおいては、エンコードされた後に、２２ビットの元の情報が、１つのみの物理リソースブロック（Ｐｈｙｚｉｃａｌ Ｒｅｓｏｕｒｃｅ Ｂｌｏｃｋ、略してＰＲＢ）ペア上で搬送される必要がある。したがって、最大で５つのキャリアが構成される既存のＣＡシナリオにおいては、それぞれのＰＵＣＣＨフォーマットが、１つのＰＲＢペアのリソースを占める。ｅＣＡシナリオにおいては、最大で３２個のＣＣが構成されることが可能であり、それぞれのサブフレームが、複数のＣＣのＣＳＩ情報をフィードバックするために使用されることが可能である。したがって、ＰＵＣＣＨを使用することによってフィードバックされるＵＣＩ情報が大幅に増大され、複数のＰＲＢペアのリソースを占め得る。

本発明の図５において示されている実施形態において提供されている、ＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報をフィードバックするための方法においては、ＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報のコードブックが、スケジュールされているキャリアの数量、またはスケジュールされているコードワードの数量に従って動的に決定され得る。これが意味するのは、それぞれのサブフレームにおいてＨＡＲＱ−ＡＣＫ／ＮＡＣＫ送信のために使用されるＰＵＣＣＨによって占められるリソースが変わり、異なるＰＵＣＣＨフォーマットが選択され得るということである。

本発明の図５において示されている実施形態において提供されている、ＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報をフィードバックするための方法をサポートするためには、基地局がさらに、ＰＵＣＣＨリソースをＵＥへ割り振る必要があり、そのＰＵＣＣＨリソースを使用することによってＨＡＲＱ−ＡＣＫ／ＮＡＣＫ情報が送信される。

これを考慮して、本発明の実施形態はさらに、ｅＣＡ用に設計されている新たなＰＵＣＣＨフォーマットのリソース割り振りおよびＰＵＣＣＨフォーマット表示を提供する。この実施形態において提供されている、キャリアアグリゲーションにおけるＰＵＣＣＨリソース割り振り方法はまた、最大で５つのキャリアがアグリゲートされる既存のシナリオに適用可能であるということが理解され得る。この実施形態において提供されている、キャリアアグリゲーションにおけるＰＵＣＣＨリソース割り振り方法は、基地局によって実行される。

図７は、本発明の実施形態による、キャリアアグリゲーションにおけるＰＵＣＣＨリソース割り振り方法のフローチャートである。図７において示されているように、この方法は、下記のステップを含み得る。

Ｓ７１． 基地局が、第２の構成情報をＵＥへ送信し、第２の構成情報は、ＵＥ用のリソースリストを構成するために使用され、そのリソースリストは、複数のリソース情報グループを含む。

Ｓ７２． 基地局は、第２の表示情報をＵＥへ送信し、第２の表示情報は、リソースリスト内の１つのリソース情報グループに対応するＰＵＣＣＨリソースをＵＥに示すために使用される。

この実施形態においては、基地局は、ＲＲＣ構成シグナリングを使用することによってＵＥ用にいくつかのリソースを構成することがあり、すなわち、基地局は、ＲＲＣ構成シグナリングを使用することによってＵＥ用のＰＵＣＣＨリソースリストを構成することがある。そのリソースリストは、複数のリソース情報グループを含み、それぞれのリソース情報グループは、１つのＰＵＣＣＨリソースに対応する。

加えて、この実施形態においては、基地局は、ＵＥによって送信されるＨＡＲＱフィードバック情報のコードブックサイズを、スケジュールされているキャリアに従って動的に決定することができる。したがって、さまざまな無線チャネル状況におけるさまざまなコードブックサイズに従って、さまざまなＰＵＣＣＨリソースサイズまたはさまざまなＰＵＣＣＨフォーマットのＰＵＣＣＨリソースが、ＵＥ用に基地局によって構成されているＰＵＣＣＨリソースリストから、使用のために選択され得る。本明細書におけるＰＵＣＣＨリソースサイズは、ＰＲＢペアの数量を指し、この実施形態における割り振られるリソースどうしは連続しているので、ＰＵＣＣＨリソースサイズはまた、ＰＲＢペアの長さと呼ばれ得るということに留意されたい。具体的には、第２の表示情報は、リソースリスト内のリソース情報グループに対応するＰＵＣＣＨリソースをＵＥに示すために使用され得る。具体的には、第２の表示情報はＡＲＩ情報であり得る。

ＰＵＣＣＨ上で搬送されるＵＣＩ情報のコードブックサイズを決定するための方法は、リソース割り振り様式上に比較的大きなインパクトを及ぼし、そのコードブックサイズは、ＵＣＩ情報ビットの数量であるということに留意されたい。本明細書においては、ＨＡＲＱ−ＡＣＫ／ＮＡＣＫコードブックサイズを決定することは、この実施形態の適用シナリオについて記述するための例として使用される。既存のプロトコルにおいては、ＨＡＲＱ−ＡＣＫ／ＮＡＣＫコードブックサイズは、構成されているキャリアの数量、およびそれぞれのキャリアの送信モード（Ｔｒａｎｓｍｉｔ Ｍｏｄｅ、略してＴＭ）に依存する。これらのパラメータは、準静的に構成される。したがって、ＨＡＲＱ−ＡＣＫ／ＮＡＣＫコードブックサイズも準静的に構成されるとみなされ得る。構成が変更されない場合には、すべてのサブフレームにおけるユーザのコードブックサイズは同じである。しかしながら、別々のＰＵＣＣＨフォーマットは、別々のコードブックサイズに関して別々のパフォーマンスを有する。これが意味するのは、複数のＰＵＣＣＨフォーマットが使用のために考慮される場合には、パフォーマンスを最適化するために別々のサブフレームに関して別々のＰＵＣＣＨフォーマットが使用され得るということである。

基地局は、スケジュールされているキャリアの数量、またはスケジュールされているコードワードの数量に従ってＵＣＩ情報のコードブックサイズを決定し、次いで現在のチャネル環境および別のパラメータを参照して、ＵＥによって必要とされるＰＵＣＣＨリソースのサイズ情報およびフォーマット情報を決定し得るということが理解され得る。これは、この実施形態においては特に限定されない。

この実施形態において提供されている、キャリアアグリゲーションにおけるＰＵＣＣＨリソース割り振り方法によれば、基地局は、ＲＲＣ構成シグナリングを使用することによってＵＥ用に複数のＰＵＣＣＨリソースを構成し、スケジュールされているキャリアの数量、またはスケジュールされているコードワードの数量に従ってＵＣＩ情報のコードブックサイズを決定し、次いで現在のチャネル環境を参照してＵＥの実際の要件を決定し、固定されたサイズおよび固定されたフォーマットのＰＵＣＣＨリソースをＵＥへ割り振る代わりに、第２の表示の表示を使用することによって、ＰＵＣＣＨリソースの選択、ならびにＰＵＣＣＨリソースサイズおよびＰＵＣＣＨフォーマットの動的でフレキシブルな決定を完遂する。これは、ＰＵＣＣＨを使用することによってＵＥによってフィードバックされるＵＣＩが複数のＰＲＢペアのリソースを占め得るｅＣＡシナリオの要件を満たすことができるだけでなく、ＰＵＣＣＨリソースの利用を改善することもできる。

加えて、関連した技術においては、キャリアアグリゲーションにおいてＰＵＣＣＨフォーマットが準静的に構成されることのみが可能である。しかしながら、この実施形態において提供されている、キャリアアグリゲーションにおけるリソース割り振り方法によれば、別々のサブフレームに関して別々のＰＵＣＣＨフォーマットが使用されることがあり、新たなＰＵＣＣＨフォーマットのための複数の可変候補がサポートされることが可能であり、それによってシステムパフォーマンスが最適化される。

この実施形態においては、基地局は、ＲＲＣ構成シグナリングを使用することによってＵＥ用のリソースリストを事前に構成し、別々のリソース情報グループが、同じＰＵＣＣＨフォーマットに対応することがあり、または別々のリソース情報グループが、別々のＰＵＣＣＨフォーマットに対応することがある。さらに、以降では、具体的な例を使用することによって詳細な説明を提供する。

図８は、ＲＲＣ構成シグナリングを使用することによってＵＥ用に構成されている第１のＰＵＣＣＨリソースリストの概略図である。リソースリスト内の複数のリソース情報グループが、２つの異なるＰＵＣＣＨフォーマットに従ってアレンジされている。それぞれのＰＵＣＣＨフォーマットは、２つのリソース情報グループに対応し、それぞれのリソース情報グループは、１つのＰＵＣＣＨリソースの開始アドレス表示情報およびサイズ表示情報を含む。ＲＲＣ構成シグナリングは、特に下記の形式で書かれ得る。明らかに、下記のシグナリングコンテンツは、本発明に対する限定ではなく、本発明について記述するための例として使用されているにすぎない。

たとえば、ＰＵＣＣＨリソースリストは、下記のＲＲＣ構成情報要素を使用することによってＵＥ用に構成され得る。

さらに、ＵＥによって必要とされるＰＵＣＣＨリソースのサイズ情報およびフォーマット情報を決定した後に、基地局が、ＵＥによって必要とされるＰＵＣＣＨリソースのサイズ情報およびフォーマット情報と同じであるサイズ表示情報およびＰＵＣＣＨフォーマットを有する第１のリソース情報グループをＰＵＣＣＨリソースリストから選択し、次いで第２の表示情報を使用することによって、第１のリソース情報グループに対応するリソースインデックス（Ｒｅｓｏｕｒｃｅ Ｉｎｄｅｘ、略してＲＩ）をＵＥへ送信することがあり、ＵＥは、第２の表示の表示に従って、第１のリソース情報グループに対応するＰＵＣＣＨリソースを入手する。

たとえば、ＵＥによって必要とされるＰＵＣＣＨリソースが、マルチＰＲＢ ＰＦ３フォーマットのものであり、２つのＰＲＢペアを占めるということを基地局が決定した場合には、基地局は、第２の表示情報を使用することによって、図８において示されているリソース情報グループ１に対応するＲＩをＵＥへ送信し得る。ＵＥは、第２の表示情報の表示に従って、リソース情報グループ１に対応するＰＵＣＣＨリソースを入手する。

第２の表示情報をＵＥへ送信するために、関連した技術におけるＡＲＩ情報送信方法が使用され得るということに留意されたい。たとえば、第２の表示情報を送信するために、ＬＴＥにおけるＤＣＩ内のＴＰＣフィールドが使用され得る。既存のプロトコルにおいては、ＡＲＩインジケータのために使用される、それぞれのキャリア上のＴＰＣフィールドが、２ビットを含み、４つのリソースのうちの１つを選択することが実施されることが可能であるということが理解され得る。

図９は、ＲＲＣ構成シグナリングを使用することによってＵＥ用に構成されている第２のＰＵＣＣＨリソースリストの概略図である。リソースリスト内の複数のリソース情報グループが、２つの異なるＰＵＣＣＨフォーマットに従ってアレンジされている。それぞれのＰＵＣＣＨフォーマットは、４つのリソース情報グループに対応し、それぞれのリソース情報グループは、１つのＰＵＣＣＨリソースの開始アドレス表示情報およびサイズ表示情報を含む。

さらに、ＵＥによって必要とされるＰＵＣＣＨリソースのサイズ情報およびフォーマット情報を決定した後に、基地局が、ＵＥによって必要とされるＰＵＣＣＨリソースのサイズ情報およびフォーマット情報と同じであるサイズ表示情報およびＰＵＣＣＨフォーマットを有する第２のリソース情報グループをＰＵＣＣＨリソースリストから選択し、次いで第２の表示情報を使用することによって、第２のリソース情報グループに対応するリソースインデックス（Ｒｅｓｏｕｒｃｅ Ｉｎｄｅｘ、略してＲＩ）をＵＥへ送信することがあり、ＵＥは、第２の表示の表示に従って、第２のリソース情報グループに対応するＰＵＣＣＨリソースを入手する。

図９において示されているケースにおいては、８つのリソース情報グループのうちの１つのリソース情報グループに対応するＰＵＣＣＨリソースが選択される必要がある。しかしながら、既存のプロトコルにおいては、ＡＲＩインジケータのために使用される、それぞれのキャリア上のＴＰＣフィールドが、２ビットのみを含み、４つのリソースのうちの１つを選択することのみが実施されることが可能である。したがって、ＡＲＩインジケータのために使用される既存のＴＰＣフィールドが、第２の表示情報を送信するために使用される場合には、８つのリソース情報グループのうちの１つのリソース情報グループに対応するＰＵＣＣＨリソースの選択が実施されることは不可能である。

実装形態においては、第２の表示情報を送信するために、ＴＰＣフィールドの２つのグループが使用され得る。ＴＰＣフィールドの一方のグループは、第２のリソース情報グループに対応するＲＩを送信するために使用され、ＰＵＣＣＨ ＴＰＣフィールド値に関しては、表２において示されているＴＰＣフィールド値の第１のグループの意味を参照されたい。ＴＰＣフィールドの他方のグループは、第２のリソース情報グループに対応するＰＵＣＣＨフォーマットインデックス（Ｆｏｒｍａｔ Ｉｎｄｅｘ、略してＦＩ）を送信するために使用され、ＰＵＣＣＨ ＴＰＣ要求フィールド値に関しては、表３において示されているＴＰＣフィールド値の第２のグループの意味を参照されたい。明らかに、表２および表３においてリストアップされているＴＰＣフィールド値の意味は、本発明に対する限定ではなく、本発明について記述するための例として使用されているにすぎない。

別の任意選択の実装形態においては、基地局は代替として、拡張ＴＰＣフィールドを使用することによって、第２のリソース情報グループに対応するＲＩおよびＦＩを送信し得る。たとえば、少なくとも１ビットが既存のＴＰＣフィールドに付加されて、拡張ＴＰＣフィールドを入手することがあり、第２のリソース情報グループに対応するＲＩを送信するために、元の２ビットが使用され、第２のリソース情報グループに対応するＦＩを送信するために、新たに付加されたビットが使用される。特定の拡張ＰＵＣＣＨ ＴＰＣフィールド値に関しては、表４において示されている拡張ＴＰＣフィールド値の意味を参照されたい。表４において示されている、第１のタイプの拡張ＴＰＣフィールドが３ビットを含む場合のＴＰＣフィールド値の意味によれば、ＰＵＣＣＨリソースの２つの異なるフォーマットを示すために、新たに付加された１ビットが使用され得るということが知られ得る。明らかに、拡張ＴＰＣフィールドが４ビットを含む場合のＴＰＣフィールド値の意味はさらに、表４において示されている、第１のタイプの拡張ＴＰＣフィールドが３ビットを含む場合のＴＰＣフィールド値の意味に従って入手され得る。すなわち、ＰＵＣＣＨリソースの４つの異なるフォーマットを示すために、新たに付加された２ビットが使用され得る。

図１０は、ＲＲＣ構成シグナリングを使用することによってＵＥ用に構成されている第３のＰＵＣＣＨリソースリストの概略図である。リソースリスト内の４つのリソース情報グループが、別々のＰＵＣＣＨフォーマットに従ってアレンジされている。それぞれのＰＵＣＣＨフォーマットは、２つのリソース情報グループに対応し、それぞれのリソース情報グループは、１つのＰＵＣＣＨリソースの開始アドレス表示情報を含む。同様に、この実施形態において示されていないＰＵＣＣＨリソースリストの概略図においては、代替として、それぞれのＰＵＣＣＨフォーマットは、４つのリソース情報グループに対応することがあり、それぞれのリソース情報グループは、１つのＰＵＣＣＨリソースの開始アドレス表示情報を含む。

さらに、ＵＥによって必要とされるＰＵＣＣＨリソースのサイズ情報およびフォーマット情報を決定した後に、基地局が、ＵＥによって必要とされるＰＵＣＣＨリソースのフォーマット情報と同じであるＰＵＣＣＨフォーマットを有する第３のリソース情報グループをＰＵＣＣＨリソースリストから選択し、次いで第２の表示情報を使用することによって、第３のリソース情報グループに対応するＲＩをＵＥへ送信することがあり、ＵＥは、第２の表示情報の表示に従って、第３のリソース情報グループに対応するＰＵＣＣＨリソースを入手する。加えて、基地局はさらに、第２の表示情報を使用することによって、ＵＥによって必要とされるＰＵＣＣＨリソースのサイズ情報に対応するＰＵＣＣＨリソースの長さインデックス（Ｌｅｎｇｔｈ Ｉｎｄｅｘ、略してＬＩ）をＵＥへ送信して、第３のリソース情報グループに対応するＰＵＣＣＨリソースのサイズをＵＥに示す。

同様に、第２の表示情報をＵＥへ送信するために、関連した技術におけるＡＲＩ情報送信方法が使用され得るということに留意されたい。たとえば、第２の表示情報を送信するために、ＬＴＥにおけるＤＣＩ内のＴＰＣフィールドが使用され得る。図１０において示されているケースにおいては、第３のリソース情報グループに対応するＲＩと、第３のリソース情報グループに対応するＬＩとの両方が、第２の表示情報を使用することによってＵＥに示される必要がある。

好ましい実装形態においては、第２の表示情報を送信するために、ＴＰＣフィールドの２つのグループが使用され得る。ＴＰＣフィールドの一方のグループは、第３のリソース情報グループに対応するＲＩを送信するために使用され、ＴＰＣ要求ＰＵＣＣＨフィールド値に関しては、表２において示されているＴＰＣフィールド値の第１のグループの意味を参照されたい。ＴＰＣフィールドの他方のグループは、第３のリソース情報グループに対応するＰＵＣＣＨリソースのサイズをＵＥに示すＬＩを送信するために使用され、ＴＰＣ要求ＰＵＣＣＨフィールド値に関しては、表５において示されているＴＰＣフィールド値の第３のグループの意味を参照されたい。

別の任意選択の実装形態においては、基地局は代替として、拡張ＴＰＣフィールドを使用することによって、第３のリソース情報グループに対応するＲＩと、第３のリソース情報グループに対応するＰＵＣＣＨリソースのサイズをＵＥに示すＬＩとを送信し得る。たとえば、少なくとも１ビットが既存のＴＰＣフィールドに付加されて、拡張ＴＰＣフィールドを入手することがあり、第３のリソース情報グループに対応するＲＩを送信するために、元の２ビットが使用され、第３のリソース情報グループに対応するＰＵＣＣＨリソースのサイズをＵＥに示すＬＩを送信するために、新たに付加されたビットが使用される。特定の拡張ＴＰＣ要求ＰＵＣＣＨフィールド値に関しては、表６において示されている第２のタイプの拡張ＴＰＣフィールド値の意味を参照されたい。表６において示されている、第２のタイプの拡張ＴＰＣフィールドが３ビットを含む場合のＴＰＣフィールド値の意味によれば、ＰＵＣＣＨリソースの２つの異なるサイズを示すために、新たに付加された１ビットが使用され得るということが知られ得る。明らかに、拡張ＴＰＣフィールドが４ビットを含む場合のＴＰＣフィールド値の意味はさらに、表６において示されている、第２のタイプの拡張ＴＰＣフィールドが３ビットを含む場合のＴＰＣフィールド値の意味に従って入手され得る。すなわち、ＰＵＣＣＨリソースの４つの異なるサイズを示すために、新たに付加された２ビットが使用され得る。

図１１は、ＲＲＣ構成シグナリングを使用することによってＵＥ用に構成されている第４のＰＵＣＣＨリソースリストの概略図である。リソースリスト内のそれぞれのリソース情報グループが、１つのＰＵＣＣＨリソースの開始アドレス表示情報およびサイズ表示情報を含む。ＲＲＣ構成シグナリングは、特に下記の形式で書かれ得る。明らかに、下記のシグナリングコンテンツは、本発明に対する限定ではなく、本発明について記述するための例として使用されているにすぎない。

たとえば、ＰＵＣＣＨリソースリストは、下記のＲＲＣ構成シグナリングを使用することによってＵＥ用に構成され得る。

図１１において示されているように、ＲＲＣ構成シグナリングを使用することによってＵＥ用に構成されているＰＵＣＣＨリソースリストは、４つのリソース情報グループを含む。それぞれのリソース情報グループは、１つのＰＵＣＣＨリソースの開始表示情報（ＲｅｓｏｕｒｃｅＳｔａｒｔ ＩＮＴＥＧＥＲ（０．．５４９））、およびそのＰＵＣＣＨリソースのサイズ情報（ＲｅｓｏｕｒｃｅＬｅｎ ＩＮＴＥＧＥＲ（０．．５））を含む。したがって、４つのリソース情報グループのＰＵＣＣＨフォーマットはさらに、動的に示されることが必要である。すなわち、ＲＲＣ構成シグナリングを使用することによってＵＥ用に構成されているＰＵＣＣＨリソースリスト内のそれぞれのリソース情報グループは、１つのＰＵＣＣＨリソースの開始アドレス表示情報およびサイズ表示情報を含む。

さらに、ＵＥによって必要とされるＰＵＣＣＨリソースのサイズ情報およびフォーマット情報を決定した後に、基地局が、ＵＥによって必要とされるＰＵＣＣＨリソースのサイズ情報と同じであるサイズ表示情報を有する第４のリソース情報グループをＰＵＣＣＨリソースリストから選択し、次いで第２の表示情報を使用することによって、第４のリソース情報グループに対応するＲＩをＵＥへ送信することがあり、ＵＥは、第２の表示情報の表示に従って、第４のリソース情報グループに対応するＰＵＣＣＨリソースを入手する。加えて、基地局はさらに、第２の表示情報を使用することによって、ＵＥによって必要とされるＰＵＣＣＨリソースのフォーマット情報に対応するＰＵＣＣＨリソースのフォーマットインデックスＦＩをＵＥへ送信して、第４のリソース情報グループに対応するＰＵＣＣＨリソースのＰＵＣＣＨフォーマットをＵＥに示す。

同様に、第２の表示情報をＵＥへ送信するために、関連した技術におけるＡＲＩ情報送信方法が使用され得るということに留意されたい。たとえば、第２の表示情報を送信するために、ＬＴＥにおけるＤＣＩ内のＴＰＣフィールドが使用され得る。図１１において示されているケースにおいては、第４のリソース情報グループに対応するＲＩと、第４のリソース情報グループに対応するＦＩとの両方が、第２の表示情報を使用することによってＵＥに示される必要がある。

好ましい実装形態においては、第２の表示情報を送信するために、ＴＰＣフィールドの２つのグループが使用され得る。ＴＰＣフィールドの一方のグループは、第４のリソース情報グループに対応するＲＩを送信するために使用され、ＴＰＣ要求ＰＵＣＣＨフィールド値に関しては、表２において示されているＴＰＣフィールド値の第１のグループの意味を参照されたい。ＴＰＣフィールドの他方のグループは、第４のリソース情報グループに対応するＰＵＣＣＨリソースをＵＥに示すＦＩを送信するために使用され、ＴＰＣ要求ＰＵＣＣＨフィールド値に関しては、表３において示されているＴＰＣフィールド値の第２のグループの意味を参照されたい。

別の任意選択の実装形態においては、基地局は代替として、拡張ＴＰＣフィールドを使用することによって、第４のリソース情報グループに対応するＲＩと、第４のリソース情報グループに対応するＰＵＣＣＨリソースのフォーマットをＵＥに示すＦＩとを送信し得る。たとえば、少なくとも１ビットが既存のＴＰＣフィールドに付加されて、拡張ＴＰＣフィールドを入手することがあり、第４のリソース情報グループに対応するＲＩを送信するために、元の２ビットが使用され、第４のリソース情報グループに対応するＰＵＣＣＨリソースのフォーマットをＵＥに示すＦＩを送信するために、新たに付加されたビットが使用される。特定の拡張ＴＰＣ要求ＰＵＣＣＨフィールド値に関しては、表７において示されている第３のタイプの拡張ＴＰＣフィールド値の意味を参照されたい。表７において示されている、第３のタイプの拡張ＴＰＣフィールドが３ビットを含む場合のＴＰＣフィールド値の意味によれば、ＰＵＣＣＨリソースの２つの異なるフォーマットを示すために、新たに付加された１ビットが使用され得るということが知られ得る。明らかに、拡張ＴＰＣフィールドが４ビットを含む場合のＴＰＣフィールド値の意味はさらに、表６において示されている、第２のタイプの拡張ＴＰＣフィールドが３ビットを含む場合のＴＰＣフィールド値の意味に従って入手され得る。すなわち、ＰＵＣＣＨリソースの４つの異なるサイズを示すために、新たに付加された２ビットが使用され得る。

図１２は、ＲＲＣ構成シグナリングを使用することによってＵＥ用に構成されている第５のＰＵＣＣＨリソースリストの概略図である。リソースリスト内のそれぞれのリソース情報グループが、１つのＰＵＣＣＨリソースの開始アドレス表示情報を含む。たとえば、ＰＵＣＣＨリソースリストは、下記のＲＲＣ構成シグナリングを使用することによってＵＥ用に構成され得る。

さらに、基地局が、第２の表示情報を使用することによって、第５のリソース情報グループに対応するＲＩをＵＥへ送信する必要があり、ＵＥは、第２の表示情報の表示に従って、第５のリソース情報グループに対応するＰＵＣＣＨリソースを入手する。加えて、基地局はさらに、第２の表示情報を使用することによって、ＵＥによって必要とされるＰＵＣＣＨリソースのフォーマット情報に対応するＰＵＣＣＨリソースのＦＩをＵＥへ送信して、第５のリソース情報グループに対応するＰＵＣＣＨリソースのフォーマットをＵＥに示す必要がある。基地局はさらに、第２の表示情報を使用することによって、ＵＥによって必要とされるＰＵＣＣＨリソースのサイズ情報に対応するＰＵＣＣＨリソースのＬＩをＵＥへ送信して、第５のリソース情報グループに対応するＰＵＣＣＨリソースのサイズをＵＥに示す必要がある。

同様に、第２の表示情報をＵＥへ送信するために、関連した技術におけるＡＲＩ情報送信方法が使用され得るということに留意されたい。たとえば、第２の表示情報を送信するために、ＬＴＥにおけるＤＣＩ内のＴＰＣフィールドが使用され得る。図１１において示されているケースにおいては、第５のリソース情報グループに対応するＲＩと、第５のリソース情報グループに対応するＦＩおよびＬＩとの両方が、第２の表示情報を使用することによってＵＥに示される必要がある。

好ましい実装形態においては、第２の表示情報を送信するために、ＴＰＣフィールドの３つのグループが使用され得る。ＴＰＣフィールドの第１のグループは、第５のリソース情報グループに対応するＲＩを送信するために使用され、ＴＰＣ要求ＰＵＣＣＨフィールド値に関しては、表２において示されているＴＰＣフィールド値の第１のグループの意味を参照されたい。ＴＰＣフィールドの第２のグループは、第５のリソース情報グループに対応するＰＵＣＣＨリソースのフォーマットをＵＥに示すＦＩを送信するために使用され、ＴＰＣ要求ＰＵＣＣＨフィールド値に関しては、表３において示されているＴＰＣフィールド値の第２のグループの意味を参照されたい。ＴＰＣフィールドの第３のグループは、第５のリソース情報グループに対応するＰＵＣＣＨリソースのサイズをＵＥに示すＬＩを送信するために使用され、ＴＰＣ要求ＰＵＣＣＨフィールド値に関しては、表５において示されているＴＰＣフィールド値の第３のグループの意味を参照されたい。

別の任意選択の実装形態においては、基地局は代替として、拡張ＴＰＣフィールドを使用することによって、第５のリソース情報グループに対応するＲＩと、第５のリソース情報グループに対応するＰＵＣＣＨリソースのフォーマットをＵＥに示すＦＩと、第５のリソース情報グループに対応するＰＵＣＣＨリソースのサイズをＵＥに示すＬＩとを送信し得る。たとえば、少なくとも２ビットが既存のＴＰＣフィールドに付加されて、拡張ＴＰＣフィールドを入手することがあり、第５のリソース情報グループに対応するＲＩを送信するために、元の２ビットが使用され、第５のリソース情報グループに対応するＰＵＣＣＨリソースのフォーマットおよびサイズをＵＥに示すＦＩおよびＬＩを送信するために、新たに付加されたビットが使用される。

できるだけ少ないビットをＴＰＣフィールドに付加するために、実装形態においては、ＲＲＣ構成シグナリングを使用することによってＵＥ用に構成されているリソースリストは、代替として２つのリソース情報グループのみを含み得る。明らかに、これは、リソース選択の柔軟性を犠牲にしている。この方法においては、第２の表示情報を送信するために、ＴＰＣフィールドの２つのグループが使用されることが可能である。ＴＰＣフィールドの一方のグループは、第６のリソース情報グループに対応するＲＩおよびＦＩを送信するために使用され、ＴＰＣフィールドの他方のグループは、第６のリソース情報グループに対応するＰＵＣＣＨリソースをＵＥに示すＬＩを送信するために使用される。

同様に、ＲＲＣ構成シグナリングを使用することによってＵＥ用に構成されているリソースリストが、２つのリソース情報グループのみを含む場合には、代替として、１ビットのみが既存のＴＰＣフィールドに付加されて、拡張ＴＰＣフィールドを入手することがあり、第６のリソース情報グループに対応するＲＩと、第６のリソース情報グループに対応するＰＵＣＣＨリソースのフォーマットをＵＥに示すＦＩとを送信するために、元の２ビットが使用され、第６のリソース情報グループに対応するＰＵＣＣＨリソースのサイズをＵＥに示すＬＩを送信するために、新たに付加されたビットが使用されるということが理解され得る。

本発明の別の実施形態においては、ＴＰＣフィールドの２つのグループか、または３つのグループかをどのようにして決定するかがさらに、例を使用することによって記述される。

図６Ａおよび図６Ｂにおいて示されているように、ＬＴＥ−Ａシステムにおいては、ＦＤＤモードにおけるＡＲＩ情報送信メカニズムと、ＴＤＤモードにおけるＡＲＩ情報送信メカニズムとは異なる。以降では、ＴＰＣフィールドをどのようにしてグループ化するかについて記述するための例として図１３Ａおよび図１３Ｂを別々に使用する。

図１３Ａは、ＦＤＤモードにおけるキャリアスケジューリングの概略図である。図１３Ａにおいて示されているように、たとえば、スケジュールされているキャリアセットが｛０，３，５，６，８，９｝であり、キャリア０がＰＣＣである。ＬＴＥ−ＡシステムにおけるＦＤＤモードにおいては、ＰＣＣ上で受信されるＤＣＩ内のすべてのＴＰＣ要求ＰＵＣＣＨフィールドが、ＰＵＣＣＨ電力コントロールのために使用される。このケースにおいては、ＡＲＩ情報を送信するために使用されることが可能であるキャリアは、５つのＳＣＣ、すなわち、｛３，５，６，８，９｝である。それらの５つのスケジュールされているキャリアは、２つのグループへとグループ化される。

任意選択の実装形態においては、ＴＰＣフィールドの２つのグループを決定するために、順次的なグループ化様式が使用され得る。具体的には、別々のスケジュールされているキャリア上のＴＰＣフィールドが、２つのグループへとグループ化され得る。

たとえば、ＴＰＣフィールドの２つのグループのそれぞれに対応するキャリアの数量が、スケジュールされているキャリアに従って決定され得る。たとえば、第１のグループが、３つのキャリアに対応することがあり、第２のグループが、２つのキャリアに対応することがあり、または第１のグループが、１つのキャリアに対応することがあり、第２のグループが、４つのキャリアに対応することがある。次いで、スケジュールされているキャリアは、それらのスケジュールされているキャリアの識別番号の配列順に従って、およびＴＰＣフィールドのそれぞれのグループに対応するキャリアの数量に従って２つのグループへと順次グループ化され、キャリアの２つの対応するグループは、Ｇ１＝｛３，５，６｝およびＧ２＝｛８，９｝、またはＧ１＝｛３｝およびＧ２＝｛５，６，８，９｝である。キャリアは通常、できるだけ均等にグループ化される。たとえば、第１のグループにおけるキャリアの数量は、［Ｎ／２］に等しく、第２のグループにおけるキャリアの数量は、Ｎ−［Ｎ／２］に等しい。Ｎは、グループ化に関与しているキャリアの合計数量を表し、［］は、切り上げ計算を表す。キャリアがグループ化された後に、スケジュールされているキャリアの２つのグループのそれぞれの上のＴＰＣフィールドが、ＴＰＣフィールドの一方のグループとして決定される。

別の任意選択の実装形態においては、ＴＰＣフィールドの２つのグループを決定するために、代替としてパリティグループ化様式が使用され得る。具体的には、スケジュールされているキャリアのうちで奇数である識別番号を有するスケジュールされているキャリア上のＴＰＣフィールドが、ＴＰＣフィールドの一方のグループとして決定されることがあり、スケジュールされているキャリアのうちで偶数である識別番号を有するスケジュールされているキャリア上のＴＰＣフィールドが、ＴＰＣフィールドの他方のグループとして決定されることがある。それに対応して、Ｇ１＝｛３，５，９｝上のＴＰＣフィールドが、ＴＰＣフィールドの一方のグループとして決定され、Ｇ２＝｛６，８｝上のＴＰＣフィールドが、ＴＰＣフィールドの他方のグループとして決定される。

パリティグループ化様式は、スケジュールされているＳＣＣの中に、奇数の識別番号および偶数の識別番号を伴うＳＣＣが存在する場合にのみ、ＴＰＣフィールドの２つのグループを決定するために使用されることが可能であるということに留意されたい。そうでない場合には、ＴＰＣフィールドの２つのグループを決定するために、順次的なグループ化様式のみが使用されることが可能である。

図１３Ｂは、ＴＤＤモードにおけるｅＣＡスケジューリングの概略図である。図１３Ｂにおいて示されているように、たとえば、スケジュールされているキャリアセットが｛０，２，３，６，９｝であり、キャリア０がＰＣＣである。ＬＴＥ−ＡシステムにおけるＴＤＤモードにおいては、ＰＣＣ上で１よりも大きいＤＡＩを有するダウンリンクＤＣＩ内のＴＰＣ要求ＰＵＣＣＨフィールド、およびすべてのＳＣＣ上で受信されるダウンリンクＤＣＩ内のすべてのＴＰＣ要求ＰＵＣＣＨフィールドが、ＡＲＩ情報を送信するために使用され得る。このケースにおいては、５つのキャリア、すなわち、｛０，２，３，６，９｝が、ＡＲＩ情報を送信するために使用され得る。それらの５つのスケジュールされているキャリアは、２つのグループへとグループ化される。

同様に、スケジュールされているキャリアの２つのグループを決定するために、順次的なグループ化様式が使用され得る。たとえば、Ｇ１＝｛０（ｓｕｂｆｒａｍｅ ８）， ２（ｓｕｂｆｒａｍｅ ４）， ３（ｓｕｂｆｒａｍｅ ４， ｓｕｂｆｒａｍｅ ５）｝上のＴＰＣフィールドが、ＴＰＣフィールドの一方のグループとして決定され、Ｇ２＝｛６（ｓｕｂｆｒａｍｅ ４， ｓｕｂｆｒａｍｅ ８）， ９（ｓｕｂｆｒａｍｅ ５， ｓｕｂｆｒａｍｅ ６）｝上のＴＰＣフィールドが、ＴＰＣフィールドの他方のグループとして決定される。

代替として、ＴＰＣフィールドの２つのグループを決定するために、パリティグループ化様式が使用され得る。たとえば、Ｇ１＝｛０（ｓｕｂｆｒａｍｅ ８），２（ｓｕｂｆｒａｍｅ ４）， ６（ｓｕｂｆｒａｍｅ ４， ｓｕｂｆｒａｍｅ ８）｝上のＴＰＣフィールドが、ＴＰＣフィールドの一方のグループとして決定され、Ｇ２＝｛３（ｓｕｂｆｒａｍｅ ４， ｓｕｂｆｒａｍｅ ５）， ９（ｓｕｂｆｒａｍｅ ５， ｓｕｂｆｒａｍｅ ６）｝上のＴＰＣフィールドが、ＴＰＣフィールドの他方のグループとして決定される。

同様に、ＰＣＣの識別番号が偶数であるので、パリティグループ化様式は、スケジュールされているＳＣＣの中に、奇数の識別番号を伴うＳＣＣが存在する場合にのみ、ＴＰＣフィールドの２つのグループを決定するために使用されることが可能であるということに留意されたい。

さらに、ＴＰＣフィールドの３つのグループを決定する特定の様式に関しては、前述の実施形態における順次的なグループ化様式を参照されたい。それらの原理は同じである。したがって、詳細がここで再び記述されることはない。複数のＴＰＣグループ化様式があり、本発明は、特定のグループ化様式に制限を課すことはないということに留意されたい。

本発明の前述の実施形態において提供されている、キャリアアグリゲーションにおけるリソース割り振り様式によれば、基地局は、ＲＲＣ構成シグナリングを使用することによってＵＥ用に複数のＰＵＣＣＨリソースを構成し、次いでＡＲＩの表示を使用することによってＵＥの実際の要件に従って、ＰＵＣＣＨリソースの選択、ならびにＰＵＣＣＨリソースサイズおよびＰＵＣＣＨフォーマットの動的でフレキシブルな決定を完遂する。これは、ＰＵＣＣＨを使用することによってＵＥによってフィードバックされるＵＣＩが複数のＰＲＢペアのリソースを占め得るｅＣＡシナリオの要件を満たすことができるだけでなく、ＰＵＣＣＨリソースの利用を改善することもできる。加えて、本発明の実施形態においては、別々のサブフレームに関して別々のＰＵＣＣＨフォーマットが使用されることがあり、新たなＰＵＣＣＨフォーマットのための複数の可変候補がサポートされることが可能であり、それによってシステムパフォーマンスが最適化される。

図１４は、本発明の実施形態による、キャリアアグリゲーションにおけるアップリンクコントロール情報送信装置の概略図である。装置Ａは、特に基地局内に配置されることがあり、本発明の図５において示されている実施形態において提供されている、キャリアアグリゲーションにおけるアップリンクコントロール情報送信方法を実施するために使用され得る。詳細がここで再び記述されることはない。図１４において示されているように、この実施形態において提供されている、キャリアアグリゲーションにおけるアップリンクコントロール情報送信装置Ａは、第１の送信モジュール１４１およびリソース割り振りモジュール１４２を含む。

第１の送信モジュール１４１は、第１の表示情報をユーザ機器ＵＥへ送信するように構成されることがあり、第１の表示情報は、その第１の表示情報に従ってアップリンクコントロール情報ＵＣＩを動的に決定するようＵＥに指示するために使用される。リソース割り振りモジュール１４２は、ＰＵＣＣＨリソースをＵＥへ割り振るように構成されることがあり、そのＰＵＣＣＨリソースは、ＵＣＩを送信するために使用される。

この実施形態においては、第１の表示情報は、特に第１のタイプの表示情報または第２のタイプの表示情報であり得る。第１の表示情報が第１のタイプの表示情報である場合には、ＵＥは、スケジュールされているキャリアの数量に従って基地局がＤＡＩ情報を生成する場合に、第１のタイプの表示情報に従ってＵＣＩを決定する。第１の表示情報が第２のタイプの表示情報である場合には、ＵＥは、スケジュールされているコードワードの数量に従って基地局がＤＡＩ情報を生成する場合に、第２のタイプの表示情報に従ってＵＣＩを決定する。

任意選択の実装形態においては、第１の送信モジュールは、第１の構成情報をＵＥへ送信するように特に構成され得る。第１の構成情報は、第１の表示情報を含む。

別の任意選択の実装形態においては、第１の送信モジュールはさらに、ダウンリンクコントロール情報ＤＣＩをＵＥへ送信するように特に構成され得る。ＤＣＩは、第１の表示情報を含む。

さらに別の任意選択の実装形態においては、第１の送信モジュールはさらに、第１の様式でエンコードされているＤＣＩをＵＥへ送信するステップであって、第１の様式は、第１のタイプの表示情報に対応し、第１の様式においては、ＤＣＩエンコーディング中に生成される巡回冗長検査ＣＲＣにスクランブリングコードが付加されない、ステップ、または第２の様式でエンコードされているＤＣＩをＵＥへ送信するステップであって、第２の様式は、第２のタイプの表示情報に対応し、第２の様式においては、ＤＣＩエンコーディング中に生成されるＣＲＣコードにスクランブリングコードが付加される、ステップを行うように特に構成され得る。

この実施形態において提供されている、キャリアアグリゲーションにおけるアップリンクコントロール情報送信装置は、特に基地局内に配置されることがあり、本発明の図５において示されている実施形態において提供されている、キャリアアグリゲーションにおけるアップリンクコントロール情報送信方法を実施するために使用され得る。それらの実施原理および技術的な効果は同様である。詳細がここで再び記述されることはない。

図１５は、本発明の実施形態による、キャリアアグリゲーションにおける別のアップリンクコントロール情報送信装置の概略図である。装置Ｂは、特に基地局内に配置されることがあり、本発明の、図５において示されている実施形態において提供されている、キャリアアグリゲーションにおけるアップリンクコントロール情報送信方法、および図７において示されている実施形態において提供されている、キャリアアグリゲーションにおけるＰＵＣＣＨリソース割り振り方法を実施するために使用され得る。詳細がここで再び記述されることはない。図１５において示されているように、図１４において示されている実施形態に基づいて、この実施形態においては、リソース割り振りモジュール１４２はさらに、構成モジュール１４２１、表示モジュール１４２２、および第２の送信モジュール１４２３を特に含み得る。

構成モジュール１４２１は、第２の構成情報を生成するように構成されることがあり、第２の構成情報は、ＵＥ用のリソースリストを構成するために使用され、そのリソースリストは、複数のリソース情報グループを含む。表示モジュール１４２２は、第２の表示情報を生成するように構成されることがあり、第２の表示情報は、リソースリスト内の１つのリソース情報グループに対応するＰＵＣＣＨリソースをＵＥに示すために使用される。第２の送信モジュール１４２３は、第２の構成情報および第２の表示情報をＵＥへ送信するように構成され得る。

第１の可能な実装形態においては、構成モジュール１４２１によってＵＥ用に構成されている複数のリソース情報グループが、別々のＰＵＣＣＨフォーマットに従ってアレンジされている場合には、それぞれのＰＵＣＣＨフォーマットは、少なくとも１つのリソース情報グループに対応し、それぞれのリソース情報グループは、１つのＰＵＣＣＨリソースの開始アドレス表示情報およびサイズ表示情報を含み、表示モジュール１４２２によって生成される第２の表示情報は、リソースインデックスＲＩを含むことがあり、ＲＩは、そのＲＩに対応する第１のリソース情報グループをＵＥに示すために使用される。

さらに、第２の送信モジュール１４２３は、送信電力コントロールＴＰＣフィールドを使用することによって第２の表示情報、すなわち、第１のリソース情報グループに対応するＲＩを送信するように特に構成され得る。

第２の可能な実装形態においては、構成モジュール１４２１によってＵＥ用に構成されている複数のリソース情報グループが、別々のＰＵＣＣＨフォーマットに従ってアレンジされている場合には、それぞれのＰＵＣＣＨフォーマットは、少なくとも１つのリソース情報グループに対応し、それぞれのリソース情報グループは、１つのＰＵＣＣＨリソースの開始アドレス表示情報を含み、表示モジュール１４２２によって生成される第２の表示情報は、リソースインデックスＲＩおよび長さインデックスＬＩを含み得る。ＲＩは、そのＲＩに対応する第２のリソース情報グループをＵＥに示すために使用され、ＬＩは、第２のリソース情報グループに対応するＰＵＣＣＨリソースのサイズをＵＥに示すために使用される。

さらに、第２の送信モジュール１４２３は、スケジュールされているキャリアに従ってＴＰＣフィールドの２つのグループを決定するステップであって、一方のグループは、第２のリソース情報グループに対応するＲＩを送信するために使用され、他方のグループは、第２のリソース情報グループに対応するＰＵＣＣＨリソースのサイズをＵＥに示すＬＩを送信するために使用される、ステップ、または拡張ＴＰＣフィールドを使用することによってＲＩおよびＬＩを送信するステップであって、その拡張ＴＰＣフィールドは、３ビット以上を含む、ステップを行うように特に構成され得る。

第３の可能な実装形態においては、構成モジュール１４２１によってＵＥ用に構成されているリソースリスト内のそれぞれのリソース情報グループが、１つのＰＵＣＣＨリソースの開始アドレス表示情報およびサイズ表示情報を含む場合には、表示モジュール１４２２によって生成される第２の表示情報は、リソースインデックスＲＩおよびフォーマットインデックスＦＩを含み得る。ＲＩは、そのＲＩに対応する第３のリソース情報グループをＵＥに示すために使用され、ＦＩは、第３のリソース情報グループに対応するＰＵＣＣＨリソースのフォーマットをＵＥに示すために使用される。

さらに、第２の送信モジュール１４２３は、スケジュールされているキャリアに従ってＴＰＣフィールドの２つのグループを決定するステップであって、一方のグループは、第３のリソース情報グループに対応するＲＩを送信するために使用され、他方のグループは、第３のリソース情報グループに対応するＰＵＣＣＨリソースのフォーマットをＵＥに示すＦＩを送信するために使用される、ステップ、または拡張ＴＰＣフィールドを使用することによってＲＩおよびＦＩを送信するステップであって、その拡張ＴＰＣフィールドは、３ビット以上を含む、ステップを行うように特に構成され得る。

第４の可能な実装形態においては、構成モジュール１４２１によってＵＥ用に構成されているリソースリスト内のそれぞれのリソース情報グループが、１つのＰＵＣＣＨリソースの開始アドレス表示情報を含む場合には、表示モジュール１４２２によって生成される第２の表示情報は、リソースインデックスＲＩ、フォーマットインデックスＦＩ、および長さインデックスＬＩを含み得る。ＲＩは、そのＲＩに対応する第４のリソース情報グループをＵＥに示すために使用され、ＦＩは、第４のリソース情報グループに対応するＰＵＣＣＨリソースのフォーマットをＵＥに示すために使用され、ＬＩは、第４のリソース情報グループに対応するＰＵＣＣＨリソースのサイズをＵＥに示すために使用される。

さらに、第２の送信モジュール１４２３は、スケジュールされているキャリアに従ってＴＰＣフィールドの３つのグループを決定するステップであって、第１のグループは、第４のリソース情報グループに対応するＲＩを送信するために使用され、第２のグループは、第４のリソース情報グループに対応するＰＵＣＣＨリソースのフォーマットをＵＥに示すＦＩを送信するために使用され、第３のグループは、第４のリソース情報グループに対応するＰＵＣＣＨリソースのサイズをＵＥに示すＬＩを送信するために使用される、ステップ、または拡張ＴＰＣフィールドを使用することによってＲＩ、ＦＩ、およびＬＩを送信するステップであって、その拡張ＴＰＣフィールドは、３ビット以上を含む、ステップを行うように特に構成され得る。

たとえば、第４の可能な実装形態においては、構成モジュール１４２１によってＵＥ用に構成されているリソースリストが、２つのリソース情報グループを含む場合には、第２の送信モジュール１４２３は、スケジュールされているキャリアに従ってＴＰＣフィールドの２つのグループを決定するステップであって、一方のグループは、第４のリソース情報グループに対応するＲＩと、第４のリソース情報グループに対応するＰＵＣＣＨリソースのフォーマットをＵＥに示すＦＩとを送信するために使用され、他方のグループは、第４のリソース情報グループに対応するＰＵＣＣＨリソースのサイズをＵＥに示すＬＩを送信するために使用される、ステップを行うように特に構成され得る。

この実施形態においては、第２の送信モジュール１４２３が、ＴＰＣフィールドの２つのグループを使用することによって、ＲＩ、ＦＩ、およびＬＩの対応する可能な組合せを送信する場合には、任意選択の実装形態においては、第２の送信モジュール１４２３は、スケジュールされているキャリアの識別番号の順序に従って、スケジュールされているキャリアを２つのグループへとグループ化するステップと、次いで、スケジュールされているキャリアの２つのグループのそれぞれの上のＴＰＣフィールドをＴＰＣフィールドの一方のグループとして決定するステップとを行うように特に構成されることがあり、別の任意選択の実装形態においては、スケジュールされているキャリアが、奇数である識別番号を有するスケジュールされているキャリアと、偶数である識別番号を有するスケジュールされているキャリアとを含む場合には、第２の送信モジュール１４２３はさらに、スケジュールされているキャリアのうちで奇数である識別番号を有するスケジュールされているキャリア上のＴＰＣフィールドをＴＰＣフィールドの一方のグループとして決定するステップと、スケジュールされているキャリアのうちで偶数である識別番号を有するスケジュールされているキャリア上のＴＰＣフィールドをＴＰＣフィールドの他方のグループとして決定するステップとを行うように特に構成され得る。

この実施形態において提供されている、キャリアアグリゲーションにおけるアップリンクコントロール情報送信装置は、特に基地局内に配置されることがあり、本発明の、図５において示されている実施形態において提供されている、キャリアアグリゲーションにおけるアップリンクコントロール情報送信方法、および図７において示されている実施形態において提供されている、キャリアアグリゲーションにおけるＰＵＣＣＨリソース割り振り方法を実施するために使用され得る。それらの実施原理および技術的な効果は同様である。詳細がここで再び記述されることはない。

図１６は、本発明の実施形態による基地局の概略図である。この基地局は、本発明の、図５において示されている実施形態において提供されている、キャリアアグリゲーションにおけるアップリンクコントロール情報送信方法、および図７において示されている実施形態において提供されている、キャリアアグリゲーションにおけるＰＵＣＣＨリソース割り振り方法を実施するために使用され得る。詳細がここで再び記述されることはない。図１６において示されているように、この実施形態において提供されている基地局は、トランシーバ１６１、メモリ１６２、およびプロセッサ１６３を含む。プロセッサ１６３は、メモリ１６２に結合されている。

具体的には、トランシーバ１６１は、第１の表示情報をユーザ機器ＵＥへ送信するステップであって、第１の表示情報は、その第１の表示情報に従ってアップリンクコントロール情報ＵＣＩを動的に決定するようＵＥに指示するために使用される、ステップを行うように構成され得る。プロセッサ１６３は、ＰＵＣＣＨリソースをＵＥへ割り振るステップであって、そのＰＵＣＣＨリソースは、ＵＣＩを送信するために使用される、ステップを行うように構成され得る。

この実施形態においては、第１の表示情報は、特に第１のタイプの表示情報または第２のタイプの表示情報であり得る。第１の表示情報が第１のタイプの表示情報である場合には、ＵＥは、スケジュールされているキャリアの数量に従って基地局がＤＡＩ情報を生成する場合に、第１のタイプの表示情報に従ってＵＣＩを決定する。第１の表示情報が第２のタイプの表示情報である場合には、ＵＥは、スケジュールされているコードワードの数量に従って基地局がＤＡＩ情報を生成する場合に、第２のタイプの表示情報に従ってＵＣＩを決定する。

実際の適用においては、トランシーバ１６１は、第１の構成情報をＵＥへ送信するステップであって、第１の構成情報は、第１の表示情報を含む、ステップを行うように特に構成され得る。トランシーバ１６１はさらに、ダウンリンクコントロール情報ＤＣＩをＵＥへ送信するステップであって、ＤＣＩは、第１の表示情報を含む、ステップを行うように特に構成され得る。代替として、トランシーバ１６１は、第１の様式でエンコードされているＤＣＩをＵＥへ送信するステップであって、第１の様式は、第１のタイプの表示情報に対応し、第１の様式においては、ＤＣＩエンコーディング中に生成される巡回冗長検査ＣＲＣコードにスクランブリングコードが付加されない、ステップ、または第２の様式でエンコードされているＤＣＩをＵＥへ送信するステップであって、第２の様式は、第２のタイプの表示情報に対応し、第２の様式においては、ＤＣＩエンコーディング中に生成されるＣＲＣコードにスクランブリングコードが付加される、ステップを行うように特に構成され得る。

実際の適用においては、プロセッサ１６２は、第２の構成情報および第２の表示情報を生成するように特に構成され得る。第２の構成情報は、ＵＥ用のリソースリストを構成するために使用され、そのリソースリストは、複数のリソース情報グループを含む。第２の表示情報は、リソースリスト内の１つのリソース情報グループに対応するＰＵＣＣＨリソースをＵＥに示すために使用される。さらに、トランシーバ１６１はさらに、第２の構成情報および第２の表示情報をＵＥへ送信するように構成され得る。

第１の可能な実装形態においては、複数のリソース情報グループが、別々のＰＵＣＣＨフォーマットに従ってアレンジされている場合には、それぞれのＰＵＣＣＨフォーマットは、少なくとも１つのリソース情報グループに対応し、それぞれのリソース情報グループは、１つのＰＵＣＣＨリソースの開始アドレス表示情報およびサイズ表示情報を含み、第２の表示情報は、リソースインデックスＲＩを含み、ＲＩは、そのＲＩに対応する第１のリソース情報グループをＵＥに示すために使用される。

さらに、トランシーバ１６１は、送信電力コントロールＴＰＣフィールドを使用することによって第２の表示情報、すなわち、第１のリソース情報グループに対応するＲＩを送信するように特に構成され得る。

第２の可能な実装形態においては、複数のリソース情報グループが、別々のＰＵＣＣＨフォーマットに従ってアレンジされている場合には、それぞれのＰＵＣＣＨフォーマットは、少なくとも１つのリソース情報グループに対応し、それぞれのリソース情報グループは、１つのＰＵＣＣＨリソースの開始アドレス表示情報を含み、第２の表示情報は、ＲＩを含み、ＲＩは、そのＲＩに対応する第２のリソース情報グループをＵＥに示すために使用される。加えて、第２の表示情報は、長さインデックスＬＩをさらに含み、ＬＩは、第２のリソース情報グループに対応するＰＵＣＣＨリソースのサイズをＵＥに示すために使用される。

さらに、トランシーバ１６１は、スケジュールされているキャリアに従ってＴＰＣフィールドの２つのグループを決定するステップであって、一方のグループは、第２のリソース情報グループに対応するＲＩを送信するために使用され、他方のグループは、第２のリソース情報グループに対応するＰＵＣＣＨリソースのサイズをＵＥに示すＬＩを送信するために使用される、ステップ、または拡張ＴＰＣフィールドを使用することによってＲＩおよびＬＩを送信するステップであって、その拡張ＴＰＣフィールドは、３ビット以上を含む、ステップを行うように特に構成され得る。

第３の可能な実装形態においては、リソースリスト内のそれぞれのリソース情報グループが、１つのＰＵＣＣＨリソースの開始アドレス表示情報およびサイズ表示情報を含む場合には、第２の表示情報は、ＲＩを含み、ＲＩは、そのＲＩに対応する第３のリソース情報グループをＵＥに示すために使用される。加えて、第２の表示情報は、フォーマットインデックスＦＩをさらに含み、ＦＩは、第３のリソース情報グループに対応するＰＵＣＣＨリソースのＰＵＣＣＨフォーマットをＵＥに示すために使用される。

さらに、トランシーバ１６１は、スケジュールされているキャリアに従ってＴＰＣフィールドの２つのグループを決定するステップであって、一方のグループは、第３のリソース情報グループに対応するＲＩを送信するために使用され、他方のグループは、第３のリソース情報グループに対応するＰＵＣＣＨリソースのフォーマットをＵＥに示すＦＩを送信するために使用される、ステップ、または拡張ＴＰＣフィールドを使用することによってＲＩおよびＦＩを送信するステップであって、その拡張ＴＰＣフィールドは、３ビット以上を含む、ステップを行うように特に構成され得る。

第４の可能な実装形態においては、リソースリスト内のそれぞれのリソース情報グループが、１つのＰＵＣＣＨリソースの開始アドレス表示情報を含む場合には、第２の表示情報は、ＲＩを含み、ＲＩは、そのＲＩに対応する第４のリソース情報グループをＵＥに示すために使用される。加えて、第２の表示情報は、ＦＩおよびＬＩをさらに含み、ＦＩは、第４のリソース情報グループに対応するＰＵＣＣＨリソースのＰＵＣＣＨフォーマットをＵＥに示すために使用され、ＬＩは、第４のリソース情報グループに対応するＰＵＣＣＨリソースのサイズをＵＥに示すために使用される。

さらに、トランシーバ１６１は、スケジュールされているキャリアに従ってＴＰＣフィールドの３つのグループを決定するステップであって、第１のグループは、第４のリソース情報グループに対応するＲＩを送信するために使用され、第２のグループは、第４のリソース情報グループに対応するＰＵＣＣＨリソースのフォーマットをＵＥに示すＦＩを送信するために使用され、第３のグループは、第４のリソース情報グループに対応するＰＵＣＣＨリソースのサイズをＵＥに示すＬＩを送信するために使用される、ステップ、または拡張ＴＰＣフィールドを使用することによってＲＩ、ＦＩ、およびＬＩを送信するステップであって、その拡張ＴＰＣフィールドは、３ビット以上を含む、ステップを行うように特に構成され得る。

たとえば、第４の可能な実装形態においては、リソースリストが、２つのリソース情報グループを含む（それぞれのリソース情報グループは、１つのＰＵＣＣＨリソースの開始アドレス表示情報を含む）場合には、トランシーバ１６１は、スケジュールされているキャリアに従ってＴＰＣフィールドの２つのグループを決定するステップであって、一方のグループは、第４のリソース情報グループに対応するＲＩと、第４のリソース情報グループに対応するＰＵＣＣＨリソースのフォーマットをＵＥに示すＦＩとを送信するために使用され、他方のグループは、第４のリソース情報グループに対応するＰＵＣＣＨリソースのサイズをＵＥに示すＬＩを送信するために使用される、ステップを行うように特に構成され得る。

この実施形態においては、トランシーバ１６１が、ＴＰＣフィールドの２つのグループを使用することによって、ＲＩ、ＦＩ、およびＬＩの対応する可能な組合せを送信する場合には、任意選択の実装形態においては、トランシーバ１６１は、スケジュールされているキャリアの識別番号の順序に従って、スケジュールされているキャリアを２つのグループへとグループ化するステップと、次いで、スケジュールされているキャリアの２つのグループのそれぞれの上のＴＰＣフィールドをＴＰＣフィールドの一方のグループとして決定するステップとを行うように特に構成されることがあり、別の任意選択の実装形態においては、スケジュールされているキャリアが、奇数である識別番号を有するスケジュールされているキャリアと、偶数である識別番号を有するスケジュールされているキャリアとを含む場合には、トランシーバ１６１はさらに、スケジュールされているキャリアのうちで奇数である識別番号を有するスケジュールされているキャリア上のＴＰＣフィールドをＴＰＣフィールドの一方のグループとして決定するステップと、スケジュールされているキャリアのうちで偶数である識別番号を有するスケジュールされているキャリア上のＴＰＣフィールドをＴＰＣフィールドの他方のグループとして決定するステップとを行うように特に構成され得る。

この実施形態において提供されている基地局は、本発明の、図５において示されている実施形態において提供されている、キャリアアグリゲーションにおけるアップリンクコントロール情報送信方法、および図７において示されている実施形態において提供されている、キャリアアグリゲーションにおけるＰＵＣＣＨリソース割り振り方法を実施するために使用され得る。実施原理および技術的な効果は同様である。詳細がここで再び記述されることはない。

本発明の実施形態はさらに、ＵＥと、図１４もしくは図１５において示されている実施形態において提供されている、キャリアアグリゲーションにおけるアップリンクコントロール情報送信装置を含む基地局とを含む、またはＵＥと、図１６において示されている実施形態において提供されている基地局とを含む複数の通信システムを提供する。

方法実施形態のステップのうちのすべてまたはいくつかは、関連するハードウェアに指示するプログラムによって実施され得るということを当技術分野における標準的な技術者なら理解し得る。そのプログラムは、コンピュータ可読ストレージメディア内に格納され得る。そのプログラムが作動したときに、方法実施形態のステップが実行される。前述のストレージメディアは、プログラムコードを格納することができる任意のメディア、たとえば、ＲＯＭ、ＲＡＭ、磁気ディスク、または光ディスクを含む。

最後に、前述の実施形態は、本発明の技術的なソリューションについて記述することを意図されているにすぎず、本発明を限定することを意図されているものではないということに留意されたい。前述の実施形態を参照しながら本発明が詳細に記述されているが、当技術分野における標準的な技術者なら、彼らが、それでもなお、本発明の実施形態の技術的なソリューションの範囲から逸脱することなく、前述の実施形態において記述されている技術的なソリューションに対する修正形態を作成し得る、またはそれらの技術的な特徴のいくつかまたはすべてに対する均等な代替形態を作成し得るということを理解するはずである。

Claims (32)

1. キャリアアグリゲーションにおけるアップリンクコントロール情報送信方法であって、
   基地局によって、第１の表示情報をユーザ機器ＵＥへ送信するステップであって、前記第１の表示情報は、前記第１の表示情報に従ってアップリンクコントロール情報ＵＣＩを動的に決定するよう前記ＵＥに指示するために使用される、ステップと、
   前記基地局によって、ＰＵＣＣＨリソースを前記ＵＥへ割り振るステップであって、前記ＰＵＣＣＨリソースは、前記ＵＣＩを送信するために使用される、ステップとを含む方法。
2. 前記第１の表示情報は、第１のタイプの表示情報または第２のタイプの表示情報であり、
   前記第１のタイプの表示情報は、スケジュールされているキャリアの数量に従って前記基地局がダウンリンク割り当てインデックスＤＡＩ情報を生成する場合に、前記第１のタイプの表示情報に従ってＵＣＩを決定するよう前記ＵＥに指示するために使用され、
   前記第２のタイプの表示情報は、スケジュールされているコードワードの数量に従って前記基地局が前記ＤＡＩ情報を生成する場合に、前記第２のタイプの表示情報に従ってＵＣＩを決定するよう前記ＵＥに指示するために使用される請求項１に記載の方法。
3. 基地局によって、第１の表示情報をＵＥへ送信する前記ステップは、
   前記基地局によって、第１の構成情報を前記ＵＥへ送信するステップであって、前記第１の構成情報は、前記第１の表示情報を含む、ステップを含む請求項２に記載の方法。
4. 基地局によって、第１の表示情報をＵＥへ送信する前記ステップは、
   前記基地局によって、ダウンリンクコントロール情報ＤＣＩを前記ＵＥへ送信するステップであって、前記ＤＣＩは、前記第１の表示情報を含む、ステップを含む請求項２に記載の方法。
5. 基地局によって、第１の表示情報をＵＥへ送信する前記ステップは、
   前記基地局によって、第１の様式でエンコードされているＤＣＩを前記ＵＥへ送信するステップであって、前記第１の様式は、前記第１のタイプの表示情報に対応し、前記第１の様式においては、ＤＣＩエンコーディング中に生成される巡回冗長検査ＣＲＣコードにスクランブリングコードが付加されない、ステップ、または
   前記基地局によって、第２の様式でエンコードされているＤＣＩを前記ＵＥへ送信するステップであって、前記第２の様式は、前記第２のタイプの表示情報に対応し、前記第２の様式においては、ＤＣＩエンコーディング中に生成されるＣＲＣコードにスクランブリングコードが付加される、ステップを含む請求項２に記載の方法。
6. 前記基地局によって、ＰＵＣＣＨリソースを前記ＵＥへ割り振る前記ステップは、
   前記基地局によって、第２の構成情報を前記ＵＥへ送信するステップであって、前記第２の構成情報は、前記ＵＥ用のリソースリストを構成するために使用され、前記リソースリストは、複数のリソース情報グループを含む、ステップと、
   前記基地局によって、第２の表示情報を前記ＵＥへ送信するステップであって、前記第２の表示情報は、前記リソースリスト内の１つのリソース情報グループに対応するＰＵＣＣＨリソースを前記ＵＥに示すために使用される、ステップとを含む請求項１に記載の方法。
7. 前記複数のリソース情報グループは、別々のＰＵＣＣＨフォーマットに従ってアレンジされており、それぞれのＰＵＣＣＨフォーマットは、少なくとも１つのリソース情報グループに対応し、それぞれのリソース情報グループは、１つのＰＵＣＣＨリソースの開始アドレス表示情報およびサイズ表示情報を含み、
   前記第２の表示情報は、リソースインデックスＲＩを含み、前記ＲＩは、前記ＲＩに対応する第１のリソース情報グループを前記ＵＥに示すために使用される請求項６に記載の方法。
8. 前記基地局によって、第２の表示情報を前記ＵＥへ送信する前記ステップは、
   前記基地局によって、送信電力コントロールＴＰＣフィールドを使用することによって前記第２の表示情報を送信するステップを含む請求項７に記載の方法。
9. 前記複数のリソース情報グループは、別々のＰＵＣＣＨフォーマットに従ってアレンジされており、それぞれのＰＵＣＣＨフォーマットは、少なくとも１つのリソース情報グループに対応し、それぞれのリソース情報グループは、１つのＰＵＣＣＨリソースの開始アドレス表示情報を含み、
   前記第２の表示情報は、ＲＩを含み、前記ＲＩは、前記ＲＩに対応する第１のリソース情報グループを前記ＵＥに示すために使用され、
   前記第２の表示情報は、長さインデックスＬＩをさらに含み、前記ＬＩは、前記第１のリソース情報グループに対応するＰＵＣＣＨリソースのサイズを前記ＵＥに示すために使用される請求項６に記載の方法。
10. 前記基地局によって、第２の表示情報を前記ＵＥへ送信する前記ステップは、
    前記基地局によって、スケジュールされているキャリアに従ってＴＰＣフィールドの２つのグループを決定するステップであって、一方のグループは、前記ＲＩを送信するために使用され、他方のグループは、前記ＬＩを送信するために使用される、ステップ、または
    前記基地局によって、拡張ＴＰＣフィールドを使用することによって前記ＲＩおよび前記ＬＩを送信するステップであって、前記拡張ＴＰＣフィールドは、３ビット以上を含む、ステップを含む請求項９に記載の方法。
11. 前記リソースリスト内のそれぞれのリソース情報グループは、１つのＰＵＣＣＨリソースの開始アドレス表示情報およびサイズ表示情報を含み、
    前記第２の表示情報は、ＲＩを含み、前記ＲＩは、前記ＲＩに対応する第１のリソース情報グループを前記ＵＥに示すために使用され、
    前記第２の表示情報は、フォーマットインデックスＦＩをさらに含み、前記ＦＩは、前記第１のリソース情報グループに対応するＰＵＣＣＨリソースのＰＵＣＣＨフォーマットを前記ＵＥに示すために使用される請求項６に記載の方法。
12. 前記基地局によって、第２の表示情報を前記ＵＥへ送信する前記ステップは、
    前記基地局によって、スケジュールされているキャリアに従ってＴＰＣフィールドの２つのグループを決定するステップであって、一方のグループは、前記ＲＩを送信するために使用され、他方のグループは、前記ＦＩを送信するために使用される、ステップ、または
    前記基地局によって、拡張ＴＰＣフィールドを使用することによって前記ＲＩおよび前記ＦＩを送信するステップであって、前記拡張ＴＰＣフィールドは、３ビット以上を含む、ステップを含む請求項１１に記載の方法。
13. 前記リソースリスト内のそれぞれのリソース情報グループは、１つのＰＵＣＣＨリソースの開始アドレス表示情報を含み、
    前記第２の表示情報は、ＲＩを含み、前記ＲＩは、前記ＲＩに対応する第１のリソース情報グループを前記ＵＥに示すために使用され、
    前記第２の表示情報は、ＦＩおよびＬＩをさらに含み、前記ＦＩは、前記第１のリソース情報グループに対応するＰＵＣＣＨリソースのＰＵＣＣＨフォーマットを前記ＵＥに示すために使用され、前記ＬＩは、前記第１のリソース情報グループに対応する前記ＰＵＣＣＨリソースのサイズを前記ＵＥに示すために使用される請求項６に記載の方法。
14. 前記リソースリストは、２つのリソース情報グループを含み、
    前記基地局によって、第２の表示情報を前記ＵＥへ送信する前記ステップは、
    前記基地局によって、スケジュールされているキャリアに従ってＴＰＣフィールドの２つのグループを決定するステップであって、一方のグループは、前記ＲＩおよび前記ＦＩを送信するために使用され、他方のグループは、前記ＬＩを送信するために使用される、ステップを含む請求項１３に記載の方法。
15. 前記基地局によって、スケジュールされているキャリアに従ってＴＰＣフィールドの２つのグループを決定する前記ステップは、
    前記基地局によって、前記スケジュールされているキャリアの識別番号の順序に従って前記スケジュールされているキャリアを２つのグループへとグループ化するステップと、
    スケジュールされているキャリアの前記２つのグループのそれぞれの上のＴＰＣフィールドをＴＰＣフィールドの一方のグループとして決定するステップとを含む請求項１０、１２、または１４のいずれか一項に記載の方法。
16. 前記スケジュールされているキャリアは、奇数である識別番号を有するスケジュールされているキャリアと、偶数である識別番号を有するスケジュールされているキャリアとを含み、
    前記基地局によって、スケジュールされているキャリアに従ってＴＰＣフィールドの２つのグループを決定する前記ステップは、
    前記スケジュールされているキャリアのうちで奇数である識別番号を有するスケジュールされているキャリア上のＴＰＣフィールドをＴＰＣフィールドの一方のグループとして決定するステップと、
    前記スケジュールされているキャリアのうちで偶数である識別番号を有するスケジュールされているキャリア上のＴＰＣフィールドをＴＰＣフィールドの他方のグループとして決定するステップとを含む請求項１０、１２、または１４のいずれか一項に記載の方法。
17. キャリアアグリゲーションにおけるアップリンクコントロール情報送信装置であって、
    第１の表示情報をユーザ機器ＵＥへ送信するステップであって、前記第１の表示情報は、前記第１の表示情報に従ってアップリンクコントロール情報ＵＣＩを動的に決定するよう前記ＵＥに指示するために使用される、ステップを行うように構成されている第１の送信モジュールと、
    ＰＵＣＣＨリソースを前記ＵＥへ割り振るステップであって、前記ＰＵＣＣＨリソースは、前記ＵＣＩを送信するために使用される、ステップを行うように構成されているリソース割り振りモジュールとを含む装置。
18. 前記第１の表示情報は、第１のタイプの表示情報または第２のタイプの表示情報であり、
    前記第１のタイプの表示情報は、スケジュールされているキャリアの数量に従って前記基地局がダウンリンク割り当てインデックスＤＡＩ情報を生成する場合に、前記第１のタイプの表示情報に従ってＵＣＩを決定するよう前記ＵＥに指示するために使用され、
    前記第２のタイプの表示情報は、スケジュールされているコードワードの数量に従って前記基地局が前記ＤＡＩ情報を生成する場合に、前記第２のタイプの表示情報に従ってＵＣＩを決定するよう前記ＵＥに指示するために使用される請求項１７に記載の装置。
19. 前記第１の送信モジュールは、第１の構成情報を前記ＵＥへ送信するステップであって、前記第１の構成情報は、前記第１の表示情報を含む、ステップを行うように特に構成されている請求項１８に記載の装置。
20. 前記第１の送信モジュールは、ダウンリンクコントロール情報ＤＣＩを前記ＵＥへ送信するステップであって、前記ＤＣＩは、前記第１の表示情報を含む、ステップを行うように特に構成されている請求項１８に記載の装置。
21. 前記第１の送信モジュールは、
    第１の様式でエンコードされているＤＣＩを前記ＵＥへ送信するステップであって、前記第１の様式は、前記第１のタイプの表示情報に対応し、前記第１の様式においては、ＤＣＩエンコーディング中に生成される巡回冗長検査ＣＲＣにスクランブリングコードが付加されない、ステップ、または
    第２の様式でエンコードされているＤＣＩを前記ＵＥへ送信するステップであって、前記第２の様式は、前記第２のタイプの表示情報に対応し、前記第２の様式においては、ＤＣＩエンコーディング中に生成されるＣＲＣコードにスクランブリングコードが付加される、ステップを行うように特に構成されている請求項１８に記載の装置。
22. 前記リソース割り振りモジュールは、構成モジュール、表示モジュール、および第２の送信モジュールを含み、
    前記構成モジュールは、第２の構成情報を生成するように構成されており、前記第２の構成情報は、前記ＵＥ用のリソースリストを構成するために使用され、前記リソースリストは、複数のリソース情報グループを含み、
    前記表示モジュールは、第２の表示情報を生成するように構成されており、前記第２の表示情報は、前記リソースリスト内の１つのリソース情報グループに対応するＰＵＣＣＨリソースを前記ＵＥに示すために使用され、
    前記第２の送信モジュールは、前記第２の構成情報および前記第２の表示情報を前記ＵＥへ送信するように構成されている請求項１７に記載の装置。
23. 前記複数のリソース情報グループは、別々のＰＵＣＣＨフォーマットに従ってアレンジされており、それぞれのＰＵＣＣＨフォーマットは、少なくとも１つのリソース情報グループに対応し、それぞれのリソース情報グループは、１つのＰＵＣＣＨリソースの開始アドレス表示情報およびサイズ表示情報を含み、
    前記第２の表示情報は、リソースインデックスＲＩを含み、前記ＲＩは、前記ＲＩに対応する第１のリソース情報グループを前記ＵＥに示すために使用される請求項２２に記載の装置。
24. 前記第２の送信モジュールは、送信電力コントロールＴＰＣフィールドを使用することによって前記第２の表示情報を送信するステップを行うように特に構成されている請求項２３に記載の装置。
25. 前記複数のリソース情報グループは、別々のＰＵＣＣＨフォーマットに従ってアレンジされており、それぞれのＰＵＣＣＨフォーマットは、少なくとも１つのリソース情報グループに対応し、それぞれのリソース情報グループは、１つのＰＵＣＣＨリソースの開始アドレス表示情報を含み、
    前記第２の表示情報は、ＲＩを含み、前記ＲＩは、前記ＲＩに対応する第２のリソース情報グループを前記ＵＥに示すために使用され、
    前記第２の表示情報は、長さインデックスＬＩをさらに含み、前記ＬＩは、前記第２のリソース情報グループに対応するＰＵＣＣＨリソースのサイズを前記ＵＥに示すために使用される請求項２２に記載の装置。
26. 前記第２の送信モジュールは、
    スケジュールされているキャリアに従ってＴＰＣフィールドの２つのグループを決定するステップであって、一方のグループは、前記ＲＩを送信するために使用され、他方のグループは、前記ＬＩを送信するために使用される、ステップ、または
    拡張ＴＰＣフィールドを使用することによって前記ＲＩおよび前記ＬＩを送信するステップであって、前記拡張ＴＰＣフィールドは、３ビット以上を含む、ステップを行うように特に構成されている請求項２５に記載の装置。
27. 前記リソースリスト内のそれぞれのリソース情報グループは、１つのＰＵＣＣＨリソースの開始アドレス表示情報およびサイズ表示情報を含み、
    前記第２の表示情報は、ＲＩを含み、前記ＲＩは、前記ＲＩに対応する第３のリソース情報グループを前記ＵＥに示すために使用され、
    前記第２の表示情報は、フォーマットインデックスＦＩをさらに含み、前記ＦＩは、前記第３のリソース情報グループに対応するＰＵＣＣＨリソースのＰＵＣＣＨフォーマットを前記ＵＥに示すために使用される請求項２２に記載の装置。
28. 前記第２の送信モジュールは、
    スケジュールされているキャリアに従ってＴＰＣフィールドの２つのグループを決定するステップであって、一方のグループは、前記ＲＩを送信するために使用され、他方のグループは、前記ＦＩを送信するために使用される、ステップ、または
    拡張ＴＰＣフィールドを使用することによって前記ＲＩおよび前記ＦＩを送信するステップであって、前記拡張ＴＰＣフィールドは、３ビット以上を含む、ステップを行うように特に構成されている請求項２７に記載の装置。
29. 前記リソースリスト内のそれぞれのリソース情報グループは、１つのＰＵＣＣＨリソースの開始アドレス表示情報を含み、
    前記第２の表示情報は、ＲＩを含み、前記ＲＩは、前記ＲＩに対応する第４のリソース情報グループを前記ＵＥに示すために使用され、
    前記第２の表示情報は、ＦＩおよびＬＩをさらに含み、前記ＦＩは、前記第４のリソース情報グループに対応するＰＵＣＣＨリソースのＰＵＣＣＨフォーマットを前記ＵＥに示すために使用され、前記ＬＩは、前記第４のリソース情報グループに対応する前記ＰＵＣＣＨリソースのサイズを前記ＵＥに示すために使用される請求項２２に記載の装置。
30. 前記リソースリストは、２つのリソース情報グループを含み、
    前記第２の送信モジュールは、スケジュールされているキャリアに従ってＴＰＣフィールドの２つのグループを決定するステップであって、一方のグループは、前記ＲＩおよび前記ＦＩを送信するために使用され、他方のグループは、前記ＬＩを送信するために使用される、ステップを行うように特に構成されている請求項２９に記載の装置。
31. 前記第２の送信モジュールは、
    前記スケジュールされているキャリアの識別番号の順序に従って前記スケジュールされているキャリアを２つのグループへとグループ化するステップと、
    スケジュールされているキャリアの前記２つのグループのそれぞれの上のＴＰＣフィールドをＴＰＣフィールドの一方のグループとして決定するステップとを行うように特に構成されている請求項２６、２８、または３０のいずれか一項に記載の装置。
32. 前記スケジュールされているキャリアは、奇数である識別番号を有するスケジュールされているキャリアと、偶数である識別番号を有するスケジュールされているキャリアとを含み、
    前記第２の送信モジュールは、
    前記スケジュールされているキャリアのうちで奇数である識別番号を有するスケジュールされているキャリア上のＴＰＣフィールドをＴＰＣフィールドの一方のグループとして決定するステップと、
    前記スケジュールされているキャリアのうちで偶数である識別番号を有するスケジュールされているキャリア上のＴＰＣフィールドをＴＰＣフィールドの他方のグループとして決定するステップとを行うように特に構成されている請求項２６、２８、または３０のいずれか一項に記載の装置。

Images