JP2021516878A - 方法及び端末デバイス - Google Patents

Abstract

本開示の実施形態は、一般的に、ＨＡＲＱ確認応答のフィードバックに関する。ネットワークデバイスは、ＨＡＲＱ確認応答のフィードバックモードを示す第１のトリガを端末デバイスに送信する。フィードバックモードは、トリガモード、タイミングモード、及び混合モードの少なくとも１つから選択される。ＨＡＲＱ確認応答に割り当てられたアンライセンスバンドへの成功したアクセスに応答して、ネットワークデバイスは、端末デバイスに、第１のトリガで示されるフィードバックモードに基づいてＨＡＲＱ確認応答をフィードバックする少なくとも１つのターゲット端末デバイスを示す第２のトリガを送信する。【選択図】図２

Description

本開示の実施形態は、一般に、通信の分野に関し、より詳細には、アンライセンスバンドでのハイブリッド自動再送要求（ＨＡＲＱ：Ｈｙｂｒｉｄ Ａｕｔｏｍａｔｉｃ Ｒｅｐｅａｔ Ｒｅｑｕｅｓｔ）確認応答のフィードバックのための方法及びデバイスに関する。

アンライセンスバンド動作は、３ＧＰＰに研究・適用されており、例えばライセンスアシストアクセス（ＬＡＡ：Ｌｉｃｅｎｓｅｄ Ａｓｓｉｓｔ Ａｃｃｅｓｓ）がある。従来の規格によれば、アンライセンスバンドに物理アップリンク制御チャネル（ＰＵＣＣＨ：Ｐｈｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）がなく、ライセンスされたプライマリセルが必須であるため、ＨＡＲＱ確認応答（ＨＡＲＱ−ＡＣＫとも呼ばれる）は、ライセンスされたセルで配信される。

新しく開発されたモバイル規格、例えば、新しい無線（ＮＲ：Ｎｅｗ Ｒａｄｉｏ）システムは、アンライセンスバンド動作、特にアンライセンスバンドでのＨＡＲＱ−ＡＣＫのフィードバックをサポートする。ＮＲの例示的なシナリオでは、ＨＡＲＱ−ＡＣＫのフィードバックはスタンドアロンの展開であり、つまり、フィードバックに関与するライセンスバンドがない。従って、アンライセンスバンドでＨＡＲＱ−ＡＣＫをフィードバックする方式が必要となる。

本開示の実施形態は、概して、上記で記述した問題を解決するための解決策を提供する。

本開示の実施形態の第１の態様では、本開示の実施形態は、ネットワークデバイスで実行される方法を提供する。前記ネットワークデバイスは、ＨＡＲＱ確認応答のフィードバックモードを示す第１のトリガを端末デバイスに送信する。前記フィードバックモードは、トリガモード、タイミングモード、及び混合モードの少なくとも１つから選択される。ＨＡＲＱ確認応答に割り当てられたアンライセンスバンドへの成功したアクセスに応答して、前記ネットワークデバイスは、前記端末デバイスに、前記第１のトリガで示される前記フィードバックモードに基づいて前記ＨＡＲＱ確認応答をフィードバックする少なくとも１つのターゲット端末デバイスを示す第２のトリガを送信する。

本開示の実施形態の第２の態様では、本開示の実施形態はネットワークデバイスを提供する。前記ネットワークデバイスは、プロセッサとメモリとを含む。前記メモリは、前記プロセッサによって実行可能な命令を含むプログラムを備えるメモリを含み、前記プロセッサは、前記ネットワークデバイスに本開示の第１の態様による方法を実行させるように構成される。

本開示の実施形態の第３の態様では、本開示の実施形態は、コンピュータ読み取り可能な記憶媒体を提供する。前記コンピュータ読み取り可能な記憶媒体には、命令が格納されており、前記命令は、ネットワークデバイスによって実行されると、ネットワークデバイスに本開示の第１の態様による方法を実行させる。

本開示の実施形態の第４の態様では、本開示の実施形態は、端末デバイスで実行される方法を提供する。前記端末デバイスは、ネットワークデバイスから、ＨＡＲＱ確認応答のフィードバックモードを示す第１のトリガを受信し、前記フィードバックモードは、トリガモード、タイミングモード、及び混合モードの少なくとも１つから選択される。前記フィードバックモードが前記トリガモード又は前記混合モードであることに応答して、前記端末デバイスは、前記ネットワークデバイスから、前記ＨＡＲＱ確認応答をフィードバックする少なくとも１つのターゲット端末デバイスを示す第２のトリガを検出する。

本開示の実施形態の第５の態様では、本開示の実施形態は端末デバイスを提供する。前記端末デバイスは、プロセッサとメモリとを備える。前記メモリは、前記プロセッサによって実行可能な命令を含むプログラムを備えるメモリを含み、前記プロセッサは、前記端末デバイスに本開示の第４の態様による方法を実行させるように構成される。

本開示の実施形態の第６の態様では、本開示の実施形態は、コンピュータ読み取り可能な記憶媒体を提供する。前記コンピュータ読み取り可能な記憶媒体には、命令が格納されており、前記命令は、端末デバイスによって実行されると、端末デバイスに本開示の第４の態様による方法を実行させる。

本開示の実施形態の他の特徴及び利点は、例示として本開示の実施形態の原理を示す添付の図面と併せて読むと、以下の特定の実施形態の説明から明らかになる。

本開示の様々な実施形態の上記及び他の態様、特徴、及び利点は、例示として、添付の図面を参照した以下の詳細な説明からより明らかになるであろう。添付の図面において、類似又は同等の要素に類似する数字やアルファベットが使用される。図面は、本開示の実施形態をより理解しやすくするために示され、必ずしも一定の縮尺で描かれている必要はない。

図１は、ＨＡＲＱ確認応答のフィードバックの従来のスキームの概略図１００を示す。

図２は、本開示の実施形態に係る、ＨＡＲＱ確認応答のフィードバックの方法２００のフローチャートを示す。

図３は、本開示の実施形態に係る、ＨＡＲＱ確認応答のフィードバックの概略図３００を示す。

図４は、本開示の実施形態に係る、ＨＡＲＱ確認応答のフィードバックの概略図４００を示す。

図５は、本開示の実施形態に係る、ＨＡＲＱ確認応答のフィードバックの概略図５００を示す。

図６は、本開示の実施形態に係る、ＨＡＲＱ確認応答のフィードバックの概略図６００を示す。

図７は、本開示の実施形態に係る、ＨＡＲＱ確認応答のフィードバックの概略図７００を示す。

図８は、本開示の実施形態に係る、ＨＡＲＱ確認応答のフィードバックの概略図８００を示す。

図９は、本開示の実施形態に係る、ＨＡＲＱ確認応答のフィードバックの概略図９００を示す。

図１０は、本開示の実施形態に係る、ＨＡＲＱ確認応答のフィードバックの方法１０００のフローチャートを示す。

図１１は、本開示の実施形態に係る、ネットワークデバイスで実装される装置１１００のブロック図を示す。

図１２は、本開示の実施形態に係る、端末デバイスで実装される装置１２００のブロック図を示す。

図１３は、本開示の実施形態を実施するのに適したデバイス１３００の簡略ブロック図を示す。

本明細書で説明される要旨について、いくつかの例示的な実施形態を参照して説明する。これらの実施形態は、当業者が本明細書で説明される要旨をよりよく理解及び実施できるという目的だけで述べられ、要旨の範囲を限定する意図ではないと理解すべきである。

