DEIM Forum 2017 A6-3

災害時における DTN を用いた情報共有システムのエミュレーション評価
高田 千暁†

前野誉††

大和田泰伯†††

高井 峰生††††

小口 正人†† お茶の水女子大学 〒 112-8610 東京都文京区大塚 2-1-1†† 株式会社スペースタイムエンジニアリング 〒 101-0025 東京都千代田区神田佐久間町 3 ‒ 27 ‒ 3††† 情報通信研究機構 〒 980-0812 宮城県仙台市青葉区片平 2-1-3†††† UCLA 3803 Boelter Hall, Los Angeles, CA 90095-1596, USA
E-mail: †{g1120526,oguchi}@is.ocha.ac.jp, ††tmaeno@spacetime-eng.com, †††yowada@nict.go.jp,††††mineo@ieee.org
あらまし地震大国である日本にとって，災害時の緊急情報交換技術を事前に設計し準備しておくことはとても重要である．そのため現在においても，様々なシステムの提案や検討がなされている．しかし，実際にそれらのシステムが有益かを実環境で評価することは困難である．シミュレーションを用いれば大規模なシナリオを想定した評価をすることができるが，そのためにはアプリケーションをモデル化するなど多大な労力がかかってしまう．そこで本研究
では，こうした労力を省いて性能評価を行うために，サーバ機能付き Wi-Fi アクセスポイントと Delay/Disruption

Tolerant Network(DTN) 技術を用いた災害時通信システムについてエミュレーション評価を行うことを目指す．
キーワード

災害時，DTN，エミュレーション

Emulation Evaluation of Information Sharing System
Using DTN in the Case of a Disaster
Chiaki TAKADA† , Taka MAENO†† , Yasunori OWADA††† , Mineo TAKAI†††† , and Masato
OGUCHI†† Ochanomizu University
2-1-1 Otsuka, Bunkyouku, Tokyo 112-8610 JAPAN†† Space-Time Engineering 3 ‒ 27 ‒ 3, KandaSakumacho, Chiyoda-ku, Tokyo, 101-0025, Japan††† National Institute of Information and Communications Technology 2-1-3, Katahira, Aoba, Sendai-city,Miyagi, 980-0812, JAPAN†††† UCLA 3803 Boelter Hall, Los Angeles, CA 90095-1596, USA
E-mail: †{g1120526,oguchi}@is.ocha.ac.jp, ††tmaeno@spacetime-eng.com, †††yowada@nict.go.jp,††††mineo@ieee.org

1. は じ め に各キャリア [1] 〜 [3] や日本限定で Facebook [4] から災害発生時に利用可能となる安否確認掲示板が提供されていたり，goo

今やインターネットは様々なアクセス網を包含し世界中を結防災アプリ [5] など地震や災害に備えたアプリケーションが用ぶことのできる情報交換・共有システムとして社会・ 経済の意されている．しかし，このようなサービスはインターネットインフラともいえる役割をはたしており，社会のネットワークが機能しているという前提で考えられている．

依存度はますます高まってきている．それに伴い，従来は想定また，劣悪な環境下を想定したシステムについても様々なもされていなかったような劣悪な環境下での通信システムの要求のが検討されているが，それらを実環境で実際に動かして評価がでてきた．中でも，地震などの災害によって本来の通信インすることは困難である．シミュレーションを用いれば大規模なフラの機能や性能が低下，停止した場合の緊急代替情報交換手シナリオを想定して性能評価を行うことができるが，通信プロ段を事前に設計し準備しておくことは，地震大国である日本にトコルのモデル化や，実アプリケーションの組み込みなど，大とって防災や減災を考える上でも大変重要になってくる．現在，きな労力がかかってしまう．

—1—

そこで本研究では，地震などの災害によって地域的にインターことができる．

ネットが機能しないような劣悪な条件下でも部分的に稼動してい手法の例として，端末間でデータをホップさせていくもの

