JP2023081914A - 無線通信のための方法 - Google Patents

Abstract

【課題】ハイブリッド自動再送要求（ＨＡＲＱ：ｈｙｂｒｉｄ ａｕｔｏｍａｔｉｃ ｒｅｐｅａｔ ｒｅｑｕｅｓｔ）のための方法を提供する。
【解決手段】無線通信のための方法であって、ネットワークデバイスは、スケジューリングメッセージを端末デバイスへ送信することと、スケジューリングメッセージに従ってデータを端末デバイスへ送信することと、端末デバイスからＨＡＲＱフィードバックを検出することと、ＨＡＲＱフィードバックが検出されたリソースのリソースＩＤを決定することと、受信したＨＡＲＱフィードバック及びリソースＩＤに基づいて、後続の送信又は再送信を制御することと、を実施する。前記ＨＡＲＱフィードバックに関する情報は、ＨＡＲＱフィードバック用の処理ＩＤ、及び前記端末デバイス又は前記処理ＩＤのために送信されたスケジューリングメッセージの前記累計数の少なくとも１つを示す。
【選択図】図７

Description

本開示の非限定的かつ例示的な実施形態は、一般的に、無線通信の技術分野に関し、特に、ハイブリッド自動再送要求（ＨＡＲＱ：Ｈｙｂｒｉｄ Ａｕｔｏｍａｔｉｃ Ｒｅｐｅａｔ Ｒｅｑｕｅｓｔ）のための方法及びデバイスに関する。

この部分では、開示をより理解できる態様を紹介する。従って、この部分の記載は、この観点から読み取られるべきであり、先行技術に開示された又は開示されないことを自認することとして理解されるべきではない。

送信の信頼性を向上させるために、ＨＡＲＱメカニズムは、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）と呼ばれる第４世代（４Ｇ）無線通信システムや、ＮＲ（Ｎｅｗ Ｒａｄｉｏ）と呼ばれる第５世代（５Ｇ）無線通信システムなどの３ＧＰＰ（Ｔｈｉｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）によって開発された通信システムにおいて広く使用されている。

ＨＡＲＱでは、受信機は、送信機からのデータが正しく検出された場合に肯定応答（ＡＣＫ）を送信機にフィードバックし、データが正しく検出されていない場合に否定応答（ＮＡＣＫ）をフィードバックする。そして、送信機は、受信機からＡＣＫが受信されたか又はＮＡＣＫが受信されたかに応じて、新たな送信又は再送信を実行する。従って、ＡＣＫ／ＮＡＣＫフィードバック（ＨＡＲＱフィードバックとも呼ばれる）は、データ送信のスケジューリングにとって重要である。

本開示の様々な実施形態は、主に、無線通信のための拡張ＨＡＲＱフィードバックメカニズムを提供することを目的とする。

本開示の第１の態様では、方法を提供する。当該方法は、無線通信のための方法であって、ＨＡＲＱフィードバックに関する情報を含むスケジューリングメッセージを端末デバイスへ送信することと、前記スケジューリングメッセージに従ってデータを前記端末デバイスへ送信することと、前記端末デバイスからＨＡＲＱフィードバックを受信することと、前記受信したＨＡＲＱフィードバックに基づいて後続の送信又は再送信を制御することと、を備え、前記ＨＡＲＱフィードバックに関する情報は、ＨＡＲＱフィードバック用の処理ＩＤ、及び前記端末デバイス又は前記処理ＩＤのために送信されたスケジューリングメッセージの累計数の少なくとも１つを示す。

本開示の第２の態様では、他の方法を提供する。当該方法は、スケジューリングメッセージを端末デバイスへ送信することと、前記スケジューリングメッセージに従ってデータを前記端末デバイスへ送信することと、前記端末デバイスからＨＡＲＱフィードバックを検出することと、ＨＡＲＱフィードバックが検出されたリソースのリソースＩＤを決定することと、前記受信したＨＡＲＱフィードバック及び前記リソースＩＤに基づいて、後続の送信又は再送信を制御することと、を備え、前記リソースＩＤは前記リソースに関連付けられたリソースセットグループの識別子を含み、リソースセットグループは１つ以上のリソースセットを含み、リソースセットは１つ以上のリソースを含む。

本開示の第３の態様では、もう１つの方法を提供する。当該方法は、ＨＡＲＱフィードバックのための、静的ＨＡＲＱコードブックの符号化のタイプを示すコーディング構成を端末デバイスへ送信することと、データを前記端末デバイスへ送信することと、示された符号化のタイプに基づいて、前記端末デバイスから前記データに対するＨＡＲＱフィードバックを検出することと、前記検出したＨＡＲＱフィードバックに基づいて、後続の送信又は再送信を制御することと、を備える。

本開示の第４の態様では、端末デバイスによって実施される方法を提供する。当該方法は、ネットワークデバイスからＨＡＲＱフィードバックに関する情報を含むスケジューリングメッセージを受信することと、前記スケジューリングメッセージに従って、前記ネットワークデバイスからデータを検出することと、前記ＨＡＲＱフィードバックに関する情報に基づいて、前記ネットワークデバイスへＨＡＲＱフィードバックを送信することと、を備え、前記ＨＡＲＱフィードバックに関する情報は、ＨＡＲＱフィードバック用の処理ＩＤ、及び前記端末デバイス又は前記処理ＩＤのために送信されたスケジューリングメッセージの累計数の少なくとも１つを示す。

本開示の第５の態様では、端末デバイスによって実施される他の方法を提供する。当該方法は、ネットワークデバイスからデータを受信することと、ｉ回目の前記データに対するフィードバックを再送信することを決定することに応答して、前記ｉ番目のリソースセットグループからリソースを選択することと、前記選択したリソースで前記データに対する前記フィードバックを再送信することと、を備え、ｉは正の整数であり、リソースセットグループは１つ以上のリソースセットを含み、リソースセットは１つ以上のフィードバックリソースを含む。

本開示の第６の態様では、端末デバイスによって実施されるもう1つの方法を提供する。当該方法は、ネットワークデバイスからＨＡＲＱフィードバックのための、静的ＨＡＲＱコードブックの符号化のタイプを示すコーディング構成を受信することと、前記ネットワークデバイスからデータを受信することと、前記コーディング構成に基づいて、前記データに対するＨＡＲＱフィードバックを生成することと、前記ＨＡＲＱフィードバックを前記ネットワークデバイスへ送信することを備える。

本開示の第７の態様では、無線通信のための装置を提供する。当該装置はプロセッサ及びメモリを含む。前記メモリは、前記プロセッサによって実行可能であり、かつ前記プロセッサによって実行されると、前記装置に本開示の第１、第２、第３の態様のいずれかに記載の方法を実行するように動作させる命令を有する。

本開示の第８の態様では、無線通信のための他の装置を提供する。当該装置はプロセッサ及びメモリを含む。前記メモリは、前記プロセッサによって実行可能であり、かつ前記プロセッサによって実行されると、前記装置に本開示の第４、第５、第６の態様のいずれかに記載の方法を実行するように動作させる命令を有する。

本開示の第９の態様では、装置によって実行されると、前記装置に本開示の第１、第２、第３の態様のいずれかに記載の方法を実行させるコンピュータプログラムが格納されたコンピュータ読み取り可能な媒体を提供する。

本開示の第１０の態様では、装置によって実行されると、前記装置に本開示の第４、第５、第６の態様のいずれかに記載の方法を実行させるコンピュータプログラムが格納されたコンピュータ読み取り可能な媒体を提供する。

本開示の実施形態は、ＨＡＲＱパフォーマンスを改善し、リソース効率を改善することができる。

本開示の様々な実施形態の上記及び他の態様、特徴、及び利点は、添付の図面を参照して以下の詳細な説明からより完全に明らかになる。図面において、同じ参照符号は、同じ又は均等な要素を表す。図面は、本開示の実施形態をより理解できるために示され、必ずしも一定の縮尺で描かれているものではない。

図１は、本開示の実施形態が実施され得る例示的な無線通信ネットワークを示す。

図２は、本開示の実施形態によるＤＣＩにおける提案された指示に基づいてＨＡＲＱフィードバックのペイロードサイズを決定する例を示す。

図３は、本開示の実施形態による提案されたＨＡＲＱ－ＰＵＣＣＨの処理ＩＤに基づいて再送しようとするＡＣＫ／ＮＡＣＫビットを決定する例を示す。

図４は、本開示の実施形態によるリソースの３次元（３Ｄ）指示の例を示す。

図５は、本開示の実施形態によるリソースセットグループの概念に基づいてＡＣＫ／ＮＡＣＫフィードバックのためのリソースを決定する例を示す。

図６は、本開示の実施形態によるＨＡＲＱフィードバックのためのタイプＡ及びタイプＢの符号化の例を概略的に示す。

図７は、本開示の実施形態によるネットワークデバイスによって実施され得る方法のフローチャートを示す。 図８は、本開示の実施形態によるネットワークデバイスによって実施され得る方法のフローチャートを示す。 図９は、本開示の実施形態によるネットワークデバイスによって実施され得る方法のフローチャートを示す。

図１０は、本開示の実施形態による端末デバイスによって実施され得る方法のフローチャートを示す。 図１１は、本開示の実施形態による端末デバイスによって実施され得る方法のフローチャートを示す。 図１２は、本開示の実施形態による端末デバイスによって実施され得る方法のフローチャートを示す。

図１３は、本開示の実施形態による端末デバイス又はネットワークデバイスとして具現化され又はそれに備えられる装置の簡略ブロック図を示す。

以下、例示的な実施形態を参照しながら、本開示の原理及び主旨を説明する。これらの実施形態はすべて当業者が本開示をより理解し、さらに実施するために提供されるものにすぎず、本開示の範囲を限定するものではないことを理解されたい。例えば、一実施形態の一部として図示又は説明される特徴を別の実施形態とともに使用して、更に別の実施形態を生み出すことができる。明確のために、実際の実施に関するすべての特徴が本明細書で説明されるわけではない。

