JP2017516400A - ロングタームエボリューションデバイス間発見のためのリソース割振り制御 - Google Patents

Abstract

ワイヤレス通信のための方法、装置、およびコンピュータプログラム製品が提供される。装置はＵＥであり得る。ＵＥは、システム情報がＤ２Ｄ通信に対して受信されるかどうかを決定する。加えて、ＵＥは、システム情報が受信されるとき、システム情報に基づいて少なくとも１つのフラグを設定する。さらに、ＵＥは、少なくとも１つのフラグに基づいてＤ２Ｄリソースを決定する。【選択図】図１４

Description

関連出願の相互参照

[0001] 本出願は、２０１４年５月２日に出願された「ＲＥＳＯＵＲＣＥ ＡＬＬＯＣＡＴＩＯＮ ＣＯＮＴＲＯＬ ＦＯＲ ＬＯＮＧ ＴＥＲＭ ＥＶＯＬＵＴＩＯＮ ＤＥＶＩＣＥ−ＴＯ−ＤＥＶＩＣＥ ＤＩＳＣＯＶＥＲＹ」と題する米国仮出願第６１／９８７，８３９号、および２０１５年１月１３日に出願された「ＲＥＳＯＵＲＣＥ ＡＬＬＯＣＡＴＩＯＮ ＣＯＮＴＲＯＬ ＦＯＲ ＬＯＮＧ ＴＥＲＭ ＥＶＯＬＵＴＩＯＮ ＤＥＶＩＣＥ−ＴＯ−ＤＥＶＩＣＥ ＤＩＳＣＯＶＥＲＹ」と題する米国特許出願第１４／５９６，１４６号の利益を主張するもので、それら全てが参照により本明細書に明確に組み込まれる。

[0002] 本開示は、一般に、通信システムに関し、より詳細には、ロングタームエボリューションデバイス間発見のためのリソース割振り制御に関する。

[0003] ワイヤレス通信システムは、電話、ビデオ、データ、メッセージング、およびブロードキャストなどの様々な電気通信サービスを提供するために広く展開されている。通常のワイヤレス通信システムは、利用可能なシステムリソース（例えば、帯域幅、送信電力）を共有することによって複数のユーザとの通信をサポートすることが可能な多元接続技術を採用し得る。そのような多元接続技術の例は、符号分割多元接続（ＣＤＭＡ）システム、時分割多元接続（ＴＤＭＡ）システム、周波数分割多元接続（ＦＤＭＡ）システム、直交周波数分割多元接続（ＯＦＤＭＡ）システム、シングルキャリア周波数分割多元接続（ＳＣ−ＦＤＭＡ）システム、および時分割同期符号分割多元接続（ＴＤ−ＳＣＤＭＡ）システムを含む。

[0004] これらの多元接続技術は、異なるワイヤレスデバイスが都市、国家、地域、さらには地球規模で通信することを可能にする共通プロトコルを提供するために様々な電気通信規格において採用されてきた。新生の電気通信規格の一例が、ロングタームエボリューション（ＬＴＥ（登録商標））である。ＬＴＥは、第３世代パートナーシッププロジェクト（３ＧＰＰ（登録商標））によって公表されたユニバーサルモバイルテレコミュニケーションシステム（ＵＭＴＳ）モバイル規格の拡張のセットである。ＬＴＥは、スペクトル効率を改善すること、コストを下げること、サービスを改善すること、新しいスペクトルを利用すること、およびダウンリンク（ＤＬ）上ではＯＦＤＭＡを使用し、アップリンク（ＵＬ）上ではＳＣ−ＦＤＭＡを使用し、多入力多出力（ＭＩＭＯ）アンテナ技術を使用して他のオープン規格とより良く統合することによって、モバイルブロードバンドインターネットアクセスをより良くサポートするように設計されている。しかしながら、モバイルブロードバンドアクセスに対する需要が増大し続けるにつれて、ＬＴＥ技術のさらなる改善が必要である。好ましくは、これらの改善は、他の多元接続技術、およびこれらの技術を採用する電気通信規格に適用可能であるべきである。

[0005] 本開示の一態様では、方法、コンピュータプログラム製品、および装置が提供される。装置は、ワイヤレス通信のためのユーザ機器であり得る。装置は、システム情報がデバイス間通信に対して受信される(received for device-to-device communication)かどうかを決定する。装置は、システム情報に基づいて少なくとも１つのフラグを設定する。装置は、少なくとも１つのフラグに基づいてＤ２Ｄリソースを決定する。

[0006] ＵＥの第１のレイヤが、システム情報を受信し得、少なくとも１つのフラグを設定し得、第１のレイヤよりも上位の第２のレイヤが、少なくとも１つのフラグを検査し得、Ｄ２Ｄリソースを決定するように第１のレイヤに要求し得る。第１のレイヤは無線リソース制御（ＲＲＣ：radio resource control）レイヤであり得、第２のレイヤは近接度ベースサービス（ＰｒｏＳｅ：proximity-based service）プロトコルレイヤであり得る。システム情報は、Ｄ２Ｄ通信に対して受信されていると決定され得、装置は、共通Ｄ２Ｄリソースのセットがシステム情報の中で示されるかどうかを決定し得、ＵＥの無線リソース制御（ＲＲＣ）状態を決定し得、ここにおいて、少なくとも１つのフラグが、共通Ｄ２Ｄリソースのセットがシステム情報の中で示されるかどうかに基づいて、および決定されたＲＲＣ状態に基づいて設定され得る。共通Ｄ２Ｄリソースのセットは、システム情報の中で示されると決定され得、ＲＲＣ状態は、ＲＲＣアイドル状態であると決定され得、装置は、Ｄ２Ｄリソースの割振りを求める要求が必要とされないことを第２のレイヤに対して示すために、少なくとも１つのフラグのうちの第１のフラグを設定することによって、少なくとも１つのフラグを設定し得る。装置は、Ｄ２Ｄ通信がサポートされることを示すために、少なくとも１つのフラグのうちの第２のフラグを設定することによって、少なくとも１つのフラグを設定し得る。装置は、Ｄ２Ｄ通信がサポートされることと、Ｄ２Ｄリソースの割振りを求める要求が必要とされないこととを、少なくとも１つのフラグからから決定し得、システム情報の中でＤ２Ｄ通信に対して示される共通Ｄ２Ｄリソースのセットを使用することを決定することによって、Ｄ２Ｄリソースを決定し得る。共通Ｄ２Ｄリソースのセットは、システム情報の中で示されると決定され得、ＲＲＣ状態は、ＲＲＣ接続状態であると決定され得、装置は、Ｄ２Ｄリソースの割振りを求める要求が必要とされることを示すために、少なくとも１つのフラグのうちの第１のフラグを設定することによって、少なくとも１つのフラグを設定し得る。装置は、Ｄ２Ｄ通信がサポートされることを示すために、少なくとも１つのフラグのうちの第２のフラグを設定することによって、少なくとも１つのフラグを設定し得る。装置は、Ｄ２Ｄ通信がサポートされることと、Ｄ２Ｄリソースの割振りを求める要求が必要とされることとを、少なくとも１つのフラグから決定し得、第１のレイヤにサービング基地局からのＤ２Ｄリソースの割振りを要求するように第２のレイヤにおいて要求することによって、およびＤ２Ｄリソースの割振りをサービング基地局から受信することによって、Ｄ２Ｄリソースを決定し得、ここにおいて、決定されたＤ２Ｄリソースは、受信された割振り済みＤ２Ｄリソースであり得る。装置は、Ｄ２Ｄ通信がサポートされることと、Ｄ２Ｄリソースの割振りを求める要求が必要とされることとを、少なくとも１つのフラグから決定し得、第１のレイヤにサービング基地局からのＤ２Ｄリソースのセットを用いたＤ２Ｄ通信を行うことを要求するように第２のレイヤにおいて要求することによって、およびＤ２ＤリソースのセットがＤ２Ｄ通信のために予約されているという確認を基地局から受信することによって、Ｄ２Ｄリソースを決定し得る。共通Ｄ２Ｄリソースのセットは、システム情報の中で示されないと決定され得、ＲＲＣ状態は、ＲＲＣアイドル状態であると決定され得、装置は、Ｄ２Ｄリソースの割振りを求める要求が必要とされることを第２のレイヤに対して示すために、少なくとも１つのフラグのうちの第１のフラグを設定することによって、少なくとも１つのフラグを設定し得る。装置は、Ｄ２Ｄ通信がサポートされることを示すために、少なくとも１つのフラグのうちの第２のフラグを設定することによって、少なくとも１つのフラグを設定し得る。装置は、Ｄ２Ｄ通信がサポートされることと、Ｄ２Ｄリソースの割振りを求める要求が必要とされることとを、少なくとも１つのフラグから決定し得、ＲＲＣアイドル状態からＲＲＣ接続状態へ遷移することによって、第１のレイヤにサービング基地局からのＤ２Ｄリソースの割振りを要求するように第２のレイヤにおいて要求することによって、およびＤ２Ｄリソースの割振りをサービング基地局から受信することによって、Ｄ２Ｄリソースを決定し得、ここにおいて、決定されたＤ２Ｄリソースは、受信された割振り済みＤ２Ｄリソースであり得る。装置は、第１のレイヤにＲＲＣアイドル状態からＲＲＣ接続状態へ遷移させるために、第１のレイヤよりも上位の第３のレイヤを第２のレイヤによって制御し得る。第３のレイヤは、非アクセス層（ＮＡＳ：non-access stratum）レイヤであり得る。共通Ｄ２Ｄリソースのセットは、システム情報の中で示されないと決定され得、ＲＲＣ状態は、ＲＲＣ接続状態であると決定され得、装置は、Ｄ２Ｄリソースの割振りを求める要求が必要とされることを第２のレイヤに対して示すために、少なくとも１つのフラグのうちの第１のフラグを設定することによって、少なくとも１つのフラグを設定し得る。装置は、Ｄ２Ｄ通信がサポートされることを示すために、少なくとも１つのフラグのうちの第２のフラグを設定することによって、少なくとも１つのフラグを設定し得る。装置は、Ｄ２Ｄ通信がサポートされることと、Ｄ２Ｄリソースの割振りを求める要求が必要とされることとを、少なくとも１つのフラグから決定し得、第１のレイヤにサービング基地局からのＤ２Ｄリソースの割振りを要求するように第２のレイヤにおいて要求することによって、およびＤ２Ｄリソースの割振りをサービング基地局から受信することによって、Ｄ２Ｄリソースを決定し得、ここにおいて、決定されたＤ２Ｄリソースは、受信された割振り済みＤ２Ｄリソースである。装置は、Ｄ２Ｄ通信がサポートされることと、Ｄ２Ｄリソースの割振りを求める要求が必要とされることとを、少なくとも１つのフラグから決定し得、第１のレイヤにサービング基地局からのＤ２Ｄリソースのセットを用いたＤ２Ｄ通信を行うことを要求するように第２のレイヤにおいて要求することによって、およびＤ２ＤリソースのセットがＤ２Ｄ通信のために予約されているという確認を基地局から受信することによって、Ｄ２Ｄリソースを決定し得る。システム情報は、Ｄ２Ｄ通信に対して受信されていると決定され得、共通Ｄ２Ｄリソースのセットは、システム情報の中で示され得、装置は、共通Ｄ２Ｄリソースのセットを使用してＤ２Ｄ通信を行い得、共通Ｄ２Ｄリソースのセットを通じたＤ２Ｄ通信を停止させ得、ＲＲＣアイドル状態からＲＲＣ接続状態へ遷移し得、ここにおいて、ＲＲＣアイドル状態からＲＲＣ接続状態へ遷移すると、少なくとも１つのフラグが設定され得、ここにおいて、装置は、Ｄ２Ｄリソースの割振りを求める要求が必要とされることを示すために、少なくとも１つのフラグのうちの第１のフラグを設定することによって、少なくとも１つのフラグを設定し得る。装置は、Ｄ２Ｄ通信がサポートされることを示すために、少なくとも１つのフラグのうちの第２のフラグを設定することによって、少なくとも１つのフラグを設定し得る。装置は、Ｄ２Ｄ通信がサポートされることと、Ｄ２Ｄリソースの割振りを求める要求が必要とされることとを、少なくとも１つのフラグから決定し得、Ｄ２Ｄリソースが利用可能でないことを第２のレイヤにおいて決定することによって、第１のレイヤにサービング基地局からのＤ２Ｄリソースの割振りを要求するように第２のレイヤにおいて要求することによって、およびＤ２Ｄリソースの割振りをサービング基地局から受信することによって、Ｄ２Ｄリソースを決定し得、ここにおいて、決定されたＤ２Ｄリソースは、受信された割振り済みＤ２Ｄリソースである。システム情報は、Ｄ２Ｄ通信に対して受信されていると決定され得、共通Ｄ２Ｄリソースのセットは、システム情報の中で示されないことがあり、装置は、割り振られたＤ２Ｄリソースのセットを使用してＤ２Ｄ通信を行い得、割り振られたＤ２Ｄリソースのセットの使用の取消しを受信し得、Ｄ２Ｄリソースの割振りを求める要求が必要とされることを示すために、少なくとも１つのフラグのうちの第１のフラグを設定することによって、少なくとも１つのフラグを設定し得る。装置は、Ｄ２Ｄ通信がサポートされることを示すために、少なくとも１つのフラグのうちの第２のフラグを設定することによって、少なくとも１つのフラグを設定し得る。装置は、Ｄ２Ｄ通信がサポートされることと、Ｄ２Ｄリソースの割振りを求める要求が必要とされることとを、少なくとも１つのフラグから決定し得、Ｄ２Ｄリソースが利用可能でないことを第２のレイヤにおいて決定することによって、第１のレイヤにサービング基地局からのＤ２Ｄリソースの割振りを要求するように第２のレイヤにおいて要求することによって、およびＤ２Ｄリソースの割振りをサービング基地局から受信することによって、Ｄ２Ｄリソースを決定し得、ここにおいて、決定されたＤ２Ｄリソースは、受信された割振り済みＤ２Ｄリソースである。システム情報は、Ｄ２Ｄ通信に対して受信されていないと決定され得、装置は、Ｄ２Ｄ通信がサポートされないことを示す、少なくとも１つのフラグのうちのフラグを設定することによって、少なくとも１つのフラグを設定し得、ここにおいて、Ｄ２Ｄリソースは、ヌルセットであると決定され得る。装置は、Ｄ２Ｄリソースの中で信号を送信し得る。

ネットワークアーキテクチャの一例を示す図である。 アクセスネットワークの一例を示す図である。 ＬＴＥにおけるＤＬフレーム構造の一例を示す図である。 ＬＴＥにおけるＵＬフレーム構造の一例を示す図である。 ユーザプレーンおよび制御プレーンのための無線プロトコルアーキテクチャの一例を示す図である。 アクセスネットワークの中の発展型ノードＢ（ｅＮＢ）およびユーザ機器の一例を示す図である。 デバイス間通信システムの図である。 デバイス間（Ｄ２Ｄ）通信、レイヤ機能、およびそれらの間の様々なインターフェースに関係するＵＥのスタックを構成する様々なレイヤを示すブロック図である。 ＵＥレイヤとｅＮＢとの間の例示的なメッセージングを示す第１の図である。 ＵＥレイヤとｅＮＢとの間の例示的なメッセージングを示す第２の図である。 ＵＥレイヤとｅＮＢとの間の例示的なメッセージングを示す第３の図である。 ＵＥレイヤとｅＮＢとの間の例示的なメッセージングを示す第４の図である。 ＵＥレイヤとｅＮＢとの間の例示的なメッセージングを示す第５の図である。 ワイヤレス通信の方法のフローチャートである。 ワイヤレス通信の第１の方法を示す図である。 例示的な装置の中の様々なモジュール／手段／構成要素間のデータフローを示す概念データフロー図である。 処理システムを採用する装置のためのハードウェア実施の一例を示す図である。

[0024] 添付の図面に関して以下に記載する詳細な説明は、様々な構成の説明として意図されており、本明細書で説明する概念が実践され得る構成を表すことを意図しない。詳細な説明は、様々な概念の完全な理解を与えるための具体的な詳細を含む。しかしながら、これらの概念がこれらの具体的な詳細なしに実践され得ることが、当業者に明らかであろう。場合によっては、よく知られている構造および構成要素が、そのような概念を不明瞭にすることを避けるためにブロック図の形態で示される。

[0025] ここで、様々な装置および方法を参照しながら電気通信システムのいくつかの態様が提示される。これらの装置および方法は、以下の発明を実施するための形態において説明され、様々なブロック、モジュール、構成要素、回路、ステップ、プロセス、アルゴリズムなど（「要素」と総称される）によって添付の図面に示される。これらの要素は、電子ハードウェア、コンピュータソフトウェア、またはそれらの任意の組合せを使用して実施され得る。そのような要素がハードウェアとして実施されるのか、それともソフトウェアとして実施されるのかは、特定の適用例および全体的なシステムに課された設計制約に依存する。

[0026] 例として、要素、または要素の任意の部分、または要素の任意の組合せは、１つまたは複数のプロセッサを含む「処理システム」を用いて実施され得る。プロセッサの例は、マイクロプロセッサ、マイクロコントローラ、デジタルシグナルプロセッサ（ＤＳＰ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、プログラマブル論理デバイス（ＰＬＤ）、ステートマシン、ゲート論理、個別ハードウェア回路、および本開示全体にわたって説明する様々な機能を行うように構成される他の適切なハードウェアを含む。処理システムの中の１つまたは複数のプロセッサは、ソフトウェアを実行し得る。ソフトウェアは、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語と呼ばれるか、他の名称で呼ばれるかにかかわらず、命令、命令セット、コード、コードセグメント、プログラムコード、プログラム、サブプログラム、ソフトウェアモジュール、アプリケーション、ソフトウェアアプリケーション、ソフトウェアパッケージ、ルーチン、サブルーチン、オブジェクト、実行ファイル、実行スレッド、プロシージャ、関数などを意味すると広く解釈されたい。

[0027] 従って、１つまたは複数の例示的な実施形態では、説明される機能が、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実施され得る。ソフトウェアで実施される場合、機能は、コンピュータ可読媒体上に記憶され得るか、あるいはコンピュータ可読媒体上に１つまたは複数の命令またはコードとして符号化され得る。コンピュータ可読媒体は、コンピュータ記憶媒体を含む。記憶媒体は、コンピュータによってアクセスされ得る任意の利用可能な媒体であり得る。限定ではなく例として、そのようなコンピュータ可読媒体は、ランダムアクセスメモリ（ＲＡＭ）、読取り専用メモリ（ＲＯＭ）、電気的消去可能プログラマブルＲＯＭ（ＥＥＰＲＯＭ（登録商標））、コンパクトディスクＲＯＭ（ＣＤ−ＲＯＭ）もしくは他の光ディスクストレージ、磁気ディスクストレージもしくは他の磁気ストレージデバイス、または命令もしくはデータ構造の形態で所望のプログラムコードを搬送もしくは記憶するために使用され得、コンピュータによってアクセスされ得る、任意の他の媒体を備えることができる。上記の組合せも、コンピュータ可読媒体の範囲内に含まれるべきである。

[0028] 図１は、ＬＴＥネットワークアーキテクチャ１００を示す図である。ＬＴＥネットワークアーキテクチャ１００は、発展型パケットシステム（ＥＰＳ）１００と呼ばれることがある。ＥＰＳ１００は、１つまたは複数のユーザ機器（ＵＥ）１０２と、発展型ＵＭＴＳ地上波無線アクセスネットワーク（Ｅ−ＵＴＲＡＮ：Evolved UMTS Terrestrial Radio Access Network）１０４と、発展型パケットコア（ＥＰＣ：Evolved Packet Core）１１０と、事業者のインターネットプロトコル（ＩＰ）サービス１２２とを含み得る。ＥＰＳは他のアクセスネットワークと相互接続できるが、簡単のために、それらのエンティティ／インターフェースは図示していない。図示のように、ＥＰＳはパケット交換サービスを提供するが、当業者なら容易に諒解するように、本開示全体にわたって提示される様々な概念は、回線交換サービスを提供するネットワークに拡張され得る。

[0029] Ｅ−ＵＴＲＡＮは、発展型ノードＢ（ｅＮＢ）１０６と、他のｅＮＢ１０８とを含み、マルチキャスト協調エンティティ（ＭＣＥ）１２８を含み得る。ｅＮＢ１０６は、ＵＥ１０２に向かってユーザプレーンプロトコル終端と制御プレーンプロトコル終端とを提供する。ｅＮＢ１０６は、バックホール（例えば、Ｘ２インターフェース）を介して他のｅＮＢ１０８に接続され得る。ＭＣＥ１２８は、発展型マルチメディアブロードキャストマルチキャストサービス（ＭＢＭＳ：Multimedia Broadcast Multicast Service）（ｅＭＢＭＳ）のために時間／周波数無線リソースを割り振り、ｅＭＢＭＳ用の無線構成（例えば、変調／コーディング方式（ＭＣＳ））を決定する。ＭＣＥ１２８は、別個のエンティティ、またはｅＮＢ１０６の一部であり得る。ｅＮＢ１０６は、基地局、ノードＢ、アクセスポイント、トランシーバ基地局、無線基地局、無線トランシーバ局、トランシーバ機能、基本サービスセット（ＢＳＳ：basic service set）、拡張サービスセット（ＥＳＳ：extended service set）、または何らかの他の適切な用語で呼ばれることもある。ｅＮＢ１０６は、ＥＰＣ１１０へのアクセスポイントをＵＥ１０２に提供する。ＵＥ１０２の例は、セルラーフォン、スマートフォン、セッション開始プロトコル（ＳＩＰ：session initiation protocol）フォン、ラップトップ、携帯情報端末（ＰＤＡ）、衛星無線、全地球測位システム、マルチメディアデバイス、ビデオデバイス、デジタルオーディオプレーヤ（例えば、ＭＰ３プレーヤ）、カメラ、ゲーム機、タブレット、または任意の他の同様の機能デバイスを含む。ＵＥ１０２は、当業者によって、移動局、加入者局、モバイルユニット、加入者ユニット、ワイヤレスユニット、リモートユニット、モバイルデバイス、ワイヤレスデバイス、ワイヤレス通信デバイス、リモートデバイス、モバイル加入者局、アクセス端末、モバイル端末、ワイヤレス端末、リモート端末、ハンドセット、ユーザエージェント、モバイルクライアント、クライアント、または何らかの他の適切な用語で呼ばれることもある。

