JP2021533653A - Ｈａｒｑ拡張のための方法および装置 - Google Patents

Abstract

無線通信におけるハイブリッド自動再送要求（ＨＡＲＱ）拡張のための方法、装置、およびシステムが開示される。代表的な一実施形態において、無線通信のために無線送受信ユニット（ＷＴＲＵ）において実装される方法は、第１の表示に基づいて、コードブックプロセスのセットからコードブックプロセスを識別するステップと、ハイブリッド自動再送要求（ＨＡＲＱ）フィードバックのビットのセットを、識別されたコードブックプロセスに関連付けるステップと、条件に基づいて、識別されたコードブックプロセスに関連付けられたビットのセットを維持するステップと、識別されたコードブックプロセスに関連付けられたビットのセットを送信するための第２の表示を受信するステップと、第２の表示に基づいて、ビットのセットを送信するステップとを含む。

Description

関連出願の相互参照
本出願は、2018年8月7日に出願された米国特許仮出願第62/715,458号明細書、および2019年1月4日に出願された米国特許仮出願第62/788,424号明細書の利益を主張し、その内容は、全ての目的のために、そのそれぞれの全体において本明細書に完全に明記されるかのように、参照により本明細書に組み込まれる。

モバイル通信は進化し続けている。新無線（ＮＲ）と称される高度な無線通信システムを実装することができる第５世代は、５Ｇと呼ばれ得る。本明細書で開示される実施形態は、一般に、無線および／または有線である通信ネットワークに関する。例えば、本明細書で開示される１つまたは複数の実施形態は、無線通信におけるハイブリッド自動再送要求（ＨＡＲＱ）拡張のための方法および装置に関係付けられる。

RP-172021、「Revised SID on NR-based Access to Unlicensed Spectrum」、TSG RAN #77 3GPP TS 38.213、「Physical layer procedures」、v15.0.0 3GPP TR 36.889、「Feasibility Study in Licensed-Assisted Access to Unlicensed Spectrum」、v13.0.0 3GPP TR 38.321、「Medium Access Control(MAC)protocol specification」、v15.1.0

より詳細な理解は、本明細書に添付された図面と併せて例として与えられた以下の詳細な説明から得られてよい。説明における図は、例である。従って、図および詳細な説明は、限定するものと考えられるべきではなく、他の等しく効果的な例は、可能であり、考え得る。さらに、図における同様の参照番号は、同様の要素を示す。
１つまたは複数の開示された実施形態が実装され得る例示的な通信システムを例証するシステム図である。 実施形態による、図１Ａに例証された通信システム内で使用され得る例示的な無線送受信ユニット（ＷＴＲＵ）を例証するシステム図である。 実施形態による、図１Ａに例証された通信システム内で使用され得る例示的な無線アクセスネットワーク（ＲＡＮ）および例示的なコアネットワーク（ＣＮ）を例証するシステム図である。 実施形態による、図１Ａに例証された通信システム内で使用され得るさらなる例示的なＲＡＮおよびさらなる例示的なＣＮを例証するシステム図である。 １つまたは複数の実施形態による、クリアチャネルアセスメント（ＣＣＡ）なしのＨＡＲＱフィードバックの例におけるサブフレームの列を例証する図である。 １つまたは複数の実施形態による、異なるチャネル占有時間（ＣＯＴ）におけるＨＡＲＱ送信の例を例証する図である。 １つまたは複数の実施形態による、ダウンリンク制御情報（ＤＣＩ）における１つまたは複数のＰＤＳＣＨ−ｔо−ＨＡＲＱタイミングインジケータを再使用する２つの例を例証する２つのテーブルである。 １つまたは複数の実施形態による、カウンタダウンリンク割り当てインデックス（ＤＡＩ）を有するＨＡＲＱフィードバックの例におけるサブフレームの列を例証する図である。 １つまたは複数の実施形態による、ＨＡＲＱ送信のために多数の物理アップリンク制御チャネル（ＰＵＣＣＨ）リソースを使用する例を例証する図である。 １つまたは複数の実施形態による、ＰＵＣＣＨリソースセットから選択するときに確認応答リソースインジケータ（ＡＲＩ）と共にオフセットを構成する例を例証する図である。

通信ネットワークおよびデバイス
図１Ａは、１つまたは複数の開示された実施形態が実装され得る例示的な通信システム１００を例証する図である。通信システム１００は、音声、データ、ビデオ、メッセージング、ブロードキャストなどのコンテンツを、多数の無線ユーザに提供する多重アクセスシステムであってよい。通信システム１００は、無線帯域幅を含むシステムリソースの共有を通して、多数の無線ユーザが、そのようなコンテンツにアクセスするのを容易にし得る。例えば、通信システム１００は、符号分割多重アクセス（ＣＤＭＡ）、時分割多重アクセス（ＴＤＭＡ）、周波数分割多重アクセス（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、単一キャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）、ゼロテールユニークワードＤＦＴ拡散ＯＦＤＭ（ＺＴ ＵＷ ＤＴＳ−ｓＯＦＤＭ）、ユニークワードＯＦＤＭ（ＵＷ−ＯＦＤＭ）、リソースブロックフィルタ処理済みＯＦＤＭ、フィルタバンクマルチキャリア（ＦＢＭＣ）などの、１つまたは複数のチャネルアクセス方法を採用することができる。

図１Ａに示されるように、通信システム１００は、無線送受信ユニット（ＷＴＲＵ）１０２ａ、１０２ｂ、１０２ｃ、１０２ｄと、ＲＡＮ１０４／１１３と、ＣＮ１０６／１１５と、公衆交換電話ネットワーク（ＰＳＴＮ）１０８と、インターネット１１０と、他のネットワーク１１２とを含むことができるが、開示された実施形態は、任意の数のＷＴＲＵ、基地局、ネットワーク、および／またはネットワーク要素を企図することが認識されるであろう。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの各々は、無線環境において動作する、および／または通信するように構成された任意のタイプのデバイスであってよい。例えば、いずれかが「局」および／または「ＳＴＡ」と呼ばれてもよいＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、無線信号を送信および／または受信するように構成されてよく、ユーザ機器（ＵＥ）、モバイル局、固定またはモバイルサブスクライバユニット、サブスクリプションベースのユニット、ページャ、セルラ電話、ＰＤＡ、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、無線センサ、ホットスポットまたはＭｉ−Ｆｉデバイス、ＩоＴデバイス、ウォッチまたは他のウェアラブル、ヘッドマウントディスプレイ（ＨＭＤ）、ビークル、ドローン、医療デバイスおよびアプリケーション（例えば、リモート手術）、産業デバイスおよびアプリケーション（例えば、産業および／または自動化された処理チェーンコンテキストにおいて動作するロボットおよび／または他の無線デバイス）、家庭用電子機器、商業および／または産業無線ネットワーク上で動作するデバイス、その他を含むことができる。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、および１０２ｄのいずれかは、交換可能にＵＥと呼ばれ得る。

通信システム１００はまた、基地局１１４ａおよび／または基地局１１４ｂを含むことができる。基地局１１４ａ、１１４ｂの各々は、ＣＮ１０６／１１５、インターネット１１０、および／または他のネットワーク１１２などの１つまたは複数の通信ネットワークへのアクセスを促進するために、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの少なくとも１つとワイヤレスにインターフェースを取るように構成された任意のタイプのデバイスであってよい。例えば、基地局１１４ａ、１１４ｂは、基地トランシーバ局（ＢＴＳ）、Ｎｏｄｅ−Ｂ、ｅＮｏｄｅＢ、ホームＮｏｄｅＢ、ホームｅＮｏｄｅＢ、ｇＮＢ、新無線（ＮＲ）ＮｏｄｅＢ、サイトコントローラ、アクセスポイント（ＡＰ）、無線ルータ、その他であってよい。基地局１１４ａ、１１４ｂは各々、単一の要素として描写されているが、基地局１１４ａ、１１４ｂは、任意の数の相互接続された基地局および／またはネットワーク要素を含んでもよいことが認識されるであろう。

基地局１１４ａは、ＲＡＮ１０４／１１３の一部であってもよく、ＲＡＮ１０４／１１３はまた、基地局コントローラ（ＢＳＣ）、無線ネットワークコントローラ（ＲＮＣ）、中継ノード、その他などの、他の基地局および／またはネットワーク要素（図示せず）を含むことができる。基地局１１４ａおよび／または基地局１１４ｂは、セル（図示せず）と呼ばれてよい１つまたは複数のキャリア周波数上で、無線信号を送信および／または受信するように構成されてよい。これらの周波数は、認可スペクトルに、無認可スペクトルに、または認可および無認可スペクトルの組合せにあることがある。セルは、相対的に固定されることも、または経時的に変化することもある固有の地理的エリアに、無線サービスのためのカバレッジを提供することができる。セルは、セルセクタにさらに分割されてもよい。例えば、基地局１１４ａに関連付けられたセルは、３つのセクタに分割されてもよい。従って、一実施形態において、基地局１１４ａは、例えば、セルのセクタごとに１つの、３つのトランシーバを含むことができる。実施形態において、基地局１１４ａは、ＭＩＭＯ技術を採用することができ、セルのセクタごとに多数のトランシーバを利用することができる。例えば、ビームフォーミングが、所望の空間的方向において信号を送信および／または受信するために使用されてもよい。

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

より具体的には、上記されたように、通信システム１００は、多重アクセスシステムであってよく、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、ＳＣ−ＦＤＭＡなどの、１つまたは複数のチャネルアクセス方式を採用することができる。例えば、ＲＡＮ１０４／１１３における基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、広帯域ＣＤＭＡ（ＷＣＤＭＡ（登録商標））を使用してエアインターフェース１１５／１１６／１１７を確立できる、ユニバーサルモバイル電気通信システム（ＵＭＴＳ）地上無線アクセス（ＵＴＲＡ）などの無線技術を実装することができる。ＷＣＤＭＡは、高速パケットアクセス（ＨＳＰＡ）および／または進化型ＨＳＰＡ（ＨＳＰＡ＋）などの通信プロトコルを含むことができる。ＨＳＰＡは、高速ダウンリンク（ＤＬ）パケットアクセス（ＨＳＤＰＡ）および／または高速ＵＬパケットアクセス（ＨＳＵＰＡ）を含むことができる。

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

実施形態において、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、新無線（ＮＲ）を使用してエアインターフェース１１６を確立することができる、ＮＲ無線アクセスなどの無線技術を実装することができる。

実施形態において、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、多数の無線アクセス技術を実装することができる。例えば、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、デュアル接続性（ＤＣ）原理を使用して、ＬＴＥ無線アクセスとＮＲ無線アクセスとを一緒に実装することができる。従って、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃによって利用されるエアインターフェースは、多数のタイプの無線アクセス技術および／または多数のタイプの基地局（例えば、ｅＮＢおよびｇＮＢ）へ／から送られる送信によって特徴付けられてよい。

他の実施形態において、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＩＥＥＥ８０２．１１（例えば、ＷｉＦｉ（Wireless Fidelity））、ＩＥＥＥ８０２．１６（例えば、ＷｉＭＡＸ（Worldwide Interoperability for Microwave Access））、ＣＤＭＡ２０００、ＣＤＭＡ２０００ １Ｘ、ＣＤＭＡ２０００ ＥＶ−ＤＯ、Ｉｎｔｅｒｉｍ Ｓｔａｎｄａｒｄ２０００（ＩＳ−２０００）、Ｉｎｔｅｒｉｍ Ｓｔａｎｄａｒｄ９５（ＩＳ−９５）、Ｉｎｔｅｒｉｍ Ｓｔａｎｄａｒｄ８５６（ＩＳ−８５６）、ＧＳＭ（登録商標）（Global System for Mobile Communications）、ＧＳＭエボリューションのための拡張データレート（ＥＤＧＥ）、ＧＳＭ ＥＤＧＥ（ＧＥＲＡＮ）、その他などの無線技術を実装することができる。

図１Ａにおける基地局１１４ｂは、無線ルータ、ホームＮｏｄｅＢ、ホームｅＮｏｄｅＢ、またはアクセスポイントであってよく、例えば、ビジネス、ホーム、ビークル、キャンパス、産業施設、（例えば、ドローンによる使用のための）空中回廊、道路、その他の場所などの局所化されたエリアにおける無線接続性を促進するための任意の好適なＲＡＴを利用することができる。一実施形態において、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、ＩＥＥＥ８０２．１１などの無線技術を実装して、無線ローカルエリアネットワーク（ＷＬＡＮ）を確立することができる。実施形態において、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、ＩＥＥＥ８０２．１５などの無線技術を実装して、無線パーソナルエリアネットワーク（ＷＰＡＮ）を確立することができる。さらに別の実施形態において、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、セルラベースのＲＡＴ（例えば、ＷＣＤＭＡ、ＣＤＭＡ２０００、ＧＳＭ、ＬＴＥ、ＬＴＥ−Ａ、ＬＴＥ−Ａ Ｐｒｏ、ＮＲなど）を利用して、ピコセルまたはフェムトセルを確立することができる。図１Ａに示されるように、基地局１１４ｂは、インターネット１１０への直接接続を有することができる。従って、基地局１１４ｂは、ＣＮ１０６／１１５を介してインターネット１１０にアクセスするように求められなくてもよい。

ＲＡＮ１０４／１１３は、ＣＮ１０６／１１５と通信していてよく、ＣＮ１０６／１１５は、ボイス、データ、アプリケーション、および／またはＶоＩＰサービスを、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの１つまたは複数に提供するように構成された任意のタイプのネットワークであってよい。データは、異なるスループット要件、レイテンシ要件、エラー耐性要件、信頼性要件、データスループット要件、モビリティ要件、その他などの多様なサービス品質（ＱоＳ）要件を有することができる。ＣＮ１０６／１１５は、呼制御、ビリングサービス、モバイル位置情報サービス、プリペイド通話、インターネット接続性、ビデオ配信などを提供すること、および／または、ユーザ認証などの高レベルなセキュリティ機能を実施することができる。図１Ａには示されていないが、ＲＡＮ１０４／１１３および／またはＣＮ１０６／１１５は、ＲＡＮ１０４／１１３と同じＲＡＴまたは異なるＲＡＴを採用する他のＲＡＮと、直接的または間接的に通信していてもよいことが認識されるであろう。例えば、ＣＮ１０６／１１５はまた、ＮＲ無線技術を利用していることがあるＲＡＮ１０４／１１３に接続されていることに加えて、ＧＳＭ、ＵＭＴＳ、ＣＤＭＡ２０００、ＷｉＭＡＸ、Ｅ−ＵＴＲＡ、またはＷｉＦｉ無線技術を採用する別のＲＡＮ（図示せず）と通信していてもよい。

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

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

図１Ｂは、例示的なＷＴＲＵ１０２を例証するシステム図である。図１Ｂに示されるように、ＷＴＲＵ１０２は、プロセッサ１１８、トランシーバ１２０、送受信要素１２２、スピーカ／マイクロフォン１２４、キーパッド１２６、ディスプレイ／タッチパッド１２８、非リムーバブルメモリ１３０、リムーバブルメモリ１３２、電源１３４、ＧＰＳチップセット１３６、および／または、他の周辺機器１３８を含むことができる。ＷＴＲＵ１０２は、実施形態と一貫したままでありながら、上述した要素の任意の下位組合せを含むことができることが認識されるであろう。

プロセッサ１１８は、汎用プロセッサ、特殊目的プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアに関連した１つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、ＡＳＩＣ、ＦＰＧＡ回路、任意の他のタイプの集積回路（ＩＣ）、状態マシン、その他であってよい。プロセッサ１１８は、信号コーディング、データ処理、電力制御、入出力処理、および／またはＷＴＲＵ１０２が無線環境において動作するのを容易にする任意の他の機能性を実施することができる。プロセッサ１１８は、送受信要素１２２に結合され得るトランシーバ１２０に結合されてよい。図１Ｂはプロセッサ１１８とトランシーバ１２０とを別個のコンポーネントとして描写しているが、プロセッサ１１８とトランシーバ１２０とは、電子パッケージまたはチップに一緒に統合されてもよいことが認識されるであろう。

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

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

トランシーバ１２０は、送受信要素１２２によって送信されることになる信号を変調し、送受信要素１２２によって受信された信号を復調するように構成されてよい。上記されたように、ＷＴＲＵ１０２は、マルチモード能力を有することができる。従って、トランシーバ１２０は、ＷＴＲＵ１０２が、例えば、ＮＲおよびＩＥＥＥ８０２．１１などの多数のＲＡＴを介して通信するのを容易にする多数のトランシーバを含むことができる。

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

プロセッサ１１８は、電源１３４から電力を受信することができ、ＷＴＲＵ１０２における他のコンポーネントへの電力を分散および／または制御するように構成されてよい。電源１３４は、ＷＴＲＵ１０２に電力供給するための任意の好適なデバイスであってよい。例えば、電源１３４は、１つまたは複数のドライセルバッテリ（例えば、ニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル金属水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉоｎ）など）、ソーラーセル、燃料セル、その他を含み得る。

プロセッサ１１８はまた、ＷＴＲＵ１０２の現在の位置に関する位置情報（例えば、経度および緯度）を提供するように構成されてよいＧＰＳチップセット１３６に結合されてよい。ＧＰＳチップセット１３６からの情報に加えて、またはそれに代えて、ＷＴＲＵ１０２は、基地局（例えば、基地局１１４ａ、１１４ｂ）からエアインターフェース１１６上で位置情報を受信する、および／または２つ以上の付近の基地局から受信されている信号のタイミングに基づいてその位置を判定することができる。ＷＴＲＵ１０２は、実施形態と一貫したままでありながら、任意の好適な位置判定方法を経由して位置情報を取得することができることが認識されるであろう。

プロセッサ１１８は、追加の特徴、機能性、および／または有線もしくは無線接続性を提供する１つもしくは複数のソフトウェアおよび／またはハードウェアモジュールを含むことができる他の周辺機器１３８にさらに結合されてよい。例えば、周辺機器１３８は、加速度計、電子コンパス、衛星トランシーバ、（写真および／またはビデオのための）デジタルカメラ、ＵＳＢポート、振動デバイス、テレビジョントランシーバ、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）無線ユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザ、仮想現実および／または拡張現実（ＶＲ／ＡＲ）デバイス、アクティビティトラッカ、その他を含むことができる。周辺機器１３８は、１つまたは複数のセンサを含むことができ、センサは、ジャイロスコープ、加速度計、ホール効果センサ、磁気計、方位センサ、近接センサ、温度センサ、時間センサ、ジオロケーションセンサ、高度計、光センサ、タッチセンサ、磁気計、気圧計、ジェスチャセンサ、バイオメトリックセンサ、および／または湿度センサのうちの１つまたは複数であってよい。

