JPWO2020137130A1 - 端末装置、基地局、方法及び記録媒体 - Google Patents

Abstract

サイドリンクで第１のパケットを送信した後、前記第１のパケットの送信に使用したリソースの時間及び周波数を示す情報を含む送信報告情報を送信する制御部、を備える端末装置。

Description

本開示は、端末装置、基地局、方法及び記録媒体に関する。

セルラー移動通信の無線アクセス方式および無線ネットワーク（以下、「Long Term Evolution（LTE）」、「LTE-Advanced（LTE-A）」、「LTE-Advanced Pro（LTE-A Pro）」、「５Ｇ（第５世代）」「New Radio（NR）」、「New Radio Access Technology（NRAT）」、「Evolved Universal Terrestrial Radio Access（EUTRA）」、または「Further EUTRA（FEUTRA）」とも称する。）が、第三世代パートナーシッププロジェクト（3rd Generation Partnership Project: 3GPP）において検討されている。なお、以下の説明において、ＬＴＥは、LTE-A、LTE-A Pro、およびEUTRAを含み、ＮＲは、NRAT、およびFEUTRAを含む。ＬＴＥおよびＮＲでは、基地局装置（基地局）はＬＴＥにおいてｅＮｏｄｅＢ（evolved NodeB）およびＮＲにおいてｇＮｏｄｅＢ、端末装置（移動局、移動局装置、端末）はＵＥ（User Equipment）とも称する。ＬＴＥおよびＮＲは、基地局装置がカバーするエリアをセル状に複数配置するセルラー通信システムである。単一の基地局装置は複数のセルを管理してもよい。

ＮＲは、ＬＴＥに対する次世代の無線アクセス方式として、ＬＴＥとは異なるＲＡＴ（Radio Access Technology）である。ＮＲは、ｅＭＢＢ（Enhanced mobile broadband）、ｍＭＴＣ（Massive machine type communications）およびＵＲＬＬＣ（Ultra reliable and low latency communications）を含む様々なユースケースに対応できるアクセス技術である。ＮＲは、それらのユースケースにおける利用シナリオ、要求条件、および配置シナリオなどに対応する技術フレームワークを目指して検討される。

ＮＲでは、複数の送信方法が検討されている。例えば、それらの送信方法は、グラントベース送信（グラント有り送信）及びグラントフリー送信（グラント無し送信）を含む。グラント有無は、衝突防止のための所定の手続きの有無に対応する。グラント有りの場合は衝突防止のための所定の手続きが実施された上で送信が行われ、グラント無しの場合は衝突防止のための所定の手続きが実施されずに送信が行われる。ここで、衝突防止のための所定の手続きとは、基地局によるリソースの割り当て、及び／又は衝突防止のための所定のセンシング等を含む。グラントフリー送信は、衝突防止のための所定の手続きを省略可能であるため、グラントベース送信と比較して低遅延での送信が可能である。グラントフリー送信に関し、例えば、下記特許文献１に、アップリンクにおけるグラントフリー送信の関する技術が開示されている。

他方、端末同士の直接通信のための通信リンクであるサイドリンクに関する技術も、近年盛んに検討されている。とりわけ、将来の自動運転の実現のため、近年、車載通信（Ｖ２Ｘ通信）への期待が高まってきている。Ｖ２Ｘ通信とは、Vehicle to X通信の略であり、車と“何か”が通信を行うシステムである。ここでの“何か”の例として、車両（Vehicle）、設備（Infrastructure）、ネットワーク（Network）、及び歩行者（Pedestrian）等が挙げられる（Ｖ２Ｖ、Ｖ２Ｉ、Ｖ２Ｎ、及びＶ２Ｐ）。また、車用の無線通信としては、これまで主に、８０２．１１ｐベースのＤＳＲＣ（Dedicated Short Range Communication）の開発が進められてきたが、近年になり、ＬＴＥベースの車載通信である“ＬＴＥ−ｂａｓｅｄ Ｖ２Ｘ”の標準規格化が行われた。ＬＴＥベースのＶ２Ｘ通信では、基本的なセーフティメッセージ等のやり取りなどがサポートされている。

特開２０１８−５０４０８９号公報

上記特許文献１において検討されたアップリンクにおけるグラントフリー送信の他に、サイドリンクにおけるグラントフリー送信も想定される。サイドリンクにおけるグラントフリー送信は、例えば、自動運転車両の急ブレーキを示す情報や、ファクトリーオートメーションにおける警報などの、緊急度の高い情報を低遅延で送信するために利用され得る。ただし、グラントフリー送信では衝突防止のための所定の手続きが省略されるので、グラントフリー送信されたパケットは、他の端末間で送受信される他のパケットと衝突し得る。サイドリンクでの通信が、基地局等による中央集権的な制御を経ない場合があることを考慮すれば、サイドリンクでのグラントベース送信においても同様の衝突が生じ得る。

そこで、本開示では、サイドリンクで送信されたパケットと衝突した他のパケットのリカバリを可能にするための仕組みを提供する。

本開示によれば、サイドリンクで第１のパケットを送信した後、前記第１のパケットの送信に使用したリソースの時間及び周波数を示す情報を含む送信報告情報を送信する制御部、を備える端末装置が提供される。

また、本開示によれば、サイドリンクで第２のパケットを送信した後、他の端末装置によるサイドリンクでの第１のパケットの送信に用いられたリソースの時間及び周波数を示す情報を含む送信報告情報に基づいて、前記第２のパケットの再送を制御する制御部、を備える端末装置が提供される。

また、本開示によれば、第１の端末装置によるサイドリンクでの第１のパケットの送信に使用されたリソースの時間及び周波数を示す情報を含む送信報告情報に基づいて、サイドリンクで第２のパケットを送信した第２の端末装置による前記第２のパケットの再送を制御する通信制御部、を備える基地局が提供される。

また、本開示によれば、サイドリンクで第１のパケットを送信した後、前記第１のパケットの送信に使用したリソースの時間及び周波数を示す情報を含む送信報告情報を送信すること、を含む、プロセッサにより実行される方法が提供される。

また、本開示によれば、サイドリンクで第２のパケットを送信した後、他の端末装置によるサイドリンクでの第１のパケットの送信に用いられたリソースの時間及び周波数を示す情報を含む送信報告情報に基づいて、前記第２のパケットの再送を制御すること、を含む、プロセッサにより実行される方法が提供される。

また、本開示によれば、第１の端末装置によるサイドリンクでの第１のパケットの送信に使用されたリソースの時間及び周波数を示す情報を含む送信報告情報に基づいて、サイドリンクで第２のパケットを送信した第２の端末装置による前記第２のパケットの再送を制御すること、を含む、プロセッサにより実行される方法が提供される。

また、本開示によれば、コンピュータを、サイドリンクで第１のパケットを送信した後、前記第１のパケットの送信に使用したリソースの時間及び周波数を示す情報を含む送信報告情報を送信する制御部、として機能させるためのプログラムが記録された記録媒体が提供される。

また、本開示によれば、コンピュータを、サイドリンクで第２のパケットを送信した後、他の端末装置によるサイドリンクでの第１のパケットの送信に用いられたリソースの時間及び周波数を示す情報を含む送信報告情報に基づいて、前記第２のパケットの再送を制御する制御部、として機能させるためのプログラムが記録された記録媒体が提供される。

また、本開示によれば、コンピュータを、第１の端末装置によるサイドリンクでの第１のパケットの送信に使用されたリソースの時間及び周波数を示す情報を含む送信報告情報に基づいて、サイドリンクで第２のパケットを送信した第２の端末装置による前記第２のパケットの再送を制御する通信制御部、として機能させるためのプログラムが記録された記録媒体が提供される。

Ｖ２Ｘ通信の概要について示した図である。 Ｖ２Ｘ通信の全体像の一例について説明するための説明図である。 Ｖ２Ｘ通信のユースケースの一例を示した図である。 Ｖ２Ｘオペレーションシナリオの一例を説明するための図である。 Ｖ２Ｘオペレーションシナリオの一例を説明するための図である。 Ｖ２Ｘオペレーションシナリオの一例を説明するための図である。 Ｖ２Ｘオペレーションシナリオの一例を説明するための図である。 Ｖ２Ｘオペレーションシナリオの一例を説明するための図である。 Ｖ２Ｘオペレーションシナリオの一例を説明するための図である。 サイドリンク通信の拡張例を説明するための図である。 サイドリンク通信の拡張例を説明するための図である。 サイドリンク通信の拡張例を説明するための図である。 サイドリンク通信の拡張例を説明するための図である。 サイドリンクリソース割り当て方式を説明するための図である。 サイドリンク通信に割り当てられたリソースの構成の一例について示した図である。 Mode4リソース割り当てに基づき端末装置がパケットを送信する場合の動作タイムラインの一例について説明するための説明図である。 リソースプール内からリソースを選択するためのセンシングの動作の一例について説明するための説明図である。 本開示の一実施形態に係るシステムの概略的な構成の一例を示す図である。 同実施形態に係る基地局の論理的な構成の一例を示すブロック図である。 同実施形態に係る端末装置の論理的な構成の一例を示すブロック図である。 グラントベース送信の処理の流れの一例を示すシーケンス図である。 同実施形態に係るシステムにおいて実行されるグラントフリー送信及びリカバリ処理の流れの一例を示すシーケンス図である。 同実施形態に係る送信端末により実行される第１のパケットの送信処理及び事後処理の流れの一例を示すフローチャートである。 同実施形態に係る基地局により実行されるリカバリ処理の流れの一例を示すフローチャートである。 同実施形態に係る送信報告情報の黙示的な通知方法の一例を説明するための図である。 同実施形態に係る送信報告情報の黙示的な通知方法の一例を説明するための図である。 同実施形態に係る送信報告情報の黙示的な通知方法の一例を説明するための図である。 同実施形態に係るシステムにおいて実行される送信報告情報の黙示的な通知に基づくリカバリ処理の流れの一例を示すシーケンス図である。 同実施形態に係るシステムにおいて実行される送信報告情報の黙示的な通知に基づくリカバリ処理の流れの一例を示すシーケンス図である。 同実施形態に係るシステムにおいて実行される送信報告情報の黙示的な通知に基づくリカバリ処理の流れの一例を示すシーケンス図である。 同実施形態に係るシステムにおいて実行されるセンシングレス送信及びリカバリ処理の流れの一例を示すシーケンス図である。 同実施形態に係る送信端末により実行される第１のパケットの送信処理及び事後処理の流れの一例を示すフローチャートである。 同実施形態に係る周辺送信端末により実行されるリカバリ処理の流れの一例を示すフローチャートである。 ｅＮＢの概略的な構成の第１の例を示すブロック図である。 ｅＮＢの概略的な構成の第２の例を示すブロック図である。 スマートフォンの概略的な構成の一例を示すブロック図である。 カーナビゲーション装置の概略的な構成の一例を示すブロック図である。

以下に添付図面を参照しながら、本開示の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。

また、本明細書及び図面において、実質的に同一の機能構成を有する要素を、同一の符号の後に異なるアルファベットを付して区別する場合もある。例えば、実質的に同一の機能構成を有する複数の要素を、必要に応じて端末装置２００Ａ、２００Ｂ及び２００Ｃのように区別する。ただし、実質的に同一の機能構成を有する複数の要素の各々を特に区別する必要がない場合、同一符号のみを付する。例えば、端末装置２００Ａ、２００Ｂ及び２００Ｃを特に区別する必要が無い場合には、単に端末装置２００と称する。

なお、説明は以下の順序で行うものとする。
１．はじめに
１．１．Ｖ２Ｘ通信
１．２．サイドリンク通信の拡張例
１．３．サイドリンクリソース割り当て方式
２．提案技術の概要
２．１．システム構成例
２．２．技術的課題
２．３．提案技術の概要
３．構成例
３．１．基地局の構成例
３．２．端末装置の構成例
４．技術的特徴
４．１．Mode3リソース割り当て環境における処理
４．１．１．概要
４．１．２．グラントベース送信
４．１．３．グラントフリー送信及びリカバリ処理
４．１．４．各装置の動作
４．１．５．変形例
４．２．Mode4リソース割り当て環境における処理
４．２．１．センシングレス送信及びリカバリ処理
４．２．２．各装置の動作
５．応用例
５．１．基地局に関する応用例
５．２．端末装置に関する応用例
６．まとめ

＜＜１．はじめに＞＞
＜１．１．Ｖ２Ｘ通信＞
以下、Ｖ２Ｘ通信について概要を説明する。Ｖ２Ｘ通信とは、Vehicle to X通信の略であり、車と“何か”が通信を行うシステムである。例えば、図１は、Ｖ２Ｘ通信の概要について示した図である。ここでの“何か”の例としては、例えば、図１に示すように、車両（Vehicle）、設備（Infrastructure）、ネットワーク（Network）、及び歩行者（Pedestrian）等が挙げられる（Ｖ２Ｖ、Ｖ２Ｉ、Ｖ２Ｎ、及びＶ２Ｐ）。

（Ｖ２Ｘ通信の全体像）
また、図２は、Ｖ２Ｘ通信の全体像の一例について説明するための説明図である。図２に示す例では、クラウドサーバとしてＶ２Ｘのアプリケーションサーバ（ＡＰＰサーバ）が保有され、当該アプリケーションサーバにより、コアネットワーク側でＶ２Ｘ通信の制御が実施される。基地局は、端末装置とのＵｕリンクの通信を行う一方で、Ｖ２Ｖ通信やＶ２Ｐ通信等の直接通信の通信制御を実施する。また、基地局の他に、路肩のインフラストラクチャ（Infrastructure）としてＲＳＵ（Road Side Unit）が配置される。ＲＳＵとしては、基地局型のＲＳＵと、ＵＥ型のＲＳＵと、の二つが考えられる。ＲＳＵにおいてはＶ２Ｘアプリケーション（Ｖ２Ｘ ＡＰＰ）の提供やデータリレー等のサポートが行われる。

（Ｖ２Ｘ通信のユースケース）
自動車向けの無線通信としては、これまで主に、８０２．１１ｐベースのＤＳＲＣ（Dedicated Short Range Communication）の開発が進められてきたが、近年になり、ＬＴＥベースの車載通信である“LTE-based V2X（ＬＴＥベースのＶ２Ｘ通信）”の標準規格化が行われた。ＬＴＥベースのＶ２Ｘ通信では、基本的なセーフティメッセージ等のやり取りなどがサポートされている。一方で、さらなるＶ２Ｘ通信の改善をめざし、近年５Ｇ技術（ＮＲ：New Radio）を用いたＮＲ Ｖ２Ｘ通信の検討が行われている。例えば、図３は、Ｖ２Ｘ通信のユースケースの一例を示した図である。

ＮＲ Ｖ２Ｘ通信では、これまでＬＴＥベースのＶ２Ｘではサポートが困難であったような、高信頼性、低遅延、高速通信、ハイキャパシティを必要とする新たなユースケースがサポートされる。具体的な一例として、図３に示す例のうち、例えば、ダイナミックマップの提供やリモートドライビング等が挙げられる。また、この他にも、車車間や路車間でセンサデータのやり取りを行うようなセンサデータシェアリングや、隊列走行向けのプラトゥーニングユースケースが挙げられる。このようなＮＲ Ｖ２Ｘ通信のユースケース及び要求事項については、３ＧＰＰ ＴＲ２２．８８６において規定されている。参考として、以下にユースケースの一例について概要を説明する。

（１）Vehicles Platooning
複数の車両が隊列となり、同じ方向に走行する、隊列走行のユースケースであり、隊列走行を主導する車と他の車との間で隊列走行を制御するための情報のやり取りが行われる。これらの情報のやりとりにより、例えば、隊列走行の車間距離をより詰めることが可能となる。

