DEIM Forum 2016 E7-6

実地図を用いた災害時通信システムのシミュレーション評価
高田 千曉†

黒崎 裕子†

本橋 史帆†
小口大和田泰伯††

高井 峰生†,†††正人†† お茶の水女子大学 〒 112-8610 東京都文京区大塚 2-1-1†† 情報通信研究機構 〒 980-0812 宮城県仙台市青葉区片平 2-1-3††† UCLA Computer Science Department 3803 Boelter Hall, Los Angeles, CA 90095-1596, USA
E-mail: †{g1120526,oguchi}@is.ocha.ac.jp, ††{yuko-k,shiho}@ogl.is.ocha.ac.jp, †††yowada@nict.go.jp,††††mineo@ieee.org
あらましインターネットは社会・経済のインフラともいえる役割をはたしている．それに伴い，地震などの災害でその機能や性能が低下，停止した場合の緊急代替情報交換手段が必要となってきた．また，これらのことを事前に設計，準備しておくことは防災や減災を考える上でも大変重要である．現在においても，災害に備えたサービスは存在するが，これらはインターネットが機能していることを前提としている．そこで本研究では，地域的にインターネッ
トが機能しない劣悪な条件下でも，部分的に稼動しているサーバ機能付 Wi-Fi アクセスポイントと Delay/Disruption

Tolerant Network(DTN) 技術を利用した災害時通信システムのシミュレーションシナリオを構築し，その評価を行った．
キーワード 災害時通信，DTN，地図情報

A Real Map Based Simulation Evaluation of Communications System in
the Case of a Disaster
Chiaki TAKADA† , Yuko KUROSAKI† , Shiho MOTOHASHI† , Yasunori OWADA†† , Mineo
TAKAI†,††† , and Masato OGUCHI†† Ochanomizu University
2-1-1 Otsuka, Bunkyouku, Tokyo 112-8610 JAPAN†† National Institute of Information and Communications Technology 2-1-3, Katahira, Aoba, Sendai-city,Miyagi, 980-0812, JAPAN††† UCLA Computer Science Department 3803 Boelter Hall, Los Angeles, CA 90095-1596, USA
E-mail: †{g1120526,oguchi}@is.ocha.ac.jp, ††{yuko-k,shiho}@ogl.is.ocha.ac.jp, †††yowada@nict.go.jp,††††mineo@ieee.org

1. は じ め にとって防災や減災を考える上でも大変重要になってくる．現在，各キャリア [1] 〜 [3] や日本限定で Facebook [4] から災害発生

今やインターネットは様々なアクセス網を包含し世界中を結時に利用可能となる安否確認掲示板が提供されていたり，gooぶことのできる情報交換・共有システムとして社会・ 経済の防災アプリ [5] など地震や災害に備えたアプリケーションが用インフラともいえる役割をはたしており，社会のネットワーク意されている．しかし，このようなサービスはインターネット依存度はますます高まってきている．それに伴い，従来は想定が機能しているという前提で考えられている．

されていなかったような劣悪な環境下での通信システムの要求

そこで本研究では，地震などの災害によって地域的にインターがでてきた．中でも，地震などの災害によって本来の通信インネットが機能しないような劣悪な条件下でも部分的に稼動していフラの機能や性能が低下，停止した場合の緊急代替情報交換手るサーバ機能付 Wi-Fi アクセスポイントと Delay/Disruption

段を事前に設計し準備しておくことは，地震大国である日本にTolerant Network (DTN) 技術を利用した災害時通信システム—1—

を考え，そのシミュレーションシナリオの構築と評価を行った．

距離を短くすることができるので大容量のデータ転送を無線資源を浪費することなく実行することが可能となる．そして宛先

2. 従 来 研 究が見つかったら，運搬された保存データは転送される．このよ2. 1 関 連 研 究ノードと呼ぶ）を用いて，端末とフェリーノード間で通信を行DTN 技術を用いた研究は数多く検討されている．

