JP7775322B2

JP7775322B2 - 端末及び通信方法

Info

Publication number: JP7775322B2
Application number: JP2023553780A
Authority: JP
Inventors: 翔平吉岡; 尚哉芝池; 聡永田
Original assignee: NTT Docomo Inc
Current assignee: NTT Docomo Inc
Priority date: 2021-10-11
Filing date: 2021-10-11
Publication date: 2025-11-25
Anticipated expiration: 2041-10-11
Also published as: JPWO2023062704A1; EP4418779A4; WO2023062704A1; CN118140547A; EP4418779A1

Description

本発明は、無線通信システムにおける端末及び通信方法に関する。

ＬＴＥ（Long Term Evolution）及びＬＴＥの後継システム（例えば、ＬＴＥ－Ａ（LTE Advanced）、ＮＲ（New Radio）（５Ｇともいう。））では、端末同士が基地局を介さないで直接通信を行うＤ２Ｄ（Device to Device）技術が検討されている（例えば非特許文献１）。

Ｄ２Ｄは、端末と基地局との間のトラフィックを軽減し、災害時等に基地局が通信不能になった場合でも端末間の通信を可能とする。なお、３ＧＰＰ（3rd Generation Partnership Project）では、Ｄ２Ｄを「サイドリンク（ｓｉｄｅｌｉｎｋ）」と称しているが、本明細書では、より一般的な用語であるＤ２Ｄを使用する。ただし、後述する実施の形態の説明では必要に応じてサイドリンクも使用する。

Ｄ２Ｄ通信は、通信可能な他の端末を発見するためのＤ２Ｄディスカバリ（D2D discovery、Ｄ２Ｄ発見ともいう。）と、端末間で直接通信するためのＤ２Ｄコミュニケーション（D2D direct communication、Ｄ２Ｄ通信、端末間直接通信等ともいう。）と、に大別される。以下では、Ｄ２Ｄコミュニケーション、Ｄ２Ｄディスカバリ等を特に区別しないときは、単にＤ２Ｄと呼ぶ。また、Ｄ２Ｄで送受信される信号を、Ｄ２Ｄ信号と呼ぶ。ＮＲにおけるＶ２Ｘ（Vehicle to Everything）に係るサービスの様々なユースケースが検討されている（例えば非特許文献２）。

３ＧＰＰＴＳ３８．２１１Ｖ１６．６．０（２０２１－０６）３ＧＰＰＴＲ２２．８８６Ｖ１５．１．０（２０１７－０３）

ＮＲサイドリンクの強化として、遅延性能及び信頼性の向上が検討されている。例えば、端末が自律的にリソースを選択するリソース割り当てモード２（Resource allocation mode 2）において、端末はセンシングウィンドウ内のリソースに対してセンシングを実行し、当該センシングの結果に基づいて、使用可能なリソース候補をリソース選択ウィンドウから選択するとき、端末間協調（inter-UE coordination）を行い、自律的に選択するリソースを決定するための情報を取得することが検討されている。

ここで、端末が、端末間協調を実行するとき、例えばリソースの衝突に係る通知を他の端末から受信した場合に、どのようにリソース選択又は再選択を実行するかが不明であった。

本発明は上記の点に鑑みてなされたものであり、端末間直接通信において、自律的リソース選択に係る動作を他の端末からの情報に基づいて実行することを目的とする。

開示の技術によれば、他の端末から、推奨されるリソースセットを受信する受信部と、前記推奨されるリソースセットに基づくリソースと物理レイヤにより示されるリソースとに共通するリソースから送信リソースを選択する制御部と、を備え、前記制御部は、前記推奨されるリソースセットに基づくリソースと前記物理レイヤにより示されるリソースとに共通するリソースの数が所定の数未満である場合、前記推奨されるリソースセットに基づくリソース以外のリソースから前記送信リソースを選択する端末が提供される。

開示の技術によれば、端末間直接通信において、自律的リソース選択に係る動作を他の端末からの情報に基づいて実行することができる。

Ｖ２Ｘを説明するための図である。Ｖ２Ｘの送信モードの例（１）を説明するための図である。Ｖ２Ｘの送信モードの例（２）を説明するための図である。Ｖ２Ｘの送信モードの例（３）を説明するための図である。Ｖ２Ｘの送信モードの例（４）を説明するための図である。Ｖ２Ｘの送信モードの例（５）を説明するための図である。Ｖ２Ｘの通信タイプの例（１）を説明するための図である。Ｖ２Ｘの通信タイプの例（２）を説明するための図である。Ｖ２Ｘの通信タイプの例（３）を説明するための図である。Ｖ２Ｘの動作例（１）を示すシーケンス図である。Ｖ２Ｘの動作例（２）を示すシーケンス図である。Ｖ２Ｘの動作例（３）を示すシーケンス図である。Ｖ２Ｘの動作例（４）を示すシーケンス図である。センシング動作の例を示す図である。プリエンプション動作の例を説明するためのフローチャートである。プリエンプション動作の例を示す図である。部分センシング動作の例を示す図である。周期的部分センシングの例を説明するための図である。連続部分センシングの例を説明するための図である。通信状況の例（１）を説明するための図である。通信状況の例（２）を説明するための図である。通信状況の例（３）を説明するための図である。通信状況の例（４）を説明するための図である。通信状況の例（５）を説明するための図である。端末間協調の例を説明するためのシーケンス図である。本発明の実施の形態におけるリソース選択の例を説明するためのフローチャートである。本発明の実施の形態における基地局１０の機能構成の一例を示す図である。本発明の実施の形態における端末２０の機能構成の一例を示す図である。本発明の実施の形態における基地局１０又は端末２０のハードウェア構成の一例を示す図である。本発明の実施の形態における車両２００１の構成の一例を示す図である。

以下、図面を参照して本発明の実施の形態を説明する。なお、以下で説明する実施の形態は一例であり、本発明が適用される実施の形態は、以下の実施の形態に限られない。

本発明の実施の形態の無線通信システムの動作にあたっては、適宜、既存技術が使用される。ただし、当該既存技術は、例えば既存のＬＴＥであるが、既存のＬＴＥに限られない。また、本明細書で使用する用語「ＬＴＥ」は、特に断らない限り、ＬＴＥ－Ａｄｖａｎｃｅｄ、及び、ＬＴＥ－Ａｄｖａｎｃｅｄ以降の方式（例：ＮＲ）、又は無線ＬＡＮ（Local Area Network）を含む広い意味を有するものとする。

また、本発明の実施の形態において、複信（Duplex）方式は、ＴＤＤ（Time Division Duplex）方式でもよいし、ＦＤＤ（Frequency Division Duplex）方式でもよいし、又はそれ以外（例えば、Flexible Duplex等）の方式でもよい。

また、本発明の実施の形態において、無線パラメータ等が「設定される（Configure）」とは、所定の値が予め設定（Pre-configure）されることであってもよいし、基地局１０又は端末２０から通知される無線パラメータが設定されることであってもよい。また、本発明の実施の形態において、「以上」は「を超える」と置換可能であってもよいし、「以下」は「未満」と置換可能であってもよい。

図１は、Ｖ２Ｘを説明するための図である。３ＧＰＰでは、Ｄ２Ｄ機能を拡張することでＶ２Ｘ（Vehicle to Everything）あるいはｅＶ２Ｘ（enhanced V2X）を実現することが検討され、仕様化が進められている。図１に示されるように、Ｖ２Ｘとは、ＩＴＳ（Intelligent Transport Systems）の一部であり、車両間で行われる通信形態を意味するＶ２Ｖ（Vehicle to Vehicle）、車両と道路脇に設置される路側機（ＲＳＵ：Road-Side Unit）との間で行われる通信形態を意味するＶ２Ｉ（Vehicle to Infrastructure）、車両とＩＴＳサーバとの間で行われる通信形態を意味するＶ２Ｎ（Vehicle to Network）、及び、車両と歩行者が所持するモバイル端末との間で行われる通信形態を意味するＶ２Ｐ（Vehicle to Pedestrian）の総称である。

また、３ＧＰＰにおいて、ＬＴＥ又はＮＲのセルラ通信及び端末間通信を用いたＶ２Ｘが検討されている。セルラ通信を用いたＶ２ＸをセルラＶ２Ｘともいう。ＮＲのＶ２Ｘにおいては、大容量化、低遅延、高信頼性、ＱｏＳ（Quality of Service）制御を実現する検討が進められている。

ＬＴＥ又はＮＲのＶ２Ｘについて、今後３ＧＰＰ仕様に限られない検討も進められることが想定される。例えば、インターオペラビリティの確保、上位レイヤの実装によるコストの低減、複数ＲＡＴ（Radio Access Technology）の併用又は切替方法、各国におけるレギュレーション対応、ＬＴＥ又はＮＲのＶ２Ｘプラットフォームのデータ取得、配信、データベース管理及び利用方法が検討されることが想定される。

本発明の実施の形態において、通信装置が車両に搭載される形態を主に想定するが、本発明の実施の形態は、当該形態に限定されない。例えば、通信装置は人が保持する端末であってもよいし、通信装置がドローンあるいは航空機に搭載される装置であってもよいし、通信装置が基地局、ＲＳＵ、中継局（リレーノード）、スケジューリング能力を有する端末等であってもよい。

なお、ＳＬ（Sidelink）は、ＵＬ（Uplink）又はＤＬ（Downlink）と以下１）－４）のいずれか又は組み合わせに基づいて区別されてもよい。また、ＳＬは、他の名称であってもよい。
１）時間領域のリソース配置
２）周波数領域のリソース配置
３）参照する同期信号（ＳＬＳＳ（Sidelink Synchronization Signal）を含む）
４）送信電力制御のためのパスロス測定に用いる参照信号

また、ＳＬ又はＵＬのＯＦＤＭ（Orthogonal Frequency Division Multiplexing）に関して、ＣＰ－ＯＦＤＭ（Cyclic-Prefix OFDM）、ＤＦＴ－Ｓ－ＯＦＤＭ（Discrete Fourier Transform - Spread - OFDM）、ＴｒａｎｓｆｏｒｍｐｒｅｃｏｄｉｎｇされていないＯＦＤＭ又はＴｒａｎｓｆｏｒｍｐｒｅｃｏｄｉｎｇされているＯＦＤＭのいずれが適用されてもよい。

ＬＴＥのＳＬにおいて、端末２０へのＳＬのリソース割り当てに関してＭｏｄｅ３とＭｏｄｅ４が規定されている。Ｍｏｄｅ３では、基地局１０から端末２０に送信されるＤＣＩ（Downlink Control Information）によりダイナミックに送信リソースが割り当てられる。また、Ｍｏｄｅ３ではＳＰＳ（Semi Persistent Scheduling）も可能である。Ｍｏｄｅ４では、端末２０はリソースプールから自律的に送信リソースを選択する。

なお、本発明の実施の形態におけるスロットは、シンボル、ミニスロット、サブフレーム、無線フレーム、ＴＴＩ（Transmission Time Interval）と読み替えられてもよい。また、本発明の実施の形態におけるセルは、セルグループ、キャリアコンポーネント、ＢＷＰ、リソースプール、リソース、ＲＡＴ（Radio Access Technology）、システム（無線ＬＡＮ含む）等に読み替えられてもよい。

なお、本発明の実施の形態において、端末２０は、Ｖ２Ｘ端末に限定されず、Ｄ２Ｄ通信を行うあらゆる種別の端末であってもよい。例えば、端末２０は、スマートフォンのようなユーザが所持する端末でもよいし、スマートメータ等のＩｏＴ（Internet of Things）機器であってもよい。

図２は、Ｖ２Ｘの送信モードの例（１）を説明するための図である。図２に示されるサイドリンク通信の送信モードでは、ステップ１において、基地局１０がサイドリンクのスケジューリングを端末２０Ａに送信する。続いて、端末２０Ａは、受信したスケジューリングに基づいて、ＰＳＣＣＨ（Physical Sidelink Control Channel）及びＰＳＳＣＨ（Physical Sidelink Shared Channel）を端末２０Ｂに送信する（ステップ２）。図２に示されるサイドリンク通信の送信モードを、ＬＴＥにおけるサイドリンク送信モード３と呼んでもよい。ＬＴＥにおけるサイドリンク送信モード３では、Ｕｕベースのサイドリンクスケジューリングが行われる。Ｕｕとは、ＵＴＲＡＮ（Universal Terrestrial Radio Access Network）とＵＥ（User Equipment）間の無線インタフェースである。なお、図２に示されるサイドリンク通信の送信モードを、ＮＲにおけるサイドリンク送信モード１とよんでもよい。

図３は、Ｖ２Ｘの送信モードの例（２）を説明するための図である。図３に示されるサイドリンク通信の送信モードでは、ステップ１において、端末２０Ａは、自律的に選択したリソースを使用して、ＰＳＣＣＨ及びＰＳＳＣＨを端末２０Ｂに送信する。図３に示されるサイドリンク通信の送信モードを、ＬＴＥにおけるサイドリンク送信モード４と呼んでもよい。ＬＴＥにおけるサイドリンク送信モード４では、ＵＥ自身がリソース選択を実行する。

図４は、Ｖ２Ｘの送信モードの例（３）を説明するための図である。図４に示されるサイドリンク通信の送信モードでは、ステップ１において、端末２０Ａは、自律的に選択したリソースを使用して、ＰＳＣＣＨ及びＰＳＳＣＨを端末２０Ｂに送信する。同様に、端末２０Ｂは、自律的に選択したリソースを使用して、ＰＳＣＣＨ及びＰＳＳＣＨを端末２０Ａに送信する（ステップ１）。図４に示されるサイドリンク通信の送信モードを、ＮＲにおけるサイドリンク送信モード２ａと呼んでもよい。ＮＲにおけるサイドリンク送信モード２では、端末２０自身がリソース選択を実行する。

図５は、Ｖ２Ｘの送信モードの例（４）を説明するための図である。図５に示されるサイドリンク通信の送信モードでは、ステップ０において、サイドリンクのリソースパターンが、基地局１０からＲＲＣ（Radio Resource Control）設定を介して端末２０Ａに送信され、あるいは予め設定される。続いて、端末２０Ａは、当該リソースパターンに基づいて、ＰＳＳＣＨを端末２０Ｂに送信する（ステップ１）。図５に示されるサイドリンク通信の送信モードを、ＮＲにおけるサイドリンク送信モード２ｃと呼んでもよい。

図６は、Ｖ２Ｘの送信モードの例（５）を説明するための図である。図６に示されるサイドリンク通信の送信モードでは、ステップ１において、端末２０ＡがサイドリンクのスケジューリングをＰＳＣＣＨを介して端末２０Ｂに送信する。続いて、端末２０Ｂは、受信したスケジューリングに基づいて、ＰＳＳＣＨを端末２０Ａに送信する（ステップ２）。図６に示されるサイドリンク通信の送信モードを、ＮＲにおけるサイドリンク送信モード２ｄと呼んでもよい。

