(57)【要約】  いくつかの実施形態によれば、リッスンビフォアトーク（ＬＢＴ）競合ウィンドウサイズを管理するためのユーザ装置（ＵＥ）において使用される方法は、ＬＢＴ競合ウィンドウサイズを使用して実行される第１のＬＢＴ手順の後にアップリンクサブフレームの第１のバーストを送信することと、第１のバーストに基づいて参照サブフレームを決定することと、を含む。参照サブフレームは参照ハイブリッド自動再送要求（ＨＡＲＱ）プロセス識別子に関連付けられている。方法は、更に、アップリンクサブフレームの第２のバーストに対するスケジューリングを受信することを含む。スケジューリングは、各サブフレームについて、関連するＨＡＲＱプロセス識別子および関連する新規データインジケータ（ＮＤＩ）を含む。ＵＥが第２のバーストのサブフレームのうちの少なくとも１つに関連付けられたＨＡＲＱプロセス識別子が参照ＨＡＲＱプロセス識別子と一致し、関連付けられたＮＤＩが新規のデータを示すとき、方法は、ＬＢＴ競合ウィンドウサイズをリセットするし、そうでなければ、方法は、ＬＢＴ競合ウィンドウサイズをインクリメントする。【選択図】図１３
2019525603.tif 000002
【特許請求の範囲】
【請求項１】
リッスンビフォアトーク（ＬＢＴ）競合ウィンドウサイズを管理するためのユーザ装置（ＵＥ）において使用される方法であって、
第１のＬＢＴ手順の後にアップリンクサブフレームの第１のバーストを送信すること（１３１２）であって、ＬＢＴ手順はＬＢＴ競合ウィンドウサイズを使用して実行される、前記送信すること（１３１２）と、
アップリンクサブフレームの前記第１のバーストに基づいて参照サブフレームを決定すること（１３１４）であって、前記参照サブフレームは参照ハイブリッド自動再送要求（ＨＡＲＱ）プロセス識別子に関連付けられている、前記決定すること（１３１４）と、
アップリンクサブフレームの第２のバーストに対するスケジューリングを受信すること（１３１６）であって、前記スケジューリングは、アップリンクサブフレームの前記第２のバーストの各サブフレームについて、関連するＨＡＲＱプロセス識別子および関連する新規データインジケータ（ＮＤＩ）を含む、前記受信すること（１３１６）と、
前記ＵＥがアップリンクサブフレームの前記第２のバーストのサブフレームのうちの少なくとも１つに関連付けられたＨＡＲＱプロセス識別子が前記参照ＨＡＲＱプロセス識別子と一致しかつ前記関連付けられたＮＤＩが新規のデータを示すと決定したとき、前記ＬＢＴ競合ウィンドウサイズを最小値にリセットすること（１３１８）と、
前記ＵＥがアップリンクサブフレームの前記第２のバーストのサブフレームのうちの少なくとも１つに関連付けられたＨＡＲＱプロセス識別子が前記参照ＨＡＲＱプロセス識別子と一致しかつ前記関連付けられたＮＤＩが再送信を示すと決定したとき、前記ＬＢＴ競合ウィンドウサイズをインクリメントすること（１３２０）と、
前記競合ウィンドウサイズを使用して第２のＬＢＴ手順を実行すること（１３２２）と、
を含む方法。
【請求項２】
前記参照サブフレームを前記決定すること（１３１４）は、前記関連するＨＡＲＱプロセス識別子がアップリンクサブフレームの前記第２のバーストに対する前記受信されたスケジューリングにおいても見出される、アップリンクサブフレームの前記第１のバーストにおいて最も最近送信されたアップリンクサブフレームを決定することを含む
請求項１に記載の方法。
【請求項３】
前記参照サブフレームを前記決定すること（１３１４）は、アップリンクサブフレームの前記第１のバーストにおける第１のサブフレームに関連付けられた前記ＨＡＲＱプロセス識別子がアップリンクサブフレームの前記第２のバーストに対する前記受信されたスケジューリングにおいても見出される、アップリンクサブフレームの前記第１のバーストにおいて最初に送信されたサブフレームを決定することを含む
請求項１に記載の方法。
【請求項４】
前記第１のバーストの送信は、前記参照サブフレームを前記決定する前に閾値時間を超えて終了する
請求項１に記載の方法。
【請求項５】
前記閾値時間は４ｍｓである
請求項４に記載の方法。
【請求項６】
前記ＬＢＴ競合ウィンドウサイズを最小値に前記リセットすること（１３１８）は、前記ＬＢＴ競合ウィンドウサイズを、前記第１のＬＢＴ手順を実行するために前記ＵＥによって使用される優先度クラスに関連する値のセットの最小値にリセットすることを含む
請求項１乃至５の何れか１項に記載の方法。
【請求項７】
前記ＬＢＴ競合ウィンドウサイズを最小値に前記リセットすること（１３１８）は、前記ＵＥによって使用される全ての優先度クラスに関連するＬＢＴ競合ウィンドウサイズをリセットすることを含む
請求項１乃至５の何れか１項に記載の方法。
【請求項８】
前記ＬＢＴ競合ウィンドウサイズを前記インクリメントすること（１３２０）は、前記ＬＢＴ競合ウィンドウサイズを、前記第１のＬＢＴ手順を実行するために前記ＵＥによって使用される優先度クラスに関連する値のセットの中の次の値までインクリメントすることを含む
請求項１乃至５の何れか１項に記載の方法。
【請求項９】
前記ＬＢＴ競合ウィンドウサイズを前記インクリメントすること（１３２０）は、前記ＵＥによって使用される全ての優先度クラスに関連するＬＢＴ競合ウィンドウサイズをインクリメントすることを含む
請求項１乃至５の何れか１項に記載の方法。
【請求項１０】
前記参照サブフレームは複数のＨＡＲＱプロセス識別子と関連付けられ、前記ＬＢＴ競合ウィンドウサイズは、前記複数のＨＡＲＱプロセス識別子の各ＨＡＲＱプロセス識別子に関連付けられた前記ＮＤＩが再送信を示すときインクリメントされる
請求項１乃至９の何れか１項に記載の方法。
【請求項１１】
前記参照サブフレームは複数のＨＡＲＱプロセス識別子と関連付けられ、前記ＬＢＴ競合ウィンドウサイズは、前記複数のＨＡＲＱプロセス識別子のＨＡＲＱプロセス識別子に関連付けられた少なくとも１つのＮＤＩが新規のデータを示すときリセットされる
請求項１乃至９の何れか１項に記載の方法。
【請求項１２】
前記第２のＬＢＴ手順を前記実行すること（１３２２）は、ライセンス支援アクセス（ＬＡＡ）の二次セル上の物理アップリンク共有チャネル（ＰＵＳＣＨ）送信に対するカテゴリ４ＬＢＴを実行することを含む
請求項１乃至１１の何れか１項に記載の方法。
【請求項１３】
リッスンビフォアトーク（ＬＢＴ）競合ウィンドウサイズを管理するように動作可能なユーザ装置（ＵＥ）（１１０）であって、
第１のＬＢＴ手順の後にアップリンクサブフレームの第１のバーストを送信し、ここで、ＬＢＴ手順はＬＢＴ競合ウィンドウサイズを使用して実行され、
アップリンクサブフレームの前記第１のバーストに基づいて参照サブフレームを決定し、ここで、前記参照サブフレームは参照ハイブリッド自動再送要求（ＨＡＲＱ）プロセス識別子に関連付けられており、
アップリンクサブフレームの第２のバーストに対するスケジューリングを受信し、ここで、前記スケジューリングは、アップリンクサブフレームの前記第２のバーストの各サブフレームについて、関連するＨＡＲＱプロセス識別子および関連する新規データインジケータ（ＮＤＩ）を含み、
前記ＵＥがアップリンクサブフレームの前記第２のバーストのサブフレームのうちの少なくとも１つに関連付けられたＨＡＲＱプロセス識別子が前記参照ＨＡＲＱプロセス識別子と一致しかつ前記関連付けられたＮＤＩが新規のデータを示すと決定したとき、前記ＬＢＴ競合ウィンドウサイズを最小値にリセットし、
前記ＵＥがアップリンクサブフレームの前記第２のバーストのサブフレームのうちの少なくとも１つに関連付けられたＨＡＲＱプロセス識別子が前記参照ＨＡＲＱプロセス識別子と一致しかつ前記関連付けられたＮＤＩが再送信を示すと決定したとき、前記ＬＢＴ競合ウィンドウサイズをインクリメントし、
前記競合ウィンドウサイズを使用して第２のＬＢＴ手順を実行する、
よう動作可能な処理回路（１５２０）を含むユーザ装置（ＵＥ）。
【請求項１４】
前記処理回路は、前記関連するＨＡＲＱプロセス識別子がアップリンクサブフレームの前記第２のバーストに対する前記受信されたスケジューリングにおいても見出される、アップリンクサブフレームの前記第１のバーストにおいて最も最近送信されたアップリンクサブフレームを決定することにより、前記参照サブフレームを決定するよう動作可能である
請求項１３に記載のＵＥ。
【請求項１５】
前記処理回路は、アップリンクサブフレームの前記第１のバーストにおける第１のサブフレームに関連付けられた前記ＨＡＲＱプロセス識別子がアップリンクサブフレームの前記第２のバーストに対する前記受信されたスケジューリングにおいても見出される、アップリンクサブフレームの前記第１のバーストにおいて最初に送信されたサブフレームを決定することにより、前記参照サブフレームを決定するよう動作可能である
請求項１３に記載のＵＥ。
【請求項１６】
前記第１のバーストの送信は、前記参照サブフレームを前記決定する前に閾値時間を超えて終了する
請求項１４に記載のＵＥ。
【請求項１７】
前記閾値時間は４ｍｓである
請求項１６に記載のＵＥ。
【請求項１８】
前記処理回路は、前記ＬＢＴ競合ウィンドウサイズを、前記第１のＬＢＴ手順を実行するために前記ＵＥによって使用される優先度クラスに関連する値のセットの最小値にリセットすることにより、前記ＬＢＴ競合ウィンドウサイズを最小値にリセットするよう動作可能である
請求項１３乃至１７の何れか１項に記載のＵＥ。
【請求項１９】
前記処理回路は、前記ＵＥによって使用される全ての優先度クラスに関連するＬＢＴ競合ウィンドウサイズをリセットすることにより、前記ＬＢＴ競合ウィンドウサイズを最小値にリセットするよう動作可能である
請求項１３乃至１７の何れか１項に記載のＵＥ。
【請求項２０】
前記処理回路は、前記ＬＢＴ競合ウィンドウサイズを、前記第１のＬＢＴ手順を実行するために前記ＵＥによって使用される優先度クラスに関連する値のセットの中の次の値までインクリメントすることにより、前記ＬＢＴ競合ウィンドウサイズをインクリメントするよう動作可能である
請求項１３乃至１７の何れか１項に記載のＵＥ。
【請求項２１】
前記処理回路は、前記ＵＥによって使用される全ての優先度クラスに関連するＬＢＴ競合ウィンドウサイズをインクリメントすることにより、前記ＬＢＴ競合ウィンドウサイズをインクリメントするよう動作可能である
請求項１３乃至１７の何れか１項に記載のＵＥ。
【請求項２２】
前記参照サブフレームは複数のＨＡＲＱプロセス識別子と関連付けられ、前記ＬＢＴ競合ウィンドウサイズは、前記複数のＨＡＲＱプロセス識別子の各ＨＡＲＱプロセス識別子に関連付けられた前記ＮＤＩが再送信を示すときインクリメントされる
請求項１３乃至２１の何れか１項に記載のＵＥ。
【請求項２３】
前記参照サブフレームは複数のＨＡＲＱプロセス識別子と関連付けられ、前記ＬＢＴ競合ウィンドウサイズは、前記複数のＨＡＲＱプロセス識別子のＨＡＲＱプロセス識別子に関連付けられた少なくとも１つのＮＤＩが新規のデータを示すときリセットされる
請求項１３乃至２１の何れか１項に記載のＵＥ。
【請求項２４】
前記処理回路は、ライセンス支援アクセス（ＬＡＡ）の二次セル上の物理アップリンク共有チャネル（ＰＵＳＣＨ）送信に対するカテゴリ４ＬＢＴを実行することにより、前記第２のＬＢＴ手順を実行するよう動作可能である
請求項１３乃至２３の何れか１項に記載のＵＥ。
【請求項２５】
ネットワークノードにおいて使用されるリッスンビフォアトーク（ＬＢＴ）パラメータのシグナリングの方法であって、
第１のＬＢＴ手順の後に、アップリンクサブフレームの第１のバーストをユーザ装置（ＵＥ）から受信すること（１４１２）であって、アップリンクサブフレームの前記第１のバーストの各サブフレームは１つまたは複数の転送ブロックに関連付けられており、各転送ブロックはハイブリッド自動再送要求（ＨＡＲＱ）プロセス識別子に関連付けられている、前記受信すること（１４１２）と、
前記ネットワークノードによって正常に受信されなかった、アップリンクサブフレームの前記第１のバーストの中の転送ブロックのセットを決定すること（１４１４）と、
第２のＬＢＴ手順で前記ＵＥをスケジューリングする前に、前記決定された転送ブロックのセットの中の転送ブロックに関連付けられた全てのＨＡＲＱプロセス識別子を使用してアップリンクフレームの第２のバーストで前記ＵＥをスケジューリングすること（１４１６）と、
を含む方法。
【請求項２６】
前記ネットワークノードによって正常に受信されなかった、アップリンクサブフレームの前記第１のバーストの中の転送ブロックのセットを前記決定すること（１４１４）は、少なくとも１つの転送ブロックが首尾よく受信された受信サブフレームの前の最後のサブフレームに基づいて参照サブフレームを決定することを含み、
転送ブロックの前記セットは、正常に受信されなかった前記参照サブフレームの中の転送ブロックを含む
請求項２５に記載の方法。
【請求項２７】
リッスンビフォアトーク（ＬＢＴ）パラメータをシグナリングするように動作可能なネットワークノード（１２０）であって、
第１のＬＢＴ手順の後に、アップリンクサブフレームの第１のバーストをユーザ装置（ＵＥ）から受信し、ここで、アップリンクサブフレームの前記第１のバーストの各サブフレームは１つまたは複数の転送ブロックに関連付けられており、各転送ブロックはハイブリッド自動再送要求（ＨＡＲＱ）プロセス識別子に関連付けられており、
前記ネットワークノードによって正常に受信されなかった、アップリンクサブフレームの前記第１のバーストの中の転送ブロックのセットを決定し、
第２のＬＢＴ手順で前記ＵＥをスケジューリングする前に、前記決定された転送ブロックのセットの中の転送ブロックに関連付けられた全てのＨＡＲＱプロセス識別子を使用してアップリンクフレームの第２のバーストで前記ＵＥをスケジューリングする
よう動作可能な処理回路（１６２０）を含むネットワークノード。
【請求項２８】
前記ネットワークノードによって正常に受信されなかった、アップリンクサブフレームの前記第１のバーストの中の転送ブロックのセットを前記決定するよう動作可能な前記処理回路は、少なくとも１つの転送ブロックが首尾よく受信された受信サブフレームの前の最後のサブフレームに基づいて参照サブフレームを決定するよう動作可能であり、
転送ブロックの前記セットは、正常に受信されなかった前記参照サブフレームの中の転送ブロックを含む
請求項２７に記載のネットワークノード。
【請求項２９】
リッスンビフォアトーク（ＬＢＴ）競合ウィンドウサイズを管理するように動作可能なユーザ装置（ＵＥ）（１１０）であって、該ＵＥは、送信モジュール（１５５０）と決定モジュール（１５５２）と受信モジュール（１５５６）とＬＢＴモジュール（１５５４）とを有し、
前記送信モジュールは、第１のＬＢＴ手順の後にアップリンクサブフレームの第１のバーストを送信するよう動作可能であり、ここで、ＬＢＴ手順はＬＢＴ競合ウィンドウサイズを使用して実行され、
前記決定モジュールは、アップリンクサブフレームの前記第１のバーストに基づいて参照サブフレームを決定するよう動作可能であり、ここで、前記参照サブフレームは参照ハイブリッド自動再送要求（ＨＡＲＱ）プロセス識別子に関連付けられており、
前記受信モジュールは、アップリンクサブフレームの第２のバーストに対するスケジューリングを受信するよう動作可能であり、ここで、前記スケジューリングは、アップリンクサブフレームの前記第２のバーストの各サブフレームについて、関連するＨＡＲＱプロセス識別子および関連する新規データインジケータ（ＮＤＩ）を含み、
前記ＵＥがアップリンクサブフレームの前記第２のバーストのサブフレームのうちの少なくとも１つに関連付けられたＨＡＲＱプロセス識別子が前記参照ＨＡＲＱプロセス識別子と一致しかつ前記関連付けられたＮＤＩが新規のデータを示すと決定したとき、前記ＬＢＴモジュールは、前記ＬＢＴ競合ウィンドウサイズを最小値にリセットするよう動作可能であり、
前記ＵＥがアップリンクサブフレームの前記第２のバーストのサブフレームのうちの少なくとも１つに関連付けられたＨＡＲＱプロセス識別子が前記参照ＨＡＲＱプロセス識別子と一致しかつ前記関連付けられたＮＤＩが再送信を示すと決定したとき、前記ＬＢＴモジュールは、前記ＬＢＴ競合ウィンドウサイズをインクリメントするよう動作可能であり、
前記ＬＢＴモジュールは、前記競合ウィンドウサイズを使用して第２のＬＢＴ手順を実行するよう更に動作可能である
ユーザ装置（ＵＥ）。
【請求項３０】
リッスンビフォアトーク（ＬＢＴ）パラメータをシグナリングするように動作可能なネットワークノード（１２０）であって、該ネットワークノードは、受信モジュール（１６５０）と決定モジュール（１６５２）とＬＢＴモジュール（１６５４）とを有し、
前記受信モジュールは、第１のＬＢＴ手順の後に、アップリンクサブフレームの第１のバーストをユーザ装置（ＵＥ）から受信するよう動作可能であり、ここで、アップリンクサブフレームの前記第１のバーストの各サブフレームは１つまたは複数の転送ブロックに関連付けられており、各転送ブロックはハイブリッド自動再送要求（ＨＡＲＱ）プロセス識別子に関連付けられており、
前記決定モジュールは、前記ネットワークノードによって正常に受信されなかった、アップリンクサブフレームの前記第１のバーストの中の転送ブロックのセットを決定するよう動作可能であり、
第２のＬＢＴ手順で前記ＵＥをスケジューリングする前に、前記ＬＢＴモジュールは、前記決定された転送ブロックのセットの中の転送ブロックに関連付けられた全てのＨＡＲＱプロセス識別子を使用してアップリンクフレームの第２のバーストで前記ＵＥをスケジューリングするよう動作可能である
ネットワークノード。
【発明の詳細な説明】
【技術分野】
【０００１】
特定の実施形態は無線通信に関し、より詳細にはアンライセンススペクトルにおけるアップリンク送信のためのリッスンビフォアトーク（ＬＢＴ：listen before talk）パラメータのシグナリングおよび管理のための方法および装置に関するものである。
【背景技術】
【０００２】
ライセンス支援アクセス（ＬＡＡ）と呼ばれる第３世代パートナーシッププロジェクト（３ＧＰＰ）イニシアチブは、ロングタームエボリューション（ＬＴＥ）装置のアンライセンスの５ＧＨｚ無線スペクトルにおける動作を可能にする。アンライセンスの５ＧＨｚスペクトルは、ライセンススペクトルの補完に使用される。したがって、デバイスは、ライセンススペクトル（一次セル（ＰＣｅｌｌ））で接続し、キャリア集約（アグリゲーション）を使用してアンライセンススペクトル（二次セル（ＳＣｅｌｌ））により追加の伝送容量を利用することが出来る。ライセンススペクトルとアンライセンススペクトルを集約するために必要な変更を減らすために、一次セルのＬＴＥフレームタイミングが二次セルで同時に使用される。
【０００３】
スタンドアロンＬＴＥ−Ｕフォーラムおよびアップリンクライセンス支援アクセス（ＬＡＡ）に関する３ＧＰＰ  Ｒｅｌ−１４作業項目は、ＬＴＥユーザ装置（ＵＥ）がアンライセンスの５ＧＨｚまたはライセンス共有の３．５ＧＨｚ無線スペクトルのアップリンクで送信することを指定し得る。スタンドアロンＬＴＥ−Ｕの場合、ダウンリンクとアップリンクの全ての送信は完全にアンライセンススペクトルで行われる。
【０００４】
規制要件により、事前のチャネル検知なしでは、アンライセンススペクトルでの送信が許可されない場合がある。これは、アンライセンススペクトルが、類似または異なる無線テクノロジの無線と共有されているためである。無線デバイスは、リッスンビフォアトーク（ＬＢＴ）法を使用してチャネル検知を実行することができる。ＬＢＴ法は、事前に定義された最小時間量の間伝送媒体を検知することと、チャネルがビジー（使用中）である場合にバックオフすることと、を含む。
【０００５】
Ｗｉ−Ｆｉ、ＬＡＡ、およびスタンドアロンＬＴＥ−Ｕは、５ＧＨｚバンド内の複数のアンライセンスチャネルにわたる同時送信を伴うマルチキャリアモードで動作し得る。Ｗｉ−Ｆｉは、特定のチャネルボンディング規則を使用して選択された複数のキャリアにわたって階層的マルチキャリアＬＢＴ方式に従う。
【０００６】
ＬＡＡおよびスタンドアロンＬＴＥ−Ｕの場合、アップリンク送信はｅＮＢによって明示的にスケジュールされ、ｅＮＢはＵＥが送信を許可されるタイミングを完全に制御します。しかし、アンライセンススペクトルで動作しているキャリアの場合、ＵＥはキャリアで送信する前にＬＢＴの形式を実行する。ＬＢＴの形式は、スケジュールされているＵＥの数、連続してスケジュールされているサブフレームの数、キャリアでの以前の送信の長さ、および／または、他のそのような要因に依存し得る。ＬＢＴに関連するいくつかのパラメータは、ＵＥが送信前にＬＢＴを実行することができるように、ｅＮＢによってＵＥにシグナリングされ得る。しかしながら、シグナリングパラメータは、アンライセンススペクトルにおけるアップリンク送信に関して遭遇する可能性があるすべての使用事例および問題を完全に網羅するわけではない。
【０００７】
以下に説明される特定の実施形態は、これらの問題を解決しそして新しい使用事例に対処するための、より多くのシグナリング方法を含む。さらに、特定の実施形態は、アンライセンススペクトルにおけるＬＴＥの効率を高めるために使用され得るシグナリングパラメータを説明する。
【０００８】
背景として、ＬＴＥはダウンリンクにＯＦＤＭを使用し、アップリンクに離散フーリエ変換（ＤＦＴ）拡散ＯＦＤＭ（シングルキャリアＦＤＭＡとも呼ばれる）を使用する。基本的なＬＴＥダウンリンク物理リソースは、図１に示すように時間−周波数グリッドを含む。
【０００９】
図１は、例示的なＯＦＤＭシンボルを示す。横軸は時間を表し、もう一方の軸は周波数を表す。各リソース要素は、１つのＯＦＤＭシンボル間隔中の１つのＯＦＤＭサブキャリアに対応する。アップリンクサブフレームは、ダウンリンクと同じサブキャリア間隔、および時間領域においてダウンリンクにおけるＯＦＤＭシンボルと同数のＳＣ−ＦＤＭＡシンボルを有する。時間領域では、ＬＴＥダウンリンク送信は無線フレームに編成される。
【００１０】
図２は、例示的な無線フレームを示す。各無線フレームは１０ｍｓであり、長さＴsubframe＝１ｍｓの１０個の等サイズのサブフレームから構成される。通常のサイクリックプレフィックスの場合、１つのサブフレームは１４個のＯＦＤＭシンボルから構成される。各シンボルの長さは約７１．４μｓである。
【００１１】
ＬＴＥにおけるリソース割り当ては、通常、リソースブロックに関して説明され、リソースブロックは、時間領域では１スロット（０．５ｍｓ）に対応し、周波数領域では１２個の連続するサブキャリアに対応する。時間方向（１．０ｍｓ）に隣接する２つのリソースブロックのペアは、リソースブロックペアとして知られている。リソースブロックは周波数領域で番号が付けられ、システムバンド幅の一方の端から０から始まる。
【００１２】
ダウンリンク送信は動的にスケジュールされる。各サブフレームにおいて、基地局は、現在のダウンリンクサブフレームにおいて、どの端末にデータが送信されどのリソースブロックでデータが送信されるかについての制御情報を送信する。この制御シグナリングは通常、各サブフレーム内の最初の１、２、３または４個のＯＦＤＭシンボルで送信され、数ｎ＝１、２、３または４は制御フォーマットインジケータ（ＣＦＩ）として知られている。ダウンリンクサブフレームは、受信機に知られコヒーレント復調に使用される共通の参照シンボル（例えば、制御情報）も含む。
【００１３】
図３は、例示的なダウンリンクサブフレームを示す。サブフレームは、参照シンボルと制御シグナリングとを含む。図示された例では、制御領域は３個のＯＦＤＭシンボルを含む（すなわち、ＣＦＩ＝３）。参照シンボルはセル固有参照シンボル（ＣＲＳ）を含み、セル固有参照シンボル（ＣＲＳ）は特定の送信モードのための微細な時間および周波数同期およびチャネル推定を含む複数の機能をサポートすることができる。
【００１４】
ＬＴＥ  Ｒｅｌ−８からＲｅｌ−１０では、基地局は物理ダウンリンク制御チャネル（ＰＤＣＣＨ）を使用してダウンリンク送信をスケジュールする。ＬＴＥ  Ｒｅｌ−１１以降では、拡張物理ダウンリンク制御チャネル（ＥＰＤＣＣＨ）上でダウンリンク送信もスケジュールされることがある。
【００１５】
ＰＤＣＣＨ／ＥＰＤＣＣＨは、スケジューリング決定および電力制御コマンドなどのダウンリンク制御情報（ＤＣＩ）を搬送する。例えば、ＤＣＩは、物理ダウンリンク共有チャネル（ＰＤＳＣＨ）リソース指示、伝送フォーマット、ハイブリッドＡＲＱ情報、および空間多重化（該当する場合）に関連する制御情報などのダウンリンクスケジューリング割り当てを含む。ダウンリンクスケジューリング割り当ては、ダウンリンクスケジューリング割り当てに応答するハイブリッドＡＲＱ（ＨＡＲＱ）肯定応答の送信に使用される物理アップリンク制御チャネル（ＰＵＣＣＨ）の電力制御のためのコマンドも含む。ＤＣＩはまた、物理アップリンク共有チャネル（ＰＵＳＣＨ）リソース指示、伝送フォーマット、およびハイブリッドＡＲＱ関連情報などのアップリンクスケジューリング許可を含み得る。アップリンクスケジューリング許可はまた、ＰＵＳＣＨの電力制御のためのコマンドを含む。ＤＣＩはまた、スケジューリング割り当て／許可に含まれるコマンドを補完するものとして端末のセットに対する電力制御コマンドを含むことができる。
【００１６】
１つのＰＤＣＣＨ／ＥＰＤＣＣＨは、上記の情報グループのうちの１つを含む１つのＤＣＩメッセージを搬送する。基地局は複数の端末を同時にスケジュールすることができ、各端末はダウンリンクとアップリンクの両方で同時にスケジュールされることがあるので、複数のスケジューリングメッセージが各サブフレーム内で送信されることがある。各スケジューリングメッセージは別々のＰＤＣＣＨ／ＥＰＤＣＣＨリソースで送信される。その結果、複数の同時ＰＤＣＣＨ／ＥＰＤＣＣＨ送信は、通常、各セル内の各サブフレーム内にある。さらに、異なる無線チャネル状態のサポートがリンク適応を使用し得る。リンク適応では、ＰＤＣＣＨ／ＥＰＤＣＣＨの符号化率は、無線チャネル条件に一致するようにＰＤＣＣＨ／ＥＰＤＣＣＨのリソース使用量を適応させることによって選択される。
【００１７】
ＬＴＥでは、ｅＮＢは、アップリンク送信スケジューリングコマンドをＵＥに送信する。ＬＴＥ規格は、スケジューリングコマンドが送信される時間とＵＥがアップリンク信号を送信する時間との間の固定遅延を規定している。この遅延は、ＰＤＣＣＨ／ＥＰＤＣＣＨを復号し、アップリンク信号を送信する準備をするためのＵＥ時間を提供する。周波数分割多重（ＦＤＤ）サービングセルの場合、アップリンク許可遅延は４ｍｓである。時分割多重（ＴＤＤ）サービングセルの場合、アップリンク許可遅延は４ｍｓを超えることがある。
【００１８】
ＬＴＥ  Ｒｅｌ−１０規格以上は、２０ＭＨｚを超えるバンド幅をサポートする。ＬＴＥ  Ｒｅｌ−１０の１つの要件は、ＬＴＥ  Ｒｅｌ−８との後方互換性である。これはスペクトルの互換性を含む。互換性を提供するための１つの方法は、２０ＭＨｚよりも広いＬＴＥ  Ｒｅｌ−１０キャリアが、ＬＴＥ  Ｒｅｌ−８端末にとってのいくつかのＬＴＥキャリアとして現れることである。そのような各キャリアは、コンポーネントキャリア（ＣＣ）と呼ばれることがある。
【００１９】
初期のＬＴＥ  Ｒｅｌ−１０配備では、ＬＴＥ  Ｒｅｌ−１０対応端末の数は、既に存在しているＬＴＥレガシー端末の数よりおそらく少ない。したがって、ワイドキャリアの効率的な使用が（すなわちワイドバンドＬＴＥ  Ｒｅｌ−１０キャリアの全ての部分においてレガシー端末がスケジュールされ得るキャリアを提供するため）レガシー端末に必要とされる。１つの解決策はキャリアアグリゲーションを使用する。キャリアアグリゲーションを使用して、ＬＴＥ  Ｒｅｌ−１０端末は複数のコンポーネントキャリアを受信することができる。コンポーネントキャリアは、Ｒｅｌ−８キャリアと同じ構造を有し得る。
【００２０】
図４は、キャリアアグリゲーションの一例を示す。１００ＭＨｚのシステムバンド幅は、それぞれ２０ＭＨｚのバンド幅を有する５つのコンポーネントキャリアによって表され得る。キャリアアグリゲーションが可能なＵＥは、常にアクティブにされる一次セル（ＰＣｅｌｌ）と、動的にアクティブまたは非アクティブにされ得る１つまたは複数の二次セル（ＳＣｅｌｌ）とを割り当てられ得る。
【００２１】
集約されたコンポーネントキャリアの数ならびに個々のコンポーネントキャリアのバンド幅は、アップリンクとダウンリンクとでは異なり得る。対称構成は、ダウンリンクにおけるコンポーネントキャリアの数がアップリンクにおけるものと同じである構成を指す。非対称構成とは、ダウンリンクとアップリンクでコンポーネントキャリアの数が異なる構成を指す。セル内に構成されたコンポーネントキャリアの数は、端末から見たコンポーネントキャリアの数とは異なり得る。例えば、セルが同じ数のアップリンクおよびダウンリンクコンポーネントキャリアで構成されていても、端末はアップリンクコンポーネントキャリアより多くのダウンリンクコンポーネントキャリアをサポートすることができる。
【００２２】
キャリアアグリゲーションのもう１つの機能は、クロスキャリアスケジューリングを実行できることである。クロスキャリアスケジューリングは、（Ｅ）ＰＤＣＣＨメッセージの先頭に挿入された３ビットのキャリアインジケータフィールド（ＣＩＦ）を使用して、あるコンポーネントキャリア上の（Ｅ）ＰＤＣＣＨが別のコンポーネントキャリア上のデータ送信をスケジュールすることを可能にする。所与のコンポーネントキャリア上のデータ送信のために、ＵＥは、ただ１つのコンポーネントキャリア（すなわち、同じコンポーネントキャリア、またはクロスキャリアスケジューリングを介した異なるコンポーネントキャリア）の（Ｅ）ＰＤＣＣＨ上でスケジューリングメッセージを受信することを予測する。（Ｅ）ＰＤＣＣＨからＰＤＳＣＨへのマッピングは準静的に構成され得る。
【００２３】
アンライセンススペクトルをＬＴＥと共有する別の無線ネットワーク技術は、無線ローカルエリアネットワーク（ＷＬＡＮ）である。典型的なＷＬＡＮ配備は、媒体アクセスに対して衝突回避付きキャリ検知多重アクセス（ＣＳＭＡ／ＣＡ）を使用する。これは、クリアチャネルアセスメント（ＣＣＡ）を実行するためにチャネルが検知され、チャネルがアイドルであると決定された場合にのみ送信が開始されることを意味する。チャネルがビジーであると決定された場合、チャネルがアイドル状態になるまで送信は延期される。同じ周波数を使用している複数のアクセスポイントの範囲が重なっている場合、範囲内にある別のアクセスポイントへの／からの送信が同じ周波数で検出されると、あるアクセスポイントに関連するすべての送信が延期される。効果的には、複数のアクセスポイントが互いの範囲内にある場合、それらは時間においてチャネルを共有する必要があり、個々のアクセスポイントのスループットは大幅に低下する可能性がある。単一のアンライセンスチャネル上のリッスンビフォアトーク（ＬＢＴ）メカニズムの概略図が図５に示されている。
【００２４】
図５は、例示的なＷＬＡＮリッスンビフォアトークメカニズムを示す。単一チャネルＬＢＴの場合、第１のＷｉ−Ｆｉ局が第２のＷｉ−Ｆｉ局にデータフレームを送信した後、第２の局は１６μｓの遅延でＡＣＫフレームを第１の局に返信する。ＡＣＫフレームは、ＬＢＴ動作を実行することなく第２の局によって送信される。他の局がＡＣＫフレーム送信を妨害するのを防ぐために、局は、チャネルが占有されていることが観察された後、チャネルが占有されているかどうかを再び検知する前に、３４μｓの継続時間（ＤＩＦＳと呼ばれる）だけ延期する。
【００２５】
したがって、送信を希望する局は、最初に、固定継続時間ＤＩＦＳの間媒体を検知することによってクリアチャネルアセスメントを実行する。媒体がアイドルである場合、局は、媒体の所有権を取得すると仮定してフレーム交換シーケンスを開始する。媒体がビジーである場合、局は媒体がアイドルになるのを待ち、ＤＩＦＳを延期し、さらにランダムなバックオフ期間を待機する。局がチャネルを継続的に占有するのを防ぎそれによって他の局がチャネルにアクセスするのを防ぐために、送信が成功した後、局は再び送信する前にランダムバックオフを実行する。
【００２６】
マルチキャリア動作の場合、Ｗｉ−Ｆｉは階層チャネルボンディング方式を使用して、例えば２０ＭＨｚ、４０ＭＨｚ、８０ＭＨｚ、または１６０ＭＨｚなどの、フレームの送信バンド幅を決定する。５ＧＨｚバンドでは、４０ＭＨｚ、８０ＭＨｚ、１６０ＭＨｚ、または８０＋８０ＭＨｚのより広いＷｉ−Ｆｉチャネル幅が、２０ＭＨｚサブチャネルを重ならないように組み合わせることによって形成される。所定の一次チャネルは、必要に応じて、遅延期間の後に競合（コンテンション）ウィンドウベースのランダムアクセス手順を実行し、次いで生成された乱数をカウントダウンする。二次チャネルは、追加の二次チャネルが送信に利用可能かどうかを判断するために、潜在的な送信開始の前にＰＩＦＳ継続時間（一般に２５μｓ）の間、迅速なＣＣＡチェックを実行する。二次ＣＣＡチェックの結果に基づいて、送信はより広いバンド幅で実行され、そうでなければ、伝送はより狭いバンド幅にフォールバックする。Ｗｉ−Ｆｉ一次チャネルは常にすべての送信に含まれる（すなわち、二次チャネル単独での送信は許可されない）。
【００２７】
ＬＴＥは伝統的に専用の周波数スペクトルを使用してきた。専用スペクトルの利点は、ＬＴＥシステムが、同じスペクトル内で他の３ＧＰＰ無線アクセス技術以外と共存する必要がないことであり、スペクトル効率が最大化することが出来ることである。しかしながら、ＬＴＥに割り当てられるスペクトルは限られている。こでは、アプリケーション／サービスからのより大きなスループットに対する増大し続ける要求を満たすことはできないかもしれない。それゆえ、３ＧＰＰはまた、ＬＴＥがライセンススペクトルに加えてアンライセンススペクトルをどのように使用することができるかを規定する。さらに、スタンドアロンＬＴＥ−Ｕはマルテファイアアライアンス（MulteFireAlliance）によって開発中であり、ＬＴＥはライセンスのないスペクトルでのみ動作します。
【００２８】
図６は、アンライセンススペクトルへのライセンス支援アクセスを有するユーザ装置を示す。ライセンス支援アクセスでは、ＵＥはライセンスバンド内のＰＣｅｌｌとアンライセンスバンド内の１つ以上のＳＣｅｌｌに接続される。アンライセンススペクトルの二次セルは、ＬＡＡ二次セル（ＬＡＡ  ＳＣｅｌｌ）と呼ばれることがある。ＬＡＡ  ＳＣｅｌｌは、ダウンリンク専用モードで動作してもよく、またはアップリンクトラフィックとダウンリンクトラフィックの両方で動作してもよい。いくつかのシナリオでは、ＬＴＥノードは、ライセンスセルからの支援なしにライセンス免除チャネルにおいてスタンドアロンモードで動作し得る。
【００２９】
アンライセンススペクトルは、定義により、複数の異なる技術によって同時に使用され得る。したがって、ＬＡＡは、ＩＥＥＥ８０２．１１（Ｗｉ−Ｆｉ）などの他のシステムと共存し協調しなければならない。Ｗｉ−Ｆｉシステムと公平に共存するために、ＳＣｅｌｌでの送信は、進行中の送信に深刻な干渉を引き起こす可能性がある衝突を回避するために、ＬＢＴプロトコルに準拠する。これには、送信を開始する前にＬＢＴを実行することと、単一送信バーストの最大継続時間を制限することの両方が含まれる。最大送信バースト継続時間は、国および地域固有の規制によって規定されている（たとえば、日本では４ｍｓ、ＥＮ３０１．８９３によると１３ｍｓ）。一例が図７に示される。
【００３０】
図７は、アップリンクのリッスンビフォアトークプロトコルに基づくアップリンクのライセンス支援アクセス送信の例を示す。この例は、４ｍｓの最大許容送信継続時間によって制約されたＬＡＡ  ＳＣｅｌｌ上の送信バーストの継続時間を示す。例えば、この図は、８ｍｓの占有時間を、ダウンリンクチャネル占有の４ｍｓとアップリンクチャネル占有の４ｍｓとに分割する。
【００３１】
ｅＮＢは、ダウンリンクでデータを送信する前に、チャネルアクセスを獲得するためにＬＢＴを実行する。ｅＮＢの送信継続時間中に、また、特定のＵＥが特定の時間後にアップリンクで送信するようスケジュールするために制御チャネルを送信する。ｅＮＢがチャネルを解放した後、スケジュールされたＵＥは、上述の特定の時間にチャネルで送信できるかどうかを判断するためにＬＢＴを実行する。例えば、サブフレームｎ−４からｎ−１（すなわち、４ｍｓ）でダウンリンク送信を受信した後、ＵＥはサブフレームｎでアップリンクのためのクリアチャネルアクセスを実行する。チャネルが空いている場合、ＵＥはサブフレームｎからｎ＋３（すなわち、４ｍｓ）の間アップリンクで送信する。
【００３２】
ｅＮＢがアンライセンススペクトルで送信する機会を取得すると、その機会（送信機会（ＴＸＯＰ）とも呼ばれる）は、ｅＮＢがサービス提供しているＵＥと共有され得る。ｅＮＢからの送信とＵＥからの送信との間の遷移は、２つの方法、すなわち、ＵＥが送信前にＬＢＴ動作を実行する方法と、ＵＥがＬＢＴ動作を実行しない方法とで処理され得る。
【００３３】
ＬＢＴ動作が実行されない場合は、（ｅＮＢからの）ダウンリンク送信と（ＵＥからの）アップリンク送信との間のギャップが１６μｓ以下であることを必要とする可能性が最も高い。特定のサブフレームに対してＬＢＴ動作が実行される場合、同じサービングセル内の他のＵＥからの送信によって干渉されることなくＵＥがリッスンビフォアトーク動作を実行することを可能にするために、ギャップがアップリンクサブフレームに挿入される必要がある。アップリンクスループットの著しい低下を避けるために、ギャップは大きすぎてはならない。したがって、１４個のＤＦＴ拡散ＯＦＤＭ（ＤＦＴＳ−ＯＦＤＭ）シンボルのアップリンクサブフレーム内のギャップは、継続時間が約７１μｓである１つのＤＦＴＳ−ＯＦＤＭシンボルよりも大きくない可能性が高い。
【００３４】
ＬＢＴを実行することは、一般に、２つの広いカテゴリのＬＢＴ操作を含み得る。第１のタイプは、ＩＥＥＥ８０２．１１準拠ノードによって使用されるものと同様の完全ランダムバックオフを伴うＬＢＴ手順を使用する。これらのスキームはカテゴリ４ＬＢＴスキームとも呼ばれる。
【００３５】
これらの方式では、ランダムバックオフカウンタが期間｛０，ＣＷ｝の中で一様にランダムに取り出される。ここで、ＣＷは競合ウィンドウである。競合ウィンドウのサイズは、チャネル上で衝突が検出されるたびに約２倍になる可能性がある。したがって、この手順はまた、二進指数バックオフと呼ばれることもある。
【００３６】
競合ウィンドウサイズは、最小値ＣＷｍｉｎと最大値ＣＷｍａｘによって制限される。ＣＷｍｉｎとＣＷｍａｘの値は、トラフィックの優先度クラスによって異なる。最も高い優先度クラスでは、｛ＣＷｍｉｎ，ＣＷｍａｘ｝の値は｛３，７｝に制限され得、これらの数字は、図５に示すように、９μｓの継続時間を持つ１スロットのインクリメントでカウントされる。４つのクラスが定義されている。残りの３つの優先度クラスは、アクセスポイント（ＡＰ）またはｅＮＢのために、それぞれ、｛７，１５｝、｛１５，６３｝、｛１５，１０２３｝の競合ウィンドウサイズのペアを使用する。Ｗｉ−ＦｉのＳＴＡまたはＬＴＥのＵＥの場合、｛１５，６３｝の値は使用されない。
【００３７】
第２のタイプのＬＢＴ手順では、ＵＥは、固定継続時間（例えば、２５μｓ）の間ＬＢＴ動作を実行することができる。一般に、第２のタイプのＬＢＴは、別のノードがＬＢＴ動作を完了してチャネル上で送信を開始する確率を最小にするので、ダウンリンク送信とアップリンク送信との間の遷移に好ましい。ただし、多くの場合、カテゴリ４ＬＢＴスキームを使用する必要がある。
【００３８】
ダウンリンク送信とアップリンク送信との間のギャップを最小にする１つの技術は、タイミングアドバンスコマンドを使用してアップリンク上のＵＥ送信のタイミングを早め、それらがより早く起こるようにすることである。この技術は、ｅＮＢが送信バーストの最後のダウンリンクサブフレーム内のサブフレームの一部にわたってのみ送信を使用することができる場合に使用され得る。この場合、タイミングアドバンス（ＴＡ）コマンドを受信したＵＥによるアップリンク送信によって占有される可能性があるダウンリンクサブフレーム内にギャップがある。
【００３９】
Ｒｅｌ−１０で導入されたＬＴＥキャリアアグリゲーション（ＣＡ）の使用は、同じバンドまたは異なるバンドに存在する可能性がある複数のキャリアからの無線リソースを集約することによってピークデータレート、システム容量、およびユーザエクスペリエンスを向上させることができる。Ｒｅｌ−１３  ＬＡＡとスタンドアロンＬＴＥ−Ｕは、アンライセンススペクトルで同時に複数のキャリアで動作する機能を提供する。５キャリアを超えるＣＡフレームワークの拡張はＬＴＥ  Ｒｅｌ−１３で完了し、アップリンクとダウンリンクの両方で最大３２のキャリアをサポートする。
【００４０】
３ＧＰＰ仕様は、Ｒｅｌ−１４  ＬＡＡのためのマルチサブフレームスケジューリングを含むことができ、単一のサブフレームで送信される１つまたは複数のアップリンク許可が複数のサブフレームのアップリンクデータをスケジュールすることができる。マルチサブフレームスケジューリング許可の一部としてシグナリングされるパラメータは、ハイブリッドＡＲＱ肯定応答（ＨＡＲＱ−ＡＣＫ）および関連パラメータを含む。具体的には、許可は、レガシーパラメータ（すなわち、一般に肯定応答される転送ブロックごとに１ビットから構成される、新規データインジケータ（ＮＤＩ）、冗長バージョン（ＲＶ）、およびＨＡＲＱ−ＡＣＫビット自体）を含む。
【００４１】
ＬＡＡに対するＬＢＴパラメータのシグナリングは、明示的方法と暗黙的方法の両方を使用することができる。解決策は、ランダムバックオフカウンタ、競合ウィンドウサイズ、および使用されるＬＢＴ優先度クラスなどのランダムバックオフパラメータのシグナリングを含む。これらのパラメータのシグナリングは、単一のサブフレーム内で多重化されている負荷およびＵＥのセットなどの要因に応じて異なり得る。使用されるべきＬＢＴ優先度クラスの暗黙的シグナリングは、ＵＥにスケジュールされた連続したサブフレームの数を含む様々な要因に基づくことができる。ＵＥで使用されるべき競合ウィンドウサイズはまた、送信が新しい送信であるか再送信であるかを示すことによって暗示的にシグナリングされ得る。
【００４２】
しかしながら、既存のシグナリングおよび競合ウィンドウ管理方法は、ＵＥが使用しなければならない競合ウィンドウサイズを示すために暗黙的シグナリングを使用するときに生じる問題を完全には説明していない。明示的シグナリングが使用されるとき、それは不必要に大きいシグナリングオーバーヘッドを生み出す。
【発明の概要】
【００４３】
本明細書で説明される実施形態は、競合ウィンドウの管理に関する要件が満たされることを確実にしながら、カテゴリ４ＬＢＴ方式のリッスンビフォアトーク（ＬＢＴ）パラメータをユーザ装置（ＵＥ）に効率的にシグナリングすることを含む。機能を有効にするためのシグナリングが開示されている。一般に、競合ウィンドウの調整は、送信開始時に経験した無線状態に基づいている。たとえば、成功したカテゴリ４ＬＢＴの後の送信で衝突が発生した場合、次のカテゴリ４ＬＢＴの試行に対して対応する競合ウィンドウサイズが増加する。
【００４４】
いくつかの実施形態は、以下の要素を有するＵＥにおける競合ウィンドウ管理を伴う暗黙的シグナリングを含む。（１）以前にスケジュールされたバーストにおいて情報が利用可能であるＨＡＲＱプロセスのためのＮＤＩビットの使用、（２）ＵＥに対して以前にスケジュールされたバーストのサブフレームに対するＬＢＴの失敗または成功に関するＵＥの知識の使用。以下の実施形態は、特定のアップリンクサブフレームにおいてＵＥによって使用されるカテゴリ４ＬＢＴ方式の競合ウィンドウサイズを管理することを含む。
【００４５】
いくつかの実施形態によれば、リッスンビフォアトーク（ＬＢＴ）競合ウィンドウサイズを管理するためのユーザ装置（ＵＥ）において使用される方法は、第１のＬＢＴ手順の後にアップリンクサブフレームの第１のバーストを送信することを含む。ＬＢＴ手順はＬＢＴ競合ウィンドウサイズを使用して実行される。方法は、更に、アップリンクサブフレームの前記第１のバーストに基づいて参照サブフレームを決定することを含む。前記参照サブフレームは参照ハイブリッド自動再送要求（ＨＡＲＱ）プロセス識別子に関連付けられている。方法は、更に、アップリンクサブフレームの第２のバーストに対するスケジューリングを受信することを含む。前記スケジューリングは、アップリンクサブフレームの前記第２のバーストの各サブフレームについて、関連するＨＡＲＱプロセス識別子および関連する新規データインジケータ（ＮＤＩ）を含む。前記ＵＥがアップリンクサブフレームの前記第２のバーストのサブフレームのうちの少なくとも１つに関連付けられたＨＡＲＱプロセス識別子が前記参照ＨＡＲＱプロセス識別子と一致しかつ前記関連付けられたＮＤＩが新規のデータを示すと決定したとき、方法は、前記ＬＢＴ競合ウィンドウサイズを最小値にリセットする。前記ＵＥがアップリンクサブフレームの前記第２のバーストのサブフレームのうちの少なくとも１つに関連付けられたＨＡＲＱプロセス識別子が前記参照ＨＡＲＱプロセス識別子と一致しかつ前記関連付けられたＮＤＩが再送信を示すと決定したとき、前記方法は、前記ＬＢＴ競合ウィンドウサイズをインクリメントする。方法は、更に、前記競合ウィンドウサイズを使用して第２のＬＢＴ手順を実行することを含む。
【００４６】
特定の実施形態では、前記参照サブフレームを前記決定することは、前記関連するＨＡＲＱプロセス識別子がアップリンクサブフレームの前記第２のバーストに対する前記受信されたスケジューリングにおいても見出される、アップリンクサブフレームの前記第１のバーストにおいて最も最近送信されたアップリンクサブフレームを決定することを含む。
【００４７】
特定の実施形態では、前記参照サブフレームを前記決定することは、アップリンクサブフレームの前記第１のバーストにおける第１のサブフレームに関連付けられた前記ＨＡＲＱプロセス識別子がアップリンクサブフレームの前記第２のバーストに対する前記受信されたスケジューリングにおいても見出される、アップリンクサブフレームの前記第１のバーストにおいて最初に送信されたサブフレームを決定することを含む。
【００４８】
特定の実施形態では、前記第１のバーストの送信は、前記参照サブフレームを前記決定する前に閾値時間（例えば、４ｍｓ）を超えて終了する。
【００４９】
特定の実施形態では、前記ＬＢＴ競合ウィンドウサイズを最小値に前記リセットすることは、前記ＬＢＴ競合ウィンドウサイズを、前記第１のＬＢＴ手順を実行するために前記ＵＥによって使用される優先度クラスに関連する値のセットの最小値にリセットすることを含む。前記ＬＢＴ競合ウィンドウサイズを最小値に前記リセットすることは、前記ＵＥによって使用される全ての優先度クラスに関連するＬＢＴ競合ウィンドウサイズをリセットすることを含み得る。
【００５０】
特定の実施形態では、前記ＬＢＴ競合ウィンドウサイズを前記インクリメントすることは、前記ＬＢＴ競合ウィンドウサイズを、前記第１のＬＢＴ手順を実行するために前記ＵＥによって使用される優先度クラスに関連する値のセットの中の次の値までインクリメントすることを含む。前記ＬＢＴ競合ウィンドウサイズを前記インクリメントすることは、前記ＵＥによって使用される全ての優先度クラスに関連するＬＢＴ競合ウィンドウサイズをインクリメントすることを含み得る。
【００５１】
特定の実施形態では、前記参照サブフレームは複数のＨＡＲＱプロセス識別子と関連付けられ、前記ＬＢＴ競合ウィンドウサイズは、前記複数のＨＡＲＱプロセス識別子の各ＨＡＲＱプロセス識別子に関連付けられた前記ＮＤＩが再送信を示すときインクリメントされる。いくつかの実施形態では、前記ＬＢＴ競合ウィンドウサイズは、前記複数のＨＡＲＱプロセス識別子のＨＡＲＱプロセス識別子に関連付けられた少なくとも１つのＮＤＩが新規のデータを示すときリセットされる。
【００５２】
特定の実施形態において、前記第２のＬＢＴ手順を前記実行することは、ライセンス支援アクセス（ＬＡＡ）の二次セル上の物理アップリンク共有チャネル（ＰＵＳＣＨ）送信に対するカテゴリ４ＬＢＴを実行することを含む。
【００５３】
いくつかの実施形態によれば、ＬＢＴ競合ウィンドウサイズを管理するように動作可能なＵＥは、第１のＬＢＴ手順の後にアップリンクサブフレームの第１のバーストを送信するよう動作可能な処理回路を含む。ＬＢＴ手順はＬＢＴ競合ウィンドウサイズを使用して実行される。処理回路は、更に、アップリンクサブフレームの前記第１のバーストに基づいて参照サブフレームを決定するよう動作可能である。前記参照サブフレームは参照ＨＡＲＱプロセス識別子に関連付けられている。処理回路は、更に、アップリンクサブフレームの第２のバーストに対するスケジューリングを受信するよう動作可能である。前記スケジューリングは、アップリンクサブフレームの前記第２のバーストの各サブフレームについて、関連するＨＡＲＱプロセス識別子および関連するＮＤＩを含む。前記ＵＥがアップリンクサブフレームの前記第２のバーストのサブフレームのうちの少なくとも１つに関連付けられたＨＡＲＱプロセス識別子が前記参照ＨＡＲＱプロセス識別子と一致しかつ前記関連付けられたＮＤＩが新規のデータを示すと決定したとき、処理回路は、前記ＬＢＴ競合ウィンドウサイズを最小値にリセットするよう動作可能である。前記ＵＥがアップリンクサブフレームの前記第２のバーストのサブフレームのうちの少なくとも１つに関連付けられたＨＡＲＱプロセス識別子が前記参照ＨＡＲＱプロセス識別子と一致しかつ前記関連付けられたＮＤＩが再送信を示すと決定したとき、処理回路は、前記ＬＢＴ競合ウィンドウサイズをインクリメントするよう動作可能である。処理回路は、更に、前記競合ウィンドウサイズを使用して第２のＬＢＴ手順を実行するよう動作可能である。
【００５４】
特定の実施形態において、前記処理回路は、前記関連するＨＡＲＱプロセス識別子がアップリンクサブフレームの前記第２のバーストに対する前記受信されたスケジューリングにおいても見出される、アップリンクサブフレームの前記第１のバーストにおいて最も最近送信されたアップリンクサブフレームを決定することにより、前記参照サブフレームを決定するよう動作可能である。
【００５５】
特定の実施形態では、前記処理回路は、アップリンクサブフレームの前記第１のバーストにおける第１のサブフレームに関連付けられた前記ＨＡＲＱプロセス識別子がアップリンクサブフレームの前記第２のバーストに対する前記受信されたスケジューリングにおいても見出される、アップリンクサブフレームの前記第１のバーストにおいて最初に送信されたサブフレームを決定することにより、前記参照サブフレームを決定するよう動作可能である。
【００５６】
特定の実施形態では、前記第１のバーストの送信は、前記参照サブフレームを前記決定する前に閾値時間（例えば、４ｍｓ）を超えて終了する。
【００５７】
特定の実施形態では、前記処理回路は、前記ＬＢＴ競合ウィンドウサイズを、前記第１のＬＢＴ手順を実行するために前記ＵＥによって使用される優先度クラスに関連する値のセットの最小値にリセットすることにより、前記ＬＢＴ競合ウィンドウサイズを最小値にリセットするよう動作可能である。いくつかの実施形態では、前記処理回路は、前記ＵＥによって使用される全ての優先度クラスに関連するＬＢＴ競合ウィンドウサイズをリセットすることにより、前記ＬＢＴ競合ウィンドウサイズを最小値にリセットするよう動作可能である。
【００５８】
特定の実施形態では、前記処理回路は、前記ＬＢＴ競合ウィンドウサイズを、前記第１のＬＢＴ手順を実行するために前記ＵＥによって使用される優先度クラスに関連する値のセットの中の次の値までインクリメントすることにより、前記ＬＢＴ競合ウィンドウサイズをインクリメントするよう動作可能である。いくつかの実施形態では、前記処理回路は、前記ＵＥによって使用される全ての優先度クラスに関連するＬＢＴ競合ウィンドウサイズをインクリメントすることにより、前記ＬＢＴ競合ウィンドウサイズをインクリメントするよう動作可能である。
【００５９】
特定の実施形態では、前記参照サブフレームは複数のＨＡＲＱプロセス識別子と関連付けられ、前記ＬＢＴ競合ウィンドウサイズは、前記複数のＨＡＲＱプロセス識別子の各ＨＡＲＱプロセス識別子に関連付けられた前記ＮＤＩが再送信を示すときインクリメントされる。いくつかの実施形態では、前記ＬＢＴ競合ウィンドウサイズは、前記複数のＨＡＲＱプロセス識別子のＨＡＲＱプロセス識別子に関連付けられた少なくとも１つのＮＤＩが新規のデータを示すときリセットされる。
【００６０】
特定の実施形態において、前記処理回路は、ＬＡＡの二次セル上のＰＵＳＣＨ送信に対するカテゴリ４ＬＢＴを実行することにより、前記第２のＬＢＴ手順を実行するよう動作可能である。
【００６１】
いくつかの実施形態によれば、ネットワークノードにおいて使用されるＬＢＴパラメータのシグナリングの方法は、第１のＬＢＴ手順の後に、アップリンクサブフレームの第１のバーストをＵＥから受信することを含む。アップリンクサブフレームの前記第１のバーストの各サブフレームは１つまたは複数の転送ブロックに関連付けられており、各転送ブロックはＨＡＲＱプロセス識別子に関連付けられている。方法は、更に、前記ネットワークノードによって正常に受信されなかった、アップリンクサブフレームの前記第１のバーストの中の転送ブロックのセットを決定することを含む。第２のＬＢＴ手順で前記ＵＥをスケジューリングする前に、方法は、更に、前記決定された転送ブロックのセットの中の転送ブロックに関連付けられた全てのＨＡＲＱプロセス識別子を使用してアップリンクフレームの第２のバーストで前記ＵＥをスケジューリングすることを含む。
【００６２】
特定の実施形態では、前記ネットワークノードによって正常に受信されなかった、アップリンクサブフレームの前記第１のバーストの中の転送ブロックのセットを前記決定することは、少なくとも１つの転送ブロックが首尾よく受信された受信サブフレームの前の最後のサブフレームに基づいて参照サブフレームを決定することを含む。転送ブロックの前記セットは、正常に受信されなかった前記参照サブフレームの中の転送ブロックを含む。
【００６３】
いくつかの実施形態によれば、ＬＢＴパラメータをシグナリングするように動作可能なネットワークノードは、第１のＬＢＴ手順の後に、アップリンクサブフレームの第１のバーストをＵＥから受信するよう動作可能な処理回路を含む。アップリンクサブフレームの前記第１のバーストの各サブフレームは１つまたは複数の転送ブロックに関連付けられており、各転送ブロックはＨＡＲＱプロセス識別子に関連付けられている。処理回路は、更に、前記ネットワークノードによって正常に受信されなかった、アップリンクサブフレームの前記第１のバーストの中の転送ブロックのセットを決定するよう動作可能である。第２のＬＢＴ手順で前記ＵＥをスケジューリングする前に、処理回路は、更に、前記決定された転送ブロックのセットの中の転送ブロックに関連付けられた全てのＨＡＲＱプロセス識別子を使用してアップリンクフレームの第２のバーストで前記ＵＥをスケジューリングするよう動作可能である。
【００６４】
特定の実施形態では、処理回路は、少なくとも１つの転送ブロックが首尾よく受信された受信サブフレームの前の最後のサブフレームに基づいて参照サブフレームを決定するよう動作可能である。転送ブロックの前記セットは、正常に受信されなかった前記参照サブフレームの中の転送ブロックを含む。
【００６５】
いくつかの実施形態によれば、ＬＢＴ競合ウィンドウサイズを管理するように動作可能なＵＥは、送信モジュールと決定モジュールと受信モジュールとＬＢＴモジュールとを有する。前記送信モジュールは、第１のＬＢＴ手順の後にアップリンクサブフレームの第１のバーストを送信するよう動作可能である。ＬＢＴ手順はＬＢＴ競合ウィンドウサイズを使用して実行される。前記決定モジュールは、アップリンクサブフレームの前記第１のバーストに基づいて参照サブフレームを決定するよう動作可能である。前記参照サブフレームは参照ＨＡＲＱプロセス識別子に関連付けられている。前記受信モジュールは、アップリンクサブフレームの第２のバーストに対するスケジューリングを受信するよう動作可能である。前記スケジューリングは、アップリンクサブフレームの前記第２のバーストの各サブフレームについて、関連するＨＡＲＱプロセス識別子および関連するＮＤＩを含む。前記ＵＥがアップリンクサブフレームの前記第２のバーストのサブフレームのうちの少なくとも１つに関連付けられたＨＡＲＱプロセス識別子が前記参照ＨＡＲＱプロセス識別子と一致しかつ前記関連付けられたＮＤＩが新規のデータを示すと決定したとき、前記ＬＢＴモジュールは、前記ＬＢＴ競合ウィンドウサイズを最小値にリセットするよう動作可能である。前記ＵＥがアップリンクサブフレームの前記第２のバーストのサブフレームのうちの少なくとも１つに関連付けられたＨＡＲＱプロセス識別子が前記参照ＨＡＲＱプロセス識別子と一致しかつ前記関連付けられたＮＤＩが再送信を示すと決定したとき、前記ＬＢＴモジュールは、前記ＬＢＴ競合ウィンドウサイズをインクリメントするよう動作可能である。前記ＬＢＴモジュールは、前記競合ウィンドウサイズを使用して第２のＬＢＴ手順を実行するよう更に動作可能である。
【００６６】
いくつかの実施形態によれば、ＬＢＴパラメータをシグナリングするように動作可能なネットワークノードは、受信モジュールと決定モジュールとＬＢＴモジュールとを有する。前記受信モジュールは、第１のＬＢＴ手順の後に、アップリンクサブフレームの第１のバーストをＵＥから受信するよう動作可能である。アップリンクサブフレームの前記第１のバーストの各サブフレームは１つまたは複数の転送ブロックに関連付けられており、各転送ブロックはＨＡＲＱプロセス識別子に関連付けられている。前記決定モジュールは、前記ネットワークノードによって正常に受信されなかった、アップリンクサブフレームの前記第１のバーストの中の転送ブロックのセットを決定するよう動作可能である。第２のＬＢＴ手順で前記ＵＥをスケジューリングする前に、前記ＬＢＴモジュールは、前記決定された転送ブロックのセットの中の転送ブロックに関連付けられた全てのＨＡＲＱプロセス識別子を使用してアップリンクフレームの第２のバーストで前記ＵＥをスケジューリングするよう動作可能である。
【００６７】
コンピュータプログラム製品も開示される。コンピュータプログラム製品は、プロセッサによって実行されると、第１のＬＢＴ手順の後にアップリンクサブフレームの第１のバーストを送信する動作を実行する非一時的コンピュータ可読媒体に格納された命令を含む。ＬＢＴ手順はＬＢＴ競合ウィンドウサイズを使用して実行される。命令は、更に、アップリンクサブフレームの前記第１のバーストに基づいて参照サブフレームを決定する動作を実行するよう動作可能である。前記参照サブフレームは参照ハイブリッド自動再送要求（ＨＡＲＱ）プロセス識別子に関連付けられている。命令は、更に、アップリンクサブフレームの第２のバーストに対するスケジューリングを受信する動作を実行するよう動作可能である。前記スケジューリングは、アップリンクサブフレームの前記第２のバーストの各サブフレームについて、関連するＨＡＲＱプロセス識別子および関連する新規データインジケータ（ＮＤＩ）を含む。前記ＵＥがアップリンクサブフレームの前記第２のバーストのサブフレームのうちの少なくとも１つに関連付けられたＨＡＲＱプロセス識別子が前記参照ＨＡＲＱプロセス識別子と一致しかつ前記関連付けられたＮＤＩが新規のデータを示すと決定したとき、命令は、更に、前記ＬＢＴ競合ウィンドウサイズを最小値にリセットする動作を実行するよう動作可能である。前記ＵＥがアップリンクサブフレームの前記第２のバーストのサブフレームのうちの少なくとも１つに関連付けられたＨＡＲＱプロセス識別子が前記参照ＨＡＲＱプロセス識別子と一致しかつ前記関連付けられたＮＤＩが再送信を示すと決定したとき、命令は、更に、前記ＬＢＴ競合ウィンドウサイズをインクリメントする動作を実行するよう動作可能である。命令は、更に、前記競合ウィンドウサイズを使用して第２のＬＢＴ手順を実行する動作を実行するよう動作可能である。
【００６８】
別のコンピュータプログラム製品は、プロセッサによって実行されると、第１のＬＢＴ手順の後に、アップリンクサブフレームの第１のバーストをＵＥから受信する動作を実行する非一時的コンピュータ可読媒体に格納された命令を含む。アップリンクサブフレームの前記第１のバーストの各サブフレームは１つまたは複数の転送ブロックに関連付けられており、各転送ブロックはハイブリッド自動再送要求（ＨＡＲＱ）プロセス識別子に関連付けられている。命令は、更に、前記ネットワークノードによって正常に受信されなかった、アップリンクサブフレームの前記第１のバーストの中の転送ブロックのセットを決定する動作を実行するよう動作可能である。第２のＬＢＴ手順で前記ＵＥをスケジューリングする前に、命令は、更に、前記決定された転送ブロックのセットの中の転送ブロックに関連付けられた全てのＨＡＲＱプロセス識別子を使用してアップリンクフレームの第２のバーストで前記ＵＥをスケジューリングする動作を実行するよう動作可能である。
【００６９】
特定の実施形態は、以下の技術的利点のいくつかを示し得る。例えば、特定の実施形態は、シグナリング量を低減することによってアップリンクおよび／またはシステム性能を改善することができ、それはネットワーク負荷および装置の複雑さを低減し得る。いくつかの実施形態では、ネットワークノードは、無線デバイスにおける競合ウィンドウ調整を厳密に追跡し得る。他の技術的利点は、以下の図面、説明および特許請求の範囲から当業者には容易に明らかになるであろう。
【図面の簡単な説明】
【００７０】
実施形態ならびにそれらの特徴および利点をより完全に理解するために、添付の図面と併せて以下の説明を参照する。
【００７１】
【図１】例示的なＯＦＤＭシンボルを示す図である。
【図２】例示的な無線フレームを示す図である。
【図３】例示的なダウンリンクサブフレームを示す図である。
【図４】キャリア集約（アグリゲーション）の一例を示す図である。
【図５】例示的なＷＬＡＮリッスンビフォアトークのメカニズムを示す図である。
【図６】アンライセンススペクトルへのライセンス支援アクセスを有するユーザ装置を示す図である。
【図７】アップリンクのリッスンビフォアトークプロトコルに基づくアップリンクのライセンス支援アクセス送信の例を示す図である。
【図８】いくつかの実施形態による、例示的な無線ネットワークを示すブロック図である。
【図９】いくつかの実施形態による、ＬＢＴ競合ウィンドウサイズを暗黙的に決定するためのサブフレームのシーケンスの例を示す図である。
【図１０】いくつかの実施形態による、ＬＢＴ競合ウィンドウサイズを暗黙的に決定するためのサブフレームのシーケンスの例を示す図である。
【図１１】いくつかの実施形態による、ＬＢＴ競合ウィンドウサイズを暗黙的に決定するためのサブフレームのシーケンスの例を示す図である。
【図１２】いくつかの実施形態による、ＬＢＴ競合ウィンドウサイズを暗黙的に決定するためのサブフレームのシーケンスの例を示す図である。
【図１３】いくつかの実施形態による、ユーザ装置における例示的な方法を示すフロー図である。
【図１４】いくつかの実施形態による、ネットワークノードにおける例示的な方法を示すフロー図である。
【図１５Ａ】無線デバイスの例示的な実施形態を示すブロック図である。
【図１５Ｂ】無線デバイスの例示的な構成要素を示すブロック図である。
【図１６Ａ】ネットワークノードの例示的な実施形態を示すブロック図である。
【図１６Ｂ】ネットワークノードの例示的な構成要素を示すブロック図である。
【発明を実施するための形態】
【００７２】
ロングタームエボリューション（ＬＴＥ）装置は、ライセンス支援アクセス（ＬＡＡ）と呼ばれる第三世代パートナーシッププロジェクト（３ＧＰＰ）イニシアチブに従って、アンライセンスの５ＧＨｚ無線スペクトルで動作することができる。アンライセンスの５ＧＨｚスペクトルは、ライセンススペクトルの補完として使用される。したがって、デバイスは、ライセンススペクトル（一次セル（ＰＣｅｌｌ））で接続し、キャリアアグリゲーションを使用して、アンライセンススペクトル（二次セル（ＳＣｅｌｌ））で追加の伝送容量を利用できる。
【００７３】
規制要件により、事前のチャネル検知なしでは、アンライセンススペクトルでの送信が許可されない場合がある。無線デバイスは、リッスンビフォアトーク（ＬＢＴ）方法を使用してチャネル検知を実行することができる。ＬＢＴ法は、送信を検知することを含む。
【００７４】
ＬＢＴの形式は、スケジュールされているＵＥの数、連続してスケジュールされているサブフレームの数、キャリアでの以前の送信の長さ、および／または、他のそのような要因に依存し得る。ＬＢＴに関連するいくつかのパラメータは、ＵＥが送信前にＬＢＴを実行することができるように、ｅＮＢによってＵＥにシグナリングされ得る。しかしながら、シグナリングパラメータは、アンライセンススペクトルにおけるアップリンク送信に関して遭遇する可能性があるすべての使用事例および問題を完全に網羅するわけではない。  
【００７５】
ｅＮＢは、ダウンリンクでデータを送信する前に、チャネルアクセスを獲得するためにＬＢＴを実行する。ｅＮＢの送信継続時間中に、また、特定のＵＥが特定の時間後にアップリンクで送信するようスケジュールするために制御チャネルを送信する。ｅＮＢがチャネルを解放した後、スケジュールされたＵＥは、上述の特定の時間にチャネルで送信できるかどうかを判断するためにＬＢＴを実行する。
【００７６】
ＬＢＴを実行することは、一般に、２つの広いカテゴリのＬＢＴ操作を含み得る。第１のタイプは、ＩＥＥＥ８０２．１１準拠ノードによって使用されるものと同様の完全ランダムバックオフを伴うＬＢＴ手順を使用する。これらのスキームはカテゴリ４ＬＢＴスキームとも呼ばれる。
【００７７】
これらの方式では、ランダムバックオフカウンタが期間｛０，ＣＷ｝の中で一様にランダムに取り出される。ここで、ＣＷは競合ウィンドウである。競合ウィンドウのサイズは、チャネル上で衝突が検出されるたびに約２倍になる可能性がある。したがって、この手順はまた、二進指数バックオフと呼ばれることもある。
【００７８】
競合ウィンドウサイズは、最小値ＣＷｍｉｎと最大値ＣＷｍａｘによって制限される。ＣＷｍｉｎとＣＷｍａｘの値は、トラフィックの優先度クラスによって異なる。
【００７９】
第２のタイプのＬＢＴ手順では、ＵＥは、固定継続時間（例えば、２５μｓ）の間ＬＢＴ動作を実行することができる。一般に、第２のタイプのＬＢＴは、別のノードがＬＢＴ動作を完了してチャネル上で送信を開始する確率を最小にするので、ダウンリンク送信とアップリンク送信との間の遷移に好ましい。ただし、多くの場合、カテゴリ４ＬＢＴスキームを使用する必要がある。
【００８０】
３ＧＰＰ仕様は、Ｒｅｌ−１４  ＬＡＡのためのマルチサブフレームスケジューリングを含むことができ、単一のサブフレームで送信される１つまたは複数のアップリンク許可が複数のサブフレームのアップリンクデータをスケジュールすることができる。マルチサブフレームスケジューリング許可の一部としてシグナリングされるパラメータは、ハイブリッドＡＲＱ肯定応答（ＨＡＲＱ−ＡＣＫ）および関連パラメータを含む。具体的には、許可は、レガシーパラメータ（すなわち、一般に肯定応答される転送ブロックごとに１ビットから構成される、新規データインジケータ（ＮＤＩ）、冗長バージョン（ＲＶ）、およびＨＡＲＱ−ＡＣＫビット自体）を含む。
【００８１】
ＬＡＡに対するＬＢＴパラメータのシグナリングは、明示的方法と暗黙的方法の両方を使用することができる。解決策は、ランダムバックオフカウンタ、競合ウィンドウサイズ、および使用されるＬＢＴ優先度クラスなどのランダムバックオフパラメータのシグナリングを含む。これらのパラメータのシグナリングは、単一のサブフレーム内で多重化されている負荷およびＵＥのセットなどの要因に応じて異なり得る。使用されるべきＬＢＴ優先度クラスの暗黙的シグナリングは、ＵＥにスケジュールされた連続したサブフレームの数を含む様々な要因に基づくことができる。ＵＥで使用されるべき競合ウィンドウサイズはまた、送信が新しい送信であるか再送信であるかを示すことによって暗示的にシグナリングされ得る。
【００８２】
しかしながら、既存のシグナリングおよび競合ウィンドウ管理方法は、ＵＥが使用しなければならない競合ウィンドウサイズを示すために暗黙的シグナリングを使用するときに生じる問題を完全には説明していない。明示的シグナリングが使用されるとき、それは不必要に大きいシグナリングオーバーヘッドを生み出す。これらの問題を考慮して、特定の実施形態は、競合ウィンドウの管理のための要件を満たしながら、カテゴリ４ＬＢＴ方式のためのＬＢＴパラメータを効率的にＵＥにシグナリングする。
【００８３】
一般に、競合ウィンドウの調整は、送信開始時に経験した無線状態に基づいている。たとえば、成功したカテゴリ４ＬＢＴの後の送信で衝突が発生した場合、次のカテゴリ４ＬＢＴの試行に対して対応する競合ウィンドウサイズが増加する。しかしながら、ＵＥまたはｅＮＢで採用されている従来のシグナリングおよび競合ウィンドウ管理方法は、反対側で利用可能な情報が誤って解釈されるという欠点がある。ＵＥがＬＢＴに失敗して何も送信しない場合、またはＵＥが送信するがその送信が著しく妨害されている場合、ｅＮＢはＵＥからの有効な送信を検出することに失敗する。ｅＮＢは、送信失敗と衝突を伴う送信とを区別することはできず、後者だけが競合ウィンドウ調整に寄与するはずである。
【００８４】
特定の実施形態は、上述の問題を未然に防ぐものであり、ｅＮＢによって提供される暗黙的シグナリングおよびその送信に関するＵＥの知識を使用して、カテゴリ４ＬＢＴ方式の競合ウィンドウサイズなどのＬＢＴパラメータを調整することを含む。特定のアップリンクサブフレームにおいてＵＥによって使用されるカテゴリ４ＬＢＴ方式の競合ウィンドウサイズを管理するための以下の一般的な実施形態が説明される。
【００８５】
いくつかの実施形態は、ＵＥにおける競合ウィンドウ管理を伴う暗黙的シグナリングを含む。例えば、特定の実施形態は、情報が以前にスケジュールされたバーストで利用可能であるハイブリッド自動再送要求（ＨＡＲＱ）プロセスのために新規データインジケータ（ＮＤＩ）ビットを使用する。特定の実施形態はまた、ＵＥのために以前にスケジュールされたバーストのサブフレームについてのＬＢＴの失敗または成功に関するＵＥの知識を使用することができる。
【００８６】
特定の実施形態は、シグナリング量を減らすことによってアップリンクおよび／またはシステム性能を改善することができ、それはネットワーク負荷および装置の複雑さを減らすことができる。競合ウィンドウサイズを管理するために追加のシグナリングオーバーヘッドは必要ない。ｅＮＢは、ＵＥにおける競合ウィンドウ調整を厳密に追跡することができる。
【００８７】
本明細書で説明される実施形態は、ＬＡＡ  ＬＴＥおよびスタンドアロンＬＴＥ−Ｕ動作の両方に適用可能であり、一般にアンライセンススペクトルまたはＬＴＥなどのリッスンビフォアトークプロトコルが使用されるスペクトルおよび送信の発生に固定タイミングがある場合のスペクトルに適用可能である。
【００８８】
以下の説明は多数の特定の詳細を説明する。しかしながら、実施形態はこれらの具体的な詳細がなくても実施され得ることが理解される。他の例では、この説明の理解を曖昧にしないために、よく知られている回路、構造および技術は詳細には示されていない。当業者であれば、含まれる説明により、過度の実験をすることなく適切な機能を実施することができるであろう。
【００８９】
本明細書における「ある実施形態（one embodiment）」、「一実施形態（an embodiment）」、「例示的実施形態（one example embodiment）」などへの言及は、説明された実施形態が特定の特徴、構造、または特性を含み得ることを示すが、各実施形態は特定の特徴、構造、または特性を必ずしも含むとは限らない。さらに、そのような表現は必ずしも同じ実施形態を参照しているわけではない。さらに、特定の特徴、構造、または特性が実施形態に関連して説明されるとき、明示的に記述されているか否かによらず、他の実施形態に関連してそのような特徴、構造、または特性を実施することは当業者の知識の範囲内である。
【００９０】
特定の実施形態は、図面の図８〜図１６Ｂを参照して説明され、様々な図面の同じ部分および対応する部分には同じ番号が使用されている。ＬＴＥは、セルラシステムの例として本開示を通して使用されているが、本明細書に提示されたアイデアは他の無線通信システムにも同様に適用することができる。
【００９１】
図８は、特定の実施形態による例示的な無線ネットワークを示すブロック図である。無線ネットワーク１００は、１つまたは複数の無線デバイス１１０（携帯電話、スマートフォン、ラップトップコンピュータ、タブレットコンピュータ、ＭＴＣデバイス、または無線通信を提供できる他の任意の装置など）および複数のネットワークノード１２０（基地局またはｅノードＢなど）を含む。無線デバイス１１０はまた、ＵＥと呼ばれ得る。ネットワークノード１２０は、カバー領域１１５（セル１１５とも呼ばれる）にサービスを提供する。
【００９２】
一般に、ネットワークノード１２０のカバー範囲内にある（たとえば、ネットワークノード１２０によってサービス提供されるセル１１５内にある）無線デバイス１１０は、無線信号１３０を送信および受信することによってネットワークノード１２０と通信する。例えば、無線デバイス１１０及びネットワークノード１２０は、音声トラフィック、データトラフィック、および／または制御信号を含む無線信号１３０を通信する。音声トラフィック、データトラフィック、および／または制御信号を無線デバイス１１０に通信するネットワークノード１２０は、無線デバイス１１０に対するサービングネットワークノード１２０と呼ばれることがある。無線デバイス１１０とネットワークノード１２０との間の通信は、セルラ通信と呼ばれることがある。無線信号１３０は、（ネットワークノード１２０から無線デバイス１１０への）ダウンリンク送信と（無線デバイス１１０からネットワークノード１２０への）アップリンク送信の両方を含み得る。
【００９３】
各ネットワークノード１２０は、無線デバイス１１０に信号１３０を送信するための単一の送信機または複数の送信機を有し得る。いくつかの実施形態では、ネットワークノード１２０は多入力多出力（ＭＩＭＯ）システムを備える。同様に、各無線デバイス１１０は、ネットワークノード１２０または他の無線デバイス１１０から信号１３０を受信するための単一の受信機または複数の受信機を有し得る。
【００９４】
無線信号１３０は、図１〜図３に関して説明したもののようなフレームおよびサブフレームを含み得る。ネットワークノード１２０は、アップリンクサブフレーム、ダウンリンクサブフレーム、またはアップリンクとダウンリンクのサブフレームの組み合わせとして、サブフレームを動的にスケジュールすることができる。
【００９５】
ネットワークノード１２０は、ＬＴＥスペクトルなどのライセンス周波数スペクトルで動作することができる。ネットワークノード１２０はまた、５ＧＨｚのＷｉ−Ｆｉスペクトルなどのアンライセンス周波数スペクトルで動作してもよい。アンライセンス周波数スペクトルでは、ネットワークノード１２０は、ＩＥＥＥ８０２．１１アクセスポイントおよび端末などの他の装置と共存することができる。アンライセンススペクトルを共有するために、ネットワークノード１２０は、無線信号１３０を送信または受信する前にＬＢＴのプロトコルを実行することができる。無線デバイス１１０は、ライセンス又はアンライセンススペクトルの一方または両方で動作することができ、いくつかの実施形態では無線信号１３０を送信する前にＬＢＴプロトコルを実行することができる。ネットワークノード１２０と無線デバイス１１０の両方はまた、ライセンス共有スペクトルで動作してもよい。
【００９６】
例えば、ネットワークノード１２０ａはライセンススペクトルで動作し、ネットワークノード１２０ｂはアンライセンススペクトルで動作することができる。無線デバイス１１０は、ライセンススペクトルおよびアンライセンススペクトルの両方で動作し得る。特定の実施形態では、ネットワークノード１２０ａおよび１２０ｂは、ライセンススペクトル、アンライセンススペクトル、ライセンス共有スペクトル、または任意の組み合わせで動作するように構成可能であり得る。セル１１５ｂのカバー範囲はセル１１５ａのカバー範囲に含まれるように示されているが、特定の実施形態では、セル１１５ａおよび１１５ｂの有効範囲は部分的に重複し、または全く重複しなくてもよい。
【００９７】
特定の実施形態では、無線デバイス１１０およびネットワークノード１２０はキャリアアグリゲーションを実行してもよい。例えば、ネットワークノード１２０ａは無線デバイス１１０に対してＰＣｅｌｌとして機能し、ネットワークノード１２０ｂは無線デバイス１１０に対してＳＣｅｌｌとして機能することができる。ネットワークノード１２０は、自己スケジューリングまたはクロススケジューリングを実行し得る。ネットワークノード１２０ａがライセンススペクトルで動作し、ネットワークノード１２０ｂがアンライセンススペクトルで動作している場合、ネットワークノード１２０ａはアンライセンススペクトルへのライセンス支援アクセスを提供し得る（すなわち、ネットワークノード１２０ａはＬＡＡ  ＰＣｅｌｌであり、ネットワークノード１２０ｂはＬＡＡ  ＳＣｅｌｌである）。
【００９８】
特定の実施形態では、ネットワークノード１２０ａは、無線デバイス１１０のアップリンクおよびダウンリンクサブフレームを動的にスケジュールし得る。例えば、特定の実施形態では、ネットワークノード１２０ａは、第１の複数の連続サブフレームに対する第１のアップリンク／ダウンリンクスケジューリングパターンを決定し得る。ネットワークノード１２０ａは、（例えば（Ｅ）ＰＤＣＣＨを使用して）第１のアップリンク／ダウンリンクスケジューリングパターンを無線デバイス１１０に送信し、第１のアップリンク／ダウンリンクスケジューリングパターンに従って無線デバイス１１０に少なくとも１つのサブフレームを送信し得る。
【００９９】
例えば、ネットワークノード１２０ａが追加のダウンリンクデータ、または無線デバイスからのアップリンク送信の要求を受信した場合、ネットワークノード１２０ａは、第２の複数の連続サブフレームについて第２のアップリンク／ダウンリンクスケジューリングパターンを決定し得る。ネットワークノード１２０ａは、無線デバイス１１０に対して以前にスケジュールされたサブフレームのいずれかにおいて第２のアップリンク／ダウンリンクスケジューリングパターンを無線デバイス１１０に送信することができる。
【０１００】
特定の実施形態では、アップリンク／ダウンリンクスケジューリングパターンは、いくつかの後続のダウンリンクサブフレーム、いくつかの後続のダウンリンクおよびアップリンクサブフレーム、どのサブフレームをダウンリンクに関して監視するかまたは監視しないかの指示、または任意の他の適切なパターンを含み得る。
【０１０１】
特定の実施形態では、無線デバイス１１０は、（例えば、（Ｅ）ＰＤＣＣＨを使用して）ネットワークノード１２０から、第１の複数の連続サブフレームに対する第１のアップリンク／ダウンリンクスケジューリングパターンを受信することができる。無線デバイス１１０は、第１のアップリンク／ダウンリンクスケジューリングパターンに従って少なくとも１つのサブフレームを受信し得る。スケジュールされたダウンリンクサブフレームのうちの１つにおいて、無線デバイス１１０は、第２の複数の連続サブフレームについての第２のアップリンク／ダウンリンクスケジューリングパターンを受信し得る。
【０１０２】
無線デバイス１１０は、アップリンクで送信する前にＬＢＴ手順を実行し得る。たとえば、無線デバイス１１０は、第１のＬＢＴ手順の後にアップリンクサブフレームの第１のバーストを送信し得る。無線デバイス１１０は、アップリンクサブフレームの第１のバーストに基づいて参照サブフレームを決定する。参照サブフレームは、参照ＨＡＲＱプロセス識別子と関連付けられる。無線デバイス１１０は、アップリンクサブフレームの第２のバーストについてのスケジューリングを受信する。スケジューリングは、アップリンクサブフレームの第２のバーストの各サブフレームについて、関連するＨＡＲＱプロセス識別子と関連するＮＤＩとを含む。無線デバイス１１０がアップリンクサブフレームの第２のバーストのサブフレームのうちの少なくとも１つに関連付けられたＨＡＲＱプロセス識別子が参照ＨＡＲＱプロセス識別子と一致し、関連付けられたＮＤＩが新規のデータを示すと決定したとき、無線デバイス１１０は、ＬＢＴ競合ウィンドウサイズを最小値にリセットする。アップリンクサブフレームの第２のバーストのサブフレームのうちの少なくとも１つに関連付けられたＨＡＲＱプロセス識別子が参照ＨＡＲＱプロセス識別子と一致し、関連付けられたＮＤＩが再送信を示すとき、無線デバイス１１０は、ＬＢＴ競合ウィンドウサイズをインクリメントする。無線デバイス１１０は、競合ウィンドウサイズを使用して第２のＬＢＴ手順を実行する。
【０１０３】
特定の実施形態では、無線デバイス１１０は、関連するＨＡＲＱプロセス識別子がアップリンクサブフレームの第２のバーストの受信スケジューリングにおいても見出される、アップリンクサブフレームの第１のバーストにおいて最も最近送信されたアップリンクサブフレームを決定することによって、参照サブフレームを決定し得る。いくつかの実施形態では、無線デバイス１１０は、アップリンクサブフレームの第１のバーストの第１のサブフレームに関連付けられたＨＡＲＱプロセス識別子がアップリンクサブフレームの第２のバーストに対する受信スケジューリングにおいても見出される、アップリンクサブフレームの第１のバーストの最初の送信サブフレームを決定することによって参照サブフレームを決定し得る。
【０１０４】
特定の実施形態では、第２のＬＢＴ手順を実行することは、ライセンス支援アクセス（ＬＡＡ）の二次セル上で物理アップリンク共有チャネル（ＰＵＳＣＨ）送信のためのカテゴリ４ＬＢＴを実行することを含む。
【０１０５】
いくつかの実施形態によれば、ネットワークノード１２０は、第１のＬＢＴ手順の後に無線デバイス１１０からアップリンクサブフレームの第１のバーストを受信することができる。アップリンクサブフレームの第１のバーストの各サブフレームは１つまたは複数の転送ブロックと関連付けられ、各転送ブロックはＨＡＲＱプロセス識別子と関連付けられる。ネットワークノード１２０は、うまく受信されなかったアップリンクサブフレームの第１のバースト内の転送ブロックのセットを決定する。第２のＬＢＴ手順を用いて無線デバイス１１０をスケジューリングする前に、ネットワークノード１２０は、決定された転送ブロックのセット内の転送ブロックに関連付けられたすべてのＨＡＲＱプロセス識別子を使用してアップリンクフレームの第２のバーストを無線デバイス１１０にスケジュールする。
【０１０６】
特定の実施形態では、ネットワークノード１２０は、少なくとも１つの転送ブロックが首尾よく受信された受信サブフレームの前の最後のサブフレームに基づいて参照サブフレームを決定する。転送ブロックのセットは、正常に受信されなかった参照サブフレーム内の転送ブロックを含んでいる。
【０１０７】
特定の実施形態は、ライセンスまたはアンライセンススペクトル、ライセンス支援アクセス、および／またはキャリアアグリゲーションに関して説明されているが、本明細書で説明される実施形態は、任意のスペクトルにおける単一セルまたは任意のセルの組み合わせに関するアップリンクおよびダウンリンクスケジューリングに等しく適用される。
【０１０８】
無線ネットワーク１００では、各ネットワークノード１２０は、ロングタームエボリューション（ＬＴＥ）、ＬＴＥアドバンスト、ＵＭＴＳ、ＨＳＰＡ、ＧＳＭ、ｃｄｍａ２０００、ＮＲ、ＷｉＭａｘ、ＷｉＦｉ、および／または他の適切な無線アクセス技術などの任意の適切な無線アクセス技術を使用することができる。無線ネットワーク１００は、１つまたは複数の無線アクセス技術の任意の適切な組み合わせを含み得る。例の目的のために、様々な実施形態が特定の無線アクセス技術の文脈内で説明され得る。しかしながら、本開示の範囲は例に限定されず、他の実施形態は異なる無線アクセス技術を使用することができる。
【０１０９】
上述のように、無線ネットワークの実施形態は、１つ以上の無線デバイスと、無線デバイスと通信することができる１つ以上の異なる種類の無線ネットワークノードと、を含み得る。ネットワークは、無線デバイス間または無線デバイスと他の通信装置（固定電話など）との間の通信をサポートするのに適した任意の追加の要素も含むことができる。無線デバイスは、ハードウェアおよび／またはソフトウェアの任意の適切な組み合わせを含み得る。例えば、特定の実施形態において、無線デバイス１１０のような無線デバイスは、以下の図１５Ａに関して説明された構成要素を含み得る。同様に、ネットワークノードは、ハードウェアおよび／またはソフトウェアの任意の適切な組み合わせを含み得る。例えば、特定の実施形態では、ネットワークノード１２０のようなネットワークノードは、以下の図１６Ａに関して説明される構成要素を含み得る。
【０１１０】
いくつかの実施形態は、ＵＥにおける競合ウィンドウ管理を伴う暗黙的シグナリングを含む。一般に、ＵＥは、ＵＥからのサブフレームのアップリンクバーストの始めに送信される転送ブロックに利用可能な最新のＨＡＲＱフィードバック情報に基づいて競合ウィンドウサイズを増加またはリセットする。ＵＥは、現在の許可が、所与のＨＡＲＱプロセスの下で送信される転送ブロックについての新規データインジケータ（ＮＤＩ）によって示されるように、新規の転送ブロックの送信であるのか、または再送信であるのかを知っている。ｅＮＢは、いくつか（例えば、８または１６）のＨＡＲＱプロセスを並行して使用することができる。ｅＮＢからの暗黙的シグナリングと併せて送信バーストの第１のサブフレームにおける転送ブロックの使用を達成するための特定のＵＥ手順が本明細書に開示される。
【０１１１】
特定の実施形態では、ＵＥは、カテゴリ４ランダムバックオフ手順（競合ウィンドウサイズが増加する可能性がある）を使用したＬＢＴを実行すべきとｅＮＢが指示したアップリンクバーストの送信の前に、ＬＢＴを実行するための競合ウィンドウサイズを増加または最小値にリセットするために以下の手順を使用し得る。例えば、ＵＥは、バーストの最初の送信されたサブフレームで使用されたＨＡＲＱプロセス番号が後続のスケジュールされたサブフレームにも現れる、カテゴリ４ＬＢＴ手順の後に送信された連続サブフレームの最も最近送信されたバースト（現在スケジュールされているバーストを除く）を使用することができる。上記条件を満たすＨＡＲＱプロセスは、競合ウィンドウサイズを決定するための参照ＨＡＲＱプロセスとして使用される。
【０１１２】
参照サブフレームの送信および参照ＨＡＲＱプロセスを使用する後続のバーストのためのスケジューリングコマンドの受信後、参照ＨＡＲＱプロセスのためのＮＤＩビットがトグルされず、再送信を示す場合、ＵＥは、参照送信バーストの送信の前にＬＢＴを実行するために使用された優先度クラスの競合ウィンドウサイズのセットの中で次に高い値まで競合ウィンドウサイズを増加させる。いくつかの実施形態では、ＵＥによって使用される全てのＬＢＴ優先度クラスの競合ウィンドウサイズは次に高い値に増加される。
【０１１３】
参照ＨＡＲＱプロセスのＮＤＩビットがトグルされ、新規の転送ブロックの送信を示している場合、ＵＥは、次の送信バーストの送信の前にカテゴリ４ＬＢＴ手順を実行する際にＵＥによって使用される優先度クラスの競合ウィンドウサイズのセット内の最小値に競合ウィンドウサイズをリセットする。優先度クラスは、ＵＥが送信しようとしているトラフィックタイプに基づいてＵＥによって選択されてもよく、あるいは次の送信バーストに対するアップリンク許可においてｅＮＢによって示されてもよい。いくつかの実施形態では、ＵＥによって使用されるすべてのＬＢＴ優先度クラスの競合ウィンドウサイズは最小値にリセットされる。
【０１１４】
特定の実施形態は、ｅＮＢによって実行される手順を含む。いくつかの実施形態では、カテゴリ４ＬＢＴ手順の後にＵＥによって送信されたアップリンク送信バーストの受信後、ｅＮＢは、対応する転送ブロックが正常に受信されなかった受信アップリンク送信バースト内の全てのＨＡＲＱプロセス識別子を使用して、カテゴリ４の手順を使用してアップリンクで新規の送信バーストがスケジュールされる時点またはその前に、ＵＥにデータをスケジュールする。
【０１１５】
再送信を示すＨＡＲＱプロセス識別子は、ランダムバックオフを伴うカテゴリ４ＬＢＴベースのアップリンク送信のためのアップリンク許可を介してスケジュールされる必要はない。プロセスは、短いＬＢＴ（例えば、２５μｓのＣＣＡ）またはＬＢＴなしのアップリンク許可を介してスケジュールされていてもよい。
【０１１６】
上記の例では、競合ウィンドウサイズは、参照ＨＡＲＱプロセスのＮＤＩビットがトグルされず、デバイスが以前の送信バーストの最初のサブフレームとして実際に参照ＨＡＲＱプロセスを送信した場合にのみ、次に高い値に増加する。これは、２つのタイプの理由がＨＡＲＱプロセスの再送信を引き起こす可能性があるためである。
【０１１７】
１つの理由は、ＨＡＲＱプロセスは送信されたが衝突が発生する場合である。これらの場合には、再送信はより大きな競合ウィンドウサイズを使用するべきである。別の理由は、デバイスがＬＢＴプロトコルに基づく以前の予定された送信バーストでＨＡＲＱプロセスを送信することができなかった場合である。すなわち、デバイスは占有チャネル状態を観察し、衝突を避けるために送信を控えた場合である。このような場合は、競合ウィンドウサイズを大きくすべきではない。
【０１１８】
より詳細な例は、図９〜図１２に関して説明される。図９〜図１２は、いくつかの実施形態による、ＬＢＴ競合ウィンドウサイズを暗黙的に決定するためのサブフレームのシーケンスの例を示す。
【０１１９】
図９は、いくつかの実施形態による、ＬＢＴ競合ウィンドウサイズを暗黙的に決定するためのサブフレームの第１の例示的シーケンスを示す図である。図示の例は、ＮからＮ＋１９までの番号が付けられたサブフレームを含む。サブフレームＮ、Ｎ＋１、Ｎ＋２、およびＮ＋１１はダウンリンクサブフレームである。サブフレームＮ＋４、Ｎ＋６、Ｎ＋７、Ｎ＋８、Ｎ＋９、Ｎ＋１５、Ｎ＋１６、Ｎ＋１７、およびＮ＋１９はアップリンクサブフレームである。
【０１２０】
アップリンクサブフレームは、ダウンリンクサブフレームで受信された許可によってスケジュールされる。図示の例では、矢印は、アップリンクサブフレーム内のアップリンクデータをスケジュールするために、許可がダウンリンクサブフレーム内で送信される、ダウンリンクおよびアップリンクサブフレームを示す。例えば、ダウンリンクサブフレームＮは、アップリンクサブフレームＮ＋４、Ｎ＋６、Ｎ＋７、Ｎ＋８、およびＮ＋９に対するスケジューリング許可を含む。ダウンリンクサブフレームＮ＋１１は、アップリンクサブフレームＮ＋１５、Ｎ＋１６、Ｎ＋１７、およびＮ＋１９に対するスケジューリング許可を含む。
【０１２１】
スケジューリング許可は、アップリンクがカテゴリ４ＬＢＴ手順または２５μｓのＣＣＡの後に実行されるべきかどうかを示し得る。例えば、アップリンクサブフレームＮ＋４、Ｎ＋１５、Ｎ＋１６、およびＮ＝１７がＣＣＡに対してスケジュールされる。アップリンクサブフレームＮ＋６、Ｎ＋７、Ｎ＋８、Ｎ＋９、およびＮ＋１９は、カテゴリ４ＬＢＴに対してスケジュールされる。
【０１２２】
図示の例では、各サブフレームは２つの転送ブロックを含み、各転送ブロックは（ＨＡＲＱプロセス識別子Ｈ０、Ｈ１、Ｈ２などによって示される）ＨＡＲＱプロセスに関連付けられている。他の実施形態は、任意の適切な数の転送ブロックおよびＨＡＲＱプロセスを含み得る。
【０１２３】
スケジューリング情報は、タグＮ０またはＮ１によって表される新規データインジケータ（ＮＤＩ）も含む。タグＮ０は、新規データインジケータがトグルされることを示し、これは、許可が新規のデータ転送ブロックに対するものであることをＵＥに示す。同様に、Ｎ１は、新規データインジケータがトグルされていないことを示し、これは、許可が誤って受信された転送ブロックの再送信に対するものであることを意味する。
【０１２４】
図９の説明文によって示されるように、いくつかのアップリンクサブフレームは、ＬＢＴ失敗（例えば、サブフレームＮ＋６）、衝突（例えば、サブフレームＮ＋７）、または復号エラー（例えば、サブフレームＮ＋８）を経験し得る。復号エラーは、各サブフレームについて２つの転送ブロックの一方または両方に適用され得ることに留意されたい。ＵＥは、ＨＡＲＱプロセス識別子を使用して参照サブフレームを決定し、ＮＤＩを使用してＬＢＴ競合ウィンドウサイズをインクリメントするかリセットするかを決定することができる。
【０１２５】
図９に関する特定の例として、サブフレームＮにおけるアップリンク許可は、２５μｓのＣＣＡに基づくサブフレームＮ＋４におけるＰＵＳＣＨ送信と、カテゴリ４ＬＢＴに基づくサブフレームＮ＋６からＮ＋９におけるＰＵＳＣＨ送信とを用いてＵＥをスケジュールする。ＵＥはサブフレームＮ＋４においてＣＣＡで成功する。しかしながら、ＵＥはサブフレームＮ＋６でカテゴリ４ＬＢＴで失敗するが、サブフレームＮ＋７でカテゴリ４ＬＢＴで成功し、サブフレームＮ＋９まで送信を続ける。
【０１２６】
したがって、ＵＥの参照サブフレームはサブフレームＮ＋７（すなわち、カテゴリ４ＬＢＴ手順の後に最初に送信されるアップリンク）であり、対応するＨＡＲＱプロセス識別子はＨ４およびＨ５である。この例では、最初に送信されたサブフレーム（Ｎ＋７）がひどく干渉されている。ｅＮＢでは、Ｈ２、Ｈ３、Ｈ４、およびＨ５に対応する転送ブロックは検出されず、Ｈ６に対応する転送ブロックは誤って検出される。ｅＮＢは、ＵＥに別のカテゴリ４ＬＢＴを許可する前に、これらのすべてのＨＡＲＱプロセス（すなわち、Ｈ２、Ｈ３、Ｈ４、Ｈ５およびＨ６）を非トグルＮＤＩでスケジュールする。
【０１２７】
競合ウィンドウ調整のために、ＵＥは、Ｈ４およびＨ５のＮＤＩ（すなわち、参照サブフレーム）のみを探し、それらがトグルされていないことを見つける。したがって、ＵＥは、次のカテゴリ４ＬＢＴ送信のための競合ウィンドウを増加させる。図示の例では、ＵＥはサブフレームＮ＋１９においてカテゴリ４ＬＢＴにスケジュールされている。ＵＥは、サブフレームＮ＋１９においてカテゴリ４ＬＢＴを実行する前に競合ウィンドウサイズを増加する。
【０１２８】
図１０は、いくつかの実施形態による、ＬＢＴ競合ウィンドウサイズを暗黙的に決定するためのサブフレームの別の例示的なシーケンスを示す。図示の例は、図９に関して説明したものと同様のＮからＮ＋１９までの番号を付けられたサブフレームを含む。違いは、サブフレームＮ＋７におけるアップリンク送信が図１０において成功する（すなわち図９のように衝突しない）ことである。
【０１２９】
サブフレームＮにおけるアップリンク許可は、２５μｓのＣＣＡに基づくサブフレームＮ＋４におけるＰＵＳＣＨ送信、およびカテゴリ４ＬＢＴに基づくサブフレームＮ＋６からＮ＋９におけるＰＵＳＣＨ送信を用いてＵＥをスケジュールする。ＵＥはサブフレームＮ＋４におけるＣＣＡ  ＬＢＴで成功する。しかしながら、ＵＥは、サブフレームＮ＋６におけるカテゴリ４ＬＢＴで失敗するが、サブフレームＮ＋７におけるカテゴリ４ＬＢＴで成功し、サブフレームＮ＋９まで送信を続ける。図９の例と同様に、ＵＥの参照サブフレームはサブフレームＮ＋７であり、対応するＨＡＲＱプロセス識別子はＨ４とＨ５である。図１０に示す例では、成功したＬＢＴ後のＵＥ送信はｅＮＢにおいて正しく検出される（すなわち、Ｈ４およびＨ５は成功裏に復号される）。
【０１３０】
ｅＮＢでは、Ｈ２およびＨ３に対応する転送ブロックは検出されず、Ｈ６に対応する転送ブロックは誤って検出される。ｅＮＢは、ＵＥに別のカテゴリ４ＬＢＴを許可する前に、これら全てのＨＡＲＱプロセス（すなわち、Ｈ２、Ｈ３、およびＨ６）を非トグルＮＤＩでスケジュールする。
【０１３１】
競合ウィンドウの調整では、ＵＥはＨ４とＨ５のＮＤＩのみを検索し、それらがトグルされていることを確認する（ＵＥがそれらを確認できない場合もある）。したがって、ＵＥは、次のカテゴリ４ＬＢＴ送信のために競合ウィンドウサイズをリセットする。図示の例では、ＵＥはサブフレームＮ＋１９においてカテゴリ４ＬＢＴにスケジュールされている。ＵＥは、サブフレームＮ＋１９においてカテゴリ４ＬＢＴを実行する前に競合ウィンドウサイズを最小値にリセットする。
【０１３２】
図９および図１０に関して説明したように、ｅＮＢは、参照送信バースト内のすべての失敗した送信について非トグルＮＤＩを用いてＨＡＲＱプロセスにシグナリングする。しかしながら、トグルされていないＮＤＩの全てが競合ウィンドウ調整の決定に寄与するわけではない。送信バーストの開始に対応するトグルしていないＮＤＩのみが寄与する。これは、ｅＮＢが競合ウィンドウ調整のための関連情報のみを提供することを可能にすることによってｅＮＢに対するスケジューリング制約を単純化することができる。特定の実施形態では、以下の手順が、ｅＮＢがカテゴリ４のランダムバックオフ手順（競合ウィンドウサイズが増大する可能性がある）を使用してＬＢＴを実行することを示したアップリンクバーストの送信前にＬＢＴを実行するため、競合ウィンドウサイズを増加または最小値にリセットするためにＵＥによって使用される。
【０１３３】
カテゴリ４ＬＢＴ手順を実行した後に送信され、現在時刻の前にＸｍｓを超えて終了した、最も最近送信された連続するサブフレームのバーストは、参照送信バーストとして定義される。Ｘの値は、ＵＥによる送信のためのフィードバックを提供するために十分な時間が利用可能であるように選択され得る。例えば、ＨＡＲＱフィードバック遅延が少なくとも４ｍｓである限り、Ｘ＝４ｍｓがＬＴＥおよびＬＡＡに推奨される。
【０１３４】
サブフレーム内のＨＡＲＱプロセス識別子がその後にスケジュールされた送信バーストのために再使用されている参照送信バースト内の最初のサブフレームは、参照サブフレームとして定義される。参照サブフレームの送信後、参照サブフレーム内のすべてのＨＡＲＱプロセス識別子のＮＤＩビットがトグルされていない（すなわち、再送信であることを示す）場合、競合ウィンドウサイズは、参照送信バーストの送信前にＬＢＴを実行するために使用された優先度クラスの競合ウィンドウサイズのセットの中で次に高い値に増加される。あるいは、ＵＥによって使用されるすべてのＬＢＴ優先度クラスの競合ウィンドウサイズは、次に高い値に増加され得る。
【０１３５】
あるいは、参照ＨＡＲＱプロセス識別子のうちの少なくとも１つに対するＮＤＩビットがトグルされる（すなわち、許可が新規の転送ブロックの送信、または参照サブフレームのＨＡＲＱプロセス識別子がないことを示す）場合、競合ウィンドウサイズは、送信バーストの送信の前にＬＢＴを実行するためにＵＥによって使用されている優先度クラスの競合ウィンドウサイズのセット内の最小値にリセットされる。この優先度クラスは、ＵＥが送信しようとしているトラフィックタイプに基づいてＵＥによって選択されてもよく、あるいは現在の送信バーストに対するアップリンク許可においてｅＮＢによって示されてもよい。あるいは、ＵＥによって使用されるすべてのＬＢＴ優先度クラスの競合ウィンドウサイズは最小値にリセットされてもよい。
【０１３６】
特定の実施形態は、ｅＮＢによって使用される以下の手順を含み得る。ＵＥによるカテゴリ４ＬＢＴ手順の後に送信されるようにスケジュールされたアップリンク上で受信された送信バーストでは、少なくとも１つの転送ブロックが首尾よく受信されたサブフレームの前の最後のサブフレームが参照サブフレームとして定義される。バースト内の転送ブロックが正常に受信されなかった場合、バースト内の最後のサブフレームは参照サブフレームである。バースト内の各サブフレームにおいて少なくとも１つの転送ブロックが首尾よく受信された場合、送信バーストに対して定義された参照サブフレームはない。
【０１３７】
参照サブフレームが送信バーストに対して定義されている場合、ｅＮＢは、カテゴリ４手順を使用してアップリンク上で新しい送信バーストがスケジュールされる時点またはそれ以前に、非トグルの対応するＮＤＩを有する参照サブフレーム内のすべてのＨＡＲＱプロセス識別子を使用して、ＵＥにデータをスケジュールする。
【０１３８】
再送信を示すＨＡＲＱプロセス識別子は、ランダムバックオフを伴うカテゴリ４ＬＢＴベースのアップリンク送信のためのアップリンク許可を介してスケジュールされる必要はない。それはまた、短いＬＢＴ（例えば、２５μｓのＣＣＡ）またはＬＢＴなしのアップリンク許可を介してスケジュールされ得る。
【０１３９】
上記の例では、競合ウィンドウサイズは、参照ＨＡＲＱプロセスのＮＤＩビットがトグルされず、デバイスが以前の送信バーストの最初のサブフレームとして実際に参照ＨＡＲＱプロセスを送信した場合にのみ、次に高い値に増加する。これは、２つのタイプの理由がＨＡＲＱプロセスの再送信を引き起こす可能性があるためである。
【０１４０】
１つの理由は、ＨＡＲＱプロセスは送信されたが衝突が発生した場合である。これらの場合には、再送信はより大きな競合ウィンドウサイズを使用するべきである。別の理由は、デバイスがＬＢＴプロトコルに基づく以前の予定された送信バーストでＨＡＲＱプロセスを送信することができなかった場合である。すなわち、装置は占有チャネル状態を観察し、衝突を避けるために送信を控える。このような場合は、競合ウィンドウサイズを大きくすべきではない。
【０１４１】
前述の実施形態の２つの例が図１１および図１２に示されている。これら２つの例から、図９および図１０に関して説明された実施形態との違いがよりよく理解され得る。
【０１４２】
図１１は、いくつかの実施形態による、ＬＢＴ競合ウィンドウサイズを暗黙的に決定するためのサブフレームの別の例示的なシーケンスを示す。図示の例は、図９に関して説明したものと同様のＮからＮ＋１９までの番号が付けられたサブフレームを含む。
【０１４３】
ＵＥにおける参照サブフレームはサブフレームＮ＋７である。しかしながら、ｅＮＢは、サブフレームＮ＋６およびＮ＋７において、両方の転送ブロックが誤って検出されているのを検出し、一方、サブフレームＮ＋８においては、転送ブロックの一方のみが誤っている。したがって、ｅＮＢにおける参照サブフレームはサブフレームＮ＋７である。したがって、ｅＮＢは、非トグルＮＤＩを用いてＨ４およびＨ５をスケジュールするだけである。ＵＥにおける参照サブフレームもサブフレームＮ＋７であり、ＵＥは、競合ウィンドウ調整のために、ＨＡＲＱプロセスＨ４およびＨ５を探す。
【０１４４】
図１２は、いくつかの実施形態による、ＬＢＴ競合ウィンドウサイズを暗黙的に決定するためのサブフレームの別の例示的なシーケンスを示す。図示の例では、図１０に関して説明したものと同様のＮからＮ＋１９の番号が付けられたサブフレームを含む。
【０１４５】
ＵＥにおける参照サブフレームはサブフレームＮ＋７である。しかしながら、ｅＮＢは、両方の転送ブロックがサブフレームＮ＋７において正しく検出される一方で、両方の転送ブロックがサブフレームＮ＋６において誤って検出されることを検出する。したがって、ｅＮＢの観点からは、参照サブフレームはＮ＋６である。したがって、ｅＮＢは、非トグルｅＮＢを用いてＨ２およびＨ３をスケジュールする。
【０１４６】
一方、ＵＥは、参照サブフレーム７内でＨＡＲＱプロセスＨ４およびＨ５を探し、それらがスケジュールされているかどうかを確認し、スケジュールされている場合、それらがトグルされているか否かを調べる。プロセスＨ４およびＨ５がトグルされるので、ＵＥは、サブフレームＮ＋１９でスケジュールされているカテゴリ４ＬＢＴ試行に対して競合ウィンドウサイズを最小にリセットする。
【０１４７】
いくつかの実施形態は、競合ウィンドウ管理のための修正メカニズムを含む。例えば、いくつかの方法は、ｅＮＢで検出されたときの参照バーストまたはサブフレームの位置をＵＥにシグナリングすることによって競合ウィンドウサイズを調整し、それによってＵＥはこの情報を用いて競合ウィンドウサイズを調整する。しかしながら、これらの方法では、参照サブフレームは、最初のシグナリングされたパラメータが処理される前に複数回シグナリングされ得る。これは、処理遅延（例えば、ＵＥがスケジューリングコマンドを受信した時間とアップリンクで送信する時間との間の４ｍｓの遅延）のために起こり得る。このような遅延は、競合ウィンドウサイズが複数回誤って調整されることにつながる可能性がある。この問題は、例えば、ＵＥがアップリンク許可を逃した場合にも起こり得る。
【０１４８】
これらの問題に対処するために、特定の実施形態は、以下の解決策の一方または両方を含み得る。参照サブフレームは、一度だけシグナリングされる（すなわち、複数回されない）ように制限され得る。別の解決策では、参照サブフレームは、競合ウィンドウサイズ調整のためにＵＥによって一度だけ使用され、それが複数回受信された場合には無視される。
【０１４９】
図９〜図１０に関して上述した方法の一般的な例は、ＵＥに関しては図１３に、ネットワークノードに関しては図１４に示されている。
【０１５０】
図１３は、いくつかの実施形態による、ユーザ装置における例示的な方法を示すフロー図である。特定の実施形態では、図１３の１つまたは複数のステップは、図８に関して説明した無線ネットワーク１００の構成要素によって実行され得る。
【０１５１】
方法はステップ１３１２で始まり、ＵＥは第１のＬＢＴ手順の後にアップリンクサブフレームの第１のバーストを送信する。ＬＢＴ手順は、ＬＢＴ競合ウィンドウサイズを使用して実行される。たとえば、無線デバイス１１０は、図９〜図１２のいずれかに示されているサブフレームＮ＋６からＮ＋９のバーストを受信することができる。
【０１５２】
ステップ１３１４で、ＵＥは、アップリンクサブフレームの第１のバーストに基づいて参照サブフレームを決定し、この参照サブフレームは参照ＨＡＲＱプロセス識別子と関連付けられる。いくつかの実施形態では、参照サブフレームを決定することは、関連するＨＡＲＱプロセス識別子がアップリンクサブフレームの第２のバーストの受信スケジューリングにおいても見出されるアップリンクサブフレームの第１のバーストにおいて最も最近送信されたアップリンクサブフレームを決定することを含む。いくつかの実施形態では、参照サブフレームを決定することは、アップリンクサブフレームの第１のバーストの第１のサブフレームに関連するＨＡＲＱプロセス識別子がアップリンクサブフレームの第２のバーストの受信スケジューリングにおいても見出される、アップリンクサブフレームの第１のバーストの第１の送信サブフレームを決定することを含む。
【０１５３】
例えば、図９〜図１２に示す例を参照すると、無線デバイス１１０は、サブフレームＮ＋７がアップリンクサブフレームの第１のバーストの最初の送信サブフレームであると決定することができる。サブフレームＮ＋６はＬＢＴ失敗のために送信されておらず、従ってＮ＋７は最初に送信されたサブフレームである。
【０１５４】
いくつかの例（たとえば、図９および図１１）では、サブフレームＮ＋７は衝突エラーを被っている。他の例（例えば、図１０および図１２）では、サブフレームＮ＋７はネットワークノード１２０によって成功裏に受信される。いずれにしても、サブフレームＮ＋７は（成功裡に受信されたか否かにかかわらず）最初に送信されたサブフレームであり、参照サブフレームとして決定される。
【０１５５】
ステップ１３１６において、ＵＥは、アップリンクサブフレームの第２のバーストについてのスケジューリングを受信する。スケジューリングは、アップリンクサブフレームの第２のバーストの各サブフレームについて、関連するＨＡＲＱプロセス識別子と関連する新規データインジケータ（ＮＤＩ）とを含む。たとえば、無線デバイス１１０は、図９〜図１２のいずれかに示されているサブフレームＮ＋１５からＮ＋１７の第２のバーストのためのダウンリンクサブフレームＮ＋１１でスケジューリングを受信することができる。図９に関して、サブフレームＮ＋１５は、ＨＡＲＱ識別子Ｈ２およびＨ３に関連付けられている。Ｈ２およびＨ３の両方についてのＮＤＩは、Ｈ２およびＨ３について以前にスケジュールされた送信（すなわち、サブフレームＮ＋６）がＬＢＴ失敗のために送信されなかったので、再送信を示すようトグルされる。サブフレームＮ＋１６は、ＨＡＲＱ識別子Ｈ４およびＨ５に関連付けられている。Ｈ４およびＨ５の両方についてのＮＤＩは、Ｈ４およびＨ５について以前に送信されたサブフレーム（たとえば、サブフレームＮ＋７）が衝突エラーのために失敗したために再送を示すようトグルされる。サブフレームＮ＋１７は、ＨＡＲＱ識別子Ｈ６およびＨ７と関連付けられている。Ｈ６のＮＤＩは、ネットワークノード１２０での復号エラーのためにＨ６の以前に送信された転送ブロック（例えば、サブフレームＮ＋８）が失敗したために再送信を示すようトグルされる。Ｈ７のＮＤＩは、Ｈ７の以前に送信された転送ブロック（例えば、サブフレームＮ＋８）がネットワークノード１２０で首尾よく復号されたため、新規の送信を示すようトグルされない。
【０１５６】
アップリンクサブフレームの第２のバーストのサブフレームのうちの少なくとも１つに関連付けられたＨＡＲＱプロセス識別子が参照ＨＡＲＱプロセス識別子と一致し、関連付けられたＮＤＩが新規のデータを示すとＵＥが決定した場合、方法はステップ１３１８に進み、ＵＥはＬＢＴ競合ウィンドウサイズを最小値にリセットする。例えば、図１０に関して、無線デバイス１１０は、前のステップ１３１４でサブフレームＮ＋７が参照サブフレームであると決定する。サブフレームＮ＋７は、ネットワークノード１２０によって首尾よく受信されたＨＡＲＱ識別子Ｈ４およびＨ５と関連付けられる。したがって、サブフレームＮ＋１６に対してスケジュールされたＨＡＲＱ識別子Ｈ４およびＨ５に関連付けられてたＮＤＩは、新規の送信を示す。新規の送信の指示に基づいて、無線デバイス１１０は、カテゴリ４ＬＢＴ競合ウィンドウサイズを最小値または初期値にリセットする。
【０１５７】
アップリンクサブフレームの第２のバーストのサブフレームのうちの少なくとも１つに関連付けられたＨＡＲＱプロセス識別子が参照ＨＡＲＱプロセス識別子と一致し、関連付けられたＮＤＩが再送信を示すとき、方法はステップ１３２０に進み、ＵＥはＬＢＴ競合ウィンドウサイズを最小値にリセットする。例えば、図９に関して、無線デバイス１１０は、前のステップ１３１４においてサブフレームＮ＋７が参照サブフレームであると決定する。サブフレームＮ＋７は、ネットワークノード１２０によって首尾よく受信されなかったＨＡＲＱ識別子Ｈ４およびＨ５に関連付けられる。サブフレームＮ＋１６に対してスケジュールされたＨＡＲＱ識別子Ｈ４およびＨ５に関連付けられたＮＤＩは再送信を示す。再送信の指示に基づいて、無線デバイス１１０はカテゴリ４ＬＢＴ競合ウィンドウサイズをインクリメントする。
【０１５８】
特定の実施形態では、ＬＢＴ競合ウィンドウサイズを最小値にリセットすることは、ＬＢＴ競合ウィンドウサイズを、第１のＬＢＴ手順を実行するためにＵＥによって使用される優先度クラスに関連する値のセットの最小値にリセットすることを含む。例えば、無線デバイス１１０はサブフレームＮ＋７においてカテゴリ４ＬＢＴ手順に対して特定の優先度クラスを使用し得る。無線デバイス１１０は、その特定の優先度クラスに対して競合ウィンドウサイズをリセットすることができる。いくつかの実施形態では、ＬＢＴ競合ウィンドウサイズを最小値にリセットすることは、ＵＥによって使用されるすべての優先度クラスに関連するＬＢＴ競合ウィンドウサイズをリセットすることを含み得る。
【０１５９】
ステップ１３２２で、ＵＥは競合ウィンドウサイズを使用して第２のＬＢＴ手順を実行する。たとえば、無線デバイス１１０は、図９〜図１２のいずれかのサブフレームＮ＋１９に対してカテゴリ４ＬＢＴ手順を実行するために、ステップ１３１８または１３２０のうちの１つで変更された競合ウィンドウサイズを使用し得る。
【０１６０】
方法１３００に対して修正、追加、または省略を行うことができる。さらに、図１３の方法１３００の１つまたは複数のステップを並行してまたは任意の適切な順序で実行することができる。方法１３００のステップは、必要に応じて経時的に繰り返されてもよい。
【０１６１】
図１４は、いくつかの実施形態による、ネットワークノードにおける例示的な方法を示すフロー図である。特定の実施形態では、図１４の１つまたは複数のステップは、図８に関して説明した無線ネットワーク１００の構成要素によって実行され得る。
【０１６２】
方法はステップ１４１２で始まり、ここでネットワークノードは、第１のＬＢＴ手順の後に無線デバイスからアップリンクサブフレームの第１のバーストを受信する。アップリンクサブフレームの第１のバーストの各サブフレームは、１つまたは複数の転送ブロックに関連付けられており、各転送ブロックは、参照ＨＡＲＱプロセス識別子に関連付けられている。たとえば、図９に関して、ネットワークノード１２０は、カテゴリ４ＬＢＴ手順の後にアップリンクサブフレームＮ＋６、Ｎ＋７、Ｎ＋８、およびＮ＋９を送信するように無線デバイス１１０をスケジュールする。ネットワークノード１２０は、アップリンクサブフレームＮ＋８およびＮ＋９のバーストを受信する（Ｎ＋６は無線デバイス１１０によって送信されなかったため受信されず、Ｎ＋７は衝突エラーのため受信されない）。
【０１６３】
ステップ１４１４で、ネットワークノードは、ネットワークノードによって正常に受信されなかったアップリンクサブフレームの第１のバースト内の転送ブロックのセットを決定する。例えば、図９に関して、ネットワークノード１２０は、スケジュールされたサブフレームＮ＋６（ＨＡＲＱプロセス識別子Ｈ２およびＨ３に関連付けられた転送ブロックを有する）およびＮ＋７（ＨＡＲＱプロセス識別子Ｈ４およびＨ５に関連付けられた転送ブロックを有する）を、受信しなかったと決定する。ネットワークノード１２０はまた、サブフレームＮ＋８内のＨＡＲＱ識別子Ｈ６に関連する転送ブロックが首尾よく復号されなかったと判断する。したがって、アップリンクサブフレームの第１のバースト内の転送ブロックのセットは、ＨＡＲＱ識別子Ｈ２、Ｈ３、Ｈ４、Ｈ５、およびＨ６に関連付けられた転送ブロックを含む。
【０１６４】
ステップ１４１６で、ネットワークノードは、第２のＬＢＴ手順を用いてＵＥをスケジューリングする前に、決定された転送ブロックのセット内の転送ブロックに関連付けられたすべてのＨＡＲＱプロセス識別子を使用して、アップリンクフレームの第２のバーストでＵＥをスケジューリングする。例えば、図９に関して、ネットワークノード１２０は、ＨＡＲＱプロセス識別子Ｈ２およびＨ３のサブフレームＮ＋１５、ＨＡＲＱプロセス識別子Ｈ２およびＨ３のサブフレームＮ＋１６、およびＨＡＲＱプロセス識別子Ｈ６のサブフレームＮ＋１７で、アップリンクの無線デバイス１１０をスケジュールする。その後、ネットワークノード１２０はサブフレームＮ＋１９に対して次のカテゴリ４ＬＢＴ手順をスケジュールする。
【０１６５】
いくつかの実施形態では、前のステップ１４１４で上手く受信されなかったアップリンクサブフレームの第１のバースト内の転送ブロックのセットを決定することは、少なくとも１つの転送ブロックが首尾よく受信された受信サブフレームの前の最後のサブフレームに基づいて基準サブフレームを決定することを含む。転送ブロックのセットは、正常に受信されなかった参照サブフレーム内の転送ブロックを含む。例えば、図１２に関して、ネットワークノード１２０は、サブフレームＮ＋６が参照サブフレームであると決定することができる。アップリンクサブフレームＮ＋６からＮ＋９のバーストのうち、サブフレームＮ＋７は少なくとも１つの転送ブロックが首尾よく受信された最初のサブフレームであるため、Ｎ＋６は参照サブフレームである。Ｎ＋７の前の最後のサブフレームはＮ＋６であり、したがってＮ＋６は参照サブフレームであり、転送ブロックのセットはＨＡＲＱプロセス識別子Ｈ２およびＨ３に関連付けられた転送ブロックを含む。
【０１６６】
図１２に関するこの例では、ステップ１４１６で、ネットワークノード１２０は、ＨＡＲＱプロセス識別子Ｈ２およびＨ３のサブフレームＮ＋１６でアップリンクのために無線デバイス１１０をスケジュールする。その後、ネットワークノード１２０はサブフレームＮ＋１９に対して次のカテゴリ４ＬＢＴ手順をスケジュールする。
【０１６７】
方法１４００に対して修正、追加、または省略を行うことができる。さらに、図１４の方法１４００の１つまたは複数のステップを並行してまたは任意の適切な順序で実行することができる。方法１４００のステップは、必要に応じて経時的に繰り返されてもよい。
【０１６８】
図１５Ａは、無線デバイスの例示的な実施形態を示すブロック図である。無線デバイスは、図８に示す無線デバイス１１０の一例である。特定の実施形態では、無線デバイスは、アップリンクで送信する前にＬＢＴ手順を実行することができる。
【０１６９】
例えば、無線デバイスは、第１のＬＢＴ手順の後にアップリンクサブフレームの第１のバーストを送信するように動作可能である。ＬＢＴ手順は、ＬＢＴ競合ウィンドウサイズを使用して実行される。無線デバイスはアップリンクサブフレームの第１のバーストに基づいて参照サブフレームを決定する。参照サブフレームは、参照ＨＡＲＱプロセス識別子と関連付けられる。無線デバイスはアップリンクサブフレームの第２のバーストに対するスケジューリングを受信する。スケジューリングは、アップリンクサブフレームの第２のバーストの各サブフレームについて、関連するＨＡＲＱプロセス識別子と関連するＮＤＩとを含む。
【０１７０】
アップリンクサブフレームの第２のバーストのサブフレームのうちの少なくとも１つに関連付けられたＨＡＲＱプロセス識別子が参照ＨＡＲＱプロセス識別子と一致し、関連付けられたＮＤＩが新規のデータを示すとき、無線デバイスはＬＢＴ競合ウィンドウサイズを最小値にリセットする。アップリンクサブフレームの第２のバーストのサブフレームのうちの少なくとも１つに関連付けられたＨＡＲＱプロセス識別子が参照ＨＡＲＱプロセス識別子と一致し、関連付けられたＮＤＩが再送信を示すとき、無線デバイスはＬＢＴ競合ウィンドウサイズをインクリメントする。無線デバイスは競合ウィンドウサイズを使用して第２のＬＢＴ手順を実行する。
【０１７１】
特定の実施形態では、無線デバイスは、関連するＨＡＲＱプロセス識別子がアップリンクサブフレームの第２のバーストの受信スケジューリングにおいても見出されるアップリンクサブフレームの第１のバーストにおいて最も最近送信されたアップリンクサブフレームを決定することによって参照サブフレームを決定する。いくつかの実施形態では、無線デバイスは、アップリンクサブフレームの第１のバーストの第１のサブフレームに関連するＨＡＲＱプロセス識別子が、アップリンクサブフレームの第２のバーストについての受信スケジューリングにおいても見出される、アップリンクサブフレームの第１のバーストの第１のサブフレームを決定する。
【０１７２】
無線デバイスの特定の例は、携帯電話、スマートフォン、ＰＤＡ（パーソナルデジタルアシスタント）、ポータブルコンピュータ（例えばラップトップ、タブレット）、センサ、モデム、マシンタイプ（ＭＴＣ）装置／マシンツーマシン（Ｍ２Ｍ）デバイス、ラップトップ組み込み機器（ＬＥＥ）、ラップトップ搭載機器（ＬＭＥ）、ＵＳＢドングル、デバイスツーデバイス可能なデバイス、車両間デバイス、または無線通信を提供できるその他のデバイスを含む。無線デバイスは、送受信機１５１０、処理回路１５２０、メモリ１５３０、および電源１５４０を含む。いくつかの実施形態では、送受信機１５１０は、（たとえばアンテナを介して）無線ネットワークノード１２０への無線信号の送受信を容易にする。処理回路１５２０は、無線デバイスによって提供される本明細書に記載された機能の一部または全部を提供するために命令を実行し、メモリ１５３０は処理回路１５２０によって実行された命令を記憶する。電源１５４０は、送受信機１５１０、処理回路１５２０、および／またはメモリ１５３０などの無線デバイス１１０の１つ以上の構成要素に電力を供給する。
【０１７３】
処理回路１５２０は、１つまたは複数の集積回路またはモジュールに実装されたハードウェアおよびソフトウェアの任意の適切な組み合わせを含み、命令を実行しデータを操作して記載された無線デバイスの機能の一部または全部を実行する。いくつかの実施形態では、処理回路１５２０は、例えば、１つ以上のコンピュータ、１つ以上のプログラマブルロジックデバイス、１つ以上の中央処理装置（ＣＰＵ）、１つ以上のマイクロプロセッサ、１つ以上のアプリケーション、および／または他のロジック、および／または前述の任意の適切な組み合わせを含み得る。処理回路１５２０は、記載された無線デバイス１１０の機能の一部または全部を実行するように構成されたアナログおよび／またはデジタル回路を含み得る。例えば、処理回路１５２０は、抵抗器、コンデンサ、インダクタ、トランジスタ、ダイオード、および／または任意の他の適切な回路構成要素を含み得る。
【０１７４】
メモリ１５３０は一般に、コンピュータ実行可能コードおよびデータを格納するように動作可能である。メモリ１５３０の例は、コンピュータメモリ（例えば、ランダムアクセスメモリ（ＲＡＭ）または読み出し専用メモリ（ＲＯＭ））、大容量記憶媒体（例えば、ハードディスク）、取り外し可能記憶媒体（例えば、コンパクトディスク（ＣＤ）、またはデジタルビデオディスク（ＤＶＤ））、および／または他の任意の揮発性または不揮発性、非一時的なコンピュータ可読および／またはコンピュータ実行可能な情報を記憶するメモリデバイスを含む。
【０１７５】
電源１５４０は、一般に、無線デバイス１１０の構成要素に電力を供給するように動作可能である。電源１５４０は、リチウムイオン、リチウムエア、リチウムポリマー、ニッケルカドミウム、ニッケル金属水素化物、無線デバイスに電力を供給するための任意の他の適切な種類の電池などの任意の適切な種類の電池を含み得る。
【０１７６】
特定の実施形態では、送受信機１５１０と通信している処理回路１５２０は、アップリンクで送信する前にＬＢＴ手順を実行する。例えば、送受信機１５１０と通信している処理回路１５２０は、連続アップリンクサブフレームの現在のバーストについてのスケジューリングを受信し、連続アップリンクサブフレームの以前にスケジュールされたバーストに基づいて参照サブフレームを決定し、参照サブフレームに基づいてＬＢＴ競合ウィンドウを調整する。
【０１７７】
無線デバイスの他の実施形態は、上述の機能のいずれかおよび／または任意の追加の機能（上述の解決策をサポートするのに必要な機能を含む）を含む、無線デバイスの機能の特定の態様を提供する役割を果たす追加の構成要素（図１５Ａに示すものを超える）を含み得る。
【０１７８】
図１５Ｂは、無線デバイス１１０の例示的な構成要素を示すブロック図である。構成要素は、送信モジュール１５５０、決定モジュール１５５２、ＬＢＴモジュール１５５４、および受信モジュール１５５６を含み得る。
【０１７９】
送信モジュール１５５０は、無線デバイス１１０の送信機能を実行し得る。たとえば、送信モジュール１５５０は、第１のＬＢＴ手順の後にアップリンクサブフレームの第１のバーストを送信し得る。送信モジュール１５５０は、図９〜図１４を含む上記の例のいずれかにおいて説明された送信機能を実行することができる。特定の実施形態では、送信モジュール１５５０は、処理回路１５２０を含むか、またはそれに含めることができる。特定の実施形態では、送信モジュール１５５０は、判定モジュール１５５２、ＬＢＴモジュール１５５４、および受信モジュール１５５６と通信することができる。
【０１８０】
決定モジュール１５５２は、無線デバイス１１０の決定機能を実行し得る。たとえば、決定モジュール１５５２は、図９〜図１４を含む上記の例のうちのいずれかで説明されるように、参照サブフレームを決定し、競合ウィンドウサイズを決定し得る。特定の実施形態において、決定モジュール１５５２は、処理回路１５２０を含み得るか、またはそれに含まれ得る。特定の実施形態において、決定モジュール１５５２は、送信モジュール１５５０、ＬＢＴモジュール１５５４、および受信モジュール１５５６と通信し得る。
【０１８１】
ＬＢＴモジュール１５５４は、無線デバイス１１０のリッスンビフォートーク機能を実行し得る。例えば、ＬＢＴモジュール１５５４は、ランダムバックオフを用いてＬＢＴ手順を実行してもよく、または固定継続時間のクリアチャネルアセスメントを実行してもよい。ＬＢＴモジュール１５５４は、ＬＢＴを実行するための競合ウィンドウサイズをインクリメントまたはリセットすることができる。特定の実施形態では、ＬＢＴモジュール１５５４は、処理回路１５２０を含むか、またはそれに含めることができる。特定の実施形態では、ＬＢＴモジュール１５５４は、送信モジュール１５５０、決定モジュール１５５２、および受信モジュール１５５６と通信することができる。
【０１８２】
受信モジュール１５５６は、無線デバイス１１０の受信機能を実行し得る。たとえば、受信モジュール１５５６は、アップリンクサブフレームのバーストについてのスケジューリングを受信し得る。特定の実施形態において、受信モジュール１５５６は、処理回路１５２０を含むか、またはそれに含まれ得る。特定の実施形態において、受信モジュール１５５６は、送信モジュール１５５０、決定モジュール１５５２、およびＬＢＴモジュール１５５４と通信し得る。
【０１８３】
図１６Ａは、ネットワークノードの例示的な実施形態を示すブロック図である。ネットワークノードは、図８に示すネットワークノード１２０の一例である。特定の実施形態では、ネットワークノードは、競合ウィンドウサイズを管理し、その競合ウィンドウサイズを無線デバイスにシグナリングすることができる。例えば、ネットワークノードは、第１のＬＢＴ手順の後に無線デバイスからアップリンクサブフレームの第１のバーストを受信することができる。アップリンクサブフレームの第１のバーストの各サブフレームは１つまたは複数の転送ブロックと関連付けられ、各転送ブロックはＨＡＲＱプロセス識別子と関連付けられる。ネットワークノードは、ネットワークノードによってうまく受信されなかったアップリンクサブフレームの第１のバースト内の転送ブロックのセットを決定する。第２のＬＢＴ手順を用いて無線デバイスをスケジューリングする前に、ネットワークノードは、決定された転送ブロックのセット内の転送ブロックに関連付けられたすべてのＨＡＲＱプロセス識別子を使用して、アップリンクフレームの第２のバーストを用いて無線デバイスをスケジュールする。
【０１８４】
特定の実施形態では、ネットワークノードは、少なくとも１つの転送ブロックが首尾よく受信された受信サブフレームの前の最後のサブフレームに基づいて参照サブフレームを決定する。転送ブロックのセットは、正常に受信されなかった参照サブフレーム内の転送ブロックを含んでいる。
【０１８５】
ネットワークノード１２０は、ｅノードＢ、ノードＢ、基地局、無線アクセスポイント（例えば、Ｗｉ−Ｆｉアクセスポイント）、低電力ノード、基地送受信局（ＢＴＳ）、送信ポイントまたはノード、リモートＲＦユニット（ＲＲＵ）、リモートラジオヘッド（ＲＲＨ）、またはその他の無線アクセスノードであり得る。ネットワークノードは、少なくとも１つの送受信機１６１０、少なくとも１つの処理回路１６２０、少なくとも１つのメモリ１６３０、および少なくとも１つのネットワークインタフェース１６４０を含む。送受信機１６１０は、（例えば、アンテナを介して）無線デバイス１１０のような無線デバイスへの無線信号の送受信を容易にする。処理回路１６２０は、ネットワークノード１２０によって提供されるものとして上述した機能の一部または全部を提供するための命令を実行する。メモリ１６３０は、処理回路１６２０によって実行された命令を格納する。ネットワークインタフェース１６４０は、ゲートウェイ、スイッチ、ルータ、インターネット、公衆交換電話網（ＰＳＴＮ）、コントローラ、および／または他のネットワークノード１２０などのバックエンドネットワーク構成要素と信号を通信する。処理回路１６２０およびメモリ１６３０は、上の図１５Ａの処理回路１５２０およびメモリ１５３０に関して説明したものと同じタイプであり得る。
【０１８６】
いくつかの実施形態では、ネットワークインタフェース１６４０は処理回路１６２０に通信可能に結合され、ネットワークノード１２０への入力の受信、ネットワークノード１２０からの出力の送信、入力または出力またはその両方の適切な処理の実行、他のデバイスとの通信、またはこれらの任意の組み合わせ、を実行可能な任意の適切なデバイスを指す。ネットワークインタフェース１６４０は、ネットワークを介して通信するための適切なハードウェア（例えば、ポート、モデム、ネットワークインタフェースカードなど）およびソフトウェア（プロトコル変換機能およびデータ処理機能を含む）を含む。
【０１８７】
特定の実施形態では、送受信機１６１０と通信している処理回路１６２０は、競合ウィンドウサイズについての情報をシグナリングするための参照サブフレームを決定する。
【０１８８】
ネットワークノード１２０の他の実施形態は、上述の機能のいずれかおよび／または任意の追加の機能（上述の解決策をサポートするのに必要な機能を含む）を含む、ネットワークノードの機能の特定の態様を提供する役割を果たす追加の構成要素（図１６Ａに示すものを超える）を含み得る。様々な異なる種類のネットワークノードは、同じ物理ハードウェアを有するが異なる無線アクセス技術をサポートするように（例えばプログラミングによって）構成された構成要素を含むことができ、あるいは部分的または全体的に異なる物理構成要素を含み得る。
【０１８９】
図１６Ｂは、ネットワークノード１２０の例示的な構成要素を示すブロック図である。構成要素は、受信モジュール１６５０、決定モジュール１６５２、およびＬＢＴモジュール１６５４を含み得る。
【０１９０】
受信モジュール１６５０は、ネットワークノード１２０の受信機能を実行することができる。例えば、受信モジュール１６５０は、ＬＢＴ手順の後に無線デバイスからアップリンクサブフレームのバーストを受信することができる。特定の実施形態において、受信モジュール１６５０は、処理回路１６２０を含むか、またはそれに含まれ得る。特定の実施形態において、受信モジュール１６５０は、決定モジュール１６５２およびＬＢＴモジュール１６５４と通信し得る。
【０１９１】
決定モジュール１６５２は、ネットワークノード１２０の決定機能を実行することができる。例えば、決定モジュール１６５２は、ネットワークノードによって正常に受信されなかったアップリンクサブフレームのバースト内の転送ブロックのセットを決定することができる。特定の実施形態において、決定モジュール１６５２は、処理回路１６２０を含むか、またはそれに含まれ得る。特定の実施形態において、決定モジュール１６５２は、受信モジュール１６５０およびＬＢＴモジュール１６５４と通信し得る。
【０１９２】
ＬＢＴモジュール１６５４は、ネットワークノード１２０のＬＢＴ機能を実行することができる。例えば、ＬＢＴモジュール１６５４は、受信に失敗した転送ブロックに関連付けられたすべてのＨＡＲＱプロセス識別子を使用してアップリンクフレームの第２のバーストで無線デバイスをスケジュールし得る。特定の実施形態では、ＬＢＴモジュール１６５４は処理回路１６２０を含むかまたはそれに含めることができる。特定の実施形態では、ＬＢＴモジュール１６５４は受信モジュール１６５０および決定モジュール１６５２と通信することができる。
【０１９３】
本発明の範囲から逸脱することなく、本明細書に開示されているシステムおよび装置に対して修正、追加、または省略を行うことができる。システムおよび装置の構成要素は統合されても分離されてもよい。さらに、システムおよび装置の動作は、より多い、より少ない、または他の構成要素によって実行され得る。さらに、システムおよび装置の動作は、ソフトウェア、ハードウェア、および／または他のロジックを含む任意の適切なロジックを使用して実行され得る。この文書で使用されているように、「それぞれ（each）」とは、セットの各メンバーまたはセットのサブセットの各メンバーを指す。
【０１９４】
本発明の範囲から逸脱することなく、本明細書に開示された方法に対して修正、追加、または省略をすることができる。方法は、より多い、より少ない、または他のステップを含み得る。さらに、ステップは任意の適切な順序で実行され得る。
【０１９５】
本開示はある実施形態に関して説明されてきたが、実施形態の変更および置換は当業者に明らかであろう。したがって、実施形態の上記の説明は本開示を制限しない。添付の特許請求の範囲によって定義されるように、本開示の精神および範囲から逸脱することなく、他の変更、置換、および改変が可能である。
【０１９６】
上述の説明で使用されている略語は以下を含む。
３ＧＰＰ  第三世代パートナーシッププロジェクト
ＡＣＫ  肯定応答
ＢＴＳ  基地送受信局
ＣＣＡ  クリアチャネルアセスメント
ＣＷ  競合ウィンドウ
Ｄ２Ｄ  デバイスツーデバイス
ＤＣＦ  分散調整機能
ＤＩＦＳ  ＤＣＦフレーム間間隔
ＤＬ  ダウンリンク
ｅＮＢ  ｅノードＢ
ＦＤＤ  周波数分割多重
ＨＡＲＱ  ハイブリッド自動再送要求
ＬＡＡ  ライセンス支援アクセス
ＬＢＴ  リッスンビフォアトーク
ＬＴＥ  ロングタームエボリューション
ＭＡＣ  媒体アクセス制御
Ｍ２Ｍ  マシンツーマシン
ＭＩＭＯ  多入力多出力
ＭＲＢＣ  複数ランダムバックオフチャネル
ＭＴＣ  マシンタイプ通信
ＮＡＫ  否定応答
ＮＲ  ニューラジオ
ＰＤＳＣＨ  物理ダウンリンク共有チャネル
ＰＩＦＳ  ＰＣＦフレーム間間隔
ＰＵＣＣＨ  物理アップリンク制御チャネル
ＱＣＩ  ＱｏＳクラスインジケータ
ＱｏＳ  サービス品質
ＲＡＮ  無線アクセスネットワーク
ＲＡＴ  無線アクセス技術
ＲＢ  無線ベアラ
ＲＢＳ  無線基地局
ＲＮＣ  無線ネットワークコントローラ
ＲＲＣ  無線リソース制御
ＲＲＨ  リモーラジオヘッド
ＲＲＵ  リモートラジオユニット
ＳＣｅｌｌ  二次セル
ＳＲＢＣ  単一ランダムバックオフチャネル
ＳＩＦＳ  ショートフレーム間間隔
ＴＤＤ  時分割多重
ＵＥ  ユーザ装置
ＵＬ  アップリンク
ＵＴＲＡＮ  ユニバーサル地上無線アクセスネットワーク
ＷＡＮ  無線アクセスネットワーク
【図１】
2019525603.tif 000003
【図２】
2019525603.tif 000004
【図３】
2019525603.tif 000005
【図４】
2019525603.tif 000006
【図５】
2019525603.tif 000007
【図６】
2019525603.tif 000008
【図７】
2019525603.tif 000009
【図８】
2019525603.tif 000010
【図９】
2019525603.tif 000011
【図１０】
2019525603.tif 000012
【図１１】
2019525603.tif 000013
【図１２】
2019525603.tif 000014
【図１３】
2019525603.tif 000015
【図１４】
2019525603.tif 000016
【図１５Ａ】
2019525603.tif 000017
【図１５Ｂ】
2019525603.tif 000018
【図１６Ａ】
2019525603.tif 000019
【図１６Ｂ】
2019525603.tif 000020
【国際調査報告】
2019525603.tif 000021
2019525603.tif 000022
2019525603.tif 000023
2019525603.tif 000024