本明細書における「一実施形態」、「実施形態」、「例示的実施形態」などを言及する場合に、記載された実施形態が特定の特徴、構造、又は特性を含み得ることを示すが、必ずしも、すべての実施形態が特定の特徴、構造、又は特性を含むわけではない。さらに、このような表現は、必ずしも同じ実施形態を指すものではない。また、明示的に記載されているか否かに関わらず、特定の特徴、構造、又は特性が実施形態に関して説明される場合、他の実施形態に関するそのような特徴、構造、又は特性に適用することが当業者の知識の範囲内であることを意図している。

本明細書では、「第１」及び「第２」などの用語を使用して様々な要素を説明することがあるが、これらの要素は、これらの用語によって限定されるべきではないことを理解されたい。これらの用語は、ある要素を別の要素と区別するためにのみ使用される。例えば、例示的な実施形態の範囲から逸脱しない限り、第１の要素を第２の要素と呼ぶことができ、同様に、第２の要素を第１の要素と呼ぶことができる。本明細書で使用されるとき、「及び／又は」という用語は、挙げられる用語のうちの１つ以上の任意の組み合わせ及びすべての組み合わせを含む。

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

以下の説明及び特許請求の範囲において、別途定義されない限り、本明細書で使用されるすべての技術用語及び科学用語は、本開示が属する技術分野の当業者によって一般的に理解されるものと同じ意味を有する。

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

本明細書で使用されるとき、「ネットワークデバイス」という用語とは、端末デバイスとデータ及び信号を送受信する無線通信ネットワーク内のネットワークノードを指す。ネットワークデバイスは、適用される用語及び技術に応じて、基地局（ＢＳ：Ｂａｓｅ Ｓｔａｔｉｏｎ）又はアクセスポイント（ＡＰ：ａｃｃｅｓｓ ｐｏｉｎｔ）を指すことがある。ＡＰの例には、ノードＢ（ＮｏｄｅＢ又はＮＢ）、Ｅｖｏｌｖｅｄ ＮｏｄｅＢ（ｅＮｏｄｅＢ又はｅＮＢ）、ＮＲ ＮＢ（ｇＮＢとも呼ばれる）、リモート無線ユニット（ＲＲＵ：Ｒｅｍｏｔｅ Ｒａｄｉｏ Ｕｎｉｔ）、無線ヘッド（ＲＨ：Ｒａｄｉｏ Ｈｅａｄ）、リモート無線ヘッド（ＲＲＨ：Ｒｅｍｏｔｅ Ｒａｄｉｏ Ｈｅａｄ）、リレー、及びフェムトやピコなどの低電力ノードなどが含まれる。

「端末デバイス」という用語とは、無線通信が可能な任意のエンドデバイスを指す。非限定的な例として、端末デバイスは、通信デバイス、ユーザ機器（ＵＥ：Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）、加入者局（ＳＳ：Ｓｕｂｓｃｒｉｂｅｒ Ｓｔａｔｉｏｎ）、ポータブル加入者局（Ｐｏｒｔａｂｌｅ Ｓｕｂｓｃｒｉｂｅｒ Ｓｔａｔｉｏｎ）、移動局（ＭＳ：Ｍｏｂｉｌｅ Ｓｔａｔｉｏｎ）、又はアクセス端末（ＡＴ：Ａｃｃｅｓｓ Ｔｅｒｍｉｎａｌ）と呼ばれることもある。端末デバイスは、移動電話、セルラー電話、スマートフォン、ＶｏＩＰ（ｖｏｉｃｅ ｏｖｅｒ ＩＰ）電話、ＷＬＬ（ｗｉｒｅｌｅｓｓ ｌｏｃａｌ ｌｏｏｐ）電話、タブレット、ウェアラブル端末デバイス、携帯情報端末（ＰＤＡ：Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）、ポータブルコンピュータ、デスクトップコンピュータ、デジタルカメラなどの画像キャプチャ端末デバイス、ゲーム端末デバイス、音楽ストレージ及び再生機器、車載無線端末デバイス、無線エンドポイント、移動局、ＬＥＥ（ｌａｐｔｏｐ－ｅｍｂｅｄｄｅｄ ｅｑｕｉｐｍｅｎｔ）、ＬＭＥ（ｌａｐｔｏｐ－ｍｏｕｎｔｅｄ ｅｑｕｉｐｍｅｎｔ）、ＵＳＢドングル、スマートデバイス、無線ＣＰＥ（ｃｕｓｔｏｍｅｒ－ｐｒｅｍｉｓｅｓ ｅｑｕｉｐｍｅｎｔ）などを含むが、これらに限定されない。以下の説明では、「端末デバイス」、「通信デバイス」、「端末」、「ユーザ機器」、及び「ＵＥ」という用語は、互換的に使用される場合がある。

さらに別の例として、ＩＯＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）シナリオでは、端末デバイスは、監視及び／又は測定を実行し、このような監視及び／又は測定の結果を別の端末デバイス及び／又はネットワーク機器に送信するマシン又は他のデバイスを表すことができる。この場合、端末デバイスは、３ＧＰＰの文脈でＭＴＣ（ｍａｃｈｉｎｅ－ｔｙｐｅ ｃｏｍｍｕｎｉｃａｔｉｏｎ）デバイスと呼ばれるＭ２Ｍ（ｍａｃｈｉｎｅ－ｔｏ－ｍａｃｈｉｎｅ）デバイスであってもよい。特定の一例として、端末デバイスは、３ＧＰＰ ＮＢ－ＩｏＴ（ｎａｒｒｏｗ ｂａｎｄ ｉｎｔｅｒｎｅｔ ｏｆ ｔｈｉｎｇｓ）規格を実施するＵＥである。このようなマシン又はデバイスの例には、センサ、電力計などの計測デバイス、産業機械、又は家庭用或いは個人用の機器（例えば、冷蔵庫、テレビ、時計などの個人用ウェアラブルなど）が含まれる。他のシナリオでは、端末デバイスは、動作状態又はその動作に関連する他の機能を監視及び／又はレポートできる車両又は他の機器を表すことができる。

本明細書で使用されるとき、ダウンリンク（ＤＬ：ｄｏｗｎｌｉｎｋ）送信とは、ネットワークデバイスからＵＥへの送信を指し、アップリンク（ＵＬ：ｕｐｌｉｎｋ）送信とは、ＵＥからネットワークへの送信を指し、サイドリンク（ＳＬ：側ｌｉｎｋ）送信とは、ＵＥの間の送信を指す。

図１は、本開示の実施形態が実施され得る例示的な無線通信ネットワーク１００を示す。図示のように、通信ネットワーク１００は、１つ以上のネットワークデバイス、例えば、ｅＮＢ又はｇＮＢの形態であるネットワークデバイス１０１を含み得る。ネットワークデバイス１０１は、ノードＢ、ＢＴＳ（Ｂａｓｅ Ｔｒａｎｓｃｅｉｖｅｒ Ｓｔａｔｉｏｎ）、及び／又はＢＳＳ（Ｂａｓｅ Ｓｔａｔｉｏｎ Ｓｕｂｓｙｓｔｅｍ）、アクセスポイント（ＡＰ：Access Point）などの形態であっても良いと理解されたい。ネットワークデバイス１０１は、１組の端末デバイス、例えば、まとめて「端末デバイス１０２」と呼ばれる端末デバイス１０２－１、１０２－２、及び１０２－３に対して無線接続を提供する。便宜上、図１には３つの端末デバイスのみが示されているが、実際に通信ネットワークには、より多く、又はより少ない端末デバイスが存在しても良いと理解されたい。

ネットワークデバイス１０１と端末デバイス１０２との送信は、スケジューリングメッセージ、例えば、ＤＬ制御情報（ＤＣＩ：DL control information）を介してスケジュールされ得る。ＤＬスケジューリング用のＤＣＩを検出すると、端末デバイス１０２は、ＤＣＩによって示されるリソースにおいてＤＬデータ送信（例えば、物理ダウンリンク共有チャネル（ＰＤＳＣＨ：Physical Downlink Shared CHannel）送信）を検出しようとする。

ネットワークデバイス１０１は、１つ以上の周波数帯において１つ以上のキャリアを使用して端末デバイス１０２と通信することができることに留意されたい。１つ以上の周波数帯は、免許周波数帯及び／又は免許不要周波数帯を含み得る。

ＬＡＡ（Ｌｉｃｅｎｓｅｄ Ａｓｓｉｓｔｅｄ Ａｃｃｅｓｓ）として知られている免許不要帯域の動作の１つのタイプは、３ＧＰＰで研究されて採用されている。ＬＡＡシステムでは、ＤＬでのスケジューリング情報やＵＬでのＨＡＲＱフィードバックなどの制御シグナリングが免許帯域で送信され、一方、データ送信が免許不要帯域で実行される。

３ＧＰＰで研究されている免許不要帯域の動作の他のタイプは、ＮＲ－Ｕ（ＮＲ Ｕｎｌｉｃｅｎｓｅｄ）と呼ばれ、ＮＲ－Ｕでは、免許帯域からの支援が利用できず、データ及び制御送信の両方が免許不要帯域で実行される。

免許不要帯域では、送信前に、ノードは最初にクリアチャネル評価（ＣＣＡ：Clear Channel Assessment）を有し、即ち、ＬＢＴ（Ｌｉｓｔｅｎ ｂｅｆｏｒｅ ｔａｌｋ）は、送信前に実行されなければならない。ＬＢＴが故障した場合に、送信はブロックされる。本願の発明者は、ＬＢＴの故障がＨＡＲＱメカニズムに問題を引き起こせる可能性があることを発見した。

ＨＡＲＱメカニズムによれば、受信機（例えば、端末デバイス１０２）は、送信機からのデータが正しく検出された場合にＡＣＫを送信機（例えば、ネットワークデバイス１０１）へフィードバックし、そうでない場合にＮＡＣＫをフィードバックする。そして、送信機は、受信機によってＡＣＫがフィードバックされるか又はＮＡＣＫがフィードバックされるかに応じて、新な送信又は再送信を実行する。従って、ＡＣＫ／ＮＡＣＫフィードバック（ＨＡＲＱフィードバックとも呼ばれる）は、データ送信のスケジューリングにとって重要である。