[0030] ｅＮＢ１０６は、ＥＰＣ１１０に接続される。ＥＰＣ１１０は、モビリティ管理エンティティ（ＭＭＥ：Mobility Management Entity）１１２と、ホーム加入者サーバ（ＨＳＳ）１２０と、他のＭＭＥ１１４と、サービングゲートウェイ１１６と、マルチメディアブロードキャストマルチキャストサービス（ＭＢＭＳ）ゲートウェイ１２４と、ブロードキャストマルチキャストサービスセンター（ＢＭ−ＳＣ：Broadcast Multicast Service Center）１２６と、パケットデータネットワーク（ＰＤＮ：Packet Data Network）ゲートウェイ１１８とを含み得る。ＭＭＥ１１２は、ＵＥ１０２とＥＰＣ１１０との間のシグナリングを処理する制御ノードである。概して、ＭＭＥ１１２は、ベアラおよび接続の管理を提供する。全てのユーザＩＰパケットは、サービングゲートウェイ１１６を通じて転送され、サービングゲートウェイ１１６自体は、ＰＤＮゲートウェイ１１８に接続される。ＰＤＮゲートウェイ１１８は、ＵＥのＩＰアドレス割振り、ならびに他の機能を提供する。ＰＤＮゲートウェイ１１８およびＢＭ−ＳＣ１２６は、ＩＰサービス１２２に接続される。ＩＰサービス１２２は、インターネット、イントラネット、ＩＰマルチメディアサブシステム（ＩＭＳ：IP Multimedia Subsystem）、ＰＳストリーミングサービス（ＰＳＳ：PS Streaming Service）、および／または他のＩＰサービスを含み得る。ＢＭ−ＳＣ１２６は、ＭＢＭＳユーザサービスのプロビジョニングおよび配信のための機能を提供し得る。ＢＭ−ＳＣ１２６は、コンテンツプロバイダＭＢＭＳ送信のためのエントリポイントとして働き得、ＰＬＭＮ内のＭＢＭＳベアラサービスを許可および開始するために使用され得、ＭＢＭＳ送信をスケジュールおよび配信するために使用され得る。ＭＢＭＳゲートウェイ１２４は、特定のサービスをブロードキャストするマルチキャストブロードキャスト単一周波数ネットワーク（ＭＢＳＦＮ：Multicast Broadcast Single Frequency Network）エリアに属するｅＮＢ（例えば、１０６、１０８）にＭＢＭＳトラフィックを配信するために使用され得、セッション管理（開始／停止）と、ｅＭＢＭＳ関係の課金情報を収集することとを担当し得る。

[0031] 図２は、ＬＴＥネットワークアーキテクチャにおけるアクセスネットワーク２００の一例を示す図である。この例では、アクセスネットワーク２００が、いくつかのセルラー領域（セル）２０２に分割される。１つまたは複数のより低い電力クラスのｅＮＢ２０８が、セル２０２のうちの１つまたは複数と重なるセルラー領域２１０を有し得る。より低い電力クラスのｅＮＢ２０８は、フェムトセル（例えば、ホームｅＮＢ（ＨｅＮＢ：home eNB））、ピコセル、マイクロセル、またはリモートラジオヘッド（ＲＲＨ：remote radio head）であり得る。マクロｅＮＢ２０４は各々、それぞれのセル２０２に割り当てられ、セル２０２の中の全てのＵＥ２０６にＥＰＣ１１０へのアクセスポイントを提供するように構成される。アクセスネットワーク２００のこの例では集中コントローラがないが、代替構成では集中コントローラが使用され得る。ｅＮＢ２０４は、無線ベアラ制御、承認制御、モビリティ制御、スケジューリング、セキュリティ、およびサービングゲートウェイ１１６への接続性を含む、全ての無線関係機能を担当する。ｅＮＢは、１つまたは複数（例えば、３つ）のセル（セクタとも呼ばれる）をサポートし得る。「セル」という用語は、ｅＮＢ、および／または特定のカバレージエリアをサービスするｅＮＢサブシステムの、最小カバレージエリアを指すことができる。さらに、「ｅＮＢ」、「基地局」、および「セル」という用語は、本明細書において同義で使用され得る。

[0032] アクセスネットワーク２００によって採用される変調方式および多元接続方式は、展開されている特定の電気通信規格に応じて異なり得る。ＬＴＥ適用例では、周波数分割複信（ＦＤＤ）と時分割複信（ＴＤＤ）の両方をサポートするために、ＯＦＤＭがＤＬ上で使用され、ＳＣ−ＦＤＭＡがＵＬ上で使用される。当業者なら以下の詳細な説明から容易に諒解するように、本明細書で提示される様々な概念は、ＬＴＥ適用例に好適である。しかしながら、これらの概念は、他の変調技法および多元接続技法を採用する他の電気通信規格に容易に拡張され得る。例として、これらの概念は、エボリューションデータオプティマイズド（ＥＶ−ＤＯ：Evolution-Data Optimized）またはウルトラモバイルブロードバンド（ＵＭＢ：Ultra Mobile Broadband）に拡張され得る。ＥＶ−ＤＯおよびＵＭＢは、ＣＤＭＡ２０００規格ファミリーの一部として第３世代パートナーシッププロジェクト２（３ＧＰＰ２）によって公表されたエアインターフェース規格であり、移動局にブロードバンドインターネットアクセスを提供するためにＣＤＭＡを採用する。これらの概念はまた、広帯域ＣＤＭＡ（Ｗ−ＣＤＭＡ（登録商標））と、ＴＤ−ＳＣＤＭＡなどのＣＤＭＡの他の変形形態とを採用するユニバーサル地上波無線アクセス（ＵＴＲＡ：Universal Terrestrial Radio Access）、ＴＤＭＡを採用するモバイル通信用グローバルシステム（ＧＳＭ（登録商標）：Global System for Mobile Communications）、ならびに、ＯＦＤＭＡを採用する、発展型ＵＴＲＡ（Ｅ−ＵＴＲＡ：Evolved UTRA）、ＩＥＥＥ８０２．１１（Ｗｉ−Ｆｉ（登録商標））、ＩＥＥＥ８０２．１６（ＷｉＭＡＸ（登録商標））、ＩＥＥＥ８０２．２０、およびＦｌａｓｈ−ＯＦＤＭに拡張され得る。ＵＴＲＡ、Ｅ−ＵＴＲＡ、ＵＭＴＳ、ＬＴＥ、およびＧＳＭは、３ＧＰＰ団体からの文書に記載されている。ＣＤＭＡ２０００およびＵＭＢは、３ＧＰＰ２団体からの文書に記載されている。採用される実際のワイヤレス通信規格および多元接続技術は、特定の適用例およびシステムに課された全体的な設計制約に依存する。

[0033] ｅＮＢ２０４は、ＭＩＭＯ技術をサポートする複数のアンテナを有し得る。ＭＩＭＯ技術の使用は、ｅＮＢ２０４が、空間多重化と、ビームフォーミングと、送信ダイバーシティとをサポートするために、空間領域を活用することを可能にする。空間多重化は、データの異なるストリームを同じ周波数上で同時に送信するために使用され得る。データストリームは、データレートを上げるために単一のＵＥ２０６に送信され得、または全体的なシステム容量を増大させるために複数のＵＥ２０６に送信されされ得る。このことは、各データストリームを空間的にプリコーディングし（すなわち、振幅および位相のスケーリングを適用し）、次いで、空間的にプリコーディングされた各ストリームを、ＤＬ上で複数の送信アンテナを通じて送信することによって実現される。空間的にプリコーディングされたデータストリームは、異なる空間シグネチャとともにＵＥ２０６に到達し、これにより、ＵＥ２０６の各々は、そのＵＥ２０６に宛てられた１つまたは複数のデータストリームを復元することが可能になる。ＵＬ上では、各ＵＥ２０６が、空間的にプリコーディングされたデータストリームを送信し、これにより、ｅＮＢ２０４は、空間的にプリコーディングされた各データストリームのソースを識別することが可能になる。

[0034] 空間多重化は、概して、チャネル状態が良好なときに使用される。チャネル状態があまり好ましくないとき、送信エネルギーを１つまたは複数の方向に集中させるためにビームフォーミングが使用され得る。このことは、複数のアンテナを通じた送信用にデータを空間的にプリコーディングすることによって実現され得る。セルのエッジにおいて良好なカバレージを実現するために、送信ダイバーシティと組み合わせてシングルストリームビームフォーミング送信が使用され得る。

[0035] 以下の発明を実施するための形態では、アクセスネットワークの様々な態様が、ＤＬ上でＯＦＤＭをサポートするＭＩＭＯシステムに関して説明される。ＯＦＤＭは、ＯＦＤＭシンボル内でいくつかのサブキャリアを介してデータを変調するスペクトル拡散技法である。サブキャリアは、正確な周波数で離間される。離間は、受信機がサブキャリアからデータを復元することを可能にする「直交性」をもたらす。時間領域では、ＯＦＤＭシンボル間干渉をなくすために、各ＯＦＤＭシンボルにガードインターバル（例えば、サイクリックプレフィックス）が追加され得る。ＵＬは、高いピーク対平均電力比（ＰＡＰＲ）を補償するために、ＳＣ−ＦＤＭＡをＤＦＴ拡散ＯＦＤＭ信号の形態で使用し得る。

[0036] 図３は、ＬＴＥにおけるＤＬフレーム構造の一例を示す図３００である。フレーム（１０ｍｓ）は、等しいサイズの１０個のサブフレームに分割され得る。各サブフレームは、２つの連続するタイムスロットを含み得る。２つのタイムスロットを表すためにリソースグリッドが使用され得、各タイムスロットはリソースブロックを含む。リソースグリッドは、複数のリソース要素に分割される。ＬＴＥでは、ノーマルサイクリックプレフィックスの場合、リソースブロックが、合計８４個のリソース要素に対して、周波数領域における１２個の連続するサブキャリアと、時間領域における７個の連続するＯＦＤＭシンボルとを含む。拡張サイクリックプレフィックスの場合、リソースブロックは、合計７２個のリソース要素に対して、周波数領域における１２個の連続するサブキャリアと、時間領域における６個の連続するＯＦＤＭシンボルとを含む。Ｒ３０２、３０４として示されるリソース要素のいくつかは、ＤＬ基準信号（ＤＬ−ＲＳ：DL reference signal）を含む。ＤＬ−ＲＳは、セル固有ＲＳ（ＣＲＳ）（共通ＲＳと呼ばれることもある）３０２と、ＵＥ固有ＲＳ（ＵＥ−ＲＳ）３０４とを含む。ＵＥ−ＲＳ３０４は、対応する物理ＤＬ共有チャネル（ＰＤＳＣＨ）がマッピングされるリソースブロック上で送信される。各リソース要素によって搬送されるビット数は、変調方式に依存する。従って、ＵＥが受信するリソースブロックが多いほど、また変調方式が高いほど、ＵＥのためのデータレートは高くなる。

[0037] 図４は、ＬＴＥにおけるＵＬフレーム構造の一例を示す図４００である。ＵＬ用のために利用可能なリソースブロックは、データセクションおよび制御セクションに区分され得る。制御セクションは、システム帯域幅の２つのエッジにおいて形成され得、構成可能なサイズを有し得る。制御セクションの中のリソースブロックは、制御情報の送信用にＵＥに割り当てられ得る。データセクションは、制御セクションの中に含まれない全てのリソースブロックを含み得る。ＵＬフレーム構造は、単一のＵＥがデータセクションの中の連続サブキャリアの全てを割り当てられることを可能にし得る、連続サブキャリアを含むデータセクションをもたらす。

[0038] ＵＥは、制御情報をｅＮＢへ送信するために、制御セクションの中のリソースブロック４１０ａ、４１０ｂを割り当てられ得る。ＵＥはまた、データをｅＮＢへ送信するために、データセクションの中のリソースブロック４２０ａ、４２０ｂを割り当てられ得る。ＵＥは、制御セクションの中に割り当てられたリソースブロック上の物理ＵＬ制御チャネル（ＰＵＣＣＨ）において制御情報を送信し得る。ＵＥは、データセクションの中に割り当てられたリソースブロック上の物理ＵＬ共有チャネル（ＰＵＳＣＨ）においてデータまたはデータと制御情報の両方を送信し得る。ＵＬ送信は、サブフレームの両方のスロットに広がり得、周波数にわたってホッピングし得る。

[0039] 初期システムアクセスを行い、物理ランダムアクセスチャネル（ＰＲＡＣＨ）４３０の中でのＵＬ同期を実現するために、リソースブロックのセットが使用され得る。ＰＲＡＣＨ４３０は、ランダム系列を搬送し、いかなるＵＬデータ／シグナリングも搬送できない。各ランダムアクセスプリアンブルは、６つの連続するリソースブロックに対応する帯域幅を占有する。開始周波数は、ネットワークによって指定される。すなわち、ランダムアクセスプリアンブルの送信は、ある時間リソースおよび周波数リソースに制限される。ＰＲＡＣＨの場合、周波数ホッピングはない。ＰＲＡＣＨ試行は、単一のサブフレーム（１ｍｓ）において、または少数の連続サブフレームのシーケンスにおいて搬送され、ＵＥは、フレーム（１０ｍｓ）当たり単一のＰＲＡＣＨ試行を行うことができる。

[0040] 図５は、ＬＴＥにおけるユーザプレーンおよび制御プレーンのための無線プロトコルアーキテクチャの一例を示す図５００である。ＵＥおよびｅＮＢのための無線プロトコルアーキテクチャは、３つのレイヤ、すなわち、レイヤ１、レイヤ２、およびレイヤ３を用いて示される。レイヤ１（Ｌ１レイヤ）は最下位レイヤであり、様々な物理レイヤ信号処理機能を実施する。Ｌ１レイヤは、本明細書において物理レイヤ５０６と呼ばれる。レイヤ２（Ｌ２レイヤ）５０８は、物理レイヤ５０６の上にあり、物理レイヤ５０６を介したＵＥとｅＮＢとの間のリンクを担当する。

[0041] ユーザプレーンでは、Ｌ２レイヤ５０８が、ネットワーク側でのｅＮＢにおいて終端される、媒体アクセス制御（ＭＡＣ）サブレイヤ５１０と、無線リンク制御（ＲＬＣ：radio link control）サブレイヤ５１２と、パケットデータコンバージェンスプロトコル（ＰＤＣＰ）５１４サブレイヤとを含む。図示されていないが、ＵＥは、ネットワーク側でのＰＤＮゲートウェイ１１８において終端されるネットワークレイヤ（例えば、ＩＰレイヤ）と、接続の他端（例えば、遠端ＵＥ、サーバなど）において終端されるアプリケーションレイヤとを含む、Ｌ２レイヤ５０８の上のいくつかの上位レイヤを有し得る。

[0042] ＰＤＣＰサブレイヤ５１４は、異なる無線ベアラと論理チャネルとの間の多重化を提供する。ＰＤＣＰサブレイヤ５１４はまた、無線送信オーバーヘッドを低減するための上位レイヤデータパケットに対するヘッダ圧縮と、データパケットを暗号化することによるセキュリティと、ＵＥに対するｅＮＢ間のハンドオーバサポートとを提供する。ＲＬＣサブレイヤ５１２は、上位レイヤデータパケットのセグメント化および再アセンブリと、紛失データパケットの再送信と、ハイブリッド自動再送要求（ＨＡＲＱ）に起因して順が狂った受信を補正するためのデータパケットの並べ替えとを行う。ＭＡＣサブレイヤ５１０は、論理チャネルとトランスポートチャネルとの間の多重化を提供する。ＭＡＣサブレイヤ５１０はまた、１つのセルの中の様々な無線リソース（例えば、リソースブロック）をＵＥの間で割り振ることを担当する。ＭＡＣサブレイヤ５１０はまた、ＨＡＲＱ演算を担当する。

[0043] 制御プレーンにおいて、ＵＥおよびｅＮＢのための無線プロトコルアーキテクチャは、制御プレーンのためのヘッダ圧縮機能がないことを除いて、物理レイヤ５０６およびＬ２レイヤ５０８に対して実質的に同じである。制御プレーンはまた、レイヤ３（Ｌ３レイヤ）の中に無線リソース制御（ＲＲＣ）サブレイヤ５１６を含む。ＲＲＣサブレイヤ５１６は、無線リソース（例えば、無線ベアラ）を取得すること、およびｅＮＢとＵＥとの間のＲＲＣシグナリングを使用して下位レイヤを構成することを担当する。

[0044] 図６は、アクセスネットワークの中のＵＥ６５０と通信しているｅＮＢ６１０のブロック図である。ＤＬでは、コアネットワークからの上位レイヤパケットが、コントローラ／プロセッサ６７５に提供される。コントローラ／プロセッサ６７５は、Ｌ２レイヤの機能を実施する。ＤＬでは、コントローラ／プロセッサ６７５が、ヘッダ圧縮と、暗号化と、パケットのセグメント化および並べ替えと、論理チャネルとトランスポートチャネルとの間の多重化と、様々な優先度メトリックに基づくＵＥ６５０への無線リソース割振りとを提供する。コントローラ／プロセッサ６７５はまた、ＨＡＲＱ演算と、紛失パケットの再送信と、ＵＥ６５０へのシグナリングとを担当する。

[0045] 送信（ＴＸ）プロセッサ６１６は、Ｌ１レイヤ（すなわち、物理レイヤ）のための様々な信号処理機能を実施する。信号処理機能は、ＵＥ６５０における前方誤り訂正（ＦＥＣ）を容易にするための、コーディングとインターリービングと、様々な変調方式（例えば、２位相シフトキーイング（ＢＰＳＫ）、４位相シフトキーイング（ＱＰＳＫ）、Ｍ位相シフトキーイング（Ｍ−ＰＳＫ）、多値直交振幅変調（Ｍ−ＱＡＭ））に基づく信号コンスタレーションへのマッピングとを含む。コーディングおよび変調されたシンボルは、次いで、並列ストリームに分割される。各ストリームは、次いで、時間領域ＯＦＤＭシンボルストリームを搬送する物理チャネルを生成するために、ＯＦＤＭサブキャリアにマッピングされ、時間領域および／または周波数領域において基準信号（例えば、パイロット）と多重化され、次いで、逆高速フーリエ変換（ＩＦＦＴ）を使用して互いに合成される。ＯＦＤＭストリームは、複数の空間ストリームを生成するために空間的にプリコーディングされる。チャネル推定器６７４からのチャネル推定値は、コーディングおよび変調方式を決定するために、ならびに空間処理のために使用され得る。チャネル推定値は、ＵＥ６５０によって送信された基準信号および／またはチャネル状態フィードバックから導出され得る。各空間ストリームは、次いで、別個の送信機６１８ＴＸを介して異なるアンテナ６２０に供給され得る。各送信機６１８ＴＸは、送信のためにそれぞれの空間ストリームを用いてＲＦキャリアを変調し得る。

[0046] ＵＥ６５０において、各受信機６５４ＲＸは、それのそれぞれのアンテナ６５２を通じて信号を受信する。各受信機６５４ＲＸは、ＲＦキャリア上に変調された情報を復元し、受信（ＲＸ）プロセッサ６５６に情報を提供する。ＲＸプロセッサ６５６は、Ｌ１レイヤの様々な信号処理機能を実施する。ＲＸプロセッサ６５６は、ＵＥ６５０に宛てられた任意の空間ストリームを復元するために、情報に対して空間処理を行い得る。複数の空間ストリームは、ＵＥ６５０に宛てられている場合、ＲＸプロセッサ６５６によって単一のＯＦＤＭシンボルストリームに合成され得る。ＲＸプロセッサ６５６は、次いで、高速フーリエ変換（ＦＦＴ）を使用してＯＦＤＭシンボルストリームを時間領域から周波数領域に変換する。周波数領域信号は、ＯＦＤＭ信号のサブキャリアごとに別個のＯＦＤＭシンボルストリームを備える。各サブキャリア上のシンボル、および基準信号は、ｅＮＢ６１０によって送信された、可能性が最も高い信号コンスタレーションポイントを決定することによって復元および復調される。これら軟判定(soft decisions)は、チャネル推定器６５８によって計算されるチャネル推定値に基づき得る。軟判定は、次いで、物理チャネル上でｅＮＢ６１０によって最初に送信されたデータと制御信号とを復元するために、復号およびデインターリーブされる。データおよび制御信号は、次いで、コントローラ／プロセッサ６５９に提供される。

[0047] コントローラ／プロセッサ６５９は、Ｌ２レイヤを実施する。コントローラ／プロセッサは、プログラムコードとデータとを記憶するメモリ６６０に関連付けられ得る。メモリ６６０は、コンピュータ可読媒体と呼ばれることがある。ＵＬでは、コントローラ／プロセッサ６５９が、コアネットワークからの上位レイヤパケットを復元するために、トランスポートチャネルと論理チャネルとの間の多重分離と、パケットの再アセンブリと、暗号解読と、ヘッダ解凍と、制御信号処理とを提供する。上位レイヤパケットは、次いで、Ｌ２レイヤの上の全てのプロトコルレイヤを表す、データシンク６６２に提供される。様々な制御信号も、Ｌ３処理のためにデータシンク６６２に提供され得る。コントローラ／プロセッサ６５９はまた、ＨＡＲＱ演算をサポートするために、肯定応答（ＡＣＫ）および／または否定応答（ＮＡＣＫ）プロトコルを使用する誤り検出を担当する。

[0048] ＵＬでは、データソース６６７が、コントローラ／プロセッサ６５９に上位レイヤパケットを提供するために使用される。データソース６６７は、Ｌ２レイヤの上の全てのプロトコルレイヤを表す。ｅＮＢ６１０によるＤＬ送信に関して説明された機能と同様に、コントローラ／プロセッサ６５９は、ヘッダ圧縮と、暗号化と、パケットのセグメント化および並べ替えと、ｅＮＢ６１０による無線リソース割振りに基づく論理チャネルとトランスポートチャネルとの間の多重化とを提供することによって、ユーザプレーンおよび制御プレーンのためのＬ２レイヤを実施する。コントローラ／プロセッサ６５９はまた、ＨＡＲＱ演算と、紛失パケットの再送信と、ｅＮＢ６１０へのシグナリングとを担当する。

[0049] ｅＮＢ６１０によって送信された基準信号またはフィードバックからの、チャネル推定器６５８によって導出されるチャネル推定値は、適切なコーディングおよび変調方式を選択するために、また空間処理を容易にするために、ＴＸプロセッサ６６８によって使用され得る。ＴＸプロセッサ６６８によって生成された空間ストリームは、別個の送信機６５４ＴＸを介して異なるアンテナ６５２に供給され得る。各送信機６５４ＴＸは、送信のためにそれぞれの空間ストリームを用いてＲＦキャリアを変調し得る。