図７は、Ｖ２Ｘの通信タイプの例（１）を説明するための図である。図７に示されるサイドリンクの通信タイプは、ユニキャストである。端末２０Ａは、ＰＳＣＣＨ及びＰＳＳＣＨを端末２０に送信する。図７に示される例では、端末２０Ａは、端末２０Ｂにユニキャストを行い、また、端末２０Ｃにユニキャストを行う。

図８は、Ｖ２Ｘの通信タイプの例（２）を説明するための図である。図８に示されるサイドリンクの通信タイプは、グループキャストである。端末２０Ａは、ＰＳＣＣＨ及びＰＳＳＣＨを１又は複数の端末２０が属するグループに送信する。図８に示される例では、グループは端末２０Ｂ及び端末２０Ｃを含み、端末２０Ａは、グループにグループキャストを行う。

図９は、Ｖ２Ｘの通信タイプの例（３）を説明するための図である。図９に示されるサイドリンクの通信タイプは、ブロードキャストである。端末２０Ａは、ＰＳＣＣＨ及びＰＳＳＣＨを１又は複数の端末２０に送信する。図９に示される例では、端末２０Ａは、端末２０Ｂ、端末２０Ｃ及び端末２０Ｄにブロードキャストを行う。なお、図７～図９に示した端末２０ＡをヘッダＵＥ（header-UE）と称してもよい。

また、ＮＲ－Ｖ２Ｘにおいて、サイドリンクのユニキャスト及びグループキャストにＨＡＲＱ（Hybrid automatic repeat request）がサポートされることが想定される。さらに、ＮＲ－Ｖ２Ｘにおいて、ＨＡＲＱ応答を含むＳＦＣＩ（Sidelink Feedback Control Information）が定義される。さらに、ＰＳＦＣＨ（Physical Sidelink Feedback Channel）を介して、ＳＦＣＩが送信されることが検討されている。

なお、以下の説明では、サイドリンクでのＨＡＲＱ－ＡＣＫの送信において、ＰＳＦＣＨを使用することとしているが、これは一例である。例えば、ＰＳＣＣＨを使用してサイドリンクでのＨＡＲＱ－ＡＣＫの送信を行うこととしてもよいし、ＰＳＳＣＨを使用してサイドリンクでのＨＡＲＱ－ＡＣＫの送信を行うこととしてもよいし、その他のチャネルを使用してサイドリンクでのＨＡＲＱ－ＡＣＫの送信を行うこととしてもよい。

以下では、便宜上、ＨＡＲＱにおいて端末２０が報告する情報全般をＨＡＲＱ－ＡＣＫと呼ぶ。このＨＡＲＱ－ＡＣＫをＨＡＲＱ－ＡＣＫ情報と称してもよい。また、より具体的には、端末２０から基地局１０等に報告されるＨＡＲＱ－ＡＣＫの情報に適用されるコードブックをＨＡＲＱ－ＡＣＫコードブックと呼ぶ。ＨＡＲＱ－ＡＣＫコードブックは、ＨＡＲＱ－ＡＣＫ情報のビット列を規定する。なお、「ＨＡＲＱ－ＡＣＫ」により、ＡＣＫの他、ＮＡＣＫも送信される。

図１０は、Ｖ２Ｘの動作例（１）を示すシーケンス図である。図１０に示されるように、本発明の実施の形態に係る無線通信システムは、端末２０Ａ、及び端末２０Ｂを有してもよい。なお、実際には多数のユーザ装置が存在するが、図１０は例として端末２０Ａ、及び端末２０Ｂを示している。

以下、端末２０Ａ、２０Ｂ等を特に区別しない場合、単に「端末２０」あるいは「ユーザ装置」と記述する。図１０では、一例として端末２０Ａと端末２０Ｂがともにセルのカバレッジ内にある場合を示しているが、本発明の実施の形態における動作は、端末２０Ｂがカバレッジ外にある場合にも適用できる。

前述したように、本実施の形態において、端末２０は、例えば、自動車等の車両に搭載された装置であり、ＬＴＥあるいはＮＲにおけるＵＥとしてのセルラ通信の機能、及び、サイドリンク機能を有している。端末２０が、一般的な携帯端末（スマートフォン等）であってもよい。また、端末２０が、ＲＳＵであってもよい。当該ＲＳＵは、ＵＥの機能を有するＵＥタイプＲＳＵであってもよいし、基地局装置の機能を有するｇＮＢタイプＲＳＵであってもよい。

なお、端末２０は１つの筐体の装置である必要はなく、例えば、各種センサが車両内に分散して配置される場合でも、当該各種センサを含めた装置が端末２０であってもよい。

また、端末２０のサイドリンクの送信データの処理内容は基本的には、ＬＴＥあるいはＮＲでのＵＬ送信の処理内容と同様である。例えば、端末２０は、送信データのコードワードをスクランブルし、変調してcomplex-valued symbolsを生成し、当該complex-valued symbols（送信信号）を１又は２レイヤにマッピングし、プリコーディングを行う。そして、precoded complex-valued symbolsをリソースエレメントにマッピングして、送信信号（例：complex-valued time-domain SC-FDMA signal）を生成し、各アンテナポートから送信する。

なお、基地局１０については、ＬＴＥあるいはＮＲにおける基地局としてのセルラ通信の機能、及び、本実施の形態における端末２０の通信を可能ならしめるための機能（例：リソースプール設定、リソース割り当て等）を有している。また、基地局１０は、ＲＳＵ（ｇＮＢタイプＲＳＵ）であってもよい。

また、本発明の実施の形態に係る無線通信システムにおいて、端末２０がＳＬあるいはＵＬに使用する信号波形は、ＯＦＤＭＡであってもよいし、ＳＣ－ＦＤＭＡであってもよいし、その他の信号波形であってもよい。

ステップＳ１０１において、端末２０Ａは、所定の期間を有するリソース選択ウィンドウから自律的にＰＳＣＣＨ及びＰＳＳＣＨに使用するリソースを選択する。リソース選択ウィンドウは、基地局１０から端末２０に設定されてもよい。ここで、リソース選択ウィンドウの所定の期間について、例えば処理時間又はパケット最大許容遅延時間のような端末の実装条件により期間が規定されてもよいし、仕様により予め期間が規定されてもよいし、所定の期間は時間領域上の区間と呼ばれてもよい。

ステップＳ１０２及びステップＳ１０３において、端末２０Ａは、ステップＳ１０１で自律的に選択したリソースを用いて、ＰＳＣＣＨ及び／又はＰＳＳＣＨによりＳＣＩ（Sidelink Control Information)を送信するとともに、ＰＳＳＣＨによりＳＬデータを送信する。例えば、端末２０Ａは、ＰＳＣＣＨを、ＰＳＳＣＨの時間リソースの少なくとも一部と同じ時間リソースで、ＰＳＳＣＨの周波数リソースと隣接する周波数リソースを使用して送信してもよい。

端末２０Ｂは、端末２０Ａから送信されたＳＣＩ（ＰＳＣＣＨ及び／又はＰＳＳＣＨ）とＳＬデータ（ＰＳＳＣＨ）を受信する。受信したＳＣＩには、端末２０Ｂが、当該データの受信に対するＨＡＲＱ－ＡＣＫを送信するためのＰＳＦＣＨのリソースの情報が含まれてもよい。端末２０Ａは自律的に選択したリソースの情報をＳＣＩに含めて送信してもよい。

ステップＳ１０４において、端末２０Ｂは、受信したＳＣＩから定まるＰＳＦＣＨのリソースを使用して、受信したデータに対するＨＡＲＱ－ＡＣＫを端末２０Ａに送信する。

ステップＳ１０５において、端末２０Ａは、ステップＳ１０４で受信したＨＡＲＱ－ＡＣＫが再送を要求することを示す場合すなわちＮＡＣＫ（否定的応答）である場合、端末２０ＢにＰＳＣＣＨ及びＰＳＳＣＨを再送する。端末２０Ａは、自律的に選択したリソースを使用してＰＳＣＣＨ及びＰＳＳＣＨを再送してもよい。

なお、ＨＡＲＱフィードバックを伴うＨＡＲＱ制御が実行されない場合、ステップＳ１０４及びステップＳ１０５は実行されなくてもよい。

図１１は、Ｖ２Ｘの動作例（２）を示すシーケンス図である。送信の成功率又は到達距離を向上させるためのＨＡＲＱ制御によらないブラインド再送が実行されてもよい。

ステップＳ２０１において、端末２０Ａは、所定の期間を有するリソース選択ウィンドウから自律的にＰＳＣＣＨ及びＰＳＳＣＨに使用するリソースを選択する。リソース選択ウィンドウは、基地局１０から端末２０に設定されてもよい。

ステップＳ２０２及びステップＳ２０３において、端末２０Ａは、ステップＳ２０１で自律的に選択したリソースを使用して、ＰＳＣＣＨ及び／又はＰＳＳＣＨによりＳＣＩを送信するとともに、ＰＳＳＣＨによりＳＬデータを送信する。例えば、端末２０Ａは、ＰＳＣＣＨを、ＰＳＳＣＨの時間リソースの少なくとも一部と同じ時間リソースで、ＰＳＳＣＨの周波数リソースと隣接する周波数リソースを使用して送信してもよい。

ステップＳ２０４において、端末２０Ａは、ステップＳ２０１で自律的に選択したリソースを使用して、ＰＳＣＣＨ及び／又はＰＳＳＣＨによるＳＣＩ及びＰＳＳＣＨによるＳＬデータを端末２０Ｂに再送する。ステップＳ２０４における再送は、複数回実行されてもよい。

なお、ブラインド再送が実行されない場合、ステップＳ２０４は実行されなくてもよい。

図１２は、Ｖ２Ｘの動作例（３）を示すシーケンス図である。基地局１０は、サイドリンクのスケジューリングを行ってもよい。すなわち、基地局１０は、端末２０が使用するサイドリンクのリソースを決定して、当該リソースを示す情報を端末２０に送信してもよい。さらに、ＨＡＲＱフィードバックを伴うＨＡＲＱ制御が適用される場合、基地局１０は、ＰＳＦＣＨのリソースを示す情報を端末２０に送信してもよい。

ステップＳ３０１において、基地局１０は端末２０Ａに対して、ＰＤＣＣＨによりＤＣＩ（Downlink Control Information）を送ることにより、ＳＬスケジューリングを行う。以降、便宜上、ＳＬスケジューリングのためのＤＣＩをＳＬスケジューリングＤＣＩと呼ぶ。

また、ステップＳ３０１において、基地局１０は端末２０Ａに対して、ＰＤＣＣＨにより、ＤＬスケジューリング（ＤＬ割り当てと呼んでもよい）のためのＤＣＩも送信することを想定している。以降、便宜上、ＤＬスケジューリングのためのＤＣＩをＤＬスケジューリングＤＣＩと呼ぶ。ＤＬスケジューリングＤＣＩを受信した端末２０Ａは、ＤＬスケジューリングＤＣＩで指定されるリソースを用いて、ＰＤＳＣＨによりＤＬデータを受信する。

ステップＳ３０２及びステップＳ３０３において、端末２０Ａは、ＳＬスケジューリングＤＣＩで指定されたリソースを用いて、ＰＳＣＣＨ及び／又はＰＳＳＣＨによりＳＣＩ（Sidelink Control Information)を送信するとともに、ＰＳＳＣＨによりＳＬデータを送信する。なお、ＳＬスケジューリングＤＣＩでは、ＰＳＳＣＨのリソースのみが指定されることとしてもよい。この場合、例えば、端末２０Ａは、ＰＳＣＣＨを、ＰＳＳＣＨの時間リソースの少なくとも一部と同じ時間リソースで、ＰＳＳＣＨの周波数リソースと隣接する周波数リソースを使用して送信することとしてもよい。

端末２０Ｂは、端末２０Ａから送信されたＳＣＩ（ＰＳＣＣＨ及び／又はＰＳＳＣＨ）とＳＬデータ（ＰＳＳＣＨ）を受信する。ＰＳＣＣＨ及び／又はＰＳＳＣＨにより受信したＳＣＩには、端末２０Ｂが、当該データの受信に対するＨＡＲＱ－ＡＣＫを送信するためのＰＳＦＣＨのリソースの情報が含まれる。

当該リソースの情報は、ステップＳ３０１において基地局１０から送信されるＤＬスケジューリングＤＣＩ又はＳＬスケジューリングＤＣＩに含まれていて、端末２０Ａが、ＤＬスケジューリングＤＣＩ又はＳＬスケジューリングＤＣＩから当該リソースの情報を取得してＳＣＩの中に含める。あるいは、基地局１０から送信されるＤＣＩには当該リソースの情報は含まれないこととし、端末２０Ａが自律的に当該リソースの情報をＳＣＩに含めて送信することとしてもよい。

ステップＳ３０４において、端末２０Ｂは、受信したＳＣＩから定まるＰＳＦＣＨのリソースを使用して、受信したデータに対するＨＡＲＱ－ＡＣＫを端末２０Ａに送信する。

ステップＳ３０５において、端末２０Ａは、例えば、ＤＬスケジューリングＤＣＩ（又はＳＬスケジューリングＤＣＩ）により指定されたタイミング（例えばスロット単位のタイミング）で、当該ＤＬスケジューリングＤＣＩ（又は当該ＳＬスケジューリングＤＣＩ）により指定されたＰＵＣＣＨ（Physical uplink control channel）リソースを用いてＨＡＲＱ－ＡＣＫを送信し、基地局１０が当該ＨＡＲＱ－ＡＣＫを受信する。当該ＨＡＲＱ－ＡＣＫのコードブックには、端末２０Ｂから受信したＨＡＲＱ－ＡＣＫ又は受信しなかったＰＳＦＣＨに基づいて生成されるＨＡＲＱ－ＡＣＫと、ＤＬデータに対するＨＡＲＱ－ＡＣＫとが含まれ得る。ただし、ＤＬデータの割り当てがない場合等には、ＤＬデータに対するＨＡＲＱ－ＡＣＫは含まれない。ＮＲＲｅｌ．１６では、当該ＨＡＲＱ－ＡＣＫのコードブックに、ＤＬデータに対するＨＡＲＱ－ＡＣＫは含まれない。

なお、ＨＡＲＱフィードバックを伴うＨＡＲＱ制御が実行されない場合、ステップＳ３０４及び／又はステップＳ３０５は実行されなくてもよい。