本明細書で使用される用語は、特定の実施形態を説明するために過ぎず、例示的な実施形態を限定する意図ではない。本明細書で使用されるとき、単数形「一つ（ａ）」、「１つ（ａｎ）」、及び「前記（ｔｈｅ）」について、文脈からそうでないことが明確に示されていない限り、複数形も含まれる。本明細書で使用されるとき、「備える」、「備え」、「含む」及び／又は「含まれる」という用語は、述べられた特徴、整数、ステップ、動作、要素及び／又はコンポーネントの存在を限定するが、１つ以上の他の特徴、整数、ステップ、動作、要素、コンポーネント、及び／又はそれらの組み合わせの存在又は追加を排除することはない。

いくつかの代替の実施例では、示される機能／動作は、図面に示される順序とは異なる順序で発生する場合があることにも留意されたい。例えば、連続して示される２つの機能又は動作は、関連する機能／動作によっては、実際に同時に実行される場合があり、逆の順序で実行される場合もある。

本明細書で使用されるとき、「通信ネットワーク」という用語は、新い無線アクセス（ＮＲ）、ロングタームエボリューション（（ＬＴＥ：Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ））、ＬＴＥアドバンスト（ＬＴＥ−Ａ：ＬＴＥ−Ａｄｖａｎｃｅｄ）、広帯域符号分割多重アクセス（ＷＣＤＭＡ：Ｗｉｄｅｂａｎｄ Ｃｏｄｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）、高速パケットアクセス（ＨＳＰＡ：Ｈｉｇｈ−Ｓｐｅｅｄ Ｐａｃｋｅｔ Ａｃｃｅｓｓ）などの任意の適切な通信規格に準拠するネットワークを指す。さらに、通信ネットワークにおける端末デバイスとネットワークデバイスとの間の通信は、任意の適切な世代の通信プロトコルに従って実行されてもよい。通信プロトコルの例には、第１世代（１Ｇ）、第２世代（２Ｇ）、２．５Ｇ、２.７５Ｇ、第３世代（３Ｇ）、第４世代（４Ｇ）、４．５Ｇ、将来の第５世代（５Ｇ）の通信プロトコル、及び／又は現在知られている又は将来開発されるその他のプロトコルが含まれるが、これらに限定されない。

本開示の実施形態は、様々な通信システムに適用されることができる。通信分野の急速な発展を考慮すると、本開示を具現化することができる将来のタイプの通信技術及びシステムも存在することは当然である。本開示の範囲を前述のシステムのみに限定するものとして見なされるべきではない。

「ネットワークデバイス」という用語は、基地局（ＢＳ：Ｂａｓｅ Ｓｔａｔｉｏｎ）、ゲートウェイ、管理エンティティ、及び通信システムにおける他の適切なデバイスを含むが、これらに限定されない。「基地局」又は「ＢＳ」という用語は、ノードＢ（ＮoｄｅＢ又はＮＢ）、発展型ＮoｄｅＢ（ｅＮoｄｅＢ又はｅＮＢ）、ＮＲにおけるＮoｄｅＢ（ｇＮＢ）、リモート無線ユニット（ＲＲＵ：Ｒｅｍｏｔｅ Ｒａｄｉｏ Ｕｎｉｔ）、無線ヘッダ（ＲＨ：Ｒａｄｉｏ Ｈｅａｄｅｒ）、リモート無線ヘッド（ＲＲＨ：Ｒｅｍｏｔｅ Ｒａｄｉｏ Ｈｅａｄ）、リレー、及びフェムト、ピコなどの低電力ノードなどを指す。

「端末デバイス」という用語は、「ユーザ機器（ＵＥ：Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）」及びネットワークデバイスと通信可能な他の適切なエンドデバイスを含むが、これらに限定されない。例示として、「端末デバイス」は、端末、モバイル端末（ＭＴ：Ｍｏｂｉｌｅ Ｔｅｒｍｉｎａｌ）、加入者局（ＳＳ：Ｓｕｂｓｃｒｉｂｅｒ Ｓｔａｔｉｏｎ）、携帯型加入者局（Ｐｏｒｔａｂｌｅ Ｓｕｂｓｃｒｉｂｅｒ Ｓｔａｔｉｏｎ）、移動局（ＭＳ：Ｍｏｂｉｌｅ Ｓｔａｔｉｏｎ）、又はアクセス端末（ＡＴ：Ａｃｃｅｓｓ Ｔｅｒｍｉｎａｌ）を指し得る。

次に、本開示のいくつかの例示的な実施形態を、図面を参照して以下に説明する。まず図１を参照する。図１は、ＨＡＲＱ確認応答のフィードバックの従来のスキームの概略図１００を示す。

図１の実施形態は、ＬＡＡにおけるＨＡＲＱ−ＡＣＫのフィードバックを示す。該実施形態では、ダウンリンクデータは、アンライセンスバンドを介して物理ダウンリンク共有チャネル（ＰＤＳＣＨ：Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ）で送信され、ＨＡＲＱ−ＡＣＫは、ライセンスバンド上のＰＵＣＣＨを介して送信される。ライセンスされていないＰＤＳＣＨ（フレーム構造３）でのタイミングは、周波数分割複信（ＦＤＤ：Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｄｕｐｌｅｘｉｎｇ）（フレーム構造１）のタイミングとして扱われる。つまり、プライマリセル（Ｐｃｅｌｌ：Ｐｒｉｍａｒｙ Ｃｅｌｌ）がＦＤＤである場合、サブフレームｎでのＰＤＳＣＨは、サブフレームＮ＋４でのライセンスされたＰＵＣＣＨにフィードバックする。

従って、従来のＨＡＲＱ−ＡＣＫフィードバックはタイミングベースであることが分かる。つまり、ＨＡＲＱ−ＡＣＫ ＵＬスロットとスケジュールされたＰＤＳＣＨスロットとの間のタイミングが決定される。例えば、ＬＴＥ−ＦＤＤの場合は４サブフレームであり、ＴＤ−ＬＴＥの場合はｋサブフレームであり、ｋはＴＤＤ構成で決定できる。

ＮＲシステムの場合、タイミングｋは、ダウンリンク制御情報（ＤＣＩ：Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）によって示されてもよく、無線リソース制御（ＲＲＣ：Ｒａｄｉｏｎ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）によって静的に構成されもよい。これらすべてのライセンスバンドの移動通信システムは、事前に定義・決定されたタイミングベースのＨＡＲＱ−ＡＣＫフィードバックを使用する。アンライセンスバンドＬＡＡの場合、ＨＡＲＱ−ＡＣＫフィードバックＰＵＣＣＨはライセンスバンドで配信されるため、従来のタイミングベースの方法も使用される。

しかしながら、ＮＲがアンライセンスバンドにスタンドアロンで配備される場合、ＤＬとフィードバックＵＬとの間のタイミング間隔が閾値よりも長いとき、リッスンビフォアトーク（ＬＢＴ：Ｌｉｓｔｅｎ Ｂｅｆｏｒｅ Ｔａｌｋ）の失敗により、タイミングベースのフィードバックがブロックされることがある。

上記及び他の潜在的な問題を解決するために、本開示の実施形態は、アンライセンスバンドでのＨＡＲＱ−ＡＣＫのフィードバックのための解決策を提供する。提案される解決策において、ＰＤＳＣＨは、最大チャネル占有時間（ＭＣＯＴ：Ｍａｘｉｍｕｍ Ｃｈａｎｎｅｌ Ｏｃｃｕｐｉｅｄ Ｔｉｍｅ）内で連続的に送信し、且つトリガされるとフィードバックすることができる。特に、ネットワークデバイスは、ＨＡＲＱ−ＡＣＫのフィードバックモードを示す第１のトリガを送信する。ＨＡＲＱ確認応答に割り当てられたアンライセンスバンドへの成功したアクセスに応答して、ネットワークデバイスは、第１のトリガで示されるフィードバックモードに基づいてＨＡＲＱ−ＡＣＫをフィードバックする少なくとも１つのターゲット端末デバイスを示す第２のトリガをさらに送信する。２つのトリガを使用すると、ＬＢＴによるブロックの可能性を大幅に低減できる。