ＷＴＲＵ１０２は、（例えば、（例えば、送信のための）ＵＬと（例えば、受信のための）ダウンリンクとの両方のための特定のサブフレームに関連付けられた）信号のいくつかまたは全ての送信および受信が並行および／または同時であってよい、全二重無線を含むことができる。全二重無線は、ハードウェア（例えば、チョーク）またはプロセッサを介した（例えば、別個のプロセッサ（図示せず）もしくはプロセッサ１１８を介した）信号処理のいずれかを介して、自己干渉を低減するおよび／または実質的になくすための干渉管理ユニット１３９を含むことができる。実施形態において、ＷＴＲＵ１０２は、（例えば、（例えば、送信のための）ＵＬまたは（例えば、受信のための）ダウンリンクのいずれかのための特定のサブフレームに関連付けられた）信号のいくつかまたは全ての送信および受信のための、半二重無線を含んでもよい。

図１Ｃは、実施形態による、ＲＡＮ１０４およびＣＮ１０６を例証するシステム図である。上記されたように、ＲＡＮ１０４は、Ｅ−ＵＴＲＡ無線技術を採用して、エアインターフェース１１６上でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信することができる。ＲＡＮ１０４はまた、ＣＮ１０６と通信していてよい。

ＲＡＮ１０４は、ｅＮｏｄｅＢ１６０ａ、１６０ｂ、１６０ｃを含むことができるが、ＲＡＮ１０４は、実施形態と一貫したままでありながら、任意の数のｅＮｏｄｅＢを含むことができることが認識されるであろう。ｅＮｏｄｅＢ１６０ａ、１６０ｂ、１６０ｃは各々、エアインターフェース１１６上でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための１つまたは複数のトランシーバを含むことができる。一実施形態において、ｅＮｏｄｅＢ１６０ａ、１６０ｂ、１６０ｃは、ＭＩＭＯ技術を実装することができる。従って、ｅＮｏｄｅＢ１６０ａは、例えば、多数のアンテナを使用して、ＷＴＲＵ１０２ａに無線信号を送信し、および／またはＷＴＲＵ１０２ａから無線信号を受信することができる。

ｅＮｏｄｅＢ１６０ａ、１６０ｂ、１６０ｃの各々は、特定のセル（図示せず）に関連付けられていてよく、無線リソース管理決定、ハンドオーバ決定、ＵＬおよび／またはＤＬにおけるユーザのスケジューリング、その他に対処するように構成されてよい。図１Ｃに示されるように、ｅＮｏｄｅＢ１６０ａ、１６０ｂ、１６０ｃは、Ｘ２インターフェース上で互いに通信することができる。

図１Ｃに示されるＣＮ１０６は、モビリティ管理エンティティ（ＭＭＥ）１６２と、サービングゲートウェイ（ＳＧＷ）１６４と、パケットデータネットワーク（ＰＤＮ）ゲートウェイ（またはＰＧＷ）１６６とを含むことができる。上述した要素の各々は、ＣＮ１０６の一部として描写されているが、これらの要素のいずれかがＣＮオペレータ以外のエンティティによって所有および／または運用されてもよいことが認識されるであろう。

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

ＳＧＷ１６４は、Ｓ１インターフェースを介して、ＲＡＮ１０４におけるｅＮｏｄｅＢ１６０ａ、１６０ｂ、１６０ｃの各々に接続されてよい。ＳＧＷ１６４は、一般に、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃへの／からのユーザデータパケットをルーティングし、転送することができる。ＳＧＷ１６４は、ｅＮｏｄｅＢ間のハンドオーバ中にユーザプレーンをアンカーすること、ＤＬデータがＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに利用可能であるときにページングをトリガすること、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのコンテキストを管理し、記憶することなどの、他の機能を実施することができる。

ＳＧＷ１６４は、ＰＧＷ１６６に接続されてよく、ＰＧＷ１６６は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに、インターネット１１０などのパケット交換ネットワークへのアクセスを提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスとの間の通信を促進することができる。

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

ＷＴＲＵは図１Ａ〜図１Ｄで無線端末として説明されているが、そのような端末が（一時的にまたは永続的に）使用してもよい一定の代表的な実施形態においては、有線通信が通信ネットワークとインターフェースを取ることが企図される。

いくつかの代表的な実施形態において、他のネットワーク１１２は、ＷＬＡＮであってよい。

インフラストラクチャ基本サービスセット（ＢＳＳ）モードにおけるＷＬＡＮは、ＢＳＳ用のアクセスポイント（ＡＰ）と、ＡＰに関連付けられた１つまたは複数の局（ＳＴＡ）とを有することができる。ＡＰは、配信システム（ＤＳ）への、またはＢＳＳに入るおよび／もしくはＢＳＳから出るトラフィックを搬送する別のタイプの有線／無線ネットワークへの、アクセスまたはインターフェースを有することができる。ＢＳＳの外側から発信するＳＴＡへのトラフィックは、ＡＰを通して到着することができ、ＳＴＡに届けられてよい。ＳＴＡから発信するＢＳＳの外側の宛先へのトラフィックは、それぞれの宛先に届けられるために、ＡＰに送られてよい。例えば、送信元ＳＴＡがトラフィックをＡＰに送ることができ、ＡＰがトラフィックを宛先ＳＴＡに届けることができる場合に、ＢＳＳ内のＳＴＡ間のトラフィックは、ＡＰを通して送られてよい。ＢＳＳ内のＳＴＡ間のトラフィックは、ピアツーピアトラフィックと考えられても、および／またはピアツーピアトラフィックと呼ばれてもよい。ピアツーピアトラフィックは、直接リンクセットアップ（ＤＬＳ）を用いて、送信元ＳＴＡと宛先ＳＴＡとの間で（例えば、それらの間で直接）送られてよい。一定の代表的な実施形態において、ＤＬＳは、８０２．１１ｅＤＳＬまたは８０２．１１ｚトンネルドＤＬＳ（ＴＤＬＳ）を使用することができる。独立ＢＳＳ（ＩＢＳＳ）モードを使用するＷＬＡＮは、ＡＰを有さないことがあり、ＩＢＳＳ内の、またはＩＢＳＳを使用するＳＴＡ（例えば、ＳＴＡの全て）は、互いに直接通信することができる。ＩＢＳＳ通信モードは、時に、本明細書において「アドホック」通信モードと呼ばれてもよい。

８０２．１１ａｃインフラストラクチャ動作モードまたは同様の動作モードを使用するとき、ＡＰは、一次チャネルなどの固定されたチャネル上で、ビーコンを送信することができる。一次チャネルは、固定された幅（例えば、２０ＭＨｚ幅の帯域幅）、またはシグナリングを介して動的に設定された幅であってよい。一次チャネルは、ＢＳＳの動作チャネルであってよく、ＡＰとの接続を確立するためにＳＴＡによって使用されてよい。一定の代表的な実施形態において、衝突回避を備えたキャリア検知多重アクセス（ＣＳＭＡ／ＣＡ）が、例えば、８０２．１１システムにおいて実装されてもよい。ＣＳＭＡ／ＣＡの場合、ＡＰを含むＳＴＡ（例えば、あらゆるＳＴＡ）が、一次チャネルを検知することができる。特定のＳＴＡによって一次チャネルが検知／検出された場合、および／またはビジーであると判定された場合、特定のＳＴＡは、バックオフすることができる。１つのＳＴＡ（例えば、１つのみの局）が、所与のＢＳＳにおいて、任意の所与の時間に送信することができる。

高スループット（ＨＴ）ＳＴＡは、例えば、一次２０ＭＨｚチャネルと、隣り合った、または隣り合っていない２０ＭＨｚチャネルとの組合せを介して通信のための４０ＭＨｚ幅のチャネルを使用して、４０ＭＨｚ幅のチャネルを形成することができる。

超高スループット（ＶＨＴ）ＳＴＡは、２０ＭＨｚ、４０ＭＨｚ、８０ＭＨｚ、および／または１６０ＭＨｚ幅のチャネルをサポートすることができる。４０ＭＨｚおよび／または８０ＭＨｚチャネルは、隣接した２０ＭＨｚチャネルを組み合わせることによって形成されてよい。１６０ＭＨｚチャネルは、８つの隣接した２０ＭＨｚチャネルを組み合わせることによって、または、８０＋８０構成と呼ばれることがある２つの隣接していない８０ＭＨｚチャネルを組み合わせることによって形成されてよい。８０＋８０構成の場合、データは、チャネル符号化後に、データを２つのストリームに分割することができるセグメントパーサに通されてよい。逆高速フーリエ変換（ＩＦＦＴ）処理および時間ドメイン処理が、各ストリームに別々に行われてよい。ストリームは、２つの８０ＭＨｚチャネル上にマッピングされてよく、データは、送信ＳＴＡによって送信されてよい。受信ＳＴＡの受信機では、８０＋８０構成について上で説明された動作が逆にされてよく、組み合わせられたデータは、媒体アクセス制御（ＭＡＣ）に送られてよい。

サブ１ＧＨｚ動作モードが、８０２．１１ａｆおよび８０２．１１ａｈによってサポートされる。チャネル動作帯域幅およびキャリアは、８０２．１１ｎおよび８０２．１１ａｃで使用されるものに比べて、８０２．１１ａｆおよび８０２．１１ａｈでは低減される。８０２．１１ａｆは、ＴＶホワイトスペース（ＴＶＷＳ）スペクトルにおいて５ＭＨｚ、１０ＭＨｚおよび２０ＭＨｚ帯域幅をサポートし、８０２．１１ａｈは、非ＴＶＷＳスペクトルを使用して、１ＭＨｚ、２ＭＨｚ、４ＭＨｚ、８ＭＨｚおよび１６ＭＨｚ帯域幅をサポートする。代表的な実施形態によれば、８０２．１１ａｈは、マクロカバレッジエリアにおけるＭＴＣデバイスなどの、メータタイプ制御／マシンタイプ通信をサポートすることができる。ＭＴＣデバイスは、一定の能力、例えば、一定のおよび／または限定された帯域幅に対するサポート（例えば、それに対してのみのサポート）を含む、限定された能力を有することがある。ＭＴＣデバイスは、（例えば、非常に長いバッテリ寿命を維持するために）閾値を上回るバッテリ寿命を有するバッテリを含むことができる。

８０２．１１ｎ、８０２．１１ａｃ、８０２．１１ａｆ、および８０２．１１ａｈなどの、多数のチャネルおよびチャネル帯域幅をサポートすることができるＷＬＡＮシステムは、一次チャネルとして指定され得るチャネルを含む。一次チャネルは、ＢＳＳにおける全てのＳＴＡによってサポートされる最も大きい共通動作帯域幅に等しい帯域幅を有することができる。一次チャネルの帯域幅は、ＢＳＳにおいて動作中の全てのＳＴＡの中から、最も小さい帯域幅動作モードをサポートするＳＴＡによって設定および／または限定されてよい。８０２．１１ａｈの例において、ＡＰおよびＢＳＳにおける他のＳＴＡが２ＭＨｚ、４ＭＨｚ、８ＭＨｚ、１６ＭＨｚ、および／または他のチャネル帯域幅動作モードをサポートする場合であっても、一次チャネルは、１ＭＨｚモードをサポートする（例えば、それのみをサポートする）ＳＴＡ（例えば、ＭＴＣタイプデバイス）に対して１ＭＨｚ幅であってよい。キャリア検知および／または送信禁止期間（ＮＡＶ）設定は、一次チャネルのステータスに依存してよい。例えば、ＡＰに送信するＳＴＡ（１ＭＨｚ動作モードのみをサポートする）に起因して一次チャネルがビジーである場合、周波数帯域の大部分がアイドルのままであり、利用可能であり得るとしても、利用可能な周波数帯域全体がビジーであると考えられてよい。

米国において、８０２．１１ａｈによって使用され得る利用可能な周波数帯域は、９０２ＭＨｚから９２８ＭＨｚまでである。韓国において、利用可能な周波数帯域は、９１７．５ＭＨｚから９２３．５ＭＨｚまでである。日本において、利用可能な周波数帯域は、９１６．５ＭＨｚから９２７．５ＭＨｚまでである。８０２．１１ａｈのために利用可能なトータル帯域幅は、国コードに応じて、６ＭＨｚから２６ＭＨｚである。

図１Ｄは、実施形態による、ＲＡＮ１１３およびＣＮ１１５を例証するシステム図である。上記されたように、ＲＡＮ１１３は、ＮＲ無線技術を採用して、エアインターフェース１１６上でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信することができる。ＲＡＮ１１３はまた、ＣＮ１１５と通信していてよい。

ＲＡＮ１１３は、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃを含むことができるが、ＲＡＮ１１３は、実施形態と一貫したままでありながら、任意の数のｇＮＢを含むことができることが認識されるであろう。ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは各々、エアインターフェース１１６上でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための１つまたは複数のトランシーバを含むことができる。一実施形態において、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、ＭＩＭＯ技術を実装することができる。例えば、ｇＮＢ１８０ａ、１８０ｂは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに信号を送信し、および／またはＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃから信号を受信するために、ビームフォーミングを利用することができる。従って、ｇＮＢ１８０ａは、例えば、多数のアンテナを使用して、ＷＴＲＵ１０２ａに無線信号を送信し、および／またはＷＴＲＵ１０２ａから無線信号を受信することができる。実施形態において、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、キャリアアグリゲーション技術を実装することができる。例えば、ｇＮＢ１８０ａは、多数のコンポーネントキャリアをＷＴＲＵ１０２ａに送信することができる（図示せず）。これらのコンポーネントキャリアのサブセットは、無認可スペクトル上にあることがあり、一方、残りのコンポーネントキャリアは、認可スペクトル上にあることがある。実施形態において、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、協調マルチポイント（ＣｏＭＰ）技術を実装することができる。例えば、ＷＴＲＵ１０２ａは、ｇＮＢ１８０ａおよびｇＮＢ１８０ｂ（および／またはｇＮＢ１８０ｃ）から協調された送信を受信することができる。

ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、スケーラブルなニューメロロジーに関連付けられた送信を使用して、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃと通信することができる。例えば、ＯＦＤＭシンボル間隔および／またはＯＦＤＭサブキャリア間隔は、異なる送信、異なるセル、および／または無線送信スペクトルの異なる部分に対して多様であってよい。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、様々な、またはスケーラブルな長さの（例えば、多様な数のＯＦＤＭシンボルを収容する、および／または多様な長さの絶対時間を持続する）サブフレームまたは送信時間インターバル（ＴＴＩ）を使用して、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃと通信することができる。

ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、スタンドアロン構成および／または非スタンドアロン構成において、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するように構成されてよい。スタンドアロン構成において、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、他のＲＡＮ（例えば、ｅＮｏｄｅＢ１６０ａ、１６０ｂ、１６０ｃなど）にまたアクセスすることなく、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃと通信することができる。スタンドアロン構成において、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃのうちの１つまたは複数を、モビリティアンカーポイントとして利用することができる。スタンドアロン構成において、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、無認可帯域における信号を使用して、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃと通信することができる。非スタンドアロン構成において、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ｅＮｏｄｅＢ１６０ａ、１６０ｂ、１６０ｃなどの別のＲＡＮとまた通信しながら／に接続しながら、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃと通信／に接続することができる。例えば、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＤＣ原理を実装して、１つまたは複数のｇＮＢ１８０ａ、１８０ｂ、１８０ｃと、および１つまたは複数のｅＮｏｄｅＢ１６０ａ、１６０ｂ、１６０ｃと、実質的に同時に通信することができる。非スタンドアロン構成において、ｅＮｏｄｅＢ１６０ａ、１６０ｂ、１６０ｃは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのためのモビリティアンカーとして働くことができ、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃにサービスするための追加のカバレッジおよび／またはスループットを提供することができる。

ｇＮＢ１８０ａ、１８０ｂ、１８０ｃの各々は、特定のセル（図示せず）に関連付けられてよく、無線リソース管理決定、ハンドオーバ決定、ＵＬおよび／またはＤＬにおけるユーザのスケジューリング、ネットワークスライシングのサポート、デュアル接続性、ＮＲとＥ−ＵＴＲＡとの間のインターワーキング、ユーザプレーン機能（ＵＰＦ）１８４ａ、１８４ｂに向けたユーザプレーンデータのルーティング、アクセスおよびモビリティ管理機能（ＡＭＦ）１８２ａ、１８２ｂに向けた制御プレーン情報のルーティング、その他に対処するように構成されてよい。図１Ｄに示されるように、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、Ｘｎインターフェース上で互いに通信することができる。

図１Ｄに示されるＣＮ１１５は、少なくとも１つのＡＭＦ１８２ａ、１８２ｂ、少なくとも１つのＵＰＦ１８４ａ、１８４ｂ、少なくとも１つのセッション管理機能（ＳＭＦ）１８３ａ、１８３ｂ、および場合により、データネットワーク（ＤＮ）１８５ａ、１８５ｂを含むことができる。上述した要素の各々はＣＮ１１５の一部として描写されているが、これらの要素のいずれかがＣＮオペレータ以外のエンティティによって所有および／または運用されてもよいことが認識されるであろう。

ＡＭＦ１８２ａ、１８２ｂは、Ｎ２インターフェースを介して、ＲＡＮ１１３におけるｇＮＢ１８０ａ、１８０ｂ、１８０ｃのうちの１つまたは複数に接続されてよく、制御ノードとして働くことができる。例えば、ＡＭＦ１８２ａ、１８２ｂは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのユーザを認証すること、ネットワークスライシングのためのサポート（例えば、異なる要件を有する異なるＰＤＵセッションに対処すること）、特定のＳＭＦ１８３ａ、１８３ｂを選択すること、レジストレーションエリアの管理、ＮＡＳシグナリングの終了、モビリティ管理、その他を担うことができる。ネットワークスライシングは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃによって利用されるサービスのタイプに基づいて、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのためのＣＮサポートをカスタマイズするために、ＡＭＦ１８２ａ、１８２ｂによって使用されてよい。例えば、異なるネットワークスライスが、超高信頼度低レイテンシ（ＵＲＬＬＣ）アクセスに依拠したサービス、拡張大規模モバイルブロードバンド（ｅＭＢＢ）アクセスに依拠したサービス、マシンタイプ通信（ＭＴＣ）アクセスのためのサービス、および／またはその他などの、異なる使用事例のために確立されてよい。ＡＭＦ１８２は、ＲＡＮ１１３と、ＬＴＥ、ＬＴＥ−Ａ、ＬＴＥ−Ａ Ｐｒｏ、および／またはＷｉＦｉなどの非３ＧＰＰアクセス技術などの他の無線技術を採用する他のＲＡＮ（図示せず）との間をスイッチするための制御プレーン機能を提供することができる。

ＳＭＦ１８３ａ、１８３ｂは、Ｎ１１インターフェースを介して、ＣＮ１１５におけるＡＭＦ１８２ａ、１８２ｂに接続されてよい。ＳＭＦ１８３ａ、１８３ｂはまた、Ｎ４インターフェースを介して、ＣＮ１１５におけるＵＰＦ１８４ａ、１８４ｂに接続されてよい。ＳＭＦ１８３ａ、１８３ｂは、ＵＰＦ１８４ａ、１８４ｂを選択し、制御し、ＵＰＦ１８４ａ、１８４ｂを通るトラフィックのルーティングを構成することができる。ＳＭＦ１８３ａ、１８３ｂは、ＷＴＲＵまたはＵＥ ＩＰアドレスを管理し、割り当てること、ＰＤＵセッションを管理すること、ポリシー施行およびＱｏＳを制御すること、ダウンリンクデータ通知を提供することなどの、他の機能を実施することができる。ＰＤＵセッションタイプは、ＩＰベース、非ＩＰベース、イーサネットベース、その他であってよい。