ＨＡＲＱメカニズムにおけるエラーは、ＡＣＫ／ＮＡＣＫフィードバック又は検出の故障を引き起こす可能性があり、その結果、送信機は、データが正しく受信されたかどうかがわからない。

経路損失、チャネルフェージング及び／又は干渉に起因して、データ送信又はＨＡＲＱフィードバック中にエラーが発生し、ＤＬ検出漏れ、ＤＬ誤警報、ＵＬ検出漏れ、ＵＬ誤警報を含むＨＡＲＱメカニズムにいくつかの問題をもたらす可能性があることを発見した。

ＤＣＩが送信機によって送信されたが、受信機によって検出されない場合、ＤＣＩ検出漏れが発生する。このような場合に、送信機がＡＣＫ／ＮＡＣＫフィードバックを期待するが、当該ＡＣＫ／ＮＡＣＫフィードバックが受信機によって提供されないため、送信機側及び受信機側で不明確の問題が生じる。物理ダウンリンク制御チャネル（ＰＤＣＣＨ：Physical Downlink Control CHannel）で運ばれるＤＣＩは高い復号精度を有しても、通常の復号エラー率が約１％であるため、ＤＣＩ検出漏れを完全に回避することはできない。

この問題を解決するために、１回のフィードバック（即ち、単一のＰＤＳＣＨ送信に関連するフィードバック）について、不連続送信（ＤＴＸ）検出は、送信機（例えば、ネットワークデバイス１０１）側で採用されてもよい。複数回の多重化を伴うＨＡＲＱフィードバック（即ち、複数のＰＤＳＣＨ送信に対するフィードバック）について、ダウンリンク割り当てインデックス（ＤＡＩ：Downlink Assignment Index）は、最後の１つ以上の送信機会のＤＣＩ検出漏れを除いて、ＤＣＩ検出漏れによって引き起こされる問題を解決するためにＤＣＩに含まれてもよい。ＤＣＩのＤＡＩフィールドに基づいて、ＵＥは検出されていないＰＤＣＣＨを知るようになる。これにより、検出漏れが発生しても、ＵＥはｇＮＢと同様にフィードバックされるＨＡＲＱ－ＡＣＫビットの長さに関する情報を持つことが保証される。例えば、２ビットのＤＡＩでは、４つの連続したＤＣＩが漏れた場合にのみ、フィードバックのサイズ（即ち、フィードバックビットの数）が不明確である。

最後の送信機会のＤＣＩ検出漏れによって引き起こされる問題は、各ＤＣＩ内で異なる物理アップリンク制御チャネル（ＰＵＣＣＨ：Physical Uplink Control CHannel）リソースを示し、かつ送信機側で異なるＰＵＣＣＨリソース内のＡＣＫ／ＮＡＣＫの（複数の）ブラインド検出を実行することによって解決されることができる。

同様に、ＰＤＣＣＨ内のＤＣＩが送信されないが、ＵＥによって検出されると、ＤＬ誤警報は発生する。このような場合、ＵＥはスケジュールされていないリソースをフィードバックし、干渉を引き起こす可能性がある。

別のＨＡＲＱフィードバックエラーは、ＵＬ検出漏れと呼ばれ、ＡＣＫ／ＮＡＣＫは、ＰＵＣＣＨで受信機（例えば、ＵＥ）によって送信されるが、送信機（例えば、ｇＮＢ）によって正しく検出されていない。特に、ＵＥからのＮＡＣＫフィードバックがｇＮＢによって検出されていない可能性があり、そのような場合、ｇＮＢは再送信を実行するが、現在の送信機会にのみ影響を与える。ｇＮＢによってＮＡＣＫがＡＣＫであると復号されると、上位層のＡＲＱが発生するおそれがあり、これに起因して、送信効率が低下する。ＡＣＫがＮＡＣＫ又はＤＴＸであると検出されると、不要な再送信が実行され、これに起因して、現在の送信機会に悪影響を与える。

一方、ＡＣＫ／ＮＡＣＫが送信されていないが、ｇＮＢによって受信されると、ＵＬ誤警報が発生する。しかしながら、これは、ＤＬ検出漏れ及びＵＬ誤警報が同時に発生した場合にのみ発生するため、レアケースである。

いくつかのシナリオでは、複数のデータ送信（例えば、ＰＤＳＣＨ送信）に対するＨＡＲＱフィードバックは、例えば、物理アップリンク制御チャネル（ＰＵＣＣＨ）又は物理アップリンク共有チャネル（ＰＵＳＣＨ）などの単一のＵＬチャネルを介して提供されてもよい。このような場合、複数のＡＣＫ／ＮＡＣＫビットが同じＰＵＣＣＨ／ＰＵＳＣＨで運ばれる可能性がある。言い換えれば、１つ以上のＰＤＳＣＨは、ＨＡＲＱフィードバック用の１つのＰＵＣＣＨ／ＰＵＳＣＨに関連付けられ、同じＰＵＣＣＨ／ＰＵＳＣＨに関連付けられたＰＤＳＣＨはＰＤＳＣＨセット、又は送信セットと呼ばれる場合がある。ＰＤＳＣＨ（又はＰＤＳＣＨをスケジューリングするＤＣＩ）とＰＵＣＣＨ／ＰＵＳＣＨとの関連付けは、事前に決定されてもよく、動的に構成されてもよい。

さらに、ＨＡＲＱフィードバック用のタイミング及びＰＵＣＣＨリソースは、送信機、例えば、ｇＮＢによってＤＣＩを介して示されてもよい。例えば、ＰＵＣＣＨリソースセットごとに８つのＰＵＣＣＨリソースがあり、最大４つのＰＵＣＣＨリソースセットは、無線リソース制御（ＲＲＣ：Radio Resource Control）シグナリングによってＵＥに構成されることができる。ＡＣＫ／ＮＡＣＫ送信に使用されるＰＵＣＣＨリソースセットは、ＰＵＣＣＨビットのペイロードに基づいて選択されてもよく、ＰＵＣＣＨリソースセット内の使用されるＰＵＣＣＨリソースは、さらに、ＤＣＩによって示されてもよい。

５Ｇ ＮＲでは、ＨＡＲＱフィードバックはコードブックの２つのモード、即ち、静的コードブック又は動的コードブックのいずれかを使用してもよい。静的コードブックでは、ＨＡＲＱビットを生成するときに、すべての可能なタイミング及び／又はＤＣＩ／ＰＤＳＣＨとＰＵＣＣＨ／ＰＵＳＣＨとの関連付けが考慮される。このモードのコードブックは、ＰＵＣＣＨ／ＰＵＳＣＨで高いペイロードを起こすが、ペイロードサイズ（即ち、フィードバックするＨＡＲＱ－ＡＣＫビットの数）が事前に定義されて静的であるため、ＤＣＩの検出漏れを回避することができる。受信機により漏れられたＤＣＩのＨＡＲＱフィードバックは、デフォルト値であるＮＡＣＫに設定される。

ＨＡＲＱフィードバック用の動的コードブックでは、ペイロードサイズを低減するために、ＨＡＲＱビットを生成するときに、送信されたＰＤＳＣＨのみが考慮される。このような場合、ＵＥは、ＤＣＩが検出された場合にのみＨＡＲＱフィードバックを送信し、そして、フィードバックの内容であるＡＣＫ又はＮＡＣＫは、検出されたＤＣＩによってスケジュールされたＰＤＳＣＨが正しく復号化されるかどうかに依存する。従って、ＤＣＩが送信機によって送信されたが、受信機によって検出されていない場合（即ち、ＤＣＩ検出漏れが発生した場合）、ＡＣＫ／ＮＡＣＫは送信されず、送信機側及び受信機側で不明確な問題を引き起こす可能性がある。

上記の問題に加えて、ＮＲ－Ｕモードで、免許不要帯域で動作することは、ＨＡＲＱメカニズムにより多くの問題を招来する恐れがある。例えば、ＬＢＴ故障は、受信機側からのＨＡＲＱフィードバック送信をブロックする可能性があり、そのような場合、如何に送信機にＨＡＲＱフィードバックのＤＴＸを認識させることは未解決の問題である。さらに、リソースが利用可能なときに如何にブロックされたＨＡＲＱフィードバックを提供することも研究されるべきである。

いくつかのシナリオでは、ｇＮＢが免許不要帯域におけるチャネルにアクセスすると、ｇＮＢのチャネル占有時間（ＣＯＴ：Channel Occupied Time）内でのＵＥ側からのＵＬ送信は、ｇＮＢからのＤＬ送信とＵＥからのＵＬ送信との間のギャップが所定の閾値、例えば、１６ｕｓより大きくない場合に、再度のＬＢＴを行わずに実行されることができる。従って、ＬＢＴ故障によってＨＡＲＱフィードバックがブロックされることを回避するために、ＵＥは、ｇＮＢのＣＯＴ内でＨＡＲＱ－ＡＣＫをフィードバックすることが有益である。現在のＰＤＳＣＨのＨＡＲＱフィードバックに対して、現在のＰＤＳＣＨに関連付けられるＣＯＴ又は次のＰＤＳＣＨに関連付けられるＣＯＴのいずれかは使用されてもよいことに留意されたい。しかしながら、ＵＥ側でのＰＤＳＣＨの処理遅延を考慮すると、いくつかのシナリオでは１６ｕｓ内でＨＡＲＱフィードバックを送信することは不可能である場合がある。

