JP2018191333A

JP2018191333A - 基地局及び無線端末

Info

Publication number: JP2018191333A
Application number: JP2018147310A
Authority: JP
Inventors: 剛洋榮祝; Takahiro Saiwai; 裕之安達; Hiroyuki Adachi; 憲由福田; Noriyoshi Fukuda; 真人藤代; Masato Fujishiro
Original assignee: Kyocera Corp
Current assignee: Kyocera Corp
Priority date: 2015-05-15
Filing date: 2018-08-06
Publication date: 2018-11-29
Anticipated expiration: 2036-05-13
Also published as: US20180070264A1; EP3297364A1; EP4075901A1; JP6416434B1; US11337107B2; EP3297364B1; WO2016186059A1; JP6383888B2; EP3297364A4; JP6295377B2; US10390256B2; JP2018110439A; US20190342790A1; JPWO2016186059A1

Abstract

【課題】ＬＴＥシステムにおいて、無線端末の直接通信用リソース割当の方法を提供する。
【解決手段】基地局ｅＮＢは無線端末ＲｅｌａｙＵＥへ、複数の周波数のそれぞれに関連付けた直接通信用のリソースプールを示す情報ＬＣＩＤを送信する。無線端末ＲｅｌａｙＵＥは、受信した情報ＬＣＩＤに基づいて複数の周波数の中から第１周波数を選択し、第１周波数に関連付けた直接通信用のリソースプールＬＣＩＤ３を使用して直接通信におけるデータを他の無線端末ＲｅｍｏｔｅＵＥ：Ｃに送信する。
【選択図】図２３

Description

本出願は、通信システムにおいて用いられる基地局及び無線端末に関する。

移動通信システムの標準化プロジェクトである３ＧＰＰ（３ｒｄＧｅｎｅｒａｔｉｏｎＰａｒｔｎｅｒｓｈｉｐＰｒｏｊｅｃｔ）において、装置間近傍サービス（Ｄ２ＤＰｒｏＳｅ：ＤｅｖｉｃｅｔｏＤｅｖｉｃｅＰｒｏｘｉｍｉｔｙＳｅｒｖｉｃｅ）の仕様策定が進められている。

Ｄ２ＤＰｒｏＳｅの一つとして、直接通信（ＤｉｒｅｃｔＣｏｍｍｕｎｉｃａｔｉｏｎ）が規定されている。

直接通信では、基地局又はリレーノードが無線リソースを割り当てる第１のモード（Ｍｏｄｅ１）と、ユーザ端末自身が無線リソースプールから無線リソースを選択する第２のモード（Ｍｏｄｅ２）と、がある。

３ＧＰＰ技術報告書「ＴＳ３６．３００Ｖ１２．５．０」２０１５年３月２５日

一の実施形態に係る無線端末は、近傍サービスにおいて用いられる無線リソースの情報を含む複数の制御情報を基地局から受信する受信部と、前記複数の制御情報の通知タイミングによって、前記複数の制御情報のそれぞれに含まれる前記無線リソースの情報を同時に使用可能か否かを判定する制御部と、を備える。

一の実施形態に係る無線端末は、近傍サービスにおける送信データのバッファ量を報告するためのバッファ状態報告を前記基地局へ送信する送信部と、前記送信データに対応する論理チャネルの優先度に基づいて、前記バッファ状態報告を作成する制御部と、を備える。

一の実施形態に係る無線端末は、近傍サービスにおいて用いられる複数のリソースプールに関する情報と、前記複数のリソースプールのそれぞれと優先度との関連付けに関する第１の優先度情報と、論理チャネルグループに関する識別情報と優先度との関連付けに関する第２の優先度情報と、を基地局から受信する受信部を備える。

一の実施形態に係る基地局は、近傍サービスにおいて用いられる複数のリソースプールに関する情報と、前記複数のリソースプールのそれぞれと優先度との関連付けに関する第１の優先度情報と、論理チャネルグループに関する識別情報と優先度との関連付けに関する第２の優先度情報と、を無線端末へ送信する送信部を備える。

図１は、ＬＴＥシステムの構成を示す図である。図２は、ＬＴＥシステムにおける無線インターフェイスのプロトコルスタック図である。図３は、ＬＴＥシステムで使用される無線フレームの構成図である。図４は、実施形態に係るＵＥ・ネットワーク中継を説明するための図である。図５は、ＵＥ１００のブロック図である。図６は、ｅＮＢ２００のブロック図である。図７は、既存技術の概要を説明するための図である。図８は、第１実施形態に係る動作環境を説明するための図である。図９は、第１実施形態に係る動作（その１）を説明するためのシーケンス図である。図１０は、第１実施形態に係る動作（その２）を説明するためのシーケンス図である。図１１は、第１実施形態に係る動作（その２）を説明するための拡張ＤＣＩフォーマットの一例の図である。図１２は、第１実施形態に係る動作（その３）を説明するためのシーケンス図である。図１３は、第１実施形態に係る動作（その３）を説明するための拡張ＤＣＩフォーマットの一例の図である。図１４は、第１実施形態に係る動作（その４）を説明するためのシーケンス図である。図１５は、第１実施形態に係る動作（その４）を説明するためのＳＣＩ割り当ての一例の図である。図１６は、第１実施形態に係る動作（その５）を説明するための図である。図１７は、第２実施形態に係る動作（その１）を説明するための拡張ＳＣＩフォーマットの一例の図である。図１８は、第２実施形態に係る動作（その１）を説明するための拡張ＤＣＩフォーマットの一例の図である。図１９は、第２実施形態に係る動作（その２）を説明するための図である。図２０は、第２実施形態に係る動作（その４）を説明するための拡張ＳＣＩフォーマットの一例の図である。図２１は、第２実施形態に係る動作（その５）を説明するための図である。図２２は、第２実施形態に係る動作（その６）を説明するための図である。図２３は、第２実施形態に係る動作（その７）を説明するための図である。図２４は、第３実施形態に係る動作（その１）を説明するためのシーケンス図である。図２５は、第３実施形態に係る動作（その２）を説明するためのシーケンス図である。図２６は、第３実施形態に係る動作（その２）を説明するための図である。図２７は、第４実施形態に係る環境の例を説明するための図である。図２８は、第４実施形態に係るシーケンスを示す図である。図２９は、第４実施形態に係るリソースの割り当ての例を示す図である。図３０は、第４実施形態に係るリソースの割り当ての例を示す図である。図３１は、第４実施形態に係るリソースの割り当ての例を示す図である。図３２は、第４実施形態に係るリソースの割り当ての例を示す図である。図３３は、第６実施形態に係る環境の例を説明するための図である。図３４は、第６実施形態に係るシーケンスの例を示す図である。図３５は、第６実施形態に係るシーケンスの例を示す図である。図３６は、第６実施形態に係るシーケンスの例を示す図である。図３７は、第６実施形態に係るシーケンスの例を示す図である。図３８は、第６実施形態に係るシーケンスの例を示す図である。図３９は、第６実施形態に係るシーケンスの例を示す図である。図４０は、第６実施形態の追加実施例に係るシーケンスの例を示す図である。図４１は、第６実施形態の追加実施例に係るシーケンスの例を示す図である。図４２は、データが発生してから送信されるまでの遅延を説明するための図である。図４３は、第７実施形態に係る動作を説明するためのシーケンス図である。図４４は、第７実施形態の変更例１に係る動作を説明するためのシーケンス図である。図４５は、第８実施形態に係る動作環境を説明するための図である。図４６は、第８実施形態に係る動作を説明するためのシーケンス図である。図４７は、第８実施形態に係る動作を説明するための図である。図４８は、第８実施形態の変更例を説明するための図である。図４９は、第９実施形態の動作を説明するためのシーケンス図である。図５０は、第９実施形態の動作を説明するための図である。図５１は、第１０実施形態に係る動作環境を説明するための図である。図５２は、第１０実施形態に係る動作を説明するためのシーケンス図である。図５３は、第１０実施形態に係る動作を説明するための図である。図５４は、その他実施形態に係る動作を説明するための図である。図５５は、その他実施形態に係る動作を説明するための図である。図５６は、その他実施形態に係る動作を説明するための図である。図５７は、その他実施形態に係る動作を説明するための図である。図５８は、その他実施形態に係る動作を説明するための図である。図５９は、その他実施形態に係る動作を説明するための図である。図６０は、ＵＥ−ｔｏ−ネットワークリレーのレイテンシ問題を説明するための図である。図６１は、オプション１の一例を説明するための図である。図６２は、オプション２の一例を説明するための図である。図６３は、オプション３の一例を説明するための図である。

［実施形態の概要］
一の実施形態に係る無線端末は、近傍サービスにおいて用いられる無線リソースの情報を含む複数の制御情報を基地局から受信する受信部と、前記複数の制御情報の通知タイミングによって、前記複数の制御情報のそれぞれに含まれる前記無線リソースの情報を同時に使用可能か否かを判定する制御部と、を備えてもよい。

一の実施形態に係る無線端末は、近傍サービスにおける送信データのバッファ量を報告するためのバッファ状態報告を前記基地局へ送信する送信部と、前記送信データに対応する論理チャネルの優先度に基づいて、前記バッファ状態報告を作成する制御部と、を備えてもよい。

一の実施形態に係る無線端末は、近傍サービスにおいて用いられる複数のリソースプールに関する情報と、前記複数のリソースプールのそれぞれと優先度との関連付けに関する第１の優先度情報と、論理チャネルグループに関する識別情報と優先度との関連付けに関する第２の優先度情報と、を基地局から受信する受信部を備えてもよい。

一の実施形態に係る基地局は、近傍サービスにおいて用いられる複数のリソースプールに関する情報と、前記複数のリソースプールのそれぞれと優先度との関連付けに関する第１の優先度情報と、論理チャネルグループに関する識別情報と優先度との関連付けに関する第２の優先度情報と、を無線端末へ送信する送信部を備えてもよい。

なお、後述する実施形態では、以下の内容についても述べられている。

無線端末が直接通信により複数の宛先のそれぞれにデータを送信することが想定される。

実施形態に係る基地局は、近傍サービスにおける直接通信によりデータを送信する無線端末に対して、前記直接通信で用いられる無線リソースの割当情報を含む制御情報に対応付けられたＳＬ識別子からなる複数のＳＬ識別子を割り当てるコントローラを備え、前記コントローラは、前記複数のＳＬ識別子毎に無線リソースを確保し、前記複数のＳＬ識別子に対応する複数の制御情報を前記無線端末に送信する。

実施形態において、前記コントローラは、前記無線端末が、ネットワーク圏外のリモート端末とネットワークとの間で前記リモート端末のデータを中継するリレー端末である場合に、前記無線端末に前記複数のＳＬ識別子を割り当てる。

実施形態において、前記コントローラは、前記複数の宛先の数が所定値を越えた場合に、前記無線端末に前記複数のＳＬ識別子を割り当てる。

実施形態において、前記コントローラは、前記複数のＳＬ識別子のうちの特定のＳＬ識別子と関連付けられたサーチスペースに前記複数の制御情報を配置する。

実施形態に係る無線端末は、近傍サービスにおける直接通信で用いられる無線リソースの割当情報を含む複数の制御情報に対応付けられた複数のＳＬ識別子を受信するレシーバと、前記複数のＳＬ識別子に対応する前記複数の制御情報のそれぞれに含まれる複数の無線リソースの割当情報に基づいて、前記直接通信により複数の宛先のそれぞれにデータを送信するコントローラと、を備える。

実施形態に係る基地局は、近傍サービスにおける直接通信に用いられる第１の無線リソースの割当情報を含む制御情報を送信するコントローラを備え、前記コントローラは、前記直接通信に用いられる第２の無線リソースの割当情報と、インデックスとを含む制御情報を送信し、前記インデックスは、前記第１の無線リソースだけでなく前記第２の無線リソースも使用可能か否かを示す。

実施形態に係る無線端末は、近傍サービスにおける直接通信に用いられる第１の無線リソースの割当情報を含む制御情報を受信するレシーバを備え、前記レシーバは、前記直接通信に用いられる第２の無線リソースの割当情報と、インデックスとを含む制御情報を受信し、前記インデックスは、前記第１の無線リソースだけでなくだけでなく前記第２の無線リソースも使用可能か否かを示す。

実施形態に係る基地局は、近傍サービスにおける直接通信により複数の宛先のそれぞれにデータを送信する無線端末のために、１つの無線リソースプールにおいて複数の無線リソースを確保するコントローラを備え、前記コントローラは、複数の無線リソースそれぞれの割当情報からなる複数の割当情報を含む１つの制御情報を前記無線端末に送信する。

実施形態において、前記コントローラは、複数の無線リソースそれぞれの割当情報に対応し且つ互いに異なるインデックスを前記１つの制御情報に含める。

実施形態に係る無線端末は、近傍サービスにおける直接通信で用いられる複数の無線リソースそれぞれの割当情報からなる複数の割当情報を含む１つの制御情報を受信するレシーバと、前記複数の割当情報に基づいて、前記直接通信により複数の宛先のそれぞれにデータを送信するコントローラと、を備える。

実施形態に係る無線端末は、近傍サービスにおける直接通信でデータを送信するための無線リソースが選択される無線リソースプールを設定するコントローラを備え、前記コントローラは、基地局から許可された場合に、前記直接通信により送信されるデータの割当情報を含む複数の制御情報を送信するための複数の無線リソースを前記無線リソースプールから選択する。

実施形態に係る無線端末は、近傍サービスにおける直接通信により複数の宛先のそれぞれにデータを送信するための複数の無線リソースを選択する場合、前記複数の無線リソースのそれぞれが互いに時間方向で重ならないように選択するコントローラを備える。

実施形態に係る無線端末は、近傍サービスにおける直接通信により複数の宛先のそれぞれにデータを送信するための複数の無線リソースを選択するコントローラと、前記複数の無線リソースそれぞれの割当情報を含む拡張制御情報を前記複数の宛先に向けて送信するトランシーバと、を備える。

実施形態において、前記コントローラは、前記直接通信により１つの宛先にデータを送信するために選択された無線リソースの割当情報を含む制御情報に適用するＭＣＳ（ＭｏｄｕｌａｔｉｏｎａｎｄＣｏｄｉｎｇＳｃｈｅｍｅ）よりも伝送レートの高いＭＣＳを前記拡張制御情報に適用する。

実施形態において、前記トランシーバは、前記直接通信により１つの宛先にデータを送信するために選択された無線リソースの割当情報を含む制御情報よりも多い無線リソース量を用いて、前記拡張制御情報を送信する。

実施形態において、前記コントローラは、事前設定された無線リソースプールの中から前記拡張制御情報を送信するための無線リソースを選択する。

実施形態において、前記トランシーバは、前記無線端末がネットワーク圏外のリモート端末とネットワークとの間で直接通信によりデータを中継するリレー端末である場合に、無線リソースプールの情報を前記複数の宛先に向けて送信し、前記コントローラは、前記無線リソースプールの中から前記拡張制御情報を送信するための無線リソースを選択する。

実施形態に係る無線端末は、複数の宛先それぞれのデータからなる複数のデータを含むパケットを生成するコントローラと、前記パケットに前記複数の宛先の前記複数のデータが含まれることを示す特別な宛先識別子と、前記複数の宛先に対応する複数の無線端末が前記パケットを受信するための無線リソースの割当情報とを含む制御情報を前記複数の宛先に向けて送信するトランシーバと、を備える。

実施形態において、前記特別な宛先識別子は、ブロードキャスト用の識別子である。

実施形態において、前記特別な宛先識別子は、前記無線端末が、ネットワーク圏外のリモート端末とネットワークとの間で前記リモート端末のデータを中継するリレー端末である場合に用いられる識別子の少なくとも一部からなる。

実施形態に係る無線端末は、複数の宛先それぞれのデータからなる複数のデータを含むパケットを生成するコントローラと、前記パケットに前記複数の宛先の前記複数のデータが含まれることを示す宛先識別子と、前記複数の宛先に対応する複数の無線端末が前記パケットを受信するための無線リソースの割当情報とを含む制御情報を前記複数の宛先に向けて送信するトランシーバと、を備え、前記トランシーバは、前記制御情報を送信する前に、前記宛先識別子を前記複数の宛先に通知する。

実施形態に係る無線端末は、複数の宛先それぞれのデータからなる複数のデータを含むパケットを生成するコントローラと、前記複数の宛先のそれぞれを示す宛先識別子からなる複数の宛先識別子と、前記複数の宛先に対応する複数の無線端末が前記パケットを受信するための無線リソースの割当情報とを含む制御情報を前記複数の宛先に向けて送信するトランシーバと、を備える。

実施形態に係る無線端末は、近傍サービスにおける直接通信により送信されるパケットに複数の宛先それぞれのデータからなる複数のデータが含まれることを示す宛先識別子と、前記複数の宛先に対応する複数の無線端末が前記パケットを受信するための無線リソースの割当情報と、を含む制御情報を他の無線端末から受信するコントローラを備え、前記コントローラは、前記制御情報に前記宛先識別子が含まれる場合、前記割当情報に基づいて、前記パケットを受信する。

実施形態において、前記コントローラは、前記パケットに前記無線端末のデータが含まれない場合、前記他の無線端末から再送される前記パケットの受信を省略する。

実施形態において、前記割当情報は、前記パケットからなり且つ時間方向に異なって配置される複数のパケットの配置を示し、前記コントローラは、前記複数のパケットのうちの最初のパケットに前記無線端末のデータが含まれない場合、前記複数のパケットのうちの残りのパケットの受信を省略する。

実施形態において、前記割当情報は、前記パケットからなり時間方向に異なって配置される複数のパケットの所定期間における配置を示し、前記コントローラは、前記所定期間内で前記パケットに含まれる複数の宛先が変更され得るタイミングを示すタイミング情報を受信し、前記コントローラは、前記タイミング情報に基づいて、前記複数のパケットのうち、前記複数の宛先が変更され得るタイミングで送信されるパケットを受信する。

実施形態において、前記コントローラは、前記複数のパケットのうち前記宛先が変更されるタイミングで送信されるパケットに前記無線端末の宛先が含まれない場合、前記宛先が変更される次のタイミングまで前記パケットの受信を省略する。

実施形態において、前記コントローラは、前記複数のパケットのうち、前記タイミング情報によって示される最後のタイミングで送信されるパケットに前記無線端末の宛先が含まれない場合、前記所定期間が終了するよりも前に前記割当情報を破棄する。

実施形態に係る無線端末は、近傍サービスにおける直接通信により複数の宛先のそれぞれのデータを送信する場合、前記複数の宛先毎に異なる論理チャネルの識別情報を設定するコントローラと、前記識別情報に対応する論理チャネルで、前記複数の宛先のそれぞれのデータを搬送するトランシーバと、を備える。

実施形態において、前記トランシーバは、前記識別情報の利用状況を他の無線端末に通知し、前記コントローラは、前記識別情報の利用状況に基づいて選択された論理チャネルの識別情報を前記他の無線端末に設定する。前記トランシーバは、前記選択された論理チャネルの識別情報に対応する論理チャネルで前記他の無線端末宛てのデータを搬送する。

実施形態に係る基地局は、近傍サービスにおける直接通信によりデータを送信する無線端末に対して、前記直接通信で用いられる無線リソースの割当情報を含む制御情報に対応付けられたＳＬ識別子と、無線リソースプールとのセットからなる互いに異なる複数のセットを割り当てるコントローラを備え、前記コントローラは、前記複数のセットのそれぞれに対応する前記制御情報からなる複数の制御情報を前記無線端末に送信する。

実施形態において、前記コントローラは、前記複数の制御情報のいずれかに含まれる特定のＳＬ識別子と関連付けられたサーチスペースに前記複数の制御情報を配置する。

実施形態に係る基地局は、近傍サービスにおける直接通信によりデータを送信する無線端末に対して、前記直接通信で用いられる無線リソースの割当情報を含む制御情報に対応付けられたＳＬ識別子を割り当てるコントローラを備え、前記コントローラは、前記ＳＬ識別子に対応付けられた複数の無線リソースプールと、前記複数の無線リソースプールそれぞれのインデックスとを前記無線端末に通知し、前記コントローラは、前記割当情報によって示される無線リソースが含まれる無線リソースプールのインデックスを示す情報を含む前記制御情報からなる複数の制御情報を前記無線端末に送信する。

実施形態において、前記インデックスを示す情報は、前記割当情報が配置される時間位置である。

実施形態に係る基地局は、近傍サービスにおける直接通信によりデータを送信する無線端末に対して、前記データを送信するための無線リソースが選択される複数の無線リソースプールを設定するコントローラと、前記複数の無線リソースプールが同時に使用可能であるか否かの情報を前記無線端末に送信するトランシーバと、を備える。

実施形態において、前記情報は、前記複数の無線リソースプールのうちの同時に使用可能である無線リソースプールの組み合わせを示すリストである。

実施形態において、前記情報は、前記複数の無線リソースプールのうち、同時に使用可能である無線リソースプールのみを示すリストである。

実施形態に係る無線端末は、近傍サービスにおける直接通信により周波数方向に連続する複数の無線リソースを用いて送信される複数の制御情報を受信するコントローラを備え、前記コントローラは、複数の無線リソースが配置されるパターンの数に基づいて、前記複数の制御情報を受信するための処理を行う。

実施形態に係る無線端末は、近傍サービスにおける直接通信により周波数方向に連続する複数の無線リソースを用いて送信される複数の制御情報を受信するコントローラを備え、前記コントローラは、前記複数の無線リソースが配置されるリソースプールに関連付けられた情報に基づいて、前記複数の制御情報を受信するための処理を行う。

実施形態に係る無線端末は、近傍サービスにおける直接通信により周波数方向に連続する複数の無線リソースを用いて送信される複数の制御情報を送信するコントローラを備え、前記コントローラは、ＯＦＤＭ信号又は複数クラスタ送信によって、前記複数の制御情報を送信する。

移動通信システムの標準化プロジェクトである３ＧＰＰ（３ｒｄＧｅｎｅｒａｔｉｏｎＰａｒｔｎｅｒｓｈｉｐＰｒｏｊｅｃｔ）において、近傍サービス（ＰｒｏＳｅ：Ｐｒｏｘｉｍｉｔｙ−ｂａｓｅｄＳｅｒｖｉｃｅｓ）の仕様策定が進められている。

ここで、ＰｒｏＳｅには、第１の無線端末（ＰｒｏＳｅＵＥ−ｔｏ−ＮｅｔｗｏｒｋＲｅｌａｙ）が、ネットワーク圏外の第２の無線端末（ＲｅｍｏｔｅＵＥ）とネットワークとの間で第２の無線端末のデータ（トラフィック）を中継するＵＥ・ネットワーク中継が含まれる（例えば、３ＧＰＰ技術報告書「ＴＳ２３．３０３Ｖ１２．４．０」２０１５年３月１９日参照）。

しかしながら、現状の仕様では、ＵＥ・ネットワーク中継の詳細が策定されていないため、ＵＥ・ネットワーク中継を有効に活用できない可能性がある。

実施形態に係る基地局は、第１の無線端末と自基地局との間のデータの送信を前記第１の無線端末との直接通信により中継可能な第２の無線端末に対して、前記直接通信に用いる無線リソースを使用するための設定を通知する制御部を備え、前記制御部は、所定の情報に応じて、前記第２の無線端末に対して、自基地局が直接的に指定する無線リソースを使用するための設定又は前記第１の無線端末が選択する無線リソースを使用するための設定を通知する。

実施形態において、前記所定の情報は、下り方向の制御情報を送信するためのリソースの容量、自基地局の処理負荷、前記下り方向の制御情報の送信の遅延及び前記第２の無線端末の電力状況のうちの少なくとも一つである。

好適には、前記制御部は、前記第２の無線端末に対して、自基地局が直接的に指定する無線リソースを使用するための設定を通知する場合、当該無線リソースが前記第１の無線端末に予め設定された前記直接通信に用いる無線リソースに重ならないように、当該無線リソースの時間方向のパターンを設定する。

実施形態において、前記制御部は、前記第２の無線端末に対して、自基地局が直接的に指定する無線リソースを使用するための設定を通知する場合、当該無線リソースが前記第１の無線端末に対して自基地局が直接的に指定する前記直接通信に用いる無線リソースに重ならないように、当該無線リソースの時間方向のパターンを設定する。

実施形態において、前記制御部は、前記第２の無線端末に対して、自基地局が直接的に指定する無線リソースを使用するための設定を通知する場合、当該無線リソースが前記第１の無線端末に対して自基地局が直接的に指定する前記直接通信に用いる無線リソースに重ならないように、所定のタイミングで、当該無線リソースに関する情報を通知する。

実施形態において、前記制御部は、前記第２の無線端末に対して、自基地局が直接的に指定する無線リソースを使用するための設定を通知する場合、当該無線リソースの割り当てを繰り返す回数を設定する。

実施形態において、前記制御部は、前記第２の無線端末に対して、前記第１の無線端末が選択する無線リソースを使用するための設定を通知する場合、当該無線リソースが前記第１の無線端末に予め設定された前記直接通信に用いる無線リソースに重ならないように、当該無線リソースの時間方向の位置を設定する。

実施形態に係る基地局は、ユーザ端末が選択可能な無線リソースを複数割り当てる制御部を備え、前記制御部は、所定の情報に基づいて、割り当てた複数の前記無線リソースにおける各無線リソースの優先度を表す情報を送信し、前記複数の無線リソースは、端末間通信に関する無線リソースである。

実施形態に係る基地局は、第１の無線端末と自基地局との間のデータの送信を前記第１の無線端末との直接通信により中継可能な第２の無線端末を決定する制御部を備え、前記制御部は、所定の条件を満たしている無線端末を、前記第２の無線端末に決定する。

実施形態において、前記制御部は、前記第１の無線端末との間の無線環境が所定の閾値以上である無線端末、自基地局との間の無線環境が所定の閾値以上である無線端末、又は第１の無線端末と自基地局との間のデータの送信を前記第１の無線端末との直接通信により中継可能である無線端末を、前記所定の条件を満たしている無線端末と判定する。

実施形態において、前記制御部は、前記所定の条件を満たしている無線端末に対して、前記第２の無線端末の設定情報を通知する。

ところで、現状の仕様では、直接通信において、優先度の高いデータ（パケット）の取り扱いが規定されていない。

実施形態に係る無線端末は、近傍サービスにおける直接通信を行う。前記無線端末は、前記直接通信によりデータを送信するために割り当てられた無線リソースを通知するための制御情報を前記直接通信により他の無線端末に送信するコントローラを備える。前記コントローラは、前記制御情報により通知された所定の無線リソースを用いて送信予定のデータよりも優先度が高い高優先データが、前記制御情報を通知した後に発生した場合には、前記所定の無線リソースを用いて、前記送信予定のデータよりも先に前記高優先データを送信する。

実施形態において、前記コントローラは、前記所定の無線リソースを用いて送信されるデータが、前記送信予定のデータではなく、前記高優先データであることを示す情報を送信する。

実施形態において、前記コントローラは、前記送信予定のデータのための論理チャネルの識別情報よりも優先度が高い論理チャネルの識別情報を用いて前記高優先データを送信する。

実施形態において、前記コントローラは、前記送信予定のデータの宛先識別子に加えて、前記高優先データの送信先になり得る候補端末の宛先識別子を前記制御情報に含める。

実施形態において、前記コントローラは、前記無線端末が前記直接通信により前記高優先データを送信するために用いられるリソースプールと、前記高優先データの送信先になり得る候補端末の宛先識別子とを前記候補端末に通知する。前記所定の無線リソースは、前記リソースプール内に存在する。

実施形態において、前記コントローラは、基地局を介して、又は、前記近傍サービスにおける直接発見手順により、前記リソースプールと前記候補端末の宛先識別子とを前記候補端末に通知する。

実施形態に係る無線端末は、近傍サービスにおける直接通信を行う。前記無線端末は、前記直接通信によりデータを送信するために割り当てられた無線リソースを通知するための制御情報を前記直接通信により他の無線端末から受信するコントローラを備える。前記コントローラは、前記制御情報を受信した後、前記制御情報により通知された所定の無線リソースを用いて送信予定のデータよりも優先度が高い高優先データを、前記所定の無線リソースを用いて前記送信予定のデータよりも先に前記高優先データを受信する。

実施形態において、前記コントローラは、前記所定の無線リソースを用いて受信したデータが、前記送信予定のデータではなく、前記高優先データであることを示す情報を受信する。実施形態において、前記コントローラは、前記送信予定のデータのための論理チャネルの識別情報よりも優先度が高い論理チャネルの識別情報を用いて前記高優先データを受信する。前記コントローラは、前記優先度が高い論理チャネルの識別情報に基づいて、前記高優先データを受信したと判断する。

実施形態において、前記制御情報は、前記送信予定のデータの宛先識別子に加えて、前記高優先データの送信先になり得る候補端末の受信識別子を含む。前記候補端末の宛先識別子が前記無線端末を示す場合、前記所定の無線リソースを用いて送信されるデータを受信する。

実施形態において、前記コントローラは、前記他の無線端末が前記直接通信により前記高優先データを送信するために用いられるリソースプールと、前記高優先データの送信先になり得る候補端末の宛先識別子と、を受信する。前記所定の無線リソースは、前記リソースプール内に存在する。前記コントローラは、前記制御情報に前記無線端末の宛先識別子が含まれない場合であっても、前記所定の無線リソースを用いて前記他の無線端末から送信されるデータを受信する。

実施形態において、前記コントローラは、基地局を介して、又は、前記近傍サービスにおける直接発見手順により、前記リソースプールと前記候補端末の宛先識別子とを受信する。

実施形態に係る無線端末は、近傍サービスにおける直接通信により複数の宛先のそれぞれに異なるデータを送信するコントローラを備える。前記コントローラは、最初に送信されるデータよりも後に送信されるデータの送信が制限される。

実施形態において、前記コントローラは、前記後に送信されるデータの優先度が、前記最初に送信されるデータの優先度と同じ又は高い場合には、前記後に送信されるデータを制限なく送信する。

移動通信システムの標準化プロジェクトである３ＧＰＰ（３ｒｄＧｅｎｅｒａｔｉｏｎＰａｒｔｎｅｒｓｈｉｐＰｒｏｊｅｃｔ）において、装置間近傍サービス（Ｄ２ＤＰｒｏＳｅ：ＤｅｖｉｃｅｔｏＤｅｖｉｃｅＰｒｏｘｉｍｉｔｙＳｅｒｖｉｃｅ）の仕様策定が進められている。Ｄ２ＤＰｒｏＳｅの一つとして、直接通信（ＤｉｒｅｃｔＣｏｍｍｕｎｉｃａｔｉｏｎ）が規定されている。

無線端末は、送信リソースプール内の無線リソースを用いて、直接通信によりデータを送信することができる。

現状の仕様では、直接通信において、優先度の高いデータ（パケット）の取り扱いが規定されていない。

実施形態に係る無線端末は、近傍サービスにおける直接通信を行う。前記無線端末は、時間方向に所定の周期で繰り返し配置される第１リソースプール内の無線リソースを用いて第１データを前記直接通信により他の無線端末に送信するコントローラを備える。前記コントローラは、前記第１データよりも優先度が高い第２データが発生した場合、前記所定の周期よりも短い周期で繰り返し配置される第２リソースプール内の無線リソースを用いて前記第２データを前記直接通信により前記他の無線端末に送信する。

実施形態では、前記コントローラは、前記直接通信に用いられるリソースプールと優先度との関連付けに関する優先度情報を基地局から受信する。前記コントローラは、前記優先度情報に基づいて、前記第１リソースプールの優先度よりも高い優先度を有する前記第２リソースプールを前記第２データを送信するためのリソースプールとして選択する。

実施形態では、前記コントローラは、前記直接通信に用いられるリソースプールのうちモニタが必須である必須リソースプールに関する情報を基地局から受信する。前記コントローラは、前記必須リソースプールに関する情報に基づいて、前記第２データを送信するためのリソースプールとして、前記必須リソースプールである前記第２リソースプールを選択する。

実施形態では、前記コントローラは、前記第２データを送信する前に前記第１データに対応するパケットの再送が完了していない場合、前記パケットの再送よりも前記第２データの送信を優先する。

実施形態では、前記コントローラは、前記第２データを送信する前に前記第１データに対応するパケットの再送が完了していない場合、前記パケットの再送が完了した後に、前記第２データの送信を開始する。

実施形態では、前記コントローラは、前記第２データを送信する前に前記第１データに対応するパケットの再送が完了していない場合、前記基地局からの指示に基づいて、前記第２データを送信する前に前記パケットの再送を完了するか否かを判断する。