うことでデータ転送を可能とする方法をメッセージフェリー方[6] ではバッテリの残量から転送先を動的に選択し，被災地式と呼ぶ [9]．

うに，メッセージ転送を目的とした移動端末（以下，フェリー内の情報を被災地外へ運び出す災害時通信システム構築法の提既存の DTN フレームワークとしては IBR-DTN [10] があ

案がなされている．この研究では広域災害時により通信インフり，組み込みシステムへの実装に対する研究等がなされていラが機能しない場合に，避難所にいる被災者の安否情報や被災る [11]．

状況などの情報を収集し，メッセージフェリー方式を用いて被災地の外へ運び出すことを想定している．このとき避難所内の移動端末の通信では，バッテリ残量が多い端末へデータが集ま

3. 災害時の想定環境るようにデータ転送先が動的に選択される．これにより，特定災害時の通信環境として，サーバ機能付 Wi-Fi アクセスポの移動端末に負荷が集中することを防ぎ，ネットワーク持続時イントを用いた無線メッシュ/ DTN システム（図 1）を想定し間を長期化することを目指している．ている．このシステムは，平常時ではサーバ機能付 Wi-Fi ア

この研究では，フェリーノードが避難所に滞在する時間をクセスポイントが一般的なアクセスポイントとして機能してい300 ~ 600 秒とあらかじめ設定しているが，災害時においてこるが，災害が発生すると通常時モードから非常時モードに切りの値が適切かは考慮していく必要があると考える．また，運ぶ替わることで，無線で他のアクセスポイントに接続するようにデータをサイズが 50 ~ 150KB と小さいものとしているため，なる．これにより，使えなくなった経路が発生しても稼働して画像などのサイズが大きなデータは想定されていない．

いる一部のサーバ機能付 Wi-Fi アクセスポイントと DTN 技[7] ではモバイルアドホックネットワーク (MANET) と DTN術を用いて継続的に接続，再構成を繰り返し，送信先に達するの異なる 2 つのネットワーク形成技術を高度に融合した端末間までノードからノードへ転送を行って目的端末まで情報を到達通信技術が提案されている．これは変化する周囲の状況にあわさせることを可能とする．よって，大規模災害などによって地せて適切なネットワークモードを自動的に判断して切り替わる

域的にインターネット接続が切れている場合でも通信が可能とことで，通常は圏外で通信不可能な環境であっても効率的な通なる．本研究ではこのような環境を想定して検討を行う．

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

2. 2 DTN
DTN は遅延耐性ネットワークとも呼ばれ，物理的なリンク

図1

サーバ機能付 Wi-Fi アクセスポイントを用いた無線メッシュ/DTN システムの切断やデータの送受信遅延に対応していない TCP/IP 技術を拡張させた「中継転送技術」である [8]．この一般的な手法は「届きそうな」端末にデータを送信し，端末間でデータをホップ

4. 災害時通信システムさせていくことで目的端末まで届かせるというものである．これにより，中断や切断が多発したり，極端に長い通信遅延が生現在でも災害時では，紙媒体を用いて安否確認を行うことがじたりするような劣悪な通信環境下でもデータ転送を実現する少なくない．2011 年 3 月に発生した東日本大震災においても，ことができる．代表的な技術として蓄積運搬形転送がある．

避難所の様子を見てみると白板や壁に紙を張り付けるなどしてこの技術は，まず宛先に届きそうなノードにデータを転送し，安否情報を記している人が多くみられた．つまり，災害時には次に中継ノードにデータを蓄積する．この一時的な蓄積によこうした紙媒体で表された情報をうまくまとめることが必要とり，再開を待つ，あるいは最適なタイミングを待つことができなってくる．

時間的不連続性に対応できる．さらに蓄積されたデータを物理

そこで，本研究では各避難所に設置されたサーバ機能付き的に，例えば自動車や列車を用いて運搬する．この運搬によっ

Wi-Fi アクセスポイントとフェリーノードを用いて，白板等にて空間的不連続性に対応でき，また，運搬によって無線通信の記された安否情報を撮影した写真を同期させるシステムを考—2—