本開示の実施形態を、以下の図を参照してより詳細に説明する。図２は、本開示の実施形態に係る、ＨＡＲＱ確認応答のフィードバックの方法２００のフローチャートを示す。方法２００により、従来のアプローチにおける上記及び他の潜在的な欠陥を克服することができる。方法２００が例えばｇＮＢなどのネットワークデバイスによって実施され得ることは、当業者にとって理解できる。

方法２００は２１０で開始される。２１０において、ネットワークデバイスは、ＨＡＲＱ確認応答のフィードバックモードを示す第１のトリガを、端末デバイスに送信する。フィードバックモードは、トリガモード、タイミングモード、及び混合モードの少なくとも１つから選択される。

本開示の実施形態によれば、トリガモードは、ＨＡＲＱ−ＡＣＫがトリガ、即ち、上記した第１及び第２のトリガに応じてフィードバックされるモードを表す。タイミングモードは、ＨＡＲＱ−ＡＣＫがタイミングに基づいてフィードバックされるモードを表す。混合モードは、タイミングモードが最初に試行されるが、失敗した場合、端末デバイスがトリガを待つモードである。

いくつかの実施形態では、第１のトリガは、ＨＡＲＱ確認応答によってフィードバックされるスロット及び／又はサブフレーム、ＨＡＲＱ確認応答の送信用に割り当てられたリソース（以下、「割り当てリソース」又は「ＰＵＣＣＨリソース」とも呼ばれる）、フィードバックタイミング、及び／又はその他を含むＨＡＲＱ確認応答グループをさらに示してもよい。

いくつかの実施形態では、タイミングモードにおいて、１つ又は複数のビットフィールドを使用してフィードバックタイミングを示してもよい。トリガモード又は混合モードでは、同じビットフィールドがＨＡＲＱ−ＡＣＫグループ及び割り当てリソースとして再解釈されてもよい。

いくつかの実施形態では、ＨＡＲＱ確認応答グループは、第１のトリガが送信された後のすべてのスケジュール可能なサブフレームを含んでもよい。言い換えれば、すべてのスケジュール可能なサブフレームのＨＡＲＱ確認応答は、前回のトリガ以降、スケジュールされた順序でフィードバックされてもよい。

あるいは、いくつかの実施形態では、ＨＡＲＱ確認応答グループは、スケジュール可能なサブフレームの一部のみを含んでもよい。例えば、システムの原理、仕様などに応じてトリガウィンドウを設定してもよい。トリガウィンドウに繰り返される新しいデータＨＡＲＱプロセスがないと仮定すると、すべてのＨＡＲＱプロセスは、いくつかのグループに分割されてもよく、且つ１つ以上のグループがフィードバックされてもよい。別の例では、トリガウィンドウにおけるすべてのスケジュール可能なサブフレームは、ＨＡＲＱ確認応答グループによって示されてもよい。ＨＡＲＱ確認応答グループにおいて、ウィンドウサイズは、第２のトリガに関連付けられたＤＣＩで示されてもよい。

２２０において、ＨＡＲＱ確認応答に割り当てられたアンライセンスバンドへの成功したアクセスに応答して、ネットワークデバイスは、第２のトリガを端末デバイスに送信する。第２のトリガは、第１のトリガによって示されるフィードバックモードに基づいてＨＡＲＱ確認応答をフィードバックする１つ又は複数の端末デバイス（以下、「ターゲット端末デバイス」とも呼ばれる）を示す。例えば、第２のトリガは、ターゲット端末デバイスの識別子を含んでもよい。

いくつかの実施形態では、第２のトリガは、すべての端末デバイスがＨＡＲＱ確認応答をフィードバックすることを示す共通トリガである。つまり、この場合、すべての端末デバイスはターゲット端末デバイスである。

あるいは、第２のトリガは、１つ又は複数の専用端末デバイスがＨＡＲＱ確認応答をフィードバックすることを示す専用トリガであってもよい。この場合、ターゲット端末デバイスは、専用端末デバイスのみを含む。

上記に加えて、又は代替として、第２のトリガは、フィードバックが、割り当てリソースで実行されることをさらに示してもよい。

本開示の実施形態によれば、方法２００は、第２のトリガに関連付けられた送信から一定の時間間隔の後に、１つ又は複数のターゲット端末デバイスからＨＡＲＱ確認応答を受信するステップをさらに含んでもよい。いくつかの実施形態では、上記の時間間隔は、２５μｓとして設定されてもよい。

上記した実施形態の説明によれば、ＬＢＴの失敗によるＨＡＲＱ−ＡＣＫのフィードバックのブロックの可能性を大幅に低減することができ、送信効率を効果的に改善することができる。

図３を参照してさらに詳細に説明する。図３は、本開示の実施形態に係る、ＨＡＲＱ確認応答のフィードバックの概略図３００を示す。

トリガベースのＨＡＲＱ−ＡＣＫフィードバックにおいて、第１のトリガは、スケジュールされた各ＰＤＳＣＨ送信においてＤＣＩで送信されてもよい。第１のトリガは、トリガモード、タイミングモード、又は混合モードのうちの１つのＨＡＲＱ−ＡＣＫフィードバックモードを示す１又は２ビットを含む情報を運んでもよい。トリガモードは、ＤＣＩで示されるＰＤＳＣＨに関連付けられたＨＡＲＱ−ＡＣＫフィードバックの送信が保留され、且つ第２のトリガがアクティブになることを待つことを意味する。タイミングモードは、ＤＣＩで示されるＰＤＳＣＨに関連付けられたＨＡＲＱ−ＡＣＫフィードバックの送信が、ＤＣＩで示されるタイミング情報に基づいて送信していることを意味する。混合モードは、ＤＣＩで示されるＰＤＳＣＨに関連付けられたＨＡＲＱ−ＡＣＫフィードバックの送信が、最初にＤＣＩで示されるタイミング情報に基づいて送信していることを意味する。ＬＢＴに起因してタイミング送信が失敗した場合、ＤＣＩで示されるＰＤＳＣＨに関連付けられたＨＡＲＱ−ＡＣＫフィードバックの送信は保留され、且つ第２のトリガがアクティブになることを待つ。

第２のトリガは、アップリンクＨＡＲＱ−ＡＣＫフィードバック送信をトリガするために使用されてもよい。ネットワークデバイス、例えばｇＮＢは、チャネルアクセスを取得すると、ＤＣＩ内で示された第２のトリガ情報を送信する。第２のトリガは、共通のＲＮＴＩによってスクランブルされたＤＣＩにおける共通トリガ、又は専用のＲＮＴＩによってスクランブルされた専用トリガであってもよい。第２のトリガは、ＰＵＣＣＨリソースに関する情報、及びダウンリンク送信の完了を示す時間情報を運んでもよい。端末デバイス、例えば、ＵＥは、ダウンリンク送信の完了から一定の時間間隔の後にＨＡＲＱ−ＡＣＫを送信してもよい。上記の時間間隔は、より良い共存のために２５μsであってもよい。このようにして、ＨＡＲＱ−ＡＣＫフィードバックは、より良い制御で実行されることができる。

