▶ フラウンホーファー−ゲゼルシャフト・ツール・フェルデルング・デル・アンゲヴァンテン・フォルシュング・アインゲトラーゲネル・フェラインの特許一覧
特表2022-544617サイドリンク通信におけるＰＳＦＣＨ報告をサポートするための手順
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2022-10-19
(54)【発明の名称】サイドリンク通信におけるＰＳＦＣＨ報告をサポートするための手順
(51)【国際特許分類】
H04W 72/04 20090101AFI20221012BHJP
H04W 28/04 20090101ALI20221012BHJP
H04W 92/18 20090101ALI20221012BHJP
【ＦＩ】
H04W72/04 136
H04W28/04 110
H04W92/18
【審査請求】有
【予備審査請求】未請求
(21)【出願番号】P 2022510072
(86)(22)【出願日】2020-08-07
(85)【翻訳文提出日】2022-04-15
(86)【国際出願番号】 EP2020072261
(87)【国際公開番号】W WO2021032509
(87)【国際公開日】2021-02-25
(31)【優先権主張番号】19192133.7
(32)【優先日】2019-08-16
(33)【優先権主張国・地域又は機関】EP
(81)【指定国・地域】
(71)【出願人】
【識別番号】500341779
【氏名又は名称】フラウンホーファー－ゲゼルシャフト・ツール・フェルデルング・デル・アンゲヴァンテン・フォルシュング・アインゲトラーゲネル・フェライン
(74)【代理人】
【識別番号】100134119
【弁理士】
【氏名又は名称】奥町 哲行
(72)【発明者】
【氏名】フェレンバッハ・トーマス
(72)【発明者】
【氏名】ヘルゲ・コーネリアス
(72)【発明者】
【氏名】ヴィルト・トーマス
(72)【発明者】
【氏名】シエル・トーマス
(72)【発明者】
【氏名】ゼルバネザン・ザルン
(72)【発明者】
【氏名】ゴックティーペ・バリス
【テーマコード（参考）】
5K067
【Ｆターム（参考）】
5K067HH28
(57)【要約】
無線通信ネットワークで送信された送信済メッセージの受信を確認応答するためのフィードバックリソースを提供するフィードバックチャネルを備えるように動作するように構成されたデバイスは、特定のフィードバックリソースを使用して第１のフィードバックメッセージを送信することにより、受信メッセージ、例えばＰＳＳＣＨの制御メッセージを確認応答し、確認応答送信を待つものである。デバイスは、同じまたは別の特定のフィードバックリソースの使用によって送信された第２の確認応答メッセージの受信を待つように構成される。デバイスは、第２のフィードバックメッセージを受信するために、第１のフィードバックメッセージの送信を延期または省略するように構成される。
【特許請求の範囲】
【請求項1】
無線通信ネットワークにおいて動作するように構成されたデバイスであって、前記無線通信ネットワークにおいて送信された送信済メッセージの受信を確認応答するためのフィードバックリソースを提供するフィードバックチャネルを備えるように動作し、前記デバイスは、特定のフィードバックリソースを使用して第１のフィードバックメッセージを送信することにより、受信メッセージ、例えばＰＳＳＣＨの制御メッセージを確認応答し、確認応答送信を待つものであり、
前記デバイスは、同じまたは別の特定のフィードバックリソースの使用によって送信された第２の確認応答メッセージの受信を待つように構成され、
前記デバイスは、前記第２のフィードバックメッセージを受信するために、前記第１のフィードバックメッセージの送信を延期または省略するように構成されている、デバイス。
【請求項2】
前記第１および第２のフィードバックメッセージは、同じ時間間隔（例えばＴＴＩまたはスロット）内で送受信される、請求項１に記載のデバイス。
【請求項3】
前記第１および第２のフィードバックリソースは、同じ時間間隔（例えばＴＴＩまたはスロット）内で送受信される、請求項１または２に記載のデバイス。
【請求項4】
前記デバイスは、前記第１のフィードバックメッセージが否定的なフィードバックである場合に、前記第１のフィードバックメッセージの前記送信を延期または省略するように構成されている、請求項１から３のいずれか一項に記載のデバイス。
【請求項5】
前記デバイスは、前記受信メッセージの復号の成功に応答して、前記特定のリソースを使用して前記第１のフィードバックメッセージを送信するように構成されている、請求項１から４のいずれか一項に記載のデバイス。
【請求項6】
前記デバイスは、例えば優先レベルとして示される、前記受信メッセージおよび／または前記確認応答すべきメッセージのＱｏＳ、
前記受信メッセージおよび／または前記確認応答すべきメッセージのパケットサイズ、
前記デバイスのバッファ状態、
前記デバイスのバッテリ状態、
前記デバイスの遅延バジェットおよび／または
復号結果（報告されるＨＡＲＱ結果）
のうちの少なくとも１つに基づいて、前記第１のフィードバックメッセージの送信を延期または省略するように構成されている、請求項１から５のいずれか一項に記載のデバイス。
【請求項7】
前記デバイスは、半二重方式に従って動作し、前記第１のフィードバックメッセージの送信または前記第２のフィードバックメッセージの受信のいずれかを他方よりも優先するように構成されている、請求項６に記載のデバイス。
【請求項8】
無線通信ネットワークにおいて動作するように構成されたデバイスであって、前記無線通信ネットワークにおいて送信された送信済メッセージの受信を確認応答するためのフィードバックリソースを提供するフィードバックチャネルを備えるように動作し、送信済メッセージの数は、フィードバックリソースの数と比較してより大きく、前記デバイスは、特定のフィードバックリソースを使用して第１のフィードバックメッセージを送信することにより、受信メッセージ（例えば、ＰＳＳＣＨの制御メッセージ）を確認応答し、確認応答送信を待つものであり、
前記デバイスは、前記特定のフィードバックリソースの使用によって送信された第２の確認応答メッセージを待つように構成され、
前記デバイスは、前記第１のフィードバックメッセージを送信し、前記第２のフィードバックメッセージが所定のコンテンツを含むと仮定するように構成される、デバイス。
【請求項9】
前記予め定義されたコンテンツは、否定的フィードバック（ＮＡＣＫ）である、請求項８に記載のデバイス。
【請求項10】
前記デバイスが、前記想定された否定的フィードバックに応答して前記第２のフィードバック信号の基礎であるメッセージを再送信するように構成されている、請求項９に記載のデバイス。
【請求項11】
無線通信ネットワークにおいて動作するように構成されたデバイスであって、前記無線通信ネットワークにおいて送信された送信済メッセージの受信を確認応答するためのフィードバックリソースを提供するフィードバックチャネルを備えるように動作し、送信済メッセージの数は、フィードバックリソースの数と比較してより大きく、前記ネットワークは、受信機に送信された１つまたは複数のメッセージが、結合されたフィードバックメッセージにおいて前記受信機によって確認応答されるように編成されており、
前記デバイスは、送信済メッセージについて前記ネットワークを検知し、前記送信済メッセージの受信機を決定し、フィードバック衝突を回避するために、前記検知された送信済メッセージに基づいて自身の送信のためのスロットを選択するように構成されている、デバイス。
【請求項12】
１つのリソースのための前記フィードバックメッセージの全部または一部が、異なるまたは連続する時間間隔（例えば、スロットまたはＴＴＩ）で送信済メッセージを参照している、請求項１１に記載のデバイス。
【請求項13】
フィードバック衝突を回避するために、前記送信リソースは、前記自身の送信が、前記送信済メッセージのメッセージとともに前記自身の送信の前記受信機によって確認応答されるように、および／または
前記自身の送信が、他の確認応答の前記送信と衝突することなく前記自身の送信の受信機によって確認応答されるように、
選択される、請求項１１または１２に記載のデバイス。
【請求項15】
無線通信ネットワークにおいて動作するように構成されたデバイスであって、前記無線通信ネットワークにおいて送信された送信済メッセージの受信を確認応答するためのフィードバックリソースを提供するフィードバックチャネルを備えるように動作し、送信済メッセージの数は、フィードバックリソースの数と比較してより大きく、前記ネットワークは、メッセージの送信に使用されるリソースが対応するフィードバック信号に使用されるリソースと関連付けられるように編成され、
前記デバイスは、第１の送信済メッセージの第１の受信機を決定し、第２の受信機に自身のメッセージを送信するべく、前記第１の受信機と同じリソースを使用してフィードバックメッセージも送信するために、前記自身の送信の前記受信機が使用すると予想されるリソースを回避するように構成されている、デバイス。
【請求項16】
無線通信ネットワークにおいて動作するように構成されたデバイスであって、前記無線通信ネットワークにおいて送信された送信済メッセージの受信を確認応答するためのフィードバックリソースを提供するフィードバックチャネルを備えるように動作し、送信済メッセージの数は、フィードバックリソースの数と比較してより大きく、前記ネットワークは、メッセージの送信に使用されるリソースが対応するフィードバック信号に使用されるリソースと関連付けられるように編成され、
前記デバイスは、第１の送信済メッセージの第１の受信機を決定し、前記第１の受信機に自身のメッセージを送信するために、そのフィードバックメッセージを送信するために前記第１の受信機によって使用されると見なされるリソースを使用するように構成されている、デバイス。
【請求項17】
無線通信ネットワークにおいて動作するように構成されたデバイスまたはネットワークであって、前記無線通信ネットワークにおいて送信された送信済メッセージの受信を確認応答するためのフィードバックリソースを提供するフィードバックチャネルを備えるように動作し、送信済メッセージの数は、フィードバックリソースの数と比較してより大きく、前記ネットワークは、メッセージの送信に使用されるリソースが対応するフィードバック信号に使用されるリソースと関連付けられるように編成され、
前記デバイスは、フィードバックリソース内のフィードバック信号の数を決定するものであり、別のデバイス（フィードバックの受信機または送信機）は、同じ数のフィードバック信号を決定するものである、デバイスまたはネットワーク。
【請求項18】
前記デバイスは、デフォルトとして予め構成された数のフィードバック信号を使用する、請求項１７に記載のデバイス。
【請求項19】
前記デバイスは、使用するいくつかのフィードバック信号を別のデバイスに送信する、請求項１７または１８に記載のデバイス。
【請求項20】
前記デバイスは、別のデバイスから、使用するいくつかのフィードバック信号を受信する、請求項１７から１９のいずれか一項に記載のデバイス。
【請求項21】
前記デバイスは、前記リソースプール構成の一部として前記ネットワークによってシグナリングされる前記ＰＳＦＣＨ周期性から前記フィードバックリソースの数を決定する、請求項１７から２０のいずれか一項に記載のデバイス。
【請求項22】
前記フィードバックリソースの数は、前記ＰＳＦＣＨ周期性に等しい、請求項２１に記載のデバイス。
【請求項23】
前記フィードバック信号の数が前記送信の数または前記関連する送信リソースもしくは関連するスロットの数よりも少ない場合、前記デバイスはフィードバック低減動作を実行する、請求項１７から２２のいずれか一項に記載のデバイス。
【請求項24】
前記フィードバック低減動作はＡＮＤ動作である、請求項２３に記載のデバイス。
【請求項25】
前記デバイスが送受信機である、請求項１から２４のいずれか一項に記載のデバイス。
【請求項26】
ユーザ機器と、移動型または非移動型の基地局と、
移動型端末と、
固定端末と、
セルラーＩｏＴ－ＵＥと、
車両用ＵＥと、
グループリーダＵＥ（ＧＬ）と、
ＩｏＴまたは狭帯域ＩｏＴ、ＮＢ－ＩｏＴ、デバイスと、
地上ベースの車両と、
航空機と、
ドローンと、
移動基地局と、
路側ユニット（ＲＳＵ）と、
建物と、
前記無線通信ネットワークを使用してアイテム／デバイスが通信することを可能にするネットワーク接続性を備えた任意の他のアイテムまたはデバイス、例えば、センサまたはアクチュエータと、
のうち少なくとも１つを備えている、請求項１から２５のいずれか一項に記載のデバイス。
【請求項27】
本開示および／または特許請求の範囲による特徴の任意の組み合わせを含むデバイス。
【請求項28】
無線通信ネットワークにおいて送信済メッセージの受信を確認応答するためのフィードバックリソースを提供するフィードバックチャネルを備えるように動作している無線通信ネットワークであって、前記フィードバックリソースによって有効化されたフィードバックメッセージの数と比較した場合、メッセージの数がより多く、前記ネットワークは、請求項１から２７のいずれか一項に記載の少なくとも２つのデバイスを含む、無線通信ネットワーク。
【請求項29】
１つまたは複数の基地局をさらに備えている、請求項２８に記載の無線通信ネットワーク。
【請求項30】
前記少なくとも１つの基地局は、移動型基地局または非移動型基地局として実現され、マクロセル基地局と、
スモールセル基地局と、
基地局の中央ユニットと、
基地局の分散ユニットと、
路側ユニットと、
ＵＥと、
グループリーダ（ＧＬ）と、
リレーと、
遠隔無線ヘッドと、
ＡＭＦと、
ＳＭＦと、
コアネットワークエンティティと、
移動型エッジコンピューティングエンティティと、
ＮＲまたは５Ｇコアコンテキストのようなネットワークスライスと、
アイテムまたはデバイスが前記無線通信ネットワークを使用して通信することを可能にする任意の送受信ポイントＴＲＰであって、前記アイテムまたはデバイスが前記無線通信ネットワークを使用して通信するためのネットワーク接続性を備えている、任意の送受信ポイントと、
のうちの１つまたは複数を備えている、請求項２９に記載の無線通信ネットワーク。
【請求項31】
無線通信ネットワークにおいて送信された送信済メッセージの受信を確認するためのフィードバックリソースを提供するフィードバックチャネルを備えるように動作している無線通信ネットワークにおいて動作するようにデバイスを動作させるための方法であって、前記方法は、特定のフィードバックリソースを使用して第１のフィードバックメッセージを送信することによって、受信メッセージ、例えばＰＳＳＣＨの制御メッセージを確認応答するステップと、
確認送信を待つステップと、
同じまたは別の特定のフィードバックリソースの使用によって送信された第２の確認応答メッセージの受信を待つステップと、
前記第２のフィードバックメッセージを受信するために、前記第１のフィードバックメッセージの送信を延期するか、または省略するステップと、を含む、方法。
【請求項32】
無線通信ネットワークにおいて送信された送信済メッセージの受信を確認するためのフィードバックリソースを提供するフィードバックチャネルを備えるように動作している前記無線通信ネットワークにおいて動作するようにデバイスを動作させるための方法であって、送信済メッセージの数は、フィードバックリソースの数と比較してより大きく、前記方法は、特定のフィードバックリソースを使用して第１のフィードバックメッセージを送信することにより、受信メッセージ（例えば、ＰＳＳＣＨの制御メッセージ）を確認応答するステップと、
確認送信を待つステップと
前記特定のフィードバックリソースの使用によって送信される第２の確認応答メッセージを待つステップと、
前記第１のフィードバックメッセージを送信するステップと、前記第２のフィードバックメッセージが所定のコンテンツを含むと仮定するステップと、を含む、方法。
【請求項33】
無線通信ネットワークにおいて送信された送信済メッセージの受信を確認するためのフィードバックリソースを提供するフィードバックチャネルを備えるように動作している前記無線通信ネットワークにおいて動作するようにデバイスを動作させるための方法であって、送信済メッセージの数は、フィードバックリソースの数と比較してより大きく、前記方法は、受信機に送信される１または複数のメッセージが、結合されたフィードバックメッセージにおいて前記受信機によって確認応答されるように、前記ネットワークを編成するステップと、
前記送信済メッセージについて前記ネットワークを検知し、前記送信済メッセージの受信機を決定し、フィードバック衝突を回避するために、前記検知された送信済メッセージに基づいて自身の送信のためのスロットを選択するために、前記デバイスを動作させるステップと、を含む、方法。
【請求項34】
無線通信ネットワークにおいて送信された送信済メッセージの受信を確認するためのフィードバックリソースを提供するフィードバックチャネルを備えるように動作している前記無線通信ネットワークにおいて動作するようにデバイスを動作させるための方法であって、送信済メッセージの数は、フィードバックリソースの数と比較してより大きく、前記方法は、メッセージの送信に用いられるリソースが対応するフィードバック信号に用いられるリソースと関連付けられるように前記ネットワークを編成するステップと、
第１の送信済メッセージの第１の受信機を決定し、第２の受信機に自身のメッセージを送信するべく、前記第１の受信機と同じリソースを使用してフィードバックメッセージも送信するために、自身の送信の前記受信機が使用すると予想されるリソースを回避するように前記デバイスを動作させるステップと、を含む、方法。
【請求項35】
無線通信ネットワークにおいて送信された送信済メッセージの受信を確認するためのフィードバックリソースを提供するフィードバックチャネルを備えるように動作している前記無線通信ネットワークにおいて動作するようにデバイスを動作させるための方法であって、送信済メッセージの数は、フィードバックリソースの数と比較してより大きく、前記方法は、メッセージの送信に用いられるリソースが対応するフィードバック信号に用いられるリソースと関連付けられるようにネットワークを編成するステップと、
第１の送信済メッセージの第１の受信機を決定し、前記第１の受信機に自身のメッセージを送信するべく、そのフィードバックメッセージを送信するために前記第１の受信機によって使用されると見なされるリソースを使用するように前記デバイスを動作させるステップと、を含む、方法。
【請求項36】
無線通信ネットワークにおいて送信された送信済メッセージの受信を確認するためのフィードバックリソースを提供するフィードバックチャネルを備えるように動作している前記無線通信ネットワークにおいて動作するようにデバイスを動作させるための方法であって、送信済メッセージの数は、フィードバックリソースの数と比較してより大きく、前記方法は、メッセージの送信に用いられるリソースが対応するフィードバック信号に用いられるリソースと関連付けられるように前記ネットワークを編成するステップと、
フィードバックリソース内のいくつかのフィードバック信号に前記デバイスを動作させ、同じ数のフィードバック信号を決定するために別のデバイス（フィードバックの受信機または送信機）を動作させるステップと、を含む、方法。
【請求項37】
コンピュータ上で実行されると、請求項３１から３６のいずれか一項に記載の方法を実行するためのプログラムコードを有するコンピュータプログラムが格納された、コンピュータ可読デジタル記憶媒体。【発明の詳細な説明】
【技術分野】
【0001】
【背景技術】
【0002】
図１は、図１（ａ）に示すように、コアネットワーク１０２と、１つまたは複数の無線アクセスネットワークＲＡＮ１、ＲＡＮ２、．．．ＲＡＮＮとを含む地上無線ネットワーク１００の一例の概略図である。図１（ｂ）は、１つまたは複数の基地局ｇＮＢ１～ｇＮＢ５を含み得る無線アクセスネットワークＲＡＮｎの一例の概略図であり、各々は、それぞれのセル１０６１～１０６５によって概略的に表される、基地局を取り囲む特定のエリアにサービスする。基地局は、セル内のユーザにサービスを提供するために提供される。基地局ＢＳという用語は、５ＧネットワークにおけるｇＮＢ、ＵＭＴＳ／ＬＴＥ／ＬＴＥ－Ａ／ＬＴＥ－Ａ ＰｒｏにおけるｅＮＢ、または他の移動通信規格における単なるＢＳを指す。ユーザは、固定型デバイスまたは移動型デバイスであってもよい。無線通信システムはまた、基地局またはユーザに接続する移動型または固定型ＩｏＴデバイスによってアクセスされてもよい。移動型デバイスまたはＩｏＴデバイスは、物理デバイス、ロボットまたは車などの地上ベースの車両、有人航空機または無人航空機（ｕｎｍａｎｎｅｄ ａｅｒｉａｌ ｖｅｈｉｃｌｅｓ：ＵＡＶ）などの航空機（後者はドローンとも呼ばれる）、建物、および電子機器、ソフトウェア、センサ、アクチュエータなどが組み込まれた他のアイテムまたはデバイス、ならびにこれらのデバイスが既存のネットワークインフラストラクチャにわたってデータを収集および交換することを可能にするネットワーク接続を含み得る。図１（ｂ）は、５つのセルの例示的な図を示しているが、ＲＡＮｎは、より多くの、またはより少ないそのようなセルを含んでもよく、ＲＡＮｎは、ただ１つの基地局を含んでもよい。図１（ｂ）は、セル１０６２内にあり、基地局ｇＮＢ２によってサービスされる、ユーザ機器（ｕｓｅｒ ｅｑｕｉｐｍｅｎｔ：ＵＥ）とも呼ばれる２人のユーザＵＥ１およびＵＥ２を示す。基地局ｇＮＢ４によってサービスされるセル１０６４に別のユーザＵＥ３が示されている。矢印１０８１、１０８２、および１０８３は、ユーザＵＥ１、ＵＥ２、およびＵＥ３から基地局ｇＮＢ２、ｇＮＢ４にデータを送信するための、または基地局ｇＮＢ２、ｇＮＢ４からユーザＵＥ１、ＵＥ２、ＵＥ３にデータを送信するためのアップリンク／ダウンリンク接続を概略的に表す。さらに、図１（ｂ）は、セル１０６４内の２つのＩｏＴデバイス１１０１および１１０２を示しており、これらは固定型デバイスまたは移動型デバイスであってもよい。ＩｏＴデバイス１１０１は、矢印１１２１によって概略的に表されるように、基地局ｇＮＢ４を介して無線通信システムにアクセスしてデータを送受信する。ＩｏＴデバイス１１０２は、矢印１１２２によって概略的に表されるように、ユーザＵＥ３を介して無線通信システムにアクセスする。それぞれの基地局ｇＮＢ１～ｇＮＢ５は、例えばＳ１インターフェースを介して、それぞれのバックホールリンク１１４１～１１４５を介してコアネットワーク１０２に接続されてもよく、これらは図１（ｂ）では「コア」を指す矢印によって概略的に表されている。コアネットワーク１０２は、１つまたは複数の外部ネットワークに接続されてもよい。さらに、それぞれの基地局ｇＮＢ１～ｇＮＢ５の一部または全部は、例えば、ＮＲ内のＳ１もしくはＸ２インターフェースまたはＸＮインターフェースを介して、それぞれのバックホールリンク１１６１～１１６５を介して互いに接続することができ、これらは図１（ｂ）では「ｇＮＢ」を指す矢印によって概略的に表されている。
【0003】
データ送信のために、物理リソースグリッドが使用され得る。物理リソースグリッドは、様々な物理チャネルおよび物理信号がマッピングされるリソース要素のセットを含み得る。例えば、物理チャネルは、ダウンリンク、アップリンク、およびサイドリンクペイロードデータとも呼ばれるユーザ固有のデータを搬送する物理ダウンリンク共有チャネル、物理アップリンク共有チャネル、および物理サイドリンク共有チャネル（ｐｈｙｓｉｃａｌ ｄｏｗｎｌｉｎｋ ｓｈａｒｅｄ ｃｈａｎｎｅｌｓ：ＰＤＳＣＨ、ｐｈｙｓｉｃａｌ ｕｐｌｉｎｋ ｓｈａｒｅｄ ｃｈａｎｎｅｌｓ：ＰＵＳＣＨ、ｐｈｙｓｉｃａｌ ｓｉｄｅｌｉｎｋ ｓｈａｒｅｄ ｃｈａｎｎｅｌｓ：ＰＳＳＣＨ）、例えばマスタ情報ブロック（ｍａｓｔｅｒ ｉｎｆｏｒｍａｔｉｏｎ ｂｌｏｃｋ：ＭＩＢ）およびシステム情報ブロック（ｓｙｓｔｅｍ ｉｎｆｏｒｍａｔｉｏｎ ｂｌｏｃｋ：ＳＩＢ）を搬送する物理ブロードキャストチャネル（ｐｈｙｓｉｃａｌ ｂｒｏａｄｃａｓｔ ｃｈａｎｎｅｌ：ＰＢＣＨ）、例えばダウンリンク制御情報（ｄｏｗｎｌｉｎｋ ｃｏｎｔｒｏｌ ｉｎｆｏｒｍａｔｉｏｎ：ＤＣＩ）、アップリンク制御情報（ｕｐｌｉｎｋ ｃｏｎｔｒｏｌ ｉｎｆｏｒｍａｔｉｏｎ：ＵＣＩ）、およびサイドリンク制御情報（ｓｉｄｅｌｉｎｋ ｃｏｎｔｒｏｌ ｉｎｆｏｒｍａｔｉｏｎ：ＳＣＩ）を搬送する物理ダウンリンク制御チャネル、物理アップリンク制御チャネル、および物理サイドリンク制御チャネル（ｐｈｙｓｉｃａｌ ｄｏｗｎｌｉｎｋ ｃｏｎｔｒｏｌ ｃｈａｎｎｅｌｓ：ＰＤＣＣＨ、ｐｈｙｓｉｃａｌ ｕｐｌｉｎｋ ｃｏｎｔｒｏｌ ｃｈａｎｎｅｌｓ：ＰＵＣＣＨ、ｐｈｙｓｉｃａｌ ｓｉｄｅｌｉｎｋ ｃｏｎｔｒｏｌ ｃｈａｎｎｅｌｓ：ＰＳＳＣＨ）を含み得る。アップリンクの場合、物理チャネルは、ＵＥがＭＩＢとＳＩＢを同期して取得すると、ネットワークにアクセスするためにＵＥによって使用される物理ランダムアクセスチャネル（ｐｈｙｓｉｃａｌ ｒａｎｄｏｍ ａｃｃｅｓｓ ｃｈａｎｎｅｌ：ＰＲＡＣＨまたはＲＡＣＨ）をさらに含み得る。物理信号は、基準信号またはシンボル（ｒｅｆｅｒｅｎｃｅ ｓｉｇｎａｌｓ ｏｒ ｓｙｍｂｏｌｓ：ＲＳ）、同期信号などを含み得る。リソースグリッドは、時間領域において特定の持続時間を有し、周波数領域において所与の帯域幅を有するフレームまたは無線フレームを備え得る。フレームは、所定の長さ、例えば１ｍｓの所定数のサブフレームを有し得る。各サブフレームは、サイクリックプレフィックス（ｃｙｃｌｉｃ ｐｒｅｆｉｘ：ＣＰ）長に応じて１２または１４個のＯＦＤＭシンボルの１つまたは複数のスロットを含むことができ、これは特定の帯域幅部分（ｂａｎｄｗｉｄｔｈ ｐａｒｔ：ＢＷＰ）に使用されるヌメロロジに依存し得る。例えば、１５ｋＨｚのサブキャリア間隔（ｓｕｂｃａｒｒｉｅｒ ｓｐａｃｉｎｇ：ＳＣＳ）を有するスロット持続時間は１ｍｓであり得、スロット持続時間は、３０ｋＨｚのＳＣＳでは０．５ｍｓに、または６０ｋＨｚのＳＣＳでは０．２５ｍｓに減少する。フレームはまた、例えば、短縮された送信時間間隔（ｓｈｏｒｔｅｎｅｄ ｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｅ ｉｎｔｅｒｖａｌｓ：ｓＴＴＩ）を利用する場合には、より少数のＯＦＤＭシンボルで構成されてもよく、またはわずか数個のＯＦＤＭシンボルを含むミニスロット／非スロットベースのフレーム構造で構成されてもよい。
【0004】
無線通信システムは、直交周波数分割多重（ｏｒｔｈｏｇｏｎａｌ ｆｒｅｑｕｅｎｃｙ－ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅｘｉｎｇ：ＯＦＤＭ）システム、直交周波数分割多元接続（ｏｒｔｈｏｇｏｎａｌ ｆｒｅｑｕｅｎｃｙ－ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ：ＯＦＤＭＡ）システム、またはＣＰの有無にかかわらず他のＩＦＦＴベースの信号、例えばＤＦＴ－ｓ－ＯＦＤＭのような、周波数分割多重を使用する任意のシングルトーンまたはマルチキャリアシステムであってもよい。多元接続のための非直交波形のような他の波形、例えばフィルタバンクマルチキャリア（ｆｉｌｔｅｒ－ｂａｎｋ ｍｕｌｔｉｃａｒｒｉｅｒ：ＦＢＭＣ）、一般化周波数分割多重化（ｇｅｎｅｒａｌｉｚｅｄ ｆｒｅｑｕｅｎｃｙ ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅｘｉｎｇ：ＧＦＤＭ）またはユニバーサルフィルタマルチキャリア（ｕｎｉｖｅｒｓａｌ ｆｉｌｔｅｒｅｄ ｍｕｌｔｉ ｃａｒｒｉｅｒ：ＵＦＭＣ）が使用されてもよい。無線通信システムは、例えば、ＬＴＥ高度ｐｒｏ規格または５ＧもしくはＮＲ（Ｎｅｗ Ｒａｄｉｏ：新規の無線）規格に従って動作することができる。
【0005】
図１に示された無線ネットワークまたは通信システムは、別個のオーバーレイネットワークを有する異種ネットワーク、例えば、基地局ｇＮＢ１～ｇＮＢ５のようなマクロ基地局を含む各マクロセルを有するマクロセルのネットワーク、およびフェムトまたはピコ基地局のようなスモールセル基地局（図１には示されていない）のネットワークによってもよい。
【0006】
上述の地上無線ネットワークに加えて、衛星のような宇宙用送受信機、および／または無人航空機システムのような空中送受信機を含む非地上無線通信ネットワークも存在する。非地上波無線通信ネットワークまたはシステムは、例えば、ＬＴＥ－高度Ｐｒｏ規格または５ＧもしくはＮＲの新規の無線規格に従って、図１を参照して上述した地上波システムと同様に動作することができる。
【0007】
移動通信ネットワーク、例えば図１を参照して上述したようなネットワークでは、ＬＴＥまたは５Ｇ／ＮＲネットワークのように、例えばＰＣ５インターフェースを使用して、１つまたは複数のサイドリンク（ｓｉｄｅｌｉｎｋ：ＳＬ）チャネルを介して互いに直接通信するＵＥが存在し得る。サイドリンクを介して互いに直接通信するＵＥは、他の車両と直接通信する車両（Ｖ２Ｖ通信）、無線通信ネットワークの他のエンティティと通信する車両（Ｖ２Ｘ通信）、例えば、信号機、交通標識、または歩行者などの路側エンティティを含み得る。他のＵＥは、車両関連ＵＥでなくてもよく、上述のデバイスのいずれかを備えてもよい。そのようなデバイスはまた、ＳＬチャネルを使用して互いに直接通信することができる（Ｄ２Ｄ通信）。
【0008】
サイドリンクを介して互いに直接通信する２つのＵＥを考慮すると、両方のＵＥは同じ基地局によってサービスされてもよく、その結果、基地局はＵＥにサイドリンクリソース割り当て構成または支援を提供することができる。例えば、両方のＵＥは、図１に示された基地局のうちの１つのように、基地局のカバレッジエリア内にあり得る。これは、「カバレッジ内」シナリオと呼ばれる。別のシナリオは、「カバレッジ外」シナリオと呼ばれる。「カバレッジ外」は、２つのＵＥが図１に示されたセルのうちの１つの中にないことを意味するのではなく、むしろ、これらのＵＥが、
【0009】
ＵＥが基地局からいかなるサイドリンクリソース割り当て構成または支援も受信しないように、基地局に接続されていなくてもよく、例えば、ＲＲＣ接続状態にない、および／または
【0010】
基地局に接続されていてもよいが、１つまたは複数の理由で、基地局はＵＥにサイドリンクリソース割り当て構成または支援を提供しなくてもよい、および／または
ＮＲ Ｖ２Ｘサービスをサポートしていない可能性がある基地局、例えばＧＳＭ、ＵＭＴＳ、ＬＴＥ基地局に接続され得る、
ことを意味する。
ＮＲ Ｖ２Ｘサービスをサポートしていない可能性がある基地局、例えばＧＳＭ、ＵＭＴＳ、ＬＴＥ基地局に接続され得る、
ことを意味する。
【0011】
例えばＰＣ５インターフェースを使用して、サイドリンクを介して互いに直接通信する２つのＵＥを考慮する場合、ＵＥの一方はＢＳと接続されてもよく、サイドリンクインターフェースを介してＢＳから他方のＵＥに情報を中継してもよい。中継は、同一の周波数帯で行われてもよいし（帯域内中継）、他の周波数帯が使用されてもよい（帯域外中継）。第１のケースでは、Ｕｕ上およびサイドリンク上の通信は、時分割複信ＴＤＤシステムのように、異なるタイムスロットを使用して分離され得る。
【0012】
図２は、互いに直接通信する２つのＵＥが両方とも基地局に接続されるカバレッジ内シナリオの概略図である。基地局ｇＮＢは、円２００によって概略的に表されるカバレッジエリアを有し、これは基本的に、図１に概略的に表されたセルに対応する。互いに直接通信するＵＥは、基地局ｇＮＢのカバレッジエリア２００の両方に第１の車両２０２および第２の車両２０４を含む。両方の車両２０２、２０４は、基地局ｇＮＢに接続され、さらに、ＰＣ５インターフェースを介して互いに直接接続される。Ｖ２Ｖトラフィックのスケジューリングおよび／または干渉管理は、基地局とＵＥとの間の無線インターフェースであるＵｕインターフェース上の制御シグナリングを介してｇＮＢによって支援される。言い換えれば、ｇＮＢは、ＵＥにＳＬリソース割り当て構成または支援を提供し、ｇＮＢは、サイドリンクを介したＶ２Ｖ通信に使用されるリソースを割り当てる。この構成は、ＮＲ Ｖ２Ｘにおけるモード１構成またはＬＴＥ Ｖ２Ｘにおけるモード３構成とも呼ばれる。
【0013】
図３は、無線通信ネットワークのセル内に物理的にあってもよいが、互いに直接通信するＵＥが基地局に接続されていないか、または互いに直接通信するＵＥの一部またはすべてが基地局へのものであるが、基地局はＳＬリソース割り当て構成または支援を提供しない、カバレッジ外シナリオの概略図である。例えばＰＣ５インターフェースを使用して、サイドリンクを介して互いに直接通信する３台の車両２０６、２０８および２１０が示されている。Ｖ２Ｖトラフィックのスケジューリングおよび／または干渉管理は、車両間で実施されるアルゴリズムに基づく。この構成は、ＮＲ Ｖ２Ｘにおけるモード２構成またはＬＴＥ Ｖ２Ｘにおけるモード４構成とも呼ばれる。上述したように、カバレッジ外シナリオである図３のシナリオは、それぞれのモード４ ＵＥが基地局のカバレッジ２００の外にあることを必ずしも意味するものではなく、むしろ、それぞれのモード４ ＵＥが基地局によってサービスされておらず、カバレッジエリアの基地局に接続されておらず、または基地局に接続されているが、ＳＬリソース割り振り構成または基地局からの支援を受信しないことを意味する。したがって、図２に示すカバレッジエリア２００内では、モード３のＵＥ２０２、２０４に加えて、モード４のＵＥ２０６、２０８、２１０も存在する状況があり得る。
【0014】
車両ユーザデバイス、ＵＥ、複数のそのようなユーザデバイスの上述のシナリオでは、単にグループとも呼ばれるユーザデバイスグループを形成することができ、グループ内またはグループメンバ間の通信は、ＰＣ５インターフェースのようなユーザデバイス間のサイドリンクインターフェースを介して実行することができる。例えば、車両ユーザデバイスを使用する上述のシナリオは、車両ユーザデバイスを装備している複数の車両が、例えば遠隔運転アプリケーションによって一緒にグループ化され得る輸送産業の分野で採用され得る。複数のユーザデバイスを互いにサイドリンク通信のためにグループ化することができる他のユースケースとしては、例えば、工場自動化および配電が挙げられる。工場自動化の場合、工場内の複数の移動式または固定式機械は、ユーザデバイスを備え、例えばロボットの動き制御のように機械の動作を制御するために、サイドリンク通信のために一緒にグループ化されてもよい。配電の場合、配電グリッド内のエンティティは、システムを監視し、配電グリッドの障害および停止に対処することを可能にするために、システムの特定の領域内で、サイドリンク通信を介して互いに通信するようにグループ化され得るそれぞれのユーザデバイスを備え得る。
【0015】
当然ながら、上記のユースケースでは、サイドリンク通信はグループ内の通信に限定されない。むしろ、サイドリンク通信は、ＵＥの任意のペアのように、ＵＥのいずれかの間であってもよい。
【0016】
上記のセクションの情報は、本発明の背景の理解を高めるためのものにすぎず、したがって、当業者にすでに知られている先行技術を形成しない情報を含み得ることに留意されたい。
【発明の概要】
【発明が解決しようとする課題】
【0017】
上記から開始して、信頼できるフィードバックメッセージを提供する必要があり得る。
【課題を解決するための手段】
【0018】
この目的は、特許請求の範囲に記載の主題によって達成される。
【0019】
一実施形態によれば、動作している無線通信ネットワークにおいて動作するように構成されたデバイスは、無線通信ネットワークにおいて送信された送信済メッセージの受信を確認応答するためのフィードバックリソースを提供するフィードバックチャネルを備え、特定のフィードバックリソースを使用して第１のフィードバックメッセージを送信することにより、受信メッセージ、例えばＰＳＳＣＨの制御メッセージを確認応答するように構成される。デバイスは、確認送信を待つように構成され、デバイスは、同じまたは別の特定のフィードバックリソースの使用によって送信された第２の確認応答メッセージの受信を待つように構成され、デバイスは、第２のフィードバックメッセージを受信するために、第１のフィードバックメッセージの送信を延期または省略するように構成される。
【0020】
一実施形態によれば、無線通信ネットワークにおいて動作するように構成されたデバイスは、無線通信ネットワークにおいて送信された送信済メッセージの受信を確認応答するためのフィードバックリソースを提供するフィードバックチャネルを備えるように動作し、、送信されるメッセージの数は、フィードバックリソースの数と比較してより多く、特定のフィードバックリソースを使用して第１のフィードバックメッセージを送信することによって受信メッセージ（例えば、ＰＳＳＣＨの制御メッセージ）を確認応答するように構成され、確認送信を待つものである。デバイスは、特定のフィードバックリソースの使用によって送信された第２の確認応答メッセージを待つように構成される。デバイスは、第１のフィードバックメッセージを送信し、第２のフィードバックメッセージが所定のコンテンツを含むと仮定するように構成される。
【0021】
一実施形態によれば、無線通信ネットワークにおいて動作するように構成されたデバイスは、無線通信ネットワークにおいて送信された送信済メッセージの受信を確認応答するためのフィードバックリソースを提供するフィードバックチャネルを備えるように動作し、送信済メッセージの数は、受信機へ送信された１または複数のメッセージが結合されたフィードバックメッセージにおいて受信機によって確認応答されるように編成されたフィードバックリソースの数と比較してより多い。デバイスは、送信済メッセージのためにネットワークを検知し、送信済メッセージの受信機を決定し、フィードバックの衝突を回避するために、検知された送信済メッセージに基づいて自身の送信のためのスロットを選択するように構成される。
【0022】
一実施形態によれば、例えば、すでに送信されたメッセージに基づくリソース回避のために、無線通信ネットワークにおいて動作するように構成されたデバイスは、無線通信ネットワークにおいて送信された送信済メッセージの受信を確認応答するためのフィードバックリソースを提供するフィードバックチャネルを備えるように動作し、送信されるメッセージの数は、フィードバックリソースの数と比較してより多い。ネットワークは、メッセージの送信に使用されるリソースが対応するフィードバック信号に使用されるリソースと関連付けられるように編成される。その場合、デバイスは、第１の送信済メッセージの第１の受信機を決定するように構成され、第２の受信機に自身のメッセージを送信するために、第１の受信機と同じリソースを使用してフィードバックメッセージも送信するために、自身の送信の受信機が使用すると予想されるリソースを回避する。
【0023】
一実施形態によれば、例えば、すでに送信されたメッセージに基づくリソース回避のために、無線通信ネットワークにおいて動作するように構成されたデバイスは、無線通信ネットワークにおいて送信された送信済メッセージの受信を確認応答するためのフィードバックリソースを提供するフィードバックチャネルを備えるように動作し、送信されるメッセージの数は、フィードバックリソースの数と比較してより多い。ネットワークは、メッセージの送信に使用されるリソースが対応するフィードバック信号に使用されるリソースと関連付けられるように編成される。デバイスは、第１の送信済メッセージの第１の受信機を決定するように構成されており、第１の受信機に自身のメッセージを送信するために、そのフィードバックメッセージを送信するために第１の受信機によって使用されると見なされるリソースを使用するようにさらに構成される。
【0024】
一実施形態によれば、無線通信ネットワークにおいて動作するように構成されたデバイスは、無線通信ネットワークにおいて送信された送信済メッセージの受信を確認応答するためのフィードバックリソースを提供するフィードバックチャネルを備えるように動作し、送信済メッセージの数は、メッセージの送信に使用されるリソースが対応するフィードバック信号に使用されるリソースと関連付けられるように編成されたフィードバックリソースの数と比較してより大きい。デバイスは、フィードバックリソース内のフィードバック信号の数を決定するものであり、別のデバイス（フィードバックの受信機または送信機）は、同じ数のフィードバック信号を決定するものである。
【0025】
さらなる実施形態は、無線通信ネットワーク、デバイスを動作させるための方法、およびそのようなプログラムを有するコンピュータプログラムまたはコンピュータ可読デジタル記憶媒体に関する。
本発明の実施形態を、添付の図面を参照してさらに詳細に説明する。
本発明の実施形態を、添付の図面を参照してさらに詳細に説明する。
【図面の簡単な説明】
【0026】
【図2】互いに直接通信する２つのＵＥが両方とも基地局に接続されるカバレッジ内シナリオの概略図である。
【図3】無線通信ネットワークのセル内に物理的に存在し得るが、互いに直接通信しているＵＥが基地局に接続されていない、カバレッジ外シナリオの概略図である。
【図4a】確認応答の時間ベースのマッピングを説明するための概略図である。
【図4b】確認応答の周波数ベースのマッピングを説明するための概略図である。
【図4c】混合ベースのマッピングを説明するための概略図である。
【図4d】複数のスロットおよびサブチャネルにわたって異なるＵＥに割り当てられたリソースがある報告ウィンドウの可能な実施態様の概略図を示す。
【図5a】実施形態によるメッセージを送信するための例示的な実施規則を示す。
【図5b】実施形態によるメッセージを送信するための例示的な実施規則を示す。
【図6】実施形態によるデバイスの概略ブロック図である。
【発明を実施するための形態】
【0027】
ここで、本発明の実施形態を添付の図面を参照してより詳細に説明するが、同じまたは類似の要素には同じ参照符号が割り当てられている。
【0028】
図４ａ～図４ｃは、物理サイドリンクフィードバックチャネル（ＰＳＦＣＨ）報告ウィンドウ４００の概略図を示す。そのようなＰＳＦＣＨ報告ウィンドウ４００。図４ａには、サブチャネルによって分離された複数のスロットの複数のＰＳＳＣＨが共通確認応答４０２ａ、４０２ｂでそれぞれ確認応答され得る時間ベースのマッピングが示されている。
図４ｂには、異なるスロットの複数のリソース４０６またはＰＳＳＣＨを確認応答４０２ａ～ｃが使用され得る周波数ベースのマッピングが示されている。
図４ｂには、異なるスロットの複数のリソース４０６またはＰＳＳＣＨを確認応答４０２ａ～ｃが使用され得る周波数ベースのマッピングが示されている。
【0029】
図４ｃでは、スロット＃１について示されたように周波数ベースのマッピングと時間ベースのマッピングとを組み合わせた混合ベースのマッピングが示されており、サブチャネル２、ＳＣ２は確認応答４０２ａの使用によって確認応答され、サブチャネル１、ＳＣ１は時間ベースのマッピングについて説明したように確認応答４０２ｂの使用によって確認応答されるが、他のスロットスロットスロット＃０およびスロット＃２では、周波数ベースのマッピングのような構成が使用される。
【0030】
図４ｄは、複数のスロットおよびサブチャネル、ｓｕｂＣＨを介して異なるＵＥに割り当てられたリソースが複数の確認応答４０２にマッピングされる報告ウィンドウ４００の可能な実装形態の概略図を示し、各確認応答４０２は、例えば、確認応答４０２ｄについて示されているのと同じデバイスに対して、または確認応答４０２ｈについて示されているのとは異なるデバイスに対して、例えば確認応答４０２ｂまたはより頻繁に使用され得る。
【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】
［４］ Ｒ１－１９０８６７７，“Ｄｅｓｉｇｎ ｏｆ ＮＲ Ｖ２Ｘ Ｐｈｙｓｉｃａｌ Ｌａｙｅｒ Ｓｔｒｕｃｔｕｒｅｓ”，Ｆｒａｕｎｈｏｆｅｒ ＨＨＩ，Ｆｒａｕｎｈｏｆｅｒ ＩＩＳ，３ＧＰＰ ＲＡＮ１＃９８，Ａｕｇｕｓｔ，２０１９．
【図1(a)】
【図1(b)】
【図2】
【図3】
【図4a】
【図4b】
【図4c】
【図4d】
【図5a】
【図5b】
【図6】
【手続補正書】
【提出日】2022-04-15
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
無線通信ネットワークにおいて動作するように構成されたデバイスであって、前記無線通信ネットワークにおいて送信された送信済メッセージの受信を確認応答するためのフィードバックリソースを提供するフィードバックチャネルを備えるように動作し、前記デバイスは、特定のフィードバックリソースを使用して第１のフィードバックメッセージを送信することにより、受信メッセージ、例えばＰＳＳＣＨの制御メッセージを確認応答し、第２のフィードバックメッセージの受信を待つものであり、
前記デバイスは、同じまたは別の特定のフィードバックリソースの使用によって送信された前記第２のフィードバックメッセージの受信を待つように構成され、
前記デバイスは、前記第２のフィードバックメッセージを受信するために、前記第１のフィードバックメッセージの送信を延期または省略するように構成されている、デバイス。
【請求項2】
前記第１および第２のフィードバックメッセージは、同じ時間間隔（例えばＴＴＩまたはスロット）内で送受信される、請求項１に記載のデバイス。
【請求項3】
前記第１および第２のフィードバックリソースは、同じ時間間隔（例えばＴＴＩまたはスロット）内で送受信される、請求項１に記載のデバイス。
【請求項4】
前記デバイスは、前記第１のフィードバックメッセージが否定的なフィードバックである場合に、前記第１のフィードバックメッセージの前記送信を延期または省略するように構成されている、請求項１に記載のデバイス。
【請求項5】
前記デバイスは、前記受信メッセージの復号の成功に応答して、前記特定のリソースを使用して前記第１のフィードバックメッセージを送信するように構成されている、請求項１に記載のデバイス。
【請求項6】
前記デバイスは、例えば優先レベルとして示される、前記受信メッセージおよび／または前記確認応答すべきメッセージのＱｏＳ、
前記受信メッセージおよび／または前記確認応答すべきメッセージのパケットサイズ、
前記デバイスのバッファ状態、
前記デバイスのバッテリ状態、
前記デバイスの遅延バジェットおよび／または
復号結果（報告されるＨＡＲＱ結果）
のうちの少なくとも１つに基づいて、前記第１のフィードバックメッセージの送信を延期または省略するように構成されている、請求項１に記載のデバイス。
【請求項7】
前記デバイスは、半二重方式に従って動作し、前記第１のフィードバックメッセージの送信または前記第２のフィードバックメッセージの受信のいずれかを他方よりも優先するように構成されている、請求項６に記載のデバイス。
【請求項8】
無線通信ネットワークにおいて動作するように構成されたデバイスであって、前記無線通信ネットワークにおいて送信された送信済メッセージの受信を確認応答するためのフィードバックリソースを提供するフィードバックチャネルを備えるように動作し、送信済メッセージの数は、フィードバックリソースの数と比較してより大きく、前記デバイスは、特定のフィードバックリソースを使用して第１のフィードバックメッセージを送信することにより、受信メッセージ（例えば、ＰＳＳＣＨの制御メッセージ）を確認応答し、確認応答送信を待つものであり、
前記デバイスは、前記特定のフィードバックリソースの使用によって送信された第２の確認応答メッセージを待つように構成され、
前記デバイスは、前記第１のフィードバックメッセージを送信し、前記第２のフィードバックメッセージが所定のコンテンツを含むと仮定するように構成される、デバイス。
【請求項9】
前記予め定義されたコンテンツは、否定的フィードバック（ＮＡＣＫ）である、請求項８に記載のデバイス。
【請求項10】
前記デバイスが、前記想定された否定的フィードバックに応答して前記第２のフィードバック信号の基礎であるメッセージを再送信するように構成されている、請求項９に記載のデバイス。
【請求項11】
無線通信ネットワークにおいて動作するように構成されたデバイスであって、前記無線通信ネットワークにおいて送信された送信済メッセージの受信を確認応答するためのフィードバックリソースを提供するフィードバックチャネルを備えるように動作し、送信済メッセージの数は、フィードバックリソースの数と比較してより大きく、前記ネットワークは、受信機に送信された１つまたは複数のメッセージが、結合されたフィードバックメッセージにおいて前記受信機によって確認応答されるように編成されており、
前記デバイスは、送信済メッセージについて前記ネットワークを検知し、前記送信済メッセージの受信機を決定し、フィードバック衝突を回避するために、前記検知された送信済メッセージに基づいて自身の送信のためのスロットを選択するように構成されている、デバイス。
【請求項12】
１つのリソースのための前記フィードバックメッセージの全部または一部が、異なるまたは連続する時間間隔（例えば、スロットまたはＴＴＩ）で送信済メッセージを参照している、請求項１１に記載のデバイス。
【請求項13】
フィードバック衝突を回避するために、前記送信リソースは、前記自身の送信が、前記送信済メッセージのメッセージとともに前記自身の送信の前記受信機によって確認応答されるように、および／または
前記自身の送信が、他の確認応答の前記送信と衝突することなく前記自身の送信の受信機によって確認応答されるように、
選択される、請求項１１に記載のデバイス。
【請求項14】
無線通信ネットワークにおいて動作するように構成されたデバイスであって、前記無線通信ネットワークにおいて送信された送信済メッセージの受信を確認応答するためのフィードバックリソースを提供するフィードバックチャネルを備えるように動作し、送信済メッセージの数は、フィードバックリソースの数と比較してより大きく、前記ネットワークは、メッセージの送信に使用されるリソースが対応するフィードバック信号に使用されるリソースと関連付けられるように編成され、
前記デバイスは、第１の送信済メッセージの第１の受信機を決定し、第２の受信機に自身のメッセージを送信するべく、前記第１の受信機と同じリソースを使用してフィードバックメッセージも送信するために、前記自身の送信の前記受信機が使用すると予想されるリソースを回避するように構成されている、デバイス。
【請求項15】
無線通信ネットワークにおいて動作するように構成されたデバイスであって、前記無線通信ネットワークにおいて送信された送信済メッセージの受信を確認応答するためのフィードバックリソースを提供するフィードバックチャネルを備えるように動作し、送信済メッセージの数は、フィードバックリソースの数と比較してより大きく、前記ネットワークは、メッセージの送信に使用されるリソースが対応するフィードバック信号に使用されるリソースと関連付けられるように編成され、
前記デバイスは、第１の送信済メッセージの第１の受信機を決定し、前記第１の受信機に自身のメッセージを送信するために、そのフィードバックメッセージを送信するために前記第１の受信機によって使用されると見なされるリソースを使用するように構成されている、デバイス。
【請求項16】
無線通信ネットワークにおいて動作するように構成されたデバイスまたはネットワークであって、前記無線通信ネットワークにおいて送信された送信済メッセージの受信を確認応答するためのフィードバックリソースを提供するフィードバックチャネルを備えるように動作し、送信済メッセージの数は、フィードバックリソースの数と比較してより大きく、前記ネットワークは、メッセージの送信に使用されるリソースが対応するフィードバック信号に使用されるリソースと関連付けられるように編成され、
前記デバイスは、フィードバックリソース内のフィードバック信号の数を決定するものであり、別のデバイス（フィードバックの受信機または送信機）は、同じ数のフィードバック信号を決定するものである、デバイスまたはネットワーク。
【請求項17】
前記デバイスは、デフォルトとして予め構成された数のフィードバック信号を使用する、請求項１６に記載のデバイス。
【請求項18】
前記デバイスは、使用するいくつかのフィードバック信号を別のデバイスに送信する、請求項１６に記載のデバイス。
【請求項19】
前記デバイスは、別のデバイスから、使用するいくつかのフィードバック信号を受信する、請求項１６に記載のデバイス。
【請求項20】
前記デバイスは、前記リソースプール構成の一部として前記ネットワークによってシグナリングされる前記ＰＳＦＣＨ周期性から前記フィードバックリソースの数を決定する、請求項１６に記載のデバイス。
【請求項21】
前記フィードバックリソースの数は、前記ＰＳＦＣＨ周期性に等しい、請求項２０に記載のデバイス。
【請求項22】
前記フィードバック信号の数が前記送信の数または前記関連する送信リソースもしくは関連するスロットの数よりも少ない場合、前記デバイスはフィードバック低減動作を実行する、請求項１６に記載のデバイス。
【請求項23】
前記フィードバック低減動作はＡＮＤ動作である、請求項２２に記載のデバイス。
【請求項24】
前記デバイスが送受信機である、請求項１または８または１１または１４または１５または１６に記載のデバイス。
【請求項25】
ユーザ機器と、移動型または非移動型の基地局と、
移動型端末と、
固定端末と、
セルラーＩｏＴ－ＵＥと、
車両用ＵＥと、
グループリーダＵＥ（ＧＬ）と、
ＩｏＴまたは狭帯域ＩｏＴ、ＮＢ－ＩｏＴ、デバイスと、
地上ベースの車両と、
航空機と、
ドローンと、
移動基地局と、
路側ユニット（ＲＳＵ）と、
建物と、
前記無線通信ネットワークを使用してアイテム／デバイスが通信することを可能にするネットワーク接続性を備えた任意の他のアイテムまたはデバイス、例えば、センサまたはアクチュエータと、
のうち少なくとも１つを備えている、請求項１または８または１１または１４または１５または１６に記載のデバイス。
【請求項26】
本開示および／または特許請求の範囲による特徴の任意の組み合わせを含むデバイス。
【請求項27】
無線通信ネットワークにおいて送信済メッセージの受信を確認応答するためのフィードバックリソースを提供するフィードバックチャネルを備えるように動作している無線通信ネットワークであって、前記フィードバックリソースによって有効化されたフィードバックメッセージの数と比較した場合、メッセージの数がより多く、前記ネットワークは、請求項１から２６のいずれか一項に記載の少なくとも２つのデバイスを含む、無線通信ネットワーク。
【請求項28】
１つまたは複数の基地局をさらに備えている、請求項２７に記載の無線通信ネットワーク。
【請求項29】
前記少なくとも１つの基地局は、移動型基地局または非移動型基地局として実現され、マクロセル基地局と、
スモールセル基地局と、
基地局の中央ユニットと、
基地局の分散ユニットと、
路側ユニットと、
ＵＥと、
グループリーダ（ＧＬ）と、
リレーと、
遠隔無線ヘッドと、
ＡＭＦと、
ＳＭＦと、
コアネットワークエンティティと、
移動型エッジコンピューティングエンティティと、
ＮＲまたは５Ｇコアコンテキストのようなネットワークスライスと、
アイテムまたはデバイスが前記無線通信ネットワークを使用して通信することを可能にする任意の送受信ポイントＴＲＰであって、前記アイテムまたはデバイスが前記無線通信ネットワークを使用して通信するためのネットワーク接続性を備えている、任意の送受信ポイントと、
のうちの１つまたは複数を備えている、請求項２８に記載の無線通信ネットワーク。
【請求項30】
無線通信ネットワークにおいて送信された送信済メッセージの受信を確認するためのフィードバックリソースを提供するフィードバックチャネルを備えるように動作している無線通信ネットワークにおいて動作するようにデバイスを動作させるための方法であって、前記方法は、特定のフィードバックリソースを使用して第１のフィードバックメッセージを送信することによって、受信メッセージ、例えばＰＳＳＣＨの制御メッセージを確認応答するステップと、
第２のフィードバックメッセージの受信を待つステップと、
同じまたは別の特定のフィードバックリソースの使用によって送信された前記第２のフィードバックメッセージの受信を待つステップと、
前記第２のフィードバックメッセージを受信するために、前記第１のフィードバックメッセージの送信を延期するか、または省略するステップと、を含む、方法。
【請求項31】
無線通信ネットワークにおいて送信された送信済メッセージの受信を確認するためのフィードバックリソースを提供するフィードバックチャネルを備えるように動作している前記無線通信ネットワークにおいて動作するようにデバイスを動作させるための方法であって、送信済メッセージの数は、フィードバックリソースの数と比較してより大きく、前記方法は、特定のフィードバックリソースを使用して第１のフィードバックメッセージを送信することにより、受信メッセージ（例えば、ＰＳＳＣＨの制御メッセージ）を確認応答するステップと、
確認送信を待つステップと
前記特定のフィードバックリソースの使用によって送信される第２の確認応答メッセージを待つステップと、
前記第１のフィードバックメッセージを送信するステップと、前記第２のフィードバックメッセージが所定のコンテンツを含むと仮定するステップと、を含む、方法。
【請求項32】
無線通信ネットワークにおいて送信された送信済メッセージの受信を確認するためのフィードバックリソースを提供するフィードバックチャネルを備えるように動作している前記無線通信ネットワークにおいて動作するようにデバイスを動作させるための方法であって、送信済メッセージの数は、フィードバックリソースの数と比較してより大きく、前記方法は、受信機に送信される１または複数のメッセージが、結合されたフィードバックメッセージにおいて前記受信機によって確認応答されるように、前記ネットワークを編成するステップと、
前記送信済メッセージについて前記ネットワークを検知し、前記送信済メッセージの受信機を決定し、フィードバック衝突を回避するために、前記検知された送信済メッセージに基づいて自身の送信のためのスロットを選択するために、前記デバイスを動作させるステップと、を含む、方法。
【請求項33】
無線通信ネットワークにおいて送信された送信済メッセージの受信を確認するためのフィードバックリソースを提供するフィードバックチャネルを備えるように動作している前記無線通信ネットワークにおいて動作するようにデバイスを動作させるための方法であって、送信済メッセージの数は、フィードバックリソースの数と比較してより大きく、前記方法は、メッセージの送信に用いられるリソースが対応するフィードバック信号に用いられるリソースと関連付けられるように前記ネットワークを編成するステップと、
第１の送信済メッセージの第１の受信機を決定し、第２の受信機に自身のメッセージを送信するべく、前記第１の受信機と同じリソースを使用してそのフィードバックメッセージも送信するために、前記自身の送信の前記受信機が使用すると予想されるリソースを回避するように前記デバイスを動作させるステップと、を含む、方法。
【請求項34】
無線通信ネットワークにおいて送信された送信済メッセージの受信を確認するためのフィードバックリソースを提供するフィードバックチャネルを備えるように動作している前記無線通信ネットワークにおいて動作するようにデバイスを動作させるための方法であって、送信済メッセージの数は、フィードバックリソースの数と比較してより大きく、前記方法は、メッセージの送信に用いられるリソースが対応するフィードバック信号に用いられるリソースと関連付けられるように前記ネットワークを編成するステップと、
第１の送信済メッセージの第１の受信機を決定し、前記第１の受信機に自身のメッセージを送信するべく、フィードバックメッセージを送信するために、前記第１の受信機によって使用されると見なされるリソースを使用するように前記デバイスを動作させるステップと、を含む、方法。
【請求項35】
無線通信ネットワークにおいて送信された送信済メッセージの受信を確認するためのフィードバックリソースを提供するフィードバックチャネルを備えるように動作している前記無線通信ネットワークにおいて動作するようにデバイスを動作させるための方法であって、送信済メッセージの数は、フィードバックリソースの数と比較してより大きく、前記方法は、メッセージの送信に用いられるリソースが対応するフィードバック信号に用いられるリソースと関連付けられるようにネットワークを編成するステップと、
フィードバックリソース内のいくつかのフィードバック信号に前記デバイスを動作させるステップと、
同じ数のフィードバック信号を決定するために別のデバイス（フィードバックの受信機または送信機）を動作させるステップと、を含む、方法。
【請求項36】
コンピュータ上で実行されると、請求項３０または３１または３２または３３または３４または３５に記載の方法を実行するためのプログラムコードを有するコンピュータプログラムが格納された、コンピュータ可読デジタル記憶媒体。
【国際調査報告】