WO2015005158A1

WO2015005158A1 - 通信制御方法、端末装置および基地局装置

Info

Publication number: WO2015005158A1
Application number: PCT/JP2014/067356
Authority: WO
Inventors: 政幸榎本; 真史新本
Original assignee: シャープ株式会社
Priority date: 2013-07-09
Filing date: 2014-06-30
Publication date: 2015-01-15
Also published as: CN105359621A; JPWO2015005158A1; US20160143080A1

Abstract

　第1の端末装置と、前記第１の端末装置の近隣に位置する第２の端末装置が直接通信路を確立するための第１の端末装置における通信制御方法であって、前記第２の端末装置が送信する、近隣の端末装置に前記第２の端末装置を検出させるための信号をモニタリングするステップと、前記信号を受信して前記第２の端末装置が近隣に位置することを検出するステップと、前記信号に含まれる前記第２の端末装置がＬＴＥ基地局に在圏するか否かを示すカバレッジ情報を取得するステップと、前記カバレッジ情報に基づいて前記第２の端末装置が在圏しているか否かを検出するステップと、を備える。

Description

通信制御方法、端末装置および基地局装置

　本発明は、通信制御方法と、端末装置と、基地局装置とを含む移動通信システムに関する。
　本願は、２０１３年７月９日に、日本に出願された特願２０１３－１４３４２５号に基づき優先権を主張し、その内容をここに援用する。

　移動通信システムの標準化団体３ＧＰＰ（Ｔｈｅ　３ｒｄ　Ｇｅｎｅｒａｔｉｏｎ　Ｐａｒｔｎｅｒｓｈｉｐ　Ｐｒｏｊｅｃｔ）では、次世代の移動体通信システムとして以下の非特許文献１に記載のＥＰＳ（Ｅｖｏｌｖｅｄ　Ｐａｃｋｅｔ　Ｓｙｓｔｅｍ）の仕様化作業を進めており、ＥＰＳに接続されるアクセスシステムとしてＬＴＥ（Ｌｏｎｇ　Ｔｅｒｍ　Ｅｖｏｌｕｔｉｏｎ）だけでなく、無線ＬＡＮ（Ｗｉｒｅｌｅｓｓ　ＬＡＮ、ＷＬＡＮ)について検討がなされている。

　さらに、３ＧＰＰでは、非特許文献2に記載されるように、ＵＥユーザ端末（Ｕｓｅｒ　Ｅｑｕｉｐｍｅｎｔ,　ＵＥ）間が近隣にいることを検出したり、近隣ＵＥ間で直接通信路を確立して通信を行うなどの近隣サービス（Ｐｒｏｘｉｍｉｔｙ－ｂａｓｅｄ　Ｓｅｒｖｉｃｅ、ＰｒｏＳｅ）について検討が行われている。ここで、ＰｒｏＳｅにおけるＵＥ間の直接通信路とは、従来のＵＥの通信路はＵＥが接続する基地局を介し、さらに基地局が接続するコアネットワークを介して確立されていたのに対し、近隣ＵＥ間で基地局やコアネットワークを介すことなく直接データの送受信を行うことができる通信路である。

　ＰｒｏＳｅでは、ＬＴＥ基地局やＷＬＡＮ基地局を含むアクセスネットワークや、アクセスネットワークが接続されているコアネットワークを介すことなく通信を行えることから、アクセスネットワークやコアネットワークのトラヒックの集中を回避（コンジェッション回避）のオフロード効果も期待することができる。

　ＰｒｏＳｅでは、ＵＥ間の直接通信路として２つの方式を利用することが検討されている。一つは、ＬＴＥアクセス技術を用いたＵＥ間の直接通信路を確立する方法（以下　ＬＴＥ　Ｄｉｒｅｃｔ）であり、もうひとつは、無線ＬＡＮ（Ｗｉｒｅｌｅｓｓ　ＬＡＮ）アクセス技術を用いて直接通信路を確立する方法である。

　また、ＰｒｏＳｅでは、ＵＥは、ＬＴＥ　Ｄｉｒｅｃｔまたは、ＷＬＡＮ　Ｄｉｒｅｃｔによりデータの送受信を行うために、通信対象ＵＥを探索し、近隣に通信対象ＵＥの存在を検知する必要性がサービス要求条件として挙げられている。

　さらに、ＵＥ間直接通信は移動通信事業者によって提供するサービスとするために、通信対象ＵＥを探索するにあたっては、移動通信事業者による承認が必要と規定されている。

　このように、ＰｒｏＳｅにおいては、近隣ＵＥの検出と、近隣ＵＥ間に直接通信路を確立して通信を行うこととを提供する通信サービスの規定を目的にしている。

　また、ＰｒｏＳｅでは、ｎｏｎ－Ｐｕｂｌｉｃ　ＳａｆｅｔｙとＰｕｂｌｉｃ　Ｓａｆｅｔｙが規定されている。ｎｏｎ－Ｐｕｂｌｉｃ　Ｓａｆｅｔｙでは、移動通信事業者による商用サービスが想定されており、ＵＥがＬＴＥ基地局に在圏している場合にのみ、利用可能である。一方、Ｐｕｂｌｉｃ　Ｓａｆｅｔｙでは、防災無線による利用が想定されており、ＵＥがＬＴＥ基地局に在圏している場合のみならず、ＬＴＥ基地局(ｅＮＢ)に在圏していない場合でも利用することができる。

　つまり、ＬＴＥ　Ｄｉｒｅｃｔでは、商用サービス（ｎｏｎ－Ｐｕｂｌｉｃ　Ｓａｆｅｔｙ）においてＬＴＥの通信方式を利用して、ＵＥ間において直接データの送受信を行う方法と、Ｐｕｂｌｉｃ　ＳａｆｅｔｙにおいてＬＴＥの通信方式を利用して、ＵＥ間において直接データの送受信を行う方法がある。

　また、ＷＬＡＮ　Ｄｉｒｅｃｔでは、商用サービスにおいてＷＬＡＮの通信方式を利用して、ＵＥ間において直接データの送受信を行う方法があり、さらに、Ｐｕｂｌｉｃ　ＳａｆｅｔｙにおいてＷＬＡＮの通信方式を利用して、ＵＥ間において直接データの送受信を行う可能性がある。

３ＧＰＰ　ＴＳ２３．４０１　Ｔｅｃｈｎｉｃａｌ　Ｓｐｅｃｉｆｉｃａｔｉｏｎ　Ｇｒｏｕｐ　Ｓｅｒｖｉｃｅｓ　ａｎｄ　Ｓｙｓｔｅｍ　Ａｓｐｅｃｔｓ,　Ｇｅｎｅｒａｌ　Ｐａｃｋｅｔ　Ｒａｄｉｏ　Ｓｅｒｖｉｃｅ（ＧＰＲＳ）　ｅｎｈａｎｃｅｍｅｎｔｓ　ｆｏｒ　Ｅｖｏｌｖｅｄ　Ｕｎｉｖｅｒｓａｌ　Ｔｅｒｒｅｓｔｒｉａｌ　Ｒａｄｉｏ　Ａｃｃｅｓｓ　Ｎｅｔｗｏｒｋ（ｅ－ＵＴＲＡＮ）　ａｃｃｅｓｓ３ＧＰＰ　ＴＲ２２．８０３　Ｔｅｃｈｎｉｃａｌ　Ｓｐｅｃｉｆｉｃａｔｉｏｎ　Ｇｒｏｕｐ　Ｓｅｒｖｉｃｅｓ　ａｎｄ　Ｓｙｓｔｅｍ　Ａｓｐｅｃｔｓ,　Ｆｅａｓｉｂｉｌｉｔｙ　ｓｔｕｄｙ　ｆｏｒ　Ｐｒｏｘｉｍｉｔｙ　Ｓｅｒｖｉｃｅｓ（ＰｒｏＳｅ）

　ｎｏｎ－Ｐｕｂｌｉｃ　Ｓａｆｅｔｙ利用の判断には、通信元ＵＥおよび、通信先ＵＥがＬＴＥ基地局に在圏していることを検出することが必要になる。また、Ｐｕｂｌｉｃ　Ｓａｆｅｔｙの利用の判断には、通信元ＵＥまたは、通信先ＵＥがＬＴＥ基地局に在圏していないことを検出することが必要である。さらに、ｎｏｎ－Ｐｕｂｌｉｃ　Ｓａｆｅｔｙでは、通信元ＵＥおよび通信先ＵＥがｅＮＢに在圏している場合にのみ利用可能であることから、通信路確立手続きは、ネットワークの認証の基、通信路確立が行われることが検討されている。一方、Ｐｕｂｌｉｃ　Ｓａｆｅｔｙでは、通信元ＵＥまたは、通信先ＵＥがｅＮＢに在圏していない場合に利用可能であることから、通信確立の度にネットワークから認証を受けない、通信路確立手続きが、検討されている。このように、ｎｏｎ－Ｐｕｂｌｉｃ　Ｓａｆｅｔｙにおける通信路確立手続きおよびＰｕｂｌｉｃ　Ｓａｆｅｔｙにおける通信路確立では、異なる手続きが利用されることが検討されている。

　ここで、ＵＥがＬＴＥ基地局に在圏していることを検出するというのは、通信元ＵＥがＬＴＥ基地局に在圏していることと、通信先ＵＥがＬＴＥ基地局に在圏していることを検出する必要がある。なお、通信元ＵＥは、ＬＴＥ基地局に在圏している場合と、ＬＴＥ基地局に在圏していない場合あり、通信先ＵＥは、ＬＴＥ基地局に在圏している場合と、ＬＴＥ基地局に在圏していない場合がある。つまり、通信元ＵＥと通信先ＵＥとの状態は、通信元ＵＥがＬＴＥ基地局に在圏し、通信先ＵＥがＬＴＥ基地局に在圏する場合の１状態と、通信元ＵＥがＬＴＥ基地局に在圏せず、通信先ＵＥがＬＴＥ基地局に在圏する場合の１状態と、通信元ＵＥがＬＴＥ基地局に在圏し、通信先ＵＥがＬＴＥ基地局に在圏しない場合の１状態と、通信元ＵＥがＬＴＥ基地局に在圏せず、通信先ＵＥがＬＴＥ基地局に在圏しない場合の１状態と、の計４状態へ遷移することとなる。

　このように、通信元ＵＥがＬＴＥ基地局に在圏していることと、通信先ＵＥがＬＴＥ基地局に在圏していることを検出し、上記４状態のいずれに該当するかを検出する必要がある。

　しかしながら、通信元ＵＥがＬＴＥ基地局に在圏していることや通信先ＵＥがＬＴＥ基地局に在圏していることをどのように決定し、決定した通信元ＵＥや通信先ＵＥがＬＴＥ基地局に在圏していることをＵＥがどのようにどのように利用するかはこれまで明らかにされていない。

　より具体的には、通信元ＵＥや通信先ＵＥがＬＴＥ基地局に在圏していることを検出する方法や、通信元ＵＥまたは通信先ＵＥがＬＴＥ基地局に在圏していることを示す情報の利用方法などが明らかでなかった。こうした課題に対して具体的な実現手段ないために、通信元ＵＥおよび通信先ＵＥ間で直接通信のための通信路確立手続きを開始することができず、ＰｒｏＳｅサービスを利用することができなかった。

　また、通信元ＵＥがＬＴＥ基地局に在圏し、通信先ＵＥがＬＴＥ基地局に在圏する場合、通信元ＵＥおよび通信先ＵＥはネットワーク認証の基、通信路確立手続きを行うことができなかった。さらに、通信元ＵＥがＬＴＥ基地局に在圏せず、通信先ＵＥがＬＴＥ基地局に在圏する場合、通信元ＵＥおよび通信先ＵＥはネットワーク認証の基、通信路確立手続きを行うことができなかった。また、通信元ＵＥがＬＴＥ基地局に在圏し、通信先ＵＥがＬＴＥ基地局に在圏しない場合、通信元ＵＥおよび通信先ＵＥはネットワーク認証の基、通信路確立手続きを行うことができなかった。さらに、通信元ＵＥがＬＴＥ基地局に在圏せず、通信先ＵＥがＬＴＥ基地局に在圏しない場合、通信元ＵＥおよび通信先ＵＥは、通信路確立の度に、ネットワークから認証を受けずに通信路確立手続きを行うことができなかった。

　本発明は、このような点を鑑みてなされたもので、ＰｒｏＳｅにおけるＬＴＥ基地局に在圏していることを検出し、ＵＥはこうしたＬＴＥに在圏していること示す情報を利用することを目的とした移動通信システム等を提供することである。

　この発明は上述した課題を解決するためになされたもので、本発明の第１態様は、第１の端末装置と、前記第１の端末装置の近隣に位置する第２の端末装置が直接通信路を確立するための第１の端末装置における通信制御方法であって、前記第２の端末装置が送信する、近隣の端末装置に前記第２の端末装置を検出させるための信号をモニタリングするステップと、前記信号を受信して前記第２の端末装置が近隣に位置することを検出するステップと、前記信号に含まれる前記第２の端末装置がＬＴＥ基地局に在圏するか否かを示すカバレッジ情報を取得するステップと、前記カバレッジ情報に基づいて前記第２の端末装置が在圏しているか否かを検出するステップとを備える通信制御方法である。

　また、本発明の第２の態様は、上述の第１の態様に記載の通信制御方法において、前記カバレッジ情報に基づいて前記第２の端末装置が在圏することを検出した場合には、直接通信路に対するリソースの取得を要求する情報を含めて、直接通信路の確立要求を前記第２の端末装置に送信するステップをさらに備える通信制御方法である。

　また、本発明の第３の態様は、上述の第１の態様に記載の通信制御方法において、前記カバレッジ情報に基づいて前記第２の端末装置が在圏していないことを検出した場合には、直接通信路の確立要求を前記第２の端末装置に送信するステップと直接通信路に対するリソースの要求をＬＴＥ基地局に送信するステップとをさらに備える通信制御方法である。

　また、本発明の第４の態様は、上述の第１の態様に記載の通信制御方法において、前記カバレッジ情報に基づいて前記第２の端末装置が在圏していないことを検出した場合には、直接通信路の確立要求を前記第２の端末装置に送信するステップと直接通信路に対するリソースの要求を在圏するＬＴＥ基地局が接続するコアネットワークに送信するステップとをさらに備える通信制御方法である。

　また、本発明の第５の態様は、上述の第１の態様に記載の通信制御方法において、前記第１の通信端末がＬＴＥ基地局に在圏するか否かを検出するステップをさらに備え、前記第１の通信端末および前記第２の端末装置がともに在圏していないことを検出した場合には、予め第１の端末装置が保持するリソースを直接通信路に割り当てるステップと、前記リソースに関する情報を含めて、直接通信路の確立要求を前記第２の端末装置に送信するステップを備える通信制御方法である。

　また、本発明の第６の態様は、上述の第１の態様から第５の態様のいずれか１つに記載の通信制御方法において、近隣の端末装置に前記第１の端末装置を検出させるための信号を送信するステップをさらに備える通信制御方法である。

　また、本発明の第７の態様は、上述の第１の態様から第６の態様のいずれか１つに記載の通信制御方法において、直接通信路を確立する要求は、ＬＴＥに基づく直接通信路を確立することを要求する通信制御方法である。

　また、本発明の第８の態様は、上述の第１の態様から第６の態様のいずれか１つに記載の通信制御方法において、直接通信路を確立する要求は、無線ＬＡＮに基づく直接通信路を確立することを要求する通信制御方法である。

　また、本発明の第９の態様は、第１の端末装置の近隣に位置する第２の端末装置と直接通信路を確立する第１の端末装置であって、第２の端末装置が送信する、近隣の端末装置に第２の端末装置を検出させるための信号をモニタリングし、前記信号を受信して第２の端末装置が近隣に位置することを検出し、前記信号に含まれる第２の端末装置がＬＴＥ基地局に在圏するか否かを示すカバレッジ情報を取得し、前記カバレッジ情報に基づいて第２の端末装置が在圏しているか否かを検出することを備える端末装置である。

　また、本発明の第１０の態様は、上述の第９の態様に記載の第１の端末装置において、前記カバレッジ情報に基づいて前記第２の端末装置が在圏することを検出した場合には、直接通信路に対するリソースの取得を要求する情報を含めて、直接通信路の確立要求を前記第２の端末装置に送信する端末装置である。

　また、本発明の第１１の態様は、上述の第９の態様に記載の第１の端末装置において、前記カバレッジ情報に基づいて前記第２の端末装置が在圏していないことを検出した場合には、直接通信路の確立要求を前記第２の端末装置に送信し、直接通信路に対するリソースの要求をＬＴＥ基地局に送信する端末装置である。

　また、本発明の第１２の態様は、上述の第９の態様に記載の第１の端末装置において、前記カバレッジ情報に基づいて前記第２の端末装置が在圏していないことを検出した場合には、直接通信路の確立要求を前記第２の端末装置に送信し、直接通信路に対するリソースの要求を在圏するＬＴＥ基地局が接続するコアネットワークに送信する端末装置である。

　また、本発明の第１３の態様は、上述の第９の態様に記載の第１の端末装置において、前記第１の通信端末がＬＴＥ基地局に在圏するか否かを検出し、前記第１の通信端末および前記第２の端末装置がともに在圏していないことを検出した場合には、予め第１の端末装置が保持するリソースを直接通信路に割り当て、前記リソースに関する情報を含めて、直接通信路の確立要求を前記第２の端末装置に送信する端末装置である。

　また、本発明の第１４の態様は、上述の第９の態様から第１３の態様のいずれか１つに記載の第１の端末装置において、近隣の端末装置に前記第１の端末装置を検出させるための信号を送信する。

　また、本発明の第１５の態様は、上述の第９の態様から第１４の態様のいずれか１つに記載の第１の端末装置において、直接通信路を確立する要求は、ＬＴＥに基づく直接通信路を確立することを要求する端末装置である。

　また、本発明の第１６の態様は、上述の第９の態様から第１４の態様のいずれか１つに記載の第１の端末装置において、直接通信路を確立する要求は、無線ＬＡＮに基づく直接通信路を確立することを要求する端末装置である。

　また、本発明の第１７の態様は、ＬＴＥアクセスネットワークに含まれる基地局装置であって、パブリックセーフティを用途とした通信リソースと、商用サービスを用途とした通信リソースとを管理し、端末装置が送信する直接通信路の確立の許可を要求するメッセージに含まれる、パブリックセーフティを用途とした通信路の確立の許可を要求するか、商用サービスを用途とした通信路の確立の許可を要求するかを識別する識別情報に基づいて通信リソースの割り当てを実行し、端末装置に前記リソースに関する情報を前記端末装置に通知する基地局装置である。

　また、本発明の第１８の態様は、上述の第１７の態様に記載の基地局装置において、前記識別情報がパブリックセーフティを用途とした通信路の確立を要求する場合、パブリックセーフティを用途とした通信リソースからリソース割り当てを実行し、前記端末装置にリソースに関する情報を通知する基地局装置である。

　また、本発明の第１９の態様は、上述の第１７の態様に記載の基地局装置において、前記識別情報が商用サービスを用途とした通信路の確立を要求する場合、商用サービスを用途とした通信リソースからリソース割り当てを実行し、前記端末装置にリソースに関する情報を通知する基地局装置である。

　本発明の一態様によれば、通信元ＵＥおよび通信先ＵＥがＬＴＥ基地局に在圏していることを検出することができる。通信元ＵＥまたは通信先ＵＥがＬＴＥ基地局に在圏する場合、移動通信事業者の制御の元、通信路確立手続きを行うことができる。

　また、通信元ＵＥおよび通信先ＵＥがＬＴＥ基地局に在圏しない場合、通信路確立の度に、移動通信事業者の認証を得ることなく、通信路確立手続きを行うことができる。

第１実施形態における移動通信システム１の概要を説明するための図である。ＩＰ移動通信ネットワークの構成を説明するための図である。第１実施形態におけるＵＥの機能構成を説明するための図である。ＵＥの記憶部において管理される機能構成の例を示すための図である。ＰｒｏＳｅサーバの機能構成を説明するための図である。ＰｒｏＳｅサーバの記憶部において管理される機能構成の例を示すための図である。ＡＰＰサーバの機能構成を説明するための図である。ＡＰＰサーバの記憶部において管理される機能構成の例を示すための図である。第１実施形態における近隣検出とカバレッジ情報の通知手続きを説明するための図である。第１実施形態におけるカバレッジ情報の４状態を説明するための図である。第１実施形態における通信路確立手続きを説明するための図である。第１実施形態における通信路確立手続きを説明するための図である。第１実施形態における通信路確立手続きを説明するための図である。第１実施形態における通信路確立手続きを説明するための図である。第１実施形態におけるネットワーク認証手続きを説明するための図である。第１実施形態における直接通信終端側手続きを説明するための図である。第２実施形態における近隣検出とカバレッジ情報の通知手続きを説明するための図である。第３実施形態におけるＵＥの機能構成を説明するための図である。第３実施形態におけるＵＥの記憶部において管理される機能構成の例を示すための図である。第３実施形態におけるＰｒｏＳｅサーバの機能構成を説明するための図である。第３実施形態におけるＰｒｏＳｅサーバの記憶部において管理される機能構成の例を示すための図である。第３実施形態における近隣検出とカバレッジ情報の通知手続きを説明するための図である。第３実施形態における近隣検出とカバレッジ情報の通知手続きを説明するための図である。第３実施形態における近隣検出とカバレッジ情報の通知手続きを説明するための図である。第４実施形態における移動通信システム１の概要を説明するための図である。第４実施形態における近隣検出とカバレッジ情報の通知手続きを説明するための図である。第５実施形態における近隣検出とカバレッジ情報の通知手続きを説明するための図である。

　以下、図面を参照して本発明を実施するための最良の形態について説明する。
　なお、本実施形態では、一例として、本発明を適用した場合の移動通信システムの実施形態について、図を用いて詳細に説明する。なお、ＰｒｏＳｅでは、ｎｏｎ－Ｐｕｂｌｉｃ　ＳａｆｅｔｙとＰｕｂｌｉｃ　Ｓａｆｅｔｙがある。ｎｏｎ－Ｐｕｂｌｉｃ　Ｓａｆｅｔｙでは、移動通信事業者による商用サービスが想定されており、ＵＥがＬＴＥ基地局に在圏している場合にのみ、利用可能である。一方、Ｐｕｂｌｉｃ　Ｓａｆｅｔｙでは、防災無線による利用が想定されており、ＵＥがＬＴＥ基地局に在圏している場合のみならず、ＬＴＥ基地局(ｅＮＢ)に在圏していない場合でも利用することができる。

　また、ＬＴＥ　Ｄｉｒｅｃｔでは、商用サービス（ｎｏｎ－Ｐｕｂｌｉｃ　Ｓａｆｅｔｙ）においてＬＴＥの通信方式を利用して、ＵＥ間において直接データの送受信を行うことができ、Ｐｕｂｌｉｃ　ＳａｆｅｔｙにおいてＬＴＥの通信方式を利用して、ＵＥ間において直接データの送受信を行うことができる。

　［１．第１実施形態］
　なお、ＬＴＥ基地局装置に在圏していることをＩｎ　ｃｏｖｅｒａｇｅ、ＬＴＥ基地局装置に在圏していないことをＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅとして説明する。まず、本発明を適用した第１実施形態について、図面を参照して説明する。

　［１．１　移動通信システムの概要］
　図１は、本実施形態における移動通信システム１の概略を説明するための図である。本図に示すように、移動通信システム１は、ＵＥ（移動局装置、端末装置）１０Ａと、ＵＥ（移動局装置、端末装置）１０Ｂと、ＰＤＮ（Ｐａｃｋｅｔ　Ｄａｔａ　Ｎｅｔｗｏｒｋ）２０とがＩＰ移動通信ネットワーク５を介して接続されて構成されている。また、ＰＤＮ２０には、ＰｒｏＳｅサーバ９０およびアプリケーションサーバ９５が配置されている。ここで、ＰｒｏＳｅサーバ９０は、ＵＥ１０ＡまたはＵＥ１０Ｂが近隣検出を行うネットワークの移動通信事業者が管理する認証サーバであり、アプリケーションサーバ９５は、ＵＥ１０ＡまたはＵＥ１０Ｂが利用するアプリケーション（ＡＰＰ１）によるサービスを提供するサーバである。なお、本図では、ＰｒｏＳｅサーバ９０は移動通信ネットワーク５の外部の装置として記載されているが、移動通信ネットワーク内の装置であっても良い。また、ＰｒｏＳｅサーバ９０はＭＭＥ４０の機能の一部であっても良いし、別の装置で構成されても良い。

　なお、ＰｒｏＳｅサーバ９０と、アプリケーションサーバ９５は、ＰＤＮ２０に含まれて構成されてもよいし、コアネットワーク７に含まれて構成されてもよい。

　ＵＥ１０Ａと、ＵＥ１０Ｂは、同じ移動通信事業者網に接続していてもよいし、単一の国のなかの異なる移動通信事業者網に接続していてもよい。ＩＰ移動通信ネットワーク５は、例えば、移動通信事業者が運用する無線アクセスネットワークとコアネットワークによって構成されるネットワークでもよいし、固定通信事業者が運用するブロードバンドネットワークであっても良い。移動通信事業者が運用するＩＰ移動通信ネットワークは後で詳細に説明する。

　また、ブロードバンドネットワークは、ＡＤＳＬ（Ａｓｙｍｍｅｔｒｉｃ　Ｄｉｇｉｔａｌ　Ｓｕｂｓｃｒｉｂｅｒ　Ｌｉｎｅ）等により接続し、光ファイバー等のデジタル回線による高速通信を提供する、通信事業者が運用するＩＰ通信ネットワークのことである。さらに、これらに限らずＷｉＭＡＸ（Ｗｏｒｌｄｗｉｄｅ　Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ　ｆｏｒ　Ｍｉｃｒｏｗａｖｅ　Ａｃｃｅｓｓ）等で無線アクセスするネットワークであっても良い。

　ＵＥ１０Ａは、ＬＴＥやＷＬＡＮ等のアクセスシステムを用いて接続する通信端末であり、３ＧＰＰ　ＬＴＥの通信インタフェースやＷＬＡＮの通信インタフェース等を搭載して接続することにより、ＩＰアクセスネットワークへ接続することが可能である。

　具体的な例としては、携帯電話端末やスマートフォンであり、その他通信機能を備えたタブレット型コンピュータやパソコン、家電などである。

　ＰＤＮ２０は、パケットでデータのやり取りを行うネットワークサービスを提供するネットワークのことであり、例えば、インターネットやＩＭＳなどである。

　ＰＤＮ２０は、ＩＰアクセスネットワークへ有線回線等を利用して接続される。例えば、ＡＤＳＬ（Ａｓｙｍｍｅｔｒｉｃ　Ｄｉｇｉｔａｌ　Ｓｕｂｓｃｒｉｂｅｒ　Ｌｉｎｅ）や光ファイバー等によって構築される。ただし、これに限らずＬＴＥ（Ｌｏｎｇ　Ｔｅｒｍ　Ｅｖｏｌｕｔｉｏｎ）や、ＷＬＡＮ（Ｗｉｒｅｌｅｓｓ　ＬＡＮ）、ＷｉＭＡＸ（Ｗｏｒｌｄｗｉｄｅ　Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ　ｆｏｒ　Ｍｉｃｒｏｗａｖｅ　Ａｃｃｅｓｓ）等の無線アクセスネットワークであっても良い。

　[１．１．１　ＩＰ移動通信ネットワークの構成例]
　図２に示すように、移動通信システム１は、ＵＥ１０Ａと、ＩＰ移動通信ネットワーク５と、ＰＤＮ２０（Ｐａｃｋｅｔ　Ｄａｔａ　Ｎｅｔｗｏｒｋ）とから構成される。なお、ＵＥ１０Ｂは、ＵＥ１０Ａとは異なるＵＥであり、構成はＵＥ１０Ａと同様であるため説明を省略する。また、ＩＰ移動通信ネットワーク５には、ＵＥ１０ＡやＵＥ１０Ｂ以外にも複数のＵＥが接続することができるが図面の簡略化のため記載を省略する。さらに、ＩＰ移動通信ネットワーク５はコアネットワーク７と各無線アクセスネットワークで構成される。コアネットワーク７の詳細な構成について図２（ａ）に示している。

　なお、ＰＤＮ２０は、図１を用いて説明したパケットでデータのやり取り行うネットワークサービスを提供するネットワークのことであり、例えば、インターネットやＩＭＳなどである。