端末デバイスは、ＨＡＲＱ−ＡＣＫを送信する前に、まずそのＨＡＲＱ−ＡＣＫグループを決定し、次に、対応するグループのＨＡＲＱ−ＡＣＫ情報をフィードバックする。ＨＡＲＱ−ＡＣＫグループには、ＨＡＲＱ確認応答によってフィードバックされるスロット、及び／又はサブフレームが含まれる。

ＵＥのためのＨＡＲＱ−ＡＣＫグループの１つの例として、ＨＡＲＱ−ＡＣＫグループスロットは、前回のＨＡＲＱ−ＡＣＫフィードバック送信以来の、ＵＥの最小フィードバックスロットの構成よりも早くない、すべてのスケジュールされたＰＤＳＣＨスロットである。共通トリガである第２のトリガがＵＥによって受信されると、ＵＥは、すべてのＵＥがそれぞれの事前定義されたリソースで、それぞれのＨＡＲＱ−ＡＣＫグループに対応するＨＡＲＱ−ＡＣＫをフィードバックすることを認識する。図３に示すように、ＵＥは、前回のフィードバック以来、スロット１、２、３、４においてＤＣＩトリガモードによって示されるＰＤＳＣＨを受信する。この場合、ＨＡＲＱ−ＡＣＫグループは{１,２,３,４}である。ＵＥは、スロット９において共通のＲＮＴＩによってスクランブルされた第２のトリガＤＣＩを正常にデコードすると、その割り当てリソースで、ＨＡＲＱ−ＡＣＫグループ{１,２,３,４}のＨＡＲＱ−ＡＣＫをｇＮＢにフィードバックする。

ＨＡＲＱ−ＡＣＫグループの別の例として、スロットがグループに分割され、且つ各グループがＨＡＲＱ−ＡＣＫグループに周期的に対応する。例えば、各グループにおけるスロット数は４であり、グループサイズは５である。つまり、絶対スロット０、１、２、３はグループ０、絶対スロット４、５、６、７はグループ１、…、絶対スロット１６、１７、１８、１９はグループ４、絶対スロット２０、２１、２２、２３はグループ０であるように周期的になる。図３に示すように、ＵＥは、スロット９において、第２のトリガを含み且つ専用のＲＮＴＩによってスクランブルされたＤＣＩを正常にデコードした。これにより、ＵＥは、第２のトリガがフィードバックＨＡＲＱ−ＡＫＣグループインデックス０を示すことを知ることができる。そして、示されるグループインデックスを有する最も近いグループはこの時機で送信される。例えば、スロット０、１、２、３はフィードバックである場合、スロット０にＰＤＳＣＨがなく、スロット４にＰＤＳＣＨがあるにもかかわらず、スロット０はこのフィードバックでＰＤＣＣＨが受信されないことを示すように、不連続送信（ＤＴＸ：Ｄｉｓｃｏｎｔｉｎｕｏｕｓ Ｔｒａｎｓｍｉｓｓｉｏｎ）をフィードバックするとともに、スロット４はグループインデックス１を示す時機を待つ必要がある。グループインデックスの表示はビットマップであってもよい。ビットマップは、グループ０とグループ１を一つの第２のトリガの専用ＤＣＩで同時に指示できることを意味する。

いくつかの実施形態では、ＨＡＲＱ−ＡＣＫのフィードバックは、様々な方法で符号化されることができる。例えば、コードワードごとに２つのサブフレームフィードバックに対する３つのＨＡＲＱビットは、以下のように実施されてもよい。この場合、２つのサブフレームには９つの状態があり、１つのコードワードの３ビットには８つの状態がある。従って、２対１のマッピングが少なくとも１つあり、残りは１対１のマッピングである。「ＮＡＣＫ ＮＡＣＫ」と「ＤＴＸ ＤＴＸ」はチャネル状態が悪いことを意味するため、これらを１つのコードワードに符号化することができる。残りは、各コードワードへの１対１のマッピングである。このように、PＤＣＣＨの検出の失敗によるｇＮＢとＵＥとの間のミスマッチは、ほぼ１対１のマッピングで解決できる。表１には、ＨＡＲＱビットの符号化の例が示される。

上記したＨＡＲＱ−ＡＣＫの符号化の例は、限定ではなく例示のために説明されると理解されるべきである。当業者は、符号化が本開示の範囲内で他の適切な方法で実施可能であることを理解できる。

ここで、本開示のさらなる実施形態を以下のように説明する。

一般に、アンライセンスバンドでの送信の前に、ネットワークノードは、チャネルの状態、即ちチャネルがビジーであるかアイドルであるかを感知する必要がある。チャネルが一定の時間でアイドル状態であると検知した後、ネットワークノードは該チャネルにアクセスできる。このプロセスは、クリアチャネルアクセス（ＣＣＡ：Ｃｌｅａｒ Ｃｈａｎｎｅｌ Ａｃｃｅｓｓ）又はＬＢＴと呼ばれる。

ＬＡＡでは、ＬＢＴの４つのカテゴリー、即ちＣａｔ.１〜４が特定される。最も頻繁に使用される２つのタイプは次のとおりである。

Ｃａｔ.２：バックオフなしのＬＢＴ、例えば、２５μsＬＢＴ；

Ｃａｔ.４：ランダムバックオフを伴うＬＢＴ、例えば、ウィンドウサイズが７であり、最初に乱数[０、７]を生成し、例として３を取る。ＬＢＴ時間は３４+３*９=６１μsである。

最大チャネル占有時間（ＭＣＯＴ）は、単一のアクセスの最大占有時間である。ＭＣＯＴにおいて、ｃａｔ.２ ＬＢＴを使用できる。ＭＣＯＴの外部では、公正な共存のために、Ｃａｔ.４ ＬＢＴが必要である。

本開示の実施形態によれば、スタンドアロンＮＲのアンライセンスバンドＨＡＲＱ−ＡＣＫフィードバックのより良い性能及びより簡便な実施を達成するために、ＨＡＲＱタイミングは、ＬＢＴを満たすように、自己充足型フィードバックのために設計される。

いくつかの実施形態では、ＬＢＴのための特定のＴＡオフセット、断片及び／又は完全な直交周波数分割多重（ＯＦＤＭ：Ｏｒｔｈｏｇｏｎａｌ Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅｘｉｎｇ）シンボルが、ＨＡＲＱタイミングのために使用される。

ＣＣＡの成功後、ネットワークデバイス、例えばｇＮＢは、ダウンリンクデータを端末デバイス、例えばＵＥに送信し始める。ｇＮＢによる送信が完了すると、ＵＥは、チャネルが一定の時間間隔（「ｔ_ａｃｋ」として示される「ギャップ」とも呼ばれる）にわたってアイドルであると感知した後、ＨＡＲＱ−ＡＣＫをフィードバックすることができる。いくつかの実施形態では、ギャップの長さは、２５μｓに設定されてもよい。つまり、ｔ_ａｃｋ=２５μsである。

図４は、本開示の実施形態に係る、ＨＡＲＱ確認応答のフィードバックの概略図４００を示す。図４に示すように、ｇＮＢは、アップリンクＨＡＲＱ−ＡＣＫフィードバック信号に続くギャップｔ_ａｃｋにわたって、チャネルがアイドルであると感知した後、ダウンリンクデータを送信し続けることができる。ギャップは、図４で４１０によって示されている。