図１３は、Ｖ２Ｘの動作例（４）を示すシーケンス図である。上述のとおりＮＲのサイドリンクにおいて、ＨＡＲＱ応答はＰＳＦＣＨで送信されることがサポートされている。なお、ＰＳＦＣＨのフォーマットは、例えばＰＵＣＣＨ（Physical Uplink Control Channel）フォーマット０と同様のフォーマットが使用可能である。すなわち、ＰＳＦＣＨのフォーマットは、ＰＲＢ（Physical Resource Block）サイズは１であり、ＡＣＫ及びＮＡＣＫはシーケンス及び／又はサイクリックシフトの差異によって識別されるシーケンスベースのフォーマットであってもよい。ＰＳＦＣＨのフォーマットとしては、これに限られない。ＰＳＦＣＨのリソースは、スロットの末尾のシンボル又は末尾の複数シンボルに配置されてもよい。また、ＰＳＦＣＨリソースに、周期Ｎが設定されるか予め規定される。周期Ｎは、スロット単位で設定されるか予め規定されてもよい。

図１３において、縦軸が周波数領域、横軸が時間領域に対応する。ＰＳＣＣＨは、スロット先頭の１シンボルに配置されてもよいし、先頭からの複数シンボルに配置されてもよいし、先頭以外のシンボルから複数シンボルに配置されてもよい。ＰＳＦＣＨは、スロット末尾の１シンボルに配置されてもよいし、スロット末尾の複数シンボルに配置されてもよい。なお、上述の「スロットの先頭」「スロットの末尾」は、ＡＧＣ（Automatic Gain Control）用のシンボル及び送信／受信切替用のシンボルの考慮が省略されていてもよい。すなわち、例えば１スロットが１４シンボルで構成される場合、「スロットの先頭」「スロットの末尾」は、先頭及び末尾のシンボルを除いた１２シンボルにおいて、それぞれ先頭及び末尾のシンボルであることを意味してもよい。図１３に示される例では、３つのサブチャネルがリソースプールに設定されており、ＰＳＳＣＨが配置されるスロットの３スロット後にＰＳＦＣＨが２つ配置される。ＰＳＳＣＨからＰＳＦＣＨへの矢印は、ＰＳＳＣＨに関連付けられるＰＳＦＣＨの例を示す。

ＮＲ－Ｖ２ＸのグループキャストにおけるＨＡＲＱ応答がＡＣＫ又はＮＡＣＫを送信するグループキャストオプション２である場合、ＰＳＦＣＨの送受信に使用するリソースを決定する必要がある。図１３に示されるように、ステップＳ４０１において、送信側端末２０である端末２０Ａが、ＳＬ－ＳＣＨを介して、受信側端末２０である端末２０Ｂ、端末２０Ｃ及び端末２０Ｄにグループキャストを実行する。続くステップＳ４０２において、端末２０ＢはＰＳＦＣＨ＃Ｂを使用し、端末２０ＣはＰＳＦＣＨ＃Ｃを使用し、端末２０ＤはＰＳＦＣＨ＃Ｄを使用してＨＡＲＱ応答を端末２０Ａに送信する。ここで、図１３の例に示されるように、利用可能なＰＳＦＣＨのリソースの個数が、グループに属する受信側端末２０の数より少ない場合、ＰＳＦＣＨのリソースをどのように割り当てるか決定する必要がある。なお、送信側端末２０は、グループキャストにおける受信側端末２０の数を把握していてもよい。なお、グループキャストオプション１では、ＨＡＲＱ応答として、ＮＡＣＫのみ送信され、ＡＣＫは送信されない。

図１４は、ＮＲにおけるセンシング動作の例を示す図である。リソース割り当てモード２（Resource allocation mode 2）では、端末２０がリソースを選択して送信を行う。図１４に示されるように、端末２０は、リソースプール内のセンシングウィンドウでセンシングを実行する。センシングにより、端末２０は、他の端末２０から送信されるＳＣＩに含まれるリソース予約（resource reservation）フィールド又はリソース割り当て（resource assignment）フィールドを受信し、当該フィールドに基づいて、リソースプール内のリソース選択ウィンドウ（resource selection window）内の使用可能なリソース候補を識別する。続いて、端末２０は使用可能なリソース候補からランダムにリソースを選択する。

また、図１４に示されるように、リソースプールの設定は周期を有してもよい。例えば、当該周期は、１０２４０ミリ秒の期間であってもよい。図１４は、スロットｔ_０ ^ＳＬからスロットｔ_{Ｔｍａｘ－１} ^ＳＬまでがリソースプールとして設定される例である。各周期内のリソースプールは、例えばビットマップによって領域が設定されてもよい。

また、図１４に示されるように、端末２０における送信トリガはスロットｎで発生しており、当該送信の優先度はｐ_ＴＸであるとする。端末２０は、スロットｎ－Ｔ_０からスロットｎ－Ｔ_{ｐｒｏｃ，０}の直前のスロットまでのセンシングウィンドウにおいて、例えば他の端末２０が優先度ｐ_ＲＸの送信を行っていることを検出することができる。センシングウィンドウ内でＳＣＩが検出され、かつＲＳＲＰ（Reference Signal Received Power）が閾値を上回る場合、当該ＳＣＩに対応するリソース選択ウィンドウ内のリソースは除外される。また、センシングウィンドウ内でＳＣＩが検出され、かつＲＳＲＰが閾値未満である場合、当該ＳＣＩに対応するリソース選択ウィンドウ内のリソースは除外されない。当該閾値は、例えば、優先度ｐ_ＴＸ及び優先度ｐ_ＲＸに基づいて、センシングウィンドウ内のリソースごとに設定又は定義される閾値Ｔｈ_{ｐＴＸ，ｐＲＸ}であってもよい。

また、図１４に示されるスロットｔ_ｍ ^ＳＬのように、例えば送信のため、モニタリングしなかったセンシングウィンドウ内のリソースに対応するリソース予約情報の候補となるリソース選択ウィンドウ内のリソースは除外される。

スロットｎ＋Ｔ_１からスロットｎ＋Ｔ₂までのリソース選択ウィンドウは、図１４に示されるように、他ＵＥが占有するリソースが識別され、当該リソースが除外されたリソースが、使用可能なリソース候補となる。使用可能なリソース候補の集合をＳ_Ａとすると、Ｓ_Ａがリソース選択ウィンドウの２０％未満であった場合、センシングウィンドウのリソースごとに設定される閾値Ｔｈ_{ｐＴＸ，ｐＲＸ}を３ｄＢ上昇させて再度リソースの識別を実行してもよい。すなわち、閾値Ｔｈ_{ｐＴＸ，ｐＲＸ}を上昇させて再度リソースの識別を実行することで、ＲＳＲＰが閾値未満のため除外されないリソースを増加させて、リソース候補の集合Ｓ_Ａがリソース選択ウィンドウの２０％以上となるようにしてもよい。Ｓ_Ａがリソース選択ウィンドウの２０％未満であった場合、センシングウィンドウのリソースごとに設定される閾値Ｔｈ_{ｐＴＸ，ｐＲＸ}を３ｄＢ上昇させて再度リソースの識別を実行する動作は繰り返されてもよい。

端末２０の下位レイヤは、Ｓ_Ａを上位レイヤに報告してもよい。端末２０の上位レイヤは、Ｓ_Ａに対してランダム選択を実行して使用するリソースを決定してもよい。端末２０は、決定したリソースを使用してサイドリンク送信を実行してもよい。

上述の図１４では、送信側端末２０の動作を説明したが、受信側端末２０は、センシング又は部分センシングの結果に基づいて、他の端末２０からのデータ送信を検知して、当該他の端末２０からデータを受信してもよい。

図１５は、ＮＲにおけるプリエンプションの例を示すフローチャートである。図１６は、ＮＲにおけるプリエンプションの例を示す図である。ステップＳ５０１において、端末２０は、センシングウィンドウでセンシングを実行する。端末２０が省電力動作を行う場合、予め規定された限定された期間でセンシングが実行されてもよい。続いて、端末２０は、センシング結果に基づいてリソース選択ウィンドウ内の各リソースを識別してリソース候補の集合Ｓ_Ａを決定し、送信に使用するリソースを選択する（Ｓ５０２）。続いて、端末２０は、リソース候補の集合Ｓ_Ａからプリエンプションを判定するリソースセット（ｒ＿０，ｒ＿１，・・・）を選択する（Ｓ５０３）。当該リソースセットは、プリエンプションされたか否かを判定するリソースとして上位レイヤからＰＨＹレイヤに通知されてもよい。

ステップＳ５０４において、端末２０は、図１６に示されるＴ（ｒ＿０）－Ｔ_３のタイミングで、センシング結果に基づいてリソース選択ウィンドウ内の各リソースを再度識別してリソース候補の集合Ｓ_Ａを決定し、さらに優先度に基づいてリソースセット（ｒ＿０，ｒ＿１，・・・）に対してプリエンプションを判定する。例えば、図１６に示されるｒ＿１は、再度のセンシングにより、他端末２０から送信されたＳＣＩが検出されており、Ｓ_Ａに含まれていない。プリエンプションが有効である場合、他端末２０から送信されたＳＣＩの優先度を示す値ｐｒｉｏ＿ＲＸが、自端末から送信するトランスポートブロックの優先度を示す値ｐｒｉｏ＿ＴＸよりも低い場合、端末２０はリソースｒ＿１をプリエンプションされたと判定する。なお、優先度を示す値はより低い値のほうが、優先度はより高くなる。すなわち、他端末２０から送信されたＳＣＩの優先度を示す値ｐｒｉｏ＿ＲＸが、自端末から送信するトランスポートブロックの優先度を示す値ｐｒｉｏ＿ＴＸよりも高い場合、端末２０はリソースｒ＿１をＳ_Ａから除外しない。または、プリエンプションが特定の優先度にのみ有効である場合（例えば、sl-PreemptionEnableがpl1, pl2, ..., pl8のいずれか）、この優先度をｐｒｉｏ＿ｐｒｅとする。このとき、他端末２０から送信されたＳＣＩの優先度を示す値ｐｒｉｏ＿ＲＸが、ｐｒｉｏ＿ｐｒｅよりも低く、かつ、ｐｒｉｏ＿ＲＸが、自端末から送信するトランスポートブロックの優先度を示す値ｐｒｉｏ＿ＴＸよりも低い場合、端末２０はリソースｒ＿１をプリエンプションされたと判定する。

ステップＳ５０５において、端末２０は、ステップＳ５０４においてプリエンプションが判定された場合、上位レイヤにプリエンプションを通知し、上位レイヤにおいてリソースの再選択を行い、プリエンプションのチェックを終了する。

なお、プリエンプションのチェックに代えて再評価（Re-evaluation）を実行する場合、上記ステップＳ５０４において、リソース候補の集合Ｓ_Ａを決定した後、Ｓ_Ａにリソースセット（ｒ＿０，ｒ＿１，・・・）のリソースが含まれない場合、当該リソースを使用せず、上位レイヤにおいてリソースの再選択を行う。

図１７は、ＬＴＥにおける部分センシング動作の例を示す図である。ＬＴＥサイドリンクにおいて部分センシングが上位レイヤから設定された場合、図１７に示されるように端末２０はリソースを選択して送信を行う。図１７に示されるように、端末２０は、リソースプール内のセンシングウィンドウの一部すなわちセンシングターゲットに対して部分センシングを実行する。部分センシングにより、端末２０は、他の端末２０から送信されるＳＣＩに含まれるリソース予約フィールドを受信し、当該フィールドに基づいて、リソースプール内のリソース選択ウィンドウ内の使用可能なリソース候補を識別する。続いて、端末２０は使用可能なリソース候補からランダムにリソースを選択する。

図１７は、サブフレームｔ_０ ^ＳＬからサブフレームｔ_{Ｔｍａｘ－１} ^ＳＬまでがリソースプールとして設定される例である。リソースプールは、例えばビットマップによって対象領域が設定されてもよい。図１７に示されるように、端末２０における送信トリガはサブフレームｎで発生するものとする。図１７に示されるように、サブフレームｎ＋Ｔ_１からサブフレームｎ＋Ｔ₂までのうち、サブフレームｔ_ｙ１ ^ＳＬからサブフレームｔ_ｙＹ ^ＳＬまでのＹサブフレームがリソース選択ウィンドウとして設定されてもよい。

端末２０は、Ｙサブフレーム長となるサブフレームｔ_{ｙ１－ｋ×Ｐｓｔｅｐ} ^ＳＬからサブフレームｔ_{ｙＹ－ｋ×Ｐｓｔｅｐ} ^ＳＬまでの１又は複数のセンシングターゲットにおいて、例えば他の端末２０が送信を行っていることを検出することができる。ｋは、例えば１０ビットのビットマップによって決定されてもよい。図１７では、ビットマップの３番目と６番目のビットが、部分センシングを行うことを示す"１"に設定される例を示す。すなわち、図１７において、サブフレームｔ_{ｙ１－６×Ｐｓｔｅｐ} ^ＳＬからサブフレームｔ_{ｙＹ－６×Ｐｓｔｅｐ} ^ＳＬまでと、サブフレームｔ_{ｙ１－３×Ｐｓｔｅｐ} ^ＳＬからサブフレームｔ_{ｙＹ－３×Ｐｓｔｅｐ} ^ＳＬまでとがセンシングターゲットとして設定される。上記のように、ビットマップのｋ番目のビットは、サブフレームｔ_{ｙ１－ｋ×Ｐｓｔｅｐ} ^ＳＬからサブフレームｔ_{ｙＹ－ｋ×Ｐｓｔｅｐ} ^ＳＬまでのセンシングウィンドウに対応してもよい。なお、ｙ_ｉはＹサブフレーム内のインデックス（１...Ｙ）に対応する。

なお、ｋは１０ビットのビットマップで設定されるか予め規定され、Ｐ_ｓｔｅｐは１００ｍｓであってもよい。ただし、ＤＬ及びＵＬキャリアでＳＬ通信を行う場合、Ｐ_ｓｔｅｐは（Ｕ／（Ｄ＋Ｓ＋Ｕ））＊１００ｍｓとしてもよい。ＵはＵＬサブフレーム数、ＤはＤＬサブフレーム数、Ｓはスペシャルサブフレーム数に対応する。

上記のセンシングターゲットにおいてＳＣＩが検出され、かつＲＳＲＰが閾値を上回る場合、当該ＳＣＩのリソース予約フィールドに対応するリソース選択ウィンドウ内のリソースは除外される。また、センシングターゲットにおいてＳＣＩが検出され、かつＲＳＲＰが閾値未満である場合、当該ＳＣＩのリソース予約フィールドに対応するリソース選択ウィンドウ内のリソースは除外されない。当該閾値は、例えば、送信側優先度ｐ_ＴＸ及び受信側優先度ｐ_ＲＸに基づいて、センシングターゲット内のリソースごとに設定又は定義される閾値Ｔｈ_{ｐＴＸ，ｐＲＸ}であってもよい。

