JP6416663B2 - 通信システム - Google Patents

Description

本開示は、複数の通信端末装置と基地局とサーバとを備える通信システムに関する。

従来、基地局装置（ｅＮＢ：evolved NodeB）を介さずに端末（ＵＥ：User Equipment）同士が通信を行なう端末間（D2D: device to device）通信が知られている。Ｄ２Ｄ通信は、D2D Proximity Services (ProSe)とも称される。Proximity Servicesは、非特許文献１〜３に示すとおり、3GPP（3rd Generation Partnership Project）のRelease 12において規格化されている。特に、非特許文献２には、D2D Proximity Servicesにおける近接検知サービスである“Proximity discovery”（以下、「Ｄ２Ｄディスカバリサービス」と称する）が開示されている。

Ｄ２Ｄディスカバリサービスは、Ｄ２Ｄディスカバリ機能を有するＬＴＥ（Long Term Evolution）端末およびD2D Proximity Servicesを利用するアプリケーションプログラムによって実行可能である。また、ｅＮＢがＤ２Ｄディスカバリをサポートする圏内に位置するＵＥ間において近接検知を可能するサービスが検討されている。

Ｄ２Ｄディスカバリサービスでは、D2D Proximity Servicesを利用するアプリケーションプログラムの実行により、ｅＮＢが割り当てたディスカバリ専用の無線リソースプール、あるいは予めＳＩＭ（Subscriber Identity Module）等により設定された無線リソースプールから、ＵＥが任意に１つあるいは複数のリソース（ブロック）を選択し、ディスカバリ信号を送信する。これにより、ＵＥは、他のＵＥに自身の存在を通知する。また、ＵＥは、他のＵＥの存在を発見するために、ディスカバリ用の無線リソースのすべてあるいは一部を受信する。

ディスカバリ信号は、ProSe (Proximity Service) UE IDと、ProSe Application IDとを含む。ProSe Application IDは、アプリケーションプログラム毎に割り当てられた専用のＩＤである。それゆえ、Ｄ２Ｄを利用する複数のアプリケーションプログラムは、それぞれ、ProSe Application IDを含むディスカバリ信号の送信要求を自端末の制御部に行なう。また、各アプリケーションプログラムは、ＵＥにおいて受信された他のＵＥのディスカバリ信号に基づき、同じアプリケーションプログラムを実行している他のＵＥの存在を識別できる。その際、ＵＥは、識別結果をディスプレイに表示させることによって当該ＵＥの利用者に通知する。

このようなＤ２Ｄ通信を利用してＵＥを発見するための技術が開示されている。たとえば、特開２０１４−２３１５７号公報（特許文献１）は、ＵＥ発見方法を開示している。このＵＥ発見方法において、第１ＵＥは、移動通信システムにおける上り信号を監視し、監視した上り信号から、上記上り信号を送信する発見待ちＵＥの識別に利用可能な第１情報を抽出する。第１ＵＥは、第１情報付き監視報告メッセージを基地局に送信し、監視報告応答メッセージから上記発見待ちＵＥの機器識別子を取得した後に、ＵＥ発見過程を完成する。

特開２０１４−２３１５７号公報

3GPP TR 36.843 V12.0.1 (2014-03): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Study on LTE Device to Device Proximity Services; Radio Aspects (Release 12) 3GPP TR 23.703 V12.0.0 (2014-02)： 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Study on architecture enhancements to support Proximity-based Services (ProSe) (Release 12) 3GPP TS 23.303 V12.1.0 (2014-06)： 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Proximity-based services (ProSe); Stage 2 (Release 12)

特許文献１の構成では、発見待ちＵＥの上り信号がいつ送信されるのか不明である。そのため、特許文献１に係るＵＥ発見方法では、ＵＥ（端末）の発見が遅くなってしまう可能性が懸念される。

本開示は、上記のような問題点を解決するためになされたものであって、ある局面における目的は、Ｄ２Ｄ通信が可能な端末を用いて、発見待ち端末をより迅速に発見することが可能な通信システムを提供することを目的とする。

ある実施の形態に従うと、サーバと、基地局と、端末間通信が可能な複数の通信端末とを備えた通信システムが提供される。複数の通信端末の各々は、基地局を介さずに自端末の存在を相手端末に通知するためのディスカバリ信号を送信可能である。複数の通信端末のうちの第１の通信端末は、緊急事態に関連する緊急情報をディスカバリ信号に含めて送信する。複数の通信端末のうちの第２の通信端末は、第１の通信端末から緊急情報を含むディスカバリ信号を受信した場合、当該受信したディスカバリ信号に応じた第１の情報を基地局を介してサーバに送信する。サーバは、第２の通信端末から第１の情報を受信した場合、当該受信した第１の情報に応じた第１の通知情報を第１の通信端末に送信する。

本開示によると、Ｄ２Ｄ通信が可能な端末を用いて、発見待ち端末をより迅速に発見することが可能となる。

本実施の形態において、端末を発見するための第１の局面を示す図である。 図１に示した第１の局面の後の第２の局面を示す図である。 本実施の形態に従う通信システムの処理の流れを示すシーケンス図である。 端末の機能構成を説明するための機能ブロック図である。 基地局の機能構成を説明するための図である。 捜索端末において行われる処理の流れを説明するためのフローチャートである。 サーバにおいて行われる処理の流れを説明するためのフローチャートである。 発見待ち端末において行われる処理の流れを説明するためのフローチャートである。 本実施の形態の第１の変形例において、図１に示した第１の局面の後の第２の局面を示す図である。 図９に示した第２の局面の後の第３の局面を示す図である。 本実施の形態の第１の変形例に従う通信システムの処理の流れを示すシーケンス図である。 本実施の形態の第１の変形例において、捜索端末において行われる処理の流れを説明するためのフローチャートである。 本実施の形態の第２の変形例において、端末を発見するための第１の局面を示す図である。 図１３に示した第１の局面の後の第２の局面を示す図である。 本実施の形態の第３の変形例において、端末を発見するための第１の局面を示す図である。 図１５に示した第１の局面の後の第２の局面を示す図である。 図１６に示した第２の局面の後の第３の局面を示す図である。 本実施の形態の第３の変形例に従う通信システムの処理の流れを示すシーケンス図である。 本実施の形態の第３の変形例において、捜索端末において行われる処理の流れを説明するためのフローチャートである。 本実施の形態の第３の変形例において、発見待ち端末において行われる処理の流れを説明するためのフローチャートである。 本実施の形態の第４の変形例に従う通信システムの全体構成を示す図である。 端末のハードウェア構成を表わすブロック図である。 基地局のハードウェア構成を示すブロック図である。

以下、図面を参照しつつ、本発明の実施の形態について説明する。以下の説明では、同一の部品には同一の符号を付してある。それらの名称および機能も同じである。したがって、それらについての詳細な説明は繰り返さない。なお、以下では、アプリケーションプログラムを、略して、「アプリ」と称する。

＜システムの全体構成＞
図１は、本実施の形態に従う通信システムの全体構成を示す図である。図１を参照して、通信システムは、たとえば、ＬＴＥに対応する通信システムである。通信システムは、通信端末装置（以下、単に「端末」と称する。）１１，２１〜２３と、サーバ３０と、無線基地局（以下、単に「基地局」と称する。）５０とを含む。基地局５０は、セル５００を構成する。端末１１，２１〜２３の各々は、セル５００に在圏している。

端末１１，２１〜２３の各々は、ＬＴＥなどの無線アクセス技術に従った無線通信を実行するＵＥである。具体的には、端末１１，２１〜２３の各々は、基地局を介さずに、近くに存在する他の端末と、Ｄ２Ｄ通信（端末間通信）を行なうことが可能であり、Ｄ２Ｄディスカバリ機能を有するＬＴＥ端末（ＬＴＥ規格に準拠した携帯端末装置）である。典型的には、端末１１，２１〜２３の各々は、スマートフォンである。

端末１１，２１〜２３の各々には、Ｄ２Ｄディスカバリサービスを利用するアプリケーションプログラム（以下、「Ｄ２Ｄ対応アプリ」とも称する）が予めインストールされている。なお、Ｄ２Ｄ対応アプリとは、上述したように、D2D Proximity Serviceを利用することが可能なアプリである。Ｄ２Ｄ対応アプリの例としては、たとえば、ＳＮＳ、ゲーム、広告、コミュニケーションアプリなどのアプリが挙げられる。また、端末１１，２１〜２３の各々には、たとえば、D2D Proximity Servicesを実行可能な端末の識別子として“ProSe UE ID”が割り振られている。