（２）Extended Sensors
センサ関連の情報（データ処理前のＲａｗデータや、処理後のデータ）を車車間等において交換可能とするユースケースである。センサ情報は、ローカルセンサ、ライブビデオイメージ（例えば、周辺の車両、ＲＳＵ、及び歩行者との間のライブビデオイメージ）、及びＶ２Ｘアプリケーションサーバ等を通して集められる。車両はこれらの情報交換により、自身のセンサ情報では得られない情報を入手することが可能となり、より広範囲の環境を認知／認識することが可能となる。なお、本ユースケースでは、多くの情報を交換する必要があるため、通信には高いデータレートが求められる。

（３）Advanced Driving
準自動走行や、完全自動走行を可能とするユースケースである。本ユースケースでは、ＲＳＵが自身のセンサ等から得られた認知／認識情報を周辺車両へとシェアすることで、それぞれの車両が、軌道や操作を他の車両と同期、協調しながら調整することができる。また、それぞれの車両は、ドライビングの意図や意思を周辺車両とシェアすることも可能となる。

（４）Remote Driving
遠隔操縦者やＶ２Ｘアプリケーションに遠隔操縦させるユースケースである。遠隔操作は、運転を行うことが困難な人に替わって他者が運転を行う場合や、危険地域での車両の操作等に用いられる。ルートや走行する道がある程度決まっているような公共交通機関に対しては、例えば、クラウドコンピューティングベースの操縦を適用することも可能である。本ユースケースでは、高い信頼性と低い伝送遅延が通信に求められる。

（物理レイヤエンハンスメント）
上述した要求事項を達成するためには、ＬＴＥ Ｖ２Ｘから物理レイヤのさらなるエンハンスメントが必要となる。対象となるリンクは、ＵｕリンクやＰＣ５リンク（サイドリンク）が挙げられる。Ｕｕリンクは、基地局やＲＳＵ（Road Side Unit）等のインフラストラクチャと、端末装置との間のリンクである。また、ＰＣ５リンク（サイドリンク）は、端末装置間のリンクである。主なエンハンスメントのポイントを以下に示す。

エンハンスメントの一例としては、以下が挙げられる。
−チャネルフォーマット
−サイドリンクフィードバック通信
−サイドリンクリソース割り当て方式
−車両位置情報推定技術
−端末間リレー通信
−ユニキャスト通信、マルチキャスト通信のサポート
−マルチキャリア通信、キャリアアグリゲーション
−MIMO/ビームフォーミング
−高周波周波数対応（例: ６ＧＨｚ以上）
…等

また、チャネルフォーマットとしては、例えば、Flexible numerology、short TTI（Transmission Time Interval）、マルチアンテナ対応、及びWaveform等が挙げられる。また、サイドリンクフィードバック通信としては、例えば、ＨＡＲＱ、ＣＳＩ（Channel Status Information）等が挙げられる。

（Ｖ２Ｘオペレーションシナリオ）
以下に、Ｖ２Ｘの通信オペレーションシナリオの一例について述べる。Ｖ２Ｎ通信においては、基地局−端末装置間のＤＬ／ＵＬ通信のみでシンプルであった。これに対して、Ｖ２Ｖ通信では、多様な通信経路が考えられる。以降では、主にＶ２Ｖ通信の例に着目して、各シナリオの説明を行うが、Ｖ２ＰやＶ２Ｉについても同様の通信オペレーションを適用可能である。なお、Ｖ２ＰやＶ２Ｉにおいては、通信先がPedestrianやＲＳＵとなる。

例えば、図４〜図９は、Ｖ２Ｘオペレーションシナリオの一例を説明するための図である。具体的には、図４は、車両同士が基地局（Ｅ−ＵＴＲＡＮ）を介さずに直接通信を行うシナリオを示している。図５は、車両同士が基地局を介して通信を行うシナリオを示している。図６及び図７は、車両同士が端末装置（ＵＥ、ここではＲＳＵ）及び基地局を介して通信を行うシナリオを示している。図８及び図９は、車両同士が端末装置（ＵＥ、ここではＲＳＵや他の車両）を介して通信を行うシナリオを示している。

なお、図４〜図９において、「サイドリンク」は、端末装置間の通信リンクに相当し、ＰＣ５とも称される。サイドリンクの具体的な一例として、Ｖ２Ｖ、Ｖ２Ｐ、及びＶ２Ｉの通信リンクが挙げられる。「Ｕｕインタフェース」は、端末装置−基地局間の無線インタフェースに相当する。Ｕｕインタフェースの具体的な一例として、Ｖ２Ｎの通信リンクが挙げられる。「ＰＣ５インタフェース」は、端末装置間の無線インタフェースに相当する。

＜１．２．サイドリンク通信の拡張例＞
サイドリンク通信には、多様な拡張例が考えられる。例えば、上述したＶ２Ｘ通信は、サイドリンク通信の拡張例のひとつである。他にも、サイドリンク通信の拡張例として、Ｄ２Ｄ（Device to Device）通信、ＭＴＣ（Machine−type communication）、ムービングセル、及びリレー通信等が考えられる。以下、図１０〜図１３を参照しながら、サイドリンク通信の拡張例を説明する。

図１０は、車両に搭載された車載基地局によりサイドリンク通信が使用される例を示している。図１０に示すように、車載基地局は、周囲の端末装置（例えば、同一の車両内のＵＥ）との間での通信、又は他の車両との間での車車間通信を、サイドリンク通信により行う。車載基地局は、ＵＥであってもよいし、ＲＳＵ等であってもよい。

図１１は、ＵＥにより提供されるウェアラブル端末向けのリレー通信にサイドリンク通信が使用される例を示している。図１１に示すように、ＵＥは、ウェアラブル端末との間でサイドリンク通信を行い、ウェアラブル端末と基地局との間の通信を中継する。

図１２は、ドローンに搭載されたドローン基地局によりサイドリンク通信が使用される例を示している。図１２に示すように、ドローン基地局は、周囲のＵＥとの間でサイドリンク通信を行い、ＵＥと基地局との間の通信を中継する。

図１３は、ＵＥに搭載された端末基地局によりサイドリンク通信が使用される例を示している。図１３に示すように、端末基地局は、周囲のＵＥとの間でサイドリンク通信を行い、ＵＥと基地局との間の通信を中継する。

他にも、サイドリンク通信の拡張例として、ファクトリーオートメーションが挙げられる。その場合、工場内のロボット間の通信にサイドリンク通信が使用され得る。例えば、緊急停止信号をロボット群にブロードキャストして生産ラインを緊急停止するようなユースケースにおいて、サイドリンク通信が使用される。また、サイドリンク通信の拡張例として、ドローン間の通信が挙げられる。

＜１．３．サイドリンクリソース割り当て方式＞
続いて、サイドリンクへのリソース割り当ての方式について概要を説明する。サイドリンクへのリソース割り当ての方式としては、基地局がサイドリンクのリソースを割り当てる「Mode3リソース割り当て」の方式と、端末装置自身でセンシングを行いサイドリンクのリソース選択を行う「Mode4リソース割り当て」の方式とがある。これらについて、図１４を参照しながら説明する。

図１４は、サイドリンクリソース割り当て方式を説明するための図である。図１４の左図は、Mode3リソース割り当ての一例を示している。Mode3リソース割り当てでは、リソースプールが予め割り当てられ、端末に送信パケットが発生すると、リソースプールのうち当該パケットの送信に使用すべきリソースが基地局により割り当てられる。Mode3リソース割り当てでは、送信パケットが発生する度に基地局によりリソース割り当てが行われるので、パケットの衝突が発生しない一方で、高いシグナリングオーバーヘッドが発生する。図１４の右図は、Mode4リソース割り当ての一例を示している。Mode4リソース割り当てでは、リソースプールが予め割り当てられ、送信パケットが発生すると、リソースプールのうち当該パケットの送信に使用するリソースを端末が自律的に選択する。Mode4リソース割り当てでは、シグナリングオーバーヘッドが少ない一方で、パケットの衝突が発生し得る。

−リソースプール割り当て
Mode3リソース割り当て又はMode4リソース割り当てを行うに当たり、事前にリソースプールの割り当てが行われる。当該リソースプールの割り当ては、例えば、基地局により行われる。また、他の一例として、Pre-configurationにより、当該リソースプールの割り当てが行われていてもよい。Mode4リソース割り当てにおいては、端末装置は、割り当てられたリソースプールから、サイドリンク通信用のリソースをセンシングし、適切なリソースを自ら選択して通信を行う。

例えば、図１５は、サイドリンク通信に割り当てられたリソース（リソースプール）の構成の一例について示した図であり、周波数分割多重（ＦＤＭ：Frequency Division Multiplexing）が適用される場合の一例について示している。図１５に示すように、リソースプールは、ＳＡ（Scheduling Assignment）領域とＤａｔａ領域とに分けられ、各領域により、ＰＳＣＣＨ（Physical Sidelink Control Channel）及びＰＳＳＣＨ（Physical Sidelink Shared Channel）が送信される。なお、以降では、図１５に示すようにＦＤＭが適用される場合に着目して説明するが、必ずしも本開示に係る技術の適用先を限定するものではない。具体的な一例として、時間分割多重（ＴＤＭ：Time Division Multiplexing）が適用される場合においても、以降で説明する本開示に係る技術を適用することが可能である。なお、ＴＤＭが適用される場合には、ＳＡ領域とＤａｔａ領域とは時間軸上で直交することとなる。

−Mode4リソース割り当て
図１６を参照して、Mode4リソース割り当ての概要について説明する。図１６は、Mode4リソース割り当てに基づき端末装置がパケットを送信する場合の動作タイムラインの一例について説明するための説明図である。図１６に示すように、パケットを送信する端末装置は、まず、当該パケットの送信に利用するリソースをリソースプール内から発見するためにセンシングを行う。次いで、端末装置は、当該センシングの結果に基づき、当該リソースプール内からのリソースの選択を行う。そして、端末装置は、選択したリソースを利用してパケットの送信を行う。また、このとき端末装置は、必要に応じて、以降におけるパケットの送信に利用するリソースの予約を行う。

ここで、図１７を参照して、上記センシングの動作の一例について説明する。図１７は、リソースプール内からリソースを選択するためのセンシングの動作の一例について説明するための説明図である。

具体的には、端末装置は、センシングウィンドウ内における干渉パターンの測定結果や、当該センシングウィンドウ内におけるリソースの予約状況に基づき、リソース選択ウィンドウ内におけるリソースの選択や、将来のリソースの予約を行う。具体的な一例として、図１７に示す例では、端末装置は、送信対象となるパケットＤが発生した場合に、センシングの結果に基づき、未来のリソースの使用状況、例えば、将来的に他のパケットＡ〜Ｃの送信に利用されるリソースを予測する。端末装置は、当該予測の結果を利用することで、当該パケットＤの送信に利用可能なリソース、即ち、他のパケットの送信に利用されないことが予測されるリソースの選択や予約が可能となる。

＜＜２．提案技術の概要＞＞
＜２．１．システム構成例＞
続いて、図１８を参照しながら、提案技術が適用されるシステムの概略的な構成の一例を説明する。図１８は、本開示の一実施形態に係るシステム１の概略的な構成の一例を示す図である。図１８に示すように、システム１は、基地局１００、端末装置２００（２００Ａ〜２００Ｄ）、コアネットワーク（Core Network）２０、及びＰＤＮ（Packet Data Network）３０を含む。

基地局１００は、セル１１を運用し、セル１１の内部に位置する１つ以上の端末装置２００へ無線サービスを提供する通信装置である。セル１１は、例えばＬＴＥ又はＮＲ等の任意の無線通信方式に従って運用され得る。基地局１００は、コアネットワーク２０に接続される。コアネットワーク２０は、ＰＤＮ３０に接続される。

コアネットワーク２０は、例えばＭＭＥ（Mobility Management Entity）、Ｓ−ＧＷ（Serving gateway）、Ｐ−ＧＷ（PDN gateway）、ＰＣＲＦ（Policy and Charging Rule Function）及びＨＳＳ（Home Subscriber Server）を含み得る。若しくは、コアネットワーク２０は、これらと同様の機能を有するＮＲのエンティティを含み得る。ＭＭＥは、制御プレーンの信号を取り扱う制御ノードであり、端末装置の移動状態を管理する。Ｓ−ＧＷは、ユーザプレーンの信号を取り扱う制御ノードであり、ユーザデータの転送経路を切り替えるゲートウェイ装置である。Ｐ−ＧＷは、ユーザプレーンの信号を取り扱う制御ノードであり、コアネットワーク２０とＰＤＮ３０との接続点となるゲートウェイ装置である。ＰＣＲＦは、ベアラに対するＱｏＳ（Quality of Service）等のポリシー及び課金に関する制御を行う制御ノードである。ＨＳＳは、加入者データを取り扱い、サービス制御を行う制御ノードである。

端末装置２００は、他の装置と無線通信する通信装置である。例えば、端末装置２００は、基地局１００による制御に基づいて基地局１００と無線通信する。その場合、端末装置２００は、Ｕｕリンクにおいて、基地局１００にアップリンク信号を送信して、基地局１００からダウンリンク信号を受信する。また、例えば、端末装置２００は、基地局１００による制御に基づいて、又は自律的に、他の端末装置２００と無線通信する。その場合、端末装置２００は、ＰＣ５リンクにおいて、他の端末装置２００にサイドリンク信号を送信して、他の端末装置２００からサイドリンク信号を受信する。例えば、端末装置２００Ａは端末装置２００Ｂに、端末装置２００Ｃは端末装置２００Ｄに、それぞれサイドリンク信号を送信する。端末装置２００は、いわゆるユーザ端末（User Equipment：ＵＥ）であってもよい。

＜２．２．技術的課題＞
既存のサイドリンク通信においては、Mode3リソース割り当てにおける基地局からのリソース割り当て、又はMode4リソース割り当てにおけるセンシング等の、衝突防止のための所定の手続きが実施された上で送信が行われる。従って、パケット発生からパケット送信に至るまでに遅延が発生してしまう。なお、パケットの衝突とは、少なくとも一部が重複するリソース（時間リソース及び周波数リソース）を使用して、複数のパケットの送受信が行われることを指す。

ＵＲＬＬＣのような、緊急のパケットを低遅延且つ高信頼に送信するユースケースにおいては、このような遅延が発生せずに且つ高信頼にパケットを送信可能にする仕組みが求められる。特に、サイドリンク通信においては、基地局がすべて制御を行う通常のＵｕリンクのグラントフリー送信とは異なり、送信主体が複数の端末装置となるため、パケットの衝突が発生したときの対応がより複雑になる。

＜２．３．提案技術の概要＞
そこで、本開示では、サイドリンクで送信されたパケットと衝突した他のパケットのリカバリを可能にするための仕組みを提供する。とりわけ、本開示では、サイドリンクでグラントフリー送信されたパケットと衝突した他のパケットのリカバリを可能にするための仕組みを提供する。ここでのリカバリとは、例えば再送信である。

端末装置２００は、パケットをグラントフリー送信すると、かかるグラントフリー送信に関する情報を他の装置（例えば、基地局１００又は他の端末装置２００）に報告する。かかる報告を受けた基地局１００又は他の端末装置２００は、衝突の発生有無を判定し、衝突したと判定したパケットの再送のための処理を行う。これにより、グラントフリー送信されたパケットと衝突した他のパケットが再送される。このように、グラントフリー送信によりパケットの低遅延を実現しつつ、グラントフリー送信されたパケットと衝突した他のパケットのリカバリが実現される。

