以下では、本明細書の開示における具体的な側面について、図面を参照しながら詳細に説明する。各図面において、同一または対応する要素には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略される。
<本明細書の開示における第1の側面>
関連する技術においては、端末と制御装置が通信不能となった場合に、端末を捜索するための適切な対策手段を選択することができなかった。第1の側面では、制御装置3が端末の位置を推定し、推定した位置における通信確率を決定し、決定された通信確率に基づいて、適切な対策手段を示す情報を出力する。
図1は、第1の側面における端末1と制御装置3の動作の一例を示すシーケンス図である。ステップ1では、端末1は第1のタイミングにおける端末1に関する位置情報と加速度情報を制御装置3へ送信する。
なおステップ1の前にステップ0として、制御装置3が端末1へ位置情報と加速度情報の送信を要求しても良い。位置情報と加速度情報は、それぞれ別のタイミングで送信されてもよいし、同時に送信されても良い。また位置情報と加速度情報のそれぞれは、所定期間の平均値であってもよいし、所定タイミングの値であっても良い。また加速度情報は、所定期間における最大値であっても良い。
端末1による位置情報および加速度情報の送信は、それぞれ、事前に設定された周期、端末1がネットワークとの接続を確立したこと、端末1の通信品質劣化を検知したこと、端末1の電池残量のしきい値を下回ったこと、端末1の位置情報や加速度情報が急激に変化したこと、などに基づいても良い。
位置情報は、端末1に備えられた位置センサにて収集される。位置センサは、例えば人工衛星を活用した全地球測位システム(Global Positioning System; GPS)による信号を受信して計測される情報を位置情報として収集しても良い。位置センサは、例えば携帯電話通信網の基地局からの信号に基づいて計測される情報を位置情報として収集しても良い。位置センサは、例えばIEEE802.11シリーズの通信規格の電波に基づいて計測される情報を位置情報として収集しても良い。位置センサによって収集された位置情報は、制御装置3へ送信されるまで、メモリに記録されてもよい。
加速度情報は、端末1に備えられた加速度センサにて収集される。加速度センサによって収集された加速度情報は、制御装置3へ送信されるまで、メモリに記録されても良い。
ステップ2では、制御装置3は端末1へ、応答信号を要求する捜索信号を送信する。この捜索信号は、例えば発呼、メール送信、アプリケーションへの通知などであってもよい。なお捜索信号の送信は、端末1の捜索に関する依頼が制御装置3へ入力されたこと、所定期間位置情報と加速度情報の少なくともいずれかを受信できないこと、などをトリガーとしても良い。なお制御装置3は、捜索信号を端末1に送信する代わりに、携帯電話通信網に対して、端末1の接続状況を問い合わせても良い。応答信号は、例えば、制御装置3からの発呼に対する応答、制御装置3から受信したメールへの返信、通知されたアプリケーションに対する何らかの動作、などであってもよい。
ステップ3では、制御装置3は、端末1からの応答信号の受信がないと判断する。制御装置3は、所定期間応答信号を受信しないこと、または応答できないことを示す応答信号を受信したこと、に応じて、端末1からの応答信号の受信がないと判断する。
ステップ4では、制御装置3は、記録している第1のタイミングにおける端末1に関する位置情報と加速度情報のいずれか、または両方に基づいて第1のタイミングとは異なる第2のタイミングにおける端末1の位置を推定する。一例として第2のタイミングにおける端末1の位置の推定は、最新(例えば、第1のタイミング)の位置情報を起点とし、最新(例えば、第1のタイミング)の加速度情報に基づいた移動距離および方向を利用することで推定することであっても良い。一例として第2のタイミングにおける端末1の位置の推定は、位置の推定は、最新(例えば、第1のタイミング)の位置情報を起点に、以前の位置情報、経過時間、加速度情報等、に基づいた移動距離および方向を利用することで推定することであってもよい。加速度情報から推定される移動距離や方向は、移動確率などの変動するパラメータを用いることで、領域として推定されてもよい。位置情報から推定される移動距離や方向は、所定期間の位置情報の差分をとり、移動確率などの変動するパラメータを用いることで、領域として推定されてもよい。なお、第1のタイミングが最近の情報である場合に、この第1のタイミングにおける端末1に関する位置情報をそのまま用いて第2のタイミングにおける端末1の位置として推定してもよい。
ステップ5では、位置と当該位置での通信確率を示す情報から、推定した位置における端末1の通信確率を決定する。通信確率を示す情報は、制御装置3が保持していてもよいし、外部ネットワークから随時取得しても良い。通信確率を示す情報は、当該位置における通信実績から算出されてもよいし、当該位置における通信速度であっても良いし、当該位置における受信信号電力対干渉および雑音電力比SINR(Signal to Interference plus Noise power Ratio)であってもよいし、当該位置におけるパケットロス率であってもよい。また通信確率を示す情報は、当該位置に関する基地局の配置情報や基地局セルの周波数情報、干渉局の配置情報などから生成されてもよい。
通信確率は、対応する当該位置における場所に関する属性によって決定されるものであってもよい。例えば、当該位置に基地局セルが設置されていない、もしくは設置されていても電波の届かない山間部や海周辺といった圏外である領域であれば、通信確率を「低」としてもよい。また例えば、当該位置が公園等の街中に点在する基地局セルからの電波の届かない領域である場合の通信確率を、「中」から「低」としてもよい。また例えば、ビル等建物の屋内や建物間の隙間、壁際、地下通路といった領域の場合、電波の届く領域と届かない領域が混在し、端末1が一時的に圏外エリア(不感地帯)に侵入することがあるため、当該位置に対応する通信確率は「中」としてもよい。また例えば、都市部における道路上といった屋外である場合、基地局セルからの電波が基本的に届くとして、当該位置に対応する通信確率を「高」としてもよい。
ステップ6では、制御装置3は端末1の通信確率に基づいて、端末1を捜索するための対策手段を選択する。そして制御装置3は選択した対策手段を示す情報を出力する。なお出力は、一つ以上の対策手段を示す情報をユーザーインターフェース(UI)に表示することであってもよいし、所定の捜査機関へ捜索依頼を送信することであっても良い。
制御装置3は、応答信号を受信できなかったと判定した場合、捜索を容易にするために、端末1に対してLED点滅要求、および、警告音発生要求の少なくともいずれかを所定の間隔で送信してもよい。特に端末の通信確率が「高」または「中」と決定された場合にLED点滅要求、および、警告音発生要求の少なくともいずれかが送信されてもよい。
対策手段は、下記に示すような例に基づいて選択されても良い。図13は、下記の通信確率と対策手段の対応関係の一例を示す図である。
例えば通信確率が「高」と決定された場合、応答信号が受信できないことは、言い換えるとセルラ圏内にいるのに通信できない状況であることが想定できる。かかる状況とは例えば端末1の所持者が何らかのトラブルに巻き込まれたこと、端末1に不具合が生じたことなどである。この場合、D2D通信できる端末2で捜索することは適さないかもしれない。端末1の所持者が事件に巻き込まれている場合は、端末2を所持して捜索する人にも影響があるかもしれない。そのためこの場合において、制御装置3は「所定の捜索を行う団体(例えば、警察機関、消防機関、セキュリティ企業など)へ通報し、端末1の捜索を依頼すること」を対策手段として選択する。
例えば通信確率が「中」と決定された場合、端末1が一時的に圏外エリア(不感地帯)に侵入したことが想定されるため、制御装置3は、「所定期間待機した後に、再度端末1へ捜索信号を送信すること」を対策手段として選択する。引き続き応答信号がない場合、制御装置3は決定した通信確率が適切でないと判断してもよい。この場合制御装置3は、通信確率を「低~中」と仮定して、対応する対策手段を再び選択し、その対策手段を示す情報を出力すればよい。
例えば、通信確率が「低~中」と決定された場合、端末1が圏外エリアに侵入したと想定されるため、「D2D通信できる端末2を利用して捜索すること」を対策手段として選択してもよい。このときの推定した位置に関する属性によって、制御装置3は、対策手段として用いることが可能な端末2の種別を決定しても良い。
例えば、推定した位置が端末2を携帯する人が侵入可能なエリアである場合、端末2の種別は携帯端末であっても良い。また例えば、推定した位置が、山中など人が侵入困難なエリアである、あるいは人がアクセス可能な経路がないと判断される場合、端末2の種別はドローンに備えられた端末2であってもよいし、端末2がドローンの機能を有しても良い。また例えば、推定した位置が海上であれば端末2の種別は船舶であってもよい。また例えば、決定された端末2の種別が携帯端末である場合、制御装置3は適切な所持者を選択しても良い。所持者は、例えば、輸送業者、地域団体、営業員などであってもよい。
また、例えば推定した位置に関する属性として、推定した位置の近傍の圏外エリア(不感地帯)の推定した大きさが用いられてもよい。例えば不感地帯がビル等建物の屋内、地下通路といった領域であると推定される場合、不感地帯が比較的小さいことが想定されるため、制御装置3は、人が携帯している端末2に対し捜索を依頼することを対策手段として選択してもよい。また他の例では、不感地帯が山間部等の領域であると推定される場合、不感地帯が比較的大きいことが想定されるため、制御装置3は、ドローンなど人が離れても操作可能な端末2に対し捜索を依頼することを対策手段として選択してもよい。また他の例では、不感地帯がビル等建物の屋内であると推定される場合、制御装置3は、端末1の捜索のための進入が困難であると推定し、警察など所定の捜査機関へ捜索依頼を送信することを捜索手段として決定してもよい。この場合制御装置3は、端末1の電話番号などの、所定の捜査機関が捜索に使用しうる情報も併せて通知してもよい。
図2は、第1の側面における制御装置3の動作の一例を示すフロー図である。
図2-Aは、端末1の位置情報と加速度情報を収集する制御装置3の動作の一例を示すフロー図である。
ステップ20では、制御装置3は位置情報と加速度情報を制御装置3へ送信するよう要求する信号を端末1へ送信する。なおこのステップ20は省略されても良い。要求は、明示的に位置情報および加速度情報のいずれかを要求することであってもよいし、位置情報と加速度情報の両方を要求することであっても良い。位置情報と加速度情報のそれぞれは、センサが測定したタイミングの情報であってもよいし、センサが測定した所定期間の情報であっても良い。なお加速度情報が所定期間の情報である場合は、平均値を示す情報でもよいし、最大値と最小値を含めた情報でもよい。
ステップ21では、制御装置3は端末1から第1のタイミングにおける端末1に関する位置情報と加速度情報を受信する。受信は、位置情報と加速度情報とをまとめて受信することであってもよいし、いずれか一つだけを受信することであっても良い。また受信する周期は、一定であってもそうでなくても良い。
ステップ22では、制御装置3は受信した位置情報と加速度情報を記録し、フローを終了またはステップ20から繰り返す。記録は、制御装置3のメモリに記録することであってもよいし、制御装置3と接続される外部データベースへ記録することであっても良い。
図2-Bは、端末1を捜索する制御装置3の動作の一例を示すフロー図である。ステップ23では、制御装置3は応答信号を制御装置3へ送信するよう要求する捜索信号を、端末1へ送信する。
捜索信号は、例えば発呼、メール送信、アプリケーションへの通知などであってもよい。なお捜索信号の送信は、端末1の捜索に関する依頼が制御装置3へ入力されたこと、所定期間位置情報と加速度情報の少なくともいずれかを受信できないこと、などをトリガーとしても良い。なお制御装置3は、捜索信号を端末1に送信する代わりに、携帯電話通信網に対して、端末1の接続状況の問い合わせを行っても良い。
ステップ24では、制御装置3は、ステップ23の捜索信号に対して応答信号を受信できたかを判定する。受信できたと判定した場合は、制御装置3は受信したことを示す情報を出力し、フローを終了する。出力は例えばユーザーインターフェースへ表示することであってもよい。なお受信できなかったと判定された場合は、ステップ25へ進む。応答信号は、例えば、制御装置3からの発呼に対する応答、制御装置3から受信したメールへの返信、通知されたアプリケーションに対する何らかの動作、などであってもよい。
ステップ25では、制御装置3は記録している第1のタイミングにおける端末1に関する位置情報と加速度情報のいずれか、または両方に基づいて第1のタイミングとは異なる第2のタイミングにおける端末1の位置を推定する。一例として第2のタイミングにおける端末1の位置の推定は、最新(例えば、第1のタイミング)の位置情報を起点とし、最新(例えば、第1のタイミング)の加速度情報に基づいた移動距離および方向を利用することで推定することであっても良い。
一例として第2のタイミングにおける端末1の位置の推定は、最新(例えば、第1のタイミング)の位置情報を起点に、以前の位置情報、経過時間、加速度情報等、に基づいた移動距離および方向を利用することで推定することであってもよい。加速度情報から推定される移動距離や方向は、移動確率などの変動するパラメータを用いることで推定される領域であってもよい。位置情報から推定される移動距離や方向は、所定期間の位置情報の差分をとり、移動確率などの変動するパラメータを用いることで推定される領域であってもよい。なお、第1のタイミングが最近の情報である場合に、この第1のタイミングにおける端末1に関する位置情報をそのまま用いて第2のタイミングにおける端末1の位置として推定してもよい。
ステップ26では、制御装置3は位置と当該位置での通信確率を示す情報から、推定した位置における端末の通信確率を決定する。
通信確率を示す情報は、制御装置3が保持していてもよいし、外部のデータベースやインターネットサービスから随時取得しても良い。通信確率を示す情報は、当該位置における通信実績から算出されてもよいし、当該位置における通信速度であっても良いし、当該位置における受信信号電力対干渉および雑音電力比SINR(Signal to Interference plus Noise power Ratio)であってもよいし、当該位置におけるパケットロス率であってもよい。また通信確率を示す情報は、当該位置に関する基地局の配置情報や基地局セルの周波数情報、干渉局の配置情報などから生成されてもよい。
通信確率は、対応する当該位置における場所に関する属性によって決定されるものであってもよい。例えば、当該位置に基地局セルが設置されていない、もしくは設置されていても電波の届かない山間部や海周辺といった圏外である領域であれば、通信確率を「低」としてもよい。また例えば、当該位置が公園等の街中に点在する基地局セルからの電波の届かない領域である場合の通信確率を、「中」から「低」としてもよい。また例えば、ビル等建物の屋内や建物間の隙間、壁際、地下通路といった領域の場合、電波の届く領域と届かない領域が混在し、端末1が一時的に圏外エリア(不感地帯)に侵入することがあるため、当該位置に対応する通信確率は「中」としてもよい。また例えば、都市部における道路上といった屋外である場合、基地局セルからの電波が基本的に届くとして、当該位置に対応する通信確率を「高」としてもよい。
ステップ27では、制御装置3は決定した通信確率に基づいて、端末1を捜索するための対策手段を選択する。そして制御装置3は選択した対策手段を示す情報を出力する。なお出力は、一つ以上の対策手段を示す情報をユーザーインターフェースに表示することであってもよいし、所定の捜査機関へ捜索依頼を送信することであっても良い。
制御装置3は、応答信号を受信できなかったと判定した場合、捜索を容易にするために、端末1に対してLED点滅要求、および、警告音発生要求の少なくともいずれかを所定の間隔で送信してもよい。特に端末の通信確率が「高」または「中」と決定された場合にLED点滅要求、および、警告音発生要求の少なくともいずれかが送信されてもよい。
図3は、第1の側面における端末1の動作の一例を示すフロー図である。
図3ーAは、位置情報と加速度情報の報告に関する端末1の動作の一例を示すフロー図である。ステップ31では、端末1は所定の報告条件に合致するか判定する。条件に合致する場合は、ステップ32へ進む。合致しない場合は、合致するまでステップ31を繰り返すか、フローを終了する。
所定の条件は、例えば、制御装置3から報告の要求を受信したこと、事前に設定された周期となったこと、端末1がネットワークとの接続を確立したこと、端末1の通信品質劣化を検知したこと、端末1の電池残量のしきい値を下回ったこと、端末1の位置情報や加速度情報が急激に変化したこと、などであってもよい。
ステップ32では、端末1は第1のタイミングにおける端末1に関する位置情報と加速度情報を制御装置3へ送信し、フローを終了する。
位置情報と加速度情報は、それぞれ端末1に備えられた位置センサおよび加速度センサで収集した情報であってもよい。位置情報と加速度情報のそれぞれは、センサが測定したタイミングの情報であってもよいし、センサが測定した所定期間の情報であっても良い。なお加速度情報が所定期間の情報である場合は、平均値を示す情報でもよいし、最大値と最小値を含めた情報でもよい。また収集した情報は、端末1のメモリに記録し、端末1は記録した情報を送信しても良い。また位置情報と加速度情報は、同時に送信されてもよいし、別々に送信されても良い。
図3-Bは、制御装置3から捜索信号を受信する端末1の動作の一例を示すフロー図である。ステップ33では、端末1は制御装置3から、応答信号を制御装置3へ送信するよう要求する捜索信号を受信する。捜索信号は、例えば発呼、メール送信、アプリケーションへの通知などであってもよい。
ステップ34では、端末1は制御装置3へ応答信号を送信し、フローを終了する。応答信号は、例えば、制御装置3からの発呼に対する応答、制御装置3から受信したメールへの返信、通知されたアプリケーションに対する何らかの動作、などであってもよい。
関連する技術においては、端末と制御装置が通信不能となった場合に、端末を捜索するための適切な対策手段を選択することができなかった。本明細書の開示における第1の側面の構成によれば、端末の位置を推定し、推定した位置における通信確率を決定し、決定された通信確率に対応する対策手段を示す情報を出力するので、状況に応じた適切な対策手段を選択することができるようになる。
<本明細書の開示における第2の側面>
第2の側面では、端末1の推定した位置における通信確率に基づいて、D2D通信を用いた対策手段が選択される場合に関して説明する。
関連する技術においては、圏外等を理由に通信不能になった端末について、捜索する手順は検討されていなかった。また、視覚や聴覚に基づいた人間の判断による捜索が行われており、誤発見の可能性があった。
第2の側面によれば、圏外、または圏内にいるにもかかわらず応答できない状態である、等を理由に通信不能になった端末を、D2D通信を用いて捜索することができるようになる。また、D2D通信を用いて捜索するため、広範囲を正確に端末の捜索ができるようになる。
図4は、第2の側面における端末1、端末2-2、2-3、2-4および制御装置3を有する通信システムの動作の一例を示すシーケンス図である。
第2の側面では、第1の側面の図1におけるステップ5の後、推定した位置における通信確率に基づいて、端末1が通信不能と判定され、D2D通信を用いた対策手段が選択された場合の動作の一例について説明する。ステップ5までは、図1と同様の動作のため説明を省略する。
ステップ108では、制御装置3は、少なくとも1台以上のD2D通信可能な端末2(一例として、端末2-2、端末2-3、端末2-4を図示)へ、捜索依頼を送信する。捜索依頼の送信は、複数の対策手段を示す情報をユーザーインターフェース(UI)に表示し、操作者が少なくとも1つの対策手段を選択するステップ(不図示)に基づいて特定される捜索依頼を送信すること、であっても良い。捜索依頼は、端末1の属性や、推定した位置に関する情報を含んでも良い。捜索依頼は、制御装置3が希望する、端末2の能力情報(例えば、D2D通信能力、移動能力、飛行能力など)を含んでも良い。また捜索依頼は、依頼先を指定して送信されてもよいし、登録してある依頼先全体に送信されてもよい。
ステップ109では、端末2(図4では一例として、端末2-2と端末2-3)は、制御装置3へ、捜索依頼に対する応答信号を送信する。端末2は捜索依頼に対して対応可能である場合、応答信号として許諾を示す許諾応答を送信する。一方端末2は捜索依頼に対して対応できない場合、応答信号として拒否を示す拒否応答を送信してもよいし、応答信号を送信せずに無視しても良い。図4では、端末2-4は、捜索依頼に対して応答していない例を示している。許諾を示す場合、端末2は応答信号に、端末2の情報(例えば、所持者に関する情報、通信能力(電波送信可能距離、対応周波数、対応携帯ネットワークオペレータ、など)、端末2の電源残量、など)を含めても良い。
ステップ110では、制御装置3は、許諾を示す内容の応答信号(許諾応答)を送信した端末2へ、捜索情報を送信する。ここで、許諾応答である応答信号を送信してきた端末2をD2D端末とも呼ぶ。制御装置3は、応答信号に含まれる端末2の情報に基づいて、捜索情報を送信する宛先を選択しても良い。図4では、一例として端末2-3は選ばれず、端末2-2が選ばれた場合を示している。
捜索情報は、許諾応答に含まれる端末2の情報に基づいて生成されても良い。捜索情報は、例えば、端末1の属性情報(保持者に関する情報、端末の種類、捜索理由など)、推定した端末1の位置、第1の端末の推定した位置における通信確率、D2D捜索信号を送信すべき領域を示すナビゲーション情報、などであってもよい。ここで、D2D捜索信号とはD2D通信を用いて端末2から端末1へと送信される、端末1からの応答信号を要求する捜索信号である。ナビゲーション情報は、端末1の推定した位置から生成されても良い。またナビゲーション情報は、端末2の通信能力、通信確率を示す情報などを考慮して生成されても良い。またナビゲーション情報は、D2D捜索信号を発信すべき回数、時間、位置などを示しても良い。なお許諾を示す応答を受信しない場合、制御装置3は推定した位置と、応答を受信していないことに基づいて、新たな対策手段を選択し、フローを終了してもよい。
ステップ111では、端末2は、D2D通信を用いてD2D捜索信号を発信する。D2D捜索信号として、例えば、ProSe Direct Discovery信号が使われても良い。端末2はD2D捜索信号の発信を、例えば、移動しながら行うことで、D2D捜索信号の到達距離に加えて移動距離分の範囲を捜索することができる。D2D捜索信号には、端末1にLEDの点滅要求を含めてもよいし、警告音の再生要求を含めても良い。
ステップ112では、端末1は、端末2からのD2D捜索信号の受信に応じて、D2D通信を用いて応答信号を端末2へ送信する。応答信号として、例えば、ProSe Direct Discovery信号が使われても良い。応答信号は、例えば、端末1の識別子、端末1の位置情報、端末1の状況(行動可否、保持者の状態、電源残量など)、などを含んでも良い。また端末1は、D2D捜索信号の受信又は制御装置3からの要求に応じて、LEDを点滅させてもよいし、警告音を再生しても良い。
ステップ113では、端末2は、制御装置3へ、捜索結果を送信する。捜索結果は、端末1からの応答信号を受信したことを示してもよいし、所定のD2D捜索信号を送信したが応答信号を受信しなかったことを示しても良い。応答信号を受信した場合の捜索結果は、例えば、端末1の位置情報、応答信号を受信したときの端末2の位置情報、端末1の状況(行動可否、保持者の状態、電源残量、など)、など含んでもよい。応答信号を受信しなかった場合の捜索結果は、例えば、端末2の移動履歴、端末2からの発信回数、などを含んでも良い。
図5は、第2の側面における制御装置3の動作の一例を示すフロー図である。
第2の側面では、第1の側面の図2におけるステップ26の後、推定した位置における通信確率に基づいて、D2D通信を用いた対策手段が選択された場合の制御装置3の動作である。ステップ20~26までは、第1の側面の図2の動作と同様のため省略する。
ステップ208では、制御装置3は、少なくとも1台以上のD2D通信可能な端末2へ、捜索依頼を送信する。複数の対策手段を示す情報をユーザーインターフェース(UI)に表示し、操作者が少なくとも1つの対策手段を選択するステップ(不図示)に基づいて特定される捜索依頼を送信すること、であっても良い。捜索依頼は、端末1の属性や、推定した位置に関する情報を含んでも良い。捜索依頼は、制御装置3が希望する、端末2の能力情報(例えば、D2D通信能力、移動能力、飛行能力など)を含んでも良い。また捜索依頼は、依頼先を指定して送信されてもよいし、登録してある依頼先候補全てに送信されてもよい。
ステップ209では、制御装置3は、捜索依頼に対する応答信号を端末2から受信する。応答信号は、捜索依頼に対応可能であれば許諾を示す許諾応答であってもよい。応答信号は、捜索依頼に対し、拒否を示す拒否応答であってもよい。また応答信号が所定期間経過後も受信できない場合、制御装置3は、捜索依頼に対応可能な端末2がいないと判断しても良い。許諾を示す内容の応答信号(許諾応答)は、例えば、端末2の情報(例えば、所持者に関する情報、通信能力(電波送信可能距離、対応周波数、対応携帯ネットワークオペレータ、など)、端末2の電源残量、など)を含んでも良い。なお許諾を示す応答信号(許諾応答)を受信しない場合、制御装置3は推定した位置と、応答を受信していないことに基づいて、新たな対策手段を選択し、対応する情報を出力してフローを終了してもよい。
ステップ210では、制御装置3は、ステップ209で、許諾応答を受信した少なくとも1台の端末2へ捜索情報を送信する。ここで、許諾応答である応答信号を送信してきた端末2をD2D端末とも呼ぶ。制御装置3は、応答信号に含まれる端末2の情報に基づいて、捜索情報を送信する宛先を選択しても良い。捜索情報は、許諾応答に含まれる端末2の情報に基づいて生成されても良い。捜索情報は、例えば、端末1の属性情報(保持者に関する情報、端末の種類、捜索理由など)、推定した端末1の位置、推定した位置の通信確率、D2D捜索信号を送信すべき領域を示すナビゲーション情報、などであってもよい。ナビゲーション情報は、端末1の推定した位置から生成されても良い。またナビゲーション情報は、端末2の通信能力、通信確率を示す情報などを考慮して生成されても良い。またナビゲーション情報は、D2D捜索信号を発信すべき回数、時間、位置などを示しても良い。
ステップ211では、制御装置3は、ステップ210で捜索情報を送信した端末2から捜索結果を受信する。捜索結果は、端末2が端末1からの応答信号を受信したことを示してもよいし、端末2が所定のD2D捜索信号を送信したが応答信号を受信しなかったことを示しても良い。応答信号を受信した場合の捜索結果は、例えば、端末1の位置情報、応答信号を受信したときの端末2の位置情報、端末1の状況(行動可否、保持者の状態、電源残量、など)、など含んでもよい。応答信号を受信しなかった場合の捜索結果は、例えば、端末2の移動履歴、端末2からの発信回数、などを含んでも良い。
ステップ212では、制御装置3は、端末2による捜索結果を出力してフローを終了する。出力はユーザーインターフェースに表示することでもよい。
図6は、第2の側面における端末1の動作の一例を示すフロー図である。ステップ31~34の動作は図3と同様のため省略する。
ステップ35では、端末1は、D2D通信を用いたD2D捜索信号を端末2から受信する。
ステップ36では、ステップ35で受信したD2D捜索信号に基づき、送信元である端末2へD2D通信を用いて応答信号を送信し、フローを終了する。応答信号は、例えば、端末1の識別子、端末1の位置情報、端末1の状況(行動可否、保持者の状態、電源残量など)、などを含めても良い。なお端末1は、D2D捜索信号の受信又は制御装置3からの要求に応じて、LEDを点滅させてもよいし、警告音を再生しても良い。
図7は、第2の側面における端末2の動作の一例を示すフロー図である。ステップ301では、端末2は、制御装置3から捜索依頼を受信する。捜索依頼は、端末1の属性や、推定した位置に関する情報を含んでも良い。捜索依頼は、制御装置3が希望する能力情報(例えば、D2D通信能力、移動能力、飛行能力など)を含めても良い。
ステップ302では、端末2は、捜索依頼に対する応答信号を、制御装置3へ送信する。応答信号は、捜索依頼に対する許諾を示す許諾応答であっても良い。また応答信号は拒否を示す拒否応答であっても良い。また捜索依頼に対して拒否する場合は、応答信号を送信しなくても良い。拒否する場合は、フローを終了する。許諾を示す場合は、許諾を示す応答信号(許諾応答)に、端末2の情報(例えば、所持者に関する情報、通信能力(電波送信可能距離、対応周波数、対応携帯ネットワークオペレータ、など)、端末2の電源残量、など)を含めても良い。ここで、許諾応答である応答信号を送信してきた端末2をD2D端末とも呼ぶ。
ステップ303では、端末2は、制御装置3から、捜索情報を受信する。捜索情報は、例えば、端末1の属性情報(保持者に関する情報、端末の種類、捜索理由など)、推定した端末1の位置、推定した位置の通信確率、捜索すべき領域を示すナビゲーション情報、などであってもよい。ナビゲーション情報は、端末1の推定した位置から生成されても良い。またナビゲーション情報は、端末2の通信能力、通信確率を示す情報などを考慮して生成されても良い。またナビゲーション情報は、D2D捜索信号を発信すべき回数、時間、位置などを示しても良い。
ステップ304では、端末2は捜索情報に基づいて、D2D通信を用いてD2D捜索信号を発信する。D2D捜索信号は、例えば、ProSe Direct Discovery信号を使えば良い。端末2はD2D捜索信号の発信を、例えば、移動しながら行うことで、D2D捜索信号の到達距離に加えて移動距離分の範囲を捜索することができる。D2D捜索信号には、端末1にLEDの点滅要求を含めてもよいし、警告音の再生要求を含めても良い。
ステップ305では、端末2は、D2D捜索信号に対する応答信号を受信したこと、または所定のD2D捜索信号を発信完了したこと、のいずれかを満たしたかを判定する。条件を満たした場合ステップ306へ進む。満たしていない場合は、引き続きステップ304を繰り返す。所定の条件は、例えば、捜索情報等で設定された期間D2D捜索信号を発信したこと、設定された回数D2D捜索信号を発信したこと、指定された領域でD2D捜索信号を発信したこと、などであってもよい。受信する応答信号は、例えば、端末1の識別子、端末1の位置情報、端末1の状況(行動可否、保持者の状態、電源残量など)、などが含まれても良い。
ステップ306では、端末2は、D2D捜索信号を用いた捜索結果を、制御装置3へ送信し、フローを終了する。応答信号を受信した場合の捜索結果は、例えば、端末1の位置情報、応答信号を受信したときの端末2の位置情報、端末1の状況(行動可否、保持者の状態、電源残量、など)、など含んでもよい。応答信号を受信しなかった場合の捜索結果は、例えば、端末2の移動履歴、端末2からの発信回数、などを含んでも良い。
関連技術では、圏外等を理由に通信不能になった端末について、捜索する手順は検討されていなかった。また、視覚や聴覚に基づいた人間の判断による捜索が行われており、誤発見の可能性があった。
本明細書の開示における第2の側面によれば、圏外、または、圏内にいるにもかかわらず応答できない状態である等を理由に通信不能になった端末を、D2D通信を用いて捜索することができるようになる。また、D2D通信を用いて捜索するため、広範囲を正確に端末の捜索ができるようになる。
<本明細書の開示における第3の側面>
本明細書の開示における第2の側面の構成では、端末2が単体である場合について説明した。本明細書の開示における第3の側面では、複数の端末2を用いることで、より効率的に端末1の捜索をする対策手段について説明する。
図8は、第3の側面における端末1、端末2-1、2-2、2-3、2-4および制御装置3を備える通信システムの動作の一例を示すシーケンス図である。ステップ6までの動作は図1および図4と同様のため省略する。
ステップ108では、制御装置3は、複数のD2D通信可能な端末2(e.g.端末2-1、端末2-2、端末2-3、端末2-4)へ、捜索依頼を送信する。捜索依頼の送信は、複数の対策手段を示す情報をユーザーインターフェース(UI)に表示し、操作者が選択するステップ(不図示)に基づいて送信しても良い。捜索依頼は、端末1の属性や、推定した位置に関する情報を含んでも良い。捜索依頼は、制御装置3が希望する能力情報(例えば、D2D通信能力、移動能力、飛行能力など)を含めても良い。また捜索依頼は、依頼先を指定して送信されてもよいし、登録してある依頼先全体に送信されてもよい。
ステップ409では、少なくとも複数の端末2(e.g.端末2-1、端末2-2、端末2-3)は、捜索依頼に対する応答信号を、制御装置3へ送信する。端末2は捜索依頼に対して対応可能である場合、応答信号として許諾を示す許諾応答を送信する。一方端末2は捜索依頼に対して対応できない場合、応答信号として拒否を示す拒否応答を送信してもよいし、応答信号を送信せずに無視しても良い。図8では、端末2-4は、捜索依頼に対して応答していない例を示している。許諾を示す場合、端末2は応答信号に、端末の情報(例えば、位置情報、所持者に関する情報、通信能力(電波送信可能距離、対応周波数、対応携帯ネットワークオペレータ、D2D通信に関する設定情報など)、端末の電源残量、移動能力、飛行能力など)を含めても良い。
ステップ410では、制御装置3は、許諾を示す内容の応答信号(許諾応答)を送信した複数の端末2(e.g.端末2-1、端末2-2)へ、捜索情報を送信する。ここで、許諾応答である応答信号を送信してきた端末2をD2D端末とも呼ぶ。制御装置3は、応答信号に含まれる端末の情報に基づいて、捜索情報を送信する宛先を選択しても良い。図8では、一例として端末2-3は選ばれず、端末2-1と端末2-2が選ばれた場合を示している。なお許諾を示す応答を受信しない場合は、制御装置3は推定した位置と、応答を受信していないことに基づいて、新たな対策手段を選択し、フローを終了してもよい。制御装置3による複数の端末2の選択は、複数の端末2間(例えば端末2-1と端末2-2との間)でD2D通信可能かどうか、に基づいても良い。
捜索情報は、許諾応答に含まれる端末2の情報に基づいて生成されても良い。捜索情報は、例えば、端末1の属性情報(保持者に関する情報、端末の種類、捜索理由など)、推定した端末1の位置、推定した位置の通信確率、D2D捜索信号を送信すべき領域を示すナビゲーション情報、D2D捜索信号を発信する他端末2の情報(一例として、端末2-2の情報を捜索情報に含めて端末2-1に送信)、などであってもよい。
ナビゲーション情報は、端末1の推定した位置と、端末2-1の情報と、端末2-2の情報から生成される。ナビゲーション情報の生成に用いられる端末2-1と端末2-2の情報は、例えば、端末2-1の通信能力と端末2-2の通信能力であってもよいし、端末2-1の位置情報と端末2-2の位置情報であってもよいし、通信能力と位置情報との両方であっても良い。またナビゲーション情報の生成に用いられる端末2-1と端末2-2の情報は、応答信号に含められる端末2の情報に含まれる要素を適宜組み合わせたものであってもよい。またナビゲーション情報はさらに、端末1の推定した位置における通信確率を示す情報をさらに考慮して生成しても良い。
ナビゲーション情報は、D2D捜索信号を発信すべき回数、時間、位置などを示しても良い。このとき端末2の電池残量に応じてD2D捜索信号を発信すべき回数、時間、位置などが決定されても良い。例えば電池残量が充分あるときは短時間の発信を多く繰り返すようにしてもよいし、例えば電池残量が少ないときは長時間の発信を少ない回数行うようにしてもよい。
またナビゲーション情報は、端末2-1または端末2-2の侵入を禁止する領域や制限する領域を示しても良い。このときナビゲーション情報は、崖や急勾配といった地理、地形情報に基づいた領域を示しても良い。
ナビゲーション情報は、他端末のD2D電波到達範囲を示す地図情報を含んでも良い。ナビゲーション情報は、一例として端末2-2が、端末2-1と同一領域でD2D捜索信号を発信しないような領域を示すように生成されても良い。またナビゲーション情報は、例えば端末2-2が、端末2-1を介して基地局と接続可能な領域内でD2D捜索信号を発信するように適切な領域を示すように生成されても良い。
ステップ411では、複数の端末2(e.g.端末2-1と端末2-2)は、捜索情報に基づき、複数の端末2の間でD2D通信のパスを確立する。D2D通信のパスは例えば、ProSe Direct Communicationのパスであってもよい。パスは、端末2(e.g.端末2-2、リモート端末)と他の端末2(e.g.端末2-1、リレー端末)を介して携帯通信網と接続する中継パスとして使われても良い。中継については、例えば、ProSe UE-to-NW Relay通信であってもよい。またD2D通信のパスは、D2D捜索信号を既に発信した領域を示す情報の交換に用いられても良い。またD2D通信のパスは、端末1を発見したことの他端末との共有に用いられても良い。
ステップ412では、端末2は(e.g.端末2-2)、他の端末2(e.g.端末2-1)と端末間直接通信のパスを確立したまま、D2D捜索信号を送信する。D2D捜索信号は、例えば、ProSe Direct Discovery信号が使われても良い。またD2D捜索信号は、端末1へのLEDの点滅要求を含んでもよいし、警告音の再生要求を含んでも良い。端末2はD2D捜索信号の発信を、例えば、移動しながら行うことで、D2D捜索信号の到達距離に加えて移動距離分の範囲を捜索することができる。さらに第3の側面の構成であれば、端末2-1が基地局と通信しながらD2Dパスを確立することができるため、端末2-2は基地局と通信できないエリアに侵入した上でD2D捜索信号を発信することができる。これによれば、第2の側面の構成に比べて、端末2-1のD2D通信距離に加えて端末2-2のD2D通信距離分より広範囲に対して端末1を捜索できる。
ステップ413では、端末1はD2D捜索信号を受信すると、D2D捜索信号の送信元である端末2-2へ、D2D通信を用いて応答信号を送信する。応答信号は、例えば、ProSe Direct Discovery信号が使われても良い。応答信号は、例えば、端末1の識別子、端末1の位置情報、端末1の状況(行動可否、保持者の状態、電源残量など)、などを含んでも良い。なお端末1は、D2D捜索信号又は制御装置3からの要求の受信に応じて、LEDを点滅させてもよいし、警告音を再生しても良い。
ステップ414では、端末2(e.g.端末2-2)は、確立しているパスを介して捜索結果を他の端末2(e.g.端末2-1)へ送信する。捜索結果は、端末1からの応答信号を受信したことを示してもよいし、所定のD2D捜索信号を送信したが応答信号を受信しなかったことを示しても良い。応答信号を受信した場合の捜索結果は、例えば、端末1の位置情報、応答信号を受信したときの端末2-2の位置情報、端末1の状況(行動可否、保持者の状態、電源残量、など)、など含んでもよい。応答信号を受信しなかった場合の捜索結果は、例えば、端末2-2の移動履歴、端末2-2からの発信回数、などを含んでも良い。
ステップ415では、他の端末2(e.g.端末2-1)は、制御装置3へ、複数の端末2(e.g.端末2-1および端末2-2)によるD2D通信を用いた端末1の捜索結果を報告する。捜索結果は、端末2(e.g.端末2-2)から送信された内容と同様であってもよい。また、捜索結果は、端末2(e.g.端末2-2)から送信された内容に加えて、他の端末2(e.g.端末2-1)の位置情報、他の端末2(e.g.端末2-1)の移動履歴などを含んでも良い。制御装置3は、受信した捜索結果を出力しても良い。
図9は、第3の側面における制御装置3の動作の一例を示すフロー図である。
第3の側面では、第1の側面の図2におけるステップ26の後、推定した位置における通信確率に基づいて、端末1が通信不能と判定され、複数の端末によるD2D通信を用いた対策手段が選択された場合の制御装置3の動作を説明する。ステップ26までの動作は、図2および図5と同様のため省略する。
ステップ208では、制御装置3は、複数のD2D通信可能な端末2(e.g.端末2-1、端末2-2、端末2-3、端末2-4)へ、捜索依頼を送信する。捜索依頼の送信は、複数の対策手段を示す情報をユーザーインターフェース(UI)に表示し、操作者が選択するステップ(不図示)に基づいて送信することであっても良い。捜索依頼は、端末1の属性や、推定した位置に関する情報を含んでも良い。捜索依頼は、制御装置3が希望する、端末2の能力情報(例えば、D2D通信能力、移動能力、飛行能力など)を含めても良い。また捜索依頼は、依頼先を指定して送信されてもよいし、登録してある依頼先全体に送信されてもよい。
ステップ509では、制御装置3は、少なくとも複数の端末2(e.g.端末2-1、端末2-2、端末2-3)から、捜索依頼に対する応答信号を受信する。応答信号が許諾を示す内容(許諾応答)である場合に、制御装置3は、捜索依頼に対して当該端末が対応可能であると判断しても良い。応答信号が拒否を示す内容(拒否応答)である場合、制御装置3は、捜索依頼に対して当該端末が対応不能であると判断しても良い。また制御装置3は、応答信号を受信しない場合、当該端末が拒否を示していると判断しても良い。許諾を示す応答信号には、端末2の情報(例えば、所持者に関する情報、通信能力(電波送信可能距離、対応周波数、対応携帯ネットワークオペレータ、など)、端末2の電源残量、など)が含まれていても良い。なお許諾を示す応答信号(許諾応答)を受信しない場合、制御装置3は推定した位置と、応答を受信していないことに基づいて、新たな対策手段を選択し、対応する情報を出力してフローを終了してもよい。
ステップ510では、制御装置3は、ステップ509で、許諾応答を受信した複数の端末2(e.g.端末2-1、端末2-2)へ、捜索情報を送信する。ここで、許諾応答である応答信号を送信してきた端末2をD2D端末とも呼ぶ。制御装置3は、応答信号に含まれる端末の情報に基づいて、捜索情報を送信する宛先を選択しても良い。図9では、一例としてステップ509で許諾を示した端末2-3は選ばれず、端末2-1と端末2-2が選ばれた場合を示している。制御装置3による複数の端末2の選択は、複数の端末2間(例えば端末2-1と端末2-2との間)でD2D通信可能かどうか、に基づいても良い。
捜索情報は、許諾応答に含まれる端末2の情報に基づいて生成されても良い。捜索情報は、例えば、端末1の属性情報(保持者に関する情報、端末の種類、捜索理由など)、推定した端末1の位置、推定した位置の通信確率、D2D捜索信号を送信すべき領域を示すナビゲーション情報、D2D捜索信号を発信する他端末の情報(一例として、端末2-2の情報を捜索情報に含めて端末2-1に送信)、などを含んでもよい。
ナビゲーション情報は、端末1の推定した位置と、複数の端末2の情報(e.g.端末2-1の情報と、端末2-2の情報)から生成される。ナビゲーション情報の生成に用いられる端末2-1と端末2-2の情報は、例えば、端末2-1の通信能力と端末2-2の通信能力であってもよいし、端末2-1の位置情報と端末2-2の位置情報であってもよいし、通信能力と位置情報との両方であっても良い。またナビゲーション情報の生成に用いられる端末2-1と端末2-2の情報は、応答信号に含められる端末の情報に含まれる要素を適宜組み合わせたものであってもよい。またナビゲーション情報はさらに、端末1の推定した位置における通信確率を示す情報をさらに考慮して生成しても良い。
ナビゲーション情報は、D2D捜索信号を発信すべき回数、時間、位置などを示しても良い。このとき端末2の電池残量に応じてD2D捜索信号を発信すべき回数、時間、位置などが決定されても良い。例えば電池残量が充分あるときは短時間の発信を多く繰り返すように端末2を制御するようなナビゲーション情報が生成されてもよいし、例えば電池残量が少ないときは長時間の発信を少ない回数行うように端末2を制御するようなナビゲーション情報が生成されてもよい。
またナビゲーション情報は、複数の端末2(e.g.端末2-1または端末2-2)の侵入を禁止する領域や制限する領域を示しても良い。このときナビゲーション情報は、崖や急勾配といった地理、地形情報に基づいて領域を決定しても良い。
ナビゲーション情報は、他端末のD2D電波到達範囲を示す地図情報を含んでも良い。ナビゲーション情報は、一例として端末2(e.g.端末2-2)が、他の端末2(e.g.端末2-1)と同一領域でD2D捜索信号を発信しないような領域を示すように生成されても良い。またナビゲーション情報は、例えば端末2(e.g.端末2-2、リモート端末)が、他の端末2(e.g.端末2-1、リレー端末)を介して基地局と接続可能な領域内でD2D捜索信号を発信するように適切な領域を示すように生成されても良い。
ステップ511では、制御装置3は、他の端末2(e.g.端末2-1)を介して端末2(e.g.端末2-2)から、複数の端末2(e.g.端末2-1および端末2-2)によるD2D通信を用いた端末1の捜索結果を受信する。制御装置3が受信する捜索結果は、端末2(e.g.端末2-2)から送信された内容と同様であってもよい。また、捜索結果は、端末2(e.g.端末2-2)から送信された内容に加えて、他の端末2(e.g.端末2-1)の位置情報、他の端末2(e.g.端末2-1)の移動履歴などを含んでも良い。
ステップ512では、制御装置3は、捜索結果を出力してフローを終了する。出力はユーザーインターフェースに表示することでもよい。
第3の側面における端末1の動作については、図3および図6と同様のため省略する。
図10は第3の側面における複数の端末2の動作の一例を示すフロー図である。
図10-Aは、第3の側面における端末2(e.g.端末2-2)の動作の一例を示すフロー図である。ステップ302までの動作は、第2の側面の図7と同様のため省略する。
ステップ603では、端末2(e.g.端末2-2)は、制御装置3から、他の端末2(e.g.端末2-1)と協調して端末1を捜索することを求める捜索情報を受信する。
捜索情報は、許諾応答に含まれる端末2の情報に基づいて生成されても良い。捜索情報は、例えば、端末1の属性情報(保持者に関する情報、端末の種類、捜索理由など)、推定した端末1の位置、推定した位置の通信確率、D2D捜索信号を送信すべき領域を示すナビゲーション情報、D2D捜索信号を発信する他端末の情報(e.g.端末2-1の情報)、などを含んでもよい。
ナビゲーション情報は、端末1の推定した位置と、複数の端末2の情報(e.g.端末2-1の情報と端末2-2の情報)から生成される。ナビゲーション情報の生成に用いられる複数の端末2の情報(e.g.端末2-1と端末2-2の情報)は、例えば、複数の端末2の通信能力(e.g.端末2-1の通信能力と端末2-2の通信能力)であってもよいし、複数の端末2の位置情報(e.g.端末2-1の位置情報と端末2-2の位置情報)であってもよいし、通信能力と位置情報との両方であっても良い。またナビゲーション情報の生成に用いられる複数の端末2(e.g.端末2-1と端末2-2)の情報は、応答信号に含められる端末の情報に含まれる要素を適宜組み合わせたものであってもよい。またナビゲーション情報はさらに、端末1の推定した位置における通信確率を示す情報をさらに考慮して生成されても良い。
ナビゲーション情報は、D2D捜索信号を発信すべき回数、時間、位置などを示しても良い。このとき端末2(e.g.端末2-2)の電池残量に応じて、D2D捜索信号を発信すべき回数、時間、位置などが決定されても良い。例えば電池残量が充分あるときは短時間の発信を多く繰り返すように端末2を制御するようなナビゲーション情報が生成されてもよいし、例えば電池残量が少ないときは長時間の発信を少ない回数行うよう端末2を制御するようなナビゲーション情報が生成されてもよい。
またナビゲーション情報は、侵入を禁止する領域や制限する領域を示しても良い。このときナビゲーション情報は、崖や急勾配といった地理、地形の情報に基づいて領域を決定しても良い。
ナビゲーション情報は、他端末(e.g.端末2-1)のD2D電波到達範囲を示す地図情報を含んでも良い。このときナビゲーション情報は、一例として端末2-1と同一領域でD2D捜索信号を発信しないような領域を示すように生成されても良い。またナビゲーション情報は、端末2-1を介して基地局と接続可能な領域内でD2D捜索信号を発信するように適切な領域を示すように生成されても良い。
ステップ604では、複数の端末2は他の端末2と(e.g.端末2-2と端末2-1)、捜索情報に基づいてD2D通信パスを確立する。D2D通信のパスは例えば、ProSe Direct Communicationのパスであってもよい。パスは、端末2-1(e.g.リレー端末)を介して携帯通信網と接続する中継パスとして使われても良い。中継については、例えば、ProSe UE-to-NW Relay通信であってもよい。またD2D通信のパスは、D2D捜索信号を既に発信した領域を示す情報の交換に用いられても良い。またD2D通信のパスは、端末1を発見したことの他端末(e.g.端末2-1)との共有に用いられても良い。
ステップ605では、端末2は(e.g.端末2-2)、他の端末2(e.g.端末2-1)と端末間直接通信のパスを確立したまま、D2D捜索信号を発信する。D2D捜索信号として、例えば、ProSe Direct Discovery信号が使われても良い。またD2D捜索信号には、端末1へのLEDの点滅要求を含めてもよいし、警告音の再生要求を含めても良い。端末2-2はD2D捜索信号の発信を、例えば、移動しながら行うことで、D2D捜索信号の到達距離に加えて移動距離分の範囲を捜索することができる。さらに第3の側面の構成であれば、端末2-1(e.g.リレー端末)が基地局と通信しながらD2Dパスを確立することができるため、端末2-2は基地局と通信できないエリアに侵入した上でD2D捜索信号を発信することができる。これによれば、第2の側面の構成に比べて、端末2-1のD2D通信距離に加えて端末2-2のD2D通信距離分より広範囲に対して端末1を捜索できる。
ステップ606では、端末2(e.g.端末2-2)は、D2D捜索信号に対する応答信号を受信したこと、または所定のD2D捜索信号を発信完了したこと、のいずれかの条件を満たしたかを判定する。条件を満たした場合、ステップ607へ進む。条件を満たしていない場合、ステップ605を繰り返す。
応答信号は、例えば、ProSe Direct Discovery信号が使われても良い。応答信号は、例えば、端末1の識別子、端末1の位置情報、端末1の状況(行動可否、保持者の状態、電源残量など)、などを含んでも良い。
所定の条件は、例えば、捜索情報等で設定された期間D2D捜索信号を発信したこと、設定された回数D2D捜索信号を発信したこと、指定された領域でD2D捜索信号を発信完了したこと、などであってもよい。
ステップ607では、端末2(e.g.端末2-2)は、確立しているパスを介して捜索結果を他の端末2(e.g.端末2-1)へ送信し、フローを終了する。
捜索結果は、端末1からの応答信号を受信したことを示してもよいし、所定のD2D捜索信号を送信したが応答信号を受信しなかったことを示しても良い。応答信号を受信した場合の捜索結果は、例えば、端末1の位置情報、応答信号を受信したときの端末2-2の位置情報、端末1の状況(行動可否、保持者の状態、電源残量、など)、など含んでもよい。応答信号を受信しなかった場合の捜索結果は、例えば、端末2-2の移動履歴、端末2-2からの発信回数、などを含んでも良い。
図10-Bは、第3の側面における他の端末2(e.g.端末2-1)の動作の一例を示すフロー図である。ステップ604までの動作は、図10-Aと同様のため省略する。
ステップ608では、他の端末2(e.g.端末2-1)は、端末2(e.g.端末2-2)から、D2D通信パスを介して捜索結果を受信する。
捜索結果は、端末1からの応答信号を受信したことを示してもよいし、所定のD2D捜索信号を送信したが応答信号を受信しなかったことを示しても良い。端末2(e.g.端末2-2)が応答信号を受信した場合の捜索結果は、例えば、端末1の位置情報、応答信号を受信したときの端末2-2の位置情報、端末1の状況(行動可否、保持者の状態、電源残量、など)、など含んでもよい。端末2(e.g.端末2-2)が応答信号を受信しなかった場合の捜索結果は、例えば、端末2-2の移動履歴、端末2-2からの発信回数、などを含んでも良い。
ステップ609では、他の端末2(e.g.端末2-1)は、制御装置3へ、複数の端末2(e.g.端末2-1および端末2-2)によるD2D通信を用いた端末1の捜索結果を送信し、フローを終了する。
制御装置3へ送信される捜索結果は、端末2(e.g.端末2-2)から送信された内容と同様であってもよい。また、捜索結果は、端末2(e.g.端末2-2)から送信された内容に加えて、他の端末2(e.g.端末2-1)の位置情報、他の端末2(e.g.端末2-1)の移動履歴などを含んでも良い。
複数の端末2を用いて端末1を捜索する第3の側面の構成によれば、端末2が単体で端末1を捜索するより、効率的に捜索を行うことができるようになる。また、D2D中継通信を用いることで、端末2単体では捜索できない領域の捜索もできるようになる。
<本明細書の開示におけるその他の側面>
上述の開示における、位置推定の精度向上、および各対策手段の捜索精度向上について説明する。
図14は、上述の開示において、制御装置3が取得した、端末1の加速度情報の傾向を分析した場合の一例である。例えば、出勤や通学等の時間帯は、端末1を所有する所有者及びその端末1自体の動きも大きくなるため、横軸に示す加速度値も比較的大きな値でばらつきも大きな傾向となる。また夜間であれば在宅で就寝中の為に、加速度値は非常に小さな値でばらつきの少ない傾向となる。年齢や、性別、職業、天候、季節によっても傾向は変わる。子供であれば、昼間の在学中は、必然的に授業と休憩時間に応じた動きのサイクルとなり、夜間は就寝する為、動きが無くなる。また老人であれば、全体的に動きが小さくなる。移動は歩行程度で時間帯は昼間が多く、それ以外は在宅となるので、動きは小さい。また端末1が盗難等によって、所有者が変わった場合は、傾向が大きく変わる。
上述したような属性ごとの傾向を、予めパターンデータとして保有し、収集した端末1の加速度情報と比較分析を行うことで、推定する位置の精度を向上させることができる。端末1の加速度情報とパターンデータとの差分量がある閾値よりも大きく、その回数が閾値回数よりも大きくなった場合は、異常ありと判断してもよい。また端末1の管理者へ異常ありと判断したことを通報してもよい。また、このパターンデータは、本端末自体の過去の情報とする事も可能である。これにより、過去と異なる動きの情報となった場合は、異常ありと判断する事も可能となる。
図15は、上述の傾向分析を、加速度情報と同様に位置情報に対して行った一例である。位置情報は、その前後の情報から移動距離に置き換える事で、絶対値に換算する。この移動距離情報は、加速度情報と同様に、年齢や、性別、職業、天候、季節によって傾向が変化する。例えば子供であれば、平日は学校、塾、自宅の間付近の位置を取る。通学の際にバスや電車での移動手段を用いる場合は、反映された傾向が表れる。位置情報であれば、加速度センサで測定できない車両による移動の情報も、位置情報の変化により取得が可能となる。
上述したような属性ごとの傾向を、予めパターンデータとして保有し、収集した端末1の位置情報と比較分析を行うことで、推定する位置の精度を向上させることができる。端末1の位置情報とパターンデータとの差分量がある閾値よりも大きく、その回数が閾値回数よりも大きくなった場合は、異常ありと判断してもよい。また端末1の管理者へ異常ありと判断したことを通報してもよい。また、このパターンデータは、本端末自体の過去の情報とする事も可能である。これにより、過去と異なる動きの情報となった場合は、異常ありと判断する事も可能となる。
また、加速度情報、位置情報のそれぞれで分析する例を述べたが、それぞれを組み合わせて分析してもよい。両者による分析において同時に異常と判定された場合は、更に盗難の確度が高まる為、該当端末でのサービス利用を禁止する等の、応用も可能となる。
最後に、本明細書の開示にかかる端末1、端末2(端末2-1、2-2、2-3、2-4)及び制御装置3の構成例について説明する。
図11は、本明細書の開示にかかる端末1の構成を示すブロック図である。端末2(端末2-1、2-2、2-3、2-4)についても同じ構成を有しても良い。
ワイヤレストランシーバ1101は、Radio Frequency(RF)トランシーバと、アンテナから構成されても良い。RFトランシーバは、PLMN内の基地局装置と通信するためにアナログRF信号処理を行う。RFトランシーバは、さらに、端末間のProSeダイレクト・ディスカバリ及びダイレクト通信のために使用されてもよい。RFトランシーバは、PLMN内の基地局装置との通信に使用される第1のトランシーバと、他の端末(e.g., 端末2など)とのD2D通信に使用される第2のトランシーバを含んでもよい。RFトランシーバにより行われるアナログRF信号処理は、周波数アップコンバージョン、周波数ダウンコンバージョン、及び増幅を含む。RFトランシーバは、アンテナ及びベースバンドプロセッサと結合される。すなわち、RFトランシーバは、変調シンボルデータ(又はOFDMシンボルデータ)をベースバンドプロセッサから受信し、送信RF信号を生成し、送信RF信号をアンテナに供給する。また、RFトランシーバは、アンテナによって受信された受信RF信号に基づいてベースバンド受信信号を生成し、これをベースバンドプロセッサ1102に供給する。
ベースバンドプロセッサ1102は、無線通信のためのデジタルベースバンド信号処理(データプレーン処理)とコントロールプレーン処理を行う。デジタルベースバンド信号処理は、(a) データ圧縮/復元、(b) データのセグメンテーション/コンカテネーション、(c) 伝送フォーマット(伝送フレーム)の生成/分解、(d) 伝送路符号化/復号、(e) 変調(シンボルマッピング)/復調、(f) 拡散/逆拡散、及び(g) Inverse Fast Fourier Transform(IFFT)によるOFDMシンボルデータ(ベースバンドOFDM信号)の生成などを含む。一方、コントロールプレーン処理は、レイヤ1(e.g., 送信電力制御)、レイヤ2(e.g., 無線リソース管理、及びhybrid automatic repeat request(HARQ)処理)、及びレイヤ3(e.g., アタッチ、モビリティ、及び通話管理に関するシグナリング)の通信管理を含む。
ベースバンドプロセッサ1102は、デジタルベースバンド信号処理を行うモデム・プロセッサ(e.g., Digital Signal Processor(DSP))とコントロールプレーン処理を行うプロトコルスタック・プロセッサ(e.g., Central Processing Unit(CPU)、又はMicro Processing Unit(MPU))を含んでもよい。この場合、コントロールプレーン処理を行うプロトコルスタック・プロセッサは、後述するアプリケーションプロセッサ1103と共通化されてもよい。
アプリケーションプロセッサ1103は、CPU、MPU、マイクロプロセッサ、又はプロセッサコアとも呼ばれる。アプリケーションプロセッサ1103は、複数のプロセッサ(複数のプロセッサコア)を含んでもよい。アプリケーションプロセッサ1103は、メモリ1105又は図示されていないメモリから読み出されたシステムソフトウェアプログラム(Operating System(OS))及び様々なアプリケーションプログラム(例えば、通話アプリケーション、WEBブラウザ、メーラ、カメラ操作アプリケーション、音楽再生アプリケーション)を実行することによって、端末1の各種機能を実現する。
いくつかの実装において、図に破線で示されているように、ベースバンドプロセッサ1102及びアプリケーションプロセッサ1103は、1つのチップ上に集積されてもよい。言い換えると、ベースバンドプロセッサ1102及びアプリケーションプロセッサ1103は、1つのSystem on Chip(SoC)デバイス1104として実装されてもよい。SoCデバイスは、システムLarge Scale Integration(LSI)またはチップセットと呼ばれることもある。
メモリ1105は、揮発性メモリ若しくは不揮発性メモリ又はこれらの組合せである。メモリ1105は、物理的に独立した複数のメモリデバイスを含んでもよい。揮発性メモリは、例えば、SRAM若しくはDRAM又はこれらの組み合わせである。不揮発性メモリは、例えば、MROM、PROM、フラッシュメモリ、若しくはハードディスクドライブ、又はこれらの組合せである。例えば、メモリ1105は、ベースバンドプロセッサ1102、アプリケーションプロセッサ1103、及びSoCからアクセス可能な外部メモリデバイスを含んでもよい。メモリ1105は、ベースバンドプロセッサ1102内、アプリケーションプロセッサ1103内、又はSoC1104内に集積された内蔵メモリデバイスを含んでもよい。さらに、メモリ1105は、UICC内のメモリを含んでもよい。
メモリ1105は、通信用モジュールを格納する。既に説明したようにメモリは、物理的に独立した複数のメモリデバイスを含んでもよく、ソフトウェア及びデータは、同じメモリデバイスに格納されてもよいし、異なるメモリデバイスに格納されてもよい。
通信用モジュールは、ベースバンドプロセッサ1102又はアプリケーションプロセッサ1103により実行されるソフトウェアモジュールを含む。これにより、ベースバンドプロセッサ1102又はアプリケーションプロセッサ1103は、制御装置3、や基地局装置と通信する。
さらに、通信用モジュールは、本明細書の開示においてシーケンス図およびフローチャートを用いて説明された端末1、2の処理を行うための命令群およびデータを含む。これにより、ベースバンドプロセッサ1102又はアプリケーションプロセッサ1103は、通信用モジュールを含むソフトウェアモジュール群をメモリから読み出して実行することで、本明細書の開示で説明された処理を行うことができる。
本明細書における、端末、ユーザー端末(User Equipment、 UE)(もしくは移動局(mobile station)、移動端末(mobile terminal)、 モバイルデバイス(mobile device)、または無線端末(wireless device)などを含む)は、無線インターフェースを介して、ネットワークに接続されたエンティティである。
本明細書のUEは、専用の通信装置に限定されるものではなく、本明細書中に記載されたUEとしての通信機能を有する次のような任意の機器であっても良い。
用語として「(3GPPで使われる単語としての)ユーザー端末(User Equipment、UE)」、「移動局」、「移動端末」、「モバイルデバイス」、「無線端末」のそれぞれは、一般的に互いに同義であることを意図しており、ターミナル、携帯電話、スマートフォン、タブレット、セルラIoT端末、IoTデバイス、などのスタンドアローン移動局であってもよい。
なお用語としての「UE」「無線端末」は、長期間にわたって静止している装置も包含することが理解されよう。
またUEは、例えば、生産設備・製造設備および/またはエネルギー関連機械(一例として、ボイラー、機関、タービン、ソーラーパネル、風力発電機、水力発電機、火力発電機、原子力発電機、蓄電池、原子力システム、原子力関連機器、重電機器、真空ポンプなどを含むポンプ、圧縮機、ファン、送風機、油圧機器、空気圧機器、金属加工機械、マニピュレータ、ロボット、ロボット応用システム、工具、金型、ロール、搬送装置、昇降装置、貨物取扱装置、繊維機械、縫製機械、印刷機、印刷関連機械、紙工機械、化学機械、鉱山機械、鉱山関連機械、建設機械、建設関連機械、農業用機械および/または器具、林業用機械および/または器具、漁業用機械および/または器具、安全および/または環境保全器具、トラクター、軸受、精密ベアリング、チェーン、歯車(ギアー)、動力伝動装置、潤滑装置、弁、管継手、および/または上記で述べた任意の機器又は機械のアプリケーションシステムなど)であっても良い。
またUEは、例えば、輸送用装置(一例として、車両、自動車、二輪自動車、自転車、列車、バス、リヤカー、人力車、船舶(ship and other watercraft)、飛行機、ロケット、人工衛星、ドローン、気球など)であっても良い。
またUEは、例えば、情報通信用装置(一例として、電子計算機及び関連装置、通信装置及び関連装置、電子部品など)であっても良い。
またUEは、例えば、冷凍機、冷凍機応用製品および装置、商業およびサービス用機器、自動販売機、自動サービス機、事務用機械及び装置、民生用電気・電子機械器具(一例として音声機器、スピーカー、ラジオ、映像機器、テレビ、オーブンレンジ、炊飯器、コーヒーメーカー、食洗機、洗濯機、乾燥機、扇風機、換気扇及び関連製品、掃除機など)であっても良い。
またUEは、例えば、電子応用システムまたは電子応用装置(一例として、X線装置、粒子加速装置、放射性物質応用装置、音波応用装置、電磁応用装置、電力応用装置など)であっても良い。
またUEは、例えば、電球、照明、計量機、分析機器、試験機及び計測機械(一例として、煙報知器、対人警報センサ、動きセンサ、無線タグなど)、時計(watchまたはclock)、理化学機械、光学機械、医療用機器および/または医療用システム、武器、利器工匠具、または手道具などであってもよい。
またUEは、例えば、無線通信機能を備えたパーソナルデジタルアシスタントまたは装置(一例として、無線カードや無線モジュールなどを取り付けられる、もしくは挿入するよう構成された電子装置(例えば、パーソナルコンピュータや電子計測器など))であっても良い。
またUEは、例えば、有線や無線通信技術を使用した「あらゆるモノのインターネット(IoT:Internet of Things)」において、以下のアプリケーション、サービス、ソリューションを提供する装置またはその一部であっても良い。
IoTデバイス(もしくはモノ)は、デバイスが互いに、および他の通信デバイスとの間で、データ収集およびデータ交換することを可能にする適切な電子機器、ソフトウェア、センサー、ネットワーク接続、などを備える。
またIoTデバイスは、内部メモリの格納されたソフトウェア指令に従う自動化された機器であっても良い。
またIoTデバイスは、人間による監督または対応を必要とすることなく動作しても良い。
またIoTデバイスは、長期間にわたって備え付けられている装置および/または、長期間に渡って非活性状態(inactive)状態のままであっても良い。
またIoTデバイスは、据え置き型な装置の一部として実装され得る。IoTデバイスは、非据え置き型の装置(例えば車両など)に埋め込まれ得る、または監視される/追跡される動物や人に取り付けられ得る。
人間の入力による制御またはメモリに格納されるソフトウェア命令、に関係なくデータを送受信する通信ネットワークに接続することができる、任意の通信デバイス上に、IoT技術が実装できることは理解されよう。
IoTデバイスが、機械型通信(Machine Type Communication、MTC)デバイス、またはマシンツーマシン(Machine to Machine、M2M)通信デバイス、NB-IoT(Narrow Band-IoT) UEと呼ばれることもあるのは理解されよう。
またUEが、1つまたは複数のIoTまたはMTCアプリケーションをサポートすることができることが理解されよう。
MTCアプリケーションのいくつかの例は、以下の表(出典:3GPP TS22.368 V13.2.0(2017-01-13) Annex B、その内容は参照により本明細書に組み込まれる)に列挙されている。このリストは、網羅的ではなく、一例としてのMTCアプリケーションを示すものである。
アプリケーション、サービス、ソリューションは、一例として、MVNO(Mobile Virtual Network Operator:仮想移動体通信事業者)サービス/システム、防災無線サービス/システム、構内無線電話(PBX(Private Branch eXchange:構内交換機))サービス/システム、PHS/デジタルコードレス電話サービス/システム、POS(Point of sale)システム、広告発信サービス/システム、マルチキャスト(MBMS(Multimedia Broadcast and Multicast Service))サービス/システム、V2X(Vehicle to Everything:車車間通信および路車間・歩車間通信)サービス/システム、列車内移動無線サービス/システム、位置情報関連サービス/システム、災害/緊急時無線通信サービス/システム、IoT(Internet of Things:モノのインターネット)サービス/システム、コミュニティーサービス/システム、映像配信サービス/システム、Femtoセル応用サービス/システム、VoLTE(Voice over LTE)サービス/システム、無線TAGサービス/システム、課金サービス/システム、ラジオオンデマンドサービス/システム、ローミングサービス/システム、ユーザー行動監視サービス/システム、通信キャリア/通信NW選択サービス/システム、機能制限サービス/システム、PoC(Proof of Concept)サービス/システム、端末向け個人情報管理サービス/システム、端末向け表示・映像サービス/システム、端末向け非通信サービス/システム、アドホックNW/DTN(Delay Tolerant Networking)サービス/システムなどであっても良い。
なお、上述したUEのカテゴリは、本明細書に記載された技術思想及び側面の応用例に過ぎない。これらの例に限定されるものではなく、当業者は種々の変更が可能であることは勿論である。
図12は、本明細書の開示にかかる制御装置3の構成を示すブロック図である。制御装置3は、ネットワークインターフェース1201、プロセッサ1202、及びメモリ1203を含む。
ネットワークインターフェース1201は、端末1、2と通信するために使用される。ネットワークインターフェース1201は、例えば、IEEE802.3シリーズに準拠したネットワークインターフェースカード(NIC)を含んでも良い。
プロセッサ1202は、メモリ1203からソフトウェア(コンピュータプログラム)を読み出して実行することで、上述の側面においてシーケンス図およびフローチャートを用いて説明された制御装置3の処理を行う。プロセッサ1202は、例えば、マイクロプロセッサ、MPU、又はCPUであってもよい。プロセッサ1202は、複数のプロセッサを含んでも良い。
メモリ1203は、揮発性メモリ及び不揮発性メモリの組み合わせによって構成される。メモリ1203は、プロセッサから離れて配置されたストレージを含んでも良い。この場合、プロセッサ1202は、図示されていないI/Oインターフェースを介してメモリ1203にアクセスしても良い。
図の例では、メモリ1203は、制御装置3の動作を行うためのソフトウェアモジュール群を格納するために使用される。ソフトウェアモジュールは、本明細書の開示において説明された制御装置3の処理(例えば、端末1から位置情報と加速度情報を受信する処理、端末1へ捜索信号を送信する処理、端末2へ捜索依頼を送信する処理など)を実行するための命令群およびデータを含む。プロセッサ1202は、ソフトウェアモジュールを含む、ソフトウェアモジュール群をメモリ1203から読み出して実行することで、本明細書の開示において説明された制御装置3の処理を行うことができる。
図を用いて説明したように、上述の開示に係る端末1、2(2-1,2-2、2-3、2-4)、及び制御装置3が有するプロセッサの各々は、図面を用いて説明されたアルゴリズムをコンピュータに行わせるための命令群を含む1又は複数のプログラムを実行する。このプログラムは、様々なタイプの非一時的なコンピュータ可読媒体(non-transitory computer readable medium)を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体(tangible storage medium)を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体(例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ)、光磁気記録媒体(例えば光磁気ディスク)、Compact Disc Read Only Memory(CD-ROM)、CD-R、CD-R/W、半導体メモリ(例えば、マスクROM、Programmable ROM(PROM)、Erasable PROM(EPROM)、フラッシュROM、Random Access Memory(RAM))を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体(transitory computer readable medium)によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。
上述の各側面は、各々独立に実施されてもよいし、適宜組み合わせて実施されてもよい。
上述の各側面は、制御装置3がインターネット上に配置された例を示した。しかしながら、制御装置3は、PLMN内のノード(例えば、基地局、モビリティ管理装置、又は加入者管理装置など)に配置されても良い。
さらに、上述した各側面は本件発明者により得られた技術思想の適用に関する例に過ぎない。すなわち、当該技術思想は、上述した各側面のみに限定されるものではなく、種々の変更が可能であることは勿論である。
例えば、上記の各側面の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。
(付記1.)
制御装置で行われる通信方法であって、
第1の端末から、第1のタイミングにおける第1の端末の第1の位置情報と加速度情報とを受信し、
前記第1の端末へ、応答信号を要求する第1の捜索信号を送信し、
前記捜索信号に対する応答信号がないと判断した場合、
前記第1の位置情報と前記加速度情報とを用いて第2のタイミングにおける前記第1の端末の第2の位置情報を推定し、
位置と当該位置における第1の通信確率とに基づいて、前記第2の位置情報に対応する第2の通信確率を決定し、
前記第2の通信確率に対応する、前記第1の端末を捜索するための対策手段を示す情報を出力する、
通信方法。
(付記2.)
前記対策手段は、Device to Device (D2D)通信を用いた第2の捜索信号を前記第1の端末へ送信する少なくとも1以上の第2の端末へ、前記第1の端末を捜索することを要求する捜索依頼を送信すること、を含む
付記1に記載の通信方法。
(付記3.)
前記捜索依頼に対して許諾を示す内容の応答信号である許諾応答を、少なくとも1以上の前記第2の端末であるD2D端末から受信し、
前記第2の捜索信号を送信する領域を示す捜索情報を、前記D2D端末へ送信する、
付記2に記載の通信方法。
(付記4.)
前記領域で送信された前記第2の捜索信号に対する応答の受信結果を含む捜索結果情報を、前記D2D端末から受信し、
受信した捜索結果情報を出力する、
付記3に記載の通信方法。
(付記5.)
前記領域は、前記第2の通信確率に基づいて生成される、
付記3または4に記載の通信方法。
(付記6.)
複数の前記第2の端末から前記許諾応答を受信した場合、
複数の前記許諾応答にそれぞれ含まれる前記複数の前記第2の端末の属性に基づいて前記捜索情報のそれぞれが示す領域が重複しないように当該捜索情報を生成する、
付記3~5のいずれか1項に記載の通信方法。
(付記7.)
前記D2D端末のうち少なくとも1つの第2の端末から、前記第2の捜索信号に対する前記第1の端末からの応答内容を示す捜索結果を受信した場合、
前記D2D端末のうちの前記第2の端末とは他の少なくとも1つの第2の端末へ前記捜索結果を送信する、
付記4~6のいずれか1項に記載の通信方法。
(付記8.)
前記第2の通信確率が高いと判定された場合、
捜索を行う団体へ、前記第1の端末の捜索依頼を送信する、
付記1~7のいずれか1項に記載の通信方法。
(付記9.)
前記第2の通信確率が、低いと判定されずかつ高いと判定されない場合、
前記第1の捜索信号を前記第1の端末へ再送する、
付記1~8のいずれか1項に記載の通信方法。
(付記10.)
前記第2の通信確率が低いと判定されさらに前記第2の位置情報が示す位置上に人間がアクセス可能な経路がないと判断した場合、
前記第2の端末としてドローンを用いた端末を指定する、
付記2~9のいずれか1項に記載の通信方法。
(付記11.)
制御装置であって、
第1の端末から、第1のタイミングにおける第1の端末の第1の位置情報と加速度情報とを受信する受信部と、
前記第1の端末へ、応答を要求する第1の捜索信号を送信する送信部と、
ここで前記捜索信号に対する応答がないと判断した場合、
前記第1の位置情報と前記加速度情報とを用いて第2のタイミングにおける前記第1の端末の第2の位置情報を推定する推定部と、
位置と当該位置における第1の通信確率とに基づいて、前記第2の位置情報に対応する第2の通信確率を決定する決定部、
前記第2の通信確率に対応する対策手段を示す情報を出力する出力部、
を備える制御装置。
(付記12.)
前記対策手段は、Device to Device (D2D)通信を用いた第2の捜索信号を前記第1の端末へ送信する少なくとも1以上の第2の端末へ、前記第1の端末を捜索することを要求する捜索依頼を送信する、ことを含む
付記11に記載の制御装置。
(付記13.)
前記受信部はさらに、前記捜索依頼に対して許諾を示す内容の応答信号である許諾応答を、少なくとも1以上の前記第2の端末であるD2D端末から受信するよう構成され、
前記送信部はさらに、前記第2の捜索信号を送信する領域を示す捜索情報を、前記D2D端末へ送信するよう構成された、
付記12に記載の制御装置。
(付記14.)
前記受信部はさらに、前記領域で送信された前記第2の捜索信号に対する応答の受信結果を含む捜索結果情報を、前記D2D端末から受信するよう構成され、
前記出力部はさらに、受信した捜索結果情報を出力するよう構成された、
付記13に記載の制御装置。
(付記15.)
前記領域は、前記第2の通信確率に基づいて生成される、
付記13または14に記載の制御装置。
(付記16.)
複数の前記第2の端末から前記許諾応答を受信した場合、
複数の前記許諾応答にそれぞれ含まれる前記複数の前記第2の端末の属性に基づいて前記捜索情報のそれぞれが示す領域が重複しないように当該捜索情報を生成する、
付記13~15のいずれか1項に記載の制御装置。
(付記17.)
前記D2D端末のうち少なくとも1つの第2の端末から、前記第2の捜索信号に対する前記第1の端末からの応答内容を示す捜索結果を受信した場合、
前記送信部はさらに、前記D2D端末のうちの前記第2の端末とは他の少なくとも1つの第2の端末へ前記捜索結果を送信するよう構成された、
付記14~16のいずれか1項に記載の制御装置。
(付記18.)
前記第2の通信確率が高いと判定された場合、
前記送信部はさらに、捜索を行う団体へ、前記第1の端末の捜索依頼を送信するよう構成された、
付記11~17のいずれか1項に記載の制御装置。
(付記19.)
前記第2の通信確率が、低いと判定されずかつ高いと判定されない場合、
前記送信部はさらに、前記第1の捜索信号を前記第1の端末へ再送するよう構成された、
付記11~18のいずれか1項に記載の制御装置。
(付記20.)
前記第2の通信確率が低いと判定され、さらに前記第2の位置情報が示す位置上に人間がアクセス可能な経路がないと判断した場合、
前記第2の端末としてドローンを用いた端末を指定する、
付記12~19のいずれか1項に記載の制御装置。