端末１１，２１〜２３の各々は、基地局５０からの無線リソースプールの情報に基づき、Ｄ２Ｄのディスカバリ信号を送信するための無線リソースを任意に選択する。また、端末１１，２１〜２３の各々は、基地局５０を介さずにディスカバリ信号の送受信を行なうことが可能である。端末１１，２１〜２３の各々は、任意に選択したディスカバリ信号送信用の無線リソースを用いて、自端末の存在を周りの端末に通知するためのディスカバリ信号を送信する。ディスカバリ信号には、典型的には、アプリを識別するためのProSe Application ID、および端末を識別するProSe UE IDが含まれている。

＜システムの動作概要＞
図１〜３を参照して、システムの動作概要について説明する。具体的には、図１は、本実施の形態において、端末１１を発見するための第１の局面を示す図である。図２は、図１に示した第１の局面の後の第２の局面を示す図である。図３は、通信システムの処理の流れを示すシーケンス図である。なお、図１〜図３における説明では、端末２１〜２３の各々のユーザが、遭難した端末１１のユーザを捜索している場面を想定する。すなわち、端末１１が発見待ち（発見される側の）端末であり、端末２１〜２３が捜索（発見する側の）端末である。

図１，図３を参照して、端末１１，２１〜２３の各々は、自端末のおおよそ（精度が低い）の現在地を表す位置情報を基地局５０に送信する（図３のシーケンスＳＱ２，ＳＱ４，ＳＱ６，ＳＱ８）。端末１１，２１〜２３の各々は、通常通信（基地局５０を介した通信）およびＤ２Ｄ通信に必要な制御情報を基地局５０から受信する（シーケンスＳＱ１０，ＳＱ１２，ＳＱ１４，ＳＱ１６）。制御情報は、無線通信網を利用したＤ２Ｄ通信を許可するための許可情報、およびＤ２Ｄ通信に必要となる通信環境の設定情報を含む。設定情報には、通常通信およびＤ２Ｄ通信で許容される周波数帯などの無線リソースの他に、無線信号の電波強度、端末の発信タイミング（Ｄ２Ｄ通信の実行タイミング）、相手（着信側）端末の識別子（電話番号、端末識別子および加入者識別子など）を含んでいてもよい。

これらの処理の後に、端末１１が災害により遭難し、端末２１〜２３が端末１１を発見するための処理を実行する。

端末２１〜２３の各々は、緊急用のエクスプレッションを送信する（シーケンスＳＱ２０，ＳＱ２２，ＳＱ２４）。具体的には、端末２１〜２３の各々は、緊急事態に関連する緊急情報（たとえば、災害の発生を通知するための情報、人の捜索を通知するための情報、人の安否を確認するための情報など）を、自端末の存在を相手端末に通知するためのディスカバリ信号に含めて送信する。すなわち、緊急用のエクスプレッションには、上述したProSe Application IDおよび端末を識別するProSe UE IDと、緊急情報とが含まれる。本実施の形態では、災害が発生して端末１１が遭難している場合を想定するため、緊急情報は、災害発生の通知情報であるとする。そのため、緊急情報を含むディスカバリ信号を、「災害エクスプレッション」とも称する。

ここで、図１を参照して、端末２１、端末２２および端末２３から送信された災害エクスプレッションの到達範囲が、それぞれ範囲２１０、範囲２２０および範囲２３０で示されている。たとえば、範囲２１０は、端末２１から半径５００ｍ圏内であり、範囲２２０は、端末２２から半径５００ｍ圏内であり、範囲２３０は、端末２３から半径５００ｍ圏内である。図１の例では、端末１１は、範囲２１０および範囲２２０内には存在しているが、範囲２３０内には存在していない。そのため、端末１１は、端末２１，２２の各々から送信された災害エクスプレッションを受信し、端末２３から送信された災害エクスプレッションを受信しない。

端末１１は、端末２１，２２の各々から受信した災害エクスプレッションのコードをサーバ３０に問い合わせる（シーケンスＳＱ２６，ＳＱ２８）。具体的には、端末１１は、基地局５０を介して、端末２１，２２の各々から受信した災害エクスプレッションに応じた問い合わせ情報をサーバ３０に送信する。端末１１は、災害エクスプレッションを受信した場合には、自動的に（強制的に）当該災害エクスプレッションに応じた問い合わせ情報をサーバ３０に送信する。なお、ユーザの操作により当該問い合わせ情報の送信が行われる場合であってもよい。問い合わせ情報は、自端末（ここでは、端末１１）の識別情報（たとえば、ProSe UE ID）と、災害エクスプレッションのコードを要求するための情報と、災害エクスプレッションを送信した端末（ここでは、端末２１〜２３）の識別情報（たとえば、ProSe UE ID）とを含む。サーバ３０は、災害エクスプレッションを送信した端末の識別情報に基づいて、端末２１〜２３のうちどの端末から送信された災害エクスプレッションに対する問い合わせなのかを判断することができる。

サーバ３０は、端末２１，２２の各々から送信された災害エクスプレッションのコードを端末１１に送信する。サーバ３０は、端末１１から受信した問い合わせ情報に応じたフィードバック情報を端末２１〜２３に送信する（シーケンスＳＱ３０）。

具体的には、サーバ３０は、端末２１，２２の各々が送信した災害エクスプレッションに対する問い合わせ情報を端末１１から受信した旨を、フィードバック情報として端末２１〜２３に通知する。この通知により、端末２１〜２３は、端末１１が端末２１，２２の各々から送信された災害エクスプレッションを受信したことを把握できる。端末２１〜２３は、端末１１が、端末２１および端末２２の近傍に存在し、かつ端末２３の近傍には存在しないと推定する。

そこで、図２に示すように、端末２１は端末２２の方へ移動し、端末２２は端末２１の方へ移動し、端末２３は端末２１および端末２２の中間地点の方へ移動する。以降、端末２１〜２３は、再度、災害エクスプレッションを送信することによりサーバ３０からのフィードバック情報を受信し、端末１１の捜索エリアを絞り込んでいく。なお、端末２１〜２３は、互いに、現在の位置情報をやり取りしているものとする。たとえば、端末２１〜２３の各々は、ＧＰＳ（（Global Positioning System）信号に基づく現在の自端末の位置情報を他の端末に送信する。あるいは、端末２１〜２３の各々のユーザが、電話などでお互いの位置を知らせてもよい。また、端末２１〜２３の各々の端末が、Ｄ２Ｄ通信を用いてお互いの位置を知らせてもよい。

なお、上記シーケンスＳＱ３０において、サーバ３０は、フィードバック情報として、端末２１，２２の各々から送信された災害エクスプレッションを端末１１が受信した旨を、端末２１〜２３に通知してもよい。すなわち、フィードバック情報は、端末２１〜２３側で、自端末（あるいは他の端末）が送信した災害エクスプレッションが端末１１に届いているのかを判断できるような情報であればよい。

上記構成によると、発見待ち端末（端末１１）は、捜索端末（端末２１〜２３）から送信された災害エクスプレッションを受信すると、当該受信に応じた問い合わせ情報をサーバ３０に送信する。サーバ３０は、受信した問い合わせ情報に応じたフィードバック情報を捜索端末に送信する。

このように、捜索端末は、自端末による災害エクスプレッションの送信に対するフィードバックを確実に受けることができる。そのため、捜索端末は、発見待ち端末が自端末（あるいは他の端末）の近傍に存在するのか否かを迅速に判断できる。さらに、捜索端末は、他の端末による災害エクスプレッションの送信に対するフィードバックを取得することにより、より精度よく迅速に発見待ち端末の位置を推定することができる。

また、上記構成は、特に、災害が発生して発見待ち端末（端末１１）自身がＧＰＳ等の高精度な位置情報の取得が困難な場合に、特に有用である。たとえば、災害発生時において、地下街やショッピングモール内では、崩落事故などの影響により精度の高い位置情報取得は難しい可能性が高い。また、ＧＰＳを用いた位置情報の取得は、消費電力が大きく、端末の電力がすぐになくなってしまう可能性もある。しかしながら、上記構成によると、発見待ち端末は受信した災害エクスプレッションに応じた問い合わせ情報をサーバ３０に送信するだけで、捜索端末による発見待ち端末の捜索が可能となる。そのため、発見待ち端末はＧＰＳ等の高精度な位置情報を取得する必要がなく、また当該取得による電力消費を避けることもできる。

