(57)【特許請求の範囲】
【請求項１】
無線送受信ユニット（ＷＴＲＵ）で用いる方法であって、
物理ダウンリンク制御チャネル（ＰＤＣＣＨ）を介して、ダウンリンク制御情報（ＤＣＩ）を受信することと、
前記ＤＣＩが少なくとも１つのトランスポートブロック（ＴＢ）のコードブロックグループ（ＣＢＧ）に基づく再送信を示すフィールドを含まないという条件で、前記少なくとも１つのＴＢにおけるＣＢＧの数に基づいて、単一ビットを複数回繰り返すことによってマルチビットハイブリッド自動再送要求（ＨＡＲＱ）フィードバックを生成することと、
物理アップリンク制御チャネル（ＰＵＣＣＨ）を介して、前記ＣＢＧに基づく再送信のための前記マルチビットＨＡＲＱフィードバックを送信することと
を備え、
前記ＷＴＲＵは、ＴＢに基づく再送信のための単一ビットＨＡＲＱフィードバックおよび前記ＣＢＧに基づく再送信のための前記マルチビットＨＡＲＱフィードバックを提供するように構成される、方法。
【請求項２】
前記ＤＣＩが前記少なくとも１つのＴＢの前記ＣＢＧに基づく再送信を示すフィールドを含むという条件で、前記ＰＵＣＣＨを介して、前記ＣＢＧに基づく再送信のためのマルチビットＨＡＲＱフィードバックを送信することをさらに備える、請求項１の方法。
【請求項３】
前記マルチビットＨＡＲＱフィードバックは、前記少なくとも１つのＴＢにおける少なくとも１つのＣＢＧが再送信を要求されるかどうかを示す複数のビットを備える、請求項１の方法。
【請求項４】
前記複数のビットのそれぞれは、前記少なくとも１つのＴＢにおける少なくとも１つのＣＢＧのそれぞれにマップする、請求項３の方法。
【請求項５】
前記マルチビットＨＡＲＱフィードバックは、上位レイヤのパラメータに基づいて最大数のＣＢＧによって半静的に構成され、前記上位レイヤのパラメータは、媒体アクセス制御（ＭＡＣ）レイヤよりも高いレイヤから受信される、請求項１の方法。
【請求項６】
前記最大数のＣＢＧに基づいて、前記マルチビットＨＡＲＱフィードバックのペイロードサイズを決定することをさらに備える、請求項５の方法。
【請求項７】
前記少なくとも１つのＴＢにおけるそれぞれのＣＢＧの全てのＣＢが正確に復号され、かつ前記少なくとも１つのＴＢが正確に復号されるという条件で、前記マルチビットＨＡＲＱフィードバックにおける前記それぞれのＣＢＧに関連付けられる前記単一ビットに対する肯定応答（ＡＣＫ）を決定することをさらに備える、請求項１の方法。
【請求項８】
前記少なくとも１つのＴＢにおけるそれぞれのＣＢＧの全てのＣＢが正確に復号されるが、前記少なくとも１つのＴＢが正確に復号されないという条件で、前記マルチビットＨＡＲＱフィードバックにおける前記それぞれのＣＢＧに関連付けられる前記単一ビットに対する否定応答（ＮＡＣＫ）を決定することをさらに備える、請求項１の方法。
【請求項９】
前記少なくとも１つのＴＢの前記ＣＢＧに基づく再送信を示す前記フィールドを含まない前記ＤＣＩが、フォールバックＤＣＩである、請求項１の方法。
【請求項１０】
無線送受信ユニット（ＷＴＲＵ）であって、
物理ダウンリンク制御チャネル（ＰＤＣＣＨ）を介して、ダウンリンク制御情報（ＤＣＩ）を受信するように構成された受信機と、
前記ＤＣＩが少なくとも１つのトランスポートブロック（ＴＢ）のコードブロックグループ（ＣＢＧ）に基づく再送信を示すフィールドを含まないという条件で、前記少なくとも１つのＴＢにおけるＣＢＧの数に基づいて、単一ビットを複数回繰り返すことによってマルチビットハイブリッド自動再送要求（ＨＡＲＱ）フィードバックを生成するように構成されたプロセッサと、
物理アップリンク制御チャネル（ＰＵＣＣＨ）を介して、前記ＣＢＧに基づく再送信のための前記マルチビットＨＡＲＱフィードバックを送信するように構成された送信機と
を備え、
前記プロセッサは、ＴＢに基づく再送信のための単一ビットＨＡＲＱフィードバックおよび前記ＣＢＧに基づく再送信のための前記マルチビットＨＡＲＱフィードバックを提供するように構成される、ＷＴＲＵ。
【請求項１１】
前記送信機は、前記ＤＣＩが前記少なくとも１つのＴＢの前記ＣＢＧに基づく再送信を示すフィールドを含むという条件で、前記ＰＵＣＣＨを介して、前記ＣＢＧに基づく再送信のためのマルチビットＨＡＲＱフィードバックを送信するようにさらに構成される、請求項１０のＷＴＲＵ。
【請求項１２】
前記マルチビットＨＡＲＱフィードバックは、前記少なくとも１つのＴＢにおける少なくとも１つのＣＢＧが再送信を要求されるかどうかを示す複数のビットを備える、請求項１０のＷＴＲＵ。
【請求項１３】
前記複数のビットのそれぞれは、前記少なくとも１つのＴＢにおける少なくとも１つのＣＢＧのそれぞれにマップする、請求項１２のＷＴＲＵ。
【請求項１４】
前記マルチビットＨＡＲＱフィードバックは、上位レイヤのパラメータに基づいて最大数のＣＢＧによって半静的に構成され、前記上位レイヤのパラメータは、媒体アクセス制御（ＭＡＣ）レイヤよりも高いレイヤから受信される、請求項１０のＷＴＲＵ。
【請求項１５】
前記プロセッサは、前記最大数のＣＢＧに基づいて、前記マルチビットＨＡＲＱフィードバックのペイロードサイズを決定するようにさらに構成される、請求項１４のＷＴＲＵ。
【請求項１６】
前記プロセッサは、前記少なくとも１つのＴＢにおけるそれぞれのＣＢＧの全てのＣＢが正確に復号され、かつ前記少なくとも１つのＴＢが正確に復号されるという条件で、前記マルチビットＨＡＲＱフィードバックにおける前記それぞれのＣＢＧに関連付けられる前記単一ビットに対する肯定応答（ＡＣＫ）を決定するようにさらに構成される、請求項１０のＷＴＲＵ。
【請求項１７】
前記プロセッサは、前記少なくとも１つのＴＢにおけるそれぞれのＣＢＧの全てのＣＢが正確に復号されるが、前記少なくとも１つのＴＢが正確に復号されないという条件で、前記マルチビットＨＡＲＱフィードバックにおける前記それぞれのＣＢＧに関連付けられる前記単一ビットに対する否定応答（ＮＡＣＫ）を決定するようにさらに構成される、請求項１０のＷＴＲＵ。
【請求項１８】
前記少なくとも１つのＴＢの前記ＣＢＧに基づく再送信を示す前記フィールドを含まない前記ＤＣＩが、フォールバックＤＣＩである、請求項１０のＷＴＲＵ。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願の相互参照
本出願は、参照によりその内容が本明細書に組み込まれる、2018年1月10日に出願された米国特許仮出願第62/615,744号、2017年8月9日に出願された米国特許仮出願第62/543,047号、2017年6月14日に出願された米国特許仮出願第62/519,372号、および、2017年5月3日に出願された米国特許仮出願第62/500,938号の利益を主張する。
【背景技術】
【０００２】
ハイブリッド自動再送要求（ＨＡＲＱ）は、ソフト合成誤り訂正とＡＲＱ誤り制御との組み合わせである。ソフト合成誤り訂正技法によれば、適切に復号されなかったデータパケットは、もはや廃棄されない。代わりに、受信データは、バッファ内に記憶され、次の再送信と合成される。破損されたメッセージを検出した受信機は、フィードバックメッセージを送信することによって、送信機からの新たなメッセージ（すなわち、再送信）を要求する。これらのフィードバックメッセージは、それぞれ、以前の送信の良好な（すなわち、肯定応答）または不良な（すなわち、否定応答）受信を通知するために、受信機から送信機へと送信される。ロングタームエボリューション（ＬＴＥ）において、これらの再送信は、物理レイヤに与えられる上位レイヤからのデータであるトランスポートブロック（ＴＢ）に基づく。受信されているＴＢが適切に復号されない（すなわち、破損されている）場合、無線送受信ユニット（ＷＴＲＵ）が、否定応答（ＮＡＣＫ）を送信することができ、それによって、基地局（ＢＳ）がＴＢ全体を再送信することになる。ＢＳが、最初に高速大容量モバイルブロードバンド（ｅＭＢＢ）トラフィックの存在下で超高信頼低遅延（ＵＲＬＬＣ）トラフィックをサービスする必要がある新無線（ＮＲ）においては、ＴＢ内で検出される誤りの小さい部分に起因してＴＢ全体を再び送信することは、非常に非効率的である。従って、ネットワーク／デバイス構成に応じて、コードブロック（ＣＢ）、コードブロックグループ（ＣＢＧ）、またはトランスポートブロック（ＴＢ）に基づいてフィードバックメッセージを提供するより柔軟な再送信方式があることが望ましい。
【発明の概要】
【０００３】
無線送受信ユニット（ＷＴＲＵ）において単一ビットハイブリッド自動再送要求（ＨＡＲＱ）フィードバックおよびマルチビットＨＡＲＱフィードバックを提供するための方法および装置が説明される。例えば、ＷＴＲＵは、物理ダウンリンク制御チャネル（ＰＤＣＣＨ）を介して、ダウンリンク制御情報（ＤＣＩ）を受信することができる。ＤＣＩは、少なくとも１つのトランスポートブロック（ＴＢ）のコードブロックグループ（ＣＢＧ）に基づく再送信を示すフィールドを含むことができる。ＤＣＩが、少なくとも１つのトランスポートブロック（ＴＢ）のＣＢＧに基づく再送信を示すフィールドを含まない状態では、ＷＴＲＵは、物理アップリンク制御チャネル（ＰＵＣＣＨ）を介して、ＴＢに基づく再送信のための単一ビットＨＡＲＱフィードバックを送信することができる。ＤＣＩが、少なくとも１つのトランスポートブロック（ＴＢ）のＣＢＧに基づく再送信を示すフィールドを含む状態では、ＷＴＲＵは、ＰＵＣＣＨを介して、ＣＢＧに基づく再送信のためのマルチビットＨＡＲＱフィードバックを送信することができる。マルチビットＨＡＲＱフィードバックは、少なくとも１つのＴＢ内の少なくとも１つのＣＢＧが再送信のために要求されるか否かを示す複数のビットを含むことができる。複数のビットの各々は、それぞれ、少なくとも１つのＴＢ内の少なくとも１つのＣＢＧの各々にマッピングする。マルチビットＨＡＲＱフィードバックはまた、上位レイヤのパラメータに基づいて最大数のＣＢＧによって半静的に構成されることもできる。ＷＴＲＵは、ＴＢに基づく再送信のための単一ビットＨＡＲＱフィードバックおよびＣＢＧに基づく再送信のためのマルチビットＨＡＲＱフィードバックを提供するように構成されることができる。
【図面の簡単な説明】
【０００４】
添付図面とともに例として与えられる以下の詳細説明から、詳細な理解が得られ得る。
【図１Ａ】１つまたは複数の開示される実施形態が実施されることができる例示的な通信システムを示すシステム図である。
【図１Ｂ】一実施形態による、図１Ａに示される通信システム内で使用されることができる例示的な無線送受信ユニット（ＷＴＲＵ）を示すシステム図である。
【図１Ｃ】一実施形態による、図１Ａに示される通信システム内で使用されることができる例示的な無線アクセスネットワーク（ＲＡＮ）および例示的なコアネットワーク（ＣＮ）を示すシステム図である。
【図１Ｄ】一実施形態による、図１Ａに示される通信システム内で使用されることができるさらなる例示的なＲＡＮおよびさらなる例示的なＣＮを示すシステム図である。
【図２】例示的なコードブロック（ＣＢ）セグメント化およびＣＢごとの巡回冗長検査（ＣＲＣ）挿入を示す図である。
【図３】超高信頼低遅延（ＵＲＬＬＣ）トラフィックによる高速大容量モバイルブロードバンド（ｅＭＢＢ）トラフィックの例示的なプリエンプションを示す図である。
【図４Ａ】マルチビットハイブリッド自動再送要求（ＨＡＲＱ）フィードバックが、再送信のＣＢレベルの粒度を可能にする、例示的なマルチビットＨＡＲＱフィードバックを示す図である。
【図４Ｂ】マルチビットＨＡＲＱフィードバックが、再送信のコードブロックグループ（ＣＢＧ）レベルの粒度を可能にする、例示的なマルチビットＨＡＲＱフィードバックを示す図である。
【図４Ｃ】マルチビットＨＡＲＱフィードバックが、再送信のＣＢＧレベルの粒度を可能にする、別の例示的なマルチビットＨＡＲＱフィードバックを示す図である。
【図５】ダウンリンク制御情報（ＤＣＩ）に基づいて単一ビットＨＡＲＱフィードバックおよび／またはマルチビットＨＡＲＱフィードバックを提供するための例示的なシグナリング手順を示す図である。
【図６】ダウンリンク制御情報（ＤＣＩ）に基づいて単一ビットＨＡＲＱフィードバックおよび／またはマルチビットＨＡＲＱフィードバックを提供するための例示的な手順を示す図である。
【図７】ＷＴＲＵが提供すべきである単一ビットＨＡＲＱフィードバックおよび／またはマルチビットＨＡＲＱフィードバックを決定するための例示的な手順を示す図である。
【図８】例示的な可変ビットのＣＢＧに基づくＨＡＲＱフィードバックとは対照的な、例示的な固定ビットのＣＢＧに基づくＨＡＲＱフィードバックを示す図である。
【図９】ダウンリンク（ＤＬ）システム帯域幅の中間部分がプリエンプション可能な領域として指定されている、例示的な、黙示的なプリエンプション指示を示す図である。
【図１０】ミニスロットタイミングによるスロット内の例示的な早期のＨＡＲＱフィードバックを示す図である。
【図１１】ミニスロットタイミングによるスロット内の早期のＨＡＲＱフィードバックを決定するための例示的な手順を示す図である。
【発明を実施するための形態】
【０００５】
図１Ａは、１つまたは複数の開示される実施形態が実施され得る例示的な通信システム１００を示す図である。通信システム１００は、音声、データ、ビデオ、メッセージング、ブロードキャストなどのコンテンツを複数の無線ユーザに提供する多重アクセスシステムであることができる。通信システム１００は、複数の無線ユーザが、無線帯域幅を含むシステム資源の共有を通じてこのようなコンテンツにアクセスすることを可能にする。例えば、通信システム１００は、コード分割多重アクセス（ＣＤＭＡ）、時分割多重アクセス（ＴＤＭＡ）、周波数分割多重アクセス（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、単一キャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）、ゼロテールユニークワードＤＦＴ拡散ＯＦＤＭ（ＺＴ  ＵＷ  ＤＴＳ−ｓ  ＯＦＤＭ）、ユニークワードＯＦＤＭ（ＵＷ−ＯＦＤＭ）、リソースブロックフィルタ処理済みＯＦＤＭ、フィルタバンクマルチキャリア（ＦＢＭＣ）などの１つまたは複数のチャネルアクセス方法を採用することができる。
【０００６】
図１Ａに示されるように、通信システム１００は、無線送受信ユニット（ＷＴＲＵ）１０２ａ、１０２ｂ、１０２ｃ、１０２ｄ、ＲＡＮ１０４／１１３、ＣＮ１０６／１１５、公衆交換電話回線網（ＰＳＴＮ）１０８、インターネット１１０、および他のネットワーク１１２を含むことができるが、開示される実施形態は任意の数のＷＴＲＵ、基地局、ネットワーク、および／またはネットワーク要素を考慮することが諒解されよう。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの各々は、無線環境において動作および／または通信するように構成される任意のタイプのデバイスであることができる。例えば、いずれかが「局」および／または「ＳＴＡ」として参照される場合があるＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、無線信号を送信および／または受信するように構成され得、ユーザ機器（ＵＥ）、移動局、固定またはモバイル加入者ユニット、サブスクリプションに基づくユニット、ページャ、セルラ電話、ＰＤＡ、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、無線センサ、ホットスポットまたはＭｉ−Ｆｉデバイス、ＩｏＴデバイス、腕時計または他のウェアラブル、ヘッドマウントディスプレイ（ＨＭＤ）、車両、ドローン、医療デバイスおよびアプリケーション（例えば、遠隔手術）、産業用デバイスおよびアプリケーション（例えば、産業および／または自動処理チェーンコンテキストで動作するロボットおよび／または他の無線デバイス）、家庭用電子機器デバイス、商用および／または産業用無線ネットワーク上で動作するデバイスなどを含み得る。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃおよび１０２ｄのいずれかは、互換的にＵＥとして参照される場合がある。
【０００７】
通信システム１００はまた、基地局１１４ａおよび／または基地局１１４ｂをも含むことができる。基地局１１４ａ、１１４ｂの各々は、ＣＮ１０６／１１５、インターネット１１０、および／または他のネットワーク１１２などの１つまたは複数の通信ネットワークへのアクセスを容易にするために、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの少なくとも１つと無線でインターフェースするように構成される任意のタイプのデバイスであることができる。例えば、基地局１１４ａ、１１４ｂは、ベーストランシーバ基地局（ＢＴＳ）、Ｎｏｄｅ−Ｂ、ｅＮｏｄｅ  Ｂ、Ｈｏｍｅ  Ｎｏｄｅ  Ｂ、Ｈｏｍｅ  ｅＮｏｄｅ  Ｂ、ｇＮＢ、ＮＲ  ＮｏｄｅＢ、サイトコントローラ、アクセスポイント（ＡＰ）、無線ルータなどであることができる。基地局１１４ａ、１１４ｂは各々単一の要素として描かれているが、基地局１１４ａ、１１４ｂは、任意の数の相互接続された基地局および／またはネットワーク要素を含んでもよいことが諒解されよう。
【０００８】
基地局１１４ａは、ＲＡＮ１０４／１１３の一部であってもよく、これは、基地局コントローラ（ＢＳＣ）、無線通信ネットワークコントローラ（ＲＮＣ）、中継ノードなどの、他の基地局および／またはネットワーク要素（図示せず）も含むことができる。基地局１１４ａおよび／または基地局１１４ｂは、セル（図示せず）として参照される場合がある１つまたは複数の搬送波周波数において無線信号を送信および／また受信するように構成されることができる。これらの周波数は、認可スペクトル、無認可スペクトル、または認可スペクトルと無認可スペクトルとの組み合わせ中にあり得る。セルは、比較的固定され得るか、または時間とともに変化し得る特定の地理的領域に無線サービスのためのカバレージを与えることができる。セルは、複数のセルセクタにさらに分割されることができる。例えば、基地局１１４ａに関連付けられるセルは、３つのセクタに分割されることができる。従って、１つの実施形態では、基地局１１４ａは、３つの送受信機、すなわち、セルのセクタごとに１つずつ、を含むことができる。一実施形態において、基地局１１４ａはＭＩＭＯ技術を採用してもよく、セルのセクタごとに複数の送受信機を利用してもよい。例えば、所望の空間的方向内で信号を送信および／または受信するために、ビームフォーミングが使用され得る。
【０００９】
基地局１１４ａ、１１４ｂは、エアインターフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの１つまたは複数と通信することができ、このエアインターフェースは、任意の適切な無線通信リンク（例えば、無線周波数（ＲＦ）、マイクロ波、センチメートル波、マイクロメートル波、赤外線（ＩＲ）、紫外線（ＵＶ）、可視光など）であることができる。エアインターフェース１１６は、任意の適切な無線通信アクセス技術（ＲＡＴ）を使用して確立されることができる。
【００１０】
より具体的には、上記のように、通信システム１００は、多重アクセスシステムであることができ、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、ＳＣ−ＦＤＭＡなどの１つまたは複数のチャネルアクセス方式を採用することができる。例えば、ＲＡＮ１０４／１１３内の基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、広帯域ＣＤＭＡ（ＷＣＤＭＡ（登録商標））を使用してエアインターフェース１１５／１１６／１１７を確立することができる、ユニバーサルモバイルテレコミュニケーションシステム（ＵＭＴＳ）地上波無線通信アクセス（ＵＴＲＡ）などの無線技術を実施することができる。ＷＣＤＭＡは、高速パケットアクセス（ＨＳＰＡ）および／または発展型ＨＳＰＡ（Ｅｖｏｌｖｅｄ  ＨＳＰＡ）（ＨＳＰＡ＋）などの通信プロトコルを含むことができる。ＨＳＰＡは、高速ダウンリンク（ＤＬ）パケットアクセス（ＨＳＤＰＡ）および／または高速ＵＬパケットアクセス（ＨＳＵＰＡ）を含むことができる。
【００１１】
一実施形態において、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ロングタームエボリューション（ＬＴＥ）および／またはＬＴＥ−Ａｄｖａｎｃｅｄ（ＬＴＥ−Ａ）および／またはＬＴＥ−Ａｄｖａｎｃｅｄ  Ｐｒｏ（ＬＴＥ−Ａ  Ｐｒｏ）を使用してエアインターフェース１１６を確立することができる、発展型ＵＭＴＳ地上波無線通信アクセス（Ｅ−ＵＴＲＡ）などの無線技術を実施してもよい。
【００１２】
一実施形態において、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、新無線（ＮＲ）を使用してエアインターフェース１１６を確立することができる、ＮＲ無線アクセスなどの無線技術を実施することができる。
【００１３】
一実施形態では、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、複数の無線アクセス技術を実施することができる。例えば、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、例えば、デュアル接続性（ＤＣ）原理を使用してＬＴＥ無線アクセスとＮＲ無線アクセスとをともに実施することができる。従って、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃによって利用されるエアインターフェースは、複数のタイプの無線アクセス技術および／または複数のタイプの基地局（例えば、ｅＮＢおよびｇＮＢ）との間で送られる送信によって特徴づけられ得る。
【００１４】
他の実施形態において、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＩＥＥＥ８０２．１１（すなわち、ＷｉＦｉ）、ＩＥＥＥ８０２．１６（すなわち、ＷｉＭＡＸ）、ＣＤＭＡ２０００、ＣＤＭＡ２０００  １Ｘ、ＣＤＭＡ２０００ＥＶ−ＤＯ、ＩＳ−２０００（Interim Standard2000）、ＩＳ−９５（Interim Standard95）、ＩＳ−８５６（Interim Standard856）、移動体通信用グローバルシステム（ＧＳＭ（登録商標））、ＧＳＭ進化型高速データレート（ＥＤＧＥ）、ＧＳＭ  ＥＤＧＥ（ＧＥＲＡＮ）などの無線技術を実施してもよい。
【００１５】
図１Ａ中の基地局１１４ｂは、例えば、無線ルータ、Ｈｏｍｅ  Ｎｏｄｅ  Ｂ、Ｈｏｍｅ  ｅＮｏｄｅ  Ｂ、またはアクセスポイントであることができ、職場、家庭、車両、構内、産業設備、（例えば、ドローンが使用するための）空中回廊、道路などの局所的領域における無線接続を容易にするために任意の適切なＲＡＴを利用することができる。１つの実施形態では、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、無線ローカルエリアネットワーク（ＷＬＡＮ）を確立するためにＩＥＥＥ８０２．１１などの無線技術を実施することができる。一実施形態では、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、無線パーソナルエリアネットワーク（ＷＰＡＮ）を確立するために、ＩＥＥＥ８０２．１５などの無線技術を実施してもよい。別の実施形態では、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、ピコセルまたはフェムトセルを確立するためにセルラベースのＲＡＴ（例えば、ＷＣＤＭＡ、ＣＤＭＡ２０００、ＧＳＭ、ＬＴＥ、ＬＴＥ−Ａ、ＬＴＥ−Ａ  Ｐｒｏ、ＮＲなど）を利用することができる。図１Ａに示されるように、基地局１１４ｂはインターネット１１０に直接接続することができる。従って、基地局１１４ｂは、ＣＮ１０６／１１５を介してインターネット１１０にアクセスしなくてもよい。
【００１６】
ＲＡＮ１０４／１１３は、ＣＮ１０６／１１５と通信することができ、これは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの１つまたは複数に音声、データ、アプリケーション、および／またはＶｏＩＰサービスを提供するように構成される任意のタイプのネットワークであることができる。データは、異なるスループット要件、レイテンシ要件、誤り耐性要件、信頼性要件、データスループット要件、モビリティ要件などの変動するサービス品質（ＱｏＳ）要件を有し得る。ＣＮ１０６／１１５は、呼制御、課金サービス、モバイル位置情報サービス、プリペイド発呼、インターネット接続、ビデオ配信などを可能にし、および／またはユーザ認証などの高レベルなセキュリティ機能を実行することができる。図１Ａには示されていないが、ＲＡＮ１０４／１１３および／またはＣＮ１０６／１１５は、ＲＡＮ１０４／１１３と同じＲＡＴまたは異なるＲＡＴを採用する他のＲＡＮと直接または間接的に通信することができることが諒解されよう。例えば、ＲＡＮ１０４／１１３に接続されていることに加えて、これはＮＲ無線技術を利用することであり得るが、ＣＮ１０６／１１５は、ＧＳＭ、ＵＭＴＳ、ＣＤＭＡ２０００、ＷｉＭＡＸ、Ｅ−ＵＴＲＡ、またはＷｉＦｉ無線技術を採用する別のＲＡＮ（図示せず）とも通信することができる。
【００１７】
ＣＮ１０６／１１５はまた、ＰＳＴＮ１０８、インターネット１１０、および／または他のネットワーク１１２にアクセスするためにＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのためのゲートウェイとしての役割を果たすことができる。ＰＳＴＮ１０８は、基本電話サービス（ＰＯＴＳ）を提供する回線交換電話回線網を含み得る。インターネット１１０は、相互接続されたコンピュータネットワークと、ＴＣＰ／ＩＰインターネットプロコトルスイート内のＴＣＰ、ＵＤＰ、および／またはＩＰなどの共通の通信プロトコルを使用するデバイスとから成る地球規模のシステムを含むことができる。ネットワーク１１２は、他のサービス提供者によって所有および／または運営される有線および／または無線通信ネットワークを含むことができる。例えば、ネットワーク１１２は、ＲＡＮ１０４／１１３と同じＲＡＴまたは異なるＲＡＴを採用することができる、１つまたは複数のＲＡＮに接続される別のＣＮを含んでもよい。
【００１８】
通信システム１００内のＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのいくつかまたは全ては、マルチモード機能を含むことができる（例えば、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、種々の無線リンクにわたって種々の無線ネットワークと通信するための複数の送受信機を含むことができる）。例えば、図１Ａに示されるＷＴＲＵ１２０ｃは、これは、セルラベースの無線技術を採用することができる基地局１１４ａと通信し、ＩＥＥＥ８０２無線技術を採用することができる基地局１１４ｂと通信するように構成されることができる。
【００１９】
図１Ｂは、例示的なＷＴＲＵ１０２を示すシステム図である。図１Ｂに示されるように、ＷＴＲＵ１０２は、とりわけ、プロセッサ１１８、送受信機１２０、送受信要素１２２、スピーカ／マイク１２４、キーパッド１２６、ディスプレイ／タッチパッド１２８、固定メモリ１３０、取り外し可能メモリ１３２、電源１３４、ＧＰＳチップセット１３６および／または他の周辺機器１３８を含むことができる。ＷＴＲＵ１０２が、実施形態に一致したままでありながら、上記要素の任意の部分組合せを含み得ることを諒解されよう。
【００２０】
プロセッサ１１８は、汎用プロセッサ、専用プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと協働する１つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意の他のタイプの集積回路（ＩＣ）、状態機械などであることができる。プロセッサ１１８は、信号符号化、データ処理、電力制御、入力／出力処理、および／または、ＷＴＲＵ１０２が無線環境において動作することを可能にする任意の他の機能を実行することができる。プロセッサ１１８は、送受信機１２０に結合されることができ、この送受信機は、送受信要素１２２に結合されることができる。図１Ｂはプロセッサ１１８と送受信機１２０とを別個の構成要素として描いているが、プロセッサ１１８および送受信機１２０は電子パッケージまたはチップ内にともに統合されてもよいことが諒解されよう。
【００２１】
送受信要素１２２は、エアインターフェース１１６を介して基地局（例えば、基地局１１４ａ）へ信号を送信するか、または基地局から信号を受信するように構成され得る。例えば、１つの実施形態では、送受信要素１２２は、ＲＦ信号を送信および／または受信するように構成されるアンテナであってもよい。一実施形態では、送受信要素１２２は、例えば、ＩＲ信号、ＵＶ信号または可視光信号を送信および／または受信するように構成されるエミッタ／検出器であってもよい。さらに別の実施形態では、送受信要素１２２は、例えば、ＲＦ信号および光信号の両方を送信および／または受信するように構成されてもよい。送受信要素１２２は、無線信号の任意の組み合わせを送信および受信するように構成されてもよいことが諒解されよう。
【００２２】
送受信要素１２２は、図１Ｂにおいては単一の要素として描かれているが、ＷＴＲＵ１０２は任意の数の送受信要素１２２を含んでもよい。より具体的には、ＷＴＲＵ１０２はＭＩＭＯ技術を採用してもよい。従って、１つの実施形態では、ＷＴＲＵ１０２は、エアインターフェース１１６を介して無線信号を送信および受信するために、２つ以上の送受信要素１２２（例えば、複数のアンテナ）を含んでもよい。
【００２３】
送受信機１２０は、送受信要素１２２によって送信される信号を変調するとともに、送受信要素１２２によって受信される信号を復調するように構成されることができる。上記のように、ＷＴＲＵ１０２はマルチモード機能を有することができる。従って、送受信機１２０は、ＷＴＲＵ１０２が、例えば、ＮＲおよびＩＥＥＥ８０２．１１などの複数のＲＡＴを介して通信することを可能にするために、複数の送受信機を含むことができる。
【００２４】
ＷＴＲＵ１０２のプロセッサ１１８は、スピーカ／マイク１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８（例えば、液晶ディスプレイ（ＬＣＤ）表示ユニットまたは有機発光ダイオード（ＯＬＥＤ）表示ユニット）に結合されることができ、それらからユーザ入力データを受信することができる。プロセッサ１１８は、ユーザデータをスピーカ／マイク１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８に出力することもできる。加えて、プロセッサ１１８は、固定メモリ１３０および／または取り外し可能メモリ１３２などの任意のタイプの適切なメモリの情報にアクセスすることができ、その中にデータを記憶することができる。固定メモリ１３０は、ＲＡＭ、ＲＯＭ、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含んでもよい。取り外し可能メモリ１３２は、ＳＩＭカード、メモリスティック、ＳＤメモリカード、などを含むことができる。他の実施形態では、プロセッサ１１８は、サーバまたはホームコンピュータ（図示せず）などにある、物理的にＷＴＲＵ１０２上には位置していないメモリからの情報にアクセスすることができ、その中にデータを記憶することができる。
【００２５】
プロセッサ１１８は電源１３４から電力を受け取ることができ、電力を、ＷＴＲＵ１０２内の他の構成要素に分散させ、かつ／または制御することができる。電源１３４は、ＷＴＲＵ１０２に給電する任意の適切なデバイスであることができる。例えば、電源１３４は、１つまたは複数の乾電池（例えば、ニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉｏｎ）他）、太陽電池、燃料電池などを含むことができる。
【００２６】
プロセッサ１１８はＧＰＳチップセット１３６にも結合されることができ、これは、ＷＴＲＵ１０２の現在のロケーションに関連するロケーション情報（例えば、経度および緯度）を提供するように構成されることができる。ＧＰＳチップセット１３６からの情報に加えて、またはその代わりに、ＷＴＲＵ１０２は、基地局（例えば、基地局１１４ａ、１１４ｂ）からエアインターフェース１１６を介してロケーション情報を受信し、かつ／または２つ以上の近隣の基地局から受信されている信号のタイミングに基づいてそのロケーションを決定することができる。ＷＴＲＵ１０２は、実施形態との一貫したままで任意の適切な定位方法によってロケーション情報を獲得してもよいことが諒解されよう。
【００２７】
プロセッサ１１８は、他の周辺機器１３８にさらに結合されることができ、この周辺機器は、追加の特徴、機能および／または有線もしくは無線接続を提供する１つまたは複数のソフトウェアモジュールおよび／またはハードウェアモジュールを含むことができる。例えば、周辺機器１３８は、加速度計、電子コンパス、衛星送受信機、デジタルカメラ（写真および／またはビデオ用）、ＵＳＢポート、振動デバイス、テレビ送受信機、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）無線装置、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザ、仮想現実および／または拡張現実（ＶＲ／ＡＲ）デバイス、アクティビティトラッカなどを含むことができる。周辺機器１３８は、１つまたは複数のセンサを含むことができ、センサは、ジャイロスコープ、加速度計、ホール効果センサ、磁力計、向きセンサ、近接センサ、温度センサ、時間センサ、ジオロケーションセンサ、高度計、光センサ、タッチセンサ、磁力計、気圧計、ジェスチャセンサ、生体センサ、および／または湿度センサのうちの１つまたは複数であってもよい。
【００２８】
ＷＴＲＵ１０２は、（例えば、（例えば、送信のための）ＵＬと（例えば、受信のための）ＤＬとの両方のための特定のサブフレームに関連する）信号の一部または全部の送信および受信が並列および／または同時であり得る全二重無線を含むことができる。全二重無線は、ハードウェア（例えば、チョーク）またはプロセッサ（例えば、別個のプロセッサ（図示せず）またはプロセッサ１１８）を介した信号処理のいずれかを介して自己干渉を小さくするかおよび／または実質的になくすために干渉管理ユニット１３９を含むことができる。一実施形態では、ＷＴＲＵ１０２は、（例えば、（例えば、送信のための）ＵＬまたは（例えば、受信のための）ＤＬのいずれかのための特定のサブフレームに関連する）信号の一部または全部の送信および受信のための半二重無線を含んでもよい。
【００２９】
図１Ｃは、一実施形態による、ＲＡＮ１０４およびＣＮ１０６を示すシステム図である。上記のように、ＲＡＮ１０４は、エアインターフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するためにＥ−ＵＴＲＡ無線技術を採用することができる。ＲＡＮ１０４はまた、ＣＮ１０６と通信することもできる。
【００３０】
ＲＡＮ１０４は、ｅＮｏｄｅ−Ｂ１６０ａ、１６０ｂ、１６０ｃを含むことができるが、ＲＡＮ１０４は実施形態との一貫性を維持しながら、任意の数のｅＮｏｄｅ−Ｂを含んでもよいことが諒解されよう。ｅＮｏｄｅ−Ｂ１６０ａ、１６０ｂ、１６０ｃは各々、エアインターフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するために１つまたは複数の送受信機を含むことができる。１つの実施形態では、ｅＮｏｄｅ−Ｂ１６０ａ、１６０ｂ、１６０ｃはＭＩＭＯ技術を実施してもよい。従って、ｅＮｏｄｅ−Ｂ１６０ａは、例えば、無線信号をＷＴＲＵ１０２ａに送信し、および／または、無線信号をＷＴＲＵ１０２ａから受信するために、複数のアンテナを使用してもよい。
【００３１】
ｅＮｏｄｅ−Ｂ１６０ａ、１６０ｂ、１６０ｃの各々は、特定のセル（図示せず）に関連付けられることができ、無線リソース管理に関する決定、ハンドオーバに関する決定、ＵＬおよび／またはＤＬにおけるユーザのスケジューリングなどをハンドリングするように構成されることができる。図１Ｃに示されるように、ｅＮｏｄｅ−Ｂ１６０ａ、１６０ｂ、１６０ｃは、Ｘ２インターフェースを介して互いに通信することができる。
【００３２】
図１Ｃに示されるＣＮ１０６は、モビリティ管理エンティティ（ＭＭＥ）１６２、サービングゲートウェイ（ＳＧＷ）１６４、パケットデータネットワーク（ＰＤＮ）ゲートウェイ（またはＰＧＷ）１６６を含むことができる。上記の要素の各々はＣＮ１０６の一部として描かれているが、これらの要素のいずれかはＣＮのオペレータ以外のエンティティによって所有および／または操作されてもよいことが諒解されよう。
【００３３】
ＭＭＥ１６２は、Ｓ１インターフェースを介してＲＡＮ１０４中のｅＮｏｄｅ−Ｂ１６２ａ、１６２ｂ、１６２ｃの各々に接続され、制御ノードとしての役割を果たすことができる。例えば、ＭＭＥ１６２は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃの初期接続の間の、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのユーザの認証、ベアラの起動／停止、特定のサービングゲートウェイの選択などに関与することができる。ＭＭＥ１６２は、ＲＡＮ１０４と、ＧＳＭおよび／またはＷＣＤＭＡのような他の無線技術を採用する他のＲＡＮ（図示せず）との間で切り替えるための制御プレーン機能を提供することができる。
【００３４】
ＳＧＷ１６４は、Ｓ１インターフェースを介してＲＡＮ１０４中のｅＮｏｄｅ  Ｂ１６０ａ、１６０ｂ、１６０ｃの各々に接続され得る。ＳＧＷ１６４は一般的に、ユーザデータパケットをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃから／ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃにルーティングおよび転送することができる。ＳＧＷ１６４は、ｅＮｏｄｅ  Ｂ間のハンドオーバ中のユーザプレーンのアンカリング、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃにとってＤＬデータが利用可能であるときのページングのトリガ、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのコンテキストの管理および記憶などの、他の機能を実行することができる。
【００３５】
ＳＧＷ１６４はＰＧＷ１６６に接続されることができ、これは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃおよびＩＰ使用可能デバイスの間の通信を容易にするために、インターネット１１０などのパケット交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供することができる。
【００３６】
ＣＮ１０６は、他のネットワークとの通信を容易にすることができる。例えば、ＣＮ１０６は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと従来の固定通信デバイスとの間の通信を容易にするためにＰＳＴＮ１０８などの回線交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供することができる。例えば、ＣＮ１０６は、ＣＮ１０６とＰＳＴＮ１０８との間のインターフェースの役割を果たすＩＰゲートウェイ（例えば、ＩＰマルチメディアサブシステム（ＩＭＳ）サーバ）を含むことができるか、またはそれと通信することができる。加えて、ＣＮ１０６は、他のネットワーク１１２に対するアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供することができ、他のネットワーク１１２は、他のサービス提供者によって所有および／または運営される有線ネットワークおよび／または無線ネットワークを含むことができる。
【００３７】
図１Ａ〜図１ＤにおいてＷＴＲＵは無線端末として記載されているが、いくつかの代表的な実施形態では、そのような端末は（例えば、一時的にまたは永続的に）通信ネットワークとの有線通信インターフェースを使用し得ることが企図されている。
【００３８】
代表的な実施形態では、他のネットワーク１１２は、ＷＬＡＮであり得る。
【００３９】
インフラストラクチャ基本サービスセット（ＢＳＳ）モードのＷＬＡＮは、ＢＳＳのためのアクセスポイント（ＡＰ）と、ＡＰに関連する１つまたは複数の局（ＳＴＡ）とを有することができる。ＡＰは、ＢＳＳを出入りするトラフィックを搬送するディストリビューションシステム（ＤＳ）または別のタイプの有線／無線ネットワークへのアクセスまたはインターフェースを有することができる。ＢＳＳの外部から発信するＳＴＡへのトラフィックは、ＡＰを通して到着し得、ＳＴＡに送達され得る。ＳＴＡからＢＳＳ外の宛先に発信されるトラフィックは、それぞれの宛先に配信されるためにＡＰに送られ得る。ＢＳＳ内のＳＴＡ間のトラフィックは、ＡＰを通して送られ得、例えば、発信元ＳＴＡはＡＰにトラフィックを送り得、ＡＰは、宛先ＳＴＡにトラフィックを送達し得る。ＢＳＳ内のＳＴＡ間のトラフィックは、ピアツーピアトラフィックと考えられ、および／または参照される場合がある。ピアツーピアトラフィックは、直接リンクセットアップ（ＤＬＳ）を用いて発信元ＳＴＡと宛先ＳＴＡとの間で（例えば、それらの間で直接）送られ得る。いくつかの代表的な実施形態では、ＤＬＳは、８０２．１１ｅＤＬＳまたは８０２．１１ｚトンネリングされたＤＬＳ（ＴＤＬＳ：tunneled DLS）を使用し得る。独立ＢＳＳ（ＩＢＳＳ）モードを使用するＷＬＡＮはＡＰを有しないことがあり、ＩＢＳＳ内のまたはそれを使用するＳＴＡ（例えば、ＳＴＡの全て）は互いに直接的に通信し得る。ＩＢＳＳ通信モードは、本明細書では「アドホック」通信モードとして参照される場合がある。
【００４０】
８０２．１１ａｃインフラストラクチャ動作モードまたは同様の動作モードを使用するとき、ＡＰは、１次チャネルなどの固定チャネル上でビーコンを送信し得る。１次チャネルは、固定幅（例えば、２０ＭＨｚ幅の帯域幅）であるか、またはシグナリングを介して動的に設定された幅であり得る。１次チャネルは、ＢＳＳの動作チャネルであり得、ＡＰとの接続を確立するためにＳＴＡによって使用され得る。いくつかの代表的な実施形態では、キャリア検知多重アクセス／衝突回避（ＣＳＭＡ／ＣＡ）が、例えば、８０２．１１システムにおいて実施され得る。ＣＳＭＡ／ＣＡでは、ＡＰを含むＳＴＡ（例えば、あらゆるＳＴＡ）が１次チャネルを検知し得る。１次チャネルが特定のＳＴＡによって検知／検出されるおよび／またはビジーであると決定される場合、特定のＳＴＡはバックオフし得る。１つのＳＴＡ（例えば、ただ１つの局）が、所与のＢＳＳ中で任意の所与の時間に送信することができる。
【００４１】
高スループット（ＨＴ）のＳＴＡは、４０ＭＨｚ幅のチャネルを形成するために、例えば、隣接するまたは隣接していない２０ＭＨｚのチャネルとの１次の２０ＭＨｚのチャネルの組み合わせを介した通信のために４０ＭＨｚ幅のチャネルを使用することができる。
【００４２】
極高スループット（ＶＨＴ）のＳＴＡは、２０ＭＨｚ、４０ＭＨｚ、８０ＭＨｚおよび／または１６０ＭＨｚ幅のチャネルをサポートすることができる。４０ＭＨｚおよび／または８０ＭＨｚのチャネルは、連続する２０ＭＨｚのチャネルを組み合わせることによって形成され得る。１６０ＭＨｚのチャネルは、８つの連続する２０ＭＨｚのチャネルを組み合わせることによって、または８０＋８０構成と呼ばれることがある２つの不連続の８０ＭＨｚのチャネルを組み合わせることによって形成され得る。８０＋８０構成では、データは、チャネル符号化後に、２つのストリームにデータを分割し得るセグメントパーサを通して渡され得る。逆高速フーリエ変換（ＩＦＦＴ）処理と時間領域処理とが、各ストリームに対して別個に行われ得る。ストリームは、２つの８０ＭＨｚのチャネル上にマッピングされ得、データは、送信ＳＴＡによって送信され得る。受信ＳＴＡの受信機では、８０＋８０構成について上述された動作が逆行され得、組み合わされたデータが媒体アクセス制御（ＭＡＣ）に送られ得る。
【００４３】
８０２．１１ａｆおよび８０２．１１ａｈによってサブ１ＧＨｚ動作モードがサポートされる。チャネル動作帯域幅およびキャリアは、８０２．１１ｎおよび８０２．１１ａｃで使用されるものと比較して、８０２．１１ａｆおよび８０２．１１ａｈでは低減される。８０２．１１ａｆは、ＴＶホワイトスペース（ＴＶＷＳ）スペクトル中の５ＭＨｚ、１０ＭＨｚ、および２０ＭＨｚの帯域幅をサポートし、８０２．１１ａｈは、非ＴＶＷＳスペクトルを使用して１ＭＨｚ、２ＭＨｚ、４ＭＨｚ、８ＭＨｚ、および１６ＭＨｚの帯域幅をサポートする。代表的な実施形態によれば、８０２．１１ａｈは、マクロカバレッジエリア中のＭＴＣデバイスなどのメータ型制御／マシン型通信をサポートし得る。ＭＴＣデバイスは、特定の能力、例えば、いくつかのおよび／または限定された帯域幅のサポート（例えば、それだけのサポート）を含む限定された能力を有し得る。ＭＴＣデバイスは、（例えば、非常に長いバッテリ寿命を維持するために）閾値を上回るバッテリ寿命を有するバッテリを含むことができる。
【００４４】
８０２．１１ｎ、８０２．１１ａｃ、８０２．１１ａｆおよび８０２．１１ａｈなどの複数のチャネルおよびチャネル帯域幅をサポートすることができるＷＬＡＮシステムは、１次チャネルとして指定され得るチャネルを含む。１次チャネルは、ＢＳＳ中の全てのＳＴＡによってサポートされる最大の共通動作帯域幅に等しい帯域幅を有し得る。１次チャネルの帯域幅は、ＢＳＳ中で動作する全てのＳＴＡの中から、最小の帯域幅動作モードをサポートするＳＴＡによって設定および／または限定され得る。８０２．１１ａｈの例では、ＡＰおよびＢＳＳ中の他のＳＴＡが、２ＭＨｚ、４ＭＨｚ、８ＭＨｚ、１６ＭＨｚおよび／または他のチャネル帯域幅動作モードをサポートする場合でも、１次チャネルは、１ＭＨｚモードをサポートする（例えば、それだけをサポートする）ＳＴＡ（例えば、ＭＴＣタイプのデバイス）について１ＭＨｚ幅であり得る。キャリア検知および／またはネットワーク割り振りベクトル（ＮＡＶ）の設定は、１次チャネルのステータスに依存し得る。例えば（１ＭＨｚ動作モードのみをサポートする）ＳＴＡのために１次チャネルがビジーである場合、周波数帯域の大部分がアイドルのままであり、利用可能であり得る場合であっても、ＡＰに利用可能な周波数帯域全体を送信することが、ビジーであると考えられ得る。
【００４５】
米国では、８０２．１１ａｈによって使用され得る利用可能な周波数帯域は、９０２ＭＨｚから９２８ＭＨｚまでである。韓国では、利用可能な周波数帯域は、９１７．５ＭＨｚから９２３．５ＭＨｚまでである。日本では、利用可能な周波数帯域は、９１６．５ＭＨｚから９２７．５ＭＨｚまでである。８０２．１１ａｈのために利用可能な総帯域幅は、国コードに応じて６ＭＨｚから２６ＭＨｚである。
【００４６】
図１Ｄは、一実施形態による、ＲＡＮ１１３およびＣＮ１１５を示すシステム図である。上記のように、ＲＡＮ１１３は、エアインターフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するためにＮＲ無線技術を採用することができる。ＲＡＮ１１３はまた、ＣＮ１１５と通信することもできる。
【００４７】
ＲＡＮ１１３は、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃを含むことができるが、ＲＡＮ１１３は実施形態との一貫性を維持しながら、任意の数のｇＮＢを含んでもよいことが諒解されよう。ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは各々、エアインターフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するために１つまたは複数の送受信機を含むことができる。１つの実施形態では、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃはＭＩＭＯ技術を実施してもよい。例えば、ｇＮＢ１８０ａ、１８０ｂは、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃに信号を送信し、および／またはそれから信号を受信するためにビームフォーミングを利用し得る。従って、ｇＮＢ１８０ａは、例えば、無線信号をＷＴＲＵ１０２ａに送信し、および／または、無線信号をＷＴＲＵ１０２ａから受信するために、複数のアンテナを使用してもよい。一実施形態では、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃはキャリアアグリゲーション技術を実施してもよい。例えば、ｇＮＢ１８０ａは、ＷＴＲＵ１０２ａ（図示せず）に複数のコンポーネントキャリアを送信することができる。これらのコンポーネントキャリアのサブセットは、無認可スペクトル上にあり得、一方、残りのコンポーネントキャリアは、認可スペクトル上にあり得る。一実施形態では、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、協調マルチポイント（ＣｏＭＰ）技術を実施してもよい。例えば、ＷＴＲＵ１０２ａは、ｇＮＢ１８０ａおよびｇＮＢ１８０ｂ（および／またはｇＮＢ１８０ｃ）から協調送信を受信することができる。
【００４８】
ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、スケーラブルなヌメロロジに関連する送信を使用してｇＮＢ１８０ａ、１８０ｂ、１８０ｃと通信することができる。例えば、ＯＦＤＭシンボル間隔および／またはＯＦＤＭサブキャリア間隔は、異なる送信、異なるセル、および／または無線送信スペクトルの異なる部分ごとに変動し得る。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、（例えば、様々な数のＯＦＤＭシンボルを含んでいるおよび／または変動する長さの絶対時間の間続く）様々なまたはスケーラブルな長さのサブフレームまたは送信時間間隔（ＴＴＩ）を使用してｇＮＢ１８０ａ、１８０ｂ、１８０ｃと通信することができる。
【００４９】
ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、スタンドアロン構成および／または非スタンドアロン構成においてＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するように構成され得る。スタンドアロン構成では、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、他のＲＡＮ（例えば、ｅＮｏｄｅ−Ｂ１６０ａ、１６０ｂ、１６０ｃなど）にアクセスすることもなしにｇＮＢ１８０ａ、１８０ｂ、１８０ｃと通信し得る。スタンドアロン構成では、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃのうちの１つまたは複数をモビリティアンカーポイントとして利用し得る。スタンドアロン構成では、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、無認可帯域中の信号を使用してｇＮＢ１８０ａ、１８０ｂ、１８０ｃと通信し得る。非スタンドアロン構成では、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ｅＮｏｄｅ−Ｂ１６０ａ、１６０ｂ、１６０ｃなどの別のＲＡＮとも通信しながら／それにも接続しながらｇＮＢ１８０ａ、１８０ｂ、１８０ｃと通信し得る／それに接続し得る。例えば、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、１つまたは複数のｇＮＢ１８０ａ、１８０ｂ、１８０ｃおよび１つまたは複数のｅＮｏｄｅ−Ｂ１６０ａ、１６０ｂ、１６０ｃと実質的に同時に通信するためにＤＣ原理を実施し得る。非スタンドアロン構成では、ｅノードＢ１６０ａ、１６０ｂ、１６０ｃは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのモビリティアンカーとしての役割を果たし得、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃにサービスするための追加のカバレッジおよび／またはスループットを与え得る。
【００５０】
ｇＮＢ１８０ａ、１８０ｂ、１８０ｃの各々は、特定のセル（図示せず）に関連付けられ得、無線リソース管理の決定、ハンドオーバの決定、ＵＬおよび／またはＤＬにおけるユーザのスケジューリング、ネットワークスライシングのサポート、デュアル接続性、ＮＲとＥ−ＵＴＲＡとの間の相互接続、ユーザプレーン機能（ＵＰＦ）１８４ａ、１８４ｂに向けたユーザプレーンデータのルーティング、アクセスおよびモビリティ管理機能（ＡＭＦ）１８２ａ、１８２ｂに向けた制御プレーン情報のルーティングなどをハンドリングするように構成され得る。図１Ｄに示すように、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、Ｘｎインターフェースを介して互いと通信することができる。
【００５１】
図１Ｄに示すＣＮ１１５は、少なくとも１つのＡＭＦ１８２ａ、１８２ｂと、少なくとも１つのＵＰＦ１８４ａ、１８４ｂと、少なくとも１つのセッション管理機能（ＳＭＦ）１８３ａ、１８３ｂと、場合によっては、データネットワーク（ＤＮ）１８５ａ、１８５ｂとを含むことができる。上記の要素の各々はＣＮ１１５の一部として描かれているが、これらの要素のいずれかはＣＮのオペレータ以外のエンティティによって所有および／または操作されてもよいことが諒解されよう。
【００５２】
ＡＭＦ１８２ａ、１８２ｂは、Ｎ２インターフェースを介してＲＡＮ１１３中のｇＮＢ１８０ａ、１８０ｂ、１８０ｃのうちの１つまたは複数に接続され得、制御ノードとしての役割を果たすことができる。例えば、ＡＭＦ１８２ａ、１８２ｂは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのユーザを認証すること、ネットワークスライシング（例えば、異なる要件を有する異なるＰＤＵセッションのハンドリング）のサポート、特定のＳＭＦ１８３ａ、１８３ｂを選択すること、登録エリアの管理、ＮＡＳシグナリングの終了、モビリティ管理などを担当し得る。ネットワークスライシングは、利用されているＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃであるサービスのタイプに基づいてＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのＣＮサポートをカスタマイズするために、ＡＭＦ１８２ａ、１８２ｂによって使用され得る。例えば、異なるネットワークスライスは、超高信頼低遅延（ＵＲＬＬＣ）アクセスに依拠するサービス、高速大容量モバイルブロードバンド（ｅＭＢＢ）アクセスに依拠するサービス、マシン型通信（ＭＴＣ）アクセスのサービスなどの異なる使用事例のために確立され得る。ＡＭＦ１６２は、ＲＡＮ１１３と、ＬＴＥ、ＬＴＥ−Ａ、ＬＴＥ−Ａ  Ｐｒｏ、および／またはＷｉＦｉなどの非３ＧＰＰアクセス技術などの他の無線技術を採用する他のＲＡＮ（図示せず）との間で切り替えるための制御プレーン機能を提供することができる。
【００５３】
ＳＭＦ１８３ａ、１８３ｂは、Ｎ１１インターフェースを介してＣＮ１１５中のＡＭＦ１８２ａ、１８２ｂに接続され得る。ＳＭＦ１８３ａ、１８３ｂはまた、Ｎ４インターフェースを介してＣＮ１１５中のＵＰＦ１８４ａ、１８４ｂにも接続され得る。ＳＭＦ１８３ａ、１８３ｂは、ＵＰＦ１８４ａ、１８４ｂを選択および制御し、ＵＰＦ１８４ａ、１８４ｂを通してトラフィックのルーティングを構成し得る。ＳＭＦ１８３ａ、１８３ｂは、ＵＥのＩＰアドレスを管理し、割り振ること、ＰＤＵセッションを管理すること、ポリシの執行およびＱｏＳを制御すること、ダウンリンクデータの通知を提供することなどの他の機能を実行することができる。ＰＤＵセッションのタイプは、ＩＰに基づくもの、ＩＰに基づかないもの、イーサネットに基づくものなどであり得る。
【００５４】
ＵＰＦ１８４ａ、１８４ｂは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスとの間の通信を容易にするためにインターネット１１０などのパケット交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供することができる、Ｎ３インターフェースを介してＲＡＮ１１３中のｇＮＢ１８０ａ、１８０ｂ、１８０ｃのうちの１つまたは複数に接続され得る。ＵＰＦ１８４、１８４ｂは、パケットをルーティングおよび転送すること、ユーザプレーンのポリシを執行すること、マルチホームＰＤＵセッションをサポートすること、ユーザプレーンＱｏＳをハンドリングすること、ダウンリンクパケットをバッファリングすること、モビリティアンカリングを提供することなどの他の機能を実行することができる。
【００５５】
ＣＮ１１５は、他のネットワークとの通信を容易にすることができる。例えば、ＣＮ１１５は、ＣＮ１１５とＰＳＴＮ１０８との間のインターフェースの役割を果たすＩＰゲートウェイ（例えば、ＩＰマルチメディアサブシステム（ＩＭＳ）サーバ）を含むことができるか、またはそれと通信することができる。また、ＣＮ１１５は、他のネットワーク１１２に対するアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供することができ、他のネットワーク１１２は、他のサービス提供者によって所有および／または運営される有線ネットワークおよび／または無線ネットワークを含むことができる。１つの実施形態では、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＵＰＦ１８４ａ、１８４ｂへのＮ３インターフェース、および、ＵＰＦ１８４ａ、１８４ｂとＤＮ１８５ａ、１８５ｂとの間のＮ６インターフェースとを介して、ＵＰＦ１８４ａ、１８４ｂを通してローカルデータネットワーク（ＤＮ）１８５ａ、１８５ｂに接続され得る。
【００５６】
図１Ａ〜図１Ｄおよび図１Ａ〜図１Ｄの対応する説明に鑑みて、ＷＴＲＵ１０２ａ〜ｄ、基地局１１４ａ〜ｂ、ｅＮｏｄｅ−Ｂ１６０ａ〜ｃ、ＭＭＥ１６２、ＳＧＷ１６４、ＰＧＷ１６６、ｇＮＢ１８０ａ〜ｃ、ＡＭＦ１８２ａ〜ｂ、ＵＰＦ１８４ａ〜ｂ、ＳＭＦ１８３ａ〜ｂ、ＤＮ１８５ａ〜ｂ、および／または本明細書で説明されている任意の他のデバイスのうちの１つまたは複数に関して本明細書で説明されている機能のうちの１つもしくは複数または全ては、１つまたは複数のエミュレーションデバイス（図示せず）によって実行されてもよい。エミュレーションデバイスは、本明細書で説明されている機能のうちの１つもしくは複数または全てをエミュレートするように構成された１つまたは複数のデバイスであり得る。例えば、エミュレーションデバイスは、他のデバイスをテストする、並びに／またはネットワークおよび／もしくはＷＴＲＵ機能をシミュレートするために使用され得る。
【００５７】
エミュレーションデバイスは、ラボ環境においておよび／またはオペレータネットワーク環境において他のデバイスの１つまたは複数のテストを実施するように設計され得る。例えば、１つまたは複数のエミュレーションデバイスは、通信ネットワーク内の他のデバイスをテストするために有線および／または無線通信ネットワークの一部として完全にまたは部分的に実施および／または展開されながら、１つもしくは複数または全ての機能を実行することができる。１つまたは複数のエミュレーションデバイスは、有線および／または無線通信ネットワークの一部として一時的に実施／展開されながら、１つもしくは複数または全ての機能を実行することができる。エミュレーションデバイスは、テストする目的で別のデバイスに直接的に結合され得、および／または、無線ワイヤレス通信を使用してテストを実行することができる。
【００５８】
１つまたは複数のエミュレーションデバイスは、有線および／または無線通信ネットワークの一部として実施／展開されることなく、全てを含む１つまたは複数の機能を実行することができる。例えば、エミュレーションデバイスは、１つまたは複数の構成要素のテストを実施するために試験所並びに／または展開されていない（例えば、テスト用の）有線および／もしくは無線通信ネットワーク中のテストシナリオで利用され得る。１つまたは複数のエミュレーションデバイスは、テスト機器であり得る。データを送信および／または受信するためにエミュレーションデバイスによって、直接ＲＦ結合および／または（例えば、１つまたは複数のアンテナを含み得る）ＲＦ回路を介した無線通信が使用され得る。
【００５９】
ＬＴＥにおいて、ターボコーダインターリーバは、制限された数のコードブロック（ＣＢ）サイズに対してのみ定義され、最大ブロックサイズは６１４４ビットである。結果として、２４ビットのＴＢ巡回冗長検査（ＣＲＣ）を含むトランスポートブロック（ＴＢ）が、この６１４４ビットの制限を超える場合、各ＴＢは、ターボコーディングの前に、より小さいＣＢへとセグメント化される。
【００６０】
図２は、本明細書において説明されている他の実施形態の任意の組み合わせにおいて使用されてもよい、コードブロック（ＣＢ）セグメント化２５０およびＣＢごとの巡回冗長検査（ＣＲＣ）の挿入２７０の一例２００を示す。図２に示されるように、ＴＢ２０５におけるＣＢセグメント化２５０は、ＣＢ＃１  ２１５にフィラービット２６０（すなわち、ターボコーダによってサポートされるサイズに第１のＣＢを合わせるためのフィラー）を挿入するターボコーディングプロセスに先行し得る。ＣＢセグメント化２５０の間、各ＣＢ（すなわち、ＣＢ＃１  ２１５、ＣＢ＃２  ２１７、ＣＢ＃Ｍ  ２１８）は、それに付加されているＣＲＣ２３０、２３２、２３４を有することができる。このＣＲＣ２３０、２３２、２３４はまた、２４ビットの長さをも含み得るが、これはＴＢ  ＣＲＣ２１０とは異なる。ＣＢ２１５、２１７、２１８ごとにＣＲＣ２３０、２３２、２３４を有することによって、チャネルコード化２８０のために正確に復号されたＣＢを早期に検出することを可能にすることができ、これによって、そのＣＢ２１５、２１７、２１８の反復復号プロセスを早期に終了することが可能である。これは、ＷＴＲＵ処理の複雑度およびエネルギー消費を低減するために使用され得る。ＴＢ  ＣＲＣ２１０とＣＢ  ＣＲＣ２３０、２３２、２３４とを組み合わせることによって、復号されたＴＢの誤りが検出されない危険性を最小限に抑えることができる。
【００６１】
ＬＴＥにおいて、ＴＢのサイズ、すなわちトランスポートブロックサイズ（ＴＢＳ）は、２０ＭＨｚのシステム帯域幅に基づいて、９７，８９６ビット程度の大きさであり得る。この結果、ＴＢあたりＣＢはおよそ１６個になり得る。ＬＴＥにおいては、たとえ復号に失敗したＣＢが単一であっても、ＴＢ全体が再送信される。６ＧＨｚ未満に対するシステム帯域幅が１００ＭＨｚであり、可能性としてｍｍＷ帯域についてＧＨｚ単位までになる新無線（ＮＲ）において、ＴＢＳは、ＬＴＥの２０ＭＨｚ帯域幅のスケーリングに基づいて、例えば、１００ＭＨｚに対して８０個のＣＢなど、はるかにより大きくなり得る。
【００６２】
高速大容量モバイルブロードバンド（ｅＭＢＢ）、超高信頼低遅延通信（ＵＲＬＬＣ）、および大規模マシンタイプ通信（ｍＭＴＣ）などの複数の使用事例が提供されるＮＲにおいては、無線リソースを利用する効率的な方法が必要とされ得る。例えば、ＵＲＬＬＣ  ＷＴＲＵは、それらの厳密な遅延要件を満たすために、直ちにサービスされる必要があり得る。この結果、ｅＭＢＢトラフィックをプリエンプトすることが必要になり得、ｅＭＢＢトラフィックのためにスケジューリングされているリソースが、ＵＲＬＬＣトラフィックにサービスするためにプリエンプトされ得る。リソースのこのプリエンプションは、ミニスロット（すなわち、シンボルの単位）レベルであり得、少数のＣＢにしか影響を与えない。従って、ＬＴＥの場合のようにＴＢ全体を再送信することは、リソースに関して非効率であり、無駄が多い。結果として、ＣＢ、ＣＢのグループ（ＣＢＧ）、ＴＢ、またはそれらの任意の組み合わせに基づいて動作することができるより柔軟な再送信方式が必要であり得る。
【００６３】
図３は、超高信頼低遅延（ＵＲＬＬＣ）トラフィックによる高速大容量モバイルブロードバンド（ｅＭＢＢ）トラフィックの例示的なプリエンプションを示す。例えば、ＣＢ１から２８は元々、ｅＭＢＢトラフィックのためにスケジューリングされている。しかしながら、ＵＲＬＬＣトラフィックがサービスされる必要があるとき、ｅＭＢＢトラフィックのためにスケジューリングされているＣＢは、領域３０５および３１５に示されているように、ＵＲＬＬＣトラフィックにサービスするためにプリエンプトされ得る。ＬＴＥにおいては、プリエンプトされる領域３０５、３１５内のＣＢ（またはｅＭＢＢトラフィックのための領域内の任意のＣＢ）が適切に復号されない場合、ＴＢ全体が再送信される必要がある。上述したように、この結果として、無線リソースの使用が非常に非効率になる。
【００６４】
ＣＢＧに基づく再送信をサポートするために、マルチビットＨＡＲＱフィードバックが必要とされ得る。マルチビットフィードバックは、ＷＴＲＵが、基地局（例えば、次世代ノードＢ（ｇＮＢ））からいずれのＣＢ／ＣＢＧまたは他のリソース（例えば、ＰＲＢまたはＰＲＢのグループ）の再送信を要求しているかを示すために使用され得る。
【００６５】
ＷＴＲＵまたはＷＴＲＵのセット／グループは、ＨＡＲＱフィードバック、単一ビットＨＡＲＱフィードバック、またはマルチビットＨＡＲＱを利用しないように半静的にまたは動的に構成され得る。これは、サービスされているｅＭＢＢトラフィックのタイプ／クラス（例えば、ライブストリーミングビデオ対非ライブビデオコンテンツ）と、ｅＭＢＢトラフィックをプリエンプトしているＵＲＬＬＣトラフィックの周波数の両方に応じ得る。ＷＴＲＵに対するフィードバックフォーマットの構成（または再構成）は、ＢＳ（例えば、ｇＮＢ）によって、シグナリングメッセージを介して決定され得る。例えば、半静的構成は、ＲＲＣシグナリングを介して決定され得、ＷＴＲＵまたはＷＴＲＵのセット／グループが提供するＨＡＲＱフィードバックのタイプが長い時間期間にわたって変化し得ないことを示すことができる。例えば、ＷＴＲＵがセル内でマルチビットＨＡＲＱフィードバックを提供するように半静的に構成されるとき、ＷＴＲＵは、単一ビットＨＡＲＱフィードバックのみを許容することができる異なるセルに移動するまで、そのＨＡＲＱフィードバック構成を変化させない。対照的に、動的構成は、ＤＣＩを介して決定され得、ＷＴＲＵまたはＷＴＲＵのセット／グループが提供するＨＡＲＱフィードバックのタイプが、必要とされるときに短い時間期間内で変化し得ることを示すことができる。例えば、ＤＣＩは、ＷＴＲＵが提供しているＨＡＲＱフィードバックのタイプを変更するためのパラメータを含むことができる。
【００６６】
一実施形態において、ｅＭＢＢトラフィックが、ライブストリーミングビデオなどの、主に時間に敏感なトラフィックから構成され、ＵＲＬＬＣトラフィック負荷が低く、それによって、ｅＭＢＢリソースのプリエンプションが相対的に低頻度になる場合、ＢＳ（例えば、ｇＮＢ）は、ＨＡＲＱフィードバックを利用しないように、ＷＴＲＵまたはＷＴＲＵのグループを半静的または動的に（再）構成することができる。ＷＴＲＵはこのとき、このタイプのサービスについてのＨＡＲＱに基づく再送信と関連付けられる遅延にとって、いくつかのパケットの損失が好ましいため、順方向誤り訂正（ＦＥＣ）に依拠し得る。
【００６７】
代替的にまたは付加的に、ＵＲＬＬＣトラフィックの頻度が高く、結果、ｅＭＢＢリソースのプリエンプションの度合いが高くなる場合、ＢＳ（例えば、ｇＮＢ）は、マルチビットＨＡＲＱフィードバックを利用するように、影響されるＷＴＲＵまたはＷＴＲＵのグループを半静的または動的に（再）構成することができる。マルチビットＨＡＲＱフィードバックが受信されると、ＢＳは、データの影響を受ける部分を再送信することができ、結果、ＷＴＲＵまたはＷＴＲＵのグループは、影響を受けるＴＢを効率的に復号することができる。これらの再送信は、ＣＢ／ＣＢＧ、ミニスロットレベルの再送信であり得、遅延に関して視る者の体験に劇的に影響しないようにしながら、ＷＴＲＵまたはＷＴＲＵのグループが追加のデータ送信から受益することを可能にする。
【００６８】
別の実施形態において、ＢＳ（例えば、ｇＮＢ）は、マルチビットＨＡＲＱフィードバックの特定の予め定められたマッピングを使用するように、ＷＴＲＵまたはＷＴＲＵのグループを半静的に構成することができる。これらのマッピングは、マルチビットＨＡＲＱフィードバックが、ＣＢレベルの粒度、ＣＢＧレベルの粒度、またはさらには時間−周波数リソースを可能にするか否かを示すことができる。そのようなマッピングの例が、図４Ａ〜図４Ｃに示されている。
【００６９】
図４Ａは、本明細書において説明されている他の実施形態のいずれかと組み合わせて使用され得る、例示的なマルチビットＨＡＲＱフィードバック４０５を示す。図４Ａに示されているように、マルチビットＨＡＲＱフィードバック４０５は、ＣＢレベルの粒度の再送信を可能にすることができる。ここで、粒度は、マルチビットＨＡＲＱフィードバックの各ビット（すなわち、各ＨＡＲＱ情報ビット）内に含まれるＣＢ／ＣＢＧの数を意味する。具体的には、ＣＢレベルの粒度は、マルチビットＨＡＲＱフィードバック４０５内の各ビットが、個々のＣＢを表すことができることを意味する。この例において、マルチビットＨＡＲＱフィードバック４０５は、各ＣＢ（すなわち、ＣＢ１〜ＣＢ１２）を表す１２個のＨＡＲＱ情報ビットを含む。１２個のＨＡＲＱ情報ビットは、ＷＴＲＵが再送信を要求しているそれぞれのＣＢを示すことができる。例えば、ＣＢ１が、正確に復号されない（すなわち、破損されている）場合、ＷＴＲＵは、ＣＢ１を表す第１のＨＡＲＱ情報ビットを、ＮＡＣＫとして決定することができる。ＣＢ１が首尾よく復号される場合、ＷＴＲＵは、第１のＨＡＲＱ情報ビットを、ＡＣＫとして決定することができる。０のＨＡＲＱ情報ビット値がＮＡＣＫを表すことができ、一方、１のＨＡＲＱ情報ビット値がＡＣＫを表すことができ、またはその逆であってもよい。これは、ＷＴＲＵが、首尾よく復号するのに失敗したＣＢを正確に指定することができるという点で、最大の柔軟性を提供する。従って、ＢＳは、再送信リソースの使用を最小限に抑えることができる。これは、ＴＢサイズが小さい場合に特に魅力的であり得る。しかしながら、ＴＢサイズがさらに適度に大きい場合、この手法は、多数のＨＡＲＱフィードバックビットを必要とし得、シグナリングオーバーヘッドが大きく増大する。
【００７０】
図４Ｂは、本明細書において説明されている他の実施形態のいずれかと組み合わせて使用され得る、ＨＡＲＱフィードバック４１０がコードブロックグループ（ＣＢＧ）レベルの粒度の再送信を可能にする、例示的なマルチビットＨＡＲＱフィードバック４１０を示す。ＣＢＧレベルの粒度は、マルチビットＨＡＲＱフィードバック４１０内の各ビットが、ＣＢのグループ（すなわち、ＣＢＧ）４１５、４２０、４２５、４３０を表すことができることを意味する。この例において、マルチビットＨＡＲＱフィードバック４１０は、ＣＢＧ４１５、４２０、４２５、４３０の各々を表す４個のＨＡＲＱ情報ビットを含む。４個のＨＡＲＱ情報ビットの各々は、ＷＴＲＵが再送信を要求しているそれぞれのＣＢＧ４１５、４２０、４２５、４３０を示すことができる。例えば、マルチビットＨＡＲＱフィードバック４１０の第１のビットは、第１のＣＢＧ４１５（すなわち、ＣＢ１、ＣＢ２、ＣＢ３から成るグループ）を表し、第１のＣＢＧが再送信を要求されているか否かを示す。例えば、第１のＣＢＧ４１５内のＣＢのいずれかが正確に復号されない（すなわち、破損されている）場合、ＷＴＲＵは、第１のＣＢＧ４１５を表す第１のＨＡＲＱ情報ビットを、ＮＡＣＫとして決定することができる。第１のＣＢＧ４１５内のＣＢの全てが首尾よく復号される場合、ＷＴＲＵは、第１のＣＢＧ４１５を表す第１のビットを、ＡＣＫとして決定することができる。上記で説明されているように、０のＨＡＲＱ情報ビット値がＮＡＣＫを表すことができ、一方、１のＨＡＲＱ情報ビット値がＡＣＫを表すことができ、またはその逆であってもよい。
【００７１】
図４Ｃは、本明細書において説明されている他の実施形態のいずれかと組み合わせて使用され得る、ＨＡＲＱフィードバック４３５がＣＢＧレベルの粒度の再送信を可能にする、別の例示的なマルチビットＨＡＲＱフィードバック４３５を示す。ＣＢＧレベルの粒度は、マルチビットＨＡＲＱフィードバック４１０内のビットが、ＣＢのグループ（すなわち、ＣＢＧ）４４０、４４５を表すことができることを意味する。図４Ｃに示されているように、各ＨＡＲＱ情報ビットは、この場合は各々が６個のＣＢから成る２つのＣＢＧグループである、ＣＢＧ４４０、４４５にマッピングする。例えば、マルチビットＨＡＲＱフィードバック４３５の第１のビットは、第１のＣＢＧ４４０（すなわち、ＣＢ１、ＣＢ２、ＣＢ３、ＣＢ４、ＣＢ５、ＣＢ６から成るグループ）を表し、第１のＣＢＧが再送信を要求されているか否かを示す。第１のＣＢＧ４１５内のＣＢの全てが首尾よく復号される場合、ＷＴＲＵは、第１のＣＢＧ４４０を表す第１のビットを、ＡＣＫとして決定することができる。第１のＣＢＧ４４０内のＣＢのいずれかが正確に復号されない（例えば、破損されている）場合、ＷＴＲＵは、第１のＣＢＧ４４０を表す第１のＨＡＲＱ情報ビットを、ＮＡＣＫとして決定することができる。言い換えれば、関連するＣＢＧグループ内のいずれかのＣＢが誤っている場合、この結果として、ＮＡＣＫフィードバックが生じ得、その結果、そのＣＢＧ内の全てのＣＢが再送信されることになる。ＷＴＲＵが、ＣＢＧの全てのコードブロックを正確に受信した場合、ＷＴＲＵは、ＣＢＧのＨＡＲＱ−ＡＣＫ情報ビットのＡＣＫを生成することができる。ＷＴＲＵが、ＣＢＧの少なくとも１つのコードブロックを正確に受信しなかった場合、ＷＴＲＵは、ＣＢＧのＨＡＲＱ−ＡＣＫ情報ビットのＮＡＣＫを生成することができる。上述されているように、０のＨＡＲＱ情報ビット値がＮＡＣＫを表すことができ、一方、１のＨＡＲＱ情報ビット値がＡＣＫを表すことができ、またはその逆であってもよい。
【００７２】
一実施形態において、ＷＴＲＵは、複数のＨＡＲＱフィードバックのオプションを利用するように構成され得る。例えば、ＷＴＲＵは、マルチビットＨＡＲＱフィードバックと単一ビットＨＡＲＱフィードバックの両方を提供するように構成され得る。ＷＴＲＵは、２つのうちのいずれの１つを利用すべきかを判断し、必要とされる場合に２つの間で切り替える柔軟性を有することができる。例えば、ＷＴＲＵが、特定のＴＢについて少数のＣＢを首尾よく復号することができない場合、それは、基地局（例えば、ｇＮＢ）がいずれのＣＢを再送信すべきかをシグナリングするために、マルチビットＨＡＲＱフィードバックを利用することを選択する（またはそうするように切り替える）ことができる。
【００７３】
代替的にまたは付加的に、ＷＴＲＵが、相当数のＣＢ（例えばＴＢ全体のうちの大きい割合）を復号することができない場合、それは、プリエンプションが複数のＣＢ／ＣＢＧに影響を与えており、ＢＳ（例えば、ｇＮＢ）がＴＢ全体を再送信することがより良好であり得ることを知らせることができる。そのような事例において、ＷＴＲＵは、単一ビットＨＡＲＱフィードバックを利用することを選択する（または、そのように切り替える）ことができ、これは、シグナリングオーバーヘッドも同時に低減しながら、ＴＢ全体を再送信するようにＢＳ（例えば、ｇＮＢ）に通知する。ＢＳ（例えば、ｇＮＢ）は、単一ビットＨＡＲＱフィードバックとマルチビットＨＡＲＱフィードバックとの間の切り替えを容易にするために、閾値パラメータ「δ」を用いてＷＴＲＵを構成することができる。
【００７４】
ＴＢに基づく再送信を要求している単一ビットＨＡＲＱフィードバックと、ＣＢＧに基づく再送信を要求しているマルチビットＨＡＲＱフィードバックとの間の切り替えを容易にするために、ＷＴＲＵは、ＢＳ（例えば、ｇＮＢ）によって、各々が異なるペイロード（例えば、アップリンク制御情報（ＵＣＩ））サイズを有する、複数のＰＵＣＣＨフォーマットを利用するように構成され得る。ＷＴＲＵは、このとき、ＨＡＲＱフィードバック要件に基づいて適切なＰＵＣＣＨフォーマットを選択することができる。このシナリオの下では、ＢＳ（例えば、ｇＮＢ）は、いずれのフォーマットが、および、いずれのフィードバックオプションがＷＴＲＵによって利用されているかを確認するために、ＰＵＣＣＨをブラインド復号する必要があり得る。
【００７５】
ＷＴＲＵは、無線リソース制御（ＲＲＣ）シグナリングを介して複数のＰＵＣＣＨリソースセットを用いて構成され得、ここで、リソースセットは、ＵＣＩペイロード容量に基づいて分割される。例えば、単純なシナリオにおいて、「Ｋ＝２」個の構成済みリソースセットがあり得る。第１のリソースセットは、ＨＡＲＱ−ＡＣＫフィードバック、従って、最大２ビットのＵＣＩペイロードサイズを有するＰＵＣＣＨフォーマットに対して定義され得る。一方、第２のリソースセットは、ＨＡＲＱ−ＡＣＫフィードバック、従って、２ビットよりも大きいＵＣＩペイロードサイズを有するＰＵＣＣＨフォーマットに対して定義され得る。別の例において、ＷＴＲＵは、粒度が追加された、「Ｋ＝３」個のリソースセットを用いて構成され得る。例えば、第１のリソースセットは、最大２ビットのＵＣＩペイロードサイズに対して定義され得る。第２のリソースセットは、２ビットよりも大きく１９ビット未満のＵＣＩペイロードサイズを利用するＰＵＣＣＨフォーマットに対して定義され得る。第３のリソースセットは、２０ビット以上のＵＣＩペイロードサイズに対して定義され得る。また別の例において、「Ｋ＝４」個のＰＵＣＣＨリソースセットがあり得、（「Ｋ＝３」の場合のように）第１のリソースセットは最大２ビットのＵＣＩペイロードサイズに対して定義され、第２のリソースセットは２ビットよりも大きく１９ビット未満のＵＣＩペイロードサイズを利用するＰＵＣＣＨフォーマットに対して定義される。しかしながら、第３のリソースセットおよび第４のリソースセットは、第３のリソースセットが、２０よりも大きく、何らかの値「Ｌ」（一例としてＬ＝８０）未満であるＵＣＩペイロードサイズから定義され、第４のリソースセットが、Ｌよりも大きいＵＣＩペイロードサイズに対して定義されることによって、増大された粒度を提供することができる。
【００７６】
リソースセットの数と、リソースセットあたりの利用可能なＰＵＣＣＨリソース（リソースブロック）の数との間にはトレードオフがあり得る。ここで、ＰＵＣＣＨリソースの総数はより多数のリソースセットの間で分割される必要があるため、より多数のＰＵＣＣＨリソースセットを有する結果として、セットあたりのＰＵＣＣＨリソースは少なくなり得る。より多数のリソースセットを有することは、相当数のＷＴＲＵがより高いＵＣＩペイロードを有し得ると一般的に予測される場合に、有益であり得る。この事例において、これらのペイロードの分布は多様であり、ＰＵＣＣＨリソースセットは、ＵＣＩペイロードの分布に対して微調整され得、それによって、これらのリソースの最適な使用が可能になる。より多数のリソースセットを有することが有益であり得る例示的なソリューションは、ＵＣＩペイロードの大きな変動が可能である場合であり得る。ＣＢＧに基づく（再）送信の事例において、これは、単一のＨＡＲＱフィードバックの応答が、複数のスロット／ＣＣなどにわたる複数のＰＤＳＣＨ送信に提供される必要があり得る、フィードバックのＨＡＲＱ多重化があるときに発生し得る。そのような状況において、かつ、特にＣＢＧに基づく（再）送信について、ＨＡＲＱビットの数は相当になり得、例えば、ＴＢあたり８個のＣＢＧによって構成されるＷＴＲＵについて、５個のＣＣで、ＨＡＲＱフィードバックについて４０ビットのＵＣＩペイロードが予測され得、一方、２個のＣＣについて、１６ビットのＵＣＩペイロードが予測され得る。そのようなシナリオでは、より多数のＰＵＣＣＨリソースセット（例えば、「Ｋ＝３」とは対照的に「Ｋ＝４」）を有することがより良好であり得、セットの間のＰＵＣＣＨリソースの分布は、より多数のリソースがＫ＝３の場合について供給されるようなものであり得る。これは、４０ビットのＨＡＲＱフィードバックが提供される確率が、３と何らかの中間の数（例えば、「Ｋ＝４」の場合の第３のセットについての上記における１９ビット）との間のＨＡＲＱ、および、従って、ＵＣＩペイロードが提供される確率よりもはるかに低いと予期され得るためである。
【００７７】
ＷＴＲＵは、このとき、ＨＡＲＱペイロード（ＵＣＩ）サイズに基づいて適切なリソースセットを選択することができる。例えば、ＷＴＲＵがＴＢあたり２個のＣＢＧおよび単一のみのコードワード（ＣＷ）によって構成される上記のシナリオにおいて、ＷＴＲＵは、２ビットのマルチビットフィードバックを報告する必要があり得る。そのような事例のシナリオにおいて、ＷＴＲＵは、最大２ビットのＵＣＩのＰＵＣＣＨフォーマットに対して定義されるＰＵＣＣＨリソースセット（すなわち、上記の例の各々における第１のセット）を選択することができる。
【００７８】
別の実施形態において、単一のＣＷ構成についてＴＢあたり８個のＣＢＧによって構成されるＷＴＲＵは、８ビットのサイズのマルチビットフィードバックを報告する必要があり得る。ＷＴＲＵは、上記の例の第２のセットにおいて示されている２ビットよりも大きいＵＣＩをサポートすることが可能であるＰＵＣＣＨフォーマットに対して定義されるＰＵＣＣＨリソースセットを選択することができる。
【００７９】
また別の例において、ＷＴＲＵが複数のＰＵＣＣＨリソースセットによって構成され得ることが可能であり、ここで、２つ以上のリソースセットが、ＨＡＲＱペイロードサイズ（またはより一般的には、特定のサイズのＵＣＩペイロード）をサポートすることが可能であるＰＵＣＣＨフォーマットに対して定義される。例えば、ＷＴＲＵは、Ｋ＝４個のセットを用いて構成され得、ここで、２つのセットが最大２ビットのＵＣＩペイロードのＰＵＣＣＨフォーマットに対して定義され、一方で、残りの２つのリソースセットは、２ビットよりも大きいＵＣＩペイロードのＰＵＣＣＨフォーマットに対して定義される。そのようなシナリオにおいて、ＷＴＲＵは、いずれかのペイロード事例に対して２つの定義されているセットの間から一方を無作為に選ぶことができる。これは、ＰＵＣＣＨリソースセットあたり多数のＷＴＲＵが割り振られる場合に、複数のＷＴＲＵの間の衝突の可能性を低減するのに役立ち得る。
【００８０】
選択されているＰＵＣＣＨフォーマットが、適度なＵＣＩ（ＨＡＲＱ）ペイロードが可能であり、複数の／いくつかのシンボル／ミニスロット／サブスロットにわたって送信される場合（例えば、単一のリソース−ブロック対にわたるＰＵＣＣＨフォーマット４などの長い持続時間にわたるＰＵＣＣＨ）、ＰＵＣＣＨリソースセットを効率的に活用するために、複数のＷＴＲＵが同じリソース−ブロック対を共有することができる。シンボル／ミニスロット内で同じリソース−ブロック対を共有するデバイスは、周波数領域シーケンスの異なる直交位相回転（例えば、時間領域におけるサイクリックシフト）によって分離され得る。代替的にまたは付加的に、複数のリソース−ブロック対が使用される、例えば、２ビットよりも大きいなど、より大きいＵＣＩペイロードフォーマット（例えば、ＰＵＣＣＨフォーマット２または３）について、シンボル／ミニスロット／サブスロットの多重化容量は、複数のＷＴＲＵに同じリソース−ブロック対を共有させることによって増大され得、ここで、各ＷＴＲＵは、異なる直交カバーシーケンスを使用する。これによって、ＨＡＲＱフィードバックに必要とされ得るＰＵＣＣＨリソースの数を低減することができる。
【００８１】
適切なリソースセットを（例えば、ＨＡＲＱ−ＡＣＫペイロードサイズに基づいて）選択することに加えて、ＢＳ（例えば、ｇＮＢ）は、ＷＴＲＵによって、そのＨＡＲＱフィードバックを提供するために使用されることになるＰＵＣＣＨリソースを微調整することができる。これは、ＰＵＣＣＨリソースおよび／またはＰＵＣＣＨリソースセット内のフォーマットを動的に制御するために使用され得る、ＬＴＥにおける２ビットのＡＣＫ−ＮＡＣＫオフセットフィールド（ＡＮＯ）と同様のＡＣＫ−ＮＡＣＫリソースインジケータ（ＡＲＩ）フィールドを利用することによって行われ得る。
【００８２】
１つの実施形態において、２ビットのＡＲＩは、以下のようにＰＵＣＣＨリソースのインデックスを提供することができ、すなわち、選択されているＰＵＣＣＨリソースセット内で、００は第１のＰＵＣＣＨリソースをインデックス付けし、０１は第２のＰＵＣＣＨリソースをインデックス付けし、１０は第３のＰＵＣＣＨリソースをインデックス付けし、１１は第４のＰＵＣＣＨリソースをインデックス付けする。
【００８３】
別の実施形態において、ＡＲＩは、特定のＰＵＣＣＨフォーマットのＰＵＣＣＨリソースインデックスのインデックスを提供することができる。例えば、ＷＴＲＵが２ビットよりも大きいＵＣＩペイロードの短いＰＵＣＣＨと長いＰＵＣＣＨの両方に対して構成される場合、これは、２つの異なるＰＵＣＣＨフォーマットによって構成され得る。一実施形態において、一方のＰＵＣＣＨフォーマットが短いＰＵＣＣＨに使用され得、他方のＰＵＣＣＨフォーマットが長いＰＵＣＣＨ送信に使用され得る。ＡＲＩインデックスは、このとき、ＰＵＣＣＨリソースインデックスおよびＰＵＣＣＨフォーマットに関する情報を提供するために利用され得る。例えば、ＡＲＩインデックスに基づいて、ＷＴＲＵは、一方のフォーマット（例えば、ＰＵＣＣＨａ）が短い持続時間のＰＵＣＣＨの送信のためのものであり、他方のフォーマット（例えば、ＰＵＣＣＨｂ）が長い持続時間のためのものである、両方が２ビットよりも大きいＵＣＩペイロードを搬送することが可能な２つのＰＵＣＣＨフォーマット（例えば、ＰＵＣＣＨａおよびＰＵＣＣＨｂ）を有するＰＵＣＣＨリソースセットを選択することができる。具体的には、ＡＲＩインデックス００は、ＰＵＣＣＨａのＰＵＣＣＨリソース１を示すことができ、インデックス０１は、ＰＵＣＣＨａのＰＵＣＣＨリソース２を示すことができ、インデックス１０は、ＰＵＣＣＨｂのＰＵＣＣＨリソース１を示すことができ、インデックス１１は、ＰＵＣＣＨｂのＰＵＣＣＨリソース２を示すことができる。
【００８４】
また別の実施形態において、短いＰＵＣＣＨフォーマットと長いＰＵＣＣＨフォーマットの両方によって構成されているＷＴＲＵは、特定の予め定められた基準に基づいて、１つのＰＵＣＣＨフォーマットを判断することができる。例えば、ＷＴＲＵが電力を制限されているかまたはカバレッジを制約されている場合、ＷＴＲＵは、長いＰＵＣＣＨフォーマットを利用するように判断することができる。そのような事例において、最良の適切なＰＵＣＣＨフォーマットを選ぶ柔軟性を有するＷＴＲＵは、ＰＵＣＣＨリソースインデックスを示すためにのみ、ＤＣＩ内のＡＲＩフィールドを使用することができる。
【００８５】
加えて、適切なＰＵＣＣＨリソースを選択する柔軟性を有することによって、ＷＴＲＵが、結果生じ得るフィードバック粒度の任意の変化に適合することが可能であり得る。例えば、ＣＢＧに基づく（再）送信のためにマルチビットＨＡＲＱフィードバックを提供するように構成されているＷＴＲＵは、ＢＳ（例えば、ｇＮＢ）がＰＤＣＣＨ上のフォールバックＤＣＩを使用してＰＤＳＣＨをスケジューリングする場合、ＴＢに基づく（再）送信のための単一ビットＨＡＲＱフィードバックによって応答することができる。フォールバックＤＣＩは、ＢＳが、送信されているトランスポートブロック（ＴＢ）のＣＢＧに基づく再送信をサポートしないことを示し得る。ＷＴＲＵがフォールバックＤＣＩを受信するとき、単一または２つのコードワード（またはＴＢ）の再送信を要求している単一ビットＨＡＲＱフィードバックにはそれで十分であるため、２ビットのより小さいＵＣＩペイロードサイズをサポートするＰＵＣＣＨフォーマット向けに構成されているＰＵＣＣＨリソースセットを選択し得る。このように、まずマルチビットＨＡＲＱフィードバックを提供するように構成されているＷＴＲＵは、（より大きいＵＣＩペイロード向けに構成されているリソースセットを利用することによる）ＣＢＧに基づく再送信のためのマルチビットＨＡＲＱフィードバックと、（より小さいＵＣＩペイロードサイズ向けに構成されているリソースセットを利用することによる）ＴＢに基づく再送信のための単一ビットＨＡＲＱフィードバックとの間で切り替えることができる。このフォールバックＤＣＩの事例において、ＢＳ（例えば、ｇＮＢ）は、ＨＡＲＱペイロードサイズが（マルチビットＨＡＲＱフィードバックから単一ビットＨＡＲＱフィードバックへと）変化しており、それに応じてＰＵＣＣＨフォーマットの変化しているため、ＷＴＲＵが、異なるＰＵＣＣＨリソースセットに切り替わっているという事実を考慮に入れて、（ＡＲＩフィールドを介して）更新されたＰＵＣＣＨリソースインデックス情報を提供することができる。新たなＡＲＩは、その後、このＰＵＣＣＨリソースセットのＰＵＣＣＨリソースインデックス情報を反映するように修正され得る。
【００８６】
ＷＴＲＵがＰＵＳＣＨ上でデータを送信している一実施形態において、ＷＴＲＵは、再送信のより微細な粒度を提供するために、マルチビットＨＡＲＱフィードバックを利用することを選択することができる。この例において、ＷＴＲＵはまた、より厳密な閾値パラメータ「δs」（δs＞δ）に基づいて、マルチビットＨＡＲＱフィードバックから単一ビットＨＡＲＱフィードバックへと切り替えることもできる。これは、ＴＢ全体が誤っている場合にのみ単一ビットに切り替えることを暗示する、例えば、δs＝１の、ＨＡＲＱフィードバックがＰＵＣＣＨ上で送信される場合よりも厳密である。
【００８７】
別の実施形態において、ＷＴＲＵは、マルチビットＨＡＲＱフィードバックと単一ビットＨＡＲＱフィードバックの両方を同時にＢＳ（例えば、ｇＮＢ）に提供するなど、複数のＨＡＲＱフィードバックのオプションを提供するように構成され得る。両方のタイプのＨＡＲＱフィードバックを提供することは、組み込み誤り検出およびＨＡＲＱフィードバックの誤りに対する追加されたロバスト性を必要とし得る。例えば、プリエンプションによって影響される単一のＣＢＧを用いるＷＴＲＵは、影響されるＣＢＧに関するマルチビットＨＡＲＱフィードバックと、ＴＢに関する単一ビットフィードバックの両方を提供することができる。これは、マルチビットＨＡＲＱフィードバックが、影響されるＣＢＧに関する単一のＮＡＣＫを含み、単一ビットＨＡＲＱフィードバックが、ＴＢに関する単一のＮＡＣＫを含むことを意味する。いずれかのＮＡＣＫビットがＮＡＣＫ−ＡＣＫの誤りによって影響される場合、ＢＳ（例えば、ｇＮＢ）は依然として、ＴＢの少なくとも何らかの部分がＷＴＲＵによって正確に復号されなかったことを伝達することが可能であり得る。この事例において、ＢＳ（例えば、ｇＮＢ）は、ＴＢ全体を再送信する（影響されるＣＢＧに関する単一のＮＡＣＫがＡＣＫに反転される場合）か、または、ＮＡＣＫを受信したＣＢＧのみを再送信するように判断することができる。前者の場合（すなわち、ＴＢ全体の再送信）の結果として、不要な送信が発生し得るが、これは、影響されるＣＢＧの再送信は、ＲＬＣプロトコルによって補正される可能性があることに起因して、（例えば、ＴＢ全体を首尾よく受信するまで）ＴＢ全体を再送信するよりも長い時間がかかる場合があるため、代替形態（すなわち、影響されるＣＢＧの再送信）よりも好ましい場合がある。
【００８８】
マルチビットＨＡＲＱフィードバックを提供するように構成されているＷＴＲＵはまた、フィードバックオーバーヘッドを低減するための方法としてのフォールバックのオプションとして、単一ビットフィードバックに戻るかまたはこれを利用することもできる。ＷＴＲＵはまた、マルチビットＨＡＲＱフィードバックと単一ビットＨＡＲＱフィードバックの両方のオプションによって構成されてもよく、ＢＳ（例えば、ｇＮＢ）によってスケジューリングされている（再）送信が、少なくとも１つの（再）送信されているＣＢＧに誤り（すなわち、ＮＡＣＫ）をもたらす限り、マルチビットＨＡＲＱフィードバックを提供することができる。全てのＣＢＧ（および、従って、ＴＢ全体）がＷＴＲＵによって首尾よく受信されると、ＷＴＲＵはその後、ＴＢ全体がその時点で首尾よく受信されたことをＢＳ（例えば、ｇＮＢ）に通知するために、単一ビットＨＡＲＱフィードバックメッセージを送ることができる。このマルチビットＨＡＲＱフィードバックから単一ビットＨＡＲＱフィードバックへの切り替えの結果として、性能に悪影響を与えないままで、オーバーヘッドが低減されるようにすることができる。
【００８９】
別の実施形態において、マルチビットＨＡＲＱフィードバックと単一ビットＨＡＲＱフィードバックの両方のオプションによって構成されているＷＴＲＵは、プリエンプトされているデータに起因して（例えば、ＣＢＧの絶対数または構成されているＣＢＧの割合／比などの何らかの閾値に基づいて）相当数のＣＢＧが復号不可能である場合、ＴＢに基づく再送信のために単一ビットＨＡＲＱフィードバックを選択するように判断することができる。そのような事例において、ＷＴＲＵは、ＴＢ全体の再送信を要求することが最良であり得ると判断し得る。ＴＢ全体の再送信を要求するために、ＷＴＲＵは、単一ビットＨＡＲＱ−ＮＡＣＫを送ることができる。
【００９０】
また別の実施形態において、マルチビットＨＡＲＱフィードバック向けに構成されている（または、マルチビットＨＡＲＱフィードバックと単一ビットＨＡＲＱフィードバックの両方向けに構成されている）ＷＴＲＵは、ＰＤＳＣＨをスケジューリングするために利用されるＤＣＩの変化に起因して単一ビットフィードバックに切り替わる（またはそれを選択する）ように要求され得る。例えば、ＣＢＧに基づく（再）送信およびＤＣＩを介してスケジューリングされているＰＤＳＣＨのためのマルチビットＨＡＲＱフィードバックを用いて構成されているＷＴＲＵが、ＣＢＧに基づく送信をサポートしない場合、ＷＴＲＵは、フォールバックＤＣＩフォーマットが利用されるため、単一ビットＨＡＲＱフィードバックに切り替わる（またはそれを選択する）必要があり得る。そのようなシナリオにおいて、フォールバックＤＣＩを用いてＰＤＳＣＨをスケジューリングすることは、ＷＴＲＵが、ＴＢに基づく再送信のために単一ビットＨＡＲＱフィードバックを用いて応答する必要があることの指標と考えられ得る。周期的なＤＣＩ（または非フォールバックＤＣＩ）は、ＷＴＲＵがＣＢＧ（またはＣＢ）に基づく再送信のためにマルチビットＨＡＲＱフィードバックを用いて応答するはずであることの指標と考えられ得る。
【００９１】
各ＰＤＣＣＨは、ＷＴＲＵまたはＷＴＲＵのグループのリソース割り当ておよび他の制御情報を含む、ＤＣＩとして知られるメッセージを搬送することができる。例えば、ＤＣＩは、ダウンリンクおよびアップリンクスケジューリング情報、非周期的なチャネル品質指標（ＣＱＩ）のレポート、または、１つのセルおよび１つの無線ネットワーク一時識別子（ＲＮＴＩ）に対するアップリンク電力制御コマンドを輸送することができる。情報内容に応じて、ＤＣＩは、下記の表１に示されているように、異なるＤＣＩメッセージフォーマットを有し得る。
【００９２】
【表１】
0006835984.tif 000002
【００９３】
例えば、１つのセルにおけるＰＤＳＣＨのスケジューリングに使用されるＤＣＩフォーマット１＿１は、少なくとも１つのトランスポートブロック（ＴＢ）のためのコードブロックグループ（ＣＢＧ）に基づく（再）送信を示すフィールドを含むことができる。周期的なＤＣＩ（または非フォールバックＤＣＩ）は、ＷＴＲＵがＣＢＧ（またはＣＢ）に基づく再送信のためにマルチビットＨＡＲＱフィードバックを用いて応答するはずであることを明示的に示すために、このＤＣＩフォーマット１＿１であり得る。他方、１つのＤＬセルにおけるＰＤＳＣＨのスケジューリングに使用されるＤＣＩフォーマット１＿０は、ＣＢＧに基づく（再）送信を示すフィールドを含まない場合がある。このシナリオにおいて、ＤＣＩフォーマット１＿０を用いてＰＤＳＣＨをスケジューリングすることは、ＷＴＲＵが、ＴＢに基づく（再）送信のために単一ビットＨＡＲＱフィードバックを用いて応答する必要があることの黙示的な指標と考えられ得る。上述されているように、ＷＴＲＵは、ＤＣＩフォーマット１＿０を受信すると、ＣＢＧに基づく再送信のために単一ビットＨＡＲＱフィードバックに切り替わるかまたはそれを選択することができる。その上、ＷＴＲＵが、ＤＣＩフォーマット１＿０を有するＰＤＣＣＨによってスケジューリングされているＰＤＳＣＨを受信した場合、ＷＴＲＵは、ＰＤＳＣＨにおけるトランスポートブロックのみに関するＨＡＲＱフィードバック情報を生成することができる。上述されているフォールバックＤＣＩは、このＤＣＩフォーマット１＿０であり得る。
【００９４】
ＷＴＲＵによる、ＰＵＣＣＨリソース／フォーマットの選択は、ＷＴＲＵが、純粋にそれ自体の判断決定に基づいて（例えば、上述されているように誤りがあったＣＢＧの数に基づいて）マルチビットＨＡＲＱフィードバックから単一ビットＨＡＲＱフィードバックに切り替わったか否か、または、それが、ＰＤＳＣＨがＢＳ（例えば、ｇＮＢ）によってスケジューリングされた方法（例えば、フォールバックＤＣＩ）の変化に基づいていたか否かに基づいて、異なり得る。切り替えがフォールバックＤＣＩに起因する後者の事例において、ＢＳ（例えば、ｇＮＢ）は、選択されているＰＵＣＣＨリソースセットからの使用されるべきＰＵＣＣＨリソースのＡＲＩを動的に示すことができ、セット選択は、以前に言及されているようなＵＣＩペイロードサイズに基づくことができる。これの動的に示されるリソースはその後、ＷＴＲＵによって、単一ビットＨＡＲＱフィードバックに使用され得る。
【００９５】
ＷＴＲＵがマルチビットＨＡＲＱフィードバックから単一ビットＨＡＲＱフィードバックへと切り替わることを自動的に判断する事例において、ＷＴＲＵは、予め構成されているＰＵＣＣＨリソース（例えば、アップリンク制御情報（ＵＣＩ））を利用することができる。この目的のために、ＢＳ（例えば、ｇＮＢ）は、適切なＰＵＣＣＨリソースセットを含むＰＵＣＣＨリソースを半静的に構成することができる。この事例において、ＰＵＣＣＨリソースセットは、２ビット未満のＵＣＩペイロードをハンドリングするように構成されているセットであり得る（ＰＵＣＣＨフォーマット０／１）。この予め構成されているリソースは、ＣＢＧに基づく（再）送信のためにＰＤＳＣＨをスケジューリングする、フォールバックに基づかないＤＣＩにおけるＡＲＩを介して動的に示されるＰＵＣＣＨリソースに優先し得る。これは、このＤＣＩにおいて示されるＰＵＣＣＨリソースが、マルチビットフィードバックのペイロードサイズおよび対応するＰＵＣＣＨリソースに特異的であったためである。
【００９６】
代替的にまたは付加的に、ＷＴＲＵは、ＢＳ（例えば、ｇＮＢ）に単一ビットＨＡＲＱフィードバックを提供する目的のために、マルチビットＨＡＲＱフィードバック向けに指定されているＰＵＣＣＨリソースを利用することができる。この事例において、ＰＵＣＣＨフォーマット０およびＰＵＣＣＨフォーマット２などの両方のＰＵＣＣＨフォーマットが、同じＰＵＣＣＨリソースに使用され得る。例えば、ＰＵＣＣＨフォーマット０は１〜２ビットのＵＣＩペイロード向けに指定され得、ＰＵＣＣＨフォーマット２は、２ビットよりも大きいＵＣＩペイロードに対して定義され得る。
【００９７】
先行する例にて、構成されているＰＵＣＣＨリソースセットの数およびそれらのＵＣＩペイロード容量に関する情報は、ＷＴＲＵが送信されるＰＤＳＣＨに対するＨＡＲＱ応答を提供するときに、ＷＴＲＵが、単一ビットＨＡＲＱフィードバックまたはマルチビットＨＡＲＱフィードバックの間で自律的に判断する能力を制限し得る。例えば、ＷＴＲＵが、ＵＣＩペイロード容量の小さい単一のＰＵＣＣＨリソースセットのみを用いて構成される場合、ＷＴＲＵは、これを、常に単一ビットＨＡＲＱを用いて応答すると予測されることの指標と解釈することができる。一方、ＷＴＲＵが、大きいＵＣＩペイロードを搬送することが可能な、ＵＣＩペイロードの大きいＰＵＣＣＨリソースセットを用いて構成される場合、ＷＴＲＵは、これを、このＰＤＳＣＨに対して常にマルチビットＨＡＲＱフィードバックを用いて応答すると予測されることの明示的な指標と解釈することができる。
【００９８】
また別の実施形態において、２つ以上のＰＵＣＣＨリソースセットを用いて構成されているＷＴＲＵは、これを、適切なフィードバック粒度を選択するのはＷＴＲＵ次第であることの黙示的な指示と解釈することができる。この事例において、ＢＳ（例えば、ｇＮＢ）は、いずれのＰＵＣＣＨフォーマットが、ＷＴＲＵによって選択されたかを確認するために、ＰＵＣＣＨをブラインド復号する必要があり得る。
【００９９】
代替的にまたは付加的に、マルチビットＨＡＲＱフィードバックのオプションのみを用いて構成されているＷＴＲＵは、ＴＢレベルのフィードバックを提供するためにこの構成を利用することができる。図２に示されているように、ＴＢ２０５はＣＲＣ２１０を有し、各ＣＢ（すなわち、ＣＢ＃１  ２１５、ＣＢ＃２  ２１７、ＣＢ＃Ｍ  ２１８）は、それに付加されているＣＲＣ２３０、２３２、２３４を有する。ＷＴＲＵが全てのＣＢ２１５、２１７、２１８を含むＴＢ２０５を受信した後、ＷＴＲＵにおけるＣＢレベルのＣＲＣ検査が合格であるが、ＷＴＲＵにおけるＴＢレベルのＣＲＣ検査が失格である場合、マルチビットＨＡＲＱフィードバックフィールドは、このＴＢレベルのＮＡＣＫフィードバックを含むことができる。このＴＢレベルのＮＡＣＫフィードバック（例えば、ＮＡＣＫフィードバックビット０）は、Ｎ回繰り返され得、ＮはＣＢＧ／ＣＢの数であるか、または、Ｎは、ＣＢＧ／ＣＢの最大数である。例えば、マルチビットＨＡＲＱフィードバックを提供するように半静的に構成されているＷＴＲＵは、１６個のＣＢＧを含む２つのＴＢを受信し、ここで、各ＴＢは８個のＣＢＧを含む。第１のＴＢに関するＣＢレベルのＣＲＣおよびＴＢレベルのＣＲＣ検査が合格になった場合、ＷＴＲＵは、ＡＣＫ情報ビットを８回繰り返すことによって（すなわち、１１１１１１１１）、ＴＢレベルのＡＣＫフィードバックを生成することができる。第２のＴＢに関して、全てのＣＢレベルのＣＲＣ検査が合格になったが、ＴＢレベルのＣＲＣ検査が不合格になった場合、ＷＴＲＵは、ＮＡＣＫ情報ビットを８回繰り返すことによって（すなわち、００００００００）、ＴＢレベルのＮＡＣＫフィードバックを生成することができる。ＷＴＲＵは、マルチビットＨＡＲＱフィードバックを提供するように半静的に構成されているため、マルチビットＨＡＲＱフィードバック内のビット数は、ＣＢＧの最大数（この例では１６ビット）である必要があり得る。従って、２つの８ビット（すなわち、第１のＴＢの１１１１１１１１および第２のＴＢの００００００００）が多重化された後、ＷＴＲＵは、１６ビットのマルチビットＨＡＲＱフィードバック（すなわち、１１１１１１１１００００００００）を生成することができる。
【０１００】
言い換えれば、ＷＴＲＵがＮ個のＣＢＧの各々を正確に検出し、Ｎ個のＣＢＧのＴＢを正確に検出しない場合、ＷＴＲＵは、Ｎ個のＣＢＧの各々についてＮＡＣＫビットを生成することができる。他方、ＷＴＲＵがＮ個のＣＢＧの各々を正確に検出し、また、Ｎ個のＣＢＧのＴＢも正確に検出する場合、ＷＴＲＵは、Ｎ個のＣＢＧの各々についてＡＣＫビットを生成することができる。１つまたは複数のＴＢが使用される場合、各ＴＢの単一のＨＡＲＱコードブックが多重化される必要があり、それによって、マルチビットＨＡＲＱフィードバックが生成される。そのような手法は、ＨＡＲＱフィードバックに冗長性を付加するのを助けることができ、それによって、誤検出の確率が低減し、遅延が低減し、追加のオーバーヘッド／コストを受けない。これは、ＷＴＲＵが、マルチビットフィードバックフォーマットのペイロードを搬送するように意図されているＰＵＣＣＨフォーマットを使用するようにすでに構成されているためである。
【０１０１】
一実施形態において、ＷＴＲＵが、フォールバックＤＣＩを用いたＰＤＣＣＨによってスケジューリングされているＰＤＳＣＨを受信し、かつ、ＷＴＲＵが、マルチビットＨＡＲＱフィードバックを提供するために上位レイヤのパラメータを用いて半静的に構成されている場合、ＷＴＲＵは、Ｎ個のＨＡＲＱ  ＡＣＫまたはＮＡＣＫ情報ビットを生成するために、ＰＤＳＣＨにおけるＴＢについてＨＡＲＱ  ＡＣＫまたはＮＡＣＫをＮ回（すなわち、ＢＳによって構成されているＣＢＧの数またはＣＢＧの最大数）繰り返すことができる。
【０１０２】
図５は、本明細書において説明されている他の実施形態の任意の組み合わせにおいて使用されてもよい、ＤＣＩに基づいて単一ビットＨＡＲＱフィードバックおよび／またはマルチビットＨＡＲＱフィードバックを提供するための例示的なシグナリング手順５００を示す。図５に示されているように、ＷＴＲＵ５０５は、基地局（ＢＳ）５１０から無線リソース制御（ＲＲＣ）メッセージ５１５を受信することができる。ＲＲＣメッセージ５１５は、メッセージを送信するレイヤが媒体アクセス制御（ＭＡＣ）レイヤよりも高い、上位レイヤのメッセージとして交換可能に参照され得る。ＲＲＣレイヤは、ＢＳ（例えば、ｇＮＢ／ｅＮＢ）内に配置され、制御プレーンプロトコルをハンドリングすることができる。例えば、ＲＲＣレイヤは、システム情報のブロードキャスト、接続管理、モビリティ、ＷＴＲＵ能力などの、ＲＡＮに関係付けられる手順を管理する。これらのメッセージは、共通のまたは専用にされた制御チャネルのいずれかにマッピングされる、無線ベアラを使用して送信され得る。
【０１０３】
ＲＲＣメッセージ５１５は、ステップ５２０においてＣＢＧに基づく（再）送信のために、ＣＢＧの最大数に基づいてマルチビットＨＡＲＱフィードバックを提供するように、ＷＴＲＵを半静的に構成する上位レイヤのパラメータ（例えば、ＣＢＧ−ＤＬ＝ＯＮ）を含むことができる。例えば、ＷＴＲＵが、ＣＢＧの最大数を含む上位レイヤによって構成される場合、ＷＴＲＵは、ＴＢ受信のためのそれぞれのＨＡＲＱフィードバック情報を生成するために、最大数のＣＢＧを使用する必要があり得る。例えば、受信されているＴＢが８つのＣＢＧを含むが、上位レイヤのパラメータによって構成されているＣＢＧの最大数が１０である場合、ＷＴＲＵは、マルチビットＨＡＲＱフィードバックのために１０個のＨＡＲＱ情報ビットを生成することができる。この事例において、最初の８ビットはＣＢＧ（またはＴＢ）の復号の結果によって決定され得、最後の２ビットは、ダミービット（例えば、ＡＣＫまたはＮＡＣＫビット）に基づいて付加または挿入され得る。マルチビットＨＡＲＱフィードバックのペイロードサイズは、ＣＢＧの構成されている数によって決定され得る。例えば、マルチビットＨＡＲＱフィードバックのペイロードサイズは、ＣＢＧの最大数と同じであり得る。
【０１０４】
ＲＲＣメッセージ５１５を受信した後、ＷＴＲＵ５０５は、上述されているようにマルチビットＨＡＲＱフィードバックおよび／または単一ビットＨＡＲＱフィードバックを提供するように構成され得る。ＷＴＲＵ５０５は、ＰＤＣＣＨを介して、ＰＤＳＣＨスケジューリングのための周期的な（非フォールバック）ＤＣＩ５２５を受信することができる。周期的なＤＣＩ５２５に基づいて、ＷＴＲＵは、ＰＤＳＣＨを介してデータ（すなわち、ＴＢ）５３０を受信することができる。ＷＴＲＵ５０５は周期的なＤＣＩ５２５を受信しているため、受信されているＴＢ内の少なくとも１つのＣＢがステップ５３５において適切に復号されていないとき、ＷＴＲＵ５０５は、ＰＵＣＣＨを介してＢＳ５１０にマルチビットＨＡＲＱフィードバック５４０を送信することができる。このマルチビットＨＡＲＱフィードバック５４０は、ＵＣＩ内に含まれ得る。マルチビットＨＡＲＱフィードバック５４０はまた、ＷＴＲＵ５０５が再送信を要求しているＣＢＧの１つまたは複数のＨＡＲＱ  ＮＡＣＫ情報ビットをも含むことができる。マルチビットＨＡＲＱフィードバック５４０を送信した後、ＷＴＲＵ５０５は、再送信のためにスケジューリングされているＣＢＧ５５０について、ＰＤＣＣＨを介して周期的な（非フォールバック）ＤＣＩ５４５を受信することができる。周期的なＤＣＩ５４５がＣＢＧの再送信をスケジューリングする場合、ＤＣＩ５４５は、ＣＢＧ送信情報（ＣＢＧＴＩ：CBG transmission information）フィールドを含むことができる。ＣＢＧＴＩフィールドは、ＴＢの各ＣＢＧとの１対１のマッピングを有するビットマップを含むことができる。ＷＴＲＵ５０５は、ＣＢＧＴＩフィールドの対応する値に基づいて、ＣＢＧが再送信されるか否かを決定することができる。例えば、２進数０は、対応するＣＢＧが再送信されることを示し、２進数１は、対応するＣＢＧが再送信されないことを示す。
【０１０５】
ＷＴＲＵ５０５はまた、ＰＤＳＣＨスケジューリングのために、ＰＤＣＣＨを介してフォールバックＤＣＩ５５５をも受信することができる。フォールバックＤＣＩ５５５に基づいて、ＷＴＲＵは、ＰＤＳＣＨを介してデータ（すなわち、ＴＢ）５６０を受信することができる。ＷＴＲＵ５０５はフォールバックＤＣＩ５５５を受信しているため、受信されているＴＢ内の少なくとも１つのＣＢがステップ５６５において適切に復号されていないとき、ＷＴＲＵ５０５は、ＰＵＣＣＨを介してＢＳ５１０に単一ビットＨＡＲＱフィードバック５７０を送信することができる。この単一ビットＨＡＲＱフィードバック５７０もまた、ＵＣＩ内に含まれ得る。単一ビットＨＡＲＱフィードバック５７０はまた、ＷＴＲＵ５０５が再送信を要求しているＴＧの複数のＨＡＲＱ  ＮＡＣＫ情報ビットを含むことができる。単一ビットＨＡＲＱフィードバック５７０を送信した後、ＷＴＲＵ５０５は、再送信のためにスケジューリングされているＴＢ５８０について、ＰＤＣＣＨを介してフォールバックＤＣＩ５７５を受信することができる。単一ビットＨＡＲＱフィードバック５７０がＮＡＣＫ（すなわち、２進数０）である場合、ＷＴＲＵ５０５は、ＢＳ５１０によって再送信されている対応するＴＢを受信することができる。単一ビットＨＡＲＱフィードバック５７０がＡＣＫ（すなわち、２進数１）である場合、ＷＴＲＵ５０５は、ＢＳ５１０からさらなる再送信を一切受信しない。
【０１０６】
図６は、本明細書において説明されている他の実施形態の任意の組み合わせにおいて使用されてもよい、ＤＣＩに基づいて単一ビットＨＡＲＱフィードバックおよび／またはマルチビットＨＡＲＱフィードバックを提供するための例示的な手順６００を示す。ステップ６０５において、ＷＴＲＵは、上述されているようにマルチビットＨＡＲＱフィードバックおよび／または単一ビットＨＡＲＱフィードバックを提供するように構成され得る。ステップ６１０において、ＷＴＲＵは、ＰＤＳＣＨスケジューリングのために、ＰＤＣＣＨを介してＤＣＩを受信することができる。ステップ６１５において、ＷＴＲＵはデータ（すなわち、ＴＢ）を受信することができる。ステップ６２０において、受信されているＤＣＩがフォールバックＤＣＩであり、かつ、受信されているＴＢ内の少なくとも１つのＣＢが正確に復号されない場合、ＷＴＲＵは、ステップ６２５において単一ビットＨＡＲＱフィードバックを送信することができる。単一ビットＨＡＲＱフィードバック５７０がＮＡＣＫ（すなわち、２進数０）である場合、ＷＴＲＵは、ステップ６３０において、ＢＳ５１０によって再送信されている対応するＴＢを受信することができる。
【０１０７】
ステップ６２０において、受信されているＤＣＩが非フォールバックＤＣＩであり、かつ、受信されているＴＢ内の少なくとも１つのＣＢが正確に復号されない場合、ＷＴＲＵは、ステップ６３５においてマルチビットＨＡＲＱフィードバックを送信することができる。マルチビットＨＡＲＱフィードバックは、ＷＴＲＵが再送信を要求しているＣＢＧの１つまたは複数のＨＡＲＱ  ＮＡＣＫ情報ビットを含むことができる。ステップ６３５においてマルチビットＨＡＲＱフィードバックを送信した後、ＷＴＲＵは、再送信のためにスケジューリングされているＣＢＧについて、ＰＤＣＣＨを介して周期的な（非フォールバック）ＤＣＩを受信することができる。周期的なＤＣＩがＣＢＧの再送信をスケジューリングする場合、周期的なＤＣＩは、ＣＢＧ送信情報（ＣＢＧＴＩ）フィールドを含むことができる。ＣＢＧＴＩフィールドは、ＴＢの各ＣＢＧとの１対１のマッピングを有するビットマップを含むことができる。ＷＴＲＵは、ＣＢＧＴＩフィールドの対応する値に基づいて、ＣＢＧが再送信されるか否かを決定することができる。例えば、２進数０は、対応するＣＢＧが再送信されることを示し、２進数１は、対応するＣＢＧが再送信されないことを示す。ステップ６４０において、ＣＢＧＴＩフィールドに基づいて、ＷＴＲＵは、ＢＳによって再送信されているＣＢＧを受信することができる。
【０１０８】
図７は、本明細書において説明されている他の実施形態の任意の組み合わせにおいて使用されてもよい、ＷＴＲＵが提供すべきである単一ビットＨＡＲＱフィードバックおよび／またはマルチビットＨＡＲＱフィードバックを決定するための例示的な手順７００を示す。ステップ７０５において、ＷＴＲＵが、最初の（ＴＢ）送信またはＣＢＧに基づく再送信をＢＳから受信することができる。ステップ７１０において、ＷＴＲＵは、単一ビットＨＡＲＱフィードバックおよび／またはマルチビットＨＡＲＱフィードバックの間からＷＴＲＵが提供すべきであるＨＡＲＱフィードバックを考慮することができる。ステップ７３０において、単一ビットＨＡＲＱフィードバックとマルチビットＨＡＲＱフィードバックを考慮することを決定する場合、ＷＴＲＵは最初に、ＢＳから受信されている全てのＣＢＧに誤りがないかを検査することができる。全ての受信されているＣＢＧに誤りがない場合、ＷＴＲＵは、ステップ７２０において、単一ビットＨＡＲＱフィードバックを生成することができる。これは、単一ビットＨＡＲＱ  ＡＣＫであり得る。受信されているＣＢＧに誤りがある場合、ＷＴＲＵは、ステップ７３５において、単一ビットＨＡＲＱフィードバックおよびマルチビットＨＡＲＱフィードバックを生成することができる。これは、ＷＴＲＵが、単一ビットおよびマルチビットＨＡＲＱフィードバックを多重化することによって、単一のＨＡＲＱフィードバックメッセージを介して、複数のＴＢ（例えば、ＰＤＳＣＨ）に対するＨＡＲＱフィードバックを提供している事例に関連し得る。
【０１０９】
ステップ７１０において、ＷＴＲＵが、単一ビットＨＡＲＱフィードバックおよび／またはマルチビットＨＡＲＱフィードバックの間からＷＴＲＵが提供すべきであるＨＡＲＱフィードバックを考慮しないと決定する場合、ＷＴＲＵは、ＷＴＲＵがいずれのＨＡＲＱフィードバックを選択するかを決定するために他の要因を考慮することができる。例えばステップ７１５において、ＷＴＲＵは、ＴＢ内の全ＣＢＧに対する、誤りのあるＣＢＧの比を考慮することができる。ＴＢ内の全ＣＢＧに対する、誤りのあるＣＢＧの比が予め定められた閾値（δ）よりも大きい場合、ＷＴＲＵは、ステップ７２０において、ＴＢに基づく再送信のために、単一ビットＨＡＲＱフィードバックを生成することができる。ＴＢ内の全ＣＢＧに対する、誤りのあるＣＢＧの比が予め定められた閾値（δ）よりも小さい場合、ＷＴＲＵは、ステップ７２５において、ＣＢＧに基づく再送信のために、マルチビットＨＡＲＱフィードバックを生成することができる。最後に、ＷＴＲＵは、ステップ７４０において、決定されているＨＡＲＱフィードバックをＢＳに送信することができる。
【０１１０】
１つの実施形態において、ＷＴＲＵは、マルチビットＨＡＲＱフィードバックのオプションを利用するように構成され得る。マルチビットＨＡＲＱフィードバックのオプションは、ＣＢに基づいてもよく、ＣＢＧに基づいてもよく、ＣＢに基づくのとＣＢＧに基づくのとの間で切り替わってもよい。例えば、ＷＴＲＵまたはＷＴＲＵのグループは、ＣＢＧに基づく再送信のためにマルチビットＨＡＲＱを利用するように半静的に構成され得る。ネットワークは、低遅延トラフィックが、「Ｘ」ｍｓごとに送信機会を必要とする、本質的に周期的なものであることを経時的に推測することができ、これは転じて、ＷＴＲＵまたはＷＴＲＵのグループのためのＣＢの数が制限されていることを意味し得る。そのような事例において、システムがＣＢに基づくマルチビットＨＡＲＱフィードバックに切り替わることが有益である。これを行うために、ＢＳ（例えば、ｇＮＢ）は、ＷＴＲＵの影響されるセットを動的に（再）構成することができる。
【０１１１】
別の実施形態において、ＢＳ（例えば、ｇＮＢ）によってサービスされるＷＴＲＵは、デフォルトのＨＡＲＱフィードバック設定によって初期化され得る。初期／デフォルトのＨＡＲＱフィードバック設定は、単一ビットＨＡＲＱフィードバックまたはマルチビットＨＡＲＱフィードバックであってもよい。マルチビットＨＡＲＱフィードバックがデフォルトの設定である場合、システムは、予め定められた最大ビット数「Ｎ＿ｍａｘ」を有することができ、各ビットは、ＣＢ、または、複数のＣＢを含むＣＢＧのいずれかに適用される。加えて、各ビットは、ＣＢに適用されるかまたはＣＢＧに適用されるかにかかわらず、システムの最大のＴＢをカバーすることが可能である。Ｎ＿ｍａｘの選択は、Ｎ＿ｍａｘの可能な最大値に関して低い複雑度から適度な複雑度までを維持しながら、再送信のために十分に微細な粒度の選択が可能であることに関する、柔軟性の間のトレードオフを提供し得る。
【０１１２】
ＣＢＧに基づく再送信を可能にするために、ＢＳ（例えば、ｇＮＢ）は、ＴＢに基づく初期送信と、ＣＢＧに基づく（再）送信の両方をスケジューリングする必要があり得る。ＢＳ（例えば、ｇＮＢ）は、ＣＢＧに基づく（再）送信をスケジューリングするために別個のＤＣＩフォーマット（例えば、非フォールバックＤＣＩ）を利用しながら、初期のＴＢに基づく送信をスケジューリングするために、スケジューリング割り当て（例えば、フォールバックＤＣＩ）を使用することができる。スケジューリング割り当て（すなわち、ＤＣＩ）は、変調符号化方式（ＭＣＳ）、冗長バージョン（ＲＶ）、新規データインジケータ（ＮＤＩ）などのフィールドを含むことができる。代替的にまたは付加的に、スケジューリング割り当ては、ＣＢＧが再送信のためにスケジューリングされていることをＷＴＲＵに明示的に示すために、ＣＢＧインジケータフィールド（ＣＢＧＩＦ：CBG indicator field）またはＣＢＧ送信情報（ＣＢＧＴＩ）フィールドを含むことができる。
【０１１３】
代替的にまたは付加的に、ＢＳ（例えば、ｇＮＢ）は、既存のフィールドが初期ＴＢフィールドに適用されるか否かであって、それらの既存のフィールドは、それらの元々の有意性を有する、適用されるか否か、または、それらの既存のフィールドがＣＢＧに基づく再送信に適用されるか否かを集合的に示すための既存のＮＤＩフィールドまたは新たなフラグなどの、単一ビットフラグを有する、例えば、ＭＣＳ／ＮＤＩ／ＲＶなどの、既存のフィールドを再使用するＤＣＩフォーマットを利用することができる。
【０１１４】
１つの実施形態において、ＢＳ（例えば、ｇＮＢ）は、ＭＣＳフィールドまたはＭＣＳフィールドの拡張されたバージョンが、いずれのＣＢＧが再送信されているかに関する情報を搬送することを、ＷＴＲＵに通知するために、ＮＤＩおよびＲＶフィールドを利用することができる。ＢＳ（例えば、ｇＮＢ）は、以前に送信されているＴＢのスケジューリングされている送信がＣＢＧに基づく再送信であり、元々と同じＲＶを再送信することをＷＴＲＵに通知するために、ＮＤＩを使用することができる。ＮＤＩフィールドまたはフラグの使用は、端末が、ＭＣＳフィールドをＣＢＧのＣＢＧＩＦ（またはＣＢＧＴＩ）が再送信されていることを示すものとして解釈でき、また再送信が元々の送信と同じＭＣＳを利用していると仮定することもできることの黙示的な指標とみなされ得る。
【０１１５】
別の実施形態において、ＢＳ（例えば、ｇＮＢ）は、ＣＢＧに基づく再送信をスケジューリングするために特定的に指定されている拡張されたＤＣＩフォーマットを利用することができる。この拡張されたＤＣＩフォーマットは、例えば、ＭＣＳ／ＲＶ／ＮＤＩなど、ＬＴＥによって利用されるものと同じ元々のフィールドを含むことができる。元々のフィールドに加えて、拡張されたＤＣＩフォーマットは、再送信されているＣＢＧを通知するために、追加のＣＢＧＩＦ（またはＣＢＧＴＩ）を含むことができる。ＣＢＧＩＦまたはＣＢＧＴＩフィールドによって、ＢＳ（例えば、ｇＮＢ）はＣＢＧに基づく再送信にＭＣＳ／ＲＶフィールドを利用することができるため、ＢＳ（例えば、ｇＮＢ）は、初期送信と再送信との間で送信パラメータを適合させることに関する最大の柔軟性を有することができる。
【０１１６】
また別の実施形態において、ＢＳ（例えば、ｇＮＢ）は、初期のＴＢ送信とＣＢに基づく（再）送信の両方をスケジューリングするために、単一の共通のＤＣＩフォーマットを利用することができる。そのような手法は、ＷＴＲＵにおいて必要とされるブラインド復号の試行の数を低減することができる。利用されるＤＣＩフォーマットは、ＬＴＥによって利用されるもの（ＭＣＳ／ＲＶ／ＨＡＲＱプロセスＩＤ／ＰＵＣＣＨ電力制御など）と同じ元々のフィールド、および、追加のＣＢＧＩＦまたはＣＢＧＴＩを含むことができる。ＣＢＧＩＦまたはＣＢＧＴＩフィールドは、ＣＢＧ再送信の場合にいずれのＣＢＧが再送信されているかを示すために使用され得る。代替的にまたは付加的にＣＢＧＩＦまたはＣＢＧＴＩ内の全ての「１」の状態またはビットは、ＴＢ全体の送信／再送信を示し得る。この共通のＤＣＩのＤＣＩペイロードサイズを低減するために、ＢＳ（例えば、ｇＮＢ）によってコンパクトな割り当てフォーマットが利用され得る。例えば、連続したリソースブロック（リソース割り振りタイプ２）のみをサポートすることによって、スケジューリングの柔軟性がわずかに低減されることと引き換えに、ＤＣＩペイロードサイズを低減することができる。
【０１１７】
別の実施形態において、ＢＳ（例えば、ｇＮＢ）は、ＣＢＧＩＦを用いずに、かつ、ＣＢＧに基づくスケジューリング割り当てのためにいずれのＣＢＧが再送信されているかを明示的に示すことなく、ＴＢに基づくおよび／またはＣＢＧに基づく再送信をスケジューリングするために、ＤＣＩフォーマットを利用することができる。２つのスケジューリング割り当ては、ＮＤＩなどの既存のフィールドを利用し得るか、または、初期のＴＢに基づく送信とＣＢＧに基づく再送信との間の区別を可能にする追加のフィールドを有し得る、フラグに関して異なり得る。そのような事例において、ＢＳ（例えば、ｇＮＢ）は、いずれのＣＢＧが再送信されているかを示していないため、ＷＴＲＵは、ＨＡＲＱフィードバックを提供するときに、ＷＴＲＵが否定応答されている（ＮＡＣＫ−ｅｄ）ものとして示したＣＢＧを再送信していると黙示的に仮定し得る。スケジューリング割り当ては、既存のＬＴＥ  ＤＣＩフォーマットからＭＣＳ／ＲＶフィールドを保持することができ、これによって、ＴＢに基づく再送信からＣＢＧに基づく再送信に移行するときに、必要とされるように、例えば、ＭＣＳ／ＲＶなどの送信パラメータを適合させることに関して最大の柔軟性を可能にし得る。
【０１１８】
上述されているように、ＨＡＲＱビットの数は、柔軟性とフィードバックオーバーヘッドとの間のトレードオフを提供するように選択され得る。ＢＳ（例えば、ｇＮＢ）は、マルチビットフィードバックに「Ｎ」ビットを利用するようにＷＴＲＵまたはＷＴＲＵのグループを構成することができ、各ビットはＣＢまたはＣＢＧに適用される。例えば、ＣＢＧレベルのマルチビットＨＡＲＱフィードバックは、再送信の粒度に関する柔軟性を提供しながら、フィードバックオーバーヘッドを制限することができる。各ビットがＣＢＧに適用される「Ｎ」ビットのマルチビットＨＡＲＱフィードバック方式であって、「Ｎ」はＴＢにかかわらず固定されている、方式を利用するために、ＣＢＧ内のＣＢの数「Ｋ」は、ＴＢに従って変化し得、より大きいＴＢはより大きい「Ｋ」をもたらし、より小さいＴＢは、「Ｋ」がより小さいため、より微細な粒度の再送信をもたらす。
【０１１９】
代替的にまたは付加的に、ＢＳ（例えば、ｇＮＢ）は、その後、ＢＳ（例えば、ｇＮＢ）が半静的に適合することができる、ネットワークによって観測される最大のトランスポートブロックサイズ（ＴＢＳ）に基づいて、マルチビットＨＡＲＱフィードバックのために「Ｎ」ビットを利用するように、ＷＴＲＵのグループを半静的に構成することができる。これはその後、適切なＣＢからＣＢＧへのグループ化を決定するために使用され得る（例えば、「Ｋ」個のＣＢがＣＢＧを形成し、「Ｋ」は固定され、最大の観測されているＴＢＳに基づいて決定される）。
【０１２０】
また別の実施形態において、ＢＳ（例えば、ｇＮＢ）は、ＴＢＳとは無関係に選択される固定された「Ｋ」のＣＢからＣＢＧへのグループ化を利用することができる。この結果として、異なるＴＢに対して異なる数のＣＢＧがもたらされ、ＨＡＲＱフィードバック方式に対して異なるビット数（「Ｎ」）がもたらされる。
【０１２１】
別の実施形態において、ＢＳ（例えば、ｇＮＢ）は、ＤＣＩを介して、マルチビットＨＡＲＱフィードバックのための「Ｎ」ビットを用いて、ＷＴＲＵを動的に構成することができる。上記で定義されている「Ｎ」と「Ｋ」は両方とも、ＴＢの初期または最初の送信のＴＢに基づいて決定され得、このＴＢの全ての再送信にわたって変化され得ない。
【０１２２】
ＨＡＲＱフィードバックサイズの半静的および／または動的な構成を採用するのに加えて、ＷＴＲＵは、マルチビットＨＡＲＱフィードバックのためのＣＢＧの数（すなわち、サイズ「Ｎ」）を黙示的に導出することができる。これは、ＷＴＲＵまたはＷＴＲＵのグループに対して指定されている構成済みＰＵＣＣＨフォーマットのＵＣＩペイロードサイズに基づいて行われ得る。例えば、ＬＴＥにおけるＰＵＣＣＨフォーマット３と同様のフォーマットを用いて構成されているＷＴＲＵは、マルチビットＨＡＲＱフィードバックのために１０ビットを仮定し得、一方、ＬＴＥにおけるＰＵＣＣＨフォーマット１ｂと同様のフォーマットを用いて構成されているＷＴＲＵは、マルチビットＨＡＲＱフィードバックのために４ビットを黙示的に仮定し得る。
【０１２３】
ＢＳ（例えば、ｇＮＢ）は、ＷＴＲＵのマルチビットＨＡＲＱフィードバックサイズを再構成するために、半静的および／または動的なシグナリングを利用することができる。例えば、ＢＳ（例えば、ｇＮＢ）は、パラメータ「Ｎ」を用いてＷＴＲＵを半静的に構成することができ、「Ｎ」は、ＴＢ内のＣＢＧの総数を示す。パラメータ「Ｎ」によって、ＢＳはまた、「Ｎ」ビットのＨＡＲＱフィードバック（ＣＢＧあたり１ビット）が予測されることをＷＴＲＵに通知することもできる。加えて、ＢＳ（例えば、ｇＮＢ）は、異なる値「Ｎ1」（Ｎ1≦Ｎ）を動的に示すことができ、それによって、ここで、任意の再送信に対して「Ｎ1」ビットのＨＡＲＱフィードバックが提供されるべきであることを、ＷＴＲＵに通知する。「Ｎ1」のこの値は、ＴＢ内の全てのＣＢＧとは対照的に、再送信のためにスケジューリングされているＣＢＧに基づき得る。
【０１２４】
代替的にまたは付加的に、マルチビットＨＡＲＱフィードバックサイズの明示的な指標として使用されるＣＢＧの数の代わりに、ＷＴＲＵは、ＣＢＧ再送信のスケジューリングＤＣＩに基づいて、この情報を黙示的に導出することができる。例えば、ＷＴＲＵが、フォールバックＤＣＩを有するＰＤＣＣＨによってスケジューリングされているＰＤＳＣＨを受信した場合、ＷＴＲＵは、ＰＤＳＣＨにおけるＴＢのみに関するＨＡＲＱフィードバック情報ビットを生成することができる。例えば、変動するＵＣＩペイロードを搬送することが可能である複数のＰＵＣＣＨフォーマットを用いて構成されているＷＴＲＵは、これを黙示的な指標として解釈することができる。従って、ＷＴＲＵは、再送信されるＣＢＧに関するＨＡＲＱフィードバックを提供するために、ペイロードサイズのより小さいＰＵＣＣＨフォーマットを利用することができる。いずれのＣＢＧがスケジューリングされているかに関する情報が、スケジューリングＤＣＩのＣＢＧＩＦ（またはＣＢＧＴＩ）から導出され得る。この結果として、この可変サイズのマルチビットＨＡＲＱフィードバックの信頼性が保証され得る限り、全体的な性能に影響を与えることなく、同じＴＢの複数の（ＣＢＧに基づく）再送信を確認応答するときに、ＨＡＲＱフィードバック（すなわち、ＵＣＩサイズ）が低減され得る。
【０１２５】
マルチビットＨＡＲＱフィードバックは、再送信の間に再構成され得る。上述されているように、ＵＣＩに対するマルチビットＨＡＲＱフィードバックの影響も考慮されるべきであるが、より多数のＨＡＲＱフィードバックビットは、再送信の粒度に関してより高い柔軟性およびスペクトル効率の向上を可能にする。
【０１２６】
初期のＴＢの部分を形成する全てのＣＢＧにフィードバックを提供するのとは対照的に、ＨＡＲＱフィードバックビットの数を制限することは、再送信のために明示的にスケジューリングされているＣＢＧのみに対してＡＣＫ／ＮＡＣＫフィードバックを提供することによって達成され得る。
【０１２７】
１つの実施形態において、ＢＳ（例えば、ｇＮＢ）は、ＢＳ（例えば、ｇＮＢ）によって再送信のためにスケジューリングされているＣＢＧの数にかかわらず、例えば、ＴＢ内の全てのＣＢＧなど、固定されているＣＢＧ割り当て／スケジューリングのセットに基づいて、ＨＡＲＱフィードバックを報告するように、ＷＴＲＵまたはＷＴＲＵのグループを構成することができる。ＨＡＲＱフィードバックビットの数は、固定されており、ＴＢの初期の送信、および、このＴＢに関する、全ての後続するＣＢＧに基づく再送信のためのＣＢＧの総数に等しいため、これはＨＡＲＱ設計を単純化することができ、結果として、ＨＡＲＱフィードバックビットがいずれのＣＢＧに適用され得るかに関して曖昧さがなくなる。このシナリオの下で、ＷＴＲＵは、ＢＳ（例えば、ｇＮＢ）によって再送信されないＣＢＧに関する何らかの予め定められた規則に従うことができる。例えば、ＷＴＲＵは、これらのＣＢＧについて、それらはＷＴＲＵによって首尾よく受信（または復号）されたため、ＡＣＫを報告することができる。ＷＴＲＵが、ＴＢの以前の送信と同じＨＡＲＱプロセスに対応するＴＢの再送信に応答してＨＡＲＱ  ＡＣＫフィードバックを生成する場合、ＷＴＲＵは、ＴＢの以前の送信においてＷＴＲＵが正確に復号した各ＣＢＧのＡＣＫを生成することができる。
【０１２８】
別の実施形態において、ＢＳは、ＢＳによって再送信のためにスケジューリングされているＣＢＧの数にかかわらず、ＴＢ内の最大数のＣＢＧに基づいて、ＨＡＲＱフィードバックを報告するように、ＷＴＲＵまたはＷＴＲＵのグループを構成することができる。ＷＴＲＵが、ＣＢＧの最大数を含む上位レイヤによって構成される場合、ＷＴＲＵは、ＴＢ受信のためのそれぞれのＨＡＲＱフィードバック情報を生成するために、最大数のＣＢＧを使用する必要があり得る。例えば、受信されているＴＢが８つのＣＢＧを含むが、上位レイヤのパラメータによって構成されているＣＢＧの最大数が１０である場合、ＷＴＲＵは、マルチビットＨＡＲＱフィードバックのために１０個のＨＡＲＱ情報ビットを生成することができる。この事例において、最初の８ビットはＣＢＧ（またはＴＢ）の復号の結果によって決定され得、最後の２ビットは、ダミービット（例えば、ＡＣＫまたはＮＡＣＫビット）に基づいて付加または挿入され得る。この例において、マルチビットＨＡＲＱフィードバックのペイロードサイズは、ＣＢＧの最大数と同じであり得る。
【０１２９】
別の例において、ＢＳ（例えば、ｇＮＢ）は、再送信のために現在スケジューリングされているＣＢＧに純粋に基づく、可変ビットのＨＡＲＱフィードバック方式を採用するように、ＷＴＲＵまたはＷＴＲＵのグループを構成することができる。このフィードバック方式は、特に、プリエンプションが、初期のＴＢ送信および任意の後続する再送信における全ＣＢＧの非常に小さい比にしか影響しない場合に、ＨＡＲＱフィードバックオーバーヘッドを大幅に低減することができる。ＷＴＲＵは、ＢＳ（例えば、ｇＮＢ）に報告されているマルチビットＨＡＲＱフィードバックに小さいＣＲＣ（例えば、単一のパリティビットまたは３ビットのＣＲＣ）を付加することができる。フィードバックビットの数は、再送信の間に変化し得、ＮＡＣＫとＡＣＫとの誤りの結果として、以前に送信されているＣＢＧを復元するのが困難になり得るため、これは、可変ビットのＨＡＲＱフィードバック方法にとって有益であり得る。
【０１３０】
図８は、本明細書において説明されている他の実施形態の任意の組み合わせにおいて使用されてもよい、固定ビットのＣＢＧに基づくＨＡＲＱフィードバック８１５または可変ビットのＣＢＧに基づくＨＡＲＱフィードバック８２０、８２５に基づく、マルチビットＨＡＲＱフィードバックの例示的な再構成を示す。上述されているように、マルチビットＨＡＲＱフィードバックは、ＷＴＲＵが再送信を要求しているＣＢＧの１つまたは複数のＨＡＲＱ  ＮＡＣＫ情報ビットを含むことができる。マルチビットＨＡＲＱフィードバックを送信した後、ＷＴＲＵは、再送信のためにスケジューリングされているＣＢＧについて、ＰＤＣＣＨを介してＤＣＩを受信することができる。ＤＣＩは、送信のためにスケジューリングされているＣＢＧ８０５のビットマップを含むことができる。図８に示されているように、ＣＢＧ８０５のビットマップは、ＣＢＧ２、ＣＢＧ３、ＣＢＧ４、ＣＢＧ５およびＣＢＧ６  ８１０が再送信のためにスケジューリングされているＣＢＧであることを示す。ＷＴＲＵが、再送信されているＣＢＧ８１０（すなわち、ＣＢＧ２、ＣＢＧ３、ＣＢＧ４、ＣＢＧ５およびＣＢＧ６）を受信すると、ＷＴＲＵは、固定ビットのＣＢＧに基づくＨＡＲＱフィードバック８１５または可変ビットのＣＢＧに基づくＨＡＲＱフィードバック８２０、８２５に基づいて、マルチビットＨＡＲＱフィードバックを再構成することができる。
【０１３１】
ＷＴＲＵが、固定ビットのＣＢＧに基づくＨＡＲＱフィードバック８１５を提供するように再構成される場合、ＷＴＲＵは、ＴＢ内のＣＢＧの総数に基づいて、マルチビットＨＡＲＱフィードバック（すなわち、固定ビットのＣＢＧに基づくＨＡＲＱフィードバック８１５）を生成することができる。図８に示されているように、マルチビットＨＡＲＱフィードバックは、その固定ビットのＣＢＧに基づくＨＡＲＱフィードバック８１５のために１２ビットを含むことができる。ＷＴＲＵは、復号の結果に基づいて再送信されているＣＢＧ８１０のＡＣＫまたはＮＡＣＫビット８１６を生成することができる。以前の送信において首尾よく受信（または復号）されたＣＢＧ（すなわち、ＣＢＧ１、ＣＢＧ７〜１２）について、ＷＴＲＵは、ＡＣＫビット８１７を生成することができる。
【０１３２】
ＷＴＲＵが、可変ビットのＣＢＧに基づくＨＡＲＱフィードバック８２０、８２５を提供するように再構成される場合、ＷＴＲＵは、スケジューリングされているＣＢＧの総数に基づいて、マルチビットＨＡＲＱフィードバック（すなわち、可変ビットのＣＢＧに基づくＨＡＲＱフィードバック８２０、８２５）を生成することができる。図８に示されているように、マルチビットＨＡＲＱフィードバックは、その可変ビットのＣＢＧに基づくＨＡＲＱフィードバック８２０のために５ビットを含むことができる。ＷＴＲＵは、復号の結果に基づいて再送信されているＣＢＧ８１０のＡＣＫまたはＮＡＣＫビット８２０を生成することができる。加えて、可変ビットのＣＢＧに基づくＨＡＲＱフィードバック８２５は、誤り検出のためのＣＲＣ８３０を含むことができる。例えば、単一ビットのＣＲＣ８３０または３ビットのＣＲＣ８３０が、ＢＳに報告されているマルチビットＨＡＲＱフィードバック（すなわち、可変ビットのＣＢＧに基づくＨＡＲＱフィードバック８２５）に付加され得る。例えば、スケジューリングされているＣＢＧの数が少なく、かつ／または、ＮＡＣＫとＡＣＫとの誤りの確率が低い場合、ＷＴＲＵは、誤り検出のために単一のパリティビットのみを含むことを選択することができる。代替的にまたは付加的に、スケジューリングされているＣＢＧの数が多く、かつ／または、ＮＡＣＫとＡＣＫとの誤りに遭遇する可能性がある場合、ＷＴＲＵは、より長い、例えば、３ビットのＣＲＣを利用することを選択することができる。ＨＡＲＱフィードバックを受信すると、ＢＳ（例えば、ｇＮＢ）は、ＣＲＣを検査することができる。ＣＲＣ検査が不合格である場合、ＢＳは、ＷＴＲＵに、ＨＡＲＱフィードバックを再送することを求めることができる。代替的にまたは付加的に、ＢＳが、いずれのビットに誤りがあるかを検出することが可能である場合、ＢＳは、誤りがあるＨＡＲＱビットに対応するＣＢＧのみを再送信することを選択することができる。
【０１３３】
パリティビットまたは小さいＣＲＣを使用することによっていくらかの追加のオーバーヘッドビットがＨＡＲＱフィードバックに加わるにもかかわらず、そのような手法は、少ない数「ｋ」のＣＢＧ（ｋ＜＜Ｎ）のみが再送信のためにスケジューリングされている、固定「Ｎ」ビットのＨＡＲＱフィードバック方式を利用する代わりに使用され得る。
【０１３４】
上述されているように、ＢＳ（例えば、ｇＮＢ）は、固定マルチビットＨＡＲＱまたは可変ビットＨＡＲＱフィードバック方式を利用するように、ＷＴＲＵまたはＷＴＲＵのグループを半静的または動的に構成することができる。１つの例において、ＢＳ（例えば、ｇＮＢ）は、ＬＴＥにおけるＰＵＣＣＨフォーマット４または５と同様に、ペイロードのより大きいＰＵＣＣＨフォーマットを使用して固定マルチビットＨＡＲＱフィードバックを報告するように、ＷＴＲＵを構成することができる。別の例において、ＢＳ（例えば、ｇＮＢ）は、ＬＴＥにおけるＰＵＣＣＨフォーマット１ｂまたは３と同様に、ペイロードのより小さいＰＵＣＣＨフォーマットを使用して可変マルチビットフィードバックを報告するように、ＷＴＲＵを構成することができる。
【０１３５】
加えて、ＷＴＲＵまたはＷＴＲＵのグループは、固定ビットＨＡＲＱフィードバック報告方式と、可変ビットＨＡＲＱフィードバック報告方式との間で半静的にまたは動的に切り替えられ得る。この切り替えは、ＷＴＲＵのｅＭＢＢトラフィックをプリエンプトしているＵＲＬＬＣトラフィックの周波数、プリエンプションによって影響されている時間−周波数（Ｔ−Ｆ）リソースの量、または、観測されている干渉の変化などのような要因によって容易にされ得る。
【０１３６】
ＨＡＲＱフィードバックサイズの半静的および／または動的な構成に加えて、ＷＴＲＵは、マルチビットＨＡＲＱフィードバックに利用するためのビット数「Ｎ」を黙示的に導出することができる。これは、ＷＴＲＵまたはＷＴＲＵのグループに対して指定されている構成済みＰＵＣＣＨフォーマットに基づいて行われ得る。例えば、ペイロードサイズのより小さいＰＵＣＣＨフォーマットを用いて構成されているＷＴＲＵは、可変ビットＨＡＲＱフィードバックフォーマットを利用するための黙示的な指標としてこれを使用することができ、ＷＴＲＵは、ＢＳ（例えば、ｇＮＢ）によって再送信のためにスケジューリングされているＣＢＧのＨＡＲＱフィードバックのみを提供し得る。代替的にまたは付加的に、ＷＴＲＵが全ＣＢＧセット（ＴＢ内の全てのＣＢＧから成るセット）の全ての「Ｎ」ビットに対応することができる、ペイロードサイズのより大きいＰＵＣＣＨフォーマットを用いて構成される場合、ＷＴＲＵは、ＴＢ内の全てのＣＢＧのＨＡＲＱフィードバックを提供するための指標としてこれを使用することができる。
【０１３７】
一実施形態において、ＷＴＲＵは、ＵＣＩペイロードサイズが変動する複数のＰＵＣＣＨフォーマットを利用するように構成され得、ここで、これらのフォーマットの間で選択するというオプションがある。例えば、カバレッジまたは電力が制約されたＷＴＲＵは、電力消費を低減するための手段として、ＴＢ内の全てのＣＢＧとは対照的に、ペイロードのより小さいＰＵＣＣＨフォーマットを選択することによって、ＢＳ（例えば、ｇＮＢ）によって再送信されるＣＢＧのみに対するＨＡＲＱフィードバックを提供することができる。ＢＳ（例えば、ｇＮＢ）はこのとき、ＰＵＣＣＨフォーマット、および、従って、例えば固定または可変ビットなど、いずれのタイプのフィードバックがＷＴＲＵによって提供されているかを決定するために、ＰＵＣＣＨをブラインド復号する必要があり得る。
【０１３８】
別の実施形態において、固定ビットＨＡＲＱフィードバックと可変ビットＨＡＲＱフィードバックの両方を利用することができるように構成されているＷＴＲＵは、１つのオプションを使用して開始し、その後、プリエンプトしているトラフィックの周波数、プリエンプションによって影響されるＣＢＧ、影響されるＷＴＲＵの数、干渉などの様々な要因に基づいて、他方のオプションに切り替えることができる。例えば、ＷＴＲＵは、初期送信のためのＣＢＧセット全体（例えば、ＴＢ内の全てのＣＢＧ）に対して固定ビットＨＡＲＱフィードバックを提供することができる。しかしながら、第２の送信において、再送信されているＣＢＧの数が大幅に少ない場合、ＷＴＲＵは、現在の再送信のためにスケジューリングされているＣＢＧに対してのみ、可変ビットＨＡＲＱフィードバックを報告することがより効率的であると判断することができる。
【０１３９】
ＢＳ（例えば、ｇＮＢ）は、特定のフィードバックオプションをデフォルトのフィードバックモードとして使用するように、ＷＴＲＵを半静的に構成することができる。例えば、ＷＴＲＵは、全ＣＢＧセットに基づいて固定ビットＨＡＲＱフィードバックを利用するように構成され得るが、ＵＣＩオーバーヘッドの観点からこれが非効率であることが判明している場合、可変ビットフィードバックのオプションに切り替えることができる。例えば、誤りがあるＣＢＧが少数のみであるために、ＢＳ（例えば、ｇＮＢ）が、多数の再送信をスケジューリングする必要がある場合、固定ビットフィードバック方式の下で多数のＨＡＲＱフィードバックビットが送られる必要があるため、これは大きいアップリンクオーバーヘッドを引き起こす。デフォルトのフィードバックオプションは、いくつかのＴＢ送信に適用されるように構成され得、一方、優先的なオプションは、送信されている現在のＴＢのみに適用され得る。
【０１４０】
別の実施形態において、ＷＴＲＵは、可変ビットＨＡＲＱフィードバックのオプションをデフォルトのオプションとして利用するように構成され得るが、固定ビットＨＡＲＱフィードバックに切り替えることができる。例えば、いくつかの可変ビットフィードバックメッセージが（これらのＨＡＲＱフィードバックメッセージのＣＲＣ検査に不合格になり、結果として、ＢＳによってＨＡＲＱフィードバックの再送信が要求されることに起因して）ＷＴＲＵによって再送信される必要がある場合、この結果として、追加のＨＡＲＱオーバーヘッドおよび／またはデータ再送信が生じ得る。そのような事例において、ＷＴＲＵが、固定ビットＨＡＲＱフィードバックのオプションに戻ることがより効率的である場合がある。
【０１４１】
別の実施形態において、ＷＴＲＵは、デフォルトのフィードバック構成から代替的なフィードバックオプションへと（例えば、可変ビットＨＡＲＱフィードバックから固定ビットＨＡＲＱフィードバックへと）自律的に切り替えることができる。これは、複数のＰＵＣＣＨフォーマットを用いてＷＴＲＵを構成することによって容易にされ得る。代替的にまたは付加的に、ＨＡＲＱフィードバックオプションの切り替えまたは再構成は、ＤＣＩを介して明示的に、または、ＰＵＣＣＨフォーマットの再構成などに基づいて黙示的にシグナリングされ得る。
【０１４２】
複数のＰＤＳＣＨに対するマルチビットＨＡＲＱフィードバックが本明細書において説明されている。マルチキャリアスケジューリングの事例において、ＷＴＲＵは、複数のＴＢに対して、アグリゲートされたＨＡＲＱフィードバックを提供する必要があり得る。例えば、ＤＬ送信のための複数のスロットが、単一のＨＡＲＱ−ＡＣＫフィードバックスロットによって確認応答される必要があり得る。ペイロードのより大きいＰＵＣＣＨフォーマットを用いてさえ、送信に利用可能なＨＡＲＱフィードバックビットの数は、ＵＣＩペイロードサイズによって制限され得る。複数のＰＤＳＣＨは、複数のコンポーネントキャリア（ＣＣ）、複数のセル、複数のスロット／ミニスロット／サブスロット／非スロット、複数の帯域幅部分（ＢＷＰ）などにわたってスケジューリングされているものとして考えられ得る。本明細書において開示されている方法は、単一のＨＡＲＱフィードバックメッセージによって確認応答される必要がある複数のＰＤＳＣＨの上記シナリオのいずれかに適用することができる。
【０１４３】
一実施形態において、ＢＳ（例えば、ｇＮＢ）は、ＲＲＣシグナリングを介して、および／または、動的にＬ１／Ｌ２レイヤシグナリングを介して、複数のＴＢのためのフィードバックを提供するために固定されたＨＡＲＱ−ＡＣＫフィードバックフォーマットを利用するように、ＷＴＲＵを半静的に構成することができる。ＷＴＲＵは、その後、単一のＨＡＲＱ−ＡＣＫフィードバックメッセージにおいて全てのＴＢにわたって、例えば、ＴＢ内の全てのＣＢＧなど、ＣＢＧセット全体に関するＡＣＫ−ＮＡＣＫ情報を送る、複数のＰＤＳＣＨ  ＴＢに対するＨＡＲＱ−ＡＣＫフィードバックを多重化することができる。複数のＴＢに対するＨＡＲＱフィードバックを多重化することは、ＷＴＲＵまたはＷＴＲＵのグループが、同じマルチビットＨＡＲＱフィードバックにおいて複数のＴＢの受信を確認応答することを意味し得る。例えば、ＷＴＲＵが２つのＴＢを受信する場合、ＷＴＲＵは、第１のＴＢのＨＡＲＱ−ＡＣＫ情報ビットの後に、第２のＴＢのＨＡＲＱ−ＡＣＫ情報ビットを連結することができる。例えば、ＷＴＲＵが２つのＴＢを受信し、各ＴＢが８つのＣＢＧを含む場合、マルチビットＨＡＲＱフィードバックは、２つのＴＢの１６個のＨＡＲＱ−ＡＣＫ情報ビットを含むことができる。最初の８ビットは、第１のＴＢ内のＣＢＧのＨＡＲＱ−ＡＣＫ情報ビットを表すことができ、第２の８ビットは、第２のＴＢ内のＣＢＧのＨＡＲＱ情報ビットを表すことができる。ＷＴＲＵが、ＣＢＧの全てのＣＢを正確に受信した場合、ＷＴＲＵは、ＣＢＧのＨＡＲＱ−ＡＣＫ情報ビットのＡＣＫを生成することができる。ＷＴＲＵが、ＣＢＧの少なくとも１つのＣＢを正確に受信しなかった場合、ＷＴＲＵは、ＣＢＧのＨＡＲＱ−ＡＣＫ情報ビットのＮＡＣＫを生成することができる。
【０１４４】
代替的にまたは付加的に、ＢＳ（例えば、ｇＮＢ）は、複数のＴＢのフィードバックを提供するのに必要とされるＨＡＲＱフィードバックビットの総数を低減するために、可変ビットＨＡＲＱ−ＡＣＫフィードバックを利用するように、ＷＴＲＵまたはＷＴＲＵのグループを半静的および／または動的に構成することができる。ＷＴＲＵは、その後、単一のＨＡＲＱ−ＡＣＫフィードバックメッセージにおいて全てのＴＢにわたって再送信のためにスケジューリングされているＣＢＧのみに関するＡＣＫまたはＮＡＣＫを送る、複数のＰＤＳＣＨに対するＨＡＲＱ−ＡＣＫフィードバックを多重化することができる。
【０１４５】
別の実施形態において、ＢＳ（例えば、ｇＮＢ）は、ペイロードが変動する１つまたは複数のＰＵＣＣＨフォーマットタイプを利用するように、ＷＴＲＵまたはＷＴＲＵのグループを構成することができる。ＷＴＲＵはこのとき、これは、特定のフィードバックフォーマットを利用するための黙示的な指標であると仮定することができる。例えば、小さいＵＣＩペイロードのみを搬送することが可能なＰＵＣＣＨフォーマットを用いて構成されているＷＴＲＵは、ＢＳ（例えば、ｇＮＢ）がＴＢに基づくＨＡＲＱフィードバックのみを予測することの指標として解釈され得る。ＷＴＲＵはこのとき、各ＴＢのＡＣＫ−ＮＡＣＫフィードバックを多重化し、これをフィードバックとしてＢＳ（例えば、ｇＮＢ）に提供することができる。
【０１４６】
別の実施形態において、ＢＳ（例えば、ｇＮＢ）は、大きいＵＣＩペイロードを搬送することが可能である単一のＰＵＣＣＨフォーマットを利用するように、ＷＴＲＵまたはＷＴＲＵのグループを構成することができる。これは、ＢＳ（例えば、ｇＮＢ）が、各多重化されたＰＤＳＣＨについて、ＣＢＧに基づくＨＡＲＱフィードバックまたはＣＢＧレベルとＴＢレベルとが組み合わされたフィードバックを予測することの指標として解釈され得る。
【０１４７】
また別の実施形態において、複数のＰＵＣＣＨリソース／リソースセット／フォーマットを用いて構成されているＷＴＲＵは、ＵＣＩペイロードに基づいて、ＰＵＣＣＨリソース／リソースセット／フォーマットの中から１つまたは複数のリソースを選択することができる。例えば、ＷＴＲＵが、複数のＴ−Ｆリソース（例えば、スロット、セル、ＣＣ、ＢＷＰなど）にわたるいくつかのＰＤＳＣＨに対するマルチビットＨＡＲＱフィードバック応答を提供する必要がある場合、ＷＴＲＵは、最大のＵＣＩペイロードサイズ向けに構成されているＰＵＣＣＨリソースセットを選択することができる。しかしながら、ＷＴＲＵが、少数のＰＤＳＣＨに対するマルチビットＨＡＲＱフィードバックを提供する必要がある場合、ＷＴＲＵは、わずかにより小さいＵＣＩペイロードサイズ向けに構成されているＰＵＣＣＨリソースセットを選択することによって最良にサービスされ得る。ＰＵＣＣＨリソースセット／フォーマットおよびＰＵＣＣＨリソース選択に関する追加の詳細が、本明細書において開示されている。
【０１４８】
別の実施形態において、複数のＰＵＣＣＨフォーマットオプションを用いて構成されているＷＴＲＵは、（例えば、ＣＢＧに基づくおよび／またはＴＢに基づくフィードバックを多重化することによって）ＴＢに対して単一ビットＨＡＲＱフィードバックを提供しようとしているか、または、マルチビットＨＡＲＱフィードバックを提供しようとしているかを自律的に判断することができる。例えば、ＷＴＲＵは、ＨＡＲＱフィードバックのサイズに基づいて、複数のＰＵＣＣＨフォーマットの中から適切なＰＵＣＣＨフォーマットを選択することができる。適切なＰＵＣＣＨフォーマットは、大きいまたは小さいＵＣＩペイロード容量をサポートすることができるフォーマットであり得る。適切なＰＵＣＣＨフォーマットおよびＨＡＲＱフィードバックのサイズに基づいて、ＷＴＲＵは、提供すべきＨＡＲＱフィードバックのタイプを決定することができる。加えて、ＢＳ（例えば、ｇＮＢ）は、その後、ＰＵＣＣＨをブラインド復号することによって、いずれのタイプのフィードバックが提供されたかを確認することができる。
【０１４９】
代替的にまたは付加的に、確認応答される必要がある全てのＴＢのＣＢＧにわたってマルチビットＨＡＲＱフィードバックを多重化する代わりに、ＢＳ（例えば、ｇＮＢ）は、ＷＴＲＵに、全てのＴＢのサブセットに対するＣＢＧに基づくマルチビットＨＡＲＱフィードバックと、残りのＴＢに対するＴＢに基づく単一ビットＨＡＲＱフィードバックとを多重化する柔軟性を提供することができる。具体的には、上位レイヤのパラメータを用いて半静的および／または動的に構成されているＷＴＲＵは、残りのＴＢに対するＴＢに基づく単一ビットＨＡＲＱフィードバックを提供しながら、ＴＢのサブセットに対するＣＢＧに基づくマルチビットＨＡＲＱフィードバックを多重化することができる。例えば、それぞれ５つのコンポーネントキャリアを介して５つのＴＢを受信したＷＴＲＵは、最初の３つのＣＣに対するＣＢＧにマルチビットＨＡＲＱフィードバック、および、残りの２つのＣＣに対するＴＢに基づく単一ビットＨＡＲＱフィードバックを提供するように構成され得る。これは、ＷＴＲＵが、最初の３つのＣＣを介して受信される最初の３つのＴＢに対するマルチビットＨＡＲＱフィードバック、および、残りの２つのＣＣを介して受信される残りのＴＢに対する単一ビットＨＡＲＱフィードバックを提供することができることを意味する。これらのマルチビットＨＡＲＱフィードバックおよび単一ビットＨＡＲＱフィードバックは、単一のフィードバックメッセージに多重化（または連結）され得る。この技法は、動的なコードブック設計として参照される場合がある。例えば、多重化されたフィードバックメッセージは、マルチビットＨＡＲＱフィードバックおよび単一ビットＨＡＲＱフィードバックを含むことができ、第１のサブコードブックおよび第２のサブコードブックを含むコードブックに基づいて生成され得る。第１のサブコードブックは、フォールバックＤＣＩによってスケジューリングされるＴＢに基づくＰＤＳＣＨ受信に基づいて決定され得る。第２のサブコードブックは、非フォールバックＤＣＩによってスケジューリングされるＣＢＧに基づくＰＤＳＣＨ受信に基づいて決定され得る。
【０１５０】
ＣＢＧに基づくマルチビットＨＡＲＱフィードバックは、プリエンプションによって影響されるＴＢに利用され得、一方、プリエンプションによって影響されないかまたは全てのＣＢＧを首尾よく受信する（すなわち、ＴＢ全体を正確に受信する）ＴＢは、ＴＢに基づく単一ビットＨＡＲＱフィードバックによって確認応答され得る。ＣＢＧに基づくマルチビットＨＡＲＱフィードバックという用語は、マルチビットＨＡＲＱフィードバックと交換可能に使用され得、ＴＢに基づく単一ビットＨＡＲＱフィードバックという用語は、単一ビットＨＡＲＱフィードバックと交換可能に使用され得る。
【０１５１】
ＢＳ（例えば、ｇＮＢ）は、ＷＴＲＵが、単一のＨＡＲＱフィードバックメッセージにおいて、いくつかのＰＤＳＣＨに対するこの多重化されたＣＢＧに基づくマルチビットＨＡＲＱフィードバックおよびＴＢに基づく単一ビットＨＡＲＱフィードバックを提供することを可能にするフィードバック構成（すなわち、ＰＵＣＣＨフォーマット）を用いてＷＴＲＵを構成することができる。例えば、ＷＴＲＵが、ＰＵＣＣＨフォーマット２またはＰＵＣＣＨフォーマット３またはＰＵＣＣＨフォーマット４を使用してＨＡＲＱフィードバックを送信する場合、ＷＴＲＵは、この単一のＨＡＲＱフィードバックメッセージを提供するために上位レイヤのパラメータを用いて半静的および動的に構成され得る。上位レイヤのパラメータは、ＷＴＲＵがＨＡＲＱフィードバックを提供するように半静的に構成されていることを示すインジケータ（例えば、ＣＢＧ−ＤＬ＝ＯＮ）を含むことができる。インジケータ（例えば、ＣＢＧ−ＤＬ＝ＯＦＦ）はまた、ＷＴＲＵがＨＡＲＱフィードバックを提供するように動的に構成されていることも示すことができる。一実施形態において、ＷＴＲＵは上位レイヤのパラメータを用いて構成されないが、ＷＴＲＵは、多重化されたＣＢＧに基づくマルチビットＨＡＲＱフィードバックおよびＴＢに基づく単一ビットＨＡＲＱフィードバックを提供することができる。構成済みフィードバックフォーマットは、各ＰＤＳＣＨに対するＣＢＧに基づくマルチビットＨＡＲＱフィードバックとＴＢに基づく単一ビットＨＡＲＱフィードバックの両方のフィールドを提供することができる。ＷＴＲＵは、これらのＰＤＳＣＨ送信がＣＢＧに基づくマルチビットＨＡＲＱフィードバックによってより良好にサービスされ得ることの指標として、ＢＳ（例えば、ｇＮＢ）によって送信されるプリエンプション指標の存在を利用することができ、一方、復号されるのに失敗し、プリエンプトされなかった（すなわち、プリエンプション指標が存在しない）ＰＤＳＣＨは、ＴＢ全体を再送信することによって、より良好にサービスされ得る。ＴＢとＣＢＧの両方のレベルのフィードバックをサポートする単一のＰＵＣＣＨフォーマットを使用することによって、ＷＴＲＵに、一切の追加のＵＬシグナリングを必要とすることなく、ＰＤＳＣＨごとにＰＤＳＣＨに関するＣＢＧおよび／またはＴＢレベルのフィードバックを提供すべきか否かを選択する柔軟性を提供することができるため、一定程度の柔軟性を提供しながら、フィードバック設計を単純化することができる。ＷＴＲＵはまた、その判断決定の補助においてプリエンプション指標などの追加のシグナリングの存在を利用することもできる。
【０１５２】
ＷＴＲＵは、ＴＢビットマップなどのＰＵＣＣＨフィールド内のフィールドを介してＴＢのサブセットを示すことができる。ＷＴＲＵが、単一のＨＡＲＱ−ＡＣＫフィードバックメッセージにおいて複数のＴＢを確認応答する方法の決定において柔軟性を有することを可能にすることは、特に、ＷＴＲＵが電力またはカバレッジを制約されているときに有益であり得る。この事例において、ＰＵＣＣＨあたりの送信されているビット数を制限することによって、ダウンリンクスペクトル効率に対する影響を無視できる程度にしながら、ＵＬカバレッジを改善することができる。
【０１５３】
一実施形態において、ＷＴＲＵは、単一のフィードバックメッセージにおいて、全てのＴＢに対する、または、ＴＢのサブセットのみに対する、バンドル化されたＨＡＲＱフィードバックを提供することができる。例えば、ＷＴＲＵは、ＷＴＲＵによって正確に受信されたＴＢのみにわたって、各ＴＢからの単一ビットのＡＣＫを多重化し、または、誤って受信されている各ＴＢからの単一ビットのＮＡＣＫを多重化することができる。
【０１５４】
単一のＰＤＳＣＨの事例と同様に、ＷＴＲＵまたはＷＴＲＵのグループは、構成済みＰＵＣＣＨフォーマットに基づいてＨＡＲＱフィードバックフォーマットについて判断することができる。例えば、小さい（または最小の）ＰＵＣＣＨペイロードフォーマットを用いて構成されているＷＴＲＵは、ＢＳ（例えば、ｇＮＢ）が、全てのＰＤＳＣＨに対する多重化されたＴＢに基づく単一ビットＨＡＲＱフィードバックを受信すると予測することの黙示的な指標としてこれを解釈することができ、一方、大きいＰＵＣＣＨペイロードフォーマットを用いて構成されているＷＴＲＵは、ＢＳ（例えば、ｇＮＢ）が、いくつかのＰＤＳＣＨに対する、ＴＢに基づくマルチビットとＣＢＧに基づく単一ビットの両方の多重化されたＨＡＲＱフィードバックを含む単一のフィードバックメッセージを受信すると予測することの指標としてこれを解釈することができる。
【０１５５】
複数のＰＤＳＣＨに対するフィードバックオプションを容易にするために、ＨＡＲＱコードブック設計の様々な態様が考慮され得る。１つの例において、ＣＢＧに基づくマルチビットＨＡＲＱフィードバックの事例について、マルチビットＨＡＲＱフィードバックのサイズが全てのＰＤＳＣＨにわたって固定されている半静的なコードブック設計が、ＣＢＧに基づくマルチビットＨＡＲＱフィードバックに対して採用され得る。これは、全てのＰＤＳＣＨにわたる最大数のＣＢＧなどの、ＣＢＧの構成されている数に基づき得る。半静的なコードブック設計は、ＷＴＲＵが、全てのＰＤＳＣＨにわたって固定されたマルチビットフィードバックサイズを構成することを可能にすることができ、これは、全ての構成済みコンポーネントキャリア（すなわち、スケジューリングされているおよびスケジューリングされていないＰＤＳＣＨを含む全ての可能なＰＤＳＣＨ）に対するフィードバックを提供することと組み合わされる。従って、半静的なコードブック設計の結果として、複雑度が低減され得る。しかしながら、構成済みＣＢＧおよびコンポーネントキャリアの数に起因して、ＵＣＩペイロードが過度に大きくされ得る。
【０１５６】
上述されているように、上位レイヤのパラメータを用いてサービングセルごとに半静的に構成されているＷＴＲＵは、ＴＢのＣＢＧを含むＰＤＳＣＨを受信することができる。ＷＴＲＵが半静的に構成されている場合、ＷＴＲＵは、半静的なコードブックを生成するために、サービングセルごとの上位レイヤのパラメータによって最大数のＣＢＧを用いて構成され得る。この半静的なコードブックは、ＴＢ受信のためにそれぞれのＨＡＲＱ−ＡＣＫ情報ビットを含むことができる。ＨＡＲＱ−ＡＣＫ情報ビットの各々は、ＴＢ内の全てのＣＢＧ（スケジューリングされていないＣＢＧを含む）に対応することができる。半静的なコードブックのペイロードサイズは、ＣＢＧの構成されている数（すなわち、ＣＢＧの最大数）と同じであり得る。
【０１５７】
別の実施形態において、ＷＴＲＵは、ＨＡＲＱフィードバックメッセージを提供するために動的なＨＡＲＱコードブック設計を利用することができ、ここで、マルチビットＨＡＲＱフィードバックのサイズは全てのＰＤＳＣＨにわたって固定される。例えば、マルチビットＨＡＲＱフィードバックのサイズは、半静的なＨＡＲＱコードブック設計と同様に、全てのＰＤＳＣＨにわたって、構成済みＣＢＧの最大数に基づいて決定され得る。しかしながら、動的なＨＡＲＱコードブック設計においては、ＷＴＲＵは、全ての構成済みＰＤＳＣＨではなく、スケジューリングされているＰＤＳＣＨに対するＨＡＲＱフィードバックを提供することができる。これは、ダウンリンク割り当てインデックス（ＤＡＩ）のタイプのメカニズムを利用することによって容易にされ得る。そのような手法は、ＨＡＲＱフィードバックのペイロードサイズの低減をもたらすことができる。しかしながら、スケジューリングされているＰＤＳＣＨにわたる構成済みＣＢＧの数の差などの、他の要因が、この節約をオフセットする可能性がある。
【０１５８】
フィードバックリソースを効率的に利用し、無駄にされるリソースを最小限に抑えるための追加の実施形態が、本明細書において説明され得る。一例は、複数のＴＢにわたるＴＢあたりの構成済みＣＢＧの数が同様であることを保証することであり、それによって、結果として、多重化されたＰＤＳＣＨのセットについて送信される不要なフィードバックビットの数が最小限に抑えられる。これは、複数のＰＤＳＣＨにわたる全てのＴＢを、同じ数のＣＢＧを用いて、または、何らかの差分値（例えば、０もしくは１）内で構成することによって行われ得る。この結果として、これらのＴＢにわたるＣＢＧを形成するＣＢの数に関して異なる粒度をもたらすことができ、また、結果として、（再）送信の異なる粒度ももたらすことができる。しかしながら、これは、特に異なるセルが異なるカバレッジを有する場合に、ＴＢ（またはセル／ＣＣ）ごとに大きいフィードバックサイズを有するために好適であり得る。加えて、カバレッジおよび電力が制約されているＷＴＲＵに対するフィードバックビット（および、一般的に全体的なフィードバック）の数を制限することがより重要であり得る。これらの要因を考慮して、ＢＳ（例えば、ｇＮＢ）は、このカバレッジおよび電力が制約されているＷＴＲＵに対するＨＡＲＱフィードバックサイズ（対ＣＢＧ（再）送信の粒度）に関して最良のトレードオフを提供するものをファクタリングしながら、ＴＢあたりのＣＢＧの数を構成することができる。
【０１５９】
代替的にまたは付加的に、ＢＳ（例えば、ｇＮＢ）は、スケジューリングされているＰＤＳＣＨを確認応答するためにＷＴＲＵによって送られる必要があるフィードバックビットの数を低減／最適化することができるように、ＰＤＳＣＨをスケジューリングすることができる。例えば、ＢＳ（例えば、ｇＮＢ）は、連続するタイムスロットにおいて構成済みＣＢＧの何らかの「δ」内にあるＰＤＳＣＨをスケジューリングするように試行することができる。この結果として、無駄にされるまたは不要なＨＡＲＱビットの数を大幅に低減することができる。同様のサイズにされているＰＤＳＣＨをこのようにスケジューリングする結果として、特定の事例において追加のフィードバック節約をもたらすことができる。例えば、スケジューリングされているＰＤＳＣＨがいずれも低遅延トラフィックによってプリエンプトされていない場合、ＷＴＲＵは、全てのＰＤＳＣＨに対する単一ビットＨＡＲＱフィードバックの多重化／バンドル化に戻るまたはフォールバックすることができる。特に、ＰＤＳＣＨあたりの（スケジューリングされているＰＤＳＣＨの）ＣＢＧの数が少ないとき、そのようなシナリオの結果として、送信窓が、例えば、ＰＤＳＣＨあたりの構成済みＣＢＧの数がより多いときよりも小さくなり得るため、低遅延トラフィックがこれらの送信に影響を与える機会をより少なくすることができる。
【０１６０】
構成済みＣＢＧの数に基づくＰＤＳＣＨのスケジューリングは、この結果として、低遅延トラフィックによって、スケジューリングされているＰＤＳＣＨの全てが影響を受けるかまたはＰＤＳＣＨのいずれもが影響を受けないかのいずれかになり得るため、低遅延トラフィックのプリエンプションが本質的に周期的である事例において、効率的なフィードバック多重化をもたらすことができる。第１のシナリオは、低遅延トラフィックが周期的かつ頻繁である事例であり得る。第２のシナリオは、プリエンプションのトラフィックが周期的かつ相対的に頻繁でない事例であり得る。これらの事例のいずれかにおいて、ＷＴＲＵは、１つのタイプのフィードバック、例えば、第１のシナリオのマルチビットＨＡＲＱフィードバックおよび第２のシナリオの単一ビットＨＡＲＱフィードバックを必要とし得る。これによって、ＷＴＲＵが、フィードバックリソースを効率的に使用することが可能になり得る。
【０１６１】
代替的にまたは付加的に、ＢＳ（例えば、ｇＮＢ）は、割り当てられているコンポーネントキャリア（ＣＣ）に基づいてＰＤＳＣＨをスケジューリングすることができる。割り当てられているＣＣに基づくＰＤＳＣＨのスケジューリングは、これが、低遅延トラフィックをスケジューリングするためにいずれのリソースが利用される可能性が高いかに関する情報を利用する場合に有用であり得る。特定のＣＣが優先度の高い低遅延トラフィックをスケジューリングするために指定または利用される場合、ＢＳ（例えば、ｇＮＢ）は、連続するスロットにおいてこれらのＣＣをスケジューリングすること、または、連続的なスロットに対してこれらのＣＣを回避することのいずれかを考慮することができる。この結果として、このとき、全てのＰＤＳＣＨが単純にマルチビットＨＡＲＱフィードバック（スケジューリングされているＣＣ送信がプリエンプトされる事例において）または単一ビットＨＡＲＱフィードバック（スケジューリングされているＰＤＳＣＨのいずれもがプリエンプションによって影響されない事例において）を必要とし得るため、フィードバックの多重化がより効率的になり得る。
【０１６２】
代替的にまたは付加的に、ＣＣ／サービングセルのカバレッジが、スケジューリングされているＰＤＳＣＨに対する適切なＨＡＲＱフィードバックフォーマットの選択における決定要因であり得る。例えば、いくつかのＣＣのカバレッジに起因してＷＴＲＵの電力が制約されている場合、それは、これらのセルにおけるＷＴＲＵのＵＬカバレッジを改善するために、全てのスケジューリングされているＰＤＳＣＨに対するＴＢに基づく単一ビットＨＡＲＱフィードバックの多重化に戻るまたはフォールバックする必要があり得る。
【０１６３】
代替的にまたは付加的に、それは、スケジューリングされているＰＤＳＣＨに対する、ＴＢに基づく単一ビットおよび／またはＣＢＧに基づくマルチビットの多重化されたＨＡＲＱフィードバックの何らかの組み合わせを提供する必要があり得る。これは、ＰＤＳＣＨのサブセットのいくつかがプリエンプションによって影響されるシナリオに当てはまり得る。この事例において、プリエンプションによって影響されるＷＴＲＵは、個々のＣＢＧに対するフィードバックを提供するために、マルチビットＨＡＲＱフィードバックを提供する必要があり得る。しかしながら、プリエンプションによって影響されないＷＴＲＵについては、単一ビットフィードバックで十分であり得る。ＴＢに基づくフィードバックとＣＢＧに基づくフィードバックの両方のオプションを提供するために、各個々のフィードバックメッセージは、固定された単一ビットおよびマルチビットのフィードバックフィールドを含み得る。スケジューリングされているＰＤＳＣＨに対するＴＢに基づくフィードバックとＣＢＧに基づくフィードバックの両方を提供することが可能である結果として、それは、ＢＳ（例えば、ｇＮＢ）に、再送信の最適な粒度（ＣＢＧ対ＴＢ）における完全な柔軟性を提供することができる。単一のＰＤＳＣＨと同様に、ＴＢに基づくフィードバックとＣＢＧに基づくフィードバックの両方を利用することによって、ＨＡＲＱフィードバックの誤りのための組み込み誤り検出（ロバスト性が追加される）を提供することもできる。そのような手法の不都合な点は、ＵＣＩペイロードが大きい事例であり得る。
【０１６４】
ＷＴＲＵは、スケジューリングされている各ＰＤＳＣＨに対してＣＢＧに基づくマルチビットおよび／またはＴＢに基づく単一ビットＨＡＲＱフィードバックを提供すべきかに関するその判断決定を補助するために、ＢＳ（例えば、ｇＮＢ）によるプリエンプション指標の存否を利用することができる。例えば、ＷＴＲＵは、ＢＳ（例えば、ｇＮＢ）が、影響されるＰＤＳＣＨに対してＣＢＧに基づくマルチビットＨＡＲＱフィードバックを予測することの明示的な指標として、この信号を知覚することができる。別の例では、ＷＴＲＵは、いずれのタイプのフィードバックフォーマットを利用すべきかに関して自律性を有することができる。例えば、全てのスケジューリングされているＰＤＳＣＨにおいて多数のＣＢＧが首尾よく復号されることが不可能であり、かつ、ＷＴＲＵが、多重化されたＴＢに基づく単一ビットＨＡＲＱフィードバックまたは多重化されたＣＢＧに基づくマルチビットＨＡＲＱフィードバックのいずれかをサポートするために２つのＰＵＣＣＨフォーマットを用いて構成されている場合、ＷＴＲＵは、全てのＰＤＳＣＨに対してＴＢ全体の再送信を要求した方がよいと判断することができる。ＷＴＲＵは、全てのＰＤＳＣＨに対してＴＢ全体の再送信を要求すると判断するため、ＷＴＲＵは、それに応じて、全てのＰＤＳＣＨに対する単一ビットＨＡＲＱフィードバックを用いて応答することができる。
【０１６５】
上述されているように、スケジューリングされているＰＤＳＣＨにわたってＨＡＲＱフィードバックを多重化するための様々なオプションが、半静的と動的の両方のコードブック設計に適用され得る。結果として、多重化されたＰＤＳＣＨのセットに対する、ＴＢに基づく単一ビットＨＡＲＱフィードバックおよび／またはＣＢＧに基づくマルチビットＨＡＲＱフィードバック、または、両方のフィードバックの組み合わせは、半静的と動的の両方のコードブック設計に利用され得る。
【０１６６】
動的なＨＡＲＱフィードバックコードブック設計（スケジューリングされているセル／ＣＣに基づく）の事例について、ＢＳ（例えば、ｇＮＢ）は、ＰＤＳＣＨに対してスケジューリングされている各ＤＬ割り当てにおけるカウンタダウンリンク割り当てインジケータ（ＤＡＩ）および／または全ＤＡＩを使用することによって、このコードブックサイズを示すことができる。ＷＴＲＵはその後、たとえいくつかのＤＬ割り当てが失われている場合であっても、スケジューリングされているＰＤＳＣＨの数を確実に決定することができる。ＰＤＳＣＨあたりの構成済みＣＢＧの数はＷＴＲＵに示されるため、ＷＴＲＵは、その後、ＰＤＳＣＨに対するマルチビットＨＡＲＱフィードバックを決定するために、各ＰＤＳＣＨのスケジューリングされているＤＣＩからのＣＢＧＩＦビットマップ（またはＣＢＧＴＩビットマップ）とともに、この情報を使用することができる。ＤＡＩタイプフィールドを利用することは、各ＴＢが同じマルチビットＨＡＲＱフィードバックサイズを有するシナリオ（上述されているように全てのＰＤＳＣＨにわたる構成済みＣＢＧの最大数に基づき得る）に役立ち得る。
【０１６７】
単一のＰＤＳＣＨまたは多重化されていないＨＡＲＱフィードバックの事例と同様に、いくつかのＰＤＳＣＨに対する多重化されたマルチビットＨＡＲＱフィードバックを提供するために、マルチビットＨＡＲＱフィードバック向けに半静的に構成されているＷＴＲＵは、それらのそれぞれのＨＡＲＱフィードバック応答において確認応答されているＰＤＳＣＨのうちの１つまたは複数が、ＣＢＧ（再）送信をサポートしていないＤＣＩを用いてスケジューリングされているとき（例えば、ＰＤＳＣＨがフォールバックＤＣＩを介してスケジューリングされているとき）、これらのＰＤＳＣＨに対する単一ビットＨＡＲＱフィードバックに戻る必要があり得る。
【０１６８】
上述されているように、半静的なコードブック設計について、コードブックサイズは、構成済みＣＣの数、ＣＢＧの構成されている数、ＨＡＲＱタイミング窓などに依存し得る。例えば、ＴＢあたり６つのＣＢＧによって構成されるＷＴＲＵは、５つのＴＢに対して単一ビットＨＡＲＱフィードバック応答を提供する必要があり得る。単一のＨＡＲＱフィードバック応答は、各ＴＢの各コードブックを、ＴＢ全体の単一のコードブックに多重化することによって生成され得る。１つの例において、５つ全てのＴＢが、ＣＢＧに基づく（再）送信が可能であるＤＣＩによってスケジューリングされ得、ＷＴＲＵは、単純に、５＊６＝３０ビットのＨＡＲＱフィードバック応答によって応答することができる。しかしながら、１つまたは複数のＴＢがフォールバックＤＣＩを介してスケジューリングされる事例においては、ＴＢ全体がＴＢに基づく再送信のためにスケジューリングされ得る。ＷＴＲＵは、単一ビットＨＡＲＱフィードバックによって応答すべきか、または、マルチビットＨＡＲＱフィードバックによって応答すべきかを判断する必要があり得る。様々なＴＢに対して単一ビットとマルチビットとのＨＡＲＱフィードバックを混合させることによって、フィードバックが誤って解釈される可能性がある。
【０１６９】
一実施形態において、ＷＴＲＵは、同じフィードバック応答を維持する（例えば、それらが通常のまたはフォールバックＤＣＩを介してスケジューリングされているか否かにかかわらず、全てのＴＢに対してマルチビットフィードバックによって応答する）ことを選択することができる。マルチビットＨＡＲＱフィードバックを提供するように構成されているが、フォールバックＤＣＩを介してスケジューリングされているＷＴＲＵについて、ＷＴＲＵは、ＴＢが正確に受信されたか否かを示すために、単純に、単一ビットのＴＢ  ＡＣＫまたはＮＡＣＫをＮ回繰り返すことができる。ここで、ＮはＴＢ内のＣＢＧの数またはＴＢ全体であり得る。これによって、フィードバックオーバーヘッドが増大されることと引き換えには成るが、設計が単純化され得る。例えば、マルチビットＨＡＲＱフィードバックを提供するように半静的に構成されているＷＴＲＵは、２つのＴＢを受信し、ここで、各ＴＢは８個のＣＢＧを有する。第１のＴＢに関して、全てのＣＢレベルのＣＲＣおよびＴＢレベルのＣＲＣ検査が合格になった場合、ＷＴＲＵは、ＡＣＫ情報ビットを８回繰り返すことによって（すなわち、１１１１１１１１）、ＴＢレベルのＡＣＫフィードバックを生成することができる。第２のＴＢに関して、全てのＣＢレベルのＣＲＣ検査が合格になったが、ＴＢレベルの検査が不合格になった場合、ＷＴＲＵは、ＮＡＣＫ情報ビットを８回繰り返すことによって（すなわち、００００００００）、ＴＢレベルのＮＡＣＫフィードバックを生成することができる。ＷＴＲＵは、マルチビットＨＡＲＱフィードバックを提供するように半静的に構成されているため、２つの８ビットの結果（すなわち、第１のＴＢの１１１１１１１１および第２のＴＢの００００００００）は、多重化される必要があり得る。従って、ＷＴＲＵは、第１のＴＢに対する第１のマルチビットＨＡＲＱフィードバックおよび第２のＴＢに対する第２のマルチビットＨＡＲＱフィードバックを含むマルチビットＨＡＲＱフィードバックメッセージ（すなわち、１１１１１１１１００００００００）を送信することができる。
【０１７０】
別の実施形態において、フォールバックＤＣＩを用いてスケジューリングされている単一のＴＢを有するＷＴＲＵは、それが、ＣＣ／ＨＡＲＱタイミング窓内で全てのＴＢに対して単一ビットＨＡＲＱフィードバックによって応答する必要があることの指標としてこれを解釈することができる。例えば、ＷＴＲＵがそれぞれ５つのＣＣにおいてフォールバックＤＣＩを用いてスケジューリングされている５つのＴＢを受信し、かつ、各ＴＢが６つのＣＢＧを含む場合、ＷＴＲＵは、ＷＴＲＵがマルチビットＨＡＲＱフィードバックを提供するように構成されている場合に３０ビット（すなわち６ビット＊５つのＴＢ）を提供する必要があり得る。しかしながら、ＷＴＲＵが全てのＴＢに対して単一ビットＨＡＲＱフィードバックを提供することができる場合、ＨＡＲＱフィードバック内のビット数は、３０ビットから５ビットのみに降下し得る。この結果として、ＵＣＩペイロードははるかに小さくなり得るが、そのような手法の不都合な点は、不要な可能性がある再送信の回数が大きく、スペクトル効率が無駄にされることであり得る。
【０１７１】
また別の実施形態において、複数のアグリゲートされたＰＤＳＣＨに対して、単一ビットのＨＡＲＱフィードバック応答によって応答すべきか、それに対して、マルチビットＨＡＲＱフィードバック応答によって応答すべきかの選択は、確認応答される必要がある各ＰＤＳＣＨの復号結果に基づき得る。
【０１７２】
別の実施形態において、単一のＴＢがフォールバックＤＣＩを介してスケジュールされているが、ＷＴＲＵが、相当数の他のＰＤＳＣＨがＣＢＧに基づく（再）送信のためにスケジュールされている、または、相当数のＣＢＧが低遅延トラフィックをプリエンプトすることによって影響されると決定する場合、ＷＴＲＵは、これらのＰＤＳＣＨについて、ＴＢ全体の再送信を要求するように判断することができる。結果として、ＷＴＲＵはこのとき、全てのＰＤＳＣＨに対する単一ビットＨＡＲＱフィードバックメッセージによって応答することができる。この決定は、何らかの閾値に基づき得る。そのような閾値は、限定ではないが、ＰＤＳＣＨの何らかの数、または、アグリゲートされたＰＤＳＣＨの割合（ｘ％）を含むことができる。アグリゲートされたＰＤＳＣＨに対して、単一ビットとマルチビットとの間でＨＡＲＱフィードバックを切り替えるためのそのようなメカニズムを利用する結果として、フィードバックリソースの使用が最適になり（例えば、ＵＣＩペイロードを制限する）、また、結果生じ得る不要な再送信の回数も最小になる。
【０１７３】
ＷＴＲＵが、マルチビットＨＡＲＱフィードバックを用いて構成されており、ＨＡＲＱ信頼性を改善する手段として単一ビットＨＡＲＱフィードバックおよび／またはマルチビットＨＡＲＱフィードバックを示すＤＣＩ内の１つまたは複数のフィールドを提供するフィードバックフォーマットを利用する場合、ＷＴＲＵは、ＰＤＳＣＨをスケジューリングするためにフォールバックＤＣＩが利用されたか、または、非フォールバックＤＣＩが利用されたかに応じて、これらのフィールドを適切に利用することができる。例えば、非フォールバックＤＣＩを用いてスケジューリングされているＰＤＳＣＨについて、ＷＴＲＵは、各ＣＢＧに対してＨＡＲＱフィードバックを提供するためにマルチビットフィードバックを利用することができる。フォールバックＤＣＩを用いてスケジューリングされているＰＤＳＣＨについて、ＷＴＲＵは、ＴＢの復号結果に基づいて単一ビットＨＡＲＱフィードバックを提供するために、単一ビットのフィードバックフィールドを使用する（またはまったく使用しない）ことができる。他方、フォールバックＤＣＩを介してスケジューリングされているＰＤＳＣＨについて、単一ビットのＴＢの結果が関連し、ＷＴＲＵは、マルチビットのフィードバックフィールドに対して単一ビットフィードバックの結果を繰り返すことを選択することもできる（例えば、ＴＢが首尾よく復号されることができたか否かに基づいて、全てのＣＢＧに対してＡＣＫまたはＮＡＣＫ）。これは、フォールバックＤＣＩの事例において、単一ビットフィールドがより妥当であるが、マルチビットフィールドも、ＴＢに基づくマルチビットＨＡＲＱフィードバックを提供するために使用され得ることを意味する。
【０１７４】
上記実施形態において、構成されているＰＵＣＣＨリソースセットの数およびそれらのＵＣＩペイロード容量に関する情報は、複数のアグリゲートされているＰＤＳＣＨに対してＨＡＲＱフィードバック応答を提供するときに、ＷＴＲＵが、単一ビットＨＡＲＱフィードバックまたはマルチビットＨＡＲＱフィードバックの間で自律的に判断する能力を制限し得る。例えば、ＷＴＲＵが、ＵＣＩペイロード容量の小さい単一のＰＵＣＣＨリソースセットのみを用いて構成される場合、ＷＴＲＵは、これを、全てのアグリゲートされたＰＤＳＣＨに対して、常に単一ビットＨＡＲＱを用いて応答すると予測されることの指標と解釈することができる。一方、ＷＴＲＵが、大きいＵＣＩペイロードを搬送することが可能な、ＵＣＩペイロードの大きいＰＵＣＣＨリソースセットを用いて構成される場合、ＷＴＲＵは、これを、アグリゲートされたＰＤＳＣＨの各々に対して常にマルチビットＨＡＲＱフィードバックを用いて応答すると予測されることの明示的な指標と解釈することができる。
【０１７５】
また別の実施形態において、２つ以上のＰＵＣＣＨリソースセットを用いて構成されているＷＴＲＵは、これを、適切なフィードバック粒度を選択するのはＷＴＲＵ次第であることの黙示的な指示と解釈することができる。この事例において、ＢＳ（例えば、ｇＮＢ）は、いずれのフォーマットが、従って、いずれのフォーマットがＷＴＲＵによって選択されたかを確認するために、ＰＵＣＣＨをブラインド復号する必要があり得る。
【０１７６】
ＷＴＲＵが、全てのスケジューリングされているＰＤＳＣＨの構成済みＣＢＧの数が同じである、動的なＨＡＲＱコードブックの事例においてフォールバックＤＣＩと非フォールバックＤＣＩとの混合に遭遇するとき、ＷＴＲＵは、上述されているように、これらのアグリゲートされたＰＤＳＣＨに対して、単一ビットのみおよび／またはマルチビットのＨＡＲＱフィードバックを利用することを選択することができる。
【０１７７】
上述されている動的なコードブック設計は、全ての構成済みセルとは対照的に、スケジューリングされているセル／ＣＣに対してＨＡＲＱフィードバックを考慮することができる。ＣＢＧに基づくスケジューリングを用いると、コードブック設計の動的な態様に対して追加の次元の可能性が存在し、これは、ＣＢＧに基づくスケジューリング／送信の粒度の結果である。マルチビットＨＡＲＱフィードバックのサイズは、ＴＢ内のＣＢＧの総数（すなわち、ＣＢＧの構成されている数）または（再）送信のためにスケジューリングされているＣＢＧの数に基づき得る。（再）送信のためにスケジューリングされているサイズＣＢＧに基づいてサイズを決定する結果として、同じＴＢ内の再送信の間のＨＡＲＱフィードバックビットの数が可変になり得る。ＰＤＳＣＨ間の（およびＰＤＳＣＨ内の）可変ビット数を考慮に入れるために、動的なコードブック設計のＤＡＩ機能は、全ての可能な状態を考慮に入れるように拡張され得る。例えば、ＰＤＳＣＨの４つの構成済みＣＢＧによって、ＨＡＲＱフィードバックビットの数は、１から４の間で変化し得る。連続的な欠けているＤＬ割り当てをハンドリングするために、ＤＡＩは、可能な１２個の状態をサポートするために４ビットを必要とし得る。構成済みＣＢＧの数に応じて、ＤＡＩサイズ、および、ＤＣＩメッセージは、大幅に増大し得る。代替的にまたは付加的に、異なるＰＤＳＣＨは異なる数の構成済みＣＢＧを有し、ＤＡＩフィールドサイズを効率的に設計するのを困難にし得る。複雑度およびＤＣＩオーバーヘッドを制限しながら、可変ビットのフィードバックを可能にするために、様々な技法が本明細書において説明され得る。
【０１７８】
一実施形態において、ネットワークは、ＰＤＳＣＨごとに構成されているＣＢＧの数を制限することを考慮することができ、これによって、ＤＡＩによってカバーされる必要がある可能な状態の数を制限することができる。代替的にまたは付加的に、ＤＣＩの２つの特色が使用され得、それらの各々は、異なるＤＡＩフィールドサイズを有する。これは、ＢＳ（例えば、ｇＮＢ）が、大きいかまたは小さいかにかかわらず、同様の数の構成済みＣＢＧを有するＰＤＳＣＨを多重化することを考慮する場合に有益であり得、これによって、２つの特色の間で選択することが可能である。これによって、このとき、より少数の構成済みＣＢＧを有するＰＤＳＣＨのＤＣＩサイズを制限することができ、これによってまた、このフィールドを利用する効率的な方法が可能になる。
【０１７９】
別の実施形態において、ＤＣＩの２つの特色は、フィードバック長の変動性に基づいて区別され得る。例えば、一方の特色は、ＰＤＳＣＨごとに固定されたフィードバックビット数が利用される事例のものであり（この事例においては、ＬＴＥからの２ビットのＤＡＩフィールドがそのまま使用され得る）、他方の特色は、ＰＤＳＣＨごとに可変ビット数が利用される事例のものであり、これは、より大きいＤＡＩサイズを有するＤＣＩを必要とし得る。ＷＴＲＵが、両方のＤＣＩ特色をモニタリングする必要があるか否かは、上位レイヤのシグナリングによって構成され得、ＢＳ（例えば、ｇＮＢ）が、ＲＲＣシグナリングを介してＷＴＲＵごとに、ＴＢ／ＰＤＳＣＨあたりのＣＢＧの数を構成するときに同時に行われ得る（ＤＡＩサイズはＴＢ内のＣＢＧの数に直に依存するため）。
【０１８０】
また別の実施形態において、ＤＣＩの２つの特色は、ＬＴＥにおけるＤＣＩフォーマットに基づき得る。例えば、拡張されたＤＡＩフィールドが、既存のＤＣＩフォーマットフィールドによって再使用され得る。例えば、５ビットのＤＡＩフィールド（ＴＢあたり１０個のＣＢＧをサポートすることが可能）が、既存の２ビットのＤＡＩおよび３ビットのキャリアインジケータフィールド（ＣＩＦ）を組み合わせることによって考慮され得る。この結果として、クロスキャリアスケジューリングの柔軟性が損失し得るが、例えば、マクロのみの展開を考慮するとき、これ自体は問題になり得ない。これは、複数のＰＤＳＣＨのＨＡＲＱ多重化を考慮するときに、フィードバックオーバーヘッドを低減するのを大きく助けることができる。
【０１８１】
ＷＴＲＵは、ＢＳ（例えば、ｇＮＢ）によって、各ＰＵＣＣＨフォーマットが異なるペイロード（ＵＣＩ）サイズを有する、複数のＰＵＣＣＨフォーマットを利用するように構成され得る。ＷＴＲＵは、このとき、上述されているＨＡＲＱフィードバック要件に基づいて、その適切なＰＵＣＣＨフォーマットを選択する場合を考慮することができる。そのようなシナリオの下では、ＢＳ（例えば、ｇＮＢ）は、いずれのフォーマットおよびフィードバックオプションがコードブックによって利用されているかを確認するために、ＰＵＣＣＨをブラインド復号する必要があり得る。
【０１８２】
ＢＳ（例えば、ｇＮＢ）は、影響されるＷＴＲＵまたはＷＴＲＵのグループに、プリエンプションによって影響される時間−周波数（Ｔ−Ｆ）領域を黙示的または明示的のいずれかで示すことができる。システムは、低遅延トラフィックに対応するために、システム帯域幅の特定の部分が利用されることを指定することができる。指定されている領域は、ＤＬシステム帯域幅全体をカバーし得、または、全ＤＬシステム帯域幅の何らかの部分に制限され得る。指定されている領域はまた、半静的に割り当てられ得るか、または、動的に変化し得る。
【０１８３】
図９は、ＤＬシステム帯域幅の中間部分がプリエンプション可能な領域９２５として指定されている、例示的な、黙示的なプリエンプション指標９００を示す。例えば、ＢＳ（例えば、ｇＮＢ）は、ＲＲＣシグナリングを介して、全システム帯域幅のうちのいずれの部分がＢＳ（例えば、ｇＮＢ）によって低遅延トラフィックに対応するために利用され得るかをＷＴＲＵまたはＷＴＲＵのグループに半静的に示すことができる。半静的な構成は、黙示的なプリエンプション指標９００として考えられることができ、ＢＳ（例えば、ｇＮＢ）は、プリエンプション中に影響されるリソースをＷＴＲＵに明示的に示さない。この黙示的なプリエンプション指標９００は、その後、ＷＴＲＵによって、影響されているＣＢ／ＣＢＧ／ＴＢを復号するのを助けるために利用され得る。例えば、この情報を用いて構成されているＷＴＲＵは、最初に、この指定されている領域においてＰＲＢを復号するように試行することができる。この領域内のＣＢ／ＣＢＧのいずれかに誤りがある場合、ＷＴＲＵは、残りのＰＲＢをさらに処理する前に、これらのＣＢのインデックスを示すマルチビットＨＡＲＱフィードバックを送ることができる。これは、黙示的なプリエンプション指標９００に基づく早期のＨＡＲＱフィードバックメカニズムとして考えられ得る。早期のＨＡＲＱフィードバックは、早期の再送信をトリガすることができ、それによって、遅延が改善する。図９に示されているように、システム帯域幅の中間部分は、予め定められたプリエンプション可能な領域９２５として指定され得る。指定されているプリエンプション可能な領域９２５は、ＣＢ２、ＣＢ３、ＣＢ６、ＣＢ７、ＣＢ１４、ＣＢ１５、ＣＢ１８、ＣＢ１９、ＣＢ２２、ＣＢ２３、ＣＢ２６、およびＣＢ２７を含むＰＲＢを含むことができる。プリエンプション可能な領域９２５内のＣＢの中で、ＣＢ１０  ９０５、ＣＢ１１  ９１５の一部、およびＣＢ１８  ９１０は、低遅延トラフィックに対応するためにプリエンプトされていることができる。上部領域９２０および下部領域９３０は、ｅＭＢＢトラフィックＣＢのためにスケジューリングされ得る。例えば、上部領域９２０および下部領域９３０は、ＣＢ１、ＣＢ４、ＣＢ５、ＣＢ８、ＣＢ９、ＣＢ１２、ＣＢ１３、ＣＢ１６、ＣＢ１７、ＣＢ２０、ＣＢ２１、ＣＢ２４、ＣＢ２５、およびＣＢ２８を含むことができる。この黙示的なプリエンプション指標９００を用いて構成されているＷＴＲＵは、最初に、プリエンプション可能な領域９２５においてＣＢを復号しようと試行することができる。ＷＴＲＵが、プリエンプション可能な領域９２５においてＣＢのいずれかを復号することができない場合、ＷＴＲＵは、残りのＣＢを処理する前に、これらのＣＢのインデックスを示すマルチビットＨＡＲＱフィードバックを送ることができる。
【０１８４】
受信されているＣＢＧに基づく送信／（再）送信を迅速／積極的に処理する能力を保持するＷＴＲＵは、そのような早期のフィードバックメカニズムを利用することができる。そのようなＷＴＲＵは、積極的／高速／高機能ＷＴＲＵとして分類されることができ、送信されるスロット内でシンボル、ミニスロット、サブスロット、非スロットなどを積極的／迅速に処理／復号することができる。これは、ＷＴＲＵが、早期のＨＡＲＱフィードバック（すなわち、早期のＨＡＲＱタイミングに基づく早期のＨＡＲＱ−ＮＡＣＫ）を提供することを可能にすることができる。スロットに基づく通常のＨＡＲＱフィードバックタイミングとは異なり、早期のＨＡＲＱ−ＮＡＣＫフィードバックタイミングは、シンボル、ミニスロット、サブスロット、非スロットのタイミングなどに基づき得る。結果として、早期のＨＡＲＱフィードバックを提供することが可能なＷＴＲＵは、より高速の再送信を要求することができ、それによって、再送信遅延が低減する。
【０１８５】
一実施形態において、プリエンプション可能な領域を用いて半静的に構成されている高機能ＷＴＲＵ／ＷＴＲＵのグループは、スロット（例えば、シンボル、サブスロット、ミニスロット、非スロットなど）内でプリエンプション可能な領域内のリソースの復号を優先順位付けすることができる。例えば、スロット内の各ミニスロット、サブスロット、非スロットについて、ＷＴＲＵは、低遅延トラフィックをプリエンプトすることによって影響されている可能性があり得るＣＢＧを識別することができる。ＷＴＲＵはその後、ＣＢＧ内のＣＢを決定することができ、ＣＢＧの、プリエンプションによって影響されている可能性がある部分であるＣＢの復号に進む。ＷＴＲＵはその後、ＣＢＧ内の失敗したＣＢの数を決定することができる。この数が何らかの閾値を超える場合、ＷＴＲＵは、ＣＢＧを、復号不可能であり、失敗したと考える。１つもしくは複数のＣＢＧまたはＣＢＧの何らかの閾値が失敗したと考えられる場合、ＷＴＲＵは、例えば、ミニスロット／非スロット／サブスロットのタイミングに基づいて早期のＨＡＲＱフィードバックを開始することができる。早期のＨＡＲＱフィードバックは、単一ビットまたはマルチビットのＨＡＲＱフィードバックであってもよい。一例において、ＣＢＧに基づくマルチビットＨＡＲＱフィードバックを用いて構成されているＷＴＲＵは、失敗したＣＢＧの再送信を要求するために、ミニスロットのタイミングにおいてこれを利用することができる。例えば、ＴＢあたり８つのＣＢＧを用いて構成されているＷＴＲＵは、８ビットのマルチビットＨＡＲＱフィードバックを含むことができる。このＷＴＲＵは、これらのシンボルまたはミニスロット内のそれらのリソースの復号を優先順位付けするために、構成済みのプリエンプション可能な領域の知識を利用することができる。何らかの数（例えば、少なくとも１つのＣＢＧ）または閾値（例えば、構成済みＣＢＧのある割合または比）に基づいて、影響されており、失敗したと考えられ得るＣＢＧの数が相当であると考えられる場合、ＷＴＲＵは、これらの影響されている（否定応答されている）ＣＢＧを再送信するようにＢＳ（例えば、ｇＮＢ）に通知するために、マルチビットフィードバックを利用することができる。
【０１８６】
別の実施形態において、構成済みのプリエンプション可能な領域についてシンボルまたはミニスロット内のリソースの復号を優先順位付けするＷＴＲＵは、特定のＣＢＧとは対照的に、ＴＢ全体の（早期の）再送信を要求するために、早期のＨＡＲＱフィードバックを利用することができる。これは、相当数のＣＢＧが、プリエンプトしているトラフィックによって影響されるシナリオにおいて発生し得る。例えば、早期のＨＡＲＱフィードバックが、８つの可能な（または構成済み）ＣＢＧのうちの５つに基づき、これらの５つのＣＢＧのうちの４つが破損されているとＷＴＲＵが決定した場合、ＷＴＲＵは、ＢＳ（例えば、ｇＮＢ）が、選択されるＣＢＧとは対照的にＴＢ全体を再送信することを要求するマルチビット（８ビット）の全てのＮＡＣＫのフィードバックを送ることができる。
【０１８７】
また別の実施形態において、マルチビットＨＡＲＱフィードバックを用いて構成されているＷＴＲＵは、ＴＢに基づく単一ビットＨＡＲＱフィードバックの形態で、早期のＨＡＲＱフィードバックを提供することができる。例えば、ＣＢＧに基づく（再）送信のために構成されているＷＴＲＵは、ＣＢＧに基づく（再）送信をサポートしないが、ＴＢに基づく（再）送信をサポートするＤＣＩによってスケジューリングされているＰＤＳＣＨを有し、ＷＴＲＵは、ＴＢに基づく単一ビットＨＡＲＱフィードバックの形態で、早期のＨＡＲＱフィードバックを提供することができる。このために、ＢＳ（例えば、ｇＮＢ）は、例えば、ＣＢＧ送信インジケータ（ＣＢＧＴＩ）フィールドまたはＣＢＧ送信情報（ＣＢＧＴＩ）フィールドを含まないフォールバックＤＣＩを利用することができる。そのような事例において、たとえＷＴＲＵがＣＢＧに基づく（再）送信向けに構成されている場合であっても、フォールバックＤＣＩは、ＷＴＲＵがＴＢに基づく単一ビットＨＡＲＱフィードバックによって応答することの明示的な指標として機能することができる。そのようなシナリオにおいて、単一のＣＢＧがプリエンプトされているトラフィックによって影響される場合、ＷＴＲＵは再び、これらのシンボル／ミニスロット内のリソースの復号を優先順位付けするために、構成済みのプリエンプション可能な領域の知識を利用することができる。この事例において、影響されている可能性があるＣＢＧのいずれか（すなわち、少なくとも１つ）が、プリエンプトされているトラフィックに起因して復号されることが不可能である場合、ＷＴＲＵは、通常のＨＡＲＱタイムラインを待つ必要があるのとは対照的に、ミニスロットのタイミングにおいて、ＴＢに基づく単一ビットのＮＡＣＫ早期ＨＡＲＱフィードバックを提供することができ、結果として、ＢＳ（例えば、ｇＮＢ）によるＴＢ全体の再送信がより高速になる。上述されているように、フォールバックＤＣＩは、ＴＢに基づく単一ビットＨＡＲＱフィードバックのサポートを示すためのＣＢＧＴＩフィールドを含まない場合がある。周期的な（非フォールバック）ＤＣＩは、ＣＢＧに基づくマルチビットＨＡＲＱフィードバックのサポートを示すためのＣＢＧＴＩフィールドを含み得る。
【０１８８】
上述されているように、マルチビットＨＡＲＱフィードバックを用いて構成されているＷＴＲＵは、ＴＢに基づく単一ビットＨＡＲＱフィードバックによって応答することができる。このシナリオにおいて、ＷＴＲＵが、相当数の早期のＣＢＧがプリエンプトしているトラフィックによって影響されていることに気付いた場合、ＷＴＲＵは、ＴＢに基づく単一ビットの早期のＨＡＲＱ−ＮＡＣＦＫフィードバックメッセージを介して（特定のＣＢＧとは対照的に）ＴＢ全体の再送信を要求するのに最良の（すなわち、最も適切な）フィードバックフォーマットを選択する自律性を有することができる。ミニスロットのＨＡＲＱタイミングに基づく早期のＨＡＲＱフィードバックと、通常の（スロットに基づく）ＨＡＲＱタイミングに基づく通常のＨＡＲＱフィードバックの単一ビットＨＡＲＱフィードバックフォーマットとマルチビットＨＡＲＱフィードバックフォーマットとの間で自律的に切り替える柔軟性によって、ＷＴＲＵは、ＰＵＣＣＨリソースセット／フォーマット／リソースの間で切り替えることができるため、ＷＴＲＵは、ＰＵＣＣＨリソースを最適に使用することを可能にすることができる。この結果として、様々なＰＵＣＣＨリソースセット／リソースにわたって均等に分散させることができ（マルチビットＨＡＲＱフィードバック向けに構成されている全てのＷＴＲＵが、フィードバックのミニスロットのＨＡＲＱタイミングまたはフィードバックのスロットに基づくタイミングのみを排他的に利用する事例とは対照的に）、それによって、ＰＵＣＣＨが衝突する可能性が低減する。
【０１８９】
代替的にまたは付加的に、ＷＴＲＵの早期のＨＡＲＱフィードバックのための窓は、ＷＴＲＵに、早期のＨＡＲＱフィードバックを提供する複数の機会を提供することができる。ＨＡＲＱフィードバックを提供する各機会は、スケジューリングされているＰＤＳＣＨ送信スロット内のいくつかのシンボル／ミニスロット／サブスロット／非スロットの境界のうちの１つの上にあり得る。複数の早期のＨＡＲＱフィードバックの機会を提供することによって、結果として再送信遅延を低減する最適なＨＡＲＱ性能を可能にすることができる。早期のＨＡＲＱフィードバックの機会は、累積的なＨＡＲＱ−ＮＡＣＫフィードバックを提供するために利用され得る。それらは、ＰＤＳＣＨ送信の開始から現在の／最近復号されたＣＢＧ結果までの、全てのＣＢＧに対するＨＡＲＱ−ＮＡＣＫフィードバックを示すことができ、それによって、ＣＢＧあたり複数の可能なＨＡＲＱ−ＮＡＣＫを提供する。代替的にまたは付加的に、早期のＨＡＲＱフィードバックの機会は、最後の早期のＨＡＲＱフィードバックのミニスロット境界と、現在のＨＡＲＱフィードバックのミニスロット境界との間のＣＢＧに対するＨＡＲＱ−ＮＡＣＫフィードバックを提供するために利用され得、これは、ＣＢＧあたり単一のＨＡＲＱ−ＮＡＣＫフィードバックを暗示する。第１の（累積的な早期のフィードバックの）オプションは、オーバーヘッドが増大されることと引き換えに、より高い信頼性を提供することが可能であり得る。例えば、ＴＢあたり８つのＣＢＧを用いて構成されているＷＴＲＵは、２回の早期のＨＡＲＱ−ＮＡＣＫの機会を有することができる。第１の機会は、最初の２つのＣＢＧの復号結果に基づき得、第２の機会は、最初の５つのＣＢＧの復号結果に基づき得る。最初の２つのＣＢＧのうちの１つがプリエンプションに起因して破損される場合、ＷＴＲＵは、第２のＨＡＲＱフィードバックのミニスロット境界にある破損されているＣＢＧのＮＡＣＫを示すマルチビット（例えば、８ビット）ＨＡＲＱフィードバックメッセージによって応答することができる。ＷＴＲＵが、第１のＨＡＲＱＫフィードバックのミニスロット境界と第２のＨＡＲＱフィードバックのミニスロット境界との間で、追加の２つのＣＢＧ（３つのＣＢＧのうちの）が破損されていると認識した場合、ＷＴＲＵは、５つのＣＢＧのうち３つの破損されているＣＢＧのＮＡＣＫを示す別のマルチビットＨＡＲＱフィードバックメッセージによって応答することができる。２つのＨＡＲＱフィードバックメッセージが、破損されているＣＢＧに対して有効かつ累積的に提供されているため、この累積的な早期のフィードバックは、最初の２つのＣＢＧの信頼性を改善することができる。これは、結果として再送信遅延が増大されることになり得るＮＡＣＫ−ＡＣＫの誤り、または、結果として不要な再送信をもたらし得るＡＣＫ−ＮＡＣＫの誤りの可能性を低減することができる。
【０１９０】
加えて、早期のＨＡＲＱフィードバックレポートをＢＳ（例えば、ｇＮＢ）に送信することができるＷＴＲＵは、スロットに基づくＨＡＲＱフィードバックのレポートの送信が、再送信がすでに要求されているために不要であると考えられ得るときには、これを控えることができる。これは、ＷＴＲＵが早期のＨＡＲＱフィードバックを利用する複数の機会を有しており、実際に、特定のＣＢＧおよび／またはＴＢ全体の再送信を要求するためにこれらの機会を利用している事例に特に関連し得る。通常のＨＡＲＱフィードバック応答を控えることは、複数のＷＴＲＵの間で、早期のＨＡＲＱと通常のスロットに基づくＨＡＲＱの両方のフィードバックを提供するために利用されるＰＵＣＣＨリソースのセット（例えば、リソースブロック）の重なりがある場合に、特に関連し得る。これは、ＰＵＣＣＨリソースの不要な使用の可能性および異なるＷＴＲＵの間の可能性のある衝突を低減するのを助けることができる。
【０１９１】
加えて、早期のＨＡＲＱフィードバックが利用されようとしているために、通常のＨＡＲＱフィードバックが必要ないことをＷＴＲＵが知っている場合、それは、ＰＵＣＣＨリソース／ＰＵＣＣＨ送信持続時間に関する可能性のある制約およびＷＴＲＵ間の衝突の可能性、並びに、信頼できるＰＵＣＣＨ性能を保証するために必要とされ得るＰＵＣＣＨリソースの全体的な数を低減することができる。
【０１９２】
図１０は、本明細書において説明されている他の実施形態の任意の組み合わせにおいて使用されてもよい、ミニスロットのタイミングによるスロット内の例示的な早期のＨＡＲＱフィードバックのタイミング１０００を示す。図１０に示されているように、ＴＢ（またはスロット）１００１は、低遅延トラフィックのためのＣＢＧ２  １０２０、ＣＢＧ４  １０３０、およびＣＢＧｎ−１  １０３４を含むプリエンプション領域１００５を有して構成され得る。プリエンプション領域１００１内のＣＢＧの間で、ＣＢＧ２  １０２０およびＣＢＧ４  １０３０のいくつかの部分１０１０は、低遅延トラフィックに対応するためにプリエンプトされ（すなわち、低遅延トラフィックによってプリエンプトされ）得る。ＷＴＲＵは、複数の（この事例においては２回の）早期のＨＡＲＱフィードバックの機会（すなわち、早期のＨＡＲＱ１  １０４０および早期のＨＡＲＱ２  １０４５）を有する。第１の早期のＨＡＲＱの機会（すなわち、早期のＨＡＲＱ１  １０４０）について、ＷＴＲＵが、第１の２つのＣＢＧ（すなわち、ＣＢＧ１  １０１５およびＣＢＧ２  １０２０）のいずれかがプリエンプトしている低遅延トラフィックによって影響されているか否かを決定した後、ＷＴＲＵは、早期のＨＡＲＱ−ＮＡＣＫ応答を、早期のＨＡＲＱ１ミニスロットタイミング１０４０において送信すべきか否かを決定することができる。第２の早期のＨＡＲＱの機会（すなわち、早期のＨＡＲＱ２  １０４５）について、ＷＴＲＵが、第２の２つのＣＢＧ（すなわち、ＣＢＧ３  １０２５およびＣＢＧ４  １０３０）のいずれかがプリエンプトしている低遅延トラフィックによって影響されているか否か、または、累積的なＣＢＧ（すなわち、ＣＢＧ１  １０１５、ＣＢＧ２  １０２０、ＣＢＧ３  １０２５、およびＣＢＧ４  １０３０）のいずれかがプリエンプトしている低遅延トラフィックによって影響されているか否かを決定した後、ＷＴＲＵは、その後、上述されているように、ＣＢＧ３およびＣＢＧ４  １０２５、１０３０に対してのみ、または、ＣＢＧ１〜４  １０１５、１０２０、１０２５、１０３０（累積的）に対して、早期のＨＡＲＱ２ミニスロットタイミング１０４５において、早期のＨＡＲＱ−ＮＡＣＫ応答を提供すべきかを判断することができる。ＷＴＲＵが、早期のＨＡＲＱ１ミニスロットタイミング１０４０または早期のＨＡＲＱ２ミニスロットタイミング１０４５のいずれにおいても早期のＨＡＲＱフィードバックを送信しないことを選択した場合、ＷＴＲＵは、全てのＣＢＧ（すなわち、ＣＢＧ１  １０１５、ＣＢＧ２  １０２０、ＣＢＧ３  １０２５、ＣＢＧ４  １０３０．．．ＣＢＧｎ−１  １０３４、およびＣＢＧｎ  １０３５）について、通常のＨＡＲＱタイミング１０５０において通常のＨＡＲＱフィードバック１０５０を送信することができる。
【０１９３】
図１１は、本明細書において説明されている他の実施形態の任意の組み合わせにおいて使用されてもよい、ミニスロットのタイミングによるスロット内での早期のＨＡＲＱフィードバックを決定するための例示的な手順１１００を示す。図１１に示されているように、ＷＴＲＵは、スロット内のプリエンプション領域リソースの優先順位付けされている復号に基づいて、早期のＨＡＲＱ  ＮＡＣＫフィードバックを提供すべきか否かを決定することができる。例えば、ステップ１１０５において、ＷＴＲＵは、上述されているように、低遅延トラフィックのためのプリエンプション領域を用いて構成され得る。ステップ１１１０において、ＷＴＲＵは、スロット内でプリエンプション領域内のリソースの復号を優先順位付けすることができる。ステップ１１１５において、ＷＴＲＵは、各ミニスロットについて低遅延トラフィックによって影響される可能性があるＣＢＧを識別することができる。ステップ１１２０において、ＷＴＲＵは、識別されているＣＢＧ内の影響されている可能性があるＣＢを復号するように試行することができる。ステップ１１２５において、識別されているＣＢＧ内のＣＢの数が予め定められた閾値よりも大きい場合、ＷＴＲＵは、ステップ１１３０において、各ミニスロットについて、失敗した（または破損されている）ＣＢを含むＣＢＧをさらに識別することができる。ＷＴＲＵはその後、ステップ１１３５において、ミニスロットに基づくＨＡＲＱタイミングに従って、スロット内で早期のＨＡＲＱフィードバックを生成することができる。一方、ステップ１１２５において、識別されているＣＢＧ内のＣＢの数が予め定められた閾値よりも小さい場合、ＷＴＲＵは、ステップ１１４０において、スロットに基づくＨＡＲＱタイミングに従って通常のＨＡＲＱフィードバックを生成することができる。予め定められた閾値は、ＢＳからのブロードキャストメッセージまたはＲＲＣメッセージを介して受信され得る。予め定められた閾値はまた、ＷＴＲＵのメモリ内で予め構成されてもよい。
【０１９４】
一実施形態において、早期のＨＡＲＱフィードバックは、ｅＭＢＢデータが低遅延データによってプリエンプトされるときに、再送信遅延を低減するために使用される。ＷＴＲＵが、プリエンプション領域内のＣＢＧの過度に多いＣＢを復号するのに失敗するとき、早期のＨＡＲＱフィードバックは、ミニスロットＨＡＲＱタイミングに従って送信され得る。例えば、ＷＴＲＵは最初に、構成済みプリエンプションリソースにおけるＰＤＳＣＨ送信の１つまたは複数のＣＢＧ（すなわち、プリエンプション可能なＣＢＧ）内のＣＢの復号を優先順位付けすることができ、ここで、ＣＢＧはＣＢのセットを含むことができる。ＷＴＲＵは、その後、ＰＤＳＣＨトランスポートブロック（ＴＢ）の送信において１つまたは複数のプリエンプション可能なＣＢＧを決定することができる。決定されている１つまたは複数のプリエンプション可能なＣＢＧのうちのプリエンプション可能なＣＢＧについて、ＷＴＲＵは、対応するＣＢのうちの１つまたは複数を受信し、これを復号するように試行することができる。ＷＴＲＵは、復号が失敗されたプリエンプション可能なＣＢＧ内のＣＢの数を決定することができる。ＷＴＲＵは、プリエンプション可能なＣＢＧ内の失敗したＣＢの数が予め定められた閾値を超えるときに、ミニスロットのＨＡＲＱタイミングに基づいて早期のＨＡＲＱフィードバックを送信することができる。代替的にまたは付加的に、ＷＴＲＵは、スロット内のプリエンプション可能なＣＢＧの各々のうちの失敗したＣＢの数が予め定められた閾値以下であるときに、スロットに基づくＨＡＲＱタイミングに基づいて周期的なＨＡＲＱフィードバックを送信することができる。
【０１９５】
別の実施形態において、指定されているプリエンプション領域に関する情報を用いてＷＴＲＵを（例えば、ＲＲＣシグナリングを介して）半静的に構成することに加えて、ＢＳ（例えば、ｇＮＢ）は、動的なシグナリングを介して、影響される時間／周波数リソースの位置を明示的に示すことができる。ＷＴＲＵが、影響されるＣＢ／ＣＢＧ／ＴＢの復号を助けるために利用することができるように、これは、ＷＴＲＵに、影響される時間または周波数リソースの明示的な位置を提供することができる。例えば、黙示的な指標の事例と同様に、ＷＴＲＵは、最初に、示されている／影響されているＰＲＢ内のＣＢを復号するように試行することができる。ＷＴＲＵはその後、この復号の結果に基づいて、ＨＡＲＱフィードバックを送ることができ、早期の再送信が可能になる。この明示的な指標は、より大きいシグナリングオーバーヘッドを有し得るが、黙示的な指標の事例からの差異は、影響されるリソースに関するより正確な情報が提供されることである。
【０１９６】
ＢＳ（例えば、ｇＮＢ）は、ＷＴＲＵまたはＷＴＲＵのグループに、ＷＴＲＵが早期のＨＡＲＱフィードバックメッセージを送るための、追加のタイミングおよび／またはリソース位置情報を動的に提供することができる。この情報は、プリエンプション指標シグナリングの一部として提供され得る。ＷＴＲＵは、影響されるリソースの位置（時間および／または周波数的な）に基づいて早期のＨＡＲＱフィードバックメッセージを送ることを選択することができる。例えば、プリエンプトされているリソースの位置は、最初の数シンボルのうちの１つのような、スケジューリングされているスロット内の早期に生じ得る。ＷＴＲＵは、低遅延トラフィックに対応するために利用される可能性が高い周波数リソースの位置に関する情報を有することができる。そのようなシナリオにおいて、ＷＴＲＵは、これらのシンボルにおける周波数リソースの復号結果に基づいて、早期のＨＡＲＱフィードバックを提供することができる。代替的にまたは付加的に、ＷＴＲＵは、プリエンプトされているリソースの位置が、ＷＴＲＵ処理時間に適切でない制約を課す場合、例えば、プリエンプションが、スケジューリングスロットの端部に向かうところにあるシンボル／シンボルのグループに影響を与える場合、早期のＨＡＲＱフィードバックメッセージを提供しないと判断することができる。
【０１９７】
別の実施形態において、ＷＴＲＵは、早期のＨＡＲＱフィードバックを提供する目的で特定的に利用されることになるＰＵＣＣＨリソースのセットを用いて半静的に予め構成され得る。ＰＵＣＣＨリソースのセットは、通常の（スロットに基づく）ＨＡＲＱフィードバック向けに予め構成されているリソースセットに共通のリソースを含むことができる。代替的にまたは付加的に、これらのリソースは、通常のスロットに基づくＨＡＲＱタイミングに基づく通常のＨＡＲＱフィードバックに利用される他のＰＵＣＣＨリソースセットとは別個のものであってもよい。
【０１９８】
選択されているＰＵＣＣＨフォーマットが、適度なＵＣＩ（ＨＡＲＱ）ペイロードを含むことができ、複数の／いくつかのシンボル／ミニスロット／サブスロットにわたって送信される場合（例えば、単一のリソース−ブロック対にわたる長い持続時間（ＰＵＣＣＨフォーマット４）にわたるＰＵＣＣＨ）、ＰＵＣＣＨリソースセットを効率的に活用するために、複数のＷＴＲＵが同じリソース−ブロック対を共有することができる。シンボル／ミニスロット内で同じリソース−ブロック対を共有するデバイスは、周波数領域シーケンスの異なる直交位相回転（例えば、時間領域におけるサイクリックシフト）によって分離され得る。代替的にまたは付加的に、複数のリソース−ブロック対が使用される、より大きい（例えば、２ビットよりも大きい）ＵＣＩペイロードフォーマット（例えば、ＰＵＣＣＨフォーマット２または３）について、シンボル／ミニスロット／非スロットの多重化容量は、複数のＷＴＲＵに同じリソース−ブロック対を共有させることによって増大され得、ここで、各ＷＴＲＵは、異なる直交カバーシーケンスを使用し、それによって、早期のＨＡＲＱフィードバックに必要とされ得るＰＵＣＣＨリソースの数が低減する。
【０１９９】
積極的なＨＡＲＱ処理が可能な高機能ＷＴＲＵの数は、サービスされる全ＷＴＲＵのうちの小さい比であり得るため、これらのリソースは制限され得、場合によって、ＷＴＲＵまたは高機能ＷＴＲＵのグループの間で共有され得る。ＢＳ（例えば、ｇＮＢ）は、いずれの割合のＷＴＲＵが高機能ＷＴＲＵであるかを決定するために、ＷＴＲＵから受信されたＨＡＲＱフィードバックデータを利用することができる。ＢＳはまた、いずれの比のこれらのＷＴＲＵが実際に早期のＨＡＲＱ−ＮＡＣＫフィードバックを送信しているかを決定することもできる。ＢＳ（例えば、ｇＮＢ）はその後、リソース使用を最適化するために、ＰＵＣＣＨリソースセットを半静的に再構成するために、このデータを利用することができる。
【０２００】
早期のＨＡＲＱフィードバックは、単一ビットまたはマルチビットのＨＡＲＱフィードバック（上述されているような）であり得るため、ＷＴＲＵは、ＢＳ（例えば、ｇＮＢ）に早期のＨＡＲＱフィードバックを提供するために、２つ以上のＰＵＣＣＨリソースセット／フォーマットを半静的に予め構成され得る。これらのＰＵＣＣＨリソースセットは、ペイロードサイズに基づいて、通常のスロットに基づくＨＡＲＱペイロードサイズとして区別され得る。
【０２０１】
別の実施形態にて、ＷＴＲＵは、スロットに基づくＨＡＲＱフィードバックに対して定義されている同じＰＵＣＣＨリソース（リソースブロック）を利用することができる。
【０２０２】
上記の実施形態のいずれかにおいて、ＷＴＲＵは、早期のＨＡＲＱフィードバックリソースを提供するために必要とされるリソースが、時間／周波数領域においてスロットに基づくＨＡＲＱフィードバックを提供するために利用されるリソースと競合する場合があるという事実を考慮に入れる必要があり得る。例えば、早期のＨＡＲＱがスロット内のシンボル／ミニスロットの特定のセットにわたるリソース（リソースブロック）を利用する場合、これらの送信は重なり合い、それゆえ、スロットに基づくＨＡＲＱフィードバックの送信窓に影響する場合がある。代替的にまたは付加的に、高機能ＷＴＲＵ（例えば、早期のＨＡＲＱフィードバックが可能）およびベースライン機能ＷＴＲＵ（すなわち、通常のＨＡＲＱフィードバックのみが可能）に対応する必要があることによって、ＰＵＣＣＨ使用を制限するために、様々なＷＴＲＵの間でＰＵＣＣＨリソースを共有する必要があり得る。しかしながら、これによって、ＷＴＲＵ間の衝突の可能性が増大し得る。
【０２０３】
衝突の可能性を回避する単純な方法は、早期のＨＡＲＱフィードバックが送信されていることを受けて、通常のＨＡＲＱ送信を控えることである。上記で開示されているように、これは、全体的な再送信の信頼性を損なうことなく、また、異なるＷＴＲＵのＰＵＣＣＨ送信の間で衝突する可能性なしに、早期のＨＡＲＱフィードバックに対する任意の制約を低減することができる。
【０２０４】
ＷＴＲＵは、高信頼性用途に関連する早期のＨＡＲＱフィードバックと通常のＨＡＲＱフィードバックの両方を送信する必要があり得る。早期のＨＡＲＱ（ミニスロットタイミングに基づく）フィードバックが通常のＨＡＲＱフィードバックに影響しないことを保証するために、ＷＴＲＵは、早期のＨＡＲＱフィードバックを短い持続時間のＰＵＣＣＨ送信に制限することができ、それによって、スロットに基づくＨＡＲＱフィードバックの送信窓の前に、早期のＨＡＲＱフィードバック送信が終了することを保証する。短い持続時間のＰＵＣＣＨ送信を利用することは、任意の所与の時点において、システム内の全ＷＴＲＵのうちの小さい割合のみが制限された電力または制限されたカバレッジを有し、ほとんどのＷＴＲＵは長い持続時間のＰＵＣＣＨ送信を必要としないと仮定され得るため、それが、ＨＡＲＱフィードバックの信頼性に悪影響を与え得ないという点において、許容可能であり得る。
【０２０５】
別の実施形態において、ＷＴＲＵは、スロット内の利用可能な早期のＨＡＲＱフィードバックの送信機会の数に関して制約され得る。例えば、図１０において、２回の早期のＨＡＲＱフィードバックの送信機会（早期のＨＡＲＱ１  １０４０および早期のＨＡＲＱ２  １０４５）の代わりに、ＷＴＲＵは、単一の早期のＨＡＲＱフィードバック機会（すなわち、早期のＨＡＲＱ１  １０４０）に制限され得る。この制約は、ＨＡＲＱフィードバックに対して短いまたは長いＰＵＣＣＨ送信が構成／利用されるかに基づき得る。例えば、ＷＴＲＵが、ＨＡＲＱフィードバックに対して長い持続時間のＰＵＣＣＨ送信を利用する必要がある場合、それは、早期のＨＡＲＱ１  １０４０が早期のＨＡＲＱフィードバックの唯一の機会を提供すると決定することができる。他方、ＷＴＲＵが、短い持続時間のＰＵＣＣＨ送信を利用する必要がある場合、いずれも通常の（スロットに基づく）ＨＡＲＱ送信１０５０と干渉し得ないため、それは、両方のＨＡＲＱフィードバック機会（すなわち、早期のＨＡＲＱ１  １０４０および早期のＨＡＲＱ２  １０４５）を提供するのに満足なものであり得る。
【０２０６】
別の実施形態において、ＷＴＲＵは、異なるアンテナ上で異なるリソース（時間および周波数リソースに加えて、コード領域も利用する）を使用することによって、空間的に直行するリソース送信ダイバーシティ（例えば、ＬＴＥにおける）と同様である送信ダイバーシティを利用することができる。これは、異なるアンテナからのＰＵＣＣＨ送信が、基本的に、（ＰＵＣＣＨリソースの量が２倍になることと引き換えに）２つの異なるＷＴＲＵからの２つのＰＵＣＣＨ送信に見えることを可能にすることができる。これは、早期および通常のＨＡＲＱフィードバックに対して同じＰＵＣＣＨリソースを使用する代わりに、ＷＴＲＵが、２つのＨＡＲＱフィードバック送信を分離するために、コード領域（例えば、各アンテナ上で異なるコード）を利用することができることを意味する。これは実効的に、早期のＨＡＲＱフィードバックと通常のＨＡＲＱフィードバックの両方の送信を可能にすることができる。
【０２０７】
別の実施形態において、低遅延トラフィック（例えば、ＵＲＬＬＣ）がｅＭＢＢ  ＷＴＲＵリソースをプリエンプトする場合、ＢＳ（例えば、ｇＮＢ）は、プリエンプトされているリソースの明示的な指標を送るのに加えて、たとえそれがＷＴＲＵからＨＡＲＱフィードバックを受信する前であっても、影響されるＣＢ／ＣＢＧを自動的に再送信する（またはその後続の送信を実施する）と判断することができる。後続の送信の存在は、１ビットのフラグを介してＷＴＲＵまたは影響されるＷＴＲＵのセットに示され得、明示的な指標の信号とともにＷＴＲＵに送られ得る。
【０２０８】
初期送信が失敗した場合に影響されるＣＢを復号するためにＷＴＲＵが使用することができるフォローアップ送信を知っているため、ＷＴＲＵはその後、いかなるＨＡＲＱフィードバックも提供しないことによって、このフラグを使用することができる。そのようなメカニズムは、追加の送信リソースを使用することと引き換えに、遅延を改善しながらシグナリングオーバーヘッドを低減するという二重の利益を有することができる。
【０２０９】
別の実施形態において、ＷＴＲＵが、元々スケジューリングされているリソースがプリエンプトされているか否かに関する情報を有しない可能性がある。これは以下の場合に当てはまり得る。（ｉ）予め定められたプリエンプション可能な領域に関する、半静的に構成されている情報がない。（ｉｉ）ダウンリンク制御情報（ＤＣＩ）を介して受信されるプリエンプションリソースの動的な指標が、ＡＣＫ／ＮＡＣＫフィードバックの前に到達することに失敗する。または、（ｉｉｉ）開始するためのプリエンプトされているリソースの明示的な指標がない。そのような事例において、ＷＴＲＵは、先行するスロット／ミニスロット内で送信されるように元々スケジューリングされていたＴＢの任意のＣＢ／ＣＢＧが、ここで、後続の送信としてスケジューリングされているか否かを確認するために、後続のスケジューリング割り当て（例えば、後続のスロット）をモニタリングすることができる。
【０２１０】
ＢＳ（例えば、ｇＮＢ）は、ＷＴＲＵに、低遅延トラフィックをプリエンプトすることによって影響されるリソース、および、従ってＣＢ／ＣＢＧを通知するために、プリエンプション指標を送信することができる。このプリエンプション指標および結果としての再送信は、影響されるＣＢＧをハンドリングし、ＴＢを復号する方法を決定するときに、ＷＴＲＵを助けることができる。
【０２１１】
一実施形態において、ＷＴＲＵは、全ての影響されているＣＢＧまたは影響されているＣＢＧのサブセットに関係付けられるソフトバッファ内容をフラッシュし、これらの影響されているＣＢＧの再送信を復号に利用すると判断することができる。ＣＢＧの全ての関係付けられる内容をフラッシュアウトするこの手法は、影響されているＣＢＧ内の相当数のＣＢがプリエンプションに起因して破損されている場合に特に有益であり得る。この事例において、信頼性を著しく欠く初期送信とは対照的に、将来の再送信にわたるＨＡＲＱ合成を利用することが最良であり得る。
【０２１２】
別の実施形態において、ＷＴＲＵは、ＣＢＧ全体とは対照的に、ＣＢＧの影響されているセット内のＣＢのサブセットに関係付けられるソフトバッファ内容をフラッシュすると判断することができる。そのようなシナリオ下では、ＷＴＲＵは、復号成功を改善するための手段として、再送信が初期送信と同じ増分冗長（ＩＲ）に基づく場合にはチェース合成を利用することができ、または、フラッシュされなかったソフトバッファ内のＣＢの再送信に異なる冗長バージョン（ＲＶ）が利用される場合には増分冗長ＨＡＲＱを利用することができる。ＷＴＲＵは、ＣＢＧ内のいずれのＣＢがフラッシュされる必要があるかを判断するための方法として、ＣＢレベルのＣＲＣ検査を利用することができる。この手法は、ＣＢＧ内の少数のＣＢがプリエンプションに起因して破損されている場合に特に有益であり得る。
【０２１３】
ＣＢＧに基づく送信のタイミングは、ＷＴＲＵのＨＡＲＱフィードバックに影響し得る。ＢＳ（例えば、ｇＮＢ）は、プリエンプトされている低遅延トラフィックによって影響されているＴＢのＣＢＧに基づく再送信をスケジューリングすることができる。このＢＳ（例えば、ｇＮＢ）は、この再送信を、積極的に（すなわち、ＷＴＲＵからＨＡＲＱフィードバックを受信する前に）、または、ＷＴＲＵによって提供される結果としてのＨＡＲＱ  ＡＣＫ−ＮＡＣＫフィードバックに基づいて開始することができる。
【０２１４】
一実施形態において、ＢＳ（例えば、ｇＮＢ）は、プリエンプションによって影響されているＣＢＧを、積極的に、例えば、ＷＴＲＵからの結果としてのＨＡＲＱ応答を待つことなく再送信すると判断することができる。これは、影響されているリソース、および、従って、影響されているＣＢＧの数などに基づく何らかの推定される復号失敗の確率に基づいて行われてもよい。積極的なまたは後続の送信の事例において、ＢＳ（例えば、ｇＮＢ）は、ＷＴＲＵが利用する必要があるＨＡＲＱフィードバックのためのタイミングおよびリソースをＷＴＲＵに示すことができる。
【０２１５】
そのようなシナリオの下で、ＷＴＲＵは、２つの別個のＨＡＲＱフィードバックメッセージによって応答すると判断することができる。第１のＨＡＲＱメッセージは、元々のＰＤＳＣＨ（ＴＢ）送信タイミングに基づき得、第２のＨＡＲＱメッセージは、後続の送信によって提供される新たな／更新されたリソース／タイミング情報に基づき得る。ＷＴＲＵは、初期送信と、第２のＨＡＲＱメッセージのための後続の送信とのＨＡＲＱ合成を利用することができる。代替的にまたは付加的に、２つのＨＡＲＱメッセージは、フィードバックフォーマットの粒度（例えばマルチビット対単一ビット）などに関して異なり得る。例えば、プリエンプションを伴う初期送信の結果として、いくつかのＣＢＧが不正確に復号される場合、ＷＴＲＵは、いずれのＣＢＧが再送信される必要があるかをＢＳ（例えば、ｇＮＢ）に通知するために、ＣＢＧに基づくマルチビットＨＡＲＱフィードバックを提供することができる。初期送信と後続の送信とのＨＡＲＱ合成が、依然として、誤りのあるいくつかのＣＢＧをもたらすか、または、ＴＢ全体が首尾よく復号されるようにする場合、ＷＴＲＵは、これらの事例のいずれかについて単一ビットＨＡＲＱフィードバックメッセージを提供すると判断することができる。これは、ＢＳ（例えば、ｇＮＢ）が次の再送信においてＴＢ全体を再送信すべきであることの黙示的な指標として解釈され得る。
【０２１６】
代替的にまたは付加的に、初期送信と後続の送信の両方が、結果として、誤りのある少数のＣＢＧをもたらす場合、周波数スペクトル効率の観点から、ＢＳ（例えば、ｇＮＢ）が、結果としてＴＢ全体が再送信されるようにする単一ビットのフィードバックとは対照的に、ＷＴＲＵによって要求されるＣＢＧを再送信することができるように、ＢＳ（例えば、ｇＮＢ）に、ＣＢＧに基づくＨＡＲＱフィードバックを提供することがより効率的であり得る。
【０２１７】
各メッセージについて最良のフィードバックオプションを選択するためのＷＴＲＵの柔軟性は、スペクトル効率に関して最良の性能を提供しながら、ＵＣＩオーバーヘッドを低減するのを助けることができる。代替的にまたは付加的に、２つのＨＡＲＱフィードバックメッセージを使用する結果としてまた、ＡＣＫ−ＮＡＣＫメッセージのロバスト性も改善され得る。
【０２１８】
異なるＰＵＣＣＨフォーマットを用いてＷＴＲＵを構成することによって、ＨＡＲＱフィードバックオプション間での切り替えが容易にされ得る。ＢＳ（例えば、ｇＮＢ）はその後、フィードバックメッセージの粒度を確認するために、ＰＵＣＣＨをブラインド復号することができる。一実施形態において、ＷＴＲＵは、ＢＳ（例えば、ｇＮＢ）による後続の再送信手順が、２つの送信のＨＡＲＱ合成の結果に基づくときに、単一のＨＡＲＱフィードバック応答によって応答するように構成され得る。これは、明示的または黙示的のいずれかで構成され得る。例えば、ＢＳ（例えば、ｇＮＢ）による後続の送信の指標は、単一のＨＡＲＱ応答を送るための信号として解釈され得る。ＷＴＲＵはその後、２つの送信のＨＡＲＱ合成の結果に基づいて、単一のＨＡＲＱ応答を送ることができる。応答のタイミングは、ＷＴＲＵに適切な処理時間を提供するために、新たに示されたタイミング／リソースに基づくことができる。代替的にまたは付加的に、ＷＴＲＵは、この単一のＨＡＲＱフィードバック応答のためのフォーマット（例えば、単一ビット対マルチビット）を自律的に判断することができる。例えば、少数のＣＢＧのみに誤りがある場合、ＣＢＧに基づくマルチビットＨＡＲＱフィードバックによって応答することがより良好であり得る。一方、相当数のＣＢＧに誤りがあるままである場合、ＷＴＲＵは、ＢＳ（例えば、ｇＮＢ）がＴＢ全体を再送信する必要があることを示す、単一ビットのＮＡＣＫによって応答することができる。単一のＨＡＲＱフィードバックメッセージによる応答はまた、フィードバックオーバーヘッドの節約をももたらすことができる。例えば、後続の送信の結果として、任意の以前に破損されたＣＢＧが首尾よく受信される場合、単一のＨＡＲＱメッセージを送るのを待っているＷＴＲＵは、この時点でＴＢ全体が受信されていることを知らせる単一ビットのＡＣＫを送信することができる。対照的に、２つのＨＡＲＱフィードバックメッセージによるＨＡＲＱに基づく再送信または後続の送信に依拠することは、結果として、少なくとも１つのマルチビットＨＡＲＱメッセージ、および、それに続く、別のマルチビットまたは単一ビットのＨＡＲＱメッセージをもたらし得る。上記で言及されている手順は、ＢＳ（例えば、ｇＮＢ）がプリエンプション後に複数の後続の送信をスケジューリングする事例に拡張され得る。代替的にまたは付加的に、ＢＳ（例えば、ｇＮＢ）が、ＷＴＲＵによって提供されるＨＡＲＱフィードバックに基づいてＣＢＧ再送信をスケジューリングした場合、ＷＴＲＵは、単純に、元々のＴＢ送信と関連付けられるタイミングに従うことができる。
【０２１９】
代替的にまたは付加的に、ＷＴＲＵのＨＡＲＱ処理機能は、ＨＡＲＱ処理およびフィードバック応答時間に影響し得る。例において、高機能ＷＴＲＵが元々の送信、および、それに続く、後続の送信を受信する場合、ＷＴＲＵは、元々の送信に対して、（ミニスロットタイミングに基づく）早期のＨＡＲＱフィードバックおよび／または（スロットに基づく）通常のＨＡＲＱフィードバックを利用することができる。ＷＴＲＵはその後、（元々の送信とのＨＡＲＱ合成の後）後続の送信に同じことを実施することができる。これは、ＨＡＲＱ信頼性を改善するための方法として利用され得る。
【０２２０】
別の実施形態において、ＷＴＲＵは、初期送信に対して、スロットに基づくＨＡＲＱ応答によってのみ応答することができ、それに続いて、元々の送信とのＨＡＲＱ合成後の後続の送信に対して、（ミニスロットに基づく）早期のＨＡＲＱフィードバックおよび／または（スロットに基づく）通常のＨＡＲＱフィードバックの組み合わせによって応答することができる。
【０２２１】
別の実施形態において、ＷＴＲＵは、初期送信に対してＨＡＲＱ応答を送るのを控え、ＨＡＲＱフィードバック応答を送る前に、後続の再送信を待つことができる。結果としてのＨＡＲＱフィードバック応答は、初期送信と、後続の送信とのＨＡＲＱ合成に基づくことができ、早期のＨＡＲＱフィードバックおよび／または通常のＨＡＲＱフィードバックを含むことができる。
【０２２２】
上記の例における後続の送信の送信中に生成される早期のＨＡＲＱフィードバックは、初期送信（すでに受信されている）のＨＡＲＱ合成結果に基づくことができ、ここで、ＣＢＧは後続の送信の初期シンボル／ミニスロット内で受信される。図１０において、２つの連続する（ＴＢ／スロット１００１）送信（ＴＢ／スロットの第２の送信は図１０には示されていない）を考慮すると、早期のＨＡＲＱミニスロットタイミングの機会は、第２のスロットの（後続の送信）のシンボル／ミニスロット／非スロット内で生じ得る。この事例について、ＷＴＲＵは、後続の送信がＢＳ（例えば、ｇＮＢ）によってスケジューリングされ得るか否かの決定において、プリエンプション指標（グループ共通のＰＤＣＣＨを介した）およびＣＧＢフラッシュアウト指標（ＣＢＧＦＩ）情報を利用することができる。これは、ＨＡＲＱ応答によって応答する前にこの後続の送信の受信を待つ代わりに、初期送信に基づいてＨＡＲＱフィードバック応答をスキップすることを正当化することができる。
【０２２３】
初期および／または後続の送信に対する早期および／または通常のＨＡＲＱフィードバック応答の粒度（例えば、単一ビット対マルチビット）およびフォーマットは、上述されている手順に従うことができる。
【０２２４】
特徴および要素が特定の組み合わせにおいて上述されているが、各特徴および要素は単独で、または他の特徴および要素との任意の組み合わせにおいて使用されることができることを、当業者には諒解されよう。本明細書に記載の方法は、コンピュータまたはプロセッサによる実行のために、コンピュータ可読媒体内に組み込まれるコンピュータプログラム、ソフトウェア、またはファームウェア内で実施されることができる。コンピュータ可読媒体の例は、電子信号（有線または無線接続にわたって送信される）およびコンピュータ可読記憶媒体を含むことができる。コンピュータ可読記憶媒体の例は、限定ではないが、ＲＯＭ、ＲＡＭ、レジスタ、キャッシュメモリ、半導体メモリデバイス、内部ハードディスクおよび取り外し可能ディスクなどの磁気媒体、磁気光媒体、並びにＣＤ−ＲＯＭディスクおよびＤＶＤなどの光媒体を含む。ソフトウェアに関連するプロセッサは、ＷＴＲＵ、ＵＥ、端末、基地局、ＲＮＣ、または任意のホストコンピュータにおいて使用するための無線周波数送受信機を実施するために使用されることができる。
【図１Ａ】
0006835984.tif 000003
【図１Ｂ】
0006835984.tif 000004
【図１Ｃ】
0006835984.tif 000005
【図１Ｄ】
0006835984.tif 000006
【図２】
0006835984.tif 000007
【図３】
0006835984.tif 000008
【図４Ａ】
0006835984.tif 000009
【図４Ｂ】
0006835984.tif 000010
【図４Ｃ】
0006835984.tif 000011
【図５】
0006835984.tif 000012
【図６】
0006835984.tif 000013
【図７】
0006835984.tif 000014
【図８】
0006835984.tif 000015
【図９】
0006835984.tif 000016
【図１０】
0006835984.tif 000017
【図１１】
0006835984.tif 000018