るサーバ機能付 Wi-Fi アクセスポイントと Delay/Disruption

や，メッセージ転送を目的とした物理的に移動する端末（以下，Tolerant Network (DTN) 技術を利用した災害時通信システムフェリーノードと呼ぶ）を用いて，距離が遠くて直接通信がでを検討し，そのシステムの評価をエミュレーションを用いて行きないノード間のデータ転送を可能とするメッセージフェリーうことを目指す．

方式というものがある [9]．こうした手法により，中断や切断が多発したり，極端に長い通信遅延が生じたりするような劣悪な2. 従 来 研 究

通信環境下でもデータ転送を実現することができる．

2. 1 関 連 研 究

り，組み込みシステムへの実装に対する研究等がなされていDTN 技術を用いた研究は数多く検討されている．

る [11]．

既存の DTN フレームワークとしては IBR-DTN [10] があ[6] ではバッテリの残量から転送先を動的に選択し，被災地内の情報を被災地外へ運び出す災害時通信システム構築法の提案がなされている．この研究では広域災害時により通信インフラが機能しない場合に，メッセージフェリー方式を用いて被災

3. 災害時の想定環境
災害時の通信環境として，サーバ機能付 Wi-Fi アクセスポ

地内の情報を被災地の外へ運び出すことを想定している．このイントを用いた無線メッシュ/ DTN システム（図 1）を想定しとき避難所内の移動端末の通信では，バッテリ残量が多い端末ている．

へデータが集まるようにデータ転送先が動的に選択される．ここのシステムでは，平常時ではサーバ機能付 Wi-Fi アクセス

れにより，特定の移動端末に負荷が集中することを防ぎ，ネッポイントが一般的なアクセスポイントとして機能している．しトワーク持続時間を長期化することを目指している．

かし，大規模な災害が発生し有線接続が切れると，通常時モーこの研究では，フェリーノードが避難所に滞在する時間をドから非常時モードに切り替わることで，無線で他のアクセス300 〜 600 秒とあらかじめ設定しているが，災害時においてこポイントに接続するようになる．これにより，使えなくなったの値が適切かは考慮していく必要があると考える．また，運ぶ経路が発生しても稼働している一部のサーバ機能付 Wi-Fi ア

データをサイズが 50 〜 150KB と小さいものとしているため，

クセスポイントを用いて継続的に接続，再構成を繰り返す．ま

画像などのサイズが大きなデータは想定されていない．

た，距離が離れていて直接通信ができなかったり，メッシュ接[7] ではモバイルアドホックネットワーク (MANET) と DTN続ができないようなアクセスポイントに対しては DTN 技術をの異なる 2 つのネットワーク形成技術を高度に融合した端末間用いることで，目的端末に達するまでノードからノードへ情報通信技術が提案されている．これは変化する周囲の状況にあわを転送することができる．よって，大規模災害などによって地せて適切なネットワークモードを自動的に判断して切り替わる

域的にインターネット接続が切れている場合でも通信が可能とことで，通常は圏外で通信不可能な環境であっても効率的な通なる．

信の実現と消費電力の低減を目指しており，全行程 2.7km での実証実験もなされている．
この研究では，アクセスポイントを介さずに機器同士が直接通信を行うアドホックモードを用いて，情報のやりとりがなされている．ネットワークモードの切り替えにより端末のバッテリ消費はある程度抑えられると予想できるが，これはまだ解決

また，このネットワークは災害時だけでなく平常時も利用可能なので，災害時のみを想定したネットワークよりも運用コス
ト面やユーザにシステムを認知してもらえないといった問題を抑えることができる．
本研究ではこのような環境を想定して災害時通信システムについての検討を行う．

すべき問題である．また，すれ違いなど端末が近い位置にないと行えないこと，ホップすることによってスループットが低下してしまうといった課題もあり，これらを考慮していく必要があると考える．
このように，災害時を想定した通信システムは様々なものが考えられているが，そうしたシステムが実際に災害時において有益かを検証することは困難である．