[0050] ＵＬ送信は、ＵＥ６５０における受信機機能に関して説明された方法と同様の方法で、ｅＮＢ６１０において処理される。各受信機６１８ＲＸは、それのそれぞれのアンテナ６２０を通じて信号を受信する。各受信機６１８ＲＸは、ＲＦキャリア上に変調された情報を復元し、情報をＲＸプロセッサ６７０に提供する。ＲＸプロセッサ６７０は、Ｌ１レイヤを実施し得る。

[0051] コントローラ／プロセッサ６７５は、Ｌ２レイヤを実施する。コントローラ／プロセッサ６７５は、プログラムコードとデータとを記憶するメモリ６７６に関連付けられ得る。メモリ６７６は、コンピュータ可読媒体と呼ばれることがある。ＵＬでは、コントローラ／プロセッサ６７５が、ＵＥ６５０からの上位レイヤパケットを復元するために、トランスポートチャネルと論理チャネルとの間の多重分離と、パケットの再アセンブリと、暗号解読と、ヘッダ解凍と、制御信号処理とを提供する。コントローラ／プロセッサ６７５からの上位レイヤパケットは、コアネットワークに提供され得る。コントローラ／プロセッサ６７５はまた、ＨＡＲＱ演算をサポートするために、ＡＣＫおよび／またはＮＡＣＫプロトコルを使用する誤り検出を担当する。

[0052] 図７は、デバイス間通信システム７００の図である。デバイス間通信システム７００は、複数のワイヤレスデバイス７０４、７０６、７０８、７１０を含む。デバイス間通信システム７００は、例えば、ワイヤレスワイドエリアネットワーク（ＷＷＡＮ）などのセルラー通信システムと重なることがある。ワイヤレスデバイス７０４、７０６、７０８、７１０の一部は、ＤＬ／ＵＬ ＷＷＡＮスペクトルを使用するデバイス間通信において互いに通信し得、一部は基地局７０２と通信し得、一部は両方を行い得る。例えば、図７に示すように、ワイヤレスデバイス７０８、７１０がデバイス間通信中であり、ワイヤレスデバイス７０４、７０６がデバイス間通信中である。ワイヤレスデバイス７０４、７０６はまた、基地局７０２と通信している。

[0053] 以下で説明する例示的な方法および装置は、例えば、ＦｌａｓｈＬｉｎＱ、ＷｉＭｅｄｉａ、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＺｉｇＢｅｅ（登録商標）、またはＩＥＥＥ８０２．１１規格に基づくＷｉ−Ｆｉに基づくワイヤレスデバイス間通信システムなどの、様々なワイヤレスデバイス間通信システムのいずれにも適用可能である。説明を簡略化するために、例示的な方法および装置は、ＬＴＥのコンテキスト内で説明される。しかしながら、例示的な方法および装置が、様々な他のワイヤレスデバイス間通信システムに、より一般的に適用可能であることを当業者なら理解されよう。

[0054] 例示的な実施形態は、概して、ＵＥが別のＵＥと通信することを可能にする（例えば、ＵＥがＬＴＥバンドを介して何かを告知することを可能にし、その何かが他のＵＥによって受信される）ための方法と装置とを提供する。

[0055] 図８は、Ｄ２Ｄ発見通信、それらの機能、およびそれらの間の様々なインターフェースなどの、Ｄ２Ｄ通信に関係するＵＥ８０２のスタックを構成する様々なレイヤを示すブロック図８００である。ＵＥ８０２のスタックの様々なレイヤは、ＰｒｏＳｅ（近接度ベースサービス）プロトコル８０４と、非アクセス層（ＮＡＳ）レイヤ８０６と、ＲＲＣレイヤ／サブレイヤ８０８と、ＭＡＣレイヤ／サブレイヤ８１０とを含む。様々な他のレイヤ／サブレイヤが、例示的な実施形態のＵＥ８０２のスタックの中に存在することがある。しかしながら、この詳細な説明は、ＰｒｏＳｅプロトコル８０４、ＮＡＳレイヤ８０６、ＲＲＣレイヤ８０８、およびＭＡＣレイヤ８１０、ならびにレイヤのうちの異なるものの間の様々な対話(interaction)チャネルに焦点を当てる。

[0056] ＰｒｏＳｅプロトコル８０４の下は、ＵＥ８０２の状態遷移を（例えば、「アイドル状態」から「接続状態」へ）制御できるＮＡＳレイヤ８０６である。しかしながら、ＮＡＳレイヤ８０６は、通常、Ｄ２Ｄ動作に気づいていない。さらに、ＮＡＳレイヤ８０６は、他のアプリケーションによって共有されるとともに影響を及ぼされる。

[0057] ＮＡＳレイヤ８０６の下は、Ｄ２Ｄ無線リソース割振りのための要件に関する情報を有するＲＲＣレイヤ８０８であり、ＲＲＣレイヤ８０８はまた、ＵＥ８０２の現在の状態に関する情報を有するが、ＵＥ状態の遷移を制御することはできない。ＲＲＣレイヤ８０８は、ＵＥ８０２の無線リソースを制御でき、ネットワークの基地局／ｅＮＢ８１２と通信できる。従って、無線リソース割振りは、ＲＲＣレイヤ８０８のみに対して利用可能であり、ＲＲＣレイヤ８０８のみによって制御される。さらに、無線リソース割振りは、ＮＡＳレイヤ８０６に、またはＰｒｏＳｅプロトコル８０４に、すぐには知られない場合がある。

[0058] 最後に、ＲＲＣレイヤ８０８の下は、ＵＥ８０２用の送信スケジューリングを担当するＭＡＣレイヤ８１０である。すなわち、ＭＡＣレイヤ８１０が、事実上、ＵＥ８０２によって送信されるべきいくつかのメッセージがオーバージエアへ進むときを決定し、それはＰｒｏＳｅプロトコル８０４と通信することによってスケジュールされ得る。また、ＲＲＣレイヤ８０８は、以下で説明するように、ネットワークによって提供されるシステム情報に従って、および他のイベントに従って、ＭＡＣレイヤ８１０のＭＡＣ無線リソースを制御できる。

[0059] 実施形態は、利用可能なＤ２Ｄリソースに関する情報、および一般的なＵＥの接続状態（すなわち、接続済みまたはアイドル）に関する情報が、前記ＵＥのスタックのうちの選ばれたレイヤだけに知られているという事実に対処する。さらに、ある状態から次の状態へ（例えば、アイドル状態から接続状態へ）前記ＵＥを制御するための、または遷移させるための能力は、１つまたは複数のレイヤのみによって処理されることがある。

[0060] 例えば、一般的なＵＥの上位レイヤに対応する制御プロトコル（例えば、ＰｒｏＳｅプロトコル）は、Ｄ２Ｄ送信に対応するタイミングおよび情報の制約に気づいているが、下位レイヤ（ＲＲＣレイヤなどの）に対応する情報への直接のアクセスを有しない。

[0061] 例示的な実施形態では、いくつかの状況の下で、ＰｒｏＳｅプロトコル８０４が、ＮＡＳレイヤ８０６と（例えば、インターフェース８２２を介して）、ＲＲＣレイヤ８０８と（例えば、インターフェース８２１を介して）、およびＭＡＣレイヤ８１０と（例えば、インターフェース８２３を介して）情報を交換し得、ＲＲＣレイヤ８０８は、ＮＡＳレイヤ８０６と（例えば、インターフェース８２２’を介して）通信し得る。さらに、ＲＲＣレイヤ８０８は、基地局／ｅＮＢ８１２と通信し得る。

[0062] ＬＴＥダイレクト（ＬＴＥ−Ｄ）発見などの、Ｄ２Ｄ通信のためのＵＥ８０２に対する無線リソース割振りは、ｅＮＢ８１２が接続されているネットワークによって制御され得る。ＵＥ８０２が（一緒にＤ２Ｄ発見通信に関与しようとＵＥ８０２が求める）別のＵＥと直接通信できる前に、ＵＥ８０２は、ネットワークからｅＮＢ８１２経由で許可を取得し得る。ＵＥ８０２がネットワークから許可を受信すると、ＵＥ８０２は、それの所期の通信に対応するコードを、オーバージエアで他のＵＥへ送り得る。ピア発見リソースと呼ばれることがあるＤ２Ｄリソースを使用することによって、ＵＥ８０２は、他のＵＥによって発見され得、その後、Ｄ２Ｄ通信リソースと呼ばれることがあるＤ２Ｄリソースを使用して、他のＵＥと直接通信できる。ＬＴＥ−Ｄ発見は、１）システム情報（例えば、システム情報ブロック（ＳＩＢ：System Information Block）に含まれる情報）がタイプ１（すなわち、共通の）リソースを示す場合、２）ネットワークがＬＴＥ−Ｄをサポートすることだけをシステム情報が示す場合、および３）Ｄ２Ｄのためのシステム情報が提供されない場合、という３つの主なユースケースを考慮する。ユースケースおよびＵＥの接続状態／アイドル状態に応じて、ＵＥは、リソース（例えば、タイプ２（割り振られる）リソースおよび／またはタイプ１（共通の）リソース） 要求するＲＲＣメッセージを送ることもあり、または送らないこともある。以下は、ＬＴＥ−Ｄ発見についての３つの主なユースケース（１、２、および３）、およびそれらの下位区分（ａ，ｂ，およびｃ）である。

[0063] 事例１ａ）Ｄ２Ｄ通信のためのシステム情報（例えば、ＳＩＢ）がタイプ１リソースを示すとき（例えば、共通ピア発見リソースまたはＤ２Ｄ通信リソースなどのＤ２Ｄリソースのセットが、ｅＮＢ８１２経由でリソースプールから利用可能であることをシステム情報が示すとき）、およびＵＥ８０２がアイドル状態（例えば、ＲＲＣアイドル状態）にあるとき、ＵＥ８０２は、示されたタイプ１リソースをＤ２Ｄ発見通信のために使用でき、ＲＲＣメッセージは必要とされない。すなわち、ＵＥ８０２がアイドル状態にあるとき、ＵＥ８０２は、ｅＮＢ８１２によりブロードキャストされた情報（例えば、リソース情報）を利用でき、ｅＮＢ８１２との追加の通信なしに無線リソース管理を行うことが可能である。

[0064] 事例１ｂ）Ｄ２Ｄ通信のためのＳＩＢがタイプ１リソースを示し、ＵＥ８０２が接続状態（例えば、ＲＲＣ接続状態）にあるとき、ＵＥ８０２は、ＵＥがタイプ１リソースを使用するのか、それともタイプ２リソースを使用するのかにかかわらず、リソース割振りのためにＲＲＣメッセージをｅＮＢ８１２へ送る。すなわち、ＵＥ８０２が接続状態にあるとき、ＵＥ８０２は、ＵＥ８０２がＤ２Ｄ発見通信を行うことを可能にするための、許可、ならびにリソース割振りに関する情報を、ｅＮＢ８１２経由でネットワークに求める。

[0065] 事例１ｃ）Ｄ２Ｄ通信のためのＳＩＢがタイプ１リソースを示し、ＵＥ８０２がピア発見のために、またはＤ２Ｄ通信のためにタイプ１リソースを利用しながらアイドル状態から接続状態へ遷移するとき、ＵＥ８０２は、現在のタイプ１リソースを使用する送信を終えて、リソース割振りを求めるＲＲＣメッセージを送り得、次いで、ｅＮＢ８１２によって示される割り振られたリソースを用いて送信を再開し得る。

[0066] 事例２ａ）Ｄ２Ｄ通信のためのＳＩＢが、ネットワークがＬＴＥ−Ｄをサポートすること（例えば、ネットワークがピア発見をサポートすること、または発見がサポートされること）だけを示すが、いかなるタイプ１リソース情報も示さず、ＵＥ８０２がアイドル状態にあるとき、ＵＥ８０２は、接続状態へ遷移し得、次いで、ネットワークにリソースを要求するためのＲＲＣメッセージを送り得る。

[0067] 事例２ｂ）Ｄ２Ｄ通信のためのＳＩＢが、Ｄ２Ｄ通信およびＤ２Ｄ発見がサポートされることを示すが、いかなるリソース情報も示さず、ＵＥ８０２が接続状態にあるとき、ＵＥ８０２は、リソース割振りを求めるＲＲＣメッセージを送る。

[0068] 事例２ｃ）Ｄ２Ｄ通信のためのＳＩＢが、Ｄ２Ｄ通信およびＤ２Ｄ発見がサポートされることを示すが、いかなるリソース情報も示さず、ＵＥ８０２がネットワークとのそれの接続を失っているか、またはＵＥ８０２に許可されているリソースをｅＮＢ８１２が取り消すとき、もはやＵＥ８０２はリソースを使用し続けることができない。

[0069] 事例３）Ｄ２ＤのためのＳＩＢが提供されないとき（例えば、ＵＥ８０２が、レガシーｅＮＢによってサービスされ、ＬＴＥ−Ｄをサポートするネットワークに接続されていないとき）、ＵＥ８０２は、Ｄ２Ｄ送信を行わなず、ＭＡＣレイヤ８１０へコードを送るのをやめ得る。すなわち、Ｄ２Ｄ発見またはＤ２Ｄ通信をサポートしないネットワークにｅＮＢ８１２が接続されているとき、ＵＥ８０２は、他のＵＥとのＤ２Ｄ通信に関与し得ない。

[0070] 上記の事例の各々（１ａ、１ｂ、１ｃ、２ａ、２ｂ、２ｃ、および３）は、図９〜図１３のうちの１つに対応し、例示的な実施形態に関して以下でさらに詳細に説明される。

[0071] 例示的な実施形態は、ＵＥ８０２が、上記で略述した同じ方式または同じ事例において依然として動作しながら、ＬＴＥ Ｄ２Ｄ通信またはＬＴＥ Ｄ２Ｄ発見のための無線リソース割振りの方法を行うための構成を提供する。すなわち、例示的な実施形態は、様々なシナリオの下で、ＬＴＥ−Ｄネットワークに接続されているＵＥへのリソース割振りを管理するための方法および装置を提供する。

[0072] 例えば、適切なＤ２Ｄリソース管理をサポートする目的で、例示的な実施形態は、ＲＲＣレイヤ８０８がＮＡＳレイヤ８０６またはＰｒｏＳｅプロトコル８０４などの上位レイヤからトリガを受信することを可能にし、トリガは、ＲＲＣレイヤ８０８に、「Ｄ２Ｄリソース要求」メッセージをｅＮＢ８１２へ送らせる。このシナリオは、事例１ｂ、１ｃ、２ａ、および２ｂを参照しながら説明する。

[0073] さらに、例示的な実施形態は、ＲＲＣレイヤ８０８がＰｒｏＳｅプロトコル８０４にいくつかの状態変化イベントを示すことまたは通信することを可能にし、それによって、ＰｒｏＳｅプロトコル８０４が、どんなアクションが行われる必要があるのかを決定することを可能にする。このシナリオは、事例２ｃおよび３を参照しながら説明する。

[0074] さらに、例示的な実施形態は、ＲＲＣメッセージを送ること（例えば、ＲＲＣレイヤ８０８によってＤ２Ｄリソース要求メッセージを送ること）が、常にＵＥ８０２の状態遷移と同時に起こるとは限らないことを考慮に入れる。そのような事例では、ＮＡＳレイヤ８０６を伴うことが、いかなる追加の利点ももたらさない場合があり、ＵＥ８０２の動作の効率を低減する場合がある。このシナリオは、事例１ｂおよび２ｂを参照しながら説明する。

[0075] 再び図８を参照すると、例示的な実施形態は、ＵＥ８０２におけるＰｒｏＳｅプロトコル８０４とＲＲＣレイヤ８０８との間にインターフェース、すなわち対話チャネル８２１を設けることによって、ＬＴＥ Ｄ２Ｄ通信用のリソースの効率的なＵＥ管理を提供する。対話チャネル８２１は、ＲＲＣレイヤ８０８がＰｒｏＳｅプロトコル８０４に情報を提供することを可能にし、ＰｒｏＳｅプロトコル８０４は、情報に基づいて（またＮＡＳレイヤ８０６の接続状態／アイドル状態に基づいて）ＵＥ８０２の関係する状態遷移を処理し得る。

[0076] 本実施形態で、ＲＲＣレイヤ８０８によってＰｒｏＳｅプロトコル８０４に提供される情報は、１）ｅＮＢ８１２のネットワークがＬＴＥ−Ｄ（Ｄ２Ｄ）をサポートするかどうか、および２）ＲＲＣレイヤ８０８がｅＮＢ８１２からリソースを取得することを可能にするために、ＲＲＣレイヤ８０８がＵＥ８０２の他のレイヤによるいくつかのアクションを必要とするかどうか、に対応する。

[0077] 上記で説明した事例の各々に対して、情報は、ＲＲＣレイヤ８０８によってＰｒｏＳｅプロトコル８０４へ、１つまたは複数のフラグを使用して通信され得、それによって、比較的少量の情報を通信しながらＲＲＣレイヤ８０８がＵＥ８０２のいくつかの状態を示すことを可能にする。本実施形態で、ＲＲＣレイヤ８０８は、２つのフラグを設定することによってＰｒｏＳｅプロトコル８０４へ上記の情報を通信する。この発明を実施するための形態において、これらのフラグは、「トリガ必要」フラグおよび「発見サポート」フラグと呼ばれることがある。これらの２つのフラグは、ＲＲＣレイヤ８０８によって、ＳＩＢの、ＲＲＣレイヤの読取り値に従って設定される。

[0078] 図を参照して、フラグの３つの異なる構成を説明する。第１に、発見サポートフラグがセットされ（例えば、フラグに対応する値が１に等しい）、トリガ必要フラグがアンセット（ｕｎｓｅｔ）される（例えば、フラグに対応する値が０に等しい）（例えば、事例１ａ）。第２に、発見サポートフラグとトリガ必要フラグの両方がセットされる（例えば、事例１ｂ、１ｃ、２ａ、２ｂ、および２ｃ）。第３に、発見サポートフラグがアンセットされる（トリガ必要フラグはセットされ得、またはアンセットされされ得る）（例えば、事例３）。「発見サポートフラグ」という用語が本明細書全体にわたって、また図面において使用されるが、他の構成で、「発見サポートフラグ」は、Ｄ２Ｄ通信がネットワークによってサポートされることを示す「Ｄ２Ｄ通信サポートフラグ」であり得る。

[0079] フラグおよびＵＥ８０２接続状態に基づいて、ＰｒｏＳｅプロトコル８０４は、以下で説明するように、（例えば、ＮＡＳレイヤ８０６をトリガすることによって）状態遷移を引き起こし得、（例えば、リソースを求める要求を送ることをＲＲＣレイヤ８０８に命令するように）ＲＲＣレイヤ８０８をトリガし得、および／またはコマンドをＭＡＣレイヤ８１０へ送り得る。

[0080] 図９は、ＵＥレイヤとｅＮＢとの間の例示的なメッセージングを示す第１の図９００である。図９を参照して、上述の事例１ａを説明する。本事例では、ｅＮＢ８１２のネットワークがＬＴＥをサポートし、ＵＥ８０２がアイドル状態にある。さらに、タイプ１リソースが利用可能であることをＳＩＢが示し、それによって、Ｄ２Ｄ通信（例えば、ピア発見）のための所望のリソースをそこから選択するために、無線リソースの共通プールがＵＥ８０２にとって利用可能であることを示す。

[0081] 従って、ＲＲＣレイヤ８０８が発見サポートフラグをセットし（例えば、発見サポートフラグが１に設定される）、トリガ必要フラグがアンセットされる（例えば、トリガ必要フラグが０に設定される）。この情報は、例示的な実施形態によるＰｒｏＳｅプロトコル８０４によって見られ得る。さらに、フラグは、ＰｒｏＳｅプロトコル８０４によって使用される必要がない情報を通信することなく、ＲＲＣレイヤ８０８が有用な情報をＰｒｏＳｅプロトコル８０４へ通信することを可能にする（利用可能なリソースがタイプ１リソースであるのか、それともタイプ２リソースであるのかを示す情報などの）。

[0082] さらに、ＳＩＢに含まれる情報に従って、Ｄ２ＤのためのＭＡＣ無線リソースがＭＡＣレイヤ８１０の中に、ＲＲＣレイヤ８０８によってタイプ１リソースに従って構成される。ＲＲＣレイヤ８０８がＭＡＣ無線リソースを構成すると、ＰｒｏＳｅプロトコル８０４は、ＰｒｏＳｅプロトコル８０４によって取得された１つまたは複数のＰｒｏＳｅアプリケーションコード（ＰｒｏＳｅ Ａｐｐコード）に従って送信機会（ＴｘＯＰ）時間を取得するために、インターフェース、すなわち対話チャネル８２３（図８参照）を介してＭＡＣレイヤ８１０と通信する。対話チャネル８２３は、ＰｒｏＳｅプロトコル８０４が問合せをＭＡＣレイヤ８１０へ送ることを可能にし、その結果、ＰｒｏＳｅ Ａｐｐコードに対応する所期のＬＴＥ−Ｄメッセージを送り出すべき時をＰｒｏＳｅプロトコル８０４が知ることができ、ＵＥ８０２がそうした時を協調させることができる。

[0083] 本事例では、メッセージのＵＥ８０２からの配送のためにＵＥ８０２の状態遷移が必要とされないので、ＰｒｏＳｅプロトコル８０４は、ＴｘＯＰをＭＡＣレイヤ８１０から成功裡に直接取得可能で、ＵＥ８０２による送信を可能にできる。すなわち、たとえＵＥ８０２がアイドル状態にあっても、ＭＡＣレイヤ８１０の無線リソースが構成されるので、またリソースがタイプ１リソースとして示されるので、ＵＥ８０２の状態遷移が、Ｄ２Ｄ通信のために、またはＤ２Ｄ発見通信のために必要とされない。

[0084] ＰｒｏＳｅプロトコル８０４がＭＡＣレイヤ８１０と連絡を取ると、ＭＡＣレイヤ８１０が様々な所期のメッセージに様々な時間を割り当てる必要があるので、ＭＡＣレイヤ８１０は、送信時間に関してＰｒｏＳｅプロトコル８０４へどんな情報を送り返すべきか（例えば、どんなＴｘＯＰ時間を送り返すべきか）を決定する。すなわち、ＰｒｏＳｅプロトコル８０４は、ＰｒｏＳｅプロトコル８０４がＰｒｏＳｅ Ａｐｐコードを送信できる将来の時間を決定するために、ＭＡＣレイヤ８１０と通信する。従って、ＭＡＣレイヤ８１０は、選ばれたＴｘＯＰ時間をＰｒｏＳｅプロトコル８０４へ送り返し、その結果、ＰｒｏＳｅプロトコル８０４がメッセージ（例えば、ＰｒｏＳｅ Ａｐｐコードおよびメッセージインテグリティチェックサム（ＭＩＣ））をＴｘＯＰ時間に従って配送できる特定の時間を、ＭＡＣレイヤ８１０が格下げできる。