以下では、図１８に示した例において、端末装置２００Ａ（第１の端末装置に相当）が、端末装置２００Ｂへのパケットをグラントフリー送信するものとする。そして、端末装置２００Ｃ（第２の端末装置に相当）が端末装置２００Ｄへ送信したパケットが、端末装置２００Ａによりグラントフリー送信されたパケットと衝突するものとする。以下、端末装置２００Ａを送信端末２００Ａ、端末装置２００Ｂを受信端末２００Ｂ、端末装置２００Ｃを周辺送信端末２００Ｃ、端末装置２００Ｄを周辺受信端末２００Ｄとも称する。他方、これらを特に区別する必要が無い場合、単に端末装置２００とも総称する。また、なお、以下では、送信端末２００Ａが送信するパケットを第１のパケットとも称し、周辺送信端末２００Ｃが送信するパケットを第２のパケットとも称する場合がある。

また、以下では、ＮＲ Ｖ２Ｘ通信におけるサイドリンク通信（Ｖ２Ｖ／Ｉ／Ｐ）にフォーカスする。ＮＲ Ｖ２Ｘ通信では緊急メッセージであるＵＲＬＬＣパケットの送信を行う場合がでてくる。そこで、以下では、サイドリンクにおける低遅延で高信頼（少なくとも低遅延）なＵＲＬＬＣパケット送信方法について説明する。なお、ＵＲＬＬＣパケットとは、ＵＲＬＬＣのユースケースにおいて送信されるパケットである。

＜＜３．構成例＞＞
以下、提案技術に関与する各装置の構成例を説明する。

＜３．１．基地局の構成例＞
図１９は、本実施形態に係る基地局１００の論理的な構成の一例を示すブロック図である。図１９に示すように、本実施形態に係る基地局１００は、アンテナ部１１０、無線通信部１２０、ネットワーク通信部１３０、記憶部１４０及び制御部１５０を含む。

アンテナ部１１０は、無線通信部１２０により出力される信号を電波として空間に放射する。また、アンテナ部１１０は、空間の電波を信号に変換し、当該信号を無線通信部１２０へ出力する。

無線通信部１２０は、信号を送受信する。例えば、無線通信部１２０は、端末装置からのアップリンク信号を受信し、端末装置へのダウンリンク信号を送信する。

ネットワーク通信部１３０は、情報を送受信する。例えば、ネットワーク通信部１３０は、他のノードへの情報を送信し、他のノードからの情報を受信する。例えば、上記他のノードは、他の基地局及びコアネットワークノードを含む。

記憶部１４０は、基地局１００の動作のためのプログラム及び様々なデータを一時的に又は恒久的に記憶する。

制御部１５０は、基地局１００の様々な機能を提供する。例えば、制御部１５０は、通信制御部１５１を含む。通信制御部１５１は、端末装置２００へのリソースプールの割り当て、送信パケットが発生した端末装置２００へのリソースの割り当て、衝突したパケットの再送指示等の、制御下の端末装置２００によるサイドリンク通信を制御する機能を有する。制御部１５０は、通信制御部１５１以外の他の構成要素をさらに含み得る。即ち、制御部１５０は、通信制御部１５１の動作以外の動作も行い得る。

＜３．２．端末装置の構成例＞
図２０は、本実施形態に係る端末装置２００の論理的な構成の一例を示すブロック図である。図２０に示すように、本実施形態に係る端末装置２００は、アンテナ部２１０、無線通信部２２０、記憶部２３０及び制御部２４０を含む。

アンテナ部２１０は、無線通信部２２０により出力される信号を電波として空間に放射する。また、アンテナ部２１０は、空間の電波を信号に変換し、当該信号を無線通信部２２０へ出力する。

無線通信部２２０は、信号を送受信する。例えば、無線通信部２２０は、基地局からのダウンリンク信号を受信し、基地局へのアップリンク信号を送信する。また、無線通信部２２０は、他の端末装置２００との間でサイドリンク信号（Ｖ２Ｐ信号／Ｖ２Ｖ信号／Ｖ２Ｉ信号等）を送受信する。

記憶部２３０は、端末装置２００の動作のためのプログラム及び様々なデータを一時的に又は恒久的に記憶する。

制御部２４０は、端末装置２００の様々な機能を提供する。例えば、制御部２４０は、送信処理部２４１及び受信処理部２４３を含む。送信処理部２４１は、上位層から入力されたパケットのグラントベース送信、グラントフリー送信、及び再送等を行う機能を有する。受信処理部２４３は、パケットを受信及び復号して上位層に出力する機能を有する。制御部２４０は、これらの構成要素以外の他の構成要素をさらに含み得る。即ち、制御部１５０は、これらの構成要素の動作以外の動作も行い得る。

＜＜４．技術的特徴＞＞
＜４．１．Mode3リソース割り当て環境における処理＞
以下では、Mode3リソース割り当て環境における衝突防止のための所定の手続きが省略されて送信された（即ち、グラントフリー送信された）パケットに衝突したパケットの、リカバリについて説明する。本例での衝突防止のための所定の手続きとは、リソースの割り当て（即ち、グラント）である。

＜４．１．１．概要＞
送信端末２００Ａは、第１のパケットをグラントフリー送信（Configured Grant送信とも称される）し、かかるグラントフリー送信に関する情報を、基地局１００に報告する。基地局１００は、Mode3リソース割り当てを行う関係で、周辺送信端末２００Ｃが第２のパケットの送信に使用したリソースを把握しており、衝突の発生有無を判定可能である。基地局１００は、衝突が発生したと判定した第２のパケットの再送を周辺送信端末２００Ｃに指示する。

送信端末２００Ａは、グラントフリー送信に関する情報を、周辺の他の端末装置２００（例えば、周辺送信端末２００Ｃ）に報告してもよい。その場合、周辺送信端末２００Ｃは、パケットの衝突発生有無を判定し、衝突が発生したと判定したパケットの再送を行う。

＜４．１．２．グラントベース送信＞
以下、比較のために、図２１を参照しながら、通常のグラントベース送信の処理の流れを説明する。図２１は、グラントベース送信の処理の流れの一例を示すシーケンス図である。本シーケンスには、基地局１００、送信端末２００Ａ、受信端末２００Ｂ、周辺送信端末２００Ｃ、及び周辺受信端末２００Ｄが関与する。

図２１に示すように、まず、基地局１００は、制御下の端末装置２００（２００Ａ〜２００Ｄ）の各々に、サイドリンク通信に関する制御情報を通知する（ステップＳ１２）。かかる制御情報は、例えば、リソースプールの割り当て情報、送信電力の設定情報、及びＭＣＳ（Modulation and Coding Scheme）の設定情報等の、各種設定情報を含む。次いで、基地局１００は、送信パケットが発生した端末装置２００に対しリソース割り当てを行い（ステップＳ１４）、リソースの割り当て結果を含むサイドリンクリソースグラントを送信する（ステップＳ１６）。次に、送信端末２００Ａは、割り当てられたリソースを使用して第１のパケットを送信し（ステップＳ１８）、受信端末２００Ｂは、第１のパケットを受信する（ステップＳ２０）。他方、周辺送信端末２００Ｃは、割り当てられたリソースを使用して第２のパケットを送信し（ステップＳ２２）、周辺受信端末２００Ｄは、第２のパケットを受信する（ステップＳ２４）。

＜４．１．３．グラントフリー送信及びリカバリ処理＞
続いて、図２２を参照しながら、提案技術に係るグラントフリー送信及びリカバリ処理の流れを説明する。図２２は、本実施形態に係るシステム１において実行されるグラントフリー送信及びリカバリ処理の流れの一例を示すシーケンス図である。本シーケンスには、基地局１００、送信端末２００Ａ、受信端末２００Ｂ、周辺送信端末２００Ｃ、及び周辺受信端末２００Ｄが関与する。

図２２に示すように、まず、基地局１００は、制御下の端末装置２００（２００Ａ〜２００Ｄ）の各々に、サイドリンク通信に関する制御情報を通知する（ステップＳ１０２）。次いで、基地局１００は、送信すべき第２のパケットが発生した端末装置２００に対しリソース割り当てを行い（ステップＳ１０４）、リソースの割り当て結果を含むサイドリンクリソースグラントを送信する（ステップＳ１０６）。次に、周辺送信端末２００Ｃは、割り当てられたリソースを使用して第２のパケットを送信し（ステップＳ１０８）、周辺受信端末２００Ｄは、第２のパケットを受信する（ステップＳ１１０）。

一方、送信端末２００Ａは、送信すべき第１のパケット（ここでは、ＵＲＬＬＣパケット）が発生すると（ステップＳ１１２）、第１のパケットをグラントフリー送信し（ステップＳ１１４）、受信端末２００Ｂは、第１のパケットを受信する（ステップＳ１１６）。

衝突防止のための所定の手続き（即ち、リソースグラント）を省略して第１のパケットが送信されるので、低遅延が実現される。一方で、送信端末２００Ａがグラントフリー送信を行っていることから、第１のパケットと第２のパケットとに衝突が発生する可能性がある。この衝突に起因する第２のパケットの受信失敗のリカバリのために、送信端末２００Ａは、事後処理を実施する。

具体的には、送信端末２００Ａは、第１のパケットをグラントフリー送信した旨を基地局１００に報告する、パケット送信報告を行う（ステップＳ１１８）。詳しくは、送信端末２００Ａは、第１のパケットのグラントフリー送信に使用されたリソースの時間及び周波数を示す情報を含む送信報告情報を、基地局１００に送信する。その後、基地局１００は、受信した送信報告情報に基づいて、第２のパケットに対する自らのリソース割り当て結果と第１のパケットの送信に使用されたリソースとを比較し、衝突の発生有無を確認する（ステップＳ１２０）。衝突が発生していた場合、周辺受信端末２００Ｄが第２のパケットの受信に失敗している可能性があることから、基地局１００は、リカバリ処理を実施する（ステップＳ１２２）。基地局１００によるリカバリ処理は、例えば、周辺送信端末２００Ｃに再送手続きを行うよう指示することを含む。その場合、基地局１００は、サイドリンクリソースの再割り当てを行い、再割り当て結果を含むサイドリンクリソースグラント及び第２のパケットのリカバリ指示を、周辺送信端末２００Ｃに送信する。周辺送信端末２００Ｃは、リカバリ指示を受信すると、再度割り当てられたリソースを使用して第２のパケットを再送し（ステップＳ１２４）、周辺受信端末２００Ｄは、再送された第２のパケットを受信する（ステップＳ１２６）。このようにして、ステップＳ１１０において周辺受信端末２００Ｄが第２のパケットの受信に失敗していた場合、ステップＳ１２６において第２のパケットの受信に成功させることができる。

なお、図２２に示した例では、送信報告情報が基地局１００に送信されていたが、本技術はかかる例に限定されない。例えば、送信報告情報は、周辺送信端末２００Ｃに直接的に送信されてもよい。その場合、周辺送信端末２００Ｃが、衝突の発生有無を確認し、衝突が発生したと判定した場合にリカバリ処理を行う。周辺送信端末２００Ｃによるリカバリ処理は、例えば、リソース要求を基地局１００に送信し、割り当てられたリソースを使用して第２のパケットを再送することを含む。なお、リソース要求とは、リソース割り当ての要求である。

＜４．１．４．各装置の動作＞
以上、Mode3リソース割り当て環境における処理の概要を説明した。以下では、各ノードの動作を詳細に説明する。

（１）送信端末２００Ａの動作
−第１のパケット発生時の判断
送信端末２００Ａ（例えば、送信処理部２４１）は、ＵＲＬＬＣパケットである第１のパケットが発生した場合、以下の判断を行い得る。

送信端末２００Ａは、第１のパケットを送信可能な割り当てリソースがあるか否かを判定してもよい。割り当てリソースが有ると判定された場合、送信端末２００Ａは、割り当てリソースを使用して第１のパケットを送信する。他方、割り当てリソースが無いと判定された場合、送信端末２００Ａは、基地局１００にリソース要求を送信する。なお、ＵＲＬＬＣパケットを送信可能なリソースは、基地局１００からのＲＲＣ（Radio Resource Control）シグナリングにより事前に割り当てられ得る。

送信端末２００Ａは、仮に基地局１００にリソース要求を送信した場合に遅延要求が満たされるか否かを判定してもよい。即ち、送信端末２００Ａは、リソース要求を送信した場合に基地局１００により割り当てられると想定されるリソースを使用して第１のパケットを送信する場合に、遅延要求が満たされるか否かを判定する。遅延要求が満たされると判定された場合、送信端末２００Ａは、リソース要求を送信する。他方、遅延要求が満たされないと判定された場合、送信端末２００Ａは、グラントフリー送信を行う。

−グラントフリー送信
上述したように、グラントフリー送信とは、パケットの衝突防止のための所定の手続きが実施されずにパケットが送信される方法である。換言すると、グラントフリー送信とは、パケットの衝突防止のための所定の基準を満たせない（即ち、パケットの衝突が発生し得る）送信方法である。

ここでの所定の手続きは、パケットの送信のためのリソースの割り当てを受けることを含む。即ち、グラントフリー送信では、基地局１００によるリソースの割り当てを経ずに、パケットが送信される。

なお、グラントフリー送信に先立って、センシング又はＬＢＴ（Listen Before Talk）が実施されてもよい。ここでのセンシングは、３ＧＰＰ ＬＴＥ Ｖ２Ｘで規定されているような、所定時間（１秒など）のセンシングである。また、ＬＢＴとは、より短期間のセンシングを指し、例えばＷｉ−Ｆｉ（登録商標）で用いられているような、送信前の数ｍｓオーダーのセンシングである。センシングの実施可否は、基地局１００により設定される。

グラントフリー送信用のリソースプールが、基地局１００からのＲＲＣシグナリングにより事前に割り当てられてもよい。カバレッジ外の場合、グラントフリー送信用のリソースプールが、端末装置２００にPre-configurationされてもよい。グラントフリー送信用のリソースプールは、通常の（即ち、グラントベース送信用の）リソースプールと同一であってもよいし、時間方向及び／又は周波数方向に制限されていてもよい。

グラントフリー送信用のリソースプールに関するＲＲＣシグナリングは、リソースプールの時間方向の位置を示す情報、及び周波数方向の位置を示す情報、並びに繰り返し送信のための繰り返し送信回数を示す情報等を含む。なお、リソースプールの時間方向の位置を示す情報は、シンボル単位、スロット単位、又はサブフレーム単位の、時間方向における所定の時間周期に関する情報を含み得る。また、リソースプールの周波数方向の位置を示す情報は、リソースブロック又はリソースエレメントに関する情報を含み得る。

グラントフリー送信では、送信端末２００Ａは自ら送信リソースをランダムに選択してもよい。また、送信端末２００Ａは、所定の選択基準に従って送信リソースを選択してもよい。所定の選択基準は、例えば、基地局１００により設定され得る。

−送信報告情報の送信
送信端末２００Ａ（例えば、送信処理部２４１）は、サイドリンクで第１のパケットをグラントフリー送信した後、第１のパケットのグラントフリー送信に関する情報を含む送信報告情報を送信する。送信報告情報が送信されることで、送信報告情報の受信側での第１のパケットと第２のパケットとの衝突の発生有無の確認が可能となり、衝突が発生していた場合に第２パケットの再送が実現される。とりわけ、送信端末２００Ａは、パケットの衝突防止のための所定の手続き（即ち、リソース割り当て）が実施されずに第１のパケットを送信する場合に、送信報告情報を送信する。パケットの衝突が発生し得る場合に限定して送信報告情報が送信されるので、シグナリングオーバーヘッドを抑制することができる。

