WO2017130592A1

WO2017130592A1 - ネットワーク装置、無線端末、及びこれらの方法

Info

Publication number: WO2017130592A1
Application number: PCT/JP2016/087337
Authority: WO
Inventors: 太一大辻; 洋明網中; 一志村岡
Original assignee: 日本電気株式会社
Priority date: 2016-01-25
Filing date: 2016-12-15
Publication date: 2017-08-03
Also published as: US20190029029A1; US10524235B2; JPWO2017130592A1; JP6822418B2

Abstract

ネットワーク装置（２）は、第１のＤ２Ｄ送信モード及び第２のＤ２Ｄ送信モードのいずれが有効化されるかを示す指示を包含する第１の制御信号（５０１）をＤ２Ｄ送信端末（１Ａ）及びＤ２Ｄ受信端末（１Ｂ）の少なくとも一方に送信する。第１のＤ２Ｄ送信モードは、第１の時間周期で繰り返される第１のリソース・パターンに従う。第２のＤ２Ｄ送信モードは、第１の時間周期と同一又は異なる第２の時間周期で繰り返される第２のリソース・パターンに従う。第２のリソース・パターンは、低遅延での送信が可能となるように定義される。一例では、第２のリソース・パターンは、データ送信のためのリソース割り当てを示すＤ２Ｄ制御情報の送信に使用される制御チャネル・サブフレーム・プールを含まない。

Description

ネットワーク装置、無線端末、及びこれらの方法

　本開示は、端末間直接通信（device-to-device（D2D）通信）に関し、特にD2D通信のための無線リソースの割り当てに関する。

　無線端末が基地局等のインフラストラクチャ・ネットワークを介さずに他の無線端末と直接的に通信する形態は、device-to-device（D2D）通信と呼ばれる。D2D通信は、直接通信（Direct Communication）および直接ディスカバリ（Direct Discovery）の少なくとも一方を含む。いくつかの実装において、D2D通信をサポートする複数の無線端末は、自律的に又はネットワークの指示に従ってD2D通信グループを形成し、当該D2D通信グループ内の他の無線端末と通信を行う。

　3GPP Release 12に規定されたProximity-based services（ProSe）は、D2D通信の一例である（例えば、非特許文献１を参照）。ProSe直接ディスカバリは、ProSeを実行可能な無線端末（ProSe-enabled User Equipment（UE））が他のProSe-enabled UEを、これら２つのUEが有する無線通信技術（例えば、Evolved Universal Terrestrial Radio Access (E-UTRA) technology）の能力だけを用いてディスカバリする手順により行われる。ProSe直接ディスカバリは、３つ以上のProSe-enabled UEsにより行われてもよい。

　ProSe直接通信は、ProSe直接ディスカバリの手順の後に、直接通信レンジ内に存在する２以上のProSe-enabled UEsの間の通信パスの確立を可能にする。言い換えると、ProSe直接通信は、ProSe-enabled UEが、基地局（eNodeB（eNB））を含む公衆地上移動通信ネットワーク（Public Land Mobile Network (PLMN)）を経由せずに、他のProSe-enabled UEと直接的に通信することを可能にする。ProSe直接通信は、基地局（eNB）にアクセスする場合と同様の無線通信技術（E-UTRA technology）を用いて行われてもよいし、Wireless Local Area Network (WLAN)の無線技術（つまり、IEEE 802.11 radio technology）を用いて行われてもよい。

　3GPP Release 12では、直接通信または直接ディスカバリに用いられる無線端末間の無線リンクは、サイドリンク（Sidelink）と呼ばれる（例えば、非特許文献２のセクション１４を参照）。サイドリンク送信は、アップリンク及びダウンリンクのために定義されたLong Term Evolution（LTE）フレーム構造と同じフレーム構造を使用し、周波数および時間ドメインにおいてアップリンク・リソースのサブセットを使用する。無線端末（UE）は、アップリンクと同様のシングルキャリア周波数分割多重（Single Carrier FDMA（Frequency Division Multiple Access）、SC-FDMA）を使用してサイドリンク送信を行う。

　3GPP Release 12 ProSeでは、サイドリンク送信のための無線リソースのUEへの割り当ては、無線アクセスネットワーク（e.g., Evolved Universal Terrestrial Radio Access Network（E-UTRAN））によって行われる。ProSe functionによってサイドリンク通信を許可されたUEは、無線アクセスネットワークノード（e.g., eNB（eNB））によって割り当てられた無線リソースを使用してProSe直接ディスカバリ又はProSe直接通信を行う。

　ProSe直接通信に関しては、２つのリソース割り当てモード、つまりscheduled resource allocation 及び autonomous resource selectionが規定されているscheduled resource allocation 及び autonomous resource selection は、それぞれ“sidelink transmission mode 1”及び“sidelink transmission mode 2”と呼ばれる（非特許文献２のセクション１４を参照）。

　ProSe直接通信のscheduled resource allocationでは、UEがサイドリンク送信を希望する場合、当該UEがサイドリンク送信のための無線リソース割り当てをeNBに要求し、eNBがサイドリンク・コントロール及びデータのためのリソースを当該UEに割り当てる。具体的には、UEは、アップリンク（UL）データ送信リソース（Uplink Shared Channel（UL-SCH）リソース）を要求するためにスケジューリング・リクエストをeNB に送信し、アップリンクグラント（UL grant）で割り当てられたULデータ送信リソースにおいてSidelink Buffer Status Report（Sidelink BSR）をeNBに送信する。eNBは、Sidelink BSRに基づいてUEに割り当てるサイドリンク送信リソースを決定し、サイドリンク・グラント（SL grant）をUEに送信する。

　SL grantは、Downlink Control Information（DCI） format 5として定義されている。SL grant（DCI format 5）は、Resource for PSCCH、Resource block assignment and hopping allocation、及びtime resource pattern indexなどのコンテンツを含む。Resource for PSCCHは、サイドリンク制御チャネル（i.e., Physical Sidelink Control Channel（PSCCH））用の無線リソースを示す。Resource block assignment and hopping allocationは、サイドリンクでのデータ送信用のサイドリンク・データチャネル（i.e., Physical Sidelink Shared Channel（PSSCH））を送信するための周波数リソース、つまりサブキャリア（リソースブロック）のセット、を決定するために使用される。Time resource pattern indexは、PSSCHを送信するための時間リソース、つまりサブフレームのセット、を決定するために使用される。なお、厳密に述べると、リソースブロックは、LTE及びLTE-Advancedの時間－周波数リソースを意味し、時間ドメインにおいて連続する複数個のOFDM（又はSC-FDMA）シンボルと周波数ドメインにおいて連続する複数個のサブキャリアによって規定されるリソース単位である。Normal cyclic prefixの場合、１リソースブロックは、時間ドメインにおいて連続する１２OFDM（又はSC-FDMA）シンボルを含み、周波数ドメインにおいて１２サブキャリアを含む。すなわち、Resource block assignment and hopping allocationおよびTime resource pattern indexは、PSSCHを送信するためのリソースブロックを指定する。UE（つまり、サイドリンク送信端末）は、SL grantに従ってPSCCHリソースおよびPSSCHリソースを決める。

　一方、ProSe直接通信のautonomous resource selectionでは、UEは、eNBによって設定されたリソースプールの中から、サイドリンク・コントロール（PSCCH）及びデータ（PSSCH）のためのリソースを自律的に選択する。eNBは、System Information Block（SIB）18において、autonomous resource selectionに使用するためのリソースプールをUEに割り当ててもよい。なお、eNBは、Radio Resource Control (RRC)_CONNECTEDのUEに対して、個別（dedicated）RRCシグナリングで、autonomous resource selectionに使用するためのリソースプールを割り当ててもよい。このリソースプールは、UEがRRC_IDLEであるときにも利用可能であってもよい。

　サイドリンクでの直接送信を行う場合、送信側のUE（D2D transmitting UE）（以下、送信端末とする）は、サイドリンク制御チャネル（i.e., PSCCH）用の無線リソース領域（resource pool）を使って、スケジューリング割当情報（Scheduling Assignment）の送信を行う。スケジューリング割当情報は、Sidelink Control Information (SCI) format 0とも呼ばれる。スケジューリング割当情報は、resource block assignment and hopping allocation、time resource pattern index、及び Modulation and Coding Scheme（MCS）などのコンテンツを含む。上述したscheduled resource allocation の場合、Scheduling Assignment（SCI format 0）が示す Resource block assignment and hopping allocation及びtime resource pattern indexは、eNBから受信したSL grant（DCI format 5）が示すResource block assignment and hopping allocation及びtime resource pattern indexに従う。

　送信端末は、スケジューリング割当情報に従った無線リソースを使って、PSSCHにおいてデータを送信する。受信側のUE（D2D receiving UE）（以下、受信端末とする）は、送信端末からのスケジューリング割当情報をPSCCHにおいて受信し、そのスケジューリング割当情報に従ってPSSCHにおいてデータを受信する。なお、ここで送信端末との用語は、無線端末の送信動作に着目した表現であって、送信専用の無線端末を意味するものではない。同様に、受信端末との用語は、無線端末の受信動作に着目した表現であり、受信専用の端末を意味するものではない。すなわち、送信端末は受信動作を行うことも可能であり、受信端末は送信動作を行うことも可能である。

　以下では、サイドリンク制御周期（sidelink control period）、PSCCHのためのリソースプール、及びPSSCHのためのリソースプールについて説明する。これらは、PSCCHを送信するための無線リソース（i.e., subframes及びresource blocks）及びPSSCHを送信するための無線リソースを決定するために必要である。既に説明したように、PSCCHは、スケジューリング割当情報などのサイドリンク制御情報（Sidelink Control Information (SCI)）の送信に使用されるサイドリンクの物理チャネルである。一方、PSSCHは、ユーザデータ送信（ダイレクト送信）のために使用されるサイドリンクの物理チャネルである。

　サイドリンク制御周期（sidelink control period）は、サイドリンクのためのスケジューリング周期である（図１を参照）。サイドリンク制御周期は、PSCCH周期（PSCCH period）とも呼ばれる。送信端末は、サイドリンク制御周期毎にスケジューリング割当情報（i.e., SCI format 0）を送信する。3GPP Release 12では、サイドリンク制御周期は、40ミリ秒（ms）, 60 ms, 70 ms, 80 ms, 120 ms, 140 ms, 160 ms, 240 ms, 280 ms, 又は320 msである。言い換えると、サイドリンク制御周期は、40サブフレーム, 60サブフレーム, 70サブフレーム, 80サブフレーム, 120サブフレーム, 140サブフレーム, 160サブフレーム, 240サブフレーム, 280サブフレーム, 又は320サブフレームである。

　したがって、送信端末は、サイドリンク制御周期毎に、つまり40 ms又はそれ以上の周期で、PSSCHリソースの割り当てを受信端末に通知する。ただし、PSSCHリソースの割り当てはtime resource pattern indexを用いて６、７又は８サブフレーム（6, 7, or 8 ms）単位で指定される。したがって、１つのサイドリンク制御周期の間は、６、７又は８サブフレーム周期で同じPSSCHリソースの割り当てが使用される。

　１つのサイドリンク制御周期において、送信端末は、PSCCHのためのリソースプール（サブフレームプール）に含まれるL_PSCCH個のサブフレームのうち２つのサブフレームにおいてスケジューリング割当情報（i.e., SCI format 0）を２回送信する。これら２回の送信は、PSCCHのためのリソースプール（リソースブロックプール）に含まれるM^PSCCH_RP _RB個のリソースブロックのうち異なる２つのリソースブロックにおいて行われる。

　PSCCHのためのリソースプールは、ブロードキャスト（SIB 18）又は個別シグナリング（RRCシグナリング）でeNBによってUEに設定される。PSCCHのためのリソースプールは、サイドリンク制御周期内のL_PSCCH個のサブフレーム及びM^PSCCH_RP _RB個の周波数ドメイン・リソースブロックから成る。

　PSCCHのためのリソースプールの指定方法について図２及び図３を用いて説明する。PSCCHのためのリソースプールは、サブフレーム・プールとリソースブロック・プールから成る。図２は、PSCCHサブフレーム・プールを示しており、図３は、PSCCHのためのリソースブロック・プールを示している。

　eNBは、PSCCHサブフレーム・プールを特定するために、サイドリンク制御周期（PSCCH周期）の長さ（P）、並びにPSCCHサブフレーム・ビットマップ及びその長さ（N’）を指定する。サブフレーム・ビットマップの長さ（N’）は、4、8、12、16、30、40又は42 bitsである。当該サブフレーム・ビットマップに対応するN’サブフレームは、図２に示すように、サイドリンク制御周期内の最初のN’サブフレームである。サブフレーム・ビットマップは、“0”にセットされたビットに対応するサブフレームがPSCCH送信に使用されないことを示し、“1”にセットされたビットに対応するサブフレームがPSCCH送信に使用できることを示す。したがって、１つのサイドリンク制御周期内のPSCCHリソースプールに含まれるサブフレーム数（L_PSCCH）は、サブフレーム・ビットマップで値１が指定されている数に等しい。PSCCHリソースプール（つまり、サブフレーム・プール）に含まれるサブフレームは、以下のように表すことができる：

　一方、図３に示すように、eNBは、PSCCHのためのリソースブロック・プールを特定するために、開始（start）Physical Resource Block（PRB）のインデックス（S1）、終了（end）PRBのインデックス（S2）、及びPRB数（M）を指定する。リソースブロック・プールは、PRBインデックスqが開始インデッククス（S1）以上であり且つS1+Mより小さい（S1 <= q < S1+M）M個のPRBsと、PRBインデックスqがS2-Mより大きく且つ終了インデッククス（S2）以下である（S2-M < q <= S2）M個のPRBsを含む（つまり、合計2M個のPRBs）。すなわち、eNBは、各々がM個のPRBsを含む２つのPRBクラスターをPSCCHのためのリソースブロック・プールに含めることができる。

　次に、PSSCHのためのリソースプールの指定方法について説明する。Scheduled resource allocation（sidelink transmission mode 1）の場合、eNBは、PSSCHサブフレーム・プールをSIB 18又は個別シグナリング（RRCシグナリング）で指定する。PSCCHリソース設定に関連付けられたサイドリンク制御周期（PSCCH周期）は、PSSCHリソース設定にもさらに関連付けられる。UEは、サブフレーム・プールから成るPSSCHリソースプールを以下のように決定する。すなわち、図２に示されるように、サイドリンク制御周期（PSCCH周期）内において、l^PSCCH _PSCCH-1 + 1と同じかこれより大きいサブフレーム・インデックスを持つ各サブフレームは、PSSCHサブフレーム・プールに属する。

