特開 2022-110042 多数のキャリアを用いて動作するためのアップリンクフィードバック方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2022110042

(43)【公開日】2022-07-28

(54)【発明の名称】多数のキャリアを用いて動作するためのアップリンクフィードバック方法

(51)【国際特許分類】

   H04W 72/04 20090101AFI20220721BHJP

   H04W 28/04 20090101ALI20220721BHJP

   H04W 72/12 20090101ALI20220721BHJP

   H04W 52/18 20090101ALI20220721BHJP

   H04L 1/16 20060101ALI20220721BHJP

【ＦＩ】

H04W72/04 136

H04W28/04 110

H04W72/12 150

H04W52/18

H04L1/16

【審査請求】有

【請求項の数】16

【出願形態】ＯＬ

(21)【出願番号】P 2022076968

(22)【出願日】2022-05-09

(62)【分割の表示】P 2020183626の分割

【原出願日】2016-01-28

(31)【優先権主張番号】62/108,849

(32)【優先日】2015-01-28

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】62/144,835

(32)【優先日】2015-04-08

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】62/161,057

(32)【優先日】2015-05-13

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】62/166,523

(32)【優先日】2015-05-26

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】62/214,552

(32)【優先日】2015-09-04

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】62/250,890

(32)【優先日】2015-11-04

(33)【優先権主張国・地域又は機関】US

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．３ＧＰＰ

２．ＷＣＤＭＡ

(71)【出願人】

【識別番号】510030995

【氏名又は名称】インターデイジタル パテント ホールディングス インコーポレイテッド

(74)【代理人】

【識別番号】110001243

【氏名又は名称】弁理士法人谷・阿部特許事務所

(72)【発明者】

【氏名】ポール マリニエール

(72)【発明者】

【氏名】ギスラン ペルティエ

(72)【発明者】

【氏名】ジェイ．パトリック トゥーハー

(72)【発明者】

【氏名】ポウリヤ サデギ

(72)【発明者】

【氏名】マリアン ルドルフ

【テーマコード（参考）】

5K014

5K067

【Ｆターム（参考）】

5K014DA02

5K067AA23

5K067EE02

5K067EE10

5K067HH21

5K067HH28

5K067JJ13

(57)【要約】      （修正有）

【課題】複数キャリアを用いて動作する無線送受信ユニット（ＷＴＲＵ）におけるアップリンクフィードバック方法を提供する。
【解決手段】方法は、複数のキャリアのセット上で複数のトランスポートブロックを受信するステップと、複数のトランスポートブロックについてのＨＡＲＱ－ＡＣＫフィードバックと複数の構成されたキャリアのうちの少なくとも１つに対するＣＳＩフィードバックおよびＣＲＣを生成するステップと、ＨＡＲＱ－ＡＣＫフィードバックのビット数とＣＳＩフィードバックのビット数とＣＲＣのビット数とを含むフィードバックメッセージを生成するステップと、ＨＡＲＱ－ＡＣＫフィードバックビット数とＣＳＩフィードバックビット数とＣＲＣビット数とに基づいてＰＵＣＣＨ送信のために使用される電力を決定するステップと、この決定された電力で、ＰＵＣＣＨ送信においてフィードバックメッセージを送信するステップと、を備える。
【選択図】図５

【特許請求の範囲】

【請求項1】

無線送受信ユニット（ＷＴＲＵ）における、複数の構成されたキャリアを用いて動作する、アップリンクフィードバックのための方法であって、
前記複数の構成されたキャリア上において、複数のトランスポートブロックを受信するステップと、
前記複数のトランスポートブロックに対するハイブリッド自動再送要求（ＨＡＲＱ）－肯定応答（ＡＣＫ）フィードバック、前記複数の構成されたキャリアのうちの少なくとも１つに対するチャネル状態情報（ＣＳＩ）フィードバック、および、巡回冗長検査（ＣＲＣ）を生成するステップと、
前記ＨＡＲＱ－ＡＣＫフィードバックのためのＨＡＲＱ－ＡＣＫフィードバックビットの数と、前記ＣＳＩフィードバックのためのＣＳＩフィードバックビットの数と、前記ＣＲＣのためのＣＲＣビットの数とを含む、フィードバックメッセージを生成するステップと、
ＨＡＲＱ－ＡＣＫフィードバックビットの前記数と、ＣＳＩフィードバックビットの前記数と、前記ＣＲＣビットの前記数とに基づいて、物理アップリンク制御チャネル（ＰＵＣＣＨ）送信のために使用されることになる電力を決定するステップと、
前記決定された電力で、前記ＰＵＣＣＨ送信において前記フィードバックメッセージを送信するステップと
を備えることを特徴とする方法。

【請求項2】

前記ＣＲＣビットの前記数は、ＨＡＲＱ－ＡＣＫフィードバックビットの前記数およびＣＳＩフィードバックビットの前記数に基づいていることを特徴とする請求項１に記載の方法。

【請求項3】

スケジューリング要求（ＳＲ）を生成するステップ
をさらに備えることを特徴とする請求項１に記載の方法。

【請求項4】

前記フィードバックメッセージは、前記ＳＲのためのＳＲビットの数をさらに含むことを特徴とする請求項３に記載の方法。

【請求項5】

ＣＲＣビットの前記数は、ＨＡＲＱ－ＡＣＫフィードバックビットの前記数、ＣＳＩフィードバックビットの前記数、および、ＳＲビットの前記数に基づいていることを特徴とする請求項４に記載の方法。

【請求項6】

前記ＨＡＲＱ－ＡＣＫフィードバックのためのＨＡＲＱ－ＡＣＫフィードバックビットの前記数、または、前記ＣＳＩフィードバックのためのＣＳＩフィードバックビットの前記数の少なくとも１つは、前記複数の構成されたキャリアにおけるキャリアのための複数のダウンリンク割当てに基づいて、決定されることを特徴とする請求項１に記載の方法。

【請求項7】

前記ＨＡＲＱ－ＡＣＫフィードバックのためのＨＡＲＱ－ＡＣＫフィードバックビットの前記数、または、前記ＣＳＩフィードバックのためのＣＳＩフィードバックビットの前記数の少なくとも１つは、トランスポートブロックの数または前記複数の構成されたキャリアにおけるキャリアの数の少なくとも１つに基づいて、決定されることを特徴とする請求項１に記載の方法。

【請求項8】

前記ＨＡＲＱ－ＡＣＫフィードバックのためのＨＡＲＱ－ＡＣＫフィードバックビットの前記数、または、前記ＣＳＩフィードバックのためのＣＳＩフィードバックビットの前記数の少なくとも１つは、前記トランスポートブロックがその上で受信されるサブフレームの数に基づいて、決定されることを特徴とする請求項１に記載の方法。

【請求項9】

前記複数の構成されたキャリアは、５を越える構成されたキャリアを含むことを特徴とする請求項１に記載の方法。

【請求項10】

前記フィードバックメッセージは、サブフレームにおいて前記決定された電力で、前記ＰＵＣＣＨ送信において送信されることを特徴とする請求項１に記載の方法。

【請求項11】

複数の構成されたキャリアを用いて動作する、アップリンクフィードバックのための無線送受信ユニット（ＷＴＲＵ）であって、
送受信機と、
前記送受信機に動作可能に結合されたプロセッサとを備え、
前記送受信機は、前記複数の構成されたキャリア上において、複数のトランスポートブロックを受信するよう構成され、
前記プロセッサは、前記複数のトランスポートブロックに対するハイブリッド自動再送要求（ＨＡＲＱ）－肯定応答（ＡＣＫ）フィードバック、前記複数の構成されたキャリアのうちの少なくとも１つに対するチャネル状態情報（ＣＳＩ）フィードバック、および、巡回冗長検査（ＣＲＣ）を生成するよう構成され、
前記プロセッサは、前記ＨＡＲＱ－ＡＣＫフィードバックのためのＨＡＲＱ－ＡＣＫフィードバックビットの数と、前記ＣＳＩフィードバックのためのＣＳＩフィードバックビットの数と、前記ＣＲＣのためのＣＲＣビットの数とを含む、フィードバックメッセージを生成するよう構成され、
前記プロセッサは、ＨＡＲＱ－ＡＣＫフィードバックビットの前記数と、ＣＳＩフィードバックビットの前記数と、前記ＣＲＣビットの前記数とに基づいて、物理アップリンク制御チャネル（ＰＵＣＣＨ）送信のために使用されることになる電力を決定するよう構成され、
前記送受信機および前記プロセッサは、前記決定された電力で、前記ＰＵＣＣＨ送信において前記フィードバックメッセージを送信するよう構成されたこと
を特徴とするＷＴＲＵ。

【請求項12】

前記ＣＲＣビットの前記数は、ＨＡＲＱ－ＡＣＫフィードバックビットの前記数およびＣＳＩフィードバックビットの前記数に基づいていることを特徴とする請求項１１に記載のＷＴＲＵ。

【請求項13】

前記プロセッサは、スケジューリング要求（ＳＲ）を生成するよう構成されたことを特徴とする請求項１１に記載のＷＴＲＵ。

【請求項14】

前記フィードバックメッセージは、前記ＳＲのためのＳＲビットの数をさらに含むことを特徴とする請求項１３に記載のＷＴＲＵ。

【請求項15】

ＣＲＣビットの前記数は、ＨＡＲＱ－ＡＣＫフィードバックビットの前記数、ＣＳＩフィードバックビットの前記数、および、ＳＲビットの前記数に基づいていることを特徴とする請求項１４に記載のＷＴＲＵ。

【請求項16】

前記ＨＡＲＱ－ＡＣＫフィードバックのためのＨＡＲＱ－ＡＣＫフィードバックビットの前記数、または、前記ＣＳＩフィードバックのためのＣＳＩフィードバックビットの前記数の少なくとも１つは、前記複数の構成されたキャリアにおけるキャリアのための複数のダウンリンク割当てに基づいて、決定されることを特徴とする請求項１１に記載のＷＴＲＵ。

【発明の詳細な説明】

【背景技術】

【0001】

本出願は、それらの内容が参照によって本明細書に組み込まれる、２０１５年１月２８日に出願された米国仮出願第６２／１０８８４９号、２０１５年４月８日に出願された米国仮出願第６２／１４４８３５号、２０１５年５月１３日に出願された米国仮出願第６２／１６１０５７号、２０１５年５月２６日に出願された米国仮出願第６２／１６６５２３号、２０１５年９月４日に出願された米国仮出願第６２／２１４５５２号、および２０１５年１１月４日に出願された米国仮出願第６２／２５０８９０号の利益を主張する。

【0002】

ロングタームエボリューション（ＬＴＥ）のためのキャリアアグリゲーションが、第３世代パートナシッププロジェクト（３ＧＰＰ）リリース１０において導入された。この機能は、無線送受信ユニット（ＷＴＲＵ）が、同時に２つ以上のキャリア上において送信および受信することを可能にして、エアインターフェース上におけるそれのピークデータレートの向上をもたらす。アグリゲートすることができるキャリアの最大数は、最大帯域幅が１００メガヘルツ（ＭＨｚ）の場合、５つである。

【発明の概要】

【発明が解決しようとする課題】

【0003】

ＬＴＥにおいては、ダウンリンクにおけるデータの送信は、物理ダウンリンク共用チャネル（ＰＤＳＣＨ）を使用して実行することができる。この物理チャネルは、（ＷＴＲＵにおける）受信機が、トランスポートブロックの連続する送信を組み合わせて、各再送において復号が成功する確率を高めることができる、ハイブリッド自動再送要求（ＨＡＲＱ）送信をサポートする。ＷＴＲＵは、トランスポートブロックの与えられた受信の試みについて、受信が成功したことを、肯定応答（ＡＣＫ）を用いて、または成功しなかったことを、否定応答（ＮＡＣＫ）を用いて報告することができる。いくつかのケースにおいては、ＷＴＲＵは、不連続送信（ＤＴＸ）などにおいて、トランスポートブロックが送信されたことを検出しなかったことも報告することができる。
多数のキャリアを用いて動作するためのアップリンクフィードバック方法を提供する。

【課題を解決するための手段】

【0004】

多数のキャリアを用いて動作するためのアップリンクフィードバックについての方法および装置が、本明細書において開示される。無線送受信ユニット（ＷＴＲＵ）における方法は、ダウンリンク制御情報（ＤＣＩ）を受信するステップであって、ＤＣＩは、物理ダウンリンク共用チャネル（ＰＤＳＣＨ）送信をスケジュールし、ＤＣＩは、表示（indication）を含む、ステップと、ＰＤＳＣＨ送信に対して、ハイブリッド自動再送要求（ＨＡＲＱ）肯定応答（ＡＣＫ）／否定応答（ＮＡＣＫ）（Ａ／Ｎ）報告が予期される(expected)かどうかを、ＤＣＩ内の表示（indication）に基づいて決定するステップと、ＰＤＳＣＨ送信に対して、それが予期されるという条件において、ＨＡＲＱ Ａ／Ｎ報告を受信するステップとを含む。

【0005】

さらなる例は、ＨＡＲＱ－ＡＣＫペイロードを減少させ、物理アップリンク制御チャネル（ＰＵＣＣＨ）ペイロードを増加させ、物理アップリンク共用チャネル（ＰＵＳＣＨ）内におけるアップリンク制御情報（ＵＣＩ）ペイロードを増加させ、ならびにフィードバックグループまたはフィードバックグループの組合せのために使用されるリソースまたはサブリソースを、いずれかのＰＤＳＣＨと関連付けられたダウンリンク制御シグナリングの、およびこのフィードバックグループと関連付けられたインデックスまたは順序の組合せに基づいて決定するためのソリューションを含む。

【0006】

さらなる例は、動的コードブックおよびフィードバック圧縮を可能にするための、ＰＵＣＣＨ上におけるＵＣＩの動的スケジューリングと、各ダウンリンク割り当てに対するインデックスとを含む。例においては、ＷＴＲＵは、コードブック内の情報ビットの順序の決定を行うことができる。ＷＴＲＵは、復号性能を最適化するように、コードブック順列（permutation）の選択を行うことができる。さらなる例は、コードブックインジケータを含む。さらに、選択するキャリアの特定のグループは、どのキャリアについての割り当てを受信したかに基づいて決定することができる。加えて、コードブックは、１つまたは複数の方法を使用して決定することができる。また、最終的な割り当ての決定のために、Ａ／Ｎリソースインジケータ（ＡＲＩ）を使用することができる。さらに、複数のチャネル状態情報（ＣＳＩ）報告を、１つまたは複数の方法を使用して、サブフレーム内において送信することができる。例えばＷＴＲＵは、サブフレーム内におけるＨＡＲＱ－ＡＣＫ、定期的な(periodic)ＣＳＩ報告、および／またはスケジューリング要求（ＳＲ）の送信のために使用することができる各ＰＵＣＣＨリソースに対して最大ペイロードを用いるように構成することができる。

【0007】

例においては、ＷＴＲＵは、複数の構成されたキャリアのセット上において、複数のトランスポートブロックを受信し、複数のトランスポートブロックについてのＨＡＲＱ－ＡＣＫフィードバックを生成し、ＨＡＲＱ－ＡＣＫフィードバックのために使用するＨＡＲＱ－ＡＣＫフィードバックビットの数を決定することができる。さらに、ＷＴＲＵは、ＨＡＲＱ－ＡＣＫフィードバックビットの数が閾値以下であるという条件において、ＨＡＲＱ－ＡＣＫフィードバックビットに、リード－マラー符号化を適用することができる。ＷＴＲＵは、その後、エンコードされたＨＡＲＱ－ＡＣＫフィードバックビットを送信することができる。

【0008】

加えて、ＷＴＲＵは、ＨＡＲＱ－ＡＣＫフィードバックビットの数が閾値よりも多いという条件において、ＨＡＲＱ－ＡＣＫフィードバックビットに、巡回冗長検査（ＣＲＣ）ビットを追加することができる。また、ＷＴＲＵは、ＨＡＲＱ－ＡＣＫフィードバックビットの数が閾値よりも多いという条件において、ＨＡＲＱ－ＡＣＫフィードバックビットおよびＣＲＣビットに、畳み込み符号化を適用することができる。ＷＴＲＵは、その後、エンコードされたＨＡＲＱ－ＡＣＫフィードバックビットおよびＣＲＣビットを送信することができる。

【0009】

さらに、ＷＴＲＵは、構成されたキャリア（configured carriers）のセット内のキャリアに対する複数のダウンリンク割り当てに基づいて、ＨＡＲＱ－ＡＣＫフィードバックのために使用するＨＡＲＱ－ＡＣＫフィードバックビットの数を決定することができる。構成されたキャリアのセットは、６つ以上の構成されたキャリアを含むことができる。

【0010】

別の例において、ＷＴＲＵは、複数の構成されたキャリアのセット上において、複数のトランスポートブロックを受信し、複数のトランスポートブロックについてのＨＡＲＱ－ＡＣＫフィードバックおよびＣＳＩフィードバックを生成することができる。ＷＴＲＵは、その後、ＨＡＲＱ－ＡＣＫフィードバックのために使用するＨＡＲＱ－ＡＣＫフィードバックビットの数と、ＣＳＩフィードバックのために使用するＣＳＩフィードバックビットの数とを含む、フィードバックメッセージを生成することができる。ＷＴＲＵは、その後、ＨＡＲＱ－ＡＣＫフィードバックビットの数と、ＣＳＩフィードバックビットの数とに基づいて、ＰＵＣＣＨフォーマットを決定することができる。加えて、ＷＴＲＵは、その後、決定されたＰＵＣＣＨフォーマットを使用して、フィードバックメッセージを送信することができる。

【0011】

さらに、ＷＴＲＵは、構成されたキャリアのセット内のキャリアに対する複数のダウンリンク割り当てに基づいて、ＨＡＲＱ－ＡＣＫフィードバックのために使用するＨＡＲＱ－ＡＣＫフィードバックビットの数、ＣＳＩフィードバックのために使用するＣＳＩフィードバックビットの数、または両方を決定することができる。例においては、ＷＴＲＵは、４つのＰＵＣＣＨフォーマットから選択することができる。

【0012】

より詳細な理解は、添付の図面と関連する例として与えられる、以下の説明から得ることができる。

【発明の効果】

【0013】

多数のキャリアを用いて動作するアップリンクフィードバック方法が提供される。

【図面の簡単な説明】

【0014】

【図1A】１つまたは複数の開示される実施形態を実施することができる、例示的な通信システムの図である。

【図1B】図１Ａの通信システム内で使用できる、例示的な無線送受信ユニット（ＷＴＲＵ）のシステム図である。

【図1C】図１Ａの通信システム内で使用できる、例示的な無線アクセスネットワークおよびコアネットワークのシステム図である。

【図2】２つの連続するリソースブロックを利用する拡張された物理アップリンク制御チャネル設計のための、可能なリソースエレメントマッピングの例の図である。

【図3】フィードバックのサイズおよびタイプに基づいた、ＰＵＣＣＨフォーマットについての例示的選択プロセスの図である。

【図4】ハイブリッド自動再送要求（ＨＡＲＱ）肯定応答／否定応答（Ａ／Ｎ）コードブック決定の例の図である。

【図5】送信されるフィードバックビットの数に基づいた、チャネル符号化および巡回冗長検査（ＣＲＣ）の包含についての例示的な選択プロセスの図である。

【発明を実施するための形態】

【0015】

図１Ａは、１つまたは複数の開示される実施形態を実施することができる、例示的な通信システム１００の図である。通信システム１００は、音声、データ、ビデオ、メッセージング、放送などのコンテンツを複数の無線ユーザに提供する、多元接続システムとすることができる。通信システム１００は、複数の無線ユーザが、無線帯域幅を含むシステムリソースの共用を通して、そのようなコンテンツにアクセスすることを可能にすることができる。例えば、通信システム１００は、符号分割多元接続（ＣＤＭＡ）、時分割多元接続（ＴＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、およびシングルキャリアＦＤＭＡ（ＳＣ－ＦＤＭＡ）など、１つまたは複数のチャネルアクセス方法を利用することができる。

【0016】

図１Ａに示されるように、通信システム１００は、無線送受信ユニット（ＷＴＲＵ）１０２ａ、１０２ｂ、１０２ｃ、１０２ｄ、無線アクセスネットワーク（ＲＡＮ）１０４、コアネットワーク１０６、公衆交換電話網（ＰＳＴＮ）１０８、インターネット１１０、および他のネットワーク１１２を含むことができるが、開示される実施形態は、任意の数のＷＴＲＵ、基地局、ネットワーク、および／またはネットワーク要素を企図していることが理解されよう。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの各々は、無線環境において動作および／または通信するように構成された任意のタイプのデバイスとすることができる。例として、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、無線信号を送信および／または受信するように構成することができ、ユーザ機器（ＵＥ）、移動局、固定もしくは移動加入者ユニット、ページャ、セルラ電話、パーソナルデジタルアシスタント（ＰＤＡ）、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、無線センサ、および家電製品などを含むことができる。

【0017】

通信システム１００は、基地局１１４ａおよび基地局１１４ｂも含むことができる。基地局１１４ａ、１１４ｂの各々は、コアネットワーク１０６、インターネット１１０、および／または他のネットワーク１１２などの１つまたは複数の通信ネットワークへのアクセスを容易にするために、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの少なくとも１つと無線でインターフェースを取るように構成された、任意のタイプのデバイスとすることができる。例として、基地局１１４ａ、１１４ｂは、基地送受信局（ＢＴＳ）、ノードＢ、ｅノードＢ、ホームノードＢ、ホームｅノードＢ、サイトコントローラ、アクセスポイント（ＡＰ）、および無線ルータなどとすることができる。基地局１１４ａ、１１４ｂは、各々、単一の要素として示されているが、基地局１１４ａ、１１４ｂは、任意の数の相互接続された基地局および／またはネットワーク要素を含むことができることが理解されよう。

【0018】

基地局１１４ａは、ＲＡＮ１０４の部分とすることができ、ＲＡＮ１０４は、他の基地局、および／または基地局コントローラ（ＢＳＣ）、無線ネットワークコントローラ（ＲＮＣ）、中継ノードなどのネットワーク要素（図示せず）も含むことができる。基地局１１４ａおよび／または基地局１１４ｂは、セル（図示せず）と呼ばれることがある特定の地理的領域内で、無線信号を送信および／または受信するように構成することができる。セルは、さらにセルセクタに分割することができる。例えば、基地局１１４ａに関連付けられたセルは、３つのセクタに分割することができる。したがって、一実施形態では、基地局１１４ａは、送受信機を３つ、すなわち、セルのセクタ毎に１つずつ含むことができる。別の実施形態では、基地局１１４ａは、多入力多出力（ＭＩＭＯ）技術を利用することができ、したがって、セルのセクタ毎に複数の送受信機を利用することができる。

【0019】

基地局１１４ａ、１１４ｂは、エアインターフェース１１６上で、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの１つまたは複数と通信することができ、エアインターフェース１１６は、任意の適切な無線通信リンク（例えば、無線周波（ＲＦ）、マイクロ波、赤外線（ＩＲ）、紫外線（ＵＶ）、可視光など）とすることができる。エアインターフェース１１６は、任意の適切な無線アクセス技術（ＲＡＴ）を使用して確立することができる。

【0020】

より具体的には、上で言及されたように、通信システム１００は、多元接続システムとすることができ、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、およびＳＣ－ＦＤＭＡなどの、１つまたは複数のチャネルアクセス方式を利用することができる。例えば、ＲＡＮ１０４内の基地局１１４ａ、およびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ユニバーサル移動体通信システム（ＵＭＴＳ）地上無線アクセス（ＵＴＲＡ）などの無線技術を実施することができ、それは、広帯域ＣＤＭＡ（ＷＣＤＭＡ）を使用して、エアインターフェース１１６を確立することができる。ＷＣＤＭＡは、高速パケットアクセス（ＨＳＰＡ）および／または進化型ＨＳＰＡ（ＨＳＰＡ＋）などの通信プロトコルを含むことができる。ＨＳＰＡは、高速ダウンリンクパケットアクセス（ＨＳＤＰＡ）および／または高速アップリンクパケットアクセス（ＨＳＵＰＡ）を含むことができる。

【0021】

別の実施形態では、基地局１１４ａ、およびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、進化型ＵＭＴＳ地上無線アクセス（Ｅ－ＵＴＲＡ）などの無線技術を実施することができ、それは、ロングタームエボリューション（ＬＴＥ）および／またはＬＴＥアドバンスト（ＬＴＥ－Ａ）を使用して、エアインターフェース１１６を確立することができる。

【0022】

他の実施形態では、基地局１１４ａ、およびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＩＥＥＥ８０２．１６（すなわち、マイクロ波アクセス用の世界的相互運用性（ＷｉＭＡＸ））、ＣＤＭＡ２０００、ＣＤＭＡ２０００ ＩＸ、ＣＤＭＡ２０００ ＥＶ－ＤＯ、暫定標準２０００（ＩＳ－２０００）、暫定標準９５（ＩＳ－９５）、暫定標準８５６（ＩＳ－８５６）、移動体通信用グローバルシステム（ＧＳＭ）、ＧＳＭエボリューション用の高速データレート（ＥＤＧＥ）、およびＧＳＭ ＥＤＧＥ（ＧＥＲＡＮ）などの無線技術を実施することができる。

【0023】

図１Ａの基地局１１４ｂは、例えば、無線ルータ、ホームノードＢ、ホームｅノードＢ、またはアクセスポイントとすることができ、職場、家庭、乗物、およびキャンパスなどの局所的エリアにおける無線接続性を容易にするために、任意の適切なＲＡＴを利用することができる。一実施形態では、基地局１１４ｂ、およびＷＴＲＵ１０２ｃ、１０２ｄは、ＩＥＥＥ８０２．１１などの無線技術を実施して、無線ローカルエリアネットワーク（ＷＬＡＮ）を確立することができる。別の実施形態では、基地局１１４ｂ、およびＷＴＲＵ１０２ｃ、１０２ｄは、ＩＥＥＥ８０２．１５などの無線技術を実施して、無線パーソナルエリアネットワーク（ＷＰＡＮ）を確立することができる。また別の実施形態では、基地局１１４ｂ、およびＷＴＲＵ１０２ｃ、１０２ｄは、セルラベースのＲＡＴ（例えば、ＷＣＤＭＡ、ＣＤＭＡ２０００、ＧＳＭ、ＬＴＥ、ＬＴＥ－Ａなど）を利用して、ピコセルまたはフェムトセルを確立することができる。図１Ａに示されるように、基地局１１４ｂは、インターネット１１０への直接的な接続を有することがある。したがって、基地局１１４ｂは、コアネットワーク１０６を介して、インターネット１１０にアクセスする必要がないことがある。

【0024】

ＲＡＮ１０４は、コアネットワーク１０６と通信することができ、コアネットワーク１０６は、音声、データ、アプリケーション、および／またはボイスオーバインターネットプロトコル（ＶｏＩＰ）サービスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの１つまたは複数に提供するように構成された、任意のタイプのネットワークとすることができる。例えば、コアネットワーク１０６は、呼制御、ビリングサービス、モバイルロケーションベースのサービス、プリペイド通話、インターネット接続性、ビデオ配信などを提供することができ、および／またはユーザ認証など、高レベルのセキュリティ機能を実行することができる。図１Ａには示されていないが、ＲＡＮ１０４および／またはコアネットワーク１０６は、ＲＡＮ１０４と同じＲＡＴまたは異なるＲＡＴを利用する他のＲＡＮと直接的または間接的に通信することができることが理解されよう。例えば、Ｅ－ＵＴＲＡ無線技術を利用することができるＲＡＮ１０４に接続されるのに加えて、コアネットワーク１０６は、ＧＳＭ無線技術を利用する別のＲＡＮ（図示せず）とも通信することができる。

【0025】

コアネットワーク１０６は、ＰＳＴＮ１０８、インターネット１１０、および／または他のネットワーク１１２にアクセスするための、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのためのゲートウェイとしての役割も果たすことができる。ＰＳＴＮ１０８は、基本電話サービス（ＰＯＴＳ）を提供する回線交換電話網を含むことができる。インターネット１１０は、ＴＣＰ／ＩＰインターネットプロトコルスイート内の伝送制御プロトコル（ＴＣＰ）、ユーザデータグラムプロトコル（ＵＤＰ）、およびインターネットプロトコル（ＩＰ）など、共通の通信プロトコルを使用する、相互接続されたコンピュータネットワークおよびデバイスからなるグローバルシステムを含むことができる。ネットワーク１１２は、他のサービスプロバイダによって所有および／または運営される有線または無線通信ネットワークを含むことができる。例えば、ネットワーク１１２は、ＲＡＮ１０４と同じＲＡＴまたは異なるＲＡＴを利用することができる１つまたは複数のＲＡＮに接続された、別のコアネットワークを含むことができる。

【0026】

通信システム１００内のＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのいくつかまたはすべては、マルチモード機能を含むことができ、すなわち、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、異なる無線リンク上で異なる無線ネットワークと通信するための複数の送受信機を含むことができる。例えば、図１Ａに示されたＷＴＲＵ１０２ｃは、セルラベースの無線技術を利用することができる基地局１１４ａと通信するように、またＩＥＥＥ８０２無線技術を利用することができる基地局１１４ｂと通信するように構成することができる。

【0027】

図１Ｂは、例示的なＷＴＲＵ１０２のシステム図である。図１Ｂに示されるように、ＷＴＲＵ１０２は、プロセッサ１１８と、送受信機１２０と、送信／受信要素１２２と、スピーカ／マイクロフォン１２４と、キーパッド１２６と、ディスプレイ／タッチパッド１２８と、非リムーバブルメモリ１３０と、リムーバブルメモリ１３２と、電源１３４と、全地球測位システム（ＧＰＳ）チップセット１３６と、他の周辺機器１３８とを含むことができる。ＷＴＲＵ１０２は、実施形態との整合性を保ちながら、上述の要素の任意のサブコンビネーションを含むことができることが理解されよう。

【0028】

プロセッサ１１８は、汎用プロセッサ、専用プロセッサ、従来型プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと連携する１つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、他の任意のタイプの集積回路（ＩＣ）、および状態機械などとすることができる。プロセッサ１１８は、信号符号化、データ処理、電力制御、入力／出力処理、および／またはＷＴＲＵ１０２が無線環境で動作することを可能にする他の任意の機能性を実行することができる。プロセッサ１１８は、送受信機１２０に結合することができ、送受信機１２０は、送信／受信要素１２２に結合することができる。図１Ｂは、プロセッサ１１８と送受信機１２０を別々の構成要素として示しているが、プロセッサ１１８と送受信機１２０は、電子パッケージまたはチップ内に一緒に統合することができることが理解されよう。

【0029】

送信／受信要素１２２は、エアインターフェース１１６上で、基地局（例えば、基地局１１４ａ）に信号を送信し、または基地局から信号を受信するように構成することができる。例えば、一実施形態においては、送信／受信要素１２２は、ＲＦ信号を送信および／または受信するように構成されたアンテナとすることができる。別の実施形態においては、送信／受信要素１２２は、例えば、ＩＲ信号、ＵＶ信号、または可視光信号を送信および／または受信するように構成された放射器／検出器とすることができる。また別の実施形態においては、送信／受信要素１２２は、ＲＦ信号と光信号の両方を送信および受信するように構成することができる。送信／受信要素１２２は、無線信号の任意の組合せを送信および／または受信するように構成することができることが理解されよう。

【0030】

加えて、図１Ｂでは、送信／受信要素１２２は単一の要素として示されているが、ＷＴＲＵ１０２は、任意の数の送信／受信要素１２２を含むことができる。より具体的には、ＷＴＲＵ１０２は、ＭＩＭＯ技術を利用することができる。したがって、一実施形態では、ＷＴＲＵ１０２は、エアインターフェース１１６上で無線信号を送信および受信するための２つ以上の送信／受信要素１２２（例えば、複数のアンテナ）を含むことができる。

【0031】

送受信機１２０は、送信／受信要素１２２によって送信される信号を変調し、送信／受信要素１２２によって受信された信号を復調するように構成することができる。上で言及されたように、ＷＴＲＵ１０２は、マルチモード機能を有することができる。したがって、送受信機１２０は、ＷＴＲＵ１０２が、例えば、ＵＴＲＡおよびＩＥＥＥ８０２．１１など、複数のＲＡＴを介して通信することを可能にするための、複数の送受信機を含むことができる。

【0032】

ＷＴＲＵ１０２のプロセッサ１１８は、スピーカ／マイクロフォン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８（例えば、液晶表示（ＬＣＤ）ディスプレイユニットもしくは有機発光ダイオード（ＯＬＥＤ）ディスプレイユニット）に結合することができ、それらからユーザ入力データを受け取ることができる。プロセッサ１１８は、スピーカ／マイクロフォン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８にユーザデータを出力することもできる。加えて、プロセッサ１１８は、非リムーバブルメモリ１３０および／またはリムーバブルメモリ１３２など、任意のタイプの適切なメモリから情報を入手することができ、それらにデータを記憶することができる。非リムーバブルメモリ１３０は、ランダムアクセスメモリ（ＲＡＭ）、リードオンリメモリ（ＲＯＭ）、ハードディスク、または他の任意のタイプのメモリ記憶デバイスを含むことができる。リムーバブルメモリ１３２は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、およびセキュアデジタル（ＳＤ）メモリカードなどを含むことができる。他の実施形態においては、プロセッサ１１８は、サーバまたはホームコンピュータ（図示せず）上などに配置された、ＷＴＲＵ１０２上に物理的に配置されていないメモリから情報を入手することができ、それにデータを記憶することができる。

【0033】

プロセッサ１１８は、電源１３４から電力を受け取ることができ、ＷＴＲＵ１０２内の他の構成要素への電力の分配および／または制御を行うように構成することができる。電源１３４は、ＷＴＲＵ１０２に給電するための任意の適切なデバイスとすることができる。例えば、電源１３４は、１つまたは複数の乾電池（例えば、ニッケル－カドミウム（ＮｉＣｄ）、ニッケル－亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、およびリチウム－イオン（Ｌｉ－ｉｏｎ）など）、太陽電池、ならびに燃料電池などを含むことができる。

【0034】

プロセッサ１１８は、ＧＰＳチップセット１３６にも結合することができ、ＧＰＳチップセット１３６は、ＷＴＲＵ１０２の現在ロケーションに関するロケーション情報（例えば、経度および緯度）を提供するように構成することができる。ＧＰＳチップセット１３６からの情報に加えて、またはそれの代わりに、ＷＴＲＵ１０２は、基地局（例えば、基地局１１４ａ、１１４ｂ）からエアインターフェース１１６上でロケーション情報を受信することができ、および／または２つ以上の近くの基地局から受信した信号のタイミングに基づいて、自らのロケーションを決定することができる。ＷＴＲＵ１０２は、実施形態との整合性を保ちながら、任意の適切なロケーション決定方法を用いて、ロケーション情報を獲得することができることが理解されよう。

【0035】

プロセッサ１１８は、他の周辺機器１３８にさらに結合することができ、他の周辺機器１３８は、追加の特徴、機能性、および／または有線もしくは無線接続性を提供する、１つまたは複数のソフトウェアモジュールおよび／またはハードウェアモジュールを含むことができる。例えば、周辺機器１３８は、加速度計、ｅコンパス、衛星送受信機、（写真またはビデオ用の）デジタルカメラ、ユニバーサルシリアルバス（ＵＳＢ）ポート、バイブレーションデバイス、テレビ送受信機、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）ラジオユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、およびインターネットブラウザなどを含むことができる。

【0036】

図１Ｃは、実施形態による、ＲＡＮ１０４およびコアネットワーク１０６のシステム図である。上で言及されたように、ＲＡＮ１０４は、エアインターフェース１１６上でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するために、Ｅ－ＵＴＲＡ無線技術を利用することができる。ＲＡＮ１０４は、コアネットワーク１０６とも通信することができる。

【0037】

ＲＡＮ１０４は、ｅノードＢ１４０ａ、１４０ｂ、１４０ｃを含むことができるが、ＲＡＮ１０４は、実施形態との整合性を保ちながら、任意の数のｅノードＢを含むことができることが理解されよう。ｅノードＢ１４０ａ、１４０ｂ、１４０ｃは、各々が、エアインターフェース１１６上でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための１つまたは複数の送受信機を含むことができる。一実施形態では、ｅノードＢ１４０ａ、１４０ｂ、１４０ｃは、ＭＩＭＯ技術を実施することができる。したがって、ｅノードＢ１４０ａは、例えば、複数のアンテナを使用して、ＷＴＲＵ１０２ａに無線信号を送信し、ＷＴＲＵ１０２ａから無線信号を受信することができる。

