JP6732185B2 - ユーザ端末及び制御方法 - Google Patents

Description

本発明は、直接的な端末間通信であるＤ２Ｄ（Ｄｅｖｉｃｅ ｔｏ Ｄｅｖｉｃｅ）通信をサポートする移動通信システムにおいて用いられるユーザ端末及び制御方法に関する。

移動通信システムの標準化プロジェクトである３ＧＰＰ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）では、リリース１２以降の新機能として、端末間（Ｄｅｖｉｃｅ ｔｏ Ｄｅｖｉｃｅ：Ｄ２Ｄ）近傍サービスの導入が検討されている（非特許文献１参照）。

Ｄ２Ｄ近傍サービス（Ｄ２Ｄ ＰｒｏＳｅ）は、同期がとられた複数のユーザ端末からなる同期クラスタ内で直接的な端末間通信を可能とするサービスである。Ｄ２Ｄ近傍サービスは、近傍端末を発見するＤ２Ｄ発見手続（ＰｒｏＳｅＤｉｓｃｏｖｅｒｙ）と、直接的な端末間通信であるＤ２Ｄ通信（ＰｒｏＳｅＣｏｍｍｕｎｉｃａｔｉｏｎ）と、を含む。

３ＧＰＰ技術報告書 「ＴＲ ３６．８４３ Ｖ１２．０．１」 ２０１４年３月２７日

一実施形態に係るユーザ端末は、直接的な端末間通信であるＤ２Ｄ（Ｄｅｖｉｃｅ ｔｏ Ｄｅｖｉｃｅ）通信をサポートする移動通信システムにおいて用いられる。ユーザ端末はコントローラを備える。コントローラは、セルカバレッジ外のユーザ端末を対象としたＤ２Ｄ発見手続を実行すると決めた場合には、事前に設定されたＤ２Ｄ通信用のリソースプールにおけるＤ２Ｄデータリソースを用いてＤ２Ｄ発見手続を実行する。前記コントローラは、前記Ｄ２Ｄ発見手続を実行するときには、前記Ｄ２Ｄデータリソースによって運ばれるデータが当該Ｄ２Ｄ発見手続のために使用されることを示す識別情報を送信する処理を実行する。

第１実施形態に係るＬＴＥシステムの構成図である。 第１実施形態に係るＵＥ（ユーザ端末）のブロック図である。 第１実施形態に係るｅＮＢ（基地局）のブロック図である。 ＬＴＥシステムにおける無線インターフェイスのプロトルスタック図である。 ＬＴＥシステムで使用される無線フレームの構成図である。 第１実施形態に係る動作環境を示す図である。 第１実施形態に係る動作状態を示す図である。 第１実施形態に係るＭＡＣヘッダの使用例を示す図である。 ＭＡＣヘッダとＭＡＣペイロードの構成を示す図である。 ＭＡＣヘッダのその他の使用例（１）を示す図である。 ＭＡＣヘッダのその他の使用例（２）を示す図である。 ＭＡＣヘッダのその他の使用例（３）を示す図である。 ＭＡＣヘッダとＭＡＣペイロードの別の構成を示す図である。 ＭＡＣヘッダとＭＡＣペイロードの更に別の構成を示す図である。 第２実施形態に係るＣｏｍｍｕｎｉｃａｔｉｏｎリソースプールを説明するための図である。 第２実施形態に係る動作状態を示す図である。 第２実施形態に係る第１のＳＣの内容を示す図である。 第２実施形態に係る第２のＳＣの内容を示す。

Ｄ２Ｄ ＰｒｏＳｅでは、同期がとられた複数のユーザ端末がセルカバレッ外に位置するシナリオ（Ｏｕｔｏｆｃｏｖｅｒａｇｅ）が想定されている。かかるシナリオでは、セルカバレッジ外に位置する複数のユーザ端末が、ネットワークを介さずに直接的に端末間通信を実行する。このため、このシナリオにおける最適な運用のために、複数のユーザ端末間で効率良くＤ２Ｄ発見手続が行われることが望まれている。

そこで、本実施形態は、同期がとられた複数のユーザ端末がセルカバレッジ外に位置する場合に効率の良いＤ２Ｄ発見手続を実現可能なユーザ端末及び制御方法を提供する。

［第１実施形態の概要］
第１実施形態に係るユーザ端末は、直接的な端末間通信であるＤ２Ｄ（Ｄｅｖｉｃｅ ｔｏ Ｄｅｖｉｃｅ）通信をサポートする移動通信システムにおいて用いられる。ユーザ端末は、コントローラを備える。前記コントローラは、セルカバレッジ外のユーザ端末を対象としたＤ２Ｄ発見手続きを実行すると決めた場合には、事前に設定されたＤ２Ｄ通信用のリソースプールにおけるＤ２Ｄデータリソースを用いてＤ２Ｄ発見手続を実行する。前記コントローラは、前記Ｄ２Ｄ発見手続を実行するときには、前記Ｄ２Ｄデータリソースによって運ばれるデータが当該Ｄ２Ｄ発見手続のために使用されることを示す識別情報を送信する処理を実行する。

第１実施形態では、前記データは、ＭＡＣ（Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）レイヤにおけるデータであり、前記識別情報は、ＭＡＣヘッダにおける第１のフィールドにおいて構成される。

第１実施形態では、前記ＭＡＣヘッダは、第２のフィールドにおいて、前記データが前記Ｄ２Ｄ発見手続のために使用される最後のデータであるか否かを示す第１の拡張情報を構成する。

第１実施形態では、前記ＭＡＣヘッダは、特定のユーザ端末を対象としたＤ２Ｄデータ送信のために、自ユーザ端末の識別情報を示す第３のフィールド及び前記特定のユーザ端末の識別情報を示す第４のフィールドを構成可能であり、前記ＭＡＣヘッダは、更に、前記第３のフィールド及び前記第４のフィールドの存在の有無を示す第２の拡張情報を、第５のフィールドにおいて構成可能である。

第１実施形態では、前記ＭＡＣヘッダは、前記第４のフィールドのオクテッド数を、前記Ｄ２Ｄデータリソースを用いたＤ２Ｄ発見手続が実行されない場合に構成される第６のフィールドのオクテッド数よりも多く設定し、前記第６のフィールドは、データの送信先ユーザ端末の識別情報を構成する。

第２実施形態では、前記データは、ＭＡＣレイヤよりも下位のレイヤにおいて運ばれるデータである。前記識別情報は、前記Ｄ２Ｄ通信用のリソースプールにおける制御情報用の時間・周波数リソース領域において運ばれる情報である。

第２実施形態では、前記識別情報は、明示的な情報である。

第２実施形態では、前記識別情報は、特定のＭＣＳ（Ｍｏｄｕｌａｔｉｏｎ ａｎｄ Ｃｏｄｉｎｇ Ｓｃｈｅｍｅ）によって暗黙的に示される情報である。