図１７に示されるように、区間［ｎ＋Ｔ_１，ｎ＋Ｔ_２］のうちＹサブフレームに設定されるリソース選択ウィンドウにおいて、端末２０は、他ＵＥが占有するリソースを識別し、当該リソースを除外したリソースが、使用可能なリソース候補となる。なお、Ｙサブフレームは連続していなくてもよい。使用可能なリソース候補の集合をＳ_Ａとすると、Ｓ_Ａがリソース選択ウィンドウのリソースの２０％未満であった場合、センシングターゲットのリソースごとに設定される閾値Ｔｈ_{ｐＴＸ，ｐＲＸ}を３ｄＢ上昇させて再度リソースの識別を実行してもよい。

すなわち、閾値Ｔｈ_{ｐＴＸ，ｐＲＸ}を上昇させて再度リソースの識別を実行することで、ＲＳＲＰが閾値未満のため除外されないリソースを増加させてもよい。さらに、Ｓ_Ａの各リソースのＲＳＳＩを測定し、ＲＳＳＩが最小のリソースを集合Ｓ_Ｂに追加してもよい。リソース候補の集合Ｓ_Ｂがリソース選択ウィンドウの２０％以上となるまで、Ｓ_Ａに含まれるＲＳＳＩが最小のリソースをＳ_Ｂに追加する動作を繰り返してもよい。

端末２０の下位レイヤは、Ｓ_Ｂを上位レイヤに報告してもよい。端末２０の上位レイヤは、Ｓ_Ｂに対してランダム選択を実行して使用するリソースを決定してもよい。端末２０は、決定したリソースを使用してサイドリンク送信を実行してもよい。なお、端末２０は、一度リソースを確保した後、所定の回数（例えばＣ_{ｒｅｓｅｌ}回）はセンシングを行わずに周期的にリソースを使用してもよい。

ここで、ＮＲリリース１７サイドリンクにおいて、ランダムリソース選択（random resource selection）及び部分センシング（partial sensing）をベースとする省電力化が検討されている。例えば、省電力化のため、ＬＴＥリリース１４におけるサイドリンクのランダムリソース選択及び部分センシングが、ＮＲリリース１６サイドリンクのリソース割り当てモード２に適用されてもよい。部分センシングが適用される端末２０は、センシングウィンドウ内の特定のスロットでのみ受信及びセンシングを実行する。

また、ＮＲリリース１７サイドリンクにおいて、端末間協調（inter-UE coordination）をベースラインとして、動作が検討されている。例えば、端末２０Ａはリソースセットを示す情報を端末２０Ｂと共有し、端末２０Ｂは送信のためのリソース選択において当該情報を考慮してもよい。

例えば、サイドリンクにおけるリソース割り当て方法として、端末２０は、図１４に示されるようなフルセンシングを実行してもよい。また、端末２０は、フルセンシングと比較して限定されたリソースのみに対するセンシングによってリソースの識別を実行し、識別されたリソースセットからリソース選択を行う部分センシングを実行してもよい。また、端末２０は、リソース選択ウィンドウ内のリソースからリソースの除外を行うことなく、リソース選択ウィンドウ内のリソースを識別されたリソースセットとし、当該識別されたリソースセットからリソース選択を行うランダム選択を実行してもよい。

なお、リソース選択の時点では、ランダム選択を実行し、再評価又はプリエンプションチェック時にはセンシング情報を使用する方法が、部分センシングとして扱われてもよいし、ランダム選択として扱われてもよい。

なお、センシングにおける動作として、以下に示される１）及び２）が適用されてもよい。なお、センシングとモニタリングとは互いに読み替えられてもよく、受信ＲＳＲＰの測定、予約リソース情報の取得及び優先度情報の取得のうち少なくとも一つが当該動作に含まれていてもよい。

１）周期的部分センシング（Periodic-based partial sensing）
一部のスロットのみセンシングを行う仕組みにおいて、予約周期（Reservation periodicity）に基づいてセンシングスロットを決定する動作。なお、予約周期は、リソース予約周期フィールド（resource reservation period field）に関連する値である。なお、周期は周期性に置き換えられてもよい。

２）連続部分センシング（Contiguous partial sensing）
一部のスロットのみセンシングを仕組みにおいて、非周期的予約（aperiodic reservation）に基づいてセンシングスロットを決定する動作。なお、非周期的予約は、時間リソース割り当てフィールド（time resource assignment field）に関連する値である。

リリース１７においては、３タイプの端末２０を想定して動作を規定してもよい。一つは、タイプＡであり、タイプＡの端末２０は、いかなるサイドリンクの信号及びチャネルを受信する能力を有しない。ただし、ＰＳＦＣＨ及びＳ－ＳＳＢを受信することを例外としてもよい。

他の一つは、タイプＢであり、タイプＢの端末２０は、ＰＳＦＣＨ及びＳ－ＳＳＢ受信を除くいかなるサイドリンクの信号及びチャネルを受信する能力を有しない。

他の一つは、タイプＤであり、タイプＤの端末２０は、リリース１６で定義されたすべてのサイドリンクの信号及びチャネル受信する能力を有する。ただし、一部のサイドリンクの信号及びチャネルを受信することを除外しない。

なお、上記のタイプＡ、タイプＢ及びタイプＤ以外のＵＥタイプが想定されてもよく、ＵＥタイプとＵＥ能力とは関連付けられなくてもよいし、関連付けられてもよい。

また、リリース１７においては、あるリソースプールに複数のリソース割り当て方法が設定され得る。また、省電力化機能の一つとして、ＳＬ－ＤＲＸ（Discontinuous reception）がサポートされる。すなわち、所定の時間区間でのみ受信動作が行われる。

上記の通り、省電力機能の一つとして部分センシングがサポートされる。部分センシングが設定されたリソースプールにおいて、端末２０は、上述した周期的部分センシングを実行してもよい。端末２０は、部分センシングが設定され、かつ周期的予約が有効に設定されたリソースプールを設定するための情報を、基地局１０から受信してもよい。

図１８は、周期的部分センシングの例を説明するための図である。図１８に示されるように、リソース選択のためのＹ候補スロットを、リソース選択ウィンドウ［ｎ＋Ｔ_１，ｎ＋Ｔ_２］から選択する。

ｔ_ｙ ^ＳＬをＹ候補スロットに含まれる一つのスロットとして、ｔ_{ｙ－ｋ×Ｐｒｅｓｅｒｖｅ} ^ＳＬを、周期的部分センシングの対象スロットとしてセンシングを行ってもよい。

Ｐ_{ｒｅｓｅｒｖｅ}は、設定されるか予め規定されるセットｓｌ－ＲｅｓｏｕｃｅＲｅｓｅｒｖｅＰｅｒｉｏｄＬｉｓｔに含まれるすべての値に対応してもよい。あるいは、ｓｌ－ＲｅｓｏｕｃｅＲｅｓｅｒｖｅＰｅｒｉｏｄＬｉｓｔのサブセットに限定されたＰ_{ｒｅｓｅｒｖｅ}の値が、設定されるか予め規定されてもよい。Ｐ_{ｒｅｓｅｒｖｅ}及びｓｌ－ＲｅｓｏｕｃｅＲｅｓｅｒｖｅＰｅｒｉｏｄＬｉｓｔは、リソース割り当てモード２の送信リソースプールごとに設定されてもよい。また、ＵＥ実装として、限定されたサブセット以外のｓｌ－ＲｅｓｏｕｃｅＲｅｓｅｒｖｅＰｅｒｉｏｄＬｉｓｔに含まれる周期をモニタリングしてもよい。例えば、端末２０は、Ｐ＿ＲＳＶＰ＿Ｔｘに対応する機会を追加的にモニタリングしてもよい。

ｋ値に関して、端末２０は、リソース選択トリガのスロットｎ以前の、あるいは、処理時間の制限を受けるＹ候補スロットの先頭スロット以前の、ある予約周期における最も新しいセンシング機会をモニタリングしてもよい。また、端末２０は、１以上のｋ値のセットに対応する周期的なセンシング機会を追加的にモニタリングしてもよい。例えば、ｋ値として、リソース選択トリガのスロットｎ以前の、あるいは、処理時間の制限を受けるＹ候補スロットの先頭スロット以前の、ある予約周期における最も新しいセンシング機会に対応する値と、当該ある予約周期における最も新しいセンシング機会の直前のセンシング機会に対応する値とが設定されてもよい。

上記の通り、省電力機能の一つとして部分センシングがサポートされる。部分センシングが設定されたリソースプールにおいて、端末２０は、上述した連続部分センシングを実行してもよい。端末２０は、部分センシングが設定され、かつ非周期的予約が有効に設定されたリソースプールを設定するための情報を、基地局１０から受信してもよい。

図１９は、連続部分センシングの例を説明するための図である。図１９に示されるように、端末２０は、リソース選択のトリガをスロットｎとした場合、リソース選択のためのＹ候補スロットをリソース選択ウィンドウ［ｎ＋Ｔ_１，ｎ＋Ｔ_２］から選択する。図１９は、Ｙ＝７の場合の一例である。図１９に示されるように、Ｙ候補スロットの先頭をスロットｔ_ｙ１とし、次のスロットをｔ_ｙ２とし、・・・、Ｙ候補スロットの末尾をスロットｔ_ｙＹと表記する。

端末２０は、区間［ｎ＋Ｔ_Ａ，ｎ＋Ｔ_Ｂ］でセンシングを行い、ｎ＋Ｔ_Ｂ又はｎ＋Ｔ_Ｂ以降（ｎ＋Ｔ_Ｃとする）でリソース選択を実行する。なお、上述した周期的部分センシングが追加的に実行されてもよい。なお、区間［ｎ＋Ｔ_Ａ，ｎ＋Ｔ_Ｂ］のＴ_ＡおよびＴ_Ｂは何れの値であってもよい。また、ｎはＹ候補スロットのうちの何れかのスロットのインデックスに置き換えられてもよい。

また、記号［は記号（に置き換えられてもよく、記号］は記号）に置き換えられてもよい。なお、例えば、区間［ａ，ｂ］は、スロットａからスロットｂまでの区間であって、スロットａ及びスロットｂを含む。例えば、区間（ａ，ｂ）は、スロットａからスロットｂまでの区間であって、スロットａ及びスロットｂを含まない。

なお、リソース選択の対象となる候補リソースを、Ｙ候補スロットと記載するが、区間［ｎ＋Ｔ_１，ｎ＋Ｔ_２］のすべてのスロットが候補スロットであってもよいし、一部のスロットが候補スロットであってもよい。

図２０は、通信状況の例（１）を説明するための図である。隠れ端末問題の例として、図２０に示されるように、端末２０Ｂから端末２０Ａに送信しようとするとき、端末２０Ａからは検出できない端末２０Ｃが、受信側端末２０Ｂに干渉を与える位置に存在する場合がある。例えば、端末２０Ａが予約した時間リソースにおいて端末２０Ｃが送信を行うと、端末２０Ｂが受信するときリソースのオーバラップが発生する。

また、サイドリンクは半二重通信であるため、双方の端末２０が送信を行うとリソースの衝突が発生する可能性がある。

図２１は、通信状況の例（２）を説明するための図である。遠近問題の例として、図２１に示されるように、端末２０Ｃから端末２０Ａに送信しようとするとき、送信側端末２０Ｃにおいては小さな電力で検出された端末２０Ｂが、受信側端末２０Ａに大きな干渉を与える位置に存在する場合がある。

図２２は、通信状況の例（３）を説明するための図である。時間領域における送信リソースと送信リソースの衝突の例として、図２２に示されるように、端末２０Ｂから予約された又はＰＳＳＣＨに関連付けられるＰＳＦＣＨ送信リソースと、端末２０Ｃから予約された又はＰＳＳＣＨに関連付けられるＰＳＦＣＨ送信リソースとが、端末２０Ａにてオーバラップする場合がある。複数の送信がオーバラップした場合、ドロップ又は電力低減が発生する。例えば、図２０に示されるＰＳＦＣＨとＰＳＦＣＨのオーバラップ、あるいはＰＳＦＣＨとＵＬチャネルのオーバラップ等が発生することが想定される。

図２３は、通信状況の例（４）を説明するための図である。時間領域における受信リソースと送信リソースの衝突の例として、図２３に示されるように、端末２０Ｂから予約されたリソースにおけるＰＳＳＣＨ受信と、端末２０Ａから予約されたリソースにおけるＰＳＳＣＨ送信とが、端末２０Ａにてオーバラップする場合がある。

図２４は、通信状況の例（５）を説明するための図である。時間領域における送信リソースと受信リソースの衝突の例として、図２４に示されるように、端末２０Ｂから予約されたＰＳＳＣＨに関連付けられるＰＳＦＣＨと、端末２０Ａから予約されたＰＳＳＣＨに関連付けられるＰＳＦＣＨとが、端末２０Ａにてオーバラップする場合がある。

信頼性及び遅延性能を向上させる手法として、端末間協調が検討されている。例えば、以下に示される端末間協調方法１及び端末間協調方法２が検討されている。以下、協調情報（Coordination information）を送信する端末２０をＵＥ－Ａ、協調情報を受信する端末２０をＵＥ－Ｂと記載する。

端末間協調方法１）ＵＥ－Ｂの送信のため、推奨される（preferred）リソースセット及び／又は推奨されない（non-preferred）リソースセットが、ＵＥ－ＡからＵＥ－Ｂに送信される。以下、「推奨されるリソースセット及び／又は推奨されないリソースセット」を、「推奨される／推奨されないリソース」と記載する。

端末間協調方法２）ＵＥ－Ｂから受信したＳＣＩにより指示されたリソースにおいて、他の送信又は受信との衝突が予期されること及び／又は衝突が検出されたリソースを示す情報を、ＵＥ－ＡはＵＥ－Ｂに送信する。

図２５は、端末間協調の例を説明するためのシーケンス図である。上記端末間協調方法１）は、図２５に示されるシーケンスによって実行されてもよい。

ステップＳ６０１において、ＵＥ－Ｂは、推奨される／推奨されないリソースを示す情報を要求する信号をＵＥ－Ａに送信する。ステップＳ６０１は、ＵＥ－Ａにおけるイベントに置換されてもよい。すなわち、ＵＥ－Ｂからの要求がない場合に、ＵＥ－Ａは自発的に推奨される／推奨されないリソースを示す情報をＵＥ－Ｂに送信してもよい。

続くステップＳ６０２において、ＵＥ－Ａは、推奨される／推奨されないリソースを決定する。続くステップＳ６０３において、ＵＥ－Ａは、推奨される／推奨されないリソースを示す情報をＵＥ－Ｂに送信する。続くステップＳ６０４において、ＵＥ－Ｂは、受信した推奨される／推奨されないリソースを示す情報に基づいて、リソース選択又は再選択を実行する。なお、選択又は再選択されたリソースを使用して、ＵＥ－ＢはＵＥ－Ａに送信してもよいし、ＵＥ－Ａ以外のＵＥに送信してもよい。

