通信被害時における人口集中地区での被災者間情報共有手法に関する研究
代表研究者

樫原 茂

奈良先端科学技術大学院大学情報科学研究科 助教

1 はじめに災害発生時、特に発災後 72 時間は人命救助において重要な時間となる。そのため、災害発生時には、被災地の現状（被災者の情報や建物や道路の損壊等）を迅速に把握することが求められる。一方、被災者においても避難時の所持品の割合として、「携帯電話（76.9 %）」がトップであり、「財布・重要書類（70.7 %）」を上回っている[1]。しかし、携帯電話を所持しても、基地局の倒壊等が発生した場合、通信サービスが停止するため、携帯電話を用いた救助要請を行うことができない。また、基地局が倒壊していなくても、通信規制により通話による救助要請を行うことは困難である。このような状況において、救助の必要な被災者の情報を少しでも多く迅速に収集することが求められる。
東日本大震災においては、Twitter 等のソーシャルメディアのアプリケーションが情報伝達に役立ったとの報告もあるが、基地局の倒壊等により通信被害が発生した地域においては、情報の発信・受信は不可能である。また、発災直後に、通信被害地域に移動基地局を配置することは、被害状況が明らかとなっていない
状況下では、安全性、人的資源、移動基地局の台数の限界等により難しい。そのため、携帯電話を所持していても有効に活用できない可能性が高い。
これまで、我々はこのような通信被害地域において、共助・公助による人命救助につながるための情報収集及び提供を行うための方法として、Delay/Disruption Tolerant Network（DTN）の概念に基づいたスマー
トフォンアプリケーション（SOSCast）を提案し、実装した。SOSCast では、携帯電話の中でもスマートフォンを対象に、スマートフォン間で救助要請メッセージ（SOS メッセージ）を伝搬させ、それらの情報を収集できる。
本研究では、これまでに提案した SOSCast を発展させるために、通信被害が発生した人口集中地区において、救助活動に必要な情報を迅速に収集するために、既存の通信インフラに依存せずに、被災者情報収集手法について研究を実施した。本研究では、最初に情報収集効率を向上させるためには、スマートフォンの稼
働時間を延ばす必要があるため、スマートフォン間におけるオン・オフ制御によるバッテリ消費を考慮した通信方式の提案と評価に取り組んだ。また、災害時には、建物の倒壊などのため、人が近寄るには危険な場合がある。そのような、危険な場所に対して情報を収集するために、UAV(Unmanned Aerial Vehicle)を用いた上空からスマートフォンの検知に関しての提案と実験を行った。

2 Delay/Disruption Tolerant Network（DTN）
現在取り組んでいる研究は主に DTN の概念に基づいている。DTN は日本では遅延・切断耐性ネットワークとも呼ばれる。これまでの既存のネットワークと大きく異なる点は、エンドツーエンドのデータ通信を行うのではなく、ホップバイホップでデータ通信を行う点にある。そのため、データ配送において遅延や切断が発生する。また、このようなデータ転送方法は蓄積運搬型転送（Store-Carry-Forward routing scheme）と呼ばれている。DTN の研究が開始された背景や現状の動向については、文献[2,3]を参照されたい。
蓄積運搬型転送方式は、端末間において直接通信を行い、転送を繰り返すことで宛先へデータを届ける。
つまり、エンドツーエンドで通信可能なネットワークを構築しないため、時には他の端末と出会うまでデー
タを蓄積し、運搬することもある。その結果、宛先へのデータ到達率を 100％にすることが難しくなる。DTN
環境において、宛先へのデータの到達率を高めるために、これまでに数多くのルーティング手法が提案されてきている[4,5]。しかし、これらは主に理論解析やシミュレーションによる結果であり、実際の災害時の環境に当てはめた評価はあまり行われていない。災害の種類や地形等によって、端末の移動モデルが異なるため、実際にどのルーティング手法が有効であるかについても、理論解析やシミュレーションから明らかになった特性をもとに、今後調査していく必要がある。
DTN では、従来の TCP/IP 技術を前提とし、それを拡張することで蓄積運搬型転送を実現している。そのため、エンド間の端末において、遅延や切断を許容可能な通信を実現するために、アプリケーション層とトラ