第１実施形態に係る制御方法は、直接的な端末間通信であるＤ２Ｄ（Ｄｅｖｉｃｅ ｔｏ Ｄｅｖｉｃｅ）通信をサポートする移動通信システムにおいて用いられるユーザ端末における制御方法である。ユーザ端末は、セルカバレッジ外のユーザ端末を対象としたＤ２Ｄ発見手続を実行する場合、事前に設定されたＤ２Ｄ通信用のリソースプールにおけるＤ２Ｄデータリソースを用いてＤ２Ｄ発見手続を実行する。ユーザ端末は、前記Ｄ２Ｄ発見手続を実行するときには、前記Ｄ２Ｄデータリソースによって運ばれるデータが当該Ｄ２Ｄ発見手続のために使用されることを示す識別情報を送信する。

［第１実施形態］
以下において、本発明をＬＴＥシステムに適用する場合の実施形態を説明する。

（システム構成）
図１は、第１実施形態に係るＬＴＥシステムの構成図である。図１に示すように、第１実施形態に係るＬＴＥシステムは、ＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）１００、Ｅ−ＵＴＲＡＮ（Ｅｖｏｌｖｅｄ Ｕｎｉｖｅｒｓａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）１０、及びＥＰＣ（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｃｏｒｅ）２０を備える。

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

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

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

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

図２は、ＵＥ１００のブロック図である。図２に示すように、ＵＥ１００は、アンテナ１０１、無線送受信機１１０、ユーザインターフェイス１２０、ＵＩＣＣ（Ｕｎｉｖｅｒｓａｌ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ Ｃａｒｄ）１３０、バッテリ１４０、メモリ１５０、及びプロセッサ１６０を備える。メモリ１５０は記憶部に相当し、プロセッサ１６０は制御部（コントローラ）に相当する。また、メモリ１５０をプロセッサ１６０と一体化し、このセット（すなわち、チップセット）を、制御部を構成するプロセッサ１６０’（コントローラ）としてもよい。コントローラは、後述する各種の処理及び各種の通信プロトコルを実行する。

アンテナ１０１及び無線送受信機１１０は、無線信号の送受信に用いられる。無線送受信機１１０は、プロセッサ１６０が出力するベースバンド信号（送信信号）を無線信号に変換してアンテナ１０１から送信する。また、無線送受信機１１０は、アンテナ１０１が受信する無線信号をベースバンド信号（受信信号）に変換してプロセッサ１６０に出力する。無線送受信機１１０及びプロセッサ１６０は、送信部及び受信部を構成する。

無線送受信機１１０は、複数の送信機及び／又は複数の受信機を含んでもよい。実施形態では無線送受信機１１０が１つの送信機及び１つの受信機のみを含むケースを主として想定する。

ユーザインターフェイス１２０は、ＵＥ１００を所持するユーザとのインターフェイスであり、例えば、ディスプレイ、マイク、スピーカ、及び各種ボタンなどを含む。ユーザインターフェイス１２０は、ユーザからの操作を受け付けて、該操作の内容を示す信号をプロセッサ１６０に出力する。

ＵＩＣＣ１３０は、加入者情報を記憶する着脱可能な記憶媒体である。ＵＩＣＣ１３０は、ＳＩＭ（Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｙ Ｍｏｄｕｌｅ）又はＵＳＩＭ（Ｕｎｉｖｅｒｓａｌ ＳＩＭ）と称されることがある。ＵＩＣＣ１３０は、後述する「Ｐｒｅ−ｃｏｎｆｉｇｕｒｅｄパラメータ」を記憶する。

バッテリ１４０は、ＵＥ１００の各ブロックに供給すべき電力を蓄える。ＵＥ１００がカード型端末である場合、ＵＥ１００は、ユーザインターフェイス１２０及びバッテリ１４０を備えていなくてもよい。

メモリ１５０は、プロセッサ１６０により実行されるプログラム、及びプロセッサ１６０による処理に使用される情報を記憶する。

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

図３は、ｅＮＢ２００のブロック図である。図３に示すように、ｅＮＢ２００は、アンテナ２０１、無線送受信機２１０、ネットワークインターフェイス２２０、メモリ２３０、及びプロセッサ２４０（コントローラ）を備える。尚、メモリ２３０をプロセッサ２４０と一体化し、このセット（すなわち、チップセット）を、制御部を構成するプロセッサ２４０’（コントローラ）としてもよい。

アンテナ２０１及び無線送受信機２１０は、無線信号の送受信に用いられる。無線送受信機２１０は、プロセッサ２４０が出力するベースバンド信号（送信信号）を無線信号に変換してアンテナ２０１から送信する。また、無線送受信機２１０は、アンテナ２０１が受信する無線信号をベースバンド信号（受信信号）に変換してプロセッサ２４０に出力する。無線送受信機２１０及びプロセッサ２４０は、送信部及び受信部を構成する。

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

メモリ２３０は、プロセッサ２４０により実行されるプログラム、及びプロセッサ２４０による処理に使用される情報を記憶する。

プロセッサ２４０は、ベースバンド信号の変調・復調及び符号化・復号などを行うベースバンドプロセッサと、メモリ２３０に記憶されるプログラムを実行して各種の処理を行うＣＰＵと、を含む。プロセッサ２４０は、後述する各種の処理及び各種の通信プロトコルを実行する。

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

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

ＭＡＣ層は、データの優先制御、及びハイブリッドＡＲＱ（ＨＡＲＱ）による再送処理などを行う。ＵＥ１００のＭＡＣ層とｅＮＢ２００のＭＡＣ層との間では、トランスポートチャネルを介してユーザデータ及び制御信号が伝送される。ｅＮＢ２００のＭＡＣ層は、上下リンクのトランスポートフォーマット（トランスポートブロックサイズ、変調・符号化方式）、ＵＥ１００への割当リソースブロックを決定（スケジューリング）するスケジューラを含む。

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

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

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

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

ＵＥ１００において、物理層乃至ＲＲＣ層は、ＡＳ（Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）エンティティ１００Ａを構成する。ＮＡＳ層は、ＮＡＳエンティティ１００Ｂを構成する。ＡＳエンティティ１００Ａ及びＮＡＳエンティティ１００Ｂの機能はプロセッサ１６０（制御部）により実行される。すなわち、プロセッサ１６０（制御部）は、ＡＳエンティティ１００Ａ及びＮＡＳエンティティ１００Ｂを含む。アイドルモードにおいて、ＡＳエンティティ１００Ａはセル選択／再選択を行い、ＮＡＳエンティティ１００ＢはＰＬＭＮ選択を行う。

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

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