【0038】

ｅノードＢ１４０ａ、１４０ｂ、１４０ｃの各々は、特定のセル（図示せず）に関連付けることができ、無線リソース管理決定、ハンドオーバ決定、ならびにアップリンクおよび／またはダウンリンクにおけるユーザのスケジューリングなどを処理するように構成することができる。図１Ｃに示されるように、ｅノードＢ１４０ａ、１４０ｂ、１４０ｃは、Ｘ２インターフェース上で互いに通信することができる。

【0039】

図１Ｃに示されるコアネットワーク１０６は、モビリティ管理エンティティゲートウェイ（ＭＭＥ）１４２、サービングゲートウェイ１４４、およびパケットデータネットワーク（ＰＤＮ）ゲートウェイ１４６を含むことができる。上記の要素の各々は、コアネットワーク１０６の部分として示されているが、これらの要素は、どの１つをとっても、コアネットワークオペレータとは異なるエンティティによって所有および／または運営することができることが理解されよう。

【0040】

ＭＭＥ１４２は、Ｓ１インターフェースを介して、ＲＡＮ１０４内のｅノードＢ１４０ａ、１４０ｂ、１４０ｃの各々に接続することができ、制御ノードとしての役割を果たすことができる。例えば、ＭＭＥ１４２は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのユーザの認証、ベアラアクティブ化／非アクティブ化、およびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃの初期接続中における特定のサービングゲートウェイの選択などを担うことができる。ＭＭＥ１４２は、ＲＡＮ１０４とＧＳＭまたはＷＣＤＭＡなどの他の無線技術を利用する他のＲＡＮ（図示せず）との間の交換のためのコントロールプレーン機能も提供することができる。

【0041】

サービングゲートウェイ１４４は、Ｓ１インターフェースを介して、ＲＡＮ１０４内のｅノードＢ１４０ａ、１４０ｂ、１４０ｃの各々に接続することができる。サービングゲートウェイ１４４は、一般に、ユーザデータパケットのＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃへの／からの経路選択および転送を行うことができる。サービングゲートウェイ１４４は、ｅノードＢ間ハンドオーバ中におけるユーザプレーンのアンカリング、ダウンリンクデータがＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに利用可能な場合に行うページングのトリガ、ならびにＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのコンテキストの管理および記憶など、他の機能も実行することができる。

【0042】

サービングゲートウェイ１４４は、ＰＤＮゲートウェイ１４６にも接続することができ、ＰＤＮゲートウェイ１４６は、インターネット１１０などのパケット交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスとの間の通信を容易にすることができる。

【0043】

コアネットワーク１０６は、他のネットワークとの通信を容易にすることができる。例えば、コアネットワーク１０６は、ＰＳＴＮ１０８などの回線交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと従来の陸線通信デバイスとの間の通信を容易にすることができる。例えば、コアネットワーク１０６は、コアネットワーク１０６とＰＳＴＮ１０８との間のインターフェースとしての役割を果たすＩＰゲートウェイ（例えば、ＩＰマルチメディアサブシステム（ＩＭＳ）サーバ）を含むことができ、またはＩＰゲートウェイと通信することができる。加えて、コアネットワーク１０６は、ネットワーク１１２へのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供することができ、ネットワーク１１２は、他のサービスプロバイダによって所有および／または運営される他の有線または無線ネットワークを含むことができる。

【0044】

ＬＴＥのためのキャリアアグリゲーションが、第３世代パートナシッププロジェクト（３ＧＰＰ）リリース１０において導入された。この機能は、ＷＴＲＵが、同時に２つ以上のキャリア上において送信および受信することを可能にして、エアインターフェース上におけるそれのピークデータレートの向上をもたらす。キャリアアグリゲーションの変更されていない形態においては、アグリゲートすることができるキャリアの最大数は、最大帯域幅が１００メガヘルツ（ＭＨｚ）の場合、５つである。

【0045】

ＬＴＥにおいては、ダウンリンクにおけるデータの送信は、物理ダウンリンク共用チャネル（ＰＤＳＣＨ）を使用して実行することができる。この物理チャネルは、（ＷＴＲＵにおける）受信機が、トランスポートブロックの連続する送信を組み合わせて、各再送において復号が成功する確率を高めることができる、ハイブリッド自動再送要求（ＨＡＲＱ）送信をサポートする。ＷＴＲＵは、トランスポートブロックの与えられた受信の試みについて、受信が成功したことを、肯定応答（ＡＣＫ）を用いて、または成功しなかったことを、否定応答（ＮＡＣＫ）を用いて報告することができる。いくつかのケースにおいては、ＷＴＲＵは、不連続送信（ＤＴＸ）などにおいて、トランスポートブロックが送信されたことを検出しなかったことも報告することができる。そのような報告は、本明細書においては、一括して「ＨＡＲＱ－ＡＣＫフィードバック」と呼ばれることがある。トランスポートブロックの特定の受信の試みについての結果（ＡＣＫ、もしくはＮＡＣＫ、またはあるソリューションにおいては、ＡＣＫ、ＮＡＣＫ、もしくはＤＴＸ）は、本明細書においては、「ＨＡＲＱ Ａ／Ｎ報告」と呼ばれることがある。

【0046】

キャリアアグリゲーションが構成される場合、ＰＤＳＣＨチャネル上においては、キャリア（またはサービングセル）およびサブフレーム当たり、最大２つのトランスポートブロックを受信することができる。周波数分割複信（ＦＤＤ）モードにおいては、ＷＴＲＵは、トランスポートブロック毎に別々に、１ビットのＨＡＲＱ－ＡＣＫフィードバックを報告することができ、トランスポートブロックの受信が成功した場合は、ＡＣＫが送信され、そうでない場合は、ＮＡＣＫが送信される。時分割複信（ＴＤＤ）モードにおいては、いくつかの構成では、ＷＴＲＵは、（例えば、空間的に多重化された）同じキャリアおよびサブフレーム内において受信されたトランスポートブロックの各ペアに対して、１ビットのＨＡＲＱ－ＡＣＫを報告することができ、または同じキャリア内およびサブフレームのセット内において受信されたトランスポートブロックのセットに対して、１ビットのＨＡＲＱ－ＡＣＫを報告することができ、ペアまたはセットに属するすべてのトランスポートブロックの受信が成功した場合は、ＡＣＫが送信され、そうでない場合は、ＮＡＣＫが送信される。ＷＴＲＵが、２つ以上のトランスポートブロックからなるセットに属するすべての受信が成功したという条件において、ＡＣＫを報告し、そうではない場合は、ＮＡＣＫを報告する、そのような方式は、「Ａ／Ｎバンドリング」と呼ばれることがある。Ａ／Ｎバンドリングは、空間多重化されたトランスポートブロックに対して実行することができ（空間バンドリング）、異なるサブフレーム内において受信されたトランスポートブロックに対して実行することができ（時間バンドリング）、または異なるキャリアもしくはセル内において受信されたトランスポートブロックに対して実行することができる（周波数バンドリング）。

【0047】

どちらのモードにおいても、トランスポートブロックの受信と、このトランスポートブロックの受信の成功または失敗に依存するＨＡＲＱ－ＡＣＫビットの送信との間には、固定されたタイミング関係が存在する。より具体的には、ＦＤＤモードにおいては、サブフレームｎ内において受信されたトランスポートブロックに対応するＨＡＲＱ－ＡＣＫビットは、サブフレームｎ＋４内において送信することができる。ＴＤＤモードにおいては、タイミング関係は、サブフレーム構成に依存することができ、およびトランスポートブロックが受信されたサブフレームのインデックスに依存することができる。

【0048】

サブフレーム内におけるＨＡＲＱ－ＡＣＫビットの送信は、物理アップリンク制御チャネル（ＰＵＣＣＨ）または物理アップリンク共用チャネル（ＰＵＳＣＨ）物理チャネル上において実行することができる。ＰＵＣＣＨは、サブフレーム内においてＰＵＳＣＨ送信が利用可能でない場合に、またはＷＴＲＵがＰＵＣＣＨおよびＰＵＳＣＨを同時に送信するように構成される場合に使用することができる。

【0049】

ＰＵＣＣＨは、サブフレームの各タイムスロット内において、単一の物理リソースブロック（ＰＲＢ）を占有することができ、可能なフォーマットからなるセットに属する１つに従って、送信することができる。単一のサブフレーム内のＰＵＣＣＨ上において、５つ以上のＨＡＲＱ－ＡＣＫビットを送信する必要がある場合、ＷＴＲＵは、ＰＵＣＣＨフォーマット３を使用するように構成される必要があることがある。ＰＵＣＣＨフォーマット３は、離散フーリエ変換－拡散－直交周波数分割多重（ＤＦＴ－Ｓ－ＯＦＤＭ）送信として説明することができ、４位相偏移変調（ＱＰＳＫ）によって変調された各シンボルは、単一のサブキャリアを占有し、直交カバーコードからなるセットに属する１つを使用して、時間領域内において拡散される。ＰＵＣＣＨフォーマット３においては、各ＱＰＳＫ変調シンボルは、４８の符号化ビットをサブフレーム内に収容することができるように、１つのタイムスロット上に拡散させることができる（２タイムスロット×１２サブキャリア×シンボル当たり２ビット）。それらの４８の符号化ビット内にエンコードされるように、（ＦＤＤモードにおいては）最大で１０のＨＡＲＱ－ＡＣＫビットを、または（ＴＤＤモードにおいては）２０のＨＡＲＱ－ＡＣＫビットを、最大で１つのスケジューリング要求（ＳＲ）ビットと多重化することができる。

【0050】

セル内においては、最大で４つのＷＴＲＵが、同じリソースブロック内において、相互に直交するＰＵＣＣＨフォーマット３を送信することができる。しかしながら、同じリソースブロックを使用するように構成することができるＷＴＲＵの最大数は、セル間干渉が著しいときは、より小さいことがある。

【0051】

サブフレーム内のＨＡＲＱ－ＡＣＫビットをＰＵＳＣＨ上において送信する必要があるとき、対応する変調シンボルは、サブフレーム内における復調基準信号（ＤＭ－ＲＳ）の送信のために使用される時間シンボルに隣接する４つの時間シンボルにおける一部（またはすべて）のサブキャリアを占有する、リソースエレメント上にマッピングすることができる。リソースの数は、ＰＵＳＣＨ割り当てのサイズ、およびＨＡＲＱ－ＡＣＫに利用可能なエネルギーの量が、誤り性能目標が満たされることを保証するのに十分であるように構成されたパラメータに基づいて決定することができる。

【0052】

キャリアアグリゲーション機能を強化するために、最大で３２のキャリアのアグリゲーションを可能にすることが提案された。レガシシステムと同じソリューションの再使用は、（ＦＤＤモードの場合は）最大で６４のＨＡＲＱ－ＡＣＫビット、または（ＴＤＤモードの場合は）１２８のＨＡＲＱ－ＡＣＫビットの送信を今度は必要とすることがあるので、この強化は、ＨＡＲＱ－ＡＣＫフィードバックを提供する観点からは、困難なことがある。これは、以下の懸念を生むことがある。第１に、ＰＵＣＣＨ送信において利用可能な符号化ビットの最大数（４８）は、レガシソリューションを使用して決定されるＨＡＲＱ－ＡＣＫ（およびＳＲ）情報ビットの数よりも低いことがある。第２に、ＰＵＳＣＨ内におけるＨＡＲＱ－ＡＣＫ（およびＳＲ）送信のために使用されるエネルギーの量は、許容可能な誤り性能を保証するのに不十分になることがある。

【0053】

１つまたは複数のセカンダリセル（ＳＣｅｌｌ）上においてＰＵＣＣＨを用いるようにＷＴＲＵを構成することができることも提案された。そのようなケースにおいては、ＷＴＲＵは、アップリンク制御情報（ＵＣＩ）のいくつかまたはすべてを、単一の送信を使用して送信すべきかどうかを決定し、そうすべき場合、プライマリセル（ＰＣｅｌｌ）（もしくはセカンダリセルグループ（ＳＧ）（ＳＣＧ）についての場合は、プライマリＳＣｅｌｌ（ＰＳＣｅｌｌ））上におけるＰＵＣＣＨ送信を使用すべきか、マスタセルグループ（ＭＣＧ）（利用可能であり、ＵＣＩがＭＣＧと関連付けられる場合）のセル上におけるＰＵＳＣＨ送信を使用すべきか、それともＳＣＧ（利用可能であり、ＵＣＩがＳＣＧと関連付けられる場合）のセル上におけるＰＵＳＣＨ送信を使用すべきかを決定する必要があることがある。

【0054】

本明細書においては、以下を含む、ＨＡＲＱ－ＡＣＫペイロードを減少させるための方法およびソリューションが開示される。ＨＡＲＱ Ａ／Ｎ報告の条件付き生成は、例えば、変調および符号化方式（ＭＣＳ）、ならびに／または報告されたチャネル品質インジケータ（ＣＱＩ）に関する条件など、１つまたは複数の条件を満たすことに基づくことができる。また、不必要な再送を最少化するために、バンドリングが適用されるトランスポートブロック（ＴＢ）のグループをサブフレームベースで選択する、選択的な部分バンドリングを使用することができる。さらに、肯定応答報告のダウン選択（ｄｏｗｎ－ｓｅｌｅｃｔｉｏｎ）を使用することができる。

【0055】

本明細書においては、以下を含む、ＰＵＣＣＨペイロードを増加させるための方法およびソリューションが開示される。例えば、本明細書においては、不均一誤り保護を実施するための、おそらくはサブキャリアのサブセット上における、より高次の変調の使用についての方法およびソリューションが開示される。また、本明細書においては、低いキュービックメトリック（ＣＭ）を維持しながら、レガシフォーマットとの多重化を可能にする、新しいＤＭ－ＲＳ設計を使用する、２つ以上のリソースブロック（ＲＢ）の使用についての方法およびソリューションが開示される。加えて、本明細書においては、各レイヤ上における情報ビットの数を動的に選択することができる、空間多重化の使用についての方法およびソリューションが開示される。さらに、変調シンボルは、変更されていない手法におけるよりも少ないリソースエレメント（ＲＥ）上に拡散させることができ、シンボルの数は、動的に選択することができる。

【0056】

本明細書においては、以下を含む、リソースの効率的な使用についての方法およびソリューションが開示される。コードブック特性は、例えば、ダウンリンク制御シグナリングに基づいて、動的に決定することができる。また、コードブック順列は、復号性能を最適化するように選択することができる。加えて、複数のフィードバックグループを、別々に、または合同で、送信および処理することができ、復号を容易にするために、フィードバックグループインジケータを使用することができる。さらに、リソース選択およびマッピング、ＰＵＣＣＨの電力設定機能、ならびに／またはＰＵＣＣＨ上におけるＵＣＩの動的スケジューリングを使用することができる。また、フィードバック圧縮ばかりでなく、動的コードブックも可能にするために、各ダウンリンク割り当てに対するインデックスおよび／またはカウンタの表示を使用することができる。

【0057】

本明細書においては、以下を含む、ＰＵＳＣＨ内におけるＵＣＩペイロードを増加させるための方法およびソリューションが開示される。ＰＵＳＣＨ内におけるＲＥの数／比率が閾値を超えたとき、変更されたトランスポートブロック処理を使用することができる。

【0058】

本明細書においては、複数のセル内での複数のタイプの送信のケースにおけるリソース選択についての方法およびソリューションが開示される。また、本明細書においては、サブフレーム内における複数の定期的なＣＳＩ報告の送信についての方法およびソリューションが開示される。

【0059】

本明細書においては、最終的な割り当ての決定のために肯定応答／否定応答（Ａ／Ｎ）リソースインジケータ（ＡＲＩ）を使用することができるコードブック決定、および複数のＣＳＩ報告の送信についての方法およびソリューションが開示される。

【0060】

以下のソリューションは、ＨＡＲＱ－ＡＣＫのために使用される情報ビットの数の削減を可能にすることによって、ＨＡＲＱ－ＡＣＫの送信のための限られたペイロード（または範囲）の問題に対処する。

【0061】

いくつかのソリューションにおいては、ＨＡＲＱ－ＡＣＫのために生成される情報ビットの数は、与えられたトランスポートブロックについてのＨＡＲＱ Ａ／Ｎ報告（またはビット）の生成を、少なくとも１つの条件が満たされたときだけに制限することによって、減少させることができる。少なくとも１つの条件は、ネットワークによるトランスポートブロックの不必要な再送が最少化されるように定義することができる。一般に、これは、少なくとも１つの条件が、Ａ／Ｎ報告は復号の成功の確率が著しいときだけ生成されるというようなものである場合に、達成することができる。

【0062】

レガシＬＴＥシステムにおいては、ＷＴＲＵは、一般に、それが、ＰＤＳＣＨ上において送信を受信したときに、および／またはそれが、構成されたアップリンクグラントまたは構成されたダウンリンク割り当てをアクティブ化もしくは非アクティブ化する、ダウンリンク制御情報（ＤＣＩ）を受信したときに、ＨＡＲＱ Ａ／Ｎ報告を生成することができる。

【0063】

１つの方法においては、ＷＴＲＵは、ＨＡＲＱ Ａ／Ｎ報告を生成するときに、さらなる決定を実行することができる。ＷＴＲＵは、以下のうちの少なくとも１つに従って、ＷＴＲＵの構成の特定のキャリアと関連付けられた（または特定のサービングセルと関連付けられた）送信についてのＨＡＲＱ Ａ／Ｎ報告を生成することができる。

【0064】

ＷＴＲＵは、以下のうちの少なくとも１つ、すなわち、ＤＣＩタイプ、ＤＣＩ内の表示、ＤＣＩの復号が成功するために使用される無線ネットワーク一時識別子（ＲＮＴＩ）、受信されたＤＣＩと関連付けられた探索空間（search space）、探索空間内におけるＤＣＩのロケーション、ＤＣＩのアグリゲーションレベル、他のＤＣＩ内容、またはそれらの組合せのうちの少なくとも１つによって特徴付けられるＤＣＩなど、ＤＣＩを受信することができる。

【0065】

ＤＣＩタイプの場合、ＷＴＲＵは、送信についてのＨＡＲＱ Ａ／Ｎ報告が予期されるかどうかを、送信と関連付けられたＤＣＩのタイプ（またはフォーマット）の関数として、決定することができる。例えば、ＷＴＲＵは、特定のタイプ（またはフォーマット）のＤＣＩを受信し、ＨＡＲＱ Ａ／Ｎ報告を生成しなくてよいと決定することができる。そのような関連付けは、ＤＣＩフォーマット自体に基づくことができる。例えば、ＤＣＩは、関連する送信についてのスケジューリング情報も伝えることができる。そのような関連付けは、例えば、関連するサブフレーム内における１つまたは複数の送信をスケジュールするＤＣＩと同じサブフレーム内で受信された特定のタイプ（またはフォーマット）のＤＣＩなど、タイミングに基づくことができる。そのようなタイプは、ダウンリンク制御シグナリングのＷＴＲＵ処理のサポートにおいて「ヒント」を提供するためにおそらくは使用することができる、ＤＣＩタイプを含むことができる。そのようなＤＣＩは、与えられたサブフレーム内において関連するキャリアに対して送信が適用可能でないことを示すことができる。あるいは、そのようなＤＣＩは、ＷＴＲＵが１つまたは複数のキャリアについてのＨＡＲＱ Ａ／Ｎフィードバックを生成することを予期されないことを示すことができる。おそらく、そのようなＤＣＩは、例えば、コードポイントを使用して、関連する間隔（例えば、サブフレーム）の間にそれについてのＨＡＲＱ Ａ／Ｎ報告が予期される特定のフォーマットおよび／またはキャリアの組合せを示すことができる。そのようなＤＣＩのさらなる例が、本明細書において説明される。レガシシステムと同様に、ＷＴＲＵは、構成されたグラントおよび／または構成されたダウンリンク割り当てをアクティブ化または非アクティブ化するＤＣＩについてのＨＡＲＱ Ａ／Ｎ報告を生成するように求められることがあり、一方、他のＤＣＩフォーマットは、ＨＡＲＱ Ａ／Ｎ報告を生成するかどうかを決定するために、追加のルールを必要とすることがある。

【0066】

ＤＣＩ内の表示の場合、ＷＴＲＵは、送信についてのＨＡＲＱ Ａ／Ｎ報告が予期されるかどうかを、送信と関連付けられたＤＣＩの内容の関数として、決定することができる。例えば、ＷＴＲＵは、例えば、ＰＤＳＣＨ送信をスケジュールするＤＣＩを受信することができる。そのようなＤＣＩは、表示を含むことができる。ＷＴＲＵは、そのような表示から、関連するＰＤＳＣＨ送信についてのＨＡＲＱ Ａ／Ｎ報告が予期されるかどうかを決定することができる。おそらく、そのようなＤＣＩは、例えば、コードポイントを使用して、関連する間隔（例えば、サブフレーム）の間にそれについてのＨＡＲＱ Ａ／Ｎ報告が予期される特定のフォーマットおよび／またはキャリアの組合せを示すことができる。表示は、ＤＣＩのペイロード内に含まれるフィールドの値からなること、または巡回冗長検査（ＣＲＣ）のビットのサブセットもしくはすべてをマスクするために使用されるフィールドの値からなることができる。フィールドは、例えば、ダウンリンク割り当てインデックス（ＤＡＩ）フィールドから、または専用フィールド（ＨＡＲＱ Ａ／Ｎ報告インジケータ）からなることができる。

【0067】

ＤＣＩの復号が成功するために使用されるＲＮＴＩの場合、ＷＴＲＵは、送信についてのＨＡＲＱ Ａ／Ｎ報告が予期されるかどうかを、送信と関連付けられたＤＣＩの復号が成功するために使用されるＲＮＴＩの関数として、決定することができる。例えば、ＷＴＲＵは、複数のＲＮＴＩを用いるように構成することができる。ＷＴＲＵは、与えられたＲＮＴＩを使用したときにＤＣＩの復号に成功したことが、関連付けられた送信についてのＨＡＲＱ Ａ／Ｎ報告が必要とされない（または反対に、ＨＡＲＱ Ａ／Ｎ報告が必要とされる）ことを示すことができるように構成することができる。

【0068】

受信されたＤＣＩと関連付けられた探索空間の場合、ＷＴＲＵは、送信についてのＨＡＲＱ Ａ／Ｎ報告が予期されるかどうかを、送信と関連付けられたＤＣＩの探索空間の関数として、決定することができる。例えば、ＷＴＲＵが、共通探索空間（ＣＳＳ）内で受信されたＤＣＩと関連付けられた送信についてのＨＡＲＱ Ａ／Ｎ報告を生成することは、予期することができるが、おそらく、ＷＴＲＵ固有の探索空間（またはＵＥ固有の探索空間（ＵＥＳＳ））内において受信されたＤＣＩについては、予期することができず、および／または後者のケースにおいては、ＷＴＲＵは、追加のルールを適用することができる。例えばＷＴＲＵは、複数のＵＥＳＳ（または類似のもの、例えばＵＥＳＳは分割することができる）を用いるように構成することができ、特定のＵＥＳＳ（またはそれの部分）内におけるＤＣＩの受信は、ＨＡＲＱ Ａ／Ｎ報告が予期されないことを示すことができ、一方、異なるＵＥＳＳ（またはそれの部分）の場合は、それを予期することができる。

【0069】

探索空間内におけるＤＣＩのロケーションの場合、ＷＴＲＵは、送信についてのＨＡＲＱ Ａ／Ｎ報告が予期されるかどうかを、送信と関連付けられたＤＣＩの制御チャネルエレメント（ＣＣＥ）の関数として、決定することができる。例えば、そのようなＣＣＥは、受信されたＤＣＩについての第１のＣＣＥとすることができる。例えば、ＣＣＥは、ＤＣＩの第１のＣＣＥがＳＳ内の特定の（例えば、偶数インデックスの）ＣＣＥと一致したときは、ＨＡＲＱ Ａ／Ｎ報告を予期することができるが、ＳＳ内の別の（例えば、奇数インデックスの）ＣＣＥについては、予期することができないと、ＷＴＲＵが決定することができるように、（例えば、ＳＳの第１のＣＣＥは＃０であり、第２のＣＣＥは＃２に対応するなど）数秘術的シーケンス（ｎｕｍｅｒｏｌｏｇｉｃａｌ ｓｅｑｕｅｎｃｅ）を使用して組織することができる。

【0070】

ＤＣＩのアグリゲーションレベル（例えば、１、２、４、または８のＣＣＥなど、ＣＣＥの数）の場合、ＷＴＲＵは、送信についてのＨＡＲＱ Ａ／Ｎ報告が予期されるかどうかを、送信と関連付けられたＤＣＩのアグリゲーションレベル（ＡＬ）の関数として、決定することができる。例えば、ＷＴＲＵが、４以上のＡＬと関連付けられた送信についてのＨＡＲＱ Ａ／Ｎ報告を生成することを予期することができ、一方、それ以外の場合、それを必要としないことができる。

【0071】

他のＤＣＩ内容の場合、例えば、（本明細書においてさらに説明されるように）スケジューリング情報および／または送信特性を使用することができる。１つの方法においては、ＷＴＲＵは、上述の方法のいずれかを使用して、復号が成功したＤＣＩが、本明細書において説明されるような、ＵＣＩ（またはＨＡＲＱフィードバックのみの）要求を含むかどうかを決定することができる。

【0072】

ＷＴＲＵは、送信が、以下のうちの少なくとも１つ、すなわち、関連付けられたＨＡＲＱプロセスの識別情報、冗長性バージョン、関連するＨＡＲＱプロセスについての初期送信もしくは再送、送信についてのスケジューリングのタイプ、送信と関連付けられたタイミング、スケジューリングパラメータ、同時ダウンリンク送信および／もしくはＵＣＩのアグリゲーションサイズ、またはそれらの組合せのうちの少なくとも１つに従って特徴付けられると決定することができる。

【0073】

関連付けられたＨＡＲＱプロセスの識別情報の場合、ＷＴＲＵは、送信についてのＨＡＲＱ Ａ／Ｎ報告が予期されるかどうかを、送信と関連付けられた（またはＤＣＩ内において示された）ＨＡＲＱプロセスの識別情報の関数として、決定することができる。例えば、ＷＴＲＵは、それが、ＨＡＲＱプロセスのサブセットについてのＨＡＲＱ Ａ／Ｎ報告を生成することは予期されないことができ、一方、それが、他のプロセスについてのＨＡＲＱ Ａ／Ｎ報告を生成することはできるように構成することができる。例えば、ＷＴＲＵは、半永久的な割り当てを用いるように構成されたプロセスについてのＨＡＲＱ Ａ／Ｎ報告は常に予期されると決定することができる。

【0074】

冗長性バージョン（例えば、０、２、３、１）の場合、ＷＴＲＵは、送信についてのＨＡＲＱ Ａ／Ｎ報告が予期されるかどうかを、送信と関連付けられた冗長性バージョン（ＲＶ）の関数として、決定することができる。例えば、ＷＴＲＵは、ＲＶ＝２、３、１については、ＨＡＲＱ Ａ／Ｎ報告を生成することができるが、ＲＶ＝０については、生成しないことができる。

【0075】

関連するＨＡＲＱプロセスについての初期送信または再送の場合、ＷＴＲＵは、送信についてのＨＡＲＱ Ａ／Ｎ報告が予期されるかどうかを、送信がＨＡＲＱプロセスについての初期送信であるかどうかの関数として、決定することができる。例えば、ＷＴＲＵは、ＨＡＲＱ再送についてだけ、それがＨＡＲＱ Ａ／Ｎ報告を生成することを予期されると決定することができる。

【0076】

送信についてのスケジューリングのタイプの場合、ＷＴＲＵは、送信についてのＨＡＲＱ Ａ／Ｎ報告が予期されるかどうかを、送信についての動的スケジューリング情報（例えば、送信パラメータを提供した物理ダウンリンク制御チャネル（ＰＤＣＣＨ）上のＤＣＩ）が受信されたかどうか、または送信が構成された割り当てを使用して受信されたかどうかの関数として、決定することができる。例えば、ＷＴＲＵは、動的にスケジュールされた送信については、ＨＡＲＱ Ａ／Ｎ報告を必要としないことができ（例えば半永久的な割り当てについては、それを常に必要とすることができ）ると決定することができ、おそらくは、本明細書において説明される他の方法と組み合わせて、さらなる決定を下す。

【0077】

送信と（または関連付けられたＵＣＩの送信と）関連付けられたタイミングの場合、ＷＴＲＵは、送信についてのＨＡＲＱ Ａ／Ｎ報告が予期されるかどうかを、ダウンリンク送信と関連付けられた送信時間間隔（ＴＴＩ）（またはサブフレームもしくはスロット）の関数として、決定することができる。例えば、ＷＴＲＵは、フレーム内の１つまたは複数のサブフレーム（例えば、偶数サブフレーム）については、それがＨＡＲＱ Ａ／Ｎ報告を生成することを必要としないことができるように構成することができる。

【0078】

おそらくは、チャネル品質などの別のメトリックに関連する、スケジューリングパラメータ（例えば、ＴＢのサイズおよびＭＣＳなど）の場合、ＷＴＲＵは、送信についてのＨＡＲＱ Ａ／Ｎ報告が予期されるかどうかを、送信と関連付けられたパラメータの関数として、決定することができる。例えば、ＷＴＲＵは、特定の値よりも大きいＴＢについては、ＨＡＲＱ Ａ／Ｎ報告を必要とし、それ以外については、それを必要としないことができると決定することができる。同様に、ＭＣＳを決定因子として使用することができる。例えば、ＷＴＲＵは、予期されるＢＬＥＲが閾値よりも高い場合、ＨＡＲＱ Ａ／Ｎ報告は任意選択とすることができると決定することができる。ＷＴＲＵは、最後に報告されたＣＳＩと、ＣＱＩの閾値関数よりも大きいＭＣＳ、およびランクインジケータ（ＲＩ）よりも大きい送信ランクなど、ダウンリンク送信の１つまたは複数の特性との組合せを使用することができる。

【0079】

同時ダウンリンク送信および／またはＵＣＩのアグリゲーションサイズの場合、ＷＴＲＵは、送信についてのＨＡＲＱ Ａ／Ｎ報告が予期されるかどうかを、ペイロードビットの数、すべてのトランスポートブロックについてのトータルサム、または送信が特定の条件を満たす、例えば、Ｘよりも大きいときの、時間間隔と関連付けられた他の任意のアグリゲートされたメトリックの関数として、決定することができる。ＷＴＲＵは、ＵＣＩのアグリゲートされたサイズの関数として、類似の決定を実行することができ、例えば、レガシ挙動に従って予期されるＨＡＲＱ Ａ／Ｎビットの合計は、ある値Ｘビットを超えることができる。

【0080】

説明された例の組合せを使用することができる。例えば、ＷＴＲＵは、それが、（おそらくは、少なくとも）本明細書において説明されるＤＣＩ（ＵＣＩ）の受信など、明示的なフィードバック要求の受信時には、１（または複数）の特定のＨＡＲＱプロセスについてのＨＡＲＱ Ａ／Ｎ報告が生成されるように構成され、それ以外のときは、ＷＴＲＵは、関連するプロセスについてのＨＡＲＱ Ａ／Ｎ報告を生成しないことができ、そのような挙動は、ＷＴＲＵが他の状況下においてＨＡＲＱ Ａ／Ｎ報告を生成することができるように、追加のルールと組み合わせることができると決定することができる。例えば、ＷＴＲＵは、関連するＨＡＲＱプロセスについてのｘ回目の再送から開始する、ＨＡＲＱ Ａ／Ｎ報告を生成することができ、および／またはＷＴＲＵが、本明細書において説明されるようなＵＣＩ報告のためのアップリンクリソースについての動的スケジューリングを受信したときに、ＨＡＲＱ Ａ／Ｎ報告を生成することができる。

【0081】

本明細書において説明される方法は、報告のために使用される物理チャネルの関数として適用可能であることができる。ＷＴＲＵは、それが上述の決定を実行することができるかどうかを決定することができ、またはＨＡＲＱ Ａ／Ｎ報告の生成のためのレガシ挙動を、ＵＣＩを伝えるために使用することができるかを、アップリンク送信のタイプの関数として決定することができる。例えば、ＷＴＲＵは、それが、１（または複数）のＰＵＳＣＨ送信を使用して、ＨＡＲＱ Ａ／Ｎ報告を送信することができると決定したときは、レガシ挙動を使用することができる。ＷＴＲＵは、それが、１（または複数）のＰＵＣＣＨ送信を使用して、ＨＡＲＱ Ａ／Ｎ報告を送信することができると決定したときは、いくつかのＨＡＲＱ Ａ／Ｎ報告は任意選択とすることができると決定することができる。ＷＴＲＵは、そのような決定を、関連するアップリンク送信のタイミングの関数として実行することができる。

【0082】

本明細書において説明される方法は、送信と関連付けられたキャリアの関数として適用可能であることができる。ＷＴＲＵは、それが上述の決定を実行することができるかどうかを決定することができ、またはＨＡＲＱ Ａ／Ｎ報告の生成のためのレガシ挙動を、ダウンリンク送信と関連付けることができるかを、キャリアのタイプの関数として決定することができる。例えば、ＷＴＲＵは、ライセンスバンドにおいては、キャリアのための第１の方法を使用することができ、一方、アンライセンスバンドにおいては、キャリアのための第２の方法を使用することができる。例えば、ＷＴＲＵは、それが、（本明細書において説明されるような）ＵＣＩ（またはＨＡＲＱフィードバックのみの）要求を含むＤＣＩの受信に成功したときに、（例えば、ＬＴＥライセンス補助アクセス（ＬＡＡ）のための）アンライセンスバンドと関連付けられたＨＡＲＱプロセスについての（および／またはＣＳＩについての）ＨＡＲＱ Ａ／Ｎ報告（またはより一般的に、ＵＣＩ報告）を生成することができる。どのケースにおいても、例えば、ＷＴＲＵは、関連するＨＡＲＱプロセスのステータスを報告することができ、そのようなステータスは、例えば、そのような要求の受信の時刻において決定すること（およびそれに対応すること）ができる。それ以外では、ＷＴＲＵは、関連するＵＣＩフィードバックを必ずしも生成しなくてもよい（例えば、他のルールを適用することができる）。例えば、ＷＴＲＵは、必ずしもすべての受信した送信についてＨＡＲＱ Ａ／Ｎ報告を生成しなくてもよい。

【0083】

本明細書において説明される例のいずれについても、そのような送信は、以下のうちの少なくとも一方、すなわち、ＰＤＳＣＨおよび特定のタイプのＤＣＩのうちの少なくとも一方とすることができる。送信は、ＰＤＳＣＨ送信とすることができる。送信は、サイドリンクとすることができる。送信は、直接的なＷＴＲＵ対ＷＴＲＵ送信、例えば、（例えば、データ用の）物理サイドリンク共用チャネル（ＰＳＳＣＨ）、（例えば、制御用の）物理サイドリンク制御チャネル（ＰＳＣＣＨ）、および／または（例えば、発見用の）物理サイドリンク発見チャネル（ＰＳＤＣＨ）とすることができる。

【0084】

送信は、半永久的なダウンリンク割り当てまたは半永久的なアップリンクグラントを変更する、ＤＣＩとすることができる。送信は、本明細書において説明されるような、例えば、ＵＣＩ要求および／または動的ＵＣＩスケジューリング情報を含む、例えば、ＤＣＩ（ＵＣＩ）とすることができる。ＤＣＩは、上述の方法のいずれかをそれに対して適用することができる、例えば、他の任意のＤＣＩとすることができる。

【0085】

本明細書において説明される例のいずれについても、そのような送信は、サービングセルと関連付けることができ、どのサービングセルかは、以下のうちの少なくとも１つ、すなわち、ＷＴＲＵの構成のサービングセルのタイプ、セル構成、セルのグループ、セルの状態、およびセルの品質のうちの少なくとも１つとすることができる。

【0086】

例においては、サービングセルは、ＷＴＲＵの構成のサービングセルのタイプとすることができる。例えば、セルは、条件付きのＨＡＲＱ Ａ／Ｎ報告が、そのようなセルについてのそのような送信に適用されるように、ＷＴＲＵの構成の（ＳＣｅｌｌなどの）セカンダリセルとすることができる。例えば、ＷＴＲＵは、キャリアアグリゲーションを用いるように構成されたＷＴＲＵのための、またはデュアル接続性を用いるように構成されたＷＴＲＵのための、ＷＴＲＵの構成の（ＰＣｅｌｌなどの）プライマリセルについてのいずれのそのような送信にも条件付きのＨＡＲＱ Ａ／Ｎ報告を適用しないことができる。例えば、ＷＴＲＵは、デュアル接続性を用いるように構成されたＷＴＲＵのための、（ＰＳＣｅｌｌなどの）セカンダリセルグループの特別なセルについてのいずれのそのような送信にも条件付きのＨＡＲＱ Ａ／Ｎ報告を適用しないことができる。