アンライセンスバンドの場合、参照ＴＡオフセットは少なくともｔ_ａｃｋ、即ち７６８Ｔｓ（７６８＊６４Ｔｃ、２５μｓ）である。ＬＴＥ−ＦＤＤの場合、参照ＴＡオフセットは０Ｔsであり、ＬＴＥ−ＴＤＤの場合、参照ＴＡオフセットは６２４Ｔs（２０.３１２５μs）である。

ＰＤＳＣＨデータとＰＵＣＣＨ ＨＡＲＱ−ＡＣＫとの間のタイミングは、ＤＣＩで示されてもよい。図５は、本開示の実施形態に係る、ＨＡＲＱ確認応答のフィードバックの概略図５００を示す。具体的に、図５は、２サブフレームのタイミング遅延の例を示す。ＭＣＯＴにおいて、Ｃａｔ.２ ＬＢＴが送信に使用される。

カバレッジの点から、ＰＵＣＣＨフィードバックは、ＨＡＲＱ_ＡＣＫフィードバックのためのＰＵＣＣＨフォーマットシンボル長Ｎ_ＰＵＣＣＨ及びＰＵＣＣＨリソースシンボル長Ｎ_ＡＣＫに基づいて繰り返されてもよい。Ｎ_ＰＵＣＣＨは上位層又はＤＣＩによって示されるフォーマットであり、Ｎ_ＡＣＫはＤＣＩ又はＲＲＣによって示されてもよく、スロットフォーマット表示（ＳＦＩ：Ｓｌｏｔ Ｆｏｒｍａｔ Ｉｎｄｉｃａｔｉｏｎ）構成によって計算されてもよい。

例えば、ＰＵＣＣＨフォーマット１では、Ｎ_ＰＵＣＣＨ＝２である。ＳＦＩは、ＤＬのための９つのＯＦＤＭシンボルを示すので、１５ＫＨｚサブキャリア間隔（ＳＣＳ：Ｓｕｂｃａｒｒｉｅｒ Ｓｐａｃｉｎｇ）のために、３つの完全なシンボルと１つの断片シンボル（６６．７＋４．７−２５−２５＝２１．４μｓ）が残っている。

本開示の実施形態によれば、断片シンボルの開始位置及び完全シンボルの繰り返しを計算する方法はいくつかあり得る。

いくつかの実施形態では、任意の物理チャネル又は信号用のサブフレームにおけるＯＦＤＭシンボル

のためのアンテナポート

及びサブキャリア間隔構成

での時間連続信号

は、

内で送信される。本実施形態では、時間領域における様々なフィールドのサイズは、複数の時間単位

として表され、ここで、

Ｈｚであり、

である。

サブフレームにおけるサブキャリア間隔構成

のためのＯＦＤＭシンボル

の開始位置は、以下のように与えられる。

（１）
ただし、

は、断片シンボルの開始ＯＦＤＭシンボルを示し、

は、ＰＤＳＣＨシンボルの終了を示す。

は時間間隔である。ここで、

は、ｇＮＢによってシグナリングされるタイミングアドバンス（ＴＡ）であり、Ｔ_ｇａｐは、ダウンリンクとアップリンクの切り替え時間の間隔である。いくつかの実施形態では、Ｔ_ｇａｐは、アンライセンスバンドで２５μｓに設定される。

は、アップリンクＨＡＲＱ−ＡＣＫ送信のためのＰＵＣＣＨ ＯＦＤＭシンボルの長さであり、

は、サンプルレート

に対応する断片ＯＦＤＭシンボル内の開始サンプルである。

上記の定義により、ＵＥは、以下のように、断片シンボルの開始ＯＦＤＭシンボル

及び断片ＯＦＤＭシンボル内の開始サンプル

を計算することができる。

（２）

ＵＥによって送信される時間連続信号

は、以下のように定義される。

が

である場合、即ち、断片シンボルの場合、

（３）
そうではない場合、即ち、完全シンボルの場合、

（４）

このようにして、ＵＥは、任意のサブキャリア間隔構成

において、間隔Ｔ_ｇａｐの後、アップリンク信号、例えば、ＨＡＲＱ−ＡＣＫを送信し始めることができる。断片シンボルと完全シンボルの適切な繰り返しは、受信機の多様性のために提供されることができる。

図６は、本開示の実施形態に係る、ＨＡＲＱ確認応答のフィードバックの概略図６００を示す。特に、図６は、ＳＣＳ １５ＫＨｚのための２つの完全シンボルＰＵＣＣＨ及び１つの断片シンボルＰＵＣＣＨの例を示し、ここで、断片シンボルはシンボル１１で生成され、完全シンボルはシンボル１２及び１３でそれぞれ生成される。

図７は、本開示の実施形態に係る、ＨＡＲＱ確認応答のフィードバックの概略図７００を示す。特に、図７は、１つのサブフレーム内のＳＣＳ ６０ＫＨｚの例を示す。図７に示すように、１つの断片シンボルと４つの完全シンボルがある。完全シンボルには、２つのＰＵＣＣＨシンボルと２つの繰り返しシンボルが含まれる。ギャップの期間は、１シンボル以上続く。

スロット全体がＰＵＣＣＨ用である場合、式（２）〜（４）に基づいて、断片シンボル２で送信を開始する。断片スロットがＰＵＣＣＨ用である場合、ＰＤＳＣＨマルチスロットスケジューリングは、ＰＵＣＣＨフィードバックスロットにおけるＤＬ ＯＦＤＭの終了シンボルを示すべきである。トランスポートブロックは、ＤＬ ＯＦＤＭシンボルの合計に基づいてレートマッチングされる。

以下、本開示のさらなる実施形態を説明する。

ＨＡＲＱ−ＡＣＫのフィードバックのために、特に、時折又はウィンドウベースのフィードバックのために、リソース割り当てのメカニズムが必要である。当該問題及び潜在的な関連問題を解決するために、本開示の実施形態は、ＨＡＲＱ−ＡＣＫウィンドウのためのＨＡＲＱ−ＡＣＫのリソース割り当て及び／又は符号化の解決策を提供する。

図８は、本開示の実施形態に係る、ＨＡＲＱ確認応答のフィードバックの概略図８００を示す。図８に示す例では、ＰＤＳＣＨが時間ウィンドウ（例えば、最大チャネル占有時間（ＭＣＯＴ））内でフィードバックできない場合、タイマーを開始することができる。この例では、タイムウィンドウは「ＭＣＯＴ１」と呼ばれ、サブフレーム１〜３を含む。タイマーが切れる前に別のＭＣＯＴ（「ＭＣＯＴ２」と呼ばれる）が検出されると、ＨＡＲＱ−ＡＣＫはＭＣＯＴ２においてフィードバックされることができる。それ以外の場合、ＨＡＲＱ−ＡＣＫは別のタイミングでフィードバックされるか、廃棄されることができる。

いくつかの実施形態では、ＵＥは、ＬＢＴの失敗によりフィードバックできない場合、「ＨＡＲＱ−ＡＣＫウィンドウ」とも呼ばれる時間ウィンドウ内で次のフィードバック時機を待つことができる。ＵＥは、フィードバックの時機にチャネルにアクセスできる場合、現在のＨＡＲＱ−ＡＣＫの情報と、ＬＢＴの失敗によりブロックされた以前のＨＡＲＱ−ＡＣＫの情報とをフィードバックすることができる。

図９は、本開示の実施形態に係る、ＨＡＲＱ確認応答のフィードバックの概略図９００を示す。図９に示す例では、ＨＡＲＱ−ＡＣＫウィンドウは４であり、つまり、ＨＡＲＱ−ＡＣＫウィンドウが４つのサブフレームを含む。サブフレーム１〜３では、ＵＥはチャネルにアクセスできず、且つ位置９１０、９２０、及び９３０でＨＡＲＱ−ＡＣＫをフィードバックできない。この例では、ＵＥはサブフレーム４でチャネルへのアクセスに成功するので、位置９４０でＨＡＲＱ−ＡＣＫをフィードバックする。