（Ｄ２Ｄ発見手続の概要）
以下において、第１実施形態に係るＤ２Ｄ近傍サービスについて、Ｄ２Ｄ発見手続を主として説明する。第１実施形態に係るＬＴＥシステムは、Ｄ２Ｄ近傍サービスをサポートする。

Ｄ２Ｄ近傍サービス（Ｄ２Ｄ ＰｒｏＳｅ）は、同期がとられた複数のＵＥ１００からなる同期クラスタ内で直接的なＵＥ間通信を可能とするサービスである。Ｄ２Ｄ近傍サービスは、近傍ＵＥを発見するＤ２Ｄ発見手続（ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ）と、直接的なＵＥ間通信であるＤ２Ｄ通信（ＰｒｏＳｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）と、を含む。Ｄ２Ｄ通信は、Ｄｉｒｅｃｔ ｃｏｍｍｕｎｉｃａｔｉｏｎと称されてもよい。

同期クラスタを形成する全ＵＥ１００がセルカバレッジ内に位置するシナリオを「カバレッジ内（Ｉｎ ｃｏｖｅｒａｇｅ）」という。同期クラスタを形成する全ＵＥ１００がセルカバレッジ外に位置するシナリオを「カバレッジ外（Ｏｕｔ ｏｆ ｃｏｖｅｒａｇｅ）」という。同期クラスタのうち一部のＵＥ１００がセルカバレッジ内に位置し、残りのＵＥ１００がセルカバレッジ外に位置するシナリオを「部分的カバレッジ（Ｐａｒｔｉａｌ ｃｏｖｅｒａｇｅ）」という。

Ｄ２Ｄ発見手続は、カバレッジ内、カバレッジ外及び部分的カバレッジにおいて行われることが想定される。

第１実施形態では、図６に示す、「カバレッジ外」でのシナリオについて説明する。図６は、第１実施形態に係る動作環境を示す図である。

図６では、ｅＮＢ２００のカバレッジ外において、ＵＥ１００−１とＵＥ１００−２とＵＥ１００−３とがＤ２Ｄ近傍サービスを利用している状態を示している。尚、図６では３台のＵＥ１００を示しているが、少なくとも２台以上であればよい。

図６では、ＵＥ１００−１が同期元であり、ＵＥ１００−２とＵＥ１００−３が非同期元であるものとする。ＵＥ１００−１とＵＥ１００−２とＵＥ１００−３は、ＵＥ１００−１を同期元として互いに同期しているものとする。ＵＥ１００−１とＵＥ１００−２とＵＥ１００−３は、互いに同期している状態でＤ２Ｄ発見手続を実行する。

Ｄ２Ｄ発見手続では、各ＵＥ１００（ＵＥ１００−１，ＵＥ１００−２，ＵＥ１００−３）が、近傍端末を発見するためのＤ２Ｄ発見信号（Ｄｉｓｃｏｖｅｒｙ信号）を送信する。

Ｄ２Ｄ発見手続の方式として、ＵＥ１００に固有に割り当てられない無線リソースがＤ２Ｄ発見信号の送信に使用される第１の方式（Ｔｙｐｅ １ ｄｉｓｃｏｖｅｒｙ）と、ＵＥ１００毎に固有に割り当てられる無線リソースがＤ２Ｄ発見信号の送信に使用される第２の方式（Ｔｙｐｅ ２ ｄｉｓｃｏｖｅｒｙ）とがある。

第１の方式では、Ｄ２Ｄ発見信号の伝送のためにＤ２Ｄ発見信号用のリソースプールが使用される。Ｄ２Ｄ発見信号用のリソースプールは、同期がとられた複数のＵＥ１００からなる同期クラスタ内で共有される。

また、Ｄ２Ｄ通信のために２つの動作モード（Ｍｏｄｅ１／Ｍｏｄｅ２）が定義される。Ｍｏｄｅ１では、ｅＮＢ２００又は図示しないリレーノードが、Ｄ２Ｄデータ（Ｄ２Ｄデータ及び／又は制御データ）を送信するための無線リソースを割り当てる。Ｍｏｄｅ２では、ＵＥ１００自身が、Ｄ２Ｄデータ（Ｄ２Ｄデータ及び／又は制御データ）を送信するための無線リソースをリソースプールから選択する。

第１実施形態においては、Ｄ２Ｄ通信のＭｏｄｅ２の動作を利用して、Ｄ２Ｄ発見手続が実行される場合の例を想定している。つまり、第１実施形態では、ＵＥ１００−１が、「カバレッジ外」においてＭｏｄｅ−２によるＤ２Ｄ通信を行う他、Ｄ２Ｄ通信用のリソースプールにおいて、Ｄ２Ｄ発見信号を伝送するというシナリオを想定している。このシナリオは、「Ｄｉｓｃｏｖｅｒｙ ｔｈｒｏｕｇｈ Ｃｏｍｍｕｎｉｃａｔｉｏｎ （ＤｔＣ） ｆｏｒ ｏｕｔ ｏｆ ｃｏｖｅｒａｇｅ」と称され得る。以下、説明の便宜上、適宜「カバレッジ外でのＤＴＣシナリオ」と称する。

カバレッジ外でのＤＴＣシナリオでは、上記に示したＤ２Ｄ通信用のリソースプールの構成等が事前設定（ｐｒｅ−ｃｏｎｆｉｇｕｒｅｄ）される。事前設定されたパラメータを以下、「Ｐｒｅ−ｃｏｎｆｉｇｕｒｅｄパラメータ」という。尚、Ｐｒｅ−ｃｏｎｆｉｇｕｒｅｄパラメータに含まれる情報要素は、同一の目的（軍事、消防、警察など）に使用されるＵＥには、同一のｐｒｅ−ｃｏｎｆｉｇｕｒｅｄパラメータが設定される。

尚、Ｄ２Ｄ通信用のリソースプールは、制御情報用リソースプールとデータ用リソースプールから構成される。各リソースプールの構成を示す情報は、無線フレームにおいて最初にＤ２Ｄ通信用のリソースプールが構成される時間・周波数領域を特定するパラメータ（開始位置指定用のオフセット値）と、Ｄ２Ｄ通信用のリソースプールにおける周波数方向リソースを指定するパラメータ（周波数方向リソース指定パラメータ）と、該Ｄ２Ｄ通信用のリソースプールの繰り返し周期（ｐｅｒｉｏｄ）と、特定のサブフレームがＤ２Ｄ通信のために使用可能である時間・周波数リソースかどうかを示す情報（ビットマップ情報）と、を含む。

