JP2015534307A - デバイスツーデバイス発見を行うための方法および装置 - Google Patents

Abstract

デバイスツーデバイス（Ｄ２Ｄ）発見を行うための方法および装置が説明される。サービス発見プロセスは、発見可能デバイス（例えば、無線送受信ユニット（ＷＴＲＵ））が、所与のサービスについての無線周波数（ＲＦ）近傍検出のための送信を行うために、無線接続を介して無線リソースを求める発見要求を送ることを含むことができる。ＷＴＲＵは、ネットワークからＲＦ近傍検出のための構成を含む発見応答を受信することができ、その構成はサービスに関連付けられ得る。ＲＦ近傍のための構成は、特に発見可能ＷＴＲＵについて、専用シグナリング（例えば、物理ダウンリンク共有チャネル（ＰＤＳＣＨ））によって受信されることができる。ＲＦ近傍のための構成は、特に監視ＷＴＲＵについて、ブロードキャストチャネル（例えば、発見共有チャネル（ＤＩＳＣＨ））上で受信されることができ、また、それぞれがＲＦ近傍検出構成に関連付けられた１もしくは複数のサービスアイデンティティ、または有効性情報および測定構成を含むことができる。

Description

本発明は無線通信に関する。

近傍サービス（proximity services：ＰｒｏＳｅ）は、セルラー技術エコシステムにおいてデバイスツーデバイス（Ｄ２Ｄ）通信をサポートすることができる。ＰｒｏＳｅは、２以上のデバイス（例えば、無線送受信ユニット（ＷＴＲＵ）、ユーザ機器（ＵＥ）、移動局）の間の近傍に依拠することが可能であり、特定の商用およびソーシャルアプリケーション、ネットワークオフロードまたは公共安全直接通信（public safety direct communication）を可能にする。Ｗｉ−ＦｉやＢｌｕｅｔｏｏｔｈ（登録商標）などの他の選択肢もＤ２Ｄ通信をサポートし得るが、それらは、ライセンス不要バンドで動作することがあり、従って、より高い干渉およびより低いサービス品質（ＱｏＳ）にさらされることがある。ＰｒｏＳｅは、これらの問題に対処するためにＤ２Ｄ発見および様々な通信手順を使用することができる。

デバイスツーデバイス（device-to-device：Ｄ２Ｄ）発見を行うための方法および装置が説明される。サービス発見プロセス（service discovery process）は、発見可能デバイス（例えば、無線送受信ユニット（ＷＴＲＵ））が、所与のサービスについての無線周波数（ＲＦ）近傍検出のための送信を行うために、無線接続を介して無線リソースを求める発見要求を送ることを含むことができる。

サービス発見プロセスは、ＷＴＲＵが、ネットワークからＲＦ近傍検出のための構成を含む発見応答を受信することを含むことができ、その構成は、関係するサービスに関連付けられ得る。ＲＦ近傍のための構成は、特に発見可能ＷＴＲＵについて、専用シグナリング（例えば、物理ダウンリンク共有チャネル（ＰＤＳＣＨ））によって受信され得る。ＲＦ近傍のための構成は、特に監視ＷＴＲＵについて、ブロードキャストチャネル（例えば、発見共有チャネル（discovery shared channel：ＤＩＳＣＨ））上で受信され得る。ブロードキャストチャネルから受信される送信は、それぞれがＲＦ近傍検出構成に関連付けられた１もしくは複数のサービスアイデンティティ（即ち、サービスに関連付けられた送信リソース）、または有効性情報および測定構成を含むことができる。ＷＴＲＵによって受信されるブロードキャストチャネル上の送信は、特定の無線ネットワーク一時アイデンティティ（radio network temporary identity：ＲＮＴＩ）またはサブフレームタイミングを使用してＰＤＳＣＨによってスケジューリングされ得る。

サービス発見プロセスは、ＷＴＲＵが、関係するサービスについての受信されたＲＦ近傍検出構成を使用して動作を開始することを含むことができる。発見可能ＷＴＲＵは、それが、構成されたリソースの有効時間中に、構成されたリソース上でＲＦ近傍検出信号の送信を開始し得ることを決定することができる。監視ＷＴＲＵは、関連付けられた測定構成を使用して、それが、構成されたリソースの有効時間中に、構成されたリソース上でＲＦ近傍検出信号の受信を開始し得ることを決定することができる。

サービス発見プロセスは、１）関係する測定オブジェクトについての測定報告の送信を、無線接続を介して開始する、２）（Ｄ２Ｄデータ転送を開始するために、）所与のサービスに対応するＤ２Ｄセッションのための無線リソース構成を求める要求を、無線接続を介して開始する、または３）（相互発見のために）所与のサービスについてのＲＦ近傍検出のための送信を行うための無線リソースを求める要求を、無線接続を介して開始するように、関係するサービスについてのＲＦ近傍信号がＷＴＲＵをトリガーし得ることを、監視ＷＴＲＵが検出することを含むことができる。

サービス発見プロセスは、ＷＴＲＵが、ネットワークから、Ｄ２Ｄチャネルのための構成を受信することを含むことができる。

発見可能ＷＴＲＵは、リソースの有効性が期限切れしたとき、ＷＴＲＵがネットワークに対するアップリンク同期をもはや行わないとき、または他の条件で、ＲＦ近傍検出を終了する、または近傍検出のためのＲＦ信号での送信を終了することができる。

ＷＴＲＵ内のアプリケーションは、サービスアイデンティティを含むワイヤレスモジュールに対する要求によってサービス発見手順をトリガーすることができる。発見クラスとＷＴＲＵの役割（例えば、監視、発見可能）とに応じた優先規則も適用可能である。

添付図面と併せて例として与えられる以下の詳細な説明から、より詳細な理解が得られるであろう。
１または複数の開示された実施形態が実装され得る例示的通信システムを示す図である。 図１Ａに示される通信システム内で使用され得る例示的無線送受信ユニット（ＷＴＲＵ）を示す図である。 図１Ａに示される通信システム内で使用され得る例示的アクセスネットワークおよび例示的コアネットワークを示す図である。 ネットワークパラメータに対する発見可能および監視状態の影響の例を示す図である。 ネットワークパラメータに対する発見可能および監視状態の影響の例を示す図である。 アップリンク（ＵＬ）ハイブリッド自動再送要求（ＨＡＲＱ）に対する発見手順影響の例を示す図である。 帯域内に割り振られた公衆陸上移動体ネットワーク（public land mobile network：ＰＬＭＮ）専用発見チャネルの例を示す図である。 帯域外に割り振られた共通発見チャネルの例を示す図である。 ＵＬを有する帯域内時分割多重（ＴＤＭ）に割り振られた発見チャネルの例を示す図である。 発見信号設計のためのＬＴＥ信号特性を示す図である。 発見信号設計のためのＬＴＥ信号特性を示す図である。 デバイスツーデバイス（Ｄ２Ｄ）ダウンリンク（ＤＬ）またはアップリンク（ＵＬ）同期の例を示す図である。 ネットワークによって定義された時間ウィンドウを有する分散されたＤ２Ｄ同期戦略の例を示す図である。 探索デバイス匿名性保持の例を示す図である。

図１Ａは、１または複数の開示される実施形態が実装され得る例示的通信システム１００を示す。通信システム１００は、音声、データ、映像、メッセージングおよびブロードキャストなどのコンテンツを複数の無線ユーザに提供する多元接続システムとすることができる。通信システム１００は、複数の無線ユーザが、無線帯域幅を含むシステムリソースの共有によってそのようなコンテンツにアクセスすることを可能にすることができる。例えば、通信システム１００は、符号分割多元接続（ＣＤＭＡ）、時分割多元接続（ＴＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）およびシングルキャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）などの１または複数のチャネルアクセス方法を利用することができる。

図１Ａに示されるように、通信システム１００は、無線送受信ユニット（ＷＴＲＵ）１０２ａ、１０２ｂ、１０２ｃ、１０２ｄ、無線アクセスネットワーク（ＲＡＮ）１０４、コアネットワーク１０６、公衆交換電話網（ＰＳＴＮ）１０８、インターネット１１０、および他のネットワーク１１２を含むことができるが、開示される実施形態は任意の数のＷＴＲＵ、基地局、ネットワークおよび／またはネットワーク要素を企図していることは理解されよう。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのそれぞれは、無線環境で動作および／または通信するように構成された任意のタイプのデバイスとすることができる。例えば、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、無線信号を送信および／または受信するように構成されてよく、ユーザ機器（ＵＥ）、移動局、固定または移動加入者ユニット、ページャ、セルラー電話、携帯情報端末（ＰＤＡ）、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、無線センサおよび家庭用電化製品などを含むことができる。

また、通信システム１００は、基地局１１４ａおよび基地局１１４ｂを含むことができる。基地局１１４ａ、１１４ｂのそれぞれは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの少なくとも１つと無線でインターフェースして、コアネットワーク１０６、インターネット１１０、および／または他のネットワーク１１２などの１または複数の通信ネットワークへのアクセスを容易にするように構成された任意のタイプのデバイスとすることができる。例えば、基地局１１４ａ、１１４ｂは、トランシーバ基地局（ＢＴＳ）、ノードＢ、ｅＮＢ（evolved Node-B）、ホームノードＢ（ＨＮＢ）、ホームｅＮＢ（ＨｅＮＢ）、サイトコントローラ、アクセスポイント（ＡＰ）および無線ルータなどとすることができる。基地局１１４ａ、１１４ｂはそれぞれ単一の要素として示されているが、基地局１１４ａ、１１４ｂは任意の数の相互接続された基地局および／またはネットワーク要素を含むことができることは理解されよう。

基地局１１４ａは、ＲＡＮ１０４の一部とすることができ、ＲＡＮ１０４はまた、基地局コントローラ（ＢＳＣ）、無線ネットワークコントローラ（ＲＮＣ）および中継ノードなど、他の基地局および／またはネットワーク要素（図示せず）を含むこともできる。基地局１１４ａおよび／または基地局１１４ｂは、セル（図示せず）と呼ばれることがある特定の地理的領域内で無線信号を送信および／または受信するように構成され得る。セルは、さらにセルセクタに分割されてもよい。例えば、基地局１１４ａに関連付けられたセルは３つのセクタに分割されてもよい。従って、一実施形態では、基地局１１４ａは、３つのトランシーバ、即ち、セルの各セクタに１つずつを含むことができる。別の実施形態では、基地局１１４ａは、多入力多出力（ＭＩＭＯ）技術を利用することができ、従って、セルの各セクタについて複数のトランシーバを利用することができる。

基地局１１４ａ、１１４ｂは、任意の適切な無線通信リンク（例えば、無線周波数（ＲＦ）、マイクロ波、赤外線（ＩＲ）、紫外線（ＵＶ）および可視光など）とすることができるエアインターフェース１１６を介して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの１または複数と通信することができる。エアインターフェース１１６は、任意の適切な無線アクセス技術（ＲＡＴ）を使用して確立され得る。

より具体的には、前述のように、通信システム１００は、多元接続システムとすることができ、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡおよびＳＣ−ＦＤＭＡなどの１または複数のチャネルアクセス方式を利用することができる。例えば、ＲＡＮ１０４内の基地局１１４ａ、およびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、広帯域ＣＤＭＡ（ＷＣＤＭＡ（登録商標））を使用してエアインターフェース１１６を確立することができるユニバーサル移動体通信システム（ＵＭＴＳ）地上波無線アクセス（ＵＴＲＡ）などの無線技術を実装することができる。ＷＣＤＭＡは、高速パケットアクセス（ＨＳＰＡ）および／または進化型ＨＳＰＡ（ＨＳＰＡ＋）などの通信プロトコルを含むことができる。ＨＳＰＡは、高速ダウンリンクパケットアクセス（ＨＳＤＰＡ）および／または高速アップリンクパケットアクセス（ＨＳＵＰＡ）を含むことができる。

別の実施形態では、基地局１１４ａ、およびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＬＴＥ（Long Term Evolution）および／またはＬＴＥアドバンスト（ＬＴＥ−Ａ）を使用してエアインターフェース１１６を確立することができる、進化型ＵＴＲＡ（Ｅ−ＵＴＲＡ）のような無線技術を実装することができる。

他の実施形態では、基地局１１４ａ、およびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＩＥＥＥ８０２．１６（即ち、ＷｉＭＡＸ）、ＣＤＭＡ２０００、ＣＤＭＡ２０００ １Ｘ、ＣＤＭＡ２０００ ＥＶ−ＤＯ（evolution-data optimized）、ＩＳ−２０００（Interim Standard 2000）、ＩＳ−９５（Interim Standard 95）、ＩＳ−８５６（Interim Standard 856）、ＧＳＭ（登録商標）（Global System for Mobile Communications）、ＥＤＧＥ（enhanced data rates for GSM Evolution）およびＧＥＲＡＮ（GSM/EDGE RAN）などの無線技術を実装することができる。

図１Ａにおける基地局１１４ｂは、例えば、無線ルータ、ＨＮＢ、ＨｅＮＢまたはＡＰとすることができ、事業所、住宅、乗物およびキャンパスなどの局所的エリアでの無線接続性を促進する任意の適切なＲＡＴを利用することができる。一実施形態では、基地局１１４ｂ、およびＷＴＲＵ１０２ｃ、１０２ｄは、無線ローカルエリアネットワーク（ＷＬＡＮ）を確立するために、ＩＥＥＥ８０２．１１などの無線技術を実装することができる。別の実施形態では、基地局１１４ｂ、およびＷＴＲＵ１０２ｃ、１０２ｄは、無線パーソナルエリアネットワーク（ＷＰＡＮ）を確立するために、ＩＥＥＥ８０２．１５などの無線技術を実装することができる。さらに別の実施形態では、基地局１１４ｂ、およびＷＴＲＵ１０２ｃ、１０２ｄは、ピコセルまたはフェムトセルを確立するために、セルラーベースのＲＡＴ（例えば、ＷＣＤＭＡ、ＣＤＭＡ２０００、ＧＳＭ、ＬＴＥおよびＬＴＥ−Ａなど）を利用することができる。図１Ａに示されるように、基地局１１４ｂは、インターネット１１０に対する直接接続を有することができる。基地局１１４ｂは、コアネットワーク１０６を介してインターネット１１０にアクセスする必要がないことがある。

ＲＡＮ１０４は、コアネットワーク１０６と通信することができ、コアネットワーク１０６は、音声、データ、アプリケーションおよび／またはＶｏＩＰ（Voice over Internet Protocol）サービスを、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの１または複数に提供するように構成された任意のタイプのネットワークとすることができる。例えば、コアネットワーク１０６は、呼制御、課金サービス、モバイル位置情報サービス、プリペイド通話、インターネット接続性、およびビデオ配信などを提供することができ、かつ／またはユーザ認証などの高レベルセキュリティ機能を実行することができる。図１Ａには示されていないが、ＲＡＮ１０４および／またはコアネットワーク１０６は、ＲＡＮ１０４と同じＲＡＴまたは異なるＲＡＴを利用する他のＲＡＮと直接または間接的に通信することができることは理解されよう。例えば、Ｅ−ＵＴＲＡ無線技術を利用し得るＲＡＮ１０４に接続されることに加えて、コアネットワーク１０６は、ＧＳＭ無線技術を利用する別のＲＡＮ（図示せず）と通信することもできる。

コアネットワーク１０６は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄがＰＳＴＮ１０８、インターネット１１０、および／または他のネットワーク１１２にアクセスするためのゲートウェイとして機能することができる。ＰＳＴＮ１０８は、基本電話サービス（ＰＯＴＳ）を提供する回線交換電話網を含むことができる。インターネット１１０は、ＴＣＰ／ＩＰスイートにおけるＴＣＰ、ＵＤＰおよびＩＰなど、一般的な通信プロトコルを使用する相互接続されたコンピュータネットワークおよびデバイスのグローバルシステムを含むことができる。ネットワーク１１２は他のサービスプロバイダによって所有および／または運営される有線または無線通信ネットワークを含むことができる。例えば、ネットワーク１１２は、ＲＡＮ１０４と同じＲＡＴまたは異なるＲＡＴを利用することができる１または複数のＲＡＮに接続された別のコアネットワークを含むことができる。

通信システム１００におけるＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの一部または全部がマルチモード機能を含むことができ、即ち、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、異なる無線リンクを介して異なる無線ネットワークと通信するために複数のトランシーバを含むことができる。例えば、図１Ａに示されるＷＴＲＵ１０２ｃは、セルラーベースの無線技術を利用することができる基地局１１４ａ、およびＩＥＥＥ８０２無線技術を利用することができる基地局１１４ｂと通信するように構成されてもよい。

図１Ｂは、図１Ａに示される通信システム１００内で使用され得る例示的ＷＴＲＵ１０２を示す。図１Ｂに示されるように、ＷＴＲＵ１０２は、プロセッサ１１８、トランシーバ１２０、送受信要素（例えばアンテナ）１２２、スピーカ／マイクロホン１２４、キーパッド１２６、ディスプレイ／タッチパッド１２８、非リムーバブルメモリ１３０、リムーバブルメモリ１３２、電源１３４、ＧＰＳチップセット１３６および周辺機器１３８を含むことができる。ＷＴＲＵ１０２は、実施形態と整合性を維持しながら、上述の要素の任意の部分的組み合わせを含み得ることは理解されよう。

プロセッサ１１８は、汎用プロセッサ、専用プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、マイクロプロセッサ、ＤＳＰコアに関連付けられた１または複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、ＡＳＩＣ、ＦＰＧＡ回路、集積回路（ＩＣ）および状態機械などとすることができる。プロセッサ１１８は、信号符号化、データ処理、電力制御、入力／出力処理、および／またはＷＴＲＵ１０２が無線環境で動作することを可能にする任意の他の機能性を実行することができる。プロセッサ１１８は、送受信要素１２２に結合され得るトランシーバ１２０に結合され得る。図１Ｂは、プロセッサ１１８とトランシーバ１２０を別個の構成要素として示しているが、プロセッサ１１８とトランシーバ１２０は、電子パッケージまたはチップに一体化されてもよい。

送受信要素１２２は、エアインターフェース１１６を介して基地局（例えば、基地局１１４ａ）に信号を送信し、または基地局から信号を受信するように構成され得る。例えば、一実施形態では、送受信要素１２２は、ＲＦ信号を送信および／または受信するように構成されたアンテナとすることができる。別の実施形態では、送受信要素１２２は、例えば、ＩＲ、ＵＶまたは可視光信号を、送信および／または受信するように構成されたエミッタ／検出器とすることができる。さらに別の実施形態では、送受信要素１２２は、ＲＦ信号と光信号の両方を送信および受信するように構成され得る。送受信要素１２２は、任意の組み合わせの無線信号を送信および／または受信するように構成されてもよい。

また、送受信要素１２２は図１Ｂに単一の要素として示されているが、ＷＴＲＵ１０２は任意の数の送受信要素１２２を含むことができる。より具体的には、ＷＴＲＵ１０２は、ＭＩＭＯ技術を利用することができる。従って、一実施形態では、ＷＴＲＵ１０２は、エアインターフェース１１６を介して無線信号を送信および受信するために２以上の送受信要素１２２（例えば、複数のアンテナ）を含むことができる。

トランシーバ１２０は、送受信要素１２２によって送信される信号を変調し、また送受信要素１２２によって受信された信号を復調するように構成され得る。前述のように、ＷＴＲＵ１０２は、マルチモード機能を有することができる。従って、トランシーバ１２０は、例えばＵＴＲＡおよびＩＥＥＥ８０２．１１など複数のＲＡＴを介してＷＴＲＵ１０２が通信することを可能にするために、複数のトランシーバを含むことができる。

ＷＴＲＵ１０２のプロセッサ１１８は、スピーカ／マイクロホン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８（例えば、液晶ディスプレイ（ＬＣＤ）ユニットもしくは有機発光ダイオード（ＯＬＥＤ）ディスプレイユニット）に結合されてよく、それらからユーザ入力データを受信することができる。また、プロセッサ１１８は、ユーザデータを、スピーカ／マイクロホン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８に出力することができる。さらに、プロセッサ１１８は、非リムーバブルメモリ１３０および／またはリムーバブルメモリ１３２など任意のタイプの適切なメモリの情報にアクセスし、またそれらにデータを記憶することができる。非リムーバブルメモリ１３０は、ＲＡＭ、ＲＯＭ、ハードディスク、または任意の他のタイプのメモリストレージデバイスを含むことができる。リムーバブルメモリ１３２は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、およびセキュアデジタル（ＳＤ）メモリカードなどを含むことができる。他の実施形態では、プロセッサ１１８は、サーバまたはホームコンピュータ（図示せず）上などの物理的にＷＴＲＵ１０２に位置しないメモリの情報にアクセスし、またそれらにデータを記憶することができる。

プロセッサ１１８は、電源１３４から電力を受け取ることができ、また、ＷＴＲＵ１０２内の他の構成要素への電力を分配および／または制御するように構成され得る。電源１３４は、ＷＴＲＵ１０２に電力供給するための任意の適切なデバイスとすることができる。例えば、電源１３４は、１または複数の乾電池（例えば、ニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉｏｎ）など）、太陽電池、および燃料電池などを含むことができる。

プロセッサ１１８はまた、ＧＰＳチップセット１３６にも結合されてもよく、ＧＰＳチップセット１３６は、ＷＴＲＵ１０２の現在位置に関する位置情報（例えば、経度および緯度）を提供するように構成されてもよい。ＧＰＳチップセット１３６からの情報に加えて、あるいはその代わりに、ＷＴＲＵ１０２は、基地局（例えば、基地局１１４ａ、１１４ｂ）からエアインターフェース１１６を介して位置情報を受信し、かつ／または、２以上の近隣の基地局から信号が受信されるタイミングに基づいて、その位置を決定することができる。ＷＴＲＵ１０２は、実施形態と整合性を維持しながら、任意の適切な位置決定方法により位置情報を取得することができる。

プロセッサ１１８はさらに、他の周辺機器１３８に結合されてもよく、それらは、追加的な特徴、機能性、および／または有線もしくは無線接続性を提供する１または複数のソフトウェアおよび／またはハードウェアモジュールを含むことができる。例えば、周辺機器１３８は、加速度計、電子コンパス、衛星トランシーバ、デジタルカメラ（写真またはビデオ用）、ＵＳＢポート、振動デバイス、テレビトランシーバ、ハンドフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈモジュール、周波数変調（ＦＭ）無線ユニット、デジタルミュージックプレイヤ、メディアプレイヤ、ビデオゲームプレイヤモジュール、およびインターネットブラウザなどを含むことができる。

図１Ｃは、図１Ａに示される通信システム１００内で使用され得る例示的ＲＡＮ１０４および例示的コアネットワーク１０６を示す。前述のように、ＲＡＮ１０４は、エアインターフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するためにＥ−ＵＴＲＡ無線技術を利用することができる。ＲＡＮ１０４は、コアネットワーク１０６と通信していることもできる。

ＲＡＮ１０４は、ｅＮＢ１４０ａ、１４０ｂ、１４０ｃを含むことができるが、ＲＡＮ１０４が、実施形態と整合性を維持しながら、任意の数のｅＮＢを含むことができることは理解されよう。ｅＮＢ１４０ａ、１４０ｂ、１４０ｃはそれぞれ、エアインターフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための１または複数のトランシーバを含むことができる。一実施形態では、ｅＮＢ１４０ａ、１４０ｂ、１４０ｃは、ＭＩＭＯ技術を実装することができる。従って、例えば、ｅＮＢ１４０ａは、ＷＴＲＵ１０２ａに無線信号を送信し、またＷＴＲＵ１０２ａから無線信号を受信するために複数のアンテナを使用することができる。

ｅＮＢ１４０ａ、１４０ｂ、１４０ｃのそれぞれは、特定のセル（図示せず）に関連付けられることができ、無線リソース管理判断、ハンドオーバ判断、並びにアップリンクおよび／またはダウンリンクでのユーザのスケジューリングなどを取り扱うように構成され得る。図１Ｃに示されるように、ｅＮＢ１４０ａ、１４０ｂ、１４０ｃは、Ｘ２インターフェースを介して互いに通信することができる。

図１Ｃに示されるコアネットワーク１０６は、モビリティ管理ゲートウェイ（ＭＭＥ）１４２、サービングゲートウェイ１４４、およびパケットデータネットワーク（ＰＤＮ）ゲートウェイ１４６を含むことができる。上述の要素のそれぞれはコアネットワーク１０６の一部として示されるが、これらの要素の任意の１つがコアネットワークオペレータ以外のエンティティによって所有および／または運営され得ることは理解されよう。

ＭＭＥ１４２は、Ｓ１インターフェースを介してＲＡＮ１０４におけるｅＮＢ１４０ａ、１４０ｂ、１４０ｃのそれぞれに接続されてもよく、制御ノードとして機能することができる。例えば、ＭＭＥ１４２は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのユーザの認証、ベアラアクティブ化／非アクティブ化、およびＷＴＲＵ１０２ａ、１０２ｂ、および１０２ｃの初期アタッチ中の特定サービングゲートウェイの選択などを担当することができる。ＭＭＥ１４２はまた、ＲＡＮ１０４と、ＧＳＭまたはＷＣＤＭＡなど他の無線技術を利用する他のＲＡＮ（図示せず）との切り替えをするための制御プレーン機能も提供することができる。

サービングゲートウェイ１４４は、Ｓ１インターフェースを介してＲＡＮ１０４におけるｅＮＢ１４０ａ、１４０ｂ、１４０ｃのそれぞれに接続され得る。サービングゲートウェイ１４４は、一般に、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃにユーザデータパケットを送り、またそれらからユーザデータパケットを転送することができる。サービングゲートウェイ１４４はまた、ｅＮＢ間のハンドオーバ中のユーザプレーンのアンカリング、ダウンリンクデータがＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに利用可能なときのページングのトリガー、並びにＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのコンテキストの管理および記憶など、他の機能を実行することができる。

