JP2016522639A - 通信ネットワークにおけるデバイス−デバイス間通信に関するデバイス発見方法、ユーザ機器デバイスおよびコンピュータプログラム製品 - Google Patents

Abstract

通信ネットワークにおけるデバイス−デバイス間通信のためのデバイス発見方法であって、第１のデバイスから、第１のデバイスにリンクされた第１の近接サービス識別子を含む発見要求を、第２のデバイスにおいて直接的に受信するために近接サービス発見チャネルを用いて送信するステップと、第１のデバイスにおいて、近接サービス発見チャネルを通じて、直接的に第２のデバイスから、第２のデバイスにリンクされた第２の近接サービス識別子を含む発見要求に対する応答を受信するステップとを含む、方法が提供される。

Description

例示的な実施形態は、概してワイヤレス通信システムに関し、より詳細にはデバイス−デバイス間の発見および通信に関する。

近年では、より高いデータレートとシステム容量とをエンドユーザおよびネットワークオペレータにもたらす次世代ワイヤレス通信システムの開発に主な努力が払われてきた。このような次世代システムの例は３ＧＰＰロングタームエボリューション（ＬＴＥ：Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）およびＷｉＭＡＸである。

データレートの上昇およびサービスエリアの改善等の典型的な性能の目的に加えて、次世代ワイヤレス通信システムはエンドユーザのための新規サービスも可能にする。

例えば、２つの隣接するデバイス間で基地局を介することなく直接データ送信および受信を実行する通信方法である、デバイス−デバイス間通信（これ以降、Ｄ２Ｄ通信とも呼ぶ）の形態の直接接続性のサービスが注目されている。

このようなデバイス−デバイス間通信の効率的な利用について、複数の使用事例が存在する。例えばデバイスは、サービス提供セルにアクセスして電話接続を実行でき、既存のセルラーリンクを用いてインターネットにアクセスでき、同時に例えばＤ２Ｄ通信リンクで動作中の例えばローカルメディアサーバまたは他のデバイスとの間で、大量のデータを直接的に送信および受信することも可能である。

ＴＳ２３．４０１、図４．２．１−１、「３ＧＰＰアクセスのための非ローミングアーキテクチャ（Ｎｏｎ−ｒｏａｍｉｎｇ ａｒｃｈｉｔｅｃｔｕｒｅ ｆｏｒ ３ＧＰＰ ａｃｃｅｓｓｅｓ）」

一態様によれば、通信ネットワークにおけるデバイス−デバイス間通信に関するデバイス発見方法であって、第１のデバイスから、第１のデバイスにリンクされた第１の近接サービス識別子を含む発見要求を、第２のデバイスにおいて直接的に受信するために近接サービス発見チャネルを用いて送信するステップと、第１のデバイスにおいて、近接サービス発見チャネルを通じて、直接的に第２のデバイスから、第２のデバイスにリンクされた第２の近接サービス識別子を含む発見要求に対する応答を受信するステップとを含む、方法が提供される。

デバイスにリンクされた近接サービス識別子が、通信ネットワークへのデバイスのアタッチのポイントでそのデバイスに提供されてよく、またはそのデバイスに対して事前構成される。発見要求をデバイスのグループにアドレス指定してよい。デバイスを、デバイスアプリケーションに関連する特定のグループ識別子に関連付けてよい。デバイスを、複数のデバイスアプリケーションに関連する複数のグループ識別子に関連付けてよい。方法は、第１のデバイスと第２のデバイスとの間の直接通信リンクを確立するステップを更に含んでよい。

方法は、第１のデバイスから、第１の近接サービス識別子を含み、かつ第２の近接サービス識別子を要求用のアドレスとして用いるデバイス−デバイス間通信要求を送信するステップと、第２のデバイスから、第２の近接サービス識別子を含む肯定応答を、肯定応答用のアドレスとして第１の近接サービス識別子を用いて第１のデバイスへと送信することにより、第１のデバイスの要求を肯定応答するステップとを更に含んでよい。

デバイス−デバイス間通信のために、第１のデバイスおよび第２のデバイスのうちの１つまたは両方から、デバイスに関連付けられたネットワークのそれぞれの基地局へと承認要求を送信してよく、承認要求がデバイスの通信ネットワークサービスエリアを表すデータを含む。

基地局からモビリティ管理エンティティへと承認要求を送信してよく、デバイス−デバイス間通信を承認してよい。デバイス−デバイス間通信の承認が、デバイス間の通信を調整するための、送信パラメータのセットを提供するステップを含んでよい。送信パラメータが、デバイス−デバイス間通信をセキュリティ保護するためにデバイスが使用するための暗号化データ、ならびに／または周波数および／もしくはパワー範囲もしくは動作の最大パワーレベルに関するデータを含んでよい。送信パラメータが、デバイス−デバイス間送信用に許可されたデータ量割り当てを表すデータを含んでよい。

一態様によれば、通信ネットワークにおけるデバイス−デバイス間通信のための方法であって、目標を定めたまたは目標を定めない検出処理を用いてネットワーク内の潜在的なピアのセットを発見するステップと、デバイス−デバイス間通信を承認するためのハンドシェイクを実行するために、セット内のデバイスとのリンクを確立するステップと、ハンドシェイクに基づいて、直接的にデバイスと通信するステップとを含む、方法が提供される。

一態様によれば、上述の方法に従って動作可能なユーザ機器デバイスが提供される。

一態様によれば、コンピュータ可読プログラムコードを組み込んだコンピュータが使用可能な媒体を含む、コンピュータプログラム製品であって、前記コンピュータ可読プログラムコードは、上述の方法において提供されるような通信ネットワークにおけるデバイス−デバイス間通信に関するデバイス発見のための方法を実装するために実行されるように構成される、コンピュータプログラム製品が提供される。

実施形態は、例としてのみ添付の図面を参照して説明されるであろう。

