特許 7265488 ＨＡＲＱフィードバック方法および指示情報の送信方法、ならびに、そのユーザ機器および基地局

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-04-18

(45)【発行日】2023-04-26

(54)【発明の名称】ＨＡＲＱフィードバック方法および指示情報の送信方法、ならびに、そのユーザ機器および基地局

(51)【国際特許分類】

   H04L 1/16 20230101AFI20230419BHJP

   H04W 28/04 20090101ALI20230419BHJP

【ＦＩ】

H04L1/16

H04W28/04 110

【請求項の数】 9

(21)【出願番号】P 2019569212

(86)(22)【出願日】2017-06-16

(65)【公表番号】

(43)【公表日】2020-08-06

(86)【国際出願番号】 CN2017088705

(87)【国際公開番号】W WO2018227574

(87)【国際公開日】2018-12-20

【審査請求日】2020-01-15

【審判番号】

【審判請求日】2022-01-11

(73)【特許権者】

【識別番号】516180667

【氏名又は名称】北京小米移動軟件有限公司

【氏名又は名称原語表記】Ｂｅｉｊｉｎｇ Ｘｉａｏｍｉ Ｍｏｂｉｌｅ Ｓｏｆｔｗａｒｅ Ｃｏ．，Ｌｔｄ．

【住所又は居所原語表記】Ｎｏ．０１８， Ｆｌｏｏｒ ８， Ｂｕｉｌｄｉｎｇ ６， Ｙａｒｄ ３３， Ｍｉｄｄｌｅ Ｘｉｅｒｑｉ Ｒｏａｄ， Ｈａｉｄｉａｎ Ｄｉｓｔｒｉｃｔ， Ｂｅｉｊｉｎｇ １０００８５， Ｃｈｉｎａ

(74)【代理人】

【識別番号】110000729

【氏名又は名称】弁理士法人ユニアス国際特許事務所

(72)【発明者】

【氏名】周 ▲チュエ▼嘉

【合議体】

【審判長】土居 仁士

【審判官】寺谷 大亮

【審判官】角田 慎治

(56)【参考文献】

【文献】特開２００３－３２４４９６（ＪＰ，Ａ）

【文献】特開２０１２－１９９７１９（ＪＰ，Ａ）

【文献】特表２０１５－５３１２２０（ＪＰ，Ａ）

【文献】Ｓａｍｓｕｎｇ，Ｍｕｌｔｉｐｌｅｘｉｎｇ ｏｆ ｅＭＢＢ ａｎｄ ＵＲＬＬＣ ｉｎ Ｄｏｗｎｌｉｎｋ，３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１ ＃８８ｂ Ｒ１－１７０５４０７，２０１７年０３月２４日

(58)【調査した分野】(Int.Cl.，ＤＢ名)

H04L1/00

H04L1/08-1/24

H04W4/00-99/00

(57)【特許請求の範囲】

【請求項1】

ハイブリッド自動反復要求（ＨＡＲＱ）フィードバック方法であって、
基地局から第１のサービス・データ送信を受信するステップであって、該第１のサービス・データ送信のスケジュール制御データは指示情報を運び、該指示情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすることと、または、該第２のサービス・データが該第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示するように構成される、受信するステップと、
該指示情報に従って、該送信リソースをプリエンプトする該第２のサービス・データをキャッシュに保存し、該第１のサービス・データのＨＡＲＱフィードバック情報を生成するステップと、
該ＨＡＲＱフィードバック情報を該基地局へ送るステップとを含み、
前記指示情報に従って、該送信リソースをプリエンプトする該第２のサービス・データをキャッシュに保存し、該第１のサービス・データのＨＡＲＱフィードバック情報を生成するステップは、
前記指示情報が、前記第２のサービス・データが前記第１のサービス・データの前記送信リソースをプリエンプトすることを指示するように構成されるとき、送信に失敗したすべてのデータを該キャッシュに保存し、該保存されたデータの中から、送信に失敗した該第１のサービス・データを識別し、送信に失敗した該第１のサービス・データに基づいて、該ＨＡＲＱフィードバック情報を生成するステップと、
前記指示情報が、前記第２のサービス・データが前記第１のサービス・データの前記送信リソース位置をプリエンプトすることを指示するように構成されるとき、前記送信リソースをプリエンプトする前記第２のサービス・データ以外の、前記第１のサービス・データ送信のデータの送信成功または失敗状態に基づいて、該ＨＡＲＱフィードバック情報を生成するステップと、を含む、方法。

【請求項2】

第１のサービス・データ送信を基地局から受信する前記ステップが、
２つの第１のサービス・データ送信を該基地局から受信するステップを含み、該２つの第１のサービス・データ送信の間の時間間隔は、非適応型ＨＡＲＱフィードバック・モードにおける送信レイテンシより短く、
前記指示情報が後の第１のサービス・データ送信の前記スケジュール制御データにて運ばれ、該指示情報は、前記第２のサービス・データが前記第１のサービス・データの前記送信リソースをプリエンプトすること、または、前記第２のサービス・データが先の第１のサービス・データ送信における前記第１のサービス・データの前記送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示するように構成される、請求項１記載の方法。

【請求項3】

前記指示情報が、前記後の第１のサービス・データ送信の前記スケジュール制御データにて運ばれる場合、前記基地局へ前記ＨＡＲＱフィードバック情報を送る前記ステップが、
前記非適応型ＨＡＲＱフィードバック・モードにて該基地局へ該ＨＡＲＱフィードバック情報を送るステップを含む、請求項２記載の方法。

【請求項4】

前記指示情報を運ぶ前記第１のサービス・データ送信の前記スケジュール制御データが、
スクランブル化コード形式の該スケジュール制御データにおける標的制御情報へと該指示情報をスクランブル化するステップを含む、請求項１記載の方法。

【請求項5】

指示情報を送るための方法であって、
第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトするか否かを判断するステップと、
該第２のサービス・データが該第１のサービス・データの該送信リソースをプリエンプトする場合、第１のサービス・データ送信をユーザ機器（ＵＥ）へ送るステップであって、該第１のサービス・データ送信のスケジュール制御データは指示情報を運び、該指示情報は、該第２のサービス・データが該第１のサービス・データの該送信リソースをプリエンプトすること、または、該第２のサービス・データが該第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示するように構成され、それにより、該ＵＥは、該指示情報に従って、該送信リソースをプリエンプトする該第２のサービス・データをキャッシュに保存し、該第１のサービス・データのＨＡＲＱフィードバック情報を基地局へ送る、送るステップとを含み、
前記ＨＡＲＱフィードバック情報は、
前記指示情報が、前記第２のサービス・データが前記第１のサービス・データの前記送信リソースをプリエンプトすることを、明示的または暗示的に、指示するように構成されるとき、送信に失敗したすべてのデータを該キャッシュに保存し、該保存されたデータの中から、送信に失敗した該第１のサービス・データを識別し、送信に失敗した該第１のサービス・データに基づいて、該ＨＡＲＱフィードバック情報を生成するステップと、
前記指示情報が、前記第２のサービス・データが前記第１のサービス・データの前記送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示するように構成されるとき、前記送信リソースをプリエンプトする前記第２のサービス・データ以外の、前記第１のサービス・データ送信のデータの送信成功または失敗状態に基づいて、該ＨＡＲＱフィードバック情報を生成するステップと、によって生成される、方法。

