災害時の DTN 対応安否確認アプリケーションの設計に関する一検討
高田 千暁

1

(指導教員：小口 正人)

はじめに

今やインターネットは様々なアクセス網を包含し世界中を結ぶことのできる情報交換・共有システムとして社会・ 経済のインフラともいえる役割をはたしており，社会のネットワーク依存度はますます高まっている．それに伴い，従来は想定されていなかったような劣悪な環境下での通信アプリケーションの要求がでてきた．中でも，地震などの災害によって本来の通信インフラ機能や性能が低下，停止した場合の緊急代替情報交換手段を事前に設計，準備しておくことは防災や減災を考える上で大変重要である．現在，災害時には各キャリアや日本限定で Facebook から安否確認掲示板が提供されたり，goo アプリなど災害に備えたアプリが用意されているが，そういったサービスはインターネットが機能しているという前提で考えられている．
そこで本研究では，地震などによって地域的にインターネットが機能しないような劣悪な条件下でも部分的に稼動しているサーバ機能付 Wi-Fi アクセスポイント
を用い，Delay/Disruption Tolerant Network (DTN)技術を利用して安否確認が行える通信アプリケーションの開発とその実装要件を検討する．

2

図 1: サーバ機能付 Wi-Fi アクセスポイントを用いた無線メッシュ/DTN システム

災害時アプリケーションの検討

4.1

アプリケーション概要

本研究では Android 端末を用い，稼働しているサーバ機能付 Wi-Fi アクセスポイント同士のデータ同期を可能とするような Android アプリケーション（以下，アプリ）の設計を行った（図 2）．

1) アプリは災害が起きネットワーク環境が不安定になった後でもインストールできるよう，アクセスポイントに保存されている．ユーザはここからアプリをインストールする．

DTN

2) アプリを用いて安否情報を記入し，アクセスポイント 1（以下，AP1）に送る．このときユーザは，自身のデータを送信すると同時に AP1 に保存されているデータを受け取り，端末に保存する．

DTN は遅延耐性ネットワークとも呼ばれ，物理的なリンクの切断やデータの送受信遅延に対応していな
い TCP/IP 技術を拡張させた「中継転送技術」である [1]．この一般的な手法は「届きそうな」端末にデータを送信し，端末間でデータをホップさせていくことで目的端末まで届かせるというものである．これにより，中断や切断が多発したり，極端に長い通信遅延が生じたりするような劣悪な通信環境下でも信頼性のあるデータ転送を実現することができる．

343) ユーザが動くことで端末がアクセスポイント 2（以下，AP2）とデータのやり取りを行い，非接続状態の AP1 と AP2 のデータが同期される．

災害時の想定環境

災害時のネットワーク環境として，サーバ機能付 WiFi アクセスポイントを用いた無線メッシュ/ DTN システム（図 1）を想定している．このシステムは，使えなくなった経路が発生しても稼働している一部のサーバ機能付 Wi-Fi アクセスポイントと DTN 技術を用いて継続的に接続，再構成を繰り返し，送信先に達するまでノードからノードへ転送を行って目的端末まで到達させることを可能とするものである．これにより，大規模災害などによって地域的にネットワーク接続が切れている場合でも通信が可能となる．本研究ではこのような環境を想定して検討していく．

図 2: アプリケーション概要

4.2

アプリ設計における注意点

アプリを検討するにあたり，注意しておかなれければならないこととして各ポイントでのデータ取得の時間のずれがあげられる．例えば, 端末から AP1 には
PM2:00 にデータが届き，インターネットには PM5:00

47端末側で述べたように端末とサーバでデータのやり取りを行う場合はデータは JSON 形式で扱われているが，サーバ内ではデータベースとして保存されている．
よって，検索機能などをつけたい場合は端末側ではな
くサーバ側で検索する形となる．
データの保存方法は update 文で上書きするのではなく， insert 文のみを用いて追加だけしていくようにしている．これは，例えばユーザのデータ送信履歴から行動軌跡をたどるなど，災害時においては過去のデータも価値がある可能性が考えられるためである．に届いたとする． このときデータの取得には 3 時間のずれがでているが，このずれに気づかずにインターネッ
トにデータの問い合わせを PM3：00 にしてしまうと，データは「まだ届いていない」だけにも関わらず，「ない」と勘違いされてしまう可能性がある．また，各アクセスポイントはつながっておらず同期ができていないので，インターネット側はどのアクセスポイントといつの時点のデータを同期したかを把握しておかなければならない．さもなければ，実際は古いデータにも関わらず届いた時間が新しいからといってそのデータを同期してしまうといったことが起こりうる．アプリの設計はこのような問題に注意しながら検討していく．