サービングゲートウェイ１４４はまた、ＰＤＮゲートウェイ１４６に接続されてもよく、ＰＤＮゲートウェイ１４６は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃにインターネット１１０などのパケット交換ネットワークへのアクセスを提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスとの間の通信を容易にすることができる。

コアネットワーク１０６は、他のネットワークとの通信を容易にしてもよい。例えば、コアネットワーク１０６は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃにＰＳＴＮ１０８などの回線交換ネットワークへのアクセスを提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと従来の陸線通信デバイスとの間の通信を容易にすることができる。例えば、コアネットワーク１０６は、コアネットワーク１０６とＰＳＴＮ１０８の間のインターフェースとして機能するＩＰゲートウェイ（例えば、ＩＰマルチメディアサブシステム（ＩＭＳ）サーバ）を含んでもよく、またはこのＩＰゲートウェイと通信してもよい。加えて、コアネットワーク１０６は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃにネットワーク１１２へのアクセスを提供してもよく、ネットワーク１１２は、他のサービスプロバイダにより所有および／または運営される他の有線または無線ネットワークを含むことができる。

セルラー技術エコシステムから近傍サービス（ＰｒｏＳｅ）が受ける注目が高まっている。ＰｒｏＳｅは、２以上のデバイス（例えば、無線送受信ユニット（ＷＴＲＵ）、ユーザ機器（ＵＥ）、移動局）の間の近傍に依拠することができ、特定の商用およびソーシャルアプリケーション、ネットワークオフロード、または公共安全直接通信を可能にする。

Ｗｉ−ＦｉやＢｌｕｅｔｏｏｔｈなどの他の選択肢も２つのデバイスの間（Ｄ２Ｄ）の直接通信を可能にし得るが、それらはライセンス不要バンド上で動作し、従って、より高い干渉およびより低いサービス品質（ＱｏＳ）にさらされることがある。さらに、セルラー技術は、Ｄ２Ｄ通信のネットワーク制御を可能にすることができる。これは、デバイスのスキャン時間ひいてはそれらの電力消費を減らすために特に有利であり得る。しかしながら、これはまた、集中化インフラストラクチャによって与えられるリンクセキュリティレベルの観点からも有利であり得る。同じリソースが、Ｄ２Ｄのために再使用されることができ、インフラストラクチャモードが、各モード間の干渉のレベルの緊密な制御のもとで実装され得る。さらに、Ｄ２Ｄ能力をセルラー技術に追加することは、公共安全アプリケーションのために有用であり得る。同じ技術が、直接またはＤ２Ｄモードでの市内通話（地上基盤無線（terrestrial trunked radio：ＴＥＴＲＡ）で今日利用可能なものなど）に使用され得るが、同じ設備によって全国のセルラーネットワークへのアクセスを可能にすることもできる。これは、規模の経済をもたらすことができる。両方の能力の緊密な統合は、大きな災害の場合の応答時間および調整を改善し得る。

ＰｒｏＳｅは、Ｄ２Ｄ発見および通信手順を必要とすることがあり、それにより各手順は互いに独立して使用され得る。新しいＤ２Ｄ発見機能を使用する方法および装置が本明細書で説明されるが、それにより、１またはいくつかの監視デバイスが、１またはいくつかの発見可能デバイスを識別することを可能にされ得る。この新しいＤ２Ｄ発見機能は、発見サービス連続性を保証するように、サービスとＲＦアイデンティティの間のマッピングを最適化するように、発見プロセスにおける優先レベルを取り扱うように、モバイルの場合の発見を取り扱うように、かつ、ＰＬＭＮ（public land mobile network）を伴う発見手順を取り扱うように、アプリケーションレベルまたはネットワークレベルでトリガーされ得る。

以下では、用語「デバイス」は、その適用可能性を限定することなく、無線送受信ユニット（ＷＴＲＵ）、ユーザ機器（ＵＥ）、モバイルデバイスまたはネットワークノード、任意のアプリケーションまたはユーザ、クライアント、ネットワークアダプタ、またはこれらの任意の組み合わせなど、任意のエンティティを包含することができる。拡張して、デバイスは、その適用可能性を限定することなく、固定または移動中継装置、フェムトセル、スモールセル、およびホームｅＮＢ（ＨｅＮＢ）を包含することもできる。

以下では、用語「ネットワーク」は、デバイス（例えば、ＷＴＲＵ）の送信および／もしくは受信を制御する能力を有する、またはそのようなデバイスによって参照として使用される信号を送信する無線ネットワークインフラストラクチャの任意の要素または機能を指すことができる。ネットワークの例は、ｅＮＢ、ＭＭＥ、およびサービングゲートウェイ（Ｇ−ＳＷ）などを含むことができる。拡張して、ネットワークは、特定のコンテキストにおいてネットワークの能力を有する任意のデバイスを指すこともできる。例えば、公共安全アプリケーションによっては、デバイスは、同期参照を提供するなど特定の機能性のためのネットワークの役割をすることができる。

以下では、用語「発見（discovery）」は、第１のデバイスが第２のデバイスを検出できる手順を指すことができる。

以下では、用語「サービス発見（service discovery）」は、デバイスがサービスの利用可能性を検出できる手順を指すことができる。

以下では、用語「ＲＦ発見（RF discovery）」は、第２のデバイスの１または複数の無線特性に基づいて第１のデバイスが第２のデバイスの近傍を検出できる手順を指すことができる。例えば、第１のデバイスは、第２のデバイスによって送信された信号を検出することができ、または、第１のデバイスは、ネットワークによって（例えば、セルレベルの近傍について）第２のデバイスの近傍を通知されることができる。

以下では、用語「ＲＦ近傍（RF proximity）」は、第１のデバイスが第２のデバイスの範囲内にあることを指すことができる。この範囲は、メトリック測定に関係付けられ得る。例えば、ＲＦ近傍は、第２のデバイスにより送信された発見信号上の測定に基づいて第１のデバイスによって、または、第２のデバイスの送信上で行われた測定（または等価物）を受信することができるネットワーク内のエンティティによって検出され得る。

以下では、用語「発見アイデンティティ（discovery identity）」は、発見手順と要求デバイス間の関係を決定するために使用され得る識別子を指すことができる。発見アイデンティティは、ＲＦ発見手順もしくはサービス発見手順または両方に関連付けられ得る。

以下では、用語「サービス発見アイデンティティ（service discovery identity）」は、サービス発見手順に関連付けられた発見アイデンティティを指すことができる。

以下では、用語「ＲＦ発見アイデンティティ（RF discovery identity）」は、ＲＦ発見手順に関連付けられた発見アイデンティティを指すことができる。

以下では、用語「発見信号（discovery signal）」は、第１のデバイスによって送信される発見信号を指すことができる。そのような信号は、第２のデバイスによって受信されることができ、ＲＦ近傍を検出するために使用されることができる。発見信号は、ペイロード（例えば、サービス発見アイデンティティ）を含むことができる。

以下では、用語「発見共有チャネル（discovery shared channel）」または「ＤＩＳＣＨ」は、発見情報を含み得る論理チャネルを指すことができる。

以下では、用語「物理発見共有チャネル」または「ＰＤＩＳＣＨ」は、発見信号のためおよび／またはペイロードの送信のために使用される物理チャネルを指すことができる。例えば、ＰＤＩＳＣＨはＤＩＳＣＨメッセージを搬送することができる。用語ＤＩＳＣＨおよびＰＤＩＳＣＨは、交換可能に使用され得る。

以下では、用語「発見可能サービス（discoverable service）」は、サービス発見手順を使用して別のデバイス（例えば、ＷＴＲＵまたはアプリケーション）により検出され得るサービスを指すことができる。

以下では、用語「検出可能デバイス（detectable device）」は、ＲＦ発見手順を使用して別のデバイス（例えば、第１のＷＴＲＵ）により検出され得るデバイス（例えば、第２のＷＴＲＵ）を指すことができる。

以下では、用語「発見可能デバイス」、「発見可能ＷＴＲＵ」、または「プローブデバイス（probing device）」は、サービスをアドバタイズすることによって（即ち、デバイスが少なくとも１つの発見可能サービスを有することができる）、もしくは発見信号を送信することによって（即ち、検出可能デバイス）、または両方の組み合わせで、発見可能であり得るデバイスを指すことができる。従って、発見可能デバイスは、発見信号を送信する、かつ／または（例えば、ネットワークによりブロードキャストされた）ＤＩＳＣＨ上で少なくとも発見アイデンティティの送信を要求する、かつ／またはＤＩＳＣＨ上で少なくとも発見アイデンティティの送信を行うデバイスとすることができる。発見可能デバイスは、プローブデバイスと呼ばれることもある。

以下では、用語「探索デバイス（seeking device）」または「探索ＷＴＲＵ（seeking WTRU）」は、発見手順を開始するデバイスを指すことができる。

以下では、用語「監視デバイス（monitoring device）」、「監視ＷＴＲＵ（monitoring WTRU）」または「スキャンデバイス（scanning device）」は、サービスもしくは別のデバイス、または両方を能動的に検索するデバイスを指すことができる。例えば、監視デバイスは、時間／周波数内および／またはＤＩＳＣＨ上の所与のリソースにおける発見信号および／または発見アイデンティティについて監視することができる。監視デバイスは、本明細書では潜在的隣接要素（potential neighbor）と呼ばれることもある。

以下では、用語「発見サーバ（discovery server）」は、発見手順の管理に関係付けられた機能を実装するエンティティを指すことができる。これは、例えば、ネットワーク内のノード、または無線アクセスネットワーク（ＲＡＮ）内のノードであり得る。

以下では、用語「発見エリア（discovery area）」は、発見手順が発見サーバによって管理され得る地理的エリアを指すことができる。これは、セル、セルのグループ、トラッキングエリア（ＴＡ）、およびＴＡの一部分などに対応し得る。

以下では、用語「サービス近傍（service proximity）」は、第２のデバイスと同じ発見エリア内にある第１のデバイスを指すことができる。

以下では、用語「加入されたサービス（subscribed service(s)）」は、発見プロセスの候補となり得る１または複数の発見アイデンティティのセットを指すことができる。

以下では、用語「プライベートサービス）」は、それぞれの発見アイデンティティが、関係するサービスにアクセスするための適切な資格証明を有する監視デバイスのセットに制限される、１または複数の発見アイデンティティのセットを指すことができる。

サービス発見手順および装置が本明細書で説明される。サービス発見手順は、サービスの特性に基づいて第１のデバイスが第２のデバイスの利用可能性を検出することによって実装され得る。そのような特性は、例えば、本明細書で説明されるようなサービス発見アイデンティティを含むことができるが、これに限定されない。

サービスは、ネットワーク手順を含むことができるが、これに限定されない。これは、例えば、２以上のデバイスの間のＲＦ発見のための手順、それによりデバイスがその後互いに通信信号を直接送信することができる２以上のデバイス間の直接データ転送の確立、または、データがサービングｅＮＢを越えてもしくはより一般的にＲＡＮを越えて伝播する必要なしに複数のデバイス間でデータが交換され得るローカルパス最適化であり得る。それはまた、デバイスがサービスエリアを決定してサービスエリアをネットワーク内の調整エンティティに報告する手順を含むことができる。

サービスは、アプリケーションを含むことができるが、これに限定されない。これは、例えば、フェイスブックやＧｏｏｇｌｅ（登録商標）サークルなどのソーシャルネットワーキングアプリケーション、Ｆｏｕｒｓｑｕａｒｅや広告サービスなどの商用アプリケーション、ローカルメディアストリーミングを含むマルチメディア配信、または支払いサービスであり得る。

サービスは、ユーザ（例えば、ｕｓｅｒＡ＠ａｐｐｌｉｃａｔｉｏｎ．ｃｏｍなど）を含むことができるが、これに限定されない。

サービスは、関係（例えば、「友人関係」および商業契約など）を含むことができるが、これに限定されない。

サービスはまた、サービスタイプに関連付けられ得る。例えば、サービスは、調整機能、無線アクセスサービス、ソーシャルネットワーキングサービス、公共安全サービス、クローズドグループサービス、オープンサービス、一方向サービス（例えば、ブロードキャスト）、対話（例えば、双方向、マルチキャスト）サービスまたはこれらの組み合わせであり得る。サービスは、同じまたは異なるＲＡＮおよび／またはＰＬＭＮにおいて他のデバイスによってホストされ得る。他のデバイスは、ＲＦ近傍内であってもなくてもよい。

ＲＦ発見手順および装置が本明細書で説明される。ＲＦ発見手順において、第１のデバイスは、関係するデバイスの少なくとも１つの無線特性に基づいて第２のデバイスの近傍を検出することができる。例えば、第１のデバイスは、第２のデバイスによって送信された信号を検出することができ、または、第１のデバイスは、ネットワークによって（例えばセルレベルで）第２のデバイスの近傍を通知されることができる。１つのそのような特性は、発見信号に適用されるメトリック（参照信号受信電力（ＲＳＲＰ）および参照信号受信品質（ＲＳＲＱ）など）であり得る。第２のデバイスは、同じまたは異なるＲＡＮおよび／またはＰＬＭＮに接続され得る。

ＲＦ発見における近傍の決定は、第２のデバイスによって送信された発見信号を受信した第１のデバイスによって行われてもよい。ＲＦ発見における近傍の決定は、発見信号を受信したデバイスにより提供された少なくとも１つの報告に基づいて、発見サーバまたはｅＮＢなどのネットワークエンティティによって行われてもよい。ＲＦ発見における近傍の決定は、少なくとも１つの発見信号を受信した第２のデバイスにより提供された少なくとも１つの報告に基づいて、少なくとも１つの発見信号を前もって送信した第１のデバイスによって行われてもよい。報告は、ネットワークによる中継によって、または直接的にＤ２Ｄトランスポートチャネルによって、第１のデバイスに送られ得る。

ＲＦ発見手順は、デバイスによって開始され得る。この場合、デバイスは、発見信号の送信のためのリソースをネットワークに要求することができる。あるいは、ＲＦ発見手順は、ネットワークエンティティによって開始され得る。少なくとも第１のデバイスは、発見信号の送信のためにネットワークによってリソースを提供され得る。また、少なくとも１つの他のデバイスが、同じリソース割り振りを受け取ることができ、それにより、他のデバイスが第１のデバイスから発見信号を受信することができる。この場合、必要な資格証明を有する（例えば、第１のデバイスを検出することを可能にされた）デバイスが、関係するリソース割り振りを提供され得る。そのような信号は、無線リソース制御（ＲＲＣ）メッセージ内、メディアアクセス制御（ＭＡＣ）制御要素内、動的物理ダウンリンク制御チャネル（ＰＤＣＣＨ）メッセージ内、この目的に特有の論理チャネル（例えば、ＤＩＳＣＨ）、またはブロードキャストされたシステム情報（システム情報ブロック（ＳＩＢ））に含まれ得る。また、ネットワークは、発見信号上で行われた測定の報告を可能にするために他のデバイスに測定構成を提供することもできる。

発見事前選択方法および装置が本明細書で説明される。発見事前選択は、ＲＦ発見手順が２つのデバイス間で開始され得るかどうかまたは開始され得るときを決定するために使用される手順または手順のセットを指すことができる。事前選択は、サービスまたはデバイスのおよその地理的位置の知識に基づく、例えば、デバイスのサービングセルまたはＴＡに基づくことが可能である。事前選択は、ネットワークリソースおよび／またはデバイスバッテリリソースが効率的方法で使用されることを保証することができる。事前選択は、本明細書で説明されるように、ネットワークまたはデバイスによって行われ得る。事前選択は、ＲＦ発見手順を開始するまたは近傍を決定する同じエンティティによって行われてもそうでなくてもよい。

いくつかの解決法では、発見事前選択は、発見サーバなどのネットワークエンティティによって行われ得る。発見サーバ機能は、ｅＮＢ、ＭＭＥまたはネットワーク内の別の位置に配置され得る。この場合、ネットワークエンティティは、ネットワークエンティティにより制御される特定の地理的エリア（例えば、発見エリア）下であることが知られているデバイスに対応する発見アイデンティティのリスト、およびデバイスのおよその位置を保持することができる。事前選択は、リスト内の第１の発見アイデンティティがリスト内の第２の発見アイデンティティの発見可能サービスに対応し、かつおよそのデバイス位置が十分に近いかどうかを確認することによって、達成され得る。発見可能サービスは、サービス発見手順を使用して別のデバイスによって検出されるかつ／または検出されることが可能にされるデバイスまたはサービスであり得る。

ネットワークエンティティが特定の地理的エリア下の発見アイデンティティのリストを保持することを可能にする方法は、デバイスが、その発見アイデンティティおよびそのおよその位置を、それがリストに追加されるようにネットワークエンティティに提供することができるネットワークエンティティによって制御されるエリア内へ移動することを含むことができるが、これに限定されない。デバイスは、周期的に、または定義されたサービスエリア内に移動するもしくは定義されたサービスエリアを変更するとき、非アクセス層（ＮＡＳ）またはＲＲＣメッセージを介して情報を提供することができる。

ネットワークエンティティが特定の地理的エリア下の発見アイデンティティのリストを保持することを可能にする方法は、デバイスが、その発見アイデンティティおよびそのおよその位置を、それがリストから除去されるようにネットワークエンティティに提供することができるネットワークエンティティによって制御されるエリアの外へ移動することを含むことができるが、これに限定されない。デバイスは、周期的に、または定義されたサービスエリア外へ移動するとき、ＮＡＳまたはＲＲＣメッセージを介して情報を提供することができる。

ネットワークエンティティが特定の地理的エリア下の発見アイデンティティのリストを保持することを可能にする方法は、特定の発見アイデンティティに対応するデバイスのおよその位置が変更するとき、（または、デバイスがＲＣＣもしくは進化型パケットシステム（ＥＰＳ）モビリティ管理（ＥＭＭ）状態を変更するとき）、発見サーバが別のネットワークエンティティ（例えば、ＭＭＥまたはｅＮＢ）によって通知されることを含むことができるが、これに限定されない。

ネットワークエンティティが特定の地理的エリア下の発見アイデンティティのリストを保持することを可能にする方法は、発見可能サービスに対応する発見アイデンティティを有する少なくとも第２のデバイスが第１のデバイスと同じおよその位置にあることを検出するたびに、ネットワークエンティティ（例えば、ｅＮＢまたはＭＭＥ）に通知するまたはネットワークエンティティに示すことができる発見サーバを含むことができるが、これに限定されない。発見サーバは、それが、発見可能サービスに対応する発見アイデンティティを有する第２のデバイスが第１のデバイスと同じおよその位置にあることを検出したときに、第１および／または第２のデバイスに通知することができる。ネットワークエンティティは、ＲＦ発見手順を開始することができる。

発見事前選択は、デバイスによって行われもよい。デバイスベースの事前選択をサポートするために、デバイスは、そのおよその位置を、その発見アイデンティティおよび発見可能サービスを管理するアプリケーションサーバへ、アプリケーションサーバと共に可能な任意の通信手段を介して提供することができる。デバイスは、周期的に、またはネットワーク定義されたサービスエリアに対応するおよその位置の変更のときに情報を提供することができる。アプリケーションサーバは、それが、発見可能サービスに対応する発見アイデンティティを有する第２のデバイスが第１のデバイスと同じおよその位置にあることを検出したときに、第１および／または第２のデバイスに通知することができる。

デバイスは、ＲＦ発見手順を開始することができ、またはＲＦ発見手順が開始され得ることをネットワークに通知することができる。デバイスは、その発見アイデンティティ、および発見可能サービスに対応するデバイスのアイデンティティを（例えば、ＮＡＳまたはＲＲＣシグナリングを介して）ネットワークに示すことができる。

アイデンティティは、サービス発見および／またはＲＦ発見に関連付けられ得る。例えば、ネットワークベースの手法では、サービス発見に関連付けられたアイデンティティは、ＧＵＴＩ（globally unique temporary identity）、ＩＭＳＩ（international mobile subscriber identity）およびＰ−ＴＭＳＩ（packet temporary mobile subscriber identity）など、ネットワークレベルで知られたアイデンティティからなることができる。エンドユーザの観点からは、アイデンティティは、電話番号、電子メールアドレスまたはアプリケーション固有アイデンティティに対応し得る。

アイデンティティは複数の態様の組み合わせとして構成され得る。例えば、そのような態様は、サービスおよび／もしくはデバイスカテゴリ、タイプ、優先度、アクセシビリティ、並びに／またはアクセス権、または他の同様の原理の使用（例えば、サービスアイデンティティが、＜アプリケーション識別子＋アプリケーション固有識別子＞の形式を使用して構築され得る、また、ＲＦアイデンティティが、＜デバイスカテゴリ＋サービスのタイプ＋必要とされるアクセス権＞の形式を使用して構築され得る）を含むことができる。

セキュリティ機構が、アイデンティティの少なくとも一部分に適用され得る。機密保持のためにアイデンティティの少なくとも一部分に暗号化が適用され、関連付けられたセキュリティコンテキストを有する受信機のみがアイデンティティを正しく解釈できるようにされ得る。同様に、認証が、完全性検証のためにアイデンティティの少なくとも一部分に適用され、関連付けられたセキュリティコンテキストを有する受信機のみがアイデンティティの正しい解釈を検証できるようにされ得る。巡回冗長検査（ＣＲＣ）は、スクランブリングがアイデンティティに（例えば、ＲＦ発見アイデンティティに対して）提供されたときなどに、受信機が受信されたアイデンティティの正当性を検証できるようにする、アイデンティティの一態様であり得る。

フィルタリングが、１または複数のそのような態様に応じて適用され得る。例えば、ネットワークは、別のデバイスからの発見要求を含む要求の受信の際に、フィルタリングを適用することができる。フィルタリングは、アクセス権に基づいて、（例えば、他（プライベートサービス）に関する発見を制限しながら一部のアプリケーションを可能にするように）適用され得る。さらに、フィルタリングは、優先度に基づいて、（例えば、発見によるセル内の追加の負荷を制限するように）適用され得る。

ネットワークは、発見手順に利用可能なリソースが特定の閾値未満であるとき、より低い優先度を有する信号またはメッセージ（例えば、発見要求）を破棄することができる。デバイスは、サービスの要求を開始する前に潜在的候補の範囲を制限するなどのために、発見アイデンティティの受信の際、サービスのタイプに基づいて発見手順中にフィルタリングを適用することができる。デバイスは、デバイスが関心を有するタイプとは異なるタイプを有するアイデンティティを破棄および／または無視することができる。さらに別の例では、デバイスは、それが認証もしくはＣＲＣ検証のいずれかまたは両方に失敗した場合、アイデンティティを破棄および／または無視することができる。

アイデンティティは、同じアプリケーションの複数のユーザによって共有されてもよい。例えば、同じセルのデバイスが、サービスが無線アクセス技術（ＲＡＴ）アプリケーションに関係付けられる場合に、共通のアイデンティティを使用することができ、それにより、所与のデバイスが複数の他のデバイスによって発見できるまたは発見可能にできる。さらに別の例では、同じアプリケーションの異なるインスタンスが、各インスタンスについて同じ（例えば、ユーザＢに接続される）サービスを表すために同じアイデンティティを有することができる。

アイデンティティは、少なくとも１つの共通部分および少なくとも１つの専用部分からなることができる。例えば、アイデンティティの共通部分は、セル、位置登録エリア（ＬＡ）、ＴＡ、サービス発見エリア、ＰＬＭＮおよび／またはデバイス近傍エリアに関連付けられ得る。共通部分がセルに関連付けられた場合、同じセル内の全てのデバイスがアイデンティティの同じ共通部分を共有することができる。共通部分は、アプリケーションおよびサービスなどに対応することもできる。デバイスは、そのアイデンティティ内に複数の共通部分（例えば、セルアイデンティティ部分およびアプリケーション／サービスアイデンティティ部分）を有することができる。アイデンティティの専用部分は、一意のユーザに関連付けられてもよく、またはグループ、アプリケーション、もしくはサービスに関連付けられてもよい。例えば、位置（例えば、セル、ＴＡまたはデバイス近傍エリア）に関連付けられたアイデンティティの共通部分は、アプリケーションサーバまたはＤ２Ｄサーバによって、同じエリア内の少なくとも対のデバイスを識別するために使用されることができ、従って、ＲＦ近傍手順に適格になり得る。アイデンティティは、位置登録エリアの変更の際、またはデバイスまたはネットワークエンティティによるサービスアイデンティティの変更の際にアプリケーションサーバまたはＤ２Ｄサーバに提供され得る。

デバイスは、あるエリアから別のエリア（例えば、あるセルから別のセル）に移動するときに、そのサービスアイデンティティを自律的に更新することができる。例えば、デバイスは、共通セルアイデンティティ部分を専用アイデンティティに付加して、サービスアイデンティティを構築することができる。ネットワークが同じことを行ってもよい。あるいは、サービスアイデンティティは、ネットワークおよび／またはアプリケーションによって明示的に更新され得る。

アイデンティティは、期限切れ時間（または有効性の時間）に関連付けられ得る。例えば、デバイスは、それが関心を有し得る１または複数のアイデンティティを記憶することができ、そのアイデンティティは有効期間に関連付けられ得る。デバイスは、発見を求める要求を行い、関係するアイデンティティについての有効期間を超え得ない期間にそれがアイデンティティについての応答を受信しない場合に要求を繰り返すことができる。デバイスアイデンティティはまた、所与のエリア（例えば、セル、ＴＡ、ルーティングエリア（ＲＡ）、発見エリア、および／または近傍エリア）内で有効であり得る。アイデンティティは、セル内の接続性の持続期間に有効であってもよい。デバイスがセルを変更する（例えば、ハンドオーバを行う）、かつ／またはデバイスがＬＡ、ＲＡまたはＴＡを変更すると、アイデンティティまたはアイデンティティの部分がもはや有効でなくてもよい。

