(57)【要約】  Ｄ２Ｄ通信をサポートする無線通信システムにおけるユーザ装置であって、制御情報用のリソースプールから制御情報を繰り返し送信するための複数の制御情報用リソースを選択し、データ送信用のリソースプールからデータを繰り返し送信するための複数のデータ用リソースを選択する選択部と、前記複数のデータ用リソースを指定する情報を含む制御情報を前記複数の制御情報用リソースを用いて繰り返し送信し、前記複数のデータ用リソースを用いてデータを繰り返し送信する送信部と、を有し、前記選択部は、前記複数の制御情報用リソースのうち最初に制御情報を送信するための制御情報用リソースと、前記複数のデータ用リソースのうち最初にデータを送信するためのデータ用リソースとが同一のサブフレームになるように、前記複数の制御情報用リソースと前記複数のデータ用リソースとを選択する、ユーザ装置を提供する。
2017169835.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
【非特許文献２】３ＧＰＰ  ＴＳ３６．３００  Ｖ１３．２．０（２０１５−１２）
【非特許文献３】３ＧＰＰ  ＴＳ３６．２１３  Ｖ１２．８．０（２０１５−１２）
【発明の概要】
【発明が解決しようとする課題】
【０００７】
Ｄ２Ｄでは、データを送信するための無線リソースの範囲であるデータ用のリソースプールと、制御情報（ＳＣＩ：Sidelink Control Information）を送信するための無線リソースの範囲である制御情報用のリソースプールとが時間多重されて周期的に設定されている。当該周期は、ＰＳＣＣＨ期間（Physical Sildelink Control Channel Period）と呼ばれ、４０ｍｓ以上の周期であることが規定されている。【０００８】
また、送信側のユーザ装置は、制御情報用のリソースプールから選択された無線リソースで制御情報（ＳＣＩ）を送信し、データ用のリソースプールから選択された無線リソースでデータを送信する。制御情報には、データ用のリソースプールから選択された無線リソースの位置等を示す情報が含まれる。従って、送信側のユーザ装置がデータを送信可能なタイミングは、ＰＳＣＣＨ期間の長さ、及び制御情報用／データ用のリソースプール構成の影響を受けることになる。【０００９】
現在、３ＧＰＰでは、主にＶ２Ｖの通信において、制御情報及びデータを送信可能なタイミングを柔軟に制御可能にするため、様々なリソースプール構成が検討されている。一例として、図２に示すように、制御情報用のリソースプールと、データ用のリソースプールとを周波数多重させたリソースプール構成が検討されている。【００１０】
Ｒｅｌ−１２のＤ２Ｄでは、ＳＣＩは、予め規定されている周波数及び時間方向のリソース選択方法（ホッピングパターン）に従って、初回を含めて２回繰り返し送信されるように規定されており、受信側のユーザ装置は、２つのＳＣＩを合成受信することで、受信品質を高めることが可能である。同様に、データについても、Physical Uplink Shared Channel（ＰＵＳＣＨ）と同様のリソース選択方法（ホッピングパターン）に従って、初回を含めて４回繰り返し送信されるように規定されている。【００１１】
しかしながら、図２のように制御情報用のリソースプールと、データ用のリソースプールとを周波数多重させたリソースプール構成を採用する場合、従来のＲｅｌ−１２のＤ２Ｄで規定されているリソース選択方法（ホッピングパターン）では、適切なリソース選択が困難になる可能性がある。また、Ｖ２ＸはＤ２Ｄの一種であると考えると、上述の問題はＤ２Ｄ全般に発生し得る。【００１２】
開示の技術は上記に鑑みてなされたものであって、制御情報用のリソースプールと、データ用のリソースプールとを周波数多重させたリソースプール構成を採用する場合に、より適切なＤ２Ｄ通信を行うことが可能な技術を提供することを目的とする。
【課題を解決するための手段】
【００１３】
開示の技術のユーザ装置は、Ｄ２Ｄ通信をサポートする無線通信システムにおけるユーザ装置であって、制御情報用のリソースプールから制御情報を繰り返し送信するための複数の制御情報用リソースを選択し、データ送信用のリソースプールからデータを繰り返し送信するための複数のデータ用リソースを選択する選択部と、前記複数のデータ用リソースを指定する情報を含む制御情報を前記複数の制御情報用リソースを用いて繰り返し送信し、前記複数のデータ用リソースを用いてデータを繰り返し送信する送信部と、を有し、前記選択部は、前記複数の制御情報用リソースのうち最初に制御情報を送信するための制御情報用リソースと、前記複数のデータ用リソースのうち最初にデータを送信するためのデータ用リソースとが同一のサブフレームになるように、前記複数の制御情報用リソースと前記複数のデータ用リソースとを選択する。
【発明の効果】
【００１４】
開示の技術によれば、制御情報用のリソースプールと、データ用のリソースプールとを周波数多重させたリソースプール構成を採用する場合に、より適切なＤ２Ｄ通信を行うことが可能な技術が提供される。
【図面の簡単な説明】
【００１５】
【図１】Ｖ２Ｘを説明するための図である。
【図２】リソースプール構成を示す図である。
【図３Ａ】Ｄ２Ｄを説明するための図である。
【図３Ｂ】Ｄ２Ｄを説明するための図である。
【図４】Ｄ２Ｄ通信に用いられるＭＡＣ  ＰＤＵを説明するための図である。
【図５】ＳＬ−ＳＣＨ  ｓｕｂｈｅａｄｅｒのフォーマットを説明するための図である。
【図６】Ｄ２Ｄで使用されるチャネル構造の例を説明するための図である。
【図７Ａ】ＰＳＤＣＨの構造例を示す図である。
【図７Ｂ】ＰＳＤＣＨの構造例を示す図である。
【図８Ａ】ＰＳＣＣＨとＰＳＳＣＨの構造例を示す図である。
【図８Ｂ】ＰＳＣＣＨとＰＳＳＣＨの構造例を示す図である。
【図９Ａ】リソースプールコンフィギュレーションを示す図である。
【図９Ｂ】リソースプールコンフィギュレーションを示す図である。
【図１０】実施の形態に係る無線通信システムの構成例を示す図である。
【図１１】ＳＣＩ及びデータの繰り返し送信方法を説明するための図である。
【図１２】１回目にＳＣＩ及びデータを送信するリソース位置の選択方法（その１）を説明するための図である。
【図１３】１回目にＳＣＩ及びデータを送信するリソース位置の選択方法（その２）を説明するための図である。
【図１４】１回目にＳＣＩ及びデータを送信するリソース位置の選択方法（その３）を説明するための図である。
【図１５】２回目以降にデータを送信するリソース位置の選択方法（その１）を説明するための図である。
【図１６】２回目以降にデータを送信するリソース位置の選択方法（その２）を説明するための図である。
【図１７Ａ】ＳＣＩが繰り返し送信されるリソース位置の選択方法を説明するための図である。
【図１７Ｂ】ＳＣＩが繰り返し送信されるリソース位置の選択方法を説明するための図である。
【図１８】ＰＳＣＣＨ期間を跨いでデータが繰り返し送信される場合を示す図である。
【図１９】実施の形態に係るユーザ装置の機能構成の一例を示す図である。
【図２０】実施の形態に係る基地局の機能構成の一例を示す図である。
【図２１】実施の形態に係るユーザ装置のハードウェア構成の一例を示す図である。
【図２２】実施の形態に係る基地局のハードウェア構成の一例を示す図である。
【発明を実施するための形態】
【００１６】
以下、図面を参照して本発明の実施の形態を説明する。なお、以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。例えば、本実施の形態に係る無線通信システムはＬＴＥに準拠した方式のシステムを想定しているが、本発明はＬＴＥに限定されるわけではなく、他の方式にも適用可能である。なお、本明細書及び特許請求の範囲において、「ＬＴＥ」は、３ＧＰＰのリリース８、又は９に対応する通信方式のみならず、３ＧＰＰのリリース１０、１１、１２、１３、又はリリース１４以降に対応する第５世代の通信方式も含む広い意味で使用する。
【００１７】
また、本実施の形態は、主にＶ２Ｘを対象としているが、本実施の形態に係る技術は、Ｖ２Ｘに限らず、広くＤ２Ｄ全般に適用可能である。また、「Ｄ２Ｄ」はその意味としてＶ２Ｘを含むものである。
【００１８】
また、「Ｄ２Ｄ」は、ユーザ装置ＵＥ間でＤ２Ｄ信号を送受信する処理手順のみならず、Ｄ２Ｄ信号を基地局が受信（モニタ）する処理手順、及び、ＲＲＣ  ｉｄｌｅの場合若しくは基地局ｅＮＢとコネクションを確立していない場合に、ユーザ装置ＵＥが基地局ｅＮＢに上り信号を送信する処理手順を含む広い意味で使用する。
【００１９】
＜Ｄ２Ｄの概要＞
ＬＴＥで規定されているＤ２Ｄの概要について説明する。なお、Ｖ２Ｘにおいても、ここで説明するＤ２Ｄの技術を使用することは可能であり、本発明の実施の形態におけるＵＥは、当該技術によるＤ２Ｄ信号の送受信を行うことができる。
【００２０】
既に説明したように、Ｄ２Ｄには、大きく分けて「Ｄ２Ｄディスカバリ」と「Ｄ２Ｄコミュニケーション」がある。「Ｄ２Ｄディスカバリ」については、図３Ａに示すように、Ｄｉｓｃｏｖｅｒｙ  ｐｅｒｉｏｄ毎に、Ｄｉｓｃｏｖｅｒｙメッセージ用のリソースプールが確保され、ＵＥはそのリソースプール内でＤｉｓｃｏｖｅｒｙメッセージを送信する。より詳細にはＴｙｐｅ１、Ｔｙｐｅ２ｂがある。Ｔｙｐｅ１では、ＵＥが自律的にリソースプールから送信リソースを選択する。Ｔｙｐｅ２ｂでは、上位レイヤシグナリング（例えばＲＲＣ信号）により準静的なリソースが割り当てられる。
【００２１】
「Ｄ２Ｄコミュニケーション」についても、図３Ｂに示すように、ＳＣＩ／データ送信用のリソースプールが周期的に確保される。送信側のＵＥはＣｏｎｔｒｏｌリソースプール（ＰＳＣＣＨリソースプール）から選択されたリソースでＳＣＩによりデータ送信用リソース（ＰＳＳＣＨリソースプール）等を受信側に通知し、当該データ送信用リソースでデータを送信する。「Ｄ２Ｄコミュニケーション」について、より詳細には、Ｍｏｄｅ１とＭｏｄｅ２がある。Ｍｏｄｅ１では、ｅＮＢからＵＥに送られる（Ｅ）ＰＤＣＣＨによりダイナミックにリソースが割り当てられる。Ｍｏｄｅ２では、ＵＥはリソースプールから自律的に送信リソースを選択する。リソースプールについては、ＳＩＢで通知されたり、予め定義されたものが使用される。
【００２２】
ＬＴＥにおいて、「Ｄ２Ｄディスカバリ」に用いられるチャネルはPhysical Sidelink Discovery Channel（ＰＳＤＣＨ）と称され、「Ｄ２Ｄコミュニケーション」におけるＳＣＩ等の制御情報を送信するチャネルはPhysical Sidelink Control Channel（ＰＳＣＣＨ）と称され、データを送信するチャネルは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（ＤＭ−ＲＳ）が挿入される構造になっている。
【００２８】
図８Ａに、「Ｄ２Ｄコミュニケーション」に使用されるＰＳＣＣＨとＰＳＳＣＨのリソースプールの例を示す。図８Ａに示すとおり、ＰＳＣＣＨは、周波数ホッピングしながら、初回を含めて２回繰り返し送信（ｒｅｐｅｔｉｔｉｏｎ）がなされる。ＰＳＳＣＨは、周波数ホッピングしながら、初回を含めて４回繰り返し送信（ｒｅｐｅｔｉｔｉｏｎ）がなされる。また、図８Ｂに示すように、ＰＳＣＣＨとＰＳＳＣＨはＰＵＳＣＨベースの構造を有し、ＤＭＲＳが挿入される構造になっている。
【００２９】
図９に、ＰＳＣＣＨ、ＰＳＤＣＨ、ＰＳＳＣＨ（Ｍｏｄｅ２）におけるリソースプールコンフィギュレーションの例を示す。図９Ａに示すように、時間方向では、リソースプールはサブフレームビットマップとして表される。また、ビットマップは、ｎｕｍ．ｒｅｐｒｔｉｔｉｏｎの回数だけ繰り返される。また、各周期における開始位置を示すｏｆｆｓｅｔが指定される。
【００３０】
周波数方向では、連続割り当て（ｃｏｎｔｉｇｕｏｕｓ）と不連続割り当て（ｎｏｎ−ｃｏｎｔｉｇｕｏｕｓ）が可能である。図９Ｂは、不連続割り当ての例を示しており、図示のとおり、開始ＰＲＢ、終了ＰＲＢ、ＰＲＢ数（ｎｕｍＰＲＢ）が指定される。
【００３１】
＜システム構成＞
図１０は、実施の形態に係る無線通信システムの構成例を示す図である。図１０に示すように、本実施の形態に係る無線通信システムは、基地局ｅＮＢ、ユーザ装置ＵＥ１、ユーザ装置ＵＥ２を有する。図１０において、ユーザ装置ＵＥ１は送信側、ユーザ装置ＵＥ２は受信側を意図しているが、ユーザ装置ＵＥ１とユーザ装置ＵＥ２はいずれも送信機能と受信機能の両方を備える。以下、ユーザ装置ＵＥ１とユーザ装置ＵＥ２を特に区別しない場合、単に「ユーザ装置ＵＥ」と記述する。
【００３２】
図１０に示すユーザ装置ＵＥ１、ユーザ装置ＵＥ２は、それぞれ、ＬＴＥにおけるユーザ装置ＵＥとしてのセルラ通信の機能、及び、上述したチャネルでの信号送受信を含むＤ２Ｄ機能を有している。また、ユーザ装置ＵＥ１、ユーザ装置ＵＥ２は、本実施の形態で説明する動作を実行する機能を有している。なお、セルラ通信の機能及び既存のＤ２Ｄの機能については、一部の機能（本実施の形態で説明する動作を実行できる範囲）のみを有していてもよいし、全ての機能を有していてもよい。
【００３３】
また、各ユーザ装置ＵＥは、Ｄ２Ｄの機能を有するいかなる装置であってもよいが、例えば、各ユーザ装置ＵＥは、車両、歩行者が保持する端末、ＲＳＵ（ＵＥの機能を有するＵＥタイプＲＳＵ）等である。
【００３４】
また、基地局ｅＮＢについては、ＬＴＥにおける基地局ｅＮＢとしてのセルラ通信の機能、及び、本実施の形態におけるユーザ装置ＵＥの通信を可能ならしめるための機能（リソース割当ての機能、設定情報通知機能等）を有している。また、基地局ｅＮＢはＲＳＵ（ｅＮＢの機能を有するｅＮＢタイプＲＳＵ）を含む。
【００３５】
＜処理手順＞
以下、実施の形態に係るユーザ装置ＵＥが行う具体的な処理手順について説明する。なお、以下の説明において、制御情報を送信するためのリソースプールを、便宜上「ＳＣＩリソースプール」と記載するが、これに限られることを意図しているのではない。本実施の形態には、従来のＤ２Ｄで用いられている「ＰＳＣＣＨリソースプール」及び「Scheduling Assignment（ＳＡ）リソースプール」の名称で呼ばれるリソースプール、及び５Ｇ等で新たに規定される可能性のある名称で呼ばれるリソースプールも含む。また、データを送信するためのリソースプールを、便宜上「データリソースプール」と記載するが、これに限られることを意図しているのではない。本実施の形態には、従来のＤ２Ｄで用いられている「ＰＳＳＣＨリソースプール」及び５Ｇ等で新たに規定される可能性のある名称で呼ばれるリソースプールも含む。
【００３６】
また、以下の説明では、Ｄ２Ｄ通信に用いられる制御情報を「ＳＣＩ」と記載するが、制御情報がこれに限定されることを意図しているのではない。本実施の形態には、従来のＤ２Ｄで用いられている「ＳＡ」の名称で呼ばれる制御情報及び５Ｇ等で新たに規定される可能性のある名称で呼ばれる制御情報も含む。
【００３７】
本実施の形態では、ＳＣＩリソースプールとデータリソースプールとが周波数多重されていることを前提とする。また、データリソースプールが設定される帯域の上下の帯域にＳＣＩリソースプールが設定されていることを前提として説明するが、これに限られず、ＳＣＩリソースプールは、必ずしもデータリソースプールが設定される帯域の上下の帯域に設定されていなくてもよい。例えば、帯域の上側（又は下側）にＳＣＩリソースプールが設定され、帯域の下側（又は上側）にデータリソースプールが設定されていてもよい。
【００３８】
また、本実施の形態では、受信側のユーザ装置ＵＥにおいて、受信した複数のＳＣＩの合成を可能にするため、送信側のユーザ装置ＵＥが２回目以降にＳＣＩを送信するために選択するリソースの位置は、１回目のＳＣＩが送信されるリソース位置から、所定のリソース選択方法（ホッピングパターン）に従って一意に決定される前提とする。つまり、送信側のユーザ装置ＵＥ及び受信側のユーザ装置ＵＥは、当該所定のリソース選択方法を予め把握していることを前提とする。また、データが複数回繰り返し送信されるリソースの位置を示す情報は、ＳＣＩに含まれていることを前提とする。つまり、受信側のユーザ装置ＵＥは、受信したＳＣＩに含まれている当該情報に基づいて、データが複数回繰り返し送信されるリソース位置を認識する。
【００３９】
（ＳＣＩ及びデータの繰り返し送信方法について）
本実施の形態に係るユーザ装置ＵＥは、受信側のユーザ装置ＵＥに向けてデータを送信する際、ＳＣＩを繰り返し送信するための複数のＳＣＩ送信用のリソースをＳＣＩリソースプールから選択すると共に、データを繰り返し送信するための複数のデータ送信用のリソースをデータリソースプールから選択し、選択した複数のＳＣＩ送信用のリソースと複数のデータ送信用のリソースとを用いて、同一の内容のＳＣＩ及び同一の内容のデータを繰り返し送信する。
【００４０】
ここで、ユーザ装置ＵＥは、最初に（１回目に）ＳＣＩを送信するためのＳＣＩ用のリソースと、最初に（１回目）にデータを送信するためのデータ送信用のリソースとが同一のサブフレームになるように、複数のＳＣＩ送信用のリソースと複数のデータ送信用のリソースとを選択する。
【００４１】
なお、所定のリソース選択方法により規定される複数のＳＣＩ送信用のリソースは、周波数方向に上側のＳＣＩリソースプールと下側のＳＣＩリソースプールとの間で周波数ホッピングされるように規定されていてもよい。また、ユーザ装置ＵＥは、複数のデータ送信用のリソースを、データリソースプールのうち周波数方向に上半分のリソースプールと、下半分のリソースプールとの間で、周波数ホッピングされるように選択するようにしてもよい。これにより、受信側のユーザ装置ＵＥにおいて周波数ダイバーシチ効果を得ることが可能になる。
【００４２】
図１１は、ＳＣＩ及びデータの繰り返し送信方法を説明するための図である。図１１に示すように、本実施の形態に係るユーザ装置ＵＥは、１回目に送信されるＳＣＩのリソースと１回目に送信されるデータのリソースとが、同一のサブフレームになるようにリソースを選択する。また、ユーザ装置ＵＥは、２回目以降にデータを繰り返し送信するために用いるリソースを、１回目にＳＣＩが送信されるサブフレーム（ＳＣＩとデータとが同時に送信されるサブフレーム）より後のサブフレームである任意のリソースから選択するようにする。図１１の例では、ＳＣＩが２回繰り返し送信され、データが３回繰り返し送信される場合の例を示している。しかしながら、本実施の形態は、これに限られず、ＳＣＩは３回以上繰り返し送信されてもよいし、データは２回又は４回以上繰り返し送信されてもよい。
【００４３】
以上説明した方法でＳＣＩ及びデータを繰り返し送信することで、受信側のユーザ装置ＵＥは、ＳＣＩ及びデータの合成受信を行うことが可能になる。また、ＳＣＩ及びデータが繰り返し送信されることで、複数のユーザ装置ＵＥが同一のサブフレームでＤ２Ｄ信号を送信してしまい、他方のユーザ装置ＵＥが送信するＤ２Ｄ信号をもう一方のユーザ装置ＵＥが受信できなくなるという問題（ハーフデュプレックス問題）が極力発生しないように制御することが可能になる。また、送信側のユーザ装置ＵＥは、１回目に送信するＳＣＩと１回目に送信するデータとを同一のサブフレームで送信するため、従来のＤ２Ｄ通信と比較して伝送遅延を短縮することが可能になる。また、送信側のユーザ装置ＵＥは、データを送信するリソースを、任意のリソースから選択することができるため、より柔軟なＤ２Ｄ通信が可能になる。
【００４４】
（１回目にＳＣＩ及びデータを送信するリソース位置の選択方法について）
送信側のユーザ装置ＵＥは、１回目にＳＣＩ及びデータを送信するリソースを選択する際、他のユーザ装置ＵＥとの間で同一のリソースを選択してしまうことを抑止するため、以下に示す選択方法を用いてリソースの選択を行うようにしてもよい。
【００４５】
［選択方法（その１）］
選択方法（その１）では、ユーザ装置ＵＥは、ＳＣＩにリソース予約情報を含めることで、所定の時間後（所定のサブフレーム後）に新たなＳＣＩ（又は新たなＳＣＩ及びデータ）を送信するためのリソースを予約することが可能であることを前提とする。また、リソース予約ウインドウとは、リソース予約情報を含むＳＣＩを送信すべき期間を意図しており、リソース選択ウインドウとは、リソース予約情報によりリソースを予約可能な期間を意図している。つまり、ユーザ装置ＵＥは、リソース予約ウインドウをモニタすることで、リソース選択ウインドウにおけるリソースの予約状況を把握することができ、リソース選択ウインドウ内のリソースのうち予約されていないリソースを用いてＳＣＩ／データを送信することが可能である。
【００４６】
図１２に示すように、ユーザ装置ＵＥは、リソース予約ウインドウの期間において、１回目のＳＣＩ送信が行われるＳＣＩリソースプール内の各リソースをモニタすることで、他のユーザ装置ＵＥから送信されるＳＣＩを受信し、受信したＳＣＩに含まれるリソース予約情報を取得する。続いて、ユーザ装置ＵＥは、取得したリソース予約情報に基づいてリソースの予約状況を判定し、リソース選択ウインドウ内のリソースのうち、ＳＣＩ及びデータを同一サブフレームで送信可能なリソースが空いている（リソースが予約されていない）と判定した場合に、当該リソースを１回目にＳＣＩ及びデータを送信するリソースとして選択する。
【００４７】
なお、リソース選択ウインドウ内のリソースのうち、ＳＣＩを送信可能なリソースしか空いていないと判定した場合（つまり、データを送信可能なリソースが空いていないと判定した場合）、当該空いているリソースをＳＣＩを送信するリソースとして選択すると共に、選択したリソースと同一サブフレームにおけるデータリソースプールの中から、任意のリソースをデータを送信するリソースとして選択するようにしてもよい。本実施の形態ではＳＣＩ及びデータは繰り返し送信されることが前提とされ、かつ予約されているリソースで必ずしも他のユーザ装置ＵＥからデータが送信されるとは限られないため、多少の干渉の発生は許容されるためである。
【００４８】
同様に、リソース選択ウインドウ内のリソースのうち、データを送信可能なリソースしか空いていないと判定した場合（つまり、ＳＣＩを送信可能なリソースが空いていないと判定した場合）、当該空いているリソースをデータを送信するリソースとして選択する共に、選択したリソースと同一サブフレームにおけるＳＣＩリソースプールの中から、任意のリソースをＳＣＩを送信するリソースとして選択するようにしてもよい。本実施の形態ではＳＣＩ及びデータは繰り返し送信されることが前提とされており、かつ予約されているリソースで必ずしも他のユーザ装置ＵＥからＳＣＩが送信されるとは限られないため、多少の干渉の発生は許容されるためである。
【００４９】
［選択方法（その２）］
選択方法（その２）では、ユーザ装置ＵＥは、ＳＣＩを送信してから所定の時間後（所定のサブフレーム後）に新たなＳＣＩ（又は新たなＳＣＩ及びデータ）を送信するためのリソースを予約することが可能であることを前提とする。また、リソース予約ウインドウ内でＳＣＩ及びデータを送信する際のリソースと、所定の時間後にＳＣＩ及びデータを送信するために予約可能なリソース（リソース選択ウインドウ内のリソース）は、それぞれ予め対応づけられており、ユーザ装置ＵＥは、当該対応づけを示す情報を予め保持していることを前提とする。
【００５０】
図１３に示すように、ユーザ装置ＵＥは、リソース予約ウインドウの期間において、１回目のＳＣＩ送信が行われるＳＣＩリソースプール内の各リソースの受信電力を測定すると共に、データ送信が行われるデータリソースプール内の各リソースの受信電力を測定する。続いて、ユーザ装置ＵＥは、測定した受信電力に基づいてリソースの予約状況を判定する。より具体的には、ユーザ装置ＵＥは、受信電力が所定の閾値以上であるＳＣＩ／データのリソース位置に対応づけられているリソース選択ウインドウ内のＳＣＩ／データ送信用のリソースについては、リソースが予約されていると判定し、受信電力が所定の閾値未満であるＳＣＩ／データのリソース位置に対応づけられているリソース選択ウインドウ内のＳＣＩ／データ送信用のリソースについては、リソースが予約されていないと判定する。
【００５１】
続いて、ユーザ装置ＵＥは、リソース選択ウインドウ内のリソースのうち、ＳＣＩ及びデータを同一サブフレームで送信可能なリソースが空いている（リソースが予約されていない）と判定した場合に、当該リソースを１回目にＳＣＩ及びデータを送信するリソースとして選択する。
【００５２】
なお、選択方法（その１）と同様、リソース選択ウインドウ内のリソースのうち、ＳＣＩを送信可能なリソースしか空いていないと判定した場合（つまり、データを送信可能なリソースが空いていないと判定した場合）、当該空いているリソースをＳＣＩを送信するリソースとして選択する共に、選択したリソースと同一サブフレームにおけるデータリソースプールの中から、任意のリソースをデータを送信するリソースとして選択するようにしてもよい。同様に、リソース選択ウインドウ内のリソースのうち、データを送信可能なリソースしか空いていないと判定した場合（つまり、ＳＣＩを送信可能なリソースが空いていないと判定した場合）、当該空いているリソースをデータを送信するリソースとして選択する共に、選択したリソースと同一サブフレームにおけるＳＣＩリソースプールの中から、任意のリソースをＳＣＩを送信するリソースとして選択するようにしてもよい。
【００５３】
なお、選択方法（その２）と選択方法（その１）とを組み合わせるようにしてもよい。例えば、リソース選択ウインドウでＳＣＩを送信する際のリソースについては、選択方法（その１）に従って選択し、リソース選択ウインドウでデータを送信する際のリソースについては、選択方法（その２）に従って選択するようにしてもよい。
【００５４】
［選択方法（その３）］
選択方法（その３）では、ユーザ装置ＵＥは、ＳＣＩを送信してから所定の時間後（所定のサブフレーム後）に新たなＳＣＩ（又は新たなＳＣＩ及びデータ）を送信するためのリソースを予約することが可能であることを前提とする。また、リソース予約ウインドウ内でＳＣＩ及びデータを送信する際のリソースと、所定の時間後にＳＣＩ及びデータを送信するために予約可能なリソース（リソース選択ウインドウ内のリソース）は、それぞれサブフレーム単位で予め対応づけられており、ユーザ装置ＵＥは、当該対応づけを示す情報を予め保持していることを前提とする。
【００５５】
図１４に示すように、ユーザ装置ＵＥは、リソース予約ウインドウの期間に含まれる各サブフレームにおいて、１回目のＳＣＩ送信が行われるＳＣＩリソースプール内の各リソースの受信電力と、データ送信が行われるデータリソースプール内の各リソースの受信電力とを、サブフレームごとに測定する。
【００５６】
続いて、ユーザ装置ＵＥは、測定されたＳＣＩリソースプール内の各リソースの受信電力におけるサブフレームごとの統計値（最大値、平均値又は最小値）、及び、測定されたデータリソースプール内の各リソースの受信電力におけるサブフレームごとの統計値（最大値、平均値又は最小値）を用いて、いずれか１つのサブフレームを選択する。
【００５７】
いずれか１つのサブフレームを選択する方法についてはどのような方法であってもよいが、例えば、ユーザ装置ＵＥは、ＳＣＩリソースプールにおける受信電力の統計値及びデータリソースプールにおける受信電力の統計値のうち大きい値が最も小さいサブフレームを選択するようにしてもよい。図１４を用いて具体的に説明すると、ユーザ装置ＵＥは、「１」の範囲のリソースの受信電力の統計値及び「５」の範囲のリソースの受信電力の統計値のうち"大きい方の値"と、「２」の範囲のリソースの受信電力の統計値及び「６」の範囲のリソースの受信電力の統計値のうち"大きい方の値"と、「３」の範囲のリソースの受信電力の統計値及び「７」の範囲のリソースの受信電力の統計値のうち"大きい方の値"と、「４」の範囲のリソースの受信電力の統計値及び「８」の範囲のリソースの受信電力の統計値のうち"大きい方の値"とを比較し、これらの"大きい方の値"のうち最も小さい値のサブフレームを選択するようにしてもよい。
【００５８】
また、他の方法として、例えば、ユーザ装置ＵＥは、ＳＣＩリソースプールにおける受信電力の統計値及びデータリソースプールにおける受信電力の統計値を所定の比率で合計した値が最も小さいサブフレームを選択するようにしてもよい。図１４を用いて具体的に説明すると、ユーザ装置ＵＥは、「１」の範囲のリソースの受信電力の統計値及び「５」の範囲のリソースの受信電力の統計値を所定の比率で合計した値と、「２」の範囲のリソースの受信電力の統計値及び「６」の範囲のリソースの受信電力の統計値を所定の比率で合計した値と、「３」の範囲のリソースの受信電力の統計値及び「７」の範囲のリソースの受信電力の統計値を所定の比率で合計した値と、「４」の範囲のリソースの受信電力の統計値及び「８」の範囲のリソースの受信電力の統計値を所定の比率で合計した値とを比較し、これらの"合計した値"のうち最も小さい値のサブフレームを選択するようにしてもよい。
【００５９】
続いて、ユーザ装置ＵＥは、選択したサブフレームに対応づけられているリソース選択ウインドウ内のサブフレームを、リソースが予約されていないサブフレームであると認識し、当該サブフレームのリソースを１回目にＳＣＩ及びデータを送信するリソースとして選択する。
【００６０】
（２回目以降にデータを送信するリソース位置の選択方法について）
前述の通り、本実施の形態に係るユーザ装置ＵＥは、２回目以降にデータを繰り返し送信するために用いるリソースを、１回目のＳＣＩが送信されるサブフレーム（ＳＣＩとデータとが同時に送信されるサブフレーム）より後のサブフレームである任意のリソースから選択するようにする。より具体的には、ユーザ装置ＵＥは、以下に示す選択方法に従って２回目以降にデータを送信するリソース位置を選択するようにしてもよい。
【００６１】
［選択方法（その１）］
選択方法（その１）では、ユーザ装置ＵＥは、図１５に示すように、複数のデータ送信用リソースのうち２回目にデータを繰り返し送信するためのリソースを、１回目にＳＣＩを送信するサブフレームより後のサブフレームと、２回目にＳＣＩを送信するサブフレームより前のサブフレームとの間のいずれかのサブフレームの中から選択するようにしてもよい。なお、ユーザ装置ＵＥは、３回以上データを繰り返し送信する場合、３回目以降にデータを繰り返し送信するためのリソースについては、２回目のデータ送信を行うサブフレームより後のサブフレーム（２回目にＳＣＩを送信するサブフレームより後のサブフレームを含む）である任意のリソースから選択するようにしてもよい。
【００６２】
なお、図１５の例の場合、受信側のユーザ装置ＵＥは、１回目のＳＣＩの受信に失敗した場合（例えば、復号に失敗した場合）、１回目のＳＣＩを受信したサブフレームと、２回目にＳＣＩが送信されるサブフレームより１つ前のサブフレームまでの全てのサブフレームの信号をメモリ等にバッファしておき、２回目のＳＣＩの復号に成功した場合（又は、１回目と２回目のＳＣＩを合成受信することで復号に成功した場合）に、ＳＣＩに含まれているデータのリソース位置を示す情報に基づいて、バッファ内のサブフレームの信号からデータを復号するようにしてもよい。バッファ内には、少なくとも２回分のデータの信号が含まれていることから、受信側のユーザ装置ＵＥは、必要に応じて２回分のデータの信号を合成して復号することが可能になる。
【００６３】
［選択方法（その２）］
選択方法（その２）では、ユーザ装置ＵＥは、図１６に示すように、複数のデータ送信用リソースのうち２回目にデータを繰り返し送信するためのリソースを、２回目にＳＣＩを送信するサブフレーム以後のサブフレームから選択するようにしてもよい。なお、ユーザ装置ＵＥは、３回以上データを繰り返し送信する場合、３回目以降にデータを繰り返し送信するためのリソースについては、２回目のデータ送信を行うサブフレームより後のサブフレームである任意のリソースから選択するようにしてもよい。
【００６４】
なお、図１６の例の場合、受信側のユーザ装置ＵＥは、１回目のＳＣＩの受信に失敗した場合（例えば、復号に失敗した場合）、１回目のＳＣＩを受信したサブフレームの信号と、２回目にＳＣＩが送信されるサブフレームの信号とをメモリ等にバッファしておき、２回目のＳＣＩの復号に成功した場合（又は、１回目と２回目のＳＣＩを合成受信することで復号に成功した場合）に、ＳＣＩに含まれているデータのリソース位置を示す情報に基づいて、バッファ内のサブフレームの信号からデータを復号するようにしてもよい。バッファ内には、少なくとも1回分のデータの信号が含まれおり、受信側のユーザ装置ＵＥは、必要に応じて後続のデータの信号も含め合成して復号することが可能になる。
【００６５】
（ＳＣＩを送信するリソースの選択方法について）
本実施の形態では、受信側のユーザ装置ＵＥにおいて、受信した複数のＳＣＩの合成を可能にするため、送信側のユーザ装置ＵＥが２回目以降にＳＣＩを送信するために選択するリソースの位置は、１回目のＳＣＩを送信するためのリソース位置から所定のリソース選択方法（ホッピングパターン）に従って一意に決定される前提としている。ここで、本実施の形態では、当該所定のリソース選択方法として、３ＧＰＰのＲｅｌ−１２で規定されているリソース選択方法（ホッピングパターン）を拡張したリソース選択方法を用いるようにしてもよい。なお、本実施の形態ではＳＣＩを１サブフレームあたり連続する周波数リソース１つを用いて送信する例を記載しているがそれに限らず、不連続周波数リソースを用いたＳＣＩ送信であってもよい。例えば、ユーザ装置ＵＥは、上位レイヤシグナリング（例えば報知情報又はＲＲＣシグナリングなど）又は事前設定に基づき不連続周波数リソース送信のＯＮ／ＯＦＦを切り替えるようにしてもよい。不連続周波数リソース送信を行う場合、ユーザ装置ＵＥは、１つの連続周波数リソース（例えば１ＰＲＢのリソース）と、システム帯域幅若しくはＳＣＩリソースプールの中で鏡像関係にあるもう１つの連続周波数リソース又は一定周波数リソースのオフセット関係にあるもう１つの連続周波数リソースを用いることで、２つの不連続周波数リソースでＳＣＩを送信するようにしてもよい。ここで、ユーザ装置ＵＥは、連続周波数リソース間に渡る符号化を行なってもよいし、一定の周波数リソースサイズ（連続周波数リソースごと等）ごとに符号化を行ってＳＣＩの送信を行い、受信側のユーザ装置ＵＥで合成受信を行なってもよい。このとき、ユーザ装置ＵＥは、一定のルールに基づいて決定される異なるＲｅｄｕｎｄａｎｃｙ  Ｖｅｒｓｉｏｎ（ＲＶ）で各連続周波数リソースの信号を送信してもよい。
【００６６】
図１７は、ＳＣＩが繰り返し送信されるリソース位置の選択方法を説明するための図である。図１７の「Ｎｆ」は、ＳＣＩリソースプールの周波数方向のリソース数（例えば、周波数方向のＲＢ（Resource Block）数）を意味している。
【００６７】
図１７Ａに、Ｒｅｌ−１２で規定されているリソース選択方法のイメージを示す。図１７Ａにおいて、同一番号が付されている２つのリソースは、同一のＳＣＩが繰り返し送信されるリソース位置を示している。Ｒｅｌ−１２で規定されているリソース選択方法では、ＰＳＣＣＨ期間内で１回目に送信されるＳＣＩと、２回目に送信されるＳＣＩとが、周波数方向に上側（又は下側）のＳＣＩリソースプールと下側（又は上側）のＳＣＩリソースプールとの間で周波数ホッピングされて送信されるように規定されている。また、同一のサブフレームかつ異なる周波数のリソースで送信される２つのＳＣＩは、１回目の送信時と２回目の送信時とでは異なるサブフレームで送信されるように規定されている。より具体的なリソース選択方法は、３ＧＰＰ  ＴＳ３６．２１３の１４．２．１．１章及び１４．２．１．２章に規定されている。
【００６８】
ここで、Ｒｅｌ−１２のリソース選択方法では、１回目のＳＣＩと２回目のＳＣＩが同一ＰＳＣＣＨ期間内に送信される前提である。従って、１回目のＳＣＩのリソース位置によっては、１回目に送信されるＳＣＩと２回目に送信されるＳＣＩとの間のサブフレーム間隔が空いてしまう場合がある。例えば、図１７Ａの例において、「１」に示すリソースのＳＣＩは、１回目に送信されるＳＣＩと２回目に送信されるＳＣＩとの間のサブフレーム間隔は１サブフレームであるが、「３」に示すリソースのＳＣＩは、１回目に送信されるＳＣＩと２回目に送信されるＳＣＩとの間のサブフレーム間隔は７サブフレームである。
【００６９】
そこで、本実施の形態では、ＳＣＩリソースプールを、複数の連続したＰＳＣＣＨ期間に分割すると共に、ユーザ装置ＵＥは、Ｒｅｌ−１２のリソース選択方法に従って規定される１回目のＳＣＩと２回目のＳＣＩとの間のサブフレーム間隔が、ＰＳＣＣＨ期間の半分の期間におけるサブフレーム数より長い場合（図１７Ａでは４サブフレーム）、Ｒｅｌ−１２のリソース選択方法に従って規定される２回目のＳＣＩのリソース位置を１回目のＳＣＩのリソース位置とみなし、更に、次のＰＳＣＣＨ期間における１回目のＳＣＩのリソース位置を２回目のＳＣＩのリソース位置とみなすようにする。ここで、具体例を図１７Ｂに示す。例えば、図１７Ａにおいて「３」、「４」に示すＳＣＩは、１回目のＳＣＩと２回目のＳＣＩとの間のサブフレーム間隔がＰＳＣＣＨ期間（８サブフレーム）の半分（４サブフレーム）よりも空いている。従って、ユーザ装置ＵＥは、図１７Ｂに示すように、「３」、「４」に示すＳＣＩについては、所定のＰＳＣＣＨ期間（ｎ）において２回目のＳＣＩのリソース位置を１回目のＳＣＩのリソース位置とみなし、所定のＰＳＣＣＨ期間（ｎ）の次のＰＳＣＣＨ期間（ｎ＋１）において１回目のＳＣＩのリソース位置を２回目のＳＣＩのリソース位置とみなすようにする。
【００７０】
以上、３ＧＰＰのＲｅｌ−１２で規定されているリソース選択方法を拡張したリソース選択方法について説明した。当該リソース選択方法によれば、ＳＣＩが繰り返し送信される時間間隔が短縮されるため、受信側のユーザ装置ＵＥにおいて複数のＳＣＩを合成受信する場合等における遅延時間を短縮することが可能になる。
【００７１】
（ＰＳＣＣＨ期間を跨ったデータの繰り返し送信について）
Ｒｅｌ−１２の規定では、１つのＰＳＣＣＨ期間内にＳＣＩリソースプール及びデータリソースプールの両方が含まれており、ＰＳＣＣＨ期間を跨いで同一のＳＣＩ及び同一のデータが繰り返し送信されることは想定されていなかった。しかしながら、上述の３ＧＰＰのＲｅｌ−１２で規定されているリソース選択方法を拡張したリソース選択方法を用いる場合、ＳＣＩは、ＰＳＣＣＨ期間を跨いで繰り返し送信されることになる。そこで、本実施の形態では、データリソースプールについても複数の連続したＰＳＣＣＨ期間に分割すると共に、ユーザ装置ＵＥは、データについてもＰＳＣＣＨ期間を跨いで繰り返し送信するようにしてもよい。
【００７２】
図１８は、ＰＳＣＣＨ期間を跨いでデータが繰り返し送信される場合を示す図である。図１８に示すように、ユーザ装置ＵＥは、ＳＣＩをＰＳＣＣＨ期間を跨って繰り返し送信する場合、データを繰り返し送信するリソースについてもＰＳＣＣＨ期間を跨って選択するようにしてもよい。また、ユーザ装置ＵＥは、データを繰り返し送信するリソースを、ＰＳＣＣＨ期間と同一の長さである「データ再送期間」のリソースの中から選択するようにしてもよい。これにより、ユーザ装置ＵＥは、新たなＳＣＩの１回目の送信が可能なタイミング（具体的には、ＰＳＣＣＨ期間（ｎ＋１）の「１」に示すリソース位置のタイミング）までの間に、データの再送を終えることが可能になる。
【００７３】
なお、３ＧＰＰのＲｅｌ−１２では、データを送信するためのリソースのサブフレーム位置を、ＳＣＩに含まれるＴ−ＲＰＴと呼ばれるビットマップにより指定することが規定されている。また、Ｒｅｌ−１２の規定では、Ｔ−ＲＰＴは、ＳＣＩが送信されるＰＳＣＣＨ期間と同一のＰＳＣＣＨ期間におけるデータリソースプールの最初のサブフレームを起点とするように規定されている。
【００７４】
そこで、本実施の形態では、ＳＣＩがＰＳＣＣＨ期間を跨って繰り返し送信される場合、ＳＣＩに含まれるＴ−ＲＰＴは、１回目のＳＣＩが送信されるサブフレームを起点とすることを意味するように明示的又は暗示的に設定されていてもよい。なお、本実施の形態では、１回目のＳＣＩ及びデータは同一のサブフレームで送信されることから、１回目のデータを送信するサブフレームをＴ−ＲＰＴで指定する必要性は低い。そこで、ＳＣＩがＰＳＣＣＨ期間を跨って繰り返し送信される場合、ＳＣＩに含まれるＴ−ＲＰＴは、１回目のＳＣＩが送信されるＰＳＣＣＨ期間の次のＰＳＣＣＨ期間の最初のサブフレーム起点とすることを意味するように明示的又は暗示的に設定されていてもよい。以上、ＰＳＣＣＨ期間を跨ってデータが繰り返し送信される場合について説明した。
【００７５】
＜機能構成＞
以上説明した複数の実施の形態の動作を実行するユーザ装置ＵＥ及び基地局ｅＮＢの機能構成例を説明する。
【００７６】
（ユーザ装置）
図１９は、実施の形態に係るユーザ装置の機能構成の一例を示す図である。図１９に示すように、ユーザ装置ＵＥは、信号送信部１０１と、信号受信部１０２と、選択部１０３とを有する。なお、図１９は、ユーザ装置ＵＥにおいて本発明の実施の形態に特に関連する機能部のみを示すものであり、少なくともＬＴＥに準拠した動作を行うための図示しない機能も有するものである。また、図１９に示す機能構成は一例に過ぎない。本実施の形態に係る動作を実行できるのであれば、機能区分及び機能部の名称はどのようなものでもよい。ただし、これまでに説明したユーザ装置ＵＥの処理の一部（例：特定の１つ又は複数の変形例、具体例のみ等）を実行可能としてもよい。
【００７７】
信号送信部１０１は、ユーザ装置ＵＥから送信されるべき上位のレイヤの信号から、物理レイヤの各種信号を生成し、無線送信する機能を含む。また、信号送信部１０１は、Ｄ２Ｄ信号の送信機能とセルラ通信の送信機能を有する。また、信号送信部１０１は、Ｄ２Ｄ信号を、選択部１０３で選択されたリソースを用いて送信する機能を有する。また、信号送信部１０１は、複数のデータ送信用のリソースを指定する情報を含むＳＣＩを、複数のＳＣＩ送信用のリソースを用いて繰り返し送信し、複数のデータ送信用のリソースを用いてデータを繰り返し送信する機能を有する。
【００７８】
信号受信部１０２は、他のユーザ装置ＵＥ又は基地局ｅＮＢから各種の信号を無線受信し、受信した物理レイヤの信号からより上位のレイヤの信号を取得する機能を含む。また、信号受信部１０２は、Ｄ２Ｄ信号の受信機能とセルラ通信の受信機能を有する。
【００７９】
選択部１０３は、複数のＳＣＩ送信用のリソースのうち最初にＳＣＩを送信するためのＳＣＩ送信用のリソースと、複数のデータ送信用のリソースのうち最初にデータを送信するためのデータ送信用のリソースとが同一のサブフレームになるように、複数のＳＣＩ送信用のリソースと複数のデータ送信用のリソースとを選択する機能を有する。
【００８０】
また、選択部１０３は、複数のデータ送信用のリソースのうち２回目にデータを送信するためのデータ送信用のリソースを、複数のＳＣＩ送信用のリソースのうち最初にＳＣＩを送信するためのＳＣＩ送信用のリソースのサブフレームより後のサブフレームと、２回目にＳＣＩを送信するためのＳＣＩ送信用のリソースのサブフレームより前のサブフレームとの間のいずれかのサブフレームの中から選択するようにしてもよい。
【００８１】
また、選択部１０３は、複数のデータ送信用のリソースのうち２回目にデータを送信するためのデータ送信用のリソースを、複数のＳＣＩ送信用のリソースのうち２回目にＳＣＩを送信するためのＳＣＩ送信用のリソースのサブフレーム以後のサブフレームの中から選択するようにしてもよい。
【００８２】
また、選択部１０３は、複数のＳＣＩ送信用のリソースのうち、最初にＳＣＩを送信するためのＳＣＩ送信用のリソースと、２回目にＳＣＩを送信するためのＳＣＩ送信用のリソースとが、それぞれ異なるＰＳＣＣＨ期間になるように複数のＳＣＩ送信用のリソースを選択するようにしてもよい。なお、この場合、ＳＣＩリソースプールは、複数の連続したＰＳＣＣＨ期間に分割されていてもよい。
【００８３】
また、選択部１０３は、複数のデータ送信用のリソースのうち、最初にデータを送信するためのデータ送信用のリソースと、２回目にデータを送信するためのデータ送信用のリソースとが、それぞれ異なるＰＳＣＣＨ期間になるように前記複数のデータ用リソースを選択するようにしてもよい。なお、この場合、データリソースプールは、複数の連続したＰＳＣＣＨ期間に分割されていてもよい。
【００８４】
また、選択部１０３は、ＳＣＩリソースプールにおいて、他のユーザ装置ＵＥから送信されるＳＣＩを取得することで、ＳＣＩリソースプール内のリソースの予約状況及びデータリソースプール内のリソースの予約状況を判定し、ＳＣＩリソースプールのうちリソースに空きがあると判定されたリソースの中からＳＣＩを繰り返し送信するための複数のＳＣＩ送信用のリソースを選択し、データリソースプールのうちリソースに空きがあると判定されたリソースの中からデータを繰り返し送信するための複数のデータ送信用のリソースを選択するようにしてもよい。
【００８５】
また、選択部１０３は、ＳＣＩリソースプールの各リソースにおける受信電力に基づいて、ＳＣＩリソースプール内のリソースの予約状況を判定し、ＳＣＩリソースプールのうちリソースに空きがあると判定されたリソースの中からＳＣＩを繰り返し送信するための複数のＳＣＩ送信用のリソースを選択してもよい。また、選択部１０３は、データリソースプールの各リソースにおける受信電力に基づいて、データリソースプール内のリソースの予約状況を判定し、データリソースプールのうちリソースに空きがあると判定されたリソースの中からデータを繰り返し送信するための複数のデータ送信用のリソースを選択するようにしてもよい。
【００８６】
（基地局）
図２０は、実施の形態に係る基地局の機能構成の一例を示す図である。図２０に示すように、基地局ｅＮＢは、信号送信部２０１と、信号受信部２０２と、通知部２０３とを有する。なお、図２０は、基地局ｅＮＢにおいて本発明の実施の形態に特に関連する機能部のみを示すものであり、少なくともＬＴＥに準拠した動作を行うための図示しない機能も有するものである。また、図２０に示す機能構成は一例に過ぎない。本実施の形態に係る動作を実行できるのであれば、機能区分及び機能部の名称はどのようなものでもよい。ただし、これまでに説明した基地局ｅＮＢの処理の一部（例：特定の１つ又は複数の変形例、具体例のみ等）を実行可能としてもよい。
【００８７】
信号送信部２０１は、基地局ｅＮＢから送信されるべき上位のレイヤの信号から、物理レイヤの各種信号を生成し、無線送信する機能を含む。信号受信部２０２は、ユーザ装置ＵＥから各種の信号を無線受信し、受信した物理レイヤの信号からより上位のレイヤの信号を取得する機能を含む。
【００８８】
通知部２０３は、ユーザ装置ＵＥが本実施の形態に係る動作を行うために用いる各種情報を、報知情報（ＳＩＢ）又はＲＲＣシグナリングを用いてユーザ装置ＵＥに通知する。なお、当該各種情報は、例えは、ＳＣＩリソースプール及びデータリソースプールの設定を示す情報、ＳＣＩリソースプールにおけるＰＳＣＣＨ期間の分割位置を示す情報、データリソースプールにおけるＰＳＣＣＨ期間の分割位置を示す情報、又は、Ｔ−ＲＰＴの基点となるサブフレームの位置を示す情報などである。
【００８９】
以上説明した基地局ｅＮＢ及びユーザ装置ＵＥの機能構成は、全体をハードウェア回路（例えば、１つ又は複数のＩＣチップ）で実現してもよいし、一部をハードウェア回路で構成し、その他の部分をＣＰＵとプログラムとで実現してもよい。
【００９０】
（ユーザ装置）
図２１は、実施の形態に係るユーザ装置のハードウェア構成の一例を示す図である。図２１は、図１９よりも実装例に近い構成を示している。図２１に示すように、ユーザ装置ＵＥは、無線信号に関する処理を行うRadio Frequency（ＲＦ）モジュール３０１と、ベースバンド信号処理を行うBase Band（ＢＢ）処理モジュール３０２と、上位レイヤ等の処理を行うＵＥ制御モジュール３０３とを有する。
【００９１】
ＲＦモジュール３０１は、ＢＢ処理モジュール３０２から受信したデジタルベースバンド信号に対して、Digital-to-Analog（Ｄ／Ａ）変換、変調、周波数変換、及び電力増幅等を行うことでアンテナから送信すべき無線信号を生成する。また、受信した無線信号に対して、周波数変換、Analog to Digital（Ａ／Ｄ）変換、復調等を行うことでデジタルベースバンド信号を生成し、ＢＢ処理モジュール３０２に渡す。ＲＦモジュール３０１は、例えば、図１９の信号送信部１０１及び信号受信部１０２の一部を含む。
【００９２】
ＢＢ処理モジュール３０２は、ＩＰパケットとデジタルベースバンド信号とを相互に変換する処理を行う。Digital Signal Processor（ＤＳＰ）３１２は、ＢＢ処理モジュール３０２における信号処理を行うプロセッサである。メモリ３２２は、ＤＳＰ３１２のワークエリアとして使用される。ＲＦモジュール３０１は、例えば、図１９の信号送信部１０１の一部、信号受信部１０２の一部及び選択部１０３を含む。
【００９３】
ＵＥ制御モジュール３０３は、ＩＰレイヤのプロトコル処理、各種アプリケーションの処理等を行う。プロセッサ３１３は、ＵＥ制御モジュール３０３が行う処理を行うプロセッサである。メモリ３２３は、プロセッサ３１３のワークエリアとして使用される。
【００９４】
（基地局）
図２２は、実施の形態に係る基地局のハードウェア構成の一例を示す図である。図２２は、図２０よりも実装例に近い構成を示している。図２２に示すように、基地局ｅＮＢは、無線信号に関する処理を行うＲＦモジュール４０１と、ベースバンド信号処理を行うＢＢ処理モジュール４０２と、上位レイヤ等の処理を行う装置制御モジュール４０３と、ネットワークと接続するためのインタフェースである通信ＩＦ４０４とを有する。
【００９５】
ＲＦモジュール４０１は、ＢＢ処理モジュール４０２から受信したデジタルベースバンド信号に対して、Ｄ／Ａ変換、変調、周波数変換、及び電力増幅等を行うことでアンテナから送信すべき無線信号を生成する。また、受信した無線信号に対して、周波数変換、Ａ／Ｄ変換、復調等を行うことでデジタルベースバンド信号を生成し、ＢＢ処理モジュール４０２に渡す。ＲＦモジュール４０１は、例えば、図２０に示す信号送信部２０１及び信号受信部２０２の一部を含む。
【００９６】
ＢＢ処理モジュール４０２は、ＩＰパケットとデジタルベースバンド信号とを相互に変換する処理を行う。ＤＳＰ４１２は、ＢＢ処理モジュール４０２における信号処理を行うプロセッサである。メモリ４２２は、ＤＳＰ４１２のワークエリアとして使用される。ＢＢ処理モジュール４０２は、例えば、図２０に示す信号送信部２０１の一部、信号受信部２０２の一部及び通知部２０３の一部を含む。
【００９７】
装置制御モジュール４０３は、ＩＰレイヤのプロトコル処理、Operation and Maintenance（ＯＡＭ）処理等を行う。プロセッサ４１３は、装置制御モジュール４０３が行う処理を行うプロセッサである。メモリ４２３は、プロセッサ４１３のワークエリアとして使用される。補助記憶装置４３３は、例えばＨＤＤ等であり、基地局ｅＮＢ自身が動作するための各種設定情報等が格納される。装置制御モジュール４０３は、例えば、図２０に示す通知部２０３の一部を含む。
【００９８】
＜まとめ＞
以上、実施の形態によれば、Ｄ２Ｄ通信をサポートする無線通信システムにおけるユーザ装置であって、制御情報用のリソースプールから制御情報を繰り返し送信するための複数の制御情報用リソースを選択し、データ送信用のリソースプールからデータを繰り返し送信するための複数のデータ用リソースを選択する選択部と、前記複数のデータ用リソースを指定する情報を含む制御情報を前記複数の制御情報用リソースを用いて繰り返し送信し、前記複数のデータ用リソースを用いてデータを繰り返し送信する送信部と、を有し、前記選択部は、前記複数の制御情報用リソースのうち最初に制御情報を送信するための制御情報用リソースと、前記複数のデータ用リソースのうち最初にデータを送信するためのデータ用リソースとが同一のサブフレームになるように、前記複数の制御情報用リソースと前記複数のデータ用リソースとを選択する、ユーザ装置が提供される。このユーザ装置ＵＥにより、制御情報用のリソースプールと、データ用のリソースプールとを周波数多重させたリソースプール構成を採用する場合に、より適切なＤ２Ｄ通信を行うことが可能な技術が提供される。
【００９９】
また、前記選択部は、前記複数のデータ用リソースのうち２回目にデータを送信するためのデータ用リソースを、前記複数の制御情報用リソースのうち最初に制御情報を送信するための制御情報用リソースのサブフレームより後のサブフレームと、２回目に制御情報を送信するための制御情報用リソースのサブフレームより前のサブフレームとの間のいずれかのサブフレームの中から選択するようにしてもよい。これにより、受信側のユーザ装置ＵＥは、必要に応じて２回分のデータの信号を合成して復号することが可能になる。
【０１００】
また、前記選択部は、前記複数のデータ用リソースのうち２回目にデータを送信するためのデータ用リソースを、前記複数の制御情報用リソースのうち２回目に制御情報を送信するための制御情報用リソースのサブフレーム以後のサブフレームの中から選択するようにしてもよい。これにより、受信側のユーザ装置ＵＥは、必要に応じて２回分のデータの信号を合成して復号することが可能になる。また、１回目のＳＣＩを復号することが出来なかった場合に、受信側のユーザ装置ＵＥでバッファすべきサブフレームを最小限に抑えることが可能になる。
【０１０１】
また、前記制御情報用のリソースプールは、複数の連続したＰＳＣＣＨ期間に分割され、前記選択部は、前記複数の制御情報用リソースのうち、最初に制御情報を送信するための制御情報用リソースと、２回目に制御情報を送信するための制御情報用リソースとが、それぞれ異なるＰＳＣＣＨ期間になるように前記複数の制御情報用リソースを選択するようにしてもよい。これにより、制御情報用のリソースプールと、データ用のリソースプールとを周波数多重させたリソースプール構成を採用する場合に、従来のＲｅｌ−１２で規定されているＳＣＩのリソース選択方法（ホッピングパターン）を流用することが可能になる。
【０１０２】
また、前記データ送信用のリソースプールは、複数の連続したＰＳＣＣＨ期間に分割され、前記選択部は、前記複数のデータ用リソースのうち、最初にデータを送信するためのデータ用リソースと、２回目にデータを送信するためのデータ用リソースとが、それぞれ異なるＰＳＣＣＨ期間になるように前記複数のデータ用リソースを選択するようにしてもよい。これにより、制御情報用のリソースプールと、データ用のリソースプールとを周波数多重させたリソースプール構成を採用する場合に、従来のＲｅｌ−１２で規定されているＳＣＩのリソース選択方法（ホッピングパターン）を流用することが可能になる。
【０１０３】
また、前記選択部は、前記制御情報用のリソースプールにおいて、他のユーザ装置から送信される制御情報を取得することで、前記制御情報のリソースプール内のリソースの予約状況及び前記データ送信用のリソースプール内のリソースの予約状況を判定し、前記制御情報用のリソースプールのうちリソースに空きがあると判定されたリソースの中から制御情報を繰り返し送信するための複数の制御情報用リソースを選択し、前記データ送信用のリソースプールのうちリソースに空きがあると判定されたリソースの中からデータを繰り返し送信するための複数のデータ用リソースを選択するようにしてもよい。これにより、ユーザ装置ＵＥは、他のユーザ装置ＵＥから送信されるＤ２Ｄ信号と自身が送信するＤ２Ｄ信号とが干渉する可能性を減らすことが可能になる。
【０１０４】
また、前記選択部は、前記制御情報用のリソースプールの各リソースにおける受信電力に基づいて、前記制御情報のリソースプール内のリソースの予約状況を判定し、前記制御情報用のリソースプールのうちリソースに空きがあると判定されたリソースの中から制御情報を繰り返し送信するための複数の制御情報用リソースを選択し、前記データ送信用のリソースプールの各リソースにおける受信電力に基づいて、前記データ送信用のリソースプール内のリソースの予約状況を判定し、前記データ送信用のリソースプールのうちリソースに空きがあると判定されたリソースの中からデータを繰り返し送信するための複数の制御情報用リソースを選択するようにしてもよい。これにより、ユーザ装置ＵＥは、他のユーザ装置ＵＥから送信されるＤ２Ｄ信号と自身が送信するＤ２Ｄ信号とが干渉する可能性を減らすことが可能になる。また、ＳＣＩをモニタせずに受信電力でリソースの空き状況（予約状況）を判定することができ、ユーザ装置ＵＥの処理負荷を軽減することが可能になる。
【０１０５】
また、実施の形態によれば、Ｄ２Ｄ通信をサポートする無線通信システムにおけるユーザ装置が実行する送信方法であって、制御情報用のリソースプールから制御情報を繰り返し送信するための複数の制御情報用リソースを選択し、データ送信用のリソースプールからデータを繰り返し送信するための複数のデータ用リソースを選択する選択ステップと、前記複数のデータ用リソースを指定する情報を含む制御情報を前記複数の制御情報用リソースを用いて繰り返し送信し、前記複数のデータ用リソースを用いてデータを繰り返し送信する送信ステップと、を有し、前記選択ステップは、前記複数の制御情報用リソースのうち最初に制御情報を送信するための制御情報用リソースと、前記複数のデータ用リソースのうち最初にデータを送信するためのデータ用リソースとが同一のサブフレームになるように、前記複数の制御情報用リソースと前記複数のデータ用リソースとを選択する、送信方法が提供される。この送信方法により、制御情報用のリソースプールと、データ用のリソースプールとを周波数多重させたリソースプール構成を採用する場合に、より適切なＤ２Ｄ通信を行うことが可能な技術が提供される。
【０１０６】
＜実施形態の補足＞
ＰＳＣＣＨ期間は、ＳＡ期間（Scheduling Assignment Period）と呼ばれてもよいし、又は、ＳＣ期間（Sidelink Control Period）と呼ばれてもよい。
【０１０７】
以上、本発明の実施の形態で説明する各装置（ユーザ装置ＵＥ／基地局ｅＮＢ）の構成は、ＣＰＵとメモリを備える当該装置において、プログラムがＣＰＵ（プロセッサ）により実行されることで実現される構成であってもよいし、本実施の形態で説明する処理のロジックを備えたハードウェア回路等のハードウェアで実現される構成であってもよいし、プログラムとハードウェアが混在していてもよい。
【０１０８】
情報の通知は、本明細書で説明した態様／実施形態に限られず、他の方法で行われてもよい。例えば、情報の通知は、物理レイヤシグナリング（例えば、Downlink  Control  Information（ＤＣＩ）、Uplink  Control  Information（ＵＣＩ））、上位レイヤシグナリング（例えば、ＲＲＣシグナリング、ＭＡＣシグナリング、ブロードキャスト情報（Master  Information  Block（ＭＩＢ）、System  Information  Block（ＳＩＢ）））、その他の信号又はこれらの組み合わせによって実施されてもよい。また、ＲＲＣメッセージは、ＲＲＣシグナリングと呼ばれてもよい。また、ＲＲＣメッセージは、例えば、ＲＲＣ接続セットアップ（RRC Connection Setup）メッセージ、ＲＲＣ接続再構成（RRC Connection Reconfiguration）メッセージなどであってもよい。
【０１０９】
本明細書で説明した各態様／実施形態は、Long  Term  Evolution（ＬＴＥ）、LTE-Advanced（ＬＴＥ−Ａ）、ＳＵＰＥＲ  ３Ｇ、ＩＭＴ−Ａｄｖａｎｃｅｄ、４Ｇ、５Ｇ、Future  Radio  Access（ＦＲＡ）、Ｗ−ＣＤＭＡ（登録商標）、ＧＳＭ（登録商標）、ＣＤＭＡ２０００、Ultra  Mobile  Broadband（ＵＭＢ）、ＩＥＥＥ  ８０２．１１（Ｗｉ−Ｆｉ）、ＩＥＥＥ  ８０２．１６（ＷｉＭＡＸ）、ＩＥＥＥ  ８０２．２０、Ultra-WideBand（ＵＷＢ）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、その他の適切なシステムを利用するシステム及び／又はこれらに基づいて拡張された次世代システムに適用されてもよい。
【０１１０】
判定又は判断は、１ビットで表される値（０か１か）によって行われてもよいし、真偽値（Boolean：trueまたはfalse）によって行われてもよいし、数値の比較（例えば、所定の値との比較）によって行われてもよい。
【０１１１】
なお、本明細書で説明した用語及び／又は本明細書の理解に必要な用語については、同一の又は類似する意味を有する用語と置き換えてもよい。例えば、チャネル及び／又はシンボルは信号（シグナル）であってもよい。また、信号はメッセージであってもよい。
【０１１２】
ＵＥは、当業者によって、加入者局、モバイルユニット、加入者ユニット、ワイヤレスユニット、リモートユニット、モバイルデバイス、ワイヤレスデバイス、ワイヤレス通信デバイス、リモートデバイス、モバイル加入者局、アクセス端末、モバイル端末、ワイヤレス端末、リモート端末、ハンドセット、ユーザエージェント、モバイルクライアント、クライアント、またはいくつかの他の適切な用語で呼ばれる場合もある。
【０１１３】
本明細書で説明した各態様／実施形態は単独で用いてもよいし、組み合わせて用いてもよいし、実行に伴って切り替えて用いてもよい。また、所定の情報の通知（例えば、「Ｘであること」の通知）は、明示的に行うものに限られず、暗黙的（例えば、当該所定の情報の通知を行わない）ことによって行われてもよい。
【０１１４】
本明細書で使用する「判断(determining)」、「決定(determining)」という用語は、多種多様な動作を包含する場合がある。「判断」、「決定」は、例えば、計算(calculating)、算出(computing)、処理(processing)、導出(deriving)、調査(investigating)、探索(looking up)（例えば、テーブル、データベースまたは別のデータ構造での探索）、確認(ascertaining)した事を「判断」「決定」したとみなす事などを含み得る。また、「判断」、「決定」は、受信(receiving)（例えば、情報を受信すること）、送信(transmitting)(例えば、情報を送信すること)、入力(input)、出力(output)、アクセス(accessing)（例えば、メモリ中のデータにアクセスすること）した事を「判断」「決定」したとみなす事などを含み得る。また、「判断」、「決定」は、解決(resolving)、選択(selecting)、選定(choosing)、確立(establishing)、比較(comparing)などした事を「判断」「決定」したとみなす事を含み得る。つまり、「判断」「決定」は、何らかの動作を「判断」「決定」したとみなす事を含み得る。
【０１１５】
本明細書で使用する「に基づいて」という記載は、別段に明記されていない限り、「のみに基づいて」を意味しない。言い換えれば、「に基づいて」という記載は、「のみに基づいて」と「に少なくとも基づいて」の両方を意味する。
【０１１６】
また、本明細書で説明した各態様／実施形態の処理手順、シーケンスなどは、矛盾の無い限り、順序を入れ替えてもよい。例えば、本明細書で説明した方法については、例示的な順序で様々なステップの要素を提示しており、提示した特定の順序に限定されない。
【０１１７】
入出力された情報等は特定の場所（例えば、メモリ）に保存されてもよいし、管理テーブルで管理してもよい。入出力される情報等は、上書き、更新、または追記され得る。出力された情報等は削除されてもよい。入力された情報等は他の装置へ送信されてもよい。
【０１１８】
所定の情報の通知（例えば、「Ｘであること」の通知）は、明示的に行うものに限られず、暗黙的（例えば、当該所定の情報の通知を行わない）ことによって行われてもよい。
【０１１９】
本明細書で説明した情報、信号などは、様々な異なる技術のいずれかを使用して表されてもよい。例えば、上記の説明全体に渡って言及され得るデータ、命令、コマンド、情報、信号、ビット、シンボル、チップなどは、電圧、電流、電磁波、磁界若しくは磁性粒子、光場若しくは光子、又はこれらの任意の組み合わせによって表されてもよい。
【０１２０】
以上、本発明の実施の形態を説明してきたが、開示される発明はそのような実施形態に限定されず、当業者は様々な変形例、修正例、代替例、置換例等を理解するであろう。発明の理解を促すため具体的な数値例を用いて説明がなされたが、特に断りのない限り、それらの数値は単なる一例に過ぎず適切な如何なる値が使用されてもよい。上記の説明における項目の区分けは本発明に本質的ではなく、２以上の項目に記載された事項が必要に応じて組み合わせて使用されてよいし、ある項目に記載された事項が、別の項目に記載された事項に（矛盾しない限り）適用されてよい。機能ブロック図における機能部又は処理部の境界は必ずしも物理的な部品の境界に対応するとは限らない。複数の機能部の動作が物理的には１つの部品で行われてもよいし、あるいは１つの機能部の動作が物理的には複数の部品により行われてもよい。実施の形態で述べたシーケンス及びフローチャートは、矛盾の無い限り順序を入れ替えてもよい。処理説明の便宜上、ユーザ装置ＵＥ／基地局ｅＮＢは機能的なブロック図を用いて説明されたが、そのような装置はハードウェアで、ソフトウェアで又はそれらの組み合わせで実現されてもよい。本発明の実施の形態に従ってユーザ装置ＵＥが有するプロセッサにより動作するソフトウェア及び本発明の実施の形態に従って基地局ｅＮＢが有するプロセッサにより動作するソフトウェアはそれぞれ、ランダムアクセスメモリ（ＲＡＭ）、フラッシュメモリ、読み取り専用メモリ（ＲＯＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、レジスタ、ハードディスク（ＨＤＤ）、リムーバブルディスク、ＣＤ−ＲＯＭ、データベース、サーバその他の適切な如何なる記憶媒体に保存されてもよい。
【０１２１】
本国際特許出願は２０１６年３月３１日に出願した日本国特許出願第２０１６−０７３４５４号に基づきその優先権を主張するものであり、日本国特許出願第２０１６−０７３４５４号の全内容を本願に援用する。
【符号の説明】
【０１２２】
ＵＥ  ユーザ装置
ｅＮＢ  基地局
１０１  信号送信部
１０２  信号受信部
１０３  選択部
２０１  信号送信部
２０２  信号受信部
２０３  通知部
３０１  ＲＦモジュール
３０２  ＢＢ処理モジュール
３０３  ＵＥ制御モジュール
３０４  通信ＩＦ
４０１  ＲＦモジュール
４０２  ＢＢ処理モジュール
４０３  装置制御モジュール
【図１】
2017169835.tif 000003
【図２】
2017169835.tif 000004
【図３Ａ】
2017169835.tif 000005
【図３Ｂ】
2017169835.tif 000006
【図４】
2017169835.tif 000007
【図５】
2017169835.tif 000008
【図６】
2017169835.tif 000009
【図７Ａ】
2017169835.tif 000010
【図７Ｂ】
2017169835.tif 000011
【図８Ａ】
2017169835.tif 000012
【図８Ｂ】
2017169835.tif 000013
【図９Ａ】
2017169835.tif 000014
【図９Ｂ】
2017169835.tif 000015
【図１０】
2017169835.tif 000016
【図１１】
2017169835.tif 000017
【図１２】
2017169835.tif 000018
【図１３】
2017169835.tif 000019
【図１４】
2017169835.tif 000020
【図１５】
2017169835.tif 000021
【図１６】
2017169835.tif 000022
【図１７Ａ】
2017169835.tif 000023
【図１７Ｂ】
2017169835.tif 000024
【図１８】
2017169835.tif 000025
【図１９】
2017169835.tif 000026
【図２０】
2017169835.tif 000027
【図２１】
2017169835.tif 000028
【図２２】
2017169835.tif 000029
【国際調査報告】
2017169835.tif 000030
2017169835.tif 000031
2017169835.tif 000032
2017169835.tif 000033