　コアネットワーク７は、ＰＧＷ（アクセス制御装置）３０（Ｐａｃｋｅｔ　Ｄａｔａ　Ｎｅｔｗｏｒｋ　Ｇａｔｅｗａｙ）と、ＳＧＷ３５(Ｓｅｒｖｉｎｇ　Ｇａｔｅｗａｙ)と、ＭＭＥ４０(Ｍｏｂｉｌｅ　Ｍａｎａｇｅｍｅｎｔ　Ｅｎｔｉｔｙ)と、ＨＳＳ５０(Ｈｏｍｅ　Ｓｕｂｓｃｒｉｂｅｒ　Ｓｅｒｖｅｒ)と、ＡＡＡ５５(Ａｕｔｈｅｎｔｉｃａｔｉｏｎ,　Ａｕｔｈｏｒｉｚａｔｉｏｎ,　Ａｃｃｏｕｎｔｉｎｇ)と、ＰＣＲＦ６０(Ｐｏｌｉｃｙ　ａｎｄ　ｃｈａｒｇｉｎｇ　ｒｕｌｅｓ　ｆｕｎｃｔｉｏｎ)と、ｅＰＤＧ６５(ｅｎｈａｎｃｅｄ　Ｐａｃｋｅｔ　Ｄａｔａ　Ｇａｔｅｗａｙ)と、を含んで構成される。

　無線アクセスネットワークは、複数の異なるアクセスネットワークで構成されてよい。それぞれのアクセスネットワークはコアネットワーク７に接続されている。さらに、ＵＥ１０Ａは無線アクセスネットワークに無線接続することができる。

　無線アクセスネットワークには、ＬＴＥアクセスシステムで接続できるＬＴＥアクセスネットワーク（ＬＴＥ　ＡＮ８０）や、ＷＬＡＮアクセスシステムで接続できるアクセスネットワークを構成することができる。

　さらに、ＷＬＡＮアクセスシステムで接続可能なアクセスネットワークは、ｅＰＤＧ６５をコアネットワーク７への接続装置として接続するＷＬＡＮアクセスネットワークｂ（ＷＬＡＮ　ＡＮｂ７５）と、ＰＧＷ３０とＰＣＲＦ６０とＡＡＡ５５とに接続するＷＬＡＮアクセスネットワークａ（ＷＬＡＮ　ＡＮａ７０）とが構成可能である。

　なお、各装置はＥＰＳを利用した移動通信システムにおける従来の装置と同様に構成されるため、詳細な説明は省略するが、簡単に機能を説明すると、ＰＧＷ３０はＰＤＮ２０とＳＧＷ３５とｅＰＤＧ６５と、ＷＬＡＮ　ＡＮａと、ＰＣＲＦ６０と、ＡＡＡ５５とに接続されており、ＰＤＮ２０とコアネットワーク７のゲートウェイ装置としてユーザデータ配送を行う。

　ＳＧＷ３５は、ＰＧＷ３０と、ＭＭＥ４０とＬＴＥ　ＡＮ８０とに接続されており、コアネットワーク７とＬＴＥ　ＡＮ８０とのゲートウェイ装置としてユーザデータの配送を行う。

　ＭＭＥ４０は、ＳＧＷ３５とＬＴＥ　ＡＮ８０に接続されており、ＬＴＥ　ＡＮ８０を経由したＵＥ１０Ａのアクセス制御を行うアクセス制御装置である。なお、ＭＭＥ４０において、ＰｒｏＳｅサーバ９０の機能を保持していても良い。

　ＨＳＳ５０は、ＳＧＷ３５とＡＡＡ５５とに接続されており、加入者情報の管理を行う。また、ＡＡＡ５５は、ＰＧＷ３０と、ＨＳＳ５０と、ＰＣＲＦ６０と、ＷＬＡＮ　ＡＮａ７０とに接続されており、ＷＬＡＮ　ＡＮａ７０を経由して接続するＵＥ１０Ａのアクセス制御を行う。ＰＣＲＦ６０は、ＰＧＷ３０と、ＷＬＡＮ　ＡＮａ７０と、ＡＡＡ５５とに接続されており、データ配送に対するＱｏＳ管理を行う。

　ｅＰＤＧ６５は、ＰＧＷ３０と、ＷＬＡＮ　ＡＮｂ７５とに接続されており、コアネットワーク７と、ＷＬＡＮ　ＡＮｂ７５とのゲートウェイ装置としてユーザデータの配送を行う。

　また、図２（ｂ）に示すように、各無線アクセスネットワークには、ＵＥ１０Ａが実際に接続される装置（例えば、基地局装置やアクセスポイント装置）等が含まれている。接続に用いられる装置は、無線アクセスネットワークに適応した種々の装置が考えられるが、本実施形態においては、ＬＴＥ　ＡＮ８０はｅＮＢ４５を含んで構成される。ｅＮＢ４５はＬＴＥアクセスシステムでＵＥ１０Ａが接続する無線基地局であり、ＬＴＥ　ＡＮ８０には１又は複数の無線基地局が含まれて構成されてよい。

　さらに、ＷＬＡＮ　ＡＮａ７０はＷＬＡＮ　ＡＰａ７２と、ＧＷ７４(Ｇａｔｅｗａｙ)とが含まれて構成される。ＷＬＡＮ　ＡＰ７２はＷＬＡＮアクセスシステムでＵＥ１０Ａが接続する無線基地局であり、ＷＬＡＮ　ＡＮ７０には１又は複数の無線基地局が含まれて構成されてよい。ＧＷ７４はコアネットワーク７とＷＬＡＮ　ＡＮａ７０のゲートウェイ装置である。また、ＷＬＡＮ　ＡＰａ７２とＧＷ７４とは、単一の装置で構成されてもよい。

　このように、ＷＬＡＮ　ＡＮａ７０に含まれるゲートウェイは複数のコアネットワーク７内装置に接続することができる。コアネットワーク７を運用する事業者とＷＬＡＮ　ＡＮａ７０を運用する事業者が異なる場合等では、事業者間に運用上の契約や規約等により、信頼関係が結ばれている場合にこのような構成で運用することができる。言い換えると、ＷＬＡＮ　ＡＰａ７２はコアネットワーク７を運用する事業者に対して信頼性のあるアクセスネットワークである。

　また、ＷＬＡＮ　ＡＮｂ７５はＷＬＡＮ　ＡＰｂ７６を含んで構成される。ＷＬＡＮ　ＡＰ７６はＷＬＡＮアクセスシステムでＵＥ１０Ａが接続する無線基地局であり、ＷＬＡＮ　ＡＮ７５には１又は複数の無線基地局が含まれて構成されてよい。

　このように、ＷＬＡＮ　ＡＮｂ７５はコアネットワーク７に含まれる装置であるｅＰＤＧ６５をゲートウェイとしてコアネットワーク７に接続される。ｅＰＤＧ６５は安全性を確保するためのセキュリティ機能を持つ。コアネットワーク７を運用する事業者とＷＬＡＮ　ＡＮａ７０を運用する事業者が異なる場合等では、事業者間に運用上の契約や規約等により、信頼関係が結ばれていない場合にこのような構成で運用する。言い換えると、ＷＬＡＮ　ＡＰａはコアネットワーク７を運用する事業者に対して信頼性のないアクセスネットワークであり、コアネットワーク７に含まれるｅＰＤＧ６５において安全性を提供している。

　なお、本明細書において、ＵＥ１０Ａが各無線アクセスネットワークに接続されるとは、各無線アクセスネットワークに含まれる基地局装置やアクセスポイント等に接続されることをいい、送受信されるデータや信号等も、基地局装置やアクセスポイントを経由している。

　例えば、ＬＴＥ　ＡＮ８０にＵＥ１０Ａが接続されるとは、ＵＥ１０ＡがｅＮＢ４５を介して接続されることをいい、ＷＬＡＮ　ＡＮａ７０に接続されるとは、ＷＬＡＮ　ＡＰａ７２及び／又はＧＷ７４を介して接続されることをいう。また、ＵＥ１０ＡがＷＬＡＮ　ＡＮｂ７５に接続されるとは、ＵＥ１０ＡがＷＬＡＮ　ＡＰｂ７６に接続されることを言う。

　［１．２　装置構成］
　続いて、各装置構成について図を用いて簡単に説明する。

　[１．２．１　ＵＥの構成]
　ＵＥは、ＬＴＥアクセス方式により、無線通信によるデータの送受信を行う携帯電話端末であっても良いし、マシーンツーマシーンと呼ばれるような形態で機器同士が相互に情報交換する端末装置であっても良い。また、これらに限られない通信端末であっても良い。図３は、本実施形態におけるＵＥ１０Ａの機能構成を示す。ＵＥ１０Ａは、制御部１００に、送受信部１１０と直接送受信部１２０と、記憶部１４０とがバスを介して接続されている。

　制御部１００は、ＵＥ１０Ａを制御するための機能部である。制御部１００は、記憶部１４０に記憶されている各種プログラムを読みだして実行することにより各種処理を実現する。

　送受信部１１０は、ＬＴＥアクセス方式により無線通信によるデータの送受信を実行する機能部である。ここで、送受信部１１０は、送信部と受信部から構成される。送信部はＬＴＥ基地局を介してデータや制御情報を送信することができ、受信部はＬＴＥ基地局を介してデータや制御情報を送信することができる。なお、送受信部１１０には、外部アンテナ１１２が接続されており、送信部においてＬＴＥ基地局を介してデータや制御情報の送信を行い、直接受信部においてＬＴＥ基地局を介してデータや制御情報の受信を行うことができる。ＵＥ１０Ａは、送受信部を介してＬＴＥ基地局に接続してＩＰアクセスネットワーク５に接続して通信を行うこともできる。

　ここで、送受信部１１０は、アプリケーションの通信データであるユーザデータと制御情報の送信を行う送信部と、アプリケーションの通信データであるユーザデータと制御情報の受信を行う受信部とを分けて構成しても良い。

　直接送受信部１２０は、ＬＴＥ基地局を介さずに他のＵＥへデータや制御情報などで直接通信を行うことができる機能部である。ここで、直接送受信部１２０は、直接送信部と直接受信部から構成される。直接送信部はＬＴＥ基地局を介さずにデータや制御情報を送信することができ、直接受信部はＬＴＥ基地局を介さずにデータや制御情報を送信することができる。なお、直接送受信部１１０には、外部アンテナ１１２が接続されており、直接送信部においてＬＴＥ基地局を介さずにデータや制御情報の送信を行い、直接受信部においてＬＴＥ基地局を介さずにデータや制御情報の受信を行うことができる。

　ここで、直接送受信部１２０は、アプリケーション（ＡＰＰ）の通信データであるユーザデータと制御情報の送信を行う送信部と、アプリケーション（ＡＰＰ）の通信データであるユーザデータと制御情報の受信を行う受信部とを分けて構成しても良い。

　また、送受信部１１０と直接送受信部１２０とは一つの送受信部として構成されてもよいし、送受信部１１０の送信部と直接送受信部１２０の送信部とを一つの送信部として構成し、送受信部１１０の受信部と直接送受信部１２０の受信部とを一つの受信部として構成しても良い。

　記憶部１４０は、ＵＥ１０Ａの各種動作に必要なプログラム、データ等を記憶する機能部である。記憶部１４０は、例えば、半導体メモリや、ＨＤＤ（Ｈａｒｄ　Ｄｉｓｋ　Ｄｒｉｖｅ）等により構成されている。さらに、記憶部１４０には、ＰｒｏＳｅ　ＩＤ１４２、Ｇｒｏｕｐ　ＩＤ１４４、ＡＰＰサーバ情報１４６、Ｉｎ　ｃｏｖｅｒａｇｅフラグ１４７、ｐｕｂｌｉｃ　Ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙ１４８、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグ１４９が記憶されている。

　ＰｒｏＳｅ　ＩＤ１４２には、ＵＥ１０Ａが近隣検出または、直接通信を行うことができるＵＥを識別する情報を記憶している。図４（ａ）は、ＰｒｏＳｅ　ＩＤ１４２の一例を示した図である。図４（ａ）は、ＰｒｏＳｅ　ＩＤ１４２を示した図である。図４（ａ）では、ＵＥ１０Ａを識別するための識別子（ＰｒｏＳｅ　ＩＤ　Ａ）や近隣に存在し、直接通信を行うことができるＵＥ１０Ｂを識別するための識別子（ＰｒｏＳｅ　ＩＤ　Ｂ）が管理されている。また、近隣に在圏しないが、直接通信を行うことができるＵＥ１０Ｃ（識別子：ＰｒｏＳｅ　ＩＤ　Ｃ）やＵＥ１０Ｄ（識別子：ＰｒｏＳｅ　ＩＤ　Ｄ）も管理されている。

　また、ＰｒｏＳｅ　ＩＤ１４２は、ＵＥを識別するだけでなく、特定のＵＥのアプリケーション毎に管理されてもよい。これにより、ＰｒｏＳｅ　ＩＤ１４２は、ＵＥを識別できるだけでなく、ＵＥのアプリケーションも特定することができる。

　また、ＰｒｏＳｅ　ＩＤ１４２は、Ｅｘｐｒｅｓｓｉｏｎコードであっても良い。Ｅｘｐｒｅｓｓｉｏｎコードとは、ＵＥを識別するための識別子である。Ｅｘｐｒｅｓｓｉｏｎコードは、ＥＰＳやアプリケーションサーバによって割り当てられても良い。また、ＵＥ１０Ａは、ＥｘｐｒｅｓｓｉｏｎコードをＵＥ１０Ｂに送信し、ＵＥ１０ＢがＵＥ１０Ａと近隣に存在することを検出するために、Ｅｘｐｒｅｓｓｉｏｎコードを利用してもよい。

　Ｇｒｏｕｐ　ＩＤ１４４は、ＵＥ１０Ａが参加するグループを識別する識別子を管理している。Ｇｒｏｕｐ　ＩＤ１４４により、ＵＥ１０Ａは近隣検出や直接通信を行うＵＥを制限することができる。なお、Ｇｒｏｕｐ　ＩＤ１４４は、必ずしも利用されるものでなく、Ｇｒｏｕｐ　ＩＤ１４４を利用せずに、近隣検出や直接通信を開始しても良い。図４（ｂ）では、Ｇｒｏｕｐ　ＩＤ１４４は、Ｇｒｏｕｐ　１およびＧｒｏｕｐ２が管理されている。なお、Ｇｒｏｕｐ　ＩＤは複数管理可能であり、ＵＥ１０Ａは複数のグループに所属することができる。

　ＡＰＰサーバ情報１４６は、アプリケーション（ＡＰＰ）毎に関連付けられるＡＰＰサーバに関する情報を管理する。ＡＰＰサーバは、ＵＥ１０Ａが利用するアプリケーションにおいて、サービスを提供するサーバのことである。ＵＥ１０Ａは、ＡＰＰサーバから近隣検出や直接通信に必要な情報を受信し、近隣検出や直接通信を行うことができる。

　図４（ｃ）におけるＡＰＰサーバ情報では、ＵＥ１０Ａが利用するアプリケーションのＡＰＰ１におけるＡＰＰサーバ１とＡＰＰ２におけるＡＰＰサーバ２が管理されている。

　なお、ＡＰＰサーバは、複数管理可能であり、ＵＥ１０Ａは各アプリケーションに対して、異なるＡＰＰサーバを利用することができる。

　また、アプリケーションは、ＶｏＩＰまたはビデオストリーミングまたはビデオファイルまたはテキストなどのデータ種別によって異なるアプリケーションと識別されて管理しても良い。

　もしくは、ＩＭＳなどのミドルウェアを用いた通信を単一のアプリケーションとして識別して管理しても良い。

　もしくは、ＳｋｙｐｅやＬＩＮＥといった個別のアプリケーションをアプリケーション名やアプリケーションＩＤによって識別して管理しても良い。

　もしくはこれらの組み合わせによってアプリケーションを異なるものとして識別して管理しても良い。

　ここで、ＵＥ１０が利用可能なアプリケーションは、製造段階において、インストールされていても良いし、ユーザ操作によりインストールされていても良い。

　図４（ｄ）は、近隣検出または、直接通信を行うことができるＵＥに対するＩｎ　ｃｏｖｅｒａｇｅフラグ１４７の例を示した図である。図４（ｄ）では、ＵＥ１０ＡのＩｎ　ｃｏｖｅｒａｇｅフラグ１４７と、ＵＥ１０ＢのＩｎ　ｃｏｖｅｒａｇｅフラグと、ＵＥ１０ＢのＩｎ　ｃｏｖｅｒａｇｅフラグと、ＵＥ１０ＢのＩｎ　ｃｏｖｅｒａｇｅフラグとが管理されている。ここでは、一例として、ＵＥ１０Ａに対してＩｎ　ｃｏｖｅｒａｇｅフラグをＩｎ　ｃｏｖｅｒａｇｅとして管理し、ＵＥ１０Ｂに対してＩｎ　ｃｏｖｅｒａｇｅフラグをＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅとして管理し、ＵＥ１０Ｃに対してＩｎ　ｃｏｖｅｒａｇｅフラグをＩｎ　ｃｏｖｅｒａｇｅとして管理し、ＵＥ１０Ｄに対してＩｎ　ｃｏｖｅｒａｇｅフラグをＩｎ　ｃｏｖｅｒａｇｅとして管理している。

　ここで、ＵＥ１０Ａに対してＩｎ　ｃｏｖｅｒａｇｅフラグをＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅとして管理し、ＵＥ１０Ｂに対してＩｎ　ｃｏｖｅｒａｇｅフラグをＩｎ　ｃｏｖｅｒａｇｅとして管理し、ＵＥ１０Ｃに対してＩｎ　ｃｏｖｅｒａｇｅフラグをＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅとして管理し、ＵＥ１０Ｄに対してＩｎ　ｃｏｖｅｒａｇｅフラグをＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅとして管理しても良い。

　図４（ｅ）は、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙ１４８の例を示した図である。ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙ１４８は、ｐｕｂｌｉｃ　ｓａｆｅｔｙを利用することができることを示す情報を管理している。図４（ｅ）では、ＵＥ１０Ａのｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙと、ＵＥ１０Ｂのｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙと、ＵＥ１０Ｃのｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙと、ＵＥ１０Ｄのｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙと、を管理している。ここでは、一例として、ＵＥ１０Ａに対するｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙを可として管理し、ＵＥ１０Ｂに対するｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙを可として管理し、ＵＥ１０Ｃ対するｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙを可として管理し、ＵＥ１０Ｄに対するｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙを不可として管理している。ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙが可の場合、ＵＥはｐｕｂｌｉｃ　ｓａｆｅｔｙの機能を保持し、ｐｕｂｌｉｃ　ｓａｆｅｔｙを利用可能であることを示し、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙが不可の場合、ＵＥはｐｕｂｌｉｃ　ｓａｆｅｔｙの機能を保持せず、ｐｕｂｌｉｃ　ｓａｆｅｔｙを利用不可能であることを示している。

　図４（ｆ）は、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグ１４９の例を示した図である。ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグ１４９は、ｐｕｂｌｉｃ　ｓａｆｅｔｙを各ＵＥが許可（またはｏｎ）していることを示す情報を管理している。図４（ｆ）では、ＵＥ１０Ａのｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグと、ＵＥ１０Ｂのｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグと、ＵＥ１０Ｃのｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグと、ＵＥ１０Ｄのｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグと、を管理している。ここでは、一例として、ＵＥ１０Ａに対するｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグをｏｎとして管理し、ＵＥ１０Ｂに対するｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグをｏｎとして管理し、ＵＥ１０Ｃに対するｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグをｏｆｆとして管理し、ＵＥ１０Ｄに対するｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグを「―」として管理している。ここで、ＵＥ１０Ｄは、ｐｕｂｌｉｃ　ｓａｆｅｔｙを利用することができないため、「―」として管理しているが、ｏｆｆとして管理しても良い。ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグ１４９において、「―」または、「ｏｆｆ」として管理されているＵＥは、ｐｕｂｌｉｃ　ｓａｆｅｔｙを利用できないＵＥとして管理される。

　[１．２．２　ＰｒｏＳｅサーバの構成]
　図５にＰｒｏＳｅサーバ９０の機能構成を示す。なお、ＰｒｏＳｅサーバ９０とは、ＰｒｏＳｅによる近隣検出やＰｒｏＳｅによる通信を行う移動通信事業者で管理される認証サーバである。認証サーバ９０は、制御部９００に、ＩＰ移動通信ネットワークインタフェース部９１０と、記憶部９４０とがバスを介して接続されている。

　制御部９００は、ＵＥ１０を制御するための機能部である。制御部９００は、記憶部９４０に記憶されている各種プログラムを読みだして実行することにより各種処理を実現する。

　ＩＰ移動通信ネットワークインタフェース部９１０は、認証サーバ９０がＩＰ移動通信ネットワーク５に接続するための機能部である。

　記憶部９４０は、ＵＥ１０の各種動作に必要なプログラム、データ等を記録する機能部である。記憶部９４０は、例えば、半導体メモリや、ＨＤＤ（Ｈａｒｄ　Ｄｉｓｋ　Ｄｒｉｖｅ）等により構成される。

　さらに、記憶部９４０には、ＰｒｏＳｅ　ＩＤ９４２と、Ｇｒｏｕｐ　ＩＤ９４４と、ＵＥ　Ｉｎ　ｃｏｖｅｒａｇｅフラグ９４６と、ＵＥ　ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙ９４８とＵＥ　ｐｕｂｌｉｃ　ｓａｆｅｔｙフラグ９４９とを管理する。

　なお、以下で説明するＰｒｏＳｅ　ＩＤ９４２、Ｇｒｏｕｐ　ＩＤ９４４、ＵＥ　Ｉｎ　ｃｏｖｅｒｇｅフラグ９４６と、ＵＥ　ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙ９４８と、ＵＥ　ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグ９４９は、外部装置により記憶されていても良い。例えば、ＨＳＳ５０にこれらを記憶し、必要に応じてＨＳＳ５０への問い合わせを行うことで参照したり、記憶部９４０に登録したり更新を行ってもよい。

　図６（ａ）に、ＰｒｏＳｅサーバで管理されるＰｒｏＳｅ　ＩＤ９４２の例を示す。ＰｒｏＳｅ　ＩＤ９４２には、ＵＥ１０Ａが近隣検出または、直接通信を行うことができるＵＥ識別子を記憶している。図６（ａ）では、ＵＥ１０Ａを識別するための識別子（ＰｒｏＳｅ　ＩＤ　Ａ）や近隣に存在し、直接通信を行うことができるＵＥ１０Ｂを識別するための識別子（ＰｒｏＳｅ　ＩＤ　Ｂ）と、ＵＥ１０Ｃ（識別子：ＰｒｏＳｅ　ＩＤ　Ｃ）やＵＥ１０Ｄ（識別子：ＰｒｏＳｅ　ＩＤ　Ｄ）とが管理されている。

　なお、ＰｒｏＳｅ　ＩＤ９４２は、アプリケーション毎に管理されていても良い。つまり、ＡＰＰ毎に、ＰｒｏＳｅ　ＩＤ９４２を管理しても良い。

　また、ＰｒｏＳｅ　ＩＤ９４２は、ＵＥを識別するための識別子であれば、Ｅｘｐｒｅｓｓｉｏｎコードであっても良い。Ｅｘｐｒｅｓｓｉｏｎコードとは、ＵＥを識別するための識別子である。Ｅｘｐｒｅｓｓｉｏｎコードは、ＥＰＳやアプリケーションサーバによって割り当てられても良い。また、ＵＥ１０Ａは、ＥｘｐｒｅｓｓｉｏｎコードをＵＥ１０Ｂに送信し、ＵＥ１０ＢがＵＥ１０Ａと近隣に存在することを検出するために、Ｅｘｐｒｅｓｓｉｏｎコードを利用してもよい。

　Ｇｒｏｕｐ　ＩＤ９４４は、ＵＥ１０Ａが参加するグループを識別する識別子を管理している。図６（ｂ）では、Ｇｒｏｕｐ　ＩＤ９４４は、Ｇｒｏｕｐ　１およびＧｒｏｕｐ２が管理されている。なお、Ｇｒｏｕｐ　ＩＤは複数管理可能である。

　図６（ｃ）は、近隣検出または、直接通信を行うことができるＵＥに対するＩｎ　ｃｏｖｅｒａｇｅフラグ９４６の例を示した図である。図６（ｃ）では、ＵＥ１０ＡのＩｎ　ｃｏｖｅｒａｇｅフラグ１４７と、ＵＥ１０ＢのＩｎ　ｃｏｖｅｒａｇｅフラグと、ＵＥ１０ＢのＩｎ　ｃｏｖｅｒａｇｅフラグと、ＵＥ１０ＢのＩｎ　ｃｏｖｅｒａｇｅフラグとが管理されている。ここでは、一例として、ＵＥ１０Ａに対してＩｎ　ｃｏｖｅｒａｇｅフラグをＩｎ　ｃｏｖｅｒａｇｅとして管理し、ＵＥ１０Ｂに対してＩｎ　ｃｏｖｅｒａｇｅフラグをＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅとして管理し、ＵＥ１０Ｃに対してＩｎ　ｃｏｖｅｒａｇｅフラグをＩｎ　ｃｏｖｅｒａｇｅとして管理し、ＵＥ１０Ｄに対してＩｎ　ｃｏｖｅｒａｇｅフラグをＩｎ　ｃｏｖｅｒａｇｅとして管理している。

　図６（ｄ）は、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙ９４８の例を示した図である。ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙ９４８は、ｐｕｂｌｉｃ　ｓａｆｅｔｙを利用することができることを示す情報を管理している。図６（ｄ）では、ＵＥ１０Ａのｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙと、ＵＥ１０Ｂのｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙと、ＵＥ１０Ｃのｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙと、ＵＥ１０Ｄのｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙと、を管理している。ここでは、一例として、ＵＥ１０Ａに対するｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙを可として管理し、ＵＥ１０Ｂに対するｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙを可として管理し、ＵＥ１０Ｃ対するｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙを可として管理し、ＵＥ１０Ｄに対するｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙを不可として管理している。

　図６（ｅ）は、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグ９４９の例を示した図である。ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグ９４９は、ｐｕｂｌｉｃ　ｓａｆｅｔｙを各ＵＥが許可（またはｏｎ）していることを示す情報を管理している。図６（ｅ）では、ＵＥ１０Ａのｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグと、ＵＥ１０Ｂのｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグと、ＵＥ１０Ｃのｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグと、ＵＥ１０Ｄのｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグと、を管理している。ここでは、一例として、ＵＥ１０Ａに対するｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグをｏｎとして管理し、ＵＥ１０Ｂに対するｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグをｏｎとして管理し、ＵＥ１０Ｃに対するｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグをｏｆｆとして管理し、ＵＥ１０Ｄに対するｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグを「―」として管理している。ここで、ＵＥ１０Ｄは、ｐｕｂｌｉｃ　ｓａｆｅｔｙを利用することができないため、「―」として管理しているが、ｏｆｆとして管理しても良い。ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグ１４９において、「―」または、「ｏｆｆ」として管理されているＵＥは、ｐｕｂｌｉｃ　ｓａｆｅｔｙを利用できないＵＥとして管理される。

　［１．２．３　ＡＰＰサーバの構成］
　図７にＡＰＰサーバ９５の機能構成を示す。なお、ＡＰＰサーバ９５とは、ＵＥ１０Ａが利用するアプリケーションにおいてサービスを提供するサーバである。

　ＡＰＰサーバ９５は、制御部９５００に、ＩＰ移動通信ネットワークインタフェース部９５１０と、記憶部９５４０とがバスを介して接続されている。

　制御部９５００は、ＵＥ１０を制御するための機能部である。制御部９５００は、記憶部９５４０に記憶されている各種プログラムを読みだして実行することにより各種処理を実現する。

　ＩＰ移動通信ネットワークインタフェース部９５１０は、ＡＰＰサーバ９５がＩＰ移動通信ネットワーク５に接続するための機能部である。

　記憶部９５４０は、ＵＥ１０の各種動作に必要なプログラム、データ等を記録する機能部である。記憶部９５４０は、例えば、半導体メモリや、ＨＤＤ（Ｈａｒｄ　Ｄｉｓｋ　Ｄｒｉｖｅ）等により構成される。さらに、記憶部９５４０には、ＰｒｏＳｅ　ＩＤ９５４２とＧｒｏｕｐ　ＩＤ９５４４が管理されている。

　図８（ａ）に、ＰｒｏＳｅ　ＩＤ９５４２の一例を示す。図９（ａ）では、ＡＰＰ１を利用しているＵＥの識別子が管理されている。図９（ａ）では、ＵＥ１０ＡおよびＵＥ１０Ｂにおける識別子が９５４２の一例として、ＰｒｏＳｅ　ＩＤ　ＡおよびＰｒｏＳｅ　ＩＤ　Ｂが管理されているが、ＰｒｏＳｅ　ＩＤ　ＡおよびＰｒｏＳｅ　ＩＤ　Ｂに限るものでなく、他のＵＥであっても良い。