実施形態では、前記コントローラは、前記第２リソースプールのうち前記他の無線端末がモニタするリソースプールに関するモニタ情報を前記基地局から受信する。前記他の無線端末がモニタする前記リソースプールの時間方向の間隔は、前記所定の周期よりも短い。前記コントローラは、前記モニタ情報に基づいて、前記第２データを前記他の無線端末に送信する。

実施形態では、前記第２リソースプールは、前記第１リソースプールが設けられるキャリアと異なるキャリアに設けられる。

実施形態では、前記コントローラは、キャリアと優先度との関連付けに関する優先度情報を基地局から受信する。前記コントローラは、前記優先度情報に基づいて、前記第１リソースプールが設けられるキャリアの優先度よりも高い優先を有するキャリアに設けられる前記第２リソースプールを前記第２データを送信するためのリソースプールとして選択する。

実施形態に係る無線端末は、近傍サービスにおける直接通信を行う。前記無線端末は、時間方向に所定の周期で繰り返し配置される第１リソースプール内の無線リソースを用いて第１データを前記直接通信により他の無線端末から受信するコントローラを備える。前記コントローラは、前記所定の周期よりも短い周期で繰り返し配置される第２リソースプール内の無線リソースを用いて、前記第１データよりも優先度が高い第２データを前記直接通信により前記他の無線端末から受信する。

実施形態では、前記コントローラは、前記第２リソースプールが、前記第１リソースプールが設けられているキャリアと異なるキャリアに設けられている場合には、前記無線端末が同時受信可能なキャリア数を示す受信チェイン数に基づいて、前記第２データを受信する。

実施形態に係る基地局は、時間方向に所定の周期で繰り返し配置される第１リソースプールと、前記所定の周期よりも短い周期で繰り返し配置される第２リソースプールと、を設けるコントローラを備える。前記第１リソースプールは、前記近傍サービスにおける直接通信を行う第１無線端末が前記直接通信により第１データを第２無線端末に送信するために用いられる。前記第２リソースプールは、前記第１データよりも優先度が高い第２データが発生した場合に、前記第１無線端末が前記直接通信により前記第２データを前記第２無線端末に送信するために用いられる。

実施形態では、前記コントローラは、前記直接通信に用いられるリソースプールと優先度との関連付けに関する優先度情報を前記第１無線端末に送信する。

実施形態では、前記コントローラは、前記直接通信に用いられるリソースプールのうちモニタが必須である必須リソースプールに関する情報を前記第１無線端末及び前記第２無線端末に送信する。

実施形態では、前記コントローラは、前記第１無線端末が前記第２データを送信する前に、前記第１データに対応するパケットの再送が完了していない場合、前記第２データを送信する前に前記パケットの再送を完了するか否かを判断するための指示を前記第１無線端末に送信する。

実施形態では、前記コントローラは、前記第２リソースプールのうち前記第２無線端末がモニタするリソースプールに関するモニタ情報を前記第１無線端末に送信する。

実施形態では、前記コントローラは、キャリアと優先度との関連付けに関する優先度情報を前記第１無線端末に送信する。

実施形態では、前記コントローラは、前記第１無線端末が同時送信可能なキャリア数を示す送信チェイン数及び前記第２無線端末が同時受信可能なキャリア数を示す受信チェイン数の少なくとも一方に基づいて、前記キャリアと前記優先度との関連づけを決定する。

実施形態に係る基地局は、時間方向において間隔をおいて配置される制御リソースプール内の制御リソースを用いて、近傍サービスにおける直接通信により、制御情報を送信する無線端末と接続可能な基地局である。前記基地局は、前記制御情報により通知されるデータリソースを用いて送信される第１データよりも優先度が高い第２データが発生した場合、前記第２データが発生した後に配置される制御リソースプールよりも時間的に前に位置する所定の無線リソースを、前記直接通信により送信される前記第２データのための無線リソースとして、前記無線端末に割り当てるコントローラを備える。

実施形態では、前記コントローラは、前記データリソースが配置されるデータリソースプールの外に位置する前記所定の無線リソースを前記無線端末に割り当てる。

実施形態では、前記コントローラは、前記第２データの発生を示す情報を前記無線端末から受信した場合に、前記所定の無線リソースを前記無線端末に割り当てる。

実施形態では、前記コントローラは、前記第２データの発生を示す情報として、前記第２データのデータ量を含む前記近傍サービスにおけるＳＬバッファ状態報告を受信する。

実施形態では、前記コントローラは、論理チャネルに関する識別情報の優先度に関する情報を前記無線端末に通知する。前記コントローラは、前記ＳＬバッファ状態報告に含まれる前記論理チャネルに関する識別情報に基づいて、前記無線端末から受信した前記ＳＬバッファ状態報告が、前記第２データの発生を示す情報であるか否かを判断する。

実施形態に係る無線端末は、近傍サービスにおける直接通信を行う。前記無線端末は、時間方向において間隔をおいて配置される制御リソースプール内の制御リソースを用いて、前記直接通信により、制御情報を送信するコントローラを備える。前記コントローラは、前記制御情報により通知されるデータリソースを用いて送信される第１データよりも優先度が高い第２データが発生した場合、前記第２データが発生した後に配置される制御リソースプールよりも時間的に前に位置する所定の無線リソースを、前記直接通信により他の無線端末に送信される前記第２データのための無線リソースとして、前記基地局から割り当てられる。

実施形態では、前記コントローラは、前記第２データが発生した場合に、前記第２データの発生を示す情報を前記基地局に送信する。

実施形態では、前記コントローラは、前記近傍サービスにおけるＳＬバッファ状態報告に前記第２データのデータ量を含め、前記ＳＬバッファ状態報告を前記第２データの発生を示す情報として前記基地局に送信する。

実施形態では、前記コントローラは、前記第２データのデータ量を含む前記ＳＬバッファ状態報告を、セルラ通信のためのバッファ状態報告及び前記第１データのデータ量を含むＳＬバッファ状態報告よりも優先的に前記基地局に送信する。

実施形態では、前記コントローラは、論理チャネルに関する識別情報の優先度に関する情報を前記基地局から受信する。前記コントローラは、前記優先度に関する情報に基づいて、前記第２データの優先度に対応する優先度を有する論理チャネルに関する識別情報を前記ＳＬバッファ状態報告に含める。

実施形態では、前記コントローラは、前記所定の無線リソースを用いて前記第２データを送信する前に、前記第１データに対応するパケットの再送が完了していない場合、前記パケットの再送よりも前記第２データを優先的に送信する。

実施形態では、前記コントローラは、前記所定の無線リソースを用いて前記第２データを送信する前に、前記第１データに対応するパケットの再送が完了していない場合、前記パケットの再送を完了した後に、前記第２データの送信を開始する。

実施形態では、前記コントローラは、前記所定の無線リソースを用いて前記第２データを送信する前に、前記第１データに対応するパケットの再送が完了していない場合、前記基地局からの指示に基づいて、前記第２データを送信する前に前記パケットの再送を完了するか否かを判断する。

実施形態では、前記コントローラは、前記第２データを受信するための動作のトリガとなる受信要求情報を前記他の無線端末に送信する。

実施形態では、前記コントローラは、システム及び同期に関する情報を運搬する物理サイドリンクブロードキャストチャネル、前記近傍サービスにおける同期信号、及び、前記近傍サービスにおける発見信号、の少なくともいずれかに基づいて、前記受信要求情報を前記他の無線端末に送信する。

実施形態では、前記第２の無線リソースは、前記第２データを送信するための所定の無線リソースだけでなく、前記所定の無線リソースを通知するための制御情報を送信するための無線リソースも含む。

実施形態に係る無線端末は、近傍サービスにおける直接通信を行う。前記無線端末は、時間方向において間隔をおいて配置される制御リソースプール内の制御リソースを用いて、前記直接通信により、制御情報を他の無線端末から受信するコントローラを備える。前記コントローラは、前記制御情報により通知されるデータリソースを用いて送信される第１データよりも優先度が高い第２データが発生した場合、前記第２データが発生した後に配置される制御リソースプールよりも時間的に前に位置する所定の無線リソースを用いて、前記第２データを受信する。

実施形態では、前記コントローラは、前記第２データを受信するための動作のトリガとなる受信要求情報を前記他の無線端末から受信する。前記コントローラは、前記受信要求情報に基づいて、前記第２データを受信する。

実施形態では、前記コントローラは、前記受信要求情報に基づいて、前記第２データの送信に用いられる前記所定の無線リソースを通知するための制御情報を前記他の無線端末から受信する。

実施形態では、前記コントローラは、前記制御情報を含む前記受信要求情報を受信する。

［全体概要］
（移動通信システム）
以下において、実施形態に係る移動通信システムであるＬＴＥシステムについて説明する。図１は、ＬＴＥシステムの構成を示す図である。

図１に示すように、ＬＴＥシステムは、ＵＥ（ＵｓｅｒＥｑｕｉｐｍｅｎｔ）１００、Ｅ−ＵＴＲＡＮ（ＥｖｏｌｖｅｄＵｎｉｖｅｒｓａｌＴｅｒｒｅｓｔｒｉａｌＲａｄｉｏＡｃｃｅｓｓＮｅｔｗｏｒｋ）１０、及びＥＰＣ（ＥｖｏｌｖｅｄＰａｃｋｅｔＣｏｒｅ）２０を備える。また、セルラネットワークのオペレータにより管理されない外部ネットワークには、Ｓｅｒｖｅｒ４００が設けられる。

ＵＥ１００は、無線端末に相当する。ＵＥ１００は、移動型の通信装置である。ＵＥ１００は、セル（サービングセル）との無線通信を行う。ＵＥ１００の構成については後述する。

Ｅ−ＵＴＲＡＮ１０は、無線アクセスネットワークに相当する。Ｅ−ＵＴＲＡＮ１０は、ｅＮＢ２００（ｅｖｏｌｖｅｄＮｏｄｅ−Ｂ）を含む。ｅＮＢ２００は、基地局に相当する。ｅＮＢ２００は、Ｘ２インターフェイスを介して相互に接続される。ｅＮＢ２００の構成については後述する。

ｅＮＢ２００は、１又は複数のセルを管理している。ｅＮＢ２００は、自セルとの接続を確立したＵＥ１００との無線通信を行う。ｅＮＢ２００は、無線リソース管理（ＲＲＭ）機能、ユーザデータ（以下、単に「データ」という）のルーティング機能、モビリティ制御・スケジューリングのための測定制御機能等を有する。「セル」は、無線通信エリアの最小単位を示す用語として使用される。「セル」は、ＵＥ１００との無線通信を行う機能を示す用語としても使用される。

ＥＰＣ２０は、コアネットワークに相当する。ＥＰＣ２０は、ＭＭＥ（ＭｏｂｉｌｉｔｙＭａｎａｇｅｍｅｎｔＥｎｔｉｔｙ）／Ｓ−ＧＷ（Ｓｅｒｖｉｎｇ−Ｇａｔｅｗａｙ）３００と、Ｐ−ＧＷ（ＰａｃｋｅｔＤａｔａＮｅｔｗｏｒｋＧａｔｅｗａｙ）３５０とを含む。ＭＭＥは、ＵＥ１００に対する各種モビリティ制御等を行う。Ｓ−ＧＷは、データの転送制御を行う。ＭＭＥ／Ｓ−ＧＷ３００は、Ｓ１インターフェイスを介してｅＮＢ２００と接続される。Ｅ−ＵＴＲＡＮ１０及びＥＰＣ２０は、ネットワークを構成する。Ｐ−ＧＷ３５０は、外部ネットワークから（及び外部ネットワークに）ユーザデータを中継する制御を行う。

Ｓｅｒｖｅｒ４００は、ＰｒｏＳｅアプリケーションサーバ（ＰｒｏＳｅＡｐｐｌｉｃａｔｉｏｎＳｅｒｖｅｒ）である。この場合、Ｓｅｒｖｅｒ４００は、ＰｒｏＳｅにおいて用いられる識別子を管理する。例えば、Ｓｅｒｖｅｒ４００は、「ＥＰＣＰｒｏＳｅユーザＩＤ」及び「ＰｒｏＳｅファンクションＩＤ」を記憶する。また、Ｓｅｒｖｅｒ４００は、「アプリケーションレイヤユーザＩＤ」と「ＥＰＣＰｒｏＳｅユーザＩＤ」とをマッピングする。

図２は、ＬＴＥシステムにおける無線インターフェイスのプロトコルスタック図である。図２に示すように、無線インターフェイスプロトコルは、ＯＳＩ参照モデルの第１層乃至第３層に区分されている。第１層は、物理（ＰＨＹ）層である。第２層は、ＭＡＣ（ＭｅｄｉｕｍＡｃｃｅｓｓＣｏｎｔｒｏｌ）層、ＲＬＣ（ＲａｄｉｏＬｉｎｋＣｏｎｔｒｏｌ）層、及びＰＤＣＰ（ＰａｃｋｅｔＤａｔａＣｏｎｖｅｒｇｅｎｃｅＰｒｏｔｏｃｏｌ）層を含む。第３層は、ＲＲＣ（ＲａｄｉｏＲｅｓｏｕｒｃｅＣｏｎｔｒｏｌ）層を含む。

物理層は、符号化・復号、変調・復調、アンテナマッピング・デマッピング、及びリソースマッピング・デマッピングを行う。ＵＥ１００の物理層とｅＮＢ２００の物理層との間では、物理チャネルを介してデータ及び制御信号が伝送される。

ＭＡＣ層は、データの優先制御、ハイブリッドＡＲＱ（ＨＡＲＱ：ＨｙｂｒｉｄＡｕｔｏｍａｔｉｃＲｅｐｅａｔＲｅｑｕｅｓｔ）による再送処理、及びランダムアクセス手順等を行う。ＵＥ１００のＭＡＣ層とｅＮＢ２００のＭＡＣ層との間では、トランスポートチャネルを介してデータ及び制御信号が伝送される。ｅＮＢ２００のＭＡＣ層は、スケジューラを含む。当該スケジューラは、上下リンクのトランスポートフォーマット（トランスポートブロックサイズ、変調・符号化方式（ＭＣＳ：ＭｏｄｕｌａｔｉｏｎａｎｄＣｏｄｉｎｇＳｃｈｅｍｅ））及びＵＥ１００への割当リソースブロックを決定する。

ＲＬＣ層は、ＭＡＣ層及び物理層の機能を利用してデータを受信側のＲＬＣ層に伝送する。ＵＥ１００のＲＬＣ層とｅＮＢ２００のＲＬＣ層との間では、論理チャネルを介してデータ及び制御信号が伝送される。

ＰＤＣＰ層は、ヘッダ圧縮・伸張、及び暗号化・復号化を行う。

ＲＲＣ層は、制御信号を取り扱う制御プレーンでのみ定義される。ＵＥ１００のＲＲＣ層とｅＮＢ２００のＲＲＣ層との間では、各種設定のためのメッセージ（ＲＲＣメッセージ）が伝送される。ＲＲＣ層は、無線ベアラの確立、再確立及び解放に応じて、論理チャネル、トランスポートチャネル、及び物理チャネルを制御する。ＵＥ１００のＲＲＣとｅＮＢ２００のＲＲＣとの間に接続（ＲＲＣ接続）がある場合、ＵＥ１００はＲＲＣコネクティッド状態（コネクティッド状態）であり、そうでない場合、ＵＥ１００はＲＲＣアイドル状態（アイドル状態）である。

ＲＲＣ層の上位に位置するＮＡＳ（Ｎｏｎ−ＡｃｃｅｓｓＳｔｒａｔｕｍ）層は、セッション管理及びモビリティ管理等を行う。

図３は、ＬＴＥシステムで使用される無線フレームの構成図である。ＬＴＥシステムは、下りリンクにはＯＦＤＭＡ（ＯｒｔｈｏｇｏｎａｌＦｒｅｑｕｅｎｃｙＤｉｖｉｓｉｏｎＭｕｌｔｉｐｌｅＡｃｃｅｓｓ）、上りリンクにはＳＣ−ＦＤＭＡ（ＳｉｎｇｌｅＣａｒｒｉｅｒＦｒｅｑｕｅｎｃｙＤｉｖｉｓｉｏｎＭｕｌｔｉｐｌｅＡｃｃｅｓｓ）がそれぞれ適用される。

図３に示すように、無線フレームは、時間方向に並ぶ１０個のサブフレームで構成される。各サブフレームは、時間方向に並ぶ２個のスロットで構成される。各サブフレームの長さは１ｍｓである。各スロットの長さは０．５ｍｓである。各サブフレームは、周波数方向に複数個のリソースブロック（ＲＢ）を含み、時間方向に複数個のシンボルを含む。各リソースブロックは、周波数方向に複数個のサブキャリアを含む。１つのシンボル及び１つのサブキャリアにより１つのリソースエレメント（ＲＥ）が構成される。また、ＵＥ１００に割り当てられる無線リソース（時間・周波数リソース）のうち、周波数リソースはリソースブロックにより特定でき、時間リソースはサブフレーム（又はスロット）により特定できる。

下りリンクにおいて、各サブフレームの先頭数シンボルの区間は、主に下りリンク制御信号を伝送するための物理下りリンク制御チャネル（ＰＤＣＣＨ）として使用される領域である。ＰＤＣＣＨの詳細については後述する。また、各サブフレームの残りの部分は、主に下りリンクデータを伝送するための物理下りリンク共有チャネル（ＰＤＳＣＨ）として使用できる領域である。

上りリンクにおいて、各サブフレームにおける周波数方向の両端部は、主に上りリンク制御信号を伝送するための物理上りリンク制御チャネル（ＰＵＣＣＨ）として使用される領域である。各サブフレームにおける残りの部分は、主に上りリンクデータを伝送するための物理上りリンク共有チャネル（ＰＵＳＣＨ）として使用できる領域である。

（近傍サービス）
以下において、近傍サービス（ＰｒｏＳｅ：Ｐｒｏｘｉｍｉｔｙ−ｂａｓｅｄＳｅｒｖｉｃｅｓ）について説明する。ＰｒｏＳｅにおいて、複数のＵＥ１００は、ｅＮＢ２００を介さない直接的な無線リンクを介して各種の信号を送受信する。ＰｒｏＳｅにおける直接的な無線リンクは、「サイドリンク（Ｓｉｄｅｌｉｎｋ）」と称される。

「Ｓｉｄｅｌｉｎｋ」は、直接ディスカバリ及び直接通信のためのＵＥ−ＵＥ間インターフェイスである。「Ｓｉｄｅｌｉｎｋ」は、ＰＣ５インターフェイスに対応する。ＰＣ５は、直接ディスカバリ、直接通信及び近傍サービスによるＵＥ・ネットワーク中継のための制御及びユーザプレーンのために用いられる近傍サービスを利用可能なＵＥ間の参照点である。ＰＣ５インターフェイスは、ＰｒｏＳｅにおけるＵＥ−ＵＥ間インターフェイスである。

ＰｒｏＳｅのモードとしては、「直接ディスカバリ（ＤｉｒｅｃｔＤｉｓｃｏｖｅｒｙ）」及び「直接通信（ＤｉｒｅｃｔＣｏｍｍｕｎｉｃａｔｉｏｎ）」の２つのモードが規定されている。

直接ディスカバリは、特定の宛先を指定しないディスカバリ信号をＵＥ間で直接的に伝送することにより、相手先を探索するモードである。また、直接ディスカバリは、ＰＣ５を介してＥ−ＵＴＲＡ（ＥｖｏｌｖｅｄＵｎｉｖｅｒｓａｌＴｅｒｒｅｓｔｒｉａｌＲａｄｉｏＡｃｃｅｓｓ）における直接無線信号を用いて、ＵＥの近傍における他のＵＥを発見するための手順である。或いは、直接ディスカバリは、Ｅ−ＵＴＲＡ技術で２つのＵＥ１００の能力のみを用いて、近傍サービスを実行可能な他のＵＥ１００を発見するために近傍サービスを実行可能なＵＥ１００によって採用される手順である。直接ディスカバリは、ＵＥ１００がＥ−ＵＴＲＡＮ（ｅＮＢ２００（セル））によってサービスが提供される場合にのみ、サポートされる。ＵＥ１００は、セル（ｅＮＢ２００）に接続又はセルに在圏している場合、Ｅ−ＵＴＲＡＮ１０によってサービスが提供され得る。

ディスカバリ信号（ディスカバリメッセージ）の送信（アナウンスメント）のためのリソース割り当てタイプには、ＵＥ１００が無線リソースを選択する「タイプ１」と、ｅＮＢ２００が無線リソースを選択する「タイプ２（タイプ２Ｂ）」と、がある。

「ＳｉｄｅｌｉｎｋＤｉｒｅｃｔＤｉｓｃｏｖｅｒｙ」プロトコルスタックは、物理（ＰＨＹ）層、ＭＡＣ層、及びＰｒｏＳｅプロトコルを含む。ＵＥ（Ａ）の物理層とＵＥ（Ｂ）の物理層との間では、物理サイドリンクディスカバリチャネル（ＰＳＤＣＨ）と称される物理チャネルを介してディスカバリ信号が伝送される。ＵＥ（Ａ）のＭＡＣ層とＵＥ（Ｂ）のＭＡＣ層との間では、サイドリンクディスカバリチャネル（ＳＬ−ＤＣＨ）と称されるトランスポートチャネルを介してディスカバリ信号が伝送される。

直接通信は、特定の宛先（宛先グループ）を指定してデータをＵＥ間で直接的に伝送するモードである。また、直接通信は、いずれのネットワークノードを通過しない経路を介してＥ−ＵＴＲＡ技術を用いたユーザプレーン伝送による、近傍サービスを実行可能である２以上のＵＥ間の通信である。

直接通信のリソース割り当てタイプには、直接通信の無線リソースをｅＮＢ２００が指定する「モード１」と、直接通信の無線リソースをＵＥ１００が選択する「モード２」と、がある。

直接通信プロトコルスタックは、物理（ＰＨＹ）層、ＭＡＣ層、ＲＬＣ層、及びＰＤＣＰ層を含む。ＵＥ（Ａ）の物理層とＵＥ（Ｂ）の物理層との間では、物理サイドリンク制御チャネル（ＰＳＣＣＨ）を介して制御信号が伝送され、物理サイドリンク共有チャネル（ＰＳＳＣＨ）を介してデータが伝送される。また、物理サイドリンクブロードキャストチャネル（ＰＳＢＣＨ）を介して同期信号等が伝送されてもよい。ＵＥ（Ａ）のＭＡＣ層とＵＥ（Ｂ）のＭＡＣ層との間では、サイドリンク共有チャネル（ＳＬ−ＳＣＨ）と称されるトランスポートチャネルを介してデータが伝送される。ＵＥ（Ａ）のＲＬＣ層とＵＥ（Ｂ）のＲＬＣ層との間では、サイドリンクトラフィックチャネル（ＳＴＣＨ）と称される論理チャネルを介してデータが伝送される。

（ＵＥ・ネットワーク中継）
以下において、ＵＥ・ネットワーク中継について、図４を用いて説明する。図４は、実施形態に係るＵＥ・ネットワーク中継を説明するための図である。

図４において、リモートＵＥ（ＲｅｍｏｔｅＵＥ）は、Ｅ−ＵＴＲＡＮ１０によって直接サービスが提供されないＵＥ１００（Ｅ−ＵＴＲＡＮ１０によってサーブ（ｓｅｒｖｅ）されないＵＥ１００）である。リモートＵＥは、ネットワーク圏外（Ｏｕｔ−ｏｆ−Ｎｅｔｗｏｒｋ）（セルのカバレッジ外）に位置してもよい。リモートＵＥは、セルのカバレッジ内に位置していてもよい。また、リモートＵＥ１００は、後述するリレーＵＥを介してパケットデータネットワーク（ＰＤＮ：ＰａｃｋｅｔＤａｔａＮｅｔｗｏｒｋ）と通信できる。リモートＵＥは、公衆安全（ＰｕｂｌｉｃＳａｆｅｔｙ）のためのＵＥ（ＰｒｏＳｅ−ｅｎａｂｌｅｄＰｕｂｌｉｃＳａｆｅｔｙＵＥ）であってもよい。

なお、「ＰｒｏＳｅ−ｅｎａｂｌｅｄＰｕｂｌｉｃＳａｆｅｔｙＵＥ」は、ＨＰＬＭＮ（ＨｏｍｅＰｕｂｌｉｃＬａｎｄＭｏｂｉｌｅＮｅｔｗｏｒｋ）が公衆安全のための使用を許可するように構成されている。「ＰｒｏＳｅ−ｅｎａｂｌｅｄＰｕｂｌｉｃＳａｆｅｔｙＵＥ」は、近傍サービスを利用可能であり、近傍サービスにおける手順及び公衆安全のための特定の能力をサポートしている。例えば、「ＰｒｏＳｅ−ｅｎａｂｌｅｄＰｕｂｌｉｃＳａｆｅｔｙＵＥ」は、公衆安全のための情報を近傍サービスにより送信する。公衆安全のための情報とは、例えば、災害（地震・火災など）に関する情報、消防関係者又は警察関係者に用いられる情報などである。

リモートＵＥは、後述するように、リレーＵＥからＰｒｏＳｅ中継サービスを提供される。ＰｒｏＳｅ中継サービスが提供されるリモートＵＥとＰｒｏＳｅ中継サービスを提供するリレーＵＥとの間で、ＵＥ・ネットワーク中継が実行される。

リレーＵＥ（ＰｒｏＳｅＵＥ−ｔｏＮｅｔｗｏｒｋＲｅｌａｙ）は、ＰｒｏＳｅ中継サービスをリモートＵＥのために提供する。具体的には、リレーＵＥは、リモートＵＥのためにパケットデータネットワークとの通信のサービス継続性を提供する。従って、リレーＵＥは、リモートＵＥとネットワークとの間でデータ（ユニキャストトラフィック）を中継する。リレーＵＥは、近傍サービス（直接通信）によりリモートＵＥのデータ（トラフィック）を中継する。具体的には、リレーＵＥは、ＰＣ５インターフェイスを介してリモートＵＥから受信したデータ（上りトラフィック）を、Ｕｕインターフェイス（ＬＴＥ−Ｕｕ）又はＵｎインターフェイス（ＬＴＥ−Ｕｎ）を介してｅＮＢ２００に中継する。また、リレーＵＥは、Ｕｕインターフェイス又はＵｎインターフェイスを介してｅＮＢ２００から受信したデータ（下りトラフィック）をＰＣ５インターフェイスを介してリモートＵＥへ中継する。リレーＵＥは、ネットワーク内（セルのカバレッジ内）にのみ位置する。

また、リレーＵＥは、公衆安全のための通信に関係する任意のタイプのトラフィックを中継できる包括的な機能を提供することができる。

リレーＵＥとリモートＵＥは、物理層間でデータ及び制御信号を伝送できる。同様に、リレーＵＥとリモートＵＥは、ＭＡＣ層間、ＲＬＣ層間及びＰＤＣＰ層間でデータ及び制御信号を伝送できる。さらに、リレーＵＥは、ＰＤＣＰ層の上位層としてＩＰリレー（ＩＰ−Ｒｅｌａｙ）層を有してもよい。リモートＵＥは、ＰＤＣＰ層の上位層としてＩＰ層を有してもよい。リレーＵＥとリモートＵＥとは、ＩＰリレー層とＩＰ層との間でデータ及び制御信号を伝送できる。また、リレーＵＥは、ＩＰリレー層とＰＧＷ３５０のＩＰ層との間でデータを伝送できる。

なお、リレーＵＥは、ＡＳ層（ＡｃｃｅｓｓＳｔｒａｔｕｍ）において、ブロードキャストを用いてリモートＵＥにデータ（トラフィック）を送信できる。リレーＵＥは、ＡＳ層において、ユニキャストを用いてリモートＵＥにデータを送信してもよい。なお、ＵＥ・ネットワーク中継がブロードキャストを用いて実行されている場合、リレーＵＥとリモートＵＥとの間において、ＡＳ層におけるフィードバックは行われないが、ＮＡＳ層（ＮｏｎＡｃｃｅｓｓＳｔｒａｔｕｍ）におけるフィードバックは行われてもよい。また、ＵＥ・ネットワーク中継がユニキャストを用いて実行されている場合、ＡＳ層におけるフィードバックが行われてもよい。

（無線端末）
以下において、実施形態に係るＵＥ１００（無線端末）について説明する。図５は、ＵＥ１００のブロック図である。図５に示すように、ＵＥ１００は、レシーバ（Ｒｅｃｅｉｖｅｒ：受信部）１１０、トランスミッタ（Ｔｒａｎｓｍｉｔｔｅｒ：送信部）１２０、及びコントローラ（Ｃｏｎｔｒｏｌｌｅｒ：制御部）１３０を備える。レシーバ１１０とトランスミッタ１２０とは、一体化されたトランシーバ（送受信部）であってもよい。

レシーバ１１０は、コントローラ１３０の制御下で各種の受信を行う。レシーバ１１０は、アンテナを含む。レシーバ１１０は、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換してコントローラ１３０に出力する。

なお、ＵＥ１００は、「ＰｒｏＳｅ−ｅｎａｂｌｅｄＰｕｂｌｉｃＳａｆｅｔｙＵＥ」である場合、レシーバ１１０は、異なる２つの周波数における無線信号を同時に受信可能である。例えば、ＵＥ１００は、２つのレシーバ１１０（２ＲＸＣｈａｉｎ）を有する。ＵＥ１００は、一方のレシーバ１１０によりセルラ用の無線信号を受信でき、他方のレシーバ１１０によりＰｒｏＳｅ用の無線信号を受信できる。

トランスミッタ１２０は、コントローラ１３０の制御下で各種の送信を行う。トランスミッタ１２０は、アンテナを含む。トランスミッタ１２０は、コントローラ１３０が出力するベースバンド信号（送信信号）を無線信号に変換してアンテナから送信する。

コントローラ１３０は、ＵＥ１００における各種の制御を行う。コントローラ１３０は、プロセッサ及びメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に使用される情報を記憶する。プロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行うベースバンドプロセッサと、メモリに記憶されるプログラムを実行して各種の処理を行うＣＰＵ（ＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔ）と、を含む。プロセッサは、音声・映像信号の符号化・復号を行うコーデックを含んでもよい。プロセッサは、後述する各種の処理及び上述した各種の通信プロトコルを実行する。

ＵＥ１００は、ＧＮＳＳ受信機を備えていてもよい。ＧＮＳＳ受信機は、ＵＥ１００の地理的な位置を示す位置情報を得るために、ＧＮＳＳ信号を受信して、受信した信号をコントローラ１３０に出力する。或いは、ＵＥ１００は、ＵＥ１００の位置情報を取得するためのＧＰＳ機能を有していてもよい。

（基地局）
以下において、実施形態に係るｅＮＢ２００（基地局）について説明する。図６は、ｅＮＢ２００のブロック図である。図６に示すように、ｅＮＢ２００は、レシーバ（受信部）２１０、トランスミッタ（送信部）２２０、コントローラ（制御部）２３０、及びネットワークインターフェイス（バックホール通信部）２４０を備える。レシーバ２１０とトランスミッタ２２０とは、一体化されたトランシーバ（送受信部）であってもよい。

レシーバ２１０は、コントローラ２３０の制御下で各種の受信を行う。レシーバ２１０は、アンテナを含む。レシーバ２１０は、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換してコントローラ２３０に出力する。

トランスミッタ２２０は、コントローラ２３０の制御下で各種の送信を行う。トランスミッタ２２０は、アンテナを含む。トランスミッタ２２０は、コントローラ２３０が出力するベースバンド信号（送信信号）を無線信号に変換してアンテナから送信する。

コントローラ２３０は、ｅＮＢ２００における各種の制御を行う。コントローラ２３０は、プロセッサ及びメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に使用される情報を記憶する。プロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行うベースバンドプロセッサと、メモリに記憶されるプログラムを実行して各種の処理を行うＣＰＵ（ＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔ）と、を含む。プロセッサは、後述する各種の処理及び上述した各種の通信プロトコルを実行する。

ネットワークインターフェイス（バックホール通信部）２４０は、Ｘ２インターフェイスを介して隣接ｅＮＢ２００と接続され、Ｓ１インターフェイスを介してＭＭＥ／Ｓ−ＧＷ３００と接続される。ネットワークインターフェイス２４０は、Ｘ２インターフェイス上で行う通信及びＳ１インターフェイス上で行う通信等に使用される。

（既存技術の概要）
次に、既存技術の概要について、図７を用いて説明する。図７は、既存技術の概要を説明するための図である。

ＵＥ１００−１が、直接通信により複数のＵＥ１００のそれぞれにデータを送信するケースを例を挙げて説明する。