ステップＳ６０４において、ＵＥ－Ｂは、自装置におけるセンシング結果と、推奨されるリソースを示す情報とに基づいて、リソース選択又は再選択を実行してもよく、条件に基づいて推奨されるリソースに含まれないリソースを選択又は再選択してもよい。また、ステップＳ６０４において、ＵＥ－Ｂは、推奨されるリソースを示す情報のみに基づいて、推奨されるリソースの中からリソースを選択又は再選択してもよい。

また、ステップＳ６０４において、ＵＥ－Ｂは、自装置におけるセンシング結果と、推奨されないリソースを示す情報とに基づいて、リソース選択又は再選択を実行してもよく、推奨されないリソースを選択対象から除外してもよい。

図２６は、本発明の実施の形態におけるリソース選択の例を説明するためのフローチャートである。ステップＳ７０１において、端末２０は、識別するリソースセットＳ_Ａを初期化する。続くステップＳ７０２において、端末２０は、センシングによるＲＳＲＰに基づいてＳ_Ａからリソースを除外してＳ_Ａを更新する。なお、Ｓ_Ａは、リソース選択における候補リソースの集合である。

続くステップＳ７０３において、端末２０は、Ｓ_Ａは初期化されたリソースセットのＫ％以上であるか否か判定する。Ｋ％以上である場合（Ｓ７０３のＹＥＳ）、ステップＳ７０４に進み、Ｋ％以上でない場合（Ｓ７０３のＮＯ）、ステップＳ７０５に進む。

ステップＳ７０４において、端末２０は、上位レイヤにＳ_Ａを報告し、ステップＳ７０６に進む。一方、ステップＳ７０５において、端末２０は、ＲＳＲＰを判定する閾値を変更し、ステップＳ７０１に進む。ステップＳ７０６において、端末２０は、Ｓ_Ａからリソースを選択する。

ここで、ＵＥ－Ａから推奨される／推奨されないリソースを示す情報を受信し、ステップＳ６０４におけるＵＥ－Ｂの動作の詳細として、推奨されるリソースが使用できない状況の判定方法が明確ではなかった。例えば、ＵＥ－Ｂは、リソース除外及び識別のいずれの段階のリソースセットＳ_Ａに基づいて、推奨されるリソースが使用できるか否かを判定するか、また当該状況における動作が不明であった。

また、推奨されないリソース以外のリソースが使用できない状況の判定方法、例えば、ＵＥ－Ｂは、リソース除外及び識別のいずれの段階のリソースセットＳ_Ａに基づいて、推奨されるリソースが使用できるか否かを判定するか、また当該状況における動作が不明であった。

そこで、ＵＥ－Ｂは、ＵＥ－Ａから推奨されるリソースセットを示す情報を受信した場合、以下に示される１－０）から１－６）までのように動作してもよい。

１－０）ＵＥ－Ｂは、所定のＲＳＲＰ閾値を使用し、推奨されるリソースに対する他のＵＥの予約信号の受信ＲＳＲＰが当該閾値を超えるか否かを判定してもよい。１－０）における動作は、ステップＳ７０１－ステップＳ７０６におけるＳ_Ａの決定とは独立して実行されてもよい。推奨されるリソースのうち、当該閾値を超えないリソースが所定数以上存在する場合、Ｓ_Ａとして又はＳ_Ａの代替として当該閾値を超えないリソースを上位レイヤに報告してもよい。また、推奨されるリソースのうち、当該閾値を超えないリソースが所定数以上存在しない場合、Ｓ_ＡをステップＳ７０１－ステップＳ７０６により決定して上位レイヤに報告してもよい。

１－１）ＵＥ－Ｂは、ＲＳＲＰ閾値を変更しない段階におけるＳ_Ａに推奨されるリソースが含まれるか否か判定してもよい。例えば、ＵＥ－Ｂは、ステップＳ７０２の後かつステップＳ７０３の前で、１－１）を実行してもよい。例えば、ＵＥ－Ｂは、初期のＲＳＲＰ閾値を用いてリソース除外を実行した段階で１－１）を実行してもよい。例えば、ＵＥ－Ｂは、周期的予約に対してモニタリングしなかったスロットに対応するスロットを除外した段階で１－１）を実行してもよい。なお、ＵＥ－Ｂは、ＲＳＲＰ閾値を変更しない段階におけるＳ_Ａに推奨されるリソースが含まれる場合、Ｓ_Ａに含まれる推奨されるリソースを上位レイヤにＳ_Ａとして報告し、上位レイヤは報告されたＳ_Ａからリソースを選択してもよい。なお、１－１）は物理レイヤにおける動作であってもよい。

１－２）ＵＥ－Ｂは、ＲＳＲＰ閾値を所定値まで変更した段階におけるＳ_Ａに推奨されるリソースが含まれるか否かを判定してもよい。当該所定値は、定義されてもよいし、予め設定されてもよいし、設定されてもよい。例えば、ＵＥ－Ｂは、ステップＳ７０２の後かつステップＳ７０３の前で、１－２）を実行してもよい。なお、ＵＥ－Ｂは、ＲＳＲＰ閾値を所定値まで変更した段階におけるＳ_Ａに推奨されるリソースが含まれる場合、Ｓ_Ａに含まれる推奨されるリソースを上位レイヤにＳ_Ａとして報告し、上位レイヤは報告されたＳ_Ａからリソースを選択してもよい。なお、１－２）は物理レイヤにおける動作であってもよい。

１－３）ＵＥ－Ｂは、Ｓ_Ａが初期化されたＳ_Ａのリソース量のＫ％以上であることが満たされた段階におけるＳ_Ａに推奨されるリソースが含まれるか否かを判定してもよい。例えば、ＵＥ－Ｂは、ステップＳ７０３の後かつステップＳ７０４の前で、１－３）を実行してもよい。なお、ＵＥ－Ｂは、Ｓ_Ａが初期化されたＳ_Ａのリソース量のＫ％以上であることが満たされた段階におけるＳ_Ａに推奨されるリソースが含まれる場合、Ｓ_Ａに含まれる推奨されるリソースを上位レイヤにＳ_Ａとして報告し、上位レイヤは報告されたＳ_Ａからリソースを選択してもよい。なお、１－３）は物理レイヤにおける動作であってもよい。

１－４）ＵＥ－Ｂは、物理レイヤから上位レイヤにＳ_Ａが報告された段階におけるＳ_Ａに推奨されるリソースが含まれるか否かを判定してもよい。例えば、ＵＥ－Ｂは、ステップＳ７０４の後かつステップＳ７０６の前で、１－４）を実行してもよい。なお、ＵＥ－Ｂは、物理レイヤから上位レイヤにＳ_Ａが報告された段階におけるＳ_Ａに推奨されるリソースが含まれる場合、上位レイヤは、Ｓ_Ａに含まれる推奨されるリソースからリソースを選択してもよい。なお、１－４）は上位レイヤ（例えばＭＡＣレイヤ）における動作であってもよい。

１－５）ＵＥ－Ｂは、１－１）、１－２）、１－３）及び１－４）のいずれかにおいて判定を行い、推奨されるリソースが所定数以上、Ｓ_Ａに含まれていない場合、推奨されるリソース以外のリソースを使用してもよい。例えば、ＵＥ－Ｂは、複数のリソースを選択する場合、一部が推奨されるリソースで残りの一部が推奨されるリソース以外のリソースであってもよい。例えば、複数サブチャネルのリソースを選択する場合、一部のサブチャネルが推奨されるリソースで、残りのサブチャネルが推奨されるリソース以外であってもよい。例えば、ＵＥ－Ｂの送信トランスポートブロックに係る優先度が所定の優先度より高い（値が小さい）場合に限定して、推奨されるリソースが所定数以上、Ｓ_Ａに含まれていない場合、推奨されるリソース以外のリソースを使用してもよい。当該所定の優先度は、定義されてもよいし、予め設定されてもよいし、設定されてもよい。

１－６）ＵＥ－Ｂは、１－１）、１－２）、１－３）及び１－４）のいずれかにおいて判定を行い、推奨されるリソースが所定数以上、Ｓ_Ａに含まれている場合、当該推奨されるリソースを使用してもよい。例えば、ＵＥ－Ｂは、１－１）及び１－２）においてＳ_Ａが初期化されたリソースセットのＫ％以上であることが満たされない場合であっても、推奨されるリソースが所定数以上Ｓ_Ａに含まれている場合、Ｓ_Ａを上位レイヤに報告してもよい。

上述のように動作することで、推奨されるリソースの使用可否に係るＵＥ動作が明確になる。

また、ＵＥ－Ｂは、ＵＥ－Ａから推奨されないリソースセットを示す情報を受信した場合、以下に示される２－１）から２－８）までのように動作してもよい。

２－１）ＵＥ－Ｂは、リソース除外動作において、Ｓ_Ａに含まれる推奨されないリソースをＳ_Ａから除外してもよい。例えば、ＵＥ－Ｂは、ステップＳ７０２においてＳ_Ａに含まれる推奨されないリソースをＳ_Ａから除外してもよい。また、ＵＥ－Ｂは、センシング及びＲＳＲＰ閾値に基づくリソース除外動作の前に、Ｓ_Ａに含まれる推奨されないリソースをＳ_Ａから除外してもよい。なお、２－１）は物理レイヤにおける動作であってもよい。

２－２）ＵＥ－Ｂは、Ｓ_Ａが初期化されたリソースセットＳ_ＡのＫ％以上であることが満たされた段階において、Ｓ_Ａに含まれている推奨されないリソースをＳ_Ａから除外してもよい。例えば、ＵＥ－Ｂは、ステップＳ７０３の後かつステップＳ７０４の前でＳ_Ａに含まれる推奨されないリソースをＳ_Ａから除外してもよい。なお、２－２）は物理レイヤにおける動作であってもよい。

２－３）ＵＥ－Ｂは、物理レイヤから上位レイヤにＳ_Ａが報告された段階において、Ｓ_Ａに含まれている推奨されないリソースをＳ_Ａから除外してもよい。例えば、ＵＥ－Ｂは、ステップＳ７０４の後かつステップＳ７０６の前でＳ_Ａに含まれる推奨されないリソースをＳ_Ａから除外してもよい。なお、２－３）は上位レイヤ（例えばＭＡＣレイヤ）における動作であってもよい。

２－４）ＵＥ－Ｂは、２－１）に示される動作の実行後、Ｓ_Ａに含まれるリソース量が初期化されたリソースセットＳ_ＡのＫ％を超えない場合、Ｓ_Ａに推奨されないリソースを含めるようにＳ_Ａを変更してもよい。

２－５）ＵＥ－Ｂは、２－２）又は２－３）に示される動作の実行後、Ｓ_Ａに含まれるリソース量が、選択したリソース量に達しない場合、Ｓ_Ａに推奨されないリソースを含めるようにＳ_Ａを変更してもよい。

２－６）２－４）又は２－５）に示される動作の実行は、ＵＥ－Ｂの送信トランスポートブロックに係るデスティネーションＵＥが当該ＵＥ－Ａを含まない場合に限定されてもよい。

２－７）２－４）又は２－５）に示される動作の実行は、ＵＥ－Ｂの送信トランスポートブロックに係る優先度が所定の優先度よりも高い（値が小さい）場合に限定されてもよい。当該所定の優先度は、定義されてもよいし、予め設定されてもよいし、設定されてもよい。

２－８）２－４）又は２－５）に示される動作の実行は、推奨されないリソースである条件（例えば、時間及び周波数リソースのオーバラップ等）が所定の条件である場合に限定されてもよい。当該所定の条件は定義されていてもよいし、予め設定されてもよいし、設定されてもよい。

上述のように動作することで、推奨されないリソースの使用可否に係るＵＥ動作が明確になる。

上述の実施例は、ある端末２０が他の端末２０の送信リソースを設定する又は割り当てる動作に適用されてもよい。

上述の実施例は、Ｖ２Ｘ端末に限定されず、Ｄ２Ｄ通信を行う端末に適用されてもよい。

上述の実施例に係る動作は、特定のリソースプールのみで実行されるとしてもよい。例えば、リリース１７以降の端末２０が使用可能なリソースプールでのみ実行されるとしてもよい。

上述の実施例により、端末２０は、端末間協調に係る動作において、他の端末から推奨される／推奨されないリソースを示す情報を受信し、当該情報に基づいてリソース選択を実行することで、通信の信頼性を向上させることができる。

すなわち、端末間直接通信において、自律的リソース選択に係る動作を他の端末からの情報に基づいて実行することができる。

（装置構成）
次に、これまでに説明した処理及び動作を実行する基地局１０及び端末２０の機能構成例を説明する。基地局１０及び端末２０は上述した実施例を実施する機能を含む。ただし、基地局１０及び端末２０はそれぞれ、実施例の中の一部の機能のみを備えることとしてもよい。

＜基地局１０＞
図２７は、基地局１０の機能構成の一例を示す図である。図２７に示されるように、基地局１０は、送信部１１０と、受信部１２０と、設定部１３０と、制御部１４０とを有する。図２７に示される機能構成は一例に過ぎない。本発明の実施の形態に係る動作を実行できるのであれば、機能区分及び機能部の名称はどのようなものでもよい。

送信部１１０は、端末２０側に送信する信号を生成し、当該信号を無線で送信する機能を含む。受信部１２０は、端末２０から送信された各種の信号を受信し、受信した信号から、例えばより上位のレイヤの情報を取得する機能を含む。また、送信部１１０は、端末２０へＮＲ－ＰＳＳ、ＮＲ－ＳＳＳ、ＮＲ－ＰＢＣＨ、ＤＬ／ＵＬ制御信号、ＤＬ参照信号等を送信する機能を有する。

設定部１３０は、予め設定される設定情報、及び、端末２０に送信する各種の設定情報を記憶装置に格納し、必要に応じて記憶装置から読み出す。設定情報の内容は、例えば、Ｄ２Ｄ通信の設定に係る情報等である。

制御部１４０は、実施例において説明したように、端末２０がＤ２Ｄ通信を行うための設定に係る処理を行う。また、制御部１４０は、Ｄ２Ｄ通信及びＤＬ通信のスケジューリングを送信部１１０を介して端末２０に送信する。また、制御部１４０は、Ｄ２Ｄ通信及びＤＬ通信のＨＡＲＱ応答に係る情報を受信部１２０を介して端末２０から受信する。制御部１４０における信号送信に関する機能部を送信部１１０に含め、制御部１４０における信号受信に関する機能部を受信部１２０に含めてもよい。

＜端末２０＞
図２８は、端末２０の機能構成の一例を示す図である。図２８に示されるように、端末２０は、送信部２１０と、受信部２２０と、設定部２３０と、制御部２４０とを有する。図２８に示される機能構成は一例に過ぎない。本発明の実施の形態に係る動作を実行できるのであれば、機能区分及び機能部の名称はどのようなものでもよい。

