(57)【要約】  Ｄ２Ｄをサポートする移動通信システムにおけるユーザ装置において、前記ユーザ装置によるデータ送信のために用いる予約リソースに対応する予約リソース識別情報を含む予約情報を送信する予約手段と、前記予約リソース識別情報に対応する予約リソースを用いてデータを送信する送信手段とを備える。
2017026545.tif 000002
【特許請求の範囲】
【請求項１】
Ｄ２Ｄをサポートする移動通信システムにおけるユーザ装置であって、
前記ユーザ装置によるデータ送信のために用いる予約リソースに対応する予約リソース識別情報を含む予約情報を送信する予約手段と、
前記予約リソース識別情報に対応する予約リソースを用いてデータを送信する送信手段と
を備えるユーザ装置。
【請求項２】
前記予約情報は、前記ユーザ装置と、前記ユーザ装置から送信されるデータを受信する受信側ユーザ装置との間で前記予約リソースを使用する期間を示す情報を含む
請求項１に記載のユーザ装置。
【請求項３】
前記予約手段は、前記予約リソースを使用する期間が満了したことを検出した場合に、当該予約リソースとは別の予約リソースを選択し、当該別の予約リソースに対応する予約リソース識別情報を含む予約情報を送信する
請求項２に記載のユーザ装置。
【請求項４】
前記予約情報を送信するための制御情報リソースプールと前記データを送信するためのデータリソースプールとを有する制御期間よりも長い期間が予約期間として定められており、
前記送信手段は、前記予約期間だけ離れた制御期間毎に前記予約リソースを用いてデータを送信する
請求項１ないし３のうちいずれか１項に記載のユーザ装置。
【請求項５】
前記予約手段は、前記予約リソースとして、固定帯域幅のリソースを選択する
請求項１ないし４のうちいずれか１項に記載のユーザ装置。
【請求項６】
前記予約手段は、前記予約情報を送信するための制御情報リソースプールにおける受信電力に基づいて、他のユーザ装置により使用されていないと推定されるリソースを用いて前記予約情報を送信する
請求項１ないし５のうちいずれか１項に記載のユーザ装置。
【請求項７】
前記予約手段は、前記データを送信するためのデータリソースプールにおける受信電力の測定に基づき、もしくは、他のユーザ装置から受信する予約情報に基づき、他のユーザ装置により使用されていないと推定されるリソースを前記予約リソースとして選択する
請求項１ないし６のうちいずれか１項に記載のユーザ装置。
【請求項８】
Ｄ２Ｄをサポートする移動通信システムにおけるユーザ装置が実行するデータ送信方法であって、
前記ユーザ装置によるデータ送信のために用いる予約リソースに対応する予約リソース識別情報を含む予約情報を送信する予約ステップと、
前記予約リソース識別情報に対応する予約リソースを用いてデータを送信する送信ステップと
を備えるデータ送信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、Ｄ２Ｄをサポートする移動通信システムにおけるＤ２Ｄ信号の送受信技術に関連するものである。
【背景技術】
【０００２】
ＬＴＥ（Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）及びＬＴＥの後継システム（例えば、ＬＴＥ−Ａ（ＬＴＥ  Ａｄｖａｎｃｅｄ）、ＦＲＡ（Ｆｕｔｕｒｅ  Ｒａｄｉｏ  Ａｃｃｅｓｓ）、４Ｇなどともいう）では、ユーザ装置同士が無線基地局を介さないで直接通信を行うＤ２Ｄ（Ｄｅｖｉｃｅ  ｔｏ  Ｄｅｖｉｃｅ）技術が検討されている（例えば、非特許文献１）。【０００３】
Ｄ２Ｄは、ユーザ装置と基地局との間のトラヒックを軽減したり、災害時などに基地局が通信不能になった場合でもユーザ装置間の通信を可能とする。【０００４】
Ｄ２Ｄは、Ｄ２Ｄディスカバリ（Ｄ２Ｄ  ｄｉｓｃｏｖｅｒｙ、Ｄ２Ｄ発見ともいう）と、Ｄ２Ｄコミュニケーション（Ｄ２Ｄ  ｄｉｒｅｃｔ  ｃｏｍｍｕｎｉｃａｔｉｏｎ、）と、に大別される。以下では、Ｄ２Ｄコミュニケーション、Ｄ２Ｄディスカバリなどを特に区別しないときは、単にＤ２Ｄと呼ぶ。また、Ｄ２Ｄで送受信される信号を、Ｄ２Ｄ信号と呼ぶ。【０００５】
また、３ＧＰＰ（３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ）では、Ｄ２Ｄ機能を拡張することでＶ２Ｘを実現することが検討されている。図１に示すように、Ｖ２Ｘには、自動車（Ｖｅｈｃｌｅの例）と自動車との間で行われる通信形態を意味するＶ２Ｖ（Ｖｅｈｉｃｌｅ  ｔｏ  Ｖｅｈｃｌｅ）、自動車と道路脇に設置される路側ユニット（ＲＳＵ：Ｒｏａｄ−Ｓｉｄｅ  Ｕｎｉｔ）との間で行われる通信形態を意味するＶ２Ｉ（Ｖｅｈｉｃｌｅ  ｔｏ  Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）、自動車とドライバーのモバイル端末との間で行われる通信形態を意味するＶ２Ｎ（Ｖｅｈｉｃｌｅ  ｔｏ  Ｎｏｍａｄｉｃ  ｄｅｖｉｃｅ）、及び、自動車と歩行者のモバイル端末との間で行われる通信形態を意味するＶ２Ｐ（Ｖｅｈｉｃｌｅ  ｔｏ  Ｐｅｄｅｓｔｒｉａｎ）等がある。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】"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
【非特許文献２】３ＧＰＰ  ＴＳ  ３６．２１３  Ｖ１２．４．０  （２０１４−１２）
【発明の概要】
【発明が解決しようとする課題】
【０００７】
Ｖ２Ｘでは、車両からの警告情報発信等のように安全に関わるクリティカル（緊急、重大）な通信と、クリティカルではない通常通信とが存在する。【０００８】
クリティカルな通信については、信号を迅速かつ確実に送信先に届ける必要があり、通常の通信とは別に、衝突防止及びオーバヘッド削減等を考慮したチャネル構成等が必要と考えられる。しかしながら、従来技術では、クリティカルなＶ２Ｘ通信を考慮したチャネル構成等は提案されていない。【０００９】
なお、Ｖ２ＸはＤ２Ｄの一種であると考えると、上記のような課題はＶ２Ｘに限らず、Ｄ２Ｄ全般に生じ得る課題である。【００１０】
本発明は上記の点に鑑みてなされたものであり、Ｄ２Ｄをサポートする移動通信システムにおいて、クリティカルな通信に適したＤ２Ｄ通信の技術を提供することを目的とする。
【課題を解決するための手段】
【００１１】
本発明の実施の形態によれば、Ｄ２Ｄをサポートする移動通信システムにおけるユーザ装置であって、
前記ユーザ装置によるデータ送信のために用いる予約リソースに対応する予約リソース識別情報を含む予約情報を送信する予約手段と、
前記予約リソース識別情報に対応する予約リソースを用いてデータを送信する送信手段と
を備えるユーザ装置が提供される。【００１２】
また、本発明の実施の形態によれば、Ｄ２Ｄをサポートする移動通信システムにおけるユーザ装置が実行するデータ送信方法であって、
前記ユーザ装置によるデータ送信のために用いる予約リソースに対応する予約リソース識別情報を含む予約情報を送信する予約ステップと、
前記予約リソース識別情報に対応する予約リソースを用いてデータを送信する送信ステップと
を備えるデータ送信方法が提供される。
【発明の効果】
【００１３】
本発明の実施の形態によれば、Ｄ２Ｄをサポートする移動通信システムにおいて、クリティカルな通信に適したＤ２Ｄ通信の技術が提供される。
【図面の簡単な説明】
【００１４】
【図１】Ｖ２Ｘを説明するための図である。
【図２Ａ】Ｄ２Ｄを説明するための図である。
【図２Ｂ】Ｄ２Ｄを説明するための図である。
【図３】Ｄ２Ｄで使用されるチャネル構造の例を説明するための図である。
【図４Ａ】ＰＳＤＣＨの構造例を示す図である。
【図４Ｂ】ＰＳＤＣＨの構造例を示す図である。
【図５Ａ】ＰＳＣＣＨとＰＳＳＣＨの構造例を示す図である。
【図５Ｂ】ＰＳＣＣＨとＰＳＳＣＨの構造例を示す図である。
【図６Ａ】リソースプールコンフィギュレーションを示す図である。
【図６Ｂ】リソースプールコンフィギュレーションを示す図である。
【図７】本発明の実施の形態に係る通信システムの構成図である。
【図８】Ｖ２Ｘクリティカルトラフィックのための物理チャネルを説明するための図である。
【図９】予約動作の例を説明するための図である。
【図１０Ａ】予約期間毎のデータ送信方法の例を示す図である。
【図１０Ｂ】予約期間毎のデータ送信方法の例を示す図である。
【図１１Ａ】複数サブフレームでのＭＡＣ  ＰＤＵ送信の例を説明するための図である。
【図１１Ｂ】複数サブフレームでのＭＡＣ  ＰＤＵ送信の例を説明するための図である。
【図１１Ｃ】複数サブフレームでのＭＡＣ  ＰＤＵ送信の例を説明するための図である。
【図１２】予約情報の衝突を削減するための処理を説明するための図である。
【図１３】Ｈａｌｆ  ｄｕｐｌｅｘの問題を説明するための図である。
【図１４】リソース選択方法例１を説明するための図である。
【図１５Ａ】リソース選択方法例２を説明するための図である。
【図１５Ｂ】リソース選択方法例２を説明するための図である。
【図１５Ｃ】リソース選択方法例２を説明するための図である。
【図１６】ユーザ装置ＵＥの構成図である。
【図１７】ユーザ装置ＵＥのＨＷ構成図である。
【発明を実施するための形態】
【００１５】
以下、図面を参照して本発明の実施の形態を説明する。以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。例えば、本実施の形態に係る移動通信システムはＬＴＥに準拠した方式のシステムを想定しているが、本発明はＬＴＥに限定されるわけではなく、他の方式にも適用可能である。また、本明細書及び特許請求の範囲において、「ＬＴＥ」は、３ＧＰＰのＲｅｌ−１２、１３もしくはそれ以降に対応する通信方式（５Ｇを含む）を含み得る広い意味で使用する。
【００１６】
また、本実施の形態は、主にＶ２Ｘを対象としているが、本実施の形態に係る技術は、Ｖ２Ｘに限らず、広くＤ２Ｄ全般に適用可能である。「Ｄ２Ｄ」はその意味としてＶ２Ｘを含むものである。
【００１７】
以下では、基本的に、基地局を「ｅＮＢ」と表記し、ユーザ装置を「ＵＥ」と表記する。ｅＮＢは「ｅｖｏｌｖｅｄ  Ｎｏｄｅ  Ｂ」の略語であり、ＵＥは、「Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ」の略語である。
【００１８】
（Ｄ２Ｄの概要）
本実施の形態に係るＶ２Ｘの技術は、ＬＴＥで規定されているＤ２Ｄの技術をベースとしていることから、まずは、ＬＴＥで規定されているＤ２Ｄの概要について説明する。
【００１９】
ＬＴＥで規定されているＤ２Ｄでは、各ＵＥは、ＵＥからｅＮＢへの上り信号送信のリソースとして既に規定されている上りリソースの一部を利用して信号送受信を行う。
【００２０】
「Ｄｉｓｃｏｖｅｒｙ」については、図２Ａに示すように、Ｄｉｓｃｏｖｅｒｙ  ｐｅｒｉｏｄ毎に、Ｄｉｓｃｏｖｅｒｙメッセージ用のリソースプールが確保され、ＵＥはそのリソースプール内でＤｉｓｃｏｖｅｒｙメッセージを送信する。より詳細にはＴｙｐｅ１、Ｔｙｐｅ２ｂがある。Ｔｙｐｅ１では、ＵＥが自律的にリソースプールから送信リソースを選択する。Ｔｙｐｅ２ｂでは、上位レイヤシグナリング（例えばＲＲＣ信号）により準静的なリソースが割り当てられる。
【００２１】
「Ｃｏｍｍｕｎｉｃａｔｉｏｎ」についても、図２Ｂに示すように、Ｃｏｎｔｒｏｌ／Ｄａｔａ送信用リソースプールが周期的に確保される。この周期（期間）をＳＣ期間（ｓｉｄｅｌｉｎｋ  ｃｏｎｔｒｏｌ  ｐｅｒｉｏｄ）と呼ぶ。送信側のＵＥはＣｏｎｔｒｏｌリソースプール（ＳＣＩリソースプール）から選択されたリソースでＳＣＩ（Ｓｉｄｅｌｉｎｋ  Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）によりＤａｔａ送信用リソース等を受信側に通知し、当該Ｄａｔａ送信用リソースでＤａｔａを送信する。「Ｃｏｍｍｕｎｉｃａｔｉｏｎ」について、より詳細には、Ｍｏｄｅ１とＭｏｄｅ２がある。Ｍｏｄｅ１では、ｅＮＢからＵＥに送られる（Ｅ）ＰＤＣＣＨによりダイナミックにリソースが割り当てられる。Ｍｏｄｅ２では、ＵＥはＣｏｎｔｒｏｌ／Ｄａｔａ送信用リソースプールから自律的に送信リソースを選択する。リソースプールについては、ＳＩＢで通知されたり、予め定義されたものが使用される。
【００２２】
ＬＴＥにおいて、「Ｄｉｓｃｏｖｅｒｙ」に用いられるチャネルはＰＳＤＣＨ（Ｐｈｙｓｉｃａｌ  Ｓｉｄｅｌｉｎｋ  Ｄｉｓｃｏｖｅｒｙ  Ｃｈａｎｎｅｌ）と称され、「Ｃｏｍｍｕｎｉｃａｔｉｏｎ」におけるＳＣＩ等の制御情報を送信するチャネルはＰＳＣＣＨ（Ｐｈｙｓｉｃａｌ  Ｓｉｄｅｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ）と称され、データを送信するチャネルはＰＳＳＣＨ（Ｐｈｙｓｉｃａｌ  Ｓｉｄｅｌｉｎｋ  Ｓｈａｒｅｄ  Ｃｈａｎｎｅｌ）と称される（非特許文献２）。
【００２３】
Ｄ２Ｄのチャネル構造の例を図３に示す。図３に示すように、Ｃｏｍｍｕｎｉｃａｔｉｏｎに使用されるＰＳＣＣＨのリソースプール及びＰＳＳＣＨのリソースプールが割り当てられている。また、Ｃｏｍｍｕｎｉｃａｔｉｏｎのチャネルの周期よりも長い周期でＤｉｓｃｏｖｅｒｙに使用されるＰＳＤＣＨのリソースプールが割り当てられている。
【００２４】
また、Ｄ２Ｄ用の同期信号としてＰＳＳＳ（Ｐｒｉｍａｒｙ  Ｓｉｄｅｌｉｎｋ  Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ）とＳＳＳＳ（Ｓｅｃｏｎｄａｒｙ  Ｓｉｄｅｌｉｎｋ  Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ）が用いられる。また、例えばカバレッジ外動作のためにＤ２Ｄのシステム帯域、フレーム番号、リソース構成情報等の報知情報（ｂｒｏａｄｃａｓｔ  ｉｎｆｏｒｍａｔｉｏｎ）を送信するＰＳＢＣＨ（Ｐｈｙｓｉｃａｌ  Ｓｉｄｅｌｉｎｋ  Ｂｒｏａｄｃａｓｔ  Ｃｈａｎｎｅｌ）が用いられる。
【００２５】
図４Ａに、Ｄｉｓｃｏｖｅｒｙに使用されるＰＳＤＣＨのリソースプールの例を示す。リソースプールは、サブフレームのビットマップで設定されるため、図４Ａに示すようなイメージのリソースプールになる。他のチャネルのリソースプールも同様である。また、ＰＳＤＣＨは、周波数ホッピングしながら繰り返し送信（ｒｅｐｅｔｉｔｉｏｎ）がなされる。繰り返し回数は例えば０〜４で設定可能である。また、図４Ｂに示すように、ＰＳＤＣＨはＰＵＳＣＨベースの構造を有し、ＤＭ−ＲＳが挿入される構造になっている。
【００２６】
図５Ａに、「Ｃｏｍｍｕｎｉｃａｔｉｏｎ」に使用されるＰＳＣＣＨとＰＳＳＣＨのリソースプールの例を示す。図５Ａに示すとおり、ＰＳＣＣＨは、周波数ホッピングしながら１回繰り返し送信（ｒｅｐｅｔｉｔｉｏｎ）がなされる。ＰＳＳＣＨは、周波数ホッピングしながら３回繰り返し送信（ｒｅｐｅｔｉｔｉｏｎ）がなされる。また、図５Ｂに示すように、ＰＳＣＣＨとＰＳＳＣＨはＰＵＳＣＨベースの構造を有し、ＤＭ−ＲＳが挿入される構造になっている。
【００２７】
図６に、ＰＳＣＣＨ、ＰＳＤＣＨ、ＰＳＳＣＨ（Ｍｏｄｅ２）におけるリソースプールコンフィギュレーションの例を示す。図６Ａに示すように、時間方向では、リソースプールはサブフレームビットマップとして表される。また、ビットマップは、ｎｕｍ．ｒｅｐｒｔｉｔｉｏｎの回数だけ繰り返される。また、各周期における開始位置を示すｏｆｆｓｅｔが指定される。
【００２８】
周波数方向では、連続割り当て（ｃｏｎｔｉｇｕｏｕｓ）と不連続割り当て（ｎｏｎ−ｃｏｎｔｉｇｕｏｕｓ）が可能である。図６Ｂは、不連続割り当ての例を示しており、図示のとおり、開始ＰＲＢ、終了ＰＲＢ、ＰＲＢ数（ｎｕｍＰＲＢ）が指定される。
【００２９】
（システム構成）
図７に、本実施の形態における通信システムの構成例を示す。図７に示すように、ｅＮＢ、ＵＥ１、ＵＥ２が備えられている。以下、ＵＥ１とＵＥ２を特に区別しない場合、単にＵＥと記述する。なお、ｅＮＢは、例えば、各ＵＥに対してリソースプールの設定等を行うが、本実施の形態におけるＵＥ間の通信は、ｅＮＢを介さずに実施されるものである。
【００３０】
図７に示すＵＥ１、ＵＥ２は、それぞれ、ＬＴＥにおけるＵＥとしてのセルラー通信の機能、及び、上述したチャネルでの信号送受信を含むＤ２Ｄ機能を有している。また、ＵＥ１、ＵＥ２は、本実施の形態で説明する動作を実行する機能を有している。なお、セルラー通信の機能及び既存のＤ２Ｄの機能については、一部の機能（本実施の形態で説明する動作を実行できる範囲）のみを有していてもよいし、全ての機能を有していてもよい。
【００３１】
また、各ＵＥは、Ｖ２Ｘを行ういかなる装置であってもよいが、例えば、各ＵＥは、車両、歩行者が保持する端末、ＲＳＵ等である。
【００３２】
また、ｅＮＢについては、ＬＴＥにおけるｅＮＢとしてのセルラー通信の機能、及び、Ｖ２Ｘ（Ｄ２Ｄ）を可能ならしめるための機能（Ｖ２Ｘリソース割り当ての機能等）を有している。
【００３３】
（物理チャネル構成例）
本実施の形態において、ＵＥがＶ２Ｘのデータ送受信に使用する物理チャネルの構成例を図８に示す。
【００３４】
図８において、横軸方向が時間方向であり、縦軸方向が周波数方向である。図８に示すように、通常のＶ２Ｘ通信のためのＳＣ期間（周期的に到来する期間）が定められ、当該ＳＣ期間の内側にクリティカルなＶ２Ｘ通信のためのＳＣ期間が定められている。図示のとおり、通常のＶ２Ｘ通信のためのＳＣ期間はＳＣ期間Ａで示し、クリティカルなＶ２Ｘ通信のためのＳＣ期間は、ＳＣ期間Ｂとして示されている。
【００３５】
ＳＣ期間Ａとしては、例えば、ＬＴＥで規定される既存のＤ２Ｄ用のＳＣ期間を使用することができる。ＳＣ期間Ａにおいて、図８に示すように、ＳＣＩリソースプールにおけるＳＣＩ（既存のＳＣＩフォーマット０）を使用して、データリソースの割り当てを行うことができる。なお、データリソースの割り当てを行うためのＳＣＩをＳＡ（Ｓｃｈｅｄｕｌｉｎｇ  Ａｓｓｉｇｎｍｅｎｔ）と呼んでもよい。
【００３６】
一方、ＳＣ期間Ｂは、ＳＣ期間Ａよりも短い。一例として、ＳＣ期間Ａは、４０ｍｓあるいはそれ以上であり、ＳＣ期間Ｂは１０ｍｓあるいは２０ｍｓである。このように短い期間（ｐｅｒｉｏｄ）を使用することで、遅延を抑制できる。
【００３７】
また、図８に示すように、通常のＶ２Ｘ通信のためのリソース（例：通常のＤ２Ｄリソース）とクリティカルなＶ２Ｘ通信のためのリソースは重複させず、直交（ｏｒｔｈｏｇｏｎａｌ）させることとしているので、クリティカルなＶ２Ｘ通信と通常のＶ２Ｘ通信との衝突を回避可能となっている。
【００３８】
後述するように、本実施の形態では、クリティカルなＶ２Ｘ通信のためのデータリソースをセミスタティック（ｓｅｍｉ−ｓｔａｔｉｃａｌｌｙ）に割り当てることができる。このようなセミスタティックな割り当てにより信頼性を向上させることができる。
【００３９】
そのため、本実施の形態では、ＳＣ期間ＢにおけるＳＣＩリソースプールのリソースで送信されるＳＣＩ（クリティカルなＶ２Ｘ通信のデータリソース割り当てのための情報）のフォーマットとして、リソースの予約（ｒｅｓｅｒｖａｔｉｏｎ）を可能とする新たなＳＣＩフォーマットを定義している。
【００４０】
具体的には、当該ＳＣＩには、予約リソース識別情報（Ｒｅｓｅｒｖａｔｉｏｎ  ｒｅｓｏｕｒｃｅ  ｉｎｄｉｃａｔｉｏｎ）、タイマ値等が含められる。また、更に、宛先ＩＤ、ＭＣＳを含めることとしてもよい。なお、予約リソース識別情報、タイマ値等を総称して予約情報と呼ぶことにする。
【００４１】
上記のタイマ値は、予約が終了するまでの時間的な長さ（例：送信回数）を示す値であり、当該タイマ値は、ＳＣＩのリソースと、ＳＣＩにより割り当てるデータリソースの両方に適用される。また、タイマ値をデータリソースのみに適用することとしてもよい。タイマ値を用いた予約動作例については後述する。
【００４２】
図８に示すように、クリティカルなＶ２Ｘ通信用のデータリソースプール内には、データ送信のためのリソースとして、固定帯域幅(予め定めた帯域幅)のリソースが割り当てられる。また、時間リソースについても、固定長（予め定めた長さ、例：１サブフレーム）としてよい。つまり、クリティカルなＶ２Ｘ通信用のデータリソースとして、固定的なサイズのリソースが割り当てられる。なお、データリソースを完全に固定とせずに、例えば、固定サイズの整数倍のサイズを許容することとしてもよい。また、当該リソース(リソースブロック)で送信を行う際の送信電力については、ｅＮＢとの間のパスロス等に依存せずに、固定的な送信電力を用いることとしてよい。
【００４３】
クリティカルなＶ２Ｘ通信用のＳＣＩ及びデータに関しては、既に説明したようなＤ２Ｄにおける再送（例：図５）と同様に再送（ＳＣＩは１回再送、データは３回再送）を行うこととしてもよいし、既存のＤ２Ｄにおける再送とは異なる再送を行うこととしてもよい。
【００４４】
（予約に関する動作例）
以下、予約に関する動作等についてより詳細に説明する。以下では、特に断らない限り、ＳＣ期間、ＳＣＩ、データ、データリソース等は、クリティカルなＶ２Ｘ通信用のものを指すものとする。また、以下の動作は、Ｄ２ＤでのＭｏｄｅ２の「Ｃｏｍｍｕｎｉｃａｔｉｏｎ」に相当する動作である。
【００４５】
上述したように、本実施の形態では、クリティカルなＶ２Ｘ通信用に、新たなＳＣＩフォーマットが定義され、当該フォーマットを有するＳＣＩには、セミスタティックな割り当てを実現するための予約情報として、予約リソース識別情報、及びタイマ値が含められる。
【００４６】
予約リソース識別情報は、例えば、予約される（ｒｅｓｅｒｖｅｄ）リソースの時間−周波数の位置を示す。前述したように、リソースサイズを固定とするので、位置の情報を指定すればよい。一例として、予約リソース識別情報は、周波数位置とＴ−ＲＰＴ（Ｔｉｍｅ  Ｒｅｓｏｕｒｃｅ  Ｐａｔｔｅｒｎ）により構成される。Ｔ−ＲＰＴのパターンは、再送を含むデータリソース（送信リソース）の時間位置（例：サブフレーム位置）を示すパターンである。ただし、Ｔ−ＲＰＴを時間位置の指示情報として使用することは一例に過ぎず、他の指示情報を用いて時間位置を指示してもよい。また、次のＳＣＩ送信リソースの予約情報も通知してもよい。この場合、ＳＣＩの衝突を回避したり、送信データの時間・周波数リソースだけを予約して、ＳＣＩ送信の度にＭＣＳを変更することで送信データサイズを変更することができる。
【００４７】
タイマ値（タイマの初期値）は、予約終了までのカウント値を示す値である。ＵＥは、タイマを有し、当該タイマ値は、例えば、ＵＥが、データ送信を行う際に、データリソース（予約するリソース）を選択した後、最初に予約情報を有するＳＣＩを送信する際にタイマに設定される。タイマ値（初期値、タイマの長さ）は、例えば、上位レイヤ（例：ｅＮＢからのＲＲＣシグナリング）で、ある範囲内［Ｔｍｉｎ，Ｔｍａｘ］のランダムな値として設定される。
【００４８】
また、予約情報を有するＳＣＩを送信するためのリソース位置についても、ＳＣ期間内のＳＣＩリソースプールの中から選択される。
【００４９】
上記タイマにおけるタイマ値は、ＳＣＩがＵＥから送信されるたびに減算され、タイマ値がゼロになった場合（タイマが満了した場合）に、予約が終了し、予約されていたリソースは開放される。ＵＥにおいて送信データがまだある場合、ＵＥは、再びデータリソースを選択し、割り当てを行う。再選択されたリソースに関する予約情報を送信する際に、タイマには初期値が設定され、上記と同様にＳＣＩ送信の度に減算がなされる。また、ＳＣＩ（予約情報）を送信するためのリソースについても、再選択／再割り当てが行われる。
【００５０】
図９を参照して具体例を説明する。図９に示す例において、ＵＥは最初にＡで示すＳＣＩリソースプールにおけるあるリソースを選択し、当該リソースでＳＣＩ（予約情報）を送信する。最初のタイマ値（初期値）は２である。そして、Ｂで示すデータリソースプールにおいて、ＵＥは、予約情報における予約リソース識別情報で識別されるデータリソース（予約されたリソース）を用いてデータを送信する。
【００５１】
なお、予約情報を受信する受信側ＵＥでは、予約情報により、予約されたデータリソースの位置とタイマ値を把握できるので、当該データリソースでデータを受信できる回数を把握できる。
【００５２】
続いて、Ｃで示すＳＣＩリソースプールにおいて、ＵＥはＳＣＩ（予約情報）を送信する。この時点でタイマ値が１だけ減算され、当該予約リソースに関してＵＥが管理するタイマ値は１になる。送信する予約情報には、タイマ値＝１が含めてもよいし、含めなくてもよいが、図９は含める例を示している。タイマ値＝１を含めない場合でも、受信側では、予約リソースによりデータ受信により、タイマ値を減算することができる。
【００５３】
そして、Ｄで示すデータリソースプールにおいて、ＵＥは、予約情報における予約リソース識別情報で識別されるデータリソースを用いてデータを送信する。
【００５４】
図９に示す例において、２回目のＳＣＩ送信等、予約期間（タイマ値が０でない期間）においては、予約情報を送信しないことしてもよい。受信側では、最初の予約情報により、データリソースが所定の期間だけ予約されていることを把握でき、当該期間ではそのデータリソースを使用してデータの受信を行うことができるからである。この場合でも、予約情報を送信するタイミング毎にタイマ値を減算する。また、予約期間中は、予約情報を含まず、送信の度に変化し得る情報（ＭＣＳ等）のみを含むＳＣＩを送信することとしてもよい。
【００５５】
また、図９に示す予約情報／データを送信するＳＣ期間として、周期的に到来する毎回のＳＣ期間を用いてもよいし、当該ＳＣ期間の到来周期よりも長い周期で到来するＳＣ期間を用いてもよい。
【００５６】
図９の例では、ＵＥがＥで示すリソースプールでＳＣＩ（予約情報）を送信した時点でタイマ値が０になる。従って、その次の送信（Ｇ、Ｈ）においては、新たにＳＣＩリソースとデータリソースが選択され、ＳＣＩ送信、データ送信が継続される。
【００５７】
なお、本実施の形態における「予約」とは、予約情報／データを送信する側の送信側ＵＥにおいて、ある期間だけ同一または一定の時間・周波数パターンに基づくリソースを使用して予約情報／データを送信し、予約情報／データを受信する側の受信側ＵＥにおいて、当該期間だけ当該同一または一定の時間・周波数パターンに基づくリソースで予約情報／データを期待する（受信する）ことであり、送信側ＵＥと受信側ＵＥ以外のＵＥに対して当該リソースの「予約」が有効になるわけではない。つまり、送信側ＵＥと受信側ＵＥ以外のＵＥは、当該送信側ＵＥと受信側ＵＥにおいて予約されたリソースを使用することはできる。ただし、この場合、リソースの衝突が発生してしまうので、後述するように、本実施の形態では、各ＵＥは、リソースの衝突を回避するようにリソース選択（予約するリソースの選択）を行うことが可能である。
【００５８】
また、上記の例では、予約情報（もしくはデータ）を送信する回数をカウントすることで、予約に係る期間の満了を検知しているが、これは例である。例えば、タイマ値として時間（例：１ｍｓ単位の時間）を指定し、最初の予約情報／時間を送信（受信）してから、当該タイマ値の時間が経過した時点で予約されたリソースを開放してもよい。
【００５９】
（固定サイズリソースを使用することの利点）
上記のように、本実施の形態では、データ送信のために予約するリソースのサイズを固定としている。
【００６０】
これにより、測定（ｍｅａｓｕｒｅｍｅｎｔ）が容易になり、例えば、割り当てようとする位置のリソースが他のＵＥに使用されているか否かを容易に把握できるようになる。また、固定サイズのリソースの指定に要するビット数が少なくて済むので、リソースの予約を容易に行うことができる。
【００６１】
しかしながら、例えば、各サブフレームにおいて固定帯域幅のリソースを使用する場合、１サブフレームで送信できるビット数に制限が生じ、柔軟なパケットサイズ及びデータレートをサポートすることが難しくなる可能性がある。この点に鑑みて、本実施の形態では、以下で説明するように、固定帯域幅を用いる場合でも、柔軟なパケットサイズ及びデータレートを可能とする技術を導入している。
【００６２】
（柔軟な送信レートの実現）
本実施の形態では、ある予約されたリソースに関しての予約情報／データを送信する周期を示す予約期間（ｒｅｓｅｒｖａｔｉｏｎ  ｐｅｒｉｏｄ）を用いることができる。当該予約期間は、クリティカルな通信のためのＳＣ期間と同じでもよいし、異なっていてもよいが、例えば、予約期間をＳＣ期間の整数倍（ｍｕｌｔｉｐｌｅ  ｏｆ  ＳＣ  ｐｅｒｉｏｄ）とする。この何倍かを示す整数の値は固定であってもよいし、ｅＮＢから設定（ｃｏｎｆｉｇｕｒｅ）されることとしてもよい。
【００６３】
予約期間の例を図１０Ａ、Ｂに示す。図１０Ａ、ＢのいずれもＳＣ期間が２０ｍｓであり、予約期間が１００ｍｓである場合の例を示している。
【００６４】
図１０Ａの場合、最初の予約期間中のＡで示すＳＣ期間で最初の予約情報／データが送信される。前述したタイマが満了しない間、各予約期間において予約は有効であり、図１０Ａの例では、次の予約期間におけるＢで示すＳＣ期間（予約期間内での時間位置は、Ａで示すＳＣ期間と同じ）で、最初に用いたリソースと同じリソースを用いて、次の予約情報／データが送信される。
【００６５】
このような予約期間の概念を用いないで、ＳＣ期間毎（例：２０ｍｓ毎）に予約を有効とし、なおかつ、予約されたリソースでのデータ送信周期がＳＣ期間より長い場合（例：１００ｍｓ）、データ送信が行わずに予約だけされるリソースが発生し、リソースの無駄が生じる。一方、本実施の形態のように、予約期間を導入することでこのような無駄の発生を防止できる。
【００６６】
例えば、図１０Ａの場合において、各予約期間内の予約に係るＳＣ期間（Ａ、Ｂで示すＳＣ期間）以外のＳＣ期間については、当該リソースについての予約はなく、他の通信に使用することができる。つまり、予約期間だけ離れたＳＣ期間毎に予約が有効である。
【００６７】
また、図１０Ｂに示す送信方法を用いることで、ＳＣ期間に比べて長い予約期間を用いる場合でも、ＵＥは、柔軟な送信レートで予約リソースに係るデータを送信することができる。
【００６８】
図１０Ｂに示す例では、別々の予約期間（各予約期間は、予約期間の周期で到来）をＳＣ期間の単位で設ける（ＳＣ期間だけずらしながら設ける）こととしている。ＵＥは、別々の予約期間のうちの１つであるＡで示す予約期間（予約期間Ａとする）において、Ｂで示すＳＣ期間で予約情報／データを送信する。当該予約期間Ａの次の期間におけるＥで示すＳＣ期間において、同じリソースを用いて予約情報／データが送信される。また、Ｃで示す予約期間（予約期間Ｃとする）において、Ｄで示すＳＣ期間で予約情報／データが送信され、当該予約期間Ｃの次の期間におけるＦで示すＳＣ期間において、同じリソースを用いて予約情報／データが送信される。
【００６９】
上記の例では、予約期間をＳＣ期間の単位で設けることとしているが、この単位の長さをより長くすることで送信データレートを下げることができる。このように、予約期間を用いることで柔軟な送信レートを実現できる。
【００７０】
（複数サブフレームでのＭＡＣ  ＰＤＵ送信について）
ＬＴＥにおいて、一般的に、大きなサイズの上位レイヤのＰＤＵ（プロトコルデータユニット）は、複数のＭＡＣ  ＰＤＵに分割され、各ＭＡＣ  ＰＤＵは１つのサブフレームで送信される。
【００７１】
しかしながら、本大きなデータを複数のＭＡＣ  ＰＤＵに分割する場合、各ＭＡＣ  ＰＤＵに付されるＭＡＣヘッダがオーバヘッド（プロトコルコスト）を増大させる。特に本実施の形態における固定帯域幅送信を考慮すると、このようなオーバヘッドの増大は好ましくない。
【００７２】
本実施の形態では、ＭＡＣヘッダのコストを削減するために、ＵＥは、大きなサイズのデータを１つの大きなＭＡＣ  ＰＤＵに収容し、当該ＭＡＣ  ＰＤＵを複数の部分データに分割して送信する。各部分データは１つのサブフレームで送信される。
【００７３】
上記の送信を行う際に、ＵＥは、ＳＣＩ（予約情報）に中に、１つの（ａ  ｓｉｎｇｌｅ）ＭＡＣ  ＰＤＵの送信を完了させるための複数の部分データの数の値を含める。
【００７４】
分割したＭＡＣ  ＰＤＵの各部分データに関し、異なるＭＡＣ  ＰＤＵに属する２つの部分データは受信側で結合されない。また、１つのＭＡＣ  ＰＤＵの複数の部分データは単一のＳＣ期間で送信される。ただし、１つのＭＡＣ  ＰＤＵの複数の部分データを複数のＳＣ期間で送信することとしてもよい。
【００７５】
また、複数の部分データに分けて送信を行う際に、部分データの数に応じて、１つのＭＡＣ  ＰＤＵ当たりの再送回数を削減してもよい。例えば、分割を行わない場合のＭＡＣ  ＰＤＵの再送回数が４回である場合において、分割数が２である場合、各部分データを２回送信することとしてもよい（１回が初回送信、１回が再送）。
【００７６】
具体例を図１１Ａ、Ｂ、Ｃに示す。図１１Ａ、Ｂ、Ｃはそれぞれ、あるＳＣ期間を示す。また、ここでは、１つのＳＣ期間において、データ送信のために、８サブフレームが割り当てられる（予約される）ものとする。
【００７７】
図１１Ａは、ＭＡＣ  ＰＤＵの分割を行わない場合の例である。また、ここでは、ＵＥは、ＭＡＣ  ＰＤＵ１とＭＡＣ  ＰＤＵ２の２つのＭＡＣ  ＰＤＵを送信する。本例では、各ＭＡＣ  ＰＤＵの送信のための各ＳＣＩには部分データの数として１が含められる。１は分割をしないことを示している。
【００７８】
図１１Ａのデータリソースプール内に示されているように、各ＭＡＣ  ＰＤＵについて４回の送信がされている。
【００７９】
図１１Ｂは、１つのＳＣ期間で１つのＭＡＣ  ＰＤＵを送信する場合において、ＭＡＣ  ＰＤＵを２つに分割する場合の例である。図１１Ｂのデータリソースプール内に示されているように、分割された各部分データについて４回の送信がされている。また、各部分データの送信のための各ＳＣＩには部分データの数として２が含められる。２はＭＡＣ  ＰＤＵを２つに分割したことを示している。
【００８０】
図１１Ｃは、１つのＳＣ期間で２つのＭＡＣ  ＰＤＵを送信する場合において、各ＭＡＣ  ＰＤＵを２つに分割する場合の例である。図１１Ｃのデータリソースプール内に示されているように、分割された各部分データについて２回の送信がされている。また、各ＭＡＣ  ＰＤＵの送信のための各ＳＣＩには部分データの数として２が含められる。２はＭＡＣ  ＰＤＵを２つに分割したことを示している。
【００８１】
（予約情報の衝突の削減）
本実施の形態において、ＵＥがＳＣ期間のＳＣＩリソースプールで予約情報を含むＳＣＩ（以下、予約情報）を送信する際に、ＵＥは、予約情報を送信するためのリソースを任意に選択することとしてもよいが、その場合、他のＵＥが送信する予約情報との衝突が発生する可能性がある。
【００８２】
そこで、本実施の形態におけるＵＥは、ＳＣＩリソースプールにおいて他のＵＥから送信される予約情報の監視（ｌｉｓｔｅｎ）、測定を行い、他のＵＥが予約情報を送信していないと推定できるリソースを選択して予約情報を送信する。
【００８３】
より具体的には、データの送信を行おうとするＵＥは、予約情報（ＳＣＩ）のリソースを選択する前に、予約期間におけるＳＣＩリソースプールの各リソースで受信する信号の受信電力（受信エネルギー）を測定し、例えば、受信電力が所定の閾値以下となるリソースを選択して予約情報の送信を行う。受信電力が所定の閾値以下となるリソースが複数ある場合には、その中から１つのリソースを任意に選択することとしてよい。
【００８４】
また、受信電力が所定の閾値以下となるリソースがない場合、例えば、最小の受信電力となったリソースを予約情報送信のリソースとして選択することとしてもよい。
【００８５】
前述したように、ＵＥが管理するタイマが満了した場合、データのリソースとともに、予約情報のためのリソースも開放され、新たなリソースを選択する。
【００８６】
具体例について、図１２を参照して説明する。図１２の例では、予約期間が２×ＳＣ期間として設定されている。この場合、ＵＥは、まず、予約期間の中の２つのＳＣＩリソースプールにおける監視・測定を行って、ＳＣＩリソースプールの中から予約情報送信のためのリソースを選択する。そして、次の予約期間におけるＳＣＩリソースプール（図１２でＡで示される）において、選択したリソースを用いて予約情報の送信を行う。
【００８７】
（Ｈａｌｆ  ｄｕｐｌｅｘ問題の解消）
Ｖ２Ｘを含むＤ２Ｄ通信では、ＵＥは、同時に（例：１つのサブフレームで）は送信と受信を行わない半二重（Ｈａｌｆ  ｄｕｐｌｅｘ）通信を行う。例えば、ＵＥ１とＵＥ２が同じサブフレームで信号を送信する場合、ＵＥ１はＵＥ２からの信号を受信できず、ＵＥ２はＵＥ１からの信号を受信できない。そのため、セミスタティックにリソース割り当てを行う本実施の形態では、ＵＥ間で受信ができない期間が継続する可能性があるという問題がある。
【００８８】
この問題を図１３を参照して説明する。図１３に示すように、ＵＥ１とＵＥ２においてセミスタティックに割り当てられたリソースの時間位置（サブフレーム）が重なっており、この時間位置において、ＵＥ１とＵＥ２はそれぞれ相手からの信号を受信できなくなる。リソースの予約が継続する時間長によっては、このような状況が長く継続する可能性がある。
【００８９】
上記の問題を解消するために、ＵＥは、以下のオプション１とオプション２のいずれかを実行することとしてよい。
【００９０】
＜オプション１＞
オプション１は、データリソースプールにおいて、時間−周波数ホッピングを導入するものである。時間−周波数ホッピングとしては、既存のホッピングルール（例：既存のＳＣＩで用いられているルール）を適用することとしてもよいし、新たなルールを導入してもよい。
【００９１】
図１４に、オプション１における時間−周波数ホッピングの例を示す。図１４に示す例では、Ｎｆ（周波数長さ）×Ｍ＊Ｎｔ（時間長さ）で示される部分がＳＣ期間におけるデータリソースプールを示す。図示のとおり、データリソースプールは、Ｎｆ×Ｎｔのリソースからなるサブプールに分けられる。図１４の例では、Ｍ＝８であり、Ｔ−ＰＲＴパターンにより、どのサブプールにデータリソースを割り当てるかが指定される。例えば、Ｔ−ＰＲＴ＝｛１００１１００１｝であるとすると、最初のサブプール（図１４における左端のサブプール）は、パターンの１に該当し、データリソースを割り当てるサブプールに該当する。そして、各サブプールでは、例えば、既存のＳＣＩ（ＳＡ）のホッピング方法によりホッピングを行う。また、他の方法によりホッピングを行ってもよい。
【００９２】
このようなホッピングにより、ＵＥがＳＣ期間毎に送信するデータにおけるリソースは、時間ホッピングがなされ、Ｈａｌｆ  ｄｕｐｌｅｘ問題が生じる可能性を低減できる。
【００９３】
なお、図１４はＭ＝８の場合を示しているが、Ｍ＜８の場合には、Ｔ−ＰＲＴ＝｛１００１１００１｝における最初のＭビットを有効とする。また、Ｍ＞８の場合には、例えば、Ｔ−ＰＲＴのパターンを繰り返し用いればよい。
【００９４】
＜オプション２＞
オプション２では、ＵＥはデータリソースプールにおける割り当て状態を検出することにより、既に割り当てられているリソース以外のリソースを選択することとする。
【００９５】
より具体的には、ＵＥは、データ送信のリソースを選択する前に、データリソースプールでの各リソースにおける受信電力（受信エネルギ）を測定することで、例えば、受信電力が所定の閾値以下となるリソース（他のＵＥで使用していないと推定できるリソース）を選択する。また、ＵＥは、他のＵＥからのＳＣＩ（予約情報）を受信することにより、他のＵＥがデータリソースプールに割り当てたリソースを把握し、当該リソース以外のリソースを選択してもよい。
【００９６】
ＵＥは、データ送信に割り当てるリソースとして、他のＵＥのリソースと衝突しないリソースの周波数位置及び時間位置を決定し、割り当てを行う。なお、時間位置としてはＴ−ＰＲＴパターンとして決定してもよい。ここでのリソース選択にあたっては、他の予約に係るリソースとは時間位置（サブフレーム）が重複しないようにする。
【００９７】
また、最初に他のリソースと時間位置が重複しないようにＴ−ＰＲＴパターンを選択し、その後に、周波数位置を選択することとしてもよい。
【００９８】
なお、受信電力が所定の閾値以下となるリソースの量が十分でない場合、受信電力が所定の閾値より大きいリソースの中で、受信電力が最も小さいリソースを選択候補として選択を行うこととしてもよい。
【００９９】
図１５Ａ〜Ｃに具体例を示す。ここではＵＥ１、ＵＥ２、ＵＥ３がリソース選択を行っていることを想定する。図１５Ａに示す最初の状態では、ＵＥ１により、Ｔ−ＲＰＴ＝｛１１００００００｝で示される時間位置のリソースが予約されている。図１５Ｂに示す次の状態では、ＵＥ２が、ＵＥ１の予約リソースを把握した結果、ＵＥ２は、ＵＥ１のリソースと時間位置が重ならないＴ−ＲＰＴ＝｛００１１１１００｝を決定している。また、図１５Ｃに示す次の状態では、ＵＥ３は、可能な限り時間位置が重ならないようにＴ−ＲＰＴ＝｛１００００１１１｝を決定している。
【０１００】
（装置構成）
＜ＵＥの構成例＞
図１６に、本実施の形態に係るＵＥの機能構成図を示す。図１６に示すＵＥは、これまでに説明したＵＥの処理を全て実行可能である。ただし、これまでに説明したＵＥの処理の一部を実行可能としてもよい。以下では、主要な機能を説明する。
【０１０１】
図１６に示すように、当該ＵＥは、信号送信部１０１、信号受信部１０２、リソース管理部１０３、予約制御部１０４、測定部１０５を含む。なお、図１６は、ＵＥにおいて本発明の実施の形態に特に関連する機能部のみを示すものであり、少なくともＬＴＥに準拠した動作を行うための図示しない機能も有するものである。また、図１６に示す機能構成は一例に過ぎない。本実施の形態に係るＵＥの動作を実行できるのであれば、機能区分や機能部の名称はどのようなものでもよい。また、ＵＥは、Ｖ２Ｘに適用する際には、Ｖ２Ｘを構成するいかなる装置にもなり得る装置である。例えば、ＵＥは、車両、ＲＳＵ、歩行者の保持する端末等であってよい。
【０１０２】
信号送信部１０１は、ＵＥから送信されるべき上位のレイヤの信号から、物理レイヤの各種信号を生成し、無線送信する機能を含む。また、信号送信部１０１は、Ｄ２Ｄ（Ｖ２Ｘを含む）の送信機能とセルラ通信の送信機能を有する。
【０１０３】
信号受信部１０２は、他のＵＥ、ｅＮＢ等から各種の信号を無線受信し、受信した物理レイヤの信号からより上位のレイヤの信号を取得する機能を含む。信号受信部１０２は、Ｄ２Ｄ（Ｖ２Ｘを含む）の受信機能とセルラ通信の受信機能を有する。
【０１０４】
リソース管理部１０３は、ＵＥにおいてデータ送受信を行うために使用するリソースプール等の情報を例えばｅＮＢもしくはＲＳＵからの設定に基づき保持する。当該リソースプールの情報は、信号送信部１０１／信号受信部１０２によりデータ送受信に利用される。また、リソース管理部１０３は、例えば、測定部１０５による測定結果に基づいて、リソースプールの中から特定のリソースを選択する機能及び、時間−周波数ホッピングの制御機能も含んでいる。
【０１０５】
予約制御部１０４は、図９等を参照して説明した予約に係る制御を実行する。例えば、予約制御部１０４は、タイマの管理（タイマ値の減算等）、タイマ値が０になった場合に、予約リソース開放を信号送信部１０１／信号受信部１０２に指示する機能等を含む。
【０１０６】
測定部１０５は、他のＵＥから送信される信号の受信電力等を測定することで、リソース管理部１０３において、他のＵＥと衝突しないリソースを選択することを可能とする。
【０１０７】
＜ハードウェア構成＞
上記実施の形態の説明に用いたブロック図（図１６）は、機能単位のブロックを示している。これらの機能ブロック（構成部）は、ハードウェア及び／又はソフトウェアの任意の組み合わせによって実現される。また、各機能ブロックの実現手段は特に限定されない。すなわち、各機能ブロックは、物理的及び／又は論理的に結合した１つの装置により実現されてもよいし、物理的及び／又は論理的に分離した２つ以上の装置を直接的及び／又は間接的に（例えば、有線及び／又は無線）で接続し、これら複数の装置により実現されてもよい。
【０１０８】
例えば、本発明の一実施の形態におけるユーザ装置ＵＥは、本発明の実施の形態に係る処理を行うコンピュータとして機能してもよい。図１７は、本発明の一実施の形態に係る基地局ｅＮＢ及びユーザ装置ＵＥのハードウェア構成の一例を示す図である。上述のユーザ装置ＵＥは、物理的には、プロセッサ１００１、メモリ１００２、ストレージ１００３、通信装置１００４、入力装置１００５、出力装置１００６、バス１００７などを含むコンピュータ装置として構成されてもよい。
【０１０９】
なお、以下の説明では、「装置」という文言は、回路、デバイス、ユニットなどに読み替えることができる。ユーザ装置ＵＥのハードウェア構成は、図に示した各装置を１つ又は複数含むように構成されてもよいし、一部の装置を含まずに構成されてもよい。
【０１１０】
ユーザ装置ＵＥにおける各機能は、プロセッサ１００１、メモリ１００２などのハードウェア上に所定のソフトウェア（プログラム）を読み込ませることで、プロセッサ１００１が演算を行い、通信装置１００４による通信、メモリ１００２及びストレージ１００３におけるデータの読み出し及び／又は書き込みを制御することで実現される。
【０１１１】
プロセッサ１００１は、例えば、オペレーティングシステムを動作させてコンピュータ全体を制御する。プロセッサ１００１は、周辺装置とのインターフェース、制御装置、演算装置、レジスタなどを含む中央処理装置（ＣＰＵ：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）などのハードウェアを含んで構成されてもよく、当該ハードウェアにより、各機能ブロックの一部又は全てが実現されてもよい。例えば、プロセッサ１００１は、これらのハードウェアの少なくとも１つで実装されてもよい。
【０１１９】
（実施の形態のまとめ）
以上、説明したように、本実施の形態によれば、Ｄ２Ｄをサポートする移動通信システムにおけるユーザ装置であって、前記ユーザ装置によるデータ送信のために用いる予約リソースに対応する予約リソース識別情報を含む予約情報を送信する予約手段と、前記予約リソース識別情報に対応する予約リソースを用いてデータを送信する送信手段とを備えるユーザ装置が提供される。
【０１２０】
上記の構成により、Ｄ２Ｄをサポートする移動通信システムにおいて、クリティカルな通信に適したＤ２Ｄ通信を行うことが可能となる。もちろん、上記の構成は、クリティカルな通信ではない通信に適用してもよい。
【０１２１】
前記予約情報は、前記ユーザ装置と、前記ユーザ装置から送信されるデータを受信する受信側ユーザ装置との間で前記予約リソースを使用する期間を示す情報を含むこととしてもよい。この構成により、受信側のユーザ装置は、リソースが予約（ｒｅｓｅｒｖｅ）される期間を把握できる。
【０１２２】
前記予約手段は、前記予約リソースを使用する期間が満了したことを検出した場合に、当該予約リソースとは別の予約リソースを選択し、当該別の予約リソースに対応する予約リソース識別情報を含む予約情報を送信することとしてもよい。この構成により、予約が長期間継続することを回避できる。
【０１２３】
また、前記予約情報を送信するための制御情報リソースプールと前記データを送信するためのデータリソースプールとを有する制御期間よりも長い期間が予約期間として定められており、前記送信手段は、前記予約期間だけ離れた制御期間毎に前記予約リソースを用いてデータを送信することとしてもよい。この構成により、柔軟な送信レートを実現することができる。
【０１２４】
前記予約手段は、前記予約リソースとして、固定帯域幅のリソースを選択することとしてもよい。このように固定帯域幅のリソースを用いることで、例えば、リソースの測定及び予約を容易に行うことが可能となる。
【０１２５】
前記予約手段は、前記予約情報を送信するための制御情報リソースプールにおける受信電力に基づいて、他のユーザ装置により使用されていないと推定されるリソースを用いて前記予約情報を送信することとしてもよい。この構成により、予約情報が、他のユーザ装置により送信される信号と衝突することを回避できる。
【０１２６】
前記予約手段は、前記データを送信するためのデータリソースプールにおける受信電力の測定に基づき、もしくは、他のユーザ装置から受信する予約情報に基づき、他のユーザ装置により使用されていないと推定されるリソースを前記予約リソースとして選択することとしてもよい。この構成により、データが、他のユーザ装置により送信される信号と衝突することを回避できる。
【０１２７】
また、上記の装置の構成における「手段」を、「部」、「回路」、「デバイス」等に置き換えてもよい。
【０１２８】
本実施の形態で説明したＵＥは、ＣＰＵとメモリを備えるＵＥにおいて、プログラムがＣＰＵ（プロセッサ）により実行されることで実現される構成であってもよいし、本実施の形態で説明する処理のロジックを備えたハードウェア回路等のハードウェアで実現される構成であってもよいし、プログラムとハードウェアが混在していてもよい。
【０１２９】
本実施の形態で説明したｅＮＢは、ＣＰＵとメモリを備えるｅＮＢにおいて、プログラムがＣＰＵ（プロセッサ）により実行されることで実現される構成であってもよいし、本実施の形態で説明する処理のロジックを備えたハードウェア回路等のハードウェアで実現される構成であってもよいし、プログラムとハードウェアが混在していてもよい。
【０１３０】
以上、本発明の実施の形態を説明してきたが、開示される発明はそのような実施形態に限定されず、当業者は様々な変形例、修正例、代替例、置換例等を理解するであろう。発明の理解を促すため具体的な数値例を用いて説明がなされたが、特に断りのない限り、それらの数値は単なる一例に過ぎず適切な如何なる値が使用されてもよい。上記の説明における項目の区分けは本発明に本質的ではなく、２以上の項目に記載された事項が必要に応じて組み合わせて使用されてよいし、ある項目に記載された事項が、別の項目に記載された事項に（矛盾しない限り）適用されてよい。機能ブロック図における機能部又は処理部の境界は必ずしも物理的な部品の境界に対応するとは限らない。複数の機能部の動作が物理的には１つの部品で行われてもよいし、あるいは１つの機能部の動作が物理的には複数の部品により行われてもよい。説明の便宜上、基地局及びユーザ装置は機能的なブロック図を用いて説明されたが、そのような装置はハードウェアで、ソフトウェアで又はそれらの組み合わせで実現されてもよい。本発明の実施の形態に従って、ユーザ装置及び基地局が有するプロセッサにより動作するソフトウェアはそれぞれ、ランダムアクセスメモリ（ＲＡＭ）、フラッシュメモリ、読み取り専用メモリ（ＲＯＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、レジスタ、ハードディスク（ＨＤＤ）、リムーバブルディスク、ＣＤ−ＲＯＭ、データベース、サーバその他の適切な如何なる記憶媒体に保存されてもよい。
【０１３１】
＜実施形態の補足＞
情報の通知は、本明細書で説明した態様／実施形態に限られず、他の方法で行われてもよい。例えば、情報の通知は、物理レイヤシグナリング（例えば、ＤＣＩ（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)などした事を「判断」「決定」したとみなす事を含み得る。つまり、「判断」「決定」は、何らかの動作を「判断」「決定」したとみなす事を含み得る。
【０１４１】
本明細書で使用する「に基づいて」という記載は、別段に明記されていない限り、「のみに基づいて」を意味しない。言い換えれば、「に基づいて」という記載は、「のみに基づいて」と「に少なくとも基づいて」の両方を意味する。
【０１４２】
本発明は上記実施形態に限定されず、本発明の精神から逸脱することなく、様々な変形例、修正例、代替例、置換例等が本発明に包含される。
【０１４３】
本特許出願は、２０１５年８月１３日に出願した日本国特許出願第２０１５−１６０００２号に基づきその優先権を主張するものであり、日本国特許出願第２０１５−１６０００２号の全内容を本願に援用する。
【符号の説明】
【０１４４】
ｅＮＢ  基地局
ＵＥ１、ＵＥ２  ユーザ装置
１０１  信号送信部
１０２  信号受信部
１０３  リソース管理部
１０４  予約制御部
１０５  測定部
１００１  プロセッサ
１００２  メモリ
１００３  ストレージ
１００４  通信装置
１００５  入力装置
１００６  出力装置
【図１】
2017026545.tif 000003
【図２Ａ】
2017026545.tif 000004
【図２Ｂ】
2017026545.tif 000005
【図３】
2017026545.tif 000006
【図４Ａ】
2017026545.tif 000007
【図４Ｂ】
2017026545.tif 000008
【図５Ａ】
2017026545.tif 000009
【図５Ｂ】
2017026545.tif 000010
【図６Ａ】
2017026545.tif 000011
【図６Ｂ】
2017026545.tif 000012
【図７】
2017026545.tif 000013
【図８】
2017026545.tif 000014
【図９】
2017026545.tif 000015
【図１０Ａ】
2017026545.tif 000016
【図１０Ｂ】
2017026545.tif 000017
【図１１Ａ】
2017026545.tif 000018
【図１１Ｂ】
2017026545.tif 000019
【図１１Ｃ】
2017026545.tif 000020
【図１２】
2017026545.tif 000021
【図１３】
2017026545.tif 000022
【図１４】
2017026545.tif 000023
【図１５Ａ】
2017026545.tif 000024
【図１５Ｂ】
2017026545.tif 000025
【図１５Ｃ】
2017026545.tif 000026
【図１６】
2017026545.tif 000027
【図１７】
2017026545.tif 000028
【国際調査報告】
2017026545.tif 000029
2017026545.tif 000030