[0085] 本事例では、ＰｒｏＳｅプロトコル８０４が、対応する単一のＰｒｏＳｅ Ａｐｐコードに対して単一のＴｘＯＰ時間を取得するが、以下で説明するように、ＵＥ８０２が、対応する複数のそれぞれのＴｘＯＰ時間を有する複数のＰｒｏＳｅ Ａｐｐコードを考慮に入れることに留意されたい。

[0086] 有効なＴｘＯＰ時間をＭＡＣレイヤ８１０から受信すると、以下でさらに説明するように、ＰｒｏＳｅプロトコル８０４は、ＮＡＳレイヤ８０６またはＲＲＣレイヤ８０８をトリガするべきかどうかを決定する。この場合、どちらのトリガも必要とされないので、ＰｒｏＳｅプロトコル８０４は、対応するＴｘＯＰ時間に基づいて、ＰｒｏＳｅアプリケーションコードごとにメッセージインテグリティチェックサム（ＭＩＣ）（例えば、セキュリティインテグレーション検査結果）を計算する。その後、ＰｒｏＳｅプロトコル８０４は、ＭＡＣレイヤ８１０によって通信された、要求され取得されたＴｘＯＰ時間に従ってＰｒｏＳｅ Ａｐｐコードを送り、ＵＥ８０２が、ＰｒｏＳｅ Ａｐｐコードに対応するＤ２Ｄ通信メッセージ（例えば、Ｄ２Ｄ発見通信メッセージ）を送る。

[0087] 引き続き図９を参照して、上述の事例１ｂを説明する。本事例では、ｅＮＢ８１２のネットワークがやはりＬＴＥ−Ｄをサポートし、タイプ１リソースが利用可能であることをＳＩＢが示すが、ＵＥ８０２は、接続状態へ遷移している。

[0088] 本事例では、ＲＲＣレイヤ８０８がアイドル状態（例えば、事例１ａにおける）から接続状態へ遷移しているので、ＭＡＣ無線リソースは、ＲＲＣレイヤ８０８によってＭＡＣレイヤ８１０から除去される。すなわち、ＲＲＣレイヤ８０８は、発見サポートフラグとトリガ必要フラグの両方をセットし（例えば、発見サポートフラグおよびトリガ必要フラグが両方とも１に設定され）、トリガ必要フラグが新たにセットされるので、ＲＲＣレイヤ８０８は、Ｄ２Ｄ無線リソースをＭＡＣレイヤ８１０から除去する。再び、フラグによって示される情報が、ＰｒｏＳｅプロトコル８０４によって見られ得る。

[0089] 前の事例とは異なり、ＰｒｏＳｅプロトコル８０４が、ＭＡＣレイヤ８１０とのそれの通信を介してＰｒｏＳｅプロトコル８０４によって前に取得された１つまたは複数のＰｒｏＳｅ Ａｐｐコードに従って、ＴｘＯＰ時間を取得しようと試みるとき、ＴｘＯＰ時間を取得するための試行は失敗する。発見無線リソースがＭＡＣレイヤ８１０の中に構成されていないので、ＭＡＣレイヤ８１０は、いくつかのアクションが行われる必要があることをＰｒｏＳｅプロトコル８０４に示すために、「ヌルＴｘＯＰ時間」を使用する。すなわち、ＭＡＣレイヤ８１０は、送信時間が利用可能でないことを示すために、「ヌル」または何らかの他のインジケータをＰｒｏＳｅプロトコル８０４へ送り、それによって、発見期間の中で無線リソースが利用可能でないことを示すことによって、何らかのアクションが行われる必要があることをＰｒｏＳｅプロトコル８０４に示す。

[0090] 再び、ＰｒｏＳｅプロトコル８０４は、ＮＡＳレイヤ８０６またはＲＲＣレイヤ８０８をトリガするべきかどうかを決定する。ここで、発見サポートフラグおよびトリガ必要フラグが両方とも１に設定されているので、またＵＥ８０２が接続状態へ遷移しているので、ＵＥ８０２の状態遷移は必要とされない。従って、ＰｒｏＳｅプロトコル８０４は、トリガをＲＲＣレイヤ８０８へ送ることを決定する。

[0091] より詳細には、ＴｘＯＰ時間を取得することに失敗することの結果として、ＰｒｏＳｅプロトコル８０４は、ＲＲＣレイヤ８０８によって設定された上述の２つのフラグを検査する。ＬＴＥ−Ｄがサポートされるがアクションが必要とされることをＲＲＣレイヤ８０８が示すとき（例えば、発見サポートフラグおよびトリガ必要フラグが両方とも１に設定されているとき）、ＰｒｏＳｅプロトコル８０４は検査して、ＵＥ８０２が接続状態にあるのか、それともアイドル状態にあるのかを決定する。ＳＩＢが利用可能なリソース（例えば、タイプ１リソースまたはタイプ２リソース）として何を示すのかをＰｒｏＳｅプロトコル８０４が知っている必要がないので、その情報は、ＰｒｏＳｅプロトコル８０４へ（例えば、ＲＲＣレイヤ８０８のフラグから）通信される必要がない。すなわち、ＴｘＯＰ時間を取得するための失敗した試行に続いて、ＰｒｏＳｅプロトコル８０４は、ＵＥ８０２の状態（例えば、接続状態またはアイドル状態）を決定するべきであることを知るために、トリガ必要フラグが１に設定されていることだけを知っていればよい。本事例では、ＵＥ８０２が接続状態にあるので（例えば、ＵＥ８０２のＮＡＳレイヤ８０６が接続状態にあるので）、状態遷移は必要とされず、ＰｒｏＳｅプロトコル８０４は、リソースを求める要求（例えば、ＲＲＣ Ｄ２Ｄリソース要求）をｅＮＢ８１２へ送るようにＲＲＣレイヤ８０８に告げる。

[0092] トリガ（例えば、Ｄ２Ｄ要求のためのトリガ）をＰｒｏＳｅプロトコル８０４から受信すると、ＲＲＣレイヤ８０８は、要求（例えば、ＲＲＣ Ｄ２Ｄリソース要求）をｅＮＢ８１２へ送る。その後、ｅＮＢ８１２は、応答（例えば、ＲＲＣ Ｄ２Ｄリソース応答）をＲＲＣレイヤ８０８へ送り返すことによって要求に応答して、ＲＲＣレイヤ８０８に応答する。従って、説明されるＲＲＣ Ｄ２Ｄメッセージ交換を使用することによって、ｅＮＢ８１２は、ネットワークトラフィック（例えば、対象のＵＥ８０２と、ネットワークに接続するために同じｅＮＢ８１２を使用する様々な他のＵＥとを伴うトラフィック）をより良くスケジュールできる。

[0093] 次いで、ＲＲＣレイヤ８０８は、ｅＮＢ８１２から受信された応答に含まれる情報に従って、ＭＡＣレイヤ８１０においてＭＡＣ Ｄ２Ｄ無線リソースを構成する。すなわち、ＲＲＣレイヤ８０８とｅＮＢ８１２との間のメッセージ交換の結果として取得された情報に従って、Ｄ２ＤのためのＭＡＣ Ｄ２Ｄ無線リソースが設定される。次いで、ＭＡＣレイヤ８１０は、Ｄ２Ｄ送信のためのＴｘＯＰ時間をＰｒｏＳｅプロトコル８０４に提供できる。

[0094] 前に説明した事例１ａと同様に、また図９に示すように、ＰｒｏＳｅプロトコル８０４がＴｘＯＰ時間を成功裡に取得すると、ＰｒｏＳｅプロトコル８０４は、ＭＩＣを計算し、その後、取得されたＴｘＯＰ時間に従って、対象のＰｒｏＳｅ Ａｐｐコードおよび計算されたＭＩＣに対応するコマンドをＭＡＣレイヤ８１０へ送る。その後、ＭＡＣレイヤ８１０は、受信されたコマンドに従ってＤ２Ｄ送信を開始する。

[0095] 図１０は、ＵＥレイヤとｅＮＢとの間の例示的なメッセージングを示す第２の図１０００である。以下に図１０を参照して、上述の事例１ｃを説明する。本事例では、ＵＥ８０２が、アイドル状態から接続状態へ遷移する。再び、ｅＮＢ８１２のネットワークがＬＴＥ−Ｄをサポートし、タイプ１リソースが利用可能であることをＳＩＢが示す。

[0096] 従って、ＲＲＣレイヤ８０８は、ＭＡＣレイヤ８１０の中のＤ２Ｄ無線リソースをヌルに設定する。すなわち、ＭＡＣ Ｄ２Ｄ無線リソースがＲＲＣレイヤ８０８によってＭＡＣレイヤ８１０から除去され、その結果、ＲＲＣレイヤ８０８とｅＮＢ８１２との間の、前に説明したＲＲＣメッセージ交換に含まれる情報に従って、ＲＲＣレイヤ８０８がＭＡＣ Ｄ２Ｄ無線リソースを後で設定できる。さらに、ＲＲＣレイヤ８０８は、ＰｒｏＳｅプロトコル８０４によって見られ得る情報である発見サポートフラグとトリガ必要フラグの両方をセットする。

[0097] 本事例では、ＲＲＣレイヤ８０８がＭＡＣレイヤ８１０からＭＡＣ無線リソースを除去したことにＰｒｏＳｅプロトコル８０４が気づいていないので、ＰｒｏＳｅプロトコル８０４は、取得されたＰｒｏＳｅ Ａｐｐコードに基づいてＭＩＣを計算し、ＰｒｏＳｅ Ａｐｐコードおよび計算されたＭＩＣに従ってコマンドをＭＡＣレイヤ８１０へ送る。事例１ａとは異なり、ＭＡＣレイヤ８１０が、ＲＲＣレイヤ８０８によって前に除去されたそれのＲＲＣ無線リソースを有していて、再構成されていないので、ＰｒｏＳｅプロトコル８０４によって送られるコマンドは、ＭＡＣレイヤ８１０によって誤って受信される。

[0098] 従って、本事例で、ＭＡＣレイヤ８１０は、ＭＡＣレイヤ８１０にとって利用可能なＤ２Ｄ無線リソースがないことをＰｒｏＳｅプロトコル８０４に通知するために、エラー通知をＰｒｏＳｅプロトコル８０４へ送り返すか、または、代替として、ＰｒｏＳｅプロトコル８０４は、ＴｘＯＰ時間をＭＡＣレイヤ８１０から取得するためのそれの試行に単に失敗する（例えば、設計の選択が、ＭＡＣレイヤ８１０がエラー通知をＰｒｏＳｅプロトコル８０４へ送るための能力を取り除く場合）。

[0099] エラー通知をＭＡＣレイヤ８１０から受信すると（または、ＴｘＯＰ時間を取得することに失敗すると）、トリガをＲＲＣレイヤ８０８へ送るべきかどうかを（例えば、図９、事例１ｂ）、またはアイドル状態から接続状態へのＵＥ８０２の状態遷移を開始するべきかどうかを（例えば、図１１に関して以下でさらに説明される事例２ａ）、ＰｒｏＳｅプロトコル８０４が決定できるように、ＰｒｏＳｅプロトコル８０４は、ＵＥ８０２が接続状態にあるのか、それともアイドル状態にあるのかを決定する。

[00100] 本事例で、ＰｒｏＳｅプロトコル８０４は、ＵＥ８０２がアイドル状態にあることを、ＮＡＳレイヤ８０６と通信することによって認識する。ＵＥのＮＡＳレイヤ８０６がアイドル状態にあるので、ＰｒｏＳｅプロトコル８０４は、「レガシーメッセージ」または「サービス要求」と呼ばれるものを使用して、ＵＥ８０２の状態遷移をトリガしようと試みる。レガシーメッセージ／サービス要求を使用することによって、ＰｒｏＳｅプロトコル８０４はＮＡＳレイヤ８０６と通信し、ＮＡＳレイヤ８０６は、ＵＥ８０２を接続状態へ遷移させ（ＥＣＭ＿ＣＯＮＮＥＣＴＥＤ）、状態遷移が起こったことをＰｒｏＳｅプロトコル８０４に示す。

[00101] その後、また図９に示す事例１ｂと同様に、ＰｒｏＳｅプロトコル８０４は、Ｄ２Ｄ要求のためのトリガをＲＲＣレイヤ８０８へ送り、それによって、ＲＲＣレイヤ８０８にリソースをネットワークからｅＮＢ８１２を介して取り出すように命令する。トリガを受信すると、ＲＲＣレイヤ８０８は、要求メッセージ（例えば、ＲＲＣ Ｄ２Ｄリソース要求メッセージ）をｅＮＢ８１２へ送り、ｅＮＢ８１２は、応答メッセージ（例えば、ＲＲＣ Ｄ２Ｄリソース応答メッセージ）をＲＲＣレイヤ８０８へ送ることによって応答する。次いで、ＲＲＣレイヤ８０８は、ｅＮＢ８１２から受信された応答に含まれる情報に従って、ＭＡＣレイヤ８１０においてＭＡＣ Ｄ２Ｄ無線リソースを構成し、それによって、ＰｒｏＳｅプロトコル８０４がＴｘＯＰ時間をＭＡＣレイヤ８１０から成功裡に取得することを可能にする。ＰｒｏＳｅプロトコル８０４がＴｘＯＰ時間を成功裡に取得すると、ＰｒｏＳｅプロトコル８０４は、ＭＩＣを計算し、その後、取得されたＴｘＯＰ時間に従って、対象のＰｒｏＳｅ ＡｐｐコードおよびＭＩＣに対応するコマンドをＭＡＣレイヤ８１０へ送る。その後、ＭＡＣレイヤ８１０は、受信されたコマンドに従って送信を開始する。

[00102] 図１１は、ＵＥレイヤとｅＮＢとの間の例示的なメッセージングを示す第３の図１１００である。図１１を参照して、上述の事例２ａを説明する。本事例では、ＵＥ８０２がアイドル状態である。例示的な実施形態に従って前に説明したシナリオとは異なり、タイプ１リソースが利用可能であることをＳＩＢは示さず、代わりに、Ｄ２Ｄ通信がネットワークによってサポートされる（例えば、ネットワークがＬＴＥ−Ｄをサポートする）ことを示すにすぎない。

[00103] 従って、利用可能な特定のタイプのリソースに関する情報（例えば、タイプ１またはタイプ２であるかどうか）をＳＩＢが提供しないので、ＭＡＣ Ｄ２Ｄ無線リソースは、ＲＲＣレイヤ８０８によってＭＡＣレイヤ８１０から除去され、ＲＲＣレイヤ８０８は、ＰｒｏＳｅプロトコル８０４によって見られる情報である発見サポートフラグ（例えば、Ｄ２Ｄ通信サポートフラグ）とトリガ必要フラグの両方をセットする。フラグのうちの両方がセットされるので、またＵＥ８０２がアイドル状態にあるので、ＵＥ８０２は、接続状態になるように状態を遷移させる。

[00104] 再び、ＰｒｏＳｅプロトコル８０４は、取得されたＰｒｏＳｅ Ａｐｐコードに基づいてＭＩＣを計算し、ＰｒｏＳｅ Ａｐｐコードおよび計算されたＭＩＣに従ってコマンドをＭＡＣレイヤ８１０へ送る。しかしながら、ＭＡＣレイヤ８１０が、ＲＲＣレイヤ８０８によって前に除去されたそれのＤ２Ｄ無線リソースを有していたので、ＰｒｏＳｅプロトコル８０４は、ＴｘＯＰ時間をＭＡＣレイヤ８１０から取得するためのそれの試行に失敗する。ＴｘＯＰ時間を取得することに失敗すると、ＰｒｏＳｅプロトコル８０４はＮＡＳレイヤ８０６と通信し、ＮＡＳレイヤ８０６は、ＵＥ８０２がアイドル状態にあることをＰｒｏＳｅプロトコル８０４に示す。

[00105] ＵＥ８０２がアイドル状態にあるので、ＰｒｏＳｅプロトコル８０４は、ＮＡＳレイヤ８０６にサービス要求（ＳＲ）（例えば、呼出しを開始するタイプを有するサービス要求）をＲＲＣレイヤ８０８へ（例えば、図８に示す対話チャネル８２２’を介して）送らせるために、トリガをＮＡＳレイヤ８０６へ送る。次いで、ＮＡＳレイヤ８０６は、サービス要求をＲＲＣレイヤ８０８へ送り、ＲＲＣレイヤ８０８は、ＭＡＣレイヤ８１０と通信し、サービス要求に対応する手順に従ってｅＮＢ８１２を介してネットワークとも通信する。

[00106] その後、ＵＥ８０２が接続状態になり、ＵＥ８０２が接続されているという表示をＮＡＳレイヤ８０６が受信すると、ＮＡＳレイヤ８０６は、ＵＥが接続状態（ＥＣＭ＿ＣＯＮＮＥＣＴＥＤ）にあることをＰｒｏＳｅプロトコル８０４へ（例えば、図８に示す対話チャネル８２２を介して）通信する。ＰｒｏＳｅプロトコル８０４とＮＡＳレイヤ８０６との間の上記の対話が、ＵＥ８０２が接続状態にあった後にそれの接続を失っているとき（例えば、図１１における事例２ｃ）に起こり得ることに留意されたい。

[00107] その後、図９および図１０に関して説明したシナリオ（例えば、事例１ｂおよび１ｃ）と類似の方式で、ＰｒｏＳｅプロトコル８０４は、Ｄ２Ｄ要求のためのトリガをＲＲＣレイヤ８０８へ送り、ＲＲＣレイヤ８０８に要求をｅＮＢ８１２へ送らせ、ｅＮＢ８１２は、その後、応答を送り返すことによって要求に応答する。次いで、ＲＲＣレイヤ８０８は、応答に含まれる情報に従って、ＭＡＣレイヤ８１０においてＭＡＣ Ｄ２Ｄ無線リソースを構成し、ＰｒｏＳｅプロトコル８０４は、ＴｘＯＰ時間をＭＡＣレイヤ８１０から成功裡に取得する。

[00108] 本事例では、ＰｒｏＳｅプロトコル８０４がオーバージエアのＰｒｏＳｅコードをいつ送ることができるのかをＰｒｏＳｅプロトコル８０４が理解することを可能にするために、ＰｒｏＳｅプロトコル８０４は、ＴｘＯＰ時間においてＭＡＣレイヤ８１０にポーリングする。ＰｒｏＳｅプロトコル８０４がＴｘＯＰ時間を成功裡に取得すると、ＰｒｏＳｅプロトコル８０４は、ＭＩＣを計算し、取得されたＴｘＯＰ時間に従って、対象のＰｒｏＳｅ ＡｐｐコードおよびＭＩＣに対応するコマンドをＭＡＣレイヤ８１０へ送る。その後、ＭＡＣレイヤ８１０は、受信されたコマンドに従って送信を開始する。

[00109] 図１２は、ＵＥレイヤとｅＮＢとの間の例示的なメッセージングを示す第４の図１２００である。図１２を参照して、上述の事例２ｂを説明する。図１１に示すもの（例えば、事例２ａ）と同様に、タイプ１リソースが利用可能であることをＳＩＢは示さず、代わりに、Ｄ２Ｄ通信がネットワークによってサポートされる（例えば、ネットワークがＬＴＥ−Ｄをサポートする）ことを示すにすぎない。しかしながら、事例２ａに関して説明したシナリオとは異なり、ＵＥ８０２は接続状態にある。従って、所期のＤ２Ｄ通信のためにＵＥ８０２の状態遷移は必要とされない。

[00110] 再び、ＭＡＣ無線リソースは、ＲＲＣレイヤ８０８によってＭＡＣレイヤ８１０から除去され、ＲＲＣレイヤ８０８は、ＰｒｏＳｅプロトコル８０４によって見られる情報である発見サポートフラグとトリガ必要フラグの両方をセットする。

[00111] 再び、ＰｒｏＳｅプロトコル８０４は、取得されたＰｒｏＳｅ Ａｐｐコードに基づいてＭＩＣを計算し、ＰｒｏＳｅ Ａｐｐコードおよび計算されたＭＩＣに従ってコマンドをＭＡＣレイヤ８１０へ送り、ＴｘＯＰ時間をＭＡＣレイヤ８１０から取得するためのそれの試行に失敗する。ＴｘＯＰ時間を取得することに失敗すると、ＰｒｏＳｅプロトコル８０４は、ＲＲＣレイヤ８０８によって設定されたフラグを検査する。トリガ必要フラグが１に設定されているので、ＰｒｏＳｅプロトコル８０４は、ＵＥ８０２が接続状態にあるのか、それともアイドル状態にあるのかを決定する。ＰｒｏＳｅプロトコル８０４は、本シナリオではＵＥ８０２が接続状態にあることを示すＮＡＳレイヤ８０６と通信することによって、ＵＥ８０２の状態を決定する。

[00112] ＵＥ８０２が接続状態にあるので、事例２ａに関して説明したシナリオとは異なり、ＰｒｏＳｅプロトコル８０４は、ＵＥ８０２をアイドル状態から接続状態へ遷移させるためにトリガをＮＡＳレイヤ８０６へ送ることを必要としない。従って、図９、図１０、および図１１に関して説明したシナリオ（事例１ｂ、１ｃ、および２ａ）と同様に、ＰｒｏＳｅプロトコル８０４は、Ｄ２Ｄリソース要求のためのトリガをＲＲＣレイヤ８０８へ送り、ＲＲＣレイヤ８０８は、ｅＮＢ８１２とのメッセージ交換（例えば、ＲＲＣ Ｄ２Ｄリソース要求メッセージ交換）に関与する。次いで、ＲＲＣレイヤ８０８は、Ｄ２Ｄリソース要求メッセージ交換を介してｅＮＢ８１２から取得された情報に従って、ＭＡＣ Ｄ２Ｄ無線リソースをＭＡＣレイヤ８１０において構成し、ＰｒｏＳｅプロトコル８０４は、ＴｘＯＰ時間をＭＡＣレイヤ８１０から成功裡に取得する。次いで、ＰｒｏＳｅプロトコル８０４は、取得されたＴｘＯＰ時間に従って、対象のＰｒｏＳｅ Ａｐｐコードおよび計算されたＭＩＣに対応するコマンドをＭＡＣレイヤ８１０へ送り、それによって、ＭＡＣレイヤ８１０が受信されたコマンドに従って送信を開始することを可能にする。