直接通信に用いられる無線リソースプールは、サイドリンク用の制御情報（ＳＣＩ：ＳｉｄｅｌｉｎｋＣｏｎｔｒｏｌＩｎｆｏｒｍａｔｉｏｎ）が配置される制御領域（ＳＣプール：ＳＣｐｏｏｌ）と、データが配置されるデータ領域（データプール：Ｄａｔａｐｏｏｌ）とによって構成される。なお、モード１では、データ領域は、時間方向において、制御領域の後に続く領域である。モード２では、データ領域は、時間方向において、制御領域と重複することもある。

図７に示すように、複数の無線リソースプールが時間方向に配置される。１つの無線リソースプールの時間方向の長さは、無線リソースプールの周期であるＳＣ期間（ＳＣＰｅｒｉｏｄ）と一致する。

ここで、ＵＥ１００−１が、互いに宛先が異なる複数のグループ（グループ１−５）のそれぞれにデータを送信するケースを想定する。リリース１２では、１つのＳＣ期間において、１つのＳＣＩしか送信できない。このため、ＵＥ１００−１が、複数のグループに順番にデータを送信すると仮定して説明する。この場合、ＵＥ１００−１は、第１のＳＣ期間にグループ１にＳＣＩを送信し、当該ＳＣＩにより示される無線リソースでグループ１宛てにデータを送信する。ＵＥ１００−１は、第１のＳＣ期間の次の期間（第２のＳＣ期間）にグループ２にＳＣＩを送信し、当該ＳＣＩにより示される無線リソースでグループ１宛てにデータを送信する。同様に、ＵＥ１００−１は、他のグループにＳＣＩを送信する。ＵＥ１００−１は、複数のグループ全てにＳＣＩを送信した後に、グループ１に次のデータを送信するために（第６のＳＣ期間に）次のＳＣＩを送信する。このように、ＵＥ１００−１は、複数のグループのそれぞれにデータを送信する場合、「（ＳＣ期間長）×（宛先の数−１）」の時間だけ遅延が発生するという問題がある。

特に、ＵＥ１００−１がリレーＵＥであり、複数のリモートＵＥを収容する（サーブ）ケースにおいても同じ問題が生じることが想定される。そこで、本出願では、以下に説明する技術により、上述の問題を解消することを一つの目的とする。

なお、以下で説明するＵＥ１００が実行する処理（動作）について、ＵＥ１００が備えるレシーバ１１０、トランスミッタ１２０、コントローラ１３０の少なくともいずれかが実行するが、便宜上、ＵＥ１００が実行する処理として説明する。同様に、以下で説明するｅＮＢ２００が実行する処理（動作）について、ｅＮＢ２００が備えるレシーバ２１０、トランスミッタ２２０、コントローラ２３０、ネットワークインターフェイス（バックホール通信部）２４０の少なくともいずれかが実行するが、便宜上、ｅＮＢ２００が実行する処理として説明する。

また、以下において、既出の動作と同じ動作の説明を適宜省略する。

［第１実施形態］
第１実施形態について説明する。第１実施形態では、１つのＳＣプール内で、複数のＳＣＩが送信されるケースを説明する。

（第１実施形態に係る動作環境）
次に、第１実施形態に係る動作環境を図８を用いて説明する。図８は、第１実施形態に係る動作環境を説明するための図である。

図８に示すように、ＵＥ１００−１は、ｅＮＢ２００が管理するセル内に位置する。ＵＥ１００−１は、ｅＮＢ２００とセルラ通信（ＬＴＥ−Ｕｕ）を実行可能である。ＵＥ１００−１は、ＲＲＣコネクティッド状態である。或いは、ＵＥ１００−１は、ＲＲＣアイドル状態であってもよい。ＵＥ１００−１は、ｅＮＢ２００と通信を行う場合に、ＲＲＣアイドル状態からＲＲＣコネクティッド状態に移行してもよい。

ＵＥ１００−１は、リモートＵＥである複数のＵＥ１００（ＵＥ１００−２〜１００−４）をサーブするリレーＵＥである。複数のＵＥ１００の宛先、すなわち、宛先識別子（ＤｅｓｔｉｎａｔｉｏｎＩＤ）は、互いに異なる。

なお、以下において、ＵＥ１００−３及びＵＥ１００−４の動作は、他のＵＥと同様である場合、説明を適宜省略する。

（Ａ）モード１
ｅＮＢ２００が直接通信の無線リソースを指定するモード１で、ＵＥ１００−１が直接通信を実行するケースを説明する。モード１において適用可能な第１から第３の方法について説明する。

（Ａ１）第１の方法
第１の方法について、図９を用いて説明する。図９は、第１実施形態に係る動作（その１）を説明するためのシーケンス図である。

図９に示すように、ステップＳ１０１において、ｅＮＢ２００は、ＵＥ１００−１に複数のＳＬ−ＲＮＴＩ（ＳＬ−ＲＮＴＩ１、２）を割り当てる（設定する）。ＳＬ−ＲＮＴＩ（ＳｉｄｅｌｉｎｋＲａｄｉｏＮｅｔｗｏｒｋＴｅｍｐｏｒａｒｙＩｄｅｎｔｉｆｉｅｒ）は、直接通信で用いられる無線リソースの割当情報を含む制御情報（ＤＣＩ：ＤｏｗｎｌｉｎｋＣｏｎｔｒｏｌＩｎｆｏｒｍａｔｉｏｎ）に対応付けられた識別子（ＳＬ識別子に相当）である。なお、ＳＬ−ＲＮＴＩは、サイドリンク送信用の専用の識別子である。ＤＣＩ（ＤＣＩフォーマット５）は、サイドリンク送信用の制御情報である。また、ＤＣＩは、無線リソースの割当情報を含むＳＬグラントを含む。なお、ＤＣＩフォーマット５には、ＳＣＩフォーマット０の中にそのまま入れる情報と、ＳＣＩフォーマット０を送るためのリソース情報が含まれる。

ｅＮＢ２００は、ＲＲＣ接続再設定（ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎ）を実行する際に、ＵＥ１００−１に複数のＳＬ−ＲＮＴＩを割り当ててもよい。

ｅＮＢ２００は、ＵＥ１００−１がリレーＵＥである場合に、ＵＥ１００−１に複数のＳＬ−ＲＮＴＩを割り当ててもよい。ｅＮＢ２００は、ＵＥ１００−１がリレーＵＥであるか否かをＵＥ１００−１からの通知に基づいて判断してもよい。或いは、ｅＮＢ２００は、ＵＥ１００−１が有する宛先の数が所定値を越えた場合に、ＵＥ１００−１に複数のＳＬ−ＲＮＴＩを割り当ててもよい。例えば、ｅＮＢ２００は、ＵＥ１００−１がサーブするリモートＵＥの数が所定値を越えた場合に、ＵＥ１００−１に複数のＳＬ−ＲＮＴＩを割り当ててもよい。

ｅＮＢ２００は、複数のＳＬ−ＲＮＴＩのサーチスペースが特定のＳＬ−ＲＮＴＩと関連付くように、ＵＥ１００−１に複数のＳＬ−ＲＮＴＩを割り当ててもよい。例えば、ｅＮＢ２００は、連番の複数のＳＬ−ＲＮＴＩをＵＥ１００−１に割り当てることができる。

その後、ｅＮＢ２００は、複数のＳＬ−ＲＮＴＩ毎に無線リソースを確保する。その結果、ｅＮＢ２００は、ＵＥ１００−１のために複数の無線リソースを確保する。ｅＮＢ２００は、確保した各無線リソースの割当情報のそれぞれを各ＤＣＩに含める。これにより、ｅＮＢ２００は、１つの割当情報を含むＤＣＩを複数生成する。

ステップＳ１０２において、ｅＮＢ２００は、複数のＳＬ−ＲＮＴＩに対応する複数のＤＣＩ（ＤＣＩ１、ＤＣＩ２）をＵＥ１００−１に送信する。ｅＮＢ２００は、所定のＳＣ期間が始まる前（具体的には、４サブフレーム前）までに、複数のＤＣＩを送信する。ｅＮＢ２００は、特定のＳＬ−ＲＮＴＩと関連付けられたサーチスペースに複数のＤＣＩを配置してもよい。

ＵＥ１００−１は、複数のＳＬ−ＲＮＴＩに基づいて、複数のＤＣＩを受信する。ここで、ＵＥ１００−１は、特定のＳＬ−ＲＮＴＩと関連付けられたサーチスペースのみをサーチすることによって複数のＤＣＩを受信してもよい。これにより、ＵＥ１００−１は、複数のサーチスペースをサーチする必要がないため、ＵＥ１００−１の処理負荷を低減できる。

ＵＥ１００−１は、所定のＳＣ期間が始まる前に複数のＤＣＩを受信しているため、複数のＤＣＩのそれぞれに含まれる割当情報に基づいて、各データの送信に用いる無線リソースを決定する。ＵＥ１００−１は、決定した無線リソースの割当情報を含むＳＣＩを生成する。具体的には、ＵＥ１００−１は、ＵＥ１００−２のデータの送信用の無線リソースの割当情報を含むＳＣＩ１を生成し、ＵＥ１００−３のデータの送信用の無線リソースの割当情報を含むＳＣＩ２を生成する。ＳＣＩ１は、ＵＥ１００−２宛ての宛先識別子を含み、ＳＣＩ２は、ＵＥ１００−３宛ての宛先識別子を含む。

ステップＳ１０３において、ＵＥ１００−１は、複数のＳＣＩをＵＥ１００−２及びＵＥ１００−３に送信する。その後、ＵＥ１００−１は、各無線リソースの割当情報に基づいて、ＵＥ１００−２のデータ及びＵＥ１００−３のデータを送信する。ＵＥ１００−２は、ＵＥ１００−２宛てのＳＣＩ１に含まれる無線リソースの割当情報に基づいて、ＵＥ１００−２のデータを受信する。一方、ＵＥ１００−３は、ＵＥ１００−３宛てのＳＣＩ２に含まれる無線リソースの割当情報に基づいて、ＵＥ１００−３のデータを受信する。

以上のように、ＵＥ１００−１は、１つのＳＣ期間において、複数のＳＣＩを送信できるため、データ送信の遅延が発生することを抑制できる。また、ｅＮＢ２００が無線リソースを割り当てているため、干渉が発生することを低減できる。

（Ａ２）第２の方法
第２の方法について、図１０及び図１１を用いて説明する。図１０は、第１実施形態に係る動作（その２）を説明するためのシーケンス図である。図１１は、第１実施形態に係る動作（その２）を説明するための拡張ＤＣＩフォーマットの一例の図である。

図１０に示すように、ステップＳ２０１において、ｅＮＢ２００は、ＵＥ１００−１に単一のＳＬ−ＲＮＴＩを割り当てる。

ｅＮＢ２００は、１つの無線リソースプールにおいて、複数の無線リソースを確保する。なお、本明細書において、「複数の無線リソース」は、原則として、ＳＣプールにおける複数の無線リソース及びデータプールにおける複数の無線リソースを意味する。「複数の無線リソース」は、ＳＣプールにおける単一の無線リソースとデータプールにおける単一の無線リソースとによって構成される複数の無線リソースを意味するものではない。

ｅＮＢ２００は、確保した第１の無線リソースの割当情報とインデックス１とを含むＤＣＩ１を生成する。また、ｅＮＢ２００は、確保した第２の無線リソースの割当情報とインデックス２とを含むＤＣＩ２を生成する。本実施形態において、これらのインデックスの値は、異なる。

図１１に示すように、（拡張）ＤＣＩフォーマットは、インデックスに相当する「Ｒｅｓｏｕｒｃｅｐｏｏｌｉｎｄｅｘ」を含む。当該インデックスは、１つのＳＣ期間において複数の無線リソース使用可能か否かを示す。すなわち、当該インデックスは、複数のＳＣＩを同時送信可能か否かを示す。当該インデックスは、例えば、整数であり、１〜最大同時送信ＳＣＩ数の値を取り得る。

なお、図１１において「ＲｅｓｏｕｒｃｅｆｏｒＰＳＣＣＨ」は、ＰＳＣＣＨリソース割り当て識別子である。「ＴＰＣｃｏｍｍａｎｄｆｏｒＰＳＣＣＨ＆ＰＳＳＣＨ」は、送信電力情報である。「Ｆｒｅｑｕｅｎｃｙｈｏｐｐｉｎｇｆｌａｇ」は、周波数ホッピング情報である。「Ｒｅｓｏｕｒｃｅｂｌｏｃｋａｓｓｉｇｎｍｅｎｔ＆ｈｏｐｐｉｎｇｒｅｓｏｕｒｃｅａｌｌｏｃａｔｉｏｎ」は、周波数方向リソース割当情報である。「Ｔｉｍｅｒｅｓｏｕｒｃｅｐａｔｔｅｒｎ」は、時間方向サブフレーム割当パターン情報である。なお、「ＲｅｓｏｕｒｃｅｆｏｒＰＳＣＣＨ」、「Ｆｒｅｑｕｅｎｃｙｈｏｐｐｉｎｇｆｌａｇ」、「Ｒｅｓｏｕｒｃｅｂｌｏｃｋａｓｓｉｇｎｍｅｎｔ＆ｈｏｐｐｉｎｇｒｅｓｏｕｒｃｅａｌｌｏｃａｔｉｏｎ」、「Ｔｉｍｅｒｅｓｏｕｒｃｅｐａｔｔｅｒｎ」は、ＳＬグラントを構成する。

ステップＳ２０２において、ｅＮＢ２００は、複数のＤＣＩを送信する。ＵＥ１００−１は、複数のＤＣＩを受信する。これにより、ＵＥ１００−１は、ＤＣＩ１に含まれる無線リソースの割当情報１とＤＣＩ２に含まれる無線リソースの割当情報２とを取得する。

ＵＥ１００−１は、最初に取得した割当情報１に基づく第１の無線リソースだけでなく、次に取得した割当情報２に基づく第２の無線リソースを使用可能かを、インデックスに基づいて、判断する。具体的には、ＵＥ１００−１は、ＤＣＩ１に含まれるインデックス１とＤＣＩ２に含まれるインデックス２とが異なる値であるか否かを判断する。ＵＥ１００−１は、これらのインデックスが異なる値である場合、第１の無線リソースだけでなく、第２の無線リソースも使用可能であると判断する。一方、ＵＥ１００−１は、これらのインデックスが同じ値である場合、ＤＣＩ１の情報をＤＣＩ２の情報に上書きする。

なお、既存技術では、ＤＣＩには当該インデックスは含まれていない。ＵＥは、新たなＤＣＩを受信した場合、保持しているＤＣＩの情報を新たなＤＣＩの情報で上書きする。

ステップＳ２０３は、ステップＳ１０３に対応する。

以上のように、ＵＥ１００−１は、複数の無線リソースが割り当てられることが可能であるため、データ送信の遅延が発生することを抑制できる。また、ｅＮＢ２００が無線リソースを割り当てているため、干渉が発生することを低減できる。

（Ａ３）第３の方法
第３の方法について、図１２及び図１３を用いて説明する。図１２は、第１実施形態に係る動作（その３）を説明するためのシーケンス図である。図１３は、第１実施形態に係る動作（その３）を説明するための拡張ＤＣＩフォーマットの一例の図である。

図１２において、ステップＳ３０１において、ｅＮＢ２００は、ＵＥ１００−１に単一のＳＬ−ＲＮＴＩを割り当てる。

ｅＮＢ２００は、１つの無線リソースプールおいて、複数の無線リソースプールを確保する。ｅＮＢ２００は、複数の無線リソースプールそれぞれの割当情報からなる複数の割当情報を含むＤＣＩを生成する。具体的には、ｅＮＢ２００は、複数の割当情報に対応する複数のＳＬグラント（太枠参照）を含むＤＣＩを生成する。

図１３に示すように、（拡張）ＤＣＩフォーマットは、複数のＳＬグラントを含む。ここで、１つのＳＬグラントは、「ＲｅｓｏｕｒｃｅｆｏｒＰＳＣＣＨ」、「Ｆｒｅｑｕｅｎｃｙｈｏｐｐｉｎｇｆｌａｇ」、「Ｒｅｓｏｕｒｃｅｂｌｏｃｋａｓｓｉｇｎｍｅｎｔ＆ｈｏｐｐｉｎｇｒｅｓｏｕｒｃｅａｌｌｏｃａｔｉｏｎ」、「Ｔｉｍｅｒｅｓｏｕｒｃｅｐａｔｔｅｒｎ」及び「Ｒｅｓｏｕｒｃｅｐｏｏｌｉｎｄｅｘ」により構成される。ＳＬグラントは、「Ｒｅｓｏｕｒｃｅｐｏｏｌｉｎｄｅｘ」（インデックス）を含まなくてもよい。

ｅＮＢ２００は、ＳＬグラントは、「Ｒｅｓｏｕｒｃｅｐｏｏｌｉｎｄｅｘ」を含む場合、複数の無線リソースプールそれぞれの割当情報に対応するインデックスを互いに異なる値に設定する。これにより、ＵＥ１００が、複数のＳＬグラントのいずれかに基づいて保持しているＤＣＩ（ＳＬグラント）の情報に上書きすることを抑制できる。

ステップＳ３０２において、ｅＮＢ２００は、ｅＮＢ２００は、１つのＤＣＩを送信し、ＵＥ１００−１は、１つのＤＣＩを受信する。これにより、ＵＥ１００−１は、ＤＣＩに含まれる複数の無線リソースの割当情報を取得する。

ステップＳ３０３は、ステップＳ１０３に対応する。

（Ｂ）モード２
次に、直接通信の無線リソースをＵＥ１００が選択するモード２で、ＵＥ１００−１が直接通信を実行するケースを、図１４及び図１５を用いて説明する。図１４は、第１実施形態に係る動作（その４）を説明するためのシーケンス図である。図１５は、第１実施形態に係る動作（その４）を説明するためのＳＣＩ割り当ての一例の図である。

図１４に示すように、ステップＳ４０１において、ｅＮＢ２００は、モード２において用いられる無線リソースプールをＵＥ１００−１に設定するための設定情報をＵＥ１００−１に送信する。ＵＥ１００−１は、設定情報に基づいて、無線リソースプールを設定する。なお、ＵＥ１００−１は、事前に設定された無線リソースプールを設定してもよい。また、ここで設定される無線リソースプールは、複数の制御情報を同時に送信することができる無線リソースプールであってもよい。

ステップＳ４０２において、ｅＮＢ２００は、複数の制御情報を１つのＳＣ期間で（又は同時に）送信することができる無線リソースプールを使用することを許可する許可情報をＵＥ１００−２に送信する。或いは、ｅＮＢ２００は、設定した無線リソースプールにおいて複数の制御情報を１つのＳＣ期間で（又は同時に）送信することを許可する許可情報をＵＥ１００−２に送信する。ｅＮＢ２００は、設定情報と共に許可情報を送信してもよい。

ｅＮＢ２００は、ＵＥ１００−１がリレーＵＥである場合に、許可情報をＵＥ１００−２に送信してもよい。ｅＮＢ２００は、ＵＥ１００−１がリレーＵＥであるか否かをＵＥ１００−１からの通知に基づいて判断してもよい。或いは、ｅＮＢ２００は、ＵＥ１００−１が有する宛先の数が所定値を越えた場合に、許可情報をＵＥ１００−２に送信してもよい。例えば、ｅＮＢ２００は、ＵＥ１００−１がサーブするリモートＵＥの数が所定値を越えた場合に、許可情報をＵＥ１００−２に送信してもよい。

ＵＥ１００−１は、ｅＮＢ２００からの許可情報を受信しない場合には、設定された複数の無線リソースプールから１つの制御情報を送信するための無線リソースを選択する。

一方、ｅＮＢ２００からの許可情報を受信したＵＥ１００−１は、ｅＮＢ２００からの許可に応じて、設定された無線リソースプールから、複数の無線リソースを選択できる。

ここで、ＵＥ１００−１が、ＳＣＩの送信に用いる無線リソースを選択する一例を説明する。

図１５に示すように、ＵＥ１００−１は、複数のＳＣＩが時間方向で衝突しないように無線リソースを選択することが好ましい。これにより、リリース１２端末も受信が可能になり、後方互換性が担保される。

ステップＳ４０３は、ステップＳ１０３に対応する。

以上のように、ＵＥ１００−１は、複数の無線リソースを選択できるため、１つのＳＣ期間で（又は同時に）複数のＳＣＩを送信できる。このため、データ送信の遅延が発生することを抑制できる。また、ＵＥ１００−１は、ｅＮＢ２００の許可を得た上で、無線リソースを選択しているため、干渉が発生することを低減できる。

（Ｃ）データ送信用の無線リソースの選択
次に、データ送信用の無線リソースの選択について、図１６を用いて説明する。図１６は、第１実施形態に係る動作（その５）を説明するための図である。

データ送信用の無線リソースの選択方法は、モード１及びモード２のいずれでも適用することができる。

図１６に示すように、ＵＥ１００−１は、複数の宛先（Ｄｅｓｔｉｎａｔｉｏｎ１〜３）のそれぞれにデータを送信するための複数の無線リソースを選択する場合、複数の無線リソースのそれぞれが互いに時間方向で重ならないように選択する。これにより、ＰＡＰＲ（ＰｅａｋｔｏＡｖｅｒａｇｅＰｏｗｅｒＲａｔｉｏ（１ピーク電力対平均電力比））問題を解消できる。

［第２実施形態］
次に、第２実施形態について説明する。第２実施形態では、１つのＳＣＩで複数の宛先識別子（ＤｅｓｔｉｎａｔｉｏｎＩＤ）を通知するケースを中心に説明する。なお、第１実施形態と同様の部分は、説明を省略する。

（Ｄ）第１の方法
第１の方法について、図１７及び図１８を用いて説明する。図１７は、第２実施形態に係る動作（その１）を説明するための拡張ＳＣＩフォーマットの一例の図である。図１８は、第２実施形態に係る動作（その１）を説明するための拡張ＤＣＩフォーマットの一例の図である。

第１の方法では、ＳＣＩ格納フィールドを変更し、複数の宛先（ＤｅｓｔｉｎａｔｉｏｎＩＤ）向けの割当情報を含む拡張ＳＣＩが用いられる。

図１７に示すように、拡張ＳＣＩは、複数の無線リソースの割当情報（太枠参照）を含む。割当情報は、例えば、「Ｆｒｅｑｕｅｎｃｙｈｏｐｐｉｎｇｆｌａｇ」、「Ｒｅｓｏｕｒｃｅｂｌｏｃｋａｓｓｉｇｎｍｅｎｔ＆ｈｏｐｐｉｎｇｒｅｓｏｕｒｃｅａｌｌｏｃａｔｉｏｎ」、「Ｔｉｍｅｒｅｓｏｕｒｃｅｐａｔｔｅｒｎ」、「Ｍｏｄｕｌａｔｉｏｎ＆ｃｏｄｉｎｇｓｃｈｅｍｅ（ＭＣＳ）」により構成される。割当情報と割当情報に対応する宛先識別子（グループｄｅｓｔｉｎａｔｉｏｎＩＤ）とのセットから成る複数のセットを拡張ＳＣＩは、含む。

なお、「Ｔｉｍｅａｄｖａｎｃｅｉｎｄｉｃａｔｉｏｎ」は、送信タイミングに関する補正値である。また、「Ｎｕｍｂｅｒｏｆｄｅｓｔｉｎａｔｉｏｎｓ」は、１つの拡張ＳＣＩが同時に指定できるデータリソースの上限を示す。すなわち、「Ｎｕｍｂｅｒｏｆｄｅｓｔｉｎａｔｉｏｎｓ」は、拡張ＳＣＩが含む割当情報の最大の数を示す。図１７の例では、拡張ＳＣＩは、１６個の割当情報を含み得る。

ＵＥ１００−１は、複数の無線リソースを選択し、拡張ＳＣＩを生成する。ＵＥ１００−１は、拡張ＳＣＩを生成するために、以下の方法を実行できる。

例えば、ＵＥ１００−１は、１つの割当情報を含む既存ＳＣＩに適用するＳＣＩに適用するＭＣＳよりも伝送レートの高いＭＣＳを拡張ＳＣＩに適用することができる。

また、ＵＥ１００−１は、既存ＳＣＩよりも多い無線リソース量を拡張ＳＣＩの送信のために割り当ててもよい。ＵＥ１００−１は、割り当てられた無線リソースを用いて拡張ＳＣＩを送信できる。

ＵＥ１００−１は、複数の無線リソースそれぞれの割当情報を含む生成した拡張ＳＣＩを複数の宛先に向けて送信する。ＵＥ１００−１は、拡張ＳＣＩを送信するための無線リソースを事前設定された無線リソースプールの中から選択してもよい。ＵＥ１００−１は、セルのカバレッジ外に位置するネットワーク圏外のＵＥに事前設定された無線リソースプールの中から、当該無線リソースを選択することにより、ネットワーク圏外のＵＥも、拡張ＳＣＩを取得できる。或いは、ＵＥ１００−１は、リレーＵＥによって通知される無線リソースプールの中から、当該無線リソースを選択してもよい。例えば、ＵＥ１００−１がリレーＵＥである場合に、ＵＥ１００−１は、無線リソースプールをリモートＵＥに通知する。ＵＥ１００−１は、通知した無線リソースプール中から拡張ＳＣＩを送信するための無線リソースを選択できる。これにより、リモートＵＥは、拡張ＳＣＩを取得できる。

なお、モード１において、第１の方法を適用する場合、ｅＮＢ２００が、複数の宛先への割当情報をＵＥ１００へ送信する必要がある。このため、上述の第１実施形態と同様にＤＣＩに、当該割当情報を含める。具体的には、図１８に示すように、ＤＣＩは、１つのＳＣＩ送信用の割当情報（パラメータ：「ＲｅｓｏｕｒｃｅｆｏｒＰＳＣＣＨ」、「ＴＰＣｃｏｍｍａｎｄｆｏｒＰＳＣＣＨ＆ＰＳＳＣＨ」、「Ｆｒｅｑｕｅｎｃｙｈｏｐｐｉｎｇｆｌａｇ」）を含み、複数のデータ用の割当情報（パラメータ：「Ｒｅｓｏｕｒｃｅｂｌｏｃｋａｓｓｉｇｎｍｅｎｔ＆ｈｏｐｐｉｎｇｒｅｓｏｕｒｃｅａｌｌｏｃａｔｉｏｎ」、「Ｔｉｍｅｒｅｓｏｕｒｃｅｐａｔｔｅｒｎ」、「Ｒｅｓｏｕｒｃｅｐｏｏｌｉｎｄｅｘ」）を含む。

また、モード２において、ＰＡＰＲ問題を解消するため、上述した第１実施形態の通り、ＵＥ１００−１は、データ送信用の無線リソースを選択することが好ましい。

（Ｅ）第２の方法
次に、第２の方法について、図１９を用いて説明する。図１９は、第２実施形態に係る動作（その２）を説明するための図である。

第２の方法では、ＵＥ１００−１は、パケット（ＭＡＣＰＤＵ（ＭＡＣＰｒｏｔｏｃｏｌＤａｔａＵｎｉｔ））を拡張し、当該パケットに複数の宛先のそれぞれのデータを含める（すなわち、複数のデータをＭＡＣＰＤＵに多重する）。従って、ＵＥ１００−１は、複数の宛先それぞれのデータからなる複数のデータを含むパケットを生成する。また、ＵＥ１００は、特別な宛先識別子を用いることにより、パケットが複数の宛先のデータを含むことを複数の受信ＵＥ（ＵＥ１００−２〜１００−４）に通知する。

ＵＥ１００−１は、複数の宛先の複数のデータがパケットに含まれることを示す特別な宛先識別子（例えば、特別なＬ１ｄｅｓｔｉｎａｔｉｏｎＩＤ）と、複数の宛先に対応する複数の受信ＵＥがパケットを受信するための無線リソースの割当情報を含むＳＣＩを送信する。

特別な宛先識別子は、例えば、ブロードキャスト用の識別子である。或いは、特別な宛先識別子は、ＵＥ１００−１がリレー端末である場合に用いられる識別子の少なくとも一部からなるものであってもよい。従って、特別な宛先識別子は、同一のＵＥ１００（同一のリレーＵＥ）に接続するリモートＵＥが特別な宛先識別子が同一であると認識できるようなものであってもよい。例えば、特別な宛先識別子は、リレーＵＥの識別子であるＬ２ＲｅｌａｙＵＥＩＤであってもよい。或いは、特別な宛先識別子は、リレーＵＥの識別子（ＲｅｌａｙＵＥＩＤ）の一部であってよい。例えば、特別な宛先識別子は、リレーＵＥの識別子（ＲｅｌａｙＵＥＩＤ）のＭＳＢ（ＭｏｓｔＳｉｇｎｉｆｉｃａｎｔＢｉｔ）であってもよい。

図１９に示すように、リモートＵＥは、リレーＵＥからディスカバリ信号（ＲｅｌａｙＤｉｓｃｏｖｅｒｙ）により通知されたリレーＵＥの識別子（ＲｅｌａｙＵＥＩＤ）のＭＳＢ（例えば、先頭の８ビット）を、特別な宛先識別子として記憶する。

なお、図１９に示すように、リレーＵＥは、リレーＵＥ自身の宛先識別子として、リレーＵＥの識別子（ＲｅｌａｙＵＥＩＤ）のＭＳＢと、自身のＬ２ＵＥＩＤのＭＳＢ（例えば、先頭の１６ビット）又はＬＳＢ（ＬａｓｔＳｉｇｎｉｆｉｃａｎｔＢｉｔ：最終の重要ビット）とを結合した新たな識別子（ＲｅｍｏｔｅＵＥ’ｓＬ２ＩＤ）を生成してもよい。当該新たな識別子が、用いられてもよい。

以上のように、ＵＥ１００−１は、特別な宛先識別子を他のＵＥ（例えば、リモートＵＥ）に通知しなくても、他のＵＥは、特別な宛先識別子を認識できる。従って、他のＵＥは、ＵＥ１００−１から、特別な宛先識別子を含むＳＣＩを受信した場合、ＳＣＩが複数の宛先のデータの割当情報を含むことが分かる。従って、他のＵＥは、当該割当情報が自身の宛先向けではない場合であっても、割当情報を破棄せずに済む。

（Ｆ）第３の方法
第３の方法について説明する。第３の方法は、第２の方法と同様に、ＵＥ１００−１は、複数の宛先それぞれのデータからなる複数のデータを含むパケットを生成する。

第３の方法では、ＵＥ１００−１は、ＳＣＩを送信する前に、複数の宛先向けのデータ受信用の宛先識別子（Ｌ１ｄｅｓｔｉｎａｔｉｏｎＩＤ）を、他のＵＥに通知する。ＵＥ１００−１は、当該宛先識別子を通知するためにディスカバリ信号（ディスカバリメッセージ）を用いてもよい。

これにより、他のＵＥは、当該宛先識別子を含むＳＣＩを受信した場合、ＳＣＩが複数の宛先のデータの割当情報を含むことが分かる。従って、他のＵＥは、当該割当情報が自身の宛先向けではない場合であっても、割当情報を破棄せずに済む。

（Ｇ）第４の方法
第４の方法について、図２０を用いて説明する。図２０は、第２実施形態に係る動作（その４）を説明するための拡張ＳＣＩフォーマットの一例の図である。

図２０に示すように、ＵＥ１００−１は、複数の宛先識別子と、パケットを受信するための割当情報とを含む（拡張）ＳＣＩを送信する。拡張ＳＣＩは、例えば、宛先の数を示す「Ｎｕｍｂｅｒｏｆｄｅｓｔｉｎａｔｉｏｎｓ」と、複数の宛先識別子である「ＧｒｏｕｐｄｅｓｔｉｎａｔｉｏｎＩＤ」とを含む。なお、図２０の例では、拡張ＳＣＩフォーマットは、最大１６個（４ビット）の宛先識別子（ｄｅｓｔｉｎａｔｉｏｎＩＤ）を格納可能である。

拡張ＳＣＩを受信した他のＵＥは、拡張ＳＣＩ内の複数の宛先識別子に、自身の宛先識別子がある場合、割当情報に基づいて、データの受信を行う。一方、他のＵＥは、拡張ＳＣＩ内の複数の宛先識別子に自身の宛先識別子がない場合には、割当情報を破棄できる。

なお、上述した第２実施形態に係る第２から第４の方法を、モード１に適用する場合、ｅＮＢ２００が、複数の宛先への割当情報をＵＥ１００へ送信する必要がある。このため、上述した方法と同様の動作が実行される。