ＵＰＦ１８４ａ、１８４ｂは、Ｎ３インターフェースを介して、ＲＡＮ１１３におけるｇＮＢ１８０ａ、１８０ｂ、１８０ｃのうちの１つまたは複数に接続されてよく、これは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスとの間の通信を促進するために、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに、インターネット１１０などのパケット交換ネットワークへのアクセスを提供することができる。ＵＰＦ１８４ａ、１８４ｂは、パケットをルーティングし、転送すること、ユーザプレーンポリシーを施行すること、マルチホームドＰＤＵセッションをサポートすること、ユーザプレーンＱｏＳに対処すること、ダウンリンクパケットをバッファすること、モビリティアンカリングを提供することなどの、他の機能を実施することができる。

ＣＮ１１５は、他のネットワークとの通信を促進することができる。例えば、ＣＮ１１５は、ＣＮ１１５とＰＳＴＮ１０８との間のインターフェースとして働くＩＰゲートウェイ（例えば、ＩＰマルチメディアサブシステム（ＩＭＳ）サーバ）を含むことができる、またはＩＰゲートウェイと通信することができる。また、ＣＮ１１５は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに、他のサービスプロバイダによって所有および／または運用される他の有線および／または無線ネットワークを含むことができる他のネットワーク１１２へのアクセスを提供することができる。一実施形態において、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＵＰＦ１８４ａ、１８４ｂへのＮ３インターフェース、およびＵＰＦ１８４ａ、１８４ｂとＤＮ１８５ａ、１８５ｂとの間のＮ６インターフェースを介して、ＵＰＦ１８４ａ、１８４ｂを通してローカルデータネットワーク（ＤＮ）１８５ａ、１８５ｂに接続されてよい。

図１Ａ〜図１Ｄ、および図１Ａ〜図１Ｄの対応する説明を考慮して、ＷＴＲＵ１０２ａ〜ｄ、基地局１１４ａ〜ｂ、ｅＮｏｄｅＢ１６０ａ〜ｃ、ＭＭＥ１６２、ＳＧＷ１６４、ＰＧＷ１６６、ｇＮＢ１８０ａ〜ｃ、ＡＭＦ１８２ａ〜ｂ、ＵＰＦ１８４ａ〜ｂ、ＳＭＦ１８３ａ〜ｂ、ＤＮ１８５ａ〜ｂ、および／または本明細書で説明される任意の他のデバイスのうちの１つまたは複数に関して本明細書で説明される機能のうちの１つもしくは複数または全ては、１つまたは複数のエミュレーションデバイス（図示せず）によって実施されてもよい。エミュレーションデバイスは、本明細書で説明される機能のうちの１つもしくは複数または全てを、エミュレートするように構成された１つまたは複数のデバイスであってよい。例えば、エミュレーションデバイスは、他のデバイスをテストするために、並びに／または、ネットワークおよび／もしくはＷＴＲＵ機能をシミュレートするために使用されてよい。

エミュレーションデバイスは、ラボ環境においておよび／またはオペレータネットワーク環境において、他のデバイスの１つまたは複数のテストを実装するように設計されてよい。例えば、１つまたは複数のエミュレーションデバイスは、通信ネットワーク内の他のデバイスをテストするために、有線および／または無線通信ネットワークの一部として完全にまたは部分的に実装および／または展開されながら、１つもしくは複数または全ての機能を実施することができる。１つまたは複数のエミュレーションデバイスは、有線および／または無線通信ネットワークの一部として一時的に実装／展開されながら、１つもしくは複数または全ての機能を実施することができる。エミュレーションデバイスは、テストする目的のために別のデバイスに直接結合されてもよいし、および／または無線（ｏｖｅｒ−ｔｈｅ−ａｉｒ）無線通信を使用してテスティングを実施してもよい。

１つまたは複数のエミュレーションデバイスは、有線および／または無線通信ネットワークの一部として実装／展開されないまま、全てを含む１つまたは複数の機能を実施することができる。例えば、エミュレーションデバイスは、１つまたは複数のコンポーネントのテスティングを実装するために、テスティングラボラトリおよび／または非展開（例えば、テスティング）有線および／または無線通信ネットワークにおけるテスティングシナリオにおいて利用されてもよい。１つまたは複数のエミュレーションデバイスは、テスト機器であってもよい。直接ＲＦ結合、および／または（例えば、１つまたは複数のアンテナを含むことができる）ＲＦ回路を介した無線通信が、データを送信および／または受信するためにエミュレーションデバイスによって使用されてよい。

無認可周波数帯域における動作
無認可周波数帯域における動作は、５ＧＨｚ地域などにおける無認可スペクトルについて定義され得る、公称チャネル帯域幅（ＮＣＢ）および／または占有チャネル帯域幅（ＯＣＢ）についての要件次第であってよい。いくつかの例において、ＮＣＢは、単一のチャネルに割り当てられた周波数の最も広い帯域（保護帯域を含む）であることがある。いくつかの例示的な規制方式において、ＮＣＢは、少なくとも５ＭＨｚでなければならず、ＯＣＢ（例えば、信号の電力の９９％を収容する帯域幅）は、宣言されたＮＣＢの８０％から１００％の間でなければならない。確立される通信の間、デバイスは、ＯＣＢが低減され得るモード（例えば、ＮＣＢの４０％程度の低さ）において、一時的に動作するのを可能にされる、または動作するように構成されてよい。

いくつかの例において、認可または無認可周波数帯域におけるチャネルアクセスは、リッスンビフォートーク（ＬＢＴ）メカニズムを使用することができる。態様において、ＬＢＴは、チャネルが占有されているか否かには無関係に命じられてもよい。例において、ＬＢＴ手続きまたはメカニズムは、チャネルを使用する前に、機器がそれによってクリアチャネルアセスメント（ＣＣＡ）検査を適用するメカニズムとして定義されてよい。

フレームベースのシステムにおいて、例えば、ＬＢＴは、ＣＣＡ時間（例えば、〜２０μｓ）、チャネル占有時間（ＣＯＴ）（例えば、最小１ｍｓ、最大１０ｍｓ）、アイドル期間（例えば、ＣＯＴの最小５％）、固定フレーム期間（例えば、ＣＯＴ＋アイドル期間に等しい時間期間）、短い制御シグナリング送信時間（例えば、５０ｍｓの観察期間内で５％の最大デューティサイクル）、および／またはＣＡＡエネルギー検出閾値のうちのいずれかによって特徴付けられてよい。

負荷ベースのシステムにおいて、例えば、ＬＢＴは、固定フレーム期間の代わりに、ＣＣＡまたは拡張ＣＣＡ（ＥＣＣＡ）における１つまたは複数のクリアアイドルスロットの数に対応する数、Ｎによって特徴付けられてよい。換言すれば、ＬＢＴ動作は、チャネルが利用可能であるとみなされる前に、クリアかつアイドルとして検出される必要があるスロットの数（Ｎ個のスロット）に関して定義され得るＣＣＡまたはＥＣＣＡを含むことができる。いくつかの例において、数Ｎは、予め決められたまたは予め構成された範囲内で、ランダムに選択され得る。いくつかの事例において、負荷ベースのシステムの場合、送信および／または受信構造は負荷ベースであってよく、時間内に固定されなくてもよい。

典型的な展開シナリオは、１つもしくは複数の（例えば、異なる）スタンドアロンＮＲベースの動作、１つもしくは複数の（例えば、異なる）デュアル接続性（ＤＣ）動作の変形、および／または、１つもしくは複数の（例えば、異なる）キャリアアグリゲーション（ＣＡ）の変形のうちのいずれかを含むことができる。一実施形態において、ＤＣ動作の異なる変形は、例えば、ＬＴＥ無線アクセス技術（ＲＡＴ）に従って動作する少なくとも１つのキャリアを有する進化型ユニバーサル地上無線アクセス−新無線−デュアル接続性（ＥＮ−ＤＣ）、またはＮＲ ＲＡＴに従って動作する１つもしくは複数のキャリアの少なくとも２つのセットを備えるＮＲ ＤＣを含むことができる。別の実施形態において、ＣＡの異なる変形は、例えば、ＬＴＥまたはＮＲ ＲＡＴの各々の、ゼロ、１つ、または複数のキャリアの異なる組合せを含むことができる。

ＬＴＥシステムの場合、本明細書で議論される１つまたは複数の機能性は、認可支援アクセス（ＬＡＡ）システムについて考えられてよい。第１の例において、ＬＢＴ（例えば、クリアチャネルアセスメント）が使用されてよい。ＣＣＡは、少なくともエネルギー検出を利用して、チャネルが占有されているかどうかを判定するために、チャネル上の他の信号の有無を判定する。いくつかの事例において、ヨーロッパおよび／または日本の規則は、１つまたは複数の無認可帯域においてＬＢＴの使用を命じることがある。規制要件とは別に、ＬＢＴを介したキャリア検知は、無認可スペクトルの公平な共有のための１つの方策であってよく、従って、それは、単一のグローバルソリューションフレームワークにおける無認可スペクトルでの公平かつ友好的な動作のために不可欠な特徴であり得る。

いくつかの例において、ＬＴＥシステムの場合、不連続な送信が、限定された最大送信時間長を有するキャリア上で発生することがある。無認可スペクトルにおいては、時に、チャネル利用可能性が保証されないことがある。ヨーロッパおよび日本などの一定の地域は、無認可スペクトルにおいて、連続送信を禁止する、および／または送信バーストの最大時間長に限度を課すことがある。従って、いくつかの事例において、限定された最大送信時間長を有する不連続送信は、ＬＡＡに対して求められた機能性であることがある。

いくつかの例において、ＬＴＥシステムの場合、キャリア選択が構成または使用されることがある。例えば、無認可スペクトルは、大量の利用可能な帯域幅を含むことがあり、この事例において、キャリア選択は、ＬＡＡノードが低干渉を有する１つまたは複数のキャリアを選択し、それと共に他の無認可スペクトル展開との良好な共存を実現するために、構成または使用されてよい。

新無線（ＮＲ）におけるＷＴＲＵ動作
ＮＲにおいて、ＷＴＲＵは、キャリアにおける帯域幅パート（ＢＷＰ）を使用して動作することができる。例えば、ＷＴＲＵは、初期ＢＷＰを使用してセルに最初にアクセスすることができる。いくつかの例において、ＷＴＲＵは、手続きまたは動作を続行するためのＢＷＰのセットで構成されてよい。一定の代表的な実施形態において、任意の所与の瞬間に、ＷＴＲＵは、１つ（１）のアクティブなＢＷＰを有することができる。例において、各ＢＷＰは、スケジューリング、および／または他のプロセスもしくは手続きのために、その中でＷＴＲＵが１つまたは複数の物理ダウンリンク制御チャネル（ＰＤＣＣＨ）候補をブラインド復号することができるＣＯＲＥＳＥＴのセットで構成されてよい。

また、ＮＲは、可変の送信時間長およびフィードバックタイミングをサポートすることができる。いくつかの実施形態において、可変の送信時間長により、例えば、物理ダウンリンク共有チャネル（ＰＤＳＣＨ）または物理アップリンク共有チャネル（ＰＵＳＣＨ）送信は、スロットのシンボルの隣接したサブセットを占有することができる。いくつかの他の実施形態において、可変のフィードバックタイミングにより、ダウンリンク割り当てのためのダウンリンク制御情報（ＤＣＩ）は、ＷＴＲＵのためのフィードバックのタイミングについての表示を含むことができる。例において、表示は、固有の物理アップリンク制御チャネル（ＰＵＣＣＨ）リソースを示す、または指摘することができる。

いくつかの例において、ＮＲは、２つのタイプのＰＵＣＣＨリソース、すなわち、短いＰＵＣＣＨおよび長いＰＵＣＣＨをサポートすることができる。前者（短いＰＵＣＣＨ）は、１つまたは２つのＯＦＤＭシンボルを使用して送信されてよく、一方、後者（長いＰＵＣＣＨ）は、例えば、１４個までのＯＦＤＭシンボルを使用することができる。各ＰＵＣＣＨタイプは、対応するペイロードのタイプおよび／またはサイズに依存してよい多数のフォーマットを有することができる。

いくつかの実施形態において、ＮＲは、動的ＨＡＲＱ−ＡＣＫコードブックをサポートすることができ、ここで、ＨＡＲＱコードブックのサイズは、スケジュールされたトランスポートブロック（ＴＢ）の数に依存してよい。基地局（例えば、ｇＮＢ）は、ＤＣＩにおけるカウンタダウンリンク割り当てインデックス（ＤＡＩ）および／またはトータルＤＡＩを使用して、以前にスケジュールされたＴＢの数を示すことができる。いくつかの例において、カウンタＤＡＩおよび／またはトータルＤＡＩは、２ビットのサイズを有して、４つまでの見つからないまたは見逃されたＴＢを、ＷＴＲＵが取り戻すのを可能にすることができる。例えば、ＬＴＥおよび／またはＮＲにおいて、カウンタＤＡＩは、ＨＡＲＱ−ＡＣＫコードブック内で、ＴＢのＡ／Ｎビットのポジションを示すための（ＴＢをスケジュールするＤＣＩに含まれた）２ビットである。

無認可帯域におけるＷＴＲＵ動作
ＮＲは、ＮＲ無認可についての検討項目説明によれば、３ＧＰＰリリース１６において、１つまたは複数の無認可帯域における動作をサポートすることができる。例えば、参考文献を参照されたい。エラー！ 参考文献ソースは見当たらず。例において、無認可スペクトルにおけるＮＲベースの動作は、ＬＴＥ−ＬＡＡおよび他の現在作動中のＲＡＴとの共存方法と共に、初期アクセス、スケジューリング／ＨＡＲＱ、およびモビリティを含むことができる。いくつかのシナリオは、無認可スペクトルにおいて、ＬＴＥまたはＮＲアンカーセルに接続されたＮＲベースのＬＡＡセル、並びにスタンドアロンで動作するＮＲベースのセルを含むことができる。

ＮＲ無認可帯域のいくつかの例において、全ての送信は、チャネル取得方法（例えば、ＬＢＴ）により先行されてよい。正常なＬＢＴは、ＷＴＲＵが制御情報をｇＮＢに送信できるよりも前に、必要とされ得る。そのような制約は、ＬＴＥ無認可帯域においては適用されないことがあり、その理由は、ＬＴＥ無認可スペクトルでは、アップリンク制御送信が無認可帯域においてサポートされないことがあるからである。ＬＴＥ無認可において、アップリンク制御情報（ＵＣＩ）メッセージは、認可帯域において送られてよい。

図２を参照すると、いくつかの例において、ＮＲおよび／またはＬＴＥにおけるＨＡＲＱプロトコル設計が、クリアチャネルアセスメント（ＣＣＡ）を考えていないことがある。例えば、ｇＮＢがフィードバックのために構成された時間内にＨＡＲＱ−ＡＣＫフィードバックを受信しない場合、ｇＮＢは、（例えば、ＤＣＩにおいてスケジュールされた）ＴＢがＷＴＲＵによって受信されなかったこと、またはＡＣＫ−ｔｏ−ＤＴＸ／ＮＡＣＫ−ｔｏ−ＤＴＸエラーが発生したことを想定することができる。いくつかの事例において、ＷＴＲＵが構成された時間にチャネルにアクセスできることは保証されていないので、Ｋ₁値（例えば、ＨＡＲＱフィードバックタイミング限度）を構成することは、（例えば、ＮＲ無認可動作のために）好適ではないことがある。例えば、図２を参照して、Ｋ₁のＨＡＲＱフィードバックタイミングを示すサブフレーム２０２（サブフレームｎ）でＤＣＩが受信されたことを想定する。サブフレーム２０４（サブフレームｎ＋Ｋ₁）によってＨＡＲＱを返すためにＷＴＲＵがチャネルを使用できないように、チャネルがビジーであることもまた想定する。この事例において、ｇＮＢは、ＷＴＲＵがＴＢを受信しなかった、またはエラーが発生したことを想定することができる。

さらに、ＮＲは、動的ＨＡＲＱフィードバック（例えば、ＨＡＲＱ−ＡＣＫコードブック）を使用し、それによって、多数のＴＢの確認応答が１つのＵＣＩ送信において組み合わせられ得る。いくつかの例において、動的ＨＡＲＱフィードバックは、ＴＢがスケジュールされた時間に、および／またはＨＡＲＱ−ＡＣＫフィードバックが送られるように構成された時間に依拠して送信されてよい。ｇＮＢがＨＡＲＱ−ＡＣＫコードブックを適切に解釈するために、ＷＴＲＵとｇＮＢとの両方が、ＨＡＲＱ−ＡＣＫコードブックのサイズ（例えば、ビットの数）およびコードブック内の各ＨＡＲＱ ＡＣＫ／ＮＡＣＫビットの順序について同期される必要がある。ＮＲ ＷＴＲＵは、ＤＡＩを使用して、見逃されたＤＣＩの数を計算する。ＤＡＩは、ＮＲリリース１５において２ビットであり、４つまでの見逃されたＰＤＳＣＨの検出を可能にする。４つよりも多いＰＤＳＣＨが見逃された場合、ＷＴＲＵは、正しいＨＡＲＱ−ＡＣＫコードブックサイズを報告することができないことがある。ＮＲ無認可においては、他のセルおよび他のＲＡＴからの衝突を有することが予期されており、従って、見つからない４つよりも多いＰＤＳＣＨは可能性がある。

ＨＡＲＱフィードバック送信のための共有ＣＯＴについての代表的な手続き
いくつかの例において、ＣＯＴは、ネットワーク（例えば、ｇＮＢ）とＷＴＲＵとの間で共有および／または使用されてよい。ネットワーク（例えば、ｇＮＢ）は、ＷＴＲＵのためにＵＣＩを搬送するアップリンク制御チャネルまたはアップリンク共有チャネルを確保することができる。ＷＴＲＵは次いで、以下の条件のうちの１つまたは複数に基づいて、例えば、ＨＡＲＱ−ＡＣＫフィードバックを送信する前に、ＬＢＴを実施しないように構成されても、または短いＬＢＴを実施するように構成されてもよい。

一実施形態において、ＴＢをスケジュールするＰＤＣＣＨをスクランブルするために、ＲＮＴＩが使用されてよい。例において、ＷＴＲＵは、ＵＲＬＬＣサービスに固有のＲＮＴＩで構成されてよい。ＵＲＬＬＣ ＲＮＴＩによってスケジュールされた１つまたは複数のＴＢを受信すると、ＷＴＲＵは、ＬＢＴを実施することなく、または短いＬＢＴを実施して、ＨＡＲＱフィードバックを送信することができる。別の実施形態において、ＴＢをスケジュールするために、ＤＣＩフォーマットが使用されてもよい。例えば、ＷＴＲＵは、コンパクトＤＣＩで構成されてよい。そのようなＤＣＩを使用するスケジューリングを受信すると、ＷＴＲＵは、ＬＢＴを実施することなく、ＨＡＲＱ ＡＣＫ／ＮＡＣＫを送信することができる。

