JP2022541717A - 方法、及び端末装置 - Google Patents

Abstract

本開示の実施形態は、サイドリンクチャネルにおける再送用のリソース予約のためのソリューションを提供する。通信方法において、第１デバイスは、サイドリンクチャネルを介して第２デバイスに送信されるデータを生成する。第１デバイスは、データの再送用の再送リソースを予約するための予約基準が満たされたか否かを判定する。再送リソースは、第２デバイスを含む別のデバイス及び第１デバイスのサイドリンク通信のためのリソースプールに含まれる。予約基準が満たされたと判定したことに応答して、第１デバイスは、再送リソースが予約されていることを示す予約情報を別のデバイスに送信する。本開示の実施形態によれば、フィードバックによる再送のためのリソース予約を可能にするサイドリンク通信用のリソースプールのより良いリソース利用が達成される。【選択図】図２

Description

本開示の実施形態は、一般的に、通信の分野に関し、特に、サイドリンク通信における再送リソースの予約に関する。

３ＧＰＰ規格の最新の発展技術は、進化したパケットコア（ＥＰＣ：Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｃｏｒｅ）ネットワークのロングタームエボリューション（ＬＴＥ：Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）及びＥ‐ＵＴＲＡＮ（Ｅｖｏｌｖｅｄ ＵＭＴＳ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）と呼ばれ、通常、「４Ｇ」とも呼ばれる。さらに、「５Ｇ ＮＲ（Ｎｅｗ Ｒａｄｉｏ）」という用語は、様々なアプリケーションやサービスをサポートすることが期待される進化した通信技術を指す。５Ｇ ＮＲは、遅延性、信頼性、セキュリティ、スケーラビリティ（例えば、ＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ））に関連する新たな要求、及びその他の要求を満たすために、第３世代パートナーシッププロジェクト（３ＧＰＰ：Ｔｈｉｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）によって公表された継続的なモバイルブロードバンドの進化の一部である。５Ｇ ＮＲのいくつかの態様は、４Ｇロングタームエボリューション（ＬＴＥ）規格に基づくことがある。

最近、５Ｇ ＮＲにおけるサイドリンク通信について、以下のようにいくつかの合意が得られている。ＮＲ Ｖ２Ｘ（ｖｅｈｉｃｌｅ－ｔｏ－ｅｖｅｒｙｔｈｉｎｇ） Ｍｏｄｅ－２は、同じトランスポートブロック（ＴＢ：ｔｒａｎｓｐｏｒｔ ｂｌｏｃｋ）の以前の送信に関連付けられるシグナリングでの、フィードバックによる物理サイドリンク共有チャネル（ＰＳＳＣＨ：ｐｈｙｓｉｃａｌ ｓｉｄｅｌｉｎｋ ｓｈａｒｅｄ ｃｈａｎｎｅｌ）の再送のためのリソース予約をサポートする。その後のセンシング及びリソース選択のプロシージャへの影響は今後の研究課題である。少なくともこのＴＢの送信機の観点から、未使用リソースの解放用のハイブリッド自動リピート要求（ＨＡＲＱ：ｈｙｂｒｉｄ ａｕｔｏｍａｔｉｃ ｒｅｐｅａｔ ｒｅｑｕｅｓｔ）フィードバックの使用がサポートされる。送信側ＵＥによる未使用リソースの解放を目的とする追加のシグナリングは定義されていない。このＴＢの受信側ＵＥの動作及び他のＵＥの動作は、今後の検討課題である。

一般的に、本開示の例示的な実施形態は、サイドリンクチャネルにおける再送用のリソース予約のためのソリューションを提供する。

第１態様では、通信方法が提供される。この方法は、第１デバイスで、サイドリンクチャネルを介して第２デバイスに送信されようとするデータを生成することを含む。この方法は、前記データの再送用の再送リソースを予約するための予約基準が満たされたか否かを判定することも含み、前記再送リソースは、前記第２デバイスを含む別のデバイス及び前記第１デバイスのサイドリンク通信用のリソースプールに含まれる。この方法は、前記予約基準が満たされたと判定したことに応答して、前記再送リソースが予約されていることを示す予約情報を前記別のデバイスに送信することをさらに含む。

第２態様では、通信方法が提供される。この方法は、第２デバイスで、第１デバイスから、サイドリンクチャネルを介する前記第１デバイスから前記第２デバイスへのデータの再送のために再送リソースが予約されていることを示す予約情報を受信することを含み、前記再送リソースは、前記第１デバイスを含む別のデバイス及び前記第２デバイスのサイドリンク通信用のリソースプールに含まれる。この方法は、前記第１デバイスを含む前記別のデバイスのうちの少なくとも１つへのサイドリンク送信に対する前記再送リソースの利用可能性を判定することも含む。この方法は、前記再送リソースの前記利用可能性に基づいて、前記リソースプールから前記サイドリンク送信用の送信リソースを選択することをさらに含む。

第３態様では、通信方法が提供される。この方法は、第３デバイスで、第２デバイスとサイドリンク通信している第１デバイスから、サイドリンクチャネルを介する前記第１デバイスから前記第２デバイスへの再送のために再送リソースが予約されていることを示す予約情報を受信することを含み、前記再送リソースは、前記第１デバイス及び前記第２デバイスを含む別のデバイス及び前記第３デバイスのサイドリンク通信用のリソースプールに含まれる。この方法は、前記第２デバイスから前記第１デバイスへのＡＣＫ／ＮＡＣＫチャネルを監視することも含む。この方法は、前記監視の結果に基づいて、前記第１デバイス及び前記第２デバイスを含む前記別のデバイスのうちの少なくとも１つへのサイドリンク送信に対する前記再送リソースの利用可能性を判定することも含む。この方法は、前記再送リソースの前記利用可能性に基づいて、前記リソースプールから前記サイドリンク送信用の送信リソースを選択することをさらに含む。

第４態様では、第１デバイスが提供される。この第１デバイスは、プロセッサと、命令を格納するメモリと、を備える。前記メモリ及び前記命令は、前記プロセッサによって、前記第１デバイスに第１態様に記載の方法を実行させる。

第５態様では、第２デバイスが提供される。この第２デバイスは、プロセッサと、命令を格納するメモリと、を備える。前記メモリ及び前記命令は、前記プロセッサによって、前記第２デバイスに第２態様に記載の方法を実行させる。

第６態様では、第３デバイスが提供される。この第３デバイスは、プロセッサと、命令を格納するメモリと、を備える。前記メモリ及び前記命令は、前記プロセッサによって、前記第３デバイスに第３態様に記載の方法を実行させる。

第７態様では、命令が格納されたコンピュータ読み取り可能な媒体が提供される。前記命令は、デバイスの少なくとも１つのプロセッサで実行されると、前記デバイスに第１、第２、又は第３態様に記載の方法を実行させる。

本概要部分は、本開示の実施形態の主要な又は本質的な特徴を特定することを意図しておらず、本開示の範囲を限定するために使用されることも意図していないことを理解されたい。本開示の他の特徴は、以下の説明により容易に理解できるようになる。

添付図面を参照しながら本開示のいくつかの実施形態をより詳細に説明することを通して、本開示の上記及び他の目的、特徴、及び利点がより明らかになる。

図１は、本開示のいくつかの実施形態を実施可能な通信環境の概略図である。

図２は、本開示のいくつかの実施形態にかかる例示的な方法のフローチャートを示す。

図３は、本開示のいくつかの実施形態にかかる端末デバイス間のサイドリンク通信用のリソースを含むリソースプールの概略図を示す。

図４は、本開示のいくつかの実施形態にかかる別の例示的方法のフローチャートを示す。

図５は、本開示のいくつかの実施形態にかかるさらなる別の例示的な方法のフローチャートを示す。

図６は、本開示の実施形態の実施に適したデバイスの簡略化したブロック図である。

図面全体において、同一又は類似の参照番号は、同一又は類似の要素を表す。

本開示の原理について、いくつかの例示的な実施形態を参照して説明する。これらの実施形態は、例示の目的のみで記載され、本開示の範囲に関するいかなる限定を示唆することなく、当業者が本開示を理解して実施することに寄与することを理解されたい。本明細書で説明される開示は、以下に説明されるもの以外の様々な態様で実施されることができる。

以下の説明及び特許請求の範囲において、別途定義されない限り、本明細書で使用されるすべての技術用語及び科学用語は、本開示が属する技術分野の当業者にとって一般的に理解されるものと同じ意味を有する。

本明細書で使用されるとき、「ネットワークデバイス」又は「基地局」（ＢＳ：Ｂａｓｅ Ｓｔａｔｉｏｎ）という用語は、端末デバイスが通信できるセル又はカバレッジを提供し、又はホストすることができるデバイスを指す。ネットワークデバイスの例として、Ｎｏｄｅ Ｂ（ＮｏｄｅＢ又はＮＢ）、Ｅｖｏｌｖｅｄ ＮｏｄｅＢ（ｅＮｏｄｅＢ又はｅＮＢ）、次世代ＮｏｄｅＢ（ｇＮＢ）、Ｖ２Ｘ通信用のインフラデバイス、送信／受信ポイント（ＴＲＰ：Ｔｒａｎｓｍｉｓｓｉｏｎ／Ｒｅｃｅｐｔｉｏｎ Ｐｏｉｎｔ）、リモート無線ユニット（ＲＲＵ：Ｒｅｍｏｔｅ Ｒａｄｉｏ Ｕｎｉｔ）、無線ヘッド（ＲＨ：Ｒａｄｉｏ Ｈｅａｄ）、リモート無線ヘッド（ＲＲＨ：Ｒｅｍｏｔｅ Ｒａｄｉｏ Ｈｅａｄ）、及びフェムトノードやピコノードなどの低パワーノードなどが挙げられるが、これらに限定されない。

本明細書で使用されるとき、「端末デバイス」という用語は、無線又は有線の通信機能を有する任意のデバイスを指す。端末デバイスの例として、ユーザ機器（ＵＥ：Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）、車載端末デバイス、歩行者のデバイス、路側機、パーソナルコンピュータ、デスクトップ、移動電話、セルラー電話、スマートフォン、携帯情報端末（ＰＤＡ：Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）、ポータブルコンピュータ、デジタルカメラなどの画像キャプチャデバイス、ゲームデバイス、音楽記憶及び再生機器、又は無線や有線インターネットアクセス及びブラウジングを可能にするインターネット機器などが挙げられるが、これらに限定されない。説明の目的のために、以下、端末デバイスの例としてＵＥを参照していくつかの実施形態を説明し、「端末デバイス」及び「ユーザ機器」（ＵＥ）という用語は、本開示の文脈で互換的に使用されることができる。

本明細書で使用されるとき、単数形である「１つ（ａ）」、「１つ（ａｎ）」、及び「前記（ｔｈｅ）」は、文脈からそうでないことが明確に示されない限り、複数形も含むことを意図している。「含む」という用語及びその変形は、「．．．含むが、これに限定されない」ことを意味するオープンな用語として読み取られる。「に基づいて」という用語は、「少なくとも部分的に基づいて」として読み取られる。「一実施形態」及び「実施形態」という用語は、「少なくとも１つの実施形態」として読み取られる。「別の実施形態」という用語は、「少なくとも１つの他の実施形態」として読み取られる。「第１」、「第２」などの用語は、異なるオブジェクト又は同じオブジェクトを指すことができる。以下には、明示的及び暗黙的なその他の定義が含まれることがある。

いくつかの例では、値、手順、又は装置は、「最もよい」、「最も低い」、「最も高い」、「最小」、「最大」などとして言及される。そのような記述は、多くの使用される機能的選択肢から選択可能であることを示すと意図しており、このような選択は、他の選択に比べてより良い、小さい、高い、又はより好ましい必要がないことを理解されたい。

図１は、本開示のいくつかの実施形態を実施可能な通信環境１００の概略図である。図１に示すように、第１デバイス１１０、第２デバイス１２０、及び第３デバイス１３０は、第４デバイス１０５のカバレージにある。言い換えれば、第４デバイス１０５は、第１デバイス１１０、第２デバイス１２０、及び第３デバイス１３０にサービスを提供し、それらに無線接続を提供することができる。特に、第１デバイス１１０は、通信チャネル１１２を介して第４デバイス１０５と通信してもよく、第２デバイス１２０は、通信チャネル１２２を介して第４デバイス１０５と通信してもよく、第３デバイス１３０は、通信チャネル１３２を介して第４デバイス１０５と通信してもよい。