ワイヤレスセルラーネットワークの概略ブロック図である。 図１で示されるようなセルラー通信ネットワークに基づいたデバイス−デバイス間通信を示す概略ブロック図である。 対のデバイス間の目標を定めた発見処理に関する例示的なメッセージの流れの概略図である。 対のデバイス間の目標を定めない発見処理に関する例示的なメッセージの流れの概略図である。 対のデバイス間の例示的なメッセージの流れの概略図である。 対のデバイス間の更なる例示的なメッセージの流れの概略図である。 対のデバイス間の更なる例示的なメッセージの流れの概略図である。 直接通信の確立に関するアーキテクチャの概略図である。

本明細書に記載のシステムおよび処理を当業者が実施および実装できるように、例示的な実施形態を十分詳細に以下に説明する。実施形態は多数の代替の形態で提供することができ、本明細書に記述する例に限定されるものと解釈されるべきではないことを理解することが重要である。

したがって実施形態は様々な方法で修正でき、様々な代替の形態で実施できるが、例として特定の実施形態を図面に示し、以下で詳細に説明する。開示される特定の形態に限定するという意図はない。反対に、添付の請求項の範囲に当てはまる全ての修正例、均等物および代替物が含まれるべきである。例示的な実施形態の要素は、必要に応じて図面および詳細な説明を通して同じ参照番号で一貫して表される。

実施形態を説明するために本明細書中で使用される用語は、範囲を限定することを意図したものではない。冠詞「ａ」、「ａｎ」および「ｔｈｅ」は、単一の指示対象を有するという点で単数であるが、本文書での単数形の使用は、２つ以上の指示対象の存在を排除するものではない。換言すると、単数で言及された要素は、文脈がそうでないことを明示しない限りは１つまたは複数の数であり得る。用語「を備える（ｃｏｍｐｒｉｓｅ）」、「を備えている（ｃｏｍｐｒｉｓｉｎｇ）」、「を含む（ｉｎｃｌｕｄｅ）」および／または「を含んでいる（ｉｎｃｌｕｄｉｎｇ）」は、本明細書で使用される際、言及された特徴、項目、ステップ、操作、要素および／または構成要素の存在を特定するが、１つまたは複数の他の特徴、項目、ステップ、操作、要素、構成要素、および／もしくはこれらのグループの存在または追加を排除するものではないことが更に理解されるであろう。

そうでないことが定義されない限り、本明細書で使用される（技術的なおよび科学的な用語を含む）全ての用語は、当技術分野において慣例であるように解釈されるべきである。通常使用される用語もまた、関連する技術分野において慣例であるように解釈されるべきであり、本明細書中でそのように明白に定義されない限り、理想化されたり過度に形式的な意味で解釈されたりするべきではないことも更に理解されるであろう。

本明細書で使用されるデバイスは、デバイス、端末（ｔｅｒｍｉｎａｌ）、移動局（ＭＳ：ｍｏｂｉｌｅ ｓｔａｔｉｏｎ）、ユーザ機器（ＵＥ：ｕｓｅｒ ｅｑｕｉｐｍｅｎｔ）、ユーザ端末（ＵＴ：ｕｓｅｒ ｔｅｒｍｉｎａｌ）、ワイヤレス端末、アクセス端末（ＡＴ：ａｃｃｅｓｓ ｔｅｒｍｉｎａｌ）、端末（ａ ｔｅｒｍｉｎａｌ）、加入者ユニット、加入者局（ＳＳ：ｓｕｂｓｃｒｉｂｅｒ ｓｔａｔｉｏｎ）、ワイヤレスデバイス、ワイヤレス通信デバイス、ワイヤレス送信／受信ユニット（ＷＴＲＵ：ｗｉｒｅｌｅｓｓ ｔｒａｎｓｍｉｔ／ｒｅｃｅｉｖｅ ｕｎｉｔ）、移動ノード、移動体（ｍｏｂｉｌｅ）、または他の用語として呼ばれることもある。デバイスの様々な実施形態は、携帯電話、ワイヤレス通信機能を有するスマートフォン、ワイヤレス通信機能を有する携帯情報端末（ＰＤＡ：ｐｅｒｓｏｎａｌ ｄｉｇｉｔａｌ ａｓｓｉｓｔａｎｔ）、ワイヤレスモデム、ワイヤレス通信機能を有するポータブルコンピュータ、ワイヤレス通信機能を有するデジタルカメラ等のキャプチャリングデバイス、ワイヤレス通信機能を有するゲームデバイス、ワイヤレス通信機能を有する音楽記憶再生機器、ワイヤレスインターネットアクセスおよびブラウジングを可能にするインターネット機器、ならびに機能の組み合わせを有する端末またはポータブルユニットを含むことができる。他の代替物も可能である。

本明細書で使用される基地局は、一般的には固定されているか、または端末もしくはデバイスと通信するために移動される通信ネットワークの一部であり、かつ基地局、ノード−Ｂ、ｅＮｏｄｅ−Ｂ、基地局システム（ｂａｓｅ ｔｒａｎｓｃｅｉｖｅｒ ｓｙｓｔｅｍ）、アクセスポイント、リレー、フェムトセル等についての集合名を示す用語であり得る。

図１は、進化型Ｎｏｄｅ Ｂ（ｅＮＢ）または基地局（ＢＳ）１０３と、デバイス（ユーザ機器（デバイス）または移動局（ＭＳ））１０６、１０８、１１０とを含む、例示的な実施形態によるワイヤレスセルラーネットワーク１０１の概略ブロック図である。各デバイス１０６、１０８、１１０は、ＢＳ１０３に関連付けることができ、データを上りリンク方向に送信し、ＢＳ１０３から下りリンク方向でデータを受信できる。ただ１つのＢＳ１０３と３つの移動デバイス（１０６、１０８および１１０）とが示されているが、複数の基地局とデバイスとをネットワーク１０１に設けてよいことを理解されたい。