　一方、autonomous resource selection（sidelink transmission mode 2）の場合、eNBは、PSSCHサブフレーム・プール及びリソースブロック・プールをSIB 18又は個別シグナリング（RRCシグナリング）で指定する。eNBは、サブフレーム・プールを指定するために、オフセット（O₂）、並びにサブフレーム・ビットマップ及びその長さ（N_B）を指定する。

　オフセット（O₂）は、サイドリンク制御周期（PSCCH周期）の先頭サブフレームのサブフレーム・インデックスj_beginからのオフセットを示す。ここでは、PSCCH周期内においてj_begin + O₂と同じかこれより大きいサブフレーム・インデックスを持つ各サブフレームの総数をN’とする。

　サブフレーム・ビットマップの長さ（N_B）は、4、8、12、16、30、40又は42 bitsである。サブフレーム・ビットマップは、“0”にセットされたビットに対応するサブフレームがPSSCH送信に使用されないことを示し、“1”にセットされたビットに対応するサブフレームがPSSCH送信に使用できることを示す。なお、通常の場合、サブフレーム・ビットマップの長さ（N_B）は、PSCCH周期内においてj_begin + O₂と同じかこれより大きいサブフレーム・インデックスを持つサブフレームの総数（N’）より小さい。したがって、UEは、ビットマップb₀, b₁, b₂, ..., b_N’-1を以下の数式に従って決定する：

ここで、a₀, a₁, a₂, ..., a_{N_B-1}は、eNBによりPSSCH設定として指定される長さN_Bのビットマップである。もしb_j = 1であれば、サブフレームl_jは、PSSCHサブフレーム・プールに属する。

　Autonomous resource selection（sidelink transmission mode 2）の場合のPSSCHのためのリソースブロック・プールは、PSCCHのためのリソースブロック・プールと同様に指定される。すなわち、eNBは、PSSCHのためのリソースブロック・プールを特定するために、開始（start）Physical Resource Block（PRB）のインデックス（S1）、終了（end）PRBのインデックス（S2）、及びPRB数（M）をPSSCHリソース設定において指定する。

3GPP TS 23.303 V12.7.0 (2015-12), "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Proximity-based services (ProSe); Stage 2 (Release 12)", 2015年12月 3GPP TS 36.213 V12.5.0 (2015-03), "3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access (E-UTRA); Physical layer procedures (Release 12)", 2015年3月

　上述したように、3GPP Release 12では、サイドリンク送信のための無線リソースは、サイドリンク制御周期（PSCCH周期）ごとにスケジュールされる。すなわち、サイドリンク送信端末は、サイドリンク送信リソースを示すスケジューリング割当情報（i.e., SCI format 0）をサイドリンク制御周期（PSCCH周期）ごとにサイドリンク受信端末に送信する。したがって、送信端末は、サイドリンクで送信するべきデータが発生してからこれを送信するまでに、サイドリンク制御周期の長さに応じた遅延を受け入れなければならない。仮にサイドリンク制御周期の長さが最短の40 msであっても、最大で35 ms程度の送信遅延が発生し得る。このような送信遅延の存在は、遅延要件の厳しい（つまり、低遅延（low‐latency）を必要とする）アプリケーションへのD2D通信の適用を妨げるかもしれない。例えば、Vehicle-to-Vehicle（V2V）通信およびVehicle-to-Infrastructure（V2I）通信に関する幾つかのアプリケーションは、D2D通信に対して10ミリ秒オーダーの低遅延性能を必要とするかもしれない。

　本明細書に開示される実施形態が達成しようとする目的の１つは、低遅延を要求する通信サービスへのD2D通信の適用を容易にすることに寄与する装置、方法、及びプログラムを提供することである。

　第１の態様では、ネットワーク装置は、メモリ、及び少なくとも１つのプロセッサを含む。前記少なくとも１つのプロセッサは、第１のdevice-to-device（D2D）送信モード及び第２のD2D送信モードのいずれが有効化されるかを示す指示を包含する第１の制御信号をD2D送信端末及びD2D受信端末の少なくとも一方に送信するよう構成されている。前記第１のD2D送信モードは、第１の時間周期で繰り返される第１のリソース・パターンに従う。各第１のリソース・パターンは、データ送信のためのリソース割り当てを示す第１のD2D制御情報を前記D2D送信端末から前記D2D受信端末に送信するために使用される制御チャネル・サブフレーム・プールと、前記第１のD2D制御情報に従う前記D2D送信端末から前記D2D受信端末へのデータ送信のために使用されるデータチャネル・サブフレーム・プールを含む。前記第２のD2D送信モードは、前記第１の時間周期と同一又は異なる第２の時間周期で繰り返される第２のリソース・パターンに従う。各第２のリソース・パターンは、前記D2D送信端末から前記D2D受信端末へのデータ送信のために使用されるデータチャネル・サブフレーム・プールを含む。各第２のリソース・パターンは、
（ａ）１つの第２のリソース・パターン内又は隣接する２つの第２のリソース・パターンにおいて、前記第１のD2D制御情報の送信に使用される複数の制御チャネル・サブフレーム・プールが前記第１の時間周期より短い間隔で現れる、
（ｂ）複数の連続する第２の時間周期でのデータ送信のためのリソース割り当てを示す第２のD2D制御情報を送信するために使用される制御チャネル・サブフレーム・プールを含む、又は
（ｃ）前記第１のD2D制御情報又は前記第２のD2D制御情報の送信に使用される制御チャネル・サブフレーム・プールを含まない、
よう定義されている。

　第２の態様では、ネットワーク装置における方法は、第１のdevice-to-device（D2D）送信モード及び第２のD2D送信モードのいずれが有効化されるかを示す指示を包含する第１の制御信号をD2D送信端末及びD2D受信端末の少なくとも一方に送信することを含む。第１及び第２の送信モードの定義は、第１の態様と同様である。

　第３の態様では、無線端末は、メモリ、及び少なくとも１つのプロセッサを含む。前記少なくとも１つのプロセッサは、前記少なくとも１つのプロセッサは、第１のdevice-to-device（D2D）送信モード及び第２のD2D送信モードのいずれが有効化されるかを示す指示を含む第１の制御信号を受信し、且つ前記第１の制御信号の受信に応答して前記第２のD2D送信モードに従うD2D通信を行うよう構成されている。第１及び第２の送信モードの定義は、第１の態様と同様である。

　第４の態様では、無線端末における方法は、第１のdevice-to-device（D2D）送信モード及び第２のD2D送信モードのいずれが有効化されるかを示す指示を含む第１の制御信号を受信すること、及び前記第１の制御信号の受信に応答して前記第２のD2D送信モードに従うD2D通信を行うこと、を含む。第１及び第２の送信モードの定義は、第１の態様と同様である。

　第５の態様では、プログラムは、コンピュータに読み込まれた場合に、上述の第２又は第４の態様に係る方法をコンピュータに行わせるための命令群（ソフトウェアコード）を含む。

　上述の態様によれば、低遅延を要求する通信サービスへのD2D通信の適用を容易にすることに寄与する装置、方法、及びプログラムを提供できる。

サイドリンク制御周期（PSCCH周期）を示す図である。サイドリンク制御周期内のPSCCHサブフレーム・プールとPSSCHサブフレーム・プールの一例を示す図である。サイドリンク制御周期内のPSCCHリソースブロック・プールの一例を示す図である。いくつかの実施形態に係る無線通信システムの構成例を示す図である。第１の実施形態に係る基地局、送信端末、及び受信端末の動作の一例を示すシーケンス図である。第１の実施形態に係る基地局、送信端末、及び受信端末の動作の一例を示すシーケンス図である。低遅延モードのためのリソース・パターンの一例を説明するための図である。低遅延モードのためのリソース・パターンの一例を説明するための図である。低遅延モードのためのリソース・パターンの一例を説明するための図である。低遅延モードのためのリソース・パターンの一例を説明するための図である。低遅延モードのためのリソース・パターンの一例を説明するための図である。第２の実施形態に係る基地局、送信端末、及び受信端末の動作の一例を示すシーケンス図である。第２の実施形態に係る基地局、送信端末、及び受信端末の動作の一例を示すシーケンス図である。第３の実施形態に係る基地局、送信端末、及び受信端末の動作の一例を示すシーケンス図である。第３の実施形態に係る基地局、送信端末、及び受信端末の動作の一例を示すシーケンス図である。第４の実施形態に係る無線通信システムの構成例を示す図である。第５の実施形態に係る基地局の動作の一例を示す図である。第６の実施形態に係る基地局の動作の一例を示す図である。いくつかの実施形態に係る無線端末の構成例を示すブロック図である。いくつかの実施形態に係る基地局の構成例を示すブロック図である。

　以下では、具体的な実施形態について、図面を参照しながら詳細に説明する。各図面において、同一又は対応する要素には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略される。

　以下に示される複数の実施形態は、3GPP Release 12（LTE-Advanced）に規定されたProSeの改良を主な対象として説明される。しかしながら、これらの実施形態は、LTE-Advanced 及びその改良に限定されるものではなく、他のモバイル通信ネットワーク又はシステムでのD2D通信に適用されてもよい。

＜第１の実施形態＞
　図４は、本実施形態を含むいくつかの実施形態に係る無線通信システムの構成例を示している。無線端末（UE）１Ａ及び１Ｂの各々は、少なくとも１つの無線トランシーバを有し、基地局（eNB）２とのセルラー通信（１０１又は１０２）を行うとともに、端末間ダイレクトインタフェース（e.g., PC5インタフェース又はサイドリンク）１０３上でD2D通信を行うよう構成されている。当該D2D通信は、少なくとも直接通信（i.e., ProSe Direct Communication）を含み、直接ディスカバリ（i.e., ProSe Direct Discovery）をさらに含んでもよい。なお、ProSe Direct Communication は、サイドリンク送信を利用する直接通信であり、Sidelink Direct Communicationとも呼ばれる。同様に、ProSe Direct Discoveryは、サイドリンク送信を利用する直接ディスカバリであり、Sidelink Direct Discoveryとも呼ばれる。

　eNB２は、セル２１を管理し、セルラー通信技術（e.g., Evolved Universal Terrestrial Radio Access (E-UTRA) technology）を用いて複数のUE１の各々とセルラー通信（１０１及び１０２）を行うことができる。なお、図５の例では、説明の簡略化のために複数のUE１Ａ及び１Ｂが同じセル２１内に位置している状況を示しているが、このような配置は一例に過ぎない。例えば、UE１Ａは、異なるeNB２によって管理される互いに隣接する２つのセルの一方のセル内に位置し、UE１Ｂは他方のセル内に位置してもよい。あるいは、UE１Ａ及びUE１Ｂのうち少なくとも一方は、１又は複数のeNB２によるカバレッジの外に位置してもよい。

　続いて以下では、本実施形態に係るサイドリンク通信に関する制御手順について説明する。ここでは、UE１Ａがサイドリンク送信端末であり、UE１Ｂがサイドリンク受信端末であり、UE１ＡからUE１Ｂへのサイドリンク送信が行われる場合を想定する。

　図５は、UE１Ａ、UE１Ｂ、及びeNB２の動作の一例（処理５００）を示すシーケンス図である。ステップ５０１では、eNB２は、UE１ＡとUE１Ｂの間のD2D通信（サイドリンク送信）のために通常モードと低遅延モードのいずれが有効化されるかを示す制御信号をUE１Ａ及びUE１Ｂに送信する。なお、通常モードは、通常のサイドリンク送信モードであり、低遅延モードは低遅延アプリケーション用のサイドリンク送信モードである。通常モード及び低遅延モードの詳細については後述する。当該制御信号が低遅延モードの有効化を示す場合、送信端末（UE１Ａ）は、低遅延モードに従ってサイドリンクでデータを送信し、受信端末（UE１Ｂ）は、低遅延モードに従って当該データを受信する。

　図６に示されるように、eNB２は、UE１Ａ及びUE１Ｂのいずれか一方のみ、例えば送信端末（UE１Ａ）のみに当該制御信号を送信してもよい。図６は、UE１Ａ、UE１Ｂ、及びeNB２の動作の他の例（処理６００）を示すシーケンス図である。ステップ６０１では、eNB２は、UE１ＡとUE１Ｂの間のD2D通信（サイドリンク送信）のために通常モードと低遅延モードのいずれが有効化されるかを示す制御信号を送信端末（UE１Ａ）に送信する。ステップ６０２では、送信端末（UE１Ａ）は、eNB２からの当該制御信号の受信に応答して、当該制御信号の内容を受信端末（UE１Ｂ）にサイドリンクを介して知らせる。

　scheduled resource allocation（sidelink transmission mode 1）の場合、eNB２は、通常モードと低遅延モードのいずれが有効化されるかを示す当該制御信号をサイドリンク・スケジューリング・グラント（DCI format 5）に含めてもよい。Autonomous resource selection（sidelink transmission mode 2）の場合、eNB２は、SIB 18又はRRCシグナリングでのPSCCHリソース設定又はPSSCHリソース設定において、当該制御信号をUE１Ａ及びUE１Ｂに送信してもよい。

　続いて以下では、通常モード及び低遅延モードの詳細について説明する。UE１Ａ及びUE１Ｂは、通常のサイドリンク送信モード（通常モード）と低遅延アプリケーション用のサイドリンク送信モード（低遅延モード）のどちらでも動作できるよう構成されている。通常モードは、例えば、背景技術で説明された3GPP Release 12サイドリンク送信であってもよい。すなわち、通常モードでは、送信端末（UE１Ａ）は、サイドリンク送信リソースを示すスケジューリング割当情報（i.e., SCI format 0）を40ms～320 msの間のサイドリンク制御周期（PSCCH周期）ごとに受信端末（UE１Ｂ）に送信してもよい。通常モードの場合、既に説明したように、仮にサイドリンク制御周期の長さが最短の40 msであっても、最大で35 ms程度の送信遅延が発生し得る。

　通常モードは、第１の時間周期（i.e., サイドリンク制御周期）で繰り返される第１のリソース・パターンに従う。図１及び図２を用いて説明したように、第１のリソース・パターンは、制御チャネル・サブフレーム・プール（i.e., PSCCHサブフレーム・プール）、及びデータチャネル・サブフレーム・プール（i.e., PSSCHサブフレーム・プール）を含む。PSCCHサブフレーム・プールは、スケジューリング割当情報（i.e., SCI format 0）を含むサイドリンク制御情報（SCI）の送信のために使用可能なL_PSCCH個のサブフレームから成る。一方、PSSCHサブフレーム・プールは、スケジューリング割当情報（i.e., SCI format 0）に従う送信端末（UE１Ａ）から受信端末（UE１Ｂ）へのサイドリンク上でのデータ送信（PSSCH送信）のために使用可能なL_PSSCH個のサブフレームから成る。