2. 2 DTN
DTN は遅延耐性ネットワークとも呼ばれ，物理的なリンクの切断やデータの送受信遅延に対応していない TCP/IP 技術を拡張させた「中継転送技術」である [8]．この一般的な手法は「届きそうな」端末にデータを送信し，端末間でデータをホップ

図 1 サーバ機能付 Wi-Fi アクセスポイントを用いた無線メッシュ/DTN システムさせていくことで目的端末まで届かせるというものである．これにより，中断や切断が多発したり，極端に長い通信遅延が生じたりするような劣悪な通信環境下でもデータ転送を実現する—2—

4. 2 通信システムの概要

4. 災害時の通信システム

本研究では，図 2 のような，各避難所に設置されたサーバ機

4. 1 通信で扱う対象について

能付き Wi-Fi アクセスポイントとフェリーノードを用いて，白現在においても災害時では，紙媒体を用いて情報を表すこと

板等に記された安否情報や被災状況を撮影した写真（画像デーが少なくない．2011 年 3 月に発生した東日本大震災においてタ）などを同期させるシステムを考えた．これにより，紙媒体も，避難所の様子を見てみると白板や壁に紙を張り付けるなどで表された情報や文字だけでは表しにくい情報など，様々な情して安否確認をしている人が多くみられた．さらに，必要物資報を共有することができる．

やボランティアの割り振りの管理，負傷した被災者のトリアー

ここでは，役場や消防，警察等の車両が避難所などを循環す

ジなど，救援活動を行う上でもアナログの情報はまだまだ用いる際に情報の蓄積や運搬もする事を想定し，そのノードをフェられている．また，家屋や道路の損壊具合など，被災状況を正リーノードとしている．

しく伝えるためには，視覚的に情報を伝えることも有益である

1) 避難所に避難している人々は従来通り，白板や壁に安否情報を書いた紙を貼るなどして安否情報を表す．と考えられる．
つまり，災害時には紙媒体で表された情報や文字だけでは表しにくい情報など，様々な情報をまとめることが必要となってくる．
しかし，現在用意されている，災害時安否確認掲示板の多くは文字データを扱っている．文字データを扱うことの大きなメ

2) 安否情報が記された白板等を撮影した写真や被災状況についての画像データは，避難所に設置されたサーバ機能付き

Wi-Fi アクセスポイントに保存される．
このとき，接続しているアクセスポイント同士は，自動的に同期される．

リットは，データサイズが小さく，また，データベース等で管理がしやすい点である．しかし，文字データはスマートフォンやパソコン等の機器を用いて入力するため，そうした機器に不3) 未接続なサーバ機能付き Wi-Fi アクセスポイント同士は，フェリーノードが情報を運ぶことにより同期される．

慣れな人にとっては大変な作業である．災害時で余裕がない状況では，こうした作業はユーザにとって大きな負担になると考える．
そこで本研究では，通信で扱う対象として文字データだけでなく画像も含めた．そうすることで，避難所の白板等に貼られた安否情報の写真を撮ることで情報をまとめられるため，被災者は普段と違った行動をしなくて済む．また，無機質な文字データではなく，画像で視覚的にデータを伝えることができるのでその人自身が書いた文字を見ることができ，被災者に安心感を与えられるのではないかと考えた．さらに，文字データでは伝えにくい情報を扱うこともできるので，そうした情報を活図 2 災害時通信システム概要

かすことで効率の良い救援活動にもつなげやすくなると考える．
（表 1 にそれぞれのメリットとデメリットについてまとめた．
）
しかし，画像を扱う上の大きな懸念点として，データサイズが5. エミュレーションの環境の構築大きいということがあげられる．安否情報を文字データで表すと，名前や簡単な状況を伝えるだけならば，1 つあたり 120byteほどで扱うことでできる．一方，画像の場合は，スマートフォンで撮影した写真は 1 枚あたり約 1 〜 3MB となり，文字デー災害時における安否確認システムについて，エミュレーションによる評価を行うために環境構築を行った．