様々な実施形態において、ＷＴＲＵは、以下の条件または表示のうちの１つもしくは複数に基づいて、（例えば、ＨＡＲＱフィードバックを送信する前に）ＬＢＴを実施しないように構成されても、または短いＬＢＴを実施するように構成されてもよい。１）ＴＢをスケジュールするＤＣＩのアグリゲーションレベル、２）ＴＢをスケジュールするＤＣＩがそこで検出されたサーチスペース、３）ＴＢをスケジュールするＤＣＩがそこで検出されたＣＯＲＥＳＥＴ、４）ＰＵＣＣＨリソース表示。例えば、ＷＴＲＵは、ＬＢＴを実施することなく使用され得るＰＵＣＣＨリソースのセットで構成されてよい。そのようなリソースの構成は、半静的に構成されても、または動的に示されてもよい。５）ＨＡＲＱフィードバックコードブックサイズ。例えば、ＷＴＲＵは、ＨＡＲＱ−ＡＣＫコードブックのサイズが閾値を下回る場合に、ＬＢＴを実施しないように構成されてよい。６）ＨＡＲＱフィードバックタイミング。いくつかの例において、ｇＮＢからの暗黙的な表示が使用されてもよい。例において、ＰＤＳＣＨ／ＰＵＳＣＨのタイミング表示が使用されてもよい。例えば、ＨＡＲＱフィードバックタイミングがＫ_{1_thr}よりも少ない場合、ＬＢＴは実施されず、ここで、Ｋ_{1_thr}は、Ｋ₁について予め定義された閾値である。別の例において、ＷＴＲＵが閾値（例えば、Ｋ_{1_thr}）を上回るＨＡＲＱフィードバックタイミングで構成される場合、ＷＴＲＵは、ＨＡＲＱ ＡＣＫおよび／またはＨＡＲＱ ＮＡＣＫ送信に先立って、ＬＢＴ（例えば、全ＬＢＴ）を実施することができる。７）ＨＡＲＱプロセス識別子（ＩＤ）。例において、ＨＡＲＱプロセスは、上位レイヤ（例えば、ＭＡＣレイヤ）にまだ届けられていない（例えば、ＷＴＲＵにおけるバッファに記憶された）ＴＢと考えられてもよい。ＷＴＲＵは、それぞれのＨＡＲＱプロセスＩＤによって各々が識別され得る１つまたは複数のＨＡＲＱプロセスを維持することができる。ＨＡＲＱプロセスのためのＨＡＲＱフィードバック（例えば、ＨＡＲＱ ＡＣＫ／ＮＡＣＫフィードバック）は、ＨＡＲＱプロセスに関連付けられたＴＢの現在の復号状態（例えば、上位レイヤにまだ届けられていないＴＢ）を示すために使用されてよい。例えば、ＷＴＲＵは、ＬＢＴを実施することなく送信され得るＨＡＲＱプロセスＩＤのセットで構成されてよい。８）スロットフォーマット表示。例において、グループ共通ＤＣＩを使用する半静的構成または動的構成に基づいて、ＷＴＲＵは、ＨＡＲＱフィードバック送信に先立ってＬＢＴを実施しなくてもよい。いくつかの事例において、ＷＴＲＵは、自己収容スロットにおいてＬＢＴを実施しなくてもよい。および９）ＤＣＩにおける明示的なビット表示。

いくつかの例において、ＨＡＲＱ−ＡＣＫ送信は、別個のまたは異なるＣＯＴにあってよい。態様において、ＷＴＲＵは、ｇＮＢとＷＴＲＵとの間で次に続く共有ＣＯＴにおいてトランスポートブロック（ＴＢ）のＨＡＲＱ−ＡＣＫフィードバックを送信するように構成されてよい。ＷＴＲＵは、ＨＡＲＱ ＡＣＫ／ＮＡＣＫフィードバックが、１つまたは複数の次のＣＯＴで送信されてもよいこと、または送信されることになることを判定するように構成されてよい。図３Ａを参照すると、例えば、以下の実施形態または例のうちの１つまたは複数に基づいて、ＷＴＲＵは、第１のＣＯＴ（ＣＯＴ₁）において受信されたＴＢのＨＡＲＱ−ＡＣＫフィードバックが、１つまたは複数の次のＣＯＴ（例えば、図３Ａに示されるＣＯＴ₂および／またはＣＯＴ_N）において送信され得ることを判定することができる。

ＨＡＲＱ送信メカニズム３００について図３Ａをなおも参照すると、ＷＴＲＵは、ＨＡＲＱ−ＡＣＫフィードバックがそこで送信されるＣＯＴ番号、ＣＯＴインデックス、および／またはＣＯＴオフセットを示すＤＣＩにおける専用のビットフィールドに基づいて、第１のＣＯＴ（例えば、各々がスロット３０２として表現された１０のスロットを含むＣＯＴ₁）において受信されたＴＢのＨＡＲＱ−ＡＣＫフィードバックが、次のまたは進行中のＣＯＴ（例えば、各々がスロット３０４として表現された１０のスロットを含むＣＯＴ₂、および／または各々がスロット３０６として表現された１０のスロットを含むＣＯＴ_N）のうちの１つもしくは複数において送信され得ることを判定することができる。例えば、ＷＴＲＵは、ＤＣＩ３１０がそこで受信されたＣＯＴ（例えば、ＣＯＴ₁）においてＣＯＴオフセット表示を受信することがある。図３Ａに示される例において、ＷＴＲＵは、（例えば、１つまたは複数のＴＢをスケジュールするために）ＣＯＴ₁においてＤＣＩ３１０を受信し、ＤＣＩ３１０は、（例えば、スロット３０６にある）ＣＯＴ_Nなどのより後のＣＯＴにおいてＨＡＲＱフィードバックタイミングを示す。いくつかの例において、ＷＴＲＵは、（例えば、テーブルまたはリストにおける）「ＣＯＴオフセット」のセットを有するより高位のレイヤシグナリング（例えば、ＲＲＣシグナリング）を使用して構成されてよく、ＤＣＩビットフィールドは、構成された値のいくつか（例えば、テーブルまたはリストにおけるポジション）を指摘する。別の実施形態において、ＷＴＲＵは、例えば、ＣＯＴにつき一度のみ見出される特定の信号（例えば、ＣＯＴプリアンブル）の発生の数をカウントすることなどによって、自動的にＣＯＴインデックスの経過を追うことができる。別の例において、ＣＯＴインデックスが、進行中のＣＯＴのＣＯＴインデックスを明示的に示すｇＮＢからの信号の受信によって判定されてもよい。例えば、ＵＥは、ＣＯＴのインデックスを提供するＣＯＴ内のなんらかのポイントで（例えば、グループ共通チャネル上の）送信を予期することができる。

いくつかの実施形態において、ＷＴＲＵは、ＤＣＩおよび／またはＤＣＩにおいてＰＤＳＣＨ−ｔо−ＨＡＲＱタイミングインジケータを再使用することに基づいて、第１のＣＯＴ（ＣＯＴ₁）において受信されたＴＢのＨＡＲＱ−ＡＣＫフィードバックが、次のＣＯＴのうちの１つまたは複数において送信され得ることを判定することができる。図３Ｂを参照すると、テーブル３２０およびテーブル３３０が、異なるコードポイント、ＰＤＳＣＨ−ｔо−ＨＡＲＱタイミングインジケータ（Ｋ₁、Ｋ₂、Ｋ₃、およびＫ₄の値）、並びにユニット（例えば、スロット、ＣＯＴ、またはＣＯＴおよびスロット）のうちの１つまたは複数を含む。例において、図３Ｂのテーブル３２０に示されるように、ＰＤＳＣＨ−ｔо−ＨＡＲＱタイミングインジケータのサブセットが、スロットのユニットにおいて構成されてよく、ＰＤＳＣＨ−ｔо−ＨＡＲＱタイミングインジケータの別のサブセットが、「ｇＮＢ開始ＣＯＴ」のユニットにおいて構成されてよい。別の例において、図３Ｂのテーブル３３０に示されるように、（例えば、ＰＤＳＣＨ−ｔо−ＨＡＲＱタイミングインジケータにおける）ＰＤＳＣＨ−ｔо−ＨＡＲＱタイミングのセットが、ＣＯＴオフセットおよびＣＯＴ内のスロットを示すことができる。

いくつかの実施形態において、ＷＴＲＵは、再使用されている、ＰＤＳＣＨ時間ドメインリソースアロケーション、およびＤＣＩにおけるＰＤＳＣＨ−ｔо−ＨＡＲＱタイミングインジケータのうちのいずれかに基づいて、第１のＣＯＴ（ＣＯＴ₁）において受信されたＴＢのＨＡＲＱ−ＡＣＫフィードバックが、次のＣＯＴのうちの１つまたは複数において送信され得ることを判定することができる。例えば、ＣＯＴの最後の１つまたは複数のスロット（例えば、最後のＸスロット）におけるＰＤＳＣＨ時間ドメインリソースアロケーション、およびＫ_{1_thr}よりも大きい値を示すＰＤＳＣＨ−ｔо−ＨＡＲＱタイミングを受信すると、ＷＴＲＵは、ＨＡＲＱフィードバック（例えば、ＨＡＲＱ ＡＣＫ／ＮＡＣＫフィードバック）が、次のｇＮＢ開始ＣＯＴにおいて送信されることになることを判定することができる。例において、ＷＴＲＵは、次のまたは今後のＣＯＴのスターティングスロットから、ＰＤＳＣＨ−ｔо−ＨＡＲＱタイミングを適用することができる。例えば、ＷＴＲＵは、４スロットのＰＤＳＣＨ−ｔо−ＨＡＲＱタイミング値を受信することができる。ＷＴＲＵは、次のＣＯＴのスタートの後に、ＨＡＲＱフィードバック４スロットを送信することができる。別の例において、ＷＴＲＵは、ＰＤＳＣＨ時間ドメインリソースアロケーションおよびＰＤＳＣＨ−ｔо−ＨＡＲＱタイミングインジケータにおけるＫ₀値の和に等しいスロット番号を有するスロットの次のＣＯＴにおいて、ＨＡＲＱフィードバックを送信するように構成されてもよい。いくつかの事例において、ＸおよびＫ_{1_thr}の値は、より高位のレイヤシグナリング（例えば、ＳＩＢ／ＲＲＣ固有のシグナリング）を使用して構成されても、または標準で固定されていてもよい。例において、ＷＴＲＵは、ＣＯＴインデックス（例えば、ＰＤＳＣＨのために使用されたＣＯＴからの１つまたは複数のオフセットを含むインデックス）と、ＨＡＲＱフィードバック送信のためのＣＯＴ内の１つまたは複数のスロットとを示す、ＰＤＳＣＨ−ｔо−ＨＡＲＱタイミング値を受信することができる。

いくつかの実施形態において、ＷＴＲＵは、少なくとも、ＤＣＩ送信のために使用されたサーチスペースおよび／またはＣＯＲＥＳＥＴに基づいて、第１のＣＯＴ（ＣＯＴ₁）において受信されたＴＢのＨＡＲＱ−ＡＣＫフィードバックが、次のＣＯＴのうちの１つまたは複数において送信され得ることを判定することができる。例えば、ＷＴＲＵは、それらのサーチスペースセットおよび／またはＣＯＲＥＳＥＴによってスケジュールされたＴＢに関係付けられたＨＡＲＱフィードバックが次のＣＯＴにおいて送られ得る、サーチスペースおよび／またはＣＯＲＥＳＥＴのセットで構成されてよい。ＷＴＲＵは、次のＣＯＴ内のＰＤＳＣＨ−ｔо−ＨＡＲＱタイミングインジケータによって示されたスロット番号で、または、次のＣＯＴ内のＰＤＳＣＨ時間ドメインリソースアロケーションおよびＰＤＳＣＨ−ｔо−ＨＡＲＱタイミングインジケータにおけるＫ₀値の和に等しいスロット番号で、ＨＡＲＱフィードバックを送信するように構成されてよい。

例において、ＣＯＴは、ＷＴＲＵのための固定された時間長（図３Ａに示されるように、ＣＯＴは１０スロットの時間長を有する）で、ネットワーク（例えば、ｇＮＢ）によって構成されてよい。別の例において、ＣＯＴ時間長は、１つのチャネル占有期間から別のチャネル占有期間に変化してもよい。いくつかの例において、ＷＴＲＵは、以下の要因のうちの１つまたは複数に基づいて、ＣＯＴまたは各ＣＯＴの時間長を判定するように構成されてよい。

いくつかの実施形態において、ＷＴＲＵは、スロットフォーマット表示に基づいて、１つのまたは各ＣＯＴの時間長を判定するように構成されてよい。例えば、ＷＴＲＵは、各ＣＯＴの冒頭でスロットフォーマット表示を受信するように構成されてよい。スロットフォーマット表示に示されたスロットフォーマットに基づいて、ＷＴＲＵは、ＤＬに、フレキシブルに、およびＵＬに割り当てられたスロットおよび／またはシンボルの数を判定し、現在のＣＯＴ時間長を判定することができる。さらに、ＷＴＲＵは、スロットフォーマットとＣＯＴ時間長との間のマッピングルールまたはインデックスで構成されてもよい。

いくつかの実施形態において、ＷＴＲＵは、サーチスペース周期性構成に基づいて、１つのまたは各ＣＯＴの時間長を判定するように構成されてよい。例えば、ＷＴＲＵは、サーチスペース周期性および／または時間長構成に基づいて、ＣＯＴ時間長を判定するように構成されてよい。一実装において、ＷＴＲＵは、構成されたサーチスペースセットの最大周期性および／または時間長に基づいて、ＣＯＴ時間長を判定することができる。

いくつかの実施形態において、ＷＴＲＵは、１つまたは複数のプリアンブル送信に基づいて、１つのまたは各ＣＯＴの時間長を判定するように構成されてよい。例えば、ＷＴＲＵは、異なるシーケンスおよび／または長さを有するプリアンブルのセットをモニタするように構成されてよい。固有のシーケンスまたは長さを有するプリアンブルを検出すると、ＷＴＲＵは、ｇＮＢ開始ＣＯＴの時間長を判定することができる。いくつかの事例において、ＷＴＲＵは、ＣＯＴ時間長とプリアンブルとの間のマッピングルールまたはインデックスで構成されてよい。

多数のＴＢのＨＡＲＱ−ＡＣＫフィードバックを組み合わせるための代表的な手続き
ＨＡＲＱ−ＡＣＫコードブック判定についてのいくつかの例において、ＷＴＲＵは、１つのＨＡＲＱ−ＡＣＫコードブックにおけるフィードバック送信時間に先立って、全ての受信されたＴＢについてのＡＣＫ／ＮＡＣＫ（Ａ／Ｎ）フィードバックを送信するように構成されてよい。ＷＴＲＵは、コードブックによって搬送されたＨＡＲＱプロセスＩＤおよび／またはＨＡＲＱプロセスＩＤの数を示すために、ＨＡＲＱ−ＡＣＫコードブックと共に追加の情報を送信することができる。いくつかの事例において、ＨＡＲＱプロセスＩＤの数は、確認応答されたＴＢの数（または受信されたＴＢの数）に等しくてよい。いくつかの実施形態において、追加の情報は、以下のうちのいずれかを含むことができる。１）コードブックにおいて確認応答された最初のＴＢの受信された時間。例えば、コードブックにおける最初のＡ／Ｎのスロット番号および／またはサブフレーム番号、２）コードブックにおいて確認応答された最後のＴＢの受信された時間、３）ＨＡＲＱフィードバックにおいて確認応答されたＴＢの数、および４）ＨＡＲＱ−ＡＣＫフィードバックにおいて送信されたＨＡＲＱプロセスＩＤの表示。例えば、ＷＴＲＵは、ＨＡＲＱ−ＡＣＫコードブック内で送信され得るＨＡＲＱプロセスＩＤのセットで構成されてよい。例において、１６のＨＡＲＱプロセスＩＤのうちの８つが、１つのコードブックにおいて送信されてよく、一方、残りの８つのＨＡＲＱプロセスＩＤは、異なるＨＡＲＱコードブックにおいて送信されてよい。いくつかの事例において、ＨＡＲＱプロセスＩＤは、ＨＡＲＱプロセスを識別する。あるいは、ＷＴＲＵは、フィードバックにおいて送信されたＨＡＲＱプロセスＩＤのサブセットを示すビットマップを送信することができる。

いくつかの実施形態において、ＷＴＲＵは、ＨＡＲＱコードブック送信に先立って予め構成された時間ウィンドウにおいて受信されたＴＢのＡ／Ｎフィードバックを除外するように構成されてよい。例えば、ＷＴＲＵは、ＨＡＲＱフィードバック送信に先行する最後のサブフレームにおいて受信されたＴＢを処理できないことがあり、従って、最後のＴＢのＡ／Ｎを送信しない。

いくつかの実施形態において、ＷＴＲＵは、スケジュールされたＴＢの数、およびＨＡＲＱ−ＡＣＫコードブック内のＡ／Ｎビットのシーケンスを判定するために、カウンタＤＡＩおよび／またはトータルＤＡＩで構成されてよい。ＷＴＲＵは、見つからないＤＣＩを検出すると、誤検出時間に先立って受信されたＴＢのみでＨＡＲＱ−ＡＣＫコードブックを送信することができる。例えば、図４に示されるように、ＷＴＲＵは、サブフレーム４０２（例えば、サブフレームｎ）において第１のＴＢを、およびサブフレーム４０４（例えば、サブフレームｎ＋３）において第２のＴＢを、カウンタＤＡＩ ｃ＝０およびｃ＝１で、それぞれスケジュールする２つのＤＣＩを受信する。ＷＴＲＵは、サブフレーム４０８（例えば、サブフレームｎ＋１０）において、カウンタＤＡＩ ｃ＝３でＴＢをスケジュールするＤＣＩを受信する。ＷＴＲＵは、少なくとも１つのＤＣＩが見つからないことを判定し、サブフレーム４０２におけるＴＢ、およびサブフレーム４０４におけるＴＢ（ＴＢ₁およびＴＢ₂）のみについて、ＨＡＲＱ−ＡＣＫフィードバックを報告する。例において、見逃されたＤＣＩは、サブフレーム４０６（例えば、サブフレームｎ＋６）においてＴＢをスケジュールしている。

ＨＡＲＱ ＡＣＫコードブック蓄積の場合、いくつかの例において、ＷＴＲＵは、ＴＢの１つまたはセットについてＨＡＲＱ−ＡＣＫフィードバックを送信するためのチャネルを取得できないことがある。この事例において、ＷＴＲＵは、今後のＨＡＲＱ−ＡＣＫフィードバックリソースにおいて、そのコードブックのためのＨＡＲＱ−ＡＣＫフィードバックを送信することができる。失敗したＨＡＲＱ−ＡＣＫフィードバックリソースと今後のリソースとの時間の間に、ＷＴＲＵは、さらなるＰＤＳＣＨ送信のためにスケジュールされてよい。ＷＴＲＵは、以前のフィードバックされていないＴＢについてのＨＡＲＱ−ＡＣＫビットを、新しいコードブックにおける新しいＴＢについてのＨＡＲＱ ＡＣＫビットと組み合わせることができる。例において、ビットの２つのセットは、同じフィードバック報告において（例えば、別々に符号化された）２つの別個のコードブックとして対処されてよい。別の例において、ビットの２つのセットは、単一の、より大きなコードブックとして考えられてもよい。ＷＴＲＵは、報告に含まれるコードブックのトータル数（または報告に含まれるＴＢセットのトータル数、または報告に含まれる組み合わせられたＨＡＲＱ−ＡＣＫフィードバック報告セットの数）の表示を、フィードバック報告において提供することができる。