第４デバイス１０５から第１デバイス１１０、第２デバイス１２０、又は第３デバイス１３０への送信の場合、通信チャネル１１２、１２２、又は１３２はダウンリンクチャネルと呼ばれることがあり、一方、第１デバイス１１０、第２デバイス１２０、又は第３デバイス１３０から第４デバイス１０５への送信の場合、通信チャネル１１２、１２２、又は１３２は代替的にアップリンクチャネルと呼ばれることがある。さらに、第１デバイス１１０は、サイドリンクチャネル１１５とも呼ばれるデバイス間（Ｄ２Ｄ：ｄｅｖｉｃｅ－ｔｏ－ｄｅｖｉｃｅ）のチャネルを介して第２デバイス１２０と通信してもよい。同様に、第１デバイス１１０は、サイドリンクチャネル１２５を介して第３デバイス１３０と通信してもよく、第２デバイス１２０は、サイドリンクチャネル１３５を介して第３デバイス１３０と通信してもよい。いくつかの場合に、第４デバイス１０５は、通信環境１００に存在しなくてもよい。例えば、第１デバイス１１０、第２デバイス１２０、及び第３デバイス１３０は、第４デバイス１０５のカバレッジ外である。このような場合、第１デバイス１１０、第２デバイス１２０、及び第３デバイス１３０、ならびに図１に示されていない他の可能な端末デバイスの間にサイドリンク通信のみが存在する。

いくつかの実施形態では、第１デバイス１１０、第２デバイス１２０、及び第３デバイス１３０、ならびに可能な他のデバイスは、これらのデバイスの間でサイドリンク送信を行うための同じリソースプールを共有してもよい。複数のデバイスがそれぞれのサイドリンク送信を同時に実行する場合、特にリソースプールに関連付けられる輻輳レベル（輻輳状態とも呼ばれ、例えば、チャネル予約、ＣＲ、又はチャネルビジー率、ＣＢＲなど）が高いと、複数のデバイスがそれらのサイドリンク送信のためにリソースプール内の同一の送信リソースを選択する可能性がある。言い換えれば、第１デバイス１１０がサイドリンク送信を実行するためにリソースプールから送信リソースを選択している場合、第１デバイス１１０と、それらのサイドリンク送信を実行するためにこの送信リソースも選択している他のデバイスとの間で送信リソースの選択衝突が発生する可能性がある。

本明細書で使用される場合、「リソース」、「送信リソース」、又は「サイドリンクリソース」という用語は、時間領域のリソース、周波数領域のリソース、空間領域のリソース、コード領域のリソース、又は通信を可能にする任意の他のリソースなどの、通信、例えば、サイドリンク通信を行うための任意のリソースを指してもよい。従って、「リソースプール」という用語は、時間領域におけるリソースユニット（例えば、タイムスロット）、周波数領域におけるリソースユニット（例えば、サブチャネル）、空間領域におけるリソースユニット、コード領域におけるリソースユニットなどのセットを指してもよい。以下、本開示のいくつかの実施形態を説明するためのサイドリンクリソースの例として、周波数領域と時間領域の両方におけるリソースが使用される。本開示の実施形態は、他の領域における他のリソースにも同等に適用可能であることを理解されたい。

サイドリンク送信の例示的なシナリオでは、第１デバイス１１０は、サイドリンクチャネル１１５を介してデータ１４０を第２デバイス１２０に送信してもよい。いくつかの実施形態では、データ１４０は、ユニキャスト送信を介して送信されてもよく、この場合に、第２デバイス１２０が唯一の所期の受信デバイス（宛先デバイスとも呼ばれる）である。いくつかの他の実施形態では、データ１４０は、グループキャスト送信を介して送信されてもよく、この場合に、第２デバイス１２０が所期の受信デバイスのグループのうちの１つである。いくつかのさらなる実施形態では、データ１４０は、ブロードキャスト送信又は他の任意の適切な送信方法を介して送信されてもよい。本明細書で使用されるとき、データ１４０は、ユーザープレーンデータ、制御プレーンデータなどの、サイドリンクチャネルを介して送信されることができる任意のデータを含んでもよい。例えば、データ１４０は、ＴＢ又はパケットであってもよい。

第１デバイス１１０から送信されたデータ１４０に対して、受信デバイスとしての第２デバイス１２０は、データ１４０が第２デバイス１２０によって正常に受信されたか否かを示すフィードバック（例えば、ＨＡＲＱフィードバック）を第１デバイス１１０に提供することが可能である。データ１４０が第２デバイス１２０によって正常に受信された場合、第２デバイス１２０は、第１デバイス１１０に肯定的なフィードバック（肯定応答、略してＡＣＫとも呼ばれる）を提供してもよい。逆に、データ１４０が第２デバイス１２０によって正常に受信されなかった場合、第２デバイス１２０は、第１デバイス１１０に否定的なフィードバック（否定応答、略してＮＡＣＫとも呼ばれる）を提供してもよい。本明細書で使用するとき、このようなフィードバックを提供するための通信チャネルは、ＡＣＫ／ＮＡＣＫチャネルと呼ばれることがある。同様に、データ１４０がグループキャスト送信を介して送信される場合、所期の受信デバイスのグループのうちの他の受信デバイスも、それぞれのフィードバックを、それぞれのＡＣＫ／ＮＡＣＫチャネルを介して第１デバイス１１０に送信することができる。

以下、物理サイドリンクフィードバックチャネル（ＰＳＦＣＨ：ｐｈｙｓｉｃａｌ ｓｉｄｅｌｉｎｋ ｆｅｅｄｂａｃｋ ｃｈａｎｎｅｌ）がＡＣＫ／ＮＡＣＫチャネルの一例として使用されることがある。一般的に、ＰＳＦＣＨは、３ＧＰＰ会議での最近の合意で定義されており、ＰＳＦＣＨを介してユニキャスト及びグループキャスト用のサイドリンクフィードバック制御情報（ＳＦＣＩ：ｓｉｄｅｌｉｎｋ ｆｅｅｄｂａｃｋ ｃｏｎｔｒｏｌ ｉｎｆｏｒｍａｔｉｏｎ）を伝送することがサポートされる。しかしながら、本明細書で使用されるＡＣＫ／ＮＡＣＫチャネルは、ＰＳＦＣＨに限定されず、他のデバイスによって送信されたデータに対する肯定的なフィードバック又は否定的なフィードバックを提供するための任意の適切なチャネルを参照してもよいことを理解されたい。

さらに、いくつかの実施形態では、サイドリンク通信において肯定的なフィードバック又は否定的なフィードバックを送信するために、受信デバイスは、２つの異なるＡＣＫ／ＮＡＣＫ送信モードのうちの１つを採用してもよい。第１ＡＣＫ／ＮＡＣＫ送信モードは、ＡＣＫ／ＮＡＣＫチャネルにおいて受信デバイスによる受信成功を示す信号がない、ＨＡＲＱフィードバックのオプション１とも呼ばれてもよい。第２ＡＣＫ/ＮＡＣＫ送信モードは、ＡＣＫ/ＮＡＣＫチャネルにおけるＡＣＫが受信デバイスによる受信成功を示す、ＨＡＲＱフィードバックのオプション２とも呼ばれてもよい。

特に、ＨＡＲＱフィードバックのオプション１及びオプション２に関して、以下のようにいくつかの合意が得られている。オプション１の場合、受信側ＵＥは、関連する物理サイドリンク制御チャネル（ＰＳＣＣＨ：ｐｈｙｓｉｃａｌ ｓｉｄｅｌｉｎｋ ｃｏｎｔｒｏｌ ｃｈａｎｎｅｌ）を復号した後、対応するＴＢを復号できなかった場合、ＰＳＦＣＨ上でＨＡＲＱ－ＮＡＣＫを送信する。それ以外の場合、ＰＳＦＣＨ上で信号を送信しない。オプション２の場合、受信側ＵＥは対応するＴＢの復号に成功した場合、ＰＳＦＣＨ上でＨＡＲＱ－ＡＣＫを送信する。また、受信側ＵＥは、受信側ＵＥをターゲットとする関連ＰＳＣＣＨを復号した後、対応するＴＢの復号に成功しなかった場合、ＰＳＦＣＨ上でＨＡＲＱ－ＮＡＣＫを送信する。２つのＡＣＫ／ＮＡＣＫ送信モードが例として上述されたが、本開示の実施形態は、他の既存又は将来のＡＣＫ／ＮＡＣＫ送信モードにも同等に適用可能であることを理解されたい。

第１デバイス１１０が、第２デバイス１２０から（ユニキャスト送信の場合）、又は所期の受信デバイスのグループのうちの任意の受信デバイスから（グループキャスト送信の場合）ＮＡＣＫを受信する場合、第１デバイス１１０は、リソースプールから選択された再送リソース１５０を使用してデータ１４０を再送する必要がある。再送リソース１５０を選択する際に、サイドリンク送信を実行するために同じく当該再送リソース１５０を選択している他のデバイスとの衝突の可能性を回避するために、第１デバイス１１０は、例えば、データ１４０の最初の送信用の送信リソースがリソースプールから、又はデータ１４０の以前の送信に関連付けられるシグナリングによって選択される時点で、再送リソース１５０を事前に予約することができる。

第１デバイス１１０による再送リソース１５０の予約は、予約情報１６０によって、同じリソースプールを共有する他のデバイスに通知されることができる。これらの他のデバイスには、第２デバイス１２０及び第３デバイス１３０も含まれることに留意されたい。予約情報１６０は、データ１４０の潜在的な再送のために、再送リソース１５０が第１デバイス１１０によって予約されていることを示してもよい。再送リソース１５０の予約により、第１デバイス１１０がデータ１４０に対するＮＡＣＫを受信した場合、第１デバイス１１０は、データ１４０を再送すると判定した後に利用可能なリソースを再度選択する代わりに、再送リソース１５０を使用してデータ１４０を再送することができる。第１デバイス１１０がいずれの受信デバイスからもＮＡＣＫを受信しない場合、第１デバイス１１０はデータ１４０を再送する必要がなく、再送リソース１５０を解放してもよく、これは、再送リソース１５０が他のデバイス及び第１デバイス１１０自身による他のサイドリンク送信に利用可能であることを意味する。

いくつかの実施形態では、第１デバイス１１０、第２デバイス１２０、及び第３デバイス１３０は、端末デバイスであってもよく、第４デバイス１０５は、ネットワークデバイスであってもよい。いくつかの他の実施形態では、第１デバイス１１０、第２デバイス１２０、及び第３デバイス１３０、並びに第４デバイス１０５は、互いに通信可能な他の任意の適切な通信デバイスであってもよい。本開示の実施形態は、図１の例示的なシナリオに限定されない。この点に関して、図１では、第１デバイス１１０、第２デバイス１２０、及び第３デバイス１３０が携帯電話として概略的に描かれているが、この描写は、いかなる限定を示唆することなく、例示的なものに過ぎないことを理解されたい。他の実施形態では、第１デバイス１１０、第２デバイス１２０、及び第３デバイス１３０は、例えば、車載端末デバイスなど、他の任意の無線通信デバイスであってもよい。

第１デバイス１１０、第２デバイス１２０、及び第３デバイス１３０が車載端末デバイスである場合、第１デバイス１１０、第２デバイス１２０、及び第３デバイス１３０に関連する通信は、Ｖ２Ｘ通信と呼ばれることがある。より一般的には、図１に示されていないが、第１デバイス１１０、第２デバイス１２０、又は第３デバイス１３０に関連するＶ２Ｘ通信は、第１デバイス１１０、第２デバイス１２０、又は第３デバイス１３０と、他の通信デバイスとの間の通信を構成してもよく、ここでの他の通信デバイスは、インフラ装置、他の車載端末デバイス、歩行者のデバイス、路側機等を含むが、これらに限定されない。さらに、図示されていないが、図１に示すような全ての通信リンクは、１つ以上のリレーを経由してもよい。

図１に示されるような通信デバイスの数は、いかなる限定を示唆することなく、説明のためのものに過ぎないことを理解されたい。通信環境１００は、本開示の実施形態の実施に適した任意の適切な数の通信デバイスを含んでもよい。さらに、これらの追加の通信デバイスの間には、様々な有線通信、（必要な場合）及び無線通信が存在してもよいことを理解されたい。