いくつかの実施形態では、ＨＡＲＱ−ＡＣＫフィードバックのための符号化スキームがいくつあり、例えば、複数のコードブック、バンドリング、及び部分バンドリングに基づくスキームがある。

複数のコードブックのスキームを使用する実施形態では、ｎ_１が１回目の時機でのリソースであると仮定すると、ｉ回目の時機では、リソースｎ_ｉは以下のように表されることができる。

（５）
ここで、

はＰＵＣＣＨリソースの数を示し、

はＨＡＲＱ−ＡＣＫウィンドウサイズを示す。

バンドリングのスキームを使用する実施形態では、ＨＡＲＱ−ＡＣＫウィンドウでフィードバックされる必要があるすべてのＨＡＲＱ−ＡＣＫは、１つのＨＡＲＱ−ＡＣＫ、例えば、１ビットにバンドルされる。図９に示す例をさらに参照すると、サブフレーム１〜４におけるダウンリンク（ＤＬ）データがＵＥによって正しく受信される場合、ＵＥは、肯定のＨＡＲＱ−ＡＣＫ、例えば、「１」又は「ＡＣＫ」をｇＮＢに送信する。サブフレーム１〜４におけるＤＬデータのいずれかがＵＥによって正しく受信されない場合、ＵＥは、否定のＨＡＲＱ−ＡＣＫ、例えば「０」又は「ＮＡＣＫ」をｇＮＢに送信する。

部分バンドリングのスキームを使用する実施形態では、リソースｎは現在のタイミングのＨＡＲＱ−ＡＣＫによって使用され、ウィンドウ内の以前のすべてのＨＡＲＱ−ＡＣＫは、別の事前に定義されたリソース、例えばｎ＋１を使用して、１つのＨＡＲＱ−ＡＣＫ、例えば１ビットにバンドルされる。図９に示す例をさらに参照すると、部分バンドリングが採用されている場合、サブフレーム４で送信されるＤＬデータのＨＡＲＱ−ＡＣＫはリソースｎで送信されるとともに、サブフレーム１〜３で送信されるＤＬデータのＨＡＲＱ−ＡＣＫは、リソースｎ＋１で送信される１ビットにバンドルされる。

図１０は、本開示の実施形態に係る、ＨＡＲＱ確認応答のフィードバックの方法１０００のフローチャートを示す。方法１０００は、端末デバイス、例えばＵＥによって実施されることができる。

方法１０００は１０１０で開始される。１０１０において、端末デバイスは、ネットワークデバイスから、ＨＡＲＱ確認応答のフィードバックモードを示す第１のトリガを受信する。フィードバックモードは、トリガモード、タイミングモード、及び混合モードの少なくとも１つから選択される。

本開示の実施形態によれば、トリガモードは、ＨＡＲＱ−ＡＣＫがトリガ、即ち、説明した第１及び第２のトリガに応じてフィードバックされるモードを表す。タイミングモードは、ＨＡＲＱ−ＡＣＫがタイミングに基づいてフィードバックされるモードを表す。混合モードは、タイミングモードが最初に試行されるが、失敗した場合、端末デバイスがトリガを待つモードである。

いくつかの実施形態では、第１のトリガは、ＨＡＲＱ確認応答によってフィードバックされるスロット及び／又はサブフレーム、ＨＡＲＱ確認応答の送信用に割り当てられたリソース、フィードバックタイミング、及び／又はその他を含むＨＡＲＱ確認応答グループをさらに示してもよい。

いくつかの実施形態では、ＨＡＲＱ確認応答グループは、第１のトリガが送信された後のすべてのスケジュール可能なサブフレームを含んでもよい。言い換えれば、すべてのスケジュール可能なサブフレームのＨＡＲＱ確認応答は、前回のトリガ以降、スケジュールされた順序でフィードバックされてもよい。

１０２０において、フィードバックモードがトリガモード又は混合モードであることに応答して、端末デバイスは、ネットワークデバイスからの第２のトリガを検出する。第２のトリガは、第１のトリガによって示されるフィードバックモードに基づいてＨＡＲＱ確認応答をフィードバックすることになる１つ又は複数の端末デバイス（以下、「ターゲット端末デバイス」とも呼ばれる）を示す。例えば、第２のトリガは、ターゲット端末デバイスの識別子を含んでもよい。

いくつかの実施形態では、第２のトリガは、すべての端末デバイスがＨＡＲＱ確認応答をフィードバックすることを示す共通トリガである。つまり、この場合、すべての端末デバイスはターゲット端末デバイスである。

あるいは、第２のトリガは、１つ又は複数の専用端末デバイスがＨＡＲＱ確認応答をフィードバックすることを示す専用トリガであってもよい。この場合、ターゲット端末デバイスは、専用端末デバイスのみを含む。

上記に加えて、又は代替として、第２のトリガは、フィードバックが、割り当てリソースで実行されることをさらに示してもよい。

本開示の実施形態によれば、端末デバイスは、該端末デバイスが第２のトリガに基づいてＨＡＲＱ確認応答をフィードバックするか否かをさらに決定してもよい。例えば、端末デバイスは、第２のトリガで示されたターゲット端末デバイスの識別に基づいて、それ自体がターゲット端末デバイスであるか否かを決定してもよい。端末デバイスは、それ自体がＨＡＲＱ確認応答をフィードバックすると決定した場合、第２のトリガに関連付けられた受信から一定の時間間隔の後に、ＨＡＲＱ確認応答をネットワークデバイスに送信する。

次に、図１１を参照する。図１１は、本開示の実施形態に係る、ネットワークデバイスで実装される装置１１００のブロック図を示す。装置１１００は、ネットワークデバイス、例えば、ｇＮＢで実装され得ることが理解すべきである。

図示されるように、装置１１００は、第１の送信ユニット１１１０及び第２の送信ユニット１１２０を含む。第１の送信ユニット１１１０は、ＨＡＲＱ確認応答のフィードバックモードを示す第１のトリガを、端末デバイスに送信するように構成される。フィードバックモードは、トリガモード、タイミングモード、及び混合モードの少なくとも１つから選択される。第２の送信ユニット１１２０は、ＨＡＲＱ確認応答に割り当てられたアンライセンスバンドへの成功したアクセスに応答して、端末デバイスに第２のトリガを送信するように構成される。該第２のトリガは、第１のトリガで示されるフィードバックモードに基づいてＨＡＲＱ確認応答をフィードバックする少なくとも１つのターゲット端末デバイスを示す。

いくつかの実施形態では、第１のトリガは、ＨＡＲＱ確認応答によってフィードバックされるスロット及び／又はサブフレームを含むＨＡＲＱ確認応答グループ、ＨＡＲＱ確認応答の送信用に割り当てられたリソース、及びフィードバックタイミングのうちの少なくとも１つをさらに示す。

いくつかの実施形態では、ＨＡＲＱ確認応答グループは、第１のトリガが送信された後のスケジュール可能なサブフレームのすべて又は一部を含む。

いくつかの実施形態では、第２のトリガは、すべての端末デバイスがＨＡＲＱ確認応答をフィードバックすることを示す共通トリガである。あるいは、第２のトリガは、専用端末デバイスがＨＡＲＱ確認応答をフィードバックすることを示す専用トリガである。