送信端末２００Ａは、送信報告情報をＵｕリンク及び／又はサイドリンクで送信する。即ち、送信端末２００Ａは、送信報告情報を基地局１００に送信してもよいし、送信報告情報を他の端末装置２００（即ち、周辺送信端末２００Ｃ）に送信してもよい。送信報告情報の送信には、物理層の制御チャネルが使用される。送信報告情報が基地局１００に送信される場合、予め規定又は設定されたアップリンク制御チャネル（ＰＵＣＣＨ）が使用される。送信報告情報が他の端末装置２００に送信される場合、予め規定又は設定されたサイドリンク制御チャネルが使用される。

送信端末２００Ａは、第１のパケットの送信に使用されるリソースと時間方向に所定の関係にあるリソースを使用して、送信報告情報を送信してもよい。例えば、第１のパケットの送信に使用されるリソースに基づいて、送信報告情報の送信に使用されるリソースが決定される。送信報告情報の送信に使用されるスロットは、第１のパケットの送信に使用されるスロットと同じスロット又は次のスロットであってもよい。ここで、送信報告情報の送信に使用されるスロットは、第１のパケットの送信に使用されるシンボルに応じて決定されてもよい。例えば、第１のパケットの送信が、あるスロット内の所定のシンボルよりも前に行われる場合、送信報告情報の送信に使用されるスロットは、第１のパケットの送信に使用されるスロットと同じスロットに決定される。他方、第１のパケットの送信が、あるスロット内の所定のシンボルよりも後に行われる場合、送信報告情報の送信に使用されるスロットは、第１のパケットの送信に使用されるスロットの次のスロットに決定される。基地局１００又は周辺送信端末２００Ｃは、上述した所定の関係を利用して、送信報告情報を容易に受信することができる。詳しくは、基地局１００又は周辺送信端末２００Ｃは、第２のパケットの送信に使用されるリソースと時間方向に上述した所定の関係にあるリソースを常時監視する。これにより、実際に衝突が発生して送信報告情報が送信された場合に、基地局１００又は周辺送信端末２００Ｃは、送信報告情報を受信することができる。

−送信報告情報の内容
送信報告情報は、送信端末２００Ａが第１のパケットのグラントフリー送信に使用したリソースの時間及び周波数を示す情報を含む。例えば、送信報告情報は、リソースブロック番号、シンボル番号、スロット番号、及び／又はシステムフレーム番号を含んでいてもよい。また、例えば、送信報告情報は、送信リソースのスタート番号及び送信リソースのエンド番号を含んでいてもよい。なお、情報量削減のため、報告用のリソースが予め規定又は設定され、グラントフリー送信に実際に使用されたリソースを包含する報告用のリソースを示す情報が、送信報告情報に含まれてもよい。報告用のリソースは、グラントフリー送信に使用され得るリソースの大きさよりも大きく規定又は設定されることが望ましい。送信報告情報が時間周波数情報を含むことで、送信報告情報の受信側で、衝突の発生有無を判断することが可能となる。

送信報告情報は、以下に示す情報の少なくともいずれかをさらに含み得る。
−第１のパケットの送信に使用したリソースプールを示す情報
−第１のパケットの送信に使用した周波数帯域を示す情報
−第１のパケットの送信繰り返し回数を示す情報
−第１のパケットの送信に使用した送信電力を示す情報
−第１のパケットの優先度を示す情報
−第１のパケットを送信したときの送信端末２００Ａの位置情報
−第１のパケットの送信時のＭＣＳ情報
−第１のパケットの送信時のトランスミッションモード情報
−第１のパケットの送信時のＱＣＬ（Quasi−Colocation）情報

−処理の流れ
以下、図２３を参照しながら、送信端末２００Ａによる処理の流れの一例を説明する。図２３は、本実施形態に係る送信端末２００Ａにより実行される第１のパケットの送信処理及び事後処理の流れの一例を示すフローチャートである。

図２３に示すように、まず、送信端末２００Ａにおいて、送信すべき第１のパケット（例えば、ＵＲＬＬＣパケット）が発生する（ステップＳ１３２）。すると、送信端末２００Ａは、第１のパケットを送信可能な割り当てリソースがあり、且つそのリソースを使用した場合に遅延要求が満たされるかを判定する（ステップＳ１３４）。ステップＳ１３４がＹＥＳの場合、送信端末２００Ａは、当該割り当てリソースを使用して第１のパケットを送信する（ステップＳ１３６）。ステップＳ１３４がＮＯの場合、送信端末２００Ａは、基地局１００にリソース要求を送信した場合に遅延要求が満たされるかを判定する（ステップＳ１３８）。ステップＳ１３８がＹＥＳの場合、送信端末２００Ａは、リソース要求を基地局１００に送信し（ステップＳ１４０）、基地局１００から割り当てられたリソースを使用して第１のパケットを送信する（ステップＳ１３６）。他方、ステップＳ１３８がＮＯ場合、送信端末２００Ａは、グラントフリー送信の実施を決定し（ステップＳ１４２）、第１のパケットをグラントフリー送信する（ステップＳ１４４）。そして、送信端末２００Ａは、第１のパケットのグラントフリー送信に関する情報を含む送信報告情報を送信する（ステップＳ１４６）。

（２）受信端末２００Ｂの動作
受信端末２００Ｂ（例えば、受信処理部２４３）は、送信端末２００Ａから送信された第１のパケットを受信し、復号する。

（３）基地局１００の動作
−リソース割り当て
基地局１００（例えば、通信制御部１５１）は、制御下の端末装置２００に送信パケットが発生した場合に、かかるパケットを送信するためのリソースを割り当てる。基地局１００は、送信端末２００Ａに対し、事前にＵＲＬＬＣパケット送信用のリソース割り当てを実施してもよい。この場合、基地局１００は、ＲＲＣシグナリングを用いて事前の割り当て結果を送信端末２００Ａに送信する。

−リカバリ処理
基地局１００（例えば、通信制御部１５１）は、送信端末２００Ａによるサイドリンクでの第１のパケットのグラントフリー送信に関する情報を含む送信報告情報に基づいて、サイドリンクで第２のパケットを送信した周辺送信端末２００Ｃによる第２のパケットの再送を制御する。詳しくは、まず、基地局１００は、送信報告情報に基づいて、第１のパケットと第２のパケットとの衝突の発生有無を判定する。具体的には、基地局１００は、送信報告情報が示す第１のパケットの送信に使用されたリソースと所定の関係にあるリソースを、他の端末装置２００に割り当てたか否かを確認する。ここでの所定の関係にあるリソースとは、例えば、第１のパケットの送信に使用されたリソースと、同一のリソース、又は少なくとも一部が重複するリソースである。基地局１００は、第１のパケットの送信に使用されたリソースと所定の関係にあるリソースを他の端末装置２００に割り当てていた場合に衝突が発生したと判定し、そうでない場合に衝突は発生していないと判定する。そして、基地局１００は、第１のパケットと第２のパケットとが衝突したと判定された場合に、リカバリ指示を周辺送信端末２００Ｃに送信することで、第２のパケットの再送を指示する。他方、基地局１００は、第１のパケットと第２のパケットとが衝突していないと判定された場合に、再送を指示しない。これにより、パケットの衝突が発生した場合に限定して再送が指示されるので、シグナリングオーバーヘッドを抑制することができる。

基地局１００は、第１のパケットと第２のパケットとが衝突したと判定された場合、第２のパケットを再送した場合に第２のパケットの遅延要求が満たされるか否かにさらに基づいて、再送を制御してもよい。例えば、基地局１００は、第２のパケットを再送しても第２のパケットの遅延要求が満たされる場合に再送を指示し、満たされない場合に再送を指示しない。この場合、周辺送信端末２００Ｃによる第２のパケットの再送は実施されない。これにより、パケットの衝突が発生し、且つ再送しても遅延要求が満たされる場合に限定して再送が指示されるので、シグナリングオーバーヘッドを抑制することができる。

−リカバリ指示の内容
リカバリ指示は、第２のパケットの再送を指示する情報である。よって、リカバリ指示により、周辺送信端末２００Ｃによる第２のパケットの再送をトリガすることができる。

リカバリ指示は、第２のパケットの再送のために割り当てられたリソースを示す情報を含み得る。この場合、基地局１００は、第２のパケットの送信のためのリソースを再度割り当て、リカバリ指示は、再度のリソースの割り当て結果を含む。

リカバリ指示は、第２のパケットの再送のための送信パラメータを含み得る。再送のための送信パラメータは、例えば、送信電力、ＭＣＳ、及び送信繰り返し回数等を含み得る。

−処理の流れ
以下、図２４を参照しながら、基地局１００による処理の流れの一例を説明する。図２４は、本実施形態に係る基地局１００により実行されるリカバリ処理の流れの一例を示すフローチャートである。

図２４に示すように、まず、基地局１００は、ＵＲＬＬＣパケット送信用のリソース割り当てを行う（ステップＳ１５２）。ただし、本ステップはオプションであり、実行されなくてもよい。次いで、基地局１００は、第１のパケットをグラントフリー送信した送信端末２００Ａから送信報告情報を受信する（ステップＳ１５４）。次に、基地局１００は、送信報告情報が示す第１のパケットの送信に使用されたリソースと所定の関係にあるリソースを、他の端末装置２００に割り当てたか否かを確認することで、衝突の発生有無を確認する（ステップＳ１５６）。そして、衝突が発生したと判定された場合（ステップＳ１５８／ＹＥＳ）、基地局１００は、第１のパケットと衝突した第２のパケットを送信した周辺送信端末２００Ｃにリカバリ指示を送信する（ステップＳ１６０）。他方、衝突が発生していないと判定された場合（ステップＳ１５８／ＮＯ）、基地局１００は、何も実行しない。

（４）周辺送信端末２００Ｃの動作
周辺送信端末２００Ｃ（例えば、送信処理部２４１）は、基地局１００による制御に基づいて、サイドリンクで第２のパケットを送信する。詳しくは、周辺送信端末２００Ｃは、基地局１００により割り当てられたリソースを使用して、第２のパケットを送信する。ただし、周辺送信端末２００Ｃは、基地局１００からリカバリ指示を受信した場合に、リカバリ指示に基づいて第２のパケットを再送する。詳しくは、周辺送信端末２００Ｃは、リカバリ指示が示す再送用のリソースを使用して、第２のパケットを送信する。

（５）周辺受信端末２００Ｄの動作
周辺受信端末２００Ｄ（例えば、受信処理部２４３）は、周辺送信端末２００Ｃから送信された第２のパケットを受信し、復号する。

＜４．１．５．変形例＞
上記では、送信報告情報が、基地局１００へアップリンク制御チャネルを用いて送信される例を主に説明したが、本技術はかかる例に限定されない。例えば、送信報告情報は、サイドリンクで送信されてもよい。

−サイドリンクでの通知
送信端末２００Ａは、グラントフリー送信する第１のパケットのＳＣＩ（Sidelink Control Information）に、グラントフリー送信するパケットであることを示す情報を含めてもよい。受信側は、ＰＳＣＣＨ（Physical Sidelink Control Channel）をデコードすることで、第１のパケットがグラントフリー送信されたことを認識することができる。さらに、かかるＳＣＩは、第１のパケットのグラントフリー送信に用いるリソースの時間及び周波数を示す情報を含んでいてもよい。これにより、受信側は、第１のパケットのグラントフリー送信に用いるリソースを認識し、衝突確認に用いることができる。なお、グラントフリー送信は、繰り返し送信などが行われることが想定されるため、全繰り返し送信内の１パケットを受信した場合でも、全繰り返し送信の時間周波数リソースを把握可能となる方法が望ましい。そのため、制御領域が上述の情報を含む方法以外に、データ領域が各繰り返し送信の時間周波数リソースを示す情報を含む方法が採用されてもよい。

−黙示的なパケット送信報告
送信端末２００Ａは、送信報告情報を、黙示的に通知してもよい。送信方向情報の黙示的な通知について、図２５〜図２７を参照しながら説明する。

図２５及び図２６は、本実施形態に係る送信報告情報の黙示的な通知方法の一例を説明するための図である。図２５に示した例では、第１のパケットを構成する制御チャネル及びデータチャネルの各々が繰り返し送信されており、各々のチャネルの周波数オフセットが示す周波数ホッピングパターンが、送信報告情報に対応している。即ち、図２５に示した例では、送信報告情報に対応する周波数ホッピングパターンが、第１のパケットの繰り返し送信に使用される。図２６に示した例では、第１のパケットを構成する制御チャネル及びデータチャネルの各々が繰り返し送信されており、各々のチャネルの時間オフセットが示す時間間隔パターンが、送信報告情報に対応している。即ち、図２６に示した例では、送信報告情報に対応する時間間隔パターンが、第１のパケットの繰り返し送信に使用される。

このように、送信端末２００Ａは、第１のパケットをグラントフリーに且つ繰り返し送信しつつ、繰り返し送信パターン（周波数ホッピングパターン及び／又は時間間隔パターン）により送信報告情報を通知してもよい。繰り返し送信パターンは、Pre-configureされていてもよいし、基地局１００からのＲＲＣシグナリングにより設定されてもよい。

図２７は、本実施形態に係る送信報告情報の黙示的な通知方法の一例を説明するための図である。図２７に示した例では、第１のパケットを構成する制御チャネル及びデータチャネルが送信されており、隣接するチャネル間の時間オフセット値が、送信報告情報に対応している。即ち、図２７に示した例では、送信報告情報に対応する時間オフセット値が、第１のパケットの送信に使用される。同様に、送信報告情報に対応する周波数オフセット値が、第１のパケットの送信に使用されてもよい。なお、図２７に示した例では、第１のパケットは繰り返し送信されなくてもよい。

他に、送信電力により送信報告情報が通知されてもよい。例えば、送信端末２００Ａは、グラントベース送信よりも大きな送信電力でグラントフリー送信を行ってもよい。その場合、周辺送信端末２００Ｃは、所定の閾値よりも大きな受信電力を検知した場合に、グラントフリー送信されたことを認識する。所定の閾値は、Pre-configureされていてもよいし、基地局１００からのＲＲＣシグナリングにより設定されてもよい。

−黙示的な通知に基づくリカバリ処理
以下、図２８〜図３０を参照しながら、黙示的な通知に基づくリカバリ処理について説明する。

−基地局１００が黙示的な通知を検出する例
図２８は、本実施形態に係るシステム１において実行される送信報告情報の黙示的な通知に基づくリカバリ処理の流れの一例を示すシーケンス図である。本シーケンスには、基地局１００、送信端末２００Ａ、受信端末２００Ｂ、周辺送信端末２００Ｃ、及び周辺受信端末２００Ｄが関与する。

図２８に示したステップＳ２０２〜Ｓ２１２に係る処理は、図２２に示したステップＳ１０２〜Ｓ１１２に係る処理と同様である。ステップＳ２１２の後、送信端末２００Ａは、第１のパケットをグラントフリー送信しつつ、送信報告情報を黙示的に送信する黙示的なパケット送信報告を行う（ステップＳ２１４）。受信端末２００Ｂは、第１のパケットを受信する（ステップＳ２１６）。他方、基地局１００は、黙示的に送信された送信報告情報に基づいて、第１のパケットがグラントフリー送信されたことを検出する（ステップＳ２１８）。その後のステップＳ２２０〜Ｓ２２６に係る処理は、図２２に示したステップＳ１２０〜Ｓ１２６に係る処理と同様である。

なお、基地局１００が黙示的に送信された送信報告情報を検出するためには、サイドリンク信号を受信するか、又は第１のパケットがグラントフリー送信されたことを示す情報を周辺受信端末２００Ｄ等から報告されることが望ましい。

−周辺送信端末２００Ｃが黙示的な通知を検出する例
図２９は、本実施形態に係るシステム１において実行される送信報告情報の黙示的な通知に基づくリカバリ処理の流れの一例を示すシーケンス図である。本シーケンスには、基地局１００、送信端末２００Ａ、受信端末２００Ｂ、周辺送信端末２００Ｃ、及び周辺受信端末２００Ｄが関与する。

