(57)【要約】【課題】ＨＡＲＱフィードバックの方法および装置、指示情報を送る方法および装置、ならびに、それらのＵＥ、基地局、およびコンピュータ可読記憶媒体を提供すること。【解決手段】このＨＡＲＱフィードバック方法は、基地局から第１のサービス・データ送信を受信することであって、第１のサービス・データ送信のスケジュール制御データは指示情報を運び、この情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示するように構成される、受信することと、指示情報に従って、送信リソースをプリエンプトする第２のサービス・データをキャッシュに保存し、第１のサービス・データのＨＡＲＱフィードバック情報を生成することと、ＨＡＲＱフィードバック情報を基地局へ送ることとを含む。本開示の実施形態によれば、指示情報に基づいて送信リソースをプリエンプトする第２のサービス・データを保存することにより、第１のサービス・データ送信時に、有用な第２のサービス・データが破棄されなくてもよい。【選択図】図１
2020523877.tif 000002
【特許請求の範囲】
【請求項１】
ハイブリッド自動反復要求（ＨＡＲＱ）フィードバック方法であって、
基地局から第１のサービス・データ送信を受信するステップであって、該第１のサービス・データ送信のスケジュール制御データは指示情報を運び、該指示情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすることと、または、該第２のサービス・データが該第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示するように構成される、受信するステップと、
該指示情報に従って、該送信リソースをプリエンプトする該第２のサービス・データをキャッシュに保存し、該第１のサービス・データのＨＡＲＱフィードバック情報を生成するステップと、
該ＨＡＲＱフィードバック情報を該基地局へ送るステップと
を含む、方法。
【請求項２】
第１のサービス・データ送信を基地局から受信する前記ステップが、
２つの第１のサービス・データ送信を該基地局から受信するステップを含み、該２つの第１のサービス・データ送信の間の時間間隔は、非適応型ＨＡＲＱフィードバック・モードにおける送信レイテンシより短く、
前記指示情報が後の第１のサービス・データ送信の前記スケジュール制御データにて運ばれ、該指示情報は、前記第２のサービス・データが前記第１のサービス・データの前記送信リソースをプリエンプトすること、または、前記第２のサービス・データが先の第１のサービス・データ送信における前記第１のサービス・データの前記送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示するように構成される、請求項１記載の方法。
【請求項３】
前記第１のサービス・データのＨＡＲＱフィードバック情報を生成する前記ステップが、
前記送信リソースをプリエンプトする前記第２のサービス・データ以外のデータの送信成功または失敗状態に基づいて、該ＨＡＲＱフィードバック情報を生成するステップ、または、
該送信リソースをプリエンプトする該第２のサービス・データの送信成功または失敗状態を送信成功と設定し、前記第１のサービス・データ送信にあるすべてのデータの送信成功または失敗状態に基づいて該ＨＡＲＱフィードバック情報を生成するステップ
を含む、請求項１記載の方法。
【請求項４】
前記指示情報が、前記第２のサービス・データが前記第１のサービス・データの前記送信リソースをプリエンプトすることを、明示的または暗示的に、指示するように構成されるとき、該送信リソースをプリエンプトする該第２のサービス・データをキャッシュに保存し、該第１のサービス・データのＨＡＲＱフィードバック情報を生成する前記ステップが、
送信に失敗したすべてのデータを該キャッシュに保存し、該保存されたデータの中から、送信に失敗した該第１のサービス・データを識別し、送信に失敗した該第１のサービス・データに基づいて、該ＨＡＲＱフィードバック情報を生成するステップを含む、請求項１記載の方法。
【請求項５】
前記指示情報が、前記後の第１のサービス・データ送信の前記スケジュール制御データにて運ばれる場合、前記基地局へ前記ＨＡＲＱフィードバック情報を送る前記ステップが、
前記非適応型ＨＡＲＱフィードバック・モードにて該基地局へ該ＨＡＲＱフィードバック情報を送るステップを含む、請求項２記載の方法。
【請求項６】
前記指示情報を運ぶ前記第１のサービス・データ送信の前記スケジュール制御データが、
スクランブル化コード形式の該スケジュール制御データにおける標的制御情報へと該指示情報をスクランブル化するステップを含む、請求項１記載の方法。
【請求項７】
指示情報を送るための方法であって、
第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトするか否かを判断するステップと、
該第２のサービス・データが該第１のサービス・データの該送信リソースをプリエンプトする場合、第１のサービス・データ送信をユーザ機器（ＵＥ）へ送るステップであって、該第１のサービス・データ送信のスケジュール制御データは指示情報を運び、該指示情報は、該第２のサービス・データが該第１のサービス・データの該送信リソースをプリエンプトすること、または、該第２のサービス・データが該第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示するように構成され、それにより、該ＵＥは、該指示情報に従って、該送信リソースをプリエンプトする該第２のサービス・データをキャッシュに保存し、該第１のサービス・データのＨＡＲＱフィードバック情報を基地局へ送る、送るステップと
を含む、方法。
【請求項８】
第１のサービス・データ送信を前記ＵＥへ送る前記ステップが、
２つの第１のサービス・データ送信を該ＵＥへ送ることを含み、前記２つの第１のサービス・データ送信の間の時間間隔は、非適応型ＨＡＲＱフィードバック・モードの送信レイテンシよりも短く、
前記指示情報は後の第１のサービス・データ送信の前記スケジュール制御データにて運ばれ、該指示情報は、前記第２のサービス・データが前記第１のサービス・データの前記送信リソースをプリエンプトすること、または、該第２のサービス・データが先の第１のサービス・データ送信における該第１のサービス・データの前記送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示するように構成される、請求項７記載の方法。
【請求項９】
前記指示情報が前記第２のサービス・データが前記第１のサービス・データの前記送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示するように構成されるとき、前記方法は、
該第１のサービス・データのＨＡＲＱフィードバック情報を前記ＵＥから受信するステップであって、該ＨＡＲＱフィードバック情報は、該送信リソース位置に対応する該第２のサービス・データのＨＡＲＱフィードバック情報、および他の送信リソース位置に対応する該第１のサービス・データのＨＡＲＱフィードバック情報を含む、受信するステップと、
他の送信リソース位置に対応する該第１のサービス・データの該ＨＡＲＱフィードバック情報に従って、該ＵＥに送信に失敗した該第１のサービス・データを再送信するステップと
をさらに含む、請求項７または８記載の方法。
【請求項１０】
前記指示情報を運ぶ前記第１のサービス・データ送信の前記スケジュール制御データが、
スクランブル化コード形式の該スケジュール制御データにおける標的制御情報へと該指示情報をスクランブル化するステップを含む、請求項７記載の方法。
【請求項１１】
ハイブリッド自動反復要求（ＨＡＲＱ）フィードバック装置であって、
基地局から第１のサービス・データ送信を受信するように構成された受信モジュールであって、該第１のサービス・データ送信のスケジュール制御データは指示情報を運び、該指示情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、該第２のサービス・データが該第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示するように構成される、受信モジュールと、
該受信モジュールによって受信された、該第１のサービス・データ送信の該スケジュール制御データにて運ばれる該指示情報に従って、該送信リソースをプリエンプトする該第２のサービス・データをキャッシュに保存し、該第１のサービス・データのＨＡＲＱフィードバック情報を生成するように構成された、保存生成モジュールと、
該保存生成モジュールによって生成された該ＨＡＲＱフィードバック情報を該基地局へ送るように構成された送信モジュールと
を含む、装置。
【請求項１２】
前記受信モジュールが、前記基地局から２つの第１のサービス・データ送信を受信するように構成され、該２つの第１のサービス・データ送信の間の時間間隔は、非適応型ＨＡＲＱフィードバック・モードの送信レイテンシよりも短く、
前記指示情報が後の第１のサービス・データ送信の前記スケジュール制御データにて運ばれ、該指示情報は、前記第２のサービス・データが前記第１のサービス・データの前記送信リソースをプリエンプトすること、または、該第２のサービス・データが先の第１のサービス・データ送信における該第１のサービス・データの前記送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示するように構成される、請求項１１記載の装置。
【請求項１３】
前記保存生成モジュールが、
前記送信リソースをプリエンプトする前記第２のサービス・データ以外のデータの送信成功または失敗状態に基づいて、前記ＨＡＲＱフィードバック情報を生成するように構成された第１の生成サブモジュール、または、
該送信リソースをプリエンプトする該第２のサービス・データの送信成功または失敗状態を送信成功と設定し、前記第１のサービス・データ送信にあるすべてのデータの送信成功または失敗状態に基づいて、該ＨＡＲＱフィードバック情報を生成するように構成された第２の生成サブモジュール
を含む、請求項１１記載の装置。
【請求項１４】
前記指示情報が、前記第２のサービス・データが前記第１のサービス・データの前記送信リソースをプリエンプトすることを、明示的または暗示的に、指示するように構成されるとき、前記保存生成モジュールが、
送信に失敗したすべてのデータを前記キャッシュに保存し、該保存されたデータの中から、送信に失敗した該第１のサービス・データを識別し、送信に失敗した該第１のサービス・データに基づいて、前記ＨＡＲＱフィードバック情報を生成するように構成される、請求項１１記載の装置。
【請求項１５】
前記指示情報が、前記後の第１のサービス・データ送信の前記スケジュール制御データにて運ばれるとき、前記送信モジュールが、前記非適応型ＨＡＲＱフィードバック・モードで前記ＨＡＲＱフィードバック情報を前記基地局へ送るように構成される、請求項１２記載の装置。
【請求項１６】
前記指示情報がスクランブル化コード形式の前記スケジュール制御データにおける標的制御情報にスクランブル化される、請求項１１記載の装置。
【請求項１７】
指示情報を送るための装置であって、
第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトするか否かを判断するように構成された判断モジュールと、
前記判断モジュールが該第２のサービス・データが該第１のサービス・データの該送信リソースをプリエンプトすると判断した場合、第１のサービス・データ送信をユーザ機器（ＵＥ）へ送り、該第１のサービス・データ送信のスケジュール制御データが指示情報を含み、該指示情報は、該第２のサービス・データが該第１のサービス・データの該送信リソースをプリエンプトすること、または、該第２のサービス・データが該第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示するように構成され、それにより、該ＵＥが、該指示情報に従って、該送信リソースをプリエンプトする該第２のサービス・データをキャッシュに保管し、該第１のサービス・データのＨＡＲＱフィードバック情報を基地局へ送る、ように構成された判定送信モジュールと
を備える、装置。
【請求項１８】
前記判定送信モジュールが、
２つの第１のサービス・データ送信を前記ＵＥへ送るように構成され、該２つの第１のサービス・データ送信の間の時間間隔は、非適応型ＨＡＲＱフィードバック・モードの送信レイテンシよりも短く、
ここで、前記指示情報は、後の第１のサービス・データ送信の前記スケジュール制御データにて運ばれ、該指示情報は、前記第２のサービス・データが前記第１のサービス・データの前記送信リソースをプリエンプトすること、または、該第２のサービス・データが、先の第１のサービス・データ送信における該第１のサービス・データの前記送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示するように構成される、請求項１７記載の装置。
【請求項１９】
前記指示情報が、前記第２のサービス・データが前記第１のサービス・データの前記送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示するように構成されるとき、前記装置は、
前記判定送信モジュールが該第１のサービス・データ送信を前記ＵＥへ送った後、該ＵＥから該第１のサービス・データのＨＡＲＱフィードバック情報を受信するように構成された受信モジュールであって、該ＨＡＲＱフィードバック情報は該送信リソース位置に対応する該第２のサービス・データのＨＡＲＱフィードバック情報および他の送信リソース位置に対応する該第１のサービス・データのＨＡＲＱフィードバック情報を含む、受信モジュールと、
該受信モジュールによって受信された、他の送信リソース位置に対応する該第１のサービス・データの該ＨＡＲＱフィードバック情報に従って、該ＵＥへの送信に失敗した該第１のサービス・データを再送信するように構成された再送信モジュールと
をさらに含む、請求項１７または１８記載の装置。
【請求項２０】
前記指示情報がスクランブル化コード形式の前記スケジュール制御データにおける標的制御情報にスクランブル化される、請求項１７記載の装置。
【請求項２１】
プロセッサと、
該プロセッサによって実行可能な命令を記憶するためのメモリと
を含む、ユーザ機器であって、
該プロセッサが、
基地局から第１のサービス・データ送信を受信することであって、該第１のサービス・データ送信のスケジュール制御データが指示情報を運び、該指示情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、該第２のサービス・データが該第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示するように構成される、受信することと、
該指示情報に従って、該送信リソースをプリエンプトする該第２のサービス・データをキャッシュに保存し、該第１のサービス・データのＨＡＲＱフィードバック情報を生成することと、
該ＨＡＲＱフィードバック情報を該基地局へ送ることと
を行うように構成される、ユーザ機器。
【請求項２２】
プロセッサと、
該プロセッサによって実行可能な命令を記憶するためのメモリと
を含む基地局であって、
該プロセッサは、
第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトするか否かを判断し、
該第２のサービス・データが該第１のサービス・データの該送信リソースをプリエンプトする場合、第１のサービス・データ送信をユーザ機器（ＵＥ）へ送り、該第１のサービス・データ送信のスケジュール制御データが指示情報を運び、該指示情報は、該第２のサービス・データが該第１のサービス・データの該送信リソースをプリエンプトすること、または、該第２のサービス・データが該第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示するように構成され、それにより、該ＵＥは、該指示情報に従って、該送信リソースをプリエンプトする該第２のサービス・データをキャッシュに保存し、該第１のサービス・データのＨＡＲＱフィードバック情報を基地局へ送る
ように構成される、基地局。
【請求項２３】
コンピュータ・プログラムを記憶するコンピュータ可読記憶媒体であって、該コンピュータ・プログラムは、プロセッサによって実行されると、該プロセッサに、請求項１記載のＨＡＲＱフィードバック方法のステップを実行させる、コンピュータ可読記憶媒体。
【請求項２４】
コンピュータ・プログラムを記憶するコンピュータ可読記憶媒体であって、該コンピュータ・プログラムは、プロセッサによって実行されると、前記プロセッサに、請求項７記載の指示情報を送るための方法のステップを実行させる、コンピュータ可読記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、通信テクノロジーの分野に関するものであり、特に、ハイブリッド自動反復要求（ＨＡＲＱ）フィードバック方法および装置、指示情報を送るための方法および装置、ならびに、そのユーザ機器（ＵＥ）、基地局、およびコンピュータ可読記憶媒体に関する。
【背景技術】
【０００２】
通信テクノロジーの発展とともに、第５世代モバイル通信テクノロジー（５Ｇ）が、開発されてきた。５Ｇにおけるサービスの種類は、少なくとも、高速モバイル・ブロード・バンド（ｅＭＢＢ）、大数量機械タイプ通信（ｍＭＴＣ）、超高信頼度低レイテンシ通信（ＵＲＬＬＣ）などを含む。これらのサービス種類は、すべて、データ・サービスに関するものであるが、レイテンシおよび信頼度に関して課す要件は異なる。たとえば、ＵＲＬＬＣサービスは、低レイテンシが要求される車両のインターネットなどの分野に適用される。このサービスは、適時性について、より厳格な要件を課し、適時のサービス確立を要求するか、またはさらには元のサービスをプリエンプト(preempt)する。ｍＭＴＣサービスは、レイテンシに敏感ではなく、このサービスでは、データは、時間間隔をさらに空けて送信されてもよい。レイテンシに敏感なサービスの有効な送信を実現する１つの方法は、ハイブリッド自動反復要求（ＨＡＲＱ）の送信を改良して、たとえば、再送信フィードバックを、より迅速、より正確にすることである。
【０００３】
ロング・ターム・エボリューション（ＬＴＥ）では、ＨＡＲＱフィードバックは、送信ブロック（ＴＢ）を単位として用いて実行され、各ＴＢは、１ビットの肯定応答（ＡＣＫ）または否定応答（ＮＡＣＫ）メッセージをフィードバックする。再送信の正確性を向上させるため、第３世代パートナーシップ・プロジェクト（３ＧＰＰ）は、コード・ブロック・グループ（ＣＢＧ）に基づく再送信を提案している。ＣＢＧは、ＴＢにおける、さらにより小さなデータ単位である。１個のＣＢＧは、１ビットのＡＣＫまたはＮＡＣＫのフィードバックに対応する。再送信の粒度がさらに細かくなるので、不正確な送信の位置が、より精密に反映され得ることになり、再送信がより正確となる。さらに、再送信に要するデータ量がなおいっそう少なくなるので、再送信効率が向上する。
【０００４】
しかし、たとえば、ｅＭＢＢサービスが送信中であるかまたは送信予定であり、かつＵＲＬＬＣサービスが起動中であるときのサービス・プリエンプションの場合、ＵＲＬＬＣサービスは、ｅＭＢＢサービスの送信時間−周波数リソースをプリエンプトすることができる。その結果、元のｅＭＢＢサービスは、ＨＡＲＱフィードバック・プロセスにおいて、ｅＭＢＢデータが不正確に送信されるものと誤認し、その結果、有用なＵＲＬＬＣデータが破棄されることがあり得る。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
以上に基づき、本開示は、有用なサービス・データを破棄しないような、指示情報を送るための方法および装置、ならびにそのユーザ機器（ＵＥ）、基地局、およびコンピュータ可読記憶媒体を提供する。
【課題を解決するための手段】
【０００６】
本開示の実施形態の第１の態様により、ハイブリッド自動反復要求（ＨＡＲＱ）フィードバック方法が提供され、この方法は、
基地局から第１のサービス・データ送信を受信することであって、第１のサービス・データ送信のスケジュール制御データは指示情報を運び、それは、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプト(preempt)すること、または第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に示すように構成されている、受信することと、
指示情報に従って送信リソースをプリエンプトする第２のサービス・データをキャッシュに保存し、第１のサービス・データのＨＡＲＱフィードバック情報を生成することと、
そのＨＡＲＱフィードバック情報を基地局に送信することと、を含む。
【０００７】
１つの実施形態において、基地局から第１のサービス・データを受信することは、
基地局から２つの第１のサービス・データ送信を受信することを含み、その２つの第１のサービス・データ送信の時間間隔は非適応型ＨＡＲＱフィードバック・モードにおける送信レイテンシよりも短く、
後の第１のサービス・データ送信のスケジュール制御データにて指示情報が運ばれ、その指示情報は、第２のサービス・データが、第１のサービス・データの送信リソースをプリエンプトすること、または第２のサービス・データが、先の第１のサービス・データ送信における第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に指示する。
【０００８】
１つの実施形態において、第１のサービス・データのＨＡＲＱフィードバック情報を生成することは、
送信リソースをプリエンプトする第２のサービス・データ以外のデータの送信の成功もしくは失敗状態に基づいて、ＨＡＲＱフィードバック情報を生成すること、または、
送信リソースをプリエンプトする第２のサービス・データの送信の成功もしくは失敗状態を、送信成功と設定し、第１のサービス・データ送信におけるすべてのデータの送信の成功もしくは失敗状態に基づいてＨＡＲＱフィードバック情報を生成することを含む。
【０００９】
１つの実施形態において、指示情報が、明示的または暗示的に、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすることを指示するとき、指示情報に基づいて送信リソースをプリエンプトする第２のサービス・データをキャッシュに保存し、第１のサービス・データのＨＡＲＱフィードバック情報を生成することは、
送信に失敗したデータをすべてキャッシュに保存し、保存されたデータの中から、送信に失敗した第１のサービス・データを認識し、送信に失敗した第１のサービス・データに基づいてＨＡＲＱフィードバック情報を生成することを含む。
【００１０】
１つの実施形態において、指示情報が、後の第１のサービス・データ送信のスケジュール制御データにて運ばれる場合、基地局へＨＡＲＱフィードバック情報を送ることは、
非適応型ＨＡＲＱフィードバック・モードで、ＨＡＲＱフィードバック情報を、基地局へ送ることを含む。
【００１１】
１つの実施形態において、第１のサービス・データ送信のスケジュール制御データは、
スクランブル化方式で、指示情報をスケジュール制御データにおける標的制御情報にスクランブル化することにより、指示情報を運ぶ。
【００１２】
本開示の実施形態の第２の態様により、指示情報を送るための方法が提供され、その方法は、
第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトするか否かを判断することと、
第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトする場合は、ユーザ機器（ＵＥ）に対して第１のサービス・データ送信を送ることとを含み、ここで、第１のサービス・データ送信のスケジュール制御データは、指示情報を運び、その情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすること、を明示的または暗示的に、指示するように構成され、それにより、ＵＥが、指示情報に従って、送信リソースをプリエンプトする第２のサービス・データをキャッシュに保存し、第１のサービス・データのＨＡＲＱフィードバック情報を基地局へ送る。
【００１３】
１つの実施形態において、第１のサービス・データ送信をユーザ機器（ＵＥ）へ送ることは、
２つの第１のサービス・データ送信をＵＥに送ることを含み、２つの第１のサービス・データ送信の時間間隔は非適応型ＨＡＲＱフィードバック・モードにおける送信レイテンシよりも短く、
指示情報は、後の第１のサービス・データ送信のスケジュール制御データで運ばれ、その指示情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが、先の第１のサービス・データ送信における第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示する。
【００１４】
１つの実施形態において、指示情報が、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示する場合、この方法は、さらに、
ＵＥから第１のサービス・データのＨＡＲＱフィードバック情報を受信することであって、このＨＡＲＱフィードバック情報は、第２のサービス・データの送信リソース位置に対応する第２のサービス・データのＨＡＲＱフィードバック情報および別の送信リソース位置に対応する第１のサービス・データのＨＡＲＱフィードバック情報を含む、受信することと、
別の送信リソース位置に対応する第１のサービス・データのＨＡＲＱフィードバック情報に基づいて、ＵＥへの送信に失敗した第１のサービス・データを再送信することとを含む。
【００１５】
１つの実施形態において、第１のサービス・データ送信のスケジュール制御データは、
スクランブル化方式で、指示情報をスケジュール制御データにおける標的制御情報にスクランブル化することにより、指示情報を運ぶ。
【００１６】
本開示の実施形態の第３の態様により、ハイブリッド自動反復要求（ＨＡＲＱ）フィードバック装置が提供され、その装置は、
基地局から第１のサービス・データ送信を受信するように構成された受信モジュールであって、第１のサービス・データ送信のスケジュール制御データは、指示情報を運び、指示情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示するように構成される、受信モジュールと、
受信モジュールによって受信された第１のサービス・データ送信のスケジュール制御データにて運ばれた指示情報に従って、送信リソースをプリエンプトする第２のサービス・データをキャッシュに保存し、第１のサービス・データのＨＡＲＱフィードバック情報を生成するように構成された保存生成モジュールと、
保存生成モジュールによって生成されたＨＡＲＱフィードバック情報を基地局に送るように構成された送信モジュールとを含む。
【００１７】
１つの実施形態において、受信モジュールは、２つの第１のサービス・データ送信を受信するように構成されており、この２つの第１のサービス・データ送信の時間間隔は非適応型ＨＡＲＱフィードバック・モードにおける送信レイテンシより短く、
指示情報は、後の第１のサービス・データ送信のスケジュール制御データで運ばれ、その指示情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが先の第１のサービス・データ送信における第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示する。
【００１８】
１つの実施形態において、保存生成モジュールは、
送信リソースをプリエンプトする第２のサービス・データ以外のデータの送信成功もしくは失敗状態に基づいて、ＨＡＲＱフィードバック情報を生成するように構成された第１の生成サブモジュール、または、
送信リソースをプリエンプトする第２のサービス・データの送信成功もしくは失敗状態を、送信成功と設定し、第１のサービス・データ送信におけるすべてのデータの送信成功または失敗状態に基づいて、ＨＡＲＱフィードバック情報を生成するように構成された第２の生成サブモジュールを含む。
【００１９】
１つの実施形態において、指示情報が、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすることを、明示的または暗示的に指示するとき、保存生成モジュールは、
送信に失敗したすべてのデータをキャッシュに保存し、保存されたデータの中から、送信に失敗した第１のサービス・データを識別し、送信に失敗した第１のサービス・データに基づいて、ＨＡＲＱフィードバック情報を生成するように構成される。
【００２０】
１つの実施形態において、指示情報が、後の第１のサービス・データ送信のスケジュール制御データで運ばれる場合、送信モジュールは、非適応型ＨＡＲＱフィードバック・モードでＨＡＲＱフィードバック情報を基地局へ送るように構成される。
【００２１】
１つの実施形態において、指示情報は、スクランブル化方式で、スケジュール制御データにおける標的制御情報に、スクランブル化される。
【００２２】
本開示の実施形態の第４の態様により、指示情報を送るための装置が提供され、この装置は、
第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトするか否かを判断するように構成された判断モジュールと、
判断モジュールが、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすると判断したならば、第１のサービス・データ送信をユーザ機器（ＵＥ）へ送り、第１のサービス・データ送信のスケジュール制御データは指示情報を運び、その情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示するように構成され、それにより、ＵＥが、指示情報に従って、送信リソースをプリエンプトする第２のサービス・データをキャッシュに保存し、第１のサービス・データのＨＡＲＱフィードバック情報を基地局へ送る、ように構成される判定送信モジュールとを含む。
【００２３】
１つの実施形態において、判定送信モジュールは、
２つの第１のサービス・データ送信をＵＥへ送信するように構成され、２つの第１のサービス・データ送信の時間間隔は、非適応型ＨＡＲＱフィードバック・モードにおける送信レイテンシよりも短く、
指示情報は、後の第１のサービス・データ送信のスケジュール制御データで運ばれ、指示情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが先の第１のサービス・データ送信における第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示する。
【００２４】
１つの実施形態において、指示情報が、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示している場合、この装置は、さらに、
ＵＥから、第１のサービス・データのＨＡＲＱフィードバック情報を受信するように構成された受信モジュールであって、このＨＡＲＱフィードバック情報は、第２のサービス・データの送信リソース位置に対応する第２のサービス・データのＨＡＲＱフィードバック情報、および別の送信リソース位置に対応する第１のサービス・データのＨＡＲＱフィードバック情報を含む、受信モジュールと、
別の送信リソース位置に対応する第１のサービス・データのＨＡＲＱフィードバック情報に基づいて、ＵＥへの送信に失敗した第１のサービス・データを、再送信するように構成された再送信モジュールとを含む。
【００２５】
１つの実施形態において、指示情報は、スクランブル化方式で、スケジュール制御データにおける標的制御情報に、スクランブル化される。
【００２６】
本開示の実施形態の第５の態様により、ユーザ機器が提供され、このユーザ機器は、
プロセッサと、
プロセッサによって実行可能な命令を記憶するためのメモリとを含み、
プロセッサは、
基地局から、第１のサービス・データ送信を受信することであって、この第１のサービス・データ送信のスケジュール制御データは指示情報を運び、その指示情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示する、受信することと、
指示情報に基づいて、送信リソースをプリエンプトする第２のサービス・データをキャッシュに保存し、第１のサービス・データのＨＡＲＱフィードバック情報を生成することと、
ＨＡＲＱフィードバック情報を基地局へ送ることとを行うように構成される。
【００２７】
本開示の実施形態の第６の態様により、基地局が提供され、この基地局は、
プロセッサと、
プロセッサによって実行可能な命令を記憶するためのメモリとを含み、
プロセッサは、
第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトするか否かを判断することと、
第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトする場合は、第１のサービス・データ送信をユーザ機器（ＵＥ）へ送ることとを行うように構成され、第１のサービス・データ送信のスケジュール制御データは指示情報を運び、指示情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示し、それにより、ＵＥは、指示情報に基づいて、送信リソースをプリエンプトする第２のサービス・データをキャッシュに保存し、第１のサービス・データのＨＡＲＱフィードバック情報を基地局へ送る。
【００２８】
本開示の実施形態の第７の態様により、コンピュータ可読記憶媒体が提供され、この媒体は、コンピュータ・プログラムを記憶し、コンピュータ・プログラムは、プロセッサにより実行されると、上述のＨＡＲＱフィードバック方法のステップをプロセッサに行わせる。
【００２９】
本開示の実施形態の第８の態様により、コンピュータ可読記憶媒体が提供され、この媒体は、コンピュータ・プログラムを記憶し、コンピュータ・プログラムは、プロセッサにより実行されると、上述の指示情報を送るための方法のステップをプロセッサに行わせる。
【発明の効果】
【００３０】
本開示の実施形態による技術的解決法は、以下の利益のある効果を達成し得る。
【００３１】
第１のサービス・データ送信にて運ばれる指示情報を受信することにより、送信リソースをプリエンプトする第２のサービス・データがキャッシュにあり、それにより、有用な第２のサービス・データが第１のサービス・データ送信の間に破棄されなくてもよい。
【００３２】
指示情報は、後の第１のサービス・データ送信のスケジュール制御データから取得され、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすることが指示情報から認知され、それにより、ＵＥは第１のサービス・データ送信の間に有用な第２のサービス・データを破棄せずともよく、第１のサービス・データの送信成功または失敗状態が正確に基地局にフィードバックされ得る。このようにして、基地局は、実際には送信に失敗した第１のサービス・データを再送信することができる。
【００３３】
第１のサービス・データの送信成功または失敗状態が正確に反映され得、それにより、ＵＥの誤動作を防ぐことができる。
【００３４】
送信に失敗したデータはすべてキャッシュに保存され、保存されたデータの中から、送信に失敗した第１のサービス・データが識別され、送信に失敗した第１のサービス・データに基づいて、ＨＡＲＱフィードバック情報が生成され得、それにより、生成されたＨＡＲＱフィードバック情報が、第１のサービス・データの送信成功または失敗状態を正確に反映することができる。
【００３５】
指示情報が、後の第１のサービス・データ送信のスケジュール制御データにて運ばれると、非適応型ＨＡＲＱフィードバック・モードでＨＡＲＱフィードバック情報が基地局に送られ、それにより、ＵＥは、第１のサービス・データの送信成功または失敗状態を正確に基地局にフィードバックすることができる。
【００３６】
指示情報は、スクランブル化方式で、スケジュール制御データにおける標的制御情報にスクランブル化され、それにより、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることが、暗示的に指示される。その実施は簡単である。
【００３７】
第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすると判定されると、指示情報を運ぶ第１のサービス・データ送信がＵＥに送られて、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすることがＵＥに通知され、それにより、ＵＥの誤動作を防ぐことができる。
【００３８】
指示情報は、後の第１のサービス・データ送信のスケジュール制御データから運ばれ、それにより、ＵＥは、その指示情報から、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすることを認知し得る。したがって、ＵＥは、第１のサービス・データ送信の時に、有用な第２のサービス・データを破棄せずともよく、第１のサービス・データの送信成功または失敗状態を正確に基地局にフィードバックすることができる。このようにして、基地局は、実際には送信に失敗した第１のサービス・データを再送信することができる。
【００３９】
他の送信リソース位置に対応する第１のサービス・データの、受信したＨＡＲＱフィードバック情報に基づいて、ＵＥへの送信に失敗した第１のサービス・データを再送信することにより、基地局は、実際には再送信されるべき第１のサービス・データを識別することができる。
【００４０】
指示情報は、スクランブル化方式において、スケジュール制御データにおける標的制御情報にスクランブル化され、それにより、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることが、暗示的に示される。その実施は簡単である。
【００４１】
以上に述べた概略の説明と以下に述べる詳細な説明のいずれも、単なる例示および説明であって、本開示を制限するものではないことを理解されたい。
【図面の簡単な説明】
【００４２】
【図１】本開示の例示的実施形態による、ＨＡＲＱフィードバック方法のフローチャートである。
【００４３】
【図２】本開示の例示的実施形態による、指示情報を送るための方法のフローチャートである。
【００４４】
【図３】本開示の例示的実施形態による、ＨＡＲＱフィードバック方法のシグナリング・フローチャートである。
【００４５】
【図４】本開示の例示的実施形態による、指示情報が１つのｅＭＢＢ送信プロセスにおいて運ばれることを図示する概略図である。
【００４６】
【図５】本開示の例示的実施形態による、別のＨＡＲＱフィードバック方法のシグナリング・フローチャートである。
【００４７】
【図６】本開示の例示的実施形態による、指示情報が２つのｅＭＢＢ送信プロセスにおいて運ばれることを図示する概略図である。
【００４８】
【図７】本開示の例示的実施形態による、ＨＡＲＱフィードバック装置のブロック図である。
【００４９】
【図８】本開示の例示的実施形態による、別のＨＡＲＱフィードバック装置のブロック図である。
【００５０】
【図９】本開示の例示的実施形態による、指示情報を送るための装置のブロック図である。
【００５１】
【図１０】本開示の例示的実施形態による、指示情報を送るための別の装置のブロック図である。
【００５２】
【図１１】本開示の例示的実施形態による、ＨＡＲＱフィードバックにおいて使用される装置のブロック図である。
【００５３】
【図１２】本開示の例示的実施形態による、指示情報を送るために使用される装置のブロック図である。
【発明を実施するための形態】
【００５４】
本開示の実施形態における原理、技術的解決法、および利点を明確かつ完全に説明するために、添付の図面を用いて、本開示を、以下に、詳細に説明する。当然、記載された実施形態は、本開示の一部の実施形態にすぎず、そのすべてではない。本開示の実施形態に基づき、当業者が創造的努力を用いることなく導く、その他のすべての実施形態は、本開示の保護範囲内である。
【００５５】
図１は、本開示の例示的実施形態によるＨＡＲＱフィードバック方法のフローチャートである。この実施形態は、ＵＥ側から記述される。図１に示すように、ＨＡＲＱフィードバック方法は、以下のステップを含む。
【００５６】
ステップＳ１０１において、基地局からの第１のサービス・データ送信が受信され、ここで、第１のサービス・データ送信のスケジュール制御データは指示情報を運び、指示情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示する。
【００５７】
この実施形態において、第１のサービスは、第２のサービスと比較して、適時性に関して、より高い要件を課すので、第１のサービス・データが第１のサービス・データをプリエンプトすることがある。第１のサービスは、ｅＭＢＢを含んでもよいが、それに限定されず、第２のサービスは、ＵＲＬＬＣを含んでもよいが、それに限定されない。
【００５８】
ＵＥが基地局から１つの第１のサービス・データ送信を受信するとき、指示情報がこの１つの第１のサービス・データ送信のスケジュール制御データで運ばれてよく、指示情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示する。ＵＥが基地局から２つの第１のサービス・データ送信を受信すると、指示情報は、後の第１のサービス・データ送信のスケジュール制御データで運ばれてよく、ここで、指示情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトする、または、第２のサービス・データが先の第１のサービス・データ送信における第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示する。スケジュール制御データは、物理的ダウンリンク制御チャネル（ＰＤＣＣＨ）を含むことができるが、それに限定されるものではない。後者の場合、２つの第１のサービス・データ送信の時間間隔は非適応型ＨＡＲＱフィードバック・モードにおける送信レイテンシより短いこと、そうでないと、後の第１のサービス・データ送信のスケジュール制御データが到着する前に、ＨＡＲＱフィードバック情報が基地局に送られなければならないことに留意する必要がある。すなわち、ＵＥは、指示情報を受信する前に、ＨＡＲＱフィードバック情報を基地局に送らなければならない。
【００５９】
ステップＳ１０２において、送信リソースをプリエンプトする第２のサービス・データは、指示情報に従ってキャッシュに保存され、第１のサービス・データのＨＡＲＱフィードバック情報が生成される。
【００６０】
この実施形態において、送信リソースをプリエンプトする第２のサービス・データを送信するために、指示情報に従ってその第２のサービス・データをキャッシュに保管することができる。
【００６１】
ＨＡＲＱフィードバック情報は、複数のやり方で生成することができる。たとえば、ＨＡＲＱフィードバック情報は、送信リソースをプリエンプトする第２のサービス・データ以外のデータの送信成功または失敗状態に基づいて、生成され得る。さらに、たとえば、送信リソースをプリエンプトする第２のサービス・データの送信成功または失敗状態が、送信成功と設定されてよく、第１のサービス・データ送信のすべてのデータの送信成功または失敗状態に従って、ＨＡＲＱフィードバック情報が生成される。
【００６２】
生成されたＨＡＲＱフィードバック情報は、第１のサービス・データの送信成功または失敗状態を正確に反映し得、それにより、ＵＥの誤動作を防ぐことができる。
【００６３】
ステップＳ１０３において、ＨＡＲＱフィードバック情報が、基地局へ送られる。
【００６４】
この実施形態において、指示情報が、後の第１のサービス・データ送信のスケジュール制御データにて運ばれると、ＨＡＲＱフィードバック情報が、非適応型ＨＡＲＱフィードバック・モードで、基地局へ送られ得る。
【００６５】
上の実施形態において、第１のサービス・データ送信で運ばれる指示情報を受信することにより、送信リソースをプリエンプトする第２のサービス・データがキャッシュに保存され、それにより、第１のサービス・データ送信時に、有用な第２のサービス・データが破棄されなくてもよい。
【００６６】
図２は、本開示の例示的実施形態による、指示情報を送るための方法のフローチャートである。この実施形態は、基地局側から記述される。図２に示すように、この方法は、以下のステップを含む。
【００６７】
ステップＳ２０１において、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトするか否かが判断される。
【００６８】
第１のサービスはｅＭＢＢを含むことができるが、それに限定されず、第２のサービスはＵＲＬＬＣを含むことができるが、それに限定されない。第１のサービスは、第２のサービスと比較して、適時性に関して、より高い要件を課すので、第１のサービス・データが第１のサービス・データをプリエンプトすることがある。この実施形態では、基地局は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトするか否かを判断し得る。
【００６９】
ステップＳ２０２では、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトする場合、第１のサービス・データ送信がＵＥに送られ、ここで、第１のサービス・データ送信のスケジュール制御データが指示情報を運び、指示情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示し、それにより、ＵＥは、第１の指示情報に基づいて、第１のサービス・データのＨＡＲＱフィードバック情報を基地局へ送る。
【００７０】
この実施形態において、基地局が、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすると判定した場合、指示情報は、ＵＥに送られる第１のサービス・データ送信のスケジュール制御データにて運ばれ得る。指示情報は、明示の指示を与えるものとすることができ、たとえば、指示情報のいくつかのビットが直接追加されてもよいし、または、指示情報は、暗示の指示を与えてもよく、たとえば、スケジュール制御データにおける標的制御情報に指示情報がスクランブル化される、すなわち、対応する指示情報は、元の制御情報の一部にスクランブル化される。指示情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることを指示してよく、ここで、送信リソース位置はビットマップによって指示することができる。指示情報を受信すると、ＵＥは、指示情報に従って送信リソースをプリエンプトする第２のサービス・データをキャッシュに保存し、第１のサービス・データのＨＡＲＱフィードバック情報を基地局へ送る。
【００７１】
基地局によってＵＥへ第１のサービス・データ送信を送ることは、基地局によってＵＥへ１つの第１のサービス・データ送信を送ることを含むことができる。その場合、指示情報は、その１つの第１のサービス・データ送信のスケジュール制御データで運ばれてもよく、指示情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示する。
【００７２】
さらに、基地局によってＵＥへ第１のサービス・データ送信を送ることは、基地局によってＵＥへ２つの第１のサービス・データ送信を送ることをさらに含んでもよい。その場合、指示情報は、後の第１のサービス・データ送信のスケジュール制御データにて運ばれてもよく、指示情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが先の第１のサービス・データ送信における第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示する。
【００７３】
スケジュール制御データは、物理的ダウンリンク制御チャネル（ＰＤＣＣＨ）を含むことができるが、それに限定されるものではない。
【００７４】
後者の場合、２つの第１のサービス・データ送信の時間間隔は非適応型ＨＡＲＱフィードバック・モードにおける送信レイテンシより短いこと、そうでないと、後の第１のサービス・データ送信のスケジュール制御データが到着する前に、ＨＡＲＱフィードバック情報が基地局に送られなければならないことに留意する必要がある。すなわち、ＵＥは、指示情報を受信する前に、ＨＡＲＱフィードバック情報を基地局に送らなければならない、すなわち、ＵＥは、指示情報に基づいて誤動作を防ぐことができない。
【００７５】
上の実施形態において、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすると判定された場合、指示情報を運ぶ第１のサービス・データ送信が、ＵＥに送られて、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすることがＵＥに通知され、それにより、ＵＥの誤動作を防ぐことができる。
【００７６】
図３は、本開示の例示的実施形態によるＨＡＲＱフィードバック方法のシグナリング・フローチャートである。この実施形態は、ＵＥと基地局のインタラクションの視点から記述される。ＵＥと基地局のインタラクションをより明確に記述するために、この実施形態は、図４を参照して記述される。図４は、本開示の例示的実施形態により、指示情報が１つのｅＭＢＢ送信プロセスにおいて運ばれることを図示する概略図である。図４に示されるように、指示情報は、１つのｅＭＢＢデータ送信のＰＤＣＣＨにて運ばれる。図３に示されるように、ＨＡＲＱフィードバック方法は、以下のステップを含む。
【００７７】
ステップＳ３０１において、基地局が、ＵＲＬＬＣデータがｅＭＢＢデータの送信リソースをプリエンプトすると判定したとき、基地局は、１つのｅＭＢＢデータ送信をＵＥに送り、ここで、ｅＭＢＢデータ送信は指示情報を運ぶ。
【００７８】
指示情報は、ＵＲＬＬＣデータがｅＭＢＢデータの送信リソースをプリエンプトすること、または、ＵＲＬＬＣデータがｅＭＢＢデータの送信リソース位置をプリエンプトすることを、明示的に指示し得る。
【００７９】
ステップＳ３０２において、ＵＥは、基地局から、ｅＭＢＢデータ送信を受信し、ｅＭＢＢデータ送信のＰＤＣＣＨにて運ばれた指示情報に従って、送信リソースをプリエンプトするＵＲＬＬＣデータをキャッシュに保存し、ｅＭＢＢデータのＨＡＲＱフィードバック情報を生成する。
【００８０】
指示情報が、ＵＲＬＬＣデータがｅＭＢＢデータの送信リソースをプリエンプトすることを、明示的に指示する場合、ＵＥは、送信に失敗したすべてのデータをキャッシュに保存し、保存されたデータの中から、送信に失敗したｅＭＢＢデータを識別し、送信されないｅＭＢＢデータに基づいて、ＨＡＲＱフィードバック情報を生成する。
【００８１】
たとえば、ＵＥは、ＮＡＣＫフィードバックを有するすべての送信リソースに対応するデータをキャッシュに保存してよく、データを消去しなくてよい。ＵＲＬＬＣのすべてのデータが送信された後、保存されたデータ内の有用なＵＲＬＬＣデータが使用される。使用されたデータのほかにさらに一部のデータが残っている場合は、そのデータが実際には送信に失敗したデータであることを示し、ＵＥは、そのデータに基づいて、ＨＡＲＱフィードバック情報を計算することができる。
【００８２】
指示情報が、ＵＲＬＬＣデータがｅＭＢＢデータの送信リソース位置をプリエンプトすることを、明示的に指示するとき、ＵＥは、ＵＲＬＬＣデータを送信するために、送信リソースをプリエンプトするＵＲＬＬＣデータをキャッシュに保存してよく、ＮＡＣＫフィードバックを有する他のデータはすべて消去してよい。さらに、ＵＥは、送信リソースをプリエンプトするＵＲＬＬＣデータ以外のデータの送信成功または失敗状態に基づいてＨＡＲＱフィードバック情報を生成し得る。たとえば、ＵＥは、ＣＢＧ  ４以外のコード・ブロック・グループ（ＣＢＧ）のｅＭＢＢデータの送信成功または失敗状態に基づいて、ＨＡＲＱフィードバック情報を生成し得る。
【００８３】
ステップＳ３０３において、ＵＥはｅＭＢＢデータのＨＡＲＱフィードバック情報を基地局に送る。
【００８４】
ステップＳ３０４において、基地局は、受信したＨＡＲＱフィードバック情報に基づいて、送信に失敗したｅＭＢＢデータをＵＥに再送信する。
【００８５】
任意選択で、指示情報が、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることを指示するとき、基地局は、ＵＥから、第１のサービス・データのＨＡＲＱフィードバック情報を受信してよく、ここで、ＨＡＲＱフィードバック情報は、送信リソース位置に対応する第２のサービス・データのＨＡＲＱフィードバック情報、および、他の送信リソース位置に対応する第１のサービス・データのＨＡＲＱフィードバック情報を含み、そして、他の送信リソース位置に対応する第１のサービス・データのＨＡＲＱフィードバック情報に従って、ＵＥへの送信に失敗した第１のサービス・データを再送信する。すなわち、第１のサービス・データの再送信を決定すると、基地局は、送信リソース位置に対応する第２のサービス・データのＨＡＲＱフィードバック情報を無視し、他のリソース位置に対応する第１のサービス・データのＨＡＲＱフィードバック情報のみを考慮する。
【００８６】
たとえば、基地局は、図４に示すように、ＣＢＧ  ４以外のＣＢＧに対応するｅＭＢＢデータのＨＡＲＱフィードバック情報に従って、再送信するｅＭＢＢデータを決定し得る。
【００８７】
上の実施形態では、ＵＥと基地局のインタラクションに基づいて、ＵＥは、ＵＲＬＬＣデータがｅＭＢＢデータの送信リソースをプリエンプトすることを認知し得、それにより、ＵＥは、ｅＭＢＢデータ送信の間に有用なＵＲＬＬＣを破棄せずともよく、ｅＭＢＢデータの送信成功または失敗状態を、正確に、基地局にフィードバックし得る。このようにして、基地局は、実際には送信に失敗したｅＭＢＢデータを再送信し得る。
【００８８】
第２のサービス・データが第１のサービス・データをプリエンプトすることを判断する能力を有する基地局に関して、図３に示すようなプロセスに基づいて、ＨＡＲＱフィードバックが生成されてもよいことが留意されるべきである。ただし、そのような能力を持たない基地局に関しては、この判断は、後の第１のサービス・データ送信のＰＤＣＣＨにて運ばれる指示情報に基づいて実行され得る。指示情報は、第２のサービス・データが、第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが、先の第１のサービス・データ送信における第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示し得る。２つの第１のサービス・データ送信は、連続していても、連続していなくてもよい。
【００８９】
図５は、本開示の例示的実施形態による、別のＨＡＲＱフィードバック方法のシグナリング・フローチャートである。この実施形態は、ＵＥと基地局のインタラクションの視点から記述される。ＵＥと基地局のインタラクションをより明確に説明するために、この実施形態は、図６を参照して記述される。図６に示されるように、指示情報は、後のｅＭＢＢデータ送信のＰＤＣＣＨにて運ばれ、ここで、指示情報は、先のｅＭＢＢデータ送信におけるＵＲＬＬＣデータがｅＭＢＢデータの送信リソースをプリエンプトすること、または、ＵＲＬＬＣデータがｅＭＢＢデータの送信リソース位置をプリエンプトすることを、明示的に示し得る。図５に示されているように、ＨＡＲＱフィードバック方法は、以下のステップを含む。
【００９０】
ステップＳ５０１において、基地局は、２つのｅＭＢＢデータ送信をＵＥへ送り、ここで、２つの第１のサービス・データ送信の時間間隔は、非適応型ＨＡＲＱフィードバック・モードにおける送信レイテンシより短い。
【００９１】
指示情報は、後の第１のサービス・データ送信のスケジュール制御データにて運ばれる。
【００９２】
ステップＳ５０２において、先のｅＭＢＢデータ送信を受信すると、ＵＥは、後のｅＭＢＢデータ送信のＰＤＣＣＨを読んで、指示情報を得る。
【００９３】
ステップＳ５０３において、送信リソースをプリエンプトするＵＲＬＬＣデータは、得られた指示情報に従ってキャッシュに保存され、ｅＭＢＢデータのＨＡＲＱフィードバック情報が生成される。
【００９４】
ステップＳ５０３においてＨＡＲＱフィードバック情報を生成するプロセスは、ステップＳ３０２においてＨＡＲＱフィードバック情報を生成するプロセスと同じであり、本明細書ではこれ以上記述しない。
【００９５】
ステップＳ５０４において、ＵＥは、ｅＭＢＢデータのＨＡＲＱフィードバック情報を、非適応型ＨＡＲＱフィードバック・モードで、基地局へ送る。
【００９６】
ステップＳ５０５において、基地局は、受信したＨＡＲＱフィードバック情報に基づいて、ＵＥへの送信に失敗したｅＭＢＢデータを再送信する。
【００９７】
上の実施形態において、ＵＥは、ＵＥと基地局のインタラクションに基づいて、後の第１のサービス・データ送信のスケジュール制御データから指示情報を取得して、ＵＲＬＬＣデータがｅＭＢＢデータの送信リソースをプリエンプトすることを認知することができ、その結果、ＵＥは、ｅＭＢＢデータ送信の間に有用なＵＲＬＬＣデータを破棄せずともよく、ｅＭＢＢデータの送信成功または失敗状態を、正確に、基地局にフィードバックし得る。このようにして、基地局は、実際には送信に失敗したｅＭＢＢデータを再送信し得る。
【００９８】
図７は、本開示の例示的実施形態によるＨＡＲＱフィードバック装置のブロック図である。ＨＡＲＱフィードバック装置は、ＵＥに配置され、受信モジュール７１、保存モジュール７２、および送信モジュール７３を含む。
【００９９】
受信モジュール７１は、第１のサービス・データ送信を基地局から受信するように構成され、第１のサービス・データ送信のスケジュール制御データが指示情報を運び、ここで、指示情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示する。
【０１００】
この実施形態において、第１のサービスは、第２のサービスに比べて、より高い適時性の要件を課すので、第１のサービス・データが第１のサービス・データをプリエンプトすることがあり得る。第１のサービスはｅＭＢＢを含むことができるが、それに限定されず、第２のサービスはＵＲＬＬＣを含むことができるが、それに限定されない。
【０１０１】
ＵＥが１つの第１のサービス・データ送信を基地局から受信する場合、指示情報は、その１つの第１のサービス・データ送信のスケジュール制御データにて運ばれてもよく、ここで、指示情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示する。ＵＥが、２つの第１のサービス・データ送信を基地局から受信する場合、指示情報は、後の第１のサービス・データ送信のスケジュール制御データで運ばれてもよく、ここで、指示情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示する。このスケジュール制御データは、ＰＤＣＣＨを含むことができるが、それに限定されない。後者の場合には、２つの第１のサービス・データ送信の間の時間間隔は非適応型ＨＡＲＱフィードバック・モードの送信レイテンシよりも短く、そうでないと、後の第１のサービス・データ送信のスケジュール制御データが到着する前に、ＨＡＲＱフィードバック情報が基地局に送られなければならないことに留意する必要がある。すなわち、ＵＥは、指示情報を受信する前に、ＨＡＲＱフィードバック情報を基地局に送らなければならない。
【０１０２】
保存生成モジュール７２は、受信モジュール７１によって受信される、第１のサービス・データ送信のスケジュール制御データにて運ばれる指示情報に従って、送信リソースをプリエンプトする第２のサービス・データをキャッシュに保存し、第１のサービス・データのＨＡＲＱフィードバック情報を生成するように構成される。
【０１０３】
１つの実施形態において、指示情報が、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすることを、明示的または暗示的に、指示するとき、保存生成モジュール７２は、送信に失敗したすべてのデータをキャッシュに保存し、保存されたデータの中から、送信に失敗した第１のサービス・データを識別し、送信に失敗した第１のサービス・データに基づいて、ＨＡＲＱフィードバック情報を生成するように構成され得る。
【０１０４】
送信モジュール７３は、保存生成モジュールによって生成されたＨＡＲＱフィードバック情報を基地局へ送るように構成される。
【０１０５】
指示情報が、後の第１のサービス・データ送信のスケジュール制御データにて運ばれる場合、送信モジュール７３は、非適応型ＨＡＲＱフィードバック・モードで、ＨＡＲＱフィードバック情報を、基地局へ送るように構成されてもよい。
【０１０６】
上の実施形態において、第１のサービス・データ送信で運ばれる指示情報を受信することにより、第２のサービス・データがキャッシュ中に送信リソースをプリエンプトし、その結果、有用な第２のサービス・データが第１のサービス・データ送信の時に破棄されなくてもよい。
【０１０７】
図８は、本開示の例示的実施形態による、別のＨＡＲＱフィードバック装置のブロック図である。図８に示されるように、図７に図示した実施形態に基づいて、保管生成モジュール７２は、第１の生成サブモジュール７２１または第２の生成サブモジュール７２２を含んでもよい。
【０１０８】
第１の生成サブモジュール７２１は、送信リソースをプリエンプトする第２のサービス・データ以外のデータの送信成功または失敗状態に基づいて、ＨＡＲＱフィードバック情報を生成するように構成される。
【０１０９】
第２の生成サブモジュール７２２は、送信リソースをプリエンプトする第２のサービス・データの送信成功または失敗状態を、送信成功と設定し、第１のサービス・データ送信におけるすべてのデータの送信成功または失敗状態のＨＡＲＱフィードバック情報を生成するように構成される。
【０１１０】
このＨＡＲＱフィードバック情報は、複数のやり方で生成されてもよい。たとえば、ＨＡＲＱフィードバック情報は、送信リソースをプリエンプトする第２のサービス・データ以外のデータの送信成功または失敗状態に基づいて生成されてもよい。さらに、たとえば、送信リソースをプリエンプトする第２のサービス・データの送信成功または失敗状態が、送信成功と設定されてもよく、第１のサービス・データ送信におけるすべてのデータの送信成功または失敗状態に従って、ＨＡＲＱフィードバック情報が生成される。
【０１１１】
上の実施形態において、第１の生成サブモジュールまたは第２の生成サブモジュールによって生成されたＨＡＲＱフィードバック情報は、第１のサービス・データの送信成功または失敗状態を正確に反映することができ、その結果、ＵＥの誤動作を防ぐことができる。
【０１１２】
図９は、本開示の例示的実施形態による、指示情報を送るための装置のブロック図である。この装置は、基地局に配置され、判断モジュール９１と判定送信モジュール９２を含む。
【０１１３】
判断モジュール９１は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトするか否かを判断するように構成される。
【０１１４】
第１のサービスはｅＭＢＢを含むことができるが、それに限定されず、第２のサービスはＵＲＬＬＣを含むことができるが、それに限定されない。第１のサービスは、第２のサービスに比べて、適時性に関して高い要件を課すので、第１のサービス・データが第１のサービス・データをプリエンプトすることがあり得る。この実施形態において、基地局は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトするか否かを判定してもよい。
【０１１５】
判定送信モジュール９２は、判断モジュール９１が第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすると判断した場合、第１のサービス・データ送信をユーザ機器（ＵＥ）へ送り、ここで、第１のサービス・データ送信のスケジュール制御データは指示情報を運び、指示情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示し、その結果、ＵＥは、指示情報に従って、送信リソースをプリエンプトする第２のサービス・データをキャッシュに保存し、第１のサービス・データのＨＡＲＱフィードバック情報を基地局へ送る、ように構成される。
【０１１６】
この実施形態において、基地局が、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすると判定した場合、指示情報は、ＵＥへ送られる第１のサービス・データ送信のスケジュール制御データにて運ばれてもよい。指示情報は、明示の指示を与えるものとすることができ、たとえば、指示情報にいくつかのビットが直接付加されてもよく、または、指示情報は、暗示の指示を与えるものとすることができ、たとえば、指示情報が、スケジュール制御データにおける標的制御情報にスクランブル化される、すなわち、対応する指示情報が、元の制御情報の一部にスクランブル化される。指示情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることを指示するために用いられてもよく、ここで、送信リソース位置は、ビットマップによって指示されてもよい。ＵＥは、指示情報を受信すると、その指示情報に従って、送信リソースをプリエンプトする第２のサービス・データをキャッシュに保存して、第１のサービス・データのＨＡＲＱフィードバック情報を基地局へ送ってもよい。
【０１１７】
基地局によってＵＥへ第１のサービス・データ送信を送ることは、基地局によってＵＥへ１つの第１のサービス・データ送信を送ることを含んでもよい。その場合、指示情報は、その１つの第１のサービス・データ送信のスケジュール制御データで運ばれてもよく、指示情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示する。
【０１１８】
１つの実施形態において、判定送信モジュール９２は、２つの第１のサービス・データ送信をＵＥへ送るように構成され、ここで、２つの第１のサービス・データ送信の間の時間間隔は、非適応型ＨＡＲＱフィードバック・モードの送信レイテンシよりも短い。指示情報は、後の第１のサービス・データ送信のスケジュール制御データで運ばれ、指示情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが先の第１のサービス・データ送信における第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示する。
【０１１９】
上の実施形態において、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすると判定されると、指示情報を運ぶ第１のサービス・データ送信がＵＥに送られて、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすることがＵＥに通知され、それにより、ＵＥの誤動作を防ぐことができる。
【０１２０】
図１０は、本開示の例示的実施形態による、指示情報を送るための別の装置のブロック図である。図１０に示されるように、図９に図示された実施形態に基づいて、指示情報が、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示しているときは、装置は、受信モジュール９３と再送信モジュール９４を、さらに含んでもよい。
【０１２１】
受信モジュール９３は、ＵＥから第１のサービス・データのＨＡＲＱフィードバック情報を受信するように構成され、ここで、ＨＡＲＱフィードバック情報は、第２のサービス・データの送信リソース位置に対応する第２のサービス・データのＨＡＲＱフィードバック情報と、別の送信リソース位置に対応する第１のサービス・データのＨＡＲＱフィードバック情報を含む。
【０１２２】
再送信モジュール９４は、別の送信リソース位置に対応する第１のサービス・データのＨＡＲＱフィードバック情報に従って、ＵＥへの送信に失敗した第１のサービス・データを再送信するように構成される。
【０１２３】
指示情報が、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることを指示するとき、基地局は、ＵＥから第１のサービス・データのＨＡＲＱフィードバック情報を受信してもよく、ここで、ＨＡＲＱフィードバック情報は、送信リソース位置に対応する第２のサービス・データのＨＡＲＱフィードバック情報と、他の送信リソース位置に対応する第１のサービス・データのＨＡＲＱフィードバック情報を含み、他の送信リソース位置に対応する第１のサービス・データのＨＡＲＱフィードバック情報に従って、送信に失敗した第１のサービス・データをＵＥへ再送信する。すなわち、第１のサービス・データを再送信すると決定した場合、基地局は、送信リソース位置に対応する第２のサービス・データのＨＡＲＱフィードバック情報を無視し、他のリソース位置に対応する第１のサービス・データのＨＡＲＱフィードバック情報のみを考慮する。
【０１２４】
上の実施形態において、他の送信リソース位置に対応する、第１のサービス・データの受信したＨＡＲＱフィードバック情報に基づいて、送信に失敗した第１のサービス・データを、ＵＥへ再送信することにより、基地局は、実際に再送信されるべき第１のサービス・データを識別してもよい。
【０１２５】
図１１は、例示的実施形態によるＨＡＲＱフィードバックにおいて使用される装置のブロック図である。たとえば、装置１１００は、携帯電話、コンピュータ、デジタル・ブロードキャスト端末、メッセージング・デバイス、ゲーム・コンソール、タブレット・デバイス、医療用デバイス、フィットネス機器、携帯情報端末などとすることができる。
【０１２６】
図１１を参照すると、装置１１００は、処理コンポーネント１１０２、メモリ１１０４、電力コンポーネント１１０６、マルチメディア・コンポーネント１１０８、音声コンポーネント１１１０、入出力（Ｉ／Ｏ）インタフェース１１１２、センサ・コンポーネント１１１４、および通信コンポーネント１１１６のうちの、１つ以上のコンポーネントを含むことができる。
【０１２７】
処理コンポーネント１１０２は、一般的には、表示、電話通話、データ通信、カメラ動作、記録動作に関連する動作など、装置１１００の動作全体を制御する。処理コンポーネント１１０２は、上述の方法のステップの全部または一部を行う命令を実行する１つまたは複数のプロセッサ１１２０を含んでもよい。さらに、処理コンポーネント１１０２は、処理コンポーネント１１０２と他のコンポーネントの間のインタラクションを容易にする１つまたは複数のモジュールを含んでもよい。たとえば、処理コンポーネント１１０２は、マルチメディア・コンポーネント１１０８と処理コンポーネント１１０２の間のインタラクションを容易にするマルチメディア・モジュールを含んでもよい。
【０１２８】
メモリ１１０４は、装置１１００の動作をサポートするために各種データを記憶するように構成される。そのようなデータの例として、装置１１００上で動作するアプリケーションまたは方法のための命令、連絡先データ、電話帳データ、メッセージ、画像、動画等がある。メモリ１１０４は、静的ランダム・アクセス・メモリ（ＳＲＡＭ）、電気的消去可能プログラマブル・リードオンリ・メモリ（ＥＥＰＲＯＭ）、消去可能プログラマブル・リードオンリ・メモリ（ＥＰＲＯＭ）、プログラマブル・リードオンリ・メモリ（ＰＲＯＭ）、リードオンリ・メモリ（ＲＯＭ）、磁気メモリ、フラッシュ・メモリ、磁気または光学ディスクなど、任意の種類の揮発性もしくは非揮発性のメモリデバイス、またはそれらの組み合わせを用いて実施してもよい。
【０１２９】
電力コンポーネント１１０６は、装置１１００の各種コンポーネントに電力を提供する。電力コンポーネント１１０６は、装置１１００における電力管理システム、１つまたは複数の電源、ならびに発電、電力管理、および配電に関連するその他のコンポーネントを含むことができる。
【０１３０】
マルチメディア・コンポーネント１１０８は装置１１００とユーザの間の出力インタフェースを提供する画面を含む。いくつかの実施形態では、この画面は、液晶ディスプレイ（ＬＣＤ）とタッチ・パネル（ＴＰ）を含んでもよい。画面がタッチ・パネルを含む場合、画面は、ユーザから入力信号を受信するタッチ・スクリーンとして実装されてもよい。このタッチ・パネルは、タッチ・パネルに対するタッチ、スワイプ、およびジェスチャを感知する１つまたは複数のタッチ・センサを含む。タッチ・センサは、タッチまたはスワイプ動作の境界を感知するのみならず、タッチまたはスワイプ動作に関わる時間および圧力をも感知するものとすることができる。いくつかの実施形態では、マルチメディア・コンポーネント１１０８は、前部カメラおよび／または後部カメラを含む。前部カメラおよび後部カメラは、装置１１００が、撮影モードまたはビデオ・モードなどの、動作モードにある間、外部のマルチメディア・データを受信するものであってもよい。前部カメラと後部カメラは、各々、固定光学レンズ・システムであるか、または、焦点光学ズーム機能を有するものであってもよい。
【０１３１】
音声コンポーネント１１１０は、音声信号を、出力および／または入力するように構成される。たとえば、音声コンポーネント１１１０は、装置１１００が、通話モード、記録モード、およびボイス認識モードなどの動作モードにあるとき、外部の音声信号を受信するように構成されたマイクロホン（ＭＩＣ）を含む。受信された音声信号は、さらに、メモリ１１０４に格納されるか、または通信コンポーネント１１１６を介して送信されてもよい。いくつかの実施形態では、音声コンポーネント１１１０は、さらに、音声信号を出力するためのスピーカーを含む。
【０１３２】
Ｉ／Ｏインタフェース１１１２は、処理コンポーネント１１０２と、キーボード、クリック・ホイール、ボタンなどの周辺インタフェース・モジュールの間のインタフェースを提供する。ボタンは、ホーム・ボタン、ボリューム・ボタン、スタート・ボタン、およびロック・ボタンを含んでもよいが、それらに限定されない。
【０１３３】
センサ・コンポーネント１１１４は、装置１１００の様々な面のステータス評価を提供する１つまたは複数のセンサを含む。たとえば、センサ・コンポーネント１１１４は、装置１１００のオン／オフ・ステータス、装置１１００のコンポーネント同士、たとえば、ディスプレイ・デバイスとミニ・キーボード、の相対的位置を検知してもよく、また、センサ・コンポーネント１１１４は、装置１１００または装置１１００のコンポーネントの位置変化、ユーザと装置１１００の接触の有無、装置１１００の方向または加速／減速、および装置１１００の温度変化を検出してもよい。センサ・コンポーネント１１１４は、物理的接触なしに付近の物体の存在を検知するように構成された近接センサを含んでもよい。センサ・コンポーネント１１１４は、撮像アプリケーションに用いられる、ＣＭＯＳまたはＣＣＤイメージセンサなどの、光センサを含んでもよい。いくつかの実施形態では、センサ・コンポーネント１１１４はまた、加速度計センサ、ジャイロスコープ・センサ、磁気センサ、圧力センサ、または温度センサを含んでもよい。
【０１３４】
通信コンポーネント１１１６は、装置１１００と他のデバイスの間の有線または無線の通信を容易にするように構成される。装置１１００は、ＷｉＦｉ、２Ｇ、もしくは３Ｇ、またはそれらの組み合わせなどの通信標準に基づく無線ネットワークにアクセスすることができる。例示的実施形態において、通信コンポーネント６１６は、ブロードキャスト・チャネルを介して、外部のブロードキャスト管理システムから、ブロードキャスト信号またはブロードキャスト関連情報を受信する。例示的実施形態において、通信コンポーネント１１１６は、さらに、短距離通信を容易にする近距離無線通信（ＮＦＣ）モジュールを含む。
【０１３５】
例示的実施形態において、装置１１００は、１つまたは複数の特定用途向け集積回路（ＡＳＩＣ）、デジタル信号プロセッサ（ＤＳＰ）、デジタル信号処理デバイス（ＤＳＰＤ）、プログラマブル論理デバイス（ＰＬＤ）、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、コントローラ、マイクロコントローラ、マイクロプロセッサ、または、上述の方法を実行するためのその他の電子コンポーネントを用いて実装されてもよい。たとえば、ＮＦＣモジュールは、無線周波数識別（ＲＦＩＤ）テクノロジー、赤外線データ協会（ＩｒＤＡ）テクノロジー、超広帯域（ＵＷＢ）テクノロジー、ブルートゥース（登録商標）（ＢＴ）テクノロジー、およびその他のテクノロジーに基づいて実装されてもよい。
【０１３６】
例示的実施形態において、上述の方法を実行するために、装置１１００内のプロセッサ１１２０によって実行可能な命令を含む、メモリ１１０４など、命令を含む非一時的コンピュータ可読記憶媒体も提供される。たとえば、非一時的コンピュータ可読記憶媒体は、ＲＯＭ、ＲＡＭ、ＣＤ−ＲＯＭ、磁気テープ、フロッピー・ディスク、光学データ記憶デバイスなどとすることができる。
【０１３７】
図１２は、本開示の例示的実施形態による、指示情報を送るために使用される装置１２００のブロック図である。装置１２００は、基地局として提供されてもよい。図１２を参照すると、装置１２００は、処理コンポーネント１２２２、無線送信／受信コンポーネント１２２４、無線アンテナ１２２６、および無線インタフェース専用の信号処理部を含む。処理コンポーネント１２２２は、さらに、１つまたは複数のプロセッサを含んでもよい。
【０１３８】
処理コンポーネント１２２２内の１つのプロセッサは、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトするか否かを判断し、
【０１３９】
第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトする場合、第１のサービス・データ送信をＵＥへ送るように構成されてもよく、第１のサービス・データ送信のスケジュール制御データは指示情報を運び、その指示情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示し、それにより、ＵＥは、指示情報に従って、送信リソースをプリエンプトする第２のサービス・データをキャッシュに保存し、第１のサービス・データのＨＡＲＱフィードバック情報を基地局へ送る。
【０１４０】
装置の実施形態は、方法の実施形態に実質的に対応するので、装置の実施形態の説明は簡単になされており、関連部分は、方法の実施形態の説明部分を参照して得られ得る。上述の装置の実施形態は、単に、例示のみを目的とするものである。別個のコンポーネントとして記述されているユニットは、物理的に分離されていても、物理的に分離されていなくてもよく、ユニットとして示されているコンポーネントは、物理的なユニットであっても、そうでなくてもよい、すなわち、コンポーネントは、同じ位置に配置されてもよく、複数のネットワーク・ユニットに分散されていてもよい。モジュールの一部または全部が、実施形態の技術的解決法の目的を達成するために、実際のニーズに従って選択されてもよい。当業者は、創造的努力を要せずに、本開示を理解し、実施できる。
【０１４１】
本明細書において、「第１の」および「第２の」のような関係性を表す用語は、あるエンティティまたは動作を別のエンティティまたは動作と区別するためにのみ用いられ、それらのエンティティまたは動作の間に実際上の関係または順序があることを要求する、または意味する意図はないことに留意されたい。本明細書において、「備える」、「備えている」、「有する」、「有している」、「含む」、「含んでいる」、「内包する」、「内包している」、またはそれらの変形は、非排他的包含を意味することが意図されており、したがって、要素のリストを備える、有する、含む、包含するプロセス、方法、物品、またはデバイスは、それらの要素のみを含むのではなく、そのプロセス、方法、物品、またはデバイスに明示的に列挙されていないかまたは固有ではない、その他の要素を含んでもよいことに留意されたい。「〜を備える」、「〜を有する」、「〜を含む」、「〜を内包する」という語句が後に続く要素は、さらに制約がなければ、当該プロセス、方法、物品、または装置に、同じ要素が追加されて存在することを妨げるものではない。
【０１４２】
本開示による方法および装置は、以上に詳細に説明され、本開示の原理および実施形態は、具体的な実施形態および例を参照して説明されているが、上述の実施形態は、本開示の方法および中核的思想の理解を助けるためにのみ記述されたものである。当業者は、本開示の概念に従って、具体的な実施形態または適用の範囲に修正または変形を加えることができる。結論として、本明細書は、本開示を限定するものと理解されてはならない。
【図１】
2020523877.tif 000003
【図２】
2020523877.tif 000004
【図３】
2020523877.tif 000005
【図４】
2020523877.tif 000006
【図５】
2020523877.tif 000007
【図６】
2020523877.tif 000008
【図７】
2020523877.tif 000009
【図８】
2020523877.tif 000010
【図９】
2020523877.tif 000011
【図１０】
2020523877.tif 000012
【図１１】
2020523877.tif 000013
【図１２】
2020523877.tif 000014
【手続補正書】
【提出日】令和2年1月15日(2020.1.15)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
（関連出願への相互参照）
この出願は、２０１７年６月１６日に出願された国際出願番号ＰＣＴ／ＣＮ２０１７／０８８７０５の継続出願であり、その全内容は参照により本明細書に組み込まれます。
本開示は、通信テクノロジーの分野に関するものであり、特に、ハイブリッド自動反復要求（ＨＡＲＱ）フィードバック方法および装置、指示情報を送るための方法、ならびに、そのユーザ機器（ＵＥ）および基地局に関する。
【背景技術】
【０００２】
通信テクノロジーの発展とともに、第５世代モバイル通信テクノロジー（５Ｇ）が、開発されてきた。５Ｇにおけるサービスの種類は、少なくとも、高速モバイル・ブロード・バンド（ｅＭＢＢ）、大数量機械タイプ通信（ｍＭＴＣ）、超高信頼度低レイテンシ通信（ＵＲＬＬＣ）などを含む。これらのサービス種類は、すべて、データ・サービスに関するものであるが、レイテンシおよび信頼度に関して課す要件は異なる。たとえば、ＵＲＬＬＣサービスは、低レイテンシが要求される車両のインターネットなどの分野に適用される。このサービスは、適時性について、より厳格な要件を課し、適時のサービス確立を要求するか、またはさらには元のサービスをプリエンプト(preempt)する。ｍＭＴＣサービスは、レイテンシに敏感ではなく、このサービスでは、データは、時間間隔をさらに空けて送信されてもよい。レイテンシに敏感なサービスの有効な送信を実現する１つの方法は、ハイブリッド自動反復要求（ＨＡＲＱ）の送信を改良して、たとえば、再送信フィードバックを、より迅速、より正確にすることである。
【０００３】
ロング・ターム・エボリューション（ＬＴＥ）では、ＨＡＲＱフィードバックは、送信ブロック（ＴＢ）を単位として用いて実行され、各ＴＢは、１ビットの肯定応答（ＡＣＫ）または否定応答（ＮＡＣＫ）メッセージをフィードバックする。再送信の正確性を向上させるため、第３世代パートナーシップ・プロジェクト（３ＧＰＰ）は、コード・ブロック・グループ（ＣＢＧ）に基づく再送信を提案している。ＣＢＧは、ＴＢにおける、さらにより小さなデータ単位である。１個のＣＢＧは、１ビットのＡＣＫまたはＮＡＣＫのフィードバックに対応する。再送信の粒度がさらに細かくなるので、不正確な送信の位置が、より精密に反映され得ることになり、再送信がより正確となる。さらに、再送信に要するデータ量がなおいっそう少なくなるので、再送信効率が向上する。
【０００４】
しかし、たとえば、ｅＭＢＢサービスが送信中であるかまたは送信予定であり、かつＵＲＬＬＣサービスが起動中であるときのサービス・プリエンプションの場合、ＵＲＬＬＣサービスは、ｅＭＢＢサービスの送信時間−周波数リソースをプリエンプトすることができる。その結果、元のｅＭＢＢサービスは、ＨＡＲＱフィードバック・プロセスにおいて、ｅＭＢＢデータが不正確に送信されるものと誤認し、その結果、有用なＵＲＬＬＣデータが破棄されることがあり得る。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
以上に基づき、本開示は、有用なサービス・データを破棄しないような、指示情報を送るための方法、ならびにそのユーザ機器（ＵＥ）および基地局を提供する。
【課題を解決するための手段】
【０００６】
本開示の実施形態の第１の態様により、ハイブリッド自動反復要求（ＨＡＲＱ）フィードバック方法が提供され、この方法は、
基地局から第１のサービス・データ送信を受信することであって、第１のサービス・データ送信のスケジュール制御データは指示情報を運び、それは、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプト(preempt)すること、または第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に示すように構成されている、受信することと、
指示情報に従って送信リソースをプリエンプトする第２のサービス・データをキャッシュに保存し、第１のサービス・データのＨＡＲＱフィードバック情報を生成することと、
そのＨＡＲＱフィードバック情報を基地局に送信することと、を含む。
【０００７】
１つの実施形態において、基地局から第１のサービス・データを受信することは、
基地局から２つの第１のサービス・データ送信を受信することを含み、その２つの第１のサービス・データ送信の時間間隔は非適応型ＨＡＲＱフィードバック・モードにおける送信レイテンシよりも短く、
後の第１のサービス・データ送信のスケジュール制御データにて指示情報が運ばれ、その指示情報は、第２のサービス・データが、第１のサービス・データの送信リソースをプリエンプトすること、または第２のサービス・データが、先の第１のサービス・データ送信における第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に指示する。
【０００８】
１つの実施形態において、第１のサービス・データのＨＡＲＱフィードバック情報を生成することは、
送信リソースをプリエンプトする第２のサービス・データ以外のデータの送信の成功もしくは失敗状態に基づいて、ＨＡＲＱフィードバック情報を生成すること、または、
送信リソースをプリエンプトする第２のサービス・データの送信の成功もしくは失敗状態を、送信成功と設定し、第１のサービス・データ送信におけるすべてのデータの送信の成功もしくは失敗状態に基づいてＨＡＲＱフィードバック情報を生成することを含む。
【０００９】
１つの実施形態において、指示情報が、明示的または暗示的に、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすることを指示するとき、指示情報に基づいて送信リソースをプリエンプトする第２のサービス・データをキャッシュに保存し、第１のサービス・データのＨＡＲＱフィードバック情報を生成することは、
送信に失敗したデータをすべてキャッシュに保存し、保存されたデータの中から、送信に失敗した第１のサービス・データを認識し、送信に失敗した第１のサービス・データに基づいてＨＡＲＱフィードバック情報を生成することを含む。
【００１０】
１つの実施形態において、指示情報が、後の第１のサービス・データ送信のスケジュール制御データにて運ばれる場合、基地局へＨＡＲＱフィードバック情報を送ることは、
非適応型ＨＡＲＱフィードバック・モードで、ＨＡＲＱフィードバック情報を、基地局へ送ることを含む。
【００１１】
１つの実施形態において、第１のサービス・データ送信のスケジュール制御データは、
スクランブル化方式で、指示情報をスケジュール制御データにおける標的制御情報にスクランブル化することにより、指示情報を運ぶ。
【００１２】
本開示の実施形態の第２の態様により、指示情報を送るための方法が提供され、その方法は、
第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトするか否かを判断することと、
第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトする場合は、ユーザ機器（ＵＥ）に対して第１のサービス・データ送信を送ることとを含み、ここで、第１のサービス・データ送信のスケジュール制御データは、指示情報を運び、その情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすること、を明示的または暗示的に、指示するように構成され、それにより、ＵＥが、指示情報に従って、送信リソースをプリエンプトする第２のサービス・データをキャッシュに保存し、第１のサービス・データのＨＡＲＱフィードバック情報を基地局へ送る。
【００１３】
１つの実施形態において、第１のサービス・データ送信をユーザ機器（ＵＥ）へ送ることは、
２つの第１のサービス・データ送信をＵＥに送ることを含み、２つの第１のサービス・データ送信の時間間隔は非適応型ＨＡＲＱフィードバック・モードにおける送信レイテンシよりも短く、
指示情報は、後の第１のサービス・データ送信のスケジュール制御データで運ばれ、その指示情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが、先の第１のサービス・データ送信における第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示する。
【００１４】
１つの実施形態において、指示情報が、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示する場合、この方法は、さらに、
ＵＥから第１のサービス・データのＨＡＲＱフィードバック情報を受信することであって、このＨＡＲＱフィードバック情報は、第２のサービス・データの送信リソース位置に対応する第２のサービス・データのＨＡＲＱフィードバック情報および別の送信リソース位置に対応する第１のサービス・データのＨＡＲＱフィードバック情報を含む、受信することと、
別の送信リソース位置に対応する第１のサービス・データのＨＡＲＱフィードバック情報に基づいて、ＵＥへの送信に失敗した第１のサービス・データを再送信することとを含む。
【００１５】
１つの実施形態において、第１のサービス・データ送信のスケジュール制御データは、
スクランブル化方式で、指示情報をスケジュール制御データにおける標的制御情報にスクランブル化することにより、指示情報を運ぶ。
【００１６】
本開示の実施形態の第３の態様により、ユーザ機器が提供され、このユーザ機器は、
プロセッサと、
プロセッサによって実行可能な命令を記憶するためのメモリとを含み、
プロセッサは、上記第１の実施形態によるＨＡＲＱフィードバック方法を実行する。
【００１７】
本開示の実施形態の第４の態様により、基地局が提供され、この基地局は、
プロセッサと、
プロセッサによって実行可能な命令を記憶するためのメモリとを含み、
プロセッサは、上記第２の実施形態による指示情報を送るための方法を実行する。
【００１８】
以上に述べた概略の説明と以下に述べる詳細な説明のいずれも、単なる例示および説明であって、本開示を制限するものではないことを理解されたい。
【図面の簡単な説明】
【００１９】
【図１】本開示の例示的実施形態による、ＨＡＲＱフィードバック方法のフローチャートである。
【００２０】
【図２】本開示の例示的実施形態による、指示情報を送るための方法のフローチャートである。
【００２１】
【図３】本開示の例示的実施形態による、ＨＡＲＱフィードバック方法のシグナリング・フローチャートである。
【００２２】
【図４】本開示の例示的実施形態による、指示情報が１つのｅＭＢＢ送信プロセスにおいて運ばれることを図示する概略図である。
【００２３】
【図５】本開示の例示的実施形態による、別のＨＡＲＱフィードバック方法のシグナリング・フローチャートである。
【００２４】
【図６】本開示の例示的実施形態による、指示情報が２つのｅＭＢＢ送信プロセスにおいて運ばれることを図示する概略図である。
【００２５】
【図７】本開示の例示的実施形態による、ＨＡＲＱフィードバック装置のブロック図である。
【００２６】
【図８】本開示の例示的実施形態による、別のＨＡＲＱフィードバック装置のブロック図である。
【００２７】
【図９】本開示の例示的実施形態による、指示情報を送るための装置のブロック図である。
【００２８】
【図１０】本開示の例示的実施形態による、指示情報を送るための別の装置のブロック図である。
【００２９】
【図１１】本開示の例示的実施形態による、ＨＡＲＱフィードバックにおいて使用される装置のブロック図である。
【００３０】
【図１２】本開示の例示的実施形態による、指示情報を送るために使用される装置のブロック図である。
【発明を実施するための形態】
【００３１】
本開示の実施形態における原理、技術的解決法、および利点を明確かつ完全に説明するために、添付の図面を用いて、本開示を、以下に、詳細に説明する。当然、記載された実施形態は、本開示の一部の実施形態にすぎず、そのすべてではない。本開示の実施形態に基づき、当業者が創造的努力を用いることなく導く、その他のすべての実施形態は、本開示の保護範囲内である。
【００３２】
図１は、本開示の例示的実施形態によるＨＡＲＱフィードバック方法のフローチャートである。この実施形態は、ＵＥ側から記述される。図１に示すように、ＨＡＲＱフィードバック方法は、以下のステップを含む。
【００３３】
ステップＳ１０１において、基地局からの第１のサービス・データ送信が受信され、ここで、第１のサービス・データ送信のスケジュール制御データは指示情報を運び、指示情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示する。
【００３４】
この実施形態において、第１のサービスは、第２のサービスと比較して、適時性に関して、より高い要件を課すので、第１のサービス・データが第１のサービス・データをプリエンプトすることがある。第１のサービスは、ｅＭＢＢを含んでもよいが、それに限定されず、第２のサービスは、ＵＲＬＬＣを含んでもよいが、それに限定されない。
【００３５】
ＵＥが基地局から１つの第１のサービス・データ送信を受信するとき、指示情報がこの１つの第１のサービス・データ送信のスケジュール制御データで運ばれてよく、指示情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示する。ＵＥが基地局から２つの第１のサービス・データ送信を受信すると、指示情報は、後の第１のサービス・データ送信のスケジュール制御データで運ばれてよく、ここで、指示情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトする、または、第２のサービス・データが先の第１のサービス・データ送信における第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示する。スケジュール制御データは、物理的ダウンリンク制御チャネル（ＰＤＣＣＨ）を含むことができるが、それに限定されるものではない。後者の場合、２つの第１のサービス・データ送信の時間間隔は非適応型ＨＡＲＱフィードバック・モードにおける送信レイテンシより短いこと、そうでないと、後の第１のサービス・データ送信のスケジュール制御データが到着する前に、ＨＡＲＱフィードバック情報が基地局に送られなければならないことに留意する必要がある。すなわち、ＵＥは、指示情報を受信する前に、ＨＡＲＱフィードバック情報を基地局に送らなければならない。
【００３６】
ステップＳ１０２において、送信リソースをプリエンプトする第２のサービス・データは、指示情報に従ってキャッシュに保存され、第１のサービス・データのＨＡＲＱフィードバック情報が生成される。
【００３７】
この実施形態において、送信リソースをプリエンプトする第２のサービス・データを送信するために、指示情報に従ってその第２のサービス・データをキャッシュに保管することができる。
【００３８】
ＨＡＲＱフィードバック情報は、複数のやり方で生成することができる。たとえば、ＨＡＲＱフィードバック情報は、送信リソースをプリエンプトする第２のサービス・データ以外のデータの送信成功または失敗状態に基づいて、生成され得る。さらに、たとえば、送信リソースをプリエンプトする第２のサービス・データの送信成功または失敗状態が、送信成功と設定されてよく、第１のサービス・データ送信のすべてのデータの送信成功または失敗状態に従って、ＨＡＲＱフィードバック情報が生成される。
【００３９】
生成されたＨＡＲＱフィードバック情報は、第１のサービス・データの送信成功または失敗状態を正確に反映し得、それにより、ＵＥの誤動作を防ぐことができる。
【００４０】
ステップＳ１０３において、ＨＡＲＱフィードバック情報が、基地局へ送られる。
【００４１】
この実施形態において、指示情報が、後の第１のサービス・データ送信のスケジュール制御データにて運ばれると、ＨＡＲＱフィードバック情報が、非適応型ＨＡＲＱフィードバック・モードで、基地局へ送られ得る。
【００４２】
上の実施形態において、第１のサービス・データ送信で運ばれる指示情報を受信することにより、送信リソースをプリエンプトする第２のサービス・データがキャッシュに保存され、それにより、第１のサービス・データ送信時に、有用な第２のサービス・データが破棄されなくてもよい。
【００４３】
図２は、本開示の例示的実施形態による、指示情報を送るための方法のフローチャートである。この実施形態は、基地局側から記述される。図２に示すように、この方法は、以下のステップを含む。
【００４４】
ステップＳ２０１において、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトするか否かが判断される。
【００４５】
第１のサービスはｅＭＢＢを含むことができるが、それに限定されず、第２のサービスはＵＲＬＬＣを含むことができるが、それに限定されない。第１のサービスは、第２のサービスと比較して、適時性に関して、より高い要件を課すので、第１のサービス・データが第１のサービス・データをプリエンプトすることがある。この実施形態では、基地局は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトするか否かを判断し得る。
【００４６】
ステップＳ２０２では、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトする場合、第１のサービス・データ送信がＵＥに送られ、ここで、第１のサービス・データ送信のスケジュール制御データが指示情報を運び、指示情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示し、それにより、ＵＥは、第１の指示情報に基づいて、第１のサービス・データのＨＡＲＱフィードバック情報を基地局へ送る。
【００４７】
この実施形態において、基地局が、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすると判定した場合、指示情報は、ＵＥに送られる第１のサービス・データ送信のスケジュール制御データにて運ばれ得る。指示情報は、明示の指示を与えるものとすることができ、たとえば、指示情報のいくつかのビットが直接追加されてもよいし、または、指示情報は、暗示の指示を与えてもよく、たとえば、スケジュール制御データにおける標的制御情報に指示情報がスクランブル化される、すなわち、対応する指示情報は、元の制御情報の一部にスクランブル化される。指示情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることを指示してよく、ここで、送信リソース位置はビットマップによって指示することができる。指示情報を受信すると、ＵＥは、指示情報に従って送信リソースをプリエンプトする第２のサービス・データをキャッシュに保存し、第１のサービス・データのＨＡＲＱフィードバック情報を基地局へ送る。
【００４８】
基地局によってＵＥへ第１のサービス・データ送信を送ることは、基地局によってＵＥへ１つの第１のサービス・データ送信を送ることを含むことができる。その場合、指示情報は、その１つの第１のサービス・データ送信のスケジュール制御データで運ばれてもよく、指示情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示する。
【００４９】
さらに、基地局によってＵＥへ第１のサービス・データ送信を送ることは、基地局によってＵＥへ２つの第１のサービス・データ送信を送ることをさらに含んでもよい。その場合、指示情報は、後の第１のサービス・データ送信のスケジュール制御データにて運ばれてもよく、指示情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが先の第１のサービス・データ送信における第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示する。
【００５０】
スケジュール制御データは、物理的ダウンリンク制御チャネル（ＰＤＣＣＨ）を含むことができるが、それに限定されるものではない。
【００５１】
後者の場合、２つの第１のサービス・データ送信の時間間隔は非適応型ＨＡＲＱフィードバック・モードにおける送信レイテンシより短いこと、そうでないと、後の第１のサービス・データ送信のスケジュール制御データが到着する前に、ＨＡＲＱフィードバック情報が基地局に送られなければならないことに留意する必要がある。すなわち、ＵＥは、指示情報を受信する前に、ＨＡＲＱフィードバック情報を基地局に送らなければならない、すなわち、ＵＥは、指示情報に基づいて誤動作を防ぐことができない。
【００５２】
上の実施形態において、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすると判定された場合、指示情報を運ぶ第１のサービス・データ送信が、ＵＥに送られて、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすることがＵＥに通知され、それにより、ＵＥの誤動作を防ぐことができる。
【００５３】
図３は、本開示の例示的実施形態によるＨＡＲＱフィードバック方法のシグナリング・フローチャートである。この実施形態は、ＵＥと基地局のインタラクションの視点から記述される。ＵＥと基地局のインタラクションをより明確に記述するために、この実施形態は、図４を参照して記述される。図４は、本開示の例示的実施形態により、指示情報が１つのｅＭＢＢ送信プロセスにおいて運ばれることを図示する概略図である。図４に示されるように、指示情報は、１つのｅＭＢＢデータ送信のＰＤＣＣＨにて運ばれる。図３に示されるように、ＨＡＲＱフィードバック方法は、以下のステップを含む。
【００５４】
ステップＳ３０１において、基地局が、ＵＲＬＬＣデータがｅＭＢＢデータの送信リソースをプリエンプトすると判定したとき、基地局は、１つのｅＭＢＢデータ送信をＵＥに送り、ここで、ｅＭＢＢデータ送信は指示情報を運ぶ。
【００５５】
指示情報は、ＵＲＬＬＣデータがｅＭＢＢデータの送信リソースをプリエンプトすること、または、ＵＲＬＬＣデータがｅＭＢＢデータの送信リソース位置をプリエンプトすることを、明示的に指示し得る。
【００５６】
ステップＳ３０２において、ＵＥは、基地局から、ｅＭＢＢデータ送信を受信し、ｅＭＢＢデータ送信のＰＤＣＣＨにて運ばれた指示情報に従って、送信リソースをプリエンプトするＵＲＬＬＣデータをキャッシュに保存し、ｅＭＢＢデータのＨＡＲＱフィードバック情報を生成する。
【００５７】
指示情報が、ＵＲＬＬＣデータがｅＭＢＢデータの送信リソースをプリエンプトすることを、明示的に指示する場合、ＵＥは、送信に失敗したすべてのデータをキャッシュに保存し、保存されたデータの中から、送信に失敗したｅＭＢＢデータを識別し、送信されないｅＭＢＢデータに基づいて、ＨＡＲＱフィードバック情報を生成する。
【００５８】
たとえば、ＵＥは、ＮＡＣＫフィードバックを有するすべての送信リソースに対応するデータをキャッシュに保存してよく、データを消去しなくてよい。ＵＲＬＬＣのすべてのデータが送信された後、保存されたデータ内の有用なＵＲＬＬＣデータが使用される。使用されたデータのほかにさらに一部のデータが残っている場合は、そのデータが実際には送信に失敗したデータであることを示し、ＵＥは、そのデータに基づいて、ＨＡＲＱフィードバック情報を計算することができる。
【００５９】
指示情報が、ＵＲＬＬＣデータがｅＭＢＢデータの送信リソース位置をプリエンプトすることを、明示的に指示するとき、ＵＥは、ＵＲＬＬＣデータを送信するために、送信リソースをプリエンプトするＵＲＬＬＣデータをキャッシュに保存してよく、ＮＡＣＫフィードバックを有する他のデータはすべて消去してよい。さらに、ＵＥは、送信リソースをプリエンプトするＵＲＬＬＣデータ以外のデータの送信成功または失敗状態に基づいてＨＡＲＱフィードバック情報を生成し得る。たとえば、ＵＥは、ＣＢＧ  ４以外のコード・ブロック・グループ（ＣＢＧ）のｅＭＢＢデータの送信成功または失敗状態に基づいて、ＨＡＲＱフィードバック情報を生成し得る。
【００６０】
ステップＳ３０３において、ＵＥはｅＭＢＢデータのＨＡＲＱフィードバック情報を基地局に送る。
【００６１】
ステップＳ３０４において、基地局は、受信したＨＡＲＱフィードバック情報に基づいて、送信に失敗したｅＭＢＢデータをＵＥに再送信する。
【００６２】
任意選択で、指示情報が、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることを指示するとき、基地局は、ＵＥから、第１のサービス・データのＨＡＲＱフィードバック情報を受信してよく、ここで、ＨＡＲＱフィードバック情報は、送信リソース位置に対応する第２のサービス・データのＨＡＲＱフィードバック情報、および、他の送信リソース位置に対応する第１のサービス・データのＨＡＲＱフィードバック情報を含み、そして、他の送信リソース位置に対応する第１のサービス・データのＨＡＲＱフィードバック情報に従って、ＵＥへの送信に失敗した第１のサービス・データを再送信する。すなわち、第１のサービス・データの再送信を決定すると、基地局は、送信リソース位置に対応する第２のサービス・データのＨＡＲＱフィードバック情報を無視し、他のリソース位置に対応する第１のサービス・データのＨＡＲＱフィードバック情報のみを考慮する。
【００６３】
たとえば、基地局は、図４に示すように、ＣＢＧ  ４以外のＣＢＧに対応するｅＭＢＢデータのＨＡＲＱフィードバック情報に従って、再送信するｅＭＢＢデータを決定し得る。
【００６４】
上の実施形態では、ＵＥと基地局のインタラクションに基づいて、ＵＥは、ＵＲＬＬＣデータがｅＭＢＢデータの送信リソースをプリエンプトすることを認知し得、それにより、ＵＥは、ｅＭＢＢデータ送信の間に有用なＵＲＬＬＣを破棄せずともよく、ｅＭＢＢデータの送信成功または失敗状態を、正確に、基地局にフィードバックし得る。このようにして、基地局は、実際には送信に失敗したｅＭＢＢデータを再送信し得る。
【００６５】
第２のサービス・データが第１のサービス・データをプリエンプトすることを判断する能力を有する基地局に関して、図３に示すようなプロセスに基づいて、ＨＡＲＱフィードバックが生成されてもよいことが留意されるべきである。ただし、そのような能力を持たない基地局に関しては、この判断は、後の第１のサービス・データ送信のＰＤＣＣＨにて運ばれる指示情報に基づいて実行され得る。指示情報は、第２のサービス・データが、第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが、先の第１のサービス・データ送信における第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示し得る。２つの第１のサービス・データ送信は、連続していても、連続していなくてもよい。
【００６６】
図５は、本開示の例示的実施形態による、別のＨＡＲＱフィードバック方法のシグナリング・フローチャートである。この実施形態は、ＵＥと基地局のインタラクションの視点から記述される。ＵＥと基地局のインタラクションをより明確に説明するために、この実施形態は、図６を参照して記述される。図６に示されるように、指示情報は、後のｅＭＢＢデータ送信のＰＤＣＣＨにて運ばれ、ここで、指示情報は、先のｅＭＢＢデータ送信におけるＵＲＬＬＣデータがｅＭＢＢデータの送信リソースをプリエンプトすること、または、ＵＲＬＬＣデータがｅＭＢＢデータの送信リソース位置をプリエンプトすることを、明示的に示し得る。図５に示されているように、ＨＡＲＱフィードバック方法は、以下のステップを含む。
【００６７】
ステップＳ５０１において、基地局は、２つのｅＭＢＢデータ送信をＵＥへ送り、ここで、２つの第１のサービス・データ送信の時間間隔は、非適応型ＨＡＲＱフィードバック・モードにおける送信レイテンシより短い。
【００６８】
指示情報は、後の第１のサービス・データ送信のスケジュール制御データにて運ばれる。
【００６９】
ステップＳ５０２において、先のｅＭＢＢデータ送信を受信すると、ＵＥは、後のｅＭＢＢデータ送信のＰＤＣＣＨを読んで、指示情報を得る。
【００７０】
ステップＳ５０３において、送信リソースをプリエンプトするＵＲＬＬＣデータは、得られた指示情報に従ってキャッシュに保存され、ｅＭＢＢデータのＨＡＲＱフィードバック情報が生成される。
【００７１】
ステップＳ５０３においてＨＡＲＱフィードバック情報を生成するプロセスは、ステップＳ３０２においてＨＡＲＱフィードバック情報を生成するプロセスと同じであり、本明細書ではこれ以上記述しない。
【００７２】
ステップＳ５０４において、ＵＥは、ｅＭＢＢデータのＨＡＲＱフィードバック情報を、非適応型ＨＡＲＱフィードバック・モードで、基地局へ送る。
【００７３】
ステップＳ５０５において、基地局は、受信したＨＡＲＱフィードバック情報に基づいて、ＵＥへの送信に失敗したｅＭＢＢデータを再送信する。
【００７４】
上の実施形態において、ＵＥは、ＵＥと基地局のインタラクションに基づいて、後の第１のサービス・データ送信のスケジュール制御データから指示情報を取得して、ＵＲＬＬＣデータがｅＭＢＢデータの送信リソースをプリエンプトすることを認知することができ、その結果、ＵＥは、ｅＭＢＢデータ送信の間に有用なＵＲＬＬＣデータを破棄せずともよく、ｅＭＢＢデータの送信成功または失敗状態を、正確に、基地局にフィードバックし得る。このようにして、基地局は、実際には送信に失敗したｅＭＢＢデータを再送信し得る。
【００７５】
図７は、本開示の例示的実施形態によるＨＡＲＱフィードバック装置のブロック図である。ＨＡＲＱフィードバック装置は、ＵＥに配置され、受信モジュール７１、保存モジュール７２、および送信モジュール７３を含む。
【００７６】
受信モジュール７１は、第１のサービス・データ送信を基地局から受信するように構成され、第１のサービス・データ送信のスケジュール制御データが指示情報を運び、ここで、指示情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示する。
【００７７】
この実施形態において、第１のサービスは、第２のサービスに比べて、より高い適時性の要件を課すので、第１のサービス・データが第１のサービス・データをプリエンプトすることがあり得る。第１のサービスはｅＭＢＢを含むことができるが、それに限定されず、第２のサービスはＵＲＬＬＣを含むことができるが、それに限定されない。
【００７８】
ＵＥが１つの第１のサービス・データ送信を基地局から受信する場合、指示情報は、その１つの第１のサービス・データ送信のスケジュール制御データにて運ばれてもよく、ここで、指示情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示する。ＵＥが、２つの第１のサービス・データ送信を基地局から受信する場合、指示情報は、後の第１のサービス・データ送信のスケジュール制御データで運ばれてもよく、ここで、指示情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示する。このスケジュール制御データは、ＰＤＣＣＨを含むことができるが、それに限定されない。後者の場合には、２つの第１のサービス・データ送信の間の時間間隔は非適応型ＨＡＲＱフィードバック・モードの送信レイテンシよりも短く、そうでないと、後の第１のサービス・データ送信のスケジュール制御データが到着する前に、ＨＡＲＱフィードバック情報が基地局に送られなければならないことに留意する必要がある。すなわち、ＵＥは、指示情報を受信する前に、ＨＡＲＱフィードバック情報を基地局に送らなければならない。
【００７９】
保存生成モジュール７２は、受信モジュール７１によって受信される、第１のサービス・データ送信のスケジュール制御データにて運ばれる指示情報に従って、送信リソースをプリエンプトする第２のサービス・データをキャッシュに保存し、第１のサービス・データのＨＡＲＱフィードバック情報を生成するように構成される。
【００８０】
１つの実施形態において、指示情報が、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすることを、明示的または暗示的に、指示するとき、保存生成モジュール７２は、送信に失敗したすべてのデータをキャッシュに保存し、保存されたデータの中から、送信に失敗した第１のサービス・データを識別し、送信に失敗した第１のサービス・データに基づいて、ＨＡＲＱフィードバック情報を生成するように構成され得る。
【００８１】
送信モジュール７３は、保存生成モジュールによって生成されたＨＡＲＱフィードバック情報を基地局へ送るように構成される。
【００８２】
指示情報が、後の第１のサービス・データ送信のスケジュール制御データにて運ばれる場合、送信モジュール７３は、非適応型ＨＡＲＱフィードバック・モードで、ＨＡＲＱフィードバック情報を、基地局へ送るように構成されてもよい。
【００８３】
上の実施形態において、第１のサービス・データ送信で運ばれる指示情報を受信することにより、第２のサービス・データがキャッシュ中に送信リソースをプリエンプトし、その結果、有用な第２のサービス・データが第１のサービス・データ送信の時に破棄されなくてもよい。
【００８４】
図８は、本開示の例示的実施形態による、別のＨＡＲＱフィードバック装置のブロック図である。図８に示されるように、図７に図示した実施形態に基づいて、保管生成モジュール７２は、第１の生成サブモジュール７２１または第２の生成サブモジュール７２２を含んでもよい。
【００８５】
第１の生成サブモジュール７２１は、送信リソースをプリエンプトする第２のサービス・データ以外のデータの送信成功または失敗状態に基づいて、ＨＡＲＱフィードバック情報を生成するように構成される。
【００８６】
第２の生成サブモジュール７２２は、送信リソースをプリエンプトする第２のサービス・データの送信成功または失敗状態を、送信成功と設定し、第１のサービス・データ送信におけるすべてのデータの送信成功または失敗状態のＨＡＲＱフィードバック情報を生成するように構成される。
【００８７】
このＨＡＲＱフィードバック情報は、複数のやり方で生成されてもよい。たとえば、ＨＡＲＱフィードバック情報は、送信リソースをプリエンプトする第２のサービス・データ以外のデータの送信成功または失敗状態に基づいて生成されてもよい。さらに、たとえば、送信リソースをプリエンプトする第２のサービス・データの送信成功または失敗状態が、送信成功と設定されてもよく、第１のサービス・データ送信におけるすべてのデータの送信成功または失敗状態に従って、ＨＡＲＱフィードバック情報が生成される。
【００８８】
上の実施形態において、第１の生成サブモジュールまたは第２の生成サブモジュールによって生成されたＨＡＲＱフィードバック情報は、第１のサービス・データの送信成功または失敗状態を正確に反映することができ、その結果、ＵＥの誤動作を防ぐことができる。
【００８９】
図９は、本開示の例示的実施形態による、指示情報を送るための装置のブロック図である。この装置は、基地局に配置され、判断モジュール９１と判定送信モジュール９２を含む。
【００９０】
判断モジュール９１は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトするか否かを判断するように構成される。
【００９１】
第１のサービスはｅＭＢＢを含むことができるが、それに限定されず、第２のサービスはＵＲＬＬＣを含むことができるが、それに限定されない。第１のサービスは、第２のサービスに比べて、適時性に関して高い要件を課すので、第１のサービス・データが第１のサービス・データをプリエンプトすることがあり得る。この実施形態において、基地局は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトするか否かを判定してもよい。
【００９２】
判定送信モジュール９２は、判断モジュール９１が第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすると判断した場合、第１のサービス・データ送信をユーザ機器（ＵＥ）へ送り、ここで、第１のサービス・データ送信のスケジュール制御データは指示情報を運び、指示情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示し、その結果、ＵＥは、指示情報に従って、送信リソースをプリエンプトする第２のサービス・データをキャッシュに保存し、第１のサービス・データのＨＡＲＱフィードバック情報を基地局へ送る、ように構成される。
【００９３】
この実施形態において、基地局が、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすると判定した場合、指示情報は、ＵＥへ送られる第１のサービス・データ送信のスケジュール制御データにて運ばれてもよい。指示情報は、明示の指示を与えるものとすることができ、たとえば、指示情報にいくつかのビットが直接付加されてもよく、または、指示情報は、暗示の指示を与えるものとすることができ、たとえば、指示情報が、スケジュール制御データにおける標的制御情報にスクランブル化される、すなわち、対応する指示情報が、元の制御情報の一部にスクランブル化される。指示情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることを指示するために用いられてもよく、ここで、送信リソース位置は、ビットマップによって指示されてもよい。ＵＥは、指示情報を受信すると、その指示情報に従って、送信リソースをプリエンプトする第２のサービス・データをキャッシュに保存して、第１のサービス・データのＨＡＲＱフィードバック情報を基地局へ送ってもよい。
【００９４】
基地局によってＵＥへ第１のサービス・データ送信を送ることは、基地局によってＵＥへ１つの第１のサービス・データ送信を送ることを含んでもよい。その場合、指示情報は、その１つの第１のサービス・データ送信のスケジュール制御データで運ばれてもよく、指示情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示する。
【００９５】
１つの実施形態において、判定送信モジュール９２は、２つの第１のサービス・データ送信をＵＥへ送るように構成され、ここで、２つの第１のサービス・データ送信の間の時間間隔は、非適応型ＨＡＲＱフィードバック・モードの送信レイテンシよりも短い。指示情報は、後の第１のサービス・データ送信のスケジュール制御データで運ばれ、指示情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが先の第１のサービス・データ送信における第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示する。
【００９６】
上の実施形態において、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすると判定されると、指示情報を運ぶ第１のサービス・データ送信がＵＥに送られて、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすることがＵＥに通知され、それにより、ＵＥの誤動作を防ぐことができる。
【００９７】
図１０は、本開示の例示的実施形態による、指示情報を送るための別の装置のブロック図である。図１０に示されるように、図９に図示された実施形態に基づいて、指示情報が、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示しているときは、装置は、受信モジュール９３と再送信モジュール９４を、さらに含んでもよい。
【００９８】
受信モジュール９３は、ＵＥから第１のサービス・データのＨＡＲＱフィードバック情報を受信するように構成され、ここで、ＨＡＲＱフィードバック情報は、第２のサービス・データの送信リソース位置に対応する第２のサービス・データのＨＡＲＱフィードバック情報と、別の送信リソース位置に対応する第１のサービス・データのＨＡＲＱフィードバック情報を含む。
【００９９】
再送信モジュール９４は、別の送信リソース位置に対応する第１のサービス・データのＨＡＲＱフィードバック情報に従って、ＵＥへの送信に失敗した第１のサービス・データを再送信するように構成される。
【０１００】
指示情報が、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることを指示するとき、基地局は、ＵＥから第１のサービス・データのＨＡＲＱフィードバック情報を受信してもよく、ここで、ＨＡＲＱフィードバック情報は、送信リソース位置に対応する第２のサービス・データのＨＡＲＱフィードバック情報と、他の送信リソース位置に対応する第１のサービス・データのＨＡＲＱフィードバック情報を含み、他の送信リソース位置に対応する第１のサービス・データのＨＡＲＱフィードバック情報に従って、送信に失敗した第１のサービス・データをＵＥへ再送信する。すなわち、第１のサービス・データを再送信すると決定した場合、基地局は、送信リソース位置に対応する第２のサービス・データのＨＡＲＱフィードバック情報を無視し、他のリソース位置に対応する第１のサービス・データのＨＡＲＱフィードバック情報のみを考慮する。
【０１０１】
上の実施形態において、他の送信リソース位置に対応する、第１のサービス・データの受信したＨＡＲＱフィードバック情報に基づいて、送信に失敗した第１のサービス・データを、ＵＥへ再送信することにより、基地局は、実際に再送信されるべき第１のサービス・データを識別してもよい。
【０１０２】
図１１は、例示的実施形態によるＨＡＲＱフィードバックにおいて使用される装置のブロック図である。たとえば、装置１１００は、携帯電話、コンピュータ、デジタル・ブロードキャスト端末、メッセージング・デバイス、ゲーム・コンソール、タブレット・デバイス、医療用デバイス、フィットネス機器、携帯情報端末などとすることができる。
【０１０３】
図１１を参照すると、装置１１００は、処理コンポーネント１１０２、メモリ１１０４、電力コンポーネント１１０６、マルチメディア・コンポーネント１１０８、音声コンポーネント１１１０、入出力（Ｉ／Ｏ）インタフェース１１１２、センサ・コンポーネント１１１４、および通信コンポーネント１１１６のうちの、１つ以上のコンポーネントを含むことができる。
【０１０４】
処理コンポーネント１１０２は、一般的には、表示、電話通話、データ通信、カメラ動作、記録動作に関連する動作など、装置１１００の動作全体を制御する。処理コンポーネント１１０２は、上述の方法のステップの全部または一部を行う命令を実行する１つまたは複数のプロセッサ１１２０を含んでもよい。さらに、処理コンポーネント１１０２は、処理コンポーネント１１０２と他のコンポーネントの間のインタラクションを容易にする１つまたは複数のモジュールを含んでもよい。たとえば、処理コンポーネント１１０２は、マルチメディア・コンポーネント１１０８と処理コンポーネント１１０２の間のインタラクションを容易にするマルチメディア・モジュールを含んでもよい。
【０１０５】
メモリ１１０４は、装置１１００の動作をサポートするために各種データを記憶するように構成される。そのようなデータの例として、装置１１００上で動作するアプリケーションまたは方法のための命令、連絡先データ、電話帳データ、メッセージ、画像、動画等がある。メモリ１１０４は、静的ランダム・アクセス・メモリ（ＳＲＡＭ）、電気的消去可能プログラマブル・リードオンリ・メモリ（ＥＥＰＲＯＭ）、消去可能プログラマブル・リードオンリ・メモリ（ＥＰＲＯＭ）、プログラマブル・リードオンリ・メモリ（ＰＲＯＭ）、リードオンリ・メモリ（ＲＯＭ）、磁気メモリ、フラッシュ・メモリ、磁気または光学ディスクなど、任意の種類の揮発性もしくは非揮発性のメモリデバイス、またはそれらの組み合わせを用いて実施してもよい。
【０１０６】
電力コンポーネント１１０６は、装置１１００の各種コンポーネントに電力を提供する。電力コンポーネント１１０６は、装置１１００における電力管理システム、１つまたは複数の電源、ならびに発電、電力管理、および配電に関連するその他のコンポーネントを含むことができる。
【０１０７】
マルチメディア・コンポーネント１１０８は装置１１００とユーザの間の出力インタフェースを提供する画面を含む。いくつかの実施形態では、この画面は、液晶ディスプレイ（ＬＣＤ）とタッチ・パネル（ＴＰ）を含んでもよい。画面がタッチ・パネルを含む場合、画面は、ユーザから入力信号を受信するタッチ・スクリーンとして実装されてもよい。このタッチ・パネルは、タッチ・パネルに対するタッチ、スワイプ、およびジェスチャを感知する１つまたは複数のタッチ・センサを含む。タッチ・センサは、タッチまたはスワイプ動作の境界を感知するのみならず、タッチまたはスワイプ動作に関わる時間および圧力をも感知するものとすることができる。いくつかの実施形態では、マルチメディア・コンポーネント１１０８は、前部カメラおよび／または後部カメラを含む。前部カメラおよび後部カメラは、装置１１００が、撮影モードまたはビデオ・モードなどの、動作モードにある間、外部のマルチメディア・データを受信するものであってもよい。前部カメラと後部カメラは、各々、固定光学レンズ・システムであるか、または、焦点光学ズーム機能を有するものであってもよい。
【０１０８】
音声コンポーネント１１１０は、音声信号を、出力および／または入力するように構成される。たとえば、音声コンポーネント１１１０は、装置１１００が、通話モード、記録モード、およびボイス認識モードなどの動作モードにあるとき、外部の音声信号を受信するように構成されたマイクロホン（ＭＩＣ）を含む。受信された音声信号は、さらに、メモリ１１０４に格納されるか、または通信コンポーネント１１１６を介して送信されてもよい。いくつかの実施形態では、音声コンポーネント１１１０は、さらに、音声信号を出力するためのスピーカーを含む。
【０１０９】
Ｉ／Ｏインタフェース１１１２は、処理コンポーネント１１０２と、キーボード、クリック・ホイール、ボタンなどの周辺インタフェース・モジュールの間のインタフェースを提供する。ボタンは、ホーム・ボタン、ボリューム・ボタン、スタート・ボタン、およびロック・ボタンを含んでもよいが、それらに限定されない。
【０１１０】
センサ・コンポーネント１１１４は、装置１１００の様々な面のステータス評価を提供する１つまたは複数のセンサを含む。たとえば、センサ・コンポーネント１１１４は、装置１１００のオン／オフ・ステータス、装置１１００のコンポーネント同士、たとえば、ディスプレイ・デバイスとミニ・キーボード、の相対的位置を検知してもよく、また、センサ・コンポーネント１１１４は、装置１１００または装置１１００のコンポーネントの位置変化、ユーザと装置１１００の接触の有無、装置１１００の方向または加速／減速、および装置１１００の温度変化を検出してもよい。センサ・コンポーネント１１１４は、物理的接触なしに付近の物体の存在を検知するように構成された近接センサを含んでもよい。センサ・コンポーネント１１１４は、撮像アプリケーションに用いられる、ＣＭＯＳまたはＣＣＤイメージセンサなどの、光センサを含んでもよい。いくつかの実施形態では、センサ・コンポーネント１１１４はまた、加速度計センサ、ジャイロスコープ・センサ、磁気センサ、圧力センサ、または温度センサを含んでもよい。
【０１１１】
通信コンポーネント１１１６は、装置１１００と他のデバイスの間の有線または無線の通信を容易にするように構成される。装置１１００は、ＷｉＦｉ、２Ｇ、もしくは３Ｇ、またはそれらの組み合わせなどの通信標準に基づく無線ネットワークにアクセスすることができる。例示的実施形態において、通信コンポーネント６１６は、ブロードキャスト・チャネルを介して、外部のブロードキャスト管理システムから、ブロードキャスト信号またはブロードキャスト関連情報を受信する。例示的実施形態において、通信コンポーネント１１１６は、さらに、短距離通信を容易にする近距離無線通信（ＮＦＣ）モジュールを含む。
【０１１２】
例示的実施形態において、装置１１００は、１つまたは複数の特定用途向け集積回路（ＡＳＩＣ）、デジタル信号プロセッサ（ＤＳＰ）、デジタル信号処理デバイス（ＤＳＰＤ）、プログラマブル論理デバイス（ＰＬＤ）、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、コントローラ、マイクロコントローラ、マイクロプロセッサ、または、上述の方法を実行するためのその他の電子コンポーネントを用いて実装されてもよい。
【０１１３】
例示的実施形態において、上述の方法を実行するために、装置１１００内のプロセッサ１１２０によって実行可能な命令を含む、メモリ１１０４など、命令を含む非一時的コンピュータ可読記憶媒体も提供される。たとえば、非一時的コンピュータ可読記憶媒体は、ＲＯＭ、ＲＡＭ、ＣＤ−ＲＯＭ、磁気テープ、フロッピー・ディスク、光学データ記憶デバイスなどとすることができる。
【０１１４】
図１２は、本開示の例示的実施形態による、指示情報を送るために使用される装置１２００のブロック図である。装置１２００は、基地局として提供されてもよい。図１２を参照すると、装置１２００は、処理コンポーネント１２２２、無線送信／受信コンポーネント１２２４、無線アンテナ１２２６、および無線インタフェース専用の信号処理部を含む。処理コンポーネント１２２２は、さらに、１つまたは複数のプロセッサを含んでもよい。
【０１１５】
処理コンポーネント１２２２内の１つのプロセッサは、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトするか否かを判断し、
【０１１６】
第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトする場合、第１のサービス・データ送信をＵＥへ送るように構成されてもよく、第１のサービス・データ送信のスケジュール制御データは指示情報を運び、その指示情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示し、それにより、ＵＥは、指示情報に従って、送信リソースをプリエンプトする第２のサービス・データをキャッシュに保存し、第１のサービス・データのＨＡＲＱフィードバック情報を基地局へ送る。
【０１１７】
装置の実施形態は、方法の実施形態に実質的に対応するので、装置の実施形態の説明は簡単になされており、関連部分は、方法の実施形態の説明部分を参照して得られ得る。上述の装置の実施形態は、単に、例示のみを目的とするものである。別個のコンポーネントとして記述されているユニットは、物理的に分離されていても、物理的に分離されていなくてもよく、ユニットとして示されているコンポーネントは、物理的なユニットであっても、そうでなくてもよい、すなわち、コンポーネントは、同じ位置に配置されてもよく、複数のネットワーク・ユニットに分散されていてもよい。モジュールの一部または全部が、実施形態の技術的解決法の目的を達成するために、実際のニーズに従って選択されてもよい。当業者は、創造的努力を要せずに、本開示を理解し、実施できる。
【０１１８】
本明細書において、「第１の」および「第２の」のような関係性を表す用語は、あるエンティティまたは動作を別のエンティティまたは動作と区別するためにのみ用いられ、それらのエンティティまたは動作の間に実際上の関係または順序があることを要求する、または意味する意図はないことに留意されたい。本明細書において、「備える」、「備えている」、「有する」、「有している」、「含む」、「含んでいる」、「内包する」、「内包している」、またはそれらの変形は、非排他的包含を意味することが意図されており、したがって、要素のリストを備える、有する、含む、包含するプロセス、方法、物品、またはデバイスは、それらの要素のみを含むのではなく、そのプロセス、方法、物品、またはデバイスに明示的に列挙されていないかまたは固有ではない、その他の要素を含んでもよいことに留意されたい。「〜を備える」、「〜を有する」、「〜を含む」、「〜を内包する」という語句が後に続く要素は、さらに制約がなければ、当該プロセス、方法、物品、または装置に、同じ要素が追加されて存在することを妨げるものではない。
【０１１９】
本開示による方法および装置は、以上に詳細に説明され、本開示の原理および実施形態は、具体的な実施形態および例を参照して説明されているが、上述の実施形態は、本開示の方法および中核的思想の理解を助けるためにのみ記述されたものである。当業者は、本開示の概念に従って、具体的な実施形態または適用の範囲に修正または変形を加えることができる。結論として、本明細書は、本開示を限定するものと理解されてはならない。
【手続補正２】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ハイブリッド自動反復要求（ＨＡＲＱ）フィードバック方法であって、
基地局から第１のサービス・データ送信を受信するステップであって、該第１のサービス・データ送信のスケジュール制御データは指示情報を運び、該指示情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすることと、または、該第２のサービス・データが該第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示するように構成される、受信するステップと、
該指示情報に従って、該送信リソースをプリエンプトする該第２のサービス・データをキャッシュに保存し、該第１のサービス・データのＨＡＲＱフィードバック情報を生成するステップと、
該ＨＡＲＱフィードバック情報を該基地局へ送るステップと
を含む、方法。
【請求項２】
第１のサービス・データ送信を基地局から受信する前記ステップが、
２つの第１のサービス・データ送信を該基地局から受信するステップを含み、該２つの第１のサービス・データ送信の間の時間間隔は、非適応型ＨＡＲＱフィードバック・モードにおける送信レイテンシより短く、
前記指示情報が後の第１のサービス・データ送信の前記スケジュール制御データにて運ばれ、該指示情報は、前記第２のサービス・データが前記第１のサービス・データの前記送信リソースをプリエンプトすること、または、前記第２のサービス・データが先の第１のサービス・データ送信における前記第１のサービス・データの前記送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示するように構成される、請求項１記載の方法。
【請求項３】
前記第１のサービス・データのＨＡＲＱフィードバック情報を生成する前記ステップが、
前記送信リソースをプリエンプトする前記第２のサービス・データ以外の、前記第１のサービス・データ送信のデータの送信成功または失敗状態に基づいて、該ＨＡＲＱフィードバック情報を生成するステップ、または、
該送信リソースをプリエンプトする該第２のサービス・データの送信成功または失敗状態を送信成功と設定し、前記第１のサービス・データ送信にあるすべてのデータの送信成功または失敗状態に基づいて該ＨＡＲＱフィードバック情報を生成するステップ
を含む、請求項１記載の方法。
【請求項４】
前記指示情報が、前記第２のサービス・データが前記第１のサービス・データの前記送信リソースをプリエンプトすることを、明示的または暗示的に、指示するように構成されるとき、該送信リソースをプリエンプトする該第２のサービス・データをキャッシュに保存し、該第１のサービス・データのＨＡＲＱフィードバック情報を生成する前記ステップが、
送信に失敗したすべてのデータを該キャッシュに保存し、該保存されたデータの中から、送信に失敗した該第１のサービス・データを識別し、送信に失敗した該第１のサービス・データに基づいて、該ＨＡＲＱフィードバック情報を生成するステップを含む、請求項１記載の方法。
【請求項５】
前記指示情報が、前記後の第１のサービス・データ送信の前記スケジュール制御データにて運ばれる場合、前記基地局へ前記ＨＡＲＱフィードバック情報を送る前記ステップが、
前記非適応型ＨＡＲＱフィードバック・モードにて該基地局へ該ＨＡＲＱフィードバック情報を送るステップを含む、請求項２記載の方法。
【請求項６】
前記指示情報を運ぶ前記第１のサービス・データ送信の前記スケジュール制御データが、
スクランブル化コード形式の該スケジュール制御データにおける標的制御情報へと該指示情報をスクランブル化するステップを含む、請求項１記載の方法。
【請求項７】
指示情報を送るための方法であって、
第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトするか否かを判断するステップと、
該第２のサービス・データが該第１のサービス・データの該送信リソースをプリエンプトする場合、第１のサービス・データ送信をユーザ機器（ＵＥ）へ送るステップであって、該第１のサービス・データ送信のスケジュール制御データは指示情報を運び、該指示情報は、該第２のサービス・データが該第１のサービス・データの該送信リソースをプリエンプトすること、または、該第２のサービス・データが該第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示するように構成され、それにより、該ＵＥは、該指示情報に従って、該送信リソースをプリエンプトする該第２のサービス・データをキャッシュに保存し、該第１のサービス・データのＨＡＲＱフィードバック情報を基地局へ送る、送るステップと
を含む、方法。
【請求項８】
第１のサービス・データ送信を前記ＵＥへ送る前記ステップが、
２つの第１のサービス・データ送信を該ＵＥへ送ることを含み、前記２つの第１のサービス・データ送信の間の時間間隔は、非適応型ＨＡＲＱフィードバック・モードの送信レイテンシよりも短く、
前記指示情報は後の第１のサービス・データ送信の前記スケジュール制御データにて運ばれ、該指示情報は、前記第２のサービス・データが前記第１のサービス・データの前記送信リソースをプリエンプトすること、または、該第２のサービス・データが先の第１のサービス・データ送信における該第１のサービス・データの前記送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示するように構成される、請求項７記載の方法。
【請求項９】
前記指示情報が前記第２のサービス・データが前記第１のサービス・データの前記送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示するように構成されるとき、前記方法は、
該第１のサービス・データのＨＡＲＱフィードバック情報を前記ＵＥから受信するステップであって、該ＨＡＲＱフィードバック情報は、該送信リソース位置に対応する該第２のサービス・データのＨＡＲＱフィードバック情報、および他の送信リソース位置に対応する該第１のサービス・データのＨＡＲＱフィードバック情報を含む、受信するステップと、
他の送信リソース位置に対応する該第１のサービス・データの該ＨＡＲＱフィードバック情報に従って、該ＵＥに送信に失敗した該第１のサービス・データを再送信するステップと
をさらに含む、請求項７または８記載の方法。
【請求項１０】
前記指示情報を運ぶ前記第１のサービス・データ送信の前記スケジュール制御データが、
スクランブル化コード形式の該スケジュール制御データにおける標的制御情報へと該指示情報をスクランブル化するステップを含む、請求項７記載の方法。
【請求項１１】
プロセッサと、
該プロセッサによって実行可能な命令を記憶するためのメモリと
を含む、ユーザ機器であって、
該プロセッサが、
請求項１から６のいずれか１項に記載のＨＡＲＱフィードバック方法を実行する、ユーザ機器。
【請求項１２】
プロセッサと、
該プロセッサによって実行可能な命令を記憶するためのメモリと
を含む基地局であって、
該プロセッサは、
請求項７から１０のいずれか１項に記載の指示情報を送るための方法を実行する、基地局。
【国際調査報告】
2020523877.tif 000015
2020523877.tif 000016
2020523877.tif 000017
2020523877.tif 000018
2020523877.tif 000019
2020523877.tif 000020