発見ＩＤが「選択規則」とも呼ばれる選択に利用可能なオプションのセットから選択され得る。選択規則は、ＷＴＲＵで予め構成されてもよく、またはネットワークによって提供されてもよい。選択規則は、ユニキャストまたはブロードキャストシグナリングを使用してｅＮＢによってＷＴＲＵに提供されてもよい。あるいは、選択規則は、コアネットワークエンティティ（例えば、ＭＭＥまたはＰｒｏＳｅ機能）によってＷＴＲＵで構成されてもよい。選択規則は、アプリケーション層シグナリングまたはＯＭＡ（Open Mobile Alliance）を使用してＷＴＲＵで構成されてもよい。選択規則は、送信のための識別子を選ぶため、または受信中に識別子をフィルタリングするための基準を提供することができる。基準は、発見のタイプを含むことができ、それにより、識別子のセットは開かれた発見（open discovery）または制限された発見（restricted discovery）のために使用され得る。基準は、アプリケーションＩＤを含むことができ、それにより、識別子のセットは特定のアプリケーションに対して可能にされ得る。基準は、ターゲット化対非ターゲット化発見を含むことができ、それにより、識別子のセットはターゲット化発見に対して可能にされ得る。基準は、近傍範囲を含むことができ、それにより、識別子のセットは範囲（例えば、小、中、大）に対して可能にされ得る。例えば、大きい範囲に対して発見が構成された場合、ＷＴＲＵは、大きいエリアの送信に対して割り振られたセットから識別子を選択することができる。選択規則は、どのように識別子が送信または受信に使用され得るかを定義するための他のパラメータに関連付けられてもよい。例えば、規則は、識別子のセットの送信に使用される電力、送信機会および受信ウィンドウなどを含むことができる。

サービス発見アイデンティティは、サービスに関連付けられ得る。サービス発見アイデンティティは、どのデバイスが、関係するサービスに関心を有する、そのサービスを提供している、そのサービスに参加している、またはそのサービスを利用可能にしているかを決定するために、本明細書で説明される手順によって使用され得る。

サービス発見アイデンティティは、制御機能（例えば、ＮＡＳまたはＲＲＣ）によって生成されてもよい。例えば、ネットワークが、関係するアプリケーションのためのアイデンティティを割り振ることができる。デバイスは、例えばＲＲＣ手順またはＮＡＳ手順を使用して、アイデンティティを受信することができる。

サービス発見アイデンティティは、アプリケーション（例えば、フェイスブックまたはＦｏｕｒＳｑｕａｒｅ（登録商標）など）によって生成されてもよい。アプリケーションは、本明細書で説明されるようにサービスに割り当てられ得る識別子のセットを管理することができる。アプリケーションは、アイデンティティをそのアプリケーションの異なるインスタンスの間で転送することができる。例えば、フェイスブックなどのアプリケーションは、第１のユーザの関係（例えば、Ｊｏｈｎの友人）にアイデンティティを割り当て、この関係に関連付けられた１または複数の他のユーザ（例えば、Ｊｏｈｎの友人の一部または全部）にアイデンティティを提供し、アイデンティティをサービス発見プロセスに関連付けることができ、それにより、この他のユーザのいずれも第１のユーザを発見することができる。発見手順のための発見の開始の時間（例えば、絶対時間）および有効期間（例えば、絶対期限切れ時間）のスケジューリングが、アイデンティティと一緒に提供されてもよい。デバイスと関係するアプリケーションとの間のアプリケーションプログラミングインターフェース（ＡＰＩ）が、アイデンティティそれ自体を含むアイデンティティに関係付けられた情報を交換するために使用されてもよい。

サービス発見アイデンティティは、例えば、オペレータに制御されかつ／またはインターネットプロトコル（ＩＰ）ネットワークのどこかに存在し得る集中サーバへの要求を使用して、クライアントによって生成され得る。要求は、ＤＨＣＰ（Dynamic Host Configuration Protocol）、ＳＯＡＰ（Simple Object Access Protocol）、およびＵＰｎＰ（Universal Plug and Play）などに類似のプロトコルを使用して作成され得る。

サービス発見アイデンティティは、数値（例えば、１６進数）を含むことができるが、これに限定されない。アイデンティティの異なる部分が、アイデンティティの異なる態様に割り当てられ得る。例えば、異なる値の範囲または値のグループが、アイデンティティの異なる態様に割り当てられ得る。

サービス発見アイデンティティは、サービス名（例えば、文字列）を含むことができるが、これに限定されない。ドメインネームシステム（ＤＮＳ）構造に類似した階層命名システム、例えば、形式<InstanceID.ServiceType.Domain>または<ApplicationID::ConnectionID>などのものが使用され得る。サービス名の各要素は、さらに数値に関連付けられてもよい。

サービス発見アイデンティティは、ＵＲＩ（Uniform Resource Identifier）（例えばUserA@application.com）を含むことができるが、これに限定されない。

サービス発見アイデンティティは、（例えば、ＸＭＬ（Extensible Markup Language）などのマークアップ言語を使用する）要素の構造化リストを含むことができるが、これに限定されない。

サービス発見アイデンティティは、複数のアイデンティティから導出されたアイデンティティを含むことができるが、これに限定されない。アイデンティティは、例えば、タイプ識別子（ＩＤ）、サービスＩＤ、デバイスＩＤ、オペレータＩＤおよびユーザＩＤなどから１または複数を組み合わせることによって構築されてもよい。

サービス発見アイデンティティは、ＲＦ発見アイデンティティまたはその導出された値を含むことができるが、これに限定されない。

サービス発見アイデンティティは、上記のいずれかに対する参照（reference）またはインデックスを含むことができるが、これに限定されない。

上記の組み合わせも可能である。特に、アイデンティティは、位置情報（例えば、セルアイデンティティ、隣接セルアイデンティティ、ＰＬＭＮおよび発見エリアアイデンティティなど）を含むことができる。デバイスは、そのような位置に基づいてそれがサービスに関心を有するかどうかを決定することができる。これはまた、ネットワークによって事前選択を行うために使用され得る。

サービスアイデンティティがもはや有効でなくなると、アイデンティティに関連付けられた（ＲＦアイデンティティなどの）任意のパラメータが無効にされ得る。例えば、ユーザおよびアプリケーションに対応するＵＲＩ（例えば、john@rn.facebook.com）が、ＸＭＬを使用して、ＲＦ発見アイデンティティ（例えば、物理リソースに対するインデックス）、サービスタイプ（例えば「発見可能」）およびアクセス権（例えば「友人」）に組み合わされることがある。それはまた、位置情報を含むこともできる。それはまた、発見手順のための発見の開始の時間（絶対時間）および（例えば絶対期限切れ時間としての）有効期間のスケジューリングを含むこともできる。

ＲＦ発見アイデンティティは、デバイスに関連付けられ得る。さらに、ＲＦ発見アイデンティティは、本明細書で説明される手順によって、どのデバイスが近接しているかまたは所与のデバイスが近接しているかどうかを決定するために使用され得る。

ＲＦ発見アイデンティティは、無線制御機能（例えば、ＮＡＳまたはＲＲＣ）によって生成されてもよい。ネットワークは、アイデンティティを所与のデバイスに割り当てることができる。デバイスは、例えばＲＲＣ手順またはＮＡＳ手順を使用して、アイデンティティを受信することができる。

ＲＦ発見アイデンティティは、クライアントによって、例えば集中サーバへの要求を使用して生成され得る。そのようなサーバは、オペレータに制御され得る。要求は、ＲＲＣまたはＮＡＳプロトコルを使用して作成され得る。

ＲＦ発見アイデンティティは、（例えば、関連付けられたサービス発見アイデンティティの機能を使用して初期化される）物理リソースに対するインデックス、時間および／もしくは周波数および／もしくは空間の物理リソース、またはスクランブリングシーケンスを含むことができるが、これらに限定されない。スクランブリングシーケンスは、ＲＦ発見信号として使用される送信に適用されてもよい。スクランブリングシーケンスは、ＰＤＩＳＣＨに関する送信に適用されてもよい。ＲＦ発見アイデンティティは、数値（例えば、１６進数）または（例えば、ＲＦ発見信号のペイロードとしての）サービス発見アイデンティティ、ＣＲＣ、または上記のいずれかに対する参照もしくはインデックスをさらに含むことができるが、これらに限定されない。ＲＦ発見アイデンティティがもはや有効でなくなると、アイデンティティに関連付けられた（無線リソースなどの）任意のパラメータが、無効にされ、関係するデバイスにもはや利用可能でなくなり得る。

デバイスは、優先度を発見手順に関連付けることができる。そのような優先度は、対応するプロセスに関連付けられたＱｏＳクラスに基づくことができる。あるいは、発見プロセスは発見クラスに関連付けられ得る。

デバイスは、そのような発見クラスを使用して、異なるタイプのサービスの間または送信のタイプの間（例えば、ＲＦ発見手順に関係付けられた送信とネットワークベースの送信との間）の優先度を実施することができる。

デバイスは、最大電力レベルを示し得る電力発見クラス（power discovery class）が割り当てられ得る。電力発見クラスは、デバイスのアクセスを発見クラスの範囲に限定することができる（例えば、電力クラス３を有するデバイスは、発見クラス５から７にアクセスできないことがあり得る）。電力クラスは、最大発見範囲（例えば２００メートル）を示すことができる。例えば、３つの異なるレベルの電力発見クラスが、ＲＦ発見に関する最大範囲（例えば、それぞれ５０メートル、２００メートル、および５００メートル）に基づいて指定され得る。これは、対応するＲＦ発見信号に対して可能にされた最大送信（Ｔｘ）電力に関係付けられ得る。

発見クラスは、サービスのタイプに基づくことができる。公共サービスアプリケーションに対応するあるサービスタイプは、商用アプリケーションに対応する別のサービスタイプより優先度が高いことが可能である。例えば、緊急信号または医療デバイスによって開始された発見プロセスは、デバイスの近隣のレストランを広告するプロセスより高い値で指定されてもよい。

発見クラスは、加入者プロファイルに基づくこともできる。例えば、公共安全アプリケーションをサポートする加入者に対応するデバイスは、より高い優先度のクラスの対応するサービスを有することができる。

発見クラスは、デバイスカテゴリに基づくこともできる。発見クラスは、最小待ち時間要件に関連付けられ得る。デバイスカテゴリは、アクセスを特定の発見クラスに制限することができる。

発見クラスは、デバイスステータスに基づくこともできる。公共安全配置では、クラスタの主要な役割をしているデバイスが特権的発見クラスを割り当てられ得る。

発見クラスの使用は、リソースのスケジューリングに適用され得る（発見クラスはＱｏＳクラスインジケータ（ＱＣＩ）に変換することができる）。これは、発見信号パラメータ（競合なし対競合ベースの反復および帯域幅など）に影響することができる。

発見クラスは、異なる要求間のプリエンプション（例えば、新しい要求に対応する新しいプロセスの開始を優先して、進行中であるが完了していない既存プロセスを解放すること）に基づくこともできる。

発見クラスは、ネットワーク通信の優先順位付け、発見プロセス解放戦略に基づくこともできる（例えば、タイムアウト値が発見クラスに関係付けられ得る）。

発見クラスは、発見サービス登録中に割り当てられ得る。それらは、異なるチャージ値（charging values）に関連付けられ得る。デバイスは、それが要求する発見プロセスのタイプに応じて異なる発見クラスを使用することができる。いくつかのクラスはＲＲＣ＿ＩＤＬＥモードに適合し得るが、他のクラスはそうではない。

専用発見（dedicated discovery）の使用の場合、デバイスのサブセット（即ち、潜在的隣接要素）は発見要求において示され得る。潜在的隣接要素の概念は、非常に広いことがあり、例えば、セルにアタッチされた全てのデバイスを指すことがある。例えば、このセットは、１つのデバイスからの特定の要求の後にＥＰＳによって提供され得る。ブラインド発見（blind discovery）の使用の場合、潜在的隣接要素の表示（indication）が存在しないことがある。

対称発見クラスが、発見可能であることを望む発見手順に関与する異なるデバイスに対して指定され得る。

非対称発見クラスは、発見手順に関与する少なくとも１つのデバイスが発見可能であることを望むことがない場合に指定されてもよい。

開かれた発見クラスが、（初期オペレータおよびユーザ設定に従う）先行認可なしに任意の時間に発見され得るデバイスに適用可能であってよい。

制限された発見クラスが適用可能であってよく、その場合、ユーザまたはアプリケーションからの先行認可が任意の発見プロセスの前に必要とされ得る。発見手順がアプリケーションレベルで認可された場合、隣接デバイス上の情報が特定のアプリケーションに制限されて、同じユーザによって実行される他のアプリケーションに限定されないことができる。

発見手順は、２以上のデバイス間の通信が行われる前に（事前手順）または後に（事後手順）開始され得る。デバイスは、１またはいくつかのＰＬＭＮに由来し得る。この手順は、アプリケーションから独立してネットワークによって適用され得る。この場合、アプリケーションは、２つのデバイスが隣接要素であることを知らないことが可能である。発見利得（ひいては通信利得）が、ネットワークの観点からパフォーマンスを改善することができる（例えば、Ｄ２Ｄ通信がネットワークトラフィック負荷を低減することができる）。アプリケーションは、発見手順を直接呼び出すことができ、発見利得が、アプリケーションそれ自体およびネットワークパフォーマンスについて実現され得る。

発見手順は、特に、商用／ソーシャルアプリケーション、ネットワークオフロード、および公共安全に適合され得る。発見手順は、ネットワークカバレッジ下のデバイスに適用できるが、公共安全の場合、ネットワークカバレッジ外の１またはいくつかのデバイスに適用することもできる。発見手順は、公共安全アプリケーション（例えば、プッシュツートークアプリケーション）における呼び出し手順の部分であってもよい。

発見プロセス方法の構成のための方法および装置が本明細書で説明される。発見手順構成は、デバイス発見プロセスを開始／終了または再構成するようにデバイスを構成するように、ネットワークによって行われ得る。発見プロセスは、ネットワーク構成、アプリケーションまたはデバイスイベントによって明示的にトリガー（開始／停止／中断）され得る。ネットワークベースのイベントは、特定のデバイスがサービス外であることまたはリンク状態の低下の報告をしていることをネットワークが検出したとき、トリガーされ得る。ネットワークは、近隣の全ての可能なデバイスについて発見プロセスを開始して発見手順を始める。ネットワークベースのイベントは、外部アプリケーションサーバまたはアプリケーションエンティティからトリガーされてもよい。ネットワークベースのイベントは、輻輳に応答してトリガーされてもよい。ネットワークは、オフロードを開始するために隣接要素を探索するようにデバイスを構成することができる。ネットワークベースのイベントは、データプレーン接続が同じＩＰネットワークまたは地理的位置の一部である２つのデバイスの間であるとネットワークが決定した場合に、トリガーされてもよい。

デバイスベースのイベントは、デバイスがサービス外であることまたはリンク状態の低下を報告していることをデバイスが検出することによって、トリガーされ得る。デバイスは、隣接デバイスから任意の発見信号を探すために、リッスン（listening）（受信）モードに移ることを自律的に開始することができる。リッスンモードを自律的に始める判断は、以前の明示的構成またはポリシーベースの構成に基づくことができる。

デバイスベースのイベントは、デバイス上で実行しているアプリケーションによってトリガーされてもよい。デバイスは、同じＩＰネットワーク内の対象デバイスとのセッションを開始することができる（この情報は、アプリケーションレベルで交換されていることが可能である）。

デバイスは、同じ地理的位置における対象デバイスとのセッションを開始することができる（例えば、アプリケーションが、ＧＰＳ座標を交換し、デバイスの非アクセス層（ＮＡＳ）／アクセス層（ＡＳ）をトリガーして直接発見を開始する）。

発見プロセス構成は、発見モードの構成、発見に関連付けられたポリシー、リソース構成、並びに発見送信の開始、停止および測定のための規則を含むことができる。

発見プロセス構成は、発見モードの構成、発見に関連付けられたポリシー、リソース構成、並びに発見送信の開始、停止および測定のための規則を含むことができる。発見プロセス構成は、発見信号リソース構成を含むことができ、それにより、発見リソースが、有効エリアを有するネットワークによって構成され得る（例えば、発見リソースは、ネットワーク全体または発見エリアまたはセルに対して構成され得る）。この有効性に応じて、デバイスは、それがあるエリアから他のエリアにハンドオーバするときに発見リソースを再取得するように構成され得る。

発見プロセス構成は、ビーコン送信周期性情報、および、リッスンのみ、送信のみまたはリッスンと送信の交互の期間を示すがこれらに限定されない動作情報の発見モードを含むことができる。動作情報の発見モードはまた、ブロードキャストまたは専用シグナリングが発見プロセスに使用され得るかどうかを示すこともできる。

デバイスは、それが発見アイデンティティの監視を始めると、デバイスが、発見アイデンティティが発見エリアにアドバタイズされるかどうかを検査するためにブロードキャストチャネルをデコードすることができるか、または、デバイスが、それが発見アイデンティティを監視することを告示するためにネットワークに専用シグナリングを送信することができるように、ネットワークによって構成され得る。デバイスは、発見リソースが開始され得るブロードキャストチャネルをデコードすることによって、または専用シグナリングを使用することによって、発見リソースを再取得するように、ネットワークによって構成され得る。

発見プロセス構成は、送信情報、受信情報または２つの組み合わせのデューティサイクルを含むことができる。発見プロセス構成は、発見シグナリングのための測定構成情報を含むことができる。

デバイスは、異なる時間において構成情報を用いて構成されることができ、これらの時間は、以下に限定されないが、デバイスが、ネットワークに最初にアタッチできるとき、デバイスが、セルに入ることができる、もしくは最初にセルに接続することができるとき（例えば、モビリティ制御情報を有するもしくは有しないＲＲＣ再構成のとき）、デバイスが、Ｄ２Ｄ通信のサービス要求を行うことができるとき、および／またはデバイス発見要求の後を含むことができる。

発見構成のためのメッセージングは、新しいもしくは既存のシステム情報ブロックメッセージを使用して、または、専用ＲＲＣシグナリング、ＭＡＣシグナリングもしくは専用ＮＡＳシグナリングを使用して、セル全体に対してブロードキャストされ得る。

異なる発見構成が、ブロードキャストチャネルにおける近傍サービスの異なるグループに対して示され得る。例えば、ＰｒｏＳｅサービスＳ１（ＰｒｏＳｅグループＧ１の一部）およびＳ２（ＰｒｏＳｅグループＧ２の一部）に登録されたデバイスは、ブロードキャストチャネルのデコーディングを通して、（Ｓ１の）ＰｒｏＳｅサービスグループＧ１および（Ｓ２の）ＰｒｏＳｅサービスグループＧ２に関連付けられた発見構成を識別するように構成され得る。Ｓ１について発見プロセスを実行するようにトリガーされると、デバイスは、グループＧ１発見構成に関連付けられた発見手順を適用することができる。

発見手順は、発見プロセス構成（要求／応答）、発見プロセス報告、発見プロセス修正、および／または発見プロセス解放を含む段階によって構成され得る。各段階は、１またはいくつかの関連付けられたメッセージにマッピングされ得る。いくつかの段階が、組み合わされまたは下位段階に分割されてもよい。複数の発見エリアまたは複数のＰＬＭＮを伴うモビリティおよび発見プロセスを取り扱うために追加の段階が必要とされ得る。

発見要求段階において、エンティティ（デバイスまたはネットワーク）が、別のエンティティ（ネットワークまたはデバイス）に要求を送って発見プロセスを始めることができる。

要求イニシエータ（request initiator）は、ステータスパラメータを提供することができる。要求イニシエータは、「発見可能」または「監視」ステータスをとることができる。この役割は、現在のデバイスステータス（バッテリレベル、位置および受信（Ｒｘ）信号対干渉雑音比（ＳＩＮＲ）など）、並びに／またはセキュリティコンテキストに基づいて、発見プロセスに先立ってアプリケーションレベルで定義され得る。

要求イニシエータは、発見タイプパラメータを提供することができる。発見プロセスは、ＲＦ近傍に、または発見エリア内のサービスの存在のみに向けられ得る。ＲＦ近傍の場合は、サービス検出を含むことができる。

発見タイプは、発見手順が「開かれている」かまたは「制限されている」かを示すことができる。「開かれている」場合、任意のデバイスが要求イニシエータを発見することを可能にされ得る。「制限されている」場合、デバイスは、要求イニシエータを発見するために明示的許可を必要とし得る。

発見タイプは、発見手順が「ターゲットとされている」かまたは「ターゲットとされていない」かを示すことができる。「ターゲットとされている」場合、要求イニシエータは、発見するための特定の発見アイデンティティを定義することができる。「ターゲットとされていない」場合、要求イニシエータは、発見するための特定の発見アイデンティティを定義することがなく、近接している任意のデバイスを発見するように開かれ得る。

要求イニシエータは、一時発見プロセス識別子（temporary discovery process identifier：Ｔ−ＤＰＩ）に参照を提供することができる。この参照は、この要求が新しくなく拒否された要求の反復であることを示すために使用され得る。例えば、これは、メッセージがネットワークにより要求された報告を含むときにも有用であり得る。

要求イニシエータは、発見アイデンティティのリストを提供することができる。要求イニシエータは、監視またはアドバタイズするための発見アイデンティティリストを提供することができる。監視の場合、要求イニシエータは、それ自体の発見アイデンティティを提供することもでき、その場合、発見が対称手順となる。発見可能の場合、イニシエータは、発見アイデンティティの一部分のみをアドバタイズするように要求することができる。それはまた、関係するサービスにアクセスするための適切な資格証明を有する監視デバイスのセットを提供することができる（これは、暗号化された発見アイデンティティを提供すること、および暗号化鍵を特定のセットのデバイスに提供することと等価である）。このリストは、発見サービスまたは更新などのような先行段階で提供されてもよい。

要求イニシエータは、発見プロセス持続期間に対応する生存時間（ＴＴＬ）パラメータを提供することができる。それは、静的発見プロセス（例えば、公共サービスのアドバタイズ）のための無限値をとることができる。絶対終了時間、並びに時間単位（サブフレームおよび秒など）での持続期間を含むがこれらに限定されないいくつかの単位が、このフィールドに使用され得る。発見応答受信の際にタイマが開始することができる。

要求イニシエータは、成功／失敗／報告の最大数を提供することができる。これらの数は、発見プロセスを解放するために使用され得る。それらは、独立して、または例えばＴＴＬ値と組み合わせて使用され得る。

要求イニシエータは、前述のように発見クラスを提供することができる。

要求イニシエータは、セキュリティコンテキストを提供することができる。（例えば、セルまたはセルのグループでブロードキャストされるＤＩＳＣＨ上で）発見アイデンティティのアドバタイズを行うために使用される方法によっては、このアイデンティティは機密性を保持するために暗号化され得る。この場合、対応する鍵を有するアプリケーションが発見アイデンティティをデコードすることができるように、使用されるべき暗号化鍵／方法に関する表示が提供され得る。

要求イニシエータは、発見信号の存在に関する報告を提供することができる。デバイスは、その近隣（例えばそれらのスケジューリングがブロードキャストされている場所）で発見信号の初期の報告を提供することができる。この報告は、発見プロセスで使用される発見アイデンティティ直交性を最大にするために、ネットワークによって使用され得る。

要求イニシエータは、受動または能動発見を提供することができる。受動発見は、デバイスが発見プロセス中に最終的にアイドルモードに切り替わり得ることを示すことができる。これは、その役割を監視に限定し得るが、発見プロセス中のネットワークメッセージング戦略で考慮されることもできる（例えば、ページング機会において送信されたメッセージなど）。

要求イニシエータは、解放トリガーオプションを提供することができる。発見プロセス解放トリガーは、発見要求内に示されてよく、イニシエータにより送られた成功／失敗／報告の最大数、ＴＴＬおよび明示的発見解放メッセージのうちの少なくとも１つに基づくことができる。

マルチＰＬＭＮ発見の場合、パラメータは、以下に限定されないが、ターゲットＰＬＭＮ、および監視された発見アイデンティティに関連付けられたデバイス識別子（例えば、電話番号など）を含む要求に追加されることができ、ターゲットＰＬＭＮの場合、要求イニシエータが１またはいくつかのターゲットＰＬＭＮ識別子を提供することができ、監視された発見アイデンティティが配置されていることが知られている。

発見要求メッセージの送信の後、デバイスは、将来の参照のためのＴ−ＤＰＩを記憶し、この発見要求に関連付けられたタイマを開始し、かつ／または対応するチャネル上で発見応答を監視することができる。

発見応答段階において、ネットワークは、デバイスにより送信された発見要求に対するその回答を提供することができる。ネットワークは、発見要求を受諾または拒否することができる。

受諾の場合、ネットワークは、発見プロセス識別子（ＤＰＩ）（任意のメッセージング（発見応答および解放など）でこのプロセスを参照するのに使用される一意の識別子）を提供することができる。

受諾の場合、ネットワークは、発見プロセスに専用にされる専用発見ＲＮＴＩを提供することができる。場合によっては、同じＲＮＴＩが、異なる発見プロセス（例えば、マルチキャスト発見）のために使用され得る。

受諾の場合、ネットワークは、初期報告を提供することができる。監視している場合、ネットワークは、それの応答において、要求に関係付けられた発見可能発見アイデンティティのリストを直接提供することができる。例えば、要求が発見グループアイデンティティに向けられている場合、ネットワークは、それの応答において、このグループの一部であって発見エリアに存在する現在の発見アイデンティティを提供することができる。監視デバイスが、この発見可能デバイスについて資格証明を有していない場合、報告は単純にそれをリストにすることがない。発見可能の場合、ネットワークは、それの応答において、発見アイデンティティを既に監視しているサービスアイデンティティのリストを直接提供することができる。

受諾の場合、ネットワークは、ＤＩＳＣＨパラメータを提供することができる。ネットワークは、スケジューリングおよびセキュリティパラメータなど、ＤＩＳＣＨをデコードするために必要とされる情報を提供することができる。