通信環境１００における通信は、任意の適切な規格に準拠してもよく、ここでの規格は、モバイル通信用グローバルシステム（ＧＳＭ：Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）、ＥＣ‐ＧＳＭ‐ＩｏＴ（Ｅｘｔｅｎｄｅｄ Ｃｏｖｅｒａｇｅ Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）、ロングタームエボリューション（ＬＴＥ：Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）、ＬＴＥエボリューション（ＬＴＥ－Ｅｖｏｌｕｔｉｏｎ）、ＬＴＥアドバンスト（ＬＴＥ－Ａ：ＬＴＥ－Ａｄｖａｎｃｅｄ）、広帯域符号分割多元接続（Ｗ－ＣＤＭＡ：Ｗｉｄｅｂａｎｄ Ｃｏｄｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）、符号分割多元接続（ＣＤＭＡ：Ｃｏｄｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）、ＧＳＭ ＥＤＧＥ無線アクセスネットワーク（ＧＥＲＡＮ：ＧＳＭ ＥＤＧＥ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）などを含むが、これらに限定されない。さらに、通信は、現在知られている、又は将来に開発される任意の世代の通信プロトコルに従って実施されることができる。通信プロトコルの例として、第１世代（１Ｇ）、第２世代（２Ｇ）、２．５Ｇ、２．７５Ｇ、第３世代（３Ｇ）、第４世代（４Ｇ）、４．５Ｇ、第５世代（５Ｇ）の通信プロトコルが挙げられるが、これらに限定されない。

上述したように、サイドリンク通信におけるデバイスは、同じＴＢの以前の送信に関連付けられるシグナリングによって、潜在的な将来のデータの再送用の再送リソースを予約できることが合意されている。しかし、この再送リソースの予約にはいくつかの問題がある可能性がある。具体的には、送信デバイスによって肯定的なフィードバックが受信された場合、即ち、再送が必要ない場合、予約リソースは未使用のままであるので、無駄になる。この問題は、オーバーブッキング問題として知られ、非効率的なリソース利用をもたらす可能性がある。いくつかのシミュレーション結果によると、ＨＡＲＱによる再送の確率は約１０％しかない。これは、ＨＡＲＱによる再送のリソースの９０％がオーバーブッキングされ、明示的又は暗黙的に解放されることを意味する。従って、オーバーブッキングの問題を緩和し、予約デバイスによって使用されていない予約リソースを適切に処理する必要がある。

上記のオーバーブッキングの問題に対処するためのアプローチが提案されている。このアプローチでは、ある条件下で送信リソースがさらなる端末デバイスによって予約されている場合でも、端末デバイスが当該送信リソースを選択することができる。前記条件とは、送信リソース上の基準信号受信電力（ＲＳＲＰ：ｒｅｆｅｒｅｎｃｅ ｓｉｇｎａｌ ｒｅｃｅｉｖｅｄ ｐｏｗｅｒ）の測定値がＲＳＲＰ閾値以下であること、又は、端末デバイスによって送信されるデータが、さらなる端末デバイスによって再送されるデータよりも重要であることであってもよい。しかしながら、このアプローチにはいくつかの欠点がある。例えば、このアプローチでは、端末デバイスによって予約されている送信リソースは、ＲＳＲＰ又は優先度が低いため、依然として別の端末デバイスによって使用可能であり、これは送信リソースの予約の本来の意図に反している。再送が必要でない限り、予約されている送信リソースが他の端末デバイスによって占有されるべきではないことは適切である。

従来のソリューションにおける上記の技術問題及び潜在的な他の技術問題を解決するために、本開示の実施形態は、サイドリンクチャネルにおける再送用のリソース予約のためのソリューションを提供する。本開示の実施形態の主な考え方は、再送用の再送リソースを予約する際にデータの送信デバイスの動作を定義して不要な予約を避け、かつデータの受信ＵＥの動作及び解放されたリソースを使用する他のＵＥの動作を定義することである。本開示の実施形態により、フィードバックによる再送用のリソース予約を可能にするサイドリンク通信用のリソースプールのより良いリソース利用を達成する。本開示の原理及び実施について、図面を参照しながら以下に詳細に説明する。

図２は、本開示のいくつかの実施形態にかかる例示的な方法２００のフローチャートを示す。いくつかの実施形態では、方法２００は、図１に示すような第１デバイス１１０などの端末デバイスで実施されることができる。追加的に又は代替的に、方法２００は、図１に示されていない他の通信デバイスで実施されることもできる。説明の目的のために、方法２００は、一般性を損なうことなく、第１デバイス１１０によって実行されるように、図１を参照して説明される。

ブロック２１０において、第１デバイス１１０と第２デバイス１２０との間のサイドリンク通信において、第１デバイス１１０は、サイドリンクチャネル１１５を介して第２デバイス１２０に送信されようとするデータ１４０を生成する。データ１４０の最初の送信のために、第１デバイス１１０は、第１デバイス１１０と、第２デバイス１２０及び第３デバイス１３０を含む別のデバイスとによって共有されるリソースプールから送信リソースを選択してもよい。上述したように、第１デバイス１１０が第２デバイス１２０から（ユニキャスト送信の場合）、又は所期の受信デバイスのグループのうちの任意の受信デバイスから（グループキャスト送信の場合）ＮＡＣＫを受信すると、第１デバイス１１０は、リソースプールから選択される再送リソース１５０を使用してデータ１４０を再送する必要がある場合がある。

同様に、再送されたデータ１４０に対して、第２デバイス１２０（ユニキャスト送信の場合）又は所期の受信デバイス（グループキャスト送信の場合）は、第１デバイス１１０にＡＣＫ／ＮＡＣＫフィードバックを提供することができる。第１デバイス１１０が、第２デバイス１２０から（ユニキャスト送信の場合）、又は所期の受信デバイスのグループの任意の受信デバイスから（グループキャスト送信の場合）再びＮＡＣＫを受信すると、第１デバイス１１０は、リソースプールから選択される第２再送リソースを使用してデータ１４０の２回目の再送を実行する必要がある場合がある。データ１４０の複数回の再送は、同様の方法で実行されることができる。

以下、図３に示すリソースプールの例を参照しながら、上記の送信プロシージャ及び再送プロシージャについて詳述する。なお、本説明書では、分かりやすくするために、データ１４０のユニキャスト送信を例とすることがある。しかしながら、本開示の実施形態は、グループキャスト送信を含む他の送信方法にも同等に適用可能であることを理解されたい。

図３は、本開示のいくつかの実施形態にかかる端末デバイス間のサイドリンク通信用のリソースを含むリソースプール３００の概略図である。図３において、横軸は時間を表し、縦軸は周波数を表し、各ブロックは、サイドリンク送信用の送信リソースを表す。いくつかの実施形態では、１つのブロックは、時間領域におけるタイムスロット、及び周波数領域におけるサブチャネルに対応する。しかしながら、１つのブロックは、時間領域における任意の他の適切な時間単位及び周波数領域における任意の他の適切な周波数単位に対応してもよいことを理解されたい。

図３の例では、第１デバイス１１０が、時点Ｔ０でデータ１４０を生成すると想定されている。次に、第１デバイス１１０は、データ１４０を送信するために、リソースプール３００から送信リソース３１０を選択してもよい。送信リソース３１０の開始時点は、時点Ｔ１である。その後、第１デバイス１１０は、送信リソース３１０を使用してデータ１４０の最初の送信を実行することができる。第２デバイス１２０がデータ１４０を正常に受信しなかった場合、第２デバイス１２０は、時点Ｔ２でＮＡＣＫを送信してもよい。

第２デバイス１２０からＮＡＣＫを受信すると、第１デバイス１１０は、データ１４０を第２デバイス１２０に再送してもよい。第１デバイス１１０が再送リソースの予約を行わない場合、第１デバイス１１０は、第２デバイス１２０からＮＡＣＫを受信した後に、データ１４０の再送用の送信リソースを再び選択することができる。しかし、リソースプール３００は、サイドリンク送信を行うための複数のデバイスによって共有されるため、最も早く再送に利用可能なリソースは、時点Ｔ２から相対的に離れている可能性がある。この場合、データ１４０を送信するための遅延が相対的に大きくなることがあり、これは望ましくない。

データ１４０の再送用の再送リソースの選択衝突の可能性を回避するために、第１デバイス１１０は、データ１４０が最初に送信される前に、特に送信リソース３１０が第１デバイス１１０によって選択されると同時に、データ１４０の潜在的な再送用の再送リソースを予約してもよい。同様に、第１デバイス１１０は、データ１４０の可能な２回目の再送用の第２再送リソース３３０を予約してもよく、図３に示されていないが、より多くの可能な再送のために、より多くのリソースが第１デバイス１１０によって予約されることができる。予約リソースの数は、構成可能であってもよい。

データ１４０の１回目の再送について、第２デバイス１２０は、時点Ｔ４でＡＣＫ／ＮＡＣＫフィードバックを提供することもできる。１回目の再送に対するフィードバックが再びＮＡＣＫである場合、第１デバイス１１０は、データ１４０の２回目の再送を実行するために、時点Ｔ５での第２再送リソース３３０を使用することができる。１回目の再送に対するフィードバックがＡＣＫである場合、第１デバイス１１０は、第２再送リソース３３０を解放してもよい。データ１４０のより多くの再送及びより多くの予約リソースの解放は、同様の方法で実行されてもよい。

データ１４０の送信失敗の比較的低い確率（例えば、前述のように１０％）を考慮すると、第１デバイス１１０が、サイドリンクチャネルを介して送信されるデータを有するとき常に再送リソースを予約することは不利であり、これにより、リソースプール３００内のリソースの非効率な利用をもたらす可能性がある。

従って、図２に戻って、ブロック２２０において、サイドリンクチャネル１１５を介して第２デバイス１２０に送信されようとするデータ１４０を生成した後、第１デバイス１１０は、データ１４０の再送用の再送リソース１５０を予約するための予約基準が満たされたか否かを判定する。予約基準が満たされた場合、第１デバイス１１０は、将来の潜在的な再送のために再送リソース１５０を予約すると判定する。そうでない場合、第１デバイス１１０は、再送リソース１５０を予約せず、第２デバイス１２０からＮＡＣＫを受信した後に、データ１４０の再送を行うための送信リソースを選択することが可能である。このように、第１デバイス１１０は、送信しようとするデータがあるとき常に再送リソースを予約するのではなく、予約基準に基づいて再送リソースを選択的に予約するので、第１デバイス１１０による不要な予約を有利に回避することができる。

いくつかの実施形態では、第１デバイス１１０は、様々な予約基準のうちの１つ又は複数で構成されることができる。例えば、第１デバイス１１０は、サービス品質（ＱｏＳ）レベルを使用して、再送リソース１５０を予約するか否かを判定することができる。ここでのＱｏＳレベルは、データ１４０のＱｏＳレベル又はデータ１４０の送信ＱｏＳレベルを含んでもよい。前者は、パケット遅延や信頼性要件など、データ１４０自身に対するＱｏＳ要求を示してもよい。後者は、データ１４０に関連付けられる送信に対するＱｏＳ要求を示してもよい。例えば、データ１４０の再送は、データ１４０の最初の再送よりも高いＱｏＳ要求を有してもよい。いくつかの実施形態では、ＱｏＳレベルは、上位層構成、又はサイドリンク送信に関連付けられるサイドリンク制御情報（ＳＣＩ：ｓｉｄｅｌｉｎｋ ｃｏｎｔｒｏｌ ｉｎｆｏｒｍａｔｉｏｎ）で搬送されるＱｏＳパラメータから導出されることができる。

従って、データ１４０のＱｏＳレベルが構成可能な閾値（第１閾値とも呼ばれる）を超える場合、即ち、データ１４０が高いＱｏＳ要求を有する場合、第１デバイス１１０は再送リソース１５０を予約することができる。そうでない場合、第１デバイス１１０は再送リソース１５０を予約しなくてもよい。同様に、データ１４０の送信ＱｏＳレベルが構成可能な閾値（第２閾値とも呼ばれる）を超える場合、即ち、データ１４０に関連付けられる送信が高いＱｏＳ要求を有する場合、第１デバイス１１０は再送リソース１５０を予約することができる。そうでない場合、第１デバイス１１０は再送リソース１５０を予約しなくてもよい。いくつかの実施形態では、第１及び第２閾値は、上位層（データリンク層又はネットワーク層など）からのパラメータであってもよく、又は予め構成されてもよい。