【0087】

別の例においては、サービングセルは、セル構成において構成することができる。例えば、セルは、条件付きのＨＡＲＱ Ａ／Ｎ報告が、そのようなセルのためのそのような送信に適用されるように、（無線リソース制御（ＲＲＣ）または媒体アクセス制御（ＭＡＣ）などによって）構成することができる。

【0088】

また例においては、サービングセルは、セルのグループの一部とすることができる。例えば、セルは、条件付きのＨＡＲＱ Ａ／Ｎ報告が、そのようなセルのためのそのような送信に適用されるように、「ＨＡＲＱ Ａ／Ｎグループ」など、セルの特定のグループの一部とすることができる。そのようなグループは、デュアル接続性を用いるように構成されたＷＴＲＵのための、セカンダリセルグループ（例えば、サービス継続ゲートウェイ（ＳＣＧ））に対応することができる。そのようなグループは、キャリアアグリゲーションを用いるように構成されたＷＴＲＵのための、セカンダリタイミングアドバンスグループ（例えば、セカンダリタイミングアドバンスグループ（ｓＴＡＧ））に対応することができる。

【0089】

さらなる例においては、サービングセルは、セルの状態と関連付けることができる。例えば、セルは、条件付きのＨＡＲＱ Ａ／Ｎ報告を適用するかどうかを制御する目的で、状態と関連付けることができる。ＷＴＲＵは、数々のイベント、例えば、Ｌ１シグナリングの受信、またはセルについての状態の変化を示すＬ２／ＭＡＣ制御シグナリングの受信に基づいて、そのような状態を変更することができる。例えば、セルは、条件付きのＨＡＲＱ Ａ／Ｎ報告が、セルと関連付けられたアップリンク制御シグナリングに適用されるように、非アクティブ化状態にあることができる。

【0090】

さらなる例においては、サービングセルの品質を使用することができる。例えば、セルの品質は、ＷＴＲＵ測定に基づくことができる。例えば、ＷＴＲＵは、セルの品質がある閾値を下回る（または上回る）と決定することができ、ＷＴＲＵが、品質が十分に、著しく、またおそらくは十分な長さの時間にわたっても、変化したと決定するまで、それが、セルのためのそのような送信に条件付きのＨＡＲＱ Ａ／Ｎ報告を適用することができるかどうかを決定することができる。ＷＴＲＵは、それが、それについての測定を、例えば、チャネル品質インジケータ（ＣＱＩ）を報告するセルについてだけ、そのような決定を実行することができる。ＷＴＲＵは、それが、関連するセルのためのそのような測定の送信を実行するときに、そのような決定を実行することができる。

【0091】

追加の制御情報は、ＵＣＩ報告を含むアップリンク送信内に配置することができる。１つの方法においては、ＷＴＲＵは、アップリンク送信内において、例えば、条件付きのＨＡＲＱ Ａ／Ｎがアップリンク制御シグナリングに適用されたかどうかを示す１ビットを送信することによって、ＨＡＲＱ Ａ／Ｎビットの非レガシ処理が適用されたかどうかを伝達することができ、またはそれは、ＣＲＣを追加することができる。例えば、ＷＴＲＵは、以下のうちの少なくとも１つ、すなわち、１ビットを連結することと（１ビットフラグ表示が送信に追加される）、ＣＲＣを連結することと（例えば、３ビットＣＲＣを送信に追加することができ、それによって、異なる方法を異なるＣＲＣ計算と関連付けることができる）、ＰＵＣＣＨの異なるリソース／特性を使用することとのうちの少なくとも１つを実行することができる。

【0092】

１つの方法においては、ＷＴＲＵは、上述のいずれかを使用して、そのような送信についてのＨＡＲＱ Ａ／Ｎ報告にプライオリティを関連付けることができる。ＷＴＲＵは、加えて、以下のうちの少なくとも１つ、すなわち、ＷＴＲＵが情報ビットをドロップすることができること、ＷＴＲＵが情報ビットの値を特定の値になるように設定することができること、ＷＴＲＵが情報ビットを他の情報ビットとバンドルすることができること、ＷＴＲＵがより少ない保護を用いて情報ビットをエンコードすることができること、およびＷＴＲＵが異なる物理レイヤチャネルを使用して情報ビットを送信することができることのうちの少なくとも１つに従って、ＨＡＲＱ Ａ／Ｎ報告と関連付けられた情報ビットを処理することができる。

【0093】

ＷＴＲＵが情報ビットをドロップすることができる場合、ＷＴＲＵは、プライオリティが低い送信のために、例えば、いずれかのＨＡＲＱ Ａ／Ｎを送信しないことができる。そのようなケースにおいては、ＷＴＲＵは、送信すべきＨＡＲＱ Ａ／Ｎビットの結果的な総数が選択されるフォーマットに適する場合、異なる（おそらくはより小さい）フォーマットを選択することができる。あるいは、ＷＴＲＵは、ｅノードＢが関連するＨＡＲＱ Ａ／Ｎビットの非存在をＮＡＣＫとして解釈することができるように、存在する場合は、ＨＡＲＱ Ａ／Ｎシグナリングのアップリンク送信を実行することができる。

【0094】

ＷＴＲＵが情報ビットの値を（ＮＡＣＫになど）特定の値になるように設定することができる場合、ＷＴＲＵは、ＨＡＲＱ ＮＡＣＫ送信のためにエネルギーが使用されないように、ＨＡＲＱ Ａ／Ｎビットのための符号化を使用することができ、ｅノードＢは、ＨＡＲＱ Ａ／Ｎの非存在をＮＡＣＫとして解釈することができる。

【0095】

ＷＴＲＵが情報ビットを（プライオリティが類似するなどの）他の情報ビットとバンドルすることができる場合、ＷＴＲＵは、ＨＡＲＱフィードバックがそれについて生成された送信と関連付けられたＳＣｅｌｌのアクティブ化状態に基づいて、例えば、複数のＨＡＲＱ Ａ／Ｎ情報ビットをバンドルすることができる。例えば、プライオリティが類似するキャリアについてのフィードバックは、一緒にバンドルすることができる。おそらくは、プライオリティが低いアップリンク制御情報と関連付けられたキャリアについてだけである。

【0096】

ＷＴＲＵがより少ない保護を用いて情報ビットをエンコードすることができる場合、例えば、ＷＴＲＵは、不均一誤り保護が情報ビットの送信に適用されるケースにおいて、そうすることができる。

【0097】

ＷＴＲＵが異なる物理レイヤチャネルを使用して情報ビットを送信することができる場合、ＷＴＲＵは、プライオリティがより高いビットの送信のために使用されたのとは異なる物理レイヤチャネルを使用して、情報ビットを送信することができる。

【0098】

上で説明されたソリューションは、ＷＴＲＵが特定のリソースまたはチャネル上でＨＡＲＱ Ａ／Ｎを送信するかどうかを決定するためにも使用することができる。例えば、ＷＴＲＵが、ＰＵＣＣＨ上または特定のＰＵＣＣＨリソース上における送信は、少なくとも１つのＨＡＲＱ Ａ／Ｎビットが、ソリューションの１つに基づいて送信される場合にのみ行われると決定することができるケースにおいてである。

【0099】

本明細書において説明されるいくつかの例においては、選択的な部分バンドリングを使用することができる。いくつかの例においては、ＨＡＲＱ－ＡＣＫのために生成される情報ビットの数は、不必要な再送の結果的な数を最小にするために、動的に選択することができる、トランスポートブロックのグループのサブセットに、バンドリングを適用することによって、減少させることができる。

【0100】

より一般的には、ＷＴＲＵは、ＨＡＲＱ－ＡＣＫ情報ビットを生成するための第１のソリューションをトランスポートブロックのグループの第１のサブセットに、また第２のソリューションをトランスポートブロックの第２のサブセットに適用することができ、トランスポートブロックの第１および第２のサブセットは、動的に変化することができる少なくとも１つの基準に基づいて選択される。例えば、基準は、ＷＴＲＵがそれについて肯定応答を示さない正しく受信されたトランスポートブロックの数が、ＨＡＲＱ－ＡＣＫ情報ビットの与えられた数に対して最小化されることとすることができる。ＷＴＲＵは、例えば、組合せインデックスを使用して、どのグループが第１のサブセットに属し、どのグループが第２のサブセットに属するかを示すために、追加のＨＡＲＱ－ＡＣＫ情報ビットを生成することができる。

【0101】

トランスポートブロックのグループ上においてＨＡＲＱ－ＡＣＫ情報ビットを生成するための例は、以下のうちの少なくとも１つ、すなわち、バンドリングなし、全体バンドリング、および部分バンドリングのうちの少なくとも１つを含むことができる。バンドリングなしの場合、トランスポートブロック毎に１つのビットを生成することができ、トランスポートブロックが正しく受信されたという条件において、第１の値（「ＡＣＫ」または１）が生成され、トランスポートブロックが正しく受信されなかった、またはまったく受信されなかったという条件において、第２の値（「ＮＡＣＫ」または０）が生成される。全体バンドリングの場合、すべてのトランスポートブロックに対して１つのビットを生成することができ、すべてのトランスポートブロックが正しく受信されたという条件において、第１の値（「ＡＣＫ」または１）が生成され、それ以外の場合、第２の値（「ＮＡＣＫ」または０）が生成される。部分バンドリングの場合、グループに属するトランスポートブロックからなる数々のサブセットの各々に対して１つのビットを生成することができ、トランスポートブロックのサブセット毎に、サブセットに属するすべてのトランスポートブロックが正しく受信されたという条件において、第１の値（「ＡＣＫ」または１）が生成され、それ以外の場合、第２の値（「ＮＡＣＫ」または０）が生成される。

【0102】

上述において、トランスポートブロックのサブセットおよび／またはグループは、例えば、あるサービングセル（もしくはそれのサブセット）、あるサブフレーム（もしくはそれのサブセット）、またはそれらの組合せから受信することができるトランスポートブロックとして定義することができる。グループは、より高位のレイヤによって明示的に構成することができ、または構成から暗黙的に導出することができる（例えば、グループサイズは、固定の値になるように設定することができ、グループは、構成の構成されたサービングセルの順序から定義することができる）。

【0103】

例えば、ＷＴＲＵは、ＦＤＤにおいては、３２のサービングセルを用いるように構成され、サブフレーム内において最大で６４のトランスポートブロックを受信することができる。１つは、８つのトランスポートブロックからなるグループを８つ定義することができ、それの各々は、４つのサービングセルからなるセットから受信することができるトランスポートブロックに対応することができる。８つのグループのうちの２つについては、「バンドリングなし」ソリューションに従って、ＨＡＲＱ－ＡＣＫ情報ビットを生成することができ、残りの６つのグループについては、「全体バンドリング」ソリューションに従って、ＨＡＲＱ－ＡＣＫ情報を生成することができ、すべてのグループについて、１６ビットプラス６ビットをもたらす。加えて、このサブフレーム内において「バンドリングなし」ソリューションが利用される２つを８つのグループから選ぶときに可能な２８の組合せについての組合せインデックスを表すために、５つの情報ビットを生成することができる。８つのグループのうちのどの２つにおいて「バンドリングなし」ソリューションが使用されるかを選択するために、ＷＴＲＵは、「全体バンドリング」が使用されたならば、受信に成功したのに「ＮＡＣＫ」が生成されるトランスポートブロックの数を、グループ毎に、決定することができる。ＷＴＲＵは、そのような受信に成功したトランスポートブロックの数が最多である２つのグループを選択することができる。例えば、サブフレーム内において、受信に成功したトランスポートブロックの数は、以下のようであると、すなわち、グループ１、４、８については８、グループ２については５、グループ３については４、グループ５、６については２、およびグループ７については０であるとすることができる。このケースにおいては、ＷＴＲＵは、「バンドリングなし」ソリューションのためにグループ２および３を選択することができ、他のすべてのグループは、「全体バンドリング」を使用する。

【0104】

与えられたバンドリングソリューションがそれに対して使用されるグループの選択は、以下の基準のうちの少なくとも１つに基づくことができる。グループの選択は、本明細書において説明されるように、サブフレーム内における、ＷＴＲＵがそれについて肯定応答を示さない正しく受信されたトランスポートブロックの数の最小化に基づくことができる。また、グループの選択は、グループ毎の、先行するサブフレームのセット内における、ＷＴＲＵがそれについて肯定応答を示すことができない正しく受信されたトランスポートブロックの存在または数に基づくことができる。加えて、グループの選択は、グループ内の受信に成功したトランスポートブロックについて「ＡＣＫ」が報告されなかった回数に基づくことができる。例えば、ＷＴＲＵは、それについてさもなければ「ＮＡＣＫ」を報告することができるグループ、この数についての最大値を有するグループ、またはこの数が閾値を上回ることができるグループに対して、「バンドリングなし」ソリューションを使用することができる。さらに、グループの選択は、あるグループに適用されるバンドリングソリューションについての、物理レイヤまたはより高位のシグナリングからの表示に基づくことができる。そのような表示は、グループのサービングセルについてのダウンリンク（ＤＬ）割り当てを含むＰＤＣＣＨ／進化型ＰＤＣＣＨ（Ｅ－ＰＤＣＣＨ）のフィールド内に、またはサブフレーム内におけるＤＬ割り当てについての情報を含むＰＤＣＣＨ／Ｅ－ＰＤＣＣＨ内に含むことができる。これは、ＷＴＲＵがグループの特定のサービングセルからＤＬ割り当てを受信したかどうかに関わらず、ネットワークが、ＷＴＲＵによるグループの選択をオーバライドすることを可能にすることができる。また、グループの選択は、グループのＰＤＳＣＨ送信の１つについての特性に基づくことができる。さらに、グループの選択は、グループのＰＤＳＣＨ送信をスケジュールするために使用されるＤＣＩフォーマットに基づくことができる。

【0105】

本明細書において開示される例においては、バンドリングソリューションが、サービングセルのグループにわたって使用されるとき、ＷＴＲＵは、グループの別のサービングセルについてのＤＬ割り当てを含むＰＤＣＣＨ／Ｅ－ＰＤＣＣＨ内の表示から、ＤＬ割り当てがサービングセル内において失われたかどうかを決定することができる。そのような表示は、このサブフレーム内のグループにおいて送信されたＤＬ割り当ての数を含むことができる。ＷＴＲＵは、サブフレーム内のグループについての正しく受信されたＤＬ割り当ての総数が、示された数よりも低い場合に、ＤＬ割り当てが失われたと決定し、したがって、グループについて「ｎａｃｋ」を報告することができる。

【0106】

いくつかの例においては、送達確認されたセルまたはＴＢのインデックスの表示を使用することができる。さらに、いくつかの例においては、ＷＴＲＵは、ＰＵＣＣＨ Ａ／Ｎ（ＡＣＫ／ＮＡＣＫ）リソースだけを使用して、ＡＣＫを報告するように、より高位のレイヤによって、構成することができる。そのような例においては、ＷＴＲＵによるフィードバックの欠落は、ｅノードＢにおいてＮＡＣＫを表すことを暗示することができる。ＴＢおよびＨＡＲＱプロセスは、交換可能に使用することができる。

【0107】

（おそらくは、複数のセルからの）複数のトランスポートブロックＨＡＲＱ Ａ／Ｎビットの報告を可能にするＰＵＣＣＨフォーマットにおいては、可能なＴＢ ＨＡＲＱ Ａ／Ｎ報告毎に、ビットストリング内に事前決定されたロケーションが存在することができる。ＷＴＲＵは、それについてさもなければＮＡＣＫを送信することができる、ＴＢ ＨＡＲＱ Ａ／Ｎを表す任意のビットを空白にしておく（または事前構成された値になるように設定する）ことができる。

【0108】

別の例においては、ＴＢ ＨＡＲＱ Ａ／Ｎ報告のセットを配置することができる、事前構成されたロケーションが、ビットストリング内に存在することができる。ビットロケーションのそのようなセットは、複数のＴＢについてのＡＣＫのサブセットを報告するために使用することができる。例えば、ＰＵＣＣＨ内において報告されるＨＡＲＱ Ａ／Ｎビットストリングは、各々がｘビットからなるセットから構成することができる。ｘビットからなる各セットは、ｎのＴＢについてのＨＡＲＱ Ａ／Ｎを報告するために使用することができる。この例においては、ＷＴＲＵは、ビットのセットのすべての可能な２^xのコードポイントが意味を有するように（おそらくは半静的に）事前構成することができ、各コードポイントは、ｅノードＢにおいて、それについてのＡＣＫを仮定することができるＴＢの異なるサブセットを識別することができる。簡単な数値的な例として、ＰＵＣＣＨ内において報告されるビットストリングは、各々が２ビットの５つのセットから構成することができる。２ビットの各セットは、３つのＴＢのいずれかについてＡＣＫを報告するために使用することができる。例えば、コードポイント「００」は、３つのＴＢのいずれについてもＡＣＫを示さないことができ、「０１」は、第１のＴＢについてのＡＣＫを示すことができ、「１０」は、第２のＴＢについてのＡＣＫを示すことができ、「１１」は、第３のＴＢについてのＡＣＫを示すことができる。各コードポイントの意味は、ｅノードＢによって半静的に設定することができ、送達確認されたＴＢのグループも示すことができる（例えば、コードポイントは、第１および第２のＴＢがＡＣＫであることを示すことができる）。

【0109】

別の例においては、ＴＢ ＨＡＲＱ Ａ／Ｎ報告毎に、ビットストリング内に事前決定されたロケーションが存在しなくてもよい。そのような例においては、ＡＣＫを示していないＴＢ ＨＡＲＱ Ａ／Ｎ報告のための場所をビットストリング内に確保する必要をなくすことができる。ＮＡＣＫ ＴＢのＴＢ ＨＡＲＱ Ａ／Ｎ報告のために、容量を無駄にしないことができることを考えると、これは、平均してより多数の可能なＴＢ ＨＡＲＱ Ａ／Ｎ報告を可能にすることができる。

【0110】

ＨＡＲＱ Ａ／Ｎ報告のビットストリング内において、事前決定（および／または事前構成）されたロケーションが、ＴＢ ＨＡＲＱ Ａ／Ｎ毎に使用されないケースにおいては、ＷＴＲＵは、ＡＣＫがそれについて送信されるＴＢを、ｅノードＢに示すことができる。ＴＢ毎の一意識別子（おそらくは、ビットストリング）を、すべての可能なセルから、ＷＴＲＵに提供することができる。ＷＴＲＵは、ＰＵＣＣＨ内において、識別子をＡＣＫとして報告し返すことができる。例えば、ＷＴＲＵが、サブフレーム内で送信される最大で６４のＴＢを有するケースの場合、６ビットで構成されるＴＢ毎の識別子を、ＷＴＲＵに提供することができる。そのようなケースにおいては、ＨＡＲＱ Ａ／Ｎ報告は、単に、ＷＴＲＵが、ＡＣＫがそれについて送信されるいずれかのＴＢの６ビットストリングを含めることとすることができる。１つの例においては、ＴＢ識別子は、ＷＴＲＵがトランスポートブロックを用いるようにスケジュールされたときに提供することができる。別の例においては、ＷＴＲＵは、ＴＢを送信するセルの（セル識別情報（ＩＤ）などの）識別子およびＨＡＲＱプロセスＩＤの関数として、ＴＢ識別子を決定することができる。

【0111】

本明細書において提示されるいくつかの例においては、ＷＴＲＵは、ＰＵＣＣＨリソース内において送信する複数のＡＣＫを有することができる。各ＴＢ ＨＡＲＱ Ａ／Ｎが、ＨＡＲＱ Ａ／Ｎビットストリング内の特定のビットロケーションを用いるように構成されないソリューションの場合、ＰＵＣＣＨ容量が許容するよりも多くのＡＣＫをＰＵＣＣＨインスタンス内において送信することが必要とされる状況が存在することがある。そのような状況においては、ＷＴＲＵは、いずれかのＰＵＣＣＨインスタンス内においてＡＣＫがそれについてフィードバックされるべきＴＢをダウン選択することができる。ＡＣＫがそれについて送信されないいずれのＴＢも、ｅノードＢにおいて、ＮＡＣＫであると仮定されることができ、おそらくは、誤ってそうされる。

【0112】

ＷＴＲＵは、ＰＵＣＣＨフィードバックがすべてのＡＣＫを含んでおらず、ＷＴＲＵによってダウン選択が使用されたことを、ｅノードＢに示すことができる。別の例においては、ＷＴＲＵは、そのＴＢについてのＡＣＫが、直近に送信されたＰＤＳＣＨに関するものか、それとも先行するバージョンに関するものかを、ｅノードＢに通知する表示を、いずれのＡＣＫ送信とも一緒に含むことができる。例えば、ＷＴＲＵは、現実には第１の再送後にそれが送達確認されたとき、第２の再送後にしかＡＣＫを送信することができないことがある。ＡＣＫが先行する再送について生じたのかどうかをＷＴＲＵに示すことは、および／またはおそらくは、どの再送についてＡＣＫが生じたのかを示すことも、ｅノードＢがリンク適応を用いることを可能にすることができる。

【0113】

送信すべきＡＣＫのダウン選択は、いくつかの事前構成されたルールに従って、ＷＴＲＵによって自律的に行うことができる。ＷＴＲＵは、プライオリティリストおよび半静的に構成されたルールのセットのうちの少なくとも一方によって、送信すべきＡＣＫのサブセットを決定することができる。

【0114】

プライオリティリストは、ｅノードＢによって事前構成することができ、ＴＢおよび／またはＴＢを送信するＳＣｅｌｌの関数として決定することができる。ＷＴＲＵは、送達確認されたＴＢをランク付け、いずれの場合もＰＵＣＣＨがｎのＡＣＫを送信するための容量を有すると仮定して、第１のＴＢについてのＡＣＫフィードバックを送信することができる。プライオリティランキングは、ＰＤＳＣＨの内容の関数として、ＷＴＲＵによって決定することができる。例えば、（ＲＲＣ再構成メッセージなど）コントロールプレーン送信のために使用されるＰＤＳＣＨは、ユーザプレーン送信のために使用されるＰＤＳＣＨのそれよりも高いＡＣＫ報告プライオリティを有することができる。プライオリティランキングは、ＰＤＳＣＨのために使用されるスケジューリングのタイプに依存することができる。例えば、クロスキャリアスケジュールされるＰＤＳＣＨは、セルフスケジュールされるＰＤＳＣＨよりも高い／低いプライオリティを有することができる。または、半永久的にスケジュールされるＰＤＳＣＨは、単独でスケジュールされるＰＤＳＣＨよりも高い／低いプライオリティを有することができる。

【0115】

半静的に構成されたルールのセットは、ＷＴＲＵが、最大でいずれか１つのインスタンス内において許容されるＡＣＫ容量まで、ＰＵＣＣＨインスタンス内において、それについてのＡＣＫが送信されるＴＢを決定することを可能にすることができる。例えば、最大数の再送を有することができた送達確認されたプロセスについてＡＣＫを報告する。例えば、ＷＴＲＵは、ＨＡＲＱプロセス当たりの再送の数に関して、ＴＢ ＡＣＫ報告プライオリティを順序付け、最大数の再送を有するｎのプロセスについてＡＣＫをフィードバックすることができる。例えば、ＡＣＫ報告が先にスキップされた送達確認されたプロセスについてＡＣＫを報告する。これらは、おそらくは、（最多のスキップが最高のランキングをもたらすなど）プロセスの間にＡＣＫ報告が何回スキップされたかによって順序付けることができる。例えば、最高／最低のデータレート、および／または最高／最低のＭＣＳ、および／または最高／最低のＰＲＢの数、および／または最高／最低のＲＩを有する送達確認されたＴＢについてＡＣＫを報告する。例えば、空間多重化を用いて／用いずに送信された送達確認されたＴＢについてＡＣＫを報告する。上述のルールは、任意の組合せで使用することができ、ルールに従うことができる順序は、事前構成することができる。例えば、第１のルールは、ＡＣＫが先にスキップされた送達確認されたプロセスについてＡＣＫを報告することとすることができる。ｎよりも少ないプロセスしか適格でない場合、ＰＵＣＣＨフィードバックは、さらに、（最大数の再送を有するプロセスなど）別のルールを満たすプロセスについてのＡＣＫで満たすことができる。

【0116】

プライオリティリストおよび／またはルールのセットは、半静的に構成することができ、ならびにＰＤＳＣＨおよび／またはＰＵＣＣＨのタイミングにも依存することができる。サブフレームの第１のサブセットにおいては、第１のルールのセットが、ＡＣＫフィードバックをダウン選択するために使用され、サブフレームの第２のサブセットにおいては、第２のルールのセットが、ＡＣＫフィードバックをダウン選択するために使用されるような、サブフレームのサブセットが存在することができる。

【0117】

与えられたサブフレームまたはサブフレームのグループにおいて、ＷＴＲＵは、ＨＡＲＱ－ＡＣＫ情報の生成のための方法を、以下のうちの少なくとも１つ、すなわち、ＨＡＲＱ－ＡＣＫが事前決定された順序で連結されたＨＡＲＱ Ａ／Ｎ報告を含むことができる、バンドリングなし、（空間、周波数、および／または時間領域などにおける）トランスポートブロックの決定されたサブセットについてのＨＡＲＱ Ａ／Ｎ報告の固定されたバンドリング、本明細書において説明されるような条件付きＨＡＲＱ Ａ／Ｎ報告生成、本明細書において説明されるような選択的な部分バンドリング、ならびに本明細書において説明されるようなＡＣＫ送信のダウン選択のうちの少なくとも１つに従って、決定することができる。

【0118】

特定のサブフレームにおいて適用されるＨＡＲＱ－ＡＣＫの生成のための方法およびおそらくはそれのパラメータの選択は、以下のうちの少なくとも１つ、すなわち、ＨＡＲＱ－ＡＣＫ情報ビットのペイロード、ＰＵＣＣＨフォーマットによって収容される最大ペイロード、ＰＵＳＣＨ送信によって収容される最大ペイロード、および物理レイヤ、ＭＡＣ、またはＲＲＣシグナリングからの表示のうちの少なくとも１つに従って、決定することができる。

【0119】

特定のサブフレームにおいて適用される方法を決定するために、ＨＡＲＱ－ＡＣＫ情報ビットのペイロードを使用することができる。ペイロードは、（受信したＤＬ割り当てに基づいた）ＨＡＲＱ－ＡＣＫ送信が関係する受信したトランスポートブロックの数について、または（受信したＤＬ割り当ての最大可能数および割り当て毎のトランスポートブロックの最大数などに基づいた）ＨＡＲＱ－ＡＣＫ送信が関係する受信することができるトランスポートブロックの最大数について決定することができる。

【0120】

特定のサブフレーム内において適用される方法を決定するために、ＰＵＳＣＨ送信がサブフレーム内において生じないという条件において、このサブフレーム内において使用されるように構成された、ＰＵＣＣＨフォーマットによって収容することができる最大ペイロードを使用することができる。例えば、ＷＴＲＵは、最大よりも少ない数のＨＡＲＱ－ＡＣＫ情報を生成する方法を選択することができる。

【0121】

ＨＡＲＱ－ＡＣＫ情報を送信するために必要とされるＲＥの数が閾値を超えないように、特定のサブフレーム内において適用される方法を決定するために、このサブフレーム内におけるＰＵＳＣＨ送信によって収容することができる最大ペイロードを使用することができる。

【0122】

特定のサブフレーム内において適用される方法を決定するために、物理レイヤ、ＭＡＣ、またはＲＲＣシグナリングからの表示を使用することができる。例えば、ダウンリンク割り当て、アップリンクグラントを含む、またはダウンリンク割り当ておよびアップリンクグラントのセットについての情報を含む、ＰＤＣＣＨ／Ｅ－ＰＤＣＣＨに属するフィールドを使用して、ＨＡＲＱ－ＡＣＫ情報をどのように生成することができるか、または生成することができるＨＡＲＱ－ＡＣＫビットの最大数を示すことができる。

【0123】

以下のソリューションは、ＨＡＲＱ－ＡＣＫ、チャネル状態情報（ＣＳＩ）、およびＳＲのうちの少なくとも１つを含む、ＰＵＣＣＨ内のＵＣＩに対して、最大ペイロードが不十分である問題に対処する。例においては、ＰＵＣＣＨ内における利用可能な符号化ビットの数を増やすことができる。

【0124】

いくつかのソリューションにおいては、高い変調次数のシンボルを使用することによって、例えば、１６直交振幅変調（ＱＡＭ）、６４ＱＡＭ、および２５６ＱＡＭなど、ＱＰＳＫのそれよりも高い変調次数を使用することによって、ＰＵＣＣＨペイロードを増やすことができる。

【0125】

例として、単一の１６ＱＡＭシンボルにおいて搬送される符号化ビットの数は、４ビットであり、それは、（ＰＵＣＣＨフォーマット３など）単一のレガシＰＵＣＣＨ ＱＰＳＫシンボルにおいて搬送されるそれらと比較して、２倍多い。レガシＰＵＣＣＨフォーマット３のペイロードは、４８ビットにエンコードすることができ、その後、２４のＱＰＳＫシンボルにマッピングすることができる。例として、２４シンボルなど、同数のシンボルに対して、ＱＰＳＫの代わりに、１６ＱＡＭシンボルを使用することができる場合、ＰＵＣＣＨは、４×２４＝９６の符号化ビットを搬送することができ、それは、比較すると、ＱＰＳＫ変調を使用するレガシＰＵＣＣＨフォーマット３の最大エンコードビットの２倍の多さとすることができる。

【0126】

ＷＴＲＵは、異なるＰＵＣＣＨ ＲＥにマッピングすることができる異なるシンボルに対して、異なる変調次数を使用することができる。

【0127】

ＷＴＲＵは、異なるサブキャリアにマッピングすることができる異なるシンボルに対して、異なる変調次数を使用することができる。例えば、ＰＵＣＣＨ ＲＢ当たり１２のサブキャリアのうち、ｎ＝４など、ｎのサブキャリアは、ＱＰＳＫ変調されたシンボルを搬送することができ、（１２－ｎ）の、すなわち、８つのサブキャリアは、１６ＱＡＭ変調されたシンボルを搬送することができる。２つのＰＲＢを有するＰＵＣＣＨについての符号化ビットの総数は、（同じＰＲＢ内のすべてのＳＣ－ＦＤＭＡシンボルは、同じ情報を搬送することができると仮定して）以下のように計算することができる。
２×［ｎ×２＋（１２－ｎ）×４］＝９６－２×ｎ 式（１）
同じＰＵＣＣＨ ＰＲＢ内の同じサブキャリアにマッピングされるすべてのシンボルは、同じ変調次数、例えば、ＱＰＳＫおよび１６ＱＡＭなどを使用して、変調することができる。

【0128】

ＷＴＲＵは、異なるエンコーダを使用することができ、および／またはエンコードビットの異なるセットを生成することができる。エンコードビットの異なるセットは、ＰＵＣＣＨシンボルの異なるセットにマッピングすることができ、ＰＵＣＣＨシンボルの各セットは、異なる変調技法、例えば、ＱＰＳＫおよび１６ＱＡＭなどを使用して、変調することができる。例として、単一のＰＵＣＣＨ ＰＲＢ内において搬送される情報ビットをエンコードするために、２つのエンコーダを使用することができ、それらは、「エンコーダＡ」および「エンコーダＢ」と呼ばれることがある。各エンコーダは、エンコーダ入力として、情報ビットの異なるセットを有することができる。エンコーダＡの出力は、ある変調技法、例えば、ＱＰＳＫを使用して変調することができ、４つのサブキャリアなど、ある数のＰＵＣＣＨサブキャリアにマッピングすることができる。エンコーダＢの出力は、異なる変調技法、例えば、１６ＱＡＭを使用して変調することができ、１２－８＝４のサブキャリアなど、ＰＵＣＣＨサブキャリアの異なるセットにマッピングすることができる。２つのＰＲＢを有するＰＵＣＣＨについての符号化ビットの総数は、（同じＰＲＢ内のすべてのＳＣ－ＦＤＭＡシンボルは、同じ情報を搬送することができると仮定して）先に説明された公式によれば、８８と計算することができる。

【0129】

エンコードビットを異なる変調次数／技法にマッピングすることができる、各ＰＵＣＣＨエンコーダは、チャネル／復号障害に対する異なる保護レベルおよび／またはロバストネスを有することができる。例えば、最終的に１６ＱＡＭシンボルにマッピングすることができるエンコードビットは、ＱＰＳＫシンボルにマッピングされるエンコードビットと比較して、チャネル／復号障害に対するより小さいロバストネスを有することができる。

【0130】

ＷＴＲＵは、２つ以上の異なる性能要件に対する可能性を有する、情報ビットの２つ以上の異なるセットを有することができる。情報ビットの２つ以上の異なるセットは、２つ以上のエンコーダを使用してエンコードすることができ、ならびに／またはエンコードビットは、２つ以上の変調技法、例えば、ＱＰＳＫおよび１６ＱＡＭなどによって、変調することができる。変調シンボルの２つ以上のセットは、サブキャリアおよび／またはＲＥの２つ以上のセットにマッピングすることができる。

【0131】

例として、ＷＴＲＵは、ＨＡＲＱ ＡＣＫ／ＮＡＣＫバンドリングを使用して、いくつかのコンポーネントキャリアのＨＡＲＱ ＡＣＫ／ＮＡＣＫビットをバンドルすることができ、および／またはＷＴＲＵは、他のいくつかのコンポーネントキャリアのＨＡＲＱ ＡＣＫ／ＮＡＣＫをバンドルしないことができる。バンドルされたＨＡＲＱ ＡＣＫ／ＮＡＣＫビットの受信における誤りは、バンドルされていないＨＡＲＱ ＡＣＫ／ＮＡＣＫビットにおける誤りのそれと比較して、より多くのコンポーネントキャリアの動作に影響することができるので、ＷＴＲＵは、バンドルされたＨＡＲＱ ＡＣＫ／ＮＡＣＫビットを、最終的にＱＰＳＫシンボルへのマッピングを行うことができるエンコーダに割り当てることができ、一方、ＷＴＲＵは、バンドルされていないＨＡＲＱ ＡＣＫ／ＮＡＣＫビットを、最終的に１６ＱＡＭシンボルへのマッピングを行うことができるエンコーダに割り当てることができる。結果として、バンドルされたＨＡＲＱ ＡＣＫ／ＮＡＣＫビットは、バンドルされていないＨＡＲＱ ＡＣＫ／ＮＡＣＫビットと比較して、チャネル／復号障害に対するより高い保護を有することができる。

【0132】

ＷＴＲＵは、サブフレーム内において送信される必要がある符号化ビットの数に基づいて、変調方式を決定することができる。例えば、ＰＵＣＣＨフォーマット３と同じ拡散方式およびＲＢの数（すなわち、サブキャリア当たり２つのシンボル、および１つのＲＢ）が使用されると仮定すると、ＷＴＲＵは、必要とされる符号化ビットの数が４８ビットである場合は、ＱＰＳＫを使用して、必要とされる符号化ビットの数が９２ビットである場合は、１６ＱＡＭを使用して、送信することができる。

【0133】

いくつかのソリューションにおいては、単一のＰＵＣＣＨリソースに２つ以上のリソースブロックを割り当てることによって、ＰＵＣＣＨペイロードを増やすことができる。そのようなソリューションは、本明細書において説明されるときは、「拡張ＰＵＣＣＨ」と呼ばれることがある。

【0134】

図２は、２つの連続するＲＢを利用する拡張ＰＵＣＣＨ設計のための可能なＲＥマッピングの例の図である。マッピング２００に示されるように、時間次元および周波数次元は、それぞれ、水平軸および垂直軸によって表される。マッピング２００の例においては、ＲＢ＃１ ２１０およびＲＢ＃２ ２２０は、連続しており、同じタイムスロット内で送信される。この設計は、アップリンク送信のシングルキャリア特性を保存する利益を有することができる。アップリンク制御情報を搬送するために利用可能なＲＥの数は、単一のＲＢを利用するレガシ送信フォーマットと比較して、基本的に２倍とすることができる。

【0135】