図２９に示したステップＳ２３２〜Ｓ２４６に係る処理は、図２８に示したステップＳ２０２〜Ｓ２１６に係る処理と同様である。ステップＳ２４６の後、周辺送信端末２００Ｃは、黙示的に送信された送信報告情報に基づいて、第１のパケットがグラントフリー送信されたことを検出する（ステップＳ２４８）。次いで、周辺送信端末２００Ｃは、送信報告情報に基づいて、自らが第２のパケットの送信に使用したリソースと第１のパケットの送信に使用されたリソースとを比較し、衝突の発生有無を確認する（ステップＳ２５０）。衝突が発生していた場合、周辺受信端末２００Ｄが第２のパケットの受信に失敗している可能性があることから、周辺送信端末２００Ｃは、リカバリ処理を実施する（ステップＳ２５２）。周辺送信端末２００Ｃによるリカバリ処理は、例えば、第２のパケットの再送のためのリソース要求を基地局１００に送信すること、及び割り当てられたリソースを使用して第２のパケットを再送することを含む。周辺送信端末２００Ｃは、再度割り当てられたリソースを使用して第２のパケットを再送し（ステップＳ２５４）、周辺受信端末２００Ｄは、再送された第２のパケットを受信する（ステップＳ２５６）。

−周辺受信端末２００Ｄが黙示的な通知を検出する例
図３０は、本実施形態に係るシステム１において実行される送信報告情報の黙示的な通知に基づくリカバリ処理の流れの一例を示すシーケンス図である。本シーケンスには、基地局１００、送信端末２００Ａ、受信端末２００Ｂ、周辺送信端末２００Ｃ、及び周辺受信端末２００Ｄが関与する。

図３０に示したステップＳ２６２〜Ｓ２７６に係る処理は、図２８に示したステップＳ２０２〜Ｓ２１６に係る処理と同様である。ステップＳ２７６の後、周辺受信端末２００Ｄは、黙示的に送信された送信報告情報に基づいて、第１のパケットがグラントフリー送信されたことを検出する（ステップＳ２７８）。次いで、周辺受信端末２００Ｄは、送信報告情報に基づいて、第２のパケットの受信に使用したリソースと第１のパケットの送信に使用されたリソースとを比較し、衝突の発生有無を確認する（ステップＳ２８０）。衝突が発生していた場合、周辺受信端末２００Ｄが第２のパケットの受信に失敗している可能性があることから、周辺受信端末２００Ｄは、リカバリ処理を実施する（ステップＳ２８２）。周辺受信端末２００Ｄによるリカバリ処理は、例えば、周辺送信端末２００Ｃに再送手続きを行うよう指示することを含む。その場合、周辺受信端末２００Ｄは、第２のパケットのリカバリ指示を、周辺送信端末２００Ｃに送信する。周辺送信端末２００Ｃは、リカバリ指示を受信すると、リカバリ処理を実施する（ステップＳ２８４）。周辺送信端末２００Ｃによるリカバリ処理は、例えば、第２のパケットの再送のためのリソース要求を基地局１００に送信すること、及び割り当てられたリソースを使用して第２のパケットを再送することを含む。周辺送信端末２００Ｃは、再度割り当てられたリソースを使用して第２のパケットを再送し（ステップＳ２８６）、周辺受信端末２００Ｄは、再送された第２のパケットを受信する（ステップＳ２８８）。

＜４．２．Mode4リソース割り当て環境における処理＞
以下では、Mode4リソース割り当て環境における衝突防止のための所定の手続きが省略されて送信された（即ち、グラントフリー送信された）パケットに衝突したパケットの、リカバリについて説明する。本例での衝突防止のための所定の手続きとは、センシングである。Mode4におけるグラントフリー送信を、Mode3におけるグラントフリー送信と特別するために、以下ではセンシングレス送信とも称する。

送信端末２００Ａは、第１のパケットをセンシングレス送信し、かかるセンシングレス送信に関する情報を、周辺の他の端末装置２００（例えば、周辺送信端末２００Ｃ）に報告する。周辺送信端末２００Ｃは、自らが第２のパケットの送信に使用したリソースを把握しているので、衝突の発生有無を判定可能である。周辺送信端末２００Ｃは、衝突が発生したと判定した第２のパケットの再送を行う。

なお、以下では、Mode3リソース割り当て環境における動作と同一の動作については記載を省略し、差分について記載するものとする。

＜４．２．１．センシングレス送信及びリカバリ処理＞
以下、図３１を参照しながら、提案技術に係るセンシングレス送信及びリカバリ処理の流れを説明する。図３１は、本実施形態に係るシステム１において実行されるセンシングレス送信及びリカバリ処理の流れの一例を示すシーケンス図である。本シーケンスには、基地局１００、送信端末２００Ａ、受信端末２００Ｂ、周辺送信端末２００Ｃ、及び周辺受信端末２００Ｄが関与する。

図３１に示すように、まず、基地局１００は、制御下の端末装置２００（２００Ａ〜２００Ｄ）の各々に、サイドリンク通信に関する制御情報を通知する（ステップＳ３０２）。周辺送信端末２００Ｃは、送信すべき第２のパケットが発生すると、所定のセンシングを行い（ステップＳ３０４）、空きを確認したリソースを使用して第２のパケットを送信する（ステップＳ３０６）。周辺受信端末２００Ｄは、第２のパケットを受信する（ステップＳ３０８）。

一方、送信端末２００Ａは、送信すべき第１のパケット（ここでは、ＵＲＬＬＣパケット）が発生すると（ステップＳ３１０）、第１のパケットをセンシングレス送信する（ステップＳ３１２）。受信端末２００Ｂは、第１のパケットを受信する（ステップＳ３１４）。

衝突防止のための所定の手続き（即ち、センシング）を省略して第１のパケットが送信されるので、低遅延が実現される。一方で、送信端末２００Ａがセンシングレス送信を行っていることから、第１のパケットと第２のパケットとに衝突が発生する可能性がある。この衝突に起因する第２のパケットの受信失敗のリカバリのために、送信端末２００Ａは、事後処理を実施する。

具体的には、送信端末２００Ａは、第１のパケットをセンシングレス送信した旨を周辺の他の端末装置２００に報告する、パケット送信報告を行う（ステップＳ３１６）。詳しくは、送信端末２００Ａは、第１のパケットのセンシングレス送信に使用されたリソースの時間及び周波数を示す情報を含む送信報告情報を、周辺の他の端末装置２００（例えば、周辺送信端末２００Ｃ）に送信する。その後、周辺送信端末２００Ｃは、受信した送信報告情報に基づいて、自らが第２のパケットの送信に使用したリソースと第１のパケットの送信に使用されたリソースとを比較し、衝突の発生有無を確認する（ステップＳ３１８）。衝突が発生していた場合、周辺受信端末２００Ｄが第２のパケットの受信に失敗している可能性があることから、周辺送信端末２００Ｃは、リカバリ処理を実施する（ステップＳ３２０）。周辺送信端末２００Ｃによるリカバリ処理は、例えば、第２のパケットを再送することを含む。周辺送信端末２００Ｃは、再度割り当てられたリソースを使用して第２のパケットを再送し（ステップＳ３２２）、周辺受信端末２００Ｄは、再送された第２のパケットを受信する（ステップＳ３２４）。

なお、図３１に示した例では、送信報告情報が周辺送信端末２００Ｃに直接的に送信されているが、本技術はかかる例に限定されない。例えば、送信報告情報は、基地局１００を介して周辺送信端末２００Ｃに送信されてもよい。その場合、送信端末２００Ａは、Ｕｕリンクで送信報告情報を送信し、周辺送信端末２００ＣはＵｕリンクで送信報告情報を受信する。

＜４．２．２．各装置の動作＞
以上、Mode4リソース割り当て環境における処理の概要を説明した。以下では、各ノードの動作を詳細に説明する。

（１）送信端末２００Ａの動作
−第１のパケット発生時の判断
送信端末２００Ａ（例えば、送信処理部２４１）は、ＵＲＬＬＣパケットである第１のパケットが発生した場合、以下の判断を行い得る。

送信端末２００Ａは、第１のパケットを送信可能な割り当てリソースがあるか否かを判定してもよい。割り当てリソースが有ると判定された場合、送信端末２００Ａは、割り当てリソースを使用して第１のパケットを送信する。他方、割り当てリソースが無いと判定された場合、送信端末２００Ａは、センシングレス送信を実施する。ただし、バックグラウンドでセンシングを実施していた場合、送信端末２００Ａは、かかるセンシングの結果を使用してもよい。また、センシングを実施しても遅延要求が満たされる場合、送信端末２００Ａは、センシングを実施してもよい。なお、ＵＲＬＬＣパケットを送信可能なリソースは、基地局１００からのＲＲＣシグナリングにより事前に割り当てられ得る。

−センシングレス送信
センシング送信とは、パケットの衝突防止のための所定のセンシングが実施されずに、パケットが送信される方法である。換言すると、センシングレス送信とは、パケットの衝突防止のための所定の基準を満たせない（即ち、パケットの衝突が発生し得る）送信方法である。

所定のセンシングは、３ＧＰＰ ＬＴＥ Ｖ２Ｘで規定されているような、所定時間（１秒など）のセンシングであってもよい。他にも、所定のセンシングは、ＬＢＴ（Listen Before Talk）であってもよい。ＬＢＴとは、より短期間のセンシングを指し、例えばＷｉ−Ｆｉで用いられているような、送信前の数ｍｓオーダーのセンシングである。センシングレス送信では、上述した所定のセンシングが実施されずに、パケットが送信される。ただし、所定のセンシング以外の（具体的には、より貧弱な）センシングが実施された上でパケットが送信されることも、センシングレス送信の一例である。所定のセンシング以外のセンシングとは、例えば極短い時間（例えば、数シンボル、略ゼロ）のセンシング等の、パケットの衝突防止のための所定の基準を満たせないセンシングである。

センシングレス送信用のリソースプールが、基地局１００からのＲＲＣシグナリングにより事前に割り当てられてもよい。カバレッジ外の場合、センシングレス送信用のリソースプールが、端末装置２００にPre-configurationされてもよい。センシングレス送信用のリソースプールは、通常の（即ち、センシングを伴う送信用の）リソースプールと同一であってもよいし、時間方向及び／又は周波数方向に制限されていてもよい。

センシングレス送信では、送信端末２００Ａは自ら送信リソースをランダムに選択してもよい。また、送信端末２００Ａは、所定の選択基準に従って送信リソースを選択してもよい。所定の選択基準は、例えば、基地局１００により設定され得る。

−送信報告情報の送信
送信端末２００Ａ（例えば、送信処理部２４１）は、サイドリンクで第１のパケットをセンシングレス送信した後、第１のパケットのセンシングレス送信に関する情報を含む送信報告情報を送信する。送信報告情報が送信されることで、送信報告情報の受信側での第１のパケットと第２のパケットとの衝突の発生有無の確認が可能となり、衝突が発生していた場合に第２パケットの再送が実現される。とりわけ、送信端末２００Ａは、パケットの衝突防止のための所定の手続き（即ち、所定のセンシング）が実施されずに第１のパケットを送信する場合に、送信報告情報を送信する。パケットの衝突が発生し得る場合に限定して送信報告情報が送信されるので、シグナリングオーバーヘッドを抑制することができる。

送信端末２００Ａは、送信報告情報をＵｕリンク及び／又はサイドリンクで送信する。即ち、送信端末２００Ａは、送信報告情報を基地局１００経由で、又は直接的に他の端末装置２００に送信する。

送信端末２００Ａは、第１のパケットの送信に使用されるリソースと時間方向に所定の関係にあるリソースを使用して、送信報告情報を送信してもよい。

−送信報告情報の内容
送信報告情報の内容は、Mode3リソース割り当ての場合と同様である。即ち、送信報告情報は、送信端末２００Ａが第１のパケットのセンシングレス送信に使用したリソースの時間及び周波数を示す情報を含む。また、送信報告情報は、以下に示す情報の少なくともいずれかをさらに含み得る。
−第１のパケットの送信に使用したリソースプールを示す情報
−第１のパケットの送信に使用した周波数帯域を示す情報
−第１のパケットの送信繰り返し回数を示す情報
−第１のパケットの送信に使用した送信電力を示す情報
−第１のパケットの優先度を示す情報
−第１のパケットを送信したときの送信端末２００Ａの位置情報
−第１のパケットの送信時のＭＣＳ情報
−第１のパケットの送信時のトランスミッションモード情報
−第１のパケットの送信時のＱＣＬ（Quasi−Colocation）情報

−処理の流れ
以下、図３２を参照しながら、送信端末２００Ａによる処理の流れの一例を説明する。図３２は、本実施形態に係る送信端末２００Ａにより実行される第１のパケットの送信処理及び事後処理の流れの一例を示すフローチャートである。

図３２に示すように、まず、送信端末２００Ａにおいて、送信すべき第１のパケット（例えば、ＵＲＬＬＣパケット）が発生する（ステップＳ３３２）。すると、送信端末２００Ａは、第１のパケットを送信可能な割り当てリソースがあり、且つそのリソースを使用した場合に遅延要求が満たされるかを判定する（ステップＳ３３４）。ステップＳ３３４がＹＥＳの場合、送信端末２００Ａは、当該割り当てリソースを使用して第１のパケットを送信する（ステップＳ３３６）。ステップＳ３３４がＮＯの場合、送信端末２００Ａは、センシングレス送信の実施を決定し（ステップＳ３３８）、第１のパケットをセンシングレス送信する（ステップＳ３４０）。そして、送信端末２００Ａは、第１のパケットのセンシングレス送信に関する情報を含む送信報告情報を送信する（ステップＳ３４２）。

（２）周辺送信端末２００Ｃの動作
周辺送信端末２００Ｃ（例えば、送信処理部２４１）は、基地局１００による制御に基づいて、サイドリンクで第２のパケットを送信する。詳しくは、周辺送信端末２００Ｃは、基地局１００により割り当てられたリソースを使用して、第２のパケットを送信する。

ただし、周辺送信端末２００Ｃは、送信端末２００Ａによるセンシングレス送信に関する情報を含む送信報告情報を受信する場合がある。その場合、周辺送信端末２００Ｃは、サイドリンクで第２のパケットを送信した後、送信報告情報に基づいて第２のパケットの再送を制御する。

詳しくは、まず、周辺送信端末２００Ｃは、送信報告情報に基づいて、第１のパケットと第２のパケットとの衝突の発生有無を判定する。具体的には、周辺送信端末２００Ｃは、送信報告情報が示す第１のパケットの送信に使用されたリソースと所定の関係にあるリソースを、第２のパケットの送信に使用したか否かを確認する。ここでの所定の関係にあるリソースとは、例えば、第１のパケットの送信に使用されたリソースと、同一のリソース、又は少なくとも一部が重複するリソースである。周辺送信端末２００Ｃは、第１のパケットの送信に使用されたリソースと所定の関係にあるリソースを第２のパケットの送信に使用していた場合に衝突が発生したと判定し、そうでない場合に衝突は発生していないと判定する。そして、周辺送信端末２００Ｃは、第１のパケットと第２のパケットとが衝突したと判定された場合に、リカバリ処理を実施する。これにより、パケットの衝突が発生した場合に限定してリカバリ処理を実施することが可能となる。