　図８（ｂ）に、Ｇｒｏｕｐ　ＩＤの一例を示す。図８（ｂ）では、ＡＰＰサーバ９５においてサービスを提供するグループＩＤを管理している。図８（ｂ）では、Ｇｒｕｏｐ　ＩＤ９５４４の一例として、Ｇｒｏｕｐ　１およびＧｒｏｕｐ２が管理されている。ここで、管理されるＧｒｏｕｐ　ＩＤはＡＰＰ１およびＡＰＰ２に限るものでなく、他のＧｒｏｕｐ　ＩＤであっても良い。

　［１．３　処理の説明］
　［１．３．１　近隣検出手続き］
　続いて、上述した移動通信システムにおける具体的な手続きおよび処理について説明する。図９を用いて、ＵＥ１０ＡがＵＥ１０Ｂを近隣検出するためにブロードキャストで送信を行う際に、ｉｎ　ｃｏｖｅｒａｇｅフラグ１４７、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙ１４８、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグ１４９を含め、ＵＥ１０Ｂは、ＵＥ１０Ａからの近隣検出において、ｉｎ　ｃｏｖｅｒａｇｅフラグ１４７、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙ１４８、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグ１４９が含められた信号をブロードキャストで受信し、ＵＥ１０Ａからの信号（ブロードキャスト）に対する応答をＵＥ１０Ａに送信することにより、ＵＥ１０Ａは、ＵＥ１０Ｂのｉｎ　ｃｏｖｅｒａｇｅフラグ１４７、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙ１４８、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグ１４９を検出する手続きを説明する。

　まず、ＵＥ１０ＡのＡＰＰ１は、ＵＥ１０Ａの３ＧＰＰレイヤにＥｘｐｒｅｓｓｉｏｎコードの要求を送信する（Ｓ９０２）。ここで、Ｅｘｐｒｅｓｓｉｏｎコードとは、ＵＥ１０Ａを識別するための識別子である。また、Ｅｘｐｒｅｓｓｉｏｎコードは、ＵＥ１０Ａによってブロードキャストして送信され、ＵＥ１０Ｂによって受信されることにより、ＵＥ１０Ａが近隣に存在することをＵＥ１０Ｂに検出させるための識別子である。

　続いて、ＵＥ１０Ａの３ＧＰＰレイヤは、ＥＰＳへ問い合わせることにより、ＵＥ１０ＡのＥｘｐｒｅｓｓｉｏｎコードの取得を行う（Ｓ９０４）。ここで、ＵＥ１０Ａは、ＵＥ１０Ａの識別子（ＰｒｏＳｅ　ＩＤ　Ａ）を通知し、近隣検出に利用するＥｘｐｒｅｓｓｉｏｎコードを取得しても良い。なお、一度、Ｅｘｐｒｅｓｓｉｏｎコードの認証を受けている場合、Ｅｘｐｒｅｓｓｉｏｎコードの認証手続きをスキップしても良い。

　次に、ＵＥ１０Ａの３ＧＰＰレイヤは、ＵＥ１０ＡのＥｘｐｒｅｓｓｉｏｎコードをＵＥ１０Ｂのアプリケーションレイヤに通知する（Ｓ９０６）。一方、ＵＥ１０Ａの３ＧＰＰレイヤは、ＵＥ１０ＡのＥｘｐｒｅｓｓｉｏｎコードをＵＥ１０Ｂへ送信する（Ｓ９０８）。ここで、ＵＥ１０Ａは、アナウンスするＥｘｐｒｅｓｓｉｏｎコードを通知する。また、ＵＥ１０Ｂは、送信されたＥｘｐｒｅｓｓｉｏｎコードを受信し、Ｅｘｐｒｅｓｓｉｏｎコードをモニタリングする。なお、ＵＥ１０ＡからＵＥ１０ＢへＥｘｐｒｅｓｓｉｏｎコードを送信する方法は、アプリケーションレイヤによって送受信されても良いし、３ＧＰＰレイヤによって送受信されても良い。

　次に、ＵＥ１０Ｂのアプリケーションレイヤは、ＵＥ１０Ｂの３ＧＰＰレイヤがモニターするＥｘｐｒｅｓｓｉｏｎコードを要求する（Ｓ９１２）．ここで、ＵＥ１０Ｂのアプリケーションレイヤは、Ｓ９０８で通知されたＵＥ１０ＡのＥｘｐｒｅｓｓｉｏｎコードが、ＵＥ１０Ｂの３ＧＰＰレイヤでモニターされるＥｘｐｒｅｓｓｉｏｎコードと同じであることを確認するために、Ｅｘｐｒｅｓｓｉｏｎコードの要求を行う。なお、ＵＥ１０Ｂの３ＧＰＰレイヤは、このＥｘｐｒｅｓｓｉｏｎコードの要求により、ＵＥ１０Ａからの近隣検出するための信号の待ち受けを開始してもよい。

　Ｅｘｐｒｅｓｓｉｏｎコードを受信したＵＥ１０Ａのアプリケーションレイヤは、近隣検出の開始を３ＧＰＰレイヤに要求する（Ｓ９１０）。近隣検出開始の要求を受け取った３ＧＰＰレイヤは、ＵＥ１０Ｂを近隣検出するための信号をブロードキャストで送信する（Ｓ９１４）。近隣検出のための信号には、ｉｎ　ｃｏｖｅｒａｇｅフラグ１４７、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙ１４８、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグ１４９を含める。ここで、ｉｎ　ｃｏｖｅｒａｇｅフラグ１４７には、ＵＥ１０ＡがＬＴＥ基地局に在圏していること（Ｉｎ　ｃｏｖｅｒａｇｅ）（または、在圏していないこと（Ｏｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ））を示す情報を含める。

　ここで、ＵＥ１０ＡがＬＴＥ基地局に在圏していることを検出する方法は、種々の方法が考えられるが、例えば、ｅＮＢ４５から送信される情報を一定時間以内に受信していれば、ＬＴＥ基地局に在圏していると判断し、ｅＮＢ４５から送信される情報を一定時間以内に受信していなければ、ＬＴＥ基地局に在圏していないと判断しても良い。

　また、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙ１４８は、ｐｕｂｌｉｃ　ｓａｆｅｔｙを機能として保持していることを示す情報であり、ここでは、ＵＥ１０Ａはｐｕｂｌｉｃ　ｓａｆｅｔｙの機能を保持するため、「可」として通知する。

　さらに、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグ１４９は、ｐｕｂｌｉｃ　ｓａｆｅｔｙを利用することを許可することを示す情報であり、ここでは、ＵＥ１０Ａはｐｕｂｌｉｃ　ｓａｆｅｔｙを許可しているため、「ｏｎ」として通知する。また、近隣検出を行っているＵＥ１０ＡのＥｘｐｒｅｓｓｉｏｎコードを含めても良い。このように、ＵＥ１０Ａは、ＵＥ１０Ａの検出を要求する信号として送信しても良い。

　さらに、ＵＥ１０Ａは、ＵＥ１０ＡがＬＴＥ　Ｄｉｒｅｃｔで直接通信路を確立することができる能力情報などを示す識別情報を含めても良い。また、ＵＥ１０Ａは、ＵＥ１０ＡがＷＬＡＮ　Ｄｉｒｅｃｔで直接通信路を確立することができる能力情報などを示す識別情報を含めても良い。

　なお、ＵＥ１０Ａの３ＧＰＰレイヤが送信する近隣検出のための信号は、一定時間毎に送信されても良い。また、ｉｎ　ｃｏｖｅｒａｇｅフラグ１４７が更新される度に送信しても良い。ｉｎ　ｃｏｖｅｒａｇｅフラグ１４７は、送信時点での、圏内または、圏外の状況に応じて、更新して検出要求信号に含めて送信する。

　近隣検出のための信号（ブロードキャスト）を受信したＵＥ１０Ｂは、信号（ブロードキャスト）に含まれる近隣検出の対象であることを示すＵＥ１０ＢのＥｘｐｒｅｓｓｉｏｎコードを検出し、ＵＥ１０Ｂが検出の対象であることを判断する。また、ＵＥ１０Ｂは、信号（ブロードキャスト）に含まれるｉｎ　ｃｏｖｅｒａｇｅフラグ１４７、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙ１４８、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグ１４９を検出し、ＵＥ１０Ａに関する情報として格納する。

　ＵＥ１０Ａの３ＧＰＰレイヤは、ＵＥ１０ＡとＵＥ１０Ｂのカバレッジ情報を検知する（Ｓ９１５）。図１０に、ＵＥ１０ＡとＵＥ１０Ｂのカバレッジ情報を示す。図１０（ａ）は、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅであり、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅであることを示している。図１０（ｂ）は、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅであり、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅであることを示している。図１０（ｃ）は、ＵＥ１０ＡがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅであり、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅであることを示している。図１０（ｄ）は、ＵＥ１０ＡがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅであり、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅであることを示している。図１０に示すように、ＵＥ１０Ａにおいて、Ｉｎ　ｃｏｖｅｒａｇｅかＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅであることを検出し、ＵＥ１０Ｂからの通知により、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅかＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅであることを検出することにより、ＵＥ１０Ａにおけるｉｎ　ｃｏｖｅｒａｇｅフラグ１４７は、図１０（ａ）または、図１０（ｂ）または、図１０（ｃ）、図１０（ｄ）のいずれかとなる。

　ＵＥ１０ＡとＵＥ１０Ｂが上記の４状態のいずれかであることを検出することにより、通信路確立手続きを開始することができる。具体的には、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅである１状態のそれぞれの状態で、異なる通信路確立手続きを行う。

　ここで、ＵＥ１０Ａまたは、ＵＥ１０Ｂのｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙが「不可」で、ＵＥ１０Ａまたは、ＵＥ１０Ｂのｉｎ　ｃｏｖｅｒａｇｅフラグ１４７がｏｕｔ　ｏｆ　ｃｏｖｅｒａｇｅの場合、直接通信を行うことができないと判断しても良い。また、ＵＥ１０Ａまたは、ＵＥ１０Ｂのｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグが「ｏｆｆ」で、ＵＥ１０Ａまたは、ＵＥ１０Ｂのｉｎ　ｃｏｖｅｒａｇｅフラグ１４７がｏｕｔ　ｏｆ　ｃｏｖｅｒａｇｅの場合、直接通信を行うことができないと判断しても良い。

　また、ＵＥ１０Ｂは、ＵＥ１０ＡがＬＴＥ　Ｄｉｒｅｃｔで直接通信路を確立することができる能力情報などを示す識別情報により、ＵＥ１０ＡがＬＴＥ　Ｄｉｒｅｃｔを利用できることを検出しても良い。また、ＵＥ１０Ｂは、ＵＥ１０ＡがＷＬＡＮ　Ｄｉｒｅｃｔで直接通信路を確立することができる能力情報などを示す識別情報により、ＵＥ１０ＡがＷＬＡＮ　Ｄｉｒｅｃｔを利用できることを検出しても良い。

　ＵＥ１０Ａから信号（ブロードキャスト）を受信したＵＥ１０Ｂの３ＧＰＰレイヤは、信号（ブロードキャスト）で検出したＵＥ１０ＡのＥｘｐｒｅｓｓｉｏｎコードをＵＥ１０Ｂのアプリケーションレイヤに通知する（Ｓ９１６）。このとき、ＵＥ１０Ｂは、個の通知に、ｉｎ　ｃｏｖｅｒａｇｅフラグ１４７、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙ１４８、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグ１４９を含めても良い。ここで、ｉｎ　ｃｏｖｅｒａｇｅフラグ１４７には、ＵＥ１０ＢがＬＴＥ基地局に在圏していること（Ｉｎ　ｃｏｖｅｒａｇｅ）（または、在圏していないこと（Ｏｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ））を示す情報を含めても良い。

　ここで、ＵＥ１０ＢがＬＴＥ基地局に在圏していることを検出する方法は、種々の方法が考えられるが、例えば、ｅＮＢ４５から送信される情報を一定時間以内に受信していれば、ＬＴＥ基地局に在圏していると判断し、ｅＮＢ４５から送信される情報を一定時間以内に受信していなければ、ＬＴＥ基地局に在圏していないと判断しても良い。また、近隣検出を行っているＵＥ１０ＢのＥｘｐｒｅｓｓｉｏｎコードや近隣検出の対象であるＵＥ１０ＢのＥｘｐｒｅｓｓｉｏｎコードを含める。

　また、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙ１４８は、ｐｕｂｌｉｃ　ｓａｆｅｔｙを機能として保持していることを示す情報であり、ここでは、ＵＥ１０Ｂはｐｕｂｌｉｃ　ｓａｆｅｔｙの機能を保持するため、「可」として通知しても良い。

　さらに、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグ１４９は、ｐｕｂｌｉｃ　ｓａｆｅｔｙを利用することを許可することを示す情報であり、ここでは、ＵＥ１０Ｂはｐｕｂｌｉｃ　ｓａｆｅｔｙを許可しているため、「ｏｎ」として通知しても良い。

　以上の手続きにより、ＵＥ１０Ｂは、ＵＥ１０ＡおよびＵＥ１０Ｂにおけるカバレッジ情報を検出することができる。つまり、ＵＥ１０Ｂは、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅである１状態の４状態のうち、いずれかであることを検出することができる。

　ここで、ＵＥ１０ＡはＵＥ１０Ｂによって検出された後でも、近隣検出のための信号を、一定時間毎に送信し続けても良い。また、ｉｎ　ｃｏｖｅｒａｇｅフラグ１４７が更新される度に送信しても良い。ｉｎ　ｃｏｖｅｒａｇｅフラグ１４７は、送信時点での、圏内または、圏外の状況に応じて、更新して検出要求信号に含めて送信する。

　ここで、Ｓ９０２からＳ９１６までの一連の手続きにおいて、ＵＥ１０ＡとＵＥ１０Ｂを入れ替えて手続きを開始しても良い。つまり、ＵＥ１０ＢのアプリケーションがＥｘｐｒｅｓｓｉｏｎコードを要求し（Ｓ９０２）、ＵＥ１０ＢのＥｘｐｒｅｓｓｉｏｎコードを取得し（Ｓ９０４）、ＵＥ１０Ｂの３ＧＰＰレイヤがＥｘｐｒｅｓｓｉｏｎコードをＵＥ１０Ｂのアプリケーションレイヤに通知し（Ｓ９０６）、ＵＥ１０Ｂのアプリケーションレイヤが、ＵＥ１０Ｂを識別するＥｘｐｒｅｓｓｉｏｎコードを送信し（Ｓ９０８）、ＵＥ１０Ａのアプリケーションレイヤが近隣検出開始の要求を送信し（Ｓ９１０）、ＵＥ１０Ａの３ＧＰＰレイヤが信号（ブロードキャスト）を送信し、ＵＥ１０ＡのアプリケーションレイヤがモニターするＥｘｐｒｅｓｓｉｏｎコードを要求し（Ｓ９１２）、ＵＥ１０ＡはＵＥ１０Ｂを識別するＥｘｐｒｅｓｓｉｏｎコードが含められたＵＥ１０Ｂを検出させるための信号をモニタリングする。ＵＥ１０Ｂの３ＧＰＰレイヤは、近隣検出の信号（ブロードキャスト）の送信を行う（Ｓ９１４）。ＵＥ１０Ａは、この信号を受信することで、ＵＥ１０Ｂが近隣に位置することを検出する。ＵＥ１０Ａの３ＧＰＰレイヤがＵＥ１０ＡとＵＥ１０Ｂのカバレッジ情報を検知し（Ｓ９１５）、ＵＥ１０Ａの３ＧＰＰレイヤがＵＥ１０ＡのアプリケーションレイヤにモニターしたＥｘｐｒｅｓｓｉｏｎコードを通知（Ｓ９１６）しても良い。なお、近隣検出の信号の送信（Ｓ９１４）では、近隣検出を行っているＵＥ１０ＢのＥｘｐｒｅｓｓｉｏｎコードを含めても良い。このように、ＵＥ１０ＢはＵＥ１０Ｂの検出を要求する信号として送信しても良い。

　この一連の手続きにより、ＵＥ１０Ａは、ＵＥ１０Ｂの近隣を検知し、ＵＥ１０ＡおよびＵＥ１０Ｂにおけるカバレッジ情報を検出することができる。つまり、ＵＥ１０Ａは、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅである１状態の４状態のうち、いずれかであることを検出することができる。

　次に、ＵＥ１０Ｂの３ＧＰＰレイヤは、ＵＥ１０Ａの３ＧＰＰレイヤに、近隣検出に対する応答をブロードキャストで送信しても良い（Ｓ９１８）。これにより、ＵＥ１０Ｂは、ＵＥ１０Ａが近隣に存在すると検出したことをＵＥ１０Ａに通知することができる。さらに、ＵＥ１０Ａはこの応答の受信することにより、ＵＥ１０ＢがＵＥ１０Ａの近隣に存在することを検知することもできる。このとき、ＵＥ１０Ｂは、この応答に、ｉｎ　ｃｏｖｅｒａｇｅフラグ１４７、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙ１４８、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグ１４９を含めても良い。ここで、ｉｎ　ｃｏｖｅｒａｇｅフラグ１４７には、ＵＥ１０ＢがＬＴＥ基地局に在圏していること（Ｉｎ　ｃｏｖｅｒａｇｅ）（または、在圏していないこと（Ｏｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ））を示す情報を含めても良い。

　さらに、ＵＥ１０Ｂは、ＵＥ１０ＢがＬＴＥ　Ｄｉｒｅｃｔで直接通信路を確立することができる能力情報などを示す識別情報を含めても良い。また、ＵＥ１０Ｂは、ＵＥ１０ＢがＷＬＡＮ　Ｄｉｒｅｃｔで直接通信路を確立することができる能力情報などを示す識別情報を含めても良い。

　ここで、ＵＥ１０ＢがＬＴＥ基地局に在圏していることを検出する方法は、種々の方法が考えられるが、例えば、ｅＮＢ４５から送信される情報を一定時間以内に受信していれば、ＬＴＥ基地局に在圏していると判断し、ｅＮＢ４５から送信される情報を一定時間以内に受信していなければ、ＬＴＥ基地局に在圏していないと判断しても良い。また、近隣検出を行っているＵＥ１０ＢのＥｘｐｒｅｓｓｉｏｎコードや近隣検出の対象であるＵＥ１０ＢのＥｘｐｒｅｓｓｉｏｎコードを含めても良い。

　一方、ＵＥ１０Ｂからの信号（ブロードキャスト）に対する応答を受信したＵＥ１０Ａは、信号（ブロードキャスト）に対する応答に含まれるＩｎ　ｃｏｖｅｒａｇｅフラグ１４７、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙ１４８、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグ１４９を検出し、格納する。

　また、ＵＥ１０Ａは、ＵＥ１０ＢがＬＴＥ　Ｄｉｒｅｃｔで直接通信路を確立することができる能力情報などを示す識別情報により、ＵＥ１０ＢがＬＴＥ　Ｄｉｒｅｃｔを利用できることを検出しても良い。また、ＵＥ１０Ａは、ＵＥ１０ＢがＷＬＡＮ　Ｄｉｒｅｃｔで直接通信路を確立することができる能力情報などを示す識別情報により、ＵＥ１０ＢがＷＬＡＮ　Ｄｉｒｅｃｔを利用できることを検出しても良い。

　ＵＥ１０ＡがＵＥ１０Ｂに送信するブロードキャストの送信（Ｓ９１４）は、あらかじめ取得した通信リソースを利用して、ユニキャストで送信しても良い。また逆に、ＵＥ１０ＢがＵＥ１０Ａに送信するブロードキャストの送信（Ｓ９１４）する場合、あらかじめ取得した通信リソースを利用して、ユニキャストで送信しても良い。ここで、取得した通信リソースとは、特定のＵＥに検出させるために利用することができる通信リソースであり、ｅＮＢ４５またはＭＭＥ４０によって明示的に通知されることにより割り当てられても良いし、あらかじめＵＥ１０ＡまたはＵＥ１０Ｂに通知されているものを利用しても良い。

　さらに、ＵＥ１０ＢがＵＥ１０Ａに送信するブロードキャストの送信（Ｓ９１８）は、あらかじめ取得した通信リソースを利用して、ユニキャストで送信しても良い。また逆に、ＵＥ１０ＡがＵＥ１０Ｂに送信するブロードキャストの送信（Ｓ９１８）する場合、あらかじめ取得した通信リソースを利用して、ユニキャストで送信しても良い。ここで、取得した通信リソースとは、特定のＵＥに検出させるために利用することができる通信リソースであり、ｅＮＢ４５またはＭＭＥ４０によって明示的に通知されることにより割り当てられても良いし、あらかじめＵＥ１０ＡまたはＵＥ１０Ｂに通知されているものを利用しても良い。

　以上の手続きにより、ＵＥ１０Ｂ（およびＵＥ１０Ａ）は、ＵＥ１０ＡおよびＵＥ１０Ｂにおけるカバレッジ情報を検出することができる。つまり、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅである１状態の４状態のうち、いずれかであることを検出することができる。

　近隣検出手続きにおいて、ＵＥ１０Ｂ（およびＵＥ１０Ａ）は、ＵＥ１０ＡおよびＵＥ１０Ｂにおけるカバレッジ情報を検出し、カバレッジ情報に基づいて、通信路確立手続きを行う。具体的には、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅである１状態のそれぞれの状態で、異なる通信路確立手続きを行う。

　［１．３．２　通信路確立手続き］
　次に、通信路確立手続きについて示す。ここでは、近隣検出手続きにおいて、ＵＥ１０Ａは、ＵＥ１０ＡおよびＵＥ１０Ｂにおけるカバレッジ情報を検出した。通信路確立手続きでは、ＵＥ１０ＡとＵＥ１０Ｂのカバレッジ情報を利用して、通信路確立手続きを行う。具体的には、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅである１状態のそれぞれの状態で、異なる通信路確立手続きを行う。

　［１．３．２．１　通信路確立手続き１］
　通信路確立手続き１について説明する。本手続きでは、ＵＥ１０Ａは、ｅＮＢ－Ａに在圏し、ｅＮＢ－Ａは、ＭＭＥ－Ａによって管理されている。また、ＵＥ１０Ｂは、ｅＮＢ－Ｂに在圏し、ｅＮＢ－Ｂは、ＭＭＥ－Ｂによって管理されている。ここで、ＭＭＥ－ＡまたはＭＭＥ－Ｂには、ＰｒｏＳｅサーバ９０（ＰｒｏＳｅサーバＡ、ＰｒｏＳｅサーバＢ）であっても良い。

　［１．３．２．１．１　ＵＥ１０Ａ：Ｉｎ　ｃｏｖｅｒｇｅ　ＵＥ１０Ｂ：Ｉｎ　ｃｏｖｅｒａｇｅ］
　図１１を用いて、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅである１状態における通信路確立手続きについて説明する。

　まず、ＵＥ１０Ａは、ＵＥ１０Ｂに直接通信要求を送信する（Ｓ１００２）。ここで、ＵＥ１０Ａは、ＵＥ１０Ａの管理するＧｒｏｕｐ　ＩＤ（Ｇｒｏｕｐ　１）およびＰｒｏＳｅ　ＩＤ（ＰｒｏＳｅ　ＩＤ　Ａ）を含める。

　ここで、通信路確立手続きを行うためのトリガーは、近隣検出手続きにおいて、ＵＥ１０ＡとＵＥ１０Ｂが近隣であることを検出し、ユーザが直接通信を行うようアプリケーションを操作し、アプリケーションレイヤが３ＧＰＰレイヤにＵＥ１０ＡとＵＥ１０Ｂ間で直接通信を行うよう要求する場合であっても良い。また、通信路確立手続きのトリガーは、ＵＥ１０ＡとＵＥ１０Ｂが近隣に存在することを検出した場合であっても良い。

　ここで、ＵＥ１０Ａは、直接通信要求に、ｉｎ　ｃｏｖｅｒａｇｅフラグ１４７、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙ１４８、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグ１４９を含めても良い。また、ｉｎ　ｃｏｖｅｒａｇｅフラグ１４７には、ＵＥ１０ＢがＬＴＥ基地局に在圏していること（Ｉｎ　ｃｏｖｅｒａｇｅ）（または、在圏していないこと（Ｏｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ））を示す情報を含めても良い。

　ここで、ＵＥ１０ＡがＬＴＥ基地局に在圏していることを検出する方法は、種々の方法が考えられるが、例えば、ｅＮＢ４５（ｅＮＢ－Ａ）から送信される情報を一定時間以内に受信していれば、ＬＴＥ基地局に在圏していると判断し、ｅＮＢ４５（ｅＮＢ－Ａ）から送信される情報を一定時間以内に受信していなければ、ＬＴＥ基地局に在圏していないと判断しても良い。

　さらに、通信路確立要求には、ＬＴＥ　ＤｉｒｅｃｔまたはＷＬＡＮ　Ｄｉｒｅｃｔかを示す識別子を含めてもよい。この識別子に応じて直接通信路を決定しても良い。なお、この識別子の決定には、アプリケーションに応じて決定されても良い。例えば、電話のような通話のアプリケーションであれば、ＬＴＥ　Ｄｉｒｅｃｔを利用し、大容量のビデオファイルを扱うアプリケーションであれば、ＷＬＡＮ　Ｄｉｒｅｃｔを利用するよう管理し、決定しても良い。

　また、近隣検出を行っているＵＥ１０ＡのＥｘｐｒｅｓｓｉｏｎコードや近隣検出の対象であるＵＥ１０ＡのＥｘｐｒｅｓｓｉｏｎコードを含めても良い。

　また、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙ１４８は、ｐｕｂｌｉｃ　ｓａｆｅｔｙを機能として保持していることを示す情報であり、ここでは、ＵＥ１０Ａはｐｕｂｌｉｃ　ｓａｆｅｔｙの機能を保持するため、「可」として通知しても良い。

　さらに、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグ１４９は、ｐｕｂｌｉｃ　ｓａｆｅｔｙを利用することを許可することを示す情報であり、ここでは、ＵＥ１０Ａはｐｕｂｌｉｃ　ｓａｆｅｔｙを許可しているため、「ｏｎ」として通知しても良い。

　さらに、ＵＥ１０Ａは、Ｎｏｎ―ｐｕｂｌｉｃ　ｓａｆｅｔｙにおける直接通信路を確立することを要求しても良い。また、ＵＥ１０Ａは、直接通信路を確立するためのリソースの取得を要求しても良い。ここで、ＵＥ１０Ａは、直接通信路を確立するためのリソースの取得は、ＵＥ１０Ａが取得すると通知しても良い。

　さらに、ＵＥ１０Ａは、Ｎｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙにおける直接通信路を確立することを示す識別子を含めても良い。また、ＵＥ１０Ａは、Ｐｕｂｌｉｃ　ｓａｆｅｔｙにおける直接通信路を確立することを示す識別子を含めても良い。

　ここで、ＵＥ１０Ａおよび、ＵＥ１０Ｂにおいて、Ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙ１４８がそれぞれ「可」になっていることを条件に、ＵＥ１０Ａは、Ｐｕｂｌｉｃ　ｓａｆｅｔｙの通信路確立となる直接通信要求を送信しても良い。また、ＵＥ１０Ａおよび、ＵＥ１０Ｂにおいて、Ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグ１４９がそれぞれ「ｏｎ」になっている場合、ＵＥ１０Ａは、Ｐｕｂｌｉｃ　ｓａｆｅｔｙの通信路確立となる直接通信要求を送信しても良い。

　また、ＵＥ１０Ａまたは、ＵＥ１０Ｂの少なくとも一方において、Ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙ１４８が「不可」になっている場合、ＵＥ１０Ａは、Ｐｕｂｌｉｃ　ｓａｆｅｔｙの通信路確立となる直接通信要求を送信しない。また、ＵＥ１０Ａまたは、ＵＥ１０Ｂの少なくとも一方において、Ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグ１４９が「ｏｆｆ」になっている場合、ＵＥ１０Ａは、Ｐｕｂｌｉｃ　ｓａｆｅｔｙの通信路確立となる直接通信要求を送信しない。　ＵＥ１０Ａは、ＵＥ１０ＢがＬＴＥ　Ｄｉｒｅｃｔを利用できることを検出している場合、ＬＴＥ　Ｄｉｒｅｃｔで直接通信路を確立することができる能力情報などを示す識別情報を含めても良い。また、ＵＥ１０Ａは、ＵＥ１０ＢがＷＬＡＮ　Ｄｉｒｅｃｔを利用できることを検出している場合、ＷＬＡＮ　Ｄｉｒｅｃｔで直接通信路を確立することができる能力情報などを示す識別情報を含めても良い。