Ｐｒｅ−ｃｏｎｆｉｇｕｒｅｄパラメータは、ＵＥ１００に提供される。ここでは、Ｐｒｅ−ｃｏｎｆｉｇｕｒｅｄパラメータがＵＥ１００のＵＩＣＣ１３０に予め記憶されているものとする。尚、Ｐｒｅ−ｃｏｎｆｉｇｕｒｅｄパラメータは、ＵＩＣＣ１３０に予め記憶されない場合には、ＵＥ１００が所定の機会にｅＮＢを介してネットワーク（ＯＡＭ等）から提供を受けることにより、メモリ１５０に記憶されてもよい。

（カバレッジ外でのＤＴＣシナリオにおけるＤ２Ｄ発見手続について）
上述したように、カバレッジ外にいる同期クラスタを構成する複数のＵＥ１００は、Ｍｏｄｅ２でＤ２Ｄ通信を実行し得る。この場合、各ＵＥ１００は、Ｄ２Ｄ通信用のリソースプールにおける時間・周波数リソースを使って、Ｃｏｍｍｕｎｉｃａｔｉｏｎデータを送信できる。ここで、送信側のＵＥ１００が、Ｄ２Ｄ発見手続を実行する場合、Ｄ２Ｄ通信用のリソースプールにおける時間・周波数リソースを使って、Ｄ２Ｄ発見信号を送信しなければならない。そうすると、受信側のＵＥ１００は、受信した信号がＤ２Ｄ発見信号なのかＣｏｍｍｕｎｉｃａｔｉｏｎデータ用の信号なのかの区別がつかない事態が想定される。

このため、上記に示した事態を回避すること、つまり、カバレッジ外でのＤＴＣシナリオにおいて、複数のユーザ端末間で効率良くＤ２Ｄ発見手続が行われる技術が要求される。以下、その技術について説明する。

（第１実施形態の動作説明）
以下、図７乃至図１４に基づいて、第１実施形態の動作内容について説明する。図７は、第１実施形態に係る動作状態を示す。図８は、第１実施形態に係るＭＡＣヘッダの使用例を示す。図９は、ＭＡＣヘッダとＭＡＣペイロードの構成を示す。図１０は、ＭＡＣヘッダのその他の使用例（１）を示す。図１１は、ＭＡＣヘッダのその他の使用例（２）を示す。図１２は、ＭＡＣヘッダのその他の使用例（３）を示す。図１３は、ＭＡＣヘッダとＭＡＣペイロードの別の構成を示す。図１４は、ＭＡＣヘッダとＭＡＣペイロードの更に別の構成を示す。尚、ＵＥ１００が実行する処理については、該ＵＥ１００のコントローラ１６０（１６０’）が処理を実行するが、図７乃至１４の説明においては、便宜上、ＵＥ１００が行うものとして説明する。

前提として、複数のＵＥ１００（ＵＥ１００−１〜Ｎ｛Ｎ≧２｝）は、ＵＥ１００−１が同期元であり、その他のＵＥ１００（ＵＥ１００−２〜Ｎ）が非同期元である。複数のＵＥ１００（ＵＥ１００−１〜Ｎ）は、ＵＥ１００−１を同期元として互いに同期している。

ここで、複数のＵＥ１００の各ＵＥ１００は、Ｄ２Ｄ通信用のリソースプールの構成を示す情報を含むＰｒｅ−ｃｏｎｆｉｇｕｒｅｄパラメータを予めＵＩＣＣ１３０に記憶している。

図７において、ＵＥ１００は、カバレッジ外において、Ｍｏｄｅ２でＤ２Ｄ通信を実行可能であるときに、Ｄ２Ｄ通信用リソースプールにおいてＤ２Ｄ発見信号（Ｄｉｓｃｏｖｅｒｙ 信号）を送信すると決める（ステップＳ１０１）。

次に、ＵＥ１００の図示しないＭＡＣエンティティは、ＭＡＣレイヤにおける情報を生成する。ＭＡＣエンティティは、Ｄｉｓｃｏｖｅｒｙ用（Ｄ２Ｄ発見手順用）の制御情報を構成したＭＡＣヘッダ及びＤｉｓｃｏｖｅｒｙ用のＭＡＣペイロードを生成する（ステップＳ１０２）。

図８及び図９は、ステップＳ１０２においてＭＡＣエンティティによって生成されたＭＡＣ ＰＤＵ（Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ）におけるＭＡＣヘッダ及びＭＡＣペイロードの一例を示している。図８において、オクテッド１の「ｖ」フィールドでは、通信システムのバージョンを示す。尚、「ｖ」フィールドでは、通信システムのバージョン以外の情報を示してよい。

「ｖ」フィールドに続く「Ｃ／Ｄ」フィールドは、Ｄ２Ｄデータリソースによって運ばれるデータ（第１実施形態ではＭＡＣペイロード）が、Ｃｏｍｍｕｎｉｃａｔｉｏｎ用として使用されるのか、Ｄｉｓｃｏｖｅｒｙ用として使用されるのかを示す１ビット（「０」か「１」）からなる識別情報である。図８の「Ｃ／Ｄ」フィールドは「１」を示している。この場合の「１」は、後のフィールドに格納されるＭＡＣペイロードがＤｉｓｃｏｖｅｒｙ用として使用されることを示す。尚「Ｃ／Ｄ」フィールドが「０」の場合は、後のフィールドに格納されるＭＡＣペイロードがＣｏｍｍｕｎｉｃａｔｉｏｎ用として使用されることを示す。

「Ｃ／Ｄ」フィールドに続く「Ｘ」フィールドは、特定のユーザ端末１００を対象としたＣｏｍｍｕｎｉｃａｔｉｏｎデータ送信のために、自ユーザ端末１００の識別情報（ソースＵＥのＩＤ）を示す「ＳＲＣ」フィールド（図１０参照）及び特定のユーザ端末１００の識別情報（ターゲットＵＥのＩＤ）を示す「ＤＳＴ」フィールド（図１０）が、後のフィールドに格納されるか否かを示す１ビット（「０」か「１」）からなる拡張情報である。図８の「Ｘ」フィールドは、いずれも「０」を示している。この場合の「０」は、後のフィールドに「ＳＲＣ」フィールドと「ＤＳＴ」フィールドが構成されないことを示す。尚、「Ｘ」フィールドが「１」の場合には、図１０に示すように、後のフィールドにおいて「ＳＲＣ」フィールドと「ＤＳＴ」フィールドが構成される。

「Ｒ」フィールドは、リザーブ用のフィールドである。

「Ｙ」フィールドは、後のフィールドに格納されるＭＡＣペイロードがＤｉｓｃｏｖｅｒｙ用あるいはＣｏｍｍｕｎｉｃａｔｉｏｎ用として使用されるペイロードとして最後のペイロードであるか否かを示す拡張情報である。図８のオクテッド１とオクテッド２の「Ｙ」フィールドは、「１」を示している。この場合の「１」は、後のフィールドに格納されるＭＡＣペイロードがＤｉｓｃｏｖｅｒｙ用として使用されるペイロードとして最後のペイロードではなく、後のフィールドに格納されるＭＡＣペイロードが引き続き別のＤｉｓｃｏｖｅｒｙ用に使用されることを示す。図８のオクテッド３の「Ｙ」フィールドは、「０」を示している。この場合の「０」は、後のフィールドに格納されるＭＡＣペイロードがＤｉｓｃｏｖｅｒｙ用として使用されるペイロードとして最後のペイロードであることを示す。