代替的又は追加的に、第１デバイス１１０は、データ１４０の優先度を使用して、再送リソース１５０を予約するか否かを判定してもよい。いくつかの実施形態では、データ１４０の優先度は、上位層構成、又はサイドリンク送信に関連付けられるＳＣＩで搬送される優先度フィールドから導出されることができる。従って、データ１４０の優先度が構成可能な閾値（第３閾値とも呼ばれる）を超える場合、即ち、データ１４０の重要度が高い場合、第１デバイス１１０は再送リソース１５０を予約することができる。そうでない場合、第１デバイス１１０は再送リソース１５０を予約しなくてもよい。いくつかの実施形態では、第３閾値は、上位層からのパラメータであってもよく、又は予め構成されてもよい。

代替的又は追加的に、第１デバイス１１０は、第１デバイス１１０の利用可能な送信電力を使用して、再送リソース１５０を予約するか否かを判定することができる。１つのオプションにおいて、第１デバイス１１０の利用可能な送信電力が構成可能な閾値（第４閾値とも呼ばれる）を超える場合、即ち、第１デバイス１１０が追加の情報を送信するための余分な電力を有する場合、第１デバイス１１０は再送リソース１５０を予約することができる。そうでない場合、第１デバイス１１０は再送リソース１５０を予約しなくてもよい。いくつかの実施形態では、第４閾値は、上位層からのパラメータであってもよく、又は予め構成されてもよい。

別のオプションとして、第１デバイス１１０の利用可能な送信電力が、さらなる構成可能な電力閾値以下である場合、即ち、第２デバイス１２０がデータ１４０を受信することに失敗する確率がより高い場合、第１デバイス１１０は、再送リソース１５０を予約することができる。そうでない場合、第１デバイス１１０は、再送リソース１５０を予約しなくてもよい。いくつかの実施形態では、さらなる構成可能な電力閾値は、上位層からのパラメータであってもよく、又は予め構成されてもよい。

代替的又は追加的に、第１デバイス１１０は、利用可能な再送リソースに関連付けられる時間間隔を使用して、再送リソース１５０を予約するか否かを判定することができる。特に、図３を参照すると、第２デバイス１２０がデータ１４０に対するＡＣＫ／ＮＡＣＫを送信する時点Ｔ２と利用可能な再送リソース１５０の開始時点である時点Ｔ３との間の時間間隔（第１時間間隔とも呼ばれる）が、構成可能な閾値（第５閾値とも呼ばれる）よりも短い場合、即ち、データ１４０の再送が大きな遅延を起こさない場合、第１デバイス１１０は再送リソース１５０を予約することができる。図３に示すように、時点Ｔ２及びＴ３は関連付けられるリソースブロックの開始を示すが、他の実施形態では、時点Ｔ２及びＴ３は代替的に関連付けられるリソースブロックの終了を示すことがあることに留意されたい。

そうでない場合、第１時間間隔が第５閾値よりも長い場合、第１デバイス１１０は再送リソース１５０を予約しなくてもよい。この場合、第１デバイス１１０が予約を実行するときに占有されている送信リソースは、第１デバイス１１０がＮＡＣＫを受信した後に解放される可能性があるので、第１デバイス１１０は第２デバイス１２０からＮＡＣＫを受信した後に、より前の送信リソースを選択することが可能であることがあると留意されたい。いくつかの実施形態では、第５閾値は、上位層からのパラメータであってもよく、又は予め構成されてもよい。

代替的に又は追加的に、第１デバイス１１０は、データ１４０の遅延バジェットを使用して、再送リソース１５０を予約するか否かを判定してもよい。特に、図３を参照すると、データ１４０の遅延バジェットが、データ１４０が生成される時点Ｔ０と利用可能な再送リソース１５０の開始時点である時点Ｔ３との間の時間間隔（第２時間間隔とも呼ばれる）を超える場合、即ち、データ１４０の再送に関連付けられる遅延がデータ１４０の遅延バジェット以下である場合、第１デバイス１１０は再送リソース１５０を予約することができる。そうでない場合、第１デバイス１１０は再送リソース１５０を予約しなくてもよい。図３に示すように、時点Ｔ３は利用可能な再送リソース１５０の開始を示すが、他の実施形態では、時点Ｔ３は代替的に利用可能な再送リソース１５０の終了を示す場合があることに留意されたい。

いくつかの他の実施形態では、第１デバイス１１０は、遅延バジェットを、構成可能な閾値（第６閾値とも呼ばれる）と比較して、再送リソース１５０を予約するか否かを判定することができる。従って、データ１４０の遅延バジェットが第６閾値以下である場合、即ち、データ１４０が緊急のデータである場合、第１デバイス１１０は、再送リソース１５０を予約することができる。そうでない場合、第１デバイス１１０は再送リソース１５０を予約しなくてもよい。いくつかの実施形態では、第６閾値は、上位層からのパラメータであってもよく、又は予め構成されてもよい。

代替的に又は追加的に、第１デバイス１１０は、リソースプール３００に関連付けられる輻輳レベルを使用して、再送リソース１５０を予約するか否かを判定してもよい。従って、リソースプール３００に関連付けられる輻輳レベルが構成可能な閾値（第７閾値とも呼ばれる）を超える場合、即ち、予約が実行されないと、利用可能な再送リソースの選択に衝突が生じる確率が高い場合、第１デバイス１１０は再送リソース１５０を予約することができる。そうでない場合、第１デバイス１１０は再送リソース１５０を予約しなくてもよい。いくつかの実施形態では、第７閾値は、上位層からのパラメータであってもよく、又は予め構成されてもよい。いくつかの実施形態では、第７閾値は、データ１４０が高い優先度を有する場合に再送リソース１５０を確実に予約できるように、データ１４０の優先度と関連付けられてもよい。例えば、高い優先度を有するＴＢに対して、低い第７閾値が構成されることができる。

代替的又は追加的に、第１デバイス１１０は、再送回数を使用して、再送リソース１５０を予約するか否かを判定してもよい。特に、データ１４０の再送回数が構成可能な閾値（第８閾値とも呼ばれる）以下である場合、第１デバイス１１０は、再送リソース１５０を予約することができる。そうでない場合、第１デバイス１１０は再送リソース１５０を予約しなくてもよい。即ち、第１デバイス１１０は、データ１４０の最初のＮ回の再送に対してリソースを予約することができる。数Ｎは、予め構成されることができる。いくつかの実施形態では、データ１４０の最後の再送に対して予約が行われない。

いくつかの実施形態では、図３に示されているように、時間領域における再送リソース１５０の位置は、第２デバイス１２０がデータ１４０に対するＡＣＫ／ＮＡＣＫを送信する時点Ｔ２の後であってもよい。言い換えれば、時間領域における再送リソース１５０の開始時点である時点Ｔ３は、時点Ｔ２よりも後であってもよい。これにより、第１デバイス１１０は、第２デバイス１２０からＮＡＣＫを受信する前にデータ１４０の再送を行うことができないため、第１デバイス１１０が時間領域における時点Ｔ２以前の送信リソースを使用してデータ１４０を再送することができず、第１デバイス１１０による無駄な予約を効果的に回避することができる。従って、第１デバイス１１０によって予約されることができる最も早い利用可能なリソースは、関連するＰＳＦＣＨの時点Ｔ２の後であることができ、ＰＳＦＣＨの周期及びＰＳＳＣＨのスロットインデックスの構成に応じて決定されることができる。

図２に戻って、ブロック２３０において、第１デバイス１１０は予約基準が満たされたと判定した場合、第１デバイス１１０は、予約情報１６０を別のデバイスに送信する。当該別のデバイスは、第２デバイス１２０及び第３デバイス１３０を含む。予約情報１６０は、再送リソース１５０が第１デバイス１１０によって予約されていることを示すので、別のデバイスは、再送リソース１５０が第１デバイス１１０によって予約されていることを考慮して、リソースプール３００から送信リソースを選択してそのサイドリンク送信を実行することが可能である。

第１デバイス１１０は、任意の適切な方法で予約情報１６０を送信してもよい。例えば、第１デバイス１１０は、既存のシグナリングのコンテンツ及び構造を変更することなく、予約情報１６０を送信するために新しい専用のシグナリングを使用してもよい。別の例として、第１デバイス１１０は、既存のシグナリングを十分に活用するように、サイドリンク通信用の既存のシグナリングに予約情報１６０を含めることができる。特に、第１デバイス１１０は、予約情報１６０をＳＣＩに含め、ＳＣＩを第２デバイス１２０及び他のデバイスに送信してもよい。１つのオプションにおいて、予約情報１６０を含むＳＣＩは、データ１４０の前回の送信のＳＣＩ（第１ＳＣＩとも呼ばれる）であってもよい。別のオプションにおいて、予約情報１６０を含むＳＣＩは、データ１４０の前回の送信用の送信リソースを予約するためのＳＣＩ（第２ＳＣＩとも呼ばれる）であってもよい。

時間領域及び周波数領域における再送リソース１５０の位置を示すために、予約情報１６０を含むＳＣＩは、時間位置インジケータ及び周波数位置インジケータをさらに含むことができる。時間位置インジケータは、時間領域における再送リソース１５０の位置を示し、周波数位置インジケータは、周波数領域における再送リソース１５０の位置を示す。例えば、データ１４０の最初の送信のＳＣＩは、時間領域及び周波数領域における第１再送リソース１５０の位置を示すことができ、データ１４０の１回目の再送のＳＣＩは、時間領域及び周波数領域における第２再送リソース３３０の位置を示すことができる、などである。

言い換えれば、再送リソースが前回の送信に関連付けられるＳＣＩに示され、送信リソースのＳＣＩは、次の再送用の送信リソースを示すことができる。この指示アプローチは、チェーン方式と呼ばれてもよく、データ１４０の送信に関連付けられる複数のＳＣＩに、全ての予約送信リソースの時間位置インジケータと周波数位置インジケータを分配して、ＳＣＩにおけるシグナリングオーバーヘッドを均等化することができる。

このチェーン方法での指示アプローチの例として、再送予約があるか否かを示すように、フィードバックによる再送リソース予約のフラグフィールドをＳＣＩに定義してもよい。ＳＣＩにおいて、再送予約がない場合、フラグフィールドは０に設定され、時間オフセットフィールドはＳＣＩの末尾に０でパディングされ、周波数オフセット又は周波数位置フィールドもＳＣＩの末尾に０でパディングされることができる。あるいは、再送予約がある場合、フラグフィールドを１に設定し、時間オフセットフィールドと周波数オフセット又は周波数位置フィールドをＳＣＩの末尾に定義することができる。時間オフセットフィールドは、ＳＣＩのタイムスロットインデックスに対するオフセットを示し、例えば、スロット数又はシンボル数で表されることができる。周波数オフセット又は周波数位置フィールドは、ＳＣＩの周波数位置に対するオフセットを示し、例えば、サブチャネル数で表されることができる。他のデバイスは、ＳＣＩを復号した後、再送予約の有無及び予約リソースの位置を知ることができる。

他の例示的な指示アプローチとして、予約情報１６０を含むＳＣＩは、数インジケータ、時間位置インジケータ、及び周波数位置インジケータを含んでもよい。数インジケータは、データ１４０の複数の再送のための再送リソースの数を示し、時間位置インジケータは、時間領域における再送リソースの複数の位置を示し、周波数位置インジケータは、周波数領域における再送リソースの複数の位置を示している。このようにして、データ１４０の送信に関連付けられる他のＳＣＩに影響を与えることなく、全ての予約送信リソースの時間位置インジケータ及び周波数位置インジケータを、１つのＳＣＩに含めることができる。

例えば、フィードバックによる再送リソース予約のフラグフィールドは、データ１４０の再送用の予約リソースの数を示すように、最初の送信のＳＣＩ又は最初の送信の予約ＳＣＩにおいて定義されることが可能である。ＳＣＩにおいて、再送予約がない場合、フラグフィールドは０に設定され、時間オフセットフィールドはＳＣＩの末尾に０でパディングされ、周波数オフセット又は周波数位置フィールドもＳＣＩの末尾に０でパディングされることができる。あるいは、再送予約がある場合、フラグフィールドは、再送リソースの数、即ち、データ１４０の再送回数を示す。時間オフセットフィールドと周波数オフセット又は周波数位置フィールドはＳＣＩの末尾に定義されることができる。時間オフセットフィールドは、各送信のタイムスロットインデックスに対するオフセットを示し、例えば、スロット数で表される。周波数オフセット又は周波数位置フィールドは、各送信の周波数位置に対するオフセットを示し、例えば、サブチャネル数で表される。他のデバイスは、ＳＣＩを復号した後、再送予約の有無及び予約リソースの位置を知ることができる。