【請求項6】

第１のサービス・データ送信を前記ＵＥへ送る前記ステップが、
２つの第１のサービス・データ送信を該ＵＥへ送ることを含み、前記２つの第１のサービス・データ送信の間の時間間隔は、非適応型ＨＡＲＱフィードバック・モードの送信レイテンシよりも短く、
前記指示情報は後の第１のサービス・データ送信の前記スケジュール制御データにて運ばれ、該指示情報は、前記第２のサービス・データが前記第１のサービス・データの前記送信リソースをプリエンプトすること、または、該第２のサービス・データが先の第１のサービス・データ送信における該第１のサービス・データの前記送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示するように構成される、請求項５記載の方法。

【請求項7】

前記指示情報が前記第２のサービス・データが前記第１のサービス・データの前記送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示するように構成されるとき、前記方法は、
該第１のサービス・データのＨＡＲＱフィードバック情報を前記ＵＥから受信するステップであって、該ＨＡＲＱフィードバック情報は、該送信リソース位置に対応する該第２のサービス・データのＨＡＲＱフィードバック情報、および他の送信リソース位置に対応する該第１のサービス・データのＨＡＲＱフィードバック情報を含む、受信するステップと、
他の送信リソース位置に対応する該第１のサービス・データの該ＨＡＲＱフィードバック情報に従って、該ＵＥに送信に失敗した該第１のサービス・データを再送信するステップとをさらに含む、請求項５または６記載の方法。

【請求項8】

前記指示情報を運ぶ前記第１のサービス・データ送信の前記スケジュール制御データが、
スクランブル化コード形式の該スケジュール制御データにおける標的制御情報へと該指示情報をスクランブル化するステップを含む、請求項５記載の方法。

【請求項9】

プロセッサと、
該プロセッサによって実行可能な命令を記憶するためのメモリとを含む、ユーザ機器であって、
該プロセッサが、
請求項１から４のいずれか１項に記載のＨＡＲＱフィードバック方法を実行する、ユーザ機器。

【発明の詳細な説明】

【技術分野】

【0001】

（関連出願への相互参照）
この出願は、２０１７年６月１６日に出願された国際出願番号ＰＣＴ／ＣＮ２０１７／０８８７０５の継続出願であり、その全内容は参照により本明細書に組み込まれます。
本開示は、通信テクノロジーの分野に関するものであり、特に、ハイブリッド自動反復要求（ＨＡＲＱ）フィードバック方法および装置、指示情報を送るための方法、ならびに、そのユーザ機器（ＵＥ）および基地局に関する。

【背景技術】

【0002】

通信テクノロジーの発展とともに、第５世代モバイル通信テクノロジー（５Ｇ）が、開発されてきた。５Ｇにおけるサービスの種類は、少なくとも、高速モバイル・ブロード・バンド（ｅＭＢＢ）、大数量機械タイプ通信（ｍＭＴＣ）、超高信頼度低レイテンシ通信（ＵＲＬＬＣ）などを含む。これらのサービス種類は、すべて、データ・サービスに関するものであるが、レイテンシおよび信頼度に関して課す要件は異なる。たとえば、ＵＲＬＬＣサービスは、低レイテンシが要求される車両のインターネットなどの分野に適用される。このサービスは、適時性について、より厳格な要件を課し、適時のサービス確立を要求するか、またはさらには元のサービスをプリエンプト(preempt)する。ｍＭＴＣサービスは、レイテンシに敏感ではなく、このサービスでは、データは、時間間隔をさらに空けて送信されてもよい。レイテンシに敏感なサービスの有効な送信を実現する１つの方法は、ハイブリッド自動反復要求（ＨＡＲＱ）の送信を改良して、たとえば、再送信フィードバックを、より迅速、より正確にすることである。

【0003】

ロング・ターム・エボリューション（ＬＴＥ）では、ＨＡＲＱフィードバックは、送信ブロック（ＴＢ）を単位として用いて実行され、各ＴＢは、１ビットの肯定応答（ＡＣＫ）または否定応答（ＮＡＣＫ）メッセージをフィードバックする。再送信の正確性を向上させるため、第３世代パートナーシップ・プロジェクト（３ＧＰＰ）は、コード・ブロック・グループ（ＣＢＧ）に基づく再送信を提案している。ＣＢＧは、ＴＢにおける、さらにより小さなデータ単位である。１個のＣＢＧは、１ビットのＡＣＫまたはＮＡＣＫのフィードバックに対応する。再送信の粒度がさらに細かくなるので、不正確な送信の位置が、より精密に反映され得ることになり、再送信がより正確となる。さらに、再送信に要するデータ量がなおいっそう少なくなるので、再送信効率が向上する。

【0004】

しかし、たとえば、ｅＭＢＢサービスが送信中であるかまたは送信予定であり、かつＵＲＬＬＣサービスが起動中であるときのサービス・プリエンプションの場合、ＵＲＬＬＣサービスは、ｅＭＢＢサービスの送信時間－周波数リソースをプリエンプトすることができる。その結果、元のｅＭＢＢサービスは、ＨＡＲＱフィードバック・プロセスにおいて、ｅＭＢＢデータが不正確に送信されるものと誤認し、その結果、有用なＵＲＬＬＣデータが破棄されることがあり得る。

【発明の概要】

【発明が解決しようとする課題】

【0005】

以上に基づき、本開示は、有用なサービス・データを破棄しないような、指示情報を送るための方法、ならびにそのユーザ機器（ＵＥ）および基地局を提供する。

【課題を解決するための手段】

【0006】

本開示の実施形態の第１の態様により、ハイブリッド自動反復要求（ＨＡＲＱ）フィードバック方法が提供され、この方法は、
基地局から第１のサービス・データ送信を受信することであって、第１のサービス・データ送信のスケジュール制御データは指示情報を運び、それは、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプト(preempt)すること、または第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に示すように構成されている、受信することと、
指示情報に従って送信リソースをプリエンプトする第２のサービス・データをキャッシュに保存し、第１のサービス・データのＨＡＲＱフィードバック情報を生成することと、
そのＨＡＲＱフィードバック情報を基地局に送信することと、を含む。

【0007】

１つの実施形態において、基地局から第１のサービス・データを受信することは、
基地局から２つの第１のサービス・データ送信を受信することを含み、その２つの第１のサービス・データ送信の時間間隔は非適応型ＨＡＲＱフィードバック・モードにおける送信レイテンシよりも短く、
後の第１のサービス・データ送信のスケジュール制御データにて指示情報が運ばれ、その指示情報は、第２のサービス・データが、第１のサービス・データの送信リソースをプリエンプトすること、または第２のサービス・データが、先の第１のサービス・データ送信における第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に指示する。

【0008】

１つの実施形態において、第１のサービス・データのＨＡＲＱフィードバック情報を生成することは、
送信リソースをプリエンプトする第２のサービス・データ以外のデータの送信の成功もしくは失敗状態に基づいて、ＨＡＲＱフィードバック情報を生成すること、または、
送信リソースをプリエンプトする第２のサービス・データの送信の成功もしくは失敗状態を、送信成功と設定し、第１のサービス・データ送信におけるすべてのデータの送信の成功もしくは失敗状態に基づいてＨＡＲＱフィードバック情報を生成することを含む。