送信部２１０は、送信データから送信信号を作成し、当該送信信号を無線で送信する。受信部２２０は、各種の信号を無線受信し、受信した物理レイヤの信号からより上位のレイヤの信号を取得する。また、受信部２２０は、基地局１０から送信されるＮＲ－ＰＳＳ、ＮＲ－ＳＳＳ、ＮＲ－ＰＢＣＨ、ＤＬ／ＵＬ／ＳＬ制御信号又は参照信号等を受信する機能を有する。また、例えば、送信部２１０は、Ｄ２Ｄ通信として、他の端末２０に、ＰＳＣＣＨ（Physical Sidelink Control Channel）、ＰＳＳＣＨ（Physical Sidelink Shared Channel）、ＰＳＤＣＨ（Physical Sidelink Discovery Channel）、ＰＳＢＣＨ（Physical Sidelink Broadcast Channel）等を送信し、受信部２２０は、他の端末２０から、ＰＳＣＣＨ、ＰＳＳＣＨ、ＰＳＤＣＨ又はＰＳＢＣＨ等を受信する。

設定部２３０は、受信部２２０により基地局１０又は端末２０から受信した各種の設定情報を記憶装置に格納し、必要に応じて記憶装置から読み出す。また、設定部２３０は、予め設定される設定情報も格納する。設定情報の内容は、例えば、Ｄ２Ｄ通信の設定に係る情報等である。

制御部２４０は、実施例において説明したように、他の端末２０との間のＲＲＣ接続を確立するＤ２Ｄ通信を制御する。また、制御部２４０は、省電力動作に係る処理を行う。また、制御部２４０は、Ｄ２Ｄ通信及びＤＬ通信のＨＡＲＱに係る処理を行う。また、制御部２４０は、基地局１０からスケジューリングされた他の端末２０へのＤ２Ｄ通信及びＤＬ通信のＨＡＲＱ応答に係る情報を基地局１０に送信する。また、制御部２４０は、他の端末２０にＤ２Ｄ通信のスケジューリングを行ってもよい。また、制御部２４０は、センシングの結果に基づいてＤ２Ｄ通信に使用するリソースをリソース選択ウィンドウから自律的に選択してもよいし、再評価又はプリエンプションを実行してもよい。また、制御部２４０は、Ｄ２Ｄ通信の送受信における省電力に係る処理を行う。また、制御部２４０は、Ｄ２Ｄ通信における端末間協調に係る処理を行う。制御部２４０における信号送信に関する機能部を送信部２１０に含め、制御部２４０における信号受信に関する機能部を受信部２２０に含めてもよい。

（ハードウェア構成）
上記実施形態の説明に用いたブロック図（図２７及び図２８）は、機能単位のブロックを示している。これらの機能ブロック（構成部）は、ハードウェア及びソフトウェアの少なくとも一方の任意の組み合わせによって実現される。また、各機能ブロックの実現方法は特に限定されない。すなわち、各機能ブロックは、物理的又は論理的に結合した１つの装置を用いて実現されてもよいし、物理的又は論理的に分離した２つ以上の装置を直接的又は間接的に（例えば、有線、無線などを用いて）接続し、これら複数の装置を用いて実現されてもよい。機能ブロックは、上記１つの装置又は上記複数の装置にソフトウェアを組み合わせて実現されてもよい。

機能には、判断、決定、判定、計算、算出、処理、導出、調査、探索、確認、受信、送信、出力、アクセス、解決、選択、選定、確立、比較、想定、期待、見做し、報知（broadcasting）、通知（notifying）、通信（communicating）、転送（forwarding）、構成（configuring）、再構成（reconfiguring）、割り当て（allocating、mapping）、割り振り（assigning）などがあるが、これらに限られない。たとえば、送信を機能させる機能ブロック（構成部）は、送信部（transmitting unit）や送信機（transmitter）と呼称される。いずれも、上述したとおり、実現方法は特に限定されない。

例えば、本開示の一実施の形態における基地局１０、端末２０等は、本開示の無線通信方法の処理を行うコンピュータとして機能してもよい。図２９は、本開示の一実施の形態に係る基地局１０及び端末２０のハードウェア構成の一例を示す図である。上述の基地局１０及び端末２０は、物理的には、プロセッサ１００１、記憶装置１００２、補助記憶装置１００３、通信装置１００４、入力装置１００５、出力装置１００６、バス１００７などを含むコンピュータ装置として構成されてもよい。

なお、以下の説明では、「装置」という文言は、回路、デバイス、ユニット等に読み替えることができる。基地局１０及び端末２０のハードウェア構成は、図に示した各装置を１つ又は複数含むように構成されてもよいし、一部の装置を含まずに構成されてもよい。

基地局１０及び端末２０における各機能は、プロセッサ１００１、記憶装置１００２等のハードウェア上に所定のソフトウェア（プログラム）を読み込ませることによって、プロセッサ１００１が演算を行い、通信装置１００４による通信を制御したり、記憶装置１００２及び補助記憶装置１００３におけるデータの読み出し及び書き込みの少なくとも一方を制御したりすることによって実現される。

プロセッサ１００１は、例えば、オペレーティングシステムを動作させてコンピュータ全体を制御する。プロセッサ１００１は、周辺装置とのインタフェース、制御装置、演算装置、レジスタ等を含む中央処理装置（ＣＰＵ：Central Processing Unit）で構成されてもよい。例えば、上述の制御部１４０、制御部２４０等は、プロセッサ１００１によって実現されてもよい。

また、プロセッサ１００１は、プログラム（プログラムコード）、ソフトウェアモジュール又はデータ等を、補助記憶装置１００３及び通信装置１００４の少なくとも一方から記憶装置１００２に読み出し、これらに従って各種の処理を実行する。プログラムとしては、上述の実施の形態において説明した動作の少なくとも一部をコンピュータに実行させるプログラムが用いられる。例えば、図２７に示した基地局１０の制御部１４０は、記憶装置１００２に格納され、プロセッサ１００１で動作する制御プログラムによって実現されてもよい。また、例えば、図２８に示した端末２０の制御部２４０は、記憶装置１００２に格納され、プロセッサ１００１で動作する制御プログラムによって実現されてもよい。上述の各種処理は、１つのプロセッサ１００１によって実行される旨を説明してきたが、２以上のプロセッサ１００１により同時又は逐次に実行されてもよい。プロセッサ１００１は、１以上のチップによって実装されてもよい。なお、プログラムは、電気通信回線を介してネットワークから送信されてもよい。

記憶装置１００２は、コンピュータ読み取り可能な記録媒体であり、例えば、ＲＯＭ（Read Only Memory）、ＥＰＲＯＭ（Erasable Programmable ROM）、ＥＥＰＲＯＭ（Electrically Erasable Programmable ROM）、ＲＡＭ（Random Access Memory）等の少なくとも１つによって構成されてもよい。記憶装置１００２は、レジスタ、キャッシュ、メインメモリ（主記憶装置）等と呼ばれてもよい。記憶装置１００２は、本開示の一実施の形態に係る通信方法を実施するために実行可能なプログラム（プログラムコード）、ソフトウェアモジュール等を保存することができる。

補助記憶装置１００３は、コンピュータ読み取り可能な記録媒体であり、例えば、ＣＤ－ＲＯＭ（Compact Disc ROM）等の光ディスク、ハードディスクドライブ、フレキシブルディスク、光磁気ディスク（例えば、コンパクトディスク、デジタル多用途ディスク、Ｂｌｕ－ｒａｙ（登録商標）ディスク）、スマートカード、フラッシュメモリ（例えば、カード、スティック、キードライブ）、フロッピー（登録商標）ディスク、磁気ストリップ等の少なくとも１つによって構成されてもよい。上述の記憶媒体は、例えば、記憶装置１００２及び補助記憶装置１００３の少なくとも一方を含むデータベース、サーバその他の適切な媒体であってもよい。

通信装置１００４は、有線ネットワーク及び無線ネットワークの少なくとも一方を介してコンピュータ間の通信を行うためのハードウェア（送受信デバイス）であり、例えばネットワークデバイス、ネットワークコントローラ、ネットワークカード、通信モジュールなどともいう。通信装置１００４は、例えば周波数分割複信（ＦＤＤ：Frequency Division Duplex）及び時分割複信（ＴＤＤ：Time Division Duplex）の少なくとも一方を実現するために、高周波スイッチ、デュプレクサ、フィルタ、周波数シンセサイザなどを含んで構成されてもよい。例えば、送受信アンテナ、アンプ部、送受信部、伝送路インタフェース等は、通信装置１００４によって実現されてもよい。送受信部は、送信部と受信部とで、物理的に、または論理的に分離された実装がなされてもよい。

入力装置１００５は、外部からの入力を受け付ける入力デバイス（例えば、キーボード、マウス、マイクロフォン、スイッチ、ボタン、センサ等）である。出力装置１００６は、外部への出力を実施する出力デバイス（例えば、ディスプレイ、スピーカー、LEDランプ等）である。なお、入力装置１００５及び出力装置１００６は、一体となった構成（例えば、タッチパネル）であってもよい。

また、プロセッサ１００１及び記憶装置１００２等の各装置は、情報を通信するためのバス１００７によって接続される。バス１００７は、単一のバスを用いて構成されてもよいし、装置間ごとに異なるバスを用いて構成されてもよい。

また、基地局１０及び端末２０は、マイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ：Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）、ＦＰＧＡ（Field Programmable Gate Array）等のハードウェアを含んで構成されてもよく、当該ハードウェアにより、各機能ブロックの一部又は全てが実現されてもよい。例えば、プロセッサ１００１は、これらのハードウェアの少なくとも１つを用いて実装されてもよい。

図３０に車両２００１の構成例を示す。図３０に示すように、車両２００１は駆動部２００２、操舵部２００３、アクセルペダル２００４、ブレーキペダル２００５、シフトレバー２００６、前輪２００７、後輪２００８、車軸２００９、電子制御部２０１０、各種センサ２０２１～２０２９、情報サービス部２０１２と通信モジュール２０１３を備える。本開示において説明した各態様／実施形態は、車両２００１に搭載される通信装置に適用されてもよく、例えば、通信モジュール２０１３に適用されてもよい。

駆動部２００２は例えば、エンジン、モータ、エンジンとモータのハイブリッドで構成される。操舵部２００３は、少なくともステアリングホイール（ハンドルとも呼ぶ）を含み、ユーザによって操作されるステアリングホイールの操作に基づいて前輪及び後輪の少なくとも一方を操舵するように構成される。

電子制御部２０１０は、マイクロプロセッサ２０３１、メモリ（ROM、RAM）２０３２、通信ポート（ＩＯポート）２０３３で構成される。電子制御部２０１０には、車両２００１に備えられた各種センサ２０２１～２０２９からの信号が入力される。電子制御部２０１０は、ＥＣＵ（Electronic Control Unit）と呼んでも良い。

各種センサ２０２１～２０２９からの信号としては、モータの電流をセンシングする電流センサ２０２１からの電流信号、回転数センサ２０２２によって取得された前輪や後輪の回転数信号、空気圧センサ２０２３によって取得された前輪や後輪の空気圧信号、車速センサ２０２４によって取得された車速信号、加速度センサ２０２５によって取得された加速度信号、アクセルペダルセンサ２０２９によって取得されたアクセルペダルの踏み込み量信号、ブレーキペダルセンサ２０２６によって取得されたブレーキペダルの踏み込み量信号、シフトレバーセンサ２０２７によって取得されたシフトレバーの操作信号、物体検知センサ２０２８によって取得された障害物、車両、歩行者等を検出するための検出信号等がある。

情報サービス部２０１２は、カーナビゲーションシステム、オーディオシステム、スピーカ、テレビ、ラジオといった、運転情報、交通情報、エンターテイメント情報等の各種情報を提供するための各種機器と、これらの機器を制御する１つ以上のＥＣＵとから構成される。情報サービス部２０１２は、外部装置から通信モジュール２０１３等を介して取得した情報を利用して、車両２００１の乗員に各種マルチメディア情報及びマルチメディアサービスを提供する。

運転支援システム部２０３０は、ミリ波レーダ、ＬｉＤＡＲ（Light Detection and Ranging）、カメラ、測位ロケータ（例えば、ＧＮＳＳ等）、地図情報（例えば、高精細（ＨＤ）マップ、自動運転車（ＡＶ）マップ等）、ジャイロシステム（例えば、ＩＭＵ（Inertial Measurement Unit）、ＩＮＳ（Inertial Navigation System）等）、ＡＩ（Artificial Intelligence）チップ、ＡＩプロセッサといった、事故を未然に防止したりドライバの運転負荷を軽減したりするための機能を提供するための各種機器と、これらの機器を制御する１つ以上のＥＣＵとから構成される。また、運転支援システム部２０３０は、通信モジュール２０１３を介して各種情報を送受信し、運転支援機能又は自動運転機能を実現する。

通信モジュール２０１３は通信ポートを介して、マイクロプロセッサ２０３１および車両２００１の構成要素と通信することができる。例えば、通信モジュール２０１３は通信ポート２０３３を介して、車両２００１に備えられた駆動部２００２、操舵部２００３、アクセルペダル２００４、ブレーキペダル２００５、シフトレバー２００６、前輪２００７、後輪２００８、車軸２００９、電子制御部２０１０内のマイクロプロセッサ２０３１及びメモリ（ＲＯＭ、ＲＡＭ）２０３２、センサ２０２１～２９との間でデータを送受信する。

通信モジュール２０１３は、電子制御部２０１０のマイクロプロセッサ２０３１によって制御可能であり、外部装置と通信を行うことが可能な通信デバイスである。例えば、外部装置との間で無線通信を介して各種情報の送受信を行う。通信モジュール２０１３は、電子制御部２０１０の内部と外部のどちらにあってもよい。外部装置は、例えば、基地局、移動局等であってもよい。

通信モジュール２０１３は、電子制御部２０１０に入力された電流センサからの電流信号を、無線通信を介して外部装置へ送信する。また、通信モジュール２０１３は、電子制御部２０１０に入力された、回転数センサ２０２２によって取得された前輪や後輪の回転数信号、空気圧センサ２０２３によって取得された前輪や後輪の空気圧信号、車速センサ２０２４によって取得された車速信号、加速度センサ２０２５によって取得された加速度信号、アクセルペダルセンサ２０２９によって取得されたアクセルペダルの踏み込み量信号、ブレーキペダルセンサ２０２６によって取得されたブレーキペダルの踏み込み量信号、シフトレバーセンサ２０２７によって取得されたシフトレバーの操作信号、物体検知センサ２０２８によって取得された障害物、車両、歩行者等を検出するための検出信号等についても無線通信を介して外部装置へ送信する。