1
電気通信普及財団 研究調査報告書

ンスポート層の間にバンドル層と呼ばれる新しい層を提供し、バンドル層が蓄積運搬型転送の制御を行う。
DTN 全体およびバンドル層においては、Internet Re-search Task Force（IRTF）の研究グループである
Delay-Tolerant Networking Research Group（DTNRG）[6]によって議論されている。
DTN ではバンドル層を設けることでアプリケーション毎に独自プロトコルを開発する労力の削減と相互運用を目的に提案されてきたが、実際には DTN のプロトコルを使用せずに、蓄積運搬型転送の概念のみを適用
したアプリケーションの開発が行われている。このような独自プロトコルの開発が行われる理由としては、
現状の DTN 実装が想定しているアプリケーションには不必要な機能（様々なルーティング手法）などがあり、DTN の標準化で考えられている機能を理解して実装するよりも、必要な機能だけをアプリケーション上で簡単に実現できる点と、スマートフォンの OS に DTN 自体がまだ搭載されていない点があげられる。

3 通信被害地域での情報収集手法
これまで我々は、情報通信技術、特にモバイルネットワーク技術を減災に役立てるために、建物の損壊や怪我のために避難できなく救助が必要な被災者（以下、要救助者と呼ぶ）の SOS メッセージを伝搬・収集するためのスマートフォンアプリケーションとして、SOSCast を提案し、研究を継続している[7-14]。
SOSCast では、スマートフォンのアプリケーションとして、端末間の直接通信により、要救助者の SOS メ
ッセージを伝搬する。その結果、収集された SOS メッセージをもとに、救助が可能な人がその情報を参考に
要救助者の救助に向かえることを目的としている。つまり、共助（地域で協力する）及び公助（警察や消防による対応）がより迅速に行われるための情報の収集及び提供を行う。
SOSCast の動作概要を図 1 に示す。初期のプロトタイプとして作成した SOSCast[7-10]では、要救助者の端末が Bluetooth デバイスを用いて、近隣を移動する被災者（A, B, C）の端末に対して自動的に SOS メッセー
ジを送信する。そして、被災者の各端末は、SOS メッセージを受信すると GPS により自身の位置情報を取得
し、受信した SOS メッセージに位置情報を付加する。そして、その付加した SOS メッセージを保存するとともに、要救助者端末にも返送する。このように受信した SOS メッセージに受信位置の情報を付加して要救助者に返送することで、要救助者は受信者の位置情報も含めて、次に通信する端末にも渡すことができる。つまり、単にデータを蓄積するだけでなく、通信毎に得た新たな情報を加工し付加していくことで、より多くの有用な情報を一度に伝搬・収集することが可能となる。また、避難者端末同士や避難者と救助者の端末間においても、自身が保持しているデータを自動で互いに交換し共有することで、効率的に要救助者の SOS メ
ッセージを拡散・収集することができる。一方、救助者は、自身の端末が保持しているデータを見ることで、どの辺りに要救助者がいるかを推測することが可能となる。このように、SOSCast では、単にエピデミック
ルーティングのように拡散させるだけでなく、新たな情報を付加し、共有しながら拡散させることで迅速な情報収集へつなげることができる。

図 １ SOSCast の動作概要
上述した SOSCast のプロトタイプを作成し、評価を行うことで、実装上での問題点が明らかとなった。プ
ロトタイプでは、比較的少ない要救助者を想定した場合は、通信時間に余裕を持って情報収集を行うことができるが、都市部のように人口が多い環境においては、コネクション接続時間と通信時間により、要救助者
すべての SOS メッセージを収集することは難しくなる。例えば、図 2 に示すように、要救助者 A から E が集まった状況で、被災者の端末が要救助者の端末を発見し、SOS メッセージを収集すると仮定する。このとき、

2
電気通信普及財団 研究調査報告書