周辺送信端末２００Ｃは、送信報告情報に基づいて第１のパケットと第２のパケットとが衝突したと判定された場合に、リカバリ処理として、第２のパケットを再送する。例えば、周辺送信端末２００Ｃは、所定のセンシングを行って空きを確認したリソースを使用して、第２のパケットを再送する。当該所定のセンシングは、周辺送信端末２００Ｃにより代理で実施されてもよい。その場合、送信報告情報は、空きが確認された再送用のリソースの時間及び周波数を示す情報を含む。再送のための送信パラメータは、基地局１００により事前に設定されていてもよいし、送信端末２００Ａにより指示されてもよい。再送のための送信パラメータは、例えば、送信電力、ＭＣＳ、及び送信繰り返し回数等を含み得る。

周辺送信端末２００Ｃは、第１のパケットと第２のパケットとが衝突したと判定された場合、第２のパケットを再送した場合に第２のパケットの遅延要求が満たされるか否かにさらに基づいて、再送を制御してもよい。例えば、周辺送信端末２００Ｃは、第２のパケットを再送しても第２のパケットの遅延要求が満たされる場合に再送し、満たされない場合に再送しない。これにより、パケットの衝突が発生し、且つ再送しても遅延要求が満たされる場合に限定して再送が実施されるので、リソース効率の低下を抑制することができる。

−処理の流れ
以下、図３３を参照しながら、周辺送信端末２００Ｃによる処理の流れの一例を説明する。図３３は、本実施形態に係る周辺送信端末２００Ｃにより実行されるリカバリ処理の流れの一例を示すフローチャートである。

図３３に示すように、まず、周辺送信端末２００Ｃは、第１のパケットをグラントフリー送信した送信端末２００Ａから送信報告情報を受信する（ステップＳ３５２）。次に、周辺送信端末２００Ｃは、送信報告情報が示す第１のパケットの送信に使用されたリソースと所定の関係にあるリソースを、第２のパケットの送信に使用したか否かを確認することで、衝突の発生有無を確認する（ステップＳ３５４）。衝突が発生したと判定された場合（ステップＳ３５６／ＹＥＳ）、周辺送信端末２００Ｃは、第２のパケットを再送した場合に第２のパケットの遅延要求が満たされるか否かを判定する（ステップＳ３５８）。第２のパケットを再送しても第２のパケットの遅延要求が満たされると判定された場合（ステップＳ３５８／ＹＥＳ）、周辺送信端末２００Ｃは、リカバリ処理として、第２のパケットの再送処理を実施する（ステップＳ３６０）。他方、衝突が発生していないと判定された場合（ステップＳ３５６／ＮＯ）、又は第２のパケットを再送すると第２のパケットの遅延要求が満たされないと判定された場合（ステップＳ３５８／ＮＯ）、周辺送信端末２００Ｃは、リカバリ処理を実施しない。

（３）補足
送信報告情報は、Mode3リソース割り当ての場合と同様に、黙示的に通知されてもよい。

＜＜５．応用例＞＞
本開示に係る技術は、様々な製品へ応用可能である。

例えば、基地局１００は、マクロｅＮＢ又はスモールｅＮＢなどのいずれかの種類のｅＮＢ（evolved Node B）として実現されてもよい。スモールｅＮＢは、ピコｅＮＢ、マイクロｅＮＢ又はホーム（フェムト）ｅＮＢなどの、マクロセルよりも小さいセルをカバーするｅＮＢであってよい。その代わりに、基地局１００は、ＮｏｄｅＢ又はＢＴＳ（Base Transceiver Station）などの他の種類の基地局として実現されてもよい。基地局１００は、無線通信を制御する本体（基地局装置ともいう）と、本体とは別の場所に配置される１つ以上のＲＲＨ（Remote Radio Head）とを含んでもよい。また、後述する様々な種類の端末が一時的に又は半永続的に基地局機能を実行することにより、基地局１００として動作してもよい。

また、例えば、端末装置２００は、スマートフォン、タブレットＰＣ（Personal Computer）、ノートＰＣ、携帯型ゲーム端末、携帯型／ドングル型のモバイルルータ若しくはデジタルカメラなどのモバイル端末、又はカーナビゲーション装置などの車載端末として実現されてもよい。また、端末装置２００は、Ｍ２Ｍ（Machine To Machine）通信を行う端末（ＭＴＣ（Machine Type Communication）端末ともいう）として実現されてもよい。さらに、端末装置２００は、これら端末に搭載される無線通信モジュール（例えば、１つのダイで構成される集積回路モジュール）であってもよい。

＜５．１．基地局に関する応用例＞
（第１の応用例）
図３４は、本開示に係る技術が適用され得るｅＮＢの概略的な構成の第１の例を示すブロック図である。ｅＮＢ８００は、１つ以上のアンテナ８１０、及び基地局装置８２０を有する。各アンテナ８１０及び基地局装置８２０は、ＲＦケーブルを介して互いに接続され得る。

アンテナ８１０の各々は、単一の又は複数のアンテナ素子（例えば、ＭＩＭＯアンテナを構成する複数のアンテナ素子）を有し、基地局装置８２０による無線信号の送受信のために使用される。ｅＮＢ８００は、図３４に示したように複数のアンテナ８１０を有し、複数のアンテナ８１０は、例えばｅＮＢ８００が使用する複数の周波数帯域にそれぞれ対応してもよい。なお、図３４にはｅＮＢ８００が複数のアンテナ８１０を有する例を示したが、ｅＮＢ８００は単一のアンテナ８１０を有してもよい。

基地局装置８２０は、コントローラ８２１、メモリ８２２、ネットワークインタフェース８２３及び無線通信インタフェース８２５を備える。

コントローラ８２１は、例えばＣＰＵ又はＤＳＰであってよく、基地局装置８２０の上位レイヤの様々な機能を動作させる。例えば、コントローラ８２１は、無線通信インタフェース８２５により処理された信号内のデータからデータパケットを生成し、生成したパケットをネットワークインタフェース８２３を介して転送する。コントローラ８２１は、複数のベースバンドプロセッサからのデータをバンドリングすることによりバンドルドパケットを生成し、生成したバンドルドパケットを転送してもよい。また、コントローラ８２１は、無線リソース管理（Radio Resource Control）、無線ベアラ制御（Radio Bearer Control）、移動性管理（Mobility Management）、流入制御（Admission Control）又はスケジューリング（Scheduling）などの制御を実行する論理的な機能を有してもよい。また、当該制御は、周辺のｅＮＢ又はコアネットワークノードと連携して実行されてもよい。メモリ８２２は、ＲＡＭ及びＲＯＭを含み、コントローラ８２１により実行されるプログラム、及び様々な制御データ（例えば、端末リスト、送信電力データ及びスケジューリングデータなど）を記憶する。

ネットワークインタフェース８２３は、基地局装置８２０をコアネットワーク８２４に接続するための通信インタフェースである。コントローラ８２１は、ネットワークインタフェース８２３を介して、コアネットワークノード又は他のｅＮＢと通信してもよい。その場合に、ｅＮＢ８００と、コアネットワークノード又は他のｅＮＢとは、論理的なインタフェース（例えば、Ｓ１インタフェース又はＸ２インタフェース）により互いに接続されてもよい。ネットワークインタフェース８２３は、有線通信インタフェースであってもよく、又は無線バックホールのための無線通信インタフェースであってもよい。ネットワークインタフェース８２３が無線通信インタフェースである場合、ネットワークインタフェース８２３は、無線通信インタフェース８２５により使用される周波数帯域よりもより高い周波数帯域を無線通信に使用してもよい。

無線通信インタフェース８２５は、ＬＴＥ（Long Term Evolution）又はＬＴＥ−Ａｄｖａｎｃｅｄなどのいずれかのセルラー通信方式をサポートし、アンテナ８１０を介して、ｅＮＢ８００のセル内に位置する端末に無線接続を提供する。無線通信インタフェース８２５は、典型的には、ベースバンド（ＢＢ）プロセッサ８２６及びＲＦ回路８２７などを含み得る。ＢＢプロセッサ８２６は、例えば、符号化／復号、変調／復調及び多重化／逆多重化などを行なってよく、各レイヤ（例えば、Ｌ１、ＭＡＣ（Medium Access Control）、ＲＬＣ（Radio Link Control）及びＰＤＣＰ（Packet Data Convergence Protocol））の様々な信号処理を実行する。ＢＢプロセッサ８２６は、コントローラ８２１の代わりに、上述した論理的な機能の一部又は全部を有してもよい。ＢＢプロセッサ８２６は、通信制御プログラムを記憶するメモリ、当該プログラムを実行するプロセッサ及び関連する回路を含むモジュールであってもよく、ＢＢプロセッサ８２６の機能は、上記プログラムのアップデートにより変更可能であってもよい。また、上記モジュールは、基地局装置８２０のスロットに挿入されるカード若しくはブレードであってもよく、又は上記カード若しくは上記ブレードに搭載されるチップであってもよい。一方、ＲＦ回路８２７は、ミキサ、フィルタ及びアンプなどを含んでもよく、アンテナ８１０を介して無線信号を送受信する。

無線通信インタフェース８２５は、図３４に示したように複数のＢＢプロセッサ８２６を含み、複数のＢＢプロセッサ８２６は、例えばｅＮＢ８００が使用する複数の周波数帯域にそれぞれ対応してもよい。また、無線通信インタフェース８２５は、図３４に示したように複数のＲＦ回路８２７を含み、複数のＲＦ回路８２７は、例えば複数のアンテナ素子にそれぞれ対応してもよい。なお、図３４には無線通信インタフェース８２５が複数のＢＢプロセッサ８２６及び複数のＲＦ回路８２７を含む例を示したが、無線通信インタフェース８２５は単一のＢＢプロセッサ８２６又は単一のＲＦ回路８２７を含んでもよい。

図３４に示したｅＮＢ８００において、図１９を参照して説明した制御部１５０に含まれる１つ以上の構成要素（通信制御部１５１）は、無線通信インタフェース８２５において実装されてもよい。あるいは、これらの構成要素の少なくとも一部は、コントローラ８２１において実装されてもよい。一例として、ｅＮＢ８００は、無線通信インタフェース８２５の一部（例えば、ＢＢプロセッサ８２６）若しくは全部、及び／又はコントローラ８２１を含むモジュールを搭載し、当該モジュールにおいて上記１つ以上の構成要素が実装されてもよい。この場合に、上記モジュールは、プロセッサを上記１つ以上の構成要素として機能させるためのプログラム（換言すると、プロセッサに上記１つ以上の構成要素の動作を実行させるためのプログラム）を記憶し、当該プログラムを実行してもよい。別の例として、プロセッサを上記１つ以上の構成要素として機能させるためのプログラムがｅＮＢ８００にインストールされ、無線通信インタフェース８２５（例えば、ＢＢプロセッサ８２６）及び／又はコントローラ８２１が当該プログラムを実行してもよい。以上のように、上記１つ以上の構成要素を備える装置としてｅＮＢ８００、基地局装置８２０又は上記モジュールが提供されてもよく、プロセッサを上記１つ以上の構成要素として機能させるためのプログラムが提供されてもよい。また、上記プログラムを記録した読み取り可能な記録媒体が提供されてもよい。

また、図３４に示したｅＮＢ８００において、図１９を参照して説明した無線通信部１２０は、無線通信インタフェース８２５（例えば、ＲＦ回路８２７）において実装されてもよい。また、アンテナ部１１０は、アンテナ８１０において実装されてもよい。また、ネットワーク通信部１３０は、コントローラ８２１及び／又はネットワークインタフェース８２３において実装されてもよい。また、記憶部１４０は、メモリ８２２において実装されてもよい。

（第２の応用例）
図３５は、本開示に係る技術が適用され得るｅＮＢの概略的な構成の第２の例を示すブロック図である。ｅＮＢ８３０は、１つ以上のアンテナ８４０、基地局装置８５０、及びＲＲＨ８６０を有する。各アンテナ８４０及びＲＲＨ８６０は、ＲＦケーブルを介して互いに接続され得る。また、基地局装置８５０及びＲＲＨ８６０は、光ファイバケーブルなどの高速回線で互いに接続され得る。

アンテナ８４０の各々は、単一の又は複数のアンテナ素子（例えば、ＭＩＭＯアンテナを構成する複数のアンテナ素子）を有し、ＲＲＨ８６０による無線信号の送受信のために使用される。ｅＮＢ８３０は、図３５に示したように複数のアンテナ８４０を有し、複数のアンテナ８４０は、例えばｅＮＢ８３０が使用する複数の周波数帯域にそれぞれ対応してもよい。なお、図３５にはｅＮＢ８３０が複数のアンテナ８４０を有する例を示したが、ｅＮＢ８３０は単一のアンテナ８４０を有してもよい。

基地局装置８５０は、コントローラ８５１、メモリ８５２、ネットワークインタフェース８５３、無線通信インタフェース８５５及び接続インタフェース８５７を備える。コントローラ８５１、メモリ８５２及びネットワークインタフェース８５３は、図３４を参照して説明したコントローラ８２１、メモリ８２２及びネットワークインタフェース８２３と同様のものである。

無線通信インタフェース８５５は、ＬＴＥ又はＬＴＥ−Ａｄｖａｎｃｅｄなどのいずれかのセルラー通信方式をサポートし、ＲＲＨ８６０及びアンテナ８４０を介して、ＲＲＨ８６０に対応するセクタ内に位置する端末に無線接続を提供する。無線通信インタフェース８５５は、典型的には、ＢＢプロセッサ８５６などを含み得る。ＢＢプロセッサ８５６は、接続インタフェース８５７を介してＲＲＨ８６０のＲＦ回路８６４と接続されることを除き、図３４を参照して説明したＢＢプロセッサ８２６と同様のものである。無線通信インタフェース８５５は、図３５に示したように複数のＢＢプロセッサ８５６を含み、複数のＢＢプロセッサ８５６は、例えばｅＮＢ８３０が使用する複数の周波数帯域にそれぞれ対応してもよい。なお、図３５には無線通信インタフェース８５５が複数のＢＢプロセッサ８５６を含む例を示したが、無線通信インタフェース８５５は単一のＢＢプロセッサ８５６を含んでもよい。

接続インタフェース８５７は、基地局装置８５０（無線通信インタフェース８５５）をＲＲＨ８６０と接続するためのインタフェースである。接続インタフェース８５７は、基地局装置８５０（無線通信インタフェース８５５）とＲＲＨ８６０とを接続する上記高速回線での通信のための通信モジュールであってもよい。

また、ＲＲＨ８６０は、接続インタフェース８６１及び無線通信インタフェース８６３を備える。

接続インタフェース８６１は、ＲＲＨ８６０（無線通信インタフェース８６３）を基地局装置８５０と接続するためのインタフェースである。接続インタフェース８６１は、上記高速回線での通信のための通信モジュールであってもよい。

無線通信インタフェース８６３は、アンテナ８４０を介して無線信号を送受信する。無線通信インタフェース８６３は、典型的には、ＲＦ回路８６４などを含み得る。ＲＦ回路８６４は、ミキサ、フィルタ及びアンプなどを含んでもよく、アンテナ８４０を介して無線信号を送受信する。無線通信インタフェース８６３は、図３５に示したように複数のＲＦ回路８６４を含み、複数のＲＦ回路８６４は、例えば複数のアンテナ素子にそれぞれ対応してもよい。なお、図３５には無線通信インタフェース８６３が複数のＲＦ回路８６４を含む例を示したが、無線通信インタフェース８６３は単一のＲＦ回路８６４を含んでもよい。

