(57)【特許請求の範囲】
【請求項１】
Ｐｅｄｅｓｔｒｉａｎ  ＵＥ（Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ）であるユーザ装置であって、
他のユーザ装置との直接的な端末間通信であるＰ２Ｘ通信を実行するよう構成されたトランスミッタと、
リソースプールを示すメッセージを基地局から受信するよう構成されたレシーバと、
コントローラと、を備え、
前記コントローラは、前記ユーザ装置がＲａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ（ＲＲＣ）アイドル状態である場合、前記メッセージに前記Ｐ２Ｘ通信用のリソースプールが含まれていないことに応じて、前記Ｐ２Ｘ通信のための無線リソースを前記基地局へ要求するために、前記ＲＲＣアイドル状態からＲＲＣコネクティッド状態へ遷移する制御を開始するよう構成されるユーザ装置。
【請求項２】
前記コントローラは、前記メッセージが示す前記リソースプールの種別に応じて、前記Ｐ２Ｘ通信のために前記リソースプールが利用可能か否かを判定するように構成される請求項１に記載のユーザ装置。
【請求項３】
前記コントローラは、前記リソースプールの種別と前記ユーザ装置の能力とに応じて、前記リソースプールを利用可能な否かを判定するよう構成される請求項２に記載のユーザ装置。
【請求項４】
前記リソースプールが当該リソースプールを使用するためにセンシングが必要なリソースプールであることに応じて、前記コントローラは、前記リソースプールを利用可能であると判定するよう構成される請求項２に記載のユーザ装置。
【請求項５】
前記リソースプールが当該リソースプールを使用するためにセンシングが不要なリソースプールであり、
前記コントローラは、前記ユーザ装置が前記端末間通信における受信能力を有さないことに応じて、前記リソースプールを利用可能であると判定するよう構成される請求項２に記載のユーザ装置。
【請求項６】
前記コントローラは、前記無線リソースを要求するための第１メッセージに、前記ユーザ装置が前記Ｐｅｄｅｓｔｒｉａｎ  ＵＥであるか否かを示す情報を含めるよう構成され、
前記トランスミッタは、前記第１メッセージを前記基地局へ送信するよう構成される請求項１に記載のユーザ装置。
【請求項７】
Ｐｅｄｅｓｔｒｉａｎ  ＵＥ（Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ）であるユーザ装置を制御するプロセッサであって、
他のユーザ装置との直接的な端末間通信であるＰ２Ｘ通信を実行する処理と、
リソースプールを示すメッセージを基地局から受信する処理と、
前記ユーザ装置がＲａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ（ＲＲＣ）アイドル状態である場合、前記メッセージに前記Ｐ２Ｘ通信用のリソースプールが含まれていないことに応じて、前記Ｐ２Ｘ通信のための無線リソースを前記基地局へ要求するために、前記ＲＲＣアイドル状態からＲＲＣコネクティッド状態へ遷移する制御を開始する処理と、を実行するよう構成されるプロセッサ。
【請求項８】
移動通信制御方法であって、
Ｐｅｄｅｓｔｒｉａｎ  ＵＥ（Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ）であるユーザ装置が、他のユーザ装置との直接的な端末間通信であるＰ２Ｘ通信を実行し、
前記ユーザ装置が、リソースプールを示すメッセージを基地局から受信し、
前記ユーザ装置が、前記ユーザ装置がＲａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ（ＲＲＣ）アイドル状態である場合、前記メッセージに前記Ｐ２Ｘ通信用のリソースプールが含まれていないことに応じて、前記Ｐ２Ｘ通信のための無線リソースを前記基地局へ要求するために、前記ＲＲＣアイドル状態からＲＲＣコネクティッド状態へ遷移する制御を開始する移動通信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、無線端末及び基地局に関する。
【背景技術】
【０００２】
移動通信システムの標準化プロジェクトである３ＧＰＰ（３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ）において、端末間での直接的なシグナリング（Ｓｉｄｅｌｉｎｋ）に関する仕様策定が進められている（非特許文献１参照）。
【先行技術文献】
【非特許文献】
【０００３】
【非特許文献１】３ＧＰＰ技術仕様書「ＴＳ３６．３００  Ｖ１３．４．０」  ２０１６年７月７日
【発明の概要】
【０００４】
一の実施形態に係る無線端末は、Ｐｅｄｅｓｔｒｉａｎ  ＵＥ（Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ）である。前記無線端末は、他の無線端末との直接的な端末間通信を実行するよう構成されたトランスミッタと、前記Ｐｅｄｅｓｔｒｉａｎ  ＵＥに向けて送信されるリソースプールを基地局から受信するよう構成されたレシーバと、前記リソースプールの種別に応じて、前記端末間通信のために前記リソースプールが利用可能か否かを判定するよう構成されたコントローラと、を備える。
【０００５】
一の実施形態に係る基地局は、Ｐｅｄｅｓｔｒｉａｎ  ＵＥ（Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ）である第１の無線端末から、第２の無線端末との直接的な端末間通信のための無線リソースを要求するメッセージを受信するよう構成されたレシーバと、前記第１の無線端末の能力に応じて、前記第１の無線端末へ割り当てる無線リソースを決定するよう構成されたコントローラと、を備えてもよい。
【図面の簡単な説明】
【０００６】
【図１】図１は、ＬＴＥシステムの構成を示す図である。
【図２】図２は、ＬＴＥシステムにおける無線インターフェイスのプロトコルスタック図である。
【図３】図３は、ＬＴＥシステムで使用される無線フレームの構成図である。
【図４】図４は、ＵＥ１００のブロック図である。
【図５】図５は、ｅＮＢ２００のブロック図である。
【図６】図６は、動作例１を説明するためのシーケンス図（その１）である。
【図７】図７は、動作例１を説明するためのシーケンス図（その２）である。
【図８】図８は、動作例２を説明するための図（その１）である。
【図９】図９は、動作例２を説明するための図（その２）である。
【発明を実施するための形態】
【０００７】
［実施形態の概要］
近年、歩行者型の機能を有する無線端末（Ｐｅｄｅｓｔｒｉａｎ  ＵＥ：Ｐ−ＵＥ）と車両型の機能を有する無線端末（Ｖｅｈｉｃｌｅ  ＵＥ：ＶＵＥ）との間での歩車間通信（Ｐｅｄｅｓｔｒｉａｎ−ｔｏ−Ｖｅｈｉｃｌｅ（Ｐ２Ｖ）通信）の議論が行われている。
【０００８】
しかしながら、現状の仕様書には、Ｐ−ＵＥが、Ｐ２Ｖ通信のために利用可能無線リソースについて規定されていない。このため、Ｐ２Ｖ通信が適切に実行できない可能性がある。
【０００９】
一の実施形態に係る無線端末は、Ｐｅｄｅｓｔｒｉａｎ  ＵＥ（Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ）である。前記無線端末は、他の無線端末との直接的な端末間通信を実行するよう構成されたトランスミッタと、前記Ｐｅｄｅｓｔｒｉａｎ  ＵＥに向けて送信されるリソースプールを基地局から受信するよう構成されたレシーバと、前記リソースプールの種別に応じて、前記端末間通信のために前記リソースプールが利用可能か否かを判定するよう構成されたコントローラと、を備える。
【００１０】
前記コントローラは、前記リソースプールの種別と前記無線端末の能力とに応じて、前記リソースプールを利用可能な否かを判定するよう構成されてもよい。
【００１１】
前記リソースプールが当該リソースプールを使用するためにセンシングが必要なリソースプールであることに応じて、前記コントローラは、前記リソースプールを利用可能であると判定するよう構成されてもよい。
【００１２】
前記リソースプールが当該リソースプールを使用するためにセンシングが不要なリソースプールであってもよい。前記コントローラは、前記無線端末が前記端末間通信における受信能力を有さないことに応じて、前記リソースプールを利用可能であると判定するよう構成されてもよい。
【００１３】
前記コントローラは、前記無線端末がＲａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ（ＲＲＣ）アイドル状態である場合、前記リソースプールを利用不能であると判定したことに応じて、前記端末間通信のための無線リソースを前記基地局へ要求するために、前記ＲＲＣアイドル状態からＲＲＣコネクティッド状態へ遷移する制御を開始するよう構成されてもよい。
【００１４】
前記コントローラは、前記無線リソースを要求するためのメッセージに、前記無線端末が前記Ｐｅｄｅｓｔｒｉａｎ  ＵＥであるか否かを示す情報を含めるよう構成されてもよい。前記トランスミッタは、前記メッセージを前記基地局へ送信するよう構成されてもよい。
【００１５】
前記トランスミッタは、前記無線端末が前記Ｐｅｄｅｓｔｒｉａｎ  ＵＥであるか否かを示す情報を前記基地局へ送信するよう構成されてもよい。
【００１６】
一の実施形態に係る基地局は、Ｐｅｄｅｓｔｒｉａｎ  ＵＥ（Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ）である第１の無線端末から、第２の無線端末との直接的な端末間通信のための無線リソースを要求するメッセージを受信するよう構成されたレシーバと、前記第１の無線端末の能力に応じて、前記第１の無線端末へ割り当てる無線リソースを決定するよう構成されたコントローラと、を備えてもよい。
【００１７】
前記コントローラは、前記第１の無線端末が、前記端末間通信における受信能力を有する場合、センシングが必要なリソースプールを前記無線リソースとして割り当てるよう構成されてもよい。
【００１８】
前記基地局は、前記Ｐｅｄｅｓｔｒｉａｎ  ＵＥ（Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ）とＶｅｈｉｃｌｅ  ＵＥとの前記端末間通信を推奨するセル及び周波数の少なくとも一方を示す情報を前記第１の無線端末へ通知するトランスミッタをさらに備えてもよい。
【００１９】
［実施形態］
（移動通信システム）
以下において、実施形態に係る移動通信システムであるＬＴＥシステムについて説明する。図１は、ＬＴＥシステムの構成を示す図である。
【００２０】
図１に示すように、ＬＴＥシステムは、ＵＥ（Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ）１００、Ｅ−ＵＴＲＡＮ（Ｅｖｏｌｖｅｄ  Ｕｎｉｖｅｒｓａｌ  Ｔｅｒｒｅｓｔｒｉａｌ  Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ）１０、及びＥＰＣ（Ｅｖｏｌｖｅｄ  Ｐａｃｋｅｔ  Ｃｏｒｅ）２０を備える。
【００２１】
ＵＥ１００は、通信装置（例えば、無線端末）に相当する。ＵＥ１００は、移動型の通信装置である。
【００２２】
ＵＥ１００は、歩行者型の機能を有する無線端末であってもよい。例えば、ＵＥ１００は、歩行者が携帯可能な無線端末である。ＵＥ１００は、歩行者型の機能を永続的に有していてもよい。ＵＥ１００は、所定の条件を満たす場合にのみ、歩行者型の機能を有していてもよい。
【００２３】
ＵＥ１００は、当該ＵＥ１００（を構成する各機器（例えば、後述する図４に示すレシーバ１１０、トランスミッタ１２０、コントローラ１３０））へ電力を供給するバッテリを有する場合、歩行者型の機能を有してもよい。ＵＥ１００は、バッテリを有さない場合、すなわち、外部からＵＥ１００へ電力が供給される場合、歩行者型の機能を有さなくてもよい。
【００２４】
ＵＥ１００は、低速移動を実行する又は停止している場合に、歩行者型の機能を有してもよい。ＵＥ１００は、移動速度が低速移動を示す閾値（例えば、１０ｋｍ／ｈ）未満である場合にのみ、歩行者型の機能を有してもよい。ＵＥ１００は、移動速度が閾値以上である場合には、歩行者型の機能を有さなくてもよい。
【００２５】
ＵＥ１００は、加速度が閾値未満である場合にのみ、歩行者型の機能を有してもよい。ＵＥ１００は、加速度が閾値以上である場合には、歩行者型の機能を有さなくてもよい。
【００２６】
ＵＥ１００は、Ｐｅｄｅｓｔｒｉａｎ  ＵＥ（Ｐ−ＵＥ）１００向けの無線リソース（リソースプール）を利用することを望む場合に、歩行者型の機能を有してもよい。ＵＥ１００は、Ｐ−ＵＥ１００向けの無線リソース（リソースプール）を利用することに興味がある場合に、歩行者型の機能を有してもよい。ＵＥ１００は、Ｐ−ＵＥ１００向けの無線リソース（リソースプール）を利用することを望まない場合に、歩行者型の機能を有さなくてもよい。ＵＥ１００は、Ｐ−ＵＥ１００向けの無線リソース（リソースプール）を利用することに興味がない（もはや興味がなくなった）場合に、歩行者型の機能を有さなくてもよい。
【００２７】
ＵＥ１００は、車両に設けられない場合に、歩行者型の機能を有してもよい。ＵＥ１００は、車両に設けられる場合に、歩行者型の機能を有さなくてもよい。
【００２８】
ＵＥ１００は、Ｐ−ＵＥ１００と推定される場合に、歩行者型の機能を有してもよい。例えば、ＵＥ１００は、車両による衝突を回避すべきＵＥ１００である場合に、Ｐ−ＵＥ１００と推定されてもよい。ＵＥ１００は、車両が気を付けるべきＵＥ１００である場合に、Ｐ−ＵＥ１００と推定されてもよい。ＵＥ１００は、車両に対する歩行者が保持するＵＥ１００と推定される場合に、歩行者型の機能を有してもよい。
【００２９】
ＵＥ１００は、所定のアプリケーション（例えば、歩行者の動作に関するアプリケーション）を起動（実行）している場合にのみ、歩行者型の機能を有してもよい。ＵＥ１００は、所定のアプリケーションを起動（実行）していない場合、歩行者型の機能を有さなくてもよい。
【００３０】
ＵＥ１００は、所定のアプリケーション（例えば、車両の動作に関するアプリケーション）を起動（実行）していない場合にのみ、歩行者型の機能を有さなくてもよい。ＵＥ１００は、所定のアプリケーションを起動（実行）していない場合、歩行者型の機能を有していてもよい。
【００３１】
ＵＥ１００は、車両型の機能を有する無線端末であってもよい。例えば、ＵＥ１００は、通信機能を有する車両（ＶＵＥ（Ｖｅｈｉｃｌｅ  ＵＥ）１００）であってもよい。ＵＥ１００は、車両そのもの（例えば、自動車、バイク等）であってもよい。ＵＥ１００は、車両に着脱可能な通信モジュールであってもよい。ＵＥ１００は、車両型の機能を永続的に有していてもよい。ＵＥ１００は、所定の条件を満たす場合にのみ、車両型の機能を有していてもよい。所定の条件は、少なくとも以下のいずれかである。
【００３２】
ＵＥ１００は、バッテリを有さない場合、車両型の機能を有してもよい。ＵＥ１００は、バッテリを有する場合、車両型の機能を有さなくてもよい。
【００３３】
ＵＥ１００は、高速移動を実行する場合に、車両型の機能を有してもよい。ＵＥ１００は、移動速度が高速移動を示す閾値（例えば、１０ｋｍ／ｈ）以上である場合にのみ、車両型の機能を有してもよい。ＵＥ１００は、移動速度が閾値未満である場合には、車両型の機能を有さなくてもよい。ＵＥ１００は、移動速度が高速移動を示す閾値を下回った期間が所定期間を経過した場合にのみ、車両型の機能を（一時的に）失ってもよい。ＵＥ１００は、移動速度が高速移動を示す閾値を下回った期間が所定期間を経過していない場合には、車両型の機能を有してもよい。
【００３４】
ＵＥ１００は、加速度が閾値以上である場合にのみ、車両型の機能を有してもよい。ＵＥ１００は、加速度が閾値未満である場合には、車両型の機能を有さなくてもよい。ＵＥ１００は、加速度が閾値を下回った期間が所定期間を経過した場合にのみ、車両型の機能を（一時的に）失ってもよい。ＵＥ１００は、加速度が閾値を下回った期間が所定期間を経過していない場合には、車両型の機能を有してもよい。
【００３５】
ＵＥ１００は、車両に設けられる場合に、車両型の機能を有してもよい。ＵＥ１００は、車両に設けられない場合に、車両型の機能を有してもよい。
【００３６】
ＵＥ１００は、Ｖ−ＵＥ１００と推定される場合に、車両型の機能を有してもよい。例えば、ＵＥ１００は、Ｐ−ＵＥ１００Ａへの衝突を回避すべきＵＥ１００である場合に、Ｖ−ＵＥ１００と推定されてもよい。ＵＥ１００は、Ｐ−ＵＥ１００Ａに気を付ける場合に、Ｖ−ＵＥ１００と推定されてもよい。ＵＥ１００は、車両に設けられるＵＥ１００と推定される場合に、車両型の機能を有してもよい。
【００３７】
ＵＥ１００は、所定のアプリケーション（例えば、車両の動作に関するアプリケーション）を起動（実行）している場合にのみ、車両型の機能を有してもよい。ＵＥ１００は、所定のアプリケーションを起動（実行）していない場合、車両型の機能を有さなくてもよい。
【００３８】
ＵＥ１００は、所定のアプリケーション（例えば、歩行者の動作に関するアプリケーション）を起動（実行）していない場合にのみ、車両型の機能を有さなくてもよい。ＵＥ１００は、所定のアプリケーションを起動（実行）していない場合、車両型の機能を有していてもよい。
【００３９】
ＵＥ１００は、セル（後述するｅＮＢ２００）と無線通信（Ｕｐｌｉｎｋ／Ｄｏｗｎｌｉｎｋ）を行ってもよい。ＵＥ１００は、他の通信装置と直接的なシグナリングの送信及び／又は受信を実行できてもよい。例えば、ＵＥ１００は、歩車間（Ｐ２Ｖ：Ｐｅｄｅｓｔｒｉａｎ−ｔｏ−Ｖｅｈｉｃｌｅ）通信を実行できる。ＵＥ１００は、Ｖ２Ｘ（Ｖｅｈｉｃｌｅ−ｔｏ−Ｅｖｅｒｙｔｈｉｎｇ）通信（例えば、車車間（Ｖ２Ｖ：Ｖｅｈｉｃｌｅ−ｔｏ−Ｖｅｈｉｃｌｅ）通信、路車間（Ｖ２Ｉ：Ｖｅｈｉｃｌｅ−ｔｏ−Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）通信の少なくともいずれかを実行できてもよい。
【００４０】
Ｅ−ＵＴＲＡＮ１０は、無線アクセスネットワークに相当する。Ｅ−ＵＴＲＡＮ１０は、ｅＮＢ２００（ｅｖｏｌｖｅｄ  Ｎｏｄｅ−Ｂ）を含む。ｅＮＢ２００は、基地局に相当する。ｅＮＢ２００は、Ｘ２インターフェイスを介して相互に接続される。ｅＮＢ２００の動作は、Ｅ−ＵＴＲＡＮ１０の動作とみなされてもよい。
【００４１】
ｅＮＢ２００は、１又は複数のセルを管理する。ｅＮＢ２００は、ｅＮＢ２００が管理するセルとの接続を確立したＵＥ１００との無線通信を行う。ｅＮＢ２００は、無線リソース管理（ＲＲＭ：Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｍａｎａｇｅｍｅｎｔ）機能、ユーザデータ（以下、「データ」と称することがある）のルーティング機能、モビリティ制御・スケジューリングのための測定制御機能等を有する。「セル」は、無線通信エリアの最小単位を示す用語として使用される。「セル」は、ＵＥ１００との無線通信を行う機能を示す用語としても使用されてもよい。
【００４２】
ＥＰＣ２０は、コアネットワークに相当する。ＥＰＣ２０は、Ｅ−ＵＴＲＡＮ１０と共にネットワークを構成してもよい。ＥＰＣ２０は、ＭＭＥ（Ｍｏｂｉｌｉｔｙ  Ｍａｎａｇｅｍｅｎｔ  Ｅｎｔｉｔｙ）３００、及びＳＧＷ（Ｓｅｒｖｉｎｇ  Ｇａｔｅｗａｙ）４００を含む。
【００４３】
ＭＭＥ３００は、例えば、ＵＥ１００に対する各種モビリティ制御を行う。ＳＧＷ４００は、例えば、データの転送制御を行う。ＭＭＥ３００及びＳＧＷ４００は、Ｓ１インターフェイスを介してｅＮＢ２００と接続される。
【００４４】
ＥＰＣ２０の外部には、ＨＳＳ（Ｈｏｍｅ  Ｓｕｂｓｃｒｉｂｅｒ  Ｓｅｒｖｅｒ）５００が設けられていてもよい。ＨＳＳ５００は、ＵＥ１００の加入者情報を管理するノード（ＮＷ装置）である。
【００４５】
図２は、ＬＴＥシステムにおける無線インターフェイスのプロトコルスタック図である。図２に示すように、無線インターフェイスプロトコルは、ＯＳＩ参照モデルの第１層乃至第３層に区分されている。第１層は、物理（ＰＨＹ）層である。第２層は、ＭＡＣ（Ｍｅｄｉｕｍ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ）層、ＲＬＣ（Ｒａｄｉｏ  Ｌｉｎｋ  Ｃｏｎｔｒｏｌ）層、及びＰＤＣＰ（Ｐａｃｋｅｔ  Ｄａｔａ  Ｃｏｎｖｅｒｇｅｎｃｅ  Ｐｒｏｔｏｃｏｌ）層を含む。第３層は、ＲＲＣ（Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ）層を含む。
【００４６】
物理層は、符号化・復号化、変調・復調、アンテナマッピング・デマッピング、及びリソースマッピング・デマッピングを行う。ＵＥ１００の物理層とｅＮＢ２００の物理層との間では、物理チャネルを介してデータ及び制御信号が伝送される。
【００４７】
ＭＡＣ層は、データの優先制御、ハイブリッドＡＲＱ（ＨＡＲＱ）による再送処理、及びランダムアクセス手順等を行う。ＵＥ１００のＭＡＣ層とｅＮＢ２００のＭＡＣ層との間では、トランスポートチャネルを介してデータ及び制御信号が伝送される。ｅＮＢ２００のＭＡＣ層は、スケジューラ（ＭＡＣ  スケジューラ）を含む。スケジューラは、上下リンクのトランスポートフォーマット（トランスポートブロックサイズ、変調・符号化方式（ＭＣＳ））及びＵＥ１００への割当リソースブロックを決定する。
【００４８】
ＲＬＣ層は、ＭＡＣ層及び物理層の機能を利用してデータを受信側のＲＬＣ層に伝送する。ＵＥ１００のＲＬＣ層とｅＮＢ２００のＲＬＣ層との間では、論理チャネルを介してデータ及び制御信号が伝送される。
【００４９】
ＰＤＣＰ層は、ヘッダ圧縮・伸張、及び暗号化・復号化を行う。
【００５０】
ＲＲＣ層は、制御信号を取り扱う制御プレーンでのみ定義される。ＵＥ１００のＲＲＣ層とｅＮＢ２００のＲＲＣ層との間では、各種設定のためのメッセージ（ＲＲＣメッセージ）が伝送される。ＲＲＣ層は、無線ベアラの確立、再確立及び解放に応じて、論理チャネル、トランスポートチャネル、及び物理チャネルを制御する。ＵＥ１００のＲＲＣとｅＮＢ２００のＲＲＣとの間にＲＲＣ接続がある場合、ＵＥ１００は、ＲＲＣコネクティッド状態である。ＵＥ１００のＲＲＣとｅＮＢ２００のＲＲＣとの間にＲＲＣ接続がない場合、ＵＥ１００は、ＲＲＣアイドル状態である。
【００５１】
ＲＲＣ層の上位に位置するＮＡＳ（Ｎｏｎ−Ａｃｃｅｓｓ  Ｓｔｒａｔｕｍ）層は、例えば、セッション管理及びモビリティ管理を行う。
【００５２】
図３は、ＬＴＥシステムで使用される無線フレームの構成図である。ＬＴＥシステムにおいて、下りリンクにはＯＦＤＭＡ（Ｏｒｔｈｏｇｏｎａｌ  Ｆｒｅｑｕｅｎｃｙ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓ）が適用される。上りリンクにはＳＣ−ＦＤＭＡ（Ｓｉｎｇｌｅ  Ｃａｒｒｉｅｒ  Ｆｒｅｑｕｅｎｃｙ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓ）が適用される。
【００５３】
図３に示すように、無線フレームは、時間方向に並ぶ１０個のサブフレームで構成される。各サブフレームは、時間方向に並ぶ２個のスロットで構成される。各サブフレームの長さは１ｍｓである。各スロットの長さは０．５ｍｓである。各サブフレームは、周波数方向に複数のリソースブロック（ＲＢ：Ｒｅｓｏｕｒｃｅ  Ｂｌｏｃｋ）を含む。各サブフレームは、時間方向に複数のシンボルを含む。各リソースブロックは、周波数方向に複数のサブキャリアを含む。１つのシンボル及び１つのサブキャリアにより、１つのリソースエレメント（ＲＥ：Ｒｅｓｏｕｒｃｅ  Ｅｌｅｍｅｎｔ）が構成されるＵＥ１００には、無線リソース（時間・周波数リソース）が割り当てられる。周波数方向において、無線リソース（周波数リソース）は、リソースブロックにより構成される。時間方向において、無線リソース（時間リソース）は、サブフレーム（又はスロット）により構成される。
【００５４】
下りリンクにおいて、各サブフレームの先頭数シンボルの区間は、下りリンク制御信号を伝送するための物理下りリンク制御チャネル（ＰＤＣＣＨ：Ｐｈｙｓｉｃａｌ  Ｄｏｗｎｌｉｎｋ．  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ）として使用可能な領域である。各サブフレームの残りの部分は、下りリンクデータを伝送するための物理下りリンク共有チャネル（ＰＤＳＣＨ：Ｐｈｙｓｉｃａｌ  Ｄｏｗｎｌｉｎｋ  Ｓｈａｒｅｄ  Ｃｈａｎｎｅｌ）として使用可能な領域である。
【００５５】
上りリンクにおいて、各サブフレームにおける周波数方向の両端部は、上りリンク制御信号を伝送するための物理上りリンク制御チャネル（ＰＵＣＣＨ：Ｐｈｙｓｉｃａｌ  Ｕｐｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ）として使用可能な領域である。各サブフレームにおける残りの部分は、上りリンクデータを伝送するための物理上りリンク共有チャネル（ＰＵＳＣＨ：Ｐｈｙｓｉｃａｌ  Ｕｐｌｉｎｋ  Ｓｈａｒｅｄ  Ｃｈａｎｎｅｌ）として使用可能な領域である。
【００５６】
（近傍サービス）
近傍サービス（ＰｒｏＳｅ：Ｐｒｏｘｉｍｉｔｙ−ｂａｓｅｄ  Ｓｅｒｖｉｃｅｓ）について説明する。近傍サービスは、互いに近傍にある通信装置（例えば、ＵＥ１００）に基づいて３ＧＰＰシステムにより提供され得るサービスである。
【００５７】
ＰｒｏＳｅでは、ネットワーク（例えば、ｅＮＢ２００）を経由せずにノード間（例えば、ＵＥ間）で直接的な無線リンクを介して各種の無線信号が直接的に送受信される。ＰｒｏＳｅにおける直接的な無線リンクは、「サイドリンク（Ｓｉｄｅｌｉｎｋ）」と称される。
【００５８】
サイドリンクは、サイドリンク通信及びサイドリンクディスカバリのためのインターフェイス（例えば、ＵＥとＵＥとの間のインターフェイス）であってもよい。サイドリンク通信は、ＰｒｏＳｅ直接通信（以下、「直接通信」と適宜称する）を可能にする機能（ＡＳ  ｆｕｎｃｔｉｏｎａｌｉｔｙ）である。サイドリンクディスカバリは、ＰｒｏＳｅ直接ディスカバリ（以下、「直接ディスカバリ」と適宜称する）を可能にする機能（ＡＳ  ｆｕｎｃｔｉｏｎａｌｉｔｙ）である。
【００５９】
サイドリンクは、ＰＣ５インターフェイスに対応する。ＰＣ５は、ＰｒｏＳｅ直接ディスカバリ、ＰｒｏＳｅ直接通信及びＰｒｏＳｅ  ＵＥ・ネットワーク中継のための制御プレーン及びユーザプレーンのために用いられるＰｒｏＳｅ使用可能なＵＥ（ＰｒｏＳｅ−ｅｎａｂｌｅｄ  ＵＥ）間の参照ポイントである。
【００６０】
ＰｒｏＳｅは、「直接ディスカバリ（Ｄｉｒｅｃｔ  Ｄｉｓｃｏｖｅｒｙ）」及び「直接通信（Ｄｉｒｅｃｔ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ）」及び「Ｒｅｌａｙ」のモードが規定されている。「Ｒｅｌａｙ」については後述する。
【００６１】
直接ディスカバリは、例えば、特定の宛先を指定しないディスカバリメッセージ（ディスカバリ信号）をＵＥ間で直接的に伝送することにより、相手先を探索するモードであってもよい。直接ディスカバリは、ＰＣ５を介してＥ−ＵＴＲＡ（Ｅｖｏｌｖｅｄ  Ｕｎｉｖｅｒｓａｌ  Ｔｅｒｒｅｓｔｒｉａｌ  Ｒａｄｉｏ  Ａｃｃｅｓｓ）における直接無線信号を用いて、ＵＥの近傍における他のＵＥを発見するための手順であってもよい。直接ディスカバリは、Ｅ−ＵＴＲＡ技術で２つのＵＥ１００の能力のみを用いて、近傍サービスを実行可能な他のＵＥ１００を発見するために近傍サービスを実行可能なＵＥ１００によって採用される手順であってもよい。直接ディスカバリは、ＵＥ１００がＥ−ＵＴＲＡＮ（ｅＮＢ２００（セル））によってサービスが提供される場合にのみ、サポートされてもよい。ＵＥ１００は、セル（ｅＮＢ２００）に接続又はセルに在圏している場合、Ｅ−ＵＴＲＡＮによってサービスが提供されてもよい。
【００６２】
ディスカバリメッセージ（ディスカバリ信号）の送信（アナウンスメント）のためのリソース割り当てタイプには、「タイプ１」と「タイプ２（タイプ２Ｂ）」がある。「タイプ１」では、ＵＥ１００が無線リソースを選択する。「タイプ２（タイプ２Ｂ）」では、ｅＮＢ２００が無線リソースを割り当てる。タイプ１では、ＵＥ１００は、ｅＮＢ２００から提供されたリソースプールの中から無線リソースを選択してもよい。「タイプ１」の無線リソース（リソースプール）は、ＵＥ選択送信方式（UE-selected transmission scheme）用の無線リソース（リソースプール）に対応する。「タイプ２（タイプ２Ｂ）」の無線リソース（リソースプール）は、ｅＮＢ制御送信方式（eNB-controlled transmission scheme）用の無線リソース（リソースプール）に対応する。
【００６３】
「Ｓｉｄｅｌｉｎｋ  Ｄｉｒｅｃｔ  Ｄｉｓｃｏｖｅｒｙ」プロトコルスタックは、物理（ＰＨＹ）層、ＭＡＣ層、及びＰｒｏＳｅプロトコルを含む。
【００６４】
直接通信は、例えば、特定の宛先（宛先グループ）を指定してデータをＵＥ間で直接的に伝送するモードであってもよい。直接通信は、いずれのネットワークノードを通過しない経路を介してＥ−ＵＴＲＡ技術を用いたユーザプレーン伝送による、近傍サービスを実行可能である２以上のＵＥ間の通信であってもよい。
【００６５】
直接通信のリソース割り当てタイプには、「モード１」と「モード２」がある。「モード１」では、直接通信の無線リソースをｅＮＢ２００が指定する。「モード２」では、直接通信の無線リソースをＵＥ１００が選択する。モード２では、ＵＥ１００は、ｅＮＢ２００から提供されたリソースプールの中から無線リソースを選択してもよい。「モード１」の無線リソース（リソースプール）は、ｅＮＢ制御送信方式用の無線リソース（リソースプール）に対応する。「モード２」の無線リソース（リソースプール）は、ＵＥ選択送信方式用の無線リソース（リソースプール）に対応する。
【００６６】
ＰＣ５におけるサイドリンク通信（直接通信）におけるユーザプレーンのプロトコルスタックは、物理（ＰＨＹ）層、ＭＡＣ層、ＲＬＣ層、及びＰＤＣＰ層を含む。ＰＣ５におけるサイドリンクブロードキャスト制御チャネル（ＳＢＣＣＨ）のための制御プレーンのプロトコルスタックは、物理（ＰＨＹ）層、ＭＡＣ層、ＲＬＣ層、及びＲＲＣ層を含む。１対１サイドリンク通信のための制御プレーンのプロトコルスタックは、物理（ＰＨＹ）層、ＭＡＣ層、ＲＬＣ層、ＰＤＣＰ層、及びＰＣ５シグナリングプロトコルを含む。
【００６７】
サイドリンクでは、以下のチャネルを用いることによって各種情報が伝送される。
【００６８】
サイドリンクに関する物理チャネルには、物理サイドリンクブロードキャストチャネル（ＰＳＢＣＨ）、物理サイドリンクディスカバリチャネル（ＰＳＤＣＨ）、物理サイドリンク制御チャネル（ＰＳＣＣＨ）及び物理サイドリンク共有チャネル（ＰＳＳＣＨ）がある。
【００６９】
ＰＳＢＣＨは、システム及び同期関連情報（例えば、同期信号）を伝送するためのチャネルである。ＰＳＤＣＨは、ＵＥからのサイドリンクディスカバリメッセージ（ディスカバリ信号）を伝送するためのチャネルである。ＰＳＣＣＨは、サイドリンク通信のためにＵＥからの制御情報を伝送するためのチャネルである。ＰＳＳＣＨは、サイドリンク通信のためにＵＥからのデータを伝送するためのチャネルである。
【００７０】
サイドリンクに関するトランスポートチャネルには、サイドリンクブロードキャストチャネル（ＳＬ−ＢＣＨ）、サイドリンクディスカバリチャネル（ＳＬ−ＤＣＨ）、及びサイドリンク共有チャネル（ＳＬ−ＳＣＨ）がある。ＳＬ−ＢＣＨは、ＰＳＢＣＨにマッピングされる。ＳＬ−ＤＣＨは、ＰＳＤＣＨにマッピングされる。ＳＬ−ＳＣＨは、ＰＳＳＣＨにマッピングされる。
【００７１】
サイドリンクに関する論理チャネル（制御チャネル、トラフィックチャネル）には、サイドリンクブロードキャスト制御チャネル（ＳＢＣＣＨ）及びサイドリンクトラフィックチャネル（ＳＴＣＨ）がある。
【００７２】
ＳＢＣＣＨは、１のＵＥから他のＵＥ（ｓ）へサイドリンクシステム情報をブロードキャストするためのサイドリンクチャネルである。ＳＴＣＨは、１のＵＥから他のＵＥ（ｓ）へユーザ情報（データ）を転送するためのポイントツーマルチポイントチャネルである。ＳＴＣＨは、サイドリンク通信が可能なＵＥでのみ使用される。ＳＴＣＨは、２つのサイドリンク通信可能なＵＥ間でのポイントツーポイント通信に使用されてもよい。ＳＴＣＨは、ＳＬ−ＳＣＨにマッピングされる。ＳＢＣＣＨは、ＳＬ−ＢＣＨにマッピングされる。
【００７３】
（無線端末）
実施形態に係るＵＥ１００（無線端末）について説明する。図４は、ＵＥ１００のブロック図である。図４に示すように、ＵＥ１００は、レシーバ（Ｒｅｃｅｉｖｅｒ：受信部）１１０、トランスミッタ（Ｔｒａｎｓｍｉｔｔｅｒ：送信部）１２０、及びコントローラ（Ｃｏｎｔｒｏｌｌｅｒ：制御部）１３０を備える。レシーバ１１０とトランスミッタ１２０とは、一体化されたトランシーバ（送受信部）であってもよい。
【００７４】
レシーバ１１０は、コントローラ１３０の制御下で各種の受信を行う。レシーバ１１０は、アンテナを含む。レシーバ１１０は、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換する。レシーバ１１０は、ベースバンド信号をコントローラ１３０に出力する。
【００７５】
トランスミッタ１２０は、コントローラ１３０の制御下で各種の送信を行う。トランスミッタ１２０は、アンテナを含む。トランスミッタ１２０は、コントローラ１３０が出力するベースバンド信号（送信信号）を無線信号に変換する。トランスミッタ１２０は、無線信号をアンテナから送信する。
【００７６】
コントローラ１３０は、ＵＥ１００における各種の制御を行う。コントローラ１３０は、プロセッサ及びメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に使用される情報を記憶する。プロセッサは、ベースバンドプロセッサとＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）とを含む。ベースバンドプロセッサは、例えば、ベースバンド信号の変調・復調及び符号化・復号化を行う。ＣＰＵは、メモリに記憶されるプログラムを実行することにより、各種の処理を行う。プロセッサは、音声・映像信号の符号化・復号化を行うコーデックを含んでもよい。プロセッサは、後述する各種の処理及び上述した各種の通信プロトコルを実行する。
【００７７】
ＵＥ１００は、ＧＮＳＳ（Ｇｌｏｂａｌ  Ｎａｖｉｇａｔｉｏｎ  Ｓａｔｅｌｌｉｔｅ  Ｓｙｓｔｅｍ）受信機を備えていてもよい。ＧＮＳＳ受信機は、ＵＥ１００の地理的な位置を示す位置情報を得るために、ＧＮＳＳ信号を受信できる。ＧＮＳＳ受信機は、ＧＮＳＳ信号をコントローラ１３０に出力する。ＵＥ１００は、ＵＥ１００の位置情報を取得するためのＧＰＳ（Ｇｌｏｂａｌ  Ｐｏｓｉｔｉｏｎｉｎｇ  Ｓｙｓｔｅｍ）機能を有していてもよい。ＵＥ１００は、電子コンパス、加速度センサなどの位置を予想する機能を有していてもよい。
【００７８】
ＵＥ１００は、他の通信装置と直接的なシグナリングの送信及び／又は受信を実行可能な機能を有する通信装置である。このため、ＵＥ１００は、その他の構成（例えば、機能、部材等）を有していてもよいことは勿論である。
【００７９】
本明細書では、ＵＥ１００が備えるレシーバ１１０、トランスミッタ１２０及びコントローラ１３０の少なくともいずれかが実行する処理を、便宜上、ＵＥ１００が実行する処理（動作）として説明する。
【００８０】
（基地局）
実施形態に係るｅＮＢ２００（基地局）について説明する。図５は、ｅＮＢ２００のブロック図である。図５に示すように、ｅＮＢ２００は、レシーバ（受信部）２１０、トランスミッタ（送信部）２２０、コントローラ（制御部）２３０、及びネットワークインターフェイス２４０を備える。レシーバ２１０とトランスミッタ２２０は、一体化されたトランシーバ（送受信部）であってもよい。
【００８１】
レシーバ２１０は、コントローラ２３０の制御下で各種の受信を行う。レシーバ２１０は、アンテナを含む。レシーバ２１０は、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換する。レシーバ２１０は、ベースバンド信号をコントローラ２３０に出力する。
【００８２】
トランスミッタ２２０は、コントローラ２３０の制御下で各種の送信を行う。トランスミッタ２２０は、アンテナを含む。トランスミッタ２２０は、コントローラ２３０が出力するベースバンド信号（送信信号）を無線信号に変換する。トランスミッタ２２０は、無線信号をアンテナから送信する。
【００８３】
コントローラ２３０は、ｅＮＢ２００における各種の制御を行う。コントローラ２３０は、プロセッサ及びメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に使用される情報を記憶する。プロセッサは、ベースバンドプロセッサとＣＰＵとを含む。ベースバンドプロセッサは、例えば、ベースバンド信号の変調・復調及び符号化・復号化等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行することにより各種の処理を行う。プロセッサは、後述する各種の処理及び上述した各種の通信プロトコルを実行する。
【００８４】
ネットワークインターフェイス２４０は、Ｘ２インターフェイスを介して隣接ｅＮＢ２００と接続される。ネットワークインターフェイス２４０は、Ｓ１インターフェイスを介してＭＭＥ３００及びＳＧＷ４００と接続される。ネットワークインターフェイス２４０は、例えば、Ｘ２インターフェイス上で行う通信及びＳ１インターフェイス上で行う通信に使用される。
【００８５】
本明細書では、ｅＮＢ２００が備えるレシーバ２１０、トランスミッタ２２０、コントローラ２３０、及びネットワークインターフェイス２４０の少なくともいずれかが実行する処理を、便宜上、ｅＮＢ２００が実行する処理（動作）として説明する。
【００８６】
（実施形態に係る動作）
実施形態に係る動作について、以下の動作例１及び２により説明する。
【００８７】
（Ａ）動作例１
動作例１について、図６及び図７を用いて説明する。図６は、動作例１を説明するためのシーケンス図（その１）である。図７は、動作例１を説明するためのシーケンス図（その２）である。
【００８８】
（ａ）ＲＲＣアイドル状態における動作
図６において、Ｐ−ＵＥ１００Ａは、歩行者型の機能を有する。初期状態において、Ｐ−ＵＥ１００Ａは、ＲＲＣアイドル状態である。Ｐ−ＵＥ１００Ａは、ｅＮＢ２００が管理するセルにキャンプしていてもよい。Ｖ−ＵＥ１００Ｂは、車両型の機能を有する。
【００８９】
ステップＳ１１０において、ｅＮＢ２００は、Ｐ−ＵＥ向けのリソースプールの情報をＰ−ＵＥ１００Ａへ送信する。Ｐ−ＵＥ１００Ａは、Ｐ−ＵＥ１００Ａに向けて送信されるリソースプールをｅＮＢ２００から受信する。
【００９０】
ｅＮＢ２００は、リソースプールの情報を、ブロードキャストシグナリング（例えば、ＳＩＢ（Ｓｙｓｔｅｍ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｂｌｏｃｋ））により、Ｐ−ＵＥ１００Ａへ送信してもよい。
【００９１】
リソースプールは、複数の時間・周波数リソースにより構成される。リソースプールは、端末間通信用のリソースプールである。具体的には、リソースプールは、Ｐ２Ｖ通信用のリソースプールである。端末間通信は、例えば、サイドリンク（近傍サービス）を利用した通信（送信／受信）である。
【００９２】
リソースプールは、当該リソースプールを使用するためにセンシングが必要なリソースプール（第１リソースプール）であってもよい。Ｐ−ＵＥ１００Ａは、第１リソースプールを使用する場合、第１リソースプールをセンシングする。すなわち、Ｐ−ＵＥ１００Ａは、第１リソースプールの少なくとも一部の無線リソースにおいて無線信号（特に、Ｐ２Ｖ通信のための直接的な無線信号）のモニタを試みる。Ｐ−ＵＥ１００Ａは、センシング結果に応じて、使用されていない無線リソースを判定する。Ｐ−ＵＥ１００Ａは、使用されていない無線リソースを用いて、Ｐ２Ｖ通信を実行する。センシング時間は、Ｖ−ＵＥ１００ＢがＶ２Ｖ（又はＶ２Ｘ）通信をするために必要なセンシング時間よりも短くてもよい。これにより、Ｐ−ＵＥ１００Ａは、電力消費を低減できる。
【００９３】
第１リソースプールは、センシングが必要であるため、端末間通信における受信能力（例えば、Ｓｉｄｅｌｉｎｋ  Ｒｘ  Ｃａｐａｂｉｌｉｔｙ）を有するＰ−ＵＥ１００のみが利用可能であってもよい。第１リソースプールは、端末間通信における受信能力を有さないＰ−ＵＥ１００が利用不能であってもよい。
【００９４】
Ｐ−ＵＥ１００Ａは、端末間通信における受信能力を有する場合、端末間通信において送信された無線信号を受信することができる。Ｐ−ＵＥ１００Ａは、端末間通信における受信能力を有さない場合、端末間通信において送信された無線信号を受信することができない。
【００９５】
リソースプールは、当該リソースプールを使用するためにセンシングが不要な第２リソースプールであってもよい。第２リソースプールは、第１リソースプールの例外的なリソースプール（Ｅｘｃｅｐｔｉｏｎａｌ  ｐｏｏｌ）であってもよい。第１リソースプールが使用できない場合にのみ、第２リソースプールが使用できてもよい。
【００９６】
Ｐ−ＵＥ１００Ａは、第２リソースプールの中からランダムにＰ２Ｖ通信のための無線リソースを選択してもよい。第２リソースプール内の無線リソースを用いた送信は、Ｐ−ＵＥ１００Ａのみが許可されていてもよい。
【００９７】
ｅＮＢ２００は、サービングセル（サービング周波数）がＰ２Ｖ通信（送信）を推奨するセル（周波数）であることを示す情報を通知してもよい。ｅＮＢ２００は、当該情報を、ブロードキャストシグナリング（例えば、ＳＩＢ）により、Ｐ−ＵＥ１００Ａへ通知（送信）してもよい。ｅＮＢ２００は、当該情報をリソースプールの情報と共に通知（送信）してもよい。
【００９８】
Ｐ−ＵＥ１００Ａは、当該情報に基づいて、以下の動作を実行するか否かを判定してもよい。Ｐ−ＵＥ１００Ａは、サービングセルがＰ２Ｖ通信を推奨するセルである場合にのみ、以下の動作を実行してもよい。Ｐ−ＵＥ１００Ａは、サービングセルがＰ２Ｖ通信を推奨するセルでない場合には、以下の動作を省略してもよい。
【００９９】
ステップＳ１２０において、Ｐ−ＵＥ１００Ａは、ｅＮＢ２００から受信したリソースプールの種別をチェックしてもよい。
【０１００】
ステップＳ１３０において、Ｐ−ＵＥ１００Ａは、リソースプールの種別に応じて、リソースプールが利用可能な否かを判定してもよい。
【０１０１】
Ｐ−ＵＥ１００Ａは、ｅＮＢ２００により提供されるリソースプールが第１リソースプール（センシング要）であることに応じて、リソースプールが利用可能であると判定してもよい。Ｐ−ＵＥ１００Ａは、ｅＮＢ２００により提供されるリソースプールが第２リソースプール（センシング不要）であることに応じて、リソースプールが利用可能であると判定してもよい。
【０１０２】
Ｐ−ＵＥ１００Ａは、リソースプールの種別とＰ−ＵＥ１００Ａの能力とに応じて、リソースプールを利用可能か否かを判定してもよい。
【０１０３】
リソースプール（の種別）が第１リソースプールである場合、Ｐ−ＵＥ１００Ａは、Ｐ−ＵＥ１００Ａが端末間通信（Ｐ２Ｖ通信）における受信能力を有さないことに応じて、リソースプールが利用不能と判定してもよい。Ｐ−ＵＥ１００Ａは、Ｐ−ＵＥ１００Ａが端末間通信における受信能力を有することに応じて、リソースプールが利用可能と判定してもよい。
【０１０４】
リソースプール（の種別）が第２リソースプールである場合、Ｐ−ＵＥ１００Ａは、Ｐ−ＵＥ１００Ａが端末間通信（Ｐ２Ｖ通信）における受信能力を有さないことに応じて、リソースプールが利用可能と判定してもよい。Ｐ−ＵＥ１００Ａは、Ｐ−ＵＥ１００Ａが端末間通信における受信能力を有することに応じて、リソースプールが利用不能と判定してもよい。
【０１０５】
ｅＮＢ２００は、第２リソースプールを利用可能であるＰ−ＵＥ１００は、端末間通信（Ｐ２Ｖ通信）における受信能力を有さないＰ−ＵＥ１００のみであることを、Ｐ−ＵＥ１００Ａへ通知してもよい。ｅＮＢ２００は、当該情報をブロードキャストシグナリング（例えば、ＳＩＢ）により、Ｐ−ＵＥ１００Ａへ送信してもよい。Ｐ−ＵＥ１００Ａは、当該情報に基づいて、リソースプールが利用可能か否かを判定してもよい。
【０１０６】
Ｐ−ＵＥ１００Ａは、リソースプールが利用可能であると判定したことに応じて、ステップＳ１４０の処理を実行してもよい。Ｐ−ＵＥ１００Ａは、リソースプールが利用不能であると判定したことに応じて、ステップＳ１５０の処理を実行してもよい。
【０１０７】
ステップＳ１４０において、Ｐ−ＵＥ１００Ａは、利用可能なリソースプールを用いて、Ｐ２Ｖ送信を実行できる。例えば、Ｐ−ＵＥ１００Ａは、第１リソースプールを用いる場合、センシング結果に基づいて、第１リソースプールの中から、使用されていない無線リソースを選択する。Ｐ−ＵＥ１００Ａは、選択した無線リソースを用いて、Ｐ２Ｖ通信により直接的な無線信号を送信する。Ｖ−ＵＥ１００Ｂは、ｅＮＢ２００から提供されるリソースプールにおいて、無線信号のモニタを実行する。これにより、Ｖ−ＵＥ１００Ｂは、Ｐ−ＵＥ１００Ａからの無線信号を受信する。Ｖ−ＵＥ１００Ｂは、Ｐ−ＵＥ１００Ａからの無線信号に基づいて、移動に関する制御を実行してもよい。
【０１０８】
Ｐ−ＵＥ１００Ａは、第２リソースプールを用いる場合、第２リソースプールの中からランダムに無線リソースを選択してもよい。その他の動作は、第１リソースプールが使用されるケースと、同様である。
【０１０９】
以上のように、Ｐ−ＵＥ１００Ａは、リソースプールが利用可能である場合、自律的に無線リソースを選択する。Ｐ−ＵＥ１００Ａは、選択した無線リソースを用いて、Ｐ２Ｖ通信により直接的な無線信号を送信できる（Ｍｏｄｅ  ４送信）。
【０１１０】
ステップＳ１５０において、Ｐ−ＵＥ１００Ａは、端末間通信のための無線リソースをｅＮＢ２００（ネットワーク）へ要求するために、ＲＲＣアイドル状態からＲＲＣコネクティッド状態へ遷移する制御を開始してもよい。すなわち、Ｐ−ＵＥ１００Ａは、ＲＲＣ接続要求をｅＮＢ２００へ送信してもよい。その後、Ｐ−ＵＥ１００Ａは、ＲＲＣコネクティッド状態へ遷移する。すなわち、Ｐ−ＵＥ１００Ａは、ｅＮＢ２００（セル（Ｐｒｉｍａｒｙ  セル／サービングセル））とＲＲＣ接続を確立する。ＲＲＣコネクティッド状態におけるＰ−ＵＥ１００Ａの動作は、後述する。
【０１１１】
Ｐ−ＵＥ１００Ａは、リソースプールを利用不能であると判定したことに応じて、ＲＲＣアイドル状態からＲＲＣコネクティッド状態へ遷移してもよい。Ｐ−ＵＥ１００Ａは、端末間通信（Ｐ２Ｖ通信）用のリソースプールを提供していないことに応じて、ＲＲＣアイドル状態からＲＲＣコネクティッド状態へ遷移してもよい。すなわち、Ｐ−ＵＥ１００Ａは、ＲＲＣアイドル状態では、Ｐ２Ｖ通信が実行できない場合に、ＲＲＣアイドル状態からＲＲＣコネクティッド状態へ遷移してもよい。
【０１１２】
このように、Ｐ−ＵＥ１００Ａは、端末間通信（Ｐ２Ｖ通信）用のためのリソースプールが提供されているか否かによって、Ｍｏｄｅ  ４送信を実行するか否かを判定してもよい。
【０１１３】
（ｂ）ＲＲＣコネクティッド状態における動作
次に、ＲＲＣコネクティッド状態について、図７を用いて説明する。初期状態において、Ｐ−ＵＥ１００Ａは、ＲＲＣコネクティッド状態である。Ｐ−ＵＥ１００Ａは、ｅＮＢ２００（セル）とＲＲＣ接続を確立している。
【０１１４】
Ｐ−ＵＥ１００Ａは、上述のアイドル状態における動作を実行した後に、以下の動作を実行してもよい。Ｐ−ＵＥ１００Ａは、上述のアイドル状態に動作を実行したかに関係なく、以下の動作を実行してもよい。
【０１１５】
ステップＳ２１０において、Ｐ−ＵＥ１００Ａは、端末間通信における受信能力を有するか否かを示す情報（Ｓｉｄｅｌｉｎｋ  Ｒｘ  Ｃａｐａｂｉｌｉｔｙ）をｅＮＢ２００へ送信してもよい。
【０１１６】
Ｐ−ＵＥ１００Ａは、Ｐ−ＵＥ１００Ａが歩行者型の機能を有するか（Ｐ−ＵＥであるか）否かを示す情報（“Ｐ−ＵＥ”  ｉｎｄｉｃａｔｉｏｎ）をｅＮＢ２００へ送信してもよい。Ｐ−ＵＥ１００Ａは、Ｓｉｄｅｌｉｎｋ  Ｒｘ  Ｃａｐａｂｉｌｉｔｙと共に”Ｐ−ＵＥ”  ｉｎｄｉｃａｔｉｏｎをｅＮＢ２００へ送信してもよい。Ｐ−ＵＥ１００Ａは、歩行者型の機能を有する場合にのみ、”Ｐ−ＵＥ”  ｉｎｄｉｃａｔｉｏｎをｅＮＢ２００へ送信してもよい。Ｐ−ＵＥ１００Ａは、歩行者型の機能を有さなくなった場合に、歩行者型の機能を有さないことを示す”Ｐ−ＵＥ”  ｉｎｄｉｃａｔｉｏｎをｅＮＢ２００へ送信してもよい。Ｐ−ＵＥ１００Ａは、Ｐ−ＵＥ１００Ａの能力情報（Ｃａｐａｂｉｌｉｔｙ）として、”Ｐ−ＵＥ”  ｉｎｄｉｃａｔｉｏｎをｅＮＢ２００へ送信してもよい。このように、Ｐ−ＵＥ１００Ａは、端末間通信（Ｐ２Ｖ通信）を実行するか否かにかかわらず、”Ｐ−ＵＥ”  ｉｎｄｉｃａｔｉｏｎをｅＮＢ２００へ予め送信してもよい。
【０１１７】
ｅＮＢ２００は、Ｓｉｄｅｌｉｎｋ  Ｒｘ  Ｃａｐａｂｉｌｉｔｙにより、Ｐ−ＵＥ１００Ａが端末間通信における受信能力を有するか否かを判定できる。ｅＮＢ２００は、”Ｐ−ＵＥ”  ｉｎｄｉｃａｔｉｏｎにより、Ｐ−ＵＥ１００Ａが、歩行者型の機能を有するか（すなわち、Ｐｅｄｅｓｔｒｉａｎ  ＵＥであるか否か）を判定できる。
【０１１８】
ステップＳ２２０において、Ｐ−ＵＥ１００Ａにおいて、送信のために利用可能な端末間通信用のデータ（サイドリンクデータ）が発生したと仮定する。Ｐ−ＵＥ１００Ａにおいて、Ｐ２Ｖ通信により送信すべきデータが発生してもよい。
【０１１９】
ステップＳ２３０において、Ｐ−ＵＥ１００Ａは、端末間通信のための無線リソースを要求するためのメッセージをｅＮＢ２００へ送信する。Ｐ−ＵＥ１００Ａは、当該メッセージに、送信すべきデータの量を示す情報を含めてもよい。Ｐ−ＵＥ１００Ａは”Ｐ−ＵＥ”  ｉｎｄｉｃａｔｉｏｎを当該メッセージに含めてもよい。
【０１２０】
ステップＳ２４０において、ｅＮＢ２００は、上位のネットワーク装置から”Ｐ−ＵＥ”  ｉｎｄｉｃａｔｉｏｎを把握するための情報を受け取ってもよい。例えば、ｅＮＢ２００は、ＭＭＥ３００を介して、”Ｐ−ＵＥ”  ｉｎｄｉｃａｔｉｏｎを含むＵＥコンテキストをＨＳＳ５００から受け取ってもよい。ｅＮＢ２００は、ＵＥコンテキストに基づいて、Ｐ−ＵＥ１００Ａが歩行者型の機能を有するか判定してもよい。
【０１２１】
ｅＮＢ２００は、ＭＭＥ３００（又はＨＳＳ５００）に、”Ｐ−ＵＥ”  ｉｎｄｉｃａｔｉｏｎを要求するためのメッセージを送ってもよい。ＭＭＥ３００（又はＨＳＳ５００）は、当該メッセージの受信に応じて、”Ｐ−ＵＥ”  ｉｎｄｉｃａｔｉｏｎ（ＵＥコンテキスト）をｅＮＢ２００へ送ってもよい。
【０１２２】
ステップＳ２５０において、ｅＮＢ２００は、Ｐ−ＵＥ１００Ａへ無線リソースを割り当てる。ｅＮＢ２００は、Ｐ−ＵＥ１００Ａが歩行者型の機能を有することに応じて、Ｐ−ＵＥ向けの無線リソース（リソースプール）の中から、Ｐ−ＵＥ１００Ａへ割り当てる無線リソース（リソースプール）を割り当てる。
【０１２３】
ｅＮＢ２００は、Ｐ−ＵＥ１００Ａが歩行者型の機能を有すると判定した場合、Ｐ−ＵＥ１００Ａの能力に応じて、無線リソース（リソースプール）の割り当てを行うことができる。
【０１２４】
ｅＮＢ２００は、Ｐ−ＵＥ１００Ａが端末間通信における受信能力を有する場合に（のみ）、第１のリソースプールをＰ−ＵＥ１００Ａへ割り当ててもよい。ｅＮＢ２００は、Ｐ−ＵＥ１００Ａが端末間通信における受信能力を有する場合には、第２のリソースプールをＰ−ＵＥ１００Ａへ割り当てないようにしてもよい。
【０１２５】
ｅＮＢ２００は、Ｐ−ＵＥ１００Ａが端末間通信における受信能力を有さない場合には、第２のリソースプールをＰ−ＵＥ１００Ａへ割り当ててもよい。ｅＮＢ２００は、Ｐ−ＵＥ１００Ａが端末間通信における受信能力を有さない場合には、第１のリソースプールをＰ−ＵＥ１００Ａへ割り当てないようにしてもよい。ｅＮＢ２００は、端末間通信における受信能力を有さないＰ−ＵＥ１００にのみ、第２のリソースプールを割り当ててもよい。
【０１２６】
ｅＮＢ２００は、リソースプールを利用した端末間通信（Ｍｏｄｅ  ４送信）を許可していない場合には、時間・周波数リソースをＰ−ＵＥ１００Ａへ割り当ててもよい。ｅＮＢ２００は、リソースプールを利用した端末間通信（Ｍｏｄｅ  ４送信）を許可している場合であっても、時間・周波数リソースをＰ−ＵＥ１００Ａへ割り当ててもよい。
【０１２７】
Ｐ−ＵＥ１００Ａは、ｅＮＢ２００から割り当てられた無線リソース（リソースプール）を受信する。
【０１２８】
ステップＳ２６０において、Ｐ−ＵＥ１００Ａは、割り当てられた無線リソース（リソースプール）を用いて、端末間通信による送信を実行する。
【０１２９】
Ｐ−ＵＥ１００Ａは、リソースプールではなく、時間・周波数リソースが割り当てられた場合、当該リソースを用いて、端末間通信による送信を実行する（Ｍｏｄｅ  ３送信）。すなわち、Ｐ−ＵＥ１００Ａは、ｅＮＢ２００の制御下で、端末間通信による送信を実行する。
【０１３０】
割り当てられた無線リソースがリソースプール内である場合、Ｖ−ＵＥ１００Ｂは、リソースプールにおいてモニタを実行することにより、Ｐ−ＵＥ１００Ａからの直接的な無線信号を受信することができる。
【０１３１】
ｅＮＢ２００は、割り当てた無線リソースをブロードキャスト又はユニキャストにより、Ｖ−ＵＥ１００へ通知してもよい。Ｖ−ＵＥ１００は、通知された無線リソースにおいてモニタを実行することにより、Ｐ−ＵＥ１００Ａからの直接的な無線信号を受信することができる。
【０１３２】
Ｐ−ＵＥ１００Ａは、リソースプールが割り当てられた場合には、ＲＲＣアイドルにおける動作と同様に、Ｍｏｄｅ  ４送信を実行する。具体的には、Ｐ−ＵＥ１００Ａは、割り当てられたリソースプールの中から、使用されていない無線リソースを選択する。Ｐ−ＵＥ１００Ａは、選択した無線リソースを用いて、Ｐ２Ｖ通信により直接的な無線信号を送信する。Ｖ−ＵＥ１００Ｂは、ｅＮＢ２００から提供されるリソースプールにおいて、無線信号のモニタを実行する。これにより、Ｖ−ＵＥ１００Ｂは、Ｐ−ＵＥ１００Ａからの無線信号を受信する。
【０１３３】
以上によれば、Ｐ−ＵＥ１００Ａは、自身が利用可能な無線リソースを適切に把握することができるため、Ｐ２Ｖ通信を適切に実行することができる。
【０１３４】
（Ｂ）動作例２
動作例２について、図８及び図９を用いて説明する。図８は、動作例２を説明するための図（その１）である。図９は、動作例２を説明するための図（その２）である。
【０１３５】
図８において、各Ｐ−ＵＥ１００（Ｐ−ＵＥ１００Ａ、Ｐ−ＵＥ１００Ｂ、Ｐ−ＵＥ１００Ｃ）は、ｅＮＢ２００が管理するセルＸに接続又はキャンプしている。セルＸは、セルラ通信用のセルである。セルＸは、セルラ通信用の周波数Ｘに属する。
【０１３６】
ｅＮＢ２００Ａは、周波数Ｙに属するセルＡを管理する。ｅＮＢ２００Ｂは、周波数Ｙに属するセルＢを管理する。ｅＮＢ２００Ｃは、周波数Ｙに属するセルＣを管理する。セルＡ、セルＢ及びセルＣは、Ｖ２Ｘ通信用のセルである。セルＡ、セルＢ及びセルＣは、少なくとも一部がセルＸと重複している。周波数Ｙは、Ｖ２Ｘ通信用の周波数である。周波数Ｙは、周波数Ｘと異なる。ｅＮＢ２００Ａ、ｅＮＢ２００Ｂ及びｅＮＢ２００Ｃは、路側機（Ｒｏａｄ  Ｓｉｄｅ  Ｕｎｉｔ：ＲＳＵ）であってもよい。
【０１３７】
ｅＮＢ２００は、Ｐ２Ｖ送信を推奨するセル及び周波数の少なくとも一方を示す情報（推奨情報）を各Ｐ−ＵＥ１００へ通知できる。ｅＮＢ２００は、推奨情報を、個別シグナリング（例えば、ＲＲＣ再設定メッセージ、ＤＣＩなど）及び／又はブロードキャストシグナリング（例えば、ＳＩＢ）により、Ｐ−ＵＥ１００Ａへ通知（送信）してもよい。
【０１３８】
ｅＮＢ２００は、Ｖ２Ｘ通信用のセル（周波数Ｙ）が推奨セル（周波数）であるか否かを示す推奨情報を各Ｐ−ＵＥ１００へ通知できる。例えば、ｅＮＢ２００は、セルＡ及びセルＢでは、Ｐ２Ｖ送信を推奨し、セルＣでは、Ｐ２Ｖ通信を推奨しないことを示す推奨情報を各Ｐ−ＵＥ１００へ通知できる。一例として、車両の交通量が多い場所に設定されたｅＮＢ（ＲＳＵ）２００Ａ及び２００Ｂが管理するセルでは、Ｐ２Ｖ送信を推奨してもよい。車両の交通量が少ない場所に設定されたｅＮＢ（ＲＳＵ）２００Ｃ管理するセルでは、Ｐ２Ｖ送信を推奨してもよい。
【０１３９】
Ｐ−ＵＥ１００Ａは、推奨情報に基づいて、セルＡ（周波数Ｙ）において、Ｐ２Ｖ送信を実行すると判定してもよい。この場合、Ｐ−ＵＥ１００Ａは、上述の動作例１の動作を実行してもよい。Ｐ−ＵＥ１００Ａは、例えば、ｅＮＢ（ＲＳＵ）２００Ａから提供されるリソースプールを用いて、Ｐ２Ｖ送信を実行してもよい。このように、推奨情報が、Ｐ２Ｖ送信のトリガであってもよい。ｅＮＢ（ＲＳＵ）２００ＡとＶ２Ｘ通信を実行中のＶ−ＵＥ１００Ａは、同一周波数のリソースプールをモニタすることによって、Ｐ−ＵＥ１００ＡからのＰ２Ｖ送信を受信することができる。Ｐ−ＵＥ１００Ｂも同様である。一方、Ｐ−ＵＥ１００Ｃは、推奨情報に基づいて、セルＣ（周波数Ｙ）において、Ｐ２Ｖ送信を実行しないと判定してもよい。
【０１４０】
図９に示すように、ｅＮＢ（ＲＳＵ）２００は、Ｖ２Ｘ通信用の隣接セルにおける推奨情報をＰ−ＵＥ１００へ通知してもよい。
【０１４１】
例えば、ｅＮＢ（ＲＳＵ）２００Ｂは、セルＡ（周波数Ａ）ではＰ２Ｖ送信を推奨していることを示す推奨情報をＰ−ＵＥ１００Ａ（及びＰ−ＵＥ１００Ｂ）へ通知する。これにより、Ｐ−ＵＥ１００Ａは、セルＡに入る前にセルＡではＰ２Ｖ送信を推奨していることを知ることができる。ｅＮＢ（ＲＳＵ）２００Ｂが通知するセルＡにおける推奨情報は、セルＡにおいてＰ２Ｖ送信に用いられるリソースプールの情報を含んでいてもよい。これにより、Ｐ−ＵＥ１００Ａは、セルＡに入るとすぐに、Ｐ２Ｖ送信を実行することができる。Ｖ−ＵＥ１００Ａは、セルＡに入るとすぐに、Ｐ２Ｖ送信を受信することができる。
【０１４２】
ｅＮＢ（ＲＳＵ）２００Ａが管理する周波数ＡとｅＮＢ（ＲＳＵ）２００Ｂが管理する周波数Ｂとは同一であってもよい。周波数Ａと周波数Ｂとは異なってもよい。
【０１４３】
［その他の実施形態］
上述した各実施形態によって、本出願の内容を説明したが、この開示の一部をなす論述及び図面は、本出願の内容を限定するものであると理解すべきではない。この開示から当業者には様々な代替実施形態、実施例及び運用技術が明らかとなろう。
【０１４４】
上述において、Ｐ−ＵＥ１００Ａは、サイドリンクを利用した端末間通信を中心に説明したが、これに限られない。Ｐ−ＵＥ１００Ａは、Ｄｉｓｃｏｖｅｒｙ信号（メッセージ）、ＰＣ５シグナリングなどの直接的な無線信号の送信／受信を実行する場合に、上述の動作を実行してもよい。Ｐ−ＵＥ１００Ａは、ＬＴＥシステム以外のシステムにおける直接的な無線信号の送信／受信をする場合に、上述の動作を実行してもよい。
【０１４５】
Ｐ−ＵＥ１００Ａは、端末間通信における送信能力（例えば、Ｓｉｄｅｌｉｎｋ  Ｔｘ  Ｃａｐａｂｉｌｉｔｙ）を有さない場合、ｅＮＢ２００を介した（Ｕｕ経由での）Ｐ２Ｖ送信を実行してもよい。
【０１４６】
上述した実施形態に係る動作（各動作例）は、適宜組み合わせて実行されてもよい。上述した各シーケンスにおいて、必ずしも全ての動作が必須の構成ではない。例えば、各シーケンスにおいて、一部の動作のみが実行されてもよい。
【０１４７】
上述した各実施形態では特に触れていないが、上述した各ノード（ＵＥ１００、ｅＮＢ２００など）のいずれかが行う各処理をコンピュータに実行させるプログラムが提供されてもよい。プログラムは、コンピュータ読取り可能媒体に記録されていてもよい。コンピュータ読取り可能媒体を用いれば、コンピュータにプログラムをインストールすることが可能である。プログラムが記録されたコンピュータ読取り可能媒体は、非一過性の記録媒体であってもよい。非一過性の記録媒体は、特に限定されるものではないが、例えば、ＣＤ−ＲＯＭやＤＶＤ−ＲＯＭ等の記録媒体であってもよい。
【０１４８】
ＵＥ１００及びｅＮＢ２００のいずれかが行う各処理を実行するためのプログラムを記憶するメモリ及びメモリに記憶されたプログラムを実行するプロセッサによって構成されるチップが提供されてもよい。
【０１４９】
上述した実施形態では、移動通信システムの一例としてＬＴＥシステムを説明したが、ＬＴＥシステムに限定されるものではなく、ＬＴＥシステム以外のシステムに本出願に係る内容を適用してもよい。
【０１５０】
［付記］
（１）導入
Ｐ２Ｖ型サービスは、歩行者ＵＥにとって、Ｖ２Ｐ型サービスよりも電力効率が高い。Ｐ２Ｖ通信の更なる特徴を検討する。
【０１５１】
（２）検討
（２．１）サイドリンク受信能力のないＰ−ＵＥ
歩行者ＵＥ（Ｐ−ＵＥ）はサイドリンク受信能力を有していないことが想定される。サイドリンク受信能力のないＰ−ＵＥはセンシングを行うことができないので、Ｐ−ＵＥがＰ２Ｖ送信を実行したい場合、Ｐ−ＵＥは、センシングなしでのｅＮＢ制御送信方式（ｅＮＢ−ｃｏｎｔｒｏｌｌｅｄ  ｔｒａｎｓｍｉｓｓｉｏｎ  ｓｃｈｅｍｅ）又はＵＥ選択送信方式（ＵＥ−ｓｅｌｅｃｔｅｄ  ｔｒａｎｓｍｉｓｓｉｏｎ  ｓｃｈｅｍｅ）に従う必要がある。ＲＲＣ＿ＩＤＬＥにおいてサイドリンク受信能力のないＰ−ＵＥを考慮すると、ｅＮＢがセンシングなしでの送信リソースプールをＳＩＢで提供する場合、ＵＥは直接的にそれを使用することができる。そして、ｅＮＢがセンシングなしでの送信リソースプールをＳＩＢで提供しない場合、Ｐ−ＵＥは、送信リソースを要求するためにＲＲＣ＿ＣＯＮＮＥＣＴＥＤに遷移すべきである。ＲＲＣ＿ＣＯＮＮＥＣＴＥＤにおいてサイドリンク受信能力のないＰ−ＵＥを考慮すると、ｅＮＢは、個別シグナリング（ｄｅｄｉｃａｔｅｄ  ｓｉｇｎａｌｌｉｎｇ）を介して送信リソース（プール）を提供する。その場合、ｅＮＢは、サイドリンク受信能力のないＰ−ＵＥがセンシングなしでの送信リソース（プール）を必要としているかどうかを知る必要がある。従って、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤにおいてサイドリンク受信能力のないＰ−ＵＥは、センシングなしでの送信リソースの必要性をｅＮＢに通知すべきである。
【０１５２】
所見１：ＲＲＣ＿ＣＯＮＮＥＣＴＥＤにおいてサイドリンク受信能力のないＰ−ＵＥは、センシングなしでの送信リソースの必要性をｅＮＢに通知すべきである。
【０１５３】
（２．２）サイドリンク受信能力があるＰ−ＵＥ
前のセクションで説明したように、サイドリンク受信機能のないＰ−ＵＥは、センシングなしでのｅＮＢ制御送信方式用のリソース又はＵＥ選択送信方式用のリソースプールのいずれかを使用する必要がある。一方、サイドリンク受信能力があるＰ−ＵＥが、部分的なセンシング（すなわち、限られた時間の間のセンシング）を伴うＵＥ選択送信方式用のリソースプールと、センシングなしでのＵＥ選択送信方式用のリソースプールとの両方を使用できるかどうかはまだ先の課題であるが、無線能力の観点から、サイドリンク受信能力があるＰ−ＵＥは、両方のタイプのリソースプールを使用することができる。Ｐ−ＵＥの観点からは、バッテリ消費量が少ない方が良いので、サイドリンク受信能力があるＰ−ＵＥもセンシングなしでの送信リソースを使用できることが有益である。しかしながら、ＵＥ選択送信方式を考慮すると、送信リソースの衝突は、センシングなしでの送信リソースプール内で発生する。従って、センシングなしでの送信リソースプールがサイドリンク受信能力があるＰ−ＵＥに提供されるかどうかをｅＮＢが制御できることが望ましい。
【０１５４】
ＲＲＣ＿ＩＤＬＥにおけるサイドリンク受信能力があるＰ−ＵＥを考慮すると、Ｐ−ＵＥの観点からは、サイドリンク受信能力があるＰ−ＵＥが、Ｐ−ＵＥの電力消費を最小限に抑えることができる送信リソースを選択することが有用であろう。しかしながら、ｅＮＢの観点から、センシングなしでの送信リソースプールを使用するＰ−ＵＥの数を制限することによって送信リソースの衝突を制御するために、ｅＮＢは、サイドリンク受信能力があるＰ−ＵＥにセンシングなしでの送信リソースを使用できるか否かを通知することが有用かもしれない。
【０１５５】
一方、ＲＲＣ＿ＣＯＮＮＥＣＥＴＤにおいてサイドリンク受信能力があるＰ−ＵＥを考慮すると、ｅＮＢは、ＵＥ選択送信リソースの衝突確率とＰ−ＵＥの電力効率とを考慮して、サイドリンク受信能力があるＰ−ＵＥに適切なリソースを提供することができる。
【０１５６】
提案１：サイドリンク受信能力があるＰ−ＵＥに、センシングなしでのリソースプールを使用する許可をｅＮＢが通知できるか否かについて検討されるべきである。
【０１５７】
米国仮出願第６２／４０２２５１号（２０１６年９月３０日出願）の全内容が、参照により、本願明細書に組み込まれている。
【図１】
0006533345.tif 000002
【図２】
0006533345.tif 000003
【図３】
0006533345.tif 000004
【図４】
0006533345.tif 000005
【図５】
0006533345.tif 000006
【図６】
0006533345.tif 000007
【図７】
0006533345.tif 000008
【図８】
0006533345.tif 000009
【図９】
0006533345.tif 000010