いくつかの例において、ＷＴＲＵは、周期的なＨＡＲＱ−ＡＣＫフィードバックリソースを提供されてよい。ＷＴＲＵは、周期的なＨＡＲＱ−ＡＣＫフィードバックリソースを使用して、ＷＴＲＵがまだフィードバックを送信していないＴＢのセットについてのフィードバックビットのセットを送信することができる。コードブックサイズは、フィードバック報告するために失敗したチャネルアクセスのたびに増加してよい。ＷＴＲＵは、それが動的に示されたＨＡＲＱ−ＡＣＫフィードバックリソースにおいてＨＡＲＱ−ＡＣＫを送信できなかった場合に、そのような周期的なＨＡＲＱ−ＡＣＫリソースを、フォールバックとして使用することができる。

蓄積は、異なる無認可チャネルにおいて送信されたＴＢのフィードバックについて行われてよい（ここで、無認可チャネルは、ＬＢＴプロセスで取得され得る無認可キャリアの部分として定義される）。例えば、ＷＴＲＵは、第１の無認可チャネルにおいて多数のＴＢを受信することができ、同じチャネルにおいてＨＡＲＱ−ＡＣＫをフィードバックするように予期されてよい。しかしながら、ＷＴＲＵは、ＨＡＲＱ−ＡＣＫフィードバックのためにチャネルを取得できないことがある。ＷＴＲＵはその場合、第２の無認可チャネルにおいてスケジュールされてよく、その第２のチャネルにおいてフィードバックを報告することができる。第２の無認可チャネルにおけるフィードバック報告は、（第１および第２の無認可チャネルにおいて、それぞれ、ＷＴＲＵによって受信された）ＴＢの第１および第２のセットの両方についての蓄積されたフィードバックを含むことができる。

いくつかの実施形態において、ＷＴＲＵは、その間にＴＢのＡ／Ｎフィードバックがネットワークに送られるべき時間期間ｔ₁で構成されてよい。時間期間ｔ₁は、ＴＢが受信された時間からのオフセットとして、またはＴＢをスケジュールするＤＣＩが受信された時間からのオフセットとして定義されてよい。そのような時間期間は、半静的に、または動的に構成されてよい。

あるいは、ＷＴＲＵは、可能なＨＡＲＱ−ＡＣＫ送信のための時間のセット｛ｋ₁，₁，ｋ₁，₂，…ｋ₁，_N｝で構成されてもよい。例えば、ＷＴＲＵは、サブフレームｎにおいてＴＢをスケジュールするＤＣＩを受信し、そのＴＢのＨＡＲＱ−ＡＣＫフィードバックが、ＬＢＴ結果に応じて、サブフレームｎ＋ｋ₁，₁，ｎ＋ｋ₁，₂，…ｎ＋ｋ₁，_Nのいずれかにおいて送信され得る。時間のセットは、半静的にまたは動的に構成されてよい。

別の実施形態において、ＷＴＲＵは、ＨＡＲＱ−ＡＣＫ送信のためのタイミングおよびタイマで構成されてもよい。例えば、ＷＴＲＵは、構成された時間においてＨＡＲＱ−ＡＣＫフィードバックを送信することに失敗すると、タイマをスタートすることができる。タイマが満了すると、ＷＴＲＵは、ＨＡＲＱ−ＡＣＫフィードバックを再送信するように試行する。ＨＡＲＱ−ＡＣＫフィードバックを送信するための時間およびタイマについての値は、より高位のレイヤシグナリングを使用して構成されてもよいし、または動的に示されてもよい。タイマが稼働している間、ＷＴＲＵは、ネットワークからタイミング更新を受信することができる。タイマを用いる別の実施形態において、構成されたタイマが稼働している間、ＷＴＲＵは、ＨＡＲＱ−ＡＣＫを送るように試行することができる。タイマが満了すると、ＷＴＲＵは、ＨＡＲＱ−ＡＣＫを送ることに先立って、再送信のためのＰＤＣＣＨ、またはｇＮＢからのＨＡＲＱ−ＡＣＫトリガ信号をモニタすることができる。ＷＴＲＵはさらに、タイマへの値を調整または追加することができる。例えば、ＷＴＲＵは、チャネルがビジーだった、またはサービングセルによって占有されていたことを判定すると、タイマを延長することができる。

いくつかの例において、ＨＡＲＱ−ＡＣＫコードブックを送信するためのトリガが使用されてよい。ＷＴＲＵは、トリガのうちの１つまたは複数に応答して（例えば、受信して、または識別して）、ＨＡＲＱ−ＡＣＫフィードバックを送信するように構成されてよい。１つまたは複数のトリガは、閾値を上回る受信されたＰＤＳＣＨの数を含むことができる。例えば、ＷＴＲＵは、Ｎ個のＰＤＳＣＨを受信した後に、全ての受信されたＰＤＳＣＨのためのＨＡＲＱ−ＡＣＫフィードバックを送信するように構成されてよい。１つまたは複数のトリガは、Ｎスロットおよび／もしくはＫ_Nシンボル、並びにＮ’スロットおよび／もしくはＫ’_Nシンボルまでが、送信または受信されているという判定を含むことができる。１つまたは複数のトリガは、ダウンリンクからアップリンクへのスイッチングポイントの数を含むことができる。例えば、ＷＴＲＵは、Ｍ＝１スイッチングポイントの後に、例えば、ダウンリンクからアップリンクへのスイッチがあるたびに、ＨＡＲＱ−ＡＣＫを送信するように構成されてよい。いくつかの事例において、１つまたは複数のトリガは、ＨＡＲＱプロセスのセットを示すダウンリンク制御シグナリングが受信されているという判定を含むことができる。１つまたは複数のトリガは、以前のＨＡＲＱ−ＡＣＫリソースにおけるＨＡＲＱ−ＡＣＫコードブックの送信の失敗が発生したという判定を含むことができる。例えば、ＨＡＲＱ−ＡＣＫコードブックの送信の失敗は、ＷＴＲＵが以前のＨＡＲＱ−ＡＣＫリソースにおいてチャネルを取得できなかったことであってもよい。別の例において、ＷＴＲＵは、（例えば、フィードバック報告するための１つまたは複数の以前に失敗したチャネルアクセスに起因して）以前のＨＡＲＱ−ＡＣＫリソースにおいて閾値数よりも多いフィードバックビットを蓄積することがあり、ＷＴＲＵは、ＨＡＲＱ−ＡＣＫコードブックを１つのＨＡＲＱ−ＡＣＫリソースにおいて送信することができないので、ＷＴＲＵは、フィードバック報告を、異なるＨＡＲＱ−ＡＣＫリソースにおいて各々送信されるように、多数の報告にセグメント化する。

様々な実施形態において、ＷＴＲＵは、ＨＡＲＱプロセスのためのフィードバック値を記憶または維持することができる。例えば、ＷＴＲＵは、該当したＨＡＲＱプロセスのための新データインスタンス（ＮＤＩ）を受信した後に、ＨＡＲＱプロセスのためのフィードバック値をさらに記憶または維持することができる。ＷＴＲＵは、場合により、ネットワークからＨＡＲＱ−ＡＣＫを送信するためのトリガを受信すると、同じＨＡＲＱプロセスＩＤで既に送信されたいくつかのＴＢについて集約したフィードバックを提供することができる。

ＨＡＲＱ−ＡＣＫ情報の再送信についての代表的な手続き
いくつかの実施形態において、ＷＴＲＵは、第１のリソース（ＰＵＣＣＨまたはＰＵＳＣＨ）に、および第１の時間インスタンスに含まれるように元々スケジュールされたＨＡＲＱ−ＡＣＫ情報を、第２のリソース（ＰＵＣＣＨまたはＰＵＳＣＨ）において、および第２の時間インスタンスにおいて送信することができる。そのようなソリューションは、第１のリソースおよび時間インスタンスでの送信が、ＬＢＴ失敗に起因して行われ得なかった場合に有用であることがある。より広くは、ソリューションはまた、固有のインスタンスについてのＨＡＲＱ−ＡＣＫ情報が正常に受信されなかったことをネットワークが検出するときにはいつでも有用であってよい。

ＨＡＲＱ−ＡＣＫ情報の再送信をサポートするために、ＷＴＲＵは、コードブックプロセス（またはコードブックプロセスアイデンティティ）を、ダウンリンク送信のセットに対応するＨＡＲＱ−ＡＣＫフィードバックビットのセットに関連付けることができる。例において、コードブックプロセスは、１つまたは複数のＨＡＲＱプロセスのためのＨＡＲＱ−ＡＣＫフィードバックのセットであってよく、各ＨＡＲＱ−ＡＣＫフィードバックは、ＴＢにつき少なくとも１つのビットに関連付けられている。ＷＴＲＵは、同じコードブックプロセスのために、場合により、ダウンリンク送信の異なるセットのために、それがＨＡＲＱ−ＡＣＫビットの新しいセットを生成するまで、コードブックプロセスのＨＡＲＱ−ＡＣＫビットのセットをメモリに保持することができる。ＷＴＲＵは、リソースにおいて少なくとも１つのコードブックプロセスのＨＡＲＱ−ＡＣＫビットを含むようにスケジュールされてよい。上のステップを容易にするためのソリューションが、以下で説明される。コードブックプロセスの数は、予め決められていても、またはより高位のレイヤによって構成されてもよい。

ＤＬ送信のＨＡＲＱ−ＡＣＫのためのコードブックプロセスの判定についてのいくつかの例が、本明細書で提供される。ＤＬ送信のためのＨＡＲＱ−ＡＣＫを生成するとき、例えば、ＷＴＲＵは、以下のソリューションのうちの少なくとも１つに基づいて、対応するコードブックプロセスを入手することができる。

例において、コードブックプロセスは、新しいまたは既存のフィールドを使用してＤＬ送信をスケジュールするＤＣＩにおいて明示的に識別されてよい。例えば、ＰＵＣＣＨリソースインジケータフィールドの、またはＰＤＳＣＨ−ｔо−ＨＡＲＱフィードバックタイミングインジケータフィールドの各コードポイントが、フィールドの既存の解釈通りの他の情報に加えて、固有のプロセスインデックスに関連付けられてよい。

様々な実施形態において、コードブックプロセスは、ＤＬ送信の以下の特性のうちのいずれかによって暗黙的に識別されてもよい。１）例えば、送信がスタートする、またはストップするときの、サブフレーム番号、スロット番号、またはシンボルインデックスに関するＤＬ送信のタイミング、２）帯域幅パート（ＢＷＰ）インデックス、３）キャリアまたはサービングセルインデックス、および４）場合により、ＤＬ送信のＤＣＩに含まれる情報に基づいて、ＨＡＲＱ−ＡＣＫがその中に含まれることになるＵＬ送信（またはリソース）のタイミング。そのようなタイミングは、サブフレーム番号、スロット番号、および／またはシンボルインデックスのうちのいずれかに関してであってよい。

一実施形態において、１つまたは複数のコードブックプロセスは、ＤＬ送信に関連付けられた送信プロファイル、またはパラメータのセットによって識別されてよい。各ＤＬ送信は、送信プロファイルに関連付けられても、または送信プロファイルによってパラメータ化されてもよい。送信プロファイルは、優先度要件、レイテンシ要件、ブロックエラーレート（ＢＬＥＲ）要件、送信電力要件、冗長要件、繰り返し要件、およびＬＢＴカテゴリ要件のうちのいずれかによって判定されてもよいし、またはそれらのうちのいずれかを示してもよい。例において、ＷＴＲＵは、多数の異なるコードブックプロセスを維持することができ、各コードブックプロセスは、（例えば、ｅＭＢＢまたはＵＲＬＬＣなどのサービスタイプに関連付けられた）それぞれの送信プロファイルに関連付けられてよい。いくつかの事例において、各々異なる送信プロファイル（および異なる対応するコードブックプロセス）を有する異なる変形が、ＵＲＬＬＣのために使用されてもよい。別の実施形態において、１つまたは複数のコードブックプロセスは、ＤＬ送信の優先度などの、ＤＬ送信のパラメータによって識別されてもよい。例えば、ＷＴＲＵは、ＤＬ送信のパラメータに基づいて、優先度を判定することができる。別の例において、優先度は、ＤＬ送信をスケジュールするＤＣＩにおける優先度表示に基づいて判定されてもよい。

コードブックプロセスは、ＨＡＲＱ−ＡＣＫがその中に含まれることになるＵＬリソースおよび／または時間インスタンスに基づいて、暗黙的に識別されてもよい。例えば、ＷＴＲＵは、現在のコードブックプロセスインデックスを維持し、新しい時間インスタンスおよび／またはリソースがＨＡＲＱ−ＡＣＫの送信のために示されたときに、プロセスインデックスを循環させる（例えば、コードブックプロセスの数を法としてインクリメントする）ことができる。場合により、現在のプロセスインデックスは、新しい時間インスタンスおよび／またはリソースを示すＤＣＩにおけるフィールドが固有の値に設定される場合にのみ、インクリメントされる。例えば、新しいフィールド「ＨＡＲＱ−ＡＣＫ再送信」がＤＣＩに含まれることがあり、そのようなフィールドがゼロに設定される場合にのみ、ＷＴＲＵは、コードブックプロセスをインクリメントすることになる。

一実施形態において、コードブックプロセスインデックスは、示されたＰＵＣＣＨリソースインデックスの関数として判定されてよい。別の実施形態において、コードブックプロセスインデックスは、それぞれのＤＬ送信に関連付けられた、送信プロファイルおよび／または優先度の関数として判定されてもよい。例えば、コードブックプロセスインデックスの異なるセットが、異なる優先度の送信のために確保されてよい。ＷＴＲＵが固有の優先度のＤＬ送信でスケジュールされ、新しいコードブックプロセスインデックスが求められていることを判定するとき、ＷＴＲＵは、固有の優先度を有する送信のための最も低い（または最も高い）利用可能なインデックス値を使用することができる。別の例において、ＷＴＲＵは、より高い優先度を有するデータのために新しいコードブックプロセスを構築するように求められると、既存のコードブックプロセスの全てのコードブックプロセスインデックス値をシフトさせることができる。

いくつかの例において、リソース上で送信されたＨＡＲＱ−ＡＣＫのコードブックプロセスが、識別または判定されてよい。ＰＵＣＣＨまたはＰＵＳＣＨリソース上でＨＡＲＱ−ＡＣＫ情報を送信するとき、ＷＴＲＵは、以下のソリューションのうちの少なくとも１つにつき、少なくとも１つのコードブックプロセスのＨＡＲＱ−ＡＣＫを含むことができる。

例において、コードブックプロセスのセットは、リソースを示すＤＣＩにおいて明示的に示されてよい。例えば、ＰＵＣＣＨリソースを示すＤＣＩにおけるフィールドが、ＨＡＲＱ−ＡＣＫ情報が含まれることになるコードブックプロセスのインデックスを示すことができる。そのようなフィールドは、ＰＵＣＣＨリソースインジケータなどの既存のフィールド、または新しく定義されるフィールドに対応してよい。

そのような表示は、絶対インデックスであってもよいし、現在のプロセスインデックスに相対的であってもよい。例えば、ゼロ（０）の値が、現在のプロセスインデックスに対応してよく、１（１）の値が、プロセスの数を法として以前のプロセスインデックス（Ｃ−１）に対応してよい、などである。別の例において、フィールドの各コードポイントが、予め定義されたマッピングに基づいて、またはより高位のレイヤシグナリングに基づいて、コードブックプロセスのサブセットを示してもよい。例えば、２つのコードブックプロセスが構成される場合、第１のコードポイントは、現在のプロセスインデックスに対応してよく、第２のコードポイントは、両方のプロセスに対応してよく、第３のコードポイントは、以前のプロセスインデックスに対応してよく、第４のコードポイントは、いずれのプロセスにも対応しなくてよい。後者の事例においては、いずれのＨＡＲＱ−ＡＣＫ情報も含まれないことがあり、ＰＵＣＣＨ送信は実施されないことがある。

別の例において、ＤＣＩにおけるフィールドが、ＨＡＲＱ−ＡＣＫ情報が含まれることになるプロセスの数、Ｎを示すことができる。この事例において、プロセスのセットは、（プロセスの数を法として）｛Ｃ−Ｎ＋１，Ｃ−Ｎ＋２，…，Ｃ｝に対応してよく、ここで、Ｃは、現在のプロセスインデックスである。

例において、コードブックプロセスは、リソースを示すＤＣＩにおいて暗黙的に示されてもよい。例えば、ＤＣＩがＤＬ割り当てに対応する場合、（例えば、上の段落において説明されたソリューションを使用して判定された）対応するＨＡＲＱ−ＡＣＫのためのコードブックプロセスは、ＨＡＲＱ−ＡＣＫフィードバックに割り当てられた特定のリソースによって暗黙的に示されてもよい。いくつかの事例において、リソースに含まれることになるＨＡＲＱ−ＡＣＫビットは、ＤＣＩによって示されたＤＬ割り当てについての１つまたは複数のＨＡＲＱ−ＡＣＫビットを含むことができる。この事例において、ＤＣＩの別のフィールドを使用して、コードブックプロセスを明示的に示す必要はなくてよい。

ＰＵＣＣＨリソースが１つよりも多いＤＣＩによって示される事例において、含まれることになるコードブックプロセスは、最後に受信されたＤＣＩに対応してよい。

一実施形態において、コードブックプロセスのセットは、ＤＣＩフォーマットに依存してよい。例えば、ＤＬ割り当てなしに、ＰＵＣＣＨリソースの表示を収容する新しいＤＣＩフォーマットが定義されてもよい。このＤＣＩフォーマットが受信されるとき、ＷＴＲＵは、そのようなフォーマットにおいて明示的に示されたコードブックプロセスのセットのＨＡＲＱ−ＡＣＫを含むことができる。ＤＬ送信が受信されていることをＤＣＩフォーマットが示す事例においては、ＷＴＲＵは、ＤＬ送信に対応するコードブックプロセスのＨＡＲＱ−ＡＣＫ情報を含むことができる。

一実施形態において、ＷＴＲＵは、ＨＡＲＱ−ＡＣＫがリソースに含まれるコードブックプロセスのセットを示すために、少なくとも１つのコードブックプロセスインデックスを、ＰＵＣＣＨまたはＰＵＳＣＨリソースに含むことができる。このソリューションは、例えば、リソースを動的にスケジュールするＤＣＩが存在しないときに使用されてよい。