受諾の場合、ネットワークは、ＲＦ発見アイデンティティを提供することができる。ネットワークは、リソース情報を含むＲＦ発見手順に関連付けられたＲＦ発見アイデンティティの１つまたはグループを割り当てることができる。これらのアイデンティティは、他の進行中の発見プロセスで既に使用されていることがある。

受諾の場合、ネットワークは、発見信号に関連付けられた追加のパラメータ（例えば、初期送信電力などＲＦ発見アイデンティティに含まれない）を提供することができる。

発見応答（受諾）メッセージの受信のとき、デバイスは、ＰＤＣＣＨにおける専用ＲＮＴＩを監視し、ＤＩＳＣＨ受信をスケジューリングし、この発見プロセスに関連付けられたＴＴＬに設定された（タイマ）を開始し、この発見プロセスに関連付けられたカウンタ（成功／失敗／報告の最大数）を開始することができる。ＲＦアイデンティティのグループが提供される場合、一意のＲＦアイデンティティが、デバイスまたはサービスパラメータに基づいてこのグループ内で選択され得る。スケジューリング情報がＲＦ発見アイデンティティに含まれる場合、発見信号送信または受信がスケジューリングされ得る。ネットワークが開始した場合、発見要求が同様に対処され得る。

ネットワークは、その要求において、上記に説明された任意のパラメータを送信することができる。

拒否の場合、ネットワークは、デバイスが将来の発見要求の試みでこの応答を参照することができるように、Ｔ−ＤＰＩを提供することができる。

拒否の場合、ネットワークは、拒否理由を提供することができる。拒否の理由は、飽和されたネットワーク、ネットワーク上でサービスＩＤが可能にされない、サービスＩＤがもはや利用可能でない（例えば、発見エリアで前もって識別されたサービスに適用されたＲＦ発見の場合、サービスが発見エリアを去っているまたは無線リンク障害を経験していることがある）、および発見可能／監視の役割を切り替える必要を含むことができるが、これに限定されない。

拒否の場合、ネットワークは、次の認可された要求の前にタイマ値を提供することができる。例えば、無限の値は、対応するサービスが、可能にされない、サポートされない、または関係するエリア（例えば、セル、発見エリア、またはＰＬＭＮ）内の関係するデバイスに対して有効でないことを示すことができる。

拒否の場合、ネットワークは、発見信号の存在についての報告を提供することができる。ネットワークは、要求を受諾する前にその現在の近隣に関する最初または追加の報告を提供するようにデバイスに要求することができる。これは、信号送信が他の進行中の発見プロセスと干渉し得る「発見可能」の場合に特に有用であり得る。それはまた、分析するための発見ゾーンに関するスケジューリング情報を提供することもできる。

発見応答（拒否）メッセージの受信のとき、デバイスは、要求された報告を含む新しい発見要求を送信し、次の要求時間に対するタイマを開始し、将来の参照のためのＴ−ＤＰＩを記憶し、その原因とともに失敗をアプリケーションに報告することができる。

発見報告段階において、エンティティ（ネットワークまたはデバイス）は、発見プロセス上の別のエンティティ（デバイスまたはネットワーク）に報告を送ることができる。

発見報告メッセージがネットワークによって送られるとき、以下のパラメータが発見報告メッセージの一部となり得る。即ち、「発見可能」発見アイデンティティを監視するデバイス（それらのＲＦアイデンティティまたはサービスアイデンティティを介して識別される）のリスト、「発見アイデンティティ」発見を報告している監視デバイスのリスト、各監視デバイスに関連付けられた発見信号測定、監視された発見アイデンティティが発見エリア内で現在発見可能であることを示すためのフラグ、ＲＦ発見アイデンティティ、セキュリティコンテキスト、フィルタリングされた発見候補のリスト、閾値調節、および／または発見プロセス解放を示すフラグが、発見報告メッセージの一部となり得る。

発見報告メッセージがデバイスによって送られるとき、以下のパラメータが、報告イベントがトリガー（例えば、周期的報告またはイベントベースのトリガー）され得るときを示す表示であり得る発見報告メッセージの一部となり得る。即ち、報告メッセージで報告され得るデバイスの数、（それにより、周期的報告の場合、報告構成が周期性も含むことができる）、報告で送られ得るパラメータ、監視された信号上の測定結果、監視された信号上のＲＦ近傍結果、発見信号のタイミング問題、および／または潜在的発見候補のリストが、発見報告メッセージの一部となり得る。

発見報告メッセージの受信のとき、デバイスは、新しい報告を送る前にタイマを開始することができる。サービスアイデンティティを監視しているデバイスのリストが受信された場合、デバイスは、ＲＦ発見を開始するように新しい発見プロセスに要求することができる。監視されたサービスアイデンティティが発見エリアで発見可能になる場合、デバイスは、ＲＦ近傍に向けられている新しい発見要求を送信することができる。監視されたＲＦアイデンティティが発見可能になり、スケジューリング情報を含む場合、デバイスは、発見信号の監視を始めることができる。監視されたＲＦアイデンティティが発見可能になるが、スケジューリング情報を含まない場合、デバイスは、関係付けられたスケジューリング情報の監視を始めることができる。発見プロセス解放を示すフラグがオンの場合、デバイスは、発見プロセス解放段階で説明されたアクションをとることができる。

さらに、監視デバイスからの潜在的候補のリストがネットワークにより受信された場合、ネットワークは、それらの候補をフィルタリングし、新しい報告を監視デバイスに送信することができる。

デバイスがＩＤＬＥ（アイドル）モードであって報告を送信するように構成される場合、デバイスは、ＣＯＮＮＥＣＴＥＤ（接続）モードに切り替わって報告を送信するように構成され得る。ＲＦ近傍が、ＣＯＮＮＥＣＴＥＤモードへのＲＲＣ移行をトリガーすることができる。デバイスは、次のＣＯＮＮＥＣＴＥＤモード移行まで報告送信を遅延するように構成され得る（即ち、発見手順がＲＲＣ移行をトリガーしない）。デバイスは、ＩＤＬＥモードに留まり報告を送信するように構成され得る（例えば、発見報告が無接続手法の一部であり得る）。この場合、デバイスは、報告送信のための専用Ｓ１−Ｕベアラを確立することがない。発見報告は、報告送信がセルラー通信と干渉することがないように、ランダムアクセスチャネル（random access channel：ＲＡＣＨ）などの競合リソースで送信され得る。

デバイスは、発見プロセス構成の少なくとも１つの要素（例えば、無線リソース割り振り、発見アイデンティティおよび発見エリアなど）がもはや有効でないことを示すことができる。この表示は、専用もしくはブロードキャストシグナリングまたはタイマ期限切れによって提供され得る。

専用シグナリングの場合、デバイスは、専用無線リソース制御（ＲＲＣ）またはインターネットプロトコル（ＩＰ）シグナリングを介してそのような表示を受信することができる。ブロードキャストシグナリングの場合、システム情報ブロック（ＳＩＢ）でブロードキャストされたビットが、デバイスが発見構成の少なくとも１つの要素を取り出す必要があり得るときを示すことができる。複数のビットが、異なるサービスタイプおよび発見のタイプなどについてこの表示を提供するために使用され得る。

タイマ期限切れの場合、発見構成は、所与の持続期間において有効であり得る。

様々なトリガーに基づいて、デバイスは、発見プロセス構成の少なくとも１つの要素（例えば、無線リソース割り振り、発見アイデンティティおよび発見エリアなど）を再取得するように構成され得る。デバイスは、専用要求／応答によってこれらの要素を再取得することができ、それにより、デバイスは、ＲＲＣまたはＩＰシグナリングを介して発見構成再取得を要求するように構成され得る。デバイスは、ＣＯＮＮＥＣＴＥＤモードに切り替わる、かつ／またはＰｒｏＳｅ機能とのＲＲＣ接続を再確立するように構成され得る。デバイスは、専用ＲＲＣまたはＩＰシグナリングを介して更新された発見構成を受信するように構成され得る。ブロードキャストシグナリングの場合、デバイスは、ブロードキャストチャネルのデコーディングによって発見構成を再取得するように構成され得る。

発見プロセス解放段階において、発見プロセスは停止され得る。プロセス解放イニシエータは、デバイスまたはネットワークとすることができる。例えば、ネットワークは、リソースが欠如する場合に、低優先度の発見プロセスを終了することができる。デバイスは、アプリケーションが必要とされる発見情報を受信するとき、またはアプリケーションがユーザによって閉じられるときに発見プロセスを終了することができる。デバイスは、発見プロセスを終了するためのメッセージを受信したときに、発見プロセスを終了することができる。デバイスは、Ｄ２Ｄ近傍エリア（例えば、セル、ＴＡ）の変更のとき、発見プロセスを終了し発見プロセス構成をクリアすることができる。ネットワークは、デバイスがＤ２Ｄ近傍エリアを去るときに、発見プロセスを終了することができる。

以下のパラメータ、即ち、解放理由（例えば飽和されたネットワーク）および次の認可された要求の前のタイマ値が、発見解放メッセージの一部となり得る。

ネットワークからの発見解放メッセージの受信のとき、デバイスは、この発見プロセスに関連付けられた任意の信号送信を終了し、この発見プロセスに適用された任意のタイマをリセットし、かつ／または次の認可された要求時間のタイマを開始することができる。

デバイスは、発見信号測定リソースの少なくとも１つのセット上の発見測定を行い、結果をネットワークに報告することによって、ＲＦ発見を補助することができる。測定および発見測定の報告は、ＲＲＣプロトコルの測定サブシステムによって管理および制御され得る。または、それは論理チャネル（例えばＤＩＳＣＨ）を介して管理され得る。Ｄ２Ｄ発見手順の構成は、発見信号および発見手順の報告構成を測定するために使用され得る。

測定構成は、スキャンデバイスが報告のために考慮することができるホワイトリストに載せられたデバイスのセットを含むことができる（各構成されたデバイスは、セルＲＮＴＩ（Ｃ−ＲＮＴＩ）またはＳＡＥ（system architecture evolved）一時モバイル加入者アイデンティティ（Ｓ−ＴＭＳＩ）のようなセル固有またはエリア固有識別子によって識別され得る）。

測定構成は、スキャンデバイスが報告のために考慮することがないブラックリストに載せられたデバイスのセットを含むことができる。測定構成は、デバイスがスキャンまたは測定を行って隣接探索デバイスから発見信号を検出するために使用される、ギャップ構成または不連続送信（ＤＴＸ）構成パターンを含むことができる。測定構成は、デバイスが隣接探索デバイスを検出するために監視することができるリソースまたは周波数を含むことができる。

イベントにトリガーされる報告の場合、スキャンデバイスからの報告構成は、絶対および相対イベント構成（即ち、発見信号測定が絶対閾値を上回るもしくは下回るとき比較する、または他のデバイスからの測定と相対的に比較される）、を含むことができる。イベントにトリガーされる報告の場合、スキャンデバイスからの報告構成は、１または構成された数Ｎの隣接探索デバイスが検出されたときに報告をトリガーするための構成を含むことができる。イベントにトリガーされる報告の場合、スキャンデバイスからの報告構成は、既に検出されたデバイスがもはや検出されない（例えば、構成から去っている）ときに行われる報告のための構成を含むことができる。イベントにトリガーされる報告の場合、スキャンデバイスからの報告構成は、新しいデバイスが既に検出されたデバイスより良くなるときのための構成を含むことができる。

発見エリア「ＤＡ１」を去っているデバイスの場合、別の発見エリア「ＤＡ２」について、発見プロセスが、新しい発見エリアに転送され得るまたは解放され得る。発見プロセス転送において、特定のメッセージングが、２つの発見サーバの間の発見情報を転送するために使用され得る。転送される発見パラメータは、初期要求パラメータに類似することができ、以下の修正が、ＤＡ１に対する発見サーバによって適用される。即ち、ＴＴＬ値が残りのプロセス持続期間に基づいて更新され得る、デバイスアイデンティティを監視しているデバイスの現在のリストがＤＡ１に対する発見サーバに追加され得る、デバイスアイデンティティを識別した監視デバイスの現在のリストがＤＡ１に対する発見サーバに追加され得る、および、暗号化鍵／方法識別子が、ＤＡ１に対する発見サーバに追加され得る。

初期要求に基づいて、ＤＡ２発見サーバは、発見プロセス転送を受諾または拒否することができる。「拒否」の場合、発見プロセスは、ハンドオーバ完了前にＤＡ１発見サーバによって解放され得る。

発見プロセス解放において、ＤＡ１発見サーバは、ハンドオーバ完了前に発見プロセスを解放することができ、デバイスは、新しいセルにハンドオフすることができ、デバイスは、ＤＡ２発見サーバに新しい発見プロセスを要求することができる。

発見要求がいくつかのＰＬＭＮに関わる場合、ソースＰＬＭＮがターゲットＰＬＭＮに発見要求を転送することができる。上記に説明された初期要求パラメータは、転送メッセージに含まれ得る。いくつかのパラメータが、タイマ（ＴＴＬ）およびカウンタの更新などによって、追加または修正され得る。発見サーバは、ターゲットＰＬＭＮにおけるデバイスの追跡を補助し得る地理的表示を提供することができる。

発見報告メッセージの受信のとき、以下の手順が使用され得る。即ち、ターゲットＰＬＭＮが、ターゲットデバイス識別子をそれのネットワークにおいて追跡し、対応する発見エリアを選択することができる、ターゲットＰＬＭＮが、選択された発見サーバに発見要求を転送し、発見サーバが、発見要求を受諾もしくは拒否することができる、ターゲットＰＬＭＮが、発見応答をソースＰＬＭＮに送信することができる、発見サーバが、ターゲットデバイスとともに新しい発見プロセスを開始することができる、ターゲットＰＬＭＮが、発見報告および／もしくは発見スケジューリング表示をソースＰＬＭＮに転送することができる、かつ／または、ソースＰＬＭＮが、それらのメッセージを対応する発見サーバに転送するのを担当することができる。

ＲＦ発見プロセスの場合、ソースＰＬＭＮは、測定構成を監視デバイスに提供することができる。この測定構成は、測定ギャップを含み、ターゲットＰＬＭＮ搬送周波数を示すことができる。測定ギャップ中に、デバイスは、ターゲットＰＬＭＮ信号に同期し、現在のサブフレーム番号をデコードし、発見信号がスケジューリングされたサブフレームをデコードすることができる。デバイスは、ターゲットＰＬＭＮにアタッチする必要がない。測定ギャップが終了すると、デバイスは、ソースＰＬＭＮに切り替わって戻り、報告をそれの発見サーバに送信することができる。ソースＰＬＭＮは、この報告をターゲットＰＬＭＮに転送することができる。発見プロセス解放は、プロセスに関与した任意のＰＬＭＮによって要求されることができ、関与したＰＬＭＮのセットに分配され得る。

監視デバイスは、マルチＰＬＭＮ発見を要求することができる。発見可能デバイスは、単一ＰＬＭＮ発見を要求することができる。これは、測定処理を簡略化することができる（訪問されたＰＬＭＮ上のデバイスは、それが単に監視しているときにアタッチしてもしなくてもよい）。

ネットワークによって開始される発見可能および監視要求手順が、本明細書で説明される。

ネットワークは、発見可能および監視要求手順を開始することができる。これは、例えばソースからの発見要求を受信した後に行われ得る。少なくとも１つのデバイスが発見可能状態にあってよく、少なくとも１つのデバイスが監視状態にあってよい。発見可能状態のデバイスが、少なくとも１つの発見信号を送信することができる。監視状態のデバイスが、少なくとも１つの発見信号を受信するまたは受信しようと試みることができる。デバイスは、発見可能状態と監視状態の両方であることが可能であり、そうすると、それは、（例えば異なるリソースで、）少なくとも１つの発見信号を送信し、少なくとも１つの発見信号を受信または受信しようと試みることができる。デバイスは、それがいかなる発見信号も送信または受信の試みをしない「ヌル」状態にあることも可能である。

図２Ａは、複数の発見可能デバイス２０５、監視デバイス２１０および探索デバイス２１５を含むネットワーク２００についてのパラメータに対する発見可能および監視状態の影響の例を示す。図２Ｂは、複数の発見可能デバイス２５５、監視デバイス２６０および探索デバイス２６５を含むネットワーク２５０についてのパラメータに対する発見可能および監視状態の影響の例を示す。発見手順において、発見可能または監視状態は、デバイスステータス（探索デバイスまたは潜在的隣接要素）から独立し得る。探索デバイス２１５および２６５は監視状態に割り当てられることができ、それにより、それら各々の潜在的隣接要素は発見可能状態に割り当てられることができる。

図２Ａおよび図２Ｂに示されるように、発見可能および監視デバイスの選択は、発見応答性、デバイスバッテリレベル、ネットワークエネルギー効率および容量の間の妥協の結果であり得る。この妥協は、ネットワーク内のノード（デバイス）の数、それらの現在のバッテリ電力レベル、それらのモビリティおよび特に発見信号帯域幅などのネットワークパラメータによって影響され得る。従って、ネットワーク２００および２５０は、発見可能要求に関する最適判断を行うためにこれらのメトリクスへのアクセスを有することができる。１つのメトリックが最新でない場合、ネットワーク２００および２５０は、（例えば、バッテリ電力レベルに基づいて、）１またはいくつかのノードに特定の報告を要求することができる。その現在の状態に基づいて、ネットワーク２００および２５０は、ノードを、発見可能、監視、通信またはアイドルモードに割り当てることができる（いくつかの場合、通信モードは、発見可能または監視モードと共存することができる）。

発見可能および監視要求メッセージは、ユニキャスト、マルチキャストまたはブロードキャストとすることができ、以下に限定されないが、該当する場合、デバイスが発見可能状態かそれとも監視状態であり得るか；チャネルアクセスモード（競合ベースおよび／または競合なしパラメータ）；リソース割り振りモード（（制御チャネルを介する）静的、半永続的または動的）；Ｔｘ電力割り当て（例えば、発見可能要求）；チャネルリソース割り振り（特定のリソースまたはリソースのセット）；信号インデックス（特定のインデックスまたはインデックスのセット）；（参照同期に関係付けられた）Ｔｘタイミングオフセット；プロセスを終了するトリガー（信号肯定応答、完了された隣接識別、タイマ、または単発手順）；発見要求パラメータ（例えば、発見グループ識別、デバイス、ネットワークまたはアプリケーションなどのイニシエータ、優先度、待ち時間要件、セキュリティパラメータ）；発見信号同期（即ち、発見信号が同期バースト／プリアンブルを含む（このバーストは異なるチャネル上で送られ得る））；フォーマット、ダイバーシチ方式、変調および符号方式（ＭＣＳ）を含むがこれらに限定されない追加の発見信号パラメータ；並びに、肯定応答パラメータ：チャネルリソース割り振り（時間オフセットを有する発見可能信号と同じリソースまたは異なるリソース）、（電力またはタイミングオフセットを含むがこれらに限定されない）適用される測定を示す、パラメータの組み合わせを含むことができる。

パラメータのこの組み合わせは、同じＤ２Ｄ発見要求に関連付けられた発見可能および監視要求に対して異なってもよい。

発見可能／監視の結合手順が、２つの別個の手順を使用せずに実装されてもよく、それにより、発見手順に関与するノードへ、発見可能および監視パラメータが（例えば、同じダウンリンク制御情報（ＤＣＩ）で）一緒に提供され得る。図２Ａおよび図２Ｂに示すように、発見可能期間２３０および２７０並びに監視期間２４０および２８０は、ノードごとに定義され得る。これらの期間は特定の形で定義され得る（例えば、単一または複数の発見可能／監視段階がインターリーブされ得る）。発見可能／監視モードの切り替えは、特定のイベントに依存してもよい。例えば、第１の発見信号の識別の後に、ノードが、監視モードから発見可能モードに切り替わることができる。モード切り替えは、タイマまたはカウンタに依存してもよい。例えば、ノードは、（そのネットワークＵＬスケジュールに応じて）それが送るべきＴｘ信号を他に有しないとすぐに、発見可能モードに切り替わることができる。ノードが発見可能状態に移行するたびに、ノードはカウンタを増分することができる。カウンタ上限に達したとき、発見可能モードが終了され得る。隣接要素識別が失敗した場合、新しい発見可能要求がネットワークによって送られ得る。

発見可能／監視要求イニシエータはまた、その優先度の取り扱いを担当することもできる。例えば、新しい発見要求がより高い優先度で受信され、ノードが既に発見可能状態である場合、ネットワークが、プリエンプション機構を取り扱い、（少なくともこのノードについて）この発見プロセスに関連付けられた監視セッションと同様の様式で初期発見可能セッションを終了することができる。

デバイス位置決めに適用されるデバイスＤ２Ｄ発見手順が本明細書で説明される。Ｄ２Ｄ発見の１つの可能な用途は位置および存在サービス強化であり得る。発見信号およびその肯定応答は、探索デバイスとその隣接要素の間のラウンドトリップ時間（ＲＴＴ）を計算するために使用され得る。このＲＴＴは、２つのデバイスの間の距離を計算するために使用され得る。２つのデバイスのいずれかの位置が、（Ａ−ＧＮＳＳ：Assisted Global Navigation Satellite System）などの任意のＬＴＥ位置決め手順によって）既に知られている場合、第２のデバイスの位置が推定され得る。発見信号または肯定応答信号の到来角（ＡｏＡ：angle of arrival）がデバイス位置のうちの１つの方向情報を提供するために使用され得る（より良い初期位置推定を有するデバイスが参照として使用され得る）。

上記の手順は、強化された推定を得るために組み合わされてもよい。さらに、３つ以上のデバイスがＤ２Ｄ発見に関与する場合、推定は、各デバイスによって得られる情報を相互に関連付けることにより改良され得る（例えば、３つのデバイスの間で計算されたＲＴＴまたはＡｏＡが、通常の三角測量または三辺測量方法などで正確な位置を得るために使用され得る）。

発見プロセスは、ＲＲＣ接続管理と相互作用することができる。発見プロセスは、ＥＵＴＲＡＮ、またはデバイス高位層（例えば、ＮＡＳ、ＰｒｏＳｅクライアント、デバイスアプリケーション層）によるシグナリングによってトリガーされ得る。１つの方法では、発見プロセスがトリガーされると、それはデバイスを開始して新しいＲＲＣ接続を確立することができる。別の方法では、発見プロセスがトリガーされ、デバイスが発見情報の送信機となるように指定されると、デバイスは接続確立を開始することができる。接続確立原因は、理由がＰｒｏＳｅ発見であることを示すように設定され得る。

ＲＦ発見は、送信デバイスに関連付けられたパラメータを識別するＲＦメッセージを送信および／または受信することを含むことができる。送信デバイス（または告示デバイス（announcing device））は、ＲＦ発見メッセージを送信することができ、ＲＦ発見メッセージは、以下のパラメータ、即ち、デバイスＩＤ、ユーザＩＤ、アプリケーションＩＤ、アプリケーションサービスタイプおよび／またはＰｒｏＳｅ ＩＤのいずれかに、マッピングすることができる。

受信機（または監視）デバイスは、対象のＲＦ発見ＩＤを監視するように構成され得る。構成された署名に合致するＲＦ発見ＩＤを受信機が検出すると、受信機は、以下に説明されるアクションを行うことができる。同じデバイスが、発見プロセスについて告示および監視する機能、もしくはある発見プロセスについて告示し別の発見プロセスについて監視する機能、またはこれらの任意の組み合わせを行うことができる。

ＲＦ発見ＩＤの検出が成功すると、デバイスは、ＲＲＣ接続要求を開始して、ＲＲＣ＿ＩＤＬＥ（ＲＲＣアイドル）からＲＲＣ＿ＣＯＮＮＥＣＴＥＤ（ＲＲＣ接続）に進むように要求することができる。

ＲＦ発見ＩＤの検出が成功すると、デバイスは、発見測定報告の送信を開始することができる。

ＲＦ発見ＩＤの検出が成功すると、デバイスが既にＲＲＣ＿ＣＯＮＮＥＣＴＥＤモードにある場合、デバイスは、サービス発見メッセージを送るためのグラントを求めるスケジューリング要求を開始することができる。

ＲＦ発見ＩＤの検出が成功すると、デバイスは、メッセージを高位層（例えば、ＮＡＳおよび／またはＰｒｏＳｅクライアント）に送ることができる。

ＲＦ発見ＩＤの検出が成功すると、デバイスは、ＲＡＣＨメッセージをｅＮＢに送ることができる。

サービス発見メッセージの検出が成功すると、デバイスは、ＲＲＣ接続要求を開始し、ＲＲＣ＿ＩＤＬＥからＲＲＣ＿ＣＯＮＮＥＣＴＥＤに進むように要求することができる。

サービス発見メッセージの検出が成功すると、デバイスは、発見測定報告の送信を開始することができる。

サービス発見メッセージの検出が成功すると、デバイスは、スケジューリング要求を開始することができる。スケジューリング要求構成は、クロスリンク通信のグラントを要求するためにデバイスに提供され得る。グラントの目的は、応答ペイロード（例えば、サービス発見肯定応答）を搬送することであり得る。

サービス発見メッセージの検出が成功すると、デバイスは、メッセージを高位層（例えば、ＮＡＳおよび／またはＰｒｏＳｅクライアント）に送ることができる。

サービス発見メッセージの検出が成功すると、デバイスは、グラントを得るための要求とともにＲＡＣＨメッセージをｅＮＢに送ることができる。

発見手順および関係付けられた送信は、既存のＬＴＥ手順に影響することができる。例えば、本明細書で適用される一般的原理として、発見は、スケジュールされたおよび／または進行中の送信に少なくともあり得る影響を有することを確実にするのが望ましいことがある。例えば、発見のためのリソースがセル固有であり、トリガーがデバイス自律であり得る場合における（例えば、ネットワークは、リソースの割り振りを制御することができるが、ＲＦ発見送信を行うトリガーを制御することがない）。そのような場合、ネットワークは、競合する状況が所与のサブフレームについて発生し得るかどうかを正確に決定することができない。