また、発見待ち端末は、災害エクスプレッションを受信すると、当該災害エクスプレッションに応じた問い合わせ情報を自動的に送信する。そのため、発見待ち端末のユーザが、災害発生時の怪我などにより端末を操作できない場合であっても、問い合わせ情報がサーバ３０に送信される。これにより、捜索端末はサーバ３０からフィードバック情報を受信することができるため、発見待ち端末を捜索することができる。また、発見待ち端末が防水性を有する場合には、当該端末が水没している場合であっても捜索端末により捜索が可能となる。

＜機能構成＞
（端末）
図４は、端末１１の機能構成を説明するための機能ブロック図である。図４を参照して、端末１１は、アプリ実行部１５１と、Ｄ２Ｄ管理部１５２と、ＧＵＩ（Graphical User Interface）部１５３と、記憶部１５４と、受信部１５５と、送信部１５６とを含む。ＧＵＩ部１５３は、表示部１５３１と入力部１５３２とを有する。受信部１５５は、Ｄ２Ｄディスカバリ信号受信部１５５１を有する。送信部１５６は、ディスカバリ信号送信部１５６１を有する。

アプリ実行部１５１は、記憶部１５４に予め記憶されているＤ２Ｄ対応の災害情報アプリ＃１，アプリ＃２，アプリ＃３，…を記憶部１５４から読出し、各々のアプリを実行する。なお、災害情報アプリ＃１は、災害に関連する情報（災害関連情報）を配信したり、受信したりすることができる緊急用のアプリである。

アプリ実行部１５１は、ユーザ操作を受け付けてアプリを起動する。アプリ実行部１５１は、外部装置からの起動指示を受信した場合にアプリを自動的に起動してもよい。なお、以下では、Ｄ２Ｄ通信を行なうための設定（ユーザＩＤやProSe Application ID等の設定）がされている構成を例に挙げて説明する。実行中の各アプリ＃１，＃２，＃３，…は、ディスカバリ信号の送受信が必要となった場合、ディスカバリ信号の送受信要求をＤ２Ｄ管理部１５２に送る。

Ｄ２Ｄ管理部１５２は、Ｄ２Ｄ通信に関する各種の処理を管理する。たとえば、Ｄ２Ｄ管理部１５２は、各アプリ＃１，＃２，＃３，…から送信された、ディスカバリ信号の送受信要求を受信すると、ディスカバリ信号の送受信を管理（制御）する。また、Ｄ２Ｄ管理部１５２は、自端末の通信モードを、基地局５０を介する通常通信のモード（以下、「通常モード」とも称する）からＤ２Ｄ通信のモード（以下、「Ｄ２Ｄモード」とも称する）に切り替える。たとえば、Ｄ２Ｄ管理部１５２は、他の端末または基地局５０から、自端末をＤ２Ｄモードに変更するための指示を受け付けると、当該切り替えを実行する。

ＧＵＩ部１５３の表示部１５３１は、各種の情報を表示する。入力部１５３２は、ユーザから各種の入力を受け付ける。

受信部１５５は、基地局（図１の場合には基地局５０）から送信されるデータ、および他の端末（図１の場合には端末２１〜２３）から送られてくる各種のデータ（ユーザデータ等）を受信する。特に、受信部１５５のディスカバリ信号受信部１５５１は、他の端末から送信されてくるディスカバリ信号（たとえば、災害エクスプレッション）等を受信する。

送信部１５６は、基地局（図１の場合には基地局５０）に対して、あるいはＤ２Ｄ通信の場合には他の端末に対して、データ（ユーザデータ等）を送信する。特に、ディスカバリ信号送信部１５６１は、ディスカバリ信号（たとえば、災害エクスプレッション）を送信する。たとえば、各アプリに対応するディスカバリ信号は、各アプリが起動し、実行されていることを条件に、マルチキャスト送信される。

なお、端末２１〜２３も、端末１１と同様の機能的構成を有するため、端末２１〜２３の機能構成については説明を繰り返さない。

（基地局）
図５は、基地局の機能構成を説明するための図である。図５を参照して、基地局５０は、主制御部２５１と、記憶部２５２と、通信制御部２５３と、無線通信部２５４と、アンテナ２５５とを含む。

主制御部２５１は、基地局５０の全体の動作を制御する。主制御部２５１は、ＣＰＵに対応する。より詳しくは、ＣＰＵがＯＳ（Operating System）および各種のプログラムを実行することにより、主制御部２５１が実現される。

記憶部２５２は、ＯＳ、各種のプログラム、各端末から受信（取得）した各種のデータを記憶する。記憶部２５２は、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）、ＨＤＤ（Hard Disk Drive）等で構成される。

通信制御部２５３は、基地局５０が構成するセル５００に在圏する端末との間の通信と、サーバ３０との通信とを制御する。無線通信部２５４は、アンテナ２５５からデータを送信するため各種の処理、アンテナ２５５で受信した信号を受信するための各種の処理を行なう。無線通信部２５４は、典型的には、ベースバンド変換等を行なう。

＜処理手順＞
端末１１，端末２１〜２３，サーバ３０の各装置で行なわれる処理について具体的に説明する。

（端末２１〜２３）
図６は、捜索側の端末２１において行われる処理の流れを説明するためのフローチャートである。また、図６は、端末２２，２３において行われる処理の流れを説明するためのフローチャートでもある。ここでは、サーバ３０は、端末１１から受信した問い合わせ情報に応じたフィードバック情報を端末２１〜２３すべてに送信するものとする。

図６を参照して、端末２１は、災害エクスプレッションの到達範囲を設定する（ステップＳ２）。具体的には、端末２１は、災害エクスプレッションの送信パワー（送信電力）を調整して当該到達範囲を設定する。たとえば、端末２１は、自端末から半径５００ｍまで災害エクスプレッションが到達可能なように送信パワーを調整する。

端末２１は、災害エクスプレッションを送信する（ステップＳ４）。具体的には、端末２１のユーザは、災害情報アプリ＃１を起動する。ユーザにより、当該アプリのＵＩを用いた送信指示が選択されると、災害エクスプレッションが送信される。

端末２１は、サーバ３０からフィードバック情報を受信したか否かを判断する（ステップＳ６）。端末２１は、フィードバック情報を受信しない場合には（ステップＳ６においてＮＯ）、ステップＳ４からの処理を繰り返す（すなわち、端末２１は、災害エクスプレッションを再送信する）。なぜなら、端末２１がフィードバック情報を受信しないということは、端末１１が、端末２１〜２３のうちのどの端末からも災害エクスプレッションを受信していないということである。すなわち、端末１１は、端末２１〜２３のどの端末の近傍（災害エクスプレッションの到達範囲内）にも存在しない。そのため、端末２１のユーザは、捜索エリアを移動して、再度、災害エクスプレッションの送信指示を端末２１に与える必要がある。

端末２１は、フィードバック情報を受信した場合には（ステップＳ６においてＹＥＳ）、フィードバック情報に基づいて端末１１の位置を推定する（ステップＳ８）。たとえば、フィードバック情報は、端末２１，２２の各々が送信した災害エクスプレッションに対する問い合わせ情報を、サーバ３０が端末１１から受信した旨の通知情報であるとする。この場合、端末２１は、フィードバック情報に基づいて、端末１１が端末２１および端末２２の近傍に存在し、かつ端末２３の近傍には存在しないと推定する。

他の例として、フィードバック情報は、端末２２が送信した災害エクスプレッションに対する問い合わせ情報を、サーバ３０が端末１１から受信した旨の通知情報であるとする。この場合、端末２１は、端末１１が端末２２の近傍にのみ存在し、端末２１および端末２２の近傍には存在しないと推定する。端末２１は、推定結果を自端末のディスプレイに表示したり、スピーカから出力することによりユーザに報知したりしてもよい。