5. 1 エミュレーションの特徴

タに比べとても大きいことがわかる．よって，災害時における災害時の通信システムについての通信評価を行うためには，通信システムを考えるには，こうしたデメリットにも注意しな物理層からアプリケーションに至るまでの様々な挙動を考慮すければならない．

る必要がある．
表 1 画像と文字の違い

メリット

シミュレーションでは，これらの全挙動を計算によって再現

画像

文字する．そのため，少ない計算量でシステムを評価するために，紙媒体の情報を画像としてサイズが小さい通信プロトコルから影響の少ない処理を削除したり，機能の簡残せる略化を行って，プロトコルのモデル化を行う．これにより，シ様々な情報を扱えるため， 情報を整理しやすい

ミュレーションでは高速に通信の特性を再現することができ効率の良い支援につなげやる．しかし，シミュレーションを行う際には実際のシステムをすくなる
デメリット サイズが大きいシミュレーションに適した形でモデル化することもあるため，入力が負担そのモデル化が妥当であるかに気をつけなければならない．また，実際に動いているアプリケーションを組み込んで評価する
ためには，プログラムの書き換えなど，非常に大きな労力が必—3—

要となる．こうしたことを抑えるために，エミュレーションを用いる．
エミュレーションでは仮想化技術を用いて，1 台のコンピュータ（以下，ホスト OS と呼ぶ）上に複数の仮装マシン（以下，

6. 実地図を用いたエミュレーションシナリオ
和歌山県の観光地である南紀白浜地域の実地図を用いて，災害時通信システムのシナリオを構築した．

VM と呼ぶ）を構築し，それらの上で実アプリケーション等を観光地は地元の人々だけでなく，その土地になじみのない観動作させて評価を行うことができる．そのため，図 3 のように，光客も集まるため，災害が起きた場合，より多くの情報を迅速下位層の通信システムのみ実時間で動作するシミュレーションに集めることのできる通信システムが必要だと考える．

を介して通信を行い，上位層では実機で用いる場合と同一のアプリケーションやバイナリをそのまま動作をさせることが可能となる．これにより，アプリケーションや上位プロトコルの動作をシミュレーションへ組み込む手間が省け，また，より実環境に近い動作確認ができると考える．

6. 1 シナリオ概要
シナリオは図 5 のような約 2km 四方の南紀白浜地域を想定
し，地震が発生してから少し時間が経ち，人々は避難所に避難し終わっているものとする．各避難所にはサーバ機能付き Wi-Fiアクセスポイントが設置され，そこに被災者から投稿された災害情報が保存されている．
今回は白浜町のハザードマップに避難所と記されている 4 箇所にアクセスポイントを設置し，2MB のデータが 20 個ずつ生成されているものとした．フェリーノードはデータの生成が完了してから動き始め，時速 43.2 〜 54.0km で各避難所を巡回し，3 周する．このとき，各アクセスポイントでの滞在時間は180 秒とした．
シナリオの設定詳細は表 3 で，仮想端末の使用を表 4 で示す．

図 3 エミュレーションによる各レイヤの動作主体

5. 2 エミュレーション環境
本研究では実験環境として，図 4 のような環境をホストOS 上に構築した．ホスト OS の仕様については表 4 に示す．
各 VM とエミュレーションシナリオ内のノードはブリッジで接続されており，各 VM は同じネットワーク空間にあるものとした．また，各 VM 上では，データベースアプリケーション

図 5 実地図を用いたシナリオが作動している，このアプリケーションは，複数のノード間で通信が成立した際，ノード同士のデータベースの差分を補う．
これにより複数の VM の同期を行うことができる．

図 4 エミュレーション環境の構成

表 2 ホスト OS の仕様

CPU

表3

実地図を用いたシナリオの環境

シミュレーション時間