現在のＮＲシステムでは、最後の１つ以上の送信機会の検出漏れによって引き起こされる問題は、送信された各ＤＣＩで異なるＰＵＣＣＨリソースを示すことによって解決され得る。しかしながら、複数のＰＤＳＣＨセットのＨＡＲＱフィードバックビットを単一のＰＵＣＣＨ／ＰＵＳＣＨチャネルで同時に送信する必要がある場合に、当該ソリューションはうまく効かない。説明の目的で、ＰＤＳＣＨセット１及びＰＤＳＣＨセット２が単一のＰＵＣＣＨ／ＰＵＳＣＨリソースでフィードバックされ、各ＰＤＳＣＨセットが２つのＰＤＳＣＨを含むと仮定する。この例では、ＰＤＳＣＨセット１の２番目のＰＤＳＣＨがミスで検出されず、かつ、他のＰＤＳＣＨが正しく検出されると、ＵＥは、３つのＡＣＫビットをフィードバックする。しかしながら、ｇＮＢは４つのＡＣＫビットを期待し、たとえｇＮＢがこれらのＰＤＳＣＨのＤＣＩによって示される複数のＰＵＣＣＨリソースで盲目的に検出しても、３ビットのみがＵＥによって送信されることを知ることができない。

さらに、ＡＣＫ／ＮＡＣＫビットを運ぶＰＵＣＣＨが免許不要帯域でのＬＢＴ故障に起因してブロックされた場合には、次のＰＵＣＣＨの機会に、自動的に又はＤＣＩトリガーに基づいてブロックされたＰＵＣＣＨを再送信する。しかしながら、ブロックされたＰＵＣＣＨ機会のＨＡＲＱ－ＡＣＫビットの長さが不明確である場合には、次のＰＵＣＣＨの復号に大きな問題が発生する。

本開示は、上記した問題及び他の問題の少なくともいくつかの問題を解決するために、方法、デバイス、及びコンピュータ読み取り可能な媒体を提供した。例えば、いくつかの実施形態は、最後の１つ以上のＤＣＩ送信機会の検出漏れに引き起こされた問題を解決できる。その代わりに、又はそれに加えて、いくつかの実施形態は、期待されないＤＣＩの検出漏れによるエラー拡散を回避することができる。

いくつかの実施形態において、ＤＣＩ検出漏れに起因する、ＡＣＫ／ＮＡＣＫフィードバックのペイロードサイズ及び／又は１つ以上の漏れたＰＤＳＣＨ及び対応するＡＣＫ／ＮＡＣＫビットの位置が不明確である問題を解決するために、サイクルＤＡＩ（Cycled DAI）、ＨＡＲＱ ＰＵＣＣＨ処理ＩＤ、及び新しいフィードバック識別子の１つ以上がスケジューリングメッセージ（例えば、ＤＣＩ）に含まれる。

説明のために、サイクリックＤＡＩと共に、カウンタＤＡＩ又は合計ＤＡＩが各ＤＣＩに含まれてもよく、ＤＣＩ内のカウンタＤＡＩは、現在の時刻までにＰＤＳＣＨセット（即ち、同じＰＵＣＣＨフィードバック機会に関連付けられたＰＤＳＣＨの１セット）で送信されたＤＣＩの合計数を示し、ＤＣＩ内の合計ＤＡＩは、キャリアアグリゲーションが採用されたときにＰＤＳＣＨセットで送信されるＤＣＩの合計数を示す。キャリアアグリゲーションの合計ＤＡＩは、最後の１つ以上の送信機会の検出漏れによって引き起こされる問題の解決に寄与する。しかしながら、単一のキャリア展開では、合計ＤＡＩが存在しない。サイクリックＤＡＩは、現在の時刻までに特定のＵＥ又は特定のＨＡＲＱ－ＰＵＣＣＨ処理に対して（可能性として複数のＰＤＳＣＨセットにわたって）送信されたＤＣＩの累積数を示す。カウンタＤＡＩ／合計ＤＡＩ及びサイクリックＤＡＩの組み合わせによれば、特に合計ＤＡＩが存在しない単一のキャリア展開では、ＨＡＲＱフィードバックのペイロードサイズの不明確を回避できる。

図２は、ＤＣＩにおける提案された指示に基づいてＨＡＲＱフィードバックのペイロードサイズを決定するための例を示す。この例では、ＰＤＳＣＨはスロットｎ、ｎ＋１、ｎ＋３、ｎ＋４、ｎ＋６、及びｎ＋７で送信され、ＡＣＫ／ＮＡＣＫはスロットｎ＋２、ｎ＋５、及びｎ＋８でフィードバックされる。それに加えて、スロットｎ及びｎ＋１のＰＤＳＣＨはＰＤＳＣＨセット１を形成し、スロットｎ＋３及びｎ＋４のＰＤＳＣＨはＰＤＳＣＨセット２を形成し、スロットｎ＋６及びｎ＋７のＰＤＳＣＨはＰＤＳＣＨセット３を形成する。図２に示す各スロット内の参照記号（ｉ、ｊ）は、現在のスロットのカウンタＤＡＩ ｉ及びサイクリックＤＡＩ ｊを表す。言い換えると、（ｉ、ｊ）とは、現在のＰＤＳＣＨセットで送信されたｉ番目のＤＣＩであり、当該ＵＥに送信されたｊ番目のＤＣＩであることを意味する。

上記の例では、仮に、スロットｎ及びｎ＋１におけるＰＤＳＣＨ用の２つのＡＣＫ／ＮＡＣＫビットがスロットｎ＋２で正しく送信され、スロットｎ＋４におけるＤＣＩはミスで検出されず、スロットｎ＋５におけるＡＣＫ／ＮＡＣＫはＬＢＴの故障に起因して送信されていなくても、受信したＤＣＩのＤＡＩに基づいて、ＵＥは、スロットｎ＋８で合計４つのＡＣＫ／ＮＡＣＫビットを送信することを決定できる。特に、スロットｎ＋３、ｎ＋６、及びｎ＋７（即ち、２、４、５）で受信されたＤＣＩのサイクリックＤＡＩに基づいて、ＵＥは、サイクリックＤＡＩ＝２とサイクリックＤＡＩ＝４との間の１つのＰＤＳＣＨ送信がミスで検出されず、合計４つのＰＤＳＣＨが送信されたことがわかる。

サイクリックＤＡＩは、送信されたスケジューリングメッセージの累積数がサイクリックＤＡＩによって表されることができる最大数を超える場合、その数が０にリセットされることを意味することに留意されたい。例えば、サイクリックＤＡＩは、２ビットであり、かつ値が０、１、２、又は３であり、合計６つのＤＣＩが送信されると、サイクリックＤＡＩは値１に設定される。いくつかの実施形態では、サイクリックＤＡＩは、ＵＥ（Ｃ－ＲＮＴＩ（ｃｅｌｌ Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｔｅｍｐｏｒａｒｙ Ｉｄｅｎｔｉｔｙ）によって識別され得る）ごとに、又はＵＥのＨＡＲＱ－ＰＵＣＣＨ処理ごとに示されてもよい。いくつかの実施形態において、ＨＡＲＱフィードバックがｇＮＢによって成功に受信されると、サイクリックＤＡＩはリセットされる。

ＮＲ－Ｕなどの通信システムの場合、ＡＣＫ／ＮＡＣＫフィードバックを運ぶＰＵＣＣＨ送信は、ＬＢＴ故障に起因してブロックされ、又は失敗する可能性がある。いくつかのシナリオでは、ＬＢＴ故障の確率が、ＤＣＩ検出漏れの確率よりも高い。従って、ＰＵＣＣＨの再送信は、ＮＲ－Ｕシステムにおいて有益である。ＰＵＣＣＨを再送信できない場合に、ｇＮＢは、対応するＰＤＳＣＨをＮＡＣＫとして扱い、当該ＰＤＳＣＨを再送信する必要があり、効率が低い。

失敗したＰＵＣＣＨの再送信は、直交リソース、即ち、他の送信と異なるリソースを使用してもよい。その代わりに、又はそれに加えて、いくつかの実施形態において、ＰＵＣＣＨ再送信は、ブロックされたＡＣＫ／ＮＡＣＫビットを新しいＡＣＫ／ＮＡＣＫビットと組み合わせ、新しいＡＣＫ／ＮＡＣＫビットのリソースで組み合わせた後のビットを送信することによって実行されてもよい。つまり、ブロックされたＡＣＫ／ＮＡＣＫビットは、新しいＡＣＫ／ＮＡＣＫビットとともに、新しいＡＣＫ／ＮＡＣＫビットのリソースを使用して送信されてもよい。

ＰＵＣＣＨ再送信は、例えばＬＢＴの結果に基づいて、ＵＥによって自動的に決定されてもよい。しかしながら、このような自動的ＰＵＣＣＨ再送信は、いくつかのシナリオにおいてエラー拡散を引き起こす可能性がある。いくつかの実施形態において、以前のＰＵＣＣＨが検出されたかどうかを示すためにＤＣＩに付加的なフィールドを追加し、これにより、ＵＥがＰＵＣＣＨ再送信を実行するかどうかを決定することを支援することが提案される。

本願の発明者は、処理の遅延に起因して、ＤＣＩが以前のＰＵＣＣＨの検出結果を示すことができない可能性があると発見した。そのような場合のＨＡＲＱフィードバックを改善するために、ＨＡＲＱ－ＰＵＣＣＨ処理ＩＤの概念がいくつかの実施形態において提案される。ＨＡＲＱ－ＰＵＣＣＨ処理ＩＤは、ＨＡＲＱ ＰＵＣＣＨ処理の識別子を示し、ＤＣＩに含まれ得る。ＤＣＩの当該新しいフィールドは、（潜在的にＰＵＣＣＨ再送信の他の指示も一緒に）ＵＥに次のＰＵＣＣＨ送信機会に同じＨＡＲＱ－ＰＵＣＣＨ処理ＩＤを有するＨＡＲＱ－ＡＣＫビットのみを再送信させることができる。いくつかの実施形態において、ＨＡＲＱ－ＰＵＣＣＨ処理の最大数は、ＤＣＩが検出されるＰＤＣＣＨと、そのＤＣＩによって示される対応するＰＵＣＣＨの完了（成功又は失敗）の示しとの間の新たに示されたＰＵＣＣＨ機会の最大数によって決定される。いくつかの実施形態において、ＨＡＲＱ－ＰＵＣＣＨ処理の最大数は１であってもよい。この場合、ＨＡＲＱ－ＰＵＣＣＨ処理ＩＤは必要とされない。しかしながら、ＨＡＲＱフィードバックについてある程度の限定が必要であり、例えば、基地局が既存のＰＵＣＣＨ機会でのＰＵＣＣＨ送信の完了（成功又は失敗）を示す前に、ＵＥが新しいＰＵＣＣＨ機会を示すことと期待されない。これは、いくつかの実施形態において、ＵＥによるそのＰＵＣＣＨの送信時間より、基地局（例えば、ｇＮＢ）によるＰＵＣＣＨの完了の示しの方が、カウントするＰＵＣＣＨ－ＨＡＲＱ処理の終了位置と見なされることを意味する。

