JP2016523044A - 近接サービス提供のための近接サービス探索方法及び装置 - Google Patents

Abstract

【課題】無線通信システムにおいて第１端末の近接サービス（Ｐｒｏｘｉｍｉｔｙ Ｓｅｒｖｉｃｅ；ＰｒｏＳｅ）を行う方法及び装置を提供する。【解決手段】第１端末が第１ネットワークエンティティにＰｒｏＳｅ探索要請（ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ Ｒｅｑｕｅｓｔ）を送信するステップと、第１ネットワークエンティティから、ＰｒｏＳｅ探索応答（ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ Ｒｅｓｐｏｎｓｅ）を受信するステップとを有し、ＰｒｏＳｅ探索応答は、第１端末と第２端末とが予め決定された時間区間に近接関係（ｐｒｏｘｉｍｉｔｙ）が設定されないと判断される場合、ＰｒｏＳｅの拒絶を示すことを特徴とする。【選択図】図１６

Description

本発明の説明は、無線通信システムに関し、特に、近接サービス提供のための近接サービス探索方法及び装置に関する。

近接サービス（Ｐｒｏｘｉｍｉｔｙ Ｓｅｒｖｉｃｅ；ＰｒｏＳｅ）は、物理的に近い場所に位置する各装置（ｄｅｖｉｃｅ）間の通信をサポートする方案を意味する。具体的に、ＰｒｏＳｅは、互いに近接した各装置で動作するアプリケーションを探索（ｄｉｓｃｏｖｅｒ）し、究極的には、アプリケーション―関連データを交換する動作をサポートすることを目的とする。例えば、ソーシャルネットワークサービス（ＳＮＳ）、商業、ゲームなどのアプリケーションにＰｒｏＳｅが適用されることを考慮することができる。

ＰｒｏＳｅは、装置―対―装置（Ｄｅｖｉｃｅ―ｔｏ―Ｄｅｖｉｃｅ；Ｄ２Ｄ）通信と称することもできる。すなわち、複数の装置（例えば、端末（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ；ＵＥ））間に直接的なリンクを設定し、ネットワークを経ずにユーザーデータ（例えば、音声、マルチメディアデータなど）を各装置間で直接取り交わす通信方式をいう。ＰｒｏＳｅ通信は、端末―対―端末（ＵＥ―ｔｏ―ＵＥ）通信、ピア―対―ピア（Ｐｅｅｒ―ｔｏ―Ｐｅｅｒ）通信などの方式を含むことができる。また、ＰｒｏＳｅ通信方式は、Ｍ２Ｍ（Ｍａｃｈｉｎｅ―ｔｏ―Ｍａｃｈｉｎｅ）通信、ＭＴＣ（Ｍａｃｈｉｎｅ Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）などに応用することができる。したがって、ＰｒｏＳｅは、急速に増加するデータトラフィックによる基地局の負担を解決できる一案として考慮されている。また、ＰｒｏＳｅを導入することによって、基地局の手順減少、ＰｒｏＳｅに参加する各装置の消費電力減少、データ伝送速度増加、ネットワークの収容能力増加、負荷分散、セルカバレッジ拡大などの効果を期待することができる。

このようにＰｒｏＳｅの導入の必要性が議論されているが、ＰｒｏＳｅを支援及び制御するためのメカニズムについては具体的な方案がない現状である。

本発明の目的は、ＰｒｏＳｅベースの通信メカニズムと関連して、端末から位置情報を取得するＥＰＣ−レベルＰｒｏＳｅ探索方案を提供することを技術的課題とする。

本発明で遂げようとする技術的課題は、以上で言及した技術的課題に制限されず、言及していない他の技術的課題は、以下の記載から、本発明の属する技術の分野における通常の知識を有する者に明確に理解されるであろう。

上述した問題点を解決するための本発明の一様相である、無線通信システムにおいて第１端末の近接サービス（Ｐｒｏｘｉｍｉｔｙ Ｓｅｒｖｉｃｅ；ＰｒｏＳｅ）を行う方法は、前記第１端末が第１ネットワークエンティティにＰｒｏＳｅ探索要請（ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ Ｒｅｑｕｅｓｔ）を送信するステップと、前記第１ネットワークエンティティから、ＰｒｏＳｅ探索応答（ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ Ｒｅｓｐｏｎｓｅ）を受信するステップとを有し、前記ＰｒｏＳｅ探索応答は、前記第１端末と第２端末とが予め決定された時間区間に近接関係（ｐｒｏｘｉｍｉｔｙ）が設定されないと判断される場合、前記ＰｒｏＳｅの拒絶を示すことを特徴とする。

なお、前記近接関係は、ＨＳＳ（Ｈｏｍｅ Ｓｕｂｓｃｒｉｂｅｒ Ｓｅｒｖｅｒ）を介して受信された位置情報に基づいて判断されたことを特徴とする。また、前記位置情報は、前記ＨＳＳに予め記憶された位置情報であるか、ＭＭＥ（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）によって送信された位置情報であることを特徴とし、前記位置情報は、前記第１端末或いは前記第２端末のうち少なくとも一つの位置情報であることを特徴とする。

なお、前記近接関係は、前記第１端末と前記第２端末が、所定の距離以上で位置する場合、近接関係（ｐｒｏｘｉｍｉｔｙ）が設定されないと判断されることを特徴とする。また、前記所定の距離は、前記第１端末と前記第２端末間の実際距離値、或いは前記第１端末と前記第２端末間の距離類推のための情報であることを特徴とし、好ましくは、前記所定の距離は、予め設定（ｃｏｎｆｉｇｕｒｅ）されたり、又は第２ネットワークエンティティから取得されることを特徴とする。

なお、前記ＰｒｏＳｅの拒絶は、近接関係確認（ｐｒｏｘｉｍｉｔｙ ｃｈｅｃｋ）、近接関係要請手順（ｐｒｏｘｉｍｉｔｙ ｒｅｑｕｅｓｔ ｐｒｏｃｅｄｕｒｅ）、位置報告手順（ｌｏｃａｔｉｏｎ ｒｅｐｏｒｔｉｎｇ ｐｒｏｃｅｄｕｒｅ）、或いはＰｒｏＳｅ探索のいずれかの手順を行わないことを指示することを特徴とする。

なお、前記ＰｒｏＳｅ探索応答は、前記第１端末と前記第２端末に関する、近接関係にあるか否か、近接関係設定が可能か否か、或いは前記第１端末と前記第２端末間の距離情報のうち少なくとも一つをさらに含むことを特徴とする。

なお、前記予め決定された時間区間は、前記ＰｒｏＳｅ探索要請（ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ Ｒｅｑｕｅｓｔ）に含まれて送信されたことを特徴とする。

なお、前記ＰｒｏＳｅ探索応答は、前記第１ネットワークエンティティによって決定され、前記第１ネットワークエンティティは、ＰｒｏＳｅサーバー又はＰｒｏＳｅ Ｆｕｎｃｔｉｏｎであることを特徴とする。

なお、前記近接関係は、前記第１端末と前記第２端末間の最初の近接関係の判断時に決定されることを特徴とする。

上述した問題点を解決するための本発明の他の様相である、無線通信システムにおいて第１ネットワークエンティティの近接サービス（Ｐｒｏｘｉｍｉｔｙ Ｓｅｒｖｉｃｅ；ＰｒｏＳｅ）を支援する方法は、前記第１ネットワークエンティティが第１端末からＰｒｏＳｅ探索要請（ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ Ｒｅｑｕｅｓｔ）を受信するステップと、前記第１ネットワークエンティティから前記第１端末に、ＰｒｏＳｅ探索応答（ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ Ｒｅｓｐｏｎｓｅ）を送信するステップとを有し、前記ＰｒｏＳｅ探索応答は、前記第１端末と第２端末が予め決定された時間区間に近接関係（ｐｒｏｘｉｍｉｔｙ）が設定されないと判断される場合、前記ＰｒｏＳｅの拒絶を示すことを特徴とする。

上述した問題点を解決するための本発明の更に他の様相である、無線通信システムにおいて近接サービス（Ｐｒｏｘｉｍｉｔｙ Ｓｅｒｖｉｃｅ；ＰｒｏＳｅ）を行う第１端末は、無線周波数ユニットと、プロセッサとを備え、前記プロセッサは、前記第１端末が第１ネットワークエンティティにＰｒｏＳｅ探索要請（ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ Ｒｅｑｕｅｓｔ）を送信し、前記第１ネットワークエンティティから、ＰｒｏＳｅ探索応答（ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ Ｒｅｓｐｏｎｓｅ）を受信するように構成され、前記ＰｒｏＳｅ探索応答は、前記第１端末と第２端末とが予め決定された時間区間に近接関係（ｐｒｏｘｉｍｉｔｙ）が設定されないと判断される場合、前記ＰｒｏＳｅの拒絶を示すことを特徴とする。

上述した問題点を解決するための本発明の更に他の様相である、無線通信システムにおいて近接サービス（Ｐｒｏｘｉｍｉｔｙ Ｓｅｒｖｉｃｅ；ＰｒｏＳｅ）を支援する第１ネットワークエンティティは、無線周波数ユニットと、プロセッサとを備え、前記プロセッサは、第１端末からＰｒｏＳｅ探索要請（ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ Ｒｅｑｕｅｓｔ）を受信し、前記第１端末にＰｒｏＳｅ探索応答（ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ Ｒｅｓｐｏｎｓｅ）を送信するように構成され、前記ＰｒｏＳｅ探索応答は、前記第１端末と第２端末とが予め決定された時間区間に近接関係（ｐｒｏｘｉｍｉｔｙ）が設定されないと判断される場合、前記ＰｒｏＳｅの拒絶を示すことを特徴とする。

本発明によれば、端末から正確な位置情報を取得してＥＰＣ−レベルＰｒｏＳｅ探索を行うことによって、効率的な通信を行うことができる。

本発明から得られる効果は、以上で言及した効果に制限されず、言及していない他の効果は、以下の記載から、本発明の属する技術の分野における通常の知識を有する者にとって明らかになるであろう。

本発明に関する理解を助けるために詳細な説明の一部として含まれる添付の図面は、本発明に関する実施例を提供し、詳細な説明と共に本発明の技術的思想を説明する。

ＥＰＣ（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｃｏｒｅ）を含むＥＰＳ（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｓｙｓｔｅｍ）の概略的な構造を示す図である。 ＥＰＳにおいて２つのＵＥが通信する基本的なデータ経路（ｄｅｆａｕｌｔ ｄａｔａ ｐａｔｈ）を示す図である。 ＰｒｏＳｅに基づく２つのＵＥ間の直接モードデータ経路（ｄｉｒｅｃｔ ｍｏｄｅ ｄａｔａ ｐａｔｈ）を示す図である。 ＰｒｏＳｅに基づく２つのＵＥ間のローカルルーティング方式データ経路（ｌｏｃａｌｌｙ−ｒｏｕｔｅｄ ｄａｔａ ｐａｔｈ）を示す図である。 本発明の第１方案に基づく第１実施例に係るＰｒｏＳｅ探索動作を示す参考図である。 本発明の第２方案に基づく第２実施例に係るＰｒｏＳｅ探索動作を示す参考図である。 本発明の第１方案に基づく第３実施例に係るＰｒｏＳｅ探索動作を示す参考図である。 本発明の第２方案に基づく第４実施例に係るＰｒｏＳｅ探索動作を示す参考図である。 本発明の第１方案に基づく共有ネットワークでのＰｒｏＳｅ探索動作を示す参考図である。 本発明の一実施例によって、時間区間（ｔｉｍｅ ｗｉｎｄｏｗ）を適用したＰｒｏＳｅ探索動作を示す参考図である。 本発明に係るＥＰＣ−レベル近接サービス探索（ＥＰＣ−ｌｅｖｅｌ ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ）を説明するための参考図である。 本発明に係るＥＰＣ−レベル近接サービス探索（ＥＰＣ−ｌｅｖｅｌ ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ）を説明するための参考図である。 本発明に係るＥＰＣ−レベル近接サービス探索（ＥＰＣ−ｌｅｖｅｌ ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ）を説明するための参考図である。 本発明に係るＥＰＣ−レベル近接サービス探索（ＥＰＣ−ｌｅｖｅｌ ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ）を説明するための参考図である。 本発明に係るＥＰＣ−レベル近接サービス探索（ＥＰＣ−ｌｅｖｅｌ ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ）を説明するための参考図である。 本発明に係るＥＰＣ−レベル近接サービス探索（ＥＰＣ−ｌｅｖｅｌ ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ）を説明するための参考図である。 本発明に係るＥＰＣ−レベル近接サービス探索（ＥＰＣ−ｌｅｖｅｌ ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ）を説明するための参考図である。 本発明に係るＥＰＣ−レベル近接サービス探索（ＥＰＣ−ｌｅｖｅｌ ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ）を説明するための参考図である。 本発明に係るＥＰＣ−レベル近接サービス探索（ＥＰＣ−ｌｅｖｅｌ ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ）を説明するための参考図である。 本発明に係るＥＰＣ−レベル近接サービス探索（ＥＰＣ−ｌｅｖｅｌ ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ）を説明するための参考図である。 本発明に係るＥＰＣ−レベル近接サービス探索（ＥＰＣ−ｌｅｖｅｌ ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ）を説明するための参考図である。 本発明に係るＥＰＣ−レベル近接サービス探索（ＥＰＣ−ｌｅｖｅｌ ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ）を説明するための参考図である。 本発明に係るＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ関連Ｐｒｏｘｉｍｉｔｙ Ｒｅｑｕｅｓｔを説明するための参考図である。 本発明に係るＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ関連Ｐｒｏｘｉｍｉｔｙ Ａｌｅｒｔを説明するための参考図である。 本発明に係るＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ関連Ｐｒｏｘｉｍｉｔｙ Ｒｅｑｕｅｓｔ Ｃａｎｃｅｌｌａｔｉｏｎを説明するための参考図である。 本発明の好適な実施例に係る端末装置及びネットワークノード装置の構成を示す図である。

以下の実施例は、本発明の構成要素と特徴を所定の形態で結合したものである。各構成要素又は特徴は、別の明示的言及がない限り、選択的なものとして考慮することができる。各構成要素又は特徴は、他の構成要素や特徴と結合しない形態で実施することができる。また、一部の構成要素及び／又は特徴を結合して本発明の実施例を構成することもできる。本発明の実施例で説明する動作の順序は変更されてもよい。ある実施例の一部の構成や特徴は他の実施例に含まれてもよく、他の実施例の対応する構成又は特徴に取って代わってもよい。

以下の説明で使われる特定用語は、本発明の理解を助けるために提供されたものであり、このような特定用語の使用は、本発明の技術的思想から逸脱しない範囲で他の形態に変更されてもよい。

いくつかの場合、本発明の概念が曖昧になることを避けるために、公知の構造及び装置は省略されてもよく、各構造及び装置の核心機能を中心にしたブロック図の形式で図示されてもよい。また、本明細書全体を通じて同一の構成要素については同一の図面符号を付しい説明する。

本発明の実施例は、ＩＥＥＥ（Ｉｎｓｔｉｔｕｔｅ ｏｆ Ｅｌｅｃｔｒｉｃａｌ ａｎｄ Ｅｌｅｃｔｒｏｎｉｃｓ Ｅｎｇｉｎｅｅｒｓ）８０２系列システム、３ＧＰＰシステム、３ＧＰＰ ＬＴＥ及びＬＴＥ−Ａシステム、及び３ＧＰＰ２システムのうち少なくとも一つに関連して開示された標準文書によってサポートすることができる。すなわち、本発明の実施例において、本発明の技術的思想を明確にするために説明を省いた段階又は部分は、上記の文書によってサポートすることができる。また、本文書で開示している用語はいずれも、上記の標準文書によって説明することができる。

以下の技術は、様々な無線通信システムに用いることができる。明確性のために以下では３ＧＰＰ ＬＴＥ及び３ＧＰＰ ＬＴＥ−Ａシステムを中心に説明するが、本発明の技術的思想がこれに制限されるものではない。

本文書で使われる用語は、次のように定義される。

− ＵＭＴＳ（Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｙｓｔｅｍ）：３ＧＰＰによって開発された、ＧＳＭ（Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）ベースの３世代（Ｇｅｎｅｒａｔｉｏｎ）移動通信技術。

− ＥＰＳ（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｓｙｓｔｅｍ）：ＩＰベースのパケット交換コアネットワーク（ｐａｃｋｅｔ ｓｗｉｔｃｈｅｄ ｎｅｔｗｏｒｋ）であるＥＰＣ（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｃｏｒｅ）と、ＬＴＥ、ＵＴＲＡＮなどのアクセスネットワークで構成されたネットワークシステム。ＵＭＴＳが進化した形態のネットワークである。

− ＮｏｄｅＢ：ＧＥＲＡＮ／ＵＴＲＡＮの基地局。屋外に設置され、カバレッジはマクロセル（ｍａｃｒｏ ｃｅｌｌ）規模である。

− ｅＮｏｄｅＢ：ＬＴＥの基地局。屋外に設置され、カバレッジはマクロセル（ｍａｃｒｏ ｃｅｌｌ）規模である。

− ＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）：ユーザ機器。ＵＥは、端末（ｔｅｒｍｉｎａｌ）、ＭＥ（Ｍｏｂｉｌｅ Ｅｑｕｉｐｍｅｎｔ）、ＭＳ（Ｍｏｂｉｌｅ Ｓｔａｔｉｏｎ）などの用語に言い換えてもよい。また、ＵＥは、ノートパソコン、携帯電話、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）、スマートフォン、マルチメディア機器などのように携帯可能な機器であってもよく、又はＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）、車両搭載装置のように携帯不可能な機器であってもよい。ＵＥは、ＬＴＥのような３ＧＰＰスペクトル（ｓｐｅｃｔｒｕｍ）及び／又はＷｉＦｉ、公共安全（Ｐｕｂｌｉｃ Ｓａｆｅｔｙ）用スペクトルのような非−３ＧＰＰスペクトルで通信可能なＵＥである。

− 近接サービス（Ｐｒｏｘｉｍｉｔｙ Ｓｅｒｖｉｃｅｓ又はＰｒｏｘｉｍｉｔｙ−ｂａｓｅｄ Ｓｅｒｖｉｃｅｓ；ＰｒｏＳｅ）：物理的に近接している装置間の探索（ｄｉｓｃｏｖｅｒｙ）、及び相互直接的な通信／基地局を介した通信／第３の装置を介した通信を可能にするサービス。このとき、ユーザプレーンデータ（ｕｓｅｒ ｐｌａｎｅ ｄａｔａ）は３ＧＰＰコアネットワーク（例えば、ＥＰＣ）を経ずに直接データ経路（ｄｉｒｅｃｔ ｄａｔａ ｐａｔｈ）（又は、直接モードデータ経路（ｄｉｒｅｃｔ ｍｏｄｅ ｄａｔａ ｐａｔｈ））を通じて交換される。Ｄ２Ｄ（Ｄｅｖｉｃｅ−ｔｏ−Ｄｅｖｉｃｅ）サービスとも呼ばれる。

− 近接性（Ｐｒｏｘｉｍｉｔｙ）：一つのＵＥが他のＵＥと近接しているか否かは、所定の近接性基準を満たすか否かによって決定される。近接性基準は、ＰｒｏＳｅ探索（ｄｉｓｃｏｖｅｒｙ）及びＰｒｏＳｅ通信（ｃｏｍｍｕｎｉｃａｔｉｏｎ）に対して異なるように与えられてもよい。また、近接性基準は、事業者の制御対象として設定されてもよい。

− 近接サービス探索（ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ）：Ｅ−ＵＴＲＡを用いてあるＵＥが他のＵＥに近接しているか否かを識別する過程。

− 近接サービス通信（ＰｒｏＳｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）：ＵＥの間に形成された（ｅｓｔａｂｌｉｓｈｅｄ）通信経路を通じて行われる近接しているＵＥの間の通信。通信経路は、ＵＥの間に直接的に形成されてもよく、ローカル基地局（ｅＮｏｄｅＢ）を介してルーティングされてもよい。

− 近接サービス−可能ＵＥ（ＰｒｏＳｅ−ｅｎａｂｌｅｄ ＵＥ）：ＰｒｏＳｅ探索及び／又はＰｒｏＳｅ通信を支援するＵＥ。以下ではＵＥと呼ぶ。

− 近接サービス−可能ネットワーク（ＰｒｏＳｅ−ｅｎａｂｌｅｄ Ｎｅｔｗｏｒｋ）：ＰｒｏＳｅ探索及び／又はＰｒｏＳｅ通信を支援するネットワーク。以下ではネットワークと呼ぶ。

− 近接サービスＥ−ＵＴＲＡ通信（ＰｒｏＳｅ Ｅ−ＵＴＲＡ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）：ＰｒｏＳｅ Ｅ−ＵＴＲＡ通信経路（Ｃｏｍｍｕｎｉｃａｔｉｏｎ ｐａｔｈ）を用いるＰｒｏＳｅ通信を意味する。

− 近接サービス支援ＷＬＡＮ直接通信（ＰｒｏＳｅ−ａｓｓｉｓｔｅｄ ＷＬＡＮ ｄｉｒｅｃｔ ｃｏｍｍｕｎｉｃａｔｉｏｎ）：近接サービス支援ＷＬＡＮ直接通信経路を用いるＰｒｏＳｅ通信を意味する。ＥＰＣ支援ＷＬＡＮ直接通信（ＥＰＣ−ａｓｓｉｓｔｅｄ ＷＬＡＮ ｄｉｒｅｃｔ ｃｏｍｍｕｎｉｃａｔｉｏｎ）と呼ぶこともできる。

− 近接サービスグループ通信（ＰｒｏＳｅ Ｇｒｏｕｐ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）：近接サービス−可能端末の間の共通通信経路（ｃｏｍｍｏｎ ｃｏｍｍｕｎｉｃａｔｉｏｎ ｐａｔｈ）設定方法であり、近接している２つ以上の近接サービス−可能端末（ＰｒｏＳｅ−ｅｎａｂｌｅｄ ＵＥ）同士の１対多近接サービス通信（ｏｎｅ−ｔｏ−ｍａｎｙ ＰｒｏＳｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）を意味する。

− 近接サービスブロードキャスト通信（ＰｒｏＳｅ Ｂｒｏａｄｃａｓｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）：近接サービス−可能端末の間の共通通信経路（ｃｏｍｍｏｎ ｃｏｍｍｕｎｉｃａｔｉｏｎ ｐａｔｈ）設定方法であり、近接している２つ以上の近接サービス−可能端末（ＰｒｏＳｅ−ｅｎａｂｌｅｄ ＵＥ）同士の１対全部近接サービス通信（ｏｎｅ−ｔｏ−ａｌｌ ＰｒｏＳｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）を意味する。

− 近接サービスＵＥ−ｔｏ−Ｎｅｔｗｏｒｋ中継（ＰｒｏＳｅ ＵＥ−ｔｏ−Ｎｅｔｗｏｒｋ Ｒｅｌａｙ）：近接サービス−可能公共安全用端末（ｐｕｂｌｉｃ ｓａｆｅｔｙ ＵＥ）であり、近接サービス−可能公共安全用端末（ｐｕｂｌｉｃ ｓａｆｅｔｙ ＵＥ）とＥ−ＵＴＲＡを用いる近接サービス−可能ネットワークとの間で通信リレーとして動作するリレーの形態。

− 近接サービスＵＥ−ｔｏ−ＵＥ中継（ＰｒｏＳｅ ＵＥ−ｔｏ−ＵＥ Ｒｅｌａｙ）：近接サービス−可能公共安全用端末（ｐｕｂｌｉｃ ｓａｆｅｔｙ ＵＥ）であり、近接サービス−可能公共安全用端末（ｐｕｂｌｉｃ ｓａｆｅｔｙ ＵＥ）同士の間の近接サービス通信リレーとして動作するリレーの形態。

− ＩＳＲ（Ｉｄｌｅ Ｍｏｄｅ Ｓｉｇｎａｌｉｎｇ Ｒｅｄｕｃｔｉｏｎ）：端末がＥ−ＵＴＲＡＮとＵＴＲＡＮ／ＧＥＲＡＮとの間を頻繁に移動する場合、反復的な位置登録手順によるネットワークリソースの浪費が発生する。これを低減するための方法として、端末が遊休モードである場合、Ｅ−ＵＴＲＡＮとＵＴＲＡＮ／ＧＥＲＡＮを経由してそれぞれＭＭＥとＳＧＳＮ（以下、これら２つのノードを移動性管理モジュール（ｍｏｂｉｌｉｔｙ ｍａｎａｇｅｍｅｎｔ ｎｏｄｅ）という。）に位置登録した後、既に登録した２つのＲＡＴ（Ｒａｄｉｏ Ａｃｃｅｓｓ Ｔｅｃｈｎｏｌｏｇｙ）間の移動或いはセル再選択を行った場合、別途の位置登録をしないようにする技術である。したがって、当該端末への下りリンク（ＤＬ）データが到着する場合、ページングをＥ−ＵＴＲＡＮとＵＴＲＡＮ／ＧＥＲＡＮで同時に送ることによって、端末を成功的に探して下りリンクデータを伝達することができる。その更なる内容は、３ＧＰＰ ＴＳ ２３．４０１及び３ＧＰＰ ＴＳ ２３．０６０を参照することができる。

− ＲＡＮ（Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）：３ＧＰＰネットワークにおいてＮｏｄｅＢ、ｅＮｏｄｅＢ及びそれらを制御するＲＮＣ（Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌｌｅｒ）を含む単位。ＵＥとコアネットワークとの間に存在し、コアネットワークへの接続を提供する。

− ＨＬＲ（Ｈｏｍｅ Ｌｏｃａｔｉｏｎ Ｒｅｇｉｓｔｅｒ）／ＨＳＳ（Ｈｏｍｅ Ｓｕｂｓｃｒｉｂｅｒ Ｓｅｒｖｅｒ）：３ＧＰＰネットワーク内の加入者情報を有しているデータベース。ＨＳＳは、設定記憶（ｃｏｎｆｉｇｕｒａｔｉｏｎ ｓｔｏｒａｇｅ）、アイデンティティー管理（ｉｄｅｎｔｉｔｙ ｍａｎａｇｅｍｅｎｔ）、ユーザ状態記憶などの機能を有することができる。

− ＲＡＮＡＰ（ＲＡＮ Ａｐｐｌｉｃａｔｉｏｎ Ｐａｒｔ）：ＲＡＮとコアネットワークの制御を担当するノード（ＭＭＥ（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）／ＳＧＳＮ（Ｓｅｒｖｉｎｇ ＧＰＲＳ（Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ） Ｓｕｐｐｏｒｔｉｎｇ Ｎｏｄｅ）／ＭＳＣ（Ｍｏｂｉｌｅｓ Ｓｗｉｔｃｈｉｎｇ Ｃｅｎｔｅｒ））との間のインターフェース。

− ＰＬＭＮ（Ｐｕｂｌｉｃ Ｌａｎｄ Ｍｏｂｉｌｅ Ｎｅｔｗｏｒｋ）：個人に移動通信サービスを提供する目的で構成されたネットワーク。オペレーター別に区分して構成することができる。

− ＮＡＳ（Ｎｏｎ−Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）：ＵＭＴＳプロトコルスタックにおいてＵＥとコアネットワーク間のシグナリング、トラフィックメッセージを授受するための機能的な階層。ＵＥの移動性を支援し、ＵＥとＰＤＮ ＧＷ（Ｐａｃｋｅｔ Ｄａｔａ Ｎｅｔｗｏｒｋ Ｇａｔｅｗａｙ）間のＩＰ接続を形成（ｅｓｔａｂｌｉｓｈ）及び維持（ｍａｉｎｔａｉｎ）するセッション管理手順（ｐｒｏｃｅｄｕｒｅ）を支援することを主な機能とする。

− ＨＮＢ（Ｈｏｍｅ ＮｏｄｅＢ）：ＵＴＲＡＮ（ＵＭＴＳ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）カバレッジを提供するＣＰＥ（Ｃｕｓｔｏｍｅｒ Ｐｒｅｍｉｓｅｓ Ｅｑｕｉｐｍｅｎｔ）。その更なる事項は、標準文書ＴＳ ２５．４６７を参照することができる。

− ＨｅＮｏｄｅＢ（Ｈｏｍｅ ｅＮｏｄｅＢ）：Ｅ−ＵＴＲＡＮ（Ｅｖｏｌｖｅｄ−ＵＴＲＡＮ）カバレッジを提供するＣＰＥ（Ｃｕｓｔｏｍｅｒ Ｐｒｅｍｉｓｅｓ Ｅｑｕｉｐｍｅｎｔ）。その更なる事項は、標準文書ＴＳ３６．３００を参照することができる。

− ＣＳＧ（Ｃｌｏｓｅｄ Ｓｕｂｓｃｒｉｂｅｒ Ｇｒｏｕｐ）：Ｈ（ｅ）ＮＢのＣＳＧの構成員であり、ＰＬＭＮ（Ｐｕｂｌｉｃ Ｌａｎｄ Ｍｏｂｉｌｅ Ｎｅｔｗｏｒｋ）内の一つ以上のＣＳＧセルにアクセスすることが許容される加入者グループ。

− ＬＩＰＡ（Ｌｏｃａｌ ＩＰ Ａｃｃｅｓｓ）：ＩＰ機能を持つ（ＩＰ ｃａｐａｂｌｅ）ＵＥがＨ（ｅ）ＮＢを経由して、同じ住居（ｒｅｓｉｄｅｎｔｉａｌ）／企業（ｅｎｔｅｒｐｒｉｓｅ）ＩＰネットワーク内の他のＩＰ機能を持つ個体へのアクセス。ＬＩＰＡトラフィックは移動事業者（ｏｐｅｒａｔｏｒ）ネットワークを経由しない。３ＧＰＰリリース−１０システムでは、Ｈ（ｅ）ＮＢを経由してローカルネットワーク（すなわち、顧客（ｃｕｓｔｏｍｅｒ）の家又は会社構内に位置しているネットワーク）上のリソースへのアクセスを提供する。

− ＳＩＰＴＯ（Ｓｅｌｅｃｔｅｄ ＩＰ Ｔｒａｆｆｉｃ Ｏｆｆｌｏａｄ）：３ＧＰＰリリース−１０システムでは事業者がＥＰＣネットワークでＵＥに物理的に近接しているＰＧＷ（Ｐａｃｋｅｔ ｄａｔａ ｎｅｔｗｏｒｋ ＧａｔｅＷａｙ）を選択することによってユーザのトラフィックを渡すことを支援する。

− ＰＤＮ（Ｐａｃｋｅｔ Ｄａｔａ Ｎｅｔｗｏｒｋ）接続：一つのＩＰアドレス（一つのＩＰｖ４アドレス及び／又は一つのＩＰｖ６プリフィクス）で表現されるＵＥとＡＰＮ（Ａｃｃｅｓｓ Ｐｏｉｎｔ Ｎａｍｅ）で表現されるＰＤＮ間の論理的な接続。

ＥＰＣ（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｃｏｒｅ）

図１は、ＥＰＣ（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｃｏｒｅ）を含むＥＰＳ（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｓｙｓｔｅｍ）の概略的な構造を示す図である。

ＥＰＣは、３ＧＰＰ技術の性能を向上するためのＳＡＥ（Ｓｙｓｔｅｍ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｅｖｏｌｕｔｉｏｎ）の核心的な要素である。ＳＡＥは、種々のネットワーク間の移動性を支援するネットワーク構造を決定する研究課題に該当する。ＳＡＥは、例えば、ＩＰベースに様々な無線接続技術を支援し、より向上したデータ送信能力を提供するなどの最適化されたパケット−ベースシステムを提供することを目標とする。

具体的に、ＥＰＣは、３ＧＰＰ ＬＴＥシステムのためのＩＰ移動通信システムのコアネットワーク（Ｃｏｒｅ Ｎｅｔｗｏｒｋ）であり、パケット−ベース実時間及び非実時間サービスを支援することができる。既存の移動通信システム（すなわち、２世代又は３世代移動通信システム）では、音声のためのＣＳ（Ｃｉｒｃｕｉｔ−Ｓｗｉｔｃｈｅｄ）及びデータのためのＰＳ（Ｐａｃｋｅｔ−Ｓｗｉｔｃｈｅｄ）といった２つの区別されるサブ−ドメインを通じてコアネットワークの機能を具現している。しかし、３世代移動通信システムの進化である３ＧＰＰ ＬＴＥシステムでは、ＣＳ及びＰＳのサブ−ドメインを１つのＩＰドメインに単一化した。すなわち、３ＧＰＰ ＬＴＥシステムでは、ＩＰ能力（ｃａｐａｂｉｌｉｔｙ）を有する端末と端末との接続を、ＩＰベースの基地局（例えば、ｅＮｏｄｅＢ（ｅｖｏｌｖｅｄ Ｎｏｄｅ Ｂ））、ＥＰＣ、アプリケーションドメイン（例えば、ＩＭＳ（ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ））を通じて構成することができる。すなわち、ＥＰＣは、端−対−端（ｅｎｄ−ｔｏ−ｅｎｄ）ＩＰサービス具現に必須な構造である。

ＥＰＣは、様々な構成要素を含むことができ、図１では、その一部に該当する、ＳＧＷ（Ｓｅｒｖｉｎｇ Ｇａｔｅｗａｙ）、ＰＤＮ ＧＷ（Ｐａｃｋｅｔ Ｄａｔａ Ｎｅｔｗｏｒｋ Ｇａｔｅｗａｙ）、ＭＭＥ（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）、ＳＧＳＮ（Ｓｅｒｖｉｎｇ ＧＰＲＳ（Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ） Ｓｕｐｐｏｒｔｉｎｇ Ｎｏｄｅ）、ｅＰＤＧ（ｅｎｈａｎｃｅｄ Ｐａｃｋｅｔ Ｄａｔａ Ｇａｔｅｗａｙ）を示している。

ＳＧＷは、無線接続ネットワーク（ＲＡＮ）とコアネットワーク間の境界点として動作し、ｅＮｏｄｅＢとＰＤＮ ＧＷ間のデータ経路を維持する機能を果たす要素である。また、端末がｅＮｏｄｅＢによってサービング（ｓｅｒｖｉｎｇ）される領域にわたって移動する場合、ＳＧＷはローカル移動性アンカーポイント（ａｎｃｈｏｒ ｐｏｉｎｔ）の役割を担う。すなわち、Ｅ−ＵＴＲＡＮ（３ＧＰＰリリース−８以降に定義されるＥｖｏｌｖｅｄ−ＵＭＴＳ（Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｙｓｔｅｍ） Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）内における移動性のためにＳＧＷを介してパケットがルーティングされてもよい。また、ＳＧＷは、他の３ＧＰＰネットワーク（３ＧＰＰリリース−８の前に定義されるＲＡＮ、例えば、ＵＴＲＡＮ又はＧＥＲＡＮ（ＧＳＭ（Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）／ＥＤＧＥ（Ｅｎｈａｎｃｅｄ Ｄａｔａ ｒａｔｅｓ ｆｏｒ Ｇｌｏｂａｌ Ｅｖｏｌｕｔｉｏｎ）Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）との移動性のためのアンカーポイントとして機能することもできる。

ＰＤＮ ＧＷ（又は、Ｐ−ＧＷ）は、パケットデータネットワークに向かうデータインターフェースの終了点（ｔｅｒｍｉｎａｔｉｏｎ ｐｏｉｎｔ）に該当する。ＰＤＮ ＧＷは、政策執行特徴（ｐｏｌｉｃｙ ｅｎｆｏｒｃｅｍｅｎｔ ｆｅａｔｕｒｅｓ）、パケットフィルタリング（ｐａｃｋｅｔ ｆｉｌｔｅｒｉｎｇ）、課金支援（ｃｈａｒｇｉｎｇ ｓｕｐｐｏｒｔ）などを支援することができる。また、３ＧＰＰネットワークと非−３ＧＰＰネットワーク（例えば、Ｉ−ＷＬＡＮ（Ｉｎｔｅｒｗｏｒｋｉｎｇ Ｗｉｒｅｌｅｓｓ Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）のような信頼できないネットワーク、ＣＤＭＡ（Ｃｏｄｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）ネットワークやＷｉＭａｘのような信頼できるネットワーク）との移動性管理のためのアンカーポイントの役割を担うことができる。

図１のネットワーク構造の例示ではＳＧＷとＰＤＮ ＧＷが別のゲートウェイとして構成されているが、２つのゲートウェイが単一ゲートウェイ構成オプション（Ｓｉｎｇｌｅ Ｇａｔｅｗａｙ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｏｐｔｉｏｎ）によって具現されてもよい。

ＭＭＥは、ＵＥのネットワーク接続に対するアクセス、ネットワークリソースの割り当て、トラッキング（ｔｒａｃｋｉｎｇ）、ページング（ｐａｇｉｎｇ）、ローミング（ｒｏａｍｉｎｇ）及びハンドオーバーなどを支援するためのシグナリング及び制御機能を有する要素である。ＭＭＥは、加入者及びセッション管理に関連したコントロールプレーン（ｃｏｎｔｒｏｌ ｐｌａｎｅ）機能を制御する。ＭＭＥは、多数のｅＮｏｄｅＢを管理し、他の２Ｇ／３Ｇネットワークへのハンドオーバーのための従来のゲートウェイの選択のためのシグナリングを行う。また、ＭＭＥは、保安過程（Ｓｅｃｕｒｉｔｙ Ｐｒｏｃｅｄｕｒｅｓ）、端末−対−ネットワークセッションハンドリング（Ｔｅｒｍｉｎａｌ−ｔｏ−ｎｅｔｗｏｒｋ Ｓｅｓｓｉｏｎ Ｈａｎｄｌｉｎｇ）、遊休端末位置決定管理（Ｉｄｌｅ Ｔｅｒｍｉｎａｌ Ｌｏｃａｔｉｏｎ Ｍａｎａｇｅｍｅｎｔ）などの機能を有する。

ＳＧＳＮは、他の３ＧＰＰネットワーク（例えば、ＧＰＲＳネットワーク）に対するユーザの移動性管理及び認証（ａｕｔｈｅｎｔｉｃａｔｉｏｎ）のような全てのパケットデータをハンドリングする。

ｅＰＤＧは、信頼できない非−３ＧＰＰネットワーク（例えば、Ｉ−ＷＬＡＮ、ＷｉＦｉホットスポット（ｈｏｔｓｐｏｔ）など）に対する保安ノードとしての役割を有する。

図１を参照して説明したように、ＩＰ能力を有する端末は、３ＧＰＰアクセスはもとより、非−３ＧＰＰアクセスに基づいても、ＥＰＣにおける様々な要素を経由して事業者（すなわち、オペレーター（ｏｐｅｒａｔｏｒ））が提供するＩＰサービスネットワーク（例えば、ＩＭＳ）にアクセスすることができる。

また、図１では、様々なレファレンスポイント（例えば、Ｓ１−Ｕ、Ｓ１−ＭＭＥなど）を示す。３ＧＰＰシステムではＥ−ＵＴＲＡＮ及びＥＰＣの異なる機能個体（ｆｕｎｃｔｉｏｎａｌ ｅｎｔｉｔｙ）に存在する２個の機能を接続させる概念的なリンクをレファレンスポイント（ｒｅｆｅｒｅｎｃｅ ｐｏｉｎｔ）と定義する。次の表１は、図１に示すレファレンスポイントをまとめたものである。表１の例示の他にもネットワーク構造によって様々なレファレンスポイントが存在してもよい。

図１に示すレファレンスポイントのうち、Ｓ２ａ及びＳ２ｂは、非−３ＧＰＰインターフェースに該当する。Ｓ２ａは、信頼できる非−３ＧＰＰアクセス及びＰＤＮＧＷ間の関連制御及び移動性支援をユーザプレーンに提供するレファレンスポイントである。Ｓ２ｂは、ｅＰＤＧ及びＰＤＮ ＧＷ間の関連制御及び移動性支援をユーザプレーンに提供するレファレンスポイントである。

近接サービス（ＰｒｏＳｅ）を提供するための制御メカニズム

本発明では、３ＧＰＰ ＥＰＳ（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｓｙｓｔｅｍ）のような移動通信システムにおいて近接サービス（ＰｒｏＳｅ）又はＤ２Ｄサービスを支援するための制御メカニズムを提案する。

近年、ＳＮＳ（Ｓｏｃｉａｌ Ｎｅｔｗｏｒｋ Ｓｅｒｖｉｃｅ）に対するユーザの要求事項の増加により、物理的に近い距離のユーザ／装置間の検出（ｄｅｔｅｃｔ）／探索（ｄｉｓｃｏｖｅｒｙ）及び特別なアプリケーション／サービス（すなわち、近接性−ベースアプリケーション／サービス）に対する要求が台頭している。３ＧＰＰ移動通信システムでもこのような種類のサービスを提供するために、ＰｒｏＳｅに対する可能な用例（ｕｓｅ ｃａｓｅ）及びシナリオと、可能なサービス要件（ｓｅｒｖｉｃｅ ｒｅｑｕｉｒｅｍｅｎｔ）に対する議論を行っている。

ＰｒｏＳｅの可能な用例としては、商業的／ソーシャルサービス、ネットワークオフロード、公共安全（Ｐｕｂｌｉｃ Ｓａｆｅｔｙ）、既存インフラストラクチャー（ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）サービスの統合（これは、到達性（ｒｅａｃｈａｂｉｌｉｔｙ）及び移動性（ｍｏｂｉｌｉｔｙ）の側面を含むユーザ経験の一貫性を保障するためである。）などを挙げることができる。また、Ｅ−ＵＴＲＡＮカバレッジが提供されない場合における公共安全（この場合、特定地域の規制及び事業者政策に符合することを条件とし、公共−安全のために指定された特定周波数帯域及び特定端末に制限されることを考慮しなければならない。）に対する用例及び可能な要件を議論中である。

特に、３ＧＰＰで進行しているＰｒｏＳｅに関する議論の範囲は、近接性−ベースアプリケーション／サービスはＬＴＥ又はＷＬＡＮを経由して提供され、事業者／ネットワークの制御を受けて装置間の探索及び通信が行われることを仮定する。

図２は、ＥＰＳにおいて２つのＵＥが通信する基本的なデータ経路（ｄｅｆａｕｌｔ ｄａｔａ ｐａｔｈ）を示す図である。すなわち、図２には、ＵＥ−１とＵＥ−２との間のＰｒｏＳｅが適用されない一般的な場合のＵＥ−１とＵＥ−２間のデータ経路を例示する。このような基本的な経路は、基地局（すなわち、ｅＮｏｄｅＢ又はＨｏｍｅ ｅＮｏｄｅＢ）及びゲートウェイノード（すなわち、ＥＰＣ又は事業者網）を経由する。例えば、図２に示すように、ＵＥ−１とＵＥ−２がデータをやり取りする時に、ＵＥ−１からのデータは、ｅＮｏｄｅＢ−１、Ｓ−ＧＷ／Ｐ−ＧＷ、ｅＮｏｄｅＢ−２を経てＵＥ−２に伝達し、同様に、ＵＥ−２からのデータは、ｅＮｏｄｅＢ−２、Ｓ−ＧＷ／Ｐ−ＧＷ、ｅＮｏｄｅＢ−１を経てＵＥ−１に伝達することができる。図２では、ＵＥ−１とＵＥ−２がそれぞれ異なるｅＮｏｄｅＢにキャンプ−オン（ｃａｍｐ−ｏｎ）していると図示しているが、同一のｅＮｏｄｅＢにキャンプ−オンしてもよい。また、図２では、２つのＵＥが同一のＳ−ＧＷ及びＰ−ＧＷからサービスを受けていると示しているが、様々な組合せのサービスも可能である。すなわち、同一のＳ−ＧＷ及び異なるＰ−ＧＷからサービスを受けてもよく、異なるＳ−ＧＷ及び同一のＰ−ＧＷからサービスを受けてもよく、異なるＧＷ及び異なるＰ−ＧＷからサービスを受けてもよい。

本発明では、このような基本的なデータ経路を、インフラストラクチャーデータ経路（すなわち、ｉｎｆｒａｓｔｒｕｃｔｕｒｅ ｐａｔｈ又はｉｎｆｒａｓｔｒｕｃｔｕｒｅ ｄａｔａ ｐａｔｈ又はｉｎｆｒａｓｔｒｕｃｔｕｒｅ ｃｏｍｍｕｎｉｃａｔｉｏｎ ｐａｔｈ）と呼ぶことができる。また、このようなインフラストラクチャーデータ経路を通じた通信をインフラストラクチャー通信と呼ぶことができる。

図３は、ＰｒｏＳｅに基づく２つのＵＥ間の直接モードデータ経路（ｄｉｒｅｃｔ ｍｏｄｅ ｄａｔａ ｐａｔｈ）を示す図である。このような直接モード通信経路は、基地局（すなわち、ｅＮｏｄｅＢ又はＨｏｍｅ ｅＮｏｄｅＢ）及びゲートウェイノード（すなわち、ＥＰＣ）を経由しない。

図３（ａ）には、ＵＥ−１とＵＥ−２がそれぞれ異なるｅＮｏｄｅＢ（すなわち、ｅＮｏｄｅＢ−１及びｅＮｏｄｅＢ−２）にキャンプ−オン（ｃａｍｐ−ｏｎ）しているとともに、直接モード通信経路を用いてデータをやり取りする場合を例示する。図３（ｂ）には、同じｅＮｏｄｅＢ（すなわち、ｅＮｏｄｅＢ−１）にキャンプ−オンしているＵＥ−１とＵＥ−２が直接モード通信経路を用いてデータをやり取りする場合を例示する。

一方、ユーザプレーンのデータ経路は、図３に示すように、基地局やゲートウェイノードを経由せずにＵＥ間に直接的に形成されるが、コントロールプレーン経路は、基地局及びコアネットワークを経て形成されてもよいという点に留意されたい。コントロールプレーン経路を通じて交換される制御情報は、セッション管理、認証（ａｕｔｈｅｎｔｉｃａｔｉｏｎ）、権限検証（ａｕｔｈｏｒｉｚａｔｉｏｎ）、保安、課金などに関する情報であってもよい。図３（ａ）の例示のように、異なるｅＮｏｄｅＢによってサービングされるＵＥ間のＰｒｏＳｅ通信の場合に、ＵＥ−１に関する制御情報は、ｅＮｏｄｅＢ−１を経てコアネットワークの制御ノード（例えば、ＭＭＥ）と交換し、ＵＥ−２に関する制御情報は、ｅＮｏｄｅＢ−２を経てコアネットワークの制御ノード（例えば、ＭＭＥ）と交換することができる。図３（ｂ）の例示のように、同じｅＮｏｄｅＢによってサービングされるＵＥ間のＰｒｏＳｅ通信の場合に、ＵＥ−１及びＵＥ−２に関する制御情報は、ｅＮｏｄｅＢ−１を経てコアネットワークの制御ノード（例えば、ＭＭＥ）と交換することができる。

図４は、ＰｒｏＳｅに基づく２つのＵＥ間のローカルルーティング方式データ経路（ｌｏｃａｌｌｙ−ｒｏｕｔｅｄ ｄａｔａ ｐａｔｈ）を示す図である。図４の例示のように、ＵＥ−１とＵＥ−２との間のＰｒｏＳｅ通信データ経路はｅＮｏｄｅＢ−１を経て形成されるが、事業者が運営するゲートウェイノード（すなわち、ＥＰＣ）は経由しない。一方、コントロールプレーン経路は、図４のように同一のｅＮｏｄｅＢによってサービングされるＵＥのローカルルーティング方式データ経路が構成される場合、ＵＥ−１及びＵＥ−２に関する制御情報は、ｅＮｏｄｅＢ−１を経てコアネットワークの制御ノード（例えば、ＭＭＥ）と交換することができる。

本発明では、図３及び図４で説明した通信経路を、直接データ経路、ＰｒｏＳｅのためのデータ経路、ＰｒｏＳｅベースデータ経路、又はＰｒｏＳｅ通信経路と呼ぶことができる。また、このような直接データ経路を用いた通信を、直接通信、ＰｒｏＳｅ通信、又はＰｒｏＳｅベース通信と呼ぶことができる。

近接サービス（ＰｒｏＳｅ）のために、Ｅ−ＵＴＲＡを用いて、近接している位置にある他のＵＥを探す過程が必要でありうるが、これをＰｒｏＳｅ探索（ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ）と呼ぶ。ＬＴＥ関連標準文書である３ＧＰＰ ＴＳ ２２．２７８で定義された、近接サービス（ＰｒｏＳｅ）のためのサービス要件（ｓｅｒｖｉｃｅ ｒｅｑｕｉｒｅｍｅｎｔ）を参照すると、ＰｒｏＳｅ探索は、ＵＥの間において直接無線信号（ｄｉｒｅｃｔ ｒａｄｉｏ ｓｉｇｎａｌ）を用いて行われてもよく、移動通信事業者ネットワーク（ｏｐｅｒａｔｏｒ ｎｅｔｗｏｒｋ）を介して行われてもよい。

ここで、移動通信事業者ネットワークを用いたＰｒｏＳｅ探索と関連して３ＧＰＰ ＴＲ ２３．７０３では、上述したとおり、ＥＰＣ−レベルＰｒｏＳｅ探索（ＥＰＣ−ｌｅｖｅｌ ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ）を定義している。しかし、３ＧＰＰ ＴＲ ２３．７０３では、ＥＰＣ−レベルＰｒｏＳｅ探索は、複数の近接サービス−可能端末の近接性（ｐｒｏｘｉｍｉｔｙ）を決定し、これら複数の端末に近接サービスを知らせる過程であると開示されているだけであり、それに関する具体的な方案については定義されていないという問題点があった。

すなわち、ＥＰＣ−レベルＰｒｏＳｅ探索の場合、ネットワークで探索（ｄｉｓｃｏｖｅｒ）しようとするＵＥに対する最新の正確な位置情報を取得する必要がある。ところが、ＧＥＲＡＮ／ＵＴＲＡＮにもキャンプ−オン（ｃａｍｐ−ｏｎ）できるＥ−ＵＴＲＡＮ端末がＩＳＲ（Ｉｄｌｅ ｍｏｄｅ Ｓｉｇｎａｌｉｎｇ Ｒｅｄｕｃｔｉｏｎ）適用を受ける場合（すなわち、ＩＳＲ ａｃｔｉｖａｔｅｄ状態である場合）、ネットワークにとってはＵＥの正確な位置（すなわち、Ｅ−ＵＴＲＡＮにあるかそれともＵＴＲＡＮ／ＧＥＲＡＮにあるか）がわからない。

ところが、近接ベースサービス（Ｐｒｏｘｉｍｉｔｙ ｂａｓｅｄ Ｓｅｒｖｉｃｅｓ）を提供するための作業範囲（ｓｃｏｐｅ）は、ＬＴＥ（すなわち、Ｅ−ＵＴＲＡＮ）、ＷＬＡＮ、公共安全用スペクトルであるどころ、ＵＴＲＡＮ及びＧＥＲＡＮ、そしてＵＭＴＳ及びＧＳＭの場合、ＰｒｏＳｅを提供するためのメカニズムを構成する時に影響（ｉｍｐａｃｔ）を与えてはならない。このため、ＥＰＣ−レベルＰｒｏＳｅ探索の場合、ＵＴＲＡＮ／ＧＥＲＡＮ及びＵＭＴＳ／ＧＳＭに影響を与えることなくＵＥに対する最新の正確な位置情報を取得する必要がある。

しかし、従来にはこのような方案が提案されておらず、上記の問題点を解決するために、本発明ではＩＳＲの適用を受ける（又は、ＩＳＲがａｃｔｉｖａｔｅｄである又はＩＳＲが適用され得る）ＵＥに対する位置情報を取得するＥＰＣ−レベルＰｒｏＳｅ探索方案を提案する。

また、ＥＰＣ−レベルＰｒｏＳｅ探索の場合、ネットワークで２つのＵＥが近接関係（ｐｒｏｘｉｍｉｔｙ）にあるか否かを決定する。共有ＲＡＮ（Ｓｈａｒｅｄ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ、Ｓｈａｒｅｄ ＲＡＮ）である場合、２つのＵＥが近接関係にあるにもかかわらず、キャンプ−オンしたセルのＥＣＧＩが異なることから、ネットワークでは２つのＵＥが近接関係にないと判断することができる。例えば、ＰＬＭＮ１とＰＬＭＮ２がｅＮｏｄｅＢを共有するが、該ｅＮｏｄｅＢのセルの一つであるｃｅｌｌ＃１に２つのＵＥ（ＵＥ１とＵＥ２）が位置しており、互いに近接関係にあると仮定する。このとき、ＵＥ１はＰＬＭＮ１のｃｅｌｌ＃１に、ＵＥ２はＰＬＭＮ２のｃｅｌｌ＃１にキャンプ−オンしたとすれば、キャンプ−オンしたセルが物理的には同一であるが、ＰＬＭＮが異なることからＥＣＧＩが異なる。このため、ネットワークがＥＣＧＩ情報のみに基づいて２つのＵＥが近接しているか否かを決定すると、上記の場合、ＵＥ１とＵＥ２とが近接関係にあると決定／判断することが不可能であるか難しい。本発明では、このような問題点を解決するために、ネットワーク共有（ｎｅｔｗｏｒｋ ｓｈａｒｉｎｇ）の場合、ＵＥ同士が近接関係にあるか否かを決定するＥＰＣ−レベルＰｒｏＳｅ探索方案を提案する。

さらに、ＥＰＣ−レベルＰｒｏＳｅ探索では、ＵＥ−Ａ（例、探索者（ｄｉｓｃｏｖｅｒｅｒ））がネットワークに、一定時間（有効期間、ｔｉｍｅ ｗｉｎｄｏｗ）の間にＵＥ−Ｂ（例、被探索者（ｄｉｓｃｏｖｅｒｅｅ））と近接関係にあるとそれを知らせるように要請することができる。当該要請を受けたネットワークは、前記有効期間にＵＥ−ＡとＵＥ−Ｂが近接関係にあるかをチェックするためにＵＥ間の位置を持続して把握／チェックしなければならない。ところが、仮にそもそもＵＥ−ＢがＵＥ−Ａと遠く離れており、前記有効期間内にＵＥ−ＡとＵＥ−Ｂとが近接関係にある可能性がないと、ネットワークが持続的に両ＵＥの位置を把握／チェックすることは無意味でありうる。すなわち、不要な位置報告（ｌｏｃａｔｉｏｎ ｒｅｐｏｒｔｉｎｇ）によるシグナリングの浪費が発生しうる。このような不要な位置報告は、さらには、位置報告の実行のためにＵＥが遊休モード（ｉｄｌｅ ｍｏｄｅ）から接続モード（ｃｏｎｎｅｃｔｅｄ ｍｏｄｅ）に切り替えるようにし、ＵＥのバッテリー（電力）を消耗させる問題が発生しうる。そこで、本発明では、上記の問題点を解決するためのＥＰＣ−レベルＰｒｏＳｅ探索方案を提案する。

１． ３ＧＰＰ ＥＰＳ（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｓｙｓｔｅｍ）のような移動通信システム上のＰｒｏＳｅ探索方法

以下、本発明で提案する３ＧＰＰ ＥＰＳ（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｓｙｓｔｅｍ）のような移動通信システムで近接ベースのサービスを効率的に提供するためのＰｒｏＳｅ探索方法を説明する。

１−１． ＰｒｏＳｅ探索方法−第１方案

第１方案の動作１）として、ＨＳＳがＰｒｏＳｅ探索／ＰｒｏＳｅ通信／ＰｒｏＳｅと関連してＵＥに対する位置情報が必要であるか否かを判断する。これは、ＨＳＳが他のネットワークノード（例、Ｐｒｏｘｉｍｉｔｙ Ｓｅｒｖｉｃｅ／Ｐｒｏｘｉｍｉｔｙ ＤｉｓｃｏｖｅｒｙのためのＳｅｒｖｅｒ、既存のネットワークノードなど）から上記の情報を要請するメッセージを受信することによって判断してもよく、ＨＳＳが独自で上記の情報を取得すべきだと判断してもよいなど、様々な基準によって行うことができる。

ここで、ＵＥに対する位置情報をＨＳＳに要請する他のネットワークノードは、上記位置情報要請がＰｒｏＳｅ探索／ＰｒｏＳｅ通信／ＰｒｏＳｅに関連したものであることを示す情報を明示的に又は暗示的に含めることもできる。また、上記位置情報を直ちに提供することを指示したり、又は遅延されない形態で提供することを指示する情報を含めることもできる。

第１方案の動作２）として、ＨＳＳが上記ＵＥに対し登録されているサービングノード（ｓｅｒｖｉｎｇ ｎｏｄｅ）を確認することができる。このとき、ＨＳＳは、サービングノードの確認結果によって、以下に説明する動作２−１）乃至２−３）を行うことができる。

動作２−１）によれば、ＨＳＳは、ＭＭＥとＳＧＳＮが全てサービングノードとして登録されている場合、ＭＭＥにのみ、上記ＵＥに対する位置情報を要請するメッセージを送信する。この要請メッセージを送信するとき、ＨＳＳは、次の一つ以上の情報を含めることができる。
ｉ）要請メッセージが位置情報を要請するためのものである旨を示す情報
ｉｉ）要請する位置情報の種類：例えば、ＥＣＧＩ（Ｅ−ＵＴＲＡＮ Ｃｅｌｌ Ｇｌｏｂａｌ Ｉｄｅｎｔｉｆｉｅｒ）、座標情報、地理学的位置（ｇｅｏｇｒａｐｈｉｃ ｌｏｃａｔｉｏｎ）、ＵＥの移動関連情報（例、速度（ｖｅｌｏｃｉｔｙ））など
ｉｉｉ）位置情報要請が、ａ）ＰｒｏＳｅ探索及び／或いはＰｒｏＳｅ通信及び／或いは近接サービス関連の位置情報要請、及び／或いはｂ）ＰｒｏＳｅ探索及び／或いはＰｒｏＳｅ通信及び／或いは近接サービスを開始するためのものである旨を示す情報
ｉｖ）ＵＥの最新位置情報（又は、現在位置（ｃｕｒｒｅｎｔ ｌｏｃａｔｉｏｎ）情報）を要請するためのものである旨を示す情報
ｖ）ＵＥが遊休（ｉｄｌｅ）状態（又は、遊休モード）である場合、ＭＭＥがページング（ｐａｇｉｎｇ）を行って位置情報を取得するようにする指示情報、又はページングを行うようにする指示情報
ｖｉ）ＵＥが接続（ｃｏｎｎｅｃｔｅｄ）状態（又は、接続モード）である場合、ＵＥをサービス（ｓｅｒｖｅ）している（すなわち、ＵＥが接続されている）ｅＮｏｄｅＢからＭＭＥがＵＥの位置情報を取得するようにする指示情報

さらに、要請メッセージに含まれる情報は、上記の情報の他にも、ＰｒｏＳｅ探索と関連して必要な情報（例、ＵＥの状態（ｓｔａｔｅ）情報など）又は他のネットワークノードが要求した情報を要請するための様々な情報を含むことができる。さらに、上記の情報は、明示的に又は暗示的に又は複数個が組み合わされたり含蓄されたりして含まれてもよい。例えば、上記ｉｉｉ）の情報のみを用いて、上記要請メッセージを受信したＭＭＥにとって上記ｖ）及び／又はｖｉ）情報を受信した効果を有するようにしてもよく、上記ｉｖ）の情報のみを用いて、上記要請メッセージを受信したＭＭＥにとって上記ｖ）及び／又はｖｉ）情報を受信した効果を有するようにしてもよい。

上記要請メッセージとしては、従来のメッセージ（例、Ｉｎｓｅｒｔ Ｓｕｂｓｃｒｉｂｅｒ Ｄａｔａ Ｒｅｑｕｅｓｔメッセージなど）が使われてもよく、本発明によって新しく定義されたメッセージが使われてもよい。従来のメッセージを使用する場合、これを拡張された形態（例えば、新しい情報要素（ｉｎｆｏｒｍａｔｉｏｎ ｅｌｅｍｅｎｔ；ＩＥ）を定義及び／又は既存の情報要素（ＩＥ）を利用しながら新しい値を定義するなど）で使用することもできる。なお、上述した情報はメッセージに含まれてもよく、メッセージ自体が上記の情報を内包する形態であってもよい。また、上記で説明した、使用しようとするメッセージの選択／拡張／定義に関する思想は、本発明の全般にわたって適用されてもよい。

また、上記の情報を含んだり含まない基準として、ＨＳＳは上記ＵＥに対して登録されているサービングノードの種類（すなわち、ＭＭＥとＳＧＳＮの両方か、ＭＭＥのみか）の他、次のような様々な情報をさらに考慮することもできる。ただし、以下に説明する情報は一例示に過ぎず、これに限定して本発明を解釈してはならない。
− 上記ＵＥに対する位置情報を必要とする理由が、ＰｒｏＳｅ探索のみのためであるか、或いはＰｒｏＳｅ通信のためであるか（すなわち、ＰｒｏＳｅ探索後にＰｒｏＳｅ通信を行う形態、又はＰｒｏＳｅ探索動作無しでＰｒｏＳｅ通信を行う形態であるか）
− ローカル政策（ｌｏｃａｌ ｐｏｌｉｃｙ）
− ＵＥに対する加入者情報
− ＵＥのローミング（ｒｏａｍｉｎｇ）有無

また、ＨＳＳは、上記ＵＥに対して登録されているサービングノードの種類及び上記の追加的な情報とは無関係に、上記ｉ）乃至ｖｉ）情報のうち一つ以上の情報を含めることもできる。又は、ＨＳＳは上記ＵＥに対して登録されているサービングノードの種類及び上記の追加的な情報とは無関係に、上記ＵＥに対する位置情報を取得すべき理由がＰｒｏＳｅ探索／ＰｒｏＳｅ通信／ＰｒｏＳｅのためであると、上記ｉ）乃至ｖｉ）情報のうち一つ以上の情報を含めることもできる。

動作２−２）によれば、ＨＳＳは、ＭＭＥとＳＧＳＮのうちＭＭＥのみがサービングノードとして登録されている場合、ＭＭＥに、上記ＵＥに対する位置情報を要請するメッセージを送信することができる。ここで、動作２−２）による要請メッセージには、動作２−１）と関連して上述した要請メッセージ関連内容を同一に適用することができ、上述した内容でその説明に代える。

動作２−３）によれば、ＨＳＳは、ＭＭＥとＳＧＳＮのうちＳＧＳＮのみがサービングノードとして登録されている場合、ＳＧＳＮに上記ＵＥに対する位置情報を要請するメッセージを送信しない。

第１方案の動作３）として、ＨＳＳからＵＥに対する位置情報を要請するメッセージを受信したＭＭＥは、上記要請メッセージ及び／又は要請メッセージに含まれた情報及び／又は設定（ｃｏｎｆｉｇｕｒａｔｉｏｎ）及び／又はローカル政策（ｌｏｃａｌ ｐｏｌｉｃｙ）に基づいて、以下に説明する動作３−１）乃至３−４）の一つを行うことができる。

動作３−１）によれば、ＭＭＥは、上記ＵＥが遊休状態であるか接続状態であるかを確認し、ＵＥが遊休（ｉｄｌｅ）状態である場合、ＵＥをページングする。これで、ＵＥに対する位置情報を取得する。仮に、ＵＥが接続（ｃｏｎｎｅｃｔｅｄ）状態であると、ＵＥの接続しているｅＮｏｄｅＢからＵＥに対する位置情報を取得する。

動作３−２）によれば、ＭＭＥは、上記ＵＥが遊休状態であるか接続状態であるかを確認する。仮に、ＵＥが遊休状態であると、ＵＥをページングし、これで、ＵＥに対する位置情報を取得する。仮に、ＵＥが接続状態であると、最近にｅＮｏｄｅＢから取得したＵＥに対する位置情報を使用するように決定する。

動作３−３）によれば、ＭＭＥは、上記ＵＥが遊休状態であるか接続状態であるか確認し、ＵＥが遊休状態である場合、最近にｅＮｏｄｅＢから取得したＵＥに対する位置情報を使用するように決定する。仮に、ＵＥが接続状態であると、ＵＥの接続しているｅＮｏｄｅＢからＵＥに対する位置情報を取得する。

動作３−４）によれば、ＭＭＥは、最近にｅＮｏｄｅＢから取得したＵＥに対する位置情報を使用するように決定する。

なお、上記の動作３）と関連してＵＥが接続状態である場合、ＵＥの接続しているｅＮｏｄｅＢからＵＥに対する位置情報を取得するために、ＭＭＥは、従来のＳ１−ＡＰメッセージ（例えば、Ｌｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｃｏｎｔｒｏｌメッセージなど）を使用することもでき、新しく定義されたメッセージを使用することもできる。従来のメッセージを使用する場合、これを拡張された形態（例えば、新しい情報要素（ＩＥ）を定義及び／又は既存の情報要素（ＩＥ）を利用しながら新しい値を定義するなど）で使用することもできる。

第１方案の動作４）として、ＭＭＥは、上記ＵＥに対する位置情報を含めた応答メッセージをＨＳＳに送信する。ここで、上記応答メッセージは、従来のメッセージ（例えば、Ｉｎｓｅｒｔ Ｓｕｂｓｃｒｉｂｅｒ Ｄａｔａ Ａｎｓｗｅｒメッセージなど）が使われてもよく、新しく定義されたメッセージが使われてもよい。従来のメッセージを使用する場合、これを拡張された形態（例えば、新しい情報要素（ＩＥ）を定義及び／又は既存の情報要素（ＩＥ）を利用しながら新しい値を定義するなど）で使用することもできる。なお、上記応答メッセージは、位置情報をはじめとして、ＨＳＳが要請した様々な情報及び／又はＭＭＥが提供できる情報を含むこともできる。

第１方案の動作５）として、ＭＭＥが送信した上記位置情報を含む応答メッセージを受信したＨＳＳは、次の動作を行うことができる。
他のネットワークノードに上記ＵＥに対する位置情報を提供しなければならない場合に、
− ＭＭＥが上記ＵＥに対して登録されていてＭＭＥから位置情報を取得すると、ＭＭＥが提供した位置情報及び様々な情報をそのまま又は加工した形態で他のネットワークノードに提供する。
− 仮に、上述した第１方案の動作２）においてＨＳＳが上記ＵＥに対して登録されているサービングノードを確認した結果、ＳＧＳＮのみが登録されていたとすれば（すなわち、動作２−３）の場合）、ＨＳＳは他のネットワークノードに位置情報を取得でき旨を知らせるメッセージを送信する。ここで、上記メッセージは、様々な情報（例、上記ＵＥが接続可能（ｒｅａｃｈａｂｌｅ）でない及び／又は上記ＵＥがｎｏｔ＿ｆｏｕｎｄである及び／又は上記ＵＥがＥ−ＵＴＲＡＮによってサービス提供（ｓｅｒｖｅ）されない及び／又は上記ＵＥが分離された（ｄｅｔａｃｈ）状態である旨）を明示的に又は暗示的に指示することができる。

１−２． ＰｒｏＳｅ探索方法−第２方案

第２方案の動作１）として、ＨＳＳが、ＰｒｏＳｅ探索／ＰｒｏＳｅ通信／ＰｒｏＳｅと関連してＵＥに対する位置情報が必要か否かを判断する。これは、ＭＭＥが他のネットワークノード（例えば、ＨＳＳ、Ｐｒｏｘｉｍｉｔｙ Ｓｅｒｖｉｃｅ／Ｐｒｏｘｉｍｉｔｙ探索のためのサーバー、既存のネットワークノードなど）又は他のＵＥから上記の情報を要請するメッセージを受信することによって判断してもよく、ＭＭＥが独自で上記の情報を取得すべきであると判断してもよいなど、様々な基準に従うことができる。

ＵＥに対する位置情報をＭＭＥに要請する他のネットワークノード又は他のＵＥは、上記位置情報要請がａ）ＰｒｏＳｅ探索／ＰｒｏＳｅ通信／ＰｒｏＳｅ関連したものである、及び／又はｂ）ＰｒｏＳｅ探索／ＰｒｏＳｅ通信／ＰｒｏＳｅ関連した動作を開始するためのものである旨を示す情報を、明示的に又は暗示的に含めることができる。また、上記位置情報を直ちに提供することを指示したり、又は遅延されない形態で提供することを指示する情報を含めることもできる。

第２方案の動作２）として、ＭＭＥが上記ＵＥに対してＩＳＲ状態（すなわち、ＩＳＲ ａｃｔｉｖａｔｅｄであるか否か）を確認（ｃｈｅｃｋ）することができる。ＩＳＲ状態を確認した結果、ＩＳＲ ａｃｔｉｖａｔｅｄであれば、ＭＭＥは、以下に説明する動作２−１）又は２−２）を行い、ＩＳＲがａｃｔｉｖａｔｅｄでないと（又は、ＩＳＲ ｄｅａｃｔｉｖａｔｅｄ又はＭＭＥがＩＳＲ ｃａｐａｂｌｅでないと）、ＭＭＥは以下に説明する動作２−３）又は２−４）を行う。

動作２−１）によれば、ＩＳＲ ａｃｔｉｖａｔｅｄであれば、ＵＥが遊休状態である場合、ＵＥをページングし、これで、ＵＥに対する位置情報を取得する。仮に、ＵＥが接続状態であると、ＵＥの接続しているｅＮｏｄｅＢからＵＥに対する位置情報を取得する。

動作２−２）によれば、ＩＳＲ ａｃｔｉｖａｔｅｄであれば、ＵＥが遊休状態である場合、ＵＥをページングし、これで、ＵＥに対する位置情報を取得する。仮に、ＵＥが接続状態であると、最近にｅＮｏｄｅＢから取得したＵＥに対する位置情報を使用するように決定する。

動作２−３）によれば、ＩＳＲがａｃｔｉｖａｔｅｄでないと、最近にｅＮｏｄｅＢから取得したＵＥに対する位置情報を使用するように決定する。

動作２−４）によれば、ＩＳＲがａｃｔｉｖａｔｅｄでないと、ＵＥが遊休状態である場合、ＵＥをページングし、これで、ＵＥに対する位置情報を取得する。逆に、ＵＥが接続状態である場合、最近にｅＮｏｄｅＢから取得したＵＥに対する位置情報を使用するように決定する。

なお、第２方案と関連して、ＵＥが接続状態である場合、ＵＥの接続しているｅＮｏｄｅＢからＵＥに対する位置情報を取得するためにＭＭＥが使用するメッセージは、上述した第１方案のそれと同一であるので、その説明を省略する。

また、ＭＭＥは、上記ＵＥに対するＩＳＲ状態にかかわらず、上記ＵＥに対する位置情報を取得すべき理由がＰｒｏＳｅ通信のためであると（すなわち、ＰｒｏＳｅ探索後にＰｒｏＳｅ通信を行う形態又はＰｒｏＳｅ探索動作無しでＰｒｏＳｅ通信を行う形態）、上記ＵＥが遊休状態であると、ＵＥをページングする動作を行うこともできる。

動作３）によれば、ＭＭＥが他のネットワークノード又はＵＥに上記ＵＥに対する位置情報を提供しなければならない場合、上記ＵＥに対する位置情報及び様々な関連情報を、そのまま又は加工した形態で他のネットワークノード又はＵＥに提供する。

１−３． ＰｒｏＳｅ探索方法−第３方案

第３方案の動作１）として、ＨＳＳに他のネットワークノード（例えば、近接サービス／近接探索のためのサーバー、既存のネットワークノードなど）からＰｒｏＳｅ探索／ＰｒｏＳｅと関連してルーティング情報（又は、ＵＥのサービングノード情報）が要請されてもよい。

第３方案の動作２）によれば、ＨＳＳが、上記ＵＥに対して登録されているサービングノードを確認し、以下の動作２−１）乃至２−３）の一つを行うことができる。

動作２−１）によれば、ＭＭＥとＳＧＳＮが両方ともサービングノードとして登録されている場合、ＭＭＥに関する情報のみを含む応答メッセージを、上記要請メッセージを送ったノードに送信する。すなわち、ＳＧＳＮに関する情報は含まない。このとき、さらに、上記ＵＥに対してＭＭＥだけでなく他のサービングノードも存在することを知らせる情報、及び／又はＵＥがＥ−ＵＴＲＡＮにキャンプ−オン（ｃａｍｐ−ｏｎ）した状態でなくてもよいことを知らせる情報、及び／又はＵＥが接続可能（ｒｅａｃｈａｂｌｅ）でなくてもよいことを知らせる情報、及び／又はＵＥがｎｏｔ＿ｆｏｕｎｄでなくてもよいことを知らせる情報などを明示的に又は暗示的に含むこともできる。

動作２−２）によれば、ＭＭＥとＳＧＳＮのうちＭＭＥのみがサービングノードとして登録されている場合、ＭＭＥに関する情報を含む応答メッセージを、上記要請メッセージを送ったノードに送信することができる。

動作２−３）によれば、ＭＭＥとＳＧＳＮのうちＳＧＳＮのみがサービングノードとして登録されている場合、ルーティング情報が無いことを知らせる応答メッセージを、上記要請メッセージを送ったノードに送信することができる。ここで、上記応答メッセージは、様々な情報（例えば、上記ＵＥが接続可能（ｒｅａｃｈａｂｌｅ）でなくてもよい、及び／又は上記ＵＥがｎｏｔ＿ｆｏｕｎｄである、及び／又は上記ＵＥがＥ−ＵＴＲＡＮによってサービス（ｓｅｒｖｅ）されない、及び／又は上記ＵＥが分離された（ｄｅｔａｃｈ）状態であることなど）を明示的に又は暗示的に指示することができる。

動作３）によれば、ＨＳＳから応答を受信した他のネットワークノードは、応答メッセージに基づいて、ＵＥのサービングノードであるＭＭＥに位置情報を要請することができる。この時、上記他のネットワークノードは、ＨＳＳから受信した応答メッセージに基づいて、ＭＭＥに位置情報要請メッセージを送信することができ、このとき、位置情報を要請するメッセージには、上述した第１方案の動作２）に記述された様々な情報が含まれてもよい。

以上述べた方法１−１．乃至方法１−３．の場合、本発明は、一つのＵＥを探索するための動作だけでなく、複数のＵＥ（例、グループに属したＵＥ）を探索するための動作にも適用することができる。

なお、本発明は一回のみの位置情報提供動作だけでなく、周期的な位置情報提供動作にも拡張して適用することができる。

また、本発明で言及したＵＥの位置情報は、位置関連情報、又はＰｒｏＳｅ探索に必要な位置関連情報などのように様々に解釈されてもよい。上記ＵＥの位置情報は、例えば、ＴＡＩ、ＥＣＧＩ、ｅＮｏｄｅＢ情報（ｅＮｏｄｅＢ ＩＤ又はｇｌｏｂａｌ ｅＮｏｄｅＢ ＩＤなど）、座標情報、地理学的位置（ｇｅｏｇｒａｐｈｉｃ ｌｏｃａｔｉｏｎ）情報、ＵＥの移動関連情報（例、ｖｅｌｏｃｉｔｙ）などのうち一つ以上の様々な情報を含むことができる。また、ネットワークシェアリング（ｎｅｔｗｏｒｋ ｓｈａｒｉｎｇ（ＧＷＣＮ）：Ｇａｔｅｗａｙ Ｃｏｒｅ Ｎｅｔｗｏｒｋ又はＭＯＣＮ：Ｍｕｌｔｉ−Ｏｐｅｒａｔｏｒ Ｃｏｒｅ Ｎｅｔｗｏｒｋ）の場合（すなわち、ＵＥが共有ネットワーク（ｓｈａｒｅｄ ｎｅｔｗｏｒｋ）にキャンプ−オンしている場合）、上記のＵＥ位置情報は、ｅＮｏｄｅＢがブロードキャストするＰＬＭＮのリスト（すなわち、ｅＮｏｄｅＢがＳＩＢ（Ｓｙｓｔｅｍ Ｉｎｆｏｒｍａｔｉｏｎ Ｂｌｏｃｋ）に含めてブロードキャストするＰＬＭＮ ＩＤ）を含むことができる。上記ブロードキャストＰＬＭＮリスト（ブロードキャストＰＬＭＮリスト（ｂｒｏａｄｃａｓｔ ＰＬＭＮｓ ｌｉｓｔ））は、ＭＭＥがｅＮｏｄｅＢからあらかじめ取得しているものであってもよく、ＵＥに対する位置情報取得のためにｅＮｏｄｅＢと相互作用（ｉｎｔｅｒａｃｔｉｏｎ）時にｅＮｏｄｅＢが提供したものであってもよい。

ＭＭＥは、ＵＥの位置情報を要請したネットワークノードにＵＥの位置情報を送信する際、上記ブロードキャストＰＬＭＮリスト（ｂｒｏａｄｃａｓｔ ＰＬＭＮｓ ｌｉｓｔ）を併せて送信することができる。また、ネットワークシェアリング（ｎｅｔｗｏｒｋ ｓｈａｒｉｎｇ）の場合、上記のＵＥ位置情報は、ＵＥが共有ネットワーク（ｓｈａｒｅｄ ｎｅｔｗｏｒｋ）にキャンプ−オンしたことを示す情報（例、指示子）を含むこともできる。また、共有ネットワークに対するＰＬＭＮ情報がネットワークノード（例えば、ＭＭＥ、ＨＳＳ、ＰｒｏＳｅ Ｓｅｒｖｅｒなど）に保存されていて、これを活用することもでき、必要時に、他のネットワークノードに提供又は他のネットワークノードから取得することもできる。

２つのＵＥ間の近接性（ｐｒｏｘｉｍｉｔｙ）を最終的に判断するネットワークノード（例えば、ＰｒｏＳｅ Ｓｅｒｖｅｒ）又はＵＥが、取得した上記の２つりＵＥの位置情報だけでは両ＵＥ間の距離（ｄｉｓｔａｎｃｅ）／近接性（ｐｒｏｘｉｍｉｔｙ）測定が不可能であるか難しい場合、以下に開示する一つ以上の情報を用いて両ＵＥ間の近接性（ｐｒｏｘｉｍｉｔｙ）の有無を判断することができる。
− 隣接するセル（Ｎｅｉｇｈｂｏｒ ｃｅｌｌ）に関する情報又はセル（ｃｅｌｌ）間の位置連携性に関する情報又は隣接するセル関係テーブル（Ｎｅｉｇｈｂｏｕｒ ｃｅｌｌ ｒｅｌａｔｉｏｎ ｔａｂｌｅ）又は隣接関係テーブル（Ｎｅｉｇｈｂｏｕｒ ｒｅｌａｔｉｏｎ ｔａｂｌｅ）又は隣接するセルマッピングテーブル（Ｎｅｉｇｈｂｏｕｒ ｃｅｌｌ ｍａｐｐｉｎｇ ｔａｂｌｅ／ｌｉｓｔ）：例えば、ＵＥに対して取得した位置情報がＥＣＧＩであり、ＵＥ＃１がＥＣＧＩ＃１にキャンプ−オンしており、ＵＥ＃２がＥＣＧＩ＃２にキャンプ−オンしていると、隣接するセル（ｎｅｉｇｈｂｏｒ ｃｅｌｌ）に対するテーブルを用いてＥＣＧＩ＃１とＥＣＧＩ＃２とが互いに隣接するセルであるか確認することができる。これによって、両ＵＥが近接関係（ｐｒｏｘｉｍｉｔｙ）にあるか否かを判断できる。ここで、上記隣接するセル（ｃｅｌｌ）に関する情報は、すぐ隣のセル（ｃｅｌｌ）に関する情報だけでなく、近接関係を判断できるようにする範囲の隣の情報を含むことができる。
− セル（ｃｅｌｌ）の地理学的情報又はセル（ｃｅｌｌ）の座標情報：セル（ｃｅｌｌ）の中心座標情報及び／又はセル（ｃｅｌｌ）がカバーする東西南北の各端に対する座標情報及び／又はセル（ｃｅｌｌ）がカバーする範囲（例、セルの中心からの半径、セルがカバーする距離など）に関する情報を挙げることができる。例えば、ＵＥに対して取得した位置情報がＥＣＧＩであり、ＵＥ＃１がＥＣＧＩ＃１にキャンプ−オンしており、ＵＥ＃２がＥＣＧＩ＃２にキャンプ−オンしていると、ＥＣＧＩ＃１とＥＣＧＩ＃２の座標情報を用いて両セル間の最長距離を確認することができる。これによって、両ＵＥが近接関係にあるか否かを判断することができる。
− セル（ｃｅｌｌ）間の距離／距離情報
− 近接関係にあると判断できるセルの集合に対するリスト

なお、上記の情報（すなわち、近接性の判断のための情報）は、組み合わされた形態で及び／又は順次に適用されたり活用されてもよい。以上では説明の便宜のために上記の情報を羅列したが、上記情報に限定されず、２つのＵＥ間の近接性（ｐｒｏｘｉｍｉｔｙ）を最終的に判断するネットワークノード又はＵＥが、取得した位置情報を変換／切替／マッピングして変形された情報が適用されたり活用される場合も、本発明の技術的思想に含まれなければならない。また、上記の情報は、近接性を最終的に判断するネットワークノード又はＵＥに、設定（ｃｏｎｆｉｇｕｒｅ）されていたり、他のネットワークノードから取得する方案のうち少なくとも一つが適用されてもよい。また、上記の情報がアップデートされる度ごとにこれを取得してもよい。以上述べた方法は、様々な方式の互いに組み合わされた形態で用いられてもよい。

２．３ ＧＰＰ ＥＰＳ（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｓｙｓｔｅｍ）のような移動通信システム上のＰｒｏＳｅ探索方法に関する実施例

以下では、上述したＰｒｏＳｅ探索方案について具体的な実施例を挙げて詳細に説明する。

２−１． 第１実施例

図５は、本発明に係る第１実施例を示すものであり、具体的には、上述した第１方案に基づくＰｒｏＳｅ探索動作を示す参考図である。

図５の段階１で、ＰｒｏＳｅサーバーがＨＳＳに、ＰｒｏＳｅ探索の対象となるＵＥ（以下、ＵＥ−１）の位置情報を要請するための要請メッセージ、例えば、Ｌｏｃａｔｉｏｎ Ｉｎｆｏ Ｒｅｑｕｅｓｔメッセージを送信する。図５の段階１は、ＰｒｏＳｅサーバーが、ＵＥ−１との近接関係（ｐｒｏｘｉｍｉｔｙ）を知りたがっている他のＵＥ（以下、ＵＥ−２）からの要請、例えば、Ｐｒｏｘｉｍｉｔｙ Ｒｅｑｕｅｓｔを受信することによって開始することができる。又は、ＵＥ−１の位置情報、或いはＵＥ−１と他のＵＥとの近接関係（ｐｒｏｘｉｍｉｔｙ）を知りたがっている他のネットワークノード（例えば、ＰｒｏＳｅ Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｅｒなど）からの要請によって開始してもよい。

なお、上記要請をするＵＥ−２は、要請時に、自身の位置情報を含めてＰｒｏｘｉｍｉｔｙ ＲｅｑｕｅｓｔメッセージをＰｒｏＳｅサーバーに送信することもできる。仮にＵＥ−２が自身の位置情報を含めていないと、上記ＰｒｏＳｅサーバーは、本実施例でＵＥ−１の位置情報を取得する方法と同様にしてＵＥ−２の位置情報を取得することができる。また、これは、上記要請をする他のネットワークノードがＵＥ−１との近接関係（ｐｒｏｘｉｍｉｔｙ）を知りたがっている他のＵＥに対する位置情報を提供しない場合にも同一に適用される。

図５の段階２で、ＨＳＳが、上記ＵＥ−１に対して登録されているサービングノードを確認する。本実施例では、ＭＭＥとＳＧＳＮが両方ともサービングノードとして登録されていると仮定する。

図５の段階３で、ＨＳＳはＭＭＥに、ＵＥ−１に対する位置情報を要請するメッセージ、例えば、Ｉｎｓｅｒｔ Ｓｕｂｓｃｒｉｂｅｒ Ｄａｔａ Ｒｅｑｕｅｓｔメッセージを送信する。この時、ＨＳＳは、Ｉｎｓｅｒｔ Ｓｕｂｓｃｒｉｂｅｒ Ｄａｔａ Ｒｅｑｕｅｓｔメッセージを構成するＩＤＲ ｆｌａｇｓ（下記の表２参照）においてＥＰＳ Ｌｏｃａｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｑｕｅｓｔ値（ｂｉｔ）を設定し、Ｃｕｒｒｅｎｔ Ｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔ値（ｂｉｔ）を設定する。なお、上述した第１方案の動作２）で記述した様々な情報がさらに含まれるように定義されてもよい。

図５の段階４及び段階５で、ＨＳＳが送信した要請メッセージ（すなわち、Ｉｎｓｅｒｔ Ｓｕｂｓｃｒｉｂｅｒ Ｄａｔａ Ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅ）を受信したＭＭＥは、上記要請メッセージに基づいて、ＵＥ−１が遊休状態であるため、ＵＥ−１にページングを行う。本実施例ではＵＥ−１が遊休状態であると仮定し、ＭＭＥは上述した第１方案の動作３）のうち動作３−１）によって行われると仮定する。

図５の段階６で、ページングメッセージを受信したＵＥ−１は、サービス要請手順（Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ ｐｒｏｃｅｄｕｒｅ）を行う（以下、サービス要請手順に関する事項は、３ＧＰＰ ＴＳ ２３．４０１の５．３．４．１節の「ＵＥ ｔｒｉｇｇｅｒｅｄ Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ」参照）。ＭＭＥはＵＥ−１に対する位置情報を取得する。この位置情報は、ＵＥ−１がＭＭＥに送信したサービス要請メッセージをｅＮｏｄｅＢがＭＭＥにフォーワーディングするために送信するＳ１−ＡＰメッセージ（例、ＩＮＩＴＩＡＬ ＵＥ ＭＥＳＳＡＧＥ）にＵＥに対する位置情報（例えば、ＴＡＩ、ＥＣＧＩなど）を含めることによって取得することができる。

図５の段階７で、ＵＥ−１に対する位置情報を取得したＭＭＥは、ＨＳＳに、ＵＥ−１に対する位置情報を含むＩｎｓｅｒｔ Ｓｕｂｓｃｒｉｂｅｒ Ｄａｔａ Ａｎｓｗｅｒメッセージを送信する。

図５の段階８で、ＨＳＳはＰｒｏＳｅサーバーに、ＵＥ−１の位置情報を含む応答メッセージ、例えば、Ｌｏｃａｔｉｏｎ Ｉｎｆｏ Ａｎｓｗｅｒメッセージを送信する。この時、ＨＳＳからＵＥ−１に対する位置情報を取得したＰｒｏＳｅサーバーは近接関係（ｐｒｏｘｉｍｉｔｙ）を判断し、近接関係を知りたがっていたＵＥ（すなわち、段階１の場合、ＵＥ−２）に応答をすることもできる。また、ＵＥ−１とＵＥ−２とが近接関係にあると、選択的にはＵＥ−１にもそれを知らせることができる。

２−２． 第２実施例

図６は、本発明に係る第２実施例を示すものであり、具体的には、上述した第２方案に基づくＰｒｏＳｅ探索動作を示す参考図である。

図６の段階１で、ＰｒｏＳｅサーバーがＨＳＳに、ＰｒｏＳｅ探索の対象となるＵＥ（以下、ＵＥ−１）の位置情報を要請するための要請メッセージ、例えば、Ｌｏｃａｔｉｏｎ Ｉｎｆｏ Ｒｅｑｕｅｓｔメッセージを送信する。参考として、ＰｒｏＳｅサーバーとＭＭＥ間のインターフェースが存在する場合、ＰｒｏＳｅサーバーは、ＵＥ−１をサービスするＭＭＥに、位置情報を要請するメッセージを送信することもできる。この段階は、ＰｒｏＳｅサーバーがＵＥ−１との近接関係（ｐｒｏｘｉｍｉｔｙ）を知りたがっている他のＵＥ（以下、ＵＥ−２）からの要請、例えば、Ｐｒｏｘｉｍｉｔｙ Ｒｅｑｕｅｓｔを受信することによって開始することができる。又は、ＵＥ−１の位置情報、或いはＵＥ−１と他のＵＥとの近接関係（ｐｒｏｘｉｍｉｔｙ）を知りたがっている他のネットワークノード（例えば、ＰｒｏＳｅ Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｅｒなど）からの要請によって開始してもよい。

なお、上記要請をするＵＥ−２は、要請時に、自身の位置情報を含めてＰｒｏｘｉｍｉｔｙ ＲｅｑｕｅｓｔメッセージをＰｒｏＳｅサーバーに送ることもできる。仮にＵＥ−２が自身の位置情報を含めていないと、上記ＰｒｏＳｅサーバーは、この実施例でＵＥ−１の位置情報を取得する方法と同様にしてＵＥ−２の位置情報を取得することができる。これは、上記要請をする他のネットワークノードがＵＥ−１との近接関係（ｐｒｏｘｉｍｉｔｙ）を知りたがっている他のＵＥに対する位置情報を提供しない場合にも同一に適用することができる。

図６の段階２で、ＨＳＳは、ＵＥ−１をサービス（ｓｅｒｖｅ）するＭＭＥに、位置情報を要請するための要請メッセージ、例えば、Ｉｎｓｅｒｔ Ｓｕｂｓｃｒｉｂｅｒ Ｄａｔａ Ｒｅｑｕｅｓｔメッセージを送信する。この時、ＨＳＳは、Ｉｎｓｅｒｔ Ｓｕｂｓｃｒｉｂｅｒ Ｄａｔａ Ｒｅｑｕｅｓｔメッセージを構成するＩＤＲ ｆｌａｇｓにおいてＥＰＳ Ｌｏｃａｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｑｕｅｓｔ値（ｂｉｔ）を設定する。また、上記位置情報要請がＰｒｏＳｅ探索関連のものであることを示す情報をさらに含めることができる。

図６の段階３で、上記ＨＳＳが送信したＩｎｓｅｒｔ Ｓｕｂｓｃｒｉｂｅｒ Ｄａｔａ Ｒｅｑｕｅｓｔメッセージを受信したＭＭＥは、上記ＵＥに対してＩＳＲ状態（すなわち、ＩＳＲ ａｃｔｉｖａｔｅｄであるか否か）を確認する。以下、この実施例では、ＵＥ−１に対するＩＳＲがａｃｔｉｖａｔｅｄであると仮定する。

図６の段階４及び段階５で、ＭＭＥは、ＵＥ−１に対するＩＳＲがａｃｔｉｖａｔｅｄであり、ＵＥ−１が遊休状態であるため、ＵＥ−１にページングを行う。この実施例では、ＵＥ−１が遊休状態であると仮定し、ＭＭＥは上述した第２方案の動作２）のうち動作２−１）によって行うと仮定する。

図６の段階６で、ページングメッセージを受信したＵＥ−１は、Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ ｐｒｏｃｅｄｕｒｅを行う（以下、サービス要請手順に関する事項は、３ＧＰＰ ＴＳ ２３．４０１の５．３．４．１節の「ＵＥ ｔｒｉｇｇｅｒｅｄ Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ」参照）。ＭＭＥはＵＥ−１に対する位置情報を取得する。上記位置情報は、ＵＥ−１がＭＭＥに送信したＳｅｒｖｉｃｅ ＲｅｑｕｅｓｔメッセージをｅＮｏｄｅＢがＭＭＥにフォーワーディングするために送信するＳ１−ＡＰメッセージ（例えば、ＩＮＩＴＩＡＬ ＵＥ ＭＥＳＳＡＧＥ）にＵＥに対する位置情報（例えば、ＴＡＩ，ＥＣＧＩなど）を含めることによって取得することができる。

図６の段階７で、ＵＥ−１に対する位置情報を取得したＭＭＥは、ＨＳＳに、ＵＥ−１に対する位置情報を含むＩｎｓｅｒｔ Ｓｕｂｓｃｒｉｂｅｒ Ｄａｔａ Ａｎｓｗｅｒメッセージを送信する。参考として、図６の段階１でＰｒｏＳｅサーバーがＭＭＥにＵＥ−１の位置情報を要請するメッセージを送信した場合、ＭＭＥはＰｒｏＳｅサーバーに応答メッセージを送信することができる。

図６の段階８で、ＨＳＳはＰｒｏＳｅサーバーに、ＵＥ−１の位置情報を含む応答メッセージ、例えば、Ｌｏｃａｔｉｏｎ Ｉｎｆｏ Ａｎｓｗｅｒメッセージを送信する。ここで、ＨＳＳからＵＥ−１に対する位置情報を取得したＰｒｏＳｅサーバーは、近接関係を判断し、近接関係を知りたがっていたＵＥ（上記段階１の説明では、ＵＥ−２）に応答をすることができる。また、ＵＥ−１とＵＥ−２とが近接関係にあると、選択的にはＵＥ−１にもそれを知らせることができる。

２−３． 第３実施例

図７は本発明に係る第３実施例を示すものであり、具体的には、上述した第１方案に基づくＰｒｏＳｅ探索動作を示す参考図である。

図７の段階１で、ＰｒｏＳｅサーバーがＨＳＳに、ＰｒｏＳｅ探索の対象となるＵＥ（以下、ＵＥ−１）の位置情報を要請するための要請メッセージ、例えば、Ｌｏｃａｔｉｏｎ Ｉｎｆｏ Ｒｅｑｕｅｓｔメッセージを送信する。この段階１は、ＰｒｏＳｅサーバーがＵＥ−１との近接関係を知りたがっている他のＵＥ（以下、ＵＥ−２）からの要請、例えば、Ｐｒｏｘｉｍｉｔｙ Ｒｅｑｕｅｓｔを受信することによって開始することができる。又は、ＵＥ−１の位置情報又はＵＥ−１と他のＵＥとの近接関係を知りたがっている他のネットワークノード（例えば、ＰｒｏＳｅ Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｅｒなど）からの要請によって開始してもよい。上記要請をするＵＥ−２は、要請時に、自身の位置情報を含めてＰｒｏｘｉｍｉｔｙ ＲｅｑｕｅｓｔメッセージをＰｒｏＳｅサーバーに送ることもできる。仮にＵＥ−２が自身の位置情報を含めていないと、上記ＰｒｏＳｅサーバーは、この実施例でＵＥ−１の位置情報を取得する方法と同様にしてＵＥ−２の位置情報を取得することができる。これは、上記要請をする他のネットワークノードがＵＥ−１との近接関係を知りたがっている他のＵＥに対する位置情報を提供しない場合にも同一に適用される。

図７の段階２で、ＨＳＳが上記受信した要請メッセージに含まれた情報を確認する。ここで、上記要請メッセージは、ＰｒｏＳｅ通信と関連するものである旨を示したり、又はＰｒｏＳｅ通信を開始するためのものである旨（すなわち、ＰｒｏＳｅ探索後にＰｒｏＳｅ通信を行う形態又はＰｒｏＳｅ探索動作無しでＰｒｏＳｅ通信を行う形態）を示す情報が含まれていると仮定する。

図７の段階３で、ＨＳＳはＵＥのサービングノードであるＭＭＥに、ＵＥ−１に対する位置情報を要請するメッセージ、例えば、Ｌｏｃａｔｉｏｎ Ｉｎｆｏ Ｒｅｑｕｅｓｔメッセージを送信する。この時、ＨＳＳは、Ｌｏｃａｔｉｏｎ Ｉｎｆｏ Ｒｅｑｕｅｓｔメッセージに、位置情報要請がＰｒｏＳｅ通信を開始するためである旨を示す情報を含める。また、上述した第１方案の動作２）で記述した様々な情報がさらに含まれてもよい。

図７の段階４及び段階５で、上記ＨＳＳの送信したＬｏｃａｔｉｏｎ Ｉｎｆｏ Ｒｅｑｕｅｓｔメッセージを受信したＭＭＥは、上記要請メッセージに基づいてＵＥ−１が遊休状態であるため、ＵＥ−１にページングを行う。この実施例では、ＵＥ−１が遊休状態であると仮定し、ＭＭＥは上述した第１方案の動作３）のうち動作３−１）によって動作すると仮定する。

図７の段階６で、Ｐａｇｉｎｇメッセージを受信したＵＥ−１は、サービス要請手順（Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ ｐｒｏｃｅｄｕｒｅ）を行う（以下、サービス要請手順に関する事項は、３ＧＰＰ ＴＳ ２３．４０１の５．３．４．１節の「ＵＥ ｔｒｉｇｇｅｒｅｄ Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ」参照）。ＭＭＥは、ＵＥ−１に対する位置情報を取得する。この位置情報は、ＵＥ−１がＭＭＥに送信したサービス要請メッセージをｅＮｏｄｅＢがＭＭＥにフォーワーディングするために送信するＳ１−ＡＰメッセージ（例えば、ＩＮＩＴＩＡＬ ＵＥ ＭＥＳＳＡＧＥ）にＵＥに対する位置情報（例えば、ＴＡＩ、ＥＣＧＩなど）を含めることによって取得することができる。

図７の段階７で、ＵＥ−１に対する位置情報を取得したＭＭＥは、ＨＳＳに、ＵＥ−１に対する位置情報を含むＬｏｃａｔｉｏｎ Ｉｎｆｏ Ａｎｓｗｅｒメッセージを送信する。

図７の段階８で、ＨＳＳはＰｒｏＳｅサーバーに、ＵＥ−１の位置情報を含む応答メッセージ、例えば、Ｌｏｃａｔｉｏｎ Ｉｎｆｏ Ａｎｓｗｅｒメッセージを送信する。なお、ＨＳＳからＵＥ−１に対する位置情報を取得したＰｒｏＳｅサーバーは、近接関係を判断し、近接関係を知りたがっていたＵＥ（すなわち、この実施例ではＵＥ−２）に応答をすることができる。この時、ＵＥ−２にＰｒｏＳｅ通信に必要な情報も併せて提供することができる。また、ＵＥ−１とＵＥ−２とが近接関係にあると、ＵＥ−１にも、ＵＥ−２がＰｒｏＳｅ通信をしようとする旨の情報を、ＰｒｏＳｅ通信に必要な情報と併せて知らせることができる。ＵＥ−１は既に接続（ｃｏｎｎｅｃｔｅｄ）状態であるから、ＰｒｏＳｅサーバーとＵＥ−１とが通信を行い得るように、ＭＭＥがＵＥ−１をページングする必要がない。

２−４． 第４実施例

図８は、本発明に係る第４実施例を示すものであり、具体的には、上述した第２方案に基づくＰｒｏＳｅ探索動作を示す参考図である。

図８の段階１で、ＰｒｏＳｅサーバーがＨＳＳに、ＰｒｏＳｅ探索の対象となるＵＥ（以下、ＵＥ−１）の位置情報を要請するための要請メッセージ、例えば、Ｌｏｃａｔｉｏｎ Ｉｎｆｏ Ｒｅｑｕｅｓｔメッセージを送信する。参考として、ＰｒｏＳｅサーバーとＭＭＥ間のインターフェースが存在する場合、ＰｒｏＳｅサーバーは、ＵＥ−１をサービスするＭＭＥに、位置情報を要請するメッセージを送信することができる。

この段階１は、ＰｒｏＳｅサーバーがＵＥ−１との近接関係を知りたがっている他のＵＥ（以下、ＵＥ−２）からの要請、例えば、Ｐｒｏｘｉｍｉｔｙ Ｒｅｑｕｅｓｔを受信することによって開始することができる。又は、ＵＥ−１の位置情報、或いはＵＥ−１と他のＵＥとの近接関係を知りたがっている他のネットワークノード（例えば、ＰｒｏＳｅ Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｅｒなど）からの要請によって開始してもよい。上記要請をするＵＥ−２は、要請時に、自身の位置情報を含めてＰｒｏｘｉｍｉｔｙ ＲｅｑｕｅｓｔメッセージをＰｒｏＳｅサーバーに送ることもできる。仮にＵＥ−２が自身の位置情報を含めていないと、上記ＰｒｏＳｅサーバーは、この実施例でＵＥ−１の位置情報を取得する方法と同様にしてＵＥ−２の位置情報を取得することができる。これは、上記要請をする他のネットワークノードがＵＥ−１との近接関係を知りたがっている他のＵＥに対する位置情報を提供しない場合にも同一に適用することができる。

なお、上記ＰｒｏＳｅサーバーが送信する要請メッセージは、ＰｒｏＳｅ通信と関連するものである旨を示したり、ＰｒｏＳｅ通信を開始するためのものである旨（すなわち、ＰｒｏＳｅ探索後にＰｒｏＳｅ通信を行う形態又はＰｒｏＳｅ探索動作無しでＰｒｏＳｅ通信を行う形態）を示す情報が含まれていると仮定する。

図８の段階２で、ＨＳＳは、上記ＰｒｏＳｅサーバーの送信した要請メッセージに基づいて、ＵＥ−１をサービス（ｓｅｒｖｅ）するＭＭＥに、位置情報を要請するための要請メッセージ、例えば、Ｌｏｃａｔｉｏｎ Ｉｎｆｏ Ｒｅｑｕｅｓｔメッセージを送信する。

図８の段階３で、上記ＨＳＳの送信したＬｏｃａｔｉｏｎ Ｉｎｆｏ Ｒｅｑｕｅｓｔメッセージを受信したＭＭＥは、受信した要請メッセージに含まれた情報を確認する。

図８の段階４及び段階５で、ＭＭＥは、上記要請メッセージがＰｒｏＳｅ通信を開始するためのものである旨を示す情報が含まれており、ＵＥ−１が遊休状態であるため、ＵＥ−１にページングを行う。

図８の段階６で、ページングメッセージを受信したＵＥ−１は、サービス要請手順（Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ ｐｒｏｃｅｄｕｒｅ）を行う（以下、サービス要請手順に関する事項は、３ＧＰＰ ＴＳ ２３．４０１の５．３．４．１節の「ＵＥ ｔｒｉｇｇｅｒｅｄ Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ」参照）。ＭＭＥはＵＥ−１に対する位置情報を取得する。この位置情報は、ＵＥ−１がＭＭＥに送信したＳｅｒｖｉｃｅ ＲｅｑｕｅｓｔメッセージをｅＮｏｄｅＢがＭＭＥにフォーワーディングするために送信するＳ１−ＡＰメッセージ（例えば、ＩＮＩＴＩＡＬ ＵＥ ＭＥＳＳＡＧＥ）にＵＥに対する位置情報（例えば、ＴＡＩ、ＥＣＧＩなど）を含めることによって取得することができる。

図８の段階７で、ＵＥ−１に対する位置情報を取得したＭＭＥは、ＨＳＳに、ＵＥ−１に対する位置情報を含むＬｏｃａｔｉｏｎ Ｉｎｆｏ Ａｎｓｗｅｒメッセージを送信する。また、図８の段階１でＰｒｏＳｅサーバーがＭＭＥにＵＥ−１の位置情報を要請するメッセージを送信した場合、ＭＭＥはＰｒｏＳｅサーバーに応答メッセージを送信することができる。

図８の段階８で、ＨＳＳはＰｒｏＳｅサーバーに、ＵＥ−１の位置情報を含む応答メッセージ、例えば、Ｌｏｃａｔｉｏｎ Ｉｎｆｏ Ａｎｓｗｅｒメッセージを送信する。

ここで、ＨＳＳからＵＥ−１に対する位置情報を取得したＰｒｏＳｅサーバーは、近接関係を判断し、近接関係を知りたがっていたＵＥ（この実施例ではＵＥ−２）に応答をすることができる。この時、ＵＥ−２に、ＰｒｏＳｅ通信に必要な情報も併せて提供することができる。また、ＵＥ−１とＵＥ−２とが近接関係にあると、ＵＥ−１にも、ＵＥ−２がＰｒｏＳｅ通信をしようとする旨の情報を、ＰｒｏＳｅ通信に必要な情報と併せて知らせることができる。なお、ＵＥ−１は既に接続（ｃｏｎｎｅｃｔｅｄ）状態であるから、ＰｒｏＳｅサーバーとＵＥ−１とが通信を行い得るように、ＭＭＥがＵＥ−１をページングする必要がない。

２−５． 第５実施例

図９は、本発明に係る第５実施例を示すものであり、具体的には、上述した第１方案に基づくＰｒｏＳｅ探索動作を示す参考図である。この実施例では、ＵＥ−１とＵＥ−２が共有ネットワーク（ｓｈａｒｅｄ ｎｅｔｗｏｒｋ、ＧＷＣＮ又はＭＯＣＮ）にキャンプ−オンした状態であると仮定する。

図９の段階１で、ＰｒｏＳｅ探索を行おうとするＵＥ（以下、ＵＥ−１）がＰｒｏＳｅ探索の対象となるＵＥ（以下、ＵＥ−２）との近接関係を知るためにＰｒｏＳｅサーバーにｐｒｏｘｉｍｉｔｙ情報要請メッセージ、例えば、Ｐｒｏｘｉｍｉｔｙ Ｒｅｑｕｅｓｔメッセージを送信する。上記要請をするＵＥ−１は、自身の位置情報を含めてＰｒｏｘｉｍｉｔｙ Ｒｅｑｕｅｓｔメッセージを送信することもできる。また、上記ＵＥ−１が共有ネットワーク（ｓｈａｒｅｄ ｎｅｔｗｏｒｋ）にキャンプ−オンしているため、キャンプ−オンしたｅＮｏｄｅＢがブロードキャストしたＰＬＭＮｓ ｌｉｓｔ情報を上記要請メッセージに含めることもできる。

図９の段階２で、ＰｒｏＳｅサーバーがＨＳＳに、ＵＥ−２の位置情報を要請するための要請メッセージ、例えば、Ｌｏｃａｔｉｏｎ Ｉｎｆｏ Ｒｅｑｕｅｓｔメッセージを送信する。

図９の段階３で、ＨＳＳが上記ＵＥ−２に対して登録されているサービングノードを確認する。この実施例では、ＭＭＥとＳＧＳＮが両方ともサービングノードとして登録されていると仮定する。

図９の段階４で、ＨＳＳはＭＭＥに、ＵＥ−２に対する位置情報を要請するメッセージ、例えば、Ｉｎｓｅｒｔ Ｓｕｂｓｃｒｉｂｅｒ Ｄａｔａ Ｒｅｑｕｅｓｔメッセージを送信する。この時、ＨＳＳは、Ｉｎｓｅｒｔ Ｓｕｂｓｃｒｉｂｅｒ Ｄａｔａ Ｒｅｑｕｅｓｔメッセージを構成するＩＤＲ ｆｌａｇｓ（上述の表２参照）においてＥＰＳ Ｌｏｃａｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｑｕｅｓｔ値（ｂｉｔ）を設定し、Ｃｕｒｒｅｎｔ Ｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔ値（ｂｉｔ）を設定する。なお、上述した第１方案の動作２）に記述された様々な情報がさらに含まれてもよい。

図９の段階５及び段階６で、上記ＨＳＳの送信したＩｎｓｅｒｔ Ｓｕｂｓｃｒｉｂｅｒ Ｄａｔａ Ｒｅｑｕｅｓｔメッセージを受信したＭＭＥは、上記要請メッセージに基づいて、ＵＥ−２が遊休状態であるため、ＵＥ−２にページングを行う。この実施例では、ＵＥ−２が遊休状態であると仮定し、ＭＭＥは上述した第１方案の動作３）のうち動作３−１）によって動作すると仮定する。

図９の段階７で、ページングメッセージを受信したＵＥ−２は、サービス要請手順（Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ ｐｒｏｃｅｄｕｒｅ）を行う（以下、サービス要請手順に関する事項は、３ＧＰＰ ＴＳ ２３．４０１の５．３．４．１節の「ＵＥ ｔｒｉｇｇｅｒｅｄ Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ」参照）。ＭＭＥはＵＥ−２に対する位置情報を取得する。

上記位置情報は、ＵＥ−２がＭＭＥに送信したＳｅｒｖｉｃｅ ＲｅｑｕｅｓｔメッセージをｅＮｏｄｅＢがＭＭＥにフォーワーディングするために送信するＳ１−ＡＰメッセージ（例えば、ＩＮＩＴＩＡＬ ＵＥ ＭＥＳＳＡＧＥ）にＵＥに対する位置情報（例えば、ＴＡＩ、ＥＣＧＩなど）を含めることによって取得することができる。ｅＮｏｄｅＢは共有ｅＮｏｄｅＢ（ｓｈａｒｅｄ ｅＮｏｄｅＢ）であるため、ＭＭＥにＳ１−ＡＰメッセージを送信時に、ブロードキャストＰＬＭＮリスト（ｂｒｏａｄｃａｓｔ ＰＬＭＮｓ ｌｉｓｔ）情報を含めることができる。

また、共有ｅＮｏｄｅＢ（Ｓｈａｒｅｄ ｅＮｏｄｅＢ）は、ＵＥに対する位置情報と併せて、ｉ）常にブロードキャストＰＬＭＮリスト情報を含めることができるが、ｉｉ）設定（ｃｏｎｆｉｇｕｒａｔｉｏｎ）に基づいてブロードキャストＰＬＭＮリスト情報を含めることもでき、ｉｉｉ）ＭＭＥが図９の段階５で送信するページングメッセージに含まれた情報（ここで、本発明のために新しく定義された情報であってもよい。）に基づいてブロードキャストＰＬＭＮリスト情報を含めることもできる。また、ブロードキャストＰＬＭＮリスト情報を含めるために、従来のＳ１−ＡＰメッセージ（例えば、ＩＮＩＴＩＡＬ ＵＥ ＭＥＳＳＡＧＥ）を拡張することもでき、新しいＳ１−ＡＰメッセージを定義することもできる。

図９の段階８で、ＵＥ−２に対する位置情報を取得したＭＭＥは、ＨＳＳに、ＵＥ−２に対する位置情報を含む応答メッセージ、例えば、Ｉｎｓｅｒｔ Ｓｕｂｓｃｒｉｂｅｒ Ｄａｔａ Ａｎｓｗｅｒメッセージを送信する。上記ＵＥ−２に対する位置情報は、ｅＮｏｄｅＢのブロードキャストＰＬＭＮリスト（ｂｒｏａｄｃａｓｔ ＰＬＭＮｓ ｌｉｓｔ）情報を含む。これを含むために、従来のＩｎｓｅｒｔ Ｓｕｂｓｃｒｉｂｅｒ Ｄａｔａ Ａｎｓｗｅｒメッセージが拡張されてもよく、新しい応答メッセージが定義されてもよい。

図９の段階９で、ＨＳＳはＰｒｏＳｅサーバーに、ＵＥ−２の位置情報を含む応答メッセージ、例えば、Ｌｏｃａｔｉｏｎ Ｉｎｆｏ Ａｎｓｗｅｒメッセージを送信する。

図９の段階１０で、ＨＳＳからＵＥ−２に対する位置情報を取得したＰｒｏＳｅサーバーは、近接関係（ｐｒｏｘｉｍｉｔｙ）を判断する。共有ネットワーク（Ｓｈａｒｅｄ ｎｅｔｗｏｒｋ）にキャンプ−オンしたＵＥ−１とＵＥ−２が、互いに異なるＰＬＭＮに登録した状態であり、近接 関係（ｐｒｏｘｉｍｉｔｙ）にある場合、ＰｒｏＳｅサーバーは、ＵＥ−１とＵＥ−２に対するブロードキャストＰＬＭＮリスト（ｂｒｏａｄｃａｓｔ ＰＬＭＮｓ ｌｉｓｔ）情報を含む位置情報に基づいて近接関係（ｐｒｏｘｉｍｉｔｙ）を決定することができる。

仮に、図９の段階１でＵＥ−１が自身の位置情報を含めていないと、上記ＰｒｏＳｅサーバーは、ＵＥ−１とＵＥ−２とが近接関係にあるか否かを判断するために、ＵＥ−２の位置情報を取得する方法と同様にしてＵＥ−１の位置情報を取得することができる。

図９の段階１１で、ＰｒｏＳｅサーバーは、近接関係の判断を要請したＵＥ−１にＵＥ−２との近接関係の判断結果を知らせる応答メッセージ、例えば、Ｐｒｏｘｉｍｉｔｙ Ｒｅｓｐｏｎｓｅメッセージを送信する。ここで、ＰｒｏＳｅサーバーは、ＵＥ−１とＵＥ−２とが近接関係にあると、選択的にＵＥ−２にもそれを知らせることができる。

２−６． 第６実施例

図１０は、本発明の更に他の実施例に係るＰｒｏＳｅ探索動作を示す参考図である。

図１０の段階１で、ＵＥ−ＡがＵＥ−Ｂとの近接関係を知るためにＰｒｏＳｅサーバーに近接（ｐｒｏｘｉｍｉｔｙ）情報要請メッセージ、例えば、ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ Ｒｅｑｕｅｓｔメッセージを送信する。この時、ＵＥ−Ａは、一定時間内にＵＥ−Ｂと近接関係（ｐｒｏｘｉｍｉｔｙ）になるとそれを知らせることを要請するために時間情報（例えば、Ｔｉｍｅ＿Ｘ）を含めて送信する。

図１０の段階２で、ＰｒｏＳｅサーバーは、ＵＥ−ＡがＵＥ−Ｂを探索（ｄｉｓｃｏｖｅｒ）できるかパーミッション（ｐｅｒｍｉｓｓｉｏｎ）を検証する。また、この動作は、ＰｒｏＳｅ探索要請又はＰｒｏＳｅ関連動作と関連してＵＥ−Ａを認証（ａｕｔｈｏｒｉｚａｔｉｏｎ）する作業を含むこともできる。

以下、図１０の段階３ａ〜１１ａは、ＵＥ−Ａに対する位置情報を取得するための動作である。

図１０の段階３ａで、ＰｒｏＳｅサーバーはＨＳＳに、ＵＥ−Ａの位置情報を要請するための要請メッセージ、例えば、Ｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔメッセージを送信する。この時、ＰｒｏＳｅサーバーはＴｉｍｅ＿Ｘ情報を含める。

図１０の段階４ａで、ＨＳＳはＭＭＥに、ＵＥ−Ａに対する位置情報を要請するメッセージ、例えば、Ｉｎｓｅｒｔ Ｓｕｂｓｃｒｉｂｅｒ Ｄａｔａ Ｒｅｑｕｅｓｔメッセージを送信する。この時、ＨＳＳは、Ｉｎｓｅｒｔ Ｓｕｂｓｃｒｉｂｅｒ Ｄａｔａ Ｒｅｑｕｅｓｔメッセージを構成するＩＤＲ ｆｌａｇｓにおいてＥＰＳ Ｌｏｃａｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｑｕｅｓｔ値（ｂｉｔ）を設定し、Ｃｕｒｒｅｎｔ Ｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔ値（ｂｉｔ）を設定する。上記第１方案の動作２）に記述された様々な情報がさらに含まれてもよい。また、ＨＳＳはＴｉｍｅ＿Ｘ情報を含める。

図１０の段階５ａで、ＭＭＥはＴｉｍｅ＿Ｘの値でタイマーを始動する。

図１０の段階６ａで、ＭＭＥは、接続状態であるＵＥ−Ａの位置情報を取得するために、ｅＮｏｄｅＢに、位置情報を報告することを要請するメッセージ、例えば、Ｌｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｃｏｎｔｒｏｌメッセージを送信する。この時、上記メッセージに、ＵＥ−Ａに対するサービングセルが変更される度ごとにｅＮｏｄｅＢがＵＥ−Ａの位置情報を報告することを示す指示情報を含める。この段階６ａで、従来のＳ１−ＡＰメッセージであるＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｃｏｎｔｒｏｌメッセージを使用する場合、上記指示情報を含めるために、従来の情報要素（ＩＥ）に新しい値を追加したり新しい情報要素（ＩＥ）を定義したりして使用することができる。

図１０の段階７ａで、ｅＮｏｄｅＢは、ＵＥ−Ａの現在位置（すなわち、最新位置）情報を含む応答メッセージ、例えば、Ｌｏｃａｔｉｏｎ ＲｅｐｏｒｔメッセージをＭＭＥに送信する。

図１０の段階８ａで、ＵＥ−Ａに対する位置情報を取得したＭＭＥは、ＨＳＳに、ＵＥ−Ａに対する位置情報を含むＩｎｓｅｒｔ Ｓｕｂｓｃｒｉｂｅｒ Ｄａｔａ Ａｎｓｗｅｒメッセージを送信する。

図１０の段階９ａで、ＨＳＳはＰｒｏＳｅサーバーに、ＵＥ−Ａの位置情報を含む応答メッセージ、例えば、Ｌｏｃａｔｉｏｎ Ｒｅｓｐｏｎｓｅメッセージを送信する。

図１０の段階１０ａで、ｅＮｏｄｅＢは、上記段階図１０の段階６ａで受信したＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｃｏｎｔｒｏｌメッセージに基づいて、ＵＥ−Ａに対するサービングセルが変更される都度、変更された位置情報を含むメッセージ（例えば、Ｌｏｃａｔｉｏｎ Ｒｅｐｏｒｔメッセージ）をＭＭＥに送信する。これを受信したＭＭＥは、上記受信した位置情報をＨＳＳに送信し、ＨＳＳはこれをＰｒｏＳｅサーバーに送信する。

図１０の段階１１ａで、ＭＭＥは、上記段階５ａで起動されたタイマーが満了（ｅｘｐｉｒｅ）すると、ｅＮｏｄｅＢに、ＵＥ−Ａに対する位置情報をそれ以上報告する必要が無い旨を知らせるメッセージ、例えば、Ｃａｎｃｅｌ Ｌｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇメッセージを送信する。

以下、図１０の段階３ｂ〜１１ｂは、ＵＥ−Ｂに対する位置情報を取得するための動作である。

図１０の段階３ｂで、ＰｒｏＳｅサーバーはＨＳＳに、ＵＥ−Ｂの位置情報を要請するための要請メッセージ、例えば、Ｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔメッセージを送信する。この時、ＰｒｏＳｅサーバーはＴｉｍｅ＿Ｘ情報を含める。

図１０の段階４ｂで、ＨＳＳはＭＭＥに、ＵＥ−Ｂに対する位置情報を要請するメッセージ、例えば、Ｉｎｓｅｒｔ Ｓｕｂｓｃｒｉｂｅｒ Ｄａｔａ Ｒｅｑｕｅｓｔメッセージを送信する。この時、ＨＳＳは、Ｉｎｓｅｒｔ Ｓｕｂｓｃｒｉｂｅｒ Ｄａｔａ Ｒｅｑｕｅｓｔメッセージを構成するＩＤＲ ｆｌａｇｓにおいてＥＰＳ Ｌｏｃａｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｑｕｅｓｔ値（ｂｉｔ）を設定し、Ｃｕｒｒｅｎｔ Ｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔ値（ｂｉｔ）を設定する。上述した第１方案の動作２）に記述された様々な情報がさらに含まれてもよい。また、ＨＳＳはＴｉｍｅ＿Ｘ情報を含める。

図１０の段階５ｂで、ＭＭＥは、Ｔｉｍｅ＿Ｘの値でタイマー起動する。

図１０の段階６ｂ〜７ｂで、上記ＨＳＳの送信したＩｎｓｅｒｔ Ｓｕｂｓｃｒｉｂｅｒ Ｄａｔａ Ｒｅｑｕｅｓｔメッセージを受信したＭＭＥは、上記要請メッセージに基づいて、ＵＥ−Ｂが遊休状態であるため（この実施例ではＵＥ−Ｂが遊休状態であると仮定）、ＵＥ−Ｂにページングを行う。

図１０の段階８ｂで、ページングメッセージを受信したＵＥ−Ｂは、サービス要請手順（Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ ｐｒｏｃｅｄｕｒｅ）を行う（以下、サービス要請手順に関する事項は、３ＧＰＰ ＴＳ ２３．４０１の５．３．４．１節の「ＵＥ ｔｒｉｇｇｅｒｅｄ Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ」参照）。ＭＭＥは、ＵＥ−Ｂに対する位置情報を取得する。この位置情報は、ＵＥ−ＢがＭＭＥに送信したＳｅｒｖｉｃｅ ＲｅｑｕｅｓｔメッセージをｅＮｏｄｅＢがＭＭＥにフォーワーディングするために送信するＳ１−ＡＰメッセージ（例えば、ＩＮＩＴＩＡＬ ＵＥ ＭＥＳＳＡＧＥ）にＵＥに対する位置情報（例えば、ＴＡＩ、ＥＣＧＩなど）を含めることによって取得することができる。

図１０の段階９ｂ−１で、ＵＥ−Ｂに対する位置情報を取得したＭＭＥは、ＨＳＳに、ＵＥ−Ｂに対する位置情報を含む応答メッセージ、例えば、Ｉｎｓｅｒｔ Ｓｕｂｓｃｒｉｂｅｒ Ｄａｔａ Ａｎｓｗｅｒメッセージを送信する。

図１０の段階１０ｂ−１で、ＨＳＳはＰｒｏＳｅサーバーに、ＵＥ−Ｂの位置情報を含む応答メッセージ、例えば、Ｌｏｃａｔｉｏｎ Ｒｅｓｐｏｎｓｅメッセージを送信する。

図１０の段階９ｂ−２で、ＭＭＥは接続状態であるＵＥ−Ｂの位置情報を取得するために、ｅＮｏｄｅＢに、位置情報を報告することを要請するメッセージ、例えば、Ｌｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｃｏｎｔｒｏｌメッセージを送信する。この時、上記メッセージに、ＵＥ−Ｂに対するサービングセルが変更される度ごとにｅＮｏｄｅＢがＵＥ−Ｂの位置情報を報告することを示す指示情報を含めることができる。この段階９ｂ−２で、従来のＳ１−ＡＰメッセージであるＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｃｏｎｔｒｏｌメッセージを使用する場合、上記指示情報を含めるために従、来の情報要素（ＩＥ）に新しい値を追加したり新しい情報要素（ＩＥ）を定義したりして使用することができる。

図１０の段階１０ｂ−２で、ｅＮｏｄｅＢは、図１０の段階９ｂ−２で受信したＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｃｏｎｔｒｏｌメッセージに基づいて、ＵＥ−Ｂに対するサービングセルが変更される都度、変更された位置情報を含むメッセージ、例えば、Ｌｏｃａｔｉｏｎ ＲｅｐｏｒｔメッセージをＭＭＥに送信する。これを受信したＭＭＥは、上記受信した位置情報をＨＳＳに送信し、ＨＳＳはこれをＰｒｏＳｅサーバーに送信する。

図１０の段階１１ｂで、ＭＭＥは、上記段階５ｂで起動したタイマーが満了すると、ｅＮｏｄｅＢに、ＵＥ−Ｂに対する位置情報をそれ以上報告する必要がない旨を知らせるメッセージ、例えば、Ｃａｎｃｅｌ Ｌｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇメッセージを送信する。

ここで、上記ＵＥ−Ａに対する位置情報を取得するための動作（すなわち、段階３ａ〜１１ａ）とＵＥ−Ｂに対する位置情報を取得するための動作（すなわち、段階３ｂ〜１１ｂ）は並列的に行われてもよい。

なお、ＰｒｏＳｅサーバーは同一のＨＳＳにＵＥ−Ａ及びＵＥ−Ｂの位置情報を要請するメッセージを送る時、段階３ａと段階３ｂのようにそれぞれ要請メッセージを送る代わりに、一つの要請メッセージにＵＥ−Ａ及びＵＥ−Ｂに関する情報を含めてＨＳＳに送ることもできる。

図１０の段階１２で、ＰｒｏＳｅサーバーは、上記段階９ａと段階１０ｂ−１でＨＳＳから応答メッセージを受信すると、取得したＵＥ−Ａの位置情報とＵＥ−Ｂの位置情報に基づいて、両ＵＥの近接関係（ｐｒｏｘｉｍｉｔｙ）を判断する。仮に、両ＵＥが近接関係にあると、図１０の段階１４とそれ以降の段階を行う。

図１０の段階１３で、ＰｒｏＳｅサーバーはＨＳＳからＵＥ−Ａに対する位置情報を含むメッセージ又はＵＥ−Ｂに対する位置情報を含むメッセージを受信する都度、ＵＥ−ＡとＵＥ−Ｂとの近接関係を判断する。仮に、両ＵＥが近接関係にあると、図１０の段階１４とそれ以降の段階を行う。

図１０の段階１４で、ＰｒｏＳｅサーバーは、近接関係の判断を要請したＵＥ−Ａに、ＵＥ−Ｂとの近接関係の結果を知らせる応答メッセージ、例えば、ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ Ｒｅｓｐｏｎｓｅメッセージを送信する。

図１０の段階１５で、ＰｒｏＳｅサーバーは、ＵＥ−ＡとＵＥ−Ｂとが近接関係にあると、選択的にＵＥ−Ｂにもそれを知らせるメッセージ、例えば、ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ Ａｌｅｒｔメッセージを送信することができる。

なお、この実施例で、仮にＵＥ−Ａが要請した期間（すなわち、Ｔｉｍｅ＿Ｘ）に、両ＵＥ間の近接関係が成立しないと、ＰｒｏＳｅサーバーは、Ｔｉｍｅ＿Ｘが満了すると、ＵＥ−Ａにそれを知らせるメッセージを送信することもできる。そのために、ＰｒｏＳｅサーバーは、Ｔｉｍｅ＿Ｘ関連のタイマーを図１０の段階１の後に始動させることもできる。

また、図１０の段階１０ａ及び図１０の段階１０ｂ−２と関連して、ｅＮｏｄｅＢがＵＥ−ＡとＵＥ−Ｂに対するサービングセルの変更を知るために、ｅＮｏｄｅＢはＵＥ−ＡとＵＥ−Ｂに対する位置情報をＭＭＥに報告しなければならない期間に（すなわち、ＭＭＥからＣａｎｃｅｌ Ｌｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇメッセージをそれぞれ受信するまで）は、ＵＥ−ＡとＵＥ−Ｂを接続（ｃｏｎｎｅｃｔｅｄ）状態に維持することもできる。

なお、この実施例では、ＭＭＥがＴｉｍｅ＿Ｘに対するタイマーを管理することによって、ＵＥ−Ａが要請した期間にＵＥ−Ａ及びＵＥ−Ｂに対する位置情報を取得することを中心に説明した。しかし、これに限定されず、ｅＮｏｄｅＢがＴｉｍｅ＿Ｘに対するタイマーを管理することによって、ＵＥ−Ａが要請した期間にＵＥ−Ａ及びＵＥ−Ｂに対する位置情報をＭＭＥに報告したり、又はＭＭＥがＴｉｍｅ＿Ｘに対するタイマーを管理することと併行してｅＮｏｄｅＢがＴｉｍｅ＿Ｘに対するタイマーを管理することによって、ＵＥ−Ａが要請した期間にＵＥ−Ａ及びＵＥ−Ｂに対する位置情報をＭＭＥに報告することもできる。また、ＨＳＳ又はＰｒｏＳｅサーバーがＴｉｍｅ＿Ｘに対するタイマーを管理することによって、この実施例でＭＭＥが動作するのと同様に動作することもできる。（すなわち、ＨＳＳは、ＭＭＥに位置情報報告の開始を要請し、タイマーが満了すると、それを取り消す動作を行い、ＰｒｏＳｅサーバーはＨＳＳに位置情報報告の開始を要請し、タイマーが満了すると、それを取り消す動作を行う。）

３． 本発明に係るＥＰＣ−レベルＰｒｏＳｅ探索の実施例

以下、本発明に係るＰｒｏＳｅ探索動作を説明し、より具体的には、ＥＰＣ−レベルＰｒｏＳｅ探索について説明する。

この実施例では、ＰｒｏＳｅサーバーを含むＥＰＣ−レベルＰｒｏＳｅ探索のために、上記ＰｒｏＳｅサーバーは上記ＥＰＣ内に存在し、次のような機能を果たす。
− ＥＰＣ−レベルＰｒｏＳｅ探索機能を支援する端末と相互作用
− 端末の位置情報を取得するためにＨＳＳと相互作用
− 探索を行う端末（探索ＵＥ（Ｄｉｓｃｏｖｅｒｅｒ ＵＥ）、探索者（ｄｉｓｃｏｖｅｒｅｒ））と探索対象端末（被探索ＵＥ（Ｄｉｓｃｏｖｅｒｅｅ ＵＥ）、被探索者（ｄｉｓｃｏｖｅｒｅｅ））との近接関係（ｐｒｏｘｉｍｉｔｙ）を判断
− インバウンドローマー（ｉｎｂｏｕｎｄ ｒｏａｍｅｒ）端末に対する位置情報を取得するために、インバウンドローマーのｈｏｍｅ ＰｒｏＳｅサーバーと通信
− 探索を行う端末（すなわち、探索ＵＥ）と探索対象端末（すなわち、被探索ＵＥ）とが異なったＰＬＭＮに登録された場合のＥＰＣ−レベルＰｒｏＳｅ探索を支援するための他のＰＬＭＮのＰｒｏＳｅサーバーピア（ｐｅｅｒｓ）と通信

上記ＰｒｏＳｅサーバーにＰｒｏＳｅ探索を要請する前に、探索ＵＥ（Ｄｉｓｃｏｖｅｒｅｒ ＵＥ）は、登録されたＰＬＭＮに存在するＰｒｏＳｅサーバーに登録する。したがって、仮に探索者がノン−ローミング（ｎｏｎ−ｒｏａｍｉｎｇ）である場合には、ｈｏｍｅ ＰｒｏＳｅサーバーに登録し、仮に探索者がローミング（ｒｏａｍｉｎｇ）である場合には、ｖｉｓｉｔｅｄ ＰｒｏＳｅサーバーに登録する。

以下に詳述する実施例で、ｅＮｏｄｅＢ／ＭＭＥ／ＨＳＳ／ＰｒｏＳｅサーバーが自身の次のノードに提供するＵＥの位置情報（ｌｏｃａｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎ）の代表例には、セルインフォメーション（ｃｅｌｌ ｉｎｆｏｒｍａｔｉｏｎ）と関連した情報（例、ＥＣＧＩ情報）を挙げることができる。しかし、これに限定されず、「１．３ＧＰＰ ＥＰＳ（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｓｙｓｔｅｍ）のような移動通信システム上のＰｒｏＳｅ探索方法」と関連して記述した様々な位置情報が提供されもよい。

３−１． 第７実施例

図１１は、本発明に係る第７実施例を示すものであり、具体的には、同一ＰＬＭＮ内に存在する場合（ここで、探索者も被探索者もノン−ローミング）のＥＰＣ−レベルＰｒｏＳｅ探索動作を示す参考図である。

現在探索可能な他の端末（以下、ＵＥ−Ｂ）があるかを確認するために、探索を行う端末（以下、ＵＥ−Ａ）は、図１１に示すように、ネットワークにＰｒｏＳｅ探索を要請する。以下の過程で、ＵＥ−Ａ（すなわち、探索者）及びＵＥ−Ｂ（すなわち、被探索者）は両方とも同一ＰＬＭＮに登録され、ノン−ローミング（ｎｏｎ−ｒｏａｍｉｎｇ）である場合を仮定する。

まず、ＵＥ−Ａ及びＵＥ−Ｂは、上記ＰｒｏＳｅサーバーに登録されている。

図１１の段階１で、ＵＥ−Ａは、ＵＥ−Ｂとの近接関係（ｐｒｏｘｉｍｉｔｙ）、すなわちＵＥ−Ｂを探索可能か否かに関する情報を得るために、ＰｒｏＳｅ ｄｉｓｃｏｖｅｒｙ Ｒｅｑｕｅｓｔメッセージを上記ＰｒｏＳｅサーバーに送信する。この時、ＵＥ−Ａは、ＵＥ−Ｂとの近接関係をＰｒｏＳｅサーバーが直ちに提供することを指示する情報を、上記ＰｒｏＳｅ ｄｉｓｃｏｖｅｒｙ Ｒｅｑｕｅｓｔメッセージに含めることができる。ここで、ＵＥ−Ａ及びＵＥ−Ｂは、それぞれＰｒｏＳｅ−可能ＵＥ−Ａ上のアプリケーション及びＰｒｏＳｅ−可能ＵＥ−Ｂ上のアプリケーションを実質的に意味することができる。

図１１の段階２で、ＰｒｏＳｅサーバーは、ＵＥ−Ａから送信されたＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ ｒｅｑｕｅｓｔを認証（ａｕｔｈｏｒｉｚｅ）し、ＵＥ−Ａ／ユーザ−ＡがＵＥ−Ｂ／ユーザ−Ｂを探索することが許容（ｐｅｒｍｉｔ）されるか否かを確認する。仮にＵＥ−Ａ／ユーザ−ＡがＵＥ−Ｂ／ユーザ−Ｂを探索することが許容されないと、図１１の段階１１が行われる。

その後、図１１の段階３ａ〜８ａが、ＵＥ−Ａの位置情報の取得のために行われる。

図１１の段階３ａで、ＰｒｏＳｅサーバーは、ＵＥ−Ａの現在位置情報を要請するために、Ｌｏｃａｔｉｏｎ ＲｅｑｕｅｓｔメッセージをＨＳＳに送信する。

図１１の段階４ａで、ＨＳＳは、ＵＥ−ＡをサービスするＭＭＥにＩｎｓｅｒｔ Ｓｕｂｓｃｒｉｂｅｒ Ｄａｔａ Ｒｅｑｕｅｓｔメッセージを送信する。ここで、ＨＳＳは、Ｉｎｓｅｒｔ Ｓｕｂｓｃｒｉｂｅｒ Ｄａｔａ Ｒｅｑｕｅｓｔメッセージに含まれた「ＥＰＳ Ｌｏｃａｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｑｕｅｓｔ」のビット及び「Ｃｕｒｒｅｎｔ Ｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔ」のビットを、ＵＥ−Ａの最新位置情報をＭＭＥが提供することを要請するように設定することができる。

図１１の段階５ａで、ＵＥ−Ａは接続（ｃｏｎｎｅｃｔｅｄ）状態であると仮定する。ＭＭＥはｅＮｏｄｅＢに、ＵＥ−Ａの最新のセル情報（ｃｅｌｌ ｉｎｆｏｒｍａｔｉｏｎ）を取得するためにＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｃｏｎｔｒｏｌメッセージを送信する。上記Ｌｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｃｏｎｔｒｏｌメッセージに含まれた要請タイプ情報要素（Ｒｅｑｕｅｓｔ Ｔｙｐｅ ＩＥ）は、ＵＥ−Ａの位置情報をｅＮｏｄｅＢが直ちに報告することを指示する。

図１１の段階６ａで、ｅＮｏｄｅＢは、Ｌｏｃａｔｉｏｎ ＲｅｐｏｒｔメッセージをＭＭＥに送信することによって、ＵＥ−Ａの最新セル情報（ｃｅｌｌ ｉｎｆｏｒｍａｔｉｏｎ）を提供する。

図１１の段階７ａで、ＭＭＥは、ＵＥ−Ａの最新位置情報を含むＩｎｓｅｒｔ Ｓｕｂｓｃｒｉｂｅｒ Ｄａｔａ ＡｎｓｗｅｒメッセージをＨＳＳに送信する。

図１１の段階８ａで、ＨＳＳは、ＵＥ−Ａの最新位置情報を含むＬｏｃａｔｉｏｎ ＲｅｓｐｏｎｓｅメッセージをＰｒｏＳｅサーバーに送信する。

次に、図１１の段階３ｂ〜９ｂが、ＵＥ−Ｂの位置情報の取得のために行われる。

図１１の段階３ｂで、ＰｒｏＳｅサーバーはＵＥ−Ｂの現在位置情報を要請するためにＬｏｃａｔｉｏｎ ＲｅｑｕｅｓｔメッセージをＨＳＳに送信する。

図１１の段階４ｂで、ＨＳＳは、ＵＥ−ＢをサービスするＭＭＥにＩｎｓｅｒｔ Ｓｕｂｓｃｒｉｂｅｒ Ｄａｔａ Ｒｅｑｕｅｓｔメッセージを送信する。ここで、ＨＳＳは、Ｉｎｓｅｒｔ Ｓｕｂｓｃｒｉｂｅｒ Ｄａｔａ Ｒｅｑｕｅｓｔメッセージに含まれた「ＥＰＳ Ｌｏｃａｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｑｕｅｓｔ」のビット及び「Ｃｕｒｒｅｎｔ Ｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔ」のビットを、ＵＥ−Ｂの最新位置情報をＭＭＥが提供することを要請するように設定することができる。

図１１の段階５ｂで、ＵＥ−Ｂは遊休状態であると仮定する。ＭＭＥは、ＵＥ−Ｂが登録されているトラッキング（ｔｒａｃｋｉｎｇ）領域に属しているそれぞれのｅＮｏｄｅＢにページングメッセージを送信する。又は、ＭＭＥは、遊休状態であるＵＥ−Ｂをページングする代わりに、ＨＳＳにＵＥが遊休状態であることを知らせる（又は／さらにはこのため、ｃｕｒｒｅｎｔ ｌｏｃａｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎを提供できないことを知らせる）応答メッセージを送信することができる。

又は、ＭＭＥは、遊休状態であるＵＥ−Ｂをページングする代わりに、ｉ）自身が有しているＵＥ−Ｂに対する位置情報（ｌｏｃａｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎ）、ｉｉ）又はｅＮｏｄｅＢに問い合わせて取得したＵＥ−Ｂに対する位置情報を含めて、ＨＳＳに応答メッセージを送信することもできる。この時、上記位置情報を取得した時間情報（例、ＭＭＥが有している位置情報を提供する場合、ＭＭＥがそれを取得した時間、ｅＮｏｄｅＢから問い合わせて位置情報が提供される場合、ｅＮｏｄｅＢがそれをＵＥから取得した時間）を応答メッセージにさらに含めることもできる。

なお、ＭＭＥがページングを行う代わりに上記のような応答を行う基準には、次の一つ以上の情報を用いることができる。
− ＭＭＥ内の設定（ｃｏｎｆｉｇｕｒａｔｉｏｎ）情報
− 加入者情報
− 移動事業者政策（ｏｐｅｒａｔｏｒ ｐｏｌｉｃｙ）
− ユーザ選好（ｕｓｅｒ ｐｒｅｆｅｒｅｎｃｅ）情報
− ユーザセッティング（ｕｓｅｒ ｓｅｔｔｉｎｇ）情報（例、遊休状態時には探索（ｄｉｓｃｏｖｅｒｙ）のための位置情報の取得のためにページングをしないと設定するなど）
− ＨＳＳの送った位置情報要請メッセージにこのような応答を行うようにする情報が明示的又は暗示的に含まれてもよい。なお、ＨＳＳの場合、ＰｒｏＳｅサーバーが上記の情報を含めて位置情報要請メッセージを送ることによって、自身もＭＭＥに上記の情報を含めて位置情報要請メッセージを送ることもできる。また、ＰｒｏＳｅサーバーは、ローカル設定（ｌｏｃａｌ ｃｏｎｆｉｇｕｒａｔｉｏｎ）情報、加入者情報、移動事業者政策（ｏｐｅｒａｔｏｒ ｐｏｌｉｃｙ）、ユーザ選好情報、ユーザセッティング情報などに基づいて上記の情報を含めることを決定することもできる。

上述したＭＭＥが遊休状態であるＵＥをページングせず、ＨＳＳに応答メッセージを送信する事項は、以下に後述する実施例８、９及び１１にも同一に適用することができる。

図１１の段階６ｂで、ＵＥ−ＢはｅＮｏｄｅＢによってページングメッセージを受信する。

図１１の段階７ｂで、受信されたページングメッセージによって、ＵＥ−ＢはＳｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ ｐｒｏｃｅｄｕｒｅを開始する。

図１１の段階８ｂで、図１１の段階７ｂでＵＥ−Ｂのセル情報を取得したＭＭＥは、ＵＥ−Ｂの最新位置情報を含むＩｎｓｅｒｔ Ｓｕｂｓｃｒｉｂｅｒ Ｄａｔａ ＡｎｓｗｅｒメッセージをＨＳＳに送信する。

図１１の段階９ｂで、ＨＳＳは、ＵＥ−Ｂの最新位置情報を含むＬｏｃａｔｉｏｎ ＲｅｓｐｏｎｓｅメッセージをＰｒｏＳｅサーバーに送信する。

図１１の段階１０で、図１１の段階８ａで受信したＬｏｃａｔｉｏｎ Ｒｅｓｐｏｎｓｅメッセージ及び図１１の段階９ｂで受信したＬｏｃａｔｉｏｎ Ｒｅｓｐｏｎｓｅメッセージに基づいて、ＰｒｏＳｅサーバーは、ＵＥ−Ａの位置情報及びＵＥ−Ｂの位置情報、そして近接基準（ｐｒｏｘｉｍｉｔｙ ｃｒｉｔｅｒｉａ）によって、ＵＥ−ＡとＵＥ−Ｂとの近接関係を決定する。

図１１の段階１１で、ＰｒｏＳｅサーバーは、ＵＥ−ＡとＵＥ−Ｂとが近接しているか否か（ｐｒｏｘｉｍｉｔｙ）を示す情報と併せてＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ ＲｅｓｐｏｎｓｅメッセージをＵＥ−Ａに送信する。仮にＵＥ−Ａ／ユーザ−ＡがＵＥ−Ｂ／ユーザ−Ｂを探索する権限がない場合には、ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ Ｒｅｓｐｏｎｓｅメッセージは、ＵＥ−ＡからのＰｒｏＳｅ探索要請が拒絶されたことを示す。

図１１の段階１２で、仮にＵＥ−ＡとＵＥ−Ｂとが近接していると、ＰｒｏＳｅサーバーは、ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ ＡｌｅｒｔメッセージをＵＥ−Ｂに送信し、ＵＥ−ＡがＵＥ−Ｂを探索することを希望していることを知らせることができる。

また、ＵＥ−ＡとＵＥ−Ｂとが相互発見しようと試みてもよい。

なお、ＵＥ−Ａの位置情報を取得するための段階（すなわち、段階３ａ〜８ａ）及びＵＥ−Ｂの位置情報を取得するための段階（すなわち、段階３ｂ〜９ｂ）は並列的に行われてもよい。

仮に、ＵＥ−Ａが遊休状態である場合、遊休状態の位置情報を取得するための図１１の段階５ｂ〜７ｂが、図１１の段階５ａ〜６ａの代わりに行われてもよい。また、仮にＵＥ−Ｂが接続状態である場合には、接続状態の位置情報を取得するための図１１の段階５ａ〜６ａが、図１１の段階５ｂ〜７ｂの代わりに行われてもよい。

図１１で、説明の便宜のために、ＵＥ−ＡとＵＥ−Ｂとが同一ｅＮｏｄｅＢ及び同一ＭＭＥによってサービスされる場合を説明したが、以上で説明した実施例は、異なるｅＮｏｄｅＢ及び同一のＭＭＥによってサービスされたり、同一ｅＮｏｄｅＢ及び異なるＭＭＥによってサービスされたり、異なるｅＮｏｄｅＢ及び異なるＭＭＥによってサービスされる場合にも適用することができる。

３−２． 第８実施例

図１２は、本発明に係る第８実施例を示すものであり、具体的には、同一ＰＬＭＮ内に存在する場合（ここで、探索者も被探索者もノン−ローミング）のＥＰＣ−レベルＰｒｏＳｅ探索動作を示す参考図である。

現在探索可能な他の端末（以下、ＵＥ−Ｂ）があるかを確認するために、探索を行う端末（以下、ＵＥ−Ａ）は、図１２に示すように、ネットワークにＰｒｏＳｅ探索を要請する。以下の過程で、ＵＥ−Ａ（すなわち、探索者）及びＵＥ−Ｂ（すなわち、被探索者）の両方とも同一ＰＬＭＮ（すなわち、ＵＥ−ＡがそのＨＰＬＭＮ（すなわち、ＰＬＭＮ−Ａ）からローミングされている場合にはＰＬＭＮ−Ｂ）に登録されたと仮定する。図１２で、ＨＳＳ−Ａ及びＰｒｏＳｅサーバー−ＡはＰＬＭＮ−Ａに属し、ｅＮｏｄｅＢ、ＭＭＥ、ＨＳＳ−Ｂ及びＰｒｏＳｅサーバー−Ｂは、ＰＬＭＮ−Ｂに属する。

まず、ＵＥ−Ａ及びＵＥ−Ｂは、上記ＰｒｏＳｅサーバー−Ｂに登録されている。

図１２の段階１で、ＵＥ−ＡはＵＥ−Ｂとの近接関係、すなわち、ＵＥ−Ｂが探索可能か否かに関する情報を得るために、ＰｒｏＳｅ ｄｉｓｃｏｖｅｒｙ Ｒｅｑｕｅｓｔメッセージを、ｖｉｓｉｔｅｄ ＰｒｏＳｅサーバーであるＰｒｏＳｅサーバー−Ｂに送信する。この時、ＵＥ−Ａは、ＵＥ−Ｂと近接しているか否かに関する情報をＰｒｏＳｅサーバー−Ｂが直ちに提供することを指示する情報を、上記ＰｒｏＳｅ ｄｉｓｃｏｖｅｒｙ Ｒｅｑｕｅｓｔメッセージに含めることができる。ここで、ＵＥ−Ａ及びＵＥ−Ｂは、それぞれ、ＰｒｏＳｅ−可能ＵＥ−Ａ上のアプリケーション及びＰｒｏＳｅ−可能ＵＥ−Ｂ上のアプリケーションを実質的に意味することができる。

図１２の段階２で、ＰｒｏＳｅサーバー−Ｂは、ＵＥ−Ａから送信されたＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ ｒｅｑｕｅｓｔを認証し、ＵＥ−Ａ／ユーザ−ＡがＵＥ−Ｂ／ユーザ−Ｂを探索することが許容（ｐｅｒｍｉｔ）されるか否かを確認する。仮に、ＵＥ−Ａ／ユーザ−ＡがＵＥ−Ｂ／ユーザ−Ｂを探索することが許容されない場合、図１２の段階１４が行われる。

その後、図１２の段階３ａ〜１２ａがＵＥ−Ａの位置情報の取得のために行われる。

図１２の段階３ａで、ＰｒｏＳｅサーバー−Ｂは、ＵＥ−Ａの現在位置情報を要請するために、ＰｒｏＳｅ Ｌｏｃａｔｉｏｎ ＲｅｑｕｅｓｔメッセージをＰｒｏＳｅサーバー−Ａ（すなわち、Ｈｏｍｅ ＰｒｏＳｅサーバー）に送信する。ここで、ＰｒｏＳｅサーバー−Ｂは、ＵＥ−Ａの位置情報をＰｒｏＳｅサーバー−Ａが直ちにＰｒｏＳｅサーバー−Ｂに提供することを指示する情報を、上記ＰｒｏＳｅ Ｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔメッセージに含めることができる。

図１２の段階４ａで、ＰｒｏＳｅサーバー−ＡはＰｒｏＳｅ Ｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔ ＡｃｋメッセージをＰｒｏＳｅサーバー−Ｂに回答する。

図１２の段階５ａで、ＰｒｏＳｅサーバー−Ａは、ＵＥ−Ａの現在位置情報を要請するために、Ｌｏｃａｔｉｏｎ ＲｅｑｕｅｓｔメッセージをＨＳＳ−Ａに送信する。

図１２の段階６ａで、ＨＳＳ−Ａは、ＵＥ−ＡをサービスするＭＭＥにＩｎｓｅｒｔ Ｓｕｂｓｃｒｉｂｅｒ Ｄａｔａ Ｒｅｑｕｅｓｔメッセージを送信する。ここで、ＨＳＳ−Ａは、Ｉｎｓｅｒｔ Ｓｕｂｓｃｒｉｂｅｒ Ｄａｔａ Ｒｅｑｕｅｓｔメッセージに含まれた「ＥＰＳ Ｌｏｃａｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｑｕｅｓｔ」のビット及び「Ｃｕｒｒｅｎｔ Ｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔ」のビットを、ＵＥ−Ａの最新位置情報をＭＭＥが提供することを要請するように設定することができる。

図１２の段階７ａで、ＵＥ−Ａは接続（ｃｏｎｎｅｃｔｅｄ）状態であると仮定する。ＭＭＥはｅＮｏｄｅＢに、ＵＥ−Ａの最新のセル情報（ｃｅｌｌ ｉｎｆｏｒｍａｔｉｏｎ）を取得するために、Ｌｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｃｏｎｔｒｏｌメッセージを送信する。上記Ｌｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｃｏｎｔｒｏｌメッセージに含まれた要請タイプ情報要素（Ｒｅｑｕｅｓｔ Ｔｙｐｅ ＩＥ）は、ＵＥ−Ａの位置情報をｅＮｏｄｅＢが直ちに報告することを指示する。

図１２の段階８ａで、ｅＮｏｄｅＢは、Ｌｏｃａｔｉｏｎ ＲｅｐｏｒｔメッセージをＭＭＥに送信することによって、ＵＥ−Ａの最新セル情報（ｃｅｌｌ ｉｎｆｏｒｍａｔｉｏｎ）を回答（ｒｅｔｕｒｎ）する。

図１２の段階９ａで、ＭＭＥはＵＥ−Ａの最新位置情報を含むＩｎｓｅｒｔ Ｓｕｂｓｃｒｉｂｅｒ Ｄａｔａ ＡｎｓｗｅｒメッセージをＨＳＳ−Ａに送信する。

図１２の段階１０ａで、ＨＳＳ−ＡはＵＥ−Ａの最新位置情報を含むＬｏｃａｔｉｏｎ ＲｅｓｐｏｎｓｅメッセージをＰｒｏＳｅサーバー−Ａに送信する。

図１２の段階１１ａで、ＰｒｏＳｅサーバー−Ａは、ＵＥ−Ａの現在位置情報を提供するために、ＰｒｏＳｅ Ｌｏｃａｔｉｏｎ ＮｏｔｉｆｉｃａｔｉｏｎメッセージをＰｒｏＳｅサーバー−Ｂに送信する。

図１２の段階１２ａで、ＰｒｏＳｅサーバー−ＢはＰｒｏＳｅサーバー−ＡにＰｒｏＳｅ Ｌｏｃａｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎ Ａｃｋメッセージを回答する。

以下、図１２の段階３ｂ〜９ｂがＵＥ−Ｂの位置情報の取得のために行われる。

図１２の段階３ｂで、ＰｒｏＳｅサーバー−Ｂは、ＵＥ−Ｂの現在位置情報を要請するために、Ｌｏｃａｔｉｏｎ ＲｅｑｕｅｓｔメッセージをＨＳＳ−Ｂに送信する。

図１２の段階４ｂで、ＨＳＳ−Ｂは、ＵＥ−ＢをサービスするＭＭＥにＩｎｓｅｒｔ Ｓｕｂｓｃｒｉｂｅｒ Ｄａｔａ Ｒｅｑｕｅｓｔメッセージを送信する。ここで、ＨＳＳ−Ｂは、Ｉｎｓｅｒｔ Ｓｕｂｓｃｒｉｂｅｒ Ｄａｔａ Ｒｅｑｕｅｓｔメッセージに含まれた「ＥＰＳ Ｌｏｃａｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｑｕｅｓｔ」のビット及び「Ｃｕｒｒｅｎｔ Ｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔ」のビットを、ＵＥ−Ｂの最新位置情報をＭＭＥが提供することを要請するように設定することができる。

図１２の段階５ｂで、ＵＥ−Ｂは遊休状態であると仮定する。ＭＭＥは、ＵＥ−Ｂが登録されているトラッキング（ｔｒａｃｋｉｎｇ）領域に属しているそれぞれのｅＮｏｄｅＢにページングメッセージを送信する。

図１２の段階６ｂで、ＵＥ−ＢはｅＮｏｄｅＢによってページングメッセージを受信する。

図１２の段階７ｂで、受信したページングメッセージによって、ＵＥ−ＢはＳｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ ｐｒｏｃｅｄｕｒｅを開始する。

図１２の段階８ｂで、図１２の段階７ｂでＵＥ−Ｂのセル情報を取得したＭＭＥは、ＵＥ−Ｂの最新位置情報を含むＩｎｓｅｒｔ Ｓｕｂｓｃｒｉｂｅｒ Ｄａｔａ ＡｎｓｗｅｒメッセージをＨＳＳ−Ｂに送信する。

図１２の段階９ｂで、ＨＳＳ−ＢはＵＥ−Ｂの最新位置情報を含むＬｏｃａｔｉｏｎ ＲｅｓｐｏｎｓｅメッセージをＰｒｏＳｅサーバー−Ｂに送信する。

図１２の段階１３で、図１２の段階１１ａで受信されたＰｒｏＳｅ Ｌｏｃａｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージ及び図１２の段階９ｂで受信されたＬｏｃａｔｉｏｎ Ｒｅｓｐｏｎｓｅメッセージに基づいて、ＰｒｏＳｅサーバー−ＢはＵＥ−Ａの位置情報及びＵＥ−Ｂの位置情報並びに近接基準（ｐｒｏｘｉｍｉｔｙ ｃｒｉｔｅｒｉａ）によって、ＵＥ−ＡとＵＥ−Ｂとの近接関係を決定する。

図１２の段階１４で、ＰｒｏＳｅサーバー−Ｂは、ＵＥ−ＡとＵＥ−Ｂとが近接しているか否かを示す情報と併せてＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ ＲｅｓｐｏｎｓｅメッセージをＵＥ−Ａに送信する。仮に、ＵＥ−Ａ／ユーザ−ＡがＵＥ−Ｂ／ユーザ−Ｂを探索する権限がない場合には、ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ ＲｅｓｐｏｎｓｅメッセージはＵＥ−ＡからのＰｒｏＳｅ探索要請が拒絶されたことを示す。

図１２の段階１５で、仮にＵＥ−ＡとＵＥ−Ｂとが近接していると、ＰｒｏＳｅサーバー−ＢはＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ ＡｌｅｒｔメッセージをＵＥ−Ｂに送信し、ＵＥ−ＡがＵＥ−Ｂを探索することを希望していることを知らせることができる。

また、ＵＥ−ＡとＵＥ−Ｂとが相互発見しようと試みてもよい。

なお、ＵＥ−Ａの位置情報を取得するための段階（すなわち、段階３ａ〜１２ａ）及びＵＥ−Ｂの位置情報を取得するための段階（すなわち、段階３ｂ〜９ｂ）は並列的に行われてもよい。

仮に、ＵＥ−Ａが遊休状態である場合、遊休状態の位置情報を取得するための図１２の段階５ｂ〜７ｂが、図１２の段階７ａ〜８ａの代わりに行われてもよい。また、仮にＵＥ−Ｂが接続状態である場合には、接続状態の位置情報を取得するための図１２の段階７ａ〜８ａが、図１２の段階５ｂ〜７ｂの代わりに行われてもよい。

図１２で、説明の便宜のためにＵＥ−ＡとＵＥ−Ｂは同一ｅＮｏｄｅＢ及び同一ＭＭＥによってサービスされる場合を説明したが、以上で説明した実施例は、異なるｅＮｏｄｅＢ及び同一ＭＭＥによってサービスされたり、同一ｅＮｏｄｅＢ及び異なるＭＭＥによってサービスされたり、異なるｅＮｏｄｅＢ及び異なるＭＭＥによってサービスされる場合にも適用することができる。

３−３． 第９実施例

図１３は、本発明に係る第９実施例を示すものであり、具体的には、同一ＰＬＭＮ内に存在する場合（ここで、探索者も被探索者もノン−ローミング）のＥＰＣ−レベルＰｒｏＳｅ探索動作を示す参考図である。

現在探索可能な他の端末（以下、ＵＥ−Ａ）があるかを確認するために、探索を行う端末（以下、ＵＥ−Ｂ）は、図１３に示すように、ネットワークにＰｒｏＳｅ探索を要請する。以下の過程で、ＵＥ−Ｂ（すなわち、探索者）及びＵＥ−Ａ（すなわち、被探索者）の両方とも同一ＰＬＭＮ（すなわち、ＵＥ−ＡがそのＨＰＬＭＮ（すなわち、ＰＬＭＮ−Ａ）からローミングされている場合にはＰＬＭＮ−Ｂ）に登録された場合を仮定する。図１３で、ＨＳＳ−Ａ及びＰｒｏＳｅサーバー−ＡはＰＬＭＮ−Ａに属し、ｅＮｏｄｅＢ、ＭＭＥ、ＨＳＳ−Ｂ及びＰｒｏＳｅサーバー−ＢはＰＬＭＮ−Ｂに属する。

まず、ＵＥ−Ａ及びＵＥ−Ｂは、上記ＰｒｏＳｅサーバー−Ｂに登録されている。

図１３の段階１で、ＵＥ−Ｂは、ＵＥ−Ａとの近接関係、すなわち、ＵＥ−Ａが探索可能か否かに関する情報を得るために、ＰｒｏＳｅ ｄｉｓｃｏｖｅｒｙ Ｒｅｑｕｅｓｔメッセージを、Ｈｏｍｅ ＰｒｏＳｅサーバーであるＰｒｏＳｅサーバー−Ｂに送信する。この時、ＵＥ−Ｂは、ＵＥ−Ａとの近接関係をＰｒｏＳｅサーバー−ＢがＵＥ−Ｂに直ちに提供することを指示する情報を、上記ＰｒｏＳｅ ｄｉｓｃｏｖｅｒｙ Ｒｅｑｕｅｓｔメッセージに含めることができる。ここで、ＵＥ−Ａ及びＵＥ−Ｂは、それぞれ、ＰｒｏＳｅ−可能ＵＥ−Ａ上のアプリケーション及びＰｒｏＳｅ−可能ＵＥ−Ｂ上のアプリケーションを実質的に意味することができる。

図１３の段階２で、ＰｒｏＳｅサーバー−Ｂは、ＵＥ−Ｂから送信されたＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ ｒｅｑｕｅｓｔを認証し、ＵＥ−Ａの現在位置情報を要請するためにＰｒｏＳｅ Ｌｏｃａｔｉｏｎ ＲｅｑｕｅｓｔメッセージをＰｒｏＳｅサーバー−Ａ（すなわち、Ｈｏｍｅ ＰｒｏＳｅサーバー）に送信する。ここで、ＰｒｏＳｅサーバー−Ｂは、ＵＥ−Ａの位置情報をＰｒｏＳｅサーバー−Ａが直ちにＰｒｏＳｅサーバー−Ｂに提供することを指示する情報を、上記ＰｒｏＳｅ Ｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔメッセージに含めることができる。なお、ＰｒｏＳｅサーバー−Ｂは、上記ＰｒｏＳｅ Ｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔメッセージに、ＵＥ−ＢがＵＥ−Ａを探索することを希望する旨の情報を含めることができる。

図１３の段階３で、ＰｒｏＳｅサーバー−Ａは、ＵＥ−Ｂ／ユーザ−ＢがＵＥ−Ａ／ユーザ−Ａを探索することが許容されるか否かを確認する。

図１３の段階４で、ＰｒｏＳｅサーバー−Ａは、ＵＥ−Ｂ／ユーザ−ＢがＵＥ−Ａ／ユーザ−Ａを探索することが許容されるか否かを示す情報と併せて、ＰｒｏＳｅ Ｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔ ＡｃｋメッセージをＰｒｏＳｅサーバー−Ｂに応答する。仮に、ＵＥ−Ｂ／ユーザ−ＢがＵＥ−Ａ／ユーザ−Ａを探索することが許容されない場合には、図１３の段階１５が行われる。

以下、図１３の段階５ａ〜１３ａがＵＥ−Ａの位置情報の取得のために行われる。

図１３の段階５ａで、ＰｒｏＳｅサーバー−Ａは、ＵＥ−Ａの現在位置情報を要請するために、Ｌｏｃａｔｉｏｎ ＲｅｑｕｅｓｔメッセージをＨＳＳ−Ａに送信する。

図１３の段階６ａで、ＨＳＳ−Ａは、ＵＥ−ＡをサービスするＭＭＥにＩｎｓｅｒｔ Ｓｕｂｓｃｒｉｂｅｒ Ｄａｔａ Ｒｅｑｕｅｓｔメッセージを送信する。ここで、ＨＳＳ−ＡはＩｎｓｅｒｔ Ｓｕｂｓｃｒｉｂｅｒ Ｄａｔａ Ｒｅｑｕｅｓｔメッセージに含まれた「ＥＰＳ Ｌｏｃａｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｑｕｅｓｔ」のビット及び「Ｃｕｒｒｅｎｔ Ｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔ」のビットを、ＵＥ−Ａの最新位置情報をＭＭＥが提供することを要請するように設定することができる。

図１３の段階７ａで、ＵＥ−Ａは遊休状態であると仮定する。ＭＭＥは、ＵＥ−Ａが登録されているトラッキング（ｔｒａｃｋｉｎｇ）領域に属しているそれぞれのｅＮｏｄｅＢにページングメッセージを送信する。

図１３の段階８ａで、ＵＥ−Ａは、ｅＮｏｄｅＢによってページングメッセージを受信する。

図１３の段階９ａで、受信したページングメッセージによって、ＵＥ−ＡはＳｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ ｐｒｏｃｅｄｕｒｅを開始する。

図１３の段階１０ａで、図１３の段階９ａでＵＥ−Ａのセル情報を取得したＭＭＥは、ＵＥ−Ａの最新位置情報を含むＩｎｓｅｒｔ Ｓｕｂｓｃｒｉｂｅｒ Ｄａｔａ Ａｎｓｗｅｒメッセージを、ＨＳＳ−Ａに送信する。

図１３の段階１１ａで、ＨＳＳ−Ａは、ＵＥ−Ａの最新位置情報を含むＬｏｃａｔｉｏｎ ＲｅｓｐｏｎｓｅメッセージをＰｒｏＳｅサーバー−Ａに送信する。

図１３の段階１２ａで、ＰｒｏＳｅサーバー−Ａは、ＵＥ−Ａの現在位置情報を提供するためにＰｒｏＳｅ Ｌｏｃａｔｉｏｎ ＮｏｔｉｆｉｃａｔｉｏｎメッセージをＰｒｏＳｅサーバー−Ｂに送信する。

図１３の段階１３ａで、ＰｒｏＳｅサーバー−Ｂは、ＰｒｏＳｅサーバー−ＡにＰｒｏＳｅ Ｌｏｃａｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎ Ａｃｋメッセージを回答する。

以下、図１３の段階５ｂ〜１０ｂは、ＵＥ−Ｂの位置情報の取得のために行われる。

図１３の５ｂで、ＰｒｏＳｅサーバー−Ｂは、ＵＥ−Ｂの現在位置情報を要請するために、Ｌｏｃａｔｉｏｎ ＲｅｑｕｅｓｔメッセージをＨＳＳ−Ｂに送信する。

図１３の６ｂで、ＵＥ−Ｂは接続状態であると仮定する。ＨＳＳ−Ｂは、ＵＥ−ＢをサービスするＭＭＥに、Ｉｎｓｅｒｔ Ｓｕｂｓｃｒｉｂｅｒ Ｄａｔａ Ｒｅｑｕｅｓｔメッセージを送信する。ここで、ＨＳＳ−Ｂは、Ｉｎｓｅｒｔ Ｓｕｂｓｃｒｉｂｅｒ Ｄａｔａ Ｒｅｑｕｅｓｔメッセージに含まれた「ＥＰＳ Ｌｏｃａｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｑｕｅｓｔ」のビット及び「Ｃｕｒｒｅｎｔ Ｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔ」のビットを、ＵＥ−Ｂの最新位置情報をＭＭＥが提供することを要請するように設定することができる。

図１３の７ｂで、ＭＭＥはｅＮｏｄｅＢに、ＵＥ−Ｂの最新のセル情報（ｃｅｌｌ ｉｎｆｏｒｍａｔｉｏｎ）を取得するために、Ｌｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｃｏｎｔｒｏｌメッセージを送信する。上記Ｌｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｃｏｎｔｒｏｌメッセージに含まれた要請タイプ情報要素（Ｒｅｑｕｅｓｔ Ｔｙｐｅ ＩＥ）は、ＵＥ−Ｂの位置情報をｅＮｏｄｅＢが直ちに報告することを指示する。

図１３の段階８ｂで、ｅＮｏｄｅＢは、Ｌｏｃａｔｉｏｎ ＲｅｐｏｒｔメッセージをＭＭＥに送信することによって、ＵＥ−Ａの最新セル情報（ｃｅｌｌ ｉｎｆｏｒｍａｔｉｏｎ）を回答する。

図１３の段階９ｂで、ＭＭＥは、ＵＥ−Ｂの最新位置情報を含むＩｎｓｅｒｔ Ｓｕｂｓｃｒｉｂｅｒ Ｄａｔａ Ａｎｓｗｅｒメッセージを、ＨＳＳ−Ｂに送信する。

図１３の段階１０ｂで、ＨＳＳ−Ｂは、ＵＥ−Ｂの最新位置情報を含むＬｏｃａｔｉｏｎ Ｒｅｓｐｏｎｓｅメッセージを、ＰｒｏＳｅサーバー−Ｂに送信する。

図１３の段階１４で、図１３の段階１２ａで受信したＰｒｏＳｅ Ｌｏｃａｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージ及び図１３の段階１０ｂで受信したＬｏｃａｔｉｏｎ Ｒｅｓｐｏｎｓｅメッセージに基づいて、ＰｒｏＳｅサーバー−Ｂは、ＵＥ−Ａの位置情報及びＵＥ−Ｂの位置情報並びに近接基準（ｐｒｏｘｉｍｉｔｙ ｃｒｉｔｅｒｉａ）によって、ＵＥ−ＡとＵＥ−Ｂとの近接関係を決定する。

図１３の段階１５で、ＰｒｏＳｅサーバー−Ｂは、ＵＥ−ＡとＵＥ−Ｂとが近接しているか否かを示す情報と併せて、ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ ＲｅｓｐｏｎｓｅメッセージをＵＥ−Ｂに送信する。仮に、ＵＥ−Ａ／ユーザ−ＡがＵＥ−Ｂ／ユーザ−Ｂを探索する権限がない場合には、ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ ＲｅｓｐｏｎｓｅメッセージはＵＥ−ＢからのＰｒｏＳｅ探索要請が拒絶されたことを示す。

図１３の段階１６で、仮に、ＵＥ−ＡとＵＥ−Ｂとが近接していると、ＰｒｏＳｅサーバー−Ｂは、ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ ＡｌｅｒｔメッセージをＵＥ−Ａに送信し、ＵＥ−ＢがＵＥ−Ａを探索することを希望していることを知らせることもできる。

また、ＵＥ−ＡとＵＥ−Ｂとが相互発見しようと試みてもよい。

なお、ＵＥ−Ａの位置情報を取得するための段階（すなわち、段階５ａ〜１３ａ）及びＵＥ−Ｂの位置情報を取得するための段階（すなわち、段階５ｂ〜１０ｂ）は並列的に行われてもよい。

仮に、ＵＥ−Ａが接続状態である場合、接続状態の位置情報を取得するための図１３の段階７ｂ〜８ｂが、図１３の段階７ａ〜９ａの代わりに行われてもよい。また、仮にＵＥ−Ｂが遊休状態である場合には、遊休状態の位置情報を取得するための図１３の段階７ａ〜９ａが、図１３の段階７ｂ〜８ｂの代わりに行われてもよい。

図１３で、説明の便宜のために、ＵＥ−ＡとＵＥ−Ｂは同一ｅＮｏｄｅＢ及び同一ＭＭＥによってサービスされる場合を説明したが、以上で説明した実施例は、異なるｅＮｏｄｅＢ及び同一ＭＭＥによってサービスされたり、同一ｅＮｏｄｅＢ及び異なるＭＭＥによってサービスされたり、異なるｅＮｏｄｅＢ及び異なるＭＭＥによってサービスされる場合にも適用することができる。

３−４． 第１０実施例

図１４は、本発明に係る第１０実施例を示すものであり、具体的には、同一ＰＬＭＮ内に存在する場合（ここで、探索者も被探索者もノン−ローミング）に、時間区間（ｔｉｍｅ ｗｉｎｄｏｗ）を適用してＥＰＣ−レベルＰｒｏＳｅ探索動作を示す参考図である。

ＵＥ−Ａは、図１４に示すように、時間区間内にＵＥ−Ｂと近接（ｐｒｏｘｉｍｉｔｙ）関係が成立する場合、これを知るために、ネットワークに時間区間（ｔｉｍｅ ｗｉｎｄｏｗ）と共にＰｒｏＳｅ探索要請を送信する。以下の過程で、ＵＥ−Ｂ（すなわち、探索者）及びＵＥ−Ａ（すなわち、被探索者）の両方も同一ＰＬＭＮ（すなわち、ＵＥ−ＡがそのＨＰＬＭＮ（すなわち、ＰＬＭＮ−Ａ）からローミングされている場合にはＰＬＭＮ−Ｂ）に登録され、ノン−ローミングされた場合を仮定する。

まず、ＵＥ−Ａ及びＵＥ−Ｂは、上記ＰｒｏＳｅサーバーに登録されている。

図１４の段階１で、ＵＥ−ＡはＰｒｏＳｅサーバーに、時間区間内でＵＥ−Ｂと近接（ｐｒｏｘｉｍｉｔｙ）関係が成立する場合、それを知るために、ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ Ｒｅｑｕｅｓｔメッセージを送信する。

この時、ＵＥ−ＡはＰｒｏＳｅサーバーにどれくらいの時間区間まで要請が有効であるかを示す時間区間情報（すなわち、図１４のＴｉｍｅ＿Ｘ）をＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ Ｒｅｑｕｅｓｔメッセージに含めることができる。ここで、ＵＥ−Ａ及びＵＥ−Ｂは、それぞれ、ＰｒｏＳｅ−可能ＵＥ−Ａ上のアプリケーション及びＰｒｏＳｅ−可能ＵＥ−Ｂ上のアプリケーションを実質的に意味することができる。

図１４の段階２で、ＰｒｏＳｅサーバーはＵＥ−Ａから送信されたＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ ｒｅｑｕｅｓｔを認証し、ＵＥ−Ａ／ユーザ−ＡがＵＥ−Ｂ／ユーザ−Ｂを探索することが許容されるか否かを確認する。仮にＵＥ−Ａ／ユーザ−ＡがＵＥ−Ｂ／ユーザ−Ｂを探索することが許容されない場合、図１４の段階１６が行われる。

以下、図１４の段階３ａ〜１４ａがＵＥ−Ａの位置情報の取得のために行われる。

図１４の段階３ａで、ＰｒｏＳｅサーバーはＵＥ−Ａに対してＴｉｍｅ＿Ｘの値でタイマーを起動する。

図１４の段階４ａで、ＰｒｏＳｅサーバーはＨＳＳにＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｒｅｑｕｅｓｔメッセージを送信することによって、ＵＥ−Ａと関連した位置報告を開始することをＨＳＳに要請する。

図１４の段階５ａで、ＭＭＥにＵＥ−Ａと関連した位置報告を開始させるために、ＨＳＳはＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ ＲｅｑｕｅｓｔメッセージをＭＭＥに送信する。

図１４の段階６ａで、ＭＭＥはＨＳＳにＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｒｅｑｕｅｓｔ Ａｃｋメッセージで応答する。

図１４の段階７ａで、ＨＳＳはＰｒｏＳｅサーバーにＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｒｅｑｕｅｓｔ Ａｃｋメッセージで応答する。

図１４の段階８ａで、ＵＥ−Ａは接続モードであると仮定する。ＭＭＥはＵＥ−Ａに対する最新のセル情報（ｃｅｌｌ ｉｎｆｏｒｍａｔｉｏｎ）を取得するために、ｅＮｏｄｅＢにＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｃｏｎｔｒｏｌメッセージを送信する。なお、ＭＭＥは、ＵＥ−ＡがそのサービングセルをｅＮｏｄｅＢに属した他のセルへと変更する都度、ＵＥ−Ａの現在位置をｅＮｏｄｅＢが報告することを指示する情報をＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｃｏｎｔｒｏｌメッセージに含めることができる。

図１４の段階９ａで、ｅＮｏｄｅＢは、Ｌｏｃａｔｉｏｎ ＲｅｐｏｒｔメッセージをＭＭＥに送信することによって、ＵＥ−Ａの最新のセル情報を回答する。

図１４の段階１０ａで、ＭＭＥは、ＵＥ−Ａの最新の位置情報を含むＬｏｃａｔｉｏｎ ＮｏｔｉｆｉｃａｔｉｏｎメッセージをＨＳＳに送信する。

図１４の段階１１ａで、ＨＳＳは、ＵＥ−Ａの最新の位置情報を含むＬｏｃａｔｉｏｎ ＮｏｔｉｆｉｃａｔｉｏｎメッセージをＰｒｏＳｅサーバーに送信する。

図１４の段階１２ａで、ＰｒｏＳｅサーバーは、Ｌｏｃａｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎ ＡｃｋメッセージでＨＳＳに応答する。

図１４の段階１３ａで、ＨＳＳは、Ｌｏｃａｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎ ＡｃｋメッセージでＭＭＥに応答する。

図１４の段階１４ａで、段階９ａ以降に、ｅＮｏｄｅＢは、ＵＥ−ＡがそのサービングセルをｅＮｏｄｅＢに属した他のセルへと変更する都度、Ｌｏｃａｔｉｏｎ ＲｅｐｏｒｔメッセージをＭＭＥに送信する。更新（ｕｐｄａｔｅ）された位置情報は、ＭＭＥからＰｒｏＳｅサーバーに、図１４の段階１０ａ乃至１３ａに示したようにＨＳＳを介して伝達される。

以下、図１４の段階３ｂ〜１４ｂがＵＥ−Ｂの位置情報の取得のために行われる。

図１４の段階３ｂで、ＰｒｏＳｅサーバーはＵＥ−Ｂに対してＴｉｍｅ＿Ｘの値でタイマーを起動する。

図１４の段階４ｂで、ＰｒｏＳｅサーバーはＨＳＳにＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｒｅｑｕｅｓｔメッセージを送信することによって、ＵＥ−Ｂと関連した位置報告を開始することをＨＳＳに要請する。

図１４の段階５ｂで、ＭＭＥにＵＥ−Ｂと関連した位置報告を開始させるために、ＨＳＳはＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ ＲｅｑｕｅｓｔメッセージをＭＭＥに送信する。

図１４の段階６ｂで、ＭＭＥはＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｒｅｑｕｅｓｔ ＡｃｋメッセージでＨＳＳに応答する。

図１４の段階７ｂで、ＨＳＳは、Ｌｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｒｅｑｕｅｓｔ ＡｃｋメッセージでＰｒｏＳｅサーバーに応答する。

図１４の段階８ｂで、ＵＥ−Ｂは遊休状態であると仮定する。ＭＭＥは、ＵＥ−Ｂがｉ）トラッキング領域アップデート手順（ＵＥ−Ｂ ｐｅｒｆｏｒｍｓ Ｔｒａｃｋｉｎｇ Ａｒｅａ Ｕｐｄａｔｅ ｐｒｏｃｅｄｕｒｅ）、或いはｉｉ）端末トリガーされたサービス要請手順（ＵＥ ｔｒｉｇｇｅｒｅｄ Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ ｐｒｏｃｅｄｕｒｅ）、或いはｉｉｉ）ネットワークトリガーされたサービス要請手順（Ｎｅｔｗｏｒｋ ｔｒｉｇｇｅｒｅｄ Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ ｐｒｏｃｅｄｕｒｅ）を行うまで待つ。その後、ＵＥ−Ｂはトラッキング領域アップデート手順又はサービス要請手順を行う。

図１４の段階９ｂで、図１４の段階８ｂでＵＥ−Ｂのセル情報を取得したＭＭＥは、ＵＥ−Ｂの最新位置情報を含むＬｏｃａｔｉｏｎ ＮｏｔｉｆｉｃａｔｉｏｎメッセージをＨＳＳに送信する。

図１４の段階１０ｂで、ＨＳＳは、ＵＥ−Ｂの最新位置情報を含むＬｏｃａｔｉｏｎ ＮｏｔｉｆｉｃａｔｉｏｎメッセージをＰｒｏＳｅサーバーに送信する。

図１４の段階１１ｂで、ＰｒｏＳｅサーバーはＨＳＳにＬｏｃａｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎ Ａｃｋメッセージで応答する。

図１４の段階１２ｂで、ＨＳＳはＭＭＥにＬｏｃａｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎ Ａｃｋメッセージで応答する。

図１４の段階１３ｂで、段階８ｂ以降に、仮にＵＥ−Ｂが段階８ｂによって接続モードに変更されると、ＭＭＥはｅＮｏｄｅＢに、段階８ａで記述したように、ＵＥ−ＢがそのサービングセルをＥｎｏｄｅＢに属した他のセルへと変更する都度、ＵＥ−Ｂの現在位置を報告することを指示するように位置報告制御を行う。

図１４の段階１４ｂで、仮に段階１３ｂでＭＭＥがｅＮｏｄｅＢに対して位置報告制御を行うと、ｅＮｏｄｅＢは、ＵＥ−ＢがそのサービングセルをＥｎｏｄｅＢに属した他のセルへと変更する都度、Ｌｏｃａｔｉｏｎ ＲｅｐｏｒｔメッセージをＭＭＥに送信する。更新された位置情報は、ＭＭＥからＰｒｏＳｅサーバーに、図１４の段階９ｂ乃至１２ｂに示したように、ＨＳＳを介して伝達される。

図１４の段階１５で、図１４の段階１１ａで受信したＬｏｃａｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージ及び図１４の段階１０ｂで受信したＬｏｃａｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージに基づいて、ＰｒｏＳｅサーバーは、ＵＥ−Ａの位置情報及びＵＥ−Ｂの位置情報並びに近接基準（ｐｒｏｘｉｍｉｔｙ ｃｒｉｔｅｒｉａ）によって、ＵＥ−ＡとＵＥ−Ｂとの近接関係を決定する。仮にＰｒｏＳｅサーバーがＵＥ−ＡとＵＥ−Ｂとが近接関係にあると判断する場合には、図１４の段階１６が行われる。そうでないと、ＰｒｏＳｅサーバーは、新しいＬｏｃａｔｉｏｎ ＮｏｔｉｆｉｃａｔｉｏｎメッセージがＨＳＳから受信される都度、近接関係（ｐｒｏｘｉｍｉｔｙ）を確認する。仮に、ＰｒｏＳｅサーバーが、ＵＥ−ＡとＵＥ−Ｂとが近接関係にあると判断したり、仮に図１４の段階３ａで起動したタイマーと図１４の段階３ｂで起動したタイマーが満了すると、図１４の段階１６が行われる。

図１４の段階１６で、ＰｒｏＳｅサーバーは、ＵＥ−Ａに関連した位置報告を中断することをＨＳＳに要請する。この位置報告取消は、ＭＭＥ及び必要な場合にはｅＮｏｄｅＢに適用することができる。

図１４の段階１７で、ＰｒｏＳｅサーバーは、ＵＥ−Ｂに関連した位置報告を中断することをＨＳＳに要請する。この位置報告取消は、ＭＭＥ及び必要な場合にはｅＮｏｄｅＢに適用することができる。

図１４の段階１８で、ＰｒｏＳｅサーバーは、ＵＥ−ＡとＵＥ−Ｂとが近接しているか否かを示す情報と併せて、ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ ＲｅｓｐｏｎｓｅメッセージをＵＥ−Ａに送信する。仮に、ＵＥ−Ａ／ユーザ−ＡがＵＥ−Ｂ／ユーザ−Ｂを探索する権限がない場合には、ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ ＲｅｓｐｏｎｓｅメッセージはＵＥ−ＡからのＰｒｏＳｅ探索要請が拒絶されたことを示す。

図１４の段階１９で、仮に、ＵＥ−ＡとＵＥ−Ｂとが近接していると、ＰｒｏＳｅサーバーはＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ ＡｌｅｒｔメッセージをＵＥ−Ｂに送信し、ＵＥ−ＡがＵＥ−Ｂを探索することを希望していることを知らせることもできる。

また、ＵＥ−ＡとＵＥ−Ｂとが相互発見しようと試みてもよい。

なお、ＵＥ−Ａの位置情報を取得するための段階（すなわち、段階３ａ〜１４ａ）及びＵＥ−Ｂの位置情報を取得するための段階（すなわち、段階３ｂ〜１４ｂ）は並列的に行われてもよい。

また、ＰｒｏＳｅサーバーはＵＥ−Ａ及びＵＥ−Ｂに対してそれぞれ別個のタイマーを起動する代わりに、ＵＥ−Ａ及びＵＥ−Ｂ両方のためのＴｉｍｅ＿Ｘを有する単一タイマーを起動することもできる。

仮に、ＵＥ−Ａが遊休状態である場合、遊休状態の位置情報を取得するための図１４の段階８ｂ〜１４ｂが、図１４の段階８ａ〜１４ａの代わりに行われてもよい。また、仮にＵＥ−Ｂが接続状態である場合には、接続状態の位置情報を取得するための図１４の段階８ａ〜１４ａが、図１４の段階８ｂ〜１４ｂの代わりに行われてもよい。

図１４で、説明の便宜のために、ＵＥ−ＡとＵＥ−Ｂは同一ｅＮｏｄｅＢ及び同一ＭＭＥによってサービスされる場合を説明したが、以上で説明した実施例は、異なるｅＮｏｄｅＢ及び同一ＭＭＥによってサービスされたり、同一ｅＮｏｄｅＢ及び異なるＭＭＥによってサービスされたり、異なるｅＮｏｄｅＢ及び異なるＭＭＥによってサービスされる場合にも適用することができる。

なお、上述した図１４の段階１６〜１７及び段階１８〜１９は並列的に行われてもよい。

また、図１４の段階１６及び１７は、ＰｒｏＳｅサーバーがＵＥ−ＡとＵＥ−Ｂとが近接関係にあると判断した場合に行うことができるが、これと違い、段階１８を行い、ＵＥ−ＡからＵＥ−Ｂを探索したことを確認するメッセージを受信した後に行うこともできる。又は、段階１９を行い、ＵＥ−ＢからＵＥ−Ａを探索したことを確認するメッセージを受信した後に行うこともできる。

３−５． 第１１実施例

図１５は、本発明に係る第１１実施例を示すものであり、具体的には、探索者と被探索者が互いに異なるＰＬＭＮ内に存在する場合（ここで、探索者も被探索者もノン−ローミング）、ＥＰＣ−レベルＰｒｏＳｅ探索動作を示す参考図である。

現在探索可能な他の端末（以下、ＵＥ−Ｂ）があるかを確認するために、探索を行う端末（以下、ＵＥ−Ａ）は、図１５に示すように、ネットワークにＰｒｏＳｅ探索を要請する。以下の過程で、ＵＥ−Ａ（すなわち、探索者）及びＵＥ−Ｂ（すなわち、被探索者）はそれぞれ異なるＰＬＭＮ（すなわち、ＵＥ−Ａ、ＵＥ−ＢはそれぞれＰＬＭＮ−Ａ、ＰＬＭＮ−Ｂ）に登録された場合を仮定する。図１５で、ＵＥ−ＡとＵＥ−Ｂはノン−ローミング（ｎｏｎ−ｒｏａｍｉｎｇ）である場合であり、ＭＭＥ−Ａ、ＨＳＳ−Ａ及びＰｒｏＳｅサーバー−ＡはＰＬＭＮ−Ａに属し、ＭＭＥ−Ｂ、ＨＳＳ−Ｂ及びＰｒｏＳｅサーバー−ＢはＰＬＭＮ−Ｂに属する。

まず、ＵＥ−ＡはＰｒｏＳｅサーバー−Ａに登録されており、ＵＥ−ＢはＰｒｏＳｅサーバー−Ｂに登録されている。

まず、図１５の段階１で、ＵＥ−ＡはＵＥ−Ｂとの近接関係、すなわち、ＵＥ−Ｂが探索可能か否かに関する情報を得るために、ＰｒｏＳｅ ｄｉｓｃｏｖｅｒｙ ＲｅｑｕｅｓｔメッセージをＰｒｏＳｅサーバー−Ａに送信する。この時、ＵＥ−Ａは、ＵＥ−Ｂとの近接関係をＰｒｏＳｅサーバー−ＡがＵＥ−Ａに直ちに提供することを指示する情報を、上記ＰｒｏＳｅ ｄｉｓｃｏｖｅｒｙ Ｒｅｑｕｅｓｔメッセージに含めることができる。ここで、ＵＥ−Ａ及びＵＥ−Ｂは、それぞれ、ＰｒｏＳｅ−可能ＵＥ−Ａ上のアプリケーション及びＰｒｏＳｅ−可能ＵＥ−Ｂ上のアプリケーションを実質的に意味することができる。

図１５の段階２で、ＰｒｏＳｅサーバー−Ａは、ＵＥ−Ａから送信されたＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ ｒｅｑｕｅｓｔを認証し、ＵＥ−Ｂの現在位置情報を要請するためにＰｒｏＳｅ Ｌｏｃａｔｉｏｎ ＲｅｑｕｅｓｔメッセージをＰｒｏＳｅサーバー−Ｂ（すなわち、Ｈｏｍｅ ＰｒｏＳｅサーバー）に送信する。ここで、ＰｒｏＳｅサーバー−Ａは、ＵＥ−Ｂの位置情報をＰｒｏＳｅサーバー−Ｂが直ちにＰｒｏＳｅサーバー−Ａに提供することを指示する情報を、上記ＰｒｏＳｅ Ｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔメッセージに含めることができる。なお、ＰｒｏＳｅサーバー−Ａは上記ＰｒｏＳｅ Ｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔメッセージに、ＵＥ−ＡがＵＥ−Ｂを探索することを希望する旨の情報を含めることができる。被探索者、すなわち、ＵＥ−ＢがＰｒｏＳｅサーバー−Ａに登録されておらず、ＰｒｏＳｅサーバー−Ａは、ＵＥ−Ｂとの近接関係を確認するためにネットワーク共有情報（ｎｅｔｗｏｒｋ ｓｈａｒｉｎｇ ｉｎｆｏｒｍａｔｉｏｎ）が必要であると判断するためである。したがって、ＰｒｏＳｅサーバー−Ａは、ＵＥ−Ｂの位置情報と併せてネットワーク共有情報をＰｒｏＳｅサーバー−ＢがＰｒｏＳｅサーバー−Ａに提供することを指示する情報を、上記ＰｒｏＳｅ Ｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔメッセージに含めることができる。

図１５の段階３で、ＰｒｏＳｅサーバー−Ｂは、ＵＥ−Ａ／ユーザ−ＡがＵＥ−Ｂ／ユーザ−Ｂを探索することが許容されるか確認する。

図１５の段階４で、ＰｒｏＳｅサーバー−Ｂは、ＵＥ−Ａ／ユーザ−ＡがＵＥ−Ｂ／ユーザ−Ｂを探索することが許容されるか否かを示す情報と併せて、ＰｒｏＳｅ Ｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔ ＡｃｋメッセージをＰｒｏＳｅサーバー−Ａに応答する。仮に、ＵＥ−Ａ／ユーザ−ＡがＵＥ−Ｂ／ユーザ−Ｂを探索することが許容されない場合には、図１５の段階１５が行われる。

以下、図１５の段階５ａ〜１３ａがＵＥ−Ｂの位置情報の取得のために行われる。

図１５の段階５ａで、ＰｒｏＳｅサーバー−ＢはＵＥ−Ｂの現在位置情報を要請するために、Ｌｏｃａｔｉｏｎ ＲｅｑｕｅｓｔメッセージをＨＳＳ−Ｂに送信する。ここで、ＰｒｏＳｅサーバー−Ｂは、ＵＥ−Ｂの現在位置情報と併せてネットワーク共有情報をＨＳＳ−ＢがＰｒｏＳｅサーバー−Ｂに提供することを指示する情報を、上記Ｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔメッセージに含めることができる。

図１５の段階６ａで、ＨＳＳ−Ｂは、ＵＥ−ＢをサービスするＭＭＥ−ＢにＩｎｓｅｒｔ Ｓｕｂｓｃｒｉｂｅｒ Ｄａｔａ Ｒｅｑｕｅｓｔメッセージを送信する。ここで、ＨＳＳ−Ｂは、Ｉｎｓｅｒｔ Ｓｕｂｓｃｒｉｂｅｒ Ｄａｔａ Ｒｅｑｕｅｓｔメッセージに含まれた「ＥＰＳ Ｌｏｃａｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｑｕｅｓｔ」のビット及び「Ｃｕｒｒｅｎｔ Ｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔ」のビットを、ＵＥ−Ｂの最新位置情報をＭＭＥ−Ｂが提供することを要請するように設定することができる。また、ＨＳＳ−Ｂは、Ｉｎｓｅｒｔ Ｓｕｂｓｃｒｉｂｅｒ Ｄａｔａ Ｒｅｑｕｅｓｔメッセージに、ネットワーク共有情報をＭＭＥ−ＢがＨＳＳ−Ｂに提供することを指示するために「Ｎｅｔｗｏｒｋ Ｓｈａｒｉｎｇ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｑｕｅｓｔ」の新しいビットを設定することもできる。

図１５の段階７ａで、ＵＥ−Ｂは遊休状態であると仮定する。ＭＭＥ−Ｂは、ＵＥ−Ｂが登録されているトラッキング（ｔｒａｃｋｉｎｇ）領域に属しているそれぞれのｅＮｏｄｅＢにページングメッセージを送信する。

図１５の段階８ａで、ＵＥ−ＢはｅＮｏｄｅＢによってページングメッセージを受信する。

図１５の段階９ａで、受信したページングメッセージによって、ＵＥ−ＢはＳｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ ｐｒｏｃｅｄｕｒｅを開始する。

図１５の段階１０ａで、図１５の段階９ａでＵＥ−Ｂのセル情報を取得したＭＭＥは、ＵＥ−Ｂの最新位置情報を含むＩｎｓｅｒｔ Ｓｕｂｓｃｒｉｂｅｒ Ｄａｔａ Ａｎｓｗｅｒメッセージを、ＨＳＳ−Ｂに送信する。仮に、ＵＥ−ＢをサービスするｅＮｏｄｅＢが共有ＲＡＮ（Ｓｈａｒｅｄ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ；Ｓｈａｒｅｄ ＲＡＮ）である場合、ＭＭＥ−Ｂは、ＵＥ−ＢをサービスするｅＮｏｄｅＢと関連したブロードキャストＰＬＭＮｓに関するネットワーク共有情報を、上記Ｉｎｓｅｒｔ Ｓｕｂｓｃｒｉｂｅｒ Ｄａｔａ Ａｎｓｗｅｒメッセージに含めることができる。ここで、ブロードキャストＰＬＭＮに関する情報は、ＵＥ−ＢをサービスするｅＮｏｄｅＢによってブロードキャストされるＰＬＭＮの識別子リストであってもよい。

また、ＭＭＥは、上記Ｉｎｓｅｒｔ Ｓｕｂｓｃｒｉｂｅｒ Ｄａｔａ Ｒｅｑｕｅｓｔメッセージに含まれたネットワーク共有情報（ｎｅｔｗｏｒｋ ｓｈａｒｉｎｇ ｉｎｆｏｒｍａｔｉｏｎ）を要請する「Ｎｅｔｗｏｒｋ Ｓｈａｒｉｎｇ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｑｕｅｓｔ」ビット情報が設定されていないか存在していなくても、ＵＥ−Ｂをサービスする（ｓｅｒｖｅ）ｅＮｏｄｅＢが共有ＲＡＮである場合、無条件でネットワーク共有情報を含めてＨＳＳに応答メッセージ、すなわち、Ｉｎｓｅｒｔ Ｓｕｂｓｃｒｉｂｅｒ Ｄａｔａ Ａｎｓｗｅｒメッセージを送信することもできる。なお、これは、図１５の段階９ｂにも同一に適用することができる。

図１５の段階１１ａで、ＨＳＳ−ＢはＰｒｏＳｅサーバー−Ｂに、ＵＥ−Ｂの最新の位置情報を提供し、仮にＰＬＭＮの識別子リストが存在する場合には、これを提供するためにＬｏｃａｔｉｏｎ Ｒｅｓｐｏｎｓｅメッセージを送信する。

図１５の段階１２ａで、ＰｒｏＳｅサーバー−ＢはＰｒｏＳｅサーバー−Ａに、ＵＥ−Ｂの最新の位置情報を提供し、仮にＰＬＭＮの識別子リストが存在する場合には、これを提供するためにＰｒｏＳｅ Ｌｏｃａｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージを送信する。

図１５の段階１３ａで、ＰｒｏＳｅサーバー−ＡはＰｒｏＳｅ Ｌｏｃａｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎ ＡｃｋメッセージをＰｒｏＳｅサーバー−Ｂに回答する。

以下、図１５の段階５ｂ〜１０ｂがＵＥ−Ａの位置情報の取得のために行われる。

図１５の段階５ｂで、ＰｒｏＳｅサーバー−Ａは、ＵＥ−Ａの現在位置情報を要請するために、Ｌｏｃａｔｉｏｎ ＲｅｑｕｅｓｔメッセージをＨＳＳ−Ａに送信する。被探索者、すなわち、ＵＥ−ＢがＰｒｏＳｅサーバー−Ａに登録されておらず、ＰｒｏＳｅサーバー−ＡはＵＥ−Ｂとの近接関係を確認するためにネットワーク共有情報（ｎｅｔｗｏｒｋ ｓｈａｒｉｎｇ ｉｎｆｏｒｍａｔｉｏｎ）が必要であると判断するためである。したがって、ＰｒｏＳｅサーバー−Ａは、ＵＥ−Ｂの位置情報と併せてネットワーク共有情報をＨＳＳ−ＡがＰｒｏＳｅサーバー−Ａに提供することを指示する情報を、上記Ｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔメッセージに含めることができる。

図１５の段階６ｂで、ＨＳＳ−Ａは、ＵＥ−ＡをサービスするＭＭＥ−ＡにＩｎｓｅｒｔ Ｓｕｂｓｃｒｉｂｅｒ Ｄａｔａ Ｒｅｑｕｅｓｔメッセージを送信する。ここで、ＨＳＳ−Ａは、Ｉｎｓｅｒｔ Ｓｕｂｓｃｒｉｂｅｒ Ｄａｔａ Ｒｅｑｕｅｓｔメッセージに含まれた「ＥＰＳ Ｌｏｃａｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｑｕｅｓｔ」のビット及び「Ｃｕｒｒｅｎｔ Ｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔ」のビットを、ＵＥ−Ａの最新位置情報をＭＭＥ−Ａが提供することを要請するように設定することができる。また、ＨＳＳ−Ａは、Ｉｎｓｅｒｔ Ｓｕｂｓｃｒｉｂｅｒ Ｄａｔａ Ｒｅｑｕｅｓｔメッセージに、ネットワーク共有情報をＭＭＥ−ＡがＨＳＳ−Ａに提供することを指示するために「Ｎｅｔｗｏｒｋ Ｓｈａｒｉｎｇ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｑｕｅｓｔ」の新しいビットを設定してもよい。

図１５の７ｂで、ＵＥ−Ａは接続状態であると仮定する。ＭＭＥ−ＡはｅＮｏｄｅＢに、ＵＥ−Ａの最新のセル情報（ｃｅｌｌ ｉｎｆｏｒｍａｔｉｏｎ）を取得するために、Ｌｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｃｏｎｔｒｏｌメッセージを送信する。上記Ｌｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｃｏｎｔｒｏｌメッセージに含まれた要請タイプ情報要素（Ｒｅｑｕｅｓｔ Ｔｙｐｅ ＩＥ）は、ＵＥ−Ａの位置情報をｅＮｏｄｅＢが直ちに報告することを指示する。

図１５の段階８ｂで、ｅＮｏｄｅＢはＬｏｃａｔｉｏｎ ＲｅｐｏｒｔメッセージをＭＭＥ−Ａに送信することによって、ＵＥ−Ａの最新セル情報（ｃｅｌｌ ｉｎｆｏｒｍａｔｉｏｎ）を回答する。

図１５の段階９ｂで、ＭＭＥは、ＵＥ−Ａの最新位置情報を含むＩｎｓｅｒｔ Ｓｕｂｓｃｒｉｂｅｒ Ｄａｔａ ＡｎｓｗｅｒメッセージをＨＳＳ−Ａに送信する。仮に、ＵＥ−ＡをサービスするｅＮｏｄｅＢが共有ＲＡＮ（Ｓｈａｒｅｄ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ；Ｓｈａｒｅｄ ＲＡＮ）である場合、ＭＭＥ−Ａは、ＵＥ−ＡをサービスするｅＮｏｄｅＢと関連したブロードキャストＰＬＭＮｓに関するネットワーク共有情報を、上記Ｉｎｓｅｒｔ Ｓｕｂｓｃｒｉｂｅｒ Ｄａｔａ Ａｎｓｗｅｒメッセージに含めることができる。ここで、ブロードキャストＰＬＭＮに関する情報は、ＵＥ−ＡをサービスするｅＮｏｄｅＢによってブロードキャストされるＰＬＭＮの識別子リストであってもよい。

図１５の段階１０ｂで、ＨＳＳ−ＡはＰｒｏＳｅサーバー−Ａに、ＵＥ−Ａの最新の位置情報を含むとともに、仮にＰＬＭＮの識別子リストが存在する場合にはこれを含む、Ｌｏｃａｔｉｏｎ Ｒｅｓｐｏｎｓｅメッセージを送信する。

図１５の段階１４で、図１５の段階１２ａで受信したＰｒｏＳｅ Ｌｏｃａｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージ及び図１５の段階１０ｂで受信したＬｏｃａｔｉｏｎ Ｒｅｓｐｏｎｓｅメッセージに基づいて、ＰｒｏＳｅサーバー−Ａは、ＵＥ−Ａの位置情報及びＵＥ−Ｂの位置情報並びにブロードキャストＰＬＭＮに対するネットワーク共有情報、そして近接基準（ｐｒｏｘｉｍｉｔｙ ｃｒｉｔｅｒｉａ）によって、ＵＥ−ＡとＵＥ−Ｂとの近接関係を決定する。ここで、上記ネットワーク共有情報は、ＭＭＥが提供する代わりに、ＰｒｏＳｅサーバーが自分で設定（ｃｏｎｆｉｇｕｒｅ）していてもよく、他のネットワークノード又は他のＵＥから取得して持っていてもよい。

図１５の段階１５で、ＰｒｏＳｅサーバー−Ａは、ＵＥ−ＡとＵＥ−Ｂとが近接しているか否かを示す情報と併せてＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ Ｒｅｓｐｏｎｓｅメッセージを、ＵＥ−Ａに送信する。仮に、ＵＥ−Ａ／ユーザ−ＡがＵＥ−Ｂ／ユーザ−Ｂを探索する権限がない場合には、ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ Ｒｅｓｐｏｎｓｅメッセージは、ＵＥ−ＡからのＰｒｏＳｅ探索要請が拒絶されたことを示す。

図１５の段階１６乃至１８で、仮にＵＥ−ＡとＵＥ−Ｂとが近接していると、ＰｒｏＳｅサーバー−Ａは、ＰｒｏＳｅサーバー−ＢにＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ ＡｌｅｒｔメッセージをＵＥ−Ｂに送信し、ＵＥ−ＡがＵＥ−Ｂを探索することを希望していることを知らせるように要請することができる。

また、ＵＥ−ＡとＵＥ−Ｂとが相互発見しようと試みてもよい。

なお、ＵＥ−Ａの位置情報を取得するための段階（すなわち、段階５ａ〜１３ａ）及びＵＥ−Ｂの位置情報を取得するための段階（すなわち、段階５ｂ〜１０ｂ）は並列的に行われてもよい。

なお、ＵＥ−Ｂの位置情報を取得するための段階（すなわち、段階５ａ〜１３ａ）及びＵＥ−Ａの位置情報を取得するための段階（すなわち、段階５ｂ〜１０ｂ）は並列的に行われてもよい。

仮に、ＵＥ−Ａが接続状態である場合、接続状態の位置情報を取得するための図１５の段階７ｂ〜８ｂが、図１５の段階７ａ〜９ａの代わりに行われてもよい。また、仮にＵＥ−Ｂが遊休状態である場合には、遊休状態の位置情報を取得するための図１５の段階７ａ〜９ａが、図１５の段階７ｂ〜８ｂの代わりに行われてもよい。

図１５に示した実施例は、ＵＥ−ＡとＵＥ−Ｂが同一ｅＮｏｄｅＢ及び同一ＭＭＥによってサービスされる場合にも適用することができ、異なるｅＮｏｄｅＢ及び同一ＭＭＥによってサービスされたり、同一ｅＮｏｄｅＢ及び異なるＭＭＥによってサービスされたり、異なるｅＮｏｄｅＢ及び異なるＭＭＥによってサービスされる場合にも適用することができる。

３−６． 第１２実施例

図１６は、本発明に係る第１２実施例を示す図であり、時間区間（ｔｉｍｅ ｗｉｎｄｏｗ）が設定されたＥＰＣ−レベルＰｒｏＳｅ探索（ＥＰＣ−ｌｅｖｅｌ ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ）について説明する。

ＵＥ−Ａは、図１６に示すように、時間区間内にＵＥ−Ｂと近接関係（ｐｒｏｘｉｍｉｔｙ）が成立する場合、これを知るために、ネットワークに時間区間（ｔｉｍｅ ｗｉｎｄｏｗ）と共にＰｒｏＳｅ探索を要請する。以下、ＵＥ−Ａ（探索者）とＵＥ−Ｂ（被探索者）は同一ＰＬＭＮに登録されており、ノン−ローミングである場合を仮定する。

この実施例で、ＵＥ−ＡとＵＥ−ＢはＰｒｏＳｅサーバーに登録されている。

図１６の段階１で、ＵＥ−ＡはＰｒｏＳｅサーバーに、時間区間内でＵＥ−Ｂと近接関係が成立する場合、これを知るために、ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ Ｒｅｑｕｅｓｔメッセージを送信する。この時、ＵＥ−Ａは、ＰｒｏＳｅサーバーにどれくらいの時間区間まで要請が有効であるかを示す時間区間情報（すなわち、図１６のＴｉｍｅ＿Ｘ）を、ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ Ｒｅｑｕｅｓｔメッセージに含めることができる。ここで、ＵＥ−Ａ及びＵＥ−Ｂは、それぞれ、ＰｒｏＳｅ−可能ＵＥ−Ａ上のアプリケーション及びＰｒｏＳｅ−可能ＵＥ−Ｂ上のアプリケーションを実質的に意味することができる。

図１６の段階２で、ＰｒｏＳｅサーバーは、ＵＥ−Ａから送信されたＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ ｒｅｑｕｅｓｔを認証し、ＵＥ−Ａ／ユーザ−ＡがＵＥ−Ｂ／ユーザ−Ｂを探索することが許容されるか否かを確認する。仮にＵＥ−Ａ／ユーザ−ＡがＵＥ−Ｂ／ユーザ−Ｂを探索することが許容されない場合、図１６の段階１６が行われる。

以下、図１６の段階３ａ〜１４ａは、ＵＥ−Ａの位置情報の取得のために行われる。

図１６の段階３ａで、ＰｒｏＳｅサーバーはＵＥ−Ａに対してＴｉｍｅ＿Ｘの値でタイマーを起動する。

図１６の段階４ａで、ＰｒｏＳｅサーバーは、ＨＳＳにＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｒｅｑｕｅｓｔメッセージを送信することによって、ＵＥ−Ａと関連した位置報告を開始することをＨＳＳに要請する。

図１６の段階５ａで、ＭＭＥにＵＥ−Ａと関連した位置報告を開始させるために、ＨＳＳはＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ ＲｅｑｕｅｓｔメッセージをＭＭＥに送信する。

図１６の段階６ａで、ＭＭＥはＨＳＳにＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｒｅｑｕｅｓｔ Ａｃｋメッセージで応答する。この時、ＭＭＥは記憶している（例えば、ＵＥのＭＭ ｃｏｎｔｅｘｔに記憶している最後に知っているＥＣＧＩ情報、及び／又は最後のＴＡＵのＴＡＩ（例、ＴＡＩ ｏｆ ｔｈｅ ＴＡ ｉｎ ｗｈｉｃｈ ｔｈｅ ｌａｓｔ Ｔｒａｃｋｉｎｇ Ａｒｅａ Ｕｐｄａｔｅ ｗａｓ ｉｎｉｔｉａｔｅｄ）、及び／又はＣｕｒｒｅｎｔ Ｔｒａｃｋｉｎｇ Ａｒｅａ ｌｉｓｔ）ＵＥ−Ａに対する最新位置情報を、上記Ｌｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｒｅｑｕｅｓｔ Ａｃｋメッセージに含めることができる。これは、以下に記述する本発明の実施例でも同一に適用することができる。

図１６の段階７ａで、ＨＳＳはＰｒｏＳｅサーバーにＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｒｅｑｕｅｓｔ Ａｃｋメッセージで応答する。

図１６の段階８ａで、ＵＥ−Ａは接続モードであると仮定する。ＭＭＥは、ＵＥ−Ａに対する最新のセル情報（ｃｅｌｌ ｉｎｆｏｒｍａｔｉｏｎ）を取得するために、ｅＮｏｄｅＢにＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｃｏｎｔｒｏｌメッセージを送信する。なお、ＭＭＥは、ＵＥ−ＡがそのサービングセルをｅＮｏｄｅＢに属した他のセルへと変更する都度、ＵＥ−Ａの現在位置をｅＮｏｄｅＢが報告することを指示する情報を、Ｌｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｃｏｎｔｒｏｌメッセージに含めることができる。

図１６の段階９ａで、ｅＮｏｄｅＢは、Ｌｏｃａｔｉｏｎ ＲｅｐｏｒｔメッセージをＭＭＥに送信することによって、ＵＥ−Ａの最新のセル情報を回答する。

図１６の段階１０ａで、ＭＭＥは、ＵＥ−Ａの最新の位置情報を含むＬｏｃａｔｉｏｎ ＮｏｔｉｆｉｃａｔｉｏｎメッセージをＨＳＳに送信する。

図１６の段階１１ａで、ＨＳＳは、ＵＥ−Ａの最新の位置情報を含むＬｏｃａｔｉｏｎ ＮｏｔｉｆｉｃａｔｉｏｎメッセージをＰｒｏＳｅサーバーに送信する。

図１６の段階１２ａで、ＰｒｏＳｅサーバーは、Ｌｏｃａｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎ ＡｃｋメッセージでＨＳＳに応答する。

図１６の段階１３ａで、ＨＳＳはＬｏｃａｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎ ＡｃｋメッセージでＭＭＥに応答する。

図１６の段階１４ａで、段階９ａ以降に、ｅＮｏｄｅＢは、ＵＥ−ＡがそのサービングセルをｅＮｏｄｅＢに属した他のセルへと変更する都度、Ｌｏｃａｔｉｏｎ ＲｅｐｏｒｔメッセージをＭＭＥに送信する。更新された位置情報は、ＭＭＥからＰｒｏＳｅサーバーに、図１６の段階１０ａ乃至１３ａに示したようにＨＳＳを介して伝達される。

以下、図１６の段階３ｂ〜１４ｂがＵＥ−Ｂの位置情報の取得のために行われる。

図１６の段階３ｂで、ＰｒｏＳｅサーバーはＵＥ−Ｂに対してＴｉｍｅ＿Ｘの値でタイマーを起動する。

図１６の段階４ｂで、ＰｒｏＳｅサーバーはＨＳＳにＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｒｅｑｕｅｓｔメッセージを送信することによって、ＵＥ−Ｂと関連した位置報告を開始することをＨＳＳに要請する

図１６の段階５ｂで、ＭＭＥにＵＥ−Ｂと関連した位置報告を開始させるために、ＨＳＳはＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ ＲｅｑｕｅｓｔメッセージをＭＭＥに送信する。

図１６の段階６ｂで、ＭＭＥはＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｒｅｑｕｅｓｔ ＡｃｋメッセージでＨＳＳに応答する。

この時、ＭＭＥは、記憶している（例えば、ＵＥのＭＭ ｃｏｎｔｅｘｔに記憶している最後に知らされた（ｌａｓｔ ｋｎｏｗｎ）ＥＣＧＩ情報及び／又は最後のＴＡＵのＴＡＩ（例、ＴＡＩ ｏｆ ｔｈｅ ＴＡ ｉｎ ｗｈｉｃｈ ｔｈｅ ｌａｓｔ Ｔｒａｃｋｉｎｇ Ａｒｅａ Ｕｐｄａｔｅ ｗａｓ ｉｎｉｔｉａｔｅｄ）及び／又はＣｕｒｒｅｎｔ Ｔｒａｃｋｉｎｇ Ａｒｅａ ｌｉｓｔ）ＵＥ−Ｂに対する最新位置情報を、上記Ｌｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｒｅｑｕｅｓｔ Ａｃｋメッセージに含めることができる。これは、以下に記述する本発明の実施例でも同一に適用することができる。

図１６の段階７ｂで、ＨＳＳはＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｒｅｑｕｅｓｔ ＡｃｋメッセージでＰｒｏＳｅサーバーに応答する。

図１６の段階８ｂで、ＵＥ−Ｂは遊休状態であると仮定する。ＭＭＥは、ＵＥ−Ｂがｉ）トラッキング領域アップデート手順（ＵＥ−Ｂ ｐｅｒｆｏｒｍｓ Ｔｒａｃｋｉｎｇ Ａｒｅａ Ｕｐｄａｔｅ ｐｒｏｃｅｄｕｒｅ）、或いはｉｉ）端末トリガーされたサービス要請手順（ＵＥ ｔｒｉｇｇｅｒｅｄ Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ ｐｒｏｃｅｄｕｒｅ）、或いはｉｉｉ）ネットワークトリガーされたサービス要請手順（Ｎｅｔｗｏｒｋ ｔｒｉｇｇｅｒｅｄ Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ ｐｒｏｃｅｄｕｒｅ）を行うまで待つ。その後、ＵＥ−Ｂは、トラッキング領域アップデート手順又はサービス要請手順を行う。

図１６の段階９ｂで、図１６の段階８ｂでＵＥ−Ｂのセル情報を取得したＭＭＥは、ＵＥ−Ｂの最新位置情報を含むＬｏｃａｔｉｏｎ ＮｏｔｉｆｉｃａｔｉｏｎメッセージをＨＳＳに送信する。

図１６の段階１０ｂで、ＨＳＳは、ＵＥ−Ｂの最新位置情報を含むＬｏｃａｔｉｏｎ ＮｏｔｉｆｉｃａｔｉｏｎメッセージをＰｒｏＳｅサーバーに送信する。

図１６の段階１１ｂで、ＰｒｏＳｅサーバーはＨＳＳに、Ｌｏｃａｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎ Ａｃｋメッセージを応答する。

図１６の段階１２ｂで、ＨＳＳはＭＭＥにＬｏｃａｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎ Ａｃｋメッセージを応答する。

図１６の段階１３ｂで、段階８ｂ以降に、仮にＵＥ−Ｂが段階８ｂによって接続モードに変更されると、ＭＭＥはｅＮｏｄｅＢに、段階８ａで記述したように、ＵＥ−ＢがそのサービングセルをＥｎｏｄｅＢに属した他のセルへと変更する都度、ＵＥ−Ｂの現在位置を報告することを指示するように位置報告制御を行う。

図１６の段階１４ｂで、仮に段階１３ｂでＭＭＥがｅＮｏｄｅＢに対して位置報告制御を行うと、ｅＮｏｄｅＢは、ＵＥ−ＢがそのサービングセルをＥｎｏｄｅＢに属した他のセルへと変更する都度、Ｌｏｃａｔｉｏｎ ＲｅｐｏｒｔメッセージをＭＭＥに送信する。更新された位置情報は、ＭＭＥからＰｒｏＳｅサーバーに、図１６の段階９ｂ乃至１２ｂに示したように、ＨＳＳを介して伝達される。

図１６の段階１５で、図１６の段階１１ａで受信したＬｏｃａｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージ及び図１６の段階１０ｂで受信したＬｏｃａｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージに基づいて、ＰｒｏＳｅサーバーは、ＵＥ−Ａの位置情報及びＵＥ−Ｂの位置情報並びに近接基準（ｐｒｏｘｉｍｉｔｙ ｃｒｉｔｅｒｉａ）によって、ＵＥ−ＡとＵＥ−Ｂとの近接関係を決定する。仮に、ＰｒｏＳｅサーバーがＵＥ−ＡとＵＥ−Ｂとが近接関係にあると判断する場合には、図１６の段階１６が行われる。そうでないと、ＰｒｏＳｅサーバーは、新しいＬｏｃａｔｉｏｎ ＮｏｔｉｆｉｃａｔｉｏｎメッセージがＨＳＳから受信される度ごとに近接関係を確認する。仮に、ＰｒｏＳｅサーバーが、ＵＥ−Ａ及びＵＥ−Ｂが近接関係にあると判断したり、仮に図１６の段階３ａで起動したタイマーと図１６の段階３ｂで起動したタイマーが満了すると、図１６の段階１６が行われる。

また、仮に図１６の段階６ａで、ＭＭＥがＵＥ−Ａに対する最新位置情報を上記Ｌｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｒｅｑｕｅｓｔ Ａｃｋメッセージに含めると、図１６の段階１１ａのＬｏｃａｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージの代わりに段階７ａのＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｒｅｑｕｅｓｔ Ａｃｋメッセージを受信時に、これに含まれたＵＥ−Ａの位置情報に基づいて、ＰｒｏＳｅサーバーは最初の近接関係（ｐｒｏｘｉｍｉｔｙ）の決定／確認動作を行うことができる。

また、図１６の段階６ｂで、ＭＭＥがＵＥ−Ｂに対する最新位置情報を上記Ｌｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｒｅｑｕｅｓｔ Ａｃｋメッセージに含めると、段階１０ｂのＬｏｃａｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージの代わりに段階７ｂのＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｒｅｑｕｅｓｔ Ａｃｋメッセージを受信時に、これに含まれたＵＥ−Ｂの位置情報に基づいて、ＰｒｏＳｅサーバーは最初の近接関係の決定／確認動作を行うことができる。

なお、この実施例で説明する最初の近接関係の決定／確認動作に関連した事項は、以下に説明する実施例でも同じ思想として適用することができる。

また、選択的にＰｒｏＳｅサーバーは、次のような最適化（ｏｐｔｉｍｉｚａｔｉｏｎ）動作を行うことができる（なお、以下に説明する動作は、後述する本発明の実施例でも同じ思想として適用することができる。）。

すなわち、ＰｒｏＳｅサーバーが最初の近接関係の決定／確認動作を行った結果、ＵＥ−ＡとＵＥ−Ｂとが一定の距離以上離れていることを認知すると、ＰｒｏＳｅサーバーは、両ＵＥが時間区間（ｔｉｍｅ ｗｉｎｄｏｗ、例、Ｔｉｍｅ＿Ｘ）で互いに近接位置／関係になることが不可能であると判断することができる。

そこで、ＰｒｏＳｅサーバーは、ｉ）それ以上近接確認（ｐｒｏｘｉｍｉｔｙ ｃｈｅｃｋ）を行わないこと、又はｉｉ）近接確認動作を中断／取り消すこと、又はｉｉｉ）近接要請手順／動作を中断／取り消すこと、又はｉｖ）位置報告手順／動作を中断／取り消すこと、又はｖ）ＰｒｏＳｅ探索動作を中断／取り消すことを決定することができる。

そこで、ＰｒｏＳｅサーバーは、ＰｒｏＳｅ探索（ｄｉｓｃｏｖｅｒｙ）を行うＵＥであるＵＥ−Ａに、図１６の段階１で受信したＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ Ｒｅｑｕｅｓｔメッセージに対する応答メッセージ、例えば、ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ Ｒｅｓｐｏｎｓｅメッセージを送信し、図１６の段階１８と段階１９を行うことができる。ここで、上記応答メッセージには、ＵＥ−ＡがＵＥ−Ｂとｉ）近接位置／関係にないことを知らせる情報、及び／又はｉｉ）近接位置／関係になることができないことを知らせる情報、及び／又はｉｉｉ）ＵＥ−ＡとＵＥ−Ｂとが遠く離れていることを知らせる情報などを、明示的又は含蓄的に含めることができる。ここでいう「一定の距離」は、実際の距離値であってもよいが、距離又は両ＵＥが離れている程度を類推できる情報であってもよい。また、「一定の距離」情報は、ＰｒｏＳｅサーバーに設定（ｃｏｎｆｉｇｕｒｅ）されていてもよく（例えば、ｐｒｏｘｉｍｉｔｙ ｃｒｉｔｅｒｉａの形態で）、ＰｒｏＳｅサーバーが他のネットワークノードから取得してもよい。

なお、この実施例では、上記の最適化動作を、近接関係を確認／決定するネットワークノードであるＰｒｏＳｅサーバーで行うが、このような最適化動作は、ＰｒｏＳｅサーバーではなく他のネットワークノード（すなわち、近接関係を確認／決定する他のネットワークノードがある場合、そのノード又はその他のネットワークノード）で行われてもよい。

また、ＵＥの位置情報トラッキング／報告する方法は、実施例のような方法以外の方法（例えば、ＬＣＳ（Ｌｏｃａｔｉｏｎ Ｓｅｒｖｉｃｅｓ）、ＳＵＰＬ（Ｓｅｃｕｒｅ Ｕｓｅｒ Ｐｌａｎｅ Ｌｏｃａｔｉｏｎ）など）が用いられる場合にも適用可能である。また、上記の最適化動作は、最初の近接関係の決定／確認時にのみ行うこともできるが、近接関係の決定／確認の度ごとに行うこともできる。

図１６の段階１６で、ＰｒｏＳｅサーバーは、ＵＥ−ＡとＵＥ−Ｂとが近接しているか否かを示す情報と併せてＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ ＲｅｓｐｏｎｓｅメッセージをＵＥ−Ａに送信する。仮に、ＵＥ−Ａ／ユーザ−ＡがＵＥ−Ｂ／ユーザ−Ｂを探索する権限がない場合には、ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ ＲｅｓｐｏｎｓｅメッセージはＵＥ−ＡからのＰｒｏＳｅ探索要請が拒絶されたことを示す。

図１６の段階１７で、仮に、ＵＥ−ＡとＵＥ−Ｂとが近接していると、ＰｒｏＳｅサーバーはＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ ＡｌｅｒｔメッセージをＵＥ−Ｂに送信し、ＵＥ−ＡがＵＥ−Ｂを探索することを希望していることを知らせることもできる。

また、ＵＥ−ＡとＵＥ−Ｂとが相互発見しようと試みてもよい。

図１６の段階１８で、ＰｒｏＳｅサーバーは、ＵＥ−Ａに関連した位置報告を中断することをＨＳＳに要請する。この位置報告取消は、ＭＭＥ及び必要な場合にはｅＮｏｄｅＢに適用することができる。

図１６の段階１９で、ＰｒｏＳｅサーバーは、ＵＥ−Ｂに関連した位置報告を中断することをＨＳＳに要請する。この位置報告取消は、ＭＭＥ及び必要な場合にはｅＮｏｄｅＢに適用することができる。

なお、ＵＥ−Ａの位置情報を取得するための段階（すなわち、段階３ａ〜１４ａ）及びＵＥ−Ｂの位置情報を取得するための段階（すなわち、段階３ｂ〜１４ｂ）は並列的に行われてもよい。

また、ＰｒｏＳｅサーバーはＵＥ−Ａ及びＵＥ−Ｂに対してそれぞれ別個のタイマーを起動する代わりに、ＵＥ−Ａ及びＵＥ−Ｂ両方のためのＴｉｍｅ＿Ｘを有する単一タイマーを起動することもできる。

仮に、ＵＥ−Ａが遊休状態である場合、遊休状態の位置情報を取得するための図１６の段階８ｂ〜１４ｂが、図１６の段階８ａ〜１４ａの代わりに行われてもよい。また、仮にＵＥ−Ｂが接続状態である場合には、接続状態の位置情報を取得するための図１６の段階８ａ〜１４ａが、図１６の段階８ｂ〜１４ｂの代わりに行われてもよい。

図１６で、説明の便宜のために、ＵＥ−ＡとＵＥ−Ｂは同一ｅＮｏｄｅＢ及び同一ＭＭＥによってサービスされる場合を説明したが、以上で説明した実施例は、異なるｅＮｏｄｅＢ及び同一ＭＭＥによってサービスされたり、同一ｅＮｏｄｅＢ及び異なるＭＭＥによってサービスされたり、異なるｅＮｏｄｅＢ及び異なるＭＭＥによってサービスされる場合にも適用することができる。

３−７． 第１３実施例

図１７は、本発明に係る第１３実施例を示す図であり、探索者及び被探索者が同一ＰＬＭＮに登録されており、探索者はローミングである場合、時間区間が定められたＥＰＣ−レベルＰｒｏＳｅ探索（ＥＰＣ−ｌｅｖｅｌ ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ）について説明する。

ＵＥ−Ａは、図１７に示すように、時間区間内にＵＥ−Ｂと近接関係が成立する場合、これを知るために、ネットワークに時間区間（ｔｉｍｅ ｗｉｎｄｏｗ）と共にＰｒｏＳｅ探索を要請する。以下では、ＵＥ−Ａ（探索者）とＵＥ−Ｂ（被探索者）は同一ＰＬＭＮ（すなわち、ＰＬＭＮ−Ｂ、一方、ＵＥ−ＡはそのＨＰＬＭＮ、すなわち、ＰＬＭＮ−Ａからローミングされた場合）に登録されている場合を仮定する。図１７で、ＨＳＳ−ＡとＰｒｏＳｅサーバー−ＡはＰＬＭＮ−Ａに属し、ｅＮｏｄｅＢ、ＭＭＥ、ＨＳＳ−Ｂ及びＰｒｏＳｅサーバー−ＢはＰＬＭＮ−Ｂに属する。

まず、ＵＥ−Ａ及びＵＥ−ＢはＰｒｏＳｅサーバー−Ｂに登録されている。

図１７の段階１で、ＵＥ−ＡはＰｒｏＳｅサーバー−Ｂ、すなわち、ＵＥ−Ａのｖｉｓｔｅｄ ＰｒｏＳｅサーバーに、時間区間内でＵＥ−Ｂと近接関係が成立する場合、これを知るために、ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ Ｒｅｑｕｅｓｔメッセージを送信する。この時、ＵＥ−ＡはＰｒｏＳｅサーバー−Ｂにどれくらいの時間区間まで要請が有効であるかを示す時間区間情報（すなわち、図１７のＴｉｍｅ＿Ｘ）をＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ Ｒｅｑｕｅｓｔメッセージに含めることができる。ここで、ＵＥ−Ａ及びＵＥ−Ｂは、それぞれ、ＰｒｏＳｅ−可能ＵＥ−Ａ上のアプリケーション及びＰｒｏＳｅ−可能ＵＥ−Ｂ上のアプリケーションを実質的に意味することができる。

図１７の段階２で、ＰｒｏＳｅサーバーはＵＥ−Ａから送信されたＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ ｒｅｑｕｅｓｔを認証し、ＵＥ−Ａ／ユーザ−ＡがＵＥ−Ｂ／ユーザ−Ｂを探索することが許容されるか否かを確認する。仮にＵＥ−Ａ／ユーザ−ＡがＵＥ−Ｂ／ユーザ−Ｂを探索することが許容されない場合、図１７の段階２０が行われる。

以下、図１７の段階３ａ〜１８ａがＵＥ−Ａの位置情報の取得のために行われる。

図１７の段階３ａで、ＰｒｏＳｅサーバー−ＢはＵＥ−Ａに対してＴｉｍｅ＿Ｘの値でタイマーを起動する。

図１７の段階４ａで、ＰｒｏＳｅサーバー−Ｂは、ＰｒｏＳｅサーバー−Ａ（すなわち、ＵＥ−ＡのＨｏｍｅ Ｐｒｏｓｅサーバー）にＰｒｏＳｅ Ｌｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｒｅｑｕｅｓｔメッセージを送信することによって、ＵＥ−Ａと関連した位置報告を要請する。

図１７の段階５ａで、ＰｒｏＳｅサーバー−Ａは、ＰｒｏＳｅ Ｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔ ＡｃｋメッセージをＰｒｏＳｅサーバー−Ｂに回答する。

図１７の段階６ａで、ＰｒｏＳｅサーバー−ＡはＨＳＳ−ＡにＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｒｅｑｕｅｓｔメッセージを送信することによって、ＵＥ−Ａと関連した位置報告を開始することをＨＳＳ−Ａに要請する。

図１７の段階７ａで、ＭＭＥにＵＥ−Ａと関連した位置報告を開始させるために、ＨＳＳ−ＡはＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ ＲｅｑｕｅｓｔメッセージをＭＭＥに送信する。

図１７の段階８ａで、ＭＭＥはＨＳＳ−ＡにＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｒｅｑｕｅｓｔ Ａｃｋメッセージで応答する。

図１７の段階９ａで、ＨＳＳ−ＡはＰｒｏＳｅサーバー−ＡにＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｒｅｑｕｅｓｔ Ａｃｋメッセージで応答する。

図１７の段階１０ａで、ＵＥ−Ａは接続モードであると仮定する。ＭＭＥはＵＥ−Ａに対する最新のセル情報（ｃｅｌｌ ｉｎｆｏｒｍａｔｉｏｎ）を取得するために、ｅＮｏｄｅＢにＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｃｏｎｔｒｏｌメッセージを送信する。なお、ＭＭＥは、ＵＥ−ＡがそのサービングセルをｅＮｏｄｅＢに属した他のセルへと変更する都度、ＵＥ−Ａの現在位置をｅＮｏｄｅＢが報告することを指示する情報をＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｃｏｎｔｒｏｌメッセージに含めることができる。

図１７の段階１１ａで、ｅＮｏｄｅＢはＬｏｃａｔｉｏｎ ＲｅｐｏｒｔメッセージをＭＭＥに送信することによって、ＵＥ−Ａの最新のセル情報を回答する。

図１７の段階１２ａで、ＭＭＥはＵＥ−Ａの最新の位置情報を含むＬｏｃａｔｉｏｎ ＮｏｔｉｆｉｃａｔｉｏｎメッセージをＨＳＳ−Ａに送信する。

図１７の段階１３ａで、ＨＳＳ−Ａは、ＵＥ−Ａの最新の位置情報を含むＬｏｃａｔｉｏｎ ＮｏｔｉｆｉｃａｔｉｏｎメッセージをＰｒｏＳｅサーバー−Ａに送信する。

図１７の段階１４ａで、ＰｒｏＳｅサーバー−ＡはＬｏｃａｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎ ＡｃｋメッセージでＨＳＳ−Ａに応答する。

図１７の段階１５ａで、ＨＳＳ−ＡはＬｏｃａｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎ ＡｃｋメッセージでＭＭＥに応答する。

図１７の段階１６ａで、ＰｒｏＳｅサーバー−Ａは、ＵＥ−Ａの現在位置情報を提供するために、ＰｒｏＳｅ Ｌｏｃａｔｉｏｎ ＮｏｔｉｆｉｃａｔｉｏｎメッセージをＰｒｏＳｅサーバー−Ｂに送信する。

図１７の段階１７ａで、ＰｒｏＳｅサーバー−Ｂは、ＰｒｏＳｅ Ｌｏｃａｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎ ＡｃｋメッセージをＰｒｏＳｅサーバー−Ａに回答する。

図１７の段階１８ａで、段階１１ａ以降に、ｅＮｏｄｅＢは、ＵＥ−ＡがそのサービングセルをｅＮｏｄｅＢに属した他のセルへと変更する都度、Ｌｏｃａｔｉｏｎ ＲｅｐｏｒｔメッセージをＭＭＥに送信する。更新された位置情報は、ＭＭＥからＰｒｏＳｅサーバー−Ａに、図１７の段階１２ａ乃至１５ａに示したようにＨＳＳ−Ａを介して伝達される。仮に、ＰｒｏＳｅサーバー−Ａが更新された位置情報を受信すると、受信した情報を、図１７の段階１６ａ乃至段階１７ａに示したように、ＰｒｏＳｅサーバー−Ｂにフォワード（ｆｏｒｗａｒｄ）することができる。

以下、図１７の段階３ｂ〜１４ｂがＵＥ−Ｂの位置情報の取得のために行われる。

図１７の段階３ｂで、ＰｒｏＳｅサーバー−ＢはＵＥ−Ｂに対してＴｉｍｅ＿Ｘの値でタイマーを起動する。

図１７の段階４ｂで、ＰｒｏＳｅサーバー−ＢはＨＳＳ−ＢにＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｒｅｑｕｅｓｔメッセージを送信することによって、ＵＥ−Ｂと関連した位置報告を開始することをＨＳＳ−Ｂに要請する。

図１７の段階５ｂで、ＭＭＥにＵＥ−Ｂと関連した位置報告を開始させるために、ＨＳＳ−ＢはＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ ＲｅｑｕｅｓｔメッセージをＭＭＥに送信する。

図１７の段階６ｂで、ＭＭＥはＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｒｅｑｕｅｓｔ ＡｃｋメッセージでＨＳＳ−Ｂに応答する。

図１７の段階７ｂで、ＨＳＳ−ＢはＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｒｅｑｕｅｓｔ ＡｃｋメッセージでＰｒｏＳｅサーバー−Ｂに応答する。

図１７の段階８ｂで、ＵＥ−Ｂは遊休状態であると仮定する。ＭＭＥは、ＵＥ−Ｂがｉ）トラッキング領域アップデート手順（ＵＥ−Ｂ ｐｅｒｆｏｒｍｓ Ｔｒａｃｋｉｎｇ Ａｒｅａ Ｕｐｄａｔｅ ｐｒｏｃｅｄｕｒｅ）、或いはｉｉ）端末トリガーされたサービス要請手順（ＵＥ ｔｒｉｇｇｅｒｅｄ Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ ｐｒｏｃｅｄｕｒｅ）、或いはｉｉｉ）ネットワークトリガーされたサービス要請手順（Ｎｅｔｗｏｒｋ ｔｒｉｇｇｅｒｅｄ Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ ｐｒｏｃｅｄｕｒｅ）を行うまで待つ。その後、ＵＥ−Ｂはトラッキング領域アップデート手順又はサービス要請手順を行う。

図１７の段階９ｂで、図１７の段階８ｂでＵＥ−Ｂのセル情報を取得したＭＭＥは、ＵＥ−Ｂの最新位置情報を含むＬｏｃａｔｉｏｎ ＮｏｔｉｆｉｃａｔｉｏｎメッセージをＨＳＳ−Ｂに送信する。

図１７の段階１０ｂで、ＨＳＳ−Ｂは、ＵＥ−Ｂの最新位置情報を含むＬｏｃａｔｉｏｎ ＮｏｔｉｆｉｃａｔｉｏｎメッセージをＰｒｏＳｅサーバー−Ｂに送信する。

図１７の段階１１ｂで、ＰｒｏＳｅサーバー−ＢはＨＳＳ−ＢにＬｏｃａｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎ Ａｃｋメッセージを応答する。

図１７の段階１２ｂで、ＨＳＳ−ＢはＭＭＥにＬｏｃａｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎ Ａｃｋメッセージを応答する。

図１７の段階１３ｂで、段階８ｂ以降に、仮にＵＥ−Ｂが段階８ｂによって接続モードに変更されると、ＭＭＥはｅＮｏｄｅＢに、段階１０ａで記述したように、ＵＥ−ＢがそのサービングセルをＥｎｏｄｅＢに属した他のセルへと変更する都度、ＵＥ−Ｂの現在位置を報告することを指示するように位置報告制御を行う。

図１７の段階１４ｂで、仮に段階１３ｂでＭＭＥがｅＮｏｄｅＢに対して位置報告制御を行うと、ｅＮｏｄｅＢは、ＵＥ−ＢがそのサービングセルをＥｎｏｄｅＢに属した他のセルへと変更する都度、Ｌｏｃａｔｉｏｎ ＲｅｐｏｒｔメッセージをＭＭＥに送信する。更新された位置情報は、ＭＭＥからＰｒｏＳｅサーバー−Ｂに、図１７の段階９ｂ乃至１２ｂに示したように、ＨＳＳ−Ｂを介して伝達される。

図１７の段階１９で、図１７の段階１６ａで受信されたＰｒｏＳｅ Ｌｏｃａｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージ及び図１７の段階１０ｂで受信したＬｏｃａｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージに基づいて、ＰｒｏＳｅサーバー−ＢはＵＥ−Ａの位置情報及びＵＥ−Ｂの位置情報並びに近接基準（ｐｒｏｘｉｍｉｔｙ ｃｒｉｔｅｒｉａ）によって、ＵＥ−ＡとＵＥ−Ｂとの近接関係を決定する。仮に、ＰｒｏＳｅサーバー−ＢがＵＥ−ＡとＵＥ−Ｂとが近接関係にあると判断する場合には、図１７の段階２０が行われる。そうでないと、ＰｒｏＳｅサーバー−Ｂは、新しいＬｏｃａｔｉｏｎ ＮｏｔｉｆｉｃａｔｉｏｎメッセージがＰｒｏＳｅサーバー−Ａ又はＨＳＳ−Ｂから受信される度ごとに近接関係を確認する。仮に、ＰｒｏＳｅサーバーが、ＵＥ−Ａ及びＵＥ−Ｂが近接関係にあると判断したり、仮に図１７の段階３ａで起動したタイマーと図１７の段階３ｂで起動したタイマーが満了すると、図１７の段階２０が行われる。

図１７の段階２０で、ＰｒｏＳｅサーバー−ＢはＵＥ−ＡとＵＥ−Ｂとが近接しているか否かを示す情報と併せてＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ ＲｅｓｐｏｎｓｅメッセージをＵＥ−Ａに送信する。仮に、ＵＥ−Ａ／ユーザ−ＡがＵＥ−Ｂ／ユーザ−Ｂを探索する権限がない場合には、ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ Ｒｅｓｐｏｎｓｅメッセージは、ＵＥ−ＡからのＰｒｏＳｅ探索要請が拒絶されたことを示す。

図１７の段階２１で、仮に、ＵＥ−ＡとＵＥ−Ｂとが近接していると、ＰｒｏＳｅサーバー−ＢはＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ ＡｌｅｒｔメッセージをＵＥ−Ｂに送信し、ＵＥ−ＡがＵＥ−Ｂを探索することを希望していることを知らせることもできる。

また、ＵＥ−ＡとＵＥ−Ｂとが相互発見しようと試みてもよい。

図１７の段階２２で、ＰｒｏＳｅサーバー−Ｂは、ＵＥ−Ａに関連した位置報告を中断することをＰｒｏＳｅサーバー−Ａに要請する。この位置報告取消は、ＨＳＳ−Ａを介してＭＭＥ及び必要な場合にはｅＮｏｄｅＢに適用することができる。

図１７の段階２３で、ＰｒｏＳｅサーバー−Ｂは、ＵＥ−Ｂに関連した位置報告を中断することをＨＳＳ−Ｂに要請する。この位置報告取消は、ＭＭＥ及び必要な場合にはｅＮｏｄｅＢに適用することができる。

なお、ＵＥ−Ａの位置情報を取得するための段階（すなわち、段階３ａ〜１８ａ）及びＵＥ−Ｂの位置情報を取得するための段階（すなわち、段階３ｂ〜１４ｂ）は並列的に行われてもよい。

また、ＰｒｏＳｅサーバー−Ｂは、ＵＥ−Ａ及びＵＥ−Ｂに対してそれぞれ別個のタイマーを起動する代わりに、ＵＥ−Ａ及びＵＥ−Ｂ両方のためのＴｉｍｅ＿Ｘを有する単一タイマーを起動することもできる。

仮にＵＥ−Ａが遊休状態である場合、遊休状態の位置情報を取得するための図１７の段階８ｂ〜１４ｂが、図１７の段階１０ａ〜１５ａ及び段階１８ａの代わりに行われてもよい。また、仮にＵＥ−Ｂが接続状態である場合には、接続状態の位置情報を取得するための図１７の段階１０ａ〜１５ａ及び段階１８ａが、図１７の段階８ｂ〜１４ｂの代わりに行われてもよい。

図１７で、説明の便宜のために、ＵＥ−ＡとＵＥ−Ｂは同一ｅＮｏｄｅＢ及び同一ＭＭＥによってサービスされる場合を説明したが、以上で説明した実施例は、異なるｅＮｏｄｅＢ及び同一ＭＭＥによってサービスされたり、同一ｅＮｏｄｅＢ及び異なるＭＭＥによってサービスされたり、異なるｅＮｏｄｅＢ及び異なるＭＭＥによってサービスされる場合にも適用することができる。

３−８． 第１４実施例

図１８は、本発明に係る第１４実施例を示す図であり、探索者及び被探索者が同一ＰＬＭＮに登録されており、被探索者はローミングである場合、時間区間が定められたＥＰＣ−レベルＰｒｏＳｅ探索（ＥＰＣ−ｌｅｖｅｌ ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ）について説明する。

ＵＥ−Ｂは、図１８に示すように、時間区間内にＵＥ−Ａと近接関係が成立する場合、これを知るために、ネットワークに時間区間（ｔｉｍｅ ｗｉｎｄｏｗ）と共にＰｒｏＳｅ探索を要請する。以下では、ＵＥ−Ｂ（探索者）及びＵＥ−Ａ（被探索者）は同一ＰＬＭＮ（すなわち、ＰＬＭＮ−Ｂ、一方、ＵＥ−ＡはそのＨＰＬＭＮ、すなわちＰＬＭＮ−Ａからローミングされた場合）に登録されている場合を仮定する。図１８で、ＨＳＳ−Ａ及びＰｒｏＳｅサーバー−ＡはＰＬＭＮ−Ａに属し、ｅＮｏｄｅＢ、ＭＭＥ、ＨＳＳ−Ｂ及びＰｒｏＳｅサーバー−ＢはＰＬＭＮ−Ｂに属する。

まず、ＵＥ−Ａ及びＵＥ−ＢはＰｒｏＳｅサーバー−Ｂに登録されている。

図１８の段階１で、ＵＥ−ＢはＰｒｏＳｅサーバー−Ｂに、時間区間内でＵＥ−Ａと近接関係が成立する場合、これを知るために、ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ Ｒｅｑｕｅｓｔメッセージを送信する。この時、ＵＥ−ＢはＰｒｏＳｅサーバー−Ｂにどれくらいの時間区間まで要請が有効であるかを示す時間区間情報（すなわち、図１８のＴｉｍｅ＿Ｘ）をＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ Ｒｅｑｕｅｓｔメッセージに含めることができる。ここで、ＵＥ−Ａ及びＵＥ−Ｂは、それぞれ、ＰｒｏＳｅ−可能ＵＥ−Ａ上のアプリケーション及びＰｒｏＳｅ−可能ＵＥ−Ｂ上のアプリケーションを実質的に意味することができる。

図１８の段階２で、ＰｒｏＳｅサーバー−Ｂは、ＵＥ−Ｂから送信されたＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ ｒｅｑｕｅｓｔを認証し、ＵＥ−ＡのＨｏｍｅ ＰｒｏＳｅサーバーであるＰｒｏＳｅサーバー−ＡにＰｒｏＳｅ Ｐｅｒｍｉｓｓｉｏｎ Ｃｈｅｃｋ Ｒｅｑｕｅｓｔメッセージを送信することによって、ＵＥ−Ｂ／ユーザ−ＢがＵＥ−Ａ／ユーザ−Ａを探索することが許容されるか否かを確認することを要請する。

図１８の段階３で、ＰｒｏＳｅサーバー−Ａは、ＵＥ−Ｂ／ユーザ−ＢがＵＥ−Ａ／ユーザ−Ａを探索することが許容されるか否かを確認する。

図１８の段階４で、ＰｒｏＳｅサーバー−Ａは、ＰｒｏＳｅ Ｐｅｒｍｉｓｓｉｏｎ Ｃｈｅｃｋ Ｒｅｓｐｏｎｓｅメッセージを、ＵＥ−Ｂ／ユーザ−ＢがＵＥ−Ａ／ユーザ−Ａを探索することが許容（ｐｅｒｍｉｔ）されるか否かを示す情報と併せてＰｒｏＳｅサーバー−Ｂに送信する。仮にＵＥ−Ｂ／ユーザ−ＢがＵＥ−Ａ／ユーザ−Ａを探索することが許容されない場合、図１８の段階２２が行われる。

以下、図１８の段階５ａ〜２０ａがＵＥ−Ａの位置情報の取得のために行われる。

図１８の段階５ａで、ＰｒｏＳｅサーバー−ＢはＵＥ−Ａに対してＴｉｍｅ＿Ｘの値でタイマーを起動する。

図１８の段階６ａで、ＰｒｏＳｅサーバー−ＢはＰｒｏＳｅサーバー−Ａ（すなわち、ＵＥ−ＡのＨｏｍｅ Ｐｒｏｓｅサーバー）にＰｒｏＳｅ Ｌｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｒｅｑｕｅｓｔメッセージを送信することによって、ＵＥ−Ａと関連した位置報告を要請する。

図１８の段階７ａで、ＰｒｏＳｅサーバー−Ａは、ＰｒｏＳｅ Ｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔ ＡｃｋメッセージをＰｒｏＳｅサーバー−Ｂに回答する。

図１８の段階８ａで、ＰｒｏＳｅサーバー−ＡはＨＳＳ−ＡにＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｒｅｑｕｅｓｔメッセージを送信することによって、ＵＥ−Ａと関連した位置報告を開始することをＨＳＳ−Ａに要請する。

図１８の段階９ａで、ＭＭＥにＵＥ−Ａと関連した位置報告を開始させるために、ＨＳＳ−ＡはＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ ＲｅｑｕｅｓｔメッセージをＭＭＥに送信する。

図１８の段階１０ａで、ＭＭＥはＨＳＳ−ＡにＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｒｅｑｕｅｓｔ Ａｃｋメッセージで応答する。

図１８の段階１１ａで、ＨＳＳ−ＡはＰｒｏＳｅサーバー−ＡにＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｒｅｑｕｅｓｔ Ａｃｋメッセージで応答する。

図１８の段階１２ａで、ＵＥ−Ａは遊休状態であると仮定する。ＭＭＥは、ＵＥ−Ａがｉ）トラッキング領域アップデート手順（ＵＥ−Ｂ ｐｅｒｆｏｒｍｓ Ｔｒａｃｋｉｎｇ Ａｒｅａ Ｕｐｄａｔｅ ｐｒｏｃｅｄｕｒｅ）、或いはｉｉ）端末トリガーされたサービス要請手順（ＵＥ ｔｒｉｇｇｅｒｅｄ Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ ｐｒｏｃｅｄｕｒｅ）、或いはｉｉｉ）ネットワークトリガーされたサービス要請手順（Ｎｅｔｗｏｒｋ ｔｒｉｇｇｅｒｅｄ Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ ｐｒｏｃｅｄｕｒｅ）を行うまで待つ。その後、ＵＥ−Ａはトラッキング領域アップデート手順又はサービス要請手順を行う。

図１８の段階１３ａで、図１８の段階１２ａでＵＥ−Ａのセル情報を取得したＭＭＥは、ＵＥ−Ａの最新位置情報を含むＬｏｃａｔｉｏｎ ＮｏｔｉｆｉｃａｔｉｏｎメッセージをＨＳＳ−Ａに送信する。

図１８の段階１４ａで、ＨＳＳ−Ａは、ＵＥ−Ａの最新位置情報を含むＬｏｃａｔｉｏｎ ＮｏｔｉｆｉｃａｔｉｏｎメッセージをＰｒｏＳｅサーバー−Ａに送信する。

図１８の段階１５ａで、ＰｒｏＳｅサーバー−ＡはＨＳＳ−ＡにＬｏｃａｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎ Ａｃｋメッセージを応答する。

図１８の段階１６ａで、ＨＳＳ−ＡはＭＭＥにＬｏｃａｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎ Ａｃｋメッセージを応答する。

図１８の段階１７ａで、ＰｒｏＳｅサーバー−Ａは、ＵＥ−Ａの現在位置情報を提供するために、ＰｒｏＳｅ Ｌｏｃａｔｉｏｎ ＮｏｔｉｆｉｃａｔｉｏｎメッセージをＰｒｏＳｅサーバー−Ｂに送信する。

図１８の段階１８ａで、ＰｒｏＳｅサーバー−ＢはＰｒｏＳｅ Ｌｏｃａｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎ ＡｃｋメッセージをＰｒｏＳｅサーバー−Ａに回答する。

図１８の段階１９ａで、段階１２ａ以降に、仮にＵＥ−Ａが段階１２ａによって接続モードに変更されると、ＭＭＥはｅＮｏｄｅＢに、段階１０ｂで記述したように、ＵＥ−ＡがそのサービングセルをｅＮｏｄｅＢに属した他のセルへと変更する都度、ＵＥ−Ａの現在位置を報告することを指示するように位置報告制御を行う。

図１８の段階２０ａで、仮に段階１９ａでＭＭＥがｅＮｏｄｅＢに対して位置報告制御を行うと、ｅＮｏｄｅＢは、ＵＥ−ＡがそのサービングセルをｅＮｏｄｅＢに属した他のセルへと変更する都度、Ｌｏｃａｔｉｏｎ ＲｅｐｏｒｔメッセージをＭＭＥに送信する。更新された位置情報は、ＭＭＥからＰｒｏＳｅサーバー−Ａに、図１８の段階１３ａ乃至１６ａに示したように、ＨＳＳ−Ａを介して伝達される。仮に、ＰｒｏＳｅサーバー−Ａが更新された位置情報を受信すると、段階１７ａ乃至１８ａに示したように、その情報をＰｒｏＳｅサーバー−Ｂにフォワードする。

以下、図１８の段階５ｂ〜１６ｂがＵＥ−Ｂの位置情報の取得のために行われる。

図１８の段階５ｂで、ＰｒｏＳｅサーバー−ＢはＵＥ−Ｂに対してＴｉｍｅ＿Ｘの値でタイマーを起動する。

図１８の段階６ｂで、ＰｒｏＳｅサーバー−ＢはＨＳＳ−ＢにＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｒｅｑｕｅｓｔメッセージを送信することによって、ＵＥ−Ｂと関連した位置報告を開始することをＨＳＳ−Ｂに要請する。

図１８の段階７ｂで、ＭＭＥにＵＥ−Ｂと関連した位置報告を開始させるために、ＨＳＳ−ＢはＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ ＲｅｑｕｅｓｔメッセージをＭＭＥに送信する。

図１８の段階８ｂで、ＭＭＥはＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｒｅｑｕｅｓｔ ＡｃｋメッセージでＨＳＳ−Ｂに応答する。

図１８の段階９ｂで、ＨＳＳ−ＢはＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｒｅｑｕｅｓｔ ＡｃｋメッセージでＰｒｏＳｅサーバー−Ｂに応答する。

図１８の段階１０ｂでＵＥ−Ｂは接続モードであると仮定する。ＭＭＥは、ＵＥ−Ｂに対する最新のセル情報（ｃｅｌｌ ｉｎｆｏｒｍａｔｉｏｎ）を取得するために、ｅＮｏｄｅＢにＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｃｏｎｔｒｏｌメッセージを送信する。なお、ＭＭＥは、ＵＥ−ＢがそのサービングセルをｅＮｏｄｅＢに属した他のセルへと変更する都度、ＵＥ−Ｂの現在位置をｅＮｏｄｅＢが報告することを指示する情報をＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｃｏｎｔｒｏｌメッセージに含めることができる。

図１８の段階１１ｂで、ｅＮｏｄｅＢはＬｏｃａｔｉｏｎ ＲｅｐｏｒｔメッセージをＭＭＥに送信することによって、ＵＥ−Ｂの最新のセル情報を回答する。

図１８の段階１２ｂで、ＭＭＥは、ＵＥ−Ｂの最新の位置情報を含むＬｏｃａｔｉｏｎ ＮｏｔｉｆｉｃａｔｉｏｎメッセージをＨＳＳ−Ｂに送信する。

図１８の段階１３ｂで、ＨＳＳ−Ｂは、ＵＥ−Ｂの最新の位置情報を含むＬｏｃａｔｉｏｎ ＮｏｔｉｆｉｃａｔｉｏｎメッセージをＰｒｏＳｅサーバー−Ｂに送信する。

図１８の段階１４ｂで、ＰｒｏＳｅサーバー−ＢはＬｏｃａｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎ ＡｃｋメッセージでＨＳＳ−Ｂに応答する。

図１８の段階１５ｂで、ＨＳＳ−ＢはＬｏｃａｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎ ＡｃｋメッセージでＭＭＥに応答する。

図１８の段階１６ｂで、段階１１ｂ以降に、ｅＮｏｄｅＢは、ＵＥ−ＢがそのサービングセルをｅＮｏｄｅＢに属した他のセルへと変更する都度、Ｌｏｃａｔｉｏｎ ＲｅｐｏｒｔメッセージをＭＭＥに送信する。更新された位置情報は、ＭＭＥからＰｒｏＳｅサーバー−Ｂに、図１８の段階１２ｂ乃至１３ｂに示したように、ＨＳＳ−Ｂを介して伝達される。

図１８の段階２１で、図１８の段階１７ａで受信されたＰｒｏＳｅ Ｌｏｃａｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージ及び図１８の段階１３ｂで受信したＬｏｃａｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージに基づいて、ＰｒｏＳｅサーバー−Ｂは、ＵＥ−Ａの位置情報及びＵＥ−Ｂの位置情報並びに近接基準（ｐｒｏｘｉｍｉｔｙ ｃｒｉｔｅｒｉａ）によって、ＵＥ−ＡとＵＥ−Ｂとの近接関係を決定する。仮に、ＰｒｏＳｅサーバー−Ｂが、ＵＥ−ＡとＵＥ−Ｂとが近接関係にあると判断する場合には、図１８の段階２２が行われる。そうでないと、ＰｒｏＳｅサーバー−Ｂは、新しいＬｏｃａｔｉｏｎ ＮｏｔｉｆｉｃａｔｉｏｎメッセージがＰｒｏＳｅサーバー−Ａ又はＨＳＳ−Ｂから受信される度ごとに近接関係を確認する。仮に、ＰｒｏＳｅサーバーが、ＵＥ−Ａ及びＵＥ−Ｂが近接関係にあると判断したり、仮に図１８の段階５ａで起動したタイマーと図１８の段階５ｂで起動したタイマーが満了すると、図１８の段階２２が行われる。

図１８の段階２２で、ＰｒｏＳｅサーバー−Ｂは、ＵＥ−ＡとＵＥ−Ｂとが近接しているか否かを示す情報と併せてＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ ＲｅｓｐｏｎｓｅメッセージをＵＥ−Ｂに送信する。仮に、ＵＥ−Ｂ／ユーザ−ＢがＵＥ−Ａ／ユーザ−Ａを探索する権限がない場合には、ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ Ｒｅｓｐｏｎｓｅメッセージは、ＵＥ−ＢからのＰｒｏＳｅ探索要請が拒絶されたことを示す。

図１８の段階２３で、仮にＵＥ−ＡとＵＥ−Ｂとが近接していると、ＰｒｏＳｅサーバー−ＢはＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ ＡｌｅｒｔメッセージをＵＥ−Ａに送信し、ＵＥ−ＢがＵＥ−Ａを探索することを希望していることを知らせることもできる。

また、ＵＥ−ＡとＵＥ−Ｂとが相互発見しようと試みてもよい。

図１８の段階２４で、ＰｒｏＳｅサーバー−Ｂは、ＵＥ−Ａに関連した位置報告を中断することをＰｒｏＳｅサーバー−Ａに要請する。この位置報告取消は、ＨＳＳ−Ａを介してＭＭＥ及び必要な場合にはｅＮｏｄｅＢに適用することができる。

図１８の段階２５で、ＰｒｏＳｅサーバー−Ｂは、ＵＥ−Ｂに関連した位置報告を中断することをＨＳＳ−Ｂに要請する。この位置報告取消は、ＭＭＥ及び必要な場合にはｅＮｏｄｅＢに適用することができる。

なお、ＵＥ−Ａの位置情報を取得するための段階（すなわち、段階５ａ〜２０ａ）及びＵＥ−Ｂの位置情報を取得するための段階（すなわち、段階５ｂ〜１６ｂ）は並列的に行われてもよい。

また、ＰｒｏＳｅサーバー−Ｂは、ＵＥ−Ａ及びＵＥ−Ｂに対してそれぞれ別個のタイマーを起動する代わりに、ＵＥ−Ａ及びＵＥ−Ｂ両方のためのＴｉｍｅ＿Ｘを有する単一タイマーを起動することもできる。

仮に、ＵＥ−Ａが接続状態である場合、接続状態の位置情報を取得するための図１８の段階１０ｂ〜１６ｂが、図１８の段階１２ａ〜１６ａ及び段階１９ａ〜２０ａの代わりに行われてもよい。また、仮にＵＥ−Ｂが遊休状態である場合には、遊休状態の位置情報を取得するための図１８の段階１２ａ〜１６ａ及び段階１９ａ〜２０ａが、図１８の段階１０ｂ〜１６ｂの代わりに行われてもよい。

図１８で、説明の便宜のために、ＵＥ−Ａ及びＵＥ−Ｂは同一ｅＮｏｄｅＢ及び同一ＭＭＥによってサービスされる場合を説明したが、以上で説明した実施例は、異なるｅＮｏｄｅＢ及び同一ＭＭＥによってサービスされたり、同一ｅＮｏｄｅＢ及び異なるＭＭＥによってサービスされたり、異なるｅＮｏｄｅＢ及び異なるＭＭＥによってサービスされる場合にも適用することができる。

３−９． 第１５実施例

以下では、互いに異なるＰＬＭＮ内で行われるＥＰＣ−レベルＰｒｏＳｅ探索について説明する。

仮にＰｒｏＳｅサーバーが探索者（ｄｉｓｃｏｖｅｒｅｒ）からＰｒｏＳｅ探索のための要請を受信すると、被探索者（ｄｉｓｃｏｖｅｒｅｅ）がＰｒｏＳｅサーバーに登録されているか否かを確認する。仮に、被探索者がＰｒｏＳｅサーバーに登録されない場合には、ＰｒｏＳｅサーバーは、ＰｒｏＳｅサーバーが存在し、探索者が登録されたＰＬＭＮではなく他のＰＬＭＮに被探索者が登録されたと判断する。

したがって、ＰｒｏＳｅサーバーが、探索者と被探索者間の近接関係を判断するために、ネットワーク共有情報（ｎｅｔｗｏｒｋ ｓｈａｒｉｎｇ ｉｎｆｏｒｍａｔｉｏｎ）をチェックし、他のネットワークノードに位置要請をする時、他のネットワークノードにＵＥの位置情報と併せてネットワーク共有情報を提供することを指示する。

仮に端末（探索者或いは被探索者）をサービスするｅＮｏｄｅＢが共有ＲＡＮ（Ｓｈａｒｅｄ ＲＡＮ）である場合には、ＭＭＥはネットワーク共有情報と併せて端末の位置情報を提供する。ネットワーク共有情報は、端末をサービスするｅＮｏｄｅＢによってブロードキャストされたＰＬＭＮの識別子リストであってもよい。

図１９は、この実施例によって異なるＰＬＭＮ内で行うＥＰＣ−レベルＰｒｏＳｅ探索を示す参考図である。ここで、探索者と被探索者はノン−ローミングであると仮定する。

ＵＥ−Ａは、図１９に示すように、時間区間内にＵＥ−Ｂと近接関係が成立する場合、これを知るために、ネットワークに時間区間（ｔｉｍｅ ｗｉｎｄｏｗ）と共にＰｒｏＳｅ探索を要請する。以下では、ＵＥ−Ａ（探索者）とＵＥ−Ｂ（被探索者）は異なるＰＬＭＮ、すなわち、ＵＥ−ＡとＵＥ−ＢはそれぞれＰＬＭＮ−ＡとＰＬＭＮ−Ｂに登録された場合を仮定する。ここで、ＵＥ−Ａ及びＵＥ−Ｂはノン−ローミングである場合を仮定し、図１９で、ＭＭＥ−Ａ、ＨＳＳ−Ａ及びＰｒｏＳｅサーバー−ＡはＰＬＭＮ−Ａに属し、ＭＭＥ−Ｂ、ＨＳＳ−Ｂ及びＰｒｏＳｅサーバー−ＢはＰＬＭＮ−Ｂに属する。

まず、ＵＥ−ＡはＰｒｏＳｅサーバー−Ａに登録されており、ＵＥ−ＢはＰｒｏＳｅサーバー−Ｂに登録されている。

図１９の段階１で、ＵＥ−ＡはＰｒｏＳｅサーバー−Ａに、時間区間内でＵＥ−Ｂと近接関係が成立する場合、これを知るために、ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ Ｒｅｑｕｅｓｔメッセージを送信する。この時、ＵＥ−Ａは、ＰｒｏＳｅサーバーにどれくらいの時間区間まで要請が有効であるかを示す時間区間情報（すなわち、図１９のＴｉｍｅ＿Ｘ）を、ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ Ｒｅｑｕｅｓｔメッセージに含めることができる。ここで、ＵＥ−Ａ及びＵＥ−Ｂは、それぞれ、ＰｒｏＳｅ−可能ＵＥ−Ａ上のアプリケーション及びＰｒｏＳｅ−可能ＵＥ−Ｂ上のアプリケーションを実質的に意味することができる。

図１９の段階２で、ＰｒｏＳｅサーバー−Ａは、ＵＥ−Ａから送信されたＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ ｒｅｑｕｅｓｔを認証し、ＵＥ−ＢのＨｏｍｅ ＰｒｏＳｅサーバーであるＰｒｏＳｅサーバー−ＢにＰｒｏＳｅ Ｐｅｒｍｉｓｓｉｏｎ Ｃｈｅｃｋ Ｒｅｑｕｅｓｔメッセージを送信することによって、ＵＥ−Ａ／ユーザ−ＡがＵＥ−Ｂ／ユーザ−Ｂを探索することが許容されるか否かをＰｒｏＳｅサーバー−Ｂが確認することを要請する。

図１９の段階３で、ＰｒｏＳｅサーバー−Ｂは、ＵＥ−Ａ／ユーザ−ＡがＵＥ−Ｂ／ユーザ−Ｂを探索することが許容されるか否かを確認する。

図１９の段階４で、ＰｒｏＳｅサーバー−Ｂは、ＰｒｏＳｅ Ｐｅｒｍｉｓｓｉｏｎ Ｃｈｅｃｋ Ｒｅｓｐｏｎｓｅメッセージを、ＵＥ−Ａ／ユーザ−ＡがＵＥ−Ｂ／ユーザ−Ｂを探索することが許容（ｐｅｒｍｉｔ）されるか否かを示す情報と併せてＰｒｏＳｅサーバー−Ａに送信する。仮にＵＥ−Ａ／ユーザ−ＡがＵＥ−Ｂ／ユーザ−Ｂを探索することが許容されない場合、図１９の段階２２が行われる。

以下、図１９の段階５ａ〜１６ａがＵＥ−Ａの位置情報の取得のために行われる。

図１９の段階５ａで、ＰｒｏＳｅサーバー−ＡはＵＥ−Ａに対してＴｉｍｅ＿Ｘの値でタイマーを起動する。

図１９の段階６ａで、ＰｒｏＳｅサーバー−ＡはＨＳＳ−ＡにＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｒｅｑｕｅｓｔメッセージを送信し、ＨＳＳ−ＡがＵＥ−Ａに関する位置報告を開始することを要請する。これは、被探索者、ＵＥ−ＢがＰｒｏＳｅサーバー−Ａに登録されておらず、ＰｒｏＳｅサーバー−ＡはＵＥ−Ｂとの近接関係を確認するためにネットワーク共有情報が必要であると判断するためである。したがって、ＰｒｏＳｅサーバー−Ａは、ネットワーク共有情報と併せてＵＥ−Ａの位置情報をＨＳＳ−ＡがＰｒｏＳｅサーバー−Ａに提供することを指示する情報を、Ｌｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｒｅｑｕｅｓｔメッセージに含めることができる。ここで、上記ネットワーク共有情報を提供することを示す情報は、ネットワーク共有情報を提供することを示す情報の他、様々な形態の情報（例えば、ｄｉｓｃｏｖｅｒｅｒ ＵＥとｄｉｓｃｏｖｅｒｅｅ ＵＥが異なるＰＬＭＮに登録／位置することを示す情報）であってもよい。すなわち、明示的な形態又は含蓄的な形態の指示情報であってもよく、複数の情報が組み合わされた形態でＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｒｅｑｕｅｓｔメッセージに含まれてもよい。これは、段階図１９の段階７ａでＨＳＳ−ＡがＭＭＥ−ＡにＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｒｅｑｕｅｓｔメッセージを送る時にも同一に適用することができる。

図１９の段階７ａで、ＨＳＳ−Ａは、ＭＭＥ−ＡにＵＥ−Ａに関する位置報告を開始させるために、Ｌｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ ＲｅｑｕｅｓｔメッセージをＭＭＥ−Ａに送信する。

図１９の段階８ａで、ＭＭＥ−ＡはＨＳＳ−ＡにＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｒｅｑｕｅｓｔ Ａｃｋメッセージで応答する。

図１９の段階９ａで、ＨＳＳ−ＡはＰｒｏＳｅサーバー−ＡにＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｒｅｑｕｅｓｔ Ａｃｋメッセージで応答する。

図１９の段階１０ａで、ＵＥ−Ａは接続モードであると仮定する。ＭＭＥ−Ａは、ＵＥ−Ａに対する最新のセル情報（ｃｅｌｌ ｉｎｆｏｒｍａｔｉｏｎ）を取得するために、ｅＮｏｄｅＢにＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｃｏｎｔｒｏｌメッセージを送信する。なお、ＭＭＥ−Ａは、ＵＥ−ＡがそのサービングセルをｅＮｏｄｅＢに属した他のセルへと変更する都度、ＵＥ−Ａの現在位置をｅＮｏｄｅＢが報告することを指示する情報をＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｃｏｎｔｒｏｌメッセージに含めることができる。

図１９の段階１１ａで、ｅＮｏｄｅＢはＬｏｃａｔｉｏｎ ＲｅｐｏｒｔメッセージをＭＭＥ−Ａに送信することによって、ＵＥ−Ａの最新のセル情報を回答する。

図１９の段階１２ａで、ＭＭＥ−Ａは、ＵＥ−Ａの最新の位置情報を含むＬｏｃａｔｉｏｎ ＮｏｔｉｆｉｃａｔｉｏｎメッセージをＨＳＳ−Ａに送信する。仮に、ＵＥ−ＡをサービスするｅＮｏｄｅＢが共有ＲＡＮ（Ｓｈａｒｅｄ ＲＡＮ）である場合、ＭＭＥ−Ａは、ＵＥ−ＡをサービスするｅＮｏｄｅＢ関連ブロードキャストされたＰＬＭＮに関するネットワーク共有情報を、Ｌｏｃａｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージに含めることができる。ここで、ブロードキャストされたＰＬＭＮに関する情報は、ＵＥ−ＡをサービスするｅＮｏｄｅＢによってブロードキャストされたＰＬＭＮの識別子リストであってもよい。

図１９の段階１３ａで、ＨＳＳ−Ａは、ＵＥ−Ａの最新の位置情報、及び仮にブロードキャストされたＰＬＭＮの識別子リストが存在するとそれを含むＬｏｃａｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージを、ＰｒｏＳｅサーバー−Ａに送信する。

図１９の段階１４ａで、ＰｒｏＳｅサーバー−ＡはＬｏｃａｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎ ＡｃｋメッセージでＨＳＳ−Ａに応答する。

図１９の段階１５ａで、ＨＳＳ−Ａは、Ｌｏｃａｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎ ＡｃｋメッセージでＭＭＥ−Ａに応答する。

図１９の段階１６ａで、段階１１ａ以降に、ｅＮｏｄｅＢは、ＵＥ−ＡがそのサービングセルをｅＮｏｄｅＢに属した他のセルへと変更する都度、Ｌｏｃａｔｉｏｎ ＲｅｐｏｒｔメッセージをＭＭＥ−Ａに送信する。更新された位置情報は、ＭＭＥ−ＡからＰｒｏＳｅサーバー−Ａに、図１９の段階１２ａ乃至１５ａに示したようにＨＳＳ−Ａを介して伝達される。

以下、図１９の段階５ｂ〜２０ｂがＵＥ−Ｂの位置情報の取得のために行われる。

図１９の段階５ｂで、ＰｒｏＳｅサーバー−ＡはＵＥ−Ｂに対してＴｉｍｅ＿Ｘの値でタイマーを起動する。

図１９の段階６ｂで、ＰｒｏＳｅサーバー−Ａは、ＵＥ−Ｂの位置情報を要請するために、ＵＥ−ＢのＨｏｍｅ ＰｒｏＳｅサーバーであるＰｒｏＳｅサーバー−Ｂに、ＰｒｏＳｅ Ｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔメッセージを送信する。これは、被探索者、ＵＥ−ＢがＰｒｏＳｅサーバー−Ａに登録されておらず、ＰｒｏＳｅサーバー−ＡはＵＥ−Ｂとの近接関係を確認するためにネットワーク共有情報が必要であると判断するためである。したがって、ＰｒｏＳｅサーバー−Ａは、ネットワーク共有情報と併せてＵＥ−Ｂの位置情報をＰｒｏＳｅサーバー−ＢがＰｒｏＳｅサーバー−Ａに提供することを指示する情報を、ＰｒｏＳｅ Ｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔメッセージに含めることができる。ここで、上記ネットワーク共有情報を提供することを示す情報は、ネットワーク共有情報を提供することを示す情報の他、様々な形態の情報（例えば、ｄｉｓｃｏｖｅｒｅｒ ＵＥとｄｉｓｃｏｖｅｒｅｅ ＵＥが異なるＰＬＭＮに登録／位置することを示す情報）であってもよい。すなわち、明示的な形態又は含蓄的な形態の指示情報であってもよく、複数の情報が組み合わされた形態でＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｒｅｑｕｅｓｔメッセージに含まれてもよい。これは、図１９の段階８ｂでＰｒｏＳｅサーバー−ＢがＨＳＳ−ＢにＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｒｅｑｕｅｓｔメッセージを送る時、そして段階９ｂでＨＳＳ−ＢがＭＭＥ−ＢにＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｒｅｑｕｅｓｔメッセージを送る時にも同一に適用することができる。

図１９の７ｂで、ＰｒｏＳｅサーバー−ＢはＰｒｏＳｅ Ｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔ ＡｃｋメッセージをＰｒｏＳｅサーバー−Ａに回答する。

図１９の段階８ｂで、ＰｒｏＳｅサーバー−ＢはＨＳＳ−ＢにＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｒｅｑｕｅｓｔメッセージを送信することによって、ＵＥ−Ｂと関連した位置報告を開始することをＨＳＳ−Ｂに要請する。ここで、ＰｒｏＳｅサーバー−Ｂは、ネットワーク共有情報と併せてＵＥ−Ｂの位置情報をＨＳＳ−ＢがＰｒｏＳｅ−サーバーＢに提供することを指示する情報を、Ｌｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｒｅｑｕｅｓｔメッセージに含めることができる。

図１９の段階９ｂで、ＨＳＳ−ＢはＭＭＥ−ＢにＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｒｅｑｕｅｓｔメッセージを送信することによって、ＵＥ−Ｂと関連した位置報告を開始することをＭＭＥ−Ｂに要請する。ここで、ＨＳＳ−Ｂは、ネットワーク共有情報と併せてＵＥ−Ｂの位置情報をＭＭＥ−ＢがＨＳＳ−Ｂに提供することを指示する情報を、Ｌｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｒｅｑｕｅｓｔメッセージに含めることができる。

図１９の段階１０ｂで、ＭＭＥ−ＢはＨＳＳ−ＢにＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｒｅｑｕｅｓｔ Ａｃｋメッセージで応答する。

図１９の段階１１ｂで、ＨＳＳ−ＢはＰｒｏＳｅサーバー−ＢにＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｒｅｑｕｅｓｔ Ａｃｋメッセージで応答する。

図１９の段階１２ｂで、ＵＥ−Ｂは遊休状態であると仮定する。ＭＭＥ−Ｂは、ＵＥ−Ｂがｉ）トラッキング領域アップデート手順（ＵＥ−Ａ ｐｅｒｆｏｒｍｓ Ｔｒａｃｋｉｎｇ Ａｒｅａ Ｕｐｄａｔｅ ｐｒｏｃｅｄｕｒｅ）、或いはｉｉ）端末トリガーされたサービス要請手順（ＵＥ ｔｒｉｇｇｅｒｅｄ Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ ｐｒｏｃｅｄｕｒｅ）、或いはｉｉｉ）ネットワークトリガーされたサービス要請手順（Ｎｅｔｗｏｒｋ ｔｒｉｇｇｅｒｅｄ Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ ｐｒｏｃｅｄｕｒｅ）を行うまで待つ。その後、ＵＥ−Ｂはトラッキング領域アップデート手順又はサービス要請手順を行う。

図１９の段階１３ｂで、図１９の段階１２ｂでＵＥ−Ｂのセル情報を取得したＭＭＥ−Ｂは、ＵＥ−Ｂの最新位置情報を含むＬｏｃａｔｉｏｎ ＮｏｔｉｆｉｃａｔｉｏｎメッセージをＨＳＳ−Ｂに送信する。仮にＵＥ−ＢをサービスするｅＮｏｄｅＢが共有ＲＡＮ（Ｓｈａｒｅｄ ＲＡＮ）である場合、ＭＭＥ−Ｂは、ＵＥ−ＢをサービスするｅＮｏｄｅＢ関連ブロードキャストされたＰＬＭＮに関するネットワーク共有情報を、Ｌｏｃａｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージに含めることができる。ここで、ブロードキャストされたＰＬＭＮに関する情報は、ＵＥ−ＢをサービスするｅＮｏｄｅＢによってブロードキャストされたＰＬＭＮの識別子リストであってもよい。

図１９の段階１４ｂで、ＨＳＳ−ＢはＵＥ−Ｂの最新の位置情報、及び仮にブロードキャストされたＰＬＭＮの識別子リストが存在するとそれを含むＬｏｃａｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージを、ＰｒｏＳｅサーバー−Ｂに送信する。

図１９の段階１５ｂで、ＰｒｏＳｅサーバー−ＢはＨＳＳ−ＢにＬｏｃａｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎ Ａｃｋメッセージを応答する。

図１９の段階１６ｂで、ＨＳＳ−ＢはＭＭＥ−ＢにＬｏｃａｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎ Ａｃｋメッセージを応答する。

図１９の段階１７ｂで、ＰｒｏＳｅサーバー−Ｂは、ＵＥ−Ｂの最近の位置情報、及び仮にブロードキャストされたＰＬＭＮの識別子リストが存在するとそれを提供するために、ＰｒｏＳｅ Ｌｏｃａｔｉｏｎ ＮｏｔｉｆｉｃａｔｉｏｎメッセージをＰｒｏＳｅサーバー−Ａに送信する。

図１８の段階１８ｂで、ＰｒｏＳｅサーバー−ＡはＰｒｏＳｅ Ｌｏｃａｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎ ＡｃｋメッセージをＰｒｏＳｅサーバー−Ｂに応答する。

図１９の段階１９ｂで、段階１２ｂ以降に、仮にＵＥ−Ｂが段階１２ｂによって接続モードに変更されると、ＭＭＥ−ＢはｅＮｏｄｅＢに、段階１０ａで記述したように、ＵＥ−ＢがそのサービングセルをｅＮｏｄｅＢに属した他のセルへと変更する都度、ＵＥ−Ｂの現在位置を報告することを指示するように位置報告制御を行う。

図１９の段階２０ｂで、仮に段階１９ｂでＭＭＥ−ＢがｅＮｏｄｅＢに対して位置報告制御を行うと、ｅＮｏｄｅＢは、ＵＥ−ＢがそのサービングセルをｅＮｏｄｅＢに属した他のセルへと変更する都度、Ｌｏｃａｔｉｏｎ ＲｅｐｏｒｔメッセージをＭＭＥ−Ｂに送信する。更新された位置情報は、ＭＭＥ−ＢからＰｒｏＳｅサーバー−Ｂに、図１９の段階１３ｂ乃至１６ｂに示したように、ＨＳＳ−Ｂを介して伝達される。仮に、ＰｒｏＳｅサーバー−Ｂが更新された位置情報を受信すると、段階１７ｂ乃至１８ｂに示すように、その情報をＰｒｏＳｅサーバー−Ａにフォワードする。

図１９の段階２１で、図１９の段階１３ａで受信したＬｏｃａｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージ及び図１９の段階１７ｂで受信されたＰｒｏＳｅ Ｌｏｃａｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージに基づいて、ＰｒｏＳｅサーバー−Ａは、ＵＥ−Ａの位置情報及びＵＥ−Ｂの位置情報及びブロードキャストされたＰＬＭＮのネットワーク共有情報並びに近接基準（ｐｒｏｘｉｍｉｔｙ ｃｒｉｔｅｒｉａ）によって、ＵＥ−ＡとＵＥ−Ｂとの近接関係を決定する。仮に、ＰｒｏＳｅサーバー−ＡがＵＥ−ＡとＵＥ−Ｂとが近接関係にあると判断する場合には、図１９の段階２２が行われる。そうでないと、ＰｒｏＳｅサーバー−Ａは、新しいＬｏｃａｔｉｏｎ ＮｏｔｉｆｉｃａｔｉｏｎメッセージがＰｒｏＳｅサーバー−Ｂ又はＨＳＳ−Ａから受信される度ごとに近接関係を確認する。仮に、ＰｒｏＳｅサーバー−Ａが、ＵＥ−Ａ及びＵＥ−Ｂが近接関係にあると判断したり、仮に図１９の段階５ａで起動したタイマーと図１９の段階５ｂで起動したタイマーが満了すると、図１９の段階２２が行われる。

図１９の段階２２で、ＰｒｏＳｅサーバー−Ａは、ＵＥ−ＡとＵＥ−Ｂとが近接しているか否かを示す情報と併せてＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ Ｒｅｓｐｏｎｓｅメッセージを、ＵＥ−Ａに送信する。仮にＵＥ−Ａ／ユーザ−ＡがＵＥ−Ｂ／ユーザ−Ｂを探索する権限がない場合には、ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ Ｒｅｓｐｏｎｓｅメッセージは、ＵＥ−ＡからのＰｒｏＳｅ探索要請が拒絶されたことを示す。

図１９の段階２３乃至段階２５で、仮にＵＥ−ＢとＵＥ−Ａとが近接（ｐｒｏｘｉｍｉｔｙ）する場合には、ＰｒｏＳｅサーバー−ＡはＰｒｏＳｅサーバー−ＢにＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ ＡｌｅｒｔメッセージをＵＥ−Ｂに送信し、ＵＥ−ＡがＵＥ−Ｂを探索することを希望していることを知らせるように要請することもできる。

また、ＵＥ−ＡとＵＥ−Ｂとが相互発見しようと試みてもよい。

図１９の段階２６で、ＰｒｏＳｅサーバー−Ａは、ＵＥ−Ａに関連した位置報告を中断することをＨＳＳ−Ａに要請する。この位置報告取消は、ＭＭＥ−Ａ及び必要な場合にはｅＮｏｄｅＢに適用することができる。

図１９の段階２７で、ＰｒｏＳｅサーバー−ＡはＵＥ−Ｂに関連した位置報告を中断することをＰｒｏＳｅサーバー−Ｂに要請する。この位置報告取消は、ＨＳＳ−Ｂを介して、ＭＭＥ−Ｂ及び必要な場合にはｅＮｏｄｅＢに適用することができる。

なお、ＵＥ−Ａの位置情報を取得するための段階（すなわち、段階５ａ〜１６ａ）及びＵＥ−Ａの位置情報を取得するための段階（すなわち、段階５ｂ〜２０ｂ）は並列的に行われてもよい。

また、ＰｒｏＳｅサーバー−Ａは、ＵＥ−Ａ及びＵＥ−Ｂに対してそれぞれ別個のタイマーを起動する代わりに、ＵＥ−Ａ及びＵＥ−Ｂ両方のためのＴｉｍｅ＿Ｘを有する単一タイマーを起動することもできる。

仮にＵＥ−Ａが遊休状態である場合、遊休状態の位置情報を取得するための図１９の段階１２ｂ〜１６ｂ及び１９ｂ〜２０ｂが、図１９の段階１０ａ〜１６ａの代わりに行われてもよい。また、仮にＵＥ−Ｂが接続状態である場合には、接続状態の位置情報を取得するための図１９の段階１０ａ〜１６ａが、図１９の段階１２ｂ〜１６ｂ及び段階１９ｂ〜２０ｂの代わりに行われてもよい。

図１９に開示した手順は、ＵＥ−ＢとＵＥ−Ａが同一ｅＮｏｄｅＢ及び同一ＭＭＥによってサービスされる場合にも適用することができ、異なるｅＮｏｄｅＢ及び同一ＭＭＥによってサービスされたり、異なるｅＮｏｄｅＢ及び異なるＭＭＥによってサービスされる場合にも適用することができる。

３−１０． 第１６実施例

以下、Ｉｎｔｅｒ−ＰＬＭＮ ＥＰＣ−レベルＰｒｏＳｅ探索について説明する。図２０で、探索者と被探索者はノン−ローミングであると仮定する。

ＵＥ−Ａは、図２０に示すように、時間区間（ｔｉｍｅ ｗｉｎｄｏｗ）内にＵＥ−Ｂと近接関係が成立する場合、これを知るために、ネットワークに時間区間（ｔｉｍｅ ｗｉｎｄｏｗ）と共にＰｒｏＳｅ探索を要請する。以下では、ＵＥ−Ａ（探索者）とＵＥ−Ｂ（被探索者）は異なるＰＬＭＮ、すなわち、ＵＥ−ＡとＵＥ−ＢはそれぞれＰＬＭＮ−ＡとＰＬＭＮ−Ｂに登録された場合を仮定する。ここで、ＵＥ−ＡとＵＥ−Ｂはノン−ローミングである場合を仮定し、図２０で、ＭＭＥ−Ａ、ＨＳＳ−Ａ及びＰｒｏＳｅサーバー−ＡはＰＬＭＮ−Ａに属し、ＭＭＥ−Ｂ、ＨＳＳ−Ｂ及びＰｒｏＳｅサーバー−ＢはＰＬＭＮ−Ｂに属する。

まず、ＵＥ−ＡはＰｒｏＳｅサーバー−Ａに登録されており、ＵＥ−ＢはＰｒｏＳｅサーバー−Ｂに登録されている。

図２０の段階１で、ＵＥ−ＡはＰｒｏＳｅサーバー−Ａに、時間区間内でＵＥ−Ｂと近接関係が成立する場合、これを知るために、ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ Ｒｅｑｕｅｓｔメッセージを送信する。この時、ＵＥ−Ａは、ＰｒｏＳｅサーバーにどれくらいの時間区間まで要請が有効であるかを示す時間区間情報（すなわち、図２０のＴｉｍｅ＿Ｘ）を、ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ Ｒｅｑｕｅｓｔメッセージに含めることができる。ここで、ＵＥ−Ａ及びＵＥ−Ｂは、それぞれ、ＰｒｏＳｅ−可能ＵＥ−Ａ上のアプリケーション及びＰｒｏＳｅ−可能ＵＥ−Ｂ上のアプリケーションを実質的に意味することができる。

図２０の段階２で、ＰｒｏＳｅサーバー−Ａは、ＵＥ−Ａから送信されたＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ ｒｅｑｕｅｓｔを認証し、ＵＥ−ＢのＨｏｍｅ ＰｒｏＳｅサーバーであるＰｒｏＳｅサーバー−ＢにＰｒｏＳｅ Ｐｅｒｍｉｓｓｉｏｎ Ｃｈｅｃｋ Ｒｅｑｕｅｓｔメッセージを送信することによって、ＵＥ−Ａ／ユーザ−ＡがＵＥ−Ｂ／ユーザ−Ｂを探索することが許容されるか否かをＰｒｏＳｅサーバー−Ｂが確認することを要請する。

図２０の段階３で、ＰｒｏＳｅサーバー−Ｂは、ＵＥ−Ａ／ユーザ−ＡがＵＥ−Ｂ／ユーザ−Ｂを探索することが許容されるか否かを確認する。

図２０の段階４で、ＰｒｏＳｅサーバー−Ｂは、ＰｒｏＳｅ Ｐｅｒｍｉｓｓｉｏｎ Ｃｈｅｃｋ ＲｅｓｐｏｎｓｅメッセージをＵＥ−Ａ／ユーザ−ＡがＵＥ−Ｂ／ユーザ−Ｂを探索することが許容（ｐｅｒｍｉｔ）されるか否かを示す情報と併せてＰｒｏＳｅサーバー−Ａに回答する。仮にＵＥ−Ａ／ユーザ−ＡがＵＥ−Ｂ／ユーザ−Ｂを探索することが許容されない場合、図２０の段階２２が行われる。

以下、図２０の段階５ａ〜１６ａがＵＥ−Ａの位置情報の取得のために行われる。

図２０の段階５ａで、ＰｒｏＳｅサーバー−ＡはＵＥ−Ａに対してＴｉｍｅ＿Ｘの値でタイマーを起動する。

図２０の段階６ａで、ＰｒｏＳｅサーバー−ＡはＨＳＳ−ＡにＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｒｅｑｕｅｓｔメッセージを送信し、ＨＳＳ−ＡがＵＥ−Ａに関する位置報告を開始することを要請する。

図２０の段階７ａで、ＨＳＳ−Ａは、ＭＭＥ−ＡにＵＥ−Ａに関する位置報告を開始させるために、Ｌｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ ＲｅｑｕｅｓｔメッセージをＭＭＥ−Ａに送信する。

図２０の段階８ａで、ＭＭＥ−ＡはＨＳＳ−ＡにＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｒｅｑｕｅｓｔ Ａｃｋメッセージで応答する。

図２０の段階９ａで、ＨＳＳ−ＡはＰｒｏＳｅサーバー−ＡにＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｒｅｑｕｅｓｔ Ａｃｋメッセージで応答する。

図２０の段階１０ａでＵＥ−Ａは接続モードであると仮定する。ＭＭＥ−Ａは、ＵＥ−Ａに対する最新のセル情報（ｃｅｌｌ ｉｎｆｏｒｍａｔｉｏｎ）を取得するために、ｅＮｏｄｅＢにＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｃｏｎｔｒｏｌメッセージを送信する。なお、ＭＭＥ−Ａは、ＵＥ−ＡがそのサービングセルをｅＮｏｄｅＢに属した他のセルへと変更する都度、ＵＥ−Ａの現在位置をｅＮｏｄｅＢが報告することを指示する情報をＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｃｏｎｔｒｏｌメッセージに含めることができる。

図２０の段階１１ａで、ｅＮｏｄｅＢはＬｏｃａｔｉｏｎ ＲｅｐｏｒｔメッセージをＭＭＥ−Ａに送信することによって、ＵＥ−Ａの最新のセル情報を回答する。

図２０の段階１２ａで、ＭＭＥ−Ａは、ＵＥ−Ａの最新の位置情報を含むＬｏｃａｔｉｏｎ ＮｏｔｉｆｉｃａｔｉｏｎメッセージをＨＳＳ−Ａに送信する。

図２０の段階１３ａで、ＨＳＳ−Ａは、ＵＥ−Ａの最新の位置情報を含むＬｏｃａｔｉｏｎ ＮｏｔｉｆｉｃａｔｉｏｎメッセージをＰｒｏＳｅサーバー−Ａに送信する。

図２０の段階１４ａで、ＰｒｏＳｅサーバー−ＡはＬｏｃａｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎ ＡｃｋメッセージでＨＳＳ−Ａに応答する。

図２０の段階１５ａで、ＨＳＳ−Ａは、Ｌｏｃａｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎ ＡｃｋメッセージでＭＭＥ−Ａに応答する。

図２０の段階１６ａで、段階１１ａ以降に、ｅＮｏｄｅＢは、ＵＥ−ＡがそのサービングセルをｅＮｏｄｅＢに属した他のセルへと変更する都度、Ｌｏｃａｔｉｏｎ ＲｅｐｏｒｔメッセージをＭＭＥ−Ａに送信する。更新された位置情報は、ＭＭＥ−ＡからＰｒｏＳｅサーバー−Ａに、図２０の段階１２ａ乃至１５ａに示したようにＨＳＳ−Ａを介して伝達される。

以下、図２０の段階５ｂ〜２０ｂがＵＥ−Ｂの位置情報の取得のために行われる。

図２０の段階５ｂで、ＰｒｏＳｅサーバー−ＡはＵＥ−Ｂに対してＴｉｍｅ＿Ｘの値でタイマーを起動する。

図２０の段階６ｂで、ＰｒｏＳｅサーバー−Ａは、ＵＥ−Ｂの位置情報を要請するために、ＵＥ−ＢのＨｏｍｅ ＰｒｏＳｅサーバーであるＰｒｏＳｅサーバー−Ｂに、ＰｒｏＳｅ Ｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔメッセージを送信する。これは、被探索者、ＵＥ−ＢがＰｒｏＳｅサーバー−Ａに登録されておらず、ＰｒｏＳｅサーバー−ＡはＵＥ−Ｂとの近接関係を確認するためにネットワーク共有情報が必要であると判断するためである。したがって、ＰｒｏＳｅサーバー−Ａは、ＵＥ−Ｂの位置情報のような座標（ｃｏ−ｏｒｄｉｎａｔｅｓ）関連情報と併せてＵＥ−Ｂの位置情報をＰｒｏＳｅサーバー−ＢがＰｒｏＳｅサーバー−Ａに提供することを指示する情報を、ＰｒｏＳｅ Ｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔメッセージに含めることができる。

ここで、上記ＵＥ−Ｂの位置情報として座標関連情報（ｃｏ−ｏｒｄｉｎａｔｅｓ ｒｅｌａｔｅｄ ｉｎｆｏｒｍａｔｉｏｎ）を提供することを示す情報は、座標関連情報を提供することを示す情報の他、様々な形態の情報（例えば、ｄｉｓｃｏｖｅｒｅｒ ＵＥとｄｉｓｃｏｖｅｒｅｅ ＵＥとが異なるＰＬＭＮに登録／位置することを示す情報）であってもよい。すなわち、明示的な形態又は含蓄的な形態の指示（ｉｎｄｉｃａｔｉｏｎ）情報であってもよく、複数の情報が組み合わされた形態でＰｒｏＳｅ Ｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔメッセージに含まれてもよい。

図２０の７ｂで、ＰｒｏＳｅサーバー−ＢはＰｒｏＳｅ Ｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔ ＡｃｋメッセージをＰｒｏＳｅサーバー−Ａに回答する。

図２０の段階８ｂで、ＰｒｏＳｅサーバー−ＢはＨＳＳ−ＢにＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｒｅｑｕｅｓｔメッセージを送信することによって、ＵＥ−Ｂと関連した位置報告を開始することをＨＳＳ−Ｂに要請する。

図２０の段階９ｂで、ＨＳＳ−ＢはＭＭＥ−ＢにＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｒｅｑｕｅｓｔメッセージを送信することによって、ＵＥ−Ｂと関連した位置報告を開始することをＭＭＥ−Ｂに要請する。

図２０の段階１０ｂで、ＭＭＥ−ＢはＨＳＳ−ＢにＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｒｅｑｕｅｓｔ Ａｃｋメッセージで応答する。

図２０の段階１１ｂで、ＨＳＳ−ＢはＰｒｏＳｅサーバー−ＢにＬｏｃａｔｉｏｎ Ｒｅｐｏｒｔｉｎｇ Ｒｅｑｕｅｓｔ Ａｃｋメッセージで応答する。

図２０の段階１２ｂで、ＵＥ−Ｂは遊休状態であると仮定する。ＭＭＥ−Ｂは、ＵＥ−Ｂがｉ）トラッキング領域アップデート手順（ＵＥ−Ａ ｐｅｒｆｏｒｍｓ Ｔｒａｃｋｉｎｇ Ａｒｅａ Ｕｐｄａｔｅ ｐｒｏｃｅｄｕｒｅ）、或いはｉｉ）端末トリガーされたサービス要請手順（ＵＥ ｔｒｉｇｇｅｒｅｄ Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ ｐｒｏｃｅｄｕｒｅ）、或いはｉｉｉ）ネットワークトリガーされたサービス要請手順（Ｎｅｔｗｏｒｋ ｔｒｉｇｇｅｒｅｄ Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ ｐｒｏｃｅｄｕｒｅ）を行うまで待つ。その後、ＵＥ−Ｂはトラッキング領域アップデート手順又はサービス要請手順を行う。

図２０の段階１３ｂで、図２０の段階１２ｂでＵＥ−Ｂのセル情報を取得したＭＭＥ−Ｂは、ＵＥ−Ｂの最新位置情報を含むＬｏｃａｔｉｏｎ ＮｏｔｉｆｉｃａｔｉｏｎメッセージをＨＳＳ−Ｂに送信する。

図２０の段階１４ｂで、ＨＳＳ−Ｂは、ＵＥ−Ｂの最新の位置情報を含むＬｏｃａｔｉｏｎ ＮｏｔｉｆｉｃａｔｉｏｎメッセージをＰｒｏＳｅサーバー−Ｂに送信する。

図２０の段階１５ｂで、ＰｒｏＳｅサーバー−ＢはＨＳＳ−ＢにＬｏｃａｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎ Ａｃｋメッセージを応答する。

図２０の段階１６ｂで、ＨＳＳ−ＢはＭＭＥ−ＢにＬｏｃａｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎ Ａｃｋメッセージを応答する。

図２０の段階１７ｂで、ＰｒｏＳｅサーバー−Ｂは、ＵＥ−Ｂの現在位置情報を提供するために、ＰｒｏＳｅ Ｌｏｃａｔｉｏｎ ＮｏｔｉｆｉｃａｔｉｏｎメッセージをＰｒｏＳｅサーバー−Ａに送信する。

仮に図２０の段階６ｂで受信したＰｒｏＳｅ Ｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔメッセージに座標関連情報を提供することを示す情報が含まれていると、ＰｒｏＳｅサーバー−Ｂは、上記段階１４ｂで受信したＬｏｃａｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージに含まれたＵＥ−Ｂの現在位置情報に基づいて抽出／類推／決定した座標（ｃｏ−ｏｒｄｉｎａｔｅｓ）情報を、上記ＰｒｏＳｅサーバー−Ａに送るＰｒｏＳｅ Ｌｏｃａｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージに含める。この時、ＵＥ−Ｂのセル情報（すなわち、ＥＣＧＩ情報）は含めても含めなくてもよい。

また、仮に図２０の段階６ｂで受信したＰｒｏＳｅ Ｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔメッセージに座標関連情報を提供することを示す情報が含まれていなくとも、ＵＥ−ＢがＰｒｏＳｅサーバー−Ｂに登録されていないと、ＰｒｏＳｅサーバー−Ｂは、図２０の段階１４ｂで受信したＬｏｃａｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージに含まれたＵＥ−Ｂの現在位置情報に基づいて抽出／類推／決定した座標（ｃｏ−ｏｒｄｉｎａｔｅｓ）情報を、上記ＰｒｏＳｅサーバー−Ａに送るＰｒｏＳｅ Ｌｏｃａｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージに含める。この時、ＵＥ−Ｂのセル情報（すなわち、ＥＣＧＩ情報）は含めても含めなくてもよい。

また、ＰｒｏＳｅサーバー−Ｂは、ＵＥの位置情報（例えば、セル情報又はＥＣＧＩ）から座標情報を抽出／類推／決定／変換するために必要なマッピング（ｍａｐｐｉｎｇ）情報を維持していたり、他のネットワークノードとの相互作用（ｉｎｔｅｒａｃｔｉｏｎ）によってセル情報に対応／マッピングする座標情報を取得することができる。このため、上記座標情報は、ｉ）セルの中心座標（すなわち、緯度と経度）情報、及び／又はｉｉ）セルがカバーする東西南北それぞれの座標（すなわち、緯度と経度）情報、及び／又はｉｉｉ）セルがカバーする東西距離情報、及び／又はｉｖ）セルがカバーする南北距離情報とすることができる。また、ここで、座標情報は、正確な値であってもよいが、概略的な値であってもよい。

図２０の段階１８ｂで、ＰｒｏＳｅサーバー−Ａは、ＰｒｏＳｅ Ｌｏｃａｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎ ＡｃｋメッセージをＰｒｏＳｅサーバー−Ｂに応答する。

図２０の段階１９ｂで、段階１２ｂ以降に、仮にＵＥ−Ｂが段階１２ｂによって接続モードに変更されると、ＭＭＥ−ＢはｅＮｏｄｅＢに、段階１０ａで記述したように、ＵＥ−ＢがそのサービングセルをｅＮｏｄｅＢに属した他のセルへと変更する都度、ＵＥ−Ｂの現在位置を報告することを指示するように位置報告制御を行う。

図２０の段階２０ｂで、仮に段階１９ｂでＭＭＥ−ＢがｅＮｏｄｅＢに対して位置報告制御を行うと、ｅＮｏｄｅＢは、ＵＥ−ＢがそのサービングセルをｅＮｏｄｅＢに属した他のセルへと変更する都度、Ｌｏｃａｔｉｏｎ ＲｅｐｏｒｔメッセージをＭＭＥ−Ｂに送信する。更新された位置情報は、ＭＭＥ−ＢからＰｒｏＳｅサーバー−Ｂに、図２０の段階１３ｂ乃至１６ｂに示したように、ＨＳＳ−Ｂを介して伝達される。仮に、ＰｒｏＳｅサーバー−Ｂは、更新された位置情報を受信すると、段階１７ｂ乃至１８ｂに示すように、その情報をＰｒｏＳｅサーバー−Ａにフォワードする。

図２０の段階２１で、図２０の段階１３ａで受信したＬｏｃａｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージ及び図２０の段階１７ｂで受信したＰｒｏＳｅ Ｌｏｃａｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージに基づいて、ＰｒｏＳｅサーバー−Ａは、ＵＥ−Ａの位置情報及びＵＥ−Ｂの位置情報並びに近接基準（ｐｒｏｘｉｍｉｔｙ ｃｒｉｔｅｒｉａ）によって、ＵＥ−ＡとＵＥ−Ｂとの近接関係を決定する。仮にＰｒｏＳｅサーバー−Ａが、ＵＥ−ＡとＵＥ−Ｂとが近接関係にあると判断する場合には、図２０の段階２２が行われる。そうでないと、ＰｒｏＳｅサーバー−Ａは、新しいＬｏｃａｔｉｏｎ ＮｏｔｉｆｉｃａｔｉｏｎメッセージがＰｒｏＳｅサーバー−Ｂ又はＨＳＳ−Ａから受信される度ごとに近接関係を確認する。仮に、ＰｒｏＳｅサーバー−Ａが、ＵＥ−Ａ及びＵＥ−Ｂが近接関係にあると判断したり、仮に図２０の段階５ａで起動したタイマーと図２０の段階５ｂで起動したタイマーが満了すると、図２０の段階２２が行われる。

なお、上記でＰｒｏＳｅサーバー−ＡがＵＥ−ＡとＵＥ−Ｂとの近接関係を決定するために用いる位置情報は、セル情報（すなわち、ＥＣＧＩ情報）ではなく座標（ｃｏ−ｏｒｄｉｎａｔｅｓ）情報である。

ここで、ＰｒｏＳｅサーバー−Ａは、ＵＥの位置情報（例えば、ｃｅｌｌ情報又はＥＣＧＩ）から座標情報を抽出／類推／決定／変換するために必要なマッピング情報を維持していたり、他のネットワークノードとの相互作用によって、セル情報に対応／マッピングする座標情報を取得することができる。このため、上記座標情報は、ｉ）セルの中心座標（すなわち、緯度と経度）情報、及び／又はｉｉ）セルがカバーする東西南北それぞれの座標（すなわち、緯度と経度）情報、及び／又はｉｉｉ）セルがカバーする東西距離情報、及び／又はｉｖ）セルがカバーする南北距離情報とすることができる。ここで、座標情報は、正確な値であってもよく、概略的な値であってもよい。

図２０の段階２２で、ＰｒｏＳｅサーバー−Ａは、ＵＥ−ＡとＵＥ−Ｂとが近接しているか否かを示す情報と併せてＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ ＲｅｓｐｏｎｓｅメッセージをＵＥ−Ａに送信する。仮に、ＵＥ−Ａ／ユーザ−ＡがＵＥ−Ｂ／ユーザ−Ｂを探索する権限がない場合には、ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ Ｒｅｓｐｏｎｓｅメッセージは、ＵＥ−ＡからのＰｒｏＳｅ探索要請が拒絶されたことを示す。

図２０の段階２３乃至段階２５で、仮にＵＥ−ＡとＵＥ−Ｂとが近接していると、ＰｒｏＳｅサーバー−ＡはＰｒｏＳｅサーバー−ＢにＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ ＡｌｅｒｔメッセージをＵＥ−Ｂに送信し、ＵＥ−ＡがＵＥ−Ｂを探索することを希望していることを知らせるように要請することができる。

また、ＵＥ−ＡとＵＥ−Ｂとが相互発見しようと試みてもよい。

図２０の段階２６で、ＰｒｏＳｅサーバー−Ａは、ＵＥ−Ａに関連した位置報告を中断することをＨＳＳ−Ａに要請する。この位置報告取消は、ＭＭＥ−Ａ及び必要な場合にはｅＮｏｄｅＢに適用することができる。

図２０の段階２７で、ＰｒｏＳｅサーバー−Ａは、ＵＥ−Ｂに関連した位置報告を中断することをＰｒｏＳｅサーバー−Ｂに要請する。この位置報告取消は、ＨＳＳ−Ｂを介してＭＭＥ−Ｂ及び必要な場合にはｅＮｏｄｅＢに適用することができる。

なお、ＵＥ−Ａの位置情報を取得するための段階（すなわち、段階５ａ〜１６ａ）及びＵＥ−Ａの位置情報を取得するための段階（すなわち、段階５ｂ〜２０ｂ）は並列的に行われてもよい。

また、ＰｒｏＳｅサーバー−Ａは、ＵＥ−Ａ及びＵＥ−Ｂに対してそれぞれ別個のタイマーを起動する代わりに、ＵＥ−Ａ及びＵＥ−Ｂ両方のためのＴｉｍｅ＿Ｘを有する単一タイマーを起動することもできる。

仮にＵＥ−Ａが遊休状態である場合、遊休状態の位置情報を取得するための図２０の段階１２ｂ〜１６ｂ及び１９ｂ〜２０ｂが、図２０の段階１０ａ〜１６ａの代わりに行われてもよい。また、仮にＵＥ−Ｂが接続状態である場合には、接続状態の位置情報を取得するための図２０の段階１０ａ〜１６ａが、図２０の段階１２ｂ〜１６ｂ及び段階１９ｂ〜２０ｂの代わりに行われてもよい。

図２０に開示された手順は、ＵＥ−ＡとＵＥ−Ｂは、同一ｅＮｏｄｅＢ及び同一ＭＭＥにも適用することができ、異なるｅＮｏｄｅＢ及び同一ＭＭＥによってサービスされたり、異なるｅＮｏｄｅＢ及び異なるＭＭＥによってサービスされる場合にも適用することができる。

なお、上記した内容は、探索ＵＥと被探索者ＵＥがＲＡＮ／ネットワークを共有（ｓｈａｒｅ）する（すなわち、ＲＡＮ ｓｈａｒｉｎｇ又はｎｅｔｗｏｒｋ ｓｈａｒｉｎｇとなる）異なるＰＬＭＮに登録されている場合の他、ＲＡＮ／ネットワークを共有しない異なるＰＬＭＮに登録されている場合にも適用することができる。

また、上述した実施例では、ＰｒｏＳｅサーバーがセル情報（ＥＣＧＩ情報）から座標情報を抽出／類推／決定／変換する動作を行うが、これとは違い、ＭＭＥ又はＨＳＳが行うこともできる。

また、上記で提案した座標情報に基づく近接関係（ｐｒｏｘｉｍｉｔｙ）決定方法は、ＰＬＭＮ間探索（ｉｎｔｅｒ−ＰＬＭＮ ｄｉｓｃｏｖｅｒｙ）（すなわち、探索ＵＥと被探索ＵＥが異なるＰＬＭＮに登録されている場合）の他、ＰＬＭＮ内探索（ｉｎｔｒａ−ＰＬＭＮ ｄｉｓｃｏｖｅｒｙ）（すなわち、探索ＵＥと被探索ＵＥが同一ＰＬＭＮに登録されている場合）にも適用することができる。特に、ＰＬＭＮ内探索では、探索ＵＥと被探索ＵＥが異なるセルにキャンプ−オンした場合に、前述した座標情報に基づく近接関係決定方法を用いることができる。

３−１１． 第１７実施例

以下では、本発明にまた違う実施例に係る、時間区間（ｔｉｍｅ ｗｉｎｄｏｗ）を適用したＥＰＣ−レベルＰｒｏＳｅ探索について説明する。図２１で、ＵＥ−Ａ（すなわち、探索者）とＵＥ−Ｂ（すなわち、被探索者）は同一ＰＬＭＮに登録されており、ノン−ローミングであると仮定する。

ＵＥ−Ａは、図２１に示すように、時間区間（ｔｉｍｅ ｗｉｎｄｏｗ）内にＵＥ−Ｂと近接関係が成立する場合、これを知るために、ネットワークに時間区間（ｔｉｍｅ ｗｉｎｄｏｗ）と共にＰｒｏＳｅ探索を要請する。以下では、ＵＥ−Ａ（探索者）とＵＥ−Ｂ（被探索者）は同一ＰＬＭＮに登録され、ノン−ローミングである場合を示す。

この実施例で、ＵＥ−ＡとＵＥ−ＢはＰｒｏＳｅサーバーに登録されている。

図２１の段階１で、ＵＥ−ＡはＰｒｏＳｅサーバーに、時間区間内でＵＥ−Ｂと近接関係が成立する場合、これを知るために、ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ Ｒｅｑｕｅｓｔメッセージを送信する。この時、ＵＥ−Ａは、ＰｒｏＳｅサーバーにどれくらいの時間区間まで要請が有効であるかを示す時間区間情報（すなわち、図２１のＴｉｍｅ＿Ｘ）を、ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ Ｒｅｑｕｅｓｔメッセージに含めることができる。ここで、ＵＥ−Ａ及びＵＥ−Ｂは、それぞれ、ＰｒｏＳｅ−可能ＵＥ−Ａ上のアプリケーション及びＰｒｏＳｅ−可能ＵＥ−Ｂ上のアプリケーションを実質的に意味することができる。

図２１の段階２で、ＰｒｏＳｅサーバーは、ＵＥ−Ａから送信されたＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ ｒｅｑｕｅｓｔを認証し、ＵＥ−Ａ／ユーザ−ＡがＵＥ−Ｂ／ユーザ−Ｂを探索することが許容されるか否かを確認する。仮にＵＥ−Ａ／ユーザ−ＡがＵＥ−Ｂ／ユーザ−Ｂを探索することが許容されない場合には、図２１の段階８を行う。

図２１の段階３で、ＰｒｏＳｅサーバーは、上記要請（すなわち、ＵＥ−Ａからの要請）に対して、ＵＥ−Ａ及びＵＥ−ＢのためのＴｉｍｅ＿Ｘの値でタイマーを起動する。

図２１の段階４ａで、ＵＥ−Ａの最新のセル情報（すなわち、ＥＣＧＩ）を取得するために、ＨＳＳを介してＭＭＥに、ＵＥ−Ａのためのｏｎｅ ｒｏｕｎｄ ｌｏｃａｔｉｏｎ ｒｅｐｏｒｔｉｎｇ ｒｅｑｕｅｓｔを行う。ＭＭＥは、ＵＥ−ＡのＥＣＧＩを含む応答を、ＨＳＳを介してＰｒｏＳｅサーバーに送信する。仮にＵＥ−Ａが遊休状態であると、ＭＭＥは、ＵＥ−ＡのＥＣＧＩを取得するために、ＵＥ−Ａにページングを行う。

図２１の段階４ｂで、ＵＥ−Ｂの最新のセル情報（すなわち、ＥＣＧＩ）を取得するために、ＨＳＳを介してＭＭＥに、ＵＥ−Ｂのためのｏｎｅ ｒｏｕｎｄ ｌｏｃａｔｉｏｎ ｒｅｐｏｒｔｉｎｇ ｒｅｑｕｅｓｔを行う。ＭＭＥは、ＵＥ−ＢのＥＣＧＩを含む応答を、ＨＳＳを介してＰｒｏＳｅサーバーに送信する。仮にＵＥ−Ｂが遊休状態であると、ＭＭＥは、ＵＥ−ＢのＥＣＧＩを取得するために、ＵＥ−Ｂにページングを行う。

図２１の段階５で、ＵＥ−Ａ、ＵＥ−Ｂ両方の位置情報を受信したため、ＵＥ−Ａの位置情報及びＵＥ−Ｂの位置情報並びに近接基準（ｐｒｏｘｉｍｉｔｙ ｃｒｉｔｅｒｉａ）に基づいて、ＵＥ−ＡとＵＥ−Ｂの近接関係を判断する。

仮に、ＵＥ−ＡとＵＥ−Ｂとの近接関係の確認（ｐｒｏｘｉｍｉｔｙ ｃｈｅｃｋ）のための時間（すなわち、Ｔｉｍｅ＿Ｘ）が満了するまで、ＵＥ−ＡとＵＥ−Ｂとの近接関係が設定されないと判断される場合、ＰｒｏＳｅサーバーは、それに続く（ｓｕｂｓｅｑｕｅｎｔ）近接関係の確認を行わないと決定する。この場合、図２１の段階８のみが行われ、このため、ＰｒｏＳｅサーバーはＵＥ−Ａに、ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ Ｒｅｓｐｏｎｓｅメッセージと併せて、ＵＥ−ＡとＵＥ−Ｂとの近接関係が成立しないことを示す情報を送信する。そうでないと、図２１の段階６ａ及び６ｂが行われる。

図２１の段階６ａで、ＰｒｏＳｅサーバーはＭＭＥにＨＳＳを介して、ＵＥ−Ａのためのｌｏｃａｔｉｏｎ ｒｅｐｏｒｔｉｎｇ ｒｅｑｕｅｓｔを行う。このｌｏｃａｔｉｏｎ ｒｅｐｏｒｔｉｎｇ ｒｅｑｕｅｓｔを行う際、ＰｒｏＳｅサーバーは位置報告（ｌｏｃａｔｉｏｎ ｒｅｐｏｒｔｉｎｇ）周期を含むことができる。この位置報告周期は、ＰｒｏＳｅサーバーに設定（ｃｏｎｆｉｇｕｒｅ）されている固定値であってもよく、Ｔｉｍｅ＿Ｘ値に基づいて算出／策定された値（例えば、Ｔｉｍｅ＿Ｘ値よりもやや小さい値）であってもよい。

なお、ＭＭＥは、上記ＰｒｏＳｅサーバーが送ったｌｏｃａｔｉｏｎ ｒｅｐｏｒｔｉｎｇ ｒｅｑｕｅｓｔを受信すると、次のように動作する。
− ＵＥ−Ａが接続モード（ｃｏｎｎｅｃｔｅｄ ｍｏｄｅ）である場合：ＵＥ−Ａがセル変更をする度ごとに位置情報（すなわち、ＥＣＧＩ）をｅＮｏｄｅＢがＭＭＥに報告するようにする（これは、従来のｌｏｃａｔｉｏｎ ｒｅｐｏｒｔｉｎｇ ｃｏｎｔｒｏｌ動作（３ＧＰＰ ＴＳ ２３．４０１の５．９．１節を参考）をそのまま用いてもよく、拡張／変形して用いてもよい。）。ＭＭＥはセル変更を毎回ＨＳＳを介してＰｒｏＳｅサーバーに報告する。上記ＭＭＥの報告は、図２１の段階４ａ以降に、ＵＥ−ＡのＥＣＧＩが変更された場合にも該当する。
− 上記ｌｏｃａｔｉｏｎ ｒｅｐｏｒｔｉｎｇ ｒｅｑｕｅｓｔを受信時に、ＵＥが遊休モードである場合、又はＵＥが接続モードから遊休モードに切り替わった場合：ｌｏｃａｔｉｏｎ ｒｅｐｏｒｔｉｎｇ周期値に設定されたｔｉｍｅｒ（以下、ｔｉｍｅ＿ｒ）を始動／起動する。ｉ）上記ｔｉｍｅ＿ｒが満了する前に、ＵＥ−ＡがＴＡＵ（Ｔｒａｃｋｉｎｇ Ａｒｅａ Ｕｐｄａｔｅ）手順又はＳＲ（Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ）手順（これは、ＵＥ ｔｒｉｇｇｅｒｅｄであってもよく、ｎｅｔｗｏｒｋ ｔｒｉｇｇｅｒｅｄであってもよい。）を行うと、ＭＭＥは、上記の手順から取得したＵＥ−ＡのＥＣＧＩ情報を、ＨＳＳを介してＰｒｏＳｅサーバーに報告する。そして又は同時に又はこれに（すなわち、ＰｒｏＳｅサーバー報告）に先立って、ｔｉｍｅ＿ｒを中断（ｓｔｏｐ）する。ｉｉ）上記ｔｉｍｅ＿ｒが満了すると、ＭＭＥはＵＥ−ＡのＥＣＧＩ情報を得るためにＵＥ−Ａをページングする。これによって取得したＵＥ−ＡのＥＣＧＩ情報を、ＨＳＳを介してＰｒｏＳｅサーバーに報告する。

図２２は、上述した、ＭＭＥがＨＳＳを介してＰｒｏＳｅサーバーからｌｏｃａｔｉｏｎ ｒｅｐｏｒｔｉｎｇ ｒｅｑｕｅｓｔを受信する時の動作を示す参考図である。

図２１の段階６ａに記述された動作ｉ）のように、遊休モードであるＵＥ−ＡがＴＡＵ手順を行った場合、仮にＴＡＵ Ｒｅｑｕｅｓｔメッセージに「Ａｃｔｉｖｅ」フラグ（その詳細は、３ＧＰＰ ＴＳ ２４．３０１のＴａｂｌｅ９．９．３．１４．１：ＥＰＳ ｕｐｄａｔｅ ｔｙｐｅ情報要素（ＩＥ）を参照）が設定されていないと、ＭＭＥは、ＵＥ−Ａのセル変更の都度にｅＮｏｄｅＢが報告するようにする要請（図２２でＮＯＴＥ１）と表示された動作）を行わなくてもよい。これは、ＵＥ−Ａに対してＴＡＵ手順によるユーザプレーン設定手順（ｕｓｅｒ ｐｌａｎｅ ｓｅｔｕｐ ｐｒｏｃｅｄｕｒｅ）を行う必要がないことから、ＭＭＥがＴＡＵ手順を完了後に、Ｓ１ ｒｅｌｅａｓｅ ｐｒｏｃｅｄｕｒｅ（３ＧＰＰ ＴＳ ２３．４０１の５．３．５節を参考）を行うためである。また、ＭＭＥが図２２のように動作することによって、ＵＥの位置を把握するために行うページング（ｐａｇｉｎｇ）動作を減らすことができる。これによって、ＵＥを接続モード（ｃｏｎｎｅｃｔｅｄ ｍｏｄｅ）にする上で発生するＵＥの電力消耗、並びにＵＥとネットワーク間及びネットワーク内におけるシグナリングを減らすことができる。

また、上記の位置報告周期を、ＰｒｏＳｅサーバーが提供する代わりに、ＭＭＥが決定したりＨＳＳが提供したりしてもよい。そのために、ＰｒｏＳｅサーバーは、ｌｏｃａｔｉｏｎ ｒｅｐｏｒｔｉｎｇ ｒｅｑｕｅｓｔを行う際にＴｉｍｅ＿Ｘ値を提供することもできる。すると、ＨＳＳ又はＭＭＥは、Ｔｉｍｅ＿Ｘ値に基づいて位置報告周期を算出／策定することができる。又は、上記位置報告周期情報がＨＳＳ又はＭＭＥに設定されていてもよい。ＭＭＥが位置報告周期を算出／策定する場合、ＵＥの周期的ＴＡＵタイマー関連情報、ＵＥの次のＴＡＵ手順を行うまでに残った時間、その他ＵＥのＭＭ動作と関連したタイマー情報などをさらに考慮することができる。

図２１の段階６ｂで、ＰｒｏＳｅサーバーはＭＭＥにＨＳＳを介して、ＵＥ−Ｂのためのｌｏｃａｔｉｏｎ ｒｅｐｏｒｔｉｎｇ ｒｅｑｕｅｓｔを行う。この段階でｌｏｃａｔｉｏｎ ｒｅｐｏｒｔｉｎｇ ｒｅｑｕｅｓｔと関連して起こる動作は、図２１の段階６ａで説明した内容と同一であり、その説明は省略する。

図２１の段階７で、ＰｒｏＳｅサーバーはＨＳＳを介してＭＭＥからＵＥ−Ａ又はＵＥ−Ｂの新しい位置アップデートを受信する度ごとに近接関係の確認（ｐｒｏｘｉｍｉｔｙ ｃｈｅｃｋ）を行う。仮に、ＰｒｏＳｅサーバーがＵＥ−ＡとＵＥ−Ｂとが近接関係にあると判断したり、図２１の段階３で起動したタイマーが満了した場合には、図２２の段階８が行われる。

図２１の段階８で、ＰｒｏＳｅサーバーは、ＵＥ−ＡとＵＥ−Ｂとが近接しているか否かを示す情報と併せてＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ ＲｅｓｐｏｎｓｅメッセージをＵＥ−Ａに送信する。仮にＵＥ−Ａ／ユーザ−ＡがＵＥ−Ｂ／ユーザ−Ｂを探索する権限がない場合には、ＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ Ｒｅｓｐｏｎｓｅメッセージは、ＵＥ−ＡからのＰｒｏＳｅ探索要請が拒絶されたことを示す。

図２１の段階９で、仮にＵＥ−ＡとＵＥ−Ｂとが近接していると、ＰｒｏＳｅサーバーはＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ ＡｌｅｒｔメッセージをＵＥ−Ｂに送信し、ＵＥ−ＡがＵＥ−Ｂを探索することを希望していることを知らせることもできる。

また、ＵＥ−ＡとＵＥ−Ｂとが相互発見しようと試みてもよい。

図２１の段階１０ａで、ＰｒｏＳｅサーバーはＭＭＥにＨＳＳを介して、ＵＥ−Ａに関連した位置報告を取り消すようにすることができる。この位置報告取消は、ＭＭＥ及び必要な場合にはｅＮｏｄｅＢに適用することができる。

図２２の段階１０ｂで、ＰｒｏＳｅサーバーはＭＭＥにＨＳＳを介して、ＵＥ−Ｂに関連した位置報告を取り消すようにすることができる。この位置報告取消は、ＭＭＥ及び必要な場合にはｅＮｏｄｅＢに適用することができる。

上述したこの実施例で、段階４ａ及び段階５ａにおけるｏｎｅ ｒｏｕｎｄ ｌｏｃａｔｉｏｎ ｒｅｐｏｒｔｉｎｇ ｒｅｑｕｅｓｔは、ｌｏｃａｔｉｏｎ ｒｅｐｏｒｔｉｎｇ ｒｅｑｕｅｓｔに対する応答をＭＭＥが一度だけ行うようにする要請である。

なお、ＵＥ−Ａの初期位置情報を取得するための段階（すなわち、段階４ａ）及びＵＥ−Ａの初期位置情報を取得するための段階（すなわち、段階４ｂ）は並列的に行われてもよい。また、ＵＥ−Ａの位置情報を取得するための段階（すなわち、段階６ａ）及びＵＥ−Ａの位置情報を取得するための段階（すなわち、段階６ｂ）は並列的に行われてもよい。

また、ＰｒｏＳｅサーバーはＵＥ−Ａ及びＵＥ−Ｂに対してそれぞれ別個のタイマーを起動する代わりに、ＵＥ−Ａ及びＵＥ−Ｂ両方のためのＴｉｍｅ＿Ｘを有する単一タイマーを起動することもできる。

図２１及び図２２に開示された手順は、説明の便宜のために、ＵＥ−ＢとＵＥ−Ａは同一ｅＮｏｄｅＢ及び同一ＭＭＥにも適用される場合を説明したが、異なるｅＮｏｄｅＢ及び同一ＭＭＥによってサービスされたり、同一ｅＮｏｄｅＢ及び異なるＭＭＥによってサービスされたり、異なるｅＮｏｄｅＢ及び異なるＭＭＥによってサービスされる場合にも適用することができる。

また、この実施例は、ＵＥ−Ａ及び／又はＵＥ−Ｂがローミング（ｒｏａｍｉｎｇ）である場合にも拡張して適用することができる。なお、上記実施例はＰＬＭＮ間探索（すなわち、ＵＥ−ＡとＵＥ−Ｂが異なるＰＬＭＮに登録されている場合）にも拡張適用することができる。

４． ＰｒｏＳｅ Ｆｕｎｃｔｉｏｎに基づく本発明の実施例−第１８実施例

以下、本発明によってＰｒｏＳｅ Ｆｕｎｃｔｉｏｎに適用される実施例を説明する。

４−１． Ｐｒｏｘｉｍｉｔｙ Ｒｅｑｕｅｓｔ

図２３を参照して、本発明に係るＰｒｏｘｉｍｉｔｙ Ｒｅｑｕｅｓｔについて説明する。以下では、説明の便宜のために、探索者はＵＥ−Ａであり、被探索者はＵＥ−Ｂであるとする。

図２３の段階１で、ＵＥ−Ａは、ＰｒｏＳｅ探索を要請するために、Ｐｒｏｘｉｍｉｔｙ ＲｅｑｕｅｓｔメッセージをＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ−Ａに送信する。ここで、Ｐｒｏｘｉｍｉｔｙ Ｒｅｑｕｅｓｔメッセージに含まれるパラメータとしては、ＥＰＵＩＤ、アプリケーション識別子（Ａｐｐｌｉｃａｔｉｏｎ ＩＤ）、探索者のＡＬＵＩＤ、被探索者のＡＬＵＩＤ、区間（ｗｉｎｄｏｗ）、範囲（Ｒａｎｇｅ）、端末の位置（ｌｏｃａｔｉｏｎ）、ＷＬＡＮ指示情報（ｉｎｄｉｃａｔｉｏｎ）を含むことができる。したがって、ＵＥ−Ａは、例えば、Ｐｒｏｘｉｍｉｔｙ Ｒｅｑｕｅｓｔメッセージ（ＥＰＵＩＤ＿Ａ、Ａｐｐｌｉｃａｔｉｏｎ ＩＤ、ＡＬＵＩＤ＿Ａ、ＡＬＵＩＤ＿Ｂ、ｗｉｎｄｏｗ、Ｒａｎｇｅ、Ａ’ｓ ｌｏｃａｔｉｏｎ、［ＷＬＡＮ ｉｎｄｉｃａｔｉｏｎ］）のような形態のＰｒｏｘｉｍｉｔｙ Ｒｅｑｕｅｓｔメッセージを送信することができる（以下、特定メッセージの具体的形態において「［Ａ］」は、「Ａ」パラメータがオプションとして追加されてもよいことを表す。）。

ここで、ＥＰＵＩＤは、ユーザのＥＰＣ ＰｒｏＳｅユーザＩＤ（Ｕｓｅｒ’ｓ ＥＰＣ ＰｒｏＳｅ Ｕｓｅｒ ＩＤ）を表し（すなわち、ＥＰＵＩＤ＿Ａは、ユーザＡのＥＰＣ ＰｒｏＳｅユーザＩＤ）、ＥＰＣ−レベルＰｒｏＳｅ探索及びＷＬＡＮ直接通信を支援するＥＰＣのための識別子であり、ＰｒｏＳｅのために登録されたＵＥを固有に識別させる。このような識別子は、場合によってＰｒｏＳｅ Ｆｕｎｃｔｉｏｎによって再割り当てされてもよい。アプリケーション識別子（Ａｐｐｌｉｃａｔｉｏｎ ＩＤ）は、サードパーティアプリケーションサーバープラットフォーム（３ｒｄ ｐａｒｔｙ Ａｐｐ Ｓｅｒｖｅｒ ｐｌａｔｆｏｒｍ）を識別するために用いられる。ＡＬＵＩＤは、アプリケーションレイヤユーザＩＤを表し、以下、ＡＬＵＩＤ＿Ａ及びＡＬＵＩＤ＿Ｂはそれぞれ、ユーザＡ及びユーザＢのアプリケーションレイヤユーザＩＤを表す。区間（ｗｉｎｄｏｗ）パラメータは、上記要請が有効な時間区間を示す。範囲（ｒａｎｇｅ）は、許容される範囲等級（ｒａｎｇｅ ｃｌａｓｓｅｓ）のうち、上記アプリケーションのために選択された要請範囲等級を示す。ここで、範囲等級情報は、例えば、近距離（ｓｈｏｒｔ）、中間（ｍｅｄｉｕｍ）及び最大（ｍａｘｉｍｕｍ）のような形態であってもよい。端末の位置は、端末が知らせた最も正確な現在位置を表し、例えば、Ａ’ｓ ｌｏｃａｔｉｏｎは、ＵＥ−Ａの最も正確に知らされた現在位置を意味する。ここで、ＵＥ−Ａは、ＷＬＡＮ指示情報を追加することによって、場合によって（ｏｐｔｉｏｎａｌｌｙ）、ＷＬＡＮ直接探索及びＵＥ−ＢとのＷＬＡＮ直接通信のためのＥＰＣ支援を要請することができる。

図２３の段階２で、ＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ−Ａは、ターゲットユーザーＢのＥＰＣ ＰｒｏＳｅユーザＩＤを提供することを要請するために、ＵＥ−Ａ及びＵＥ−ＢのアプリケーションレイヤユーザＩＤを含むＭａｐ Ｒｅｑｕｅｓｔメッセージ（例えば、Ｍａｐ Ｒｅｑｕｅｓｔ（ＡＬＵＩＤ＿Ａ、ＡＬＵＩＤ＿Ｂ））をアプリケーションサーバー（Ａｐｐ ｓｅｒｖｅｒ）に送信する。ここで、ＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ−Ａは、上記アプリケーションレイヤユーザＩＤ（すなわち、ＡＬＵＩＤ＿Ａ及びＡＬＵＩＤ＿Ｂ）を、後述する図２４に示すＰｒｏｘｉｍｉｔｙ Ａｌｅｒｔ Ｐｒｏｃｅｄｕｒｅが実行されるまで記憶したり、図２５に示すＰｒｏｘｉｍｉｔｙ Ｒｅｑｕｅｓｔ Ｃａｎｃｅｌｌａｔｉｏｎ ｐｒｏｃｅｄｕｒｅが実行されるまで記憶したり、上記要請が有効な時間区間が満了するまで記憶する。

図２３の段階３で、アプリケーションサーバーは、ユーザＢのアプリケーション−特定Ｐｒｏｓｅ許可（ｐｅｒｍｉｓｓｉｏｎ）をチェックし、ユーザＡがユーザＢを探索することが許容されるか確認する。そして、アプリケーションサーバーは、ユーザＢのＥＰＣ ＰｒｏＳｅユーザＩＤ（以下、ＥＰＵＩＤ＿Ｂ）及びＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ−ＢのＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ ＩＤを指示するＭａｐ Ｒｅｓｐｏｎｓｅメッセージ（例えば、Ｍａｐ Ｒｅｓｐｏｎｓｅ（ＥＰＵＩＤ＿Ｂ、ＰＦＩＤ＿Ｂ））を、ＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ−Ａに送信する。ここで、ＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ−Ａは、上記ＥＰＵＩＤ＿Ｂ及びＰＦＩＤ＿Ｂを、後述する図２４に示すＰｒｏｘｉｍｉｔｙ Ａｌｅｒｔ Ｐｒｏｃｅｄｕｒｅが実行されるまで記憶したり、図２５に示すＰｒｏｘｉｍｉｔｙ Ｒｅｑｕｅｓｔ Ｃａｎｃｅｌｌａｔｉｏｎ ｐｒｏｃｅｄｕｒｅが実行されるまで記憶したり、上記要請が有効な時間区間が満了するまで記憶する。

図２３の段階４で、ＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ−Ａは、ＥＰＣ ＰｒｏＳｅユーザＩＤ、（時間）区間、探索者の位置、探索者のＷＬＡＮリンクレイヤＩＤ（以下、ＷＬＬＩＤ）を含むＰｒｏｘｉｍｉｔｙ Ｒｅｑｕｅｓｔメッセージ（例えば、Ｐｒｏｘｉｍｉｔｙ Ｒｅｑｕｅｓｔ（ＥＰＵＩＤ＿Ｂ、ＥＰＵＩＤ＿Ａ、ｗｉｎｄｏｗ、Ａ’ｓ ｌｏｃａｔｉｏｎ、［ＷＬＬＩＤ＿Ａ］）を、ＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ−Ｂに送信する。ここで、Ｐｒｏｘｉｍｉｔｙ Ｒｅｑｕｅｓｔメッセージは、位置アップデート周期を示したり、位置アップデートトリガーを示したり、或いは両者を示したりすることができる。また、Ａの位置情報は、図２３の段階１で提供されたＵＥ−Ａの現在位置情報であり、ＧＡＤ（Ｇｅｏｇｒａｐｈｉｃａｌ Ａｒｅａ Ｄｅｓｃｒｉｐｔｉｏｎ）の形態で表現されてもよい。ＧＡＤ形態に関する詳細な説明と定義は、３ＧＰＰ ＴＳ ２３．０３２を参照することができる。しかし、Ａの位置情報は、必ずしも上述の定義に限定して解釈されず、本発明に係る「１． ３ＧＰＰ ＥＰＳ（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｓｙｓｔｅｍ）のような移動通信システム上のＰｒｏＳｅ探索方法」と関連して記述した様々な位置情報であってもよい。なお、図２３の段階１でＵＥ−ＡがＷＬＡＮ直接探索と通信を要請した場合、ＷＬＡＮ指示情報が含まれてもよい。

図２３の段階５で、前の段階で受信されたＥＰＵＩＤ＿Ｂに基づいて、ＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ−Ｂは、ユーザＢの記録（ｒｅｃｏｒｄ）を検索（ｒｅｔｒｉｅｖｅ）する。この時、ＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ−Ｂは、ＵＥ−Ｂの最後に知らされた位置をＨＳＳを介して要請することができる（図２３の段階５ａ）。

なお、上記ＵＥ−Ｂの位置情報は、上述した「１． ３ＧＰＰ ＥＰＳ（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｓｙｓｔｅｍ）のような移動通信システム上のＰｒｏＳｅ探索方法」と関連して記述した様々な位置情報とすることができる。また、上記ＵＥ−Ｂの位置情報は、ｉ）ＵＥ−ＢをサービスしているＭＭＥ情報（ＭＭＥ ｉｄｅｎｔｉｆｉｅｒ及び／又はＭＭＥ ｎａｍｅ及び／又はＭＭＥ ｎｏｄｅ ＦＱＤＮ（Ｆｕｌｌｙ Ｑｕａｌｉｆｉｅｄ Ｄｏｍａｉｎ Ｎａｍｅ）及び／又はＭＭＥ ｎｕｍｂｅｒ）、及び／又はｉｉ）ＵＥ−Ｂの位置している国情報、及び／又はｉｉｉ）ＵＥ−Ｂの位置／登録しているＰＬＭＮ情報、及び／又はｉｖ）ＵＥ−Ｂの位置している大陸情報などとすることができる。

ここで、ＵＥ−Ｂの位置している国情報、ＰＬＭＮ情報、大陸情報は、ＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ−ＢがＨＳＳから直接的な形態で取得してもよいが、ＨＳＳから取得したＵＥ−Ｂの位置情報を用いて直接又は間接的に類推してもよい。例えば、ＨＳＳから取得したＵＥ−Ｂの位置情報がＵＥ−Ｂが位置／登録しているＰＬＭＮ情報であれば、ＰＬＭＮ ｉｄｅｎｔｉｆｉｅｒはＭＣＣ（Ｍｏｂｉｌｅ Ｃｏｕｎｔｒｙ Ｃｏｄｅ）及びＭＮＣ（Ｍｏｂｉｌｅ Ｎｅｔｗｏｒｋ Ｃｏｄｅ）で構成されるので、国情報を類推することができる。他の例として、ＨＳＳから取得したＵＥ−Ｂの位置情報がＵＥ−ＢのＥＣＧＩ情報であれば、ＥＣＧＩはＰＬＭＮ ｉｄｅｎｔｉｆｉｅｒ及びＥＣＩ（Ｅ−ＵＴＲＡＮ Ｃｅｌｌ Ｉｄｅｎｔｉｔｙ）で構成されるので、ＰＬＭＮ情報又は国情報を類推することができる。さらに他の例として、ＨＳＳから取得したＵＥ−Ｂの位置情報がＵＥ−Ｂの位置している座標情報であれば、これを用いて国情報又は大陸情報を類推することができる。なお、ＵＥ−Ｂに対して記述したこのような位置情報内容は、ＵＥ−Ａから取得した位置情報にも同一に適用することができる。また、ＵＥ−Ａに対する位置情報の種類とＵＥ−Ｂに対する位置情報の種類とが異なっても、ＰｒｏＳｅ Ｆｕｎｃｔｉｏｎは、上記位置情報が内包／含蓄している情報及び／又は位置情報変換デーベース（ＤＢ）／テーブル（例えば、座標情報を国情報に変換するＤＢ／テーブルなど）を用いて、両ＵＥ間の距離情報／近接関係（ｐｒｏｘｉｍｉｔｙ）を決定することができる。

ＨＳＳを介して受信されたＵＥ−Ｂの最後に知らされた位置と図２３の段階４でＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ−Ａによって提供されるＵＥ−Ａの位置及び時間区間（ｔｉｍｅ ｗｉｎｄｏｗ）に基づいて、ＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ−Ｂは、要請された時間区間（ｔｉｍｅ ｗｉｎｄｏｗ）内でユーザ（すなわち、ユーザＡとユーザＢ又はＵＥ−ＡとＵＥ−Ｂ）が近接関係（ｐｒｏｘｉｍｉｔｙ）に設定されない（又は、近接関係に置かれない）と判断される場合、ＵＥ−Ａに対して適切な根拠値（ｃａｕｓｅ ｖａｌｕｅ）と共にＰｒｏｘｉｍｉｔｙ Ｒｅｑｕｅｓｔ Ｒｅｊｅｃｔメッセージを送信することによって、上記要請を拒絶することもできる（図２３の段階５ｂ及び段階５ｃ）。この場合、図２３に示す残り段階はスキップ（ｓｋｉｐ）される。

なお、ＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ−Ｂが上記のようにＰｒｏｘｉｍｉｔｙ Ｒｅｑｕｅｓｔ ｐｒｏｃｅｄｕｒｅを中断し、ＵＥ−ＡにＰｒｏｘｉｍｉｔｙ Ｒｅｑｕｅｓｔ Ｒｅｊｅｃｔメッセージを送ることを決定する様々なシナリオを次のように考慮することができる。しかし、これに限定されず、ＰｒｏＳｅ Ｆｕｎｃｔｉｏｎは様々な決定基準（例、段階１でＵＥ−Ａから受信したｄｉｓｃｏｖｅｒｙ ｒａｎｇｅ ｃｌａｓｓ情報など）に基づいて上記に対する決定を行うこともできる：
− シナリオＡ）図２３の段階１で受信した区間パラメータ（ｗｉｎｄｏｗ ｐａｒａｍｅｔｅｒ）値が大きい場合又は相対的に大きい場合であり：
Ａ−１）ＵＥ−ＡとＵＥ−Ｂとの距離が遠い場合又は相対的に遠い場合
Ａ−２）ＵＥ−ＡとＵＥ−Ｂが異なる大陸に位置している場合
Ａ−３）ＵＥ−ＡとＵＥ−Ｂが異なる国に位置している場合
Ａ−４）ＵＥ−ＡとＵＥ−Ｂが、互いに遠く離れている（又は、隣接していない）国に位置している場合：
上記Ａ−１）乃至Ａ−４）のいずれかの場合において、ＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ−Ｂは、両ＵＥが時間区間（ｔｉｍｅ ｗｉｎｄｏｗ）内に近接する可能性が小さいと判断し、Ｐｒｏｘｉｍｉｔｙ Ｒｅｑｕｅｓｔ ｐｒｏｃｅｄｕｒｅを中断し、ＵＥ−ＡにＰｒｏｘｉｍｉｔｙ Ｒｅｑｕｅｓｔ Ｒｅｊｅｃｔメッセージを送ることを決定する。これによって、長い時間に余計にＵＥ−Ａ及びＵＥ−Ｂの位置を把握しなければならないことに伴うシグナリング及びＵＥ電力消耗を低減することができる。
−シナリオＢ）図２３の段階１で受信した区間パラメータ（ｗｉｎｄｏｗ ｐａｒａｍｅｔｅｒ）値が小さな場合又は相対的に小さい場合であり：
Ｂ−１）ＵＥ−ＡとＵＥ−Ｂとの距離が遠い場合又は相対的に遠い場合
Ｂ−２）ＵＥ−ＡとＵＥ−Ｂが異なる大陸に位置している場合
Ｂ−３）ＵＥ−ＡとＵＥ−Ｂが異なる国に位置している場合
Ｂ−４）ＵＥ−ＡとＵＥ−Ｂが、互いに遠く離れている（又は、隣接していない）国に位置している場合
Ｂ−５）ＵＥ−ＡとＵＥ−Ｂが異なるＭＭＥによってサービス（ｓｅｒｖｅ）されている場合
Ｂ−６）ＵＥ−ＡとＵＥ−Ｂが遠く離れてはいないが、区間パラメータ（ｗｉｎｄｏｗ ｐａｒａｍｅｔｅｒ）値を基準にしては遠い場合：
上記Ｂ−１）乃至Ｂ−６）のいずれかの場合において、ＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ−Ｂは、両ＵＥが時間区間（ｔｉｍｅ ｗｉｎｄｏｗ）内に近接する可能性が小さいと判断し、Ｐｒｏｘｉｍｉｔｙ Ｒｅｑｕｅｓｔ ｐｒｏｃｅｄｕｒｅを中断し、ＵＥ−ＡにＰｒｏｘｉｍｉｔｙ Ｒｅｑｕｅｓｔ Ｒｅｊｅｃｔメッセージを送ることを決定する。これによって、短い時間に近接関係を決定する／知らせるサービスをするために余計にＵＥ−Ａ及びＵＥ−Ｂの位置を把握しなければならないことに伴う作業上のオーバーヘッド（すなわち、ただ数回の位置情報を把握するために多数のネットワークノード及びＵＥにシグナル／メッセージを送信するなど）を減らすことができる。

図２３の段階６で、ＵＥ−ＢのＰｒｏＳｅプロファイルによって、ＵＥ−Ｂは、近接要請（ｐｒｏｘｉｍｉｔｙ ｒｅｑｕｅｓｔ、例えば、ｕｓｅｒ−Ｂが一時的にＵＥ−ＢのＰｒｏＳｅ Ｆｕｎｃｔｉｏｎを非活性化したかもしれない）のための許可（ｐｅｒｍｉｓｓｉｏｎ）を確認するための要請を受けることができる。

図２３の段階７で、ＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ−ＢがＳＬＰ（ＳＵＰＬ Ｌｏｃａｔｉｏｎ Ｐｌａｔｆｏｒｍ）−ＢにＵＥ−Ｂ上の位置報告を要請し、ＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ−Ａに近接要請（ｐｒｏｘｉｍｉｔｙ ｒｅｑｕｅｓｔ）を受信したことを知らせ（ａｃｋｎｏｗｌｅｄｇｅ）、（仮に知っていると）ＵＥ−Ｂの現在位置を提供する。この時、図２３の段階１でＵＥ−ＡがＷＬＡＮ直接探索及び通信のためのＥＰＣ支援を要請した場合であり、ＵＥ−Ｂが永久的な（ｐｅｒｍａｎｅｎｔ）ＷＬＡＮリンクレイヤＩＤを使用する場合であれば、ＵＥ−ＢのＷＬＡＮリンクレイヤＩＤ（すなわち、ＷＬＬＩＤ＿Ｂ）が含まれてもよい。

図２３の段階８で、ＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ−ＡはＳＬＰ−ＡにＵＥ−Ａ上の位置報告を要請する。仮に、ＵＥ−Ａの現在位置が利用可能（ａｖａｉｌａｂｌｅ）であり、ＵＥ−Ｂの位置が図２３の段階７で含まれた場合、仮に要請された時間区間（ｔｉｍｅ ｗｉｎｄｏｗ）内にユーザ（すなわち、ユーザＡとユーザＢ、又はＵＥ−ＡとＵＥ−Ｂ）が近接関係に設定されない（又は、近接関係に置かれない）と判断される場合には、ＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ−ＡはＰｒｏｘｉｍｉｔｙ Ｒｅｑｕｅｓｔ ｐｒｏｃｅｄｕｒｅを取り消すことを決定することができる。そうでないと、ＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ−ＡはＵＥ−Ａにｐｒｏｘｉｍｉｔｙ ｒｅｑｕｅｓｔを受信したことを知らせる（ａｃｋｎｏｗｌｅｄｇｅｓ）。

この段階、すなわち、図２３の段階８における、ＵＥ−Ａ及びＵＥ−Ｂに対する位置情報内容、ＰｒｏＳｅ Ｆｕｎｃｔｉｏｎが両ＵＥ間の距離情報／近接関係を決定する内容、そしてＰｒｏＳｅ Ｆｕｎｃｔｉｏｎが時間区間パラメータ（ｔｉｍｅ ｗｉｎｄｏｗ ｐａｒａｍｅｔｅｒ）値に基づいてＰｒｏｘｉｍｉｔｙ Ｒｅｑｕｅｓｔ ｐｒｏｃｅｄｕｒｅを取り消す（ｃａｎｃｅｌ）動作に関する内容は、上述した段階５の内容を同一に適用することが可能である。

４−２． Ｐｒｏｘｉｍｉｔｙ Ａｌｅｒｔ

図２４を参照して、本発明に係るＰｒｏｘｉｍｉｔｙ Ａｌｅｒｔについて説明する。

まず、図２４の段階１乃至段階３で、ＵＥ−Ｂの位置がＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ−Ｂに報告され、ＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ−ＢはこれをＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ−Ａにフォワードする。

図２４の段階４で、ＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ−Ａは、要請されたｄｉｓｃｏｖｅｒｙ ｒａｎｇｅ ｃｌａｓｓに基づいて両ＵＥの近接関係を検出し、ＵＥ−ＡにＰｒｏｘｉｍｉｔｙ Ａｌｅｒｔメッセージを送信してそれを知らせる。ここで、Ｐｒｏｘｉｍｉｔｙ Ａｌｅｒｔメッセージは、例えば、「Ｐｒｏｘｉｍｉｔｙ Ａｌｅｒｔ（ＡＬＵＩＤ＿Ｂ、Ａｓｓｉｓｔａｎｃｅ Ｉｎｆｏｒｍａｔｉｏｎ）」のように、ＡＬＵＩＤ及びＡｓｓｉｓｔａｎｃｅ Ｉｎｆｏｒｍａｔｉｏｎを含むことができる。ここで、ＡＬＵＩＤは、ユーザのアプリケーション層ユーザＩＤであり、ＡＬＵＩＤ＿Ｂは、ユーザＢのアプリケーション層ユーザＩＤを表す。また、Ｐｒｏｘｉｍｉｔｙ Ａｌｅｒｔメッセージは、ＵＥ−ＢとのＷＬＡＮ直接探索及び通信のためのＡｓｓｉｓｔａｎｃｅ Ｉｎｆｏｒｍａｔｉｏｎをさらに含むことができる。なお、ＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ−Ａは、ＳＬＰ−ＡからＵＥ−Ａ上の位置報告を取り消すことができる。

図２４の段階５で、ＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ−ＡはＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ−ＢにＰｒｏｘｉｍｉｔｙ Ａｌｅｒｔメッセージ（例えば、Ｐｒｏｘｉｍｉｔｙ Ａｌｅｒｔ（ＡＬＵＩＤ＿Ａ、Ａｓｓｉｓｔａｎｃｅ Ｉｎｆｏｒｍａｔｉｏｎ）のような形態）をＵＥ−Ｂに送信することを要請することができる。ここで、ＡＬＵＩＤ＿Ａは、ユーザＡのアプリケーション層ユーザＩＤを示す。また、Ｐｒｏｘｉｍｉｔｙ Ａｌｅｒｔメッセージは、ＵＥ−ＢとのＷＬＡＮ直接探索及び通信のためのＡｓｓｉｓｔａｎｃｅ Ｉｎｆｏｒｍａｔｉｏｎをさらに含むことができる。なお、ＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ−ＢはＳＬＡ−ＢからＵＥ−Ｂ上の位置報告を取り消すことができる。

以上において、ＵＥのＷＬＡＮインターフェースは、図２４の段階６以前にはターン−オン（ｔｕｒｎ ｏｎ）される必要がない。

また、上述した実施例で、ａｓｓｉｓｔａｎｃｅ ｉｎｆｏｒｍａｔｉｏｎは、ＷＬＡＮ直接探索及び通信を速かに処理するために設定される。ａｓｓｉｓｔａｎｃｅ ｉｎｆｏｒｍａｔｉｏｎの内容は、ＷＬＡＮ直接リンク（ＷＬＡＮ ｄｉｒｅｃｔ ｌｉｎｋ）で用いられる技術にしたがう。また、ＵＥ−Ｂが永久的なＷＬＡＮリンクレイヤＩＤ（ＷＬＬＩＤ）のみを支援する場合には、ＷＬＬＩＤ＿Ｂ以外の、ａｓｓｉｓｔａｎｃｅ ｉｎｆｏｒｍａｔｉｏｎの全ての内容は、ＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ−Ａによって動的に生成することができる。

４−３． Ｐｒｏｘｉｍｉｔｙ Ｒｅｑｕｅｓｔ Ｃａｎｃｅｌｌａｔｉｏｎ

図２５を参照して、本発明に係るＰｒｏｘｉｍｉｔｙ Ｒｅｑｕｅｓｔ Ｃａｎｃｅｌｌａｔｉｏｎについて説明する。

図２５の段階１で、ＵＥ−ＡはＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ−ＡにＣａｎｃｅｌ Ｐｒｏｘｉｍｉｔｙ Ｒｅｑｕｅｓｔを送信する。Ｃａｎｃｅｌ Ｐｒｏｘｉｍｉｔｙ Ｒｅｑｕｅｓｔには、ＥＰＵＩＤ、アプリケーション識別子（ａｐｐｌｉｃａｔｉｏｎ ＩＤ）、ＡＬＵＩＤ（例えば、Ｃａｎｃｅｌ Ｐｒｏｘｉｍｉｔｙ Ｒｅｑｕｅｓｔ（ＥＰＵＩＤ＿Ａ、Ａｐｐｌｉｃａｔｉｏｎ ＩＤ、ＡＬＵＩＤ＿Ｂ）のような形態）を含めることができる。

図２５の段階２で、Ｐｒｏｓｅ Ｆｕｎｃｔｉｏｎ−Ａは、記憶しているＰＦＩＤ＿Ｂ情報に基づいてＣａｎｃｅｌ Ｐｒｏｘｉｍｉｔｙ ＲｅｑｕｅｓｔメッセージをＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ−Ｂに送信する。ここで、Ｃａｎｃｅｌ Ｐｒｏｘｉｍｉｔｙ ＲｅｑｕｅｓｔメッセージはＥＰＵＩＤを含むことができ、例えば、Ｃａｎｃｅｌ Ｐｒｏｘｉｍｉｔｙ Ｒｅｑｕｅｓｔ（ＥＰＵＩＤ＿Ｂ、ＥＰＵＩＤ＿Ａ）のような形態であってもよい。

図２５の段階３で、Ｐｒｏｓｅ Ｆｕｎｃｔｉｏｎ−Ａは、ＳＬＰ−ＡからＵＥ−Ａ上の位置報告を取り消す。

図２５の段階４及び段階５で、Ｐｒｏｓｅ Ｆｕｎｃｔｉｏｎ−Ｂは、ＳＬＰ−ＢからＵＥ−Ｂ上の位置報告を取り消し、ＰｒｏＳｅ−Ａにｐｒｏｘｉｍｉｔｙ ｒｅｑｕｅｓｔ ｃａｎｃｅｌｌａｔｉｏｎを確認したことを知らせる（ａｃｋｎｏｗｌｅｄｇｅｓ）。

図２５の段階６で、ＰｒｏＳｅ Ｆｕｎｃｔｉｏｎ−ＡはＵＥ−Ａにｐｒｏｘｉｍｉｔｙ ｒｅｑｕｅｓｔ ｃａｎｃｅｌｌａｔｉｏｎを確認したことを知らせる（ａｃｋｎｏｗｌｅｄｇｅｓ）。

なお、上述した各実施例は一つの実施の形態として用いられてもよいが、上述した様々な実施例の全て或いは一部の組み合わされた形態で実施される場合も、本発明の実施例として解釈しなければならない。

また、上述した実施例において、ＵＥ又はネットワークノードが他のＵＥの位置情報を要請する時に、ＵＥの識別子及び／又はＰｒｏＳｅ Ｄｉｓｃｏｖｅｒｙ／ＰｒｏＳｅ通信／ＰｒｏＳｅ動作と関連したアプリケーションに関する識別子情報を含むこともできる。これは、他のＵＥとの近接関係の確認を要請するＵＥ及びその対象となるＵＥのいずれか一方に該当してもよく、両方に該当してもよい。

なお、本発明で、ＰｒｏＳｅサーバーはＰｒｏＳｅ Ｆｕｎｃｔｉｏｎと解釈してもよい。

図２６は、本発明の好適な実施例に係る端末装置及びネットワークノード装置の構成を示す図である。

図２６を参照すると、本発明に係る端末装置１００は、送受信モジュール１１０、プロセッサ１２０及びメモリ１３０を備えることができる。送受信モジュール１１０は、外部装置に各種の信号、データ及び情報を送信し、外部装置から各種の信号、データ及び情報を受信するように構成することができる。端末装置１００は、外部装置と有線及び／又は無線で接続されてもよい。プロセッサ１２０は、端末装置１００の動作全般を制御し、端末装置１００が外部装置と送受信する情報などを演算処理する機能を果たすように構成することができる。メモリ１３０は、演算処理された情報などを所定の時間記憶することができ、バッファー（図示せず）などの構成要素に取って代わってもよい。

本発明の一実施例に係る端末装置１００は、ネットワークによって開始されるＰｒｏＳｅ可能か否かの検出又はＰｒｏＳｅ端末探索の結果によってＰｒｏＳｅに参加できるように構成することができる。端末装置１００のプロセッサ１２０は、送受信モジュール１１０を用いてネットワークノード２００にＰｒｏＳｅ基礎情報を送信するように構成することができる。プロセッサ１２０は、送受信モジュール１１０を用いて、ネットワークノード２００からＰｒｏＳｅを許容するか否かを示す情報を受信するように構成されてもよい。プロセッサ１２０は、他の端末装置との直接データ経路セットアップを行うためのシグナリングを処理するように構成されてもよい。プロセッサ１２０は、送受信モジュール１１０を用いて上記他の端末装置との直接通信を行うように構成されてもよい。プロセッサ１２０は、送受信モジュール１１０を用いてネットワークノード装置２００にＰｒｏＳｅ実行関連結果情報を送信するように構成されてもよい。

図２６を参照すると、本発明に係るネットワークノード装置２００は、送受信モジュール２１０、プロセッサ２２０及びメモリ２３０を備えることができる。送受信モジュール２１０は、外部装置に各種の信号、データ及び情報を送信し、外部装置から各種の信号、データ及び情報を受信するように構成することができる。ネットワークノード装置２００は、外部装置と有線及び／又は無線で接続されてもよい。プロセッサ２２０は、ネットワークノード装置２００の動作全般を制御し、ネットワークノード装置２００が外部装置と送受信する情報などを演算処理する機能を果たすように構成することができる。メモリ２３０は、演算処理された情報などを所定の時間記憶することができ、バッファー（図示せず）などの構成要素に取って代わってもよい。

本発明の一実施例に係るネットワークノード装置２００は、複数の端末間のＰｒｏＳｅを支援するように構成することができる。ネットワークノード装置２００のプロセッサ２２０は、送受信モジュール２１０を用いて端末装置１００又は他のネットワークノード装置からＰｒｏＳｅ基礎情報を受信するように構成することができる。プロセッサ１２０は、送受信モジュール２１０を用いて、端末装置１００にＰｒｏＳｅを許容するか否かを示す情報を送信するように構成されてもよい。プロセッサ２２０は、端末装置１００が他の端末装置と直接データ経路セットアップを行うことを支援するシグナリングを処理するように構成されてもよい。プロセッサ２２０は、送受信モジュール２１０を用いて端末装置１００からＰｒｏＳｅ実行関連結果情報を受信するように構成されてもよい。

また、上記のような端末装置１００及びネットワーク装置２００の具体的な構成は、前述した本発明の様々な実施例で説明した事項が独立して適用されたり、又は２つ以上の実施例が同時に適用されるように具現されてもよく、重複する内容は明確性のために説明を省略する。

上述した本発明の実施例は、様々な手段によって具現することができる。例えば、本発明の実施例は、ハードウェア、ファームウェア（ｆｉｒｍｗａｒｅ）、ソフトウェア又はそれらの結合などによって具現することができる。

ハードウェアによる具現の場合、本発明の実施例に係る方法は、一つ又はそれ以上のＡＳＩＣｓ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔｓ）、ＤＳＰｓ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒｓ）、ＤＳＰＤｓ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｄｅｖｉｃｅｓ）、ＰＬＤｓ（Ｐｒｏｇｒａｍｍａｂｌｅ Ｌｏｇｉｃ Ｄｅｖｉｃｅｓ）、ＦＰＧＡｓ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙｓ）、プロセッサ、コントローラ、マイクロコントローラ、マイクロプロセッサなどによって具現することができる。

ファームウェアやソフトウェアによる具現の場合、本発明の実施例に係る方法は、以上で説明した機能又は動作を行うモジュール、手順又は関数などの形態として具現することができる。ソフトウェアコードはメモリユニットに記憶され、プロセッサによって駆動されてもよい。メモリユニットは、プロセッサの内部又は外部に設けられ、既に公知の様々な手段によってプロセッサとデータを授受することができる。

以上開示された本発明の好適な実施例に関する詳細な説明は、当業者が本発明を具現して実施できるように提供されている。以上では本発明の好適な実施例を参照して説明したが、当該技術の分野における熟練した当業者にとっては、本発明の領域から逸脱しない範囲内で本発明を様々に修正及び変更可能であることは明らかである。例えば、当業者は、上述した実施例に記載された各構成を組み合わせる方式で用いることができる。したがって、本発明は、ここに表された実施の形態に制限しようとするものではなく、ここに開示された原理及び新規な特徴と一致する最も広い範囲を与えようとするものである。

本発明は、本発明の精神及び必須特徴から逸脱ない範囲で他の特定の形態として具体化してもよい。したがって、上記の詳細な説明は、いずれの面においても制限的に解釈してはならず、例示的なものとして考慮しなければならない。本発明の範囲は、添付された請求項の合理的解釈によって決定しなければならず、本発明の等価的範囲内における変更はいずれも本発明の範囲に含まれる。本発明は、ここに表された実施の形態に制限しようとするものではなく、ここに開示された原理及び新規な特徴と一致する最も広い範囲を与えようとするものである。また、特許請求の範囲で明示的な引用関係を有しない請求項を結合して実施例を構成してもよく、出願後の補正によって新しい請求項として含めてもよい。

上述したような本発明の実施の形態は、様々な移動通信システムに適用することができる。

Claims (15)

1. 無線通信システムにおいて第１端末の近接サービス（ＰｒｏＳｅ）を行う方法であって、
   前記第１端末が第１ネットワークエンティティにＰｒｏＳｅ探索要請を送信するステップと、
   前記第１ネットワークエンティティから、ＰｒｏＳｅ探索応答を受信するステップと、
   を有し
   前記ＰｒｏＳｅ探索応答は、前記第１端末と第２端末とがあらかじめ決定された時間区間に近接関係が設定されないと判断される場合、前記ＰｒｏＳｅの拒絶を示すことを特徴とする、近接サービス実行方法。
2. 前記近接関係は、ＨＳＳを介して受信された位置情報に基づいて判断される、請求項１に記載の近接サービス実行方法。
3. 前記位置情報は、前記ＨＳＳに予め記憶された位置情報であるか、ＭＭＥによって送信された位置情報である、請求項２に記載の近接サービス実行方法。
4. 前記位置情報は、前記第１端末或いは前記第２端末のうち少なくとも一つの位置情報である、請求項２に記載の近接サービス実行方法。
5. 前記近接関係は、前記第１端末と前記第２端末が、所定の距離以上で位置する場合に、近接関係が設定されないと判断される、請求項１に記載の近接サービス実行方法。
6. 前記所定の距離は、前記第１端末と前記第２端末間の実際距離値、或いは前記第１端末と前記第２端末間の距離類推のための情報である、請求項５に記載の近接サービス実行方法。
7. 前記所定の距離は、予め設定されるか、又は第２ネットワークエンティティから取得される、請求項６に記載の近接サービス実行方法。
8. 前記ＰｒｏＳｅの拒絶は、近接関係確認、近接関係要請手順、位置報告手順、或いはＰｒｏＳｅ探索のいずれかの手順を行わないことを示す、請求項１に記載の近接サービス実行方法。
9. 前記ＰｒｏＳｅ探索応答は、前記第１端末と前記第２端末が近接関係にあるか否かに関する情報、前記第１端末と前記第２端末が近接関係になるか否かに関する情報、又は前記第１端末と前記第２端末間の距離に関する情報のうち少なくとも一つをさらに含む、請求項１に記載の近接サービス実行方法。
10. 前記予め決定された時間区間は、前記ＰｒｏＳｅ探索要請に含まれて、送信される、請求項１に記載の近接サービス実行方法。
11. 前記ＰｒｏＳｅ探索応答は、前記第１ネットワークエンティティによって決定され、
    前記第１ネットワークエンティティは、ＰｒｏＳｅサーバー又はＰｒｏＳｅ Ｆｕｎｃｔｉｏｎである、請求項１に記載の近接サービス実行方法。
12. 前記近接関係は、前記第１端末と前記第２端末間の最初の近接関係の判断時に決定される、請求項１に記載の近接サービス実行方法。
13. 無線通信システムにおいて第１ネットワークエンティティの近接サービス（ＰｒｏＳｅ）を支援する方法であって、
    前記第１ネットワークエンティティが第１端末からＰｒｏＳｅ探索要請を受信するステップと、
    前記第１ネットワークエンティティから前記第１端末に、ＰｒｏＳｅ探索応答を送信するステップと、
    を有し
    前記ＰｒｏＳｅ探索応答は、前記第１端末と第２端末とが予め決定された時間区間に近接関係が設定されないと判断される場合、前記ＰｒｏＳｅの拒絶を示すことを特徴とする、近接サービス支援方法。
14. 無線通信システムにおいて近接サービス（ＰｒｏＳｅ）を行う第１端末であって、
    無線周波数ユニットと、
    プロセッサと、
    を備え、
    前記プロセッサは、前記第１端末が第１ネットワークエンティティにＰｒｏＳｅ探索要請を送信し、前記第１ネットワークエンティティから、ＰｒｏＳｅ探索応答を受信するように構成され、
    前記ＰｒｏＳｅ探索応答は、前記第１端末と第２端末とが予め決定された時間区間に近接関係が設定されないと判断される場合、前記ＰｒｏＳｅの拒絶を示すことを特徴とする、第１端末。
15. 無線通信システムにおいて近接サービス（ＰｒｏＳｅ）を支援する第１ネットワークエンティティであって、
    無線周波数ユニットと、
    プロセッサと、
    を備え、
    前記プロセッサは、第１端末からＰｒｏＳｅ探索要請を受信し、前記第１端末にＰｒｏＳｅ探索応答を送信するように構成され、
    前記ＰｒｏＳｅ探索応答は、前記第１端末と第２端末とが予め決定された時間区間に近接関係が設定されないと判断される場合、前記ＰｒｏＳｅの拒絶を示すことを特徴とする、第１ネットワークエンティティ。

Images