表1

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

画像と文字の違い環する際に情報の蓄積や運搬もする事を想定し，そのノードをフェリーノードとしている．以下にその概要を示す (図 2)．

1) 避難所に避難している人々は従来通り，白板や壁に安メリット

文字

紙媒体の情報を画像としてサイズが小さい（120byte）

残せる

否情報を書いた紙を貼るなどして安否情報を表す．

2) 安否情報が記された白板等を撮影した写真は，避難所

画像

デメリット

画像ならではの安心感

情報を整理しやすい

サイズが大きい（3MB）

入力が負担に設置されたサーバ機能付き Wi-Fi アクセスポイントに保存される．このとき，接続しているアクセスポイント同士は，自動的に同期される．

3) 未接続なサーバ機能付き Wi-Fi アクセスポイント同士は，フェリーノードが情報を運ぶことにより同期される．

5. データサイズによる通信時間比較
災害時通信で画像を扱う上で難点となるのは，データサイズが大きいことであると予想できる．そこで，データのサイズによってどの程度通信速度が異なるのか，シミュレーションによる比較を行った．

5. 1 シナリオ概要
シナリオは図 3 のような，2.5km 四方の道路を想定した．左上の隅に アクセスポイント を 1 台設置し，そこでは 40 個のバンドルが 2000 秒かけて生成される．フェリーノードはバンドルの生成が終わると右下の隅から動き始め，時速 28.8 〜46.8km で止まらずに 2 周道路を時計周りに回ってから元の位置に戻る．実験の設定詳細は表 2 で示す．
このとき，シミュレーション時間を 5000 秒とし，AP で生図 2 災害時通信システム概要

成されるバンドルのサイズを 120 byte， 3MB と変えた場合のフェリーノードのバンドル受信数の推移について調べた．

4. 1 通信で扱う対象について現在用意されている，災害時安否確認掲示板の多くは文字データを扱っている．文字データを扱うことの大きなメリットは，データサイズが小さく，また，データベース等で管理がしやすいという点である．しかし，文字データはスマートフォンやパソコン等の機器を用いて入力するため，そうした機器に不慣れな人にとっては大変な作業である．災害時で余裕がない状況では，こうした入力作業はユーザにとって大きな負担になると考える．
そこで本研究では，通信で扱う対象として画像を考えた．そうすることで，避難所の白板等に貼られた安否情報の写真を撮

図3

通信時間比較シナリオることで情報をまとめられるため，被災者は普段と違った行動をしなくて済む．また，無機質な文字データではなく，画像で

表 2 通信速度比較シナリオの環境視覚的にデータを伝えることができるのでその人自身が書いたシミュレーション時間

5,000 秒文字を見ることができ，被災者に安心感を与えられるのではな

範囲

2.5km × 2.5km

いかと考えた．（表 1 にそれぞれのメリットとデメリットについてまとめた．
）
しかし，画像を扱う上の大きな懸念点として，データサイズがアクセスポイントの台数1台生成するバンドル数

40 個

バンドルのサイズ

120byte or 3MBフェリーノードの台数

1台

フェリーノードの速度

時速 28.8 〜 46.8kmと，名前や簡単な状況を伝えるだけならば，1 つあたり 120byte

各ノードの送信電力10dBm(10mW)ほどで扱うことでできる．一方，画像の場合は，スマートフォ

無線 LAN 規格

IEEE802.11g大きいということがあげられる．安否情報を文字データで表す

ンで撮影した写真は 1 枚あたり約 3MB となり，文字データに比べとても大きいことがわかる．よって，災害時で画像を扱う通信を考えるには，データサイズに注意する必要があると考える．

—3—

5. 2 シミュレーション結果

6 白浜中央保険センター敷地に設置されたサーバ機能付
いが，⃝フェリーノードのバンドル受信数の推移を図 4 で示す．

き Wi-Fi アクセスポイントと通信が行われ，2 箇所は同期がな