（Ｈ）データの受信
データの受信について、図２１及び図２２を用いて説明する。図２１は、第２実施形態に係る動作（その５）を説明するための図である。図２２は、第２実施形態に係る動作（その６）を説明するための図である。

上述の通り、パケットに複数の宛先のデータが含まれることを示す宛先識別子（特別な宛先識別子）又は複数の宛先識別子を含むＳＣＩを受信する他のＵＥ（以下、ＵＥ１００−２）は、当該ＳＣＩに含まれる割当情報に基づいて、パケットを受信する。ここで、ＵＥ１００−２は、パケットに自身のデータが含まれない場合にまで、パケットを受信し続ける可能性がある。そこで、以下の方法により、不要なパケットの受信を低減する。

第１に、ＵＥ１００−２は、パケットに自身のデータが含まれない場合、ＵＥ１００−１から再送されるパケットの受信を省略する。具体的には、ＵＥ１００−２は、受信したＭＡＣＰＤＵに自身の宛先のＭＡＣＳＤＵ（ＳｅｒｖｉｃｅＤａｔａＵｎｉｔ）が含まれない場合には、再送されるＭＡＣＰＤＵの受信を省略する（すなわち、受信しない）。

第２に、ＵＥ１００−２は、１つの無線リソースプールにおいて、最初のパケットに自身のデータが含まれない場合、以後のパケットの受信を省略する。また、ＵＥ１００−２は、割当情報を破棄する。ＵＥ１００−１は、割当情報を破棄することにより、ＨＡＲＱ処理をより速く終了することができる。

具体的には、ＵＥ１００−２は、時間方向に異なって配置される複数のパケットの配置を示す割当情報に基づいて、最初のＭＡＣＰＤＵ（図２１のＳＣプールの次のサブフレーム内のパケット）を受信する。ＵＥ１００−２は、受信した最初のＭＡＣＰＤＵに自身の宛先が格納されていない場合、以後のパケットの受信を省略する（無視）。また、ＵＥ１００−２は、対応する割当情報を破棄する。

なお、ＵＥ１００−１は、１つの無線リソースプールにおいて、最初のパケットに含まれる複数の宛先識別子（ＤｅｓｔｉｎａｔｉｏｎＩＤ１，３，４）に対応するデータのみを送信する。ＵＥ１００−１は、以下に示すように、１つの無線リソースプールにおいて、宛先を変更しない。

第３に、ＵＥ１００−２は、複数のデータの宛先が変更され得るタイミングで送信されるパケット（ＭＡＣＰＤＵ）を受信し、以後のパケットの受信を省略するか否かを判断する。

具体的には、まず、ＵＥ１００−１は、所定期間内（１つの無線リソースプールの期間内）でＭＡＣＰＤＵに含まれる複数の宛先が変更され得るタイミングを示すタイミング情報を送信する。ＵＥ１００−２は、タイミング情報を受信する。ＵＥ１００−１は、タイミング情報を最初のＭＡＣＰＤＵ内の格納するＭＡＣＣＥ（ＣｏｎｔｒｏｌＥｌｅｍｅｎｔ）として格納してもよい。

ＵＥ１００−２は、最初のＭＡＣＰＤＵを受信する。ＵＥ１００−２は、最初のＭＡＣＰＤＵに自身の宛先（識別子）が格納されている場合、複数の宛先が変更され得る次のタイミング（Ｒｅｃｅｐｔｉｏｎｔｉｍｉｎｇ）まで受信し続ける。一方、ＵＥ１００−２は、最初のＭＡＣＰＤＵに自身の宛先が格納されていない場合、タイミング情報に基づいて、次のタイミングまでＭＡＣＰＤＵの受信を省略する（無視）。なお、ＵＥ１００−２は、後述の最後のタイミングまで、割当情報を引き続き保持する。

ＵＥ１００−２は、タイミング情報に基づく次のタイミングでＭＡＣＰＤＵを受信し、受信したＭＡＣＰＤＵに自身の宛先（識別子）が格納されているか判断する。図２２では、ＵＥ１００−２は、受信したＭＡＣＰＤＵに自身の宛先が格納されているため、割当情報に基づいて、ＭＡＣＰＤＵの受信を行う。

ＵＥ１００−２は、タイミング情報に基づいて、複数の宛先が変更され得るタイミングでＭＡＣＰＤＵを受信する。ここでのタイミングは、タイミング情報によって示される最後のタイミングである。ＭＡＣＰＤＵに自身の宛先が格納されていないため、ＵＥ１００−２は、以後のＭＡＣＰＤＵの受信を省略する。また、ＵＥ１００−２は、所定期間（１つの無線リソースプール）が終了するよりも前に、割当情報を破棄する。ＵＥ１００−１は、１つの無線リソースプールが終了するよりも前に割当情報を破棄することにより、ＨＡＲＱ処理をより速く終了することができる。

（Ｉ）ＬＣＩＤの利用
次に、ＬＣＩＤ（ＬｏｇｉｃａｌＣｈａｎｎｅｌＩＤ）を利用する方法を、図２３を用いて説明する。図２３は、第２実施形態に係る動作（その７）を説明するための図である。

図２３に示すように、リレーＵＥは、複数の宛先毎に異なる論理チャネルの識別情報（ＬＣＩＤ）を設定する。具体的には、リレーＵＥは、ＬＣＩＤ１をリモートＵＥ（Ａ）に設定し、ＬＣＩＤ２をリモートＵＥ（Ｂ）に設定している。ＬＣＩＤ３、４は、使用されていない。このように、リレーＵＥは、ＬＣＩＤと宛先（ｄｅｓｔｉｎａｔｉｏｎＩＤ）とを対応付けて記憶する。

リレーＵＥは、ＬＣＩＤに対応する論理チャネルで複数の宛先のそれぞれのデータ（ＭＡＣＳＤＵ）を搬送する。これにより、リレーＵＥは、ＬＣＩＤ１に対応する論理チャネルでリモートＵＥ（Ａ）のデータを搬送する。リモートＵＥ（Ａ）は、ＬＣＩＤ１が設定されているため、ＬＣＩＤ１に対応する論理チャネルで搬送されるデータを自身のデータと認識し、当該データを取得する。

リレーＵＥは、ＬＣＩＤの利用状況をリモートＵＥ（Ｃ）に通知する。例えば、リレーＵＥは、ＬＣＩＤの利用状況を示すビットマップ（図２３参照）をリモートＵＥ（Ｃ）に送信する。リレーＵＥは、ＬＣＩＤの利用状況を示すＬＣＩＤフィールドを有するディスカバリメッセージにより、ビットマップを送信してもよい。ＬＣＩＤフィールドにＬＣＩＤの利用状況を示すビットマップが格納され得る。

リモートＵＥ（Ｃ）は、ＬＣＩＤの利用状況を示すビットマップに基づいて使用されていないＬＣＩＤを選択する。例えば、リモートＵＥ（Ｃ）は、ＬＣＩＤ３を選択すると決定する。

リモートＵＥ（Ｃ）は、選択したＬＣＩＤ３をリレーＵＥに通知する。リレーＵＥは、ＬＣＩＤ３に対応する論理チャネルでリモートＵＥ（Ｃ）のデータの搬送を開始する。

以上のように、リレーＵＥは、ＬＣＩＤに対応する論理チャネルで複数の宛先のそれぞれのデータ（ＭＡＣＳＤＵ）を搬送するため、複数のデータを同時に送信することができる。

［第３実施形態］
次に、第３実施形態について説明する。第３実施形態では、複数の無線リソースプールでの同時送信を許可するケースを中心に説明する。なお、第１及び第２実施形態と同様の部分は、説明を省略する。

（Ｊ）モード１
ｅＮＢ２００が直接通信の無線リソースを指定するモード１で、ＵＥ１００−１が直接通信を実行するケースを説明する。モード１において適用可能な第１及び第２の方法について説明する。第１の方法は、第１実施形態に係る「（Ａ１）第１の方法」に類似するため、異なる部分を中心に説明する。また、第２の方法は、第１実施形態に係る「（Ａ２）第２の方法」に類似するため、異なる部分を中心に説明する。

（Ｊ１）第１の方法
第１の方法について、図２４を用いて説明する。図２４は、第３実施形態に係る動作（その１）を説明するためのシーケンス図である。

ステップＳ５０１において、ｅＮＢ２００は、ＳＬ−ＲＮＴＩと送信リソースプールとのセット（組み合わせ）からなる互いに異なる複数のセット（Ｍｏｄｅ１送信設定）をＵＥ１００−１に設定する（割り当てる）。ＵＥ１００−１は、複数のＭｏｄｅ１送信設定を設定する。これにより、ＵＥ１００−１には、複数のＳＬ−ＲＮＴＩが割り当てられている。

ｅＮＢ２００は、複数のＳＬ−ＲＮＴＩ毎に無線リソースを確保する。ここで、ｅＮＢ２００は、ＳＬ−ＲＮＴＩに対応する無線リソースプール内の無線リソースを確保する。

なお、ｅＮＢ２００は、上述の「（Ａ１）第１の方法」と同様に、複数のＳＬ−ＲＮＴＩのサーチスペースが特定のＳＬ−ＲＮＴＩと関連付くように、ＵＥ１００−１に複数のＳＬ−ＲＮＴＩを割り当ててもよい。また、ｅＮＢ２００は、特定のＳＬ−ＲＮＴＩと関連付けられたサーチスペースに複数のＤＣＩを配置してもよい。

ステップＳ５０２は、ステップＳ１０２に対応する。ｅＮＢ２００は、複数のＭｏｄｅ１送信設定のそれぞれに対応するＤＣＩからなる複数のＤＣＩをＵＥ１００−１に送信する。ＵＥ１００−１は、複数のＳＬ−ＲＮＴＩに基づいて、複数のＤＣＩを受信する。ＵＥ１００−１は、複数のＳＬ−ＲＮＴＩのそれぞれに対応する送信リソースプール内の無線リソースからなる複数の無線リソースが割り当てられる。

ステップＳ５０３は、ステップＳ１０３に対応する。

以上より、ＵＥ１００−１は、複数の無線リソースが割り当てられることが可能であるため、データ送信の遅延が発生することを抑制できる。また、ｅＮＢ２００が無線リソースを割り当てているため、干渉が発生することを低減できる。

（Ｊ２）第２の方法
第２の方法について、図２５及び図２６を用いて説明する。図２５は、第３実施形態に係る動作（その２）を説明するためのシーケンス図である。図２６は、第３実施形態に係る動作（その２）を説明するための図である。

ステップＳ６０１において、ｅＮＢ２００は、単一のＳＬ−ＲＮＴＩと、当該ＳＬ−ＲＮＴＩと対応付けられた複数の無線リソースプールと、複数の無線リソースプールのそれぞれのインデックスとをＵＥ１００−１に設定する（割り当てる）。ｅＮＢ２００は、複数の無線リソースプールとインデックスとの対応関係をブロードキャストによりＵＥ１００−１に通知してもよい。ＵＥ１００−１は、ＳＬ−ＲＮＴＩと複数の無線リソースプールとを対応付けて設定する。

ステップＳ６０２において、ｅＮＢ２００は、複数のＤＣＩを送信し、ＵＥ１００−１は、複数のＤＣＩを受信する。これにより、ＵＥ１００−１は、ＤＣＩ１に含まれる無線リソースの割当情報１とＤＣＩ２に含まれる無線リソースの割当情報２とを取得する。

ＵＥ１００−１は、割当情報１に基づいて、ＤＣＩ１に含まれるインデックス１が示す無線リソースプール（Ｐｏｏｌ１）内の無線リソースが割り当てられる。ＵＥ１００−２は、割当情報２に基づいて、ＤＣＩ２に含まれるインデックス２が示す無線リソースプール（Ｐｏｏｌ２）内の無線リソースが割り当てられる。

ステップＳ６０３は、ステップＳ１０３に対応する。

なお、図２６に示すように、インデックスを示す情報は、無線リソースの割当情報が配置される時間位置であってもよい。すなわち、ＳＬグラント（ＤＣＩ）の通知タイミングによって無線リソースプールが指定されてもよい。

例えば、ＵＥ１００−１は、以下の式によって所定のタイミングで通知されたＳＬグラントが、どの無線リソースプールに対応するＳＬグラントであるかを判断してもよい。

（ＳＦＮ（ＳｙｓｔｅｍＦｒａｍｅＮｕｍｂｅｒ） × １０＋ｓｕｂｆｒａｍｅ）ｍｏｄ利用可能プール数＝インデックス

これにより、ＤＣＩがインデックスを含まなくてよいため、ＤＣＩを送信するために必要な無線リソース量を低減できる。

（Ｋ）モード２
次に、直接通信の無線リソースをＵＥ１００が選択するモード２で、ＵＥ１００−１が直接通信を実行するケースを説明する。この動作は、第１実施形態に係る「（Ｂ）モード２」と類似するため、異なる点を中心に説明する。

図１４のステップＳ４０２において、ｅＮＢ２００は、許可情報ではなく、複数の無線リソースプールが同時に使用可能であるか否かの情報を１００−１に送信する。例えば、当該情報は、複数の無線リソースプールのうちの同時に使用可能である無線リソースプールの組み合わせを示すリストである。或いは、当該情報は、前記複数の無線リソースプールのうち、同時に使用可能である無線リソースプールのみを示すリストである。このリストに記載の無線リソースプールは、同時使用が許可された無線リソースプールである。これらのリストには、無線リソースプールと対応付けられたインデックスが記載されていてもよい。

以上のように、ＵＥ１００−１は、複数の無線リソースプールのそれぞれから選択された無線リソースを用いて、複数のＳＣＩを送信できる。このため、データ送信の遅延が発生することを抑制できる。また、ＵＥ１００−１は、ｅＮＢ２００の許可を得た上で、無線リソースを選択するため、干渉が発生することを低減できる。

［第４実施形態］
次に、第４実施形態について、説明する。上述の各実施形態の少なくともいずれかと同様の内容は説明を省略する。

第４実施形態は、ＵＥ１００−１がｅＮＢ２００とＵＥ１００−２との間のデータの送受信を中継する場合（言い換えれば、リレーＵＥとして動作する場合）に、ｅＮＢ２００（又はｅＮＢ２００が管理するセル、以下同様）が、ＵＥ１００−１に対して、ＵＥ１００−２との直接通信に用いる無線リソースの情報を通知することに関する。

第４実施形態に係る環境の例を、図２７を用いて説明する。

第４実施形態において、例えば、ｅＮＢ２００、ＵＥ１００−１及びＵＥ１００−２は、図２７（Ａ）に示される第１の環境又は図２７（Ｂ）に示される第２の環境にある。

まず、第１の環境におけるＵＥ１００−１及びＵＥ１００−２を以下に説明する。

ＵＥ１００−１は、ｅＮＢ２００が管理するセル（サービングセル）に在圏する。ＵＥ１００−１は、ｅＮＢ２００と接続（ＲＲＣ接続）を確立している状態（ＲＲＣ接続状態）である。また、ＵＥ１００−１は、ＵＥ１００−２との直接通信（Ｄ２Ｄ通信）によって、ｅＮＢ２００とＵＥ１００−２との間のデータの送受信を中継する能力を有する。つまり、ＵＥ１００−１は、リレーＵＥとして機能する能力を有する。

ＵＥ１００−２は、ｅＮＢ２００が管理するセルに在圏しない。ＵＥ１００−２は、ｅＮＢ２００と接続（ＲＲＣ接続）を確立していない状態である。また、ＵＥ１００−２は、前述した通り、ＵＥ１００−１を介して、ｅＮＢ２００と間接的にデータの送受信を行う機能を有する。つまり、ＵＥ１００−２は、リモートＵＥとして機能する能力を有する。

次に、第２の環境におけるＵＥ１００−１及びＵＥ１００−２を以下に説明する。

ＵＥ１００−１は、第１の環境と同様に、ｅＮＢ２００が管理するセルに在圏する。ＵＥ１００−１は、ｅＮＢ２００と接続を確立している状態である。

ＵＥ１００−２は、第１の環境とは異なり、ｅＮＢ２００が管理するセル（サービングセル）に在圏する。ＵＥ１００−２は、ｅＮＢ２００と接続（又はＲＲＣ接続）を確立している状態（ＲＲＣ接続状態）である。

第１実施形態において、ｅＮＢ２００がリレーＵＥを決定し、リレー制御を実行する場合のｅＮＢ２００、ＵＥ１００−１及びＵＥ１００−２の動作について、図２８を用いて以下に説明する。

（モードの選択）
ステップＳ７０１において、ｅＮＢ２００は、ＵＥ１００−２との間でデータの送受信を中継するＵＥ（リレーＵＥ）を、ＵＥ１００−１に決定する。ｅＮＢ２００によるリレーＵＥの決定方法については、例えば、後述する第６実施形態を用いてもよい。

ステップＳ７０２において、ｅＮＢ２００は、ＵＥ１００−１に対する直接通信のリソース割り当てタイプとして、モード１かモード２のいずれかを選択する。

ｅＮＢ２００は、以下の少なくともいずれかの条件を満たす場合に、モード２を選択してもよい。ｅＮＢ２００は、以下の全ての条件を満たさない場合に、モード１を選択してもよい。

・ｅＮＢ２００の処理負荷が所定値以上である。

・物理下りリンク制御チャネル（ＰＤＣＣＨ）の無線リソースの容量（使用可能な無線リソースの量）が所定値以下である。

・ＰＤＣＣＨの送信による遅延（４サブフレーム以上の遅延）を許容できない。

・ＵＥ１００−１の消費電力の削減が必要である。

・ＵＥ１００−１によるＰＤＣＣＨの監視の停止が望まれる。

ステップＳ７０３において、ｅＮＢ２００は、ステップＳ７０２で選択したモード（モード１又はモード２）に関する設定情報を含むＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージをＵＥ１００−１へ送信する。具体的には、例えば、ｅＮＢ２００は、ステップＳ７０２でモード１を選択した場合には、ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ内のＳＬ−ＣｏｍｍＣｏｎｆｉｇのｓｃｈｅｄｕｌｅｄにビットを含めて送信する。一方で、例えば、ｅＮＢ２００は、ステップＳ７０２でモード２を選択した場合には、ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ内のＳＬ−ＣｏｍｍＣｏｎｆｉｇのｕｅ−Ｓｅｌｅｃｔｅｄにビットを含めて送信する。

ＵＥ１００−１は、ステップＳ７０３でｅＮＢ２００から送信されたＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージに含まれる設定情報を適用する。これによって、ＵＥ１００−１は、自端末に割り当てられる直接通信の無線リソースのタイプがモード１及びモード２のうちのいずれであるかを把握する。

なお、ｅＮＢ２００は、ステップＳ７０２でモード１を選択した場合、ステップＳ７０３におけるＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージの送信後に、ＰＤＣＣＨを介して、無線リソースを特定するための情報（ＤＣＩｆｏｒｍａｔ５等）を送信する。一方で、ｅＮＢ２００は、ステップＳ７０２でモード２を選択した場合、ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ内に割り当てる無線リソースを特定するための情報を含める。このため、ｅＮＢ２００は、追って、ＰＤＣＣＨを介して、無線リソースを特定するための情報を送信する必要が無くなる。

ステップＳ７０４において、ＵＥ１００−１がｅＮＢ２００により割り当てられた直接通信の無線リソースを使用して、リモートＵＥであるＵＥ１００−２とｅＮＢ２００の間のデータを中継するリレー制御を行う。

従って、ｅＮＢ２００は、ＵＥ１００−１に対する無線リソースを特定するための情報を別途送信することが望ましくないか否かに応じた最適なモードを選択し、ＵＥ１００−１を介したリレー制御を実現することができる。

（リソースの割当）
次に、ステップＳ７０２でｅＮＢ２００が選択したモードとＵＥ１００−２の環境（つまり、ＵＥ１００−２がｅＮＢ２００の管理するセルに在圏しているか否か）に応じた、ｅＮＢ２００によるＵＥ１００−１への直接通信の無線リソースの割り当ての例について、図２９〜３２を用いて説明する。

（前提条件）
ＵＥ１００−２は、第１の環境（ｅＮＢ２００が管理するセルに在圏しない場合）において、リレー制御によってＵＥ１００−１と直接通信を行う場合に、ＵＥ１００−２が使用可能な直接通信の無線リソース（リソースプール）のうちの一部又は全ての無線リソースを使用する。ＵＥ１００−２は、ＵＥ１００−２が使用可能な直接通信の無線リソースを、ＵＥ１００−２（例えば、ＵＥ１００−２のＳＩＭ（ＳｕｂｓｃｒｉｂｅｒＩｄｅｎｔｉｔｙＭｏｄｕｌｅＣａｒｄ）等）に予め記憶されている直接通信の無線リソースに関する情報（Ｐｒｅｃｏｎｆｉｇｕｒｅｄｐａｒａｍｅｔｅｒｓにおけるｍｏｄｅ２ＤａｔａＯｆｆｓｅｔＩｎｄｉａｔｏｒ及びｍｏｄｅ２ＤａｔａＳｕｂｆｒａｍｅＢｉｔｍａｐ等）に基づいて特定する。なお、ｍｏｄｅ２ＤａｔａＯｆｆｓｅｔＩｎｄｉａｔｏｒは、時間方向のオフセット値であり、ｓａＰｅｒｉｏｄ（サイドリンクによる無線リソースの割り当てが行われる期間）の開始位置からモード２の無線リソースを使用して送信されるデータの開始位置を示す。ｍｏｄｅ２ＤａｔａＳｕｂｆｒａｍｅＢｉｔｍａｐは、ＵＥ１００−２が使用可能な無線リソースのサブフレームを示す。

ｅＮＢ２００は、ＵＥ１００−２に予め記憶されている無線リソースに関する情報と同じ情報を、予め記憶しているか、過去にＵＥ１００−２の認証の際にＵＥ１００−２から受信したか又はＵＥ１００−２を管理するサーバに要求し取得することによって、ＵＥ１００−２が使用可能な直接通信の無線リソースを把握している。

（第１の環境においてモード１を選択した場合）
ｅＮＢ２００は、ＵＥ１００−１に割り当てる直接通信の無線リソースの時間的な位置（サブフレーム）が、ＵＥ１００−２に使用可能な直接通信の無線リソースの時間的な位置（サブフレーム）と重ならない（言い換えれば、ＵＥ１００−１に割り当てる直接通信に用いる無線リソースとＵＥ１００−２に使用可能な直接通信の無線リソースとが時間的に直交する）ように、ＵＥ１００−１に割り当てる直接通信の無線リソースのサブフレームのパターン（ｔｉｍｅｒｅｓｏｕｒｃｅｐａｔｔｅｒｎ）を選択する。具体的には、例えば、ｅＮＢ２００は、ＵＥ１００−２が使用可能な直接通信の無線リソースのサブフレームが「ｍｏｄｅ２ＤａｔａＯｆｆｓｅｔＩｎｄｉｃａｔｏｒ＝０」及び「ｍｏｄｅ２ＤａｔａＳｕｂｆｒａｍｅＢｉｔｍａｐ＝｛１，０，１，０，１，０ …｝」によって表される場合、ＵＥ１００−１のｔｉｍｅｒｅｓｏｕｒｃｅｐａｔｔｅｒｎとして、同じサブフレームにおけるビットが重複しないパターン（例えば、｛０，１，０，１，０，１ …｝、｛０，１，０，１，０，０ …｝又は｛０，０，０，１，０，１ …｝等）を選択する。

また、ｅＮＢ２００は、ＵＥ１００−２のｍｏｄｅ２ＤａｔａＯｆｆｓｅｔＩｎｄｉｃａｔｏｒ＝１の場合、モード２の無線リソースを使用して送受信されるデータの開始位置がモード１の無線リソースを使用して送受信されるデータの開始位置と異なる。このため、ｅＮＢ２００は、ｍｏｄｅ２ＤａｔａＳｕｂｆｒａｍｅＢｉｔｍａｐ＝｛１，０，１，０，１，０ … ０｝の最後尾の１ビット（０）を一番前に移動したパターン｛０，１，０，１，０，１，０ …｝と重複しないように、ｔｉｍｅｒｅｓｏｕｒｃｅｐａｔｔｅｒｎを選択する。例えば、ｅＮＢ２００は、ｔｉｍｅｒｅｓｏｕｒｃｅｐａｔｔｅｒｎ＝｛１，０，１，０，１，０ …｝を選択する。

図２９は、ｅＮＢ２００が、ＵＥ１００−２が使用可能な直接通信の無線リソースと重ならないように、ＵＥ１００−１に対して割り当てた直接通信の無線リソースの例を示す。

図２９では、横軸が時間軸となっており、ＵＥ１００−１及びＵＥ１００−２の互いのＰＳＳＣＨにおける無線リソースが時間方向において重複しない。

ｅＮＢ２００は、ステップＳ７０３の後に、先に選択したＵＥ１００−１に割り当てる直接通信の無線リソースのサブフレームのパターン（ｔｉｍｅｒｅｓｏｕｒｃｅｐａｔｔｅｒｎ）を含む情報（ＤＣＩｆｏｒｍａｔ５）を、ＰＤＣＣＨによってＵＥ１００−１へ送信する。

ＵＥ１００−１は、ＤＣＩｆｏｒｍａｔ５を受信すると、自身に割り当てられた直接通信の無線リソースのサブフレームのパターンに対応する無線リソースを使用して、ステップＳ７０４において、リレー制御を行う。

（第２の環境においてモード１を選択した場合）
（第１の動作例）
ｅＮＢ２００は、ＵＥ１００−１及びＵＥ１００−２に割り当てる直接通信に用いる無線リソースの時間的な位置（サブフレーム）が、互いに重ならない（言い換えれば、ＵＥ１００−１に割り当てる無線リソースとＵＥ１００−２に割り当てる無線リソースとが互いに時間的に直交する）ように、ＵＥ１００−１及びＵＥ１００−２に割り当てる無線リソースのサブフレームのパターン（ｔｉｍｅｒｅｓｏｕｒｃｅｐａｔｔｅｒｎ）を選択する。具体的には、例えば、ｅＮＢ２００は、ＵＥ１００−１のｔｉｍｅｒｅｓｏｕｒｃｅｐａｔｔｅｒｎに｛０，１，０，１，０，１｝を選択した場合、ＵＥ１００−２のｔｉｍｅｒｅｓｏｕｒｃｅｐａｔｔｅｒｎに｛１，０，１，０，１，０｝に選択する。つまり、ｅＮＢ２００は、ＵＥ１００−１のｔｉｍｅｒｅｓｏｕｒｃｅｐａｔｔｅｒｎ及びＵＥ１００−２のｔｉｍｅｒｅｓｏｕｒｃｅｐａｔｔｅｒｎの互いの同じサブフレームのビットが重ならないように互いのｔｉｍｅｒｅｓｏｕｒｃｅｐａｔｔｅｒｎを選択する。

図３０は、ｅＮＢ２００が、ＵＥ１００−１及びＵＥ１００−２に対して割り当てた直接通信の無線リソースの例を示す。

図３０では、横軸が時間軸である。ＵＥ１００−１及びＵＥ１００−２の互いのＰＳＳＣＨにおける無線リソースが時間方向において重複しない。

ｅＮＢ２００は、ステップＳ７０３の後に、先に選択したＵＥ１００−１及びＵＥ１００−２に割り当てる直接通信の無線リソースのサブフレームのパターン（ｔｉｍｅｒｅｓｏｕｒｃｅｐａｔｔｅｒｎ）を含む情報（ＤＣＩｆｏｒｍａｔ５）を、それぞれＰＤＣＣＨによってＵＥ１００−１及びＵＥ１００−２へ送信する。

（第２の動作例）
ｅＮＢ２００は、ＵＥ１００−１及びＵＥ１００−２に対してそれぞれ所定のタイミングでＤＣＩｆｏｒｍａｔ５を送信する。具体的には、ｅＮＢ２００は、図２８に示すステップＳ７０３の後に、ＵＥ１００−１に対して、ｓａＰｅｒｉｏｄの開始位置より所定のサブフレーム（例えば、４サブフレーム）前のサブフレームよりも前のサブフレーム（例えば、５サブフレーム前のサブフレームにおいてＤＣＩｆｏｒｍａｔ５を送信する。一方で、ｅＮＢ２００は、ＵＥ１００−２に対して、ｓａＰｅｒｉｏｄの開始位置より所定のサブフレーム（例えば、４サブフレーム）前のサブフレーム以降のサブフレーム（例えば、３サブフレーム前のサブフレーム）においてＤＣＩｆｏｒｍａｔ５を送信する。これによって、図３１に示すように、ＵＥ１００−１に対して割り当てられる無線リソースがｓａＰｅｒｉｏｄ内に含められる。一方で、ＵＥ１００−１に対して割り当てられる無線リソースが収められるｓａＰｅｒｉｏｄ後の次のｓａＰｅｒｉｏｄに、ＵＥ１００−２に対して割り当てられる無線リソースが収められることになる。

従って、ＵＥ１００−１に対して割り当てられる無線リソースの時間的な位置（サブフレーム）とＵＥ１００−２に対して割り当てられる無線リソースの時間的な位置（サブフレーム）とが互いに重ならないようにすることができる。これによって、ＵＥ１００−１とＵＥ１００−２とは、リレー制御の際に、互いの送受信のタイミングが重なることを回避することができる。

（第１の環境においてモード２を選択した場合）
ｅＮＢ２００は、ＵＥ１００−１が直接通信に用いるためのＵＥ１００−１が選択可能な無線リソースの時間的な位置（サブフレーム）を、ＵＥ１００−２に予め設定されている直接通信に用いる無線リソースの時間的な位置（サブフレーム）と重ならない（言い換えれば、ＵＥ１００−１が直接通信に用いるためのＵＥ１００−１が選択可能な無線リソースとＵＥ１００−２に予め設定されている直接通信に用いる無線リソースとが時間的に直交する）ように、ＵＥ１００−１が選択可能な無線リソースのサブフレームを設定する。具体的には、例えば、ｅＮＢ２００は、ＵＥ１００−２に予め設定されている直接通信に用いる無線リソースのサブフレームが「ｍｏｄｅ２ＤａｔａＯｆｆｓｅｔＩｎｄｉｃａｔｏｒ＝０」及び「ｍｏｄｅ２ＤａｔａＳｕｂｆｒａｍｅＢｉｔｍａｐ＝｛１，０，１，０，１，０｝」によって表される場合、ＵＥ１００−１が選択可能な無線リソースのサブフレームを、当該サブフレームのビットが互いに重ならないように設定する。例えば、ｅＮＢ２００は、「ｍｏｄｅ２ＤａｔａＯｆｆｓｅｔＩｎｄｉｃａｔｏｒ＝０」及び「ｍｏｄｅ２ＤａｔａＳｕｂｆｒａｍｅＢｉｔｍａｐ＝｛０，１，０，１，０，１｝又は｛０，０，０，１，０，１｝」を設定する。これによって、互いの無線リソースの時間的な位置（サブフレーム）が重ならないようにする。

ｅＮＢ２００は、ステップＳ７０３におけるＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージに、上記のように設定したＵＥ１００−１が選択可能な無線リソースのサブフレーム（ｍｏｄｅ２ＤａｔａＯｆｆｓｅｔＩｎｄｉｃａｔｏｒ及びｍｏｄｅ２ＤａｔａＳｕｂｆｒａｍｅＢｉｔｍａｐ）を含めて送信する。これによって、図３２に示すように、ＵＥ１００−１の直接通信に用いることが可能なリソースの位置とＵＥ１００−２の直接通信に用いることが可能なリソースの位置とが互いに重ならない。従って、リレー制御の際に、ＵＥ１００−１及びＵＥ１００−２による直接通信の衝突を防止することができる。

さらに、ｅＮＢ２００は、既に他のリレーＵＥを設定している場合、当該他のリレーＵＥの無線リソース（リソースプール）と重ならない（時間的に直交する）ように、ＵＥ１００−１が選択可能な無線リソースのサブフレームを設定することができる。

具体的には、例えば、ｅＮＢ２００は、他のリレーＵＥの無線リソースのサブフレーム１００−１に予め設定されている直接通信に用いる無線リソースのサブフレームが「ｍｏｄｅ２ＤａｔａＯｆｆｓｅｔＩｎｄｉｃａｔｏｒ＝０」及び「ｍｏｄｅ２ＤａｔａＳｕｂｆｒａｍｅＢｉｔｍａｐ＝｛０，１，０，０，０，０｝」によって表される場合、ＵＥ１００−１が選択可能な無線リソースのサブフレームを、当該サブフレームのビットが互いに重ならないように設定する。例えば、ｅＮＢ２００は、ｍｏｄｅ２ＤａｔａＯｆｆｓｅｔＩｎｄｉｃａｔｏｒ＝０及びｍｏｄｅ２ＤａｔａＳｕｂｆｒａｍｅＢｉｔｍａｐ＝｛０，０，０，１，０，１｝を設定する。