ＰＵＣＣＨが２つのＲＢを利用するいくつかのソリューションにおいては、復調ＤＭ－ＲＳ２３０は、ＰＵＣＣＨフォーマット３など、レガシ送信フォーマットにおけるのと同じ時間シンボルにおいて送信することができる。情報２４０および情報２５０も、送信することができる。これも、図２において示されている。

【0136】

本明細書において説明されるように、ＤＭ－ＲＳのシーケンスを決定するための異なるソリューションも想定することができる。

【0137】

第１のソリューションにおいては、拡張ＰＵＣＣＨのためのＤＭ－ＲＳシーケンスは、レガシシステムにおいて２つのＲＢのＰＵＳＣＨ割り当てのＤＭ－ＲＳシーケンスのために使用される、長さ２４の基本シーケンスＦ_u,v（＜＜）から生成することができる。そのような基本シーケンスは、ＰＵＣＣＨのために使用される長さ１２の基本シーケンスとは異なることができる。シーケンス自体は、基本シーケンスの巡回シフトとして定義することができる。

【0138】

【数1】

【0139】

このソリューションの利益は、ＤＭ－ＲＳシーケンスが、低いピーク対平均電力比を有すること、およびそれが、同じ基本シーケンスの異なる巡回シフトの使用によって、ＲＢの同じペアを使用する他の拡張ＰＵＣＣＨリソースの多重化を可能にすることとすることができる。

【0140】

第２のソリューションにおいては、拡張ＰＵＣＣＨのためのＤＭ－ＲＳシーケンスは、長さ１２の２つの連結された基本シーケンスから生成することができる。言い換えると、拡張ＰＵＣＣＨのために使用されるＤＭ－ＲＳシーケンス

【0141】

【数2】

【0142】

は、

【0143】

【数3】

【0144】

【数4】

【0145】

と表現することができ、ここで、Ｋは、ＤＭ－ＲＳシーケンスのピーク対平均比が低い値に保たれるように構成された、グループシーケンス番号ｕ１およびｕ２におそらくは依存する、単位振幅の定数とすることができる。グループシーケンス番号ｕ１およびｕ２は、同じ値ｕになるように設定することができる。このケースにおいては、このソリューションにおける拡張ＤＭ－ＲＳシーケンスは、異なる巡回シフトα_iおよびα₂を用いて、ならびに第２のシーケンスについては位相オフセットβ、Ｋ≡ｅ^jβを用いて、同じ基本シーケンスから生成された、長さ１２の２つの連結されたＤＭ－ＲＳシーケンス、例えば、

【0146】

【数5】

【0147】

および

【0148】

【数6】

【0149】

と等価とすることができる。

【0150】

このソリューションの例示的な利益は、第１のＲＢ（または第２のＲＢ）上におけるＰＵＣＣＨフォーマット３の巡回シフトが、それぞれ、α₁（またはα₂）と異なる限り、また情報を搬送するリソースについて直交性も保証されるならば、それが、同じＲＢ上において、拡張ＰＵＣＣＨリソースのＰＵＣＣＨフォーマット３リソースとの多重化を可能にすることとすることができる。ＲＢの同じペア上における他の拡張ＰＵＣＣＨリソースとの多重化も、巡回シフトの適切な選択を用いて可能にすることができる。巡回シフトα₁およびα₂の可能な組合せと、位相オフセットβとのセットは、ＤＭ－ＲＳシーケンスの望ましい特性（例えば、低いピーク対平均電力比）が維持されるように制限することができる。例えば、ｐｉ／４の位相オフセットの利用は、位相オフセットを使用しないよりも低いピーク対平均電力比をもたらすことができる。

【0151】

すべての上述のソリューションにおいて、ＤＭ－ＲＳのために使用される巡回シフト、および位相オフセットβの値は、ＤＭ－ＲＳがその中で送信される時間シンボルの関数とすることができる。

【0152】

拡張ＰＵＣＣＨによって搬送される情報に対する処理は、変調後にＰＵＣＣＨフォーマット３に対して使用される処理と同様とすることができる。各変調シンボルは、１つのサブキャリアおよび１つのタイムスロット上に拡散させることができ、ＱＰＳＫが使用される場合は、合計で４８の変調シンボルまたは９６の符号化ビットをもたらす。この手法は、ＤＭ－ＲＳの直交性も達成されるならば、同じＲＢ上における、拡張ＰＵＣＣＨのＰＵＣＣＨフォーマット３との多重化を可能にする利益を有することができる。

【0153】

ＷＴＲＵは、サブフレーム内において送信される必要がある符号化ビットの数に基づいて、ＲＢの数を決定することができる。例えば、ＰＵＣＣＨフォーマット３と同じ拡散および変調方式（すなわち、サブキャリア当たり２つのシンボル、およびＱＰＳＫ）が使用されると仮定すると、ＷＴＲＵは、必要とされる符号化ビットの数が９６ビットである場合は、２つのＲＢ上において、必要とされる符号化ビットの数が１４４ビットである場合は、３つのＲＢ上において送信することができる。ＰＵＣＣＨのために使用されるＲＢの数が、２つ以上であるとき、ＷＴＲＵは、以下のソリューションのうちの１つを使用する変換プリコーディングを適用することができる。

【0154】

ソリューションにおいては、ＷＴＲＵは、すべての送信されるサブキャリアのセット上において離散フーリエ変換（ＤＦＴ）を適用することができる。ＷＴＲＵが、（例えば、以下のパラグラフにおいて説明されるソリューションのうちの１つに従って）ＰＵＣＣＨ送信のために定義されたＲＢの１つの上で送信しない場合、対応するサブキャリアにＤＦＴを適用しないことができる。このソリューションは、出力信号が、ＳＣ－ＦＤＭＡの望ましい特性（例えば、低いキュービックメトリック）を可能な限り維持することを保証することができる。

【0155】

別のソリューションにおいては、ＷＴＲＵは、各ＲＢ上において別々にＤＦＴを適用することができる。このソリューションは、ＷＴＲＵが各ＲＢ上で送信するかどうかについての不確実性が存在するケースにおいて、受信機の複雑さを低減することができる。

【0156】

いくつかのソリューションにおいては、空間多重化によって、ＰＵＣＣＨペイロードを増やすことができる。そのようなソリューションは、本明細書において「ランクｎのＰＵＣＣＨ」と呼ばれることがあり、ここで、ｎは、レイヤの数である。情報の送信のために利用可能なＲＥの数が同じである場合に、そのようなソリューションを用いると、変調シンボル（および符号化ビット）の数を、ｎ倍に増やすことができる。ＷＴＲＵは、レイヤに対応するアンテナポート毎に、異なるＤＭ－ＲＳシーケンスを送信することができる。

【0157】

いくつかのソリューションにおいては、アンテナポート毎に送信される各ＤＭ－ＲＳシーケンスは、長さ１２の同じ基本シーケンス

【0158】

【数7】

【0159】

から生成することができる。時間シンボル内において使用されるＤＭ－ＲＳシーケンス

【0160】

【数8】

【0161】

は、アンテナポートｐ毎に異なる巡回シフトａを使用することができる。この手法は、同じリソースブロック内におけるレガシＰＵＣＣＨフォーマット３送信との多重化を達成可能とすることができるという利益を有することができる。

【0162】

空間多重化が使用されるとき、ｅノードＢ受信機によって見られるようなチャネル品質は、２つのアンテナポート間において異なることができる。いくつかのソリューションにおいては、ＷＴＲＵは、したがって、アップリンク制御情報の少なくとも１つのタイプの誤り性能目標が、可能な限り低い送信電力に対して満たされることを保証するために、２つの送信レイヤ間において、異なる符号化レート、符号化方式、および／または変調方式を利用することができる。例えば、ランク２のＰＵＣＣＨ（ｎ＝２）のケースにおいては、以下のソリューションのうちの少なくとも１つ、すなわち、ｋ１の情報ビットが第１のアンテナポート上においてエンコード、変調、およびマッピングされ、ｋ２の情報ビットが第２のアンテナポート上においてエンコード、変調、およびマッピングされる、与えられたタイプのｋの情報ビットの処理と、第１のアンテナポート上における第１のタイプの、および第２のアンテナポート上における第２のタイプの情報ビットのエンコード、変調、およびマッピングと、各アンテナポート上において使用するための変調次数（例えば、ＱＰＳＫまたは１６ＱＡＭ）の決定と、各アンテナポート上において利用可能な符号化ビットの数の決定と、各アンテナポート上において使用するための符号化方式（例えば、ブロックコード、畳み込みコード、ターボ）の決定とのうちの少なくとも１つを適用することができる。

【0163】

例えば、ＷＴＲＵは、ランク２のＰＵＣＣＨ上において（ＨＡＲＱ－ＡＣＫなど）与えられた情報タイプのｋ＝３０ビットを送信しなければならないことがある。ＷＴＲＵは、ｋ１＝２０ビットおよびｋ２＝１０ビットが、それぞれ、第１のアンテナポートおよび第２のアンテナポート上においてエンコード、変調、およびマッピングされると決定することができる。ＷＴＲＵは、アンテナポート毎に４８の符号化ビットが利用可能であると決定されるように、各アンテナポート上においてＱＰＳＫが使用されると決定することもできる。ＷＴＲＵは、その後、第１のアンテナポート上にマッピングされる２０の情報ビットを、２０／４８の符号化レートを使用して、また第２のアンテナポート上にマッピングされる１０の情報ビットを、１０／４８の符号化レートを使用して、エンコードすることができる。

【0164】

ＷＴＲＵは、以下のソリューションのうちの少なくとも１つを使用して、上述のパラメータのうちの少なくとも１つを決定することができる。ＷＴＲＵは、より高位のレイヤのシグナリングから受け取った表示を使用することができる。ＷＴＲＵは、ＰＤＣＣＨまたはＥ－ＰＤＣＣＨ上において受信されたＤＣＩの少なくとも１つのフィールドから受け取った表示を使用することができる。例えば、ＤＣＩは、ＰＵＣＣＨ送信においてＨＡＲＱ－ＡＣＫがそれについて送信されるべきトランスポートブロックを示す、ダウンリンク割り当ての１つを含むＤＣＩとすることができる。表示は、以下のうちの少なくとも１つ、すなわち、各レイヤ上においてエンコードおよびマッピングされる情報ビットの数または比の表示（例えば、２ビットフィールドは、比が、第１のアンテナポート上においては１／３、１／２、２／３、または３／４であり、第２のアンテナポート上においては残りであることを示すことができる（ここで、ビットの数は、切り上げまたは切り下げを行うことができる））と、上述のものを含むようにオーバロードされたＡ／Ｎリソースインジケータ（ＡＲＩ）フィールド（ＡＲＩフィールドは、ＳＣｅｌｌのためのダウンリンク制御情報内において受け取られた送信機電力制御（ＴＰＣ）フィールドと等価とすることができ、またはそれと同じリソースを再使用することができる）と、各アンテナポートに対してＱＰＳＫを使用することができるか、それとも１６ＱＡＭを使用することができるかについての表示と、例えば、信号対干渉比（ＳＩＮＲ）の比もしくはｄＢの差に関して、または各アンテナポート上における情報ビット当たりの送信エネルギー間における必要とされる差に関して表現される、２つのアンテナポート間におけるチャネル品質不均衡についての表示とのうちの１つまたは複数を含むことができる。ＷＴＲＵは、より高位のレイヤのシグナリングと組み合わせて、ＡＲＩフィールドを使用して示すことができる、ＮランクＰＵＣＣＨと関連付けられた少なくとも１つのリソースインデックスを使用することができる。アンテナポート毎の情報ビットの数および変調は、より高位のレイヤによって構成されるリソースの一部として構成することができる。

【0165】

例においては、プリコーディングを使用することができる。いくつかの例においては、アップリンク用の２つ以上のアンテナポートを備えたＷＴＲＵは、ＰＵＳＣＨに適用されるプリコーディングに類似したプリコーディングを利用することができる。これは、同じ周波数および時間リソース上における複数のＷＴＲＵのＰＵＣＣＨ送信の空間多重化を可能にすることができる。ＰＵＣＣＨ送信に適用可能なプリコーディング行列は、サブフレーム内においてそれについてのフィードバックが提供されているＰＤＳＣＨ割り当てを含む、少なくとも１つのＰＤＣＣＨ／Ｅ－ＰＤＣＣＨなどにおけるダウンリンク制御シグナリングを用いて提供することができる。

【0166】

いくつかの例においては、より小さい拡散係数を有するＤＦＴ－Ｓ－ＯＦＤＭを使用することができる。いくつかのソリューションにおいては、ＤＦＴ－Ｓ－ＯＦＤＭ構造内のより少数のリソースエレメント上に変調シンボルを拡散させることによって、ＰＵＣＣＨペイロードを増やすことができる。例えば、３つの時間シンボル上に拡散される４８の変調シンボルをＰＵＣＣＨ上にマッピングすることができ、その場合、ＤＭ－ＲＳのために使用される時間シンボルの数は、２に減らされる。

【0167】

いくつかのソリューションにおいては、ＤＭ－ＲＳのために使用される時間シンボルは、レガシＰＵＣＣＨフォーマット３におけるのと同じ時間シンボル内に維持されて、同じＲＢ内におけるこのフォーマットのレガシＰＵＣＣＨ送信との多重化の可能性を維持することができる。そのようなフレームワークにおいては、サブキャリア上における変調シンボルから時間シンボルへの拡散について、限定することなく、各々が単一の時間シンボル上にある、１０の変調シンボル（例えば、拡散なし）、各々が２つの時間シンボル上に拡散される、５つの変調シンボル、３つの時間シンボル上に拡散させることができる２つと、２つの時間シンボル上に拡散させることができる２つの、４つの変調シンボル、および３つの時間シンボル上に拡散させることができる２つと、４つの時間シンボル上に拡散させることができる１つの、３つの変調シンボルなど、いくつかの可能性を想定することができる。

【0168】

最後の時間シンボルが利用可能ではない、短縮化されたＰＵＣＣＨ送信のケースにおいては、変調シンボルがその上に拡散される時間シンボルの数は、変調シンボル１つにつき１だけ減らすことができる。影響を受ける変調シンボルは、好ましくは、短縮化されていないＰＵＣＣＨ送信において、より多数の時間シンボル上に拡散されるものである。

【0169】

サブキャリア内における変調シンボルから時間シンボルへの正確なマッピング（したがって、拡散係数）をパラメータ化して、このパラメータ値に依存する、ＰＵＣＣＨについての最大ペイロード値をサポートすることができる。パラメータは、ＰＵＣＣＨリソースインデックスから導出することができ、ＰＵＣＣＨリソースインデックスとともに構成することができる。

【0170】

別々の符号化が、ＵＣＩビットの異なるサブセットに適用される場合、ＰＵＣＣＨ内のより多数の時間シンボル上に拡散される変調シンボル（例えば、２つの代わりに３つの時間シンボル上に拡散される、サブキャリア当たり２つの変調シンボル）を使用して、より高いロバストネスを必要とするＵＣＩのための符号化ビットを搬送することができる。

【0171】

ＷＴＲＵは、サブフレーム内において送信する必要がある符号化ビットの数に基づいて、拡散方式を決定することができる。例えば、ＷＴＲＵは、必要とされる符号化ビットの数が１２０ビットである場合は、サブキャリア当たり５つの変調シンボルを、また必要とされる符号化ビットの数が７２ビットである場合は、サブキャリア当たり３つの変調シンボルを拡散させることができる。

【0172】

例においては、コードブック、リソースおよび送信フォーマット、ならびにパラメータの選択を使用することができる。ＷＴＲＵは、特定のサブフレーム内において使用するための、ＰＵＣＣＨ送信フォーマット、およびおそらくは関連するパラメータを決定することができる。ＰＵＣＣＨ送信フォーマットは、符号化ビットの総数、および符号化ビットのセット（または適用可能な場合は、符号化ビットの各サブセット）をどのように変調し、拡散し、物理リソースにマッピングすることができるか（おそらくは、空間多重化を含む）によって特徴付けることができる。

【0173】

ＰＵＣＣＨ送信フォーマットは、１、１ａ、１ｂ、２、および３などのレガシＰＵＣＣＨフォーマット、ならびに上で説明された技法（より高次の変調、より大きいＢＷ、空間多重化、または縮小された拡散）の１つまたは組合せに基づいたフォーマットなど、より高いペイロードをサポートする新しいＰＵＣＣＨフォーマットのうちの少なくとも一方を含むことができる。

【0174】

フォーマットおよび関連するパラメータの選択は、以下のうちの少なくとも１つに基づくことができる。選択は、ＰＵＣＣＨ上において送信される（複数のタイプのＨＡＲＱ－ＡＣＫ、ＣＳＩ、ＳＲを含む）異なるタイプのＵＣＩのための情報ビットの数に基づくことができる。例えば、選択は、ＰＵＣＣＨ上において送信される異なるタイプのＵＣＩの存在または非存在に基づくことができる。また、選択は、ＤＬ割り当てまたはＤＬ割り当てについての情報を含むＰＤＣＣＨ／Ｅ－ＰＤＣＣＨなど、物理レイヤまたはより高位のレイヤのシグナリングから受け取られる表示に基づくことができる。例えば、表示は、サブキャリア当たりのマッピングされる変調シンボルの数（もしくは拡散係数もしくは拡散係数のセット）を示すパラメータ、（ＱＰＳＫもしくは１６ＱＡＭなど）変調タイプを示すパラメータ、および／またはＰＵＣＣＨ送信のためのレイヤの数（ランク）を示すパラメータを含むことができる。さらに、選択は、ＰＵＣＣＨ内において送信されるＨＡＲＱ－ＡＣＫ情報ビットを生成するために使用される方法に基づくことができる。加えて、選択は、本明細書において説明されるような、少なくとも１つのコードブック特性についての物理レイヤまたはより高位のレイヤのシグナリングから受け取られる表示に基づくことができる。選択は、本明細書において説明されるような、サブフレーム内において送信されるフィードバックグループのサブセットにも基づくことができる。さらに、選択は、例えば、本明細書において説明されるそれに類似するＤＣＩ（ＵＣＩ）を使用する、本明細書において説明されるような、ＵＣＩスケジューリング情報に関連する方法を含む、本明細書において説明されるような、ＵＣＩフィードバックのためのアップリンクリソースの動的スケジューリングに基づくことができる。

【0175】

いくつかのソリューションにおいては、ＷＴＲＵは、必要とされる符号化ビットの数に基づいて、（変調、ＲＢの数、拡散、空間多重化のうちの少なくとも１つを含む）送信フォーマットのすべての特性を決定することができ、符号化ビットの数、情報ビットの数、および／またはフィードバックグループのサブセットからなる事前決定されたセットに基づいて、マッピングを決定することができる。例えば、ＷＴＲＵは、表１に類似した表に基づいて、送信フォーマットを決定することができる。

【0176】

【表1】

【0177】

この例においては、ＷＴＲＵは、以下のパラグラフにおいて説明されるように、例えば、情報ビットの総数および最大符号化レートに基づいて、符号化ビットの数を決定することができる。例えば、ＷＴＲＵが、必要とされる符号化ビットの数は１４４であると決定した場合、ＷＴＲＵは、符号化ビットに対してＱＰＳＫ変調を利用し、３つのシンボルが各サブキャリア上に拡散されるように、変調されたシンボルを拡散し、結果の信号を２つのＲＢ上にマッピングすることができる。

【0178】

いくつかのソリューションにおいては、ＷＴＲＵは、ＰＤＣＣＨ／Ｅ－ＰＤＣＣＨからＡＲＩまたは別のフィールドを受け取るなど、動的な表示に基づいて、送信フォーマットのいくつかの特性を選択することができる。例えば、受け取ったＡＲＩによって示されるリソースは、１つのＲＢを有することができる。必要とされる符号化ビットの数が９６ビットである場合、ＷＴＲＵは、拡散は、サブキャリア当たり４つの変調シンボルが拡散され、ＲＢ内において９６の符号化ビットを可能にするようなものであるべきであると決定することができる。受け取ったＡＲＩによって示されるリソースが、２つのＲＢを有するケースにおいては、ＷＴＲＵは、拡散は、サブキャリア当たり２つの変調シンボルが拡散され、２つのＲＢ内において９６の符号化ビットを可能にするようなものであるべきであると決定することができる。そのような動的な態様のさらなる例が、本明細書において説明される。

【0179】

例においては、コードブック特性の動的決定を使用することができる。いくつかのソリューションにおいては、ＷＴＲＵは、半静的および／または動的な態様に基づいて、ＨＡＲＱフィードバックおよびおそらくは他のＵＣＩ（例えば、コードブック）のための情報ビットのセットの少なくとも１つの特性を決定することができる。ソリューションは、そのような情報の送信のために使用されるリソースの量の最小化を可能にすることができる。そのような動的な態様のさらなる例が、本明細書において説明される。

【0180】

拡張によって、以下で説明されるソリューションは、（コードブックサイズなど）コードブック特性と関連付けることができる、ＰＵＣＣＨフォーマット、ＰＵＣＣＨリソース、または電力制御方法を決定するためにも使用することができる。例えば、ＷＴＲＵは、コードブックサイズが第１の値よりも小さい場合は、第１のＰＵＣＣＨフォーマット（および／または電力制御方法）が使用され、コードブックサイズが第１の値以上であるが、第２の値よりも小さい場合は、第２のＰＵＣＣＨフォーマットが使用され、以降も同様であると決定することができる。

【0181】

以下のコードブック特性のうちの少なくとも１つを決定することができる。コードブックの情報ビットの数を決定することができる。例えば、どのセルまたはセルグループのどのトランスポートブロックがコードブックの与えられた位置にマッピングされるかに関する、コードブックの情報ビットの順序を決定することができる。ビットが、特定のセル、セルグループ、および／もしくはサブフレーム上において受信されたトランスポートブロックの復号のＡＣＫもしくはＮＡＣＫ結果を表すかどうか、ならびに／またはバンドリングがその上で適用される、もしくはされないセルもしくはセルグループもしくはサブフレームの表示を表すかどうかなど、各情報ビット（またはそれのセット）の解釈を決定することができる。適用することができる情報源符号化方式（例えば、ハフマンエンコード）を決定することができる。コードブックに適用することができるチャネル符号化方式（例えば、リード－マラー、ターボ、または畳み込み）を決定することができる。

【0182】

図３は、フィードバックのサイズおよびタイプに基づいた、ＰＵＣＣＨフォーマットについての例示的な選択プロセスの図である。プロセス３００に示される例においては、ＷＴＲＵは、複数の構成されたキャリアのセット上において複数のトランスポートブロックを受信し、複数のトランスポートブロックについてのＨＡＲＱ－ＡＣＫフィードバック３１０およびＣＳＩフィードバック３２０を生成することができる。さらに、ｎによって表すことができる、ＨＡＲＱ－ＡＣＫフィードバック３１０のために必要とされる情報ビットの数、およびｍによって表すことができる、ＣＳＩフィードバック３２０のために必要とされる情報ビットの数は、３３０において、ＷＴＲＵによって組み合わせる（例えば、連結する）ことができる。ＷＴＲＵは、ＨＡＲＱ－ＡＣＫフィードバックのために使用するＨＡＲＱ－ＡＣＫフィードバックビットの数と、ＣＳＩフィードバックのために使用するＣＳＩフィードバックビットの数とを含む、フィードバックメッセージを生成することができる。ＷＴＲＵは、その後、３４０において、フィードバックの内容に基づいて、可能なＰＵＣＣＨフォーマットを決定することができる。例えば、このＰＵＣＣＨフォーマット決定は、ＨＡＲＱ－ＡＣＫフィードバックビットの数およびＣＳＩフィードバックビットの数に基づいて行うことができる。ＷＴＲＵは、決定されたＰＵＣＣＨフォーマットを使用して、フィードバックメッセージを送信することができる。

【0183】

例えば、ＨＡＲＱ－ＡＣＫフィードバックが存在し、したがって、ｎ＞０である場合、およびＣＳＩフィードバックが存在し、したがって、ｍ＞０である場合、３５０において、ＰＵＣＣＨフォーマットｘなどの第１のＰＵＣＣＨフォーマット、またはＰＵＣＣＨフォーマットｙなどの第２のＰＵＣＣＨフォーマットを選択することができる。また、ＨＡＲＱ－ＡＣＫフィードバックが存在せず、したがって、ｎ＝０であり、ＣＳＩフィードバックだけが存在し、したがって、ｍ＞０である場合、３６０において、ＰＵＣＣＨフォーマットｘ、またはＰＵＣＣＨフォーマットｚなどの第３のＰＵＣＣＨフォーマットを選択することができる。さらに、ＨＡＲＱ－ＡＣＫフィードバックが存在し、したがって、ｎ＞０である場合、およびＣＳＩフィードバックが存在せず、したがって、ｍ＝０である場合、３７０において、ＰＵＣＣＨフォーマットｘ、またはＰＵＣＣＨフォーマットｗなどの第４のＰＵＣＣＨフォーマットを選択することができる。

【0184】

３５０において、ＰＵＣＣＨフォーマットｘまたはＰＵＣＣＨフォーマットｙが選択されたケースにおいては、ＷＴＲＵは、その後、３５５において、フィードバックペイロードの情報ビットの数をＢ１などの第１の閾値と比較することができる。フィードバックペイロードが第１の閾値よりも大きく、したがって、ｎ＋ｍ＞Ｂ１である場合、３５６において、ＰＵＣＣＨフォーマットｘを選択することができる。さらに、フィードバックペイロードが第１の閾値以下であり、したがって、ｎ＋ｍ≦Ｂ１である場合、３５８において、ＰＵＣＣＨフォーマットｙを選択することができる。ＷＴＲＵは、決定されたＰＵＣＣＨフォーマットを使用して、フィードバックメッセージを送信することができる。

【0185】

３６０において、ＰＵＣＣＨフォーマットｘまたはＰＵＣＣＨフォーマットｚが選択されたケースにおいては、ＷＴＲＵは、その後、３６５において、フィードバックペイロードの情報ビットの数をＢ２などの第２の閾値と比較することができる。フィードバックペイロードが第２の閾値よりも大きく、したがって、ｍ＞Ｂ２である場合、３６６において、ＰＵＣＣＨフォーマットｘを選択することができる。さらに、フィードバックペイロードが第２の閾値以下であり、したがって、ｍ≦Ｂ２である場合、３６９において、ＰＵＣＣＨフォーマットｚを選択することができる。ＷＴＲＵは、決定されたＰＵＣＣＨフォーマットを使用して、フィードバックメッセージを送信することができる。

【0186】

３７０において、ＰＵＣＣＨフォーマットｘまたはＰＵＣＣＨフォーマットｗが選択されたケースにおいては、ＷＴＲＵは、その後、３７５において、フィードバックペイロードの情報ビットの数をＢ３などの第３の閾値と比較することができる。フィードバックペイロードが第３の閾値よりも大きく、したがって、ｎ＞Ｂ３である場合、３７６において、ＰＵＣＣＨフォーマットｘを選択することができる。さらに、フィードバックペイロードが第３の閾値以下であり、したがって、ｎ≦Ｂ３である場合、３７７において、ＰＵＣＣＨフォーマットｗを選択することができる。ＷＴＲＵは、決定されたＰＵＣＣＨフォーマットを使用して、フィードバックメッセージを送信することができる。

【0187】

コードブック特性は、少なくとも、構成されたキャリア（またはセル）の数、サブフレーム構成、セルグループ内におけるセルのグループ化、与えられたセル内において受信することができるトランスポートブロックの数、与えられたセル内において使用される送信モード、および（サブフレームもしくはセル内におけるバンドリング、もしくはサブフレームもしくはセルにわたるバンドリングが適用されるかどうか、または先に説明されたようなＨＡＲＱフィードバックソリューションが適用されるかどうかなど）セルまたはセルのグループ内において利用されるように構成されたＨＡＲＱフィードバック方式などの、半静的（または静的）な情報に依存することができる。

【0188】

ＷＴＲＵは、セルまたはセルグループのアクティブ化状態、セルグループについて無線リンク問題もしくは無線リンク障害が発生したかどうか、またはセルグループについてそれらが報告されたかどうか、セルもしくはセルグループについてＰＤＳＣＨがネットワークから送信されなかったことが知られているかどうか、またはあるいは、ネットワークから送信されたことが知られているかどうか、セル内における動的サブフレーム構成（アップリンク（ＵＬ）またはＤＬ）、およびサブフレーム内において受信されるＤＬ制御情報など、よりダイナミックに変化することができる情報の関数として、コードブック特性を決定することもできる。

【0189】

例えば、ＷＴＲＵは、コードブックが、アクティブ化された状態にある、またはそれについての無線リンク障害が報告されなかった、セルまたはセルのグループについてのＨＡＲＱフィードバックだけを含むと決定することができる。ＷＴＲＵは、コードブックが、ＰＤＳＣＨを送信することができたとＷＴＲＵがそれから決定する、セル、セルのグループ、またはサブフレームについてのＨＡＲＱフィードバックだけを含むと決定することもできる。このケースにおいては、ＷＴＲＵは、コードブックサイズおよびビット位置をしかるべく決定することができる。例えば、構成されたセルが１０、セル当たりのトランスポートブロックが２つのケースにおいては、ＷＴＲＵが、ＰＤＳＣＨはセル２、３、６だけから送信することができたと決定する場合、６ビットのコードブックサイズに対して、最初の２ビットは、セル２についてのＨＡＲＱフィードバックに対応することができ、次の２ビットは、セル３についてのＨＡＲＱフィードバックに対応することができ、以降も同様である。

【0190】

ＷＴＲＵは、以下のソリューションのうちの１つを使用することによって、ＰＤＳＣＨを送信することができたと決定することができる。ＷＴＲＵは、ＰＤＳＣＨをその中で送信することができるセル、セルグループ、トランスポートブロック、および／またはサブフレームの表示を、ＰＤＣＣＨまたはＥ－ＰＤＣＣＨ内に含まれるダウンリンク制御シグナリングから受け取ることができる。表示は、それの各可能な値が、ＰＤＳＣＨをその中で送信することができる（または送信することができない）セル、セルグループ、および／またはサブフレームのサブセットを示す、フィールドからなることができる。各値と関連付けられたサブセットは、より高位のレイヤによって事前決定または構成することができる。サブセットは、シグナリングがその中で受信されるセルもしくはセルグループ、またはフィールドがその中に含まれる同じＰＤＣＣＨもしくはＥ－ＰＤＣＣＨ内で示されるセルもしくはセルグループの関数とすることもできる。

【0191】

例えば、フィールドサイズが２ビットである場合、値「００」は、このＰＤＣＣＨまたはＥ－ＰＤＣＣＨ内においてＰＤＳＣＨがそれに対してスケジュールされたセルまたはセルグループ内においてだけ、ＰＤＳＣＨを受信することができることを示すことができ、値「１１」は、任意の構成されたセルまたはセルグループ内において、ＰＤＳＣＨを受信することができることを示すことができ、値「０１」は、より高位のレイヤによって構成されたセルグループの第１のセット内において、ＰＤＳＣＨを受信することができることを示すことができ、値「１０」は、より高位のレイヤによって構成されたセルグループの第２のセット内において、ＰＤＳＣＨを受信することができることを示すことができる。

【0192】

別の例においては、コードブックを決定するために、ＰＤＳＣＨが送信される１（または複数）のサービングセルのセルインデックスを、表示値と組み合わせて使用することができる。この例においては、ダウンリンク割り当てを有するどのＤＣＩも、同じ表示を送信することができる。表示値は、ＷＴＲＵがそれについてのＡ／Ｎをフィードバックすることを予期することができる、セルおよび／またはキャリアおよび／またはトランスポートブロックの異なるセットにマッピングすることができる。表示に基づいた適切なセットの決定は、ＰＤＳＣＨが送信される少なくとも１つのセルのサービングセルＩＤの関数とすることができる。

【0193】

表２は、表示と、ＷＴＲＵがそれについてＡ／Ｎを報告することができるセルのセットとの間の関係の例を、サービングセルの関数として提供する。基本的に、ＷＴＲＵは、表示の関数として、およびその中の少なくとも１つがＰＤＳＣＨを送信するサービングセルであるセットの関数として、適切なセットを決定することができる。

【0194】

【表2】

【0195】

２つ以上のサブフレームについてのＨＡＲＱ－ＡＣＫが報告されるべきケースでは（例えば、ＴＤＤのケースでは）、１つのソリューションにおいては、表示は、それがその中で受信されたサブフレームに関わらず、すべてのサブフレームおよびセルにわたるコードブック全体を表すことができる。あるいは、表示は、それがその中で受信されたサブフレームに対応するコードブックの一部を表すことができる。あるいは、表示は、それがその中で受信されたサブフレームを含む、そのサブフレームまでのサブフレームに対応するコードブックの一部を表すことができる。例えば、表示は、表示がその中で受信されたサブフレームを含む、そのサブフレームまでのいずれかのサブフレーム内においてＰＤＳＣＨを受信することができる、セルまたはセルグループのセットを表すことができる。

【0196】

表示の意味（例えば、ＷＴＲＵがそれについてのＨＡＲＱ Ａ／Ｎをフィードバックすることが予期されるトランスポートブロックおよび／またはセルおよび／またはキャリアおよび／またはサブフレームのセット）は、他のおそらくは暗黙的な要因に依存することができる。例えば、ＷＴＲＵは、表示内において特定のコードポイントまたはビットマップを受け取ることができ、ＷＴＲＵは、以下のうちの少なくとも１つに応じて、そのような表示を異なるコードブックにマッピングすることができる。ＷＴＲＵは、表示の送信のタイミングに応じて、そのような表示を異なるコードブックにマッピングすることができる。例えば、表示と併せて、サブフレーム番号を使用することができる。別の例においては、（ＴＤＤにおいて）特定のサブフレーム内においてそれについてのフィードバックが報告される、サブフレームのセットのうちの特定のサブフレームを使用することができる。ＷＴＲＵは、表示を含むＤＣＩの別のパラメータに応じて、そのような表示を異なるコードブックにマッピングすることもできる。例えば、ＴＰＣコマンドと新しい表示との組合せを使用することができる。別の例においては、ＤＣＩの探索空間のパラメータ（例えば、それが共通探索空間か、それともＷＴＲＵ固有の探索空間かどうか、または探索空間のＣＣＥ）を、表示値と組み合わせて、使用することができる。さらに、ＷＴＲＵは、ダウンリンク割り当て内で示されるＰＵＣＣＨフォーマットおよび／またはリソースに応じて、そのような表示を異なるコードブックにマッピングすることもできる。

【0197】

上においては、表示は、ダウンリンク割り当てのサブセットまたはすべての中に含むことができる。表示は、本明細書において説明されるような、ＵＣＩのためのスケジューリング情報の提供に専用される、１つまたは複数のＰＤＣＣＨ／Ｅ－ＰＤＣＣＨ（またはＤＣＩ）内に含むこともできる。

【0198】

別の例においては、ネットワークは、キャリアのどの事前構成されたグループが少なくとも１つのダウンリンク割り当てを含むかを示すことができる。したがって、スケジュールされていないキャリアに対応するＮＡＣＫビット（「知られた」ＮＡＣＫ）の数は、キャリアのあるグループ内にスケジュールされたダウンリンク割り当てが存在しないとき、減らすことができる。したがって、それは、依然として、スケジュールされていないキャリアからの（より少数の）いくつかのＮＡＣＫを含むことがあるが、コードブックのサイズは、劇的に減らすことができる。コードブックのサイズの減少は、電力の観点からの性能ばかりでなく、ＰＵＣＣＨリソース使用も改善する。

【0199】

３２のキャリアを用いるように構成されたＷＴＲＵについての別の例が、表３に示されている。この例においては、インジケータのコードポイントの１つ（００）は、「すべてのキャリア」を示すことができ、ＷＴＲＵがすべてのキャリア上においてスケジュールされることを可能にする。別のコードポイント（０１）は、８つのキャリアからなる４つの互いに素なグループを示すことができる。選択する特定のグループは、どのキャリアについて割り当てが受け取られたかに基づいて、決定することができる。２つの他のコードポイント（１０）および（１１）は、１６のキャリアからなる異なるグループ、またはおそらくはオプション１にあるようにキャリアの順序が変更されたグループを示すことができる。スケジューリング柔軟性および性能を最大化するために、より高位のレイヤによって、正確なマッピングを構成することができる。３ビット以上を有するフィールドを使用して、追加の柔軟性を獲得することもできる。追加のオーバヘッドを最小化するための１つの可能性は、ＡＲＩおよびコードブックインジケータのための単一のフィールドを使用することとすることができる。

【0200】

【表3】

【0201】