あるいは、原理の例外のためにいくつかの規則が必要とされることがあり、それにより、発見に関係付けられた送信が、スケジューリングされたかつ／または進行中の送信に対して優先され得る。例外の１つの理由は、ＲＦ発見が、ネットワークに知られ関係するデバイスを含み得る関係するデバイスおよび／またはデバイスのグループへの動的シグナリングを使用して、ネットワークにより制御されるときを含むことができるが、これに限定されない。そのような場合、ネットワークは、競合する状況が所与のサブフレームについて発生し得るときを正確に決定する能力を有することができる。

ある場合、発見リソースがデバイスごとにスケジューリングされ得るという考慮事項があり得る。別の考慮事項として、リソースのセットが発見のためにスケジューリングされ得るが、このセット内のデバイスによって使用される特定のリソースが、ネットワークによって知られることがないということがあり得る。これらの考慮事項は、本明細書では、時間（サブフレーム）および／または周波数（物理リソースブロック（ＰＲＢ））における衝突の場合に議論される。例えば、デバイス（即ち、デバイス固有の様式で適用される）の全ての送信（例えば、アップリンクおよびダウンリンク）、または関係する送信のみが、発見手順に関係付けられた送信にも適用可能なような同じトランシーバチェーンに向けられ得る。

複数のトランシーバチェーンを実装するデバイスは、ネットワークに関係付けられたＬＴＥ物理層手順および発見に関係付けられた物理層手順を、それぞれの異なるトランシーバチェーンを使用して互いに独立して行うことができる。例えば、アイドルモードのデバイス、単一キャリア動作用に構成されたデバイス、バンド内連続キャリア動作用に構成されたデバイス、および／またはシングルタイミングアドバンスグループ（single timing advance groups：ＴＡＧｓ）により構成されたデバイスが、第２のトランシーバを発見に専用とすることができる。

上記と異なるアーキテクチャを有するデバイス、またはより一般的に、ＬＴＥ動作と発見動作のために同じトランシーバチェーンを使用するデバイスは、以下に説明される挙動から利益を得ることができる。

ネットワーク通信と発見手順の間の優先順位付けは、以下のパラメータ、即ち、発見クラス、デバイス発見ステータス（監視または発見可能）、発見信号特性（例えば反復など）、およびデバイス能力を考慮することができる。発見可能デバイスは、発見サブフレームを破棄する柔軟性が低いことがあり、そのため、破棄ごとに、監視デバイスは影響されることがあり、ただし、特定の監視デバイスによる破棄はそれ自体の発見プロセスに影響するだけであり得る。

発見クラスに基づいて、デバイスは、後続のネットワーク通信対発見信号送信／受信を破棄または優先付けることができる。全ての場合において、破棄の場合は、関係するシグナリングの上限の連続またはパーセンテージに限定され得る（パーセンテージは発見クラスに固有であり得る）。これらの規則は、特定のネットワーク要求が受信された場合に回避され得る。

デバイスは、ＲＦ発見のためにスケジューリングされたサブフレームにおいて物理アップリンク制御チャネル（ＰＵＣＣＨ）上でハイブリッド自動再送要求（ＨＡＲＱ）フィードバック送信を優先付けることができる。

デバイスは、ＲＦ発見のためにスケジューリングされたサブフレームにおいて物理アップリンク共有チャネル（ＰＵＳＣＨ）（再）送信を優先付けることができる。そのような場合、それは、関係するサブフレームがＲＦ発見用のサブフレームである場合にＰＤＣＣＨ上の適応再送信のための対応するスケジューリング機会を優先付けることができる
デバイスは、ＲＦ発見のためにスケジューリングされたサブフレームにおいてＰＵＣＣＨ上で専用スケジューリング要求（Ｄ−ＳＲ）を優先付けることができる。あるいは、そのような場合、デバイスは、次のＤ−ＳＲ機会まで延期をすることができる。

デバイスは、ＲＦ発見のためにスケジューリングされたサブフレームにおいてＰＵＣＣＨ上で非周期チャネル状態情報（ＣＳＩ）報告（チャネル品質インジケータ（ＣＱＩ）／プリコーディング行列インジケータ（ＰＭＩ）／ランクインジケータ（ＲＩ））を優先付けることができる。

デバイスは、ＲＦ発見のためにスケジューリングされたサブフレームにおいてＰＵＣＣＨ上で周期的ＣＳＩ報告（ＣＱＩ／ＰＭＩ／ＲＩ）を優先付けることができる。あるいはまたは加えて、デバイスは、そのような場合、周期的ＣＳＩ送信を破棄することができる（即ち、優先順位付けは、報告が周期的または非周期的であるかどうかに応じ得る）。

デバイスは、ＲＦ発見のためにスケジューリングされたサブフレームにおいて非周期的サウンディング参照信号（ＳＲＳ）送信を優先付けることができる。デバイスは、ＲＦ発見のためにスケジューリングされたサブフレームにおいて周期的ＳＲＳ送信を優先付けることができる。あるいは、デバイスは、そのような場合、周期的ＳＲＳ送信を破棄することができる（即ち、優先順位付けは、ＳＲＳが周期的または非周期的であるかどうかに応じ得る）。

デバイスは、ＲＦ発見のためにスケジューリングされたサブフレームにおいて物理ランダムアクセスチャネル（ＰＲＡＣＨ）専用（競合なし）リソースでのプリアンブル送信を優先付けることができる。あるいはまたは加えて、デバイスは、そのような場合、プリアンブル送信を次のＰＲＡＣＨ機会まで延期することができる。

デバイスは、ＲＦ発見のためにスケジューリングされたサブフレームにおいてＰＲＡＣＨ競合ベースのリソースでのプリアンブル送信を優先付けることができる（即ち、優先順位付けはトリガーがデバイス自律またはネットワーク制御であるかどうかに応じ得る）。

デバイスは、ＲＦ発見のためにスケジューリングされたサブフレームにおいて、送信時間間隔（ＴＴＩ）バンドル送信の一部である送信を優先付けることができる。

関係するデバイスは、セル固有であるシグナリングを使用してＲＦ発見送信を決定することができる（即ち、デバイスは、専用シグナリングを使用してスケジューリング情報を受信することがない、例えば、ネットワークが認識することがない）。関係するデバイスは、監視デバイスであり得る（例えば、ネットワークが認識することがない）。

そのＣ−ＲＮＴＩ向けの専用シグナリングを使用してＲＦ発見用の制御情報を受信する発見可能デバイス（例えば、ネットワークが認識する）は、代わりに、上記の送信の少なくとも１つについて逆の優先順位付けを使用し得る。

デバイスは、制御シグナリングが適応再送信のために進行中のＨＡＲＱプロセスについて受信され得るサブフレームに関して、ＲＦ発見のためにスケジューリングされたサブフレームにおいてＰＤＣＣＨ受信を優先付けることができ、または、デバイスは、ＲＦ発見のためにスケジューリングされたサブフレームにおいてＲＡ応答ウィンドウ内のＲＡ−ＲＮＴＩについてＰＤＣＣＨデコーディングを優先付けることができる。

デバイスは、ＲＦ発見のためにスケジューリングされたサブフレームにおいて物理ＨＡＲＱインジケータチャネル（physical HARQ indicator channel：ＰＨＩＣＨ）受信を優先付けることができる。

デバイスは、ＲＦ発見のためにスケジューリングされたサブフレームにおいてページング、マルチキャスト制御チャネル（multicast control channel：ＭＣＣＨ）またはシステム情報（ＳＩ）受信を優先付けることができる。

デバイスは、ＲＦ発見のためにスケジューリングされたサブフレームにおいて半永続的スケジューリング（semi-persistent scheduling：ＳＰＳ）グラントについてのＰＤＳＣＨ受信を優先付けることができる。

デバイスは、ＲＦ発見のためにスケジューリングされたサブフレームにおいてマルチキャストトラフィックチャネル（multicast traffic channel：ＭＴＣＨ）受信を優先付けることができる。

デバイスは、タイマが動作している場合（例えば、Ｔ３１０、Ｔ３１１またはＴ３２０）ＲＦ発見手順を休止することができる。

関係するデバイスは、セル固有のシグナリングを使用してＲＦ発見送信を決定することができる（即ち、デバイスは、専用シグナリングを使用してスケジューリング情報を受信することがない、例えば、ネットワークが認識することがない）。

関係するデバイスは、監視デバイスであり得る（例えば、ネットワークが認識することがない）。結果として、そのＣ−ＲＮＴＩ向けの専用シグナリングを使用してＲＦ発見用の制御情報を受信する発見可能デバイス（例えばネットワークが認識する）は、代わりに、上記の送信の少なくとも１つについて逆の優先順位付けを使用し得る。

ＤＬ ＨＡＲＱフィードバックと発見サブフレームの間の競合の場合、デバイスは次のフィードバック機会においてＨＡＲＱ肯定応答バンドリングまたは多重化を使用することができる。これは、ネットワークが、対応するＰＤＣＣＨにおいてダウンリンク割り当てインデックス（downlink assignment index：ＤＡＩ）を増大することを必要とし得る。

ＨＡＲＱフィードバックが発見サブフレームと衝突する場合、ネットワークは、次のフィードバック機会においてＤＡＩを増大することができる。デバイスがこの発見サブフレームを使用しない場合、デバイスは、それにもかかわらず、この肯定応答を再送することができる。

ＵＬ ＨＡＲＱフィードバックの場合、ＵＬ ＨＡＲＱフィードバックと発見サブフレームの間に衝突がある場合、デバイスは、次のフィードバック機会に追加のＰＨＩＣＨ（ＤＬサブフレーム）を受信することができる。

ネットワークは、発見サブフレームとネットワーク通信の間のスケジューリング衝突を取り扱うために利用可能な様々なオプションを有することができる。

図３は、ＵＬ ＨＡＲＱに対する発見手順の影響の例を示す。図３のＵＬ ＨＡＲＱ手順３０５を行うことによって、発見リソースは、サブフレームｎ＋８における周波数分割複信（ＦＤＤ）ＵＬバンド上の発見可能デバイス（ＷＴＲＵ１）に割り振られ得る。この場合、発見プロセスは、発見可能デバイスからの最終的ＰＵＳＣＨ再送信と干渉し得る。

図３を参照すると、ＷＴＲＵ１は、ｅＮＢにより正しく受信されないＰＵＳＣＨチャネル上のデータを送信することができる。サブフレームｎ＋４で、ｅＮＢは、制御チャネル上で否定応答（ＮＡＣＫ）を送信することにより、ＰＵＳＣＨが正しく受信されなかったことをＷＴＲＵ１に示すことができる。ＷＴＲＵ１はＬＴＥ規格に従ってサブフレームｎ＋８でデータを再送信し得るので、発見リソース割り振りとの衝突が発生し得る。

図３の１つの発見影響方式３１０では、ネットワークは、（必要に応じてＷＴＲＵ１がメッセージを再送信することができないように）ＷＴＲＵ１へのＰＵＳＣＨ割り振りをサブフレームｎに制限することができる。Ｔｘ／Ｒｘ切り替えギャップは、サブフレームｎの第１の部分の再送信、およびサブフレームｎ＋８の第２の部分の発見プロセスを可能にするため、発見リソースに追加され得る。サブフレームｎ＋８が発見のためにスケジューリングされたことをｅＮＢが認識している場合、ｅＮＢは、ＷＴＲＵ１のスケジューリングを制限することができる（即ち、このサブフレームにおいてＷＴＲＵ１に割り振られ得るグラントが存在することがない）。図３の発見影響方式３１５では、発見リソースは、サブフレームｎ＋４におけるＦＤＤ ＵＬ上の発見可能ＷＴＲＵに割り振られることができ、ＤＬトラフィックは、サブフレームｎでこのＷＴＲＵに割り振られることができる。発見可能ＷＴＲＵは、サブフレームｎ＋４においてＡＣＫを送信することができない。（フェイクの）肯定応答（ＡＣＫ）は、サブフレームｎ＋４におけるＰＨＩＣＨを介してフィードバックされて、ＬＴＥ規格により可能にされるように、サブフレームｎ＋１２におけるＰＤＣＣＨを介してサブフレームｎ＋１６における再送信を要求することができる。

図３の発見影響方式３１５では、ｅＮＢは、サブフレーム（ｎ＋４）におけるデータについて、それが正しく受信されていなくても肯定応答し得る。ＷＴＲＵ１は、発見のためにサブフレームｎ＋８を使用することができる。サブフレームｎ＋１２で、ｅＮＢは、サブフレームｎ＋１６についてＷＴＲＵ１に新しいグラントを示し、また、それは新しい送信に対して割り振られず代わりにデータの再送信に割り振られることを示すことができる。ＷＴＲＵ１はサブフレームｎ＋１６上でデータを再送信することができ、発見との衝突がない。

ネットワークは、必要に応じてＷＴＲＵがメッセージを再送信することができないように、任意のＰＵＳＣＨ割り振りをサブフレームｎにおいてこのＷＴＲＵに制限することができる。ネットワークは、組み合わされた肯定応答および発見信号を可能にすることができる（即ち、ｅＮＢが適切に発見信号をデコードすることを必要とし、これは、送信電力などの観点から追加の要件をもたらし得る）。

報告送信スケジュールは、発見サブフレームと競合し得る。ネットワークは、組み合わされた報告および発見信号を可能にすることができる（即ち、ｅＮＢが適切に発見信号をデコードすることを必要とし、これは、送信電力などの観点から追加の要件をもたらし得る）。

デバイスは、ｅＮＢに送られる必要がある利用可能なアップリンクデータが存在するとき、ＰｒｏＳｅ発見または通信のために予約されたサブフレーム上のスケジューリング要求（ＳＲ）を送るようにトリガーされ得る。デバイスは、ＳＲを送るために利用不可能となるＰｒｏＳｅリソースとして構成された送信時間間隔（ＴＴＩ）を考慮することができる。複数のＰｒｏＳｅリソースが連続して構成される場合、予約されたＰｒｏＳｅサブフレームのブロック内の第１のサブフレームでＳＲ禁止タイマが開始され得る。サブフレームは、ＳＲがＰｒｏＳｅ発見または通信に利用不可能なようにトリガーされるときに考慮されることができ、ＳＲが送信され得る。デバイスは、ｅＮＢに送られる必要がある利用可能なアップリンクデータが存在するとき、ＰｒｏＳｅ発見または通信のために予約されたサブフレーム上のアップリンクＲＡＣＨを送るようにトリガーされ得る。デバイスは、ＲＡＣＨを送るために利用不可能となるＰｒｏＳｅリソースとして構成されたＴＴＩを考慮することができ、または、ＲＡＣＨがＰｒｏＳｅ発見または通信に利用不可能なようにトリガーされるときにサブフレームを考慮し、ＲＡＣＨを送信することができる。

ネットワークは、ｅＮＢスケジューラで再送信を延期することができる（ＤＬ ＨＡＲＱは非同期プロセスである）。

発見リソースは、ＦＤＤ ＤＬバンド（サブフレームｎ＋４）に割り振られることができ、デバイスは、サブフレームｎにおけるＵＬトラフィックに割り振られることができる。発見リソースとＰＨＩＣＨ受信の間の競合が存在し得る。

ネットワークは、ＰＨＩＣＨをまずデコードするために発見サブフレームの終わりに発見信号を割り振ることができ、ネットワークは、発見信号受信または送信に切り替わることができる（タイミング問題は、注意深く評価され、かつＲｘ／Ｔｘ切り替えギャップである必要がある）。ネットワークは、発見ゾーンがサブフレームｎに割り振られ得る場合、サブフレームｎ−４にＰＵＳＣＨ割り振りを制限することができる。

ネットワークが時分割複信（ＴＤＤ）モードである場合、同じ制限が適用し得るが、送信とその肯定応答との間の時間関係は、ｋ個のサブフレームに等しいことが可能であり、ここで、ｋ≧４でありｋはＴＤＤ ＤＬ−ＵＬ構成に依存する。また、ＤＬサブフレームとＵＬサブフレームのあり得る非対称のため、ＵＬサブフレームは、２以上のＤＬ送信の肯定応答を含み得る。その場合、このサブフレームは発見監視に割り振られ得る場合、スケジューリング制限がいくつかのＤＬサブフレームに伝播され得る。

既存のＬＴＥ手順に対するあり得る追加が本明細書で説明される。インフラストラクチャモードの場合、アイドルモードデバイスがＤＩＳＣＨを監視することができる。再選択されたセルが（例えば、システム情報の取得中に発見エリアアイデンティティから検出されるように）異なる発見エリアに属する場合、異なるセルのセル再選択は、発見に関係付けられた構成（例えば、専用シグナリングを使用して受信され、かつ／またはシステム情報ブロードキャストによって受信された任意の構成）の少なくとも一部を無効にし得る。

インフラストラクチャモードの場合、Ｄ２Ｄリソース用の割り当てのためのＰＤＣＣＨ受信は、ＤＲＸタイマに影響を及ぼすことがない（即ち、Ｄ２Ｄ発見のためのスケジューリングは、ＰＤＣＣＨブラインドデコーディングの観点から分離され得る）。ＰＤＣＣＨデコーディングは、発見固有スケジューリング（例えば、ＤＩ−ＲＮＴＩ）のためのサブフレームをさらにデコードすることができる。

さらに、ＴＡＴ（Time alignment timer）満了は、特定のタイプの発見信号フォーマット（例えば、セルのアップリンクタイミングへの何らかの形態の同期を必要とするもの）を無効にすることができる。ＴＡＴ満了はさらに、ＲＦ発見のための発見信号のいかなる送信も排除することができ、さらに、ＲＦ発見構成の少なくとも一部（例えば、（もしあれば）専用部分、永続的リソース）を無効にすることができる。

無線リンク監視（ＲＬＭ）の場合、デバイスは、タイマＴ３１０が動作しているとき、ＲＦ発見のための発見信号のいかなる送信も行わないことができる。ＤＬ無線リンク障害（ＲＬＦ）および接続再確立の場合、デバイスは、タイマＴ３１１（および／またはタイマＴ３０１）が動作中であり得るとき、ＲＦ発見のための発見信号のいかなる送信も行わないことができる。ＵＬ ＲＬＦの場合、デバイスは、それがプリアンブル送信の最大数に達したとき、ＲＦ発見のための発見信号のいかなる送信も行わないことができる。

モビリティの場合、デバイスは、タイマＴ３０４が動作しているとき（進行中のハンドオーバ（ＨＯ））、ＲＦ発見のための発見信号のいかなる送信も行わないことができる。電力設定の場合、所与のサブフレームにおいて、デバイスが、ＰＵＳＣＨ、ＰＵＣＣＨおよび／またはＰＲＡＣＨのいずれかのアップリンク送信を有し、デバイスが、その最大出力電力に達する前にＲＦ発見信号の送信のための電力が残されていない場合、デバイスは、ＲＦ発見のための発見信号のいかなる送信も行わないことができる。

測定ギャップは、要件が満たされている限りまたはさらに専用シグナリングがない限り、デバイス実装次第であり得る。デバイスは非アクティブ化されたセカンダリセル（Ｓセル（SCell））上でＲＦ発見を行わないことができる。Ｓセル非アクティブ化は、関係するＳセル上の進行中のＲＦ発見を非アクティブ化および／または終了することができる。

発見情報がデバイスによって送信および／または受信され得るトランスポートチャネルのための構造が本明細書で説明される。

ＤＩＳＣＨの構成のために想定される代替形態は、（例えば、ブロードキャスト制御チャネル（ＢＣＣＨ）を介する、アイドルモードデバイス用、かつ／または接続モードデバイス用の）ブロードキャストされたＤＩＳＣＨ制御情報を含み得るがこれに限定されない。デバイスは、ブロードキャストされたシステム情報において１または複数のＤＩＳＣＨのための構成を受信することができる。デバイスはまた、ＰＤＩＳＣＨ構成を受信することもできる。（例えば、シグナリング無線ベアラ１（ＳＲＢ１）を介する、接続モードデバイス用の）ＤＩＳＣＨ制御情報を有する専用シグナリングに関して、デバイスは、専用ＲＲＣシグナリングによって１または複数のＤＩＳＣＨのための構成を受信することができる。ＷＴＲＵはまた、ＰＤＩＳＣＨ構成を受信することもできる。

ＤＩＳＣＨの取得のために想定される代替形態は、ＰＤＩＳＣＨを介するＤＩＳＣＨ、およびＰＤＳＣＨを介するＤＩＳＣＨを含み得るがこれらに限定されない。ＤＩＳＣＨは、特にＰＤＩＳＣＨがデバイス間で直接送信され得るとき、ＰＤＩＳＣＨの情報転送サービスを使用することができる。例えば、ＤＩＳＣＨは、セルのアップリンクリソースの一部を使用してＰＵＳＣＨと同様にスケジューリングされ得る。ＤＩＳＣＨは、ネットワークと１または複数のデバイスの間でレガシＬＴＥ物理チャネルの情報転送サービスを使用することができる。この場合、関係するチャネルは、共有チャネル、ブロードキャスト／マルチキャストチャネル、または専用チャネルのいずれかであり得る。例えば、デバイスは、セル内の複数のデバイスにより共有されたＲＮＴＩによってスケジューリングされたセルのＰＤＳＣＨ上のＤＩＳＣＨを受信することができる。

ＤＩＳＣＨは、発見情報を含むチャネルであり得る（例えば、そのようなチャネル上の送信は、発見信号を含むことができ、かつ／またはペイロードを含むことができる）。そのようなペイロードは、１または複数のメッセージからなることができる。そのようなメッセージは、１または複数の発見アイデンティティを含むことができる。デバイスは、ＤＩＳＣＨ上で送信を監視し受信することができるとともに、ＤＩＳＣＨ上で送信をすることができる。

デバイスは、ＤＩＳＣＨ送信上でセキュリティ手順（例えば、暗号化／復号化および／または完全性保護）を行うことができる。インフラストラクチャモードにおいて、デバイスは、ネットワークから必要なセキュリティコンテキストを受信することができる。インフラストラクチャなしモードにおいて、デバイスは、必要なセキュリティコンテキストによって事前構成され得る。ブロードキャストチャネル上で受信されたＤＩＳＣＨ構成について、セキュリティは適用されることがない（あるいはヌル暗号化アルゴリズムが適用され得る）。

発見サービスに関心を有するデバイスは、ブロードキャストされたシステム情報およびＤＩＳＣＨパラメータを取得することができる。デバイスは、本明細書で説明された手順に従ってＤＩＳＣＨをさらに取得することができる。あるいはまたは加えて、デバイスは、ネットワークに接続するとき、そのようなサービスに関する能力を報告することができ、かつ／または、ＤＩＳＣＨパラメータを有する専用シグナリングを使用して構成されることができる。デバイスは、本明細書で説明される手順に従ってＤＩＳＣＨを取得することができる。

デバイスは、高位層（例えばＲＲＣ層）によって１または複数のＤＩＳＣＨチャネルを用いて構成され得る。デバイスは、ブロードキャストされたシステム情報においてそのような構成を受信することができる。例えば、デバイスは、セルのＢＣＣＨ上でＤＩＳＣＨ制御情報を受信することができる。特に、アイドル中のデバイスは、ＤＩＳＣＨの取得のためにＢＣＣＨ上で受信された制御情報を利用することができる。この情報は、修正期間の対象となり得る（例えば、デバイスは、所与の修正期間に受信された情報が期間全体を通して有効であること、および情報が修正期間境界のみに更新され得ることを、想定することができる）。デバイスは、デバイスがＤＩＳＣＨ制御情報を再取得することができるように、ＤＩＳＣＨ制御情報が現在の修正期間の終わりに修正され得るかどうかを示すシグナリングを受信することができる。この情報は、セルおよび／または関係するセルのエリアに適用可能なＤＩＳＣＨの取得に関わり得る。この情報は、１または複数のＤＩＳＣＨ構成メッセージを含むことができるシステム情報ブロック（ＳＩＢ）によって搬送され得る。この情報は、発見エリアアイデンティティ（例えば、ＤＩＳＣＨエリア構成（DISCHAreaConfiguration）に含まれるＤＩＳＣＨエリアＩＤ（DISCH-areaID）、各ＤＩＳＣＨに１つ）を含むことができる。この情報はまた、（例えば、ＤＩＳＣＨスケジューリング情報（DISCHSchedulinglnformation）情報要素（ＩＥ）を介して）少なくとも１つのＤＩＳＣＨに関するスケジューリング情報を含むことができる。そのようなスケジューリング情報は、ＤＬ ＤＩＳＣＨ（即ち、ネットワークにより行われたＤＩＳＣＨ送信用）に対応し得る。あるいは、そのようなスケジューリング情報は、ＰＤＩＳＣＨのためのスケジューリング（即ち、デバイスによるＤＩＳＣＨ送信のためのリソースのスケジューリング用）をさらに含むことができる。

そのようなスケジューリング情報は半静的スケジューリング情報を示すことができる。例えば、情報は、時間領域スケジューリングおよび／または物理パラメータなどのパラメータ、例えば、サブフレーム割り振り（即ち、無線フレーム内のそのサブフレーム）、（例えば、システムフレーム番号（ＳＦＮ）ｍｏｄ期間＝オフセットに対応する）無線フレームの期間およびオフセット、（関係するサブフレームに関するＤＩＳＣＨ送信に適用される）シグナリングＭＣＳ、サブフレームにおける非ＤＩＳＣＨ領域の表示（例えば、ＤＩＳＣＨの開始前のシンボルの個数）、並びに／またはＤＩＳＣＨ送信のために使用され得る物理リソースブロック（ＰＲＢ）のセットの少なくとも１つを含むことができる。