最初に被災者端末が要救助者 A の端末と Bluetooth デバイスを用いて通信している間に、被災者は移動を続ける。そして、要救助者 A との通信終了後、被災者端末は要救助者 E の端末と通信を開始するかもしれない。
その結果、要救助者 B, C, D の SOS メッセージは収集されない。本アプリケーションでは、SOS メッセージの収集は自動で行われるが、端末間でピアデバイス探索を行い、コネクションを確立し、データ転送を終了するまでに時間を要する。また、文献[1]の調査結果でも述べられているように、被災者は端末のバッテリ消費に関して不安を持っているため、省電力なアプリケーションであることも望まれる。

図 ２ SOS メッセージの収集時の問題
そこで、文献[11,12]では、このような要救助者が密集した環境を対象に、SOS メッセージの収集効率を改善し、更にバッテリ消費量の削減を行うための手法の提案を行った。提案手法では、まず、各端末の通信回数を削減することでバッテリ消費量の削減を行う。そのため、図 3 に示すように、要救助者群の各端末は、
１ホップ内でバッテリ残量が最も多い端末（自端末も含む）を代表者として推薦し、クラスタを構築する。
そして、１ホップ内の代表者に自身の SOS メッセージを送信し、代表者は周辺端末の SOS メッセージを保持する。仮に、被災者端末が代表者端末以外の要救助者端末を発見しても、発見された要救助者端末は代表者
端末から保持している情報を送信してもらい、それを被災者端末に転送することができる。そのため、どの要救助者端末と通信しても情報を収集可能である。また、図 3 では 1 つのクラスタの例であるが、どれか一つの端末でも通信可能な別クラスタが存在する場合は、代表者間で情報共有を行う。そうすることで、要救助者群内で情報が効率的に拡散される。その結果、各端末の通信回数が削減され、結果として、仮想的に伝搬可能範囲も拡大される。このようなクラスタ構築による利点を下記にまとめる。
(1)
全端末間で SOS メッセージを共有するのではなく、代表者に情報を集めることで代表者端末以外の通信回数を削減し、バッテリ消費の削減につながる。なお、代表者は定期的に変更可能である。
(2)
クラスタ構築により、要救助者群の１つの端末と通信するだけで、要救助者群のすべての SOS メッ
セージを収集する可能となる。つまり、仮想的に一端末の伝搬可能範囲が拡大する効果が得られる。
(3)
要救助者群の SOS メッセージは代表者において保持されるため、ある端末のバッテリが尽きたとしても、その端末の情報は要救助者群すべての端末のバッテリがつきるまで保持される。
このように、１対１で通信を行うのではなく、複数の端末が協調し、情報を集約することで、効率よく情報を収集できる可能性が高まる。

図 ３ 伝搬可能範囲の拡大
文献[13]では、400 台の要救助者端末群を想定し、シミュレーションにより有効性の評価を行った。その3
電気通信普及財団 研究調査報告書

結果、初期のプロトタイプよりも通信回数が削減されることが明らかとなった。しかし、バッテリ消費量の削減に関しては、限定的な向上にとどまった。限定的な向上に留まった原因としては、通信回数自体によるバッテリ消費はそれほど大きくなく、通信デバイスがオンになっていることの方がバッテリ消費に大きく影響していることが明らかとなった。
そこで、本研究では、通信デバイスのオン・オフ制御によるバッテリ消費を削減するための方式提案を行い、評価を行った。図 4 に本方式の全体像を示す。以前の方式においては、クラスタを構築して、情報共有を行った。本方式においても、前方式と同様にクラスタを構築して情報共有を行う。異なる点としては、位置が近い端末同士で近接クラスタを構築する点にある。ここでの位置が近いとは電波強度の強さがほとんど同じ強さ、つまり数 m 程度の範囲内に存在する端末間のクラスタを構築する。そして、その構築されたクラスタ内で代表者を決定し、情報を集約する。そのあとは、これまでの方式と同様に代表者間クラスタにより情報共有を行う。つまり、２階層でのクラスタの構築を行う。

図 ４ 提案方式におけるクラスタ構築
近接クラスタの構築方法について説明する。図 5 に示すように、各端末は近距離端末の探索を行い、バッ
テリ残量が多い端末を近接クラスタ内代表者として推薦 (自分のバッテリ残量が最大の場合は自薦)する。そして、近接クラスタ内代表者は近接クラスタを構築し、代表者はクラスタ内の情報を収集する。