端末２１のユーザは、推定結果に基づいて移動する。端末２１は、端末１１を発見した旨の指示をユーザから受け付けたか否かを判断する（ステップＳ１０）。端末２１は、当該指示を受け付けていない場合には（ステップＳ１０においてＮＯ）、ステップＳ４からの処理を繰り返す。すなわち、端末２１は、再度、災害エクスプレッションを送信する。一方、端末２１は、当該指示を受け付けた場合には（ステップＳ１０においてＹＥＳ）、処理を終了する。

（サーバ３０）
図７は、サーバ３０において行われる処理の流れを説明するためのフローチャートである。図７を参照して、サーバ３０は、災害エクスプレッションに対する問い合わせ情報を端末１１から受信したか否かを判断する（ステップＳ２０）。サーバ３０は、問い合わせ情報を受信していない場合には（ステップＳ２０においてＮＯ）、ステップＳ２０の処理を繰り返す。

サーバ３０は、問い合わせ情報を受信した場合には（ステップＳ２０においてＹＥＳ）、当該問い合わせ情報が、端末２１〜２３のうちのどの捜索端末が送信した災害エクスプレッションに対する問い合わせ情報なのかを特定する（ステップＳ２２）。具体的には、サーバ３０は、問い合わせ情報に含まれる端末の識別情報に基づいて当該特定を行なう。たとえば、問い合わせ情報に端末２１の識別情報が含まれている場合には、当該問い合わせ情報は、端末２１が送信した災害エクスプレッションに対する問い合わせ情報であると特定する。

サーバ３０は、端末１１の捜索を行なっている端末２１〜２３にフィードバック情報を送信する（ステップＳ２４）。サーバ３０は、たとえば、端末２１が送信した災害エクスプレッションに対する問い合わせ情報のみを受信している（すなわち、端末２２，２３が送信した災害エクスプレッションに対する問い合わせ情報を受信していない）場合を考える。この場合、サーバ３０は、端末２１が送信した災害エクスプレッションに対する問い合わせ情報を端末１１から受信した旨を、フィードバック情報として端末２１〜２３に通知する。

そして、サーバ３０は、ステップＳ２０からの処理を繰り返す。すなわち、サーバ３０は、災害エクスプレッションに対する問い合わせ情報を端末１１から受信する度に、端末２１〜２３にフィードバック情報を送信する。

（端末１１）
図８は、発見待ちの端末１１において行われる処理の流れを説明するためのフローチャートである。図８を参照して、端末１１は、災害エクスプレッションを受信したか否かを判断する（ステップＳ３２）。端末１１は、災害エクスプレッションを受信していない場合には（ステップＳ３２においてＮＯ）、ステップＳ３２の処理を繰り返す。

端末１１は、災害エクスプレッションを受信した場合には（ステップＳ３２においてＹＥＳ）、当該受信した災害エクスプレッションに応じた問い合わせ情報をサーバ３０に送信する（ステップＳ３４）。端末１１は、災害エクスプレッションの詳細内容をサーバ３０から受信する（ステップＳ３６）。具体的には、端末１１は、災害エクスプレッションのコードの詳細内容（すなわち、この災害エクスプレッションのコードが、災害の発生を通知するためのコードであること）を受信する。

ただし、端末１１は、災害エクスプレッションを受信した場合に、そのコードを確認することにより、災害エクスプレッションが緊急用のエクスプレッションであることは把握できるものとする。そのため、端末１１は、Ｄ２Ｄモードに設定されていない場合であっても、緊急用のエクスプレッション（ここでは、災害エクスプレッション）を受信したときには、当該受信したエクスプレッションに応じた問い合わせ情報をサーバ３０に送信する。

＜変形例＞
次に、通信システムの変形例について説明する。

（第１の変形例）
図１，図９〜図１１を参照して、本実施の形態の第１の変形例に従う通信システムについて説明する。具体的には、第１の変形例における、端末１１を発見するための第１の局面は、上述した図１の局面と同じである。図９は、本実施の形態の第１の変形例において、図１に示した第１の局面の後の第２の局面を示す図である。図１０は、図９に示した第２の局面の後の第３の局面を示す図である。図１１は、本実施の形態の第１の変形例に従う通信システムの処理の流れを示すシーケンス図である。なお、図１，図９〜図１１における説明では、端末２１〜２３の各々のユーザが、遭難した端末１１のユーザを捜索している場面を想定する。

図１１を参照して、シーケンスＳＱ２〜ＳＱ３０の処理は、それぞれ図３の処理と同じであるため、ここでは説明を繰り返さない。

シーケンスＳＱ３０において、サーバ３０は、端末２１，２２の各々が送信した災害エクスプレッションに対する問い合わせ情報を端末１１から受信した旨を、フィードバック情報として端末２１〜２３に通知している。そのため、端末２１〜２３は、端末１１が端末２１および端末２２の近傍に存在し、かつ端末２３の近傍には存在しないことを把握している。

そこで、自端末の近傍に端末１１が存在している端末２１，２２の各々は、到達範囲を小さくして災害エクスプレッションを送信する（シーケンスＳＱ４２，ＳＱ４４）。一方、自端末の近傍に端末１１が存在しない端末２３は、到達範囲を変更せずに災害エクスプレッションを送信する（シーケンスＳＱ４６）。

具体的には、第２の局面における範囲２１０および範囲２２０（図９参照）は、それぞれ第１の局面における範囲２１０および範囲２２０（図１参照）よりも小さくなる。一方、図９に示す範囲２３０と、図１に示す範囲２３０とは同じ大きさである。図９を参照すると、端末１１は、範囲２１０内にのみ存在し、範囲２２０および範囲２３０には存在していないことがわかる。そのため、端末１１は、端末２１から送信された災害エクスプレッションを受信するが、端末２２，２３の各々から送信された災害エクスプレッションを受信しない。

端末１１は、端末２１から受信した災害エクスプレッションのコードをサーバ３０に問い合わせる（シーケンスＳＱ４８）。サーバ３０は、端末２１から送信された災害エクスプレッションのコードを端末１１に送信する。サーバ３０は、端末２１〜２３にフィードバック情報を送信する（シーケンスＳＱ５０）。具体的には、サーバ３０は、端末２１が送信した災害エクスプレッションに対する問い合わせ情報を端末１１から受信した旨を、フィードバック情報として端末２１〜２３に通知する。端末２１〜２３は、範囲２１０内に端末１１が存在し、かつ範囲２２０および範囲２３０内には存在しないと推定する。

そこで、図１０に示すように、端末２１は待機し、端末２２は端末２１の方へ移動し、端末２３は端末２１の方へ移動する。以降、端末２１〜２３は、再度、災害エクスプレッションを送信することによりサーバ３０からのフィードバック情報を受信し、端末１１の捜索エリアを絞り込んでいく。特に、第１の変形例においては、端末２１〜２３の各々は、フィードバック情報に基づいて、自端末の近傍（災害エクスプレッションの到達範囲内）に端末１１が存在すると判断した場合には、災害エクスプレッションの到達範囲を小さくする。

図１２は、本実施の形態の第１の変形例において、端末２１において行われる処理の流れを説明するためのフローチャートである。また、図１２は、端末２２，２３において行われる処理の流れを説明するためのフローチャートでもある。ここでは、サーバ３０は、端末１１から受信した問い合わせ情報に応じたフィードバック情報を端末２１〜２３すべてに送信するものとする。

図１２を参照して、ステップＳ２，Ｓ４の処理は、図６の処理と同じであるため、説明を繰り返さない。端末２１は、フィードバック情報として、自端末が送信した災害エクスプレッションに対する問い合わせがあった旨をサーバ３０から受信したか否かを判断する（ステップＳ１０２）。

当該フィードバック情報を受信した場合には（ステップＳ１０２においてＹＥＳ）、端末２１は、災害エクスプレッションの到達範囲を小さくして（ステップＳ１０４）、ステップＳ４からの処理を繰り返す。このように、端末２１が、災害エクスプレッションの送信電力を弱めて再送信する理由は、端末１１の位置をさらに絞り込むためである。