図３は、提案されたＨＡＲＱ－ＰＵＣＣＨ処理ＩＤに基づいて再送信しようとするＡＣＫ／ＮＡＣＫビットを決定するための例を示す。

この例において、ＨＡＲＱ ＰＵＣＣＨ ＩＤ ０のＡＣＫ／ＮＡＣＫは、スロットｎ及びｎ＋１で送信されるが、スロットｎ＋１でのＡＣＫ／ＮＡＣＫ送信は、例えばＬＢＴ故障の原因で失敗する。ＨＡＲＱ ＰＵＣＣＨ ＩＤ １のＡＣＫ／ＮＡＣＫは、スロットｎ＋２及びｎ＋３で送信される。スロットｎ＋３のＡＣＫ／ＮＡＣＫが検出されていない場合、ｇＮＢは、ＨＡＲＱ ＰＵＣＣＨ処理ＩＤ ０をＵＥに示し、ＵＥにスロットｎ＋１を再送信する必要があると知らせ、さもなければ、ＵＥはスロットｎ＋１又はｎ＋３のＰＵＣＣＨを再送信する必要があるかどうかを知ることができない。

その代わりに、又はそれに加えて、いくつかの実施形態において、ＨＡＲＱフィードバックの再送信性能を示すためにＰＵＣＣＨリソースセットグループの概念が提出され、これにより、ＰＵＣＣＨ及びＰＤＳＣＨの検出漏れによって引き起こされる問題を解決する。例えば、ＨＡＲＱフィードバック用のＰＵＣＣＨリソースの３次元（３Ｄ）指示が提案されている。図４に示されるように、３Ｄ指示は、リソースセットグループの指示、リソースセットの指示、及びリソースインジケータを含む。リソースセットグループは、１つ以上のリソースセットを含んでもよく、リソースセットは、１つ以上のフィードバックリソース（例えば、ＰＵＣＣＨリソース）を含んでも良い。ＰＵＣＣＨリソースセットグループの指示は、例えば、ＬＢＴの結果に基づいて、ＰＵＣＣＨリソースを選択するために提案された新しい次元である。一般的に、ＨＡＲＱフィードバックがｎ回目に送信／再送信される場合、リソースセットグループｎからのＰＵＣＣＨリソースが選択され、ここで、ｎは正の整数である。例えば、ＡＣＫ／ＮＡＣＫビットを運ぶＰＵＣＣＨ送信がＬＢＴ故障に起因して２回失敗した場合に、ＵＥがＡＣＫ／ＮＡＣＫビットを３回目に再送信すると、３番目のＰＵＣＣＨリソースセットグループからリソースを選択して、３回目の再送信であることを示す。それに対応して、３番目のリソースセットグループでＰＵＣＣＨを検出すると、ｇＮＢは、これが３回目の再送信であることを知り、ＡＣＫ／ＮＡＣＫフィードバックに関連付けられるＰＤＳＣＨを決定することができ、即ち、ＡＣＫ／ＮＡＣＫがフィードバックされるＰＤＳＣＨを決定することができる。

選択されたリソースセットグループ内で、リソースセットはフィードバックされようとするＡＣＫ／ＮＡＣＫのペイロードに応じて選択されてもよい。それに加えて、選択されたリソースセット内のＰＵＣＣＨリソースは、対応するＰＤＳＣＨのＤＣＩに含まれる指示に基づいて、ＰＵＣＣＨ送信のために決定されてもよい。

いくつかの実施形態において、ｎ回目のＰＵＣＣＨ送信／再送信及びｍ回目のＰＵＣＣＨ送信／再送信に同じＰＵＣＣＨリソースインジケータが割り当てられる場合に、ｎ回目及びｍ回目のＰＵＣＣＨ送信／再送信のＡＣＫ／ＮＡＣＫビットはともに多重化されてもよい。それに加えて、ＵＥは、組み合わせられたＡＣＫ／ＮＡＣＢビットの全長に基づいて、組み合わせられた送信用のＰＵＣＣＨリソースセットを選択してもよい。

図５はＰＵＣＣＨリソースセットグループの概念に基づいてＡＣＫ／ＮＡＣＫフィードバック用のＰＵＣＣＨリソースを決定するための例を示し、以下の表１はリソース選択規則の例を示す。

表１

この例において、スロットｎ、ｎ＋１におけるＰＤＳＣＨのＤＣＩが、ＨＡＲＱフィードバックに対して同じＰＵＣＣＨリソースインジケータを割り当てると仮定する。そして、表１によれば、スロットｎにおけるＰＤＳＣＨのＡＣＫ／ＮＡＣＫがスロットｎ＋２で送信される場合に、ＡＣＫ／ＮＡＣＫの最初の送信であるため、グループ１のリソース０が選択される。スロットｎ＋１におけるＰＤＳＣＨのＡＣＫ／ＮＡＣＫもスロットｎ＋２で送信される場合に、スロットｎにおけるＰＤＳＣＨのＡＣＫ／ＮＡＣＫと多重化され、そして、最初の送信であり、かつペイロードサイズは２であるため、グループ１のリソース１が選択される。スロットｎにおけるＰＤＳＣＨのＡＣＫ／ＮＡＣＫがスロットｎ＋５で送信される場合に、２回目の再送信であるため、グループ２のリソース２が選択される。スロットｎ＋１におけるＰＤＳＣＨのＡＣＫ／ＮＡＣＫもスロットｎ＋５で送信される場合に、スロットｎにおけるＰＤＳＣＨのＡＣＫ／ＮＡＣＫと多重化され、そして、２回目の送信であり、かつ、ペイロードサイズは２であるため、グループ１のリソース３が選択される。スロットｎ＋３、ｎ＋４のＰＤＳＣＨに関連付けられたＡＣＫ／ＮＡＣＫのリソースも同様に導出される。

ＤＣＩ検出漏れ又はＰＵＣＣＨ再送信による不明確な問題を回避するための代替の方法は、静的ＨＡＲＱコードブックを使用することであり、これは、例えば、ＰＤＳＣＨタイムスロットとフィードバックタイムスロットとの関連付けに基づいて、ＨＡＲＱフィードバック送信のペイロードサイズが事前に決定されることを意味する。関連付け／タイミングは、たとえばＲＲＣシグナリングを介して構成される。

静的ＨＡＲＱコードブックに関して、ｎ＋ｋでインデックスされたフィードバックスロットを示すＤＣＩと共にＰＤＳＣＨをスロットｎで受信したＵＥについて、当該ＵＥがスロットｎ＋ｋ以外のスロットでＰＤＳＣＨ受信用のＨＡＲＱ－ＡＣＫ情報を報告する場合に、対応する各ＨＡＲＱ－ＡＣＫ情報ビットの値をＮＡＣＫに設定すると３ＧＰＰで規格される。このような符号化の方法は、ｇＮＢ側での検出の複雑さを軽減し、優れた送信性能を提供する。しかしながら、本開示の発明者は、そのような符号化の方法が冗長性を提供せず、例えば、ＬＢＴ故障に起因してＰＵＣＣＨがブロックされる可能性がある免許不要帯域でのＰＵＣＣＨ送信に適切ではないことを発見した。

従って、いくつかの実施形態において、静的ＨＡＲＱコードブックに対して、タイプＡ及びタイプＢと呼ばれ得る２つのタイプの符号化を構成することを提案する。

３ＧＰＰで規格されたように、タイプＡの符号化では、ＵＥがスロットｎ＋ｋ以外のスロットでＰＤＳＣＨ受信用のＨＡＲＱ－ＡＣＫ情報を報告する場合、ＵＥは、対応する各ＨＡＲＱ－ＡＣＫ情報ビットの値をＮＡＣＫに設定する。

これに対して、タイプＢの符号化では、たとえＵＥがスロットｎ＋ｋ（対応するＰＤＳＣＨのＤＣＩで示されるフィードバックスロット）以外のスロットでＰＤＳＣＨ受信用のＨＡＲＱ－ＡＣＫ情報を報告しても、ＵＥは、対応する各ＨＡＲＱ－ＡＣＫ情報ビットの値を実際の値、即ち、ＰＤＳＣＨの検出結果に基づいて決定された値に設定する。

ＨＡＲＱフィードバックに使用される符号化のタイプ（即ち、タイプＡ又はタイプＢ）は、ネットワークデバイス（例えば、ｇＮＢ）によって構成されてもよい。

図６は、ＨＡＲＱフィードバックのためのタイプＡ及びタイプＢの例を概略的に示す。図６に示されるように、スロット６０１～６０５におけるＰＤＳＣＨセットに対するＨＡＲＱフィードバックはＲＲＣシグナリングを介して事前に決定され、又は構成されたタイミング／関連付けに従って、スロット６０６で送信されてもよいが、スロット６０３におけるＰＤＳＣＨのＤＣＩのみは、ＡＣＫ／ＮＡＣＫがスロット６０６にフィードバックされることを示す。そして、スロット６０６において、スロット６０１～６０５の５つのＡＣＫ／ＮＡＣＫビットが送信されるが、スロット６０３のＡＣＫ／ＮＡＣＫビットのみが実際の値に設定され、他のビットが、タイプＡの符号化に従ってＮＡＣＫに設定される。同様に、スロット６０２～６０５のＰＤＳＣＨセットに対するＨＡＲＱフィードバックが、所定のタイミング／関連付けに従ってスロット６０７で送信されてもよいが、スロット６０５におけるＰＤＳＣＨのＤＣＩのみは、ＡＣＫ／ＮＡＣＫがスロット６０７にフィードバックされることを示す場合には、スロット６０７において、スロット６０２～６０５の４つのＡＣＫ／ＮＡＣＫビットが送信されるが、スロット６０５のＡＣＫ／ＮＡＣＫビットのみが実際の値に設定され、他のビットがＮＡＣＫに設定される。タイプＡの符号化は、良好な送信性能を有するが、冗長な情報を提供しないため、スロット６０６におけるＰＵＣＣＨがミスで検出されないと、スロット６０３に対するＨＡＲＱフィードバックの値は、ネットワークデバイスに知らされない。