　ここで、ＵＥ１０Ａおよび、ＵＥ１０Ｂにおいて、ＬＴＥ　Ｄｉｒｅｃｔで直接通信路を確立することができる能力情報などを示す識別情報により、双方が能力を有する場合には、ＵＥ１０Ａは、ＬＴＥ　Ｄｉｒｅｃｔの通信路の確立要求をＵＥ１０Ｂに送信しても良い。確立要求には、ＬＴＥ　Ｄｉｒｅｃｔの通信路の確立要求を示す識別情報を含めても良い。また、ＵＥ１０Ａおよび、ＵＥ１０Ｂにおいて、ＷＬＡＮ　Ｄｉｒｅｃｔで直接通信路を確立することができる能力情報などを示す識別情報により、双方が能力を有する場合には、ＵＥ１０Ａは、ＷＬＡＮ　Ｄｉｒｅｃｔの通信路の確立要求をＵＥ１０Ｂに送信しても良い。確立要求には、ＷＬＡＮ　Ｄｉｒｅｃｔの通信路の確立要求を示す識別情報を含めても良い。

　また、ＵＥ１０Ａまたは、ＵＥ１０Ｂの少なくとも一方において、ＬＴＥ　Ｄｉｒｅｃｔで直接通信路を確立することができる能力情報などを示す識別情報により、能力を保持しないことを検出した場合には、ＵＥ１０Ａは、ＬＴＥ　Ｄｉｒｅｃｔの通信路の確立要求をＵＥ１０Ｂに送信しない。また、ＵＥ１０Ａまたは、ＵＥ１０Ｂの少なくとも一方において、ＷＬＡＮ　Ｄｉｒｅｃｔで直接通信路を確立することができる能力情報などを示す識別情報により、能力を保持しないことを検出した場合には、ＵＥ１０Ａは、ＷＬＡＮ　Ｄｉｒｅｃｔの通信路の確立要求をＵＥ１０Ｂに送信しない。

　ＵＥ１０Ａから直接通信要求を受信したＵＥ１０Ｂは、直接通信要求に含められたＧｒｏｕｐ　ＩＤ（Ｇｒｏｕｐ　１）、ＰｒｏＳｅ　ＩＤ（ＰｒｏＳｅ　ＩＤ　Ａ）を確認する。このとき、ＵＥ１０Ｂは、ＵＥ１０ＡのＧｒｏｕｐ　ＩＤ、ＰｒｏＳｅ　ＩＤを確認し、ＵＥ１０Ａと直接通信できることを確認する。　また、ＵＥ１０Ｂは、ＵＥ１０ＡがＬＴＥ　Ｄｉｒｅｃｔで直接通信路を確立することができる能力情報などを示す識別情報を含めた場合、ＬＴＥ　Ｄｉｒｅｃｔで直接通信を行うことを決定しても良い。また、ＵＥ１０Ｂは、ＵＥ１０ＡがＷＬＡＮ　Ｄｉｒｅｃｔで直接通信路を確立することができる能力情報などを示す識別情報を含めた場合、ＷＬＡＮ　Ｄｉｒｅｃｔで直接通信を行うことを決定しても良い。

　直接通信要求を受信したＵＥ１０Ｂは、直接通信確認応答を送信する（Ｓ１００４）。ここで、ＵＥ１０Ｂは、Ｇｒｏｕｐ　ＩＤ（Ｇｒｏｕｐ　１）、ＰｒｏＳｅ　ＩＤ（ＰｒｏＳｅ　ＩＤ　Ｂ）を含める。このとき、ＵＥ１０Ａは、ＵＥ１０ＢのＧｒｏｕｐ　ＩＤ、ＰｒｏＳｅ　ＩＤを確認し、ＵＥ１０Ａと直接通信できることを確認する。

　ここで、ＵＥ１０Ｂは、直接通信要求に、ｉｎ　ｃｏｖｅｒａｇｅフラグ１４７、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙ１４８、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグ１４９を含めても良い。また、ｉｎ　ｃｏｖｅｒａｇｅフラグ１４７には、ＵＥ１０ＢがＬＴＥ基地局に在圏していること（Ｉｎ　ｃｏｖｅｒａｇｅ）（または、在圏していないこと（Ｏｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ））を示す情報を含めても良い。

　ここで、ＵＥ１０ＢがＬＴＥ基地局に在圏していることを検出する方法は、種々の方法が考えられるが、例えば、ｅＮＢ４５（ｅＮＢ－Ｂ）から送信される情報を一定時間以内に受信していれば、ＬＴＥ基地局に在圏していると判断し、ｅＮＢ４５（ｅＮＢ－Ｂ）から送信される情報を一定時間以内に受信していなければ、ＬＴＥ基地局に在圏していないと判断しても良い。また、近隣検出を行っているＵＥ１０ＡのＥｘｐｒｅｓｓｉｏｎコードや近隣検出の対象であるＵＥ１０ＢのＥｘｐｒｅｓｓｉｏｎコードを含めても良い。

　また、ＵＥ１０Ｂは、直接通信確認応答をここで行わず、後で行っても良い。具体的には、ＵＥ１０ＢがＲＲＣ認証直接通信承諾通知を受信した（Ｓ１０２４）の後や、ＵＥ１０ＢがＲＲＣ認証直接通信完了通知を送信した（Ｓ１０２６）の後であっても良い。なお、直接通信確認応答を後で行う場合、ＵＥ１０Ｂは、ＲＲＣ認証直接通信要求を送信しても良い（Ｓ１００６）。

　次に、ＵＥ１０Ａ、ＵＥ１０Ｂは、サービス要求手続きにより、ＲＲＣ接続状態に遷移する（Ｓ１００５）。なお、サービス要求手続きは、ＬＴＥにおいてデータの送受信を開始する際に、従来から利用されている手続きを利用することができる。

　ＲＲＣ接続状態に遷移したＵＥ１０Ｂは、ＲＲＣ認証直接通信要求をｅＮＢ－Ｂに送信する（Ｓ１００６）。ＲＲＣ認証直接通信要求には、Ｇｒｏｕｐ　ＩＤ、ＰｒｏＳｅ　ＩＤ　Ａ、ＰｒｏＳｅ　ＩＤ　Ｂ、Ｇｒｏｕｐ　ＩＤ（Ｇｒｏｕｐ　１）、ＡＰＰサーバ情報を含める。ＰｒｏＳｅ　ＩＤ　Ａは、ＵＥ１０Ａを示すＵＥ識別子情報であり、ＰｒｏＳｅ　ＩＤ　Ｂは、ＵＥ１０Ｂを示すＵＥ識別子情報である。ＡＰＰサーバ情報は、直接通信を行うアプリケーションにおいてサービスを提供するサーバに関する情報である。

　ここで、ＵＥ１０Ｂは、ＵＥ１０ＡからのＮｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙにおける通信リソースを示す識別子からＮｏｎ―ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを要求しても良い。具体的な要求方法として、Ｎｏｎ－ｐｕｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを要求するための識別子を含めても良い。また、Ｎｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースではなく、Ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを示す識別子を含めても良い。ここで、ＵＥ１０ＢはあらかじめＰｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースで通信をするか、Ｎｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースで通信をするかをアプリケーションに応じて管理するなどしてよい。このようにこの識別子は、アプリケーションに応じて決定されても良い。また、この識別子は、ＵＥ１０ＡのＩｎ　ｃｏｖｅｒａｇｅフラグ１４７およびＵＥ１０ＢのＩｎ　ｃｏｖｅｒａｇｅフラグ１４７に応じて決定されても良い。

　このＮｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙまたは、ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを示す識別子を利用して、ｅＮＢ―ＢまたはＭＭＥ―Ｂは、割り当てる通信リソースを選択しても良い。　ここで、通信リソースとは、時間、周波数、符号であって良いし、その他の干渉を回避するための情報であってよい。またはこれらの時間、周波数、符号等の情報の組み合わせであっても良い。また、通信リソースに対して、送信するアンテナに関する情報や送信するために必要な送信電力情報を含んでいても良い。

　ＲＲＣ認証直接通信要求を受信したｅＮＢ－Ｂは、Ｇｒｏｕｐ　ＩＤ、ＰｒｏＳｅ　ＩＤ　Ａ、ＰｒｏＳｅ　ＩＤ　Ｂ、Ｇｒｏｕｐ　ＩＤ、ＡＰＰサーバ情報を確認する。なお、Ｎｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙまたは、ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを示す識別子が含まれている場合、ｅＮＢ―Ｂは、Ｐｕｂｌｉｃ　ｓａｆｅｔｙを用途とした通信路か、商用サービスを用途とした通信路かを識別する識別情報に基づいて通信リソースの割り当てを実行し、通信リソースに関する情報をＵＥ１０Ｂに通知することを決定しても良い。なお、ｅＮＢ－Ｂは、あらかじめ、Ｐｕｂｌｉｃ　Ｓａｆｅｔｙで利用可能な通信リソースと、Ｎｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを分けて管理し、上記決定に応じて、Ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースまたは、Ｎｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを割り当てても良い。

　一方、ＲＲＣ接続状態に遷移したＵＥ１０Ａは、ＲＲＣ認証直接通信要求をｅＮＢ－Ａに送信する（Ｓ１００８）。ＲＲＣ認証直接通信要求には、Ｇｒｏｕｐ　ＩＤ、ＰｒｏＳｅ　ＩＤ　Ａ、ＰｒｏＳｅ　ＩＤ　Ｂ、Ｇｒｏｕｐ　ＩＤ（Ｇｒｏｕｐ　１）、ＡＰＰサーバ情報を含める。

　ここで、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅである場合、ＵＥ１０Ａは、Ｎｏｎ―ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを要求しても良い。具体的な要求方法として、Ｎｏｎ－ｐｕｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを要求するための識別子を含めても良い。また、Ｎｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースではなく、Ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを示す識別子を含めても良い。ここで、ＵＥ１０ＡはあらかじめＰｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースで通信をするか、Ｎｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースで通信をするかをアプリケーションに応じて管理するなどしてよい。このようにこの識別子は、アプリケーションに応じて決定されても良い。また、この識別子は、ＵＥ１０ＡのＩｎ　ｃｏｖｅｒａｇｅフラグ１４７およびＵＥ１０ＡのＩｎ　ｃｏｖｅｒａｇｅフラグ１４７に応じて決定されても良い。

　このＮｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙまたは、ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを示す識別子を利用して、ｅＮＢ―ＡまたはＭＭＥ―Ａは、割り当てる通信リソースを選択しても良い。

　ここで、通信リソースとは、時間、周波数、符号であって良いし、その他の干渉を回避するための情報であってよい。またはこれらの時間、周波数、符号等の情報の組み合わせであっても良い。また、通信リソースに対して、送信するアンテナに関する情報や送信するために必要な送信電力情報を含んでいても良い。

　ｅＮＢ－Ｂは、Ｓ１－ＡＰ認証直接通信要求をＭＭＥ－Ｂに送信する（Ｓ１０１０）。ここで、Ｓ１－ＡＰ認証直接通信要求には、Ｇｒｏｕｐ　ＩＤ、ＰｒｏＳｅ　ＩＤ　Ａ、ＰｒｏＳｅ　ＩＤ　Ｂ、Ｇｒｏｕｐ　ＩＤ、ＡＰＰサーバ情報を含める。

　ここで、ｅＮＢ－Ｂは、ＭＭＥ－ＢにＮｏｎ―ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを要求しても良い。具体的な要求方法として、Ｎｏｎ－ｐｕｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを要求するための識別子を含めても良い。また、Ｎｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースではなく、Ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを示す識別子を含めても良い。ここで、ｅＮＢ－ＢはあらかじめＰｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースで通信をするか、Ｎｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースで通信をするかＵＥ１０Ｂからの通知により決定してよい。

　このＮｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙまたは、ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを示す識別子を利用して、ＭＭＥ―Ｂは、割り当てる通信リソースを選択しても良い。ここで、通信リソースとは、時間、周波数、符号であって良いし、その他の干渉を回避するための情報であってよい。またはこれらの時間、周波数、符号等の情報の組み合わせであっても良い。また、通信リソースに対して、送信するアンテナに関する情報や送信するために必要な送信電力情報を含んでいても良い。

　Ｓ１－ＡＰ認証直接通信要求を受信したＭＭＥ－Ｂは、Ｇｒｏｕｐ　ＩＤ、ＰｒｏＳｅ　ＩＤ　Ａ、ＰｒｏＳｅ　ＩＤ　Ｂ、Ｇｒｏｕｐ　ＩＤ、ＡＰＰサーバ情報を確認する。なお、Ｎｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙまたは、ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを示す識別子が含まれている場合、ＭＭＥ―Ｂは、Ｐｕｂｌｉｃ　ｓａｆｅｔｙを用途とした通信路か、商用サービスを用途とした通信路かを識別する識別情報に基づいて通信リソースの割り当てを実行し、通信リソースに関する情報をＵＥ１０Ｂに通知することを決定しても良い。なお、ＭＭＥ－Ｂは、あらかじめ、Ｐｕｂｌｉｃ　Ｓａｆｅｔｙで利用可能な通信リソースと、Ｎｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを分けて管理し、上記決定に応じて、Ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースまたは、Ｎｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを割り当てても良い。

　また、ＲＲＣ認証直接通信要求を受信したｅＮＢ－Ａは、Ｇｒｏｕｐ　ＩＤ、ＰｒｏＳｅ　ＩＤ　Ａ、ＰｒｏＳｅ　ＩＤ　Ｂ、Ｇｒｏｕｐ　ＩＤ、ＡＰＰサーバ情報を確認する。なお、Ｎｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙまたは、ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを示す識別子が含まれている場合、ｅＮＢ―Ａは、Ｐｕｂｌｉｃ　ｓａｆｅｔｙを用途とした通信路か、商用サービスを用途とした通信路かを識別する識別情報に基づいて通信リソースの割り当てを実行し、通信リソースに関する情報をＵＥ１０Ａに通知することを決定しても良い。なお、ｅＮＢ－Ａは、あらかじめ、Ｐｕｂｌｉｃ　Ｓａｆｅｔｙで利用可能な通信リソースと、Ｎｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを分けて管理し、上記決定に応じて、Ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースまたは、Ｎｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを割り当てても良い。

　ｅＮＢ－Ａは、Ｓ１－ＡＰ認証直接通信要求をＭＭＥ－Ａに送信する（Ｓ１０１２）。ここで、Ｓ１－ＡＰ認証直接通信要求には、Ｇｒｏｕｐ　ＩＤ、ＰｒｏＳｅ　ＩＤ　Ａ、ＰｒｏＳｅ　ＩＤ　Ｂ、Ｇｒｏｕｐ　ＩＤ、ＡＰＰサーバ情報を含める。

　ここで、ｅＮＢ－Ａは、ＭＭＥ－ＡにＮｏｎ―ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを要求しても良い。具体的な要求方法として、Ｎｏｎ－ｐｕｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを要求するための識別子を含めても良い。また、Ｎｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースではなく、Ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを示す識別子を含めても良い。ここで、ｅＮＢ－ＡはあらかじめＰｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースで通信をするか、Ｎｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースで通信をするかＵＥ１０Ａからの通知により決定してよい。

　このＮｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙまたは、ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを示す識別子を利用して、ＭＭＥ―Ａは、割り当てる通信リソースを選択しても良い。ここで、通信リソースとは、時間、周波数、符号であって良いし、その他の干渉を回避するための情報であってよい。またはこれらの時間、周波数、符号等の情報の組み合わせであっても良い。また、通信リソースに対して、送信するアンテナに関する情報や送信するために必要な送信電力情報を含んでいても良い。

　Ｓ１―ＡＰ認証直接通信要求を受信したＭＭＥ－Ａは、Ｇｒｏｕｐ　ＩＤ、ＰｒｏＳｅ　ＩＤ　Ａ、ＰｒｏＳｅ　ＩＤ　Ｂ、Ｇｒｏｕｐ　ＩＤ、ＡＰＰサーバ情報を確認する。なお、Ｎｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙまたは、ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを示す識別子が含まれている場合、ＭＭＥ―Ａは、Ｐｕｂｌｉｃ　ｓａｆｅｔｙを用途とした通信路か、商用サービスを用途とした通信路かを識別する識別情報に基づいて通信リソースの割り当てを実行し、通信リソースに関する情報をＵＥ１０Ａに通知することを決定しても良い。なお、ＭＭＥ－Ａは、あらかじめ、Ｐｕｂｌｉｃ　Ｓａｆｅｔｙで利用可能な通信リソースと、Ｎｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを分けて管理し、上記決定に応じて、Ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースまたは、Ｎｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを割り当てても良い。

　次に、ＭＭＥＡは直接通信を確立することを認証し、ＵＥＢがどのＭＭＥに属しているかを識別する（Ｓ１０１４）。ここで、ＭＭＥＡは、ＵＥＡとＵＥＢが直接通信を確立しても良いかを確認する。また、ＭＭＥＡは、ＭＭＥＢを含むＭＭＥ４０に問合せを行い、ＵＥＢが属すＭＭＥＢを検出する。なお、各ＭＭＥ４０がＵＥ１０Ｂを検出する方法は種々の方法が考えられるが、例えば、ＭＭＥ４０において管理するＵＥ識別子を検出することで、検出しても良い。

　ＵＥＢが属すＭＭＥ―Ｂを検出したＭＭＥ－Ａは、ＭＭＥ－ＢおよびｅＮＢＡにＳ１－ＡＰ認証直接通信の通知を送信する（Ｓ１０１６）。ここで、Ｓ１－ＡＰ認証直接通信の通知には、Ｇｒｏｕｐ　ＩＤ、ＰｒｏＳｅ　ＩＤ　Ａ、ＰｒｏＳｅ　ＩＤ　Ｂ、送信パラメータを含める。ここで、送信パラメータとは、ＵＥ１０ＡとＵＥ１０Ｂ間で直接通信を行うために必要となる情報要素のことで、例えば、通信リソースや送信範囲を示す情報（レンジクラス）を含めても良い。

　ＭＭＥ－ＡからＳ１－ＡＰ認証直接通信の通知を受信したＭＭＥ－Ｂは、Ｓ１－ＡＰ認証直接通信の通知を送信する（Ｓ１０１８）。ここで、Ｓ１－ＡＰ認証直接通信の通知には、Ｇｒｏｕｐ　ＩＤ、ＰｒｏＳｅ　ＩＤ　Ａ、ＰｒｏＳｅ　ＩＤ　Ｂ、送信パラメータを含める。

　また、Ｓ１－ＡＰ認証直接通信の通知を受信したｅＮＢ―ＡはＵＥ１０Ａに、ＲＲＣ認証直接通信承諾通知を送信する（Ｓ１０２０）。ここで、ＲＲＣ認証直接通信承諾通知には、Ｇｒｏｕｐ　ＩＤ、ＰｒｏＳｅ　ＩＤ　Ａ、ＰｒｏＳｅ　ＩＤ　Ｂ、送信パラメータを含める。ここで、送信パラメータとして、ＭＭＥ－Ａが通知した送信パラメータに加え、ｅＮＢ－Ａにおいて、送信パラメータを加えても良い。なお、ＲＲＣ認証直接通信要求（Ｓ１００６）に、Ｎｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙまたは、ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを示す識別子が含まれている場合、ｅＮＢ―Ａは、Ｐｕｂｌｉｃ　ｓａｆｅｔｙを用途とした通信路か、商用サービスを用途とした通信路かを識別する識別情報に基づいて通信リソースの割り当てを実行し、通信リソースに関する情報をＵＥ１０Ｂに通知しても良い。なお、ｅＮＢ－Ａは、あらかじめ、Ｐｕｂｌｉｃ　Ｓａｆｅｔｙで利用可能な通信リソースと、Ｎｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを分けて管理し、上記決定に応じて、Ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースまたは、Ｎｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを割り当てても良い。ＲＲＣ認証直接通信承諾通知を受信したＵＥ１０Ａは、直接通信で利用するＧｒｏｕｐ　ＩＤ、ＰｒｏＳｅ　ＩＤ　Ａ、ＰｒｏＳｅ　ＩＤ　Ｂ、送信パラメータを確認する。

　次に、ＵＥ１０Ａは、ＲＲＣ認証直接通信完了通知を送信する（Ｓ１０２２）。ここで、ＲＲＣ認証直接通信完了通知には、ＰｒｏＳｅ　ＩＤ　Ａ、ＰｒｏＳｅ　ＩＤ　Ｂ、Ｇｒｏｕｐ　ＩＤを含める。ＲＲＣ認証直接通信完了通知を送信したＵＥ１０ＡはＵＥ１０Ｂと直接通信を開始する準備を行っても良い。

　一方、Ｓ１－ＡＰ認証直接通信の通知を受信したｅＮＢ―ＢはＵＥ１０Ｂに、ＲＲＣ認証直接通信承諾通知を送信する（Ｓ１０２４）。ここで、ＲＲＣ認証直接通信承諾通知には、Ｇｒｏｕｐ　ＩＤ、ＰｒｏＳｅ　ＩＤ　Ａ、ＰｒｏＳｅ　ＩＤ　Ｂ、送信パラメータを含める。ここで、送信パラメータとして、ＭＭＥ―Ｂが通知した送信パラメータに加え、ｅＮＢ－Ｂにおいて、送信パラメータを加えても良い。なお、ＲＲＣ認証直接通信要求（Ｓ１００８）に、Ｎｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙまたは、ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを示す識別子が含まれている場合、ｅＮＢ―Ｂは、Ｐｕｂｌｉｃ　ｓａｆｅｔｙを用途とした通信路か、商用サービスを用途とした通信路かを識別する識別情報に基づいて通信リソースの割り当てを実行し、通信リソースに関する情報をＵＥ１０Ｂに通知しても良い。なお、ｅＮＢ－Ｂは、あらかじめ、Ｐｕｂｌｉｃ　Ｓａｆｅｔｙで利用可能な通信リソースと、Ｎｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを分けて管理し、上記決定に応じて、Ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースまたは、Ｎｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを割り当てても良い。ＲＲＣ認証直接通信承諾通知を受信したＵＥ１０Ｂは、直接通信で利用するＧｒｏｕｐ　ＩＤ、ＰｒｏＳｅ　ＩＤ　Ａ、ＰｒｏＳｅ　ＩＤ　Ｂ、送信パラメータを確認する。

　次に、ＵＥ１０Ｂは、ＲＲＣ認証直接通信完了通知を送信する（Ｓ１０２６）。ここで、ＲＲＣ認証直接通信完了通知には、ＰｒｏＳｅ　ＩＤ　Ａ、ＰｒｏＳｅ　ＩＤ　Ｂ、Ｇｒｏｕｐ　ＩＤを含める。ＲＲＣ認証直接通信完了通知を送信したＵＥ１０ＢはＵＥ１０Ａと直接通信を開始する準備を行っても良い。

　ＵＥ１０ＡとＵＥ１０Ｂと直接通信を開始する（Ｓ１０２８）。このとき、ＵＥ１０ＡとＵＥ１０ＢはｅＮＢ－ＡまたはｅＮＢ－Ｂから送信された送信パラメータにより、直接通信路を確立する。また、ＵＥ１０Ａは、ＵＥ１０Ｂに直接通信に利用するＩＰアドレスを割り当てても良い。一方、ＵＥ１０Ｂは、ＵＥ１０Ａに直接通信に利用するＩＰアドレスを割り当てても良い。

　以上の手続きにより、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅである１状態において通信路確立を行うことができる。

　［１．３．２．１．２　ＵＥ１０Ａ：Ｏｕｔ　ｏｆ　ｃｏｖｅｒｇｅ　ＵＥ１０Ｂ：Ｏｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ］
　次に、図１１を用いて、ＵＥ１０ＡがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅである１状態における通信路確立手続きについて説明する。ＵＥ１０ＡがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅである場合、ｅＮＢ－Ａ、ｅＮＢ－Ｂ、ＭＭＥ－Ａ、ＭＭＥ－Ｂと制御情報を送受信することができない。つまり、図１１において、Ｓ１００５からＳ１０２６までの手続きを行わずに、通信路確立を行う。

　まず、ＵＥ１０ＡはＵＥ１０Ｂに直接通信要求を送信する（Ｓ１００２）。このとき、直接通信要求にＧｒｏｕｐ　ＩＤとＰｒｏＳｅ　ＩＤ（ＰｒｏＳｅ　ＩＤ　Ａ）を含める。

　さらに、通信路確立要求には、ＬＴＥ　ＤｉｒｅｃｔまたはＷＬＡＮ　Ｄｉｒｅｃｔかを示す識別子を含めてもよい。この識別子に応じて直接通信路を決定しても良い。

　ここで、ＵＥ１０Ａは、あらかじめＵＥ１０Ａが保持するリソースから直接通信路に割り当て、リソースに関する情報を含めて、直接通信路の確立要求をＵＥ１０Ｂに送信しても良い。

　さらに、ＵＥ１０ＡがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅであるため、ＵＥ１０Ａは、ｐｕｂｌｉｃ　ｓａｆｅｔｙにおける直接通信路を確立することを決定しても良い。

　さらに、ＵＥ１０Ａは、Ｐｕｂｌｉｃ　ｓａｆｅｔｙにおける直接通信路を確立することを示す識別子を含めても良い。また、カバレッジ情報から少なくても一方のＵＥが圏外であることを検出し、この検出に基づいて、Ｎｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙを用途とした直接通信路の確立要求は送信しない。

　また、ＵＥ１０Ａまたは、ＵＥ１０Ｂの少なくとも一方において、Ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙ１４８が「不可」になっている場合、ＵＥ１０Ａは、直接通信要求を送信しない。また、ＵＥ１０Ａまたは、ＵＥ１０Ｂの少なくとも一方において、Ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグ１４９が「ｏｆｆ」になっている場合、ＵＥ１０Ａは、直接通信要求を送信しない。直接通信要求を受信したＵＥ１０Ｂは、Ｇｒｏｕｐ　ＩＤとＰｒｏＳｅ　ＩＤを確認し、ＵＥ１０Ａと直接通信できることを確認する。

　ＵＥ１０Ａと直接通信できることを確認したＵＥ１０ＢはＵＥ１０Ａに直接通信確認応答を送信する（Ｓ１００４）。このとき、直接通信要求にＧｒｏｕｐ　ＩＤとＰｒｏＳｅ　ＩＤ（ＰｒｏＳｅ　ＩＤ　Ｂ）を含める。以上により、ＵＥ１０ＡとＵＥ１０Ｂは直接通信できる程度に近隣であることを検出する。

　さらに、ＵＥ１０Ｂは、ＵＥ１０Ａからのｐｕｂｌｉｃ　ｓａｆｅｔｙにおける通信リソースを示す情報を利用してｐｕｂｌｉｃ　ｓａｆｅｔｙにおける直接通信路を確立することを決定しても良い。

　次に、ＵＥ１０Ａは、ＵＥ１０Ａと直接通信の開始を行う（Ｓ１０２８）。

　ここで、ＵＥ１０Ａは、直接通信確認応答受信後（Ｓ１００４）、あらかじめＵＥ１０Ａが保持するリソースを直接通信路に割り当て、リソースに関する情報をＵＥ１０Ｂに通知しても良い。

　以上の手続きにより、ＵＥ１０ＡがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅである１状態において通信路確立を行うことができる。

　［１．３．２．１．３　ＵＥ１０Ａ：Ｏｕｔ　ｏｆ　ｃｏｖｅｒｇｅ　ＵＥ１０Ｂ：Ｉｎ　ｃｏｖｅｒａｇｅ］
　図１２を用いて、ＵＥ１０ＡがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅである１状態における通信路確立手続きについて説明する。なお、本手続きでは、ＵＥ１０Ｂは、ｅＮＢ－Ｂに在圏し、ｅＮＢ－Ｂは、ＭＭＥ－Ｂによって管理されている。ここで、ＭＭＥ－ＡまたはＭＭＥ－Ｂには、ＰｒｏＳｅサーバ９０（ＰｒｏＳｅサーバＡ、ＰｒｏＳｅサーバＢ）であっても良い。

　まず、ＵＥ１０Ａは、ＵＥ１０Ｂに直接通信要求を送信する（Ｓ１２０２）。ここで、ＵＥ１０Ａは、ＵＥ１０Ａの管理するＧｒｏｕｐ　ＩＤ（Ｇｒｏｕｐ　１）およびＰｒｏＳｅ　ＩＤ（ＰｒｏＳｅ　ＩＤ　Ａ）を含める。ここで、通信路確立手続きを行うためのトリガーは、近隣検出手続きにおいて、ＵＥ１０ＡとＵＥ１０Ｂが近隣であることを検出し、ユーザが直接通信を行うようアプリケーションを操作し、アプリケーションレイヤが３ＧＰＰレイヤにＵＥ１０ＡとＵＥ１０Ｂ間で直接通信を行うよう要求する場合であっても良い。また、通信路確立手続きのトリガーは、ＵＥ１０ＡとＵＥ１０Ｂが近隣に存在することを検出した場合であっても良い。　ここで、ＵＥ１０Ａは、直接通信要求に、ｉｎ　ｃｏｖｅｒａｇｅフラグ１４７、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙ１４８、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグ１４９を含めても良い。また、ｉｎ　ｃｏｖｅｒａｇｅフラグ１４７には、ＵＥ１０ＢがＬＴＥ基地局に在圏していること（Ｉｎ　ｃｏｖｅｒａｇｅ）（または、在圏していないこと（Ｏｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ））を示す情報を含めても良い。