図８の例は、３つのＤｉｓｃｏｖｅｒｙ用のＭＡＣペイロード（Ｄｉｓｃｏｖｅｒｙ｛Ａ｝，｛Ｂ｝，｛Ｃ｝）が格納されるＭＡＣＰＤＵの構成を示す。図１０の例は、一つのＭＡＣ ＰＤＵにおいて、１つのＤｉｓｃｏｖｅｒｙ用のＭＡＣペイロード（Ｄｉｓｃｏｖｅｒｙ｛Ａ｝）と特定のユーザ端末１００のためのＤａｔａ（Ｄａｔａ｛Ａ｝）が格納される構成を示す。

図７において、ステップＳ１０２にてＵＥ１００のＭＡＣエンティティが、図８に示したようなＭＡＣヘッダ及びＭＡＣペイロードを生成すると、生成した情報をＵＥ１００のＰＨＹレイヤに送る（ステップＳ１０３）。

ＵＥ１００のＰＨＹレイヤは、ＭＡＣレイヤからの上記情報を、事前に設定されたＤ２Ｄ通信用のリソースプールにおけるＤ２Ｄ通信用の時間・周波数リソース（無線リソース）を用いて送信する処理を実行する（ステップＳ１０４）。

ステップＳ１０４によって送信されたデータを受信した受信側ＵＥ１００は、ＭＡＣレイヤにおいて、図８（図１０）に示した「Ｃ／Ｄ」フィールド、「Ｘ」フィールド、及び「Ｙ」フィールドに示されたビット情報を認識する。受信側ＵＥ１００は、上述した各フィールドが示す情報の意味合いを理解してその後の処理を実行する。

尚、図１０の例は、Ｄ２Ｄ発見手続とＤ２Ｄ通信とが同時に実行される場合に適用される。図１０の例では、オクテッド２〜８のデータ用のサブヘッダ（ＳＬ‐ＳＣＨサブヘッダ）の後のフィールドに、セルラ通信でも利用されている「ＭＡＣ ＣＥ用のｓｕｂｈｅａｄｅｒ」と「ＭＡＣ ＳＤＵ用のｓｕｂｈｅａｄｅｒ」とを構成する。

また、図１０の例では、「ＳＲＣ」フィールドと「ＤＳＴ」フィールドが構成される例を示しているが、この場合の「ＤＳＴ」フィールドのオクテッド数は、通常のＤ２Ｄ通信シナリオの場合（Ｄ２Ｄデータリソースを用いたＤ２Ｄ発見手続が実行されない場合）に構成される「ＤＳＴ」フィールドのオクテッド数よりも多く設定されてもよい。通常のＤ２Ｄ通信シナリオの場合に構成される「ＤＳＴ」フィールドのオクテッド数が「２」（１６ビット分）であるとした場合に、図１０の例では、「ＤＳＴ」フィールドのオクテッド数を「３」（２４ビット分）としている。尚、この場合「ＤＳＴ」フィールドのオクテッド数は「３」以上であればよい。ちなみに、「ＤＳＴ」フィールドを拡張する理由は次の通りである。

まず、通常のＤ２Ｄ通信のシナリオでは、送信側のＵＥ１００は、ＳＣ（Ｓｉｄｅｌｉｎｋ Ｃｏｎｔｒｏｌ）リソースプールを用いて、ターゲットＵＥ１００の識別情報（ターゲットＵＥ−ＩＤ）を送ることができる。しかしながら、ＤＴＣシナリオにおいてＤ２Ｄ発見手続が実行される場合には、ＳＣリソースプールを用いたターゲットＵＥの識別情報の送信が省略される。これは、Ｄ２Ｄ発見信号はブロードキャスト信号であるため、送信側のＵＥ１００がターゲットＵＥを特定することなくＤ２Ｄ発見信号を送信できることによる。このため、ＤＴＣシナリオにおいて、特定のＵＥ１００用にＣｏｍｍｕｎｉｃａｔｉｏｎデータを送信しようとする場合、「ＤＳＴ」フィールドのオクテッド数を増やすことによって、特定のＵＥ１００に対してターゲットＵＥの識別情報を取得させる機会を確保できる。このため、特定のＵＥ１００以外のＵＥ１００は、「ＤＳＴ」フィールドに格納されたターゲットＵＥ−ＩＤが自ＵＥ用のＩＤではないことを認識した場合には、その後のＭＡＣペイロードを破棄できる。また、特定のＵＥ１００は、「ＤＳＴ」フィールドに格納されたターゲットＵＥ−ＩＤが自ＵＥ用のＩＤであることを認識できたならば、その後のＭＡＣペイロードの受信動作を実行することができる。

（ＭＡＣヘッダのその他の使用例）
図１１及び図１２は、ＭＡＣヘッダのその他の使用例を示す。図１１の例は、上述したＤｉｓｃｏｖｅｒｙ用のＭＡＣペイロードを送信できる能力を有したＵＥ１００が、所定の期間においてＣｏｍｍｕｎｉｃａｔｉｏｎデータを送信する場合のフィールドの内容を示す。各フィールドの内容は上述した通りである。尚、図１１の例では、後述するＳｉｄｅｌｉｎｋ用制御情報（Ｓｉｄｅｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ：ＳＣＩ）においてブロードキャスト用のＩＤが使用されているため、ＭＡＣヘッダ内の「ＤＳＴ」フィールドにターゲットＵＥのＩＤ（送り先ＩＤ）を省略せずに格納する。

図１２の例にて、ＭＡＣ ＰＤＵにおいて複数の宛先のデータが格納されている場合の、各データの認識方法について説明する。ＵＥ１００のＭＡＣエンティティは、Ｃｏｍｍｕｎｉｃａｔｉｏｎデータ用のＭＡＣサブヘッダ（Ｏｃｔ２〜Ｏｃｔ８）において、Ｏｃｔ ２の「Ｙ」フィールドにて、以降に別の宛先のＣｏｍｍｕｎｉｃａｔｉｏｎデータ用のＭＡＣサブヘッダが存在する旨（Ｙ ＝ １）を理解する。次に、ＵＥ１００のＭＡＣエンティティは、更に続くＭＡＣ ＳＤＵ指定用のＭＡＣサブヘッダ（Ｏｃｔ１１〜１２）において、以降にＭＡＣ ＳＤＵもしくはＭＡＣ ＣＥ指定用のＭＡＣサブヘッダの有無を示す、Ｏｃｔ １１の「Ｅ」フィールドにて、以降にＭＡＣ ＳＤＵもしくはＭＡＣ ＣＥを指定するＭＡＣサブヘッダが存在しない旨（Ｅ＝０）を理解する。そうすると、ＵＥ１００のＭＡＣエンティティは、次のオクテットから別の宛先のＣｏｍｍｕｎｉｃａｔｉｏｎデータ用のＭＡＣサブヘッダ（Ｏｃｔ １３〜１９）が格納されていると認識する。