具体的には、端末２１が当該フィードバック情報を受信した（ステップＳ１０２においてＹＥＳ）ということは、自端末の近傍（現在の範囲２１０内）に端末１１が存在することを意味する。そこで、端末１１が自端末からどの程度の距離に存在しているのかをさらに絞り込むため、端末２１は、災害エクスプレッションの到達範囲を、前回（当該フィードバック情報を受信する前に）設定した到達範囲よりも小さくして、再度、災害エクスプレッションを送信する。すなわち、端末２１は、フィードバック情報（自端末が送信した災害エクスプレッションに対する問い合わせがあった旨）を受信した場合、ディスカバリ信号の到達範囲を、当該フィードバック情報を受信していない場合の当該到達範囲よりも小さくする。たとえば、ステップＳ２において、自端末から半径５００ｍまで災害エクスプレッションが到達するように送信電力が設定されている場合には、今回の送信電力は、自端末から半径２５０ｍまで災害エクスプレッションが到達するように調整される。

一方、当該フィードバック情報を受信していない場合には（ステップＳ１０２においてＮＯ）、端末２１は、フィードバック情報として、他の端末（ここでは、端末２２および端末２３の少なくとも一方）が送信した災害エクスプレッションに対する問い合わせがあった旨をサーバ３０から受信したか否かを判断する（ステップＳ１０６）。当該フィードバック情報を受信していない場合には（ステップＳ１０６においてＮＯ）、端末２１は、災害エクスプレッションの到達範囲を小さくしたか否かを判断する（ステップＳ１０８）。すなわち、端末２１は、ステップＳ１０４の処理を実行したか否かを判断する。

端末２１は、当該到達範囲を小さくしている場合には（ステップＳ１０８においてＹＥＳ）、ステップＳ１０６からの処理を繰り返す。この場合、端末２１は、端末１１が前回の災害エクスプレッションの到達範囲内（端末２１から半径５００ｍ圏内）には存在し、今回の当該到達範囲内（端末２１から半径２５０ｍ圏内）には存在しないことを推定できる。ただし、端末２１は、端末１１が存在する方向の推定までは難しい。そこで、端末２１は、他の端末が送信した災害エクスプレッションに対する問い合わせがあった旨をサーバ３０から受信するまで待機する。

端末２１は、当該到達範囲を小さくしていない場合には（ステップＳ１０８においてＮＯ）、ステップＳ４からの処理を繰り返す。なぜなら、この場合、端末１１は、端末２１〜２３のどの端末の近傍にも存在しない。そのため、端末２１のユーザは、捜索エリアを移動して、再度、災害エクスプレッションの送信指示を端末２１に与える必要がある。

ステップＳ１０６において、端末２１は、他の端末が送信した災害エクスプレッションに対する問い合わせがあった旨をサーバ３０から受信した場合には（ステップＳ１０６においてＹＥＳ）、端末１１の位置を推定する（ステップＳ１１０）。たとえば、端末２１は、端末２２が送信した災害エクスプレッションに対する問い合わせがあった旨をサーバ３０から受信したとする。また、端末２１は、災害エクスプレッションの到達範囲を５００ｍから２５０ｍに小さくしているとする。この場合、端末２１は、端末１１が自端末から２５０ｍ〜５００ｍの範囲内かつ端末２２の近傍に存在し、端末２３の近傍には存在しないと推定する。

端末２１のユーザは、推定結果に基づいて移動する。そして、端末２１は、ステップＳ１０の処理を実行する。ステップＳ１０の処理は、図６の処理と同じであるため、説明を繰り返さない。

上記構成によると、捜索端末は、自端末による災害エクスプレッションの到達範囲内に発見待ち端末が存在する場合には、災害エクスプレッションの到達範囲を小さくして、当該災害エクスプレッションを再送信する。そのため、捜索端末は、自端末と発見待ち端末との距離をより精度よく把握できるため、発見待ち端末をより迅速に発見することが可能となる。

なお、上記では、端末２１（捜索端末）が災害エクスプレッションの到達範囲を小さくしながら、自端末と端末１１（発見待ち端末）との距離を把握する構成について説明したが、当該構成に限られない。たとえば、端末２１は、到達範囲が５００ｍに設定された災害エクスプレッションを送信した場合にはフィードバック情報を受信したが、到達範囲を小さくした（たとえば、２５０ｍ）災害エクスプレッションを送信した場合にはフィードバック情報を受信できなかったとする。この場合、端末２１は、端末１１が自端末から２５０ｍ〜５００ｍの範囲内に存在すると推定できるため、到達範囲を２５０ｍから３７５ｍに大きくして、再度、災害エクスプレッションを送信してもよい。端末２１は、フィードバック情報を受信した場合には端末１１が自端末から２５０ｍ〜３７５ｍの範囲内に存在すると推定できるし、フィードバック情報を受信しなかった場合には端末１１が自端末から３７５ｍ〜５００ｍの範囲内に存在すると推定できる。端末２１は、フィードバック情報の受信の有無に応じて到達範囲の変更を繰り返すことにより、自端末と端末１１との距離をより精度よく推定することができる。

このように、端末２１は、フィードバック情報の受信の有無に基づいて、災害エクスプレッションの到達範囲を大きくしたり、小さくしたりしながら自端末と端末１１との距離を推定することもできる。すなわち、端末２１は、フィードバック情報を受信した場合には、災害エクスプレッションの到達範囲を、前回（当該フィードバック情報を受信する前に）設定した到達範囲とは異なるように変更して、再度、災害エクスプレッションを送信する。これにより、端末２１は、端末１１をより迅速に発見することが可能となる。

（第２の変形例）
本実施の形態の第２の変形例では、災害などにより基地局５０が停止した場合に、端末１１を発見する構成について説明する。

図１３は、本実施の形態の第２の変形例において、端末１１を発見するための第１の局面を示す図である。図１４は、図１３に示した第１の局面の後の第２の局面を示す図である。図１３および図１４では、基地局５０が停止（通信不能な状態）しており、基地局５０に隣接する基地局５１が生存（通信可能な状態）しているものとする。

停止した基地局５０が構成するセル５００内の端末１１，２１〜２３は、基地局５０との通信が途絶えて圏外になると、通信モードを、通常モードから基地局５０を介さないＤ２Ｄモードに切り替える。また、端末１１，２１〜２３の各々は、ディスカバリ信号を出して周囲に存在する他の端末を検索（サーチ）し、応答してきた（サーチによって発見された）端末とＤ２Ｄ通信を確立する。たとえば、端末２１は、端末１１とＤ２Ｄ通信を確立する。このとき、端末２１が割当てた無線リソースで端末１１とＤ２Ｄ通信を行うように構成してもよい。

なお、生存する基地局５１が構成するセル５１０内の端末２５は、基地局５１からＤ２Ｄ通信の指示を受けてもよい。たとえば、基地局５１は、複数の基地局の動作を監視する監視装置などによって基地局５０が停止したことを示す通知情報を受信する。端末２５は、ディスカバリ信号を出して他の端末をサーチし、応答してきた端末２４とＤ２Ｄ通信を確立する。このとき、基地局５１が割当てた無線リソースで端末２５が端末２４とＤ２Ｄ通信を行うように、通信システムを構成してもよい。

セル５１０内に存在する端末１１とのＤ２Ｄ通信が確立した端末２１は、さらにＤ２Ｄ通信可能な他の端末をサーチする。そして、端末２１は、サーチされた端末２４とＤ２Ｄ通信を確立する。同様に、端末２４は、端末２５との間でＤ２Ｄ通信を確立する。これにより、基地局５０が停止した場合であっても、端末１１は、端末２１および端末２４を経由して、生存している基地局５１が構成するセル５１０に在圏する端末２５との通信が可能となる。

そのため、基地局５０が停止した場合であっても、端末１１は、端末２１〜２３の各々から送信される災害エクスプレッションに対する問い合わせ情報をサーバ３０に送信することができる。図１３の例では、端末１１は、災害エクスプレッションを受信した場合、端末２１、端末２４、端末２５および基地局５１を介して、受信した災害エクスプレッションに対する問い合わせ情報をサーバ３０に送信する。

具体的には、Ｄ２Ｄ通信を用いて、問い合わせ情報が「端末１１→端末２１→端末２４」のルートを経由して端末２５まで送信される。セル５１０に在圏する端末２５は、基地局５１を介して、端末２４から受信した問い合わせ情報をサーバ３０に送信する。

同様に、端末２１〜２３の各々は、少なくとも基地局５１および端末２５を介して、サーバ３０からフィードバック情報を受信する。図１３の例では、端末２１は、基地局５１、端末２５および端末２４を介して、サーバ３０から送信されるフィードバック情報を受信する。

