(57)【要約】  端末間で直接通信を行う通信装置を提供する。  通信装置は、無線信号を送受信する通信部と、前記通信部による、所定のリソースプールを用いたデータの送信と、前記データの送信先の端末からのフィードバックの受信を制御する制御部を具備する。前記制御部は、前記データの送信用のリソース及び前記データの送信先の端末のための前記フィードバック用リソースを前記所定のリソースプール内で確保し、前記送信先の端末に対してＳＣＩを用いて前記フィードバック用リソースに関する情報を通知するように制御する。
2019064983.tif 000002
【特許請求の範囲】
【請求項１】
無線信号を送受信する通信部と、
前記通信部による、所定のリソースプールを用いたデータの送信と、前記データの送信先の端末からのフィードバックの受信を制御する制御部と、
を具備する通信装置。
【請求項２】
前記制御部は、前記データの送信用のリソース及び前記データの送信先の端末のための前記フィードバック用リソースを前記所定のリソースプール内で確保するように、さらに制御する、
請求項１に記載の通信装置。
【請求項３】
前記制御部は、前記送信先の端末に対して、ＳＣＩ（Ｓｉｄｅｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｉｎｆｏｒｍａｔｉｏｎ）を用いて前記フィードバック用リソースに関する情報を通知するように、さらに制御する、
請求項２に記載の通信装置。
【請求項４】
前記制御部は、前記フィードバック用リソースの前記データの送信用のリソースからのオフセット又は位置情報を、前記ＳＣＩを用いて通知するように、制御する、
請求項３に記載の通信装置。
【請求項５】
前記制御部は、Ｒｅｓｏｕｒｃｅ  ｒｅｓｅｒｖａｔｉｏｎ  ｉｎｄｉｃａｔｏｒを用いて前記フィードバック用リソースを予約するように、さらに制御する、
請求項３に記載の通信装置。
【請求項６】
前記制御部は、前記ＳＣＩで指示した前記フィードバック用リソースと前記予約したフィードバック用リソースとの時間方向又は周波数方向のオフセットを前記ＳＣＩに含めるように、さらに制御する、
請求項５に記載の通信装置。
【請求項７】
前記制御部は、データの送信周期に基づく時間方向のオフセットにより前記フィードバック用リソースを予約するように、さらに制御する、
請求項５に記載の通信装置。
【請求項８】
前記制御部は、送信データの優先度及び周辺で送信されているパケットの優先度の比較に基づいて前記データの送信用のリソースをセンシングするとともに、フィードバックに関して規定した優先度に基づいて前記フィードバック用リソースをセンシングするように、さらに制御する、
請求項２に記載の通信装置。
【請求項９】
前記制御部は、確保した前記フィードバック用リソースを前記送信先の端末に通知するように、さらに制御する、
請求項２に記載の通信装置。
【請求項１０】
前記制御部は、前記データの送信直後を基準として、複数の前記送信先の端末の前記フィードバック用リソースの割り当てを決定する、
請求項９に記載の通信装置。
【請求項１１】
前記制御部は、複数の前記送信先の端末の所定の識別情報に基づく順番に従って、前記データの送信直後からの前記フィードバック用リソースを割り当てる、
請求項１０に記載の通信装置。
【請求項１２】
前記制御部は、前記フィードバックを受信したことに応答して、前記データの再送をさらに制御する、
請求項１に記載の通信装置。
【請求項１３】
前記制御部は、再送上限数、受信したＮＡＣＫ数、送信した前記データの優先度、前記データ及び前記フィードバックを送受信するリンクのチャネル状況、又は、前記送信先の端末におけるデータ再送に関するプロセス状況のうち少なくとも１つからなる条件に基づいて、データ再送を行うかどうかを判断する、
請求項１２に記載の通信装置。
【請求項１４】
端末からのアップリンクの無線信号を受信し、端末へのダウンリンクの無線信号を送信する通信部と、
前記端末間で通信するサイドリンクのためのリソースの割り当てを制御する制御部と、
を具備し、
前記制御部は、前記サイドリンクに割り当てたリソースプール内でフィードバック用リソースを割り当てる、
通信装置。
【請求項１５】
前記制御部は、前記所定のリソースプール内に前記フィードバック用リソースを周期的に割り当てる、
請求項１４に記載の通信装置。
【請求項１６】
前記制御部は、ＳＩＢ（Ｓｙｓｔｅｍ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｂｌｏｃｋ）又はＲＲＣ（Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ）シグナリングを用いて前記フィードバック用リソースに関する情報を前記端末に通知するように、さらに制御する、
請求項１５に記載の通信装置。
【請求項１７】
前記制御部は、符号化多重又はプリアンブル送信を用いて、同じリソースを複数の端末の前記フィードバック用リソースに多重化する、
請求項１５又は１６のいずれかに記載の通信装置。
【請求項１８】
無線信号を送受信する通信部と、
前記通信部による、所定のリソースプールを用いて送信されたデータの受信と、前記データの送信元の端末へのフィードバックの送信を制御する制御部と、
を具備する通信装置。
【請求項１９】
前記制御部は、前記送信元の端末が確保したフィードバック用リソースを用いてフィードバックを送信するように制御する、
請求項１８に記載の通信装置。
【請求項２０】
前記制御部は、基地局が前記所定のリソースプール内に周期的に割り当てたフィードバック用リソースを用いてフィードバックを送信するように制御する、
請求項１８に記載の通信装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本明細書で開示する技術は、端末間で直接通信を行う通信装置に関する。
【背景技術】
【０００２】
将来の自動運転の実現のため、近年、車載通信（Ｖ２Ｘ通信）への期待が高まってきている。Ｖ２Ｘ通信とは、Ｖｅｈｉｃｌｅｔｏ Ｘ通信の略であり、車と「何か」が通信を行うシステムである。ここでの「何か」の例として、Ｖｅｈｉｃｌｅ、 Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ、Ｐｅｄｅｓｔｒｉａｎなどが挙げられる（Ｖ２Ｖ、Ｖ２Ｉ／Ｎ、Ｖ２Ｐ）。【０００３】
自動車向けの無線通信としては、これまで主に、ＩＥＥＥ８０２．１１ｐベースのＤＳＲＣ（Ｄｅｄｉｃａｔｅｄ  Ｓｈｏｒｔ  Ｒａｎｇｅ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ）の開発が進められてきた。近年になり、３ＧＰＰ（Ｔｈｉｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ）において、ＬＴＥ（Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）ベースの車載通信である“ＬＴＥ−ｂａｓｅｄＶ２Ｘ”の標準規格化が行われた。３ＧＰＰにおいては、さらに、５Ｇ（ＮＲ：Ｎｅｗ  Ｒａｄｉｏ）において、Ｖ２Ｘの標準化活動が継続している。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１７−１３９６５９号公報
【特許文献２】特開２０１７−１３９６６１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
本明細書で開示する技術の目的は、端末間で直接通信を行う通信装置を提供することにある。
【課題を解決するための手段】
【０００６】
本明細書で開示する技術の第１の側面は、
無線信号を送受信する通信部と、
前記通信部による、所定のリソースプールを用いたデータの送信と、前記データの送信先の端末からのフィードバックの受信を制御する制御部と、
を具備する通信装置である。第１の側面に係る通信装置は、例えば、Ｖ２Ｘ通信においてサイドリンクの送信端末として好適に動作することができる。【０００７】
前記制御部は、前記データの送信用のリソース及び前記データの送信先の端末のための前記フィードバック用リソースを前記所定のリソースプール内で確保し、確保した前記フィードバック用リソースを前記送信先の端末に通知するように、さらに制御する。【０００８】
また、前記制御部は、前記フィードバックを受信したことに応答して、前記データの再送をさらに制御する。例えば、前記制御部は、再送上限数、受信したＮＡＣＫ数、送信した前記データの優先度、前記データ及び前記フィードバックを送受信するリンクのチャネル状況、又は、前記送信先の端末におけるデータ再送に関するプロセス状況のうち少なくとも１つからなる条件に基づいて、データ再送を行うかどうかを判断する。【０００９】
また、本明細書で開示する技術の第２の側面は、
端末からのアップリンクの無線信号を受信し、端末へのダウンリンクの無線信号を送信する通信部と、
前記端末間で通信するサイドリンクのためのリソースの割り当てを制御する制御部と、
を具備し、
前記制御部は、前記サイドリンクに割り当てたリソースプール内でフィードバック用リソースを割り当てる、
通信装置である。第２の側面に係る通信装置は、例えば、Ｖ２Ｘ通信において基地局として動作することができる。【００１０】
前記制御部は、前記所定のリソースプール内に前記フィードバック用リソースを周期的に割り当てて、前記端末に通知するように、さらに制御する。また、前記制御部は、符号化多重又はプリアンブル送信を用いて、同じリソースを複数の端末の前記フィードバック用リソースに多重化するようにしてよい。【００１１】
また、本明細書で開示する技術の第３の側面は、
無線信号を送受信する通信部と、
前記通信部による、所定のリソースプールを用いて送信されたデータの受信と、前記データの送信元の端末へのフィードバックの送信を制御する制御部と、
を具備する通信装置である。第３の側面に係る通信装置は、例えば、Ｖ２Ｘ通信においてサイドリンクの受信端末として好適に動作することができる。【００１２】
前記制御部は、前記送信元の端末が確保したフィードバック用リソースを用いてフィードバックを送信するように制御する。【００１３】
あるいは、前記制御部は、基地局が前記所定のリソースプール内に周期的に割り当てたフィードバック用リソースを用いてフィードバックを送信するように制御する。
【発明の効果】
【００１４】
本明細書で開示する技術によれば、端末間で直接通信を行う通信装置を提供することができる。【００１５】
なお、本明細書に記載された効果は、あくまでも例示であり、本発明の効果はこれに限定されるものではない。また、本発明が、上記の効果以外に、さらに付加的な効果を奏する場合もある。【００１６】
本明細書で開示する技術のさらに他の目的、特徴や利点は、後述する実施形態や添付する図面に基づくより詳細な説明によって明らかになるであろう。
【図面の簡単な説明】
【００１７】
【図１】図１は、Ｖ２Ｘ通信の概要を示した図である。
【図２】図２は、Ｖ２Ｖ通信の第１のシナリオを示した図である。
【図３】図３は、Ｖ２Ｖ通信の第２のシナリオを示した図である。
【図４】図４は、Ｖ２Ｖ通信の第３のシナリオを示した図である。
【図５】図５は、Ｖ２Ｖ通信の第４のシナリオを示した図である。
【図６】図６は、Ｖ２Ｖ通信の第５のシナリオを示した図である。
【図７】図７は、Ｖ２Ｘ通信が実施される無線通信システムの構成例を模式的に示した図である。
【図８】図８は、車両などの移動体に搭載して用いられる通信装置（ＵＥ）の機能的構成例を模式的に示した図である。
【図９】図９は、フィードバック型サイドリンク通信におけるＨＡＲＱオペレーションの例を示した図である。
【図１０】図１０は、サイドリンク通信時において送信端末が受信端末からのフィードバックに対応するための処理手順を示したフローチャートである。
【図１１】図１１は、サイドリンク通信時において受信端末が送信端末に対して情報をフィードバックするための処理手順を示したフローチャートである。
【図１２】図１２は、基地局がサイドリンクにおけるフィードバック用リソースの割り当てを行う通信シーケンス例を示した図である。
【図１３】図１３は、サイドリンク用のリソースプール内にフィードバック用のリソースプールを設けた様子を示した図である。
【図１４】図１４は、送信端末がサイドリンクにおけるフィードバック用リソースの割り当てを行う通信シーケンス例を示した図である。
【図１５】図１５は、フィードバック用リソースの割り当て例を示した図である。
【図１６】図１６は、受信端末がフィードバック信号を送信するための処理手順を示したフローチャートである。
【図１７】図１７は、受信端末がフィードバック信号を送信するための処理手順を示したフローチャートである。
【図１８】図１８は、データ送信を基準として複数の受信端末にフィードバック用リソースを割り当てた例を示した図である。
【図１９】図１９は、送信端末が再送制御するための処理手順を示したフローチャートである。
【図２０】図２０は、基地局（Ｅ−ＵＴＲＡＮ、ｅＮＢ）として動作する通信装置の機能的構成例を模式的に示した図である。
【発明を実施するための形態】
【００１８】
以下、図面を参照しながら本明細書で開示する技術の実施形態について詳細に説明する。
【００１９】
Ａ．システム構成
車両などの移動体に通信装置を搭載することによって、移動体と種々の対象物との間で直接的な通信が実現される。とりわけ、車両と種々の対象物との間の通信はＶ２Ｘ通信と呼ばれる。図１には、Ｖ２Ｘ通信の概要を示している。図示のように、Ｖ２Ｘ通信として、Ｖ２Ｖ（Ｖｅｈｉｃｌｅ  ｔｏ  Ｖｅｈｉｃｌｅ）通信、Ｖ２Ｉ（Ｖｅｈｉｃｌｅ  ｔｏ  Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）通信、Ｖ２Ｐ（Ｖｅｈｉｃｌｅ  ｔｏ  Ｐｅｄｅｓｔｒｉａｎ）通信、Ｖ２Ｈ（Ｖｅｈｉｃｌｅ  ｔｏ  Ｈｏｍｅ）通信などが挙げられる。また、図示を省略するが、Ｖ２Ｎ（Ｖｅｈｉｃｌｅ  ｔｏ  Ｎｅｔｗｏｒｋ）通信も、Ｖ２Ｘ通信に含まれる。なお、Ｖ２Ｘ通信の１文字目と３文字目は、それぞれ通信の始点と終点を意味しており、通信経路を限定するものではない。例えば、Ｖ２Ｖ通信は、車両同士が直接的に通信することと、基地局などを介して車両同士が間接的に通信することの両方を含む概念である。
【００２０】
Ｖ２Ｖ通信における車両の通信対象として、乗用車（ｐａｓｓｅｎｇｅｒ  ｖｅｈｉｃｌｅ）、商用車（Ｃｏｍｍｅｒｃｉａｌ  ｏｒ  ｆｌｅｅｔ  ｖｅｈｉｃｌｅ）、緊急車両（Ｅｍｅｒｇｅｎｃｙ  ｖｅｈｉｃｌｅ）、輸送車（Ｔｒａｎｓｉｔ  ｖｅｈｉｃｌｅ）などが挙げられる。また、Ｖ２Ｉ通信における車両の通信対象として、セルラーネットワーク（Ｃｅｌｌｕｌｅｒ  ｎｅｔｗｏｒｋ）、データセンタ（Ｄａｔａ  ｃｅｎｔｒｅ）、商用車管理センタ（ｆｌｅｅｔ  ｏｒ  ｆｒｅｉｇｈｔ  ｍａｎａｇｅｍｅｎｔ  ｃｅｎｔｒｅ）、交通管理センタ（Ｔｒａｆｆｉｃ  ｍａｎａｇｅｍｅｎｔ  ｃｅｎｔｒｅ）、気象サービス（Ｗｅａｔｈｅｒ  ｓｅｒｖｉｃｅ）、列車運行センタ（Ｒａｉｌ  ｏｐｅｒａｔｉｏｎ  ｃｅｎｔｒｅ）、駐車システム（Ｐａｒｋｉｎｇ  ｓｙｓｔｅｍ）、料金システム（Ｔｏｌｌ  ｓｙｓｔｅｍ）などが挙げられる。また、Ｖ２Ｐ通信における車両の通信対象として、自転車の運転者（Ｃｙｃｌｉｓｔ）、歩行者用シェルタ（Ｐｅｄｅｓｔｒｉａｎ  ｓｈｅｌｔｅｒ）、自動二輪（Ｍｏｔｏｒｃｙｃｌｅ）などが挙げられる。また、Ｖ２Ｈ通信における車両の通信対象として、家庭用ネットワーク（Ｈｏｍｅ  ｎｅｔｗｏｒｋ）、車庫（Ｇａｒａｇｅ）、商用ネットワーク（Ｅｎｔｅｒｐｒｉｓｅ  ｏｒ  ｄｅｅｌｅｒ  ｎｅｔｗｏｒｋｓ）などが挙げられる。
【００２１】
自動車向けの無線通信としては、これまで主にＩＥＥＥ８０２．１１ｐベースのＤＳＲＣの開発が進められてきたが、近年になり、３ＧＰＰにおいてＬＴＥ−ｂａｓｅｄＶ２Ｘの標準規格化が行われた（前述）。ＬＴＥベースのＶ２Ｘ通信では、基本的なセーフティメッセージなどのやり取りなどがサポートされている。
【００２２】
一方で、さらなるＶ２Ｘ通信の改善をめざし、３ＧＰＰでは５Ｇ技術を用いたｅＶ２Ｘ（ｅｎｈａｎｃｅｄ  Ｖ２Ｘ）通信の検討が行われている。ｅＶ２Ｘ通信では、これまでＬＴＥベースのＶ２Ｘではサポートできなかったような、高信頼性、低遅延、高速通信、及びハイキャパシティを必要とする新たなユースケースをサポートする。ｅＶ２Ｘ向けのユースケース及び要求事項は３ＧＰＰ  ＴＲ２２．８８６に記載されている。ｅＶ２Ｘによってサポートされる主なユースケースとして、以下の（１）〜（４）が挙げられる。
【００２３】
（１）Ｖｅｈｉｃｌｅ  Ｐｌａｔｏｏｎｎｉｎｇ
複数の車両が隊列となり、同じ方向に走行する、隊列走行のユースケースであり、隊列走行を主導する車から隊列走行を制御するための情報をやり取りする。これらの情報のやりとりにより、隊列走行の車間距離をより詰めることが可能となる。
【００２４】
（２）Ｅｘｔｅｎｄｅｄ  Ｓｅｎｓｏｒｓ
センサー関連の情報（データ処理前のＲａｗデータや処理されたデータ）を車車間などで交換することを可能とする。センサー情報は、ローカルセンサーや、周辺の車両やＲＳＵ（Ｒｏａｄ  Ｓｉｄｅ  Ｕｎｉｔ：路側ユニット）や歩行者間のライブビデオイメージやＶ２Ｘアプリケーションサーバーなどを通して集められる。車両はこれらの情報交換により、自身のセンサー情報では得られない情報を入手することができ、より広範囲の環境を認知若しくは認識することが可能となる。多くの情報を交換する必要があるため、通信には高いデータレートが求められる。
【００２５】
（３）Ａｄｖａｎｃｅｄ  Ｄｒｉｖｉｎｇ
準自動走行や、完全自動走行を可能とする。それぞれの車両はＲＳＵが自身のセンサーなどから得られた認知／認識情報を周辺車両へとシェアすることで、車両の軌道や操作を同期、協調しながら調整することができる。それぞれの車両は、ドライビングの意図や意思を周辺車両とシェアすることも可能である。
【００２６】
（４）Ｒｅｍｏｔｅ  Ｄｒｉｖｉｎｇ
遠隔操縦者やＶ２Ｘアプリケーションに遠隔操縦させる。運転ができない人や、危険地域に対して遠隔操作が用いられる。ルートや走行する道がある程度決まっているような公共交通機関に対しては、クラウドコンピューティングをベースとした操縦を用いることも可能である。高い信頼性と低い伝送遅延が通信には求められる。
【００２７】
上述したようなユースケース（１）〜（４）を実現するためには、ｅＶ２Ｘ通信の物理レイヤのエンハンスメントが必要となる。主なエンハンスメントとしては、インフラ、端末間通信の改善、及び端末間通信の改善が挙げられる。インフラ、端末間通信としては、Ｖ２Ｎ通信並びにＶ２Ｉ（ｅＮＢ（ｅｖｏｌｖｅｄ  Ｎｏｄｅ  Ｂ）  ｔｙｐｅ  ＲＳＵ：基地局型ＲＳＵ）通信が改善の対象となる。また、端末間通信としては、Ｖ２Ｖ通信並びにＶ２Ｐ通信が改善の対象となる。これらＶ２Ｘ通信の物理レイヤにおいて必要と考えられる主なエンハンスメントのポイントを以下に示す。
【００２８】
・チャネルフォーマット
−Ｆｌｅｘｉｂｌｅ ｎｕｍｅｒｏｌｏｇｙ
−ｓｈｏｒｔ ＴＴＩ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｔｉｍｅ Ｉｎｔｅｒｖａｌ）
−マルチアンテナ対応
−Ｗａｖｅｆｏｒｍエンハンスメント
・サイドリンクフィードバック通信
−ＨＡＲＱ（Ｈｙｂｒｉｄ  Ａｕｔｏｍａｔｉｃ  Ｒｅｐｅａｔ  Ｒｅｑｕｅｓｔ）
−ＣＳＩ（Ｃｈａｎｎｅｌ  Ｓｔａｔｕｓ  Ｉｎｆｏｒｍａｔｉｏｎ）
・サイドリンク通信におけるリソース割り当て方式
・車両位置情報推定技術
・端末間リレー通信
・ユニキャスト通信、マルチキャスト通信のサポート
・マルチキャリア通信、キャリアアグリゲーション
・高周波周波数（ミリ波）対応（例：６ＧＨｚ以上）
【００２９】
Ｖ２Ｘ通信のオペレーションシナリオはさまざまである。Ｖ２Ｘ通信のオペレーションシナリオは、Ｖ２Ｖ通信をベースに構成され、片方の自動車がＰｅｄｅｓｒｉａｎになるとＶ２Ｐ通信となり、ＩｎｆｒａｓｔｒｕｃｔｕｒｅやＮｅｔｗｏｒｋで終端するとＶ２Ｉ通信又はＶ２Ｎ通信となる。図２〜図６には、Ｖ２Ｘ通信のベースとなるＶ２Ｖ通信のシナリオを例示している。
【００３０】
図２には、Ｖ２Ｖ通信の第１のシナリオを示している。第１のシナリオでは、車両などの移動体同士が直接的にＶ２Ｖ通信を行う。この場合の車両同士が直接的に通信を行う通信リンクは、ＳＬ（サイドリンク）である。
【００３１】
図３には、Ｖ２Ｖ通信の第２のシナリオを示している。第２のシナリオでは、車両などの移動体同士が、Ｅ−ＵＴＲＡＮ（Ｅｖｏｌｖｅｄ  Ｕｎｉｖｅｒｓａ    Ｔｅｒｒｅｓｔｒｉａｌ  Ｒａｄｉｏ  Ａｃｃｅｓｓ）を介して、すなわち基地局を介して間接的にＶ２Ｖ通信を行う。送信側から基地局への通信リンクはＵＬ（アップリンク）であり、基地局から受信側への通信リンクはＤＬ（ダウンリンク）である。
【００３２】
図４には、Ｖ２Ｖ通信の第３のシナリオを示している。第３のシナリオでは、車両などの移動体が、ＲＳＵ又はＲＳＵタイプのユーザ端末（Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ：ＵＥ）、及びＥ−ＵＴＲＡＮを順に介して他の移動体へ信号を送信する。各装置間の通信リンクは、順にＳＬ、ＵＬ、及びＤＬである。
【００３３】
図５には、Ｖ２Ｖ通信の第４のシナリオを示している。第４のシナリオでは、車両などの移動体が、Ｅ−ＵＴＲＡＮ、及びＲＳＵ又はＲＳＵタイプのＵＥを順に介して他の移動体へ信号を送信する。各装置間の通信リンクは、順にＵＬ、ＤＬ及びＳＬである。
【００３４】
図６には、Ｖ２Ｖ通信の第５のシナリオを示している。第５のシナリオでは、車両などの移動体同士が、ＲＳＵ又はＲＳＵタイプのＵＥを介して間接的にＶ２Ｖ通信を行う。移動体とＲＳＵ又はＲＳＵタイプのＵＥとの間の通信リンクは、ＳＬである。
【００３５】
図２〜図６に示した各シナリオは、移動体の片方を歩行者に変えると、Ｖ２Ｐ通信のシナリオとなる。同様に、各シナリオは、移動体の片方をインフラ又はネットワークに変えると、それぞれＶ２Ｉ通信又はＶ２Ｎ通信のシナリオとなる。
【００３６】
本明細書では、ｅＶ２Ｘ通信の物理レイヤのエンハンスメント（前述）のうち、とりわけサイドリンクフィードバック通信に着目する。
【００３７】
これまでのＶ２Ｘ通信においては、サイドリンクはブロードキャスト通信が採用されていた（例えば、特許文献１を参照のこと）。送信端末は受信端末からのフィードバックが得られないことから、初めから複数回繰り返し送信を行うことで信頼性の向上を行っている。すなわち、従来のサイドリンク通信では、物理層レベルでブロードキャスト信号が複数回送信され、受信側では取り敢えずすべての信号を受信して、上位レイヤにおいて受信信号が自分宛かどうかを判断する。したがって、再送の概念がそもそもない。しかしながら、このような繰り返し送信を行うような通信では、再送の仕組みがないことから信頼性を担保することが難しい。また、繰り返し送信により余分に周波数リソースを消費するので、周波数利用効率の観点からもあまり望ましくない。
【００３８】
そこで、本明細書では、受信側からのＨＡＲＱやチャネル情報などのフィードバックをベースに通信を行うフィードバック型サイドリンク通信に関して提案する。受信側がフィードバック信号（例えば、ＡＣＫ／ＮＡＣＫ、伝搬環境情報など）を送信することにより、信頼性が向上する。また、物理層レベルでブロードキャスト信号が複数回送信される場合と比較して、周波数利用効率が向上する。但し、フィードバック型サイドリンク通信の詳細については、後述に譲る。
【００３９】
図７には、Ｖ２Ｘ通信が実施される無線通信システムの構成例を模式的に示している。図示の無線通信システムは、ＵＥ１０と、ＵＥ２０と、車両２２と、ｅＮＢ（基地局）３０と、ＧＮＳＳ（Ｇｌｏｂａｌ  Ｎａｖｉｇａｔｉｏｎ  Ｓａｔｅｌｌｉｔｅ  Ｓｙｓｔｅｍ）衛星４０と、ＲＳＵ５０で構成される。
【００４０】
ｅＮＢ３０は、セル内に位置するＵＥ２０にセルラー通信サービスを提供するセルラー基地局である。例えば、ｅＮＢ３０は、ＵＥ１０及びＵＥ２０が通信するためのリソースをスケジュールし、スケジュールしたリソースをＵＥ１０及びＵＥ２０に通知する。そして、ｅＮＢ３０は、当該リソースにおいてＵＥ１０及びＵＥ２０との間でアップリンク通信又はダウンリンク通信を行う。
【００４１】
ＧＮＳＳ衛星４０は、地球を所定の軌道に沿って周回する人工衛星（通信装置）である。ＧＮＳＳ衛星４０は、航法メッセージを含むＧＮＳＳ信号を送信する。航法メッセージは、ＧＮＳＳ衛星４０の軌道情報及び時間情報などの、位置測定のための種々の情報を含む。
【００４２】
ＲＳＵ５０は、道路脇に設置される通信装置である。ＲＳＵ５０は、車両２２若しくは車両２２に搭載されたＵＥ２０、又はユーザ１２が携行するＵＥ１０と双方向通信を行うことができる。なお、ＲＳＵ５０は、車両２２若しくは車両２２に搭載されたＵＥ２０、又はユーザ１２が携行するＵＥ１０とＤＳＲＣ通信を行うことができる。また、本実施形態では、ＲＳＵ５０が、車両２２若しくは車両２２に搭載されたＵＥ２０、又はユーザ１２が携行するＵＥ１０とセルラー通信の方式に従って通信することも想定される。
【００４３】
ＵＥ２０は、車両２２に搭載され、車両２２の走行に伴って移動する通信装置である。ＵＥ２０は、ｅＮＢ３０による制御に従ってｅＮＢ３０と通信する機能を有する。また、ＵＥ２０は、ＧＮＳＳ衛星４０から送信されるＧＮＳＳ信号を受信し、ＧＮＳＳ信号に含まれる航法メッセージからＵＥ２０の位置情報を測定する機能を有する。また、ＵＥ２０は、ＲＳＵ５０と通信する機能を有する。さらに、本実施形態によるＵＥ２０は、ユーザ１２に携行されるＵＥ１０、又は他の車両２２に搭載されたＵＥ２０と直接通信すること、すなわち、サイドリンクなどのＤ２Ｄ通信を行うことも可能である。以下では、ＵＥ２０及び移動体２２を特に区別する必要がない場合、ＵＥ２０と総称する。
【００４４】
ＵＥ１０は、ユーザ１２に携行され、ユーザ１２の歩行、走行又はユーザ１２が乗車した乗り物（バス、バイク、又は車両など）の移動に伴って移動する通信装置である。ＵＥ１０は、ｅＮＢ３０による制御に従ってｅＮＢ３０と通信する機能を有する。また、ＵＥ１０は、ＧＮＳＳ衛星４０から送信されるＧＮＳＳ信号を受信し、ＧＮＳＳ信号に含まれる航法メッセージからＵＥ１０の位置情報を測定する機能を有する。また、ＵＥ１０は、ＲＳＵ５０と通信する機能を有する。さらに、本実施形態では、ＵＥ１０は、他のＵＥ１０又はＵＥ２０と直接通信すること、すなわち、サイドリンクなどのＤ２Ｄ通信を行うことも可能である。ＵＥ１０とＵＥ２０との通信はＶ２Ｐ通信でもある。
【００４５】
なお、図７では移動体の一例として車両２２を示しているが、移動体は車両２２に限定されない。例えば、移動体は、船舶、航空機及び自転車などであってもよい。また、上記では、ＵＥ２０がＧＮＳＳ信号を受信する機能を有することを説明したが、車両２２がＧＮＳＳ信号を受信する機能を有し、車両２２がＧＮＳＳ信号の受信結果をＵＥ２０に出力してもよい。
【００４６】
図８には、車両などの移動体に搭載して用いられる通信装置の機能的構成例を模式的に示している。図８に示す通信装置は、例えば、図７に示した無線通信システムのうち車両２２に搭載されるＵＥ２０に対応するが、ユーザ１２に携行されるＵＥ１０も同様の構成であると理解されたい。また、図８に示す通信装置は、フィードバック型サイドリンク通信における送信端末及び受信端末のいずれとしても動作するものとする。
【００４７】
図８に示すように、ＵＥ２０は、アンテナ部２１０と、無線通信部２２０、ＧＮＳＳ信号処理部２３０と、記憶部２４０と、処理部２５０を備えている。
【００４８】
アンテナ部２１０は、無線通信部２２０により出力される信号を電波として空間に放射する。また、アンテナ部２１０は、空間の電波を信号に変換し、当該信号を無線通信部２２０へ出力する。
【００４９】
無線通信部２２０は、信号を送受信する。例えば、無線通信部２２０は、ｅＮＢ３０からのダウンリンク信号を受信し、ｅＮＢ３０へのアップリンク信号を送信する。また、無線通信部２２０は、ＵＥ１０、他のＵＥ２０又はＲＳＵ５０との間でサイドリンク信号を送受信する。
【００５０】
ＧＮＳＳ信号処理部２３０は、ＧＮＳＳ衛星４０から送信されたＧＮＳＳ信号についての処理を行う構成である。例えば、ＧＮＳＳ信号処理部２３０は、ＧＮＳＳ信号を処理することにより、ＵＥ２０の位置情報及び時間情報を測定する。
【００５１】
記憶部２４０は、ＵＥ２０の動作のためのプログラム及びさまざまなデータを、一時的に又は不揮発的に記憶する。
【００５２】
処理部２５０は、ＵＥ２０のさまざまな機能を提供する。例えば、処理部２５０は、無線通信部２２０により行われる通信を制御する。後述するフィードバック型サイドリンク通信における送信端末又は受信端末としてのＵＥ２０の通信動作は、基本的には処理部２５０の制御によって実現されるものとする。
【００５３】
また、図２０には、主に基地局として動作する通信装置の機能的構成例を模式的に示している。図２０に示す通信装置は、例えば図２〜図６に示したＶ２Ｖ通信環境におけるＥ−ＵＴＲＡＮ、若しくは図７に示した無線通信システムにおけるｅＮＢ３０に対応する。
【００５４】
図２０に示すように、ｅＮＢ３０は、アンテナ部３１０と、無線通信部３２０、ネットワーク通信部３３０と、記憶部３４０と、処理部３５０を備えている。
【００５５】
アンテナ部３１０は、無線通信部３２０により出力される信号を電波として空間に放射する。また、アンテナ部３１０は、空間の電波を信号に変換し、当該信号を無線通信部３２０へ出力する。
【００５６】
無線通信部３２０は、信号を送受信する。例えば、無線通信部３２０は、ＵＥ１０、ＵＥ２０、又はＲＳＵ５０からのアップリンク信号を受信し、ＵＥ１０、ＵＥ２０、又はＲＳＵ５０へのダウンリンク信号を送信する。
【００５７】
ネットワーク通信部３３０は、図示しないネットワークを経由して情報を送受信する。例えば、ネットワーク通信部３３０は、他のノードへの情報を送信し、他のノードからの情報を受信する。ここで言う他のノードは、他の基地局及びコアネットワークノードを含むものとする。
【００５８】
記憶部３４０は、ｅＮＢ３０の動作のためのプログラム及びさまざまなデータを、一時的に又は不揮発的に記憶する。
【００５９】
処理部３５０は、ｅＮＢ３０のさまざまな機能を提供する。例えば、処理部３５０は、配下のユーザ端末（ＵＥ１０、ＵＥ２０）、及びＲＳＵ５０により行われる通信を制御する。
【００６０】
また、処理部３５０は、ユーザ端末間で直接行うデータ送信すなわちサイドリンク用のリソースプールの割り当てを行う。さらに本実施形態では、処理部３５０は、データ送信に対するＡＣＫ若しくはＮＡＣＫといったフィードバック信号を返信するためのフィードバック用リソースの割り当ても行なう場合もある。但し、フィードバックもサイドリンク通信の一部であり、フィードバック用リソースは基本的にはサイドリンク用のリソースプール内で割り当てられるものとする。
【００６１】
Ｂ．サイドリンク通信におけるフィードバック方法
本実施形態に係る無線通信システムでは、車両同士が直接的に通信を行うサイドリンクは、周波数利用効率及び信頼性向上の観点から、従来用いられていたブロードキャスト通信に変えて、フィードバック型サイドリンク通信を行う。従来のＤ２Ｄ通信では、サイドリンク通信は物理層レベルでブロードキャスト信号が複数回送信され、受信側では取り敢えずすべての信号を受信して、上位レイヤにおいて受信信号が自分宛かどうかを判断する。したがって、再送の概念がそもそもない。これに対し、本実施形態に係る無線通信システムでは、サイドリンク通信において送信される何らかの信号に対して、受信側がフィードバック信号（例えば、ＡＣＫ／ＮＡＣＫ、伝搬環境情報など）を送信する場面を想定している。
【００６２】
フィードバック型サイドリンク通信としては、送信端末が１台の受信端末と通信を行うユニキャスト通信と、複数台の受信端末と通信を行うマルチキャスト通信という２種類のシナリオが想定される。また、後者のマルチキャスト通信は、ブロードキャスト通信とは異なり、データをデコードする受信端末を制限することができる。１台の受信端末まで制限すると、ユニキャスト通信となる。マルチキャスト通信は、グループキャスト通信とも呼ばれる。
【００６３】
図９には、フィードバック型サイドリンク通信におけるＨＡＲＱオペレーションの例を示している。但し、図９は、送信端末が複数台の受信端末と通信を行うマルチキャスト通信のシナリオである。また、送信端末並びに受信端末は、図８に示した通信装置により構成されるものとする。
【００６４】
図９左に示すように、送信端末９０１は、複数台の受信端末９１１〜９１４に対して、データをデコードすることを制限したサイドリンク通信を実施する。そして、図９右に示すように、データの受信若しくはデコードに失敗した受信端末９１２が、送信端末９０１に対してＮＡＣＫを返信してフィードバックを行う。なお、図示を省略するがデータの受信に成功した受信端末９１１〜９１４が送信端末９０１に対してＡＣＫを返信してフィードバックを行うようにしてもよい。
【００６５】
ＮＡＣＫを受信した送信端末９０１は、データ再送を行うことにより信頼性を担保することができる。また、サイドリンク通信にフィードバック若しくは再送制御を採り入れることにより、ブロードキャスト通信を用いるときと比較して繰り返し送信回数を削減することができ、周波数利用効率を向上することができる。
【００６６】
また、受信端末９１１〜９１４は、ＨＡＲＱオペレーションを利用して、さまざまな情報のフィードバックを実施することができる。そして、送信端末９０１は、受信端末からフィードバックに関する情報を受信して、フィードバック対応を実施することができる。
【００６７】
図１０には、サイドリンク通信時において、送信端末が受信端末からのフィードバックに対応するための処理手順をフローチャートの形式で示している。また、図１１には、サイドリンク通信時において、受信端末が送信端末に対して情報をフィードバックするための処理手順をフローチャートの形式で示している。送信端末及び受信端末の各処理手順はいずれも、送信端末若しくは受信端末として動作する通信装置の処理部２５０が主導して実施される。
【００６８】
図１０を参照しながら、送信端末におけるフィードバック対応処理手順について説明する。
【００６９】
送信端末は、いずれかの受信端末からフィードバックに関する情報を受信すると（ステップＳ１００１）、フィードバック情報に応じてフィードバック対応処理を実施する（ステップＳ１００２）。
【００７０】
ステップＳ１００１におけるフィードバックの実施に関する指示は、通信を行っている送信端末自身でもよい、ＲＳＵや基地局などのインフラストラクチャでもよい。後述するように、フィードバックに使用するリソースは、ＲＳＵや基地局などのインフラストラクチャで割り当てられる場合と、送信端末が割り当てる場合と、フィードバックを実施する受信端末自身で確保する場合とが考えられる。
【００７１】
また、ステップＳ１００２では、フィードバック対応処理として、例えば送信リソース、消費電力、ＭＣＳ（Ｍｏｄｕｌａｉｔｏｎ  ａｎｄ  Ｃｏｄｉｎｇ  Ｓｈｅｍｅ）、再送回数、Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｍｏｄｅなどの制御を実施する。
【００７２】
また、送信端末は、オプションとして、フィードバック情報を受信するための対応を行ってもよい（ステップＳ１００３）。例えば、フィードバック情報を受信端末側から通知してもらう場合に使用するリソースなどをあらかじめ確保してもよい。
【００７３】
その後、送信端末は、ステップＳ１００２並びにステップＳ１００３で決定したパラメータを用いて、通信先の受信端末への信号送信を行う（ステップＳ１００４）。
【００７４】
続いて、図１１を参照しながら、受信端末におけるフィードバックを実施するための処理手順について説明する。
【００７５】
受信端末は、まずフィードバックを実施する上での設定を行う（ステップＳ１１０１）。この設定は、送信元の送信端末からでもよく、ＲＳＵや基地局などのインフラストラクチャから設定されてもよい。後述するように、フィードバックに使用するリソースは、ＲＳＵや基地局などのインフラストラクチャで割り当てられる場合と、送信端末が割り当てる場合と、フィードバックを実施する受信端末自身で確保する場合とが考えられる。
【００７６】
フィードバックを実施する上での設定を行った後、受信端末は、フィードバックを行うための測定を実施する（ステップＳ１１０２）。例えば、受信端末は、信号のデコーディングや、チャネル情報の測定、パスロスの計測のためのＲＳＲＰ（Ｒｅｆｅｒｅｎｃｅ  Ｓｉｇｎａｌ  Ｒｅｃｅｉｖｅｄ  Ｐｏｗｅｒ）やＲＳＲＱ（Ｒｅｆｅｒｅｎｃｅ  Ｓｉｇｎａｌ  Ｒｅｃｅｉｖｅｄ  Ｑｕａｌｉｔｙ）の計算などを実施する。
【００７７】
そして最後に、受信端末は、ステップＳ１１０２で測定したフィードバック結果を、送信端末、若しくはＲＳＵや基地局などのインフラストラクチャに送信して、フィードバックを実施する（ステップＳ１１０３）。
【００７８】
これまでのＶ２Ｘ通信においては、サイドリンクはブロードキャスト通信が採用され、且つ、フィードバックを用いた通信が導入されていない。したがって、図９〜図１１で示した、ＨＡＲＱのようなフィードバック通信をサイドリンクで行う際には、ＡＣＫやＮＡＣＫといったフィードバック信号を受信端末から送信端末へどのようにフィードバックするか、という課題がある。
【００７９】
サイドリンク通信は、通常、基地局からあらかじめ割り当てられたリソースプールを使って行われる。したがって、車両などの移動体に搭載されたＵＥ２０は、いずれのＵＥも自由に使えるリソースプールを使って、サイドリンク通信を行うことができる（例えば、特許文献２を参照のこと）。このような環境下においては、フィードバック型サイドリンク通信を行う送信端末と受信端末間で、ＡＣＫやＮＡＣＫなどフィードバック用のリソースをどのように規定し、どのタイミングでフィードバックを行うなどの情報をどのように共有するか、という２点が主な課題になる。
【００８０】
Ｂ−１．フィードバック用リソースの確保
ここでは、フィードバック型サイドリンク通信を実現する１つ目の課題である、フィードバック用リソースを確保する方法について説明する。
【００８１】
３ＧＰＰの規格書ＴＳ  ３６．２１３では、基地局によるサイドリンクのリソース割り当て方式としてモード１及びモード３が記載され（モード３ではリソースが準静的に割り当てられるが、モード１によるリソース割り当ては準静的でない）、また、端末によるサイドリンクのリソース割り当て方式としてモード２及びモード４が規格化されている（モード４ではセンシングを伴うが、モード２ではセンシングを伴わない）。そこで、フィードバック型サイドリンク通信において、基地局がフィードバック用リソースを割り当てるケースと、端末がフィードバック用リソースを割り当てるケースについて、それぞれ考えてみる。但し、後者の端末がフィードバック用リソースを割り当てるケースは、送信端末がリソース割り当てを行うケースと受信端末がリソース割り当てを行うケースにさらに分けられる。さらにＰｒｅ−ｃｏｆｉｇｕｒａｔｉｏｎによりフィードバック用リソースを割り当てるケースも想定される。
【００８２】
Ｂ−１−１．基地局がフィードバック用リソースの割り当てを行うケース
このケースでは、サイドリンクにおけるフィードバック用のリソースは、基地局によって割り当てられる。
【００８３】
送信端末がデータリソースを割り当てる場合、送信端末は、ＡＣＫ並びにＮＡＣＫ用のリソースを別途、基地局に割り当ててもらう必要がある。
【００８４】
図１２には、基地局がサイドリンクにおけるフィードバック用リソースの割り当てを行う通信シーケンス例を示している。なお、同図中の送信端末及び受信端末はそれぞれ異なる車両に搭載された通信装置（図８を参照のこと）であり、基地局はｅＮＢ又はＲＳＵに相当する。
【００８５】
送信端末は、トラフィックが発生すると（ＳＥＱ１２０１）、接続先の基地局に対して、スケジューリングリクエストによるサイドリンクのためのリソースを要求する（ＳＥＱ１２０２）。ここでは、送信端末は、データ送信のためのリソースに加えて、フィードバック（すなわち、ＡＣＫ／ＮＡＣＫ）のためのリソースを要求する。
【００８６】
基地局は、送信端末からのサイドリンクのためのリソース要求に応答して、データ送信のためのリソース、及び、ＡＣＫ／ＮＡＣＫのためのリソース割り当てを行う（ＳＥＱ１２０３）。そして、基地局は、送信端末と受信端末の各々に対し、ＤＣＩ（Ｄｏｗｎｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｉｎｆｏｒｍａｔｉｏｎ）経由で、割り当てたリソースを通知する（ＳＥＱ１２０４）。
【００８７】
その後、送信端末は、サイドリンクによるデータ送信に割り当てられたリソースを使って、受信端末へのデータ送信を行う（ＳＥＱ１２０５）。これに対し、受信端末は、送信端末からの送信データを受信し復号処理する（ＳＥＱ１２０６）。そして、受信端末は、データの受信結果若しくは受信データの復号結果に関するＡＣＫ若しくはＮＡＣＫを、フィードバック用に割り当てられたリソースを使って、送信端末に返信する（ＳＥＱ１２０７）。
【００８８】
例えば、送信端末は、データ送信前に基地局にフィードバック用リソースを割り当ててもらう。この場合、送信端末は、データ送信前に、通信対象のデバイス、及び、通信対象のデバイスへのサイドリンクの送信タイミングを、接続先の基地局に通知する。例えば、図９に示す例では、送信端末９０１にとって受信端末９１１〜９１４が通信対象のデバイスとなる。
【００８９】
これに対し、基地局は、送信端末からの要求に応答して、フィードバック用リソースの割り当てを実施する。そして、基地局は、ダウンリンクのＰＤＣＣＨ（Ｐｈｙｓｉｃａｌ  Ｄｏｗｎｌｉｎｋ  Ｃｏｎｔｒｏｌ  ＣＨａｎｎｅｌ）を用いて、フィードバック用のＳＬ  Ｇｒａｎｔ（サイドリンクにおけるリソース割り当て結果）を通信対象のデバイスに通知する。また、基地局は、要求元の送信端末に対するリソース割り当て結果の通知も同時に行う。データ送信前に基地局がリソース割り当てを行う方法は、ダイナミックなリソース割り当て方法ということもできる。
【００９０】
また、基地局がフィードバック用リソースを割り当てる他の方法として、事前にすべての端末に対してフィードバック用リソースを周期的に割り当てておく方法も考えられる。この方法によれば、受信端末は、事前に割り当てられたリソースの一部を使って、送信端末に対してＡＣＫ若しくはＮＡＣＫを返信することができる。
【００９１】
基地局は、サイドリンクに割り当てたリソースプールの一部に、フィードバック用のリソースプールを設け、このフィードバック用のリソースプール内で配下の各端末向けのフィードバック用リソースを事前に割り当てる。このリソースの割り当て方法は、データ送信の度にフィードバック用リソースが変わることがないことから、準静的なリソース割り当て方法ということができる。
【００９２】
図１３には、サイドリンク用のリソースプール１３００内に、フィードバック用のリソースプール１３０１を設けた様子を示している。但し、横軸を時間軸とし、縦軸を周波数軸とする。図示のように、フィードバック用のリソースプール１３０１の中に、通信対象の端末Ａ及び端末Ｂの各々向けのフィードバック用リソースが事前に割り当てられている。
【００９３】
端末Ａと端末Ｂに対して直交したフィードバック用リソースを事前に割り当てることで、各々から送信されるＡＣＫ／ＮＡＣＫパケットの衝突を防ぐことが可能となる。そして、リソースプール１３００を使ってデータ送信１３０２が実施されると、通信対象の各デバイスはそれぞれ自端末向けに準静的に割り当てられたフィードバック用リソースプールを使って、ＡＣＫ若しくはＮＡＣＫを返信することができる。
【００９４】
サイドリンク用のリソースプール１３００の設定や、リソースプール１３００内でのフィードバック用リソース１３０１の準静的な割り当ては、基地局（ｅＮＢ）からのシステム情報（ＳＩＢ：Ｓｙｓｔｅｍ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｂｌｏｃｋ）や、ＲＲＣ（Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ）シグナリングを用いてＣｏｎｆｉｇｕｒｅされる。
【００９５】
ＬＴＥで標準化されているＳＰＳ（Ｓｅｍｉ−Ｐｅｒｓｉｓｔｅｎｔ  Ｓｃｈｅｄｕｌｉｎｇ）は、データ用の準静的なリソース割り当てである。この場合、ＳＰＳ  Ｃｏｎｆｉｇｕｒａｔｉｏｎを行い、実際にデータ通信を行う際には逐次的にＡｃｔｉｖａｔｉｏｎの指示が必要となる。これに対し、上記のように基地局が各端末にフィードバック用リソースを準静的に割り当てる場合には、Ａｃｔｉｖａｔｉｏｎの指示は必要ではなく、各端末はいつでも準静的に割り当てられたフィードバック用リソースを使用して、ＡＣＫ若しくはＮＡＣＫを返信することが可能となる。
【００９６】
再び図１３を参照すると、通信対象の端末Ａ及び端末Ｂはそれぞれ、データ１３０２を受信した後、フィードバック用リソース１３０１内の最も早く使用可能なリソースを選択して、ＡＣＫ若しくはＮＡＣＫを返信する。但し、受信端末は、これ以外の方法でフィードバック用リソースの選択を行ってもよい。データ送信完了とＡＣＫ／ＮＡＣＫ返信に用いるリソース選択との関連については、後に詳細に説明する。
【００９７】
各端末に直交したフィードバック用リソースを事前に割り当てることで、ＡＣＫ／ＮＡＣＫパケットの衝突を防ぐことが可能となる。また、符号多重やプリアンブル送信などを用いて、複数の受信端末を同じフィードバック用リソースに多重化するようにしてもよい。ここで言うプリアンブル送信においては、ＺＣ（Ｚａｄｏｆｆ−Ｃｈｕ）系列のようなＣＡＺＡＣ（Ｃｏｎｓｔａｎｔ  Ａｍｐｌｉｔｕｄｅ  ａｎｄ  Ｚｅｒｏ  Ａｕｔｏ−ｃｏｒｒｅｌａｔｉｏｎＣｏｄｅ）系列を用いてもよい。受信端末毎に異なる系列を事前に割り当てることで、同じリソースを使ってＡＣＫ／ＮＡＣＫが多重送信された場合であっても、送信端末側ではユーザ分離が可能となる。系列割り当ては、事前に基地局から各端末に対して設定されていてもよいし、Ｐｒｅ−ｃｏｎｆｉｇｕｒａｔｉｏｎされてもよい。また、送信端末から端末グルーピングを行う際に系列割り当てを行うようにしてもよい。
【００９８】
Ｂ−１−２．送信端末がフィードバック用リソースの割り当てを行うケース
送信端末がフィードバック用リソースの割り当てを行う場合、割り当てるリソースが他の端末によって使用されていないことを保証する必要がある。このため、送信端末が自分のデータ送信のためのセンシングを実施する際に、受信端末のフィードバック用リソースのセンシングまで併せて行い、そのリソースを予約しておく必要がある。また、送信端末は、予約したフィードバック用リソースを受信端末に通知しておく必要がある。送信端末は、例えば、ＳＣＩ（Ｓｉｄｅｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｉｎｆｏｒｍａｔｉｏｎ）を用いて、フィードバック用リソースの位置を受信端末に通知するようにしてもよい。ＳＣＩは、ＰＳＣＣＨ（Ｐｈｙｓｉｃａｌ  Ｓｉｄｅｌｉｎｋ  Ｃｏｎｔｒｏｌ  ＣＨａｎｎｅｌ）を用いて伝送されるメッセージである。
【００９９】
図１４には、送信端末がサイドリンクにおけるフィードバック用リソースの割り当てを行う通信シーケンス例を示している。なお、同図中の送信端末及び受信端末はそれぞれ異なる車両に搭載された通信装置（図８を参照のこと）である。
【０１００】
送信端末は、トラフィックが発生すると（ＳＥＱ１４０１）、センシングを用いてサイドリンクによるデータ送信を行うためのリソースを、リソースプール（前述）の中から選択する（ＳＥＱ１４０２）。このとき、送信端末は、サイドリンク用のリソースプール内に設けられたフィードバック用リソースプールの中で、受信端末用のリソースを併せて選択する。このようにして、送信端末は、自分のデータ送信用のリソース、並びに受信端末のフィードバック用リソースをそれぞれ確保する（ＳＥＱ１４０３）。
【０１０１】
その後、送信端末は、ＳＣＩを用いて、データ送信用リソース及びフィードバック用リソースの位置を受信端末に通知し、続いて、ＳＣＩで通知したリソースを使って受信端末へのデータ送信を行う（ＳＥＱ１４０４）。
【０１０２】
これに対し、受信端末は、ＳＣＩで通知されたデータ送信用のリソース位置にて送信端末からの送信データを受信し、復号処理する（ＳＥＱ１４０５）。そして、受信端末は、データの受信結果若しくは受信データの復号結果に関するＡＣＫ若しくはＮＡＣＫを、送信端末からＳＣＩで通知されたリソースを使って、送信端末に返信する（ＳＥＱ１４０６）。
【０１０３】
また、送信端末は、Ｒｅｓｅｒｖａｔｉｏｎ  ｉｎｄｉｃａｔｏｒを用いて、リソース予約を行ってもよい。データ送信完了とＡＣＫ／ＮＡＣＫ返信に用いるリソース選択との関連については、後に詳細に説明する。
【０１０４】
ＳＥＱ１４０４において、送信端末がＳＣＩを用いてデータ送信用リソース及びフィードバック用リソースの位置を受信端末に通知する方法について、詳細に説明する。送信端末は、ＳＣＩ内に、データリソースの時間周波数領域と、フィードバック用リソースの時間周波数領域を指示する情報を含める。さらに、Ｒｅｓｅｒｖａｔｉｏｎ  ｉｎｄｉｃａｔｏｒを用いてリソース予約を行う場合には、送信端末は、ＳＣＩ内にフィードバック用リソースのリソース予約を通知するＲｅｓｏｕｒｃｅ  ｒｅｓｅｒｖａｔｉｏｎ  ｉｎｄｉｃａｔｏｒを含める。
【０１０５】
受信端末側では、ＳＣＩ内にＲｅｓｅｒｖａｔｉｏｎ  ｉｎｄｉｃａｔｏｒが含まれていた場合には、フィードバック用のリソースは将来予約されているものと認識する。また、ＳＣＩで指示されたフィードバック用リソースと予約されたフィードバック用リソースの位置関係は、ＳＣＩ内で時間オフセット値として通知してもよい。このとき周波数方向のオフセット値も含めてよい。また、受信端末は、データの送信周期に基づいて時間オフセット値を推定してもよい。例えば、送信端末からデータが１００ミリ秒周期で到来していた場合、予約されたフィードバック用リソースも１００ミリ秒先のリソースで予約されていると推定することができる。
【０１０６】
図１５には、フィードバック用リソースの割り当て例を示している。但し、同図において、横軸を時間軸とし、縦軸を周波数軸とする。送信端末は、サイドリンクにおいて、ＳＣＩを送信した後に、受信端末にデータを送信する。ＳＣＩ内には、参照番号１５０１で示す、データリソースの時間周波数領域を指示する情報と、参照番号１５０２で示す、フィードバック用リソースの時間周波数領域を指示する情報が含まれている。さらに、ＳＣＩ内には、Ｒｅｓｏｕｒｃｅ  ｒｅｓｅｒｖａｔｉｏｎ  ｉｎｄｉｃａｔｏｒが含まれている。このＩｎｄｉｃａｔｏｒは、参照番号１５０３で示すように、将来予約されているフィードバック用リソースを指示する。また、参照番号１５０４で示す、ＳＣＩで指示されたフィードバック用リソースと予約されたフィードバック用リソースの時間オフセット値は、ＳＣＩ内で通知してもよいし、受信端末が送信端末からのデータ送信周期に基づいて推定してもよい。
【０１０７】
また、ＳＥＱ１４０２において、送信端末がリソースをセンシングする方法について、補足する。送信端末は、データ通信用のリソースのセンシング方法とは異なる方法を用いて、フィードバック用リソースのセンシングを行ってもよい。データ通信用のセンシングにおいては、送信データの優先度及び周辺で送信されているパケットの優先度比較を行いながらリソースの確保を行う。一方で、フィードバック用リソースのセンシングにおいては、ＡＣＫ若しくはＮＡＣＫの優先度を新たに規定して、リソースの確保を行ってもよい。リソース確保のための条件はデータとＡＣＫ／ＮＡＣＫでは異なるため、別々のセンシング設定でリソースセンシングを実施する。
【０１０８】
Ｂ−１−３．受信端末がフィードバック用リソースの割り当てを行うケース
受信端末は、送信端末からのデータ信号を受信した後に、ＡＣＫ若しくはＮＡＣＫを返信するためのフィードバック用リソースをセンシングする。そして、受信端末は、センシングによりリソースを発見できたときには、そのリソースを用いて送信端末にＡＣＫ若しくはＮＡＣＫを返信する。
【０１０９】
但し、受信端末は、パケットの最大遅延時間を超えない範囲でＡＣＫ／ＮＡＣＫを返信しなければならない。パケット毎の最大遅延時間は、例えば、送信端末がデータ送信前に送信するＳＣＩを通じて受信端末に通知される。この場合、受信端末は、ＳＣＩで通知された最大遅延時間以内に、ＡＣＫ／ＮＡＣＫ用のリソースを確保して、送信しなければならない。
【０１１０】
また、受信端末は、自ら割り当てたフィードバック用リソースの位置を、例えばＳＣＩを用いて送信端末に通知するようにしてもよい。但し、受信端末自身のデータ送信がない場合に、ＳＣＩを無駄に送信する方法は好ましくない。このため、受信端末は、データ信号としてＰｉｇｇｙ  ｂａｃｋして（すなわち、フィードバックパケットをデータパケットに乗せて）送信するようにしてもよい。この場合、データの最後にＡＣＫ若しくはＮＡＣＫを挿入するなどＩｍｐｌｉｃｉｔな送信方法を用いることができる。
【０１１１】
図１６には、受信端末がフィードバック信号を送信するための処理手順をフローチャートの形式で示している。図示の処理手順は、受信端末として動作する通信装置の処理部２５０が主導して実施される。この処理手順は、受信端末がＡＣＫ／ＮＡＣＫをデータパケットのＰｉｇｇｙ  ｂａｃｋして送信する点に主な特徴がある。
【０１１２】
受信端末は、送信端末からデータパケットを受信すると（ステップＳ１６０１）、そのデータ送信の際に送信端末から受信したＳＣＩから、フィードバック信号を送信する最大遅延時間を取得する（ステップＳ１６０２）。
【０１１３】
次いで、受信端末は、フィードバック信号の最大遅延時間内に送信するデータパケットがあるかどうかをチェックする（ステップＳ１６０３）。ここで、フィードバック信号の最大遅延時間内に送信するデータパケットがある場合には（ステップＳ１６０３のＹｅｓ）、受信端末は、そのデータパケットの宛先にステップＳ１６０１で受信したパケットの送信元の端末が含まれているか、若しくはそのデータパケットをブロードキャスト通信するかどうかを、さらにチェックする（ステップＳ１６０４）。
【０１１４】
そして、受信端末は、自身のデータパケットの宛先にステップＳ１６０１で受信したパケットの送信元の端末が含まれているか、又は、ブロードキャスト通信を行うときには（ステップＳ１６０４のＹｅｓ）、ステップＳ１６０１で受信したパケットに関するＡＣＫ若しくはＮＡＣＫを自身のデータパケットにＰｉｇｇｙ  ｂａｃｋして送信する（ステップＳ１６０５）。
【０１１５】
一方、フィードバック信号の最大遅延時間内に送信するデータパケットがない場合（ステップＳ１６０３のＮｏ）、又は、自身のデータパケットの宛先にステップＳ１６０１で受信したパケットの送信元の端末が含まれず、且つ、ブロードキャスト通信でもない場合には（ステップＳ１６０４のＮｏ）、受信端末は、フィードバック用のリソースセンシングを実施する（ステップＳ１６０６）。
【０１１６】
ここで、受信端末は、フィードバック用のリソースを確保することができた場合には（ステップＳ１６０７のＹｅｓ）、確保したリソースを使って、ステップＳ１６０１で受信したパケットの送信元の端末にＡＣＫ若しくはＮＡＣＫを返信する（ステップＳ１６０８）。その際、受信端末は、送信端末に対して、ＳＣＩにＡＣＫ若しくはＮＡＣＫの位置の情報を載せて通知するようにしてもよい。
【０１１７】
一方、フィードバック用のリソースを確保することができなかった場合には（ステップＳ１６０７のＮｏ）、受信端末は、ＡＣＫ若しくはＮＡＣＫの返信を行わない（ステップＳ１６０９）。
【０１１８】
図１６に示した処理手順によれば、受信端末は、可能な限りフィードバック信号をＰｉｇｇｙ  ｂａｃｋして送信して、ＳＣＩを無駄に送信しないように動作することができる。
【０１１９】
受信端末がフィードバック用リソースの割り当てを行うケースにおいて、送信端末が、受信端末に対して、フィードバック用に使用すべきリソースの領域を設定（若しくは制限）するようにしてもよい。このような場合、受信端末は、送信端末が設定した領域内で、フィードバック用のリソースをセンシングして、送信を行う。送信端末は、周波数方向及び時間方向のいずれか又は両方でフィードバック用のリソースの領域を制限してもよい。
【０１２０】
また、フィードバック用のリソースを発見し易くするために、フィードバック用の専用リソースプールを端末に設定してもよい。この設定は、通常のリソースプール割り当てと同様に、基地局からのシステム情報（ＳＩＢ）や、ＲＲＣシグナリングを通して行うことができる。また、フィードバック用の専用リソースプールがＰｒｅ−ｃｏｆｉｇｕｒａｔｉｏｎされてもよい。
【０１２１】
受信端末は、上記のように指定されたリソースの領域内でフィードバック用のリソースを確保できない場合（若しくは、最大遅延時間内で指定された領域からリソースを確保できない場合）、サイドリンクによるフィードバック信号の送信を諦めて、基地局のアップリンクを用いたフィードバック信号の送信に切り替えてもよい。この場合、受信端末からのＡＣＫ／ＮＡＣＫは、基地局経由で送信端末に送信されることになる。
【０１２２】
図１７には、受信端末がフィードバック信号を送信するための他の処理手順をフローチャートの形式で示している。図示の処理手順は、受信端末として動作する通信装置の処理部２５０が主導して実施される。この処理手順は、受信端末が最大遅延時間以内にサイドリンクでＡＣＫ／ＮＡＣＫを返信できない場合にはアップリンクを用いたフィードバック送信に切り替える点に主な特徴がある。
【０１２３】
受信端末は、送信端末からデータパケットを受信すると（ステップＳ１７０１）、そのデータ送信の際に送信端末から受信したＳＣＩから、フィードバック信号を送信する最大遅延時間を取得する（ステップＳ１７０２）。
【０１２４】
次いで、受信端末は、フィードバック用のリソースセンシングを実施する（ステップＳ１７０３）。そして、受信端末は、ステップＳ１７０２で取得した最大遅延時間以内でフィードバック用リソースを確保することができた場合には（ステップＳ１７０４のＹｅｓ）、確保したリソースを使って、ステップＳ１７０１で受信したパケットの送信元の端末にＡＣＫ若しくはＮＡＣＫを返信する（ステップＳ１７０５）。
【０１２５】
一方、受信端末は、ステップＳ１７０２で取得した最大遅延時間以内でフィードバック用リソースを確保することができなかった場合には（ステップＳ１７０４のＮｏ）、アップリンク通信向け（すなわち、接続先の基地局向け）のリソースセンシングを実施する（ステップＳ１７０６）。
【０１２６】
ここで、受信端末は、アップリンク通信向けのリソースを確保することができた場合には（ステップＳ１７０７のＹｅｓ）、基地局経由での、ステップＳ１７０１で受信したパケットの送信元の端末へのＡＣＫ若しくはＮＡＣＫ送信を実施する（ステップＳ１７０８）。
【０１２７】
また、受信端末は、アップリンク通信向けのリソースを確保することができなかった場合には（ステップＳ１７０７のＮｏ）、ＡＣＫ若しくはＮＡＣＫの返信を行わない（ステップＳ１７０９）。
【０１２８】
Ｂ−１−４．Ｐｒｅ−ｃｏｆｉｇｕｒａｔｉｏｎによりフィードバック用リソースの割り当てを行うケース
Ｐｒｅ−ｃｏｆｉｇｕｒａｔｉｏｎにより、すべての端末に対してデータ送信からＡＣＫ／ＮＡＣＫ送信までの関連を事前に設定しておくこともできる。この場合、データパケットを受信したすべての端末は、Ｐｒｅ−ｃｏｆｉｇｕｒｅされた設定に則って、ＡＣＫ若しくはＮＡＣＫを返信する。端末は、リソースセンシング実施時に、データ信号検出からＡＣＫ／ＮＡＣＫ送信で使用しているリソースを把握することができる。このため、端末は、データのみならずＡＣＫ／ＮＡＣＫ送信用のリソースを考慮してセンシングを行うことができる。なお、ここで言うＰｒｅ−ｃｏｆｉｇｕｒａｔｉｏｎとは、例えば端末の出荷時に設定することに相当する（但し、基地局が書き換えを行うことも想定される）。
【０１２９】
Ｂ−２．フィードバックタイミング
ここでは、フィードバック型サイドリンク通信を実現する２つ目の課題である、フィードバックタイミングを通知する方法について説明する。但し、フィードバックタイミングとは、端末がデータ受信を行ってからＡＣＫ若しくはＮＡＣＫを送信するタイミングまでの時間のことを示すものとする。フィードバックタイミングを通知する方法は、Ｉｍｐｌｉｃｉｔに通知する方法と、Ｅｘｐｌｉｃｉｔに通知する方法に大別される。以下では、各々の通知方法についてそれぞれ説明する。
【０１３０】
Ｂ−２−１．Ｉｍｐｌｉｃｉｔに通知する方法
データ送信直後を基準としてフィードバック用リソースを割り当てるケースが考えられる。複数台の受信端末と通信を行うマルチキャスト通信の場合、各受信端末にフィードバック用リソースの割り当てを決定しなければならない。図１８には、複数の受信端末ｘ、ｙ、ｚの各々に対し、データ送信直後を基準としてフィードバック用リソースを割り当てた例を示している。
【０１３１】
例えば、ｅＮＢ（基地局）が制御のために一時的に与える識別情報ＲＮＴＩ（Ｒａｄｉｏ  Ｎｅｔｗｏｒｋ  Ｔｅｍｐｏｒａｒｙ  Ｉｄｅｎｔｉｆｉｅｒ）を利用して、各端末のフィードバックタイミングを決定する方法を、Ｉｍｐｌｉｃｉｔに通知する方法として挙げることができる。受信端末は、マルチキャストグループを確立する際に入手した他端末のＲＮＴＩを用いて、自分が何番目のリソースを用いるかを決定してもよい。例えば、受信端末ｚ、ｘ、ｙにそれぞれ１、５、８といった番号が割り当てられていた場合には、端末ｙは、自身が３番目に大きな番号であるので、データ送信直後から３番目のリソースをＡＣＫ／ＮＡＣＫ用のリソースとして選択する。同様に、端末ｚは自身が最も小さな番号なのでデータ送信直後から１番目のリソースを選択し、端末ｘは自身が２番目に大きな番号なので２番目のリソースを選択する。
【０１３２】
Ｂ−２−２．Ｅｘｐｌｉｃｉｔに通知する方法
フィードバックタイミングをＥｘｐｌｉｃｉｔに通知する方法として、以下の（１）〜（４）を挙げることができる。各通知方法についてそれぞれ説明する。
【０１３３】
（１）ＳＣＩにオフセット情報を入れて受信端末に通知する。
送信端末が、受信端末に対して、データからＡＣＫ／ＮＡＣＫリソースまでの時間オフセット情報をＳＣＩに入れて通知する。逆に、受信端末が、送信端末に対して、ＡＣＫ／ＮＡＣＫを送信したいリソースの位置情報をＳＣＩに入れて送信するケースも考えられる。
【０１３４】
（２）ＳＣＩにフィードバック用リソース位置情報を入れて受信端末に通知する。
送信端末は、ＳＣＩに時間方向及び周波数方向の座標情報を入れることで、受信端末に対してＡＣＫ／ＮＡＣＫのリソース位置を指定する。また、データ信号の場所を基準としたオフセット情報として、ＳＣＩを用いてＡＣＫ／ＮＡＣＫのリソース位置を通知するようにしてもよい。
【０１３５】
（３）ＭＡＣ  ＣＥを用いて通知する。
基地局（ｅＮＢ）がＵＥ端末に送信するＭＡＣ  ＣＥ（ＭＡＣ  Ｃｏｎｔｒｏｌ  Ｅｌｅｍｅｎｔ）に、時間方向及び周波数方向の座標情報を入れることで、ＡＣＫ／ＮＡＣＫのリソース位置を指定する。また、データ信号の場所を基準としたオフセット情報として、ＭＡＣ  ＣＥを用いてＡＣＫ／ＮＡＣＫのリソース位置を通知するようにしてもよい。
【０１３６】
（４）基地局（ｅＮＢ）からのＲＲＣシグナリングを用いてフィードバック用リソースを通知する。
基地局は、準静的なフィードバック用リソースを各端末に割り当てる。このとき、基地局は、ＲＲＣシグナリングを用いて、準静的に割り当てたフィードバック用リソースを各端末に通知する。あるいは、基地局は、システム情報（ＳＩＢ）を用いて各端末に割り当てたフィードバック用リソースを通知するようにしてもよい。また、基地局は。各端末にフィードバック用リソースを動的に割り当てて、ＤＣＩ経由で通知するようにしてもよい。
【０１３７】
Ｃ．フィードバック型サイドリンク通信における再送方法
ここでは、受信端末からＮＡＣＫがフィードバックされた際の、送信端末による再送方法について説明する。
Ｃ−１．マルチキャスト通信時の再送方法
送信端末は、データパケットの宛先である受信端末からＮＡＣＫが返信されたときに、データ再送を行う。送信端末が複数台の受信端末に対して同時にデータパケットを送信するマルチキャスト通信を実施し、一部の受信端末からＮＡＣＫが返信されてきた場合の再送方法として、送信端末が再度マルチキャスト通信を実施する方法と、ＮＡＣＫを返信してきた受信端末に対してのみユニキャスト通信を実施する方法が考えられる。
【０１３８】
Ｃ−２．受信端末における初送信号と再送信号の判断方法
ＮＤＩ（Ｎｅｗ  Ｄａｔａ  Ｉｎｄｉｃａｔｏｒ）は、当該信号が初期送信又は再送のいずれであるかを示す識別情報である。受信端末は、マルチキャスト用のＮＤＩを用いて、信号が初送又は再送のいずれであるかを判断することができる。
【０１３９】
Ｃ−３．再送トリガ
送信端末は、１つ以上のパラメータを含んだ再送トリガ条件を設定して、再送判断を実施する。例えば、所定数以上のパラメータが条件を満たすときに、送信端末は再送を開始する。再送トリガ条件となるパラメータや再送判断のための閾値情報は、例えば基地局が設定してもよいし、Ｐｒｅ−ｃｏｆｉｇｕｒａｔｉｏｎされてもよい。
【０１４０】
再送トリガ条件となるパラメータを以下に示す。但し、以下のパラメータは例示列挙に過ぎず、再送トリガ条件はこれらに限定されるものではない。また、複数のパラメータを組み合わせて再送トリガ条件としてもよい。
【０１４１】
・所定の時間に受信したＮＡＣＫ数、マルチキャスト通信した宛先の端末数に対するＮＡＣＫを返信した受信端末の割合。
【０１４２】
・送信パケットの優先度情報。
【０１４３】
・ＣＢＲ（Ｃｈａｎｎｅｌ  Ｂｕｓｙ  Ｒａｔｉｏ）、ＣＲ（Ｃｈａｎｎｅｌ  Ｏｃｃｕｐａｎｃｙ  Ｒａｔｉｏｎ）などで示される、チャネル混雑度やチャネル占有度などサイドリンクのチャネル状況。
【０１４４】
・再送上限数に達していないか。
再送上限数は、基地局が設定してもよいし、Ｐｒｅ−ｃｏｆｉｇｕｒａｔｉｏｎされてもよい。
【０１４５】
・端末のＨＡＲＱプロセス状況
例えば、送信端末は、受信端末のＨＡＲＱプロセス状況の情報を共有する。ここで言うＨＡＲＱプロセス状況には、対応可能プロセス数や残プロセス数などの情報が含まれる。そして、送信端末は、受信端末のＨＡＲＱプロセス状況に応じて、再送すべきかどうかを判断する。また、送信端末は、その判断結果を基地局（ｅＮＢ）に通知してもよい。送信端末は、残プロセス数が小さい受信端末に対しては、より確実に送信できるように送信パラメータを変更して再送するなどの対応を行うことができる。
また、送信端末は、自端末のＨＡＲＱプロセス状況に応じて、再送すべきかどうかを判断するようにしてもよい。例えば、残プロセス数が大きいなどビジーな状況下では、送信端末は再送を抑制するようにしてもよい。
【０１４６】
図１９には、送信端末が再送制御するための処理手順をフローチャートの形式で示している。図示の処理手順は、送信端末として動作する通信装置の処理部２５０が主導して実施される。
【０１４７】
送信端末は、受信端末に対してデータパケットを送信し（ステップＳ１９０１）、受信端末からのＡＣＮ若しくはＮＡＣＫを受信する（ステップＳ１９０２）。
【０１４８】
そして、送信端末は、再送トリガ条件を満たしているかどうかをチェックして、再送トリガ条件を満たしているときには再送を実施するが（ステップＳ１９０７）、再送トリガ条件を満たしていないときには、再送せずに（ステップＳ１９０４）、本処理を終了する。
【０１４９】
図１９に示す処理手順では、送信端末は、再送トリガ条件として、まず再送上限に達しているかどうかをチェックする（ステップＳ１９０３）。そして、再送上限に既に達しているときには（ステップＳ１９０３のＹｅｓ）、送信端末は、再送せずに（ステップＳ１９０４）、本処理を終了する。
【０１５０】
一方、再送上限にまだ達していないときには（ステップＳ１９０３のＮｏ）、送信端末は、さらに他の再送トリガ条件についてチェックする。
【０１５１】
具体的には、送信端末は、所定の時間に受信したＮＡＣＫ数が閾値以下であるかどうかをチェックする（ステップＳ１９０５）。そして、所定の時間に受信したＮＡＣＫ数が閾値以下であるときには（ステップＳ１９０５のＹｅｓ）、送信端末は、再送せずに（ステップＳ１９０４）、本処理を終了する。
【０１５２】
また、送信端末は、ステップＳ１９０１で送信したパケットの優先度が閾値以下であるかどうかをチェックする（ステップＳ１９０６）。そして、送信パケットの優先度が閾値以下であるときには（ステップＳ１９０６のＹｅｓ）、送信端末は、再送せずに（ステップＳ１９０４）、本処理を終了する。
【０１５３】
また、送信端末は、再送上限にまだ達しておらず（ステップＳ１９０３のＮｏ）、所定の時間に受信したＮＡＣＫ数が閾値を超え（ステップＳ１９０５のＮｏ）、且つ、送信パケットの優先度が閾値を超えるときには（ステップＳ１９０６のＮｏ）、再送を実施する（ステップＳ１９０７）。
【０１５４】
Ｃ−４．再送時のＲＮＴＩ割り当て方法
マルチキャスト送信時には、グループＲＮＴＩのようなＲＮＴＩを宛先情報に用いて送信が行われる。グループＲＮＴＩは、グループリンクを確立する段階で、基地局から通知される。グループリンクは、Ｄｉｓｃｏｖｅｒｙプロセスを経て割り当てられてもよいし、基地局から割り当てられてもよい。
【０１５５】
マルチキャスト送信時のグループＲＮＴＩが他のグループのＲＮＴＩと重複しないように、例えば以下の情報（１）又は（２）を用いてグループＲＮＴＩを作成するようにする。
【０１５６】
（１）送信端末のＩＭＳＩ（Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｍｏｂｉｌｅ  Ｓｕｂｓｃｒｉｂｅｒ  Ｉｄｅｎｔｉｔｙ）情報
（２）送信端末の情報の一部を使用して生成したＲＮＴＩ（例えば、送信端末自身に割り当てられたＲＮＴＩを用いて、グループＲＮＴＩを生成する）
【０１５７】
Ｄ．フィードバック受信時のオペレーション
ここでは、送信端末が、受信端末からのフィードバック信号を受信したときに行うオペレーションについて説明する。
【０１５８】
サイドリンク通信時における、送信端末が受信端末からのフィードバックに対応するための処理手順については、図１０を参照しながら既に述べた。送信端末は、受信端末からＮＡＣＫを受信すると、送信パラメータを調整して再送を実施する（但し、前述したように、再送トリガ条件を満たさないときには再送が実施されない場合もある）。再送時に調整する送信パラメータを以下に例示しておく。
【０１５９】
・繰り返し送信回数（１回の送信に対して同じパケットを繰り返し送信する回数）
・送信電力
・ＲＶ（Ｒｅｄｕｎｄａｎｃｙ  Ｖｅｒｓｉｏｎ）情報
・ＭＣＳ
・周波数ホッピングの適用
・優先度（再送毎に優先度を上げてもよい）
・周波数帯域の変更
・ＭＩＭＯ（Ｍｕｌｔｉｐｌｅ  Ｉｎｐｕｔ  Ｍｕｌｔｉｐｌｅ  Ｏｕｔｐｕｔ）の適用、ビームフォーミングの適用
・ＣｏＭＰ（Ｃｏｏｒｄｉｎａｔｅｄ  Ｍｕｌｔｉ−ｐｏｉｎｔ：高データレートのカバレッジ拡大や、セル端におけるスループット改善を目的とした多地点協調）の適用
・ＣＡ（Ｃａｒｒｉｅｒ  Ａｇｇｒｅｇａｔｉｏｎ）の適用
・使用リソースの変更（リソースリザベーションの段階で他のキャリアをリザーブしておく方法もある）
・ＭＡ（Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓ）  ｓｉｇｎａｔｕｒｅ
・リソース割り当てモードの変更（基地局割り当てモード⇔端末割り当てモード）
【０１６０】
送信端末は、上記のような送信パラメータを、例えばＳＣＩを用いて受信端末に通知する。
【０１６１】
なお、送信パラメータの中には、初送時には必要であるが再送時には意味がなくなるものや、逆に、初送時には不要であるが再送時に必要となるものがある。そこで、ＳＣＩ中の一部のフィールドを、初送時と再送時とで読み替えを行って、メッセージのサイズを削減するようにしてもよい。例えば、繰り返し送信回数は初送時のみ必要であるが、再送データブロックの特徴を表すＲＶ情報は再送時から必要となる。したがって、初送時のＳＣＩにおいて繰り返し送信回数を記載していたフィールドを、再送時にはＲＶ情報を記載するフィールドに読み替えることができる。
【０１６２】
Ｅ．まとめ
本明細書では、受信側からのＨＡＲＱやチャネル情報などのフィードバックをベースに通信を行うフィードバック型サイドリンク通信に関して説明してきた。従来のＤ２Ｄ通信では、サイドリンク通信は物理層レベルでブロードキャスト信号が複数回送信され、受信側では取り敢えずすべての信号を受信して、上位レイヤにおいて受信信号が自分宛かどうかを判断する。すなわち、再送の概念がそもそもない。これに対し、本明細書で開示する技術によれば、上記のようにサイドリンク通信にフィードバック若しくは再送制御を採り入れることができる。したがって、サイドリンク通信において送信される何らかの信号に対して、受信側がフィードバック信号（例えば、ＡＣＫ／ＮＡＣＫ、伝搬環境情報など）を送信するので、信頼性を担保することができる。また、ブロードキャスト通信を用いるときと比較して繰り返し送信回数を削減することができ、周波数利用効率を向上することができる。
【産業上の利用可能性】
【０１６３】
以上、特定の実施形態を参照しながら、本明細書で開示する技術について詳細に説明してきた。しかしながら、本明細書で開示する技術の要旨を逸脱しない範囲で当業者が該実施形態の修正や代用を成し得ることは自明である。【０１６４】
本明細書では、Ｖ２Ｘ通信におけるサイドリンク通信に関する実施形態を中心に説明してきたが、本明細書で開示する技術の要旨はこれに限定されるものではない。すなわち、本明細書で開示する技術は、Ｖ２Ｘ通信以外のユースケースにも同様に適用することが可能である。本明細書で開示する技術は、Ｄ２Ｄ（Ｄｅｖｉｃｅ  ｔｏ  Ｄｅｖｉｃｅ）通信やＭＴＣ（Ｍａｃｈｉｎｅ  Ｔｙｐｅ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ）などさまざまなタイプの端末間直接通信に適用することができる。また、本明細書で開示する技術は、Ｍｏｖｉｎｇ  ｃｅｌｌ（移動式基地局）やＲｅｌａｙ通信などへも適用することができる。【０１６５】
要するに、例示という形態により本明細書で開示する技術について説明してきたのであり、本明細書の記載内容を限定的に解釈するべきではない。本明細書で開示する技術の要旨を判断するためには、特許請求の範囲を参酌すべきである。【０１６６】
なお、本明細書の開示の技術は、以下のような構成をとることも可能である。
（１）無線信号を送受信する通信部と、
前記通信部による、所定のリソースプールを用いたデータの送信と、前記データの送信先の端末からのフィードバックの受信を制御する制御部と、
を具備する通信装置。
（１−１）所定のリソースプールを用いてデータを送信するステップ、
前記データの送信先の端末から前記所定のリソースプール内で送信されたフィードバックを受信するステップと、
を有する通信方法。
（２）前記制御部は、前記データの送信用のリソース及び前記データの送信先の端末のための前記フィードバック用リソースを前記所定のリソースプール内で確保するように、さらに制御する、
上記（１）に記載の通信装置。
（３）前記制御部は、前記送信先の端末に対して、ＳＣＩを用いて前記フィードバック用リソースに関する情報を通知するように、さらに制御する、
上記（２）に記載の通信装置。
（４）前記制御部は、前記フィードバック用リソースの前記データの送信用のリソースからのオフセット又は位置情報を、前記ＳＣＩを用いて通知するように、制御する、
上記（３）に記載の通信装置。
（５）前記制御部は、Ｒｅｓｏｕｒｃｅ  ｒｅｓｅｒｖａｔｉｏｎ  ｉｎｄｉｃａｔｏｒを用いて前記フィードバック用リソースを予約するように、さらに制御する、
上記（３）又は（４）のいずれかに記載の通信装置。
（６）前記制御部は、前記ＳＣＩで指示した前記フィードバック用リソースと前記予約したフィードバック用リソースとの時間方向又は周波数方向のオフセットを前記ＳＣＩに含めるように、さらに制御する、
上記（５）に記載の通信装置。
（７）前記制御部は、データの送信周期に基づく時間方向のオフセットにより前記フィードバック用リソースを予約するように、さらに制御する、
上記（５）又は（６）のいずれかに記載の通信装置。
（８）前記制御部は、送信データの優先度及び周辺で送信されているパケットの優先度の比較に基づいて前記データの送信用のリソースをセンシングするとともに、フィードバックに関して規定した優先度に基づいて前記フィードバック用リソースをセンシングするように、さらに制御する、
上記（２）乃至（６）のいずれかに記載の通信装置。
（９）前記制御部は、確保した前記フィードバック用リソースを前記送信先の端末に通知するように、さらに制御する、
請求項２乃至８のいずれかに記載の通信装置。
（１０）前記制御部は、前記データの送信直後を基準として、複数の前記送信先の端末の前記フィードバック用リソースの割り当てを決定する、
上記（９）に記載の通信装置。
（１１）前記制御部は、複数の前記送信先の端末の所定の識別情報に基づく順番に従って、前記データの送信直後からの前記フィードバック用リソースを割り当てる、
上記（１０）に記載の通信装置。
（１２）前記制御部は、前記フィードバックを受信したことに応答して、前記データの再送をさらに制御する、
上記（１）乃至（１１）のいずれかに記載の通信装置。
（１３）前記制御部は、再送上限数、受信したＮＡＣＫ数、送信した前記データの優先度、前記データ及び前記フィードバックを送受信するリンクのチャネル状況、又は、前記送信先の端末におけるデータ再送に関するプロセス状況のうち少なくとも１つからなる条件に基づいて、データ再送を行うかどうかを判断する、
上記（１２）に記載の通信装置。
（１４）端末からのアップリンクの無線信号を受信し、端末へのダウンリンクの無線信号を送信する通信部と、
前記端末間で通信するサイドリンクのためのリソースの割り当てを制御する制御部と、
を具備し、
前記制御部は、前記サイドリンクに割り当てたリソースプール内でフィードバック用リソースを割り当てる、
通信装置。
（１５）前記制御部は、前記所定のリソースプール内に前記フィードバック用リソースを周期的に割り当てる、
上記（１４）に記載の通信装置。
（１６）前記制御部は、ＳＩＢ又はＲＲＣシグナリングを用いて前記フィードバック用リソースに関する情報を前記端末に通知するように、さらに制御する、
上記（１５）に記載の通信装置。
（１７）前記制御部は、符号化多重又はプリアンブル送信を用いて、同じリソースを複数の端末の前記フィードバック用リソースに多重化する、
上記（１５）又は（１６）のいずれかに記載の通信装置。
（１７−１）前記制御部は、前記送信先の端末において前記フィードバック用リソースに割り当て可能なリソースの制限を設定するように、さらに制御する、
上記（１４）に記載の通信装置。
（１７−２）前記制御部は、設定した前記リソースの制限に関する情報を、ＲＲＣシグナリング又はＳＩＢを用いて端末に通知する、
上記（１７−１）に記載の通信装置。
（１８）無線信号を送受信する通信部と、
前記通信部による、所定のリソースプールを用いて送信されたデータの受信と、前記データの送信元の端末へのフィードバックの送信を制御する制御部と、
を具備する通信装置。
（１８−１）所定のリソースプールを用いて伝送されるデータを受信するステップと、
前記データに対するフィードバックを前記所定のリソースプール内で送信するステップと、
を有する通信方法。
（１９）前記制御部は、前記送信元の端末が確保したフィードバック用リソースを用いてフィードバックを送信するように制御する、
上記（１８）に記載の通信装置。
（１９−１）前記制御部は、前記送信元の端末からＳＣＩを用いて通知されたフィードバック用リソースを用いてフィードバックを送信するように制御する、
上記（１８）又は（１９）のいずれかに記載の通信装置。
（１９−２）前記制御部は、前記ＳＣＩ内に含まれるＲｅｓｏｕｒｃｅ  ｒｅｓｅｒｖａｔｉｏｎ  ｉｎｄｉｃａｔｏｒから、予約されている前記フィードバック用リソースを認識する、
上記（１９−１）に記載の通信装置。
（２０）前記制御部は、基地局が前記所定のリソースプール内に周期的に割り当てたフィードバック用リソースを用いてフィードバックを送信するように制御する、
上記（１８）に記載の通信装置。
（２０−１）前記制御部は、前記基地局からＳＩＢ又はＲＲＣシグナリングを用いて通知された前記フィードバック用リソースを用いてフィードバックを送信するように制御する、
上記（２０）に記載の通信装置。
（２０−２）前記制御部は、前記フィードバック用リソースのうち最も早く使用可能なリソースを用いてフィードバックを送信するように制御する、
上記（２０）又は（２０−１）のいずれかに記載の通信装置。
（２０−３）前記制御部は、基地局からＭＡＣ  ＣＥ又はＲＲＣシグナリングを用いて通知された前記フィードバック用リソースを用いてフィードバックを送信するように制御する、
上記（１８）、（２０）乃至（２０−２）のいずれかに記載の通信装置。
（２１）前記制御部は、前記フィードバック用リソースをセンシングして、発見できたリソースを用いて前記フィードバックを送信するように制御する、
上記（１９）に記載の通信装置。
（２２）前記制御部は、自ら前記フィードバック用リソースに関する情報を、ＳＣＩを用いて前記送信元の端末に通知するように、さらに制御する、
上記（２１）に記載の通信装置。
（２３）前記制御部は、基地局又は前記データの送信的の端末が設定したリソースの制限内で、前記フィードバック用リソースを確保するように、さらに制御する、
上記（２１）に記載の通信装置。
（２４）前記制御部は、前記データを受信してから所定の時間内に送信するデータに前記フィードバックをＰｉｇｇｙ  ｂａｃｋして送信するように、さらに制御する、
上記（１８）又は（２１）のいずれかに記載の通信装置。
（２５）前記通信部は、接続先の基地局から割り当てられたサイドリンク用の前記所定のリソースプールを用いて無線信号の送受信を行う、
上記（１）乃至（１３）、又は上記（１８）乃至（２４）のいずれかに記載の通信装置。
（２６）前記制御部は、初送時と再送時でＳＣＩの少なくとも一部のパラメータを読み替えるように、さらに制御する、
上記（１）乃至（１３）、又は上記（１８）乃至（２４）のいずれかに記載の通信装置。
（２７）前記制御部は、初送時におけるＳＣＩ内で繰り返し送信回数を通知するフィールドを、再送時においてＲＶ情報を通知するフィールドに読み替えるように、さらに制御する、
上記（２６）に記載の通信装置。
【符号の説明】
【０１６７】
１０…ＵＥ（ユーザ携行）、２０…ＵＥ（車両搭載）
２２…移動体（車両）、３０…ｅＮＢ、４０…ＧＮＳＳ衛星
５０…ＲＳＵ
２１０…アンテナ部、２２０…無線通信部
２３０…ＧＮＳＳ信号処理部、２４０…記憶部、２５０…処理部
３１０…アンテナ部、３２０…無線通信部
３３０…ネットワーク通信部、３４０…記憶部、３５０…処理部
【図１】
2019064983.tif 000003
【図２】
2019064983.tif 000004
【図３】
2019064983.tif 000005
【図４】
2019064983.tif 000006
【図５】
2019064983.tif 000007
【図６】
2019064983.tif 000008
【図７】
2019064983.tif 000009
【図８】
2019064983.tif 000010
【図９】
2019064983.tif 000011
【図１０】
2019064983.tif 000012
【図１１】
2019064983.tif 000013
【図１２】
2019064983.tif 000014
【図１３】
2019064983.tif 000015
【図１４】
2019064983.tif 000016
【図１５】
2019064983.tif 000017
【図１６】
2019064983.tif 000018
【図１７】
2019064983.tif 000019
【図１８】
2019064983.tif 000020
【図１９】
2019064983.tif 000021
【図２０】
2019064983.tif 000022
【国際調査報告】
2019064983.tif 000023
2019064983.tif 000024