図 ５ 近接クラスタの構築
クラスタ構築後、クラスタ内の端末全てが通信する必要はないため、代表者は無線デバイスをオフにする
端末と時間を決定し、オフを通知された要救助者の端末は無線デバイスをオフにする。そして、指定時間経過後、オンに戻し、代表者へ報告する。残りのバッッテリ残量の大きさの関係が変更した際は、代表者を再度決定し、オフにする端末と時間を決定する。この処理を繰り返すことにより、端末の稼働時間を延ばすことが可能となる。

4
電気通信普及財団 研究調査報告書

図 ６ クラスタ内でのオン/オフ制御
本方式の有効性を評価するためにシミュレーション実験を行った。図 7 にシミュレーションモデルとシ
ミュレーションパラメタを示す。本シミュレーションでは、500m×500m の範囲で、要救助者端末を 1,000 から 10,000 台をランダムに配置し、本方式による稼働時間を評価した。また、各端末のバッテリ残量は 50 から 100%の間で位置分布に従ってランダムに割り当てた。Wi-Fi に関するパラメタは文献[14]を参照した。

図 ７ シミュレーションモデルとパラメタ
図 8 に端末数と稼働時間に関するシミュレーション結果を示す。結果より、エピデミック通信及びこれまでに提案した既存方式に比べ、提案方式は 20-30%ほど稼働時間が改善することが明らかになった。ただし、端末数が少ない環境においては、近接クラスタが作成できない可能性もあるため、他方式と比べての優位性
は小さくなる。このように、近接クラスタを構築することで、端末の稼働時間を改善することができ、その結果、SOS メッセージが転送される機会が増加する。

図 ８ 端末数と平均稼働時間の関係

5
電気通信普及財団 研究調査報告書

本研究において、残されている課題としては、理論的な問題だけでなく、実装時の各端末の OS の種類やバージョン等などの違いによる影響も数多く残されている。一方、このような災害時のアプリケーションでは、実際の使用を考慮した設計が必要となるため、文献[15]に示すように、ユーザインタフェースから自動制御などユーザフレンドリーな設計が重要となる。

4 UAV による上空からの情報収集
前節では、スマートフォン間による要救助者の SOS メッセージの情報収集手法について述べたが、実環境においては、建物の倒壊等の危険性もあるため、要救助者の情報収集が困難になることも想定される。そこで、現在急速に普及している UAV を利用して、人による情報収集が困難な地域に対して、上空から情報を収集する手法についての研究にも取り組んだ。
UAV は機動性にすぐれているため、上空からの現場の撮影を目的に自治体でも導入の検討が行われている[16]。しかし、現状での用途は空撮のみに限られている。そこで、我々は、空撮映像だけではなく、スマー
トフォンや既設のセンサからの情報を上空から取得し、映像で見えない情報を提供する方法についての研究を行った。しかし、UAV は使用する機体毎に飛行時間等の特性が異なるため、目的に適した UAV を用いることが重要である。現段階では、費用面から比較的容易に導入可能な AR.Drone2.0 を対象に実機を用いた基礎調査を行った。
我々が想定している罹災状況収集システムを図 9 に示す。本システムでは、発災直後からの救助活動における情報収集を行う。対象としては、消防局などの実際に救助活動を行う組織の使用を想定している。運用
手順においては、まず、①パソコンから UAV の飛行経路の設定、および UAV に搭載したセンサ機器の起動を行う。設定後、②UAV は自動飛行により、設定された上空を飛行する。③飛行中は上空からの映像とともに
Wi-Fi パケットを取得し、④対象エリア調査後、帰還する。そして、⑤UAV から映像とセンシングデータを収集し、⑥現場で状況確認を行う。もしくは、必要に応じて、⑦情報共有のため、取得データを災害情報対策
本部等の関係各所へ送る。なお、⑦に関しては、災害時にはネットワークを使用できない可能性も高く、その場合如何に情報を届けるかが重要となる。そのため、本研究では①から⑥までを対象とする。

