(57)【要約】  本出願はコンテンションウィンドウサイズを調整するための方法および装置を開示する。方法は、第1のデバイスにより、第1のHARQプロセス識別子に対応する少なくとも2つのHARQ状態を取得するステップであって、少なくとも2つのHARQ状態は相違し、第1のHARQプロセス識別子が、第1のデバイスが基準時間単位で第2のデバイスにデータを送信するときに使用されるHARQプロセス識別子である、ステップと、第1のデバイスにより、少なくとも2つのHARQ状態のうちの有効なHARQ状態を決定するステップと、有効なHARQ状態に基づいて第1のバーストのためのコンテンションウィンドウサイズを調整するステップであって、第1のバーストが基準時間単位よりも遅い、ステップとを含む。したがって、第1のデバイスは、コンテンションウィンドウ調整の精度を向上させ、チャネルアクセス効率を改善するために、その後HARQ−ACKをデフォルト状態にリセットすることによって生じる不正確なCWS調整を回避することができる。
2020522948.tif 000002
【特許請求の範囲】
【請求項１】
コンテンションウィンドウサイズを調整するための方法であって、前記方法は、
第1のデバイスにより、第1のハイブリッド自動再送要求HARQプロセス識別子に対応する少なくとも2つのHARQ状態を取得するステップであって、前記少なくとも2つのHARQ状態は相違し、前記第1のHARQプロセス識別子は、前記第1のデバイスが基準時間単位で第2のデバイスにデータを送信するときに使用されるHARQプロセス識別子である、ステップと、
前記第1のデバイスにより、前記少なくとも2つのHARQ状態のうちの有効なHARQ状態を決定するステップと、
前記第1のデバイスにより、前記有効なHARQ状態に基づいて第1のバーストのためのコンテンションウィンドウサイズを調整するステップであって、前記第1のバーストは前記基準時間単位よりも遅く、前記少なくとも2つのHARQ状態を搬送する任意の時間単位は前記基準時間単位よりも遅く、前記少なくとも2つのHARQ状態を搬送する任意の時間単位と前記基準時間単位との間の時間間隔は第1のプリセット時間間隔以上である、ステップとを備える、方法。
【請求項２】
前記少なくとも2つのHARQ状態のうちの任意のHARQ状態は、前記第1のHARQプロセス識別子に対応する同じトランスポートブロックに対応する、請求項1に記載の方法。
【請求項３】
前記第1のデバイスはネットワークデバイスであり、前記第2のデバイスは端末デバイスであり、前記第1のHARQプロセス識別子は前記第2のデバイスのためのHARQプロセス識別子である、請求項1または2に記載の方法。
【請求項４】
前記第1のデバイスは端末デバイスであり、前記第2のデバイスはネットワークデバイスであり、前記第1のHARQプロセス識別子は前記第1のデバイスに対応するHARQプロセス識別子である、請求項1または2に記載の方法。
【請求項５】
前記少なくとも2つのHARQ状態は少なくとも2つのアップリンク時間単位で搬送され、前記少なくとも2つのHARQ状態の各々が、前記第2のデバイスによって送信され、前記第1のデバイスによって検出されるHARQ状態であるとき、前記有効なHARQ状態は、前記少なくとも2つのアップリンク時間単位のうちの最も早いアップリンク時間単位で搬送されるHARQ状態である、請求項3に記載の方法。
【請求項６】
前記少なくとも2つのHARQ状態が不連続伝送DTX状態および非DTX状態を含むとき、前記有効なHARQ状態は前記非DTX状態であり、前記非DTX状態は、前記第2のデバイスによって送信され、前記第1のデバイスによって検出されるHARQ状態である、請求項3に記載の方法。
【請求項７】
前記少なくとも2つのHARQ状態がDTX状態および少なくとも2つの非DTX状態を含み、前記少なくとも2つの非DTX状態が少なくとも2つのアップリンク時間単位で搬送されるとき、前記有効なHARQ状態は、前記少なくとも2つのアップリンク時間単位のうちの最も早いアップリンク時間単位で搬送される非DTX状態である、請求項6に記載の方法。
【請求項８】
前記少なくとも2つのHARQ状態は少なくとも2つのダウンリンク時間単位で搬送され、前記有効なHARQ状態は、前記少なくとも2つのダウンリンク時間単位のうちの最も早いダウンリンク時間単位で搬送されるHARQ状態である、請求項4に記載の方法。
【請求項９】
前記少なくとも2つのHARQ状態の各々が、前記第2のデバイスによって送信されるHARQフィードバック情報内で搬送されるとき、前記有効なHARQ状態は、前記少なくとも2つのダウンリンク時間単位のうちの前記最も早いダウンリンク時間単位で搬送される前記HARQ状態である、請求項8に記載の方法。
【請求項１０】
前記少なくとも2つのHARQ状態は肯定応答ACK状態を含み、前記有効なHARQ状態は前記ACK状態である、請求項1から4のいずれか一項に記載の方法。
【請求項１１】
コンテンションウィンドウサイズを調整するためのデバイスであって、
第1のハイブリッド自動再送要求HARQプロセス識別子に対応する少なくとも2つのHARQ状態を取得するよう構成されたトランシーバであって、前記少なくとも2つのHARQ状態は相違し、前記第1のHARQプロセス識別子は、前記デバイスが基準時間単位で第2のデバイスにデータを送信するときに使用されるHARQプロセス識別子である、トランシーバと、
前記少なくとも2つのHARQ状態のうちの有効なHARQ状態を決定し、前記有効なHARQ状態に基づいて第1のバーストのためのコンテンションウィンドウサイズを調整するよう構成されたプロセッサであって、前記第1のバーストは前記基準時間単位よりも遅く、前記少なくとも2つのHARQ状態を搬送する任意の時間単位は前記基準時間単位よりも遅く、前記少なくとも2つのHARQ状態を搬送する任意の時間単位と前記基準時間単位との間の時間間隔は第1のプリセット時間間隔以上である、プロセッサとを備える、デバイス。
【請求項１２】
前記少なくとも2つのHARQ状態のうちの任意のHARQ状態は、前記第1のHARQプロセス識別子に対応する同じトランスポートブロックに対応する、請求項11に記載のデバイス。
【請求項１３】
前記デバイスはネットワークデバイスであり、前記第2のデバイスは端末デバイスであり、前記第1のHARQプロセス識別子は前記第2のデバイスのためのHARQプロセス識別子である、請求項11または12に記載のデバイス。
【請求項１４】
前記デバイスは端末デバイスであり、前記第2のデバイスはネットワークデバイスであり、前記第1のHARQプロセス識別子は前記デバイスに対応するHARQプロセス識別子である、請求項11または12に記載のデバイス。
【請求項１５】
前記少なくとも2つのHARQ状態は少なくとも2つのアップリンク時間単位で搬送され、前記少なくとも2つのHARQ状態の各々が、前記第2のデバイスによって送信され、前記第1のデバイスによって検出されるHARQ状態であるとき、前記有効なHARQ状態は、前記少なくとも2つのアップリンク時間単位のうちの最も早いアップリンク時間単位で搬送されるHARQ状態である、請求項13に記載のデバイス。
【請求項１６】
前記少なくとも2つのHARQ状態が不連続伝送DTX状態および非DTX状態を含むとき、前記有効なHARQ状態は前記非DTX状態であり、前記非DTX状態は、前記第2のデバイスによって送信され、前記第1のデバイスによって検出されるHARQ状態である、請求項13に記載のデバイス。
【請求項１７】
前記少なくとも2つのHARQ状態はDTX状態および少なくとも2つの非DTX状態を含み、前記少なくとも2つの非DTX状態が少なくとも2つのアップリンク時間単位で搬送されるとき、前記有効なHARQ状態は、前記少なくとも2つのアップリンク時間単位のうちの最も早いアップリンク時間単位で搬送される非DTX状態である、請求項16に記載のデバイス。
【請求項１８】
前記少なくとも2つのHARQ状態は少なくとも2つのダウンリンク時間単位で搬送され、前記有効なHARQ状態は、前記少なくとも2つのダウンリンク時間単位のうちの最も早いダウンリンク時間単位で搬送されるHARQ状態である、請求項14に記載のデバイス。
【請求項１９】
前記少なくとも2つのHARQ状態の各々が、前記第2のデバイスによって送信されるHARQフィードバック情報内で搬送されるとき、前記有効なHARQ状態は、前記少なくとも2つのダウンリンク時間単位のうちの前記最も早いダウンリンク時間単位で搬送される前記HARQ状態である、請求項18に記載のデバイス。
【請求項２０】
前記少なくとも2つのHARQ状態は肯定応答ACK状態を含み、前記有効なHARQ状態は前記ACK状態である、請求項11から14のいずれか一項に記載のデバイス。
【請求項２１】
コンピュータ可読記憶媒体であって、前記コンピュータ可読記憶媒体は命令を記憶し、前記命令がコンピュータ上で実行されると、前記コンピュータが請求項1から10のいずれか一項に記載の方法を行うことが可能になる、コンピュータ可読記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、参照によりその全体が本明細書に組み込まれる、2017年6月6日に中国特許庁に出願され、「METHOD AND DEVICE FOR ADJUSTING CONTENTION WINDOW SIZE」と題する、中国特許出願第201710420188．9号に基づく優先権を主張する。
【０００２】
本出願は、ワイヤレス通信技術の分野に関し、特に、コンテンションウィンドウサイズを調整するための方法およびデバイスに関する。
【背景技術】
【０００３】
さまざまな事業者の基地局およびUE、ならびに免許不要スペクトル上のWi−Fiなどのシステム間ワイヤレスノードとの友好的な共存を実装するために、免許支援アクセス（Licensed−Assisted Access、LAA）／拡張免許支援アクセス（enhanced LAA、eLAA）／Multefireシステムは、リッスンビフォアトーク（Listen−Before−Talk、LBT）チャネルアクセスメカニズムを使用する。たとえば、ダウンリンク伝送を送信する前に、送信ノードはチャネルを検知する必要があり、チャネルがアイドル状態であることを検知した後にダウンリンク情報を送信する。具体的には、ダウンリンクLBTはランダムバックオフベースのクリアチャネル評価（Clear Channel Assessment、CCA）である。送信ノードは、均等に0とコンテンションウィンドウサイズ（Contention Window Size、CWS）との間のバックオフカウンタNをランダムに生成し、検知スロット（CCA slot）の粒度で検知を実行する。リスニングスロットにおいて、チャネルがアイドルであることを検出した場合、送信ノードはバックオフカウンタから1を減算する。リスニングスロットにおいて、チャネルがビジーであることを検出した場合、送信ノードはバックオフカウンタを一時停止し、言い換えれば、チャネルがビジーである時間期間において、チャネルがアイドルであることが検出されるまで、バックオフカウンタNは変わらないままである。バックオフカウンタが0に減少すると、送信ノードはチャネルを直ちに占有することができる。
【０００４】
さらに、送信ノードは、ダウンリンクLBTのためのダウンリンクCWSを動的に調整し、言い換えれば、送信ノードは、ダウンリンク基準サブフレームのために端末によってフィードバックされるハイブリッド自動再送要求確認（Hybrid Automatic Repeat request−Acknowledgement、HARQ−ACK）状態に基づいて、ダウンリンクバーストのためのCWSを動的に調整する。具体的には、ダウンリンク基準サブフレームに対するHARQ−ACK状態での否定応答（Negative Acknowledgement、NACK）の割合が比較的大きいと決定すると、送信ノードは、検知時間を延長することにより、周囲の競合ノードとの衝突を回避し、友好的な共存を実装するためにCWSを増大させる。ダウンリンク基準サブフレームに対するHARQ−ACK状態での肯定応答（Acknowledgement、ACK）の割合が比較的大きいとき、送信ノードは、検知時間を短縮し、より迅速にチャネルにアクセスするためにCWSを減少させる。ダウンリンクLBTと同様に、アップリンクLBTがランダムバックオフベースのCCAであるとき、端末はアップリンクLBTのためのアップリンクCWSを動的に調整し、言い換えれば、端末は、アップリンク基準サブフレームに対するHARQ−ACK状態に基づいて、アップリンクバーストのためのCWSを動的に調整する。アップリンク基準サブフレームに対するHARQ−ACK状態がACKであるとき、端末はCWSを減少させ、そうでない場合、端末はCWSを増大させる。
【０００５】
Multefire 1．0システムの場合、ダウンリンクデータチャネル向けのDL HARQ−ACKフィードバックが導入される。DL HARQ−ACKは、免許不要スペクトル上のPUCCH上で搬送されてもよく、免許不要スペクトル上のPUSCH上で搬送されてもよい。DL HARQ−ACK情報は、ビットマッピング（bit map）に基づき、ダウンリンクHARQプロセスセット内のすべてのHARQプロセスに対応するHARQ−ACK状態を含む。さらに、GULベースのMultefire 1．1システムでは、ネットワークデバイスがGUL PUSCHの受信状態をフィードバックすることを支援するために、アップリンクデータチャネル向けのUL HARQ−ACKフィードバックが導入され、グラント・フリー・ダウンリンク制御情報（Grantfree−Downlink Control Information、G−DCI）内で搬送される。UL HARQ−ACK情報は、ビットマッピングに基づき、アップリンクHARQプロセスセット内のすべてのHARQプロセスに対応するHARQ−ACK状態を含む。
【発明の概要】
【０００６】
したがって、免許不要スペクトル上のダウンリンク伝送向けに新しいDL HARQ−ACKフィードバック情報が導入され、免許不要スペクトル上のアップリンク伝送向けに新しいUL HARQ−ACKフィードバック情報が導入される。ダウンリンクCWSおよびアップリンクCWSがチャネル状態を正確に反映し、周囲の競合ノードとの友好的な共存を実装することができるよう、ダウンリンクCWSおよびアップリンクCWSを正確に調整することが急務である。
【課題を解決するための手段】
【０００７】
本出願の実施形態は、コンテンションウィンドウサイズ調整の精度を向上させるために、コンテンションウィンドウサイズを調整するための方法およびデバイスを提供する。
【０００８】
本出願の実施形態における方法は以下の通りである。
【０００９】
第1の態様によれば、コンテンションウィンドウサイズを調整するための方法が提供される。方法は、第1のデバイスにより、第1のハイブリッド自動再送要求HARQプロセス識別子に対応する少なくとも2つのHARQ状態を取得するステップであって、少なくとも2つのHARQ状態は相違し、第1のHARQプロセス識別子が、第1のデバイスが基準時間単位で第2のデバイスにデータを送信するときに使用されるHARQプロセス識別子である、ステップと、第1のデバイスにより、少なくとも2つのHARQ状態のうちの有効なHARQ状態を決定するステップと、有効なHARQ状態に基づいて第1のバーストのためのコンテンションウィンドウサイズを調整するステップであって、第1のバーストが基準時間単位よりも遅い、ステップとを含む。したがって、本出願のこの実施形態で提供される方法によれば、第1のデバイスは、コンテンションウィンドウ調整の精度を向上させ、チャネルアクセス効率を改善するために、その後HARQ−ACKをデフォルト状態にリセットすることによって生じる不正確なCWS調整を回避することができる。
【００１０】
可能な設計では、少なくとも2つのHARQ状態のうちの任意のHARQ状態は、第1のHARQプロセス識別子に対応する同じトランスポートブロックに対応する。したがって、本出願のこの実施形態は、第1のHARQプロセス識別子が1つのトランスポートブロックに対応するか、複数のトランスポートブロックに対応するかに制限を課さず、複数のアプリケーションシナリオに適用することができる。
【００１１】
可能な設計では、第1のデバイスはネットワークデバイスであり、第2のデバイスは端末デバイスであり、第1のHARQプロセス識別子は第2のデバイスのためのHARQプロセス識別子である。したがって、本出願のこの実施形態は、ダウンリンク伝送シナリオに適用することができる。
【００１２】
可能な設計では、第1のデバイスは端末デバイスであり、第2のデバイスはネットワークデバイスであり、第1のHARQプロセス識別子は第1のデバイスに対応するHARQプロセス識別子である。したがって、本出願のこの実施形態は、アップリンク伝送シナリオに適用することができる。
【００１３】
可能な設計では、少なくとも2つのHARQ状態は少なくとも2つのアップリンク時間単位で搬送され、有効なHARQ状態は、少なくとも2つのアップリンク時間単位のうちの最も早いアップリンク時間単位で搬送されるHARQ状態である。したがって、本出願のこの実施形態で提供される方法によれば、有効なHARQ状態を容易に決定することができる。
【００１４】
可能な設計では、少なくとも2つのHARQ状態の各々が、第2のデバイスによって送信され、第1のデバイスによって検出されるHARQ状態であるとき、有効なHARQ状態は、少なくとも2つのアップリンク時間単位のうちの最も早いアップリンク時間単位で搬送されるHARQ状態である。したがって、本出願のこの実施形態で提供される方法によれば、DTX状態が除外された後、最も早いアップリンク時間単位で搬送されるHARQ状態が有効なHARQ状態として選択され、その結果、有効なHARQ状態はより正確である。
【００１５】
可能な設計では、少なくとも2つのHARQ状態が不連続伝送DTX状態および非DTX状態を含むとき、有効なHARQ状態は非DTX状態であり、非DTX状態は第2のデバイスによって送信され、第1のデバイスによって検出されるHARQ状態である。本出願のこの実施形態で提供される方法によれば、DTX状態が除外された後、非DTX状態が有効なHARQ状態として選択され、その結果、有効なHARQ状態はより正確である。
【００１６】
可能な設計では、少なくとも2つのHARQ状態は少なくとも2つのダウンリンク時間単位で搬送され、有効なHARQ状態は少なくとも2つのダウンリンク時間単位のうちの最も早いダウンリンク時間単位で搬送されるHARQ状態である。したがって、本出願のこの実施形態で提供される方法によれば、有効なHARQ状態を容易に決定することができる。
【００１７】
可能な設計では、少なくとも2つのHARQ状態の各々が第2のデバイスによって送信されるHARQフィードバック情報内で搬送されるとき、有効なHARQ状態は、少なくとも2つのダウンリンク時間単位のうちの最も早いダウンリンク時間単位で搬送されるHARQ状態である。本出願のこの実施形態で提供される方法によれば、スケジューリング情報内で搬送されるHARQ状態が除外された後、HARQフィードバック情報内で搬送されるHARQ状態のうちの最も早いダウンリンク時間単位で搬送されるHARQ状態が有効なHARQ状態として選択され、その結果、有効なHARQ状態はより正確である。
【００１８】
可能な設計では、少なくとも2つのHARQ状態がそれぞれ第2のデバイスによって送信されるHARQフィードバック情報および第2のデバイスによって送信されるスケジューリング情報内で搬送され、HARQフィードバック情報内で搬送されるHARQ状態がスケジューリング情報内で搬送されるHARQ状態と異なるとき、有効なHARQ状態はHARQフィードバック情報内で搬送されるHARQ状態である。本出願のこの実施形態で提供される方法によれば、HARQフィードバック情報内で搬送されるHARQ状態がスケジューリング情報内で搬送されるHARQ状態と異なるとき、スケジューリング情報内で搬送されるHARQ状態が除外された後、HARQフィードバック情報内で搬送されるHARQ状態が有効なHARQ状態として選択され、その結果、有効なHARQ状態はより正確である。
【００１９】
可能な設計では、少なくとも2つのHARQ状態は肯定応答ACK状態を含み、有効なHARQ状態はACK状態である。したがって、本出願のこの実施形態で提供される方法によれば、ACK状態が有効なHARQ状態として選択され、その結果、有効なHARQ状態はより正確である。
【００２０】
可能な設計では、少なくとも2つのHARQ状態の各々は、基準時間単位の後に第1のデバイスによって取得される。
【００２１】
可能な設計では、少なくとも2つのHARQ状態を搬送する少なくとも1つの時間単位のうちのいずれか1つと基準時間単位との間の時間間隔は、第1のプリセット時間間隔以上である。
【００２２】
可能な設計では、任意の時間単位は基準時間単位の後である。
【００２３】
可能な設計では、少なくとも2つのHARQ状態が少なくとも2つの時間単位で搬送されるとき、有効なHARQ状態は、少なくとも2つの時間単位のうちの少なくとも1つの最も早い時間単位で搬送されるHARQ状態であり、少なくとも1つの最も早い時間単位は同じHARQ状態を搬送する。
【００２４】
可能な設計では、少なくとも2つのHARQ状態がデフォルト状態および非デフォルト状態を含むとき、有効なHARQ状態は非デフォルト状態である。
【００２５】
可能な設計では、少なくとも2つのHARQ状態が少なくとも2つの時間単位で搬送されるとき、第1のデバイスは、有効なHARQ状態が少なくとも2つの時間単位のうちの最も早いアップリンク時間単位で搬送される非DTX状態であると決定し、非DTX状態は、第2のデバイスによって送信され、第1のデバイスによって検出されるHARQ状態である。
【００２６】
第2の態様によれば、本出願の一実施形態は、第1の態様または第1の態様の任意の可能な設計における方法を実行するよう構成された、コンテンションウィンドウサイズを調整するための装置を提供する。具体的には、装置は、第1の態様または第1の態様の任意の可能な設計における方法を実行するよう構成されたモジュールを含む。
【００２７】
第3の態様によれば、本出願の一実施形態は、トランシーバおよびプロセッサを含む、コンテンションウィンドウサイズを調整するためのデバイスを提供する。プロセッサは、第1の態様または第1の態様の任意の可能な設計における方法を実行するよう構成される。
【００２８】
第4の態様によれば、本出願の一実施形態は、第5の態様の第1のデバイスおよび第2のデバイスを含む通信システムを提供する。
【００２９】
第5の態様によれば、本出願はコンピュータ可読記憶媒体を提供する。コンピュータ可読記憶媒体は命令を記憶し、命令がコンピュータ上で実行されると、コンピュータは第1の態様または第1の態様の任意の可能な設計における方法を実行することが可能になる。
【００３０】
第6の態様によれば、本出願は命令を含むコンピュータプログラム製品をさらに提供する。コンピュータプログラム製品がコンピュータ上で実行されると、コンピュータは第1の態様または第1の態様の任意の可能な設計における方法を実行することが可能になる。
【図面の簡単な説明】
【００３１】
【図１】本出願の一実施形態による、LTEシステムにおけるアップリンク伝送の概略図である。
【図２】本出願の一実施形態による、HARQフィードバック情報がG−DCIであるとき、端末デバイスにより、ネットワークデバイスによって送信されたG−DCIを受信する概略図である。
【図３】本出願の一実施形態による、コンテンションウィンドウサイズを調整するための方法の概要フローチャートである。
【図４（ａ）】本出願の一実施形態による、ダウンリンクデータ伝送に対応するDTX状態の第1の概略図である。
【図４（ｂ）】本出願の一実施形態による、ダウンリンクデータ伝送に対応するDTX状態の第2の概略図である。
【図５】本出願の一実施形態による、ダウンリンクデータ伝送に対応する非DTX状態の概略図である。
【図６】本出願の一実施形態による、ダウンリンクデータ伝送において同じバースト内で同じHARQ状態を繰り返し送信する概略図である。
【図７（ａ）】本出願の一実施形態による、ダウンリンクデータ伝送に対応するDTX状態の第3の概略図である。
【図７（ｂ）】本出願の一実施形態による、ダウンリンクデータ伝送に対応するDTX状態の第4の概略図である。
【図８】本出願の一実施形態による、アップリンクデータ伝送において同じバースト内で同じHARQ状態を繰り返し送信する概略図である。
【図９】本出願の一実施形態による、アップリンクデータ伝送に対応する有効なHARQ状態の概略図である。
【図１０】本出願の一実施形態による、UL grantに対応するHARQがG−DCIに対応するHARQと矛盾する概略図である。
【図１１】本出願の一実施形態による、コンテンションウィンドウサイズを調整するためのデバイスの概略構造図である。
【図１２】本出願の一実施形態による、コンテンションウィンドウサイズを調整するための装置の概略構造図である。
【発明を実施するための形態】
【００３２】
以下で、添付図面を参照して本出願の実施形態を記載する。
【００３３】
ロングタームエボリューション（Long Term Evolution、LTE）システムは、直交周波数分割多重（Orthogonal Frequency Division Multiplexing、OFDM）技術を使用し、データ伝送に使用される最小リソース単位はリソースエレメント（Resource Element、RE）である。リソースエレメントは、時間領域内の1つのOFDMシンボルおよび周波数領域内の1つのサブキャリアに対応する。これに基づいて、リソースブロック（Resource Block、RB）は、時間領域内の複数の連続するOFDMシンボルおよび周波数領域内の複数の連続するサブキャリアを含み、リソーススケジューリングの基本単位である。LTEアップリンク伝送中、シングルキャリアが使用される。1つのREは、1つのシングルキャリア周波数分割多元接続（Single Carrier Frequency Division Multiplexing Access、SC−FDMA）シンボルおよび周波数領域内の1つのサブキャリアに対応し、LTEシステムにおけるアップリンクリソース割当ては、伝送時間間隔（Transmission Time Interval、TTI）の粒度で行われ、1つのTTIの長さは14個のOFDMシンボル、すなわち、1msの長さを有する1つのサブフレームである。
【００３４】
図1を参照すると、LTEシステムにおけるアップリンク伝送は、ネットワークデバイスによってスケジュールされ、具体的には、ネットワークデバイスは、ダウンリンク制御チャネルに含まれるアップリンクグラント（UL grant）を使用することにより、対応するアップリンクサブフレーム内でアップリンク共有チャネル（Physical Uplink Shared Channel、PUSCH）を送信するよう、端末デバイスまたはユーザー機器（User Equipment、UE）に指示する。具体的には、端末デバイスがアップリンクデータを送信する必要がある場合、端末デバイスはまず、アップリンク制御チャネル（Physical Uplink Control Channel、PUCCH）上でネットワークデバイスにスケジューリング要求（Scheduling Request、SR）を送信して、ネットワークデバイスがSRを受信した後に端末デバイスにPUSCHをスケジュールするためのUL grantを送信するのを待つ必要があり、次いで、UL grantを使用することにより、スケジュールされたアップリンクリソース上でアップリンクデータを送信する。
【００３５】
端末デバイスは、SRを送信し、PUSCHを送信する前にネットワークデバイスのUL grantスケジューリングを待つ必要があるので、UL grantスケジューリングに基づく従来のアップリンク伝送中、比較的大きな遅延があり、チャネルは、LBTが複数回実行されるので、先取りすることができない可能性がある。遅延を減らし、アップリンクリソースをより効率的に使用するために、自律アップリンク（Autonomous UL、AUL）伝送とも呼ばれるグラント・フリー・アップリンク（Grant free UpLink、GUL）伝送が行われてもよい。ネットワークデバイスは、1つまたは少なくとも2つの端末デバイスにGULリソースを準静的に構成するかまたは示し、GUL伝送をアクティブ化する。端末デバイスがアップリンクサービス要件を有する場合、端末デバイスはSRを送信する必要はないが、SRを送信し、UL grantを待つことによって引き起こされる遅延を減らすために、GULリソース上でアップリンクデータを直接送信することができる。
【００３６】
GULベースのシステムの場合、ネットワークデバイスがGUL PUSCHの受信状態をフィードバックすることを支援するために、アップリンクデータチャネルのためのアップリンクHARQ−ACKフィードバックが導入され、HARQフィードバック情報内で搬送される。具体的には、HARQフィードバック情報はG−DCIであってよい。HARQフィードバック情報内でHARQ状態をフィードバックする方式の場合、HARQフィードバック情報は、少なくとも1つのHARQプロセスを使用して端末デバイスによって行われた以前の送信が正しく受信されたかどうかを示すために使用される指示情報を含むが、HARQプロセスを使用して初期伝送または再伝送を行うよう端末デバイスをスケジュールするためにネットワークデバイスによって使用されるスケジューリング情報を含まない。
【００３７】
限定ではなく例として、HARQフィードバック情報は、GUL PUSCHに加えて、他のアップリンクデータチャネルのHARQ状態をフィードバックするために使用されてもよい。
【００３８】
具体的には、HARQフィードバック情報内で、HARQプロセスセット内の各HARQプロセスの受信状態は、ビットマッピングによって示される。たとえば、ACKはバイナリの「1」によって表され、NACKはバイナリの「0」によって表される。HARQプロセスセットが、HARQ ID｛＃0、＃1、＃2、＃3｝に対応するHARQプロセスを含むとき、＃0および＃1が正しい受信を示し、＃2および＃3が正しくない受信を示す場合、HARQフィードバック情報に含まれるbit mapは｛1、1、0、0｝である。ビットマッピングに基づくHARQフィードバック情報内で、HARQフィードバック情報に含まれる各HARQプロセス識別子は、デフォルト状態、たとえば、NACK状態を有する。ネットワークデバイスがHARQフィードバック情報を送信するとき、ネットワークデバイスが特定のHARQプロセスのHARQ状態をフィードバックする必要がない（たとえば、端末デバイスがHARQプロセスを使用してデータパケットを送信することをネットワークデバイスが検出しない）場合、それは、HARQプロセスが（NACKによって表されてよい）デフォルト状態にあることを示す。あるいは、HARQフィードバック情報を使用することにより、特定の検出されたデータチャネルに対応するHARQプロセスのHARQ状態をフィードバックした後、ネットワークデバイスは、HARQプロセスに対応するHARQ状態をデフォルト状態にリセットしてもよい。図2に示されるように、HARQフィードバック情報はG−DCIであり、HARQプロセスセットは＃H0、＃H1、＃H2、および＃H3を含む。端末デバイスは、＃H0〜＃H3を使用して、それぞれサブフレーム＃n〜＃n＋3内でアップリンクデータ情報を送信する。ネットワークデバイスは、＃n＋5のG−DCI内で＃H0および＃H1のHARQ状態［H0：NACK、H1：ACK、H2：NACK、H3：NACK］をフィードバックし、＃H2および＃H3のHARQ状態はデフォルト状態である。ネットワークデバイスは、＃n＋7のG−DCI内で＃H2および＃H3のHARQ状態［NACK、NACK、ACK、ACK」をフィードバックし、＃H1のHARQ状態は＃n＋7のG−DCI内でデフォルト状態NACKにリセットされる。
【００３９】
端末デバイスがHARQフィードバック情報に基づいてアップリンクCWSを調整するとき、デフォルト状態がリセットされることによりHARQフィードバック情報の2つの連続する部分に一貫性がないならば、端末デバイスがHARQフィードバック情報に基づいてどのようにCWSを調整するかは、本出願の実施形態において緊急に解決される必要がある課題である。
【００４０】
アップリンクCWS調整と同様に、端末デバイスによってフィードバックされるダウンリンクHARQ情報がビットマッピングに基づくとき、ダウンリンクHARQ情報もビットマッピングに基づくので、ダウンリンクHARQ情報に含まれる各HARQプロセス識別子はNACK状態などのデフォルト状態をもち、ネットワークデバイスによって受信された少なくとも2つのダウンリンクHARQ情報は、デフォルト状態がリセットされているので一貫性がない。この場合、ネットワークデバイスがダウンリンクHARQ情報に基づいてどのようにCWSを調整するかは、本出願の実施形態において緊急に解決される必要がある問題である。
【００４１】
本出願の実施形態で使用される主なネットワーク要素には、免許スペクトル上で動作することができるネットワークデバイスおよび端末デバイスが含まれる。ネットワークデバイスには、マクロ基地局、マイクロセル、ピコセル、ホーム基地局、リモート無線ヘッド、リレーなどが含まれる。端末デバイスには、携帯電話、LTEシステムにアクセスすることができるラップトップコンピュータ、タブレットコンピュータなどが含まれる。
【００４２】
本出願の実施形態は、免許不要スペクトル上で動作することができるワイヤレス通信システムに適用可能であり、限定はしないが、Multefire 1．0、Multefire 1．1、Multefire 2．0、FeLAA、および5G NRなどのシステムを含む。ワイヤレス通信システム内のネットワークデバイスおよび端末デバイスのうちの少なくとも1つは、免許不要スペクトル上で情報を送信する。たとえば、ネットワークデバイスは免許不要スペクトル上でダウンリンク情報を送信し、それに対応して、端末デバイスは免許スペクトルまたは免許不要スペクトル上でアップリンク情報を送信する。あるいは、端末デバイスは免許不要スペクトル上でアップリンク情報を送信し、それに対応して、ネットワークデバイスは免許スペクトルまたは免許不要スペクトル上でダウンリンク情報を送信する。
【００４３】
図3を参照すると、本出願の一実施形態は、コンテンションウィンドウサイズを調整するための方法を提供する。方法は以下のステップを含む。
【００４４】
ステップ300：第1のデバイスは、第1のHARQプロセス識別子に対応する少なくとも2つのHARQ状態を取得し、少なくとも2つのHARQ状態は相違し、第1のHARQプロセス識別子は、第1のデバイスが基準時間単位で第2のデバイスにデータを送信するときに使用されるHARQプロセス識別子である。
【００４５】
ステップ310：第1のデバイスは、少なくとも2つのHARQ状態のうちの有効なHARQ状態を決定する。
【００４６】
ステップ320：第1のデバイスは、有効なHARQ状態に基づいて第1のバーストのためのコンテンションウィンドウサイズを調整し、第1のバーストは基準時間単位よりも遅い。
【００４７】
本出願のこの実施形態では、第1のデバイスが免許不要スペクトル上でのLBTの実行に成功した後、第1のデバイスはチャネルを連続的に占有することができ、言い換えれば、第1のデバイスは連続する時間単位でデータを伝送することができることを理解されたい。第1のデバイスがLBTの実行に成功した後にチャネルを占有することにより第1のデバイスによって送信されるデータ伝送はバーストと呼ばれる。具体的には、第1のバーストは少なくとも1つの時間単位を含み、少なくとも1つの時間単位は連続していてもよく、不連続であってもよい。ダウンリンク伝送の場合、少なくとも1つの時間単位はダウンリンクバースト（DL Burst）と呼ばれる場合があり、アップリンク伝送の場合、少なくとも1つの時間単位はアップリンクバースト（UL Burst）と呼ばれる場合がある。少なくとも1つの時間単位が連続していてもよいということは、時間単位（たとえば、TTIまたはサブフレーム）のシーケンス番号が連続していることを意味する。加えて、第1のバーストに含まれる任意の2つの隣接する時間単位の間に、ギャップはあってもよく、なくてもよい。具体的には、第1のデバイスは、前の時間単位の最後または後の時間単位の最初において時間領域リソースを占有しないが、時間領域リソースを「アイドル」として確保する。このことは、本出願のこの実施形態では限定されない。
【００４８】
可能な設計では、第1のバーストはダウンリンクバーストであってよく、ダウンリンクバーストは、免許不要周波数帯域リソースを先取りした後にネットワークデバイス（たとえば、基地局）またはネットワークデバイスによってサービスされるセル（Cell）によって占有される少なくとも1つの時間単位であってよい。具体的には、ダウンリンクバーストは少なくとも1つの連続するダウンリンク時間単位を含み、1つのダウンリンクバーストおよび任意の他のダウンリンクバーストまたは任意の他のアップリンクバーストは不連続である。
【００４９】
可能な設計では、第1のバーストはアップリンクバーストであってよく、アップリンクバーストは、免許不要周波数帯域リソースを先取りした後に端末デバイスによって占有される少なくとも1つの時間単位であってよい。具体的には、アップリンクバーストは少なくとも1つの連続するアップリンク時間単位を含み、1つのアップリンクバーストおよびネットワークデバイスによって送信される任意の他のダウンリンクバーストまたは端末デバイスによって送信される任意の他のアップリンクバーストは不連続である。
【００５０】
第1のデバイスは、コンテンションウィンドウサイズ（CWS）に基づいてLBTを行い、LBTの完了後に第1のバーストを送信するためにチャネルを占有することを理解されたい。この場合、CWSは第1のバーストのためのCWSと呼ばれる。
【００５１】
ステップ300では、少なくとも2つのHARQ状態の各々は、基準時間単位の後に第1のデバイスによって取得され、言い換えれば、少なくとも2つのHARQ状態を搬送する時間単位の各々は、基準時間単位の後にある。加えて、少なくとも2つのHARQ状態を搬送する時間単位の各々は、第1のデバイスがCWSを決定する時点の前である。第1のデバイスは、基準時間単位の前の他の時間単位で第1のHARQプロセス識別子を使用してアップリンク情報を送信しており、他の時間単位のHARQ状態を取得しているので、他の時間単位のHARQ状態は、明らかに少なくとも2つの異なるHARQ状態に含まれるべきではない。
【００５２】
加えて、基準時間単位は、第1のデバイスがCWSを決定する前に、第1のデバイスが第1のHARQプロセス識別子を使用して第2のデバイスにデータ情報を送信するときに占有される最新の時間単位であることをさらに理解されたい。あるいは、第1のデバイスは、第1のHARQプロセス識別子を使用することにより、基準時間単位と第1のバーストとの間でデータを送信しない。
【００５３】
本出願のこの実施形態では、基準時間単位は少なくとも1つの連続するTTIを含み、言い換えれば、基準時間単位は1つのTTIであってもよく、複数の連続するTTIであってもよいことに留意されたい。基準時間単位に含まれる各TTIは、完全なTTI（具体的には、第1のデバイスは情報を送信するためにTTIに対応するすべての時間領域リソースを占有する）であっても、部分的なTTIであってもよい。たとえば、部分的なTTIの場合、第1のデバイスは、完全なTTIの他の時間領域リソースではなく、一部の時間領域リソースのみを占有する。他の例では、完全なTTIと比較して、第1のデバイスはTTIの最初において時間領域リソースを「アイドル」として確保する（言い換えれば、第1のデバイスはTTIの最初において時間領域リソースを占有しない）、またはTTIの最後において時間領域リソースを「アイドル」として確保する。他の例では、1つのダウンリンク基準時間単位は、ダウンリンクバーストの最初の2つのTTIを含んでよい。最初のTTIは部分的なTTIであり、ネットワークデバイスは最初のTTIの中間の時間領域リソースから最初のTTIの最後の時間領域リソースまで占有する。2番目のTTIは完全なTTIである。
【００５４】
TTIは、1msの長さを有するサブフレームとも呼ばれる1msのTTIであってもよく、ミニスロット（mini−slot）と呼ばれる1msより短いsTTIであってもよいことを理解されたい。sTTIによって占有される時間領域リソースの長さは1msのTTIの長さよりも短く、言い換えれば、特定のデータチャネルに対応するTTIがsTTIであるとき、TTIによって占有される時間領域リソースの長さは1msよりも短い。アップリンク伝送の場合、TTIはアップリンクリソース割当てまたはアップリンク伝送のための時間領域の粒度であるか、またはTTIはアップリンク伝送を実行するために端末デバイスによって使用される最小時間領域単位である。サポートされ得るsTTIのオプションの長さには、7つのSC−FDMAシンボル（SC−FDMA Symbol、SS）、1つのSS、2つのSS、3つのSS、4つのSSなどが含まれる。ダウンリンク伝送の場合、TTIはダウンリンクリソース割当てまたはダウンリンク伝送のための時間領域の粒度であるか、またはTTIはダウンリンク伝送を行うためにネットワークデバイスによって使用される最小時間領域単位である。サポートされ得るsTTIのオプションの長さには、7つのOFDMAシンボル（OFDMA Symbol、OS）、1つのOS、2つのOS、3つのOS、4つのOSなどが含まれる。sTTIの1msよりも短い他のTTI長がさらにサポートされる。
【００５５】
第1のデバイスが基準時間単位を決定し、第1のHARQプロセス識別子について取得されたHARQ状態に基づいて、第1のバーストのためのCWSを調整することを理解されたい。第1のHARQプロセス識別子は、第1のデバイスが基準時間単位でデータ情報を送信するときに使用されるHARQプロセス識別子である。
【００５６】
可能な設計では、基準時間単位は、第1のバーストの前にあり、第1のバーストと同じタイプを有するバースト内の時間単位である。
【００５７】
第1のデバイスは基準時間単位を使用してデータ情報を送信することができ、第1のデバイスは第1のバーストを使用してデータ情報、制御情報、または基準信号のうちの少なくとも1つを送信することができることを理解されたい。同じタイプのバーストは、アップリンクとダウンリンクの伝送方向が同じであることを意味することを理解されたい。たとえば、第1のバーストがアップリンクバーストであるとき、基準時間単位は、そのアップリンクバーストの前のアップリンクバースト内の時間単位である。第1のバーストがダウンリンクバーストであるとき、基準時間単位は、そのダウンリンクバーストの前のダウンリンクバースト内の時間単位である。
【００５８】
可能な設計では、第1のデバイスがネットワークデバイスであり、第2のデバイスが端末デバイスであるとき、基準時間単位はダウンリンク基準時間単位である。ネットワークデバイスによって決定されるダウンリンク基準時間単位は、第1のバーストの前の（第2のダウンリンクバーストと呼ばれる）最新のダウンリンクバースト内のダウンリンク時間単位であり、ネットワークデバイスは、少なくともダウンリンク基準時間単位の間に端末デバイスによってフィードバックされるHARQ状態を受信することを予想する（言い換えれば、HARQフィードバック時間シーケンスにおいて、端末デバイスは基準時間単位でデータ情報を復調し、HARQ状態をフィードバックすることができ、これは以下に記載される）。具体的には、ダウンリンク基準時間単位は、第2のダウンリンクバースト内の第1のダウンリンク時間単位である。
【００５９】
可能な設計では、第1のデバイスがネットワークデバイスであり、第2のデバイスが端末デバイスであるとき、基準時間単位はアップリンク基準時間単位である。この場合、基準時間単位は、アップリンクデータパケットに対応するHARQ状態を示すために使用される受信されたダウンリンク制御情報に基づいて、端末デバイスによって決定される。具体的には、ダウンリンク制御情報は時間的に第1のバーストの前にある。
【００６０】
加えて、基準時間単位は、端末デバイスがダウンリンク制御情報を受信する時間単位（たとえば、ダウンリンク制御情報を搬送するダウンリンク時間単位）の前の（第2のアップリンクバーストと呼ばれる）アップリンクバースト内のアップリンク時間単位であることを理解されたい。より具体的には、基準時間単位は、第2のアップリンクバースト内の第1のアップリンク時間単位である。加えて、第2のアップリンクバーストは、端末デバイスがランダムバックオフベースのCCAを介してチャネルにアクセスするときに送信されるアップリンクバーストである。その上、端末デバイスは基準時間単位でアップリンクデータ情報UL−SCHを送信し、言い換えれば、ネットワークデバイスによってスケジュールされるが、端末デバイスがLBTの障害のためチャネルにアクセスしないので、端末デバイスによって送信されないアップリンク時間単位は、基準時間単位として使用することができない。
【００６１】
加えて、第2のアップリンクバーストはターゲット時間単位の前の最新のアップリンクバーストであり、ターゲット時間単位とダウンリンク制御情報を搬送するダウンリンク時間単位との間の時間間隔は、第1の予め定義された時間間隔であることを理解されたい。たとえば、ダウンリンク制御情報がUL grantであり、UL grantが受信されるダウンリンク時間単位がサブフレーム＃nであり、第1の予め定義された時間間隔が3msである場合、第2のアップリンクバーストはサブフレーム＃n−3の前の最新のアップリンクバーストである。
【００６２】
加えて、ダウンリンク制御情報には、スケジューリング情報およびHARQフィードバック情報の2つのタイプが含まれることを理解されたい。具体的には、スケジューリング情報はUL grantを含む。具体的には、HARQフィードバック情報は、ビットマッピングに基づくアップリンクHARQフィードバック情報、たとえば、G−DCIを含む。受信されたダウンリンク制御情報に基づいて基準時間単位を決定するとき、端末デバイスは、受信されたスケジューリング情報に基づいて基準時間単位を決定してもよく、受信されたフィードバック情報に基づいて基準時間単位を決定してもよい。
【００６３】
可能な設計では、少なくとも2つのHARQ状態を搬送する少なくとも1つの時間単位のうちのいずれか1つと基準時間単位との間の時間間隔は、第1のプリセット時間間隔以上である。具体的には、任意の時間単位は、基準時間単位の後、かつ第1のバーストの前にある。ネットワークデバイスまたは端末デバイスによるデータパケットの復号の遅延、およびネットワークデバイスまたは端末デバイスによるHARQ情報のパッケージングの遅延を考慮すると、基準時間単位の間に第2のデバイスによってフィードバックされるHARQ状態は、ある時間期間の後に送信することができる。具体的には、HARQ状態を搬送する時間単位と基準時間単位との間の最短時間間隔は、第1のプリセット時間間隔である。より具体的には、第1のプリセット時間間隔はk個の時間単位であり、k＞0であり、kは整数である。たとえば、ダウンリンク伝送の場合、基準時間単位がサブフレーム＃nであるとき、端末デバイスは、最も早い時間にサブフレーム＃n＋k内で基準時間単位の間のHARQ状態をフィードバックすることができる。アップリンク伝送の場合、基準時間単位がサブフレーム＃nである場合、ネットワークデバイスは、最も早い時間にサブフレーム＃n＋k内で基準時間単位の間のHARQ状態をフィードバックすることができる。サブフレーム＃n＋kより早いサブフレーム内でフィードバックされたHARQ状態は、確かに基準時間単位の間のHARQ状態フィードバックではなく、したがって、少なくとも2つのHARQ状態に含まれない。したがって、本発明における少なくとも2つのHARQ状態の各々は、第2のデバイスが基準時間単位でデータ情報を復調することができ、HARQフィードバック時間シーケンス、言い換えれば、少なくとも2つのHARQ状態を搬送する任意の時間単位と基準時間単位との間の時間間隔でフィードバックされるHARQ状態であり、基準時間単位は第1のプリセット時間間隔以上である。
【００６４】
たとえば、第1のプリセット時間間隔がk個のサブフレームであり、k＞0であると仮定する。基準時間単位がサブフレーム＃nであるとき、第1のデバイスは、最も早い時間にサブフレーム＃n＋k内の第1のHARQプロセス識別子に対応するHARQ状態を取得することができ、サブフレーム＃n＋kより早いサブフレーム内で搬送されたHARQ状態は、基準時間単位の間のHARQフィードバックではない。したがって、少なくとも2つのHARQ状態の各々は、サブフレーム＃n＋kの後のサブフレーム内で搬送され、第1のHARQプロセス識別子に対応するHARQ状態である。
【００６５】
第1のデバイスは、少なくとも2つのHARQ状態を受信した後に基準時間単位を決定してもよく、少なくとも2つのHARQ状態を受信する前に基準時間単位を決定してもよいことを理解されたい。たとえば、アップリンクデータ伝送の場合、ダウンリンク制御情報を受信した後、端末デバイスはダウンリンク制御情報に基づいて基準時間単位を決定する。たとえば、ダウンリンクデータ伝送の場合、端末がHARQ情報を送信する時点はネットワークデバイスによって示され、ネットワークデバイスはHARQ情報が受信される時点を予想することができる。したがって、ネットワークデバイスがダウンリンク基準時間単位を決定する時点は、少なくとも2つのHARQ状態が受信される時点の前であってもよく、少なくとも2つのHARQ状態が受信される時点の後であってもよい。このことは限定されない。HARQ状態は、受信状態またはHARQ受信状態とも呼ばれることを理解されたい。
【００６６】
少なくとも2つのHARQ状態の任意のHARQ状態（すなわち、HARQ状態）は、具体的には、第1のHARQプロセス識別子に対応するHARQ状態の値、たとえば、ACK、NACK、またはDTXであることを理解されたい。したがって、HARQ状態は、具体的に特定の時間単位に対応していない。HARQ状態は、少なくとも1つの時間単位で搬送され、言い換えれば、少なくとも1つの時間単位の各々で搬送されるHARQ情報はHARQ状態に対応する。任意選択で、HARQ状態は1つの時間単位で搬送されてよい。たとえば、第2のデバイスが第1のHARQプロセス識別子に対応するHARQ情報を1つの時間単位のみでフィードバックする場合、HARQ情報に対応するHARQ状態はHARQ状態である。任意選択で、HARQ状態は少なくとも2つの時間単位で搬送されてよく、言い換えれば、少なくとも2つの時間単位の各々で搬送されるHARQ情報はHARQ状態に対応する。たとえば、第2のデバイスが第1のHARQプロセス識別子に対応する2つのHARQ情報を2つの時間単位で、フィードバックし、2つのHARQ情報に対応する両方のHARQ状態がNACKである場合、HARQ状態はNACKであり、HARQ状態は2つの時間単位で搬送される。
【００６７】
HARQ状態が少なくとも1つの時間単位で搬送されるとき、HARQ状態は、少なくとも1つの時間単位のいずれか1つで搬送されるHARQ情報に対応するHARQ状態とも呼ばれることを理解されたい。具体的には、HARQ状態が1つの時間単位で搬送され得るとき、HARQ状態は、時間単位のHARQ情報に対応するHARQ状態である。HARQ状態が少なくとも2つの時間単位で搬送されるとき、HARQ状態は、少なくとも2つの時間単位のいずれか1つのHARQ情報に対応するHARQ状態である。
【００６８】
少なくとも2つのHARQ状態が少なくとも2つの時間単位で搬送されるとき、少なくとも2つの時間単位の数は少なくとも2つのHARQ状態の数以上であることを理解されたい。たとえば、3つの時間単位で第1のデバイスによって受信された3つのHARQ情報は、それぞれ（時系列的に）ACK、NACK、およびNACKに対応し、少なくとも2つのHARQ状態は、ACKおよびNACKの2つの状態を含み、3つの時間単位で搬送される。この場合、最も早い時間単位で搬送されるHARQ状態はACKである。他の例では、3つの時間単位で第1のデバイスによって受信された3つのHARQ情報は、それぞれ（時系列的に）ACK、ACK、およびNACKに対応し、少なくとも2つのHARQ状態は、ACKおよびNACKの2つの状態を含み、3つの時間単位で搬送される。この場合、最も早い時間単位で搬送されるHARQ状態はACKである。
【００６９】
少なくとも2つの時間単位の各々は、アップリンク時間単位またはダウンリンク時間単位であってよいことを理解されたい。上記の特徴は、少なくとも2つのHARQ状態が少なくとも2つのアップリンク時間単位で搬送される以下のシナリオ、および少なくとも2つのHARQ状態が少なくとも2つのダウンリンク時間単位で搬送される以下のシナリオにも適用可能である。
【００７０】
少なくとも2つのHARQ状態が異なることは、少なくとも2つのHARQ状態のいずれか1つが少なくとも2つのHARQ状態の他のいずれとも異なることを意味することを理解されたい。たとえば、少なくとも2つのHARQ状態は、ACKおよびNACKの2つの異なるHARQ状態である。他の例では、少なくとも2つのHARQ状態は、ACK、NACK、およびDTXの3つの異なるHARQ状態である。
【００７１】
少なくとも2つのHARQ状態の各々は、免許不要スペクトル上で搬送されてよく、または少なくとも2つのHARQ状態のうちのいくつかが免許不要スペククトル上で搬送され、他のHARQ状態が免許スペクトル上で搬送されてもよく、または少なくとも2つのHARQ状態の各々が免許スペクトル上で搬送されてもよい。
【００７２】
特定のHARQプロセス識別子が少なくとも2つのトランスポートブロックに対応するとき、言い換えれば、第1のデバイスが複数のコードワード（Codeword）を使用して伝送を行うとき、第2のデバイスは、HARQプロセス識別子について2つのHARQ情報をフィードバックすることができ、各HARQ情報は、1つのコードワードまたはその1つのトランスポートブロックに対応することに留意されたい。少なくとも2つのトランスポートブロックのHARQ状態が異なるとき、たとえば、あるトランスポートブロックに対応するHARQ状態がACKであり、他のトランスポートブロックに対応するHARQ状態がNACKであるとき、HARQプロセス識別子は少なくとも2つの異なるHARQ状態にも対応する。本出願のこの実施形態で言及される少なくとも2つのHARQ状態は、同じHARQプロセス識別子についての少なくとも2つの異なるコードワードまたはトランスポートブロックの異なるHARQ状態を含まないことを理解されたい。
【００７３】
任意選択で、第1のHARQプロセス識別子は1つのトランスポートブロックに対応するか、または第1のHARQプロセス識別子は、（単一のトランスポートブロックとも呼ばれる）単一のコードワードに基づくデータ伝送に対応する。
【００７４】
第1のデバイスが単一のコードワードを使用して伝送を行うとき、各HARQプロセス識別子はただ1つのトランスポートブロックに対応する。したがって、少なくとも2つのHARQ状態は異なる時間単位または異なる制御情報で搬送されるので、少なくとも2つのHARQ状態は相違し、有効なHARQ状態は少なくとも2つのHARQ状態のうち決定されてよい。
【００７５】
任意選択で、少なくとも2つのHARQ状態のうちの任意のHARQ状態は同じトランスポートブロックに対応し、そのトランスポートブロックは第1のHARQプロセス識別子に対応する。
【００７６】
第1のデバイスが複数のコードワードを使用して伝送を行うとき、少なくとも2つのHARQ状態は、同じトランスポートブロックに対応するよう限定される。したがって、少なくとも2つのHARQ状態は異なる時間単位または異なる制御情報で搬送されるので、少なくとも2つのHARQ状態は異なる。少なくとも2つのHARQ状態が第1のHARQプロセス識別子における同じトランスポートブロックに対応することは、少なくとも2つのHARQ状態の各々がHARQ情報内の同じトランスポートブロックに対応するフィールド内で搬送されることを意味することを理解されたい。たとえば、第1のデバイスは、第1のHARQプロセス識別子を使用してTB＃1およびTB＃2の2つのトランスポートブロックを送信し、第1のHARQプロセス識別子についての2つのHARQ情報を連続的に取得する。この場合、対応する状態は｛TB＃1：ACK、TB＃2：NACK｝および｛TB＃1：NACK、TB＃2：NACK｝である。したがって、少なくとも2つの異なるHARQ状態の各々は、TB＃1に対応するHARQ状態である。
【００７７】
ステップ310では、第1のデバイスがネットワークデバイスであり、第2のデバイスが端末デバイスであり、第1のHARQプロセス識別子が第2のデバイスのためのHARQプロセス識別子である特定のシナリオ、および第1のデバイスが端末デバイスであり、第2のデバイスがネットワークデバイスであり、第1のHARQプロセス識別子が第1のデバイスに対応するHARQプロセス識別子である特定のシナリオについて、以下で少なくとも2つのHARQ状態のうちの有効なHARQ状態を決定する方法を個別に記載する。
【００７８】
シナリオ1：第1のデバイスはネットワークデバイスであり、第2のデバイスは端末デバイスであり、第1のHARQプロセス識別子は第2のデバイスのためのHARQプロセス識別子である。
【００７９】
任意選択で、第1のHARQプロセス識別子に対応する少なくとも2つのHARQ状態のいずれか1つは、肯定応答ACKおよび否定応答NACKを含む。
【００８０】
たとえば、特定のデータパケット（またはデータパケットに対応するダウンリンクHARQプロセス）が正しく受信されたと端末デバイスが決定すると、端末デバイスは、ダウンリンクHARQプロセス識別子に対応するHARQ状態がACKであることをネットワークデバイスにフィードバックする。データパケットが正しく受信されなかったと端末デバイスが決定すると、端末デバイスは、ダウンリンクHARQプロセス識別子に対応するHARQ状態がNACKであることをネットワークデバイスにフィードバックする。あるいは、ダウンリンクデータパケットが位置するダウンリンクデータチャネルを端末デバイスが検出しないとき、端末デバイスは、ダウンリンクHARQプロセス識別子に対応するHARQ状態がNACKであることをネットワークデバイスにフィードバックし、言い換えれば、NACKは、ダウンリンクデータチャネルまたはダウンリンクデータチャネルに対応するダウンリンクHARQプロセスが検出されないことを示すために使用される。
【００８１】
任意選択で、第1のHARQプロセス識別子に対応する少なくとも2つのHARQ状態のいずれか1つは、ACK状態、NACK状態、または不連続伝送（Discontinuous Transmission、DTX）状態を含む。
【００８２】
端末デバイスがHARQ情報をフィードバックする時間単位はネットワークデバイスによって示され、端末デバイスはネットワークデバイスによって示された時間単位でチャネルを占有することにより、HARQ情報を送信してもよく、送信しなくてもよいことを理解されたい。ネットワークデバイスが、端末デバイスがHARQ情報を送信すると予想される時間単位で、端末デバイスによって送信されたHARQ情報を検出しないとき、HARQ状態はDTX状態であり、DTXは、端末デバイスがチャネルを占有することによってHARQ情報を送信したことをネットワークデバイスが検出しないときに対応するHARQ状態とも呼ばれる。ネットワークデバイスが、端末デバイスがHARQ情報を送信すると予想される時間単位で、端末デバイスによって送信されたHARQ情報を検出するとき、HARQ状態は非DTX状態であり、非DTX状態は、端末デバイスがチャネルを占有することによってHARQ情報を送信したことをネットワークデバイスが検出するときに対応するHARQ状態とも呼ばれる。たとえば、非DTX状態はACKまたはNACKを含んでよい。
【００８３】
第1のHARQプロセス識別子に対応するHARQ状態がDTX状態であるとネットワークデバイスが決定することは、具体的に以下の2つの可能なケースを含む。
【００８４】
ケース1：ネットワークデバイスが端末デバイスにHARQ情報をフィードバックするための時間単位を通知した後、端末デバイスは、LBT障害のためチャネルを先取りしないので、その時間単位でHARQ情報を送信しない。
【００８５】
この場合、端末デバイスは、その後最初に先取りされるチャネル上でHARQ情報を送信し、HARQ情報は、依然として第1のHARQプロセス識別子に対応するHARQ状態を含む。たとえば、基準時間単位内の第1のHARQプロセス識別子に対応するデータパケットの受信状態がACKであるとき、端末デバイスは、LBT障害により、HARQ情報をフィードバックするための、ネットワークデバイスによって通知された時間単位でHARQ情報を送信することができず、ネットワークデバイスは、予想される時間単位で、第1のHARQプロセス識別子に対応するHARQ状態がDTXであることを決定するために、端末デバイスによって送信されたHARQ状態を検出しない。端末デバイスが、HARQ情報をフィードバックするための次の時間単位の間にLBTの実行に成功し、チャネルを先取りすると、端末デバイスはHARQ情報を送信する。この場合、HARQ情報は、第1のHARQプロセス識別子に対応するHARQ状態、すなわちACKを含む。その後、HARQ情報を次にフィードバックするための時間単位がある場合、端末デバイスによってフィードバックされるHARQ情報は、第1のHARQプロセス識別子に対応し、デフォルト状態（NACK）にリセットされるHARQ状態を含む。
【００８６】
ケース2：端末デバイスは、場合によってはネットワークデバイスのダウンリンクデータチャネルを検出しないか、または場合によっては基準時間単位でDL grantを検出しない。したがって、端末デバイスは、HARQ情報がフィードバックされる必要がないと決定する。ネットワークデバイスは、予想される時間単位で、端末デバイスによって送信されたHARQ状態を検出せず、第1のHARQプロセス識別子に対応するHARQ状態がDTXであると決定する。この場合、DTXは第1のHARQプロセス識別子に対応する実際のHARQ状態である。加えて、その後にHARQ情報をフィードバックするための時間単位がある場合でも、端末デバイスによってフィードバックされるHARQ情報は、第1のHARQプロセス識別子に対応するHARQ状態、すなわち、デフォルト状態（NACK）を含む。
【００８７】
たとえば、図4（a）および図4（b）に示されるように、ネットワークデバイスは、サブフレーム＃n〜＃n＋4でダウンリンクバーストを送信し、基準時間単位はサブフレーム＃nである。ネットワークデバイスは、基準時間単位で（＃H0を使用して）UE1および（＃H0を使用して）UE2をスケジュールし、第1のHARQプロセス識別子はUE1の＃H0である。ネットワークデバイスは、サブフレーム＃n＋4のsPUCCHおよびサブフレーム＃n＋9のePUCCH上でHARQ情報をフィードバックするようUE1およびUE2に指示する。
【００８８】
図4（a）では、UE1が＃H0を正しく復調し、UE2が＃H0を不正確に復調すると仮定する。UE1は、LBTの障害のためsPUCCHを占有しない。したがって、ネットワークデバイスは、サブフレーム＃n＋4のsPUCCH上で、UE1によって送信されたHARQ状態を検出せず、第1のHARQプロセス識別子に対応するHARQ状態がDTXであると決定する。UE1は、サブフレーム＃n＋9でのLBTの実行に成功し、ePUCCHを占有するので、UE1はHARQ情報をフィードバックする。この場合、HARQ情報内で搬送されるUE1の＃H0のHARQ状態はACKである。図4（a）は、上記のケース1に対応する。
【００８９】
図4（b）では、UE1がサブフレーム＃nでDL grantを検出せず、UE2が＃H0を不正確に復調すると仮定する。したがって、UE1は新しいHARQプロセスを検出しないので、UE1はサブフレーム＃n＋4でHARQ情報を送信しない。したがって、ネットワークデバイスは、サブフレーム＃n＋4のsPUCCH上でUE1によって送信されたHARQ状態を検出せず、第1のHARQプロセス識別子に対応するHARQ状態がDTXであると決定する。UE1はサブフレーム＃n＋1〜＃n＋3でDL grantを検出するので、UE1はサブフレーム＃n＋9のePUCCH上でHARQ情報をフィードバックする。この場合、HARQ情報内で搬送されるUE1の＃H0のHARQ状態はNACKである。図4（b）は、上記のケース2に対応する。
【００９０】
加えて、ネットワークデバイスは、予想される時間単位で、端末デバイスによって送信されたHARQ状態を検出し、言い換えれば、非DTX状態は、端末デバイスによってネットワークデバイスにフィードバックされるHARQ情報内で搬送される。具体的には、HARQ情報は、ネットワークデバイスによって送信されるデータパケット、またはデータパケットに対応するHARQプロセス識別子、またはトランスポートブロック（TB、Transport Block）、またはデータチャネルに対応するHARQ状態を含む。HARQ情報は、第1のHARQプロセス識別子に対応するHARQ状態を含む少なくとも1つのHARQ状態を搬送する制御情報である。あるいは、HARQ情報は、第1のHARQプロセス識別子に対応するHARQ状態を搬送するビット領域またはビット位置である。具体的には、第1のHARQプロセスがダウンリンクHARQプロセスであるとき、第1のHARQプロセスに対応するHARQ情報は、アップリンク制御チャネル（sPUCCH／ePUCCH）またはアップリンクデータチャネル（PUSCH）上で搬送され、第1のHARQプロセス識別子を含む少なくとも1つのダウンリンクHARQプロセス識別子のHARQ状態を示すために使用される、（HARQ−ACK情報とも呼ばれる）アップリンク制御情報である。たとえば、アップリンク制御情報はビットマッピングに基づくHARQ状態を含み、各HARQビット位置は1つのダウンリンクHARQプロセス識別子に対応する。あるいは、HARQ情報は、アップリンク制御情報内にあり、第1のHARQプロセス識別子に対応するHARQ状態を示すために使用されるビット位置である。
【００９１】
シナリオ1を参照して、本出願のこの実施形態は、少なくとも2つのHARQ状態のうちの有効なHARQ状態を決定する以下の可能な実装形態を提供する。
【００９２】
方式1−1：少なくとも2つのHARQ状態は少なくとも2つのアップリンク時間単位で搬送され、有効なHARQ状態は、少なくとも2つのアップリンク時間単位のうちの最も早いアップリンク時間単位で搬送されるHARQ状態である。
【００９３】
具体的には、有効なHARQ状態が少なくとも2つのアップリンク時間単位のうちの最も早いアップリンク時間単位で搬送されるHARQ状態である理由は以下の通りである。最も早いアップリンク時間単位で搬送されるHARQ状態は、基準時間単位で第1のHARQプロセス識別子に対応するデータ情報の受信状態を正確に反映する。後続のHARQ状態はデフォルト状態にリセットされる場合があるので、HARQ状態はデータ情報の受信状態を正確に反映していない可能性がある。したがって、有効な状態は、最も早いアップリンク時間単位で搬送されるHARQ状態であるべきである。
【００９４】
図5に示されるように、ネットワークデバイスは、サブフレーム＃n〜＃n＋4でダウンリンクバーストを送信し、基準時間単位はサブフレーム＃nである。ネットワークデバイスは、基準時間単位で（＃H0を使用して）UE1および（＃H0を使用して）UE2をスケジュールし、第1のHARQプロセス識別子はUE1の＃H0である。UE1は＃H0を正しく復調し、UE2は＃H0を不正確に復調する。ネットワークデバイスは、サブフレーム＃n＋4のsPUCCHおよびサブフレーム＃n＋8のePUCCH上でHARQ情報をフィードバックするようUE1およびUE2に指示し、HARQ情報はビットマッピングに基づくHARQ状態を含む。UE1は、サブフレーム＃n＋4のsPUCCH上でHARQ情報をフィードバックし、HARQ情報内で搬送されるUE1の＃H0のHARQ状態はACKである。UE1が＃n＋8のePUCCH上でHARQ情報を再びフィードバックすると、HARQ情報内で搬送されるUE1のHARQ状態はNACKにリセットされる。したがって、有効なHARQ状態は、少なくとも2つのアップリンク時間単位のうちの最も早いアップリンク時間単位で搬送されるHARQ状態、すなわち、サブフレーム＃n＋4のsPUCCH上でUE1によってフィードバックされるHARQ情報内で搬送されるUE1の＃H0のHARQ状態：ACKである。
【００９５】
少なくとも2つのアップリンク時間単位のいずれか1つに対応するHARQ状態がDTXである（言い換えれば、端末デバイスが任意の時間単位でHARQ情報を送信することをネットワークデバイスが検出しない）ことは、任意の時間単位で搬送されるHARQ状態がDTXであることとも呼ばれることを理解されたい。
【００９６】
図4（a）に示されるように、第1のHARQプロセス識別子に対応する2つの異なるHARQ状態は、それぞれDTXおよびACKであり、それぞれ2つのアップリンク時間単位のサブフレーム＃n＋4および＃n＋9で搬送される。ネットワークデバイスは、方式1−1において、有効なHARQ状態が2つのアップリンク時間単位のうちのより早いアップリンク時間単位で搬送されるHARQ状態、すなわち、DTXであると決定することができる。
【００９７】
図4（b）に示されるように、第1のHARQプロセス識別子に対応する2つの異なるHARQ状態は、それぞれDTXおよびNACKであり、それぞれ2つのアップリンク時間単位のサブフレーム＃n＋4および＃n＋9で搬送される。ネットワークデバイスは、方式1−1において、有効なHARQ状態が2つのアップリンク時間単位のうちのより早いアップリンク時間単位で搬送されるHARQ状態、すなわち、DTXであると決定することができる。
【００９８】
HARQ情報を搬送する時間単位はネットワークデバイスによって示されることを理解されたい。方式1−1では、少なくとも2つのアップリンク時間単位のうちの最も早いアップリンク時間単位で搬送されるHARQ状態は、第1のデバイスの観点から最も早く取得されるHARQ状態であるか、または第1のデバイスの観点から最も早く取得されると予想されるHARQ状態である。HARQ状態は、基準時間単位に対応する第1のHARQプロセス識別子について第2のデバイスによってフィードバックされる最も早いHARQ情報内で搬送されてもよく、基準時間単位に対応する第1のHARQプロセス識別子について第2のデバイスによってフィードバックされる最も早いHARQ情報内で搬送されなくてもよい。たとえば、第2のデバイスが第1のデバイスによって予想される最も早い時間単位でHARQ情報（DTX）を送信しないが、より遅い時間単位でHARQ情報を送信するとき、第1のデバイスは、依然として（実際に第2のデバイスによって最も早く送信されたHARQ情報に対応するHARQ状態ではなく）最も早く取得されたHARQ状態がDTX状態であると見なす。
【００９９】
したがって、方式1−1は簡単な実装形態によって特徴付けられる。
【０１００】
しかしながら、方式1−1では、第1のHARQプロセス識別子に対応する少なくとも2つのHARQ状態がDTXを含み、DTXが少なくとも2つのアップリンク時間単位のうちの最も早いアップリンク時間単位で搬送されるHARQ状態であるとき、有効な状態は、時間単位で搬送される後続のHARQ状態にかかわらず、方式1−1ではDTXである。DTXがケース1によって発生する場合、具体的には、端末デバイスがLBTの実行に失敗し、端末デバイスが、HARQ情報をフィードバックするための次の時間単位が続く間にLBTの実行に成功し、チャネルを先取りする場合、ネットワークデバイスがACK状態を送信するべきとき、ネットワークデバイスは、基準時間単位に対応する実際のACK状態をDTXとして不正確に記録するので、CWSを不正確に増大させる可能性がある。
【０１０１】
基準時間単位に対応する実際のACK状態がDTXとして誤って記録されるという上記の問題を解決するために、ネットワークデバイスはDTX状態を除外し、次いで、最も早いアップリンク時間単位で搬送されるHARQ状態を有効なHARQ状態として選択してもよい。
【０１０２】
言い換えれば、ネットワークデバイスは、有効なHARQ状態が最も早いアップリンク時間単位で搬送される非DTX状態であると決定する。具体的には、最も早いアップリンク時間単位は、少なくとも2つのHARQ状態を搬送する少なくとも2つの時間単位のうちの最も早い時間単位である。非DTX状態は、DTX状態以外の任意のHARQ状態であることを理解されたい。さらに、非DTX状態はACKおよびNACKのいずれかであってよい。たとえば、第1のHARQプロセス識別子について3つの時間単位で第1のデバイスによって受信される3つのHARQ情報は、それぞれ（時系列的に）DTX、ACK、およびNACKに対応し、有効なHARQ状態はACKである。この場合、最も早い時間単位で搬送されるHARQ状態はACKである。他の例では、第1のHARQプロセス識別子について2つの時間単位で第1のデバイスによって受信される2つのHARQ情報は、それぞれ（時系列的に）DTXおよびNACKに対応する。この場合、最も早い時間単位で搬送されるHARQ状態はNACKである。
【０１０３】
方式1−2：少なくとも2つのHARQ状態の各々は、第2のデバイスによって送信され、第1のデバイスによって検出されるHARQ状態であるとき、有効なHARQ状態は、少なくとも2つのアップリンク時間単位のうちの最も早いアップリンク時間単位で搬送されるHARQ状態である。第1のデバイスが第2のデバイスによって送信されたHARQ状態を検出することは、ネットワークデバイスがチャネルを占有することにより端末デバイスによって送信されたHARQ状態を検出することとも呼ばれる。具体的には、第1のデバイスは、第2のデバイスによって送信されたHARQ状態が非DTX状態であることを検出する。より具体的には、第1のデバイスは、第2のデバイスによって送信されたHARQ状態がACK状態およびNACK状態を含むことを検出する。上述されたように、方式1−1の欠点を回避するために、DTX状態は除外されてよく、少なくとも2つのHARQ状態は非DTX状態に限定され、非DTX状態のうち最も早いHARQ状態が有効なHARQ状態として決定される。たとえば、基準時間単位における第1のHARQプロセスの受信状態がACKであるとき、端末デバイスは、LBT障害のため、HARQ情報を搬送する最も早い時間単位でHARQ情報を送信することができない。HARQ情報を搬送する次の時間単位の間のLBTが成功し、チャネルが占有される場合、最も早い時間単位に対応するHARQ状態はDTXである。次の時間単位に対応するHARQ状態がACKである場合、有効なHARQ状態はACKである。
【０１０４】
言い換えれば、ネットワークデバイスが第1のHARQプロセス識別子についてDTX状態および少なくとも2つの非DTX状態を取得するとき、DTXは除外されてよく、少なくとも2つのHARQ状態は非DTX状態に限定される。
【０１０５】
任意選択で、少なくとも2つのHARQ状態の各々は、第2のデバイスによって送信され、第1のデバイスによって検出されるHARQ状態であり、少なくとも2つのHARQ状態は少なくとも2つのアップリンク時間単位で搬送され、有効なHARQ状態は、少なくとも2つのアップリンク時間単位のうちの最も早いアップリンク時間単位で搬送されるHARQ状態である。
【０１０６】
加えて、方式1−2は、代替として、ネットワークデバイスが第1のHARQプロセス識別子について少なくとも2つの非DTX状態を取得するが、DTX状態を取得しないときにのみ行われてよい。
【０１０７】
図5に示されるように、ネットワークデバイスは、サブフレーム＃n〜＃n＋4でダウンリンクバーストを送信し、基準時間単位はサブフレーム＃nである。ネットワークデバイスは、基準時間単位で（＃H0を使用して）UE1および（＃H0を使用して）UE2をスケジュールし、第1のHARQプロセス識別子はUE1の＃H0である。UE1は＃H0を正しく復調し、UE2は＃H0を不正確に復調する。ネットワークデバイスは、サブフレーム＃n＋4のsPUCCHおよびサブフレーム＃n＋8のePUCCH上でHARQ情報をフィードバックするようUE1およびUE2に指示し、HARQ情報はビットマッピングに基づくHARQ状態を含む。UE1は、サブフレーム＃n＋4のsPUCCH上でHARQ情報をフィードバックし、HARQ情報内で搬送されるUE1の＃H0のHARQ状態はACKである。UE1が＃n＋8のePUCCH上でHARQ情報を再びフィードバックすると、HARQ情報内で搬送されるUE1のHARQ状態はNACKにリセットされる。少なくとも2つのHARQ状態の各々は、端末デバイスによって送信され、ネットワークデバイスによって検出されるHARQ状態であり、それぞれACKおよびNACKである。ネットワークデバイスは、方式1−2において、有効なHARQ状態が、少なくとも2つのアップリンク時間単位のうちの最も早いアップリンク時間単位で搬送されるHARQ状態、すなわち、サブフレーム＃n＋4のsPUCCH上でUE1によってフィードバックされるHARQ情報内で搬送されるUE1の＃H0のHARQ状態：ACKであると決定することができる。
【０１０８】
方式1−2では、少なくとも2つのHARQ状態の各々が、第2のデバイスによって送信され、第1のデバイスによって検出されるHARQ状態であるとき、有効なHARQ状態は、少なくとも2つのアップリンク時間単位のうちの最も早いアップリンク時間単位で搬送されるHARQ状態であり、言い換えれば、有効なHARQ状態は、少なくとも2つのHARQ状態のうち、第1のHARQプロセス識別子に対応し、第1のデバイスによって最も早く受信されるHARQ情報内で搬送されるHARQ状態であることを理解されたい。具体的には、第1のデバイスは、第2のデバイスによって送信されたHARQ状態が非DTX状態であることを検出する。
【０１０９】
したがって、少なくとも2つのアップリンク時間単位のうちの最も早いアップリンク時間単位で搬送されるHARQ状態は、第1のデバイスの観点から最も早く受信されるHARQ情報に対応するHARQ状態である。HARQ情報は、基準時間単位に対応する第1のHARQプロセス識別子について第2のデバイスによってフィードバックされる最も早いHARQ情報であってもよく、基準時間単位に対応する第1のHARQプロセス識別子について第2のデバイスによってフィードバックされる最も早いHARQ情報でなくてもよい。たとえば、第1のデバイスは、第2のデバイスによってフィードバックされる（基準時間単位に対応する第1のHARQプロセス識別子の実際のHARQ状態を含む）最も早いHARQ情報を検出しないが、最も早いHARQ情報として、第2のデバイスによってフィードバックされる後続のHARQ情報（第1のHARQプロセス識別子に対応するHARQ状態はデフォルト状態にリセットされている）を検出する。この場合、第1のデバイスは決定を実行することができないので、有効なHARQ状態はデフォルト状態である。上記の説明は、シナリオ2（方式2−1、方式2−2、および方式2−3）にも適用可能であることを理解されたい。
【０１１０】
したがって、方式1−2は以下によって特徴付けられる。方式1−2は方式1−1よりもやや複雑であるが、方式1−2で決定された有効なHARQ状態は、方式1−1で決定された有効なHARQ状態よりも正確である。
【０１１１】
方式1−1および方式1−2の場合、少なくとも2つのアップリンク時間単位のうちの最初のK（K＞1）個の時間単位がすべて同じHARQ状態を搬送する場合、有効なHARQ状態は同じHARQ状態である。言い換えれば、有効なHARQ状態は、少なくとも2つのアップリンク時間単位のうちの最も早いK個の時間単位で搬送されるHARQ状態であり、ここで、Kは正の整数であり、K個の時間単位で搬送されるHARQ状態は同じである。
【０１１２】
具体的には、有効なHARQ状態が少なくとも2つのアップリンク時間単位のうちの最も早いアップリンク時間単位で搬送されるHARQ状態であることは、有効なHARQ状態が少なくとも2つのアップリンク時間単位のうちの最も早いアップリンク時間単位で搬送されるHARQ状態と同じであることを意味する。本出願は、有効なHARQ状態が、最も早い時間単位において、第2のデバイスによってフィードバックされ、第1のデバイスによって受信されるHARQ情報に基づいて決定されるかどうかに制限を課さない。いくつかの場合、第2のデバイスは、HARQ情報送信の信頼性を向上させるために、少なくとも2つの時間単位で同じHARQ状態を繰り返し送信する。この場合、最も早いアップリンク時間単位で第1のデバイスによって取得されるHARQ状態は、後のアップリンク時間単位で第1のデバイスによって取得されるHARQ状態と同じである。具体的には、第1のHARQプロセス識別子に対応し、後の時間単位で第2のデバイスによってフィードバックされ、第1のデバイスによって受信されるHARQ情報内で搬送されるHARQ状態が、第1のHARQプロセス識別子に対応し、最も早いHARQ情報内で搬送されるHARQ状態と同じであるとき（言い換えれば、第2のデバイスが、複数のHARQ情報の中の第1のHARQプロセス識別子について同じHARQ状態を繰り返し送信するとき）、第1のデバイスは、後のアップリンク時間単位でフィードバックされるHARQ情報に基づいて有効なHARQ状態を決定することもできる。しかしながら、有効なHARQ状態は、最も早いアップリンク時間単位におけるHARQ情報内のHARQ状態と同じであるので、有効なHARQ状態は、依然として、最も早いアップリンク時間単位で搬送されるHARQ状態と呼ばれる。上記の説明は、シナリオ2（たとえば、方式2−1および方式2−2）にも適用可能であることを理解されたい。少なくとも2つのHARQ状態が少なくとも2つのダウンリンク時間単位で搬送されるとき、第1のデバイスは、最も早い時間単位におけるHARQ情報に基づいてHARQ状態を決定してもよく、後の時間単位におけるHARQ情報に基づいてHARQ状態を決定してもよい。この場合、有効なHARQ状態は、少なくとも2つのダウンリンク時間単位のうちの最も早いダウンリンク時間単位で搬送されるHARQ状態である。
【０１１３】
言い換えれば、少なくとも2つのHARQ状態が少なくとも2つの時間単位で搬送されるとき、有効なHARQ状態は、少なくとも2つの時間単位のうちの少なくとも1つの最も早い時間単位で搬送されるHARQ状態であり、少なくとも1つの最も早い時間単位は同じHARQ状態を搬送する。（シナリオ1の場合）少なくとも2つの時間単位の各々は、アップリンク時間単位であるか、または（シナリオ2の場合）少なくとも2つの時間単位は各々ダウンリンク時間単位である。
【０１１４】
図6に示されるように、ネットワークデバイスは、サブフレーム＃n〜＃n＋4でダウンリンクバーストを送信し、基準時間単位はサブフレーム＃nである。ネットワークデバイスは、基準時間単位で（＃H0を使用して）UE1および（＃H0を使用して）UE2をスケジュールし、第1のHARQプロセス識別子はUE1の＃H0である。UE1は＃H0を正しく復調し、UE2は＃H0を不正確に復調する。ネットワークデバイスは、サブフレーム＃n＋4のsPUCCHならびにサブフレーム＃n＋6および＃n＋8のePUCCH上でHARQ情報をフィードバックするようUE1およびUE2に指示し、HARQ情報はビットマッピングに基づくHARQ状態を含む。UE1は、サブフレーム＃n＋4のsPUCCH上でHARQ情報をフィードバックし、HARQ情報内で搬送されるUE1の＃H0のHARQ状態はACKである。HARQ情報送信の信頼性を保証するために、サブフレーム＃n＋6のePUCCH上でUE1によってフィードバックされるHARQ情報内で搬送されるUE1の＃H0のHARQ状態は、依然としてACKであり、NACKにリセットされない。サブフレーム＃n＋8のePUCCH上でUE1によってフィードバックされるHARQ情報内で搬送されるUE1の＃H0のHARQ状態は、NACKにリセットされる。したがって、UE1の＃H0の有効なHARQ状態は、サブフレーム＃n＋4に対応するsPUCCHおよびサブフレーム＃n＋6に対応するePUCCH上で搬送される同じHARQ状態、すなわち、ACKである。
【０１１５】
方式1−3：少なくとも2つのHARQ状態が非DTX状態およびDTX状態を含むとき、有効なHARQ状態は非DTX状態であり、非DTX状態は第2のデバイスによって送信され、第1のデバイスによって検出されるHARQ状態である。有効なHARQ状態が決定されるべきときにDTX状態を除外するために、少なくとも2つのHARQ状態がDTX状態および非DTX状態を含むとき、有効なHARQ状態は非DTX状態として決定されてもよい。
【０１１６】
図4（a）と同様の図7（a）に示されるように、第1のHARQプロセス識別子に対応する2つの異なるHARQ状態は、それぞれDTXおよびACKであり、それぞれ2つのアップリンク時間単位のサブフレーム＃n＋4および＃n＋9で搬送される。ネットワークデバイスは、方式1−3において、有効なHARQ状態が非DTX状態、すなわち、ACKであると決定することができる。
【０１１７】
図4（b）に示されるように、第1のHARQプロセス識別子に対応する2つの異なるHARQ状態は、それぞれDTXおよびNACKであり、それぞれ2つのアップリンク時間単位のサブフレーム＃n＋4および＃n＋9で搬送される。ネットワークデバイスは、方式1−3において、有効なHARQ状態が非DTX状態、すなわち、NACKであると決定することができる。
【０１１８】
したがって、有効なHARQ状態が2つの非DTX状態のうち決定される方式1−2と比較して、方式1−3は以下によって特徴付けられる。2つの異なるHARQ状態が1つのDTX状態および1つの非DTX状態を含むとき、ネットワークデバイスは、方式1−2で有効なHARQ状態を決定するために2つの異なる非DTX状態を待つことなく、方式1−3で有効なHARQ状態を直接決定することができる。したがって、方式1−3はより簡単で効率的である。
【０１１９】
任意選択で、少なくとも2つのHARQ状態がDTX状態および（端末デバイスによって送信され、ネットワークデバイスによって検出されるHARQ状態とも呼ばれる）1つの非DTX状態を含むとき、有効なHARQ状態は非DTX状態である。言い換えれば、少なくとも2つのHARQ状態は2つの異なるHARQ状態のみを含み、1つはDTX状態であり、もう1つは非DTX状態である。この場合、非DTX状態が有効なHARQ状態として選択される。より具体的には、非DTX状態はACKまたはNACKでありうる。
【０１２０】
任意選択で、少なくとも2つのHARQ状態がDTX状態および（第2のデバイスによって送信され、第1のデバイスによって検出されるHARQ状態とも呼ばれる）少なくとも1つの非DTX状態を含むとき、有効なHARQ状態は少なくとも1つの非DTX状態のうちの1つである。少なくとも1つの非DTX状態がただ1つの非DTX状態（たとえば、ACKまたはNACK）を含むとき、有効なHARQ状態は非DTX状態である。少なくとも1つの非DTX状態が少なくとも2つの非DTX状態（たとえば、ACKおよびNACK）を含むとき、有効なHARQ状態は少なくとも2つの非DTX状態のうちの1つである。さらに、少なくとも2つの非DTX状態が少なくとも2つのアップリンク時間単位で搬送されるとき、有効なHARQ状態は、少なくとも2つのアップリンク時間単位のうちの最も早いアップリンク時間単位で搬送される非DTX状態である。
【０１２１】
加えて、ネットワークデバイスが第1のHARQプロセス識別子についてDTX状態および少なくとも2つの異なる非DTX状態を取得するとき、ネットワークデバイスは、方式1−2で有効なHARQ状態を決定することもでき、言い換えれば、少なくとも2つのHARQ状態は少なくとも2つの異なる非DTX状態に限定される。図7（b）に示されるように、ネットワークデバイスは、サブフレーム＃n＋4のsPUCCHならびにサブフレーム＃n＋8および＃n＋10のePUCCH上でHARQ情報をフィードバックするようUE1およびUE2に指示し、HARQ情報はビットマッピングに基づくHARQ状態を含む。第1のHARQプロセス識別子はUE1の＃H0である。UE1はLBTの障害のためsPUCCHを占有せず、ネットワークデバイスは、サブフレーム＃n＋4のsPUCCH上の第1のHARQプロセス識別子に対応するHARQ状態がDTXであると決定する。UE1がLBTの実行に成功し、＃n＋8および＃n＋10のePUCCHを占有する場合、＃n＋8のePUCCH上で搬送されるHARQ状態はACKであり、＃n＋10のePUCCH上で搬送されるHARQ状態はNACKにリセットされる。この場合、方式1−2において、ネットワークデバイスは＃n＋4のDTXを除外し、少なくとも2つの異なるHARQ状態を＃n＋8のACKおよび＃n＋10のNACKに限定し、有効なHARQ状態、すなわち、＃n＋8のePUCCH上で搬送されるHARQ状態：ACKを決定する。
【０１２２】
シナリオ2：第1のデバイスは端末デバイスであり、第2のデバイスはネットワークデバイスであり、第1のHARQプロセス識別子は第1のデバイスに対応するHARQプロセス識別子である。
【０１２３】
アップリンクHARQプロセス識別子に対応するHARQ状態はACKまたはNACKである。
【０１２４】
たとえば、特定のデータパケットまたはデータパケットに対応するアップリンクHARQプロセスが正しく受信されたとネットワークデバイスが決定した場合、ネットワークデバイスは、アップリンクHARQプロセス識別子に対応するHARQ状態がACKであることを端末デバイスにフィードバックする。あるいは、データパケット（またはデータパケットに対応するアップリンクHARQプロセス）が正しく受信されなかったとネットワークデバイスが決定した場合、ネットワークデバイスは、アップリンクHARQプロセス識別子に対応するHARQ状態がNACKであることを端末デバイスにフィードバックする。あるいは、ネットワークデバイスがデータパケット（またはデータパケットに対応するアップリンクHARQプロセス）を検出しない場合、ネットワークデバイスは、アップリンクHARQプロセス識別子に対応するHARQ状態がNACKであることを端末にフィードバックし、言い換えれば、NACKは、データパケットまたはデータパケットに対応するアップリンクHARQプロセスが検出されないことを示すために使用される。
【０１２５】
ネットワークデバイスは、アップリンクHARQプロセス識別子に対応するHARQ状態がHARQ情報内で搬送されることを端末デバイスにフィードバックする。第1のHARQプロセス識別子がアップリンクHARQプロセスであるとき、第1のHARQプロセス識別子に対応するHARQ情報は、ダウンリンク制御チャネル上で搬送され、第1のHARQプロセス識別子を含む少なくとも1つのダウンリンクHARQプロセスのHARQ状態を示すために使用されるダウンリンク制御情報である。HARQ情報は、それぞれHARQフィードバック情報およびスケジューリング情報である2つのタイプに対応してよい。HARQ情報は、HARQフィードバック情報であってもよく、スケジューリング情報であってもよい。HARQ情報は、代替として、HARQフィードバック情報内にあり、HARQ状態を示すために使用されるフィールドであってよく、またはHARQ情報は、スケジューリング情報内にあり、HARQ状態を示すために使用されるフィールドであってもよい。
【０１２６】
HARQフィードバック情報は、特定のHARQプロセス識別子に対応する以前のアップリンク伝送がネットワークデバイスによって正しく受信されたかどうかを示すために使用される指示情報を含むが、HARQプロセス識別子を使用して初期伝送または再伝送を行うよう端末デバイスをスケジュールするためにネットワークデバイスによって使用されるスケジューリング情報を含まない。任意選択で、HARQフィードバック情報は、（少なくとも1つのHARQプロセス識別子を含む）アップリンクHARQプロセス識別子セット内の各HARQプロセス識別子に対応するHARQ状態を含む。アップリンクHARQプロセス識別子セットは、ネットワークデバイスによって構成されてもよく、予め定義されてもよい。具体的には、HARQフィードバック情報内で、アップリンクHARQプロセス識別子セット内の各HARQプロセス識別子に対応するHARQ状態は、ビットマッピングを介して示される。具体的には、アップリンクHARQプロセス識別子セットは、第1のHARQプロセス識別子を含む。
【０１２７】
加えて、上述されたように、ビットマッピングに基づくHARQフィードバック情報内で、HARQフィードバック情報に含まれる各HARQプロセス識別子はデフォルト状態を有する。具体的には、デフォルト状態はNACKである。詳細はここでは再び記載されない。
【０１２８】
さらに、HARQフィードバック情報はG−DCIであってよい。
【０１２９】
任意選択で、HARQフィードバック情報は、G−DCI内にあり、第1のHARQプロセス識別子に対応するHARQ状態を示すために使用されるビット位置である。
【０１３０】
あるいは、HARQ情報は、スケジューリング情報、たとえばUL grantであるか、またはHARQ情報は、UL grant内にあり、HARQ状態を示すために使用されるフィールド、たとえば、新しいデータインジケータ（New Data Indicator、NDI）フィールドである。
【０１３１】
スケジューリング情報は、第1のHARQプロセス識別子に対応するHARQ状態を使用するよう端末デバイスに指示するために使用され、第1のHARQプロセス識別子を使用して初期伝送または再伝送を行うよう端末デバイスをスケジュールするために使用される送信フォーマット情報を含む。送信フォーマット情報には、周波数領域リソース情報、時間領域リソース情報、変調および符号化方式（Modulation and Coding Scheme、MCS）、電力情報、アップリンクパイロット、またはスケジュールされたアップリンク伝送に対応する制御情報、たとえば、サウンディング基準信号（Sounding Reference Signal、SRS）、および／もしくは復調基準シンボル（Demodulation Reference Symbol、DMRS）、および／もしくはチャネル状態情報（Channel State Information、CSI）、および／もしくはDL HARQ要求のうちの少なくとも1つ、ならびにプリコーディングマトリックスインジケータ（Precoding Matrix Indicator、PMI）が含まれる。具体的には、スケジューリング情報はUL grantであってよい。
【０１３２】
任意選択で、スケジューリング情報は、UL grant内にあり、HARQ状態を示すために使用されるビット位置、すなわちNDIである。
【０１３３】
任意選択で、一例としてUL grantを用いると、スケジューリング情報は、以下の方法のうちの1つを使用することにより、第1のHARQプロセス識別子に対応するHARQ状態を示すことができる。これは単なる例であり、本出願のこの実施形態に対する制限を構成するものではない。
【０１３４】
方法1：スクランブリングにより区別が行われる。UL grantが第1のRNTI（たとえば、C−RNTI）を使用してスクランブルされた動的なUL grantであるとき、C−RNTIを使用してスクランブルされたUL grantによって示されたNDIの値が0であるか1であるかにかかわらず、それは、第1のHARQプロセス識別子に対応するHARQ状態がACKであることを示す。UL grantが第2のRNTI（たとえば、SPSC−RNTIまたはGUL C−RNTI）を使用してスクランブルされた準静的なUL grantであり、UL grantによって示されたNDIの値が1などのプリセット値であるとき、それは、第1のHARQプロセス識別子に対応するHARQ状態がNACKであることを示す。第1のRNTIは第2のRNTIと異なることに留意されたい。GUL伝送は準静的なリソース割当てを介して行われてよいことを理解されたい。準静的なUL grant内で搬送されるNDIが0に等しいとき、NDIはGUL伝送をアクティブ化／再アクティブ化するために使用される。準静的なUL grant内で搬送されるNDIが1に等しいとき、NDIは単一の再伝送を行うよう端末デバイスをスケジュールするために使用される。
【０１３５】
方法2：NDIを使用して区別が行われる。UL grant内で搬送されるNDIが、第1のHARQプロセス識別子に対応する以前の送信、すなわち、第1のHARQプロセス識別子を使用して基準時間単位で端末デバイスによって送信されたデータパケットに対応するNDIとトグルされる場合、それは、端末デバイスが第1のHARQプロセス識別子を使用して初期伝送を行うようスケジュールされていることを示し、端末デバイスは、基準時間単位における第1のHARQプロセス識別子に対応するHARQ状態がACKであると見なす。UL grant内で搬送されるNDIが第1のHARQプロセス識別子に対応する以前の送信とトグルされない場合、それは、端末デバイスが第1のHARQプロセス識別子を使用して再伝送を行うようスケジュールされていることを示し、端末デバイスは、HARQ基準時間単位における第1のHARQプロセス識別子に対応する状態がNACKであると見なす。
【０１３６】
シナリオ2を参照して、本出願のこの実施形態は、少なくとも2つのHARQ状態のうちの有効なHARQ状態を決定する以下の可能な実装形態を提供する。
【０１３７】
方式2−1：少なくとも2つのHARQ状態は少なくとも2つのダウンリンク時間単位で搬送され、有効なHARQ状態は、少なくとも2つのダウンリンク時間単位のうちの最も早いダウンリンク時間単位で搬送されるHARQ状態である。
【０１３８】
シナリオ1の方式1−1と同様に、ビットマッピングに基づくHARQフィードバック情報を考慮すると、ネットワークデバイスが第1のHARQプロセス識別子について複数のHARQ状態をフィードバックするとき、最も早いアップリンク時間単位で搬送されるHARQ状態は、基準時間単位における第1のHARQプロセス識別子に対応するデータ情報の受信状態を正確に反映する。後続のHARQ状態はデフォルト状態にリセットされる場合があるので、HARQ状態はデータ情報の受信状態を正確に反映していない可能性がある。
【０１３９】
方式2−1では、有効なHARQ状態は、少なくとも2つのダウンリンク時間単位のうちの最も早いダウンリンク時間単位で搬送されるHARQ情報に対応するHARQ状態であり、HARQ情報に対応するタイプは限定されないことを理解されたい。たとえば、HARQ情報は、HARQフィードバック情報に対応してもよく、スケジューリング情報に対応してもよい。
【０１４０】
図8に示されるように、端末デバイスは、HARQプロセス＃H0〜＃H3にそれぞれ対応するサブフレーム＃n〜＃n＋3でアップリンクバーストを送信する。基準時間単位はサブフレーム＃nであり、第1のHARQプロセス識別子は＃H0である。ネットワークデバイスは、サブフレーム＃n＋5で、＃H0がUL grantを使用してスケジュールされた初期伝送（ACK）を送信し、サブフレーム＃n＋7で、サブフレーム＃nにおける＃H0に対応するHARQ状態：ACKを含むG−DCIをフィードバックし、サブフレーム＃n＋9でG−DCIをフィードバックし、＃H0に対応するHARQ状態をNACKにリセットする。
【０１４１】
端末デバイスは、有効なHARQ状態が、少なくとも2つのダウンリンク時間単位のうちの最も早いダウンリンク時間単位で搬送されるHARQ状態、すなわち、＃H0に対応し、サブフレーム＃n＋5で受信されたUL grantで搬送されるHARQ状態：ACKであると決定する。
【０１４２】
加えて、任意のHARQフィードバック情報および任意のスケジューリング情報は、異なる時間単位で別々に搬送されてもよく、同じ時間単位で搬送されてもよい。任意のHARQフィードバック情報および任意のスケジューリング情報が同じダウンリンク時間単位で搬送され、その時間単位が最も早いダウンリンク時間単位であるとき、有効なHARQ状態は、任意のHARQフィードバック情報に対応するHARQ状態であってもよく、任意のスケジューリング情報に対応するHARQ状態であってもよい。
【０１４３】
任意の2つのHARQフィードバック情報は2つの異なる時間単位で搬送されることを理解されたい。
【０１４４】
しかしながら、第1のHARQプロセス識別子についてであり、端末デバイスによって取得されるHARQ状態は、HARQフィードバック情報内およびスケジューリング情報内で別々に搬送されてよく、HARQフィードバック情報に対応するHARQ状態は、スケジューリング情報に対応するHARQ状態と異なる。たとえば、ネットワークデバイスが、第1のHARQプロセス識別子を使用して端末デバイスによって送信された（データパケット＃1と呼ばれる）アップリンクデータパケットを検出せず、上記の方法1を使用することにより、第1のHARQプロセス識別子を使用して最初に送信される（データパケット＃2と呼ばれる）データパケットを送信するよう端末デバイスをスケジュールするとき、端末デバイスは、スケジューリング情報がデータパケット＃1に対してACKであると誤って見なす可能性があり、言い換えれば、端末デバイスは、検出されない状態がACKであると誤って決定する。したがって、HARQフィードバック情報はより信頼性が高い。たとえば、上記の例では、ネットワークデバイスはデータパケット＃1を検出しないので、ネットワークデバイスは、第1のHARQプロセス識別子に対応するHARQ状態をデフォルトのNACK状態に設定する。したがって、HARQフィードバック情報に対応するHARQ状態がスケジューリング情報に対応するHARQ状態と異なるとき、スケジューリング情報内で搬送されるHARQ状態が除外されてよく、次いで、HARQフィードバック情報内で搬送されるHARQ状態のうち、最も早いHARQ状態が有効なHARQ状態として機能すると決定される。
【０１４５】
言い換えれば、端末デバイスは、有効なHARQ状態が最も早いダウンリンク時間単位でHARQフィードバック情報内で搬送されるHARQ状態である、と決定する。具体的には、最も早いアップリンク時間単位は、少なくとも2つのHARQ状態を搬送し、端末デバイスによって取得される少なくとも2つの時間単位のうちの最も早い時間単位である。
【０１４６】
方式2−2：少なくとも2つのHARQ状態の各々が第2のデバイスによって送信されるHARQフィードバック情報内で搬送されるとき、有効なHARQ状態は、少なくとも2つのダウンリンク時間単位のうちの最も早いダウンリンク時間単位で搬送されるHARQ状態である。
【０１４７】
スケジューリング情報内で搬送されるHARQ状態がHARQフィードバック情報内で搬送されるHARQ状態と異なるとき、スケジューリング情報内で搬送されるHARQ状態は除外されてよく、少なくとも2つのHARQ状態はHARQフィードバック情報内で搬送されるHARQ状態に限定され、HARQフィードバック情報内で搬送される少なくとも2つのHARQ状態のうち、最も早いHARQ状態が有効なHARQ状態として機能すると決定される。
【０１４８】
シナリオ1の方式1−2と同様に、端末デバイスは場合によっては、ダウンリンク制御チャネル領域でブラインド検出を実行することにより、HARQフィードバック情報を取得するので、最も早いダウンリンク時間単位で搬送されるHARQ状態は、実際は、端末デバイスによって検出または受信される最も早いHARQフィードバック情報に対応するHARQ状態である。
【０１４９】
図9に示されるように、端末デバイスは、HARQプロセス＃H0〜＃H3にそれぞれ対応するサブフレーム＃n〜＃n＋3でアップリンクバーストを送信する。基準時間単位はサブフレーム＃nであり、第1のHARQプロセス識別子は＃H0である。ネットワークデバイスは、サブフレーム＃n内の＃H0に対応する実際のHARQ状態ACK、サブフレーム＃n＋1内の＃H1に対応する実際のHARQ状態NACK、ならびにサブフレーム＃n＋1内の＃H2および＃H3に対応するデフォルト状態NACKを含む、サブフレーム＃n＋5内のG−DCIをフィードバックする。ネットワークデバイスは、サブフレーム＃n＋2内の＃H2に対応する実際のHARQ状態ACK、＃H3に対応する実際のHARQ状態NACK、ならびにサブフレーム＃n＋3内の＃H0および＃H1に対応するデフォルト状態NACKを含む、サブフレーム＃n＋7内のG−DCIをフィードバックする。端末デバイスは、サブフレーム＃n＋5内のG−DCIおよびサブフレーム＃n＋7内のG−DCIを正しく検出する。端末デバイスは、第1のHARQプロセス識別子＃H0に対応する2つの異なるHARQ状態がACKおよびNACKであると決定し、両方はネットワークデバイスによって送信されるHARQフィードバック情報内で搬送される。端末デバイスは、方式2−2において、有効なHARQ状態が、少なくとも2つのダウンリンク時間単位のうちの最も早いダウンリンク時間単位で搬送されるHARQ状態、すなわち、サブフレーム＃n＋5内のG−DCI内で＃H0に対応するHARQ状態：ACKであると決定することができる。
【０１５０】
シナリオ1と同様に、方式2−1および方式2−2について、少なくとも2つのダウンリンク時間単位のうちの最初のK（K＞1）個の時間単位がすべて同じHARQ状態を搬送する場合、有効なHARQ状態は同じHARQ状態であり、これはシナリオ1の方式1−1に記載されていることを理解されたい。言い換えれば、有効なHARQ状態は、少なくとも2つのダウンリンク時間単位のうちの最も早いK個の時間単位で搬送されるHARQ状態であり、ここで、Kは正の整数であり、K個の時間単位で搬送されるHARQ状態は同じである。最も早いK個の時間単位のうちのいずれか1つにあり、HARQ状態を搬送するために使用されるHARQ情報は、HARQフィードバック情報に対応してもよく、スケジューリング情報に対応してもよく、言い換えれば、HARQ情報に対応するタイプは限定されないことを理解されたい。
【０１５１】
言い換えれば、少なくとも2つのHARQ状態が少なくとも2つのダウンリンク時間単位で搬送されるとき、有効なHARQ状態は、少なくとも2つのダウンリンク時間単位のうちの少なくとも1つの最も早いダウンリンク時間単位で搬送されるHARQ状態であり、少なくとも1つの最も早いダウンリンク時間単位は同じHARQ状態を搬送する。有効なHARQ状態は同じHARQ状態である。図8に示されるように、2つの最も早いHARQ情報、すなわち、サブフレーム＃n＋5内のUL grantおよびサブフレーム＃n＋7内のG−DCIは、同じHARQ状態に対応する。端末デバイスは、＃H0に対応する有効なHARQ状態が、サブフレーム＃n＋7内のUL grantおよびG−DCIに対応する同じHARQ状態、すなわち、ACKであると決定する。
【０１５２】
方式2−3：少なくとも2つのHARQ状態がそれぞれ第2のデバイスによって送信されるHARQフィードバック情報内および第2のデバイスによって送信されるスケジューリング情報内で搬送され、HARQフィードバック情報内で搬送されるHARQ状態がスケジューリング情報内で搬送されるHARQ状態と異なるとき、有効なHARQ状態はHARQフィードバック情報内で搬送されるHARQ状態である。
【０１５３】
有効なHARQ状態が決定されるとき、スケジューリング情報内で搬送されるHARQ状態を除外するために、HARQフィードバック情報内で搬送されるHARQ状態およびスケジューリング情報内で搬送されるHARQ状態は、少なくとも2つのHARQ状態に追加されてよく、HARQフィードバック情報内で搬送されるHARQ状態がスケジューリング情報内で搬送されるHARQ状態と異なるとき、有効なHARQ状態は、HARQフィードバック情報内で搬送されるHARQ状態として決定される。
【０１５４】
スケジューリング情報内で搬送されるHARQ状態は、少なくとも1つのスケジューリング情報内で搬送されてよいが、少なくとも1つのスケジューリング情報は同じHARQ状態を搬送することを理解されたい。
【０１５５】
HARQフィードバック情報内で搬送されるHARQ状態は、少なくとも1つのHARQフィードバック情報内で搬送されてよいが、少なくとも1つのHARQフィードバック情報は同じHARQ状態を搬送することを理解されたい。
【０１５６】
任意選択で、少なくとも2つのHARQ状態がHARQフィードバック情報内で搬送されるHARQ状態およびスケジューリング情報内で搬送されるHARQ状態を含み、HARQフィードバック情報内で搬送されるHARQ状態がスケジューリング情報内で搬送されるHARQ状態と異なるとき、有効なHARQ状態はHARQフィードバック情報内で搬送されるHARQ状態である。
【０１５７】
任意選択で、少なくとも2つのHARQ状態が少なくとも1つのHARQフィードバック情報内で搬送される少なくとも1つのHARQ状態およびスケジューリング情報内で搬送されるHARQ状態を含み、少なくとも1つのHARQフィードバック情報内で搬送される少なくとも1つのHARQ状態のうちの1つがスケジューリング情報内で搬送されるHARQ状態と異なるとき、有効なHARQ状態は、少なくとも1つのHARQフィードバック情報内で搬送される少なくとも1つのHARQ状態のうちの1つである。さらに、少なくとも1つのHARQフィードバック情報が少なくとも2つの異なるHARQ状態を搬送し、少なくとも2つの異なるHARQ状態が少なくとも2つのダウンリンク時間単位で搬送されるとき、有効なHARQ状態は、少なくとも2つのダウンリンク時間単位のうちの最も早いダウンリンク時間単位で搬送されるHARQ状態である。
【０１５８】
加えて、端末デバイスは、第1のHARQプロセス識別子に対応するHARQ状態が、少なくとも1つのHARQフィードバック情報内で搬送される少なくとも1つのHARQ状態、およびスケジューリング情報内で搬送されるHARQ状態を含むことを知る。少なくとも1つのHARQフィードバック情報が少なくとも2つの異なるHARQ状態を搬送するとき、端末デバイスは、方式2−2で有効なHARQ状態を決定することができ、言い換えれば、少なくとも2つのHARQ状態は、HARQフィードバック情報内で搬送されるHARQ状態に限定され、次いで、HARQフィードバック情報内で搬送される少なくとも2つのHARQ状態のうち、最も早いHARQ状態が有効なHARQ状態として機能すると決定される。
【０１５９】
図10に示されるように、端末デバイスは、＃H0を使用して＃n＋8でGUL伝送（GUL PUSCH）を送信し、サブフレーム＃n＋8は基準時間単位である。ネットワークデバイスは、＃H0に対応するGUL伝送を検出しないが、サブフレーム＃n＋12でG−DCIをフィードバックするために、サブフレーム＃n＋9で＃H1に対応するGUL伝送を検出する。G−DCIは、サブフレーム＃n＋8内の＃H0のHARQ状態がデフォルト状態NACKであることを示す。加えて、ネットワークデバイスは、サブフレーム＃n＋12で、＃H0を使用してサブフレーム＃n＋16内で初期伝送を行うよう端末デバイスをスケジュールするために、UL grantをさらに送信する。この場合、UL grantは、サブフレーム＃n＋8内の＃H0のHARQ状態がACKであることを示す。この場合、HARQフィードバック情報G−DCI内で搬送されるHARQ状態は、スケジューリング情報UL grant内で搬送されるHARQ状態と異なる。したがって、端末デバイスは、有効なHARQ状態が＃n＋8内の＃H0のHARQ状態、すなわち、NACKであると決定する。
【０１６０】
加えて、HARQフィードバック情報内で搬送されるHARQ状態がスケジューリング情報内で搬送されるHARQ状態と同じであるとき、図8に示されるように、端末デバイスは、方式2−1および方式2−2で有効なHARQ状態を決定することができる。
【０１６１】
さらに、少なくとも2つのHARQ状態がACK状態を含むとき、有効なHARQ状態はACK状態である。上記のシナリオ1およびシナリオ2の場合、HARQ状態がNACKである理由は、以前のHARQ状態、すなわちACKがデフォルト状態（NACK）にリセットされるからである。HARQ状態がACKであるとき、それは確かに、基準時間単位における第1のHARQプロセス識別子に対応するデータ情報が第2のデバイスによって正しく受信されることを示す。したがって、少なくとも2つのHARQ状態がACK状態を含むとき、有効なHARQ状態はACK状態である。
【０１６２】
言い換えれば、少なくとも2つのHARQ状態がデフォルト状態および非デフォルト状態を含むとき、有効なHARQ状態は非デフォルト状態である。非デフォルト状態とはHARQ状態がACKであることを意味し、デフォルト状態はHARQ状態がNACKであることを意味する。
【０１６３】
図5に示されるように、ネットワークデバイスが2つの異なるHARQ状態：＃n＋4におけるACKおよび＃n＋8におけるNACKを取得するとき、NACKは明らかにリセットによってもたらされたデフォルト状態である。有効なHARQ状態は非デフォルトのACK状態である。図9に示されるように、端末デバイスが2つの異なるHARQ状態：＃n＋5におけるACKおよび＃n＋7におけるNACKを取得するとき、有効なHARQ状態は同様にACK状態である。
【０１６４】
ステップ320では、第1のデバイスは、上記の2つのシナリオを参照して、有効なHARQ状態に基づいて第1のバーストのためのコンテンションウィンドウサイズを調整する必要がある。
【０１６５】
第1のデバイスが有効なHARQ状態に基づいて第1のバーストのためのCWSを調整する前に、第1のデバイスは最初にCWSを初期値に初期化することに留意されたい。第1のデバイスが基準時間単位でデータ情報についてのHARQ状態を取得するたびに、第1のデバイスは、HARQ状態に基づいてCWSを調整し、調整されたCWSを使用して、ランダムバックオフCCAに基づいて次のバースト上でチャネル検知を実行する。CWSを調整することには、CWSを増大させること、CWSを減少させること、またはCWSを変わらないよう保つことが含まれる。たとえば、基準時間単位における少なくとも1つのHARQプロセス識別子のHARQ状態がACK状態を含まないとき、またはNACK状態が比較的大きな割合を占めるとき、CWSは増大し、そうでない場合、CWSは減少する。
【０１６６】
具体的には、シナリオ1の場合、ネットワークデバイスは、基準時間単位で少なくとも1つの端末デバイスをスケジュールし、少なくとも1つの端末デバイスの各々に対して少なくとも1つのHARQプロセス識別子を使用する。したがって、上記のすべての端末デバイスに対してネットワークデバイスによって取得され、基準時間単位に対応するすべてのHARQ状態について、基準時間単位に対応するHARQ状態のうちのNACK状態が特定の割合（たとえば、80％）を超えるとき、ネットワークデバイスはCWSを増加させ、そうでない場合、ネットワークデバイスはCWSを減少させる。
【０１６７】
ネットワークデバイスが任意のHARQプロセス識別子について少なくとも2つの異なるHARQ状態を取得するとき、基準時間単位に対応するHARQ状態は、本出願では有効なHARQ状態であることを理解されたい。
【０１６８】
さらに、有効なHARQ状態がDTX状態であるとき、有効なHARQ状態はNACKと見なされるか、または有効なHARQ状態は無視され、計算のためのNACK割合に含まれない。
【０１６９】
シナリオ1の場合、第1のHARQプロセス識別子は、基準時間単位に含まれ、任意の端末デバイスのための任意のHARQプロセス識別子であってよいことを理解されたい。言い換えれば、第2のデバイスは、第1のデバイスが基準時間単位でダウンリンク情報を送信する任意の端末デバイスである。第1のHARQプロセス識別子は、基準時間単位で第2のデバイスに使用される任意のダウンリンクHARQプロセス識別子である。基準時間単位に含まれ、少なくとも1つの端末デバイスに対応する少なくとも1つのHARQプロセス識別子は、第1のHARQプロセス識別子を含む。したがって、ネットワークデバイスは、受信状態または第1のHARQプロセス識別子を含む少なくとも1つの端末デバイスの少なくとも1つのHARQプロセス識別子に対応する有効なHARQ状態に基づいて、ダウンリンクCWSを決定すると見なされてよい。言い換えれば、第1のHARQプロセス識別子に対応するHARQ状態は、ダウンリンクCWSの決定に関与する。
【０１７０】
たとえば、ネットワークデバイスは、基準時間単位を2つの端末デバイス：UE1およびUE2にスケジュールする。UE1のスケジューリングに使用されるダウンリンクHARQプロセス識別子は、UE1の＃H1および＃H2を含み、UE2のスケジューリングに使用されるダウンリンクHARQプロセスは、UE2の＃H1および＃H2を含む。第2のデバイスはUE1であってよく、第1のHARQプロセス識別子はUE1の＃H1であってよい。UE1の＃H1の有効なHARQ状態がACKであるとき、UE1の＃H2の有効なHARQ状態はNACKであり、UE2の＃H1の有効なHARQ状態はNACKである。UE2の＃H2の有効なHARQ状態がACKであるとき、NACKはHARQ状態の総数の50％を占め、80％のしきい値に達しないので、ネットワークデバイスは、次のダウンリンクバーストを送ろうとするときにCWSを減少させる。第1のHARQプロセス識別子はNACKの割合計算に関与する。
【０１７１】
具体的には、シナリオ2の場合、端末デバイスが基準時間単位でデータを送信するために端末デバイスによって使用される（アップリンクHARQプロセス識別子セットと呼ばれる）少なくとも1つのHARQプロセス識別子のHARQ状態を取得し、アップリンクHARQプロセス識別子セット内の少なくとも1つのHARQ状態がACKである場合、端末デバイスはCWSを減少させ、そうでない（たとえば、端末デバイスが基準時間単位でいかなるHARQプロセス識別子のHARQ状態も受信しないか、またはアップリンクHARQプロセス識別子セット内のすべてのHARQ状態がNACKである）場合、端末デバイスはCWSを増大させる。
【０１７２】
端末デバイスが任意のHARQプロセス識別子について少なくとも2つの異なるHARQ状態を取得するとき、基準時間単位に対応するHARQ状態は、本出願では有効なHARQ状態であることを理解されたい。
【０１７３】
シナリオ2の場合、第1のHARQプロセス識別子は、アップリンク基準時間単位に対応する任意のHARQプロセス識別子であってよく、言い換えれば、第1のHARQプロセス識別子は、アップリンク基準時間単位で第1のデバイスによって使用される任意のアップリンクHARQプロセス識別子であることを理解されたい。アップリンク基準時間単位に含まれる少なくとも1つのHARQプロセス識別子が第1のHARQプロセス識別子を含むとき、端末デバイスは、第1のHARQプロセス識別子を含む少なくとも1つのHARQプロセス識別子に対応する有効なHARQ状態に基づいてアップリンクCWSを決定し、言い換えれば、第1のHARQプロセス識別子に対応するHARQ状態はアップリンクCWSの決定に関与する。たとえば、端末デバイスは、HARQプロセス識別子＃H1および＃H2を使用して基準時間単位でアップリンクデータを送信し、＃H1の有効なHARQ状態はACKであり、＃H2の有効なHARQ状態はNACKである。その1つのHARQプロセス識別子に対応する有効なHARQ状態がACKであるとき、端末デバイスはCWSを減少させる。したがって、端末デバイスはCWSを減少させる。この場合、第1のHARQプロセス識別子は＃H1であってよい。
【０１７４】
同じ概念に基づいて、本出願はコンテンションウィンドウサイズを調整するためのデバイスをさらに提供する。デバイスは、図3の対応する方法実施形態を実行するよう構成されてよい。したがって、本出願のこの実施形態で提供されるコンテンションウィンドウサイズを調整するためのデバイスの実装形態については、方法の実装形態を参照されたい。詳細は再び記載されない。
【０１７５】
図11を参照すると、本出願の一実施形態はコンテンションウィンドウサイズを調整するためのデバイス1100を提供する。デバイス1100は、
第1のハイブリッド自動再送要求HARQプロセス識別子に対応する少なくとも2つのHARQ状態を取得するよう構成されたトランシーバ1101であって、少なくとも2つのHARQ状態は相違し、第1のHARQプロセス識別子が、デバイスが基準時間単位で第2のデバイスにデータを送信するときに使用されるHARQプロセス識別子である、トランシーバ1101と、
少なくとも2つのHARQ状態のうちの有効なHARQ状態を決定し、有効なHARQ状態に基づいて第1のバーストのためのコンテンションウィンドウサイズを調整するよう構成されたプロセッサ1102であって、第1のバーストが基準時間単位よりも遅い、プロセッサ1102とを含む。
【０１７６】
可能な設計では、少なくとも2つのHARQ状態のうちの任意のHARQ状態は、第1のHARQプロセス識別子に対応する同じトランスポートブロックに対応する。
【０１７７】
可能な設計では、デバイスはネットワークデバイスであり、第2のデバイスは端末デバイスであり、第1のHARQプロセス識別子は第2のデバイスのためのHARQプロセス識別子である。
【０１７８】
可能な設計では、デバイスは端末デバイスであり、第2のデバイスはネットワークデバイスであり、第1のHARQプロセス識別子はデバイスに対応するHARQプロセス識別子である。
【０１７９】
可能な設計では、少なくとも2つのHARQ状態は少なくとも2つのアップリンク時間単位で搬送され、有効なHARQ状態は、少なくとも2つのアップリンク時間単位のうちの最も早いアップリンク時間単位で搬送されるHARQ状態である。
【０１８０】
可能な設計では、少なくとも2つのHARQ状態の各々が、第2のデバイスによって送信され、トランシーバ1101によって検出されるHARQ状態であるとき、有効なHARQ状態は、少なくとも2つのアップリンク時間単位のうちの最も早いアップリンク時間単位で搬送されるHARQ状態である。
【０１８１】
可能な設計では、少なくとも2つのHARQ状態が不連続伝送DTX状態および非DTX状態を含むとき、有効なHARQ状態は非DTX状態であり、非DTX状態は第2のデバイスによって送信され、トランシーバ1101によって検出されるHARQ状態である。
【０１８２】
可能な設計では、少なくとも2つのHARQ状態は少なくとも2つのダウンリンク時間単位で搬送され、有効なHARQ状態は少なくとも2つのダウンリンク時間単位のうちの最も早いダウンリンク時間単位で搬送されるHARQ状態である。
【０１８３】
可能な設計では、少なくとも2つのHARQ状態の各々が第2のデバイスによって送信されるHARQフィードバック情報内で搬送されるとき、有効なHARQ状態は、少なくとも2つのダウンリンク時間単位のうちの最も早いダウンリンク時間単位で搬送されるHARQ状態である。
【０１８４】
可能な設計では、少なくとも2つのHARQ状態がそれぞれ第2のデバイスによって送信されるHARQフィードバック情報および第2のデバイスによって送信されるスケジューリング情報内で搬送され、HARQフィードバック情報内で搬送されるHARQ状態がスケジューリング情報内で搬送されるHARQ状態と異なるとき、有効なHARQ状態はHARQフィードバック情報内で搬送されるHARQ状態である。
【０１８５】
可能な設計では、少なくとも2つのHARQ状態は肯定応答ACK状態を含み、有効なHARQ状態はACK状態である。
【０１８６】
同じ概念に基づいて、本出願はコンテンションウィンドウサイズを調整するための装置をさらに提供する。装置は、図3の対応する方法実施形態を実行するよう構成されてよい。したがって、本出願のこの実施形態で提供されるコンテンションウィンドウサイズを調整するための装置の実装形態については、方法の実装形態を参照されたい。詳細は再び記載されない。
【０１８７】
図12を参照すると、本出願の一実施形態はコンテンションウィンドウサイズを調整するための装置1200を提供する。装置1200は、
第1のハイブリッド自動再送要求HARQプロセス識別子に対応する少なくとも2つのHARQ状態を取得するよう構成されたトランシーバユニット1201であって、少なくとも2つのHARQ状態は相違し、第1のHARQプロセス識別子が、デバイスが基準時間単位で第2のデバイスにデータを送信するときに使用されるHARQプロセス識別子である、トランシーバユニット1201と、
少なくとも2つのHARQ状態のうちの有効なHARQ状態を決定し、有効なHARQ状態に基づいて第1のバーストのためのコンテンションウィンドウサイズを調整するよう構成された処理ユニット1202であって、第1のバーストが基準時間単位よりも遅い、処理ユニット1202とを含む。
【０１８８】
特定の実装形態では、図12のトランシーバユニット1201の機能は図11のトランシーバ1101によって実装されてよく、処理ユニット1202の機能は図11のプロセッサ1102によって実装されてよいことに留意されたい。
【０１８９】
本出願は第1のデバイスおよび第2のデバイスを含む通信システムをさらに提供する。
【０１９０】
結論として、本出願の実施形態はコンテンションウィンドウサイズを調整するための方法を提供する。方法は、第1のデバイスにより、第1のハイブリッド自動再送要求HARQプロセス識別子に対応する少なくとも2つのHARQ状態を取得するステップであって、少なくとも2つのHARQ状態は相違し、第1のHARQプロセス識別子が、第1のデバイスが基準時間単位で第2のデバイスにデータを送信するときに使用されるHARQプロセス識別子である、ステップと、第1のデバイスにより、少なくとも2つのHARQ状態のうちの有効なHARQ状態を決定するステップと、有効なHARQ状態に基づいて第1のバーストのためのコンテンションウィンドウサイズを調整するステップであって、第1のバーストが基準時間単位よりも遅い、ステップとを含む。したがって、本出願の実施形態で提供される方法によれば、第1のデバイスは、コンテンションウィンドウ調整の精度を向上させ、チャネルアクセス効率を改善するために、その後HARQ−ACKをデフォルト状態にリセットすることによって生じる不正確なCWS調整を回避することができる。
【０１９１】
本出願の実施形態は、方法、システム、またはコンピュータプログラム製品として提供されてよいことを当業者なら理解されよう。したがって、本出願の実施形態は、ハードウェアのみの実施形態、ソフトウェアのみの実施形態、またはソフトウェアとハードウェアの組合せを有する実施形態の形態を使用することができる。加えて、本出願の実施形態は、コンピュータ使用可能プログラムコードを含む、（限定はしないが、ディスクメモリ、CD−ROM、および光メモリを含む）1つまたは複数のコンピュータ使用可能記憶媒体に実装されたコンピュータプログラム製品の形態を使用することができる。
【０１９２】
本出願の実施形態は、本出願の実施形態による、方法、デバイス（システム）、およびコンピュータプログラム製品のフローチャートおよび／またはブロック図を参照して記載されている。コンピュータプログラム命令は、フローチャートおよび／またはブロック図の各プロセスおよび／または各ブロック、ならびにフローチャートおよび／またはブロック図のプロセスおよび／またはブロックの組合せを実装するために使用されてよいことを理解されたい。これらのコンピュータプログラム命令は、機械を生成するために、汎用コンピュータ、専用コンピュータ、組込み型プロセッサ、または任意の他のプログラマブルデータ処理デバイスのプロセッサに提供されてよく、その結果、コンピュータまたは任意の他のプログラマブルデータ処理デバイスのプロセッサによって実行される命令は、フローチャートの1つもしくは複数のプロセス内、および／またはブロック図の1つもしくは複数のブロック内の特定の機能を実装するための装置を生成する。
【０１９３】
これらのコンピュータプログラム命令は、特定の方式で動作するようコンピュータまたは任意の他のプログラマブルデータ処理デバイスに命令することができるコンピュータ可読メモリに記憶されてよく、その結果、コンピュータ可読メモリに記憶された命令は、命令装置を含む人工物を生成する。命令装置は、フローチャートの1つもしくは複数のプロセス内、および／またはブロック図の1つもしくは複数のブロック内の特定の機能を実装する。
【０１９４】
これらのコンピュータプログラム命令は、代替として、コンピュータまたは他のプログラマブルデータ処理デバイスにロードされてよく、その結果、一連の動作およびステップは、コンピュータまたは他のプログラマブルデバイス上で実行され、それにより、コンピュータ実装処理が生成される。したがって、コンピュータまたは他のプログラマブルデバイス上で実行される命令は、フローチャートの1つもしくは複数の手順内、および／またはブロック図の1つもしくは複数のブロック内の指定された機能を実装するためのステップを提供する。
【０１９５】
明らかに、当業者は、本出願の趣旨および範囲から逸脱することなく、本出願の実施形態に対してさまざまな修正および変形を行うことができる。本出願は、本出願の以下の特許請求の範囲およびそれらの等価な技術によって規定される保護範囲内に入るという条件で、これらの修正および変形を包含するものである。
【符号の説明】
【０１９６】
1100  デバイス
1101  トランシーバ
1102  プロセッサ
1200  装置
1201  トランシーバユニット
1202  処理ユニット
【図１】
2020522948.tif 000003
【図２】
2020522948.tif 000004
【図３】
2020522948.tif 000005
【図４（ａ）】
2020522948.tif 000006
【図４（ｂ）】
2020522948.tif 000007
【図５】
2020522948.tif 000008
【図６】
2020522948.tif 000009
【図７（ａ）】
2020522948.tif 000010
【図７（ｂ）】
2020522948.tif 000011
【図８】
2020522948.tif 000012
【図９】
2020522948.tif 000013
【図１０】
2020522948.tif 000014
【図１１】
2020522948.tif 000015
【図１２】
2020522948.tif 000016
【手続補正書】
【提出日】令和2年1月15日(2020.1.15)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】０００３
【補正方法】変更
【補正の内容】
【０００３】
さまざまな事業者の基地局およびUE、ならびに免許不要スペクトル上のWi−Fiなどのシステム間ワイヤレスノードとの友好的な共存を実装するために、免許支援アクセス（Licensed−Assisted Access、LAA）／拡張免許支援アクセス（enhanced LAA、eLAA）／Multefireシステムは、リッスンビフォアトーク（Listen−Before−Talk、LBT）チャネルアクセスメカニズムを使用する。たとえば、ダウンリンク伝送を行う前に、送信ノードはチャネルを検知する必要があり、チャネルがアイドル状態であることを検知した後にダウンリンク情報を送信する。具体的には、ダウンリンクLBTはランダムバックオフベースのクリアチャネル評価（Clear Channel Assessment、CCA）である。送信ノードは、均等に0とコンテンションウィンドウサイズ（Contention Window Size、CWS）との間のバックオフカウンタNをランダムに生成し、検知スロット（CCA slot）の粒度で検知を実行する。リスニングスロットにおいて、チャネルがアイドルであることを検出した場合、送信ノードはバックオフカウンタから1を減算する。リスニングスロットにおいて、チャネルがビジーであることを検出した場合、送信ノードはバックオフカウンタを一時停止し、言い換えれば、チャネルがビジーである時間期間において、チャネルがアイドルであることが検出されるまで、バックオフカウンタNは変わらないままである。バックオフカウンタが0に減少すると、送信ノードはチャネルを直ちに占有することができる。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】０００４
【補正方法】変更
【補正の内容】
【０００４】
さらに、送信ノードは、ダウンリンクLBTのためのダウンリンクCWSを動的に調整し、言い換えれば、送信ノードは、ダウンリンク基準サブフレームのために端末によってフィードバックされるハイブリッド自動再送要求確認（Hybrid Automatic Repeat request−Acknowledgement、HARQ−ACK）状態に基づいて、ダウンリンクバーストのためのCWSを動的に調整する。具体的には、ダウンリンク基準サブフレームに対するHARQ−ACK状態での否定応答（Negative Acknowledgement、NACK）の割合が比較的大きいと決定すると、送信ノードは、検知時間を延長することにより、周囲の競合ノードとの衝突を回避し、友好的な共存を実装するためにCWSを増大させる。ダウンリンク基準サブフレームに対するHARQ−ACK状態での肯定応答（Acknowledgement、ACK）の割合が比較的大きいとき、送信ノードは、検知時間を短縮し、より迅速にチャネルにアクセスするためにCWSを減少させる。ダウンリンクLBTと同様に、アップリンクLBTがランダムバックオフベースのCCAであるとき、端末はアップリンクLBTのためのアップリンクCWSを動的に調整し、言い換えれば、端末は、アップリンク基準サブフレームに対するHARQ−ACK状態に基づいて、アップリンクバーストのためのCWSを動的に調整する。アップリンク基準サブフレームに対するHARQ−ACK状態がACKであるとき、端末はCWSを減少させ、アップリンク基準サブフレームに対するHARQ−ACK状態がNACKであるとき、端末はCWSを増大させる。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】００２８
【補正方法】変更
【補正の内容】
【００２８】
第4の態様によれば、本出願の一実施形態は、第1の態様の第1のデバイスおよび第2のデバイスを含む通信システムを提供する。
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】００３３
【補正方法】変更
【補正の内容】
【００３３】
ロングタームエボリューション（Long Term Evolution、LTE）システムは、直交周波数分割多重（Orthogonal Frequency Division Multiplexing、OFDM）技術を使用し、データ伝送に使用される最小リソース単位はリソースエレメント（Resource Element、RE）である。リソースエレメントは、時間領域内の1つのOFDMシンボルおよび周波数領域内の1つのサブキャリアに対応する。これに基づいて、リソースブロック（Resource Block、RB）は、時間領域内の複数の連続するOFDMシンボルおよび周波数領域内の複数の連続するサブキャリアを含み、リソーススケジューリングの基本単位である。LTEアップリンク伝送中、シングルキャリアが使用される。1つのREは、1つのシングルキャリア周波数分割多元接続（Single Carrier Frequency Division Multiplex Access、SC−FDMA）シンボルおよび周波数領域内の1つのサブキャリアに対応し、LTEシステムにおけるアップリンクリソース割当ては、伝送時間間隔（Transmission Time Interval、TTI）の粒度で行われ、1つのTTIの長さは14個のOFDMシンボル、すなわち、1msの長さを有する1つのサブフレームである。
【手続補正５】
【補正対象書類名】明細書
【補正対象項目名】００３４
【補正方法】変更
【補正の内容】
【００３４】
図1を参照すると、LTEシステムにおけるアップリンク伝送は、ネットワークデバイスによってスケジュールされ、具体的には、ネットワークデバイスは、ダウンリンク制御チャネルに含まれるアップリンクグラント（UL grant）を使用することにより、対応するアップリンクサブフレーム内で物理アップリンク共有チャネル（Physical Uplink Shared Channel、PUSCH）を送信するよう、端末デバイスまたはユーザー機器（User Equipment、UE）に指示する。具体的には、端末デバイスがアップリンクデータを送信する必要がある場合、端末デバイスはまず、アップリンク制御チャネル（Physical Uplink Control Channel、PUCCH）上でネットワークデバイスにスケジューリング要求（Scheduling Request、SR）を送信して、ネットワークデバイスがSRを受信した後に端末デバイスにPUSCHをスケジュールするためのUL grantを送信するのを待つ必要があり、次いで、UL grantを使用することにより、スケジュールされたアップリンクリソース上でアップリンクデータを送信する。
【手続補正６】
【補正対象書類名】明細書
【補正対象項目名】００３８
【補正方法】変更
【補正の内容】
【００３８】
具体的には、HARQフィードバック情報内で、HARQプロセスセット内の各HARQプロセスの受信状態は、ビットマッピングによって示される。たとえば、ACKはバイナリの「1」によって表され、NACKはバイナリの「0」によって表される。HARQプロセスセットが、HARQ ID｛＃0、＃1、＃2、＃3｝に対応するHARQプロセスを含むとき、＃0および＃1が正しい受信を示し、＃2および＃3が正しくない受信を示す場合、HARQフィードバック情報に含まれるbit mapは｛1、1、0、0｝である。ビットマッピングに基づくHARQフィードバック情報内で、HARQフィードバック情報に含まれる各HARQプロセス識別子は、デフォルト状態、たとえば、NACK状態を有する。ネットワークデバイスがHARQフィードバック情報を送信するとき、ネットワークデバイスが特定のHARQプロセスのHARQ状態をフィードバックする必要がない（たとえば、端末デバイスがHARQプロセスを使用してデータパケットを送信することをネットワークデバイスが検出しない）場合、それは、HARQプロセスが（NACKによって表されてよい）デフォルト状態にあることを示す。あるいは、HARQフィードバック情報を使用することにより、特定の検出されたデータチャネルに対応するHARQプロセスのHARQ状態をフィードバックした後、ネットワークデバイスは、HARQプロセスに対応するHARQ状態をデフォルト状態にリセットしてもよい。図2に示されるように、HARQフィードバック情報はG−DCIであり、HARQプロセスセットは＃H0、＃H1、＃H2、および＃H3を含む。端末デバイスは、＃H0〜＃H3を使用して、それぞれサブフレーム＃n〜＃n＋3内でアップリンクデータ情報を送信する。ネットワークデバイスは、＃n＋5のG−DCI内で＃H0、＃H1、＃H2および＃H3のHARQ状態［H0：NACK、H1：ACK、H2：NACK、H3：NACK］をフィードバックし、＃H2および＃H3のHARQ状態はデフォルト状態である。ネットワークデバイスは、＃n＋7のG−DCI内で＃H2および＃H3のHARQ状態［NACK、NACK、ACK、ACK」をフィードバックし、＃H1のHARQ状態は＃n＋7のG−DCI内でデフォルト状態NACKにリセットされる。
【手続補正７】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
コンテンションウィンドウサイズを調整するための方法であって、前記方法は、
第1のデバイスにより、第1のハイブリッド自動再送要求HARQプロセス識別子に対応する少なくとも2つのHARQ状態を取得するステップであって、前記少なくとも2つのHARQ状態は相違し、前記第1のHARQプロセス識別子は、前記第1のデバイスが基準時間単位で第2のデバイスにデータを送信するときに使用されるHARQプロセス識別子である、ステップと、
前記第1のデバイスにより、前記少なくとも2つのHARQ状態のうちの有効なHARQ状態を決定するステップと、
前記第1のデバイスにより、前記有効なHARQ状態に基づいて第1のバーストのためのコンテンションウィンドウサイズを調整するステップであって、前記第1のバーストは前記基準時間単位よりも遅く、前記少なくとも2つのHARQ状態を搬送する任意の時間単位は前記基準時間単位よりも遅く、前記少なくとも2つのHARQ状態を搬送する任意の時間単位と前記基準時間単位との間の時間間隔は第1のプリセット時間間隔以上である、ステップとを備える、方法。
【請求項２】
前記少なくとも2つのHARQ状態のうちの任意のHARQ状態は、前記第1のHARQプロセス識別子に対応する同じトランスポートブロックに対応する、請求項1に記載の方法。
【請求項３】
前記第1のデバイスはネットワークデバイスであり、前記第2のデバイスは端末デバイスであり、前記第1のHARQプロセス識別子は前記第2のデバイスのためのHARQプロセス識別子である、請求項1または2に記載の方法。
【請求項４】
前記第1のデバイスは端末デバイスであり、前記第2のデバイスはネットワークデバイスであり、前記第1のHARQプロセス識別子は前記第1のデバイスに対応するHARQプロセス識別子である、請求項1または2に記載の方法。
【請求項５】
前記少なくとも2つのHARQ状態は少なくとも2つのアップリンク時間単位で搬送され、前記少なくとも2つのHARQ状態の各々が、前記第1のデバイスによって受信されるHARQ状態であるとき、前記有効なHARQ状態は、前記少なくとも2つのアップリンク時間単位のうちの最も早いアップリンク時間単位で搬送されるHARQ状態である、請求項3に記載の方法。
【請求項６】
前記少なくとも2つのHARQ状態が不連続伝送DTX状態および非DTX状態を含むとき、前記有効なHARQ状態は前記非DTX状態であり、前記非DTX状態は、前記第1のデバイスによって受信されるHARQ状態である、請求項3に記載の方法。
【請求項７】
前記少なくとも2つのHARQ状態がDTX状態および少なくとも2つの非DTX状態を含み、前記少なくとも2つの非DTX状態が少なくとも2つのアップリンク時間単位で搬送されるとき、前記有効なHARQ状態は、前記少なくとも2つのアップリンク時間単位のうちの最も早いアップリンク時間単位で搬送される非DTX状態である、請求項6に記載の方法。
【請求項８】
前記少なくとも2つのHARQ状態は少なくとも2つのダウンリンク時間単位で搬送され、前記有効なHARQ状態は、前記少なくとも2つのダウンリンク時間単位のうちの最も早いダウンリンク時間単位で搬送されるHARQ状態である、請求項4に記載の方法。
【請求項９】
前記少なくとも2つのHARQ状態の各々が、前記第2のデバイスによって送信されるHARQフィードバック情報内で搬送されるとき、前記有効なHARQ状態は、前記少なくとも2つのダウンリンク時間単位のうちの前記最も早いダウンリンク時間単位で搬送される前記HARQ状態である、請求項8に記載の方法。
【請求項１０】
前記少なくとも2つのHARQ状態は肯定応答ACK状態を含み、前記有効なHARQ状態は前記ACK状態である、請求項1から4のいずれか一項に記載の方法。
【請求項１１】
コンテンションウィンドウサイズを調整するためのデバイスであって、
第1のハイブリッド自動再送要求HARQプロセス識別子に対応する少なくとも2つのHARQ状態を取得するよう構成されたトランシーバであって、前記少なくとも2つのHARQ状態は相違し、前記第1のHARQプロセス識別子は、前記デバイスが基準時間単位で第2のデバイスにデータを送信するときに使用されるHARQプロセス識別子である、トランシーバと、
前記少なくとも2つのHARQ状態のうちの有効なHARQ状態を決定し、前記有効なHARQ状態に基づいて第1のバーストのためのコンテンションウィンドウサイズを調整するよう構成されたプロセッサであって、前記第1のバーストは前記基準時間単位よりも遅く、前記少なくとも2つのHARQ状態を搬送する任意の時間単位は前記基準時間単位よりも遅く、前記少なくとも2つのHARQ状態を搬送する任意の時間単位と前記基準時間単位との間の時間間隔は第1のプリセット時間間隔以上である、プロセッサとを備える、デバイス。
【請求項１２】
前記少なくとも2つのHARQ状態のうちの任意のHARQ状態は、前記第1のHARQプロセス識別子に対応する同じトランスポートブロックに対応する、請求項11に記載のデバイス。
【請求項１３】
前記デバイスはネットワークデバイスであり、前記第2のデバイスは端末デバイスであり、前記第1のHARQプロセス識別子は前記第2のデバイスのためのHARQプロセス識別子である、請求項11または12に記載のデバイス。
【請求項１４】
前記デバイスは端末デバイスであり、前記第2のデバイスはネットワークデバイスであり、前記第1のHARQプロセス識別子は前記デバイスに対応するHARQプロセス識別子である、請求項11または12に記載のデバイス。
【請求項１５】
前記少なくとも2つのHARQ状態は少なくとも2つのアップリンク時間単位で搬送され、前記少なくとも2つのHARQ状態の各々が、前記デバイスによって受信されるHARQ状態であるとき、前記有効なHARQ状態は、前記少なくとも2つのアップリンク時間単位のうちの最も早いアップリンク時間単位で搬送されるHARQ状態である、請求項13に記載のデバイス。
【請求項１６】
前記少なくとも2つのHARQ状態が不連続伝送DTX状態および非DTX状態を含むとき、前記有効なHARQ状態は前記非DTX状態であり、前記非DTX状態は、前記デバイスによって受信されるHARQ状態である、請求項13に記載のデバイス。
【請求項１７】
前記少なくとも2つのHARQ状態はDTX状態および少なくとも2つの非DTX状態を含み、前記少なくとも2つの非DTX状態が少なくとも2つのアップリンク時間単位で搬送されるとき、前記有効なHARQ状態は、前記少なくとも2つのアップリンク時間単位のうちの最も早いアップリンク時間単位で搬送される非DTX状態である、請求項16に記載のデバイス。
【請求項１８】
前記少なくとも2つのHARQ状態は少なくとも2つのダウンリンク時間単位で搬送され、前記有効なHARQ状態は、前記少なくとも2つのダウンリンク時間単位のうちの最も早いダウンリンク時間単位で搬送されるHARQ状態である、請求項14に記載のデバイス。
【請求項１９】
前記少なくとも2つのHARQ状態の各々が、前記第2のデバイスによって送信されるHARQフィードバック情報内で搬送されるとき、前記有効なHARQ状態は、前記少なくとも2つのダウンリンク時間単位のうちの前記最も早いダウンリンク時間単位で搬送される前記HARQ状態である、請求項18に記載のデバイス。
【請求項２０】
前記少なくとも2つのHARQ状態は肯定応答ACK状態を含み、前記有効なHARQ状態は前記ACK状態である、請求項11から14のいずれか一項に記載のデバイス。
【請求項２１】
コンピュータに請求項1から10のいずれか一項に記載の方法を行わせるためのコンピュータプログラム。
【国際調査報告】
2020522948.tif 000017
2020522948.tif 000018
2020522948.tif 000019
2020522948.tif 000020