これによって、ＵＥ１００−１は、ＵＥ１００−２に加えて他のリレーＵＥとの直接通信のタイミングが重なることを回避することができる。なお、上記第４実施形態はＳｉｄｅｌｉｎｋＣｏｎｔｒｏｌ（ＰＤＳＣＨ）における無線リソースの割り当てにおいても同様に適用できる。

［第５実施形態］
次に、第５実施形態について、説明する。上述の各実施形態の少なくともいずれかと同様の内容は説明を省略する。

第５実施形態は、ｅＮＢ２００が、ＵＥ１００−１に対して、ＵＥ１００−１とＵＥ１００−２との直接通信又はディスカバリ信号の送信のために割り当てる、ＵＥ１００−１が使用する無線リソースを選択可能な無線リソース（リソースプール）の優先度の設定に関する。

第５実施形態に係る環境の例は、第４実施形態に係る環境の例（図２７に示す環境の例）と同様である。また、第５実施形態は、第４実施形態に一部動作を追加した実施形態であってもよいし、第４実施形態とは独立した実施形態であってもよい。

（リソースプールの優先度の設定）
第５実施形態において、ｅＮＢ２００は、ＵＥ１００−１に対して割り当てる複数のリソースプールにおける各リソースプールに優先度を設定する。優先度は、各リソースプールのサブフレームが互いに重なった場合に、各リソースプールを割り当てられたＵＥがどのリソースプールを優先して使用すべきかを特定するためのものである。複数のリソースプールは、ディスカバリ信号の送信のためのリソースプール及びＵＥ１００−２との直接通信のためのリソースプールを含む。

なお、ｅＮＢ２００は、第４実施形態に係るシーケンスのステップＳ７０２（ＵＥ１００−１に対して割り当てるリソースのタイプ選択）の際に、併せて、当該無線リソース（リソースプール）の優先度を決定してもよい。

ｅＮＢ２００は、各リソースプールに優先度を設定した場合、第４実施形態のステップＳ７０３においてＵＥ１００−１に対して送信するＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージに割り当てるリソースプールの優先度に関する情報を含めてもよい。なお、一のＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージによって、複数のリソースプール（例えば、ディスカバリ信号の送信のためのリソースプールと直接通信のためのリソースプール）の設定情報を含めてもよい。その場合、複数のリソースプールの設定情報には、それぞれ各リソースプールの優先度に関する情報を含んでもよい。

ＵＥ１００−１は、第４実施形態に係るシーケンスのステップＳ７０３において、ｅＮＢ２００から送信されたＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを受信すると、当該メッセージに含まれる各リソースプールの優先度に基づいて、各リソースプールを用いてディスカバリ信号の送信又は直接通信を実行する。

具体的には、例えば、ＵＥ１００−１は、受信したＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージに、ディスカバリ信号の送信のためのリソースプールの優先度が１に設定され、なお且つ直接通信のためのリソースプールの優先度が２に設定されている場合、互いのリソースプールの時間方向に重なる位置（サブフレーム）については、優先度の高いリソースプールを使用する。つまり、ＵＥ１００−１は、互いのリソースプールの時間方向に重なる位置では、ディスカバリ信号の送信のためのリソースプールを用いて、ディスカバリ信号の送信を行う。

ｅＮＢ２００は、所定の情報に基づいて、各リソースプールの優先度を決定してもよい。

所定の情報とは、例えば、各リソースプールを使用して実現するサービスの種類（通報サービス等）及び受信成功率、リソースプールを使用するグループ及びユーザ並びにリソースプールを使用して送信するデータ量の少なくともいずれか１つであってもよい。

なお、ｅＮＢ２００は、ＵＥ１００−１から送信されるＳｉｄｅｌｉｎｋＵＥＩｎｆｏｒｍａｔｉｏｎによって、所定の情報を把握してもよい。

ｅＮＢ２００は、各無線リソースの優先度を設定することによって、ＵＥ１００−１に対して、互いのリソースプールの時間的に重なった位置において、使用するリソースプールを間接的に指定することができ、柔軟なリソースプールの使用を制御することができる。

（繰り返し回数の設定）
ｅＮＢ２００は、第４実施形態のシーケンスに係るステップＳ７０２においてモード１を選択した場合、ＵＥ１００−１に割り当てる無線リソースのサブフレームのパターン（ｔｉｍｅｒｅｓｏｕｒｃｅｐａｔｔｅｒｎ）が時間方向に繰り返される回数（ｎｕｍＲｅｐｅｔｉｔｉｏｎ）を設定してもよい。

具体的には、ｅＮＢ２００は、第４実施形態のシーケンスに係るステップＳ７０３においてＵＥ１００−１へ送信するＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージの中に、無線リソースのサブフレームのパターン（ｔｉｍｅｒｅｓｏｕｒｃｅｐａｔｔｅｒｎ）が繰り返される回数（ｎｕｍＲｅｐｅｔｉｔｉｏｎ）を含めてもよい。例えば、ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージの中に含まれるｎｕｍＲｅｐｅｔｉｔｉｏｎが３である場合には、ＵＥ１００−１は、割り当てられる無線リソースのサブフレームのパターン（ｔｉｍｅｒｅｓｏｕｒｃｅｐａｔｔｅｒｎ）の繰り返される回数が３回であると認識する。つまり、ＵＥ１００−１は、ｓａＰｅｒｉｏｄの開始からｔｉｍｅｒｅｓｏｕｒｃｅｐａｔｔｅｒｎに従って、無線リソースのサブフレームを３回繰り返した後のサブフレームを用いて直接通信をしない（又は直接通信を制限する）。

また、ｅＮＢ２００は、繰り返し回数（ｎｕｍＲｅｐｅｔｉｔｉｏｎ）をＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージに含める代わりに、ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージの後にＰＤＣＣＨを介して送信するＤＣＩＦｏｒｍａｔ５によって送信タイミングを指定して送信するＳＣＩｆｏｒｍａｔ０に含めてもよい。

なお、第４実施形態に係るシーケンスのステップＳ７０２において、ｅＮＢ２００が、ＵＥ１００−１に対して割り当てるリソースのタイプとしてモード２を選択した場合にも適用してもよい。

具体的には、ＵＥ１００−１は、ｅＮＢ２００から受信したＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージに含まれるｓａＰｅｒｉｏｄの開始地点にｍｏｄｅ２ＤａｔａＯｆｆｓｅｔＩｎｄｉｃａｔｏｒを加えた地点からｍｏｄｅ２ＤａｔａＳｕｂｆｒａｍｅＢｉｔｍａｐに従って割り当てられた無線リソースが開始し、繰り返し回数を満了した地点で割り当てられたリソースが終了すると認識する。つまり、ＵＥ１００−１は、繰り返し回数を満了した地点以降を自己に割り当てられた無線リソースであるとは認識せず、当該無線リソースを使用して直接通信を行わない（直接通信を禁止する）。

従って、ｅＮＢ２００は、ＵＥ１００−１に対して割り当てる無線リソースに繰り返し回数を設定することによって、ＵＥ１００−１に対する柔軟な無線リソースの割り当てを実現することができる。

（繰り返しパターンの設定）
ｅＮＢ２００は、第４実施形態のシーケンスに係るステップＳ７０２においてモード１を選択した場合、ＵＥ１００−１に割り当てる無線リソースのサブフレームのパターン（ｔｉｍｅｒｅｓｏｕｒｃｅｐａｔｔｅｒｎ）が時間方向に繰り返されるパターン（ｔｉｍｅｒｅｐｅｔｉｔｉｏｎｐａｔｔｅｒｎ）を設定してもよい。

具体的には、ｅＮＢ２００は、第４実施形態におけるステップＳ７０３において送信するＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージの後にＰＤＣＣＨを介して送信するＤＣＩｆｏｒｍａｔ５又はＤＣＩｆｏｒｍａｔ５によって送信タイミングを指定して送信するＳＣＩｆｏｒｍａｔ０に、無線リソースのサブフレームのパターンが時間方向に繰り返されるパターンに関する情報（ｔｉｍｅｒｅｐｅｔｉｔｉｏｎｐａｔｔｅｒｎ）を含めてもよい。例えば、ｅＮＢ２００から「ｔｉｍｅｒｅｐｅｔｉｔｉｏｎｐａｔｔｅｒｎ＝｛０，１，１，０｝」を受信した場合には、ＵＥ１００−１は、ｓａＰｅｒｉｏｄの開始地点から１回目及び４回目の無線リソースのサブフレームのパターンに対応する無線リソースが自己に割り当てられたものとは認識しない。一方で、ＵＥ１００−１は、２回目及び３回目の無線リソースのサブフレームのパターンに対応する無線リソースが自己に割り当てられたものと認識する。つまり、ＵＥ１００−１は、無線リソースのサブフレームのパターン（ｔｉｍｅｒｅｓｏｕｒｃｅｐａｔｔｅｒｎ）のうちのｔｉｍｅｒｅｐｅｔｉｔｉｏｎｐａｔｔｅｒｎのビットを有する繰り返し位置を自己に割り当てられた無線リソースであると認識する。一方で、ＵＥ１００−１は、無線リソースのサブフレームのパターン（ｔｉｍｅｒｅｓｏｕｒｃｅｐａｔｔｅｒｎ）のうちのｔｉｍｅｒｅｐｅｔｉｔｉｏｎｐａｔｔｅｒｎのビットを有しない繰り返し位置を自己に割り当てられた無線リソースでは無いと認識するＵＥ１００−１は、当該無線リソースを使用して直接通信を行わない（直接通信を禁止する）。

従って、ｅＮＢ２００は、ＵＥ１００−１に対して割り当てる無線リソースに繰り返しパターンを設定することによって、ＵＥ１００−１に対する柔軟な無線リソースの割り当てを実現することができる。

［第６実施形態］
第６実施形態は、ｅＮＢ２００が、リレーＵＥとして動作させるＵＥを決定する動作に関する。

第６実施形態に係る環境の例を、図３３を用いて説明する。

第６実施形態において、例えば、ＵＥ１００−１、ＵＥ１００−２及びＵＥ１００−３は、図３３（Ａ）に示される第１の環境又は図３３（Ｂ）に示される第２の環境にある。

第１の環境におけるＵＥ１００−１〜ＵＥ１００−３を以下に説明する。

ＵＥ１００−１及びＵＥ１００−２は、第１実施形態における第１の環境と同様の環境にある。つまり、ＵＥ１００−１は、ｅＮＢ２００が管理するセルに在圏している。ＵＥ１００−２は、ｅＮＢ２００が管理するセルに在圏していない。

ＵＥ１００−３は、ＵＥ１００−１と同様に、ｅＮＢ２００が管理するセルに在圏している。ＵＥ１００−３は、リレーＵＥとして機能する能力を有する。

次に、第２の環境におけるＵＥ１００−１〜ＵＥ１００−３を以下に説明する。

ＵＥ１００−１及びＵＥ１００−３は、第１の環境と同じ環境である。

第６実施形態におけるｅＮＢ２００がリレーＵＥとして動作させるＵＥを決定する際のｅＮＢ２００及びＵＥ１００−１〜ＵＥ１００−３の動作の複数の例について、図３４〜３９を用いて以下に説明する。

複数の動作の例のうちの図３４に示す動作の例において、ＵＥ１００−１〜ＵＥ１００−３は、第２の環境（ＵＥ１００−２が、ｅＮＢ２００が管理するセルに在圏する）にある。

ステップＳ７１１において、ｅＮＢ２００は、ＵＥ１００−２に対して、ｅＮＢ２００からの信号の測定値と対比するための閾値（Ｔｈｒｅｓｈｏｌｄ）を通知する。一例として、閾値は、例えば、受信レベル（ＲＳＲＰ：ＲｅｆｅｒｅｎｃｅＳｉｇｎａｌＲｅｃｅｉｖｅｄＰｏｗｅｒ及び／又はＲＳＲＱ：ＲｅｆｅｒｅｎｃｅＳｉｇｎａｌＲｅｃｅｉｖｅｄＱｕａｌｉｔｙ）の閾値であってもよい。ＵＥ１００−２は、ｅＮＢ２００がリモートＵＥの候補となるべきＵＥとして選択したＵＥであってもよい。

ステップＳ７１２において、ＵＥ１００−２は、ｅＮＢ２００からの信号の測定値とステップＳ７１１でｅＮＢ２００から受信した閾値と対比する。ＵＥ１００−２は、測定値が閾値を下回るか否かを判定する。

ＵＥ１００−２は、測定値が閾値を下回る場合（Ｓ７１２ＹＥＳ）には、ステップＳ７１３において、ｅＮＢ２００にリレー制御を要求する。

一方で、ＵＥ１００−２は、測定値が閾値を下回らない場合（Ｓ７１２ＮＯ）には、再度、ｅＮＢ２００からの信号の測定を継続する。

ステップＳ７１４において、ｅＮＢ２００は、ＵＥ１００−２からのリレー制御の要求に応じて、サイドリンク同期信号（ＳｉｄｅＬｉｎｋＳｙｎｃｈｒｏｎｉｚａｔｉｏｎＳｉｇｎａｌ：ＳＬＳＳ）及び／又はディスカバリ信号（ＤｉｓｃｏｖｅｒｙＳｉｇｎａｌ）の送信をＵＥ１００−１及びＵＥ１００−３へ要求する。

ステップＳ７１５において、ＵＥ１００−１及びＵＥ１００−３は、ｅＮＢ２００からの要求に応じて、サイドリンク同期信号及び／又はディスカバリ信号を報知する。

ステップＳ７１６において、ＵＥ１００−２は、ＵＥ１００−１及びＵＥ１００−３から報知されたサイドリンク同期信号及び／又はディスカバリ信号の測定を行う。測定とは、例えば、受信レベル（ＲＳＲＰ及び／又はＲＳＲＱ）の測定である。

ステップＳ７１７において、ＵＥ１００−２は、ｅＮＢ２００に対して、ステップＳ１６で測定した測定結果の報告（測定報告）を行う。

ステップＳ７１８において、ｅＮＢ２００は、ＵＥ１００−２から受信した測定報告に基づいて、リレーＵＥをＵＥ１００−１に決定する。ｅＮＢ２００は、例えば、ＵＥ１００−２から受信した測定報告に含まれるＵＥ１００−１からの信号の測定値とＵＥ１００−３からの信号の測定値とを対比する。ｅＮＢ２００は、ＵＥ１００−１からの信号の測定値の方が高いことからＵＥ１００−１をリレーＵＥに決定してもよい。また、ｅＮＢ２００は、ｅＮＢ２００から送信された信号のＵＥ１００−１及びＵＥ１００−３の測定結果に基づいて、リレーＵＥとなるＵＥを決定してもよい。また、ｅＮＢ２００は、リモートＵＥの候補として選択したＵＥのうち、それぞれＵＥ１００−１及びＵＥ１００−３の近傍にいるＵＥの数に基づいて、リレーＵＥとなるＵＥを決定してもよい。また、ｅＮＢ２００は、ＵＥ１００−１及びＵＥ１００−３によって送信されたディスカバリ信号の受信結果に基づいて特定したＵＥ１００−１及びＵＥ１００−３の送信可能範囲（Ｒａｎｇｅ）に基づいて、リレーＵＥとなるＵＥを決定してもよい。また、ｅＮＢ２００は、リモートＵＥのトラフィック量に応じて、リレーＵＥとなるＵＥを決定してもよい。

ステップＳ７１９において、ｅＮＢ２００は、リレーＵＥに決定したＵＥ１００−１に対して、ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを送信する。ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージは、リレーＵＥとして動作するための設定情報を含む。ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージの内容は、第４実施形態と同様であってもよい。

複数の動作の例のうちの図３５に示す動作の例において、ＵＥ１００−１〜ＵＥ１００−３は、第２の環境（ＵＥ１００−２が、ｅＮＢ２００が管理するセルに在圏する）にある。

ステップＳ７２１は、図３４におけるステップＳ７１１と同様である。

ステップＳ７２２において、ｅＮＢ２００は、ＵＥ１００−１及びＵＥ１００−３をリレーＵＥの候補として選択する。

ステップＳ７２３において、ｅＮＢ２００は、ステップＳ７２２において選択したＵＥ１００−１及びＵＥ１００−３に対して、サイドリンク同期信号及び／又はディスカバリ信号を送信するための設定を送信する。

ステップＳ７２４において、ＵＥ１００−１及びＵＥ１００−３は、ｅＮＢ２００から送信された設定に基づいて、サイドリンク同期信号及び／又はディスカバリ信号の報知を開始する。

ステップＳ７２５において、ＵＥ１００−２は、ｅＮＢ２００から送信された信号の測定値がステップＳ７２１でｅＮＢ２００から受信した閾値と対比する。ＵＥ１００−２は、測定値が閾値を下回るか否かを判定する。

ＵＥ１００−２は、測定値が閾値を下回ると判定した場合（Ｓ７２５ＹＥＳ）には、ステップＳ７２６において、ＵＥ１００−１及びＵＥ１００−３から報知されたサイドリンク同期信号及び／又はディスカバリ信号の測定を行う。

一方で、ＵＥ１００−２は、測定値が閾値を下回らないと判定した場合（Ｓ７２５ＮＯ）には、ｅＮＢ２００からの信号の測定を継続する。

ステップＳ７２７において、ＵＥ１００−２は、ｅＮＢ２００に対して、ステップＳ７２６で測定した測定結果の報告（測定報告）を行う。

ステップＳ７２８及びＳ７２９は、図３４に示すステップＳ７１８及び７１９と同様である。

複数の動作の例のうちの図３６に示す動作の例において、ＵＥ１００−１〜ＵＥ１００−３は、第１の環境又は第２の環境のいずれのＵＥであってもよい。

ステップＳ７３１〜Ｓ７３３は、図３５におけるステップＳ７２２〜Ｓ７２４と同様である。

ステップＳ７３４において、ＵＥ１００−２は、ＵＥ１００−１及びＵＥ１００−３から報知されたサイドリンク同期信号及び／又はディスカバリ信号を測定する。測定とは、例えば、受信レベル（ＲＳＲＰ及び／又はＲＳＲＱ）の測定である。

ステップＳ７３５において、ＵＥ１００−２は、ステップＳ７３４における測定値が閾値を超えるか否かを判断する。閾値は、ＵＥ１００−２のＳＩＭ（Ｕ−ＳＩＭ：Ｕｎｉｖｅｒｓａｌ−ＳｕｂｓｃｒｉｂｅｒＩｄｅｎｔｉｔｙＭｏｄｕｌｅＣａｒｄ）に予め記憶された情報に基づいて設定されたものである。

ＵＥ１００−２は、ステップＳ７３５において、ＵＥ１００−１から受信したサイドリンク同期信号及び／又はディスカバリ信号の測定値が閾値を超えたと判断した場合（ステップＳ７３５ＹＥＳ）に、ステップＳ７３６において、ＵＥ１００−１に対してリレー制御を要求する。

一方で、ＵＥ１００−２は、ＵＥ１００−１及びＵＥ１００−３から受信したサイドリンク同期信号及び／又はディスカバリ信号の測定値が閾値を超えていないと判断した場合（ステップＳ７３５ＮＯ）には、ＵＥ１００−１及びＵＥ１００−３から受信したサイドリンク同期信号及び／又はディスカバリ信号の測定を継続する。

ステップＳ７３７において、ＵＥ１００−１は、ＵＥ１００−２からリレー制御の要求を受けた場合、当該要求をｅＮＢ２００へ転送する。

ステップＳ７３８において、ｅＮＢ２００は、ＵＥ１００−１から転送されたＵＥ１００−２からのリレー制御の要求を受けると、リレーＵＥをＵＥ１００−１に決定する。

ステップＳ７３９は、ステップＳ７１９と同様である。

複数の動作の例のうちの図３７に示す動作の例において、ＵＥ１００−１〜ＵＥ１００−３は、第２の環境（ＵＥ１００−２が、ｅＮＢ２００が管理するセルに在圏する）にある。

ステップＳ７４１〜Ｓ７４３は、図３４におけるステップＳ７１１〜７１３と同様である。

ステップＳ７４４において、ｅＮＢ２００は、ＵＥ１００−２からのリレー制御の要求に応じて、サイドリンク同期信号（ＳｉｄｅＬｉｎｋＳｙｎｃｈｒｏｎｉｚａｔｉｏｎＳｉｇｎａｌ：ＳＬＳＳ）及び／又はディスカバリ信号（ＤｉｓｃｏｖｅｒｙＳｉｇｎａｌ）の送信をＵＥ１００−２へ要求する。

ステップＳ７４５において、ＵＥ１００−２は、ｅＮＢ２００からの要求に応じて、サイドリンク同期信号及び／又はディスカバリ信号を報知する。

ステップＳ７４６において、ＵＥ１００−１及びＵＥ１００−３は、ＵＥ１００−２から報知されたサイドリンク同期信号及び／又はディスカバリ信号の測定を行う。測定とは、例えば、受信レベル（ＲＳＲＰ及び／又はＲＳＲＱ）の測定である。

ステップＳ７４７において、ＵＥ１００−１及びＵＥ１００−３は、ｅＮＢ２００に対して、ステップＳ７４６で測定した測定結果の報告（測定報告）を行う。

ステップＳ７４８において、ｅＮＢ２００は、ＵＥ１００−１及びＵＥ１００−３から受信した測定報告に基づいて、リレーＵＥをＵＥ１００−１に決定する。ｅＮＢ２００は、例えば、ＵＥ１００−１から受信した測定報告に含まれるＵＥ１００−２からの信号の測定値とＵＥ１００−３から受信した測定報告に含まれるＵＥ１００−２からの信号の測定値とを対比し、ＵＥ１００−１から受信した測定報告に含まれるＵＥ１００−２からの信号の測定値の方が高いことからＵＥ１００−１をリレーＵＥに決定してもよい。

ステップＳ７４９は、図３４に示すステップＳ７１９と同様である。

複数の動作の例のうちの図３８に示す動作の例において、ＵＥ１００−１〜ＵＥ１００−３は、第２の環境（ＵＥ１００−２が、ｅＮＢ２００が管理するセルに在圏する）にある。

ステップＳ７５１により、ｅＮＢ２００は、ＵＥ１００−２をリモートＵＥとして決定する。ｅＮＢ２００は、例えば、ＵＥ１００−２からｅＮＢ２００からの信号の測定結果を含む測定報告を受信する。ｅＮＢ２００は、当該測定結果が所定の値より低い（悪い）場合に、ＵＥ１００−２をリモートＵＥとして決定してもよい。

ステップＳ７５２により、ｅＮＢ２００は、サイドリンク同期信号及び／又はディスカバリ信号に関する設定情報をＵＥ１００−２へ送信する。

ステップＳ７５３において、ＵＥ１００−２は、ｅＮＢ２００から受信した設定情報を適用し、サイドリンク同期信号及び／又はディスカバリ信号を報知する。

ステップＳ７５４〜Ｓ７５７は、ステップＳ７４６〜７４９と同様である。

複数の動作の例のうちの図３９に示す動作の例において、ＵＥ１００−１〜ＵＥ１００−３は、第１の環境又は第２の環境のいずれのＵＥであってもよい。

ステップＳ７６１において、ＵＥ１００−２は、ｅＮＢ２００からの信号の測定値と予めｅＮＢ２００から受信した閾値と対比する。ＵＥ１００−２は、測定値が閾値を下回るか否かを判定する。

ＵＥ１００−２は、測定値が閾値を下回ると判定した場合（Ｓ７６１ＹＥＳ）には、ステップＳ７１３において、サイドリンク同期信号及び／又はディスカバリ信号を報知する。

一方で、ＵＥ１００−２は、測定値が閾値を下回らないと判定した場合（Ｓ７６１ＮＯ）には、再度、ｅＮＢ２００からの信号の測定を継続する。

ステップＳ７６２〜Ｓ７６６は、ステップＳ７４５〜Ｓ７４９と同様である。

第６実施形態によって、ｅＮＢ２００は、複数のＵＥのうち、リモートＵＥとして適切なＵＥをリモートＵＥに選択し、リレー制御を実行することができる。

（第６実施形態の追加実施例）
第６実施形態の追加実施例は、第６実施形態において、ｅＮＢ２００がＵＥ１００−１をリモートＵＥに決定した場合に、さらに、ＵＥ１００−１がリモートＵＥになるか否かを判断する動作に関する。

図４０により、ｅＮＢ２００及びＵＥ１００−１の動作の例を以下に説明する。

ステップＳ７７１及びＳ７７２は、図３４のステップＳ７１８及びＳ７１９、図３５のステップＳ７２８及びＳ７２９、図３６のステップＳ７３８及びＳ７３９、図３７のステップＳ７４８及びＳ７４９、図３８のステップＳ７５６及びＳ７５７並びに図３９のステップＳ７６５及びＳ７６６に対応する。

ステップＳ７７３において、ＵＥ１００−１は、リレーＵＥとして動作するか否か（言い換えると、ステップＳ７７２において受信したＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージに含まれる設定を適用するか否か）を判断する。

ステップＳ７７４において、ＵＥ１００−１は、ステップＳ７７３において判断した結果（又は判断した結果を踏まえて、ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージに基づく設定が完了したか否か）をｅＮＢ２００へ送信する。

図４１により、ｅＮＢ２００及びＵＥ１００−１の動作の例を以下に説明する。

ステップＳ７８１は、ステップＳ４７１と同様である。

ステップＳ７８２において、ｅＮＢ２００は、ＵＥ１００−１がリレーＵＥであることを示す情報（ＲｅｌａｙＵＥｉｎｄｉｃａｔｉｏｎ）を送信する。

ステップＳ７８３において、ＵＥ１００−１は、ＲｅｌａｙＵＥｉｎｄｉｃａｔｉｏｎを受信すると、ステップＳ７７３と同様に、ＵＥ１００−１は、リレーＵＥとして動作するか否かを判断する。

ステップＳ７８４において、ＵＥ１００−１は、ステップＳ７８３において判断した結果をｅＮＢ２００へ送信する。

ステップＳ７８５において、ｅＮＢ２００は、ステップＳ７８４において受信したＵＥ１００−１の判断結果がリレーＵＥとして動作する（ＯＫ）か否かを判断する。

ＵＥ１００−１の判断結果がリレーＵＥとして動作する（ＯＫ）の場合（ステップＳ７８５ＹＥＳ）、ｅＮＢ２００は、ステップＳ７８６において、ｅＮＢ２００は、ステップＳ７７２と同様にＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージをＵＥ１００−１へ送信する。

ＵＥ１００−１の判断結果がリレーＵＥとして動作することを許否する（ＮＧ）の場合（ステップＳ７８５ＮＯ）、ｅＮＢ２００は、ＵＥ１００−１へＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを送信しない（送信することを制限する）。

［第７実施形態］
次に、第７実施形態について、図４２及び図４３を用いて説明する。図４２は、データが発生してから送信されるまでの遅延を説明するための図である。図４３は、第７実施形態に係る動作を説明するためのシーケンス図である。

第７実施形態では、高優先データが発生するケースについて説明する。なお、上述の実施形態の少なくともいずれかと同様の部分は、説明を省略する。

図４２に示すように、時間方向において制御領域（ＰＳＣＣＨ）とデータ領域（ＰＳＳＣＨ）とが交互に配置される無線リソースプールを直接通信に用いるケースを想定する。直接通信に用いられる無線リソースプールは、時間方向において所定の周期（ＳＣ期間：ＳＣＰｅｒｉｏｄ）で繰り返し配置される。また、直接通信に用いられる無線リソースプールは、制御領域（物理サイドリンク制御チャネル（ＰＳＣＣＨ：Ｐｈｙｓｉｃａｌｓｉｄｅｌｉｎｋｃｏｎｔｒｏｌｃｈａｎｎｅｌ））と、データ領域（物理サイドリンク共有チャネル（ＰＳＳＣＨ：Ｐｈｙｓｉｃａｌｓｉｄｅｌｉｎｋｓｈａｒｅｄｃｈａｎｎｅｌ））とによって構成される。制御領域とデータ領域とからなる複数の無線リソースプールが時間方向に配置される。１つの無線リソースプールの時間方向の長さは、無線リソースプールの周期であるＳＣ期間（ＳＣＰｅｒｉｏｄ）と一致する。制御領域とデータ領域とは、時間方向において交互に配置される。従って、制御領域は、時間方向において間隔をおいて配置される。データ領域は、時間方向において、制御領域の後に続く。

制御領域は、直接通信によりサイドリンク用の制御情報（ＳＣＩ：ＳｉｄｅｌｉｎｋＣｏｎｔｒｏｌＩｎｆｏｒｍａｔｉｏｎ）を送信するためのＰＳＣＣＨが配置される領域である。従って、制御領域は、直接通信によりＳＣＩを送信するための無線リソース（以下、制御リソース）が配置される制御リソースプールに相当する。なお、ＳＣＩは、直接通信によりデータを送信するために割り当てられた無線リソース（以下、データリソース）を通知するための情報である。具体的には、ＳＣＩは、データリソースの割当情報を含む。データ領域は、データを送信するためのＰＳＳＣＨが配置される領域である。従って、データ領域は、直接通信によりデータを送信するための無線リソースが配置されるデータリソースプールに相当する。なお、制御領域は、上述のＳＣプールに相当する。データ領域は、上述のデータプールに相当する。

図４２に示すように、ＵＥ１００は、制御領域が経過した後に、他のＵＥに送信すべきデータ（パケット）が発生した場合、データ領域の後に続く次の制御領域に達するまで待つ。ＵＥ１００は、次の制御領域内の無線リソースを用いて、その後に続くデータ領域内の無線リソースを通知するためのＳＣＩを他のＵＥに送信する。その後、ＵＥ１００は、ＳＣＩで通知した無線リソースを用いて、他のＵＥに送信すべきデータを送信する。従って、ＵＥ１００は、データが発生したＳＣ期間が経過し、かつ、その後の制御領域に対応する時間が経過した後でなければ、発生したデータを送信できないため、所定の遅延が発生してしまう。

ここで、通常のデータ（通常パケット）よりも優先度が高いデータ（高優先パケット）が発生した場合、上述の所定の遅延が高優先パケットに要求される許容遅延を越える可能性がある。その結果、ＵＥ１００が許容遅延の範囲内で高優先パケットを送信できない虞がある。そこで、優先度が高いデータが発生した場合に直接通信により適切にデータを送信可能にする技術を説明する。

以下において、ＵＥ１００−１がＵＥ１００−２に直接通信によりデータ（パケット）を送信するケースを例に挙げて説明する。

図４３に示すように、ステップＳ８０１において、ＵＥ１００−１は、制御領域内でＳＣＩを直接通信によりＵＥ１００−２に送信する。本実施形態では、ＳＣＩは、直接通信によりデータを送信するために割り当てられた無線リソースを通知するための情報である。具体的には、ＳＣＩは、データ領域内で時間方向に分かれて配置された複数の無線リソースを示す無線リソースの割当情報を含む。なお、ＳＣＩは、ＵＥ１００−２宛ての宛先識別子を含む。ＳＣＩを受信したＵＥ１００−２は、ＳＣＩ（割当情報）に基づいて、データが送信される無線リソースが分かる。

ステップＳ８０２において、ＵＥ１００−１は、割当情報によって示される無線リソース（繰り返し送信のための複数のリソースを含む第１の無線リソース）を用いて、通常パケット（Ｎｏｒｍａｌｐｒｉｏｒｉｔｙｐａｃｋｅｔ）を送信する。通常パケットは、高優先度パケットよりも優先度が低い優先度（例えば、通常の優先度）を有する。ＵＥ１００−２は、割当情報に基づいてデータを受信する。

なお、ＵＥ１００−２は、通常パケットを４回繰り返し送信する。ＵＥ１００−２は、４回受信したパケットを合成して、通常パケットを取得する。

ステップＳ８０３において、ＵＥ１００−１において、送信予定のデータ（未送信の通常パケット）よりも優先度が高い高優先データ（高優先パケット）が発生する。

ステップＳ８０４において、ＵＥ１００−１は、割当情報によって示される無線リソース（第２の無線リソース）を用いて、通常パケットよりも先に高優先パケット（Ｈｉｇｈｐｒｉｏｒｉｔｙｐａｃｋｅｔ）を送信する。すなわち、ＵＥ１００−１は、送信中のデータに高優先パケットを割り込ませて、高優先パケットを優先的に送信する。このように、ＵＥ１００−１は、送信予定の通常パケットのために割り当てられた無線リソースを、高優先パケットを送信するために用いる。