図 ９ UAV を用いた情報収集
本システムでは、UAV によって収集した空撮映像と Wi-Fi パケット情報を提供する。本節では、これらの情報を収集するための仕組みについて説明する。図 10 に本システムの全体設計を示す。本システムでは、空撮映像と上空からの Wi-Fi パケットの取得を行うため、AR.Drone 2.0（以下, Drone とする）上に Raspberry
Pi B+（以下, Rasp Pi とする）を搭載した 。空撮映像は Drone に基本搭載されているカメラを用いて取得する。一方、Wi-Fi パケットの取得のために、Rasp Pi に USB Wi-Fi（Sony UWA-BR100）と USB GPS（Canmore
GT-730FL-SU）を搭載した。なお、GPS は Drone も別途飛行用に搭載しているが、Drone の GPS データを取得することで飛行への影響を与えることを防ぐために、Rasp Pi 用に別途 GPS を搭載した。
コントロール PC でのデータ収集について述べる。Drone は Wi-Fi 経由でアクセスでき、Drone 本体はアクセスポイント（Access Point: AP）として動作する。そのため、Rasp Pi に別途通信用の小型 USB Wi-Fi（BUFFALO
WLI-UC-GNM）を搭載し、Rasp Pi をステーション（Station: STA）として Drone（AP）に接続する。また、コントロール PC も STA として Drone に接続することで、 コントロール PC から Rasp Pi および Drone に接続することができ、Rasp Pi からは Wi-Fi パケットデータを、Drone からは空撮映像を収集できる。
そして、コントロール PC 上で収集したデータを処理し、Web サーバにそれらのデータを転送することで映像およびセンシング情報を Web ブラウザで確認できる。そのため、URL により取得した情報を関係各所で共

6
電気通信普及財団 研究調査報告書

有することが可能となる。

図 １０ 全体設計
次に、取得する情報とその情報処理について説明する。上述したように、Drone は空撮映像を、Rasp Pi
は Wi-Fi パケットを取得する。Drone に関しては、Drone の空撮機能により、離陸後から着陸までの映像がmp4 形式のファイルとして自動保存される。一方、Rasp Pi では、取得用の Wi-Fi デバイス（Sony UWA-BR100）を用いて、tcpdump により Wi-Fi から発せられるプローブリクエストのみのパケット（pcap ファイル）を取得する。また、地図上へマッピングのために、tcpdump の開始時刻と終了時刻を記録する。Rasp Pi には GPSも搭載しており、tcpdump の開始時刻と終了時刻から対応する GPS ログデータ（csv ファイル）を取得する。
つまり、Drone 上では mp4 ファイル、Rasp Pi 上では pcap ファイルと csv ファイルが作成される。
そして、Drone の帰還後、コントロール PC はそれら３つのファイルを収集する。収集後、コントロール PC
は収集データをもとに、Web ブラウザで表示可能なデータに処理する。特に、本システムでは、空撮映像とともに、映像からは検知が困難な要支援者の存在確認情報を表示することが重要となる。そこで、まず、使用者は要支援者のスマートフォンの Wi-Fi MAC アドレスを事前に入手しているため、Wi-Fi パケットの pcap
ファイルから対象の MAC アドレスからのプローブパケットを抽出する。そして、抽出したパケットと GPS ロ
グデータを使って、Google Map 上で表示可能な KML ファイルを作成する。
KML ファイル作成後、作成した KML ファイルと mp4 ファイルを Web サーバに送信し、Web からそれらの情報を確認できるようにする。なお、情報表示に Google Map を使用しているため、Web サーバはインターネットに接続している必要がある。
図 11 にデータ処理後の表示画面を示す。本表示画面は上空からの映像情報と、上空から取得した Wi-Fi
パケットキャプチャによる要支援者の存在確認の可能性を自治体向けに示すことを目的としているため、シンプルな作りにしている。

図 １１ 表示画面
左側の映像は実際に Drone で作成した上空からの映像（mp4 ファイル）を示しており、右側は Google Map
上に実際に飛行経路と、飛行経路上で取得した要支援者のスマートフォンの Wi-Fi プローブパケットの位置を示している。ここでは、電波強度をもとにプロットの色（赤＞黄）と変えている。なお、閾値を複数設けることでプロットの色を増やすことも可能である。また、ここでの複数のプロットは、複数のスマートフォ