例においては、示されたグループの必ずしもすべてのキャリアをスケジュールする必要があるわけではないことがある。ＷＴＲＵは、示されたグループ内に含まれるキャリアについてＤＬ割り当てが検出されない場合、「ＮＡＣＫ」を示すことができる。

【0202】

図４は、ＨＡＲＱ Ａ／Ｎコードブック決定の例の図である。図４００に示される例においては、ＷＴＲＵは、キャリアのセット４１０内においてキャリアのサブセットについてのダウンリンク割り当てを受け取ることができる。例えば、ＷＴＲＵは、キャリア９、１０、１３、１４、１５、１６からなるサブセットについてのダウンリンク割り当てを受け取ることができ、どのＤＬ割り当てにおいても、コードブックインジケータは「０１」である。ＷＴＲＵは、キャリア１２については、ＤＬ割り当てを紛失している。ＷＴＲＵは、割り当てなしを有することができるキャリア１１については、割り当てを受け取ることができない。ＷＴＲＵは、キャリア｛９、１０、１１、１２、１３、１４、１５、１６｝などのキャリアについてのＨＡＲＱ Ａ／Ｎを保有するコードブック４２０を使用することができ、それは、キャリア１１、１２については、ＮＡＣＫを含む。

【0203】

表示は、各ＰＤＳＣＨ送信と関連付けられたダウンリンク制御情報の一部として受け取られる少なくとも１つのダウンリンク割り当てインデックス（ＤＡＩ）を含むことができる。このケースにおいては、ＷＴＲＵは、セルおよびサブフレーム毎に、受信されたＰＤＳＣＨを、事前決定されたルールに従って（例えば、第１にセルインデックス、第２にサブフレームによって、またはその反対によって）順序付けることができる。ＷＴＲＵは、（先に説明されたソリューションに基づいて、ＨＡＲＱ Ａ／Ｎが含まれるべきではないと決定されていない限り）各受信されたＰＤＳＣＨについてのＨＡＲＱ Ａ／Ｎビットをコードブック内に含むことができ、シーケンス内の連続するＤＡＩ値の間の差分に基づいて紛失したと決定された各ＰＤＳＣＨについては、（値「ＮＡＣＫ」を有する）ＨＡＲＱ Ａ／Ｎビットを含むことができる。例えば、紛失したＰＤＳＣＨの数は、（Ｎ－１） ｍｏｄ Ｍであると決定することができ、ここで、Ｎは、シーケンス内の連続するＤＡＩ値の間の差分であり、Ｍは、可能なＤＡＩ値の数である。

【0204】

表示は、少なくとも１つのＰＤＳＣＨ送信と関連付けられたダウンリンク制御情報の一部として受け取られるフィールドを含むことができる。フィールドは、おそらくは特定のサブフレーム内に、または特定のサブフレームのために割り当てられる、ダウンリンク割り当てからなるグループのうちの最終のダウンリンク割り当てを示すことができる。フィールドの１つの値（例えば、「０」）は、割り当てが最終の割り当てではないことを示すことができ、フィールドの別の値（例えば、「１」）は、割り当てがグループおよび／またはサブフレームおよび／またはコンポーネントキャリアの最終の割り当てであることを示すことができる。これは、ＷＴＲＵが、サブフレーム内においてブラインド検出をいつ停止するかについて知ることを、およびそれが最終の割り当てを検出したかどうかを知ることも可能にすることができる。

【0205】

いくつかのソリューションにおいては、最終の（または最後の）割り当てと関連付けられた表示は、他のタイプの情報を示すために使用することもできるフィールドの値から導出することができる。例えば、表示は、以下のうちの少なくとも１つに従って、１つまたは複数のＰＤＣＣＨ／Ｅ－ＰＤＣＣＨ内において受信される、ＡＲＩの、および／もしくはＰＵＣＣＨについてのＴＰＣコマンドの少なくとも１つの値から、またはＰＵＣＣＨフォーマットインジケータの少なくとも１つの値から導出することができる。

【0206】

ＷＴＲＵは、割り当てを、この割り当てについてのＡＲＩの値がセットのうちの少なくとも１つの他の割り当てと異なる場合、最終の割り当てとして識別することができる。セットは、サブフレームのすべての割り当て、またはすべての割り当てからなることができる。このケースにおいては、この割り当てについてのＡＲＩの（またはＰＵＣＣＨについてのＴＰＣコマンドの）値は、ＰＵＣＣＨリソースに対するインデックスを示すために、直接的に使用することができない。最終の割り当てとしての割り当ての決定は、以下の追加の条件のうちの少なくとも１つに従うことができる。

【0207】

例においては、他の割り当ての数は、おそらくは同じサブフレーム内に限ると、少なくとも１つとすることができる。別の例においては、少なくとも１つの他の割り当ては、事前定義されたシーケンス（例えば、第１にキャリア、第２にサブフレーム）に従って、最終の割り当てに先行する割り当てとすることができる。さらなる例においては、少なくとも１つの他の割り当ては、プライマリセルに対応しない少なくとも１つの割り当てを含むことができる。さらに別の例においては、最終の割り当てについてのＡＲＩの値は、固定または構成された値とすることができる。また別の例においては、最終の割り当てについてのＡＲＩの値は、他の割り当て内におけるＡＲＩの値に関連することができる。例えば、最終の割り当てのＡＲＩの値は、他の割り当て内におけるＡＲＩの値によって示されるＰＵＣＣＨリソース以下のＲＢの数を有するＰＵＣＣＨリソースを示すことができる。さらに、最終の割り当てのＡＲＩの値は、他の割り当て内において復号されたＡＲＩの合計に、固定もしくは構成された値をプラスしたもの（または固定もしくは構成された値とのＸＯＲ演算を施したもの）とすることができる。例えば、最終の割り当てのＡＲＩの値は、（可能なＡＲＩ値の数を法とした）１プラス他の割り当て内におけるＡＲＩの値とすることができる。

【0208】

ＷＴＲＵが、上述のソリューションのうちの１つに基づいて、最終の割り当てを検出しないケースにおいては、ＷＴＲＵは、コードブックが決定されていないと見なし、他のパラグラフにおいて説明されるソリューションに従ったアクションを適用することができる。あるいは、ＷＴＲＵは、コードブックの合計サイズが、事前定義または構成された有効サイズからなるセットのうちの有効サイズに対応するように、少なくとも１つのＮＡＣＫ（または「０」）をコードブックに追加することができる。

【0209】

表示は、各ＰＤＳＣＨ送信と関連付けられたダウンリンク制御情報の一部として受け取られるフィールドからなることができる。フィールドは、（おそらくはサブフレームおよび／またはコンポーネントキャリアについての）ダウンリンク割り当てのグループ内における、現在の割り当ての検出後に予期される残りの割り当ての数を、ＷＴＲＵに示すことができる。ＷＴＲＵは、紛失したＰＤＳＣＨをより良く決定することができ、いかなる紛失したＰＤＳＣＨについてのＮＡＣＫ値もフィードバック報告の適切な位置にあるようにすることができる。別のソリューションにおいては、フィールドは、ダウンリンク割り当てのグループおよび／またはサブフレームおよび／またはコンポーネントキャリア内におけるダウンリンク割り当ての総数を示すことができる。ＷＴＲＵは、紛失したＰＤＳＣＨの総数を決定することができ、これをフィードバック報告内においてサービングセルに示すことができる。

【0210】

表示は、各ＰＤＳＣＨ送信と関連付けられたダウンリンク制御情報の一部、例えば、ＤＡＩとして受け取られたフィールドからなることができる。ＤＡＩは、サービングセルのパラメータに従って順序付けられた、昇順カウンタとしての役割を果たすことができる（例えば、ＤＡＩは、サービングセルインデックスを増やす方向にカウントされた、現在の割り当てまでのすべての割り当ての累積カウンタとしての役割を果たすことができる）。例えば、ＤＡＩが２ビットであり、サービングセルが昇順のサービングセルインデックスで順序付けられていると仮定すると、第１のサービングセル（例えば、最も低いサービングセルインデックスを有するサービングセル）上における第１の割り当ては、ＤＡＩ＝００を有することができ、第２のサービングセル（例えば、２番目に低いサービングセルインデックスを有するサービングセル）上における第２の割り当ては、ＤＡＩ＝０１を有することができ、以降も同様である。

【0211】

別のソリューションにおいては、ＤＡＩは、サービングセルのパラメータに従って順序付けられた、降順カウンタとしての役割を果たすことができる（例えば、ＤＡＩは、サービングセルインデックスを増やす方向における、残りの割り当てのカウンタとしての役割を果たすことができる）。例えば、カウントダウンＤＡＩが２ビットであり、サービングセルが昇順のサービングセルインデックスで順序付けられていると仮定すると、最後の割り当て（例えば、最も高いサービングセルインデックスを有するサービングセル上における割り当て）は、カウントダウンＤＡＩ＝００を有することができ、最後から２番目の割り当て（例えば、残りのうちで最も高いサービングセルインデックスを有するサービングセル上における割り当て）は、カウントダウンＤＡＩ＝０１を有することができ、以降も同様である。

【0212】

カウンタは、単位値だけインクリメントすることができ、または単位カウンティングステップを有さないことができる。例えば、残りの割り当ての降順カウンタは、いくつかの連続する割り当てに対して、ＤＡＩ値を繰り返すことができる。例えば、残りの割り当ての降順カウンタは、Ｐの連続する割り当てに対して、同じ値を繰り返すことができる。例においては、割り当てを有するサービングセルが１０あり、Ｐ＝３である場合、カウントダウンＤＡＩは、（サービングセルインデックスを増やす順序において）以下のように割り当てることができる：１１ １０ １０ １０ ０１ ０１ ０１ ００ ００ ００。そのようなソリューションにおいては、ＷＴＲＵは、最後のＰ＝３の割り当てが００のカウントダウンＤＡＩを有することを予期することができる。そのようなソリューションにおいては、ＷＴＲＵは、それが最後のダウンリンク割り当ての受け取りに成功したかどうかを解決することができることがある。しかしながら、カウントダウンＤＡＩを有する割り当ての１つが紛失している場合、ＷＴＲＵは、それがＰ＝３の連続する割り当てのうちのどれが紛失しているかについて知ることができないならば、同じカウントダウンＤＡＩを共有するすべてのＰ＝３の連続する割り当てについてＮＡＣＫを報告しなければならないことがある。

【0213】

割り当ての昇順の累積カウンタおよび残りの割り当ての降順カウンタの両方が使用される、ハイブリッドなソリューションが可能なことがある。例えば、単位ステップで増えるカウンタ（例えば、どの割り当てについてもＤＡＩが１ずつ増やされる、割り当ての累積カウンタ）を使用することができ、残りの割り当ての（Ｐ回繰り返す）反復カウンタを使用することができる。例えば、累積ＤＡＩおよびカウントダウンＤＡＩが２ビットであると仮定すると、１０の割り当ては、（最初の２ビットが単位ステップ増分を使用する累積ＤＡＩを表し、最後の２ビットがＰ＝３を使用するカウントダウンＤＡＩを表す）以下の総合的なＤＡＩ値を有することができる：００１１ ０１１０ １０１０ １１１０ ０００１ ０１０１ １００１ １１００ ００００ ０１００。このケースにおいては、累積カウンタから、ＷＴＲＵは、任意の２^N+iの連続して紛失した割り当て（ここで、Ｎは、累積ＤＡＩのビット単位のサイズであり、ｉは、０以上の整数である）、および／または任意の最後に紛失した割り当てを除いて、あるとすれば、どの割り当てが紛失しているかを決定することができる。また、残りの割り当ての反復する降順カウンタから、ＷＴＲＵは、最大でＰ×２^Mの連続する割り当てが紛失しているかどうか（ここで、Ｍは、カウントダウンＤＡＩのビット単位のサイズである）、および最後のダウンリンク割り当てが紛失しているかどうかを決定することができる。２つのＤＡＩを組み合わせることによって、ＷＴＲＵは、Ｐ×２^Mと２^Nとの最小公倍数よりも大きいそれらを除いて、任意の連続する割り当てを解決することができる。ＭおよびＮの値は、等しい必要はない。例えば、累積カウンタがＮ＝２ビットを使用し、残りの割り当ての降順カウンタがＭ＝１ビットを使用し、反復がＰ＝３である状況は、最後の割り当てが紛失しているかどうか、および１２以上の連続する割り当てを除く他の任意の紛失した割り当てを、ＷＴＲＵが解決することができることをもたらすことができる。

【0214】

フィールドは、フォーマットの表示、および／またはその上において送信するＰＵＣＣＨのリソースインデックス（「ＡＣＫ／ＮＡＣＫリソースインジケータ」）など、値毎にＨＡＲＱフィードバックに関連する他の情報を示すこともできる。例えば、フィールドサイズが３ビットである場合、値「０１０」は、より高位のレイヤによって構成されたセルグループの第１のセット内においてＰＤＳＣＨを受信することができること、およびＨＡＲＱフィードバックの送信が、あるＰＵＣＣＨフォーマット上において、より高位のレイヤによって構成されたリソースインデックスの第１の値に関して生じることを示すことができ、値「０１１」は、より高位のレイヤによって構成されたセルグループの第１のセット内においてＰＤＳＣＨを受信することができること、およびＨＡＲＱフィードバックの送信が、より高位のレイヤによって構成されたリソースインデックスの第２の値に関して生じることを示すことができ、その他も同様である。あるいは、使用する１つまたは複数のＰＵＣＣＨリソースインデックスについての情報は、別個のフィールド内において、または別個のＰＤＣＣＨもしくはＥ－ＰＤＣＣＨ内において提供することができる。

【0215】

紛失した検出に対するロバストネスを保証するために、２つ以上のＰＤＣＣＨまたはＥ－ＰＤＣＣＨから（すなわち、ＷＴＲＵがそれからＰＤＳＣＨ割り当てを受信するいずれのセル内においても）、同じ値の表示を受け取ることができる。表示は、このＷＴＲＵのためのＰＤＳＣＨ割り当てを含む他のＰＤＣＣＨまたはＥ－ＰＤＣＣＨとは独立した、特定のセルまたは探索空間内における特定のＤＣＩフォーマットのＰＤＣＣＨまたはＥ－ＰＤＣＣＨ内に含まれることもできる。例えば、表示は、共通の探索空間内において受信されたＰＤＣＣＨ内に含まれることができる。表示は、１つのサブフレームまたは（１つのフレームなど）２つ以上のサブフレームの持続時間の間、有効とすることができる。

【0216】

例においては、一般化されたインジケータを使用することができる。表示は、それの特定の値に応じて、または関連するフラグもしくはフィールドの値に応じて、ダウンリンク割り当てインデックス（ＤＡＩ）として、またはコードブックインジケータもしくはコードブックサイズインジケータとして解釈することができる、フィールドからなることができる。例えば、表示は、Ｎビットからなることができ、Ｎ－１ビットの解釈は、特定のビットの値に依存する。表４は、例を提供している。

【0217】

さらなる例においては、コードブックサイズ値は、より高位のレイヤによって事前定義または構成することができる。

【0218】

【表4】

【0219】

別の例においては、コードブック決定は、ＤＡＩおよびサイズインジケータを使用することができる。いくつかの例においては、ＷＴＲＵは、ダウンリンク割り当てから受け取った、０以上のＤＡＩ、および０以上のコードブックインジケータまたはコードブックサイズインジケータに基づいて、コードブックを決定することができる。そのようなソリューションにおいては、ＷＴＲＵは、受け取ったＤＡＩに基づいて、コードブック（またはそれの部分）を決定し、このコードブック（またはそれの部分）がいずれか適用可能な受け取ったコードブックインジケータと一致することを検証することができる。ＷＴＲＵが、ＤＡＩ－コードブックが受け取ったコードブックインジケータと一致すると決定したケースにおいては、ＷＴＲＵは、ＤＡＩ－コードブックに従って、ＨＡＲＱ－ＡＣＫを送信することができる。そうではない場合、ＷＴＲＵは、他の情報を送信すること、および／または本明細書において説明されるような他のアクションを実行することができる。

【0220】

受け取ったコードブックインジケータは、ＨＡＲＱ－ＡＣＫコードブック全体に、またはＨＡＲＱ－ＡＣＫコードブックのサブセットに適用可能とすることができる。後者のケースにおいては、サブセットは、コードブックインジケータが受け取られたのと同じサブフレーム内において受け取られたダウンリンク割り当てに対応することができる。あるいは、サブセットは、コードブックインジケータが受け取られたサブフレームを含む、それに先行するサブフレーム内において受け取られたダウンリンク割り当てに対応することができる。同様に、ＤＡＩ－コードブックは、ＨＡＲＱ－ＡＣＫコードブック全体にわたって、またはサブセットに適用可能とすることができる。

【0221】

コードブックインジケータは、可能なコードブックサイズの範囲、可能なコードブックサイズのセット、または特定のサイズを示すことができる。例えば、インジケータの特定のコードポイントは、２１ビットと５０ビットの間のサイズの範囲に対応することができる。このケースにおいては、ＷＴＲＵは、それのサイズが示された範囲内にある場合、またはそれが示されたサイズに等しい場合、ＤＡＩ－コードブックが、適用可能な受け取られたコードブックインジケータと一致すると決定することができる。コードブックインジケータは、ＰＵＣＣＨフォーマットインジケータに対応することができ、ＰＵＣＣＨフォーマットの表示は、コードブックについての可能なサイズの範囲を暗黙的に示す。例えば、ＰＵＣＣＨフォーマット３の表示は、コードブックサイズが２１ビット以下であることを暗黙的に示すことができる。

【0222】

いくつかの例においては、ＷＴＲＵは、明示的なコードブックインジケータの代わりに、ダウンリンク制御シグナリングの他の特性またはフィールドから、コードブックサイズの範囲またはセットを暗黙的に導出することができる。例えば、ＷＴＲＵは、ＰＵＣＣＨに割り当てられたＲＢの数の表示から、またはおそらくはＰＵＣＣＨフォーマットインジケータと組み合わせて、ＰＵＣＣＨについてのリソース表示（例えば、ＡＲＩ）から、可能なコードブックサイズの範囲を導出することができる。ＰＵＣＣＨのＲＢのある数に対して、またはＡＲＩのある値に対して可能なコードブックサイズのセットを、より高位のレイヤによって事前定義または構成することができる。例えば、可能なコードブックサイズのセットは、ＡＲＩ＝２の場合は｛１６，３２，４８，６４，８０，９６，１１２，１２８｝として、ＡＲＩ＝３の場合は｛２４，４０，５６，７２，８８，１０４，１２０｝として構成することができる。

【0223】

特定のダウンリンク割り当ては、コードブックインジケータ、ＤＡＩ、またはコードブックインジケータとＤＡＩの両方を含むことができる。ダウンリンク割り当てが、ＤＡＩを示さないとき（例えば、一般化されたインジケータがＤＡＩに対応しない値を有するとき）、次に受信されるダウンリンク割り当て内における予期されるＤＡＩ値は、ＤＡＩが受け取られたかのように、インクリメントされることができる。

【0224】

ＤＡＩ－コードブックが、コードブックの少なくとも１つの部分について、コードブックインジケータと一致しないとＷＴＲＵが決定した場合、ＷＴＲＵは、そのようなインジケータが特定のサイズを示す場合、少なくとも１つの部分についてのコードブックのサイズを、コードブックインジケータと対応する値になるように調整することができる。ＷＴＲＵは、少なくとも１つの部分のすべてのビットについてＮＡＣＫを示すことができる。ＤＡＩ－コードブックが、コードブックの少なくとも１つの部分について、コードブックインジケータと一致しないとＷＴＲＵが決定したが、（例えば、インジケータがサイズの範囲だけを示す場合など）ＷＴＲＵがコードブックの正しいサイズを決定することができないケースにおいては、ＷＴＲＵは、コードブックが未定であると見なすことができ、本明細書において説明されるアクションを実行することができる。

【0225】

上においては、表示は、ＤＣＩのペイロード内に含まれるフィールドの値、またはＣＲＣのビットのサブセットもしくはすべてをマスクするために使用されるフィールドの値からなることができる。

【0226】

いくつかの例においては、ネットワークによって、動的な方式で、コードブックをＷＴＲＵに示すことができる。例えば、それの送信が単一のＨＡＲＱ Ａ／Ｎフィードバックリソースにマッピングされる、すべてのダウンリンク割り当てのうちの少なくとも１つの中に、コードブックインジケータを含むことができる。コードブックインジケータ内のコードポイントの意味は、ネットワークによって、おそらくは半静的に構成することができる。例えば、ＲＲＣコマンドを使用して、コードポイント毎に可能なコードブックをＷＴＲＵに示すことができる（ＷＴＲＵは、インジケータおよび少なくとも１つのサービングセルに基づいて、適切なコードブックを選択することができる）。コードブックの粒度を改善するために、したがって、おそらくは動的コードブックを使用する利益を増やすために、インジケータビットの数を増やすことができる。例えば、４つのインジケータビットを使用することができ、１６の可能なコードポイントの各１つを、少なくとも１つの割り当てのサービングセルに応じて、複数のコードブックにマッピングすることができる。そのような構成は、大きいＲＲＣペイロードを必要とすることがあり、維持できないことがある。

【0227】

コードブックに対するコードブックインジケータの意味は、コードポイントのサブセットの構成と、少なくとも１つのサービングセルとの組合せによって決定することができる。例えば、ＷＴＲＵは、おそらくはＲＲＣによって、キャリアの多数のセット（例えば、各々が最大で８つのキャリアからなる４つのセット、または各々が最大で４つのキャリアからなる８つのセット、または各々が最大で２つのキャリアからなる１６のセット、または各々が１つのキャリアからなる３２のセット）を用いるように構成することができる。セットは、事前に決定しておくことができ、またはネットワークによって明示的に構成することができる。または、セットは、ＷＴＲＵにおいて、セットの総数についてのネットワーク送信されるインジケータによって決定することができ、ＷＴＲＵは、構成されたキャリアを、事前決定または事前構成された方式で分割する（例えば、ＷＴＲＵは、セルインデックスなどのインデックスによってキャリアを順序付けることができ、その後、キャリアを構成された数のセットに均等に分割することができる）。ＷＴＲＵは、インジケータの最初のｘ（例えば、ｘ＝２）ビットをキャリアのセットにマッピングする表を用いるように（おそらくは半静的に）構成することもできる。インジケータの他の残りのｙ（例えば、ｙ＝２）ビットは、最初のｘビットのために使用される表の関数として、おそらくは、少なくとも１つのサービングセルの関数として決定することができる。

【0228】

例として、ネットワークは、ＷＴＲＵに、それがキャリアの４つのセットを使用すべきであることを示すことができる。キャリアの各セットは、最大で８つのキャリアを含むことができる（例えば、セットＡ＝｛１，２，３，４，５，６，７，８｝、セットＢ＝｛９，１０，１１，１２，１３，１４，１５，１６｝、セットＣ＝｛１７，１８，１９，２０，２１，２２，２３，２４｝、セットＤ＝｛２５，２６，２，２８，２９，３０，３１，３２｝）。ＷＴＲＵは、例えば、表５に示されるような、インジケータの最初の２ビットを異なるセットにマッピングする表を用いるように（おそらくは半静的に）構成することもできる。

【0229】

【表5】

【0230】

インジケータの最後の２ビットの意味は、少なくとも１つのコードポイント（例えば、「００」）に対して、空のセットを使用し、その後、他のすべてのコードポイントに対して、少なくとも１つのサービングセルから決定されるセットの相補セットを使用することによって（Ａの相補セットは、Ａｃによって示され、この例においては、ＢＣＤによって与えられる）決定することができる。表６は、コードブックインジケータの最後の２ビットの意味の例を示している。

【0231】

【表6】

【0232】

例えば、インジケータの最初の２ビットに対して表５を用いるように構成され、セットＡ内のセルから割り当てを受け取るＷＴＲＵは、インジケータの最初の２ビットを、表７に基づいて解釈することができ、その後、インジケータの最後の２ビットを、表８に基づいて解釈することができる。全体的なコードブックは、コードブックインジケータの最初の２ビットおよび最後の２ビットから獲得されるセットの合併から決定することができる。この例においては、ＷＴＲＵが、セットＡ内のセルからの割り当てを復号し、コードブックインジケータコードポイント０１１０も与えられた場合、それがセットＡ内の少なくとも１つのセルを有するという事実から、最初の２ビット（０１）の意味は、セットＡＢを意味することができ、最後の２ビット（１０）の意味は、セットＢＤを意味することができる。したがって、このケースにおいては、コードブックは、２つのセットの合併、したがって、セットＡ、Ｂ、Ｄ内のすべてのセルを含むことができる。

【0233】

別の例においては、ＷＴＲＵが、コードブックインジケータ（００００）を用いて、セットＡ内のセル内において割り当てを復号することができ、表７および表８から、コードブックは、セットＡと空のセットの合併であり、したがって、セットＡ内のすべてのセルを含むと決定することができる。

【0234】

【表7】

【0235】

【表8】

【0236】

別の例においては、表５におけるどのコードポイントについてのセットも、セットの総数および事前構成または事前決定された公式の関数として、ＷＴＲＵによって決定することができる。例えば、コードポイント「００」は、いずれか単一のセットとすることができ、一方、コードポイント「０１」は、２つのセットのペアとすること（例えば、インデックスを送信する少なくとも１つのセルを含むセットを、ＡＢまたはＣＤまたはＥＦまたはＧＨまたは．．．から選択すること）ができ、コードポイント「１０」は、３つのセットのグループとすること（例えば、インデックスを送信する少なくとも１つのセルを含むセットを、ＡＢＣまたはＤＥＦまたはＧＨＩまたは．．．から選択すること）ができ、コードポイント「１１」は、４つのセットのグループとすること（例えば、インデックスを送信する少なくとも１つのセルを含むセットを、ＡＢＣＤまたはＥＦＧＨまたは．．．から選択すること）ができる。

【0237】

さらなる例においては、ＷＴＲＵは、コードブック内における情報ビットの順序の決定を行うことができる。ＷＴＲＵは、復号性能を最適化するように、コードブック順列の選択を行うことができる。いくつかのソリューションにおいては、ＷＴＲＵは、サブフレーム内におけるＨＡＲＱ－ＡＣＫビットの送信についての順序（またはシーケンス）を決定または選択することができる。適切な順序の選択は、コードブックの連続した位置に存在する、（例えば、ＰＤＳＣＨが送信されなかったセル／サブフレームにそれらが対応するために）ネットワークによってＮＡＣＫであることが知られているＨＡＲＱ－ＡＣＫビットを回避することによって、ネットワークサイドにおけるＨＡＲＱ－ＡＣＫの復号性能を高めることができる。

【0238】

順序は、（コードブック表示またはシャッフリング表示など）ダウンリンク制御シグナリングからの表示に基づいて、選択することができる。あるいは、順序は、それについてのＨＡＲＱ－ＡＣＫが報告されるべき、セルおよび／またはサブフレーム内において受信されたＰＤＳＣＨまたは受信されなかったＰＤＳＣＨのセットに基づいて、決定することができる。さらに、順序は、特定のサブフレーム内におけるＨＡＲＱ－ＡＣＫコードブックの全体サイズに依存することができる。

【0239】

いくつかの例においては、ＷＴＲＵは、同じ数のビットを含むことができるが、各ビットの位置が、異なるセル、サブフレーム、および／またはセルのトランスポートブロックについてのＰＤＳＣＨのＡＣＫまたはＮＡＣＫ結果に対応する、多数の可能なコードブックの１つを選択する。例えば、第１のコードブックにおいては、第２３のビットは、第１２の構成されたセルから受信された第１のトランスポートブロックに対応することができ、一方、第２のコードブックにおいては、第２３のビットは、第１８の構成されたセルから受信された第２のトランスポートブロックに対応することができる。各コードブックのビットの総数は、構成されたセルの数、（送信モードに応じて）各セル内において受信することができるトランスポートブロックの数、およびサブフレーム構成に基づいて、決定することができる。

【0240】

いくつかの例においては、コードブックのセットは、ビット順序が事前定義されたルールに基づいて決定される基本コードブックから、ビットのインターリーブまたは並べ替えによって、構成することができる。例えば、基本コードブック順序は、第１にセル内におけるトランスポートブロックの順序により、次に第２に（ＴＤＤについての）サブフレームインデックスの順序により、最後に構成されたセルの順序によることができる。基本コードブックについての別の可能なルールは、最初にセルの順序により、次に（ＴＤＤについての）サブフレームインデックスの順序により、最後にトランスポートブロックの順序によることができる。

【0241】

セットのうちの特定のコードブックは、基本コードブックからのビットの定義された順列に対応することができる。順列のセットは、コードブックサイズの可能な数毎に、（例えば、表を使用して）明示的に定義することができる。例えば、６４ビットのコードブックサイズの場合、２つの順列を、［１；２；３；４；５；．．．６４］および［１；３３；２；３４；３；３５；．．．３２；６４］として定義することができる。あるいは、順列のセットは、コードブックサイズに依存することができる公式を使用して定義することができる。公式は、例えば、疑似ランダム順列のセット、または各順列が連続するエントリ間の特定の差によって特徴付けられる順列のセットを実施することができる。

【0242】

与えられたサブフレーム内において使用するコードブックは、ダウンリンク制御シグナリングによって示すことができる。例えば、コードブックは、それについてのＨＡＲＱ－ＡＣＫが報告されるＰＤＳＣＨについてのダウンリンク割り当てを含む、ＤＣＩまたはＤＣＩのセットのフィールド内において示すことができる。別の例においては、コードブックは、ＰＵＣＣＨまたはＰＵＳＣＨ上におけるアップリンク制御情報の送信についての動的なスケジューリング情報を提供するために使用される、ＤＣＩのフィールド内において示すことができる。ただ２つのコードブックが定義されるケースにおいては、フィールドは、基本コードブックが使用されるべきか、それとも置換された（または「シャッフルされた」）コードブックが使用されるべきかを示す、単一のビットからなることができる。

【0243】

あるいは、与えられたサブフレーム内において使用するコードブックは、受信されたＰＤＳＣＨのセットに依存するあるメトリックが最適化されるように、決定することができる。例えば、コードブックは、割り当てられなかった（または割り当てられたことが検出されなかった）ＰＤＳＣＨのＡ／Ｎビットに対応する連続するビットの最大数が最小化されるように、選択することができる。

【0244】

いくつかの例においては、ＷＴＲＵは、それがネットワークサイドにおいて仮定されるコードブックと一致する確実性が存在するように、受信されたダウンリンク割り当てに基づいて、コードブックの少なくとも１つの特性を決定することができない。そのような状況においては、コードブックは、ＷＴＲＵによって、「未定」と見なすことができる。

【0245】

ＷＴＲＵは、以下のうちの１つが生じたとき、すなわち、ＷＴＲＵが、ダウンリンク割り当てのセットから、少なくとも１つのコードブックインジケータ（もしくはコードブックサイズインジケータ）を受け取らなかったとき、セル／キャリアおよびサブフレームの事前定義されたシーケンスの最後に受信された割り当て内のフィールドが、さらなるダウンリンク割り当てが受信されるべきであることを示すとき、（おそらくは、ダウンリンク割り当てが受信された最後のサブフレーム内において受け取られたフィールドが、さらなるダウンリンク割り当てが次のサブフレーム内に存在することができることを示す場合に限って）ＷＴＲＵが、サブフレームについてのダウンリンク割り当てのセットから、このサブフレームだけについてのセル、セルグループ、および／もしくはトランスポートブロックのセットを示す、少なくとも１つのコードブックインジケータを受け取らなかったとき、（おそらくは、最後に受信されたコードブックインジケータと同じサブフレーム内のダウンリンク割り当て内において受け取られたフィールドが、さらなるダウンリンク割り当てが次のサブフレーム内に存在することができることを示す場合に限って）ＷＴＲＵが、最後のサブフレームについてのダウンリンク割り当てのセットから、それが受信されたサブフレームを含む、そのサブフレームまでのすべてのサブフレームについてのセル、セルグループ、および／もしくはトランスポートブロックのセットを示す、少なくとも１つのコードブックインジケータを受け取らなかったとき、ならびに／またはＤＡＩ－コードブックが、コードブックの少なくとも１つの部分についてのコードブックインジケータと一致しないが、（例えば、インジケータがサイズの範囲だけを示す場合など）コードブックの正しいサイズを決定することができないとき、コードブックが未定であると見なすことができる。

【0246】

ＷＴＲＵが、コードブックが未定であると見なす場合、ＷＴＲＵは、より高位のレイヤの構成だけから定義されるデフォルトのコードブックを使用してＨＡＲＱ－ＡＣＫを送信することができ、ＷＴＲＵは、コードブックが未定であることを示す表示を、特定のＰＵＣＣＨリソースおよびフォーマット上において、もしくはおそらくは、ＰＵＳＣＨ送信が存在する場合は、ＰＵＳＣＨ上において送信することができ（特定のＰＵＣＣＨリソースおよび／もしくはフォーマットは、より高位のレイヤによって構成することができ、もしくはダウンリンク制御シグナリング（例えば、ＡＲＩ）から獲得することができ、表示は、（例えば、ＮＡＣＫに対応する）単一のビットからなることができ、送信される場合、デフォルトのコードブックのＨＡＲＱ－ＡＣＫと多重化されることができ、ならびに／またはＷＴＲＵは、ＰＵＣＣＨもしくはＰＵＳＣＨ内においていかなるＨＡＲＱ－ＡＣＫも送信することを控えることができる。

【0247】

例においては、複数のフィードバックグループを使用するＨＡＲＱフィードバックの送信を使用することができる。いくつかのソリューションにおいては、与えられたアップリンクサブフレーム内において送信される必要があるＨＡＲＱフィードバック情報は、情報ビットの２つ以上のセットによって表すことができる。各そのようなセットは、本明細書においては、「フィードバックグループ」と呼ばれることがある。

【0248】

フィードバックグループは、セル、セルグループ、および／またはサブフレームに基づいて、定義することができる。例えば、第１のフィードバックグループは、セルの第１のグループ（例えば、８つの構成されたセルからなる第１のグループ）からのＨＡＲＱフィードバックを含むことができ、第２のフィードバックグループは、セルの第２のグループ（例えば、８つの構成されたセルからなる第２のグループ）からのＨＡＲＱフィードバックを含むことができ、以降も同様である。

【0249】

別の例においては、フィードバックグループは、少なくとも半静的な情報に基づいてサブフレーム内において送信される必要がある情報ビットの総数、およびそのような情報ビットの順序、フィードバックグループ当たりの情報ビットの最大数または目標数、フィードバックグループの最大数または目標数、グループ毎のビットの数を等しくする（またはその差を高々１ビットにする）ことを目指すこと、ならびにフィードバックグループの数を最小化することのうちの少なくとも１つに基づいて、定義することができる。例えば、サブフレーム内において送信される情報ビットの総数が３６であり、フィードバックグループ当たりの情報ビットの最大数が１０であるケースにおいては、フィードバックグループは、９ビットからなる４つのグループからなることができる。

【0250】

いくつかのソリューションにおいては、ＷＴＲＵは、フィードバックグループに関連する少なくとも１つのＰＤＳＣＨ（またはトランスポートブロック）が受信された場合に限って、このフィードバックグループからの情報をエンコードおよび送信することができる。このフィードバックグループについての少なくとも１つのＰＤＳＣＨが受信されたケースにおいては、ＷＴＲＵは、ＰＤＳＣＨがそれから受信されなかった、このフィードバックグループに関連するセルおよび／またはサブフレームについて、「ＮＡＣＫ」を報告することができる。あるいは、ＷＴＲＵは、「ＤＴＸ」を報告することができる。例えば、フィードバックグループが、セル当たり２つのトランスポートブロックを有する、３つのセルからなるグループについてのＨＡＲＱフィードバックからなり、ＰＤＳＣＨが、第２のセル上だけにおいて受信された場合、フィードバックグループ内には６つの情報ビットが存在することができる。（ＰＤＳＣＨがそれから受信されなかったセルに対応する）最初の２ビットおよび最後の２ビットは、「ＮＡＣＫ」を示すことができ、一方、（ＰＤＳＣＨがそれから受信されたセルに対応する）中間の２ビットは、トランスポートブロックの復号が成功した場合は「ＡＣＫ」を、それ以外の場合は「ＮＡＣＫ」を示すことができる。

【0251】

いくつかのソリューションにおいては、フィードバックグループのサブセットの組合せは、フィードバックグループの有効な組合せのセットに制限することができる。例えば、グループ＃２だけなど、正確に１つのフィードバックグループを送信することは可能ではないことがあるが、（＃１と＃２など）２つのフィードバックグループからなるいくつかの組合せは、可能であることがある。ＷＴＲＵは、フィードバックグループに関連するＰＤＳＣＨが受信されなかった場合でさえも、グループの有効な組合せを獲得するために、このフィードバックグループからの情報を送信することができる。有効な組合せのセットは、より高位のレイヤによって事前定義または提供することができる。