　さらに、ＵＥ１０Ａは、Ｐｕｂｌｉｃ　ｓａｆｅｔｙにおける直接通信路を確立することを要求しても良い。また、ＵＥ１０Ａは、直接通信路を確立するためのリソースの取得を要求しても良い。ここで、ＵＥ１０Ａは、直接通信路を確立するためのリソースの取得は、ＵＥ１０Ａが取得すると通知しても良い。

　なお、直接通信要求を送信したＵＥ１０ＡはＵＥ１０Ｂと直接通信を開始する準備を行っても良い。また、ＵＥ１０ＡがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅであるため、ＵＥ１０Ａは、ｐｕｂｌｉｃ　ｓａｆｅｔｙにおける直接通信路を確立することを決定しても良い。

　さらに、ＵＥ１０Ａは、Ｐｕｂｌｉｃ　ｓａｆｅｔｙにおける直接通信路を確立することを要求しても良い。また、ＵＥ１０Ａは、直接通信路を確立するためのリソースの取得を要求しても良い。さらに、ＵＥ１０Ａは、Ｐｕｂｌｉｃ　ｓａｆｅｔｙにおける直接通信路を確立することを示す識別子を含めても良い。また、カバレッジ情報から少なくても一方のＵＥが圏外であることを検出し、この検出に基づいて、Ｎｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙを用途とした直接通信路の確立要求は送信しない。

　また、ＵＥ１０Ａまたは、ＵＥ１０Ｂの少なくとも一方において、Ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙ１４８が「不可」になっている場合、ＵＥ１０Ａは、直接通信要求を送信しない。また、ＵＥ１０Ａまたは、ＵＥ１０Ｂの少なくとも一方において、Ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグ１４９が「ｏｆｆ」になっている場合、ＵＥ１０Ａは、直接通信要求を送信しない。　ＵＥ１０Ａは、ＵＥ１０ＢがＬＴＥ　Ｄｉｒｅｃｔを利用できることを検出している場合、ＬＴＥ　Ｄｉｒｅｃｔで直接通信路を確立することができる能力情報などを示す識別情報を含めても良い。また、ＵＥ１０Ａは、ＵＥ１０ＢがＷＬＡＮ　Ｄｉｒｅｃｔを利用できることを検出している場合、ＷＬＡＮ　Ｄｉｒｅｃｔで直接通信路を確立することができる能力情報などを示す識別情報を含めても良い。

　ＵＥ１０Ａから直接通信要
　ここで、ＵＥ１０Ａおよび、ＵＥ１０Ｂにおいて、ＬＴＥ　Ｄｉｒｅｃｔで直接通信路を確立することができる能力情報などを示す識別情報により、双方が能力を有する場合には、ＵＥ１０Ａは、ＬＴＥ　Ｄｉｒｅｃｔの通信路の確立要求をＵＥ１０Ｂに送信しても良い。確立要求には、ＬＴＥ　Ｄｉｒｅｃｔの通信路の確立要求を示す識別情報を含めても良い。また、ＵＥ１０Ａおよび、ＵＥ１０Ｂにおいて、ＷＬＡＮ　Ｄｉｒｅｃｔで直接通信路を確立することができる能力情報などを示す識別情報により、双方が能力を有する場合には、ＵＥ１０Ａは、ＷＬＡＮ　Ｄｉｒｅｃｔの通信路の確立要求をＵＥ１０Ｂに送信しても良い。確立要求には、ＷＬＡＮ　Ｄｉｒｅｃｔの通信路の確立要求を示す識別情報を含めても良い。

　また、ＵＥ１０Ａまたは、ＵＥ１０Ｂの少なくとも一方において、ＬＴＥ　Ｄｉｒｅｃｔで直接通信路を確立することができる能力情報などを示す識別情報により、能力を保持しないことを検出した場合には、ＵＥ１０Ａは、ＬＴＥ　Ｄｉｒｅｃｔの通信路の確立要求をＵＥ１０Ｂに送信しない。また、ＵＥ１０Ａまたは、ＵＥ１０Ｂの少なくとも一方において、ＷＬＡＮ　Ｄｉｒｅｃｔで直接通信路を確立することができる能力情報などを示す識別情報により、能力を保持しないことを検出した場合には、ＵＥ１０Ａは、ＷＬＡＮ　Ｄｉｒｅｃｔの通信路の確立要求をＵＥ１０Ｂに送信しない。求を受信したＵＥ１０Ｂは、直接通信要求に含められたＧｒｏｕｐ　ＩＤ（Ｇｒｏｕｐ　１）、ＰｒｏＳｅ　ＩＤ（ＰｒｏＳｅ　ＩＤ　Ａ）を確認する。このとき、ＵＥ１０Ｂは、ＵＥ１０ＡのＧｒｏｕｐ　ＩＤ、ＰｒｏＳｅ　ＩＤを確認し、ＵＥ１０Ａと直接通信できることを確認する。　直接通信要求を受信したＵＥ１０Ａは、直接通信確認応答を送信する（Ｓ１２０４）。ここで、ＵＥ１０Ｂは、Ｇｒｏｕｐ　ＩＤ（Ｇｒｏｕｐ　１）、ＰｒｏＳｅ　ＩＤ（ＰｒｏＳｅ　ＩＤ　Ｂ）を含める。このとき、ＵＥ１０Ａは、ＵＥ１０ＢのＧｒｏｕｐ　ＩＤ、ＰｒｏＳｅ　ＩＤを確認し、ＵＥ１０Ａと直接通信できることを確認する。

　また、ＵＥ１０Ｂは、ＵＥ１０ＡがＬＴＥ　Ｄｉｒｅｃｔで直接通信路を確立することができる能力情報などを示す識別情報を含めた場合、ＬＴＥ　Ｄｉｒｅｃｔで直接通信を行うことを決定しても良い。また、ＵＥ１０Ｂは、ＵＥ１０ＡがＷＬＡＮ　Ｄｉｒｅｃｔで直接通信路を確立することができる能力情報などを示す識別情報を含めた場合、ＷＬＡＮ　Ｄｉｒｅｃｔで直接通信を行うことを決定しても良い。

　次に、ＵＥ１０Ｂは、サービス要求手続きにより、ＲＲＣ接続状態に遷移する（Ｓ１２０６）。ＲＲＣ接続状態に遷移したＵＥ１０Ｂは、ＲＲＣ認証直接通信要求をｅＮＢ－Ｂに送信する（Ｓ１２０８）。ＲＲＣ認証直接通信要求には、Ｇｒｏｕｐ　ＩＤ、ＰｒｏＳｅ　ＩＤ　Ａ、ＰｒｏＳｅ　ＩＤ　Ｂ、Ｇｒｏｕｐ　ＩＤ（Ｇｒｏｕｐ　１）、ＡＰＰサーバ情報を含める。ＰｒｏＳｅ　ＩＤ　Ａは、ＵＥ１０Ａを示すＵＥ識別子情報であり、ＰｒｏＳｅ　ＩＤ　Ｂは、ＵＥ１０Ｂを示すＵＥ識別子情報である。ＡＰＰサーバ情報は、直接通信を行うアプリケーションにおいてサービスを提供するサーバに関する情報である。

　ここで、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅである場合、ＵＥ１０Ｂは、ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを要求しても良い。具体的な要求方法として、Ｎｏｎ－ｐｕｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを要求するための識別子を含めても良い。また、Ｎｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースではなく、Ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを示す識別子を含めても良い。ここで、ＵＥ１０ＢはあらかじめＰｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースで通信をするか、Ｎｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースで通信をするかをアプリケーションに応じて管理するなどしてよい。このようにこの識別子は、アプリケーションに応じて決定されても良い。また、この識別子は、ＵＥ１０ＡのＩｎ　ｃｏｖｅｒａｇｅフラグ１４７およびＵＥ１０ＢのＩｎ　ｃｏｖｅｒａｇｅフラグ１４７に応じて決定されても良い。

　このＮｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙまたは、ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを示す識別子を利用して、ｅＮＢ―ＢまたはＭＭＥ―Ｂは、割り当てる通信リソースを選択しても良い。　ここで、通信リソースとは、時間、周波数、符号であって良いし、その他の干渉を回避するための情報であってよい。またはこれらの時間、周波数、符号等の情報の組み合わせであっても良い。また、通信リソースに対して、送信するアンテナに関する情報や送信するために必要な送信電力情報を含んでいても良い。　ＲＲＣ認証直接通信要求を受信したｅＮＢ－Ｂは、Ｇｒｏｕｐ　ＩＤ、ＰｒｏＳｅ　ＩＤ　Ａ、ＰｒｏＳｅ　ＩＤ　Ｂ、Ｇｒｏｕｐ　ＩＤ、ＡＰＰサーバ情報を確認する。なお、Ｎｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙまたは、ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを示す識別子が含まれている場合、ｅＮＢ―Ｂは、Ｐｕｂｌｉｃ　ｓａｆｅｔｙを用途とした通信路か、商用サービスを用途とした通信路かを識別する識別情報に基づいて通信リソースの割り当てを実行し、通信リソースに関する情報をＵＥ１０Ｂに通知することを決定しても良い。なお、ｅＮＢ－Ｂは、あらかじめ、Ｐｕｂｌｉｃ　Ｓａｆｅｔｙで利用可能な通信リソースと、Ｎｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを分けて管理し、上記決定に応じて、Ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースまたは、Ｎｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを割り当てても良い。
次に、ｅＮＢ－ＢはＳ１－ＡＰ認証直接通信要求をＭＭＥ－Ｂに送信する（Ｓ１２１０）。ここで、Ｓ１－ＡＰ認証直接通信要求には、Ｇｒｏｕｐ　ＩＤ、ＰｒｏＳｅ　ＩＤ　Ａ、ＰｒｏＳｅ　ＩＤ　Ｂ、Ｇｒｏｕｐ　ＩＤ、ＡＰＰサーバ情報を含める。

　ここで、ｅＮＢ－Ｂは、ＭＭＥ－ＢにＰｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを要求しても良い。具体的な要求方法として、Ｎｏｎ－ｐｕｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを要求するための識別子を含めても良い。また、Ｎｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースではなく、Ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを示す識別子を含めても良い。ここで、ｅＮＢ－ＢはあらかじめＰｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースで通信をするか、Ｎｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースで通信をするかＵＥ１０Ｂからの通知により決定してよい。

　次に、ＭＭＥ―Ｂは直接通信を確立することを認証する（Ｓ１２１２）。ここで、ＭＭＥＢは、ＵＥＡとＵＥＢが直接通信を確立しても良いかを確認する。

　次に、ＭＭＥ－Ｂは、ｅＮＢ－ＢにＳ１－ＡＰ認証直接通信の通知を送信する（Ｓ１２１４）。ここで、Ｓ１－ＡＰ認証直接通信の通知には、Ｇｒｏｕｐ　ＩＤ、ＰｒｏＳｅ　ＩＤ　Ａ、ＰｒｏＳｅ　ＩＤ　Ｂ、送信パラメータを含める。

　さらに、Ｓ１－ＡＰ認証直接通信の通知を受信したｅＮＢ―ＢはＵＥ１０Ｂに、ＲＲＣ認証直接通信承諾通知を送信する（Ｓ１２１６）。ここで、ＲＲＣ認証直接通信承諾通知には、Ｇｒｏｕｐ　ＩＤ、ＰｒｏＳｅ　ＩＤ　Ａ、ＰｒｏＳｅ　ＩＤ　Ｂ、送信パラメータを含める。ここで、送信パラメータとして、ＭＭＥ－Ｂが通知した送信パラメータに加え、ｅＮＢ－Ｂにおいて、送信パラメータを加えても良い。なお、ＲＲＣ認証直接通信要求（Ｓ１２０８）に、Ｎｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙまたは、ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを示す識別子が含まれている場合、ｅＮＢ―Ｂは、Ｐｕｂｌｉｃ　ｓａｆｅｔｙを用途とした通信路か、商用サービスを用途とした通信路かを識別する識別情報に基づいて通信リソースの割り当てを実行し、通信リソースに関する情報をＵＥ１０Ｂに通知しても良い。なお、ｅＮＢ－Ｂは、あらかじめ、Ｐｕｂｌｉｃ　Ｓａｆｅｔｙで利用可能な通信リソースと、Ｎｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを分けて管理し、上記決定に応じて、Ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースまたは、Ｎｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを割り当てても良い。ＲＲＣ認証直接通信承諾通知を受信したＵＥ１０Ｂは、直接通信で利用するＧｒｏｕｐ　ＩＤ、ＰｒｏＳｅ　ＩＤ　Ａ、ＰｒｏＳｅ　ＩＤ　Ｂ、送信パラメータを確認する。

　次に、ＵＥ１０Ｂは、ＲＲＣ認証直接通信完了通知を送信する（Ｓ１２１８）。ここで、ＲＲＣ認証直接通信完了通知には、ＰｒｏＳｅ　ＩＤ　Ａ、ＰｒｏＳｅ　ＩＤ　Ｂ、Ｇｒｏｕｐ　ＩＤを含める。ＲＲＣ認証直接通信完了通知を送信したＵＥ１０ＡはＵＥ１０Ｂと直接通信を開始する準備を行っても良い。

　ＵＥ１０ＡとＵＥ１０Ｂと直接通信を開始する（Ｓ１２２０）。このとき、ＵＥ１０ＢはｅＮＢ－Ｂから送信された送信パラメータをＵＥ１０Ａに通知しても良い。また、ＵＥ１０Ｂは、ＵＥ１０Ａに直接通信に利用するＩＰアドレスを割り当てても良い。

　以上の手続きにより、ＵＥ１０ＡがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅである１状態において通信路確立を行うことができる。

　［１．３．２．１．４　ＵＥ１０Ａ：Ｉｎ　ｃｏｖｅｒｇｅ　ＵＥ１０Ｂ：Ｏｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ］
　図１３を用いて、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅである１状態における通信路確立手続きについて説明する。なお、本手続きでは、ＵＥ１０Ａは、ｅＮＢ－Ａに在圏し、ｅＮＢ－Ａは、ＭＭＥ－Ａによって管理されている。ここで、ＭＭＥ－ＡまたはＭＭＥ－Ｂには、ＰｒｏＳｅサーバ９０（ＰｒｏＳｅサーバＡ、ＰｒｏＳｅサーバＢ）であっても良い。

　まず、ＵＥ１０Ａは、ＵＥ１０Ｂに直接通信要求を送信する（Ｓ１３０２）。ここで、ＵＥ１０Ａは、ＵＥ１０Ａの管理するＧｒｏｕｐ　ＩＤ（Ｇｒｏｕｐ　１）およびＰｒｏＳｅ　ＩＤ（ＰｒｏＳｅ　ＩＤ　Ａ）を含める。ここで、通信路確立手続きを行うためのトリガーは、近隣検出手続きにおいて、ＵＥ１０ＡとＵＥ１０Ｂが近隣であることを検出し、ユーザが直接通信を行うようアプリケーションを操作し、アプリケーションレイヤが３ＧＰＰレイヤにＵＥ１０ＡとＵＥ１０Ｂ間で直接通信を行うよう要求する場合であっても良い。また、通信路確立手続きのトリガーは、ＵＥ１０ＡとＵＥ１０Ｂが近隣に存在することを検出した場合であっても良い。　ここで、ＵＥ１０Ａは、直接通信要求に、ｉｎ　ｃｏｖｅｒａｇｅフラグ１４７、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙ１４８、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグ１４９を含めても良い。また、ｉｎ　ｃｏｖｅｒａｇｅフラグ１４７には、ＵＥ１０ＢがＬＴＥ基地局に在圏していること（Ｉｎ　ｃｏｖｅｒａｇｅ）（または、在圏していないこと（Ｏｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ））を示す情報を含めても良い。

　なお、直接通信要求を送信したＵＥ１０ＡはＵＥ１０Ｂと直接通信を開始する準備を行っても良い。

　また、通信路確立要求には、ＬＴＥ　ＤｉｒｅｃｔまたはＷＬＡＮ　Ｄｉｒｅｃｔかを示す識別子を含めてもよい。この識別子に応じて直接通信路を決定しても良い。なお、この識別子の決定には、アプリケーションに応じて決定されても良い。例えば、電話のような通話のアプリケーションであれば、ＬＴＥ　Ｄｉｒｅｃｔを利用し、大容量のビデオファイルを扱うアプリケーションであれば、ＷＬＡＮ　Ｄｉｒｅｃｔを利用するよう管理し、決定しても良い。

　さらに、ＵＥ１０Ａは、Ｎｏｎ―ｐｕｂｌｉｃ　ｓａｆｅｔｙにおける直接通信路を確立することを要求しても良い。また、ＵＥ１０Ａは、直接通信路を確立するためのリソースの取得は、ＵＥ１０Ａが取得すると通知しても良い。さらに、ＵＥ１０Ａは、Ｐｕｂｌｉｃ　ｓａｆｅｔｙにおける直接通信路を確立することを示す識別子を含めても良い。また、カバレッジ情報から少なくても一方のＵＥが圏外であることを検出し、この検出に基づいて、Ｎｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙを用途とした直接通信路の確立要求は送信しない。

　また、ＵＥ１０Ａまたは、ＵＥ１０Ｂの少なくとも一方において、Ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙ１４８が「不可」になっている場合、ＵＥ１０Ａは、直接通信要求を送信しない。また、ＵＥ１０Ａまたは、ＵＥ１０Ｂの少なくとも一方において、Ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグ１４９が「ｏｆｆ」になっている場合、ＵＥ１０Ａは、直接通信要求を送信しない。

　ＵＥ１０Ａは、ＵＥ１０ＢがＬＴＥ　Ｄｉｒｅｃｔを利用できることを検出している場合、ＬＴＥ　Ｄｉｒｅｃｔで直接通信路を確立することができる能力情報などを示す識別情報を含めても良い。また、ＵＥ１０Ａは、ＵＥ１０ＢがＷＬＡＮ　Ｄｉｒｅｃｔを利用できることを検出している場合、ＷＬＡＮ　Ｄｉｒｅｃｔで直接通信路を確立することができる能力情報などを示す識別情報を含めても良い。

　ＵＥ１０Ａから直接通信要求を受信したＵＥ１０Ｂは、直接通信要求に含められたＧｒｏｕｐ　ＩＤ（Ｇｒｏｕｐ　１）、ＰｒｏＳｅ　ＩＤ（ＰｒｏＳｅ　ＩＤ　Ａ）を確認する。このとき、ＵＥ１０Ｂは、ＵＥ１０ＡのＧｒｏｕｐ　ＩＤ、ＰｒｏＳｅ　ＩＤを確認し、ＵＥ１０Ａと直接通信できることを確認する。

　さらに、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅであるため、ＵＥ１０Ａは、ｐｕｂｌｉｃ　ｓａｆｅｔｙにおける直接通信路を確立することを決定しても良い。

　直接通信要求を受信したＵＥ１０Ｂは、直接通信確認応答を送信する（Ｓ１３０４）。ここで、ＵＥ１０Ｂは、Ｇｒｏｕｐ　ＩＤ（Ｇｒｏｕｐ　１）、ＰｒｏＳｅ　ＩＤ（ＰｒｏＳｅ　ＩＤ　Ｂ）を含める。このとき、ＵＥ１０Ａは、ＵＥ１０ＢのＧｒｏｕｐ　ＩＤ、ＰｒｏＳｅ　ＩＤを確認し、ＵＥ１０Ａと直接通信できることを確認する。

　次に、ＵＥ１０Ａは、サービス要求手続きにより、ＲＲＣ接続状態に遷移する（Ｓ１３０６）。ＲＲＣ接続状態に遷移したＵＥ１０Ａは、ＲＲＣ認証直接通信要求をｅＮＢ－Ａに送信する（Ｓ１３０８）。ＲＲＣ認証直接通信要求には、Ｇｒｏｕｐ　ＩＤ、ＰｒｏＳｅ　ＩＤ　Ａ、ＰｒｏＳｅ　ＩＤ　Ｂ、Ｇｒｏｕｐ　ＩＤ（Ｇｒｏｕｐ　１）、ＡＰＰサーバ情報を含める。ＲＲＣ認証直接通信要求を送信することにより、直接通信路確立に対する許可を要求しても良い。また、ＲＲＣ認証直接通信要求を送信することにより、直接通信路に対するリソースを要求することを示しても良い。

　ここで、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅである場合、ＵＥ１０Ａは、Ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを要求しても良い。具体的な要求方法として、Ｎｏｎ－ｐｕｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを要求するための識別子を含めても良い。また、Ｎｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースではなく、Ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを示す識別子を含めても良い。ここで、ＵＥ１０ＡはあらかじめＰｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースで通信をするか、Ｎｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースで通信をするかをアプリケーションに応じて管理するなどしてよい。このようにこの識別子は、アプリケーションに応じて決定されても良い。また、この識別子は、ＵＥ１０ＡのＩｎ　ｃｏｖｅｒａｇｅフラグ１４７およびＵＥ１０ＢのＩｎ　ｃｏｖｅｒａｇｅフラグ１４７に応じて決定されても良い。

　このＮｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙまたは、ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを示す識別子を利用して、ｅＮＢ―ＡまたはＭＭＥ―Ａは、割り当てる通信リソースを選択しても良い。ここで、通信リソースとは、時間、周波数、符号であって良いし、その他の干渉を回避するための情報であってよい。またはこれらの時間、周波数、符号等の情報の組み合わせであっても良い。また、通信リソースに対して、送信するアンテナに関する情報や送信するために必要な送信電力情報を含んでいても良い。　ＲＲＣ認証直接通信要求を受信したｅＮＢ－Ａは、Ｇｒｏｕｐ　ＩＤ、ＰｒｏＳｅ　ＩＤ　Ａ、ＰｒｏＳｅ　ＩＤ　Ｂ、Ｇｒｏｕｐ　ＩＤ、ＡＰＰサーバ情報を確認する。なお、Ｎｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙまたは、ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを示す識別子が含まれている場合、ｅＮＢ―Ａは、Ｐｕｂｌｉｃ　ｓａｆｅｔｙを用途とした通信路か、商用サービスを用途とした通信路かを識別する識別情報に基づいて通信リソースの割り当てを実行し、通信リソースに関する情報をＵＥ１０Ａに通知することを決定しても良い。なお、ｅＮＢ－Ａは、あらかじめ、Ｐｕｂｌｉｃ　Ｓａｆｅｔｙで利用可能な通信リソースと、Ｎｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを分けて管理し、上記決定に応じて、Ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースまたは、Ｎｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを割り当てても良い。

　次にｅＮＢ－Ａは、Ｓ１－ＡＰ認証直接通信要求をＭＭＥ－Ａに送信する（Ｓ１３１０）。ここで、Ｓ１－ＡＰ認証直接通信要求には、Ｇｒｏｕｐ　ＩＤ、ＰｒｏＳｅ　ＩＤ　Ａ、ＰｒｏＳｅ　ＩＤ　Ｂ、Ｇｒｏｕｐ　ＩＤ、ＡＰＰサーバ情報を含める。

　ここで、ｅＮＢ－Ａは、ＭＭＥ－ＡにＰｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを要求しても良い。具体的な要求方法として、Ｎｏｎ－ｐｕｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを要求するための識別子を含めても良い。また、Ｎｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースではなく、Ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを示す識別子を含めても良い。ここで、ｅＮＢ－ＡはあらかじめＰｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースで通信をするか、Ｎｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースで通信をするかＵＥ１０Ａからの通知により決定してよい。

　次に、ＭＭＥ―Ａは直接通信を確立することを認証する（Ｓ１３１２）。ここで、ＭＭＥ―Ａは、ＵＥＡとＵＥＢが直接通信を確立しても良いかを確認する。

　次に、ＭＭＥ―Ａは、ｅＮＢ－ＡにＳ１－ＡＰ認証直接通信の通知を送信する（Ｓ１３１４）。ここで、Ｓ１－ＡＰ認証直接通信の通知には、Ｇｒｏｕｐ　ＩＤ、ＰｒｏＳｅ　ＩＤ　Ａ、ＰｒｏＳｅ　ＩＤ　Ｂ、送信パラメータを含める。

　さらに、Ｓ１－ＡＰ認証直接通信の通知を受信したｅＮＢ―ＡはＵＥ１０Ａに、ＲＲＣ認証直接通信承諾通知を送信する（Ｓ１３１６）。ここで、ＲＲＣ認証直接通信承諾通知には、Ｇｒｏｕｐ　ＩＤ、ＰｒｏＳｅ　ＩＤ　Ａ、ＰｒｏＳｅ　ＩＤ　Ｂ、送信パラメータを含める。ここで、送信パラメータとして、ＭＭＥ－Ａが通知した送信パラメータに加え、ｅＮＢ－Ａにおいて、送信パラメータを加えても良い。なお、ＲＲＣ認証直接通信要求（Ｓ１３０８）に、Ｎｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙまたは、ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを示す識別子が含まれている場合、ｅＮＢ―Ａは、Ｐｕｂｌｉｃ　ｓａｆｅｔｙを用途とした通信路か、商用サービスを用途とした通信路かを識別する識別情報に基づいて通信リソースの割り当てを実行し、通信リソースに関する情報をＵＥ１０Ｂに通知しても良い。なお、ｅＮＢ－Ａは、あらかじめ、Ｐｕｂｌｉｃ　Ｓａｆｅｔｙで利用可能な通信リソースと、Ｎｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを分けて管理し、上記決定に応じて、Ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースまたは、Ｎｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙで利用可能な通信リソースを割り当てても良い。ＲＲＣ認証直接通信承諾通知を受信したＵＥ１０Ａは、直接通信で利用するＧｒｏｕｐ　ＩＤ、ＰｒｏＳｅ　ＩＤ　Ａ、ＰｒｏＳｅ　ＩＤ　Ｂ、送信パラメータを確認する。

　次に、ＵＥ１０Ａは、ＲＲＣ認証直接通信完了通知を送信する（Ｓ１３１８）。ここで、ＲＲＣ認証直接通信完了通知には、ＰｒｏＳｅ　ＩＤ　Ａ、ＰｒｏＳｅ　ＩＤ　Ｂ、Ｇｒｏｕｐ　ＩＤを含める。ＲＲＣ認証直接通信完了通知を送信したＵＥ１０ＡはＵＥ１０Ｂと直接通信を開始する準備を行っても良い。

　ＵＥ１０ＡとＵＥ１０Ｂと直接通信を開始する（Ｓ１３２０）。このとき、ＵＥ１０ＡはｅＮＢ－Ａから送信された送信パラメータをＵＥ１０Ｂに通知しても良い。また、ＵＥ１０Ａは、ＵＥ１０Ｂに直接通信に利用するＩＰアドレスを割り当てても良い。

　なお、上記で説明した手続きにおいて、ＭＭＥ４０とＰｒｏＳｅサーバ９０が異なる装置で構成された場合、ＭＭＥ４０（ＭＭＥ－ＡまたはＭＭＥ－Ｂ）の処理は、ＰｒｏＳｅサーバ９０で行っても良い。

　以上の手続きにより、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅである１状態において通信路確立を行うことができる。

　［１．３．２．２　通信路確立手続き２］
　ここでは、通信路確立手続き１とは異なる通信路確立手続き２について説明する。通信路確立手続き１との違いは、ＵＥが直接通信を識別するための直接通信ＩＤを割り当てることにある。なお、通信路確立手続き２においても、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅである１状態のそれぞれの状態で、異なる通信路確立手続きを行う。

　［１．３．２．２．１　ＵＥ１０Ａ：Ｉｎ　ｃｏｖｅｒｇｅ　ＵＥ１０Ｂ：Ｉｎ　ｃｏｖｅｒａｇｅ　ＵＥ１０Ａ：Ｉｎ　ｃｏｖｅｒａｇｅ　ＵＥ１０Ｂ：Ｏｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ］
　図１４を用いて、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅである場合の通信路確立手続きについて説明する。

　なお、本手続きは、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅである場合の通信路確立手続きについても同様に利用可能である。ここで、通信路確立手続きを行うためのトリガーは、近隣検出手続きにおいて、ＵＥ１０ＡとＵＥ１０Ｂが近隣であることを検出し、ユーザが直接通信を行うようアプリケーションを操作し、アプリケーションレイヤが３ＧＰＰレイヤにＵＥ１０ＡとＵＥ１０Ｂ間で直接通信を行うよう要求する場合であっても良い。また、通信路確立手続きのトリガーは、ＵＥ１０ＡとＵＥ１０Ｂが近隣に存在することを検出した場合であっても良い。