7
電気通信普及財団 研究調査報告書

ンではなく、１台のスマートフォンから取得した位置をプロットしている。
上述したプロトタイプシステムを用いた奈良先端大内での実験について述べる。図 12 に奈良先端大でのDrone の自動飛行の設定画面を示す。図 12 に示すように、グラウンドを離発着ポイントとし、情報棟に沿って飛行し、同じ経路を戻ってくる飛行経路を設定した。なお、飛行高度は 20m とした。また、飛行経路上に要支援者の端末として、２台のスマートフォン（STA1: Samsung GT-I9300 と STA2: Google Nexus 7）を地面上に設置した。

図 １２ 飛行設定画面
図 12 に示した飛行経路を飛行して得られた結果を図 13、14 に示す。現在のシンプルな設計では、１画面に１端末の結果しか、表示できないため、それぞれの結果を別に示す。図 13、図 14 ともに、STA の設置場所付近でプローブリクエストを受信し、電波強度が強かったことがわかる。つまり、要支援者がスマートフォ
ン（あるいは Wi-Fi のプローブパケットを発する時計など）を保持しているとプローブパケットにより上空からセンシングすることも可能であることがわかる。

図 １３ STA1 の結果

8
電気通信普及財団 研究調査報告書

図 １４ STA2 の結果
一方、図 13 と図 14 において、プロット数が異なっている。これは、使用する STA の機種によって、プローブパケットの送出頻度が異なるためである。STA1 においては、約 30 秒毎（必ずしも 30 秒毎ではなく、30秒よりも短い場合も確認されている）にプローブパケットが送信され、STA2 においては約 10 秒毎（STA1 と同様に 10 秒よりも短い場合も確認されている）にプローブパケットが送信されているためである。また、今回の実験においては、百数十 m 間の範囲で STA を検知できている。しかし、実際の環境では、屋内を想定するため、検知可能範囲はより狭まるものと考えられる。

2 おわりに
本研究では、罹災地において、特に発災直後から 72 時間にかけて、迅速な人命救助につながるための情報収集を目的に、スマートフォンを用いた SOSCast アプリケーションと、現在新たに取り組んでいる UAV を用いた情報収集手法に関して取り組んだ。現在の研究を実際の利用につなげるためには、技術課題も多く残されているが、より重要な問題としては、それを使用する実際の被災者や自治体等を考慮した設計が重要となる。今後、利用者や自治体等と協力して、研究を進める。最後に、本研究を助成して頂いた貴財団の研究調査助成事業に心より感謝の意を表する。

【参考文献】[1] 本條晴一郎, 遊橋裕泰, "災害に強い情報社会 – 東日本大震災とモバイル・コミュニケーション," NTT
出版, (2013)[2] 鶴正人, 内田真人, 滝根哲哉, 永田晃, 松田崇弘, 巳波弘佳, 山村新也, "DTN 技術の現状と展望, " 電子情報通信学会 通信ソサイエティマガジン, No.16, pp.57-68, (2011)[3] A. G. Voyiatzis, ”A Survey of Delay- and Disrup-tion-Tolerant Networking Applications,” Journalof INTER-NET Engineering, vol.5, no.1, pp.331-343, (2012)[4] Y. Cao, Z. Sun, "Routing in Delay/Disruption Tolerant Net-works: A Taxonomy, Survey andChallenges," Communica-tions Surveys & Tutorials, IEEE, vol.15, no.2, pp.654-677, (2013)[5] M. J. Khabbaz, C. M.Assi, W. F. Fawaz, "Disrup-tion-Tolerant Networking: A Comprehensive Survey
on Re-cent Developments and Persisting Challenges," Communica-tions Surveys & Tutorials, IEEE,
vol.14, no.2, pp.607-640, (2012)[6] Delay-Tolerant Networking Research Group (DTNRG), https://irtf.org/dtnrg[7] 鈴木規之, 津田徹, 齋藤利文, 森山京平, J. L. F. Zamora, 樫原茂, 藤川和利, 山口英, "SOSCast:
救助要請伝搬アプリケーションの設計と実装," 電子情報通信学会技術研究報告, Vol.111, No.384,
MoMuC2011-45, pp.49-54, (2012)[8] 津 田 徹 , 鈴 木 規 之 , 齋 藤 利 文 , 森 山 京 平 , J. L. F. Zamora, 樫 原 茂 , 藤 川 和 利 , 山 口 英 ,"SOSCast:Bluetooth を用いた蓄積運搬転送型通信による救助要請アプリケーション (技術展示)," 電