図２は、図１で示されるようなセルラー通信ネットワークに基づいたデバイス−デバイス間通信を示す概略ブロック図である。セルラー通信ネットワーク１０１は、第１の基地局１０３と第２の基地局２０５とを含む。第１の基地局１０３のセル２１１内の第１から第３のデバイス２０１、２０２および２０３は、第１の基地局の典型的なアクセスリンク（セルラーリンク）を介して通信できる。第１の基地局のセル１１１内の第４のデバイス２０４および第５のデバイス２１５は、基地局１０３を介さずに互いとのデータ送信および受信を直接的に実行し、よってＤ２Ｄ通信モードで動作しており、このＤ２Ｄ通信モードは、一般にネットワークとセルラーおよびデータ通信が可能であるようなデバイスの通常動作への追加機能であってよい。

Ｄ２Ｄリンクは、同じサービス提供セルを有するデバイス間であってよいが、異なるサービス提供セルを有するデバイス間であってもよい。例えば、第１の基地局１０３のセル２１１内の第３のデバイス２０３は、Ｄ２Ｄ通信でネットワーク１０１の第２の基地局２０５のセル２２１内の第６の端末２０６と交流できる等である。

Ｄ２Ｄ通信リンクをセットアップするために、デバイスは、（無線サービスエリア内の）通信したい別のデバイスの存在を知る必要がある。したがって、通信が承認されて開始される前に発見が発生する。

例示的な実施形態によれば、直接的発見は、２つのデバイスが、無線通信層においておよびネットワークのいずれの中継ノードの補助なしで、互いの「存在」および直接的到達可能性を検出する処理である。

潜在的な直接通信ピアを−目標を定めておよび目標を定めずに−発見できる別の方法も存在する。例示的な実施形態によれば、目標を定めた発見は、発見を可能にするためにおよびデバイスが発見されることを可能にするために、グループのメンバーシップ／（承認された）アプリケーションの使用を使用する。したがって、ピアの発見に関心があるパーティは、潜在的な発見目標をどのように識別するかを既に知っているので、これらのエンティティのみを目標を定めた発見処理の一部として発見しようとする。

第２の種類の発見−目標を定めない発見−では、特定のグループへのメンバーシップ／特定のアプリケーションの使用は、発見のためのおよびデバイスが発見されることを可能にするための要件ではない。したがって、ピアの発見に関心があるパーティは典型的には、任意の潜在的に利用可能な通信ピアの検出と、これらが提供するサービスおよび通信可能性の発見とに関心があることになる。この発見のトリガに特定のアプリケーションは必要でない（例えばユーザは一般的な発見をトリガできる）。

目標を定めた発見は、例えば公共安全（ＰＳ：ｐｕｂｌｉｃ ｓａｆｅｔｙ）の領域等の、特定の状況においておよび特定のユーザにとって特に価値のあるものであり得る。このような場合、公共安全エージェントは、ＰＳリレーを発見するために目標を定めた発見を使用してよい。他の例は以下を含む：

自身のデバイスからビデオフィードを送信するためのピアエージェントデバイスを発見する公共安全エージェント。

（許可範囲により決定される）エージェントの近傍で発見される特定アプリケーションのユーザ。

目標を定めない発見の場合、例えばパーティはいずれの利用可能な（許可範囲により決定される）近くの直接通信ピアを発見するか、または（許可範囲により決定される）近くの近接サービス（ＰｒｏＳＥ：ｐｒｏｘｉｍｉｔｙ ｓｅｒｖｉｃｅ）リレーを発見することができる。他の使用が可能であり、上記は目標を定めた発見および目標を定めない発見に関する例示的な状況として単に提供されるものである。

上述のように、目標を定めた発見は、特定の潜在的なアプリケーションピアグループのいずれのメンバーが関心のあるパーティの近傍に位置するかどうかを見つけるための、「メンバーの探索」として考えることができる。これは、例えば関心のあるパーティのデバイスの無線範囲内、またはユーザのデバイスの一定の半径内であり得るユーザ特定のもしくは所定の範囲内であってよい。目標を定めない発見にも同じことを当てはめることができ、発見はデバイスの無線範囲を通じて、または例えば特定のもしくは所定の範囲を通じて実行できる。

例示的な実施形態によれば、目標を定めた発見について：

１） 発見デバイスは、システムにより発見することを承認される。

２） 発見可能なデバイスは、発見処理に関与することを承認される。

３） 目標を定めた発見を開始するデバイスは、デバイスグループに関連付けられ、かつ特定のデバイスアプリケーションに関連する識別子（グループＩＤ）用いること等によって、どのように発見可能なデバイスのグループをアドレス指定するかを知っている。例えばグループ識別子を発見要求の送信のためのアドレスとして用いて発見要求をデバイスのグループへとアドレス指定できる。

４） グループメンバーシップを秘密鍵により検証できる。重複するグループＩＤが存在し得るが、例えば秘密を共有したアプリケーション層を介してフィルタリングを実行できる。例示的な実施形態によれば、目標を定めた発見に関与するデバイスは、グループメンバーの相互認証のチャレンジ／応答方法をサポートできる。

５） ＰｒｏＳＥに使用されるデバイス識別子は、典型的にはデバイス加入者識別子を明かすことはない。この識別子は例えば、直接通信アドレスに対して解決可能（またはこれと同じ）であってよい。この識別子は例えば、アプリケーションについて独立であり、３ＧＰＰ層により提供される（例えばアタッチ時においておよびＭＭ手順を介してリフレッシュできる）か、またはこれは、例えば、製造業者によりデバイス内に構成されるかもしくは利用可能なネットワークがない場合はＩＭＥＩ ＳＶから導入されることができる。

