(57)【要約】Ｄ２Ｄ通信をサポートする無線通信システムにおけるユーザ装置であって、制御情報用のリソースプールとデータ送信用のリソースプールとが時間方向に制約なく連続して設定される無線リソースにおいて、前記制御情報用のリソースプールから制御情報を送信するための第一の制御情報用リソースを選択し、前記データ送信用のリソースプールからデータを送信するための第一のデータ用リソースを選択する選択部と、前記第一のデータ用リソースを指定する情報を含む制御情報を前記第一の制御情報用リソースで送信し、前記第一のデータ用リソースを用いてデータを送信する送信部と、を有するユーザ装置を提供する。
2017135126.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 Shared Channel）のリソースプールと、制御情報（ＳＣＩ：Sidelink Control Information）を送信するための無線リソースの範囲であるＰＳＣＣＨ（Physical Sildelink Control Channel）のリソースプールとが時間多重されて周期的に設定されている。当該周期は、ＳＣ期間（Ｓｉｄｅｌｉｎｋ  Ｃｏｎｔｒｏｌ  ｐｅｒｉｏｄ）と呼ばれ、４０ｍｓ以上の周期であることが規定されている。【０００８】
また、送信側のユーザ装置は、ＰＳＣＣＨのリソースプールから選択された無線リソースで制御情報（ＳＣＩ）を送信し、ＰＳＳＣＨのリソースプールから選択された無線リソースでデータを送信する。制御情報には、ＰＳＳＣＨのリソースプールから選択された無線リソースの位置等を示す情報が含まれる。従って、送信側のユーザ装置が、新たなデータを送信可能なタイミングは、ＳＣ期間の長さや、ＰＳＣＣＨ／ＰＳＳＣＨのリソースプール構成の影響を受けることになる。【０００９】
ここで、Ｖ２Ｘでは、制御情報及びデータを送信可能なタイミングを柔軟に制御可能にするため、様々なリソースプール構成が検討されている。一例として、制御情報を送信するためのリソースプールと、データを送信するためのリソースプールとを周波数多重させたリソースプール構成が検討されている。【００１０】
図２及び図３は課題を説明するための図である。図２及び図３は、制御情報を送信するためのリソースプール（以下、「ＳＣＩリソースプール」と呼ぶ）、と、データを送信するためのリソースプール（以下、「データリソースプール」と呼ぶ）とを、ＳＣ期間内で時間多重及び周波数多重させたリソースプール構成である。また、図２は、ＳＣＩリソースプールの期間とデータリソースプールの期間が同一である場合、図３は、ＳＣＩリソースプールの期間よりもデータリソースプールの期間が長い場合を示している。【００１１】
例えば、図２に示すリソースプール構成では、ユーザ装置は、ＳＣＩに対応するデータを送信する無線リソースを選択する際、ＳＣＩリソースプールと同一のＳＣ期間内のデータリソースプールで無線リソースを選択する必要があるという制約を受けることになる。例えば、データリソースプールが２０ｍｓであると仮定した場合、ユーザ装置は、１つのＳＣＩで、１０ｍｓ間隔で４回分のデータ送信用の無線リソースを選択することはできない。そこで、図３に示すように、データリソースプールの期間がＳＣＩリソースプールよりも長くなるようなリソースプール構成を採用することも考えられる。しかしながら、図３に示すリソースプール構成では、２つのデータリソースプールが一部の期間で重複することになるため、複数のユーザ装置から送信されたデータの無線リソースが重複してしまい、衝突を引き起こす可能性があるという問題がある。【００１２】
また、Ｄ２Ｄ通信は、同一のキャリアを使用してＤ２Ｄ信号の送受信が行われるハーフデュプレックス（Half Duplex）通信方式であるため、ユーザ装置は、同一サブフレームにおいて、Ｄ２Ｄ信号の送受信を同時に行うことができない。つまり、図２及び図３に示すように、ＵＥ１（ユーザ装置１）から制御情報（ＳＣＩ）が送信されるサブフレームと、ＵＥ２（ユーザ装置２）からデータが送信されるサブフレームとが同一である場合、ＵＥ１は、ＵＥ２から送信されるデータを受信することができないという問題がある。また、Ｖ２ＸはＤ２Ｄの一種であると考えると、上述の問題はＤ２Ｄ全般に発生し得る。【００１３】
開示の技術は上記に鑑みてなされたものであって、より柔軟なＤ２Ｄ通信を行うことが可能な技術を提供することを目的とする。
【課題を解決するための手段】
【００１４】
開示の技術のユーザ装置は、Ｄ２Ｄ通信をサポートする無線通信システムにおけるユーザ装置であって、制御情報用のリソースプールとデータ送信用のリソースプールとが時間方向に制約なく連続して設定される無線リソースにおいて、前記制御情報用のリソースプールから制御情報を送信するための第一の制御情報用リソースを選択し、前記データ送信用のリソースプールからデータを送信するための第一のデータ用リソースを選択する選択部と、前記第一のデータ用リソースを指定する情報を含む制御情報を前記第一の制御情報用リソースで送信し、前記第一のデータ用リソースを用いてデータを送信する送信部と、を有する。
【発明の効果】
【００１５】
開示の技術によれば、より柔軟なＤ２Ｄ通信を行うことが可能な技術が提供される。
【図面の簡単な説明】
【００１６】
【図１】Ｖ２Ｘを説明するための図である。
【図２】課題を説明するための図である。
【図３】課題を説明するための図である。
【図４Ａ】Ｄ２Ｄを説明するための図である。
【図４Ｂ】Ｄ２Ｄを説明するための図である。
【図５】Ｄ２Ｄ通信に用いられるＭＡＣ  ＰＤＵを説明するための図である。
【図６】ＳＬ−ＳＣＨ  ｓｕｂｈｅａｄｅｒのフォーマットを説明するための図である。
【図７】実施の形態に係る無線通信システムの構成例を示す図である。
【図８】ＳＣＩリソースプール及びデータリソースプールの構成例（物理）を示す図である。
【図９Ａ】ＳＣＩの繰り返し送信方法（その１）を説明するための図である。
【図９Ｂ】ＳＣＩの繰り返し送信方法（その１）を説明するための図である。
【図１０】ＳＣＩの繰り返し送信方法（その２）を説明するための図である。
【図１１】ＳＣＩの繰り返し送信方法（その２）を説明するための図である。
【図１２】データの繰り返し送信方法を説明するための図である。
【図１３】ＳＣＩ送信用リソースの予約方法を説明するための図である。
【図１４】データ送信用リソースの予約方法を説明するための図である。
【図１５】ＳＣＩ及びデータを送信するためのリソースの予約方法の具体例（その１）を示す図である。
【図１６】ＳＣＩ及びデータを送信するためのリソースの予約方法の具体例（その２）を示す図である。
【図１７】実施の形態に係るユーザ装置の機能構成の一例を示す図である。
【図１８】実施の形態に係る基地局の機能構成の一例を示す図である。
【図１９】実施の形態に係るユーザ装置のハードウェア構成の一例を示す図である。
【図２０】実施の形態に係る基地局のハードウェア構成の一例を示す図である。
【発明を実施するための形態】
【００１７】
以下、図面を参照して本発明の実施の形態を説明する。なお、以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。例えば、本実施の形態に係る無線通信システムはＬＴＥに準拠した方式のシステムを想定しているが、本発明はＬＴＥに限定されるわけではなく、他の方式にも適用可能である。なお、本明細書及び特許請求の範囲において、「ＬＴＥ」は、３ＧＰＰのリリース８、又は９に対応する通信方式のみならず、３ＧＰＰのリリース１０、１１、１２、１３、又はリリース１４以降に対応する第５世代の通信方式も含む広い意味で使用する。
【００１８】
また、本実施の形態は、主にＶ２Ｘを対象としているが、本実施の形態に係る技術は、Ｖ２Ｘに限らず、広くＤ２Ｄ全般に適用可能である。また、「Ｄ２Ｄ」はその意味としてＶ２Ｘを含むものである。
【００１９】
また、「Ｄ２Ｄ」は、ユーザ装置ＵＥ間でＤ２Ｄ信号を送受信する処理手順のみならず、Ｄ２Ｄ信号を基地局が受信（モニタ）する処理手順、及び、ＲＲＣ  ｉｄｌｅの場合若しくは基地局ｅＮＢとコネクションを確立していない場合に、ユーザ装置ＵＥが基地局ｅＮＢに上り信号を送信する処理手順を含む広い意味で使用する。
【００２０】
以下の説明では、Ｄ２Ｄ通信に用いられる制御情報を"ＳＣＩ"と呼ぶが、これに限定されることを意図しているのではない。本実施の形態には、従来のＤ２Ｄで用いられていた"ＳＡ（Scheduling Assignment）"の名称で呼ばれる制御情報も含まれる。また、仮にＶ２Ｘにて他の用語が新たに規定されたとしてもＤ２Ｄ通信に用いられる制御情報を意味するのであれば本実施の形態に含まれる。
【００２１】
＜＜Ｄ２Ｄの概要＞＞
まず、ＬＴＥで規定されているＤ２Ｄの概要について説明する。なお、Ｖ２Ｘにおいても、ここで説明するＤ２Ｄの技術を使用することは可能であり、本発明の実施の形態におけるＵＥは、当該技術によるＤ２Ｄ信号の送受信を行うことができる。
【００２２】
既に説明したように、Ｄ２Ｄには、大きく分けて「Ｄ２Ｄディスカバリ」と「Ｄ２Ｄコミュニケーション」がある。「Ｄ２Ｄディスカバリ」については、図４Ａに示すように、Ｄｉｓｃｏｖｅｒｙ  ｐｅｒｉｏｄ毎に、Ｄｉｓｃｏｖｅｒｙメッセージ用のリソースプールが確保され、ＵＥはそのリソースプール内でＤｉｓｃｏｖｅｒｙメッセージを送信する。より詳細にはＴｙｐｅ１、Ｔｙｐｅ２ｂがある。Ｔｙｐｅ１では、ＵＥが自律的にリソースプールから送信リソースを選択する。Ｔｙｐｅ２ｂでは、上位レイヤシグナリング（例えばＲＲＣ信号）により準静的なリソースが割り当てられる。
【００２３】
「Ｄ２Ｄコミュニケーション」についても、図４Ｂに示すように、ＳＣＩ／データ送信用のリソースプールが周期的に確保される。当該周期は、ＳＣ期間（ＳＣ  ｐｅｒｉｏｄ）と呼ばれる。送信側のＵＥはＣｏｎｔｒｏｌリソースプール（ＳＣＩ送信用リソースプール）から選択されたリソースでＳＣＩによりデータ送信用リソース等を受信側に通知し、当該データ送信用リソースでデータを送信する。「Ｄ２Ｄコミュニケーション」について、より詳細には、Ｍｏｄｅ１とＭｏｄｅ２がある。Ｍｏｄｅ１では、ｅＮＢからＵＥに送られる（Ｅ）ＰＤＣＣＨによりダイナミックにリソースが割り当てられる。Ｍｏｄｅ２では、ＵＥはリソースプールから自律的に送信リソースを選択する。リソースプールについては、ＳＩＢで通知されたり、予め定義されたものが使用される。
【００２４】
ＬＴＥにおいて、「Ｄ２Ｄディスカバリ」に用いられるチャネルはＰＳＤＣＨ（Physical Sidelink Discovery Channel）と称され、「Ｄ２Ｄコミュニケーション」におけるＳＣＩ等の制御情報を送信するチャネルはＰＳＣＣＨ（Physical Sidelink Control Channel）と称され、データを送信するチャネルはＰＳＳＣＨ（Physical Sidelink Shared Channel）と称される（非特許文献２）。
【００２５】
Ｄ２Ｄ通信に用いられるＭＡＣ（Medium Access Control）ＰＤＵ（Protocol Data Unit）は、図５に示すように、少なくともＭＡＣ  ｈｅａｄｅｒ、ＭＡＣ  Ｃｏｎｔｒｏｌ  ｅｌｅｍｅｎｔ、ＭＡＣ  ＳＤＵ（Service Data Unit）、Ｐａｄｄｉｎｇで構成される。ＭＡＣ  ＰＤＵはその他の情報を含んでも良い。ＭＡＣ  ｈｅａｄｅｒは、１つのＳＬ−ＳＣＨ（Sidelink Shared Channel）ｓｕｂｈｅａｄｅｒと、１つ以上のＭＡＣ  ＰＤＵ  ｓｕｂｈｅａｄｅｒで構成される。
【００２６】
図６に示すように、ＳＬ−ＳＣＨ  ｓｕｂｈｅａｄｅｒは、ＭＡＣ  ＰＤＵフォーマットバージョン（Ｖ）、送信元情報（ＳＲＣ）、送信先情報（ＤＳＴ）、Ｒｅｓｅｒｖｅｄ  ｂｉｔ（Ｒ）等で構成される。Ｖは、ＳＬ−ＳＣＨ  ｓｕｂｈｅａｄｅｒの先頭に割り当てられ、ＵＥが用いるＭＡＣ  ＰＤＵフォーマットバージョンを示す。送信元情報には、送信元に関する情報が設定される。送信元情報には、ＰｒｏＳｅ  ＵＥ  ＩＤに関する識別子が設定されてもよい。送信先情報には、送信先に関する情報が設定される。送信先情報には、送信先のＰｒｏＳｅ  Ｌａｙｅｒ−２  Ｇｒｏｕｐ  ＩＤに関する情報が設定されてもよい。
【００２７】
＜＜システム構成＞＞
図７は、実施の形態に係る無線通信システムの構成例を示す図である。図７に示すように、本実施の形態に係る無線通信システムは、基地局ｅＮＢ、ユーザ装置ＵＥ１、ユーザ装置ＵＥ２を有する。図７において、ユーザ装置ＵＥ１は送信側、ユーザ装置ＵＥ２は受信側を意図しているが、ユーザ装置ＵＥ１とユーザ装置ＵＥ２はいずれも送信機能と受信機能の両方を備える。以下、ユーザ装置ＵＥ１とユーザ装置ＵＥ２を特に区別しない場合、単に「ユーザ装置ＵＥ」と記述する。
【００２８】
図７に示すユーザ装置ＵＥ１、ユーザ装置ＵＥ２は、それぞれ、ＬＴＥにおけるユーザ装置ＵＥとしてのセルラ通信の機能、及び、上述したチャネルでの信号送受信を含むＤ２Ｄ機能を有している。また、ユーザ装置ＵＥ１、ユーザ装置ＵＥ２は、本実施の形態で説明する動作を実行する機能を有している。なお、セルラ通信の機能及び既存のＤ２Ｄの機能については、一部の機能（本実施の形態で説明する動作を実行できる範囲）のみを有していてもよいし、全ての機能を有していてもよい。
【００２９】
また、各ユーザ装置ＵＥは、Ｄ２Ｄの機能を有するいかなる装置であってもよいが、例えば、各ユーザ装置ＵＥは、車両、歩行者が保持する端末、ＲＳＵ（ＵＥの機能を有するＵＥタイプＲＳＵ）等である。
【００３０】
また、基地局ｅＮＢについては、ＬＴＥにおける基地局ｅＮＢとしてのセルラ通信の機能、及び、本実施の形態におけるユーザ装置ＵＥの通信を可能ならしめるための機能（リソース割当ての機能、設定情報通知機能等）を有している。また、基地局ｅＮＢはＲＳＵ（ｅＮＢの機能を有するｅＮＢタイプＲＳＵ）を含む。
【００３１】
＜＜概要＞＞
図４Ｂを用いて前述したように、従来のＤ２Ｄでは、ＳＣＩ／データリソースプールがＳＣ期間の単位で周期的に設定されていた。一方、本実施の形態では、Ｄ２Ｄ信号を送信するリソースを柔軟に制御可能にするため、ＳＣ期間の概念を排除し、ＳＣＩリソースプールとデータリソースプールとを時間方向に制約なく（つまり、ＳＣ期間のように、時間方向に時間的な区切りを設けずに）連続して設定する。
【００３２】
図８は、ＳＣＩリソースプール及びデータリソースプールの構成例（物理）を示す図である。図８に示すように、本実施の形態では、ＳＣＩリソースプールとデータリソースプールとが時間方向に無制限に連続して設定される。また、データリソースプールが設定される帯域の上下の帯域にＳＣＩリソースプールが設定される。ＳＣＩリソースプール及びデータリソースプールの設定は、報知情報（ＳＩＢ）又はＲＲＣシグナリングにより基地局ｅＮＢからユーザ装置ＵＥに通知されてもよいし、ＳＩＭ（Subscriber Identity Module）又はコアネットワーク等を介してユーザ装置ＵＥに事前設定（Pre-Configured）されていてもよい。
【００３３】
また、従来のＤ２Ｄでは、ＳＣ期間内のＳＣＩ／データリソースプール内で同一のＳＣＩ／データが繰り返し送信（ホッピング送信）されるように規定されていたが、本実施の形態では、ＳＣ期間の概念を排除するため、新たなＳＣＩ／データの繰り返し送信方法を規定する。
【００３４】
具体的には後述するが、ユーザ装置ＵＥは、同一のＳＣＩを、図８に示す上側のＳＣＩリソースプールと下側のＳＣＩリソースプールとの間で、周波数ホッピングさせながら繰り返し送信する。
【００３５】
また、本実施の形態では、ユーザ装置ＵＥは、同一のデータ（ＭＡＣ  ＰＤＵ）を、所定のサブフレーム間隔で繰り返し送信するように動作する。所定のサブフレーム間隔の具体的な決定方法については後述する。
【００３６】
＜＜処理手順＞＞
＜ＳＣＩの繰り返し送信方法（その１）について＞
次に、ユーザ装置ＵＥがＳＣＩを繰り返し送信する際に、各ＳＣＩを送信するリソースの位置を決定する方法について説明する。以下、ユーザ装置ＵＥがＳＣＩを繰り返し送信する回数が２回の場合及び３回以上の場合に分けて説明する。なお、ユーザ装置ＵＥがＳＣＩを繰り返し送信する回数は、報知情報（ＳＩＢ）又はＲＲＣシグナリングにより基地局ｅＮＢからユーザ装置ＵＥに通知されてもよいし、ＳＩＭ又はコアネットワーク等を介してユーザ装置ＵＥに事前設定（Pre-Configured）されていてもよい。また、ユーザ装置ＵＥ毎に異なる回数が指定されてもよいし、セル毎又はＳＣＩリソースプール毎に異なる回数が指定されるようにしてもよい。
【００３７】
（ＳＣＩが２回繰り返し送信される場合）
まず、ＳＣＩが２回以上繰り返し送信される場合のリソース決定方法について説明する。ユーザ装置ＵＥは、１回目（最初）に送信されるＳＣＩのリソースと、２回目に送信されるＳＣＩのリソースとが、それぞれ異なるＳＣＩリソースプール（図８に示す上側のＳＣＩリソースプール及び下側のＳＣＩリソースプール）に属するようにＳＣＩが周波数ホッピングされて送信されるようにする。
【００３８】
また、前述の通り、Ｄ２Ｄ通信は、同一のキャリアを使用してＤ２Ｄ信号の送受信が行われるハーフデュプレックス（Half Duplex）通信方式であるため、ユーザ装置ＵＥは、同一サブフレームにおいて、Ｄ２Ｄ信号の送受信を同時に行うことができない。つまり、複数のユーザ装置ＵＥが同一のサブフレームでＳＣＩを送信する際、複数のユーザ装置ＵＥが同一のサブフレームで繰り返しＳＣＩを送信してしまうと、当該複数のユーザ装置ＵＥは、お互いのＳＣＩを受信することができなくなってしまう。そこで、ＳＣＩの繰り返し送信方法（その１）では、１回目（最初）に送信されるＳＣＩの時間方向のリソース（サブフレーム）と、２回目に送信されるＳＣＩの周波数方向のリソース（サブフレーム）との間隔が、１回目に送信されるＳＣＩの周波数方向のリソースに基づいて決定されるようにする。
【００３９】
図９Ａ−ＢはＳＣＩの繰り返し送信方法（その１）を説明するための図である。図９Ａ−Ｂは、ＳＣＩリソースプールを論理的に図示している。つまり、物理的な表現に置き換えると、図９Ａ−Ｂの４つのリソース（「ｎｆ」＝０、１、２、３で示されるリソース）は、順に、図８の上側及び下側のＳＣＩリソースプールに存在する４つのリソースに対応する。なお、図９Ａ−Ｂの「ｎｆ＝０」のリソースが、図８の周波数方向の一番上のリソース（図８の最上段のリソース）に対応していてもよいし、逆に、図８の周波数方向の一番下のリソース（図８の最下段のリソース）に対応していてもよい。なお、図９Ａ−Ｂ（図８も同様）に示される１つのブロックは、ＳＣＩの送信に用いられるリソースブロックペアを意味している。なお、図８及び図９Ａ−Ｂでは、ＳＣＩリソースプールは周波数方向に４つのリソースブロックで構成されているが、一例であり、５つ以上のリソースブロックから構成されていてもよい。
【００４０】
図９Ａ−Ｂにおいて、「ｎｔ」はサブフレームの位置を意味しており、「ｎｆ」は周波数方向のリソースブロックの位置を意味している。なお、「ｎｔ」は具体的なサブフレーム番号を意図しているのではなく、相対的なサブフレーム位置を示す変数である。同様に、「ｎｆ」も、相対的な周波数方向のリソースブロックの位置を示す変数である。
【００４１】
繰返し送信方法（その１）では、ユーザ装置ＵＥは、１回目に送信するＳＣＩのリソースを、図９Ａ−Ｂの上半分のリソースの中から任意の位置のリソース（ｎｔ１、ｎｆ１）を選択すると共に、２回目に送信するＳＣＩのリソースの位置（ｎｔ２、ｎｆ２）を、以下に示す数式１又は数式２を用いて決定する。なお、「Ｎｆ」は、ＳＣＩリソースプール全体に含まれる周波数方向のリソースブロック数を意味している（以降に示す数式３、数式４、数式５も同様）。図９Ａ−Ｂの例では、「Ｎｆ＝４」である。
（数式１）
【００４２】
【数１】
2017135126.tif 000003
（数式２）
【００４３】
【数２】
2017135126.tif 000004
数式１を用いた場合における、１回目及び２回目のＳＣＩのリソース位置の例を図９Ａに示す。図９Ａに示すように、例えば、１回目のＳＣＩが（ｎｔ、ｎｆ）＝（０、０）のリソースで送信される場合、２回目のＳＣＩは（ｎｔ、ｎｆ）＝（１、２）のリソースで送信されることになる。同様に、例えば、１回目のＳＣＩが（ｎｔ、ｎｆ）＝（０、１）のリソースで送信される場合、２回目のＳＣＩは（ｎｔ、ｎｆ）＝（２、３）のリソースで送信されることになる。
【００４４】
また、数式２を用いた場合における、１回目及び２回目のＳＣＩのリソース位置の例を図９Ｂに示す。図９Ｂに示すように、例えば、１回目のＳＣＩが（ｎｔ、ｎｆ）＝（０、０）のリソースで送信される場合、２回目のＳＣＩは（ｎｔ、ｎｆ）＝（１、２）のリソースで送信されることになる。同様に、例えば、１回目のＳＣＩが（ｎｔ、ｎｆ）＝（０、１）のリソースで送信される場合、２回目のＳＣＩは（ｎｔ、ｎｆ）＝（２、２）のリソースで送信されることになる。
【００４５】
つまり、数式１又は数式２を用いることで、同一のサブフレームかつ異なる周波数のリソースで送信される２つのＳＣＩは、１回目の送信時と２回目の送信時とでは異なるサブフレームで送信されることになる。また、異なるサブフレームかつ同一の周波数のリソースで送信される２つのＳＣＩは、１回目の送信時と２回目の送信時とでは同一のサブフレーム間隔で送信されることになる。言い換えると、２回目に送信されるＳＣＩのサブフレーム位置は、１回目に送信されるＳＣＩの周波数方向のリソース位置に基づき決定されることになる。
【００４６】
また、数式１では、１回目の送信時と２回目の送信時とでは、周波数方向で同一のオフセット（２リソース分のオフセット）ずれたリソースで送信されることになるが、数式２では、１回目の送信時と２回目の送信時とでは、更に、周波数方向のオフセットが分散されることになる。例えば、図９Ｂにおいて、１回目のＳＣＩが（ｎｔ、ｎｆ）＝（０、０）のリソースで送信される場合、２回目のＳＣＩは（ｎｔ、ｎｆ）＝（１、２）のリソースで送信されることになる。つまり、周波数方向のオフセットは２リソース分である。一方、１回目のＳＣＩが（ｎｔ、ｎｆ）＝（０、１）のリソースで送信される場合、２回目のＳＣＩは（ｎｔ、ｎｆ）＝（２、２）のリソースで送信されることになる。つまり、周波数方向のオフセットは１リソース分である。つまり、数式２を用いることで、１回目に送信されるＳＣＩと２回目に送信されるＳＣＩとで、周波数方向のリソースが分散されることになる。
【００４７】
（ＳＣＩが３回以上繰り返し送信される場合）
続いて、ＳＣＩが３回以上繰り返し送信される場合のリソース決定方法について説明する。以下の説明では、ＳＣＩが繰り返し送信される回数を「Ｋ（Ｋ≧３）」と定義する。
【００４８】
［Ｋが偶数の場合］
Ｋが偶数の場合、ユーザ装置ＵＥは、前述した「（ＳＣＩが２回繰り返し送信される場合）」で説明したリソース決定方法を、「Ｋ／２」回繰り返すようにしてもよい。例えば、ＳＣＩを６回繰り返し送信する場合、ユーザ装置ＵＥは、前述した「（ＳＣＩが２回繰り返し送信される場合）」で説明したリソース決定方法を３回行うようにしてもよい。
【００４９】
ここで、前述した「（ＳＣＩが２回繰り返し送信される場合）」では、１回目に送信するＳＣＩのリソースは、ユーザ装置ＵＥが任意に選択するようにした。そこで、ＳＣＩが３回以上繰り返し送信される場合で、Ｋが偶数の場合、「２ｉ＋１」回目（ｉ＝１、２、３・・）で送信されるＳＣＩのリソースの位置（例えば、Ｋ＝６の場合、３回目及び５回目に送信されるＳＣＩのリソースの位置）は、以下の数式３に従って決定されるようにしてもよい。なお、数式３において、ｎｔ（１）及びｎｆ（１）の値は、それぞれ１回目のＳＣＩ送信時のリソース位置に該当する。
（数式３）
【００５０】
【数３】
2017135126.tif 000005
数式３を用いる場合、ＳＣＩが繰り返し送信されるリソースの位置（ホッピングパターン）は、ユーザ装置ＵＥに関わらず一意に（固定的に）決定されるため、受信側のユーザ装置ＵＥは、複数回送信されるＳＣＩのリソース位置を全て事前に把握することができる。つまり、受信側のユーザ装置ＵＥは、複数のＳＣＩのリソースを合成することで合成ゲインを得ることが可能になる。
【００５１】
また、「２ｉ＋１」回目（ｉ＝１、２、３・・）で送信されるＳＣＩのリソースの位置を、以下に示す数式４を用いて決定するようにしてもよい。なお、数式４の「ＳＡ＿ＩＤ」は、所定のグループのユーザ装置ＵＥに割当てられるＩＤ（ＳＡ  ＩＤ：Sidelink group destination identity）である。
（数式４）
【００５２】
【数４】
2017135126.tif 000006
数式４を用いる場合、ＳＣＩが繰り返し送信されるリソースの位置（ホッピングパターン）は、グループが異なるユーザ装置ＵＥ毎に変化することになる。つまり、数式４が用いられる場合、グループが異なる複数のユーザ装置ＵＥが１回目にＳＣＩを送信するリソースとして同一のリソースを選択してしまった場合であっても、３回目以降にＳＣＩが送信されるリソースの位置が分散されることになり、ＳＣＩの衝突を回避することが可能になる。
【００５３】
［Ｋが奇数の場合］
Ｋが奇数の場合、ユーザ装置ＵＥは、前述した「Ｋが偶数の場合」と同様の方法でＳＣＩを送信するリソースの位置を決定すると共に、更に、追加で１回ＳＣＩを送信するようにしてもよい。例えば、ＳＣＩを７回繰り返し送信する場合、ユーザ装置ＵＥは、前述した「Ｋが偶数の場合」で説明したリソース決定方法により、１〜６回目に送信されるＳＣＩのリソース位置を決定すると共に、更に、追加でＳＣＩを１回送信するようにしてもよい。
【００５４】
追加で１回送信されるＳＣＩのリソース位置は、「Ｋが偶数の場合」で説明したリソース決定方法と同様の方法を用いて決定されるリソース位置のうち最後の奇数回目のリソース位置が用いられるようにしてもよい。例えば、ＳＣＩを７回繰り返し送信する場合、ユーザ装置ＵＥは、前述した「Ｋが偶数の場合」で説明したリソース決定方法により、１〜８回目に送信されるＳＣＩのリソース位置を決定し、追加で１回送信されるＳＣＩのリソース位置は、７回目で送信されるＳＣＩのリソース位置とするようにしてもよい。
【００５５】
また、他の方法として、ユーザ装置ＵＥは、追加で１回送信されるＳＣＩのリソース位置として「Ｋが偶数の場合」で説明したリソース決定方法と同様の方法を用いて決定されるリソース位置のうち、いずれか一方を用いるようにしてもよい。例えば、ＳＣＩを７回繰り返し送信する場合、ユーザ装置ＵＥは、前述した「Ｋが偶数の場合」で説明したリソース決定方法により、１〜８回目に送信されるＳＣＩのリソース位置を決定し、追加で１回送信されるＳＣＩのリソース位置は、７回目又は８回目のいずれかのリソース位置とするようにしてもよい。また、ユーザ装置ＵＥは、どちらのリソース位置を選択するのかを、ＳＡ  ＩＤを用いて決定するようにしてもよい。例えば、ユーザ装置ＵＥは、ＳＡ  ＩＤの最後のビットが「０」である場合、最後の奇数回目のリソース位置を選択し、ＳＡ  ＩＤの最後のビットが「１」である場合、最後の偶数回目のリソース位置を選択するようにしてもよい。これにより、追加で１回送信されるＳＣＩのリソース位置は、ユーザ装置ＵＥ毎に分散されることになる。
【００５６】
以上、「ＳＣＩの繰り返し送信方法（その１）」について説明した。「ＳＣＩの繰り返し送信方法（その１）」によれば、複数のユーザ装置ＵＥ毎にＳＣＩが送信されるサブフレームを分散させることができるため、２つのユーザ装置ＵＥが同一のサブフレームでＳＣＩを送信してしまい、他方のユーザ装置ＵＥが送信するＳＣＩを受信できなくなるという問題（ハーフデュプレックス問題）が極力発生しないように制御することが可能になる。
【００５７】
＜ＳＣＩの繰り返し送信方法（その２）について＞
次に、ＳＣＩの繰り返し送信方法（その２）について説明する。以下、ユーザ装置ＵＥがＳＣＩを繰り返し送信する回数が２回の場合及び３回以上の場合に分けて説明する。なお、ユーザ装置ＵＥがＳＣＩを繰り返し送信する回数は、報知情報（ＳＩＢ）又はＲＲＣシグナリングにより基地局ｅＮＢからユーザ装置ＵＥに通知されてもよいし、ＳＩＭ又はコアネットワーク等を介してユーザ装置ＵＥに事前設定（Pre-Configured）されていてもよい。また、ユーザ装置ＵＥ毎に異なる回数が指定されてもよいし、セル毎又はＳＣＩリソースプール毎に異なる回数が指定されるようにしてもよい。
【００５８】
（ＳＣＩが２回繰り返し送信される場合）
ＳＣＩの繰り返し送信方法（その２）では、図１０に示すように、ＳＣＩリソースプールは、同一の間隔で繰り返し現れる２つの領域に分割される。１つ目の領域は、１回目のＳＣＩを送信するためのリソースプール（図１０の１回目のＳＣＩ送信用のリソースプール）に該当し、２つ目の領域は、２回目のＳＣＩを送信するためのリソースプール（図１０の２回目のＳＣＩ送信用のリソースプール）に該当する。ユーザ装置ＵＥは、１回目のＳＣＩを送信する場合、１回目のＳＣＩ送信用のリソースプールからリソースを選択して送信し、２回目のＳＣＩを送信する場合、２回目のＳＣＩ送信用のリソースプールからリソースを選択して送信する。
【００５９】
なお、図１０も図９Ａ−Ｂと同様に、ＳＣＩリソースプールを論理的に図示している。つまり、物理的な表現に置き換えると、図１０の「ｎｆ」方向のリソースは、順に、図８の上側及び下側のＳＣＩリソースプールに存在する４つのリソースに対応する。なお、図１０の「ｎｆ＝０」のリソースが、図８の周波数方向の一番上のリソース（図８の最上段のリソース）に対応していてもよいし、逆に、図１０の周波数方向の一番下のリソース（図８の最下段のリソース）に対応していてもよい。また、「ｎｔ」はサブフレームの位置を意味しており、「ｎｆ」は周波数方向のリソースブロックの位置を意味している。なお、「ｎｔ」は具体的なサブフレーム番号を意図しているのではなく、相対的なサブフレーム位置を示す変数である。同様に、「ｎｆ」も、相対的な周波数方向のリソースブロックの位置を示す変数である。
【００６０】
ＳＣＩの繰り返し送信方法（その２）では、２回目に送信されるリソースのリソース位置は、以下の数式５に従って決定されてもよい。なお、「Ｎｔ」は、１回目のＳＣＩ送信用のリソースプール及び２回目のＳＣＩ送信用のリソースプール内に存在するサブフレーム数を意味している。
（数式５）
【００６１】
【数５】
2017135126.tif 000007
ＳＣＩの繰り返し送信方法（その２）において、１回目のＳＣＩ送信用のリソースプールと２回目のＳＣＩ送信用のリソースプールの間隔は、報知情報（ＳＩＢ）又はＲＲＣシグナリングにより基地局ｅＮＢからユーザ装置ＵＥに通知されてもよいし、ＳＩＭ又はコアネットワーク等を介してユーザ装置ＵＥに事前設定（Pre-Configured）されていてもよい。
【００６２】
（ＳＣＩが３回以上繰り返し送信される場合）
続いて、ＳＣＩが３回以上繰り返し送信される場合のリソース決定方法について説明する。ＳＣＩが３回以上繰り返し送信される場合、図１１に示すように、ＳＣＩリソースプールを同一の間隔で繰り返し現れるＫ個の領域に分割しておき、ユーザ装置ＵＥは、１回目〜Ｋ回目のＳＣＩを送信する場合、それぞれ、１回目〜Ｋ回目のＳＣＩ送信用のリソースプールからリソースを選択して送信するようにしてもよい。また、ユーザ装置ＵＥは、選択するリソースを、前述の数式５を用いて決定するようにしてもよい。
【００６３】
また、他の方法として、ユーザ装置ＵＥは、所定のリソース決定方法に従って決定されるリソース選択方法を、「Ｋ／２」回繰り返すようにしてもよい。また、Ｋの数が奇数の場合、ユーザ装置ＵＥは、追加で１回送信するＳＣＩのリソース位置を、ＳＡ  ＩＤを用いて又はランダムに決定するようにしてもよい。例えば、ユーザ装置ＵＥは、ＳＡ  ＩＤの最後のビットが「０」である場合、所定のリソース決定方法で決定されるリソース位置のうち最初のリソース位置を選択し、ＳＡ  ＩＤの最後のビットが「１」である場合、所定のリソース決定方法で決定されるリソース位置のうち２番目のリソース位置を選択するようにしてもよい。これにより、追加で１回送信されるＳＣＩのリソース位置は、ユーザ装置ＵＥ毎に分散されることになる。
【００６４】
以上、「ＳＣＩの繰り返し送信方法（その２）」について説明した。「ＳＣＩの繰り返し送信方法（その２）」によれば、複数のユーザ装置ＵＥ毎にＳＣＩが送信されるサブフレームを分散させることができるため、２つのユーザ装置ＵＥが同一のサブフレームでＳＣＩを送信してしまい、他方のユーザ装置ＵＥが送信するＳＣＩを受信できなくなるという問題（ハーフデュプレックス問題）が極力発生しないように制御することが可能になる。
【００６５】
＜データの繰り返し送信方法について＞
次に、ユーザ装置ＵＥがデータを繰り返し送信する際に、各データを送信するリソースの位置を決定する方法について説明する。前述の通り、Ｄ２Ｄはハーフデュプレックスの通信方式を採用しているため、ユーザ装置ＵＥは、同一サブフレームにおいて、Ｄ２Ｄ信号の送受信を同時に行うことができない。そこで、本実施の形態では、ユーザ装置ＵＥは、繰り返し送信されるデータ間のサブフレーム間隔が、繰り返し送信されるＳＣＩ間のサブフレーム間隔の最大値より長い間隔になるように、データリソースプールの中からデータ送信用のリソースを選択してデータの送信を行う。
【００６６】
なお、本実施の形態では、データを繰り返し送信する回数は、予め標準仕様等で固定的に規定されていてもよいし、データを繰り返し送信する回数をＳＣＩの設定値に含めることでダイナミックに変更可能にしてもよい。
【００６７】
図１２は、データの繰り返し送信方法を説明するための図である。本実施の形態では、最後にＳＣＩが送信されるサブフレームと、当該ＳＣＩに対応するデータが最初に送信されるサブフレームとの間隔を示す所定のオフセット値を、「ｏｆｆｓｅｔ＿ｉｎｉ」と定義する。「ｏｆｆｓｅｔ＿ｉｎｉ」は、「１〜Ｔ＿ＳＡｍａｘ」の間の任意の値であり、送信側のユーザ装置ＵＥにより任意に決定される。ここで、Ｔ−ＳＡｍａｘは、前述の「ＳＣＩの繰り返し送信方法（その１）」に従う場合、「Ｔ−ＳＡｍａｘ＝ｆｌｏｏｒ（Ｎｆ／２）＋１」により算出される。また、前述の「ＳＣＩの繰り返し送信方法（その２）」に従う場合、「Ｔ−ＳＡｍａｘ＝１回目のＳＣＩを送信するためのリソースプール内のサブフレーム数＋２回目のＳＣＩを送信するためのリソースプール内のサブフレーム数」により算出される。
【００６８】
なお、「ｏｆｆｓｅｔ＿ｉｎｉ」は最初にＳＣＩが送信されるサブフレームとの時間オフセット値でもよい。また、「ｏｆｆｓｅｔ＿ｉｎｉ」として０を設定可能とすることで、ＳＣＩとデータの同一サブフレーム送信を設定可能としてもよい。
【００６９】
また、「ｏｆｆｓｅｔ＿ｉｎｉ」を用いず、ＳＣＩ内のフラグやＳＣＩのフォーマットで、ＳＣＩ及びデータが同一サブフレームで送信されていることを受信側のユーザ装置ＵＥが認識できるようにしてもよい。このような同一サブフレーム又は異なるサブフレームでのＳＣＩ及びデータの送信方法の切り替えは、送信側のユーザ装置ＵＥが自律的に選択してもよいし、ユーザ装置ＵＥの能力に応じて選択できる送信方法を限定してもよい。基地局ｅＮＢがリソースを割り当てる際に適切な送信方法を指示できるようそのユーザ装置ＵＥの能力を基地局ｅＮＢに報告してもよい。また、以下に述べるようにユーザ装置ＵＥは、送信電力に応じて送信方法を切り替えてもよい。
【００７０】
ＳＣＩとデータそれぞれの送信電力について、ＳＣＩとデータをそれぞれ異なるサブフレームで送信する場合は、設定された送信電力（例えば総送信電力や送信電力密度、Ｆｒａｃｔｉｏｎａｌ  ＴＰＣにおける目標受信電力と伝搬ロス補償項など）を用い、同一サブフレーム（サブフレームの一部が重なる場合を含む）で送信する場合は異なる送信電力設定を行なってもよい。例えば、ＳＣＩとデータの送信電力が２３ｄＢｍに設定されていた場合、同時送信でＳＣＩ送信を優先するとデータが送信できず、一方で電力密度を等分配するとＳＣＩの品質が十分担保できない可能性がある。独立した電力設定を行うことでこのような問題を回避することができる。
【００７１】
具体的には、同時送信により最大送信電力を超過する場合には、ユーザ装置ＵＥは次のいずれかまたはその組み合わせを用いて最大送信電力を満たすように送信電力を調整してもよいし、又は、同時送信を行わず異なるサブフレームでＳＣＩとデータを送信するようにしてもよい。（１）ＳＣＩとデータの間の送信電力オフセットを設定する。例えばＳＣＩがデータよりも送信電力（密度）が３ｄＢ高くなるように送信電力を制御する。（２）ＳＣＩ・データの最低送信電力（密度）を設定する（ＳＣＩのみに設定してもよい）。（３）データの最大送信帯域幅を設定する。
【００７２】
また、本実施の形態では、データが繰り返し送信される際のサブフレームの間隔を算出するために用いる所定のオフセット値を、「ｏｆｆｓｅｔ＿ｒｅ」と定義する。「ｏｆｆｓｅｔ＿ｒｅ」は、「０〜Ｔ＿ＳＡｍａｘ−１」の間の任意の数である。「ｏｆｆｓｅｔ＿ｒｅ」は、送信側のユーザ装置ＵＥにより任意に決定される。
【００７３】
図１２に示すように、ユーザ装置ＵＥは、ＳＣＩを最後に送信したサブフレームから「ｏｆｆｓｅｔ＿ｉｎｉ」後のサブフレームで最初のデータを送信する。またそれ以後、各データ間のサブフレーム間隔が「Ｔ＿ＳＡｍａｘ＋ｏｆｆｓｅｔ＿ｒｅ」になるようにデータを繰り返し送信する。なお、ユーザ装置ＵＥがｎ回目にデータを送信するサブフレーム位置は、「ｎ回目にデータが送信されるサブフレーム位置＝最後にＳＣＩが送信されるサブフレーム位置＋（ｎ−１）×（Ｔ−ＳＡ＿ｍａｘ＋ｏｆｆｓｅｔ＿ｒｅ）＋ｏｆｆｓｅｔ＿ｉｎｉ」の式で表現される。
【００７４】
図１２の例では、Ｎｆ＝６であるため、Ｔ−ＳＡ＿ｍａｘ＝４である。この場合、ユーザ装置ＵＥは、「ｏｆｆｓｅｔ＿ｉｎｉ」の値として、１〜６のうち任意の値を選択し、「ｏｆｆｓｅｔ＿ｒｅ」の値として、０〜５のうち任意の値を選択することになる。図１２の例では、「ｏｆｆｓｅｔ＿ｉｎｉ」及び「ｏｆｆｓｅｔ＿ｒｅ」の値としてそれぞれ「２」が選択された場合を図示している。
【００７５】
本実施の形態では、データが送信される周波数方向のリソース（リソースブロック）は、どのように選択されてもよい。例えば、繰り返し送信される各データの周波数方向のリソースは、ユーザ装置ＵＥにより任意に決定されるようにしてもよいし、基地局ｅＮＢからユーザ装置ＵＥに指示されるようにしてもよい。また、他の例として、例えば、１回目にデータが送信される際の周波数方向のリソースのみ、ユーザ装置ＵＥにより任意に決定（又は基地局ｅＮＢからユーザ装置ＵＥに指示）されるようにして、それ以後繰り返し送信されるデータについては、予め定められた所定のホッピングパターンに基づいて決定される周波数方向のリソースで送信されるようにしてもよい。当該所定のホッピングパターンは、どのようなパターンであってもよいが、例えば、従来のＬＴＥにおけるＰＳＳＣＨと同様、データが送信される周波数方向のリソース位置が、データリソースプール内に定義された複数のサブバンドで分散されるように設定されるホッピングパターンであってもよい。
【００７６】
以上、データの繰り返し送信方法について説明した。本実施の形態によれば、ＳＣＩが繰り返し送信されるサブフレーム間隔と、データが繰り返し送信されるサブフレーム間隔とがそれぞれ異なることになる。これにより、ＳＣＩを送信するユーザ装置ＵＥと、データを送信するユーザ装置ＵＥとが、同一のサブフレームでＤ２Ｄ信号を送信してしまい、他方のユーザ装置ＵＥが送信するＤ２Ｄ信号を受信できなくなるという問題（ハーフデュプレックス問題）が極力発生しないように制御することが可能になる。
【００７７】
＜ＳＣＩの設定値について＞
続いて、本実施の形態において、ＳＣＩに格納される設定値について具体的に説明する。ＳＣＩには、ＳＣＩに対応するデータが繰り返し送信される際のサブフレーム位置を算出するためのパラメータである「ｏｆｆｓｅｔ＿ｉｎｉ」及び「ｏｆｆｓｅｔ＿ｒｅ」の値が格納される。なお、「Ｔ＿ＳＡｍａｘ」の値はＳＣＩに格納されてもよいし格納されなくてもよい。「Ｔ＿ＳＡｍａｘ」は、ＳＣＩリソースプールの設定に基づき決定される「Ｎｆ」の値を用いることでユーザ装置ＵＥが自ら算出することが可能であるため、省略することができる。
【００７８】
また、ＳＣＩには、各データが送信される際の周波数方向のリソース位置を示す情報を含む。各データが送信される際の周波数方向のリソース位置を示す情報には、繰り返し回数分の全ての周波数方向のリソース位置が含まれていてもよいし、１回目にデータが送信される際の周波数方向のリソースと、所定のホッピングパターンを特定する情報とが格納されていてもよい。
【００７９】
「ｏｆｆｓｅｔ＿ｉｎｉ」及び「ｏｆｆｓｅｔ＿ｒｅ」の値は、従来のＤ２ＤにおけるＳＣＩのフォーマットのうち、Ｔ−ＲＰＴパターンビットを格納するための領域に格納されてもよい。本実施の形態では、従来のＤ２Ｄとはデータの送信方法が異なるため、Ｔ−ＲＰＴパターンビットを格納するための領域を流用することが可能である。また、「ｏｆｆｓｅｔ＿ｒｅ」の値は、ＳＣＩに格納されるＳＡ  ＩＤの最後の３又は４ビットに設定されるようにしてもよい。
【００８０】
なお、「ｏｆｆｓｅｔ＿ｒｅ」を所定の式に従って算出可能にすることで、「ｏｆｆｓｅｔ＿ｒｅ」をＳＣＩに格納しないようにしてもよい。例えば、「ｏｆｆｓｅｔ＿ｒｅ」の最大値を「ｍａｘ＿ｏｆｆｓｅｔ＿ｒｅ」とし、「ｏｆｆｓｅｔ＿ｒｅ＝ｍｏｄ（ｎｆ、ｍａｘ＿ｏｆｆｓｅｔ＿ｒｅ＋１）」の式により算出されるようにしてもよい。ここで、「ｎｆ」は、各データが送信される、データリソースプール内における周波数方向のリソースブロック位置を意味する。つまり、各データが送信される周波数方向のリソースが変化する場合、当該式が用いられることでデータの送信間隔が変化するように制御されることになる。「ｍａｘ＿ｏｆｆｓｅｔ＿ｒｅ」は、報知情報（ＳＩＢ）又はＲＲＣシグナリングにより基地局ｅＮＢからユーザ装置ＵＥに通知されてもよいし、ＳＩＭ又はコアネットワーク等を介してユーザ装置ＵＥに事前設定（Pre-Configured）されていてもよい。これにより、ＳＣＩのデータ量を削減することができる。
【００８１】
その他、ＳＣＩには、ＭＣＳ（Modulation and Coding Scheme）やＴＡ（Timing Alignment）を指定する情報が含まれていてもよい。また、本実施の形態のために新たなＳＣＩを規定してもよい。
【００８２】
基地局ｅＮＢからのリソース割り当てが行われる場合には、基地局ｅＮＢからユーザ装置ＵＥに送信されるリソース割り当て用のシグナリングに、ＳＣＩに格納される設定値及び所定のホッピングパターンを特定する情報などを含めるようにしてもよい。
【００８３】
また、前述の通り、ＳＣＩにはデータが繰り返し送信される回数が含まれていてもよい。
【００８４】
＜データの繰り返し送信方法に関する補足事項＞
前述したように、ＳＣＩには、最後にＳＣＩが送信されるサブフレームと、当該ＳＣＩに対応するデータが最初に送信されるサブフレームとの間隔を示す所定のオフセット値「ｏｆｆｓｅｔ＿ｉｎｉ」が格納される。しかしながら、受信側のユーザ装置ＵＥが、繰り返し送信されるＳＣＩのうち、最後に送信されるＳＣＩを必ず受信できるとは限らない。その場合、受信側のユーザ装置ＵＥは、受信したＳＣＩに対応するデータが最初に送信されるリソース位置を正しく認識できなくなる可能性がある。例えば、ＳＣＩが２回繰り返し送信される場合において、受信側のユーザ装置ＵＥが１回目に送信されるＳＣＩのみを受信した場合、受信側のユーザ装置ＵＥは、１回目に受信したＳＣＩのサブフレームを基準として、データが送信されるサブフレームの位置を特定してしまう可能性がある。
【００８５】
そこで、ＳＣＩの繰り返し送信方法（その１）に従ってＳＣＩが２回繰り返し送信される場合、受信側のユーザ装置ＵＥは、受信したＳＣＩの周波数方向のリソース位置に基づいて（つまり、図８の上側のＳＣＩリソースプール内のリソースなのか下側のＳＣＩリソースプール内のリソースなのかに基づいて）、受信したＳＣＩが１回目に送信されたＳＣＩなのか、２回目に送信されたＳＣＩなのかを判断するようにしてもよい。これにより、受信したＳＣＩが１回目に送信されたＳＣＩであると判断した場合、受信側のユーザ装置ＵＥは、前述した数式１又は数式２を用いて２回目に送信されるＳＣＩのサブフレーム位置を推定し、推定したサブフレーム位置を基準としてデータが送信されるサブフレームの位置を特定することが可能になる。
【００８６】
また、ＳＣＩの繰り返し送信方法（その１）に従ってＳＣＩが３回以上繰り返し送信される場合、ＳＣＩリソースプール内の周波数方向のリソースを、ＳＣＩを繰り返し送信する回数で分割し、繰り返し送信されるＳＣＩごとに、分割された周波数リソースを用いて送信してもよい。例えば、ＳＣＩリソースプール内の周波数方向のリソース（「Ｎｆ」の数）を、ＳＣＩを繰り返し送信する回数とすれば、周波数リソースをＳＣＩを繰り返し送信する回数で等分割することが可能になり、ＳＣＩの繰り返し送信ごとに等しい送信リソース候補数を確保することが可能になる。あるいは、繰り返し送信されるＳＣＩの間の時間方向のリソース間隔を予め準静的に固定してもよい。なお、繰り返し送信されるＳＣＩごとに、どの周波数方向のリソースでＳＣＩが送信されるのかを、送信側のユーザ装置ＵＥと受信側のユーザ装置ＵＥとの間で予め共有しておくようにする。これにより、受信側のユーザ装置ＵＥは、受信したＳＣＩの周波数方向のリソース位置に基づいて、受信したＳＣＩが何回目に送信されたＳＣＩなのかを判断することができる。また、ユーザ装置ＵＥは、当該判断結果に基づいて最後に送信されるＳＣＩのサブフレーム位置を推定し、推定したサブフレーム位置を基準としてデータが送信されるサブフレームの位置を特定することが可能になる。
【００８７】
なお、繰り返し送信されるＳＣＩと、周波数方向のリソースとの対応付けの例として、例えば、１回目に送信されるＳＣＩは図８の最上段のリソースで送信されるようにして、２回目に送信されるＳＣＩは図８の最下段のリソースで送信されるようにして、３回目に送信されるＳＣＩは図８の最上段の１つ下のリソースで送信されるようにして、４回目に送信されるＳＣＩは図８の最下段の１つ上のリソースで送信されるようにしてもよい。
【００８８】
また、ＳＣＩの繰り返し送信方法（その２）に従ってＳＣＩが繰り返し送信される場合、送信回数ごとのＳＣＩ送信用のリソースプール（図１１の例では、１回目〜Ｋ回目のＳＣＩ送信用リソースプールの各々）の開始地点及び終了地点のそれぞれの時間リソースの絶対位置（例えばＤＦＮ及びサブフレーム）を特定するための情報（計算式等）を、予め報知情報（ＳＩＢ）又はＲＲＣシグナリングにより基地局ｅＮＢからユーザ装置ＵＥに通知しておくようにしてもよいし、ＳＩＭ又はコアネットワーク等を介してユーザ装置ＵＥに事前設定（Pre-Configured）しておくようにしてもよい。これにより、受信側のユーザ装置ＵＥは、受信したＳＣＩのＤＦＮ及びサブフレーム番号が、何回目のＳＣＩ送信用のリソースプールに該当するかを特定することで、受信したＳＣＩが何回目に送信されたＳＣＩなのかを判断することができる。また、ユーザ装置ＵＥは、例えば、前述した数式５を用いて最後に送信されるＳＣＩのサブフレーム位置を推定し、推定したサブフレーム位置を基準としてデータが送信されるサブフレームの位置を特定することが可能になる。
【００８９】
また、他の方法として、送信側のユーザ装置ＵＥは、ＳＣＩの中に送信回数を示す情報を含めるようにしてもよい。これにより、受信側のユーザ装置ＵＥは、受信したＳＣＩが何回目に送信されたＳＣＩなのかを容易に特定することができる。
【００９０】
また、他の方法として、「ｏｆｆｓｅｔ＿ｉｎｉ」の値を、実際にＳＣＩが送信されるサブフレームと、当該ＳＣＩに対応するデータが最初に送信されるサブフレームとの間隔を示すもようにしてもよい。つまり、「ｏｆｆｓｅｔ＿ｉｎｉ」の値をＳＣＩの送信回数に合わせて変化させるようにしてもよい。これにより、受信側のユーザ装置ＵＥは、受信したＳＣＩが何回目なのかを特定せずに、データが最初に送信されるサブフレームを把握することができる。なお、「ｏｆｆｓｅｔ＿ｉｎｉ」の値をデータが最初に送信される時間リソースの絶対位置（ＤＦＮ及びサブフレーム番号）とするようにしてもよい。
【００９１】
＜ＳＣＩ及びデータの衝突回避について＞
Ｖ２Ｘでは、多数のユーザ装置ＵＥが同一のリソースプール内でＤ２Ｄ信号を送信するシナリオが想定されている。そのため、複数のユーザ装置ＵＥが同一のリソースを選択してＳＣＩ／データの送信を行ってしまい、ＳＣＩ／データの衝突が発生してしまう可能性がある。一方で、Ｖ２Ｘでは、例えば、１００ｍｓ毎にＶ２Ｘパケットを送信するような運用形態が想定されているため、ユーザ装置ＵＥは、将来的に送信予定のデータをある程度予測することが可能であると想定される。
【００９２】
そこで、本実施の形態では、複数のユーザ装置ＵＥから送信されるＳＣＩ／データの衝突を回避するため、ユーザ装置ＵＥは、ＳＣＩの中に、新たなＳＣＩ／データを送信予定のリソースの位置を示す識別子を含めることで、当該リソースで新たなＳＣＩ／データを送信予定である（当該リソースを予約する）ことを他のユーザ装置ＵＥに通知するようにしてもよい。
【００９３】
＜ＳＣＩ送信用リソースの予約方法について＞
図１３は、ＳＣＩ送信用リソースの予約方法を説明するための図である。ユーザ装置ＵＥは、所定の時間後（所定のサブフレーム後）にデータ（Ｖ２Ｘパケット）を送信するために新たなＳＣＩの送信を予定している場合、所定の時間後（所定のサブフレーム後）に新たなＳＣＩを送信するためのリソースを予約することを示す識別子（以下、「ＳＣＩ予約識別子」と呼ぶ）をＳＣＩに含めて送信する。
【００９４】
ＳＣＩ予約識別子には、直近で送信予定のＳＣＩ（ＳＣＩ予約識別子が含まれるＳＣＩ）と、所定の時間後に送信予定の新たなＳＣＩとの間の送信間隔（例えば、１００ｍｓなど）が具体的に設定されてもよいし、送信間隔を所定の単位数（例えば、１単位あたり１００ｍｓ）で表現するためのビット値（例えば２ビットの値）が設定されるようにしてもよい。後者の場合、例えば、「００」は、リソースの予約がされていないことを意味し、「０１」は送信間隔が１単位（例えば、１００ｍｓ）であることを意味し、「１０」は送信間隔が２単位（例えば、２００ｍｓ）であることを意味し、「１１」は送信間隔が４単位（例えば、４００ｍｓ）であることを意味するようにしてもよい。また、所定の１単位が意味する送信間隔は、報知情報（ＳＩＢ）又はＲＲＣシグナリングにより基地局ｅＮＢからユーザ装置ＵＥに通知されてもよいし、ＳＩＭ又はコアネットワーク等を介してユーザ装置ＵＥに事前設定（Pre-Configured）されていてもよい。
【００９５】
図１３の例は、新たなＳＣＩを送信予定のリソースとして、１００ｍｓ後のリソースが予約された場合を示している。なお、前述の通り、本実施の形態では同一のＳＣＩが複数回繰り返し送信される。そのため、ＳＣＩ予約識別子が含まれるＳＣＩを受信したユーザ装置ＵＥは、ＳＣＩ予約識別子により指定されるリソースにおいて、ＳＣＩ予約識別子を含むＳＣＩと同様の送信間隔及び周波数方向のリソース位置で新たなＳＣＩが繰り返し送信されると認識するように動作する。つまり、図１３の例に示すように、ＳＣＩ予約識別子を含むＳＣＩが２回繰り返し送信される場合、ユーザ装置ＵＥは、１００ｍｓ後において、新たなＳＣＩも、ＳＣＩ予約識別子を含むＳＣＩと同様の送信間隔及び周波数方向のリソース位置で２回繰り返し送信されると認識するように動作する。
【００９６】
＜データ送信用リソースの予約方法について＞
図１４は、データ送信用リソースの予約方法を説明するための図である。ユーザ装置ＵＥは、所定の時間後（所定のサブフレーム後）に新たなデータ（Ｖ２Ｘパケット）を送信することを予定している場合、所定の時間後（所定のサブフレーム後）に新たなデータを送信するためのリソースを予約することを示す識別子（以下、「データ予約識別子」と呼ぶ）をＳＣＩに含めて送信する。
【００９７】
データ予約識別子には、ＳＣＩ予約識別子で示される所定の時間後に、新たなデータを送信するためのリソースの予約がされているのか否かを示す情報が格納される。つまり、ユーザ装置ＵＥは、データを送信するリソースを予約する場合、ＳＣＩに、ＳＣＩ予約識別子及びデータ予約識別子の両方を含める必要がある。当該情報は、例えば１ビットで表現されてもよい。より具体的には、「０」は、リソースの予約がされていないことを意味し、「１」は、ＳＣＩ予約識別子で示される所定の時間後にリソース予約されていることを意味するようにしてもよい。
【００９８】
図１４の例は、新たなデータを送信予定のリソースとして、１００ｍｓ後のリソースが予約された場合を示している。なお、前述の通り、本実施の形態では同一のデータが複数回繰り返し送信される。そのため、データ予約識別子を含むＳＣＩを受信したユーザ装置ＵＥは、ＳＣＩ予約識別子で示される所定の時間後のリソースにおいて、当該ＳＣＩに対応するデータと同一の送信間隔及び周波数方向のリソースで新たなデータが繰り返し送信されると認識するように動作する。つまり、図１４の例に示すように、データ予約識別子を含むＳＣＩに対応するデータ（図１４の左側のデータ）が４回繰り返し送信される場合、ユーザ装置ＵＥは、１００ｍｓ後において、新たなデータ（図１４の右側のデータ）も、データ予約識別子を含むＳＣＩに対応するデータ（図１４の左側のデータ）と同様の送信間隔及び周波数方向のリソース位置で４回繰り返し送信されると認識するように動作する。
【００９９】
＜ＳＣＩ及びデータ送信用リソースの予約を用いた運用例について＞
図１５は、ＳＡ及びデータを送信するためのリソースの予約方法の具体例（その１）を示す図である。なお、図１５には、ユーザ装置ＵＥが１９０バイト又は３００バイトのＶ２Ｘパケットを１００ｍｓ間隔で送信する様子が示されているが、より詳細には、１つのＶ２Ｘパケットの送信が行われる度に、複数の同一のＳＣＩと複数の同一のデータ（１つのＶ２Ｘパケットが格納されたＭＡＣ  ＰＤＵ）が繰り返し送信される動作が行われる。言い換えると、図１５に示す１つのＶ２Ｘパケットの送信は、より詳細には、図１２に示す一連のＳＣＩ／データの送信が１回行われることに対応する。
【０１００】
ここで、ユーザ装置ＵＥは、１００ｍｓ間隔で、１９０バイト又は３００バイトのＶ２Ｘパケットを送信予定であると仮定する。ユーザ装置ＵＥは、直近で送信予定のデータサイズと、１００ｍｓに送信予定のデータサイズとが同一である場合、ＳＣＩ予約識別子及びデータ予約識別子の両方を、直近で送信予定のＳＣＩに含めて送信する。図１５の例では、直近で送信予定のデータサイズ及び１００ｍｓ後に送信予定のデータサイズが１９０バイトである場合、ユーザ装置ＵＥは、ＳＣＩ予約識別子に１００ｍｓを示すビット値を設定し、データ予約識別子にデータ予約を行うことを示すビット（「１」）を設定してＳＣＩを送信することが示されている。
【０１０１】
一方、ユーザ装置ＵＥは、直近で送信予定のデータサイズと、１００ｍｓに送信予定のデータサイズとが異なる場合、ＳＣＩ予約識別子のみを直近で送信予定のＳＣＩに含めて送信する。また、ユーザ装置ＵＥは、１００ｍｓに送信するＳＣＩを用いて、データ送信用のリソースを割当てる（つまり、データ送信用のリソースを予約せずに、データを送信する時点でリソースを割当てる）。本実施の形態では、予約されるデータ送信用のリソースは、直近で送信予定のデータと同一サイズ（例えば同一のリソースブロックペア数）のリソースになるため、１００ｍｓ後に送信予定のデータサイズが異なる場合、予約されたリソースサイズでは送信予定のデータを格納できない可能性があるためである。図１５の例では、直近で送信予定のデータサイズ及び１００ｍｓ後に送信予定のデータサイズがそれぞれ１９０バイト及び３００バイト（若しくは、３００バイト及び１９０バイト）である場合、ユーザ装置ＵＥは、ＳＣＩ予約識別子に１００ｍｓを示すビット値と、データ予約識別子にデータ予約を行わないことを示すビット（「０」）を格納してＳＣＩを送信することが示されている。
【０１０２】
なお、ユーザ装置ＵＥの物理レイヤは、次のタイミングで送信予定のＶ２Ｘパケットのサイズが、直近で送信予定のＶ２Ｘパケットのサイズと同一であるか否かを、ユーザ装置ＵＥの上位レイヤ（例えば、レイヤ２、アプリケーションレイヤ等）からの通知により把握するようにしてもよい。同様に、ユーザ装置ＵＥの物理レイヤは、直近で送信予定のＶ２Ｘパケットと次のタイミングで送信予定のＶ２Ｘパケットとの間の送信間隔を、ユーザ装置ＵＥの上位レイヤ（例えば、レイヤ２、アプリケーションレイヤ等）からの通知により把握するようにしてもよい。これにより、ユーザ装置ＵＥの物理レイヤは、直近で送信するＳＣＩを生成する処理において、ＳＣＩ予約識別子に設定すべき値及びデータ予約識別子に設定すべき値を、上位レイヤからの通知に基づいて決定することが可能になる。
【０１０３】
＜データ送信用リソースの予約方法及び運用例の変形例について＞
データ送信用リソースの予約方法の変形例として、データ予約識別子には、リソースの予約がされているのかに加えて、時間方向及び周波数方向の両方のリソースを予約するのか又は時間方向のリソース（つまり、サブフレーム）のみを予約するのかを示す情報（例えば２ビット）が設定されるようにしてもよい。例えば、「００」は、リソースの予約がされていないことを意味し、「０１」は、時間方向及び周波数方向の両方のリソースを予約することを意味し、「１０」は、時間方向のリソースのみを予約することを意味するようにしてもよい。
【０１０４】
図１６は、ＳＡ及びデータを送信するためのリソースの予約方法の具体例（その２）を示す図である。なお、特に言及しない点は図１５と同一でよい。
【０１０５】
ユーザ装置ＵＥは、直近で送信予定のデータサイズと、１００ｍｓに送信予定のデータサイズとが同一である場合、時間方向及び周波数方向の両方のリソースを予約することを示すデータ予約識別子を、直近で送信予定のＳＣＩに含めて送信する。図１６の例では、直近で送信予定のデータサイズ及び１００ｍｓ後に送信予定のデータサイズが１９０バイトである場合、ユーザ装置ＵＥは、ＳＣＩ予約識別子に１００ｍｓを示すビット値と、データ予約識別子に時間方向及び周波数方向の両方のリソースを予約することを示すビット（「０１」）を格納してＳＣＩを送信することが示されている。
【０１０６】
一方、ユーザ装置ＵＥは、直近で送信予定のデータサイズと、１００ｍｓに送信予定のデータサイズとが異なる場合、ＳＣＩ予約識別子と時間方向のリソースのみを予約することを示すデータ予約識別子とを、直近で送信予定のＳＣＩに含めて送信すると共に、１００ｍｓに送信するＳＣＩを用いて、データ送信用の周波数方向のリソースを割当てるようにしてもよい。図１６の例では、直近で送信予定のデータサイズ及び１００ｍｓ後に送信予定のデータサイズがそれぞれ１９０バイト及び３００バイト（若しくは、３００バイト及び１９０バイト）である場合、ユーザ装置ＵＥは、ＳＣＩ予約識別子に１００ｍｓを示すビット値と、データ予約識別子に時間方向のリソースのみを予約することを示すビット（「１０」）を格納してＳＣＩを送信することが示されている。
【０１０７】
これにより、ユーザ装置ＵＥは、直近で送信予定のデータサイズと、その次に送信予定のデータサイズとが異なる場合であっても、所定の時間後のサブフレームのいずれかの周波数リソースでＤ２Ｄ信号の送信を行う予定であることを、他のユーザ装置ＵＥに通知することが可能になる。
【０１０８】
＜ＳＣＩ／データを送信予定のユーザ装置の動作について＞
ＳＣＩ予約識別子で指定可能な最大の期間が４００ｍｓである場合、現時点から４００ｍｓ後までの間は、既に他のユーザ装置ＵＥがＳＣＩ（又はＳＣＩ及びデータ）を送信するリソースを予約している可能性がある。そこで、ユーザ装置ＵＥは、ＳＣＩを送信する前に、ＳＣＩ予約識別子で指定可能な最大の期間（ＳＣＩの送信が予約されている可能性のある期間）の間で他のユーザ装置ＵＥが送信するＳＣＩをモニタし、当該期間後のリソースの中から予約されていないリソースを選択してＳＣＩ（又はＳＣＩ及びデータ）の送信を開始するようにしてもよい。これにより、ユーザ装置ＵＥが、既に予約されているリソースを用いてＳＣＩ（又はＳＣＩ及びデータ）を送信してしまうことを回避することができる。
【０１０９】
また、他の方法として、ユーザ装置ＵＥは、一旦ＳＣＩを送信しつつ、自身がＳＣＩを送信するサブフレーム以外のサブフレームで他のユーザ装置ＵＥがＳＣＩを送信しているか否かをモニタし、他のユーザ装置ＵＥからのＳＣＩを検出した場合は、衝突を回避するためにそれ以後ＳＣＩの送信を中止するようにしてもよい。
【０１１０】
また、ユーザ装置ＵＥは、ＳＣＩ予約識別子で指定可能な最大の期間（ＳＣＩの送信が予約されている可能性のある期間）で他のユーザ装置ＵＥが送信するＳＣＩをモニタした結果、ＳＣＩの送信が予約されていることを検出した場合（ＳＣＩ予約識別子を含むＳＣＩを検出した場合）、予約されていないリソースを選択してＳＣＩを送信するのではなく、ＳＣＩの送信自体を中止するようにしてもよい。
【０１１１】
また、ユーザ装置ＵＥは、ＳＣＩ予約識別子で指定可能な最大の期間（ＳＣＩの送信が予約されている可能性のある期間）で他のユーザ装置ＵＥが送信するＳＣＩをモニタした結果、ＳＣＩ及びデータの送信が予約されていることを検出した場合（ＳＣＩ予約識別子及びデータ予約識別子を含むＳＣＩを検出した場合）、予約されていないリソースを選択してＳＣＩ予約識別子のみを含むＳＣＩを送信することで他のユーザ装置ＵＥにリソースを予約したことを通知し、ＳＣＩ予約識別子で予約したリソースを用いてＳＣＩを及びデータの送信を行うようにしてもよい。より確実にＳＣＩ／データの衝突を回避することが可能になる。
【０１１２】
＜＜機能構成＞＞
以上説明した複数の実施の形態の動作を実行するユーザ装置ＵＥ及び基地局ｅＮＢの機能構成例を説明する。
【０１１３】
（ユーザ装置）
図１７は、実施の形態に係るユーザ装置の機能構成の一例を示す図である。図１７に示すように、ユーザ装置ＵＥは、信号送信部１０１と、信号受信部１０２と、選択部１０３とを有する。なお、図１７は、ユーザ装置ＵＥにおいて本発明の実施の形態に特に関連する機能部のみを示すものであり、少なくともＬＴＥに準拠した動作を行うための図示しない機能も有するものである。また、図１７に示す機能構成は一例に過ぎない。本実施の形態に係る動作を実行できるのであれば、機能区分や機能部の名称はどのようなものでもよい。
【０１１４】
信号送信部１０１は、ユーザ装置ＵＥから送信されるべき上位のレイヤの信号から、物理レイヤの各種信号を生成し、無線送信する機能を含む。また、信号送信部１０１は、Ｄ２Ｄ信号の送信機能とセルラ通信の送信機能を有する。また、信号送信部１０１は、Ｄ２Ｄ信号を、選択部１０３で選択されたリソースを用いて送信する機能を有する。また、信号送信部１０１は、ＳＣＩに、ＳＣＩ予約識別子（又は、ＳＣＩ予約識別子とデータ予約識別子）を含めて送信するようにしてもよい。
【０１１５】
信号受信部１０２は、他のユーザ装置ＵＥ又は基地局ｅＮＢから各種の信号を無線受信し、受信した物理レイヤの信号からより上位のレイヤの信号を取得する機能を含む。また、信号受信部１０２は、Ｄ２Ｄ信号の受信機能とセルラ通信の受信機能を有する。
【０１１６】
選択部１０３は、ＳＣＩリソースプールから制御情報（ＳＣＩ）を送信するための第一の制御情報用リソースを選択し、データリソースプールからデータを送信するための第一のデータ用リソースを選択する機能を有する。より具体的には、選択部１０３は、ＳＣＩリソースプールとデータリソースプールとが時間方向に制約なく連続して設定される無線リソースにおいて、ＳＣＩリソースプールから制御情報（ＳＣＩ）を送信するための第一の制御情報用リソースを選択し、データリソースプールからデータを送信するための第一のデータ用リソースを選択する機能を有する。
【０１１７】
また、選択部１０３は、ＳＣＩリソースプールが、データリソースプールの周波数帯域よりも上の周波数帯域に設定される第一のＳＣＩリソースプール（図７の上側のＳＣＩリソースプール）と、データリソースプールの周波数帯域よりも下の周波数帯域に設定される第二のＳＣＩリソースプール（図７の下側のＳＣＩリソースプール）とに分けられる場合に、第一の制御情報用リソースを、第一のＳＣＩリソースプール又は第二のデータリソースプールから選択すると共に、第一の制御情報用リソースを第一のＳＣＩリソースプールから選択した場合は、第一の制御情報用のリソースのサブフレームより後のサブフレームで、第二のＳＣＩリソースプールから第二の制御情報用リソースを選択し、第一の制御情報用リソースを第二のＳＣＩリソースプールから選択した場合は、第一の制御情報用のリソースのサブフレームより後のサブフレームで、第一のＳＣＩリソースプールから第二の制御情報用リソースを選択するようにしてもよい。
【０１１８】
また、選択部１０３は、第二の制御情報用リソースが選択されるサブフレームを、第一の制御情報用リソースの周波数方向のリソース位置に基づき決定されるようにしてもよい。また、選択部１０３は、第二の制御情報用リソースが、第一のＳＣＩリソースプール及び第二のＳＣＩリソースプールに繰り返し設定される時間領域（図１０の１回目のＳＣＩ送信用のリソースプール及び２回目のＳＣＩ送信用のリソースプール）のうち、第一の制御情報用リソースが含まれる時間領域とは異なる時間領域に含まれるようにしてもよい。
【０１１９】
また、選択部１０３は、第一のデータ用リソースのサブフレームより後のサブフレームで、データリソースプールから第二のデータ用リソースを選択するようにしてもよい。また、選択部１０３は、第一のデータ用リソースが選択されるサブフレームと、第二のデータ用リソースが選択されるサブフレームの間隔が、第一の制御情報用のリソースが選択されるサブフレームと、第二の制御情報用のリソースが選択されるサブフレームとの間のサブフレーム間隔よりも広くなるように、第二のデータ用リソースを選択するようにしてもよい。
【０１２０】
（基地局）
図１８は、実施の形態に係る基地局の機能構成の一例を示す図である。図１８に示すように、基地局ｅＮＢは、信号送信部２０１と、信号受信部２０２と、通知部２０３とを有する。なお、図１８は、基地局ｅＮＢにおいて本発明の実施の形態に特に関連する機能部のみを示すものであり、少なくともＬＴＥに準拠した動作を行うための図示しない機能も有するものである。また、図１８に示す機能構成は一例に過ぎない。本実施の形態に係る動作を実行できるのであれば、機能区分や機能部の名称はどのようなものでもよい。
【０１２１】
信号送信部２０１は、基地局ｅＮＢから送信されるべき上位のレイヤの信号から、物理レイヤの各種信号を生成し、無線送信する機能を含む。信号受信部２０２は、ユーザ装置ＵＥから各種の信号を無線受信し、受信した物理レイヤの信号からより上位のレイヤの信号を取得する機能を含む。
【０１２２】
通知部２０３は、ユーザ装置ＵＥが本実施の形態に係る動作を行うために用いる各種情報（ＳＣＩリソースプール及びデータリソースプールの設定、ユーザ装置ＵＥがＳＣＩを繰り返し送信する回数、ＳＣＩの繰り返し送信方法（その２）において、１回目のＳＣＩ送信用のリソースプールと２回目のＳＣＩ送信用のリソースプールの間隔、「ｍａｘ＿ｏｆｆｓｅｔ＿ｒｅ」、所定の１単位が意味する送信間隔など）を、報知情報（ＳＩＢ）又はＲＲＣシグナリングを用いてユーザ装置ＵＥに通知する。
【０１２３】
以上説明した基地局ｅＮＢ及びユーザ装置ＵＥの機能構成は、全体をハードウェア回路（例えば、１つ又は複数のＩＣチップ）で実現してもよいし、一部をハードウェア回路で構成し、その他の部分をＣＰＵとプログラムとで実現してもよい。
【０１２４】
（ユーザ装置）
図１９は、実施の形態に係るユーザ装置のハードウェア構成の一例を示す図である。図１９は、図１７よりも実装例に近い構成を示している。図１９に示すように、ユーザ装置ＵＥは、無線信号に関する処理を行うＲＦ（Radio Frequency）モジュール３０１と、ベースバンド信号処理を行うＢＢ（Base Band）処理モジュール３０２と、上位レイヤ等の処理を行うＵＥ制御モジュール３０３とを有する。
【０１２５】
ＲＦモジュール３０１は、ＢＢ処理モジュール３０２から受信したデジタルベースバンド信号に対して、Ｄ／Ａ（Digital-to-Analog）変換、変調、周波数変換、及び電力増幅等を行うことでアンテナから送信すべき無線信号を生成する。また、受信した無線信号に対して、周波数変換、Ａ／Ｄ（Analog to Digital）変換、復調等を行うことでデジタルベースバンド信号を生成し、ＢＢ処理モジュール３０２に渡す。ＲＦモジュール３０１は、例えば、図１７の信号送信部１０１及び信号受信部１０２の一部を含む。
【０１２６】
ＢＢ処理モジュール３０２は、ＩＰパケットとデジタルベースバンド信号とを相互に変換する処理を行う。ＤＳＰ（Digital Signal Processor）３１２は、ＢＢ処理モジュール３０２における信号処理を行うプロセッサである。メモリ３２２は、ＤＳＰ３１２のワークエリアとして使用される。ＲＦモジュール３０１は、例えば、図１７の信号送信部１０１の一部、信号受信部１０２の一部及び選択部１０３を含む。
【０１２７】
ＵＥ制御モジュール３０３は、ＩＰレイヤのプロトコル処理、各種アプリケーションの処理等を行う。プロセッサ３１３は、ＵＥ制御モジュール３０３が行う処理を行うプロセッサである。メモリ３２３は、プロセッサ３１３のワークエリアとして使用される。
【０１２８】
（基地局）
図２０は、実施の形態に係る基地局のハードウェア構成の一例を示す図である。図２０は、図１８よりも実装例に近い構成を示している。図２０に示すように、基地局ｅＮＢは、無線信号に関する処理を行うＲＦモジュール４０１と、ベースバンド信号処理を行うＢＢ処理モジュール４０２と、上位レイヤ等の処理を行う装置制御モジュール４０３と、ネットワークと接続するためのインタフェースである通信ＩＦ４０４とを有する。
【０１２９】
ＲＦモジュール４０１は、ＢＢ処理モジュール４０２から受信したデジタルベースバンド信号に対して、Ｄ／Ａ変換、変調、周波数変換、及び電力増幅等を行うことでアンテナから送信すべき無線信号を生成する。また、受信した無線信号に対して、周波数変換、Ａ／Ｄ変換、復調等を行うことでデジタルベースバンド信号を生成し、ＢＢ処理モジュール４０２に渡す。ＲＦモジュール４０１は、例えば、図１８に示す信号送信部２０１及び信号受信部２０２の一部を含む。
【０１３０】
ＢＢ処理モジュール４０２は、ＩＰパケットとデジタルベースバンド信号とを相互に変換する処理を行う。ＤＳＰ４１２は、ＢＢ処理モジュール４０２における信号処理を行うプロセッサである。メモリ４２２は、ＤＳＰ４１２のワークエリアとして使用される。ＢＢ処理モジュール４０２は、例えば、図１８に示す信号送信部２０１の一部、信号受信部２０２の一部及び通知部２０３の一部を含む。
【０１３１】
装置制御モジュール４０３は、ＩＰレイヤのプロトコル処理、ＯＡＭ（Operation and Maintenance）処理等を行う。プロセッサ４１３は、装置制御モジュール４０３が行う処理を行うプロセッサである。メモリ４２３は、プロセッサ４１３のワークエリアとして使用される。補助記憶装置４３３は、例えばＨＤＤ等であり、基地局ｅＮＢ自身が動作するための各種設定情報等が格納される。装置制御モジュール４０３は、例えば、図１８に示す通知部２０３の一部を含む。
【０１３２】
＜＜まとめ＞＞
以上、実施の形態によれば、Ｄ２Ｄ通信をサポートする無線通信システムにおけるユーザ装置であって、制御情報用のリソースプールとデータ送信用のリソースプールとが時間方向に制約なく連続して設定される無線リソースにおいて、前記制御情報用のリソースプールから制御情報を送信するための第一の制御情報用リソースを選択し、前記データ送信用のリソースプールからデータを送信するための第一のデータ用リソースを選択する選択部と、前記第一のデータ用リソースを指定する情報を含む制御情報を前記第一の制御情報用リソースで送信し、前記第一のデータ用リソースを用いてデータを送信する送信部と、を有するユーザ装置が提供される。このユーザ装置ＵＥにより、より柔軟なＤ２Ｄ通信を行うことが可能な技術が提供される。
【０１３３】
また、前記制御情報用のリソースプールは、前記データ送信用のリソースプールの周波数帯域よりも上の周波数帯域に設定される第一のリソースプールと、前記データ送信用のリソースプールの周波数帯域よりも下の周波数帯域に設定される第二のリソースプールとに分けられ、前記選択部は、前記第一の制御情報用リソースを、前記第一のリソースプール又は前記第二のリソースプールから選択すると共に、前記第一の制御情報用リソースを前記第一のリソースプールから選択した場合は、前記第一の制御情報用リソースのサブフレームより後のサブフレームで、前記第二のリソースプールから第二の制御情報用リソースを選択し、前記第一の制御情報用リソースを前記第二のリソースプールから選択した場合は、前記第一の制御情報用リソースのサブフレームより後のサブフレームで、前記第一のリソースプールから第二の制御情報用リソースを選択し、前記送信部は、前記第一のデータ用リソースを指定する情報を含む制御情報を、前記第一の制御情報用リソースと前記第二の制御情報用リソースとで送信するようにしてもよい。これにより、データリソースプールの帯域の上下に設定されるＳＣＩリソースプールを用いてＳＣＩの周波数ホッピングを実現することが可能になり、特定の周波数（サブキャリア等）における伝搬品質が劣化した場合であっても、ＳＣＩの受信品質を向上させることが可能になる。
【０１３４】
また、前記第二の制御情報用リソースが選択されるサブフレームは、前記第一の制御情報用リソースの周波数方向のリソース位置に基づき決定されるようにしてもよい。これにより、２つのユーザ装置ＵＥが同一のサブフレームでＳＣＩを送信してしまい、他方のユーザ装置ＵＥが送信するＳＣＩを受信できなくなるという問題（ハーフデュプレックス問題）が極力発生しないように制御することが可能になる。
【０１３５】
また、前記第二の制御情報用リソースは、前記第一のリソースプール及び前記第二のリソースプールに繰り返し設定される時間領域のうち、前記第一の制御情報用リソースが含まれる時間領域とは異なる時間領域に含まれるようにしてもよい。これにより、リソースプール構成に基づいたＳＣＩの繰り返し送信を実現することが可能になる。
【０１３６】
また、前記選択部は、前記第一のデータ用リソースのサブフレームより後のサブフレームで、前記データ送信用のリソースプールから第二のデータ用リソースを選択し、前記送信部は、前記第一のデータ用リソースと前記第二のデータ用リソースとを用いてデータを送信するようにしてもよい。これにより、同一のデータを繰り返し送信することが可能になり、データ（ＭＡＣ  ＰＤＵ）の受信品質を向上させることが可能になる。
【０１３７】
また、前記選択部は、前記第一のデータ用リソースが選択されるサブフレームと、前記第二のデータ用リソースが選択されるサブフレームの間隔が、前記第一の制御情報用リソースが選択されるサブフレームと、前記第二の制御情報用リソースが選択されるサブフレームとの間のサブフレーム間隔よりも広くなるように、前記第二のデータ用リソースを選択するようにしてもよい。これにより、ＳＣＩを送信するユーザ装置ＵＥと、データを送信するユーザ装置ＵＥとが、同一のサブフレームでＤ２Ｄ信号を送信してしまい、他方のユーザ装置ＵＥが送信するＤ２Ｄ信号を受信できなくなるという問題（ハーフデュプレックス問題）が極力発生しないように制御することが可能になる。
【０１３８】
また、前記制御情報は、前記制御情報用のリソースプールにおいて、前記第一の制御情報用リソースが選択されるサブフレームより所定のサブフレーム後のサブフレームで、前記制御情報とは異なる他の制御情報を送信するための制御情報の送信用のリソースを予約することを示す予約情報を含むようにしてもよい。これにより、ユーザ装置ＵＥは、他のユーザ装置ＵＥに対して、所定のタイミングにＳＣＩを送信予定であることを通知することができ、自身が送信するＳＣＩと他のユーザ装置ＵＥから送信されるＳＣＩとの衝突を回避することができる。
【０１３９】
また、前記制御情報は、前記データ送信用のリソースプールにおいて、前記第一のデータ用リソースが選択されるサブフレームより前記所定のサブフレーム後のサブフレームで、前記データとは異なる他のデータを送信するためのデータ送信用のリソースを予約することを示す予約情報を含むようにしてもよい。これにより、ユーザ装置ＵＥは、他のユーザ装置ＵＥに対して、所定のタイミングにデータを送信予定であることを通知することができ、自身が送信するデータと他のユーザ装置ＵＥから送信されるデータとの衝突を回避することができる。
【０１４０】
また、実施の形態によれば、Ｄ２Ｄ通信をサポートする無線通信システムにおけるユーザ装置が実行する送信方法であって、制御情報用のリソースプールとデータ送信用のリソースプールとが時間方向に制約なく連続して設定される無線リソースにおいて、前記制御情報用のリソースプールから制御情報を送信するための第一の制御情報用リソースを選択し、前記データ送信用のリソースプールからデータを送信するための第一のデータ用リソースを選択するステップと、前記第一のデータ用リソースを指定する情報を含む制御情報を前記第一の制御情報用リソースで送信し、前記第一のデータ用リソースを用いてデータを送信するステップと、を有する送信方法が提供される。この送信方法により、より柔軟なＤ２Ｄ通信を行うことが可能な技術が提供される。
【０１４１】
＜＜実施形態の補足＞＞
ＰＳＣＣＨは、Ｄ２Ｄ通信に用いられる制御情報（ＳＣＩ等）を送信するための制御チャネルであれば他の制御チャネルであってもよい。ＰＳＳＣＨは、Ｄ２ＤコミュニケーションのＤ２Ｄ通信に用いられるデータ（ＭＡＣ  ＰＤＵ等）を送信するためのデータチャネルであれば他のデータチャネルであってもよい。ＰＳＤＣＨは、Ｄ２ＤディスカバリのＤ２Ｄ通信に用いられるデータ（ディスカバリメッセージ等）を送信するためのデータチャネルであれば他のデータチャネルであってもよい。
【０１４２】
以上、本発明の実施の形態で説明する各装置（ユーザ装置ＵＥ／基地局ｅＮＢ）の構成は、ＣＰＵとメモリを備える当該装置において、プログラムがＣＰＵ（プロセッサ）により実行されることで実現される構成であってもよいし、本実施の形態で説明する処理のロジックを備えたハードウェア回路等のハードウェアで実現される構成であってもよいし、プログラムとハードウェアが混在していてもよい。
【０１４３】
以上、本発明の実施の形態を説明してきたが、開示される発明はそのような実施形態に限定されず、当業者は様々な変形例、修正例、代替例、置換例等を理解するであろう。発明の理解を促すため具体的な数値例を用いて説明がなされたが、特に断りのない限り、それらの数値は単なる一例に過ぎず適切な如何なる値が使用されてもよい。上記の説明における項目の区分けは本発明に本質的ではなく、２以上の項目に記載された事項が必要に応じて組み合わせて使用されてよいし、ある項目に記載された事項が、別の項目に記載された事項に（矛盾しない限り）適用されてよい。機能ブロック図における機能部又は処理部の境界は必ずしも物理的な部品の境界に対応するとは限らない。複数の機能部の動作が物理的には１つの部品で行われてもよいし、あるいは１つの機能部の動作が物理的には複数の部品により行われてもよい。実施の形態で述べたシーケンス及びフローチャートは、矛盾の無い限り順序を入れ替えてもよい。処理説明の便宜上、ユーザ装置ＵＥ／基地局ｅＮＢは機能的なブロック図を用いて説明されたが、そのような装置はハードウェアで、ソフトウェアで又はそれらの組み合わせで実現されてもよい。本発明の実施の形態に従ってユーザ装置ＵＥが有するプロセッサにより動作するソフトウェア及び本発明の実施の形態に従って基地局ｅＮＢが有するプロセッサにより動作するソフトウェアはそれぞれ、ランダムアクセスメモリ（ＲＡＭ）、フラッシュメモリ、読み取り専用メモリ（ＲＯＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、レジスタ、ハードディスク（ＨＤＤ）、リムーバブルディスク、ＣＤ−ＲＯＭ、データベース、サーバその他の適切な如何なる記憶媒体に保存されてもよい。
【０１４４】
なお、実施の形態において、ＳＣＩリソースプールは、「制御情報用のリソースプール」の一例である。データリソースプールは、「データ送信用のリソースプール」の一例である。ＳＣＩは制御情報の一例である。図７の上側のＳＣＩリソースプールは、第一のリソースプールの一例である。図７の下側のＳＣＩリソースプールは、第二のリソースプールの一例である。ＳＣＩ予約識別子は、「制御情報の送信用のリソースを予約することを示す予約情報」の一例である。データ予約識別子は、「データ送信用のリソースを予約することを示す予約情報」の一例である。
【０１４５】
情報の通知は、本明細書で説明した態様／実施形態に限られず、他の方法で行われてもよい。例えば、情報の通知は、物理レイヤシグナリング（例えば、ＤＣＩ（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)などした事を「判断」「決定」したとみなす事を含み得る。つまり、「判断」「決定」は、何らかの動作を「判断」「決定」したとみなす事を含み得る。
【０１５２】
本明細書で使用する「に基づいて」という記載は、別段に明記されていない限り、「のみに基づいて」を意味しない。言い換えれば、「に基づいて」という記載は、「のみに基づいて」と「に少なくとも基づいて」の両方を意味する。
【０１５３】
また、本明細書で説明した各態様／実施形態の処理手順、シーケンスなどは、矛盾の無い限り、順序を入れ替えてもよい。例えば、本明細書で説明した方法については、例示的な順序で様々なステップの要素を提示しており、提示した特定の順序に限定されない。
【０１５４】
入出力された情報等は特定の場所（例えば、メモリ）に保存されてもよいし、管理テーブルで管理してもよい。入出力される情報等は、上書き、更新、または追記され得る。出力された情報等は削除されてもよい。入力された情報等は他の装置へ送信されてもよい。
【０１５５】
所定の情報の通知（例えば、「Ｘであること」の通知）は、明示的に行うものに限られず、暗黙的（例えば、当該所定の情報の通知を行わない）ことによって行われてもよい。
【０１５６】
本明細書で説明した情報、信号などは、様々な異なる技術のいずれかを使用して表されてもよい。例えば、上記の説明全体に渡って言及され得るデータ、命令、コマンド、情報、信号、ビット、シンボル、チップなどは、電圧、電流、電磁波、磁界若しくは磁性粒子、光場若しくは光子、又はこれらの任意の組み合わせによって表されてもよい。
【０１５７】
本特許出願は２０１６年２月４日に出願した日本国特許出願第２０１６−０２０３２７号に基づきその優先権を主張するものであり、日本国特許出願第２０１６−０２０３２７号の全内容を本願に援用する。
【符号の説明】
【０１５８】
ＵＥ  ユーザ装置
ｅＮＢ  基地局
１０１  信号送信部
１０２  信号受信部
１０３  選択部
２０１  信号送信部
２０２  信号受信部
２０３  通知部
３０１  ＲＦモジュール
３０２  ＢＢ処理モジュール
３０３  ＵＥ制御モジュール
３０４  通信ＩＦ
４０１  ＲＦモジュール
４０２  ＢＢ処理モジュール
４０３  装置制御モジュール
【図１】
2017135126.tif 000008
【図２】
2017135126.tif 000009
【図３】
2017135126.tif 000010
【図４Ａ】
2017135126.tif 000011
【図４Ｂ】
2017135126.tif 000012
【図５】
2017135126.tif 000013
【図６】
2017135126.tif 000014
【図７】
2017135126.tif 000015
【図８】
2017135126.tif 000016
【図９Ａ】
2017135126.tif 000017
【図９Ｂ】
2017135126.tif 000018
【図１０】
2017135126.tif 000019
【図１１】
2017135126.tif 000020
【図１２】
2017135126.tif 000021
【図１３】
2017135126.tif 000022
【図１４】
2017135126.tif 000023
【図１５】
2017135126.tif 000024
【図１６】
2017135126.tif 000025
【図１７】
2017135126.tif 000026
【図１８】
2017135126.tif 000027
【図１９】
2017135126.tif 000028
【図２０】
2017135126.tif 000029
【国際調査報告】
2017135126.tif 000030
2017135126.tif 000031
2017135126.tif 000032
2017135126.tif 000033