(57)【要約】Ｄ２Ｄをサポートするユーザ装置であって、予約されたリソースでＤ２Ｄ信号を送信する第一の送信部と、前記予約されたリソースでＤ２Ｄ信号が送信される前に、前記予約されたリソースでＤ２Ｄ信号を送信することを他のユーザ装置に通知するための確認情報を送信する第二の送信部と、を有するユーザ装置を提供する。
2017195538.tif 000002
【特許請求の範囲】
【請求項１】
Ｄ２Ｄをサポートするユーザ装置であって、
予約されたリソースでＤ２Ｄ信号を送信する第一の送信部と、
前記予約されたリソースでＤ２Ｄ信号が送信される前に、前記予約されたリソースでＤ２Ｄ信号を送信することを他のユーザ装置に通知するための確認情報を送信する第二の送信部と、
を有するユーザ装置。
【請求項２】
前記予約されたリソースでＤ２Ｄ信号を送信することを通知する確認情報を他のユーザ装置から受信した場合、前記予約されたリソースとは異なるリソースを選択する選択部、を有し、
前記第一の送信部は、前記予約されたリソースでＤ２Ｄ信号を送信せずに、前記選択部で選択された、前記予約されたリソースとは異なるリソースでＤ２Ｄ信号を送信する、
請求項１に記載のユーザ装置。
【請求項３】
Ｄ２Ｄ信号に格納するデータを生成する生成部、を有し、
前記選択部は、前記生成部で生成された前記Ｄ２Ｄ信号に格納するデータを、前記予約されたリソースに対応づけられる所定の期間以外の期間に前記第一の送信部が受信したことを検出した場合に、前記予約されたリソースとは異なるリソースを選択し、
前記第一の送信部は、前記生成部で生成された前記Ｄ２Ｄ信号に格納するデータを含むＤ２Ｄ信号を前記予約されたリソースで送信せずに、前記選択部で選択された、前記予約されたリソースとは異なるリソースで送信する、
請求項２に記載のユーザ装置。
【請求項４】
前記第二の送信部は、前記予約されたリソースを予約する際の予約情報との対応づけを示す情報、又は、前記予約されたリソースの時間リソース及び周波数リソースを示す情報を前記確認情報に含めて送信する、
請求項１乃至３のいずれか一項に記載のユーザ装置。
【請求項５】
前記第二の送信部は、前記確認情報を、前記予約されたリソースのサブフレームより前のサブフレームであって予め定められたサブフレームで送信する、
請求項１乃至４のいずれか一項に記載のユーザ装置。
【請求項６】
Ｄ２Ｄをサポートするユーザ装置が実行する信号送信方法であって、
予約されたリソースでＤ２Ｄ信号を送信するステップと、
前記予約されたリソースでＤ２Ｄ信号が送信される前に、前記予約されたリソースでＤ２Ｄ信号を送信することを他のユーザ装置に通知するための確認情報を送信するステップと、
を有する信号送信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユーザ装置及び信号送信方法に関する。
【背景技術】
【０００２】
ＬＴＥ（Long Term Evolution）及びＬＴＥの後継システム（例えば、ＬＴＥ−Ａ（LTE Advanced）、４Ｇ、ＦＲＡ（Future Radio Access）、５Ｇなどともいう）では、ユーザ装置同士が無線基地局を介さないで直接通信を行うＤ２Ｄ（Device to Device）技術が検討されている（例えば、非特許文献１）。【０００３】
Ｄ２Ｄは、ユーザ装置と基地局との間のトラヒックを軽減したり、災害時などに基地局が通信不能になった場合でもユーザ装置間の通信を可能とする。【０００４】
Ｄ２Ｄは、通信可能な他のユーザ装置を見つけ出すためのＤ２Ｄディスカバリ（D2D discovery、Ｄ２Ｄ発見ともいう）と、ユーザ装置間で直接通信するためのＤ２Ｄコミュニケーション（D2D direct communication、Ｄ２Ｄ通信、端末間直接通信などともいう）と、に大別される。以下では、Ｄ２Ｄコミュニケーション、Ｄ２Ｄディスカバリなどを特に区別しないときは、単にＤ２Ｄと呼ぶ。また、Ｄ２Ｄで送受信される信号を、Ｄ２Ｄ信号と呼ぶ。【０００５】
また、３ＧＰＰ（3rd Generation Partnership Project）では、Ｄ２Ｄ機能を拡張することでＶ２Ｘを実現することが検討されている。ここで、Ｖ２Ｘとは、ＩＴＳ（Intelligent Transport Systems）の一部であり、図１に示すように、自動車間で行われる通信形態を意味するＶ２Ｖ（Vehicle to Vehicle）、自動車と道路脇に設置される路側機（ＲＳＵ：Road-Side Unit）との間で行われる通信形態を意味するＶ２Ｉ（Vehicle to Infrastructure）、自動車とドライバーのモバイル端末との間で行われる通信形態を意味するＶ２Ｎ（Vehicle to Nomadic device）、及び、自動車と歩行者のモバイル端末との間で行われる通信形態を意味するＶ２Ｐ（Vehicle to Pedestrian）の総称である。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】"Key drivers for LTE success:Services Evolution"、２０１１年９月、3GPP、インターネットURL：http://www.3gpp.org/ftp/Information/presentations/presentations_2011/2011_09_LTE_Asia/2011_LTE-Asia_3GPP_Service_evolution.pdf
【非特許文献２】３ＧＰＰ  ＴＳ３６．３００  Ｖ１３．２．０（２０１５−１２）
【発明の概要】
【発明が解決しようとする課題】
【０００７】
Ｖ２Ｘの技術は、ＬＴＥで規定されているＤ２Ｄの技術をベースとしている。当該Ｄ２Ｄの技術において、ユーザ装置がＤ２Ｄ信号を送信するリソースを選択する方式として、大別して、基地局からダイナミックにリソースを割り当てる方式と、ユーザ装置が自律的にリソースを選択する方式がある。Ｖ２Ｘ、特に、Ｖ２Ｖでは、ユーザ装置（例：自動車）は高密度に存在し、高速に移動するので、ダイナミックにリソースを割り当てる方式では非効率であることから、ユーザ装置が自律的にリソースを選択する方式が用いられることが想定される。【０００８】
また、Ｖ２Ｘでは、ユーザ装置は、将来の送信リソースを自律的に選択及び予約し、予約したリソースを使用してＤ２Ｄ信号を送信することが提案されている。【０００９】
また、複数のユーザ装置が自律的にリソースを選択及び予約する際に、各ユーザ装置が自由にリソースを選択及び予約するとなると、リソースの衝突が生じ、受信側のユーザ装置は信号を適切に受信できなくなる。そこで、リソースのセンシングを行って、使用ないし予約（占有：ｏｃｃｕｐｉｅｄ）されていないリソースを選択及び予約するセンシングベースのリソース選択方式が提案されている。【００１０】
ここで、Ｖ２Ｘでは、１００ｍｓ周期でデータの送信が行われることが想定されているが、例えば緊急度の高いデータ（例えば事故を知らせるデータなど）が発生した場合など、１００ｍｓ周期よりも短い間隔で送信すべきデータが生じることも想定される。【００１１】
図２は、課題を説明するための図である。図２は、ユーザ装置が備えるＶ２Ｘアプリケーションで生成されたＶ２Ｘデータが約１００ｍｓ周期で物理レイヤに到着し、１００ｍｓの周期で予約されたリソースでＶ２Ｘデータを含むＤ２Ｄ信号が送信される様子を示している。基本的には、物理レイヤに到着したＶ２Ｘデータ（Ｄ１、Ｄ２、Ｄ３、Ｄ４、Ｄ５）は、それぞれ予約されたリソース（Ｒ１、Ｒ２、Ｒ３、Ｒ４、Ｒ５）で送信されることになる。ここで、例えば、事故を知らせるデータが生じた場合など、Ｖ２Ｘデータ（Ｄ３）が１００ｍｓ周期とは大きく異なるタイミングで物理レイヤに到着した場合、Ｖ２Ｘデータ（Ｄ３）を周期的なリソース（Ｒ３）で送信しようとすると遅延が大きくなってしまう。従って、このような状況を回避するため、ユーザ装置ＵＥは、周期的なリソースを予め大量に選択及び予約しておき、実際には予約したリソースの一部のみを用いてＶ２Ｘデータを含むＤ２Ｄ信号を送信するように動作することが想定される。【００１２】
しかしながら、Ｖ２Ｘでは、多数のユーザ装置ＵＥが存在する環境が想定されていることから、各ユーザ装置ＵＥがリソースを大量に選択及び予約してしまうと、実際にはＤ２Ｄ信号が送信されないリソースが大量に生じてしまうことになる。【００１３】
また、Ｖ２Ｘでは、ユーザ装置は、必ずしも予約されたリソースを全て用いてＤ２Ｄ信号を送信するとは限らない。Ｖ２Ｘでは、１００ｍｓ周期でデータの送信が行われることが想定されているが、ユーザ装置は必ず１００ｍｓでデータを送信するのではなく、とびとびにデータを送信することも想定される。このような場合も、実際にはＤ２Ｄ信号が送信されないリソースが生じてしまうことになる。【００１４】
このような問題を解決するためには、各ユーザ装置が、自由に周期的なリソースの選択及び予約を行いつつ、実際に使用するリソースを他のユーザ装置に通知する仕組みが必要であると考えられる。しかしながら、３ＧＰＰでは、実際に使用するリソースを他のユーザ装置に通知する仕組みは規定されていない。【００１５】
なお、Ｖ２ＸはＤ２Ｄの一種であると考えると、上記のような課題はＶ２Ｘに限らず、Ｄ２Ｄ全般に生じ得る課題である。また、上りの衝突型アクセスにおいてもユーザ装置は送信が許可されたリソースのすべてにおいて送信を行うとは限らず、同様の課題が生じ得る。【００１６】
開示の技術は上記に鑑みてなされたものであって、ユーザ装置が実際にＤ２Ｄ信号の送信に用いるリソースを他のユーザ装置に通知することを可能にする技術を提供することを目的とする。
【課題を解決するための手段】
【００１７】
開示の技術のユーザ装置は、Ｄ２Ｄをサポートするユーザ装置であって、予約されたリソースでＤ２Ｄ信号を送信する第一の送信部と、前記予約されたリソースでＤ２Ｄ信号が送信される前に、前記予約されたリソースでＤ２Ｄ信号を送信することを他のユーザ装置に通知するための確認情報を送信する第二の送信部と、を有する。
【発明の効果】
【００１８】
開示の技術によれば、ユーザ装置が実際にＤ２Ｄ信号の送信に用いるリソースを他のユーザ装置に通知することを可能にする技術が提供される。
【図面の簡単な説明】
【００１９】
【図１】Ｖ２Ｘを説明するための図である。
【図２】課題を説明するための図である。
【図３】Ｄ２Ｄを説明するための図である。
【図４】Ｄ２Ｄ通信に用いられるＭＡＣ  ＰＤＵを説明するための図である。
【図５】ＳＬ−ＳＣＨ  ｓｕｂｈｅａｄｅｒのフォーマットを説明するための図である。
【図６】Ｄ２Ｄで使用されるチャネル構造の例を説明するための図である。
【図７】ＰＳＤＣＨの構造例を示す図である。
【図８】ＰＳＣＣＨとＰＳＳＣＨの構造例を示す図である。
【図９】リソースプールコンフィギュレーションを示す図である。
【図１０】実施の形態に係る無線通信システムの構成例を示す図である。
【図１１】実施の形態に係るユーザ装置の動作の概要を説明するための図である。
【図１２】ユーザ装置が確認情報及びＤ２Ｄ信号を送信する際の動作例を説明するための図である。
【図１３】ユーザ装置が確認情報及びＤ２Ｄ信号を送信する際の動作例を説明するための図である。
【図１４】ユーザ装置がリソースを選択する際の動作の具体例を説明するための図である。
【図１５】確認情報を送信可能なサブフレームを限定する方法を説明するための図である。
【図１６】実施の形態に係るユーザ装置の機能構成の一例を示す図である。
【図１７】実施の形態に係る基地局の機能構成の一例を示す図である。
【図１８】実施の形態に係る基地局及びユーザ装置のハードウェア構成の一例を示す図である。
【発明を実施するための形態】
【００２０】
以下、図面を参照して本発明の実施の形態を説明する。なお、以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。例えば、本実施の形態に係る無線通信システムはＬＴＥに準拠した方式のシステムを想定しているが、本発明はＬＴＥに限定されるわけではなく、他の方式にも適用可能である。なお、本明細書及び特許請求の範囲において、「ＬＴＥ」は、３ＧＰＰのリリース８、又は９に対応する通信方式のみならず、３ＧＰＰのリリース１０、１１、１２、１３、又はリリース１４以降に対応する第５世代の通信方式も含む広い意味で使用する。
【００２１】
また、本実施の形態は、主にＶ２Ｘを対象としているが、本実施の形態に係る技術は、Ｖ２Ｘに限らず、広くＤ２Ｄ全般に適用可能である。また、「Ｄ２Ｄ」はその意味としてＶ２Ｘを含むものである。
【００２２】
また、「Ｄ２Ｄ」は、ユーザ装置ＵＥ間でＤ２Ｄ信号を送受信する処理手順のみならず、Ｄ２Ｄ信号を基地局が受信（モニタ）する処理手順、及び、ＲＲＣ  ｉｄｌｅの場合若しくは基地局ｅＮＢとコネクションを確立していない場合に、ユーザ装置ＵＥが基地局ｅＮＢに上り信号を送信する処理手順を含む広い意味で使用する。
【００２３】
＜Ｄ２Ｄの概要＞
まず、ＬＴＥで規定されているＤ２Ｄの概要について説明する。なお、Ｖ２Ｘにおいても、ここで説明するＤ２Ｄの技術を使用することは可能であり、本発明の実施の形態におけるユーザ装置ＵＥは、当該技術によるＤ２Ｄ信号の送受信を行うことができる。
【００２４】
既に説明したように、Ｄ２Ｄには、大きく分けて「Ｄ２Ｄディスカバリ」と「Ｄ２Ｄコミュニケーション」がある。「Ｄ２Ｄディスカバリ」については、図３（ａ）に示すように、Ｄｉｓｃｏｖｅｒｙ  ｐｅｒｉｏｄ（ＰＳＤＣＨ（Physical Sidelink Discovery Channel）  ｐｅｒｉｏｄとも呼ばれる）毎に、Ｄｉｓｃｏｖｅｒｙメッセージ用のリソースプールが確保され、ユーザ装置ＵＥはそのリソースプール内でＤｉｓｃｏｖｅｒｙメッセージ（発見信号）を送信する。より詳細にはＴｙｐｅ１、Ｔｙｐｅ２ｂがある。Ｔｙｐｅ１では、ユーザ装置ＵＥが自律的にリソースプールから送信リソースを選択する。Ｔｙｐｅ２ｂでは、上位レイヤシグナリング（例えばＲＲＣ信号）により準静的なリソースが割り当てられる。
【００２５】
「Ｄ２Ｄコミュニケーション」についても、図３（ｂ）に示すように、ＳＣＩ（Sidelink Control Information）／データ送信用のリソースプールが周期的に確保される。送信側のユーザ装置ＵＥはＣｏｎｔｒｏｌリソースプール（ＰＳＣＣＨ（Physical Sidelink Control Channel）リソースプール）から選択されたリソースでＳＣＩによりデータ送信用リソース等を受信側に通知し、当該データ送信用リソースでデータを送信する。「Ｄ２Ｄコミュニケーション」について、より詳細には、Ｍｏｄｅ１とＭｏｄｅ２がある。Ｍｏｄｅ１では、基地局ｅＮＢからユーザ装置ＵＥに送られる（Ｅ）ＰＤＣＣＨ（(Enhanced)Physical Downlink Control Channel）によりダイナミックにリソースが割り当てられる。Ｍｏｄｅ２では、ユーザ装置ＵＥはリソースプールから自律的に送信リソースを選択する。リソースプールについては、ＳＩＢ（System Information Block）で通知されたり、予め定義されたものが使用される。
【００２６】
ＬＴＥにおいて、「Ｄ２Ｄディスカバリ」に用いられるチャネルはＰＳＤＣＨと称され、「Ｄ２Ｄコミュニケーション」におけるＳＣＩ等の制御情報を送信するチャネルはＰＳＣＣＨと称され、データを送信するチャネルはＰＳＳＣＨ（Physical Sidelink Shared Channel）と称される。
【００２７】
Ｄ２Ｄ通信に用いられるＭＡＣ（Medium Access Control）ＰＤＵ（Protocol Data Unit）は、図４に示すように、少なくともＭＡＣ  ｈｅａｄｅｒ、ＭＡＣ  Ｃｏｎｔｒｏｌ  ｅｌｅｍｅｎｔ、ＭＡＣ  ＳＤＵ（Service Data Unit）、Ｐａｄｄｉｎｇで構成される。ＭＡＣ  ＰＤＵはその他の情報を含んでも良い。ＭＡＣ  ｈｅａｄｅｒは、１つのＳＬ−ＳＣＨ（Sidelink Shared Channel）ｓｕｂｈｅａｄｅｒと、１つ以上のＭＡＣ  ＰＤＵ  ｓｕｂｈｅａｄｅｒで構成される。
【００２８】
図５に示すように、ＳＬ−ＳＣＨ  ｓｕｂｈｅａｄｅｒは、ＭＡＣ  ＰＤＵフォーマットバージョン（Ｖ）、送信元情報（ＳＲＣ）、送信先情報（ＤＳＴ）、Ｒｅｓｅｒｖｅｄ  ｂｉｔ（Ｒ）等で構成される。Ｖは、ＳＬ−ＳＣＨ  ｓｕｂｈｅａｄｅｒの先頭に割り当てられ、ユーザ装置ＵＥが用いるＭＡＣ  ＰＤＵフォーマットバージョンを示す。送信元情報には、送信元に関する情報が設定される。送信元情報には、ＰｒｏＳｅ  ＵＥ  ＩＤに関する識別子が設定されてもよい。送信先情報には、送信先に関する情報が設定される。送信先情報には、送信先のＰｒｏＳｅ  Ｌａｙｅｒ−２  Ｇｒｏｕｐ  ＩＤに関する情報が設定されてもよい。
【００２９】
Ｄ２Ｄのチャネル構造の例を図６に示す。図６に示すように、「Ｄ２Ｄコミュニケーション」に使用されるＰＳＣＣＨのリソースプール及びＰＳＳＣＨのリソースプールが割り当てられている。また、「Ｄ２Ｄコミュニケーション」のチャネルの周期よりも長い周期で「Ｄ２Ｄディスカバリ」に使用されるＰＳＤＣＨのリソースプールが割り当てられている。
【００３０】
また、Ｄ２Ｄ用の同期信号としてＰＳＳＳ（Primary Sidelink Synchronization signal）とＳＳＳＳ（Secondary Sidelink Synchronization signal）が用いられる。また、例えばカバレッジ外動作のためにＤ２Ｄのシステム帯域、フレーム番号、リソース構成情報等の報知情報（broadcast information）を送信するＰＳＢＣＨ（Physical Sidelink Broadcast Channel）が用いられる。
【００３１】
図７（ａ）に、「Ｄ２Ｄディスカバリ」に使用されるＰＳＤＣＨのリソースプールの例を示す。リソースプールは、サブフレームのビットマップで設定されるため、図７（ａ）に示すようなイメージのリソースプールになる。他のチャネルのリソースプールも同様である。また、ＰＳＤＣＨは、周波数ホッピングしながら繰り返し送信（ｒｅｐｅｔｉｔｉｏｎ）がなされる。繰り返し回数は例えば０〜３で設定可能である。また、図７（ｂ）に示すように、ＰＳＤＣＨはＰＵＳＣＨベースの構造を有し、ＤＭ−ＲＳ（demodulation reference signal）が挿入される構造になっている。
【００３２】
図８（ａ）に、「Ｄ２Ｄコミュニケーション」に使用されるＰＳＣＣＨとＰＳＳＣＨのリソースプールの例を示す。図８（ａ）に示すとおり、ＰＳＣＣＨは、周波数ホッピングしながら、１回繰り返し送信（ｒｅｐｅｔｉｔｉｏｎ）がなされる。ＰＳＳＣＨは、周波数ホッピングしながら、３回繰り返し送信（ｒｅｐｅｔｉｔｉｏｎ）がなされる。また、図８（ｂ）に示すように、ＰＳＣＣＨとＰＳＳＣＨはＰＵＳＣＨベースの構造を有し、ＤＭＲＳが挿入される構造になっている。
【００３３】
図９に、ＰＳＣＣＨ、ＰＳＤＣＨ、ＰＳＳＣＨ（Ｍｏｄｅ２）におけるリソースプールコンフィギュレーションの例を示す。図９（ａ）に示すように、時間方向では、リソースプールはサブフレームビットマップとして表される。また、ビットマップは、ｎｕｍ．ｒｅｐｒｔｉｔｉｏｎの回数だけ繰り返される。また、各周期における開始位置を示すｏｆｆｓｅｔが指定される。
【００３４】
周波数方向では、連続割り当て（ｃｏｎｔｉｇｕｏｕｓ）と不連続割り当て（ｎｏｎ−ｃｏｎｔｉｇｕｏｕｓ）が可能である。図９（ｂ）は、不連続割り当ての例を示しており、図示のとおり、開始ＰＲＢ、終了ＰＲＢ、ＰＲＢ数（ｎｕｍＰＲＢ）が指定される。
【００３５】
＜システム構成＞
図１０は、実施の形態に係る無線通信システムの構成例を示す図である。図１０に示すように、本実施の形態に係る無線通信システムは、基地局ｅＮＢ、ユーザ装置ＵＥ１、及びユーザ装置ＵＥ２を有する。図１０において、ユーザ装置ＵＥ１は送信側、ユーザ装置ＵＥ２は受信側を意図しているが、ユーザ装置ＵＥ１とユーザ装置ＵＥ２はいずれも送信機能と受信機能の両方を備える。以下、ユーザ装置ＵＥ１とユーザ装置ＵＥ２を特に区別しない場合、単に「ユーザ装置ＵＥ」と記述する。
【００３６】
図１０に示すユーザ装置ＵＥ１及びユーザ装置ＵＥ２は、それぞれ、ＬＴＥにおけるユーザ装置ＵＥとしてのセルラ通信の機能、及び、上述したチャネルでの信号送受信を含むＤ２Ｄ機能を有している。また、ユーザ装置ＵＥ１、ユーザ装置ＵＥ２は、本実施の形態で説明する動作を実行する機能を有している。なお、セルラ通信の機能及び既存のＤ２Ｄの機能については、一部の機能（本実施の形態で説明する動作を実行できる範囲）のみを有していてもよいし、全ての機能を有していてもよい。
【００３７】
また、ユーザ装置ＵＥは、Ｄ２Ｄの機能を有するいかなる装置であってもよいが、例えば、ユーザ装置ＵＥは、車両、歩行者が保持する端末、ＲＳＵ（ＵＥの機能を有するＵＥタイプＲＳＵ）等である。
【００３８】
また、基地局ｅＮＢについては、ＬＴＥにおける基地局ｅＮＢとしてのセルラ通信の機能、及び、本実施の形態におけるユーザ装置ＵＥの通信を可能ならしめるための機能（設定情報通知機能等）を有している。また、基地局ｅＮＢはＲＳＵ（ｅＮＢの機能を有するｅＮＢタイプＲＳＵ）を含む。
【００３９】
以下の説明において、「センシング」とは、例えば、受信電力（受信エネルギ、又は受信強度と称してもよい）の測定結果を用いる方法、ＳＣＩのデコード結果を用いる方法（すなわち、他のユーザ装置ＵＥから送信されるＳＣＩを受信し、デコードすることで、他のユーザ装置ＵＥにより予約されているリソース位置を検知する方法）、又はこれらを組み合わせることなどにより行われる。
【００４０】
「予約リソース」、「予約されているリソース」とは、ユーザ装置ＵＥ自身又は他のユーザ装置ＵＥにより使用されることが宣言されているリソースのことを言う。本実施の形態では、各ユーザ装置ＵＥは、周期的にＤ２Ｄ信号を送信する前提であるため、後述するセンシング期間内でセンシングを行うことで、センシング期間より後の期間において、他のユーザ装置ＵＥにより予約されているリソース又は予約されていないリソース（空きリソース）を把握することが可能である。なお、具体的には後述するが、本実施の形態では、同一のリソースを複数のユーザ装置ＵＥが予約することを許容する前提である。従って、「予約されていないリソース」には、どのユーザ装置ＵＥも予約していないリソース、及び、予約しているユーザ装置ＵＥが少ないリソースの両方を含み得る。
【００４１】
「リソース」とは、特に断りの無い限り、時間リソース（例：サブフレーム）、若しくは、時間及び周波数リソースを含む。「Ｄ２Ｄ信号」は、Ｄ２Ｄコミュニケーションの信号（ＳＣＩであってもよいし、データであってもよいし、ＳＣＩとデータの組であってもよい）である前提で説明するが、これに限られず、Ｄ２Ｄディスカバリのメッセージ（発見信号）であってもよい。
【００４２】
＜ユーザ装置の動作の概要について＞
図１１は、実施の形態に係るユーザ装置の動作の概要を説明するための図である。本実施の形態では、ユーザ装置ＵＥは、基本的に、所定の周期でＤ２Ｄ信号を送信することを想定しており、ユーザ装置ＵＥが備える上位レイヤ（例えばＶ２Ｘアプリケーション）で生成されたデータは所定の周期で物理レイヤに到着する。
【００４３】
まず、ユーザ装置ＵＥは、予めセンシング期間の中でセンシングを行うことで、リソースの予約状況を把握しておく。なお、センシング期間の長さは、基本的には、本無線通信システムで通信を行う各ユーザ装置がＤ２Ｄ信号のリソースを予約可能な最大の周期以上に設定されている前提とする。例えば、各ユーザ装置ＵＥがＤ２Ｄ信号のリソースを予約可能な周期の最大が５００ｍｓである場合、センシング期間の長さは、５００ｍｓ以上であるのが望ましい。これは、センシング期間の長さが、各ユーザ装置がＤ２Ｄ信号のリソースを予約可能な最大の周期よりも短いと、センシングを行うユーザ装置ＵＥが、他のユーザ装置ＵＥが予約しているリソースを適切に把握することが困難になるためである。
【００４４】
続いて、ユーザ装置ＵＥは、自身の上位レイヤで生成されたデータが物理レイヤに最初に到着したことを検出（Ｄ１のタイミング）すると、センシング結果に基づいて、選択ウィンドウの範囲内で予約されていないリソースを選択し、選択したリソース（Ｒ１）で、物理レイヤに到着したデータ（Ｄ１）を含むＤ２Ｄ信号を送信する。また、ユーザ装置ＵＥは、選択したリソースに対応する周期的なリソースないし次回の送信に用いるリソースを予約し、予約したリソース（Ｒ２、Ｒ３、Ｒ４）を使用して、物理レイヤに到着したデータ（Ｄ２、Ｄ３、Ｄ４）を含むＤ２Ｄ信号を周期的に送信する。
【００４５】
有効データウィンドウは、遅延が許容される期間、つまり、自身の上位レイヤで生成されたデータが物理レイヤに到着してから、予約されたリソースで実際にＤ２Ｄ信号が送信されるまでに許容される時間を示している。つまり、有効データウィンドウは、ユーザ装置ＵＥの内部で、予約されたリソース毎に対応づけられて設定される。例えば、図１１に示すように、予約リソース（Ｒ２、Ｒ３、Ｒ４）にそれぞれ対応する有効データウィンドウ（Ｗ２、Ｗ３、Ｗ４）が設定される。なお、図１１に示す有効データウィンドウは、それぞれ対応する予約リソースよりも時間軸上で少し離れた位置に設定されているが、これは一例であり、それぞれ対応する予約リソースの直前に設定されていてもよい。また、ＳＣＩ及びデータを異なるサブフレームで送信することができる場合において、リソースの予約がＳＣＩを送信するためのリソース及びデータを送信するためのリソースの双方に対して適用される場合、有効データウィンドウは、先に送信されるＳＣＩのリソースに対して定められる。また、リソースの予約がデータを送信するためのリソースのみに対して適用される場合、有効データウィンドウは、予約された各データを送信するためのリソースに対して定められる。
【００４６】
リソース予約期間は、リソースの予約が可能な期間を示している。リソース予約期間は、各ユーザ装置ＵＥが将来のリソースを無制限に予約することを防止するために設けられる期間である。本実施の形態では、リソース予約期間はどのような長さであってもよいが、少なくともセンシング期間と同一又はそれ以上の期間に設定される前提である。ユーザ装置ＵＥが予約できるリソースは、次回の送信に用いる１回分のリソースのみに限定されてもよいし、複数回の送信に用いるリソースの予約が許可されていてもよい。また、短い期間のリソースのみを予約しているユーザ装置ＵＥがいた場合、センシング期間後の予約リソースが不明な場合がある。そのため、センシングを行うユーザ装置ＵＥは、センシング期間で検出されたリソースは、選択ウィンドウの長さの周期で周期的に繰り返されて予約されていると認識するようにしてもよい。
【００４７】
選択ウィンドウの期間は、遅延が許容される期間、つまり、自身の上位レイヤで生成されたデータが最初に物理レイヤに到着してから、実際にＤ２Ｄ信号が送信されるまでに許容される時間に設定される。
【００４８】
センシング期間、選択ウィンドウ、リソース予約期間の開始タイミング及び終了タイミングは、時間の経過に合わせてスライドしてもよい。例えば、センシング期間の開始タイミングは、現在のサブフレームから所定のサブフレーム前のサブフレームであり、終了タイミングは、現在のサブフレームであってもよい。また、選択ウィンドウ及びリソース予約期間の開始タイミングは、現在のサブフレームであり、終了タイミングは、現在のサブフレームから所定のサブフレーム後のサブフレームであってもよい。また、センシング期間、選択ウィンドウ、リソース予約期間の開始タイミング及び終了タイミングは、予め設定された周期的な期間（例えばＳＣ（Sidelink Control）期間）の境界のタイミングであってもよい。有効データウィンドウの開始タイミング及び終了タイミングについては後述する。
【００４９】
本実施の形態では、同一のリソースを複数のユーザ装置ＵＥが予約することを許容する。また、各ユーザ装置ＵＥが必ずしも予約したリソースの全てにおいてＤ２Ｄ信号を送信しないことを許容する。つまり、各ユーザ装置ＵＥは、対応する送信データが存在しないリソースの予約を行うことが許容される。
【００５０】
そこで、各ユーザ装置ＵＥは、予約したリソースの各々でＤ２Ｄ信号を送信する前に、当該予約したリソースの各々でＤ２Ｄ信号を送信することを他のユーザ装置に通知するための情報（以下、「確認情報（Confirmation Information）」と呼ぶ）を送信する。より具体的には、各ユーザ装置ＵＥは、自身の上位レイヤで生成されたデータが物理レイヤに到着したタイミングが、有効データウィンドウの範囲内に存在するか否かを確認する。有効データウィンドウの範囲内に存在する場合、各ユーザ装置ＵＥは、予約したリソースの各々でＤ２Ｄ信号を送信する前に、確認情報を送信する。
【００５１】
ここで、予約したリソースが実際に送信に用いられるかを他のユーザ装置ＵＥに通知する方法として、リソースの開放（つまり、予約したリソースでＤ２Ｄ信号を送信しないこと）を通知する方法もある。しかしながら、この場合、複数のユーザ装置ＵＥが同一のリソースを予約している場合、誤って他のユーザ装置ＵＥが予約しているリソースを開放することがないように、リソースの予約・開放を行うユーザ装置ＵＥの対応付けを行う必要があり、シグナリングオーバーヘッドが増加してしまう。一方で、本実施の形態のように、予約したリソースでＤ２Ｄ信号を送信することを示す確認情報を送信する方式では、どのユーザ装置ＵＥから送信された確認情報であるかを各ユーザ装置ＵＥが認識する必要はなく、有効データウィンドウ内で確認情報が検出されなければリソースが開放されたとみなすことができる。ただし、有効データウィンドウ内で、確認情報のモニタリングできなかったサブフレームが存在する場合、ユーザ装置ＵＥは、予約したリソースでは他のユーザ装置ＵＥがＤ２Ｄ信号を送信予定であると認識してもよい（つまり、確認情報を受信したとみなすようにしてもよい）。このような動作により、Ｈａｌｆ  ｄｕｐｌｅｘの制限による確認情報の受信漏れの影響を回避することができる。
【００５２】
確認情報は、ユーザ装置ＵＥ間の制御情報（例えばＳＣＩ）として単独で送信されてもよい。また、後述する、予約情報とともにまたは予約情報の代わりに確認情報が送信されてもよい。例えば、あるデータを送信する際に次回の送信が確定している場合、ユーザ装置ＵＥは、予約情報及び確認情報を同時に送信することが考えられる。例えば、予約情報及び確認情報がいずれもユーザ装置ＵＥ間の制御情報（例えばＳＣＩ）で送信される場合、予約レベルを３つ（予約なし、予約、確認）定義して通知したり、関連付けられたデータ送信の有無を通知することでこのような確認情報の通知が実現できる。
【００５３】
ユーザ装置ＵＥは、自身が確認情報を送信する前に他のユーザ装置ＵＥから確認情報を受信した場合、予約したリソースでは他のユーザ装置ＵＥからＤ２Ｄ信号が送信されると判断し、予約したリソースでＤ２Ｄ信号を送信せずに、予約したリソースとは異なる新たなリソースでＤ２Ｄ信号を送信する。
【００５４】
また、ユーザ装置ＵＥは、自身の上位レイヤで生成されたデータが物理レイヤに到着したタイミングが、有効データウィンドウの範囲内に存在しない場合、予約したリソースでは許容される遅延を満たすことができないと判断する。この場合、ユーザ装置ＵＥは、予約したリソースでＤ２Ｄ信号を送信せずに、予約したリソースとは異なる新たなリソースでＤ２Ｄ信号を送信する。
【００５５】
図１２及び図１３は、ユーザ装置が確認情報及びＤ２Ｄ信号を送信する際の動作例を説明するための図である。図１２及び図１３において、同一の符号が付されたリソースは同一のリソースを意味している。図１２は、予約したリソースの時間間隔が異なるユーザ装置ＵＥ１及びユーザ装置ＵＥ２の動作例を示しており、ユーザ装置ＵＥ１及びユーザ装置ＵＥ２は、有効データウィンドウ内でＶ２Ｘデータが到着したことを検出し、確認情報を送信してから予約リソースでＤ２Ｄ信号を送信している。図１３（ａ）は、予約したリソースの時間間隔が同一であるユーザ装置ＵＥ１及びユーザ装置ＵＥ２の動作例を示しており、ユーザ装置ＵＥ１及びユーザ装置ＵＥ２は、有効データウィンドウ内でＶ２Ｘデータが到着したことを検出し、確認情報を送信してから予約リソースでＤ２Ｄ信号を送信している。一方、図１３（ｂ）の例では、ユーザ装置ＵＥ１及びユーザ装置ＵＥ２は、共に予約リソース（Ｒ５）に対応する有効データウィンドウ内でＶ２Ｘデータが到着したことを検出したものの、ユーザ装置ＵＥ２は、ユーザ装置ＵＥ１から送信された確認情報を検出したため、予約リソース（Ｒ５）ではＤ２Ｄ信号を送信せず、予約したリソースとは異なる新たなリソース（Ｒ１０）でＤ２Ｄ信号を送信することになる。
【００５６】
＜リソースの選択及び予約について＞
前述した通り、ユーザ装置ＵＥは、予めセンシング期間の中でセンシングを行うことで、リソースの予約状況を把握しておき、自身の上位レイヤで生成されたデータが最初に物理レイヤに到着したことを検出すると、選択ウィンドウの範囲内でＤ２Ｄ信号の送信に用いるリソースを選択する。また、ユーザ装置ＵＥは、選択したリソースに対応する周期的なリソースを予約する。
【００５７】
（リソースの予約について）
リソースの予約（スケジューリングと称してもよい）は、明示的又は暗示的な方法で行われる。例えば、選択したリソース（及び予約したリソース）で送信するＤ２Ｄ信号に、予約したリソースの位置を示す予約情報（例えば、次回の送信タイミング（１ｓ、５００ｍｓ、１００ｍｓなど）を示す情報、又は、予約したリソースの周波数及び時間を示す情報など）を含めて送信することで、他のユーザ装置ＵＥに対して、予約したリソースの位置を通知するようにしてもよい。他のユーザ装置ＵＥは、センシングにより予約情報を取得することで、リソースの予約状況を把握することができる。
【００５８】
また、予め標準仕様又は報知情報などでＤ２Ｄ信号の固定的な周期が定められており、特定のリソースで他のユーザ装置ＵＥから送信されたＤ２Ｄ信号をセンシングで検出したユーザ装置ＵＥは、予め定められた固定的な周期でその特定のリソースが予約されていることを認識するようにしてもよい。例えば、ある特定の周波数（ｆ１）及び時間リソース（ｔ１）に対して１００ｍｓ周期が定められている場合、当該特定の周波数（ｆ１）及び時間リソース（ｔ１）でＤ２Ｄ信号を受信（又は受信電力が所定の閾値以上であることを検出など）したユーザ装置ＵＥは、それ以後の周波数（ｆ１）及び時間（ｔ１＋Ｎ×１００ｍｓ、Ｎは正の整数）のリソースについては、リソースが予約されていると認識するようにしてもよい。
【００５９】
上述のリソースの予約方法は一例であり、本実施の形態ではどのような方法でリソースの予約が行われてもよい。
【００６０】
（選択及び予約可能なリソースの上限について）
本実施の形態では、各ユーザ装置ＵＥが無制限にリソースを選択及び予約することを防止するために、各ユーザ装置ＵＥが選択及び予約可能なリソースの上限を予め規定しておき、ユーザ装置ＵＥは、当該規定の範囲内でリソースを選択及び予約するようにしてもよい。選択及び予約可能なリソースの上限として、例えば、選択及び予約可能なリソースの最小周期、及び／又は、選択及び予約可能なＲＢ（Resource Block）の最大数（最大サイズ）が規定されていてもよい。当該規定は、ユーザ装置ＵＥに事前設定（Pre-configured）されていてもよいし、基地局ｅＮＢから報知情報又はＲＲＣメッセージによりユーザ装置ＵＥに設定されてもよいし、予め標準仕様等で固定的に規定されていてもよい。
【００６１】
また、当該規定は、ユーザ装置ＵＥの優先度に応じて、優先度ごとに規定されてもよい。例えば、優先度が高い自動車（緊急車両など）は、優先度が低い自動車（一般車両など）よりも選択及び予約可能なリソースの上限が多くなるように規定されていてもよい。予約されたリソースが全てのＶ２Ｘトラフィック（Ｖ２Ｘデータ）で共有される場合に好適である。
【００６２】
また、当該規定は、Ｖ２Ｘトラフィック（Ｖ２Ｘデータ）の優先度に応じて、優先度ごとに規定されていてもよい。例えば、優先度が高いＶ２Ｘトラフィック（Ｖ２Ｘデータ）を送信するために選択及び予約可能なリソースの上限は、優先度が低いトラフィック（Ｖ２Ｘデータ）を送信するために選択及び予約可能なリソースの上限よりも多くなるように規定されていてもよい。
【００６３】
（選択及び予約するリソースについて）
ユーザ装置ＵＥは、選択及び予約可能なリソースの上限に従いつつ選択ウィンドウの範囲内でリソースを選択する際、以下の優先順位に従ってリソースの選択及び予約を行うようにしてもよい。
・優先順位１（1st priority）のリソース：センシングにより予約されていないと判断されたリソース。
・優先順位２（2nd priority）のリソース：センシングにより予約されていると判断されたリソースであり、かつ、確認情報が検出されていないリソース（つまり、予約されているものの他のユーザ装置ＵＥが使用しないリソース）。
【００６４】
なお、受信電力の測定結果を用いてセンシングを行う場合、ユーザ装置ＵＥは、受信電力が所定の判断基準（所定の閾値と称してもよい）以上であるか否かを判断することで、リソースが予約されているのか否かを判断する。また、ＳＣＩのデコード結果を用いてセンシングを行う場合、ユーザ装置ＵＥは、ＳＣＩのデコード結果より得られるリソースの利用状況（例えば、そのリソースを予約しているユーザ装置ＵＥの数）が所定の判断基準以上であるか否かを判断することで、リソースが予約されているのか否かを判断する。また、受信電力の測定結果及びＳＣＩのデコード結果の両方を用いてセンシングを行う場合、これらの組み合わせによりリソースが予約されているのか否かを判断する。
【００６５】
ここで、本実施の形態では、所定の判断基準は、優先順位１のリソースの判断を行う際と、優先順位２のリソースの判断を行う際とで、異なる判断基準が設定（適用）されていてもよい。この場合、優先順位２のリソースは以下のように定義されてもよい。
・優先順位２（2nd priority）のリソース：所定の判断基準を優先順位１とは異なる判断基準に変更した場合に予約されていないと判断されるリソースであり、かつ、確認情報が検出されていないリソース。
【００６６】
所定の判断基準は、ユーザ装置ＵＥに事前設定（Pre-configured）されていてもよいし、基地局ｅＮＢから報知情報又はＲＲＣメッセージによりユーザ装置ＵＥに設定されてもよいし、予め標準仕様等で固定的に規定されていてもよい。また、所定の判断基準は、全てのリソースプールで共通に規定されていてもよいし、リソースプール毎に個別に規定されていてもよい。
【００６７】
ここで、図１４を用いて、ユーザ装置がセンシングによりリソースを選択する際の動作の具体例を説明する。図１４の例は、優先順位１のリソースの判断を行う際と、優先順位２のリソースの判断を行う際とで、異なる判断基準が設定（適用）される場合の具体例である。
【００６８】
まず、ユーザ装置ＵＥは、センシング結果（受信電力の測定結果及び／又はＳＣＩのデコード結果）に基づき、予約されているリソース及び予約されていないリソースを特定する。ここで、予約されているリソースか否かを判断するための判断基準として、受信電力については「閾値Ａ−１」、リソースの利用状況については「閾値Ａ−２」を用いる。
【００６９】
例えば、ユーザ装置ＵＥは、選択ウィンドウの範囲内で、受信電力が「閾値Ａ−１」未満、及び／又は、リソースの利用状況が「閾値Ａ−２」未満のリソースを、予約されていないリソースであると判断する。この時点で予約されていないリソースが存在する場合、ユーザ装置ＵＥは、予約されていないリソース（例えば、図１４（ａ）の未予約リソース、つまり、優先順位１のリソース）の中から、Ｄ２Ｄ信号の送信に用いるリソースを選択及び予約する。
【００７０】
予約されていないリソースが存在しない場合、又は、予約されていないリソースが存在するもののＤ２Ｄ信号をするために十分なリソース量ではない場合、ユーザ装置ＵＥは、判断基準を変更し、再度、予約されているリソース及び予約されていないリソースを特定する。ここで、予約されているリソースか否かを判断するための判断基準として、受信電力については「閾値Ｂ−１」、リソースの利用状況については「閾値Ｂ−２」を用いる。なお、「閾値Ｂ−１」＞「閾値Ａ−１」であり、「閾値Ｂ−２」＞「閾値Ａ−２」であるとする。つまり、変更後の判断基準では、受信電力及びリソースの利用状況が高くても予約されていないリソースであると判断される。
【００７１】
続いて、ユーザ装置ＵＥは、受信電力が「閾値Ｂ−１」未満、及び／又は、リソースの利用状況が「閾値Ｂ−２」未満のリソース（例えば、図１４（ｂ）の「受信電力  ＜  閾値Ｂ−１  ａｎｄ  リソースの利用状況  ＜  閾値Ｂ−２」のリソース）であって、かつ、確認情報が検出されていないリソース（優先順位２のリソース）の中からリソースの選択及び予約を行う。
【００７２】
なお、優先順位２のリソースが存在しない場合、又は、優先順位２のリソースが存在するもののＤ２Ｄ信号をするために十分なリソース量ではない場合、ユーザ装置ＵＥは、所定の時間が経過後に再度リソース選択を行うか、又は、データの送信を諦める。
【００７３】
＜有効データウィンドウについて＞
有効データウィンドウの開始タイミング及び終了タイミングは、例えば、予約リソースのサブフレームをサブフレーム（ｎ）とし、ｘ及びｙを０又は正の整数とした場合、開始タイミングはサブフレーム（ｎ−ｘ）、終了タイミングはサブフレーム（ｎ−ｙ）で定義されてもよい。
【００７４】
有効データウィンドウの開始タイミング及び終了タイミングは、全ユーザ装置ＵＥで共通に設定されてもよい。この場合、有効データの開始タイミング及び終了タイミング（例えばｘ及びｙの値）は、ユーザ装置ＵＥに事前設定（Pre-configured）されていてもよいし、基地局ｅＮＢから報知情報又はＲＲＣメッセージによりユーザ装置ＵＥに設定されてもよいし、予め標準仕様等で固定的に規定されていてもよい。有効データウィンドウが全ユーザ装置ＵＥで共通に設定されることで、各ユーザ装置ＵＥから予約リソースに対応する確認情報が送信されるタイミングが概ね有効データウィンドウの範囲内に収まることになるため、各ユーザ装置ＵＥは、確認情報をモニタする期間を限定することが可能になる。
【００７５】
また、有効データウィンドウの開始タイミング及び終了タイミングは、ユーザ装置ＵＥ又はＶ２Ｘデータの優先度毎に設定されてもよい。この場合、有効データの開始タイミング及び終了タイミング（例えばｘ及びｙの値）は、ユーザ装置ＵＥに事前設定（Pre-configured）されていてもよいし、基地局ｅＮＢから報知情報又はＲＲＣメッセージによりユーザ装置ＵＥに設定されてもよいし、予め標準仕様等で固定的に規定されていてもよい。
【００７６】
また、有効データウィンドウの開始タイミング及び終了タイミングは、ユーザ装置ＵＥ毎に個別に設定されていてもよい。この場合、有効データウィンドウの開始タイミング及び終了タイミングは、ユーザ装置ＵＥの実装に委ねられてもよい。
【００７７】
また、有効データウィンドウは、必ずしも連続した期間でなくてもよい。有効データウィンドウは、確認情報を通知可能な時間間隔に基づいて、離散的なサブフレームとして定められてもよい。例えば、確認情報が、確認情報が送信されるサブフレームの｛Ｎ１、 Ｎ２、Ｎ３、Ｎ４｝サブフレーム後の予約リソースの確認に用いられる場合、予約リソースの｛ｎ×Ｎ１、ｎ×Ｎ２、ｎ×Ｎ３、ｎ×Ｎ４｝（ｎ≧ａ）前のサブフレームを有効データウィンドウとして定めてもよい。ここで「Ｎ１」、「Ｎ２」、「Ｎ３」、「Ｎ４」及び「ａ」は正の整数である。また、「ｎ＝１、２、３・・（ただし、ｎ≧ａ）」である。「ａ」は上位レイヤで設定されてもよいし、予め決められた値でもよい。
【００７８】
＜確認情報について＞
前述の通り、ユーザ装置ＵＥは、自身の上位レイヤで生成されたデータが物理レイヤに到着したタイミングが有効データウィンドウの範囲内である場合、予約したリソースの各々でＤ２Ｄ信号を送信する前に、確認情報を送信する。
【００７９】
（確認情報の例（その１））
確認情報には、リソースを予約する際の予約情報との対応づけを示す情報が含まれていてもよい。例えば、予約情報（又は、予約情報として用いられるＳＣＩでもよい）の中にプロセスＩＤ及びソースＩＤなどを含めておき、確認情報にも同一のプロセスＩＤ及びソースＩＤなどを含めるようにしてもよい。ユーザ装置ＵＥは、自身が選択したリソースと同一リソースを予約している他のユーザ装置ＵＥから受信した予約情報に含まれるプロセスＩＤ及びソースＩＤを記憶しておくと共に、確認情報に含まれるプロセスＩＤ及びソースＩＤを抽出して比較することで、自身が予約したリソースに対する確認情報なのかを判断することができる。
【００８０】
（確認情報の例（その２））
確認情報には、予約されたリソースの各々の時間方向及び周波数方向のリソースを示す情報（例えば、ＳＦＮ及びサブフレーム番号、並びに周波数方向のリソースブロックのインデックスなど）が含まれていてもよい。また、具体的には後述するが、確認情報としてＳＣＩが代用される場合、予約リソースの時間及び周波数リソースを示す情報は、ＳＣＩのスケジューリング情報であってもよい。
【００８１】
確認情報の例（その２）では、確認情報のデータ量を削減するために、各予約リソースに対応する確認情報を送信可能な時間方向のリソースは予め定められていてもよい。具体例を図１５に示す。例えば、予約リソースのサブフレームをサブフレーム（Ｍ）とした場合、当該予約リソースに対応する確認情報を送信可能なサブフレームは、サブフレーム（Ｍ−Ｔｆ×Ｎ−ｏｆｆｓｅｔＴ）であってもよい。ここで、Ｎは０又は正の整数である。「Ｔｆ」は正の整数であり、確認信号を送信可能なサブフレームの周期である。「ｏｆｆｓｅｔＴ」は正の整数であり、所定のオフセット値である。また、「Ｔｆ」及び「ｏｆｆｓｅｔＴ」の値は、ユーザ装置ＵＥに事前設定（Pre-configured）されていてもよいし、基地局ｅＮＢから報知情報又はＲＲＣメッセージによりユーザ装置ＵＥに設定されてもよいし、予め標準仕様等で固定的に規定されていてもよい。これにより、確認情報に、予約されたリソースの時間方向のリソースを示す情報を含める必要がなくなるため、確認情報のデータ量を削減することが可能になる。
【００８２】
（確認情報の送信方法（その１）について）
確認情報は、予約リソースで送信されるＤ２Ｄ信号（例えば、ＳＣＩ及びデータ）とは独立した情報として送信されるようにしてもよい。この場合、確認情報には、上述の「確認情報の例（その１）」又は「確認情報の例（その２）」で説明した情報に加えて、確認情報を送信するユーザ装置ＵＥのＵＥＩＤ（ＲＮＴＩでもよい）、プロセスＩＤ、トラフィック情報（Ｖ２Ｘデータの種別など）、及び／又は、予約リソースで送信するデータ（Ｖ２Ｘデータ）の優先クラスなどが含まれていてもよい。
【００８３】
また、確認情報の送信方法（その１）では、確認情報は、予約リソースのリソースプールとは異なるリソースプールで送信されるようにしてもよい。予約リソースのリソースプールとは異なるリソースプールは、例えば、予約リソースのリソースプールと時間多重（ＴＤＭ）されたリソースプールであってもよいし、周波数多重（ＦＤＭ）されたリソースプールであってもよい。
【００８４】
（確認情報の送信方法（その２）について）
確認情報の送信方法（その２）では、確認情報はＳＣＩであってもよい。つまり、確認情報はＳＣＩで代用されてもよい。この場合、予約リソースで送信されるＤ２Ｄ信号はデータのみであり、データに対応するＳＣＩは、予約リソースよりも前のタイミング（例えば、図１５に示すタイミングなど）で送信される。
【００８５】
［確認情報の送信方法（その２−１）］
ユーザ装置ＵＥは、自身の上位レイヤで生成されたデータが物理レイヤに到着したタイミングが有効データウィンドウの範囲内に存在しなかった場合（つまり、予約リソースでデータの送信を行わない場合）、ＳＣＩを送信しないようにしてもよい。この場合、他のユーザ装置ＵＥは、ＳＣＩを受信した場合は確認情報を受信したと暗示的に認識し、ＳＣＩを受信しない場合は確認情報を受信しなかったと認識する。
【００８６】
［確認情報の送信方法（その２−２）］
ユーザ装置ＵＥは、自身の上位レイヤで生成されたデータが物理レイヤに到着したタイミングが有効データウィンドウの範囲内に存在したか否かに関わらず、ＳＣＩを送信するようにしてもよい。この場合、ＳＣＩには、確認情報が有効であるか否かを示す１ビットの情報を含めておく。他のユーザ装置ＵＥは、確認情報が有効であることを示す情報が含まれるＳＣＩを受信した場合は確認情報を受信したと認識し、確認情報が無効であることを示す情報が含まれるＳＣＩを受信した場合は確認情報を受信しなかったと認識する。
【００８７】
（確認情報に関する補足事項）
リソースが短い周期で予約される場合、最初の数周期のリソースについてはすぐに送信タイミングが訪れることになる。そこで、ユーザ装置ＵＥは、最初の数周期の予約リソースでＤ２Ｄ信号を送信する際、確認情報の送信を省略するようにしてもよい。同様に、予約情報（又は、予約情報として用いられるＳＣＩでもよい）を受信したユーザ装置ＵＥは、最初の数周期の予約リソースについては確認情報を受信したとみなすようにしてもよい。
【００８８】
＜Ｄ２Ｄ信号が送信できない場合の新たなリソースの選択について＞
前述したように、ユーザ装置ＵＥは、自身が確認情報を送信する前に他のユーザ装置ＵＥから確認情報を受信した場合、予約したリソースのうち確認情報で示される所定のリソースでは他のユーザ装置ＵＥからＤ２Ｄ信号が送信されると判断し、当該所定のリソースでＤ２Ｄ信号を送信せずに、当該所定のリソースとは異なる新たなリソースを選択してＤ２Ｄ信号を送信する。また、ユーザ装置ＵＥは、自身の上位レイヤで生成されたデータが物理レイヤに到着したタイミングが、有効データウィンドウの範囲内に存在しない場合、予約したリソースでは許容される遅延を満たすことができないと判断し、予約したリソースでＤ２Ｄ信号を送信せずに、予約したリソースとは異なる新たなリソースを選択してＤ２Ｄ信号を送信する。
【００８９】
ユーザ装置ＵＥは、新たなリソースを選択する場合、予約していたリソースをキャンセル（破棄）して、再度リソースの選択及び予約をやり直す（「リソースの再選択」と呼ぶ）ようにしてもよい。また、ユーザ装置ＵＥは、予約していたリソースをキャンセル（破棄）せずに、未送信のデータのみを送信するためのリソースを一時的に選択するようにしてもよい。
【００９０】
また、ユーザ装置ＵＥは、新たなリソースを選択する場合（リソースの再選択を含む）、センシング期間及び選択ウィンドウの期間については、通常時にリソース選択を行う際のセンシング期間及び選択ウィンドウの期間とは異なる期間に設定するようにしてもよい。また、ユーザ装置ＵＥは、「（選択及び予約するリソースについて）」で説明した判断基準（通常時に適用される判断基準）とは異なる判断基準を適用するようにしてもよい。これにより、リソースが混雑している場合であっても、他のユーザ装置ＵＥよりも優先してリソースの選択を行うことが可能になる。
【００９１】
なお、ユーザ装置ＵＥは、所定の条件を満たす場合に限りリソースの再選択を行うようにしてもよい。所定の条件は、例えば、期間「Ｔ」の間に、新たなリソースの選択を「Ｋ」回行った場合であってもよい。なお、「Ｋ」は正の整数である。「Ｔ」及び「Ｋ」の値は、ユーザ装置ＵＥに事前設定（Pre-configured）されていてもよいし、基地局ｅＮＢから報知情報又はＲＲＣメッセージによりユーザ装置ＵＥに設定されてもよいし、予め標準仕様等で固定的に規定されていてもよい。これにより、リソースが混雑している場合に、多数のユーザ装置ＵＥがリソースの再選択を行ってしまうことで、更に多くのリソースが予約されてしまう可能性を抑制することができる。
【００９２】
＜機能構成＞
（ユーザ装置）
図１６は、実施の形態に係るユーザ装置の機能構成の一例を示す図である。図１６に示すように、ユーザ装置ＵＥは、信号送信部１０１と、信号受信部１０２と、生成部１０３と、検出部１０４と、選択部１０５とを有する。なお、図１６は、ユーザ装置ＵＥにおいて本発明の実施の形態に特に関連する機能部のみを示すものであり、少なくともＬＴＥに準拠した動作を行うための図示しない機能も有するものである。また、図１６に示す機能構成は一例に過ぎない。本実施の形態に係る動作を実行できるのであれば、機能区分及び機能部の名称はどのようなものでもよい。ただし、これまでに説明したユーザ装置ＵＥの処理の一部（一部の送信方法のみ等）を実行可能としてもよい。
【００９３】
信号送信部１０１は、Ｄ２Ｄ信号の送信機能とセルラ通信の送信機能を有し、生成部１０３で生成されたＤ２Ｄ信号から物理レイヤの各種信号を生成し、無線送信する機能を含む。信号送信部１０１には、更に、第一の信号送信部１０１１と、第二の信号送信部１０１２とが含まれる。
【００９４】
第一の信号送信部１０１１は、予約されたリソースでＤ２Ｄ信号を送信する機能を有する。また、第一の信号送信部１０１１は、選択部１０５で選択されたリソースを予約するための予約情報を含むＤ２Ｄ信号を送信するようにしてもよい。また、第一の信号送信部１０１１は、信号受信部１０２で、予約されたリソースでＤ２Ｄ信号を送信することを通知する確認情報を他のユーザ装置ＵＥから受信した場合、当該予約されたリソースでＤ２Ｄ信号を送信せずに、選択部１０５で選択された、予約されたリソースとは異なるリソースでＤ２Ｄ信号を送信するようにしてもよい。
【００９５】
また、第一の信号送信部１０１１は、Ｄ２Ｄ信号に格納するデータを有効データウィンドウ以外の期間で生成部１０３から受信した場合、Ｄ２Ｄ信号に格納するデータを含むＤ２Ｄ信号を予約されたリソースで送信せずに、選択部１０５で選択された、予約されたリソースとは異なるリソースで送信するようにしてもよい。
【００９６】
第二の信号送信部１０１２は、予約されたリソースでＤ２Ｄ信号が送信される前に、予約されたリソースＤ２Ｄ信号を送信することを他のユーザ装置ＵＥに通知するための確認情報を送信する機能を有する。
【００９７】
また、第二の信号送信部１０１２は、予約されたリソースを予約する際の予約情報との対応づけを示す情報、又は、予約されたリソースの時間リソース及び周波数リソースを示す情報を確認情報に含めて送信するようにしてもよい。
【００９８】
また、第二の信号送信部１０１２は、確認情報を、予約されたリソースのサブフレームより前のサブフレームであって予め定められたサブフレームで送信するようにしてもよい。
【００９９】
信号受信部１０２は、他のユーザ装置ＵＥ又は基地局ｅＮＢから各種の信号を無線受信し、受信した物理レイヤの信号からより上位のレイヤの信号を取得する機能を含む。また、信号受信部１０２は、Ｄ２Ｄ信号の受信機能とセルラ通信の受信機能を有する。
【０１００】
生成部１０３は、信号送信部１０１から送信されるＤ２Ｄ信号に格納するデータを生成する機能を有する。
【０１０１】
検出部１０４は、センシング期間でセンシングを行うことで、Ｄ２Ｄ信号を所定の周期で送信可能な（予約可能な）周期的なリソースであって、最初のリソースが選択ウィンドウの範囲に含まれる周期的なリソースの候補を検出する機能を有する。
【０１０２】
選択部１０５は、検出部１０４で検出された周期的なリソースの候補から、Ｄ２Ｄ信号を送信するための周期的なリソースを選択する機能を有する。
【０１０３】
また、選択部１０５は、信号受信部１０２が、予約されたリソースでＤ２Ｄ信号を送信することを通知する確認情報を他のユーザ装置ＵＥから受信した場合、予約されたリソースとは異なるリソースを選択するようにしてもよい。
【０１０４】
また、選択部１０５は、生成部１０３で生成されたＤ２Ｄ信号に格納するデータを、予約されたリソースに対応づけられる有効データウィンドウ以外の期間に第一の信号送信部１０１１が受信したことを検出した場合に、予約されたリソースとは異なるリソースを選択するようにしてもよい。
【０１０５】
（基地局）
図１７は、実施の形態に係る基地局の機能構成の一例を示す図である。図１７に示すように、基地局ｅＮＢは、信号送信部２０１と、信号受信部２０２と、通知部２０３とを有する。なお、図１７は、基地局ｅＮＢにおいて本発明の実施の形態に特に関連する機能部のみを示すものであり、少なくともＬＴＥに準拠した動作を行うための図示しない機能も有するものである。また、図１７に示す機能構成は一例に過ぎない。本実施の形態に係る動作を実行できるのであれば、機能区分及び機能部の名称はどのようなものでもよい。
【０１０６】
信号送信部２０１は、基地局ｅＮＢから送信されるべき上位のレイヤの信号から、物理レイヤの各種信号を生成し、無線送信する機能を含む。信号受信部２０２は、ユーザ装置ＵＥから各種の信号を無線受信し、受信した物理レイヤの信号からより上位のレイヤの信号を取得する機能を含む。
【０１０７】
通知部２０３は、ユーザ装置ＵＥが本実施の形態に係る動作を行うために用いる各種情報を、報知情報（ＳＩＢ）又はＲＲＣシグナリングを用いてユーザ装置ＵＥに通知する。なお、当該各種情報は、例えば、リソースプールの設定を示す情報、ＳＣ期間（Sidelink Control Period）の位置を示す情報、各種の期間（センシング期間、選択ウィンドウ、リソース予約期間、及び、有効データウィンドウ）の開始タイミング及び終了タイミングを示す情報、各ユーザ装置ＵＥが選択及び予約可能なリソースの上限の規定、優先順位１のリソースの判断を行う際及び優先順位２のリソースの判断を行う際に用いられる所定の判断基準（例えば各種の閾値）、各予約リソースに対応する確認情報を送信可能な時間方向のリソースを示す情報（例えば「Ｔｆ」及び「ｏｆｆｓｅｔＴ」の値）、「（確認情報の送信方法（その１））及び「（確認情報の送信方法（その２−１））」、「（確認情報の送信方法（その２−２））」のうちどの送信方法を用いるべきなのかを示す情報、などである。
【０１０８】
＜ハードウェア構成＞
上記実施の形態の説明に用いたブロック図（図１６及び図１７）は、機能単位のブロックを示している。これらの機能ブロック（構成部）は、ハードウェア及び／又はソフトウェアの任意の組み合わせによって実現される。また、各機能ブロックの実現手段は特に限定されない。すなわち、各機能ブロックは、物理的及び／又は論理的に結合した１つの装置により実現されてもよいし、物理的及び／又は論理的に分離した２つ以上の装置を直接的及び／又は間接的に（例えば、有線及び／又は無線）で接続し、これら複数の装置により実現されてもよい。
【０１０９】
例えば、本発明の一実施の形態における基地局ｅＮＢ、ユーザ装置ＵＥは、本発明の信号送信方法の処理を行うコンピュータとして機能してもよい。図１８は、実施の形態に係る基地局ｅＮＢ及びユーザ装置ＵＥのハードウェア構成の一例を示す図である。上述の基地局ｅＮＢ及びユーザ装置ＵＥは、物理的には、プロセッサ１００１、メモリ１００２、ストレージ１００３、通信装置１００４、入力装置１００５、出力装置１００６、バス１００７などを含むコンピュータ装置として構成されてもよい。
【０１１０】
なお、以下の説明では、「装置」という文言は、回路、デバイス、ユニットなどに読み替えることができる。基地局ｅＮＢ及びユーザ装置ＵＥのハードウェア構成は、図に示した各装置を１つ又は複数含むように構成されてもよいし、一部の装置を含まずに構成されてもよい。
【０１１１】
基地局ｅＮＢ及びユーザ装置ＵＥにおける各機能は、プロセッサ１００１、メモリ１００２などのハードウェア上に所定のソフトウェア（プログラム）を読み込ませることで、プロセッサ１００１が演算を行い、通信装置１００４による通信、メモリ１００２及びストレージ１００３におけるデータの読み出し及び／又は書き込みを制御することで実現される。
【０１１２】
プロセッサ１００１は、例えば、オペレーティングシステムを動作させてコンピュータ全体を制御する。プロセッサ１００１は、周辺装置とのインターフェース、制御装置、演算装置、レジスタなどを含む中央処理装置（ＣＰＵ：Central  Processing  Unit）で構成されてもよい。例えば、基地局ｅＮＢの信号送信部２０１、信号受信部２０２、及び通知部２０３、ユーザ装置ＵＥの信号送信部１０１、信号受信部１０２、生成部１０３、検出部１０４、及び選択部１０５は、プロセッサ１００１で実現されてもよい。
【０１１３】
また、プロセッサ１００１は、プログラム（プログラムコード）、ソフトウェアモジュール又はデータを、ストレージ１００３及び／又は通信装置１００４からメモリ１００２に読み出し、これらに従って各種の処理を実行する。プログラムとしては、上述の実施の形態で説明した動作の少なくとも一部をコンピュータに実行させるプログラムが用いられる。例えば、基地局ｅＮＢの信号送信部２０１、信号受信部２０２、及び通知部２０３、ユーザ装置ＵＥの信号送信部１０１、信号受信部１０２、生成部１０３、検出部１０４、及び選択部１０５は、メモリ１００２に格納され、プロセッサ１００１で動作する制御プログラムによって実現されてもよく、他の機能ブロックについても同様に実現されてもよい。上述の各種処理は、１つのプロセッサ１００１で実行される旨を説明してきたが、２以上のプロセッサ１００１により同時又は逐次に実行されてもよい。プロセッサ１００１は、１以上のチップで実装されてもよい。なお、プログラムは、電気通信回線を介してネットワークから送信されても良い。
【０１１４】
メモリ１００２は、コンピュータ読み取り可能な記録媒体であり、例えば、ＲＯＭ（Read  Only  Memory）、ＥＰＲＯＭ（Erasable  Programmable  ＲＯＭ）、ＥＥＰＲＯＭ（Electrically Erasable Programmable ＲＯＭ）、ＲＡＭ（Random  Access  Memory）などの少なくとも１つで構成されてもよい。メモリ１００２は、レジスタ、キャッシュ、メインメモリ（主記憶装置）などと呼ばれてもよい。メモリ１００２は、本発明の一実施の形態に係る信号送信方法を実施するために実行可能なプログラム（プログラムコード）、ソフトウェアモジュールなどを保存することができる。
【０１１５】
ストレージ１００３は、コンピュータ読み取り可能な記録媒体であり、例えば、ＣＤ−ＲＯＭ（Compact  Disc  ＲＯＭ）などの光ディスク、ハードディスクドライブ、フレキシブルディスク、光磁気ディスク（例えば、コンパクトディスク、デジタル多用途ディスク、Ｂｌｕ−ｒａｙ（登録商標）ディスク）、スマートカード、フラッシュメモリ（例えば、カード、スティック、キードライブ）、フロッピー（登録商標）ディスク、磁気ストリップなどの少なくとも１つで構成されてもよい。ストレージ１００３は、補助記憶装置と呼ばれてもよい。上述の記憶媒体は、例えば、メモリ１００２及び／又はストレージ１００３を含むデータベース、サーバその他の適切な媒体であってもよい。
【０１１６】
通信装置１００４は、有線及び／又は無線ネットワークを介してコンピュータ間の通信を行うためのハードウェア（送受信デバイス）であり、例えばネットワークデバイス、ネットワークコントローラ、ネットワークカード、通信モジュールなどともいう。例えば、基地局ｅＮＢの信号送信部２０１、及び、信号受信部２０２、ユーザ装置ＵＥの信号送信部１０１、及び、信号受信部１０２は、通信装置１００４で実現されてもよい。
【０１１７】
入力装置１００５は、外部からの入力を受け付ける入力デバイス（例えば、キーボード、マウス、マイクロフォン、スイッチ、ボタン、センサなど）である。出力装置１００６は、外部への出力を実施する出力デバイス（例えば、ディスプレイ、スピーカー、LEDランプなど）である。なお、入力装置１００５及び出力装置１００６は、一体となった構成（例えば、タッチパネル）であってもよい。
【０１１８】
また、プロセッサ１００１及びメモリ１００２などの各装置は、情報を通信するためのバス１００７で接続される。バス１００７は、単一のバスで構成されてもよいし、装置間で異なるバスで構成されてもよい。
【０１１９】
また、基地局ｅＮＢ及びユーザ装置ＵＥは、マイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ：Digital  Signal  Processor）、ＡＳＩＣ（Application  Specific  Integrated  Circuit）、ＰＬＤ（Programmable  Logic  Device）、ＦＰＧＡ（Field  Programmable  Gate  Array）などのハードウェアを含んで構成されてもよく、当該ハードウェアにより、各機能ブロックの一部又は全てが実現されてもよい。例えば、プロセッサ１００１は、これらのハードウェアの少なくとも１つで実装されてもよい。
【０１２０】
＜まとめ＞
以上、実施の形態によれば、Ｄ２Ｄをサポートするユーザ装置であって、予約されたリソースでＤ２Ｄ信号を送信する第一の送信部と、前記予約されたリソースでＤ２Ｄ信号が送信される前に、前記予約されたリソースでＤ２Ｄ信号を送信することを他のユーザ装置に通知するための確認情報を送信する第二の送信部と、を有するユーザ装置が提供される。このユーザ装置ＵＥによれば、ユーザ装置が実際にＤ２Ｄ信号の送信に用いるリソースを他のユーザ装置に通知することを可能にする技術が提供される。
【０１２１】
また、前記予約されたリソースでＤ２Ｄ信号を送信することを通知する確認情報を他のユーザ装置から受信した場合、前記予約されたリソースとは異なるリソースを選択する選択部、を有し、前記第一の送信部は、前記予約されたリソースでＤ２Ｄ信号を送信せずに、前記選択部で選択された、前記予約されたリソースとは異なるリソースでＤ２Ｄ信号を送信するようにしてもよい。これにより、ユーザ装置ＵＥは、他のユーザ装置ＵＥから確認情報を受信した場合に、確認情報に対応づけられるリソースでは他のユーザ装置ＵＥがＤ２Ｄ信号を送信予定であることを把握することができ、Ｄ２Ｄ信号の衝突を避けることが可能になる。また、確認情報を用いて他のユーザ装置ＵＥにＤ２Ｄ信号の送信を予定していることを通知するようにしたことで、同一のリソースを複数のユーザ装置ＵＥが予約することが可能になる。
【０１２２】
また、前記選択部は、前記生成部で生成された前記Ｄ２Ｄ信号に格納するデータを、前記予約されたリソースに対応づけられる所定の期間以外の期間に前記第一の送信部が受信したことを検出した場合に、前記予約されたリソースとは異なるリソースを選択し、
前記第一の送信部は、前記生成部で生成された前記Ｄ２Ｄ信号に格納するデータを含むＤ２Ｄ信号を前記予約されたリソースで送信せずに、前記選択部で選択された、前記予約されたリソースとは異なるリソースで送信する、ようにしてもよい。これにより、例えばＶ２Ｘアプリケーションで生成されたＶ２Ｘデータが、実際にＤ２Ｄ信号として送信されるまでに生じ得る遅延を抑制することが可能になる。
【０１２３】
また、前記第二の送信部は、前記予約されたリソースを予約する際の予約情報との対応づけを示す情報、又は、前記予約されたリソースの時間リソース及び周波数リソースを示す情報を前記確認情報に含めて送信するようにしてもよい。これにより、確認情報を受信したユーザ装置ＵＥは、他のユーザ装置ＵＥがどのリソースでＤ２Ｄ信号を送信予定なのかを把握することが可能になる。
【０１２４】
また、前記第二の送信部は、前記確認情報を、前記予約されたリソースのサブフレームより前のサブフレームであって予め定められたサブフレームで送信するようにしてもよい。これにより、確認情報に、予約されたリソースの各々の時間方向のリソースを示す情報を含める必要がなくなるため、確認情報のデータ量を削減することが可能になる。
【０１２５】
また、実施の形態によれば、Ｄ２Ｄをサポートするユーザ装置が実行する信号送信方法であって、予約されたリソースでＤ２Ｄ信号を送信するステップと、前記予約されたリソースでＤ２Ｄ信号が送信される前に、前記予約されたリソースでＤ２Ｄ信号を送信することを他のユーザ装置に通知するための確認情報を送信するステップと、を有する信号送信方法が提供される。この信号送信方法によれば、ユーザ装置が実際にＤ２Ｄ信号の送信に用いるリソースを他のユーザ装置に通知することを可能にする技術が提供される。
【０１２６】
＜実施形態の補足＞
「周期的なリソース」、「予約したリソース」及び「予約されたリソース」は、セミパーシステント（Semi-Persistent）なリソースと呼ばれてもよいし、セミパーシステントにスケジューリングされたリソースと呼ばれてもよい。
【０１２７】
ＳＣ期間は、ＳＡ期間（Scheduling Assignment Period）と呼ばれてもよいし、又は、ＰＳＣＣＨ期間と呼ばれてもよい。ＳＣＩは、ＳＡ（Scheduling Assignment）と呼ばれてもよい。
【０１２８】
ＰＳＣＣＨは、Ｄ２Ｄ通信に用いられる制御情報（ＳＣＩ等）を送信するための制御チャネルであれば他の制御チャネルであってもよい。ＰＳＳＣＨは、Ｄ２ＤコミュニケーションのＤ２Ｄ通信に用いられるデータ（ＭＡＣ  ＰＤＵ等）を送信するためのデータチャネルであれば他のデータチャネルであってもよい。ＰＳＤＣＨは、Ｄ２ＤディスカバリのＤ２Ｄ通信に用いられるデータ（ディスカバリメッセージ等）を送信するためのデータチャネルであれば他のデータチャネルであってもよい。
【０１２９】
本明細書で説明した各態様／実施形態は、ＬＴＥ（Long  Term  Evolution）、ＬＴＥ−Ａ（LTE-Advanced）、ＳＵＰＥＲ  ３Ｇ、ＩＭＴ−Ａｄｖａｎｃｅｄ、４Ｇ、５Ｇ、ＦＲＡ（Future  Radio  Access）、Ｗ−ＣＤＭＡ（登録商標）、ＧＳＭ（登録商標）、ＣＤＭＡ２０００、ＵＭＢ（Ultra  Mobile  Broadband）、ＩＥＥＥ  ８０２．１１（Ｗｉ−Ｆｉ）、ＩＥＥＥ  ８０２．１６（ＷｉＭＡＸ）、ＩＥＥＥ  ８０２．２０、ＵＷＢ（Ultra-WideBand）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、その他の適切なシステムを利用するシステム及び／又はこれらに基づいて拡張された次世代システムに適用されてもよい。
【０１３０】
本明細書で説明した各態様／実施形態の処理手順、シーケンス、フローチャートなどは、矛盾の無い限り、順序を入れ替えてもよい。例えば、本明細書で説明した方法については、例示的な順序で様々なステップの要素を提示しており、提示した特定の順序に限定されない。
入出力された情報等は特定の場所(例えば、メモリ)に保存されてもよいし、管理テーブルで管理してもよい。入出力される情報等は、上書き、更新、または追記され得る。出力された情報等は削除されてもよい。入力された情報等は他の装置へ送信されてもよい。
【０１３１】
判定（判断）は、１ビットで表される値（０か１か）によって行われてもよいし、真偽値（Boolean：trueまたはfalse）によって行われてもよいし、数値の比較（例えば、所定の値との比較）によって行われてもよい。
【０１３２】
本明細書で説明した情報、信号などは、様々な異なる技術のいずれかを使用して表されてもよい。例えば、上記の説明全体に渡って言及され得るデータ、命令、コマンド、情報、信号、ビット、シンボル、チップなどは、電圧、電流、電磁波、磁界若しくは磁性粒子、光場若しくは光子、又はこれらの任意の組み合わせによって表されてもよい。
【０１３３】
本明細書で使用する「に基づいて」という記載は、別段に明記されていない限り、「のみに基づいて」を意味しない。言い換えれば、「に基づいて」という記載は、「のみに基づいて」と「に少なくとも基づいて」の両方を意味する。
【０１３４】
本明細書で使用する「第一の」、「第二の」などの呼称を使用した要素へのいかなる参照も、それらの要素の量または順序を全般的に限定するものではない。これらの呼称は、２つ以上の要素間を区別する便利な方法として本明細書で使用され得る。したがって、第一および第二の要素への参照は、２つの要素のみがそこで採用され得ること、または何らかの形で第一の要素が第二の要素に先行しなければならないことを意味しない。
【０１３５】
「含む(ｉｎｃｌｕｄｉｎｇ)」、「含んでいる（ｃｏｍｐｒｉｓｉｎｇ）」、およびそれらの変形が、本明細書あるいは特許請求の範囲で使用されている限り、これら用語は、用語「備える」と同様に、包括的であることが意図される。さらに、本明細書あるいは特許請求の範囲において使用されている用語「または（or）」は、排他的論理和ではないことが意図される。
【０１３６】
情報の通知は、本明細書で説明した態様／実施形態に限られず、他の方法で行われてもよい。例えば、情報の通知は、物理レイヤシグナリング（例えば、ＤＣＩ（Downlink  Control  Information）、ＵＣＩ（Uplink  Control  Information））、上位レイヤシグナリング（例えば、ＲＲＣシグナリング、ＭＡＣシグナリング、ブロードキャスト情報（ＭＩＢ（Master  Information  Block）、ＳＩＢ（System  Information  Block）））、その他の信号又はこれらの組み合わせによって実施されてもよい。また、ＲＲＣメッセージは、ＲＲＣシグナリングと呼ばれてもよい。また、ＲＲＣメッセージは、例えば、ＲＲＣ接続セットアップ（RRC Connection Setup）メッセージ、ＲＲＣ接続再構成（RRC Connection Reconfiguration）メッセージなどであってもよい。
【０１３７】
なお、本明細書で説明した用語及び／又は本明細書の理解に必要な用語については、同一の又は類似する意味を有する用語と置き換えてもよい。例えば、チャネル及び／又はシンボルは信号（シグナル）であってもよい。また、信号はメッセージであってもよい。
【０１３８】
ＵＥは、当業者によって、加入者局、モバイルユニット、加入者ユニット、ワイヤレスユニット、リモートユニット、モバイルデバイス、ワイヤレスデバイス、ワイヤレス通信デバイス、リモートデバイス、モバイル加入者局、アクセス端末、モバイル端末、ワイヤレス端末、リモート端末、ハンドセット、ユーザエージェント、モバイルクライアント、クライアント、またはいくつかの他の適切な用語で呼ばれる場合もある。
【０１３９】
本明細書で説明した各態様／実施形態は単独で用いてもよいし、組み合わせて用いてもよいし、実行に伴って切り替えて用いてもよい。また、所定の情報の通知（例えば、「Ｘであること」の通知）は、明示的に行うものに限られず、暗黙的（例えば、当該所定の情報の通知を行わない）ことによって行われてもよい。
【０１４０】
本明細書で使用する「判断(determining)」、「決定(determining)」という用語は、多種多様な動作を包含する場合がある。「判断」、「決定」は、例えば、計算(calculating)、算出(computing)、処理(processing)、導出(deriving)、調査(investigating)、探索(looking up)（例えば、テーブル、データベースまたは別のデータ構造での探索）、確認(ascertaining)した事を「判断」「決定」したとみなす事などを含み得る。また、「判断」、「決定」は、受信(receiving)（例えば、情報を受信すること）、送信(transmitting)(例えば、情報を送信すること)、入力(input)、出力(output)、アクセス(accessing)（例えば、メモリ中のデータにアクセスすること）した事を「判断」「決定」したとみなす事などを含み得る。また、「判断」、「決定」は、解決(resolving)、選択(selecting)、選定(choosing)、確立(establishing)、比較(comparing)などした事を「判断」「決定」したとみなす事を含み得る。つまり、「判断」「決定」は、何らかの動作を「判断」「決定」したとみなす事を含み得る。
【０１４１】
所定の情報の通知（例えば、「Ｘであること」の通知）は、明示的に行うものに限られず、暗黙的（例えば、当該所定の情報の通知を行わない）ことによって行われてもよい。
【０１４２】
以上、本発明について詳細に説明したが、当業者にとっては、本発明が本明細書中に説明した実施形態に限定されるものではないということは明らかである。本発明は、特許請求の範囲の記載により定まる本発明の趣旨及び範囲を逸脱することなく修正及び変更態様として実施することができる。したがって、本明細書の記載は、例示説明を目的とするものであり、本発明に対して何ら制限的な意味を有するものではない。
【０１４３】
以上、実施の形態において、有効データウィンドウは、予約されたリソースに対応づけられる所定の期間の一例である。
【０１４４】
本特許出願は２０１６年５月１２日に出願した日本国特許出願第２０１６−０９６５７３号に基づきその優先権を主張するものであり、日本国特許出願第２０１６−０９６５７３号の全内容を本願に援用する。
【符号の説明】
【０１４５】
ＵＥ  ユーザ装置
ｅＮＢ  基地局
１０１  信号送信部
１０１１  第一の信号送信部
１０１２  第二の信号送信部
１０２  信号受信部
１０３  生成部
１０４  検出部
１０５  選択部
２０１  信号送信部
２０２  信号受信部
２０３  通知部
１００１  プロセッサ
１００２  メモリ
１００３  ストレージ
１００４  通信装置
１００５  入力装置
１００６  出力装置
【図１】
2017195538.tif 000003
【図２】
2017195538.tif 000004
【図３】
2017195538.tif 000005
【図４】
2017195538.tif 000006
【図５】
2017195538.tif 000007
【図６】
2017195538.tif 000008
【図７】
2017195538.tif 000009
【図８】
2017195538.tif 000010
【図９】
2017195538.tif 000011
【図１０】
2017195538.tif 000012
【図１１】
2017195538.tif 000013
【図１２】
2017195538.tif 000014
【図１３】
2017195538.tif 000015
【図１４】
2017195538.tif 000016
【図１５】
2017195538.tif 000017
【図１６】
2017195538.tif 000018
【図１７】
2017195538.tif 000019
【図１８】
2017195538.tif 000020
【国際調査報告】
2017195538.tif 000021
2017195538.tif 000022