なお、ＵＥ１００−１は、送信中の通常パケットの再送（４回繰り返し送信）が終了していない場合には、通常パケットの再送が完了した後に、高優先パケットの送信を開始する。これにより、ＵＥ１００−２は、通常パケットと高優先パケットとを合成せずに、通常パケットと高優先パケットとをそれぞれ適切に受信（取得）することができる。

ＵＥ１００−１は、第２の無線リソースを用いて送信されるパケット（データ）が、送信予定の通常パケット（データ）ではなく、高優先パケット（データ）であることを示す情報を送信してもよい。例えば、ＵＥ１００−１は、高優先パケットと共に、高優先パケットを示すビット情報を送信できる。ＵＥ１００−１は、高優先パケットとは別に、高優先パケットであることを示す情報を送信してもよい。ＵＥ１００−１は、高優先パケットよりも先又は後に高優先パケットであることを示す情報を送信してもよい。

ＵＥ１００−１は、論理チャネルに優先度が関連付けられている場合には、論理チャネルの識別子（ＬＣＩＤ）に優先度が関連付けられているとみなすことができる。このため、ＵＥ１００−１は、送信予定の通常パケットのためのＬＣＩＤよりも優先度が高いＬＣＩＤを用いて、高優先パケットを送信できる。すなわち、ＵＥ１００−１は、通常パケットの送信に用いていた論理チャネルよりも優先度が高い論理チャネルに対応するＬＣＩＤを含む高優先パケットを送信できる。ＵＥ１００−１は、当該優先度の高い論理チャネルを用いて高優先パケットを送信できる。

なお、論理チャネル（グループ）及びＬＣＩＤの優先度に関する情報は、ｅＮＢ２００から送信（ユニキャスト又はブロードキャスト）により各ＵＥ１００に通知されてもよい。各ＵＥ１００は、事前設定（ｐｒｅ−ｃｏｎｆｉｇｕｒｅｄ）により、上記優先度に関する情報を有していてもよい。なお、論理チャネルグループに優先度が関連付けられている場合には、ＵＥ１００−１は、論理チャネルグループの識別子（ＬＣＧＩＤ：ＬｏｇｉｃａｌＣｈａｎｎｅｌＧｒｏｕｐＩＤ）を用いて、上記動作を実行してもよい。

一方、ＵＥ１００−２は、割当情報に基づいて、第２の無線リソースを用いて送信される高優先パケットを受信する。ＵＥ１００−２は、第２の無線リソースを用いて送信されたパケットが送信予定の通常パケットではなく高優先パケットであることを示す情報を受信した場合に、受信したパケットが高優先パケットであることを判断してもよい。また、ＵＥ１００−２は、ＬＣＩＤに基づいて、受信したパケットが高優先パケットであることを判断してもよい。具体的には、ＵＥ１００−２は、これまでに受信したパケットに含まれるＬＣＩＤよりも優先度が高いＬＣＩＤを受信することにより、ステップＳ８０３において受信したパケットが高優先度であることを判断してもよい。ＵＥ１００−２は、ステップＳ８０３において受信したパケットの内容がこれまでに受信したパケットと関連がない場合に、ステップＳ８０３において受信したパケットが高優先パケットであると判断してもよい。

ステップＳ８０５において、ＵＥ１００−１は、通常パケットの送信を再開する。ＵＥ１００−１は、高優先パケットを全て送信した場合、通常パケットの送信を再開する。ＵＥ１００−１は、上述と同様に、通常パケットであることを示す情報を送信してもよい。ＵＥ１００−１は、優先度が低いＬＣＩＤを用いて、通常パケットを送信してもよい。

ＵＥ１００−２は、通常パケットを受信する。ＵＥ１００−１は、通常パケットであることを示す情報及び／又は優先度が低いＬＣＩＤにより、受信したパケットが通常パケットであることを判断してもよい。

その後、ＵＥ１００−１は、送信予定の通常パケットを全て送信できていない場合には、次の制御領域内の無線リソースを用いて新たなＳＣＩを送信し、未送信の通常パケットを送信することができる。

以上のように、ＵＥ１００−１は、ＳＣＩを通知した後に高優先パケットが発生した場合であっても、次の制御領域で制御情報を送信する前に、高優先パケットを送信することができる。このため、ＵＥ１００−１は、許容遅延内に高優先パケットを送信できるため、直接通信により適切にデータを送信することが可能である。

（第７実施形態の変更例１）
次に、第７実施形態の変更例１について、図４４を用いて説明する。図４４は、第７実施形態の変更例１に係る動作を説明するためのシーケンス図である。

上述の第７実施形態では、ＵＥ１００−１の通信相手がＵＥ１００−２のみであり、通常パケットと高優先パケットとの送信先が同じであった。本変更例では、通常パケットと高優先パケットとの送信先が異なるケースについて説明する。なお、上述の実施形態の少なくともいずれかと同様の部分は、説明を省略する。

図４４に示すように、ステップＳ９０１において、ＵＥ１００−１において、ＵＥ１００−２に送信すべきパケット（通常パケット）が発生する。なお、ＵＥ１００−１は、ＵＥ１００−２及びＵＥ１００−３が通信相手であるが、ＵＥ１００−３に送信すべきパケットは発生していない。このように、複数の通信相手が存在する場合であっても、必ずしも全ての通信相手に送信すべきパケットが発生するわけではない。

ステップＳ９０２において、ＵＥ１００−１は、ＳＣＩを送信する。ＵＥ１００−１は、送信予定のパケットの送信先であるＵＥ１００−２の宛先識別子に加えて、高優先パケットの送信先になり得る候補端末であるＵＥ１００−３の宛先識別子をＳＣＩに含める。

ＵＥ１００−１は、高優先パケットの送信先になり得る候補端末を推定する。例えば、ＵＥ１００−１は、公衆安全のためのＵＥ（ＰｒｏＳｅ−ｅｎａｂｌｅｄＰｕｂｌｉｃＳａｆｅｔｙＵＥ）を候補端末として推定してもよい。ＵＥ１００−１は、各ＳＣＩを送信する前に候補端末を推定してもよい。ＵＥ１００−１は、最初にＳＣＩを送信する前にだけ、候補端末を推定してもよい。ＵＥ１００−１は、その後にＳＣＩを送信する場合には、候補端末の推定を省略し、過去に推定した候補端末の宛先識別子をＳＣＩに含めてもよい。

また、ＵＥ１００−１は、送信先の識別子（宛先識別子）に基づいて高優先パケットの送信先になり得る候補端末を推定してもよい。例えば、ＵＥ１００−１は、過去に高優先パケットを受信した場合に、高優先パケットの送信元の識別子が示すＵＥを候補端末と推定してもよい。ＵＥ１００−１は、発生する高優先パケットの送信先が決まっている場合に、当該送信先を候補端末としてもよい。ＵＥ１００−１は、重要なＵＥ（例えば、作戦本部で用いられるＵＥ）を候補端末と決定してもよい。ＵＥ１００−１は、アプリケーションレベル（ＰｒｏＳｅＦｕｎｃｔｉｏｎ）の情報に基づいて、重要なＵＥ（すなわち、候補端末）を決定してもよい。

また、ＵＥ１００−１は、高優先データが発生した時に、所定時間パケットの送信先でないＵＥ（すなわち、当該ＵＥ宛てのパケットを送信してから所定時間経過している場合の当該ＵＥ）を候補端末として推定してもよい。ＵＥ１００−１は、所定時間内にパケットの送信先であったＵＥ（すなわち、当該ＵＥ宛てのパケットを送信してから所定時間経過していない場合の当該ＵＥ）を候補端末と推定してもよい。ＵＥ１００−１は、パケットを送信した場合に、所定時間を計測するためのタイマを開始してもよい。ＵＥ１００−１は、タイマが満了した場合、タイマを開始するトリガとなるパケットの送信元のＵＥを、候補端末と推定する。複数のＵＥと直接通信を行うＵＥ１００−１は、送信先のＵＥ毎に所定時間を測定するためのタイマを開始及び停止してもよい。ＵＥ１００−１は、満了したタイマに対応するＵＥを候補端末と推定してもよい。なお、ＵＥ１００−１は、直接通信を既に終了したＵＥに対応するタイマをリセット（又は停止）してもよい。

ＵＥ１００−１は、候補端末が送信予定のパケットの送信先でない場合であっても、候補端末（ＵＥ１００−３）の宛先識別子をＳＣＩに含める。従って、ＵＥ１００−１は、高優先パケットが発生していないにもかかわらず、候補端末の宛先識別子をＳＣＩに含める。ＵＥ１００−１は、候補端末の宛先識別子を通常パケット用の宛先識別子とは別のフィールドに格納することによって、候補端末の宛先識別子であることを明確化してもよい。なお、ＵＥ１００−１は、上述した第２実施形態で説明したように、１つのＳＣＩで複数の宛先識別子を通知できる。

ＵＥ１００−３は、ＳＣＩに自身の宛先識別子が含まれるため、ＳＣＩに含まれる割当情報により示される無線リソース（ＰＳＳＣＨ）をモニタする。

ステップＳ９０３において、ＵＥ１００−１は、ステップＳ８０２と同様に、通常パケットを送信する。ＵＥ１００−２は、通常パケットを受信する。ＵＥ１００−３は、ＳＣＩにＵＥ１００−３の宛先識別子が含まれるため、通常パケットを受信する。ＵＥ１００−３は、例えば、受信したパケット（ヘッダ）に含まれる宛先識別子がＵＥ１００−３を示していない場合には、受信したパケットを破棄できる。ＵＥ１００−３は、上述した第２実施形態の「（Ｈ）データの受信」と同様の動作を実行してもよい。

ステップＳ９０４において、ＵＥ１００−１において、高優先パケットが発生する。高優先パケットは、ＵＥ１００−３宛てのパケットである。

ステップＳ９０５において、ＵＥ１００−１は、ステップＳ８０３と同様に、高優先パケットを送信する。ＵＥ１００−１は、高優先パケット（のＭＡＣサブヘッダ）にＵＥ１００−３の宛先識別子を含める。ＵＥ１００−２は、受信したパケット（高優先パケット）に含まれる宛先識別子がＵＥ１００−２を示していないため、受信したパケットを破棄する。ＵＥ１００−３は、受信したパケット（高優先パケット）に含まれる宛先識別子がＵＥ１００−２を示しているため、受信したパケットを破棄せずにデコードする。これにより、ＵＥ１００−３は、高優先パケットが発生したＳＣ期間内に、高優先パケットを受信することができる。

ステップＳ９０６は、ステップＳ８０５に対応する。

以上のように、ＵＥ１００−１は、発生した高優先パケットの送信先が通常パケットの送信先と異なる場合であっても、許容遅延内に高優先パケットを送信できる。

（第７実施形態の変更例２）
次に、第７実施形態の変更例２について説明する。第７実施形態の変更例１では、制御情報に高優先パケットの送信先になり得る候補端末の宛先識別子を含めることによって、候補端末であるＵＥ１００−３が割当情報により示される無線リソース（ＰＤＳＣＨ）をモニタしていた。本変更例では、候補端末の宛先識別子を予め通知することにより、制御情報が候補端末の宛先識別子を含まない場合であっても、候補端末が割当情報により示される無線リソースをモニタする。

第１に、ＵＥ１００−１は、高優先パケットの送信先になり得る候補端末を推定する。ＵＥ１００−１は、高優先データを送信するために用いられるリソースプールと候補端末の宛先識別子とを関連付ける。ＵＥ１００−１は、直接通信に使用する送信リソースプールがすでに決まっている場合には、当該送信リソースプールを候補端末の宛先識別子と関連付ける。

第２に、ＵＥ１００−１は、関連付けられたリソースプールと候補端末の宛先識別子とを候補端末に通知する。例えば、ＵＥ１００−１は、リソースプールと関連付けられた候補端末の宛先識別子のリスト（ｄｅｓｔｉｎａｔｉｏｎＩＤＬｉｓｔ）を候補端末に通知できる。ＵＥ１００−１は、直接通信を行う前、又は、直接通信を行っている間に、リスト及び関連付けられたリソースプール（以下、優先情報）を通知できる。ＵＥ１００−１は、以下の方法により、優先情報を候補端末に通知できる。

第１の方法では、ＵＥ１００−１は、ｅＮＢ２００を介して、優先情報を候補端末に通知する。ＵＥ１００−１は、例えば、ＳＬＵＥＩｎｆｏｒｍａｔｉｏｎメッセージにより、優先情報をｅＮＢ２００に送信する。ｅＮＢ２００は、受信した優先情報内に含まれる宛先識別子に対応する各ＵＥ１００に対して、優先情報（又は、各ＵＥに該当する優先情報）を通知する。例えば、ｅＮＢ２００は、ＲＲＣ再設定（ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎ）メッセージにより、ＵＥ個別に優先情報を通知する。或いは、ｅＮＢ２００は、ＳＩＢ（ＳｙｓｔｅｍＩｎｆｏｒｍａｔｉｏｎＢｌｏｃｋ）等のブロードキャストにより優先情報を報知してもよい。

第２の方法では、ＵＥ１００−１は、近傍サービスにおける直接ディスカバリ（直接発見手順）により優先情報を候補端末に通知してもよい。なお、優先情報は、候補端末の宛先識別子のリスト及び関連付けられたリソースプールだけでなく、リソースプールの優先度（例えば、Ｈｉｇｎ／Ｍｉｄｄｌｅ／Ｌｏｗ）を示す情報が含まれていてもよい。リソースプールの優先度は、他の受信（例えば、異なるキャリアでの受信、異なるリソースプール）に対しての優先度を示す。例えば、ＵＥ１００−２は、受信機（ＲｘＣｈａｎｉｎ）の数に応じて、リソースプールの優先度を考慮して、受信を行うことができる。また、ＵＥ１００−２は、受信処理電力を削減するために、優先度が高いリソースプールをモニタし、優先度が低いリソースプールのモニタを省略してもよい。

候補端末であるＵＥ１００−３は、優先情報に自身の宛先識別子が含まれる場合、自身の宛先識別子に関連付けられたリソースプールをモニタする。ＵＥ１００−３は、リソースプール内の制御領域にＵＥ１００−１からのＳＣＩが含まれる場合、ＳＣＩに自身の宛先識別子が含まれない場合であっても、ＳＣＩに含まれる割当情報に基づいて、パケットの受信を行う。

以上のように、ＵＥ１００−１は、高優先パケットの発生にかかわらず、候補端末の宛先識別子及び関連付けられたリソースプールを予め候補端末に通知しておく。これにより、ＵＥ１００−１が、制御情報に候補端末の宛先識別子を含めない場合であっても、ＵＥ１００−３は、高優先パケットを取得することができる。

（第７実施形態の変更例３）
次に、第７実施形態の変更例３について、説明する。第７実施形態の変更例３では、データ（ＭＡＣサブヘッダ）に高優先パケットの送信先の宛先識別子を含める。

パケットを送信するＵＥ１００−１は、候補端末を含む複数のＵＥがデータリソースをモニタするように、上述の第２実施形態のように、パケット（データ）に複数の宛先のデータが含まれることを示す宛先識別子（特別な宛先識別子）又は複数の宛先識別子を含むＳＣＩを生成する。当該ＳＣＩを受信したＵＥ１００−２は、データ領域内の無線リソースをモニタする。

ここで、ＵＥ１００−１は、高優先パケットが発生した場合に、高優先パケット（ＭＡＣＰＤＵ）のＭＡＣサブヘッダに、高優先パケットの送信先の宛先識別子を格納する。ＵＥ１００−２は、受信したパケットに自身の宛先識別子が含まれない場合は、受信したパケットを破棄することができる。これにより、高優先パケットの送信先でないＵＥ１００は、受信したパケットをデコードすることを省略できる。また、ＵＥ１００−２は、第２実施形態の「（Ｈ）データの受信」と同様の動作を実行してもよい。

（第７実施形態の変更例４）
次に、第７実施形態の変更例４について説明する。第７実施形態では、高優先パケットが発生するケースを説明した。本変更例では、互いに異なる複数のデータ（パケット）が同じタイミングで発生するケースを説明する。

・複数のデータの宛先が同一であるケース
ＵＥ１００−１は、同じタイミングで同一の優先度を有する複数のデータが発生した場合、ＵＥ１００−１は、複数のデータのそれぞれとＬＣＩＤとを対応付ける。対応付けられたＬＣＩＤを用いて、対応するデータ（パケット）を送信する。パケットを受信するＵＥ１００−２は、ＬＣＩＤによりパケットを区別可能である。ＵＥ１００−２は、ＬＣＩＤに対応するパケット毎に処理することにより、複数のデータを適切に取得することができる。

なお、ＵＥ１００−１は、１つの宛先識別子を含む１つのＳＣＩを送信できる。ＵＥ１００−１は、ＰＨＹ層において、１ＭＡＣＰＤＵを４回繰り返し送信できる。なお、ＵＥ１００−１は、複数のデータのうちいずれかのデータを優先的に送信してもよい。

・複数のデータの宛先が異なるケース
ＵＥ１００−１は、同じタイミングで複数のデータが発生した場合、上述の第１実施形態又は第２実施形態のように、１つの制御領域（ＳＣプール）内で複数のＳＣＩを通知してもよいし、１つのＳＣＩで複数の宛先を通知してもよい。

ここで、ＵＥ１００−１は、宛先が異なる複数のデータを送信する場合、最初のデータ（第１データ）よりも後に送信されるデータ（第２データ）の送信が制限されてもよい。従って、ＵＥ１００−１は、第２データが送信し難くなるように制限されてもよい。例えば、第２データ自体を送信できる確率（ｔｘＰｒｏｂａｂｉｌｉｔｙ）、繰り返し送信（リピテーション）できる確率、ＰＳＣＣＨ内の制御リソースの選択確率、ＵＥが選択できるデータリソースの数の少なくともいずれかを低下することによって、ＵＥ１００−１は、第２データが送信し難くなる。なお、同一のＳＣ期間内において、複数のデータを送信するケースにおいて、ＵＥ１００−１は、第２データの送信が制限される。ＵＥ１００−１は、第１のＳＣ期間で第１データを送信し、第２のＳＣ期間で第２データを送信する場合には、第２データを制限なく送信できる。

また、複数の宛先にデータを送信する場合において、優先度に関係なく、ＵＥ１００−１が使用できるリソースが制限されてもよい。例えば、制御リソースのリソースブロック使用量、送信制御情報数（ＳＣＩの数）、送信制御確率（ｔｘＰｒｏｂａｂｉｌｉｔｙ）、データリソースのリソースブロック使用量、送信データ確率（ｔｘＰｒｏｂａｂｉｌｉｔｙ）等が制限されることによって、ＵＥ１００−１が使用できるリソースが制限されてもよい。これらのリソース制限は、ｅＮＢ２００からＳＩＢにより通知されてもよいし、ｅＮＢ２００から個別に設定されていてもよいし、ＵＥ１００−１に予め設定されていてもよい。

このような制限を設けることによって、直接通信用の無線リソースの消費を抑制できる。また、１つのデータを送信するＵＥと複数のデータを送信するＵＥとの間で無線リソースの使用量の不公平を抑制できる。すなわち、ＵＥが自律的にリソースを選択する場合と比べて、送信ＵＥ間でのリソース使用の不公平を抑制できる。

また、ＵＥ１００−１は、第２データの優先度が第１データの優先度と同じ又は高い場合には、第２データが制限なく送信してもよい。従って、ＵＥ１００−１は、第２データを第１データと同じように送信できる。

これにより、ＵＥ１００−１が高優先データを送信しつつも、優先度が低いデータと他のＵＥが送信する優先度が高いデータとが衝突することを避けることができる。

［第８実施形態］
次に、第８実施形態について説明する。第８実施形態では、直接通信用の複数のリソースプールが同一のキャリア内に設けられる。

（動作環境）
第８実施形態に係る動作環境について、図４２及び４５を用いて説明する。図４５は、第８実施形態に係る動作環境を説明するための図である。

図４５に示すように、ＵＥ１００（ＵＥ１００−１及びＵＥ１００−２）は、ｅＮＢ２００が管理するセル内に位置する。ＵＥ１００は、ｅＮＢ２００とセルラ通信（ＬＴＥ−Ｕｕ）を実行可能である。ＵＥ１００は、ＲＲＣコネクティッド状態である。或いは、ＵＥ１００は、ＲＲＣアイドル状態であってもよい。ＵＥ１００は、ｅＮＢ２００と通信を行う場合に、ＲＲＣアイドル状態からＲＲＣコネクティッド状態に移行してもよい。

ＵＥ１００−１及びＵＥ１００−２は、直接通信を実行中の状態又は、直接通信の実行を開始する前の状態である。ＵＥ１００−１及びＵＥ１００−２は、図４２に示すリソースプールを用いて、直接通信を行うことができる。具体的には、ＵＥ１００−１が直接通信によりデータ（パケット）をＵＥ１００−２に送信する。

（第８実施形態に係る動作）
第８実施形態に係る動作について、図４６及び図４７を用いて説明する。図４６は、実施形態に係る動作を説明するためのシーケンス図である。図４７は、実施形態に係る動作を説明するための図である。

ｅＮＢ２００は、セル内に位置するＵＥ１００−１及びＵＥ１００−２に直接通信用のリソースプールの設定を行う。ｅＮＢ２００は、本実施形態において、同一のキャリア内に複数のリソースプール（リソースプールＡ及びリソースプールＢ）を設ける（図４７参照）。なお、リソースプールＡ及びリソースプールＢが配置される周波数は異なる。リソースプールＢのＳＣ周期は、リソースプールＡのＳＣ周期よりも短い。

ｅＮＢ２００は、ＵＥ１００−１及びＵＥ１００−２に設定したリソースプール内の無線リソースをＵＥ１００−１及びＵＥ１００−２に割り当てる。ｅＮＢ２００は、データリソースをＵＥ１００−１及びＵＥ１００−２に割り当てる場合には、データリソースプールをＵＥ１００−１及びＵＥ１００−２に設定しない。ＵＥ１００−１及びＵＥ１００−２は、ｅＮＢ２００から無線リソースを割り当てられずに、設定されたリソースプールから無線リソースを自律的に選択してもよい。なお、ＵＥ１００−１及びＵＥ１００−２は、セル外に位置する場合、予め設定されたリソースプールを用いて、直接通信を行う。

ＵＥ１００−１及びＵＥ１００−２は、直接通信を実行中の状態又は、直接通信の実行を開始する前の状態である。ＵＥ１００−１は、直接通信によりデータを送信している場合は、リソースプールＡ内の制御リソース及びデータリソースを用いて、データ（パケット）をＵＥ１００−２に送信している。

図４６に示すように、ステップＳ１０１０において、ｅＮＢ２００は、直接通信に用いられるリソースプールと優先度との関連付けに関する第１優先度情報をＵＥ１００（ＵＥ１００−１及びＵＥ１００−２）に送信する。ＵＥ１００は、第１優先度情報を受信する。ｅＮＢ２００は、ブロードキャスト（例えば、ＳＩＢ）又はユニキャスト（例えば、ＲＲＣ再設定メッセージ）により第１優先度情報をＵＥ１００に送信してもよい。なお、セルのカバレッジ外に位置するＵＥ１００は、第１優先度情報が予め設定されていてもよい。

第１優先度情報は、直接通信用のリソースプールと優先度とが関連付けられている情報である。例えば、第１優先度情報では、リソースプールＡと優先度０（例えば、Ｌｏｗｐｒｉｏｒｉｔｙ）が関連付けられ、リソースプールＢと優先度１（例えば、Ｈｉｇｈｐｒｉｏｒｉｔｙ）とが関連付けられている。

また、ｅＮＢ２００は、直接通信用のリソースプールのうちモニタが必須である必須リソースプールに関する情報をＵＥ１００に送信してもよい。ｅＮＢ２００は、第１優先度情報と共に必須リソースプールに関する情報をＵＥ１００に送信してもよい。例えば、必須リソースプールに関する情報は、各リソースプールと関連付けられたフラグ情報（ｔｒｕｅ／ｆａｌｓｅ）である。例えば、「ｔｒｕｅ」がモニタが必須であることを示す。「ｆａｌｓｅ」がモニタが必須でないことを示す。例えば、リソースプールＡに「ｆａｌｓｅ」が関連付けられ、リソースプールＢに「ｔｒｕｅ」が関連付けられる。

ＵＥ１００は、必須リソースプールに関する情報を受信した場合、必須リソースプールをモニタする。具体的には、ＵＥ１００は、必須リソースプール内の制御領域内にＳＣＩを受信するための受信試行を行う。ＵＥ１００は、制御領域内にＳＣＩが含まれる場合は、ＳＣＩ内の無線リソースの割当情報（データリソース）に基づいて、データ領域をモニタし、データを受信する。ＵＥ１００は、制御領域内にＳＣＩが含まれない場合には、データ領域のモニタを行わない。

ステップＳ１０２０において、ｅＮＢ２００は、論理チャネルに関する識別情報（例えば、論理チャネルグループの識別子（ＬＣＧＩＤ））と優先度とに関する第２優先度情報をＵＥ１００（ＵＥ１００−１及びＵＥ１００−２）に送信する。ＵＥ１００は、第２優先度情報を受信する。ｅＮＢ２００は、ブロードキャスト（例えば、ＳＩＢ）又はユニキャスト（例えば、ＲＲＣ再設定メッセージ）により第２優先度情報をＵＥ１００に送信してもよい。なお、セルのカバレッジ外に位置するＵＥ１００は、第２優先度情報が予め設定されていてもよい。

第２優先度情報は、論理チャネルに関する識別情報（例えば、論理チャネルグループの識別子（ＬＣＧＩＤ））と優先度とが関連付けられている情報である。例えば、第２優先度情報では、ＬＣＧＩＤ♯１と優先度０（例えば、Ｌｏｗｐｒｉｏｒｉｔｙ）とが関連付けられ、ＬＣＧＩＤ♯２と優先度１（例えば、Ｈｉｇｈｐｒｉｏｒｉｔｙ）とが関連付けられている。なお、論理チャネルに関する識別情報は、論理チャネルの識別子（ＬＣＩＤ）であってもよい。従って、ＬＣＩＤと優先度とが関連付けられていてもよい。

また、ｅＮＢ２００は、優先度に関する情報として、通常のＬＣＧＩＤ（又はＬＣＩＤ）よりも優先度が高いＬＣＧＩＤ（又はＬＣＩＤ）をＵＥ１００−１に通知してもよい。例えば、優先リストには、優先度が低いＬＣＧＩＤ（又はＬＣＩＤ）は記載されてなく、優先度が高いＬＣＧＩＤ（又はＬＣＩＤ）が記載されていてもよい。従って、ＵＥ１００−１は、優先リストに記載されていないＬＣＧＩＤ（又はＬＣＩＤ）が通常の優先度を有すると判断してもよい。

なお、ｅＮＢ２００は、第１優先度情報と第２優先度情報とを同時にＵＥ１００に送信してもよい。

ステップＳ１０３０において、ＵＥ１００−１内で、優先度が高いデータ（以下、高優先データ）が発生する。なお、高優先データは、高優先（Ｈｉｇｈｐｒｉｏｒｉｔｙ）を有するデータでなくてもよい。高優先データは、ＵＥ１００−１が制御リソースプール内の制御リソースを用いて送信するデータ（例えば、Ｌｏｗｐｒｉｏｒｉｔｙ）よりも優先度が高いデータ（Ｍｉｄｄｌｅｐｒｉｏｒｉｔｙ）であればよい。

ＵＥ１００−１は、高優先データよりも優先度が低い通常データを送信するために用いられるリソースプールＡではなく、リソースプールＡよりも周期が短いリソースプールＢを選択する。すなわち、ＵＥ１００−１は、リソースプールＡのＳＣ期間よりも短い周期で繰り返し配置されるリソースプールＢを選択する。ＵＥ１００−１は、リソースプールのＳＣ周期に基づいて、高優先データを送信するためのリソースプールを選択してもよい。

また、ＵＥ１００−１は、第１優先度情報に基づいて、リソースプールＢを高優先データを送信するためのリソースプールとして選択してもよい。ＵＥ１００−１は、リソースプールＡよりも高い優先度を有するリソースプールＢを高優先データを送信するためのリソースプールとして選択してもよい。なお、ＵＥ１００−１は、優先度が低い通常データを送信する場合は、優先度が高いリソースプールＢを選択できない。リソースプールＢは、優先度が高いデータを送信するための高優先データ専用のリソースプールである。

また、ＵＥ１００−１は、必須リソースプールに関する情報に基づいて、リソースプールＢを高優先データを送信するためのリソースプールとして選択してもよい。例えば、ＵＥ１００−１は、リソースプールＢと同じ優先度を有し、かつ、必須リソースプールはないリソースプールＣが設定されていた場合、リソースプールＣではなく、リソースプールＢを選択してもよい。

ＵＥ１００−１は、リソースプールＢ内で、高優先データが発生した後に選択可能な制御リソースを選択する。ＵＥ１００−１は、最も早く高優先データを送信可能な制御リソース及びデータリソースを選択する。具体的には、図１０において、ＵＥ１００−１は、ＳＣ期間♯Ｂ２における制御リソースプール内の制御リソースを選択する。また、ＵＥ１００−１は、ＳＣ期間♯Ｂ２におけるデータリソースプール内のデータリソースを選択する。

なお、高優先データのためのリソースプールＢ及び無線リソース（制御リソース及び／又はデータリソース）は、ｅＮＢ２００が選択してもよい。ｅＮＢ２００は、ＵＥ１００−１と同様に、リソースプールＢ及び無線リソースを選択できる。ｅＮＢ２００は、選択したリソースプール及び無線リソースを通知するための制御情報（ＤＣＩ）をＵＥ１００−１に送信する。

ステップＳ１０４０において、ＵＥ１００−１は、高優先データを送信するためのデータリソースを通知するためのＳＣＩをＵＥ１００−２に送信する。ＵＥ１００−１は、リソースプールＢ内の選択された制御リソースを用いて、ＳＣＩを送信する。ＳＣＩは、リソースプールＢ内のデータリソースの割当情報を含む。

ＵＥ１００−２は、優先度が高いリソースプールＢ（内の制御リソースプール）を常にモニタしている。ＵＥ１００−２は、ｅＮＢ２００からの必須リソースプールに関する情報に基づいて、リソースプールＢが必須リソースプールである場合に、リソースプールＢを常にモニタしていてもよい。

制御リソースプールをモニタしているＵＥ１００−２は、リソースプールＢ内の制御リソースを用いてＵＥ１００−１からＳＣＩを受信する。ＵＥ１００−２は、受信したＳＣＩに基づいて、データ（高優先データ）が送信されるデータリソースを把握する。

ステップＳ１０５０において、ＵＥ１００−１は、ＳＣＩで通知したデータリソースを用いて高優先データをＵＥ１００−２に送信する。

ここで、ＵＥ１００−１は、高優先データよりも優先度が低い通常データを直接通信により送信している場合、通常データよりも高優先データを優先的に送信する。ＵＥ１００−１は、切りが良いところで通常データの送信を中断し、高優先データの送信を開始してもよい。例えば、ＵＥ１００−１は、通常データに対応するに対応するパケットの再送（４回繰り返し送信）が完了していない場合、パケットの再送が完了した後に、高優先データの送信を開始してもよい。

或いは、ＵＥ１００−１は、通常データの送信をすぐに中断し、高優先データの送信を開始してもよい。例えば、ＵＥ１００−１は、パケットの再送よりも高優先データの送信を優先してもよい。従って、ＵＥ１００−１は、通常データのパケットの再送が完了していない場合であっても、高優先データの送信を開始してもよい。この場合、ＵＥ１００−１は、通常データの送信を中断した旨をＵＥ１００−２に通知してもよい。これにより、ＵＥ１００−２は、途中まで受信した通常データを破棄せずに保持する。ＵＥ１００−２は、通常データの送信を中断した旨をＵＥ１００−１から受信しない場合には、途中まで受信した通常データを破棄してもよい。ＵＥ１００−１は、再送が完了していない場合には、高優先データの送信が完了した後に、再送を開始してもよい。ＵＥ１００−１は、通常データの送信を中断した旨をＵＥ１００−２に通知していない場合、再送が完了していないパケットを新たなパケットとして送信してもよい。

ＵＥ１００−１は、中断した通常データの送信を再開するタイミング（ＲｅｓｕｍｅＴｉｍｉｎｇ）及び／又は期間（ＲｅｓｕｍｅＰｅｒｉｏｄ）をＵＥ１００−２に通知してもよい。ＲｅｓｕｍｅＴｉｍｉｎｇは、通常データの送信を中断したＳＣ期間内で、通常データの送信を再開する場合のＰＳＣＣＨ時間リソースを指定する情報である。ＲｅｓｕｍｅＰｅｒｉｏｄは、通常データの送信を中断したＳＣ期間より後に、通常データの送信を再開する場合の期間を指定する情報である。ＵＥ１００−２は、ＲｅｓｕｍｅＴｉｍｉｎｇ及び／又はＲｅｓｕｍｅＰｅｒｉｏｄに基づいて、通常データの受信を再開する。