端末２１〜２３の各々は、サーバ３０からのフィードバック情報を受信することにより、端末１１の位置を推定することができる。たとえば、端末２１〜２３の各々は、端末１１が、端末２１および端末２２の近傍に存在し、端末２３の近傍には存在しないと推定したとする。この場合、図１４に示すように、端末２１は端末２２の方へ移動し、端末２２は端末２１の方へ移動し、端末２３は端末２１および端末２２の中間地点の方へ移動する。以降、端末２１〜２３は、再度、災害エクスプレッションを送信することによりサーバ３０からのフィードバック情報を受信して、端末１１の捜索エリアを絞り込んでいく。

上記構成によると、端末が在圏するセルを構成する基地局が停止した場合であっても、当該端末は、Ｄ２Ｄ通信を用いることにより、生存する基地局を介してサーバに接続することができる。そのため、発見待ち端末が災害エクスプレッションに応じた問い合わせ情報をサーバに送信可能であるとともに、捜索端末がフィードバック情報をサーバから受信することができる。

（第３の変形例）
図１５〜図１８を参照して、本実施の形態の第３の変形例について説明する。図１５は、本実施の形態の第３の変形例において、端末１１を発見するための第１の局面を示す図である。図１６は、図１５に示した第１の局面の後の第２の局面を示す図である。図１７は、図１６に示した第２の局面の後の第３の局面を示す図である。図１８は、本実施の形態の第３の変形例に従う通信システムの処理の流れを示すシーケンス図である。なお、図１５〜図１８における説明では、端末２１〜２３の各々のユーザが、遭難した端末１１のユーザを捜索している場面を想定する。

図１８を参照して、図１８のシーケンスＳＱ２〜ＳＱ２４の処理は、それぞれ図３の処理と同じであるため、ここでは説明を繰り返さない。なお、図１５では、端末２１〜２３の各々が、災害エクスプレッションを送信する（シーケンスＳＱ２０，ＳＱ２２，ＳＱ２４）までの局面が示されている。図１５に示すように、端末１１は、範囲２１０および範囲２２０内に存在し、範囲２３０内には存在しない。そのため、端末１１は、端末２１，２２の各々から送信された災害エクスプレッションを受信するが、端末２３から送信された災害エクスプレッションを受信しない。

端末１１は、端末２１，２２の各々から受信した災害エクスプレッションに対する応答用のエクスプレッションを送信する（シーケンスＳＱ５２，ＳＱ５４）。具体的には、端末１１は、災害エクスプレッションの受信に対する応答情報をディスカバリ信号に含めて送信する。すなわち、応答用のエクスプレッションには、上述したProSe Application IDおよび自端末を識別するProSe UE IDと、災害エクスプレッションの受信を通知するための情報（災害情報エクスプレッションに含まれる相手端末のProSe UE IDなど）とが含まれる。以下の説明では、応答情報を含むディスカバリ信号を、「応答エクスプレッション」とも称する。

ここで、図１６を参照して、端末１１から送信された応答エクスプレッションの到達範囲が、範囲１１０で示されている。たとえば、範囲１１０は、端末１１から半径５００ｍ圏内であり、端末２１〜２３の各々から送信される災害エクスプレッションの到達範囲と同じである。これによると、端末１１から送信された応答エクスプレッションは、範囲１１０内に存在する端末２１，２２により受信され、端末２３には受信されない。

端末２１〜２３の各々は、基地局５０を介した通常通信（あるいは、Ｄ２Ｄ通信）により、この応答結果（端末２１，２２は応答エクスプレッションを受信したが、端末２３は応答エクスプレッションを受信しなかったこと）を共有する。これにより、端末２１〜端末２３の各々は、端末１１が、端末２１および端末２２の中間地点付近に存在すると推定する。

この推定結果に基づいて、端末２１〜２３の各々は、端末１１の捜索エリアを絞り込む。具体的には、図１７に示すように、端末２１は端末２２の方へ移動し、端末２２は端末２１の方へ移動し、端末２３は端末２１および端末２２の中間地点の方へ移動する。以降、端末２１〜２３は、再度、災害エクスプレッションを送信して端末１１から応答エクスプレッションを受信することにより、端末１１の捜索エリアをさらに絞り込んでいく。

図１９は、本実施の形態の第３の変形例において、端末２１において行われる処理の流れを説明するためのフローチャートである。また、図１９は、第３の変形例において、端末２２，２３において行われる処理の流れを説明するためのフローチャートでもある。

図１９を参照して、ステップＳ２，Ｓ４の処理は、図６の処理と同じであるため、説明を繰り返さない。端末２１は、自端末が送信した災害エクスプレッションに対する応答エクスプレッションを受信したか否かを判断する（ステップＳ１１２）。

端末２１は、応答エクスプレッションを受信した場合には（ステップＳ１１２においてＹＥＳ）、他の端末（ここでは、端末２２，２３）に対して、当該受信を報告する（ステップＳ１１４）。端末２１は、他の端末が応答エクスプレッションを受信した旨の報告（受信報告）を当該他の端末から受けたか否かを判断する（ステップＳ１１６）。端末２１は、受信報告を受けていない場合には（ステップＳ１１６においてＮＯ）、ステップＳ１１４の処理を繰り返す。なぜなら、この場合、端末２１は、端末１１が自端末の近傍（災害エクスプレッションの到達範囲内）に存在することまでは推定できるが、端末１１が存在する方向までは推定できない。そこで、端末２１は、応答エクスプレッションの受信報告を他の端末から受けるまで待機する。

端末２１は、他の端末から応答エクスプレッションの受信報告を受けた場合には（ステップＳ１１６においてＹＥＳ）、端末１１の位置を推定する（ステップＳ１２０）。たとえば、端末２１は、端末２２から応答エクスプレッションの受信報告を受けているとする。この場合、端末２１は、自端末と端末２２との中間点付近に端末１１が存在すると推定する。端末２１のユーザは、推定結果に基づいて自端末と端末２２との中間点付近に向かって移動する。そして、端末２１は、ステップＳ１０の処理を実行する。ステップＳ１０の処理は、図６の処理と同じであるため、説明を繰り返さない。

ステップＳ１１２において、端末２１は、応答エクスプレッションを受信しない場合には（ステップＳ１１２においてＮＯ）、応答エクスプレッションの受信報告を他の端末から受けたか否かを判断する（ステップＳ１１８）。端末２１は、当該受信報告を受けていない場合には（ステップＳ１１８においてＮＯ）、ステップＳ４からの処理を繰り返す。なぜなら、この場合、端末１１は、端末２１〜２３のどの端末の近傍にも存在しない。そのため、端末２１のユーザは、捜索エリアを移動して、再度、災害エクスプレッションの送信指示を端末２１に与える必要がある。

端末２１は、当該受信報告を受けた場合には（ステップＳ１１８においてＹＥＳ）、端末１１の位置を推定する（ステップＳ１２０）。たとえば、端末２１は、端末２２から応答エクスプレッションの受信報告を受けているとする。この場合、端末２１は、自端末の近傍には端末１１が存在せず、端末２２の近傍に存在していると推定する。端末２１のユーザは、推定結果に基づいて端末２２の方向に向かって移動する。そして、端末２１は、ステップＳ１０の処理を実行する。

図２０は、本実施の形態の第３の変形例において、端末１１において行われる処理の流れを説明するためのフローチャートである。図２０を参照して、ステップＳ３２の処理は、図８の処理と同じであるため、その詳細な説明は繰り返さない。

端末１１は、災害エクスプレッションを受信した場合には（ステップＳ３２においてＹＥＳ）、当該受信した災害エクスプレッションに対する応答エクスプレッションを送信して（ステップＳ３１２）、ステップＳ３２からの処理を繰り返す。すなわち、端末１１は、災害エクスプレッションを受信する度に応答エクスプレッションを送信する。

上述したように、端末１１は、災害エクスプレッションを受信した場合に、そのコードを確認することにより、災害エクスプレッションが緊急用のエクスプレッションであることは把握できる。そのため、端末１１は、Ｄ２Ｄモードに設定されていない場合であっても、緊急用のエクスプレッション（ここでは、災害エクスプレッション）を受信したときには、当該受信したエクスプレッションに対する応答エクスプレッションを送信する。