【0009】

１つの実施形態において、指示情報が、明示的または暗示的に、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすることを指示するとき、指示情報に基づいて送信リソースをプリエンプトする第２のサービス・データをキャッシュに保存し、第１のサービス・データのＨＡＲＱフィードバック情報を生成することは、
送信に失敗したデータをすべてキャッシュに保存し、保存されたデータの中から、送信に失敗した第１のサービス・データを認識し、送信に失敗した第１のサービス・データに基づいてＨＡＲＱフィードバック情報を生成することを含む。

【0010】

１つの実施形態において、指示情報が、後の第１のサービス・データ送信のスケジュール制御データにて運ばれる場合、基地局へＨＡＲＱフィードバック情報を送ることは、
非適応型ＨＡＲＱフィードバック・モードで、ＨＡＲＱフィードバック情報を、基地局へ送ることを含む。

【0011】

１つの実施形態において、第１のサービス・データ送信のスケジュール制御データは、
スクランブル化方式で、指示情報をスケジュール制御データにおける標的制御情報にスクランブル化することにより、指示情報を運ぶ。

【0012】

本開示の実施形態の第２の態様により、指示情報を送るための方法が提供され、その方法は、
第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトするか否かを判断することと、
第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトする場合は、ユーザ機器（ＵＥ）に対して第１のサービス・データ送信を送ることとを含み、ここで、第１のサービス・データ送信のスケジュール制御データは、指示情報を運び、その情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすること、を明示的または暗示的に、指示するように構成され、それにより、ＵＥが、指示情報に従って、送信リソースをプリエンプトする第２のサービス・データをキャッシュに保存し、第１のサービス・データのＨＡＲＱフィードバック情報を基地局へ送る。

【0013】

１つの実施形態において、第１のサービス・データ送信をユーザ機器（ＵＥ）へ送ることは、
２つの第１のサービス・データ送信をＵＥに送ることを含み、２つの第１のサービス・データ送信の時間間隔は非適応型ＨＡＲＱフィードバック・モードにおける送信レイテンシよりも短く、
指示情報は、後の第１のサービス・データ送信のスケジュール制御データで運ばれ、その指示情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが、先の第１のサービス・データ送信における第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示する。

【0014】

１つの実施形態において、指示情報が、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示する場合、この方法は、さらに、
ＵＥから第１のサービス・データのＨＡＲＱフィードバック情報を受信することであって、このＨＡＲＱフィードバック情報は、第２のサービス・データの送信リソース位置に対応する第２のサービス・データのＨＡＲＱフィードバック情報および別の送信リソース位置に対応する第１のサービス・データのＨＡＲＱフィードバック情報を含む、受信することと、
別の送信リソース位置に対応する第１のサービス・データのＨＡＲＱフィードバック情報に基づいて、ＵＥへの送信に失敗した第１のサービス・データを再送信することとを含む。

【0015】

１つの実施形態において、第１のサービス・データ送信のスケジュール制御データは、
スクランブル化方式で、指示情報をスケジュール制御データにおける標的制御情報にスクランブル化することにより、指示情報を運ぶ。

【0016】

本開示の実施形態の第３の態様により、ユーザ機器が提供され、このユーザ機器は、
プロセッサと、
プロセッサによって実行可能な命令を記憶するためのメモリとを含み、
プロセッサは、上記第１の実施形態によるＨＡＲＱフィードバック方法を実行する。

【0017】

本開示の実施形態の第４の態様により、基地局が提供され、この基地局は、
プロセッサと、
プロセッサによって実行可能な命令を記憶するためのメモリとを含み、
プロセッサは、上記第２の実施形態による指示情報を送るための方法を実行する。

【0018】

以上に述べた概略の説明と以下に述べる詳細な説明のいずれも、単なる例示および説明であって、本開示を制限するものではないことを理解されたい。

【図面の簡単な説明】

【0019】

【図1】本開示の例示的実施形態による、ＨＡＲＱフィードバック方法のフローチャートである。

【0020】

【図2】本開示の例示的実施形態による、指示情報を送るための方法のフローチャートである。

【0021】

【図3】本開示の例示的実施形態による、ＨＡＲＱフィードバック方法のシグナリング・フローチャートである。

【0022】

【図4】本開示の例示的実施形態による、指示情報が１つのｅＭＢＢ送信プロセスにおいて運ばれることを図示する概略図である。

【0023】

【図5】本開示の例示的実施形態による、別のＨＡＲＱフィードバック方法のシグナリング・フローチャートである。

【0024】

【図6】本開示の例示的実施形態による、指示情報が２つのｅＭＢＢ送信プロセスにおいて運ばれることを図示する概略図である。

【0025】

【図7】本開示の例示的実施形態による、ＨＡＲＱフィードバック装置のブロック図である。

【0026】

【図8】本開示の例示的実施形態による、別のＨＡＲＱフィードバック装置のブロック図である。

【0027】

【図9】本開示の例示的実施形態による、指示情報を送るための装置のブロック図である。

【0028】

【図10】本開示の例示的実施形態による、指示情報を送るための別の装置のブロック図である。

【0029】

【図11】本開示の例示的実施形態による、ＨＡＲＱフィードバックにおいて使用される装置のブロック図である。

【0030】

【図12】本開示の例示的実施形態による、指示情報を送るために使用される装置のブロック図である。

【発明を実施するための形態】

【0031】

本開示の実施形態における原理、技術的解決法、および利点を明確かつ完全に説明するために、添付の図面を用いて、本開示を、以下に、詳細に説明する。当然、記載された実施形態は、本開示の一部の実施形態にすぎず、そのすべてではない。本開示の実施形態に基づき、当業者が創造的努力を用いることなく導く、その他のすべての実施形態は、本開示の保護範囲内である。

【0032】

図１は、本開示の例示的実施形態によるＨＡＲＱフィードバック方法のフローチャートである。この実施形態は、ＵＥ側から記述される。図１に示すように、ＨＡＲＱフィードバック方法は、以下のステップを含む。

【0033】

ステップＳ１０１において、基地局からの第１のサービス・データ送信が受信され、ここで、第１のサービス・データ送信のスケジュール制御データは指示情報を運び、指示情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示する。

【0034】

この実施形態において、第１のサービスは、第２のサービスと比較して、適時性に関して、より高い要件を課すので、第１のサービス・データが第１のサービス・データをプリエンプトすることがある。第１のサービスは、ｅＭＢＢを含んでもよいが、それに限定されず、第２のサービスは、ＵＲＬＬＣを含んでもよいが、それに限定されない。

【0035】