あるいはまたは加えて、スケジューリング情報は、ＤＩＳＣＨ送信の動的スケジューリングのためのパラメータを示すことができる。例えば、情報は、ＤＩＳＣＨ（ＤＩ−ＲＮＴＩ）のスケジューリングに適用可能なＲＮＴＩを含むことができる。異なるＲＮＴＩがセル内で利用可能な各ＤＩＳＣＨに割り当てられ得る。デバイスは、シグナリングされたＲＮＴＩを使用して、セルの共通検索空間においてＤＣＩのためのＰＤＣＣＨ上でスケジューリング情報をデコードすることができる。ＤＩＳＣＨ送信は、周波数領域および時間領域でスケジューリングされ得る。

例えば、ＤＩＳＣＨメッセージは、ＤＩＳＣＨメッセージタイプ（例えば、ＤＩＳＣＨエリア構成およびＤＩＳＣＨスケジューリング情報など）のシーケンスからなることができる。各メッセージは、（例えば、ＰＤＳＣＨ上の）ダウンリンクＤＩＳＣＨ、または（例えば、デバイス送信用の）アップリンクＰＤＩＳＣＨに適用可能であり得る。

接続モードのデバイスの場合、あるいはまたは加えて、デバイスは、専用シグナリングを使用してそのような構成を（例えば、ＲＲＣ接続再構成手順の一部として、または発見要求に対するネットワークからの応答の一部として）受信することができる。デバイスは、専用ＲＲＣシグナリングによってそのような構成を受信することができる。例えば、接続モードのデバイスは、ＳＲＢ１上のＤＩＳＣＨ制御情報を受信することができる。デバイスは、スケジューリング情報を含めて、システムブロードキャスト上で制御情報が受信され得る場合について本明細書で説明されている情報と同様に、情報を受信することができる。この場合、デバイスは、発見機能性を不能にする再構成、ハンドオーバコマンドの受信、またはアイドルモードへの移行の際、（少なくとも専用シグナリングにより受信された構成について）構成を無効にすることができる。ハンドオーバコマンドに関して、（例えば、特定のＰＬＭＮについて、関係するセルに適用可能なパラメータＤＩＳＣＨエリアＩＤによって決定されるように、）ターゲットセルがソースセルと同じエリアにない場合、デバイスは構成を無効にすることができる。

受信された構成は、デバイスが滞在しているセルについて（またはデバイスが接続されているセルについて）有効であり得る。この場合、デバイスは、それが滞在するセルを変更するセル再選択の際、構成を無効にすることができる。あるいはまたは加えて、（例えば、特定のＰＬＭＮについて、関係するセルに適用可能なパラメータＤＩＳＣＨエリアＩＤによって決定されるように、）同じ発見エリアアイデンティティを有する任意のセルにおいて構成が有効であり得る。

ＤＩＳＣＨスケジューリングのための方法が本明細書で開示される。ＤＩＳＣＨが、２つのデバイス間の物理チャネル上（例えばＰＤＩＳＣＨ上）で送信され得る。ＤＩＳＣＨ上の送信は、（デバイスにより送信される場合）それ自体が発見信号であり得る。通常、インフラストラクチャモードでは、ネットワークは、ＤＩＳＣＨのためのリソースを割り当てることができ、また場合によっては、動的にスケジューリングすることができる。あるいは、特にインフラストラクチャなしモードでは、デバイスは、タイミング面でＤＩＳＣＨ送信をスケジューリングすることができる。ＤＩＳＣＨは、（例えば、セルのＰＤＳＣＨ上で）送信され得る。

所与のエリア（例えば、セルのカバレッジエリア）について、少なくとも１つのＤＩＳＣＨが、１または複数のＰＤＳＣＨを使用してネットワークによって送信され得る。例えば、異なるＤＩＳＣＨが、サポートされるサービスのタイプに応じて使用され得る。所与のセルについて、あるＤＩＳＣＨは商業広告のために、別のＤＩＳＣＨはソーシャルネットワーキングのために、別のＤＩＳＣＨが公共安全サービスのためになどとして、発見サービスを提供することができる。

インフラストラクチャモードにおいて、デバイスは、（例えば、ＲＲＣシグナリングとして）ＳＲＢ１上のアップリンクでＤＩＳＣＨメッセージを送信することができる。ＤＩＳＣＨは、ネットワークによって送信され得る。

ＤＩＳＣＨは、静的または動的にスケジューリングされ得る。静的にスケジューリングされる場合、ＤＩＳＣＨは、周期的に送信される新しいブロードキャストチャネルとみなされ得る。動的にスケジューリングされる場合、発見固有ＲＮＴＩ（ＤＩ−ＲＮＴＩ）がＰＤＣＣＨ上で使用され得る（動的または半永続的；ＳＰＳ−Ｄ−ＲＮＴＩが半永続的な場合に使用され得る）。Ｄ−ＲＮＴＩは、高レベルメッセージによって提供され得る。

ＤＩＳＣＨを静的にスケジューリングするために、デバイスは、新しいシステム情報ブロック（ＳＩＢｘｘ、例えば、ＳＩＢ１４）を分析することにより、周期性およびサブフレームオフセットを得ることができる。デバイスは、ＰＤＣＣＨ上で送られる発見固有ＲＮＴＩ（ＤＩ−ＲＮＴＩ）を介してＤＩＳＣＨコンテンツ変更を通知され得る。ＤＩ−ＲＮＴＩは、静的パラメータとすることができ、または高レベルメッセージによって提供されることができる。ＤＣＩフォーマット１Ｃは、この新しい通知を含むように修正され得る。この変更通知は、修正期間ごとに構成可能回数だけ提供され得る。デバイスは、（変更が適用する）次の修正期間でＤＩＳＣＨをデコードし、更新された発見情報を得ることができる。

複数のＤＩＳＣＨが使用される場合、デバイスは、ＩＥマルチキャストブロードキャスト単一周波数ネットワーク（multicast broadcast single frequency network：ＭＢＳＦＮ）エリア情報リスト（ArealnfoList）と同様のメッセージでフィールドを得ることができる。このフィールドは、関連付けられたＤＩＳＣＨに対する変更を示すビット位置を決定することができる。ＤＩ−ＲＮＴＩ ＰＤＣＣＨが受信されると、デバイスは、修正されたＤＣＩフォーマット１Ｃに含まれるビットマップを分析することができる。ＤＣＩフォーマット１Ｃにおいてマルチメディアブロードキャストマルチキャストサービス（multimedia broadcast multicast service：ＭＢＭＳ）と発見との両方を取り扱うために、ビット９が予約され得る（ＭＢＭＳに対して０、発見に対して１）。デバイスは、それが現在監視しているサービスアイデンティティに基づいて、更新されたＤＩＳＣＨをデコードするかデコードしないかを決定することができる。

発見に関与するプロセスネットワークは、特定の地理的エリア（発見エリア）内に現在あることが知られ、かつ発見サービスを有効にしたアイドルモードまたは接続モードのデバイスのリストを保持することができる。デバイスごとに、ネットワークは、デバイスごとの加入されたサービスおよびプライベートサービスのリスト、デバイスの状態（アイドルまたは接続モード）、接続モードの場合のデバイスのサービングセルおよびＣ−ＲＮＴＩ、並びに、少なくとも接続モードの場合のセルレベルまたはアイドルモードの場合のＴＡレベルで知られたデバイスの位置を保持することができる。発見サーバは、ＭＭＥまたは位置サーバ（進化型サービングモバイル位置センタ（evolved serving mobile location center：Ｅ−ＳＭＬＣ）など）によってデバイスの状態または位置の変更をシグナリングされ得る。

ネットワークは、発見ペア内のデバイスが互いのＲＦ近傍であり得ると検出されたとき、ＲＦ発見手順を開始することができる。発見ペアは、第１のデバイスが第２のデバイスの可能にされたリスト内にあり、第２のデバイスが第１のデバイスの監視されたリスト内にある、第１のデバイスと第２のデバイスによって定義され得る。該当する場合、追加の条件が、デバイスの少なくとも１つの発見属性に基づいて定義され得る。

２つのデバイスが、それらのサービングセル（知られている場合）、それらの地理的位置、またはそれらのＴＡに基づいて、互いのＲＦ近傍にあると決定され得る。基準は、デバイスのＲＲＣ状態に応じて変わり得る。２つのデバイスが発見ペアを構成する場合、発見ペアは互いのＲＦ近傍にある。

ネットワークは、発見ペアが互いのＲＦ近傍となるときに開始されたタイマの満了のとき、ＲＦ発見手順を開始することができる。タイマの値は、デバイスのＲＲＣ状態に応じて変わり得る。例えば、デバイスのうちの１つがアイドルモードである場合、より大きな値が使用され得る。

ＲＦ発見手順は、互いのＲＦ近傍にある少なくとも１つの発見ペアの一部であるデバイスが送信デバイスもしくは受信デバイス（または両方）であると、発見サーバが決定することを含むことができる。送信または受信デバイスの役割は、このデバイスが高位層で近傍情報を要求したかどうかに必ずしも関連されることがない。ネットワークは、（例えば、互いのＲＦ近傍にある複数の発見ペアの一部であって現在アイドルモードにないデバイスに、送信デバイスの役割を優先的に割り当てることによって）、送信および受信デバイスの割り当てを最適化して、送信および／またはバッテリ消費における発見リソースの使用量を最小限にすることができる。発見サーバは、送信デバイスのサービングセルを制御しているｅＮＢに、送信のためにこのデバイスに対する発見リソースを構成するように要求することができる。

送信デバイスが当初アイドルモードである場合、それはまず、ページングを使用して接続モードにされ得る。発見リソースは、発見信号の特性（例えば、発見信号の性質に応じて、スクランブリングアイデンティティ、ＣＲＣマスク、およびＺａｄｏｆｆ−Ｃｈｕベースのシーケンスまたは循環シフトインデックスなど）と、発見信号がそれで送信され得る周期的に発生し得るサブフレームのセットとからなることができる。ｅＮＢは、Ｃ−ＲＮＴＩまたは発見固有ＲＮＴＩ（Ｄ−ＲＮＴＩ）によってスクランブリングされたＣＲＣを有するＤＣＩなどの物理層シグナリングを使用して、（サブフレームの構成されたセット内の）発見信号の送信をスケジューリングすることができる。

発見サーバは、受信デバイスのサービングセルを制御しているｅＮＢに、受信のためにこのデバイスに対する発見リソースを構成するように要求することができる。受信デバイスがアイドルモードである場合、それはまず、ページングを使用して接続モードにされ得る。あるいは、発見リソースは、システム情報によってアイドルモードのデバイスに提供され得る。発見リソースは、発見信号の少なくとも１つの特性と、発見信号がそれで受信され得る周期的に発生し得るサブフレームのセットとからなることができる。発見リソースは、受信デバイスの測定構成の一部として構成され得る。ｅＮＢは、Ｃ−ＲＮＴＩまたは発見固有ＲＮＴＩ（Ｄ−ＲＮＴＩ）によってスクランブリングされたＣＲＣを有するＤＣＩなどの物理層シグナリングを使用して、（サブフレームの構成されたセット内の）発見信号の受信をスケジューリングすることができる。

ネットワークは、送信デバイスと受信デバイスに対して構成された発見リソースの間に十分な重なりが存在することを確実にすることができる。デバイスが同じサービングセルに接続されていない場合、これはｅＮＢ間の調整を必要とし得る。

ｅＮＢは、ＲＲＣシグナリングから受信デバイスからの測定結果（例えば、測定報告）を受信し、情報を発見サーバに提供することができる。あるいは、発見サーバは、ＮＡＳシグナリングから受信デバイスからの測定結果を受信してもよい。発見サーバは、受信された測定に基づいて、２つのデバイスがＲＦ近傍にあるまたはＲＦ近傍にない（もしくはもはやＲＦ近傍にない）と決定することができる。発見サーバは、（肯定であろうと否定であろうと）ＲＦ近傍結果を、ＮＡＳシグナリングを使用してデバイスの少なくとも１つに提供することができる。結果は、距離の推定および経路損失などの測定を含むことができる。ＮＡＳシグナリングは、デバイス内のアプリケーション（即ち、要求）によって開始され得る。ＮＡＳシグナリングは、発見ペア内のデバイスが互いのＲＦ近傍になると検出されたとき、または発見ペア内のデバイスがもはや互いのＲＦ近傍にないと検出されたときに、（例えば周期ベースで）ネットワーク（発見サーバ）によって開始され得る。発見サーバはまた、ＲＦ近傍結果の提供に使用されるものと類似したＮＡＳ手順を使用して（または同じＮＡＳシグナリングを使用して）、近傍がＲＦ近傍に制限されない近傍結果も提供することができる。

デバイスは、（アプリケーションまたはエンドユーザから要求があると、）ＮＡＳシグナリングを使用することで、発見サービスの使用を有効または不能にすることができる。デバイスは、この目的のためにＲＲＣ接続要求を開始することができる。デバイスは、この情報を、ＴＡ更新などのＮＡＳメッセージ（例えばモビリティ管理メッセージ）の一部として提供することもできる。デバイスは、少なくとも１つの発見属性とともに、監視されたリストおよび／または可能にされたリストをネットワークに提供することができる。デバイスは少なくとも１つのデバイスに関する即座の発見情報を要求することができる。

デバイスは、少なくとも１つのデバイスに関する発見情報の変更の通知を要求することができる。例えば、デバイスは、別のデバイスがもはや近接していない、または近傍となるときに、通知を受信することができる。

ＲＦ発見手順中、送信デバイスは、構成された発見リソース、送信電力およびタイミングに従って、発見信号を送信することができる。発見信号は、有効なＲＮＴＩによってスクランブリングされたＣＲＣを有するＤＣＩが同じまたは先行のサブフレームで受信された場合に送信され得る。有効なＲＮＴＩは、デバイスのセルＲＮＴＩ（Ｃ−ＲＮＴＩ）またはＤ−ＲＮＴＩであり得る。

ＲＦ発見手順中、受信デバイスは、有効なＲＮＴＩによってスクランブリングされたＣＲＣを有するＤＣＩが同じまたは先行のサブフレームで受信された場合、構成された発見リソースでの発見信号の検出を試みることができる。有効なＲＮＴＩは、デバイスのセルＲＮＴＩ（Ｃ−ＲＮＴＩ）またはＤ−ＲＮＴＩであり得る。受信デバイスは、この特性の値のセットのうちの発見信号の特性の値のブラインド検出を試みることができ、値のセットは、予め定義されるまたは高位層によって提供されることができる。例えば、特性は、あり得るベースシーケンスのセットのうちの特定のＺａｄｏｆｆ−Ｃｈｕベースシーケンスであり得る。受信デバイスは、検出された発見信号ごとに、その信号強度、信号品質、およびタイミングを推定することができる。

受信デバイスは、物理層シグナリング（例えば、ＰＵＣＣＨ上の検出のバイナリ表示）、ＭＡＣまたはＲＲＣ層シグナリング（例えば、測定報告）を使用して以下の測定結果の少なくとも１つをｅＮＢに報告することができる。デバイスがアイドルモードで受信し少なくとも１つの発見信号が検出されると、デバイスは、測定結果を提供するために、ＲＲＣ接続を開始することができる。あるいは、受信デバイスは、ＮＡＳシグナリングを使用して測定結果を発見サーバに報告することができる。測定結果は、場合によってはあり得る特性値のセットに関する、少なくとも１つの発見信号の検出の肯定または否定表示、または発見信号が検出される特性値のリストを含むことができる。測定結果はまた、信号強度および／または品質情報、並びにタイミング受信情報を含むことができる。

上記に説明された手順は、サービス発見および近傍検出のための分散されたシステムを有効にするために使用され得る。ネットワークインフラストラクチャからのフルサポートを有する分散サービス発見が本明細書で説明される。

ネットワーク（例えば、ｅＮＢなどのネットワーク構成要素）は、ＤＩＳＣＨのための構成をＢＣＣＨのシステム情報でブロードキャストすることができる。例えば、ＳＩＢは、ＤＩＳＣＨ上の送信の動的スケジューリングのためにＲＮＴＩ（例えば、ＤＩ−ＲＮＴＩ）を構成するＤＩＳＣＨスケジューリング情報ＩＥを含むことができる。あるいは、ＳＩＢは、ＰＲＢリソースの半静的セットおよびＭＣＳを構成することができる。加えて、ＳＩＢは、ＳＦＮｍｏｄ期間＝オフセットに対応する無線フレーム内の期間、オフセットおよび、サブフレーム割り振りを含む、ＤＩＳＣＨ上の送信のためのスケジューリング機会をデバイスが決定することを可能にするパラメータを含むことができる。例えば、ＤＩＳＣＨがＢＣＣＨ上でネットワークによってブロードキャストされ、デバイス間のＲＦ発見送信のためのＰＤＩＳＣＨがさらに存在するとき、１つの追加の物理発見ＲＮＴＩ（ＰＤ−ＲＮＴＩ）がＰＤＩＳＣＨリソースのスケジューリングのために構成され得る。ネットワークは、（例えば、ＰＤＣＣＨ上のＤＩ−ＲＮＴＩによって）ＢＣＣＨ上のＤＩＳＣＨ送信を動的にスケジューリングすることができる。ネットワークは、（例えば、ＰＤＣＣＨ上のＰＤ−ＲＮＴＩによって）ＰＤＩＳＣＨ上のＤＩＳＣＨ送信を動的にスケジューリングすることができる。

ネットワークは、１または複数の発見アイデンティティを含めてＢＣＣＨ上のＤＩＳＣＨ送信で発見情報を送信することができる。例えば、各アイデンティティは、ＲＦ近傍検出のための物理リソース（時間／周波数）に対する構成（例えば、インデックス）に関連付けられ得る。別の例では、各アイデンティティは、ＲＦ近傍検出のためのウィンドウに関連付けられ得る。さらに別の例では、そのような発見エンティティは、発見要求でデバイスから受信された発見情報から導出され得る。ネットワークは、所与の発見アイデンティティについてＲＦ発見を行うためのリソースを求める要求を１または複数のデバイスから受信し得る。ネットワークは、所与の発見アイデンティティについて１または複数のデバイスに対してＲＦ発見のためのリソースを割り当ておよび／またはスケジューリングすることができる。ネットワークは、ＲＦ発見アイデンティティを所与のサービス発見アイデンティティに割り当てることができる。ネットワークは、（例えば、ＰＤＩＳＣＨ上の）所与のリソースで発見信号を送信するために、（例えば、ＰＤＣＣＨ上またはＤＩＳＣＨ上のＰＤ−ＲＮＴＩによって）デバイスをスケジューリングすることができる。ネットワークは、（例えば、ＰＤＩＳＣＨ上の）所与のリソースで発見信号をリッスンするために、（例えば、ＰＤＣＣＨ上またはＤＩＳＣＨ上のＰＤ−ＲＮＴＩによって）デバイスをスケジューリングすることができる。

発見可能デバイスは、ネットワークにより送信された信号を使用してＤＩＳＣＨ構成を取得することができる。デバイスは、それが発見可能であり得ることを決定することができる。例えば、アプリケーションは、適切なサービス発見アイデンティティを生成および／または決定し、ＡＰＩを介して、特定のサービス発見アイデンティティが他のデバイスに利用可能とされるように要求することができる。

デバイスはサービス発見要求手順を開始することができ、それにより、デバイスは少なくとも１つの発見アイデンティティをネットワークに（例えばネットワークに）送信することができる。デバイスは、シグナリング無線ベアラ（ＳＲＢ）を介してＲＲＣプロトコルデータユニット（ＰＤＵ）でＮＡＳメッセージを送信することができる。

デバイスは、ネットワークから応答（例えば、受諾、拒否、バックオフによる拒否）を受信することができる。例えば、受諾応答は、サービス発見アイデンティティに関連付けられたＲＦ発見信号を送信するために必要な１または複数のパラメータ（例えば、タイミング、ウィンドウ、ＲＦ発見アイデンティティ、および／または物理リソース）を含むことができる。

デバイスは、受諾応答で、サービス発見アイデンティティに関連付けられたＲＦ発見識別子を受信することができる。他の方法では、デバイスは、そのような情報を検出するためにＤＩＳＣＨを監視することができる。

デバイスは、受諾応答で発見信号に関するスケジューリング情報を受信することができる。他の方法では、デバイスは、関係する発見アイデンティティについてそのような情報を検出するために、ＰＤＣＣＨ上またはＤＩＳＣＨ上のＰＤ−ＲＮＴＩを監視することができる。

デバイスは、サービス発見アイデンティティのための要求に関連付けられたリソースで、そのようなリソースが利用可能なサブフレームにおいて、ＲＦ発見信号を送信することができる。

デバイスは、関連付けられたＲＦ発見アイデンティティについてＲＦ近傍にある１または複数のデバイスに関する報告をネットワークから受信することができる。これは、相互発見のための手順を完了することができる。

あるいは、デバイスがいかなる報告も受信することなく、一方向発見のための手順が終了され得る。この場合、検出されたＲＦ近傍を有し得る他のデバイスが、それらの各アプリケーションに発見を報告することができる。サービスアイデンティティが与えられると、アプリケーションは、何がＲＦ近傍にあるか、そしてアプリケーションがサービスアイデンティティを発見可能にできるかどうかを決定することができる。その場合、手順は、相互発見のために逆方向で反復され得る。

監視デバイスは、ネットワークにより送信された信号を使用してＤＩＳＣＨ構成を取得することができる。

デバイスは、それが発見アイデンティティについて監視することができると決定することができる。例えば、アプリケーションは、適切なサービス発見アイデンティティを決定し、ＡＰＩを介して、特定のサービス発見アイデンティティが特定の時間ウィンドウにおいて監視されるように要求することができる。

第１のデバイス内のアプリケーションは、ユーザ入力から、かつ／または（例えば第２のデバイス内の）同位アプリケーションとのアプリケーションレベルのデータ交換から、監視手順を開始することができる。例えば、第２のデバイス内のアプリケーションは、第１のデバイス内のアプリケーションに、それが特定の期間に発見可能であり得ることを示すことができる。この表示の受信により、ユーザは通知されることができ、監視手順を行うことに同意することができる。あるいは、アプリケーションは、ＡＰＩを介して監視要求を自動的に行ってもよい。アプリケーションレベルで交換される表示は、サービス発見アイデンティティを含むことができる。

監視デバイスは、関係するサービスアイデンティティについてＤＩＳＣＨを監視することができる。関係するサービス発見アイデンティティをデバイスが検出した場合、デバイスは、ＤＩＳＣＨ上の関連付けられたＲＦ発見信号のためのスケジューリング情報を受信することもできる。デバイスがＤＩＳＣＨ上の関連付けられたＲＦ発見信号のためのスケジューリング情報を受信しない場合、デバイスは、それが後でスケジューリング情報を受信できるように、サービス発見アイデンティティについてネットワークに関連する報告をすることができる。デバイスは、ＰＤＣＣＨ上のＰＤ−ＲＮＴＩについて監視して、関係する発見アイデンティティについてのスケジューリング情報を検出することができる。

デバイスは、サービス発見アイデンティティ関連付けられたリソースで、そのようなリソースがスケジューリングされるサブフレームにおいて、ＲＦ発見信号について監視することができる。デバイスは、サービス発見アイデンティティに関するＲＦ近傍を検出することができる。

例えば、デバイスは、ＡＰＩを介して、関連付けられたサービス発見アイデンティティに関するＲＦ近傍を報告することができる。アプリケーションは、何がＲＦ近傍にあるか、そしてアプリケーションがサービスアイデンティティを発見可能にできるかどうかを決定することができる。

デバイスは、（例えば、相互発見のための逆「方向」で）サービス発見手順を開始することができる。デバイスは、関連付けられたサービス発見アイデンティティに関するＲＦ近傍をネットワークに報告することができる。

例えば、第１のユーザ「Ｂｏｂ」および第２のユーザ「Ｊｏｈｎ」が、アプリケーションＸ（例えば、フェイスブック）に関して知られた関係を有する（例えば、彼らは友達である）ことができる。アプリケーションＸは、各関係についてアイデンティティ（例えば、ＵＲＩまたは等価な数値トークン）を管理することができる（例えば、Ｊｏｈｎ＠Ｆａｃｅｂｏｏｋ＝＞ＢｏｂおよびＢｏｂ＠Ｆａｃｅｂｏｏｋ＝＞Ｊｏｈｎ、またはＦａｃｅｂｏｏｋ：：Ｊｏｈｎ⇔Ｂｏｂ）。第３のユーザ「Ｍａｒｉａ」は、Ｂｏｂと知られた関係を有していないことがあるが、Ｊｏｈｎに対する接続を有することがある。アプリケーションＸは、各関係するユーザのデバイスに関連付けられた無線モジュールに対するＡＰＩを実装することができる。アプリケーションＸアプリケーションのインスタンスは、各関係するユーザのデバイス上で動作することができ、近傍検出機能が各インスタンスについて有効にされ得る。

この例では、Ｂｏｂは、彼の友人Ｊｏｈｎが近接しているかどうかを決定しようとすることができる。従って、Ｂｏｂは、彼のフェイスブックアプリケーションの近傍検出機能をアクティブにすることができる。また、Ｂｏｂは、それによって彼が彼の友人Ｊｏｈｎによる発見のために彼自身（例えば、彼のアプリケーションおよび彼のデバイス）を可視にしようとする機能を、アクティブにすることができる。フェイスブックアプリケーションは、対応する接続を識別することができる。対応する接続のアイデンティティは既に知られていることがあり（例えば、両方のユーザがアプリケーションを使用して接続されたときに決定される）、アプリケーションは、確立されたインターネット接続を介してアプリケーションサーバから接続アイデンティティを得ることができる。接続アイデンティティは、ＡＰＩを介して渡され得る。接続アイデンティティは、プロセス中に発見ＩＤに変換され得る。

ＭａｒｉａとＪｏｈｎの両方のフェイスブックアプリケーションが、近接する友人が検出され得るように有効にされたそれぞれの近傍検出機能を有することができる。無線モジュールは、ＡＰＩを介して必要なアイデンティティを用いてアプリケーションによって構成され得る。Ｍａｒｉａ、Ｂｏｂ、およびＪｏｈｎのデバイスはそれぞれ、既存の方法により、セル内でブロードキャストされたシステム情報を取得することができ、さらにそれのＤＩＳＣＨ構成を取得することができる。