　これに対して、低遅延モードは、通常モードよりも低遅延でのサイドリンク送信をUE１Ａ及びUE１Ｂに可能とする。低遅延モードは、第２の時間周期で繰り返される第２のリソース・パターンに従う。第２の時間周期は、通常モードにおける第１の時間周期と同一であってもよいし、異なってもよい。第２のリソース・パターンは、送信端末（UE１Ａ）から受信端末（UE１Ｂ）へのサイドリンク上でのデータ送信のために使用可能な複数個のサブフレームから成るデータチャネル・サブフレーム・プールを含む。第２のリソース・パターンの具体的な例１～例６を以下に説明する。

（例１）
　図７は、通常モードで使用される第１のリソース・パターンの具体例（パターン７０１）、及び低遅延モードで使用される第２のリソース・パターンの具体例（パターン７２１）を示している。第１のリソース・パターン７０１は、通常のサイドリンク制御周期（sidelink control period（SC period））（e.g., 40 ms）に従う。第１のリソース・パターン７０１は、PSCCHサブフレーム・プール７０２及びPSSCHサブフレーム・プール７０３を含む。

　一方、第２のリソース・パターン７２１は、第１のリソース・パターン７０１のサイドリンク制御周期（e.g., 40 ms）よりも短いサイドリンク制御周期（e.g., 10 ms）に従う。第２のリソース・パターン７２１は、PSCCHサブフレーム・プール７２２及びPSSCHサブフレーム・プール７２３を含む。第２のリソース・パターン７２１の短いSC periodの長さは、低遅延アプリケーションのためのサイドリンク送信に許容される送信遅延（許容遅延）の長さに応じて決定されてもよい。第２のリソース・パターン７２１の短いSC periodの長さは、低遅延アプリケーションのための許容遅延の長さと同じかこれより短く設定されてもよい。これにより、送信端末（UE１Ａ）は、サイドリンクで送信するべきデータが発生してからこれを送信するまでの送信遅延を許容遅延以下に抑えることができる。

（例２）
　図８は、通常モードで使用される第１のリソース・パターンの具体例（パターン８０１）、及び低遅延モードで使用される第２のリソース・パターンの具体例（パターン８２１）を示している。第１のリソース・パターン８０１の構造は、図７に示された第１のリソース・パターン７０１のそれと同様である。すなわち、第１のリソース・パターン８０１は、PSCCHサブフレーム・プール８０２及びPSSCHサブフレーム・プール８０３を含む。

　第２のリソース・パターン８２１は、１つの第２の時間周期（e.g., 40 ms）内に複数のPSCCHサブフレーム・プール８２２、８２４、及び８２６を含む。PSCCHサブフレーム・プール８２２は、これに引き続くPSSCHサブフレーム・プール８２３のうちUE１Ａによるデータ送信に使用される１又は複数のサブフレームを指定するスケジューリング割当情報（i.e., SCI format 0）を送信するために使用される。同様に、PSCCHサブフレーム・プール８２４は、これに引き続くPSSCHサブフレーム・プール８２５のうちUE１Ａによるデータ送信に使用される１又は複数のサブフレームを指定するスケジューリング割当情報（i.e., SCI format 0）を送信するために使用される。同様に、PSCCHサブフレーム・プール８２６は、これに引き続くPSSCHサブフレーム・プール８２７のうちUE１Ａによるデータ送信に使用される１又は複数のサブフレームを指定するスケジューリング割当情報（i.e., SCI format 0）を送信するために使用される。

　なお、隣接する２つのPSCCHサブフレーム・プール８２２と８２４の間隔は、第１の時間周期（i.e., 通常のSC period（e.g., 40 ms））より短い。同様に、隣接する２つのPSCCHサブフレーム・プール８２４と８２６の間隔は、第１の時間周期（i.e., 通常のSC period（e.g., 40 ms））より短い。隣接する２つのPSCCHサブフレーム・プールの間隔は、低遅延アプリケーションのための許容遅延の長さと同じかこれより短く設定されてもよい。これにより、送信端末（UE１Ａ）は、サイドリンクで送信するべきデータが発生してからこれを送信するまでの送信遅延を許容遅延以下に抑えることができる。

　図８の例では、第２のリソース・パターン８２１が従う時間周期（第２の時間周期）は、第１のリソース・パターン８０１が従う時間周期（i.e., SC period）と同一である。しかしながら、第２のリソース・パターン８２１が従う時間周期は、第１のリソース・パターン８０１が従う時間周期より短くてもよいし、長くてもよい。

　図８の例では、PSCCHサブフレーム・プール８２２、８２４、又は８２６において送信端末（UE１Ａ）によって送信されるスケジューリング割当情報（i.e., SCI format 0）は、データ送信のためのPSSCHリソースを指定するための「オフセット値」を包含してもよい。当該オフセット値は、当該スケジューリング割当情報（i.e., SCI format 0）が送信されたPSCCHサブフレームのサブフレーム・インデックスからのオフセットを示してもよい。なお、図８の例では、上述したように、PSCCHサブフレーム・プールの間隔が十分に短い。したがって、データ送信のためのPSSCHサブフレーム（subframes）のセットを指定する必要がないかもしれない。この場合、スケジューリング割当情報（i.e., SCI format 0）は、Time Resource Pattern（TRP）indexを包含しなくてもよい。　　

（例３）
　当該第３の例では、低遅延モードが従う第２のリソース・パターンは、通常モードが従う第１のリソース・パターンと同一であってもよい。すなわち、低遅延モードにおいて、UE１Ａ及びUE１Ｂは、通常モードと同じサイドリンク制御周期を使用し、且つ通常モードと同じPSCCHサブフレーム・プール及びPSSCHサブフレーム・プールを使用してもよい。

　ただし、当該第３の例では、低遅延モードで動作する送信端末（UE１Ａ）は、各サイドリンク制御周期においてスケジューリング割当情報を送信し、各サイドリンク制御周期においてデータ送信のためのPSSCHリソースを予め確保する。予め確保されるPSSCHリソースの最長間隔は、低遅延アプリケーションのための許容遅延の長さと同じかこれより短く設定されてもよい。また、各サイドリンク制御周期におけるPSCCHサブフレーム・プールの長さは、低遅延アプリケーションのための許容遅延の長さより短く設定されてもよい。これにより、送信端末（UE１Ａ）は、サイドリンクで送信するべきデータが発生してからこれを送信するまでの送信遅延を許容遅延以下に抑えることができる。

　なお、scheduled resource allocation（sidelink transmission mode 1）の場合、eNB２は、各サイドリンク制御周期でのPSSCHリソースを示すサイドリンク・スケジューリング・グラント（DCI format 5）を送信端末（UE１Ａ）に送信してもよい。あるいは、scheduled resource allocationの場合に、eNB２は、RRCシグナリング（RRC Connection Reconfigurationメッセージ）でのPSCCHリソース設定又はPSSCHリソース設定において、連続する複数のサイドリンク制御周期でのデータ送信のためのPSSCHリソースを送信端末（UE１Ａ）に設定してもよい。Autonomous resource selection（sidelink transmission mode 2）の場合も、eNB２は、RRCシグナリング（RRC Connection Reconfigurationメッセージ）でのPSCCHリソース設定又はPSSCHリソース設定において、連続する複数のサイドリンク制御周期でのデータ送信のためのPSSCHリソースを送信端末（UE１Ａ）に設定してもよい。

（例４）
　当該第４の例では、上述の第３の例と同様に、低遅延モードで動作する送信端末（UE１Ａ）は、各サイドリンク制御周期においてデータ送信のためのPSSCHリソースを予め確保する。ただし、各サイドリンク制御周期においてサイドリンク制御情報（SCI format 0）を送信することは、PSCCH用の無線リソースの浪費を招く。したがって、当該第４の例では、送信端末（UE１Ａ）は、第j番目のサイドリンク制御周期内のPSCCHサブフレーム・プール内の１又は複数のサブフレーム（e.g., ２つのサブフレーム）において特別なサイドリンク制御情報を送信する。当該特別なサイドリンク制御情報は、当該第j番目のサイドリンク制御周期内のPSSCHサブフレーム・プール内の１又は複数のサブフレームを特定するための第１の情報要素（i.e., スケジューリング割当情報（SCI format 0））を含む。これに加えて、当該特別なサイドリンク制御情報は、当該サイドリンク制御情報によるデータ送信（PSSCH送信）のための無線リソース割り当てが第（j+1）番目以降の少なくとも１つのサイドリンク制御周期においても引き続き有効であることを示す第２の情報要素を含む。すなわち、送信端末（UE１Ａ）は、受信端末（UE１Ｂ）へのサイドリンク送信のために継続性のある（persistent又はsemi-persistent）リソース割り当てを行う。

　送信端末（UE１Ａ）は、第j番目のサイドリンク制御周期でのデータ送信のための無線リソース割り当てが引き続き有効とされる第(j+1)番目以降の少なくとも１つのサイドリンク制御周期において、新たなサイドリンク制御情報（スケジューリング割当情報（SCI format 0））を送信すること無くPSSCH上でのデータ送信を行う。一方、受信端末（UE１Ｂ）は、第j番目のサイドリンク制御周期でのデータ送信のための無線リソース割り当てが第(j+1)番目以降の少なくとも１つのサイドリンク制御周期において引き続き有効とされる場合に、これらの第(j+1)番目以降のサイドリンク制御周期において新たなサイドリンク制御情報（スケジューリング割当情報）を受信すること無くPSSCH上でのデータ受信を行う。

　いくつかの実装において、特別なサイドリンク制御情報に含まれる第２の情報要素は、第（j+1）番目以降の少なくとも１つのサイドリンク制御周期（つまり、第j番目のサイドリンク制御周期でのデータ送信のための無線リソース割り当てが引き続き有効とされる少なくとも１つのサイドリンク制御周期）の長さを指定してもよい。例えば、当該第２の情報要素は、第j番目のサイドリンク制御周期において送信されるサイドリンク制御情報（スケジューリング割当情報（SCI format 0））が有効とされるサイドリンク制御周期の数を示してもよい。例えば、送信端末（UE１Ａ）は、低遅延アプリケーションの許容遅延に応じて、無線リソース割り当ての有効サイドリンク制御周期数を決定してもよい。ここで、許容遅延は、最大遅延、平均遅延、及び遅延保証に関する優先度、のうち少なくとも１つであってもよい。

　これに代えて、いくつかの実装において、当該第２の情報要素は、第j番目のサイドリンク制御周期でのデータ送信のための無線リソース割り当てが継続されるか否かを示してもよい。当該第２の情報要素は、無線リソース割り当ての継続の有無を示すフラグ情報であってもよい。例えば、当該第２の情報要素は、１ビットのフラグ情報であってもよい。フラグの値が“１”である場合に、第j番目のサイドリンク制御周期でのデータ送信のための無線リソース割り当てが第（j+1）番目以降のサイドリンク制御周期においても有効とされてもよい。一方、フラグの値が“０”である場合に、第j番目のサイドリンク制御周期でのデータ送信のための無線リソース割り当てが当該第j番目のサイドリンク制御周期においてのみ有効とされてもよい。

　図９は、当該第４の例に係るPSCCH及びPSSCHの送信の一例を示す図である。図９の例では、送信端末（UE１Ａ）は、第j番目のサイドリンク制御周期（PSCCH周期）９０１内のPSCCHサブフレーム・プール９１１内の２つのサブフレームにおいてサイドリンク制御情報をPSCCH上で送信する（９２２及び９２３）。サイドリンク制御情報９２２及び９２３は、スケジューリング割当情報（i.e., SCI format 0）を含むだけでなく、当該スケジューリング割当情報が第（j+1）番目のサイドリンク制御周期９０２及びそれ以降においても有効であることを示す。

　送信端末（UE１Ａ）は、第j番目のサイドリンク制御周期９０１内のPSSCHサブフレーム・プール９１２内の複数のサブフレームにおいて、サイドリンク制御情報９２２及び９２３にしたがってデータ送信（PSSCH送信）９３１～９３４を行う。さらに、送信端末（UE１Ａ）は、第（j+1）番目のサイドリンク制御周期９０２内のPSCCHサブフレーム・プール９１３においてサイドリンク制御情報を送信せずに、サイドリンク制御周期９０２内のPSSCHサブフレーム・プール９１４においてデータ送信（PSSCH送信）９３５～９３８を行う。データ送信（PSSCH送信）９３５～９３８は、第j番目のサイドリンク制御周期９０１において送信されたサイドリンク制御情報９２２及び９２３に従う。これと同様に、送信端末（UE１Ａ）は、第（j+2）番目のサイドリンク制御周期９０３内のPSCCHサブフレーム・プール９１５においてサイドリンク制御情報を送信せずに、サイドリンク制御周期９０３内のPSSCHサブフレーム・プール９１６においてデータ送信（PSSCH送信）９３９～９４２を行う。データ送信（PSSCH送信）９３９～９４２は、第j番目のサイドリンク制御周期９０１において送信されたサイドリンク制御情報９２２及び９２３に従う。

　当該第４の例によれば、上述の第３の例と同様に、送信端末（UE１Ａ）は、サイドリンクで送信するべきデータが発生してからこれを送信するまでの送信遅延を許容遅延以下に抑えることができる。さらに、当該第４の例によれば、PSCCHリソースの浪費を抑制できる。

　当該第４の例では、scheduled resource allocation（sidelink transmission mode 1）の場合、eNB２は、各サイドリンク制御周期でのPSSCHリソースを示すサイドリンク・スケジューリング・グラント（DCI format 5）を送信端末（UE１Ａ）に送信してもよい。あるいは、scheduled resource allocationの場合に、eNB２は、RRCシグナリング（RRC Connection Reconfigurationメッセージ）でのPSCCHリソース設定又はPSSCHリソース設定において、連続する複数のサイドリンク制御周期でのデータ送信のためのPSSCHリソースを送信端末（UE１Ａ）に設定してもよい。Autonomous resource selection（sidelink transmission mode 2）の場合も、eNB２は、RRCシグナリング（RRC Connection Reconfigurationメッセージ）でのPSCCHリソース設定又はPSSCHリソース設定において、連続する複数のサイドリンク制御周期でのデータ送信のためのPSSCHリソースを送信端末（UE１Ａ）に設定してもよい。