６） ユーザのアプリケーション層識別子は、更なる通信の関心を決定するためにデバイスＰｒｏＳＥ識別子（近接サービス識別子）に連結させてよいが、これは全ての可能なアプリケーションに必要なわけではない。
なお、ダイナミックグループメンバーシップまたはダイナミック承認に関連する態様を除いて、デバイスがネットワークサービスエリア内に存在するかまたは外に存在するかについて論理シーケンスに実際の論理差はないことに注意されたい。無線層手順は変更してよい。

図３は、ＵＥ ＡおよびＵＥ Ｂの対のデバイス間の目標を定めた発見処理に関する例示的なメッセージの流れの概略図である。

デバイスがネットワークサービスエリア内に存在する場合、例えばアタッチ時に、近接サービス識別子（Ｐｒｏｓｅ ＩＤ）がネットワークにより提供され、近接サービスの暗黙の承認を提供する。ＭＭ手順の一部としてデバイスまたはネットワーク要求時にこれを更新してよい。一例によれば、ｐｒｏｓｅ ＩＤは例えば、ＩＤが近接サービスに関して全体で唯一の識別子であるように、デバイスに関連付けられた電話番号、またはデバイスＩＭＥＩであってよい。他の代替物が可能であることも理解されるだろう。

あるいは、ｐｒｏｓｅ ＩＤはデバイスに対して事前構成してよい。即ち、デバイスは例えば、ＩＤ取得のためにネットワークアタッチメントが要求されないように、事前記憶されたまたは事前提供されたＩＤを有してよい。これは例えば、ネットワークサービスエリア内に存在しない場合またはネットワークがダウンしている場合等に、公共安全の職員がＤ２Ｄ通信を開始する必要があるような状況において有用であり得る。

なお、デバイスがＰＬＭＮサービスエリア内の発見のためにブロードキャストチャネルで送信できるように、デバイスはネットワークからスケジューリング許可を取得する必要があるので、デバイスが位置するサービスエリア領域内の発見を暗黙で承認することに注意されたい。ネットワークの不在時、公共安全デバイスは、件のアプリケーションが承認を要求する場合に発見するおよび発見されるための承認を有すると想定される。

いくつかのアプリケーションについては、目標を定めた発見フェーズで交換されるＰｒｏｓｅ ＩＤおよびデバイス属性は、例えばネットワークが存在せず、ｐｒｏｓｅ ＩＤをセキュアにアプリケーション層識別子に関連付けることができない時等、関心の関係の近傍に入るには十分でないことがある。したがって、２つのエンティティは、アプリケーションに固有のユーザプレーンの対話を介して更なる関心を測定する必要があり得る。したがって、アプリケーション層の関心は、３ＧＰＰ層で検出された関心と異なり得る。

例示的な実施形態によれば、デバイスは例えば、ユーザ設定とデバイス内のアプリケーションステータスおよび設定とに基づいて、またはオペレータが決定した設定に基づいて、グループ、グループのセットまたは全てのグループに関する目標を定めた発見要求に対する応答を停止するための対策を含んでよい。デバイスは例えば、特定の場所における、または特定のネットワークセル内のデバイスからの、目標を定めた発見要求に対する応答を限定するまたは停止するための対策も含むことができる。目標を定めない発見の場合にも同じ考察が適用される。

チャレンジ機構は、応答主が特定の関心のグループに属するかどうか、およびこれらのグループの信頼できるメンバーであるかどうかを決定するために、デバイスがチャレンジを送信することを許可する。例示的な実施形態によれば、チャレンジに対する応答は、応答主のＰｒｏＳｅ ＩＤとチャレンジ自体とに関連している。デバイスは典型的には、チャレンジに対して２回以上応答しないので、チャレンジ中のデバイスはチャレンジに対して最大１つの応答を承諾することになるので不可能である場合、応答に基づくアタックは極めて見込みが薄い。

目標を定めた発見手順の最後に、発見デバイスは、発見されたデバイスのｐｒｏｓｅ ＩＤと件のグループに関するデバイス属性とを得る。属性は例えば、デバイスが特定のアプリケーションに関してＰｒｏＳｅリレーとして機能できるかどうかを含むことができる。よってこれは直接通信に使用してよい。

図３を参照すると、目標を定めた発見処理に関して、件のデバイス、ＵＥ ＡおよびＵＥ Ｂは、アプリケーショングループに関連付けられた唯一の識別子と共有の秘密とを有する同じアプリケーショングループに属すると想定できる。即ち、デバイスが、デバイスアプリケーションに関連する特定のグループ識別子に関連付けられる。また、同じ識別子を共有するいずれの他のデバイスも、同じアプリケーショングループに属することになり、このようなデバイスは、したがって、前記アプリケーションを使用するか、または使用できる。デバイスを複数のグループに関連付けることができる。

３０１において、デバイスＵＥ ＡおよびＵＥ Ｂは、電源オンであり、ネットワークから近接サービスに関する識別子を取得する。即ち、ｐｒｏｓｅ ＩＤはアタッチメント時にデバイスに提供される。あるいは上述したように、デバイスがネットワークサービスエリア内に存在しない可能性がある場合に、識別子をデバイスに対して事前構成することもできる。ネットワークサービスエリアが存在しないことがあるという事実は、ネットワーク１０１を破線で示すことにより、図３に示されている。よって任意の処理ステップは、図３および他の図面において破線で示されている。

ステップ３０１において、デバイス３０３、３０５に、デバイス上にインストールされたおよび／またはデバイス上で動作可能なアプリケーションに関連するグループＩＤも提供される。

アプリケーションサーバ３０７をネットワーク１０１の一部として、図３のステップ３０９でデバイス３０３、３０５について示されるようなアプリケーション登録のために使用することができる。アプリケーションサーバ３０７への登録において、ユーザプレーンを介して等、デバイス３０３、３０５は例えば、自身のｐｒｏｓｅ ＩＤおよび近接サービスステータス、ならびに近接サービス設定を、デバイスが認識しているもしくはデバイスが発見したか、接続したか、もしくは過去に通信した任意のまたはそれぞれのピアデバイスに提供する。