更に、ＵＥ１００のＭＡＣエンティティは、Ｃｏｍｍｕｎｉｃａｔｉｏｎデータ用のＭＡＣサブヘッダ（Ｏｃｔ１３〜１９）において、Ｏｃｔ １３の「Ｙ」フィールドにて、以降に別の宛先のＣｏｍｍｕｎｉｃａｔｉｏｎデータ用のＭＡＣサブヘッダが存在しない旨（Ｙ ＝ ０）を理解する。ＵＥ１００のＭＡＣエンティティは、更に続くＭＡＣ ＳＤＵ指定用のＭＡＣサブヘッダ（Ｏｃｔ２０〜２１）の「Ｅ」フィールドにて、以降にＭＡＣ ＳＤＵもしくはＭＡＣ ＣＥを指定するＭＡＣサブヘッダが存在しない旨（Ｅ＝０）を理解する。そうすると、ＵＥ１００のＭＡＣエンティティは、次のオクテットからＭＡＣ ＳＤＵ、もしくはＭＡＣ ＣＥが格納されると認識する。図１２においては、ＭＡＣヘッダの最初に格納されたｄｉｓｃｏｖｅｒｙ用のＭＡＣサブヘッダに対応するＤｉｓｃｏｖｅｒｙ （Ａ）が格納されていると認識する。

図１３の例にて、送信元ＵＥ１００が、複数の宛先ＵＥ１００に向けたＭＡＣ制御情報（ＭＡＣ Ｃｏｎｔｒｏｌ Ｅｌｅｍｅｎｔ （ＭＡＣ ＣＥ））をＭＡＣ ＰＤＵに格納する方法について説明する。送信元ＵＥ１００は、特定のＵＥ１００を指定せず、ＭＡＣ ＣＥを通知したい場合には、Ｄｉｓｃｏｖｅｒｙ用のＭＡＣ ｓｕｂｈｅａｄｅｒの後に、ＭＡＣ ＣＥ用のＭＡＣサブヘッダを格納する。送信元ＵＥ１００は、特定のユーザに対して、ＭＡＣ ＣＥを通知したい場合、特定の宛先ＵＥ１００のＣｏｍｍｕｎｉｃａｔｉｏｎデータ用のＭＡＣサブヘッダの後に、ＭＡＣ ＣＥを格納する。受信側（送信先）のＵＥ１００は、同時に二つのＭＡＣ ＣＥを受け取った場合、受信側のＵＥ１００の判断で片方のＭＡＣ ＣＥを利用してもよいし、特定の宛先ＵＥ１００向けに通知されたＭＡＣ ＣＥを優先して利用してもよい。

図１４の例は、送信元ＵＥ１００が、複数の宛先ＵＥ１００に向けてＣｏｍｍｕｎｉｃａｔｉｏｎ用のデータを送信する際の、より効率的なＭＡＣ ＰＤＵの伝送方法を示す。Ｃｏｍｍｕｎｉｃａｔｉｏｎ用のデータを指定するＭＡＣサブヘッダには、送信元ＵＥ１００を示す識別子であるＳＲＣが含まれる。そのため、送信元ＵＥ１００が、複数の宛先ＵＥ１００用のＣｏｍｍｕｎｉｃａｔｉｏｎデータをＭＡＣ ＰＤＵにおいて多重する場合には、送信元ＵＥ１００は、ある宛先ＵＥ１００のＣｏｍｍｕｎｉｃａｔｉｏｎデータを指定するＭＡＣサブヘッダでＳＲＣを通知し、それ以外の別の宛先のＣｏｍｍｕｎｉｃａｔｉｏｎデータを指定するＭＡＣサブヘッダでは、ＳＲＣを省略することで、ＭＡＣサブヘッダに利用されるオクテット数を削減してもよい。

（第１実施形態の変形例）
上述した第１実施形態では、ＭＡＣヘッダに「Ｃ／Ｄ」フィールドを構成し、該「Ｃ／Ｄ」フィールドに、後のフィールドに格納されるＭＡＣペイロードがＤｉｓｃｏｖｅｒｙ用として使用されるペイロードであることを示す識別情報を格納したが、このような「Ｃ／Ｄ」フィールドを構成せずに、「ｖ」フィールドで示されるバージョン情報によって間接的に、後のフィールドに格納されるＭＡＣペイロードがＤｉｓｃｏｖｅｒｙ用として使用されるペイロードであることを示してもよい。つまり、「ｖ」フィールドで示されるバージョン情報が最新のバージョンを示す場合には、後のフィールドに格納されるＭＡＣペイロードがＤｉｓｃｏｖｅｒｙ用として使用されるペイロードであることを示す、という取り決めを予め定義しておけばよい。

（第１実施形態のまとめ）
第１実施形態では、上述したように、ＵＥ１００は、ＭＡＣヘッダに、後のフィールドに格納されるＭＡＣペイロードがＤｉｓｃｏｖｅｒｙ用として使用されるペイロードであることを示す識別情報を格納する。加えて、ＵＥ１００は、該識別情報の後のフィールドのＭＡＣペイロードをＤｉｓｃｏｖｅｒｙ用としたデータを生成し、生成したデータを事前に設定されたＤ２Ｄ通信用のリソースプールにおけるＤ２Ｄデータリソースを用いて送信することができる。受信側のＵＥ１００は、前記識別情報によって、受信したＭＡＣペイロードがＤｉｓｃｏｖｅｒｙ用として使われていることを理解できる。このため、カバレッジ外でのＤＴＣシナリオにおいて、複数のユーザ端末間で効率良くＤ２Ｄ発見手続が行われる。

［第２実施形態］
次に、図１５乃至図１８を用いて第２実施形態について説明する。第１実施形態と同様の部分は、説明を適宜省略する。図１５は、第２実施形態に係るＣｏｍｍｕｎｉｃａｔｉｏｎリソースプールを説明するための図である。図１６は、第２実施形態に係る動作状態を示す図である。図１７は、第２実施形態に係る第１のＳＣの内容を示す図である。図１８は、第２実施形態に係る第２のＳＣの内容を示す。