別の例として、時間オフセットフィールドは、時間領域におけるすべての予約リソースの位置を示すことができる。例えば、時間オフセットフィールドは、時間領域におけるＳＣＩに対する全部の予約リソースのすべての時間オフセット値を含んでもよい。周波数オフセット又は周波数位置フィールドは、周波数領域におけるすべての予約リソースの位置を示すことができる。例えば、周波数オフセット又は周波数位置フィールドは、周波数領域におけるＳＣＩに対する全部の予約リソースのすべての周波数オフセット値を含んでもよい。上述したような特定のフィールド及びその特定の値は、本開示の範囲に関するいかなる限定も示唆することなく、単なる例示に過ぎないことを理解されたい。他の実施形態では、ＳＣＩは、インジケータとして使用される任意の適切な値を有する任意の適切なフィールドを有してもよい。

上記において、いくつかの実施形態は、サイドリンク送信の送信デバイス（例えば、第１デバイス１１０）の観点から説明された。以下、図４を参照しながら、いくつかの他の実施形態をサイドリンク送信の受信デバイス（例えば、第２デバイス１２０）の観点から説明する。

図４は、本開示のいくつかの実施形態にかかる別の例示的な方法４００のフローチャートを示す。いくつかの実施形態では、方法４００は、図１に示すような第２デバイス１２０などの端末デバイスで実施されることができる。追加的に又は代替的に、方法４００は、図１に示されていない他の通信デバイスで実施されることもできる。説明の目的のために、方法４００は、一般性を損なうことなく、第２デバイス１２０によって実行されるように、図１を参照して説明される。

ブロック４１０において、第２デバイス１２０は、第１デバイス１１０から予約情報１６０を受信する。予約情報１６０は、再送リソース１５０が、サイドリンクチャネル１１５を介する第１デバイス１１０から第２デバイス１２０へのデータ１４０の再送のために予約されていることを示す。上述したように、再送リソース１５０は、第２デバイス１２０及び別のデバイスのサイドリンク通信用のリソースプール３００に含まれる。別のデバイスは、第１デバイス１１０及び第３デバイス１３０を含む。

ブロック４２０において、第１デバイス１１０から予約情報１６０を受信した後、第２デバイス１２０は、第２デバイス１２０から別のデバイスの少なくとも１つへのサイドリンク送信に対する再送リソース１５０の利用可能性を判定する。言い換えれば、第２デバイス１２０が、同じリソースプール３００を共有する他のデバイス（第１デバイス１１０及び第３デバイス１３０を含む）に対してサイドリンク送信を行う場合、第２デバイス１２０は、その自身のサイドリンク送信に、予約情報１６０に示された再送リソース１５０が利用可能であるか否か、即ち、第２デバイス１２０が、その自身のサイドリンク送信を行うために、この第１デバイス１１０によって予約されている再送リソース１５０を使用できるか否かを判定する必要がある。

一般的に、第２デバイス１２０は第１デバイス１１０が再送リソース１５０を使用してデータ１４０を再送しないと判定できる場合、第２デバイス１２０は、その自身のサイドリンク送信に、再送リソース１５０が利用可能であると判定してもよい。逆に、第２デバイス１２０は第１デバイス１１０が再送リソース１５０を使用してデータ１４０を再送する必要があると判定できる場合、第２デバイス１２０は、その自身のサイドリンク送信に、再送リソース１５０が利用不可能であると判定してもよい。さらに、第１デバイス１１０が再送リソース１５０を使用してデータ１４０を再送する必要があるか否かについて第２デバイス１２０が知ることができない場合、第２デバイス１２０は、その自身のサイドリンク送信に、再送リソース１５０が利用不可能であると判定することもできる。

言い換えれば、再送リソース１５０の利用可能性を判定するために、第２デバイス１２０は、第１デバイス１１０が再送リソース１５０を使用してデータ１４０を再送する必要があるか否か、即ち、データ１４０が、当該データ１４０の所期の受信デバイスによって正常に受信されたか否かを知る必要がある。この目的のために、第２デバイス１２０は、データ１４０がグループキャスト送信又はユニキャスト送信のいずれで送信されるかを最初に判定することができ、それは、データ１４０を再送する必要があるか否かに関する第２デバイス１２０による判定が、これら２つの送信方式によって異なるからである。グループキャスト送信では、第１デバイス１１０は、第２デバイス１２０を含むデバイスのグループにデータ１４０を送信し、一方、ユニキャスト送信では、第１デバイス１１０は、第２デバイス１２０にのみデータ１４０を送信する。

いくつかの実施形態では、データ１４０がグループキャスト送信を介して送信される場合、第２デバイス１２０は、その自身のサイドリンク送信に再送リソース１５０が利用不可能であると直接判定することができる。即ち、データ１４０のグループキャスト送信の場合、受信デバイスの観点からは、データ１４０が受信デバイス自身によって正常に受信及び復号されたか否かにかかわらず、予約された再送リソース１５０が第１デバイス１１０によって占有され、受信デバイス自身のサイドリンク送信のために選択されることができないと見なされてもよい。

データ１４０は、グループキャスト送信でデバイスのグループに送信され、第２デバイス１２０は、受信グループ内の他の受信デバイスから第１デバイス１１０へのＡＣＫ／ＮＡＣＫチャネルを監視しなければ、他の受信デバイスがデータ１４０を正常に受信したか否かを知ることができないからである。そこで、第２デバイス１２０が再送リソース１５０の利用可能性を判定するための簡易ルールとして、第２デバイス１２０は、グループ送信において再送リソース１５０を利用不可能と見なしてもよい。このように、第２デバイス１２０の動作を大幅に簡略化することができる。

あるいは、データ１４０のグループキャスト送信において、第２デバイス１２０は、グループキャスト送信のＡＣＫ／ＮＡＣＫ送信モードに基づいて、他の受信デバイスから第１デバイス１１０へのＡＣＫ／ＮＡＣＫチャネルを監視するか否かを判定することができる。例えば、図１を参照して説明したように、グループキャスト送信の受信デバイスは、第１デバイス１１０にＡＣＫ／ＮＡＣＫを送信するための２つの異なるＡＣＫ／ＮＡＣＫ送信モードのうちの１つを採用してもよい。第１ＡＣＫ／ＮＡＣＫ送信モードは、ＡＣＫ／ＮＡＣＫチャネルにおいて受信成功を示す信号がない、ＨＡＲＱフィードバックのオプション１とも呼ばれてもよい。また、第２ＡＣＫ／ＮＡＣＫ送信モードは、ＡＣＫ／ＮＡＣＫチャネルにおいて受信成功を示すＡＣＫが存在する、ＨＡＲＱフィードバックのオプション２とも呼ばれてもよい。

オプション１がグループキャスト送信の受信デバイスによって使用される場合には、第２デバイス１２０によってデータ１４０が正常に受信されると、第２デバイス１２０はＡＣＫを送信する必要がない。つまり、サイドリンク通信における第２デバイス１２０は一般的に半二重動作を用いるが、第２デバイス１２０は、他の受信デバイスから第１デバイス１１０へのＰＳＦＣＨを監視して、その自身のサイドリンク送信に再送リソース１５０が利用可能であるか否かを判定することができる。監視の結果に応じて、第２デバイス１２０がＡＣＫ／ＮＡＣＫチャネルのいずれにおいても信号を検出しなかった場合、即ち、すべての他の受信デバイスがデータ１４０を正常に受信した場合、第１デバイス１１０は再送リソース１５０を使用してデータ１４０を再送する必要がないため、第２デバイス１２０は、その自身のサイドリンク送信に再送リソース１５０が利用可能であると判定することができる。

反対的に、第２デバイス１２０がＡＣＫ／ＮＡＣＫチャネルのいずれかにおいて信号を検出した場合、即ち、他の受信デバイスのうちの１つ又は複数がデータ１４０を正常に受信しなかった場合、第１デバイス１１０が再送リソース１５０を使用してデータ１４０を再送する必要があるので、第２デバイス１２０は、その自身のサイドリンク送信に再送リソース１５０が利用不可能であると判定することができる。このように、第２デバイス１２０は、他の受信デバイスのＡＣＫ／ＮＡＣＫチャネルを監視することが可能である場合、再送リソース１５０の利用可能性の判定の正確さを高めることができる。

同様に、データ１４０が第２デバイス１２０によって正常に受信されなかった場合、即ち、第２デバイス１２０がＰＳＦＣＨでＮＡＣＫを送信する必要があるので、半二重制限のために他の受信デバイスのＰＳＦＣＨを監視する機会がない場合、第２デバイス１２０は、他の受信デバイスがデータ１４０を正常に受信したか否かを知ることができないので、再送リソース１５０がサイドリンク送信に利用不可能であると判定してもよい。さらに、この状況では、第２デバイス１２０は、その自身にデータ１４０を再送する必要があることを知ることができ、これも再送リソース１５０の利用可能性に対しての否定判定につながる。このように、第２デバイス１２０の動作を簡略化することができる。

グループキャスト送信と対照的に、データ１４０は第２デバイス１２０がデータ１４０の唯一の所期の受信デバイスであるユニキャスト送信で送信される場合、第２デバイス１２０による再送リソース１５０の利用可能性の判定は、より簡単になる。従って、データ１４０が第２デバイス１２０によって正常に受信された場合、第２デバイス１２０は、その自身のサイドリンク送信に再送リソース１５０が利用可能である、即ち、再送リソース１５０が第１デバイス１１０によって解放されると判定することができる。反対的に、データ１４０が第２デバイス１２０によって正常に受信されなかった場合、第２デバイス１２０は、再送リソース１５０が第１デバイス１１０によってデータ１４０を第２デバイス１２０に再送するために使用されるので、自身のサイドリンク送信に再送リソース１５０が利用不可能であると判定することができる。このように、第２デバイス１２０は、ユニキャスト送信の場合に、再送リソース１５０の利用可能性を正確に判定することができる。

ブロック４３０において、第２デバイス１２０は、再送リソース１５０の利用可能性に基づいて、リソースプール３００から自身のサイドリンク送信用の送信リソースを選択する。より具体的には、第２デバイス１２０が、再送リソース１５０が利用可能であると判定した場合、第２デバイス１２０は、再送リソース１５０を当該第２デバイス１２０自身のサイドリンク送信用の送信リソースの候補として見なすことができ、これにより、リソースプール３００のリソース利用率を増加させることができる。

一方、第２デバイス１２０は再送リソース１５０が利用不可能であると判定した場合、第２デバイス１２０は、第１デバイス１１０との再送リソース１５０における潜在的な送信衝突を回避するように、再送リソース１５０を当該第２デバイス１２０自身のサイドリンク送信用の送信リソースの候補として見なさなくてもよい。このように、送信デバイスである第１デバイス１１０からのサイドリンク送信における受信デバイスである第２デバイス１２０は、送信デバイスが解放した送信リソースを利用することができる。

同様に、データ１４０の送信デバイスとしての第１デバイス１１０も、再送リソース１５０の利用可能性に基づいて、リソースプール３００から別のサイドリンク送信用の送信リソースを選択してもよい。例えば、第１デバイス１１０が第２デバイス１２０からデータ１４０に対するＮＡＣＫを受信しなかった場合（ユニキャスト送信の場合）、又は所期の受信デバイスのいずれからもデータ１４０に対するＮＡＣＫを受信しなかった場合（グループキャスト送信の場合）、第１デバイス１１０は再送リソース１５０を使用してデータ１４０を再送する必要がない。この場合、第１デバイス１１０は、再送リソース１５０が利用可能であると判定することができるので、再送リソース１５０を第１デバイス１１０の別のサイドリンク送信用の送信リソースの候補として見なすことができ、これにより、リソースプール３００のリソース利用率を増加させることができる。

一方、第１デバイス１１０が第２デバイス１２０からデータ１４０に対するＮＡＣＫを受信した場合（ユニキャスト送信の場合）、又は所期の受信デバイスのいずれかからデータ１４０に対するＮＡＣＫを受信した場合（グループキャスト送信の場合）、第１デバイス１１０は再送リソース１５０を使用してデータ１４０を再送する必要がある。この場合、第１デバイス１１０は、再送リソース１５０が利用不可能であると判定することができ、このため、再送リソース１５０を第１デバイス１１０の別のサイドリンク送信用の送信リソースの候補として見なさなくてもよい。

