知財求人 - 知財ポータルサイト「IP Force」
▶ ミツビシ・エレクトリック・アールアンドディー・センター・ヨーロッパ・ビーヴィの特許一覧
特許7366315支援情報を提供する方法、デバイス間通信システム、第２のデバイス、コンピュータプログラム、及び処理回路
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-10-12
(45)【発行日】2023-10-20
(54)【発明の名称】支援情報を提供する方法、デバイス間通信システム、第２のデバイス、コンピュータプログラム、及び処理回路
(51)【国際特許分類】
H04W 76/14 20180101AFI20231013BHJP
H04W 92/18 20090101ALI20231013BHJP
H04W 48/16 20090101ALI20231013BHJP
H04W 4/46 20180101ALN20231013BHJP
【ＦＩ】
H04W76/14
H04W92/18
H04W48/16 132
H04W48/16 131
H04W4/46
【請求項の数】
15
(21)【出願番号】P 2023510180
(86)(22)【出願日】2021-06-25
(65)【公表番号】
(43)【公表日】2023-06-06
(86)【国際出願番号】 JP2021025535
(87)【国際公開番号】W WO2022030161
(87)【国際公開日】2022-02-10
【審査請求日】2022-10-31
(31)【優先権主張番号】20305918.3
(32)【優先日】2020-08-07
(33)【優先権主張国・地域又は機関】EP
(73)【特許権者】
【識別番号】503163527
【氏名又は名称】ミツビシ・エレクトリック・アールアンドディー・センター・ヨーロッパ・ビーヴィ
【氏名又は名称原語表記】ＭＩＴＳＵＢＩＳＨＩ ＥＬＥＣＴＲＩＣ Ｒ＆Ｄ ＣＥＮＴＲＥ ＥＵＲＯＰＥ Ｂ．Ｖ．
【住所又は居所原語表記】Ｃａｐｒｏｎｉｌａａｎ ４６， １１１９ ＮＳ Ｓｃｈｉｐｈｏｌ Ｒｉｊｋ， Ｔｈｅ Ｎｅｔｈｅｒｌａｎｄｓ
(74)【代理人】
【識別番号】100110423
【弁理士】
【氏名又は名称】曾我 道治
(74)【代理人】
【識別番号】100111648
【弁理士】
【氏名又は名称】梶並 順
(74)【代理人】
【識別番号】100122437
【弁理士】
【氏名又は名称】大宅 一宏
(74)【代理人】
【識別番号】100147566
【弁理士】
【氏名又は名称】上田 俊一
(74)【代理人】
【識別番号】100161171
【弁理士】
【氏名又は名称】吉田 潤一郎
(72)【発明者】
【氏名】チョチーナ、クリスティーナ
(72)【発明者】
【氏名】グレッセ、ニコラ
(72)【発明者】
【氏名】シェハタ、モハメド
【審査官】望月 章俊
(56)【参考文献】
【文献】国際公開第２０２０／０３３０８８（ＷＯ，Ａ１）
【文献】米国特許出願公開第２０２０／００３７３４３（ＵＳ，Ａ１）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｈ０４Ｗ４／００－Ｈ０４Ｗ９９／００
Ｈ０４Ｂ７／２４－Ｈ０４Ｂ７／２６
３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１－４
ＳＡ ＷＧ１－４
ＣＴ ＷＧ１、４
(57)【特許請求の範囲】
【請求項1】
デバイス間通信システムにおいて第１のデバイスと第２のデバイスのターゲットグループとの間の少なくとも１つの通信チャネルの品質に関する支援情報を提供する方法であって、前記方法は、前記ターゲットグループの前記第２のデバイスの中の少なくとも１つのデバイスに関連する通信条件に関連する少なくとも１つの基準に基づいて、前記ターゲットグループの前記第２のデバイスの中から少なくとも１つの候補を選択することと、
選択された少なくとも１つの候補について、前記第１のデバイスに支援情報を伝送することであって、前記支援情報は、前記第１のデバイスと前記少なくとも１つの候補との間の通信チャネルの品質を少なくとも表すことと、
を含む、方法。
【請求項2】
前記品質は、少なくとも前記通信チャネルのネットワークリソースに関連し、前記ネットワークリソースは、前記第１のデバイスから前記第２のデバイスのターゲットグループにデータを送信するために使用されていない、請求項１に記載の方法。
【請求項3】
前記支援情報は、２ビット以上で構成される、請求項１又は２に記載の方法。
【請求項4】
前記通信条件は、マルチアクセスエッジコンピューティングデバイスによって前記ターゲットグループの第２のデバイスのそれぞれに関連付けられたパケット優先度レベルを含み、決定された通信条件又は各決定された通信条件に関連する少なくとも１つの基準は、前記パケット優先度レベルに更に基づいている、
請求項１～３のいずれか一項に記載の方法。
【請求項5】
前記ターゲットグループの少なくとも１つの第２のデバイスについて、前記第２のデバイスによって受信された情報に基づいて、前記少なくとも１つの第２のデバイスに関する前記通信条件を取得することを更に含む、請求項１～４のいずれか一項に記載の方法。
【請求項6】
前記通信条件は、前記第１のデバイスと前記第２のデバイスとの間の距離に関連し、前記ターゲットグループの前記第２のデバイスの中から少なくとも１つの候補を選択することは、前記ターゲットグループの前記第２のデバイスを複数のサブグループにクラスター化することであって、各サブグループは、それぞれの地理的領域に関連付けられ、各サブグループは、関連付けられた前記それぞれの地理的領域に分散された前記第２のデバイスから形成されることと、
前記それぞれの地理的領域に関連する少なくとも１つの基準に基づいて少なくとも１つのサブグループを選択することと、
前記少なくとも１つのサブグループの各々から、少なくとも１つの追加の基準に基づいて少なくとも１つの候補を選択することと、
を含む、請求項１～５のいずれか一項に記載の方法。
【請求項7】
前記第１のデバイスによって発信され、前記第２のデバイスによって受信される情報は、ペイロードを含み、前記通信条件を取得することは、前記第２のデバイスにおいて、前記ペイロードの復号化を試みることと、前記通信条件として、前記ペイロードの復号化の試みが成功したか失敗したかを判定することと、を含み、
決定された通信条件又は各決定された通信条件に関連する少なくとも１つの基準に基づいて、前記ターゲットグループの前記第２のデバイスの中から少なくとも１つの候補を選択することは、前記ペイロードの復号化の試みに失敗した前記第２のデバイスの中から前記少なくとも１つの候補を選択することを含む、
請求項１～６のいずれか一項に記載の方法。
【請求項8】
前記通信条件は、前記ターゲットグループの第２のデバイスにそれぞれ関連付けられたユーザ識別子を含み、決定された通信条件又は各決定された通信条件に関連する少なくとも１つの基準は、前記ユーザ識別子に更に基づいている、
請求項１～７のいずれか一項に記載の方法。
【請求項9】
決定された通信条件又は各決定された通信条件に関連する少なくとも１つの基準は、前記第１のデバイスによって決定され、前記第１のデバイスによって発信され、前記第２のデバイスによって受信される情報は、前記少なくとも１つの決定された基準を示すメタデータを含む、請求項１～８のいずれか一項に記載の方法。
【請求項10】
決定された通信条件又は各決定された通信条件に関連する少なくとも１つの基準は、前記ターゲットグループの第２のデバイスによってローカルに決定される、請求項１～９のいずれか一項に記載の方法。
【請求項11】
決定された通信条件又は各決定された通信条件に関連する少なくとも１つの基準に基づいて、前記ターゲットグループの前記第２のデバイスの中から少なくとも１つの候補を選択することは、第１の選択段階中に、第２のデバイスのサブグループを選択することと、
後続の選択段階中に、前記決定された通信条件又は各決定された通信条件に関連する少なくとも１つの基準に基づいて、前記第２のデバイスのサブグループの中から少なくとも１つの候補を選択することと、
を含む、請求項１～１０のいずれか一項に記載の方法。
【請求項12】
デバイス間通信システムであって、前記デバイス間通信システムは、第１のデバイスと、第２のデバイスのターゲットグループとを備え、前記デバイス間通信システムは、前記ターゲットグループの前記第２のデバイスの中から、前記ターゲットグループの少なくとも１つのデバイスに関連する通信条件に関連する少なくとも１つの基準に基づいて、少なくとも１つの候補を選択するように構成され、
選択された少なくとも１つの候補は、前記第１のデバイスに支援情報を伝送するように更に構成され、前記支援情報は、前記第１のデバイスと前記少なくとも１つの候補との間の通信チャネルの品質を少なくとも表す、
デバイス間通信システム。
【請求項13】
第２のデバイスであって、請求項１２に記載のデバイス間通信システムの第２のデバイス。
【請求項14】
１つ以上の記憶された命令シーケンスを含むコンピュータプログラムであって、前記命令シーケンスは、処理ユニットがアクセス可能であり、前記処理ユニットによって実行されると、前記処理ユニットに請求項１～１１のいずれか一項に記載の方法を実行させる、コンピュータプログラム。
【請求項15】
メモリに動作可能に接続された処理ユニットを備えた処理回路であって、前記処理回路は、請求項１～１１のいずれか一項に記載の方法を実行するように構成されている、処理回路。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、電気通信の分野に属する。
【0002】
特に、デバイス間通信システムにおいて、第１のデバイスに支援情報を提供する方法を開示する。第１のデバイスは、第２のデバイスのターゲットグループにデータを送信する。上記に対応するデバイス間通信システム、かかるシステムの第２のデバイス、コンピュータ可読記憶媒体、コンピュータプログラム、及び処理回路が更に開示される。
【背景技術】
【0003】
本開示のフレームワークは、デバイス間車両システムにおけるリソース割り振りを強化することである。本発明は、３ＧＰＰ ＮＲ Ｖ２Ｘのモード２（ａ）のフレームワークにおいて説明するが、この特定のフレームワークに限定されるものではない。Ｖ２Ｘ通信は、ブロードキャスト（１つの車両から全ての周囲車両へ）、グループキャスト（１つの車両から周囲車両のセットへ）、及びユニキャスト（１つの車両から別の車両へ）の通信サービスをサポートしている。本開示は、主に、グループキャスト及びブロードキャストのシナリオを対象とする。
【0004】
最先端のシナリオとして、以下の３ＧＰＰシナリオを考慮した。
車両は、Ｖ２Ｖ通信のために物理サイドリンク（ＰＣ５インターフェース）チャネルを使用する。
リソース割り振りは、３ＧＰＰ ＮＲ Ｖ２Ｘモード２（ａ）に基づいて実行され、送信機（ＴＸ）は、ローカルチャネルセンシング情報に基づいて自律的にリソースを選択する。
車両は、Ｖ２Ｖ通信のために物理サイドリンク（ＰＣ５インターフェース）チャネルを使用する。
リソース割り振りは、３ＧＰＰ ＮＲ Ｖ２Ｘモード２（ａ）に基づいて実行され、送信機（ＴＸ）は、ローカルチャネルセンシング情報に基づいて自律的にリソースを選択する。
【0005】
ここで、本開示に関連する主要な最先端の障害について、その文脈を完全に理解するために簡単に説明する。
【0006】
図１に示すように、３ＧＰＰ ＮＲ Ｖ２Ｘモード２（ａ）等のセンシングベースのリソース割り振りでは、隠れノード問題が主要な問題の１つとなっている。この例では、送信機ＴＸ１０が自身の通信範囲全体に情報を発信し、発信された情報は受信機ＲＸ２０ａ、２０ｂによって受信されると考えられる。隠れノード問題とは、いくつかのノード３０が所与の受信機ＲＸ２０ｂのセンシング範囲内にはあるが、送信機ＴＸ１０のセンシング範囲内にはない場合に生じるものである。この場合、ＴＸは、そのセンシング手順において隠れノードを認識していないため、隠れノードによって既に使用されているリソースを選択する場合がある。そのため、ＲＸ側でのパケット衝突が生じ、性能劣化につながる可能性がある。
【0007】
近年、ユニキャスト伝送における隠れノード問題に対して幾つかの解決策が提案されており、これらは、非特許文献１及び非特許文献２に開示されている。
【0008】
これは、受信機がセンシング情報に基づいてリソース割り振りを実行できるようにし、同じ物理リソースを使用して、このリソース割り振りの決定を送信機にフィードバックすることによって行われる。提案されたメカニズムは、図２に示すように３つのステップに基づいており、以下のように要約される。
第１のステップはスケジューリング要求１０１である。送信機ＴＸ１０は、サイドリンクスケジューリング要求ＳＲを使用して受信機ＲＸ２０に支援情報を求める。このＳＲには、ＩＤ、バッファ状態、リソース割り振り情報等に関連する情報が含まれる。また、ＳＲは、ＴＸセンシング情報からのスケジューリング許可ＳＧのための好ましいリソースについての情報を含もことができる。
第１のステップはスケジューリング要求１０１である。送信機ＴＸ１０は、サイドリンクスケジューリング要求ＳＲを使用して受信機ＲＸ２０に支援情報を求める。このＳＲには、ＩＤ、バッファ状態、リソース割り振り情報等に関連する情報が含まれる。また、ＳＲは、ＴＸセンシング情報からのスケジューリング許可ＳＧのための好ましいリソースについての情報を含もことができる。
【0009】
次のステップは、スケジューリング許可１０２である。ＲＸは、データ伝送に使用するために、そのセンシング情報から少なくとも好ましいリソースをシグナリングするＳＧで応答する。
【0010】
最後のステップは、スケジューリング割り当て１０３を含んでおり、データ伝送１０４へと進む。ＴＸは、ＲＸによって割り振られたＳＧからの伝送パラメータを使用して、又は自身の決定を行うための支援情報としてＳＧを使用して、スケジューリング割当てＳＡ及びデータをＲＸに伝送する。
【0011】
このメカニズムには、Ｒｘの支援をフィードバックするために多数のオーバーヘッドビットが必要となる。そのため、この文献において提案されている解決策は、ユニキャスト通信のみに限定されるものであり、必要なオーバーヘッド及びスペクトルリソースが大きいため、グループキャスト通信に直接的に拡張することはできない。したがって、ＮＲ Ｖ２Ｘモード２（ａ）の隠れノードの問題は、対処すべき必要がある未解決の問題として残されている。
【0012】
３ＧＰＰ ＮＲ Ｖ２Ｘモード２（ａ）のリリース１６では、距離に基づくグループキャスト通信のためのハイブリッド自動再送要求（ＨＡＲＱ）フィードバックメカニズムの選択肢が存在している。これは、距離ベースのＨＡＲＱフィードバックメカニズムと称されるもので、図３に示している。距離ベースのＨＡＲＱフィードバックメカニズムは、非特許文献３に更に詳述されている。
【0013】
このメカニズムでは、ＴＸ１０は、サイドリンク制御情報（ＳＣＩ）においてその位置情報（ゾーンＩＤ）及びその通信範囲を送信する。次いで、ＲＸ２０ａ、２０ｂは、この情報を復号化して使用して、これらのＲＸ２０ａ、２０ｂがＴＸの通信範囲内２２にあるか否かを把握する。次に、図３に示すように、通信範囲外２１にある地理的領域内のＲＸ２０ａに対しては、ＨＡＲＱフィードバックは伝送されない。ただし、通信範囲内２２の地理的領域内のＲＸ２０ｂについては、ＲＸの挙動は以下の通りとなる。
当該ＲＸが、ＳＣＩを復号化することができ、ユーザ情報データパケットを搬送する対応するトランスポートブロックＴＢも復号化することができる場合、何も送信しない（肯定応答ＡＣＫを送信せず、サイレントのままである）。
当該ＲＸがＳＣＩを復号化することができるが、対応するＴＢを復号化することができない場合、再伝送を求めるために、否定応答ＮＡＣＫがフィードバックとしてＴＸに送り返される。
当該ＲＸが、ＳＣＩを復号化することができ、ユーザ情報データパケットを搬送する対応するトランスポートブロックＴＢも復号化することができる場合、何も送信しない（肯定応答ＡＣＫを送信せず、サイレントのままである）。
当該ＲＸがＳＣＩを復号化することができるが、対応するＴＢを復号化することができない場合、再伝送を求めるために、否定応答ＮＡＣＫがフィードバックとしてＴＸに送り返される。
【0014】
このメカニズムの主な目的は、ＨＡＲＱフィードバックを多重化するために使用されるスペクトルリソースが乏しいため、ＴＸにフィードバック情報を送信するＲＸの数を減少させることである。ＨＡＲＱフィードバックのＡＣＫ／ＮＡＣＫ報告が１ビットしか必要としない場合であっても、グループ内に多数の車両があれば、全てのＲＸ車両からのフィードバック報告を多重化する際に深刻な問題が発生する可能性がある。したがって、この解決策では、ＨＡＲＱフィードバックを与えるために最も適切な車両（セキュリティへの影響が大きい可能性があるため、最も近い車両）を選択することによって、ＨＡＲＱフィードバック情報を送信する必要がある車両の数を減少させることが提案されている。
【0015】
３ＧＰＰ ＮＲモード２（ａ）リソース割り振りに関する提案の冒頭で、センシングに依存しないＶ２Ｖにおける自律的リソース割り振りのための解決策が提案されている。この解決策は、図４に示すように、リソースプールを複数のスペクトルチャンク（ミニリソースプール）に分割し、このスペクトルチャンクを隣接する地理的エリア３１、３２、３３に割り当てることに基づいている。次いで、各地理的エリア内で、（各サブゾーンエリアがおおよそ１台の車両を有することができるように）より小さい寸法を有するサブゾーン３２０に分割される。さらに、これらのサブゾーン３２０は、所与の地理的エリアに対応するミニリソースプール４２の別個の伝送リソース４２０に割り当てられる。全体の手順は、図４に要約されており、非特許文献４により詳細に説明されている。
【0016】
この地理的（ゾーニング）ベースのリソース割り振りでは、センシングを必要とすることなく、Ｖ２Ｖ通信用の分散方式での無衝突伝送が保証される。そのため、電力効率の良いメカニズムと考えることができるが、所与の地理的エリアにおいて車両の密度が小さい場合には、大量のリソース浪費につながる可能性があるため、リソース効率の悪いメカニズムとなる。かかる場合、スペクトルの残りの部分を使用する他のユーザが存在しない場合であっても、車両は、その地理的エリアに割り振られたスペクトルのごく一部を使用する。
【先行技術文献】
【非特許文献】
【0017】
【文献】Intel, "R1-1812492: Further Considerations on Sidelink Unicast, Groupcast, and Broadcast Modes for NR V2X Communication" 3GPP RAN WG1 95, Spokane, USA, November 2018
【文献】Vivo, "R1-1906139: Discussions on mode 2 resource allocation mechanism" 3GPP RAN WG1 97, Reno, USA, May 2019
【文献】Qualcomm, "R4-1913820: On NR V2X Distance-Based HARQ for Groupcast" 3GPP RAN WG4 93, Reno, USA, November 2019
【文献】Intel, "R1-160431: Support of geo-based transmission schemes for V2V communication" 3GPP RAN WG1 84, St Julian's, Malta, February 2016
【発明の概要】
【0018】
本発明は、添付の独立請求項によって定義される。本明細書で開示する概念の追加の特徴及び利点を、以下に説明する。
【0019】
本発明の目的は、上記の制限を克服することである。
【0020】
したがって、ここでは、デバイス間通信システムにおける第１のデバイスと第２のデバイスのターゲットグループとの間の少なくとも１つの通信チャネルの品質に関する支援情報を提供する方法であって、方法は、
ターゲットグループの第２のデバイスの中の少なくとも１つのデバイスに関連する通信条件に関連する少なくとも１つの基準に基づいて、ターゲットグループの第２のデバイスの中から少なくとも１つの候補を選択することと、
少なくとも１つの選択された候補について、第１のデバイスに支援情報を伝送することであって、当該支援情報は、第１のデバイスと当該少なくとも１つの候補との間の通信チャネルの品質を少なくとも表すことと、
を含む、方法が開示される。
ターゲットグループの第２のデバイスの中の少なくとも１つのデバイスに関連する通信条件に関連する少なくとも１つの基準に基づいて、ターゲットグループの第２のデバイスの中から少なくとも１つの候補を選択することと、
少なくとも１つの選択された候補について、第１のデバイスに支援情報を伝送することであって、当該支援情報は、第１のデバイスと当該少なくとも１つの候補との間の通信チャネルの品質を少なくとも表すことと、
を含む、方法が開示される。
【0021】
「通信チャネル」とは、１つ以上の発信機と複数の受信機との間の通信を可能にするチャネルを意味する。第１のデバイスは、以下では「発信機」とも称される少なくとも１つの発信機モジュールを備えることができ、第２のデバイスのターゲットグループはそれぞれ、以下では「受信機」とも称される少なくとも１つの受信機モジュールを備えることができる。
【0022】
開示される方法によって、最小限のリソースを使用して隠れノード問題を解決するために、ブロードキャスト又はグループキャストの通信サービスにおいて発信機に正確な支援情報を提供することができる。
【0023】
より正確には、発信機に支援情報を提供することにより、グループキャスト又はマルチキャストのシナリオに対する隠れノード問題に対処することが可能になる。
【0024】
さらに、全ての受信機からではなく、限られた数の選択された候補から支援情報を伝送することにより、通信システムに固有である制限、又は規格によって課される制限を考慮することができる。例えば、Ｖ２Ｖ通信システムのための３ＧＰＰ規格には、オーバーヘッド及びスペクトル不足に対する制約が含まれている。
【0025】
したがって、本発明は、Ｖ２Ｖ通信に適用可能であり、より詳細には、ＮＲ ３ＧＰＰ Ｖ２Ｘに適用可能である。
【0026】
さらに、通信条件に関連する少なくとも１つの基準に基づいて少なくとも１つの候補を選択することにより、発信機に伝送される支援情報の精度の最適化及び冗長性の最小化が可能となる。
【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】
【図1】既知の隠れノード問題を示す図である。
【図2】既知のユニキャスト支援フレームワークを示す図である。
【図3】既知のグループキャストのためのＨＡＲＱベースのフィードバックを示す図である。
【図4】既知のゾーニングベースのリソース割り振りを示す図である。
【図7a】本開示に関するものであり、特に、受信機の中から、送信機に向けて支援情報を発信するための候補を選択する種々の方法に関する。図７ａは、地理的ゾーン及びサブゾーンに基づく候補選択の一例を示す図である。
【図7b】本開示に関するものであり、特に、受信機の中から、送信機に向けて支援情報を発信するための候補を選択する種々の方法に関する。図７ｂは、地理的ゾーン及びサブゾーンに基づく候補選択の一例を示す図である。
【図8】本開示に関するものであり、特に、受信機の中から、送信機に向けて支援情報を発信するための候補を選択する種々の方法に関する。図８は、サービス品質又はネットワーク輻輳に関連する情報に従って受信機をクラスター化することに基づく候補選択の一例を示す図である。
【図9a】最新の支援情報を示す図である。
【図10a】本開示に関するものであり、特に、受信機の中から、送信機に向けて支援情報を発信するための候補を選択する種々の方法に関する。図１０ａは、グループキャストのシナリオにおける送信機ベースの支援情報の一例を示す図である。
【図10b】本開示に関するものであり、特に、受信機の中から、送信機に向けて支援情報を発信するための候補を選択する種々の方法に関する。図１０ｂは、グループキャストのシナリオにおける送信機ベースの支援情報の一例を示す図である。
【図11a】本開示に関するものであり、特に、受信機の中から、送信機に向けて支援情報を発信するための候補を選択する種々の方法に関する。図１１ａは、グループキャストのシナリオにおけるＭＥＣベースの支援情報の一例を示す図である。
【図11b】本開示に関するものであり、特に、受信機の中から、送信機に向けて支援情報を発信するための候補を選択する種々の方法に関する。図１１ｂは、グループキャストのシナリオにおけるＭＥＣベースの支援情報の一例を示す図である。
【図12a】本開示に関するものであり、特に、受信機の中から、送信機に向けて支援情報を発信するための候補を選択する種々の方法に関する。図１２ａは、グループキャストのシナリオにおける協調受信機決定ベースの支援情報の一例を示す図である。
【図12b】本開示に関するものであり、特に、受信機の中から、送信機に向けて支援情報を発信するための候補を選択する種々の方法に関する。図１２ｂは、グループキャストのシナリオにおける協調受信機決定ベースの支援情報の一例を示す図である。
【図12c】本開示に関するものであり、特に、受信機の中から、送信機に向けて支援情報を発信するための候補を選択する種々の方法に関する。図１２ｃは、グループキャストのシナリオにおける協調受信機決定ベースの支援情報の一例を示す図である。
【図13】本開示に関するものであり、特に、受信機の中から、送信機に向けて支援情報を発信するための候補を選択する種々の方法に関する。図１３は、多段階候補選択の一例における距離に基づく大まかな候補選択の一例を示す図である。
【図14】本開示に関するものであり、特に、受信機の中から、送信機に向けて支援情報を発信するための候補を選択する種々の方法に関する。図１４は、多段階候補選択の一例における距離に基づく絞り込み候補選択の一例を示す図である。
【図15】受信機のターゲットグループにデータを送信するための送信機を構成する方法の一例を示す図である。
【図16】上記の方法を実行するように構成された処理回路の一例を示す図である。
【発明を実施するための形態】
【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】
所与のＲＸは、ＴＸ通信範囲内にあるか否かを確認することによって、ＲＸ支援をＴＸに送信する候補であるか否かの確認を開始することができる。これは、ＲＸ自身の位置、並びに（例えば、ＳＣＩ上で）ＴＸから過去に受信され、ＲＸによって復号化されたＴＸ位置情報及び通信範囲を使用することによって行うことができる。
【0120】
所与のＲＸがこの条件を満たす場合、そのＲＸは、ＴＸに支援報告を伝送するための候補ＲＸとして識別される。したがって、ＴＸ ＵＥと同じセンシング情報を有する（近すぎる）ＲＸ ＵＥ、又はＴＸ ＵＥの近傍にあるイベントによって影響を受けない（遠すぎる）ＲＸ ＵＥを候補プールから破棄することができるため、支援情報の信頼性を改善することができる。
【0121】
この任意選択の距離ベースの候補選択が実装されない場合、全てのＲＸ ＵＥは、同じ単一のクラスター内にあるか、又は同じ単一の地理的ゾーン内にあると見なされる。
【0122】
補足的な特徴として、ＴＸ ＵＥは、選択される候補の数をより良く制御して選択を改善するために、候補選択のための最小距離及び／又は最大距離を設定することができる。
【0123】
【0124】
図６では、ＴＸ１は、外側通信範囲内の車両のみが支援情報を送信する候補ＲＸ２となるように、候補選択のための最小距離及び最大距離を調整する。次に、外側通信範囲に延在するゾーンのみが選択される。この例では、８つの選択されたゾーンがＴＸの外側通信範囲に対応しており、これらの８つの選択されたゾーンは、ＴＸの内側通信範囲に対応する単一の非選択ゾーンを囲んでいる。内側通信範囲に位置するＲＸは、ＴＸ１と類似したセンシング情報を有する非候補ＲＸ２ｃとなる。外側通信範囲よりも遠くに位置するＲＸもまた、ＴＸ１の近傍のイベントによって十分に影響を受けないため、非候補ＲＸ２ｄとなる。
【0125】
各選択されたゾーン内で、１つ又は少数のＲＸが、支援情報をＴＸに伝送するために選択される可能性がある。
【0126】
候補ＲＸを選択するための基準の別の例は、ＮＡＣＫの発生に関連する。
【0127】
３ＧＰＰ Ｖ２Ｘユニキャスト伝送では、ＨＡＲＱフィードバックは、ＴＸがデータを正しく復号化した場合にＡＣＫをＴＸに送信することと、正しく復号化しなかった場合にＮＡＣＫを送信することと、に基づいている。しかしながら、グループキャスト伝送の場合、現在、以下の２つの選択肢が存在する。
第１の選択肢として、グループ内の各ＲＸ ＵＥは、データを正しく復号化した場合に、ＴＸにＡＣＫを送信し、そうでない場合、ＮＡＣＫを送信する。
第２の選択肢として、データを復号化することに失敗したＲＸ ＵＥのみがＮＡＣＫをＴＸに送信するが、ＡＣＫはＲＸによって送信される必要はない。
第１の選択肢として、グループ内の各ＲＸ ＵＥは、データを正しく復号化した場合に、ＴＸにＡＣＫを送信し、そうでない場合、ＮＡＣＫを送信する。
第２の選択肢として、データを復号化することに失敗したＲＸ ＵＥのみがＮＡＣＫをＴＸに送信するが、ＡＣＫはＲＸによって送信される必要はない。
【0128】
グループキャスト伝送の場合、第２の選択肢の方がより効率的であることがわかる。これは、再伝送を考慮する場合、ＴＸは、再伝送が必要であるか否かを判定するために、１つ又はいくつかのＲＸがＮＡＣＫを送信したか否かのみを把握するためである。
【0129】
同様に、グループキャストにおいてＲＸ支援情報をＴＸに送信する場合、データを復号化することが困難なＲＸ ＵＥ（すなわち、ＮＡＣＫを送信したＲＸ）から支援報告を得ることのみが重要となる。実際に、かかるＲＸからの支援情報は、かかるＲＸが再伝送されたデータを正しく復号化できるように、再伝送のための最も適切なネットワークリソースをどのように選択するかを判定するために最も役立つと考えられる。したがって、技術的記載全体を通して、ＮＡＣＫの発生は、所与のＲＸ ＵＥがＴＸに支援報告を送信するための候補であるか否かを判定するための関連する基準であると想定される。
【0130】
例えば、現時点において、送信機ＴＸ１は、複数のＲＸからＮＡＣＫを受信する可能性があると考えられる。ＮＡＣＫの発生を候補ＲＸを選択するための基準とすることによって、ＮＡＣＫを送信した全てのＲＸを、この場合、候補ＲＸ２と見なすことができる。
【0131】
候補ＲＸ２の数は、クラスター内の当該ＲＸの位置に関連する基準等、候補ＲＸを選択するための基準の別の例に基づいて更に低減することができる。ゾーン情報を把握することは、隣接する候補ＲＸをクラスターにグループ化するのに重要であるが、サブゾーン情報（すなわち、所与の地理的ゾーン内の、又はＲＸの所与のクラスター間の各ＲＸの正確な位置）を把握することは、クラスターのどのＲＸが支援情報の送信を担当するかを選択又は選定するのに有益である。
【0132】
例えば、上述したようなＮＡＣＫの発生に基づいて取得された候補ＲＸの選択を絞り込んで、ＴＸへの支援情報の送信を担当する候補ＲＸのより少ないリストを取得してもよい。例えば、ゾーン内のサブゾーンを、ランク付けしてもよく、リソースを送信するためのゾーンの暗黙的又は明示的なマッピングを予め決定してもよい。各ゾーンからの単一のＲＸ ＵＥ２ａを、当該マッピングに基づいて選択してもよい。次いで、選択されたＲＸ２ａは、その優先順位に基づいて所与の時間に所与の周波数リソース上で支援情報を送信することができるが、当該ゾーンからの他の全てのＲＸ ＵＥは支援情報を送信しない。これにより、異なるユーザからの支援情報間の衝突を回避する。このように、自律的な方法でユーザ選択を行うことができる。
【0133】
【0134】
図７ａでは、４つの地理的ゾーンが表されており、それぞれが、３×３の格子状として表される９つの地理的サブゾーンを含む。
【0135】
ＴＸ１は、４つのゾーンの各々がＴＸ１の外側通信範囲の異なる部分をカバーするように、全４つのゾーンの間に表されている。ＴＸは、ＲＸのターゲットグループにデータを送信する。
【0136】
ターゲットグループのいくつかのＲＸ２は、４つのゾーンのうちの１つにおけるそれぞれのサブゾーン内に表されている。
【0137】
簡略化のため、以下のように考える。
ＴＸ１によって送信されたデータを復号化することが困難なＲＸのみが表される。
多くとも１つのＲＸが各サブゾーン内に位置する。
ＴＸ１によって送信されたデータを復号化することが困難なＲＸのみが表される。
多くとも１つのＲＸが各サブゾーン内に位置する。
【0138】
ＴＸ１によって送信されたデータを復号化することが困難な各ＲＸは、ＮＡＣＫをＴＸ１に送信し、一方で、同じゾーン内に位置する他のＲＸによって発信された他のＮＡＣＫもリッスンする。
【0139】
所与のＲＸについて、（この例では、同じ地理的ゾーン内のＲＸを指定する）他の隣接ＲＸによるＮＡＣＫの発生の数を把握することは、他のＲＸ内での優先度に基づいて、支援を送信する必要があるか否かを決定するのに有用である。
【0140】
図７ｂでは、所与のゾーン内のサブゾーンの優先度を順序付ける一例が、所定のマッピングとして表されている。
【0141】
このマッピングに続いて、ＮＡＣＫを送信した各ＲＸは、以下の決定を行うことができる。
所与のゾーン内での自身の優先度ランク。
同じゾーン内でより高い優先度ランクを有する別のＲＸもＮＡＣＫを発信したか否か。
同じゾーン内でより高い優先度ランクを有する他のＲＸもＮＡＣＫを発信していない場合にのみ、支援情報を伝送する。
所与のゾーン内での自身の優先度ランク。
同じゾーン内でより高い優先度ランクを有する別のＲＸもＮＡＣＫを発信したか否か。
同じゾーン内でより高い優先度ランクを有する他のＲＸもＮＡＣＫを発信していない場合にのみ、支援情報を伝送する。
【0142】
そのようにすることで、
所与のゾーン内のどのＲＸもＴＸにＮＡＣＫを送信していない場合、所与のゾーン内のどのＲＸもＴＸに支援情報を送信することができない。
所与のゾーン内の単一のＲＸがＴＸにＮＡＣＫを送信した場合、ＲＸはＴＸに支援情報を送信することができる。
所与のゾーン内の複数のＲＸ２がＴＸにＮＡＣＫを送信した場合、そのうち最も高い優先度ランクを有する単一のＲＸ２ａのみが、ＴＸ１に支援情報を伝送することができる。
所与のゾーン内のどのＲＸもＴＸにＮＡＣＫを送信していない場合、所与のゾーン内のどのＲＸもＴＸに支援情報を送信することができない。
所与のゾーン内の単一のＲＸがＴＸにＮＡＣＫを送信した場合、ＲＸはＴＸに支援情報を送信することができる。
所与のゾーン内の複数のＲＸ２がＴＸにＮＡＣＫを送信した場合、そのうち最も高い優先度ランクを有する単一のＲＸ２ａのみが、ＴＸ１に支援情報を伝送することができる。
【0143】
ＮＡＣＫの発生は、ＴＸが更に長期統計を実行する目的で使用することができる。実際に、ＴＸ側では、各フィードバックリソース上のＮＡＣＫの到着を観測することは有益である。この場合、ＴＸが同じリソース上で多数のＮＡＣＫが到着したことを観測すると、このリソースをＨＡＲＱフィードバックに使用しているＲＸが助けを必要としていると推論することができる。かかる場合、ＴＸは、この特定のＲＸ又は潜在的に関連するセンシング情報を有するものとして識別された別のＲＸ ＵＥ（例えば、同じゾーンからの別のＲＸ）を、支援情報のために指定することができる。ＴＸ ＵＥはまた、支援情報が必要とされるゾーンを指定し、ゾーン内のＵＥに、どのＲＸ ＵＥがどの時間に支援情報を与えるべきかを自律的に決定させることができる。
【0144】
候補ＲＸを選択するための基準の別の例は、受信機又は受信機のグループに関連付けられた識別子に関連する。各ＲＸは、ユーザ識別子、機器識別子等の固有の識別子ＩＤを有することができる。ＲＸのグループは、クラスター化のために使用される同一の識別子を共有する。７層ＯＳＩモデルによれば、識別子は、物理層識別子又は上位層識別子のいずれかである可能性がある。識別子は、ネットワーキングのために、例えば、ＴＸとＲＸとの間の通信のために、又はマルチアクセスエッジコンピューティングのために使用される。ＲＸ又はＲＸのグループのＩＤは、全ての候補ＲＸから一部のＲＸをランダムに又は確率的に選択して支援情報を送信するための関連基準である。これは、ＲＸ ＩＤにランダムプロセスを適用して、このＲＸが支援情報を送信するべきか否かを確認することによって行うことができる。例えば、ＲＸ ＵＥが支援情報を送信すべきか否かを決定するために条件（ＭＩＤ ｍｏｄ ２＝＝０）（ここで、ＭＩＤはＲＸ ＵＥの上位層ＩＤである）を使用することで、ＲＸ ＵＥの平均５０％が支援情報を送信することが保証される。同様に、条件（ＭＩＤ ｍｏｄ ４＝＝０）を使用することで、ＲＸ ＵＥの平均２５％が支援情報を送信することが保証される。
【0145】
候補ＲＸを選択するための基準の別の例は、待ち時間、ジッター、パケット損失率等のサービス品質（ＱｏＳ）パラメータ、及び／又は輻輳情報に関連する。ＱｏＳ及び／又は輻輳情報は、類似又は相関する複数のＲＸをクラスター化するのに有益である。繰り返しとなるが、これは、候補ＲＸセットを複数のクラスターに分割するのに役立つものであり、各クラスターは、類似の情報又は高度に相関する情報を有する。したがって、後でクラスターごとに１つのＲＸのみが選択され、ＴＸに支援を送信することができる。
【0146】
次に、図８を参照する。図８は、ＱｏＳ／輻輳ベースのＲＸ ＵＥのクラスター化及び選択を示す。この例では、送信機ＴＸ１は、ＲＸ２のターゲットグループにデータを送信する。ターゲットグループの一部のＲＸ２ｃは、ＴＸ１の内側通信範囲内にあり、ＴＸ１と類似したセンシング情報を有するものとする。さらに、他の送信機３が、ＴＸ１が自身でセンシングできない隠れノードとして存在すること、又はＴＸ１の通信範囲内にあり、したがってＴＸ１によってセンシングされるノード３ａとして存在することが考えられる。時間－周波数センシング情報は、ＲＸのターゲットグループの種々のＲＸ又はＲＸのグループについて表される。所与のＲＸ又はＲＸのグループにおいて、各薄灰色の四角形は、データを送信するためにＴＸ１によって現在使用されているリソースに対応する。所与のＲＸ又はＲＸのグループにおいて、各濃灰色の四角形は、データを送信するためにＴＸ１によって使用されない可能性があるリソースに対応するが、これは、当該所与のＲＸ又はＲＸのグループにおいて著しい干渉をもたらすためである。同じ隠れノード３に同様に供されているＲＸは、同様の輻輳レベル及び同様の干渉特性を有するように見える。かかる特徴をＲＸ ＵＥのクラスター化に利用することによって、クラスターごとに１つの支援報告で、ＴＸが再伝送のための効率的な決定を行って、隠れノードによって使用されるネットワークリソースを回避できるようになる。
【0147】
支援情報に含まれるデータの別の例は、ＴＸから支援情報を送信するＲＸへのデータの伝送時間である。特に、ＴＸは、半二重制約を有している場合がある。この特定の場合では、ＴＸは、伝送中にリソースをセンシングすることができないため、そのセンシングウィンドウに穴が生じる。これは、１つ以上のＲＸが、隠れノード又は干渉に関連するセンシング情報に加えて、ＴＸがネットワークリソースをセンシングできなかった時間における伝送時間の指示を含む支援情報をＴＸに提供することで、補償することができる。したがって、ＴＸは、自身のセンシングウィンドウ内の穴を埋めるセンシング関連支援情報を取得することができる。多様なセンシング関連支援情報をＴＸに提供するために、伝送時間は、クラスター化のための、又は支援情報の発信を担当する候補を選択するための基準の別の例である。
【0148】
どのＲＸが支援情報をＴＸに送信すべきかの選択決定を強化するために、上述の基準の各々が別々に又は組み合わせて使用されてもよいことは明らかである。決定プロセスで使用されるパラメータの数が増加するにつれて、決定はより最適化される。しかしながら、これはまた、かかる追加情報を搬送するために必要とされるオーバーヘッドの増加につながり、候補ＲＸ自体の間、又は候補ＲＸとＴＸとの間でより多くのシグナリングが必要となる可能性がある。原則として、シグナリングは、３ＧＰＰ ＮＲ Ｖ２Ｘモード２（ａ）等の実際の実装形態のシナリオにおいて最小化する必要がある。
【0149】
以降、本開示の柔軟性及び捕捉されるトレードオフを明確にするために、これらのパラメータのうちの一部を集中方式又は分散方式のいずれかで使用するための複数の例を提供する。
【0150】
所与のＲＸから支援情報を伝送するか否かを決定すること（又は、換言すれば、候補選択メカニズム）は、集中型手法又は分散型手法のいずれかを使用して、異なるネットワークノードによって実装することができる。
【0151】
例えば、各所与のＲＸ ＵＥは、ＴＸ ＵＥ又は別のＲＸ ＵＥからのいかなる入力もなしに、支援情報を送信するべきか否かを自律的な方法で自身について決定してもよく、それにより、余分なシグナリング又は遅延なしに選択メカニズムを実行してもよい。例として、各ＲＸ ＵＥが以下に基づいて実行する決定が挙げられる。
－自身の位置情報（ゾーン又はサブゾーンに関連する位置等）、及び／又は
－ユーザ機器識別子等の自身のユーザ機器固有情報。
－自身の位置情報（ゾーン又はサブゾーンに関連する位置等）、及び／又は
－ユーザ機器識別子等の自身のユーザ機器固有情報。
【0152】
例えば、ＲＸ ＵＥの所与のクラスター又はグループからの各ＲＸ ＵＥは、分散方式で（すなわち、同じグループ内の他のＲＸ ＵＥのステータスに基づいて、又は同じグループのＲＸ ＵＥ間の交換に基づいて）、グループからのどのＵＥが所与の時間に支援情報の送信を担当するかを決定することができる。かかる場合、ＲＸ ＵＥ間にある種の協調が存在するため、支援を送信するために所与のＲＸ ＵＥを選択／選定する決定は、協調的な情報に基づいており、完全に自律的な決定ではないことから、先述の例と比較してより良好な選択が保証される。上記で提示された図７は、グループ内の他のＲＸ ＵＥからのＮＡＣＫを観測することに基づいて、又はクラスター／ゾーン内のローカルＰＣ５ Ｖ２Ｖ交換を介して、同じクラスター／ゾーン内に位置するＲＸ ＵＥ間で行われる選定プロセスの例を示している。
【0153】
例えば、ＴＸ ＵＥは、どのＲＸ ＵＥが支援を送信するべきかを決定してもよく、次いで、その選択されたＲＸ ＵＥに通知する。この例は、先述の例と比較してより良い選択を達成することができるが、これは、この場合この解決策が完全に分散又は半分散ではなく、完全に集中化されるからである。ＴＸは、全ての候補ＲＸからＴＸに過去に伝送された任意の情報又は情報の組み合わせを使用して、集約情報に基づいて集中的に、支援情報の送信を担当するＲＸ ＵＥのサブセットを選択することができる。選択決定は、例えば、地理的情報及び／又は長期統計に基づいていてもよい。
【0154】
例えば、各ＲＸ ＵＥは、ＴＸ ＵＥから受信された支援に基づいて支援情報を伝送すべきかどうかを決定してもよい。この例では、各ＵＥにおける決定は、完全に自律的ではなく、むしろＴＸからの追加情報に基づいている。意思決定における支援であるこの追加情報は、完全に自律的な意思決定と比較して、グローバルな観点から支援を送信するためのＲＸ ＵＥ選択の性能を向上させる。例えば、ＴＸは、各ＲＸ ＵＥに、そのゾーンＩＤに基づいて支援を送信するその確率について通知してもよい。次いで、各ＲＸ ＵＥは、ＲＸによってローカルに把握されているそのゾーンＩＤに基づいて、更に各ゾーンＩＤについてＴＸによって送信された確率支援情報に基づいて、支援情報を送信するか否かを決定することができる。
【0155】
例えば、ＲＸ ＵＥは、ＭＥＣ支援に基づいて支援情報を送信するべきかどうかを決定してもよい。ＭＥＣデバイスは、先述の例におけるＴＸと同様に集中ユニットとして動作して、支援情報の送信を担当するＲＸ ＵＥを選択してもよく、又は候補ＲＸ ＵＥが支援情報を送信すべきか否かを自身で決定するのに役立ってもよい。集中型の選択を実行するためにＴＸではなくＭＥＣデバイスを使用する主な利点は、シグナリング遅延及びオーバーヘッドの両方が低減されることである。実際に、ＲＸ ＵＥとＭＥＣデバイスとの間のネットワークリンクは、ＲＸ ＵＥとＴＸとの間のリンクから独立して維持することができる。したがって、ＭＥＣ側での意思決定は、ＴＸからＲＸへの初期伝送を待機することなく、かつ任意の更なるシグナリング交換なしに行うことができる。
【0156】
支援報告が送信されるリソースのセットは、利用可能な、又は潜在的に利用可能なネットワークリソースのより大きなセットの中から選択することができる。
【0157】
３ＧＰＰ ＮＲ Ｖ２Ｘの現在のリリース（リリース１６）では、ユニキャスト伝送及びグループキャスト伝送におけるＲＸからＴＸへの報告のために２つの異なるチャネル上で搬送される２つのタイプの信号が存在する。これらの信号は、物理サイドリンクフィードバックチャネル（ＰＳＦＣＨ）上で搬送されるサイドリンクフィードバック制御情報（ＳＦＣＩ）、及び物理サイドリンク共有チャネル（ＰＳＳＣＨ）上で搬送されるチャネル状態情報参照信号（ＣＳＩ－ＲＳ）である。
【0158】
本開示では、支援報告は、伝送されるビット数に依存する新しいフォーマットを用いて、ＰＳＦＣＨ等の制御チャネルによって搬送することができる。実際に、導入する必要がある追加ビットのサイズは、送信される支援情報のサイズに大きく依存する。例えば、支援情報は、主にセンシング関連であり、リソースの全て又はサブセットのインデックスを含み、適切な規則によって、当該リソースが空いていること、又は当該リソースがビジーであることのいずれかを示してもよい。したがって、この支援情報のサイズに基づいてビットの数が変化し得るため、異なるＰＳＦＣＨサイズが必要とされる。
【0159】
本開示では、支援報告はまた、データチャネルによって搬送することができる。現在、ＣＳＩ－ＲＳは、ユニキャスト伝送のためにのみ存在しているため、ＣＳＩ－ＲＳは１つのＲＸに完全に割り当てられている。本開示では、低減された数のＲＸのみが支援情報を送信するために選択されるので、ＰＳＳＣＨ上で搬送されるＣＳＩ－ＲＳの使用をグループキャスト伝送に拡張することが提案される。したがって、以降で説明するように、適切な多重化方式を使用して、低減された数の選択されたＲＸ ＵＥ間でＣＳＩ－ＲＳを共有することが可能となる。
【0160】
本開示では、支援報告はまた、データチャネルと制御チャネルとの組み合わせを使用して搬送することができる。例えば、所与のＲＸ ＵＥは、データチャネルを使用して支援報告を提供しようとしていることを、制御チャネルを介してＴＸに通知してもよい。例えば、所与のＲＸ ＵＥは、制御チャネルを介して、当該支援報告を送信するためにどのデータチャネルリソースが使用されるかに関する指示をＴＸに提供してもよい。ＴＸが通知を受けると、ＲＸ ＵＥは、当該データチャネルを介して支援報告の送信を進めることができる。
【0161】
支援報告の多重化は、当該報告を送信するＲＸを選択する提案された方法によって明らかに改善される可能性がある。実際に、支援報告を伝送するＲＸの数を低減して選択することで、ＴＸ通信範囲内の全てのＲＸ及び／又はＮＡＣＫの発生を伴うＴＸ通信範囲内の全てのＲＸが支援報告を送信する必要がある現行技術水準におけるベースラインのケースと比較して、スペクトル及びオーバーヘッドの制約が明らかに緩和される。その利点を明確にするために、図９ａ及び図９ｂに一例を示す。
【0162】
図９ａは、最先端の場合を示している。この場合、例えば隠れノード３の存在に起因してＮＡＣＫが発生したＴＸ１通信範囲内の全てのＲＸ２も支援報告を送信する。ＮＡＣＫが発生していないＴＸ１通信範囲内のＲＸ２ｃは、支援報告を送信しない。この例では、支援を送信するか否かの決定は、ＲＸ側でローカルに行われる。リソースの多重化により、ＲＸ上位層ＩＤに基づいて支援が搬送される。したがって、リソースグリッドは、グループ内の全てのＲＸの数にわたって分割され、これにより、数ビットの支援情報を搬送し得る各ＲＸに割り当てられた小さいリソースブロックがもたらされる。したがって、各ＲＸによって伝送される支援情報は非常に限定的なものとなる。
【0163】
図９ｂは、本開示による例示的なケースを示している。候補選択がＴＸ１で集中化され、支援情報を送信するＲＸ２が選択される場合、リソースグリッドは、支援を搬送する、低減された数の選択されたＲＸ２でのみ分割することができる。これにより、これらのＲＸには、現行技術水準の場合と比較してより広いスペクトルリソースが割り当てられる。したがって、選択された各ＲＸによってより多くの支援情報を伝送することができ、スペクトルがより効率的な方法で使用される。別の例では、本開示によるＲＸ選定は、分散方式で適用される。この場合、最大で、ＴＸ通信範囲内のゾーンごとに１つのＲＸが支援を送信することが知られている。したがって、この場合、スペクトルリソースは、ＴＸ伝送範囲内のゾーンの数（例えば、図９ｂに表されるシナリオでは８つのゾーン）にわたって分割される。この解決策は、集中型の解決策ほどスペクトル効率が良くないが、現行技術水準の場合と比較してスペクトル効率が極めて優れている。実際、ＴＸ範囲内のゾーンの数は、通常ＴＸ範囲内のＲＸの数よりも極めて少ない。
【0164】
支援情報を提供するためのリソース選択は、種々の方法で行うことができる。
【0165】
例えば、周波数領域リソースは、支援情報を提供するＲＸが位置するゾーン又はサブゾーンに関連する情報に基づいて選択されてもよい。単一の、又は限られた数のＲＸ ＵＥが、かかるタイプのリソース選択を通して支援情報を送信することができる。
【0166】
例えば、より多数のＲＸ ＵＥが支援情報を連続的に送信することができるように、場合によっては初期伝送後の予め定義された又は構成された時間ウィンドウ内で、時間領域リソースが選択されてもよい。支援情報を提供するために所与のＲＸに割り振られるタイムスロットは、所定の規則に基づいて（例えば、ゾーン又はサブゾーンに基づいて）選択されてもよく、又は純粋に確率に基づくか、若しくはＵＥ ＩＤに基づく等、ランダムな選択であってもよい。
【0167】
周波数領域多重化、時間領域多重化及び空間領域多重化の組み合わせが実行されてもよい。例えば、周波数領域多重化は、ゾーニングに基づいて、又はサービスタイプ若しくは優先度タイプ等の別のグループ化基準に基づいて実行されてもよい。この多重化により、ＲＸのターゲットグループの中の各クラスターについて、それぞれの周波数領域リソースを割り振ることが可能となる。さらに、時間領域多重化を実行して、所与のクラスターの各ＲＸについて、それぞれの時間領域リソースを割り振ることができる。したがって、各候補ＲＸには、ＴＸによる明確な識別のために単一の時間周波数ネットワークリソースを割り振ることができる。
【0168】
以下では、様々な実装形態が様々なシナリオにおいて説明される。
【0169】
例示的な実施形態では、支援情報を送信するための候補選択は、ＴＸにおいて実装されるか、又はＴＸによって支援される。一般的な方法では、ＴＸは、自身のセンシング情報のみに基づいて初期伝送を送信し、制御情報を復号化することができるが伝送のデータ部分を復号化することができないユーザからＮＡＣＫフィードバックを受信する。これは、全てのＵＥによって行われてもよいし、従来技術で説明されているような距離ベースの制限下のＵＥによって行われてもよい。したがって、ＴＸ ＵＥは、特定の数のセンシング情報を収集して、最も有益な支援情報を提供できるＲＸ ＵＥを更に決定することができる。かかるセンシング情報には、例えば、頻繁かつ相関するＮＡＣＫの発生挙動を有するＵＥに関する長期統計、及び／又はゾーニング情報等のＲＸ ＵＥ位置についての暗黙的若しくは明示的な情報が含まれてもよい。
【0170】
例えば、ＴＸは、１つのＵＥのＮＡＣＫの発生が別のＵＥのＮＡＣＫの発生に高度に相関する場合、その２つのＵＥのうちの１つから支援を得ることのみが必要とされると決定してもよい。実際に、ＮＡＣＫの発生の相関は、無線リンクの品質に影響を及ぼす同じ要因に由来する可能性が最も高く、２つのＵＥに対して１回だけ報告する必要がある。このことは、そのＮＡＣＫの発生の相関に従ってクラスター化されたＵＥのグループについて、１つの報告のみに拡張することができる。
【0171】
特定の例では、ＮＡＣＫフィードバックは、ゾーンに基づいて周波数領域において多重化することができる。換言すれば、所与のゾーン内のＵＥはそれぞれ、該ＵＥの位置に関連する特定の周波数リソース中でＮＡＣＫフィードバックを提供することができる。したがって、ＲＸ ＵＥによるＮＡＣＫフィードバックのために使用されるリソースは、隠れノード問題によって影響を受けるゾーンの位置を表す。
【0172】
これらの要素は、当該ＴＸと当該グループの少なくとも１つのメンバーとの間の通信条件に関する情報を構成する。
【0173】
したがって、ＴＸ ＵＥは、この情報に基づいて、最初に伝送されたデータの一部として、又は後の段階で（例えば、ＨＡＲＱフィードバックを受信した後）、ＵＥ又はＵＥのグループを直接指定することによって、候補選択を実行又は支援することができる。
【0174】
このために、ＴＸ ＵＥは、支援情報を伝送する特定のＲＸ ＵＥを決定することができる。この場合、選択決定はＴＸ ＵＥによって実行され、選択されたＲＸ ＵＥはＴＸによって通知される。ＲＸ ＵＥは、ＨＡＲＱ ＮＡＣＫを提供するＵＥのうちの１つであり得るか、又はＴＸ ＵＥによって識別される別のＵＥである。
【0175】
ＴＸ ＵＥは、１つ又は複数のＲＸ ＵＥが支援情報を提供するＵＥのグループを決定することができ、例えば、ＴＸ ＵＥは、グループＩＤ、ゾーンＩＤ、サービスタイプ等によってかかるグループを示すことができる。指定されたグループからの１つ又はいくつかのＵＥのみが支援情報を提供する場合、決定ステップは、示されたＲＸ ＵＥにおいて、どのＵＥを最終的に選択すべきか、及び支援情報の伝送を担当するかを決定する更なるサブステップを含むことができる。この絞り込み選択は、例えば、上述したようにグループ間で分散方式で実行されてもよい。例えば、指定されたグループ内の複数の／全てのＵＥは、支援情報を提供してもよく、該ＵＥは、支援情報を提供するためのリソース選択（例えば、上記で説明したように異なる支援報告を時間／周波数領域多重化する方法）を更に実行してもよい。
【0176】
図１０ａおよび図１０ｂは、上記の例によるグループキャストにおける送信機ベースの支援情報の伝送を示している。ＴＸ１は、その初期伝送の一部として、所与のクラスター２のＲＸ ＵＥに関連付けられた識別子を示すことによって、支援情報を求める。次いで、当該クラスターの１つのＲＸ２ａが、当該クラスターの間で自律的に又は分散的に選択される。選択されたＲＸ２ａは、要求された支援情報をＴＸ１に送り返すが、クラスターの他のＲＸ（２ｂ）は支援情報を送信しない。
【0177】
任意選択の実装形態の変形例では、ＭＥＣ（モバイルエッジコンピューティング又はマルチアクセスエッジコンピューティング）ユニットによって、又はＭＥＣユニットから受信された情報に基づいて、決定が行われる。一般的な方法では、パケット優先度、並びにアプリケーションパケットのトラフィック、セッションパラメータ、サービス品質、サービスタイプ、アプリケーションタイプごとのＵＥグループ化等に関する他の全ての関連情報を、ＭＥＣノードにおいて制御することができる。したがって、ＭＥＣノードは、特定の数の情報を収集して、最も有益な支援情報を提供し得るＲＸ ＵＥを決定するか、又は決定を支援することができる。
【0178】
例えば、特定のトラフィック優先度を有する、又は特定のＱｏＳ要求を有する、又はより大きなＮＡＣＫ普及に関連付けられた特定の位置を有するユーザ又はユーザのグループを決定することが可能である。したがって、かかるユーザ又はユーザのグループからの支援情報は、全体的なネットワーク性能を改善するのに特に有用である。かかる場合、ＭＥＣユニットは、支援情報を伝送するＲＸの選択に介入することができる。
【0179】
一例では、アプリケーション層によって指定されたユーザのみが、前述の方法のいずれかに基づく更なる候補選択のための候補となる。
【0180】
例えば、アプリケーション層によって指定されたユーザのみが、別のトリガー（例えば、ＮＡＣＫの発生等）に基づいて支援情報を送信してもよい。
【0181】
例えば、ＶＲＵ（交通弱者）は、安全のために、そのＡＣＫ又はＮＡＣＫステータスにかかわらず、常に支援情報を送信してもよい。
【0182】
一例では、ユーザ又はユーザのグループは、アプリケーション依存トポロジーに基づいて決定することができる。ここで、ＭＥＣユニットは、別のエンティティによって実行される選択の基礎となる通信条件に関する情報を定義することに介入することができる。例えば、通信条件に関する情報が、少なくとも複数のゾーンと、候補選択のためのＴＸ ＵＥに対する最小－最大距離とで構成されると仮定する。ゾーンの数は、ＭＥＣユニットによってアプリケーションに依存して決定されてもよい。例えば、隊列走行用途の場合、ＭＥＣユニットは、ゾーンの数を２（正面／後方）に設定し、最小距離／最大距離をハイウェイ通信範囲及びユーザ密度に依存するように決定してもよい。例えば、交差道路用途の場合、ＭＥＣユニットは、交差点に向かう／交差点から離れる車両の方向を更に考慮することによって、２つの交差道路の各レーンにそれぞれ対応するゾーンの数を８に設定してもよい。ＭＥＣユニットは、都市シナリオの通信範囲及びユーザ密度に応じて、最小距離／最大距離を更に設定してもよい。
【0183】
次に、図１１ａ及び図１１ｂを参照する。図１１ａ及び図１１ｂは、グループキャストにおけるＭＥＣベースの支援情報伝送方式の一例を示す。ＭＥＣユニットは、ＴＸ１通信範囲内の異なるＲＸクラスター２を識別し、各クラスターのＲＸに、支援情報をＴＸ１に送信する要求を送信する。次いで、各クラスター２において、候補ＲＸ２ａが要求された支援情報をＴＸ１に送信し、他のＲＸがＴＸ１に支援情報を送信しないように、単一の候補ＲＸ２ａの選択が自律的に又は分散方式で実行される。
【0184】
別の実装形態の変形例では、支援情報の伝送を担当するＲＸの選択は、いかなる集中型ユニット（ＴＸ、ＭＥＣ等）にも依存せずに、完全に分散した方法でＲＸによって実行することができる。
【0185】
ＴＸは、現在の３ＧＰＰ Ｖ２Ｘモード２（ａ）と同様に、自身のセンシング情報のみに基づいて初期伝送を送信し、次いでＮＡＣＫを受信する。
【0186】
各ＲＸは、ＴＸと当該ＲＸとの間の通信条件に関連する情報をローカルに取得する。情報は、例えば、距離、ゾーニング、ＮＡＣＫの発生等に関連していてもよい。次いで、候補ＲＸの選択は、取得された情報に関連する基準に基づいて、ＲＸ ＵＥ自体によって実装される。したがって、選択は、距離ベースであるか、ゾーニングベースであるか、又はＮＡＣＫの発生等に基づく。結果として、支援報告は、ローカルバイナリ決定に基づいてＴＸに送信される。これらのバイナリ決定は各ノードで別々に行われるため、候補選択は完全に分散される。
【0187】
これらのバイナリ決定は、各ＲＸ側で利用可能な任意のローカル情報に依存する。特定の例では、上位層ＩＤ及びゾーンＩＤにそれぞれ関連する２つの基準が使用される。例えば、各ＲＸノードがグループ内の全てのＲＸについて上位層によって定義された一意のＩＤを有すると仮定し、同じ地理的ゾーン内の複数のＲＸが同じゾーンＩＤを共有すると仮定すると、ゾーンＩＤ（共有）と上位層ＩＤ（一意）との両方の組み合わせを使用することが有益である。したがって、バイナリ決定は、或る程度、支援報告を送信するＲＸが異なるゾーン内に拡散されることを保証し、それにより、或る程度冗長性を回避し、報告の多様性を保証することができる。この手法は、上述の集中型の解決策と比較して最適な選択には至らないが、ＲＸと中央ユニットとの間のシグナリング及びオーバーヘッドを最小限に抑えることに関しては、明確な利点が得られる。
【0188】
次に、図１２ａ、図１２ｂ、及び図１２ｃを参照する。図１２ａ、図１２ｂ、及び図１２ｃは、分散型ＲＸベースの候補選択が選定ベースのメカニズムに依存する例示的な実施形態を示す。選定は、中央ユニットの介入なしにＲＸのサブグループによって実行される。選定とは、先述の例のように完全に分散型の選択ではなく、半分散型の選択である。この選定は、本明細書でより詳細に説明する。
【0189】
ＴＸ１は、（現在の３ＧＰＰ Ｖ２Ｘモード２（ａ）と同様に）自身のセンシング情報のみに基づいて初期伝送を送信し、ＮＡＣＫを待機する。ＴＸは、ＮＡＣＫをフィードバックするために使用される時間周波数リソースを割り当てるための特定の構成を更に定義する。時間周波数リソースは、現行技術水準で知られているように、当該ＲＸに関連付けられた地理的ゾーン及びサブゾーン情報に基づいて、ターゲットグループのＲＸ（２）に割り当てることができる。
【0190】
次いで、ターゲットグループのＲＸは、初期伝送を復号化しようと試みる。その後、メッセージを正しく復号化したＲＸからのアクションは必要とされない。逆に、初期伝送の復号化に失敗したＲＸは、候補選択のために距離ベースの制限を自律的に確認する必要がある。次いで、初期伝送を復号化することに失敗し、潜在的な候補となる各ＲＸは、その地理的ゾーン及びサブゾーンインデックスに基づいて、ローカルに決定された所与の時間周波数リソースに従ってＮＡＣＫを送信する。ＲＸが全二重能力を有すると仮定すると、各ＲＸは、自身のＮＡＣＫを送信しながら、他のＮＡＣＫを同時にリッスンする。したがって、各ＲＸは、ＮＡＣＫを送信した同じゾーン内のＲＸの数だけでなく、同じゾーン内の当該ＲＸの位置又はサブゾーンも把握することができる。この情報は、時間周波数リソースをリッスンし、該リソースをゾーン及びサブゾーンインデックスに変換して戻すのみで取得される。
【0191】
ＴＸは、受信機からＮＡＣＫを受信する。一方、ＮＡＣＫを送信したＲＸは、ゾーン上の自身の位置と、ＮＡＣＫを有する同じゾーン内の他のＲＸの位置とに基づいて、支援情報を送信するか否かを更に決定する。これは、図１２ｂに示されるようなサブゾーン優先度マップを使用して行うことができる。このようにして、ＲＸは、そのサブゾーン及び同じゾーン内の他のＲＸのサブゾーンに基づいて、最高の優先度を有する（したがって、選定され（２ａ）、支援情報を送信する）か否か（したがって、選定されず（２ｂ）、支援を送信しない）を把握する。
【0192】
各ゾーンの選定されたＲＸ（２ａ）は、支援情報をＴＸに送信して、ＴＸが再伝送のために適切なネットワークリソースを選択するのに役立つ。
【0193】
選定は、グループの一部として互いを識別したユーザ間の更なるＤ２Ｄ交換に基づいて実行することができる。選定は、グループの一部として互いを識別したユーザのランダムな選択に基づいて実行することができる。選定は、例えば、全てのＵＥが異なる時間／周波数スロットで支援報告を送信することを可能にする、支援情報を伝送するためのリソース選択の規則によって置き換えられてもよい。
【0194】
【0195】
この例示的な実施形態では、所与のＲＸが支援情報を提供することを決定するために、以下のような３つの条件を満たす必要があると考えられる。
ＲＸは、ＴＸ通信範囲内にある必要がある。
ＲＸは、ＴＸ通信範囲の外側部分内にある必要がある。
ＲＸは、他の隣接ＲＸ又は候補ＲＸよりも特別な特性又は特定の優先度を有する必要がある。
ＲＸは、ＴＸ通信範囲内にある必要がある。
ＲＸは、ＴＸ通信範囲の外側部分内にある必要がある。
ＲＸは、他の隣接ＲＸ又は候補ＲＸよりも特別な特性又は特定の優先度を有する必要がある。
【0196】
メカニズムの第１の段階は、図１３に示される距離ベースの大まかな候補選択である。
【0197】
この段階の間、所与のＲＸ２は、ＴＸ通信範囲内にあるか否かを最初に確認することによって、ＴＸ１にＲＸ支援を送信する候補であるか否かの確認を開始する。次いで、ＲＸは、ＳＣＩ上でＴＸによって既に送信され、ＲＸによって復号化された、自身の位置及びＴＸのゾーン情報及びＴＸの通信範囲を使用して、ＴＸ通信範囲の外側範囲内にあるか否かの確認を開始する。所与のＲＸがこれらの条件を満たす場合、該ＲＸは、ＴＸに支援報告を送信するための候補ＲＸとして宣言される。したがって、このＲＸを第２の段階に昇格させることができる。ＴＸ１の通信範囲外のＲＸ２ｄは除外され、ＴＸ１の内側通信範囲内のＲＸ２ｃも除外される。
【0198】
第２の段階は、第１の段階を生き残ったＲＸを入力として採用する絞り込み候補選択である。第２の段階の出力では、支援情報を送信するＲＸの数を低減して選択される。この例では、第１の段階は距離ベースであり、各ＲＸにおいて自律的に実行されるが、第２の段階は、複数のメカニズムに基づいて（例えば、距離及びゾーニング情報に基づいて、上位層ＩＤに基づいて、通信条件に基づいて等）実行することができる。さらに、第２の段階は、集中型手法に基づいて、又は分散型若しくは自律型手法に基づいて実行することができる。リソース選択の更なるステップを適用することもできる。例えば、候補ユーザは、時間領域多重化を使用して、構成された、又は予め構成された時間経過内に支援情報を送信してもよい。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7a】
【図7b】
【図8】
【図9a】
【図9b】
【図10a】
【図10b】
【図11a】
【図11b】
【図12a】
【図12b】
【図12c】
【図13】
【図14】
【図15】
【図16】