（例５）
　当該第５の例では、低遅延モードのための第２のリソース・パターンは、PSCCHサブフレーム・プールを含まない。図１０は、通常モードで使用される第１のリソース・パターンの具体例（パターン１００１）、及び低遅延モードで使用される第２のリソース・パターンの具体例（パターン１０２１）を示している。第１のリソース・パターン１００１の構造は、図７に示された第１のリソース・パターン７０１のそれと同様である。すなわち、第１のリソース・パターン１００１は、PSCCHサブフレーム・プール１００２及びPSSCHサブフレーム・プール１００３を含む。

　第２のリソース・パターン１０２１は、サイドリンクでのデータ送信のためのPSSCHサブフレーム・プール１０２２を含むが、PSCCHサブフレーム・プールを含まない。第２のリソース・パターン１０２１の周期（第２の時間周期）は、通常モードのサイドリンク制御周期（第１の時間周期）と同一であってもよいし、異なってもよい。

　幾つかの実装において、eNB２は、PSSCHサブフレーム・プール１０２２を受信端末（UE１Ｂ）に設定する。PSSCHサブフレーム・プール１０２２の受信端末（UE１Ｂ）への設定は、低遅延モードが有効化されることを示す制御信号（e.g., RRCシグナリング）に含まれてもよい。一方、送信端末（UE１Ａ）は、サイドリンクで送信するべきデータが発生したことに応答して、Sidelink BSRをeNB２に送信し、サイドリンク・グラント（SL grant）をeNB２から受信する。当該サイドリンク・グラントは、スケジューリング割当情報（i.e., SCI format 0）を送信するためのPSCCHリソース、及びデータ送信のためのPSSCHリソースを示す。なお、eNB２は、受信端末（UE１Ｂ）に設定されたPSSCHサブフレーム・プール１０２２の中から当該PSCCHリソース及びPSSCHリソースを決定する。

　eNB２は、PSSCHサブフレーム・プール１０２２内からUE１Ａ及びUE１Ｂに割り当てるPSSCHサブフレーム（subframes）のセットを決定するために、Time Resource Pattern（TRP）indexと同様のビットマップを用いてもよい。当該ビットマップの長さは、PSSCHサブフレーム・プール１０２２と同一でもよいし、短くてもよい。例えば、当該ビットマップは、値“1”にセットされたビットに対応するサブフレームがPSSCH送信に使用できることを示し、値“0”にセットされたビットに対応するサブフレームがPSSCH送信に使用できないことを示す。

　送信端末（UE１Ａ）は、受信端末（UE１Ｂ）へ送信されるスケジューリング割当情報（i.e., SCI format 0）に、データ送信のためのPSSCHリソースを指定する「オフセット値」を含めてもよい。当該オフセット値は、当該スケジューリング割当情報（i.e., SCI format 0）が送信されたサブフレームのサブフレーム・インデックスからのオフセットを示してもよい。言い換えると、当該オフセット値は、当該スケジューリング割当情報（i.e., SCI format 0）が送信されたサブフレームとPSSCHサブフレーム（subframes）のセット内の先頭サブフレームとの間のサブフレーム数を示してもよい。

　UE１Ａ、UE１Ｂ、及びeNB２のこれらの動作によれば、受信端末（UE１Ｂ）は、eNB２により設定されたPSSCHサブフレーム・プール１０２２のみにおいて受信動作を試みればよく、したがって、サイドリンク帯域の全てにおいて常に受信動作を試みる必要がない。よって、受信端末（UE１Ｂ）の電力消費を低減できる。

　さらに、eNB２は、PSSCHサブフレーム・プール１０２２の全帯域のうち、受信端末（UE１Ｂ）が受信動作を試みるべき一部の周波数帯域を受信端末（UE１Ｂ）に設定してもよい。当該一部の周波数帯域の受信端末（UE１Ｂ）への設定は、低遅延モードが有効化されることを示す制御信号（e.g., RRCシグナリング）に含まれてもよい。一方、送信端末（UE１Ａ）は、サイドリンクで送信するべきデータが発生したことに応答して、Sidelink BSRをeNB２に送信し、サイドリンク送信リソースを示すサイドリンク・グラント（SL grant）をeNB２から受信してもよい。このとき、eNB２は、受信端末（UE１Ｂ）に設定された一部の周波数帯域の中から当該サイドリンク送信リソースを決定すればよい。UE１Ａ、UE１Ｂ、及びeNB２のこれらの動作によれば、受信端末（UE１Ｂ）が受信を試みるべき帯域をいっそう限定できる。よって、受信端末（UE１Ｂ）の電力消費をいっそう低減できる。

　他の実装において、eNB２は、送信端末（UE１Ａ）から受信端末（UE１Ｂ）へのデータ送信のためにPSSCHサブフレーム・プール１０２２内から割り当てるPSSCHリソースを、RRCシグナリング（RRC Connection Reconfigurationメッセージ）において、送信端末（UE１Ａ）及び受信端末（UE１Ｂ）に予め設定してもよい。サブフレーム・プール１０２２内からUE１Ａ及びUE１Ｂに割り当てられるPSSCHリソースの時間間隔は、低遅延アプリケーションのための許容遅延の長さと同じかこれより短く設定されてもよい。これにより、送信端末（UE１Ａ）は、サイドリンクで送信するべきデータが発生してからこれを送信するまでの送信遅延を許容遅延以下に抑えることができる。さらに、UE１Ａ、UE１Ｂ、及びeNB２のこれらの動作によれば、受信端末（UE１Ｂ）は、eNB２により設定された特定のPSSCHリソースのみにおいて受信動作を試みればよく、したがってPSSCHサブフレーム・プール１０２２の全帯域において常に受信動作を試みる必要がない。よって、受信端末（UE１Ｂ）の電力消費を低減できる。

　なお、eNB２は、PSSCHサブフレーム・プール１０２２内からUE１Ａ及びUE１Ｂに割り当てるサブフレームのセットを決定するために、Time Resource Pattern（TRP）indexと同様のビットマップを用いてもよい。当該ビットマップの長さは、PSSCHサブフレーム・プール１０２２と同一でもよいし、短くてもよい。例えば、当該ビットマップは、値“1”にセットされたビットに対応するサブフレームがPSSCH送信に使用できることを示し、値“0”にセットされたビットに対応するサブフレームがPSSCH送信に使用できないことを示す。

（例６）
　当該第６の例は、上述の第５の例の変形である。当該第６の例では、図１１に示されるように、低遅延モードのための第２のリソース・パターン１１２１は、第２の時間周期にわたって連続的に設定されたPSCCHサブフレーム・プール１１２２及び１１２３を含む。PSCCHサブフレーム・プール１１２２及び１１２３は、PSCCHのための周波数リソースのみによって特定されることができる。すなわち、PSCCHサブフレーム・プール１１２２及び１１２３は、PSCCHのためのリソースブロック・プールによって定義されることができる。したがって、PSCCHサブフレーム・プール１１２２及び１１２３は、PSCCH帯域と呼ぶこともできる。

　図１１の例では、eNB２は、PSCCHサブフレーム・プール１１２２及び１１２３を受信端末（UE１Ｂ）に設定する。当PSCCHサブフレーム・プール１１２２及び１１２３の設定は、低遅延モードが有効化されることを示す制御信号（e.g., RRCシグナリング）に含まれてもよい。

　一方、送信端末（UE１Ａ）は、サイドリンクで送信するべきデータが発生したことに応答して、サイドリンクリソースを要求するためにSidelink BSRをeNB２に送信し、PSSCHサブフレーム・プール１１２４及び１１２５内から選択されたサイドリンク送信リソースを示すサイドリンク・グラント（SL grant）をeNB２から受信してもよい。これに代えて、eNB２は、送信端末（UE１Ａ）によるデータ送信のためのPSSCHリソースを、RRCシグナリング（RRC Connection Reconfigurationメッセージ）において、送信端末（UE１Ａ）に予め設定してもよい。

　図１１の例では、送信端末（UE１Ａ）から受信端末（UE１Ｂ）へのデータ送信は、以下のように行われる。送信データ（１１４１）の発生に応答して、送信端末（UE１Ａ）は、スケジューリング割当情報（i.e., SCI format 0）をPSCCH上で送信する（１１４２及び１１４３）。スケジューリング割当情報１１４２及び１１４３は、データ送信のためのPSSCHリソース１１４４及び１１４５を示す。なお、上述したように、送信端末（UE１Ａ）は、送信データ（１１４１）の発生に応答して、サイドリンクリソースを要求するためにSidelink BSRをeNB２に送信し、PSSCHリソース１１４４及び１１４５の割り当てを示すサイドリンク・グラント（SL grant）をeNB２から受信してもよい。これに代えて、送信端末（UE１Ａ）は、eNB２から予め設定されたPSSCHサブフレーム・プール１１２４及び１１２５内から自発的にPSSCHリソース１１４４及び１１４５を選択してもよい。

　受信端末（UE１Ｂ）は、PSCCHサブフレーム・プール１１２２及び１１２３に対する受信動作（ブラインド・デコーディング）を行う。そして、受信端末（UE１Ｂ）は、自身宛てのスケジューリング割当情報１１４２及び１１４３のデコードに成功したことに応答して、スケジューリング割当情報１１４２及び１１４３に従ってPSSCHリソース１１４４及び１１４５において送信端末（UE１Ａ）からのデータを受信する。

　なお、図１１の例では、送信端末（UE１Ａ）は、任意のサブフレームにおいてスケジューリング割当情報１１４２及び１１４３を運ぶPUCCHを送信できる。したがって、送信端末（UE１Ａ）は、データ送信のためのPSSCHサブフレーム（subframes）のセットを指定する必要がないかもしれない。この場合、スケジューリング割当情報１１４２及び１１４３は、Time Resource Pattern（TRP）indexを包含しなくてもよい。

　当該第６の例によれば、受信端末（UE１Ｂ）は、eNB２により設定されたPSCCHサブフレーム・プール１１２２及び１１２３にのみにおいて継続的に受信動作を試みればよく、したがって、サイドリンク帯域の全てにおいて常に受信動作を試みる必要がない。よって、受信端末（UE１Ｂ）の電力消費を低減できる。

　以上の説明から理解されるように、本実施形態では、eNB２は、UE１ＡとUE１Ｂの間のD2D通信（サイドリンク送信）のために通常モードと低遅延モードのいずれが有効化されるかを示す制御信号をUE１Ａ及びUE１Ｂの少なくとも一方に送信する。そして、UE１Ａ及びUE１Ｂは、eNB２によって低遅延モードが有効化された場合に、サイドリンクでのデータ送信を低遅延モードで行うよう構成されている。したがって、本実施形態に係るUE１Ａ、UE１Ｂ、及びeNB２は、低遅延を要求する通信サービスへのD2D通信の適用を容易にすることに寄与できる。

＜第２の実施形態＞
　本実施形態では、第１の実施形態で説明されたサイドリンク送信に関する制御手順の変形例が説明される。本実施形態に係る無線通信システムの構成例は図４と同様である。本実施形態では、eNB２は、低遅延モードの有効化の要求を送信端末（UE１Ａ）又は受信端末（UE１Ｂ）から受信したことに応答して、低遅延モードの有効化を示す制御信号を送信端末（UE１Ａ）若しくは受信端末（UE１Ｂ）又は両方に送信する。

　図１２は、UE１Ａ、UE１Ｂ、及びeNB２の動作の一例（処理１２００）を示すシーケンス図である。ステップ１２０１では、送信端末（UE１Ａ）は、低遅延モードが必要とされることを示す要求信号（i.e., 低遅延モード有効化の要求）をeNB２に送信する。いくつかの実装において、送信端末（UE１Ａ）は、低遅延モードが必要とされることを自発的に判定した場合に、当該要求信号を送信してもよい。

　例えば、UE１Ａ及びUE１Ｂが車両に実装され且つV2Vアプリケーションのために使用されるケースを考える。この場合、送信端末（UE１Ａ）は、UE１Ａ及びUE１Ｂが実装された車両を含む複数の車両が互いに連携した隊列走行（platooning）を行う必要があるときに、低遅延モードが必要とされることを示す当該要求信号をeNB２に送信してもよい。隊列走行（platooning）では、各車両は、車間距離を保つために通常走行時よりも頻繁に加速（accelerate）及び減速（brake）しなければならず、前後の車両の加速及び減速操作と協調するために頻繁且つ低遅延なV2V通信が必要とされる。また、送信端末（UE１Ａ）は、UE１Ａの走行速度、又はUE１Ａと対向車（受信端末、UE１Ｂ）との間の相対速度が所定値以上であることが想定される場合、例えば高速道路を走行中である場合に、低遅延モードが必要とされることを示す当該要求信号をeNB２に送信してもよい。対向車との相対速度が大きい場合、送信端末（UE１Ａ）と対向車（受信端末、UE１Ｂ）とが通信可能である時間が相対的に短いため、低遅延なV2V通信が必要とされる。

　ステップ１２０２では、eNB２は、送信端末（UE１Ａ）からの当該要求に応答して、低遅延モードの有効化を示す制御信号を送信端末（UE１Ａ）及び受信端末（UE１Ｂ）に送信する。ステップ１２０３では、送信端末（UE１Ａ）及び受信端末（UE１Ｂ）は、低遅延モードでのサイドリンク通信（D2D通信）を実行する。

　なお、ステップ１２０２において、eNB２は、送信端末（UE１Ａ）及び受信端末（UE１Ｂ）の一方のみに制御信号を送信してもよい。この場合、制御信号を受信した一方の端末（e.g., UE１Ａ）は、低遅延モードの有効化を他方の端末（e.g., UE１Ｂ）にサイドリンク上で知らせてもよい。

　第１の実施形態で説明したように、scheduled resource allocation（sidelink transmission mode 1）の場合、ステップ１２０２の制御信号は、RRCシグナリングであってもよいし、サイドリンク・スケジューリング・グラント（DCI format 5）であってもよい。Autonomous resource selection（sidelink transmission mode 2）の場合、ステップ１２０２の制御信号は、SIB 18又はRRCシグナリングであってもよい。ステップ１２０２の制御信号は、低遅延モードの有効化を示す表示、及び低遅延モードでのサイドリンク送信のための継続性のあるリソース割り当てを示してもよい。

