本発明の一態様によると、ProSeクエリコードおよびProSe応答コードを生成することと、少なくともProSe応答コードを、第1の発見鍵および第2の発見鍵と共に第1の端末デバイスに送ることと、少なくとも第1の発見鍵およびProSeクエリコードを第2の端末デバイスに送ることで、第2の端末デバイスが無線インターフェース上で第1の端末デバイスを安全に発見できるようにすることとを含む、近傍サービスサーバによって行われる方法が提供される。
1つの実施形態では、方法は、予備ステップとして、第1の発見鍵および第2の発見鍵を生成することをさらに含む。方法はまた、予備ステップとして、第1の発見鍵および第2の発見鍵を鍵管理サーバから受信することを含むことができる。
1つの実施形態では、方法は、ProSeクエリコードに基づいて発見フィルタを生成し、かつ、この発見フィルタを第1の端末デバイスに送ることを含む。
別の実施形態では、方法は、第2の端末デバイスが無線インターフェース上で第1の端末デバイスを発見することを望んでいることを指示する発見要求を第2の端末デバイスから受信することであって、近傍サービスはその後、第1の発見鍵およびProSeクエリコードを第2の端末デバイスに送る、受信することを含む。
方法は、第2の端末デバイスが通信している第2の近傍サービスサーバにProSe応答コードを送ることをさらに含むことができる。
1つの実施形態では、方法は、ProSe応答コード、および第2の発見鍵に基づくトークンを含むマッチレポート要求を第2の端末デバイスから受信することを含む。
代替的な実施形態では、方法は、第2の発見鍵を使用してトークンを検証することを含む。
トークンが検証される場合、方法は、第1の端末デバイスが真正であることを指示するマッチレポート応答を第2の端末デバイスに送ることをさらに含むことができる。
1つの実施形態では、方法は、第1の端末デバイスが真正であることを第2の端末デバイスが検証することができるように、第2の発見鍵を第2の端末デバイスに送ることを含む。
1つの実施形態では、第2の端末デバイスは複数の第2の端末デバイスを含み、それによって、方法が、ProSeクエリコードおよび第1の発見鍵をそれぞれの第2の端末デバイスに送ることを含むことができるようにする。
本発明の別の態様によると、ProSeクエリコードおよびProSe応答コードを生成する生成ユニットと、少なくともProSe応答コードを第1の発見鍵および第2の発見鍵と共に第1の端末デバイスに送り、かつ、少なくとも第1の発見鍵およびProSeクエリコードを第2の端末デバイスに送ることで、第2の端末デバイスが無線インターフェース上で第1の端末デバイスを安全に発見できるようにする送信ユニットとを含むサーバが提供される。
本発明のさらなる態様によると、プロセッサおよびメモリを含むサーバであって、メモリは、ネットワークノードが添付の請求項1から11のいずれか一項による方法を実施するように動作可能であるように、プロセッサによって実行可能な命令を包含する、サーバが提供される。
本発明のなお別の態様によると、端末デバイスによって行われる方法であって、近傍サービスサーバから、第1の発見鍵、第2の発見鍵、およびProSe応答コードを受信することと、ProSeクエリコードおよびトークンを含む直接発見要求を、端末デバイスを発見することを望んでいる第2の端末デバイスから受信することと、第1の発見鍵を使用してトークンを検証することとを含む方法が提供される。
方法は、第1の端末デバイスが、ProSeクエリコードに基づく発見フィルタを近傍サービスサーバから受信することをさらに含むことができる。
1つの実施形態では、第1の端末デバイスは無線インターフェース上でProSeクエリコードおよびトークンを受信し、トークンは第1の発見鍵に基づく。
第1の端末デバイスが第2の端末デバイスから受信されたトークンを検証する場合、方法は、第2の発見鍵に基づく第2のトークンを含む発見応答を第2の端末デバイスに送ることをさらに含むことができる。
1つの実施形態では、方法は、予備ステップとして、端末デバイスがその近傍サービスサーバに、第2の端末デバイスが上記の端末デバイスを発見可能とされるように要求するような発見要求を送ることを含む。
本発明の別の態様によると、近傍サービスサーバから、第1の発見鍵、第2の発見鍵、およびProSe応答コードを受信し、かつ、ProSeクエリコードおよびトークンを含む直接発見要求を、端末デバイスを発見することを望んでいる第2の端末デバイスから受信する送信ユニットと、第1の発見鍵を使用してトークンを検証する検証ユニットと、を含む端末デバイスが提供される。
本発明のなお別の態様によると、プロセッサおよびメモリを含む端末デバイスであって、メモリは、ネットワークノードが添付の請求項14から18のいずれか一項による方法を実施するように動作可能であるように、プロセッサによって実行可能な命令を包含する、端末デバイスが提供される。
本発明のさらなる態様によると、近傍サービスサーバによって行われる方法であって、少なくとも第1の発見鍵、ProSeクエリコード、およびProSe応答コードを第2の近傍サービスサーバから受信することと、ProSe応答コードに基づいて発見フィルタを生成することと、発見フィルタ、第1の発見鍵、およびProSeクエリコードを第1の端末デバイスに送ることで、第1の端末デバイスが無線インターフェース上で第2の端末デバイスを安全に発見できるようにすることと、を含む方法が提供される。
1つの実施形態では、方法は、第2の発見鍵に基づくトークンを含むマッチレポート要求を第1の端末デバイスから受信することと、該トークンを検証のために第2の近傍サーバに転送することとを含む。
第2の近傍サーバがトークンを検証する場合、方法は、第2の端末デバイスが真正であることを指示する応答を第2の近傍サーバから受信することをさらに含むことができる。
1つの実施形態では、方法は、近傍サービスサーバが、第2の発見鍵を第2の近傍サービスサーバから受信し、かつ、第2の発見鍵を第1の端末デバイスに送ることをさらに含む。
別の実施形態では、方法は、予備ステップとして、近傍サービスサーバが、第1の端末デバイスが第2の近傍サービスサーバの第2の端末デバイスを発見することを望んでいることを指示する発見要求を第1の端末デバイスから受信することをさらに含むことができる。
1つの実施形態では、方法は、第1の端末デバイスが第2の近傍サービスサーバの第2の端末デバイスを発見することを望んでいることを指示する発見要求を第2の近傍サービスサーバに送ることを含むことができる。
本発明の別の態様によると、第2の近傍サービスサーバから、少なくとも第1の発見鍵、ProSeクエリコード、およびProSe応答コードを受信する送信ユニットと、ProSe応答コードに基づいて発見フィルタを生成し、かつ、発見フィルタ、第1の発見鍵、およびProSeクエリコードを第1の端末デバイスに送ることで、第1の端末デバイスが無線インターフェース上で第2の端末デバイスを安全に発見できるようにする生成ユニットと、を含むサーバが提供される。
本発明のなお別の態様によると、プロセッサおよびメモリを含むサーバであって、メモリは、ネットワークノードが添付の請求項21から26のいずれか一項による方法を実施するように動作可能であるように、プロセッサによって実行可能な命令を包含する、サーバが提供される。
本発明のさらなる態様によると、端末デバイスによって行われる方法であって、ProSeクエリコードおよび第1の発見鍵を近傍サービスサーバから受信することと、第1の発見鍵に基づくトークンを含む直接発見要求を第2の端末デバイスに送ることと、ProSe応答コードおよび第2のトークンを含む発見応答を第2の端末デバイスから受信することと、を含む方法が提供される。
1つの実施形態では、方法は、ProSe応答コードに基づく発見フィルタを近傍サービスサーバから受信することを含む。
別の実施形態では、方法は、端末デバイスが、発見フィルタを使用して第2の端末デバイスから受信されたProSe応答コードを特定することを含む。
1つの実施形態では、端末デバイスは、第2のトークンを検証のために近傍サービスサーバに転送することができる。
第2のトークンが検証される場合、方法は、第2の端末デバイスが真正であることを指示するメッセージを近傍サービスサーバから受信することをさらに含むことができる。
代替的な実施形態では、方法は、端末デバイスが、近傍サービスサーバから第2の発見鍵を受信することと、端末デバイスが、第2の発見鍵を使用して第2のトークンを検証することによって、第2の端末デバイスを認証することとを含むことができる。
1つの実施形態では、方法は、予備ステップとして、端末デバイスが第2のデバイスを発見することを望んでいることを指示する発見要求を近傍サービスサーバに送ることを含むことができる。
別の実施形態では、端末デバイスは複数の端末デバイスを含むことができ、それによって、方法が、それぞれの端末デバイスが、同じProSeクエリコードおよび第1の発見鍵を受信し、直接発見要求を同じ第2の端末デバイスに送り、および、直接発見応答を前記の同じ第2の端末デバイスから受信することをさらに含むようにする。
本発明の別の態様によると、ProSeクエリコードおよび第1の発見鍵を近傍サービスサーバから受信し、第1の発見鍵に基づくトークンを含む直接発見要求を第2の端末デバイスに送り、および、ProSe応答コードおよび第2のトークンを含む発見応答を第2の端末デバイスから受信する送信ユニットを含む、端末デバイスが提供される。
本発明のなお別の態様によると、プロセッサおよびメモリを含む端末デバイスであって、メモリは、ネットワークノードが添付の請求項29から36のいずれか一項による方法を実施するように動作可能であるように、プロセッサによって実行可能な命令を包含する、端末デバイスが提供される。
さらなる態様によると、コンピュータ上で起動する時、添付の請求項1から11、14から18、21から26、または29から35のいずれか一項による方法を実施するように構成されるコンピュータプログラムが提供される。
本発明のなお別の態様によると、コンピュータ可読媒体、および、コンピュータ可読媒体上に格納される上述されるようなコンピュータプログラムを含む、コンピュータプログラム製品が提供される。
図1は、第1の基地局10、サービングセル12、および、セル12内に第1のワイヤレス通信デバイス(UE1)14および第2のワイヤレス通信デバイス(UE2)16を共に含む、セルラー通信ネットワークの一部を示す。
図2は、第1の基地局20、第1のサービングセル22、このセル22内の第1のワイヤレス通信デバイス(UE1)24、第2の基地局26、第2のサービングセル28、このセル28内の第2のワイヤレス通信デバイス(UE2)30を含む、別のセルラー通信ネットワークの一部を示す。
本明細書に説明される例では、方法に関与するデバイスはユーザ機器デバイス(UE)として説明される。この用語は、スマートフォン、またはラップトップコンピュータなどのユーザ操作のポータブル通信デバイス、追跡デバイスなどの他のポータブルデバイス、および、センサまたはスマートメーターなど、主に使用時に静止するようにするデバイスに言及するために使用されることが理解されるであろう。ユーザ機器デバイスという用語はまた、ワイヤレス通信デバイス、端末デバイス、および端末機を含むと理解されるべきであり、ユーザ操作のデバイスであることに限定されない。
図1および図2に示される例では、ネットワークは、第3世代パートナーシッププロジェクト(3GPP)によって規定されるように、エボルブドUMTS地上無線アクセスネットワーク(E−UTRAN)の一部を形成する。3GPPシステムは、互いに近傍であるユーザ機器(UE)デバイスによって使用可能である近傍サービス(ProSe)の可能性をもたらす。ProSeシステムについては、3GPP TS22.278および3GPP TS23.303に記載されている。例えば、ProSeシステムによって、メッセージを無線アクセスネットワークを通さずにデバイスツーデバイス(D2D)通信可能とすることができる。
ProSeシステムの一面はProSe発見のプロセスである。ProSe発見プロセスは、許可、承認、および近傍基準が満たされる時、ProSe対応UEが、エボルブドUMTS地上無線アクセス(E−UTRANを使用するまたは使用しない)、または拡張パケットコア(EPC)ネットワークを使用して、互いに近傍であることを特定する。近傍基準はオペレータによって構成可能である。
ProSe発見の1つの特定的な形態はProSe直接発見であり、これは、E−UTRA技術によって2つのUEの能力のみを使用することによって、近接している他のProSe対応UEを発見するためにProSe対応UEによって採用される手順である。
ProSe対応UEという用語は、ProSe要件および関連の手順をサポートするUEに言及する。ProSe対応UEは、非公共安全UEおよび/または公共安全UE(Public Safety UE)であってよい。
図1および図2は、UE1およびUE2がそれぞれ、図1に示されるように同じセル12であってよい、または図2に示されるように異なるセル22、28であってよいセルのカバレッジに位置する場合のD2D ProSeについてのシナリオを示す。UE1が送信機としての役割を果たす場合、UE1は発見メッセージを送り、UE2はこのメッセージを受信する。この2つのデバイスUE1およびUE2は、送信機および受信機としてのそれらの役割を変更することができる。UE1からの送信は、UE2に加えて少なくとも1つの他のUEによって受信可能である。
ProSe発見プロセスは、スタンドアロンプロセスとして(すなわち、必ずしも後にProSe通信が行われるわけではない)、または他のサービス用のイネーブラとして、使用可能である。
図3はProSeネットワークアーキテクチャの実例である。図3では、2つのユーザ機器デバイスのUE AおよびUE Bが同じ地上波公共移動通信ネットワーク(PLMN)に加入していると仮定される。
2つのユーザ機器デバイスのUE AおよびUE Bはそれぞれ、LTE−Uuインターフェース上でエボルブドUMTS地上無線アクセスネットワーク(E−UTRAN)にそれぞれ接続されている。S1インターフェースは、E−UTRANをエボルブドパケットコア(EPC)ネットワークに接続する。このネットワークは、他のネットワークノードの中で、モビリティ管理エンティティ(MME)、サービングゲートウェイ(SGW)、パケットゲートウェイ(PGW)、ホームサブスクライバサーバ(HSS)、およびセキュアユーザプレーンロケーション(SUPL)ロケーションプラットフォーム(SLP)を含む。
ネットワークはまた、アプリケーション機能性をビルドするためのProSe能力を使用する少なくとも1つのアプリケーションサーバを含む。
コアネットワークはまたProSe機能を含む。このProSe機能は、(ローミングしない場合はユーザのホームPLMNにおけるProSe機能によって、およびローミングする場合はホームPLMNまたは訪問先PLMN ProSe機能によって制御される)発見および直接通信のためのUEの承認および構成、EPCレベルProSe発見の機能性を有効にすること、ProSe関連の新しいサブスクライバデータおよびProSe識別のハンドリングおよび格納、ならびに、セキュリティ関連機能性などの機能性を提供する。
ProSe機能は、それぞれのUEの方へのPC3基準点を有し、EPCの方へのPC4基準点を有する。
ProSe機能は、少なくとも1つのProSeアプリケーションサーバの方へのPC2基準点も有し、この基準点は、アプリケーション機能性をビルドするためにProSe能力を使用する。
それぞれのUEは、ProSeアプリケーションを含み、このアプリケーションは、ProSeアプリケーションサーバの方へのPC1基準点を有する。
UEのUE AおよびUE Bは、(直接的にUE間で、およびLTE−Uuインターフェース上でのUE間で)中継および1対1通信のために、発見および通信用の制御およびユーザプレーンに対するPC5基準点を使用する。基準点PC5は、本明細書では、2つのUE(UE AおよびUE B)間の無線インターフェースとも呼ばれる。
図4は、ProSe機能をより詳細に示す。ホーム地上波公共移動通信ネットワーク(HPLMN)のProSe機能410は、3つのサブ機能:DPF411、直接発見名称管理機能412、およびEPCレベル発見機能413を含む。直接発見名称管理機能は、ProSe直接発見において使用されるProSeアプリケーションIDおよびProSeアプリケーションコードのマッピングを割り当てかつ処理するためにオープンProSe直接発見に対して使用される。直接発見名称管理機能は、それぞれの発見要求の承認のためにホームサブスクライバサーバ(HSS)に格納されるProSe関連サブスクライバデータを使用する。直接発見名称管理機能はまた、無線インターフェースPC5上で送信される発見メッセージを保護するために、UE414に必要なセキュリティ材料を提供する。
図5は、異なる地上波公共移動通信ネットワーク(PLMN)のいくつかのProSe機能、およびそれらのインターフェースを示す。ホームPLMN(HPLMN)510は、ローカルPLMN511の方へのPC6またはPC7基準点を有する。HPLMN510は、訪問先PLMN(VPLMN)512の方へPC7基準点を有することもできる。
ProSe直接発見手順において、2つのモデル:モデルA(「私はここにいます」)およびモデルB(「そこにいるのは誰ですか」/「あなたはそこにいますか」)がある。モデルAは、ProSe直接発見に参加しているProSe対応UEに対して2つの役割を規定する。通知側UEを発見する許可を得ている近傍の他のUEによって使用可能である、ある特定の情報を通知する1つの役割を、通知側UEが担う。通知側UEの近傍のある特定の対象情報をモニタリングするもう一方の役割を、モニタリング側UEが担う。
モデルBは、ProSe直接発見に参加しているProSe対応UEに対する2つの役割を規定する。発見することに関心があるものについてのある特定の情報を包含する要求を送信する第1の役割を、発見側UEが担う。その要求メッセージを受信し、かつ、発見側UEの要求に関連した情報と共に応答することができるもう一方の役割を、被発見側UEが担う。2つのUEが役割を変更できることは理解されるべきである。
ProSe直接発見手順は、「オープン」または「制限」発見手順とすることができる。ProSeオープン直接発見は、例えば、発見側/モニタリング側UEにおけるある特定のアプリケーションについて被発見側/通知側UEからの情報を使用することができるスタンドアロンサービスイネーブラとすることができる。発見側/モニタリング側UEはこの情報の使用を許可されている。例えば、被発見側/通知側UEは近くのタクシーとすることができ、発見側/モニタリング側UEは近くのタクシーを見つけたいと思っている。換言すれば、誰が誰を発見可能であるかについての制限はないまたはほとんどない。
ProSe制限直接発見手順において、誰が誰を発見できるかについての制限がある。ProSe対応UEは、互いに近傍であり、かつ、発見可能なProSe対応UE(被発見側/通知側UE)によって明確に許可されている他のProSe対応UE(発見側/モニタリング側UE)によってのみ発見可能とする(被発見側/通知側UE)ことができるものとする。ProSe制限直接発見は、被発見側/通知側UEを発見するための発見側/モニタリング側UEの能力を判断するために被発見側/通知側UEによってアプリケーション層で規定された許可を可能にする。
オープンProSe直接発見手順および制限ProSe直接発見手順は両方共、モデルAまたはモデルBを使用することができることは、理解されるべきである。
ここで再び、モデルBについてより詳細に言及すると、発見側UEが近接するまたは近傍の被発見側UEを発見することを望む時、発見側UEは、無線インターフェース(PC5)上で、ProSeクエリコードを含む直接発見要求メッセージをブロードキャストする(ProSeクエリコードは、ホーム地上波公共移動通信ネットワーク(HPLMN)においてProSe機能によって生成または割り当てられるコードであり、被発見側が発見側を特定できるようにする)。被発見側UEは、発見メッセージをリッスンし、かつ発見側UEから送られた直接発見要求メッセージを特定するためにProSeクエリコードに基づく発見フィルタを使用する。発見フィルタが発見側UEから送られたProSeクエリコードを特定する時、被発見側UEは、無線(PC5インターフェース)で、ProSe応答コードを含む直接発見応答メッセージをブロードキャストする。ProSe応答コードはProSe機能によって被発見側UEに割り当てられる。
本発明の一実施形態について、ここで、図6を参照して説明する。この実施形態では、被発見側UE651、被発見側UEのホーム地上波公共移動通信ネットワーク(HPLMN)ProSe機能652、発見側UE653、および発見側UEのHPLMN ProSe機能654は、メッセージを交換する。
まず、ステップ601において、アプリケーションサーバにおける所定の発見側UE(図3を参照)が上記の被発見側UE651を発見可能とされるように要求する発見要求を送ることによって、被発見側UE651はそのHPLMN ProSe機能652による発見要求手順を開始する。被発見側UEはPC3インターフェース上でその要求を送る。
被発見側UEのHPLMN ProSe機能652は、次いで、ステップ602において、ProSeクエリコード、ProSe応答コード、発見鍵A(第1の発見鍵)、および発見鍵B(第2の発見鍵)を生成または構築する。しかしながら、別の示されない実施形態では、HPLMN ProSe機能652は、発見鍵AおよびBを生成せず、その代わりに、これらの鍵を鍵管理サーバから受信する。
ProSe機能652はまた、ProSeクエリコードに基づいて発見フィルタを生成または準備する。発見フィルタは、ProSeクエリコード、ゼロ以上のProSeアプリケーションマスク、および生存時間値のコンテナであり、その使用については以下でより詳細に説明する。
ProSe機能652は次いで、ステップ603において、PC3インターフェース上で、ProSe応答コード、発見鍵A、発見鍵B、および発見フィルタを含む発見応答を被発見側UE651に送る。
その一方で、発見側UE653は、ステップ604において、PC3インターフェース上でそのHPLMN ProSe機能654に発見要求を送って被発見側UE651を発見することによって、そのHPLMN ProSe機能654による発見要求手順を開始する。発見側UEのHPLMN ProSe機能654は、次いで、ステップ605において、発見要求をPC6インターフェース上で被発見側UEのHPLMN ProSe機能652に送る。それに応じて、被発見側UEのHPLMN ProSe機能652は、ステップ606において、発見応答をPC6インターフェース上で発見側UEのHPLMN ProSe機能654に送る。この発見応答は、ProSeクエリコード、発見鍵A、およびProSe応答コードを含む。発見側UEのHPLMN ProSe機能654は、次いで、ステップ606aにおいて、ProSeクエリコード、発見鍵A、およびProSe応答コードを格納することができる。
発見側UEのHPLMN ProSe機能654は、次いで、ステップ607において、ProSe応答コードに基づいて発見フィルタを構成または生成後、発見応答を発見側UE653に送る。この発見応答は、ProSeクエリコード、発見鍵A、および、ProSe応答コードに基づく発見フィルタを含む。
その後、発見側UE653は、発見鍵Aを使用してトークンを算出する。トークンはメッセージの完全性を示すコード(MIC)であってよい。ステップ608aにおいて、MICは、入力パラメータとしての発見鍵Aおよび時間値と共に、3GPP TS33.220に記載される鍵導出関数(KDF)を使用して算出される。このトークンは本明細書ではMIC−Aと呼ばれる。ProSeクエリコードはまた、追加の入力パラメータとして使用可能である。トークンは、代替的な実施形態において、MICに限定されず、代わりにメッセージ認証コードが使用可能であることは理解されるべきである。
608bにおいて、発見側UE653が近接した被発見側UE651を発見することを望む時、発見側UE653はPC5インターフェース上で直接発見要求メッセージをブロードキャストする。直接発見要求はProSeクエリコードおよびMIC−Aを含む。
被発見側UE651は次いで、直接発見要求を聴取し、ProSeクエリコードに基づくその発見フィルタを使用して、被発見側UE651は、発見側UE653から受信されたProSeクエリコードを特定するまたはこれをマッチさせる。ステップ608cにおいて、被発見側UE651は、マッチを行った時、同じ発見鍵Aおよび時間値を使用してMIC−Aを算出することによって、トークンを検証する。MIC−Aが被発見側UE653から受信されたトークンにマッチする場合、被発見側UE651は、発見側UEが真正であることを知るため、発見側UE653に上記の被発見側UE651を安全に発見可能とすることができる。次のステップでは、被発見側UE651は、ステップ609aにおいて、発見鍵Bおよび時間値に基づくMICを含む別のトークンを算出する。このトークンは本明細書ではMIC−Bと呼ばれる。しかしながら、発見鍵Aに関連して上述されるような代替的なトークンが使用可能であることは、理解されるべきである。
被発見側UE651は、次いで、ステップ609bにおいて、発見応答をPC5インターフェース上で発見側UE653に送る。発見応答はProSe応答コードおよびMIC−B(発見鍵Bに基づく他のトークン)を含む。
発見側UE653は、次いで、発見応答を聴取し、ProSe応答コードに基づくその発見フィルタを使用することによって、被発見側UE651から送られたProSe応答コードを特定するまたはこれをマッチさせる。発見側UE653に被発見側UE651が真正であるかどうかを明らかにさせるために、発見側UE653はマッチレポート手順を開始するが、このことは、ステップ610において、マッチレポート要求をPC3インターフェース上でそのHPLMN ProSe機能654に送ることによって行われる。マッチレポートメッセージはトークンMIC−Bを含み、ProSe応答コードも含むことができる。ステップ611において、発見側UEのHPLMN ProSe機能654は、次いで、PC6インターフェース上でマッチレポート要求を被発見側UEのHPLMN ProSe機能652に転送する。
被発見側UEのHPLMN ProSe機能652は、次いで、発見鍵Bおよび時間値を使用してMIC−Bを算出することによってトークンを検証する。MIC−Bが、発見側UE653およびそのHPLMN ProSe機能654を介して被発見側UE651から受信されたトークンにマッチする場合、被発見側UEのProSe機能652は、ステップ613において、マッチレポート応答を、PC6インターフェース上で発見側UEのHPLMN ProSe機能654に送り、発見側UEのHPLMN ProSe機能654は、ステップ614において、マッチレポート応答を発見側UE653に転送する。マッチレポート応答を受信すると、発見側UE653は、被発見側UE651が真正であることを知る。
この方法の利点のうちの1つは、被発見側UE651および発見側UE653が発見鍵(A)を共有するため、被発見側UE651は発見側UE653を検証でき、それによって、被発見側UE651は、発見側UE653が真正であり、かつ、別の模倣しているまたは偽の発見側UEがProSeクエリコードを再生していないことが分かることである。
さらに、被発見側UE651は、その発見フィルタを満足させる発見要求メッセージを聴取する時に、そのHPLMN ProSe機能によってマッチレポート手順を開始する必要はなく、代わりに、被発見側UE651自体が発見要求メッセージにおいて受信されたトークンを検証できる。
また、発見鍵Bが被発見側UEのProSe機能652を決して離れないことは有利である。これは、発見側UE653が、ProSe応答コードを別の発見側UEに対して再生することによって、被発見側UEを装うことができないことを意味する。
有利には、この方法は、オープン直接発見手順および制限直接発見両方に適用可能である。
なお別の利点は、被発見側UE651および発見側UE653が、その間でネットワークへのシグナリングを必要とせずに、ProSeクエリコードおよびProSe応答コードを直接交換できることである。
ここで、図7を参照して、別の実施形態について説明する。この実施形態は、被発見側UEのHPLMN ProSe機能が発見鍵Bを発見側UEに転送することで、発見側UEはマッチレポートプロセスを開始する必要はないが、自身で被発見側UEから受信されたMIC−Bを検証できるようにする点で、図6を参照して説明されるものとは異なっている。
この実施形態では、被発見側UE751、被発見側UEのホーム地上波公共移動通信ネットワーク(HPLMN)ProSe機能752、発見側UE753、および発見側UEのHPLMN ProSe機能754は、メッセージを交換する。
まず、ステップ701において、アプリケーションサーバにおける所定の発見側UE(図3を参照)が上記の被発見側UE751を発見可能とされるように要求する発見要求を送ることによって、被発見側UE751はそのHPLMN ProSe機能752による発見要求手順を開始する。被発見側UE751はPC3インターフェース上でその要求を送る。
被発見側UEのHPLMN ProSe機能752は、次いで、ステップ702において、ProSeクエリコード、ProSe応答コード、発見鍵A(第1の発見鍵)、および発見鍵B(第2の発見鍵)を生成する。しかしながら、別の実施形態では、HPLMN ProSe機能752は、発見鍵AおよびBを生成せず、その代わりに、これらの鍵を鍵管理サーバから受信する。
HPLMN ProSe機能752はまた、ProSeクエリコードに基づいて発見フィルタを生成する。先に説明したように、発見フィルタは、ProSeクエリコード、ゼロ以上のProSeアプリケーションマスク、および生存時間値のコンテナであり、その使用については以下でより詳細に説明する。
ProSe機能752は次いで、ステップ703において、PC3インターフェース上で、ProSe応答コード、発見鍵A、発見鍵B、および発見フィルタを含む発見応答を被発見側UE751に送る。
その一方では、発見側UE753は、ステップ704において、PC3インターフェース上で、そのHPLMN ProSe機能754に被発見側UE751を発見するための発見要求を送ることによって、そのHPLMN ProSe機能754による発見要求手順を開始する。発見側UEのHPLMN ProSe機能754は、次いで、ステップ705において、発見要求をPC6インターフェース上で被発見側UEのHPLMN ProSe機能752に送る。それに応じて、被発見側UEのHPLMN ProSe機能752は、ステップ706において、発見応答をPC6インターフェース上で発見側UEのHPLMN ProSe機能754に送る。この発見応答は、ProSeクエリコード、発見鍵A、発見鍵B、およびProSe応答コードを含む。発見側UEのHPLMN ProSe機能754は、次いで、ステップ706aにおいて、ProSeクエリコード、発見鍵A、発見鍵B、およびProSe応答コードを格納することができる。
発見側UEのHPLMN ProSe機能754は、次いで、ステップ707において、ProSe応答コードに基づいて発見フィルタを構成後、発見応答を発見側UE753に送る。この発見応答は、ProSeクエリコード、発見鍵A、発見鍵B、およびProSe応答コードに基づく発見フィルタを含む。
その後、発見側UE753は、発見鍵Aを使用してトークンを算出する。トークンはメッセージの完全性を示すコード(MIC)であってよい。ステップ708aにおいて、MICは、入力パラメータとしての発見鍵Aおよび時間値と共に、3GPP TS33.220に記載される鍵導出関数(KDF)を使用して算出される。このトークンは本明細書ではMIC−Aと呼ばれる。(ProSeクエリコードはまた、追加の入力パラメータとして使用可能である。トークンは、代替的な実施形態において、MICに限定されず、代わりにメッセージ認証コードが使用可能であることは理解されるべきである。)
708bにおいて、発見側UE753が近接した被発見側UE751を発見することを望む時、発見側UE753はPC5インターフェース上で直接発見要求メッセージをブロードキャストする。直接発見要求はProSeクエリコードおよびMIC−Aを含む。
被発見側UE751は次いで、直接発見要求を聴取し、ProSeクエリコードに基づくその発見フィルタを使用して、被発見側UE751は、発見側UE753から受信されたProSeクエリコードを特定するまたはこれをマッチさせる。ステップ708cにおいて、被発見側UE751は、マッチを行った時、同じ発見鍵Aおよび時間値を使用してMIC−Aを算出することによって、トークンを検証する。MIC−Aが発見側UE753から受信されたトークンにマッチする場合、被発見側UE751は、発見側UE753が真正であるため、発見側UE753に上記の被発見側UE751を安全に発見可能とすることができることを知り、このことは、ステップ709aにおいて、発見鍵Bおよび時間値に基づくMICを含む別のトークンをさらに算出することによって、行われる。このトークンは本明細書ではMIC−Bと呼ばれる。しかしながら、発見鍵Aに関連して上で論じられるような代替的なトークンが使用可能であることは、理解されるべきである。
被発見側UE751は、次いで、ステップ709bにおいて、発見応答をPC5インターフェース上で発見側UE753に送る。発見応答はProSe応答コードおよびMIC−B(発見鍵Bに基づく他のトークン)を含む。
発見側UE753は、次いで、発見応答を聴取し、ProSe応答コードに基づくその発見フィルタを使用することによって、被発見側UE751から送られたProSe応答コードを特定するまたはこれをマッチさせる。発見側UE753に被発見側UE751が真正であるがどうかを明らかにさせるために、発見側UE753は、発見鍵Bおよび時間値を使用してMIC−Bを算出することによってトークンを検証する。MIC−Bが被発見側UE751から受信されたトークンにマッチする場合、発見側UE753は、被発見側UE751が真正であること、すなわち、被発見側UEが別の被発見側UEに属するProSe応答コードを再生していないことを知る。
この実施形態は、図6を参照して説明される実施形態と同様の利点を共有する。例えば、この方法の利点のうちの1つは、被発見側UE751および発見側UE753が発見鍵(A)を共有するため、被発見側UE751は発見側UE753を検証でき、それによって、被発見側UE751は、発見側UE753が真正であり、かつ、別の模倣しているまたは偽の発見側UEがProSeクエリコードを再生していないことを知ることである。
さらに、被発見側UE751は、その発見フィルタを満足させる発見要求メッセージを聴取する時に、そのHPLMN ProSe機能によるマッチレポート手順を開始する必要はなく、代わりに、被発見側UE751自体が発見要求メッセージにおいて受信されたトークンを検証できる。同様に、発見側UE753は、その発見フィルタを満足させる発見要求メッセージを聴取する際に、マッチレポート手順を開始する必要はない。その代わりに、発見側UE753自体が被発見側UE751から受信されたトークンを検証できる。
有利には、この方法は、オープン直接発見手順および制限直接発見両方に適用可能である。
図6を参照して説明された実施形態と同様に、別の利点は、被発見側UE751および発見側UE753が、その間でネットワークへのシグナリングを必要とせずに、ProSeクエリコードおよびProSe応答コードを直接交換できることである。
図6および図7を参照して説明される両方の実施形態において、発見側UE653、753が、全てが、同じProSeクエリコード、特定のProSe応答コードに基づく発見フィルタ、および第1の発見鍵を受信する発見側UEのグループであってよいことは、理解されるべきである。これによって、該グループにおける発見側UEのいずれも被発見側UEを発見できるようにする。よって、第1の発見鍵およびProSeクエリコードは特定の被発見側UEに特有ではない。
代替的には、グループのそれぞれの発見側UEは、さらに、同じ第2の発見鍵を受信することができるため、それぞれのUEは、被発見側UE651、751から発見応答607、707を受信すると、上記の被発見側UE651、751を検証または認証できる。
ここで、図6および図7を参照して説明される方法を実装する実施形態について説明する。
ここで、サーバの方法の一実施形態について、図8を参照して説明する。サーバは、ProSe機能などの近傍サービスサーバであってよい。近傍サービスサーバは、第1の端末デバイス(被発見側UE)と同じ地上波公共移動通信ネットワーク(PLMN)の一部であるため、第1の端末デバイスのホームPLMN ProSe機能であると考えられ得る。第1の端末デバイスおよび近傍サービスサーバは、PC3インターフェース上で情報を送信している。近傍サービスサーバはまた、別のまたは第2の近傍サービスサーバ、または第2の端末デバイス(発見側UE)と同じPLMNのProSe機能を介して第2の端末デバイスに対して情報を送りかつ受信している。よって、第2の近傍サービスサーバは、第2の端末デバイス(発見側UE)のホームPLMN ProSe機能であると考えられ得る。
述べられるように、方法は、近傍サービスサーバなどのサーバによって行われる。方法は、ProSeクエリコードおよびProSe応答コードを生成する801こと、または、ProSeクエリコードおよびProSe応答コードを第1の端末デバイスに割り当てることを含む。次のステップでは、近傍サービスサーバは、少なくともProSe応答コードを第1の発見鍵および第2の発見鍵と共に第1の端末デバイスに送る802。その後、近傍サービスサーバは、少なくとも第1の発見鍵およびProSeクエリコードを第2の端末デバイスに送る803ため、第2の端末デバイスは無線インターフェース上で第1の端末デバイスを安全に発見可能となる。
ここで、図9を参照して、この方法の別の実施形態について説明する。この実施形態では、近傍サービスサーバは、第1の発見鍵および第2の発見鍵を生成する901ことができる、あるいは、この2つの鍵を鍵管理サーバから受信できる902。近傍サービスサーバは、次いで、ProSeクエリコードおよびProSe応答コードを生成する903、または、これらのコードを第1の端末デバイスに割り当てる。その後、この近傍サービスサーバは、少なくともProSe応答コードを第1の発見鍵および第2の発見鍵と共に第1の端末デバイスに送る904。近傍サービスサーバはその後、第2の端末デバイスから、第2の端末デバイスが無線インターフェース上で第1の端末デバイスを発見することを望んでいることを指示する発見要求を受信する905。次のステップでは、近傍サービスサーバは、少なくとも第1の発見鍵およびProSeクエリコードを第2の端末デバイスに送った906後、ProSeクエリコードに基づいて発見フィルタを生成し、これを第1の端末デバイスに送る907。ProSeクエリコードに基づく発見フィルタは、代替的には、ステップ904で始められるように、ProSe応答コード、第1の発見鍵、および第2の発見鍵と共に第1の端末デバイスに送られ得る。次いで、近傍サービスサーバはまた、第2の端末デバイスが通信している第2の近傍サービスサーバにProSe応答コードを送る908。(これによって、第2の近傍サービスサーバは、近傍サービスサーバの代わりにProSe応答コードに基づいて発見フィルタを生成できる。)次のステップでは、近傍サービスサーバは、第2の端末デバイスを介して、第2の発見鍵に基づくトークンのみならず、第1の端末デバイスからのProSe応答コードを含むマッチレポート要求を受信する909。近傍サービスサーバは次いで、第2の発見鍵を使用してトークンを検証910後、第1の端末デバイスが真正であることを指示するマッチレポート応答を第2の端末デバイスに送る911ことによって応答する。1つの実施形態では、ステップ912において、第2の端末デバイスは複数の第2の端末デバイスを含み、それによって、ステップ906において始められるように、方法が、ProSeクエリコードおよび第1の発見鍵をそれぞれの第2の端末デバイスに送ることをさらに含むようにする。
ここで、図10を参照して、別の実施形態について説明する。この実施形態1000は、近傍サービスサーバがまた、第2の発見鍵を第2の端末デバイスに送ることによって、第2の端末デバイスがマッチレポート要求を送らずに第1の端末デバイスを検証または認証できるようにする点で、図9を参照して説明される実施形態と異なっている。
第1のステップ1001、1002、1003、1004、1005、1006は、図9におけるステップ901、902、903、904、905、および906に対応するため、詳細な説明は行わないものとする。ステップ1007において、近傍サービスサーバは、第2の発見鍵を第2の端末デバイスに送る。近傍サービスサーバはまた、図9におけるステップ907と同様に、ProSeクエリコードに基づいて発見フィルタを生成し、かつこれを第1の端末デバイスに送る1008。近傍サービスサーバはまた、第2の端末デバイスが通信している第2の近傍サービスサーバにProSe応答コードを送る1009。(これによって、第2の近傍サービスサーバは、近傍サービスサーバの代わりにProSe応答コードに基づいて発見フィルタを生成できる。)なお別の実施形態では、ステップ1010において、第2の端末デバイスは複数の第2の端末デバイスを含み、それによって、方法は、ステップ1006および1007において始められるように、ProSeクエリコード、第1の発見鍵、および第2の発見鍵をそれぞれの端末デバイスに送ることをさらに含む。
ここで、図11を参照して、本発明の別の態様について説明する。図11は、端末デバイス(被発見側UE)によって行われる方法1100を示す。端末デバイスは、その近傍サービスサーバまたはHPLMN ProSe機能とPC3インターフェース上で通信する。端末デバイスはまた、無線インターフェースPC5上で第2の端末デバイス(発見側UE)と通信する。
方法において、端末デバイスは、近傍サービスサーバから、第1の発見鍵、第2の発見鍵、およびProSe応答コードを受信する1102。端末デバイスはまた、ProSeクエリコードおよびトークンを含む直接発見要求を、端末デバイスを発見することを望んでいる第2の端末デバイスから受信する1103。端末デバイスは次いで、第1の発見鍵を使用してトークンを検証する1104。
図12は、方法1200が端末デバイスによって実施されるまたは行われる別の実施形態を示す。この方法では、端末デバイスは、第2の端末デバイスが端末デバイスを発見可能とされるように要求するような発見要求を近傍サービスサーバに送る1201。端末デバイスは、次いで、第1の発見鍵、第2の発見鍵、およびProSe応答コードをこの近傍サービスサーバから受信する1202。該端末デバイスはまた、近傍サービスサーバからProSeクエリコードに基づく発見フィルタを受信する1203。その後、端末デバイスは、ProSeクエリコードおよびトークンを含む直接発見要求を、端末デバイスを発見することを望んでいる第2の端末デバイスから受信する1204。端末デバイスは、無線インターフェース上でProSeクエリコードおよびトークンを受信することができ、トークンは第1の発見鍵に基づく1205。その後、端末デバイスは、第1の発見鍵を使用してトークンを検証する1206。検証が成功する場合、端末デバイスは、第2の発見鍵に基づく第2のトークンを含む発見応答を第2の端末デバイスに送る1207。
ここで、図13を参照して、本発明の別の実施形態について説明する。図13は、ProSe機能とすることができる近傍サービスサーバなどのサーバの方法を示す。近傍サービスサーバは、第1の端末デバイス(発見側UE)と同じ地上波公共移動通信ネットワーク(PLMN)の一部であるため、第1の端末デバイスのホームPLMN ProSe機能であると考えられ得る。第1の端末デバイスおよび近傍サービスサーバは、PC3インターフェース上で情報を送信している。近傍サービスサーバはまた、第2の近傍サービスサーバ、または第2の端末デバイス(被発見側UE)の同じPLMNのProSe機能に対して情報を送りかつ受信している。よって、第2の近傍サービスサーバは、第2の端末デバイスのホームPLMN ProSe機能であると考えられ得る。
この方法1300において、近傍サービスサーバは、第2の近傍サービスサーバから、少なくとも第1の発見鍵、ProSeクエリコード、およびProSe応答コードを受信する1301。近傍サービスサーバは次いで、ProSe応答コードに基づいて発見フィルタを生成し1302、その後、発見フィルタ、第1の発見鍵、およびProSeクエリコードを第1の端末デバイスに送る1303。
ここで、図14を参照して、別の実施形態について説明する。この方法1400はまた、方法1300を行うのと同様に近傍サービスサーバなどのサーバによって行われる。近傍サービスサーバは、第1の端末デバイスが第2の近傍サービスサーバの第2の端末デバイス(被発見側UE)を発見することを望んでいることを指示する発見要求を第1の端末デバイス(発見側UE)から受信する1401。近傍サービスサーバは、次いで、第1の端末デバイスが第2の近傍サービスサーバの第2の端末デバイスを発見することを望んでいることを指示する発見要求を第2の近傍サービスサーバに送るまたは転送する1402。近傍サービスサーバは次いで、少なくとも第1の発見鍵、ProSeクエリコード、およびProSe応答コードを第2の近傍サービスサーバから受信する1403。次のステップ1404において、近傍サービスサーバはProSe応答コードに基づいて発見フィルタを生成する。その後、近傍サービスサーバは、発見フィルタ、第1の発見鍵、およびProSeクエリコードを第1の端末デバイスに送る。
1つの代替策では、近傍サービスサーバは次いで、第2の発見鍵に基づくトークンを含むマッチレポート要求を第1の端末デバイスから受信後、そのトークンを検証のために第2の近傍サーバへ転送する1406。第2の近傍サービスサーバがトークンを検証する場合、方法は、第2の端末デバイスを認証する第2の近傍サーバから応答を受信することをさらに含む、すなわち、近傍サービスサーバは第2の端末デバイスが真正であることを第1の端末デバイスに知らせる1407。
別の代替策では、近傍サービスサーバはトークンを受信および転送しない。その代わりに、近傍サービスサーバは、第2の発見鍵を第2の近傍サービスサーバから受信し、かつ、この第2の発見鍵を第1の端末デバイスに送るまたは転送する1408。こうすることによって、第1の端末デバイスは自身で第2の端末デバイスの検証または認証を行うことができる。
図15では、端末デバイス(発見側)によって行われる方法1500が示される。端末デバイスは、その近傍サービスサーバまたはHPLMN ProSe機能とPC3インターフェース上で通信する。端末デバイスはまた、無線インターフェースPC5上で第2の端末デバイス(被発見側)と通信する。
方法1500では、端末デバイスはProSeクエリコードおよび第1の発見鍵を近傍サービスサーバから受信する1501。該端末デバイスは、次いで、第1の発見鍵に基づくトークンを含む直接発見要求を第2の端末デバイスに送る1502。次のステップ1503では、端末デバイスは、ProSe応答コードおよび第2のトークンを含む発見応答を第2の端末デバイスから受信する1503。
ここで、図16を参照して、方法1600の別の実施形態について説明する。この方法は、方法1500を行うのと同様に端末デバイス(発見側)によって行われる。
この方法1600では、端末デバイスは、ProSeクエリコードおよび第1の発見鍵を近傍サービスサーバから受信する1601。該端末デバイスはまた、ProSe応答コードに基づく発見フィルタを受信する1602。端末デバイスは次いで、第1の発見鍵に基づくトークンを含む直接発見要求を第2の端末デバイス(被発見側UE)に送る1603。それに応じて、端末デバイスは、ProSe応答コードおよび第2のトークンを含む発見応答を第2の端末デバイスから受信する1604。端末デバイスは次いで、発見フィルタを使用して、第2の端末デバイスから受信されたProSe応答コードを特定する1605。
そして、この実施形態には2つの代替策がある。第1の代替策では、端末デバイスは、第2のトークンを検証のためにその近傍サービスサーバに転送する1606。検証が成功する場合、端末デバイスは、第2の端末デバイスが真正であることを指示するメッセージをその近傍サービスサーバから受信する1607。図面には示されないが、別の近傍サービスサーバにおいて、すなわち、第2の端末デバイス(被発見側)の近傍サービスサーバにおいて、トークンの検証が行われる。
第2の代替策では、端末デバイスは、マッチレポートの送信または受信を行わず、代わりに、第2の発見鍵を近傍サービスサーバから受信し、端末デバイスは、第2の発見鍵を使用して第2のトークンを検証することによって、第2の端末デバイスが真正であることを認証するまたは検証する1608。
方法1600のさまざまな実施形態について、方法1600を行う端末デバイスは複数の端末デバイスであってよく、それによって、該方法が、それぞれの端末デバイスが、同じProSeクエリコードおよび第1の発見鍵を受信し、直接発見要求を同じ第2の端末デバイスに送り、および、直接発見応答を上記の第2の端末デバイスから受信することをさらに含むようにする1609ことは、認識されるべきである。
方法800、900、1000、1100、1200、1300、1400、1500、および1600の実施形態全ては、図6および図7を参照して説明されるそれぞれの実施形態の利点を享受する。
上述される方法は、UEであってよい端末デバイスの近傍サービスサーバなどのサーバにおいて、または、端末デバイス自体において、行われてよい。方法は、近傍サービスサーバまたは端末デバイス上で起動するコンピュータプログラム内で具現化可能である適したコンピュータ可読命令の受信時に行われてよい。図17および図18は、例えば、コンピュータプログラムから適した命令を受信すると、本発明の方法を実行することができる近傍サービスサーバ1701および端末デバイス1801の例を示す。図17および図18を参照すると、近傍サービスサーバおよび端末デバイスのそれぞれは、プロセッサおよびメモリを含む。メモリはプロセッサによって実行可能な命令を包含することで、近傍サービスサーバは方法800、900、1000、1300、および1400の実施形態のいずれかを実施するように動作可能である、および/または、端末デバイスは方法1100、1200、1500、1600の実施形態のいずれかを実施するように動作可能である。
図19において、サーバ1901の一実施形態が示されている。サーバ1901は、近傍サービスサーバ、または被発見側の機能を果たす端末デバイスのProSe機能であってよい。サーバはPC6インターフェース1904を含み、このインターフェース上で、サーバは、他の近傍サービスサーバ、または発見側の機能を果たす端末デバイスのProSe機能と通信する。サーバはPC3インターフェース1905をさらに含み、このインターフェース上で、サーバは、同じPLMNに属するその端末デバイス(被発見側)と通信する。サーバ1901はプロセッサ1902およびメモリ1903を含む。メモリはプロセッサによって実行可能な命令を包含することで、近傍サービスデバイスはProSeクエリコードおよびProSe応答コードを生成するように、少なくともProSe応答コードを第1の発見鍵および第2の発見鍵と共に第1の端末デバイスに送るように、および、少なくとも第1の発見鍵およびProSeクエリコードを第2の端末デバイスに送ることによって、第2の端末デバイスが無線インターフェース上で第1の端末デバイスを安全に発見できるように、構成される。
サーバ1901は、第1の発見鍵および第2の発見鍵を生成するように、または第1の発見鍵および第2の発見鍵を鍵管理サーバから受信するように構成されてもよい。
1つの実施形態では、サーバは、ProSeクエリコードに基づいて発見フィルタを生成し、かつそれを第1の端末デバイスに送るように構成される。
1つの実施形態では、サーバ1901は、第2の端末デバイスが無線インターフェース上で第1の端末デバイスを発見することを望んでいることを指示する発見要求を第2の端末デバイスから受信した後、近傍サービスサーバが第1の発見鍵およびProSeクエリコードを第2の端末デバイスに送るように構成される。
サーバ1901は、第2の端末デバイスが通信している第2の近傍サービスサーバにProSe応答コードを送るように構成されてもよい。
1つの実施形態では、サーバ1901は、ProSe応答コード、および第2の発見鍵に基づくトークンを含むマッチレポート要求を第2の端末デバイスから受信するように構成される。サーバは、第2の発見鍵を使用してトークンを検証するようにさらに構成されてよい。トークンが検証される場合、サーバは、第1の端末デバイスが真正であることを指示するマッチレポート応答を第2の端末デバイスに送るように構成可能である。
代替的な実施形態では、サーバ1901は、第1の端末デバイスが真正であることを第2の端末デバイスが検証できるように、第2の発見鍵を第2の端末デバイスに送るように構成されてよい。
サーバが、同じProSeクエリコードおよび同じ第1の発見鍵を、あるグループに属するいくつかの第2の端末デバイスに送るように構成できることは、理解されるべきである。それぞれの第2の端末デバイスはその後、直接発見要求を同じ第1の端末デバイス(被発見側)に送ることができる。よって、ProSeクエリコードおよび第1の発見鍵は特定の第2の端末デバイスに特有ではない。
図20は、例えば、コンピュータプログラムから受信されるコンピュータ可読命令に従って、本明細書に説明される方法800、900、1000のいずれかを実行可能である、第1の端末デバイス(被発見側)の近傍サービスサーバ2001またはProSe機能の別の実施形態における機能ユニットを示す。図20に示されるユニットがソフトウェアで実装される機能ユニットであり、ソフトウェアモジュールの任意の適切な組み合わせで実現可能であることは、理解されるであろう。
図20を参照すると、近傍サービスサーバ2001は、ProSeクエリコードおよびProSe応答コードを生成するための生成ユニット2002と、少なくともProSe応答コードを第1の発見鍵および第2の発見鍵と共に第1の端末デバイスに送り、かつ、少なくとも第1の発見鍵およびProSeクエリコードを第2の端末デバイスに送ることで、第2の端末デバイスが無線インターフェース上で第1の端末デバイスを安全に発見できるようにする送信ユニット2003とを含む。
近傍サービスサーバ2001はまた、ソフトウェアまたはユニットを実行するためのプロセッサ、および種々のユニットを格納するためのメモリを含む。
生成ユニット2002は、第1の発見鍵および第2の発見鍵を生成するための手段を含むこともできる。代替的には、送信ユニット2003は、第1の発見鍵および第2の発見鍵を鍵管理サーバから受信する。
生成ユニット2002は、ProSeクエリコードに基づいて発見フィルタを生成し、かつこれを第1の端末デバイスに送るための手段をさらに含んでよい。
送信ユニット2003は、第2の端末デバイスが無線インターフェース上で第1の端末デバイスを発見することを望んでいることを指示する発見要求を第2の端末デバイスから受信するための手段を含むことができる。送信ユニット2003はまた、第2の端末デバイスが通信している第2の近傍サービスサーバにProSe応答コードを送るためのものであってよい。送信ユニット2003は、ProSe応答コード、および第2の発見鍵に基づくトークンを含むマッチレポート要求を第2の端末デバイスから受信するための手段を含むこともできる。
近傍サービスサーバは、第2の発見鍵を使用してトークンを検証するための検証ユニット2004をさらに含んでよい。これは、図20において破線で示されており、それによって、このユニットがオプションであることを指示する。
代替的な実施形態では、近傍サービスサーバ2001は検証ユニット2004を含まない。この実施形態では、送信ユニット2003は、第2の発見鍵が自身で第1の端末デバイスを検証できるように、第2の発見鍵を第2の端末デバイスに送るための手段を含む。この実施形態では、送信ユニットは、マッチレポート要求を受信すること、またはマッチレポート応答を送ることを行わない。
上述される送信ユニット2003は、上述される情報を第2の端末のグループに送りかつ受信するためのものとすることができ、それによって、送信ユニットは、同じProSeクエリコードおよび第1の発見鍵を該グループのいくつかのメンバに送るようにする。送信ユニット2003は、第2の発見鍵を該グループのいくつかのメンバに送ることもできる。
いくつかの例では、送信ユニット2003、検証ユニット2004、および生成ユニット2002は、コンピュータプログラムの助けを借りて実装可能である。このコンピュータプログラムは、プロセッサ上で起動する時、送信ユニット、検証ユニット、および生成ユニットを、上述される方法800、900、1000の例を実施するように協働させる。
図21は被発見側の機能を果たすことができる端末デバイス2101を示す。端末デバイスは、その近傍サービスサーバまたはProSe機能と通信するためにPC3インターフェース2102を含む。端末デバイスはまた、PC5インターフェース2103を含み、これによって、第2の端末デバイス(発見側)と通信する。端末デバイス2101は、プロセッサ2104およびメモリ2105をさらに含む。メモリはプロセッサによって実行可能な命令を包含し、それによって、端末デバイスは、第1の発見鍵、第2の発見鍵、およびProSe応答コードを近傍サービスサーバから受信するように、ProSeクエリコードおよびトークンを含む直接発見要求を、端末デバイスを発見することを望んでいる第2の端末デバイスから受信するように、および第1の発見鍵を使用してトークンを検証するように構成される。
端末デバイスは、ProSeクエリコードに基づく発見フィルタを近傍サービスサーバから受信するようにさらに構成可能である。発見フィルタは、第2の端末デバイスから受信されたProSeクエリコードを特定するために使用される。第1の端末デバイスは、ProSeクエリコードおよびトークンを無線インターフェース上で受信するように構成されてもよく、トークンは第1の発見鍵に基づく。
1つの実施形態では、端末デバイスは、第2の端末デバイスから受信されたトークンを検証するように構成され、方法は、第2の発見鍵に基づく第2のトークンを含む発見応答を第2の端末デバイスに送ることをさらに含む。端末デバイスはまた、予備ステップとして、第2の端末デバイスが上記の端末デバイスを発見可能とされることを要求するような発見要求をその近傍サービスサーバに送るように構成されてよい。
図22は、例えば、コンピュータプログラムから受信されるコンピュータ可読命令に従って、本明細書に説明される方法1100および1200のいずれかを実行可能である、端末デバイス2201(被発見側)の別の実施形態における機能ユニットを示す。図22に示されるユニットがソフトウェアで実装される機能ユニットであり、ソフトウェアモジュールの任意の適切な組み合わせで実現可能であることは、理解されるであろう。
図22を参照すると、端末デバイス2201は、第1の発見鍵、第2の発見鍵、およびProSe応答コードを近傍サービスサーバから受信し、かつ、端末デバイスを発見することを望んでいる第2の端末デバイス(発見側UE)からProSeクエリコードおよびトークンを含む直接発見要求を受信するための送信ユニット2202を含む。端末デバイス2201は、第1の発見鍵を使用してトークンを検証するための検証ユニット2203をさらに含む。
送信ユニット2202は、ProSeクエリコードに基づく発見フィルタを近傍サービスサーバから受信するための手段をさらに含むことができる。発見フィルタは、第2の端末デバイスから受信されたProSeクエリコードを特定するために使用される。端末デバイスは、発見フィルタを使用してProSeクエリコードを特定するための特定モジュール(図示せず)を含むことができる。
送信ユニットは、無線インターフェース上でProSeクエリコードおよびトークンを受信するための手段を含むこともでき、トークンは第1の発見鍵に基づく。
検証ユニット2203が第2の端末デバイスから受信されたトークンを検証する場合、送信ユニット2204は、第2の発見鍵に基づく第2のトークンを含む発見応答を第2の端末デバイスに送るための手段をさらに含んでよい。
送信ユニット2202は、第2の端末デバイスが上記の端末デバイスを発見可能とされるように要求する発見要求をその近傍サービスサーバに送るための手段をさらに含むことができることも実現可能であるべきである。
いくつかの例では、送信ユニット2202および検証ユニット2203は、コンピュータプログラムの助けを借りて実装可能である。このコンピュータプログラムは、プロセッサ上で起動する時、送信ユニットおよび検証ユニットを、上述される方法1100および1200の例を実施するように協働させる。
図23では、別のサーバ2301の一実施形態が開示される。サーバ2301は、発見側の機能を果たす端末デバイスの近傍サービスサーバまたはProSe機能であってよい。サーバ2301はPC6インターフェース2302を含み、このインターフェース上で、該サーバは、被発見側の機能を果たす端末デバイスの他の近傍サービスサーバまたはProSe機能と通信する。サーバはPC3インターフェース2303をさらに含み、このインターフェース上で、該サーバは、同じPLMNに属するその端末デバイス(発見側)と通信する。サーバ2301はプロセッサ2304およびメモリ2305を含む。メモリ2305はプロセッサによって実行可能な命令を包含することで、近傍サービスデバイスは、少なくとも第1の発見鍵、ProSeクエリコード、およびProSe応答コードを第2の近傍サービスサーバから受信するように、ProSe応答コードに基づいて発見フィルタを生成するように、および、発見フィルタ、第1の発見鍵、およびProSeクエリコードを第1の端末デバイスに送ることによって、第1の端末デバイス(発見側UE)が無線インターフェース上で第2の端末デバイス(被発見側UE)を安全に発見できるように、構成される。
サーバ2301は、第2の発見鍵に基づくトークンを含むマッチレポート要求を第1の端末デバイスから受信し、かつ、そのトークンを検証のために第2の近傍サーバに転送するようにさらに構成されてよい。第2の近傍サーバがトークンを検証する場合、サーバ2301は、第2の端末デバイスが真正であることを指示する応答を第2の近傍サーバから受信するようにさらに構成される。
代替的な実施形態では、サーバ2301は、第2の発見鍵を第2の近傍サービスサーバから受信し、かつ、第2の発見鍵を第1の端末デバイスに送るように構成されてよい。
サーバ2301は、第1の端末デバイスが第2の近傍サービスサーバの第2の端末デバイスを発見することを望んでいることを指示する発見要求を第1の端末デバイスから受信するように構成可能である。
なお別の実施形態では、サーバ2301は、第1の端末デバイスが第2の近傍サービスサーバの第2の端末デバイスを発見することを望んでいることを指示する発見要求を第2の近傍サービスサーバに送るように構成されてよい。
図24は、発見側の機能を果たす端末デバイスの近傍サービスサーバ2401またはProSe機能の別の実施形態における機能ユニットを示す。近傍サービスサーバ2401は、例えば、コンピュータプログラムから受信されるコンピュータ可読命令に従って、本明細書に説明される方法1300および1400のいずれかを実行可能である。図24に示されるユニットがソフトウェアで実装される機能ユニットであり、ソフトウェアモジュールの任意の適切な組み合わせで実現可能であることは、理解されるであろう。
図24を参照すると、近傍サービスサーバ2401は、少なくとも第1の発見鍵、ProSeクエリコード、およびProSe応答コードを第2の近傍サービスサーバから受信する送信ユニット2402と、ProSe応答コードに基づいて発見フィルタを生成する生成ユニット2403とを含む。送信ユニット2402は、発見フィルタ、第1の発見鍵、およびProSeクエリコードを第1の端末デバイスに送るための手段をさらに含むため、第1の端末デバイスは無線インターフェース上で第2の端末デバイスを安全に発見することができる。
送信ユニット2402は、第2の発見鍵に基づくトークンを含むマッチレポート要求を受信し、かつ、トークンを検証のために第2の近傍サーバに転送するための手段をさらに含むことができる。
トークンが検証される場合、送信ユニット2402は、第2の端末デバイスが真正であることを指示する応答を第2の近傍サーバから受信するための手段をさらに含む。
別の実施形態では、送信ユニットは、第2の近傍サービスサーバから第2の発見鍵を受信し、かつ、第2の発見鍵を第1の端末デバイスに送るための手段を含む。
送信ユニット2402は、第1の端末デバイスが第2の近傍サービスサーバの第2の端末デバイスを発見することを望んでいることを指示する発見要求を第1の端末デバイスから受信するための手段をさらに含むことができる。送信ユニット2402は、第1の端末デバイスが第2の近傍サービスサーバの第2の端末デバイスを発見することを望んでいることを指示する発見要求を第2の近傍サービスサーバに送るための手段を含むこともできる。
いくつかの例では、生成ユニット2403および送信ユニット2402は、コンピュータプログラムの助けを借りて実装可能である。このコンピュータプログラムは、プロセッサ上で起動する時、送信ユニット、検証ユニット、および生成ユニットを、上述される方法1300および1400の例を実施するように協働させる。
図25は発見側の機能を果たすことができる端末デバイス2501を示す。端末デバイスは、その近傍サービスサーバまたはProSe機能と通信するためにPC3インターフェース2502を含む。端末デバイス2501はまた、PC5インターフェース2503を含み、これによって、第2の端末デバイス(被発見側)と通信する。端末デバイス2501は、プロセッサ2504およびメモリ2505をさらに含む。メモリはプロセッサによって実行可能な命令を包含し、それによって、端末デバイスは、ProSe応答コードおよび第1の発見鍵を近傍サービスサーバから受信するように、第1の発見鍵に基づくトークンを含む直接発見要求を第2の端末デバイスに送るように、および、ProSe応答コードおよび第2のトークンを含む発見応答を第2の端末デバイスから受信するように構成される。
端末デバイス2501は、ProSe応答コードに基づく発見フィルタを近傍サービスサーバから受信するようにさらに構成可能である。
1つの実施形態では、端末デバイス2501は、発見フィルタを使用して第2の端末デバイスから受信されたProSe応答コードを特定するように構成される。
端末デバイス2501は、第2のトークンを検証のために第2の近傍サービスサーバに転送するようにさらに構成されてよい。第2のトークンが検証される場合、端末デバイスは、第2の端末デバイスが真正であることを指示するメッセージを近傍サービスサーバから受信するように構成可能である。
1つの実施形態では、端末デバイス2501は、近傍サービスサーバから第2の発見鍵を受信し、かつ、第2の発見鍵を使用して第2のトークンを検証することによって第2の端末デバイスを認証するように構成される。
1つの実施形態では、端末デバイス2501は、端末デバイスが第2のデバイスを発見することを望んでいることを指示する発見要求を近傍サービスサーバに送るように構成可能である。
別の実施形態では、複数の端末デバイス2501は、同じProSe応答コードおよび第1の発見鍵を受信するように、直接発見要求を同じ第2の端末デバイスに送るように、および、直接発見応答を上記の同じ第2の端末デバイスから受信するように構成されてよい。
図26は、端末デバイス2601(発見側)の別の実施形態における機能ユニットを示す。該機能ユニットは、例えば、コンピュータプログラムから受信されるコンピュータ可読命令に従って、本明細書に説明される方法1500および1600のいずれかを実行可能である。図26に示されるユニットがソフトウェアで実装される機能ユニットであり、ソフトウェアモジュールの任意の適切な組み合わせで実現可能であることは、理解されるであろう。
図26を参照すると、端末デバイス2601は、ProSeクエリコードおよび第1の発見鍵を近傍サービスサーバから受信し、第1の発見鍵に基づくトークンを含む直接発見要求を第2の端末デバイスに送り、および、ProSe応答コードおよび第2のトークンを含む発見応答を第2の端末デバイスから受信する送信ユニット2602を含む。
送信ユニット2602は、ProSe応答コードに基づく発見フィルタを近傍サービスサーバから受信するための手段をさらに含むことができる。
端末デバイスは、発見フィルタを使用して第2の端末デバイスから受信されたProSe応答コードを特定する特定ユニット2603をさらに含むことができる。このオプションの特徴は、図26における破線によって指示される。
送信ユニット2602は、第2のトークンを検証のために近傍サービスサーバに転送するための手段をさらに含むことができる。第2のトークンが検証される場合、送信ユニットは、第2の端末デバイスが真正であることを指示するメッセージを近傍サービスサーバから受信するための手段をさらに含むことができる。
1つの実施形態では、送信ユニット2602は、第2の発見鍵を近傍サービスサーバから受信するための手段をさらに含み、端末デバイスは、第2の発見鍵を使用して第2のトークンを検証することによって第2の端末デバイスを認証する検証ユニット2604をさらに含む。検証ユニット2604は、図26における破線によって指示されるようにオプションである。
送信ユニット2602は、端末デバイスが第2のデバイスを発見することを望んでいることを指示する発見要求を近傍サービスサーバに送るための手段をさらに含むことができる。
1つの実施形態では、複数の端末デバイス2601があり、それぞれの端末デバイスは、同じProSeクエリコードおよび第1の発見鍵を受信し、直接発見要求を同じ第2の端末デバイスに送り、および、直接発見応答を上記の同じ第2の端末デバイスから受信する送信ユニットを含む。
いくつかの例では、送信ユニット2602、特定ユニット2603、および検証ユニット2604は、コンピュータプログラムの助けを借りて実装可能である。このコンピュータプログラムは、プロセッサ上で起動する時、送信ユニット、検証ユニット、および特定ユニットを、上述される方法1500および1600の例を実施するように協働させる。
上記の実施形態は本発明を例証するものであり限定するものではなく、添付の特許請求の範囲から逸脱することなく当業者が多くの代替的な実施形態を設計できることは留意されるべきである。「含む(comprising)」という単語は、請求項の中で列挙されているもの以外の要素またはステップの存在を排除するものではなく、「a」または「an」は複数のそのような要素を排除するものではない。単一の特徴または他のユニットは、特許請求の範囲に挙げられるいくつかのユニットの機能を果たすことができる。特許請求の範囲におけるいずれの参照符号も、その範囲を限定するとして解釈されるべきではない。