Ｂｏｂは、彼のデバイスを、アプリケーションＸでＪｏｈｎのデバイスに発見可能にすることができ、このアプリケーションは、サービス発見アイデンティティ（例えば、ＡｐｐＸ：：Ｊｏｈｎ＜＝＞Ｂｏｂ）を決定し、それを適切なフォーマットに変換し、要求をデバイスのワイヤレスモジュールに渡すことができる。Ｂｏｂのデバイスは、サービス発見アイデンティティを含めて発見要求をネットワークに送ることができる。Ｂｏｂのデバイスは、要求に肯定応答する発見応答を受信することができる。

Ｊｏｈｎのデバイス内のアプリケーションＸは、アクティブにされた発見機能を有することができ、Ｂｏｂのデバイスとの接続に対するサービス発見アイデンティティ（例えばＡｐｐＸ：：Ｊｏｈｎ＜＝＞Ｂｏｂ）を認識することができる。アプリケーションＸは、「ＡｐｐＸ：：Ｊｏｈｎ＜＝＞Ｂｏｂ」を含む対象の全てのアイデンティティによりＪｏｈｎのデバイスのワイヤレスモジュールを構成していることが可能である。

Ｍａｒｉａのデバイス内のアプリケーションＸは、アクティブにされた発見機能を有することができ、Ｂｏｂのデバイスとの接続を有することがないが、Ｊｏｈｎのデバイスとの接続（例えば、ＡｐｐＸ：：Ｍａｒｉａ＜＝＞Ｊｏｈｎ）を有することができる。アプリケーションＸは、対象の全てのアイデンティティによりＪｏｈｎのデバイスのワイヤレスモジュールを構成していることが可能である。

Ｍａｒｉａ、ＢｏｂおよびＪｏｈｎのデバイスは、（例えば、ＰＤＣＣＨ上のＤＩ−ＲＮＴＩによる動的スケジューリングによって）セルのためのＤＩＳＣＨを取得することができる。３つの全てのデバイスが、ＡｐｐＸ：：Ｊｏｈｎ＝Ｂｏｂに対応するアイデンティティ並びにＲＦ発見アイデンティティおよび有効期間を含むＲＦ発見信号のための（時間および周波数の）関連付けられた構成を含む、ＤＩＳＣＨ上でブロードキャストされた１または複数のサービス発見アイデンティティを検出することができる。

Ｍａｒｉａのデバイスは、ＡｐｐＸ：：Ｊｏｈｎ＜＝＞Ｂｏｂに対応するアイデンティティを認識することがない。Ｍａｒｉａのデバイスは、ＤＩＳＣＨを監視し続ける以外のさらなるアクションを行うことがない。

Ｊｏｈｎのデバイスは、ＡｐｐＸ：：Ｊｏｈｎ＜＝＞Ｂｏｂに対応するアイデンティティを認識し、対応するＲＦ発見信号の監視を開始することができる。

Ｂｏｂのデバイスは、サービス発見アイデンティティに対して割り振られた時間／リソースにおける対応するＲＦ発見信号を送信することができる。Ｂｏｂのデバイスは、有効期間の期限切れまで送信を反復することができる。

Ｊｏｈｎのデバイスは、サービス発見アイデンティティに対して割り振られた時間／リソースにおける対応するＲＦ発見信号を受信することに成功することができる。Ｊｏｈｎのデバイス内のワイヤレスモジュールは、サービスアイデンティティの存在および近傍の検出を、ＡＰＩを介してアプリケーションＸに示すことができる。アプリケーションは、発見手順が完了する（一方向発見）と決定することができ、または、アプリケーションは、ＡｐｐＸ：：Ｂｏｂ＝Ｊｏｈｎに対応するアイデンティティを使用してサービス発見を開始し、同様の手順を使用して、しかし発見可能デバイスとして相互発見を完了することができる。

Ｂｏｂのデバイスは、関係するサービスアイデンティティについてのＲＦ近傍信号の送信を終了することができる。Ｊｏｈｎのデバイス内のワイヤレスモジュールは、関係するサービスアイデンティティについての発見手順の完了を、ＡＰＩを介してアプリケーションＸに示すことができる。アプリケーションは、発見手順が完了された（一方向発見）と決定することができ、または、アプリケーションは、ＡｐｐＸ：：Ｂｏｂ＜＝＞Ｊｏｈｎに対応するアイデンティティを使用してサービス発見を開始し、同様の手順を使用して、しかし監視デバイスとして相互発見を完了することができる。

ネットワークインフラストラクチャからの部分的サポートを有するサービス発見が本明細書で説明される。これは、デバイスが、ネットワークにより割り振られスケジューリングされたリソース上で発見アイデンティティ（ＩＤ）をそれら自体でブロードキャストすることができるという点で、前述の説明とは異なり得る（即ち、チャージがアプリケーションごとに行われネットワークが発見ＩＤを検出し得るとき、および、チャージがデバイスごとに行われることができ、ネットワークは発見ＩＤに関するいかなる情報も必要とすることがないとき、ネットワークは発見ＩＤを決して検出することができない）。リソースは、近傍を検出するためにも使用され得る。

ネットワークインフラストラクチャなしのサービス発見が本明細書で説明される。これは、デバイスが、ＤＩＳＣＨに使用するためのリソースを決定し、全ての動作をＤＩＳＣＨ上で行うように構成され得るという点で、前述の説明とは異なり得る。ＤＩＳＣＨ上の送信は、近傍を検出しマスタ−スレーブ役割を担うためにも使用され得る。

ネットワークは、アクセス権およびアプリケーションタイプなどによって要求を「ポリシング（police）」することができる。監視デバイスは、対象のサービスＩＤ範囲のサブセットを決定することができる。

発見チャネルは、Ｄ２Ｄ発見のために予約されたリソースのセットであり得る。これは、発見信号、肯定応答信号、およびひいては同期信号を含むことができる。発見信号チャネルは、１または複数の発見送信信号のために予約されたリソースのセットであり得る。

１または複数のサブフレームでの少なくとも１つの発見信号の送信のための方法および装置が本明細書で説明される。これらの方法および装置は、本明細書で説明されている任意の手順を含むがこれらに限定されないより高いレベルの発見手順の一部として利用され得る。

送信手順を開始するトリガーが本明細書で説明される。送信手順は、送信手順を開始するための明示的表示をネットワークからデバイスが受信したときに開始され得る。表示は、プローブ要求から、またはプローブおよびスキャン要求からなり得る。表示は、物理層、ＭＡＣ、またはＲＲＣシグナリングによって提供され得る。

送信手順は、周期的手順に応答して開始され得る。ある期間が、別の送信手順（例えば、最後の送信手順、もしくは同じイベントによりトリガーされた最後の送信手順）の開始または完了から経過していることが可能である。この期間は、予め定義されてもよく、または高位層シグナリングを介してネットワークによって提供されてもよい。

送信手順は、先行のサブフレームで特定の品質閾値より高い特定のタイプの発見信号をデバイスが検出したときに開始され得る。検出される発見信号のタイプは、（例えば、近くのデバイスを発見しようとする別のデバイスにより送信された）送信手順の開始の要求のための特定のタイプであり得る。

送信手順は、（例えば、ＩＥによる表示に従う）デバイスに対するハンドオーバまたは再確立の後、または、発見手順が有効にされるエリアにデバイスが入った可能性があると検出した後に開始され得る。

以下の追加の手順は、デバイスが特定のイベントについて送信手順を開始することを満たすために有用であり得る。デバイスは、発見手順が有効にされるエリアまたはセル内にあり得る。デバイスは、ネットワークに同期され得る（例えば、タイミングアドバンスタイマ（timing advance timer）が動作していることが可能である）。デバイスは、無線リンク問題を経験しないことが可能である（例えば、同期状態が検出され得る）。発見信号の特性、並びにその送信に使用される送信電力、サブフレーム、およびリソースは、送信手順をトリガーしたイベントに依存し得る。

送信手順を中断するトリガーが本明細書で説明される。送信手順は、送信手順を中断するための明示的表示をネットワークからデバイスが受信したときに終了され得る。例えば、デバイスは、送信手順をトリガーしたプローブ手順もしくは要求に優先割り込みする、またはそのプローブもしくはスキャン状態を変更する、プローブまたはスキャン要求を受信していることがある。表示は、物理層、ＭＡＣまたはＲＲＣシグナリングによって提供され得る。

送信手順は、手順の開始からデバイスが最大数の発見信号を送信したときに開始され得る。送信手順は、先行のサブフレームで特定の品質閾値より高い特定のタイプの発見信号をデバイスが検出したときに開始され得る。検出される発見信号のタイプは、（例えば、別のデバイスにより送信された）送信手順の中断の要求のための特定のタイプであり得る。送信手順は、プローブ／スキャン要求で提供される潜在的隣接要素のリストの要素の全てを識別したときに開始され得る。

また、発見信号リソースおよびインデックスのための方法および装置が本明細書に開示される。図４は、帯域内に割り振られたＰＬＭＮ専用発見チャネルの例を示す。図５は、帯域外に割り振られた共通発見チャネルの例を示す。このように、発見チャネルは、帯域内（即ち、ネットワークと同じスペクトルを共有する）または帯域外（即ち、ネットワークスペクトルの外）に配置され得る。

帯域外の場合は、電力増幅器、フィルタまたはデュプレクサを含むがこれらに限定されない追加のＲＦの複雑さを生じ得る。この場合、発見チャネルは、１つのＰＬＭＮに専用にされてよく、または、異なるＰＬＭＮ間で共有されてよく、これは異なるＰＬＭＮに属するデバイスの間の発見を容易にすることができる。

セルラーネットワークおよびＤ２Ｄ二重化方法は、ＦＤＤ、半ＦＤＤ（ＨＦＤＤ）またはＴＤＤとすることができる。しかしながら、Ｄ２Ｄ ＴＤＤモードは、１つの追加のＴｘまたはＲｘチェーンが必要とされるので、それは各デバイスで２つのベースバンドおよびＲＦチェーンを追加することを必要としないため、好まれることがある。

帯域外の場合、Ｄ２Ｄ二重化方法はＴＤＤとすることができ、発見チャネルは、ＴＤＤバンド、ＦＤＤ ＤＬバンド、またはＦＤＤ ＵＬバンドにより近く割り振られ得る。異なる干渉シナリオが、それぞれの場合に適用し得る。

Ｄ２Ｄ二重化方法がＴＤＤである場合、発見チャネルは、このネットワークがＦＤＤまたはＴＤＤモードである状態で、ネットワークＤＬまたはＵＬリソースのいずれかに割り振られ得る。ＤＬリソース上の割り振りは、複数のスキャンデバイスが発見信号の受信のためにＲｘを再構成する必要がないという利点を有することができる。ＵＬリソース上の割り振りは、デバイスではなくｅＮＢ受信に影響するＤ２Ｄ干渉を低減することができる。ネットワークがＤ２Ｄ発見および通信を制御するので、それは、それらの干渉をより容易に緩和することができる。

二重化モードと独立して、発見チャネルは、サブフレーム、スロット、直交周波数分割多重（ＯＦＤＭ）シンボル、サブキャリア、リソースブロックまたはキャリアのセットに対応することができる。このチャネルは、発見信号、肯定応答信号、およびひいては同期信号の間で分割されてもよく、またはそれらの間で共有されてもよい。それらのリソースは、ネットワーク通信と同じ時間スロット上（例えば、干渉は注意深く取り扱われ得る）、または発見チャネルに専用にされた時間スロット上に割り振られ得る。

図６は、ＵＬを有する帯域内時分割多重（ＴＤＭ）に割り振られた発見チャネルの例である。発見信号は、スケジューリングされたダウンリンクまたはアップリンクリソースから使用されるリソースのセットパターンまたはオフセットとして構成され得る。発見信号は、アップリンクまたはダウンリンク送信を有するＴＤＭで動作することができ、ＴＤＭパターンが構成パラメータとしてデバイスに提供される。クロスリンク（ＸＬ）発見リソースが、帯域内であり、アップリンクリソースを有するＴＤＭであり得る。ＸＬサブフレームで使用されるさらなるリソースは、アップリンクリソースのサブセットに限定され得る。さらに、指定されたＸＬが、デバイス固有ＴＤＤパターンで動作するようにさらに構成され得る（例えば、発見信号の送信のためにスロット０を使用し、発見信号のリッスンのためにスロット１を使用する）。

低電力ビーコンの適切な受信を確実にするために、ビーコン送信または受信が発生し得るサブフレーム内のＤＴＸを行うように、隣接デバイスを構成することが望ましいことがある。ネットワークは、ＤＴＸパターン構成の存在下でどのように動作するかに関する動作ルールを用いて隣接デバイスのためのＤＴＸパターンを構成することができる。一例では、デバイスは、ＤＴＸのために構成されたサブフレーム上のランダムアクセスチャネル（ＲＡＣＨ）スケジューリング要求（ＳＲ）を行うのを禁止する、またはそれをＳＰＳ用途に使用することができる。別の例では、デバイスは、特定のアップリンク送信がクロスリンク発見送信に対してより高い優先度で行われることを可能にするように、優先順位付け規則を用いて構成され得る。例えば、ＤＴＸが割り振られたサブフレームにおける場合、アップリンク肯定応答（ＡＣＫ）／否定応答（ＮＡＣＫ）およびＣＱＩが送られることを必要とされることがあり、Ａ／ＮおよびＣＱＩはクロスリンクＤＴＸに対してより高い優先度があるとみなされ得る。

発見チャネルは、競合ベースもしくは競合なし（ＴＤＤもしくはＦＤＤ）、または両者の組み合わせ（例えば、ＬＴＥにおけるＰＲＡＣＨ割り振りなど）とすることができる。いくつかのリソースが特定のユーザに対して（例えば、それらの発見手順がより高い優先度またはより低い待ち時間要件を有するときに）予約され得るのに対し、他のリソースは、ユーザのグループに割り振られたセット内で編成され得る。

リソースに対する競合ベースのアクセスが使用されてよく、発見信号肯定応答がデバイスからネットワークを介してまたは直接受信されることがない場合、ランダムバックオフ手順が競合を解決するために適用され得る。このバックオフは、任意のＤ２Ｄ発見リソースに適用され得る。

送信手順で使用されるＤ２Ｄ発見リソースのセットが、（例えば、物理層（ＰＨＹ）、ＭＡＣまたはＲＲＣシグナリングを介する）ネットワークからのリソースの明示的表示に基づいて決定され得る。例えば、デバイスは、予め決定されたマッピングを有するリソース構成インデックスを使用してリソースのセットによって示され得る。

送信手順で使用されるＤ２Ｄ発見リソースのセットは、デバイス固有パラメータ（例えば、Ｃ−ＲＮＴＩ）またはセル固有パラメータ（例えば、ＰＣＩ）のような構成パラメータに応じて決定され得る。例えば、発見信号がＰＲＡＣＨである場合、プリアンブルインデックスはＣ−ＲＮＴＩに応じ得る。

送信手順で使用されるＤ２Ｄ発見リソースのセットは、デバイスが動作し得る発見モードに応じて決定され得る。（例えば、送信のためにスロット０、受信のためにスロット１を使用する）。

別の方法では、デバイスは、（例えば、ある順序で（例えば、順次など）リソースブロック（ＲＢ）を使用するシーケンスで進行する）自律的様式でより大きなセットの候補からリソースのセットをランダムに決定することができる。

使用される方法は、送信手順をトリガーするイベントに依存し得る。ある方法は、周期的送信手順により適切とされ得るのに対し、別の方法は、手順が発見信号の受信によりトリガーされている場合により有用であり得る。

発見信号設計のための方法および装置が本明細書で説明される。

発見信号は、ＬＴＥシステムで現在使用されている信号または物理チャネルからなることができる。それは、現在定義されていない信号からもなり得る。ある機能性は信号の使用をサポートするために必要とされることがあり、ある機能性は信号の使用により有効にされることがある。

発見信号の特定のタイプの送信および／または受信は、先行の粗いまたは精密なタイミング取得を必要とし得る。先行の精密なタイミング取得を必要とする発見信号の例は、物理制御フォーマットインジケータチャネル（physical control format indicator channel：ＰＣＦＩＣＨ）、ＰＤＣＣＨ、ＰＤＳＣＨ、物理ＨＡＲＱインジケータチャネル（ＰＨＩＣＨ）、および物理アップリンク共有チャネル（ＰＵＳＣＨ）を含むことができるがこれらに限定されない。先行の粗いタイミング取得を必要とする発見信号の例は、ＰＲＡＣＨ、ＳＲＳおよびＵＬ復調参照信号（UL demodulation reference signal：ＤＭ−ＲＳ）を含むことができるがこれらに限定されない。プライマリ同期信号（primary synchronization signal：ＰＳＳ）およびセカンダリ同期信号（secondary synchronization signal：ＳＳＳ）など他のタイプの発見信号は、何ら先行の同期を使用しないことがある。

特定のタイプの発見信号は、粗いまたは精密なタイミングを推定するために受信機によって使用され得る参照パターンを含むことができる。そのような発見信号の例は、ＰＳＳ／ＳＳＳ、物理ブロードキャストチャネル（physical broadcast channel：ＰＢＣＨ）、およびＰＲＡＣＨを含むことができるがこれらに限定されない。

特定のタイプの発見信号は、保護帯域および／または保護時間を含むことができ、それにより、時間または周波数オフセットに対する保護を提供し、通常のＬＴＥネットワーク信号に（周波数または時間で）隣接する信号の送信を可能にする。そのような発見信号の例は、ＰＳＳ／ＳＳＳおよびＰＲＡＣＨを含むことができるがこれらに限定されない。

特定のタイプの発見信号は、情報ペイロードの送信を可能にすることができる。そのような発見信号の例は、ＰＤＳＣＨ、ＰＵＣＣＨ、およびＰＵＳＣＨを含むことができるがこれらに限定されない。他の発見信号は、単にインデックスおよび／またはコードのようなパラメータの有限セットによって特徴付けられ得る。

特定のタイプの発見信号は、帯域幅（サブキャリアまたはリソースブロックの数）および時間（スロットまたはサブフレームの数）に関して柔軟性を有することができる。特定のタイプの発見信号は、リソースまたはリソースのセットに並行して送信され得る。特定のタイプの発見信号は、所与の受信信号対雑音比に対してより高いまたはより低い検出失敗確率または誤り確率で検出され得る。特定のタイプの発見信号は、現在のシステムにおけるダウンリンク方向で使用されることができ、他は、アップリンク方向で使用され得る。特定のタイプの発見信号は、ＬＴＥ先行リソース（例えば、Ｒ８〜１１）と共通性および／または互換性を有することができ、修正なしにまたはわずかなコストで、現在のデバイスＴｘおよびＲｘチェーンが再使用されることを可能にする。

図７Ａおよび図７Ｂは、発見信号設計のためのＬＴＥ信号特性を示す。これらの信号の１つまたは組み合わせは、発見信号設計のためのベースラインとして使用され得る。Ｚａｄｏｆｆ−Ｃｈｕシーケンスに基づく信号は、それらが、同じセットのリソース上で異なるユーザ間の直交送信を可能にし得るので、特に対象とすることができる。同じＺａｄｏｆｆ−Ｃｈｕベースシーケンス上で異なる循環時間シフトが使用される場合、粗同期が必要とされ得る。例えば、３から５ＲＢ割り振りでは、低相互相関を有する３０個のベースシーケンスが利用可能であり得る。それらのベースシーケンスの任意の循環時間シフトが、純粋に直交のシーケンスの生成を可能にすることができる（循環シフトがチャネルインパルス応答より長いとしたときのゼロ相互相関）。１２個の等間隔の循環時間シフトが、ＰＵＳＣＨおよびＰＵＣＣＨ上のＤＭＲＳについて定義され得る。これは、５．５５μｓの遅延拡散を可能にすることができる。Ｄ２Ｄ発見コンテキストでは、これは、同じセットのリソース上の同じセル内で１２個の並行プローブ手順の動作を可能にすることができる。この手法により、デバイスは、並行して異なるプローブ信号をデコードし、従って同時に異なる隣接要素を発見することも可能であり得る。

ＰＢＣＨチャネルに組み合わされたＰＳＳ／ＳＳＳの再使用は、発見信号にペイロード（従って追加のコンテンツ）を含めることを可能にすることができる。あるいは、ＰＲＡＣＨ信号の再使用は、それが既にランダムアクセスのために特に設計されており、Ｄ２Ｄ発見のためにわずかな修正のみを必要とし得るので、実装され得る。

さらに、追加のダイバーシチ方式が発見信号設計に含まれ得る。それらの方式は、時間、周波数、または空間ダイバーシチの１つまたは任意の組み合わせとすることができる。反復符号化が使用され得る（例えば、発見信号がいくつかの時間／周波数／空間リソースで反復され得る）。割り振りインターリーブが実装され得る（例えば、異なるユーザの発見信号がいくつかの時間／周波数／空間リソースで分割されインターリーブされ得る）。発見信号が、追加のリソース上で拡散されることができ、追加信号は擬似雑音シーケンスにより多重化され得る。

また、発見信号の送信電力およびタイミングのための方法および装置が本明細書に開示される。図８は、デバイスツーデバイス（Ｄ２Ｄ）ダウンリンク（ＤＬ）またはアップリンク（ＵＬ）同期の例を示す。デバイスはＤ２Ｄ送信のための参照としてＤＬまたはＵＬネットワーク同期を使用することができる。プローブ状態において、デバイスは特定の同期バーストを送信することができ、これは、発見信号の一部であり得る、または異なるチャネルリソース上で独立して送信され得る。デバイスは、外部同期ソース、例えば、ＧＰＳ信号などで同期することができる。

タイムスタンプが発見信号に含まれ得る。ネットワークＵＬタイミングアドバンスステータスを含むがこれに限定されない任意の他の適切な情報が連結されてもよい。

発見信号送信機は、そのタイミングを調節することを必要とされ得る。ネットワークは、（例えば、タイミングアドバンス手順中に取得されるような異なるデバイスのタイミングのその知識に基づいて）調節を必要とし得る。この調節は、発見信号送信機および１またはいくつかの潜在的隣接要素の間のタイミングオフセットを低減するために必要とされ得る。

潜在的隣接要素は、最初の発見信号送信の後に肯定応答チャネルを介して送信機に対するタイミング調節を必要とし得る。潜在的隣接要素が別のデバイスとの発見プロセスに既に関与していることがあり、２つの発見信号送信機の間のタイミング差が両方の信号を適切にデコードするためには大きすぎることがある。潜在的隣接要素は、後続のＤ２Ｄ通信段階を適切に準備するために（例えば、マルチパス変更に対してより頑健になるように）この調整を必要とし得る。

この調節は、共通Ｄ２Ｄグループ同期を達成するために必要とされ得る。いくつかの潜在的隣接要素が発見手順に関与することがあり、これらのデバイスが全て同じ範囲内にはない場合、グループ内の共通同期を達成するために、同期目標として、グループ内の最も遅延されたデバイスにタイミングを調節することができる。各デバイスは、それ自体とその隣接要素との間のタイミング差を追跡し、肯定応答信号または通信段階における他の手段によって、この情報を伝達することができる。各デバイス発見の後、送信機は、そのタイミングを最も遅延されたデバイスに対して更新することができる。

図９は、ネットワークによって定義された時間ウィンドウを有する分散されたＤ２Ｄ同期戦略の例を示す。（デバイスごとまたはデバイスのグループごとの）分散された同期調節は、ネットワークとのＤ２Ｄ干渉を制限するように、ネットワークによって定義されたタイミングウィンドウ内で発生し得る。タイミングウィンドウの別の目的は、デバイスがＤ２Ｄ通信およびネットワーク通信の並行検出または送信を達成するための能力を保持することであり得る。

また、電力制御のための方法および装置が本明細書で説明される。発見信号Ｔｘ電力は、所与のセル内で静的であることができ、セルサイズまたは（都市または地方などの）伝搬環境を含むがこれらに限定さないパラメータに基づいて予め決定され得る。Ｔｘ電力は、最初の送信について最小値に割り当てられ得る。この送信が肯定応答されない場合、各新しい送信の電力にランプアップが適用され得る。到達され得る最大電力は、静的ネットワークであってよく、または、（例えば、干渉またはトラフィック負荷のレベルを含むがこれらに限定されない現在のネットワークステータスに基づいてプローブ要求手順を介して）ネットワークによって決定され分配され得る。

閉ループ機構が、発見信号送信機と潜在的隣接要素の間で使用され得る。異なる測定が、発見信号Ｔｘ電力に適用されるべきオフセットを決定するために受信機で適用され得る。このオフセットは、肯定応答メッセージを介してまたは間接的にスキャン報告を介して送られ得る。スキャン報告をデコードした後、ネットワークは、特定のメッセージを介してまたは新しいプローブ要求を介して、プローブデバイスにＴｘ電力調節を送信することができる。ネットワークは、干渉またはトラフィック負荷を含むがこれらに限定されない現在のネットワークステータスに基づいて、電力増加要求を確認することができる。ネットワークは、ネットワークが依然としてＤ２Ｄ発見と通常のネットワーク通信との間で適切に共有され得ることを確認するために、他のデバイスにサウンディング手順を最終的に要求することができる。

静的または最大Ｔｘ電力は、Ｄ２Ｄ範囲クラスに分割され得る。これらのクラスは、１つのデバイスにアクセス可能な最大Ｄ２Ｄ範囲を制限することができる。この制限は、地方環境における最大Ｄ２Ｄ干渉レベル、または加入者によりコスト負担させるより高いクラスへのデバイスのアクセスのようなチャージ方法を含むがこれらに限定されない、ネットワークパラメータに基づいて定義され得る。最後に、Ｄ２Ｄネットワークパラメータは、クラスＡ範囲（例えば、５０ｍ）に対するアクセスを有するＤ２Ｄユーザの最大数、およびクラスＢ範囲（例えば、１００ｍ）に対するアクセスを有するＤ２Ｄユーザの最大数などとして定義され得る。