4,500 秒範囲

2.0km × 2.0km

避難所の数

4 箇所

アクセスポイントの台数4台

生成するバンドルの総数

80 個—hline アクセスポイントの送信電力

10dBm(10mW)

バンドルのサイズ

2MB

フェリーノードの台数

1台

フェリーノードの速度

時速 43.2 〜 54.0km

表4仮装端末の仕様

OSCentOS6.7

Memory2GBIntel Xeon 2.2GHz(10Cores/20 スレッド)OS

CentOS6.8

Memory

16GB

HDD

1TB

—4—

6. 2 エミュレーション結果
各ノードの Mac 層，つまりシミュレーション環境下での受信データフレーム数を図 6 で，実アプリケーションによる仮想端末の保存データ数の推移を図 7 で示す．図 6 のデータフレー
ムには，やり取りするデータだけでなく Ack なども含まれているため，図 7 より値が大きくなっている．
図 6，7 を比較すると，シミュレーション環境下で通信が行われたタイミングと，実アプリケーションによって保存データ数が増加しているタイミングが一致しており，フェリーノードが各アクセスポイントに近づいたタイミングで，エミュレーションシナリオノードに対応する仮想端末同士が実アプリケーションを用いてデータのやり取りが行われたことがわかる．よって，正しくエミュレーション環境が構築できていることが確認できた．
また，仮想端末上では実アプリケーションが稼働しているた
め，TCP dump などを用いればそのアプリケーションでやり取りされているデータを解析することができる．図 7 を見てみると，1 回の通信でのやり取り数に多少ばらつきがあり，他の通信に比べてやり取り数が少なくなっている箇所があることがわかる．その部分のデータの流れを TCP dump で見てみると，やり取り数が減っているのは，パケットが損失しているわけではなく，通信が断続的になっているためだということがわかった．これは想定よりも通信量が多くなって TCP のセッションが意図せずに切れてしまい，セッションを貼り直すことに時間がかかっているためだと考えられる．
シミュレーションでこうした解析を行うには，通信プロトコ

図 7 実アプリケーションによる保存データ数の推移

6. 3 フェリーノードを同期完了してから移動するように変更したシナリオ
前節と同じシナリオを用いるが，フェリーノードの動作を同期完了してから移動するように変更した．これにより，「人が目で見て」同期を判断して次のノードへ移動する，といった手間を省いて実験を行うことができる．
ただし，エミュレーションでは実アプリケーションを用いてデータのやり取りを行っているため，通常は実アプリケーションの動作によってシミュレーション内のフェリーノードの動作を操作することはできない．そのため，今回は実アプリケーションがデータの送受信に対して，リクエストを出したり，それらのやり取りが完了した際に，「リクエストメッセージ」と「完了メッセージ」をシミュレータに送るようにした．このメッセージにより，「同期完了」を判断する．

ル以外に解析用のプロトコルをモデル化したり，新たに作成し6. 4 動作変更後のエミュレーション結果なければならない．一方，実環境で検証する場合は，実機を用各ノードの Mac 層，つまりシミュレーション環境下での受いるためこうした解析が可能であるが，そのためにはシナリオ

信データフレーム数を図 8 で，実アプリケーションによる仮台数分の実機や実験要員を集め，実験現場に向かう，など大き想端末の保存データ数の推移を図??で示す．前節の結果と同様な手間がかかってしまう．エミュレーションでは，シミュレーに，図 8 のデータフレームには Ack なども含まれている．

ションよりスケーラビリティは低下してしまうが，こうした実

図 8，図 9 を比較すると，前節と同様にシミュレーション環境環境を想定した実験を少ない労力で行うことができるので，通下で通信が行われたタイミングと，実アプリケーションによっ信システムを検証するために有効な手段であると言える．て保存データ数が増加しているタイミングが一致しており，正その上で今回の結果を見てみると，2MB と容量が大きいデーしくエミュレーション環境が構築できていることがわかる．