バンドルサイズが 120byte の場合は，シミュレーション時されているものとする．

間 2500 秒ほどの 1 回目の通信で，40 個全てのバンドルをフェシナリオの設定詳細は表 3 で示す．

リーノードが受信できている．
一方，バンドルサイズが 3MB の場合は，2 回の通信では全てのバンドルの受信が完了しておらず，各通信で 7 個ずつのバンドルしか受信できていない．このことから，バンドルサイズが大きくなると，正しくやり取りをするにはその分，通信時間が長く必要になることがわかった．よって，災害時における画像を扱った通信システムのシミュレーション評価を行うためには，通信時間を考慮する必要があると考える．

図 5 実地図を用いたシナリオ

表3

図 4 フェリーノードのバンドル受信数

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

シミュレーション時間

86,000 秒

範囲

2.0km × 2.0km

避難所の数

21 箇所

アクセスポイントの台数

21 台

生成するバンドルの総数

517 個(詳細は表 4 を参照)

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

アクセスポイントの送信電力

10dBm(10mW)

バンドルのサイズ

3MB

フェリーノードの台数

1台

フェリーノードの速度

時速 28.8 〜 46.8km

無線 LAN 規格

IEEE802.11g

6. 1 シナリオ概要
シナリオには，約 2km 四方の南紀白浜地域で地震が発生し，発生後に 21 箇所の避難所に人々が避難している状況を想定す

表4

各避難所の生成バンドル数

避難所 (収容人数)

生成バンドル数

熊野三所神社敷地 (1500)

50

白浜第一小学校敷地 (500)16

各避難所にはサーバ機能付き Wi-Fi アクセスポイントが設

民宿まるき別館 (500)16