[00113] 図１３は、ＵＥレイヤとｅＮＢとの間の例示的なメッセージングを示す第５の図１３００である。図１１および図１３を参照して、上述の事例２ｃを説明する。前に説明した実施形態とは異なり、Ｄ２ＤリソースがｅＮＢ８１２によって割り振られていることをシステム情報／ＳＩＢが示す。すなわち、ＵＥ８０２がそれのリソースを選ぶためのタイプ１リソースプールを有する代わりに、ｅＮＢ８１２が接続されているネットワークによって決定されるように、タイプ２リソースがＵＥ８０２に割り当てられ、または割り振られる。すなわち、タイプ２は、ＵＥ８０２がリソース（例えば、タイプ１）のプールからリソースを選択するのではなく、ネットワークが具体的にどのリソースを使用するべきかをＵＥ８０２に告げ、専用のリソースをＵＥ８０２に提供することを示す。さらに、ＵＥ８０２が接続状態にある。

[00114] 従って、本事例で、ＰｒｏＳｅプロトコル８０４は、ＴｘＯＰ時間をＭＡＣレイヤ８１０から成功裡に取得し、ＰｒｏＳｅプロトコル８０４は、取得されたＴｘＯＰ時間に従って、対象のＰｒｏＳｅ Ａｐｐコードおよび計算されたＭＩＣに対応するコマンドをＭＡＣレイヤ８１０へ送り、それによって、ＭＡＣレイヤ８１０が受信されたコマンドに従って送信を開始することを可能にする。しかしながら、本シナリオでは、ＭＡＣレイヤ８１０が所期のＤ２Ｄ通信を成功裡に完了する前に、ｅＮＢ８１２が、図１３に示すように、ＲＲＣ Ｄ２Ｄリソース取消しメッセージをＲＲＣレイヤ８０８へ送る（ただし、以下の説明は、図１１に示すように、ＵＥ８０２がどういうわけか別のやり方で接続を失うときにも適用される）。

[00115] その後、ＲＲＣレイヤ８０８は、発見サポートフラグとトリガ必要フラグの両方がセットされていることをＰｒｏＳｅプロトコル８０４に示し、ＲＲＣレイヤ８０８は、ＭＡＣレイヤ８１０からＭＡＣ Ｄ２Ｄ無線リソースを除去する。従って、ＰｒｏＳｅプロトコル８０４がＰｒｏＳｅ Ａｐｐコードおよび計算されたＭＩＣに従ってコマンドをＭＡＣレイヤ８１０へ送るとき、ＰｒｏＳｅプロトコル８０４は、ＴｘＯＰ時間をＭＡＣレイヤ８１０から取得するためのそれの試行に失敗する。その後、ＰｒｏＳｅプロトコル８０４はＮＡＳレイヤ８０６と通信し、ＮＡＳレイヤ８０６はＵＥ８０２が依然として接続状態にあることを示し、従って、状態遷移は必要とされず、ＰｒｏＳｅプロトコル８０４は、サービス要求ＳＲのためのトリガをＮＡＳレイヤ８０６へ送ることを必要としない（事例２ａに関して説明したシナリオの事例であったように）。

[00116] 再び、図９、図１０、図１１、および図１２に関して説明したシナリオ（事例１ｂ、１ｃ、２ａ、および２ｂ）と同様に、ＵＥ８０２が接続状態にあることをＮＡＳレイヤ８０６が示すので、ＰｒｏＳｅプロトコル８０４は、Ｄ２Ｄ要求のためのトリガをＲＲＣレイヤ８０８へ送り、ＲＲＣレイヤ８０８は、ｅＮＢ８１２とのＲＲＣ Ｄ２Ｄリソースメッセージ交換に関与し、Ｄ２Ｄリソースメッセージ交換に従って、ＭＡＣレイヤ８１０においてＭＡＣ Ｄ２Ｄ無線リソースを構成する。次いで、ＰｒｏＳｅプロトコル８０４は、ＴｘＯＰ時間をＭＡＣレイヤ８１０から成功裡に取得し、取得されたＴｘＯＰ時間に従って、対象のＰｒｏＳｅ Ａｐｐコードおよび計算されたＭＩＣに対応するコマンドをＭＡＣレイヤ８１０へ送り、それによって、ＭＡＣレイヤ８１０が受信されたコマンドに従って送信を開始することを可能にする。

[00117] 例示的な実施形態によって遭遇され得る他の事例によれば、ＲＲＣレイヤ８０８がそれのＲＲＣ Ｄ２Ｄリソース要求へのｅＮＢ８１２からの応答を受信する際に、またはＲＲＣレイヤ８０８がＭＡＣ Ｄ２Ｄ無線リソースを構成する際に、エラーが起こったとき、ＰｒｏＳｅプロトコル８０４は、タイムアウトが発生した後、Ｄ２Ｄ要求のためのトリガをＲＲＣレイヤ８０８へ再び送る。すなわち、ＰｒｏＳｅプロトコル８０４からＲＲＣレイヤ８０８へ最初にトリガを送ることに続いて所定量の時間が過ぎた後、ＰｒｏＳｅプロトコル８０４がＭＡＣレイヤ８１０からの通信を受信しないとき、ＰｒｏＳｅプロトコル８０４は、上記で説明したプロセスの一部分を再び開始するために、Ｄ２Ｄ要求をＲＲＣレイヤ８０８へ再び送る。

[00118] 最後に、代替事例（例えば、事例３、図示せず）で、ＲＲＣレイヤ８０８は、発見サポートフラグがセットされていないこと（例えば、サービング基地局／ｅＮＢ８１２に接続されているネットワークがピア発見をサポートしないこと）をＰｒｏＳｅプロトコル８０４に示すことがある。そのようなシナリオで、ＰｒｏＳｅプロトコル８０４は、Ｄ２Ｄ動作を試みるべきでない。

[00119] ＰｒｏＳｅプロトコル８０４が複数のＰｒｏＳｅ Ａｐｐコードを配送しようと求める状況も、例示的な実施形態による潜在的な事例として考えられる。ＰｒｏＳｅプロトコル８０４は、オーバージエアで告知されるべき複数のＰｒｏＳｅアプリケーションコードを有し得る。ＰｒｏＳｅプロトコル８０４が、送るべき複数のＰｒｏＳｅアプリケーションコードを有するとき、ＰｒｏＳｅプロトコル８０４は、複数のＴｘＯＰ時間を、対話チャネル８２３を介してＭＡＣレイヤ８１０に要求し、そこから取得する。Ｄ２Ｄ送信のためのリソースが周波数領域と時間領域の両方において分配されるので、複数のＴｘＯＰ機会のためのリソースが、異なる絶対時間値に対応することが可能である。例えば、ＰｒｏＳｅプロトコル８０４が２つの送信機会を要求するとき、ＭＡＣレイヤ８１０は、時間ｔ秒と時間ｔ＋１秒とを戻し得る。これらの時間は、タイプ１リソースプールからの選択に基づき得、またはｅＮＢ８１２によって決定されるようなリソースの割振りに基づき得る。

[00120] 従って、本シナリオで、ＰｒｏＳｅプロトコル８０４は、ＰｒｏＳｅアプリケーションコードの各々に対して、異なる時間に基づいて個々のＭＩＣを計算する。例えば、ＰｒｏＳｅ Ａｐｐコード１用の第１のＭＩＣが時間ｔを用いて計算され、ＰｒｏＳｅ Ａｐｐコード２用の第２のＭＩＣが時間ｔ＋１を用いて計算される。

[00121] 従って、送信時間ｔおよびｔ＋１が、異なるメッセージ用のそれらそれぞれのＭＩＣと整合することを確実にし、それによって、（ＵＥ８０２がメッセージをそこへ配送しようと求める）受信しているＵＥがメッセージを正しく検証できることを確実にするために、ＰｒｏＳｅプロトコル８０４が送信のためにＭＡＣレイヤ８１０へＰｒｏＳｅ ＡｐｐコードとＭＩＣとを送るとき、ＰｒｏＳｅプロトコル８０４は、どのＰｒｏＳｅ Ａｐｐコードがどの時間において送信されるべきかをＭＡＣレイヤ８１０に通知する。例示的な実施形態は、ＭＡＣレイヤ８１０とＰｒｏＳｅプロトコル８０４との間で送信機会を示すための２つの手法を提供する。すなわち、ＭＡＣレイヤ８１０とＰｒｏＳｅプロトコル８０４との間で送信機会ＴｘＯＰ時間を示すための、２つの可能な手法が以下に提供される。

[00122] 第１の手法では、インデックス付けするシステムが、異なるＴｘＯＰ時間を区別するために、それぞれのＴｘＯＰ時間に割り当てられる別個のインデックス番号を使用する。例えば、ＰｒｏＳｅプロトコル８０４が複数のＴｘＯＰを要求するとき、ＭＡＣレイヤ８１０は、これらのＴｘＯＰ時間の各々を、インデックス番号を用いてインデックス付けする。

[00123] ＰｒｏＳｅプロトコル８０４が、ＰｒｏＳｅ Ａｐｐコードのうちの１つと、対応するＭＩＣとをＭＡＣレイヤ８１０に向かって下へ（例えば、下位レイヤを通じて）送るとき、ＰｒｏＳｅプロトコル８０４は、特定のＭＩＣの計算のために使用される特定のＴｘＯＰ時間に対応するインデックス番号を示し得る。本実施形態で、ＭＡＣレイヤ８１０は、ＴｘＯＰ時間を順に提供し、ＰｒｏＳｅプロトコル８０４は、様々なＰｒｏＳｅプロトコルコードと、対応するＭＩＣとを、それぞれのＭＩＣ計算のために使用される時間と同じ順序に従って送り得る。ＭＡＣレイヤ８１０がＰｒｏＳｅプロトコル８０４に応答するとき、ＭＡＣレイヤ８１０は、たとえ時間値のうちのいくつかが同一であり得ても、提供されたＴｘＯＰ時間の各々に対して対応する時間値を含める。

[00124] 第２の代替手法で、ＰｒｏＳｅプロトコル８０４は、ＰｒｏＳｅプロトコル８０４がＰｒｏＳｅ Ａｐｐコードを送信するとき、ＰｒｏＳｅ ＡｐｐコードとＭＩＣとを、ＭＩＣ計算のために使用されるＴｘＯＰ時間と一緒に送る。従って、ＰｒｏＳｅプロトコル８０４は、ＰｒｏＳｅ Ａｐｐコードの各々に対して１つ、複数のＴｘＯＰ機会を要求するためのＴｘＯＰ要求を送り得る。次いで、ＰｒｏＳｅプロトコル８０４は、ＭＡＣレイヤ８１０に送られたＴｘＯＰ要求の中で、送信されるべきＰｒｏＳｅ Ａｐｐコードの数を示す。ＭＡＣレイヤ８１０は、ＰｒｏＳｅプロトコル８０４から受信された要求に従って、ＴｘＯＰ時間のリストに応答し得る。本実施形態のＭＡＣレイヤ８１０は、ＴｘＯＰ時間ごとに個々のインデックス番号に応答し得、ＴｘＯＰ時間の全てに対するインデックスを暗示する順に送り得、その場合、ＭＡＣレイヤ８１０は、様々なインデックス番号とそれらの対応するＴｘＯＰ時間との間のマッピングを覚えている。しかしながら、ＰｒｏＳｅプロトコル８０４は、ＰｒｏＳｅ Ａｐｐコード送信のためのコマンドを送るときのＴｘＯＰ時間を含めてよく、それによって、ＭＡＣレイヤ８１０がインデックス番号マッピングを覚えている必要をなくす。

[00125] さらに、代替動作で、ＰｒｏＳｅプロトコル８０４は、送るべき複数のコードを有するとき、複数のＴｘＯＰ時間が要求されていることを示す単一のＴｘＯＰ要求を送る代わりに、複数の要求を使用し得る。そのような代替動作で、ＰｒｏＳｅプロトコル８０４は、それがＴｘＯＰにとって新しいコードであるかどうか、またはＰｒｏＳｅプロトコル８０４が既存の／前のＰｒｏＳｅアプリケーションコード用の新しいＴｘＯＰを要求しているかどうかを、要求の中で示すことになる。例えば、ＰｒｏＳｅプロトコル８０４は、インデックス番号を用いてＰｒｏＳｅ Ａｐｐコードをインデックス付けでき、それを要求の中に含めることができる。このようにして、ＭＡＣレイヤは要求が新しいＰｒｏＳｅ Ａｐｐコードのためであるかどうかを知るが、ＭＡＣレイヤは、インデックスとそれに割り振られた対応するＴｘＯＰリソースとのマッピングを覚えていてもよい。

[00126] ＲＲＣレイヤ８０８は、利用可能な無線リソースが変更されている状況に遭遇することがある。例えば、タイプ２リソース割振りの事例（例えば、図１３、事例２ｃ）で、ｅＮＢ８１２は、ｅＮＢ８１２の負荷に基づいて、またはＤ２Ｄ送信を要求しているＵＥの数に基づいて、ＵＥ８０２に割り振られたリソースを追加または削減することを決定し得る。利用可能な無線リソースが変更されているとき、ＲＲＣレイヤ８０８は、対応するアクションを行うようにＰｒｏＳｅプロトコル８０４に通知し得る。

[00127] 例えば、ＲＲＣレイヤ８０８は、システムレベルインジケータ（例えば、「リソース更新済み」インジケータ）を有する（利用可能な無線リソースが変更されているという）表示をＰｒｏＳｅプロトコル８０４に向かって送り得る。このことは、より多くのＴｘＯＰ時間をＭＡＣレイヤ８１０に要求するように、またはリソース割振りのためのトリガをリソースの程度が必要とされているという別の表示と一緒にＲＲＣレイヤ８０８へ送るように、ＰｒｏＳｅプロトコル８０４をトリガする。ＲＲＣレイヤ８０８は、ネットワークによって割り振られた実際のリソースに応答できる。

[00128] 代替実施形態では、ＲＲＣレイヤ８０８が利用可能な無線リソースが変更されている状況に遭遇するとき、ＲＲＣレイヤ８０８は、更新されたリソースを用いてＭＡＣレイヤ８１０を構成するだけでよい。従って、ＰｒｏＳｅプロトコル８０４が、ＭＡＣレイヤ８１０と通信することによって次の機会においてＴｘＯＰ時間を要求するとき、ＰｒｏＳｅプロトコルはネットワークリソースの変更に気づく（例えば、ＰｒｏＳｅプロトコルは、３つのＴｘＯＰ値をＭＡＣレイヤ８１０に要求したが、２つだけを見る場合がある）。この場合、ＰｒｏＳｅプロトコル８０４は、対応する動作（例えば、優先度のセットに従ってＰｒｏＳｅ Ａｐｐコードのうちの１つもしくは複数の送信を中断すること、または３つのコードの送信を２つの可能なＴｘＯＰ機会を用いて交互に行うこと）を決定することになる。

[00129] 記載された事例の上記の説明は、送信機ＵＥ８０２（例えば、ＬＴＥ−Ｄにおいて告知しているＵＥ）としてＵＥ８０２に焦点を当てたが、上記の説明が、受信しているＵＥ（例えば、他のＵＥ、または監視しているＵＥ）にも適用可能であり得ることに留意されたい。この場合、監視しているＵＥは接続状態にあり、さもなければ、ＳＩＢの中にリソースがないことをネットワークが示すとき、ＲＲＣレイヤ８０８がトリガ必要フラグをセット（例えば、値を１に設定する）し得る。ＰｒｏＳｅプロトコル８０４は、ＰｒｏＳｅ Ａｐｐコードを受信することを望むと決定するとき、ＲＲＣ Ｄ２Ｄリソース要求メッセージをｅＮＢ８１２に向かって送るようにＲＲＣレイヤ８０８をトリガする。ｅＮＢ８１２が、対応する確認に応答するとき、ＲＲＣレイヤ８０８は、それに応じてＤ２Ｄリソースにおいて受信するようにＭＡＣレイヤ８１０を設定し得る。

[00130] 本事例で、ＲＲＣ Ｄ２Ｄリソース要求は、もはやＤ２Ｄ送信リソースを求めるものでなく、代わりに、受信しているリソースにおいてＵＥがＤ２Ｄ動作を行うことになることをｅＮＢ８１２に示すために使用され、その結果、ｅＮＢ８１２は、それらのリソースを介したいかなる通常のＬＴＥ通信をスケジュールすることも回避するべきであり、それによって、ＵＥの他のアプリケーションへの悪影響を潜在的に回避する。従って、ｅＮＢ８１２からＲＲＣレイヤ８０８へ送り返されるＤ２Ｄリソース応答メッセージは、リソース情報を含まなくてよく、代わりに確認だけを含み得る。

[00131] 別の代替事例で、告知しているＵＥは監視しているＵＥであり得、ここにおいて同じ動作が適用される。そのような事例では、ｅＮＢ８１２へ送られるＲＲＣ Ｄ２Ｄリソース要求メッセージは、メッセージが送信リソースに対応するのか、スケジューリング支援を受信することに対応するのか、それとも両方に対応するのかを示すことになる。ｅＮＢ８１２から送り返されるＲＲＣ Ｄ２Ｄリソース応答メッセージは、メッセージが送信リソースに、または送信リソースとスケジューリング支援を受信することの両方に対応するとき、送信リソースを含むことになる。

[00132] 別の代替事例で、監視しているＵＥは、それが特定のパブリックランドモバイルネットワーク（ＰＬＭＮ）または特定の国コードに対してのみ受信するように望むことを、ＲＲＣレイヤ８０８に示し得る。その場合、ＲＲＣレイヤ８０８は、その要求を解釈し得、対応するＲＲＣ Ｄ２Ｄリソース要求の中でその希望を示し得る。ＲＲＣ Ｄ２Ｄリソース応答において、ｅＮＢ８１２は、監視するアクションを行うためのいくつかの方式で動作するように、ＵＥ８０２に命令し得る（例えば、いくつかの時間において周波数の再同調用のギャップを残すようにＵＥ８０２に命令し得る）。

[00133] 図１４は、ワイヤレス通信の方法のフローチャート１４００である。方法は、ＵＥ（例えば、ＵＥ８０２）によって行われ得る。

[00134] ステップ１４０２において、ＰｒｏＳｅプロトコル（例えば、ＰｒｏＳｅプロトコル８０４）が、ＰｒｏＳｅアプリケーションコードを取得する。ステップ１４０４において、ＲＲＣレイヤ（例えば、ＲＲＣレイヤ８０８）が、システム情報（例えば、ＳＩＢ）を取得する。ステップ１４０６において、ＲＲＣレイヤは、ネットワーク（例えば、ｅＮＢ８１２のネットワーク）がピア発見をサポートすることをシステム情報が示すかどうか（例えば、ネットワークがＬＴＥ−Ｄネットワークであるかどうか）を決定する。ネットワークがＤ２Ｄ通信をサポートしないことをシステム情報が示す場合、ＲＲＣレイヤは、ステップ１４０８において、それに対応する値が０になるように、フラグ（例えば、第２のフラグ、すなわち発見サポートフラグ）をアンセットする。従って、ＰｒｏＳｅプロトコルはＤ２Ｄ通信を試みるべきでなく、プロセスは終了される。

[00135] ネットワークがピア発見をサポートするか、またはＤ２Ｄ通信をサポートすることをシステム情報が示す場合、ＲＲＣレイヤは、ステップ１４１０において、それに対応する値が１になるように、フラグ（例えば、発見サポートフラグ、またはＤ２Ｄ通信サポートフラグ）をセットする。ステップ１４１２において、ＲＲＣレイヤは、システム情報がタイプ１リソースを示すかどうかを決定し、ステップ１４１４において、ＲＲＣレイヤは、ＵＥがアイドル状態にあるかどうかを決定する。ステップ１４１２および１４１４において、システム情報がタイプ１リソースを示さないこと、またはＵＥがアイドル状態にない（例えば、ＵＥが接続状態にある）ことのいずれかをＲＲＣレイヤが決定する場合、ＲＲＣレイヤは、ステップ１４１６において、別のフラグ（例えば、第１のフラグ、すなわちトリガ必要フラグ）をセットし、次いで、ステップ１４１８において、ＭＡＣレイヤ（例えば、ＭＡＣレイヤ８１０）のＤ２Ｄ無線リソースを除去する。

[00136] しかしながら、システム情報がタイプ１リソースを示すことと、ＵＥがアイドル状態にあることとをＲＲＣレイヤが決定する場合、ＲＲＣレイヤは、ステップ１４２０において、他のフラグをアンセットし（例えば、トリガ必要フラグを０に設定する）、ステップ１４２２において、ＭＡＣレイヤのＤ２Ｄ無線リソースを構成する。

[00137] ＲＲＣレイヤが、ステップ１４２２においてＭＡＣレイヤのＤ２Ｄ無線リソースを構成すること、またはステップ１４１８においてＭＡＣレイヤのＤ２Ｄ無線リソースを除去することのいずれかの後、ＰｒｏＳｅプロトコルは、ステップ１４２４において、ＭＡＣレイヤからＴｘＯＰ時間を取得しようと試みる。図１４のフレームワーク内で複数のＰｒｏＳｅアプリケーションコードが取得される場合があり、その場合、上記で説明したように、対応する複数のＭＩＣが計算され、複数のＴｘＯＰ時間がＭＡＣレイヤから取得され得ることに留意されたい。

[00138] ＰｒｏＳｅプロトコルの試行が成功した場合、ステップ１４２６において、ＰｒｏＳｅプロトコルは、ステップ１４０２において取得されたＰｒｏＳｅアプリケーションコード用のメッセージインテグリティチェックサム（ＭＩＣ）を計算し、ＭＩＣとＰｒｏＳｅアプリケーションコードとをＭＡＣレイヤへ送る。

[00139] しかしながら、ステップ１４２４におけるＭＡＣレイヤからＴｘＯＰ時間を取得するためのＰｒｏＳｅプロトコルの試行が失敗した場合、ステップ１４２８において、ＰｒｏＳｅプロトコルは、ＲＲＣレイヤによって設定されたフラグを検査する（例えば、トリガ必要フラグがセットされていることを確かめ、および／または発見サポートフラグがセットされていることを確かめる）。