上述のステップは広く、ｐｒｏｓｅ登録処理３１１を形成する。登録に続いて、発見処理を図３に示すように進行させることができる。より詳細には、ステップ１において、ＵＥ ＡはアドレスとしてグループＩＤを用いて発見要求を送信する。要求はＵＥ Ａにリンクされた第１の近接サービス識別子を含み、デバイスの近接サービス発見チャネルを用いて要求を送信できる。

ステップ２において、ＵＥ Ｂによる受信に続いて、ＵＥ ＢからＵＥ Ａへとチャネルを通じておよびｐｒｏｓｅ ＩＤ Ａを送信用のアドレスとして用いて応答が送信され、次いでこの送信はＩＤ Ｂをアドレスとして用いてＵＥ Ａにより肯定応答される。その結果、ＵＥ ＡはＵＥ Ｂを、目的を定めた様式で発見する。より詳細には、グループＩＤをアドレスとして用いたブロードキャストにより、件のグループのメンバーであるかまたはそうでなければ件のグループに関連付けられたデバイスは、アプリケーションがインストールまたは使用されることにより、目標を定めた形式で同じ理由でグループのメンバーである他のデバイスを発見することが可能になる。よって以下でより詳細に説明するように、ＵＥ ＡとＵＥ Ｂとの間の通信が続くことができる。

図４は、ＵＥ ＡおよびＵＥ Ｂの対のデバイス間の目標を定めない発見処理に関する例示的なメッセージの流れの概略図である。

目標を定めない発見プロトコル下のデバイスからの送信は、例えば無線通信範囲等において潜在的なアプリケーションピアのどの種類がデバイスの近傍にあるかを見つけるための「ハロー（ｈｅｌｌｏ）」タイプのメッセージであると考えることができる。上述したような、目標を定めた発見および／または直接通信はこれに続くことができる。

例示的な実施形態によれば、目標を定めない発見は、以下を仮定する：

１） 発見デバイスは、システムにより発見することを承認される。

２） 発見可能なデバイスは、発見に関与することを承認される。

３） 目標を定めない発見を開始するデバイスは、周囲に何があるかを発見することにのみ関心がある。

４） 発見の一部として応答で受信した情報を認証するまたは検証することは意図されていない。

５） 近接サービスに使用されるデバイス識別子（Ｐｒｏｓｅ ＩＤ）は、デバイス加入者識別子を明かすことはない。この識別子は、直接通信アドレスについて解決可能（またはこれと同じ）であり、例えばアプリケーションについて独立であり、かつアタッチ時等において３ＧＰＰ層により提供されるものであり、およびＭＭ手順を介してリフレッシュできる。あるいは、ネットワークサービスエリアの不在時の目標を定めた発見の場合と同様に例えばネットワークが利用可能でない場合、製造業者によりデバイス内に事前構成もしくは事前提供されるか、またはＩＭＥＩ ＳＶから導入されることができる。

６） アプリケーションとユーザ設定および選好とは、デバイスが目標を定めない発見に対して応答するかどうか、および応答する場合には、デバイスが開示しようとしているアプリケーショングループを明かすかどうかを決定する。

例示的な実施形態によれば、デバイスがネットワークサービスエリア下の発見チャネルを通じてブロードキャストすることを承認されると、オペレータは発見のためにデバイスによる近接サービス利用を制御できる。デバイスは、ユーザ選好またはオペレータ設定に基づいて、目標を定めない発見要求への応答を停止できる。目標を定めない発見手順の最後に、デバイスは、デバイスのｐｒｏｓｅ ＩＤ、開示されたグループメンバーシップおよびこれらのグループに関するデバイス属性を得る。属性は例えば、ＵＥが特定のアプリケーションに関してＰｒｏＳｅリレーとして機能できるかどうかを含むことができる。これは続く目標を定めた発見または直接通信に使用してよい。

図４を参照すると、処理は図３を参照して説明したものと同様である。なお、しかしながら、グループＩＤを発見要求のためのアドレスとして使用する代わりに、ステップ４０２におけるＵＥ Ａ４０１からの要求は、アドレスとしてエニーキャストＩＤを用いて近接サービス発見ブロードキャストチャネルを通じて送信される。ステップ４０３においてＵＥ Ｂ４０４から送信される応答は、発見ブロードキャストチャネルを用いて、アドレスとしてＵＥ Ａの無線リンク層アドレスを用いて送信される。図３を参照して述べたように、処理はネットワーク１０１のサービスエリアを用いてまたは用いずに進行する。

したがって、ＵＥ Ａ４０１はＵＥ Ｂ４０４を発見し、ＵＥ Ｂ４０４によりサポートされるグループを知る。ＵＥ Ａ４０１は、続いて目標を定めた発見または直接通信を開始してよい。

２つのデバイスは上述のように互いを発見すると、直接送信のためのピア−ピア間（ｐ２ｐ）リンクを確立できる。例示的な実施形態によれば、以下で説明される処理は、１つまたは複数のデバイスがネットワークサービスエリアの内または外に存在する時、動作できる。リンク確立におけるオペレータおよびアプリケーションレベルの制御、ならびにデータ量補強も提供される。

例示的な実施形態によれば、間のデータリンクの確立は、通信確立について、関与するエンティティ（デバイスおよびサービスエリア内の場合はｅＮＢ）に指示することを必要とする。これは、デバイスがネットワークサービスエリア下に存在する時と、例えば公共安全の場合に有用であり得るネットワークサービスエリアの外に存在する時との両方で機能する。

ネットワークサービスエリア下では、通信に関与するｅＮＢ（デバイスが手順を開始した際にデバイスがＲＲＣ接続状態に入っているｅＮＢ）は、通信を承認およびセットアップすることに関与する。