ＵＥが基地局から１つの第１のサービス・データ送信を受信するとき、指示情報がこの１つの第１のサービス・データ送信のスケジュール制御データで運ばれてよく、指示情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示する。ＵＥが基地局から２つの第１のサービス・データ送信を受信すると、指示情報は、後の第１のサービス・データ送信のスケジュール制御データで運ばれてよく、ここで、指示情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトする、または、第２のサービス・データが先の第１のサービス・データ送信における第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示する。スケジュール制御データは、物理的ダウンリンク制御チャネル（ＰＤＣＣＨ）を含むことができるが、それに限定されるものではない。後者の場合、２つの第１のサービス・データ送信の時間間隔は非適応型ＨＡＲＱフィードバック・モードにおける送信レイテンシより短いこと、そうでないと、後の第１のサービス・データ送信のスケジュール制御データが到着する前に、ＨＡＲＱフィードバック情報が基地局に送られなければならないことに留意する必要がある。すなわち、ＵＥは、指示情報を受信する前に、ＨＡＲＱフィードバック情報を基地局に送らなければならない。

【0036】

ステップＳ１０２において、送信リソースをプリエンプトする第２のサービス・データは、指示情報に従ってキャッシュに保存され、第１のサービス・データのＨＡＲＱフィードバック情報が生成される。

【0037】

この実施形態において、送信リソースをプリエンプトする第２のサービス・データを送信するために、指示情報に従ってその第２のサービス・データをキャッシュに保管することができる。

【0038】

ＨＡＲＱフィードバック情報は、複数のやり方で生成することができる。たとえば、ＨＡＲＱフィードバック情報は、送信リソースをプリエンプトする第２のサービス・データ以外のデータの送信成功または失敗状態に基づいて、生成され得る。さらに、たとえば、送信リソースをプリエンプトする第２のサービス・データの送信成功または失敗状態が、送信成功と設定されてよく、第１のサービス・データ送信のすべてのデータの送信成功または失敗状態に従って、ＨＡＲＱフィードバック情報が生成される。

【0039】

生成されたＨＡＲＱフィードバック情報は、第１のサービス・データの送信成功または失敗状態を正確に反映し得、それにより、ＵＥの誤動作を防ぐことができる。

【0040】

ステップＳ１０３において、ＨＡＲＱフィードバック情報が、基地局へ送られる。

【0041】

この実施形態において、指示情報が、後の第１のサービス・データ送信のスケジュール制御データにて運ばれると、ＨＡＲＱフィードバック情報が、非適応型ＨＡＲＱフィードバック・モードで、基地局へ送られ得る。

【0042】

上の実施形態において、第１のサービス・データ送信で運ばれる指示情報を受信することにより、送信リソースをプリエンプトする第２のサービス・データがキャッシュに保存され、それにより、第１のサービス・データ送信時に、有用な第２のサービス・データが破棄されなくてもよい。

【0043】

図２は、本開示の例示的実施形態による、指示情報を送るための方法のフローチャートである。この実施形態は、基地局側から記述される。図２に示すように、この方法は、以下のステップを含む。

【0044】

ステップＳ２０１において、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトするか否かが判断される。

【0045】

第１のサービスはｅＭＢＢを含むことができるが、それに限定されず、第２のサービスはＵＲＬＬＣを含むことができるが、それに限定されない。第１のサービスは、第２のサービスと比較して、適時性に関して、より高い要件を課すので、第１のサービス・データが第１のサービス・データをプリエンプトすることがある。この実施形態では、基地局は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトするか否かを判断し得る。

【0046】

ステップＳ２０２では、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトする場合、第１のサービス・データ送信がＵＥに送られ、ここで、第１のサービス・データ送信のスケジュール制御データが指示情報を運び、指示情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示し、それにより、ＵＥは、第１の指示情報に基づいて、第１のサービス・データのＨＡＲＱフィードバック情報を基地局へ送る。

【0047】

この実施形態において、基地局が、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすると判定した場合、指示情報は、ＵＥに送られる第１のサービス・データ送信のスケジュール制御データにて運ばれ得る。指示情報は、明示の指示を与えるものとすることができ、たとえば、指示情報のいくつかのビットが直接追加されてもよいし、または、指示情報は、暗示の指示を与えてもよく、たとえば、スケジュール制御データにおける標的制御情報に指示情報がスクランブル化される、すなわち、対応する指示情報は、元の制御情報の一部にスクランブル化される。指示情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることを指示してよく、ここで、送信リソース位置はビットマップによって指示することができる。指示情報を受信すると、ＵＥは、指示情報に従って送信リソースをプリエンプトする第２のサービス・データをキャッシュに保存し、第１のサービス・データのＨＡＲＱフィードバック情報を基地局へ送る。

【0048】

基地局によってＵＥへ第１のサービス・データ送信を送ることは、基地局によってＵＥへ１つの第１のサービス・データ送信を送ることを含むことができる。その場合、指示情報は、その１つの第１のサービス・データ送信のスケジュール制御データで運ばれてもよく、指示情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示する。

【0049】

さらに、基地局によってＵＥへ第１のサービス・データ送信を送ることは、基地局によってＵＥへ２つの第１のサービス・データ送信を送ることをさらに含んでもよい。その場合、指示情報は、後の第１のサービス・データ送信のスケジュール制御データにて運ばれてもよく、指示情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが先の第１のサービス・データ送信における第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示する。

【0050】

スケジュール制御データは、物理的ダウンリンク制御チャネル（ＰＤＣＣＨ）を含むことができるが、それに限定されるものではない。

【0051】

後者の場合、２つの第１のサービス・データ送信の時間間隔は非適応型ＨＡＲＱフィードバック・モードにおける送信レイテンシより短いこと、そうでないと、後の第１のサービス・データ送信のスケジュール制御データが到着する前に、ＨＡＲＱフィードバック情報が基地局に送られなければならないことに留意する必要がある。すなわち、ＵＥは、指示情報を受信する前に、ＨＡＲＱフィードバック情報を基地局に送らなければならない、すなわち、ＵＥは、指示情報に基づいて誤動作を防ぐことができない。

【0052】

上の実施形態において、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすると判定された場合、指示情報を運ぶ第１のサービス・データ送信が、ＵＥに送られて、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすることがＵＥに通知され、それにより、ＵＥの誤動作を防ぐことができる。

【0053】

図３は、本開示の例示的実施形態によるＨＡＲＱフィードバック方法のシグナリング・フローチャートである。この実施形態は、ＵＥと基地局のインタラクションの視点から記述される。ＵＥと基地局のインタラクションをより明確に記述するために、この実施形態は、図４を参照して記述される。図４は、本開示の例示的実施形態により、指示情報が１つのｅＭＢＢ送信プロセスにおいて運ばれることを図示する概略図である。図４に示されるように、指示情報は、１つのｅＭＢＢデータ送信のＰＤＣＣＨにて運ばれる。図３に示されるように、ＨＡＲＱフィードバック方法は、以下のステップを含む。

【0054】

ステップＳ３０１において、基地局が、ＵＲＬＬＣデータがｅＭＢＢデータの送信リソースをプリエンプトすると判定したとき、基地局は、１つのｅＭＢＢデータ送信をＵＥに送り、ここで、ｅＭＢＢデータ送信は指示情報を運ぶ。

【0055】

指示情報は、ＵＲＬＬＣデータがｅＭＢＢデータの送信リソースをプリエンプトすること、または、ＵＲＬＬＣデータがｅＭＢＢデータの送信リソース位置をプリエンプトすることを、明示的に指示し得る。