【0252】

例においては、送信されたフィードバックグループの別個の処理を使用することができる。ソリューションにおいては、それについての送信が生じる各フィードバックグループの情報ビットは、別々にエンコードすることができる。例えば、第１のフィードバックグループが８ビットからなり、第２のフィードバックグループが１０ビットからなる場合、各フィードバックグループは、（例えば、リード－マラーブロックコードを使用して）２４の符号化ビットにエンコードすることができる。その後の変調、拡散、および物理リソースへのマッピングも、フィードバックグループ毎に別々に実行することができる。

【0253】

各フィードバックグループのために使用する符号化ビットの数は、各フィードバックグループのビットの数の関数とすることができる。符号化ビットの各数は、（２４または４８など）符号化ビットの数についての事前決定された値のセットの中から選択することができる。いくつかのソリューションにおいては、符号化ビットの選択される数は、最大で最大符号化レート（例えば、符号化ビットの数に対する情報ビットの数の比）を達成する事前決定された値の中の最小数になるように選択することができる。

【0254】

例においては、送信されるフィードバックグループの共同処理を使用することができる。ソリューションにおいては、それについての送信が生じる各フィードバックグループの情報ビットは、共同で処理し、単一のリソースにマッピングすることができる。例えば、それぞれ、８、１２、１０、および１４ビットからなる、（＃１、＃２、＃３、および＃４というラベルが付された）４つの定義されたフィードバックグループが存在することができる。フィードバックグループ＃１、＃３、および＃４が送信されるサブフレームにおいては、全部でＢ＝３２ビット（＝８＋１０＋１４）をエンコードすることができる。

【0255】

エンコードは、複数のリード－マラーブロックコードからなることができ、Ｂビットのセットは、最大でＮの情報ビットからなるＭのサブセットに均等に分割することができ、各サブセットは、独立してエンコードされる。Ｍのサブセットからの符号化ビットは、その後、（おそらくは、変調、拡散、および物理リソースへのマッピングを含む）後続の処理に先立って、多重化することができる。そのようなタイプのエンコードは、テストされるコードワード候補の総数を減らすことによって、受信機における性能を改善することができる。サブセットの数Ｍは、事前定義された関数に従って、ビットの数Ｂの関数とすることができる。例えば、Ｍは、比Ｂ／Ｎよりも大きい最小の整数になるように設定することができる。

【0256】

別の例においては、エンコードは、畳み込みまたはターボエンコードなど、他のタイプのコードを使用することができる。特定のサブフレーム内において使用されるエンコードのタイプは、それについての送信が生じるフィードバックグループのサブセットを与えた場合、送信されるビットの数Ｂの関数とすることができる。例えば、フィードバックグループのサブセットが、送信されるＢ≦Ｂ０ビット（Ｂ０は４０などの固定値とすることができる）をもたらすサブフレーム内においては、ＷＴＲＵは、複数のリード－マラーブロックコードを使用することができる。ＢがＢ０よりも大きいが、Ｂ１（Ｂ１は１００などの固定値とすることができる）以下であるサブフレーム内においては、ＷＴＲＵは、畳み込みエンコードを使用することができる。ＢがＢ１よりも大きいサブフレーム内においては、ＷＴＲＵは、ターボエンコードを使用することができる。

【0257】

信頼性を改善するために、エンコードに先立って、ＣＲＣビットのセットをＢビットのセットに追加することができる。ＣＲＣビットの数は、ビットの数Ｂに依存することができ、または適用されるエンコードのタイプに依存することができる。例えば、ＢがＢ０ビット以下であるとき、または畳み込みもしくはターボエンコードが使用されないとき、０のＣＲＣビットを追加することができる。

【0258】

図５は、送信されるフィードバックビットの数に基づいた、チャネル符号化およびＣＲＣの包含のための例示的な選択プロセスの図である。プロセス５００に示されるように、ＷＴＲＵは、複数の構成されたキャリアのセット５１０上において、複数のトランスポートブロックを受信し、複数のトランスポートブロックについてのＨＡＲＱ－ＡＣＫフィードバック５２０を生成することができる。キャリアについてのＨＡＲＱ－ＡＣＫフィードバックの包含は、そのキャリアについてのダウンリンク割り当て内に存在するＤＡＩフィールドに基づくことができる。さらに、ＷＴＲＵによって検出される連続するＤＡＩの値に応じて、補足的なＨＡＲＱ－ＡＣＫフィードバックビットを、ＨＡＲＱ－ＡＣＫコードブック内に挿入することができる。さらに、キャリアについてのダウンリンク割り当てが存在しないことがある。ＨＡＲＱ－ＡＣＫフィードバック５２０は、ＨＡＲＱ－ＡＣＫフィードバックビット５２５を使用することができる。ＷＴＲＵは、使用されるＨＡＲＱ－ＡＣＫフィードバックビットの数を決定することができる。ＷＴＲＵは、５３０において、ｎによって表すことができるＨＡＲＱ－ＡＣＫフィードバックビットの数を、閾値Ｂなどの閾値と比較することができる。例においては、フィードバックビットの数が閾値以下であり、したがって、ｎ≦Ｂである場合、５４０において、リード－マラー符号化を使用することができる。エンコードされたフィードバックビットのセット５４５は、リード－マラー符号化からもたらされることができる。さらに、フィードバックビットの数が閾値よりも大きく、したがって、ｎ＞Ｂである場合、ＷＴＲＵは、５５０において、ＣＲＣを挿入または追加することができる。また、フィードバックビットの数が閾値よりも大きく、したがって、ｎ＞Ｂである場合、ＷＴＲＵは、５６０において、畳み込み符号化を使用することができる。エンコードされたフィードバックビットのセット５６５は、畳み込み符号化からもたらされることができる。

【0259】

いくつかのソリューションにおいては、エンコードに先立つ情報ビット（またはペイロードサイズ）の可能な数Ｂ’の有限なセットは、受信機における復号を単純化することを可能にすることができる。このセットは、（セルの数、セルのグループ、およびセル当たりのトランスポートブロックの数などの）構成から、事前定義または決定することができる。特定のサブフレームにおいて使用する特定のペイロードサイズＢ’は、ダウンリンク制御シグナリングから動的に決定することもできる。例えば、ＰＤＣＣＨ／Ｅ－ＰＤＣＣＨ内のフィールドは、より高位のレイヤによって事前定義または構成される可能なペイロードサイズＢ’のセットのうちの１つを示すことができる。別の例においては、フィールドは、その各々が構成（セルの数、およびセルグループなど）に応じたペイロードサイズに対応する、可能なＰＵＣＣＨフォーマットのセットのうちの１つを示すことができる。ＷＴＲＵは、送信するビットの数Ｂが情報ビットの許容される数Ｂ’よりも低いとき、パディングビットを使用することができる。例えば、可能なペイロードサイズのセットは、２０ビット、５０ビット、および１００ビットとすることができる。フィードバックグループの選択されたサブセットに基づいた、送信されるビットの数Ｂが、６０ビットであるケースにおいては、ＷＴＲＵは、全ペイロードが１００ビットになるように、パディングビットを利用することができる。ＷＴＲＵは、ビットの総数が有効なペイロードサイズと一致するように、（最初に選択されなかった）追加のフィードバックグループから情報を送信することもできる。

【0260】

使用する符号化ビットの数は、ビットの総数ＢまたはペイロードサイズＢ’の関数とすることができる。それは、符号化ビットの数についての事前決定された値のセットの中から選択することができる。いくつかのソリューションにおいては、符号化ビットの選択される数は、最大で最大符号化レート（例えば、符号化ビットの数に対する情報ビットの数の比）を達成する事前決定された値の中の最小数になるように選択することができる。

【0261】

例においては、リソースの決定を使用することができる。本明細書において説明されるように、リソースとは、（例えば、ＰＵＣＣＨ上における）フィードバックの送信のための送信特性のセットのこととすることができる。リソースは、ＲＢのセット、１つまたは複数のＤＭ－ＲＳシーケンスの特性、および少なくとも１つの拡散系列など、すべての特性がそれから導出されるインデックスによって識別することができる。ＰＵＣＣＨが複数のセル上において構成されるケースにおいては、リソースは、ＰＵＣＣＨがその上で送信されるべきセル、またはセルのセットを含むことができる。サブリソースとは、そのようなリソースの一部、例えば、リソースが２つ以上のＲＢのセットからなるケースにおける１つのＲＢ、またはリソースが２つ以上の拡散系列のセットからなるケースにおける１つの拡散系列、またはリソースが複数のセルからなるケースにおける１つのセルのこととすることができる。

【0262】

ＷＴＲＵは、フィードバックグループに関連するＰＤＳＣＨのうちの少なくとも１つと関連付けることができるダウンリンク制御シグナリングに基づいて、フィードバックグループまたはフィードバックグループの組合せの送信のために使用されるリソースまたはサブリソースを決定することができる。例えば、リソースまたはサブリソースは、フィードバックグループまたは組合せのフィードバックグループ部分に関連するＰＤＳＣＨをスケジュールする、ＰＤＣＣＨ／Ｅ－ＰＤＣＣＨ内のＡＲＩフィールドによって示すことができる。別の例においては、リソースまたはサブリソースは、ＰＤＣＣＨ／Ｅ－ＰＤＣＣＨがそれから復号されるセルもしくはセルグループ、または対応するＰＤＳＣＨのセルもしくはセルグループに依存することができる。例えば、ＰＵＣＣＨがその上で送信されるセルは、ＰＤＣＣＨ／Ｅ－ＰＤＣＣＨがそれから復号されるセルグループと同じセルグループ内のセルとすることができる。別の例においては、本明細書において説明されるようなシグナリングを使用することができる。

【0263】

フィードバックグループの組合せの送信のために使用されるリソースは、おそらくはＡＲＩと組み合わされた、符号化ビットの数および／または関連するＰＵＣＣＨフォーマットに依存することができる。例えばＷＴＲＵは、符号化ビットの数が第１の数であり、受け取ったＡＲＩが第１の値である場合は、第１のリソースを選択し、符号化ビットの数が第２の数であり、受け取ったＡＲＩが第１の値である場合は、第２のリソースを選択することができる。リソースと、ＡＲＩおよび符号化ビットの数の組合せとの間のマッピングは、より高位のレイヤによって構成することができる。別の例においては、ＷＴＲＵは、ＰＵＣＣＨフォーマット毎に、または情報ビットもしくは符号化ビットの可能な数毎に、単一のリソースを用いるように構成することができる。このケースにおいては、ＷＴＲＵは、送信される必要がある情報ビットもしくは符号化ビットの数（または使用する必要があるＰＵＣＣＨフォーマット）に対応するＰＵＣＣＨリソースを選択することができる。

【0264】

例においては、フィードバックグループの、可能なゼロ電力送信を用いるサブリソースへの固定されたマッピングを使用することができる。ＷＴＲＵは、いずれかのＰＤＳＣＨと関連付けることができるダウンリンク制御シグナリングと、フィードバックグループと関連付けられたインデックスまたは順序との組合せに基づいて、このフィードバックグループ（またはフィードバックグループの組合せ）の送信のために使用されるリソースまたはサブリソースを決定することができる。例えば、ＡＲＩフィールドから受け取られるインデックスと、フィードバックグループに対するインデックスとの組合せは、このフィードバックグループの送信のためのリソースまたはサブリソースを決定することができる。例えば、ＡＲＩの特定の値は、２つの連続するＲＢにまたがるリソースを示すことができ、送信される２つのフィードバックグループが存在することができる。このケースにおいては、第１のフィードバックグループのために使用されるサブリソースは、２つのＲＢのうちの第１の方とすることができ、第２のフィードバックグループのために使用されるサブリソースは、２つのＲＢのうちの第２の方とすることができる。

【0265】

フィードバックグループのための送信が生じる必要がないケースにおいては、ＷＴＲＵは、対応するサブリソース上において、ゼロ電力を用いて送信することができる（すなわち、送信しないことができる）。いくつかのソリューションにおいては、ＷＴＲＵは、対応するフィードバックグループのための送信が生じる必要がない場合でさえも、ＷＴＲＵによって送信される信号が連続するＲＢにまたがることを保証するために、サブリソース上において送信を行うことができる。ＷＴＲＵは、例えば、サブリソースがＲＢ上に存在し、非ゼロ電力送信が隣接するＲＢの両方の上において生じる場合に、そのような送信を実行することができる。このケースにおいては、例えば、ＷＴＲＵが、フィードバックグループのすべての対応する送信に対して「ＮＡＣＫ」または「ＤＴＸ」を報告するかのように、ＷＴＲＵは、事前決定されたルールに従って、対応するフィードバックグループについての情報をエンコードすることができる。

【0266】

例においては、フィードバックグループの、可能な表示を有するリソースへの柔軟なマッピングを使用することができる。特定のフィードバックグループの送信のために使用されるリソースは、サブフレーム内において送信されるフィードバックグループのサブセット（または組合せ）に基づいて、決定することもできる。このソリューションは、すべてのフィードバックグループの送信のために使用されるリソースの組合せが、連続するリソースブロックにまたがる信号など、望ましい特性を有する信号をもたらすことを保証することができる。例えば、（＃１、＃２、＃３、および＃４というラベルが付された）４つの定義されたフィードバックグループが存在することができ、ダウンリンク制御シグナリング（例えば、ＡＲＩ）から受け取られる値は、（＃ａ、＃ｂ、＃ｃ、および＃ｄというラベルが付された）４つの連続するリソースブロックにまたがるリソースのセットを決定することができる。すべての４つのフィードバックグループが送信されるとき、グループ＃１、＃２、＃３、＃４は、それぞれ、リソース＃ａ、＃ｂ、＃ｃ、＃ｄにマッピングすることができる。他方、グループ＃１、＃２、＃４だけが送信される場合、これらのグループは、連続したリソースブロックだけが使用されるように、リソース＃ａ、＃ｂ、＃ｃにマッピングすることができる。与えられたリソース上において送信されるフィードバックグループの識別情報について、ネットワークに対して可能な曖昧性が存在するとき、ＷＴＲＵは、リソース＃ｃ上において送信されるフィードバックグループが＃３か、それとも＃４かを示すビットなど、フィードバックグループの表示を少なくともこのリソース内に含めることができる。そのような表示は、フィードバックグループからの情報ビットと共同で、または別々にエンコードすることができる。

【0267】

例においては、フィードバックグループインジケータの送信を実行することができる。いくつかのソリューションにおいては、ＷＴＲＵは、受信機における復号を容易にするために、サブフレーム内において送信されるフィードバックグループのサブセットの少なくとも１つの表示を送信することができる。そのような表示は、以下においては「フィードバックグループ表示」（ＦＧＩ）と呼ばれることがある。ＦＧＩの値は、フィードバックグループの有効な可能な組合せのセットのうちの１つを示すことができ、コードブックサイズを含む。各可能なＦＧＩ値と、フィードバックグループの組合せとの間のマッピングは、より高位のレイヤによって提供すること、または事前定義することができる。マッピングは、情報ビットの総数Ｂ、および／またはサブフレーム内における送信のためのペイロードサイズＢ’に依存することができる。いくつかのソリューションにおいては、ＦＧＩは、ＰＵＣＣＨのための送信フォーマットの表示からなることができる。

【0268】

ソリューションにおいては、ＦＧＩは、他のフィードバックビットとは別個に処理し、特定の物理リソースにマッピングすることができる。例えば、ＦＧＩビットは、エンコードし、変調し、拡散し、リソースブロックの特定のサブキャリアおよび／またはスロットにマッピングすることができる。このソリューションは、受信機が、最初にＦＧＩを復号することによって、最初に情報ビットの数を決定することができるので、受信機における複雑さを過度に増すことなく、情報ビットの複数の可能な数（Ｂ）をサポートすることができるという利益を有する。

【0269】

ソリューションにおいては、ＦＧＩビットは、（おそらくは、符号化、変調、拡散、および物理リソースへのマッピングのうちの少なくとも１つを含む）後続の共同処理に先立って、他のフィードバックビットに連結（し、おそらくはインターリーブ）することができる。このソリューションは、ペイロードサイズの可能なセットが受信機において知られている場合に、特に有益であることができる。

【0270】

ソリューションにおいては、ＦＧＩビットは、フィードバックビットのセットに追加されるＣＲＣをマスクするために、使用することができる。このソリューションは、誤り検出を通して高められた信頼性を提供しながら、同時に、紛失したＰＤＳＣＨ割り当てまたは誤検出されたＰＤＳＣＨ割り当てに起因するフィードバック送信における誤りの可能性を低減させるという利益を有する。受信機において、ネットワークは、与えられたペイロードサイズ（または可能なペイロードサイズのセット）を仮定した復号、および送信されたＰＤＳＣＨを与えられた場合に予期されるＦＧＩ値によってマスクされたＣＲＣが有効であるかどうかのチェックを行うように試みることができる。

【0271】

ソリューションにおいては、フィードバックグループの送信のために使用されるリソースは、おそらくは、（ＡＲＩなどの）ダウンリンク制御シグナリングおよびより高位のレイヤから受け取られる情報と組み合わされた、ＦＧＩの関数とすることができる。このソリューションは、受信機が、フィードバック情報をそれから復号することができるリソースから、ＦＧＩを決定することができるので、暗黙的なＦＧＩシグナリングメカニズムを提供する。

【0272】

例においては、電力設定を使用することができる。ＷＴＲＵは、少なくとも、経路損失推定ＰＬ_C、構成された最大電力ＰＣＭＡＸ．Ｃ、ＰＯ＿ＰＵＣＣＨ、ＤｅｌｔａＦ＿ｐｕｃｃＨ、およびＤｅｌｔａＴｘＤなど、より高位のレイヤによって提供されるパラメータ、受け取られたＴＰＣコマンドｇ（ｉ）に依存するパラメータ、ならびに／または以下で説明されるようにサブフレームベースで変化することができるパラメータの関数である電力オフセットｈに基づいて、（ＰＵＣＣＨ送信など、フィードバック情報だけを含む送信を含む）フィードバック情報を含む送信に対して適用される電力を決定することができる。

【0273】

いくつかのソリューションにおいては、電力オフセットは、おそらくは、連続したＲＢ上における送信を保証するために送信されるフィードバックグループを含む、送信のために選択されるフィードバックグループのサブセットに基づいた、情報ビットの総数Ｂ、送信のために選択されたサブセットの中におけるフィードバックグループの情報ビットの最大数、受信されたＰＤＳＣＨに基づいたトランスポートブロックの数、各フィードバックグループ内における受信されたＰＤＳＣＨに基づいたトランスポートブロックの数、またはフィードバックグループの中におけるそれの最大値、構成に基づいて受信することができるトランスポートブロックの最大数、サブフレーム内におけるフィードバック情報の送信のためのペイロードサイズＢ’、サブフレーム内において利用される符号化のタイプ（リード－マラー、畳み込み、ターボ）、ＣＲＣおよび／またはＦＧＩが送信されるフィードバックビットのセットに追加されるかどうか、多重化に先立って独立にエンコードされるビットのサブセットの数Ｍ、受信されたＰＤＳＣＨに対応したものに制限されること、または制限されないことがある、独立にエンコードされるビットの各サブセット内において送信されるビットの数、またはすべてのサブセットの中におけるそれの最大値のうちの少なくとも１つの関数とすることができる。

【0274】

電力オフセット関数は、利用される符号化のタイプに応じた、またはより一般的に、使用される送信フォーマットに応じた、異なるパラメータに依存することができる。例えば、符号化がリード－マラーなどのブロックコードに基づくケースにおいては、電力オフセットは、サブフレーム内における受信されたＰＤＳＣＨに基づいたトランスポートブロックの数、またはおそらくは、独立にエンコードされるサブセットの中におけるそれの最大数の関数とすることができる。他方、符号化が畳み込みコードまたはターボコードに基づくケースにおいては、電力オフセットは、構成に基づいて受信することができるトランスポートブロックの最大数の関数とすることができる。このソリューションは、小さいコードブックに基づいたブロック符号化が使用されるケースにおいては、受信機は、（スケジュールされたＰＤＳＣＨに基づいて）ＮＡＣＫになるように設定されることが知られている情報ビットについての知識を利用して、正しい検出の可能性を改善することができるので、適切であることができる。

【0275】

レガシシステムにおいては、ＨＡＲＱ－ＡＣＫのためのレイヤ当たりの符号化された変調シンボルの数Ｑ’は、ＨＡＲＱ－ＡＣＫのための情報ビットの数、最初のＰＵＳＣＨ送信のサブキャリアの数、および係数

【0276】

【数9】

【0277】

に比例するが、ＰＵＳＣＨのサブキャリアの数の４倍よりも大きくない値になるように設定することができる。符号化、インターリーブ、多重化、およびより高位のレイヤのデータのマッピングは、ＨＡＲＱ－ＡＣＫの存在または非存在とは独立に実行される。ＨＡＲＱ－ＡＣＫが送信されるとき、それの符号化変調シンボルは、あるリソースエレメント内においてより高位のレイヤのデータのために使用されるシンボルを上書きすることができ、パンクチャリングに起因するより高位のレイヤのデータについての性能悪化を穏当なものにする。

【0278】

多数のＨＡＲＱ－ＡＣＫビットを送信する必要があるとき、例えば、ＰＵＳＣＨのために非常に大きい帯域幅を有することが可能でないことがある、電力制限されたシナリオにおいて、ＰＵＳＣＨのサブキャリアの数の４倍という限界は、不十分になることが可能なことがある。いくつかのソリューションにおいては、ＰＵＳＣＨ割り当てのサブキャリアの数の４倍という限界は、ＨＡＲＱ－ＡＣＫのための変調シンボルをＰＵＳＣＨ上の追加のリソース（例えば、時間シンボル）にマッピングすることができるように、引き上げることができる。

【0279】

いくつかのソリューションにおいては、過度なパンクチャリングに起因する性能悪化を防止するために、ＷＴＲＵは、ＨＡＲＱ－ＡＣＫまたはそれの最小数のビットの送信が原因で、少なくともいくつかのリソースエレメントが、より高位のデータのために利用可能でないことを考慮して、より高位のレイヤのデータを処理することができる。より具体的には、以下のパラメータまたは手順に影響を及ぼすことができる。より高位のレイヤのデータのトランスポートブロックサイズに影響を及ぼすことができる。例えば、伝達された変調および符号化方式（ＭＣＳ）ならびに（リソースブロック内における）ＰＵＳＣＨ割り当てのサイズの関数としてのトランスポートブロックサイズの計算は、ＨＡＲＱ－ＡＣＫの送信が原因で利用可能でない時間シンボルの数を考慮することができる。例えば、ＨＡＲＱ－ＡＣＫのために必要とされる変調シンボルの数が、ＰＵＳＣＨのサブキャリアの数の４倍を超えるケースにおいては、ＨＡＲＱ－ＡＣＫを送信する必要があることがあるとき、（ＤＭ－ＲＳのために使用されない）時間シンボルの少なくとも１／３は、より高位のレイヤのデータのために利用可能でないという事実を考慮して、トランスポートブロックサイズは、係数（１２－４）／１２＝２／３だけスケールダウンすることができる。ＰＵＳＣＨのためのＲＥにマッピングする手順は、ＨＡＲＱ－ＡＣＫのためのシンボルがその上にマッピングされるＲＥのサブセットまたはすべてが、ＰＵＳＣＨのためのシンボルをその上にマッピングすることができるＲＥのセットから除外されるように、変更することができる。例えば、ＨＡＲＱ－ＡＣＫのためのシンボルをその上にマッピングすることができる、最初の４つの時間シンボル上のＲＥは、除外することができる。

【0280】

ＷＴＲＵは、より高位のレイヤのデータが、以下の条件のうちの少なくとも１つに基づいて、上述したことに従って処理されると決定することができる。ＷＴＲＵは、より高位のレイヤのデータが、受信されたＰＤＣＣＨ／Ｅ－ＰＤＣＣＨからの明示的なシグナリングに従って処理されると決定することができる。受信されたＰＤＣＣＨ／Ｅ－ＰＤＣＣＨは、関連するＰＵＳＣＨのためのアップリンクグラントを含むＰＤＣＣＨ／Ｅ－ＰＤＣＣＨ、またはおそらくはＰＤＳＣＨおよび／もしくはＰＵＳＣＨ送信のセットについての情報を示す、別の受信されたＰＤＣＣＨ／Ｅ－ＰＤＣＣＨとすることができる。ＤＣＩの新しいまたは既存のフィールドをこの目的のために使用することができる。このソリューションは、ダウンリンク割り当ての紛失に対してロバストネスがあるという利益を有する。ＷＴＲＵは、より高位のレイヤのデータが、ＰＵＳＣＨ内において送信されるＨＡＲＱ－ＡＣＫ情報ビットの数に従って処理されると決定することができる。ＷＴＲＵは、より高位のレイヤのデータが、ＨＡＲＱ－ＡＣＫのためのシンボルの数が、ＰＵＳＣＨ送信のサブキャリアの数の４倍など、閾値を超えたかどうかに従って処理されると決定することもできる。

【0281】

例においては、ＷＴＲＵは、ＵＣＩ送信のためのアップリンクリソースを選択することができる。例においては、ＷＴＲＵは、以下の状況において、すなわち、おそらくは、複数のタイプの物理チャネル、例えば、ＰＵＳＣＨおよびＰＵＣＣＨの両方が、ＵＣＩの送信のために利用可能である状況、おそらくは、複数のタイプのＵＣＩ、例えば、ＨＡＲＱ－ＡＣＫ、ＣＳＩ、もしくはＳＲが、送信のために利用可能である状況、および／またはおそらくは、キャリア上のいくつかのセルが、免許不要周波数バンド（例えば、ＬＡＡ）において動作する状況において、送信ＵＣＩのためのリソースを決定することができる。

【0282】

例においては、ＷＴＲＵは、ＰＵＳＣＨおよびＰＵＣＣＨの間にＵＣＩを分割することができる。１つの例示的な方法においては、ＷＴＲＵは、ＵＣＩの第１の量が、第１のタイプの送信、例えば、ＰＵＣＣＨに適用可能とすることができ、一方、第２の量が、第２のタイプの送信（例えば、ＰＵＳＣＨ）に適用可能とすることができると決定することができる。おそらくは、そのような方法は、セルのグループ別に、例えば、ＰＵＣＣＨグループまたはセルグループ（例えば、ＣＧ）に対して、適用可能とすることができる。

【0283】

例えば、ＵＣＩの第１の量は、特定のタイプのＵＣＩ、例えば、ＨＡＲＱ Ａ／Ｎビットに対応することができる。例えば、ＵＣＩの第２の量は、他のタイプのＵＣＩ、例えば、ＣＱＩ、プリコーディング行列インジケータ（ＰＭＩ）、またはＲＩビットなどのＣＳＩに対応することができる。

【0284】

ＷＴＲＵがＵＣＩを送信すると予期されるサブフレーム内においては、ＷＴＲＵは、少なくとも１つのＰＵＳＣＨリソースが、関連するサブフレームのために利用可能であるかどうかを決定することができる。ＷＴＲＵは、それが、与えられたサービングセルまたはセルのグループについて、ＰＵＣＣＨおよびＰＵＳＣＨ上における同時送信のために構成されているかどうかも決定することができる。

【0285】

ＷＴＲＵが、ＰＵＳＣＨおよびＰＵＣＣＨ上において同時に送信を実行することができる（例えば、リソースが利用可能であり、ＷＴＲＵがそのような動作のために構成されている）場合、ＷＴＲＵは、第１のタイプのＵＣＩ、例えば、ＨＡＲＱ－ＡＣＫを、ＰＵＳＣＨ送信上において送信することができ、一方、第２のタイプのＵＣＩ、例えば、ＣＳＩを、ＰＵＣＣＨ送信上において送信することができると決定すること、またはその逆を行うことができると決定することができる。ＷＴＲＵは、与えられたタイプのＵＣＩ（例えば、ＨＡＲＱ－ＡＣＫ）の第１の部分を、ＰＵＳＣＨ送信上において送信することができ、一方、第２の部分を、ＰＵＣＣＨ送信上において送信することができることを、以下のうちの少なくとも１つ、すなわち、例えば、本明細書において説明されるのと類似した方法を使用する、ダウンリンク制御シグナリングの受信（そのようなシグナリングは、ＵＣＩが分割され、ＰＵＳＣＨおよびＰＵＣＣＨ送信を使用することを示すことができる）と、例えば、本明細書において説明されるのと類似した方法を使用する、ダウンリンク制御シグナリングの受信（そのようなシグナリングは、ＵＣＩ要求を含むことができ、示されたＵＣＩは、第１の特定のリソースおよび／もしくは送信（例えば、ＰＵＣＣＨ、もしくはおそらくは、動的なスケジューリングによって、例えば、本明細書において説明されるそれに従って示されるリソース）に回送することができ、一方、他のフィードバックは、第２の特定のリソースおよび／もしくは送信（例えば、ＰＵＳＣＨ）に回送すること（もしくはおそらくは、ドロップすること）ができ、またはその逆とすることができる）と、ＰＵＳＣＨ割り当て（例えば、グラントのサイズ）が、（おそらくは構成可能な）閾値よりも小さい（またはそれに等しい）ことと、（非ＵＣＩ）ペイロードビットの数と、関連するＰＵＳＣＨ送信のためのＵＣＩビットの数との結果的な比が、ＵＣＩビットの関連する量についての特定の閾値以上であることと、（非ＵＣＩ）ペイロードビットの数と、関連するＰＵＳＣＨ送信のためのＨＡＲＱ Ａ／Ｎビットの数との結果的な比が、特定の閾値以上であることと、ＵＣＩタイプおよび関連するＰＵＳＣＨ送信についてのレイヤ当たりの変調シンボルの数Ｑ’が、閾値を超えること（例えば、閾値は、ＨＡＲＱ－ＡＣＫのケースにおけるＰＵＳＣＨのサブキャリアの数の４倍とすることができる）とのうちの少なくとも１つに従って決定することもできる。

【0286】

上述の条件のうちの少なくとも１つが満たされたとき、ＷＴＲＵは、各チャネル上において送信されるＵＣＩビットの一部を、以下のうちの少なくとも１つに従って決定することができる。ＷＴＲＵは、最大で関連するＵＣＩについて必要とされるシンボルの数まで、関連するＰＵＳＣＨ送信における第１のタイプのＵＣＩ（例えば、ＨＡＲＱ－ＡＣＫビット）を含む情報に従って、一部を決定することができる。ＷＴＲＵは、ＰＵＣＣＨ上における送信を使用して、（例えば、第２のタイプの）残りのＵＣＩ（例えば、ＣＳＩビット）を送信することができる。また、ＷＴＲＵは、ＰＵＳＣＨ割り当て（例えば、グラントのサイズ）に基づいて、ＰＵＳＣＨ送信におけるＵＣＩビットの数を含む情報に従って、一部を決定することができ、残りのＵＣＩビットは、その後、異なる送信を使用して送信することができる。例えば、ＷＴＲＵは、サブキャリアの数のＮ倍など、ＰＵＳＣＨのサイズに依存することができる、多くても高々閾値までのレイヤ当たりの変調シンボルの数Ｑ’をもたらす、ＨＡＲＱ－ＡＣＫビットの数を決定することができる。別の例においては、（おそらくは与えられたタイプの）ＰＵＳＣＨ送信におけるＵＣＩビットの数は、ゼロになるように設定することができ、すべてのビットは、異なる送信上において送信することができる。

【0287】

例においては、ＷＴＲＵは、複数のＰＵＣＣＨの間にＵＣＩを分離することができる。１つの例示的な方法においては、ＷＴＲＵは、ＵＣＩの第１の量が、第１のサービングセル（例えば、ＰＣｅｌｌ）のリソース上における第１のタイプの送信、例えば、ＰＵＣＣＨに適用可能とすることができ、一方、第２の量が、第２のサービングセル（例えば、ＰＵＣＣＨを用いるように構成されたＳＣｅｌｌ）のリソース上における第１のタイプの送信（例えば、ＰＵＣＣＨ）に適用可能とすることができると決定することができる。おそらくは、そのような方法は、セルのグループ別に、例えば、ＰＵＣＣＨグループもしくはセルグループ（例えば、ＣＧ）に対して、またはＰＵＣＣＨグループもしくはＣＧにわたって適用可能とすることができる。

【0288】

例えば、ＵＣＩの第１の量は、特定のタイプのＵＣＩ、例えば、ＨＡＲＱ Ａ／Ｎビットに対応することができる。例えば、ＵＣＩの第２の量は、他のタイプのＵＣＩ、例えば、ＣＱＩ、ＰＭＩ、またはＲＩビットなどのＣＳＩに対応することができる。そのようなケースにおいては、ＷＴＲＵは、第１のＵＣＩタイプをその上において送信するＰＵＣＣＨを用いるセルを、以下のうちの少なくとも１つ、すなわち、例えば、本明細書において説明されるのと類似した方法を使用する、ダウンリンク制御シグナリングの受信（そのようなシグナリングは、ＵＣＩが分割され、異なるＰＵＣＣＨ送信を使用すること、および第１のタイプのＵＣＩは、特定のセル（例えば、制御シグナリングがその上において受信されたセル）のリソースを使用して送信されるべきであることを示すことができる）と、例えば、本明細書において説明されるのと類似した方法を使用する、ダウンリンク制御シグナリングの受信（そのようなシグナリングは、ＵＣＩ要求を含むことができ、示されたＵＣＩは、第１の特定のＰＵＣＣＨリソースおよび／もしくはＰＵＣＣＨ送信（例えば、おそらくは、例えば、本明細書において説明されるような、動的なスケジューリングによって示されるリソース）に回送することができ、一方、他のフィードバックは、（例えば、ＰＵＣＣＨリソースを決定するための他の方法に従って）第２の特定のＰＵＣＣＨリソースおよび／もしくはＰＵＣＣＨ送信に回送することができ、またはその逆とすることができる）と、常時ＰＣｅｌｌ（もしくは、ＭＣＧのための場合はＰＳＣｅｌｌ）、またはあるいは、常時ＳＣｅｌｌとすることと、ＷＴＲＵが、十分な容量を有する（および／または最良の予期される送信性能を有する）ＰＵＣＣＨを選択することと、ＷＴＲＵが、それが最も低い経路損失推定を有するセルを選択することと、（同時ＰＵＳＣＨ＋ＰＵＣＣＨ送信がＷＴＲＵのために構成されている場合に限って）ＷＴＲＵが、それがＰＵＳＣＨ送信のためのリソースも有するセルを選択することと、半静的な構成に従うこととのうちの少なくとも１つに従って決定することができる。

【0289】

例においては、ＷＴＲＵは、複数が利用可能であるときに、単一のＰＵＣＣＨを選択することができる。可能な例においては、ＷＴＲＵは、ＷＴＲＵが異なるＰＵＣＣＨ上において同時に送信を実行することができる場合に限って、複数が利用可能であるときに、単一のＰＵＣＣＨを選択することができる。別の例においては、ＷＴＲＵは、ＰＵＣＣＨを用いるサービングセルを、以下のうちの少なくとも１つ、すなわち、ＷＴＲＵが、上述のものに類似する受信された制御シグナリングに基づいてセルを選択することと、例えば、本明細書において説明されるのと類似した方法を使用する、ダウンリンク制御シグナリングの受信（そのようなシグナリングは、例えば、本明細書において説明されるものに従って、ＵＣＩ送信のための動的なスケジューリングを含むことができる）と、ＷＴＲＵが、十分な容量を有する（および／または最良の予期される送信性能を有する）ＰＵＣＣＨを選択することと、ＷＴＲＵが、それが最も低い経路損失推定を有するセルを選択することと、半静的な構成に従うこととのうちの少なくとも１つに従って決定することもできる。いくつかの例においては、ＷＴＲＵは、アクティブ化された状態にあるセルだけを考慮することができる。

【0290】

ＷＴＲＵは、少なくとも１つのＳＣｅｌｌ上において複数のＰＵＣＣＨリソースを用いるように構成することができる。おそらくは、ＷＴＲＵは、それが実行することができる同時アップリンク送信の数についての制限を有するように構成することができる。そのような制限は、（例えば、すべての構成されたセルもしくはＣＧについてのすべての送信を含む）ＷＴＲＵのすべての送信に対するもの、ＷＴＲＵの構成の与えられたＣＧのすべての送信に対するもの、特定のタイプのすべての物理的送信に対するもの（例えば、ＰＵＣＣＨ送信だけに対するもの）、および／またはあるタイプのすべての送信に対するもの（例えば、ＵＣＩ送信だけに対するもの）とすることができる。