図５は、ＵＥ ＡがＵＥ Ｂを発見し、デバイスが同じグループに属し、かつ秘密を共有している場合の、ＵＥ Ａ５０１およびＵＥ Ｂ５０２の対のデバイスと、対応するｅＮＢ５０３、５０４と、ＭＭＥ５０５、５０６と、アプリケーションサーバ５０７との間の例示的なメッセージの流れの概略図である。

ネットワークが利用可能でない場合に省略できるステップは、破線で示されたエンティティに関して示されている。ステップ１において通信を開始するデバイス５０１は、ＭＭＥ５０５には、ネットワークによりデバイスに割り当てられたＰｒｏＳｅ ＩＤを用いて、通信承認を求める（場合によってはアプリケーション層でも）デバイスのように見える。デバイスが帰属するＭＭＥをｅＮＢが解決することができるように、Ｐｒｏｓｅ ＩＤは典型的には暗黙でデバイスが帰属するＭＭＥを識別する。

ＭＭＥがアプリケーション層の承認のために任意で確認する必要がある、およびデータ量割り当てを取得する可能性があるＩＰアドレスまたはサーバ名は、デバイスにより提供される（別のオプションは、ビジネス上の同意に基づいて、例えば単にグループＩＤの同意に基づいて、ＭＭＥによりアプリケーション名を正しいＩＰアドレスへと解決することである）。アプリケーションサーバ５０７は、上述したような登録機構を介して２つのデバイス５０１、５０２について入手可能な現在のＰｒｏｓｅ ＩＤを有すると想定される。

「サービスエリア内示唆フラグ」は、２つのパーティのうちのどちらがサービスエリア内に存在するかを示す。図５に示した場合では、両方のデバイスはもう一方に自身がサービスエリア内に存在することを知らせるので、これらのフラグは真（ｔｒｕｅ）または何らかの他の好適な値に設定される。

なお、通信承認のためのメッセージ（ステップ４）は、通信要求のイニシエータのＰｒｏｓｅ ＩＤと、「コールされる（ｃａｌｌｅｄ）」パーティのｐｒｏｓｅ ＩＤとを含む。サービスエリア内示唆フラグは、コールされるおよびコールしているパーティがサービスエリア内に存在するかどうかに関する情報をネットワークに提供する。

図５に示されるメッセージの流れにおいて、上述のように、両方のパーティがサービスエリア内に存在する場合、破線のエンティティを伴うステップが適用される。そうでなければデバイスはネットワークサービスエリアの外に存在する場合、破線のエンティティを伴うステップは適用されない。

コールしているパーティ５０１のＭＭＥ５０５は、コールしているパーティがサービスエリア内に存在する場合、承認を求めることを担当する。そうでなければ、これはこのステップを実行するために動作できるのは、コールされるパーティのＭＭＥ５０６ということになる。どちらのデバイスもサービスエリア内に存在しない場合、承認ステップは行われず、例えば公共安全デバイスの場合等の、ネットワークサービスエリア外の直接通信のためのローカルの承認が想定される。

なお両方のデバイスがネットワークサービスエリア下に存在する場合、アプリケーションから承認を得るＭＭＥ５０５は、他のデバイス５０２のＭＭＥ５０６に接触することに注意されたい。

したがって、ＭＭＥ−Ａ５０５は、直接通信を確立するための承認を得て、任意選択で両方のパーティのためのデータ量割り当てを交渉できる。例えば、ステップ５、６および８で述べるように、通信中のデバイス間のデータ送信量についての割り当てを提供するために送信パラメータを提供できる。ステップ１０では、５０１と５０２との間の直接通信が提供される。パーティ間の送信をセキュリティ保護するための任意の知られた暗号化技術を用いた共有の秘密を用いてセキュリティ保護することができる専用のチャネルでデータはデバイス間で送信される。共有の秘密は、例えば送信パラメータの一部としてネットワークにより提供されてよく、または事前構成されたもしくは事前提供された秘密であってよい。どちらの場合でも、典型的なように通信の現行のセキュリティを可能にするためにパーティについて秘密を周期的にリフレッシュできる。

コールしているパーティのデバイス５０１がサービスエリア下に存在しない時、コールされたパーティのＭＭＥ５０６およびｅＮＢ５０４は（異なる場合）、図６に示すように承認の要求を担当し、図６は、ＵＥ ＡがＵＥ Ｂを発見し、デバイスが同じグループに属し、かつ秘密を共有しており、ならびにＵＥ Ａがサービスエリア内に存在しない場合の、ＵＥ Ａ６０１およびＵＥ Ｂ６０２の対のデバイスと、対応するｅＮＢ６０３、６０４と、ＭＭＥ６０５、６０６と、アプリケーションサーバ６０７との間の例示的なメッセージの流れの概略図である。

例えばステップ３−６を参照すると、サービスエリア内フラグの内容に基づいて、ＭＭＥ−Ｂ６０６は承認情報を提供するのにＭＭＥ−Ａ６０５を待機しない。代わりに、ＭＭＥ−Ｂ６０６は、直接通信を確立するための承認を得て、任意選択でデータ量割り当てをアプリケーションサーバ６０７から直接的に得ることができる。

逆に、コールしているパーティがサービスエリア内に存在する時、コールしているパーティのＭＭＥおよびｅＮＢは（異なる場合）、図７に示すように通信承認およびセットアップに関与することになり、図７は、ＵＥ ＡがＵＥ Ｂを発見し、デバイスが同じグループに属し、かつ秘密を共有しており、ならびにＵＥ Ｂがサービスエリア内に存在しない場合の、ＵＥ Ａ７０１およびＵＥ Ｂ７０２の対のデバイスと、対応するｅＮＢ７０３、７０４と、ＭＭＥ７０５、７０６と、アプリケーションサーバ７０７との間の例示的なメッセージの流れの概略図である。

ＭＭＥ−Ａ７０５は、直接通信を確立するための承認を得て、任意選択でデータ量割り当てをアプリケーションサーバ７０７から直接的に得ることができる。例えばステップ３−６を参照して、サービスエリア内フラグの内容に基づいて、ＭＭＥ−Ａ７０５はＭＭＥ−Ｂ７０６に接触しない。