【0056】

ステップＳ３０２において、ＵＥは、基地局から、ｅＭＢＢデータ送信を受信し、ｅＭＢＢデータ送信のＰＤＣＣＨにて運ばれた指示情報に従って、送信リソースをプリエンプトするＵＲＬＬＣデータをキャッシュに保存し、ｅＭＢＢデータのＨＡＲＱフィードバック情報を生成する。

【0057】

指示情報が、ＵＲＬＬＣデータがｅＭＢＢデータの送信リソースをプリエンプトすることを、明示的に指示する場合、ＵＥは、送信に失敗したすべてのデータをキャッシュに保存し、保存されたデータの中から、送信に失敗したｅＭＢＢデータを識別し、送信されないｅＭＢＢデータに基づいて、ＨＡＲＱフィードバック情報を生成する。

【0058】

たとえば、ＵＥは、ＮＡＣＫフィードバックを有するすべての送信リソースに対応するデータをキャッシュに保存してよく、データを消去しなくてよい。ＵＲＬＬＣのすべてのデータが送信された後、保存されたデータ内の有用なＵＲＬＬＣデータが使用される。使用されたデータのほかにさらに一部のデータが残っている場合は、そのデータが実際には送信に失敗したデータであることを示し、ＵＥは、そのデータに基づいて、ＨＡＲＱフィードバック情報を計算することができる。

【0059】

指示情報が、ＵＲＬＬＣデータがｅＭＢＢデータの送信リソース位置をプリエンプトすることを、明示的に指示するとき、ＵＥは、ＵＲＬＬＣデータを送信するために、送信リソースをプリエンプトするＵＲＬＬＣデータをキャッシュに保存してよく、ＮＡＣＫフィードバックを有する他のデータはすべて消去してよい。さらに、ＵＥは、送信リソースをプリエンプトするＵＲＬＬＣデータ以外のデータの送信成功または失敗状態に基づいてＨＡＲＱフィードバック情報を生成し得る。たとえば、ＵＥは、ＣＢＧ ４以外のコード・ブロック・グループ（ＣＢＧ）のｅＭＢＢデータの送信成功または失敗状態に基づいて、ＨＡＲＱフィードバック情報を生成し得る。

【0060】

ステップＳ３０３において、ＵＥはｅＭＢＢデータのＨＡＲＱフィードバック情報を基地局に送る。

【0061】

ステップＳ３０４において、基地局は、受信したＨＡＲＱフィードバック情報に基づいて、送信に失敗したｅＭＢＢデータをＵＥに再送信する。

【0062】

任意選択で、指示情報が、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることを指示するとき、基地局は、ＵＥから、第１のサービス・データのＨＡＲＱフィードバック情報を受信してよく、ここで、ＨＡＲＱフィードバック情報は、送信リソース位置に対応する第２のサービス・データのＨＡＲＱフィードバック情報、および、他の送信リソース位置に対応する第１のサービス・データのＨＡＲＱフィードバック情報を含み、そして、他の送信リソース位置に対応する第１のサービス・データのＨＡＲＱフィードバック情報に従って、ＵＥへの送信に失敗した第１のサービス・データを再送信する。すなわち、第１のサービス・データの再送信を決定すると、基地局は、送信リソース位置に対応する第２のサービス・データのＨＡＲＱフィードバック情報を無視し、他のリソース位置に対応する第１のサービス・データのＨＡＲＱフィードバック情報のみを考慮する。

【0063】

たとえば、基地局は、図４に示すように、ＣＢＧ ４以外のＣＢＧに対応するｅＭＢＢデータのＨＡＲＱフィードバック情報に従って、再送信するｅＭＢＢデータを決定し得る。

【0064】

上の実施形態では、ＵＥと基地局のインタラクションに基づいて、ＵＥは、ＵＲＬＬＣデータがｅＭＢＢデータの送信リソースをプリエンプトすることを認知し得、それにより、ＵＥは、ｅＭＢＢデータ送信の間に有用なＵＲＬＬＣを破棄せずともよく、ｅＭＢＢデータの送信成功または失敗状態を、正確に、基地局にフィードバックし得る。このようにして、基地局は、実際には送信に失敗したｅＭＢＢデータを再送信し得る。

【0065】

第２のサービス・データが第１のサービス・データをプリエンプトすることを判断する能力を有する基地局に関して、図３に示すようなプロセスに基づいて、ＨＡＲＱフィードバックが生成されてもよいことが留意されるべきである。ただし、そのような能力を持たない基地局に関しては、この判断は、後の第１のサービス・データ送信のＰＤＣＣＨにて運ばれる指示情報に基づいて実行され得る。指示情報は、第２のサービス・データが、第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが、先の第１のサービス・データ送信における第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示し得る。２つの第１のサービス・データ送信は、連続していても、連続していなくてもよい。

【0066】

図５は、本開示の例示的実施形態による、別のＨＡＲＱフィードバック方法のシグナリング・フローチャートである。この実施形態は、ＵＥと基地局のインタラクションの視点から記述される。ＵＥと基地局のインタラクションをより明確に説明するために、この実施形態は、図６を参照して記述される。図６に示されるように、指示情報は、後のｅＭＢＢデータ送信のＰＤＣＣＨにて運ばれ、ここで、指示情報は、先のｅＭＢＢデータ送信におけるＵＲＬＬＣデータがｅＭＢＢデータの送信リソースをプリエンプトすること、または、ＵＲＬＬＣデータがｅＭＢＢデータの送信リソース位置をプリエンプトすることを、明示的に示し得る。図５に示されているように、ＨＡＲＱフィードバック方法は、以下のステップを含む。

【0067】

ステップＳ５０１において、基地局は、２つのｅＭＢＢデータ送信をＵＥへ送り、ここで、２つの第１のサービス・データ送信の時間間隔は、非適応型ＨＡＲＱフィードバック・モードにおける送信レイテンシより短い。

【0068】

指示情報は、後の第１のサービス・データ送信のスケジュール制御データにて運ばれる。

【0069】

ステップＳ５０２において、先のｅＭＢＢデータ送信を受信すると、ＵＥは、後のｅＭＢＢデータ送信のＰＤＣＣＨを読んで、指示情報を得る。

【0070】

ステップＳ５０３において、送信リソースをプリエンプトするＵＲＬＬＣデータは、得られた指示情報に従ってキャッシュに保存され、ｅＭＢＢデータのＨＡＲＱフィードバック情報が生成される。

【0071】

ステップＳ５０３においてＨＡＲＱフィードバック情報を生成するプロセスは、ステップＳ３０２においてＨＡＲＱフィードバック情報を生成するプロセスと同じであり、本明細書ではこれ以上記述しない。

【0072】

ステップＳ５０４において、ＵＥは、ｅＭＢＢデータのＨＡＲＱフィードバック情報を、非適応型ＨＡＲＱフィードバック・モードで、基地局へ送る。

【0073】

ステップＳ５０５において、基地局は、受信したＨＡＲＱフィードバック情報に基づいて、ＵＥへの送信に失敗したｅＭＢＢデータを再送信する。

【0074】