4.3

5

端末からアクセスポイントまでは IEEE802.11n の無線 LAN で，アクセスポイントからサーバへは有線LAN でつなぎ，2 台のサーバには重複を含む 10 個のデータが保存されている．この環境下で端末でアプリを起動させ，必要事項を記入した後，サーバ 1 とサー
バ 2 へ順にデータを送信した．送信するサーバの切り替えはアプリのボタンで行う．
サーバ 1 にデータを送信した後，端末にはサーバ 1 のデータが保存された．次にサーバ 2 とデータのやり取りを行うと，端末に保存されているサーバ 1 のデータでサーバ 2 が保持していないデータのみがサーバ 2 へ送られた．それと同時に，端末は自身が保持していないサーバ 2 のデータを取得できたので，端末とサーバ2 のデータが同期されたことが確認できた．この状態
でさらにサーバ 1 とデータのやり取りを行えば，サーバ 1 とサーバ 2 は基本的に同期された状態になると考えられる．また，ユーザが安否情報を記入し送信ボタンを押すと，データの ID や送信時間，サーバの IDも取得できていることが確認できたので，アプリは正しく動作しているとわかった．

端末側の実装Android 開発環境である Android Studio で実装し，端末としては Galaxy Nexus， Android 4.2.2 を用いた．端末側アプリの主な動作は以下の通りである．
1) ユーザは安否情報を記入し，端末が保存しているデータに追加する．初めて使用する場合は登録したデータのみが保存される形となる．
2) アクセスポイントに端末が保持するデータのリストを送り，サーバのデータとの差分を調べる．
3) 端末のみが保持するデータをサーバへ送り，サーバから取得したデータを保存する．
ユーザが記入するものは，名前，電話番号，被害状況，居場所，コメントの 5 つであり，データの送信と同時にデータの ID ，送信した時間，通信先のサーバの ID が自動的に取得される．ただし，災害が起きた場合でも動作している機器が保有する時刻に大幅なずれは生じないということを前提としている．
端末とサーバがデータのやり取りをする場合，データは JSONObject 型で扱われるが，これには 1 人分のデータしか入らない．よってデータは， JSONObject型がリスト状になった JSONArray 型に複数人のデータを格納し，それを変数名 data の値とした JSONObject型になっている．

4.4

アプリの動作確認

6

まとめと今後の課題

地域的にインターネットが機能しないなど，劣悪な条件下でも部分的に稼動しているサーバ機能付 Wi-Fi
アクセスポイントと DTN 技術を利用して，安否確認が行えるようなアプリケーションの検討と簡単なアプリの実装を行った．2 台のサーバと１台の端末でアプリを起動させデータのやり取りを行った結果，非接続状態のアクセスポイントでもデータの同期ができそうだということが確認できた．
今後の課題として，アプリの動作評価を行っていく．
また，サーバや端末，データの数を増やしていきつつ，より効率な同期方法を検討していきたい．

サーバ側の実装

サーバとしては，メモリ 3.7 ＧＢの Intel Pentium
E2220 2.4GHz を 2 台用いた．サーバは Java で実装してあり，主な動作は以下の通りである．

1) 端末から通信がきたらサーバの ID を返す．
2) 端末から送られたデータのリストをもとにお互いが保持していないデータを判断し，端末のみが保持するデータの送信を端末へ要求する．

参考文献[1] 鶴正人，ほか ”DTN 技術の現状と展望” 通信ソサ
イエティマガジン，No.16[春号]，pp.57-68，2011.

3) 端末から送られてきたデータをデータベースに保存し，サーバのみが保持するデータを端末へ送信する．

[2] 高田千暁，黒崎裕子，高井峰生，小口正人 ”災害
時 DTN 対応安否確認アプリケーションの実装と予備評価” ＤＥＩＭ 2015，2015 年 3 月発表予定．
48