上述のように、２つのデバイスが最終的に通信を承認された時、１つまたは複数のｅＮＢは、１つまたは複数のＭＭＥから、（例えば秘密鍵、周波数、パワー範囲等を含む）任意選択の送信パラメータ構成を受信する。ネットワークサービスエリアが存在しない時、この送信パラメータ構成はデバイス内に事前構成されていると想定される。

更に、リンク層の暗号化がネットワークサービスエリア外で利用可能でない場合にアプリケーション層の暗号化を適用してよい。いくつかの送信パラメータもｅＮＢに適用する。

図５を参照すると、ステップ１０において、直接通信が開始される。このフェーズの間、デバイス５０２がリレーとして機能しデバイス５０１がリレーでないという場合でない限り（この場合ＩＰアドレスはデバイス５０２により割り当てられてよい）、デバイス５０１はリンクに対するＩＰアドレス割り当て用のＤＨＣＰサーバとして機能することができる。また、手順全体を通して、無線ネットワークノードは最適な送信のために例えばＸ２を介して協働してよい。

図８は、直接通信の確立に関するアーキテクチャの概略図である。

クライアントデバイス８０１は近接サービスアプリケーション８０２を含む。デバイス８０１のネットワークへのアタッチメントの結果、またはデバイスが全体で唯一である識別子を用いて事前構成されている故に、近接サービス識別子８０６はデバイス８０１にリンクされている。

アプリケーションサーバへのユーザプレーン経路は任意選択であり、上述したように主としてアプリケーション登録のために使用される。ＭＭＥ８０４とｐｒｏｓｅアプリケーション８０５との間の直接的論理インターフェースとしてｐｒｏｓｅ承認インターフェース８０３が示されているが、原則としてＳ１１−Ｓ５経路は例えばＰＣＲＦ Ｒｘインターフェースを介してアプリケーション対話を仲介してよく、ＰＣＲＦ Ｒｘインターフェースは、簡略化のために図面には示されていない、Ｇｘインターフェースを介してＰＧＷへとリンクされたエンティティであるが、仕様書ＴＳ２３．４０１の図４．２．１−１：「３ＧＰＰアクセスのための非ローミングアーキテクチャ（Ｎｏｎ−ｒｏａｍｉｎｇ ａｒｃｈｉｔｅｃｔｕｒｅ ｆｏｒ ３ＧＰＰ ａｃｃｅｓｓｅｓ）」に例えば見出すことができる。

ＭＭＥ（モビリティ管理エンティティ：Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）８０４は、ネットワーク用の制御ノードであり、恒例によりアイドルモードのデバイス追跡および呼び出し手順を担当する。

ＳＧＷ（サービングゲートウェイ：Ｓｅｒｖｉｎｇ Ｇａｔｅｗａｙ）８０７は、ユーザのデータパケットをルーティングおよび転送しながら、知られている通り、インターｅＮＢ（８０９）のハンドオーバーの間のユーザプレーン用のモビリティアンカーとしても機能する。

ＰＧＷ（ＰＤＮゲートウェイ：ＰＤＮ Ｇａｔｅｗａｙ）８０８は、デバイス用のトラフィックの出口および入口のポイントに存在することにより、デバイス８０１から外部パケットデータネットワークへの接続性を提供する。

よって、例示的な実施形態によれば、以下のステップを行って、第１のデバイスおよび第２のデバイス等の対のデバイスについてＤ２Ｄ通信リンクを用いて発見および通信することができる：

１） 各デバイスは、ＰｒｏＳｅサービスを使用することが承認されている場合、ネットワークへのアタッチ時においてＰｒｏＳｅ ＩＤを取得する。

２） ＰｒｏＳｅ ＩＤは、デバイスが帰属するＭＭＥを一意的に識別する−ＭＭＥが変更されるとＰｒｏＳｅ ＩＤも変更される。

３） ＰｒｏＳｅを使用する必要があるデバイスアプリケーションは、このＰｒｏＳｅ ＩＤをアプリケーションサーバに登録または更新する。

４） 各アプリケーションはグループＩＤに関連付けられる。

５） グループＩＤは、例えば最大長さの文字列である。

６） 各グループＩＤは、セキュリティおよび認証の目的のために使用される、アプリケーション層のグループ鍵に関連付けられる。

７） 好適な無線リンク層の機構が、デバイス間で発見メッセージを送信するために存在する。無線サービスエリア内の全てのデバイスへの発見メッセージの内容の送信を可能とし、メッセージの受信者を制約する何らかの必要がある場合にＰｒｏＳｅ ＩＤまたはグループＩＤのどちらかを用いてデバイスのアドレス指定を許可する場合は、このようないずれの機構（様々な技術であり得る）も使用することができる。

８） ２つの発見手順：つまり目標を定めた発見と目標を定めない発見が存在する。

９） 目標を定めた発見は、１つのアプリケーショングループに属するデバイスを発見することを目的とし、よってメッセージはグループ内の全てのデバイスに対してブロードキャストしてよい。グループ内のデバイスは応答により自分自身を報告してよい。

１０） 目標を定めない発見は、どのデバイスグループが近傍にあるか発見することを目的とし、デバイスのポーリングに基づくことにより、デバイスが自身の属するグループのグループＩＤを報告できるようにする。

１１） デバイスは、発見処理において、デバイスがリレーノードとして機能できるかどうか等の追加のプロパティを開示してよい。

１２） グループに関する共有セキュリティ鍵に基づいたチャレンジ／応答方法により発見処理は認証されてよい。デバイスがチャレンジを受信した時、応答はチャレンジ、セキュリティ鍵、ピアに対してアドバタイズされるデバイスＰｒｏｓｅ ＩＤに関連して構成される。チャレンジに対する１つの応答は、所与のＰｒｏＳｅ ＩＤにより承諾されてよい。