いくつかの実施形態において、ＷＴＲＵは、ネットワーク（例えば、ｇＮＢ）から受信された単発のＨＡＲＱフィードバック要求に基づいて、コードブックプロセスビットを調整するように構成されてよい。単発のＨＡＲＱフィードバックは、ネットワークからの要求を受信すると、ＷＴＲＵが全てのＡＣＫ／ＮＡＣＫビット（またはＡＣＫ／ＮＡＣＫビットのセット／グループ）を送信することとして定義されてよい。ＷＴＲＵは、単発のＨＡＲＱフィードバック特徴だけでなく、コードブックプロセス特徴も同時にサポートするように構成されてよい。ＷＴＲＵは次いで、単発のＨＡＲＱフィードバック要求をモニタすることに加えて、コードブックプロセス上で多数のＨＡＲＱフィードバックをグループ化する。例において、ＷＴＲＵは、単発のＨＡＲＱフィードバックを送信した後に、全てのコードブックプロセスを消去するように構成されてよい。別の例において、ＷＴＲＵは、単発のＨＡＲＱフィードバックを送信することに先立って、Ｘｍｓ（またはそれ以上）に受信されたＴＢに対応するコードブックプロセスのＡＣＫ／ＮＡＣＫビットを取り除くように構成されてもよい。例において、ＷＴＲＵは、（例えば、ネットワークからの表示に基づいて）、コードブックプロセスから、単発のＨＡＲＱフィードバック（例えば、正常なＬＢＴの後に送信された単発のＨＡＲＱフィードバック）の一部であったＴＢのＡＣＫ／ＮＡＣＫを取り除くように、例えば、もっぱら取り除くように構成されてよい。あるいは、ＷＴＲＵは、単発のＨＡＲＱフィードバックが送信されたか否かにかかわらず、コードブックプロセスのＡＣＫ／ＮＡＣＫビットを保持するように構成されてもよい。

ＨＡＲＱ−ＡＣＫリソース判定についての代表的な手続き
図５および図６を参照すると、いくつかの例において、多数のＨＡＲＱ−ＡＣＫフィードバックリソースが、使用または構成されてよい。低減されたＨＡＲＱ Ａ／Ｎ送信機会に対処するために、ＷＴＲＵは、ＨＡＲＱ−ＡＣＫ送信のための多数のＰＵＣＣＨリソースを提供されてよい。ＷＴＲＵは、以下のうちの１つまたは複数に基づいて、多数のＰＵＣＣＨリソースから１つのＰＵＣＣＨリソースを選択するように構成されてよい。

第１の例は、ＬＢＴの結果である。例えば、ＷＴＲＵは、ＬＢＴの成功または失敗に基づいて、ＰＵＣＣＨリソースを判定することができる。図５を参照すると、例において、ＷＴＲＵは、多数のＰＵＣＣＨリソースセット（例えば、ＰＵＣＣＨリソースセット５０２、ＰＵＣＣＨリソースセット５０４、およびＰＵＣＣＨリソースセット５０６）で構成されてよく、ここで、各リソースセットは、ｎ番目のチャネルアクセス試行に適用可能である。例えば、ＨＡＲＱフィードバックを送信するように最初に試行するとき、ＷＴＲＵは、第１のＰＵＣＣＨリソースセット５０２を選択し、ＤＣＩ５０８における確認応答リソースインジケータ（ＡＲＩ）に基づいて、ＷＴＲＵは、リソースセット５０２内でリソースを判定する。いくつかの事例において、ＷＴＲＵが選択されたリソースにおいてチャネルにアクセスすることに失敗した場合、ＷＴＲＵは、（例えば、ＤＣＩ５１０における）ＡＲＩに基づいて、第２のＰＵＣＣＨリソースセット５０４から、リソースを選択することができる。図６に例証された別の例において、ＰＵＣＣＨリソースセット６０２から選択するとき、ＷＴＲＵは、（例えば、ＤＣＩ６０６および／またはＤＣＩ６０４において受信された）ＡＲＩに追加されることになる（例えば、ＤＣＩ６０４における）オフセットで構成されてよい。ＬＢＴ失敗の場合のオフセットおよび／またはＰＵＣＣＨリソースセット構成は、半静的に構成されても、または動的に示されてもよい。例えば、（例えば、ＤＣＩ６０６におけるＡＲＩに基づいて）ＨＡＲＱフィードバックを送信することに失敗した後に、ＷＴＲＵは、ＤＣＩ（例えば、ＤＣＩ６０４）においてオフセット表示を、またはリソースセット表示を受信することができる。

第２の例は、ランダム化である。例えば、ＷＴＲＵは、ＰＵＣＣＨリソースセットから、ランダムにリソースを選択するように構成されてよい。そのような事例において、ネットワークは、どのＷＴＲＵがフィードバックを送信しているかを知らないことがある。この問題を解決するために、ＷＴＲＵは、フィードバックと共に、ＷＴＲＵのアイデンティティをネットワークに示すように構成されてもよい。例えば、ＷＴＲＵは、Ｃｅｌｌ ＲＮＴＩ（Ｃ−ＲＮＴＩ）でスクランブルされた巡回冗長検査（ＣＲＣ）を、ＨＡＲＱ−ＡＣＫコードブックにアタッチすることができる。

第３の例は、ＤＣＩ誤検出である。例えば、ＷＴＲＵは、ＤＣＩが見つからないかどうかに基づいて、ＵＣＩリソースを選択することがある。例えば、ＷＴＲＵは、ＤＣＩ誤検出に先立つＴＢについてのみ、ＨＡＲＱ−ＡＣＫフィードバックを送信するように構成されてよい。そのような事例において、ＷＴＲＵは、それが正しくＤＣＩを検出するときと比較して、ＨＡＲＱ−ＡＣＫのために、異なるＰＵＣＣＨリソースセットおよび／またはＰＵＣＣＨリソースセット内の異なるリソースを使用することができる。

第４の例は、ＰＵＣＣＨトリガ信号の受信時である。ＰＵＣＣＨトリガ信号は、例えば、ＰＤＣＣＨを受信することに基づいていてよい。ＰＵＣＣＨトリガ信号は、場合により、一定のＬＢＴ要件で、またはＬＢＴのなしに、一定のＰＵＣＣＨリソースの利用可能性をＷＴＲＵにさらに示すことができる。

様々な実施形態において、ＷＴＲＵは、ＰＵＳＣＨリソース上でＨＡＲＱフィードバックを送信するように構成されてよい。例えば、ＷＴＲＵは、失敗したＰＵＣＣＨ送信からのＨＡＲＱ−ＡＣＫコードブックを、次のＰＵＳＣＨ機会に含むことができる。例えば、ＨＡＲＱ−ＡＣＫフィードバックは、スロットｎにおいて送信されるように構成されてよい。ＬＢＴを実施した後に、ＷＴＲＵは、アップリンク制御チャネルにアクセスすることに失敗する。ＷＴＲＵは、次のアップリンクグラントを使用して、ＨＡＲＱ−ＡＣＫフィードバックを送ることができる。ｇＮＢがＵＣＩおよびデータを搬送するＰＵＳＣＨを正しく復号するために、ＷＴＲＵは、最初に失敗したＨＡＲＱ−ＡＣＫ送信後および構成された時間まで、ＨＡＲＱ−ＡＣＫ送信のみのためにＰＵＳＣＨグラントを使用するように構成されてよい。そのような時間は、最初のＨＡＲＱ−ＡＣＫ送信機会からのオフセットを使用して構成され得る。あるいは、ＷＴＲＵは、ＨＡＲＱ−ＡＣＫ送信のために構成された時間内に、ＰＵＳＣＨのみを使用するように構成されてもよい。例えば、ＷＴＲＵが可能なＨＡＲＱ−ＡＣＫ送信のためのタイミングのセット｛ｋ₁，₁，ｋ₁，₂，…ｋ₁，_N｝で構成されるとき、ＷＴＲＵは、それらの同じ時間の間に、ＰＵＳＣＨのみを使用することを可能にされる。

アップリンク送信のためのＨＡＲＱフィードバックについての代表的な手続き
ＷＴＲＵは、１つまたは複数のＤＬ ＨＡＲＱ−ＡＣＫフィードバックについてモニタすることができ、ＷＴＲＵは、アップリンク送信のためのダウンリンクＨＡＲＱ−ＡＣＫフィードバックを受信するために、物理ダウンリンクチャネルをモニタするように構成されてよい。物理ダウンリンクチャネルは、構成された予め定義された時間および周波数リソースにあってよい。あるいは、ＷＴＲＵは、ダウンリンクＨＡＲＱ−ＡＣＫフィードバックを受信するために、多数の時間および周波数位置内でＤＣＩをモニタするように構成されてもよい。例えば、ＷＴＲＵは、多数のＣＯＲＥＳＥＴ／サーチスペースセットにわたって多くの数のＤＣＩ候補をモニタするように構成されてよく、ｇＮＢチャネル占有期間に基づいて、ＷＴＲＵは、モニタされるべきＣＯＲＥＳＥＴ／サーチスペースセットのサブセットを優先させる。いくつかの例において、ＷＴＲＵは、以下のうちの１つまたは複数に基づいて、ＣＯＲＥＳＥＴ／サーチスペースを優先させることができる。一実施形態において、ＷＴＲＵは、ＣＯＲＥＳＥＴ／サーチスペースセットＩＤに基づいて、ＣＯＲＥＳＥＴ／サーチスペースを優先させることができる。例えば、ＷＴＲＵは、ダウンリンクＨＡＲＱフィードバックモニタリングのために、インデックス「０」を有するサーチスペースを優先させるように構成されてよい。別の実施形態において、ＷＴＲＵは、最後のＤＣＩがそこで受信されたＣＯＲＥＳＥＴ／サーチスペースセットに基づいて、ＣＯＲＥＳＥＴ／サーチスペースを優先させることができる。例えば、ＷＴＲＵは、ＤＣＩが最後に受信されたＴＢをそこでスケジュールしたＣＯＲＥＳＥＴをモニタすることを優先させることができる。

一例において、ＷＴＲＵは、任意の所与の時間に多数のＢＷＰのうちの１つのみのＢＷＰがアクティブである、多数のＢＷＰで構成されてよい。ＷＴＲＵは、ダウンリンクフィードバックが予め構成された時間内に受信されない場合、そのアクティブなＢＷＰをスイッチする、または全ての構成されたＢＷＰをモニタすることができる。別の例において、ＷＴＲＵは、多数のＣＯＲＥＳＥＴで構成されてもよく、ＨＡＲＱフィードバックのために構成されたＣＯＲＥＳＥＴのうちのサブセットのみをモニタすることができる。しかしながら、予め構成された時間内にＣＯＲＥＳＥＴのそのサブセットにおいてダウンリンクフィードバックが受信されない場合、ＷＴＲＵは、全てのＣＯＲＥＳＥＴをモニタする。

ＷＴＲＵは、ＷＴＲＵがグループ共通ＰＤＣＣＨを使用してＤＬ ＨＡＲＱ−ＡＣＫを受信するように構成されてよい。ＷＴＲＵは、グループ共通ＰＤＣＣＨを搬送するＤＣＩでスクランブルされることになるグループＩＤで構成されてもよい。あるいは、ＷＴＲＵは、そのＷＴＲＵが確認応答を受信することを予期しているＨＡＲＱプロセスＩＤプロセスに基づいて、グループＩＤを判定することができる。例えば、ＷＴＲＵは、１６に等しい最大ＨＡＲＱプロセスで構成される。ＷＴＲＵは、所与のスロットで、ＨＡＲＱプロセス０、４、および１０のための確認応答を予期している。いくつかの事例において、ＷＴＲＵは次いで、１０００１０００００１０００００でスクランブルされたグループ共通ＤＣＩをモニタする。

ＵＬ ＨＡＲＱ動作およびスケジューリングについての代表的な手続き
いくつかの例において、単一のスケジューリングＤＣＩによって、多数のＰＵＳＣＨ機会が提供されることがある。ＷＴＲＵは、単一のＰＤＳＣＨスケジューリングＤＣＩを使用して、場合により、ばらばらのＰＵＳＣＨ送信時間長で、単一のＨＡＲＱプロセスＩＤのための多数のグラントを受信することができる。そのようなグラントを受信すると、ＷＴＲＵは、最初にグラントされたＰＵＳＣＨ機会にＴＢを送信するように試行することができる。ＬＢＴに失敗すると、ＷＴＲＵは、次にグラントされたＰＵＳＣＨ機会にＰＵＳＣＨを送信するように試行することができ、ＬＢＴが成功し、ＴＢが送信されるまで、そのようなアクションをさらに繰り返すことができる。

単一ＨＡＲＱプロセスのために提供されたＰＵＳＣＨグラントの列内のＰＵＳＣＨグラントでＴＢを正常に送信すると、ＷＴＲＵは、提供されたＰＵＳＣＨグラントの列内の残りのＰＵＳＣＨ機会を無視することができる。あるいは、例えば、提供されたＰＵＳＣＨグラントの列内のＰＵＳＣＨグラントでＴＢを正常に送信すると、ＷＴＲＵは、別のＴＢを送信するように試行することができる。そのような試行は、ネットワーク構成に、またはネットワークから制御シグナリングを受信することに依存してよい。例えば、提供されたＰＵＳＣＨグラントの列内のＰＵＳＣＨグラントでＴＢを正常に送信すると、ＷＴＲＵは、それが新データインジケータ（ＮＤＩ）を受信する場合に、またはＷＴＲＵが同じＨＡＲＱプロセスで送信された以前のＴＢについてのＡＣＫを受信する場合に、次にグラントされるＰＵＳＣＨ機会に別のＴＢを送信するように試行することができる。

いくつかの例において、ＷＴＲＵが単一のグラントを使用して異なるＰＵＳＣＨ機会に異なるＴＢを送信するとき、ＷＴＲＵは、以下の実施形態のうちの１つまたは複数に基づいて、各ＴＢに関連付けられたＨＡＲＱ ＩＤを判定することができる。いくつかの事例において、ＨＡＲＱプロセスＩＤ（ＰＩＤ）のプールまたはセットが、例えば、下で議論される１つまたは複数の実施形態に基づいて、動的に示されてよい。

いくつかの実施形態において、ＷＴＲＵは、Ｌ１シグナリング（例えば、ＤＣＩにおけるＨＡＲＱ情報の一部）によってシグナリングされたＨＡＲＱ ＩＤのプールまたはセットからの選択に基づいて、各ＴＢに関連付けられたＨＡＲＱ ＩＤを判定することができる。例えば、ＤＣＩは、立て続けに各ＴＴＩにマッピングされたＨＡＲＱ ＰＩＤのプール／セット、または使用され得るＰＵＳＣＨ時間長を示すことができ、ＷＴＲＵは、送信のために選択されたＴＴＩの順序で、１つまたは複数のＨＡＲＱ ＰＩＤを選択することができる。別の例において、ＷＴＲＵは、プールから、ランダムに、またはより高位のレイヤによって構成されたパターン（例えば、予め構成されたパターン）に従って、ＨＡＲＱ ＰＩＤを選択することができる。

いくつかの実施形態において、ＷＴＲＵは、公式に基づいて、各ＴＢに関連付けられたＨＡＲＱ ＩＤを判定することができる。いくつかの事例において、ＷＴＲＵは、ＨＡＲＱプロセスＩＤ、すなわちＰＩＤを判定するための公式を使用することができる。例えば、ＨＡＲＱプロセスＩＤは、選択されたＰＵＳＣＨ時間長、示されたＨＡＲＱプロセスＩＤプール／セット、現在のスロットもしくはミニスロット、および／またはサブフレーム／フレームタイミングのうちの少なくとも１つの関数であってよい。

いくつかの実施形態において、ＷＴＲＵは、１つまたは複数の選択されたＴＴＩ／ＰＵＳＣＨ機会に基づいて、各ＴＢに関連付けられたＨＡＲＱ ＩＤを判定することができる。例えば、ＷＴＲＵは、ＨＡＲＱ情報において単一のＨＡＲＱプロセスＩＤを割り当てられてよく、ＷＴＲＵは、選択されたＰＵＳＣＨ機会と、グラントのために示された最初のＰＵＳＣＨ機会との間の時間デルタに基づいて（または同様に、選択されたＰＵＳＣＨ機会と、その間にＤＣＩが受信されたＴＴＩとの間の時間デルタに基づいて）、示されたＨＡＲＱプロセスＩＤのインクリメントを使用することができる。例において、ＤＣＩがスロットｘにおいて受信され、示されたＨＡＲＱプロセスがｙである場合、ＷＴＲＵは、ＰＵＳＣＨがスロットｘ＋３において送信されるとき、ＨＡＲＱプロセスｙ＋３を選択することができる。

いくつかの実施形態において、ＷＴＲＵは、異なるＴＢのために既に使用中のＨＡＲＱプロセスＩＤ、例えば、ＮＤＩがトグルされていないＴＢのために使用されているＨＡＲＱプロセスＩＤ、または確認応答が示されていないＨＡＲＱプロセスＩＤを回避することによって、新しいＴＢ送信のためのＨＡＲＱプロセスＩＤをさらに選択することができる。いくつかの事例において、上で言及されたＨＡＲＱプロセスＩＤ選択方法のいずれかの場合、ＷＴＲＵは、再送信のためになおも使用中の１つもしくは複数の（または全ての）ＨＡＲＱプロセスＩＤを抜かすことができる。

例において、ＷＴＲＵがマルチＴＴＩスケジューリングのために意図されたグラントを受信した後、ＷＴＲＵは、送信が行われ得るまで、またはチャネルが取得されるまで、各可能なＰＵＳＣＨ機会にＬＢＴを試行することができる。

別の例において、ＷＴＲＵがマルチＴＴＩスケジューリングのために意図されたグラントを受信した後、ＷＴＲＵは、立て続けのＰＵＳＣＨ時間長のセット（例えば、途切れなしのＰＵＳＣＨ時間長のセット）の間、単一のＬＢＴを試行することができる。例えば、ＷＴＲＵは、間に途切れなしの立て続けのＴＴＩのセットの間（例えば、ＴＴＩのセットのうちの任意の２つの立て続けのＴＴＩの間に途切れがない）、単一のＬＢＴを適用することができる。ＬＢＴが正常であり、チャネルが第１のＴＴＩの間に取得されると、ＷＴＲＵは、さらなるＬＢＴを求めることなく、隣り合ったＴＴＩにおいてＰＵＳＣＨを送信することができる。他方で、第１のＴＴＩに先立ってチャネルがビジーであるとＬＢＴが判定すると、ＷＴＲＵは、第２のＴＴＩに先立ってＬＢＴを実施することができる。いくつかの事例において、第２のＬＢＴが正常である場合、全ての来たるべき隣り合ったＴＴＩは、ＬＢＴを求めなくてもよい。他方で、チャネルがビジーであると第２のＬＢＴが判定した場合、後続のＴＴＩは、同様のやり方で、後続のＴＴＩでの送信に先立ってＬＢＴを求めることができる。

例において、ＷＴＲＵがマルチＴＴＩスケジューリングのために意図されたグラントを受信した後、ＷＴＲＵは、セットの送信時間長がＬＢＴタイプに適用可能な送信時間長よりも大きくならないような立て続けのＴＴＩのセットの間に、単一のＬＢＴを試行することができる。