図３５に示したｅＮＢ８３０において、図１９を参照して説明した制御部１５０に含まれる１つ以上の構成要素（通信制御部１５１）は、無線通信インタフェース８５５及び／又は無線通信インタフェース８６３において実装されてもよい。あるいは、これらの構成要素の少なくとも一部は、コントローラ８５１において実装されてもよい。一例として、ｅＮＢ８３０は、無線通信インタフェース８５５の一部（例えば、ＢＢプロセッサ８５６）若しくは全部、及び／又はコントローラ８５１を含むモジュールを搭載し、当該モジュールにおいて上記１つ以上の構成要素が実装されてもよい。この場合に、上記モジュールは、プロセッサを上記１つ以上の構成要素として機能させるためのプログラム（換言すると、プロセッサに上記１つ以上の構成要素の動作を実行させるためのプログラム）を記憶し、当該プログラムを実行してもよい。別の例として、プロセッサを上記１つ以上の構成要素として機能させるためのプログラムがｅＮＢ８３０にインストールされ、無線通信インタフェース８５５（例えば、ＢＢプロセッサ８５６）及び／又はコントローラ８５１が当該プログラムを実行してもよい。以上のように、上記１つ以上の構成要素を備える装置としてｅＮＢ８３０、基地局装置８５０又は上記モジュールが提供されてもよく、プロセッサを上記１つ以上の構成要素として機能させるためのプログラムが提供されてもよい。また、上記プログラムを記録した読み取り可能な記録媒体が提供されてもよい。

また、図３５に示したｅＮＢ８３０において、例えば、図Ｙを参照して説明した無線通信部１２０は、無線通信インタフェース８６３（例えば、ＲＦ回路８６４）において実装されてもよい。また、アンテナ部１１０は、アンテナ８４０において実装されてもよい。また、ネットワーク通信部１３０は、コントローラ８５１及び／又はネットワークインタフェース８５３において実装されてもよい。また、記憶部１４０は、メモリ８５２において実装されてもよい。

＜５．２．端末装置に関する応用例＞
（第１の応用例）
図３６は、本開示に係る技術が適用され得るスマートフォン９００の概略的な構成の一例を示すブロック図である。スマートフォン９００は、プロセッサ９０１、メモリ９０２、ストレージ９０３、外部接続インタフェース９０４、カメラ９０６、センサ９０７、マイクロフォン９０８、入力デバイス９０９、表示デバイス９１０、スピーカ９１１、無線通信インタフェース９１２、１つ以上のアンテナスイッチ９１５、１つ以上のアンテナ９１６、バス９１７、バッテリー９１８及び補助コントローラ９１９を備える。

プロセッサ９０１は、例えばＣＰＵ又はＳｏＣ（System on Chip）であってよく、スマートフォン９００のアプリケーションレイヤ及びその他のレイヤの機能を制御する。メモリ９０２は、ＲＡＭ及びＲＯＭを含み、プロセッサ９０１により実行されるプログラム及びデータを記憶する。ストレージ９０３は、半導体メモリ又はハードディスクなどの記憶媒体を含み得る。外部接続インタフェース９０４は、メモリーカード又はＵＳＢ（Universal Serial Bus）デバイスなどの外付けデバイスをスマートフォン９００へ接続するためのインタフェースである。

カメラ９０６は、例えば、ＣＣＤ（Charge Coupled Device）又はＣＭＯＳ（Complementary Metal Oxide Semiconductor）などの撮像素子を有し、撮像画像を生成する。センサ９０７は、例えば、測位センサ、ジャイロセンサ、地磁気センサ及び加速度センサなどのセンサ群を含み得る。マイクロフォン９０８は、スマートフォン９００へ入力される音声を音声信号へ変換する。入力デバイス９０９は、例えば、表示デバイス９１０の画面上へのタッチを検出するタッチセンサ、キーパッド、キーボード、ボタン又はスイッチなどを含み、ユーザからの操作又は情報入力を受け付ける。表示デバイス９１０は、液晶ディスプレイ（ＬＣＤ）又は有機発光ダイオード（ＯＬＥＤ）ディスプレイなどの画面を有し、スマートフォン９００の出力画像を表示する。スピーカ９１１は、スマートフォン９００から出力される音声信号を音声に変換する。

無線通信インタフェース９１２は、ＬＴＥ又はＬＴＥ−Ａｄｖａｎｃｅｄなどのいずれかのセルラー通信方式をサポートし、無線通信を実行する。無線通信インタフェース９１２は、典型的には、ＢＢプロセッサ９１３及びＲＦ回路９１４などを含み得る。ＢＢプロセッサ９１３は、例えば、符号化／復号、変調／復調及び多重化／逆多重化などを行なってよく、無線通信のための様々な信号処理を実行する。一方、ＲＦ回路９１４は、ミキサ、フィルタ及びアンプなどを含んでもよく、アンテナ９１６を介して無線信号を送受信する。無線通信インタフェース９１２は、ＢＢプロセッサ９１３及びＲＦ回路９１４を集積したワンチップのモジュールであってもよい。無線通信インタフェース９１２は、図３６に示したように複数のＢＢプロセッサ９１３及び複数のＲＦ回路９１４を含んでもよい。なお、図３６には無線通信インタフェース９１２が複数のＢＢプロセッサ９１３及び複数のＲＦ回路９１４を含む例を示したが、無線通信インタフェース９１２は単一のＢＢプロセッサ９１３又は単一のＲＦ回路９１４を含んでもよい。

さらに、無線通信インタフェース９１２は、セルラー通信方式に加えて、近距離無線通信方式、近接無線通信方式又は無線ＬＡＮ（Local Area Network）方式などの他の種類の無線通信方式をサポートしてもよく、その場合に、無線通信方式ごとのＢＢプロセッサ９１３及びＲＦ回路９１４を含んでもよい。

アンテナスイッチ９１５の各々は、無線通信インタフェース９１２に含まれる複数の回路（例えば、異なる無線通信方式のための回路）の間でアンテナ９１６の接続先を切り替える。

アンテナ９１６の各々は、単一の又は複数のアンテナ素子（例えば、ＭＩＭＯアンテナを構成する複数のアンテナ素子）を有し、無線通信インタフェース９１２による無線信号の送受信のために使用される。スマートフォン９００は、図３６に示したように複数のアンテナ９１６を有してもよい。なお、図３６にはスマートフォン９００が複数のアンテナ９１６を有する例を示したが、スマートフォン９００は単一のアンテナ９１６を有してもよい。

さらに、スマートフォン９００は、無線通信方式ごとにアンテナ９１６を備えてもよい。その場合に、アンテナスイッチ９１５は、スマートフォン９００の構成から省略されてもよい。

バス９１７は、プロセッサ９０１、メモリ９０２、ストレージ９０３、外部接続インタフェース９０４、カメラ９０６、センサ９０７、マイクロフォン９０８、入力デバイス９０９、表示デバイス９１０、スピーカ９１１、無線通信インタフェース９１２及び補助コントローラ９１９を互いに接続する。バッテリー９１８は、図中に破線で部分的に示した給電ラインを介して、図３６に示したスマートフォン９００の各ブロックへ電力を供給する。補助コントローラ９１９は、例えば、スリープモードにおいて、スマートフォン９００の必要最低限の機能を動作させる。

図３６に示したスマートフォン９００において、図２０を参照して説明した制御部２４０に含まれる１つ以上の構成要素（送信処理部２４１及び／又は受信処理部２４３）は、無線通信インタフェース９１２において実装されてもよい。あるいは、これらの構成要素の少なくとも一部は、プロセッサ９０１又は補助コントローラ９１９において実装されてもよい。一例として、スマートフォン９００は、無線通信インタフェース９１２の一部（例えば、ＢＢプロセッサ９１３）若しくは全部、プロセッサ９０１、及び／又は補助コントローラ９１９を含むモジュールを搭載し、当該モジュールにおいて上記１つ以上の構成要素が実装されてもよい。この場合に、上記モジュールは、プロセッサを上記１つ以上の構成要素として機能させるためのプログラム（換言すると、プロセッサに上記１つ以上の構成要素の動作を実行させるためのプログラム）を記憶し、当該プログラムを実行してもよい。別の例として、プロセッサを上記１つ以上の構成要素として機能させるためのプログラムがスマートフォン９００にインストールされ、無線通信インタフェース９１２（例えば、ＢＢプロセッサ９１３）、プロセッサ９０１、及び／又は補助コントローラ９１９が当該プログラムを実行してもよい。以上のように、上記１つ以上の構成要素を備える装置としてスマートフォン９００又は上記モジュールが提供されてもよく、プロセッサを上記１つ以上の構成要素として機能させるためのプログラムが提供されてもよい。また、上記プログラムを記録した読み取り可能な記録媒体が提供されてもよい。

また、図３６に示したスマートフォン９００において、例えば、図２０を参照して説明した無線通信部２２０は、無線通信インタフェース９１２（例えば、ＲＦ回路９１４）において実装されてもよい。また、アンテナ部２１０は、アンテナ９１６において実装されてもよい。また、記憶部２３０は、メモリ９０２において実装されてもよい。

（第２の応用例）
図３７は、本開示に係る技術が適用され得るカーナビゲーション装置９２０の概略的な構成の一例を示すブロック図である。カーナビゲーション装置９２０は、プロセッサ９２１、メモリ９２２、ＧＰＳ（Global Positioning System）モジュール９２４、センサ９２５、データインタフェース９２６、コンテンツプレーヤ９２７、記憶媒体インタフェース９２８、入力デバイス９２９、表示デバイス９３０、スピーカ９３１、無線通信インタフェース９３３、１つ以上のアンテナスイッチ９３６、１つ以上のアンテナ９３７及びバッテリー９３８を備える。

プロセッサ９２１は、例えばＣＰＵ又はＳｏＣであってよく、カーナビゲーション装置９２０のナビゲーション機能及びその他の機能を制御する。メモリ９２２は、ＲＡＭ及びＲＯＭを含み、プロセッサ９２１により実行されるプログラム及びデータを記憶する。

ＧＰＳモジュール９２４は、ＧＰＳ衛星から受信されるＧＰＳ信号を用いて、カーナビゲーション装置９２０の位置（例えば、緯度、経度及び高度）を測定する。センサ９２５は、例えば、ジャイロセンサ、地磁気センサ及び気圧センサなどのセンサ群を含み得る。データインタフェース９２６は、例えば、図示しない端子を介して車載ネットワーク９４１に接続され、車速データなどの車両側で生成されるデータを取得する。

コンテンツプレーヤ９２７は、記憶媒体インタフェース９２８に挿入される記憶媒体（例えば、ＣＤ又はＤＶＤ）に記憶されているコンテンツを再生する。入力デバイス９２９は、例えば、表示デバイス９３０の画面上へのタッチを検出するタッチセンサ、ボタン又はスイッチなどを含み、ユーザからの操作又は情報入力を受け付ける。表示デバイス９３０は、ＬＣＤ又はＯＬＥＤディスプレイなどの画面を有し、ナビゲーション機能又は再生されるコンテンツの画像を表示する。スピーカ９３１は、ナビゲーション機能又は再生されるコンテンツの音声を出力する。

無線通信インタフェース９３３は、ＬＴＥ又はＬＴＥ−Ａｄｖａｎｃｅｄなどのいずれかのセルラー通信方式をサポートし、無線通信を実行する。無線通信インタフェース９３３は、典型的には、ＢＢプロセッサ９３４及びＲＦ回路９３５などを含み得る。ＢＢプロセッサ９３４は、例えば、符号化／復号、変調／復調及び多重化／逆多重化などを行なってよく、無線通信のための様々な信号処理を実行する。一方、ＲＦ回路９３５は、ミキサ、フィルタ及びアンプなどを含んでもよく、アンテナ９３７を介して無線信号を送受信する。無線通信インタフェース９３３は、ＢＢプロセッサ９３４及びＲＦ回路９３５を集積したワンチップのモジュールであってもよい。無線通信インタフェース９３３は、図３７に示したように複数のＢＢプロセッサ９３４及び複数のＲＦ回路９３５を含んでもよい。なお、図３７には無線通信インタフェース９３３が複数のＢＢプロセッサ９３４及び複数のＲＦ回路９３５を含む例を示したが、無線通信インタフェース９３３は単一のＢＢプロセッサ９３４又は単一のＲＦ回路９３５を含んでもよい。

さらに、無線通信インタフェース９３３は、セルラー通信方式に加えて、近距離無線通信方式、近接無線通信方式又は無線ＬＡＮ方式などの他の種類の無線通信方式をサポートしてもよく、その場合に、無線通信方式ごとのＢＢプロセッサ９３４及びＲＦ回路９３５を含んでもよい。

アンテナスイッチ９３６の各々は、無線通信インタフェース９３３に含まれる複数の回路（例えば、異なる無線通信方式のための回路）の間でアンテナ９３７の接続先を切り替える。

アンテナ９３７の各々は、単一の又は複数のアンテナ素子（例えば、ＭＩＭＯアンテナを構成する複数のアンテナ素子）を有し、無線通信インタフェース９３３による無線信号の送受信のために使用される。カーナビゲーション装置９２０は、図３７に示したように複数のアンテナ９３７を有してもよい。なお、図３７にはカーナビゲーション装置９２０が複数のアンテナ９３７を有する例を示したが、カーナビゲーション装置９２０は単一のアンテナ９３７を有してもよい。

さらに、カーナビゲーション装置９２０は、無線通信方式ごとにアンテナ９３７を備えてもよい。その場合に、アンテナスイッチ９３６は、カーナビゲーション装置９２０の構成から省略されてもよい。

バッテリー９３８は、図中に破線で部分的に示した給電ラインを介して、図３７に示したカーナビゲーション装置９２０の各ブロックへ電力を供給する。また、バッテリー９３８は、車両側から給電される電力を蓄積する。

図３７に示したカーナビゲーション装置９２０において、図２０を参照して説明した制御部２４０に含まれる１つ以上の構成要素（送信処理部２４１及び／又は受信処理部２４３）は、無線通信インタフェース９３３において実装されてもよい。あるいは、これらの構成要素の少なくとも一部は、プロセッサ９２１において実装されてもよい。一例として、カーナビゲーション装置９２０は、無線通信インタフェース９３３の一部（例えば、ＢＢプロセッサ９３４）若しくは全部及び／又はプロセッサ９２１を含むモジュールを搭載し、当該モジュールにおいて上記１つ以上の構成要素が実装されてもよい。この場合に、上記モジュールは、プロセッサを上記１つ以上の構成要素として機能させるためのプログラム（換言すると、プロセッサに上記１つ以上の構成要素の動作を実行させるためのプログラム）を記憶し、当該プログラムを実行してもよい。別の例として、プロセッサを上記１つ以上の構成要素として機能させるためのプログラムがカーナビゲーション装置９２０にインストールされ、無線通信インタフェース９３３（例えば、ＢＢプロセッサ９３４）及び／又はプロセッサ９２１が当該プログラムを実行してもよい。以上のように、上記１つ以上の構成要素を備える装置としてカーナビゲーション装置９２０又は上記モジュールが提供されてもよく、プロセッサを上記１つ以上の構成要素として機能させるためのプログラムが提供されてもよい。また、上記プログラムを記録した読み取り可能な記録媒体が提供されてもよい。

また、図３７に示したカーナビゲーション装置９２０において、例えば、図２０を参照して説明した無線通信部２２０は、無線通信インタフェース９３３（例えば、ＲＦ回路９３５）において実装されてもよい。また、アンテナ部２１０は、アンテナ９３７において実装されてもよい。また、記憶部２３０は、メモリ９２２において実装されてもよい。

また、本開示に係る技術は、上述したカーナビゲーション装置９２０の１つ以上のブロックと、車載ネットワーク９４１と、車両側モジュール９４２とを含む車載システム（又は車両）９４０として実現されてもよい。車両側モジュール９４２は、車速、エンジン回転数又は故障情報などの車両側データを生成し、生成したデータを車載ネットワーク９４１へ出力する。