上の実施形態において、ＵＥは、ＵＥと基地局のインタラクションに基づいて、後の第１のサービス・データ送信のスケジュール制御データから指示情報を取得して、ＵＲＬＬＣデータがｅＭＢＢデータの送信リソースをプリエンプトすることを認知することができ、その結果、ＵＥは、ｅＭＢＢデータ送信の間に有用なＵＲＬＬＣデータを破棄せずともよく、ｅＭＢＢデータの送信成功または失敗状態を、正確に、基地局にフィードバックし得る。このようにして、基地局は、実際には送信に失敗したｅＭＢＢデータを再送信し得る。

【0075】

図７は、本開示の例示的実施形態によるＨＡＲＱフィードバック装置のブロック図である。ＨＡＲＱフィードバック装置は、ＵＥに配置され、受信モジュール７１、保存モジュール７２、および送信モジュール７３を含む。

【0076】

受信モジュール７１は、第１のサービス・データ送信を基地局から受信するように構成され、第１のサービス・データ送信のスケジュール制御データが指示情報を運び、ここで、指示情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示する。

【0077】

この実施形態において、第１のサービスは、第２のサービスに比べて、より高い適時性の要件を課すので、第１のサービス・データが第１のサービス・データをプリエンプトすることがあり得る。第１のサービスはｅＭＢＢを含むことができるが、それに限定されず、第２のサービスはＵＲＬＬＣを含むことができるが、それに限定されない。

【0078】

ＵＥが１つの第１のサービス・データ送信を基地局から受信する場合、指示情報は、その１つの第１のサービス・データ送信のスケジュール制御データにて運ばれてもよく、ここで、指示情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示する。ＵＥが、２つの第１のサービス・データ送信を基地局から受信する場合、指示情報は、後の第１のサービス・データ送信のスケジュール制御データで運ばれてもよく、ここで、指示情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示する。このスケジュール制御データは、ＰＤＣＣＨを含むことができるが、それに限定されない。後者の場合には、２つの第１のサービス・データ送信の間の時間間隔は非適応型ＨＡＲＱフィードバック・モードの送信レイテンシよりも短く、そうでないと、後の第１のサービス・データ送信のスケジュール制御データが到着する前に、ＨＡＲＱフィードバック情報が基地局に送られなければならないことに留意する必要がある。すなわち、ＵＥは、指示情報を受信する前に、ＨＡＲＱフィードバック情報を基地局に送らなければならない。

【0079】

保存生成モジュール７２は、受信モジュール７１によって受信される、第１のサービス・データ送信のスケジュール制御データにて運ばれる指示情報に従って、送信リソースをプリエンプトする第２のサービス・データをキャッシュに保存し、第１のサービス・データのＨＡＲＱフィードバック情報を生成するように構成される。

【0080】

１つの実施形態において、指示情報が、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすることを、明示的または暗示的に、指示するとき、保存生成モジュール７２は、送信に失敗したすべてのデータをキャッシュに保存し、保存されたデータの中から、送信に失敗した第１のサービス・データを識別し、送信に失敗した第１のサービス・データに基づいて、ＨＡＲＱフィードバック情報を生成するように構成され得る。

【0081】

送信モジュール７３は、保存生成モジュールによって生成されたＨＡＲＱフィードバック情報を基地局へ送るように構成される。

【0082】

指示情報が、後の第１のサービス・データ送信のスケジュール制御データにて運ばれる場合、送信モジュール７３は、非適応型ＨＡＲＱフィードバック・モードで、ＨＡＲＱフィードバック情報を、基地局へ送るように構成されてもよい。

【0083】

上の実施形態において、第１のサービス・データ送信で運ばれる指示情報を受信することにより、第２のサービス・データがキャッシュ中に送信リソースをプリエンプトし、その結果、有用な第２のサービス・データが第１のサービス・データ送信の時に破棄されなくてもよい。

【0084】

図８は、本開示の例示的実施形態による、別のＨＡＲＱフィードバック装置のブロック図である。図８に示されるように、図７に図示した実施形態に基づいて、保管生成モジュール７２は、第１の生成サブモジュール７２１または第２の生成サブモジュール７２２を含んでもよい。

【0085】

第１の生成サブモジュール７２１は、送信リソースをプリエンプトする第２のサービス・データ以外のデータの送信成功または失敗状態に基づいて、ＨＡＲＱフィードバック情報を生成するように構成される。

【0086】

第２の生成サブモジュール７２２は、送信リソースをプリエンプトする第２のサービス・データの送信成功または失敗状態を、送信成功と設定し、第１のサービス・データ送信におけるすべてのデータの送信成功または失敗状態のＨＡＲＱフィードバック情報を生成するように構成される。

【0087】

このＨＡＲＱフィードバック情報は、複数のやり方で生成されてもよい。たとえば、ＨＡＲＱフィードバック情報は、送信リソースをプリエンプトする第２のサービス・データ以外のデータの送信成功または失敗状態に基づいて生成されてもよい。さらに、たとえば、送信リソースをプリエンプトする第２のサービス・データの送信成功または失敗状態が、送信成功と設定されてもよく、第１のサービス・データ送信におけるすべてのデータの送信成功または失敗状態に従って、ＨＡＲＱフィードバック情報が生成される。

【0088】

上の実施形態において、第１の生成サブモジュールまたは第２の生成サブモジュールによって生成されたＨＡＲＱフィードバック情報は、第１のサービス・データの送信成功または失敗状態を正確に反映することができ、その結果、ＵＥの誤動作を防ぐことができる。

【0089】

図９は、本開示の例示的実施形態による、指示情報を送るための装置のブロック図である。この装置は、基地局に配置され、判断モジュール９１と判定送信モジュール９２を含む。

【0090】

判断モジュール９１は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトするか否かを判断するように構成される。

【0091】

第１のサービスはｅＭＢＢを含むことができるが、それに限定されず、第２のサービスはＵＲＬＬＣを含むことができるが、それに限定されない。第１のサービスは、第２のサービスに比べて、適時性に関して高い要件を課すので、第１のサービス・データが第１のサービス・データをプリエンプトすることがあり得る。この実施形態において、基地局は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトするか否かを判定してもよい。

【0092】

判定送信モジュール９２は、判断モジュール９１が第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすると判断した場合、第１のサービス・データ送信をユーザ機器（ＵＥ）へ送り、ここで、第１のサービス・データ送信のスケジュール制御データは指示情報を運び、指示情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示し、その結果、ＵＥは、指示情報に従って、送信リソースをプリエンプトする第２のサービス・データをキャッシュに保存し、第１のサービス・データのＨＡＲＱフィードバック情報を基地局へ送る、ように構成される。

【0093】

この実施形態において、基地局が、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすると判定した場合、指示情報は、ＵＥへ送られる第１のサービス・データ送信のスケジュール制御データにて運ばれてもよい。指示情報は、明示の指示を与えるものとすることができ、たとえば、指示情報にいくつかのビットが直接付加されてもよく、または、指示情報は、暗示の指示を与えるものとすることができ、たとえば、指示情報が、スケジュール制御データにおける標的制御情報にスクランブル化される、すなわち、対応する指示情報が、元の制御情報の一部にスクランブル化される。指示情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることを指示するために用いられてもよく、ここで、送信リソース位置は、ビットマップによって指示されてもよい。ＵＥは、指示情報を受信すると、その指示情報に従って、送信リソースをプリエンプトする第２のサービス・データをキャッシュに保存して、第１のサービス・データのＨＡＲＱフィードバック情報を基地局へ送ってもよい。