　さらに、図１３に示されるように、送信端末（UE１Ａ）又は受信端末（UE１Ｂ）は、低遅延モードでの通信が終了した場合に、低遅延モードの無効化（又は、低遅延モードから通常モードへの切り替え）をeNB２に要求してもよい。図１３は、UE１Ａ、UE１Ｂ、及びeNB２の動作の一例（処理１３００）を示すシーケンス図である。ステップ１３０１では、送信端末（UE１Ａ）は、低遅延モードが必要でないことを示す要求信号（i.e., 低遅延モード無効化の要求）をeNB２に送信する。ステップ１３０２では、eNB２は、送信端末（UE１Ａ）からの当該要求に応答して、低遅延モードの無効化を示す制御信号を送信端末（UE１Ａ）及び受信端末（UE１Ｂ）に送信する。eNB２は、送信端末（UE１Ａ）及び受信端末（UE１Ｂ）の一方のみに、ステップ１３０２の制御信号を送信してもよい。この場合、当該制御信号を受信した一方の端末（e.g., UE１Ａ）は、低遅延モードの無効化を他方の端末（e.g., UE１Ｂ）にサイドリンク上で知らせてもよい。

　本実施形態によれば、eNB２は、UE１Ａ又はUE１Ｂからの要求に応じて、UE１Ａ及びUE１Ｂのために低遅延モードでのサイドリンク通信を有効化できる。

＜第３の実施形態＞
　本実施形態では、第１の実施形態で説明されたサイドリンク送信に関する制御手順の変形例が説明される。本実施形態に係る無線通信システムの構成例は図４と同様である。本実施形態では、eNB２は、低遅延モードの有効化の要求を上位ネットワークから受信したことに応答して、低遅延モードの有効化を示す制御信号を送信端末（UE１Ａ）若しくは受信端末（UE１Ｂ）又は両方に送信する。

　上位ネットワークは、例えば、コアネットワーク内の制御ノード（e.g., Mobility Management Entity（MME））、ProSe function、又はアプリケーションサーバであってもよい。コアネットワーク内の制御ノード（e.g., MME）は、加入者サーバ（e.g., Home Subscriber Server（HSS））と通信し、UE１Ａ及びUE１Ｂのモビリティ管理及びセッション管理（ベアラ管理）等を行う。ProSe functionは、公衆地上移動通信ネットワーク（PLMN）を介してUE１Ａ及びUE１Ｂを含むProSe-enabled UEsと通信し、ProSeディスカバリ及びProSeダイレクト通信を支援（assist）する。ProSe functionによって提供される機能（functionality）は、例えば、（ａ）third-party applications（ProSe Application Server）との通信、（ｂ）ProSeディスカバリ及びProSeダイレクト通信のためのUEの認証、並びに（ｃ）ProSeディスカバリ及びProSeダイレクト通信のための設定情報（例えば、EPC-ProSe-User IDなど）のUEへの送信、を含む。アプリケーションサーバは、eNB２及びコアネットワークを介してUE１Ａ若しくはUE１Ｂ又は両方とアプリケーションレイヤで通信する。アプリケーションレイヤは、低遅延アプリケーション（e.g., V2V及びV2I）に関するサーバ（e.g., Traffic Safety Server（TSS）又はIntelligent Transport Systems（ITS）サーバ）であってもよい。

　図１４は、UE１Ａ、UE１Ｂ、eNB２、上位ネットワーク３の動作の一例（処理１４００）を示すシーケンス図である。ステップ１４０１では、上位ネットワーク３は、UE１Ａ及びUE１Ｂの少なくとも一方に低遅延モードが必要とされることを示す要求信号（i.e., 低遅延モード有効化の要求）をeNB２に送信する。ステップ１４０２では、eNB２は、上位ネットワーク３からの当該要求に応答して、低遅延モードの有効化を示す制御信号を送信端末（UE１Ａ）及び受信端末（UE１Ｂ）に送信する。ステップ１４０３では、送信端末（UE１Ａ）及び受信端末（UE１Ｂ）は、低遅延モードでのサイドリンク通信（D2D通信）を実行する。

　ステップ１４０２において、eNB２は、送信端末（UE１Ａ）及び受信端末（UE１Ｂ）の一方のみに制御信号を送信してもよい。この場合、制御信号を受信した一方の端末（e.g., UE１Ａ）は、低遅延モードの有効化を他方の端末（e.g., UE１Ｂ）にサイドリンク上で知らせてもよい。

　さらに、図１５に示されるように、上位ネットワーク３は、低遅延モードでの通信が終了した場合に、低遅延モードの無効化（又は、低遅延モードから通常モードへの切り替え）をeNB２に要求してもよい。図１５は、UE１Ａ、UE１Ｂ、eNB２、及び上位ネットワーク３の動作の一例（処理１５００）を示すシーケンス図である。ステップ１５０１では、上位ネットワーク３は、低遅延モードが必要でないことを示す要求信号（i.e., 低遅延モード無効化の要求）をeNB２に送信する。ステップ１５０２では、eNB２は、上位ネットワーク３からの当該要求に応答して、低遅延モードの無効化を示す制御信号を送信端末（UE１Ａ）及び受信端末（UE１Ｂ）に送信する。eNB２は、送信端末（UE１Ａ）及び受信端末（UE１Ｂ）の一方のみに、ステップ１５０２の制御信号を送信してもよい。この場合、当該制御信号を受信した一方の端末（e.g., UE１Ａ）は、低遅延モードの無効化を他方の端末（e.g., UE１Ｂ）にサイドリンク上で知らせてもよい。

　本実施形態によれば、eNB２は、上位ネットワークの要求に応じて、UE１Ａ及びUE１Ｂのために低遅延モードでのサイドリンク通信を有効化できる。

＜第４の実施形態＞
　本実施形態では、第１の実施形態で説明されたサイドリンク送信に関する制御手順の変形例が説明される。本実施形態に係る無線通信システムの構成例は図４と同様である。本実施形態では、eNB２は、低遅延モードの有効化の要否を自発的に判定する。eNB２は、低遅延モードが必要とされることを自発的に判定した場合に、低遅延モードの有効化を示す制御信号を送信端末（UE１Ａ）若しくは受信端末（UE１Ｂ）又は両方に送信する。eNB２は、低遅延モードが不要であることを自発的に判定した場合に、低遅延モードの無効化を示す制御信号を送信端末（UE１Ａ）若しくは受信端末（UE１Ｂ）又は両方に送信する。

　いくつかの実装において、eNB２は、UE１Ａ及びUE１Ｂが特定の地理的エリア内に存在する場合に、UE１Ａ及びUE１Ｂに低遅延モードでのサイドリンク通信を許可してもよい。特定の地理的エリアは、特定のセルに対応付けられてもよい。すなわち、eNB２は、自身が提供する特定のセル内にUE１Ａ及びUE１Ｂが存在する場合に、UE１Ａ及びUE１Ｂに低遅延モードでのサイドリンク通信を許可してもよい。この場合、eNB２は、特定のセル内に位置する複数のUE１が受信可能なチャネル上で、低遅延モードが許可されることを示す制御信号をブロードキャスト又はマルチキャストしてもよい。ブロードキャスト又はマルチキャストを使用することは、個別RRCシグナリングで各UE１に低遅延モードを設定する場合に比べて、制御メッセージ数（シグナリング負荷）の低減に寄与できる。

　図１６に示されるように、いくつかの実装において、eNB２は、Road Side Unit（RSU）の機能を有してもよい。RSUは、ロードサイドに設置されるエンティティであり、V2Iアプリケーションを使用する車両UE（UE１Ａ及びUE１Ｂ）との送受信を含むV2Iサービスをサポートする。図１６の例では、RSUとしてのeNB２は、交差点１６００の近くに配置される。eNB２によって提供されるセル２１は、交差点１６００を含む地理的エリアをカバーする。

　図１６の構成において、RSUとしてのeNB２は、UE１Ａ及びUE１Ｂがセル２１にハンドオーバしたことに応答して、低遅延モードの有効化を示す制御信号１６０１をUE１Ａ及びUE１Ｂに送信してもよい。

　これに代えて、RSUとしてのeNB２は、交差点１６００付近で事故又は渋滞などのイベント（アクシデント）が発生したことを検出し、当該イベントの発生に応答して、低遅延モードの有効化を示す制御信号１６０１をUE１Ａ及びUE１Ｂに送信してもよい。

　本実施形態によれば、eNB２は、自発的に、UE１Ａ及びUE１Ｂのために低遅延モードでのサイドリンク通信を有効化できる。

＜第５の実施形態＞
　本実施形態では、第１～第４の実施形態で説明されたサイドリンク送信に関する制御手順の変形例が説明される。図１７は、本実施形態に係る無線通信システムの構成例を示す図である。eNB２は、上述の第１～第４の実施形態と同様に、低遅延モードの有効化を示す制御信号１７０１を、UE１Ａ若しくはUE１Ｂ又は両方に送信する。さらに、本実施形態に係るeNB２は、低遅延モードに従うサイドリンク通信が周囲で行われていることを示す通知信号（メッセージ）１７０２を、通常モードのサイドリンク通信を行う他の無線端末１Ｃ若しくは１Ｄ又は両方に送信する。

　いくつかの実装において、通知信号１７０２は、低遅延モード用の特定の無線リソースＡ（e.g., サブフレーム・プール若しくはリソースブロック・プール又は両方）の使用が禁止されることを示してもよい。これに代えて、通知信号１７０２は、低遅延モード用の特定の無線リソースＡとは異なる無線リソースＢの使用が許可されることを示してもよい。

　本実施形態によれば、通常モードから低遅延モードへの干渉に起因する低遅延モードでのサイドリンク通信の品質劣化を抑制できる。

＜第６の実施形態＞
　本実施形態では、第１～第５の実施形態で説明されたサイドリンク送信に関する制御手順の変形例が説明される。図１８は、本実施形態に係る無線通信システムの構成例を示す図である。本実施形態に係るeNB２は、通常モードと低遅延モードのどちらが有効化されるかを示す制御信号１８０１をUEグループ１８０２に対して送信する。UEグループ１８０２は、UE１Ａ、UE１Ｂ、及びさらに他の１又は複数のUE１（e.g., UE１Ｃ及びUE１Ｄ）を含む。

　eNB２は、UEグループ１８０２内の３台以上のUE１が受信できるように制御信号１８０１を送信する。eNB２は、制御信号１８０１をブロードキャスト又はマルチキャストしてもよい。具体的には、制御信号１８０１は、Multimedia Broadcast/Multicast Service（MBMS）データを運ぶためのデータ無線ベアラ、つまりMBMS Radio Bearer（MRB）又はPoint-to-Multipoint （PTM）Radio Bearer上で送信されてもよい。これに代えて、制御信号１８０１は、System Information Block（SIB）を運ぶブロードキャスト制御チャネル（Broadcast Control Channel（BCCH））上で送信されてもよい。

　本実施形態によれば、個別RRCシグナリングで各UE１に低遅延モードを設定する場合に比べて、制御メッセージ数（シグナリング負荷）の低減に寄与できる。

　最後に、上述の複数の実施形態に係るUE１及びeNB２の構成例について説明する。図１９は、UE１の構成例を示すブロック図である。上述した送信端末としてのUE１及び受信端末としてのUE１はいずれも図１９に示される構成を有してもよい。Radio Frequency（RF）トランシーバ１９０１は、eNB２と通信するためにアナログRF信号処理を行う。RFトランシーバ１９０１により行われるアナログRF信号処理は、周波数アップコンバージョン、周波数ダウンコンバージョン、及び増幅を含む。RFトランシーバ１９０１は、アンテナ１９０２及びベースバンドプロセッサ１９０３と結合される。すなわち、RFトランシーバ１９０１は、変調シンボルデータ（又はOFDMシンボルデータ）をベースバンドプロセッサ１９０３から受信し、送信RF信号を生成し、送信RF信号をアンテナ１９０２に供給する。また、RFトランシーバ１９０１は、アンテナ１９０２によって受信された受信ＲＦ信号に基づいてベースバンド受信信号を生成し、これをベースバンドプロセッサ１９０３に供給する。

　ベースバンドプロセッサ１９０３は、無線通信のためのデジタルベースバンド信号処理（データプレーン処理）とコントロールプレーン処理を行う。デジタルベースバンド信号処理は、(a) データ圧縮／復元、(b) データのセグメンテーション／コンカテネーション、(c) 伝送フォーマット（伝送フレーム）の生成／分解、(d) 伝送路符号化／復号化、(e) 変調（シンボルマッピング）／復調、及び(f) Inverse Fast Fourier Transform（IFFT）によるOFDMシンボルデータ（ベースバンドOFDM信号）の生成などを含む。一方、コントロールプレーン処理は、レイヤ１（e.g., 送信電力制御）、レイヤ２（e.g., 無線リソース管理、及びhybrid automatic repeat request（HARQ）処理）、及びレイヤ３（e.g., アタッチ、モビリティ、及び通話管理に関するシグナリング）の通信管理を含む。

　例えば、LTEおよびLTE-Advancedの場合、ベースバンドプロセッサ１９０３によるデジタルベースバンド信号処理は、Packet Data Convergence Protocol（PDCP）レイヤ、Radio Link Control（RLC）レイヤ、MACレイヤ、およびPHYレイヤの信号処理を含んでもよい。また、ベースバンドプロセッサ１９０３によるコントロールプレーン処理は、Non-Access Stratum（NAS）プロトコル、RRCプロトコル、及びMAC CEの処理を含んでもよい。

　ベースバンドプロセッサ１９０３は、デジタルベースバンド信号処理を行うモデム・プロセッサ（e.g., Digital Signal Processor（DSP））とコントロールプレーン処理を行うプロトコルスタック・プロセッサ（e.g., Central Processing Unit（CPU）、又はMicro Processing Unit（MPU））を含んでもよい。この場合、コントロールプレーン処理を行うプロトコルスタック・プロセッサは、後述するアプリケーションプロセッサ１９０４と共通化されてもよい。

　アプリケーションプロセッサ１９０４は、CPU、MPU、マイクロプロセッサ、又はプロセッサコアとも呼ばれる。アプリケーションプロセッサ１９０４は、複数のプロセッサ（複数のプロセッサコア）を含んでもよい。アプリケーションプロセッサ１９０４は、メモリ１９０６又は図示されていないメモリから読み出されたシステムソフトウェアプログラム（Operating System（OS））及び様々なアプリケーションプログラム（例えば、通話アプリケーション、WEBブラウザ、メーラ、カメラ操作アプリケーション、音楽再生アプリケーション）を実行することによって、UE１の各種機能を実現する。

　いくつかの実装において、図１９に破線（１９０５）で示されているように、ベースバンドプロセッサ１９０３及びアプリケーションプロセッサ１９０４は、１つのチップ上に集積されてもよい。言い換えると、ベースバンドプロセッサ１９０３及びアプリケーションプロセッサ１９０４は、１つのSystem on Chip（SoC）デバイス１９０５として実装されてもよい。SoCデバイスは、システムLarge Scale Integration（LSI）またはチップセットと呼ばれることもある。