[00140] ステップ１４２６においてＭＩＣとＰｒｏＳｅアプリケーションコードとをＭＡＣレイヤへ送った後、ステップ１４３０においてエラー通知がＰｒｏＳｅプロトコルによってＭＡＣレイヤから受信される場合、または１４２８においてトリガ必要フラグがセットされていることを確かめた後、ＰｒｏＳｅプロトコルは、ステップ１４３２において、ＵＥが接続状態にあるかどうかを決定するためにＮＡＳレイヤに確認する。

[00141] ステップ１４３２においてＵＥが接続状態にないと決定される場合、ステップ１４３４において、ＰｒｏＳｅプロトコルは、接続状態へ切り替わるようにＮＡＳレイヤをトリガするためのサービス要求を送る。次いで、ステップ１４３６において、ＵＥは接続状態へ遷移される。次いで、ステップ１４３８において、ＮＡＳレイヤは、ＲＲＣが接続状態にあることをＰｒｏＳｅプロトコルに示す。

[00142] ステップ１４３８の後、または代替として、ステップ１４３２においてＵＥが接続状態にあると決定される場合、ＰｒｏＳｅプロトコルレイヤは、ステップ１４４０において、リソースを求める要求をサービング基地局（例えば、ｅＮＢ８１２）へ送るようにＲＲＣレイヤに命令する。ステップ１４４２において、ＲＲＣレイヤは、サービング基地局からのリソースの割振りを要求する。ステップ１４４４において、サービング基地局は、ピア発見リソースまたはＤ２Ｄ通信リソースなどのＤ２Ｄリソースを割り振る応答をＲＲＣレイヤへ送る。その後、ＲＲＣレイヤはステップ１４２２に戻り、ＭＡＣレイヤの無線リソースを構成する。

[00143] しかしながら、ステップ１４３０においてエラー通知がＰｒｏＳｅプロトコルによってＭＡＣレイヤから受信されない場合、ステップ１４４６において無線リソースがｅＮＢによって取り消されていない場合、およびステップ１４４８においてＤ２Ｄ通信が終了されていない場合、ＵＥは、さらなる送信用の追加のＰｒｏＳｅアプリケーションコードを取得するためにステップ１４０２に戻り得る。

[00144] 代替として、リソースが取り消されている場合、ＲＲＣレイヤは、トリガ必要フラグをセットするためにステップ１４１６に戻る。ステップ１４４８においてＤ２Ｄ通信が終了されている場合、プロセスは終了する。

[00145] 図１５は、ワイヤレス通信の第１の方法を示す図１５００である。方法は、ＵＥ８０２などのＵＥによって行われ得る。１５０２において、ＵＥは、システム情報がＤ２Ｄ通信に対して受信されるかどうかを決定する。ＵＥの第１のレイヤは、システム情報を受信し得、少なくとも１つのフラグを設定し得、第１のレイヤよりも上位の第２のレイヤは、少なくとも１つのフラグを検査し得、Ｄ２Ｄリソース（例えば、ピア発見リソース）を決定するように第１のレイヤに要求し得る。

[00146] １５０４において、一構成では、システム情報がＤ２Ｄ通信に対して受信されていると決定されるとき、ＵＥは、Ｄ２Ｄリソース（例えば、共通ピア発見リソース）のセットがシステム情報の中で示されるかどうかを決定し得る。１５０６において、ＵＥは、ＵＥの無線リソース制御（ＲＲＣ）状態を決定し得る。

[00147] １５０８において、一構成では、システム情報がＤ２Ｄ通信に対して受信されていると決定されるとき、および共通ピア発見リソースのセットなどのＤ２Ｄリソースのセットがシステム情報の中で示されるとき、ＵＥは、Ｄ２Ｄリソースのセットを使用してＤ２Ｄピア発見通信などのＤ２Ｄ通信を行い得る。１５１０において、ＵＥは、Ｄ２Ｄリソースのセットを通じたＤ２Ｄ通信を停止させ得る。１５１２において、ＵＥは、ＲＲＣアイドル状態からＲＲＣ接続状態へ遷移し得る。

[00148] １５１４において、一構成では、システム情報がＤ２Ｄ通信に対して受信されていると決定されるとき、および共通ピア発見リソースのセットなどのＤ２Ｄリソースのセットがシステム情報の中で示されないとき、ＵＥは、割り振られたリソースのセットを使用してＤ２Ｄピア発見通信などのＤ２Ｄ通信を行い得る。１５１６において、ＵＥは、割り振られたリソースのセットの使用の取消しを受信し得る。

[00149] １５１８において、ＵＥは、システム情報が受信されるとき、システム情報に基づいて少なくとも１つのフラグを設定する。少なくとも１つのフラグは、Ｄ２Ｄリソースのセットがシステム情報の中で示されるかどうかに基づいて、および決定されたＲＲＣ状態に基づいて設定され得る。Ｄ２Ｄリソースのセットがシステム情報の中で示されると決定されるとき、およびＲＲＣ状態がＲＲＣアイドル状態であると決定されるとき、少なくとも１つのフラグを設定することは、Ｄ２Ｄリソースの割振りを求める要求が必要とされないことを第２のレイヤに対して示すために、少なくとも１つのフラグのうちの第１のフラグを設定することを含み得る。Ｄ２Ｄリソースのセットがシステム情報の中で示されると決定されるとき、およびＲＲＣ状態がＲＲＣ接続状態であると決定されるとき、少なくとも１つのフラグを設定することは、Ｄ２Ｄの割振りを求める要求が必要とされることを示すために、少なくとも１つのフラグのうちの第１のフラグを設定することを含み得る。Ｄ２Ｄリソースのセットがシステム情報の中で示されないと決定されるとき、およびＲＲＣ状態がＲＲＣアイドル状態であると決定されるとき、少なくとも１つのフラグを設定することは、Ｄ２Ｄリソースの割振りを求める要求が必要とされることを第２のレイヤに対して示すために、少なくとも１つのフラグのうちの第１のフラグを設定することを含み得る。Ｄ２Ｄリソースのセットがシステム情報の中で示されないと決定されるとき、およびＲＲＣ状態がＲＲＣ接続状態であると決定されるとき、少なくとも１つのフラグを設定することは、Ｄ２Ｄリソースの割振りを求める要求が必要とされることを第２のレイヤに対して示すために、少なくとも１つのフラグのうちの第１のフラグを設定することを含み得る。ＲＲＣアイドル状態からＲＲＣ接続状態へ遷移すると、少なくとも１つのフラグが設定され得る。少なくとも１つのフラグを設定することは、Ｄ２Ｄリソースの割振りを求める要求が必要とされることを示すために、少なくとも１つのフラグのうちの第１のフラグを設定することを含み得る。システム情報がＤ２Ｄ通信に対して受信されていないと決定されるとき、および少なくとも１つのフラグを設定することが、Ｄ２Ｄ通信がサポートされないことを示す、少なくとも１つのフラグのうちのフラグを設定することを含むとき、Ｄ２Ｄリソースはヌルセットであると決定され得る。１５２０において、ＵＥは、少なくとも１つのフラグに基づいてＤ２Ｄリソースを決定する。

[00150] 一構成で、第１のレイヤはＲＲＣレイヤであり、第２のレイヤはＰｒｏＳｅプロトコルレイヤである。事例１ａ、１ｂ、２ａ、２ｂの場合、一構成では、システム情報がＤ２Ｄ通信に対して受信されていると決定され（１５０２）、ＵＥは、共通ピア発見リソースのセットなどのＤ２Ｄリソースのセットがシステム情報の中で示されるかどうかを決定し（１５０４）、ＵＥのＲＲＣ状態を決定する（１５０６）。そのような構成では、少なくとも１つのフラグが、Ｄ２Ｄリソースのセットがシステム情報の中で示されるかどうかに基づいて、および決定されたＲＲＣ状態に基づいて設定される（１５１８）。

[00151] 一構成では、事例１ａの場合、Ｄ２Ｄリソース（例えば、共通ピア発見リソース）のセットがシステム情報の中で示されると決定され（１５０４）、ＲＲＣ状態がＲＲＣアイドル状態であると決定される（１５０６）。加えて、第１のレイヤは、Ｄ２Ｄリソースの割振りを求める要求が必要とされないことを第２のレイヤに対して示すために、少なくとも１つのフラグのうちの第１のフラグを設定することによって、少なくとも１つのフラグを設定する（１５１８）。一構成で、第１のレイヤは、Ｄ２Ｄ通信がサポートされることを示すために、少なくとも１つのフラグのうちの第２のフラグを設定することによって、少なくとも１つのフラグを設定する（１５１８）。一構成で、ＵＥは、Ｄ２Ｄ通信がサポートされることと、Ｄ２Ｄリソースの割振りを求める要求が必要とされないこととを、少なくとも１つのフラグから決定する。そのような構成で、ＵＥは、Ｄ２Ｄ通信に対するシステム情報の中で示されるＤ２Ｄリソースのセットを使用することを決定することによって、Ｄ２Ｄリソースを決定する（１５２０）。

[00152] 一構成で、事例１ｂの場合、Ｄ２Ｄリソース（例えば、共通ピア発見リソース）のセットがシステム情報の中で示されると決定され（１５０４）、ＲＲＣ状態がＲＲＣ接続状態であると決定される（１５０６）。そのような構成で、第１のレイヤは、Ｄ２Ｄリソースの割振りを求める要求が必要とされることを示すために、少なくとも１つのフラグのうちの第１のフラグを設定することによって、少なくとも１つのフラグを設定する（１５１８）。一構成で、第１のレイヤは、Ｄ２Ｄ通信がサポートされることを示すために、少なくとも１つのフラグのうちの第２のフラグを設定することによって、少なくとも１つのフラグを設定する（１５１８）。一構成で、ＵＥは、Ｄ２Ｄ通信がサポートされることと、Ｄ２Ｄリソースの割振りを求める要求が必要とされることとを、少なくとも１つのフラグから決定する。そのような構成で、ＵＥは、第１のレイヤにサービング基地局からのＤ２Ｄリソースの割振りを要求するように第２のレイヤにおいて要求することによって、およびＤ２Ｄ２リソースの割振りをサービング基地局から受信することによって、Ｄ２Ｄリソースを決定する（１５２０）。そのような構成で、決定されたＤ２Ｄリソースは、受信された割振り済みＤ２Ｄ２リソースである。一構成で、ＵＥは、Ｄ２Ｄ通信がサポートされることと、Ｄ２Ｄリソースの割振りを求める要求が必要とされることとを、少なくとも１つのフラグから決定する。そのような構成で、ＵＥは、第１のレイヤにサービング基地局からのＤ２Ｄリソースのセットを用いたＤ２Ｄ通信を行うことを要求するように第２のレイヤにおいて要求することによって、およびＤ２ＤリソースのセットがＤ２Ｄ通信（例えば、ピア発見）のために予約されているという確認を基地局から受信することによって、Ｄ２Ｄリソースを決定する（１５２０）。

[00153] 一構成では、事例２ａにおいて、Ｄ２Ｄリソース（例えば、共通ピア発見リソース）のセットがシステム情報の中で示されないと決定され（１５０４）、ＲＲＣ状態がＲＲＣアイドル状態であると決定される（１５０６）。そのような構成で、第１のレイヤは、Ｄ２Ｄリソースの割振りを求める要求が必要とされることを第２のレイヤに対して示すために、少なくとも１つのフラグのうちの第１のフラグを設定することによって、少なくとも１つのフラグを設定する（１５１８）。一構成で、第１のレイヤは、Ｄ２Ｄ通信がサポートされることを示すために、少なくとも１つのフラグのうちの第２のフラグを設定することによって、少なくとも１つのフラグを設定する（１５１８）。一構成で、ＵＥは、Ｄ２Ｄ通信がサポートされることと、Ｄ２Ｄリソースの割振りを求める要求が必要とされることとを、少なくとも１つのフラグから決定する。そのような構成で、ＵＥは、ＲＲＣアイドル状態からＲＲＣ接続状態へ遷移することによって、第１のレイヤにサービング基地局からのＤ２Ｄリソースの割振りを要求するように第２のレイヤにおいて要求することによって、およびＤ２Ｄリソースの割振りをサービング基地局から受信することによって、Ｄ２Ｄリソースを決定する（１５２０）。そのような構成で、決定されたＤ２Ｄリソースは、受信された割振り済みＤ２Ｄリソースである。一構成で、ＵＥは、第１のレイヤにＲＲＣアイドル状態からＲＲＣ接続状態へ遷移させるために、第１のレイヤよりも上位の第３のレイヤを第２のレイヤによって制御する。一構成で、第３のレイヤはＮＡＳレイヤである。

[00154] 一構成では、事例２ｂにおいて、Ｄ２Ｄリソース（例えば、共通ピア発見リソース）のセットがシステム情報の中で示されないと決定され（１５０４）、ＲＲＣ状態がＲＲＣ接続状態であると決定される（１５０６）。そのような構成で、第１のレイヤは、Ｄ２Ｄリソースの割振りを求める要求が必要とされることを第２のレイヤに対して示すために、少なくとも１つのフラグのうちの第１のフラグを設定することによって、少なくとも１つのフラグを設定する（１５１８）。一構成で、第１のレイヤは、Ｄ２Ｄ通信がサポートされることを示すために、少なくとも１つのフラグのうちの第２のフラグを設定することによって、少なくとも１つのフラグを設定する（１５１８）。一構成で、ＵＥは、Ｄ２Ｄ通信がサポートされることと、Ｄ２Ｄリソースの割振りを求める要求が必要とされることとを、少なくとも１つのフラグから決定する。そのような構成で、ＵＥは、第１のレイヤにサービング基地局からのＤ２Ｄリソースの割振りを要求するように第２のレイヤにおいて要求することによって、およびＤ２Ｄリソースの割振りをサービング基地局から受信することによって、Ｄ２Ｄリソースを決定し、ここにおいて、決定されたＤ２Ｄリソースは、受信された割振り済みＤ２Ｄリソースである（１５２０）。一構成で、ＵＥは、Ｄ２Ｄ通信がサポートされることと、Ｄ２Ｄリソースの割振りを求める要求が必要とされることとを、少なくとも１つのフラグから決定する。そのような構成で、ＵＥは、第１のレイヤにサービング基地局からのＤ２Ｄリソースのセットを用いたＤ２Ｄ通信を行うことを要求するように第２のレイヤにおいて要求することによって、およびＤ２ＤリソースのセットがＤ２Ｄ通信（例えば、ピア発見）のために予約されているという確認を基地局から受信することによって、Ｄ２Ｄリソースを決定する（１５２０）。

[00155] 一構成では、事例１ｃにおいて、システム情報がＤ２Ｄ通信に対して受信されていると決定され（１５０２）、Ｄ２Ｄリソース（例えば、共通ピア発見リソース）のセットがシステム情報の中で示される（１５０４）。そのような構成で、ＵＥは、Ｄ２Ｄリソースのセットを使用してＤ２Ｄ通信を行い（１５０８）、Ｄ２Ｄリソースのセットを通じたＤ２Ｄ通信を停止させ（１５１０）、ＲＲＣアイドル状態からＲＲＣ接続状態へ遷移する（１５１２）。加えて、そのような構成で、ＲＲＣアイドル状態からＲＲＣ接続状態へ遷移すると、少なくとも１つのフラグが設定され、Ｄ２Ｄリソースの割振りを求める要求が必要とされることを示すために、第１のレイヤは、少なくとも１つのフラグのうちの第１のフラグを設定することによって、少なくとも１つのフラグを設定する（１５１８）。一構成で、第１のレイヤは、Ｄ２Ｄ通信がサポートされることを示すために、少なくとも１つのフラグのうちの第２のフラグを設定することによって、少なくとも１つのフラグを設定する（１５１８）。一構成で、ＵＥは、Ｄ２Ｄ通信がサポートされることと、Ｄ２Ｄリソースの割振りを求める要求が必要とされることとを、少なくとも１つのフラグから決定する。そのような構成で、ＵＥは、Ｄ２Ｄリソースが利用可能でないことを第２のレイヤにおいて決定することによって、第１のレイヤにサービング基地局からのＤ２Ｄリソースの割振りを要求するように第２のレイヤにおいて要求することによって、およびＤ２Ｄリソースの割振りをサービング基地局から受信することによって、Ｄ２Ｄリソースを決定する（１５２０）。そのような構成で、決定されたＤ２Ｄリソースは、受信された割振り済みＤ２Ｄリソースである。

[00156] 一構成では、事例２ｃにおいて、システム情報がＤ２Ｄ通信に対して受信されていると決定され（１５０２）、Ｄ２Ｄリソースのセットがシステム情報の中で示されない（１５０４）。そのような構成で、ＵＥは、割り振られたＤ２Ｄリソースのセット（例えば、割り振られたピア発見リソースのセット）を使用してＤ２Ｄ通信を行い（１５１４）、割り振られたＤ２Ｄリソースのセットの使用の取消しを受信する（１５１６）。そのような構成で、Ｄ２Ｄリソースの割振りを求める要求が必要とされることを示すために、第１のレイヤは、少なくとも１つのフラグのうちの第１のフラグを設定することによって、少なくとも１つのフラグを設定する（１５１８）。一構成で、第１のレイヤは、Ｄ２Ｄ通信がサポートされることを示すために、少なくとも１つのフラグのうちの第２のフラグを設定することによって、少なくとも１つのフラグを設定する（１５１８）。一構成で、ＵＥは、Ｄ２Ｄ通信がサポートされることと、Ｄ２Ｄリソースの割振りを求める要求が必要とされることとを、少なくとも１つのフラグから決定する。そのような構成で、ＵＥは、Ｄ２Ｄリソースが利用可能でないことを第２のレイヤにおいて決定することによって、第１のレイヤにサービング基地局からのＤ２Ｄリソースの割振りを要求するように第２のレイヤにおいて要求することによって、およびＤ２Ｄリソースの割振りをサービング基地局から受信することによって、Ｄ２Ｄリソースを決定し、ここにおいて、決定されたＤ２Ｄリソースは、受信された割振り済みＤ２Ｄリソースである（１５２０）。

[00157] 一構成では、事例３において、システム情報がＤ２Ｄ通信に対して受信されていないと決定され（１５０２）、第１のレイヤは、Ｄ２Ｄ通信がサポートされないことを示す、少なくとも１つのフラグのうちのフラグを設定することによって、少なくとも１つのフラグを設定し、ここにおいて、Ｄ２Ｄリソースはヌルセットであると決定される（１５１８）。一構成で、ＵＥは、Ｄ２Ｄリソース（例えば、ピア発見リソース）の中で信号を送信する。

[00158] 図１６は、例示的な装置１６０２の中の様々なモジュール／手段／構成要素間のデータフローを示す概念的なデータフロー図１６００である。装置１６０２はＵＥであり得る。装置１６０２は、Ｄ２Ｄ通信に対するシステム情報を受信するように構成されている受信モジュール１６１０を含む。装置１６０２は、システム情報がＤ２Ｄ通信に対して受信されるかどうかを決定するように構成されているシステム情報決定モジュール１６１２をさらに含む。装置１６０２は、システム情報（例えば、基地局１６４０によって割り振られたピア発見リソースに対応する情報）が受信されるとき、システム情報に基づいて少なくとも１つのフラグを設定するように構成されているフラグ設定モジュール１６１４をさらに含む。装置１６０２は、少なくとも１つのフラグに基づいてＤ２Ｄリソースを決定するように構成されているＤ２Ｄリソース決定モジュール（例えば、ピア発見リソース決定モジュール）１６１６をさらに含む。一構成で、装置１６０２の第１のレイヤは、受信モジュール１６１０と、フラグ設定モジュール１６１４と、Ｄ２Ｄリソース決定モジュール１６１６とを備え、第１のレイヤよりも上位の装置１６０２の第２のレイヤは、少なくとも１つのフラグを検査し、Ｄ２Ｄリソースを決定するように第１のレイヤに要求するように構成されている。一構成で、装置１６０２は、装置１６０２のＲＲＣ状態を決定するように構成されているＲＲＣ状態決定および制御モジュール１６１８をさらに含み、システム情報決定モジュール１６１２は、Ｄ２Ｄリソースのセットがシステム情報の中で示されるかどうかを決定するように構成され、フラグ設定モジュール１６１４は、Ｄ２Ｄリソースのセットがシステム情報の中で示されるかどうかに基づいて、および決定されたＲＲＣ状態に基づいて、少なくとも１つのフラグを設定するように構成される。一構成で、Ｄ２Ｄリソースのセットがシステム情報の中で示されると決定されるとき、およびＲＲＣ状態がＲＲＣアイドル状態であると決定されるとき、フラグ設定モジュール１６１４は、Ｄ２Ｄリソースの割振りを求める要求が必要とされないことを第２のレイヤに対して示すために、少なくとも１つのフラグのうちの第１のフラグを設定するように構成される。一構成で、Ｄ２Ｄリソースのセットがシステム情報の中で示されると決定されるとき、およびＲＲＣ状態がＲＲＣ接続状態であると決定されるとき、フラグ設定モジュール１６１４は、Ｄ２Ｄリソースの割振りを求める要求が必要とされることを示すために、少なくとも１つのフラグのうちの第１のフラグを設定するように構成される。一構成で、Ｄ２Ｄリソースのセットがシステム情報の中で示されないと決定されるとき、およびＲＲＣ状態がＲＲＣアイドル状態であると決定されるとき、フラグ設定モジュール１６１４は、Ｄ２Ｄリソースの割振りを求める要求が必要とされることを第２のレイヤに対して示すために、少なくとも１つのフラグのうちの第１のフラグを設定するように構成される。一構成で、Ｄ２Ｄリソースのセットがシステム情報の中で示されないと決定されるとき、およびＲＲＣ状態がＲＲＣ接続状態であると決定されるとき、フラグ設定モジュール１６１４は、Ｄ２Ｄリソースの割振りを求める要求が必要とされることを第２のレイヤに対して示すために、少なくとも１つのフラグのうちの第１のフラグを設定するように構成される。一構成で、装置１６０２は送信モジュール１６２０をさらに含み、システム情報がＤ２Ｄ通信に対して受信されていると決定されるとき、およびＤ２Ｄリソースのセットがシステム情報の中で示されるとき、送信モジュール１６２０は、Ｄ２Ｄリソースのセットを使用して（例えば、別のＵＥ１６５０と）Ｄ２Ｄ通信を行うように構成され、Ｄ２Ｄリソースのセットを通じたＤ２Ｄ通信を停止させるように構成され、ＲＲＣ状態決定および制御モジュール１６１８は、装置１６０２をＲＲＣアイドル状態からＲＲＣ接続状態へ遷移させるように構成され、フラグ設定モジュール１６１４は、装置１６０２がＲＲＣアイドル状態からＲＲＣ接続状態へ遷移すると少なくとも１つのフラグを設定するように構成され、Ｄ２Ｄリソースの割振りを求める要求が必要とされることを示すために、少なくとも１つのフラグのうちの第１のフラグを設定するように構成される。一構成で、システム情報がＤ２Ｄ通信に対して受信されていると決定されるとき、およびＤ２Ｄリソースのセットがシステム情報の中で示されないとき、送信モジュール１６２０は、割り振られたＤ２Ｄリソースのセットを使用してＤ２Ｄピア発見通信などのＤ２Ｄ通信を行うように構成され、受信モジュール１６１０は、割り振られたＤ２Ｄリソースのセットの使用の取消しを受信するように構成され、フラグ設定モジュール１６１４は、Ｄ２Ｄリソースの割振りを求める要求が必要とされることを示すために、少なくとも１つのフラグのうちの第１のフラグを設定するように構成される。