【0094】

基地局によってＵＥへ第１のサービス・データ送信を送ることは、基地局によってＵＥへ１つの第１のサービス・データ送信を送ることを含んでもよい。その場合、指示情報は、その１つの第１のサービス・データ送信のスケジュール制御データで運ばれてもよく、指示情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示する。

【0095】

１つの実施形態において、判定送信モジュール９２は、２つの第１のサービス・データ送信をＵＥへ送るように構成され、ここで、２つの第１のサービス・データ送信の間の時間間隔は、非適応型ＨＡＲＱフィードバック・モードの送信レイテンシよりも短い。指示情報は、後の第１のサービス・データ送信のスケジュール制御データで運ばれ、指示情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが先の第１のサービス・データ送信における第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示する。

【0096】

上の実施形態において、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすると判定されると、指示情報を運ぶ第１のサービス・データ送信がＵＥに送られて、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすることがＵＥに通知され、それにより、ＵＥの誤動作を防ぐことができる。

【0097】

図１０は、本開示の例示的実施形態による、指示情報を送るための別の装置のブロック図である。図１０に示されるように、図９に図示された実施形態に基づいて、指示情報が、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示しているときは、装置は、受信モジュール９３と再送信モジュール９４を、さらに含んでもよい。

【0098】

受信モジュール９３は、ＵＥから第１のサービス・データのＨＡＲＱフィードバック情報を受信するように構成され、ここで、ＨＡＲＱフィードバック情報は、第２のサービス・データの送信リソース位置に対応する第２のサービス・データのＨＡＲＱフィードバック情報と、別の送信リソース位置に対応する第１のサービス・データのＨＡＲＱフィードバック情報を含む。

【0099】

再送信モジュール９４は、別の送信リソース位置に対応する第１のサービス・データのＨＡＲＱフィードバック情報に従って、ＵＥへの送信に失敗した第１のサービス・データを再送信するように構成される。

【0100】

指示情報が、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることを指示するとき、基地局は、ＵＥから第１のサービス・データのＨＡＲＱフィードバック情報を受信してもよく、ここで、ＨＡＲＱフィードバック情報は、送信リソース位置に対応する第２のサービス・データのＨＡＲＱフィードバック情報と、他の送信リソース位置に対応する第１のサービス・データのＨＡＲＱフィードバック情報を含み、他の送信リソース位置に対応する第１のサービス・データのＨＡＲＱフィードバック情報に従って、送信に失敗した第１のサービス・データをＵＥへ再送信する。すなわち、第１のサービス・データを再送信すると決定した場合、基地局は、送信リソース位置に対応する第２のサービス・データのＨＡＲＱフィードバック情報を無視し、他のリソース位置に対応する第１のサービス・データのＨＡＲＱフィードバック情報のみを考慮する。

【0101】

上の実施形態において、他の送信リソース位置に対応する、第１のサービス・データの受信したＨＡＲＱフィードバック情報に基づいて、送信に失敗した第１のサービス・データを、ＵＥへ再送信することにより、基地局は、実際に再送信されるべき第１のサービス・データを識別してもよい。

【0102】

図１１は、例示的実施形態によるＨＡＲＱフィードバックにおいて使用される装置のブロック図である。たとえば、装置１１００は、携帯電話、コンピュータ、デジタル・ブロードキャスト端末、メッセージング・デバイス、ゲーム・コンソール、タブレット・デバイス、医療用デバイス、フィットネス機器、携帯情報端末などとすることができる。

【0103】

図１１を参照すると、装置１１００は、処理コンポーネント１１０２、メモリ１１０４、電力コンポーネント１１０６、マルチメディア・コンポーネント１１０８、音声コンポーネント１１１０、入出力（Ｉ／Ｏ）インタフェース１１１２、センサ・コンポーネント１１１４、および通信コンポーネント１１１６のうちの、１つ以上のコンポーネントを含むことができる。

【0104】

処理コンポーネント１１０２は、一般的には、表示、電話通話、データ通信、カメラ動作、記録動作に関連する動作など、装置１１００の動作全体を制御する。処理コンポーネント１１０２は、上述の方法のステップの全部または一部を行う命令を実行する１つまたは複数のプロセッサ１１２０を含んでもよい。さらに、処理コンポーネント１１０２は、処理コンポーネント１１０２と他のコンポーネントの間のインタラクションを容易にする１つまたは複数のモジュールを含んでもよい。たとえば、処理コンポーネント１１０２は、マルチメディア・コンポーネント１１０８と処理コンポーネント１１０２の間のインタラクションを容易にするマルチメディア・モジュールを含んでもよい。

【0105】

メモリ１１０４は、装置１１００の動作をサポートするために各種データを記憶するように構成される。そのようなデータの例として、装置１１００上で動作するアプリケーションまたは方法のための命令、連絡先データ、電話帳データ、メッセージ、画像、動画等がある。メモリ１１０４は、静的ランダム・アクセス・メモリ（ＳＲＡＭ）、電気的消去可能プログラマブル・リードオンリ・メモリ（ＥＥＰＲＯＭ）、消去可能プログラマブル・リードオンリ・メモリ（ＥＰＲＯＭ）、プログラマブル・リードオンリ・メモリ（ＰＲＯＭ）、リードオンリ・メモリ（ＲＯＭ）、磁気メモリ、フラッシュ・メモリ、磁気または光学ディスクなど、任意の種類の揮発性もしくは非揮発性のメモリデバイス、またはそれらの組み合わせを用いて実施してもよい。

【0106】

電力コンポーネント１１０６は、装置１１００の各種コンポーネントに電力を提供する。電力コンポーネント１１０６は、装置１１００における電力管理システム、１つまたは複数の電源、ならびに発電、電力管理、および配電に関連するその他のコンポーネントを含むことができる。

【0107】

マルチメディア・コンポーネント１１０８は装置１１００とユーザの間の出力インタフェースを提供する画面を含む。いくつかの実施形態では、この画面は、液晶ディスプレイ（ＬＣＤ）とタッチ・パネル（ＴＰ）を含んでもよい。画面がタッチ・パネルを含む場合、画面は、ユーザから入力信号を受信するタッチ・スクリーンとして実装されてもよい。このタッチ・パネルは、タッチ・パネルに対するタッチ、スワイプ、およびジェスチャを感知する１つまたは複数のタッチ・センサを含む。タッチ・センサは、タッチまたはスワイプ動作の境界を感知するのみならず、タッチまたはスワイプ動作に関わる時間および圧力をも感知するものとすることができる。いくつかの実施形態では、マルチメディア・コンポーネント１１０８は、前部カメラおよび／または後部カメラを含む。前部カメラおよび後部カメラは、装置１１００が、撮影モードまたはビデオ・モードなどの、動作モードにある間、外部のマルチメディア・データを受信するものであってもよい。前部カメラと後部カメラは、各々、固定光学レンズ・システムであるか、または、焦点光学ズーム機能を有するものであってもよい。