　メモリ１９０６は、揮発性メモリ若しくは不揮発性メモリ又はこれらの組合せである。メモリ１９０６は、物理的に独立した複数のメモリデバイスを含んでもよい。揮発性メモリは、例えば、Static Random Access Memory（SRAM）若しくはDynamic RAM（DRAM）又はこれらの組み合わせである。不揮発性メモリは、マスクRead Only Memory（MROM）、Electrically Erasable Programmable ROM（EEPROM）、フラッシュメモリ、若しくはハードディスクドライブ、又はこれらの任意の組合せである。例えば、メモリ１９０６は、ベースバンドプロセッサ１９０３、アプリケーションプロセッサ１９０４、及びSoC１９０５からアクセス可能な外部メモリデバイスを含んでもよい。メモリ１９０６は、ベースバンドプロセッサ１９０３内、アプリケーションプロセッサ１９０４内、又はSoC１９０５内に集積された内蔵メモリデバイスを含んでもよい。さらに、メモリ１９０６は、Universal Integrated Circuit Card（UICC）内のメモリを含んでもよい。

　メモリ１９０６は、上述の複数の実施形態で説明されたUE１による処理を行うための命令群およびデータを含むソフトウェアモジュール（コンピュータプログラム）を格納してもよい。いくつかの実装において、ベースバンドプロセッサ１９０３又はアプリケーションプロセッサ１９０４は、当該ソフトウェアモジュールをメモリ１９０６から読み出して実行することで、上述の実施形態で説明されたUE１の処理を行うよう構成されてもよい。

　図２０は、上述の実施形態に係る基地局（eNB）２の構成例を示すブロック図である。図２０を参照すると、eNB２は、RFトランシーバ２００１、ネットワークインターフェース２００３、プロセッサ２００４、及びメモリ２００５を含む。RFトランシーバ２００１は、無線端末１と通信するためにアナログRF信号処理を行う。RFトランシーバ２００１は、複数のトランシーバを含んでもよい。RFトランシーバ２００１は、アンテナ２００２及びプロセッサ２００４と結合される。RFトランシーバ２００１は、変調シンボルデータ（又はOFDMシンボルデータ）をプロセッサ２００４から受信し、送信RF信号を生成し、送信RF信号をアンテナ２００２に供給する。また、RFトランシーバ２００１は、アンテナ２００２によって受信された受信ＲＦ信号に基づいてベースバンド受信信号を生成し、これをプロセッサ２００４に供給する。

　ネットワークインターフェース２００３は、ネットワークノード（e.g., Mobility Management Entity (MME)およびServing Gateway (S-GW)）と通信するために使用される。ネットワークインターフェース２００３は、例えば、IEEE 802.3 seriesに準拠したネットワークインターフェースカード（NIC）を含んでもよい。

　プロセッサ２００４は、無線通信のためのデジタルベースバンド信号処理（データプレーン処理）とコントロールプレーン処理を行う。例えば、LTEおよびLTE-Advancedの場合、プロセッサ２００４によるデジタルベースバンド信号処理は、PDCPレイヤ、RLCレイヤ、MACレイヤ、およびPHYレイヤの信号処理を含んでもよい。また、プロセッサ２００４によるコントロールプレーン処理は、S1プロトコル、RRCプロトコル、及びMAC CEの処理を含んでもよい。

　プロセッサ２００４は、複数のプロセッサを含んでもよい。例えば、プロセッサ２００４は、デジタルベースバンド信号処理を行うモデム・プロセッサ（e.g., DSP）とコントロールプレーン処理を行うプロトコルスタック・プロセッサ（e.g., CPU又はMPU）を含んでもよい。

　メモリ２００５は、揮発性メモリ及び不揮発性メモリの組み合わせによって構成される。揮発性メモリは、例えば、SRAM若しくはDRAM又はこれらの組み合わせである。不揮発性メモリは、例えば、MROM、PROM、フラッシュメモリ、若しくはハードディスクドライブ、又はこれらの組合せである。メモリ２００５は、プロセッサ２００４から離れて配置されたストレージを含んでもよい。この場合、プロセッサ２００４は、ネットワークインターフェース２００３又は図示されていないI/Oインタフェースを介してメモリ２００５にアクセスしてもよい。

　メモリ２００５は、上述の複数の実施形態で説明されたeNB２による処理を行うための命令群およびデータを含むソフトウェアモジュール（コンピュータプログラム）を格納してもよい。いくつかの実装において、プロセッサ２００４は、当該ソフトウェアモジュールをメモリ２００５から読み出して実行することで、上述の実施形態で説明されたeNB２の処理を行うよう構成されてもよい。

　図１９及び図２０を用いて説明したように、上述の実施形態に係るUE１及びeNB２が有するプロセッサの各々は、図面を用いて説明されたアルゴリズムをコンピュータに行わせるための命令群を含む１又は複数のプログラムを実行する。このプログラムは、様々なタイプの非一時的なコンピュータ可読媒体（non-transitory computer readable medium）を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（tangible storage medium）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば光磁気ディスク）、Compact Disc Read Only Memory（CD-ROM）、CD-R、CD-R/W、半導体メモリ（例えば、マスクROM、Programmable ROM（PROM）、Erasable PROM（EPROM）、フラッシュROM、Random Access Memory（RAM））を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（transitory computer readable medium）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。

＜その他の実施形態＞
　上述の実施形態は、各々独立に実施されてもよいし、適宜組み合わせて実施されてもよい。

　上述の実施形態において、低遅延モードの有効化は、通常モードのサイドリンク制御周期（第１の時間周期）又は通常モードで使用されるリソース・パターンの無効化を示してもよい。

　上述の実施形態で説明されたeNB２により行われる処理及び動作は、Cloud Radio Access Network（C-RAN）アーキテクチャに含まれるDigital Unit（DU）又はDU及びRadio Unit（RU）の組み合せによって提供されてもよい。C-RANは、Centralized RANと呼ばれることもある。DUは、Baseband Unit（BBU）とも呼ばれる。RUは、Remote Radio Head（RRH）又はRemote Radio Equipment（RRE）とも呼ばれる。すなわち、上述の実施形態で説明されたeNB２によって行われる処理及び動作は、１又は複数のネットワーク装置（Radio Access Network（RAN）ノード）によって提供されてもよい。

　上述の実施形態は、LTE-Advanced 及びその改良に限定されるものではなく、他のモバイル通信ネットワーク又はシステムでのD2D通信に適用されてもよい。

　さらに、上述した実施形態は本件発明者により得られた技術思想の適用に関する例に過ぎない。すなわち、当該技術思想は、上述した実施形態のみに限定されるものではなく、種々の変更が可能であることは勿論である。

　例えば、上記の実施形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。

（付記１）
　メモリと、
　少なくとも１つのプロセッサと、
を備え、
　前記少なくとも１つのプロセッサは、第１のdevice-to-device（D2D）送信モード及び第２のD2D送信モードのいずれが有効化されるかを示す指示（indication）を包含する第１の制御信号をD2D送信端末及びD2D受信端末の少なくとも一方に送信するよう構成され、
　前記第１のD2D送信モードは、第１の時間周期で繰り返される第１のリソース・パターンに従い、
　各第１のリソース・パターンは、データ送信のためのリソース割り当てを示す第１のD2D制御情報を前記D2D送信端末から前記D2D受信端末に送信するために使用される制御チャネル・サブフレーム・プールと、前記第１のD2D制御情報に従う前記D2D送信端末から前記D2D受信端末へのデータ送信のために使用されるデータチャネル・サブフレーム・プールを含み、
　前記第２のD2D送信モードは、前記第１の時間周期と同一又は異なる第２の時間周期で繰り返される第２のリソース・パターンに従い、
　各第２のリソース・パターンは、前記D2D送信端末から前記D2D受信端末へのデータ送信のために使用されるデータチャネル・サブフレーム・プールを含み、
　各第２のリソース・パターンは、
（ａ）１つの第２のリソース・パターン内又は隣接する２つの第２のリソース・パターンにおいて、前記第１のD2D制御情報の送信に使用される複数の制御チャネル・サブフレーム・プールが前記第１の時間周期より短い間隔で現れる、
（ｂ）複数の連続する第２の時間周期でのデータ送信のためのリソース割り当てを示す第２のD2D制御情報を送信するために使用される制御チャネル・サブフレーム・プールを含む、又は
（ｃ）前記第１のD2D制御情報又は前記第２のD2D制御情報の送信に使用される制御チャネル・サブフレーム・プールを含まない、
よう定義されている、
ネットワーク装置。

（付記２）
　前記少なくとも１つのプロセッサは、前記第２のD2D送信モードを有効化する場合に、複数の第２のリソース・パターンにわたって有効な継続性のあるリソース割り当てを前記D2D送信端末及び前記D2D受信端末の少なくとも一方に通知するよう構成されている、
付記１に記載のネットワーク装置。

（付記３）
　前記第２のD2D送信モードを有効化するための前記第１の制御信号は、前記指示および前記継続性のあるリソース割り当てを共に包含するD2Dグラントメッセージであり、
　前記少なくとも１つのプロセッサは、前記D2Dグラントメッセージを前記D2D送信端末に送信するよう構成されている、
付記２に記載のネットワーク装置。

（付記４）
　前記第２のD2D送信モードを有効化するための前記第１の制御信号は、前記指示および前記継続性のあるリソース割り当てを共に包含するRadio Resource Control（RRC）メッセージであり、
　前記少なくとも１つのプロセッサは、前記RRCメッセージを前記D2D送信端末及び前記D2D受信端末に送信するよう構成されている、
付記２に記載のネットワーク装置。

（付記５）
　各第２のリソース・パターンは、前記制御チャネル・サブフレーム・プールを含まない、
付記２～４のいずれか１項に記載のネットワーク装置。

（付記６）
　前記第２の時間周期は、前記第１の時間周期より短い、
付記１に記載のネットワーク装置。

（付記７）
　前記第２のD2D送信モードを有効化するための前記第１の制御信号は、前記第１の時間周期又は前記第１のリソース・パターンの無効化を示す、
付記１～６のいずれか１項に記載のネットワーク装置。

（付記８）
　前記第２のD2D送信モードを有効化するための前記第１の制御信号は、前記ネットワーク装置によって提供される特定のセルにおいて、複数の無線端末が受信可能なチャネル上でブロードキャスト又はマルチキャストされる、
付記１、２、又は７に記載のネットワーク装置。

（付記９）
　前記少なくとも１つのプロセッサは、前記第２のD2D送信モードが必要とされることを示す要求を前記D2D送信端末から受信したことに応答して、前記第２のD2D送信モードを有効化するための前記第１の制御信号を前記D2D送信端末に送信するよう構成されている、
付記１～７のいずれか１項に記載のネットワーク装置。

（付記１０）
　前記少なくとも１つのプロセッサは、前記第２のD2D送信モードが必要でないことを示す通知を前記D2D送信端末から受信したことに応答して、前記第２のD2D送信モードから前記第１のD2D送信モードへの切り替えをトリガーする指示を包含する第２の制御信号を前記D2D送信端末に送信するよう構成されている、
付記１～７及び９のいずれか１項に記載のネットワーク装置。

（付記１１）
　前記少なくとも１つのプロセッサは、前記第２のD2D送信モードが必要とされることを示す要求を上位ネットワークから受信したことに応答して、前記第２のD2D送信モードを有効化するための前記第１の制御信号を前記D2D送信端末及び前記D2D受信端末の少なくとも一方に送信するよう構成されている、
付記１～７のいずれか１項に記載のネットワーク装置。

（付記１２）
　前記少なくとも１つのプロセッサは、前記第２のD2D送信モードが必要でないことを示す通知を上位ネットワークから受信したことに応答して、前記第２のD2D送信モードから前記第１のD2D送信モードへの切り替えをトリガーする指示を包含する第２の制御信号を前記D2D送信端末及び前記D2D受信端末の少なくとも一方に送信するよう構成されている、
付記１～７及び１１のいずれか１項に記載のネットワーク装置。

（付記１３）
　前記少なくとも１つのプロセッサは、前記第２のD2D送信モードが必要とされることを自発的に判定した場合に、前記第２のD2D送信モードを有効化するための前記第１の制御信号を前記D2D送信端末及び前記D2D受信端末の少なくとも一方に送信するよう構成されている、
付記１～７のいずれか１項に記載のネットワーク装置。

（付記１４）
　前記少なくとも１つのプロセッサは、前記第２のD2D送信モードが必要でないことを自発的に判定した場合に、前記第２のD2D送信モードから前記第１のD2D送信モードへの切り替えをトリガーする指示を包含する第２の制御信号を前記D2D送信端末及び前記D2D受信端末の少なくとも一方に送信するよう構成されている、
付記１～７及び１３のいずれか１項に記載のネットワーク装置。

（付記１５）
　前記少なくとも１つのプロセッサは、前記D2D送信端末と前記D2D受信端末の間のD2D通信が必要とする要求遅延に応じて、前記D2D通信に対して前記第２のD2D送信モードを有効化するか否かを決定するよう構成されている、
付記１～７のいずれか１項に記載のネットワーク装置。

（付記１６）
　前記少なくとも１つのプロセッサは、前記D2D送信端末と前記D2D受信端末の間の特定のD2D通信に対して前記第２のD2D送信モードを有効化する場合に、前記第２のD2D送信モードに従う通信が周囲で行われていることを示す制御メッセージを他のD2D端末に送信するよう構成されている、
付記１～１５のいずれか１項に記載のネットワーク装置。

（付記１７）
　前記制御メッセージは、前記特定のD2D通信に使用される無線リソースの前記他のD2D端末による使用が禁止されることを示す、
付記１６に記載のネットワーク装置。

（付記１８）
　前記少なくとも１つのプロセッサは、前記D2D送信端末、前記D2D受信端末、及び他のD2D端末を含む３つ以上の端末から成るD2D端末グループに対して前記第１の制御信号を送信するよう構成されている、
付記１～１７のいずれか１項に記載のネットワーク装置。