いくつかの実施形態では、装置１１００は、第２のトリガに関連付けられた送信から一定の時間間隔の後に、ターゲット端末デバイスからＨＡＲＱ確認応答を受信するように構成される受信ユニットをさらに含んでもよい。

図１２は、本開示の実施形態に係る、端末デバイスで実装される装置１２００のブロック図を示す。装置１２００は、端末デバイス、例えばＵＥで実装され得ることが理解されるべきである。

図示されるように、装置１２００は、第１の受信ユニット１２１０及び第２の受信ユニット１２２０を含む。第１の受信ユニット１２１０は、ネットワークデバイスから、ＨＡＲＱ確認応答のフィードバックモードを示す第１のトリガを受信するように構成される。フィードバックモードは、トリガモード、タイミングモード、及び混合モードの少なくとも１つから選択される。第２の受信ユニット１２２０は、フィードバックモードがトリガモード又は混合モードであることに応答して、ネットワークデバイスから、ＨＡＲＱ確認応答をフィードバックする少なくとも１つのターゲット端末デバイスを示す第２のトリガを検出するように構成される。

いくつかの実施形態では、第１のトリガは、ＨＡＲＱ確認応答によってフィードバックされるスロット及び／又はサブフレームを含むＨＡＲＱ確認応答グループ、ＨＡＲＱ確認応答の送信用に割り当てられたリソース、及びフィードバックタイミングのうちの少なくとも１つをさらに示す。

いくつかの実施形態では、ＨＡＲＱ確認応答グループは、第１のトリガが送信された後のスケジュール可能なサブフレームのすべて又は一部を含む。

いくつかの実施形態では、第２のトリガは、すべての端末デバイスがＨＡＲＱ確認応答をフィードバックすることを示す共通トリガである。あるいは、第２のトリガは、専用端末デバイスがＨＡＲＱ確認応答をフィードバックすることを示す専用トリガである。

いくつかの実施形態では、装置１１００は、第２のトリガに基づいて端末デバイスがＨＡＲＱ確認応答をフィードバックするか否かを決定するように構成される決定ユニットと、端末デバイスがＨＡＲＱ確認応答をフィードバックするとの決定に応答して、第２のトリガに関連付けられた受信から一定の時間間隔の後に、ＨＡＲＱ確認応答をネットワークデバイスに送信するように構成される送信ユニットと、をさらに含んでもよい。

また、装置１１００又は１２００は、現在知られている、又は将来開発される任意の適切な技術によってそれぞれ実現され得ることにも留意されたい。さらに、図２又は図１０に示される単一のデバイスが複数のデバイスで別々に実現されてもよく、複数の別々のデバイスが単一のデバイスに実現されてもよい。本開示の範囲はこれらの点で限定されない。

装置１１００又は１２００は、図２又は１０を参照して説明した機能を実現するように構成されてもよいことに留意されたい。従って、方法２００に関して説明した特徴は、装置１１００の対応するコンポーネントに適用されてもよく、方法１０００に関して説明した特徴は、装置１２００の対応するコンポーネントに適用されてもよい。さらに、装置１１００又は１２００のコンポーネントは、ハードウェア、ソフトウェア、ファームウェア、及び／又はそれらの任意の組合せで実現され得ることに留意されたい。例えば、装置１１００又は１２００のコンポーネントは、回路、プロセッサ、又は任意の他の適切なデバイスによってそれぞれ実現されてもよい。当業者は、前述の例が、限定ではなく、例示に過ぎないことを理解できる。

本開示のいくつかの実施形態では、装置１１００又は１２００は、少なくとも１つのプロセッサを備えてもよい。本開示の実施形態とともに使用するのに適する少なくとも１つのプロセッサは、例示として、知られている又は将来開発される汎用及び専用のプロセッサを含んでもよい。装置１１００又は１２００は、少なくとも１つのメモリをさらに備えてもよい。前記少なくとも１つのメモリは、例えば、ＲＡＭ、ＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭなどの半導体メモリデバイス、及びフラッシュメモリデバイスを含んでもよい。前記少なくとも１つのメモリは、コンピュータ実行可能な命令のプログラムを格納するために使用されてもよい。プログラムは、高レベル及び/又は低レベルのコンパイル可能又は解釈可能なプログラミング言語で作成されることができる。実施形態によれば、コンピュータ実行可能な命令は、少なくとも１つのプロセッサと協力して、装置１１００に少なくとも上記の方法２００に従うように動作させ、装置１２００に少なくとも上記の方法１０００に従うように動作させるように構成されてもよい。

上記の説明に基づいて、当業者は、本開示が装置、方法、又はコンピュータプログラム製品で具現化されることができることを理解できる。一般に、様々な例示的な実施形態は、ハードウェア又は専用回路、ソフトウェア、ロジック又はそれらの任意の組み合わせで実現されることができる。例えば、いくつかの態様はハードウェアで実現でき、他の態様は、コントローラ、マイクロプロセッサ、又は他のコンピューティングデバイスによって実行できるファームウェア又はソフトウェアで実現できるが、本開示はこれに限定されない。本開示の例示的な実施形態の様々な態様は、ブロック図、フローチャートとして、又は他のいくつかの図形表現を使用して図示及び説明されることができるが、本明細書に記載のこれらのブロック、装置、システム、技術又は方法は、非限定的な例として、ハードウェア、ソフトウェア、ファームウェア、専用回路又はロジック、汎用ハードウェア又はコントローラ又は他のコンピューティングデバイス、又はそれらのいくつかの組み合わせで実現されてもよい。

図１１又は図１２に示す様々なブロックは、方法ステップ、及び／又はコンピュータプログラムコードの動作により生じる動作、及び／又は関連する機能を実行するように構築された複数の結合された論理回路要素として見なされてもよい。本開示の例示的な実施形態の少なくともいくつかの態様は、集積回路チップ及びモジュールなどの様々なコンポーネントで実施されてもよく、本開示の例示的な実施形態は、本開示の例示的な実施形態に従って動作するように構成可能である集積回路、ＦＰＧＡ又はＡＳＩＣとして具現化される装置で実現されてもよい。

図１３は、本開示の実施形態を実施するのに適したデバイス１３００の簡略ブロック図である。図示されるように、デバイス１３００は、１つ又は複数のプロセッサ１３１０、プロセッサ１３１０に結合された１つ又は複数のメモリ１３２０、プロセッサ１３１０に結合された１つ又は複数の送信機及び／又は受信機（ＴＸ／ＲＸ）１３４０を含む。

プロセッサ１３１０は、ローカルの技術的ネットワークに適した任意のタイプであってもよく、非限定的な例として、汎用コンピュータ、専用コンピュータ、マイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、及びマルチコアプロセッサアーキテクチャに基づくプロセッサのうちの１つ又は複数を含んでもよい。デバイス１３００は、メインプロセッサを同期させるクロックに時間的に追従する特定用途向け集積回路チップなどのマルチプロセッサを有してもよい。

メモリ１３２０は、ローカルの技術的ネットワークに適した任意のタイプのものであってもよく、非限定的な例として、非一時的なコンピュータ読み取り可能な記憶媒体、半導体ベースのメモリデバイス、磁気メモリデバイス及びシステム、光学メモリデバイス及びシステム、固定メモリ及びリムーバブルメモリなど、任意の適切なデータストレージ技術を使用して実現されてもよい。

メモリ１３２０は、プログラム１３３０の少なくとも一部を格納する。ＴＸ／ＲＸ１３４０は、双方向通信のためのものである。ＴＸ／ＲＸ１３４０は、通信を容易にするための少なくとも１つのアンテナを有するが、実際には、本開示で言及される端末デバイス又はネットワークデバイスは、複数のアンテナを有してもよい。通信インターフェイスは、他のネットワーク要素との通信に必要な任意のインターフェイスを表してもよい。