上記において、サイドリンク送信の送信デバイス（例えば、第１デバイス１１０）及び受信デバイス（例えば、第２デバイス１２０）の観点からいくつかの実施形態を説明した。以下、図５を参照して、いくつかの他の実施形態について、サイドリンク送信の送信デバイス及び受信デバイス以外のデバイス（例えば、第３デバイス１３０）の観点から説明する。

図５は、本開示のいくつかの実施形態にかかるさらなる例示的な方法５００のフローチャートである。いくつかの実施形態では、方法５００は、図１に示されるような第３デバイス１３０などの端末デバイスで実施されることができる。追加的に又は代替的に、方法５００は、図１に示されていない他の通信デバイスで実施されることもできる。説明の目的のために、方法５００は、一般性を損なうことなく、第３デバイス１３０によって実行されるように、図１を参照して説明される。

ブロック５１０において、第３デバイス１３０は、例えばサイドリンクチャネル１２５を介して、第１デバイス１１０から予約情報１６０を受信する。上述したように、第１デバイス１１０は、第２デバイス１２０とサイドリンク通信しており、例えば、第１デバイス１１０は、サイドリンクチャネル１１５を介して第２デバイス１２０にデータ１４０を送信する。予約情報１６０は、サイドリンクチャネル１１５を介する第１デバイス１１０から第２デバイス１２０へのデータ１４０の再送のために、再送リソース１５０が予約されていることを示す。上述のように、再送リソース１５０は、第３デバイス１３０及び別のデバイスのサイドリンク通信用のリソースプール３００に含まれる。別のデバイスは、第１デバイス１１０及び第２デバイス１２０を含む。

第１デバイス１１０から予約情報１６０を受信した後、第３デバイス１３０は、予約情報１６０に示された再送リソース１５０が、第３デバイス１３０から第１デバイス１１０及び第２デバイス１２０を含む別のデバイスへのサイドリンク送信に利用可能であるか否か、即ち、第３デバイス１３０が、この第１デバイス１１０が予約している再送リソース１５０を利用して当該第３デバイス１３０自身のサイドリンク送信を実行できるか否かを判定する必要がある。

この目的のために、ブロック５２０において、第３デバイス１３０は、第２デバイス１２０から第１デバイス１１０へのＡＣＫ／ＮＡＣＫチャネルを監視して、第１デバイス１１０が再送リソース１５０を使用してデータ１４０を再送しようとするか否かを判定する。例えば、第３デバイス１３０は、第１デバイス１１０から第２デバイス１２０への関連するＰＳＳＣＨ（例えば、予約された再送の先行ＰＳＳＣＨ）のＰＳＦＣＨ、即ち、第２デバイス１２０のＰＳＦＣＨを監視してもよい。

いくつかの実施形態では、第３デバイス１３０の監視動作は、上位層によって構成又は予め構成されることができる。例えば、上位層は、第３デバイス１３０が第２デバイス１２０から第１デバイス１１０へのＡＣＫ／ＮＡＣＫチャネルを監視するか否かを構成することができる。第３デバイス１３０がＡＣＫ／ＮＡＣＫチャネルを監視するように構成されている場合、第３デバイス１３０は、監視の結果に基づいて再送リソース１５０の利用可能性を判定してもよい。第３デバイス１３０がＡＣＫ／ＮＡＣＫチャネルを監視するように構成されていない場合、第３デバイス１３０は、第１デバイス１１０が再送リソース１５０を使用してデータ１４０を再送しようとするか否かに関する情報を有していないので、再送リソース１５０を利用不可能と見なしてもよい。

いくつかの他の実施形態において、第３デバイス１３０は、予め定義された監視基準に基づいて、ＡＣＫ／ＮＡＣＫチャネルを監視するか否かを判定してもよい。例えば、ＡＣＫ／ＮＡＣＫチャネルを監視する前に、第３デバイス１３０は、監視基準が満たされたか否かを判定してもよい。監視基準が満たされた場合、第３デバイス１３０は、ＡＣＫ／ＮＡＣＫチャネルを監視し、監視の結果に基づいて再送リソース１５０の利用可能性を判定することができる。そうでない場合、第３デバイス１３０は、ＡＣＫ／ＮＡＣＫチャネルを監視せず、第１デバイス１１０が再送リソース１５０を使用してデータ１４０を再送しようとするか否かについて分からないので、再送リソース１５０を利用不可能と見なすことができる。このようにして、第３デバイス１３０によるＡＣＫ／ＮＡＣＫチャネルの不要な監視を回避することができる。

いくつかの実施形態では、第３デバイス１３０は、様々な監視基準のうちの１つ又は複数で構成されることができる。例えば、第３デバイス１３０は、ＱｏＳレベルを使用して、ＡＣＫ／ＮＡＣＫチャネルを監視するか否かを判定することができる。ＱｏＳレベルは、第３デバイス１３０のデータのＱｏＳレベル、又は第３デバイス１３０のデータの送信ＱｏＳレベルを含んでもよい。前者は、パケット遅延／信頼性要求など、第３デバイス１３０のデータ自身に対するＱｏＳ要求を示してもよい。後者は、第３デバイス１３０のデータに関連付けられる送信に対するＱｏＳ要求を示してもよい。いくつかの実施形態では、ＱｏＳレベルは、上位層構成、又はＳＣＩで搬送されるＱｏＳパラメータから導出されることができる。

従って、第３デバイス１３０によって送信されるデータのＱｏＳレベルが構成可能な閾値（第９閾値とも呼ばれる）を超える場合、即ち、第３デバイス１３０のデータが高いＱｏＳ要求を有する場合、第３デバイス１３０はＡＣＫ／ＮＡＣＫチャネルを監視することができる。そうでない場合、第３デバイス１３０は、ＡＣＫ／ＮＡＣＫチャネルを監視しなくてもよい。同様に、第３デバイス１３０のデータの送信ＱｏＳレベルが構成可能な閾値（第１０閾値とも呼ばれる）を超える場合、即ち、第３デバイス１３０のデータに関連付けられる送信が高いＱｏＳ要求を有する場合、第３デバイス１３０はＡＣＫ／ＮＡＣＫチャネルを監視することができる。そうでない場合、第３デバイス１３０は、ＡＣＫ／ＮＡＣＫチャネルを監視しなくてもよい。いくつかの実施形態では、第９及び第１０閾値は、上位層からのパラメータであってもよく、又は予め構成されてもよい。

代替的に又は追加的に、第３デバイス１３０は、第３デバイス１３０のデータの優先度を使用して、ＡＣＫ／ＮＡＣＫチャネルを監視するか否かを判定してもよい。いくつかの実施形態では、第３デバイス１３０のデータの優先度は、上位層構成、又はＳＣＩで搬送される優先度フィールドから導出されることができる。これにより、第３デバイス１３０のデータの優先度が構成可能な閾値（第１１閾値とも呼ばれる）を超える場合、即ち、第３デバイス１３０のデータの重要度が高い場合、第３デバイス１３０はＡＣＫ／ＮＡＣＫチャネルを監視することができる。そうでない場合、第３デバイス１３０はＡＣＫ／ＮＡＣＫチャネルを監視しなくてもよい。いくつかの実施形態では、第１１閾値は、上位層からのパラメータであってもよく、又は予め構成されてもよい。

別のオプションとして、第３デバイス１３０は、送信されるデータの優先度をデータ１４０の優先度と比較することができる。このオプションでは、第３デバイス１３０のデータの優先度がデータ１４０の優先度を超える場合、即ち、第３デバイス１３０のデータがデータ１４０よりも重要である場合、第３デバイス１３０はＡＣＫ／ＮＡＣＫチャネルを監視することができる。そうでない場合、第３デバイス１３０はＡＣＫ／ＮＡＣＫチャネルを監視しなくてもよい。

代替的又は追加的に、第３デバイス１３０は、第３デバイス１３０の利用可能な送信電力を使用して、ＡＣＫ／ＮＡＣＫチャネルを監視するか否かを判定してもよい。これにより、第３デバイス１３０の利用可能な送信電力が構成可能な閾値（第１２閾値とも呼ばれる）を超える場合、即ち、第３デバイス１３０がＡＣＫ／ＮＡＣＫチャネルを監視するための余分な電力を有する場合、第３デバイス１３０はＡＣＫ／ＮＡＣＫチャネルを監視することができる。そうでない場合、第３デバイス１３０は、ＡＣＫ／ＮＡＣＫチャネルを監視しなくてもよい。いくつかの実施形態では、第１２閾値は、上位層からのパラメータであってもよく、又は予め構成されてもよい。

代替的に又は追加的に、第３デバイス１３０は、リソースプール３００に関連付けられる輻輳レベルを使用して、ＡＣＫ／ＮＡＣＫチャネルを監視するか否かを判定してもよい。これにより、リソースプール３００に関連付けられる輻輳レベルが構成可能な閾値（第１３閾値とも呼ばれる）を超える場合、即ち、第３デバイス１３０のサイドリンク送信に利用可能なリソースの数が少ない場合、第３デバイス１３０はＡＣＫ／ＮＡＣＫチャネルを監視することができる。そうでない場合、第３デバイス１３０はＡＣＫ／ＮＡＣＫチャネルを監視しなくてもよい。いくつかの実施形態では、第１３閾値は、上位層からのパラメータであってもよく、又は予め構成されてもよい。さらに、第１３閾値は、第３デバイス１３０のデータの優先度と関連付けられてもよい。例えば、より高い優先度を有するＴＢに対して、より低い第１３閾値が構成されることができる。

代替的又は追加的に、第３デバイス１３０は、その自身のサイドリンク送信のデータの遅延バジェットを使用して、ＡＣＫ／ＮＡＣＫチャネルを監視するか否かを判定してもよい。特に、第３デバイス１３０のデータの遅延バジェットが構成可能な閾値（第１４閾値とも呼ばれる）以下である場合、即ち、第３デバイス１３０のデータが緊急のデータである場合、第３デバイス１３０はＡＣＫ／ＮＡＣＫチャネルを監視することができる。そうでない場合、第３デバイス１３０はＡＣＫ／ＮＡＣＫチャネルを監視しなくてもよい。いくつかの実施形態では、第１４閾値は、上位層からのパラメータであってもよく、又は予め構成されてもよい。

ブロック５３０において、監視の結果に基づいて、第３デバイス１３０は、リソースプール３００を共有する別のデバイスの少なくとも１つへのサイドリンク送信に対する再送リソース１５０の利用可能性を判定する。第２デバイス１２０について説明した場合と同様に、データ１４０を再送する必要があるか否かに関する第３デバイス１３０による判定は、グループキャスト送信又はユニキャスト送信の２つの送信方法によって異なるため、第３デバイス１３０は、最初にデータ１４０がグループキャスト送信又はユニキャスト送信のいずれを介して送信されるかを判定することができる。

第１デバイス１１０と第２デバイス１２０との間のサイドリンク通信がユニキャスト送信を含む場合、データ１４０は第２デバイス１２０にのみ送信される。この場合、第３デバイス１３０が、第２デバイス１２０から第１デバイス１１０へのＡＣＫ／ＮＡＣＫチャネルにおいてＡＣＫを検出すると、第３デバイス１３０は、その自身のサイドリンク送信に再送リソース１５０が利用可能であると判定することができる。ＡＣＫは、第１ＡＣＫ／ＮＡＣＫ送信モード、即ち、ＨＡＲＱフィードバックのオプション１において、ＡＣＫ／ＮＡＣＫチャネルに信号がないことによって表されることに留意されたい。第３デバイス１３０が第２デバイス１２０から第１デバイス１１０へのＡＣＫ／ＮＡＣＫチャネルにおいてＮＡＣＫを検出すると、第３デバイス１３０は、その自身のサイドリンク送信に再送リソース１５０が利用不可能であると判定することができる。このように、第３デバイス１３０は、データ１４０がユニキャスト送信で送信される場合、再送リソース１５０の利用可能性を正確に判定することができる。

第１デバイス１１０と第２デバイス１２０との間のサイドリンク通信がグループキャスト送信を含む場合、データ１４０は、第２デバイス１２０を含む所期の受信デバイスのグループに対して送信される。この場合、ＡＣＫ／ＮＡＣＫ送信モードが異なると、監視態様が異なる可能性があるため、第３デバイス１３０は、どのＡＣＫ／ＮＡＣＫ送信モードがグループキャスト送信に使用されるかをさらに判定する必要がある。