【0291】

そのようなケースにおいては、ＷＴＲＵは、本明細書において説明されるソリューションに従って、それがＵＣＩの送信のためにどのアップリンク送信を使用することができるかを決定することができる。例においては、ＷＴＲＵは、アップリンク回送を、制限の関数として決定することができる。

【0292】

１つの方法においては、ＷＴＲＵは、ＵＣＩの送信をどのように回送するかを、同時アップリンク送信の数に（およびおそらくは、同時ＰＵＣＣＨ送信だけに）適用可能な制限の関数として、決定することができる。例えば、ＷＴＲＵは、ＵＣＩの少なくともいくつかの送信が与えられたサブフレーム内において実行されるべきであることを、以下のうちの少なくとも１つ、すなわち、ＷＴＲＵが、ＰＵＣＣＨ上において高々数Ｘの送信を実行することができること（例えば、ＷＴＲＵは、以下のうちの少なくとも１つ、すなわち、ＰＵＣＣＨ送信のための必要とされる送信電力の降順と、対応するキャリアについての推定される経路損失基準の昇順と、ＰＵＣＣＨ容量の降順とのうちの少なくとも１つに従って、ＰＵＣＣＨリソースを用いる適用可能な数Ｘのサービングセルを決定することができる）と、ＷＴＲＵが、セルの与えられたグループについて、ＰＵＣＣＨ上において高々数Ｘの送信（例えば、２つ以上のＰＵＣＣＨリソースを使用してグループを構成することができる場合、ＰＵＣＣＨグループ当たり高々１つのＰＵＣＣＨ送信）を実行することができることとのうちの少なくとも一方に従って（おそらくは、与えられたＣＧについて）決定することができる。ＷＴＲＵは、おそらくはセルのグループ別に適用される先のケースのためのものと類似の方法を使用することができる。

【0293】

ＷＴＲＵは、免許不要周波数バンドにおいて動作するキャリアを使用する少なくとも１つのサービングセル（これ以降「ＬＡＡセル」）を用いるように構成することができる。以下のソリューションは、ＷＴＲＵが、生成されたＵＣＩのうちの少なくともいくつか（またはすべて）の送信のためにどのアップリンクリソースを使用すべきかを、アクセスのタイプ、バンドのタイプ（例えば、免許要もしくは免許不要）、ＵＣＩ自体のタイプ（例えば、ＨＡＲＱ Ａ／Ｎ、ＣＱＩ、もしくはＰＭＩ／ＲＩなど）、および／または（例えば、本明細書において説明されるシグナリング態様と類似した）受信された制御シグナリングの関数として、どのように決定することができるかについて説明する。

【0294】

例示的な方法などの例においては、ＷＴＲＵは、免許要バンドのサービングセルのリソース上においてＵＣＩを回送することができる。ＷＴＲＵは、免許要動作のために使用される周波数バンドにおけるキャリアと関連付けられた、ＷＴＲＵの構成のサービングセルのアップリンクリソースを使用して、適用可能なＵＣＩを送信することができると決定することができる。ＷＴＲＵは、ＷＴＲＵがＬＡＡセルのアップリンクリソースに対してスケジュールされたアップリンク送信を有するかどうかとは独立に、そのような決定を行うことができる。あるいは、ＷＴＲＵは、ＬＡＡセルについてのＰＵＳＣＨ送信が存在しないときに限って、ＷＴＲＵがそのような回送決定を行うことができるように、（利用可能な場合は）ＬＡＡセルのＰＵＳＣＨ送信上においてＵＣＩの少なくとも一部を送信することができる。

【0295】

そのような適用可能なＵＣＩは、以下のうちの少なくとも１つに従って決定することができる。ＷＴＲＵは、ＬＡＡセルのリソースを使用して、いずれのＵＣＩも送信することができない。例えば、ＷＴＲＵは、ＷＴＲＵがＬＡＡセルについてのＰＵＳＣＨ送信のためのリソースを有するかどうかとは独立に、ＬＡＡ動作に関連するいずれのＵＣＩも、免許要領域内におけるキャリアと関連付けられた送信に回送することができる。別の例においては、ＷＴＲＵは、利用可能なときは、ＬＡＡセルのリソースを使用して、ＬＡＡセルと関連付けられたＵＣＩだけを送信することができ、それ以外は、ＵＣＩは、免許要領域内におけるセルのリソースに回送することができる。例えば、ＷＴＲＵは、そのような送信が利用可能である（例えば、ＰＵＳＣＨ送信がスケジュールされる）場合は、ＬＡＡセルに関連するＵＣＩだけを、ＬＡＡセルのリソース上における送信に回送することができる。さらなる例においては、ＷＴＲＵは、上述のいずれかを実行することができるが、それは、特定のタイプのＵＣＩの送信のためだけである。例えば、ＷＴＲＵは、免許要領域内におけるセルのリソースだけを使用して、免許不要領域内における動作に関連する（より時間に敏感な）ＨＡＲＱ Ａ／Ｎフィードバックを送信することができ、そのようなケースにおいては、他のタイプのＵＣＩは、（利用可能な場合は）免許不要領域内におけるＰＵＳＣＨ送信を使用して、または（そうではない場合は）免許要領域内におけるリソースを使用して、送信することができる。

【0296】

さらなる例においては、適用可能なＵＣＩは、例えば、本明細書において説明されるのと類似した方法を使用して、ダウンリンク制御シグナリングの受信によって決定することができる。そのようなシグナリングは、ＵＣＩ要求を含むことができ、示されるＵＣＩは、制御シグナリングの受信時におけるＨＡＲＱプロセスのステータスに基づいて生成することができ、例えば、ＵＣＩは、それぞれのＨＡＲＱプロセスの直近のステータスと関連付けることができ、同時に受信された、および／またはそのような制御シグナリングの受信と関連付けられた時間間隔の間に受信された送信とは必ずしも関連付けることができるとは限らない。加えて、ＷＴＲＵは、そのようなセルと関連付けられたＵＣＩフィードバックについての、本明細書において説明されるものと類似した、ＵＣＩスケジューリング情報を受信することができる。

【0297】

ＵＣＩ送信のためのアップリンクリソースを決定するための方法が、本明細書において説明される。ＷＴＲＵが、少なくともいくつかのＵＣＩのためにどのリソースを使用すべきかを、ダウンリンク制御情報、例えば、動的スケジューリングに基づいて、少なくとも部分的に決定することができるような方法が、本明細書において説明される。

【0298】

ＤＣＩ（ＵＣＩ）を用いるダウンリンク制御シグナリングのための方法が、本明細書において説明される。例においては、ＷＴＲＵは、ＵＣＩについての動的スケジューリング情報を受信することができる。そのような動的スケジューリング情報は、ＤＣＩを使用して、ＰＤＣＣＨ上において受信することができる。そのようなスケジューリング情報は、（例えば、特定の制御情報を参照する１つまたは複数のインデックスを使用して）既存のＤＣＩフォーマット内に、または専用ＤＣＩフォーマット内に含むことができる。そのようなＤＣＩは、本明細書においては、ＤＣＩ（ＵＣＩ）とさらに呼ばれることがある。

【0299】

動的スケジューリングは、ＵＣＩ要求および／またはリソース割り当てを含むことができる。そのようなＤＣＩ（ＵＣＩ）は、（例えば、与えられた送信内にどのＵＣＩを含めるかを、ＷＴＲＵがそれによって決定することができる）ＵＣＩ要求と、（例えば、動的にスケジュールされた情報を使用して、どのアップリンクリソースがどのようにして適用可能なＵＣＩを送信すべきかを、ＷＴＲＵがそれによって決定することができるＵＣＩスケジューリング情報とのうちの少なくとも一方を示すことができる。

【0300】

例においては、ＤＣＩ（ＵＣＩ）は、ＵＣＩ要求を示すことができる。ＵＣＩ要求は、送信のためにどのＵＣＩを生成すべきかを決定するために使用することができる。例においては、ＷＴＲＵは、ＵＣＩ送信内にどのフィードバックを含めるべきかを、ＵＣＩ要求の関数として、決定することができる。

【0301】

さらに、ＵＣＩ要求は、より小さいＵＣＩペイロードを生成するために使用することができる。例においては、ＵＣＩ要求は、要求されたＵＣＩの送信を優先させ、おそらくは、他のＵＣＩをドロップする（またはそれの優先順位を下げる）ために使用することができる。

【0302】

また、ＵＣＩ要求は、ＵＣＩのサブセットを、スケジュールされているかどうかに関わらず、特定のリソースに回送するために使用することができる。例においては、ＵＣＩ要求は、示されたＵＣＩを、例えば、ＵＣＩスケジューリング情報によって示されるリソースなど、特定のアップリンクリソースに割り当てるために使用することができる（適用可能な場合、本明細書における例を参照）。

【0303】

ＵＣＩ要求の内容は、以下の情報のうちの少なくとも１つ、すなわち、ＵＣＩのタイプ、サービングセル識別情報、ダウンリンクＨＡＲＱプロセス識別情報、ＵＣＩサイズ削減方法、フィードバックグループ、および非定期的な要求のうちの１つを含むことができる。例えば、ＵＣＩ要求の内容は、ＵＣＩのタイプを含むことができる。ＷＴＲＵは、例えば、単独のＨＡＲＱ Ａ／Ｎ、またはいずれか適用可能なＣＳＩと組み合わされたＨＡＲＱ Ａ／Ｎなど、どのタイプのＵＣＩをＵＣＩ送信内に含むかを決定することができる。例えば、タイプは、例えば、ＤＣＩ（ＵＣＩ）フォーマット内のフィールド配置に基づいて、ＤＣＩ（ＵＣＩ）のフォーマットに対して暗黙的とすることができる。例えば、ＤＣＩ（ＵＣＩ）フォーマットは、ＣＳＩ要求のための１つのフィールドと、ＨＡＲＱ Ａ／Ｎ要求のための１つのフィールドとを、（例えば、別々のビットマップフィールドとして）含むことができる。

【0304】

別の例においては、ＵＣＩ要求の内容は、サービングセル識別情報を含むことができる。ＷＴＲＵは、要求がそれに対して適用可能であるサービングセルの識別情報を決定することができ、例えば、関連するＵＣＩについての要求は、例えば、伝達された識別情報によって示されるような、ＷＴＲＵの構成のすべての構成された（および／もしくはまたおそらくはアクティブな）サービングセルに、またはそれのサブセットに適用可能とすることができる。

【0305】

例えば、識別情報は、より高位のレイヤによって構成されたサービングセル識別情報に対応することができ、（例えば、構成されたグループ化に基づいた、ＰＵＣＣＨ送信のためのグループ化－ＰＵＣＣＨグループに基づいた、特別なセル－例えば、ＭＣＧのＰＣｅｌｌまたはＳＣＧのＰＳＣｅｌｌなどだけについてのタイミングアドバンスグループ化（ＴＡＧ）に基づいた）セルのグループの一部であるセルに対応することができる。そのような識別情報は、クロスキャリアスケジューリングのために使用されるキャリアフィールドインジケータ（ＣＦＩ）に基づくことができる。

【0306】

例においては、ＵＣＩ要求は、動的にスケジュールされたＰＵＳＣＨ上のセルのサブセットだけについてのＣＳＩ、レガシによるＨＡＲＱを示すことができる。例えば、ＵＣＩ要求は、サービングセルのサブセットについての、例えば、サービングセルＩＤ１および３についてのＣＳＩだけが要求されていることを示すことができる。そのような表示は、表９に示される例に類似したビットマップ配置を使用して、受け取ることができる。ＷＴＲＵは、その後、それらのセルについてのＣＳＩを、アップリンク送信のための適用可能なＵＣＩとともに含めることができる。

【0307】

ＷＴＲＵは、そのようなアップリンク送信を、例えば、動的にスケジュールを使用して（例えば、おそらくはＰＵＳＣＨ上において）実行することができる。例においては、ＣＳＩについてのそのようなＵＣＩ要求シグナリングは、定期的なＣＳＩ（例えば、定期的なＣＱＩ報告）にだけ、または好ましくは、非定期的なＣＳＩを含む任意のタイプのＣＳＩに対して適用可能とすることができる。表９は、ＣＳＩフィードバック要求のためのビットマップ配置の例である。

【0308】

【表9】

【0309】

さらなる例においては、ＵＣＩ要求の内容は、ダウンリンクＨＡＲＱプロセス識別情報を含むことができる。ＷＴＲＵは、例えば、要求されたＵＣＩのタイプがＨＡＲＱフィードバックであるときに、要求がそれに対して適用可能であるＨＡＲＱプロセスの識別情報を決定することができる。例えば、制御情報は、例えば、ＷＴＲＵのすべてのＨＡＲＱプロセスのビットマップ表現を、ＷＴＲＵの構成の各（またおそらくはアクティブ化された）セルについての特定の順序で、例えば、それぞれのサービングセル識別情報に基づいた、例えば、昇順のすべての適用可能なセルについてのプロセスＩＤの昇順で、使用することができる。表１０は、ＨＡＲＱフィードバック要求のためのビットマップ配置の例である。

【0310】

【表10】

【0311】

例においては、すべての適用可能なセルについての特定のプロセスだけについてのＨＡＲＱフィードバックを含むことができる。例えば、ＷＴＲＵは、ＵＣＩ要求の受信から、それが、表１０に示されるように、サービングセルＩＤ＝０についてはプロセスｘ１、ｘ３、ｘ７についての、サービングセルＩＤ＝１についてはｘ０、ｘ４についての、およびサービングセルＩＤ＝３についてはｘ０、ｘ２、ｘ３、ｘ４、ｘ５についてのＨＡＲＱフィードバックを含むと決定することができる。そのようなケースにおいては、ＷＴＲＵは、アップリンクリソース上における送信のために、１０ビットのＨＡＲＱフィードバックを生成することができる。ＷＴＲＵは、その後、本明細書において説明される方法のいずれかを使用して、またはレガシ方法を使用して、適用可能な符号化および適用可能なアップリンクリソースを決定することができる。

【0312】

例においては、オーバロードが、プロセスについての動的スケジューリング情報の存在または非存在を示すことができる。例においては、ＨＡＲＱフィードバックは、関連するプロセスがスケジュールされたことも要求が示すことができるように、ＷＴＲＵがそれについての（例えば、動的および／または構成された／半永久的な）スケジューリング情報を有する送信だけに対応することができる。そのようなケースにおいては、ＷＴＲＵは、ＷＴＲＵが関連する間隔の間に１（または複数）のＰＤＣＣＨを正常に復号することに失敗したかどうか（例えば、「紛失したＰＤＣＣＨ」）（おそらくはまたそれがどのサービングセルについてか）、それが１（または複数）のＰＤＣＣＨを正常に復号しながら誤りとしたかどうか（例えば、「フォールスポジティブ」）を決定するための検証を実行することができる。

【0313】

例においては、構成されたＤＬ割り当てに対して、特別なケースを使用することができる。関連する間隔の間にダウンリンク割り当てを用いるように構成されたＨＡＲＱプロセスについては、ＷＴＲＵは、ＵＣＩが常に要求されると決定することができ、このケースにおいては、関連するＨＡＲＱプロセスについての要求の非存在は、動的スケジューリングがプロセスと関連付けられなかったことを示すことができるが、加えて、そのような要求の存在は、動的スケジューリングがプロセスと関連付けられたことを示すことができる。

【0314】

例においては、ＰＤＣＣＨ復号支援として、オーバロードを使用することができる。例においては、ＷＴＲＵは、ＷＴＲＵがＵＣＩ要求情報を使用して、それについてのＨＡＲＱフィードバックが要求されたセルだけについて、復号の試みを実行することができるように、ＵＣＩ要求が、ＷＴＲＵの構成のすべてのセル（おそらくはアクティブ化されたセルだけ）、および／またはそのような制御シグナリングと関連付けられたすべてのそのようなセルに対応すると決定することができる。

【0315】

別の例においては、ＨＡＲＱフィードバック要求は、ＤＬスケジューリング、例えば、プロセスの状態とは独立とすることができる。例においては、ＨＡＲＱフィードバックは、関連するプロセスについてのスケジューリング活動とは独立に、関連するＨＡＲＱプロセスの状態に対応することができる。そのようなケースにおいては、紛失したＰＤＣＣＨおよび／またはいずれかのフォールスポジティブの可能な発生の検出に関して、さらなる検証をＷＴＲＵによって実行しないことができる。

【0316】

さらなる例においては、ＵＣＩ要求の内容は、ＵＣＩサイズ削減方法を含むことができる。例においては、ＷＴＲＵは、加えて、例えば、本明細書において説明される他の任意の方法など、どのサイズ削減方法を要求されたＵＣＩに対して適用すべきかを決定することができる。例えば、ＵＣＩ要求は、それについてのＨＡＲＱ Ａ／Ｎが報告されるべきセルについて、ＷＴＲＵが、空間多重化（例えば、間隔当たり複数のトランスポートブロック）を用いるように構成されたセルについてのＨＡＲＱ Ａ／Ｎのためにバンドリングを使用すべきことを示すことができる。

【0317】

またさらなる例においては、ＵＣＩ要求の内容は、例えば、本明細書において説明されるような、フィードバックグループを含むことができる。例においては、ＷＴＲＵは、それがそれについてのフィードバックを提供すべきＰＤＳＣＨ送信および／またはＨＡＲＱプロセスのセットを、動的フィードバック要求フィールドに基づいて決定することができる。フィールドの異なるコードポイントは、異なるフィードバックグループ（例えば、ＰＤＳＣＨ送信および／またはＨＡＲＱプロセスのセット）にマッピングすることができ、これらのコードポイントマッピングは、おそらくはＲＲＣ構成によって、半静的に構成することができる。

【0318】

また別の例においては、ＵＣＩ要求の内容は、非定期的な要求を含むことができる。例においては、ＷＴＲＵは、加えて、ＵＣＩ要求から、非定期的なアップリンクフィードバックが送信されるべきであると決定することができる。

【0319】

ＷＴＲＵは、構成されたダウンリンク割り当ておよび／または構成されたアップリンクグラントをアクティブ化または非アクティブ化する、１つまたは複数のＤＣＩの受信から生成される、ＨＡＲＱ Ａ／Ｎについての追加の挙動を実施することができる。１つの方法においては、ＷＴＲＵは、ＵＣＩ要求とは独立して、そのようなシグナリングについてのＨＡＲＱ Ａ／Ｎ報告を常に生成することができる。１つの方法においては、ＷＴＲＵは、ＷＴＲＵがその上において制御シグナリングを受信したサービングセルが、ＵＣＩ要求内に含まれる場合、そのようなシグナリングについてのＨＡＲＱ Ａ／Ｎ報告を生成する（例えば、半永久的スケジューリング（ＳＰＳ）コマンドおよびＵＣＩ要求の送信をネットワークにコヒーレントに調整させる）ことができる。

【0320】

別の例においては、ＷＴＲＵは、例えば、本明細書において説明される方法を使用して、示されたＵＣＩが、生成されるべきではない、および／またはアップリンク送信内に含まれるべきではないと決定することができる。言い換えると、そのようなシグナリングは、ＵＣＩ要求と見なされる代わりに、適用可能なＵＣＩのいくつか（またはすべて）を抑制するために使用することができる。

【0321】

例においては、ＤＣＩ（ＵＣＩ）は、ＵＣＩのためのスケジューリング情報を示すことができる。ＵＣＩ要求は、送信のためにどのＵＣＩを生成すべきかを決定するために使用することができる。例においては、ＷＴＲＵは、ＵＣＩスケジューリング情報の関数として、例えば、おそらくは、（変調、（開始）リソースブロック、リソースブロックの数、拡散、空間多重化、おそらくはタイミングおよび／もしくはタイミングオフセット、または１つもしくは複数のＤＭ－ＲＳシーケンスなどのうちの１つを含む）適用可能な送信リソースおよび／または適用可能な送信フォーマットを含む、適用可能なＵＣＩのうちの少なくともいくつかについてのアップリンク送信のいくつかまたはすべての特性を決定することができる。

【0322】

ＵＣＩスケジューリング情報は、以下の情報のうちの少なくとも１つ、すなわち、物理チャネルタイプ（ＰＵＣＣＨ、ＰＵＳＣＨ）、物理チャネルタイプ識別情報（例えば、ＰＣｅｌｌ上のＰＵＣＣＨ、ＳＣｅｌｌ上のＰＵＣＣＨ）、サービングセル識別情報、ＰＵＣＣＨ／ＵＣＩフィードバックグループ識別情報、ＰＵＣＣＨフォーマット、ＰＵＳＣＨ送信パラメータ、ＰＵＣＣＨ送信パラメータ、チャネル符号化、ペイロードサイズ、ＴＰＣコマンド（電力制御情報）、およびＣＳＩ要求のうちの少なくとも１つを含むことができる。さらに、示されたリソースがＰＵＳＣＨリソースか、それともＰＵＣＣＨリソースかに応じてなど、上述のスケジューリング情報の異なる組合せが可能である。

【0323】

ＵＣＩスケジューリング情報は、物理チャネルタイプ（ＰＵＣＣＨ、ＰＵＳＣＨ）を含むことができる。ＷＴＲＵは、ＵＣＩの送信のためにどのタイプの物理チャネルを使用すべきかを、スケジューリング情報内の表示の関数として、決定することができる。そのような表示が存在しないとき、ＷＴＲＵは、ＰＵＣＣＨを使用すると決定することができる。ＵＣＩの送信のために（おそらくはそのためだけに）ＰＵＳＣＨがスケジュールされるとき、ＷＴＲＵは、関連するＨＡＲＱプロセスについてのいずれのＷＴＲＵ自律的な再送も実行することができない。

【0324】

ＵＣＩスケジューリング情報は、物理チャネルタイプ識別情報（例えば、ＰＣｅｌｌ上のＰＵＣＣＨ、ＳＣｅｌｌ上のＰＵＣＣＨ）を含むことができる。ＷＴＲＵは、ＵＣＩの送信のためにあるタイプ（例えば、ＰＵＣＣＨ）のどの物理チャネルを使用すべきかを、スケジューリング情報内の表示（例えば、ＰＣｅｌｌ上のＰＵＣＣＨ、ＳＣｅｌｌ上のＰＵＣＣＨ）の関数として、決定することができる。そのような表示が存在しないとき、ＷＴＲＵは、デフォルトのＰＵＣＣＨチャネルを、例えば、ＰＣｅｌｌ上のＰＵＣＣＨを使用することに決定することができる。これは、例えば、ＰＵＣＣＨを用いるように構成されたサービングセルのＰＵＳＣＨを、ＵＣＩ送信のためにスケジュールすることができるとき、ＰＵＳＣＨ上におけるフィードバックの送信にも適用可能とすることができる。

【0325】

ＵＣＩスケジューリング情報は、サービングセル識別情報を含むことができる。ＷＴＲＵは、物理アップリンクリソースに対応するサービングセルの識別情報を決定することができる。サービングセル識別情報またはＣＦＩは、ＵＣＩについてのＰＵＳＣＨスケジューリングのために使用することができる。例えば、ＷＴＲＵは、サービングセルの識別情報に対応する値を受け取ることができる。そのような識別情報は、他のレイヤによって使用されるサービングセル識別情報、例えば、ＲＲＣにおけるｓｅｒｖＣｅｌｌ－ＩＤに基づくことができる。あるいは、そのような識別情報は、クロスキャリアスケジューリングのための構成された値、例えば、ＣＦＩに基づくことができる。例においては、これは、スケジューリング情報がＰＵＳＣＨ上のリソースを示すことができるときに、適用可能とすることができる。

【0326】

ＵＣＩスケジューリング情報は、ＰＵＣＣＨ／ＵＣＩフィードバックグループ識別情報を含むことができる。ＷＴＲＵは、物理アップリンクリソースに対応するアップリンクフィードバックチャネルの識別情報を、単一のアップリンクチャネルと関連付けられたセルのグループ（例えば、ＰＵＣＣＨグループ）の識別情報の関数として、決定することができる。これは、例えば、ＰＵＣＣＨを用いるように構成されたサービングセルのＰＵＳＣＨを、ＵＣＩ送信のためにスケジュールすることができるとき、ＰＵＳＣＨ上におけるフィードバックの送信にも適用可能とすることができる。

【0327】

ＵＣＩスケジューリング情報は、ＰＵＣＣＨフォーマットを含むことができる。ＷＴＲＵは、スケジューリング情報内において使用するＰＵＣＣＨフォーマット、例えば、ＰＵＣＣＨフォーマット３または他のフォーマットの表示を受け取ることができる。

【0328】

ＵＣＩスケジューリング情報は、ＰＵＳＣＨ送信パラメータを含むことができる。ＷＴＲＵは、ＵＣＩフィードバック上における送信のためのアップリンクＰＵＳＣＨ送信についてのグラントのためのものと類似の情報を受け取ることができる。例においては、そのようなグラントは、ＵＣＩの送信専用とすることができる。

【0329】

ＵＣＩスケジューリング情報は、ＰＵＣＣＨ送信パラメータを含むことができる。ＰＵＣＣＨ送信パラメータは、既存のＰＵＣＣＨフォーマット、例えば、ＰＲＢ割り当てについてＷＴＲＵが決定するパラメータに類似することができる。

【0330】

ＵＣＩスケジューリング情報は、チャネル符号化を含むことができる。ＷＴＲＵは、それがＵＣＩタイプの１つまたは特定の組合せを送信すべきかどうかを、示されたチャネル符号化方法の関数として、決定することができる。

【0331】

ＵＣＩスケジューリング情報は、ペイロードサイズを含むことができる。ＷＴＲＵは、アップリンク送信内に含むＵＣＩの量を、スケジュールされたＵＣＩ送信のための示されたペイロードサイズの関数として、決定することができる。例においては、そのような情報が存在しない場合、ＷＴＲＵは、本明細書において説明されるものなど、他の任意の方法を使用し、本明細書において説明されるようなＵＣＩ要求を含むことができる。

【0332】

ＵＣＩスケジューリング情報は、ＴＰＣコマンド（電力制御情報）を含むことができる。このＴＰＣコマンドは、レガシＴＰＣコマンドに類似することができるが、スケジューリング情報がＰＵＳＣＨ送信のためのものか、それともＰＵＣＣＨ送信のためのものかの関数として、解釈することができる。

【0333】

ＵＣＩスケジューリング情報は、ＣＳＩ要求を含むことができる。このＣＳＩ要求は、レガシ要求に類似することができる。例においては、そのようなＣＳＩ要求は、関連する時間間隔の間の他のＣＳＩ報告（例えば、定期的なＣＳＩ）をオーバライドすることができる。

【0334】

さらに、上述のスケジューリング情報の異なる組合せが、ＰＵＣＣＨまたはＰＵＳＣＨの一部として可能である。例えば、ＷＴＲＵは、ＰＵＳＣＨ上におけるＵＣＩの送信をスケジュールするＤＣＩ（ＵＣＩ）を受信することができ、そのＤＣＩ（ＵＣＩ）は、物理チャネルのタイプ（すなわち、ＰＵＳＣＨ）と、アップリンク送信のためのサービングセルの識別情報（例えば、サービングセル０－ＰＣｅｌｌ）と、例えば、リソースブロック割り当てを含む、ＰＵＳＣＨ送信パラメータと、変調および符号化方式（ＭＣＳ）と、ＴＰＣとを含むことができる。

【0335】

例えば、ＷＴＲＵは、ＰＣｅｌｌのＰＵＣＣＨ上におけるＵＣＩの送信をスケジュールするＤＣＩ（ＵＣＩ）を受信することができ、そのＤＣＩ（ＵＣＩ）は、物理チャネルのタイプ（すなわち、ＰＵＣＣＨ）と、例えば、リソースブロック割り当てを含む、ＰＵＣＣＨ送信パラメータと、ＴＰＣとを含むことができる。加えて、ＤＣＩ（ＵＣＩ）は、そのような送信内にどのＵＣＩを含むべきかをＷＴＲＵが決定するような、ＵＣＩ要求を含むことができる。ＷＴＲＵは、ＤＣＩ（ＵＣＩ）のためのＰＤＣＣＨがその上において受信されたセルの識別情報に基づいて、ＰＣｅｌｌのＰＵＣＣＨがスケジュールされていると決定することができる。

【0336】

例においては、ＵＣＩのためのＤＣＩ、またはＤＣＩ（ＵＣＩ）を使用することができる。例においては、専用ＤＣＩを使用することができる。別の例においては、既存のＤＣＩに対する拡張を使用することができる。

【0337】

例においては、ＤＣＩ（ＵＣＩ）は、本明細書において説明される態様のいずれかのための１（もしくは複数）のフィールドを含む専用フォーマットを使用して、またはＤＣＩ（ＵＣＩ）フォーマット内の１（もしくは複数）のインデックスを使用して、本明細書において説明される情報のいずれかを示すことができる。

【0338】

例においては、過渡的である場合、ＨＡＲＱ Ａ／Ｎは、ＤＣＩによって生成することができない。例においては、ＷＴＲＵは、ＤＣＩ（ＵＣＩ）を受信することができる。ＷＴＲＵは、ＤＣＩ自体についてのフィードバックを報告するために、いかなるＨＡＲＱ Ａ／Ｎも生成すること、および／または含むことができない。ＷＴＲＵは、そのようなＤＣＩ（ＵＣＩ）がサブフレーム毎および／またはＴＴＩ毎に適用される場合、そうすることができない。

【0339】

別の例においては、時間の期間にわたって構成／アクティブ化されている場合、または非アクティブ化されている場合、ＨＡＲＱ Ａ／Ｎは、ＤＣＩによって生成することができる。例においては、ＷＴＲＵは、ＤＣＩ（ＵＣＩ）を受信することができる。ＷＴＲＵは、サブフレーム２つ以上の長さ（またはＴＴＩ２つ以上の長さ）の期間の間、例えば、それが、構成されたＵＣＩ報告を変更または非アクティブ化する別のＤＣＩ（ＵＣＩ）を受信するまで、ＤＣＩ（ＵＣＩ）がＵＣＩ報告を構成すると決定することができる。そのようなケースにおいては、ＷＴＲＵは、例えば、ＤＣＩ（ＵＣＩ）自体の受信についてのフィードバックを報告するために、そのようなＤＣＩ（ＵＣＩ）についてのＨＡＲＱ Ａ／Ｎフィードバックを生成すること、および／または含むことができる。１つの方法においては、ＷＴＲＵは、関連するＤＣＩ（ＵＣＩ）のＨＡＲＱ Ａ／Ｎ報告についての、そのようなＤＣＩ（ＵＣＩ）の受信に先立って適用可能な、ＵＣＩ報告方法を使用することができる。ＷＴＲＵは、サブフレームｎにおいて、そのようなＤＣＩ（ＵＣＩ）を受信したとき、サブフレームｎ＋ｘ＋１において、新しい構成を使用することを開始することができる。例えば、ｘは、４に等しいとすることができ、ＷＴＲＵは、関連するＤＣＩ（ＵＣＩ）についてのＨＡＲＱ Ａ／Ｎ報告の送信に続くサブフレームから開始して、新しい構成を適用することができる。一例においては、ＷＴＲＵは、関連するＤＣＩ（ＵＣＩ）のＨＡＲＱ Ａ／Ｎ報告についての、ＤＣＩ（ＵＣＩ）自体において示される新しい構成を使用することができる。ＷＴＲＵは、サブフレームｎにおいて、そのようなＤＣＩ（ＵＣＩ）を受信したとき、サブフレームｎ＋ｘにおいて、新しい構成を使用することを開始することができる。例えば、ｘは、４に等しいとすることができ、ＷＴＲＵは、関連するＤＣＩ（ＵＣＩ）についてのＨＡＲＱ Ａ／Ｎ報告の送信を行うサブフレームから開始して、新しい構成を適用することができる。

【0340】

例においては、示されたタイプのために要求されないＵＣＩは、抑制／ドロップすることができる。例においては、ＷＴＲＵは、そのような要求を受信したとき、ＵＣＩ要求の一部ではないいかなるＵＣＩもそれが送信することができないと決定することができる。

【0341】

別の例においては、ＵＣＩがいかなるＵＣＩ要求の一部でもない場合、他の方法を使用することができる。例においては、ＷＴＲＵは、そのような要求を受信したとき、例えば、レガシ方法など、他の方法を使用して、ＵＣＩ要求の一部ではないいかなるＵＣＩもそれが送信することができると決定することができる。例えば、ＵＣＩスケジューリングが、ＰＵＣＣＨ上における送信を示すとき、ＷＴＲＵは、レガシ方法に従って、残りのＵＣＩを、（そのようなものが利用可能である場合は）ＰＵＳＣＨ送信に回送することができる。例えば、ＵＣＩスケジューリングが、ＰＵＳＣＨ上における送信を示すとき、ＷＴＲＵが同時ＰＵＳＣＨ／ＰＵＣＣＨ送信のために構成されている場合に限って、ＰＵＳＣＨおよびＰＵＣＣＨの両方が同時であり、おそらくは同じサービングセルのためのものでもある場合、ＷＴＲＵは、レガシ方法に従って、残りのＵＣＩを、ＰＵＣＣＨ送信に回送することができる。

【0342】

別の例においては、ＷＴＲＵは、それがＵＣＩ要求を含むＤＣＩ（ＵＣＩ）を受信しない限り、それがいかなるＵＣＩも送信することができないと決定することができる。例においては、ＷＴＲＵは、それがＤＣＩ要求を含むＤＣＩ（ＵＣＩ）を受信しないときでさえも、例えば、レガシ方法に従って、いずれかのＰＵＳＣＨ送信に対するＵＣＩを含むことができる。

【0343】

別の例においては、要求の一部ではないＵＣＩタイプは、抑制／ドロップすることができ、またはレガシ送信方法が、使用されることができる。例においては、ＷＴＲＵは、そのような要求を受信したとき、ＵＣＩ要求の一部ではないいかなるＵＣＩも送信することができないと決定することができる。

【0344】

別の例においては、ＤＣＩ（ＵＣＩ）要求は、ＨＡＲＱフィードバックだけのためのものとすることができる。例えば、ＷＴＲＵは、特定のＨＡＲＱプロセスについての、および／または特定のサービングセルだけについてのＨＡＲＱ Ａ／Ｎフィードバックを要求する、ＤＣＩ（ＵＣＩ）を受信することができる。

【0345】

別の例においては、代替的な決定を行うことができる。いくつかの例においては、ＵＣＩ要求についての、またはＵＣＩスケジューリング情報についての、本明細書において説明される情報のいずれかを、他の手段によって暗黙的に導出することができる。例えば、ＤＣＩのタイプ（ＤＣＩフォーマットＤＣＩ（ＵＣＩ）と比較して、例えば、ＤＣＩフォーマット０、１など）を示すために、ＵＣＩ要求のタイプを示すために、物理チャネルのタイプ（例えば、ＰＵＳＣＨ対ＰＵＣＣＨ）を示すために、またはセルの識別情報を示すためになど、特定のＲＮＴＩを割り当てることができる。同様に、ＰＤＣＣＨ探索空間の特定の領域、または特定のＤＣＩアグリゲートレベル、またはＤＣＩのＣＲＣについての特定のサイズを割り当てることができ、類似の情報を決定するために使用することができる。

【0346】

別の例においては、半永久的な割り当てを行うことができる。スケジューリング情報は、半永久的に構成することができる。そのようなケースにおいては、構成された情報を、デフォルトのスケジューリング情報として使用することができる。そのようなケースにおいては、ＷＴＲＵは、適用可能なサービングセルについての構成されたスケジューリング情報をオーバライドするＤＣＩ（ＵＣＩ）を受信することができる。そのようなケースにおいては、ＷＴＲＵは、ＵＣＩが生成されないとき、および／または関連する時間間隔の間の送信のために利用可能でないとき、構成された割り当てを使用するいかなる送信の実行も控えることができる。あるいは、ＨＡＲＱフィードバックについては、ＷＴＲＵは、関連するプロセスについての最後の受信に続くＨＡＲＱフィードバックの値を報告することができ、一方、ＣＳＩフィードバックについては、ＷＴＲＵは、（例えば、非定期的なＣＳＩ構成も存在する場合は）これを定期的な報告構成と見なすことができる。

【0347】