（付記１９）
　ネットワーク装置における方法であって、
　第１のdevice-to-device（D2D）送信モード及び第２のD2D送信モードのいずれが有効化されるかを示す指示を包含する第１の制御信号をD2D送信端末及びD2D受信端末の少なくとも一方に送信することを備え、
　前記第１のD2D送信モードは、第１の時間周期で繰り返される第１のリソース・パターンに従い、
　各第１のリソース・パターンは、データ送信のためのリソース割り当てを示す第１のD2D制御情報を前記D2D送信端末から前記D2D受信端末に送信するために使用される制御チャネル・サブフレーム・プールと、前記第１のD2D制御情報に従う前記D2D送信端末から前記D2D受信端末へのデータ送信のために使用されるデータチャネル・サブフレーム・プールを含み、
　前記第２のD2D送信モードは、前記第１の時間周期と同一又は異なる第２の時間周期で繰り返される第２のリソース・パターンに従い、
　各第２のリソース・パターンは、前記D2D送信端末から前記D2D受信端末へのデータ送信のために使用されるデータチャネル・サブフレーム・プールを含み、
　各第２のリソース・パターンは、
（ａ）１つの第２のリソース・パターン内又は隣接する２つの第２のリソース・パターンにおいて、前記第１のD2D制御情報の送信に使用される複数の制御チャネル・サブフレーム・プールが前記第１の時間周期より短い間隔で現れる、
（ｂ）複数の連続する第２の時間周期でのデータ送信のためのリソース割り当てを示す第２のD2D制御情報を送信するために使用される制御チャネル・サブフレーム・プールを含む、又は
（ｃ）前記第１のD2D制御情報又は前記第２のD2D制御情報の送信に使用される制御チャネル・サブフレーム・プールを含まない、
よう定義されている、
方法。

（付記２０）
　ネットワーク装置における方法をコンピュータに行わせるためのプログラムを格納した非一時的なコンピュータ可読媒体であって、
　前記方法は、第１のdevice-to-device（D2D）送信モード及び第２のD2D送信モードのいずれが有効化されるかを示す指示を包含する第１の制御信号をD2D送信端末及びD2D受信端末の少なくとも一方に送信することを備え、
　前記第１のD2D送信モードは、第１の時間周期で繰り返される第１のリソース・パターンに従い、
　各第１のリソース・パターンは、データ送信のためのリソース割り当てを示す第１のD2D制御情報を前記D2D送信端末から前記D2D受信端末に送信するために使用される少なくとも１つの制御チャネル・サブフレーム・プールと、前記第１のD2D制御情報に従う前記D2D送信端末から前記D2D受信端末へのデータ送信のために使用されるデータチャネル・サブフレーム・プールを含み、
　前記第２のD2D送信モードは、前記第１の時間周期と同一又は異なる第２の時間周期で繰り返される第２のリソース・パターンに従い、
　各第２のリソース・パターンは、前記D2D送信端末から前記D2D受信端末へのデータ送信のために使用されるデータチャネル・サブフレーム・プールを含み、
　各第２のリソース・パターンは、
（ａ）１つの第２のリソース・パターン内又は隣接する２つの第２のリソース・パターンにおいて、前記第１のD2D制御情報の送信に使用される複数の制御チャネル・サブフレーム・プールが前記第１の時間周期より短い間隔で現れる、
（ｂ）複数の連続する第２の時間周期でのデータ送信のためのリソース割り当てを示す第２のD2D制御情報を送信するために使用される制御チャネル・サブフレーム・プールを含む、又は
（ｃ）前記第１のD2D制御情報又は前記第２のD2D制御情報の送信に使用される制御チャネル・サブフレーム・プールを含まない、
よう定義されている、
非一時的なコンピュータ可読媒体。

（付記２１）
　メモリと、
　少なくとも１つのプロセッサと、
を備え、
　前記少なくとも１つのプロセッサは、第１のdevice-to-device（D2D）送信モード及び第２のD2D送信モードのいずれが有効化されるかを示す指示を含む第１の制御信号を受信し、且つ前記第１の制御信号の受信に応答して前記第２のD2D送信モードに従うD2D通信を行うよう構成され、
　前記第１のD2D送信モードは、第１の時間周期で繰り返される第１のリソース・パターンに従い、
　各第１のリソース・パターンは、データ送信のためのリソース割り当てを示す第１のD2D制御情報をD2D送信端末からD2D受信端末に送信するために使用される制御チャネル・サブフレーム・プールと、前記第１のD2D制御情報に従う前記D2D送信端末から前記D2D受信端末へのデータ送信のために使用されるデータチャネル・サブフレーム・プールを含み、
　前記第２のD2D送信モードは、前記第１の時間周期と同一又は異なる第２の時間周期で繰り返される第２のリソース・パターンに従い、
　各第２のリソース・パターンは、前記D2D送信端末から前記D2D受信端末へのデータ送信のために使用されるデータチャネル・サブフレーム・プールを含み、
　各第２のリソース・パターンは、
（ａ）１つの第２のリソース・パターン内又は隣接する２つの第２のリソース・パターンにおいて、前記第１のD2D制御情報の送信に使用される複数の制御チャネル・サブフレーム・プールが前記第１の時間周期より短い間隔で現れる、
（ｂ）複数の連続する第２の時間周期でのデータ送信のためのリソース割り当てを示す第２のD2D制御情報を送信するために使用される制御チャネル・サブフレーム・プールを含む、又は
（ｃ）前記第１のD2D制御情報又は前記第２のD2D制御情報の送信に使用される制御チャネル・サブフレーム・プールを含まない、
よう定義されている、
無線端末。

（付記２２）
　前記少なくとも１つのプロセッサは、前記第２のD2D送信モードが有効化される場合に、複数の第２のリソース・パターンにわたって有効な継続性のあるリソース割り当てをネットワーク装置から受信するよう構成されている、
付記２１に記載の無線端末。

（付記２３）
　前記第２のD2D送信モードを有効化するための前記第１の制御信号は、前記指示および前記継続性のあるリソース割り当てを共に包含するD2Dグラントメッセージである、
付記２２に記載の無線端末。

（付記２４）
　前記無線端末は、前記D2D送信端末であり、
　前記少なくとも１つのプロセッサは、前記D2Dグラントメッセージの受信に応答して、前記第２のD2D制御情報を前記D2D受信端末に送信するよう構成されている、
付記２３に記載の無線端末。

（付記２５）
　前記第２のD2D送信モードを有効化するための前記第１の制御信号は、前記指示および前記継続性のあるリソース割り当てを共に包含するRadio Resource Control（RRC）メッセージである、
付記２２に記載の無線端末。

（付記２６）
　各第２のリソース・パターンは、前記制御チャネル・サブフレーム・プールを含まない、
付記２２、２３、又は２５に記載の無線端末。

（付記２７）
　前記第２の時間周期は、前記第１の時間周期より短い、
付記２１に記載の無線端末。

（付記２８）
　前記第２のD2D送信モードを有効化するための前記第１の制御信号は、前記第１の時間周期又は前記第１のリソース・パターンの無効化を示す、
付記２１～２７のいずれか１項に記載の無線端末。

（付記２９）
　前記少なくとも１つのプロセッサは、前記第２のD2D送信モードを有効化するための前記第１の制御信号を受信したことに応答して、前記第２のD2D送信モードの有効化を示す制御メッセージを他のD2D端末に送信するよう構成されている、
付記２１～２８のいずれか１項に記載の無線端末。

（付記３０）
　無線端末における方法であって、
　第１のdevice-to-device（D2D）送信モード及び第２のD2D送信モードのいずれが有効化されるかを示す指示を含む第１の制御信号を受信すること、及び
　前記第１の制御信号の受信に応答して前記第２のD2D送信モードに従うD2D通信を行うこと、
を備え、
　前記第１のD2D送信モードは、第１の時間周期で繰り返される第１のリソース・パターンに従い、
　各第１のリソース・パターンは、データ送信のためのリソース割り当てを示す第１のD2D制御情報をD2D送信端末からD2D受信端末に送信するために使用される制御チャネル・サブフレーム・プールと、前記第１のD2D制御情報に従う前記D2D送信端末から前記D2D受信端末へのデータ送信のために使用されるデータチャネル・サブフレーム・プールを含み、
　前記第２のD2D送信モードは、前記第１の時間周期と同一又は異なる第２の時間周期で繰り返される第２のリソース・パターンに従い、
　各第２のリソース・パターンは、前記D2D送信端末から前記D2D受信端末へのデータ送信のために使用されるデータチャネル・サブフレーム・プールを含み、
　各第２のリソース・パターンは、
（ａ）１つの第２のリソース・パターン内又は隣接する２つの第２のリソース・パターンにおいて、前記第１のD2D制御情報の送信に使用される複数の制御チャネル・サブフレーム・プールが前記第１の時間周期より短い間隔で現れる、
（ｂ）複数の連続する第２の時間周期でのデータ送信のためのリソース割り当てを示す第２のD2D制御情報を送信するために使用される制御チャネル・サブフレーム・プールを含む、又は
（ｃ）前記第１のD2D制御情報又は前記第２のD2D制御情報の送信に使用される制御チャネル・サブフレーム・プールを含まない、
よう定義されている、
方法。

（付記３１）
　無線端末における方法をコンピュータに行わせるためのプログラムを格納した非一時的なコンピュータ可読媒体であって、
　前記方法は、
　第１のdevice-to-device（D2D）送信モード及び第２のD2D送信モードのいずれが有効化されるかを示す指示を含む第１の制御信号を受信すること、及び
　前記第１の制御信号の受信に応答して前記第２のD2D送信モードに従うD2D通信を行うこと、
を備え、
　前記第１のD2D送信モードは、第１の時間周期で繰り返される第１のリソース・パターンに従い、
　各第１のリソース・パターンは、データ送信のためのリソース割り当てを示す第１のD2D制御情報をD2D送信端末からD2D受信端末に送信するために使用される制御チャネル・サブフレーム・プールと、前記第１のD2D制御情報に従う前記D2D送信端末から前記D2D受信端末へのデータ送信のために使用されるデータチャネル・サブフレーム・プールを含み、
　前記第２のD2D送信モードは、前記第１の時間周期と同一又は異なる第２の時間周期で繰り返される第２のリソース・パターンに従い、
　各第２のリソース・パターンは、前記D2D送信端末から前記D2D受信端末へのデータ送信のために使用されるデータチャネル・サブフレーム・プールを含み、
　各第２のリソース・パターンは、
（ａ）１つの第２のリソース・パターン内又は隣接する２つの第２のリソース・パターンにおいて、前記第１のD2D制御情報の送信に使用される複数の制御チャネル・サブフレーム・プールが前記第１の時間周期より短い間隔で現れる、
（ｂ）複数の連続する第２の時間周期でのデータ送信のためのリソース割り当てを示す第２のD2D制御情報を送信するために使用される制御チャネル・サブフレーム・プールを含む、又は
（ｃ）前記第１のD2D制御情報又は前記第２のD2D制御情報の送信に使用される制御チャネル・サブフレーム・プールを含まない、
よう定義されている、
非一時的なコンピュータ可読媒体。

　この出願は、２０１６年１月２５日に出願された日本出願特願２０１６－０１１６８５を基礎とする優先権を主張し、その開示の全てをここに取り込む。

１　UE
２　eNB
３　上位ネットワーク
１９１　radio frequency（RF）トランシーバ
１９０３　ベースバンドプロセッサ
１９０４　アプリケーションプロセッサ
１９０６　メモリ
２００１　RFトランシーバ
２００４　プロセッサ
２００５　メモリ

Claims