【0108】

音声コンポーネント１１１０は、音声信号を、出力および／または入力するように構成される。たとえば、音声コンポーネント１１１０は、装置１１００が、通話モード、記録モード、およびボイス認識モードなどの動作モードにあるとき、外部の音声信号を受信するように構成されたマイクロホン（ＭＩＣ）を含む。受信された音声信号は、さらに、メモリ１１０４に格納されるか、または通信コンポーネント１１１６を介して送信されてもよい。いくつかの実施形態では、音声コンポーネント１１１０は、さらに、音声信号を出力するためのスピーカーを含む。

【0109】

Ｉ／Ｏインタフェース１１１２は、処理コンポーネント１１０２と、キーボード、クリック・ホイール、ボタンなどの周辺インタフェース・モジュールの間のインタフェースを提供する。ボタンは、ホーム・ボタン、ボリューム・ボタン、スタート・ボタン、およびロック・ボタンを含んでもよいが、それらに限定されない。

【0110】

センサ・コンポーネント１１１４は、装置１１００の様々な面のステータス評価を提供する１つまたは複数のセンサを含む。たとえば、センサ・コンポーネント１１１４は、装置１１００のオン／オフ・ステータス、装置１１００のコンポーネント同士、たとえば、ディスプレイ・デバイスとミニ・キーボード、の相対的位置を検知してもよく、また、センサ・コンポーネント１１１４は、装置１１００または装置１１００のコンポーネントの位置変化、ユーザと装置１１００の接触の有無、装置１１００の方向または加速／減速、および装置１１００の温度変化を検出してもよい。センサ・コンポーネント１１１４は、物理的接触なしに付近の物体の存在を検知するように構成された近接センサを含んでもよい。センサ・コンポーネント１１１４は、撮像アプリケーションに用いられる、ＣＭＯＳまたはＣＣＤイメージセンサなどの、光センサを含んでもよい。いくつかの実施形態では、センサ・コンポーネント１１１４はまた、加速度計センサ、ジャイロスコープ・センサ、磁気センサ、圧力センサ、または温度センサを含んでもよい。

【0111】

通信コンポーネント１１１６は、装置１１００と他のデバイスの間の有線または無線の通信を容易にするように構成される。装置１１００は、ＷｉＦｉ、２Ｇ、もしくは３Ｇ、またはそれらの組み合わせなどの通信標準に基づく無線ネットワークにアクセスすることができる。例示的実施形態において、通信コンポーネント６１６は、ブロードキャスト・チャネルを介して、外部のブロードキャスト管理システムから、ブロードキャスト信号またはブロードキャスト関連情報を受信する。例示的実施形態において、通信コンポーネント１１１６は、さらに、短距離通信を容易にする近距離無線通信（ＮＦＣ）モジュールを含む。

【0112】

例示的実施形態において、装置１１００は、１つまたは複数の特定用途向け集積回路（ＡＳＩＣ）、デジタル信号プロセッサ（ＤＳＰ）、デジタル信号処理デバイス（ＤＳＰＤ）、プログラマブル論理デバイス（ＰＬＤ）、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、コントローラ、マイクロコントローラ、マイクロプロセッサ、または、上述の方法を実行するためのその他の電子コンポーネントを用いて実装されてもよい。

【0113】

例示的実施形態において、上述の方法を実行するために、装置１１００内のプロセッサ１１２０によって実行可能な命令を含む、メモリ１１０４など、命令を含む非一時的コンピュータ可読記憶媒体も提供される。たとえば、非一時的コンピュータ可読記憶媒体は、ＲＯＭ、ＲＡＭ、ＣＤ－ＲＯＭ、磁気テープ、フロッピー・ディスク、光学データ記憶デバイスなどとすることができる。

【0114】

図１２は、本開示の例示的実施形態による、指示情報を送るために使用される装置１２００のブロック図である。装置１２００は、基地局として提供されてもよい。図１２を参照すると、装置１２００は、処理コンポーネント１２２２、無線送信／受信コンポーネント１２２４、無線アンテナ１２２６、および無線インタフェース専用の信号処理部を含む。処理コンポーネント１２２２は、さらに、１つまたは複数のプロセッサを含んでもよい。

【0115】

処理コンポーネント１２２２内の１つのプロセッサは、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトするか否かを判断し、

【0116】

第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトする場合、第１のサービス・データ送信をＵＥへ送るように構成されてもよく、第１のサービス・データ送信のスケジュール制御データは指示情報を運び、その指示情報は、第２のサービス・データが第１のサービス・データの送信リソースをプリエンプトすること、または、第２のサービス・データが第１のサービス・データの送信リソース位置をプリエンプトすることを、明示的または暗示的に、指示し、それにより、ＵＥは、指示情報に従って、送信リソースをプリエンプトする第２のサービス・データをキャッシュに保存し、第１のサービス・データのＨＡＲＱフィードバック情報を基地局へ送る。

【0117】

装置の実施形態は、方法の実施形態に実質的に対応するので、装置の実施形態の説明は簡単になされており、関連部分は、方法の実施形態の説明部分を参照して得られ得る。上述の装置の実施形態は、単に、例示のみを目的とするものである。別個のコンポーネントとして記述されているユニットは、物理的に分離されていても、物理的に分離されていなくてもよく、ユニットとして示されているコンポーネントは、物理的なユニットであっても、そうでなくてもよい、すなわち、コンポーネントは、同じ位置に配置されてもよく、複数のネットワーク・ユニットに分散されていてもよい。モジュールの一部または全部が、実施形態の技術的解決法の目的を達成するために、実際のニーズに従って選択されてもよい。当業者は、創造的努力を要せずに、本開示を理解し、実施できる。

【0118】

本明細書において、「第１の」および「第２の」のような関係性を表す用語は、あるエンティティまたは動作を別のエンティティまたは動作と区別するためにのみ用いられ、それらのエンティティまたは動作の間に実際上の関係または順序があることを要求する、または意味する意図はないことに留意されたい。本明細書において、「備える」、「備えている」、「有する」、「有している」、「含む」、「含んでいる」、「内包する」、「内包している」、またはそれらの変形は、非排他的包含を意味することが意図されており、したがって、要素のリストを備える、有する、含む、包含するプロセス、方法、物品、またはデバイスは、それらの要素のみを含むのではなく、そのプロセス、方法、物品、またはデバイスに明示的に列挙されていないかまたは固有ではない、その他の要素を含んでもよいことに留意されたい。「～を備える」、「～を有する」、「～を含む」、「～を内包する」という語句が後に続く要素は、さらに制約がなければ、当該プロセス、方法、物品、または装置に、同じ要素が追加されて存在することを妨げるものではない。

【0119】

本開示による方法および装置は、以上に詳細に説明され、本開示の原理および実施形態は、具体的な実施形態および例を参照して説明されているが、上述の実施形態は、本開示の方法および中核的思想の理解を助けるためにのみ記述されたものである。当業者は、本開示の概念に従って、具体的な実施形態または適用の範囲に修正または変形を加えることができる。結論として、本明細書は、本開示を限定するものと理解されてはならない。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】