１３） デバイスが同じアプリケーショングループのデバイスを発見すると、デバイスはそれらのうちの１つ（または複数）とポイント−ポイント間通信を開始することを決定してよい。そうするために、デバイスは（発見に使用したものと同じチャネルを通じて）、候補となる通信ピア／デバイスのＰｒｏＳｅ ＩＤを目標に定めた直接通信要求を送信する。

１４） 目標の通信ピアは、発見チャネル上の通信を承諾するかまたは拒否することにより、応答してよい。通信が承諾されると、デバイスがネットワークサービスエリア外に存在する場合に事前構成できる送信パラメータ（例えばパワーレベル、周波数帯、セキュリティ鍵）を用いてユーザプレーン上に通信が確立される。デバイスがネットワークサービスエリア内に存在する場合、承認および任意で適用可能な送信パラメータを取得するために、ネットワーク制御手順が使用される。

１５） 承認およびセットアップ処理の一部として、発信側のパーティのＭＭＥは、両方のパーティのＰｒｏｓｅ ＩＤを示して、通信を承認するためにアプリケーションサーバに接触してよい。（アプリケーションサーバは、Ｐｒｏｓｅ ＩＤをアプリケーションＩＤに解決でき、デバイスはＰｒｏＳｅ ＩＤに関連付けられている。）

１６） ＭＭＥは、ＥＮＢが直接送信を提供するために許可される量の割り当てを提供できる。

１７） 通信の発信者は、もう一方のパーティがリレーであり、かつ発信者がリレーそれ自体でないということでない限り、通信リンク用のＤＨＣＰサーバとして機能することを試みてよい。

本発明は、他の特定の装置および／または方法で実施してよい。記述した実施形態は、全ての点において例示的なものであり、制約的なものではないと考えられるべきである。特に、本発明の範囲は、本明細書中の説明および図面によるというよりは、添付の請求項により示されるものである。請求項の均等物の意図および範囲に該当する全ての変更は、請求項の範囲内に包含されるべきである。

Claims (15)

1. 通信ネットワークにおけるデバイス−デバイス間通信のためのデバイス発見方法であって、
   第１のデバイスから、第１のデバイスにリンクされた第１の近接サービス識別子を含む発見要求を、第２のデバイスにおいて直接的に受信するために近接サービス発見チャネルを用いて送信するステップと、
   第１のデバイスにおいて、近接サービス発見チャネルを通じて、直接的に第２のデバイスから、第２のデバイスにリンクされた第２の近接サービス識別子を含む発見要求に対する応答を受信するステップと
   を含む、方法。
2. デバイスにリンクされた近接サービス識別子が、通信ネットワークへのデバイスのアタッチのポイントでそのデバイスに提供されるか、またはそのデバイスに対して事前構成される、請求項１に記載の方法。
3. 発見要求がデバイスのグループにアドレス指定される、請求項１または２に記載の方法。
4. デバイスが、デバイスアプリケーションに関連する特定のグループ識別子に関連付けられる、請求項３に記載の方法。
5. デバイスが、複数のデバイスアプリケーションに関連する複数のグループ識別子に関連付けられる、請求項３に記載の方法。
6. 第１のデバイスと第２のデバイスとの間の直接通信リンクを確立するステップを更に含む、請求項１から５のいずれか一項に記載の方法。
7. 第１のデバイスから、第１の近接サービス識別子を含み、かつ第２の近接サービス識別子を要求用のアドレスとして用いるデバイス−デバイス間通信要求を送信するステップと、
   第２のデバイスから、第２の近接サービス識別子を含む肯定応答を、肯定応答用のアドレスとして第１の近接サービス識別子を用いて第１のデバイスへと送信することにより、第１のデバイスの要求を肯定応答するステップと
   を更に含む、請求項１から６のいずれか一項に記載の方法。
8. デバイス−デバイス間通信のために、第１のデバイスおよび第２のデバイスのうちの１つまたは両方から、デバイスに関連付けられたネットワークのそれぞれの基地局へと承認要求を送信するステップを更に含み、承認要求が、デバイスの通信ネットワークサービスエリアを表すデータを含む、請求項１２に記載の方法。
9. 基地局からモビリティ管理エンティティへと承認要求を送信するステップと、
   デバイス−デバイス間通信を承認するステップと
   を更に含む、請求項８に記載の方法。
10. デバイス−デバイス間通信の承認が、デバイス間の通信を調整するための、送信パラメータのセットを提供するステップを含む、請求項９に記載の方法。
11. 送信パラメータが、デバイス−デバイス間通信をセキュリティ保護するためにデバイスが使用するための暗号化データ、ならびに／または周波数および／もしくはパワー範囲もしくは動作の最大パワーレベルに関するデータを含む、請求項１０に記載の方法。
12. 送信パラメータが、デバイス−デバイス間送信用に許可されたデータ量割り当てを表すデータを含む、請求項１０または１１に記載の方法。
13. 通信ネットワークにおけるデバイス−デバイス間通信のための方法であって、
    目標を定めたまたは目標を定めない検出処理を用いてネットワーク内の潜在的なピアのセットを発見するステップと、
    デバイス−デバイス間通信を承認するためのハンドシェイクを実行するために、セット内のデバイスとのリンクを確立するステップと、
    ハンドシェイクに基づいてデバイスと直接的に通信するステップと
    を含む、方法。
14. 請求項１から１３のいずれか一項に記載の方法に従って動作可能な、ユーザ機器デバイス。
15. コンピュータ可読プログラムコードを組み込んだコンピュータが使用可能な媒体を含む、コンピュータプログラム製品であって、前記コンピュータ可読プログラムコードは、請求項１から１３のいずれか一項で提供されるような通信ネットワークにおけるデバイス−デバイス間通信に関するデバイス発見のための方法を実施するために実行されるように構成される、コンピュータプログラム製品。

Images