第１実施形態では、ＵＥ１００が、ＭＡＣヘッダに、後のフィールドに格納されるＭＡＣペイロードがＤｉｓｃｏｖｅｒｙ用として使用されるペイロードであることを示す識別情報を格納する例について説明した。これに対して、第２実施形態では、事前に設定されたＣｏｍｍｕｎｉｃａｔｉｏｎリソースプールのＳＣ（Ｓｉｄｅｌｉｎｋ Ｃｏｎｔｒｏｌ）リソースプールにおいて、データプール（Ｄ２Ｄデータリソース）で運ばれるデータがＤ２Ｄ発見手続のために使用されることを示す識別情報を構成する例について示す。尚、リソースプールとは、所定量（数）の時間・周波数リソースから構成される時間・周波数リソース群を意味する。

まず、Ｃｏｍｍｕｎｉｃａｔｉｏｎリソースプールについて、図１５を用いて説明する。Ｃｏｍｍｕｎｉｃａｔｉｏｎリソースプールは、Ｓｉｄｅｌｉｎｋ用制御情報（Ｓｉｄｅｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ：ＳＣＩ）の送受信に使用可能な無線リソースのプールであるＳＣリソースプール（ＳＣＰｏｏｌ）と、Ｄ２Ｄ通信のデータの送受信に使用可能な無線リソースのプールであるデータリソースプール（ＤａｔａＰｏｏｌ）とからなる。

ＵＥ１００は、時間方向に周期的に配置されるデータリソースプール（データ領域：Ｄａｔａ Ｒｅｇｉｏｎ）内の時間・周波数リソースの中から、データの送信に用いる無線リソースを選択する。例えば、ＵＥ１００は、時間方向において同一データを送信するタイミングをランダムに設定していた場合、データ領域の前半の時間・周波数リソースの中から、４つのサブフレームをランダムに選択し、データ領域の後半の時間・周波数リソースの中から、４つのサブフレームをランダムに選択する。ＵＥ１００は、選択した８つのサブフレームを用いて、データを送信する。或いは、ＵＥ１００は、データ領域の前半の時間・周波数リソースの中から選択した４つのサブフレームを用いて、データを繰り返し送信し、データ領域の前半の時間・周波数リソースの中から選択した４つのサブフレームを用いて、別のデータを繰り返し送信してもよい。

図１５において、「Ｙ」は周波数方向であることを意味し、「ｔ」は時間方向であることを意味する。（ａ）は、無線フレームにおいて、ＳＣリソースプールが開始される位置を示すオフセット（ＳＣ開始位置オフセット）である。ＳＣ開始位置オフセットの範囲は０〜１０２３９サブフレームである。（ｂ）は、無線フレームにおけるＣｏｍｍｕｎｉｃａｔｉｏｎリソースプールの繰り返し周期を示す。繰り返し周期は、「４０サブフレーム」、「８０サブフレーム」、「１６０サブフレーム」あるいは「３２０サブフレーム」が適用される。（ｃ）は、無線フレームにおいて、データリソースプールが開始される位置を示すオフセット（Ｄａｔａ開始位置オフセット）である。Ｄａｔａ開始位置オフセットの範囲は０〜１０２３９サブフレームである。

ＵＥ１００は、時間方向に周期的に配置されるＳＣリソースプール内の時間・周波数リソースの中から、Ｄ２Ｄ通信によって送信されるデータ用の時間・周波数リソースの位置を示す情報（Ｓｃｈｅｄｕｌｉｎｇ Ａｓｓｉｇｎｍｅｎｔ：ＳＡ）を送信するための時間・周波数リソースを選択する。

次に、第２実施形態に係る動作状態について、図１６を用いて説明する。ＵＥ１００は、ステップＳ１０１の後、Ｄｉｓｃｏｖｅｒｙ用（Ｄ２Ｄ発見手続用）の制御情報を構成したＳｉｄｅｌｉｎｋ用制御情報（Ｓｉｄｅｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ：ＳＣＩ）及びＤｉｓｃｏｖｅｒｙ用のデータを生成する（ステップＳ１１２）。

ここで、ＳＣＩについて図１７及び図１８を用いて説明する。まず、図１７に示すように、ＳＣＩ（第１のＳＣＩ）は、ＵＥＩＤ（ＵＥ識別子）及びＭＣＳが含まれる。ＵＥＩＤは、ＳＡの送信先のＩＤ（Ｔａｒｇｅｔ ＩＤ）である。例えば、ＵＥＩＤは、８ビットのビット列である。ＵＥＩＤの最初の１ビットは、ユーザデータをブロードキャストで送信するか否かを示す情報であってもよい。これにより、ＳＡを受信したＵＥ１００は、ＳＡによって位置が示されるユーザデータが、ブロードキャスト用のユーザデータでなく、且つ、自身宛のデータでない場合、復号せずに消去することができる。

ＭＣＳは、送信データのＭＣＳ（Ｍｏｄｕｌａｔｉｏｎ ａｎｄ Ｃｏｄｉｎｇ Ｓｃｈｅｍｅ）を示す。例えば、ＭＣＳは、５ビットのビット列である。

Ｄｉｓｃｏｖｅｒｙ識別情報は、Ｃｏｍｍｕｎｉｃａｔｉｏｎリソースプールのデータプールで運ばれるデータがＤ２Ｄ発見手続のために使用されることを示す。Ｄｉｓｃｏｖｅｒｙ識別情報は、１ビットの情報である。Ｄｉｓｃｏｖｅｒｙ識別情報は、Ｃｏｍｍｕｎｉｃａｔｉｏｎリソースプールのデータプールで運ばれるデータがＤ２Ｄ発見手続のために使用されることを示す場合には「１」、そうでない場合には「０」で表わされるとしてもよい。

図１６において、ステップＳ１１２の後、ＵＥ１００は、ステップＳ１１２で生成したＳＣＩを無線送信するために、ＳＣリソースプールにおける時間・周波数リソース（無線リソース）を決める。また、ＵＥ１００は、ステップＳ１１２で生成したＤｉｓｃｏｖｅｒｙ用のデータを無線送信するためにデータリソースプールにおける時間・周波数リソース（無線リソース）を決める。その後、ＵＥ１００は、決められた無線リソースを使ってＳＣＩとＤｉｓｃｏｖｅｒｙ用のデータを送信する（ステップＳ１１３）。

ステップＳ１１３において送信されたＳＣＩとＤｉｓｃｏｖｅｒｙ用のデータを受信した受信側のＵＥ１００は、ＳＣＩに示されたＤｉｓｃｏｖｅｒｙ識別情報を認識する。受信側ＵＥ１００は、Ｄｉｓｃｏｖｅｒｙ識別情報が示す意味合いを理解してその後の処理を実行する。