上記問題は、タイプＢの符号化によって解決されることができる。タイプＢの符号化では、スロット６０１～６０５におけるＰＤＳＣＨセットに対するＨＡＲＱフィードバックは、スロット６０６で送信され、また、スロット６０１～６０５のすべてのＡＣＫ／ＮＡＣＫビットは、それらの実際の値に設定される。同様に、スロット６０２～６０５における１つのＰＤＳＣＨセットに対するＨＡＲＱフィードバックは、スロット６０７で送信され、また、すべてのＡＣＫ／ＮＡＣＫビットは、それらの実際の値に設定される。これは、スロット６０２～６０５に対するフィードバックがスロット６０６及びスロット６０７の両方で送信されることを意味する。そのような場合、たとえスロット６０６のＰＵＣＣＨがミスで検出されていなくても、ネットワークデバイスは、スロット６０７のＨＡＲＱフィードバックからスロット６０２～６０５に対するＨＡＲＱフィードバックを回復することができる。

さらに、静的コードブックに基づくＨＡＲＱフィードバックの場合、ｇＮＢは、ＤＣＩにおいて、ＤＣＩが送信されるスロットに対するＰＵＣＣＨ送信のタイミング又はオフセットを示すことにより、ＨＡＲＱフィードバックの送信又は再送信をトリガーすることができる。

ここで、ＨＡＲＱフィードバックの例示的な方法７００のフローチャートを示す図７を参照する。方法７００は、ネットワークデバイス、例えば、図１に示すネットワークデバイス１０１によって実施され得る。説明の便宜上、以下、図１に示すネットワークデバイス１０１及び通信ネットワーク１００を参照して方法７００を説明する。しかしながら、本開示の実施形態はそれに限定されない。例えば、この方法は、いくつかのシナリオにおいて、Ｄ２Ｄ通信に関与する端末デバイスによって実施されてもよい。

図７に示されるように、ブロック７１０において、ネットワークデバイス１０１は、スケジューリングメッセージを端末デバイス、例えば、図１における１つの端末デバイス１０２に送信する。スケジューリングメッセージは、例えば、ＤＣＩを含んでもよい。それに加えて、スケジューリングメッセージには、ＨＡＲＱフィードバックに関する情報が含まれる。ＨＡＲＱフィードバックに関する情報は、ＨＡＲＱフィードバック用の処理ＩＤ（例えば、ＨＡＲＱ ＰＵＣＣＨ処理ＩＤ）及び／又は端末デバイス又は処理ＩＤのために送信されたスケジューリングメッセージの累積数を示す。いくつかの実施形態において、スケジューリングメッセージの累積数は、図２に示されるように、サイクリックＤＡＩの形態であってもよい。

ＨＡＲＱフィードバック用の処理ＩＤ及び／又はサイクリックＤＡＩは、端末デバイス１０２が、ＡＣＫ／ＮＡＣＫフィードバックが要求されるＰＤＳＣＨを決定することを容易にし、これにより、ＨＡＲＱフィードバックのペイロードサイズに関する不明確な問題を回避する。ＨＡＲＱフィードバックのペイロードサイズを決定するためのいくつかの例は、図２～３を参照して説明する。

いくつかの実施形態において、スケジューリングメッセージ、例えば、ＤＣＩは、同じＨＡＲＱフィードバックタイムスロットに関連付けられた所定の送信セット（例えば、ＰＤＳＣＨセット）で送信されたスケジューリングメッセージの合計数の指示（例えば、図２に示すカウンタＤＡＩの形態である）、同じＨＡＲＱフィードバックタイムスロットに関連付けられた所定の送信セット（例えば、ＰＤＳＣＨセット）で送信されようとするスケジューリングメッセージの合計数の指示（例えば、合計ＤＡＩの形態である）、及び、新しいＨＡＲＱフィードバックを提供するための指示のうちの１つ以上をさらに含んでもよい。

新しいＨＡＲＱフィードバックを提供するための指示は、トグルビット（toggle bit）であり得る新しいフィードバックインジケータ（ＮＦＩ：New Feedback Indicator）の形態であってもよい。つまり、ＤＣＩのＮＦＩは、ＵＥからの期待されたＨＡＲＱ－ＡＣＫフィードバックがｇＮＢによって正しく受信されたかどうかを示すことができる。例えば、ＮＦＩビットがトグルされていない場合には、ＮＦＩビットが最後にトグルされてからＨＡＲＱ－ＡＣＫ機会が受信されなかったことを意味する。この場合、ＵＥは、次に報告する機会に正しく受信されなかったＨＡＲＱ－ＡＣＫビットを自動的に含むことができ、即ち、ＨＡＲＱ－ＡＣＫビットを再送信することができる。一方、ＮＦＩビットがトグルされる場合には、ビットが最後にトグルされてからＨＡＲＱ－ＡＣＫ機会がｇＮＢによって受信されたことを意味するため、ＨＡＲＱ－ＡＣＫビットを再送信する必要がない。

いくつかの実施形態において、ＨＡＲＱフィードバックを容易にするように、サイクルＤＡＩ、ＨＡＲＱ ＰＵＣＣＨ ＩＤ、及びＮＦＩのうちの１つ以上の組み合わせは、ブロック７１０で端末デバイス１０２へスケジューリングメッセージで送信されてもよい。それに加えて、当該組み合わせは、ＨＡＲＱフィードバックに関連する他の情報、例えば、カウンタＤＡＩ及び／又は合計ＤＡＩとともに送信されてもよい。

ブロック７２０で、ネットワークデバイス１０１は、スケジューリングメッセージに従って、データを端末デバイス１０２へ送信する。限定ではない一例として、データは、ＰＤＳＣＨを介して送信される。

ブロック７３０で、ネットワークデバイス１０１は、端末デバイス１０２からＨＡＲＱフィードバックを受信し、ブロック７４０で、ネットワークデバイス１０１は、受信したＨＡＲＱフィードバックに基づいて、後続の送信又は再送信を制御する。ＨＡＲＱフィードバックに基づいて送信／再送信を制御する動作は、現在の通信システムの場合と同様に実行されることができる。例えば、データ送信のためにＮＡＣＫが受信されると、ネットワークデバイス１０１は、それに応じてデータ送信を再送信することができる。データ送信のためにＡＣＫが受信されると、ネットワークデバイス１０１は、データの再送信を阻止することができる。

図８は、ＨＡＲＱフィードバックの別の例示的な方法８００のフローチャートを示す。方法８００は、ネットワークデバイス、例えば、図１に示すネットワークデバイス１０１によって実施され得る。方法８００は、個別に、又は方法７００と組み合わせて実施されることができる。また、説明の便宜上、以下、図１に示すネットワークデバイス１０１及び通信ネットワーク１００を参照して方法８００を説明する。しかしながら、本開示の実施形態はそれに限定されない。例えば、この方法は、いくつかのシナリオにおいて、Ｄ２Ｄ通信に関与する端末デバイスによって実施されてもよい。

図８に示されるように、ブロック８１０で、ネットワークデバイス１０１は、スケジューリングメッセージを端末デバイス１０２へ送信する。スケジューリングメッセージは、図７を参照して説明したスケジューリングメッセージと同じであってもよく、異なってもよい。限定ではない一例として、スケジューリングメッセージはＤＣＩの形態であってもよい。

ネットワークデバイス１０１は、ブロック８２０で、例えば、ＰＤＳＣＨを介してスケジューリングメッセージに従って端末デバイス１０２へデータを送信するとともに、ブロック８３０で、端末デバイス１０２からのＨＡＲＱフィードバックを検出する。

ブロック８４０で、ネットワークデバイス１０１は、ＨＡＲＱフィードバックが検出されたリソースのリソースＩＤを決定する。リソースＩＤは、リソースに関連付けられたリソースセットグループの識別子を含む。リソースセットグループは、１つ以上のリソースセットを含み、リソースセットは、１つ以上のリソースを含む。つまり、リソースは、図４に示されるように、３ＤのＩＤを介して識別されることができる。

ブロック８５０で、ネットワークデバイス１０１は、受信したＨＡＲＱフィードバック及びリソースＩＤに基づいて、後続の送信又は再送信を制御する。限定ではない一例として、ＨＡＲＱフィードバックがｉ番目のリソースセットグループで検出された場合に、ネットワークデバイス１０１は、受信したＨＡＲＱフィードバックがｉ回目の再送信であると判定できる。そして、ネットワークデバイス１０１は、ＨＡＲＱフィードバックのｉ回目の再送信に関連付けられた以前のデータ送信を決定し、受信したＨＡＲＱフィードバックに基づいて以前のデータ送信の再送信を制御することができる。受信したＨＡＲＱフィードバックがＡＣＫである場合に、ネットワークデバイス１０１は、以前のデータ送信の再送信を阻止し、受信したＨＡＲＱフィードバックがＮＡＣＫである場合に、ネットワークデバイス１０１は、以前のデータ送信の再送信を実行する。例えば、図５に示される例において、リソースセットグループ２に属するリソース２においてＮＡＣＫが検出された場合に、ネットワークデバイス１０１は、スロットｎにおけるＰＤＳＣＨに対するＮＡＣＫの２回目の再送信であると判定できる。その結果、ネットワークデバイス１０１は、スロットｎで以前に送信されたＰＤＳＣＨを再送信する。