　さらに、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅである場合、ＵＥ１０Ａは、ｎｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙにおける直接通信路を確立することを決定し、ｎｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙにおける通信路を確立するためのリソースを要求することを決定しても良い。

　さらに、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅである場合、ＵＥ１０Ａは、ｐｕｂｌｉｃ　ｓａｆｅｔｙにおける直接通信路を確立することを決定し、ｐｕｂｌｉｃ　ｓａｆｅｔｙにおける通信路を確立するためのリソースを要求することを決定しても良い。

　まずＵＥ１０Ａは、ネットワーク認証手続きを行う（Ｓ４００３）。図１５を用いてネットワーク認証手続きを説明する。まず、ＵＥ１０Ａは、拡張したサービス要求を送信する（Ｓ５００４）。ここで、ＵＥ１０Ａは、拡張したサービス要求に、直接通信要求、ｅｘｐｒｅｓｓｉｏｎコードを含めて通知する。

　ここで、ＵＥ１０Ａは、拡張したサービス要求に、ｉｎ　ｃｏｖｅｒａｇｅフラグ１４７、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙ１４８、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグ１４９を含めても良い。また、ｉｎ　ｃｏｖｅｒａｇｅフラグ１４７には、ＵＥ１０ＢがＬＴＥ基地局に在圏していること（Ｉｎ　ｃｏｖｅｒａｇｅ）（または、在圏していないこと（Ｏｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ））を示す情報を含めても良い。

　さらに、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅである場合、ＵＥ１０Ａは、ｎｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙにおける直接通信路を確立することを決定し、ｎｏｎ－ｐｕｂｌｉｃ　ｓａｆｅｔｙにおける通信路を確立するためのリソースを要求しても良い。

　さらに、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅである場合、ＵＥ１０Ａは、ｐｕｂｌｉｃ　ｓａｆｅｔｙにおける直接通信路を確立することを決定し、ｐｕｂｌｉｃ　ｓａｆｅｔｙにおける通信路を確立するためのリソースを要求しても良い。

　ここで、ＵＥ１０Ａおよび、ＵＥ１０Ｂにおいて、ＬＴＥ　Ｄｉｒｅｃｔで直接通信路を確立することができる能力情報などを示す識別情報により、双方が能力を有する場合には、ＵＥ１０Ａは、ＬＴＥ　Ｄｉｒｅｃｔの通信路の確立要求をＭＭＥ４０に送信しても良い。確立要求には、ＬＴＥ　Ｄｉｒｅｃｔの通信路の確立要求を示す識別情報を含めても良い。また、ＵＥ１０Ａおよび、ＵＥ１０Ｂにおいて、ＷＬＡＮ　Ｄｉｒｅｃｔで直接通信路を確立することができる能力情報などを示す識別情報により、双方が能力を有する場合には、ＵＥ１０Ａは、ＷＬＡＮ　Ｄｉｒｅｃｔの通信路の確立要求をＭＭＥ４０に送信しても良い。確立要求には、ＷＬＡＮ　Ｄｉｒｅｃｔの通信路の確立要求を示す識別情報を含めても良い。

　また、ＵＥ１０Ａまたは、ＵＥ１０Ｂの少なくとも一方において、ＬＴＥ　Ｄｉｒｅｃｔで直接通信路を確立することができる能力情報などを示す識別情報により、能力を保持しないことを検出した場合には、ＵＥ１０Ａは、ＬＴＥ　Ｄｉｒｅｃｔの通信路の確立要求をＭＭＥ４０に送信しない。また、ＵＥ１０Ａまたは、ＵＥ１０Ｂの少なくとも一方において、ＷＬＡＮ　Ｄｉｒｅｃｔで直接通信路を確立することができる能力情報などを示す識別情報により、能力を保持しないことを検出した場合には、ＵＥ１０Ａは、ＷＬＡＮ　Ｄｉｒｅｃｔの通信路の確立要求をＭＭＥ４０に送信しない。

　拡張したサービス要求を受信したＭＭＥ４０は、拡張したサービス要求に直接通信要求、ｅｘｐｒｅｓｓｉｏｎコードを検出する。また、ｉｎ　ｃｏｖｅｒａｇｅフラグ１４７が含まれている場合には、ｉｎ　ｃｏｖｅｒａｇｅフラグ１４７を確認する。ここで、ｉｎ　ｃｏｖｅｒａｇｅフラグ１４７には、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅである場合と、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅである場合がある。

　また、ＭＭＥ４０は、ＵＥ１０ＡがＬＴＥ　Ｄｉｒｅｃｔで直接通信路を確立することができる能力情報などを示す識別情報により、ＵＥ１０ＡがＬＴＥ　Ｄｉｒｅｃｔを利用できることを検出しても良い。また、ＭＭＥ４０は、ＵＥ１０ＡがＷＬＡＮ　Ｄｉｒｅｃｔで直接通信路を確立することができる能力情報などを示す識別情報により、ＵＥ１０ＡがＷＬＡＮ　Ｄｉｒｅｃｔを利用できることを検出しても良い。

　次に、ＭＭＥ４０は、ＵＥ１０ＡからＰＧＷ３０までＥＰＳベアラを確立する（Ｓ５００６）。なお、ＥＰＳベアラの確立は、従来から利用されている手続きを利用し、ＵＥ１０ＡとｅＮＢ４５、ｅＮＢ４５とＳＧＷ３５、ＳＧＷ３５とＰＧＷ３０間でベアラを確立することである。

　次に、ＭＭＥ４０は、ＵＥ１０Ｂに直接通信終端側手続きを行う（Ｓ５００８）。ここで、ＭＭＥ４０は、ｉｎ　ｃｏｖｅｒａｇｅフラグが含められている場合であって、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅの場合、直接通信終端手続きを行わなくても良い。一方、Ｉｎ　ｃｏｖｅｒａｇｅフラグ１４７が含められ、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅの場合、直接通信終端手続きを行う。図１６を用いて直接通信終端側手続きを説明する。まず、ＭＭＥ４０は、ＵＥ１０Ｂにページングを送信する（Ｓ６００２）。ここで、ページングには、直接通信を示す識別子を含める。ページングを受信したＵＥ１０ＢはページングがＵＥ１０Ｂ宛てであることと、直接通信が要求されていることを検出する。

　次に、ＵＥ１０Ｂは拡張したサービス要求を送信する（Ｓ６００４）。ここで、ＵＥ１０Ｂは、直接通信を示す識別子を含められたため、直接通信要求を示す情報を含める。拡張したサービス要求を受信したＭＭＥ４０は、ＵＥ１０ＢがＵＥ１０Ａと直接通信を行うことを認証する。ここで、ＭＭＥ４０は、ＵＥ１０Ｂからページングの応答として拡張したサービス要求を一定時間以内に検出できない場合、ＵＥ１０ＢはＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅであると判断しても良い。ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅであると判断した場合、以降の手続きを行わず、図１５におけるＳ５００８に戻って、続くＳ５０１０の手続きを開始しても良い。続いて、ＭＭＥ４０は、ＵＥ１０ＢからＰＧＷ３０までＥＰＳベアラを確立する（Ｓ６００６）。なお、ＥＰＳベアラの確立は、従来から利用されている手続きを利用し、ＵＥ１０ＢとｅＮＢ４５、ｅＮＢ４５とＳＧＷ３５、ＳＧＷ３５とＰＧＷ３０間でベアラを確立することである。

　続いて、ＭＭＥ４０は、ｅＮＢ４５へＳ１－ＡＰ直接通信確立通知を送信する（Ｓ６００８）。なお、Ｓ１－ＡＰ直接通信確立通知には、直接通信有効化フラグを含める。

　Ｓ１－ＡＰ直接通信確立通知を受信したｅＮＢ４５は、ＵＥ１０ＢとＲＲＣ接続再設定を行う（Ｓ６０１０）。ｅＮＢ４５はＵＥ１０とＲＲＣ接続再設定を行ったことを確認し、Ｓ１－ＡＰ直接通信確立完了通知をＭＭＥ４０へ送信する（Ｓ６０１２）。

　以上の手続きにより、直接通信終端側手続きを行うことができる。Ｓ１－ＡＰ直接通信確立完了通知を受信したＭＭＥ４０は、ｅＮＢ４５へＳ１－ＡＰ直接通信確立通知を送信する（Ｓ５０１０）。なお、Ｓ１－ＡＰ直接通信確立通知には、直接通信有効化フラグを含める。

　Ｓ１－ＡＰ直接通信確立通知を受信したｅＮＢ４５は、ＵＥ１０ＢとＲＲＣ接続再設定を行う（Ｓ５０１２）。ｅＮＢ４５はＵＥ１０とＲＲＣ接続再設定を行ったことを確認し、Ｓ１－ＡＰ直接通信確立完了通知をＭＭＥ４０へ送信する（Ｓ５０１４）。
以上の手続きにより、ＵＥ１０ＡとＵＥ１０Ｂは直接通信を開始するためのネットワーク認証手続きを行うことができる。

　次に、ネットワーク認証手続きが完了したＵＥ１０ＡとＵＥ１０Ｂは、互いに直接通信警報を送信する（Ｓ４００４）。この通知により、ＵＥ１０ＡとＵＥ１０Ｂは、直接通信を開始することを検出する。

　次に、ＵＥ１０Ａは、直接通信要求をＵＥ１０Ｂに送信する（Ｓ４００６）。

　さらに、直接通信要求には、ＬＴＥ　ＤｉｒｅｃｔまたはＷＬＡＮ　Ｄｉｒｅｃｔかを示す識別子を含めてもよい。この識別子に応じて直接通信路を決定しても良い。なお、この識別子の決定には、アプリケーションに応じて決定されても良い。例えば、電話のような通話のアプリケーションであれば、ＬＴＥ　Ｄｉｒｅｃｔを利用し、大容量のビデオファイルを扱うアプリケーションであれば、ＷＬＡＮ　Ｄｉｒｅｃｔを利用するよう管理し、決定しても良い。

　一方、ＵＥ１０Ｂは、直接通信要求により、ＵＥ１０ＡがＬＴＥ　Ｄｉｒｅｃｔで直接通信路を確立することができる能力情報などを示す識別情報により、ＵＥ１０ＡがＬＴＥ　Ｄｉｒｅｃｔを利用できることを検出しても良い。また、ＵＥ１０Ｂは、ＵＥ１０ＡがＷＬＡＮ　Ｄｉｒｅｃｔで直接通信路を確立することができる能力情報などを示す識別情報により、ＵＥ１０ＡがＷＬＡＮ　Ｄｉｒｅｃｔを利用できることを検出しても良い。

　続いて、ＵＥ１０ＡとＵＥ１０Ｂはセキュリティを確保するための手続きを行う（Ｓ４００８）。ここで、ＵＥ１０ＡはＵＥ１０Ｂとセキュリティを確保する方法は、種々の方法が考えられるが、例えば、あらかじめＵＥ１０ＡとＵＥ１０Ｂ間で暗号化キーを保持し、ＩＰｓｅｃを利用することである。

　ＵＥ１０ＡとＵＥ１０Ｂ間でセキュリティを確保した後、ＵＥ１０Ｂは、直接通信承諾通知をＵＥ１０Ａへ送信する（Ｓ４０１０）。直接通信承諾通知には、直接通信ＩＤ、ＱｏＳ、ＩＰアドレスを含める。ここで、直接通信ＩＤは、ＵＥ１０ＡとＵＥ１０Ｂで確立する直接通信を識別するための識別子である。また、ＱｏＳは、あらかじめ決まっているものを利用して通知しても良いし、複数の候補から選択して通知しても良い。また、ＩＰアドレスは、種々の方法により生成する方法があるが、例えば、ＵＥ１０Ｂにおいて、ＩＰｖ６リンクローカルアドレスを生成して通知する方法がある。ここで生成したＩＰｖ６リンクローカルアドレスは、ＵＥ１０Ｂが利用するＩＰアドレスとして通知しても良く、ＵＥ１０Ａが利用するＩＰアドレスとして通知しても良い。直接通信承諾通知を受信したＵＥ１０Ａは、直接通信承諾通知に含まれる直接通信ＩＤ、ＱｏＳ、ＵＥ１０ＡのＩＰアドレスを確認する。

　次に、ＵＥ１０ＡはＵＥ１０Ｂへ直接通信完了通知を送信する。直接通信完了通知には、直接通信ＩＤ、ＱｏＳ、ＵＥ１０ＢのＩＰアドレスを含める。ここで、直接通信ＩＤは、ＵＥ１０Ｂが通知してきた直接通信ＩＤである。また、ＱｏＳは、ＵＥ１０Ｂが通知してきたＱｏＳである。さらに、ＩＰアドレスは、ＵＥ１０Ａにおいて、ＩＰｖ６リンクローカルアドレスを生成して通知する。ここで生成したＩＰｖ６リンクローカルアドレスは、ＵＥ１０Ｂが利用するＩＰアドレスとして通知しても良く、ＵＥ１０Ａが利用するＩＰアドレスとして通知しても良い。ただし、ＵＥ１０ＢがＵＥ１０ＡのＩＰアドレスを通知した場合には、ＵＥ１０Ａは、ＵＥ１０ＢのＩＰアドレスを通知する。また、ＵＥ１０ＢがＵＥＢのＩＰアドレスを通知した場合には、ＵＥ１０Ａは、ＵＥ１０ＡのＩＰアドレスを通知する。

　次に、ＵＥ１０ＡとＵＥ１０Ｂは、直接通信における無線ベアラの確立を行う（Ｓ４０１４）。

　以上の手続きにより、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅである１状態において通信路確立を行うことができる。また、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅである１状態において通信路確立を行うことができる。

　［１．３．２．２．２　ＵＥ１０Ａ：Ｏｕｔ　ｏｆ　ｃｏｖｅｒｇｅ、ＵＥ１０Ｂ：Ｏｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ］
　図１４を用いて、ＵＥ１０ＡがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅの場合における通信路確立手続きについて説明する。ＵＥ１０ＡがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅの場合、ネットワーク認証手続き（Ｓ４００３）を行わずに、直接通信警報から手続きを開始する（Ｓ４００４）。

　さらに、ＵＥ１０ＡがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅであるため、ＵＥ１０Ａは、ｐｕｂｌｉｃ　ｓａｆｅｔｙにおける直接通信路を確立することを決定しても良い。それ以外の手続きは、[１．３．２．２．１　ＵＥ１０Ａ：Ｉｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０Ｂ：Ｉｎ　ｃｏｖｅｒａｇｅ]で説明した方法と同様の方法を利用することができる。

　［１．３．２．２．３　ＵＥ１０Ａ：Ｏｕｔ　ｏｆ　ｃｏｖｅｒｇｅ、ＵＥ１０Ｂ：Ｉｎ　ｃｏｖｅｒａｇｅ］
　ＵＥ１０ＡがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅの場合における通信路確立手続きについて説明する。ＵＥ１０ＡがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅの場合であっても、図１４、図１５で示す手続きを利用することができる。ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅの場合との違いは、図１５におけるＵＥ１０ＡがＵＥ１０Ｂとして動作し、ＵＥ１０ＡがＵＥ１０Ｂとして動作すれば良い。　ここで、ＵＥ１０ＡがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅである場合、ＵＥ１０Ａは、ｐｕｂｌｉｃ　ｓａｆｅｔｙにおける直接通信路を確立することを決定し、ｐｕｂｌｉｃ　ｓａｆｅｔｙにおける通信路を確立するためのリソースを要求しても良い。

　以上の手続きにより、ＵＥ１０ＡがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅの場合における通信路確立を行うことができる。

　以上により、通信元ＵＥおよび通信先ＵＥがＬＴＥ基地局に在圏していることを検出することができる。通信元ＵＥまたは通信先ＵＥがＬＴＥ基地局に在圏する場合、移動通信事業者の制御の元、通信路確立手続きを行うことができる。

　［２．　第２実施形態］
　続いて、第２実施形態について説明する。第２実施形態は、近隣検出手続きが異なる。本実施形態では、図１における移動通信システムの構成を利用することができるため、その詳細な説明を省略する。また、移動通信システムにおけるＵＥの構成やＰｒｏＳｅ　Ｓｅｒｖｅｒの構成、ＡＰＰサーバの構成も同様であるため、その詳細な説明を省略する。

　[２．３　処理の説明]
　[２．３．１　近隣検出手続き]
　図１７を用いて、本実施形態における近隣検出手続きについて説明する。ここで、ＰｒｏＳｅサーバ９０は、ＭＭＥ４０であっても良い。

　まず、ＵＥ１０Ａは、フレンドリストを取得する（Ｓ２００２）。ここでＵＥ１０Ａは、あらかじめユーザの設定によりフレンドリストを保持していても良く、ＡＰＰサーバ９５と通信を行い、ＡＰＰサーバ９５からフレンドリストを取得しても良い。また、ここで取得するフレンドリストは、アプリケーションレイヤで管理される識別子情報である。識別子情報の例としては、ＳｋｙｐｅやＬＩＮＥといった個別のアプリケーションのユーザＩＤ等を用いてもよい。

　次に、ＵＥ１０Ａのアプリケーションは、ＵＥ１０Ａの３ＧＰＰレイヤにＥｘｐｒｅｓｓｉｏｎコードを要求する（Ｓ２００４）。この要求は、ＵＥ１０がＰｒｏＳｅのサービスを行うことに対する認証要求メッセージであっても良いし、ＵＥ１０がＰｒｏＳｅのサービスを行うことに対するサービス要求メッセージであっても良いし、ＵＥ１０をＰｒｏＳｅのサービスに登録するための登録要求メッセージであってもよい。また、対象とするＰｒｏＳｅのサービスは、近隣端末検出に対するサービスであってもよいし、近隣通信端末との直接通信路の確立を提供するサービスであってもよいし、その両方を含んだサービスであってもよい。

　Ｅｘｐｒｅｓｓｉｏｎコードの要求には、ＡＰＰリストやフレンドリストやＵＥ　ＩＤを含めて送信しても良い。ＵＥＩＤはＵＥ１０を識別するＩＭＳＩ（Ｉｎｔｅｒｎａｔｉｏｎａｌ　Ｍｏｂｉｌｅ　Ｓｕｂｓｃｒｉｂｅｒ　Ｉｄｅｎｔｙ）であってもよいし、アプリケーションで用いるユーザ識別情報であってもよい。ここで、ＵＥ１０はＡＰＰ１において、ＵＥ１０ａとＰｒｏＳｅによる通信（または近隣検出）を行うため、ＡＰＰリストにはＡＰＰ１が含まれ、フレンドリストにはＵＥ１０Ｂが含まれる。ここで、複数のアプリケーションでＰｒｏＳｅによる通信を行う場合、複数のアプリケーションが通知されても良い。また、複数のＵＥとＰｒｏＳｅによる通信を行う場合、複数のＵＥの識別情報をフレンドリストに含めても良い。

　なお、ＡＰＰリストおよびフレンドリストはアプリケーションで管理される識別情報であってよい。

　さらに、ＵＥ１０Ａの３ＧＰＰレイヤは、ＰｒｏＳｅサーバ９０にＥｘｐｒｅｓｓｉｏｎコードを要求する（Ｓ２００６）。Ｅｘｐｒｅｓｓｉｏｎコードの要求には、ＡＰＰリストおよびフレンドリストを含める。ここで、ＡＰＰリストおよびフレンドリストはＵＥ１０ＡのアプリケーションがＳ２００４で通知したＡＰＰリストおよびフレンドリストである。

　Ｅｘｐｒｅｓｓｉｏｎコードの要求を受信したＰｒｏＳｅサーバ９０は、Ｅｘｐｒｅｓｓｉｏｎコードの要求に含まれたＡＰＰリスト（ＡＰＰ１）とフレンドリストを抽出する。次に、ＰｒｏＳｅサーバ９０は、ＡＰＰリストを基に、ＡＰＰサーバ９５を探索する。ＡＰＰサーバ９５を探索したＰｒｏＳｅサーバ９０は、ＡＰＰサーバ９５と通信を行い、Ｅｘｐｒｅｓｓｉｏｎコードを生成するパラメータを取得する（Ｓ２００８）。ここで、Ｅｘｐｒｅｓｓｉｏｎコードを生成するパラメータとして、例えば、Ｅｘｐｒｅｓｓｉｏｎコードを暗号化するための暗号化キーを取得しても良く、またＥｘｐｒｅｓｓｉｏｎコードを生成するためのアルゴリズムを取得しても良い。

　続いて、ＰｒｏＳｅサーバ９０は、Ｅｘｐｒｅｓｓｉｏｎコードを生成する（Ｓ２０１０）。Ｅｘｐｒｅｓｓｉｏｎコードは、ＵＥ１０から受信したＡＰＰリスト１４２およびフレンドリスト１４４やＡＰＰサーバ９５から取得した情報を利用してＥｘｐｒｅｓｓｉｏｎコードを生成する。ここで、フレンドリストに含まれる通信対象ＵＥに対するＥｘｐｒｅｓｓｉｏｎコードを生成するだけでなく、Ｅｘｐｒｅｓｓｉｏｎコードの要求を送信したＵＥ１０ＡにおけるＥｘｐｒｅｓｓｉｏｎコードを生成する。

　次に、ＰｒｏＳｅサーバ９０は、Ｅｘｐｒｅｓｓｉｏｎコードの応答をＵＥ１０へ送信する（Ｓ２０１４）。ここで、ＰｒｏＳｅサーバ９０は、Ｓ２０１０で生成したＥｘｐｒｅｓｓｉｏｎコードを含める。また、ＰｒｏＳｅサーバ９０は、ＵＥ１０が近隣端末を検出するための信号や、ＵＥ１０が近隣端末に検出されるための信号を送信するための、時間や周波数に関する情報を送信しても良い。例えば、あらかじめＰｒｏＳｅにおける近隣検出やＰｒｏＳｅを利用する通信で利用可能な時間情報や周波数情報の候補がいくつか割り当てられており、そのうちのどれを利用するかを示す情報を通知しても良い。

　なお、ＰｒｏＳｅサーバ９０は、ＥｘｐｒｅｓｓｉｏｎコードをＵＥ１０Ａのみではなく、ＵＥ１０Ａの通信対象であるＵＥ１０Ｂにも通知する（Ｓ２０２２）。ここで、ＵＥ１０Ａは、アナウンスするＥｘｐｒｅｓｓｉｏｎコードを通知する。また、ＵＥ１０Ｂは、送信されたＥｘｐｒｅｓｓｉｏｎコードを受信し、Ｅｘｐｒｅｓｓｉｏｎコードをモニタリングする。なお、ＵＥ１０ＡからＵＥ１０ＢへＥｘｐｒｅｓｓｉｏｎコードを送信する方法は、アプリケーションレイヤによって送受信されても良いし、３ＧＰＰレイヤによって送受信されても良い。このように、ＵＥ１０Ａは、ＵＥ１０Ａの検出を要求する信号として送信する。

　また、ＰｒｏＳｅサーバ９０は、ＵＥ１０Ｂが近隣端末を検出するための信号や、ＵＥ１０Ａが近隣端末に検出されるための信号を送信するための、時間や周波数に関する情報を送信しても良い。例えば、あらかじめ近隣検出やＰｒｏＳｅを利用する通信で利用可能な時間情報や周波数情報の候補がいくつか割り当てられており、そのうちのどれを利用するかを示す情報を通知しても良い。

　ＵＥ１０Ａは認証サーバに送信した要求に対応する応答を受信し、Ｅｘｐｒｅｓｓｉｏｎコードを受信する。さらにＵＥ１０Ａは、アプリケーションレイヤにＥｘｒｅｓｓｉｏｎコードを受信したことを検知させ（Ｓ２０１６）、アプリケーション種別を示すＡＰＰＩＤとＥｘｐｒｅｓｓｉｏｎコードをマッピングして管理しておく（Ｓ２０１８）。

　続いて、ＵＥ１０Ａは、ＥｘｐｒｅｓｓｉｏｎコードをＵＥ１０Ｂに通知する（Ｓ２０２４）。近隣検出のためのＥｘｐｒｅｓｓｉｏｎコードには、ｉｎ　ｃｏｖｅｒａｇｅフラグ１４７、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙ１４８、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグ１４９を含める。Ｅｘｐｒｅｓｓｉｏｎコードは、ＵＥ１０Ａによってブロードキャストして送信され、ＵＥ１０Ｂによって受信されることにより、ＵＥ１０Ａが近隣に存在することをＵＥ１０Ｂに検出させるための識別子である。

　ここで、ｉｎ　ｃｏｖｅｒａｇｅフラグ１４７には、ＵＥ１０ＡがＬＴＥ基地局に在圏していること（Ｉｎ　ｃｏｖｅｒａｇｅ）（または、在圏していないこと（Ｏｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ））を示す情報を含める。

　ここで、ｉｎ　ｃｏｖｅｒａｇｅフラグ１４７には、ＵＥ１０ＡがＬＴＥ基地局に在圏していること（Ｉｎ　ｃｏｖｅｒａｇｅ）（または、在圏していないこと（Ｏｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ））を示す情報を含めても良い。

　また、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙ１４８は、ｐｕｂｌｉｃ　ｓａｆｅｔｙを機能として保持していることを示す情報であり、ここでは、ＵＥ１０Ａはｐｕｂｌｉｃ　ｓａｆｅｔｙの機能を保持するため、「可」として通知してもよい。

　さらに、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグ１４９は、ｐｕｂｌｉｃ　ｓａｆｅｔｙを利用することを許可することを示す情報であり、ここでは、ＵＥ１０Ａはｐｕｂｌｉｃ　ｓａｆｅｔｙを許可しているため、「ｏｎ」として通知してもよい。

　また、ＵＥ１０Ａは、受信した情報に基づいて、ネットワークがＰｒｏＳｅに関するサービスをサポートしているか否かを検出し、検出結果に基づいて、また、対象とするＰｒｏＳｅのサービスは、近隣端末検出に対するサービスであってもよいし、近隣通信端末との直接通信路の確立を提供するサービスであってもよいし、その両方を含んだサービスであってもよい。

　このように、接続するネットワークが近隣端末検出や近隣端末間の通信路確立などのＰｒｏＳｅに関するサービスをサポートするか否かを示す情報をネットワークから受信し、サポートする場合にはＵＥ１０Ａは要求メッセージを送信し、サポートしない場合にはＵＥ１０Ａは要求メッセージを送信しないと判定しても良い。

　なお、ＵＥ１０Ａの３ＧＰＰレイヤが送信するＥｘｐｒｅｓｓｉｏｎコードの通知は、一定時間毎に送信されても良い。また、ｉｎ　ｃｏｖｅｒａｇｅフラグ１４７が更新される度に送信しても良い。

　続いて、ＵＥ１０Ｂは、ＵＥ１０ＡのＥｘｐｒｅｓｓｉｏｎコードを受信する（Ｓ２０２６）。ＵＥ１０Ｂは、ＵＥ１０Ａと直接通信を行えることを確認する。ここで、ＵＥ１０Ｂは、ＵＥ１０Ａのｉｎ　ｃｏｖｅｒａｇｅフラグ１４７、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙ１４８、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグ１４９を確認する。

　ＵＥ１０ＡとＵＥ１０Ｂが上記の４状態のいずれかであることを検出することができる。具体的には、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅである１状態のいずれかであることを検出することができる。

　ここで、ＵＥ１０Ａのｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙが「不可」で、ＵＥ１０Ａのｉｎ　ｃｏｖｅｒａｇｅフラグがｏｕｔ　ｏｆ　ｃｏｖｅｒａｇｅの場合、直接通信を行うことができないと判断しても良い。また、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグが「ｏｆｆ」で、ｏｕｔ　ｏｆ　ｃｏｖｅｒａｇｅの場合、直接通信を行うことができないと判断しても良い。

　ＵＥ１０Ａと直接通信を行えることを確認したＵＥ１０Ｂは、ＵＥ１０ＡにＥｘｐｒｅｓｓｉｏｎコードの確認応答を送信しても良い。（Ｓ２０２８）。これにより、ＵＥ１０Ｂは、ＵＥ１０Ａが近隣に存在すると検出したことをＵＥ１０Ａに通知することができる。さらに、ＵＥ１０Ａはこの応答の受信することにより、ＵＥ１０ＢがＵＥ１０Ａの近隣に存在することを検知することもできる。この応答には、ＵＥ１０Ｂのｉｎ　ｃｏｖｅｒａｇｅフラグ１４７、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙ１４８、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグ１４９を含める。ここで、ｉｎ　ｃｏｖｅｒａｇｅフラグ１４７には、ＵＥ１０ＡがＬＴＥ基地局に在圏していること（Ｉｎ　ｃｏｖｅｒａｇｅ）（または、在圏していないこと（Ｏｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ））を示す情報を含めても良い。