置され (図 5 で記された赤いマークが設置場所である．），そこ

ラメール白浜 (500)

16には白板等に記された安否情報を撮影した写真がバンドルとし共同墓地 (1000)

33

江津良初期避難場所 (400)12

番所山 (2000)

66

り，各避難所の生成バンドル数は収容人数によって表 4 のよう常喜院敷地 (2000)

66になっており，その総計は 517 個となっている．フェリーノー

白浜中央保険センター敷地 (500)16

ドは 1 〜 2 台あり，バンドルの生成が完了する 4000 秒後から

はまゆう病院敷地 (1000)33

右中央の start 地点から動き始め，時速 28.8 〜 46.8km で各

白浜第二小学校敷地 (500)

16

ホテルシーモア駐車場 (500)16

福菱ビル (600)

20に書かれた番号順であり，2 台目はこの逆順に回る．各避難所

ネピアル白浜 (400)12では，フェリーノード自身が保持していないデータをアクセス

サニーヒル (800)26

ポイントから全て受信し，かつ，自身が保持していてアクセス

白浜中学校敷地 (500)16

る．避難している人々は，従来通り，白板等を用いて安否情報を記している．て保存されている．バンドル 1 つあたりの大きさは 3MB であ避難所を巡回する．1 台目のフェリーノードの回る順番は図 5

ポイントが保持していないデータを全て送信し終わってから次の避難所に移動するが，設定した滞在時間を越えた場合は送受信が完了していなくても次の避難所へ移動する．
災害時を想定しているため，各アクセスポイントの送信電力

ぱる敷地 (200)6

コガノベイホテル敷地 (500)

16

修道院金閣寺敷地 (1000)

33

ゲートボール場 (500)16

ホテル川久 (500)16は 10dBm（10mW）とした．また，使用できなくなる道路が9 熊野三所神社敷地にフェリーノードはたどり着けな発生し，⃝—4—

6. 2 シミュレーション結果
最大滞在時間を 10 分，20 分，制限なし，と設定し，フェリーノードが 1 〜 2 台の場合における，各避難所に設置されたサーバ機能付き Wi-Fi アクセスポイントの同期率の平均と分散の推移を，それぞれ図 6，図 7 で示す．ここでは，各アクセスポイントの保有バンドル数が生成されたバンドルの総数である 517 個になった場合を，同期が完了し，同期率が 1 であるとしている．
図 6 から，フェリーノードの台数が多い方が同期率の平均は
図7高いが，滞在時間の制限が 10 分と 20 分の場合では時間の長さ

各 AP の平均同期率によって大きな差が生じていないことがわかった．また，滞在時間に制限がある場合は，同期率が高くなるにつれてグラフの傾きが小さくなっており，フェリーノードが少ない方が同期率

7. まとめと今後の課題が収束し始めるタイミングが早いことがわかる．一方，制限がない場合は，フェリーノードの台数に関係なく最終的には全て大規模災害によって地域的にインターネットが機能しないのアクセスポイントの同期が完了しているが，同期完了までになど，劣悪な条件下でも，部分的に稼動しているサーバ機能付

かかる時間はフェリーノードが 2 台のときは約 13 時間，フェWi-Fi アクセスポイントと DTN 技術を利用した，災害時通信リーノードが 1 台のときは約 1 日であり，フェリーノードが 2システムの評価シナリオを実地図を用いて構築した．

台の場合の方が大幅に早いことが読み取れる．
図 7 から，滞在時間に制限がある場合は，分散が小さく，それぞれのアクセスポイントの同期率のばらつきが少ないことがわかる．一方，制限がない場合は同期率の差が激しく，全てのアクセスポイントの同期完了が早かったフェリーノード 2 台で全てのノードに対する同期の完了を効率よく行うためには，フェリーノードの滞在時間に制限をつけるのではなく，通信時点でその都度同期を行っていく方がいいと推測できた．
今後はこのシナリオを拡張し，より細かく通信性能を評価していく．

滞在時間に制限なし，のときが最もばらつきが見られた．つまり，制限時間がない場合は，同期完了が早い分，同期できてい謝

辞るアクセスポイントとできていないアクセスポイントの差が大きいということが確認できた．
災害時での安否情報は重要なため，同期率は 1 であるべきだと考える．よってこの場合のフェリーノードの動作は，送受信が完了してから次に移動する，といった挙動が適切だと推測できた．ただし，滞在時間に制限がない場合は最大で 3800 秒近本研究の一部はお茶の水女子大学と情報通信研究機構との共同研究契約に基づくものである．
また，本研究を進めるにあたり，有用なアドバイスを頂いた（株）スペースタイムエンジニアリングの前野誉氏に深く感謝致します．

く 1 箇所に留まってしまったり，同期率にばらつきが生じてしまった．そのため，情報を速く伝達することを優先させたい場
合や均等に同期率を上げたい場合，バンドルが時間経過によって増え続け完全に同期を完了してから移動するのが難しい場合など，状況に応じて最適な送信方法が変わる可能性も考えられる．また，滞在時間とバンドルの受信数から，1 つのバンドルを送信するには約 7 秒かかることが予想できた．

図 6 同期が完了した AP の台数

文

献[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 リレー - 圏外でも通信可能なデュアルモードアドホックネットワーク技術 - ”，東北大学電気通信研究機構シンポジウム，2013 年 7 月.
http://www.roec.tohoku.ac.jp/info/news/pdf/NJ00067.pdf[7] 鶴正人，内田真人，滝根哲哉，永田晃，松田崇弘，巳波弘佳，山村新也 ”DTN 技術の現状と展望” 通信ソサイエティマガジン，
No.16[春号]，pp.57-68，2011.
[8] 金田知展，中村嘉隆，高橋修 ” DTN を用いた災害時通信システム構築法の提案”，マルチメディア，分散，協調とモバイル(DICOMO2013) シンポジウム，pp.964-969，2013 年 7 月.
http://www.fun.ac.jp/ y-nakamr/research/dicomo/
dicomo2013kaneta.pdf[9] Zhao，W.，and Ammar，M.H. ” Message Ferrying:Proactive—5—

Routing 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.
[10] IBR-DTN
https://bousai.goo.ne.jp/apps/[11] 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.

—6—