図９は、ＨＡＲＱフィードバックの別の例示的な方法９００のフローチャートを示す。方法９００は、ネットワークデバイス、例えば、図１に示すネットワークデバイス１０１によって実施され得る。方法９００は、個別に、又は方法７００及び方法８００のうちの１つ以上との組み合わせで実施されることができる。説明の便宜上、また、以下、図１に示すネットワークデバイス１０１及び通信ネットワーク１００を参照して方法９００を説明する。しかしながら、本開示の実施形態はそれに限定されない。例えば、この方法は、いくつかのシナリオにおいて、Ｄ２Ｄ通信に関与する端末デバイスによって実施されてもよい。

図９に示されるように、ブロック９１０で、ネットワークデバイス１０１は、ＨＡＲＱフィードバックのためのコーディング構成を端末デバイス１０２へ送信する。コーディング構成は、静的ＨＡＲＱコードブックのための符号化のタイプを示す。限定ではない一例として、コーディング構成は、ＲＲＣシグナリング又はシステム情報を介して送信され得る。

ブロック９２０で、ネットワークデバイス１０１は、データを端末デバイス１０２へ送信し、ブロック９３０で、示されたタイプの符号化に基づいて、端末デバイス１０２からのデータに対するＨＡＲＱフィードバックを検出する。

いくつかの実施形態において、符号化のタイプは、図６を参照して上記で説明したように、タイプＡ及びタイプＢの符号化のうちの１つを含み得る。説明の目的で、仮にネットワークデバイス１０１がデータをスケジューリングメッセージ（例えば、ＤＣＩ）と共にタイムスロットｎで端末デバイス１０２へ送信し、かつ、スケジューリングメッセージは、ＨＡＲＱフィードバックが端末デバイス１０２によってタイムスロットｎ＋ｋで提供されることを示し、ここで、ｎ及びｋの両方が負ではない整数（non-negative integers）であり、そして、タイプＡがブロック９１０で示される場合に、データに対するＨＡＲＱフィードバックがタイムスロットｎ＋ｋで受信されると、ネットワークデバイス１０１は、ＨＡＲＱフィードバックを復号化し、一方、データに対するＨＡＲＱフィードバックがタイムスロットｎ＋ｋ以外のタイムスロットで検出されると、ネットワークデバイス１０１は、受信したＨＡＲＱフィードバックビットをＮＡＣＫとして解釈する。これに対して、符号化タイプＢがブロック９１０で示される場合に、ネットワークデバイス１０１は、ＨＡＲＱフィードバックがタイムスロットｎ＋ｋで検出されるか又は別のタイムスロットで検出されるかにかかわらず、ＨＡＲＱフィードバックを復号化する。タイプＢの符号化は、ＨＡＲＱフィードバックの冗長性を高める。

ブロック９４０で、ネットワークデバイス１０１は、検出されたＨＡＲＱフィードバックに基づいて、後続の送信または再送信を制御する。いくつかの実施形態において、現在のＨＡＲＱメカニズムで使用される動作と同様のものは、ブロック９４０で実施され得る。

図１０は、ＨＡＲＱフィードバックの例示的な方法１０００のフローチャートを示す。方法１０００は、端末デバイス、例えば、図１に示す１つの端末デバイス１０２によって実施されることができる。説明の便宜上、以下、図１に示す端末デバイス１０２及び通信ネットワーク１００を参照して方法１０００を説明する。しかしながら、本開示の実施形態はそれに限定されない。

図１０に示されるように、ブロック１０１０で、端末デバイス１０２は、ネットワークデバイス１０１からスケジューリングメッセージを受信する。スケジューリングメッセージは、ＨＡＲＱフィードバックに関する情報を含み、ＨＡＲＱフィードバックに関する情報は、ＨＡＲＱフィードバック用の処理ＩＤ、および端末デバイス又は処理ＩＤのために送信されたスケジューリングメッセージの累積数のうちの少なくとも１つを示す。

いくつかの実施形態において、スケジューリングメッセージは、ＤＣＩの形態であってもよい。いくつかの実施形態において、スケジューリングメッセージは、方法７００を参照して説明されたものと同じであってもよく、従って、方法７００の関連説明もここに適用する。

いくつかの実施形態において、ＨＡＲＱフィードバック用の処理ＩＤは、ＨＡＲＱ ＰＵＣＣＨ処理ＩＤの形態であってもよく、スケジューリングメッセージの累積数は、サイクルＤＡＩの形態であってもよい。

いくつかの実施形態において、スケジューリングメッセージは、さらに、同じＨＡＲＱフィードバックタイムスロットに関連付けられた所定の送信セット（例えば、ＰＤＳＣＨセット）で送信されたスケジューリングメッセージの合計数の指示（例えば、カウンタＤＡＩ）、同じＨＡＲＱフィードバックタイムスロットに関連付けられた所定の送信セット（例えば、ＰＤＳＣＨセット）で送信されようとするスケジューリングメッセージの合計数の指示（例えば、合計ＤＡＩ）、及び／又は、新しいＨＡＲＱフィードバックを提供するための指示（例えば、ＮＦＩ）のうちの１つ以上を含んでもよい。

ブロック１０２０で、端末デバイス１０２は、スケジューリングメッセージ（例えば、ＤＣＩ）に従ってネットワークデバイス１０１からのデータを検出し、ブロック１０３０で、端末デバイス１０２は、ＨＡＲＱフィードバックに関する情報に基づいて、ＨＡＲＱフィードバックをネットワークデバイス１０１へ送信する。

いくつかの実施形態において、ＨＡＲＱフィードバックに関する情報は、端末デバイス又は処理ＩＤのために（可能性として、複数のＰＤＳＣＨセットにわたって）送信されたスケジューリングメッセージ（例えば、ＤＣＩ）の累積数を示すサイクリックＤＡＩを含んでもよい。このような実施形態において、ブロック１０３０で、端末デバイス１０２は、サイクリックＤＡＩに基づいてＨＡＲＱフィードバックのために送信されたビットの合計数を決定し、決定されたビットの合計数を有するＨＡＲＱフィードバックをネットワークデバイス１０１へ送信することができる。

いくつかの実施形態において、ＨＡＲＱフィードバックに関する情報は、ＨＡＲＱ ＰＵＣＣＨ処理ＩＤを含んでもよい。このような場合に、端末デバイス１０２は、処理ＩＤに関連付けられた１つ以上の以前のダウンリンクデータ送信を決定し、１つ以上の以前のダウンリンクデータ送信に対するＨＡＲＱフィードバックとともに、検出されたデータに対するＨＡＲＱフィードバックをネットワークデバイス１０１へ送信することができる。

図１１は、ＨＡＲＱフィードバックの別の例示的な方法１１００のフローチャートを示す。方法１１００は、端末デバイス、例えば、図１に示される１つの端末デバイス１０２によって実施され得る。方法１１００は、個別に、又は方法１０００と組み合わせて実施され得ることに留意されたい。説明の便宜上、以下、図１に示す端末デバイス１０２及び通信ネットワーク１００を参照して方法１１００を説明する。しかしながら、本開示の実施形態はそれに限定されない。

図１１に示されるように、ブロック１１１０で、端末デバイス１０２は、ネットワークデバイス１０１からデータを受信する。ＨＡＲＱメカニズムでは、端末デバイス１０２は、受信したデータに対してフィードバックを提供する必要がある。しかしながら、いくつかのシナリオでは、例えば、ＮＲ－Ｕ通信システムにおいて、免許不要帯域でのＬＢＴ故障に起因して、フィードバックがブロックされ、又は失敗する場合がある。従って、場合によって、端末デバイス１０２は、ＨＡＲＱフィードバックを再送信することを決定することができる。

端末デバイス１０２がデータに対するフィードバックをｉ回目に再送信することを決定した場合に、ブロック１１２０で、端末デバイス１０２は、ｉ番目のリソースセットグループからリソースを選択し、ここで、ｉは正の整数である。リソースセットグループは、１つ以上のリソースセットを含み、リソースセットは、１つ以上のフィードバックリソースを含む。

ブロック１１３０で、端末デバイス１０２は、選択されたリソースでデータに対するフィードバックを再送信する。このようにして、端末デバイス１０２は、ネットワークデバイス側での不明確な問題を回避するために、ネットワークデバイス１０１へのＨＡＲＱフィードバックのために実行された再送信の回数を暗黙的に示すことができる。

図１２は、ＨＡＲＱフィードバックの別の例示的な方法１２００のフローチャートを示す。方法１２００は、端末デバイス、例えば、図１に示す１つの端末デバイス１０２によって実施され得る。方法１２００は、個別に、又は方法１０００及び１１００のうちの１つ以上との組み合わせで実施され得ることに留意されたい。説明の便宜上、また、以下、図１に示す端末デバイス１０２及び通信ネットワーク１００を参照して方法１２００を説明する。しかしながら、本開示の実施形態はそれに限定されない。

図１２に示されるように、ブロック１２１０では、端末デバイス１０２は、ネットワークデバイス１０１からＨＡＲＱフィードバックのためのコーディング構成を受信する。コーディング構成は、静的ＨＡＲＱコードブックのための符号化のタイプを示す。いくつかの実施形態において、示されたタイプの符号化は、タイプＡ又はタイプＢの符号化を含む。例えば、コーディング構成は、ＲＲＣシグナリング又はシステム情報を介して受信されてもよいが、これに限定されない。

ブロック１２２０で、端末デバイス１０２は、ネットワークデバイス１０１からデータを受信し、ブロック１２３０で、端末デバイス１０２は、コーディング構成に基づいてデータに対するＨＡＲＱフィードバックを生成する。

例えば、ブロック１２２０で、端末デバイス１０２は、タイムスロットｎでネットワークデバイス１０１からスケジューリングメッセージ（例えば、ＤＣＩ）と共にデータを受信することができる。スケジューリングメッセージは、ＨＡＲＱフィードバックがタイムスロットｎ＋ｋで端末デバイス１０２によって提供されることを示し、ここで、ｎ及びｋは両方とも負ではない整数である。