発見信号は、送信機アイデンティティ、送信機グループアイデンティティ、送信機ネットワークパラメータ（例えば、セル、ＰＬＭＮ、アタッチステータス、およびＲＲＣステータスなど）、並びに／または送信機からの電力およびタイミング参照を含むがこれらに限定されない、パラメータを含むことができる。タイミングは、タイムスタンプによって明示的に提供されてもよく、または同期バーストを介して暗黙的に提供されてもよい。

発見信号は、以下に限定されないが、発見信号再送信数、発見信号最大再送信数、送信機からのサービス記述（例えば、送信機が店舗広告に専用にされたデバイスである場合、それは、店舗名とともに店舗宣伝の一部を含むことができる）、（Ｃ−ＲＮＴＩなどの任意のデバイス固有識別子により識別された）Ｄ２Ｄ発見のための予め選択されたデバイス（潜在的隣接要素）のリスト、ターゲットにされたデバイス能力（例えば、ネットワーク、特定のＰＬＭＮ、特定のセル、特定のグループへのアタッチ、または中継能力）のリスト、（メッセージ宛先、即ちデバイスまたはｅＮＢを含むことができる）肯定応答要求、発見手順識別子、発見手順優先度、並びに／または（もしあれば）発見手順開始時間および終了時間を含む、パラメータを含むことができる。

上述のパラメータの少なくとも１つが発見信号ペイロード内で明示的に提供され得る。さらに、上述のパラメータの少なくとも１つが発見信号特性に暗黙的に含まれ得る。これは、特定の発見信号、特定の発見信号リソースまたは特定の発見信号インデックスを介して実装され得る。その特性から信号情報を取り出すことを可能にするマッピングが、マッピングテーブルを介して実装され得る。このテーブルまたは特定のパラメータは、（例えば、Ｄ２Ｄ発見要求またはＤ２Ｄ隣接通知によって）発見信号送信の前または後にネットワークによってデバイスに配布され得る。

発見信号は、そのリソースおよびインデックスマッピング以外の他の特性を有していなくてよく、また（このリソースおよびインデックスのマッピングを介して）スキャン報告の後にｅＮＢにより提供され得る任意の他の情報を有し得る。

セキュリティは無線通信における新しい特徴の主要な懸念材料であり得る。それは、Ｄ２Ｄアプリケーションについて特に要注意なことがあり、なぜならば、この種のサービスは、適切に保護されない場合、ユーザが秘密にしておきたいユーザアイデンティティ、ユーザ位置、および／または特定のグループへの所属を容易に曝露するおそれがあるためである。また、Ｄ２Ｄ通信と同様に、制御の一部がデバイスに分散されるので、セキュリティ侵害が、この種のアプリケーションを通してネットワーク全体に開かれることがある。

セキュリティセンタ（trust center）がｅＮＢ、ＭＭＥ、ホーム加入者サーバ（home subscriber server：ＨＳＳ）、または同じ能力を有する特別なデバイスノードを含むがこれらに限定されないセキュリティ信頼能力を有する任意のネットワーク要素にマッピングされ得る。同じ能力を有する特別なデバイスノードへのマッピングは、オフネットワークＤ２Ｄ発見の場合に特に適合され得る。

セキュリティを実装するために、Ｄ２Ｄ発見コンテキストはＤ２Ｄ発見要求を認可することであり得る。アプリケーションに応じて、その認可を担当するセキュリティセンタは、ネットワーク内の異なるレベル（例えば、ＭＭＥ、ｅＮＢまたはデバイス）で配置され得る。この認可は、別のエンティティ（例えばＨＳＳ）またはセキュリティセンタそれ自体に記憶されたＤ２Ｄデバイスプロファイルに関係付けられ得る。この認可の後、発見優先度の取り扱いが行われ得る。ネットワークが他の発見手順によって既に飽和された場合、新しい発見はネットワークによって遅延または拒否され得る。

Ｄ２Ｄ発見における別の主要なセキュリティ事項は、発見手順に関与する１またはいくつかのエンティティの匿名性であり得る。Ｄ２Ｄ発見要求タイプに応じて、探索デバイス、Ｄ２Ｄ発見グループ、および／または潜在的隣接要素の匿名性が必要とされ得る。異なる方法および装置がこの匿名性を保持するために適用されてもよい。

図１０は、探索デバイス匿名性保持の例を示す。図１０に示されるように、ネットワークは、発見信号リソース割り振りとＤ２Ｄ発見要求の間の秘密マッピングを定義することができる。ネットワークは、通常のｅＮＢデバイスの保護されたリンクを使用して１または複数のデバイスに対してプローブおよびスキャン要求を送ることができる。これらの要求は、任意の他のネットワークデータのように暗号化されてよく、それらは、識別する発見信号リソースを含むように限定され得る。発見信号が、Ｄ２Ｄ発見要求に関与しないデバイスにより識別されることができても、このデバイスは、Ｄ２Ｄ発見要求に関する任意の特定の情報を識別できることがない。この秘密マッピングは、特定のアプリケーションと特定の発見信号との間の相互関係が生じ得ないように、周期的に新しくされ得る。

スキャン報告を受信した後（即ち、このＤ２Ｄ発見要求のための発見信号識別の後）、ネットワークは、それが認可されたＤ２Ｄ発見要求に対応することを確認することができ、探索デバイス、Ｄ２Ｄ発見グループおよび探索アプリケーションを含むがこれらに限定されない認可された詳細を、隣接要素通知メッセージを介して認可されたノードに提供する。

探索デバイス、グループ、および／または潜在的隣接要素アイデンティティは、暗号化された信号を介して伝達され得る。この暗号化は、予め共有された鍵、証明書、または資格証明に基づくことができる。それらのセキュリティパラメータは、必要とされる機密性のレベルに応じて、オフラインでまたは無線で配布され得る。それらが無線で伝達される場合、通常のネットワークストリーム手順によって保護されることができ（例えば、それらはＤ２Ｄ発見要求のパラメータとして伝達され得る）、それらは、デバイスペアごと、またはＤ２Ｄ発見グループごとに割り当てられ得る。匿名性を必要としているデバイスは、スキャンモードに留まることができる。

匿名性問題とは別に、発見信号送信機の認証が確実にされ得る。これは、セキュリティセンタによって制御される同じオプションによって処理されることができ、セキュリティセンタは署名パラメータをプローブデバイスに提供し、スキャン報告の後にそれを検査することができる。あるいは、それは、デバイスに配布されることができ、（信号署名のために使用される）事前共有鍵、証明書、資格証明に基づくことができる。

Ｄ２Ｄ通信のＴｘ電力はｅＮＢよりも低いため、それは、フラッディング（flooding）またはジャミング攻撃により影響され得る。例えば、ネットワーク侵入者は、所与のエリア内の任意のＤ２Ｄ発見を妨害するために、または他のデバイスから何らかの情報を得るために、発見信号を継続的に送信し得る。これらのタイプの攻撃は、セキュリティセンタが発見チャネルを周期的に更新して、攻撃者がそれを追跡しＤ２Ｄ発見に干渉できないようすることにより緩和され得る。この解決策の頑健性は、更新期間が減少するに従って増大し得る。あるいは、ネットワークは、所与のＤ２Ｄが割り振られたリソースに対する不正または異常な挙動を報告するための手順を設定することができる。スキャンデバイスは、特定の干渉または不正なインデックスを有する信号（即ち、ネットワークが侵入者を識別するのを補助し得る任意の情報）を報告することができる。ネットワークは、その挙動に関する良好な判断をするために、この情報を、現在のＤ２Ｄ発見要求およびプローブデバイスなどのそれ自体の知識に相互関連させることができる。

Ｄ２Ｄサービスを劣化させ得る別の攻撃は、反射攻撃である。この攻撃では、侵入者は、信号を記録し、後でそれを再現して、ネットワーク上で既に認可されたノードのアイデンティティを得ることができる。結果として、侵入者は、正しい暗号化パラメータを用いて信号を送ることが可能であり得る。Ｄ２Ｄ発見コンテキストでは、２つの対抗手段が発見信号に適用され得る。

タイムスタンプ（例えば、サブフレーム番号）が、送信機におけるネットワーク時間参照に基づいて信号ペイロードに追加され得る。このタイムスタンプは、受信機におけるネットワーク時間参照と照合され得る。タイムスタンプが有効でない場合、信号が破棄されることができ、最終的に報告がネットワークに送られ得る。

発見信号は、送信機において、時間パラメータに従って（例えば、ランダム化シードはサブフレーム番号と等しくしてもよい）ランダム化され得る。非ランダム化は、同じ時間パラメータに従って受信機において処理され得る。反射攻撃の場合、シードが異なることができ、信号は理解され得ない。トークンは、発見要求とともに送られることができる。このトークンは、発見信号の一部分を符号化するために使用されることができ、任意の新しい手順のために新しくされ得る。これらの対策は、暗号化鍵を含むがこれに限定されない他のセキュリティパラメータの周期的更新と組み合わされ得る。

受信手順を開始するトリガーが本明細書で説明される。デバイスは、受信手順を開始するための明示的表示をネットワークから受信したときに、発見信号のリッスンを始めるように別途構成され得る。表示は、プローブ要求、またはプローブおよびスキャン要求からなることができる。表示は、物理層、ＭＡＣまたはＲＲＣシグナリングによって提供され得る。

デバイスは、別の送信手順（例えば、最後の送信手順、もしくは同じイベントによりトリガーされた最後の送信手順）の開始または完了からある期間が経過しているときに、発見信号のリッスンを始めるように別途構成され得る。この期間は、予め定義されてもよく、または高位層シグナリングを介してネットワークによって提供されてもよい。

デバイスは、先行のサブフレームで特定の品質閾値より高い特定のタイプの発見信号をデバイスが検出したときに、発見信号のリッスンを始めるように別途構成され得る。検出される発見信号のタイプは、（例えば、近くのデバイスを発見しようとする別のデバイスにより送信された）送信手順の開始の要求のための特定のタイプであり得る。

デバイスは、（例えば、ＩＥがそれが実装され得ることを示す場合に）ハンドオーバまたは再確立が発生できた後、および／または、発見手順が有効にされ得るエリアにデバイスが入ったことを検出した後に、発見信号のリッスンを始めるように別途構成され得る。

少なくとも特定のイベントについて、デバイスが受信手順を開始するために、追加の条件が満たされる必要があり得る。それらの特定のイベントは、デバイスが、発見手順が有効にされ得るエリアもしくはセル内であること、デバイスが、ネットワークに同期されていること（即ち、タイミングアドバンスタイマが動作している）、および／またはデバイスが、無線リンク問題を経験していないこと（即ち、同期状態が検出され得る）を含むことができるがこれらに限定されない。

発見信号の特性、並びにその送信に使用される送信電力、サブフレーム、およびリソースは、送信手順をトリガーしたイベントに依存し得る。

受信手順を中断するトリガーが本明細書で説明される。受信手順は終了され得る。例えば、デバイスは、受信手順を中断するための明示的表示をネットワークから受信することができる。デバイスは、受信手順をトリガーしたスキャン手順もしくは要求に優先割り込みする、またはそのプローブもしくはスキャン状態を変更する、プローブまたはスキャン要求を受信していることがある。表示は、物理層、ＭＡＣまたはＲＲＣシグナリングによって提供され得る。別の例では、デバイスは、手順の開始から最大数の発見信号を受信し得る。さらに別の例では、デバイスは、先行のサブフレームで特定の品質閾値より高い特定のタイプの発見信号を検出することができる。検出される発見信号のタイプは、（例えば、別のデバイスにより送信された）送信手順の中断の要求のための特定のタイプであり得る。デバイスは、それが探していた潜在的隣接要素のリストからの要素の全てを識別することができる。

発見信号受信のための方法および装置が本明細書で説明される。発見信号設計および発見手順構成に応じて、単一（一度に１つの発見信号反復受信）または並行検出（一度にいくつかの発見信号反復受信）が適用され得る。並行検出は、異なるデバイス信号の間のタイミングおよび電力オフセットに制限を課すことができる。各検出の頑健性および並行プロセスの最大数の間で、最適な妥協点が定義され得る。

Ｄ２Ｄ発見タイプに応じて、特定またはブラインド検出が処理され得る。特定の検出において、デバイスは、どの発見信号がスキャンされたチャネルに存在し得るかを知ることができる。ブラインド検出では、デバイスは、どの発見信号がスキャンされたチャネルに存在し得るかを知ることができない。

発見信号の受信は、同期段階で開始することができる。同期参照は、ネットワーク（ＤＬまたはＵＬ）、特定の同期バースト、またはＧＰＳ信号などの外部ソースに基づくことができる。これらの異なる方法は組み合わせられ得る。受信機は、その受信ウィンドウをネットワーク同期に基づいて開くことができ、自己相関（反復パターン）、および／または参照パターンと入力信号の間の相互相関によって、受信ウィンドウ内の入力同期バーストを識別することができる。自己相関および相互相関プロセスは、（例えば、スライディング高速フーリエ変換（ＦＦＴ）の使用によって）時間領域または周波数領域のいずれかで実装され得る。

発見信号が知られている参照パターン（パイロットおよびプリアンブルなど）を含む場合、チャネル推定および補償は受信手順に従うことができる。発見信号設計は、デコーディング戦略を規定することができる。発見信号がＬＴＥチャネル設計（ＰＲＡＣＨ、ＰＤＣＣＨ、およびＰＤＳＣＨなど）を再使用する場合、同じデコーディングチェーンが再使用され得る。

並行検出の場合、反復デコーディング技術が適用されてもよく、その場合、識別された発見信号が入力信号から抜き取られることができ、新しいデコーディング反復が処理され得る。

発見信号が再送信である場合、以前の送信との信号組み合わせが適用され得る。信号の異なる部分が各送信で送られることができ、受信機はデコーダに供給をし、既に受信された部分で新しいデコーディングを試行することができる（増分冗長性）。あるいはまたは組み合わせで、同じメッセージが何回か送られることができ、受信機はデコーダに組み合わせを送る前に同相および直交（ＩＱ）値または対数尤度比を組み合わせることができる（チェイス結合（Chase combining））。再送信は信号肯定応答によって終了され得る。

発見信号がペイロードを含む場合、信号品位検査がＣＲＣデコーディングによって実装され得る。受信手順は、発見信号測定を含むこともできる。測定され得るメトリクスは、ＲＳＲＰ、ＲＳＲＱ、ＣＱＩ、経路損失または時間および周波数オフセットの１つまたは任意の組み合わせであるがこれらに限定されない。

発見信号受諾のための方法および装置が本明細書で説明される。ペイロードは、発見信号に関連付けられ得る。ＣＲＣが信号送信の際に行われることができ、受信の際に信号品位を検査するために使用され得る。あるいは、発見信号はＣＲＣを含むことがなく（例えば、ＰＲＡＣＨ信号など）、信号肯定応答が（本明細書で説明されたような）メトリック閾値に基づいて決定され得る。

発見信号は、受諾前に検査するための１またはいくつかのパラメータを含むことができる。グループ所属または発見優先度が検査され得る（例えば、受信機がグループ所属を認識しない場合、それは、発見信号を停止し受諾しないことができ、発見手順を終了することもできる）。発見信号に設定され得る優先度は、（例えば、そのバッテリレベルが既に低いことがあるので）受信機における現在の最大レベルより低くなり得る。その場合、受信機は手順を終了することができる。

本明細書で説明される方法は、最終判断を行うために組み合わせられ得る。これらの受諾基準は、信号肯定応答判断のため、かつ／またはデバイス高位層手順またはアプリケーションのために使用され得る。

実施形態
１． 無線送受信ユニット（ＷＴＲＵ）がデバイスツーデバイス（Ｄ２Ｄ）発見を行うための方法であって、
ＷＴＲＵが、発見要求を別のＷＴＲＵまたはネットワークに送って、サービスについての無線周波数（ＲＦ）近傍検出を行うために使用される発見プロセスを開始することと、
ＷＴＲＵが、発見応答についてチャネルを監視することと
を含む方法。
２． 発見要求は少なくとも１つの発見アイデンティティを含み、ＷＴＲＵは、発見可能ステータスまたは監視ステータスを有する、実施形態１に記載の方法。
３． ＷＴＲＵが、Ｄ２Ｄチャネルのための構成を受信することをさらに含む、実施形態１〜２のいずれかに記載の方法。
４． ＷＴＲＵ内のアプリケーションが、サービス発見手順をトリガーすることをさらに含む、実施形態１〜３のいずれか１つに記載の方法。
５． 発見要求は、ＷＴＲＵのセキュリティコンテキストまたはバッテリレベルに基づくステータスパラメータをさらに含む、実施形態１〜４のいずれか１つに記載の方法。
６． 発見要求は、発見要求が拒否された要求の反復であるかどうかを示すための一時発見プロセス識別子に対する参照をさらに含む、実施形態１〜５のいずれか１つに記載の方法。
７． ＷＴＲＵが、発見報告メッセージを別のＷＴＲＵまたはネットワークに送ることをさらに含む、実施形態１〜６のいずれか１つに記載の方法。
８． 発見要求は、ＲＦ発見の最大範囲を示す電力クラスに関連付けられた発見クラスパラメータをさらに含む、実施形態１〜７のいずれか１つに記載の方法。
９． 発見要求は、公共サービスアプリケーションに対応するサービスに関連付けられた発見クラスパラメータをさらに含む、実施形態１〜８のいずれか１つに記載の方法。
１０． 無線送受信ユニット（ＷＴＲＵ）がデバイスツーデバイス（Ｄ２Ｄ）発見を行うための方法であって、
ＷＴＲＵが、別のＷＴＲＵまたはネットワークから無線周波数（ＲＦ）近傍検出のための構成を受信することであって、構成は、サービスに関連付けられ、発見プロセス識別子を含む、ことを含む、方法。
１１． ＲＦ近傍検出のための構成は、物理ダウンリンク共有チャネル（ＰＤＳＣＨ）を介して専用シグナリングによって受信される、実施形態１０に記載の方法。
１２． ＲＦ近傍検出のための構成は、発見共有チャネル（ＤＩＳＣＨ）上で受信される、実施形態１０〜１１のいずれか１つに記載の方法。
１３． ＲＦ近傍検出構成に関連付けられた少なくとも１つのサービスアイデンティティ、有効性情報、および測定構成を、ＤＩＳＣＨを介して受信することをさらに含む、実施形態１０〜１２のいずれか１つに記載の方法。
１４． 少なくとも１つのサービスアイデンティティ、有効性情報および測定構成を含む送信が、特定の無線ネットワーク一時アイデンティティ（ＲＮＴＩ）およびサブフレームタイミングを使用して物理ダウンリンク共有チャネル（ＰＤＳＣＨ）によってスケジューリングされる、実施形態１３に記載の方法。
１５． ＷＴＲＵが、リソース上でＲＦ近傍検出信号の送信を開始するためにリソースの有効時間を決定することをさらに含む、実施形態１３に記載の方法。
１６． ＷＴＲＵが、測定構成を使用して、リソース上でＲＦ近傍検出信号の受信を開始するためにリソースの有効時間を決定することをさらに含む、実施形態１３に記載の方法。
１７． 発見要求を別のＷＴＲＵまたはネットワークに送って、サービスについての無線周波数（ＲＦ）近傍検出を行うために使用される発見プロセスを開始するように構成された送信機と、
発見応答についてチャネルを監視するように構成された受信機と
を備えた無線送受信ユニット（ＷＴＲＵ）。
１８． 発見要求は、少なくとも１つの発見アイデンティティを含む、実施形態１７に記載のＷＴＲＵ。
１９． 受信機は、デバイスツーデバイス（Ｄ２Ｄ）チャネルのための構成を受信するように構成される、実施形態１７〜１８のいずれか１つに記載のＷＴＲＵ。
２０． 発見要求は、ＷＴＲＵのセキュリティコンテキストまたはバッテリレベルに基づくステータスパラメータをさらに含む、実施形態１７〜１９のいずれか１つに記載のＷＴＲＵ。
２１． 発見要求は、発見要求が拒否された要求の反復であるかどうかを示すための一時発見プロセス識別子に対する参照をさらに含む、実施形態１７〜２０のいずれか１つに記載のＷＴＲＵ。

特徴および要素が特定の組み合わせで上記に説明されているが、各特徴または要素は、単独でまたは任意の他の特徴および要素との組み合わせで使用され得ることは、当業者には理解されよう。さらに、本明細書で説明された方法は、コンピュータまたはプロセッサによって実行するためのコンピュータ可読媒体内に組み込まれるコンピュータプログラム、ソフトウェアまたはファームウェアで実装され得る。コンピュータ可読媒体の例は、（有線接続または無線接続を介して送信される）電子信号、およびコンピュータ可読記憶媒体を含む。コンピュータ可読記憶媒体の例は、以下に限定されないが、ＲＯＭ、ＲＡＭ、レジスタ、キャッシュメモリ、半導体メモリデバイス、磁気媒体（例えば、内部ハードディスクまたはリムーバブルディスク）、光磁気媒体、およびコンパクトディスク（ＣＤ）またはデジタル多用途ディスク（ＤＶＤ）などの光媒体を含む。ソフトウェアに関連付けられたプロセッサが、ＷＴＲＵ、ＵＥ、端末、基地局、ノードＢ、ｅＮＢ、ＨＮＢ、ＨｅＮＢ、ＡＰ、ＲＮＣ、無線ルータ、または任意のホストコンピュータで使用するための無線周波数トランシーバを実装するために使用され得る。

Claims (20)

1. 無線送受信ユニット（ＷＴＲＵ）がデバイスツーデバイス（Ｄ２Ｄ）発見を行うための方法であって、
   前記ＷＴＲＵが、発見要求を別のＷＴＲＵまたはネットワークに送って、サービスについての無線周波数（ＲＦ）近傍検出を行うために使用される発見プロセスを開始することと、
   前記ＷＴＲＵが、発見応答についてチャネルを監視することと
   を含む方法。
2. 前記ＷＴＲＵは発見可能ステータスまたは監視ステータスを有する、請求項１の方法。
3. 前記ＷＴＲＵが、Ｄ２Ｄチャネルのための構成を受信することをさらに含む、請求項１の方法。
4. 前記ＷＴＲＵ内のアプリケーションが、サービス発見手順をトリガーすることをさらに含む、請求項１の方法。
5. 前記発見要求は、前記ＷＴＲＵのセキュリティコンテキストまたはバッテリレベルに基づくステータスパラメータをさらに含む、請求項１の方法。
6. 前記発見要求は、前記発見要求が拒否された要求の反復であるかどうかを示すための一時発見プロセス識別子に対する参照をさらに含む、請求項１の方法。
7. 前記ＷＴＲＵが、発見報告メッセージを前記別のＷＴＲＵまたは前記ネットワークに送ることをさらに含む、請求項１の方法。
8. 前記発見要求は、ＲＦ発見の最大範囲を示す電力クラスに関連付けられた発見クラスパラメータをさらに含む、請求項１の方法。
9. 前記発見要求は、公共サービスアプリケーションに対応するサービスに関連付けられた発見クラスパラメータをさらに含む、請求項１の方法。
10. 無線送受信ユニット（ＷＴＲＵ）がデバイスツーデバイス（Ｄ２Ｄ）発見を行うための方法であって、
    前記ＷＴＲＵが、別のＷＴＲＵまたはネットワークから無線周波数（ＲＦ）近傍検出のための構成を受信することであって、前記構成は、サービスに関連付けられ、発見プロセス識別子を含む、ことを含む方法。
11. ＲＦ近傍検出のための前記構成は、物理ダウンリンク共有チャネル（ＰＤＳＣＨ）を介して専用シグナリングによって受信される、請求項１０の方法。
12. ＲＦ近傍検出のための前記構成は、発見共有チャネル（ＤＩＳＣＨ）上で受信される、請求項１０の方法。
13. ＲＦ近傍検出構成に関連付けられた少なくとも１つのサービスアイデンティティ、有効性情報、および測定構成を、前記ＤＩＳＣＨを介して受信することをさらに含む、請求項１２の方法。
14. 前記少なくとも１つのサービスアイデンティティ、前記有効性情報および前記測定構成を含む送信が、特定の無線ネットワーク一時アイデンティティ（ＲＮＴＩ）およびサブフレームタイミングを使用して物理ダウンリンク共有チャネル（ＰＤＳＣＨ）によってスケジューリングされる、請求項１３の方法。
15. 前記ＷＴＲＵが、リソース上でＲＦ近傍検出信号の送信を開始するために前記リソースの有効時間を決定することをさらに含む、請求項１３の方法。
16. 前記ＷＴＲＵが、前記測定構成を使用して、リソース上でＲＦ近傍検出信号の受信を開始するために前記リソースの有効時間を決定することをさらに含む、請求項１３の方法。
17. 発見要求を別のＷＴＲＵまたはネットワークに送って、サービスについての無線周波数（ＲＦ）近傍検出を行うために使用される発見プロセスを開始するように構成された送信機であって、前記発見要求は少なくとも１つの発見アイデンティティを含む、送信機と、
    発見応答についてチャネルを監視するように構成された受信機と
    を備えたＷＴＲＵ。
18. 前記受信機は、デバイスツーデバイス（Ｄ２Ｄ）チャネルのための構成を受信するように構成される、請求項１７のＷＴＲＵ。
19. 前記発見要求は、前記ＷＴＲＵのセキュリティコンテキストまたはバッテリレベルに基づくステータスパラメータをさらに含む、請求項１７のＷＴＲＵ。
20. 前記発見要求は、前記発見要求が拒否された要求の反復であるかどうかを示すための一時発見プロセス識別子に対する参照をさらに含む、請求項１７のＷＴＲＵ。