＜＜６．まとめ＞＞
以上、図１〜図３７を参照しながら、本開示の一実施形態について詳細に説明した。上記説明したように、本実施形態に係る送信端末２００Ａは、サイドリンクで第１のパケットを送信した後、第１のパケットの送信に使用したリソースの時間及び周波数を示す情報を含む送信報告情報を送信する。例えば、送信端末２００Ａは、サイドリンクで第１のパケットをグラントフリー送信又はセンシングレス送信した場合、送信報告情報を基地局１００又は周辺の他の端末装置２００に送信する。これにより、送信報告情報の受信側は、第１のパケット以外にサイドリンクで送信された第２のパケットの中に第１のパケットと衝突したパケットが有るか否かを確認し、衝突した第２のパケットのリカバリ処理をトリガすることができる。

Mode3リソース割り当て環境においては、基地局１００は、送信端末２００Ａによるサイドリンクでの第１のパケットの送信に使用されたリソースの時間及び周波数を示す情報を含む送信報告情報に基づいて、サイドリンクで第２のパケットを送信した周辺送信端末２００Ｃによる第２のパケットの再送を制御する。例えば、基地局１００は、送信報告情報に基づいて第１のパケットと第２のパケットとの衝突の発生有無を判定し、衝突が発生したと判定した場合に第２のパケットの再送を周辺送信端末２００Ｃに指示する。これにより、第１のパケットと衝突した第２のパケットのリカバリが実現される。

Mode4リソース割り当て環境においては、周辺送信端末２００Ｃは、サイドリンクで第２のパケットを送信した後、送信端末２００Ａによるサイドリンクでの第１のパケットの送信に用いられたリソースの時間及び周波数を示す情報を含む送信報告情報に基づいて、第２のパケットの再送を制御する。例えば、周辺送信端末２００Ｃは、送信報告情報に基づいて第１のパケットと第２のパケットとの衝突の発生有無を判定し、衝突が発生したと判定した場合に第２のパケットの再送を行う。これにより、第１のパケットと衝突した第２のパケットのリカバリを実現される。

以上、添付図面を参照しながら本開示の好適な実施形態について詳細に説明したが、本開示の技術的範囲はかかる例に限定されない。本開示の技術分野における通常の知識を有する者であれば、請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本開示の技術的範囲に属するものと了解される。

例えば、上記実施形態では、ＬＴＥと同様にサイドリンクがＮＲで定義されることを前提に説明したが、本技術はかかる例に限定されない。例えば、ＮＲでサイドリンクが定義されず、単にダウンリンク／アップリンクが定義される場合であっても、本技術は同様に適用可能である。その場合、ダウンリンク／アップリンクのグラントフリー送信において、本技術を適用して送信報告情報が報告され、リカバリ処理が行われる。例えば、端末装置は、アップリンクでグラントフリー送信を行った後、グラントフリー送信に関する送信報告情報をアップリンクで送信する。送信報告情報は、上記実施形態において説明したサイドリンクのケースにおける送信報告情報と同様の情報を含み得る。他方、基地局は、送信報告情報を受信した後、リカバリ指示を送信する等のリカバリ処理を実施する。リカバリ指示は、上記実施形態において説明したサイドリンクのケースにおけるリカバリ指示と同様の情報を含み得る。

また、上記実施形態では、パケットがグラントフリー送信される場合に衝突検出及びリカバリ処理が行われるものとして説明したが、本技術はかかる例に限定されない。パケットがグラントベース送信された場合であっても、衝突検出及びリカバリ処理が行われてもよい。

また、本技術の適用先は、多様に考えられる。例えば、本技術の適用先は、Ｖ２Ｘ通信に限定されず、＜１．２．サイドリンク通信の拡張例＞において説明したサイドリンク通信の多様な拡張例に本技術が適用されてもよい。本技術は、ＦＤＭ型のリソースプールが割り当てられる場合においても、ＴＤＭ型のリソースプールが割り当てられる場合においても、同様に適用可能である。本技術は、複数のキャリアを用いてサイドリンク通信を行うマルチキャリア通信にも適用可能である。基地局１００は、衛星又はドローン等の非地上局として構成されてもよい。また、基地局１００は、ＲＳＵ、又は複数のＵＥの代表として機能する代表ＵＥ（マスタＵＥ）として構成されてもよい。本技術は、ＩＡＢ（Integrated Access and Backhaul link）のようなリレー通信におけるサイドリンク通信に対して適用されてもよい。本技術の適用先はＵＲＬＬＣパケットに限定されず、ｅＭＢＢ又はｍＭＴＣ等の任意のユースケースのパケットの送信に対して本技術が適用されてもよい。

また、本明細書においてフローチャート及びシーケンス図を用いて説明した処理は、必ずしも図示された順序で実行されなくてもよい。いくつかの処理ステップは、並列的に実行されてもよい。また、追加的な処理ステップが採用されてもよく、一部の処理ステップが省略されてもよい。

また、本明細書に記載された効果は、あくまで説明的または例示的なものであって限定的ではない。つまり、本開示に係る技術は、上記の効果とともに、または上記の効果に代えて、本明細書の記載から当業者には明らかな他の効果を奏しうる。

なお、以下のような構成も本開示の技術的範囲に属する。
（１）
サイドリンクで第１のパケットを送信した後、前記第１のパケットの送信に使用したリソースの時間及び周波数を示す情報を含む送信報告情報を送信する制御部、
を備える端末装置。
（２）
前記制御部は、パケットの衝突防止のための所定の手続きが実施されずに前記第１のパケットが送信された場合に、前記送信報告情報を送信する、前記（１）に記載の端末装置。
（３）
前記所定の手続きは、前記第１のパケットの送信のためのリソースの割り当てを受けることを含む、前記（２）に記載の端末装置。
（４）
前記所定の手続きは、パケットの衝突防止のための所定のセンシングを実施することを含む、前記（２）又は（３）に記載の端末装置。
（５）
前記制御部は、前記第１のパケットの送信に使用されるリソースと時間方向に所定の関係にあるリソースを使用して、前記送信報告情報を送信する、前記（１）〜（４）のいずれか一項に記載の端末装置。
（６）
前記制御部は、前記送信報告情報をＵｕリンク及び／又はサイドリンクで送信する、前記（１）〜（５）のいずれか一項に記載の端末装置。
（７）
前記送信報告情報は、前記第１のパケットの送信に使用したリソースプールを示す情報、前記第１のパケットの送信に使用した周波数帯域を示す情報、前記第１のパケットの送信繰り返し回数を示す情報、前記第１のパケットの送信に使用した送信電力を示す情報、前記第１のパケットの優先度を示す情報、前記第１のパケットを送信したときの前記端末装置の位置情報、前記第１のパケットの送信時のＭＣＳ（Modulation and Coding Scheme）情報、前記第１のパケットの送信時のトランスミッションモード情報、及び前記第１のパケットの送信時のＱＣＬ（Quasi−Colocation）情報の、少なくともいずれかをさらに含む、前記（１）〜（６）のいずれか一項に記載の端末装置。
（８）
前記第１のパケットは、ＵＲＬＬＣ（Ultra reliable and low latency communications）のユースケースにおいて送信されるパケットである、前記（１）〜（７）のいずれか一項に記載の端末装置。
（９）
サイドリンクで第２のパケットを送信した後、他の端末装置によるサイドリンクでの第１のパケットの送信に用いられたリソースの時間及び周波数を示す情報を含む送信報告情報に基づいて、前記第２のパケットの再送を制御する制御部、
を備える端末装置。
（１０）
前記制御部は、前記送信報告情報に基づいて前記第１のパケットと前記第２のパケットとが衝突したと判定された場合に、前記第２のパケットを再送する、前記（９）に記載の端末装置。
（１１）
前記制御部は、前記第２のパケットを再送した場合に前記第２のパケットの遅延要求が満たされるか否かに基づいて、前記第２のパケットの再送を制御する、前記（１０）に記載の端末装置。
（１２）
第１の端末装置によるサイドリンクでの第１のパケットの送信に使用されたリソースの時間及び周波数を示す情報を含む送信報告情報に基づいて、サイドリンクで第２のパケットを送信した第２の端末装置による前記第２のパケットの再送を制御する通信制御部、
を備える基地局。
（１３）
前記通信制御部は、前記送信報告情報に基づいて前記第１のパケットと前記第２のパケットとが衝突したと判定された場合に、前記第２のパケットの再送を指示する情報を前記第２の端末装置に送信する、前記（１２）に記載の基地局。
（１４）
前記第２のパケットの再送を指示する情報は、前記第２のパケットの再送のために割り当てられたリソースを示す情報を含む、前記（１３）に記載の基地局。
（１５）
サイドリンクで第１のパケットを送信した後、前記第１のパケットの送信に使用したリソースの時間及び周波数を示す情報を含む送信報告情報を送信すること、
を含む、プロセッサにより実行される方法。
（１６）
サイドリンクで第２のパケットを送信した後、他の端末装置によるサイドリンクでの第１のパケットの送信に用いられたリソースの時間及び周波数を示す情報を含む送信報告情報に基づいて、前記第２のパケットの再送を制御すること、
を含む、プロセッサにより実行される方法。
（１７）
第１の端末装置によるサイドリンクでの第１のパケットの送信に使用されたリソースの時間及び周波数を示す情報を含む送信報告情報に基づいて、サイドリンクで第２のパケットを送信した第２の端末装置による前記第２のパケットの再送を制御すること、
を含む、プロセッサにより実行される方法。
（１８）
コンピュータを、
サイドリンクで第１のパケットを送信した後、前記第１のパケットの送信に使用したリソースの時間及び周波数を示す情報を含む送信報告情報を送信する制御部、
として機能させるためのプログラムが記録された記録媒体。
（１９）
コンピュータを、
サイドリンクで第２のパケットを送信した後、他の端末装置によるサイドリンクでの第１のパケットの送信に用いられたリソースの時間及び周波数を示す情報を含む送信報告情報に基づいて、前記第２のパケットの再送を制御する制御部、
として機能させるためのプログラムが記録された記録媒体。
（２０）
コンピュータを、
第１の端末装置によるサイドリンクでの第１のパケットの送信に使用されたリソースの時間及び周波数を示す情報を含む送信報告情報に基づいて、サイドリンクで第２のパケットを送信した第２の端末装置による前記第２のパケットの再送を制御する通信制御部、
として機能させるためのプログラムが記録された記録媒体。

１ システム
１１ セル
２０ コアネットワーク
３０ ＰＤＮ
１００ 基地局
１１０ アンテナ部
１２０ 無線通信部
１３０ ネットワーク通信部
１４０ 記憶部
１５０ 制御部
１５１ 通信制御部
２００ 端末装置
２００Ａ 送信端末
２００Ｂ 受信端末
２００Ｃ 周辺送信端末
２００Ｄ 周辺受信端末
２１０ アンテナ部
２２０ 無線通信部
２３０ 記憶部
２４０ 制御部
２４１ 送信処理部
２４３ 受信処理部

Claims (20)

1. サイドリンクで第１のパケットを送信した後、前記第１のパケットの送信に使用したリソースの時間及び周波数を示す情報を含む送信報告情報を送信する制御部、
   を備える端末装置。
2. 前記制御部は、パケットの衝突防止のための所定の手続きが実施されずに前記第１のパケットが送信された場合に、前記送信報告情報を送信する、請求項１に記載の端末装置。
3. 前記所定の手続きは、前記第１のパケットの送信のためのリソースの割り当てを受けることを含む、請求項２に記載の端末装置。
4. 前記所定の手続きは、パケットの衝突防止のための所定のセンシングを実施することを含む、請求項２に記載の端末装置。
5. 前記制御部は、前記第１のパケットの送信に使用されるリソースと時間方向に所定の関係にあるリソースを使用して、前記送信報告情報を送信する、請求項１に記載の端末装置。
6. 前記制御部は、前記送信報告情報をＵｕリンク及び／又はサイドリンクで送信する、請求項１に記載の端末装置。
7. 前記送信報告情報は、前記第１のパケットの送信に使用したリソースプールを示す情報、前記第１のパケットの送信に使用した周波数帯域を示す情報、前記第１のパケットの送信繰り返し回数を示す情報、前記第１のパケットの送信に使用した送信電力を示す情報、前記第１のパケットの優先度を示す情報、前記第１のパケットを送信したときの前記端末装置の位置情報、前記第１のパケットの送信時のＭＣＳ（Modulation and Coding Scheme）情報、前記第１のパケットの送信時のトランスミッションモード情報、及び前記第１のパケットの送信時のＱＣＬ（Quasi−Colocation）情報の、少なくともいずれかをさらに含む、請求項１に記載の端末装置。
8. 前記第１のパケットは、ＵＲＬＬＣ（Ultra reliable and low latency communications）のユースケースにおいて送信されるパケットである、請求項１に記載の端末装置。
9. サイドリンクで第２のパケットを送信した後、他の端末装置によるサイドリンクでの第１のパケットの送信に用いられたリソースの時間及び周波数を示す情報を含む送信報告情報に基づいて、前記第２のパケットの再送を制御する制御部、
   を備える端末装置。
10. 前記制御部は、前記送信報告情報に基づいて前記第１のパケットと前記第２のパケットとが衝突したと判定された場合に、前記第２のパケットを再送する、請求項９に記載の端末装置。
11. 前記制御部は、前記第２のパケットを再送した場合に前記第２のパケットの遅延要求が満たされるか否かに基づいて、前記第２のパケットの再送を制御する、請求項１０に記載の端末装置。
12. 第１の端末装置によるサイドリンクでの第１のパケットの送信に使用されたリソースの時間及び周波数を示す情報を含む送信報告情報に基づいて、サイドリンクで第２のパケットを送信した第２の端末装置による前記第２のパケットの再送を制御する通信制御部、
    を備える基地局。
13. 前記通信制御部は、前記送信報告情報に基づいて前記第１のパケットと前記第２のパケットとが衝突したと判定された場合に、前記第２のパケットの再送を指示する情報を前記第２の端末装置に送信する、請求項１２に記載の基地局。
14. 前記第２のパケットの再送を指示する情報は、前記第２のパケットの再送のために割り当てられたリソースを示す情報を含む、請求項１３に記載の基地局。
15. サイドリンクで第１のパケットを送信した後、前記第１のパケットの送信に使用したリソースの時間及び周波数を示す情報を含む送信報告情報を送信すること、
    を含む、プロセッサにより実行される方法。
16. サイドリンクで第２のパケットを送信した後、他の端末装置によるサイドリンクでの第１のパケットの送信に用いられたリソースの時間及び周波数を示す情報を含む送信報告情報に基づいて、前記第２のパケットの再送を制御すること、
    を含む、プロセッサにより実行される方法。
17. 第１の端末装置によるサイドリンクでの第１のパケットの送信に使用されたリソースの時間及び周波数を示す情報を含む送信報告情報に基づいて、サイドリンクで第２のパケットを送信した第２の端末装置による前記第２のパケットの再送を制御すること、
    を含む、プロセッサにより実行される方法。
18. コンピュータを、
    サイドリンクで第１のパケットを送信した後、前記第１のパケットの送信に使用したリソースの時間及び周波数を示す情報を含む送信報告情報を送信する制御部、
    として機能させるためのプログラムが記録された記録媒体。
19. コンピュータを、
    サイドリンクで第２のパケットを送信した後、他の端末装置によるサイドリンクでの第１のパケットの送信に用いられたリソースの時間及び周波数を示す情報を含む送信報告情報に基づいて、前記第２のパケットの再送を制御する制御部、
    として機能させるためのプログラムが記録された記録媒体。
20. コンピュータを、
    第１の端末装置によるサイドリンクでの第１のパケットの送信に使用されたリソースの時間及び周波数を示す情報を含む送信報告情報に基づいて、サイドリンクで第２のパケットを送信した第２の端末装置による前記第２のパケットの再送を制御する通信制御部、
    として機能させるためのプログラムが記録された記録媒体。

Images