プログラム１３３０は、関連するプロセッサ１３１０によって実行されると、デバイス１３００が、図２及び図１０を参照して説明したように、本開示の実施形態に従って動作することを可能にするプログラム命令を含むと想定される。即ち、本開示の実施形態は、デバイス１３００のプロセッサ１３１０によって実行可能なコンピュータソフトウェア、又はハードウェア、又はソフトウェアとハードウェアの組み合わせによって実現されることができる。

本明細書は多くの特定の実施の詳細を含むが、任意の開示の範囲又は請求される範囲に対する制限として解釈されるべきではなく、特定開示の特定実施形態に特有である特徴の説明として解釈されるべきである。本明細書において別々の実施形態で説明された特定の特徴は、単一の実施形態に組み合わせて実施されることもできる。逆に、単一の実施形態で説明された様々な特徴は、別々に、又は任意の適切なサブコンビネーションで複数の実施形態で実施されることもできる。さらに、特徴が特定の組み合わせで動作するものとして上記で説明され、当初はそのように特許請求されていても、請求された組み合わせからの１つ以上の特徴は、場合によっては、その組み合わせから除外されることができ、請求された組み合わせはサブコンビネーション又はサブコンビネーションのバリエーションに向けられてもよい。

同様に、動作は図面に特定の順序で示されているが、これらの動作が、示される特定の順序又は連続する順序で実行されること、又は望ましい結果を実現するために例示されるすべての動作が実行されることを要求すると理解されるべきではない。特定の状況では、マルチタスクと並列処理が有利である場合がある。さらに、上述の実施形態における様々なシステムコンポーネントの分離について、すべての実施形態においてそのような分離が必要となると理解されるべきではなく、説明されたプログラムコンポーネント及びシステムは、一般的に単一のソフトウェア製品に集積されるか、又は複数のソフトウェア製品にパッケージ化されることができると理解されるべきである。

前述の説明を考慮して添付の図面と併せて読むと、当業者にとって、本開示の前述の例示的な実施形態に対する様々な修正、適応は明らかになる。あらゆる修正は、依然として、本開示の非限定的かつ例示的な実施形態の範囲内にある。さらに、本明細書に記載の開示の他の実施形態は、本開示のこれらの実施形態に関係する分野の当業者が、前述の説明及び関連する図面に与えられた教示を受けて想到できるものである。

従って、本開示の実施形態は、開示された特定の実施形態に限定されず、修正及び他の実施形態は、添付の請求項の範囲内に含まれることが意図されると理解されるべきである。本明細書で特定の用語が使用されているが、これらの用語は一般的で説明的な意味でのみ使用され、限定を目的とするものではない。

Claims (14)

1. ハイブリッド自動再送要求（ＨＡＲＱ）確認応答のフィードバックモードを示す第１のトリガを端末デバイスに送信し、前記フィードバックモードは、トリガモード、タイミングモード、及び混合モードの少なくとも１つから選択されることと、
   前記ＨＡＲＱ確認応答に割り当てられたアンライセンスバンドへの成功したアクセスに応答して、前記端末デバイスに、前記第１のトリガで示される前記フィードバックモードに基づいて前記ＨＡＲＱ確認応答をフィードバックする少なくとも１つのターゲット端末デバイスを示す第２のトリガを送信することと、を含む、
   ネットワークデバイスで実施される方法。
2. 前記第１のトリガは、
   前記ＨＡＲＱ確認応答によってフィードバックされるスロット及び／又はサブフレームを含むＨＡＲＱ確認応答グループと、
   前記ＨＡＲＱ確認応答の送信用に割り当てられたリソースと、
   フィードバックタイミングと
   の少なくとも１つをさらに示す、
   請求項１に記載の方法。
3. 前記ＨＡＲＱ確認応答グループは、前記第１のトリガが送信された後のスケジュール可能なサブフレームの全部又は一部を含む、
   請求項２に記載の方法。
4. 前記第２のトリガは、すべての端末デバイスが前記ＨＡＲＱ確認応答をフィードバックすることを示す共通トリガであり、あるいは、
   前記第２のトリガは、専用端末デバイスが前記ＨＡＲＱ確認応答をフィードバックすることを示す専用トリガである、
   請求項１に記載の方法。
5. 前記第２のトリガに関連付けられた送信から一定の時間間隔の後に、ターゲット端末デバイスから前記ＨＡＲＱ確認応答を受信することをさらに含む、
   請求項１に記載の方法。
6. ネットワークデバイスから、ハイブリッド自動再送要求（ＨＡＲＱ）確認応答のフィードバックモードを示す第１のトリガを受信し、前記フィードバックモードは、トリガモード、タイミングモード、及び混合モードの少なくとも１つから選択されることと、
   前記フィードバックモードが前記トリガモード又は前記混合モードであることに応答して、前記ネットワークデバイスから、前記ＨＡＲＱ確認応答をフィードバックする少なくとも１つのターゲット端末デバイスを示す第２のトリガを検出することと、を含む、
   端末デバイスで実施される方法。
7. 前記第１のトリガは、
   前記ＨＡＲＱ確認応答によってフィードバックされるスロット及び／又はサブフレームを含むＨＡＲＱ確認応答グループと、
   前記ＨＡＲＱ確認応答の送信用に割り当てられたリソースと、
   フィードバックタイミングと
   の少なくとも１つをさらに示す、
   請求項６に記載の方法。
8. 前記ＨＡＲＱ確認応答グループは、前記第１のトリガが送信された後のスケジュール可能なサブフレームの全部又は一部を含む、
   請求項７に記載の方法。
9. 前記第２のトリガは、すべての端末デバイスが前記ＨＡＲＱ確認応答をフィードバックすることを示す共通トリガであり、あるいは、
   前記第２のトリガは、専用端末デバイスが前記ＨＡＲＱ確認応答をフィードバックすることを示す専用トリガである、
   請求項６に記載の方法。
10. 前記第２のトリガに基づいて、前記端末デバイスが前記ＨＡＲＱ確認応答をフィードバックするか否かを決定することと、
    前記端末デバイスが前記ＨＡＲＱ確認応答をフィードバックするとの決定に応答して、前記第２のトリガに関連付けられた受信から一定の時間間隔の後に、前記ＨＡＲＱ確認応答を前記ネットワークデバイスに送信することと、をさらに含む、
    請求項６に記載の方法。
11. ネットワークデバイスであって、
    プロセッサと、
    メモリと、を備え、
    前記メモリは、前記プロセッサによって実行可能な命令を含むプログラムを備え、
    前記プロセッサは、前記ネットワークデバイスに請求項１〜５のいずれかに記載の方法を実行させるように構成される、
    ネットワークデバイス。
12. 端末デバイスであって、
    プロセッサと、
    メモリと、を備え、
    前記メモリは、前記プロセッサによって実行可能な命令を含むプログラムを備え、
    前記プロセッサは、前記端末デバイスに請求項６〜１０のいずれかに記載の方法を実行させるように構成される、
    端末デバイス。
13. ネットワークデバイスによって実行されると、前記ネットワークデバイスに請求項１〜５のいずれかに記載の方法を実行させる命令が格納されている、
    コンピュータ読み取り可能な記憶媒体。
14. 端末デバイスによって実行されると、前記端末デバイスに請求項６〜１０のいずれかに記載の方法を実行させる命令が格納されている、
    コンピュータ読み取り可能な記憶媒体。

Images