（第２実施形態の変形例１）
上述した第２実施形態では、ＳＣＩにおいてＤｉｓｃｏｖｅｒｙ識別情報を構成する例を示した。この場合のＤｉｓｃｏｖｅｒｙ識別情報は明示的な情報である。これに対して、第２実施形態の変形例１では、図１８に示すように、ＳＣＩ（第２のＳＣＩ）は、Ｄｉｓｃｏｖｅｒｙ識別情報を構成しない。第２実施形態の変形例１では、ＳＣＩにおけるＵＥＩＤ（図１８の「Ｇｒｏｕｐ ｄｅｓｔｉｎａｔｉｏｎ ＩＤ」）を、Ｄｉｓｃｏｖｅｒｙ送信専用のＵＥＩＤとして定義する。この場合、Ｄｉｓｃｏｖｅｒｙ送信専用のＵＥＩＤは、当該ＳＣＩが示すデータ用の時間・周波数リソースがＤｉｓｃｏｖｅｒｙ用に使用されることを示す。この場合のＤｉｓｃｏｖｅｒｙ送信専用のＵＥＩＤは、明示的な情報と位置付け得る。尚、上述した第１のＳＣＩと本例の説明で示された第２のＳＣＩを適宜使い分けてもよい。

（第２実施形態の変形例２）
また、上述した第２実施形態及び第２実施形態の変形例１以外の例もある。例えば、図１８に示した「Ｍｏｄｕｌａｔｉｏｎ ａｎｄ ｃｏｄｉｎｇ ｓｃｈｅｍｅ」フィールドにおいて、Ｄｉｓｃｏｖｅｒｙ送信に適したＤｉｓｃｏｖｅｒｙ専用の特定ＭＣＳ（複数のＭＣＳのうち、相対的に低いレートを確保できるＭＣＳ）を示す情報を格納する。この場合の特定ＭＣＳは、データ送信用のＭＣＳと区別されるように設定される。尚、特定ＭＣＳは、暗黙的に、データ用の時間・周波数リソースがＤｉｓｃｏｖｅｒｙ用に使用されることを示す。

（第２実施形態の変形例３）
また、上述した例の他に、Ｄ２Ｄ近傍サービスのＤＴＣシナリオにおいて、特定のＣｏｍｍｕｎｉｃａｔｉｏｎリソースプールでＤ２Ｄ発見信号の伝送が許可される、というルールが事前設定（Ｐｒｅ−ｃｏｎｆｉｇｕｒｅｄ）されるならば、送信側のＵＥ１００は、特定のＣｏｍｍｕｎｉｃａｔｉｏｎリソースプールにおける時間・周波数リソースを用いてＤｉｓｃｏｖｅｒｙ用のデータを送信してもよい。この場合、受信側のＵＥ１００は、特定のＣｏｍｍｕｎｉｃａｔｉｏｎリソースプールにおける所定の時間・周波数リソースで受信したデータをＤｉｓｃｏｖｅｒｙ用のデータとして認識できる。この場合、上述したルールの有無を示すＰｒｅ−ｃｏｎｆｉｇｕｒｅｄパラメータが暗黙的な情報と位置付け得る。

（第２実施形態のまとめ）
第２実施形態及び変形例１及び２では、上述したように、ＵＥ１００は、ＳＣＩに、明示的あるいは暗黙的に、データ用の時間・周波数リソースがＤｉｓｃｏｖｅｒｙ用に使用されることを示して送信した。この場合、受信側のＵＥ１００は、受信したＳＣＩが示すデータ用の時間・周波数リソースがＤｉｓｃｏｖｅｒｙ用に使用されることを理解できる。このため、カバレッジ外でのＤＴＣシナリオにおいて、複数のユーザ端末間で効率良くＤ２Ｄ発見手続が行われる。

［その他の実施形態］
上述した第１実施形態及び第２実施形態の内容は、それぞれ別に実施し得るが、第１実施形態はＭＡＣレイヤでの動作であり、第２実施形態は、ＭＡＣレイヤよりも下位のレイヤでの動作であるため、両実施形態を組み合わせて実施してもよい。

上述した第１実施形態及び第２実施形態の内容は、「カバレッジ外」でのシナリオで実施されるが、「部分的カバレッジ」のシナリオで実施されてもよい。

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

［相互参照］
日本国特許出願第２０１５−０８１２０２号（２０１５年４月１０日）の全内容が参照により本願明細書に組み込まれている。

本発明は、通信分野において有用である。

Claims (4)

1. 直接的な端末間通信であるＤ２Ｄ（Ｄｅｖｉｃｅ ｔｏ Ｄｅｖｉｃｅ）通信をサポートする移動通信システムにおいて用いられるユーザ端末であって、
   コントローラを備え、
   前記コントローラは、セルカバレッジ外のユーザ端末を対象にしたＤ２Ｄ発見手続を実行すると決めた場合には、事前に設定されたＤ２Ｄ通信用のリソースプールにおけるＤ２Ｄデータリソースを用いてＤ２Ｄ発見手続を実行し、
   前記コントローラは、前記Ｄ２Ｄ発見手続を実行するときには、前記Ｄ２Ｄデータリソースによって運ばれるデータが当該Ｄ２Ｄ発見手続のために使用されることを示す識別情報を送信する処理を実行し、
   前記データは、ＭＡＣ（Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）レイヤよりも下位のレイヤにおいて運ばれるデータであり、前記識別情報は、前記Ｄ２Ｄ通信用のリソースプールにおける制御情報用の時間・周波数リソース領域において運ばれる情報である、ユーザ端末。
2. 前記識別情報は、明示的な情報である前記請求項１記載のユーザ端末。
3. 前記識別情報は、特定のＭＣＳ（Ｍｏｄｕｌａｔｉｏｎ ａｎｄ Ｃｏｄｉｎｇ Ｓｃｈｅｍｅ）によって暗黙的に示される情報である前記請求項１記載のユーザ端末。
4. 直接的な端末間通信であるＤ２Ｄ（Ｄｅｖｉｃｅ ｔｏ Ｄｅｖｉｃｅ）通信をサポートする移動通信システムにおいて用いられるユーザ端末における制御方法であって、
   セルカバレッジ外のユーザ端末を対象にしたＤ２Ｄ発見手続を実行する場合、事前に設定されたＤ２Ｄ通信用のリソースプールにおけるＤ２Ｄデータリソースを用いてＤ２Ｄ発見手続を実行し、
   前記Ｄ２Ｄ発見手続を実行するときには、前記Ｄ２Ｄデータリソースによって運ばれるデータが当該Ｄ２Ｄ発見手続のために使用されることを示す識別情報を送信し、
   前記データは、ＭＡＣ（Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）レイヤよりも下位のレイヤにおいて運ばれるデータであり、前記識別情報は、前記Ｄ２Ｄ通信用のリソースプールにおける制御情報用の時間・周波数リソース領域において運ばれる情報である、制御方法。

Images