ブロック１２１０でタイプＡの符号化が構成される一実施形態において、端末デバイス１０２がタイムスロットｎ＋ｋでデータに対するＨＡＲＱフィードバックを送信することを決定すると、ブロック１２３０で、端末デバイス１０２は、タイムスロットｎで受信したデータ送信の検出結果に依存してＨＡＲＱフィードバックビットを生成する。一方、端末デバイス１０２がタイムスロットｎ＋ｋ以外のタイムスロットでデータに対するＨＡＲＱフィードバックを送信することを決定すると、ブロック１２３０で、端末デバイス１０２は、データ送信用のＮＡＣＫビットを生成する。

ブロック１２１０でタイプＢの符号化が構成されるいくつかの実施形態において、ブロック１２３０で、端末デバイス１０２は、ＨＡＲＱフィードバックがタイムスロットｎ＋ｋで送信されるか又は別のスロットで送信されるかに関わらず、タイムスロットｎで受信されたデータ送信の検出結果に依存してＨＡＲＱフィードバックビットを生成する。

ブロック１２４０で、端末デバイス１０２は、生成したＨＡＲＱフィードバックをネットワークデバイス１０１へ送信する。図６を参照して説明したように、タイプＢの符号化では、端末デバイス１０２は、ＰＤＳＣＨのＨＡＲＱフィードバックを複数回送信することができるため、冗長性を提供し、これにより、ネットワークデバイス１０１は、一回の送信が失敗したとしても、ＨＡＲＱフィードバックを回復することができる。

上記実施形態から、ＵＥは、スロットｎで受信したＰＤＳＣＨに応答し、ＨＡＲＱフィードバックのためにタイプＡ又はタイプＢの符号化を使用するように構成されてもよく、ＵＥがスロットｎ＋ｋ以外のスロットでＰＤＳＣＨ受信のＨＡＲＱ－ＡＣＫ情報を報告する場合、ＵＥは、タイプＡが設定されると、対応する各ＨＡＲＱ－ＡＣＫ情報ビットの値をＮＡＣＫに設定し、タイプＢが構成されると、対応する各ＨＡＲＱ－ＡＣＫ情報ビットの値をＨＡＲＱ－ＡＣＫ情報ビットに設定し、ｋの値はスロットｎのＰＤＳＣＨに関連付けられたＤＣＩで示されてもよい。

図１３は、端末デバイス（例えば、図１に示す端末デバイス１０２）又はネットワークデバイス（例えば、図１に示すネットワークデバイス１０１）として具現化され又はそれに備えられる装置１３００の簡略化ブロック図を示す。

装置１３００は、データプロセッサ（ＤＰ）などの少なくとも１つのプロセッサ１３１１と、プロセッサ１３１１に接続される少なくとも１つのメモリ（ＭＥＭ）１３１２とを備える。装置１３００は、プロセッサ１３１１に接続される送信機ＴＸ及び受信機ＲＸ１３１３をさらに備えてもよく、送信機ＴＸ及び受信機ＲＸ１３１３は他の装置に通信可能に接続するように動作できる。ＭＥＭ１３１２は、プログラム及びコンピュータプログラムコード１３１４を格納する。少なくとも１つのメモリ１３１２及びコンピュータプログラムコード１３１４は、少なくとも１つのプロセッサ１３１１で装置１３００を少なくとも本開示の実施形態、例えば、方法７００－１２００のいずれかに従って実行させるように構成されている。

少なくとも１つのプロセッサ１３１１と少なくとも１つのＭＥＭ１３１２との組み合わせは、本開示の様々な実施形態を実施するのに構成された処理手段を形成することができる。

本開示の様々な実施形態は、プロセッサ１３１１によって実行可能なコンピュータプログラム、ソフトウェア、ファームウェア、ハードウェア、又はそれらの組み合わせによって実施されてもよい。

ＭＥＭ１３１２は、ローカルの技術的環境に適した任意のタイプのものでもよく、非限定的な例として、半導体ベースのメモリデバイス、磁気メモリデバイス及びシステム、光学メモリデバイス及びシステム、固定メモリ及びリムーバブルメモリなど、任意の適切なデータ記憶技術を使用して実施されてもよい。

プロセッサ１３１１は、ローカルの技術的環境に適した任意のタイプでもよく、非限定的な例として、汎用コンピュータ、専用コンピュータ、マイクロプロセッサ、デジタルシグナルプロセッサ（ＤＳＰ）及びマルチコアプロセッサアーキテクチャに基づくプロセッサのうちの１つ以上を含んでもよい。

さらに、本開示は上述のようなコンピュータプログラムを含むキャリアも提供できる。キャリアは、コンピュータ読み取り可能な記憶媒体及び送信媒体を含む。コンピュータ読み取り可能な記憶媒体は、例えば、光学コンパクトディスク、又はＲＡＭ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）、ＲＯＭ（ｒｅａｄ ｏｎｌｙ ｍｅｍｏｒｙ）、フラッシュメモリ、磁気テープ、ＣＤ－ＲＯＭ、ＤＶＤ、Ｂｌｕｅ－ｒａｙディスクなどのような電子メモリデバイスでもよい。送信媒体は、例えば、電気、光学、無線、音響、又は、搬送波、赤外線信号などの他の形態の伝搬信号を含んでもよい。

本明細書で説明された技術は、様々な手段で実施されてもよい。そのため、実施形態で説明された対応する装置の１つ又は複数の機能を実施する装置は、従来技術の手段を備えるだけでなく、対応する装置の１つ又は複数の機能を実施するための手段を備え、別々の機能ごとに別々の手段を備えてもよいし、２つ以上の機能を実施するように設定される手段を備えてもよい。例えば、これらの技術は、ハードウェア（例えば、回路又はプロセッサ）、ファームウェア、ソフトウェア、又はそれらの組み合わせで実施されてもよい。ファームウェア又はソフトウェアの場合、本明細書で説明された機能を実行するモジュール（例えば、手順、機能など）を介して実施されてもよい。

本明細書におけるいくつかの例示的な実施形態は、上記のように、方法及び装置のブロック図及びフローチャート図を参照して説明された。ブロック図及びフローチャート図の各ブロック、ならびにブロック図及びフローチャート図におけるブロックの組み合わせは、それぞれ、コンピュータプログラム命令を含む様々な手段によって実施できることが理解される。これらのコンピュータプログラム命令は、汎用コンピュータ、専用コンピュータ、又は機械を製造するための他のプログラマブルデータ処理装置にロードされ、コンピュータ又は他のプログラマブルデータ処理装置で実行される命令が、フローチャートのブロックで特定された機能を実行するための手段を形成するようにしてもよい。

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

技術の進歩につれて、本発明の概念を様々な方法で実施できることは、当業者にとって明らかである。上記の実施形態は、本開示を限定するものではなく説明するために提供され、当業者が容易に理解するように、本開示の意図及び範囲から逸脱することなく修正及び変更することができる。そのような修正及び変更は、本開示の範囲及び添付の特許請求の範囲内に含まれると見なされる。本開示の保護範囲は、添付の特許請求の範囲によって定義される。

本開示で使用されるいくつかの略語及びそれらに対応する表現を以下にリストする。
３ＧＰＰ 第３世代パートナーシッププロジェクト
ＬＴＥ 長期的進化
ＮＲ 新しい無線
ＮＲ－Ｕ ＮＲ－ｕｎｌｉｃｅｎｓｅｄ
ＬＡＡ ＬＴＥライセンス補助アクセス
ＨＡＲＱ ハイブリッド自動再送要求
ＰＵＣＣＨ 物理アップリンク制御チャネル
ＰＵＳＣＨ 物理アップリンク共有チャネル
ＰＤＳＣＨ 物理ダウンリンク共有チャネル
ＤＣＩ ダウンリンク制御インジケータ
ＵＣＩ アップリンク制御情報
ＡＣＫ 肯定応答
ＮＡＣＫ 否定応答
ＣＣＡ 明確なチャネル評価
ＬＢＴ リッスンビフォアトーク
ＣＯＴ チャネル占有時間
Ｃ－ＲＮＴＩ セル無線網臨時識別子

Claims (3)

1. 無線通信のための方法であって、
   スケジューリングメッセージを端末デバイスへ送信することと、
   前記スケジューリングメッセージに従ってデータを前記端末デバイスへ送信することと、
   前記端末デバイスからハイブリッド自動再送要求（ＨＡＲＱ：ｈｙｂｒｉｄ ａｕｔｏｍａｔｉｃ ｒｅｐｅａｔ ｒｅｑｕｅｓｔ）フィードバックを検出することと、
   前記ＨＡＲＱフィードバックが検出されたリソースのリソースＩＤを決定することと、
   前記受信したＨＡＲＱフィードバック及び前記リソースＩＤに基づいて、後続の送信又は再送信を制御することと、
   を備え、
   前記リソースＩＤは前記リソースに関連付けられたリソースセットグループの識別子を含み、リソースセットグループは１つ以上のリソースセットを含み、リソースセットは１つ以上のリソースを含む、
   方法。
2. 前記受信したＨＡＲＱフィードバック及び前記リソースＩＤに基づいて、後続の送信又は再送信を制御することは、
   前記リソースセットグループの前記識別子がｉ番目のリソースセットグループを示すことに応答して、前記受信したＨＡＲＱフィードバックがＨＡＲＱフィードバックのｉ回目の再送信であると判定することと、
   前記ＨＡＲＱフィードバックの前記ｉ回目の再送信に関連付けられた以前のデータ送信を決定することと、
   前記受信したＨＡＲＱフィードバックに基づいて、前記以前のデータ送信の再送信を制御することと、
   を含む、
   請求項１に記載の方法。
3. 前記受信したＨＡＲＱフィードバックに基づいて、前記以前のデータ送信の再送信を制御することは、
   前記受信したＨＡＲＱフィードバックが肯定応答（ＡＣＫ：ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）であることに応答して、前記以前のデータ送信の再送信を阻止することと、
   前記受信したＨＡＲＱフィードバックが否定応答（ＮＡＣＫ：ｎｅｇａｔｉｖｅ ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）であることに応答して、前記以前のデータ送信の再送信を実行することと、
   を含む、
   請求項１に記載の方法。

Images