通信モジュール２０１３は、外部装置から送信されてきた種々の情報（交通情報、信号情報、車間情報等）を受信し、車両２００１に備えられた情報サービス部２０１２へ表示する。また、通信モジュール２０１３は、外部装置から受信した種々の情報をマイクロプロセッサ２０３１によって利用可能なメモリ２０３２へ記憶する。メモリ２０３２に記憶された情報に基づいて、マイクロプロセッサ２０３１が車両２００１に備えられた駆動部２００２、操舵部２００３、アクセルペダル２００４、ブレーキペダル２００５、シフトレバー２００６、前輪２００７、後輪２００８、車軸２００９、センサ２０２１～２０２９等の制御を行ってもよい。

（実施の形態のまとめ）
以上、説明したように、本発明の実施の形態によれば、リソースプールにおいて推奨されるリソース及び推奨されないリソースのうち少なくとも一つを示す情報を他の端末から受信する受信部と、前記情報に基づいて、前記リソースプール内でリソースの選択を実行する制御部と、前記選択されたリソースを使用して送信を実行する送信部とを有し、前記制御部は、前記情報をリソースの選択に適用するタイミングを決定する端末が提供される。

上記の構成により、端末２０は、端末間協調に係る動作において、他の端末から推奨される／推奨されないリソースを示す情報を受信し、当該情報に基づいてリソース選択を実行することで、通信の信頼性を向上させることができる。すなわち、端末間直接通信において、自律的リソース選択に係る動作を他の端末からの情報に基づいて実行することができる。

前記制御部は、前記情報が推奨されるリソースを示す場合、リソース選択動作において受信電力に適用する閾値を変更しない段階で、前記情報をリソースの選択に適用してもよい。当該構成により、端末２０は、端末間協調に係る動作において、他の端末から推奨される／推奨されないリソースを示す情報を受信し、当該情報に基づいてリソース選択を実行することで、通信の信頼性を向上させることができる。

前記制御部は、前記情報が推奨されるリソースを示す場合、リソース選択動作において受信電力に適用する閾値をある値まで変更した段階で、前記情報をリソースの選択に適用してもよい。当該構成により、端末２０は、端末間協調に係る動作において、他の端末から推奨される／推奨されないリソースを示す情報を受信し、当該情報に基づいてリソース選択を実行することで、通信の信頼性を向上させることができる。

前記制御部は、前記情報が推奨されるリソースを示す場合、リソース選択動作において上位レイヤが候補となるリソースセットからリソースを選択する段階で、前記情報をリソースの選択に適用してもよい。当該構成により、端末２０は、端末間協調に係る動作において、他の端末から推奨される／推奨されないリソースを示す情報を受信し、当該情報に基づいてリソース選択を実行することで、通信の信頼性を向上させることができる。

前記制御部は、前記情報が推奨されないリソースを示す場合、リソース選択動作においてセンシング結果に基づいてリソースを除外する段階で、前記情報をリソースの選択に適用してもよい。当該構成により、端末２０は、端末間協調に係る動作において、他の端末から推奨される／推奨されないリソースを示す情報を受信し、当該情報に基づいてリソース選択を実行することで、通信の信頼性を向上させることができる。

また、本発明の実施の形態によれば、リソースプールにおいて推奨されるリソース及び推奨されないリソースのうち少なくとも一つを示す情報を他の端末から受信する受信手順と、前記情報に基づいて、前記リソースプール内でリソースの選択を実行する制御手順と、前記選択されたリソースを使用して送信を実行する送信手順と、前記情報をリソースの選択に適用するタイミングを決定する手順とを端末が実行する通信方法が提供される。

（実施形態の補足）
以上、本発明の実施の形態を説明してきたが、開示される発明はそのような実施形態に限定されず、当業者は様々な変形例、修正例、代替例、置換例等を理解するであろう。発明の理解を促すため具体的な数値例を用いて説明がなされたが、特に断りのない限り、それらの数値は単なる一例に過ぎず適切な如何なる値が使用されてもよい。上記の説明における項目の区分けは本発明に本質的ではなく、２以上の項目に記載された事項が必要に応じて組み合わせて使用されてよいし、ある項目に記載された事項が、別の項目に記載された事項に（矛盾しない限り）適用されてよい。機能ブロック図における機能部又は処理部の境界は必ずしも物理的な部品の境界に対応するとは限らない。複数の機能部の動作が物理的には１つの部品で行われてもよいし、あるいは１つの機能部の動作が物理的には複数の部品により行われてもよい。実施の形態で述べた処理手順については、矛盾の無い限り処理の順序を入れ替えてもよい。処理説明の便宜上、基地局１０及び端末２０は機能的なブロック図を用いて説明されたが、そのような装置はハードウェアで、ソフトウェアで又はそれらの組み合わせで実現されてもよい。本発明の実施の形態に従って基地局１０が有するプロセッサにより動作するソフトウェア及び本発明の実施の形態に従って端末２０が有するプロセッサにより動作するソフトウェアはそれぞれ、ランダムアクセスメモリ（ＲＡＭ）、フラッシュメモリ、読み取り専用メモリ（ＲＯＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、レジスタ、ハードディスク（ＨＤＤ）、リムーバブルディスク、ＣＤ－ＲＯＭ、データベース、サーバその他の適切な如何なる記憶媒体に保存されてもよい。

また、情報の通知は、本開示で説明した態様／実施形態に限られず、他の方法を用いて行われてもよい。例えば、情報の通知は、物理レイヤシグナリング（例えば、ＤＣＩ（Downlink Control Information）、ＵＣＩ（Uplink Control Information））、上位レイヤシグナリング（例えば、ＲＲＣ（Radio Resource Control）シグナリング、ＭＡＣ（Medium Access Control）シグナリング、報知情報（ＭＩＢ（Master Information Block）、ＳＩＢ（System Information Block））、その他の信号又はこれらの組み合わせによって実施されてもよい。また、ＲＲＣシグナリングは、ＲＲＣメッセージと呼ばれてもよく、例えば、ＲＲＣ接続セットアップ（RRC Connection Setup）メッセージ、ＲＲＣ接続再構成（RRC Connection Reconfiguration）メッセージ等であってもよい。

本開示において説明した各態様／実施形態は、ＬＴＥ（Long Term Evolution）、ＬＴＥ－Ａ（LTE-Advanced）、ＳＵＰＥＲ３Ｇ、ＩＭＴ－Ａｄｖａｎｃｅｄ、４Ｇ（4th generation mobile communication system）、５Ｇ（5th generation mobile communication system）、6th generation mobile communication system（６Ｇ）、xth generation mobile communication system（ｘＧ）（ｘＧ（ｘは、例えば整数、小数））、ＦＲＡ（Future Radio Access）、ＮＲ（new Radio）、New radio access（ＮＸ）、Future generation radio access（ＦＸ）、Ｗ－ＣＤＭＡ（登録商標）、ＧＳＭ（登録商標）、ＣＤＭＡ２０００、ＵＭＢ（Ultra Mobile Broadband）、ＩＥＥＥ８０２．１１（Ｗｉ－Ｆｉ（登録商標））、ＩＥＥＥ８０２．１６（ＷｉＭＡＸ（登録商標））、ＩＥＥＥ８０２．２０、ＵＷＢ（Ultra-WideBand）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、その他の適切なシステムを利用するシステム及びこれらに基づいて拡張、修正、作成、規定された次世代システムの少なくとも一つに適用されてもよい。また、複数のシステムが組み合わされて（例えば、ＬＴＥ及びＬＴＥ－Ａの少なくとも一方と５Ｇとの組み合わせ等）適用されてもよい。

本明細書で説明した各態様／実施形態の処理手順、シーケンス、フローチャート等は、矛盾の無い限り、順序を入れ替えてもよい。例えば、本開示において説明した方法については、例示的な順序を用いて様々なステップの要素を提示しており、提示した特定の順序に限定されない。

本明細書において基地局１０によって行われるとした特定動作は、場合によってはその上位ノード（upper node）によって行われることもある。基地局１０を有する１つ又は複数のネットワークノード（network nodes）からなるネットワークにおいて、端末２０との通信のために行われる様々な動作は、基地局１０及び基地局１０以外の他のネットワークノード（例えば、ＭＭＥ又はＳ－ＧＷ等が考えられるが、これらに限られない）の少なくとも１つによって行われ得ることは明らかである。上記において基地局１０以外の他のネットワークノードが１つである場合を例示したが、他のネットワークノードは、複数の他のネットワークノードの組み合わせ（例えば、ＭＭＥ及びＳ－ＧＷ）であってもよい。

本開示において説明した情報又は信号等は、上位レイヤ（又は下位レイヤ）から下位レイヤ（又は上位レイヤ）へ出力され得る。複数のネットワークノードを介して入出力されてもよい。

入出力された情報等は特定の場所（例えば、メモリ）に保存されてもよいし、管理テーブルを用いて管理してもよい。入出力される情報等は、上書き、更新、又は追記され得る。出力された情報等は削除されてもよい。入力された情報等は他の装置へ送信されてもよい。

本開示における判定は、１ビットで表される値（０か１か）によって行われてもよいし、真偽値（Boolean：true又はfalse）によって行われてもよいし、数値の比較（例えば、所定の値との比較）によって行われてもよい。

ソフトウェアは、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語と呼ばれるか、他の名称で呼ばれるかを問わず、命令、命令セット、コード、コードセグメント、プログラムコード、プログラム、サブプログラム、ソフトウェアモジュール、アプリケーション、ソフトウェアアプリケーション、ソフトウェアパッケージ、ルーチン、サブルーチン、オブジェクト、実行可能ファイル、実行スレッド、手順、機能などを意味するよう広く解釈されるべきである。

また、ソフトウェア、命令、情報などは、伝送媒体を介して送受信されてもよい。例えば、ソフトウェアが、有線技術（同軸ケーブル、光ファイバケーブル、ツイストペア、デジタル加入者回線（ＤＳＬ：Digital Subscriber Line）など）及び無線技術（赤外線、マイクロ波など）の少なくとも一方を使用してウェブサイト、サーバ、又は他のリモートソースから送信される場合、これらの有線技術及び無線技術の少なくとも一方は、伝送媒体の定義内に含まれる。

本開示において説明した情報、信号などは、様々な異なる技術のいずれかを使用して表されてもよい。例えば、上記の説明全体に渡って言及され得るデータ、命令、コマンド、情報、信号、ビット、シンボル、チップなどは、電圧、電流、電磁波、磁界若しくは磁性粒子、光場若しくは光子、又はこれらの任意の組み合わせによって表されてもよい。

なお、本開示において説明した用語及び本開示の理解に必要な用語については、同一の又は類似する意味を有する用語と置き換えてもよい。例えば、チャネル及びシンボルの少なくとも一方は信号（シグナリング）であってもよい。また、信号はメッセージであってもよい。また、コンポーネントキャリア（ＣＣ：Component Carrier）は、キャリア周波数、セル、周波数キャリアなどと呼ばれてもよい。

本開示において使用する「システム」及び「ネットワーク」という用語は、互換的に使用される。

また、本開示において説明した情報、パラメータなどは、絶対値を用いて表されてもよいし、所定の値からの相対値を用いて表されてもよいし、対応する別の情報を用いて表されてもよい。例えば、無線リソースはインデックスによって指示されるものであってもよい。

上述したパラメータに使用する名称はいかなる点においても限定的な名称ではない。さらに、これらのパラメータを使用する数式等は、本開示で明示的に開示したものと異なる場合もある。様々なチャネル（例えば、ＰＵＣＣＨ、ＰＤＣＣＨなど）及び情報要素は、あらゆる好適な名称によって識別できるので、これらの様々なチャネル及び情報要素に割り当てている様々な名称は、いかなる点においても限定的な名称ではない。

本開示においては、「基地局（ＢＳ：Base Station）」、「無線基地局」、「基地局」、「固定局（fixed station）」、「ＮｏｄｅＢ」、「ｅＮｏｄｅＢ（ｅＮＢ）」、「ｇＮｏｄｅＢ（ｇＮＢ）」、「アクセスポイント（access point）」、「送信ポイント（transmission point）」、「受信ポイント（reception point）、「送受信ポイント（transmission/reception point）」、「セル」、「セクタ」、「セルグループ」、「キャリア」、「コンポーネントキャリア」などの用語は、互換的に使用され得る。基地局は、マクロセル、スモールセル、フェムトセル、ピコセルなどの用語で呼ばれる場合もある。

基地局は、１つ又は複数（例えば、３つ）のセルを収容することができる。基地局が複数のセルを収容する場合、基地局のカバレッジエリア全体は複数のより小さいエリアに区分でき、各々のより小さいエリアは、基地局サブシステム（例えば、屋内用の小型基地局（ＲＲＨ：ＲｅｍｏｔｅＲａｄｉｏＨｅａｄ）によって通信サービスを提供することもできる。「セル」又は「セクタ」という用語は、このカバレッジにおいて通信サービスを行う基地局及び基地局サブシステムの少なくとも一方のカバレッジエリアの一部又は全体を指す。

本開示においては、「移動局（ＭＳ：Mobile Station）」、「ユーザ端末（user terminal）」、「ユーザ装置（ＵＥ：User Equipment）」、「端末」などの用語は、互換的に使用され得る。

移動局は、当業者によって、加入者局、モバイルユニット、加入者ユニット、ワイヤレスユニット、リモートユニット、モバイルデバイス、ワイヤレスデバイス、ワイヤレス通信デバイス、リモートデバイス、モバイル加入者局、アクセス端末、モバイル端末、ワイヤレス端末、リモート端末、ハンドセット、ユーザエージェント、モバイルクライアント、クライアント、又はいくつかの他の適切な用語で呼ばれる場合もある。

基地局及び移動局の少なくとも一方は、送信装置、受信装置、通信装置などと呼ばれてもよい。なお、基地局及び移動局の少なくとも一方は、移動体に搭載されたデバイス、移動体自体などであってもよい。当該移動体は、乗り物（例えば、車、飛行機など）であってもよいし、無人で動く移動体（例えば、ドローン、自動運転車など）であってもよいし、ロボット（有人型又は無人型）であってもよい。なお、基地局及び移動局の少なくとも一方は、必ずしも通信動作時に移動しない装置も含む。例えば、基地局及び移動局の少なくとも一方は、センサなどのＩｏＴ（Internet of Things）機器であってもよい。

また、本開示における基地局は、ユーザ端末で読み替えてもよい。例えば、基地局及びユーザ端末間の通信を、複数の端末２０間の通信（例えば、Ｄ２Ｄ（Device-to-Device）、Ｖ２Ｘ（Vehicle-to-Everything）などと呼ばれてもよい）に置き換えた構成について、本開示の各態様／実施形態を適用してもよい。この場合、上述の基地局１０が有する機能を端末２０が有する構成としてもよい。また、「上り」及び「下り」などの文言は、端末間通信に対応する文言（例えば、「サイド（side）」）で読み替えられてもよい。例えば、上りチャネル、下りチャネルなどは、サイドチャネルで読み替えられてもよい。