　さらに、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグ１４９は、ｐｕｂｌｉｃ　ｓａｆｅｔｙを利用することを許可することを示す情報であり、ここでは、ＵＥ１０Ａはｐｕｂｌｉｃ　ｓａｆｅｔｙを許可しているため、「ｏｎ」として通知する。

　一方、ＵＥ１０Ｂは、ＵＥ１０Ａから近隣検出が行われたことをアプリケーションに通知する（Ｓ２０３０）。

　Ｅｘｐｒｅｓｓｉｏｎコードの確認応答を受信したＵＥ１０Ａは、ＵＥ１０ＡとＵＥ１０Ｂ間のカバレッジ情報を検知する（Ｓ２０３２）。このとき、ＵＥ１０Ａで検出するＵＥ１０ＡとＵＥ１０Ｂのカバレッジ情報は、図１０で示したように、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅである１状態のいずれかであることを検出し、通信路確立手続きを選択することができる。

　次に、ＵＥ１０Ａの３ＧＰＰレイヤは、ＵＥ１０ＡおよびＵＥ１０Ｂのカバレッジ情報をアプリケーションレイヤに通知する（Ｓ２０３４）。ここで、Ｉｎ　ｃｏｖｅｒａｇｅフラグ１４７、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙ１４８、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグ１４９を含める。ここで含められるＩｎ　ｃｏｖｅｒａｇｅフラグ１４７は、ＵＥ１０Ａにおいて検出したＩｎ　ｃｏｖｅｒａｇｅ　フラグ１４７やＵＥ１０ＢにおけるＥｘｐｒｅｓｓｉｏｎコードの確認応答で含められたＩｎ　ｃｏｖｅｒａｇｅフラグ１４７である。ＵＥ１０Ａの３ＧＰＰレイヤから受信したアプリケーションレイヤは、ＵＥ１０ＡとＵＥ１０Ｂ間のカバレッジ情報を検知する（Ｓ２０３６）。このとき、アプリケーションレイヤで検出するＵＥ１０ＡとＵＥ１０Ｂのカバレッジ情報は、図１０で示したように、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅである１状態のいずれかであることを検出し、通信路確立手続きを選択することができる。

　以上の手続きにより、ＵＥ１０Ｂは、ＵＥ１０ＡおよびＵＥ１０Ｂにおけるカバレッジ情報を検出することができる。

　ここで、Ｓ２００２からＳ２０２６までとＳ２０３０の一連の手続きにおいて、ＵＥ１０ＡとＵＥ１０Ｂを入れ替えて手続きを開始しても良い。つまり、ＵＥ１０Ａのアプリケーションはフレンドリストの取得（Ｓ２００２）を行い、Ｅｘｐｒｅｓｓｉｏｎコードの要求（Ｓ２００４）を行い、ＵＥ１０Ａの３ＧＰＰレイヤはＥｘｐｒｅｓｓｉｏｎコードの要求（Ｓ２００６）を行い、ＰｒｏＳｅサーバ９０は、Ｅｘｐｒｅｓｓｉｏｎコードを生成するパラメータを取得（Ｓ２００８）し、Ｅｘｐｒｅｓｓｉｏｎコードを生成（Ｓ２０１０）し、Ｅｘｐｒｅｓｓｉｏｎコードの応答を送信（Ｓ２０１４）し、ＵＥ１０Ｂの３ＧＰＰレイヤはＥｘｐｒｅｓｓｉｏｎコードを通知（Ｓ２０１６）し、ＡＰＰＩＤとＥｘｐｒｅｓｓｉｏｎコードをマッピング（Ｓ２０１８）し、ＵＥ１０Ｂのアプリケーションは近隣検出の開始を要求（Ｓ２０２０）し、ＵＥ１０Ａは、Ｅｘｐｒｅｓｓｉｏｎコードを取得し、近隣検出を開始（Ｓ２０２２）し、ＵＥ１０Ｂの３ＧＰＰレイヤはＵＥ１０Ａの３ＧＰＰレイヤにＥｘｐｒｅｓｓｉｏｎコードを通知（Ｓ２０２４）し、Ｅｘｐｒｅｓｓｉｏｎコードを受信（Ｓ２０２６）し、近隣検出の通知（Ｓ２０３０）を行ってもよい。

　ＵＥ１０ＡがＵＥ１０Ｂに送信するブロードキャストの送信（Ｓ２０２４）は、あらかじめ取得した通信リソースを利用して、ユニキャストで送信しても良い。また逆に、ＵＥ１０ＢがＵＥ１０Ａに送信するブロードキャストの送信（Ｓ２０２４）する場合、あらかじめ取得した通信リソースを利用して、ユニキャストで送信しても良い。ここで、取得した通信リソースとは、特定のＵＥに検出させるために利用することができる通信リソースであり、ｅＮＢ４５またはＭＭＥ４０によって明示的に通知されることにより割り当てられても良いし、あらかじめＵＥ１０ＡまたはＵＥ１０Ｂに通知されているものを利用しても良い。

　さらに、ＵＥ１０ＢがＵＥ１０Ａに送信するブロードキャストの送信（Ｓ２０２８）は、あらかじめ取得した通信リソースを利用して、ユニキャストで送信しても良い。また逆に、ＵＥ１０ＡがＵＥ１０Ｂに送信するブロードキャストの送信（Ｓ２０２８）する場合、あらかじめ取得した通信リソースを利用して、ユニキャストで送信しても良い。ここで、取得した通信リソースとは、特定のＵＥに検出させるために利用することができる通信リソースであり、ｅＮＢ４５またはＭＭＥ４０によって明示的に通知されることにより割り当てられても良いし、あらかじめＵＥ１０ＡまたはＵＥ１０Ｂに通知されているものを利用しても良い。　

　以上の手続きにより、ＵＥ１０Ａは、ＵＥ１０ＡおよびＵＥ１０Ｂにおけるカバレッジ情報を検出することができる。つまり、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅである１状態の４状態のうち、いずれかであることを検出することができる。

　近隣検出手続きにおいて、ＵＥ１０Ａは、ＵＥ１０ＡおよびＵＥ１０Ｂにおけるカバレッジ情報を検出し、カバレッジ情報に基づいて、通信路確立手続きを行う。具体的には、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅである１状態のそれぞれの状態で、異なる通信路確立手続きを行う。通信路確立手続きは、第一の実施形態で示した方法を同様に利用可能であるため、その詳細な説明は省略する。

　[３．　第３実施形態]
　第３の実施形態について説明する。第３の実施形態と第１の実施形態、第２の実施形態との違いは、ＵＥにおいて管理する識別子情報が異なる。また、ＰｒｏＳｅサーバにおいて管理する識別子情報が異なる。さらに、近隣検出手続きが異なる。

　[３．２　装置構成]
　[３．２．１　ＵＥの構成]
　図１８を用いて、第３の実施形態におけるＵＥ１０Ａの構成を示す。第３の実施形態では、ＵＥ１０Ａは、記憶部１４０において管理する識別子が異なる。具体的には、記憶部１４０に、ＡＰＰ　Ｐｅｒｓｏｎａｌ　ＩＤ１４２０、ＡＰＰ　Ｇｒｏｕｐ　ＩＤ１４４０を追加で管理する。記憶部１４０におけるＡＰＰ　Ｐｅｒｓｏｎａｌ　ＩＤ１４２０、ＡＰＰ　Ｇｒｏｕｐ　ＩＤ１４４０以外は、第１の実施形態、第２の実施形態と同様の構成であるため、詳細な説明は省略する。

　図１９（ａ）にＡＰＰ　ｐｅｒｓｏｎａｌ　ＩＤ１４２０の例を示す。図１９（ａ）では、ＵＥ１０Ａを識別するための識別子（ＡＰＰ　Ｐｅｒｓｏｎａｌ　ＩＤ　Ａ）やＵＥ１０Ｂを識別するための識別子（ＡＰＰ　Ｐｅｒｓｏｎａｌ　ＩＤ　Ｂ）が管理されている。なお、ＡＰＰ　Ｐｅｒｓｏｎａｌ　ＩＤ１４２０は、アプリケーション毎に管理されていても良い。つまり、ＡＰＰ毎に、ＡＰＰ　Ｐｅｒｓｏｎａｌ　ＩＤ１４２０を管理しても良い。

　図１９（ｂ）にＡＰＰ　Ｇｒｏｕｐ　ＩＤ１４４０の例を示す。ＡＰＰ　Ｇｒｏｕｐ　ＩＤ１４４０は、ＵＥ１０Ａが参加するグループを識別する識別子を管理している。ＡＰＰ　Ｇｒｏｕｐ　ＩＤ１４４０により、ＵＥ１０Ａは近隣検出や直接通信を行うＵＥを制限することができる。図１９（ｂ）では、ＡＰＰ　Ｇｒｏｕｐ　ＩＤ１４４０は、Ｇｒｏｕｐ　１およびＧｒｏｕｐ２が管理されている。なお、ＡＰＰ　Ｇｒｏｕｐ　ＩＤは複数管理可能であり、ＵＥ１０Ａは複数のグループに所属することができる。

　[３．２．２　ＰｒｏＳｅサーバの構成]
　図２０を用いて、第３の実施形態におけるＰｒｏＳｅサーバ９０の構成を示す。第３の実施形態では、ＰｒｏＳｅサーバ９０は、記憶部１４０において管理する識別子が異なる。具体的には、記憶部１４０に、ＡＰＰ　Ｐｅｒｓｏｎａｌ　ＩＤ９４２０、ＡＰＰ　Ｇｒｏｕｐ　ＩＤ９４４０を追加で管理する。記憶部１４０におけるＡＰＰ　Ｐｅｒｓｏｎａｌ　ＩＤ９４２０、ＡＰＰ　Ｇｒｏｕｐ　ＩＤ９４４０以外は、第１の実施形態、第２の実施形態と同様の構成であるため、詳細な説明は省略する。

　図２１（ａ）にＡＰＰ　ｐｅｒｓｏｎａｌ　ＩＤ９４２０の例を示す。図２１（ａ）では、ＵＥ１０Ａを識別するための識別子（ＡＰＰ　Ｐｅｒｓｏｎａｌ　ＩＤ　Ａ）やＵＥ１０Ｂを識別するための識別子（ＡＰＰ　Ｐｅｒｓｏｎａｌ　ＩＤ　Ｂ）が管理されている。なお、ＡＰＰ　Ｐｅｒｓｏｎａｌ　ＩＤ９４２０は、アプリケーション毎に管理されていても良い。つまり、ＡＰＰ毎に、ＡＰＰ　Ｐｅｒｓｏｎａｌ　ＩＤ９４２０を管理しても良い。

　図２１（ｂ）にＡＰＰ　Ｇｒｏｕｐ　ＩＤ９４４０の例を示す。ＡＰＰ　Ｇｒｏｕｐ　ＩＤ９４４０は、ＰｒｏＳｅサーバ９０が管理するグループを識別する識別子を管理している。ＡＰＰ　Ｇｒｏｕｐ　ＩＤ９４４０により、ＰｒｏＳｅサーバ９０は近隣検出や直接通信を行うＵＥを制限することができる。図２１（ｂ）では、ＡＰＰ　Ｇｒｏｕｐ　ＩＤ９４４０は、Ｇｒｏｕｐ　１およびＧｒｏｕｐ２が管理されている。なお、ＡＰＰ　Ｇｒｏｕｐ　ＩＤは複数管理可能である。

　[３．３　処理の説明]
　[３．３．１　近隣検出手続き]
　[３．３．１．１　近隣検出手続き１]
　図２２を用いて、第３実施形態における近隣検出手続きを説明する。まず、通信元であるＵＥ１０Ａは、ＵＥ１０Ｂにターゲット近隣検出要求をブロードキャストで送信する（Ｓ２５０２）。近隣検出要求には、ＡＰＰ　Ｇｒｏｕｐ　ＩＤ１４２０、ＡＰＰ　Ｐｅｒｓｏｎａｌ　ＩＤ（ＵＥ１０Ａ）、ｉｎ　ｃｏｖｅｒａｇｅフラグ１４７、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙ１４８、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅ１４９を含める。

　ダーゲット近隣検出要求を受信したＵＥ１０Ｂは、ＵＥ１０Ａのｉｎ　ｃｏｖｅｒａｇｅフラグ１４７、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙ１４８、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグ１４９を確認する。

　ＵＥ１０Ｂは、ＵＥ１０Ａと４状態のいずれかであることを検出することができる。具体的には、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅである１状態のいずれかであることを検出することができる。

　なお、ＵＥ１０Ａが送信する近隣検出要求は、一定時間毎に送信されても良い。また、ｉｎ　ｃｏｖｅｒａｇｅフラグ１４７が更新される度に送信しても良い。ここで、ＵＥ１０ＡはＵＥ１０Ｂによって近隣検出要求が検出された後でも、近隣検出のための信号を、一定時間毎に送信し続けても良い。ｉｎ　ｃｏｖｅｒａｇｅフラグ１４７は、送信時点での、圏内または、圏外の状況に応じて、更新して検出要求信号に含めて送信する。

　ＵＥ１０Ａと直接通信を行えることを確認したＵＥ１０Ｂは、ＵＥ１０Ａにターゲット近隣検出応答を送信する（Ｓ２５０４）。この応答には、ＵＥ１０Ｂのｉｎ　ｃｏｖｅｒａｇｅフラグ１４７、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙ１４８、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグ１４９を含める。ここで、ｉｎ　ｃｏｖｅｒａｇｅフラグ１４７には、ＵＥ１０ＡがＬＴＥ基地局に在圏していること（Ｉｎ　ｃｏｖｅｒａｇｅ）（または、在圏していないこと（Ｏｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ））を示す情報を含める。

　さらに、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグ１４９は、ｐｕｂｌｉｃ　ｓａｆｅｔｙを利用することを許可することを示す情報であり、ここでは、ＵＥ１０Ａはｐｕｂｌｉｃ　ｓａｆｅｔｙを許可しているため、「ｏｎ」として通知する。　また、ＵＥ１０Ａは、ＵＥ１０ＢがＬＴＥ　Ｄｉｒｅｃｔで直接通信路を確立することができる能力情報などを示す識別情報により、ＵＥ１０ＢがＬＴＥ　Ｄｉｒｅｃｔを利用できることを検出しても良い。また、ＵＥ１０Ａは、ＵＥ１０ＢがＷＬＡＮ　Ｄｉｒｅｃｔで直接通信路を確立することができる能力情報などを示す識別情報により、ＵＥ１０ＢがＷＬＡＮ　Ｄｉｒｅｃｔを利用できることを検出しても良い。

　ターゲット近隣検出応答を受信したＵＥ１０Ａは、ＵＥ１０ＡとＵＥ１０Ｂ間のカバレッジ情報を検知する（Ｓ２５０６）。このとき、ＵＥ１０Ａで検出するＵＥ１０ＡとＵＥ１０Ｂのカバレッジ情報は、図１０で示したように、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅである１状態のいずれかであることを検出し、通信路確立手続きを選択することができる。

　ＵＥ１０ＡがＵＥ１０Ｂに送信するブロードキャストの送信（Ｓ２５０２）は、あらかじめ取得した通信リソースを利用して、ユニキャストで送信しても良い。また逆に、ＵＥ１０ＢがＵＥ１０Ａに送信するブロードキャストの送信（Ｓ２５０２）する場合、あらかじめ取得した通信リソースを利用して、ユニキャストで送信しても良い。ここで、取得した通信リソースとは、特定のＵＥに検出させるために利用することができる通信リソースであり、ｅＮＢ４５またはＭＭＥ４０によって明示的に通知されることにより割り当てられても良いし、あらかじめＵＥ１０ＡまたはＵＥ１０Ｂに通知されているものを利用しても良い。

　さらに、ＵＥ１０ＢがＵＥ１０Ａに送信するブロードキャストの送信（Ｓ２５０４）は、あらかじめ取得した通信リソースを利用して、ユニキャストで送信しても良い。また逆に、ＵＥ１０ＡがＵＥ１０Ｂに送信するブロードキャストの送信（Ｓ２５０４）する場合、あらかじめ取得した通信リソースを利用して、ユニキャストで送信しても良い。ここで、取得した通信リソースとは、特定のＵＥに検出させるために利用することができる通信リソースであり、ｅＮＢ４５またはＭＭＥ４０によって明示的に通知されることにより割り当てられても良いし、あらかじめＵＥ１０ＡまたはＵＥ１０Ｂに通知されているものを利用しても良い。

　近隣検出手続きにおいて、ＵＥ１０Ａは、ＵＥ１０ＡおよびＵＥ１０Ｂにおけるカバレッジ情報を検出し、カバレッジ情報に基づいて、通信路確立手続きを行う。具体的には、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅである１状態のそれぞれの状態で、異なる通信路確立手続きを行う。

　[３．３．１．２　近隣検出手続き２]
　近隣検出手続き２について説明する。近隣検出手続き１との違いは、チャレンジ＆レスポンスの認証を利用することにある。第２の実施形態では、チャレンジ＆レスポンスを利用することにより、通信元ＵＥおよび通信先ＵＥを認証することができる。

　図２３を用いて、近隣検出手続き２について説明する。まず、ＵＥ１０ＡはＵＥ１０Ｂにターゲット近隣検出要求を送信する（Ｓ２６０２）。ターゲット近隣検出には、ｃｈａｌｌｅｎｇｅ　Ａ、ＰｒｏＳｅ　ＩＤ（ＵＥ１０Ａ）１４２、属性を示す情報、ｉｎ　ｃｏｖｅｒａｇｅフラグ１４７、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙ１４８、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅ１４９を含める。

　ここで、ｃｈａｌｌｅｎｇｅ　Ａとは、チャレンジ＆レスポンス認証を行うための認証要求情報である。また、属性を示す情報とは、直接通信を行うアプリケーションの種別を示す情報である。

　また、ｉｎ　ｃｏｖｅｒａｇｅフラグ１４７には、ＵＥ１０ＡがＬＴＥ基地局に在圏していること（Ｉｎ　ｃｏｖｅｒａｇｅ）（または、在圏していないこと（Ｏｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ））を示す情報を含める。

　ダーゲット近隣検出要求を受信したＵＥ１０Ｂは、ｃｈａｌｌｅｎｇｅ　Ａ、ＰｒｏＳｅ　ＩＤ（ＵＥ１０Ａ）、属性を示す情報、ＵＥ１０Ａのｉｎ　ｃｏｖｅｒａｇｅフラグ１４７、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙ１４８、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグ１４９を確認する。

　また、ＵＥ１０Ｂは、ＵＥ１０Ａからのｃｈａｌｌｅｎｇｅ　Ａを認証し、直接通信を行えることを確認する。また、属性を示す情報を利用して、アプリケーションの種別を検出する。

　なお、ＵＥ１０Ａが送信するターゲット近隣検出要求は、一定時間毎に送信されても良い。また、ｉｎ　ｃｏｖｅｒａｇｅフラグ１４７が更新される度に送信しても良い。ここで、ＵＥ１０ＡはＵＥ１０Ｂによってターゲット近隣検出要求が検出された後でも、近隣検出のための信号を、一定時間毎に送信し続けても良い。ｉｎ　ｃｏｖｅｒａｇｅフラグ１４７は、送信時点での、圏内または、圏外の状況に応じて、更新して検出要求信号に含めて送信する。

　ＵＥ１０Ａと直接通信を行えることを確認したＵＥ１０Ｂは、ＵＥ１０Ａにターゲット近隣検出応答を送信する（Ｓ２６０４）。この応答には、ｒｅｓｐｏｎｓｅ　Ａ、ｃｈａｌｌｅｎｇｅ　Ｂ、ＰｒｏＳｅ　ＩＤ（ＵＥ１０Ｂ）、属性を示す情報、ＵＥ１０Ｂのｉｎ　ｃｏｖｅｒａｇｅフラグ１４７、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙ１４８、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグ１４９を含める。

　ここで、ｒｅｓｐｏｎｓｅ　Ａとは、ＵＥ１０Ａが送信したｃｈａｌｌｅｎｇｅ　Ａに対する応答であり、ＵＥ１０Ａからの認証要求を認証したことを示す情報である。また、ｃｈａｌｌｅｎｇｅ　Ｂとは、チャレンジ＆レスポンス認証を行うための認証要求情報である。さらに、属性を示す情報とは、直接通信を行うアプリケーションの種別を示す情報であり、ＵＥ１０Ａが送信した情報を利用しても良い。

　ターゲット近隣検出応答を受信したＵＥ１０Ａは、ＵＥ１０ＡとＵＥ１０Ｂ間のカバレッジ情報を検知する（Ｓ２６０６）。このとき、ＵＥ１０Ａで検出するＵＥ１０ＡとＵＥ１０Ｂのカバレッジ情報は、図１０で示したように、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅである１状態のいずれかであることを検出し、通信路確立手続きを選択することができる。

　また、ＵＥ１０Ａは、ｒｅｓｐｏｎｓｅ　Ａを受信し、ＵＥ１０Ｂに認証を受けたことを確認する。また、ｃｈａｌｌｅｎｇｅ　Ｂを受信して、ＵＥ１０Ｂと直接通信を行えることを確認して、認証を行う。

　次に、ｃｈａｌｌｅｎｇｅ　Ｂの認証を行ったＵＥ１０ＡはＵＥ１０Ｂにターゲット近隣検出確認応答を送信する（Ｓ２６０８）。ここで、ＵＥ１０Ａはターゲット近隣検出確認応答に、ｒｅｓｐｏｎｓｅ　Ｂを含める。ｒｅｓｐｏｎｓｅ　Ｂとは、ＵＥ１０Ｂから送信されたｃｈａｌｌｅｎｇｅ　Ｂにおける認証要求に対する応答である。

　ＵＥ１０Ａからターゲット近隣検出確認応答を受信したＵＥ１０Ｂは、ｃｈａｌｌｅｎｇｅ　Ｂに対する応答であるｒｅｓｐｏｎｓｅ　Ｂを受信して、ＵＥ１０Ａと直接通信を行うことができることを確認する。

　ＵＥ１０ＡがＵＥ１０Ｂに送信するターゲット近隣検出要求（Ｓ２６０２）は、取得したリソースを利用して、ブロードキャストで送信しても、ユニキャストで送信しても良い。ここで、取得した通信リソースとは、特定のＵＥに検出させるために利用することができる通信リソースであり、ｅＮＢ４５またはＭＭＥ４０によって明示的に通知されることにより割り当てられても良いし、あらかじめＵＥ１０ＡまたはＵＥ１０Ｂに通知されているものを利用しても良い。

　さらに、ＵＥ１０ＢがＵＥ１０Ａに送信するターゲット近隣検出要求（Ｓ２６０４）は、取得したリソースを利用して、ブロードキャストで送信しても、ユニキャストで送信しても良い。ここで、取得した通信リソースとは、特定のＵＥに検出させるために利用することができる通信リソースであり、ｅＮＢ４５またはＭＭＥ４０によって明示的に通知されることにより割り当てられても良いし、あらかじめＵＥ１０ＡまたはＵＥ１０Ｂに通知されているものを利用しても良い。　以上の手続きにより、ＵＥ１０Ａは、ＵＥ１０ＡおよびＵＥ１０Ｂにおけるカバレッジ情報を検出することができる。つまり、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅである１状態の４状態のうち、いずれかであることを検出することができる。

　[３．３．１．３　近隣検出手続き３]
　近隣検出手続き３について説明する。近隣検出手続き１、近隣検出手続き２では、特定のＵＥを近隣検出するターゲット近隣検出要求であったのに対し、近隣検出手続きでは、不特定のＵＥを近隣検出する非ターゲット近隣検出要求を行うことにある。

　図２４を用いて、第３実施形態における近隣検出手続き３を説明する。まず、通信元であるＵＥ１０Ａは、ＵＥ１０Ｂを含む近隣端末に非ターゲット近隣検出要求をブロードキャストで送信する（Ｓ２７０２）。近隣検出要求には、ＰｒｏＳｅ　ＩＤ（ＵＥ１０Ａ）、ｉｎ　ｃｏｖｅｒａｇｅフラグ１４７、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙ１４８、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅ１４９を含める。

　非ダーゲット近隣検出要求を受信したＵＥ１０Ｂは、ＵＥ１０Ａのｉｎ　ｃｏｖｅｒａｇｅフラグ１４７、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙ１４８、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグ１４９を確認する。

　なお、ＵＥ１０Ａが送信する非ターゲット近隣検出要求は、一定時間毎に送信されても良い。また、ｉｎ　ｃｏｖｅｒａｇｅフラグ１４７が更新される度に送信しても良い。ここで、ＵＥ１０ＡはＵＥ１０Ｂによって非ターゲット近隣検出要求が検出された後でも、近隣検出のための信号を、一定時間毎に送信し続けても良い。ｉｎ　ｃｏｖｅｒａｇｅフラグ１４７は、送信時点での、圏内または、圏外の状況に応じて、更新して検出要求信号に含めて送信する。

　ＵＥ１０Ａと直接通信を行えることを確認したＵＥ１０Ｂは、ＵＥ１０Ａにターゲット近隣検出応答を送信する（Ｓ２７０４）。この応答には、ＵＥ１０Ｂのｉｎ　ｃｏｖｅｒａｇｅフラグ１４７、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙ１４８、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグ１４９を含める。ここで、ｉｎ　ｃｏｖｅｒａｇｅフラグ１４７には、ＵＥ１０ＡがＬＴＥ基地局に在圏していること（Ｉｎ　ｃｏｖｅｒａｇｅ）（または、在圏していないこと（Ｏｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ））を示す情報を含める。

　非ターゲット近隣検出応答を受信したＵＥ１０Ａは、ＵＥ１０ＡとＵＥ１０Ｂ間のカバレッジ情報を検知する（Ｓ２７０６）。このとき、ＵＥ１０Ａで検出するＵＥ１０ＡとＵＥ１０Ｂのカバレッジ情報は、図１０で示したように、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅである１状態のいずれかであることを検出し、通信路確立手続きを選択することができる。

　ＵＥ１０ＡがＵＥ１０Ｂに送信する非ターゲット近隣検出要求（Ｓ２６０２）は、取得したリソースを利用して、ブロードキャストで送信しても、ユニキャストで送信しても良い。ここで、取得した通信リソースとは、特定のＵＥに検出させるために利用することができる通信リソースであり、ｅＮＢ４５またはＭＭＥ４０によって明示的に通知されることにより割り当てられても良いし、あらかじめＵＥ１０ＡまたはＵＥ１０Ｂに通知されているものを利用しても良い。

　さらに、ＵＥ１０ＢがＵＥ１０Ａに送信する非ターゲット近隣検出要求（Ｓ２６０４）は、取得したリソースを利用して、ブロードキャストで送信しても、ユニキャストで送信しても良い。ここで、取得した通信リソースとは、特定のＵＥに検出させるために利用することができる通信リソースであり、ｅＮＢ４５またはＭＭＥ４０によって明示的に通知されることにより割り当てられても良いし、あらかじめＵＥ１０ＡまたはＵＥ１０Ｂに通知されているものを利用しても良い。

[４．　第４実施形態]
　第４の実施形態について説明する。第４の実施形態と第１の実施形態、第２の実施形態、第３の実施形態との違いは、装置の構成が異なることにある。また、近隣検出を行うために、ＵＥが直接ＵＥを近隣検出するのではなく、移動通信事業者のネットワーク側で近隣検出し、ＵＥに通知する方法を利用する。

　[４．１　移動通信システムの概要]
　図２５を用いて、第４実施形態の移動通信システムの概要を説明する。本図に示すように、移動通信システム１は、ＵＥ（移動局装置）１０Ａと、ＵＥ（移動局装置）１０Ｂと、ＰＤＮ（Ｐａｃｋｅｔ　Ｄａｔａ　Ｎｅｔｗｏｒｋ）２０とが、ＲＡＮやＥＰＣを介して接続されて構成されている。ＲＡＮとＥＰＣは例えば、ＡＤＳＬ（Ａｓｙｍｍｅｔｒｉｃ　Ｄｉｇｉｔａｌ　Ｓｕｂｓｃｒｉｂｅｒ　Ｌｉｎｅ）や光ファイバー等によって構築される。ただし、これに限らずＬＴＥ（Ｌｏｎｇ　Ｔｅｒｍ　Ｅｖｏｌｕｔｉｏｎ）や、ＷＬＡＮ（Ｗｉｒｅｌｅｓｓ　ＬＡＮ）、ＷｉＭＡＸ（Ｗｏｒｌｄｗｉｄｅ　Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ　ｆｏｒ　Ｍｉｃｒｏｗａｖｅ　Ａｃｃｅｓｓ）等の無線アクセスネットワークであっても良い。

　ここで、ＥＰＣには、ＧＭＬＣ２５、ＭＭＥ４０、ＰｒｏＳｅサーバ９０が配置されている。なお、ＧＭＬＣ（Ｇａｔｅｗａｙ　Ｍｏｂｉｌｅ　Ｌｏｃａｔｉｏｎ　Ｃｅｎｔｅｒ）２５は、ＵＥの位置情報を取得し、管理する装置である。