上記構成によると、捜索端末が送信した災害エクスプレッションに対する応答エクスプレッションが発見待ち端末から送信される。捜索端末は、応答エクスプレッションを受信することにより、発見待ち端末の位置を推定できる。そのため、たとえば、サーバ（あるいは基地局）が停止している場合であっても、捜索端末は発見待ち端末の位置を絞り込むことが可能となる。

（第４の変形例）
本実施の形態の第４の変形例では、あるエリア内に存在する複数の発見待ち（発見される側の）端末を捜索する構成について説明する。

図２１は、本実施の形態の第４の変形例に従う通信システムの全体構成を示す図である。図２１を参照して、端末１１，１２，１３が発見待ち端末であり、端末２１，２２が捜索端末である。端末１１〜１３は、あるエリア内に存在していることは既知であるとする。たとえば、登山中に端末１１〜１３の各ユーザが遭難し、端末２１，２２のユーザは、当該各ユーザが山のどこかに存在することは把握している場面が想定される。なお、端末１２，１３は、端末１１と同じ機能および構成を有する。

端末２１が送信する災害エクスプレッションの到達範囲である範囲２１０内には端末１１，１２が存在し、端末２２が送信する災害エクスプレッションの到達範囲である範囲２２０内には端末１２，１３が存在している。そのため、端末１１は、端末２１が送信した災害エクスプレッションを受信し、当該災害エクスプレッションに応じた問い合わせ情報をサーバ３０に送信する。同様に、端末１２は、端末２１，２２の各々が送信した災害エクスプレッションに応じた問い合わせ情報をサーバ３０に送信する。端末１３は、端末２２が送信した災害エクスプレッションに応じた問い合わせ情報をサーバ３０に送信する。

端末２１，２２は、サーバ３０からのフィードバック情報を受信することにより、端末１１が端末２１の近傍に存在し、端末１２が端末２１および端末２２の近傍に存在し、端末１３が端末２２の近傍に存在すると推定する。これにより、端末２１および端末２２は、範囲２１０と範囲２２０とを含む捜索範囲内に、３つの端末が存在することを把握することができる。

ここで、あるエリア内に端末１１〜１３が存在していることは既知（たとえば、端末１１〜１３が端末２１，２２の紙面上方向に存在していることは既知）であるため、端末２１および端末２２は、推定結果に基づいて移動していく。たとえば、端末１２を捜索する場合、端末２１および端末２２は、端末２１および端末２２の中間地点かつ上方向を目指して移動していく。以降、端末２１，２２は、再度、災害エクスプレッションを送信することによりサーバ３０からのフィードバック情報を受信して、端末１１〜１３の捜索エリアを絞り込んでいく。

このように、発見待ち端末があるエリア内に存在するが既知である場合には、捜索端末の数が少ない場合であっても、発見待ち端末の位置を推定することができる。

＜ハードウェア構成＞
（端末）
図２２は、端末１１のハードウェア構成を表わすブロック図である。図２２を参照して、端末１１は、主たる構成要素として、ＣＰＵ（Central Processing Unit）３５２と、メモリ３５４と、タッチパネル３５６と、ディスプレイ３５８と、無線通信インターフェイス（Ｉ／Ｆ）３６０と、メモリインターフェイス（Ｉ／Ｆ）３６４と、スピーカ３６６と、ＧＰＳ（Global Positioning System）コントローラ３６８と、バッテリ３７０とを含む。なお、端末１２，１３、端末２１〜２５のハードウェア構成は、端末１１のハードウェア構成と同じである。

ＣＰＵ３５２は、メモリ３５４に記憶されたプログラムを読み出して実行することで、端末１１の各部の動作を制御する制御部として機能する。ＣＰＵ３５２は、当該プログラムを実行することによって、上述した端末１１の処理（ステップ）の各々を実現する。

メモリ３５４は、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read-Only Memory）、フラッシュメモリなどによって実現される。メモリ３５４は、ＣＰＵ３５２によって実行されるプログラム、またはＣＰＵ３５２によって用いられるデータなどを記憶する。

タッチパネル３５６は、表示部としての機能を有するディスプレイ３５８上に設けられており、たとえば、静電容量方式タイプである。タッチパネル３５６は、所定時間毎に外部物体によるタッチパネル３５６へのタッチ操作を検知し、タッチ座標をＣＰＵ３５２に入力する。

無線通信インターフェイス３６０は、通信アンテナ３６２に接続されている。通信アンテナ３６２および無線通信インターフェイス３６０は、たとえば、基地局５０を介した通常通信や他の端末とのＤ２Ｄ通信に用いられる。

メモリインターフェイス３６４は、外部の記憶媒体３６５からデータを読み出す。ＣＰＵ３５２は、メモリ３５４からデータを読み出して、メモリインターフェイス３６４を介して当該データを外部の記憶媒体３６５に格納する。なお、記憶媒体３６５としては、ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disk）、ＢＤ（Blu-ray（登録商標） Disc）、ＵＳＢ（Universal Serial Bus）メモリ、ＳＤ（Secure Digital）メモリカードなどの不揮発的にプログラムを格納する媒体が挙げられる。

スピーカ３６６は、ＣＰＵ３５２からの指示に従って音声を出力する。たとえば、スピーカ３６６は、ユーザに推定結果を報知するための音声を出力する。

ＧＰＳコントローラ３６８は、ＧＰＳ信号または基地局からの位置信号（測位信号）を受信して端末１１の位置情報を取得する。ＧＰＳコントローラ３６８は、取得した端末１１の位置情報をＣＰＵ３５２に入力する。

バッテリ３７０は、充放電可能な電力貯蔵要素であり、代表的にはリチウムイオン電池やニッケル水素電池などの二次電池で構成される。

端末１１は、ユーザからの指示を受け付けるためのボタン、端末１１に対する発話を受け付けるマイクを含んでいてもよい。

（基地局）
図２３は、基地局のハードウェア構成を示すブロック図である。図２３を参照して、基地局５０は、主たる構成要素として、各種処理を実行するためのＣＰＵ４０２と、ＣＰＵ４０２によって実行されるプログラム、データなどを格納するためのメモリ４０４と、無線通信網を介してセル５００に在圏する装置と各種データを送受信するための無線通信（Ｉ／Ｆ）４０６および通信アンテナ４０８と、他の装置と有線通信するための有線通信インターフェイス（Ｉ／Ｆ）４１０とを含む。ＣＰＵ４０２は、メモリ４０４に格納されたプログラムを実行することによって、基地局５０の処理の各々を実現する。なお、基地局５１のハードウェア構成は、基地局５０のハードウェア構成と同じである。

（サーバ）
サーバ３０は、上述するような情報処理を全体として提供できればよく、そのハードウェア構成については公知のものを採用することができる。たとえば、サーバ３０は、各種処理を実行するためのＣＰＵと、プログラムやデータなどを格納するためのメモリと、基地局５０，５１と各種データを送受信するための通信インターフェイスと、管理者からの指示を受け付けるための入力インターフェイス（Ｉ／Ｆ）とを含む。

［その他の実施の形態］
上述した実施の形態において、災害エクスプレッションのコードの個数は、１つであってもよいし、複数であってもよい。たとえば、災害エクスプレッションのコードの個数が複数である場合には、複数の端末２１〜２３のそれぞれから送信される複数の災害エクスプレッションのコードが、互いに異なるように構成されていてもよい。

具体例として、端末２１から送信される災害エクスプレッションのコードが「ＡＡＡＡ」、端末２２から送信される災害エクスプレッションのコードが「ＡＡＡＢ」、端末２３から送信される災害エクスプレッションのコードが「ＡＡＡＣ」であるとする。サーバ３０は、端末２１、端末２２および端末２３を、それぞれ災害エクスプレッションのコード「ＡＡＡＡ」、「ＡＡＡＢ」および「ＡＡＡＣ」と予め関連付けて記憶しておく。

これにより、サーバ３０は、たとえば、端末１１から災害エクスプレッションのコード問い合わせを受けた場合に（問い合わせ情報を受信した場合に）、災害エクスプレッションのコードが「ＡＡＡＡ」であれば、当該災害エクスプレッションを送信した端末が端末２１であると特定することができる。すなわち、サーバ３０は、端末１１からの当該問い合わせが、端末２１〜２３のうちどの端末から送信された災害エクスプレッションに対する問い合わせなのかを判断することができる。