9電気通信普及財団 研究調査報告書

子情報通信学会技術研究報告, Vol.111, No.384, MoMuC2011-52, pp.83-84, (2012).
[9] N. Suzuki, J. L. F. Zamora, S. Kashihara, S. Yamaguchi, "SOSCast: Location Estimation of
Immobilized Persons through SOS Message," In Proc. of 4th International Con-ference onIntelligent Networking and Collaborative Systems (INCoS-2012), pp.428-435, (2012)[10] N. Suzuki, J. L. F. Zamora, S. Kashihara, and S. Yamaguchi, "Using SOS Message Propagation to
Estimate the Location of Immobilized Persons," Proceedings of the 17th Annual In-ternational
Conference on Mobile Computing and Network-ing (MobiCom 2012), Demo session, pp.455-458, (2012)[11] 鈴木規之, J. L. F. Zamora, 樫原茂, 山口英, ''通信被害地域における捜索効率とバッテリー消費を
考 慮 し た 要 救 助 者 情 報 収 集 手 法 の 評 価 ,'' 電 子 情 報 通 信 学 会 技 術 研 究 報 告 , Vol.112, No.493,
MoMuC2012-73, pp.329-334, (2013)[12] J. L. F. Zamora, N. Suzuki, H. Takemoto, S. Kashihara, Y. Taenaka, S. Yamaguchi, "Battery-saving
Message Collection Method for Disrupted Communication Service Areas," In Proc. of The 11th AnnualIEEE Consumer Communications & Networking Conference (CCNC), (2014)[13] 竹本裕明, J. L. F. Zamora, 樫原茂, 妙中雄三, 高井峰生, 金田茂, 山口英, "通信被害地域における要救助者間の情報共有手法の評価と考察," 電子情報通信学会技術研究報告, Vol.113, No.304,
MoNA2013-43, pp.11-16, (2013)[14] R. Friedman et al., On Power and Throughput Tradeoffs of WiFi and Bluetooth in Smartphones, Mobile
Computing, IEEE Transactions on, vol.12, no.7, pp.1363-1376, Jul. 2013.
[15] 樫原茂, 妙中雄三, J. L. F. Zamora, 山口英, "SOSCast における現状の問題分析と解決案に関する一
検討," 電子情報通信学会技術研究報告, Vol.113, No.168, Mo-NA2013-23, pp.59-62, (2013)[16] 茨 城 新 聞 , " 坂 東 市 、 無 線 ヘ リ を 導 入
県 内 初 、 愛 好 会 と 連 携 協 定 ,"http://ibarakinews.jp/news/newsdetail.php?f_jun=13897013903047, (2014)

〈発
題

名

通信被害地域における Twitter 情報転送機
能の実装
罹災地における DTN 技術を用いた情報収集
手法
無線 LAN デバイスのオンオフ制御によるバッテリー消費を考慮した情報共有手法の提案と評価無人機で災害情報収集 奈良先端大 工科大で飛行実験
ドローンを用いた災害情報収集試作機の作成と運用に関する一考察
ドローンを用いた罹災状況収集用センサの試作と実験
Securing SOS Messages in Uncommunicable
Areas via Information Sharing Cluster

表

資

料〉

掲載誌・学会名等

発表年月

Scenargie Workshop 20142014 年 10 月

第 57 回自動制御連合講演会

2014 年 11 月

電子情報通信学会技術研究報告2014 年 11 月

高知新聞

2015 年 3 月 25 日

電子情報通信学会技術研究報告2015 年 5 月

電子情報通信学会技術研究報告2015 年 8 月

IEICE
TRANSACTIONS
on
Fundamentals of Electronics,
Communications and Computer
Sciences2015 年 8 月

10電気通信普及財団 研究調査報告書