グループキャスト送信に第１ＡＣＫ／ＮＡＣＫ送信モードが使用される場合、グループキャスト送信の受信デバイスは、受信成功を示すための信号を送信しない。この場合、第３デバイス１３０が、受信デバイスから第１デバイス１１０へのＡＣＫ／ＮＡＣＫチャネルのいずれにおいても信号を検出しなかった場合、即ち、すべての受信デバイスがデータ１４０を正常に受信した場合、第３デバイス１３０は、その自身のサイドリンク送信に再送リソースが利用可能であると判定することができる。第３デバイス１３０がＡＣＫ／ＮＡＣＫチャネルのいずれかにおいて信号を検出した場合、即ち、受信デバイスの少なくとも１つがデータ１４０を正常に受信しなかった場合、第３デバイス１３０は、その自身のサイドリンク送信に再送リソースが利用不可能であると判定することができる。このように、第３デバイス１３０は、データ１４０がグループキャスト送信で送信され、かつグループキャスト送信に第１ＡＣＫ／ＮＡＣＫ送信モードが使用される場合、再送リソース１５０の利用可能性を正確に判定することができる。

グループキャスト送信に第２ＡＣＫ／ＮＡＣＫ送信モードが使用される場合、グループキャスト送信の受信デバイスは、受信成功を示すためにＡＣＫを送信する。この場合、各受信デバイスは、第１デバイス１１０が異なる受信デバイスからのＡＣＫ／ＮＡＣＫフィードバックを区別できるように、その識別子を使用してそのＡＣＫ／ＮＡＣＫフィードバックをスクランブルすることができる。従って、第３デバイス１３０は、受信デバイスの識別子を使用して、受信デバイスから第１デバイス１１０へのＡＣＫ／ＮＡＣＫチャネルを復号化することができる。例えば、第３デバイス１３０は、グループキャスト送信における宛先デバイスのすべての識別子を、予め構成され、又は無線リソース制御（ＲＲＣ）シグナリングを介して通知されることができる。そして、第３デバイス１３０は、各識別子をスクランブルシーケンスとして使用して、受信デバイスから第１デバイス１１０へのＰＳＦＣＨのそれぞれを復号することができる。

第３デバイス１３０が、ＡＣＫ／ＮＡＣＫチャネルのいずれにおいてもＮＡＣＫを検出しなかった場合、即ち、すべての受信デバイスがデータ１４０を正常に受信した場合、第３デバイス１３０は、その自身のサイドリンク送信に再送リソース１５０が利用可能であると判定することができる。第３デバイス１３０が、ＡＣＫ／ＮＡＣＫチャネルのいずれかにおいてＮＡＣＫを検出した場合、即ち、受信デバイスがデータ１４０を正常に受信しなかった場合、第３デバイス１３０は、再送リソース１５０がサイドリンク送信に利用不可能であると判定することができる。このように、第３デバイス１３０は、データ１４０がグループキャスト送信で送信され、かつ第２ＡＣＫ／ＮＡＣＫ送信モードがグループキャスト送信に使用される場合、再送リソース１５０の利用可能性を正確に判定することができる。

ブロック５４０において、再送リソース１５０の利用可能性に基づいて、第３デバイス１３０は、第３デバイス１３０から第１デバイス１１０及び第２デバイス１２０を含む別のデバイスへの当該第３デバイス１３０自身のサイドリンク送信のために、リソースプール３００から送信リソースを選択する。より具体的には、第３デバイス１３０が、再送リソース１５０が利用可能であると判定した場合、第３デバイス１３０は、再送リソース１５０を当該第３デバイス１３０自身のサイドリンク送信用の送信リソースの候補として見なすことができ、これにより、リソースプール３００のリソース利用率を向上させることができる。

一方、第３デバイス１３０が、再送リソース１５０が利用不可能であると判定した場合、第３デバイス１３０は、第１デバイス１１０との再送リソース１５０における潜在的な送信衝突を回避するように、再送リソース１５０を当該第３デバイス１３０自身のサイドリンク送信用の送信リソースの候補として見なさなくてもよい。このようにして、サイドリンク送信の送信デバイス及び受信デバイス以外の第３デバイス１３０は、送信デバイスが解放したリソースを利用することができる。

図６は、本開示のいくつかの実施形態の実施に適したデバイス６００の簡略化したブロック図である。デバイス６００は、図１に示す第１デバイス１１０、第２デバイス１２０、第３デバイス１３０、及び第４デバイス１０５のさらなる例示的な実施形態とみなすことができる。従って、デバイス６００は、第１デバイス１１０、第２デバイス１２０、第３デバイス１３０、及び第４デバイス１０５の少なくとも一部で実施され、あるいはそれらの少なくとも一部として実施されることができる。

図示されるように、デバイス６００は、プロセッサ６１０と、プロセッサ６１０に接続されているメモリ６２０と、プロセッサ６１０に接続されている適切な送信機（ＴＸ）及び受信機（ＲＸ）６４０と、ＴＸ／ＲＸ６４０に接続されている通信インターフェースとを含む。メモリ６２０は、プログラム６３０の少なくとも一部を格納する。ＴＸ／ＲＸ６４０は、双方向通信用である。ＴＸ／ＲＸ６４０は、通信を容易にするために少なくとも１つのアンテナを有するが、実際には、本願で言及されるアクセスノードは複数のアンテナを有してもよい。通信インターフェースは、ｇＮＢ又はｅＮＢ間の双方向通信用のＸ２インターフェース、モビリティマネジメントエンティティ（ＭＭＥ：Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）／サービングゲートウェイ（Ｓ－ＧＷ：Ｓｅｒｖｉｎｇ Ｇａｔｅｗａｙ）とｇＮＢ又はｅＮＢとの間の通信用のＳ１インターフェース、ｇＮＢ又はｅＮＢとリレーノード（ＲＮ：ｒｅｌａｙ ｎｏｄｅ）との間の通信用のＵｎインターフェース、あるいはｇＮＢ又はｅＮＢと端末デバイスとの間の通信用のＵｕインターフェースなど、他のネットワーク要素との通信に必要な任意のインターフェースを表してもよい。

プログラム６３０は、関連するプロセッサ６１０によって実行されると、デバイス６００が、本明細書で図２、図４及び図５を参照して説明したように、本開示の実施形態に従って動作することを可能にするプログラム命令を含むと想定される。本明細書の実施形態は、デバイス６００のプロセッサ６１０によって実行可能なコンピュータソフトウェアにより、又はハードウェアにより、又はソフトウェアとハードウェアとの組み合わせにより実施されてもよい。プロセッサ６１０は、本開示の様々な実施形態を実施するように構成されてもよい。さらに、プロセッサ６１０とメモリ６２０の組み合わせは、本開示の様々な実施形態の実施に適した処理手段６５０を形成してもよい。

メモリ６２０は、ローカル技術ネットワークに適した任意のタイプのものであってもよく、非限定的な例として、非一時的コンピュータ読み取り可能な記憶媒体、半導体系のメモリデバイス、磁気メモリデバイス及びシステム、光メモリデバイス及びシステム、固定メモリデバイス及びリムーバブルメモリなどの任意の適切なデータ記憶技術を使用して実施されてもよい。デバイス６００には１つのメモリ６２０のみが示されているが、デバイス６００には物理的に別個である複数のメモリモジュールがあってもよい。プロセッサ６１０は、ローカル技術ネットワークに適した任意のタイプのものであってもよく、非限定的な例として、汎用コンピュータ、専用コンピュータ、マイクロプロセッサ、ＤＳＰ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒ）、及びマルチコアプロセッサアーキテクチャに基づくプロセッサのうちの１つ又は複数を含んでもよい。デバイス６００は、メインプロセッサを同期させるクロックに時間的に従属する特定用途向け集積回路チップなどの複数のプロセッサを有してもよい。

本開示の装置及び／又はデバイスに含まれる構成要素は、ソフトウェア、ハードウェア、ファームウェア、又はそれらの任意の組み合わせを含む様々な態様で実施されてもよい。一実施形態では、１つ又は複数のユニットは、ソフトウェア及び／又はファームウェア、例えば、記憶媒体に記憶されたマシン実行可能な命令を使用して実装されてもよい。マシン実行可能な命令に加えて又はその代わりに、装置及び／又はデバイスにおけるユニットの一部又は全部は、少なくとも部分的には１つ又は複数のハードウェアロジックコンポーネントによって実装されてもよい。例えば、使用され得るハードウェアロジックコンポーネントの例示的なタイプには、ＦＰＧＡ（Ｆｉｅｌｄ‐ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）、特定用途向け集積回路（ＡＳＩＣ：Ａｐｐｌｉｃａｔｉｏｎ‐ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）、特定用途向け標準製品（ＡＳＳＰ：Ａｐｐｌｉｃａｔｉｏｎ‐ｓｐｅｃｉｆｉｃ Ｓｔａｎｄａｒｄ Ｐｒｏｄｕｃｔ）、ＳＯＣ（Ｓｙｓｔｅｍ‐ｏｎ‐ａ‐ｃｈｉｐ ｓｙｓｔｅｍ）、ＣＰＬＤ（Ｃｏｍｐｌｅｘ Ｐｒｏｇｒａｍｍａｂｌｅ Ｌｏｇｉｃ Ｄｅｖｉｃｅ）などが含まれるが、これらに限定されない。

一般的に、本開示の様々な実施形態は、ハードウェア又は専用回路、ソフトウェア、ロジック、又はそれらの任意の組み合わせで実施されてもよい。いくつかの態様はハードウェアで実施され、他の態様はコントローラ、マイクロプロセッサ、又は他のコンピューティングデバイスによって実行され得るファームウェア又はソフトウェアで実施されてもよい。本開示の実施形態の様々な態様は、ブロック図、フローチャート、又は他の何らかの画像表現を使用して例示及び説明されたが、本明細書に記載されるこれらのブロック、装置、システム、技術又は方法は、非限定的な例として、ハードウェア、ソフトウェア、ファームウェア、専用回路又はロジック、汎用ハードウェア又はコントローラ又は他のコンピューティングデバイス、又はそれらのいくつかの組み合わせで実施されてもよいことを理解されたい。

本開示は、さらに、非一時的なコンピュータ読み取り可能な記憶媒体に有形に格納された少なくとも１つのコンピュータプログラム製品を提供する。コンピュータプログラム製品は、図２、図４及び図５を参照して上記したプロセス又は方法を実行するために、プログラムモジュールに含まれるものなどの、対象の実プロセッサ又は仮想プロセッサ上のデバイスで実行されるコンピュータ実行可能な命令を含む。一般的に、プログラムモジュールは、特定のタスクを実行したり、特定の抽象データ型を実施したりするルーチン、プログラム、ライブラリ、オブジェクト、クラス、コンポーネント、データ構造などを含む。プログラムモジュールの機能は、様々な実施形態で記載されたプログラムモジュール間で組み合わせる、又は分割されることができる。プログラムモジュールのためのマシン実行可能な命令は、ローカルデバイス又は分散型デバイス内で実行されてもよい。分散型デバイスでは、プログラムモジュールがローカル記憶媒体とリモート記憶媒体の両方に配置されてもよい。

本開示の方法を実行するためのプログラムコードは、１つ又は複数のプログラミング言語の任意の組み合わせで書かれてもよい。これらのプログラムコードは、汎用コンピュータ、専用コンピュータ、又は他のプログラム可能なデータ処理装置のプロセッサ又はコントローラに提供されてもよく、これにより、プログラムコードがプロセッサ又はコントローラによって実行されると、フローチャート及び／又はブロック図に規定される機能／動作が実現される。プログラムコードは、完全にマシンで実行されてもよく、その一部がマシンで実行されてもよく、スタンドアロンのソフトウェアパッケージとして実行されてもよく、一部がマシンで実行され且つ一部がリモートマシンで実行されてもよく、完全にリモートマシン又はサーバで実行されてもよい。