上述した実施の形態では、災害エクスプレッションを全方位に向けて送信する構成について説明したが、当該構成に限られない。たとえば、災害エクスプレッションは、ビームフォーミングアンテナなどの指向性アンテナを用いて、特定の方向に向けて送信される構成であってもよい。具体的には、端末２１〜２３は、端末１１が存在する方向を推定する場合に、ビームフォーミング技術を用いて、災害エクスプレッションを特定の方向に向けて送信する。

たとえば、端末２１は、全方位に向けて災害エクスプレッションを送信した結果、サーバ３０からのフィードバック情報に基づいて、自端末の近傍に端末１１が存在することまでは推定できたものとする。この場合、端末２１は、端末１１が存在する方向を特定するために、指向性を有する災害エクスプレッションを東、西、南、北の順に送信する。そして、端末２１は、たとえば、南方向に災害エクスプレッションを送信したときに、サーバ３０からフィードバック情報（自端末が送信した災害エクスプレッションを端末１１が受信したことを示すフィードバック）を受信したとする。この場合、端末２１は、端末１１が南方向に存在すると推定することができる。

このように、端末２１〜２３の各々は、端末１１が存在する方向を特定できるため、捜索側の端末が少ない（たとえば、１台または２台）場合であっても、端末１１の捜索エリアを絞り込むことができる。

上述した実施の形態では、サーバ３０は、端末１１から受信した問い合わせ情報に応じたフィードバック情報を端末２１〜２３すべてに送信する構成について説明したが、当該構成に限られない。たとえば、サーバ３０は、端末２１が送信した災害エクスプレッションに応じた問い合わせ情報を端末１１から受信したとする。この場合、サーバ３０は、当該問い合わせ情報を端末１１から受信した旨を、フィードバック情報として端末２１にのみ通知してもよい。

上述した実施の形態において、発見待ち端末の捜索センターとして機能する外部装置を設けてもよい。たとえば、複数の捜索端末は、一旦、サーバ３０から受けたフィードバック情報を外部装置に送信する。外部装置は、各捜索端末から受信したフィードバック情報に基づいて、発見待ちの位置を推定する（たとえば、端末１１が端末２１および端末２２の近傍に存在し、端末２３の近傍には存在しないことを推定する）。そして、外部装置は、その推定結果を各捜索端末に送信する。これにより、複数の捜索端末は、発見待ち端末の捜索をスムーズに行なうことができる。

上述した実施の形態において、端末１１は、複数の災害エクスプレッションを受信した場合、当該複数の災害エクスプレッションに応じた複数の問い合わせ情報をまとめて送信してもよいし、時差を設けて１つずつ送信してもよい。

上述した実施の形態において、コンピュータを機能させて、上述のフローチャートで説明したような制御を実行させるプログラムを提供することもできる。このようなプログラムは、コンピュータに付属するフレキシブルディスク、ＣＤ−ＲＯＭ（Compact Disk Read Only Memory）、ＲＯＭ、ＲＡＭおよびメモリカードなどの一時的でないコンピュータ読取り可能な記録媒体にて記録させて、プログラム製品として提供することもできる。あるいは、コンピュータに内蔵するハードディスクなどの記録媒体にて記録させて、プログラムを提供することもできる。また、ネットワークを介したダウンロードによって、プログラムを提供することもできる。

プログラムは、コンピュータのオペレーティングシステム（ＯＳ）の一部として提供されるプログラムモジュールのうち、必要なモジュールを所定の配列で所定のタイミングで呼出して処理を実行させるものであってもよい。その場合、プログラム自体には上記モジュールが含まれずＯＳと協働して処理が実行される。このようなモジュールを含まないプログラムも、本実施の形態にかかるプログラムに含まれ得る。

また、本実施の形態にかかるプログラムは他のプログラムの一部に組込まれて提供されるものであってもよい。その場合にも、プログラム自体には上記他のプログラムに含まれるモジュールが含まれず、他のプログラムと協働して処理が実行される。このような他のプログラムに組込まれたプログラムも、本実施の形態にかかるプログラムに含まれ得る。

上述の実施の形態として例示した構成は、本発明の構成の一例であり、別の公知の技術と組み合わせることも可能であるし、本発明の要旨を逸脱しない範囲で、一部を省略する等、変更して構成することも可能である。

また、上述した実施の形態において、他の実施の形態や変形例で説明した処理や構成を適宜組み合わせて実施する場合であってもよい。

今回開示された実施の形態はすべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は、上記した説明ではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。

１１〜１３，２１〜２５ 端末、３０ サーバ、５０，５１ 基地局、１５１ アプリ実行部、１５２ Ｄ２Ｄ通信管理部、１５３ ＧＵＩ部、１５４，２５２ 記憶部、１５５ 受信部、１５６ 送信部、２５１ 主制御部、２５３ 通信制御部、２５４ 無線通信部、２５５ アンテナ、３５２，４０２ ＣＰＵ、３５４，４０４ メモリ、３５６ タッチパネル、３５８ ディスプレイ、３６０ 無線通信インターフェイス、３６２，４０８ 通信アンテナ、３６４ メモリインターフェイス、３６５ 記憶媒体、３６６ スピーカ、３６８ ＧＰＳコントローラ、３７０ バッテリ、５００，５１０ セル、１５３１ 表示部、１５３２ 入力部、１５５１ ディスカバリ信号受信部、１５６１ ディスカバリ信号送信部。

Claims (5)

1. サーバと、基地局と、端末間通信が可能な複数の通信端末とを備えた通信システムであって、
   前記複数の通信端末の各々は、前記基地局を介さずに自端末の存在を相手端末に通知するためのディスカバリ信号を送信可能であり、
   前記複数の通信端末のうちの第１の通信端末は、緊急事態に関連する緊急情報を前記ディスカバリ信号に含めて送信し、
   前記複数の通信端末のうちの第２の通信端末は、前記第１の通信端末から前記緊急情報を含むディスカバリ信号を受信した場合、当該受信したディスカバリ信号に応じた第１の情報を前記基地局を介してサーバに送信し、
   前記サーバは、前記第２の通信端末から前記第１の情報を受信した場合、当該受信した第１の情報に応じた第１の通知情報を前記第１の通信端末に送信する、通信システム。
2. 前記複数の通信端末のうちの第３の通信端末は、前記緊急情報を前記ディスカバリ信号に含めて送信し、
   前記第２の通信端末は、前記第３の通信端末から前記緊急情報を含むディスカバリ信号を受信した場合、当該受信したディスカバリ信号に応じた第２の情報を前記サーバに送信し、
   前記サーバは、前記第２の通信端末から前記第２の情報を受信した場合、当該受信した第２の情報に応じた第２の通知情報を前記第１の通信端末に送信する、請求項１に記載の通信システム。
3. 前記第１の通信端末は、前記第１の通知情報を受信した場合、前記ディスカバリ信号の到達範囲を、前記第１の通知情報を受信していない場合の前記到達範囲とは異なるように変更する、請求項１または２に記載の通信システム。
4. 前記複数の通信端末の各々は、周囲に存在する通信端末をサーチし、前記サーチによって発見された他の通信端末と前記端末間通信を行ない、
   前記第２の通信端末は、前記基地局と通信可能ではない場合、前記サーチによって発見された第４の通信端末に対して、前記端末間通信により前記第１の情報を送信し、
   前記第４の通信端末は、他の基地局が構成するセルに在圏する場合、前記他の基地局を介して前記第１の情報を前記サーバに送信する、請求項１〜３のいずれか１項に記載の通信システム。
5. 基地局と、端末間通信が可能な複数の通信端末とを備えた通信システムであって、
   前記複数の通信端末の各々は、自端末の存在を前記基地局を介さずに相手端末に通知するためのディスカバリ信号を送信可能であり、
   前記複数の通信端末のうちの第１の通信端末は、緊急事態に関連する緊急情報を前記ディスカバリ信号に含めて送信し、
   前記複数の通信端末のうちの第２の通信端末は、前記第１の通信端末から前記緊急情報を含むディスカバリ信号を受信した場合、当該受信に対する応答情報を前記ディスカバリ信号に含めて送信し、
   前記第１の通信端末は、前記第２の通信端末から、前記応答情報を含むディスカバリ信号を受信する、通信システム。