別の例においては、チャネル符号化の選択は、動的スケジューリング情報の関数とすることができる。ＷＴＲＵは、適切なチャネル符号化を、要求されたＵＣＩの関数として、選択することができ（例えば、チャネル符号化は、本明細書において説明される方法のいずれかの通りに、もしくはＨＡＲＱ Ａ／Ｎ、定期的なＣＳＩ、ＣＱＩ／ＰＭＩ、およびスケジューリング要求のうちの少なくとも１つの異なる組合せのためのレガシ方法を使用して選択することができる）、ならびに／またはＵＣＩについてのスケジューリングパラメータの関数として（例えば、それがＰＵＣＣＨ上にあるか、それともＰＵＳＣＨ上にあるか（適用可能な場合））、選択することができる。

【0348】

別の例においては、ＵＣＩのためのスケジューリング情報は、ＷＴＲＵが、例えば、与えられたセルグループ（ＣＧ）についての送信を同時にＰＵＳＣＨ上において実行することが予期される場合でさえも、ＰＵＣＣＨ送信に対応するリソースを示すことができる。そのようなケースにおいては、ＷＴＲＵは、例えば、関連するＣＧについての、同時ＰＵＣＣＨおよびＰＵＳＣＨ送信が構成される場合、示されたリソースを使用して、適用可能なＵＣＩの送信を実行することができる。そうではなく、ＷＴＲＵが、同時ＰＵＣＣＨ／ＰＵＳＣＨ送信を実行しない場合、それは、レガシ挙動に従って、ＰＵＳＣＨ送信内に（例えば、動的スケジューリング情報において要求されるＵＣＩなど）適用可能なＵＣＩ情報を含むことができる。例においては、ＷＴＲＵは、スケジュールされたＵＣＩ送信内にＳＲを含むことができる。

【0349】

いくつかの例においては、ＷＴＲＵは、ＰＵＣＣＨまたはＰＵＳＣＨ上における単一のサブフレーム内において、２つ以上のセルについての定期的なＣＳＩ報告（複数の定期的なＣＳＩ報告）を送信するように構成することができる。ＷＴＲＵは、同じサブフレーム内において、ＨＡＲＱ－ＡＣＫおよび／またはＳＲを送信するように構成することもできる。

【0350】

いくつかの例においては、ＨＡＲＱ－ＡＣＫおよび定期的なＣＳＩの送信のケースにおいて、最大ペイロードを構成することができる。ＷＴＲＵは、サブフレーム内におけるＨＡＲＱ－ＡＣＫ、定期的なＣＳＩ報告、および／またはＳＲの送信のために使用することができるＰＵＣＣＨリソース毎に、最大ペイロードを用いるように構成することができる。最大ペイロードは、ビットを単位として表現することができ、または構成されたリソースについての利用可能な符号化ビットの知られた数と関連がある、最大コードレートの観点から表現することができる。そのような最大ペイロードは、送信されているＵＣＩの組合せ、例えば、ＨＡＲＱ－ＡＣＫ単独が送信されるか、それともＨＡＲＱ－ＡＣＫ、定期的なＣＳＩ、およびＳＲの組合せが送信されるかに依存することができる。

【0351】

あるいは、または加えて、ＷＴＲＵは、リソース内において送信されるＨＡＲＱ－ＡＣＫおよびＳＲビットの数とは独立して適用可能な、ＰＵＣＣＨリソース毎の定期的なＣＳＩ報告の最大ペイロードを用いるように構成することができる。定期的なＣＳＩ報告のそのような最大ペイロードは、本明細書において説明されるソリューションのうちの１つに従って、サブフレーム内において使用される、またはサブフレーム内において定期的なＣＳＩの送信のためだけに使用される、ＰＵＣＣＨリソースの構成された最大ペイロードと同じとすることができる。あるいは、ＨＡＲＱ－ＡＣＫおよび／またはＳＲとの同時送信のケースにおける定期的なＣＳＩ報告の最大ペイロードは、独立して構成することができる。

【0352】

ＷＴＲＵは、定期的なＣＳＩ報告のペイロードが定期的なＣＳＩ報告の構成された最大ペイロードを超えたケースにおいて、またはＨＡＲＱ－ＡＣＫ、ＳＲ、および定期的なＣＳＩ報告の合計ペイロードがＰＵＣＣＨリソースについての構成された最大ペイロード（もしくはＵＣＩビットの総数）を超えたケースにおいて、ＨＡＲＱ－ＡＣＫおよび／またはＳＲも送信されるサブフレーム内において、構成された数よりも少ない数の定期的なＣＳＩ報告を送信することができる。送信される定期的なＣＳＩ報告のサブセットは、本明細書において説明されるソリューションのうちの１つに従って、決定することができる。

【0353】

いくつかの例においては、ＨＡＲＱ－ＡＣＫの送信が複数の定期的なＣＳＩ報告の送信と衝突するとき、ＷＴＲＵは、本明細書において説明されるソリューションに従って、複数の定期的なＣＳＩの送信のために構成されたＰＵＣＣＨリソースのうちの１つの上において送信を行うことができる。あるいは、ＷＴＲＵは、ダウンリンク制御情報（すなわち、ＳＣｅｌｌ割り当て／ＡＲＩのＴＰＣフィールド）によって示される定期的なＰＵＣＣＨリソース上において送信を行うことができる。

【0354】

ＷＴＲＵは、サブフレーム内における複数の定期的なＣＳＩ報告の送信のために、２つ以上のＰＵＣＣＨリソースを用いるように構成することができる。このケースにおいては、ＷＴＲＵは、以下のソリューションのうちの少なくとも１つに従って、ＰＵＣＣＨリソースを決定することができる。

【0355】

例においては、ＷＴＲＵは、少なくとも１つのプライオリティ基準に基づいて、ＰＵＣＣＨリソースを選択することができる。例えば、ＷＴＲＵは、それについての定期的なＣＳＩ報告がサブフレーム内において送信されているすべてのサービングセルの中から、それの定期的なＣＳＩ報告がサブフレーム内において最も高いプライオリティを有するサービングセルと関連付けられたリソースを選択することができる。

【0356】

別の例においては、ＷＴＲＵは、サブフレーム内において送信される定期的なＣＳＩ報告の合計ペイロード、またはＨＡＲＱ－ＡＣＫ（適用可能な場合）、ＳＲ（適用可能な場合）、および定期的なＣＳＩ報告の合計ペイロードに基づいて、ＰＵＣＣＨリソースを選択することができる。例えば、ＷＴＲＵは、合計ペイロードが閾値を超えない場合、第１のＰＵＣＣＨリソースを、そうではない場合、第２のＰＵＣＣＨリソースを選択することができる。閾値は、第２のＰＵＣＣＨリソースのためにサポートすることができる最大ペイロードよりも小さいことができる、第１のＰＵＣＣＨリソースのためにサポートすることができる最大ペイロードに対応すること、またはそれの関数とすることができる。

【0357】

さらなる例においては、ＷＴＲＵは、各リソースと関連付けられた電力制御パラメータおよび公式に基づいて、必要とされる送信電力の関数として、ＰＵＣＣＨリソースを選択することができる。送信電力は、リソース固有のパラメータ、フォーマット固有のパラメータ、ペイロード、リソースブロックの数、コードレート、電力制御調整、および／または経路損失のうちの少なくとも１つの関数とすることができる。例えば、ＷＴＲＵは、必要とされる送信電力を最小化するリソースを選択することができる。別の例においては、ＷＴＲＵは、このリソースについての必要とされる送信電力が閾値を下回る場合、第１のリソースを、そうではない場合、おそらくは、第２のリソースについての必要とされる送信電力が、ｄＢ単位で第１のリソースについての必要とされる送信電力プラス構成されたオフセットよりも低いという条件の下でだけ、第２のリソースを選択することができる。上においては、各リソースについての必要とされる送信電力は、異なるリソース間のキュービックメトリック（ＣＭ）および／またはピーク対平均電力比（ＰＡＰＲ）における可能な差を考慮して、ピーク送信電力に対応するように調整することができる。調整は、ＰＵＣＣＨフォーマットまたはリソースブロックの数など、ＰＵＣＣＨリソースと関連付けられた少なくとも１つの特性の関数とすることができる。

【0358】

ＷＴＲＵは、ＨＡＲＱ－ＡＣＫおよび／またはＳＲも同じサブフレーム内において送信されるかどうかに基づいて、ＰＵＣＣＨリソースを選択することができる。ＨＡＲＱ－ＡＣＫおよび／またはＳＲも送信されるケースにおいて使用するＰＵＣＣＨリソースは、ダウンリンク制御情報から伝達すること、またはより高位のレイヤだけによって構成することができる。

【0359】

また別の例においては、ＷＴＲＵは、サブフレームのタイミングに基づいて、ＰＵＣＣＨリソースを選択することができる。例えば、サブフレームの第１のセットおよび第２のセットは、それぞれ、第１のＰＵＣＣＨリソースおよび第２のＰＵＣＣＨリソースと関連付けることができる。各セットは、フレーム番号および／もしくはサブフレーム番号に関連する期間およびオフセットの観点から、または期間およびオフセットを表すインデックスの観点から定義することができる。例えば、１つのセットは、フレーム＃０のサブフレーム＃３を含む、２０ｍｓの期間とともに生じるサブフレームに対応することができる。ＷＴＲＵは、第１のセットだけに属するサブフレーム内において第１のＰＵＣＣＨリソースを、第２のセットだけに属するサブフレーム内において第２のＰＵＣＣＨリソースを選択することができる。両方のセットに属するサブフレームについては、ＷＴＲＵは、以下のうちの少なくとも１つに基づいて、ＰＵＣＣＨリソースを選択することができる。例においては、ＷＴＲＵは、プライオリティ基準に基づいて、ＰＵＣＣＨリソースを選択することができる。プライオリティは、事前定義することができ、またはサポートされる最大ペイロード（もしくはコードレート）、リソースブロックの数、開始リソースブロック番号、またはフォーマットなど、リソースの特性に基づくことができる。例えば、プライオリティは、最も高い最大ペイロードをサポートすることができるＰＵＣＣＨリソースに与えることができる。別の例においては、ＷＴＲＵは、送信される合計ペイロード、必要とされる送信電力、および／またはそれについての報告が送信されている関連するサービングセルのプライオリティに基づいてなど、本明細書の他の箇所において既に説明されたソリューションに基づいて、ＰＵＣＣＨリソースを選択することができる。

【0360】

いくつかの例においては、ＷＴＲＵは、電力制限のせいで、構成された数よりも少ない数の定期的なＣＳＩ報告を送信することがある。ＷＴＲＵは、最初に、送信のために利用可能な最大電力、チャネルのタイプ（ＰＵＣＣＨまたはＰＵＳＣＨ）、ＰＵＣＣＨのケースにおけるフォーマット、ならびに電力制御のために使用される他のパラメータおよび測定（例えば、経路損失）に基づいて、定期的なＣＳＩ報告およびＣＲＣ（適用可能な場合）についての、または定期的なＣＳＩ報告、ＳＲ、ＨＡＲＱ－ＡＣＫフィードバック、およびＣＲＣ（適用可能な場合）の組合せについての、最大ペイロードを決定することができる。最大ペイロードは、適用可能な場合は、ＣＲＣ追加のために必要とされるビットの数を考慮することができる。そのような最大ペイロードは、電力制限されたペイロードと呼ばれることがある。ＷＴＲＵが２つ以上のＰＵＣＣＨリソースを用いるように構成されるケースにおいては、ＷＴＲＵは、最初に、本明細書において説明されるソリューションに基づいて、ＰＵＣＣＨリソースを決定し、次に、リソースと関連付けられた電力制限されたペイロードを決定することができる。あるいは、ＷＴＲＵは、最も高い可能な電力制限されたペイロードをもたらす、ＰＵＣＣＨリソースを選択することができる。

【0361】

電力制限されたペイロードは、最大ペイロードについての許可された値からなる有限セットに属する１つ、または（定期的な報告の最大数もしくは最大コードレートなど）最大ペイロードをそれから導出することができるパラメータに対応するように制約することができる。許可された値からなるそのようなセットは、ＰＵＣＣＨリソースの一部として構成することができる可能な値からなるセットに対応することができる。

【0362】

送信のために利用可能な最大電力は、複数のセルおよび／またはセルグループが構成されるとき、既存の電力スケーリングおよび割り当てソリューションを使用して、決定することができる。いくつかのソリューションにおいては、ＷＴＲＵは、定期的なＣＳＩを含むＰＵＣＣＨ送信に固有の最大電力を用いるように構成することができる。このケースにおいては、送信のために利用可能な最大電力は、定期的なＣＳＩのためのこの構成された最大電力と、既存のソリューションから獲得される最大利用可能電力との間の最小値とすることができる。

【0363】

ＰＵＣＣＨのケースにおける最大ペイロードは、情報ビットの数と、定期的なＣＳＩ報告を送信するために使用されるＰＵＣＣＨフォーマットに適用可能な電力オフセットとの間の関係を使用して、決定することができる。ＰＵＣＣＨのケースにおける最大ペイロードは、異なるタイプのＣＳＩ報告（ＲＩ、ＣＱＩ、およびＰＭＩ）のエンコードのために使用することができるシンボル（またはシンボルの比）の最大数から決定することができる。

【0364】

構成に従って定期的なＣＳＩ報告のセットを送信するのに必要とされるビットの数が、本明細書において説明されるソリューションのうちの１つに従った最大ペイロードを超える場合、ＷＴＲＵは、プライオリティルールに基づいて、ＣＳＩ報告のサブセットを送信することができる。プライオリティルールは、レガシプライオリティルール（すなわち、報告のタイプおよびサービングセルインデックス）に基づくことができる。プライオリティルールは、以下のうちの少なくとも１つにも、すなわち、セルについての定期的な報告の最後の送信以降の時間と、ＣＱＩおよび／またはＲＩの値とのうちの少なくとも１つにも基づくことができる。おそらくは、それについてのＣＱＩ／ＲＩが構成された閾値を上回るまたは下回る報告、ならびに／またはセルについての対応する報告の最後の送信以降のＣＱＩおよび／もしくはＲＩの値の変化の報告だけを送信することができる（例においては、ＣＱＩおよび／もしくはＲＩの最も大きい変化を有する報告を優先することができる）。

【0365】

ＷＴＲＵは、少なくとも、ネットワークがあらかじめプライオリティを知ることができないケースにおいて、または報告のサブセットだけが送信されるとき、セルについてのＣＳＩ報告の各セットとともに、セル識別情報を含むことができる。ＷＴＲＵは、電力制限のせいで、報告のサブセットだけが送信される旨の、おそらくは別個にエンコードされる、表示を送信することもできる。

【0366】

電力制限されたペイロードが、ＨＡＲＱ－ＡＣＫビットだけの送信、またはＨＡＲＱ－ＡＣＫおよびＳＲビット（適用可能な場合は、プラスＣＲＣビット）の送信のために必要とされるビットの数よりも低いケースにおいては、ＷＴＲＵは、送信内にいかなる定期的なＣＳＩ報告も含むことができない。いくつかのソリューションにおいては、ＷＴＲＵは、電力制限されたペイロードが、構成に従った、すべての定期的なＣＳＩ報告、ＨＡＲＱ－ＡＣＫ（適用可能な場合）、ＳＲ（適用可能な場合）、およびＣＲＣ（適用可能な場合）の送信のために必要とされるものよりも低いときは常に、送信内にいかなる定期的なＣＳＩも含むことができない。そのようなケースにおいては、ＷＴＲＵは、適用可能な場合は、ＨＡＲＱ－ＡＣＫ、ＳＲ、およびＣＲＣだけを送信することができる。

【0367】

いくつかの例においては、ペイロードは、可能な値からなる有限セットに属する１つになるように設定することができる。例えば、ＷＴＲＵは、より高位のレイヤによって事前定義または構成することができる可能なペイロード値からなるセットに属する１つにペイロードが一致するように、パディングを使用する（例えば、ペイロードに多数の「０」ビットを追加する）ことができる。これは、ネットワークサイドにおける受信機による、ペイロードのブラインド検出を容易にすることができる。そのようなパディングは、上述のソリューションのうちの１つに従って、（定期的なＣＳＩまたは他のＵＣＩについての）ペイロードの削減の後に、生じることができる。おそらくは、パディングは、電力制限のせいでペイロード削減が生じたケースにおいてだけ、実行することができる。

【0368】

上では特徴および要素が特定の組合せで説明されたが、各特徴または要素は、単独で使用することができ、または他の特徴および要素との任意の組合せで使用することができることを当業者は理解されよう。加えて、本明細書において説明された方法は、コンピュータまたはプロセッサによって実行される、コンピュータ可読媒体内に包含された、コンピュータプログラム、ソフトウェア、またはファームウェアで実施することができる。コンピュータ可読媒体の例は、（有線または無線接続上において送信される）電子信号、およびコンピュータ可読記憶媒体を含む。コンピュータ可読記憶媒体の例は、リードオンリメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、レジスタ、キャッシュメモリ、半導体メモリデバイス、内蔵ハードディスクおよびリムーバブルディスクなどの磁気媒体、光磁気媒体、ならびにＣＤ－ＲＯＭディスクおよびデジタル多用途ディスク（ＤＶＤ）などの光媒体を含むが、それらに限定されない。ＷＴＲＵ、ＵＥ、端末、基地局、ＲＮＣ、または任意のホストコンピュータのための無線周波送受信機を実施するために、ソフトウェアと連携するプロセッサを使用することができる。
[実施態様１]
無線送受信ユニット（ＷＴＲＵ）における、多数のキャリアを用いて動作するアップリンクフィードバックのための方法であって、
前記ＷＴＲＵによって、複数の構成されたキャリアのセット上において、複数のトランスポートブロックを受信するステップと、
前記ＷＴＲＵによって、前記複数のトランスポートブロックについてのハイブリッド自動再送要求（ＨＡＲＱ）－肯定応答（ＡＣＫ）フィードバックを生成するステップと、
前記ＷＴＲＵによって、前記ＨＡＲＱ－ＡＣＫフィードバックのために使用するＨＡＲＱ－ＡＣＫフィードバックビットの数を決定するステップと、
ＨＡＲＱ－ＡＣＫフィードバックビットの前記数が閾値以下であるという条件で、前記ＷＴＲＵによって、前記ＨＡＲＱ－ＡＣＫフィードバックビットにリード－マラー符号化を適用するステップと、
前記ＷＴＲＵによって、前記エンコードされたＨＡＲＱ－ＡＣＫフィードバックビットを送信するステップと
を備えることを特徴とする方法。
[実施態様２]
フィードバックビットの前記数が閾値よりも多いという条件で、前記ＷＴＲＵによって、前記ＨＡＲＱ－ＡＣＫフィードバックビットに巡回冗長検査（ＣＲＣ）ビットを追加するステップ
をさらに備えることを特徴とする実施態様１の方法。
[実施態様３]
ＨＡＲＱ－ＡＣＫフィードバックビットの前記数が閾値よりも多いという条件で、前記ＷＴＲＵによって、前記ＨＡＲＱ－ＡＣＫフィードバックビットおよび前記ＣＲＣビットに畳み込み符号化を適用するステップと、
前記ＷＴＲＵによって、前記エンコードされたＨＡＲＱ－ＡＣＫフィードバックビットおよびＣＲＣビットを送信するステップと
をさらに備えることを特徴とする実施態様２の方法。
[実施態様４]
前記複数のトランスポートブロックについてのＨＡＲＱ－ＡＣＫフィードバックの前記生成は、前記複数の構成されたキャリアについての複数のダウンリンク割り当てインデックス（ＤＡＩ）フィールドに基づき、各ＤＡＩは、ダウンリンク割り当て内において示されることを特徴とする実施態様１の方法。
[実施態様５]
前記ＨＡＲＱ－ＡＣＫフィードバックのために使用するＨＡＲＱ－ＡＣＫフィードバックビットの前記数は、トランスポートブロックの数、構成されたキャリアからなる前記セット内のキャリアの数、および前記トランスポートブロックがその上で受信されるサブフレームの数に基づいて決定されることを特徴とする実施態様４の方法。
[実施態様６]
前記ＨＡＲＱ－ＡＣＫフィードバックのために使用するＨＡＲＱ－ＡＣＫフィードバックビットの前記数は、構成されたキャリアからなる前記セット内のキャリアに対する複数のダウンリンク割り当てに基づいて決定されることを特徴とする実施態様１の方法。
[実施態様７]
構成されたキャリアからなる前記セットは、６つ以上の構成されたキャリアを含むことを特徴とする実施態様１の方法。
[実施態様８]
前記ＨＡＲＱ－ＡＣＫフィードバックのために使用するＨＡＲＱ－ＡＣＫフィードバックビットの前記数は、複数のサブフレームの各々に対して決定されることを特徴とする実施態様１の方法。
[実施態様９]
多数のキャリアを用いて動作する無線送受信ユニット（ＷＴＲＵ）であって、
複数の構成されたキャリアのセット上において、複数のトランスポートブロックを受信するように構成されたプロセッサであって、
前記プロセッサは、前記複数のトランスポートブロックについてのハイブリッド自動再送要求（ＨＡＲＱ）－肯定応答（ＡＣＫ）フィードバックを生成するように構成され、
前記プロセッサは、前記ＨＡＲＱ－ＡＣＫフィードバックのために使用するＨＡＲＱ－ＡＣＫフィードバックビットの数を決定するように構成され、
前記プロセッサは、ＨＡＲＱ－ＡＣＫフィードバックビットの前記数が閾値以下であるという条件で、前記ＨＡＲＱ－ＡＣＫフィードバックビットにリード－マラー符号化を適用するように構成された、プロセッサと、
前記プロセッサに動作可能に結合された送受信機とを備え、
前記送受信機および前記プロセッサは、前記エンコードされたＨＡＲＱ－ＡＣＫフィードバックビットを送信するように構成されたことを特徴とするＷＴＲＵ。
[実施態様１０]
前記プロセッサは、フィードバックビットの前記数が閾値よりも多いという条件で、前記ＨＡＲＱ－ＡＣＫフィードバックビットに巡回冗長検査（ＣＲＣ）ビットを追加するようにさらに構成されことを特徴とする実施態様９のＷＴＲＵ。
[実施態様１１]
前記プロセッサは、ＨＡＲＱ－ＡＣＫフィードバックビットの前記数が閾値よりも多いという条件で、前記ＨＡＲＱ－ＡＣＫフィードバックビットおよび前記ＣＲＣビットに畳み込み符号化を適用するようにさらに構成され、
送受信機および前記プロセッサは、前記エンコードされたＨＡＲＱ－ＡＣＫフィードバックビットおよびＣＲＣビットを送信するようにさらに構成されことを特徴とする実施態様１０のＷＴＲＵ。
[実施態様１２]
前記複数のトランスポートブロックについてのＨＡＲＱ－ＡＣＫフィードバックの前記生成は、前記複数の構成されたキャリアについての複数のダウンリンク割り当てインデックス（ＤＡＩ）フィールドに基づき、各ＤＡＩは、ダウンリンク割り当て内において示されことを特徴とする実施態様９のＷＴＲＵ。
[実施態様１３]
前記ＨＡＲＱ－ＡＣＫフィードバックのために使用するＨＡＲＱ－ＡＣＫフィードバックビットの前記数は、トランスポートブロックの数、構成されたキャリアからなる前記セット内のキャリアの数、および前記トランスポートブロックがその上で受信されるサブフレームの数に基づいて決定されことを特徴とする実施態様１２のＷＴＲＵ。
[実施態様１４]
前記ＨＡＲＱ－ＡＣＫフィードバックのために使用するＨＡＲＱ－ＡＣＫフィードバックビットの前記数は、構成されたキャリアからなる前記セット内のキャリアに対する複数のダウンリンク割り当てに基づいて決定されことを特徴とする実施態様９のＷＴＲＵ。
[実施態様１５]
構成されたキャリアからなる前記セットは、６つ以上の構成されたキャリアを含むことを特徴とする実施態様９のＷＴＲＵ。
[実施態様１６]
前記ＨＡＲＱ－ＡＣＫフィードバックのために使用するＨＡＲＱ－ＡＣＫフィードバックビットの前記数は、複数のサブフレームの各々に対して決定されることを特徴とする実施態様９のＷＴＲＵ。
[実施態様１７]
無線送受信ユニット（ＷＴＲＵ）における、多数のキャリアを用いて動作するアップリンクフィードバックのための方法であって、
前記ＷＴＲＵによって、複数の構成されたキャリアのセット上において、複数のトランスポートブロックを受信するステップと、
前記ＷＴＲＵによって、前記複数のトランスポートブロックについてのハイブリッド自動再送要求（ＨＡＲＱ）－肯定応答（ＡＣＫ）フィードバックおよびチャネル状態情報（ＣＳＩ）フィードバックを生成するステップと、
前記ＷＴＲＵによって、前記ＨＡＲＱ－ＡＣＫフィードバックのために使用するＨＡＲＱ－ＡＣＫフィードバックビットの数と、前記ＣＳＩフィードバックのために使用するＣＳＩフィードバックビットの数とを含む、フィードバックメッセージを生成するステップと、
前記ＷＴＲＵによって、ＨＡＲＱ－ＡＣＫフィードバックビットの前記数と、ＣＳＩフィードバックビットの前記数とに基づいて、物理アップリンク制御チャネル（ＰＵＣＣＨ）フォーマットを決定するステップと、
前記ＷＴＲＵによって、前記決定されたＰＵＣＣＨフォーマットを使用して、前記フィードバックメッセージを送信するステップと
を備えることを特徴とする方法。
[実施態様１８]
ＨＡＲＱ－ＡＣＫフィードバックビットの前記数がゼロよりも多く、およびＣＳＩフィードバックビットの前記数がゼロよりも多いという条件で、前記ＷＴＲＵによって、第１のＰＵＣＣＨフォーマットまたは第２のＰＵＣＣＨフォーマットを選択するステップ
をさらに備えることを特徴とする実施態様１７の方法。
[実施態様１９]
ＨＡＲＱ－ＡＣＫフィードバックビットの前記数とＣＳＩフィードバックビットの前記数との合計が第１の閾値よりも多いという条件で、前記ＷＴＲＵによって、第１のＰＵＣＣＨフォーマットを選択するステップと、
ＨＡＲＱ－ＡＣＫフィードバックビットの前記数とＣＳＩフィードバックビットの前記数との合計が前記第１の閾値以下であるという条件で、前記ＷＴＲＵによって、第２のＰＵＣＣＨフォーマットを選択するステップと
をさらに備えることを特徴とする実施態様１８の方法。
[実施態様２０]
ＨＡＲＱ－ＡＣＫフィードバックビットの前記数がゼロに等しく、およびＣＳＩフィードバックビットの前記数がゼロよりも多いという条件で、前記ＷＴＲＵによって、第１のＰＵＣＣＨフォーマットまたは第３のＰＵＣＣＨフォーマットを選択するステップ
をさらに備えることを特徴とする実施態様１７の方法。
[実施態様２１]
ＣＳＩフィードバックビットの前記数が第２の閾値よりも多いという条件で、前記ＷＴＲＵによって、第１のＰＵＣＣＨフォーマットを選択するステップと、
ＣＳＩフィードバックビットの前記数が前記第２の閾値以下であるという条件で、前記ＷＴＲＵによって、第３のＰＵＣＣＨフォーマットを選択するステップと
をさらに備えることを特徴とする実施態様２０の方法。
[実施態様２２]
ＨＡＲＱ－ＡＣＫフィードバックビットの前記数がゼロよりも多く、およびＣＳＩフィードバックビットの前記数がゼロに等しいという条件で、前記ＷＴＲＵによって、第１のＰＵＣＣＨフォーマットまたは第４のＰＵＣＣＨフォーマットを選択するステップ
をさらに備えることを特徴とする実施態様１７の方法。
[実施態様２３]
ＨＡＲＱ－ＡＣＫフィードバックビットの前記数が第３の閾値よりも多いという条件で、前記ＷＴＲＵによって、第１のＰＵＣＣＨフォーマットを選択するステップと、
ＨＡＲＱ－ＡＣＫフィードバックビットの前記数が前記第３の閾値以下であるという条件で、前記ＷＴＲＵによって、第４のＰＵＣＣＨフォーマットを選択するステップと
をさらに備えることを特徴とする実施態様２２の方法。
[実施態様２４]
前記ＨＡＲＱ－ＡＣＫフィードバックのために使用するＨＡＲＱ－ＡＣＫフィードバックビットの前記数は、構成されたキャリアからなる前記セット内のキャリアに対する複数のダウンリンク割り当てに基づいて決定されることを特徴とする実施態様１７の方法。
[実施態様２５]
前記ＣＳＩフィードバックのために使用するＣＳＩフィードバックビットの前記数は、構成されたキャリアからなる前記セット内のキャリアに対する複数のダウンリンク割り当てに基づいて決定されることを特徴とする実施態様１７の方法。
[実施態様２６]
前記ＨＡＲＱ－ＡＣＫフィードバックのために使用するＨＡＲＱ－ＡＣＫフィードバックビットの前記数は、トランスポートブロックの数、構成されたキャリアからなる前記セット内のキャリアの数、および前記トランスポートブロックがその上で受信されるサブフレームの数に基づいて決定されることを特徴とする実施態様１７の方法。
[実施態様２７]
前記ＣＳＩフィードバックのために使用するＣＳＩフィードバックビットの前記数は、トランスポートブロックの数、構成されたキャリアからなる前記セット内のキャリアの数、および前記トランスポートブロックがその上で受信されるサブフレームの数に基づいて決定されることを特徴とする実施態様１７の方法。
[実施態様２８]
構成されたキャリアからなる前記セットは、６つ以上の構成されたキャリアを含むことを特徴とする実施態様１７の方法。

【産業上の利用可能性】

【0369】

本発明は、一般的に無線通信システムに利用することができる。

【符号の説明】

【0370】

１００ 通信システム
１０２ａ～１０２ｄ ワイヤレス送信／受信ユニット（ＷＴＲＵ）
１０３ ＲＡＮ
１０６ コアネットワーク
１０８ ＰＳＴＮ
１１０ インターネット
１１２ その他のネットワーク
１１８ プロセッサ
１２０ トランシーバ
１２２ アンテナ

【図1A】

【図1B】

【図1C】

【図2】

【図3】

【図4】

【図5】

【手続補正書】

【提出日】2022-06-08

【手続補正1】

【補正対象書類名】特許請求の範囲

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【特許請求の範囲】

【請求項1】

無線送受信ユニット（ＷＴＲＵ）であって、
１つ以上の物理ダウンリンク共有チャネル（ＰＤＳＣＨ）送信に関連付けられたダウンリンク制御情報（ＤＣＩ）を受信し、前記ＤＣＩは、
前記１つ以上のＰＤＳＣＨ送信に割り当てられたフィードバックグループのインジケーション、および、
前記フィードバックグループに関連付けられたスケジューリング情報を含み、
前記１つ以上のＰＤＳＣＨ送信の第１のＰＤＳＣＨ送信を受信し、
前記１つ以上のＰＤＳＣＨ送信に割り当てられたフィードバックグループに基づいて、前記第１のＰＤＳＣＨ送信に対するハイブリッド自動再送要求（ＨＡＲＱ）フィードバックを送信し、前記第１のＰＤＳＣＨ送信に対する前記ＨＡＲＱフィードバックは、前記１つ以上のＰＤＳＣＨ送信に割り当てられた前記フィードバックグループと関連付けられたスケジューリング情報にしたがって送信される
よう構成されたプロセッサおよびメモリ
を備えたＷＴＲＵ。

【請求項2】

前記プロセッサおよびメモリは、
前記１つ以上のＰＤＳＣＨ送信の第２のＰＤＳＣＨ送信を受信し、
前記受信されたＤＣＩに基づいて、前記第１のＰＤＳＣＨ送信と関連付けられた前記ＨＡＲＱフィードバックと、前記第２のＰＤＳＣＨ送信と関連付けられたＨＡＲＱフィードバックを多重化するかどうかを決定し、前記受信されたＤＣＩが前記第１のＰＤＳＣＨ送信と関連付けられた前記ＨＡＲＱフィードバックおよび前記第２のＰＤＳＣＨ送信と関連付けられた前記ＨＡＲＱフィードバックが多重化されるべきと示している条件で、前記第１のＰＤＳＣＨ送信と関連付けられた前記ＨＡＲＱフィードバックおよび前記第２のＰＤＳＣＨ送信と関連付けられた前記ＨＡＲＱフィードバックが多重化される
ようさらに構成された請求項１に記載のＷＴＲＵ。

【請求項3】

前記第２のＰＤＳＣＨ送信は、第２のフィードバックグループと関連付けられている請求項２に記載のＷＴＲＵ。

【請求項4】

前記第１のＰＤＳＣＨ送信および前記第２のＰＤＳＣＨ送信は、同一のキャリア上で受信される請求項２に記載のＷＴＲＵ。

【請求項5】

前記受信されたＤＣＩは、それぞれのフィードバックグループの各々と関連付けられたコードブックのインジケーションをさらに含む請求項１に記載のＷＴＲＵ。

【請求項6】

前記スケジューリング情報は、フィードバックグループに対するフィードバックを送信するための１つ以上の物理アップリンク制御チャネル（ＰＵＣＣＨ）リソースを示している請求項１に記載のＷＴＲＵ。

【請求項7】

前記第１のＰＤＳＣＨ送信と関連付けられた前記ＨＡＲＱフィードバックは、アンライセンスバンドを使用して送信される請求項１に記載のＷＴＲＵ。

【請求項8】

前記１つ以上のＰＤＳＣＨ送信に関連付けられた前記ＤＣＩは、アップリンク制御情報に対する要求をさらに含む請求項１に記載のＷＴＲＵ。

【請求項9】

１つ以上の物理ダウンリンク共有チャネル（ＰＤＳＣＨ）送信に関連付けられたダウンリンク制御情報（ＤＣＩ）を受信するステップであって、前記ＤＣＩは、
前記１つ以上のＰＤＳＣＨ送信に割り当てられたフィードバックグループのインジケーション、および、
前記フィードバックグループに関連付けられたスケジューリング情報を含む、ステップと、
前記１つ以上のＰＤＳＣＨ送信の第１のＰＤＳＣＨ送信を受信するステップと、
前記１つ以上のＰＤＳＣＨ送信に割り当てられたフィードバックグループに基づいて、前記第１のＰＤＳＣＨ送信に対するハイブリッド自動再送要求（ＨＡＲＱ）フィードバックを送信するステップであって、前記第１のＰＤＳＣＨ送信に対する前記ＨＡＲＱフィードバックは、前記１つ以上のＰＤＳＣＨ送信に割り当てられた前記フィードバックグループと関連付けられたスケジューリング情報にしたがって送信される、ステップと
を備える方法。

【請求項10】

前記１つ以上のＰＤＳＣＨ送信の第２のＰＤＳＣＨ送信を受信するステップと、
前記受信されたＤＣＩに基づいて、前記第１のＰＤＳＣＨ送信と関連付けられた前記ＨＡＲＱフィードバックと、前記第２のＰＤＳＣＨ送信と関連付けられたＨＡＲＱフィードバックを多重化するかどうかを決定するステップであって、前記受信されたＤＣＩが、前記第１のＰＤＳＣＨ送信と関連付けられた前記ＨＡＲＱフィードバックおよび前記第２のＰＤＳＣＨ送信と関連付けられた前記ＨＡＲＱフィードバックが多重化されるべきと示している条件で、前記第１のＰＤＳＣＨ送信と関連付けられた前記ＨＡＲＱフィードバックおよび前記第２のＰＤＳＣＨ送信と関連付けられた前記ＨＡＲＱフィードバックが多重化される、ステップと
をさらに備える請求項９に記載の方法。

【請求項11】

前記第２のＰＤＳＣＨ送信は、第２のフィードバックグループと関連付けられている請求項１０に記載の方法。

【請求項12】

前記第１のＰＤＳＣＨ送信および前記第２のＰＤＳＣＨ送信は、同一のキャリア上で受信される請求項１０に記載の方法。

【請求項13】

前記受信されたＤＣＩは、それぞれのフィードバックグループの各々と関連付けられたコードブックのインジケーションをさらに含む請求項９に記載の方法。

【請求項14】

前記スケジューリング情報は、フィードバックグループに対するフィードバックを送信するための１つ以上の物理アップリンク制御チャネル（ＰＵＣＣＨ）リソースを示している請求項９に記載の方法。

【請求項15】

前記第１のＰＤＳＣＨ送信と関連付けられた前記ＨＡＲＱフィードバックは、アンライセンスバンドを使用して送信される請求項９に記載の方法。

【請求項16】

前記１つ以上のＰＤＳＣＨ送信に関連付けられた前記ＤＣＩは、アップリンク制御情報に対する要求をさらに含む請求項９に記載の方法。