上記プログラムコードは、命令実行システム、装置、又はデバイスによって、又はそれと関連付けられて使用されるためのプログラムを含む、又は格納することができる任意の有形媒体であり得るマシン読み取り可能な媒体で具現化されてもよい。マシン読み取り可能な媒体は、マシン読み取り可能な信号媒体又はマシン読み取り可能な記憶媒体であってもよい。マシン読み取り可能な媒体は、電子、磁気、光学、電磁気、赤外線、又は半導体システム、装置、デバイス、あるいは前記の任意の適切な組み合わせを含んでもよいが、これらに限定されない。マシン読み取り可能な記憶媒体のより具体的な例として、１つ又は複数のワイヤによる電気的接続、ポータブルコンピュータディスケット、ハードディスク、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、消去可能なプログラム可能な読み取り専用メモリ（ＥＰＲＯＭ又はフラッシュメモリ）、光ファイバー、ポータブルコンパクトディスク読み取り専用メモリ（ＣＤ－ＲＯＭ）、光学式ストレージデバイス、磁気ストレージデバイス、又は前記の任意の適切な組み合わせが挙げられる。

さらに、動作が特定の順序で描かれているが、これは、望ましい結果を達成するために、そのような動作が図示の特定の順序又は連続順序で実行されること、又はすべての描かれた動作が実行されることを要求するものとして理解されるべきではない。特定の状況では、マルチタスク及び並列処理が有利である場合がある。同様に、上述した説明にはいくつかの特定の実施形態の詳細が含まれているが、これらは本開示の範囲を限定するものとして解釈されるべきではなく、特定の実施形態に特有の特徴の説明として解釈されるべきである。別々の実施形態の文脈で説明されている特定の特徴は、単一の実施形態に組み合わせて実施されてもよい。逆に、単一の実施形態の文脈で説明されている様々な特徴も、複数の実施形態で別々に、又は任意の適切なサブコンビネーションで実施されてもよい。

本開示は、構造的特徴及び／又は方法論的動作に特有の用語で説明されたが、添付の特許請求の範囲で限定される本開示は、必ずしも上記した特定の特徴又は動作に限定されないことを理解されたい。むしろ、上記した特定の特徴及び動作は、特許請求の範囲を実施する例示的な形態として開示されている。

Claims (22)

1. 通信方法であって、
   第１デバイスで、サイドリンクチャネルを介して第２デバイスに送信されようとするデータを生成することと、
   前記第２デバイスを含む別のデバイス及び前記第１デバイスのサイドリンク通信用のリソースプールに含まれる、前記データの再送用の再送リソースを予約するための予約基準が満たされたか否かを判定することと、
   前記予約基準が満たされたと判定したことに応答して、前記再送リソースが予約されていることを示す予約情報を前記別のデバイスに送信することと、を含む
   方法。
2. 前記予約基準は、
   前記データのサービス品質（ＱｏＳ：ｑｕａｌｉｔｙ ｏｆ ｓｅｒｖｉｃｅ）レベルが第１閾値を超えること、
   前記データの送信ＱｏＳレベルが第２閾値を超えること、
   前記データの優先度が第３閾値を超えること、
   前記第１デバイスの利用可能な送信電力が第４閾値を超えること、
   前記第２デバイスが前記データに対する肯定応答（ＡＣＫ：ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）／否定応答（ＮＡＣＫ：ｎｅｇａｔｉｖｅ ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）を送信する第１時点と、利用可能な再送リソースの開始時点である第２時点との間の第１時間間隔が第５閾値よりも短いこと、
   前記データの遅延バジェットが、前記データが生成された第３時点と前記第２時点との間の第２時間間隔を超える、又は第６閾値以下であること、
   前記リソースプールに関連付けられる輻輳レベルが第７閾値を超えること、及び
   前記データの再送回数が第８閾値以下であること、
   のうちの少なくとも１つを含む
   請求項１に記載の方法。
3. 時間領域における前記再送リソースの位置は、前記第２デバイスが前記データに対するＡＣＫ／ＮＡＣＫを送信する時点の後である、
   請求項１に記載の方法。
4. 前記予約情報を送信することは、前記予約情報を含むサイドリンク制御情報（ＳＣＩ：ｓｉｄｅｌｉｎｋ ｃｏｎｔｒｏｌ ｉｎｆｏｒｍａｔｉｏｎ）を送信することを含み、
   前記ＳＣＩは、
   前記データの前回の送信の第１ＳＣＩと、
   前記データの前記前回の送信用の送信リソースを予約するための第２ＳＣＩと、のうちの少なくとも１つを含む
   請求項１記載の方法。
5. 前記ＳＣＩは、さらに、
   時間領域における前記再送リソースの位置を示す時間位置インジケータと、
   周波数領域における前記再送リソースの位置を示す周波数位置インジケータと、を含む
   請求項４に記載の方法。
6. 前記ＳＣＩは、さらに、
   前記再送リソースを含む、前記データの複数の再送のための再送リソースの数を示す数インジケータと、
   時間領域における前記再送リソースの複数の位置を示す時間位置インジケータと、
   周波数領域における前記再送リソースの複数の位置を示す周波数位置インジケータと、を含む
   請求項４に記載の方法。
7. 通信方法であって、
   第２デバイスで、第１デバイスから、サイドリンクチャネルを介する前記第１デバイスから前記第２デバイスへのデータの再送のために、前記第１デバイスを含む別のデバイス及び前記第２デバイスのサイドリンク通信用のリソースプールに含まれる再送リソースが予約されていることを示す予約情報を受信することと、
   前記別のデバイスのうちの少なくとも１つへのサイドリンク送信に対する前記再送リソースの利用可能性を判定することと、
   前記再送リソースの前記利用可能性に基づいて、前記リソースプールから前記サイドリンク送信用の送信リソースを選択することと、を含む
   方法。
8. 前記再送リソースの前記利用可能性を判定することは、
   前記データがグループキャスト送信を介して送信されることに応答して、前記再送リソースが前記サイドリンク送信に利用不可能あると判定することを含む
   請求項７に記載の方法。
9. 前記再送リソースの前記利用可能性を判定することは、
   前記データがグループキャスト送信を介して送信されることに応答して、
   ＡＣＫ／ＮＡＣＫチャネルにおいて受信成功を示す信号がないＡＣＫ／ＮＡＣＫ送信モードが、前記グループキャスト送信に使用されることに応答し、且つ前記データが前記第２デバイスによって正常に受信されたことに応答して、前記グループキャスト送信の他の受信デバイスから前記第１デバイスへのＡＣＫ／ＮＡＣＫチャネルを監視し、
   前記ＡＣＫ／ＮＡＣＫチャネルのいずれにおいても信号が検出されなかったことに応答して、前記再送リソースが前記サイドリンク送信に利用可能であると判定することを含む、
   請求項７に記載の方法。
10. 前記ＡＣＫ／ＮＡＣＫチャネルのいずれかにおいて信号が検出されたことに応答して、前記再送リソースが前記サイドリンク送信に利用不可能であると判定することをさらに含む
    請求項９に記載の方法。
11. 前記データが前記第２デバイスによって正常に受信されなかったことに応答して、前記再送リソースが前記サイドリンク送信に利用不可能であると判定することをさらに含む
    請求項９に記載の方法。
12. 前記再送リソースの前記利用可能性を判定することは、
    前記データがユニキャスト送信によって送信されることに応答して、
    前記データが前記第２デバイスによって正常に受信されたことに応答して、前記再送リソースが前記サイドリンク送信に利用可能であると判定し、
    前記データが前記第２デバイスによって正常に受信されなかったことに応答して、前記再送リソースが前記サイドリンク送信に利用不可能であると判定することを含む
    請求項７に記載の方法。
13. 通信方法であって、
    第３デバイスで、第２デバイスとサイドリンク通信している第１デバイスから、サイドリンクチャネルを介する前記第１デバイスから前記第２デバイスへの再送のために、前記第１デバイス及び前記第２デバイスを含む別のデバイス、並びに前記第３デバイスのサイドリンク通信用のリソースプールに含まれる再送リソースが予約されていることを示す予約情報を受信することと、
    前記第２デバイスから前記第１デバイスへのＡＣＫ／ＮＡＣＫチャネルを監視することと、
    前記監視の結果に基づいて、前記別のデバイスのうちの少なくとも１つへのサイドリンク送信に対する前記再送リソースの利用可能性を判定することと、
    前記再送リソースの前記利用可能性に基づいて、前記リソースプールから前記サイドリンク送信用の送信リソースを選択することと、を含む
    方法。
14. 前記ＡＣＫ／ＮＡＣＫチャネルを監視することは、
    前記ＡＣＫ／ＮＡＣＫチャネルを監視するための監視基準が満たされたか否かを判定することと、
    前記監視基準が満たされたと判定したことに応答して、前記ＡＣＫ／ＮＡＣＫチャネルを監視することと、を含む
    請求項１３に記載の方法。
15. 前記監視基準は、
    前記サイドリンク送信のデータのＱｏＳレベルが第９閾値を超えること、
    前記サイドリンク送信の送信ＱｏＳレベルが第１０閾値を超えること、
    前記サイドリンク送信の前記データの優先度が第１１閾値、又は前記再送のデータの優先度を超えること、
    前記第３デバイスの利用可能な送信電力が第１２閾値を超えること、
    前記リソースプールに関連付けられる輻輳レベルが第１３閾値を超えること、及び
    前記サイドリンク送信の前記データの遅延バジェットが第１４閾値以下であること、
    のうちの少なくとも１つを含む
    請求項１４に記載の方法。
16. 前記再送リソースの前記利用可能性を判定することは、
    前記第１デバイスと前記第２デバイスとの間の前記サイドリンク通信がユニキャスト送信を含むことに応答して、
    前記ＡＣＫ/ＮＡＣＫチャネルにおいてＡＣＫが検出されたことに応答して、前記再送リソースが前記サイドリンク送信に利用可能であると判定し、
    前記ＡＣＫ/ＮＡＣＫチャネルにおいてＮＡＣＫが検出されたことに応答して、前記再送リソースが前記サイドリンク送信に利用不可能であると判定することを含む
    請求項１３に記載の方法。
17. 前記再送リソースの前記利用可能性を判定することは、
    前記第１デバイスと前記第２デバイスとの間の前記サイドリンク通信がグループキャスト送信を含むことに応答して、
    ＡＣＫ/ＮＡＣＫチャネルにおいて受信成功を示す信号がない第１ＡＣＫ/ＮＡＣＫ送信モードが前記グループキャスト送信に使用されることに応答して、
    前記グループキャスト送信の受信デバイスから前記第１デバイスへのＡＣＫ／ＮＡＣＫチャネルのいずれにおいても信号が検出されなかったことに応答して、前記再送リソースが前記サイドリンク送信に利用可能であると判定し、
    前記ＡＣＫ／ＮＡＣＫチャネルのいずれかにおいて信号が検出されたことに応答して、前記再送リソースが前記サイドリンク送信に利用不可能であると判定することを含む
    請求項１３に記載の方法。
18. ＡＣＫ／ＮＡＣＫチャネルにおけるＡＣＫが受信成功を示す第２ＡＣＫ／ＮＡＣＫ送信モードがグループキャスト送信に使用されることに応答して、
    前記グループキャスト送信の前記受信デバイスから前記第１デバイスへの前記ＡＣＫ／ＮＡＣＫチャネルを、前記受信デバイスの識別子を用いて復号し、
    前記ＡＣＫ／ＮＡＣＫチャネルのいずれにおいてもＮＡＣＫが検出されなかったことに応答して、前記再送リソースが前記サイドリンク送信に利用可能であると判定し、
    前記ＡＣＫ/ＮＡＣＫチャネルのいずれかにおいてＮＡＣＫが検出されたことに応答して、前記再送リソースが前記サイドリンク送信に利用不可能であると判定することをさらに含む
    請求項１７に記載の方法。
19. 第１デバイスであって、
    プロセッサと、
    命令を格納するメモリと、を備え、
    前記メモリ及び前記命令は、前記プロセッサによって、前記第１デバイスに請求項１～６のいずれか一項に記載の方法を実行させる、
    第１デバイス。
20. 第２デバイスであって、
    プロセッサと、
    命令を格納するメモリと、を備え、
    前記メモリ及び前記命令は、前記プロセッサによって、前記第２デバイスに請求項７～１２のいずれか一項に記載の方法を実行させる、
    第２デバイス。
21. 第３デバイスであって、
    プロセッサと、
    命令を格納するメモリと、を備え、
    前記メモリ及び前記命令は、前記プロセッサによって、前記第３デバイスに請求項１３～１８のいずれか一項に記載の方法を実行させる、
    第３デバイス。
22. デバイスの少なくとも１つのプロセッサで実行されると、前記デバイスに請求項１～６、請求項７～１２、請求項１３～１８のいずれか一項に記載の方法を実行させる命令が格納されたコンピュータ読み取り可能な媒体。

Images