いくつかの例において、ＷＴＲＵがマルチＴＴＩスケジューリングのために意図されたグラントを受信し、示されたＨＡＲＱプロセスが以前のＴＢのために既に使用中（例えば、ＮＤＩがトグルされていないＨＡＲＱ ＰＩＤ）であり、グラントがマルチＴＴＩスケジューリングを示した後、ＷＴＲＵは、示されたＨＡＲＱプロセスＩＤに関連付けられたＴＢを再送信するように試行することができる。一旦ＷＴＲＵがＴＢを再送信し、残りのＰＵＳＣＨ機会がスケジュールされたグラントのために有効であると、ＷＴＲＵは、異なるＨＡＲＱプロセスＩＤを用いて（例えば、ＨＡＲＱ ＰＩＤ選択について上で言及された方法のうちのいずれかにつき選択されたＨＡＲＱ ＰＩＤを使用して）、別のＴＢを送信することができる。あるいは、ＷＴＲＵは、グラントのために有効である異なる相次ぐＴＴＩにおいて、しかし異なるＲＶで、および／または同じＨＡＲＱプロセスＩＤを使用して、同じＴＢを再送信することができる。いくつかの事例において、これは、ＤＣＩの内容にさらに依存してもよい。

様々な実施形態において、ＷＴＲＵは、ＨＡＲＱフィードバックトリガの受信のタイミングに基づいて、１つまたは複数のタイマ値を判定することができる。例において、ＷＴＲＵは、１つまたは複数のダウンリンク送信についての制御情報（例えば、ＤＣＩ）を受信することができる。制御情報は、ＷＴＲＵがより後の時間にＨＡＲＱフィードバックを報告するようにトリガされ得ることを、ＷＴＲＵに示すことができる。そのような事例において、ＷＴＲＵは、いくつかのまたは全てのアクティビティベースのタイマを（例えば、ＨＡＲＱフィードバックのためのトリガの受信まで）一時停止することができる。いくつかの例において、アクティビティベースのタイマは、いつ不連続な受信（ＤＲＸ）に進むのかを判定するためのタイマ、いつＢＷＰをスイッチするのか（例えば、デフォルトＢＷＰへのスイッチング）を判定するためのタイマ、およびいつＳＣｅｌｌをアクティブ化解除するのかを判定するためのタイマのうちの少なくとも１つを含むことができる。例において、ＷＴＲＵは、１つまたは複数のアクティビティベースのタイマを、ＨＡＲＱフィードバックトリガ信号の受信まで一時停止することができる。別の例において、ＷＴＲＵは、１つまたは複数のアクティビティベースのタイマを、トリガされたＨＡＲＱフィードバック送信が到着するタイミングまで一時停止することができる。別の例において、ＷＴＲＵは、（例えば、ＤＬ送信をスケジュールするＤＣＩを受信する瞬間から一時停止された）１つまたは複数のアクティビティベースのタイマを、そのようなスケジュールされた送信の正常な完了まで一時停止することができる。例えば、ＷＴＲＵがＰＤＳＣＨについてのＤＣＩを受信しており、ＷＴＲＵがＨＡＲＱフィードバックについての第２のＤＣＩを予期する場合、少なくともＨＡＲＱフィードバックの正常な送信まで、ＷＴＲＵは、１つまたは複数のタイマを一時停止することができる。いくつかの事例において、ＷＴＲＵは、そこでＨＡＲＱフィードバックを送信するための１つよりも多いリソースで構成されてよく、ＬＢＴが正常である最も早いリソース上でもっぱら送信することができる。

様々な実施形態において、ＷＴＲＵは、ＨＡＲＱフィードバックのために使用されることになる多数のタイマ値またはタイマ値のセットを有することができる。いくつかの例において、ＷＴＲＵは、ＨＡＲＱフィードバックがＰＤＳＣＨスケジューリングＤＣＩに示されるかどうか、またはＨＡＲＱフィードバックがより後のＤＣＩにおいてトリガされるかどうかに基づいて、タイマ値（またはタイマ値のセット）を判定または選択することができる。例えば、ＨＡＲＱフィードバック送信リソースがＰＤＳＣＨスケジューリングＤＣＩに示されている場合に、ＷＴＲＵは、第１の値（または第１の値のセット）を使用することができ、ＨＡＲＱフィードバック送信リソースが今後のＤＣＩにおいて予期される場合に、ＷＴＲＵは、第２の値（または第２の値のセット）を使用することができる。そのような例において、スケジューリングＤＣＩの受信時に、例えば、ＨＡＲＱフィードバックリソースのタイミングにかかわらず、タイマがトリガされてよい。

１つまたは複数のアクティビティベースのタイマの満了時、ＷＴＲＵは、ＨＡＲＱフィードバック送信のためにスケジュールされている時間に先立って、アクションを実施することができる。例えば、非アクティブタイマ（例えば、ＢＷＰ非アクティブタイマ）は、ＰＵＳＣＨの受信と、ＨＡＲＱフィードバックトリガの受信との時間期間の間に満了することがある。そのような事例において、ＷＴＲＵは、ＢＷＰを、デフォルトＢＷＰにスイッチすることができる。ＷＴＲＵは、ＨＡＲＱフィードバックビットまたは値を維持することができ、例えば、以前に使用されたＢＷＰにおけるＰＤＳＣＨ送信のために、新しいＢＷＰにおいてＨＡＲＱフィードバック送信トリガを受信することを予期することができる。最初のタイマが満了し、ＷＴＲＵがアクションを実施した場合、ＷＴＲＵは、他のアクティビティベースのタイマをリセットしても、または維持してもよい。例えば、ＷＴＲＵは、非アクティブ化タイマが満了したことに起因して、デフォルトＢＷＰにスイッチすることができる。

一実施形態において、ＷＴＲＵは、１つまたは複数の他のタイマ（例えば、ＤＲＸタイマおよび／またはＳＣｅｌｌアクティブ化解除タイマ）を維持することができる。他のＷＴＲＵ挙動のために使用されるタイマは、ＨＡＲＱ送信フィードバックトリガがＷＴＲＵによって受信されていないという事実を無視するように変更または構成されてよい。別の実施形態において、他のＷＴＲＵ挙動のために維持されるタイマは、以前のＷＴＲＵ状態（例えば、以前のＢＷＰ）において判定された挙動から維持されてもよく、従って、ＨＡＲＱフィードバック送信リソースの知識または知識の欠如に依存してよい。

様々な実施形態において、ＷＴＲＵは、１つまたは複数のＢＷＰおよび／またはＬＢＴサブバンド上でフィードバックを報告するようにトリガされてよい。例えば、スケジューリングＤＣＩおよび／またはＨＡＲＱフィードバックトリガリングＤＣＩは、多数のＢＷＰおよび／またはＬＢＴサブバンド上のリソースのセットを指摘することができる。これは、チャネルアクセス確率を向上させることができる。少なくとも１つのリソース上での正常な送信時、ＷＴＲＵは、それらのＨＡＲＱプロセスについて示され、ＨＡＲＱフィードバックの送信に先立ってスケジュールされた、全ての他のＨＡＲＱフィードバック送信リソースを無視するように構成されてよい。例えば、ＷＴＲＵは、それがＨＡＲＱフィードバックを以前に送信したＨＡＲＱプロセスについて、ＨＡＲＱフィードバックを送信するように再スケジュールされてよい。ＨＡＲＱフィードバックの元々の送信後に第２の要求が発生した場合は、ＷＴＲＵはそれを無視しなくてもよい。

様々な実施形態において、ＷＴＲＵは、ＨＡＲＱフィードバックに関する全ての情報を、少なくともＨＡＲＱフィードバックの正常な送信まで保持することができる。例えば、ＷＴＲＵは、ＨＡＲＱフィードバックのためのリソースをグラントされ得るものの、ＷＴＲＵは、そのようなリソース上で送信のためのチャネルを正常に取得しないことがある。そのような事例において、ＷＴＲＵは、ＨＡＲＱフィードバック情報を、それがそのようなＨＡＲＱプロセスのための新しいＨＡＲＱフィードバック送信リソースで今後においてトリガされ得ると仮定して、保持することができる。

参考文献
以下の参考文献の各々が、参照により本明細書に組み込まれる。（１）非特許文献１、（２）非特許文献２、（３）非特許文献３、（４）非特許文献４。

結び
特徴および要素が特定の組合せにおいて上記で説明されているが、当業者は、各特徴または要素が、単独で、または他の特徴および要素との任意の組合せで使用され得ることを認識するであろう。本明細書で説明された方法は、コンピュータまたはプロセッサによる実行のためのコンピュータ可読媒体に組み込まれたコンピュータプログラム、ソフトウェア、またはファームウェアにおいて実装されてよい。非一時的なコンピュータ可読ストレージ媒体の例は、限定はされないが、ＲＯＭ、ＲＡＭ、レジスタ、キャッシュメモリ、半導体メモリデバイス、内部ハードディスクおよびリムーバブルディスクなどの磁気媒体、磁気光学媒体、並びにＣＤ−ＲＯＭディスクおよびデジタル多用途ディスク（ＤＶＤ）などの光学媒体を含む。ソフトウェアに関連したプロセッサが、ＷＴＲＵ１０２、ＵＥ、端末、基地局、ＲＮＣ、または任意のホストコンピュータにおける使用のための無線周波数トランシーバを実装するために使用されてよい。

その上、上記で説明された実施形態において、処理プラットフォーム、コンピューティングシステム、コントローラおよびプロセッサを収容する他のデバイスが記されている。これらのデバイスは、少なくとも１つの中央処理ユニット（「ＣＰＵ」）およびメモリを収容することができる。コンピュータプログラミングの当業者の実践に従って、作用への言及および動作または命令のシンボル的表現が、様々なＣＰＵおよびメモリによって実施されることがある。そのような作用および動作または命令は、「実行される」、「コンピュータ実行される」、または「ＣＰＵ実行される」と呼ばれてもよい。

当業者は、作用およびシンボル的に表現された動作または命令がＣＰＵによる電気信号の操作を含むことを認識するであろう。電気システムは、電気信号の結果として生じる変換または低減、およびメモリシステムにおけるメモリ位置でのデータビットの維持をもたらして、それによってＣＰＵの動作並びに信号の他の処理を再構成する、またはそうでなければ変えることができる、データビットを表現する。データビットが維持されるメモリ位置は、データビットに対応する、またはデータビットを表現する、特定の電気的、磁気的、光学的、もしくは有機的特性を有する物理的な位置である。代表的な実施形態は上述されたプラットフォームまたはＣＰＵに限定されないこと、並びに他のプラットフォームおよびＣＰＵが提供された方法をサポートできることが理解されるべきである。

データビットはまた、磁気ディスク、光学ディスク、およびＣＰＵによって可読な任意の他の揮発性（例えば、ＲＡＭ）または不揮発性（例えば、ＲＯＭ）大容量ストレージシステムを含むコンピュータ可読媒体上に維持されてよい。コンピュータ可読媒体は、処理システム上に独占的に存在する、または処理システムにローカルもしくはリモートであってよい多数の相互接続された処理システムの間に分散された、協働するまたは相互接続されたコンピュータ可読媒体を含むことができる。代表的な実施形態は、上述されたメモリに限定されないこと、並びに他のプラットフォームおよびメモリが、説明された方法をサポートすることができることが理解される。

例証的な実施形態において、本明細書で説明された動作、プロセス、その他のいずれも、コンピュータ可読媒体上に記憶されたコンピュータ可読命令として実装されてよい。コンピュータ可読命令は、モバイルユニット、ネットワーク要素、および／または任意の他のコンピューティングデバイスのプロセッサによって実行されてよい。

システムの側面のハードウェア実装とソフトウェアの実装との間には、ほとんど区別は残されていない。ハードウェアまたはソフトウェアの使用は、一般に（例えば、常にではないが、ハードウェアとソフトウェアとの選好が重大になり得る一定のコンテキストにおいてという点で）、コスト対効率の兼ね合いを表現する設計上の選好である。本明細書で説明されたプロセスおよび／またはシステムおよび／または他の技術が影響され得る様々なビークル（例えば、ハードウェア、ソフトウェア、および／またはファームウェア）が存在してよく、好ましいビークルは、プロセスおよび／またはシステムおよび／または他の技術が展開されるコンテキストによって多様であってよい。例えば、実装者が速度および精度が最も重要であると判定する場合、実装者は、主にハードウェアおよび／またはファームウェアビークルに決めることができる。柔軟性が最も重要である場合、実装者は、主にソフトウェア実装に決めることができる。あるいは、実装者は、ハードウェア、ソフトウェア、および／またはファームウェアのなんらかの組合せに決めることができる。

上述した詳細な説明は、ブロック図、流れ図、および／または例の使用を介して、デバイスおよび／またはプロセスの様々な実施形態を明記してきた。そのようなブロック図、流れ図、および／または例が１つもしくは複数の機能および／または動作を収容する限りにおいて、そのようなブロック図、流れ図、または例内の各機能および／または動作は、広い範囲のハードウェア、ソフトウェア、ファームウェア、または事実上その任意の組合せによって、個々に、および／または共同で実装され得ることが、当業者によって理解されるであろう。好適なプロセッサは、例えば、汎用プロセッサ、特殊目的プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアに関連した１つもしくは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、特定用途向け標準製品（ＡＳＳＰ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意の他のタイプの集積回路（ＩＣ）、および／または状態マシンを含む。

特徴および要素が特定の組合せにおいて上で提供されているが、当業者は、各特徴または要素が、単独で、または他の特徴および要素との任意の組合せで使用され得ることを認識するであろう。本開示は、様々な態様の例証として意図される、本出願において説明された特定の実施形態に関して限定されるべきではない。多くの変更形態および変形形態が、当業者には明らかであるように、その趣旨および領域から逸脱することなく行われてよい。本出願の説明で使用されるいずれの要素、作用、または命令も、そのように明示的に規定されない限り、本発明に決定的または必須であると取られるべきでない。本明細書で挙げられたものに加えて、本開示の領域内で機能的に等価な方法または装置は、上述した説明から当業者には明らかであろう。そのような変更形態および変形形態は、添付の請求項の領域内に入るように意図される。本開示は、そのような請求項が権利を付される等価物の全領域と共に、添付の請求項の用語によってのみ限定されることになる。本開示は、特定の方法またはシステムには限定されないことが理解されるべきである。

本明細書で使用される術語は、特定の実施形態を説明するのみの目的のためであり、限定するように意図されないこともまた理解されるべきである。本明細書で使用されるとき、すなわち、本明細書で言及されるとき、用語「局」およびその略語「ＳＴＡ」、「ユーザ機器」およびその略語「ＵＥ」は、（ｉ）以下に説明するような、無線送信および／または受信ユニット（ＷＴＲＵ）、（ｉｉ）以下に説明するような、ＷＴＲＵのいくつかの実施形態のうちのいずれか、（ｉｉｉ）以下に説明するような、とりわけ、ＷＴＲＵのいくつかもしくは全ての構造および機能性で構成された無線能力のある、および／もしくは有線能力のある（例えば、テザリング可能な（tetherable））デバイス、（ｉｖ）以下に説明するような、ＷＴＲＵの全てには満たない構造および機能性で構成された無線能力のある、および／もしくは有線能力のあるデバイス、または（ｖ）その他を意味することができる。本明細書に記載された任意のＵＥを表現してよい（またはＵＥと交換可能な）例示的なＷＴＲＵの詳細は、図１Ａ−図１Ｄに関して下で提供される。

一定の代表的な実施形態において、本明細書で説明された主題のいくつかの部分は、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、デジタル信号プロセッサ（ＤＳＰ）、および／または他の集積された形式を介して実装されてよい。しかしながら、当業者は、本明細書で開示される実施形態のいくつかの態様が、全体にまたは部分的に、１つもしくは複数のコンピュータ上で稼働する１つもしくは複数のコンピュータプログラムとして（例えば、１つもしくは複数のコンピュータシステム上で稼働する１つもしくは複数のプログラムとして）、１つもしくは複数のプロセッサ上で稼働する１つもしくは複数のプログラムとして（例えば、１つもしくは複数のマイクロプロセッサ上で稼働する１つもしくは複数のプログラムとして）、ファームウェアとして、または事実上その任意の組合せとして集積回路において等価に実装されてもよいこと、並びに、回路を設計すること、および／またはソフトウェアおよび／もしくはファームウェアのためのコードを書くことが、本開示に照らして当業者の技能内で十分であることを認めるであろう。当業者は、本明細書で説明される主題のメカニズムが種々の形態におけるプログラム製品として配信され得ること、および配信を実際に遂行するために使用される特定のタイプの信号ベアリング媒体にかかわらず、本明細書で説明される主題の例証的な実施形態が適用されることを認識するであろう。信号ベアリング媒体の例は、限定はされないが、フロッピーディスク、ハードディスクドライブ、ＣＤ、ＤＶＤ、デジタルテープ、コンピュータメモリ、その他などの記録可能なタイプの媒体、並びに、デジタルおよび／またはアナログ通信媒体（例えば、光ファイバケーブル、導波路、有線通信リンク、無線通信リンク、その他）などの送信タイプ媒体を含む。

本明細書で説明される主題は、時に、異なる他のコンポーネント内に収容された、または異なる他のコンポーネントに接続された、異なるコンポーネントを例証する。そのような描写されたアーキテクチャは単に例であること、および実際には同じ機能性を実現する多くの他のアーキテクチャが実装されてよいということが理解されるべきである。概念的な意味において、同じ機能性を実現するためのコンポーネントの任意の配置は、所望の機能性が実現され得るように、実際上「関係付けられる」。従って、特定の機能性を実現するために組み合わされる本明細書における任意の２つのコンポーネントは、アーキテクチャまたは中間コンポーネントを問わず、所望の機能性が実現されるように、互いに「関連付けられる」と見られてよい。同様に、そのように関連付けられた任意の２つのコンポーネントはまた、所望の機能性を実現するために、互いに「動作可能に接続される」または「動作可能に結合される」と考察されてよく、そのように関連付けられる能力のある任意の２つのコンポーネントはまた、所望の機能性を実現するために、互いに「動作可能に結合可能である」と考察されてもよい。動作可能に結合可能な具体的な例は、限定はされないが、物理的にかみ合うことが可能な（mateable）および／もしくは物理的に相互作用するコンポーネント、並びに／または、無線に相互作用可能なおよび／もしくは無線に相互作用するコンポーネント、並びに／または、論理的に相互作用するおよび／もしくは論理的に相互作用可能なコンポーネントを含む。

本明細書における実質的に任意の複数形および／または単数形の用語の使用に関して、当業者は、コンテキストおよび／または用途に適切であるように、複数形から単数形へと、および／または単数形から複数形へと置き換えることができる。様々な単数形／複数形の置換は、わかりやすさのために本明細書においてわざわざ明記されることがある。