　メモリと、
　少なくとも１つのプロセッサと、
を備え、
　前記少なくとも１つのプロセッサは、第１のdevice-to-device（D2D）送信モード及び第２のD2D送信モードのいずれが有効化されるかを示す指示（indication）を包含する第１の制御信号をD2D送信端末及びD2D受信端末の少なくとも一方に送信するよう構成され、
　前記第１のD2D送信モードは、第１の時間周期で繰り返される第１のリソース・パターンに従い、
　各第１のリソース・パターンは、データ送信のためのリソース割り当てを示す第１のD2D制御情報を前記D2D送信端末から前記D2D受信端末に送信するために使用される制御チャネル・サブフレーム・プールと、前記第１のD2D制御情報に従う前記D2D送信端末から前記D2D受信端末へのデータ送信のために使用されるデータチャネル・サブフレーム・プールを含み、
　前記第２のD2D送信モードは、前記第１の時間周期と同一又は異なる第２の時間周期で繰り返される第２のリソース・パターンに従い、
　各第２のリソース・パターンは、前記D2D送信端末から前記D2D受信端末へのデータ送信のために使用されるデータチャネル・サブフレーム・プールを含み、
　各第２のリソース・パターンは、
（ａ）１つの第２のリソース・パターン内又は隣接する２つの第２のリソース・パターンにおいて、前記第１のD2D制御情報の送信に使用される複数の制御チャネル・サブフレーム・プールが前記第１の時間周期より短い間隔で現れる、
（ｂ）複数の連続する第２の時間周期でのデータ送信のためのリソース割り当てを示す第２のD2D制御情報を送信するために使用される制御チャネル・サブフレーム・プールを含む、又は
（ｃ）前記第１のD2D制御情報又は前記第２のD2D制御情報の送信に使用される制御チャネル・サブフレーム・プールを含まない、
よう定義されている、
ネットワーク装置。
　前記少なくとも１つのプロセッサは、前記第２のD2D送信モードを有効化する場合に、複数の第２のリソース・パターンにわたって有効な継続性のあるリソース割り当てを前記D2D送信端末及び前記D2D受信端末の少なくとも一方に通知するよう構成されている、
請求項１に記載のネットワーク装置。
　前記第２のD2D送信モードを有効化するための前記第１の制御信号は、前記指示および前記継続性のあるリソース割り当てを共に包含するD2Dグラントメッセージであり、
　前記少なくとも１つのプロセッサは、前記D2Dグラントメッセージを前記D2D送信端末に送信するよう構成されている、
請求項２に記載のネットワーク装置。
　前記第２のD2D送信モードを有効化するための前記第１の制御信号は、前記指示および前記継続性のあるリソース割り当てを共に包含するRadio Resource Control（RRC）メッセージであり、
　前記少なくとも１つのプロセッサは、前記RRCメッセージを前記D2D送信端末及び前記D2D受信端末に送信するよう構成されている、
請求項２に記載のネットワーク装置。
　各第２のリソース・パターンは、前記制御チャネル・サブフレーム・プールを含まない、
請求項２～４のいずれか１項に記載のネットワーク装置。
　前記第２の時間周期は、前記第１の時間周期より短い、
請求項１に記載のネットワーク装置。
　前記第２のD2D送信モードを有効化するための前記第１の制御信号は、前記第１の時間周期又は前記第１のリソース・パターンの無効化を示す、
請求項１～６のいずれか１項に記載のネットワーク装置。
　前記第２のD2D送信モードを有効化するための前記第１の制御信号は、前記ネットワーク装置によって提供される特定のセルにおいて、複数の無線端末が受信可能なチャネル上でブロードキャスト又はマルチキャストされる、
請求項１、２、又は７に記載のネットワーク装置。
　前記少なくとも１つのプロセッサは、前記第２のD2D送信モードが必要とされることを示す要求を前記D2D送信端末から受信したことに応答して、前記第２のD2D送信モードを有効化するための前記第１の制御信号を前記D2D送信端末に送信するよう構成されている、
請求項１～７のいずれか１項に記載のネットワーク装置。
　前記少なくとも１つのプロセッサは、前記第２のD2D送信モードが必要でないことを示す通知を前記D2D送信端末から受信したことに応答して、前記第２のD2D送信モードから前記第１のD2D送信モードへの切り替えをトリガーする指示を包含する第２の制御信号を前記D2D送信端末に送信するよう構成されている、
請求項１～７及び９のいずれか１項に記載のネットワーク装置。
　前記少なくとも１つのプロセッサは、前記第２のD2D送信モードが必要とされることを示す要求を上位ネットワークから受信したことに応答して、前記第２のD2D送信モードを有効化するための前記第１の制御信号を前記D2D送信端末及び前記D2D受信端末の少なくとも一方に送信するよう構成されている、
請求項１～７のいずれか１項に記載のネットワーク装置。
　前記少なくとも１つのプロセッサは、前記第２のD2D送信モードが必要でないことを示す通知を上位ネットワークから受信したことに応答して、前記第２のD2D送信モードから前記第１のD2D送信モードへの切り替えをトリガーする指示を包含する第２の制御信号を前記D2D送信端末及び前記D2D受信端末の少なくとも一方に送信するよう構成されている、
請求項１～７及び１１のいずれか１項に記載のネットワーク装置。
　前記少なくとも１つのプロセッサは、前記第２のD2D送信モードが必要とされることを自発的に判定した場合に、前記第２のD2D送信モードを有効化するための前記第１の制御信号を前記D2D送信端末及び前記D2D受信端末の少なくとも一方に送信するよう構成されている、
請求項１～７のいずれか１項に記載のネットワーク装置。
　前記少なくとも１つのプロセッサは、前記第２のD2D送信モードが必要でないことを自発的に判定した場合に、前記第２のD2D送信モードから前記第１のD2D送信モードへの切り替えをトリガーする指示を包含する第２の制御信号を前記D2D送信端末及び前記D2D受信端末の少なくとも一方に送信するよう構成されている、
請求項１～７及び１３のいずれか１項に記載のネットワーク装置。
　前記少なくとも１つのプロセッサは、前記D2D送信端末と前記D2D受信端末の間のD2D通信が必要とする要求遅延に応じて、前記D2D通信に対して前記第２のD2D送信モードを有効化するか否かを決定するよう構成されている、
請求項１～７のいずれか１項に記載のネットワーク装置。
　前記少なくとも１つのプロセッサは、前記D2D送信端末と前記D2D受信端末の間の特定のD2D通信に対して前記第２のD2D送信モードを有効化する場合に、前記第２のD2D送信モードに従う通信が周囲で行われていることを示す制御メッセージを他のD2D端末に送信するよう構成されている、
請求項１～１５のいずれか１項に記載のネットワーク装置。
　前記制御メッセージは、前記特定のD2D通信に使用される無線リソースの前記他のD2D端末による使用が禁止されることを示す、
請求項１６に記載のネットワーク装置。
　前記少なくとも１つのプロセッサは、前記D2D送信端末、前記D2D受信端末、及び他のD2D端末を含む３つ以上の端末から成るD2D端末グループに対して前記第１の制御信号を送信するよう構成されている、
請求項１～１７のいずれか１項に記載のネットワーク装置。
　ネットワーク装置における方法であって、
　第１のdevice-to-device（D2D）送信モード及び第２のD2D送信モードのいずれが有効化されるかを示す指示を包含する第１の制御信号をD2D送信端末及びD2D受信端末の少なくとも一方に送信することを備え、
　前記第１のD2D送信モードは、第１の時間周期で繰り返される第１のリソース・パターンに従い、
　各第１のリソース・パターンは、データ送信のためのリソース割り当てを示す第１のD2D制御情報を前記D2D送信端末から前記D2D受信端末に送信するために使用される制御チャネル・サブフレーム・プールと、前記第１のD2D制御情報に従う前記D2D送信端末から前記D2D受信端末へのデータ送信のために使用されるデータチャネル・サブフレーム・プールを含み、
　前記第２のD2D送信モードは、前記第１の時間周期と同一又は異なる第２の時間周期で繰り返される第２のリソース・パターンに従い、
　各第２のリソース・パターンは、前記D2D送信端末から前記D2D受信端末へのデータ送信のために使用されるデータチャネル・サブフレーム・プールを含み、
　各第２のリソース・パターンは、
（ａ）１つの第２のリソース・パターン内又は隣接する２つの第２のリソース・パターンにおいて、前記第１のD2D制御情報の送信に使用される複数の制御チャネル・サブフレーム・プールが前記第１の時間周期より短い間隔で現れる、
（ｂ）複数の連続する第２の時間周期でのデータ送信のためのリソース割り当てを示す第２のD2D制御情報を送信するために使用される制御チャネル・サブフレーム・プールを含む、又は
（ｃ）前記第１のD2D制御情報又は前記第２のD2D制御情報の送信に使用される制御チャネル・サブフレーム・プールを含まない、
よう定義されている、
方法。
　ネットワーク装置における方法をコンピュータに行わせるためのプログラムを格納した非一時的なコンピュータ可読媒体であって、
　前記方法は、第１のdevice-to-device（D2D）送信モード及び第２のD2D送信モードのいずれが有効化されるかを示す指示を包含する第１の制御信号をD2D送信端末及びD2D受信端末の少なくとも一方に送信することを備え、
　前記第１のD2D送信モードは、第１の時間周期で繰り返される第１のリソース・パターンに従い、
　各第１のリソース・パターンは、データ送信のためのリソース割り当てを示す第１のD2D制御情報を前記D2D送信端末から前記D2D受信端末に送信するために使用される少なくとも１つの制御チャネル・サブフレーム・プールと、前記第１のD2D制御情報に従う前記D2D送信端末から前記D2D受信端末へのデータ送信のために使用されるデータチャネル・サブフレーム・プールを含み、
　前記第２のD2D送信モードは、前記第１の時間周期と同一又は異なる第２の時間周期で繰り返される第２のリソース・パターンに従い、
　各第２のリソース・パターンは、前記D2D送信端末から前記D2D受信端末へのデータ送信のために使用されるデータチャネル・サブフレーム・プールを含み、
　各第２のリソース・パターンは、
（ａ）１つの第２のリソース・パターン内又は隣接する２つの第２のリソース・パターンにおいて、前記第１のD2D制御情報の送信に使用される複数の制御チャネル・サブフレーム・プールが前記第１の時間周期より短い間隔で現れる、
（ｂ）複数の連続する第２の時間周期でのデータ送信のためのリソース割り当てを示す第２のD2D制御情報を送信するために使用される制御チャネル・サブフレーム・プールを含む、又は
（ｃ）前記第１のD2D制御情報又は前記第２のD2D制御情報の送信に使用される制御チャネル・サブフレーム・プールを含まない、
よう定義されている、
非一時的なコンピュータ可読媒体。
　メモリと、
　少なくとも１つのプロセッサと、
を備え、
　前記少なくとも１つのプロセッサは、第１のdevice-to-device（D2D）送信モード及び第２のD2D送信モードのいずれが有効化されるかを示す指示を含む第１の制御信号を受信し、且つ前記第１の制御信号の受信に応答して前記第２のD2D送信モードに従うD2D通信を行うよう構成され、
　前記第１のD2D送信モードは、第１の時間周期で繰り返される第１のリソース・パターンに従い、
　各第１のリソース・パターンは、データ送信のためのリソース割り当てを示す第１のD2D制御情報をD2D送信端末からD2D受信端末に送信するために使用される制御チャネル・サブフレーム・プールと、前記第１のD2D制御情報に従う前記D2D送信端末から前記D2D受信端末へのデータ送信のために使用されるデータチャネル・サブフレーム・プールを含み、
　前記第２のD2D送信モードは、前記第１の時間周期と同一又は異なる第２の時間周期で繰り返される第２のリソース・パターンに従い、
　各第２のリソース・パターンは、前記D2D送信端末から前記D2D受信端末へのデータ送信のために使用されるデータチャネル・サブフレーム・プールを含み、
　各第２のリソース・パターンは、
（ａ）１つの第２のリソース・パターン内又は隣接する２つの第２のリソース・パターンにおいて、前記第１のD2D制御情報の送信に使用される複数の制御チャネル・サブフレーム・プールが前記第１の時間周期より短い間隔で現れる、
（ｂ）複数の連続する第２の時間周期でのデータ送信のためのリソース割り当てを示す第２のD2D制御情報を送信するために使用される制御チャネル・サブフレーム・プールを含む、又は
（ｃ）前記第１のD2D制御情報又は前記第２のD2D制御情報の送信に使用される制御チャネル・サブフレーム・プールを含まない、
よう定義されている、
無線端末。
　前記少なくとも１つのプロセッサは、前記第２のD2D送信モードが有効化される場合に、複数の第２のリソース・パターンにわたって有効な継続性のあるリソース割り当てをネットワーク装置から受信するよう構成されている、
請求項２１に記載の無線端末。
　前記第２のD2D送信モードを有効化するための前記第１の制御信号は、前記指示および前記継続性のあるリソース割り当てを共に包含するD2Dグラントメッセージである、
請求項２２に記載の無線端末。
　前記無線端末は、前記D2D送信端末であり、
　前記少なくとも１つのプロセッサは、前記D2Dグラントメッセージの受信に応答して、前記第２のD2D制御情報を前記D2D受信端末に送信するよう構成されている、
請求項２３に記載の無線端末。
　前記第２のD2D送信モードを有効化するための前記第１の制御信号は、前記指示および前記継続性のあるリソース割り当てを共に包含するRadio Resource Control（RRC）メッセージである、
請求項２２に記載の無線端末。
　各第２のリソース・パターンは、前記制御チャネル・サブフレーム・プールを含まない、
請求項２２、２３、又は２５に記載の無線端末。
　前記第２の時間周期は、前記第１の時間周期より短い、
請求項２１に記載の無線端末。
　前記第２のD2D送信モードを有効化するための前記第１の制御信号は、前記第１の時間周期又は前記第１のリソース・パターンの無効化を示す、
請求項２１～２７のいずれか１項に記載の無線端末。
　前記少なくとも１つのプロセッサは、前記第２のD2D送信モードを有効化するための前記第１の制御信号を受信したことに応答して、前記第２のD2D送信モードの有効化を示す制御メッセージを他のD2D端末に送信するよう構成されている、
請求項２１～２８のいずれか１項に記載の無線端末。
　無線端末における方法であって、
　第１のdevice-to-device（D2D）送信モード及び第２のD2D送信モードのいずれが有効化されるかを示す指示を含む第１の制御信号を受信すること、及び
　前記第１の制御信号の受信に応答して前記第２のD2D送信モードに従うD2D通信を行うこと、
を備え、
　前記第１のD2D送信モードは、第１の時間周期で繰り返される第１のリソース・パターンに従い、
　各第１のリソース・パターンは、データ送信のためのリソース割り当てを示す第１のD2D制御情報をD2D送信端末からD2D受信端末に送信するために使用される制御チャネル・サブフレーム・プールと、前記第１のD2D制御情報に従う前記D2D送信端末から前記D2D受信端末へのデータ送信のために使用されるデータチャネル・サブフレーム・プールを含み、
　前記第２のD2D送信モードは、前記第１の時間周期と同一又は異なる第２の時間周期で繰り返される第２のリソース・パターンに従い、
　各第２のリソース・パターンは、前記D2D送信端末から前記D2D受信端末へのデータ送信のために使用されるデータチャネル・サブフレーム・プールを含み、
　各第２のリソース・パターンは、
（ａ）１つの第２のリソース・パターン内又は隣接する２つの第２のリソース・パターンにおいて、前記第１のD2D制御情報の送信に使用される複数の制御チャネル・サブフレーム・プールが前記第１の時間周期より短い間隔で現れる、
（ｂ）複数の連続する第２の時間周期でのデータ送信のためのリソース割り当てを示す第２のD2D制御情報を送信するために使用される制御チャネル・サブフレーム・プールを含む、又は
（ｃ）前記第１のD2D制御情報又は前記第２のD2D制御情報の送信に使用される制御チャネル・サブフレーム・プールを含まない、
よう定義されている、
方法。
　無線端末における方法をコンピュータに行わせるためのプログラムを格納した非一時的なコンピュータ可読媒体であって、
　前記方法は、
　第１のdevice-to-device（D2D）送信モード及び第２のD2D送信モードのいずれが有効化されるかを示す指示を含む第１の制御信号を受信すること、及び
　前記第１の制御信号の受信に応答して前記第２のD2D送信モードに従うD2D通信を行うこと、
を備え、
　前記第１のD2D送信モードは、第１の時間周期で繰り返される第１のリソース・パターンに従い、
　各第１のリソース・パターンは、データ送信のためのリソース割り当てを示す第１のD2D制御情報をD2D送信端末からD2D受信端末に送信するために使用される制御チャネル・サブフレーム・プールと、前記第１のD2D制御情報に従う前記D2D送信端末から前記D2D受信端末へのデータ送信のために使用されるデータチャネル・サブフレーム・プールを含み、
　前記第２のD2D送信モードは、前記第１の時間周期と同一又は異なる第２の時間周期で繰り返される第２のリソース・パターンに従い、
　各第２のリソース・パターンは、前記D2D送信端末から前記D2D受信端末へのデータ送信のために使用されるデータチャネル・サブフレーム・プールを含み、
　各第２のリソース・パターンは、
（ａ）１つの第２のリソース・パターン内又は隣接する２つの第２のリソース・パターンにおいて、前記第１のD2D制御情報の送信に使用される複数の制御チャネル・サブフレーム・プールが前記第１の時間周期より短い間隔で現れる、
（ｂ）複数の連続する第２の時間周期でのデータ送信のためのリソース割り当てを示す第２のD2D制御情報を送信するために使用される制御チャネル・サブフレーム・プールを含む、又は
（ｃ）前記第１のD2D制御情報又は前記第２のD2D制御情報の送信に使用される制御チャネル・サブフレーム・プールを含まない、
よう定義されている、
非一時的なコンピュータ可読媒体。