(57)【要約】      （修正有）【課題】センシング結果に基づいて信号を送信するためのリソースを選択する方式において、信号の衝突を抑制することが可能な技術を提供する。【解決手段】センシング用の時間ウィンドウで行われるセンシングの結果に基づいて、信号を送信するためのリソースを選択するユーザ装置であって、センシングの結果と当該ユーザ装置が送信する信号の送信間隔とに基づいて、センシング用の時間ウィンドウより後のリソース選択用の時間ウィンドウの中で信号を送信可能な１以上のリソースの候補を選択する選択部１０４と、選択された１以上のリソースの候補の中から、信号を送信するためのリソースを選択して送信する信号送信部１０１と、を有する。【選択図】図１８
2018026736.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
【非特許文献２】３ＧＰＰ  ＴＳ３６．３００  Ｖ１３．２．０（２０１５−１２）
【発明の概要】
【発明が解決しようとする課題】
【０００７】
Ｖ２Ｘの技術は、ＬＴＥで規定されているＤ２Ｄの技術をベースとしている。当該Ｄ２Ｄの技術において、ユーザ装置がＤ２Ｄ信号を送信するリソースを選択する方式として、大別して、基地局からダイナミックにリソースを割り当てる方式と、ユーザ装置が自律的にリソースを選択する方式がある。Ｖ２Ｘ、特に、Ｖ２Ｖでは、ユーザ装置（例：自動車）は高密度に存在し、高速に移動するので、ダイナミックにリソースを割り当てる方式では非効率であることから、ユーザ装置が自律的にリソースを選択する方式が用いられることが想定される。また、Ｖ２Ｘでは、ユーザ装置は、周期的なデータ送信を実現するために、将来の送信リソースを予約（Reservation）し、予約したリソースを使用してＤ２Ｄ信号を送信することも想定されている。
【０００８】
ここで、複数のユーザ装置が自律的に送信リソースを選択（再選択を含む）する際に、各ユーザ装置が自由にリソースを選択及び予約するとなると、リソースの衝突が生じ、受信側のユーザ装置は信号を適切に受信できなくなる。そこで、３ＧＰＰでは、リソースのセンシングを行って、使用ないし予約（占有と呼んでもよい）されていないリソースの選択を行うセンシングベースのリソース選択方式が提案されている。
【０００９】
ここで、特にＶ２Ｖでは、例えば１００ｍｓ間隔、５００ｍｓ間隔などの周期でデータを送信することが想定されているため、ユーザ装置は、センシング結果に基づいてリソースを選択する際、自身が所望するデータの送信間隔を考慮してリソースを選択するのが望ましい。しかしながら、現状３ＧＰＰに提案されているセンシングベースのリソース選択方式では、送信される信号の送信間隔が考慮されていない。つまり、現状のリソース選択方式では、選択されたリソースで１回目のデータ送信は行うことは可能であるが、２回目以降のデータ送信ではリソースが衝突してしまう可能性があるという問題がある。
【００１０】
開示の技術は上記に鑑みてなされたものであって、センシング結果に基づいて信号を送信するためのリソースを選択する方式において、信号の衝突を抑制することが可能な技術を提供することを目的とする。
【課題を解決するための手段】
【００１１】
開示の技術のユーザ装置は、センシング用の時間ウィンドウで行われるセンシングの結果に基づいて、信号を送信するためのリソースを選択するユーザ装置であって、前記センシングの結果と当該ユーザ装置が送信する信号の送信間隔とに基づいて、前記センシング用の時間ウィンドウより後のリソース選択用の時間ウィンドウの中で信号を送信可能な１以上のリソースの候補を選択する選択部と、選択された１以上のリソースの候補の中から、信号を送信するためのリソースを選択して送信する送信部と、を有する。
【発明の効果】
【００１２】
開示の技術によれば、センシング結果に基づいて信号を送信するためのリソースを選択する方式において、信号の衝突を抑制することが可能な技術が提供される。
【図面の簡単な説明】
【００１３】
【図１】Ｖ２Ｘを説明するための図である。
【図２】Ｄ２Ｄを説明するための図である。
【図３】Ｄ２Ｄ通信に用いられるＭＡＣ  ＰＤＵを説明するための図である。
【図４】ＳＬ−ＳＣＨ  ｓｕｂｈｅａｄｅｒのフォーマットを説明するための図である。
【図５】Ｄ２Ｄで使用されるチャネル構造の例を説明するための図である。
【図６】ＰＳＤＣＨの構造例を示す図である。
【図７】ＰＳＣＣＨとＰＳＳＣＨの構造例を示す図である。
【図８】リソースプールコンフィギュレーションを示す図である。
【図９】実施の形態に係る無線通信システムの構成例を示す図である。
【図１０】センシングベースのリソース選択方式を説明するための図である。
【図１１】リソース選択方式（その１−１）の具体例を説明するための図である。
【図１２】リソース選択方式（その１−１）の具体例を説明するための図である。
【図１３】リソース選択方式（その１−２）の具体例を説明するための図である。
【図１４】リソース選択方式（その１−２）の具体例を説明するための図である。
【図１５】リソース選択方式（その２）を説明するためのフローチャートである。
【図１６】リソース選択方式（その２）の具体例を説明するための図である。
【図１７】リソース選択方式（その２）の具体例を説明するための図である。
【図１８】実施の形態に係るユーザ装置の機能構成の一例を示す図である。
【図１９】実施の形態に係る基地局の機能構成の一例を示す図である。
【図２０】実施の形態に係る基地局及びユーザ装置のハードウェア構成の一例を示す図である。
【発明を実施するための形態】
【００１４】
以下、図面を参照して本発明の実施の形態を説明する。なお、以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。例えば、本実施の形態に係る無線通信システムはＬＴＥに準拠した方式のシステムを想定しているが、本発明はＬＴＥに限定されるわけではなく、他の方式にも適用可能である。なお、本明細書及び特許請求の範囲において、「ＬＴＥ」は、３ＧＰＰのリリース８、又は９に対応する通信方式のみならず、３ＧＰＰのリリース１０、１１、１２、１３、又はリリース１４以降に対応する第５世代の通信方式も含む広い意味で使用する。
【００１５】
また、本実施の形態は、主にＶ２Ｘを対象としているが、本実施の形態に係る技術は、Ｖ２Ｘに限らず、広くＤ２Ｄ全般に適用可能である。また、「Ｄ２Ｄ」はその意味としてＶ２Ｘを含むものである。また、「Ｄ２Ｄ」の用語は、ＬＴＥにおけるＤ２Ｄに限らず、端末間通信全般を指すものである。
【００１６】
また、「Ｄ２Ｄ」は、ユーザ装置ＵＥ間でＤ２Ｄ信号を送受信する処理手順のみならず、Ｄ２Ｄ信号を基地局が受信（モニタ）する処理手順、及び、ＲＲＣ  ｉｄｌｅの場合若しくは基地局ｅＮＢとコネクションを確立していない場合に、ユーザ装置ＵＥが基地局ｅＮＢに上り信号を送信する処理手順を含む広い意味で使用する。
【００１７】
＜Ｄ２Ｄの概要＞
まず、ＬＴＥで規定されているＤ２Ｄの概要について説明する。なお、Ｖ２Ｘにおいても、ここで説明するＤ２Ｄの技術を使用することは可能であり、本発明の実施の形態におけるユーザ装置ＵＥは、当該技術によるＤ２Ｄ信号の送受信を行うことができる。
【００１８】
既に説明したように、Ｄ２Ｄには、大きく分けて「Ｄ２Ｄディスカバリ」と「Ｄ２Ｄコミュニケーション」がある。「Ｄ２Ｄディスカバリ」については、図２（ａ）に示すように、Ｄｉｓｃｏｖｅｒｙ  ｐｅｒｉｏｄ（ＰＳＤＣＨ（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）が挿入される構造になっている。
【００２６】
図７（ａ）に、「Ｄ２Ｄコミュニケーション」に使用されるＰＳＣＣＨとＰＳＳＣＨのリソースプールの例を示す。図７（ａ）に示すとおり、ＰＳＣＣＨは、周波数ホッピングしながら、１回繰り返し送信（ｒｅｐｅｔｉｔｉｏｎ）がなされる。ＰＳＳＣＨは、周波数ホッピングしながら、３回繰り返し送信（ｒｅｐｅｔｉｔｉｏｎ）がなされる。また、図７（ｂ）に示すように、ＰＳＣＣＨとＰＳＳＣＨはＰＵＳＣＨベースの構造を有し、ＤＭＲＳが挿入される構造になっている。
【００２７】
図８に、ＰＳＣＣＨ、ＰＳＤＣＨ、ＰＳＳＣＨ（Ｍｏｄｅ２）におけるリソースプールコンフィギュレーションの例を示す。図８（ａ）に示すように、時間方向では、リソースプールはサブフレームビットマップとして表される。また、ビットマップは、ｎｕｍ．ｒｅｐｒｔｉｔｉｏｎの回数だけ繰り返される。また、各周期における開始位置を示すｏｆｆｓｅｔが指定される。
【００２８】
周波数方向では、連続割り当て（ｃｏｎｔｉｇｕｏｕｓ）と不連続割り当て（ｎｏｎ−ｃｏｎｔｉｇｕｏｕｓ）が可能である。図８（ｂ）は、不連続割り当ての例を示しており、図示のとおり、開始ＰＲＢ、終了ＰＲＢ、ＰＲＢ数（ｎｕｍＰＲＢ）が指定される。
【００２９】
＜システム構成＞
図９は、実施の形態に係る無線通信システムの構成例を示す図である。図９に示すように、本実施の形態に係る無線通信システムは、基地局ｅＮＢ、ユーザ装置ＵＥ１、及びユーザ装置ＵＥ２を有する。図９において、ユーザ装置ＵＥ１は送信側、ユーザ装置ＵＥ２は受信側を意図しているが、ユーザ装置ＵＥ１とユーザ装置ＵＥ２はいずれも送信機能と受信機能の両方を備える。以下、ユーザ装置ＵＥ１とユーザ装置ＵＥ２を特に区別しない場合、単に「ユーザ装置ＵＥ」と記述する。
【００３０】
図９に示すユーザ装置ＵＥ１及びユーザ装置ＵＥ２は、それぞれ、ＬＴＥにおけるユーザ装置ＵＥとしてのセルラ通信の機能、及び、上述したチャネルでの信号送受信を含むＤ２Ｄ機能を有している。また、ユーザ装置ＵＥ１、ユーザ装置ＵＥ２は、本実施の形態で説明する動作を実行する機能を有している。なお、セルラ通信の機能及び既存のＤ２Ｄの機能については、一部の機能（本実施の形態で説明する動作を実行できる範囲）のみを有していてもよいし、全ての機能を有していてもよい。
【００３１】
また、ユーザ装置ＵＥは、Ｄ２Ｄの機能を有するいかなる装置であってもよいが、例えば、ユーザ装置ＵＥは、車両、歩行者が保持する端末、ＲＳＵ（ＵＥの機能を有するＵＥタイプＲＳＵ）等である。
【００３２】
また、基地局ｅＮＢについては、ＬＴＥにおける基地局ｅＮＢとしてのセルラ通信の機能、及び、本実施の形態におけるユーザ装置ＵＥの通信を可能ならしめるための機能（設定情報通知機能等）を有している。また、基地局ｅＮＢはＲＳＵ（ｅＮＢの機能を有するｅＮＢタイプＲＳＵ）を含む。
【００３３】
以下の説明において、「センシング」とは、例えば、受信電力（受信エネルギ、又は受信強度と称してもよい）の測定結果を用いる方法、Ｄ２Ｄ制御情報のデコード結果を用いる方法（すなわち、他のユーザ装置ＵＥから送信されるＤ２Ｄ制御情報を受信し、デコードすることで、他のユーザ装置ＵＥにより予約されているリソース位置を検知する方法）、又はこれらを組み合わせることなどにより行われる。また、「リソース」とは、特に断りの無い限り、時間リソース（例：サブフレーム）、若しくは、時間及び周波数リソースを含む。また「Ｄ２Ｄ信号」は、Ｄ２Ｄコミュニケーションの信号（Ｄ２Ｄ制御情報であってもよいし、データであってもよいし、Ｄ２Ｄ制御情報とデータの組であってもよい）である前提で説明するが、これに限られず、Ｄ２Ｄディスカバリのメッセージ（発見信号）であってもよい。
【００３４】
本実施の形態に係るユーザ装置ＵＥは、以下に示すセンシングベースのリソース選択方式を用いてＤ２Ｄ信号を送信するリソースを選択し、選択したリソースで、ユーザ装置ＵＥ自身が所望する送信間隔でＤ２Ｄ信号を送信する。なお、ユーザ装置ＵＥは、選択したリソースで送信されるＤ２Ｄ制御情報に、次の送信間隔後にＤ２Ｄ信号を送信するためのリソースを予約することを示す予約情報を含めることで、他のユーザ装置ＵＥに、自身が予約しているリソースを把握させるようにしてもよい。
【００３５】
＜３ＧＰＰで検討されているリソース選択方式について＞
ここで、現在の３ＧＰＰで提案されているリソース選択方式について説明する。３ＧＰＰで提案されているリソース選択方式は、以下に示す３つのステップの手順で実現される。
ＳＴＥＰ１：Ｄ２Ｄ信号を送信可能な全てのリソース（例えば、Ｄ２Ｄリソースプール）を利用可能（予約されていない）とみなす。
ＳＴＥＰ２：ＳＴＥＰ１で利用可能とみなしたリソースのうち、他のユーザ装置ＵＥから送信されるＤ２Ｄ制御情報をデコードすることで把握される予約済みリソースを除外する。あるいは、ＳＴＥＰ１で利用可能とみなしたリソースのうち、他のユーザ装置ＵＥから送信されるＤ２Ｄ制御情報をデコードすることで把握される予約済みリソースであり、かつ、所定の条件を満たすリソースを除外する。所定の条件とは、例えば、Ｄ２Ｄ制御情報が示すデータ用リソース（例えばＰＳＳＣＨのリソース）にマッピングされているＤＭ−ＲＳ（Demodulation Reference Signal）の電力が所定の閾値以上である場合、又は、Ｄ２Ｄ制御情報のリソースを測定した結果から推定される、Ｄ２Ｄ制御情報が示すデータ用リソースの電力が所定の閾値以上である場合などである。
ＳＴＥＰ３：Ｄ２Ｄ信号を送信可能なリソース（例えば、Ｄ２Ｄリソースプール）の全部（又は予め定められた一部（例えば、ＰＳＳＣＨを送信可能なリソースであり、以下の説明でも同様））の受信電力を測定し、測定結果に基づく一部のリソース（例えば、受信電力が所定の閾値以上であるリソース）を、ＳＴＥＰ２で除外された残りのリソースから更に除外することで、最終的なリソース選択候補となるリソースのサブセットを選択する。つまり、当該最終的なリソース選択候補となるリソースのサブセットには、ＳＴＥＰ２で除外対象とならず、更に、ＳＴＥＰ３でも除外対象とならなかったリソースが残ることになる。続いて、ユーザ装置ＵＥは、当該最終的なリソース選択候補となるリソースのサブセットの中から、実際にデータ送信に用いる１つのリソースをランダムに選択する。
【００３６】
なお、上記のＳＴＥＰ３において、ＳＴＥＰ２で除外されなかったリソースの中から直接、データ送信に用いる１つのリソースを選択することも考えられる。しかしながら、ユーザ装置ＵＥがＤ２Ｄ制御信号のデコードに失敗することも想定されるため、ＳＴＥＰ２に加えてＳＴＥＰ３でもリソースの除外を行うことが提案されている。
【００３７】
なお、現在の検討では、ＳＴＥＰ３において、ユーザ装置ＵＥは、リソースのサブセットの中から、実際にデータ送信に用いる１つのリソースをランダムに選択することが提案されているのみである。つまり、前述したように、現状３ＧＰＰに提案されているセンシングベースのリソース選択方式では、送信されるＤ２Ｄ信号の送信間隔が考慮されていない。そこで、本実施の形態では、上記ＳＴＥＰ１〜３の手順をベースとしつつ、一部の手順を変更することで、ユーザ装置ＵＥから送信されるＤ２Ｄ信号の送信間隔を考慮したリソース選択を可能にする。
【００３８】
＜実施の形態に係るリソース選択方式について＞
続いて、本実施の形態に係るユーザ装置ＵＥが行うセンシングベースのリソース選択方式について説明する。
【００３９】
（センシングベースのリソース選択方式の概要について）
まず、センシングベースのリソース選択方式について概要を説明する。本実施の形態に係るユーザ装置ＵＥは、当該センシングベースのリソース選択方式を実行する機能を有している。
【００４０】
図１０において、サブフレームｎは現在のサブフレームを示している。「センシングウィンドウ」とは、ユーザ装置ＵＥがセンシングを行うべきとして予め定められた時間ウィンドウである。ユーザ装置ＵＥは、センシングウィンドウの期間でセンシングを行うことで、将来のリソースの予約状況を把握する。例えば、センシングウィンドウでセンシングを行った結果、ユーザ装置ＵＥは、図１０に示すリソースＡ２〜Ａ１０で送信されるＤ２Ｄ制御信号を検出したとする。リソースＡ２〜Ａ１０で送信されるＤ２Ｄ制御信号に、それぞれ、リソースＢ２〜Ｂ１０を予約することを示す予約情報が含まれている場合、ユーザ装置ＵＥは、将来のリソースのうち、リソースＢ２〜Ｂ１０は既に予約されていることを把握することができる。なお、センシングウィンドウ内のリソースと将来のリソースとの間の対応関係は、Ｄ２Ｄ制御信号に含まれる予約情報により明示的に示されるか、又は、報知情報（ブロードキャスト情報）、ＲＲＣシグナリング若しくは標準仕様等で予め準静的に定められた対応関係（例えば、１０００ｍｓ後のリソースが予約されているとみなす等）に基づき暗示的に示される。
【００４１】
なお、センシングウィンドウの長さは、基本的には、本無線通信システムで通信を行う各ユーザ装置がＤ２Ｄ信号のリソースを予約可能な最大の期間以上に設定される前提である。例えば、各ユーザ装置ＵＥがＤ２Ｄ信号のリソースを予約可能な期間が最大１０００ｍｓである場合、センシング期間の長さは、１０００ｍｓ以上である。これは、センシング期間の長さが、各ユーザ装置がＤ２Ｄ信号のリソースを予約可能な最大の周期よりも短いと、センシングを行うユーザ装置ＵＥが、他のユーザ装置ＵＥが予約しているリソースを適切に把握することが困難になるためである。
【００４２】
「選択ウィンドウ」とは、センシング結果により予約されていないと判断された将来のリソースのうち、ユーザ装置ＵＥがリソースを選択すべき期間として予め定められた時間ウィンドウである。ユーザ装置ＵＥは、センシングを行うことで将来のリソースの予約状況を把握し、把握した予約されていないリソースのうち、選択ウィンドウ内に含まれるリソースの中からデータ送信に用いるリソースを選択する。
【００４３】
「選択ウィンドウ」が設けられることで、ユーザ装置ＵＥは、予約されていないリソースのうち、「選択ウィンドウ」の範囲内に限ってリソースを選択するように動作するため、データ送信時の遅延が短縮される。例えば、「選択ウィンドウ」が１００ｍｓに設定されている場合、ユーザ装置ＵＥは、１００ｍｓ以内で予約されていないリソースを選択することになる。もし、「選択ウィンドウ」が設定されていない場合、ユーザ装置ＵＥは、予約されていないリソースの中で任意のリソースを選択することになるため、データ送信が遅延する可能性がある。
【００４４】
センシングウィンドウ、及び選択ウィンドウの開始タイミング及び終了タイミングは、時間の経過に合わせてスライドしてもよい。例えば、センシングウィンドウの開始タイミングは、現在のサブフレームから所定のサブフレーム前のサブフレームであり、終了タイミングは、現在のサブフレームであってもよい。また、選択ウィンドウの開始タイミングは、現在のサブフレームであり、終了タイミングは、現在のサブフレームから所定のサブフレーム後のサブフレームであってもよい。また、センシングウィンドウ、及び選択ウィンドウの開始タイミング及び終了タイミングは、予め設定された周期的な期間（例えばＳＣ（Sidelink Control）期間）の境界のタイミングであってもよい。
【００４５】
（実施の形態に係るリソース選択方式について）
続いて、本実施の形態に係るユーザ装置ＵＥが行うセンシングベースのリソース選択方式について説明する。本実施の形態に係るユーザ装置ＵＥは、「＜３ＧＰＰで検討されているリソース選択方式について＞」で説明したＳＴＥＰ１〜３の手順のうち一部の手順を変更することで、ユーザ装置ＵＥから送信されるＤ２Ｄ信号の送信間隔を考慮したリソース選択を行う。
【００４６】
［リソース選択方式（その１−１）］
リソース選択方式（その１−１）では、ＳＴＥＰ３において、Ｄ２Ｄ信号を送信可能なリソースで受信電力の測定を行う際に、ユーザ装置ＵＥが所望するＤ２Ｄ信号の送信間隔を考慮して受信電力の測定を行う。より具体的には、ユーザ装置ＵＥは、以下の手順でリソース選択を行う。なお、特に言及しない点は、「＜３ＧＰＰで検討されているリソース選択方式について＞」で説明した各ＳＴＥＰと同一でよい。
ＳＴＥＰ１：Ｄ２Ｄ信号を送信可能な将来のリソース（例えば、将来のＤ２Ｄリソースプール）を利用可能（予約されていない）とみなす。
ＳＴＥＰ２：ＳＴＥＰ１で利用可能とみなしたリソースのうち、センシングウィンドウ内で受信したＤ２Ｄ制御情報をデコードすることで把握される予約済みリソースを除外する。あるいは、ＳＴＥＰ１で利用可能とみなしたリソースのうち、他のユーザ装置ＵＥから送信されるＤ２Ｄ制御情報をデコードすることで把握される予約済みリソースであり、かつ、所定の条件を満たすリソースを除外する。例えば、前述した図１０の例では、将来のリソースのうち、リソースＢ１〜Ｂ１０が除外される。
ＳＴＥＰ３：センシングウィンドウ内のリソースの全部（又は予め定められた一部）の受信電力を測定し、測定結果に基づいて把握される一部のリソースと対応関係を有する将来のリソースを、ＳＴＥＰ２で除外された残りのリソースから更に除外することで、最終的なリソース選択候補となるリソースのサブセットを選択する。続いて、ユーザ装置ＵＥは、当該最終的なリソース選択候補となるリソースのサブセットの中で、かつ選択ウィンドウ内に存在するリソースの中から、実際にデータ送信に用いる１つのリソースをランダムに選択する。
【００４７】
ＳＴＥＰ３で、ユーザ装置ＵＥは、最終的なリソース選択候補となるリソースのサブセットのうち、選択ウィンドウ内で選択可能なリソース（空きリソース）を検出し、過去の時間方向において当該空きリソースよりも１つ送信間隔前のリソースの受信電力の測定結果が所定の条件を満たす場合、当該空きリソースを、最終的なリソース選択候補となるリソースのサブセットから更に除外する。所定の条件とは、例えば、受信電力の測定結果が所定の閾値以上である場合である。もし、選択ウィンドウ内で選択可能なリソース（空きリソース）が複数存在する場合、これら複数の空きリソースについても同様の処理が行われる。
【００４８】
図１１及び図１２を用いて具体例を説明する。図１１及び図１２において、リソースＡ２〜Ａ１０は、他のユーザ装置ＵＥからＤ２Ｄ信号が送信されたリソースである。また、リソースＡ２〜Ａ１０と対応関係にあるリソースＢ２〜Ｂ１０が予約されているとする。図１１は、ユーザ装置ＵＥが所望するＤ２Ｄ信号の送信間隔が１００ｍｓである場合を示しており、図１２は、ユーザ装置ＵＥが所望するＤ２Ｄ信号の送信間隔が１０００ｍｓである場合を示している。
【００４９】
例えば、図１１において、ユーザ装置ＵＥは、選択ウィンドウ内で選択可能なリソース（空きリソース）としてリソースＢ１を検出する。続いて、ユーザ装置ＵＥは、リソースＢ１よりも、１つ前の送信間隔（つまり１００ｍｓ前）のリソースＡ１０の受信電力の測定結果が所定の閾値以上であるか否かを判定する。図１１の例では、リソースＡ１０では他のユーザ装置ＵＥからＤ２Ｄ信号が送信されているため、他のユーザ装置ＵＥとの距離が近い場合はある程度大きな受信電力が測定される。もし、リソースＡ１０の受信電力の測定結果が所定の閾値以上である場合、ユーザ装置ＵＥは、リソースＢ１を、最終的なリソース選択候補となるリソースのサブセットから除外する。この場合、最終的なリソース選択候補となるリソースのサブセットにはリソースＢ１は含まれないため、ユーザ装置ＵＥは、実際にデータ送信に用いるリソースとして、リソースＢ１以外を選択することになる。
【００５０】
同様に、図１２において、ユーザ装置ＵＥは、選択ウィンドウ内で選択可能なリソース（空きリソース）としてリソースＢ１を検出する。続いて、ユーザ装置ＵＥは、リソースＢ１よりも、１つ前の送信間隔（つまり１０００ｍｓ前）のリソースＡ１の受信電力の測定結果が所定の閾値以上であるか否かを判定する。図１２の例では、リソースＡ１では他のユーザ装置ＵＥからＤ２Ｄ信号が送信されていないため、受信電力は低い（例えば雑音電力のみ等）と想定される。従って、図１２の例では、ユーザ装置ＵＥは、リソースＢ１を、最終的なリソース選択候補となるリソースのサブセットから除外しないことになる。この場合、最終的なリソース選択候補となるリソースのサブセットにはリソースＢ１も含まるため、実際にデータ送信に用いるリソースとして、リソースＢ１が選択され得る。
【００５１】
［リソース選択方式（その１−２）］
リソース選択方式（その１−２）も、ＳＴＥＰ３において、Ｄ２Ｄ信号を送信可能なリソースで受信電力の測定を行う際に、ユーザ装置ＵＥが所望するＤ２Ｄ信号の送信間隔を考慮して受信電力の測定を行う。特に言及しない点は、リソース選択方式（その１−１）と同一でよい。ＳＴＥＰ１及びＳＴＥＰ２は、リソース選択方式（その１−１）と同一であるため説明は省略する。
ＳＴＥＰ３：センシングウィンドウ内のリソースの全部（又は予め定められた一部）の受信電力を測定し、測定結果に基づいて把握される一部のリソースと対応関係を有する将来のリソースを、ＳＴＥＰ２で除外された残りのリソースから更に除外することで、最終的なリソース選択候補となるリソースのサブセットを選択する。続いて、ユーザ装置ＵＥは、当該最終的なリソース選択候補となるリソースのサブセットの中で、かつ選択ウィンドウ内に存在するリソースの中から、実際にデータ送信に用いる１つのリソースをランダムに選択する。
【００５２】
ＳＴＥＰ３で、ユーザ装置ＵＥは、最終的なリソース選択候補となるリソースのサブセットのうち、選択ウィンドウ内で選択可能なリソース（空きリソース）を検出し、過去の時間方向において当該空きリソースを起点として送信間隔で繰り返される複数のリソースごとの受信電力の測定結果が所定の条件を満たす場合、当該空きリソースを、最終的なリソース選択候補となるリソースのサブセットから更に除外する。ここで、測定対象となる複数のリソースは、例えばリソース選択候補のリソース（当該空きリソース）から遡って特定の時間周期で定められる同一周波数位置のリソースかつセンシングウィンドウ内のリソースである。特定の時間周期は、単一または複数の周期であり、予め定められたり、事前設定されたり、基地局ｅＮＢから報知情報（ブロードキャスト情報）又は上位レイヤシグナリングで通知されてもよい。リソース選択を行なっているユーザ装置ＵＥの送信周期（予約間隔）であってもよい。所定の条件は、例えば、当該空きリソースを起点として送信間隔で繰り返される複数のリソースごとの受信電力の平均値が所定の閾値以上である場合である。これに限られず、最大値又は最小値が所定の閾値以上である場合であってもよい。もし、選択ウィンドウ内で選択可能なリソース（空きリソース）が複数存在する場合、これら複数の空きリソースについても同様の処理が行われる。
【００５３】
図１３及び図１４を用いて具体例を説明する。図１３及び図１４において、リソースＡ２〜Ａ１０は、他のユーザ装置ＵＥからＤ２Ｄ信号が送信されたリソースである。また、リソースＡ２〜Ａ１０と対応関係にあるリソースＢ２〜Ｂ１０が予約されているとする。図１３は、ユーザ装置ＵＥが所望するＤ２Ｄ信号の送信間隔が１００ｍｓである場合を示しており、図１４は、ユーザ装置ＵＥが所望するＤ２Ｄ信号の送信間隔が１０００ｍｓである場合を示している。また、上述の所定の条件は、複数のリソースごとの受信電力の平均値が所定の閾値以上である場合とする。
【００５４】
例えば、図１３において、ユーザ装置ＵＥは、選択ウィンドウ内で選択可能なリソース（空きリソース）としてリソースＢ１を検出する。続いて、ユーザ装置ＵＥは、リソースＢ１を起点として送信間隔で繰り返される複数のリソースＡ１〜Ａ１０のそれぞれの受信電力の測定結果の平均値が所定の閾値以上であるか否かを判定する。図１３の例では、リソースＡ２〜Ａ１０では他のユーザ装置ＵＥからＤ２Ｄ信号が送信されているため、受信電力の平均値はある程度大きくなると想定される。もし、リソースＡ１〜Ａ１０の受信電力の平均値が所定の閾値以上である場合、ユーザ装置ＵＥは、リソースＢ１を、最終的なリソース選択候補となるリソースのサブセットから除外する。
【００５５】
同様に、図１４において、ユーザ装置ＵＥは、選択ウィンドウ内で選択可能なリソース（空きリソース）としてリソースＢ１を検出する。続いて、ユーザ装置ＵＥは、リソースＢ１を起点として送信間隔で繰り返される複数のリソースのそれぞれの受信電力の測定結果の平均値が所定の閾値以上であるか否かを判定する。図１４の例では、送信間隔が１０００ｍｓであることから、リソースＡ１のみが該当する。図１４の例では、リソースＡ１では他のユーザ装置ＵＥからＤ２Ｄ信号が送信されていないため、受信電力は低い（例えば雑音電力のみ等）と想定される。従って、図１４の例では、ユーザ装置ＵＥは、リソースＢ１を、最終的なリソース選択候補となるリソースのサブセットから除外しないことになる。この場合、最終的なリソース選択候補となるリソースのサブセットにはリソースＢ１も含まるため、実際にデータ送信に用いるリソースとして、リソースＢ１が選択され得る。
【００５６】
なお、リソース選択方式（その１−１）及びリソース選択方式（その１−２）において、ユーザ装置ＵＥが選択し得る送信間隔（リソース予約周期）を限定するようにしてもよい。例えば、１００ｍｓ、２００ｍｓ、及び、１０００ｍｓに限定するなど、より大きな予約周期が小さな予約周期で割り切れる周期の組み合わせに限定するようにしてもよい。
【００５７】
例えば、ユーザ装置ＵＥは、選択ウィンドウ内で選択可能なリソースから２００ｍｓ後のリソースＸでデータを送信予定であると仮定する。もし、５００ｍｓ周期で信号を送信予定の他のユーザ装置ＵＥもリソースＸでデータを送信予定であるという場合、当該他のユーザ装置ＵＥは、リソースＸから５００ｍｓ前のリソースＹでＤ２Ｄ信号を送信済みである。しかしながら、例えばリソース選択方式（その１−２）では、ユーザ装置ＵＥがＳＴＥＰ３で受信電力を測定する１又は複数のリソースは、リソースＸから４００ｍｓ前、６００ｍｓ前、８００ｍｓ前というように２００ｍｓ間隔のリソースとなり、リソースＹが含まれないことになる。すなわち、測定漏れが生じてしまうことになる。そこで、ユーザ装置ＵＥが選択し得る送信間隔（リソース予約周期）を上述のように限定することで、測定漏れが生じてしまうのを回避することができる。
【００５８】
以上、リソース選択方式（その１−１）及びリソース選択方式（その１−２）について説明した。図１１及び図１３に示すように、リソースＢ２〜Ｂ１０は予約されている。つまり、ユーザ装置ＵＥが所望の送信間隔が１００ｍｓである場合に、仮にユーザ装置ＵＥがリソースＢ１を選択してデータ送信を行うと、１回目のデータ送信については衝突が発生しないものの、２回目以降のデータ送信（リソースＢ２〜Ｂ１０でのデータ送信）では衝突が発生してしまうことになる。しかしながら、リソース選択方式（その１−１）及びリソース選択方式（その１−２）によれば、２回目以降のデータ送信で衝突の発生が予測されるリソースは、最終的なリソース選択候補となるリソースのサブセットから除外されるため、衝突の発生を抑制することが可能である。また、リソース選択方式（その１−１）及びリソース選択方式（その１−２）では、Ｄ２Ｄ制御情報のデコード結果に加えて、センシングウィンドウ内のリソースの受信電力を測定した結果を用いることで、将来のリソースの予約状況を判定するようにした。これにより、Ｄ２Ｄ制御情報のデコード結果のみで将来のリソースの予約状況を判定する方法よりも、衝突の発生を抑制することができる。
【００５９】
また、リソース選択方式（その１−２）は、リソース選択方式（その１−１）と異なり、ＳＴＥＰ３において、選択ウィンドウ内で選択可能なリソース（空きリソース）を起点として送信間隔で繰り返される複数のリソースごとの受信電力の測定結果が所定の条件を満たす場合、当該空きリソースを、最終的なリソース選択候補となるリソースのサブセットから除外するようにした。もし、図１１のリソースＡ１０で他のユーザ装置ＵＥからＤ２Ｄ信号が送信されていない場合、リソース選択方式（その１−１）では、リソースＢ１は最終的なリソース選択候補となるリソースのサブセットから除外されないことになる。一方、リソース選択方式（その１−２）では、仮にリソースＡ１０で他のユーザ装置ＵＥからＤ２Ｄ信号が送信されていない場合であっても、リソースＡ１０以外のリソース（リソースＡ２〜Ａ９）の受信電力の測定結果も考慮することが可能であるため、リソースＢ１を最終的なリソース選択候補となるリソースのサブセットから除外することができる。つまり、リソース選択方式（その１−２）は、リソース選択方式（その１−１）と比較して衝突の発生を更に抑制することが可能である。
【００６０】
［リソース選択方式（その２）］
リソース選択方式（その２）では、ＳＴＥＰ２とＳＴＥＰ３との間に新たな処理手順を追加することで、ＳＴＥＰ３における最終的なリソース選択候補となるリソースのサブセットから、ユーザ装置ＵＥが所望する送信間隔でデータ送信を行うことができないリソースを除外することで、衝突の発生を抑制することを可能にする。
【００６１】
図１５は、リソース選択方式（その２）を説明するためのフローチャートである。図１５において、「Ｔ１」は、ユーザ装置ＵＥが所望する送信間隔を示す。「ｋ」は１〜Ｋまでの正の整数である。「Ｋ」は正の整数であり、標準仕様等で予め固定的に定められていてもよいし、ＳＩＭ等によりユーザ装置ＵＥに事前設定（Preconfigure）されていてもよいし、基地局ｅＮＢ又はコアネットワークを介してユーザ装置ＵＥに設定されてもよい。
【００６２】
まず、ＳＴＥＰ１の手順を行ったユーザ装置ＵＥは、ＳＴＥＰ２の手順を用いてリソースを除外する（Ｓ１１）。ＳＴＥＰ１及びＳＴＥＰ２の手順はリソース選択方式（その１−１）と同一であるため説明は省略する。続いて、ユーザ装置ＵＥは、ＳＴＥＰ２の除外対象ではないリソースのうち選択ウィンドウ内に存在するリソースと、当該リソースを起点としてｋ×Ｔ１後の複数のリソースであってＳＴＥＰ２の除外対象と判定されたリソースとのサブセット（ＳＴＥＰ３で用いられるサブセットと区別するため、便宜上、「第二のサブセット」と呼ぶ）を特定する（Ｓ１２）。
【００６３】
図１６及び図１７を用いてステップＳ１２の処理手順を具体的に説明する。図１６及び図１７において、リソースＡ２〜Ａ１０は、他のユーザ装置ＵＥからＤ２Ｄ信号が送信されたリソースである。また、リソースＡ２〜Ａ１０と対応関係にあるリソースＢ２〜Ｂ１０は予約済みリソースであり、ＳＴＥＰ２で対象外と判定されたリソースであるとする。また、図１６ではＴ１＝１００ｍｓ及びＫ＝９であるとし、図１７では、Ｔ１＝１０００ｍｓ及びＫ＝１であるとする。図１６の場合、選択ウィンドウ内のリソースＢ１と、リソースＢ１から１００ｍｓ後（１×Ｔ１後）乃至９００ｍｓ後（９×Ｔ１後）までのリソースＢ２〜リソースＢ１０とが、第二のサブセットとして特定されることになる。一方、図１７の場合、第二のサブセットは特定されないことになる。
【００６４】
つまり、第二のサブセットに含まれるリソースは、ユーザ装置ＵＥが実際にデータ送信に用いるリソースとして好適ではないリソースであると言うこともできる。
【００６５】
続いて、ユーザ装置ＵＥは、ステップＳ１１で除外された残りのリソースから、更に第二のサブセットのリソースを除外した後のリソースの中に、ユーザ装置ＵＥが所望する送信周期（Ｔ１）で繰り返しデータ送信が可能な複数のリソース（つまり、予約されていない空きリソース）が含まれているか否かを判定する（Ｓ１３）。例えば、ユーザ装置ＵＥは、ステップＳ１１で除外された残りのリソースから、更に第二のサブセットのリソースを除外した後のリソースのうち、選択ウィンドウ内に１回目のデータ送信に利用可能なリソースが含まれており、そのリソースからｋ×Ｔ１後の複数のリソースについても予約されていないリソースであるか否かを判定するようにしてもよい。図１６の例では、Ｋ＝９の場合、ユーザ装置ＵＥは、リソースＢ１〜Ｂ１０までのリソースが全て空いているか否かを判定することになる。また、Ｋ＝２の場合、ユーザ装置ＵＥは、リソースＢ１〜Ｂ３までのリソースが全て空いているか否かを判定することになる。ステップＳ１３でＹＥＳの場合はステップＳ１４に進み、ステップＳ１３でＮＯの場合はステップＳ１５に進む。
【００６６】
続いて、ユーザ装置ＵＥは、ＳＴＥＰ２の除外対象ではなく、かつ、上記第二のサブセットに含まれないリソースについて、ＳＴＥＰ３の手順を用いてリソースを選択する（Ｓ１４）。言い換えると、ステップＳ１４は、以下に示すＳＴＥＰ３の手順を行うと定義することもできる。
ＳＴＥＰ３：センシングウィンドウ内のリソースの全部（又は予め定められた一部）の受信電力を測定し、測定結果に基づいて把握される一部のリソースと対応関係を有する将来のリソースと、第二のサブセットのリソースとを、ＳＴＥＰ２で除外された残りのリソースから更に除外することで、最終的なリソース選択候補となるリソースのサブセットを選択する。続いて、ユーザ装置ＵＥは、当該最終的なリソース選択候補となるリソースのサブセットの中で、かつ選択ウィンドウ内に存在するリソースの中から、実際にデータ送信に用いる１つのリソースをランダムに選択する。
【００６７】
なお、ユーザ装置ＵＥは、ステップＳ１４で、ＳＴＥＰ２の除外対象ではなく、上記第二のサブセットに含まれないリソースであって、かつ選択ウィンドウ内に存在するリソースの中から直接、実際にデータ送信に用いる１つのリソースをランダムに選択するようにしてもよい（つまり、ＳＴＥＰ３で行われる受信電力の測定結果に基づくリソースの除外を行わないようにしてもよい）。これにより、選択ウィンドウ内でより多くのリソースの中からデータ送信に用いるリソースを選択することができる。
【００６８】
続いて、ユーザ装置ＵＥは、ＳＴＥＰ２の除外対象ではないが、上記第二のサブセットには含まれるリソースの中で、ＳＴＥＰ３の手順を用いてリソースを選択する（Ｓ１５）。言い換えると、ステップＳ１５は、以下に示すＳＴＥＰ３の手順を行うと定義することもできる。
ＳＴＥＰ３：センシングウィンドウ内のリソースの全部（又は予め定められた一部）の受信電力を測定し、測定結果に基づいて把握される一部のリソースと対応関係を有する将来のリソースを、ＳＴＥＰ２で除外された残りのリソースから更に除外することで、最終的なリソース選択候補となるリソースのサブセットを選択する。続いて、ユーザ装置ＵＥは、当該最終的なリソース選択候補となるリソースのサブセットの中で、かつ選択ウィンドウ内に存在するリソースの中から、実際にデータ送信に用いる１つのリソースをランダムに選択する。なお、ユーザ装置ＵＥは、ステップＳ１５におけるＳＴＥＰ３に代えて、リソース選択方式（その１−１）又はリソース選択方式（その１−２）のＳＴＥＰ３の処理手順を実行するようにしてもよい。
【００６９】
以上、リソース選択方式（その２）について説明した。ユーザ装置ＵＥが所望する送信周期（Ｔ１）で繰り返しデータ送信が可能な複数のリソースが存在する（つまり予約されていない）場合はステップＳ１４に進むことになる。また、ステップＳ１４で、ユーザ装置ＵＥは、第二のサブセットに含まれるリソース（前述したように、好適ではないリソース）を、実際にデータ送信に用いるリソースとして選択することはない。つまり、ユーザ装置ＵＥが実際にデータ送信に用いる１つのリソースは、次の送信周期でもデータの送信が送信可能なリソースになるため、衝突の発生を抑制することが可能になる。
【００７０】
一方、ユーザ装置ＵＥが所望する送信周期（Ｔ１）で繰り返しデータ送信が可能な複数のリソースが存在しない（つまり予約されている）場合はステップＳ１５に進むことになる。ステップＳ１５の場合、ユーザ装置ＵＥは、第二のサブセットに含まれるリソースを、実際にデータ送信に用いるリソースとして選択する可能性がある。つまり、ステップＳ１５の場合、ユーザ装置ＵＥが実際にデータ送信に用いるリソースは、次の送信周期では衝突が発生する可能性が高いリソースである。そこで、ステップＳ１５では、ユーザ装置ＵＥは、実際にデータ送信に用いる１つのリソースを選択せずに、データの送信を諦める（中止する）ようにしてもよい。これにより、衝突の発生を抑制することが可能になる。
【００７１】
また、ユーザ装置ＵＥは、所定の時間が経過した後で、再度、図１５の処理手順を実行するようにしてもよい。これにより、リソースの混雑度合いが解消していた場合に、データの送信が可能になる。
【００７２】
また、ステップＳ１５に遷移する場合、ユーザ装置ＵＥは将来の送信リソースがすでに他のユーザ装置ＵＥに予約されているとみなしているため、リソース予約を行わないとしてもよい。これによって無駄な予約シグナリングを送信することを回避することができ、リソースの空間利用効率向上・早期のリソース再選択動作が期待される。
【００７３】
＜機能構成＞
（ユーザ装置）
図１８は、実施の形態に係るユーザ装置の機能構成の一例を示す図である。図１８に示すように、ユーザ装置ＵＥは、信号送信部１０１と、信号受信部１０２と、センシング部１０３と、選択部１０４とを有する。なお、図１８は、ユーザ装置ＵＥにおいて本発明の実施の形態に特に関連する機能部のみを示すものであり、少なくともＬＴＥに準拠した動作を行うための図示しない機能も有するものである。また、図１８に示す機能構成は一例に過ぎない。本実施の形態に係る動作を実行できるのであれば、機能区分及び機能部の名称はどのようなものでもよい。ただし、これまでに説明したユーザ装置ＵＥの処理の一部（一部のリソース選択順、一部の変形例のみ等）を実行可能としてもよい。
【００７４】
信号送信部１０１は、他のユーザ装置ＵＥ又は基地局ｅＮＢに送信すべきＤ２Ｄ信号から物理レイヤの各種信号を生成し、無線送信する機能を含む。また、信号送信部１０１は、Ｄ２Ｄ信号の送信機能とセルラ通信の送信機能を含む。また、信号送信部１０１は、選択部１０４で選択された１以上のリソースの候補の中から、Ｄ２Ｄ信号を送信するためのリソースを選択してＤ２Ｄ信号を送信する機能を含む。
【００７５】
信号受信部１０２は、他のユーザ装置ＵＥ又は基地局ｅＮＢから各種の信号を無線受信し、受信した物理レイヤの信号からより上位のレイヤの信号を取得する機能を含む。また、信号受信部１０２は、Ｄ２Ｄ信号の受信機能とセルラ通信の受信機能を含む。
【００７６】
センシング部１０３は、センシングウィンドウでセンシングを行うことで、将来のリソースの予約状況を把握する。
【００７７】
選択部１０４は、センシング部１０３で把握された将来のリソースの予約状況に基づき、Ｄ２Ｄ信号を送信可能なリソースの候補を選択する機能を含む。また、選択部１０４は、センシングの結果と当該ユーザ装置ＵＥが送信するＤ２Ｄ信号の送信間隔とに基づいて、センシングウィンドウより後の選択ウィンドウの中で信号を送信可能な１以上のリソースの候補を選択する機能を含む。
【００７８】
また、選択部１０４は、センシングの結果により選択ウィンドウの中で空きリソースを検出し、過去の時間方向において当該空きリソースよりも１送信間隔前のリソースの受信電力が所定の閾値以上である場合に、当該空きリソースを、Ｄ２Ｄ信号を送信可能な１以上のリソースの候補から除外することで、Ｄ２Ｄ信号を送信可能な１以上のリソースの候補を選択するようにしてもよい。
【００７９】
また、選択部１０４は、センシングの結果により選択ウィンドウの中で空きリソースを検出し、過去の時間方向において当該空きリソースを起点として送信間隔で繰り返される複数のリソースごとの受信電力が所定の条件を満たす場合に、当該空きリソースを、Ｄ２Ｄ信号を送信可能な１以上のリソースの候補から除外することで、Ｄ２Ｄ信号を送信可能な１以上のリソースの候補を選択するようにしてもよい。なお、当該所定の条件を満たす場合は、空きリソースを起点として送信間隔で繰り返される複数のリソースごとの受信電力の最大値、平均値又は最小値が所定の閾値以上である場合であってもよい。
【００８０】
また、選択部１０４は、センシングの結果により選択ウィンドウの中で空きリソースを検出し、未来の時間方向において当該空きリソースを起点として送信間隔で繰り返される複数のリソースが、当該センシング結果により予約されていると判断される場合に、当該空きリソースを、Ｄ２Ｄ信号を送信可能な１以上のリソースの候補から除外するようにしてもよい。
【００８１】
（基地局）
図１９は、実施の形態に係る基地局の機能構成の一例を示す図である。図１９に示すように、基地局ｅＮＢは、信号送信部２０１と、信号受信部２０２と、通知部２０３とを有する。なお、図１９は、基地局ｅＮＢにおいて本発明の実施の形態に特に関連する機能部のみを示すものであり、少なくともＬＴＥに準拠した動作を行うための図示しない機能も有するものである。また、図１９に示す機能構成は一例に過ぎない。本実施の形態に係る動作を実行できるのであれば、機能区分及び機能部の名称はどのようなものでもよい。
【００８２】
信号送信部２０１は、基地局ｅＮＢから送信されるべき上位のレイヤの信号から、物理レイヤの各種信号を生成し、無線送信する機能を含む。信号受信部２０２は、ユーザ装置ＵＥから各種の信号を無線受信し、受信した物理レイヤの信号からより上位のレイヤの信号を取得する機能を含む。
【００８３】
通知部２０３は、ユーザ装置ＵＥが本実施の形態に係る動作を行うために用いる各種情報を、報知情報（ＳＩＢ）又はＲＲＣシグナリングを用いてユーザ装置ＵＥに通知する。なお、当該各種情報は、例えば、Ｄ２Ｄリソースプールの設定を示す情報、ＳＣ期間の位置を示す情報、各種ウィンドウ（センシングウィンドウ、及び、選択ウィンドウ）の開始タイミング及び終了タイミングを示す情報、「Ｋ」の値などである。
【００８４】
＜ハードウェア構成＞
上記実施の形態の説明に用いたブロック図（図１８及び図１９）は、機能単位のブロックを示している。これらの機能ブロック（構成部）は、ハードウェア及び／又はソフトウェアの任意の組み合わせによって実現される。また、各機能ブロックの実現手段は特に限定されない。すなわち、各機能ブロックは、物理的及び／又は論理的に結合した１つの装置により実現されてもよいし、物理的及び／又は論理的に分離した２つ以上の装置を直接的及び／又は間接的に（例えば、有線及び／又は無線）で接続し、これら複数の装置により実現されてもよい。
【００８５】
例えば、本発明の一実施の形態における基地局ｅＮＢ、ユーザ装置ＵＥは、本発明の信号送信方法の処理を行うコンピュータとして機能してもよい。図２０は、実施の形態に係る基地局ｅＮＢ及びユーザ装置ＵＥのハードウェア構成の一例を示す図である。上述の基地局ｅＮＢ及びユーザ装置ＵＥは、物理的には、プロセッサ１００１、メモリ１００２、ストレージ１００３、通信装置１００４、入力装置１００５、出力装置１００６、バス１００７などを含むコンピュータ装置として構成されてもよい。
【００８６】
なお、以下の説明では、「装置」という文言は、回路、デバイス、ユニットなどに読み替えることができる。基地局ｅＮＢ及びユーザ装置ＵＥのハードウェア構成は、図に示した各装置を１つ又は複数含むように構成されてもよいし、一部の装置を含まずに構成されてもよい。
【００８７】
基地局ｅＮＢ及びユーザ装置ＵＥにおける各機能は、プロセッサ１００１、メモリ１００２などのハードウェア上に所定のソフトウェア（プログラム）を読み込ませることで、プロセッサ１００１が演算を行い、通信装置１００４による通信、メモリ１００２及びストレージ１００３におけるデータの読み出し及び／又は書き込みを制御することで実現される。
【００８８】
プロセッサ１００１は、例えば、オペレーティングシステムを動作させてコンピュータ全体を制御する。プロセッサ１００１は、周辺装置とのインターフェース、制御装置、演算装置、レジスタなどを含む中央処理装置（ＣＰＵ：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）などのハードウェアを含んで構成されてもよく、当該ハードウェアにより、各機能ブロックの一部又は全てが実現されてもよい。例えば、プロセッサ１００１は、これらのハードウェアの少なくとも１つで実装されてもよい。
【００９６】
＜まとめ＞
以上、実施の形態によれば、センシング用の時間ウィンドウで行われるセンシングの結果に基づいて、信号を送信するためのリソースを選択するユーザ装置であって、前記センシングの結果と当該ユーザ装置が送信する信号の送信間隔とに基づいて、前記センシング用の時間ウィンドウより後のリソース選択用の時間ウィンドウの中で信号を送信可能な１以上のリソースの候補を選択する選択部と、選択された１以上のリソースの候補の中から、信号を送信するためのリソースを選択して送信する送信部と、を有するユーザ装置が提供される。このユーザ装置ＵＥにより、センシング結果に基づいて信号を送信するためのリソースを選択する方式において、信号の衝突を抑制することが可能な技術が提供される。
【００９７】
また、前記選択部は、前記センシングの結果により前記リソース選択用の時間ウィンドウの中で空きリソースを検出し、過去の時間方向において前記空きリソースよりも１送信間隔前のリソースの受信電力が所定の閾値以上である場合に、前記空きリソースを、前記信号を送信可能な１以上のリソースの候補から除外することで、前記信号を送信可能な１以上のリソースの候補を選択するようにしてもよい。これにより、２回目以降のＤ２Ｄ信号の送信で衝突の発生が予測されるリソースは、最終的なリソース選択候補となるリソースから除外されるため、衝突の発生を抑制することが可能になる。
【００９８】
また、前記選択部は、前記センシングの結果により前記リソース選択用の時間ウィンドウの中で空きリソースを検出し、過去の時間方向において前記空きリソースを起点として送信間隔で繰り返される複数のリソースごとの受信電力が所定の条件を満たす場合に、前記空きリソースを、前記信号を送信可能な１以上のリソースの候補から除外することで、前記信号を送信可能な１以上のリソースの候補を選択するようにしてもよい。これにより、２回目以降のＤ２Ｄ信号送信で衝突の発生が予測されるリソースは、最終的なリソース選択候補となるリソースから除外されるため、衝突の発生を更に抑制することが可能になる。
【００９９】
また、前記所定の条件を満たす場合は、前記空きリソースを起点として送信間隔で繰り返される複数のリソースごとの受信電力の最大値、平均値又は最小値が所定の閾値以上である場合であるようにしてもよい。これにより、２回目以降のＤ２Ｄ信号送信で衝突の発生が予測されるリソースを、様々な方法で、最終的なリソース選択候補となるリソースから除外することができる。
【０１００】
また、前記選択部は、前記センシングの結果により前記リソース選択用の時間ウィンドウの中で空きリソースを検出し、未来の時間方向において前記空きリソースを起点として送信間隔で繰り返される複数のリソースが、前記センシングの結果により予約されていると判断される場合に、前記空きリソースを、前記信号を送信可能な１以上のリソースの候補から除外するようにしてもよい。これにより、ユーザ装置ＵＥが実際にデータ送信に用いる１つのリソースは、次の送信周期でもデータの送信が送信可能なリソースになるため、衝突の発生を抑制することが可能になる。
【０１０１】
また、実施の形態によれば、センシング用の時間ウィンドウで行われるセンシングの結果に基づいて、信号を送信するためのリソースを選択するユーザ装置が実行する信号送信方法であって、前記センシングの結果と当該ユーザ装置が送信する信号の送信間隔とに基づいて、前記センシング用の時間ウィンドウより後のリソース選択用の時間ウィンドウの中で信号を送信可能な１以上のリソースの候補を選択するステップと、選択された１以上のリソースの候補の中から、信号を送信するためのリソースを選択して送信するステップと、を有する信号送信方法が提供される。この信号送信方法によれば、センシング結果に基づいて信号を送信するためのリソースを選択する方式において、信号の衝突を抑制することが可能な技術が提供される。
【０１０２】
＜実施形態の補足＞
Ｄ２Ｄ制御信号は、ＳＡ（Scheduling Assignment）又はＳＣＩと呼ばれてもよい。ＰＳＣＣＨは、Ｄ２Ｄ通信に用いられる制御情報（ＳＣＩ等）を送信するための制御チャネルであればどのような制御チャネルをも含む。ＰＳＳＣＨは、Ｄ２ＤコミュニケーションのＤ２Ｄ通信に用いられるデータ（ＭＡＣ  ＰＤＵ等）を送信するためのデータチャネルであればどのようなデータチャネルをも含む。ＰＳＤＣＨは、Ｄ２ＤディスカバリのＤ２Ｄ通信に用いられるデータ（ディスカバリメッセージ等）を送信するためのデータチャネルであればどのようなデータチャネルをも含む。
【０１０３】
本明細書で説明した各態様／実施形態は、ＬＴＥ（Long  Term  Evolution）、ＬＴＥ−Ａ（LTE-Advanced）、ＳＵＰＥＲ  ３Ｇ、ＩＭＴ−Ａｄｖａｎｃｅｄ、４Ｇ、５Ｇ、ＦＲＡ（Future  Radio  Access）、Ｗ−ＣＤＭＡ（登録商標）、ＧＳＭ（登録商標）、ＣＤＭＡ２０００、ＵＭＢ（Ultra  Mobile  Broadband）、ＩＥＥＥ  ８０２．１１（Ｗｉ−Ｆｉ）、ＩＥＥＥ  ８０２．１６（ＷｉＭＡＸ）、ＩＥＥＥ  ８０２．２０、ＵＷＢ（Ultra-WideBand）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、その他の適切なシステムを利用するシステム及び／又はこれらに基づいて拡張された次世代システムに適用されてもよい。
【０１０４】
本明細書で説明した各態様／実施形態の処理手順、シーケンス、フローチャートなどは、矛盾の無い限り、順序を入れ替えてもよい。例えば、本明細書で説明した方法については、例示的な順序で様々なステップの要素を提示しており、提示した特定の順序に限定されない。
【０１０５】
本明細書で使用する「判断(determining)」、「決定(determining)」という用語は、多種多様な動作を包含する場合がある。「判断」、「決定」は、例えば、判定(judging)、計算(calculating)、算出(computing)、処理(processing)、導出(deriving)、調査(investigating)、探索(looking up)（例えば、テーブル、データベースまたは別のデータ構造での探索）、確認(ascertaining)した事を「判断」「決定」したとみなす事などを含み得る。また、「判断」、「決定」は、受信(receiving)（例えば、情報を受信すること）、送信(transmitting)(例えば、情報を送信すること)、入力(input)、出力(output)、アクセス(accessing)（例えば、メモリ中のデータにアクセスすること）した事を「判断」「決定」したとみなす事などを含み得る。また、「判断」、「決定」は、解決(resolving)、選択(selecting)、選定(choosing)、確立(establishing)、比較(comparing)などした事を「判断」「決定」したとみなす事を含み得る。つまり、「判断」「決定」は、何らかの動作を「判断」「決定」したとみなす事を含み得る。
【０１０６】
本明細書で使用する「に基づいて」という記載は、別段に明記されていない限り、「のみに基づいて」を意味しない。言い換えれば、「に基づいて」という記載は、「のみに基づいて」と「に少なくとも基づいて」の両方を意味する。
【０１０７】
「含む(ｉｎｃｌｕｄｅ)」、「含んでいる（ｉｎｃｌｕｄｉｎｇ）」、およびそれらの変形が、本明細書あるいは特許請求の範囲で使用されている限り、これら用語は、用語「備える（ｃｏｍｐｒｉｓｉｎｇ）」と同様に、包括的であることが意図される。さらに、本明細書あるいは特許請求の範囲において使用されている用語「または（or）」は、排他的論理和ではないことが意図される。
【０１０８】
本開示の全体において、例えば、英語でのa, an, 及びtheのように、翻訳により冠詞が追加された場合、これらの冠詞は、文脈から明らかにそうではないことが示されていなければ、複数のものを含むものとする。
【０１０９】
以上、本発明について詳細に説明したが、当業者にとっては、本発明が本明細書中に説明した実施形態に限定されるものではないということは明らかである。本発明は、特許請求の範囲の記載により定まる本発明の趣旨及び範囲を逸脱することなく修正及び変更態様として実施することができる。したがって、本明細書の記載は、例示説明を目的とするものであり、本発明に対して何ら制限的な意味を有するものではない。
【符号の説明】
【０１１０】
ＵＥ  ユーザ装置
ｅＮＢ  基地局
１０１  信号送信部
１０２  信号受信部
１０３  センシング部
１０４  選択部
２０１  信号送信部
２０２  信号受信部
２０３  通知部
１００１  プロセッサ
１００２  メモリ
１００３  ストレージ
１００４  通信装置
１００５  入力装置
１００６  出力装置
【図１】
2018026736.tif 000003
【図２】
2018026736.tif 000004
【図３】
2018026736.tif 000005
【図４】
2018026736.tif 000006
【図５】
2018026736.tif 000007
【図６】
2018026736.tif 000008
【図７】
2018026736.tif 000009
【図８】
2018026736.tif 000010
【図９】
2018026736.tif 000011
【図１０】
2018026736.tif 000012
【図１１】
2018026736.tif 000013
【図１２】
2018026736.tif 000014
【図１３】
2018026736.tif 000015
【図１４】
2018026736.tif 000016
【図１５】
2018026736.tif 000017
【図１６】
2018026736.tif 000018
【図１７】
2018026736.tif 000019
【図１８】
2018026736.tif 000020
【図１９】
2018026736.tif 000021
【図２０】
2018026736.tif 000022
【手続補正書】
【提出日】平成29年8月10日(2017.8.10)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
第１の時間ウィンドウで行われるセンシングの結果と信号の送信間隔とに基づいて、前記第１の時間ウィンドウより後の第２の時間ウィンドウの中で１以上のリソースの候補を選択する選択部と、
選択された１以上のリソースの候補の中から、信号を送信するためのリソースを選択して送信する送信部と、
を有するユーザ装置。
【請求項２】
前記選択部は、前記センシングの結果により前記第２の時間ウィンドウの中で空きリソースを検出し、過去の時間方向において前記空きリソースよりも１送信間隔前のリソースの受信電力が所定の閾値以上である場合に、前記空きリソースを、前記１以上のリソースの候補から除外することで、前記１以上のリソースの候補を選択する、
請求項１に記載のユーザ装置。
【請求項３】
前記選択部は、前記第２の時間ウィンドウの中で空きリソースを検出し、過去の時間方向において前記空きリソースを起点として送信間隔で繰り返される複数のリソースごとの受信電力に関する所定の条件に基づいて、前記空きリソースを、前記１以上のリソースの候補から除外する、
請求項１に記載のユーザ装置。
【請求項４】
前記所定の条件を満たすかどうかは、前記空きリソースを起点として送信間隔で繰り返される複数のリソースごとの受信電力の平均値により判断される、
請求項３に記載のユーザ装置。
【請求項５】
前記選択部は、前記第２の時間ウィンドウの中のあるリソースを起点として未来の時間方向において送信間隔で繰り返される複数のリソースが、前記センシングの結果により予約されていると判断される場合に、前記リソースを、前記１以上のリソースの候補から除外する、
請求項１に記載のユーザ装置。
【請求項６】
第１の時間ウィンドウで行われるセンシングの結果と信号の送信間隔とに基づいて、前記第１の時間ウィンドウより後の第２の時間ウィンドウの中で１以上のリソースの候補を選択するステップと、
選択された１以上のリソースの候補の中から、信号を送信するためのリソースを選択して送信するステップと、
を有する、ユーザ装置が実行する信号送信方法。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】０１０９
【補正方法】変更
【補正の内容】
【０１０９】
明細書には以下の事項が開示されている。
（第１項）
センシング用の時間ウィンドウで行われるセンシングの結果に基づいて、信号を送信するためのリソースを選択するユーザ装置であって、
前記センシングの結果と当該ユーザ装置が送信する信号の送信間隔とに基づいて、前記センシング用の時間ウィンドウより後のリソース選択用の時間ウィンドウの中で信号を送信可能な１以上のリソースの候補を選択する選択部と、
選択された１以上のリソースの候補の中から、信号を送信するためのリソースを選択して送信する送信部と、
を有するユーザ装置。
（第２項）
前記選択部は、前記センシングの結果により前記リソース選択用の時間ウィンドウの中で空きリソースを検出し、過去の時間方向において前記空きリソースよりも１送信間隔前のリソースの受信電力が所定の閾値以上である場合に、前記空きリソースを、前記信号を送信可能な１以上のリソースの候補から除外することで、前記信号を送信可能な１以上のリソースの候補を選択する、
請求項１に記載のユーザ装置。
（第３項）
前記選択部は、前記センシングの結果により前記リソース選択用の時間ウィンドウの中で空きリソースを検出し、過去の時間方向において前記空きリソースを起点として送信間隔で繰り返される複数のリソースごとの受信電力が所定の条件を満たす場合に、前記空きリソースを、前記信号を送信可能な１以上のリソースの候補から除外することで、前記信号を送信可能な１以上のリソースの候補を選択する、
請求項１に記載のユーザ装置。
（第４項）
前記所定の条件を満たす場合は、前記空きリソースを起点として送信間隔で繰り返される複数のリソースごとの受信電力の最大値、平均値又は最小値が所定の閾値以上である場合である、
請求項３に記載のユーザ装置。
（第５項）
前記選択部は、前記センシングの結果により前記リソース選択用の時間ウィンドウの中で空きリソースを検出し、未来の時間方向において前記空きリソースを起点として送信間隔で繰り返される複数のリソースが、前記センシングの結果により予約されていると判断される場合に、前記空きリソースを、前記信号を送信可能な１以上のリソースの候補から除外する、
請求項１に記載のユーザ装置。
（第６項）
センシング用の時間ウィンドウで行われるセンシングの結果に基づいて、信号を送信するためのリソースを選択するユーザ装置が実行する信号送信方法であって、
前記センシングの結果と当該ユーザ装置が送信する信号の送信間隔とに基づいて、前記センシング用の時間ウィンドウより後のリソース選択用の時間ウィンドウの中で信号を送信可能な１以上のリソースの候補を選択するステップと、
選択された１以上のリソースの候補の中から、信号を送信するためのリソースを選択して送信するステップと、
を有する信号送信方法。
以上、本発明について詳細に説明したが、当業者にとっては、本発明が本明細書中に説明した実施形態に限定されるものではないということは明らかである。本発明は、特許請求の範囲の記載により定まる本発明の趣旨及び範囲を逸脱することなく修正及び変更態様として実施することができる。したがって、本明細書の記載は、例示説明を目的とするものであり、本発明に対して何ら制限的な意味を有するものではない。
【手続補正書】
【提出日】平成29年12月25日(2017.12.25)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
第１の時間ウィンドウで行われるセンシングの結果と信号の送信間隔とに基づいて、前記第１の時間ウィンドウより後の第２の時間ウィンドウの中で、前記第２の時間ウィンドウよりも過去の時間方向において送信間隔で繰り返される複数のリソースごとの受信電力に基づいて、１以上のリソースの候補を選択する選択部と、
選択された１以上のリソースの候補の中から、信号を送信するためのリソースを選択して送信する送信部と、
を有するユーザ装置。
【請求項２】
第１の時間ウィンドウで行われるセンシングの結果と信号の送信間隔とに基づいて、前記第１の時間ウィンドウより後の第２の時間ウィンドウの中で１以上のリソースの候補を選択する選択部と、
選択された１以上のリソースの候補の中から、信号を送信するためのリソースを選択して送信する送信部と、を有するユーザ装置であって、
前記選択部は、前記センシングの結果により前記第２の時間ウィンドウの中で空きリソースを検出し、過去の時間方向において前記空きリソースよりも１送信間隔前のリソースの受信電力が所定の閾値以上である場合に、前記空きリソースを、前記１以上のリソースの候補から除外することで、前記１以上のリソースの候補を選択する、
ユーザ装置。
【請求項３】
第１の時間ウィンドウで行われるセンシングの結果と信号の送信間隔とに基づいて、前記第１の時間ウィンドウより後の第２の時間ウィンドウの中で１以上のリソースの候補を選択する選択部と、
選択された１以上のリソースの候補の中から、信号を送信するためのリソースを選択して送信する送信部と、を有するユーザ装置であって、
前記選択部は、前記第２の時間ウィンドウの中で空きリソースを検出し、過去の時間方向において前記空きリソースを起点として送信間隔で繰り返される複数のリソースごとの受信電力に関する所定の条件に基づいて、前記空きリソースを、前記１以上のリソースの候補から除外する、
ユーザ装置。
【請求項４】
前記所定の条件を満たすかどうかは、前記空きリソースを起点として送信間隔で繰り返される複数のリソースごとの受信電力の平均値により判断される、
請求項３に記載のユーザ装置。
【請求項５】
前記選択部は、前記第２の時間ウィンドウの中のあるリソースを起点として未来の時間方向において送信間隔で繰り返される複数のリソースが、前記センシングの結果により予約されていると判断される場合に、前記リソースを、前記１以上のリソースの候補から除外する、
請求項１に記載のユーザ装置。
【請求項６】
第１の時間ウィンドウで行われるセンシングの結果と信号の送信間隔とに基づいて、前記第１の時間ウィンドウより後の第２の時間ウィンドウの中で、前記第２の時間ウィンドウよりも過去の時間方向において送信間隔で繰り返される複数のリソースごとの受信電力に基づいて、１以上のリソースの候補を選択するステップと、
選択された１以上のリソースの候補の中から、信号を送信するためのリソースを選択して送信するステップと、
を有する、ユーザ装置が実行する信号送信方法。
【請求項７】
第１の時間ウィンドウで行われるセンシングの結果と信号の送信間隔とに基づいて、前記第１の時間ウィンドウより後の第２の時間ウィンドウの中で１以上のリソースの候補を選択する選択ステップと、
選択された１以上のリソースの候補の中から、信号を送信するためのリソースを選択して送信するステップと、
を有する、ユーザ装置が実行する信号送信方法であって、
前記選択ステップにおいて、前記ユーザ装置は、前記センシングの結果により前記第２の時間ウィンドウの中で空きリソースを検出し、過去の時間方向において前記空きリソースよりも１送信間隔前のリソースの受信電力が所定の閾値以上である場合に、前記空きリソースを、前記１以上のリソースの候補から除外することで、前記１以上のリソースの候補を選択する、
信号送信方法。
【請求項８】
第１の時間ウィンドウで行われるセンシングの結果と信号の送信間隔とに基づいて、前記第１の時間ウィンドウより後の第２の時間ウィンドウの中で１以上のリソースの候補を選択する選択ステップと、
選択された１以上のリソースの候補の中から、信号を送信するためのリソースを選択して送信するステップと、
を有する、ユーザ装置が実行する信号送信方法であって、
前記選択ステップにおいて、前記ユーザ装置は、前記第２の時間ウィンドウの中で空きリソースを検出し、過去の時間方向において前記空きリソースを起点として送信間隔で繰り返される複数のリソースごとの受信電力に関する所定の条件に基づいて、前記空きリソースを、前記１以上のリソースの候補から除外する、
信号送信方法。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】００１１
【補正方法】変更
【補正の内容】
【００１１】
開示の技術のユーザ装置は、第１の時間ウィンドウで行われるセンシングの結果と信号の送信間隔とに基づいて、前記第１の時間ウィンドウより後の第２の時間ウィンドウの中で、前記第２の時間ウィンドウよりも過去の時間方向において送信間隔で繰り返される複数のリソースごとの受信電力に基づいて、１以上のリソースの候補を選択する選択部と、
選択された１以上のリソースの候補の中から、信号を送信するためのリソースを選択して送信する送信部と、を有する。