なお、ＵＥ１００−１は、ｅＮＢ２００からの指示に基づいて、高優先データを送信する前に通常データのパケットの再送を完了するか否かを判断してもよい。例えば、ｅＮＢ２００は、無線リソースの割当情報を含むＤＣＩに中断フラグ情報（Ｉｎｔｅｒｒｕｐｔｆｌａｇ）を含めてもよい。中断フラグ情報が「Ｔｒｕｅ」を示す場合、ＵＥ１００−１は、パケットの再送を完了していなくても、高優先データを送信する。一方、中断フラグ情報が「Ｆａｌｓｅ」を示す場合、ＵＥ１００−１は、パケットの再送が完了した後に、高優先データを送信する。なお、ＤＣＩに、ＲｅｓｕｍｅＴｉｍｉｎｇ及び／又はＲｅｓｕｍｅＰｅｒｉｏｄの情報が含まれていてもよい。

なお、ＵＥ１００−１は、１つのキャリア内でマルチクラスタ送信が許可されている場合には、リソースプールＡ内のデータリソースを用いて未送信のパケットを送信しつつ、リソースプールＢ内のデータリソースを用いて高優先データを送信してもよい。

以上によれば、ＵＥ１００−１は、リソースプールＡよりもＳＣ期間が短いリソースプールＢ内のデータリソースを用いて高優先データを送信する。このように、ＵＥ１００−１は、高優先データが発生した場合、ＳＣ期間に応じたリソースプール内の無線リソースを用いて高優先データを送信する。従って、ＵＥ１００−１は、高優先データが発生した場合、高優先データが発生したＳＣ期間内で高優先データを送信可能である。これにより、ＵＥ１００−１は、直接通信により適切にデータを送信可能である。

［第８実施形態の変更例］
次に、第８実施形態の変更例について、図４８を用いて説明する。図４８は、第８実施形態の変更例を説明するための図である。なお、第１実施形態と同様の部分は、説明を適宜省略する。

第８実施形態では、ＵＥ１００−２は、優先度の高い又はモニタが必須であるリソースプールＢを常にモニタしている。しかしながら、ＵＥ１００−２のモニタ負荷が大きくなるという問題がある。そこで、以下の方法により、ＵＥ１００−２は、常にモニタしなくてもよい。

図４８に示すように、ｅＮＢ２００は、ＵＥ１００−２がリソースプールＢのうち（実際に）モニタするリソースプールを決定する。すなわち、ｅＮＢ２００は、モニタ頻度を決定する。ｅＮＢ２００は、ユニキャスト（例えば、ＲＲＣ再設定メッセージ）によりモニタ頻度をＵＥ個別に設定してもよい。ｅＮＢ２００は、ブロードキャスト（例えば、ＳＩＢ）によりモニタ頻度を自局配下のＵＥに通知してもよい。或いは、ＵＥ１００−２は、モニタ頻度が予め設定されていてもよい。ＵＥ１００−２は、予め設定されたモニタ頻度をｅＮＢ２００に通知してもよい。

モニタ頻度は、モニタする期間の周期により決定されてもよい。図４８（Ａ）では、ＵＥ１００−２は、３ＳＣ期間毎にモニタを行う。ｅＮＢ２００は、モニタ周期を１／２／３／４／８／１６のいずれかにより、関連する各ＵＥに通知できる。

モニタ頻度は、高優先データが発生するタイミングが予測できないため、ランダムパターンにより決定されてもよい。ｅＮＢ２００は、ランダムパターンにより決定されたモニタ頻度をビットマップ又は疑似乱数により関連する各ＵＥに通知できる。図４８（Ｂ）では、ＵＥ１００−２は、｛０，１，１，０，０，１，０｝のビットマップに基づいて、モニタを行う。また、ＵＥ１００−２は、ＵＥ個別の識別子に基づく疑似乱数を用いて決定されたモニタ頻度で、モニタを行ってもよい。

ＵＥ１００−１は、ＵＥ１００−２がモニタするリソースプールに関するモニタ情報（すなわち、ＵＥ１００−２のモニタ頻度）をｅＮＢ２００から受信する。ＵＥ１００−１は、モニタ情報に基づいて選択された制御リソース及びデータリソースを用いて、高優先データを送信する。

ＵＥ１００−２がモニタするリソースプールの時間方向の間隔が、優先度が低いリソースプールＡのＳＣ期間よりも短くなるように、モニタ頻度が決定される。これにより、高優先データの送信遅延を低減させつつも、ＵＥ１００−２のモニタ負担を軽減できる。

［第９実施形態］
次に、第９実施形態について、図４９及び図５０を用いて説明する。図４９は、第９実施形態の動作を説明するためのシーケンス図である。図４９は、第９実施形態の動作を説明するための図である。なお、第８実施形態と同様の部分は、説明を適宜省略する。

第８実施形態では、リソースプールＡ及びリソースプールＢが、同一のキャリア内に設けられていた。第９実施形態では、リソースプールＡ及びリソースプールＢが、異なるキャリアに設けられる（図５０参照）。

図４９に示すように、ステップＳ１１１０において、ｅＮＢ２００は、キャリアと優先度との関連付けに関する第３優先度情報をＵＥ１００（ＵＥ１００−１及びＵＥ１００−２）に送信する。ＵＥ１００は、第３優先度情報を受信する。ｅＮＢ２００は、ブロードキャスト（例えば、ＳＩＢ１８）又はユニキャスト（例えば、ＲＲＣ再設定メッセージ）により第３優先度情報をＵＥ１００に送信してもよい。なお、セルのカバレッジ外に位置するＵＥ１００は、第３優先度情報が予め設定されていてもよい。また、ＵＥ１００が、直接ディスカバリにより第３優先度情報を周囲のＵＥ１００に送信してもよい。

第３優先度情報は、キャリアと優先度とが関連付けられている情報である。例えば、第３優先度情報では、キャリアＡと優先度０（例えば、Ｌｏｗｐｒｉｏｒｉｔｙ）が関連付けられ、キャリアＢと優先度１（例えば、Ｈｉｇｈｐｒｉｏｒｉｔｙ）とが関連付けられる。なお、１つのキャリアに複数の優先度が関連付けられていてもよい。例えば、キャリアＡと優先度０が関連付けられ、キャリアＢと優先度１，２，３とが関連付けられる。

第３優先度情報では、キャリアと論理チャネルグループの識別情報とが関連付けられていてもよい。ここで、論理チャネルグループの識別情報は、優先度と関連付けられている。ｅＮＢ２００は、論理チャネルグループの識別情報と優先度との関連付けをＵＥ１００に通知している。これにより、ＵＥ１００は、キャリアと優先度とが直接的に関連付けられていなくても、キャリアの優先度を把握できる。

また、ｅＮＢ２００は、キャリアと直接通信用のリソースプールとの関連付けに関する第４優先度情報をＵＥ１００（ＵＥ１００−１及びＵＥ１００−２）に送信する。ＵＥ１００は、第４優先度情報を受信する。

第４優先度情報には、各キャリアに関連付けられた直接通信用のリソースプールの情報が含まれていてもよい。ｅＮＢ２００は、キャリアに対応する第４優先度情報を当該キャリア毎に送信してもよい。従って、ｅＮＢ２００は、ＳＩＢ（例えば、ＳＩＢ１８）により、第１キャリアに関連付けられた第４優先度情報を第１キャリアで送信し、第２キャリアに関連付けられた第４優先度情報を第２キャリアで送信してもよい。すなわち、ｅＮＢ２００は、キャリア数に応じた第４優先度情報を含むＳＩＢを送信してもよい。或いは、ｅＮＢ２００は、インデックスが付された複数の第４優先度情報を送信し、各キャリアとインデックスとの関連づけを示す情報を送信してもよい。ＵＥ１００は、対応するインデックスの第４優先度情報を確認する。

なお、第８実施形態のように、同一のキャリアに複数のリソースプールが設けられる場合、キャリア及びリソースプールと優先度とが関連付けられていてもよい。例えば、キャリアＡ及びリソースプールＡと優先度０とが関連付けられ、キャリアＡ及びリソースプールＢと優先度２とが関連付けられ、キャリアＢ及びリソースプールＣと優先度１とが関連付けられる。

ステップＳ１１２０からＳ１１４０は、ステップＳ１０３０からＳ１０５０に対応する。なお、ＵＥ１００−１は、通常データの送信に用いられるキャリアよりも優先度が高いキャリアに設けられるリソースプールＢを高優先データを送信するためのリソースプールとして選択できる。

なお、ＵＥ１００−１は、同時送信可能なキャリア数を示す送信チェイン数（ＴｘＣｈａｉｎ）をｅＮＢ２００に通知してもよい。また、ＵＥ１００−２は、同時受信可能なキャリア数を示す受信チェイン数（ＲｘＣｈａｉｎ）をｅＮＢ２００に通知してもよい。ＵＥ１００−１及びＵＥ１００−２のそれぞれは、送信チェイン数に関する情報（例えば、「ｃｏｍｍＳｉｍｕｌｔａｎｅｏｕｓＴｘ」、「ｃｏｍｍＳｕｐｐｏｒｔＢａｎｄｓ」、「ｃｏｍｍＳｕｐｐｏｒｔｅｄＢａｎｄｓＰｅｒＢＣ」など）及び受信チェイン数に関する情報（例えば、「ｃｏｍｍＳｕｐｐｏｒｔｅｄＢａｎｄｓＰｅｒＢＣ」、「ｃｏｍｍＳｕｐｐｏｒｔＢａｎｄｓ」など）を含むＵＥ能力情報（ＵＥＣａｐａｂｉｌｉｔｙ）をｅＮＢ２００に通知してもよい。

なお、「ｃｏｍｍＳｉｍｕｌｔａｎｅｏｕｓＴｘ」は、「ｃｏｍｍＳｕｐｐｏｒｔｅｄＢａｎｄｓＰｅｒＢＣ」が示すバンド（すなわち、「ｃｏｍｍＳｕｐｐｏｒｔＢａｎｄｓ」が示すバンドのうち、同時受信をサポートしているバンド）において、ＵＥが同時送信を許可されているかを示す情報である。「ｃｏｍｍＳｕｐｐｏｒｔＢａｎｄｓ」は、ＵＥが直接通信をサポートしているバンド（周波数帯）を示す情報である。「ｃｏｍｍＳｕｐｐｏｒｔｅｄＢａｎｄｓＰｅｒＢＣ」は、ＵＥが直接通信及びセルラ通信（ＥＵＴＲＡ）で同時受信をサポートしているバンド（周波数帯）を示す情報である。

ｅＮＢ２００は、ＵＥ１００から通知された情報に基づいて、ＵＥ１００−１の送信チェイン数及びＵＥ１００−２の受信チェイン数の少なくとも一方に基づいて、第３優先度情報（キャリアと優先度との関連付け）を決定できる。

ｅＮＢ２００は、例えば、ＵＥ１００−２の受信チェイン数が２つである場合、セルラ通信（具体的には、ＤＬ（例えば、ＰＤＣＣＨ受信））のための受信チェインと、高優先データ受信のための受信チェインとのために、高優先度のキャリアを１つ設定してもよい。或いは、ｅＮＢ２００は、高優先データが同時に発生する確率が低いと判断し、高優先キャリアを２つ設定してもよい。この場合、ＵＥ１００−１は、いずれかの高優先キャリア内の直接通信用のリソースプールを用いて、高優先データを送信でき、ＵＥ１００−２は、両方の高優先キャリアをモニタすることにより、ＵＥ１００−１からの高優先データを受信できる。なお、ｅＮＢ２００−１は、以下を考慮して、第３優先度情報を決定してもよい。

第１に、キャリアと優先度とが１対１の対応関係にあるケースについて説明する。

「セルラ通信（ＤＬ）＞直接通信（ＨｉｇｈＰｒｉｏｐｒｉｔｙ）＞直接通信（ＬｏｗＰｒｉｏｐｒｉｔｙ）」の条件がある場合、セルラ通信（ＤＬ）のための受信チェイン（Ｈｉｇｈ）と、直接通信（ＨｉｇｈＰｒｉｏｐｒｉｔｙ）のための受信チェイン（Ｍｉｄｄｌｅ）と、直接通信（ＬｏｗＰｒｉｏｐｒｉｔｙ）のための受信チェイン（Ｌｏｗ）と、の合計３つの受信チェインが、受信ＵＥは必要である。受信ＵＥが、直接通信（ＬｏｗＰｒｉｏｐｒｉｔｙ）の受信を断念する場合は、２つの受信チェインが必要である。

「セルラ通信（ＤＬ）＝直接通信（ＨｉｇｈＰｒｉｏｐｒｉｔｙ）＞直接通信（ＬｏｗＰｒｉｏｐｒｉｔｙ）」の条件がある場合には、上記と同様である。

「セルラ通信（ＤＬ）＝直接通信（ＨｉｇｈＰｒｉｏｐｒｉｔｙ）＝直接通信（ＬｏｗＰｒｉｏｐｒｉｔｙ）」の条件がある場合には、受信ＵＥが希望するキャリアを選択できるため、少なくとも１つ以上の受信チェインが必要である。

受信ＵＥがセルのカバレッジ外に位置する場合には、直接通信（ＨｉｇｈＰｒｉｏｐｒｉｔｙ）のための受信チェインと、直接通信（ＬｏｗＰｒｉｏｐｒｉｔｙ）のための受信チェインと、の合計２つの受信チェインが、受信ＵＥは必要である。

第２に、１つのキャリアに複数の優先度が関連付けられているケースについて説明する。１つのキャリアに直接通信用の１以上のリソースプールが設けられるケースである。直接通信用のリソースプールが設けられたキャリアの数をＮと仮定する。

「セルラ通信（ＤＬ）＞直接通信」の条件がある場合、セルラ通信（ＤＬ）のための受信チェインと、直接通信用のリソースプールが設定された各キャリアのための受信チェインとが受信ＵＥは必要である。すなわち、受信ＵＥは、「１＋Ｎ」の受信チェインが必要である。

「セルラ通信（ＤＬ）＝直接通信」の条件がある場合、直接通信用のリソースプールが設定された各キャリアのための受信チェインが受信ＵＥは少なくとも必要である。すなわち、受信ＵＥは、Ｎ以上の受信チェインが必要である。

また、ＵＥ１００−２は、キャリアに対応付けられた優先度及び受信チェイン数に基づいて、モニタを行ってもよい。例えば、ＵＥ１００−２は、受信チェイン数が１つである場合、優先度が高いキャリアをモニタする。また、ＵＥ１００−２は、キャリアＡとキャリアＢとが同じ優先度であり、キャリアＣの優先度がキャリアＡ及びキャリアＢよりも低い場合、キャリアＡ又はキャリアＢの一方をモニタし、キャリアＣのモニタは行わなくてもよい。

［第１０実施形態］
次に、第１０実施形態について、説明する。上述の各実施形態の少なくともいずれかと同様の内容は説明を省略する。

（動作環境）
第１０実施形態に係る動作環境について、図４２及び図５１を用いて説明する。図５１は、第１０実施形態に係る動作環境を説明するための図である。

図５１に示すように、ＵＥ１００−１は、ｅＮＢ２００が管理するセル内に位置し、ｅＮＢ２００とセルラ通信（ＬＴＥ−Ｕｕ）を実行可能である。ＵＥ１００−１は、ＲＲＣコネクティッド状態である。或いは、ＵＥ１００−１は、ＲＲＣアイドル状態である。ＵＥ１００−１は、ｅＮＢ２００と通信を行う場合に、ＲＲＣアイドル状態からＲＲＣコネクティッド状態に移行してもよい。

ＵＥ１００−２は、ｅＮＢ２００が管理するセル外に位置する。ＵＥ１００−２は、リモートＵＥであってもよい。ＵＥ１００−１は、リモートＵＥをサーブするリレーＵＥであってもよい。

ＵＥ１００−１及びＵＥ１００−２は、直接通信を実行中の状態又は、直接通信の実行を開始する前の状態である。ＵＥ１００−１及びＵＥ１００−２は、図４２に示すリソースプールを用いて、直接通信を行うことができる。

（第１０実施形態に係る動作）
第１０実施形態に係る動作について、図５２及び図５３を用いて説明する。図５２は、実施形態に係る動作を説明するためのシーケンス図である。図５３は、実施形態に係る動作を説明するための図である。

図５２に示すように、ステップＳ１２１０において、ｅＮＢ２００は、論理チャネルに関する識別情報（例えば、論理チャネルグループの識別子（ＬＣＧＩＤ））の優先度に関する情報をＵＥ１００−１に通知する。ｅＮＢ２００は、優先度とＬＣＧＩＤとの関連付けを示す優先リストをＵＥ１００−１に通知してもよい。例えば、リストでは、優先度０（例えば、Ｌｏｗｐｒｉｏｒｉｔｙ）とＬＣＧＩＤ♯１とが関連付けられ、優先度１（例えば、Ｈｉｇｈｐｒｉｏｒｉｔｙ）とＬＣＧＩＤ♯２とが関連付けられている。なお、論理チャネルに関する識別情報は、論理チャネルの識別子（ＬＣＩＤ）であってもよい。従って、ＬＣＩＤと優先度とが関連付けられていてもよい。

ｅＮＢ２００は、優先度に関する情報（以下、優先リスト）を、ブロードキャスト（例えば、ＳＩＢ）によりＵＥ１００−１に通知してもよいし、ユニキャスト（例えば、ＲＲＣ再設定メッセージ）によりＵＥ１００−１に通知してもよい。

ＵＥ１００−１は、受信した優先リストに基づいて、優先度とＬＣＧＩＤとの関連づけを把握する。

ｅＮＢ２００は、ＵＥ１００−１及びＵＥ１００−２が直接通信を行う前に、制御リソースプールを設定するための設定情報をＵＥ１００−１に送信する。これにより、ｅＮＢ２００は、ＵＥ１００−１に制御リソースプールの設定を行う。ＵＥ１００−１には、設定情報に基づいて、制御リソースプールが設定される。ＵＥ１００−１は、設定された制御リソースプールを用いて、ＵＥ１００−２と直接通信を行う。具体的には、ＵＥ１００−１は、直接通信において、設定された制御リソースプール内の制御リソースを自律的に選択する。或いは、ＵＥ１００−１は、設定された制御リソースプール内の制御リソースをｅＮＢ２００から割り当てられてもよい。

また、ｅＮＢ２００は、データリソースプールを設定するための設定情報をＵＥ１００−１に送信する。これにより、ｅＮＢ２００は、ＵＥ１００−１にデータリソースプールの設定を行う。ＵＥ１００−１には、設定情報に基づいて、データリソースプールが設定される。ＵＥ１００−１は、設定されたデータリソースプールを用いて、ＵＥ１００−２と直接通信を行う。本実施形態では、ＵＥ１００−１は、直接通信において、設定された制御リソースプールからデータリソースを自律的に選択する。ＵＥ１００−１は、データリソースプールが設定されているため、後述するように優先度が高いデータが発生しない限り、ｅＮＢ２００からデータリソースが割り当てられない。

一方、ＵＥ１００−２は、セルのカバレッジ外に位置するため、予め設定された制御及びデータリソースプールを用いて、ＵＥ１００−１と直接通信を行う。ＵＥ１００−２は、ｅＮＢ２００のセル内に位置していた時に、ＵＥ１００−２（例えば、ＵＳＩＭ（ＵｎｉｖｅｒｓａｌＳｕｂｓｃｒｉｂｅｒＩｄｅｎｔｉｔｙＭｏｄｕｌｅ））に制御及びデータリソースプールが予め設定されていない場合に、制御及びデータリソースプールの設定情報を受信し、当該設定情報に基づいて、制御及びデータリソースプールを予め設定していてもよい。ＵＥ１００−２は、直接通信において、予め設定された制御及びデータリソースプール内の無線リソース（制御リソース及びデータリソース）を自律的に選択する。

ステップＳ１２２０において、ＵＥ１００−１内で、優先度が高いデータ（以下、高優先データ）が発生する。ＵＥ１００−１は、優先度の高いＬＣＧに属する論理チャネル（又は対応するベアラ）上にデータが発生した場合に、高優先データが発生したと認識してもよい。ＵＥ１００−１は、高優先データが発生した場合、近傍サービスにおけるバッファ状態報告（ＳＬ−ＢＳＲ：ＳｉｄｅｌｉｎｋＢｕｆｆｅｒＳｔａｔｕｓＲｅｐｏｒｔ）を作成する。ＳＬ−ＢＳＲの内容については後述する（ステップＳ１２４０参照）。

なお、高優先データは、高優先（Ｈｉｇｈｐｒｉｏｒｉｔｙ）を有するデータでなくてもよい。高優先データは、ＵＥ１００−１が制御リソースプール内の制御リソースを用いて送信するデータ（例えば、Ｌｏｗｐｒｉｏｒｉｔｙ）よりも優先度が高いデータ（Ｍｉｄｄｌｅｐｒｉｏｒｉｔｙ）であればよい。

ステップＳ１２３０において、ＵＥ１００−１は、宛先リストをｅＮＢ２００に送信する。宛先リストは、直接通信の相手を示す宛先識別子（ＤｅｓｔｉｎａｔｉｏｎＩＤ）を含む。例えば、ＵＥ１００−１は、宛先リストをＳＬＵＥＩｎｆｏｒｍａｔｉｏｎメッセージにより送信できる。

なお、ＵＥ１００−１は、高優先データが発生する前に、宛先リストをｅＮＢ２００に送信していてもよい。例えば、ＵＥ１００−１は、宛先リストに変更がある場合に、高優先データが発生する前に、宛先リストをｅＮＢ２００に送信していてもよい。また、ＵＥ１００−１は、ｅＮＢ２００が直接通信の相手を知っている場合には、ステップＳ１２３０を省略してもよい。

ステップＳ１２４０において、ＵＥ１００−１は、近傍サービスにおけるバッファ状態報告（ＳＬ−ＢＳＲ）を、高優先データが発生したことを示す情報として、ｅＮＢ２００に通知する。ＳＬ−ＢＳＲは、直接通信用のバッファ状態報告である。ＳＬ−ＢＳＲは、高優先データのバッファ量を示す情報を含む。ＵＥ１００−１は、優先度を考慮して、ＳＬ−ＢＳＲをｅＮＢ２００に送信する。

例えば、ＵＥ１００−１は、高優先データが発生した場合に、ＳＬ−ＢＳＲを最優先にｅＮＢ２００に送信してもよい。ＵＥ１００−１は、高優先データに関するＳＬ−ＢＳＲをセルラ通信におけるバッファ状態報告（ＣｅｌｌｕｌａｒＢＳＲ（ＢｕｆｆｅｒＳｔａｔｕｓＲｅｐｏｒｔ））よりも優先的に送信してもよい。従って、ＵＥ１００−１は、高優先データのバッファ量（データ量）を含むＳＬ−ＢＳＲを、セルラ通信用のＢＳＲ及び高優先データではなく直接通信により送信される通常データのバッファ量（データ量）を含むＳＬ−ＢＳＲよりも優先的にｅＮＢ２００に送信してもよい。また、ＵＥ１００−１は、高優先データが公衆安全のためのデータである場合には、最優先にｅＮＢ２００に送信してもよい。

ＵＥ１００−１は、宛先識別子のインデックスと、ＬＣＧＩＤと、ＬＣＧＩＤとに対応付けられたバッファ量とをＳＬ−ＢＳＲに含める。ここで、ＵＥ１００−１は、ｅＮＢ２００から受信した優先リストに基づいて、ＳＬ−ＢＳＲに含めるＬＣＧＩＤを決定する。具体的には、ＵＥ１００−１は、高優先データの優先度に対応する優先度を有するＬＣＧＩＤをＳＬ−ＢＳＲに含めるＬＣＧＩＤとして決定する。また、ＵＥ１００−１は、決定されたＬＣＧＩＤに対応するバッファ量として、高優先データのデータ量をＳＬ−ＢＳＲに含める。

例えば、ＵＥ１００−１は、優先度１と関連付けられたＬＣＧＩＤ♯１ではなく、優先度２と関連付けられたＬＣＧＩＤ♯２をＳＬ−ＢＳＲに含めるＬＣＧＩＤとして決定する。

一方、ｅＮＢ２００は、ＳＬ−ＢＳＲをＵＥ１００−１から受信する。ｅＮＢ２００は、宛先リスト及びＳＬ−ＢＳＲに基づいて、高優先データのための無線リソースを割り当てる。具体的には、ｅＮＢ２００は、宛先リストに含まれる宛先のうち、ＳＬ−ＢＳＲに含まれる宛先識別子のインデックスに対応する宛先（ＵＥ１００−２）に高優先データをＵＥ１００−１が送信するために、無線リソースを割り当てる。

ｅＮＢ２００は、ＳＬ−ＢＳＲに含まれるＬＣＧＩＤに基づいて、ＵＥ１００−１から受信したＳＬ−ＢＳＲが、高優先データの発生を示す情報であるか否かを判断する。具体的には、ｅＮＢ２００は、ＳＬ−ＢＳＲが、高優先データの優先度に対応する優先度を有するＬＣＧＩＤを含むか否かを判断する。ｅＮＢ２００は、優先度が高いＬＣＧＩＤ（ＬＣＧＩＤ♯２）を含む場合、ＳＬ−ＢＳＲが高優先データの発生を示す情報である（すなわち、ＵＥ１００−１において高優先データが発生した）と判断する。一方、ｅＮＢ２００は、優先度が低いＬＣＧＩＤ（ＬＣＧＩＤ♯１）を含む場合、ＳＬ−ＢＳＲが高優先データの発生を示す情報でない（すなわち、ＵＥ１００−１において高優先データが発生していない）と判断する。

なお、ｅＮＢ２００は、ＵＥ１００−１が自律的にＳＣＩ用及びデータ用の無線リソースを選択しているにもかかわらず、ＵＥ１００−１からＳＬ−ＢＳＲを受信した場合に、ＳＬ−ＢＳＲが高優先データの発生を示す情報であると判断してもよい。

ｅＮＢ２００は、ＵＥ１００−１から高優先データの発生を示す情報（ＳＬ−ＢＳＲ）を受信した場合に、高優先データのための無線リソースを割り当てる。具体的には、ｅＮＢ２００は、高優先データが発生した後に配置される制御リソースプールよりも時間的に前に位置する無線リソースを、高優先データのための無線リソースとしてＵＥ１００−１に割り当てる。例えば、ｅＮＢ２００は、ＵＥ１００−１に設定したデータリソースプールの外に位置し、かつ、前記高優先データが発生した後にＵＥ１００−１が選択可能な無線リソースよりも時間的に前に位置する無線リソースを、高優先データのための無線リソースとしてＵＥ１００−１に割り当てる。図５３に示すように、本実施形態では、ｅＮＢ２００は、高優先データのための無線リソースとして、ＳＣＩ用の制御リソースとデータ用のデータリソースを割り当てる。

ｅＮＢ２００は、周波数方向において、直接通信用の無線リソースプール（制御リソースプール及びデータリソースプール）と異なる周波数を有する無線リソースをＵＥ１００−１に割り当てる。ｅＮＢ２００は、セルラ通信用の無線リソースをＵＥ１００に割り当ててもよい。ｅＮＢ２００は、セルラ通信用の無線リソースのスケジューリングに基づいて、セルラ通信に干渉を与えない無線リソース（セルラ通信用の無線リソースのうちセルラＵＥに割り当てていない無線リソース）をＵＥ１００に割り当てることができる。なお、ｅＮＢ２００は、他のＵＥが実行する直接通信に干渉を与えないために、データリソースプール内に位置しない無線リソースをＵＥ１００−１に割り当てる。

また、ｅＮＢ２００は、時間方向において、高優先データが発生した後にＵＥ１００−１が選択可能な無線リソース（図５３におけるＰＳＳＣＨ♯２内のデータリソース）よりも前に位置する無線リソースをＵＥ１００−１に割り当てる。具体的には、ｅＮＢ２００は、ＳＣ期間♯２よりも前のＳＣ期間♯１（ＰＳＳＣＨ♯１の期間）の無線リソースをＵＥ１００−１に割り当てる。これにより、ＵＥ１００−１は、ｅＮＢ２００から割り当てられた無線リソースを用いて、ＳＣ期間♯２よりも前に高優先データをＵＥ１００−２に送信できる。

また、ｅＮＢ２００は、ＵＥ１００−１にデータリソースプール内に位置しない無線リソースを割り当てる場合、サイドリンク用の無線リソースと同様の配置で無線リソースを割り当ててもよい。具体的には、ｅＮＢ２００は、時間方向に２リソースブロック（ＲＢ）であるＰＳＣＣＨ用の制御リソースを割り当ててもよい。また、ｅＮＢ２００は、データが時間方向に４回繰り返し送信されるように、ＰＳＳＣＨ用のデータリソースを割り当ててもよい。

このように、ＵＥ１００−１は、データリソースプール内でデータリソースを自律的に選択しているにもかかわらず、高優先データが発生した場合には、高優先データが発生したことを示す情報（ＳＬ−ＢＳＲ）をｅＮＢ２００に送信する。

ステップＳ１２５０において、ｅＮＢ２００は、高優先データのために割り当てた無線リソースの割当情報をＵＥ１００−２に通知する。ＵＥ１００−１は、無線リソースの割当情報を受信する。これにより、ＵＥ１００−１は、高優先データのための無線リソースが割り当てられる。

ｅＮＢ２００は、ＤＣＩに基づいて、無線リソースの割当情報をＵＥ１００−１に通知できる。ｅＮＢ２００は、高優先データのために割り当てた無線リースであることを示すフラグ情報（例えば、緊急フラグ）と共に無線リソースの割当情報を、上りリンク制御情報を割り当てるためのＤＣＩ（ＤＣＩフォーマット０）により、ＵＥ１００−１に通知してもよい。ＵＥ１００−１は、フラグ情報に基づいて、受信した無線リソースの割当情報が高優先データを送信するための無線リソースの割当情報であると把握できる。

ステップＳ１２６０において、ＵＥ１００−１は、高優先データを受信するための動作（受信動作）のトリガとなる受信要求情報をＵＥ１００−２に通知する。ＵＥ１００−１は、ｅＮＢ２００から割当情報を受信した後に、受信要求情報をＵＥ１００−２に通知できる。例えば、ＵＥ１００−１は、割当情報を受信してから所定時間後にＵＥ１００−２に通知する。所定時間は、タイミングオフセット情報（Ｔｉｍｉｎｇｏｆｆｓｅｔ）として無線リソースの割当情報と共にｅＮＢ２００からＵＥ１００−１に通知されてもよい。所定時間は、予め規定されたタイミング（固定タイミング）であってもよい。例えば、ｅＮＢ２００は、ＵＥ１００−１が受信要求情報をＵＥ１００−２に通知可能なタイミングを把握している場合、当該タイミングから所定時間（例えば、４サブフレーム）前に割当情報を通知してもよい。ｅＮＢ２００は、無線リソースの割当情報を受信した後に受信要求情報を通知するための複数の無線リソースをＵＥ１００−１に通知してもよい。ＵＥ１００−１は、複数の無線リソースの少なくともいずれかを用いて、受信要求情報をＵＥ１００−２に通知できる。なお、ＵＥ１００−１は、無線リソースの割当情報を受信する前に、受信要求情報をＵＥ１００−２に通知してもよい。

ＵＥ１００−２は、例えば、下記に示すように、システム及び同期に関する情報を運搬する物理サイドリンクブロードキャストチャネル（ＰＳＢＣＨ：ＰｈｙｓｉｃａｌＳｉｄｅｌｉｎｋＢｒｏａｄｃａｓｔＣＨａｎｎｅｌ）、近傍サービスにおける同期信号（ＳｙｎｃｈｒｏｎｉｚａｔｉｏｎＳｉｇｎａｌ）、及び、近傍サービスにおけるディスカバリ信号、の少なくともいずれかに基づいて、受信要求情報をＵＥ１００−２に通知できる。

ＵＥ１００−１は、例えば、受信要求情報を示すフラグ情報をＰＢＳＣＨに含めてもよい。例えば、ＵＥ１００−２は、ＰＢＳＣＨに含まれるフラグ情報（１ビット）に基づいて、受信動作を行う。ＵＥ１００−２は、例えば、フラグ情報が「０」を示す場合、フラグ情報を受信要求情報とみなし、受信動作を行う。一方、ＵＥ１００−２は、フラグ情報が「１」を示す場合、受信動作を行わない。