[00159] 図１７は、処理システム１７１３を採用する装置１６０２’のためのハードウェア実施の一例を示す図１７００である。処理システム１７１３は、バス１７２４によって概略的に表されるバスアーキテクチャを用いて実施され得る。バス１７２４は、処理システム１７１３の特定の適用例および全体的な設計制約に応じて、任意の数の相互接続バスとブリッジとを含み得る。バス１７２４は、プロセッサ１７０４によって表される１つまたは複数のプロセッサおよび／またはハードウェアモジュールと、モジュール１６１０、１６１２、１６１４と、コンピュータ可読媒体／メモリ１７０６とを含む、様々な回路を互いにリンクする。バス１７２４はまた、タイミングソース、周辺装置、電圧調整器、および電力管理回路などの、様々な他の回路をリンクし得るが、これらの回路は当技術分野においてよく知られており、従って、これ以上説明しない。

[00160] 処理システム１７１３は、トランシーバ１７１０に結合され得る。トランシーバ１７１０は、１つまたは複数のアンテナ１７２０に結合される。トランシーバ１７１０は、送信媒体を介して様々な他の装置と通信するための手段を提供する。トランシーバ１７１０は、１つまたは複数のアンテナ１７２０から信号を受信し、受信された信号から情報を抽出し、抽出された情報を処理システム１７１３に提供する。加えて、トランシーバ１７１０は、処理システム１７１３から情報を受信し、受信された情報に基づいて、１つまたは複数のアンテナ１７２０に適用されるべき信号を生成する。処理システム１７１３は、コンピュータ可読媒体／メモリ１７０６に結合されたプロセッサ１７０４を含む。プロセッサ１７０４は、コンピュータ可読媒体／メモリ１７０６に記憶されたソフトウェアの実行を含む一般的な処理を担当する。ソフトウェアは、プロセッサ１７０４によって実行されたとき、処理システム１７１３に、特定の装置のための上記で説明した様々な機能を行わせる。コンピュータ可読媒体／メモリ１７０６はまた、ソフトウェアを実行するときにプロセッサ１７０４によって操作されるデータを記憶するために使用され得る。処理システムは、モジュール１６１０、１６１２、１６１４のうちの少なくとも１つをさらに含む。モジュールは、プロセッサ１７０４において稼働するソフトウェアモジュール、コンピュータ可読媒体／メモリ１７０６の中に常駐する／記憶されるソフトウェアモジュール、プロセッサ１７０４に結合された１つまたは複数のハードウェアモジュール、あるいはそれらの何らかの組合せであり得る。処理システム１７１３は、ｅＮＢ６１０の構成要素であり得、メモリ６７６、ならびに／またはＴＸプロセッサ６１６、ＲＸプロセッサ６７０、およびコントローラ／プロセッサ６７５のうちの少なくとも１つを含み得る。

[00161] 一構成では、ワイヤレス通信のための装置１６０２／１６０２’が、ＵＥであり得る。ＵＥは、システム情報がデバイス間（Ｄ２Ｄ）通信に対して受信されるかどうかを決定するための手段と、システム情報が受信されるとき、システム情報に基づいて少なくとも１つのフラグを設定するための手段と、少なくとも１つのフラグに基づいてＤ２Ｄリソースを決定するための手段とを含む。

[00162] ＵＥは、Ｄ２Ｄリソースのセットがシステム情報の中で示されるかどうかを決定するための手段と、ＵＥの無線リソース制御（ＲＲＣ）状態を決定するための手段とをさらに含み得る。少なくとも１つのフラグは、Ｄ２Ｄリソースのセットがシステム情報の中で示されるかどうかに基づいて、および決定されたＲＲＣ状態に基づいて設定され得る。少なくとも１つのフラグを設定するための手段は、Ｄ２Ｄリソースのセットがシステム情報の中で示されると決定されるかどうか、およびＲＲＣ状態の決定に応じて、Ｄ２Ｄリソースの割振りを求める要求が必要とされることまたは必要とされないことのいずれかを第２のレイヤに対して示すために、少なくとも１つのフラグのうちの第１のフラグを設定するように構成され得る。

[00163] ＵＥは、Ｄ２Ｄリソースのセットを使用してＤ２Ｄ通信を行うための手段と、Ｄ２Ｄリソースのセットを通じたＤ２Ｄ通信を停止させるための手段と、ＲＲＣアイドル状態からＲＲＣ接続状態へ遷移するための手段とをさらに含み得る。システム情報がＤ２Ｄ通信に対して受信されていると決定されるとき、およびＤ２Ｄリソースのセットがシステム情報の中で示されるとき、ＲＲＣアイドル状態からＲＲＣ接続状態へ遷移すると、少なくとも１つのフラグが設定され、少なくとも１つのフラグを設定するための手段は、Ｄ２Ｄリソースの割振りを求める要求が必要とされることを示すために、少なくとも１つのフラグのうちの第１のフラグを設定するように構成される。

[00164] ＵＥは、割り振られたＤ２Ｄリソースのセットを使用してＤ２Ｄ通信を行うための手段と、割り振られたＤ２Ｄリソースのセットの使用の取消しを受信するための手段とをさらに含み得る。システム情報がＤ２Ｄ通信に対して受信されていると決定されるとき、およびＤ２Ｄリソースのセットがシステム情報の中で示されないとき、少なくとも１つのフラグを設定するための手段は、Ｄ２Ｄリソースの割振りを求める要求が必要とされることを示すために、少なくとも１つのフラグのうちの第１のフラグを設定するように構成される。

[00165] 上述の手段は、上述の手段によって記載される機能を行うように構成された、装置１６０２の上述のモジュールおよび／または装置１６０２’の処理システム１７１３のうちの、１つまたは複数であり得る。上記で説明したように、処理システム１７１３は、ＴＸプロセッサ６６８と、ＲＸプロセッサ６５６と、コントローラ／プロセッサ６５９とを含み得る。従って、一構成では、上述の手段が、上述の手段によって記載される機能を行うように構成された、ＴＸプロセッサ６６８、ＲＸプロセッサ６５６、およびコントローラ／プロセッサ６５９であり得る。

[00166] 開示したプロセス／フローチャートにおけるステップの特定の順序または階層は、例示的な手法の一例であることを理解されたい。設計の選好に基づいて、プロセス／フローチャートにおけるステップの特定の順序または階層が再構成され得ることを理解されたい。さらに、いくつかのステップは組み合わされ得、または省略され得る。添付の方法クレームは、様々なステップの要素を見本の順序において提示しており、提示された特定の順序または階層に限定されることを意味するものではない。

[00167] 以上の説明は、当業者が本明細書で説明する様々な態様を実践できるようにするために提供される。これらの態様に対する様々な修正は当業者には容易に明らかであり、本明細書で定義された一般原理は他の態様に適用され得る。従って、特許請求の範囲は、本明細書で示される態様に限定されるものではなく、クレーム文言に矛盾しない全範囲を与えられるべきであり、単数形の要素への言及は、そのように明記されていない限り、「唯一無二の」を意味するものではなく、「１つまたは複数の」を意味するものである。「例示的」という単語は、本明細書では「例、事例、または例示の働きをすること」を意味するために使用される。「例示的」として本明細書で説明するいかなる態様も、必ずしも他の態様よりも好適または有利であると解釈されるべきであるとは限らない。別段に明記されていない限り、「いくつかの（ｓｏｍｅ）」という用語は１つまたは複数を表す。「Ａ、Ｂ、またはＣのうちの少なくとも１つの」、「Ａ、Ｂ、およびＣのうちの少なくとも１つ」、「Ａ、Ｂ、Ｃ、またはそれらの任意の組合せ」などの組合せは、Ａ、Ｂ、および／またはＣの任意の組合せを含み、複数のＡ、複数のＢ、または複数のＣを含み得る。具体的には、「Ａ、Ｂ、またはＣのうちの少なくとも１つ」、「Ａ、Ｂ、およびＣのうちの少なくとも１つ」、「Ａ、Ｂ、Ｃ、またはそれらの任意の組合せ」などの組合せは、Ａのみ、Ｂのみ、Ｃのみ、ＡおよびＢ、ＡおよびＣ、ＢおよびＣ、ＡおよびＢおよびＣであり得、任意のそのような組合せは、Ａ、Ｂ、またはＣのうちの１つまたは複数のメンバを含み得る。本開示全体にわたって説明される様々な態様の要素に対する全ての構造的および機能的均等物は、当業者には周知であり、または後に周知となり、参照により本明細書に明確に組み込まれ、特許請求の範囲によって包含されることを意図する。さらに、本明細書で開示するいかなることも、そのような開示が特許請求の範囲に明示的に記載されているかどうかにかかわらず、公に供するものではない。いかなるクレーム要素も、その要素が「ための手段」という句を使用して明確に記載されていない限り、ミーンズプラスファンクションとして解釈されるべきではない。

[00167] 以上の説明は、当業者が本明細書で説明する様々な態様を実践できるようにするために提供される。これらの態様に対する様々な修正は当業者には容易に明らかであり、本明細書で定義された一般原理は他の態様に適用され得る。従って、特許請求の範囲は、本明細書で示される態様に限定されるものではなく、クレーム文言に矛盾しない全範囲を与えられるべきであり、単数形の要素への言及は、そのように明記されていない限り、「唯一無二の」を意味するものではなく、「１つまたは複数の」を意味するものである。「例示的」という単語は、本明細書では「例、事例、または例示の働きをすること」を意味するために使用される。「例示的」として本明細書で説明するいかなる態様も、必ずしも他の態様よりも好適または有利であると解釈されるべきであるとは限らない。別段に明記されていない限り、「いくつかの（ｓｏｍｅ）」という用語は１つまたは複数を表す。「Ａ、Ｂ、またはＣのうちの少なくとも１つの」、「Ａ、Ｂ、およびＣのうちの少なくとも１つ」、「Ａ、Ｂ、Ｃ、またはそれらの任意の組合せ」などの組合せは、Ａ、Ｂ、および／またはＣの任意の組合せを含み、複数のＡ、複数のＢ、または複数のＣを含み得る。具体的には、「Ａ、Ｂ、またはＣのうちの少なくとも１つ」、「Ａ、Ｂ、およびＣのうちの少なくとも１つ」、「Ａ、Ｂ、Ｃ、またはそれらの任意の組合せ」などの組合せは、Ａのみ、Ｂのみ、Ｃのみ、ＡおよびＢ、ＡおよびＣ、ＢおよびＣ、ＡおよびＢおよびＣであり得、任意のそのような組合せは、Ａ、Ｂ、またはＣのうちの１つまたは複数のメンバを含み得る。本開示全体にわたって説明される様々な態様の要素に対する全ての構造的および機能的均等物は、当業者には周知であり、または後に周知となり、参照により本明細書に明確に組み込まれ、特許請求の範囲によって包含されることを意図する。さらに、本明細書で開示するいかなることも、そのような開示が特許請求の範囲に明示的に記載されているかどうかにかかわらず、公に供するものではない。いかなるクレーム要素も、その要素が「ための手段」という句を使用して明確に記載されていない限り、ミーンズプラスファンクションとして解釈されるべきではない。
以下に本願発明の当初の特許請求の範囲に記載された発明を付記する。
［Ｃ１］
ユーザ機器（ＵＥ）のワイヤレス通信の方法であって、
システム情報がデバイス間（Ｄ２Ｄ）通信に対して受信されるかどうかを決定することと、
前記システム情報が受信されるとき、前記システム情報に基づいて少なくとも１つのフラグを設定することと、
前記少なくとも１つのフラグに基づいてＤ２Ｄリソースを決定することと
を備える方法。
［Ｃ２］
前記ＵＥの第１のレイヤが、前記システム情報を受信し、前記少なくとも１つのフラグを設定し、前記第１のレイヤよりも上位の第２のレイヤが、前記少なくとも１つのフラグを検査し、前記Ｄ２Ｄリソースを決定するように前記第１のレイヤに要求する、Ｃ１に記載の方法。
［Ｃ３］
前記システム情報はＤ２Ｄ通信に対して受信されていると決定され、前記方法は、
共通Ｄ２Ｄリソースのセットが前記システム情報の中で示されるかどうかを決定することと、
前記ＵＥの無線リソース制御（ＲＲＣ）状態を決定することとをさらに備え、
ここにおいて、前記少なくとも１つのフラグは、前記共通Ｄ２Ｄリソースの前記セットが前記システム情報の中で示されるかどうかに基づいて、および前記決定されたＲＲＣ状態に基づいて設定される、
Ｃ２に記載の方法。
［Ｃ４］
共通Ｄ２Ｄリソースの前記セットは前記システム情報の中で示されると決定され、前記ＲＲＣ状態はＲＲＣアイドル状態であると決定され、
ここにおいて、前記少なくとも１つのフラグを前記設定することは、前記Ｄ２Ｄリソースの割振りを求める要求が必要とされないことを前記第２のレイヤに対して示すために、前記少なくとも１つのフラグのうちの第１のフラグを設定することを備える、
Ｃ３に記載の方法。
［Ｃ５］
共通Ｄ２Ｄリソースの前記セットは前記システム情報の中で示されると決定され、前記ＲＲＣ状態はＲＲＣ接続状態であると決定され、
ここにおいて、前記少なくとも１つのフラグを前記設定することは、前記Ｄ２Ｄリソースの割振りを求める要求が必要とされることを示すために、前記少なくとも１つのフラグのうちの第１のフラグを設定することを備える、
Ｃ３に記載の方法。
［Ｃ６］
共通Ｄ２Ｄリソースの前記セットは前記システム情報の中で示されないと決定され、前記ＲＲＣ状態はＲＲＣアイドル状態であると決定され、
ここにおいて、前記少なくとも１つのフラグを前記設定することは、前記Ｄ２Ｄリソースの割振りを求める要求が必要とされることを前記第２のレイヤに対して示すために、前記少なくとも１つのフラグのうちの第１のフラグを設定することを備える、
Ｃ３に記載の方法。
［Ｃ７］
共通Ｄ２Ｄリソースの前記セットは前記システム情報の中で示されないと決定され、前記ＲＲＣ状態はＲＲＣ接続状態であると決定され、
ここにおいて、前記少なくとも１つのフラグを前記設定することは、前記Ｄ２Ｄリソースの割振りを求める要求が必要とされることを前記第２のレイヤに対して示すために、前記少なくとも１つのフラグのうちの第１のフラグを設定することを備える、
Ｃ３に記載の方法。
［Ｃ８］
前記システム情報はＤ２Ｄ通信に対して受信されていると決定され、ここにおいて、共通Ｄ２Ｄリソースのセットが前記システム情報の中で示され、前記方法は、
共通Ｄ２Ｄリソースの前記セットを使用してＤ２Ｄ通信を行うことと、
共通Ｄ２Ｄリソースの前記セットを通じた前記Ｄ２Ｄ通信を停止させることと、
ＲＲＣアイドル状態からＲＲＣ接続状態へ遷移することとをさらに備え、
ここにおいて、前記ＲＲＣアイドル状態から前記ＲＲＣ接続状態へ遷移すると、前記少なくとも１つのフラグが設定され、
ここにおいて、前記少なくとも１つのフラグを前記設定することは、前記Ｄ２Ｄリソースの前記割振りを求める要求が必要とされることを示すために、前記少なくとも１つのフラグのうちの第１のフラグを設定することを備える、
Ｃ２に記載の方法。
［Ｃ９］
前記システム情報はＤ２Ｄ通信に対して受信されていると決定され、ここにおいて、共通Ｄ２Ｄリソースのセットが前記システム情報の中で示されず、前記方法は、
割り振られたＤ２Ｄリソースのセットを使用してＤ２Ｄ通信を行うことと、
前記割り振られたＤ２Ｄリソースのセットの前記使用の取消しを受信することとをさらに備え、
ここにおいて、前記少なくとも１つのフラグを前記設定することは、前記Ｄ２Ｄリソースの前記割振りを求める要求が必要とされることを示すために、前記少なくとも１つのフラグのうちの第１のフラグを設定することを備える、
Ｃ２に記載の方法。
［Ｃ１０］
前記システム情報はＤ２Ｄ通信に対して受信されていないと決定され、前記少なくとも１つのフラグを設定することは、Ｄ２Ｄ通信がサポートされないことを示す、前記少なくとも１つのフラグのうちのフラグを設定することを備え、ここにおいて、前記Ｄ２Ｄリソースは、ヌルセットであると決定される、Ｃ１に記載の方法。
［Ｃ１１］
ワイヤレス通信のための装置であって、前記装置はＵＥであり、
システム情報がデバイス間（Ｄ２Ｄ）通信に対して受信されるかどうかを決定するための手段と、
前記システム情報が受信されるとき、前記システム情報に基づいて少なくとも１つのフラグを設定するための手段と、
前記少なくとも１つのフラグに基づいてＤ２Ｄリソースを決定するための手段と
を備える装置。
［Ｃ１２］
前記ＵＥの第１のレイヤが、前記システム情報を受信し、前記少なくとも１つのフラグを設定し、前記第１のレイヤよりも上位の第２のレイヤが、前記少なくとも１つのフラグを検査し、前記Ｄ２Ｄリソースを決定するように前記第１のレイヤに要求する、Ｃ１１に記載の装置。
［Ｃ１３］
前記システム情報はＤ２Ｄ通信に対して受信されていると決定され、前記装置は、
共通Ｄ２Ｄリソースのセットが前記システム情報の中で示されるかどうかを決定するための手段と、
前記ＵＥの無線リソース制御（ＲＲＣ）状態を決定するための手段とをさらに備え、
ここにおいて、前記少なくとも１つのフラグは、前記共通Ｄ２Ｄリソースの前記セットが前記システム情報の中で示されるかどうかに基づいて、および前記決定されたＲＲＣ状態に基づいて設定される、
Ｃ１２に記載の装置。
［Ｃ１４］
共通Ｄ２Ｄリソースの前記セットは前記システム情報の中で示されると決定され、前記ＲＲＣ状態はＲＲＣアイドル状態であると決定され、
ここにおいて、前記少なくとも１つのフラグを設定するための前記手段は、前記Ｄ２Ｄリソースの割振りを求める要求が必要とされないことを前記第２のレイヤに対して示すために、前記少なくとも１つのフラグのうちの第１のフラグを設定するように構成される、
Ｃ１３に記載の装置。
［Ｃ１５］
共通Ｄ２Ｄリソースの前記セットは前記システム情報の中で示されると決定され、前記ＲＲＣ状態はＲＲＣ接続状態であると決定され、
ここにおいて、前記少なくとも１つのフラグを設定するための前記手段は、前記Ｄ２Ｄリソースの割振りを求める要求が必要とされることを示すために、前記少なくとも１つのフラグのうちの第１のフラグを設定するように構成される、
Ｃ１３に記載の装置。
［Ｃ１６］
共通Ｄ２Ｄリソースの前記セットは前記システム情報の中で示されないと決定され、前記ＲＲＣ状態はＲＲＣアイドル状態であると決定され、
ここにおいて、前記少なくとも１つのフラグを設定するための前記手段は、前記Ｄ２Ｄリソースの割振りを求める要求が必要とされることを前記第２のレイヤに対して示すために、前記少なくとも１つのフラグのうちの第１のフラグを設定するように構成される、
Ｃ１３に記載の装置。
［Ｃ１７］
共通Ｄ２Ｄリソースの前記セットは前記システム情報の中で示されないと決定され、前記ＲＲＣ状態はＲＲＣ接続状態であると決定され、
ここにおいて、前記少なくとも１つのフラグを設定するための前記手段は、前記Ｄ２Ｄリソースの割振りを求める要求が必要とされることを前記第２のレイヤに対して示すために、前記少なくとも１つのフラグのうちの第１のフラグを設定するように構成される、
Ｃ１３に記載の装置。
［Ｃ１８］
前記システム情報はＤ２Ｄ通信に対して受信されていると決定され、ここにおいて、共通Ｄ２Ｄリソースのセットが前記システム情報の中で示され、前記装置が、
共通Ｄ２Ｄリソースの前記セットを使用してＤ２Ｄ通信を行うための手段と、
共通Ｄ２Ｄリソースの前記セットを通じた前記Ｄ２Ｄ通信を停止させるための手段と、
ＲＲＣアイドル状態からＲＲＣ接続状態へ遷移するための手段とをさらに備え、
ここにおいて、前記ＲＲＣアイドル状態から前記ＲＲＣ接続状態へ遷移すると、前記少なくとも１つのフラグが設定され、
ここにおいて、前記少なくとも１つのフラグを設定するための前記手段は、前記Ｄ２Ｄリソースの前記割振りを求める要求が必要とされることを示すために、前記少なくとも１つのフラグのうちの第１のフラグを設定するように構成される、
Ｃ１２に記載の装置。
［Ｃ１９］
前記システム情報はＤ２Ｄ通信に対して受信されていると決定され、ここにおいて、共通Ｄ２Ｄリソースのセットが前記システム情報の中で示されず、前記装置は、
割り振られたＤ２Ｄリソースのセットを使用してＤ２Ｄ通信を行うための手段と、
前記割り振られたＤ２Ｄリソースのセットの前記使用の取消しを受信するための手段とをさらに備え、
ここにおいて、前記少なくとも１つのフラグを設定するための前記手段は、前記Ｄ２Ｄリソースの前記割振りを求める要求が必要とされることを示すために、前記少なくとも１つのフラグのうちの第１のフラグを設定するように構成される、
Ｃ１２に記載の装置。
［Ｃ２０］
前記システム情報はＤ２Ｄ通信に対して受信されていないと決定され、前記少なくとも１つのフラグを設定するための前記手段は、Ｄ２Ｄ通信がサポートされないことを示す、前記少なくとも１つのフラグのうちのフラグを設定するように構成され、ここにおいて、前記Ｄ２Ｄリソースは、ヌルセットであると決定される、Ｃ１１に記載の装置。
［Ｃ２１］
ワイヤレス通信のための装置であって、
メモリと、
前記メモリに結合された少なくとも１つのプロセッサとを備え、前記少なくとも１つのプロセッサは、
システム情報がデバイス間（Ｄ２Ｄ）通信に対して受信されるかどうかを決定し、
前記システム情報が受信されるとき、前記システム情報に基づいて少なくとも１つのフラグを設定し、
前記少なくとも１つのフラグに基づいてＤ２Ｄリソースを決定するように構成され、ここにおいて、前記ＵＥの第１のレイヤが、前記システム情報を受信し、前記少なくとも１つのフラグを設定し、前記第１のレイヤよりも上位の第２のレイヤが、前記少なくとも１つのフラグを検査し、前記Ｄ２Ｄリソースを決定するように前記第１のレイヤに要求する、
装置。
［Ｃ２２］
前記システム情報はＤ２Ｄ通信に対して受信されていると決定され、ここにおいて、前記少なくとも１つのプロセッサは、
共通Ｄ２Ｄリソースのセットが前記システム情報の中で示されるかどうかを決定し、
前記ＵＥの無線リソース制御（ＲＲＣ）状態を決定するようにさらに構成され、
ここにおいて、前記少なくとも１つのフラグは、前記共通Ｄ２Ｄリソースの前記セットが前記システム情報の中で示されるかどうかに基づいて、および前記決定されたＲＲＣ状態に基づいて設定される、
Ｃ２１に記載の装置。
［Ｃ２３］
共通Ｄ２Ｄリソースの前記セットは前記システム情報の中で示されると決定され、前記ＲＲＣ状態はＲＲＣアイドル状態であると決定され、
ここにおいて、前記少なくとも１つのプロセッサは、前記Ｄ２Ｄリソースの割振りを求める要求が必要とされないことを前記第２のレイヤに対して示すために、前記少なくとも１つのフラグのうちの第１のフラグを設定することによって、前記少なくとも１つのフラグを設定するように構成される、
Ｃ２２に記載の装置。
［Ｃ２４］
共通Ｄ２Ｄリソースの前記セットは前記システム情報の中で示されると決定され、前記ＲＲＣ状態はＲＲＣ接続状態であると決定され、
ここにおいて、前記少なくとも１つのプロセッサは、前記Ｄ２Ｄリソースの割振りを求める要求が必要とされることを示すために、前記少なくとも１つのフラグのうちの第１のフラグを設定するようにさらに構成される、
Ｃ２２に記載の装置。
［Ｃ２５］
共通Ｄ２Ｄリソースの前記セットは前記システム情報の中で示されないと決定され、前記ＲＲＣ状態はＲＲＣアイドル状態であると決定され、
ここにおいて、前記少なくとも１つのプロセッサは、前記Ｄ２Ｄリソースの割振りを求める要求が必要とされることを前記第２のレイヤに対して示すために、前記少なくとも１つのフラグのうちの第１のフラグを設定するようにさらに構成される、
Ｃ２２に記載の装置。
［Ｃ２６］
共通Ｄ２Ｄリソースの前記セットは前記システム情報の中で示されないと決定され、前記ＲＲＣ状態はＲＲＣ接続状態であると決定され、
ここにおいて、前記少なくとも１つのプロセッサは、前記Ｄ２Ｄリソースの割振りを求める要求が必要とされることを前記第２のレイヤに対して示すために、前記少なくとも１つのフラグのうちの第１のフラグを設定するように構成される、
Ｃ２２に記載の装置。
［Ｃ２７］
前記システム情報はＤ２Ｄ通信に対して受信されていると決定され、ここにおいて、共通Ｄ２Ｄリソースのセットが前記システム情報の中で示され、ここにおいて、前記少なくとも１つのプロセッサは、
共通Ｄ２Ｄリソースの前記セットを使用してＤ２Ｄ通信を行い、
共通Ｄ２Ｄリソースの前記セットを通じた前記Ｄ２Ｄ通信を停止させ、
ＲＲＣアイドル状態からＲＲＣ接続状態へ遷移するようにさらに構成され、
ここにおいて、前記ＲＲＣアイドル状態から前記ＲＲＣ接続状態へ遷移すると、前記少なくとも１つのフラグが設定され、
ここにおいて、前記少なくとも１つのプロセッサは、前記Ｄ２Ｄリソースの前記割振りを求める要求が必要とされることを示すために、前記少なくとも１つのフラグのうちの第１のフラグを設定するように構成される、
Ｃ２１に記載の装置。
［Ｃ２８］
前記システム情報はＤ２Ｄ通信に対して受信されていると決定され、ここにおいて、共通Ｄ２Ｄリソースのセットが前記システム情報の中で示されず、ここにおいて、前記少なくとも１つのプロセッサは、
割り振られたＤ２Ｄリソースのセットを使用してＤ２Ｄ通信を行い、
前記割り振られたＤ２Ｄリソースのセットの前記使用の取消しを受信するようにさらに構成され、
ここにおいて、前記少なくとも１つのプロセッサは、前記Ｄ２Ｄリソースの前記割振りを求める要求が必要とされることを示すために、前記少なくとも１つのフラグのうちの第１のフラグを設定するように構成される、
Ｃ２１に記載の装置。
［Ｃ２９］
前記システム情報はＤ２Ｄ通信に対して受信されていないと決定され、ここにおいて、前記少なくとも１つのプロセッサは、Ｄ２Ｄ通信がサポートされないことを示す、前記少なくとも１つのフラグのうちのフラグを設定するように構成され、ここにおいて、前記Ｄ２Ｄリソースは、ヌルセットであると決定される、Ｃ２１に記載の装置。
［Ｃ３０］
少なくとも１つのプロセッサ上で実行されたとき、
システム情報がデバイス間（Ｄ２Ｄ）通信に対して受信されるかどうかを決定することと、
前記システム情報が受信されるとき、前記システム情報に基づいて少なくとも１つのフラグを設定することと、
前記少なくとも１つのフラグに基づいてＤ２Ｄリソースを決定することと
に前記少なくとも１つのプロセッサにさせるコードを備えるコンピュータ可読媒体。