　ＰｒｏＳｅサーバ９０は、ＬＣＳ　Ｃｌｉｅｎｔ２７の機能を保持している。また、ＰＤＮ２０には、アプリケーションサーバ９５が配置されている。ここで、ＰｒｏＳｅサーバ９０は、ＵＥ１０ＡまたはＵＥ１０Ｂが近隣検出を行うネットワークの移動通信事業者が管理する認証サーバである。なお。ＰｒｏＳｅサーバ９０は、ＭＭＥ４０の機能の一部として構成されても良い。

　ＰｒｏＳｅサーバ９０は、ＬＣＳ　Ｃｌｉｅｎｔを保持しているため、ＧＭＬＣ２５にＵＥの位置情報を要求し、ＧＭＬＣ２５からの位置情報を取得することができる。

　アプリケーションサーバ９５は、ＵＥ１０ＡまたはＵＥ１０Ｂが利用するアプリケーション（ＡＰＰ１）によるサービスを提供するサーバである。

　ＵＥ１０Ａと、ＵＥ１０Ｂは、同じ移動通信事業者網に接続していてもよいし、単一の国のなかの異なる移動通信事業者網に接続していてもよい。

　ＰＤＮ２０は、ＥＰＣへ有線回線等を利用して接続される。例えば、ＡＤＳＬ（Ａｓｙｍｍｅｔｒｉｃ　Ｄｉｇｉｔａｌ　Ｓｕｂｓｃｒｉｂｅｒ　Ｌｉｎｅ）や光ファイバー等によって構築される。ただし、これに限らずＬＴＥ（Ｌｏｎｇ　Ｔｅｒｍ　Ｅｖｏｌｕｔｉｏｎ）や、ＷＬＡＮ（Ｗｉｒｅｌｅｓｓ　ＬＡＮ）、ＷｉＭＡＸ（Ｗｏｒｌｄｗｉｄｅ　Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ　ｆｏｒ　Ｍｉｃｒｏｗａｖｅ　Ａｃｃｅｓｓ）等の無線アクセスネットワークであっても良い。

　なお、ＵＥ１０ＡとＵＥ１０Ｂ、ＰｒｏＳｅサーバ９０、アプリケーションサーバ９５、ＭＭＥ４０は第１の実施形態で示した構成と同様の構成であるため、その説明を省略する。また、ＧＭＬＣ２５、ＬＣＳ　ｃｌｉｅｎｔ２７は、従来から利用される装置であるため、その詳細な説明を省略する。

　[４．３．１　近隣検出手続き]
　図２６を用いて、本実施形態における近隣検出手続きを説明する。なお、ＰｒｏＳｅサーバ９０は、ＭＭＥ４０であっても良い。まず、ＵＥ１０Ａは、ＰｒｏＳｅサーバ９０へ近隣検出要求を行う（Ｓ２９０２）。ここで、ＵＥ１０Ａは、近隣検出要求に、ＵＥ１０Ａ、ＵＥ１０Ｂの識別子を含める。ＵＥ１０Ａ、ＵＥ１０Ｂの識別子は、ＰｒｏＳｅ　ＩＤ１４２やＡＰＰ　Ｐｅｒｓｏｎａｌ　ＩＤ１４２０であってよい。

　次に、ＵＥ１０Ａは、ＧＭＬＣ２５に位置情報の報告を行う（Ｓ２９０４）。ここで、位置情報の報告には、ＵＥ１０Ａの識別子、ｉｎ　ｃｏｖｅｒａｇｅフラグ１４７、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙ１４８、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅ１４９を含める。なお、位置情報の報告は、定期的なタイミングで送信されても良いし、ＵＥ１０Ａが移動したことを検出して通知しても良い。

　一方、位置情報の報告を受けたＧＭＬＣ２５は、ＵＥ１０ＡがＬＴＥ　Ｄｉｒｅｃｔで直接通信路を確立することができる能力情報などを示す識別情報により、ＵＥ１０ＡがＬＴＥ　Ｄｉｒｅｃｔを利用できることを検出しても良い。また、ＧＭＬＣ２５は、ＵＥ１０ＡがＷＬＡＮ　Ｄｉｒｅｃｔで直接通信路を確立することができる能力情報などを示す識別情報により、ＵＥ１０ＡがＷＬＡＮ　Ｄｉｒｅｃｔを利用できることを検出しても良い。

　次に、ＵＥ１０Ｂは、ＧＭＬＣ２５に位置情報の報告を行う（Ｓ２９０６）。ここで、ＵＥ１０Ｂの識別子、ｉｎ　ｃｏｖｅｒａｇｅフラグ１４７、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙ１４８、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅ１４９を含める。なお、位置情報の報告は、定期的なタイミングで送信されても良いし、ＵＥ１０Ｂが移動したことを検出して通知しても良い。さらに、ＰｒｏＳｅサーバ９０からの問い合わせにより、位置情報を通知しても良い。ＵＥ１０Ａ、ＵＥ１０Ｂからの報告により、ＧＭＬＣ２５は位置情報を管理する。

　ＵＥ１０Ａから、Ｓ２９０２で近隣検出要求を受けたＰｒｏＳｅサーバ９０は、ＵＥ１０Ａ近隣検出警告を行う（Ｓ２９０８）。ここで、ＰｒｏＳｅサーバ９０は、ＵＥ１０ＡとＵＥ１０Ｂの位置情報をＧＭＬＣ２５に要求し、ＧＭＬＣ２５からＵＥ１０ＡとＵＥ１０Ｂの位置情報を検知する。ＰｒｏＳｅサーバ９０は、ＵＥ１０ＡとＵＥ１０Ｂの位置情報を利用して、ＵＥ１０ＡとＵＥ１０Ｂが近隣検出し、ＵＥ１０ＡにＵＥ１０ＡとＵＥ１０Ｂが近隣であることを通知する。ここで、ＰｒｏＳｅサーバ９０は、ＵＥ１０Ｂに、ＵＥ１０ＡとＵＥ１０Ｂが近隣であることを検知しても良い。ここで、この近隣検出警告には、ＵＥ１０Ｂのｉｎ　ｃｏｖｅｒａｇｅフラグ１４７、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙ１４８、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグ１４９を含める。ここで、ｉｎ　ｃｏｖｅｒａｇｅフラグ１４７には、ＵＥ１０ＡがＬＴＥ基地局に在圏していること（Ｉｎ　ｃｏｖｅｒａｇｅ）（または、在圏していないこと（Ｏｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ））を示す情報を含める。

　また、位置情報の報告を受けたＧＭＬＣ２５は、ＵＥ１０ＢがＬＴＥ　Ｄｉｒｅｃｔで直接通信路を確立することができる能力情報などを示す識別情報により、ＵＥ１０ＢがＬＴＥ　Ｄｉｒｅｃｔを利用できることを検出しても良い。また、ＧＭＬＣ２５は、ＵＥ１０ＢがＷＬＡＮ　Ｄｉｒｅｃｔで直接通信路を確立することができる能力情報などを示す識別情報により、ＵＥ１０ＢがＷＬＡＮ　Ｄｉｒｅｃｔを利用できることを検出しても良い。

　近隣検出警告を受信したＵＥ１０Ａは、ＵＥ１０ＡとＵＥ１０Ｂ間のカバレッジ情報を検知する（Ｓ２９１０）。このとき、ＵＥ１０Ａで検出するＵＥ１０ＡとＵＥ１０Ｂのカバレッジ情報は、図１０で示したように、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅである１状態のいずれかであることを検出し、通信路確立手続きを選択することができる。

[５．　第５実施形態]
　続いて、第５実施形態について説明する。第１実施形態、第２実施形態、第３実施形態、第４実施形態と、第５実施形態との違いは、近隣検出手続きが異なる。第５実施形態における近隣検出手続きでは、近隣検出要求を送信するために、近隣検出の無線リソースを取得する。また、近隣検出要求に対する応答を送信するために、近隣検出の無線リソースを取得する。本実施形態では、図１における移動通信システムの構成を利用することができるため、その詳細な説明を省略する。また、移動通信システムにおけるＵＥの構成やＰｒｏＳｅ　Ｓｅｒｖｅｒの構成、ＡＰＰサーバの構成も同様であるため、その詳細な説明を省略する。

　[５．３　処理の説明]
　[５．３．１　近隣検出手続き]
　図２７を用いて、近隣検出手続きについて説明する。まず、ＵＥ１０Ａのアプリケーションは、ＥＰＳレイヤに近隣検出要求を通知する（Ｓ３００２）。ここで、近隣検出要求には、近隣検出を行う対象であるＵＥ１０Ｂを示す識別子を通知する。

　次に、ＵＥ１０ＡのＥＰＳレイヤはＯｐｅｎ　ｄｉｓｃｏｖｅｒｙを行うか、Ｒｅｓｔｒｉｃｔｉｖｅ　ｄｉｓｃｏｖｅｒｙを行うかを決定する（Ｓ３００４）。この決定には、近隣検出を行う対象に応じて決定してもよい。

　[５．３．１．１　Ｒｅｓｔｒｉｃｔｉｖｅ　ｄｉｓｃｏｖｅｒｙ]
　まず、Ｒｅｓｔｒｉｃｔｉｖｅ　ｄｉｓｏｃｖｅｒｙについて説明する。Ｒｅｓｔｉｃｔｉｖｅ　ｄｉｓｃｏｖｅｒｙを行うことを検出したＵＥ１０Ａは、まず、近隣検出を行うための無線リソースを取得する（Ｓ３００６）。無線リソースを取得する方法は種々の方法が考えられるが、例えば、ｅＮＢ４５が定期的に送信する情報に含まれる情報から取得しても良いし、ＵＥ１０ＡがｅＮＢ４５に問い合わせることにより、取得しても良い。

　次にＵＥ１０Ａは、近隣検出信号をブロードキャストで送信する（Ｓ３００８）。ここで、近隣検出信号には、ＰｒｏＳｅ　ＩＤ（ＵＥ１０Ｂ）、ＰｒｏＳｅ　ＩＤ（ＵＥ１０Ａ）、ｉｎ　ｃｏｖｅｒａｇｅフラグ１４７、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙ１４８、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅ１４９を含める。

　なお、ＵＥ１０Ａが送信する近隣検出信号は、一定時間毎に送信されても良い。また、ｉｎ　ｃｏｖｅｒａｇｅフラグ１４７が更新される度に送信しても良い。ここで、ＵＥ１０ＡはＵＥ１０Ｂによって近隣検出信号が検出された後でも、近隣検出のための信号を、一定時間毎に送信し続けても良い。ｉｎ　ｃｏｖｅｒａｇｅフラグ１４７は、送信時点での、圏内または、圏外の状況に応じて、更新して検出要求信号に含めて送信する。

　一方、ＵＥ１０Ｂは、ＵＥ１０ＡがＬＴＥ　Ｄｉｒｅｃｔで直接通信路を確立することができる能力情報などを示す識別情報により、ＵＥ１０ＡがＬＴＥ　Ｄｉｒｅｃｔを利用できることを検出しても良い。また、ＵＥ１０Ｂは、ＵＥ１０ＡがＷＬＡＮ　Ｄｉｒｅｃｔで直接通信路を確立することができる能力情報などを示す識別情報により、ＵＥ１０ＡがＷＬＡＮ　Ｄｉｒｅｃｔを利用できることを検出しても良い。

　次に、ＵＥ１０ＢのＥＰＳレイヤは、近隣検出を受けたことをアプリケーションに通知する（Ｓ３０１０）。ＵＥ１０Ｂのアプリケーションは、近隣検出に対する応答を行って良いかを確認し、近隣検出の確認をＵＥ１０ＢのＥＰＳレイヤに通知する（Ｓ３０１２）。

　近隣検出の確認を受けたＵＥ１０のＥＰＳレイヤは、近隣検出に対する応答を送信するための無線リソースを取得する（Ｓ３０１４）。無線リソースを取得する方法は種々の方法が考えられるが、例えば、ｅＮＢ４５が定期的に送信する情報に含まれる情報から取得しても良いし、ＵＥ１０ＡがｅＮＢ４５に問い合わせることにより、取得しても良い。

　次にＵＥ１０Ｂは、近隣検出信号をブロードキャストで送信する（Ｓ３０１６）。ここで、近隣検出信号には、ＰｒｏＳｅ　ＩＤ（ＵＥ１０Ｂ）、ＰｒｏＳｅ　ＩＤ（ＵＥ１０Ａ）、ｉｎ　ｃｏｖｅｒａｇｅフラグ１４７、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙ１４８、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅ１４９を含める。

　なお、ＵＥ１０Ｂが送信する近隣検出信号は、一定時間毎に送信されても良い。また、ｉｎ　ｃｏｖｅｒａｇｅフラグ１４７が更新される度に送信しても良い。ここで、ＵＥ１０ＡはＵＥ１０Ｂによって近隣検出信号が検出された後でも、近隣検出のための信号を、一定時間毎に送信し続けても良い。ｉｎ　ｃｏｖｅｒａｇｅフラグ１４７は、送信時点での、圏内または、圏外の状況に応じて、更新して検出要求信号に含めて送信する。

　一方、ＵＥ１０Ａは、ＵＥ１０ＢがＬＴＥ　Ｄｉｒｅｃｔで直接通信路を確立することができる能力情報などを示す識別情報により、ＵＥ１０ＢがＬＴＥ　Ｄｉｒｅｃｔを利用できることを検出しても良い。また、ＵＥ１０Ａは、ＵＥ１０ＢがＷＬＡＮ　Ｄｉｒｅｃｔで直接通信路を確立することができる能力情報などを示す識別情報により、ＵＥ１０ＢがＷＬＡＮ　Ｄｉｒｅｃｔを利用できることを検出しても良い。

　近隣検出信号をブロードキャストで受信したＵＥ１０Ａは、ＵＥ１０ＡとＵＥ１０Ｂのカバレッジ情報を検出する（Ｓ３０１７）。つまり、ＵＥ１０Ａのｉｎ　ｃｏｖｅｒａｇｅフラグ１４７、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙ１４８、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグ１４９を確認する。

　ＵＥ１０Ａは、ＵＥ１０Ａと４状態のいずれかであることを検出することができる。具体的には、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅである１状態のいずれかであることを検出することができる。

　次に、ＵＥ１０ＡのＥＰＳレイヤは、ＵＥ１０Ａのアプリケーションに近隣検出の確認を通知する（Ｓ３０１８）。ここで、近隣検出の確認には、ＰｒｏＳｅ　ＩＤ（ＵＥ１０Ｂ）を含める。

　ＵＥ１０ＡがＵＥ１０Ｂに送信するブロードキャストの送信（Ｓ３００８）は、あらかじめ取得した通信リソースを利用して、ユニキャストで送信しても良い。また逆に、ＵＥ１０ＢがＵＥ１０Ａに送信するブロードキャストの送信（Ｓ３００８）する場合、あらかじめ取得した通信リソースを利用して、ユニキャストで送信しても良い。ここで、取得した通信リソースとは、特定のＵＥに検出させるために利用することができる通信リソースであり、ｅＮＢ４５またはＭＭＥ４０によって明示的に通知されることにより割り当てられても良いし、あらかじめＵＥ１０ＡまたはＵＥ１０Ｂに通知されているものを利用しても良い。

　さらに、ＵＥ１０ＢがＵＥ１０Ａに送信するブロードキャストの送信（Ｓ３０１６）は、あらかじめ取得した通信リソースを利用して、ユニキャストで送信しても良い。また逆に、ＵＥ１０ＡがＵＥ１０Ｂに送信するブロードキャストの送信（Ｓ３０１６）する場合、あらかじめ取得した通信リソースを利用して、ユニキャストで送信しても良い。ここで、取得した通信リソースとは、特定のＵＥに検出させるために利用することができる通信リソースであり、ｅＮＢ４５またはＭＭＥ４０によって明示的に通知されることにより割り当てられても良いし、あらかじめＵＥ１０ＡまたはＵＥ１０Ｂに通知されているものを利用しても良い。

[５．３．１．２　Ｏｐｅｎ　ｄｉｓｃｏｖｅｒｙ]
　Ｏｐｅｎ　ｄｉｓｏｃｖｅｒｙについて説明する。Ｏｐｅｎ　ｄｉｓｏｃｖｅｒｙでは、近隣検出信号をブロードキャストで近隣検出の対象であるＵＥに問合せる形で送信するのではなく、近隣検出の対象であるＵＥが定期的に近隣検出信号を送信し、その近隣検出信号を受信することで、近隣検出を行うことができる。Ｏｐｅｎ　ｄｉｓｃｏｖｅｒｙを行うことを決定したＵＥ１０ＡのＥＰＳレイヤは、近隣検出の無線リソースを取得する（Ｓ３０２０）。ここで、近隣検出の無線リソースは、ＵＥ１０Ｂが定期的に送信する近隣検出信号に関する情報である。なお、この無線リソースを取得する方法は種々の方法が考えられるが、例えば、ｅＮＢ４５が定期的に送信する情報に含まれる情報から取得しても良いし、ＵＥ１０ＡがｅＮＢ４５に問い合わせることにより、取得しても良い。

　続いて、ＵＥ１０Ａは、Ｓ３０２０で受信した無線リソースを利用して、近隣検出の対象であるＵＥ１０Ｂを検出する（Ｓ３０２２）。なお、ＵＥ１０Ｂが送信する近隣検出信号には、ＰｒｏＳｅ　ＩＤ（ＵＥ１０Ｂ）、ｉｎ　ｃｏｖｅｒａｇｅフラグ１４７、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙ１４８、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅ１４９が含まれている。

　近隣検出信号（ブロードキャスト）を受信したＵＥ１０Ａは、ＵＥ１０ＡとＵＥ１０Ｂのカバレッジ情報を検出する（Ｓ３０１７）。つまり、ＵＥ１０Ｂのｉｎ　ｃｏｖｅｒａｇｅフラグ１４７、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙ１４８、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグ１４９を確認する。

　ＵＥ１０Ａは、ＵＥ１０Ｂと４状態のいずれかであることを検出することができる。具体的には、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＩｎ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＩｎ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅである１状態と、ＵＥ１０ＡがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅ、ＵＥ１０ＢがＯｕｔ　ｏｆ　ｃｏｖｅｒａｇｅである１状態のいずれかであることを検出することができる。

　ここで、ＵＥ１０Ｂのｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙが「不可」で、ＵＥ１０Ｂのｉｎ　ｃｏｖｅｒａｇｅフラグがｏｕｔ　ｏｆ　ｃｏｖｅｒａｇｅの場合、直接通信を行うことができないと判断しても良い。また、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグが「ｏｆｆ」で、ｏｕｔ　ｏｆ　ｃｏｖｅｒａｇｅの場合、直接通信を行うことができないと判断しても良い。

　近隣検出信号をブロードキャストで受信したＵＥ１０Ａは、ＵＥ１０ＡとＵＥ１０Ｂのカバレッジ情報を検出する（Ｓ３０２３）。つまり、ＵＥ１０Ａのｉｎ　ｃｏｖｅｒａｇｅフラグ１４７、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｃａｐａｂｉｌｉｔｙ１４８、ｐｕｂｌｉｃ　ｓａｆｅｔｙ　ｅｎａｂｌｅフラグ１４９を確認する。

　次に、ＵＥ１０ＡのＥＰＳレイヤは、ＵＥ１０Ａのアプリケーションに近隣検出の確認を通知する（Ｓ３０２４）。ここで、近隣検出の確認には、ＰｒｏＳｅ　ＩＤ（ＵＥ１０Ｂ）を含める。

　［６．１．１．変形例１］
　以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も特許請求の範囲に含まれる。

　また、各実施形態において各装置で動作するプログラムは、上述した実施形態の機能を実現するように、ＣＰＵ等を制御するプログラム（コンピュータを機能させるプログラム）である。そして、これら装置で取り扱われる情報は、その処理時に一時的に一時記憶装置（例えば、ＲＡＭ）に蓄積され、その後、各種ＲＯＭやＨＤＤの記憶装置に格納され、必要に応じてＣＰＵによって読み出し、修正・書き込みが行なわれる。

　ここで、プログラムを格納する記録媒体としては、半導体媒体（例えば、ＲＯＭや、不揮発性のメモリカード等）、光記録媒体・光磁気記録媒体（例えば、ＤＶＤ（Ｄｉｇｉｔａｌ　Ｖｅｒｓａｔｉｌｅ　Ｄｉｓｃ）、ＭＯ（Ｍａｇｎｅｔｏ　Ｏｐｔｉｃａｌ　Ｄｉｓｃ）、ＭＤ（Ｍｉｎｉ　Ｄｉｓｃ）、ＣＤ（Ｃｏｍｐａｃｔ　Ｄｉｓｃ）、ＢＤ等）、磁気記録媒体（例えば、磁気テープ、フレキシブルディスク等）等のいずれであってもよい。また、ロードしたプログラムを実行することにより、上述した実施形態の機能が実現されるだけでなく、そのプログラムの指示に基づき、オペレーティングシステムあるいは他のアプリケーションプログラム等と共同して処理することにより、本発明の機能が実現される場合もある。

　また、市場に流通させる場合には、可搬型の記録媒体にプログラムを格納して流通させたり、インターネット等のネットワークを介して接続されたサーバコンピュータに転送したりすることができる。この場合、サーバコンピュータの記憶装置も本発明に含まれるのは勿論である。

　また、上述した実施形態における各装置の一部又は全部を典型的には集積回路であるＬＳＩ（Ｌａｒｇｅ　Ｓｃａｌｅ　Ｉｎｔｅｇｒａｔｉｏｎ）として実現しても良い。各装置の各機能ブロックは個別にチップ化しても良いし、一部、または全部を集積してチップ化しても良い。また、集積回路化の手法はＬＳＩに限らず専用回路、または汎用プロセッサで実現しても良い。また、半導体技術の進歩によりＬＳＩに代替する集積回路化の技術が出現した場合、当該技術による集積回路を用いることも可能であることは勿論である。

　また、上述した実施形態においては、無線アクセスネットワークの例としてＬＴＥと、ＷＬＡＮ（例えば、ＩＥＥＥ８０２．１１ａ／ｂ／ｎ等）とについて説明したが、ＷＬＡＮの代わりにＷｉＭＡＸによって接続されても良い。

１　移動通信システム
２　移動通信システム２
５　ＩＰ移動通信ネットワーク
１０　ＵＥ
２０　ＰＤＮ
２５　ＧＭＬＣ
２７　ＬＣＳ　ｃｌｉｅｎｔ
３０　ＰＧＷ
３５　ＳＧＷ
４０　ＭＭＥ
４５　ｅＮＢ
５０　ＨＳＳ
５５　ＡＡＡ
６０　ＰＣＲＦ
６５　ｅＰＤＧ
７０　ＷＬＡＮ　ＡＮａ
　７２　ＷＬＡＮ　ＡＰａ
　７４　ＧＷ
７５　ＷＬＡＮ　ＡＮｂ
　７６　ＷＬＡＮ　ＡＰｂ
８０　ＬＴＥ　ＡＮ
９０　ＰｒｏＳｅサーバ
９５　ＡＰＰサーバ

Claims

　第１の端末装置と、前記第１の端末装置の近隣に位置する第２の端末装置が直接通信路を確立するための第１の端末装置における通信制御方法であって、
　前記第２の端末装置が送信する、近隣の端末装置に前記第２の端末装置を検出させるための信号をモニタリングするステップと、
　前記信号を受信して前記第２の端末装置が近隣に位置することを検出するステップと、
　前記信号に含まれる前記第２の端末装置がＬＴＥ基地局に在圏するか否かを示すカバレッジ情報を取得するステップと、
　前記カバレッジ情報に基づいて前記第２の端末装置が在圏しているか否かを検出するステップと、
を備える通信制御方法。
　前記カバレッジ情報に基づいて前記第２の端末装置が在圏することを検出した場合には、直接通信路に対するリソースの取得を要求する情報を含めて、直接通信路の確立要求を前記第２の端末装置に送信するステップをさらに備える請求項１に記載の通信制御方法。
　前記カバレッジ情報に基づいて前記第２の端末装置が在圏していないことを検出した場合には、
　直接通信路の確立要求を前記第２の端末装置に送信するステップと、
　直接通信路に対するリソースの要求をＬＴＥ基地局に送信するステップと、
　をさらに備える請求項１に記載の通信制御方法。
　前記カバレッジ情報に基づいて前記第２の端末装置が在圏していないことを検出した場合には、
　直接通信路の確立要求を前記第２の端末装置に送信するステップと、
　直接通信路に対するリソースの要求を在圏するＬＴＥ基地局が接続するコアネットワークに送信するステップと、
　をさらに備える請求項１に記載の通信制御方法。
　前記第１の端末装置がＬＴＥ基地局に在圏するか否かを検出するステップをさらに備え、
　前記第１の端末装置および前記第２の端末装置がともに在圏していないことを検出した場合には、
　予め第１の端末装置が保持するリソースを直接通信路に割り当てるステップと、
　前記リソースに関する情報を含めて、直接通信路の確立要求を前記第２の端末装置に送信するステップと、
を備える請求項１に記載の通信制御方法。
　近隣の端末装置に前記第１の端末装置を検出させるための信号を送信するステップをさらに備える請求項１から５のいずれか一項に記載の通信制御方法。
　直接通信路を確立する要求は、ＬＴＥに基づく直接通信路を確立することを要求する請求項１から６のいずれか一項に記載の通信制御方法。
　直接通信路を確立する要求は、無線ＬＡＮに基づく直接通信路を確立することを要求する請求項１から６のいずれか一項に記載の通信制御方法。
　第１の端末装置の近隣に位置する第２の端末装置と直接通信路を確立する第１の端末装置であって、
　第２の端末装置が送信する、近隣の端末装置に第２の端末装置を検出させるための信号をモニタリングし、
　前記信号を受信して第２の端末装置が近隣に位置することを検出し、
　前記信号に含まれる第２の端末装置がＬＴＥ基地局に在圏するか否かを示すカバレッジ情報を取得し、
　前記カバレッジ情報に基づいて第２の端末装置が在圏しているか否かを検出する端末装置。
　前記カバレッジ情報に基づいて前記第２の端末装置が在圏することを検出した場合には、直接通信路に対するリソースの取得を要求する情報を含めて、直接通信路の確立要求を前記第２の端末装置に送信する請求項９に記載の端末装置。
　前記カバレッジ情報に基づいて前記第２の端末装置が在圏していないことを検出した場合には、
　直接通信路の確立要求を前記第２の端末装置に送信し、
　直接通信路に対するリソースの要求をＬＴＥ基地局に送信する請求項９に記載の端末装置。
　前記カバレッジ情報に基づいて前記第２の端末装置が在圏していないことを検出した場合には、
　直接通信路の確立要求を前記第２の端末装置に送信し、
　直接通信路に対するリソースの要求を在圏するＬＴＥ基地局が接続するコアネットワークに送信する請求項９に記載の端末装置。
　前記第１の端末装置がＬＴＥ基地局に在圏するか否かを検出し、
　前記第１の端末装置および前記第２の端末装置がともに在圏していないことを検出した場合には、
　予め第１の端末装置が保持するリソースを直接通信路に割り当て、
　前記リソースに関する情報を含めて、直接通信路の確立要求を前記第２の端末装置に送信する請求項９に記載の端末装置。
　近隣の端末装置に前記第１の端末装置を検出させるための信号を送信する請求項９から１３のいずれか一項に記載の端末装置。
　直接通信路を確立する要求は、ＬＴＥに基づく直接通信路を確立することを要求する請求項９から１４のいずれか一項に記載の端末装置。
　直接通信路を確立する要求は、無線LANに基づく直接通信路を確立することを要求する請求項９から１４のいずれか一項に記載の端末装置。
　ＬＴＥアクセスネットワークに含まれる基地局装置であって、
　パブリックセーフティを用途とした通信リソースと、商用サービスを用途とした通信リソースとを管理し、
　端末装置が送信する直接通信路の確立の許可を要求するメッセージに含まれる、パブリックセーフティを用途とした通信路の確立の許可を要求するか、商用サービスを用途とした通信路の確立の許可を要求するかを識別する識別情報に基づいて通信リソースの割り当てを実行し、端末装置に前記通信リソースに関する情報を前記端末装置に通知する基地局装置。
　前記識別情報がパブリックセーフティを用途とした通信路の確立を要求する場合、パブリックセーフティを用途とした通信リソースからリソース割り当てを実行し、前記端末装置にリソースに関する情報を通知する請求項１７に記載の基地局装置。
　前記識別情報が商用サービスを用途とした通信路の確立を要求する場合、商用サービスを用途とした通信リソースからリソース割り当てを実行し、前記端末装置にリソースに関する情報を通知する請求項１７に記載の基地局装置。