(57)【要約】  進化型ノードＢ（ｅＮＢ）およびＨＡＲＱ送信の方法の実施形態が、本明細書に開示される。ｅＮＢは低遅延化ユーザ機器（ＵＥ）に、低遅延化データブロック用の初期ＨＡＲＱブロックおよびダイバーシティＨＡＲＱブロックを送信してもよい。ＨＡＲＱブロックの送信間のサブフレーム間隔は、低遅延化ＵＥとして動作していないＵＥへのＨＡＲＱブロックの送信に使用されるサブフレーム間隔よりも狭くてもよい。低遅延化データブロック用のＨＡＲＱブロックは、低遅延化ＵＥとのＨＡＲＱプロセスのために確保された時間および周波数リソースの低遅延化領域内で送信されてもよい。加えて、ＨＡＲＱブロックは、低遅延化領域を除く時間および周波数リソース内で、低遅延化ＵＥとして動作していないその他のＵＥに送信されてもよい。
2017523641.tif 000002
【特許請求の範囲】
【請求項１】
トランシーバ回路を含むハードウェア処理回路を備える進化型ノードＢ（ｅＮＢ）であって、
第一ユーザ機器（ＵＥ）とのハイブリッド自動再送要求（ＨＡＲＱ）プロセスの一部として、
第一データブロック用の初期ＨＡＲＱブロックを送信するように、および
前記第一データブロック用の前記ＨＡＲＱブロックの送信が所定のＨＡＲＱ区間によって時間的に離間したサブフレームの間に行われるよう、前記第一データブロック用のダイバーシティＨＡＲＱブロックを送信するように、
低遅延化ＵＥとのＨＡＲＱプロセスの一部として、
低遅延化データブロック用の初期ＨＡＲＱブロックを送信するように、および
前記低遅延化データブロック用の前記ＨＡＲＱブロックの送信が、前記ＨＡＲＱ区間よりも短い所定の低遅延化ＨＡＲＱ区間によって時間的に離間したサブフレームの間に行われるよう、前記低遅延化データブロック用のダイバーシティＨＡＲＱブロックを送信するように、
構成されている、ｅＮＢ。
【請求項２】
前記低遅延化データブロック用の前記ＨＡＲＱブロックは、低遅延化ＵＥとのＨＡＲＱプロセスのために確保された時間および周波数リソース内で送信され、
前記第一データブロック用の前記ＨＡＲＱブロックは、低遅延化ＵＥとのＨＡＲＱプロセスのために確保されたものを除く時間および周波数リソース内で送信される、
請求項１に記載のｅＮＢ。
【請求項３】
前記サブフレームは、１つ以上のロングタームエボリューション（ＬＴＥ）規格にしたがって構成されており、
前記ＨＡＲＱブロックは１つ以上の直交周波数分割多重（ＯＦＤＭ）信号を用いて送信され、前記ＯＦＤＭ信号の周波数リソースは複数のリソース要素（ＲＥ）を備える、
請求項２に記載のｅＮＢ。
【請求項４】
前記サブフレームは、低遅延化ＵＥとのＨＡＲＱプロセスのために確保された時間および周波数リソースの低遅延化領域と、前記低遅延化領域専用の時間および周波数リソースの通常領域と、を備え、
前記ＯＦＤＭ周波数リソースは複数のリソースブロック（ＲＢ）を含み、各ＲＢは周波数が隣接する複数のＲＥを備え、
前記低遅延化領域は、周波数における前記ＲＢの少なくとも一部と、時間における複数の低遅延サブフレーム（ＬＬＳＦ）と、を含み、各ＬＬＳＦはＯＦＤＭ符号の隣接グループに及び、
前記ＬＬＳＦは、データブロックの送信用の低遅延データチャネル（ＬＬＤＣ）と、前記データブロックの制御情報を含む低遅延制御チャネル（ＬＬＣＣ）と、を備える、
請求項３に記載のｅＮＢ。
【請求項５】
前記サブフレームは、低遅延化ＵＥとのＨＡＲＱプロセスのために確保された時間および周波数リソースの低遅延化領域と、前記低遅延化領域専用の時間および周波数リソースの通常領域と、を備え、
前記低遅延化領域は１つ以上の低遅延サブフレーム（ＬＬＳＦ）を含み、各ＬＬＳＦは、データブロックの送信用の低遅延データチャネル（ＬＬＤＣ）と、前記データブロックの制御情報を含む低遅延制御チャネル（ＬＬＣＣ）と、を備え、前記ＬＬＤＣおよび前記ＬＬＣＣは単一のＯＦＤＭ符号の間に周波数が多重化される、
請求項３に記載のｅＮＢ。
【請求項６】
前記サブフレームの各々は、前記サブフレーム内の第一ＯＦＤＭ符号を含むＯＦＤＭ符号の隣接グループに及ぶ物理ダウンリンク制御チャネル（ＰＤＣＣＨ）をさらに備え、
前記ＰＤＣＣＨは、低遅延化ＵＥとのＨＡＲＱプロセスのために確保された時間および周波数リソースを識別する情報を含む、
請求項３に記載のｅＮＢ。
【請求項７】
前記第一データブロック用の前記初期ＨＡＲＱブロックおよび前記低遅延化データブロック用の前記初期ＨＡＲＱブロックは同じサブフレームの間に送信される、請求項３に記載のｅＮＢ。
【請求項８】
前記ハードウェア処理回路は前記トランシーバ回路に、
前記第一データブロック用の受信されたＨＡＲＱ確認標識が、前記第一データブロック用の前記初期ＨＡＲＱブロックに基づいて前記第一データブロックの、前記第一ＵＥにおける復号の成功を示すときに、前記第一データブロック用の前記ダイバーシティＨＡＲＱブロックの送信を控えさせるように、および
前記低遅延化データブロック用の受信されたＨＡＲＱ確認標識が、前記低遅延化データブロック用の前記初期ＨＡＲＱブロックに基づいて前記低遅延化データブロックの、前記低遅延化ＵＥにおける復号の成功を示すときに、前記低遅延化データブロック用の前記ダイバーシティＨＡＲＱブロックの送信を控えさせるように、
構成されている、請求項３に記載のｅＮＢ。
【請求項９】
前記ハードウェア処理回路は、前記低遅延化データブロック用の前記初期ＨＡＲＱブロックの送信の１ミリ秒以内に、前記低遅延化ＵＥにおける、前記低遅延化データブロック用の前記初期ＨＡＲＱブロックの復号成功の確認標識を前記トランシーバ回路に受信させるように構成されている、請求項１に記載のｅＮＢ。
【請求項１０】
前記低遅延化データブロック用の前記ＨＡＲＱブロックは、低遅延化ＨＡＲＱトラフィックのために確保された時間および周波数リソースの中で送信され、
前記第一データブロック用の前記ＨＡＲＱブロックは、低遅延化ＨＡＲＱトラフィックのために確保されたものを除く時間および周波数リソースの中で送信される、
請求項１に記載のｅＮＢ。
【請求項１１】
ハイブリッド自動再送要求（ＨＡＲＱ）データ送信の方法であって、前記方法は、
サブフレームのグループの間に１つ以上の初期ＨＡＲＱブロックを送信するステップであって、各サブフレームの時間および周波数リソースは、低遅延化ＨＡＲＱ送信のために確保された低遅延化部分と、前記低遅延化部分専用の通常部分と、を備える、ステップと、
データブロックの復号の成功の１つ以上のＨＡＲＱ確認標識を受信するステップと、
サブフレームの前記グループの間に、前記ＨＡＲＱ確認標識によってうまく復号されたと通知されない各データブロック用のダイバーシティＨＡＲＱブロックを送信するステップと、
を備え、
各ダイバーシティＨＡＲＱブロックは、対応する初期ＨＡＲＱブロックと比較して、サブフレームの所定間隔にしたがって送信され、前記低遅延化部分の間隔は前記通常部分の間隔よりも狭い、
方法。
【請求項１２】
前記サブフレームは、１つ以上のロングタームエボリューション（ＬＴＥ）規格にしたがって構成され、
前記ＨＡＲＱブロックは、複数のリソース要素（ＲＥ）を備えるＯＦＤＭ周波数リソースを使用する１つ以上の直交周波数分割多重（ＯＦＤＭ）信号を用いて送信される、
請求項１１に記載の方法。
【請求項１３】
前記ＯＦＤＭ周波数リソースは複数のリソースブロック（ＲＢ）を含み、各ＲＢは周波数が隣接する複数のＲＥを備え、
前記低遅延化部分は、周波数における１つ以上のＲＢおよび時間における複数の低遅延サブフレーム（ＬＬＳＦ）を含み、各ＬＬＳＦはＯＦＤＭ符号の隣接グループに及び、
前記ＬＬＳＦは、データブロックの送信用の低遅延データチャネル（ＬＬＤＣ）と、前記データブロックの制御情報を含む低遅延制御チャネル（ＬＬＣＣ）と、を備える、
請求項１２に記載の方法。
【請求項１４】
前記低遅延化部分は１つ以上の低遅延サブフレーム（ＬＬＳＦ）を含み、各ＬＬＳＦは、データブロックの送信用の低遅延データチャネル（ＬＬＤＣ）と、前記データブロックの制御情報を含む低遅延制御チャネル（ＬＬＣＣ）と、を備え、前記ＬＬＤＣおよび前記ＬＬＣＣは、単一のＯＦＤＭ符号の間に周波数が多重化される、請求項１２に記載の方法。
【請求項１５】
前記サブフレームの各々は、前記サブフレーム内の第一ＯＦＤＭ符号を含むＯＦＤＭ符号の隣接グループに及ぶ物理ダウンリンク制御チャネル（ＰＤＣＣＨ）を、さらに備え、
前記ＰＤＣＣＨは、前記低遅延化部分の時間および周波数リソースを識別する情報を含む、
請求項１２に記載の方法。
【請求項１６】
ハイブリッド自動再送要求（ＨＡＲＱ）送信の動作を行うための１つ以上のプロセッサによる実行のための命令を有するコンピュータプログラムであって、動作はトランシーバに、
第一ユーザ機器（ＵＥ）とのＨＡＲＱプロセスとして、
第一データブロック用の初期ＨＡＲＱブロックを送信させるように、および
前記第一データブロック用の前記ＨＡＲＱブロックの送信が所定のＨＡＲＱ区間によって時間的に離間したサブフレームの間に行われるよう、前記第一データブロック用のダイバーシティＨＡＲＱブロックを送信させるように、
低遅延化ＵＥとのＨＡＲＱプロセスの一部として、
低遅延化データブロック用の初期ＨＡＲＱブロックを送信させるように、および
前記低遅延化データブロック用の前記ＨＡＲＱブロックの送信が、前記ＨＡＲＱ区間よりも短い所定の低遅延化ＨＡＲＱ区間によって時間的に離間したサブフレームの間に行われるよう、前記低遅延化データブロック用のダイバーシティＨＡＲＱブロックを送信させるように、
１つ以上のプロセッサを構成する、コンピュータプログラム。
【請求項１７】
前記低遅延化データブロック用の前記ＨＡＲＱブロックは、低遅延化ＵＥとのＨＡＲＱプロセスのために確保された時間および周波数リソース内で送信され、
前記第一データブロック用の前記ＨＡＲＱブロックは、低遅延化ＵＥとのＨＡＲＱプロセスのために確保された時間および周波数リソース内で送信される、
請求項１６に記載のコンピュータプログラム。
【請求項１８】
前記サブフレームは、１つ以上のロングタームエボリューション（ＬＴＥ）規格にしたがって構成されており
前記ＨＡＲＱブロックは、複数のリソース要素（ＲＥ）を備えるＯＦＤＭ周波数リソースを使用する１つ以上の直交周波数分割多重（ＯＦＤＭ）信号を用いて送信される、
請求項１７に記載のコンピュータプログラム。
【請求項１９】
トランシーバ回路を含むハードウェア処理回路を備えるユーザ機器（ＵＥ）であって、
第一ダウンリンクサブフレームの間に、ダウンリンクデータブロックに基づく初期ハイブリッド自動再送要求（ＨＡＲＱ）ブロックを受信するように、
アップリンクサブフレームの間に、受信した前記初期ＨＡＲＱブロックに基づいて前記ダウンリンクデータブロックの復号の成功を示すＨＡＲＱ確認標識を送信するように、および
第二ダウンリンクサブフレームの間にダイバーシティＨＡＲＱブロックを受信するように、構成されており、前記ダイバーシティＨＡＲＱブロックは前記ダウンリンクデータブロックに基づき、前記初期ＨＡＲＱブロックおよび前記ダイバーシティＨＡＲＱブロックは前記ダウンリンクデータブロックの復号の組み合わせを可能にし、
前記第二ダウンリンクサブフレームと前記アップリンクサブフレームとの間の時間差および前記アップリンクサブフレームと前記第一ダウンリンクサブフレームとの間の時間差は、通常モードでのＵＥ動作と比較して低遅延化モードでのＵＥ動作の方が小さい、
ＵＥ。
【請求項２０】
前記アップリンクおよびダウンリンクサブフレームの各々は、前記低遅延化モード用の時間および周波数リソースの低遅延化部分を備え、前記低遅延化部分専用の時間および周波数リソースの通常部分をさらに備える、請求項１９に記載のＵＥ。
【請求項２１】
前記ＵＥが低遅延化モードで動作するとき、前記ＨＡＲＱブロックは前記ダウンリンクサブフレームの前記低遅延化部分で受信され、前記ＨＡＲＱ確認標識は前記アップリンクサブフレームの前記低遅延化部分で送信され、
前記ＵＥが通常モードで動作するとき、前記ＨＡＲＱブロックは前記ダウンリンクサブフレームの前記通常部分で受信され、前記ＨＡＲＱ確認標識は前記アップリンクサブフレームの前記通常部分で送信される、
請求項２０に記載のＵＥ。
【請求項２２】
前記アップリンクおよびダウンリンクサブフレームは１つ以上のロングタームエボリューション（ＬＴＥ）規格にしたがって構成されており、
前記アップリンクまたはダウンリンクサブフレームの少なくとも１つの前記低遅延化部分は１つ以上の低遅延サブフレーム（ＬＬＳＦ）を含み、各ＬＬＳＦは時間的に直交周波数分割多重（ＯＦＤＭ）符号の隣接グループに及んでおり、
前記ＬＬＳＦは、データブロックの送信用の低遅延データチャネル（ＬＬＤＣ）と、前記データブロックの制御情報を含む低遅延制御チャネル（ＬＬＣＣ）と、を備える、
請求項２１に記載のＵＥ。
【請求項２３】
前記アップリンクおよびダウンリンクサブフレームは１つ以上のロングタームエボリューション（ＬＴＥ）規格にしたがって構成されており、
前記アップリンクまたはダウンリンクサブフレームの少なくとも１つの前記低遅延化部分は１つ以上の低遅延サブフレーム（ＬＬＳＦ）を含み、各ＬＬＳＦは、データブロックの送信用の低遅延データチャネル（ＬＬＤＣ）と、前記データブロックの制御情報を含む低遅延制御チャネル（ＬＬＣＣ）と、を備え、前記ＬＬＤＣおよび前記ＬＬＣＣは、直交周波数分割多重（ＯＦＤＭ）符号の間に周波数が多重化される、
請求項２１に記載のＵＥ。
【請求項２４】
前記アップリンクおよびダウンリンクサブフレームは、前記第一ダウンリンクサブフレームに及ぶ時間枠が第一アップリンクサブフレームに含まれる最後のＯＦＤＭ符号のグループおよび第二アップリンクサブフレームに含まれる最初の符号のグループにも及ぶように、時間的に交互になっている、請求項２３に記載のＵＥ。
【請求項２５】
前記ハードウェア処理回路は前記トランシーバ回路に、
前記ＵＥによる物理アップリンク共有チャネル（ＰＵＳＣＨ）データブロックの送信用のアップリンクスケジューリンググラントを受信させるように、および
予め決められた前記ＰＵＳＣＨデータブロックの送信と前記アップリンクスケジューリンググラントの受信との間の時間差にしたがって前記ＰＵＳＣＨデータブロックを送信するように、構成されており、前記時間差は、通常モードでのＵＥ動作と比較して低遅延化モードでのＵＥ動作の方が小さい、
請求項２１に記載のＵＥ。
【請求項２６】
前記ＵＥが前記低遅延化モードで動作するとき、前記ＰＵＳＣＨデータブロックは前記アップリンクサブフレームの前記低遅延化部分内で送信され、
前記ＵＥが前記通常モードで動作するとき、前記ＰＵＳＣＨデータブロックは前記アップリンクサブフレームの前記低遅延化部分で送信される、
請求項２５に記載のＵＥ。
【請求項２７】
前記初期およびダイバーシティＨＡＲＱブロックの受信および前記ＨＡＲＱ確認標識の送信は、ＨＡＲＱプロセスの一部として実行され、
前記時間差は、通常ＨＡＲＱプロセスよりも低遅延化ＨＡＲＱプロセスの方が小さく、
前記ハードウェア処理回路は、重複期間の間に低遅延化ＨＡＲＱプロセスおよび通常プロセスをサポートするようにさらに構成されている、
請求項１９に記載のＵＥ。
【請求項２８】
請求項１６乃至１８のうちいずれか１項記載のコンピュータプログラムを記憶したコンピュータ読取り可能な記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本明細書は、各々その全体が参照により本明細書に組み込まれる、２０１４年８月１２日出願の米国特許仮出願第６２／０３６，５２３号明細書、および２０１４年６月２日出願の米国特許仮出願第６２／００６，７５４号明細書の優先権の恩典を主張する、２０１５年３月２６日出願の米国特許出願第１４／６６９，１７６号明細書の優先権の恩典を主張する。
【０００２】
実施形態は、無線通信に関連する。実施形態の範囲はこの点に関して限定されるものではないが、いくつかの実施形態は、３ＧＰＰ（Ｔｈｉｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ；第三世代パートナーシッププロジェクト）ネットワーク、３ＧＰＰ  ＬＴＥ（Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ；ロングタームエボリューション）ネットワーク、および３ＧＰＰ  ＬＴＥ−Ａ（ＬＴＥアドバンスト）ネットワークを含む、セルラー通信ネットワークに関する。いくつかの実施形態は、ハイブリッド自動再送要求（ＨＡＲＱ；Ｈｙｂｒｉｄ  Ａｕｔｏｍａｔｉｃ  Ｒｅｐｅａｔ  Ｒｅｑｕｅｓｔ）通信に関する。いくつかの実施形態は、低遅延（ｌｏｗ−ｌａｔｅｎｃｙ）または低遅延化（ｒｅｄｕｃｅｄ−ｌａｔｅｎｃｙ）通信に関する。
【背景技術】
【０００３】
セルラーネットワークを動作するユーザ機器（ＵＥ）は、ネットワークとのパケット交換の遅延など、異なる特性にしたがって動作する様々なアプリケーションをサポートすることができる。ミッションクリティカルアプリケーションおよびリアルタイムゲーミングなど、いくつかのアプリケーションは、比較的低遅延の恩恵を受ける。ファイル転送などその他のアプリケーションは、比較的緩和された遅延仕様の下で動作することができる。ネットワークは場合によりこれらおよびその他のアプリケーションを同時にサポートする必要があるので、異なる遅延特性を有するアプリケーションをサポートする方法およびシステムの一般的な需要がある。加えて、エアインターフェースに関連する遅延を低減できるものを含む、遅延を低減する方法およびシステムもまた必要とされる。
【図面の簡単な説明】
【０００４】
【図１】いくつかの実施形態による、３ＧＰＰネットワークの機能図である。
【図２】いくつかの実施形態による、ユーザ機器（ＵＥ）の機能図である。
【図３】いくつかの実施形態による、進化型ノードＢ（ｅＮＢ）の機能図である。
【図４】いくつかの実施形態による、複数のハイブリッド自動再送要求（ＨＡＲＱ）通信プロセスの例示的シナリオを説明する図である。
【図５】いくつかの実施形態による、ＨＡＲＱ通信の方法の動作を説明する図である。
【図６】いくつかの実施形態による、サブフレームの一例を説明する図である。
【図７】いくつかの実施形態による、サブフレームの別の例を説明する図である。
【図８】いくつかの実施形態による、サブフレームの別の例を説明する図である。
【図９】いくつかの実施形態による、ＨＡＲＱ通信の別の方法の動作を説明する図である。
【図１０】いくつかの実施形態による、ダウンリンクおよびアップリンクスケジューリングの一例を説明する図である。
【図１１】いくつかの実施形態による、ダウンリンクおよびアップリンクスケジューリングの別の例を説明する図である。
【図１２】いくつかの実施形態による、ダウンリンクおよびアップリンクスケジューリングの別の例を説明する図である。
【図１３】いくつかの実施形態による、ダウンリンクおよびアップリンクスケジューリングの別の例を説明する図である。
【発明を実施するための形態】
【０００５】
以下の説明および図面は、当業者が実践できるようにするための、具体的な実施形態を示す。その他の実施形態は、構造的、論理的、電気的、プロセス、およびその他の変更を組み込んでもよい。いくつかの実施形態の部分および特徴は、その他の実施形態のものに含まれるか、または置き換えられてもよい。請求項に記載される実施形態は、これら請求項のすべての利用可能な同等物を包含する。
【０００６】
図１は、いくつかの実施形態による３ＧＰＰネットワークの機能図である。ネットワークは、Ｓ１インターフェース１１５を通じて互いに結合された、無線アクセスネットワーク（ＲＡＮ）（たとえば、図示されるように、Ｅ−ＵＴＲＡＮすなわち発展型ユニバーサル地上無線アクセスネットワーク）１００、およびコアネットワーク１２０（たとえば、発展型パケットコア（ＥＰＣ）として示される）を備える。便宜上、および簡潔さのため、ＲＡＮ１００はもちろんコアネットワーク１２０もほんの一部のみが示される。
【０００７】
コアネットワーク１２０は、移動管理エンティティ（ＭＭＥ；Ｍｏｂｉｌｉｔｙ  Ｍａｎａｇｅｍｅｎｔ  Ｅｎｔｉｔｙ）１２２、サービングゲートウェイ（サービングＧＷ）１２４、およびパケットデータネットワークゲートウェイ（ＰＤＮ  ＧＷ）１２６を含む。ＲＡＮ１００は、ユーザ機器（ＵＥ）１０２と通信するための（基地局として動作する）進化型ノードＢ（ｅＮＢ）１０４を含む。ｅＮＢ１０４は、マクロｅＮＢおよび低電力（ＬＰ）ｅＮＢを含んでもよい。いくつかの実施形態によれば、ｅＮＢ１０４は、ＵＥ１０２での受信のため、データブロックのためのハイブリッド自動再送要求（ＨＡＲＱ）パケットを送信してもよい。ｅＮＢ１０４はまた、データブロックのためのＨＡＲＱ確認標識を受信するが、これはＵＥ１０２がデータブロックをうまく復号したか否かを示すことができる。
【０００８】
ＭＭＥ１２２は、レガシーサービングＧＰＲＳサポートノード（ＳＧＳＮ）の制御プレーンと類似の機能である。ＭＭＥ１２２は、ゲートウェイ選択および追跡領域リスト管理など、アクセスにおける移動局面を管理する。サービングＧＷ１２４は、ＲＡＮ１００に向けたインターフェースを終了し、ＲＡＮ１００とコアネットワーク１２０との間でデータパケットを転送する。加えて、これはｅＮＢ間ハンドオーバのためのローカルモビリティアンカーポイントであってもよく、また３ＧＰＰ間移動性のためのアンカーを提供してもよい。その他の責任としては、合法的傍受、課金、および何らかのポリシー強制を含んでもよい。サービングＧＷ１２４およびＭＭＥ１２２は、単一の物理ノードまたは個別の物理ノード内で実現されてもよい。ＰＤＮ  ＧＷ１２６は、パケットデータネットワーク（ＰＤＮ）に向けたＳＧｉインターフェースを終了させる。ＰＤＮ  ＧＷ１２６は、ＥＰＣ１２０と外部ＰＤＮとの間でデータパケットを転送するものであり、ポリシー強制および課金データ収集のためのキーノードであってもよい。これはまた、移動性のためのアンカーポイントに、非ＬＴＥアクセスを提供する。外部ＰＤＮは、ＩＰマルチメディアサブシステム（ＩＭＳ）ドメインのみならず、いずれの種類のＩＰネットワークであってもよい。ＰＤＮ  ＧＷ１２６およびサービングＧＷ１２４は、単一の物理ノードまたは個別の物理ノード内で実現されてもよい。
【０００９】
ｅＮＢ１０４（マクロおよびミクロ）は、エアインターフェースプロトコルを終了させるものであり、ＵＥ１０２のための最初の接点であってもよい。いくつかの実施形態において、ｅＮＢ１０４は、無線ベアラ管理、アップリンクおよびダウンリンク動的無線リソース管理およびデータパケットスケジューリング、ならびに移動性管理など、ＲＮＣ（無線ネットワークコントローラ機能；Ｒａｄｉｏ  Ｎｅｔｗｏｒｋ  Ｃｏｎｔｒｏｌｌｅｒ  Ｆｕｎｃｔｉｏｎｓ）を含むがこれに限定されない、ＲＡＮ１００のための様々な論理機能を実行してもよい。実施形態によれば、ＵＥ１０２は、直交周波数分割多元接続（ＯＦＤＭＡ；Ｏｒｔｈｏｇｏｎａｌ  Ｆｒｅｑｕｅｎｃｙ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓ）通信技術にしたがって、マルチキャリア通信チャネルによってｅＮＢ１０４と直交周波数分割多重（ＯＦＤＭ；Ｏｒｔｈｏｇｏｎａｌ  Ｆｒｅｑｕｅｎｃｙ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅｘｉｎｇ）通信信号を通信するように、構成されていてもよい。ＯＦＤＭ信号は、複数の直交サブキャリアを備えてもよい。
【００１０】
Ｓ１インターフェース１１５は、ＲＡＮ１００とＥＰＣ１２０とを分離するインターフェースである。これは、ｅＮＢ１０４とサービングＧＷ１２４との間のトラフィックデータを搬送するＳ１−Ｕ、およびｅＮＢ１０４とＭＭＥ１２２との間の信号インターフェースであるＳ１−ＭＭＥの、２つの部分に分割される。Ｘ２インターフェースは、ｅＮＢ１０４間のインターフェースである。Ｘ２インターフェースは、Ｘ２−ＣおよびＸ２−Ｕの２つの部分を備える。Ｘ２−ＣはｅＮＢ１０４間の制御プレーンインターフェースであり、Ｘ２−ＵはｅＮＢ１０４間のユーザプレーンインターフェースである。
【００１１】
セルラーネットワークでは、屋外信号がうまく届かない室内領域まで受信範囲を広げるため、または鉄道駅など非常に高い電話使用密度を有する領域内にネットワーク容量を追加するために、ＬＰセルが一般的に使用される。本明細書において使用される際に、低電力（ＬＰ）ｅＮＢという用語は、フェムトセル、ピコセル、またはマイクロセルなど、より狭いセル（マクロセルよりも狭い）を実施するのに適した、いずれか比較的低電力のｅＮＢを指す。フェムトセルｅＮＢは通常、モバイルネットワークオペレータによって、その住宅または企業顧客に提供される。フェムトセルは通常、住宅用ゲートウェイと同じかまたはより小さいサイズであり、一般的にユーザのブロードバンド回線と接続している。一旦接続されると、フェムトセルは、モバイルオペレータのモバイルネットワークと接続し、住宅用フェムトセルに通常３０から５０メートルの範囲の追加受信範囲を提供する。このように、ＰＤＮ  ＧＷ１２６を通じて結合されているため、ＬＰ  ｅＮＢはフェムトセルｅＮＢであってもよい。同様に、ピコセルは、建物内（オフィス、ショッピングモール、鉄道駅など）、または最近では航空機内など、通常は狭い範囲を網羅する、無線通信システムである。ピコセルｅＮＢは一般的に、その基地局コントローラ（ＢＳＣ；Ｂａｓｅ  Ｓｔａｔｉｏｎ  Ｃｏｎｔｒｏｌｌｅｒ）機能を通じてマクロｅＮＢとなど、別のｅＮＢとＸ２リンクを通じて接続することができる。このように、Ｘ２インターフェースを介してマクロｅＮＢと結合されているので、ＬＰ  ｅＮＢはピコセルｅＮＢを用いて実施されてもよい。ピコセルｅＮＢまたはその他のＬＰ  ｅＮＢは、マクロｅＮＢの一部またはすべての機能を組み込んでもよい。場合により、これはアクセスポイント基地局または企業用フェムトセルと称されてもよい。
【００１２】
いくつかの実施形態において、ｅＮＢ１０４からＵＥ１０２へのダウンリンク送信にはダウンリンクリソースグリッドが用いられてもよく、その一方でＵＥ１０２からｅＮＢ１０４へのアップリンク送信も類似の技術を利用してもよい。グリッドは、リソースグリッドまたは時間周波数リソースグリッドと称される時間周波数グリッドであってもよく、これは各スロットのダウンリンク中の物理リソースである。このような時間周波数プレーン表現はＯＦＤＭシステムでは一般的な慣行であり、これは無線リソース割り当てに関して直感的にする。リソースグリッドの各列および各行は、それぞれ１つのＯＦＤＭ符号および１つのＯＦＤＭサブキャリアに対応する。時間ドメイン中のリソースグリッドの持続時間は、無線フレーム中の１つのスロットに対応する。リソースグリッド中の最小時間周波数単位は、リソース要素（ＲＥ）で表される。各リソースグリッドは多数のリソースブロック（ＲＢ）を備えるが、これはリソース要素への特定の物理チャネルのマッピングを記述する。各リソースブロックは、周波数ドメイン内にリソース要素の集合を備えており、現在割り当て可能なリソースの最小量子を表してもよい。このようなリソースブロックを用いて搬送される、いくつかの異なる物理ダウンリンクチャネルがある。特に本開示に関連して、これら２つの物理ダウンリンクチャネルは、物理ダウンリンク共有チャネルおよび物理ダウンリンク制御チャネルである。
【００１３】
物理ダウンリンク共有チャネル（ＰＤＳＣＨ）は、ＵＥ１０２へのユーザデータおよび上位層信号を搬送する（図１）。物理ダウンリンク制御チャネル（ＰＤＣＣＨ）は、とりわけＰＤＳＣＨチャネルにかかわるトランスポートフォーマットおよびリソース割り当てに関する情報を搬送する。これはまた、アップリンク共有チャネルにかかわるトランスポートフォーマット、リソース割り当て、およびＨＡＲＱ情報について、ＵＥ１０２に通知する。通常、ダウンリンクスケジューリング（制御および共有チャネルリソースブロックをセル内のＵＥ１０２に割り当てること）は、ＵＥ１０２からｅＮＢ１０４にフィードバックされたチャネル品質情報に基づいてｅＮＢ１０４で行われ、その後ダウンリンクリソース割り当て情報が、ＵＥ１０２のために使用される（割り当てられた）制御チャネル（ＰＤＣＣＨ）上でＵＥ１０２に送信される。
【００１４】
ＰＤＣＣＨは、制御情報を搬送するためにＣＣＥ（制御チャネル要素；Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ  Ｅｌｅｍｅｎｔ）を使用する。リソース要素に対してマッピングされる前に、ＰＤＣＣＨ複素数値符号はまず４つずつにまとめられ、これらはその後、レートマッチングのためにサブブロックインターリーバを用いて並べ替えられる。各ＰＤＣＣＨはこれら制御チャネル要素（ＣＣＥ）のうちの１つ以上を用いて送信されるが、各ＣＣＥは、リソース要素グループ（ＲＥＧ）として知られる、９セットの４つの物理リソース要素に対応する。４つのＱＰＳＫ符号が各ＲＥＧに対してマッピングされる。ＰＤＣＣＨは、ＤＣＩのサイズおよびチャネル条件に応じて、１つ以上のＣＣＥを用いて送信されることが可能である。異なる数のＣＣＥ（たとえば、集約レベル、Ｌ＝１、２、４、または８）を有するＬＴＥ内で定義された、４つ以上の異なるＰＤＣＣＨフォーマットがあってもよい。
【００１５】
図２は、いくつかの実施形態による、ユーザ機器（ＵＥ）の機能図である。図３は、いくつかの実施形態による、進化型ノードＢ（ｅＮＢ）の機能図である。なお、いくつかの実施形態において、ｅＮＢ３００は固定された移動不可能な装置であってもよいことに、注意すべきである。ＵＥ２００は図１に示されるようにＵＥ１０２としての使用に適している一方で、ｅＮＢ３００は、図１に示されるようにｅＮＢ１０４としての使用に適している。ＵＥ２００は、物理層回路２０２およびトランシーバ２０５を含んでもよく、これらのうち一方または両方は、１つ以上のアンテナ２０１を用いるｅＮＢ３００、その他のｅＮＢ、その他のＵＥ、またはその他の装置との間での信号の送信および受信を可能にする。一例として、物理層回路２０２は、受信信号の送信および復号のためのベースバンド信号の形成を含む、様々な符号化および復号機能を実行してもよい。別の例として、トランシーバ２０５は、ベースバンド範囲と無線周波数（ＲＦ）範囲との間の信号の変換など、様々な送信および受信機能を実行してもよい。したがって、物理層回路２０２およびトランシーバ２０５は個別の構成要素であってもよく、あるいは組み合わせた構成要素の一部であってもよい。加えて、記載される機能のいくつかは、物理層回路２０２、トランシーバ２０５、およびその他の構成要素または層のうちの１つ、一部、またはすべてを含む組み合わせによって、行われてもよい。
【００１６】
ｅＮＢ３００は、物理層回路３０２およびトランシーバ３０５を含んでもよく、これらのうち一方または両方は、１つ以上のアンテナ３０１を用いるＵＥ２００、その他のｅＮＢ、その他のＵＥ、またはその他の装置との間での信号の送信および受信のための送信および受信を可能にする。物理層回路３０２およびトランシーバ３０５は、ＵＥ２００に関連して記載されたものと類似の様々な機能を実行してもよい。したがって、物理層回路３０２およびトランシーバ３０５は個別の構成要素であってもよく、あるいは組み合わせた構成要素の一部であってもよい。加えて、記載される機能のいくつかは、物理層回路３０２、トランシーバ３０５、およびその他の構成要素または層のうちの１つ、一部、またはすべてを含む組み合わせによって、行われてもよい。
【００１７】
ＵＥ２００はまた、無線媒体へのアクセスを制御するためのメディアアクセス制御層（ＭＡＣ；Ｍｅｄｉｕｍ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ  Ｌａｙｅｒ）回路２０４を含んでもよく、その一方でｅＮＢ３００もまた、無線媒体へのアクセスを制御するためのメディアアクセス制御層（ＭＡＣ）回路３０４を含んでもよい。ＵＥ２００はまた、本明細書に記載される動作を実行するために配置された、処理回路２０６およびメモリ２０８も含んでよい。ｅＮＢ３００もまた、本明細書に記載される動作を実行するために配置された、処理回路３０６およびメモリ３０８を含んでもよい。ｅＮＢ３００は、１つ以上のインターフェース３１０も含んでもよく、これはその他のｅＮＢ１０４（図１）、ＥＰＣ１２０内の構成要素（図１）、またはその他のネットワーク構成要素を含む、別の構成要素との通信を可能にする。加えて、インターフェース３１０は、ネットワークの外部の構成要素を含む、図１に示されないその他の構成要素との通信を可能にしてもよい。インターフェース３１０は、有線または無線、またはこれらの組み合わせであってもよい。
【００１８】
アンテナ２０１、３０１は、ＲＦ信号の送信に適した、たとえばダイポールアンテナ、モノポールアンテナ、パッチアンテナ、ループアンテナ、マイクロストリップアンテナ、またはその他のタイプのアンテナを含む、１つ以上の指向性または全方向性アンテナを備えてもよい。いくつかの複数入力複数出力（ＭＩＭＯ；Ｍｕｌｔｉｐｌｅ−Ｉｎｐｕｔ  Ｍｕｌｔｉｐｌｅ−Ｏｕｔｐｕｔ）実施形態において、アンテナ２０１、３０１は、空間的多様性および結果的な異なるチャネル特性を利用するために、効果的に分離されてもよい。
【００１９】
いくつかの実施形態において、ＵＥ２００またはｅＮＢ３００はモバイル機器であってもよく、パーソナルデジタルアシスタント（ＰＤＡ）、無線通信能力を有するラップトップまたはポータブルコンピュータ、ウェブタブレット、無線電話、スマートフォン、無線ヘッドフォン、ポケベル、インスタントメッセージング装置、デジタルカメラ、アクセスポイント、テレビ、医療機器などのウェアラブルデバイス、または無線で情報を送受信できるその他の装置など、携帯用無線通信装置であってもよい。いくつかの実施形態において、ＵＥ２００またはｅＮＢ３００は３ＧＰＰ規格にしたがって動作するように構成されてもよいが、実施形態の範囲はこの点に関して限定されるものではない。いくつかの実施形態のモバイル機器またはその他の装置は、ＩＥＥＥ８０２．１１またはその他のＩＥＥＥ規格を含む、その他のプロトコルまたは規格にしたがって動作するように構成されてもよい。いくつかの実施形態において、ＵＥ２００、ｅＮＢ３００、またはその他の装置は、キーボード、ディスプレイ、不揮発性メモリポート、複数のアンテナ、グラフィックプロセッサ、アプリケーションプロセッサ、スピーカ、およびその他のモバイル機器要素のうちの、１つ以上を含んでもよい。ディスプレイは、タッチスクリーンを含むＬＣＤスクリーンであってもよい。
【００２０】
ＵＥ２００およびｅＮＢ３００は各々、いくつかの個別の機能要素を有するように示されており、機能要素のうちの１つ以上は組み合わせられてもよく、デジタル信号プロセッサ（ＤＳＰ）を含む処理要素などのソフトウェア構成要素、および／またはその他のハードウェア要素の組み合わせによって、実施されてもよい。たとえば、いくつかの要素は、１つ以上のマイクロプロセッサ、ＤＳＰ、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、特定用途向け集積回路（ＡＳＩＣ）、無線周波数集積回路（ＲＦＩＣ）、および少なくとも本明細書に記載される機能を実行するための様々なハードウェアおよび論理回路の組み合わせを、備えてもよい。いくつかの実施形態において、機能要素は、１つ以上の処理要素上で動作する１つ以上のプロセスを指してもよい。
【００２１】
実施形態は、ハードウェア、ファームウェア、およびソフトウェアのうちの１つまたはこれらの組み合わせで実施されてもよい。実施形態はまた、コンピュータ可読記憶装置に記憶された命令として実施されてもよく、これは本明細書に記載される動作を実行するために少なくとも１つのプロセッサによって読み取りおよび実行されてもよい。コンピュータ可読記憶装置は、機械（たとえば、コンピュータ）によって読み取り可能な形態で情報を記憶するための、いずれの非一時的機構も含んでよい。たとえば、コンピュータ可読記憶装置は、読み取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気ディスク記憶媒体、光記憶媒体、フラッシュメモリ装置、およびその他の記憶装置および媒体を含んでもよい。いくつかの実施形態は、１つ以上のプロセッサを含んでもよく、コンピュータ可読記憶装置に記憶された命令を有して構成されてもよい。
【００２２】
実施形態によれば、ｅＮＢ１０４は低遅延化ＵＥ１０２に、低遅延化データブロックのための初期ＨＡＲＱブロックおよびダイバーシティＨＡＲＱブロックを送信してもよい。ＨＡＲＱブロックの送信の間のサブフレーム間隔は、低遅延化ＵＥ１０２として動作していないＵＥ１０２へのＨＡＲＱブロックの送信に用いられるサブフレーム間隔よりも小さくてもよい。低遅延化データブロックのためのＨＡＲＱブロックは、低遅延化ＵＥ１０２を有するＨＡＲＱプロセスのために確保された時間および周波数リソースの低遅延化領域内で送信されてもよい。加えて、ＨＡＲＱブロックは、低遅延化領域を除く時間および周波数リソース内で、低遅延化ＵＥ１０２として動作していないその他のＵＥ１０２に送信されてもよい。これらの実施形態は、以下により詳細に記載される。
【００２３】
図４は、いくつかの実施形態による、複数のハイブリッド自動再送要求（ＨＡＲＱ）通信プロセスの例示的シナリオを説明する。シナリオ４００において、複数のＨＡＲＱプロセスＰ１〜Ｐ８（図４において４１１から４１８が付されている）は、千鳥構成のｅＮＢ１０４によってサポートされている。ＨＡＲＱプロセスＰ１の一部として、ＰＤＳＣＨブロック４２０（または第一データブロックに基づくＨＡＲＱブロック）は、ＵＥ１０２での受信のためサブフレーム４０５の間に送信されてもよい。ＵＥ１０２は、第一データブロックを生成するためにＰＤＳＣＨブロック４２０を復号しようと試みてもよく、サブフレーム４０６の間に復号の結果をＡＣＫ／ＮＡＣＫ４２５の一部としてｅＮＢ１０４に送信してもよい。復号が成功した場合、サブフレーム４０７の間に送信された次のＰＤＳＣＨブロック４３０は、第二の新しいデータブロックに基づくＨＡＲＱブロックを含んでもよい。しかしながら、復号が成功しなかった場合、ＰＤＳＣＨブロック４３０は、前のＨＡＲＱブロック（またはこれの別のダイバーシティバージョン）の再送信を含んでもよい。したがって、ＵＥ１０２は、第一データブロックを再び復号しようと試みてもよく、復号プロセスにおいてダイバーシティ組み合わせ技術を使用してもよい。
【００２４】
図４に示されるように、往復遅延（ＲＴＤ）４３５は、サブフレーム４０５とサブフレーム４０６との間の時間であり、ｅＮＢ１０４によるＰＤＳＣＨ４２０送信とＵＥ１０２によるＡＣＫ／ＮＡＣＫ４２５送信との間の時間を表すことができる。再送信遅延４４０は、サブフレーム４０５とサブフレーム４０７との間の時間であり、ＰＤＳＣＨ４２０送信とＰＤＳＣＨ４３０送信との間の時間を表すことができる。図示されるように、ＲＴＤ４３５は３つのサブフレームであり、その一方で再送信遅延４４０は８つのサブフレームである。これらの遅延は場合により、予測または指定された復号時間に基づいて選択されてもよい。
【００２５】
プロセスＰ２は、ＲＴＤ４３５および再送信遅延４４０に同じ値を利用してもよく、またプロセスＰ１によって使用されたものの後に１つのサブフレームを生じるサブフレーム内に類似のＰＤＳＣＨおよびＡＣＫ／ＮＡＣＫを送受信してもよい。すると残りのプロセスは適切な遅延においてサポートされてもよく、したがって１セットの時間および周波数リソースは、８つのプロセスＰ１〜Ｐ８をサポートすることができる。
【００２６】
一例として、３ＧＰＰ規格のロングタームエボリューション（ＬＴＥ）サブフレームは１ミリ秒にわたってもよい。その場合、ＲＴＤは３ミリ秒であってもよく、再送信遅延は８ミリ秒であってもよい。場合により、アプリケーションは、データパケットの低遅延交換の恩恵を受けることがある。したがって、システムを通じて様々な遅延および遅延を低減する必要があるが、これらはこのようなエアインターフェース遅延（ＲＴＤおよび再送信遅延）を含んでもよい。たとえば、場合により１ミリ秒以下のＲＴＤが特定される可能性があり、これは「低遅延化」または「低遅延」と称されてもよい。
【００２７】
図５はいくつかの実施形態による、ＨＡＲＱ通信の方法の動作を説明する。方法５００の実施形態が、図５に示されるものと比較してより多いかまたは少ない動作またはプロセスを含んでもよいと気付くことは、重要である。加えて、方法５００の実施形態は必ずしも図５に示される時間的順序に限定されるものではない。方法５００の説明に当たり、方法５００がその他いずれの適切なシステム、インターフェース、および構成要素を用いて実践されてもよいことは理解されるものの、図１から図４および図６から図１３が参照される。
【００２８】
加えて、方法５００および本明細書に記載されるその他の方法は、３ＧＰＰまたはその他の規格にしたがって動作するｅＮＢ１０４またはＵＥ１０２を参照する一方で、これらの実施形態はこれらのｅＮＢ１０４またはＵＥ１０２のみに限定されるものではなく、Ｗｉ−Ｆｉアクセスポイント（ＡＰ）またはユーザステーション（ＳＴＡ）など、その他のモバイル機器によって実践されてもよい。また、方法５００および本明細書に記載されるその他の方法は、ＩＥＥＥ８０２．１１など様々なＩＥＥＥ規格にしたがって動作するように構成されたシステムを含む、その他の適切なタイプの無線通信システムで動作するように構成された無線装置によって、実践されてもよい。
【００２９】
方法５００の動作５０５において、第一データブロック用の初期ＨＡＲＱブロックは、第一ＵＥ１０２でのＨＡＲＱプロセスの一部として送信されてもよい。動作５１０において、低遅延化データブロック用の初期ＨＡＲＱブロックは、低遅延化ＵＥ１０２でのＨＡＲＱプロセスの一部として送信されてもよい。いくつかの実施形態において、低遅延化ＵＥ１０２は、低遅延化モードで動作するように構成されたＵＥ１０２であってもよく、その一方で第一ＵＥ１０２は、低遅延化モードで動作するように構成されていないＵＥ１０２であってもよい。このようなモードでの動作は、場合により構成可能であってもよい。非限定例として、低遅延化ＵＥ１０２および第一ＵＥ１０２のうちの一方または両方が、低遅延化モードまたは通常モードで動作可能であってもよい。いくつかの実施形態において、レガシーＵＥ１０２は通常モードで動作してもよいが、これらの実施形態は限定的ではない。
【００３０】
第一データブロック用の初期ＨＡＲＱブロックは、少なくとも部分的に第一データブロックに基づいていてもよい。したがって、第一データブロックは、初期ＨＡＲＱブロックの生成の一部として様々な符号化機能によって処理される、データビットを含んでもよい。符号化機能は、前方誤り訂正（ＦＥＣ；Ｆｏｒｗａｒｄ  Ｅｒｒｏｒ  Ｃｏｒｒｅｃｔｉｏｎ）、パンクチャリング、インターリービング、ビット対符号マッピング、およびその他の適切な機能のうちの一部またはすべてを含んでもよい。一例として、初期ＨＡＲＱブロックは、２相偏移変調（ＢＰＳＫ；Ｂｉｎａｒｙ  Ｐｈａｓｅ−Ｓｈｉｆｔ  Ｋｅｙｉｎｇ）、４相偏移変調（ＱＰＳＫ；Ｑｕａｄｒａｔｕｒｅ  Ｐｈａｓｅ−Ｓｈｉｆｔ  Ｋｅｙｉｎｇ）、直交振幅変調（ＱＡＭ；Ｑｕａｄｒａｔｕｒｅ  Ａｍｐｌｉｔｕｄｅ  Ｍｏｄｕｌａｔｉｏｎ）など、いずれか適切な変調の変調符号（配置点）を含んでもよい。
【００３１】
いくつかの実施形態において、初期ＨＡＲＱブロックは、１つ以上のＯＦＤＭ信号を用いて送信されてもよい。このように限定されるものではないが、ＯＦＤＭ信号の周波数リソースは複数のリソース要素（ＲＥ）を含んでもよく、周波数が隣接する複数のＲＥは、複数のリソースブロック（ＲＢ）を形成するためにグループ化されてもよい。非限定例として、３ＧＰＰまたはその他の規格で、１２個のＲＥが１つのＲＢを形成してもよい。ＯＦＤＭ信号の時間リソースは、複数のＯＦＤＭ符号またはＯＦＤＭ符号周期を含んでもよい。いくつかの実施形態において、初期ＨＡＲＱブロックに含まれる変調符号は、送信用のＯＦＤＭ信号の形成の一部として、様々なＲＥおよびＯＦＤＭ符号にマッピングされてもよい。
【００３２】
なお、特定のＨＡＲＱブロックおよび／または特定のデータブロックに関連する技術およびその他の局面は、議論または説明目的のため本明細書に記載されるが、実施形態はこれら特定のブロックまたはブロックタイプに限定されるものではないことに、注意すべきである。したがって、（その形成、送信、およびその他の特徴と併せて）第一データブロック用の初期ＨＡＲＱブロックに関する上記の議論は、初期ＨＡＲＱブロックまたは第一データブロックに限定されるものではなく、本明細書に記載されるものを含む、その他のＨＡＲＱブロックおよび／またはデータブロックに適用されてもよい。一例として、動作５１０における低遅延化データブロック用の初期ＨＡＲＱブロックが使用されてもよい。後に論じられるように、第一データブロックまたは低遅延化データブロック用のダイバーシティＨＡＲＱブロックもまた使用されてよい。加えて、場合により、その他のタイプのＨＡＲＱブロックおよびデータブロックが使用されてもよい。別の例として、特定のデータブロック用の第二または第三ダイバーシティＨＡＲＱブロックなど、ダイバーシティＨＡＲＱブロックを超える追加ダイバーシティＨＡＲＱブロックが使用されてもよい。
【００３３】
なお、ｅＮＢ１０４は、先に記載されたように、異なるＵＥ１０２との複数のＨＡＲＱセッションを同時にサポートしてもよいことに、注意すべきである。いくつかの実施形態において、複数のＨＡＲＱセッションは、いずれの適切な数のＵＥ１０２とでもサポートされてよい。ＵＥ１０２は、低遅延化モードで動作するＵＥ１０２、通常モードで動作するＵＥ１０２、その他のモードで動作するＵＥ１０２、またはこれらのうちいずれか適切な組み合わせを、含んでもよい。非限定例として、ｅＮＢ１０４は、先に記載されたシナリオ４００と同様に、通常モードで動作しているＵＥ１０２との８つのＨＡＲＱセッションをサポートしてもよい。ｅＮＢ１０４はまた、同じように低遅延化モードで動作しているＵＥ１０２との複数のＨＡＲＱセッションもサポートしてよい。つまり、ｅＮＢ１０４は、低遅延化動作のために確保された時間および周波数リソースの中で低遅延化ＵＥ１０２との複数のＨＡＲＱセッションをサポートしてもよく、低遅延化動作のために確保されたもの専用の時間および周波数リソースの中で通常モードで動作しているＵＥ１０２との複数のＨＡＲＱセッションを同時にサポートしてもよい。
【００３４】
方法５００に戻ると、第一データブロック用の初期ＨＡＲＱブロックをうまく復号するためのＨＡＲＱ確認標識は、動作５１５において受信されてもよい。いくつかの実施形態において、ＨＡＲＱ確認標識は、第一ＵＥ１０２による第一データブロックの復号の成功または失敗を示すことができ、復号結果は、第一データブロックのための受信された初期ＨＡＲＱブロックを用いて第一データブロックを復号するための、第一ＵＥ１０２による試みを反映することができる。したがって、ＨＡＲＱ確認標識は、ＡＣＫ／ＮＡＣＫなどを含むかまたはそれ自体であってもよく、場合により追加関連情報を含んでもよい。実施形態はそのように限定されないものの、ＨＡＲＱ確認標識の受信は第一ＵＥ１０２とのＨＡＲＱプロセスの一部であってもよい。
【００３５】
動作５２０において、低遅延化データブロック用の初期ＨＡＲＱブロックの復号の成功のＨＡＲＱ確認標識が受信されてもよい。実施形態はそのように限定されないものの、ＨＡＲＱ確認標識の受信は低遅延化ＵＥ１０２とのＨＡＲＱプロセスの一部であってもよい。このように限定されるものではないが、動作５１５に関する先の議論は動作５２０にも適用可能であり、場合により同一または類似の技術が用いられてもよい。たとえば、ＨＡＲＱ確認標識に含まれる復号結果は、低遅延化データブロックのための受信された初期ＨＡＲＱブロックを用いて低遅延化データブロックを復号するための、低遅延化ＵＥ１０２による試みを反映することができる。
【００３６】
いくつかの実施形態において、低遅延化データブロック用の初期ＨＡＲＱブロックの復号の成功のＨＡＲＱ確認標識は、低遅延化データブロック用の初期ＨＡＲＱブロックの送信の１ミリ秒以内に受信されてもよい。したがって、ｅＮＢ１０４によるＨＡＲＱブロックの送信とｅＮＢ１０４での標識の受信（またはＵＥ１０２による標識の送信）との間の経過時間が、１ミリ秒またはその他指定された時間値またはｅＮＢ１０４用の既存ＲＴＤよりも小さい所望の時間値よりも短いとき、ＨＡＲＱプロセスは「低遅延化」または「低遅延」と見なされてもよい。先に記載されたように、ＲＴＤおよび再送信遅延は、低遅延化モードで動作しているＵＥ１０２では、通常モードで動作しているＵＥ１０２よりも低くてもよい。
【００３７】
経過時間のその他の値もまた低遅延化動作に指定されてもよいので、実施形態は１ミリ秒の経過時間の値に限定されるものではない。加えて、ＲＴＤおよび再送信遅延を含む、今記載された経過時間以外の持続時間の値もまた、低遅延化動作のために指定されてもよい。実施形態はまた、低遅延化動作の分類における論理演算子としての「ｌｅｓｓ  ｔｈａｎ（未満）」の使用に限定されるものでもない。たとえば、「ｌｅｓｓ  ｔｈａｎ  ｏｒ  ｅｑｕａｌ  ｔｏ（以下）」またはその他の論理演算子もまた使用されてよい。
【００３８】
低遅延化動作の一例として、ＨＡＲＱ送信と標識の受信との間の経過時間について指定された最大値は、０．５ミリ秒から１．５ミリ秒の範囲から選択されてもよい。別の例として、０．５ミリ秒未満の値または１．５ミリ秒を超える値が使用されてもよい。別の例として、低遅延化モードの経過時間は、「通常」モードで動作しているかまたは低遅延化モードで動作していないＵＥ１０２のために使用されるＨＡＲＱプロセスに関連する類似の経過時間と比較して、指定されてもよい。たとえば、低遅延化ＨＡＲＱプロセスは、上述の経過時間が、通常モードで動作しているＵＥ１０２のために使用されるＨＡＲＱプロセスの類似の経過時間の２５％以下であるときに、低遅延または低遅延化と見なされてもよい。２５％という値は一例として示されており、その他の適切な値が指定または使用されてもよいことは、理解される。
【００３９】
動作５２５において、第一データブロック用のダイバーシティＨＡＲＱブロックは、第一ＵＥ１０２との第一ＨＡＲＱプロセスの一部として送信されてもよい。いくつかの実施形態において、ダイバーシティＨＡＲＱブロックは、所定のＨＡＲＱ区間だけ時間的に離間したロングタームエボリューション（ＬＴＥ）サブフレームの間に第一データブロック用のＨＡＲＱブロック（初期またはダイバーシティ）の送信が行われるように、送信されてもよい。
【００４０】
動作５３０において、低遅延化データブロック用のダイバーシティＨＡＲＱブロックは、低遅延化ＵＥ１０２との低遅延化ＨＡＲＱプロセスの一部として送信されてもよい。いくつかの実施形態において、ダイバーシティＨＡＲＱブロックは、ＨＡＲＱ区間よりも短い所定の低遅延化ＨＡＲＱ区間だけ時間的に離間したＬＴＥサブフレームの間に低遅延化データブロック用のＨＡＲＱブロック（初期またはダイバーシティ）の送信が行われるように、送信されてもよい。つまり、ダイバーシティＨＡＲＱブロックは、対応する初期ＨＡＲＱブロックと比較してＬＴＥサブフレームの所定間隔にしたがって送信されてもよく、低遅延化モードで動作しているＵＥ１０２の間隔は、通常モードで動作しているＵＥ１０２の間隔よりも狭い。いくつかの実施形態において、初期およびダイバーシティＨＡＲＱブロックの送信の間の区間に関連付けられた応答時間であってもよい再送信時間は、第一ＨＡＲＱプロセス向けよりも低遅延化ＨＡＲＱプロセス向けの方が短くてもよい。非限定例として、低遅延化ＨＡＲＱプロセス向けの応答時間は、通常ＨＡＲＱプロセス向けの応答時間の２５％であってもよい。
【００４１】
いくつかの実施形態において、（いずれかのＨＡＲＱプロセスのための）ダイバーシティＨＡＲＱブロックの送信は、対応するＨＡＲＱ確認標識がデータブロックの復号失敗を示すときに行われてもよい。復号の失敗とは、少なくとも部分的に初期ＨＡＲＱブロックに基づいてデータブロックを復号しようとするＵＥ１０２による試みの失敗を指す。送信はまた、場合により、ＨＡＲＱ確認標識がｅＮＢ１０４においてうまく受信されないときにも行われてよい。したがって、送信は、データブロックがＨＡＲＱ確認標識によってうまく復号されたものとして確認されないときに、行われてもよい。
【００４２】
先に記載されたように、（いずれかのＨＡＲＱプロセスのための）ダイバーシティＨＡＲＱブロックは、対応する初期ＨＡＲＱブロックに含まれる変調符号の一部またはすべてを含んでもよいが、このように限定されるものではない。いくつかの実施形態において、ダイバーシティＨＡＲＱブロックおよび初期ＨＡＲＱブロックはいずれもデータブロックに基づいてもよく、同じ符号化機能の一部またはすべてを使用してもよい。一例として、同じＦＥＣエンコーダからの異なるセットのパリティビットが、初期ＨＡＲＱブロックおよびダイバーシティＨＡＲＱブロックの形成に使用されてもよい。別の例として、異なるＨＡＲＱブロックに異なるインターリーバが使用されてもよい。別の例として、２つのＨＡＲＱブロックは同じ変調符号を含んでもよく、ダイバーシティＨＡＲＱブロックは初期ＨＡＲＱブロックの複製であってもよい。これらの例は、ＨＡＲＱブロックの異なる可能性を示しているが、しかしその他いずれの適切な技術が用いられてもよいので、限定的ではない。
【００４３】
動作５３５において、第一データブロック用の受信されたＨＡＲＱ確認標識が第一データブロック用の初期ＨＡＲＱブロックに基づく第一データブロックの復号の成功を示すとき、ｅＮＢ１０４は、第一データブロック用のダイバーシティＨＡＲＱブロックの送信を控えてもよい。復号は第一ＵＥ１０２において行われてもよい。したがって、第一データブロックがうまく受信されたことがｅＮＢ１０４に通知されたとき、第一データブロック用のダイバーシティＨＡＲＱブロックを送信（または形成または計算）する必要がないと見なされてもよい。動作５４０において、低遅延化データブロック用の受信されたＨＡＲＱ確認標識が低遅延化データブロック用の初期ＨＡＲＱブロックに基づく低遅延化データブロックの復号の成功を示すとき、ｅＮＢ１０４は、低遅延化データブロック用のダイバーシティＨＡＲＱブロックの送信を控えてもよい。復号は低遅延化ＵＥ１０２において行われてもよい。第一データブロックに関して先に記載されたように、データブロックが既にうまく復号されたことがｅＮＢ１０４に通知されたとき、低遅延化データブロック用のダイバーシティＨＡＲＱブロックを送信（または形成または計算）する必要がないと見なされてもよい。
【００４４】
いくつかの実施形態において、低遅延化データブロック用のＨＡＲＱブロックは、低遅延化ＵＥ１０２とのＨＡＲＱプロセスのために確保された時間および周波数リソースの中で送信されてもよい。加えて、第一データブロック用のＨＡＲＱブロックは、低遅延化ＵＥ１０２とのＨＡＲＱプロセスのために確保されたものを除く時間および周波数リソースの中で送信されてもよい。したがって、時間および周波数リソースは、場合により、低遅延化ＨＡＲＱプロセスのために確保または割り当てされたリソース、および通常ＨＡＲＱプロセスに使用されてもよいリソースを、含んでもよい。
【００４５】
いくつかの実施形態において、時間および周波数リソースは１つ以上のＬＴＥサブフレームを含んでもよく、これは、低遅延化ＵＥとのＨＡＲＱプロセスのために確保された時間および周波数リソースの低遅延化領域、ならびに低遅延化領域専用の時間および周波数リソースの通常領域を、含んでもよい。したがって、各ＬＴＥサブフレームの時間および周波数リソースは、場合により、低遅延化ＨＡＲＱ送信のために確保された低遅延化部分と、低遅延化部分専用の通常部分と、を備えてもよい。
【００４６】
以下および図６から図８に示されるいくつかの例は様々な技術および配置を示しており、そのうちのいくつかは、方法５００の一部として記載されるものを含み、様々な実施形態に含まれている。例は、先に記載された、時間および周波数リソースの低遅延化領域および通常領域、ＨＡＲＱブロックの送信、ＨＡＲＱプロセスのサポート、またはその他の概念などの概念を示す。実施形態の範囲はこの点に関して限定されないものの、いくつかの実施形態はこれらの例に示される概念の一部またはすべてを利用してもよい。加えて、いくつかの実施形態は、図６から図８の例に示されない、類似の特徴および／または付加的な特徴を含んでもよい。
【００４７】
先に記載されたように、ＨＡＲＱブロックの直交周波数分割多重（ＯＦＤＭ）送信がいくつかの実施形態において使用されてもよく、周波数リソースはＲＥおよびＲＢを含んでもよく、時間リソースはＯＦＤＭ符号およびＬＴＥサブフレームを含んでもよい。図６から図８の例はＯＦＤＭの概念を示しているものの、実施形態が信号のＯＦＤＭ送信および受信に限定されるものではないことは、理解される。
【００４８】
図６は、いくつかの実施形態による、サブフレームの一例を説明する。図６の上で、時間周波数グリッド６００は、複数のＲＢ６１０〜６１３とともに単一のＬＴＥサブフレーム６０５を示す。実施形態はいずれの適切な数のＬＴＥサブフレーム６０５およびＲＢ６１０〜６１３を含んでもよく、図６に示されるものに限定されないことは、理解される。一例として、ＬＴＥサブフレーム６０５について示される時間周波数グリッド６００は、先のおよび／または後のＬＴＥサブフレームの間にも使用されてよい。別の例として、４つより多くのまたは少ないＲＢ６１０〜６１３が使用されてもよい。
【００４９】
説明しやすくするため、図６の下の時間周波数グリッド６００の拡大部分は、特定のＲＢ６１０に関連してさらなる詳細を示す。時間周波数グリッド６００は、図６の下の拡大部分に示されるように、時間および周波数次元の両方のＲＥ６１５を備えてもよい。図解の明確さのため、含まれているすべてのＲＥ６１５が「６１５」で記されているわけではないことは、指摘すべきである。先に記載されたように、ＲＥ６１５は時間周波数グリッド６００内の割り当ての最小単位を表してもよく、変調符号は１つ以上のＯＦＤＭ信号の一部として送信されるために時間周波数グリッド６００内のＲＥ６１５にマッピングされてもよい。例示的な時間周波数グリッド６００において、ＲＢ６１０は周波数次元に１２個のＲＥ６１５を備え、ＬＴＥサブフレーム６０５は時間ドメイン内に１４個のＯＦＤＭ符号を備える。したがって、ＲＢ６１０が備えるＲＥ６１５の数は、この例において１２×１４＝１６８個である。このような値は、場合により３ＧＰＰまたはその他の規格にしたがって選択されてもよいが、しかし実施形態はこれらの値に限定されるものではない。なお、図６において、異なるＲＥ６１５タイプは斜線および無地パターンを通じて相応に区分されていることにも注意すべきであり、これについては以下に説明する。
【００５０】
ＬＴＥサブフレーム６０５は多数の低遅延サブフレーム（ＬＬＳＦ）に分割されてもよく、その各々は時間次元のＯＦＤＭ符号の隣接グループに及んでもよい。一例として、ＬＴＥサブフレーム６０５は、図６の下の部分に示されるように、４つのＬＬＳＦ６２０、６３０、６４０、および６５０に分割されてもよい。ＬＬＳＦ６２０、６４０は各々４つのＯＦＤＭ符号に及んでもよく、ＬＬＳＦ６３０、６５０は各々３つのＯＦＤＭ符号に及んでもよい。しかしながらこの例は限定的ではなく、いくつかの実施形態のように、ＬＬＳＦはいずれの適切な数のＯＦＤＭ符号に及んでもよく、ＬＬＳＦごとのＯＦＤＭ符号の数は同じであってもなくてもよい。
【００５１】
加えて、ＬＬＳＦ６２０、６３０、６４０、６５０は、周波数次元のＲＢ６１０およびその他のＲＢに及んでもよい。場合により、システムの利用可能な周波数リソースは多数のＲＢを含んでもよく、その一部またはすべてが６２０、６３０、６４０、および６５０などのＬＬＳＦのために使用されてもよい。一例として、ＬＬＳＦ６２０は、図６の上の部分に示されるように、２つのＲＢ６１０および６１１に及んでもよい。その他のＬＬＳＦ６３０、６４０、および６５０もまた、図解の明確さのため図６の上の部分にははっきりと示されていないものの、２つのＲＢ６１０および６１１に及んでもよい。したがって、ＲＢ６１０および６１１を含む時間および周波数リソースは、図６の点線フォーマットによって区分されるように、低遅延化モードで動作しているＵＥ１０２のための低遅延化領域６９０として割り当てられてもよい。ＲＢ６１２および６１３を含む時間および周波数リソースを含む領域６９５は、通常モードで動作しているＵＥ１０２のために割り当てられてもよい。
【００５２】
一例として、ＬＬＳＦ６２０は４つのＯＦＤＭ符号に及んでもよく、データブロックの送信用の低遅延データチャネル（ＬＬＤＣ）６２４およびデータブロックに関する制御情報を含む低遅延制御チャネル（ＬＬＣＣ）６２２を備えてもよい。図示されるように、ＬＬＣＣ６２２は単一のＯＦＤＭ符号にわたってもよく、その一方でＬＬＤＣ６２４は３つのＯＦＤＭ符号に及んでもよいが、しかしこの例は限定的ではない。たとえば、ＬＬＣＣ（６２２およびその他のものなど）は、実施形態において複数のＯＦＤＭ符号に及んでもよい。加えて、ＬＬＳＦ６２０が複数のＲＢに及ぶとき、ＬＬＣＣ６２２およびＬＬＤＣ６２４もまた複数のＲＢに及んでもよく、場合によりＬＬＳＦ６２０と同じ数のＲＢに及んでもよい。一例として、ＬＬＳＦ６２０、ＬＬＣＣ６２２、およびＬＬＤＣ６２４は、図６の上の部分に示されるように、２つのＲＢ６１０および６１１に及んでもよい。
【００５３】
別の例として、ＬＬＳＦ６３０は３つのＯＦＤＭ符号に及んでもよく、データブロックの送信用のＬＬＤＣ６３４およびデータブロックに関する制御情報を含むＬＬＣＣ６３２を備えてもよい。ＬＬＳＦ６２０に関連して先に記載されたように、ＬＬＣＣ６３２およびＬＬＤＣ６３４は各々、いくつかの実施形態において１つ以上のＯＦＤＭ符号に及んでもよく、これらは図６に示される例に限定されるものではない。加えて、ＬＬＣＣ６３２およびＬＬＤＣ６３４はいくつかの実施形態において、特にＬＬＳＦ６３０が複数のＲＢに及ぶとき、ＲＢ６１０に加えて複数のＲＢに及んでもよい。
【００５４】
いくつかの実施形態において、低遅延化ＨＡＲＱプロセス用の個々のＨＡＲＱブロックは、単一のＬＬＳＦ内で送信されてもよく、あるいは単一のＬＬＳＦ内の送信のために制限されてもよい。したがって、ＬＬＳＦは、低遅延化ＨＡＲＱプロセス用の１つ以上のＨＡＲＱブロック（初期またはダイバーシティ）を送信するように構成されてもよい。場合により、ＬＬＳＦ内で送信された複数のＨＡＲＱブロックは、複数の低遅延化ＨＡＲＱプロセスに関連付けられてもよい。なお、ＬＬＳＦ内のＬＬＤＣは（１つまたは複数の）ＨＡＲＱブロックの送信に使用されてもよく、その一方でＬＬＳＦ内のＬＬＣＣは関連する制御情報を含んでもよいことに、注意すべきである。また、今記載されたＬＬＳＦのこのような特徴は、図６に示されるＬＬＳＦに限定されるものではなく、場合により本明細書に記載されるその他のＬＬＳＦにも適用可能であることに、注意すべきである。
【００５５】
いくつかの異なるタイプのＲＥが、様々な位置で時間周波数グリッド６００に含まれてもよい。ＲＥ６６０は、ＬＬＣＣ  ＲＥであるかまたはこれを表してもよく、ＲＥ６７０は参照符号（ＲＳ；Ｒｅｆｅｒｅｎｃｅ  Ｓｙｍｂｏｌ）であるかまたはこれを表してもよく、ＲＥ６８０（無地の枠）はＬＬＤＣ  ＲＥであるかまたはこれを表してもよい。これらのタイプのうちいくつかは、図６において時間周波数グリッド６００の中に、およびその上の凡例に、示されている。図６に示されるようなＬＴＥサブフレーム６０５内のＲＥタイプのレイアウトおよび位置は、場合により３ＧＰＰまたはその他の規格にしたがって選択されてもよいが、しかし実施形態は図６に示されるものに限定されるものではない。たとえば、ＲＳの位置および／または量は、場合により図６に示されるのとは異なってもよい。
【００５６】
図７は、いくつかの実施形態による、サブフレームの別の例を説明する。そのように限定されないものの、図６に記載される例のいくつかの局面および特徴は、図７の例にも適用可能である。図７の上で、時間周波数グリッド７００は、複数のＲＢ７１０〜７１３とともに単一のＬＴＥサブフレーム７０５を示す。図７の下の時間周波数グリッド７００の拡大部分は、特定のＲＢ７１０に関連してさらなる詳細を示す。
【００５７】
図６に関して先に記載されたように、実施形態はいずれの適切な数のＬＴＥサブフレーム７０５を含んでもよく、ＲＢ７１０〜７１３が使用されてもよく、そしてＬＴＥサブフレーム７０５について示された時間周波数グリッド７００もまた、先のおよび／または後のＬＴＥサブフレームの間に使用されてもよい。ＲＥ７１５はＲＥ６１５と類似であってもよく、ＲＥ６１５に関する先の議論はＲＥ７１５に適用可能である。異なるＲＥ７１５タイプは斜線および無地を含む様々なパターンを通じて相応に区分され、これについては以下に説明する。
【００５８】
ＬＴＥサブフレーム７０５は多数の低遅延サブフレーム（ＬＬＳＦ）に分割されてもよく、その各々は時間次元のＯＦＤＭ符号の隣接グループに及んでもよい。一例として、ＬＴＥサブフレーム７０５は、図７の下の部分に示されるように、４つのＬＬＳＦ７２０、７３０、７４０、および７５０に分割されてもよい。先に記載されたように、低遅延化ＨＡＲＱプロセス用の個々のＨＡＲＱブロックは単一のＬＬＳＦ（７２０、７３０、７４０、または７５０など）の中で送信されてもよく、ＬＬＳＦは低遅延化ＨＡＲＱプロセス用の１つ以上のＨＡＲＱブロックを送信するように構成されてもよい。図５の例に関連して先に記載されたように、ＬＬＳＦは３つ、４つ、またはいずれか適切な数のＯＦＤＭ符号およびいずれか適切な数のＲＢに及んでもよい。したがって、時間および周波数リソースは、低遅延化モードで動作しているＵＥ１０２のために割り当てられた低遅延領域７９０を含んでもよく、領域７９５は通常モードで動作しているＵＥ１０２のために割り当てられてもよい。
【００５９】
いくつかの実施形態において、ＬＬＳＦ７２０は、時間次元の１つ以上のＯＦＤＭ符号の隣接グループに及んでもよい物理ダウンリンク制御チャネル（ＰＤＣＣＨ）７２２を含んでもよい。グループは場合により、ＰＤＣＣＨがＬＴＥサブフレーム７０５内の第一ＯＦＤＭ符号を占有するように、ＬＴＥサブフレーム７０５内の第一ＯＦＤＭ符号を含んでもよい。ＬＬＳＦ７２０はまた、低遅延化ＵＥ１０２によるデータブロックの送信用の低遅延データチャネル（ＬＬＤＣ）７２４も含んでよい。ＰＤＣＣＨ７２２は、低遅延化ＵＥ１０２とのＨＡＲＱプロセスのために確保された時間および周波数リソースを識別する情報を含んでもよい。一例として、ＰＤＣＣＨ７２２は、サイズ、場所、ＬＴＥサブフレーム７０５内の位置、またはその他の局面に関して、ＬＬＳＦ７３０、７４０、および７５０の割り当てを記述してもよい。ＰＤＣＣＨ７２２はまた、ＬＬＤＣ７２４のための割り当ても記述してよい。
【００６０】
いくつかの実施形態において、ＬＬＳＦ７３０、７４０、および７５０は各々ＬＬＤＣおよびＬＬＣＣを備えてもよく、これらは図５の例に関して記載されたものと類似であってもよい。たとえば、ＬＬＤＣ７３２はＬＬＤＣ７３４に関する制御情報を含んでもよく、ＬＬＤＣ７３２は図７に示されるように単一のＯＦＤＭ符号に限定されるものではない。
【００６１】
いくつかの異なるタイプのＲＥが、様々な位置で時間周波数グリッド７００に含まれてもよい。ＲＥ７６０はＬＬＣＣ  ＲＥであるかまたはこれを表してもよく、ＲＥ７７０は参照符号（ＲＳ）であるかまたはこれを表してもよく、ＲＥ７８０（無地の枠）はＬＬＤＣ  ＲＥであるかまたはこれを表してもよく、「Ｐ」で示されるＲＥ７９０はＰＤＣＣＨデータＲＥであるかまたはこれを表してもよい。これらのタイプのうちいくつかは、図７において時間周波数グリッド７００の中に、およびその上の凡例に、示されている。図７に示されるようなＬＴＥサブフレーム７０５内のＲＥタイプのレイアウトおよび位置は、場合により３ＧＰＰまたはその他の規格にしたがって選択されてもよいが、しかし実施形態は図７に示されるものに限定されるものではない。たとえば、ＲＳの位置および／または量は、場合により図７に示されるのとは異なってもよい。
【００６２】
図８は、いくつかの実施形態による、サブフレームの別の例を説明する。そのように限定されないものの、図６〜７に記載される例のいくつかの局面および特徴は、図８の例にも適用可能である。時間周波数グリッド８００は、１４個のＯＦＤＭ符号８１５を含むかまたはこのように分割された単一のＬＴＥサブフレーム８０５を示し、これらは１から１４の範囲でインデックスが付けられている。加えて、ＲＢ８２０〜８２５は先に記載されたＲＥ６１５、７１５と類似のＲＥを備えてもよいが、ただしこのようなＲＥは図解の明確さのため図８には示されていない。先に記載されたように、実施形態は図８に示される数のＬＴＥサブフレーム８０５、ＯＦＤＭ符号８１５、およびＲＢ８２０〜８２５に限定されるものではなく、ＬＴＥサブフレーム８０５について示される時間周波数グリッド８００もまた、先のおよび／または後のＬＴＥサブフレームの間に使用されてもよい。
【００６３】
いくつかの実施形態において、ＬＴＥサブフレーム８０５は、低遅延化ＵＥ１０２とのＨＡＲＱプロセスのために確保された時間および周波数リソースの低遅延化領域、ならびに低遅延化領域専用の時間および周波数リソースの通常領域を、含んでもよい。したがって、低遅延化領域は１つ以上の低遅延サブフレーム（ＬＬＳＦ）を含んでもよく、その各々は、データブロックの送信用の低遅延データチャネル（ＬＬＤＣ）と、データブロックの制御情報を含んでもよい低遅延制御チャネル（ＬＬＣＣ）と、を含んでもよい。各ＬＬＳＦ用のＬＬＤＣおよびＬＬＣＣは、いくつかの実施形態において、単一のＯＦＤＭ符号の間に周波数が多重化されてもよい。つまり、各ＬＬＳＦは、単一のＯＦＤＭ符号８１５の間、ＲＢおよび／またはＲＥの一部またはすべてに及んでもよい。
【００６４】
一例として、ＯＦＤＭ符号＃４の間、ＲＢ８２４に含まれるＲＥは、図８の左下の判例に示されるパターン８８０にしたがって区分されるように、ＬＬＳＦ８３０用のＬＬＣＣを形成してもよい。やはりＯＦＤＭ符号＃４内で、ＲＢ８２０〜８２３およびＲＢ８２５に含まれるＲＥは、判例に示されるパターン８８５にしたがって区分されるように、ＬＬＳＦ８３０用のＬＬＤＣを形成してもよい。したがって、ＬＬＳＦ８３０は、ＯＦＤＭ符号＃４の間、ＲＢ８２０〜８２５内のＲＥを備えてもよい。別の例として、ＬＬＳＦ８４０、８５０、および８６０は、ＬＴＥサブフレーム８０５がＯＦＤＭ符号＃４、８、１１、および１４上のＲＢを占有する４つのＬＬＳＦ８３０、８４０、８５０、および８６０を含むように、類似のやり方で形成されてもよい。図８に示されない別の例として、特定のＯＦＤＭ符号８１５の間のＲＥは、ＬＬＳＦ用のＬＬＣＣおよびＬＬＤＣを形成するためにいずれか適切なやり方で割り当てられてもよく、割り当てはＲＢ境界に限定されてもされなくてもよい。つまり、ＲＢの一部またはすべては、ＬＬＣＣに含まれる１つ以上のＲＥおよびＬＬＤＣに含まれる１つ以上のＲＥを、含んでもよい。先に記載されたように、低遅延化ＨＡＲＱプロセス用の個々のＨＡＲＱブロックは単一のＬＬＳＦ（８２０、８３０、８４０、または８５０など）の中で送信されてもよく、ＬＬＳＦは低遅延化ＨＡＲＱプロセス用の１つ以上のＨＡＲＱブロックを送信するように構成されてもよい。
【００６５】
加えて、ＰＤＣＣＨ８７０は１つ以上のＯＦＤＭ符号８１５に及んでもよい。図示されるように、ＰＤＣＣＨ８７０はＯＦＤＭ符号＃１および＃２におよび、ＲＢ８２０〜８２５に及ぶが、しかしこの例は限定的ではない。ＰＤＣＣＨ８７０は、ＯＦＤＭ符号インデックス、ＬＬＳＦ内のＬＬＣＣおよびＬＬＤＣの位置、またはその他の関連情報に関して、８３０、８４０、８５０、および８６０などのＬＬＳＦの割り当てを記述してもよい。ＰＤＣＣＨ８７０はまた、時間および周波数リソースの通常領域（低遅延化領域に専用のもの）内の割り当ても記述してよいが、これらは判例に示される無地パターン８９０にしたがって区分される。いくつかの実施形態において、通常領域に関する情報は、レガシーＰＤＣＣＨ動作と互換性のあるフォーマットのＰＤＣＣＨ８７０に含まれてもよい。
【００６６】
図８には明確に示されないものの、ＬＬＣＣ、ＬＬＤＣ、ＰＤＣＣＨ、およびその他の領域内のＲＥのいくつかは、参照符号（ＲＳ）またはその他の符号のために割り当てられてもよい。
【００６７】
図９は、いくつかの実施形態による、ＨＡＲＱ通信の別の方法の動作を説明する。方法５００に関連して先に述べられたように、方法９００の実施形態は、図９に示されるものと比較してより多くのまたは少ない動作またはプロセスを含んでもよく、方法９００の実施形態は必ずしも図９に示される時間的順序に限定されるものではない。方法９００の説明に際して、方法９００はその他いずれか適切なシステム、インターフェース、および構成要素を用いて実践されてもよいことは理解されるものの、図１から図８および図１０から図１３が参照されてもよい。たとえば、説明目的のため図４で先に記載されたシナリオが参照されてもよいが、しかし方法９００の技術および動作はこれに限定されるものではない。加えて、方法９００の実施形態は、ｅＮＢ１０４、ＵＥ１０２、ＡＰ、ＳＴＡ、またはその他の無線またはモバイル機器を参照してもよい。
【００６８】
なお、方法９００は、ＵＥ１０２において実践されてもよく、ｅＮＢ１０４との信号またはメッセージの交換を含んでもよいことに、注意すべきである。同様に、方法５００はｅＮＢ１０４において実践されてもよく、ＵＥ１０２との信号またはメッセージの交換を含んでもよい。場合により、方法５００の一部として記載された動作および技術は、方法９００に関連するかも知れない。たとえば、方法５００の動作はｅＮＢ１０４によるブロックの送信を含んでもよいが、その一方で方法９００の動作はＵＥ１０２における同じブロックまたは類似ブロックの受信を含んでもよい。
【００６９】
方法９００の動作９０５において、初期ハイブリッド自動再送要求（ＨＡＲＱ）ブロックが、第一ダウンリンクサブフレームの間に受信されてもよい。初期ＨＡＲＱブロックは、ダウンリンクデータブロックに基づいていてもよい。方法９００の動作９１０において、ＨＡＲＱ確認標識が、アップリンクサブフレームの間に送信されてもよい。ＨＡＲＱ確認標識は、受信した初期ＨＡＲＱブロックに基づいて、ダウンリンクデータブロックの復号の成功を示してもよい。方法９００の動作９１５において、ダイバーシティＨＡＲＱブロックが、第二ダウンリンクサブフレームの間に受信されてもよい。ダイバーシティＨＡＲＱブロックはダウンリンクデータブロックに基づいていてもよく、初期ＨＡＲＱブロックおよびダイバーシティＨＡＲＱブロックは、ダウンリンクデータブロックの復号の組み合わせを可能にする。
【００７０】
いくつかの実施形態において、第二ダウンリンクサブフレームとアップリンクサブフレームとの間の時間差およびアップリンクサブフレームと第一ダウンリンクサブフレームとの間の時間差は、通常モードで動作しているＵＥ１０２と比較して低遅延化モードで動作しているＵＥ１０２の方が小さい。つまり、方法５００に関連して先に記載されたように、ＲＴＤおよび再送信遅延は、通常モードで動作しているＵＥ１０２と比較して低遅延化モードで動作しているＵＥ１０２の方が少ない。
【００７１】
なお、いくつかの実施形態においてＨＡＲＱトラフィックは低遅延かまたは通常として特徴付けられることにも、注意すべきである。つまり、時間差は、通常トラフィックよりも低遅延化ＨＡＲＱトラフィックの方が小さい。場合により、ＵＥ１０２は、低遅延化ＨＡＲＱトラフィックが受信される低遅延化ＨＡＲＱセッションをサポートすること、および通常ＨＡＲＱトラフィックが受信される通常ＨＡＲＱセッションをサポートすることが、可能である。低遅延化ＨＡＲＱセッションおよび通常ＨＡＲＱセッションは、時間的に同時であるかまたは重複していてもよい。一例として、ＵＥ１０２は、同じサブフレームの間に各ＨＡＲＱセッションから初期ＨＡＲＱパケットを受信してもよい。加えて、低遅延化ＨＡＲＱセッションは（先に記載されたように）低遅延化リソースを利用してもよく、その一方で通常ＨＡＲＱセッションは、通常リソースまたは低遅延化リソース専用のリソースを利用してもよい。
【００７２】
いくつかの実施形態において、アップリンクおよびダウンリンクサブフレームの各々は、低遅延化ＵＥ１０２とのＨＡＲＱプロセスをサポートする時間および周波数リソースの低遅延化部分を備えてもよく、低遅延化部分専用の時間および周波数リソースの通常部分をさらに備えてもよい。ＵＥ１０２が低遅延化モードで動作するとき、ＨＡＲＱブロックはダウンリンクサブフレームの低遅延化部分で受信され、ＨＡＲＱ確認標識はアップリンクサブフレームの低遅延化部分で送信されてもよい。加えて、ＵＥ１０２が通常モードで動作するとき、ＨＡＲＱブロックはダウンリンクサブフレームの通常部分で受信され、ＨＡＲＱ確認標識はアップリンクサブフレームの通常部分で送信されてもよい。
【００７３】
なお、初期ＨＡＲＱブロック、ダイバーシティＨＡＲＱブロック、ＨＡＲＱ確認標識、ならびに低遅延化動作および通常動作の両方での時間および周波数リソースの割り当てなど、先に記載された概念および技術が方法９００に適用可能であることに、注意すべきである。加えて、図６から図８および他の箇所に記載されたサブフレームフォーマットもまた、方法９００に含まれる動作に使用されてよい。
【００７４】
一例として、アップリンクおよびダウンリンクサブフレームは、１つ以上のＬＴＥ規格にしたがって構成されてもよい。アップリンクまたはダウンリンクサブフレームの少なくとも１つの低遅延化部分は１つ以上の低遅延サブフレーム（ＬＬＳＦ）を含んでもよく、各ＬＬＳＦは時間的にＯＦＤＭ符号の隣接グループに及んでいる。ＬＬＳＦは、データブロックの送信用の低遅延データチャネル（ＬＬＤＣ）と、データブロックの制御情報を含む低遅延制御チャネル（ＬＬＣＣ）と、を備えてもよい。
【００７５】
別の例として、アップリンクおよびダウンリンクサブフレームは、１つ以上のＬＴＥ規格にしたがって構成されてもよく、アップリンクまたはダウンリンクサブフレームの少なくとも１つの低遅延化部分は１つ以上のＬＬＳＦを含んでもよい。各ＬＬＳＦは、データブロックの送信用のＬＬＤＣと、データブロックの制御情報を含むＬＬＣＣと、を備えてもよい。ＬＬＤＣおよびＬＬＣＣは、ＯＦＤＭ符号の間に周波数が多重化されてもよい。
【００７６】
方法９００で使用するために記載されたばかりの例示的サブフレームフォーマットは、図６から図８に示されるものやその他のものなど、先に記載されたサブフレームフォーマットと類似または同じであってもよい。アップリンクおよびダウンリンクは場合により同じサブフレームフォーマットを使用してもよいが、しかし実施形態はそのように限定されるものではなく、アップリンクおよびダウンリンクは場合により異なるサブフレームフォーマットを使用してもよい。加えて、アップリンクおよびダウンリンクサブフレームは、アップリンクフレームおよびダウンリンクフレームが実質的に同時に開始するように、共通の基準時間にしたがってタイムアラインされてもよい。しかしながら、アップリンクおよびダウンリンクサブフレームはまた、場合により時間的に交互になっていてもよい。たとえば、第一ダウンリンクサブフレームに及ぶ時間枠は、第一アップリンクサブフレームに含まれる最後のＯＦＤＭ符号のグループおよび第二アップリンクサブフレームに含まれる最初の符号のグループにも及んでよい。
【００７７】
方法９００に戻ると、動作９２０において、アップリンクスケジューリンググラントが受信されてもよい。グラントは、ＵＥ１０２による物理アップリンク共有チャネル（ＰＵＳＣＨ；Ｐｈｙｓｉｃａｌ  Ｕｐｌｉｎｋ  Ｓｈａｒｅｄ  Ｃｈａｎｎｅｌ）データブロックの送信のためのものである。動作９２５において、ＰＵＳＣＨデータブロックが送信されてもよい。ＰＵＳＣＨデータブロックの送信とアップリンクスケジューリンググラントの受信との間の時間差は、通常モードでのＵＥ１０２の動作と比較して、低遅延化モードでのＵＥ１０２の動作の方が小さい。いくつかの実施形態において、ＵＥ１０２が低遅延化モードで動作しているとき、ＰＵＳＣＨデータブロックは、アップリンクサブフレームの低遅延化部分で送信されてもよい。加えて、ＵＥ１０２が通常モードで動作しているとき、ＰＵＳＣＨデータブロックは、アップリンクサブフレームの低遅延化部分で送信されてもよい。
【００７８】
したがって、ダウンリンクＨＡＲＱ送信用の低遅延化に関する先の概念は、ＰＵＳＣＨデータブロックのアップリンク送信のために採用されてもよい。つまり、ＨＡＲＱブロックおよびＨＡＲＱ確認標識の送信間の時間差は、通常モードでのＵＥ１０２の動作と比較して、低遅延化モードでのＵＥ１０２の動作の方が小さい。
【００７９】
以下、概念の説明のため、ダウンリンクおよびアップリンクスケジューリングのいくつかの例が示される。低遅延サブフレーム（ＬＬＳＦ）の使用など、先に論じられた技術の使用は、このようなスケジューリングを通じて遅延の低減を可能にし得る。図１０は、いくつかの実施形態による、ダウンリンクおよびアップリンクスケジューリングの一例を説明する。この例および後に記載される例において、単一のＨＡＲＱプロセスまたはその他のプロセスは説明しやすくするために示されているが、しかしこれは限定的ではない。先に記載されたように、場合により複数のＨＡＲＱプロセスおよび／またはその他のプロセスがサポートされてもよい。
【００８０】
ダウンリンクはサブフレーム１０１０〜１０１３を使用してもよく、その一方でアップリンクはサブフレーム１０２０〜１０２３を使用してもよく、その各々は４つのＬＬＳＦを備えてもよい。この例において、アップリンクおよびダウンリンクサブフレームはタイムアラインされているが、しかしこれは限定的ではない。ＬＬＳＦは同じ数のＯＦＤＭ符号に及ぶように見えるものの、これは限定的ではなく、ＬＬＳＦは場合により異なる数のＯＦＤＭ符号に及んでもよい。限定されるわけではないが、サブフレームは、ＬＬＳＦが複数のＯＦＤＭ符号に及んでもよい、図６から図７の例にしたがってフォーマットされてもよい。
【００８１】
図示されるように、第一ダウンリンク送信１０３０は、サブフレーム１０１０の第一ＬＬＳＦの間に実行されてもよい。アップリンク送信１０３５は、５つのＬＬＳＦがダウンリンク送信１０３０以降に発生した後、サブフレーム１０２１の第三ＬＬＳＦの間に実行されてもよい。第二ダウンリンク送信１０５０は、５つのＬＬＳＦがアップリンク送信１０３５以降に発生した後、サブフレーム１０１３の第一ＬＬＳＦの間に実行されてもよい。これらの送信間の５つのＬＬＳＦの使用は、復号要件またはその他の要因にしたがって選択されてもよい。
【００８２】
一例として、ダウンリンク送信１０３０、１０５０はＨＡＲＱブロックを含んでもよく、アップリンク送信１０３５はＨＡＲＱ確認標識を含んでもよい。別の例として、ダウンリンク送信１０３０、１０５０はアップリンクスケジューリンググラントおよび／または物理ＨＡＲＱ標識チャネル（ＰＨＩＣＨ）ブロックを含んでもよく、アップリンク送信１０３５はＰＵＳＣＨデータブロックを含んでもよい。これらのプロセスは、先に記載されたような低遅延化プロセスであってもよい。比較例として、低遅延化モードで動作していないＵＥ１０２のための通常プロセスは、はるかに多くのＲＴＤおよび再送信時間を経験する可能性がある。
【００８３】
図１１は、いくつかの実施形態による、ダウンリンクおよびアップリンクスケジューリングの別の例を説明する。ダウンリンクはサブフレーム１１１０および１１１５を使用してもよく、アップリンクはサブフレーム１１２０および１１２５を使用してもよく、その各々は１４個のＯＦＤＭ符号を備えてもよい。この場合、アップリンクおよびダウンリンクサブフレームは、１１０５で示されるように、４つのＯＦＤＭ符号ずつ交互になっていてもよい。
【００８４】
このように限定されるものではないが、サブフレームは、ＬＬＳＦが単一のＯＦＤＭ符号に及ぶ、図８の例にしたがってフォーマットされてもよい。図示されるように、第一ダウンリンク送信１１３０はサブフレーム１１１０の第四ＯＦＤＭ符号の間に実行されてもよく、これはまたサブフレーム１１１０の第一ＬＬＳＦであってもよい。アップリンク送信１１４０はサブフレーム１１２０の第四ＯＦＤＭ符号の間に実行されてもよく、これはまたサブフレーム１１２０の第一ＬＬＳＦであってもよい。したがって、４つのＯＦＤＭ符号は、ダウンリンク送信１０３０以降に発生していてもよい。第二ダウンリンク送信１１５０はサブフレーム１１１５の第四ＯＦＤＭ符号の間に実行されてもよく、これはまたサブフレーム１１１５の第一ＬＬＳＦであってもよい。したがって、４つのＯＦＤＭ符号は、アップリンク送信１１４０以降に発生していてもよい。これらの送信間の４つのＯＦＤＭ符号の使用は、復号要件またはその他の要因にしたがって選択されてもよい。
【００８５】
図１０の例に関連して記載されたように、ダウンリンクおよびアップリンク送信は、場合によりＨＡＲＱブロックおよびＨＡＲＱ確認標識であるかまたはこれを含んでもよいが、しかしまたアップリンクスケジューリンググラントおよびＰＵＳＣＨデータブロックであるかまたはこれを含んでもよい。これらのプロセスは、先に記載されたような低遅延化プロセスであってもよく、低遅延化モードで動作していないＵＥ１０２のための通常プロセスは、はるかに多くのＲＴＤおよび再送信時間を経験する可能性がある。
【００８６】
図１２は、いくつかの実施形態による、ダウンリンクおよびアップリンクスケジューリングの別の例を説明する。例示的シナリオ１２００は、ダウンリンクおよびアップリンク送信間に短縮区間を有して、図１０のシナリオ１０００と類似であってもよい。短縮区間は、復号の複雑さまたはその他の要因に基づいていてもよい。なお、アップリンク送信１２３５はＬＬＳＦ１２２７の単一のＯＦＤＭ符号内で行われることに注意すべきであり、これはこの例において４つのＯＦＤＭ符号を備える。したがって、ｅＮＢ１０４は、ダウンリンク送信１２４０を実行するために時間内にアップリンク送信１２３５内のデータを復号できるようにするが、これは復号されたデータに基づいていてもよい。
【００８７】
図１３は、いくつかの実施形態による、ダウンリンクおよびアップリンクスケジューリングの別の例を説明する。例示的シナリオ１３００は、ダウンリンクおよびアップリンク送信間に短縮区間を有して、図１１のシナリオ１１００と類似であってもよい。先のケースのように、短縮区間は復号の複雑さまたはその他の要因に基づいていてもよい。
【００８８】
進化型ノードＢ（ｅＮＢ）が本明細書に開示されている。ｅＮＢは、トランシーバ回路を含む、ハードウェア処理回路を備えてもよい。トランシーバ回路は、第一ユーザ機器（ＵＥ）とのハイブリッド自動再送要求（ＨＡＲＱ）プロセスの一部として、第一データブロック用の初期ＨＡＲＱブロックを送信するように、および第一データブロック用のダイバーシティＨＡＲＱブロックを送信するように、構成されてもよい。第一データブロック用のＨＡＲＱブロックの送信は、所定のＨＡＲＱ区間だけ時間的に離間したサブフレームの間に行われてもよい。トランシーバ回路は、低遅延化ＵＥとのＨＡＲＱプロセスの一部として、低遅延化データブロック用の初期ＨＡＲＱブロックを送信するように、および低遅延化データブロック用のダイバーシティＨＡＲＱブロックを送信するように、さらに構成されてもよい。低遅延化データブロック用のＨＡＲＱブロックの送信は、ＨＡＲＱ区間よりも短い所定の低遅延化ＨＡＲＱ区間だけ時間的に離間したサブフレームの間に行われてもよい。
【００８９】
いくつかの実施形態において、低遅延化データブロック用のＨＡＲＱブロックは、低遅延化ＵＥとのＨＡＲＱプロセスのために確保された時間および周波数リソース内で送信されてもよい。第一データブロック用のＨＡＲＱブロックは、低遅延化ＵＥとのＨＡＲＱプロセスのために確保されたものを除く時間および周波数リソース内で送信されてもよい。いくつかの実施形態において、サブフレームはロングタームエボリューション（ＬＴＥ）規格にしたがって構成されてもよい。ＨＡＲＱブロックは１つ以上の直交周波数分割多重（ＯＦＤＭ）信号を用いて送信されてもよく、ＯＦＤＭ信号の周波数リソースは複数のリソース要素（ＲＥ）を備えてもよい。
【００９０】
いくつかの実施形態において、サブフレームは、低遅延化ＵＥとのＨＡＲＱプロセスのために確保された時間および周波数リソースの低遅延化領域と、低遅延化領域専用の時間および周波数リソースの通常領域と、を備えてもよい。ＯＦＤＭ周波数リソースは複数のリソースブロック（ＲＢ）を含んでもよく、各ＲＢは周波数が隣接する複数のＲＥを備えてもよい。低遅延化領域は、周波数におけるＲＢの少なくとも一部と、時間における複数の低遅延サブフレーム（ＬＬＳＦ）と、を含んでもよい。各ＬＬＳＦはＯＦＤＭ符号の隣接グループに及んでもよい。ＬＬＳＦは、データブロックの送信用の低遅延データチャネル（ＬＬＤＣ）と、データブロックの制御情報を含む低遅延制御チャネル（ＬＬＣＣ）と、を備えてもよい。
【００９１】
いくつかの実施形態において、サブフレームは、低遅延化ＵＥとのＨＡＲＱプロセスのために確保された時間および周波数リソースの低遅延化領域と、低遅延化領域専用の時間および周波数リソースの通常領域と、を備えてもよい。低遅延化領域は１つ以上の低遅延サブフレーム（ＬＬＳＦ）を含んでもよく、各ＬＬＳＦは、データブロックの送信用の低遅延データチャネル（ＬＬＤＣ）と、データブロックの制御情報を含む低遅延制御チャネル（ＬＬＣＣ）と、を備えてもよい。ＬＬＤＣおよびＬＬＣＣは、単一のＯＦＤＭ符号の間に周波数が多重化されてもよい。
【００９２】
いくつかの実施形態において、サブフレームの各々は、サブフレーム内の第一ＯＦＤＭ符号を含むＯＦＤＭ符号の隣接グループに及ぶ物理ダウンリンク制御チャネル（ＰＤＣＣＨ）を、さらに備えてもよい。ＰＤＣＣＨは、低遅延化ＵＥとのＨＡＲＱプロセスのために確保された時間および周波数リソースを識別する情報を含んでもよい。いくつかの実施形態において、第一データブロック用の初期ＨＡＲＱブロックおよび低遅延化データブロック用の初期ＨＡＲＱブロックは、同じサブフレームの間に送信されてもよい。
【００９３】
ハードウェア処理回路は、第一データブロック用の受信したＨＡＲＱ確認標識が、第一データブロック用の初期ＨＡＲＱブロックに基づいて第一データブロックの、第一ＵＥにおける復号の成功を示すときに、第一データブロック用のダイバーシティＨＡＲＱブロックの送信をトランシーバ回路に控えさせるように、構成されてもよい。ハードウェア処理回路は、低遅延化データブロック用の受信したＨＡＲＱ確認標識が、低遅延化データブロック用の初期ＨＡＲＱブロックに基づいて低遅延化データブロックの、低遅延化ＵＥにおける復号の成功を示すときに、低遅延化データブロック用のダイバーシティＨＡＲＱブロックの送信をトランシーバ回路に控えさせるように、さらに構成されてもよい。
【００９４】
ハードウェア処理回路は、低遅延化データブロック用の初期ＨＡＲＱブロックの送信の１ミリ秒以内に、低遅延化ＵＥにおける、低遅延化データブロック用の初期ＨＡＲＱブロックの復号成功の確認標識をトランシーバ回路に受信させるように、さらに構成されてもよい。
【００９５】
ハイブリッド自動再送要求（ＨＡＲＱ）データ送信の方法もまた、本明細書に開示されている。方法は、サブフレームのグループの間に１つ以上の初期ＨＡＲＱブロックを送信するステップを含んでもよい。各サブフレームの時間および周波数リソースは、低遅延化ＨＡＲＱ送信のために確保された低遅延化部分と、低遅延化部分専用の通常部分と、を備えてもよい。方法は、データブロックの復号の成功の１つ以上のＨＡＲＱ確認標識を受信するステップを、さらに含んでもよい。方法は、サブフレームのグループの間に、ＨＡＲＱ確認標識によってうまく復号されたと通知されない各データブロック用のダイバーシティＨＡＲＱブロックを送信するステップを、さらに含んでもよい。各ダイバーシティＨＡＲＱブロックは、対応する初期ＨＡＲＱブロックと比較して、サブフレームの所定間隔にしたがって送信されてもよく、低遅延化モードで動作しているＵＥの間隔は、通常モードで動作しているＵＥの間隔よりも狭くてもよい。
【００９６】
いくつかの実施形態において、サブフレームは１つ以上のロングタームエボリューション（ＬＴＥ）規格にしたがって構成されてもよく、ＨＡＲＱブロックは、複数のリソース要素（ＲＥ）を備えるＯＦＤＭ周波数リソースを使用する１つ以上の直交周波数分割多重（ＯＦＤＭ）信号を用いて送信されてもよい。いくつかの実施形態において、ＯＦＤＭ周波数リソースは複数のリソースブロック（ＲＢ）を含んでもよく、各ＲＢは周波数が隣接する複数のＲＥを備えてもよい。低遅延化部分は、周波数における１つ以上のＲＢおよび時間における複数の低遅延サブフレーム（ＬＬＳＦ）を含んでもよい。各ＬＬＳＦはＯＦＤＭ符号の隣接グループに及んでもよい。ＬＬＳＦは、データブロックの送信用の低遅延データチャネル（ＬＬＤＣ）と、データブロックの制御情報を含む低遅延制御チャネル（ＬＬＣＣ）と、を備えてもよい。
【００９７】
いくつかの実施形態において、低遅延化部分は１つ以上の低遅延サブフレーム（ＬＬＳＦ）を含んでもよい。各ＬＬＳＦは、データブロックの送信用の低遅延データチャネル（ＬＬＤＣ）と、データブロックの制御情報を含む低遅延制御チャネル（ＬＬＣＣ）と、を備えてもよい。ＬＬＤＣおよびＬＬＣＣは、単一のＯＦＤＭ符号の間に周波数が多重化されてもよい。いくつかの実施形態において、サブフレームの各々は、サブフレーム内の第一ＯＦＤＭ符号を含むＯＦＤＭ符号の隣接グループに及ぶ物理ダウンリンク制御チャネル（ＰＤＣＣＨ）を、さらに備えてもよい。ＰＤＣＣＨは、低遅延化部分の時間および周波数リソースを識別する情報を含んでもよい。
【００９８】
ハイブリッド自動再送要求（ＨＡＲＱ）送信の動作を実行するために１つ以上のプロセッサによって実行される命令を記憶する非一時的コンピュータ可読記憶媒体もまた、本明細書に開示されている。動作は、第一ユーザ機器（ＵＥ）とのＨＡＲＱプロセスの一部として、トランシーバに、第一データブロック用の初期ＨＡＲＱブロックを送信させ、第一データブロック用のダイバーシティＨＡＲＱブロックを送信させるように、１つ以上のプロセッサを構成してもよい。第一データブロック用のＨＡＲＱブロックの送信は、所定のＨＡＲＱ区間によって時間的に離間したサブフレームの間に行われてもよい。動作は、低遅延化ＵＥとのＨＡＲＱプロセスの一部として、トランシーバに、低遅延化データブロック用の初期ＨＡＲＱブロックを送信させ、低遅延化データブロック用のダイバーシティＨＡＲＱブロックを送信させるように、１つ以上のプロセッサをさらに構成してもよい。低遅延化データブロック用のＨＡＲＱブロックの送信は、ＨＡＲＱ区間よりも短い所定の低遅延化ＨＡＲＱ区間によって時間的に離間したサブフレームの間に行われてもよい。
【００９９】
いくつかの実施形態において、低遅延化データブロック用のＨＡＲＱブロックは、低遅延化ＵＥとのＨＡＲＱプロセスのために確保された時間および周波数リソース内で送信されてもよい。第一データブロック用のＨＡＲＱブロックは、低遅延化ＵＥとのＨＡＲＱプロセスのために確保されたものを除く時間および周波数リソース内で送信されてもよい。いくつかの実施形態において、サブフレームは１つ以上のロングタームエボリューション（ＬＴＥ）規格にしたがって構成されてもよく、ＨＡＲＱブロックは、複数のリソース要素（ＲＥ）を備えるＯＦＤＭ周波数リソースを使用する１つ以上の直交周波数分割多重（ＯＦＤＭ）信号を用いて送信されてもよい。
【０１００】
トランシーバ回路を含むハードウェア処理回路を備えるユーザ機器（ＵＥ）もまた、本明細書に開示されている。トランシーバ回路は、第一ダウンリンクサブフレームの間に初期ハイブリッド自動再送要求（ＨＡＲＱ）ブロックを受信するように構成されてもよい。初期ＨＡＲＱブロックはダウンリンクデータブロックに基づいていてもよい。トランシーバ回路は、アップリンクサブフレームの間に、受信された初期ＨＡＲＱブロックに基づいてダウンリンクデータブロックの復号の成功を示すＨＡＲＱ確認標識を送信するように、さらに構成されてもよい。トランシーバ回路は、第二ダウンリンクサブフレームの間にダイバーシティＨＡＲＱブロックを受信するように、さらに構成されてもよい。ダイバーシティＨＡＲＱブロックはダウンリンクデータブロックに基づいていてもよく、初期ＨＡＲＱブロックおよびダイバーシティＨＡＲＱブロックは、ダウンリンクデータブロックの復号の組み合わせを可能にする。第二ダウンリンクサブフレームとアップリンクサブフレームとの間の時間差、およびアップリンクサブフレームと第一ダウンリンクサブフレームとの間の時間差は、通常モードで動作しているＵＥと比較して、低遅延化モードで動作しているＵＥの方が小さい。
【０１０１】
いくつかの実施形態において、初期およびダイバーシティＨＡＲＱブロックの受信、ならびにＨＡＲＱ確認標識の送信は、ＨＡＲＱプロセスの一部として実行されてもよい。時間差は、通常ＨＡＲＱプロセスよりも低遅延化ＨＡＲＱプロセスの方が小さい。ハードウェア処理回路は、重複期間の間、低遅延化ＨＡＲＱプロセスおよび通常プロセスをサポートするように構成されてもよい。
【０１０２】
いくつかの実施形態において、アップリンクおよびダウンリンクサブフレームの各々は、低遅延化ＵＥとのＨＡＲＱプロセスをサポートする時間および周波数リソースの低遅延化部分を備えてもよく、低遅延化部分専用の時間および周波数リソースの通常部分をさらに備えてもよい。いくつかの実施形態において、ＵＥが低遅延化モードで動作するとき、ＨＡＲＱブロックはダウンリンクサブフレームの低遅延化部分において受信されてもよく、ＨＡＲＱ確認標識はアップリンクサブフレームの低遅延化部分において送信されてもよい。ＵＥが通常モードで動作するとき、ＨＡＲＱブロックはダウンリンクサブフレームの通常部分において受信されてもよく、ＨＡＲＱ確認標識はアップリンクサブフレームの通常部分において送信されてもよい。
【０１０３】
いくつかの実施形態において、アップリンクおよびダウンリンクサブフレームは、１つ以上のロングタームエボリューション（ＬＴＥ）規格にしたがって構成されてもよい。アップリンクまたはダウンリンクサブフレームの少なくとも１つの低遅延化部分は１つ以上の低遅延サブフレーム（ＬＬＳＦ）を含んでもよく、各ＬＬＳＦは時間的に直交周波数分割多重（ＯＦＤＭ）符号の隣接グループに及んでもよい。ＬＬＳＦは、データブロックの送信用の低遅延データチャネル（ＬＬＤＣ）と、データブロックの制御情報を含む低遅延制御チャネル（ＬＬＣＣ）と、を備えてもよい。
【０１０４】
いくつかの実施形態において、アップリンクおよびダウンリンクサブフレームは、１つ以上のロングタームエボリューション（ＬＴＥ）規格にしたがって構成されてもよい。アップリンクまたはダウンリンクサブフレームの少なくとも１つの低遅延化部分は１つ以上の低遅延サブフレーム（ＬＬＳＦ）を含んでもよく、各ＬＬＳＦは、データブロックの送信用の低遅延データチャネル（ＬＬＤＣ）と、データブロックの制御情報を含む低遅延制御チャネル（ＬＬＣＣ）と、を備えてもよい。ＬＬＤＣおよびＬＬＣＣは、直交周波数分割多重（ＯＦＤＭ）符号の間、周波数が多重化されてもよい。
【０１０５】
いくつかの実施形態において、アップリンクおよびダウンリンクサブフレームは、第一ダウンリンクサブフレームに及ぶ時間枠が、第一アップリンクサブフレームに含まれる最後のＯＦＤＭ符号のグループおよび第二アップリンクサブフレームに含まれる最初の符号のグループにも及ぶように、時間的に交互になっていてもよい。ハードウェア処理回路は、ＵＥによる物理アップリンク共有チャネル（ＰＵＳＣＨ）データブロックの送信のためのアップリンクスケジューリンググラントをトランシーバ回路に受信させるように、構成されてもよい。ハードウェア処理回路は、ＰＵＳＣＨデータブロックの送信とアップリンクスケジューリンググラントの受信との間の時間差にしたがってＰＵＳＣＨデータブロックをトランシーバ回路に送信させるように、さらに構成されてもよい。時間差は、通常モードでのＵＥ動作と比較して、低遅延モードでのＵＥ動作の方が小さい。時間差は、いくつかの実施形態において、予め決まっていてもよい。
【０１０６】
いくつかの実施形態において、ＵＥが低遅延化モードで動作するとき、ＰＵＳＣＨデータブロックはアップリンクサブフレームの低遅延化部分において送信されてもよい。ＵＥが通常モードで動作するとき、ＰＵＳＣＨデータブロックはアップリンクサブフレームの低遅延化部分において送信されてもよい。
【０１０７】
技術的開示の本質および要旨を読者に確認させる要約書を要求する米国特許規則３７Ｃ．Ｆ．Ｒ．セクション１．７２（ｂ）に準拠するため、要約書が提供される。これは、請求項の範囲または意味を限定または解釈するために使用されるものではないという理解のもと、提出される。以下の請求項はこれにより詳細な説明に組み込まれ、各クレームは個別の実施形態として独立している。
【図１】
2017523641.tif 000003
【図２】
2017523641.tif 000004
【図３】
2017523641.tif 000005
【図４】
2017523641.tif 000006
【図５】
2017523641.tif 000007
【図６】
2017523641.tif 000008
【図７】
2017523641.tif 000009
【図８】
2017523641.tif 000010
【図９】
2017523641.tif 000011
【図１０】
2017523641.tif 000012
【図１１】
2017523641.tif 000013
【図１２】
2017523641.tif 000014
【図１３】
2017523641.tif 000015
【国際調査報告】
2017523641.tif 000016
2017523641.tif 000017
2017523641.tif 000018