Claims (30)

1. ユーザ機器（ＵＥ）のワイヤレス通信の方法であって、
   システム情報がデバイス間（Ｄ２Ｄ）通信に対して受信されるかどうかを決定することと、
   前記システム情報が受信されるとき、前記システム情報に基づいて少なくとも１つのフラグを設定することと、
   前記少なくとも１つのフラグに基づいてＤ２Ｄリソースを決定することと
   を備える方法。
2. 前記ＵＥの第１のレイヤが、前記システム情報を受信し、前記少なくとも１つのフラグを設定し、前記第１のレイヤよりも上位の第２のレイヤが、前記少なくとも１つのフラグを検査し、前記Ｄ２Ｄリソースを決定するように前記第１のレイヤに要求する、請求項１に記載の方法。
3. 前記システム情報はＤ２Ｄ通信に対して受信されていると決定され、前記方法は、
   共通Ｄ２Ｄリソースのセットが前記システム情報の中で示されるかどうかを決定することと、
   前記ＵＥの無線リソース制御（ＲＲＣ）状態を決定することとをさらに備え、
   ここにおいて、前記少なくとも１つのフラグは、前記共通Ｄ２Ｄリソースの前記セットが前記システム情報の中で示されるかどうかに基づいて、および前記決定されたＲＲＣ状態に基づいて設定される、
   請求項２に記載の方法。
4. 共通Ｄ２Ｄリソースの前記セットは前記システム情報の中で示されると決定され、前記ＲＲＣ状態はＲＲＣアイドル状態であると決定され、
   ここにおいて、前記少なくとも１つのフラグを前記設定することは、前記Ｄ２Ｄリソースの割振りを求める要求が必要とされないことを前記第２のレイヤに対して示すために、前記少なくとも１つのフラグのうちの第１のフラグを設定することを備える、
   請求項３に記載の方法。
5. 共通Ｄ２Ｄリソースの前記セットは前記システム情報の中で示されると決定され、前記ＲＲＣ状態はＲＲＣ接続状態であると決定され、
   ここにおいて、前記少なくとも１つのフラグを前記設定することは、前記Ｄ２Ｄリソースの割振りを求める要求が必要とされることを示すために、前記少なくとも１つのフラグのうちの第１のフラグを設定することを備える、
   請求項３に記載の方法。
6. 共通Ｄ２Ｄリソースの前記セットは前記システム情報の中で示されないと決定され、前記ＲＲＣ状態はＲＲＣアイドル状態であると決定され、
   ここにおいて、前記少なくとも１つのフラグを前記設定することは、前記Ｄ２Ｄリソースの割振りを求める要求が必要とされることを前記第２のレイヤに対して示すために、前記少なくとも１つのフラグのうちの第１のフラグを設定することを備える、
   請求項３に記載の方法。
7. 共通Ｄ２Ｄリソースの前記セットは前記システム情報の中で示されないと決定され、前記ＲＲＣ状態はＲＲＣ接続状態であると決定され、
   ここにおいて、前記少なくとも１つのフラグを前記設定することは、前記Ｄ２Ｄリソースの割振りを求める要求が必要とされることを前記第２のレイヤに対して示すために、前記少なくとも１つのフラグのうちの第１のフラグを設定することを備える、
   請求項３に記載の方法。
8. 前記システム情報はＤ２Ｄ通信に対して受信されていると決定され、ここにおいて、共通Ｄ２Ｄリソースのセットが前記システム情報の中で示され、前記方法は、
   共通Ｄ２Ｄリソースの前記セットを使用してＤ２Ｄ通信を行うことと、
   共通Ｄ２Ｄリソースの前記セットを通じた前記Ｄ２Ｄ通信を停止させることと、
   ＲＲＣアイドル状態からＲＲＣ接続状態へ遷移することとをさらに備え、
   ここにおいて、前記ＲＲＣアイドル状態から前記ＲＲＣ接続状態へ遷移すると、前記少なくとも１つのフラグが設定され、
   ここにおいて、前記少なくとも１つのフラグを前記設定することは、前記Ｄ２Ｄリソースの前記割振りを求める要求が必要とされることを示すために、前記少なくとも１つのフラグのうちの第１のフラグを設定することを備える、
   請求項２に記載の方法。
9. 前記システム情報はＤ２Ｄ通信に対して受信されていると決定され、ここにおいて、共通Ｄ２Ｄリソースのセットが前記システム情報の中で示されず、前記方法は、
   割り振られたＤ２Ｄリソースのセットを使用してＤ２Ｄ通信を行うことと、
   前記割り振られたＤ２Ｄリソースのセットの前記使用の取消しを受信することとをさらに備え、
   ここにおいて、前記少なくとも１つのフラグを前記設定することは、前記Ｄ２Ｄリソースの前記割振りを求める要求が必要とされることを示すために、前記少なくとも１つのフラグのうちの第１のフラグを設定することを備える、
   請求項２に記載の方法。
10. 前記システム情報はＤ２Ｄ通信に対して受信されていないと決定され、前記少なくとも１つのフラグを設定することは、Ｄ２Ｄ通信がサポートされないことを示す、前記少なくとも１つのフラグのうちのフラグを設定することを備え、ここにおいて、前記Ｄ２Ｄリソースは、ヌルセットであると決定される、請求項１に記載の方法。
11. ワイヤレス通信のための装置であって、前記装置はＵＥであり、
    システム情報がデバイス間（Ｄ２Ｄ）通信に対して受信されるかどうかを決定するための手段と、
    前記システム情報が受信されるとき、前記システム情報に基づいて少なくとも１つのフラグを設定するための手段と、
    前記少なくとも１つのフラグに基づいてＤ２Ｄリソースを決定するための手段と
    を備える装置。
12. 前記ＵＥの第１のレイヤが、前記システム情報を受信し、前記少なくとも１つのフラグを設定し、前記第１のレイヤよりも上位の第２のレイヤが、前記少なくとも１つのフラグを検査し、前記Ｄ２Ｄリソースを決定するように前記第１のレイヤに要求する、請求項１１に記載の装置。
13. 前記システム情報はＤ２Ｄ通信に対して受信されていると決定され、前記装置は、
    共通Ｄ２Ｄリソースのセットが前記システム情報の中で示されるかどうかを決定するための手段と、
    前記ＵＥの無線リソース制御（ＲＲＣ）状態を決定するための手段とをさらに備え、
    ここにおいて、前記少なくとも１つのフラグは、前記共通Ｄ２Ｄリソースの前記セットが前記システム情報の中で示されるかどうかに基づいて、および前記決定されたＲＲＣ状態に基づいて設定される、
    請求項１２に記載の装置。
14. 共通Ｄ２Ｄリソースの前記セットは前記システム情報の中で示されると決定され、前記ＲＲＣ状態はＲＲＣアイドル状態であると決定され、
    ここにおいて、前記少なくとも１つのフラグを設定するための前記手段は、前記Ｄ２Ｄリソースの割振りを求める要求が必要とされないことを前記第２のレイヤに対して示すために、前記少なくとも１つのフラグのうちの第１のフラグを設定するように構成される、
    請求項１３に記載の装置。
15. 共通Ｄ２Ｄリソースの前記セットは前記システム情報の中で示されると決定され、前記ＲＲＣ状態はＲＲＣ接続状態であると決定され、
    ここにおいて、前記少なくとも１つのフラグを設定するための前記手段は、前記Ｄ２Ｄリソースの割振りを求める要求が必要とされることを示すために、前記少なくとも１つのフラグのうちの第１のフラグを設定するように構成される、
    請求項１３に記載の装置。
16. 共通Ｄ２Ｄリソースの前記セットは前記システム情報の中で示されないと決定され、前記ＲＲＣ状態はＲＲＣアイドル状態であると決定され、
    ここにおいて、前記少なくとも１つのフラグを設定するための前記手段は、前記Ｄ２Ｄリソースの割振りを求める要求が必要とされることを前記第２のレイヤに対して示すために、前記少なくとも１つのフラグのうちの第１のフラグを設定するように構成される、
    請求項１３に記載の装置。
17. 共通Ｄ２Ｄリソースの前記セットは前記システム情報の中で示されないと決定され、前記ＲＲＣ状態はＲＲＣ接続状態であると決定され、
    ここにおいて、前記少なくとも１つのフラグを設定するための前記手段は、前記Ｄ２Ｄリソースの割振りを求める要求が必要とされることを前記第２のレイヤに対して示すために、前記少なくとも１つのフラグのうちの第１のフラグを設定するように構成される、
    請求項１３に記載の装置。
18. 前記システム情報はＤ２Ｄ通信に対して受信されていると決定され、ここにおいて、共通Ｄ２Ｄリソースのセットが前記システム情報の中で示され、前記装置が、
    共通Ｄ２Ｄリソースの前記セットを使用してＤ２Ｄ通信を行うための手段と、
    共通Ｄ２Ｄリソースの前記セットを通じた前記Ｄ２Ｄ通信を停止させるための手段と、
    ＲＲＣアイドル状態からＲＲＣ接続状態へ遷移するための手段とをさらに備え、
    ここにおいて、前記ＲＲＣアイドル状態から前記ＲＲＣ接続状態へ遷移すると、前記少なくとも１つのフラグが設定され、
    ここにおいて、前記少なくとも１つのフラグを設定するための前記手段は、前記Ｄ２Ｄリソースの前記割振りを求める要求が必要とされることを示すために、前記少なくとも１つのフラグのうちの第１のフラグを設定するように構成される、
    請求項１２に記載の装置。
19. 前記システム情報はＤ２Ｄ通信に対して受信されていると決定され、ここにおいて、共通Ｄ２Ｄリソースのセットが前記システム情報の中で示されず、前記装置は、
    割り振られたＤ２Ｄリソースのセットを使用してＤ２Ｄ通信を行うための手段と、
    前記割り振られたＤ２Ｄリソースのセットの前記使用の取消しを受信するための手段とをさらに備え、
    ここにおいて、前記少なくとも１つのフラグを設定するための前記手段は、前記Ｄ２Ｄリソースの前記割振りを求める要求が必要とされることを示すために、前記少なくとも１つのフラグのうちの第１のフラグを設定するように構成される、
    請求項１２に記載の装置。
20. 前記システム情報はＤ２Ｄ通信に対して受信されていないと決定され、前記少なくとも１つのフラグを設定するための前記手段は、Ｄ２Ｄ通信がサポートされないことを示す、前記少なくとも１つのフラグのうちのフラグを設定するように構成され、ここにおいて、前記Ｄ２Ｄリソースは、ヌルセットであると決定される、請求項１１に記載の装置。
21. ワイヤレス通信のための装置であって、
    メモリと、
    前記メモリに結合された少なくとも１つのプロセッサとを備え、前記少なくとも１つのプロセッサは、
    システム情報がデバイス間（Ｄ２Ｄ）通信に対して受信されるかどうかを決定し、
    前記システム情報が受信されるとき、前記システム情報に基づいて少なくとも１つのフラグを設定し、
    前記少なくとも１つのフラグに基づいてＤ２Ｄリソースを決定するように構成され、ここにおいて、前記ＵＥの第１のレイヤが、前記システム情報を受信し、前記少なくとも１つのフラグを設定し、前記第１のレイヤよりも上位の第２のレイヤが、前記少なくとも１つのフラグを検査し、前記Ｄ２Ｄリソースを決定するように前記第１のレイヤに要求する、
    装置。
22. 前記システム情報はＤ２Ｄ通信に対して受信されていると決定され、ここにおいて、前記少なくとも１つのプロセッサは、
    共通Ｄ２Ｄリソースのセットが前記システム情報の中で示されるかどうかを決定し、
    前記ＵＥの無線リソース制御（ＲＲＣ）状態を決定するようにさらに構成され、
    ここにおいて、前記少なくとも１つのフラグは、前記共通Ｄ２Ｄリソースの前記セットが前記システム情報の中で示されるかどうかに基づいて、および前記決定されたＲＲＣ状態に基づいて設定される、
    請求項２１に記載の装置。
23. 共通Ｄ２Ｄリソースの前記セットは前記システム情報の中で示されると決定され、前記ＲＲＣ状態はＲＲＣアイドル状態であると決定され、
    ここにおいて、前記少なくとも１つのプロセッサは、前記Ｄ２Ｄリソースの割振りを求める要求が必要とされないことを前記第２のレイヤに対して示すために、前記少なくとも１つのフラグのうちの第１のフラグを設定することによって、前記少なくとも１つのフラグを設定するように構成される、
    請求項２２に記載の装置。
24. 共通Ｄ２Ｄリソースの前記セットは前記システム情報の中で示されると決定され、前記ＲＲＣ状態はＲＲＣ接続状態であると決定され、
    ここにおいて、前記少なくとも１つのプロセッサは、前記Ｄ２Ｄリソースの割振りを求める要求が必要とされることを示すために、前記少なくとも１つのフラグのうちの第１のフラグを設定するようにさらに構成される、
    請求項２２に記載の装置。
25. 共通Ｄ２Ｄリソースの前記セットは前記システム情報の中で示されないと決定され、前記ＲＲＣ状態はＲＲＣアイドル状態であると決定され、
    ここにおいて、前記少なくとも１つのプロセッサは、前記Ｄ２Ｄリソースの割振りを求める要求が必要とされることを前記第２のレイヤに対して示すために、前記少なくとも１つのフラグのうちの第１のフラグを設定するようにさらに構成される、
    請求項２２に記載の装置。
26. 共通Ｄ２Ｄリソースの前記セットは前記システム情報の中で示されないと決定され、前記ＲＲＣ状態はＲＲＣ接続状態であると決定され、
    ここにおいて、前記少なくとも１つのプロセッサは、前記Ｄ２Ｄリソースの割振りを求める要求が必要とされることを前記第２のレイヤに対して示すために、前記少なくとも１つのフラグのうちの第１のフラグを設定するように構成される、
    請求項２２に記載の装置。
27. 前記システム情報はＤ２Ｄ通信に対して受信されていると決定され、ここにおいて、共通Ｄ２Ｄリソースのセットが前記システム情報の中で示され、ここにおいて、前記少なくとも１つのプロセッサは、
    共通Ｄ２Ｄリソースの前記セットを使用してＤ２Ｄ通信を行い、
    共通Ｄ２Ｄリソースの前記セットを通じた前記Ｄ２Ｄ通信を停止させ、
    ＲＲＣアイドル状態からＲＲＣ接続状態へ遷移するようにさらに構成され、
    ここにおいて、前記ＲＲＣアイドル状態から前記ＲＲＣ接続状態へ遷移すると、前記少なくとも１つのフラグが設定され、
    ここにおいて、前記少なくとも１つのプロセッサは、前記Ｄ２Ｄリソースの前記割振りを求める要求が必要とされることを示すために、前記少なくとも１つのフラグのうちの第１のフラグを設定するように構成される、
    請求項２１に記載の装置。
28. 前記システム情報はＤ２Ｄ通信に対して受信されていると決定され、ここにおいて、共通Ｄ２Ｄリソースのセットが前記システム情報の中で示されず、ここにおいて、前記少なくとも１つのプロセッサは、
    割り振られたＤ２Ｄリソースのセットを使用してＤ２Ｄ通信を行い、
    前記割り振られたＤ２Ｄリソースのセットの前記使用の取消しを受信するようにさらに構成され、
    ここにおいて、前記少なくとも１つのプロセッサは、前記Ｄ２Ｄリソースの前記割振りを求める要求が必要とされることを示すために、前記少なくとも１つのフラグのうちの第１のフラグを設定するように構成される、
    請求項２１に記載の装置。
29. 前記システム情報はＤ２Ｄ通信に対して受信されていないと決定され、ここにおいて、前記少なくとも１つのプロセッサは、Ｄ２Ｄ通信がサポートされないことを示す、前記少なくとも１つのフラグのうちのフラグを設定するように構成され、ここにおいて、前記Ｄ２Ｄリソースは、ヌルセットであると決定される、請求項２１に記載の装置。
30. 少なくとも１つのプロセッサ上で実行されたとき、
    システム情報がデバイス間（Ｄ２Ｄ）通信に対して受信されるかどうかを決定することと、
    前記システム情報が受信されるとき、前記システム情報に基づいて少なくとも１つのフラグを設定することと、
    前記少なくとも１つのフラグに基づいてＤ２Ｄリソースを決定することと
    に前記少なくとも１つのプロセッサにさせるコードを備えるコンピュータ可読媒体。

Images