タの場合でも，フェリーノードとサーバ機能付き Wi-Fi アク

その上で図 9 を見てみると，毎回の通信でフェリーノードとセスポイントを用いることで同期が可能だということが推測で各 AP が保持するデータの差分を全てやり取りしていることがきた．よって，提案システムは災害時において有効であると考確認できた．よって，フェリーノードが同期完了してから動くえられる．

ように動作変更できたことがわかった．これにより，本来は実環境で「人の判断」や「人の手や足」で行う部分をシミュレーション部分で対応しつつ，シミュレーションでは扱えない実アプリケーションを用いることができるので，実環境でしか検証できないような方法でもエミュレーションを用いることができると考える．
また，図 9 から，1 時間 15 分ほどで全てのアクセスポイン
トの同期が完了していることが読み取れる．前節のシナリオ
では，ほぼ同じ時間をかけても同期が行えていないので，フェリーノードが「同期完了したから動く」ことは素早く同期を行いたい場合に有効であることがわかる．

図 6 Mac 層での受信データフレーム数の推移

—5—

[7]

[8]

[9]

図 8 Mac 層での受信データフレーム数の推移

[10]
[11]

ンポジウム，2013 年 7 月.
http://www.roec.tohoku.ac.jp/info/news/pdf/NJ00067.pdf
鶴正人，内田真人，滝根哲哉，永田晃，松田崇弘，巳波弘佳，山村新也 ”DTN 技術の現状と展望” 通信ソサイエティマガジン，No.16[春号]，pp.57-68，2011.
金田知展，中村嘉隆，高橋修 ” DTN を用いた災害時通信システム構築法の提案”，マルチメディア，分散，協調とモバイル(DICOMO2013) シンポジウム，pp.964-969，2013 年 7 月.
http://www.fun.ac.jp/ y-nakamr/research/dicomo/
dicomo2013kaneta.pdf
Zhao，W.，and Ammar，M.H. ” Message Ferrying:ProactiveRouting in Highly-partitioned Wireless Ad Hoc Networks”，Proc. of the 9th IEEE Int l Workshop on Future
Trends of Distributed Computing Systems (FTDCS 2003)，
pp.308\UTF{2013}314，2003.
IBR-DTNhttps://bousai.goo.ne.jp/apps/
Doering，M.，Lahde，S.，Morgenroth，J.，and Wolf，L. ”
IBR-DTN:An Eﬃcient Implementation for Embedded Systems ”，CHANTS’08，pp.117\UTF{2013}119，2008.

図 9 実アプリケーションによる保存データ数の推移

7. まとめと今後の課題
大規模災害によって地域的にインターネットが機能しないなど，劣悪な条件下でも，部分的に稼動しているサーバ機能付

Wi-Fi アクセスポイントと DTN 技術を利用した災害時通信システムを検討し，その評価を行うことができる環境を構築した．
評価環境には，エミュレーション環境を用いた．これにより，実アプリケーションをそのまま用いて評価することができ，かつ，より現実的な動作確認ができると考える．
今後はシナリオの設定を見直し，より詳細な評価を行っていく．

謝辞

本研究の一部はお茶の水女子大学と情報通信研究機構との共同研究契約に基づくものである．

文献[1] NTT ドコモ 災害時の安否確認と備え
https://www.nttdocomo.co.jp/info/disaster/[2] KDDI 災害用伝言板サービス
http://www.au.kddi.com/mobile/anti-disaster/saigai-dengon/[3] SoftBank 災害用伝言板／災害用音声お届けサービス
http://www.softbank.jp/mobile/service/dengon/[4] Facebook 災害時情報センター
https://www.facebook.com/about/safetycheck/[5] goo 防災アプリ
https://bousai.goo.ne.jp/apps/[6] 加藤寧 ”スマホ de リレー - 圏外でも通信可能なデュアルモード
アドホックネットワーク技術 - ”，東北大学電気通信研究機構シ

—6—