(57)【特許請求の範囲】
【請求項１】
基地局と、デバイス間通信が可能な第１の端末および第２の端末とを備えた通信システムであって、
前記第１の端末および前記第２の端末の各々は、少なくとも自端末の存在を前記基地局を介さずに相手端末に通知するために用いられるディスカバリ信号を送信可能であり、
前記第１の端末は、人の安否を確認するための第１の情報を前記ディスカバリ信号に含めて送信し、
前記第２の端末は、前記第１の端末から前記第１の情報を含むディスカバリ信号を受信した場合、前記第１の端末に対して、前記安否を通知するための第２の情報を前記ディスカバリ信号に含めて送信し、
前記第１の端末は、前記第２の端末から、前記第２の情報を含んだディスカバリ信号を受信する、通信システム。
【請求項２】
前記第２の端末は、前記基地局と通信可能でないことを条件に、前記第１の端末に対して前記第２の情報を含めたディスカバリ信号を送信する、請求項１に記載の通信システム。
【請求項３】
前記ディスカバリ信号は、前記デバイス間通信に対応した予め定められたアプリケーションによって送信される、請求項１または２に記載の通信システム。
【請求項４】
前記第１の端末は、前記第２の端末から前記第２の情報が含まれたディスカバリ信号を受信したことに基づき、前記基地局を介して、予め定められたサーバ装置に前記第２の情報を通知する、請求項１から３のいずれか１項に記載の通信システム。
【請求項５】
前記第１の端末および前記第２の端末の各々は、
基地局によって割り当てられた無線リソースプールにおいて、１または複数の無線リソースを選択し、前記選択された無線リソースを用いて前記ディスカバリ信号を送信し、
予め定められた関数を利用して、前記ディスカバリ信号同士が前記無線リソースプールにおいて同じ無線リソースに割り当てないように前記ディスカバリ信号の配置を決定する、請求項１から４のいずれか１項に記載の通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、端末と基地局とを備えた通信システムに関する。
【背景技術】
【０００２】
従来、災害が発生した時などに、人の安否を確認可能とするシステムが知られている。たとえば、特許文献１には、このようなシステムとして、安否確認サーバと複数の端末とが接続された安否確認システムが開示されている。詳しくは、上記複数の端末の各々は、他の端末との近距離通信により、端末情報を交換する。上記安否確認サーバは、確認信号を送信した端末のうち、応答信号が受信されない端末について、他の端末に問合せ信号を送信する。さらに、上記問合せ信号に含まれる端末の端末情報を有する端末は、安否確認サーバに対して端末情報を送信する。
【０００３】
また、従来、基地局（ｅＮＢ：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)
【発明の概要】
【発明が解決しようとする課題】
【０００９】
特許文献１の技術では、災害時における安否確認サーバからの問い合わせに対して、複数の端末の各々が、自端末および近距離通信で情報交換した他の端末の安否情報を各々のタイミングで送信する。それゆえ、端末間の近距離通信の通信トラフィックと、端末と安否確認サーバとの間の通信トラフィックとが原因で、安否確認システムにおける通信トラフィックが増大してしまう。
【００１０】
本願発明は、上記の問題点に鑑みなされたものであって、その目的は、災害時における通信トラフィックを低減することが可能な通信システムを提供することにある。
【課題を解決するための手段】
【００１１】
本発明のある局面に従うと、通信システムは、基地局と、デバイス間通信が可能な第１の端末および第２の端末とを備える。第１の端末および第２の端末の各々は、少なくとも自端末の存在を基地局を介さずに相手端末に通知するために用いられるディスカバリ信号を送信可能である。第１の端末は、人の安否を確認するための第１の情報をディスカバリ信号に含めて送信する。第２の端末は、第１の端末から第１の情報を含むディスカバリ信号を受信した場合、第１の端末に対して、安否を通知するための第２の情報をディスカバリ信号に含めて送信する。第１の端末は、第２の端末から、第２の情報を含んだディスカバリ信号を受信する。
【発明の効果】
【００１２】
本発明によれば、災害時における通信トラフィックを低減することが可能となる。
【図面の簡単な説明】
【００１３】
【図１】通信システム１の概略構成を説明するための図である。
【図２】ディスカバリ用のサブフレームの無線リソースプールにおけるディスカバリ信号の送受信例を説明するための図である。
【図３】ＵＥ１１の機能的構成を説明するための機能ブロック図である。
【図４】ｅＮＢ２１の機能的構成を説明するための図である。
【図５】通信システム１で行われる処理の流れを説明するためのシーケンスチャートである。
【図６】ｅＮＢ２１において行われる処理の流れを説明するためのフローチャートである。
【図７】ＵＥ１１において行われる処理の流れを説明するためのフローチャートである。
【図８】ＵＥ１２において行われる処理の流れを説明するためのフローチャートである。
【図９】通信システム１の変形例である通信システム１Ａの概略構成を説明するための図である。
【図１０】通信システム１Ａで行われる処理の流れを説明するためのシーケンスチャートである。
【図１１】通信システム１ＡのＵＥ１１において行われる処理の流れを説明するためのフローチャートである。
【図１２】ディスカバリ信号送信部１５６１（図３参照）の構成を説明するための機能ブロック図である。
【図１３】ＵＥ１１のハードウェア構成を説明するための図である。
【発明を実施するための形態】
【００１４】
以下、図面を参照しつつ、本発明の各実施の形態に係る通信システムについて説明する。また、以下の説明では、同一の部材には同一の参照符号を付してある。それらの名称および機能も同じである。したがって、それらについての詳細な説明は繰り返さない。なお、以下では、アプリケーションプログラムを、略して、「アプリ」と称する。
【００１５】
＜Ａ．システム構成＞
図１は、通信システム１の概略構成を説明するための図である。具体的には、図１は、ある局面における通信状態を表した図である。詳しくは、図１は、災害により１つのｅＮＢ（具体的には後述するｅＮＢ２２）の動作が停止した状態を表した図である。
【００１６】
図１を参照して、通信システム１は、複数のＵＥ（User Equipment）１１〜１４と、複数のｅＮＢ（evolved NodeB）２１，２２と、ＭＭＥ（Mobility Management Entity）３０とを備えている。ｅＮＢ２１，２２とＭＭＥ３０とは、有線により通信可能に接続されている。ＭＭＥ３０は、外部ネットワークＮＷに接続されている。
【００１７】
ＭＭＥ３０は、移動局の位置登録、呼出、および基地局間ハンドオーバなどのモビリティ管理を行なうノードである。ＭＭＥ３０は、図示しないゲートウェイを介してｅＮＢ２１，２２と通信する。
【００１８】
ｅＮＢ２１とｅＮＢ２２とは隣接している。ｅＮＢ２１は、セル２９１を構成する。ｅＮＢ２２は、セル２９２を構成する。ＵＥ１１は、セル２９１に在圏しており、ｅＮＢ２１と通信する。ＵＥ１２〜１４は、セル２９２内に位置しているが、ｅＮＢ２２が停止しているため、ｅＮＢ２２とは通信ができない。
【００１９】
複数のＵＥ１１〜１４の各々は、ｅＮＢを介さずに、近くに存在する他のＵＥと、Ｄ２Ｄ通信（直接通信を行なうデバイス間通信）が可能である。具体的には、各ＵＥ１１〜１４は、Ｄ２Ｄディスカバリ機能を有するＬＴＥ端末（ＬＴＥ規格に準拠した携帯端末）である。典型的には、ＵＥ１１〜１４は、スマートフォンである。
【００２０】
ＵＥ１１〜１４には、Ｄ２Ｄディスカバリサービスを利用するアプリ（以下、「Ｄ２Ｄ対応アプリ」とも称する）が予め複数インストールされている。なお、Ｄ２Ｄ対応アプリとは、上述したように、D2D Proximity Serviceを利用することが可能なアプリである。Ｄ２Ｄ対応アプリの例としては、たとえば、後述する災害情報アプリ＃１の他、ＳＮＳ、ゲーム、広告、コミュニケーションアプリ等の各種のアプリが挙げられる。
【００２１】
ＵＥ１１〜１４には、D2D Proximity Servicesを実行可能な端末の識別子として“ProSe UE ID”が割り振られている。また、通信システム１においては、各ｅＮＢ２１，２２は、動作が停止してないことを条件に、Ｄ２Ｄ通信の認証、無線リソースプールの割り当て、タイミングのリファレンス信号の生成等を制御する。また、ｅＮＢの代わりにＵＥに上記制御を行なわせることも可能である。
【００２２】
ＵＥ１１は、ｅＮＢ２１からの無線リソースプールの情報に基づき、Ｄ２Ｄのディスカバリ信号を送信するための無線リソースを任意に選択する。また、ＵＥ１１とＵＥ１２〜１４とは、ｅＮＢ２１，２２を介さずに（つまり、ｅＮＢによって無線リソースの割当を受けずに）、互いに、ディスカバリ信号の送受信を行なう。なお、ｅＮＢ２２が停止していないときには、ＵＥ１２〜１４は、ｅＮＢ２２からの無線リソースプールの情報に基づき、Ｄ２Ｄのディスカバリ信号を送信するための無線リソースを任意に選択する。
【００２３】
ＵＥ１１〜１４の各々は、任意に選択したディスカバリ信号送信用の無線リソースを用いて、ＵＥ自身の存在を周りのＵＥに通知するためのディスカバリ信号を送信する。詳細については後述するが、ディスカバリ信号には、少なくとも、アプリを識別するためのProSe Application ID、およびＵＥを識別するProSe UE IDが含まれている。
【００２４】
説明を補足すると以下のとおりである。Ｄ２Ｄ通信においては、現状、アプリベースで通信およびＵＥを発見する想定で検討がなされている。詳しくは、アプリ毎にＩＤが振られ、ＵＥが当該ＩＤを含むディスカバリ信号を発信することにより、相手のＵＥに検出してもらう仕組みになっている。
【００２５】
以下では、ｅＮＢ２１，２２を区別しない場合には、単に、「ｅＮＢ２０」と記載する。また、ＵＥ１１〜１４を区別しない場合には、単に、「ＵＥ１０」と称する。
【００２６】
＜Ｂ．処理の概要＞
以下、通信システム１における処理の概要を説明する。
【００２７】
ＵＥ１１は、人の安否を確認するための情報をディスカバリ信号に含めて送信する。ＵＥ１２〜１４の各々は、ＵＥ１１から、人の安否を確認するための情報を含むディスカバリ信号を受信した場合、ＵＥ１１に対して、安否を通知するための情報をディスカバリ信号に含めて送信する。ＵＥ１１は、ＵＥ１２〜１４の各々から、安否を通知するための情報（以下、「安否情報」とも称する）を含んだディスカバリ信号を受信する。
【００２８】
以上の処理により、ＵＥ１１は、ＵＥ１２〜１４の各々から安否情報を得ることができる。また、ディスカバリ信号はマルチキャストされる。ＵＥ１１〜１４の各々は、当該ディスカバリ信号を受信することになる。それゆえ、災害発生時に端末同士が個別に通信する従来の構成に比べて、通信トラフィックの増加を抑制できる。さらに、通信トラフィックの増加が抑制されるため、輻輳の発生を抑制できる。
【００２９】
また、ディスカバリ信号は、データ量が少ないため、ディスカバリ信号の受信側のＵＥのデータ処理の負荷が少ない。それゆえ、受信側のＵＥの消費電力を低減できる。
【００３０】
＜Ｃ．用語＞
以下では、本実施の形態で用いる用語について説明する。
【００３１】
（１）「災害情報アプリ」とは、典型的には、（i）災害情報アプリを搭載したＵＥのユーザ自身の安否情報を送信する、（ii）周囲のユーザの状況を収集して一覧で安否状況を表示する、（iii）掲示板サーバに収集した情報をあげるといった機能を持ったアプリである。災害情報アプリは、たとえば、自身の安否情報を設定（たとえば、選択または記述）する設定ボタン（無事、要救助等）、安否情報を送信するための送信ボタン、周囲の安否情報を表示する画面等を備えている。
【００３２】
（２）人の安否を確認するための情報を含むディスカバリ信号を、「災害情報エクスプレッション」とも称する。なお、「エクスプレッション」とは、ディスカバリ信号上で送信されるコードを意味する。
【００３３】
「人の安否を確認するための情報」とは、詳しくは、災害情報アプリを使用するユーザ自身が、周囲の当該災害情報アプリのユーザの安否確認をするための情報である。当該情報には、周囲の人を具体的に特定するための人名等の情報を含んでいてもよい。
【００３４】
災害情報エクスプレッションは、典型的には、「Prose UE ID」と、「Prose Application ID」と、周囲の人の安否を確認するための情報と、安全な場所を表した情報等の周辺の有用な情報とを含む。
【００３５】
（３）安否を通知するための情報を含むディスカバリ信号を、「安否情報エクスプレッション」と称する。「安否を通知するための情報」とは、詳しくは、災害情報アプリのユーザの自身の状況（たとえば、安全である、けがをしている、助けが必要など）を表した情報である。安否情報エクスプレッションは、典型的には、「Prose UE ID」と、「Prose Application ID」と、安否を通知するための情報とを含む。
【００３６】
＜Ｄ．ディスカバリ信号の送受信例＞
図２は、ディスカバリ用のサブフレームの無線リソースプールにおけるディスカバリ信号の送受信例を説明するための図である。図２を参照して、所定の周波数帯域において、ｅＮＢ２１およびｅＮＢ２２によってディスカバリ用のサブフレームとして無線リソースプールＰ１，Ｐ２，Ｐ３，…が割り当てられている。
【００３７】
また、このディスカバリ用のサブフレームは、時間と周波数とで分割した複数の無線リソースの集合である無線リソースプールとして、ｅＮＢから割り当てられている。各ＵＥはこの無線リソースプールから、１つないし複数の無線リソースを任意に選択し、その無線リソースを用いてディスカバリ信号を送信する。なお、以下では、無線リソースプールＰ１，Ｐ２，Ｐ３等のディスカバリ信号の送受信用に割り当てられたＬＴＥサブフレームを、「ディスカバリ用のサブフレーム」と称する。
【００３８】
特に、図２においては、１つの無線リソースで１つのアプリのディスカバリ信号が送信されるような形式を例示している。１つのディスカバリ用サブフレームにおいて、複数のユーザが複数のアプリのディスカバリ信号を送信する。たとえば、図２では、無線リソースプールＰ１において、ＵＥ１１のユーザが災害情報アプリ＃１のディスカバリ信号（この場合、災害情報エクスプレッション）を送信している。また、無線リソースプールＰ２において、ＵＥ１２〜１４の各ユーザが災害情報アプリ＃１のディスカバリ信号（この場合、安否情報エクスプレッション）を送信している。
【００３９】
また、無線リソースプールＰ１，Ｐ２では、アプリ＃１、＃２、＃３の３種類のアプリのディスカバリ信号が送信されている。なお、規格によっては１つの無線リソースで複数のアプリのディスカバリ信号を送信することもある。あるいは、複数の無線リソースで１つのアプリのディスカバリ信号を送信する場合もある。
【００４０】
ディスカバリ用のサブフレームについて詳しく説明すると、以下のとおりである。Ｄ２Ｄ通信は、ＴＤＤ（Time Division Duplex）方式のＬＴＥと、ＦＤＤ（Frequency Division Duplex）方式のＬＴＥに適用できる。
【００４１】
ＦＤＤ方式のＬＴＥの場合には、アップリンク用のチャネルの一部のＬＴＥサブフレームをディスカバリ用に割り当てる。ＵＥ１０は、当該ディスカバリ用に割り当てられたＬＴＥサブフレーム（つまり、ディスカバリ用のサブフレーム）を用いて、ディスカバリ信号の送受信を行なう。なお、ディスカバリ用のサブフレームの周期は、たとえば、１０〜２０秒などとすることができる。
【００４２】
ＴＤＤ方式のＬＴＥの場合には、アップリンク用のサブフレーム、ダウンリンク用のサブフレーム、およびＤ２Ｄ用のサブフレームが、同じ周波数において、タイムフレームで切り替えることになる。たとえば、アップリンク用のサブフレーム、ダウンリン用のサブフレーム、ディスカバリ用のサブフレーム、アップリンク用のサブフレーム、…といった順で、サブフレームの用途が切り替えられる。
【００４３】
なお、ディスカバリ用のサブフレームは、送信用と受信用との区別はない。１つのディスカバリ用のサブフレームで、ディスカバリ信号の送受信が行われる。
【００４４】
＜Ｅ．機能的構成＞
（ｅ１．ＵＥ）
図３は、ＵＥ１１の機能的構成を説明するための機能ブロック図である。図３を参照して、ＵＥ１１は、アプリ実行部１５１と、Ｄ２Ｄ管理部１５２と、ＧＵＩ（Graphical User Interface）部１５３と、記憶部１５４と、受信部１５５と、送信部１５６とを備えている。ＧＵＩ部１５３は、表示部１５３１と入力部１５３２とを有する。受信部１５５は、Ｄ２Ｄディスカバリ信号受信部１５５１を有する。送信部１５６は、ディスカバリ信号送信部１５６１を有する。
【００４５】
アプリ実行部１５１は、記憶部１５４に予め記憶されているＤ２Ｄ対応の災害情報アプリ＃１，アプリ＃２，アプリ＃３，…を記憶部１５４から読出し、各々のアプリを実行する。なお、以下では、Ｄ２Ｄ通信を行なうための設定（ユーザＩＤやProSe Application ID等の設定）がされている構成を例に挙げて説明する。実行中の各アプリ＃１，＃２，＃３，…は、ディスカバリ信号の送受信が必要となった場合、ディスカバリ信号の送受信要求をＤ２Ｄ管理部１５２に送る。
【００４６】
Ｄ２Ｄ管理部１５２は、Ｄ２Ｄ通信に関する各種の処理を管理する。詳しくは、Ｄ２Ｄ管理部１５２は、各アプリ＃１，＃２，＃３，…から送信された、ディスカバリ信号の送受信要求を受信すると、ディスカバリ信号の送受信を管理（制御）する。
【００４７】
ＧＵＩ部１５３の表示部１５３１は、各種の情報を表示する。入力部１５３２は、ユーザから各種の入力を受け付ける。
【００４８】
受信部１５５は、ｅＮＢ（図１の場合にはｅＮＢ２１）から送信されるデータ、および他のＵＥ（図１の場合にはＵＥ１２〜１４）から送られてくる各種のデータ（ユーザデータ等）を受信する。特に、受信部１５５のディスカバリ信号受信部１５５１は、他のＵＥから送信されてくるディスカバリ信号（たとえば、安否情報エクスプレッション）等を受信する。
【００４９】
送信部１５６は、ｅＮＢ（図１の場合にはｅＮＢ２１）に対して、あるいはＤ２Ｄ通信の場合には他のＵＥに対して、データ（ユーザデータ等）を送信する。特に、ディスカバリ信号送信部１５６１は、ディスカバリ信号（たとえば、災害情報エクスプレッション）を送信する。詳しくは、各アプリに対応するディスカバリ信号は、各アプリが起動し、実行されていることを条件に、マルチキャスト送信される。
【００５０】
なお、ＵＥ１２〜１４も、ＵＥ１１と同様の機能的構成を有するため、ＵＥ１２〜１４の機能的構成については繰り返し説明しない。
【００５１】
（ｅ２．ｅＮＢ）
図４は、ｅＮＢ２１の機能的構成を説明するための図である。図４を参照して、ｅＮＢ２１は、主制御部２５１と、記憶部２５２と、通信制御部２５３と、無線通信部２５４と、アンテナ２５５とを備える。
【００５２】
主制御部２５１は、ｅＮＢ２１の全体の動作を制御する。主制御部２５１は、ＣＰＵに対応する。より詳しくは、ＣＰＵがＯＳ（Operating System）および各種のプログラムを実行することにより、主制御部２５１が実現される。
【００５３】
記憶部２５２は、ＯＳ、各種のプログラム、ｅＮＢ２０から受信（取得）した各種のデータを記憶する。記憶部２５２は、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）、ＨＤＤ（Hard Disk Drive）等で構成される。
【００５４】
通信制御部２５３は、ｅＮＢ２１が構成するセル２９１に在圏するＵＥとの間の通信と、ＭＭＥ３０との通信とを制御する。無線通信部２５４は、アンテナ２５５からデータを送信するため各種の処理、アンテナ２５５で受信した信号を受信するための各種の処理を行なう。無線通信部２５４は、典型的には、ベースバンド変換等を行なう。
【００５５】
なお、ｅＮＢ２２も、ｅＮＢ２１と同様の機能的構成を有するため、ｅＮＢ２２の機能的構成については繰り返し説明しない。
【００５６】
＜Ｆ．制御構造＞
（ｆ１．通信システム１）
図５は、通信システム１で行われる処理の流れを説明するためのシーケンスチャートである。図５を参照して、シーケンスＳＱ２において、ＵＥ１１は、ＵＥ１１の現在地を表す位置情報を、在圏しているセル２９１を構成するｅＮＢ２１に送信する。シーケンスＳＱ４において、ＵＥ１２〜１４は、セル２９２を構成するｅＮＢ２２に対して、各々の現在地を表す位置情報を送信する。
【００５７】
シーケンスＳＱ６において、ｅＮＢ２１は、ＵＥ１１に対して、ｅＮＢ２１を介した通常の通信およびｅＮＢ２１を介さないＤ２Ｄ通信の各々の通信ための無線リソース制御を行なう。無線リソース制御は、認証、リソースプールの割当、同期処理等を含む。シーケンスＳＱ８において、ｅＮＢ２２は、ＵＥ１２〜１４の各々に対して、ｅＮＢ２２を介した通常の通信およびｅＮＢ２２を介さないＤ２Ｄ通信の各々の通信ための無線リソース制御を行なう。
【００５８】
これらの処理の後に、災害が発生し、シーケンスＳＱ１０において、ｅＮＢ２２が動作を停止（機能を停止）したとする。
【００５９】
ＵＥ１１のユーザは、災害情報アプリ＃１を起動する。ＵＥ１１のユーザは、人の安否を確認するための情報等を、災害情報アプリ＃１のＵＩを用いて作成する（記入、選択等を行なう）。シーケンスＳＱ１２において、ＵＥ１１は、人の安否を確認するための情報の作成が完了したことに基づき、典型的にはユーザによる送信指示で、災害情報エクスプレッションをマルチキャストで送信する。
【００６０】
ＵＥ１２〜１４の各々は、災害情報エクスプレッションを受信する。ＵＥ１２〜１４の各々は、災害情報アプリ＃１を起動していることを条件に、災害情報エクスプレッションに含まれている“人の安否を確認するための情報”の内容を表示する。ＵＥ１２〜１４の各ユーザは、災害情報アプリ＃１を用いて、安否を通知するための情報を用いて作成する（記入、選択等を行なう）。シーケンスＳＱ１４において、各ＵＥ１２〜１４は、人の安否を確認するための情報の作成が完了したことに基づき、典型的にはユーザによる送信指示で、安否情報エクスプレッションをマルチキャストで送信する。
【００６１】
（ｆ２．ｅＮＢ２１，２２）
図６は、ｅＮＢ２１において行われる処理の流れを説明するためのフローチャートである。また、図６は、動作が停止する前のｅＮＢ２２において行われる処理の流れを説明するためのフローチャートでもある。
【００６２】
図６を参照して、ステップＳ２において、ｅＮＢ２１は、ｅＮＢ２１が構成するセル２９１に在圏するＵＥ（具体的にはＵＥ１１）の位置情報を取得する。ステップＳ４において、ｅＮＢ２１は、セル２９１に在圏するＵＥがＤ２Ｄ通信可能となるように、無線リソース制御を行なう。なお、ｅＮＢ２１は、上述したように、ｅＮＢ２１を介した通常の通信に関する無線リソース制御も行なう。
【００６３】
（ｆ３．ＵＥ１１）
図７は、ＵＥ１１において行われる処理の流れを説明するためのフローチャートである。図７を参照して、ステップＳ１２において、ＵＥ１１は、たとえばセル２９１内に入った場合あるいは電源が投入された場合、通常の通信のモードでｅＮＢ２１と通信を開始する。ステップＳ１４において、ＵＥ１１は、ｅＮＢ２１から、Ｄ２Ｄ通信のための制御信号（詳しくは、上記無線リソース制御のための信号）を受信する。この後、災害が発生したとする。
【００６４】
ステップＳ１６において、ＵＥ１１は、災害情報アプリ＃１が起動しているか否かを判断する。なお、上述したように、災害情報アプリ＃１の起動は、ユーザ操作により行われる。起動していると判断された場合（ステップＳ１６においてＹＥＳ）、ステップＳ１８において、ＵＥ１１は、ｅＮＢ２１との通信が可能か判断する。起動していないと判断された場合（ステップＳ１６においてＮＯ）、ＵＥ１１は、処理をステップＳ１６に進める。
【００６５】
通信が可能と判断された場合（ステップＳ１８においてＹＥＳ）、ステップＳ２０において、ＵＥ１１は、人の安否確認のための情報の入力を受け付ける。ｅＮＢ２１についても動作が停止する等して、通信が不能と判断された場合（ステップＳ１８においてＮＯ）、ＵＥ１１は、処理をステップＳ１６に進める。
【００６６】
ステップＳ２２において、ＵＥ１１は、入力された安否確認のための情報を含む災害情報エクスプレッションを送信する。ステップＳ２４において、ＵＥ１１は、ＵＥ１２〜１４の各々が送信した安否情報エクスプレッションを受信する。
【００６７】
（ｆ４．ＵＥ１２〜１４）
図８は、ＵＥ１２において行われる処理の流れを説明するためのフローチャートである。また、図８は、ＵＥ１３，１４において行われる処理の流れを説明するためのフローチャートでもある。
【００６８】
図８を参照して、ステップＳ１０２において、ＵＥ１２は、たとえばセル２９２内に入った場合あるいは電源が投入された場合、通常の通信のモードでｅＮＢ２２と通信を開始する。ステップＳ１０４において、ＵＥ１２は、ｅＮＢ２２から、Ｄ２Ｄ通信のための制御信号（詳しくは、上記無線リソース制御のための信号）を受信する。この後、災害が発生したとする。
【００６９】
ステップＳ１０６において、ＵＥ１２は、災害情報アプリ＃１が起動しているか否かを判断する。起動していると判断された場合（ステップＳ１０６においてＹＥＳ）、ステップＳ１０８において、ＵＥ１２は、ｅＮＢ２２との通信が可能か判断する。起動していないと判断された場合（ステップＳ１０６においてＮＯ）、ＵＥ１２は、処理をステップＳ１０６に進める。
【００７０】
仮にｅＮＢ２２の動作が停止しており、通信が不能と判断された場合（ステップＳ１０８においてＮＯ）、ステップＳ１１０において、ＵＥ１２は、ＵＥ１１がマルチキャストした災害情報エクスプレッションを受信する。ステップＳ１１２において、ＵＥ１２は、受信した災害情報エクスプレッションをデコードする。
【００７１】
ステップＳ１１４において、ＵＥ１２は、人の安否確認のための情報の入力を受け付ける。ステップＳ１１６において、ＵＥ１２は、入力された安否情報を含む安否情報エクスプレッションを送信する。
【００７２】
ｅＮＢ２２の動作が停止しておらず、通信が可能と判断された場合（ステップＳ１０８においてＹＥＳ）、ステップＳ１１８において、ＵＥ１２は、ＵＥ１１がマルチキャストした災害情報エクスプレッションを受信する。この場合には、ＵＥ１２は、受信した災害情報エクスプレッションをデコードすることなく、一連の処理を終了する。
【００７３】
以上のように、ＵＥ１２は、ｅＮＢ２２と通信可能でないことを条件に、ＵＥ１１に対して安否情報エクスプレッション（安否情報を含めたディスカバリ信号）を送信する。
【００７４】
＜Ｇ．変形例＞
次に、通信システム１の変形例について説明する。
【００７５】
（第１の変形例）
図９は、通信システム１の変形例である通信システム１Ａの概略構成を説明するための図である。具体的には、図９は、災害によりｅＮＢ２２の動作が停止した状態を表した図である。
【００７６】
図９を参照して、通信システム１Ａは、複数のＵＥ１１〜１４と、複数のｅＮＢ２１，２２と、ＭＭＥ３０と、サーバ４０とを備えている。サーバ４０を備えている点において、通信システム１Ａは通信システム１とは異なる。
【００７７】
サーバ４０は、有線により、外部ネットワークＮＷを介してＭＭＥ３０と接続されている。サーバ４０は、安否情報を掲示する掲示板サーバとして機能している。
【００７８】
詳細については後述するが、通信システム１では、ＵＥ（図９の場合、ＵＥ１１）が受信した安否情報エクスプレッションに含まれる安否情報が、動作しているｅＮＢ（図９の場合、ｅＮＢ２１）を介して、サーバ４０に送信される。ＵＥ１１は、各ＵＥ１２〜１４から受信した各安否情報を、ｅＮＢ２１に対して、ユーザデータとして送信する。
【００７９】
図１０は、通信システム１Ａで行われる処理の流れを説明するためのシーケンスチャートである。図１０を参照して、シーケンスＳＱ２〜ＳＱ１４までは、図５と同様である。このため、シーケンスＳＱ２〜ＳＱ１４までの処理についての説明は繰り返さない。
【００８０】
シーケンスＳＱ１４の後のシーケンスＳＱ１６において、ＵＥ１１は、各ＵＥ１２〜１４から受信した安否情報をｅＮＢ２１に送信する。シーケンスＳＱ１８、ＳＱ２０において、ｅＮＢ２１は、受信した安否情報を、ＭＭＥ３０を介して、サーバ４０に送信する。
【００８１】
それゆえ、サーバ４０には、複数の安否情報が蓄積される。したがって、サーバ４０にアクセス可能なＵＥ等のユーザは、蓄積された安否情報に基づき他人の安否を確認できるようになる。
【００８２】
図１１は、通信システム１ＡのＵＥ１１において行われる処理の流れを説明するためのフローチャートである。図１１を参照して、ステップＳ１２〜Ｓ２４までは、図７と同様である。このため、ステップＳ１２〜Ｓ２４までの処理についての説明は繰り返さない。
【００８３】
ＵＥ１１は、ステップＳ２４の後のステップＳ２６において、ＵＥ１１は、各ＵＥ１２〜１４から送られてきた安否情報エクスプレッションから安否情報を抽出し、当該抽出された安否情報をｅＮＢ２１に送信する。この際、安否情報そのものに個人を特定する情報が含まれていない場合には、ＵＥ１１は、安否情報エクスプレッションに含まれるProSe UE IDを安否情報に関連付けた状態で、安否情報をｅＮＢ２１に送信する。
【００８４】
以上のように、ＵＥ１１は、ＵＥ１２から安否情報エクスプレッション（安否情報が含まれたディスカバリ信号）を受信したことに基づき、ｅＮＢ２１を介して、サーバ４０に安否情報を通知する。
【００８５】
（第２の変形例）
次に、各アプリ＃１，＃２，＃３の信号（図２参照）同士の衝突を低減する構成について説明する。図１２は、ディスカバリ信号送信部１５６１（図３参照）の構成を説明するための機能ブロック図である。
【００８６】
図１２を参照して、ディスカバリ信号送信部１５６１は、無線リソース割当部１５９１と、データ生成部１５９２とを備える。データ生成部１５９２は、アプリケーションデータに基づき、ディスカバリ信号の他にＤ２Ｄ通信で送信するデータを生成する。
【００８７】
ところで、３ＧＰＰの仕様上、無線リソースプール上でのディスカバリ信号（災害情報エクスプレッション、安否情報エクスプレッションを含む）の配置はランダムなため衝突が生じる可能性がある。そこで、無線リソース割当部１５９１が、一例としてハッシュ関数を利用して、IMEI（International Mobile Equipment Identifier）、IMSI（International Mobile Subscriber Identity）、ProSe UE ID等のＩＤ情報から無線リソースプール上でのディスカバリ信号の配置を決定する。
【００８８】
詳しくは、ＵＥ１１の無線リソース割当部１５９１は、ｅＮＢ２１によって割り当てられた無線リソースプールにおいて、１または複数の無線リソースを選択する。また、ディスカバリ信号送信部１５６１は、選択された無線リソースを用いて、災害情報エクスプレッションおよび安否確認エクスプレッション等のディスカバリ信号を送信する。無線リソース割当部１５９１は、ハッシュ関数等の予め定められた関数を利用して、ディスカバリ信号同士が無線リソースプールにおいて同じ無線リソースに割り当てないようにディスカバリ信号の配置を決定する。
【００８９】
上記の構成によれば、ディスカバリ信号の衝突を低減することができる。したがって、各ＵＥ１２〜１３の安否情報をできる限り少ない回数の受信でＵＥ１１が収集可能になる。また、再送を減らすことにもつながり、結果として輻輳を減らすことができる。さらに、処理が少なくなるため、消費電力を抑制することができる。
【００９０】
（第３の変形例）
上記では、たとえば図１に示したとおり、ＵＥ１２〜１４が在圏していたｅＮＢ２２が災害によって動作を停止したことが原因で、ＵＥ１２〜１４がｅＮＢ２１と通信ができなくなった場合を例に挙げたが、これに限定されるものではない。
【００９１】
上述した各種の処理は、たとえば、ＵＥ１２〜Ｕ１４が、災害発生時または直前に、ｅＮＢ２１が構成するセル２９１に在圏しており、災害発生後に、通信システム１内の任意の基地局と通信不能となった場合にも適用できる。
【００９２】
＜Ｈ．ハードウェア構成＞
図１３は、ＵＥ１１のハードウェア構成を説明するための図である。図１３を参照して、ＵＥ１１は、アプリ＃１，＃２，＃３…等を含む各種プログラムを実行するＣＰＵ１０１と、ＲＯＭ（Read Only Memory）１０２と、ＲＡＭ（Random Access Memory）１０３と、フラッシュメモリ１０４と、操作キー１０５と、スピーカ１０６と、カメラ１０７と、タッチスクリーン１０８と、無線通信ＩＦ（Interface）１０９と、アンテナ１１０と、リーダライタ１１１とを、少なくとも含んで構成されている。タッチスクリーン１０８は、ディスプレイ１０８１と、タッチパネル１０８２とを含む。各構成要素１０１〜１０９，１１１は、相互にデータバスによって接続されている。
【００９３】
リーダライタ１１１は、メモリカード９００が装着可能であって、メモリカード９００に情報を記録あるいはメモリカード９００から情報を読み出す。
【００９４】
アンテナ１１０は、無線通信ＩＦ１０９に接続されている。アンテナ１１０および無線通信ＩＦ１０９は、たとえば、ｅＮＢを介した、他のＵＥ、固定電話、およびＰＣ（Personal Computer）との間における無線通信に用いられる。
【００９５】
ＲＯＭ１０２は、不揮発性の半導体メモリである。ＲＯＭ１０２は、ＵＥ１１のブートプログラムが予め格納されている。フラッシュメモリ１０４は、不揮発性の半導体メモリである。フラッシュメモリ１０４は、一例としてＮＡＮＤ型で構成してもよい。フラッシュメモリ１０４は、ＵＥ１１のオペレーティングシステム、ＵＥ１１を制御するための各種のプログラム、並びに、ＵＥ１１が生成したデータ、ＵＥ１１の外部装置から取得したデータ等の各種データを揮発的に格納する。
【００９６】
ＵＥ１１における処理は、各ハードウェアおよびＣＰＵ１０１により実行されるソフトウェアによって実現される。このようなソフトウェアは、フラッシュメモリ１０４に予め記憶されている場合がある。また、ソフトウェアは、メモリカード９００その他の記憶媒体に格納されて、プログラムプロダクトとして流通している場合もある。あるいは、ソフトウェアは、いわゆるインターネットに接続されている情報提供事業者によってダウンロード可能なプログラムプロダクトとして提供される場合もある。このようなソフトウェアは、アンテナ１１０および無線通信ＩＦ１０９を介してダウンロードされた後、フラッシュメモリ１０４に一旦格納される。そのソフトウェアは、ＣＰＵ１０１によってフラッシュメモリ１０４から読み出され、さらにフラッシュメモリ１０４に実行可能なプログラムの形式で格納される。ＣＰＵ１０１は、そのプログラムを実行する。
【００９７】
本発明の本質的な部分は、フラッシュメモリ１０４その他の記憶媒体に格納されたソフトウェア、あるいはネットワークを介してダウンロード可能なソフトウェアであるともいえる。なお、記録媒体としては、ＤＶＤ-ＲＯＭ、ＣＤ−ＲＯＭ、ＦＤ、ハードディスクに限られず、磁気テープ、カセットテープ、光ディスク、光カード、マスクＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュＲＯＭなどの半導体メモリ等の固定的にプログラムを担持する媒体でもよい。また、記録媒体は、当該プログラム等をコンピュータが読取可能な一時的でない媒体である。また、ここでいうプログラムとは、ＣＰＵにより直接実行可能なプログラムだけでなく、ソースプログラム形式のプログラム、圧縮処理されたプログラム、暗号化されたプログラム等を含む。
【００９８】
なお、ＵＥ１２，１３，１４のハードウェア構成は、ＵＥ１１と同じであるため、ここでは繰り返し説明はしない。
【００９９】
今回開示された実施の形態は例示であって、上記内容のみに制限されるものではない。本発明の範囲は特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。
【符号の説明】
【０１００】
１，１Ａ  通信システム、４０  サーバ、１５１  アプリ実行部、１５２  Ｄ２Ｄ管理部、１５４，２５２  記憶部、１５５  受信部、１５６  送信部、２５１  主制御部、２５３  通信制御部、２５４  無線通信部、２９１，２９２  セル、１５５１  ディスカバリ信号受信部、１５６１  ディスカバリ信号送信部、１５９１  無線リソース割当部、１５９２  データ生成部、１０９  無線通信ＩＦ、ＮＷ  外部ネットワーク、Ｐ１，Ｐ２，Ｐ３  無線リソースプール。
【図１】
0006385298.tif 000002
【図２】
0006385298.tif 000003
【図３】
0006385298.tif 000004
【図４】
0006385298.tif 000005
【図５】
0006385298.tif 000006
【図６】
0006385298.tif 000007
【図７】
0006385298.tif 000008
【図８】
0006385298.tif 000009
【図９】
0006385298.tif 000010
【図１０】
0006385298.tif 000011
【図１１】
0006385298.tif 000012
【図１２】
0006385298.tif 000013
【図１３】
0006385298.tif 000014