同様に、本開示におけるユーザ端末は、基地局で読み替えてもよい。この場合、上述のユーザ端末が有する機能を基地局が有する構成としてもよい。

本開示で使用する「判断(determining)」、「決定(determining)」という用語は、多種多様な動作を包含する場合がある。「判断」、「決定」は、例えば、判定(judging)、計算(calculating)、算出(computing)、処理(processing)、導出(deriving)、調査(investigating)、探索(looking up、search、inquiry)（例えば、テーブル、データベース又は別のデータ構造での探索）、確認(ascertaining)した事を「判断」「決定」したとみなす事などを含み得る。また、「判断」、「決定」は、受信(receiving)（例えば、情報を受信すること）、送信(transmitting)(例えば、情報を送信すること)、入力(input)、出力(output)、アクセス(accessing)（例えば、メモリ中のデータにアクセスすること）した事を「判断」「決定」したとみなす事などを含み得る。また、「判断」、「決定」は、解決(resolving)、選択(selecting)、選定(choosing)、確立(establishing)、比較(comparing)などした事を「判断」「決定」したとみなす事を含み得る。つまり、「判断」「決定」は、何らかの動作を「判断」「決定」したとみなす事を含み得る。また、「判断（決定）」は、「想定する（assuming）」、「期待する（expecting）」、「みなす（considering）」などで読み替えられてもよい。

「接続された(connected)」、「結合された(coupled)」という用語、又はこれらのあらゆる変形は、２又はそれ以上の要素間の直接的又は間接的なあらゆる接続又は結合を意味し、互いに「接続」又は「結合」された２つの要素間に１又はそれ以上の中間要素が存在することを含むことができる。要素間の結合又は接続は、物理的なものであっても、論理的なものであっても、或いはこれらの組み合わせであってもよい。例えば、「接続」は「アクセス」で読み替えられてもよい。本開示で使用する場合、２つの要素は、１又はそれ以上の電線、ケーブル及びプリント電気接続の少なくとも一つを用いて、並びにいくつかの非限定的かつ非包括的な例として、無線周波数領域、マイクロ波領域及び光（可視及び不可視の両方）領域の波長を有する電磁エネルギーなどを用いて、互いに「接続」又は「結合」されると考えることができる。

参照信号は、ＲＳ（Reference Signal）と略称することもでき、適用される標準によってパイロット（Pilot）と呼ばれてもよい。

本開示において使用する「に基づいて」という記載は、別段に明記されていない限り、「のみに基づいて」を意味しない。言い換えれば、「に基づいて」という記載は、「のみに基づいて」と「に少なくとも基づいて」の両方を意味する。

本開示において使用する「第１の」、「第２の」などの呼称を使用した要素へのいかなる参照も、それらの要素の量又は順序を全般的に限定しない。これらの呼称は、２つ以上の要素間を区別する便利な方法として本開示において使用され得る。したがって、第１及び第２の要素への参照は、２つの要素のみが採用され得ること、又は何らかの形で第１の要素が第２の要素に先行しなければならないことを意味しない。

上記の各装置の構成における「手段」を、「部」、「回路」、「デバイス」等に置き換えてもよい。

本開示において、「含む（include）」、「含んでいる（including）」及びそれらの変形が使用されている場合、これらの用語は、用語「備える（comprising）」と同様に、包括的であることが意図される。さらに、本開示において使用されている用語「又は（or）」は、排他的論理和ではないことが意図される。

無線フレームは時間領域において１つ又は複数のフレームによって構成されてもよい。時間領域において１つ又は複数の各フレームはサブフレームと呼ばれてもよい。サブフレームは更に時間領域において１つ又は複数のスロットによって構成されてもよい。サブフレームは、ニューメロロジ（numerology）に依存しない固定の時間長（例えば、１ｍｓ）であってもよい。

ニューメロロジは、ある信号又はチャネルの送信及び受信の少なくとも一方に適用される通信パラメータであってもよい。ニューメロロジは、例えば、サブキャリア間隔（ＳＣＳ：SubCarrier Spacing）、帯域幅、シンボル長、サイクリックプレフィックス長、送信時間間隔（ＴＴＩ：Transmission Time Interval）、ＴＴＩあたりのシンボル数、無線フレーム構成、送受信機が周波数領域において行う特定のフィルタリング処理、送受信機が時間領域において行う特定のウィンドウイング処理などの少なくとも１つを示してもよい。

スロットは、時間領域において１つ又は複数のシンボル（ＯＦＤＭ（Orthogonal Frequency Division Multiplexing）シンボル、ＳＣ-ＦＤＭＡ（Single Carrier Frequency Division Multiple Access）シンボル等）で構成されてもよい。スロットは、ニューメロロジに基づく時間単位であってもよい。

スロットは、複数のミニスロットを含んでもよい。各ミニスロットは、時間領域において１つ又は複数のシンボルによって構成されてもよい。また、ミニスロットは、サブスロットと呼ばれてもよい。ミニスロットは、スロットよりも少ない数のシンボルによって構成されてもよい。ミニスロットより大きい時間単位で送信されるＰＤＳＣＨ（又はＰＵＳＣＨ）は、ＰＤＳＣＨ（又はＰＵＳＣＨ）マッピングタイプＡと呼ばれてもよい。ミニスロットを用いて送信されるＰＤＳＣＨ（又はＰＵＳＣＨ）は、ＰＤＳＣＨ（又はＰＵＳＣＨ）マッピングタイプＢと呼ばれてもよい。

無線フレーム、サブフレーム、スロット、ミニスロット及びシンボルは、いずれも信号を伝送する際の時間単位を表す。無線フレーム、サブフレーム、スロット、ミニスロット及びシンボルは、それぞれに対応する別の呼称が用いられてもよい。

例えば、１サブフレームは送信時間間隔（ＴＴＩ：Transmission Time Interval）と呼ばれてもよいし、複数の連続したサブフレームがＴＴＩと呼ばれてよいし、１スロット又は１ミニスロットがＴＴＩと呼ばれてもよい。つまり、サブフレーム及びＴＴＩの少なくとも一方は、既存のＬＴＥにおけるサブフレーム（１ｍｓ）であってもよいし、１ｍｓより短い期間（例えば、１－１３シンボル）であってもよいし、１ｍｓより長い期間であってもよい。なお、ＴＴＩを表す単位は、サブフレームではなくスロット、ミニスロットなどと呼ばれてもよい。

ここで、ＴＴＩは、例えば、無線通信におけるスケジューリングの最小時間単位のことをいう。例えば、ＬＴＥシステムでは、基地局が各端末２０に対して、無線リソース（各端末２０において使用することが可能な周波数帯域幅、送信電力など）を、ＴＴＩ単位で割り当てるスケジューリングを行う。なお、ＴＴＩの定義はこれに限られない。

ＴＴＩは、チャネル符号化されたデータパケット（トランスポートブロック）、コードブロック、コードワードなどの送信時間単位であってもよいし、スケジューリング、リンクアダプテーションなどの処理単位となってもよい。なお、ＴＴＩが与えられたとき、実際にトランスポートブロック、コードブロック、コードワードなどがマッピングされる時間区間（例えば、シンボル数）は、当該ＴＴＩよりも短くてもよい。

なお、１スロット又は１ミニスロットがＴＴＩと呼ばれる場合、１以上のＴＴＩ（すなわち、１以上のスロット又は１以上のミニスロット）が、スケジューリングの最小時間単位となってもよい。また、当該スケジューリングの最小時間単位を構成するスロット数（ミニスロット数）は制御されてもよい。

１ｍｓの時間長を有するＴＴＩは、通常ＴＴＩ（ＬＴＥＲｅｌ．８－１２におけるＴＴＩ）、ノーマルＴＴＩ、ロングＴＴＩ、通常サブフレーム、ノーマルサブフレーム、ロングサブフレーム、スロットなどと呼ばれてもよい。通常ＴＴＩより短いＴＴＩは、短縮ＴＴＩ、ショートＴＴＩ、部分ＴＴＩ（partial又はfractional TTI）、短縮サブフレーム、ショートサブフレーム、ミニスロット、サブスロット、スロットなどと呼ばれてもよい。

なお、ロングＴＴＩ（例えば、通常ＴＴＩ、サブフレームなど）は、１ｍｓを超える時間長を有するＴＴＩで読み替えてもよいし、ショートＴＴＩ（例えば、短縮ＴＴＩなど）は、ロングＴＴＩのＴＴＩ長未満かつ１ｍｓ以上のＴＴＩ長を有するＴＴＩで読み替えてもよい。

リソースブロック（ＲＢ）は、時間領域及び周波数領域のリソース割当単位であり、周波数領域において、１つ又は複数個の連続した副搬送波（subcarrier）を含んでもよい。ＲＢに含まれるサブキャリアの数は、ニューメロロジに関わらず同じであってもよく、例えば１２であってもよい。ＲＢに含まれるサブキャリアの数は、ニューメロロジに基づいて決定されてもよい。

また、ＲＢの時間領域は、１つ又は複数個のシンボルを含んでもよく、１スロット、１ミニスロット、１サブフレーム、又は１ＴＴＩの長さであってもよい。１ＴＴＩ、１サブフレームなどは、それぞれ１つ又は複数のリソースブロックで構成されてもよい。

なお、１つ又は複数のＲＢは、物理リソースブロック（ＰＲＢ：Physical RB）、サブキャリアグループ（ＳＣＧ：Sub-Carrier Group）、リソースエレメントグループ（ＲＥＧ：Resource Element Group）、ＰＲＢペア、ＲＢペアなどと呼ばれてもよい。

また、リソースブロックは、１つ又は複数のリソースエレメント（ＲＥ：Resource Element）によって構成されてもよい。例えば、１ＲＥは、１サブキャリア及び１シンボルの無線リソース領域であってもよい。

帯域幅部分（ＢＷＰ：Bandwidth Part）（部分帯域幅などと呼ばれてもよい）は、あるキャリアにおいて、あるニューメロロジ用の連続する共通ＲＢ（common resource blocks）のサブセットのことを表してもよい。ここで、共通ＲＢは、当該キャリアの共通参照ポイントを基準としたＲＢのインデックスによって特定されてもよい。ＰＲＢは、あるＢＷＰで定義され、当該ＢＷＰ内で番号付けされてもよい。

ＢＷＰには、ＵＬ用のＢＷＰ（ＵＬＢＷＰ）と、ＤＬ用のＢＷＰ（ＤＬＢＷＰ）とが含まれてもよい。端末２０に対して、１キャリア内に１つ又は複数のＢＷＰが設定されてもよい。

設定されたＢＷＰの少なくとも１つがアクティブであってもよく、端末２０は、アクティブなＢＷＰの外で所定の信号／チャネルを送受信することを想定しなくてもよい。なお、本開示における「セル」、「キャリア」などは、「ＢＷＰ」で読み替えられてもよい。

上述した無線フレーム、サブフレーム、スロット、ミニスロット及びシンボルなどの構造は例示に過ぎない。例えば、無線フレームに含まれるサブフレームの数、サブフレーム又は無線フレームあたりのスロットの数、スロット内に含まれるミニスロットの数、スロット又はミニスロットに含まれるシンボル及びＲＢの数、ＲＢに含まれるサブキャリアの数、並びにＴＴＩ内のシンボル数、シンボル長、サイクリックプレフィックス（ＣＰ：Cyclic Prefix）長などの構成は、様々に変更することができる。

本開示において、例えば、英語でのa, an及びtheのように、翻訳により冠詞が追加された場合、本開示は、これらの冠詞の後に続く名詞が複数形であることを含んでもよい。

本開示において、「ＡとＢが異なる」という用語は、「ＡとＢが互いに異なる」ことを意味してもよい。なお、当該用語は、「ＡとＢがそれぞれＣと異なる」ことを意味してもよい。「離れる」、「結合される」などの用語も、「異なる」と同様に解釈されてもよい。

本開示において説明した各態様／実施形態は単独で用いられてもよいし、組み合わせて用いられてもよいし、実行に伴って切り替えて用いられてもよい。また、所定の情報の通知（例えば、「Ｘであること」の通知）は、明示的に行うものに限られず、暗黙的（例えば、当該所定の情報の通知を行わない）ことによって行われてもよい。

以上、本開示について詳細に説明したが、当業者にとっては、本開示が本開示中に説明した実施形態に限定されるものではないということは明らかである。本開示は、請求の範囲の記載により定まる本開示の趣旨及び範囲を逸脱することなく修正及び変更態様として実施することができる。したがって、本開示の記載は、例示説明を目的とするものであり、本開示に対して何ら制限的な意味を有するものではない。

１０基地局
１１０送信部
１２０受信部
１３０設定部
１４０制御部
２０端末
２１０送信部
２２０受信部
２３０設定部
２４０制御部
１００１プロセッサ
１００２記憶装置
１００３補助記憶装置
１００４通信装置
１００５入力装置
１００６出力装置

Claims

他の端末から、推奨されるリソースセットを受信する受信部と、
前記推奨されるリソースセットに基づくリソースと物理レイヤにより示されるリソースとに共通するリソースから送信リソースを選択する制御部と、を備え、
前記制御部は、前記推奨されるリソースセットに基づくリソースと前記物理レイヤにより示されるリソースとに共通するリソースの数が所定の数未満である場合、前記推奨されるリソースセットに基づくリソース以外のリソースから前記送信リソースを選択する、端末。
前記物理レイヤにより示されるリソースは、候補リソースから、前記他の端末からの信号に対する受信電力の測定に基づくリソースが除外されたリソースである、請求項１に記載の端末。
前記受信部は、推奨されないリソースセットを受信し、
前記制御部は、前記推奨されないリソースセットに基づくリソースを、前記物理レイヤにより示されるリソースから除外する、請求項１に記載の端末。
前記制御部は、前記物理レイヤにより示されるリソースから前記推奨されないリソースセットに基づくリソースが除外された残りのリソースの数が第２の所定の数以上ではない場合、前記推奨されないリソースセットに基づくリソースと重複する前記物理レイヤにより示されるリソースから、前記送信リソースを選択する、請求項３に記載の端末。
端末により実行される通信方法であって、
他の端末から、推奨されるリソースセットを受信するステップと、
前記推奨されるリソースセットに基づくリソースと物理レイヤにより示されるリソースとに共通するリソースから送信リソースを選択するステップと、を備え、
前記選択するステップは、前記推奨されるリソースセットに基づくリソースと前記物理レイヤにより示されるリソースとに共通するリソースの数が所定の数未満である場合、前記推奨されるリソースセットに基づくリソース以外のリソースから前記送信リソースを選択する、通信方法。