一般に、本明細書において、および特に添付の特許請求の範囲（例えば、添付の特許請求の範囲の本文）において使用される用語は、「オープンな」用語として広く意図されることが当業者によって理解されるであろう（例えば、用語「〜を含むこと（ｉｎｃｌｕｄｉｎｇ）」は、「限定はされないが〜を含むこと」と解釈されるべきであり、用語「〜を有すること（ｈａｖｉｎｇ）」は「少なくとも〜を有すること」と解釈されるべきであり、用語「〜を含む（ｉｎｃｌｕｄｅ）」は、「限定はされないが〜を含む」と解釈されるべきである、など）。導入される請求項の記載の具体的な数が意図される場合には、そのような意図は請求項において明示的に記載されることになり、そのような記載がない場合には、そのような意図がないことが当業者によってさらに理解されるであろう。例えば、１つのみの項目が意図される場合、用語「単一の」または同様の言語が使用されてよい。理解の補助として、以下の添付の特許請求の範囲および／または本明細書における説明は、請求項の記載を導入するために、導入的な語句「少なくとも１つの」および「１つまたは複数の」の使用を収容することがある。しかしながら、そのような語句の使用は、不定冠詞「ａ」または「ａｎ」による請求項の記載の導入が、同じ請求項が導入的な語句「１つまたは複数の」または「少なくとも１つの」、および「ａ」または「ａｎ」などの不定冠詞を含むときでさえ、そのような導入される請求項の記載を収容する任意の特定の請求項を１つのみのそのような記載を収容する実施形態に限定することを含意するように取られるべきではない（例えば、「ａ」および／または「ａｎ」は、「少なくとも１つの」または「１つまたは複数の」を意味するように解釈されるべきである）。同じことは、請求項の記載を導入するために使用される定冠詞の使用にも当てはまる。また、導入される請求項の記載の具体的な数が明示的に記載される場合であっても、そのような記載が、少なくとも記載された数を意味するように解釈されるべきであることを当業者は認めるであろう（例えば、「２つの記載」というそのままの記載は、他の修飾語がなければ、少なくとも２つの記載、または２つ以上の記載を意味する）。

さらに、「Ａ、Ｂ、およびＣなどのうちの少なくとも１つ」に類似する伝統的表現法（convention）が使用される場合において、一般に、そのような構文は、当業者が伝統的表現法を理解することになる意味において意図される（例えば、「Ａ、Ｂ、およびＣのうちの少なくとも１つを有するシステム」は、限定はされないが、Ａを単独で、Ｂを単独で、Ｃを単独で、ＡおよびＢを一緒に、ＡおよびＣを一緒に、ＢおよびＣを一緒に、並びに／またはＡ、Ｂ、およびＣを一緒に有するシステムを含むことになる、など）。「Ａ、Ｂ、またはＣなどのうちの少なくとも１つ」に類似する伝統的表現法が使用される場合において、一般に、そのような構文は、当業者が伝統的表現法を理解することになる意味において意図される（例えば、「Ａ、Ｂ、またはＣのうちの少なくとも１つを有するシステム」は、限定はされないが、Ａを単独で、Ｂを単独で、Ｃを単独で、ＡおよびＢを一緒に、ＡおよびＣを一緒に、ＢおよびＣを一緒に、並びに／またはＡ、Ｂ、およびＣを一緒に有するシステムを含むことになる、など）。２つ以上の代替用語を提示する事実上あらゆる選言的な語および／または語句は、明細書、請求項、または図面においてにせよ、用語のうちの１つ、用語のうちのどちらか、または両方の用語を含む可能性を企図するように理解すべきであることが当業者によってさらに理解されるであろう。例えば、語句「ＡまたはＢ」は、「Ａ」または「Ｂ」または「ＡおよびＢ」の可能性を含むように理解されることになる。さらに、複数の項目のリストおよび／または項目の複数のカテゴリに続く用語「いずれか」は、本明細書で使用されるとき、項目および／または項目のカテゴリの「いずれか」、「いずれかの組合せ」、「いずれか複数の」、および／または「複数のいずれかの組合せ」を、個々に、または他の項目と併せて、および／または項目の他のカテゴリと併せて含むように意図される。その上、本明細書で使用されるとき、用語「セット」または「グループ」は、ゼロを含む任意の数の項目を含むように意図される。追加として、本明細書で使用されるとき、用語「数」は、ゼロを含む任意の数を含むように意図される。

加えて、本開示の特徴または態様がマーカッシュ群（Markush group）の観点から説明される場合、本開示はまた、それによって、マーカッシュ群の任意の個々のメンバまたはメンバの下位群の観点から説明されることを当業者は認めるであろう。

当業者によって理解されるように、書面の明細書を提供する観点からなどの任意のおよび全ての目的のために、本明細書で開示される全ての範囲はまた、任意のおよび全ての可能な下位範囲、並びにそれらの下位範囲の組合せを包含する。任意のリストにされた範囲は、同じ範囲が少なくとも均等な半分、３分の１、４分の１、５分の１、１０分の１などに分解されることを十分に説明し、容易にするものとして簡単に認められ得る。非限定的な例として、本明細書で議論される各範囲は、下３分の１、中３分の１、および上３分の１などに直ちに分解されてもよい。当業者によってまた理解されるように、「〜まで」、「少なくとも」、「〜よりも大きい」、「〜よりも小さい」その他のなどの全ての言語は、記載された数を含み、上で議論されたように、下位範囲に引き続き分解され得る範囲を指す。最後に、当業者によって理解されるように、範囲は、各個々のメンバを含む。従って、例えば、１〜３つのセルを有するグループは、１つ、２つ、または３つのセルを有するグループを指す。同様に、１〜５つのセルを有するグループは、１つ、２つ、３つ、４つ、または５つのセルを有するグループを指す、などである。

その上、特許請求の範囲は、その趣意で述べられていない限り、提供される順序または要素に限定されるものと読まれるべきではない。加えて、任意の請求項における用語「〜ための手段（ｍｅａｎｓ ｆｏｒ）」の使用は、米国特許法第１１２条６項、またはミーンズプラスファンクションクレーム形式を行使するように意図されており、いずれの請求項も用語「〜ための手段」がなければ、そのようには意図されない。

ソフトウェアに関連したプロセッサは、無線送受信ユニット（ＷＴＲＵ）、ユーザ機器（ＵＥ），端末、基地局、モビリティ管理エンティティ（ＭＭＥ）もしくは進化型パケットコア（ＥＰＣ）、または任意のホストコンピュータにおける使用のための無線周波数トランシーバを実装するために使用されてよい。ＷＴＲＵは、ソフトウェア定義無線（ＳＤＲ）と、カメラ、ビデオカメラモジュール、ビデオフォン、スピーカフォン、振動デバイス、スピーカ、マイクロフォン、テレビジョントランシーバ、ハンズフリーヘッドセット、キーボード、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）無線ユニット、近距離無線通信（ＮＦＣ）モジュール、液晶ディスプレイ（ＬＣＤ）ディスプレイユニット、有機発光ダイオード（ＯＬＥＤ）ディスプレイユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザ、および／または任意の無線ローカルエリアネットワーク（ＷＬＡＮ）もしくはウルトラワイドバンド（ＵＷＢ）モジュールなどの他のコンポーネントを含む、ハードウェアおよび／またはソフトウェアで実装されるモジュールと併せて使用されてもよい。

本発明が通信システムの観点から説明されてきたが、システムは、マイクロプロセッサ／汎用コンピュータ（図示せず）上のソフトウェアで実装されてもよいことが企図される。一定の実施形態において、様々なコンポーネントの機能のうち１つまたは複数は、汎用コンピュータを制御するソフトウェアで実装されてもよい。

本発明は具体的な実施形態を参照して本明細書で例証され、説明されているが、本発明は、示された詳細に限定されることは意図されていない。むしろ、様々な変更形態が、特許請求の範囲の等価物の領域および範囲内の詳細において、本発明から逸脱することなく行われてよい。

本開示全体を通して、当業者は、一定の代表的な実施形態が、代替的実施形態において、または他の代表的な実施形態との組合せにおいて使用されてもよいことを理解する。

特徴および要素が特定の組合せにおいて上記で説明されているが、当業者は、各特徴または要素が、単独で、または他の特徴および要素との任意の組合せで使用され得ることを認識するであろう。本明細書で説明された方法は、コンピュータまたはプロセッサによる実行のためのコンピュータ可読媒体に組み込まれたコンピュータプログラム、ソフトウェア、またはファームウェアにおいて実装されてよい。非一時的なコンピュータ可読ストレージ媒体の例は、限定はされないが、ＲＯＭ、ＲＡＭ、レジスタ、キャッシュメモリ、半導体メモリデバイス、内部ハードディスクおよびリムーバブルディスクなどの磁気媒体、磁気光学媒体、並びにＣＤ−ＲＯＭディスクおよびデジタル多用途ディスク（ＤＶＤ）などの光学媒体を含む。ソフトウェアに関連したプロセッサが、ＷＴＲＵ、ＵＥ、端末、基地局、ＲＮＣ、または任意のホストコンピュータにおける使用のための無線周波数トランシーバを実装するために使用されてよい。

その上、上述された実施形態において、処理プラットフォーム、コンピューティングシステム、コントローラ、およびプロセッサを収容する他のデバイスが記されている。これらのデバイスは、少なくとも１つの中央処理ユニット（「ＣＰＵ」）およびメモリを収容することができる。コンピュータプログラミングの当業者の実践に従って、作用への言及および動作または命令のシンボル的表現が、様々なＣＰＵおよびメモリによって実施されることがある。そのような作用および動作または命令は、「実行される」、「コンピュータ実行される」、または「ＣＰＵ実行される」と呼ばれてもよい。

当業者は、作用およびシンボル的に表現された動作または命令がＣＰＵによる電気信号の操作を含むことを認識するであろう。電気システムは、電気信号の結果として生じる変換または低減、およびメモリシステムにおけるメモリ位置でのデータビットの維持をもたらして、それによってＣＰＵの動作並びに信号の他の処理を再構成する、またはそうでなければ変えることができる、データビットを表現する。データビットが維持されるメモリ位置は、データビットに対応する、またはデータビットを表現する、特定の電気的、磁気的、光学的、もしくは有機的特性を有する物理的な位置である。

データビットはまた、磁気ディスク、光学ディスク、およびＣＰＵによって可読な任意の他の揮発性（例えば、ＲＡＭまたは不揮発性（例えば、ＲＯＭ）大容量ストレージシステムを含むコンピュータ可読媒体上に維持されてよい。コンピュータ可読媒体は、処理システム上に独占的に存在する、または処理システムにローカルもしくはリモートであってよい多数の相互接続された処理システムの間に分散された、協働するまたは相互接続されたコンピュータ可読メディアを含むことができる。代表的な実施形態は、上述されたメモリに限定されないこと、並びに他のプラットフォームおよびメモリが、説明された方法をサポートすることができることが理解される。

好適なプロセッサは、例えば、汎用プロセッサ、特殊目的プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアに関連した１つもしくは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、特定用途向け標準製品（ＡＳＳＰ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意の他のタイプの集積回路（ＩＣ）、および／または状態マシンを含む。

本発明が通信システムの観点から説明されてきたが、システムは、マイクロプロセッサ／汎用コンピュータ（図示せず）上のソフトウェアで実装されてもよいことが企図される。一定の実施形態において、様々なコンポーネントの機能のうち１つまたは複数は、汎用コンピュータを制御するソフトウェアで実装されてもよい。

加えて、本発明は具体的な実施形態を参照して本明細書で例証され、説明されているが、本発明は、示された詳細に限定されることは意図されていない。むしろ、様々な変更形態が、特許請求の範囲の等価物の領域および範囲内の詳細において、本発明から逸脱することなく行われてよい。

Claims (21)

1. 無線通信のために無線送受信ユニット（ＷＴＲＵ）によって実行される方法であって、
   第１の表示に基づいてコードブックプロセスのセットからコードブックプロセスを識別するステップと、
   ハイブリッド自動再送要求（ＨＡＲＱ）フィードバックのビットのセットを、前記識別されたコードブックプロセスに関連付けるステップと、
   条件に基づいて、前記識別されたコードブックプロセスに関連付けられたビットのセットを維持するステップと、
   前記識別されたコードブックプロセスに関連付けられたビットのセットを送信するための第２の表示を受信するステップと、
   前記第２の表示に基づいて、前記ビットのセットを送信するステップと
   を備える方法。
2. 前記関連付けることは、
   ダウンリンク制御情報（ＤＣＩ）において受信された前記第１の表示と、
   ＨＡＲＱフィードバックのビットの前記セットが対応するダウンリンク送信のセットに関連付けられる１つまたは複数のパラメータと、
   ダウンリンク送信のセットが受信されるリソースに関連付けられる１つまたは複数のパラメータと
   のうちの任意のものによって決定される、請求項１の方法。
3. 前記第１の表示は、前記コードブックプロセスの識別子を示す、請求項１の方法。
4. ＨＡＲＱフィードバックのビットの前記セットは、ダウンリンク送信のセットに対応する、請求項１の方法。
5. 前記条件は、
   リッスンビフォートーク（ＬＢＴ）失敗、
   前記ＨＡＲＱフィードバックが成功裏に受信されなかったダウンリンク送信のセットに対応することを示すメッセージの受信、および
   前記ＷＴＲＵに前記コードブックプロセスを維持するように命じるメッセージの受信
   のうちの任意のものを含む、請求項１の方法。
6. 前記第２の表示は、
   前記識別されたコードブックプロセスに関連付けられるアップリンクリソースの表示、
   ダウンリンク制御情報（ＤＣＩ）フォーマット、
   ＤＣＩにおける１つまたは複数のビット、
   無線ネットワーク一時識別子（ＲＮＴＩ）、および
   ＨＡＲＱフィードバック送信のタイミング情報
   のうちの任意のものを含む、請求項１の方法。
7. 無線通信のために無線送受信ユニット（ＷＴＲＵ）によって実行される方法であって、
   前記ＷＴＲＵによって、リッスンビフォートーク（ＬＢＴ）を行わない表示、またはハイブリッド自動再送要求（ＨＡＲＱ）フィードバックを送信する前に短いＬＢＴを行う表示を受信するステップと、
   前記表示に従って、前記ＨＡＲＱフィードバックを送信するステップと
   を備える方法。
8. 前記ＨＡＲＱフィードバックを送信する前に短いＬＢＴを行うことを前記表示が示しているという条件で、前記ＷＴＲＵによって、短いＬＢＴを行うステップをさらに備える、請求項７の方法。
9. 前記ＨＡＲＱフィードバックを送信するステップは、前記ＨＡＲＱフィードバックを送信する前にＬＢＴを行わないことを前記表示が示しているという条件で、ＬＢＴを行うことなく前記ＨＡＲＱフィードバックを送信することを含む、請求項７の方法。
10. 前記表示は、
    前記ＨＡＲＱフィードバックが応答するであろうスケジューリング信号をスクランブルするために使用される固有の無線ネットワーク一時識別子（ＲＮＴＩ）、
    前記ＨＡＲＱフィードバックが応答するであろうスケジューリング信号が受信されたサーチスペース、
    前記ＨＡＲＱフィードバックが応答するであろうスケジューリング信号が受信された制御リソースセット（ＣＯＲＥＳＥＴ）、
    前記ＨＡＲＱフィードバックが応答するであろうスケジューリング信号に関連付けられるスロットフォーマット表示、のうちの任意のものを含む、請求項７の方法。
11. 前記表示は、前記ＨＡＲＱフィードバックが応答するであろうスケジューリング信号に関連付けられる以下のもの、すなわち、
    ＲＮＴＩ、
    ダウンリンク制御情報（ＤＣＩ）フォーマット、
    トランスポートブロック（ＴＢ）をスケジュールするＤＣＩのアグリゲーションレベル、
    ＴＢをスケジュールするＤＣＩが検出されたサーチスペース、
    ＴＢをスケジュールするＤＣＩが検出されたＣＯＲＥＳＥＴ、
    物理アップリンク制御チャネル（ＰＵＣＣＨ）リソース表示、
    ＨＡＲＱコードブックサイズ、
    ＨＡＲＱフィードバックのタイミング情報、
    ＨＡＲＱプロセス識別子（ＩＤ）、
    スロットフォーマット表示、
    ＤＣＩにおけるビット表示、
    のうちの任意のものである、請求項７の方法。
12. 無線通信のために無線送受信ユニット（ＷＴＲＵ）によって実行される方法であって、
    ＨＡＲＱフィードバックを送信する表示を受信するステップと、
    前記表示に基づいて、前記ＨＡＲＱフィードバックが１つまたは複数の進行中のチャネル占有時間（ＣＯＴ）で送信されることになることを判定するステップと、
    前記判定に基づいて前記ＨＡＲＱフィードバックを送信するステップと
    を備える方法。
13. 前記表示は、ダウンリンク制御情報（ＤＣＩ）において受信され、および前記ＨＡＲＱフィードバックが送信されることになるＣＯＴを示すＣＯＴ番号、ＣＯＴインデックス、およびＣＯＴオフセットのうちの少なくとも１つを含む、請求項１２の方法。
14. 前記表示は、少なくとも、タイミング値、またはＨＡＲＱ送信のためのＤＣＩにおけるリソースアロケーションを含む、請求項１２の方法。
15. 前記表示は、ＤＣＩ送信のために使用されるサーチスペースまたはＣＯＲＥＳＥＴである、請求項１２の方法。
16. 無線送受信ユニット（ＷＴＲＵ）であって、
    第１の表示に基づいてコードブックプロセスのセットからコードブックプロセスを識別し、
    ハイブリッド自動再送要求（ＨＡＲＱ）フィードバックのビットのセットを、前記識別されたコードブックプロセスに関連付け、
    条件に基づいて、前記識別されたコードブックプロセスに関連付けられたビットのセットを維持する
    ように構成されたプロセッサと、
    前記識別されたコードブックプロセスに関連付けられたビットのセットを送信するための第２の表示を受信するように構成された受信機と、
    前記第２の表示に基づいて、前記ビットのセットを送信するように構成された送信機と
    を備えたＷＴＲＵ。
17. 前記関連付けることは、
    ダウンリンク制御情報（ＤＣＩ）において受信された前記第１の表示と、
    ＨＡＲＱフィードバックのビットの前記セットが対応するダウンリンク送信のセットに関連付けられる１つまたは複数のパラメータと、
    ダウンリンク送信のセットが受信されるリソースに関連付けられる１つまたは複数のパラメータと
    のうちの任意のものによって決定される、請求項１６のＷＴＲＵ。
18. 前記第１の表示は、前記コードブックプロセスの識別子を示す、請求項１６のＷＴＲＵ。
19. ＨＡＲＱフィードバックのビットの前記セットは、ダウンリンク送信のセットに対応する、請求項１６のＷＴＲＵ。
20. 前記条件は、
    リッスンビフォートーク（ＬＢＴ）失敗、
    前記ＨＡＲＱフィードバックが成功裏に受信されなかったダウンリンク送信のセットに対応することを示すメッセージの受信、および
    前記ＷＴＲＵに前記コードブックプロセスを維持するように命じるメッセージの受信
    のうちの任意のものを含む、請求項１６のＷＴＲＵ。
21. 前記第２の表示は、
    前記識別されたコードブックプロセスに関連付けられるアップリンクリソースの表示、
    ダウンリンク制御情報（ＤＣＩ）フォーマット、
    ＤＣＩにおける１つまたは複数のビット、
    無線ネットワーク一時識別子（ＲＮＴＩ）、および
    ＨＡＲＱフィードバック送信のタイミング情報
    のうちの任意のものを含む、請求項１６のＷＴＲＵ。

Images