ＵＥ１００−２は、通常の同期信号に含まれる識別情報（ＳＬＳＳＩＤ）とは別の緊急用の識別情報（ＳＬＳＳＩＤ）を同期信号に含めてもよい。例えば、通常の同期信号の識別情報（０−３３５）に加えて、緊急用の識別情報（３３６−５１１）を設ける。ＵＥ１００−１は、緊急用の識別情報を含む同期信号を送信する。ＵＥ１００−２は、緊急用の識別情報を含む同期信号を受信した場合に、受信動作を行う。

ＵＥ１００−１は、同期信号の送信時間に関する２つのオフセットのうち、ｅＮＢ２００からの指示によりセル内で用いられるオフセットと異なるオフセットを用いて、同期信号を送信してもよい。ＵＥ１００−２は、これまで受信していた同期信号に用いられていたオフセットと異なるオフセットが用いられた同期信号を受信した場合に、受信動作を行う。或いは、ＵＥ１００−２は、ｅＮＢ２００から指示されているオフセットと異なるオフセットが用いられた同期信号を受信した場合に、受信動作を行う。

ＵＥ１００−１は、高優先データが発生したＳＣ期間内で、ディスカバリ信号を送信できる場合は、受信要求情報を含むディスカバリ信号を送信してもよい。例えば、ディスカバリ信号の送信期間の周期がＳＣ期間（周期）よりも短い場合、ＵＥ１００−１は、ディスカバリ信号を送信できる。また、ディスカバリ信号の送信期間が、データリソースの期間と時間方向において重複する場合、ＵＥ１００−１は、ディスカバリ信号を送信できる。例えば、「（Ｄｉｓｃｏｖｅｒｙｏｆｆｓｅｔ）＝（Ｃｏｍｍｕｎｉｃａｔｉｏｎｏｆｆｓｅｔ）＋（ＣｏｍｍｕｎｉｃａｔｉｏｎＰｅｒｉｏｄ／２）」かつ「（ＤｉｓｃｏｖｅｒｙＰｅｒｉｏｄ）＝（ＣｏｍｍｕｎｉｃａｔｉｏｎＰｅｒｉｏｄ）」を満たす場合、ＵＥ１００−１は、ディスカバリ信号を送信できる。なお、Ｄｉｓｃｏｖｅｒｙｏｆｆｓｅｔは、ディスカバリ信号の送信期間の基準値からのオフセット値を示す。Ｃｏｍｍｕｎｉｃａｔｉｏｎｏｆｆｓｅｔは、ＳＣ期間の基準値からのオフセット値を示す。ＣｏｍｍｕｎｉｃａｔｉｏｎＰｅｒｉｏｄは、ＳＣ期間を示す。

ステップＳ１２７０において、ＵＥ１００−２は、受信要求情報の受信に応じて、高優先データを受信するための受信動作を開始する。ＵＥ１００−２は、所定の周波数帯（キャリア）の全てをＰＳＣＣＨ領域とみなして、受信動作（モニタ）を行う。所定の周波数帯は、予め設定された固定値であってもよい。或いは、受信要求情報に所定の周波数帯を示す情報が含まれていてもよい。ＵＥ１００−２は、ｅＮＢ２００のセル内に位置する場合に、ブロードキャスト（例えば、ＳＩＢ）又はユニキャスト（例えば、ＲＲＣ再設定メッセージ）によりｅＮＢ２００から所定の周波数帯を示す情報を受信していてもよい。

ＵＥ１００−２は、受信要求情報を受信してから所定時間経過するまで、受信動作を行ってもよい。ＵＥ１００−２は、受信要求情報を受信してから受信動作の停止を要求する停止情報をＵＥ１００−１から受信するまで、受信動作を行ってもよい。或いは、ＵＥ１００−２は、指定された個数の情報（パケット）を受信するまで、受信動作を行ってもよい。ＵＥ１００−２は、ＵＥ１００−１からＳＣＩ及び／又はデータを受信するまで、受信動作を行ってもよい。ＵＥ１００−２は、受信動作に関する情報（いずれの受信動作を実行するかの情報など）をｅＮＢ２００は、ブロードキャスト（例えば、ＳＩＢ）又はユニキャスト（例えば、ＲＲＣ再設定メッセージ）によりｅＮＢ２００から受信してもよい。或いは、受信要求情報に受信動作に関する情報が含まれていてもよい。或いは、ＵＥ１００−２は、予め設定された情報（固定）に基づいて、受信動作を実行してもよい。

ステップＳ１２８０において、ＵＥ１００−１は、ｅＮＢ２００からの無線リソースの割当情報に基づいて、高優先データを送信するためのデータリソースを通知するためのＳＣＩを送信する。なお、本実施形態において、ｅＮＢ２００からの無線リソースの割当情報は、高優先データを送信するためのデータリソースだけでなく、ＳＣＩを送信するための制御リソースを含む。

ＵＥ１００−２は、受信したＳＣＩに基づいて、高優先データの送信に用いられるデータリソースを把握する。ＵＥ１００−２は、ＳＣＩ及び／又はデータを受信した場合、受信動作を終了する。

ステップＳ１２９０において、ＵＥ１００−１は、ｅＮＢ２００からの無線リソースの割当情報に基づいて、高優先データを送信する。ＵＥ１００−２は、ＳＣＩに含まれるデータリソースに基づいて、高優先データを受信する。

ここで、ＵＥ１００−１は、高優先データよりも優先度が低い通常データを送信している場合、通常データよりも高優先データを優先的に送信する。ＵＥ１００−１は、切りが良いところで通常データの送信を中断し、高優先データの送信を開始してもよい。例えば、ＵＥ１００−１は、通常データに対応するに対応するパケットの再送（４回繰り返し送信）が完了していない場合、パケットの再送が完了してから、高優先データの送信を開始してもよい。

或いは、ＵＥ１００−１は、通常データの送信をすぐに中断し、高優先データの送信を開始してもよい。例えば、ＵＥ１００−１は、通常データのパケットの再送が完了していない場合であっても、高優先データの送信を開始してもよい。この場合、ＵＥ１００−１は、通常データの送信を中断した旨をＵＥ１００−２に通知してもよい。これにより、ＵＥ１００−２は、途中まで受信した通常データを破棄せずに保持する。ＵＥ１００−２は、通常データの送信を中断した旨をＵＥ１００−１から受信しない場合には、途中まで受信した通常データを破棄してもよい。ＵＥ１００−１は、再送が完了していない場合には、高優先データの送信が完了した後に、再送を開始してもよい。ＵＥ１００−１は、通常データの送信を中断した旨をＵＥ１００−２に通知していない場合、再送が完了していないパケットを新たなパケットとして送信してもよい。

なお、ＵＥ１００−１は、ｅＮＢ２００からの指示に基づいて、高優先データを送信する前に通常データのパケットの再送を完了するか否かを判断してもよい。例えば、ｅＮＢ２００は、無線リソースの割当情報を含むＤＣＩに中断フラグ情報（Ｉｎｔｅｒｒｕｐｔｆｌａｇ）を含めてもよい。中断フラグ情報が「Ｔｒｕｅ」を示す場合、ＵＥ１００−１は、パケットの再送を完了しなくても、高優先データを送信する。一方、中断フラグ情報が「Ｆａｌｓｅ」を示す場合、ＵＥ１００−１は、パケットの再送が完了した後に、高優先データを送信する。なお、ＤＣＩに、ＲｅｓｕｍｅＴｉｍｉｎｇ及び／又はＲｅｓｕｍｅＰｅｒｉｏｄの情報が含まれていてもよい。

なお、ＵＥ１００−１は、１つのキャリア内でマルチクラスタ送信が許可されている場合には、データリソースプール内のデータリソースを用いて未送信のパケットを送信しつつ、高優先データを送信してもよい。

以上によれば、ＵＥ１００−１は、高優先データが発生した場合、高優先データが発生したＳＣ期間内で高優先データを送信可能である。これにより、ＵＥ１００−１は、直接通信により適切にデータを送信可能である。また、ｅＮＢ２００が、直接通信用の無線リソースプール内に位置しない無線リソースを割り当てるため、セルラ通信及び直接通信に干渉を与えることを抑制できる。

［その他の実施形態］
上述において、ＵＥ１００−１がリレーＵＥであり、ＵＥ１００−２〜１００−４がリモートＵＥであるケースを説明したが、これに限られない。リレーＵＥでないＵＥ１００−１が、複数のＵＥ１００のそれぞれにデータを送信するケース（例えば、図７参照）に、上述の各実施形態の内容が適用されてもよい。

上述した第１実施形態の「（Ａ２）第２の方法」において、上述の第３実施形態で説明したように、ＳＬグラント（ＤＣＩ）の通知タイミングによってインデックスが指定されてもよい。このように、上述した第１から第３実施形態の各動作は、適宜組み合わせて実行可能である。

上述において、複数のＳＣＩの割り当てを時間方向で衝突しないように割り当てを選択している形態を説明した。以下において、複数のＳＣＩを周波数方向で連続的な無線リソース（ＰＲＢ：物理リソースブロック）で送信する場合について、記述する。

複数のＳＣＩを周波数方向に連続的なＰＲＢで送信する場合、受信ＵＥがいくつのＳＣＩが連続ＰＲＢで送信されているかを知る必要がある。なお、現状では、１ＰＲＢで割り当てが行われる前提下で、受信ＵＥは受信処理を行う。

第１の方法としては、受信ＵＥ側が複数のパターンを想定し、想定されるパターン数の受信処理を行う方法がある。受信ＵＥは、想定されるパターン数の受信処理を行うことで、周波数方向に連続する複数のＳＣＩを受信することが出来る。

パターン数によっては、処理量が膨大になる可能性があるため、パターン数を極力減らすことが好ましい。パターン数を減らす方法としては、ＳＣＩの周波数方向連続ＰＲＢ割り当て数を限定し、及び／又は、割り当て領域を限定する方法がある。例えば、ＳＣＩ連続割り当て数を１、２、３に限定し、割り当て領域を図５４のように限定する。図５４に示すように、ＳＣＩ連続割当数が大きいほど、割り当て領域が小さくなる。

第２の方法としては、ＳＣＩを送信するためのリソースプールに、周波数方向に連続して割り当てられるＰＲＢの数（以下、連続ＰＢＲ数）を紐付けることによって、連続ＰＢＲ数を固定する方法がある。送信ＵＥは、リソースプールに紐付けられた固定数（連続ＰＢＲ数）を満たすように、周波数方向に連続するＰＲＢを用いて、複数のＳＣＩを送る。受信ＵＥは、リソースプールに紐付けられた固定数（連続ＰＢＲ数）の数に対応する複数のＳＣＩが、周波数方向に連続するＰＢＲを用いて送られてくることを想定して、受信処理を行う。

ここで、リソースプールに紐付けられた固定数と、送りたいＳＣＩ数が違った場合、送信ＵＥが、送りたいＳＣＩの数と固定数とを合わせるために、無駄な情報を入れなければいけない可能性がある。

このような場合、送信ＵＥは、他のＳＣ−Ｐｅｒｉｏｄを指定した新たなＳＣＩを送る方法が考えられる。図５５に示すように、他のＳＣ−Ｐｅｒｉｏｄ又は他のリソースプールを指定することで、効率的なリソース利用が可能になる。

図５６には、他のＳＣ−Ｐｅｒｉｏｄを指定するＳＣＩ送信フォーマットを記述する。「ｐｅｒｉｏｄＩｎｄｉｃａｔｏｒＦｉｅｌｄ」がＳＣ−Ｐｅｒｉｏｄを指定するパラメータである。このＳＣＩが、送られているＳＣ−Ｐｅｒｉｏｄからの差分である。

図５７には、新たなリソースプールコンフィグパラメータを記述する。ｎｕｍＭｕｌｐｌｅＳＣＩｓが周波数方向連続ＰＲＢで送信するＳＣＩ数である。

第３の方法としては、ＯＦＤＭ信号を用いて送信を行う方法がある。ＳｉｎｇｌｅＣａｒｒｉｅｒ送信にあった制限はなくなるため、周波数方向連続及び不連続ＰＲＢで送信が可能になる。

第４の方法としては、複数クラスタ送信を行う方法がある。ＳｉｎｇｌｅＣａｒｒｉｅｒ送信にあった制限はなくなり、周波数方向連続及び不連続ＰＲＢで送信が可能になる。なお、複数クラスタ送信とは、周波数方向に連続したＰＢＲの割り当てを１クラスタとし、そのクラスタを同タイミングで複数送信する方法である。

上記の第１から第４の方法は、複数を組み合わせて実施されてもよい。

複数のＳＣＩを周波数方向で連続的なＰＲＢで送信できる場合、図５８に示すように、送信ＵＥは、複数の宛先（Ｄｅｓｔｉｎａｔｉｏｎ１〜４）のそれぞれにデータを送信するための複数の無線リソースが周波数方向に連続的にするように、データ送信用の複数の無線リソースを選択できる。図５９に示すように、周波数方向に連続的なＰＲＢでデータを送信する場合、送信されるデータは、周波数方向に連続的なＰＲＢで送られる複数のＳＣＩから選択される。受信ＵＥは、受信した複数のＳＣＩから周波数方向に連続的なＰＲＢに割り当てられるデータ領域の情報を取得し、受信処理を行う。受信ＵＥは、受信処理を行ったデータにおいて、自身のＤｅｓｔｉｎａｔｉｏｎＩＤ宛てのデータ以外のデータを破棄する。

上述した第７実施形態の変更例１，２では、ＵＥ１００−１が候補端末の宛先識別子を候補端末に予め通知するケースを説明したが、これに限られない。例えば、ＵＥ１００−３は、自身が候補端末であると認識している場合には、ＳＣＩに自身の宛先識別子が含まれない場合であっても、ＳＣＩに含まれる割当情報に基づいて、パケットを受信してもよい。なお、ＵＥ１００−３は、例えば、公衆安全のためのＵＥである場合に、自身が候補端末であると認識する。また、ＵＥ１００−３は、（アプリケーションレベルで認識可能な）重要なＵＥである場合、ＵＥ１００−１から所定時間パケットを受信していない場合、及び、ＵＥ１００−１から所定時間内にパケットを受信している場合の少なくともいずれかの場合に、自身が候補端末であると認識してもよい。ＵＥ１００−３は、最後にパケットを受信してから所定時間測定するためのタイマを保持していてもよい。

上述において、ＵＥ１００−１内で高優先データが発生していたが、これに限られない。ネットワーク側で高優先データが発生した場合に、上述の動作が実行されてもよい。例えば、リモートＵＥであるＵＥ１００−２へ送信すべき高優先データがネットワーク側で発生したケースにおいて、上述の動作が実行されてもよい。

上述した第９実施形態では、セルラ通信と直接通信との間に優先関係があるケースを説明したが、これに限られない。例えば、セルラ通信と直接通信と直接ディスカバリとの間に優先関係があるケースにおいても、ＵＥ１００及びｅＮＢ２００は、上述と同様の動作を実行してもよい。

例えば、直接ディスカバリ用のリソースプールが設定されたキャリア（直接ディスカバリ用キャリア）だけでなく、直接ディスカバリ用のリソースプールが設定されたキャリア（直接通信用キャリア）に優先度が関連付けられている場合、ＵＥ１００−２は、キャリアに対応付けられた優先度（及び自身の受信チェイン数）に基づいて、モニタを行ってもよい。

また、ｅＮＢ２００は、直接ディスカバリ用キャリアも考慮して、第３優先度情報（キャリアと優先度との関連付け）を決定してもよい。例えば、ｅＮＢ２００は、「セルラ通信（ＤＬ）＞直接通信＞直接ディスカバリ」の条件がある場合に、直接ディスカバリ用キャリアの優先度が、直接通信用のキャリアの優先度を超えないように、各キャリアに優先度を付けたり、第３優先度情報を決定したり、ＵＥ１００に設定するキャリアを決定してもよい。

なお、ＵＥ１００及びｅＮＢ２００は、例えば、以下の条件のいずれかが規定されている場合にも、キャリア（及び／又はリソースプール）の優先度を考慮して、上述と同様の動作を実行してもよい。

・「直接通信＝直接ディスカバリ」
・「直接通信（ＨｉｇｈＰｒｉｏｐｒｉｔｙ）＞直接通信（ＬｏｗＰｒｉｏｐｒｉｔｙ）＞直接ディスカバリ」
・「直接通信（ＨｉｇｈＰｒｉｏｐｒｉｔｙ）＞直接通信（ＬｏｗＰｒｉｏｐｒｉｔｙ）＝直接ディスカバリ」
・「直接通信＞直接ディスカバリ（ＨｉｇｈＰｒｉｏｐｒｉｔｙ）＞直接ディスカバリ（ＬｏｗＰｒｉｏｐｒｉｔｙ）」
・「直接通信＝直接ディスカバリ（ＨｉｇｈＰｒｉｏｐｒｉｔｙ）＞直接ディスカバリ（ＬｏｗＰｒｉｏｐｒｉｔｙ）」
・「直接通信（ＨｉｇｈＰｒｉｏｐｒｉｔｙ）＞直接通信（ＬｏｗＰｒｉｏｐｒｉｔｙ）＞直接ディスカバリ（ＨｉｇｈＰｒｉｏｐｒｉｔｙ）＞直接ディスカバリ（ＬｏｗＰｒｉｏｐｒｉｔｙ）」
・「直接通信（ＨｉｇｈＰｒｉｏｐｒｉｔｙ）＞直接通信（ＬｏｗＰｒｉｏｐｒｉｔｙ）＝直接ディスカバリ（ＨｉｇｈＰｒｉｏｐｒｉｔｙ）＞直接ディスカバリ（ＬｏｗＰｒｉｏｐｒｉｔｙ）」
・「直接通信（ＨｉｇｈＰｒｉｏｐｒｉｔｙ）＞直接ディスカバリ（ＨｉｇｈＰｒｉｏｐｒｉｔｙ）＞直接通信（ＬｏｗＰｒｉｏｐｒｉｔｙ）＞直接ディスカバリ（ＬｏｗＰｒｉｏｐｒｉｔｙ）」

上述において、ＵＥ１００−１がセルのカバレッジ内に位置し、ＵＥ１００−２がセルのカバレッジ外に位置するケース（いわゆる、部分的カバレッジ（ＰａｒｔｉａｌＣｏｖｅｒａｇｅ））を想定していたが、これに限られない。ＵＥ１００−１及びＵＥ１００−２の両方がセルのカバレッジ内に位置するケースにおいて、上述の動作が実行されてもよい。

上述において、通常の優先度のデータを送信するために、ＵＥ１００−１が、設定されたリソースプールを用いて自律的に制御リソース及びデータリソースを選択していたが、ｅＮＢ２００が、直接通信用のリソースプールから、ＵＥ１００−１に制御リソース及びデータリソースを割り当ててもよい。ｅＮＢ２００は、高優先データが発生した場合に、例えば、次の制御リソースプールよりも時間的に前に位置し、かつ、直接通信用のリソースプールの外に位置する無線リソースをＵＥ１００−１に割り当てることができる。なお、ｅＮＢ２００が、制御リソース（及びデータリソース）を割り当てる場合であっても、制御リソースプールが時間方向に間隔をおいて配置されている場合には、高優先データの遅延が発生する可能性がある。従って、ｅＮＢ２００が、高優先データが発生した後に配置される制御リソースプールよりも時間的に前に位置する無線リソースをＵＥ１００−１に割り当てることは有効である。

また、ｅＮＢ２００は、直接通信用のデータリソースプール内に位置し、かつ、次の制御リソースプールよりも時間的に前に位置する無線リソースを制御情報用及びデータ通信用の無線リソースとしてＵＥ１００に割り当ててもよい。例えば、ｅＮＢ２００は、当該データリソースプールを用いて直接通信を行っているＵＥ数が少ない場合には、干渉が発生する可能性が低いため、直接通信用のデータリソースプール内に位置する無線リソースを高優先データのための無線リソースとしてＵＥ１００に割り当ててもよい。

上述において、ＵＥ１００−１内で高優先データが発生していたが、これに限られない。ネットワーク側で高優先データが発生した場合に、上述の動作が実行されてもよい。例えば、リモートＵＥであるＵＥ１００−２へ送信すべき高優先データがネットワーク側で発生したケースにおいて、上述の動作が実行されてもよい。この場合、ｅＮＢ２００は、ＵＥ１００−１から高優先データの発生を示す情報を受信せずに、ＵＥ１００−１に対して、高優先データのための無線リソースの割当情報を送信する。

上述において、ＵＥ１００−１は、高優先データの発生を示す情報として、ＳＬ−ＢＳＲをｅＮＢ２００に送信していたが、これに限られない。ＵＥ１００−１は、高優先データのための無線リソースの割り当て要求を（例えば、ＳＬＵＥＩｎｆｏｒｍａｔｉｏｎメッセージ）ｅＮＢ２００に送信してもよい。ｅＮＢ２００は、無線リソースの割り当て要求の受信に応じて、無線リソースの割当情報をＵＥ１００−１に送信してもよい。

上述において、ＵＥ１００−１は、高優先データの送信に用いられるデータリソースの位置を通知するためのＳＣＩを送信していたが、これに限られない。ＵＥ１００−１は、ＳＣＩを送信せずに、高優先データを送信してもよい。ＵＥ１００−１は、高優先データのためのＳＣＩに対応する情報を受信要求情報に含めてもよい。或いは、ＵＥ１００−１は、ｅＮＢ２００のセル内に位置する場合に、ブロードキャスト（例えば、ＳＩＢ）又はユニキャスト（例えば、ＲＲＣ再設定メッセージ）により高優先データのためのＳＣＩに対応する情報を受信してもよい。ＵＥ１００−２は、受信要求情報を受信した場合、ＳＣＩに対応する情報に基づいて、高優先データを受信するための動作を実行できる。また、ＵＥ１００−２は、予め設定された情報（固定）に基づいて、受信動作を実行してもよい。或いは、ＵＥ１００−２は、受信要求情報を受信した後、高優先データが送信され得る全ての無線リソース（データリソースプールに位置しない無線リソースを含む）をモニタしてもよい。ＵＥ１００−２は、受信要求情報を受信してから所定時間経過するまで、モニタを行ってもよい。ＵＥ１００−２は、受信要求情報を受信してから受信動作の停止を要求する停止情報をＵＥ１００−１から受信するまで、モニタを行ってもよい。或いは、ＵＥ１００−２は、指定された個数の情報（パケット）を受信するまで、モニタを行ってもよい。

上述した各実施形態では、移動通信システムの一例としてＬＴＥシステムを説明したが、ＬＴＥシステムに限定されるものではなく、ＬＴＥシステム以外のシステムに本発明を適用してもよい。

［付記］
この付記では、ＵＥ−ｔｏ−ネットワークリレーのためのＰｒｏＳｅ直接通信へのエンハンスメントを検討する。

（１）ＵＥ−ｔｏ−ネットワークリレーのレイテンシ要件
ＵＥ−ｔｏ−ネットワークリレーのユースケースの一つは、グループ通信サービスである。グループ通信サービス実現要因（ＧＣＳＥ：ＧｒｏｕｐＣｏｍｍｕｎｉｃａｔｉｏｎＳｅｒｖｉｃｅＥｎａｂｌｅｒ）は、以下に示すパフォーマンス要件を有する。ＵＥ−ｔｏ−ネットワークリレー動作は、ＧＣＳＥレイテンシ要件を満たすことが要求されるべきである。

・ＵＥが係属中のグループ通信へ参加するために要求したときから、グループ通信を受信する時間までの時間は、３００ｍｓ以下であるべきである。

・グループ通信のためのメデイアトランスポートに関する端末相互間遅延（ｅｎｄｔｏｅｎｄｄｅｌａｙ）は、１５０ｍｓ以下であるべきである。

ＧＣＳＥシステムは、並行して複数の異なるグループの通信をサポートすべきである。基本的に、１つのＵＥは、同時に１以上の異なるグループ通信セッションをサポートできなければならない。全てのグループは、ＧＣＳＥレイテンシ要件を満たすべきである。

見解１：ＵＥ−ｔｏ−ネットワークリレーレイテンシは、ＧＣＳＥレイテンシ要件を満たすべきである。

（２）ＵＥ−ｔｏ−ネットワークリレーのレイテンシ問題
ＵＥ−ｔｏ−ネットワークリレーを用いたときの端末相互間遅延が分析された。以下の表は、メディアデリバリーのためのユニキャストベアラを用いたときのメディアトランスポートに関する端末相互間遅延である（表１）。ピリオド１及び５は、Ｄ２Ｄリンクレイテンシの評価結果である。ＵＥ−ｔｏ−ネットワークリンクレイテンシは、最小一方向伝送を想定する。

現在のＲｅｌ−１２仕様は、１つのＳＣ期間内で１つのＳＣＩ送信に制限されている。モード１では、サイドリンクグラントが受信されたサブフレームの少なくとも４サブフレーム後にスタートする最初に利用可能なＳＣ期間の開始するサブフレームで生じ、設定（コンフィグ）されるべきサイドリンクグラントである受信したサイドリンクグラント（すなわち、ＤＣＩフォーマット５）は、同じＳＣ期間に生じて前に設定されたサイドリンクグラントを書き換える。モード２では、サイドリンクグラントは、上位レイヤにより設定（コンフィグ）されたリソースプールから選択される。

リレーＵＥは、複数のグループへ中継するためのトラフィックを有する場合、ＳＣ期間×（グループの数−１）の間、データ送信が遅延する（図６０参照）。その結果、４より多いグループがリレーＵＥの制御下である場合、いくつかのグループは、ＧＣＳＥレイテンシ要件を満たすことができない（５６ｍｓ×３＝１６８ｍｓ＞１５０ｍｓ）。

提案１：Ｒｅｌ−１３は、１つのＳＣ期間内で複数のＳＣＩ送信をサポートすべきである。

（３）ＵＥ−ｔｏ−ネットワークリレーに関するＤ２Ｄ通信へのエンハンスメント
考慮可能である複数のＳＣＩに関して、以下の３つのオプションが利用可能である。

・オプション１：ＳＣ期間内で異なる送信先グループそれぞれへの複数のＳＣＩ（図６１）
・オプション２：ＳＣ期間内で異なる送信先グループそれぞれへのデータリソースを示す１つのＳＣＩ（図６２）
・オプション３：複数の送信先グループのための複数のＴＸリソースプール（図６３）
これらのオプションに関して、モード１とモード２の両方を考察する。

（３．１）モード１の考察
（３．１．１）オプション１
ｅＮＢは、ＤＣＩフォーマット５で１つのＳＣＩＴＸリソースを示す。オプション１が適用される場合、複数のＰＳＣＣＨ及びＰＳＳＣＨリソースを示すためのエンハンスメントが必要である。

オプション１は、現在の仕様内の同じＳＣＩフォーマット０を用いることができるので、Ｒｅｌ−１２Ｄ２ＤＵＥへの影響なし。

（３．１．２）オプション２
ｅＮＢは、ＤＣＩフォーマット５で１つのＳＣＩＴＸリソースを示す。オプション２が適用される場合、複数のＰＳＣＣＨ及びＰＳＳＣＨリソースを示すためのエンハンスメントが必要である。ＳＣＩフォーマット０は、１つのＬ１−送信先ＩＤ（Ｌ１−ＤｅｓｔｉｎａｔｉｏｎＩＤ）を示す。オプション２が適用される場合、複数のＬ１−送信先ＩＤを示すためのエンハンスメントが必要である。

ＭＡＣＰＤＵ／ＬＣＩＤが、複数の送信先を示す場合、現在の仕様でＬ１−送信先ＩＤをフィルタするために、多重化されたグループは同じＬ１−送信先ＩＤのみ可能である。

オプション２は、新たなＳＣＩフォーマット／ＭＡＣＰＤＵ／ＬＣＩＤが必要なので、Ｒｅｌ−１２Ｄ２ＤＵＥに関して下位互換性なし。

（３．１．３）オプション３
ｅＮＢは、ＤＣＩフォーマット５で１つのＳＣＩＴＸリソースを示す。オプション３が適用される場合、各ＴＸリソースプールにおいて複数のＰＳＣＣＨ及びＰＳＳＣＨリソースを示すためのエンハンスメントが必要である。

ＵＥが新たな送信先を追加した場合、ｅＮＢは、新たなＴＸリソースプールを設定すべきである。

複数のＴＸリソースプールをモニタすることがＵＥに要求されるので、受信ＵＥ消費電力が増加する。

オプション３は、オプション１及びオプション２の両方と比較して、遅延の増加の可能性がある。

オプション３は、現在の仕様内の同じＳＣＩフォーマット０を用いることができるので、Ｒｅｌ−１２Ｄ２ＤＵＥへの影響なし。

（３．２）モード２の考察
（３．２．１）オプション１
ＵＥは、上位レイヤにより設定されたリソースプールからＳＣＩＴＸリソースをランダムに選択する。ランダム関数は、許可された選択のそれぞれが等しい確立で選ばれ得るようなものであるべきである。オプション１が適用される場合、時間領域でのリソース衝突を避けるために、リソース選択が制限される必要がある。

ＴＸリソースプールが複数のリレーＵＥで共有される場合、オプション１を用いる場合、リソース衝突の増加の可能性がある。

（３．２．２）オプション２
ＳＣＩフォーマット０は、１つのＬ１−送信先ＩＤを示す。オプション２が適用される場合、複数のＬ１−送信先ＩＤを示すためのエンハンスメントが必要である。

（３．２．３）オプション３
ＵＥが新たな送信先を追加した場合、ｅＮＢは、新たなＴＸリソースプールを設定すべきである。

上述の表は、考察結果の要約である（表２）。

上述の検討のように、標準化への影響及び下位互換性の観点から、オプション１が、オプション２及びオプション３の両方より好ましいと考える。

提案２：Ｒｅｌ−１３は、１つのＳＣ期間内で異なる送信先グループそれぞれへの複数のＳＣＩをサポートすべきである。

なお、米国仮出願第６２／１６２２５６号（２０１５年５月１５日出願）、日本国特許出願第２０１５−１０５８８１号（２０１５年５月２５日出願）、日本国特許出願第２０１５−１５００８１号（２０１５年７月２９日出願）、日本国特許出願第２０１５−１５０１７１号（２０１５年７月２９日出願）、及び、日本国特許出願第２０１５−１５０１７２号（２０１５年７月２９日出願）の全内容が、参照により、本願明細書に組み込まれている。

Claims

通信方法であって、
基地局から無線端末へ、前記無線端末が複数の周波数上において直接通信を行うための制御情報を送信するステップであって、前記制御情報は、前記複数の周波数のそれぞれに関連付けた前記直接通信用のリソースプールを示す情報を含む、ステップと、
前記無線端末が、前記制御情報に基づいて前記複数の周波数の中から第１周波数を選択するステップと、を備える通信方法。
前記無線端末が、前記第１周波数に関連付けた前記直接通信用のリソースプールを使用して前記直接通信におけるデータを他の無線端末に送信するステップと、更に備える請求項１に記載の通信方法。
前記無線端末が、前記データの優先度に関する情報を前記他の無線端末に送信するステップと、を更に備える請求項２に記載の通信方法。
基地局であって、
無線端末が複数の周波数上において直接通信を行うための制御情報を前記無線端末に対して送信する処理を実行する制御部を備え、
前記制御情報は、前記複数の周波数のそれぞれに関連付けた前記直接通信用のリソースプールを示す情報を含む基地局。
無線端末であって、
前記無線端末が複数の周波数上において直接通信を行うための制御情報を基地局から受信する処理を実行する制御部を備え、
前記制御情報は、前記複数の周波数のそれぞれに関連付けた前記直接通信用のリソースプールを示す情報を含み、
前記制御部は、前記制御情報に基づいて前記複数の周波数の中から第１周波数を選択する無線端末。
基地局を制御するプロセッサであって、
前記プロセッサは、無線端末が複数の周波数上において直接通信を行うための制御情報を前記無線端末に対して送信する処理を実行し、
前記制御情報は、前記複数の周波数のそれぞれに関連付けた前記直接通信用のリソースプールを示す情報を含むプロセッサ。
無線端末を制御するプロセッサであって、
前記プロセッサは、前記無線端末が複数の周波数上において直接通信を行うための制御情報を基地局から受信する処理を実行し、
前記制御情報は、前記複数の周波数のそれぞれに関連付けた前記直接通信用のリソースプールを示す情報を含み、
前記プロセッサは、前記制御情報に基づいて前記複数の周波数の中から第１周波数を選択する処理を実行するプロセッサ。