DEIM Forum 2019 I7-1

XMPP を用いた災害時の臨時分散情報支援システムにおける管理対策の実現
YUHUI†

大和田泰伯††

小口正人†† お茶の水女子大学 〒 112-8610 東京都文京区大塚 2-1-1†† 情報通信研究機構 〒 980-0812 宮城県仙台市青葉区片平 2-1-3
E-mail: †{yu.hui,oguchi}@is.ocha.ac.jp, ††yowada@nict.go.jp
あらまし

インターネットとスマートフォンは現在生活に欠かせない一部分になった．情報の収集手段とし，平常時であっても，災害時であっても，電子メール，SNS 等の伝達方法が優先的に考えられている．しかし，地震等の自然災害が起きた際に，インターネットインフラが断片的に切断されることにより，インターネットに強く依存しているアプリケーションが使えなくなる可能性がある．避難情報や生活情報等の支援情報を被災者に伝達することが必要であるとともに，被災程度を支援者に報告することも不可欠である．そのため，本研究では災害時のネット環境を考え，断片的なネットワークや XMPP（Extensible Messaging and Presence Protocol）[1] を用いたサーバを利用し，情報支援を目指し，臨時分散システムの管理対策を検討する．
キーワード XMPP, インターネット非接続, 情報支援, 管理対策ムの一つであり，広く使われている．開発経験の弱い開発者で1 はじめに現在，インターネット及びスマートフォンの急速な普及に伴い，その関連技術及びスマートフォンのアプリケーションが現代生活に欠かせない一部分になった．よって，情報の収集手段として，平常時であっても，災害時であっても，伝統的な電話網やラジオだけではなく，電子メール，SNS などのインターネットを介する方法が優先的に選ばれている．
近年，日本は自然災害が多く発生している．災害時に，インターネットインフラが断片的に切断されることにより，被災地のインターネットが利用不能になる可能性が高い．その上，インターネットに強く依存しているアプリケーションも使えなくなる．

も利用しやすい．又，Android に基づくアプリケーションの開発環境は全て無償で提供されている．
現在，様々なサービスはアプリケーションを介してユーザに提供されている．アプリケーションを利用すれば，収集した情報は何時でも，何処でも見えるため，非常に便利な方式である．
本研究では，災害時の混乱状況に合う通信機能が付き，インターネットに依存しすぎない情報支援システムを開発する．そのため，Android ベースのアプリケーションで，ユーザにサービスを提供する．

2. 2 XMPPXMPP とは，アプリケーションに対応可能なリアルタイム（Real-Time）通信用のオープン XML 技術である．無償で提供

しかし，災害時に，避難情報や生活情報等の支援情報を被災されている．オープンソースのため，拡張性が強く，利用者は者に伝達することが必要であるとともに，被災者の被災程度を自らの需要により，XML ストリームの様式を書き直すことが支援者に報告することも不可欠である．つまり，安定かつ快速できる．

な情報の伝達や共有手段が必要である．

XMPP ネットワーク中にユーザ名の重複率が高い．混乱

そのため，本研究では断片的なネットワーク及び XMPP をを避けるため，XMPP は JID [3] を利用している．JID とは用いたサーバを利用した．大規模災害時の情報支援を目指し，「username@admin.com」というメールアドレスのような仕様

臨時分散情報共有システムの管理対策を提案する．又，実現ので表示されるアカウントである．よって，サーバはユーザ名のため，仮想環境下で，この提案システムの実装実験や情報共有重複を考えず，XMPP ネットワークに簡単に追加することが手法の実装・評価実験を行う．

できる．そして，メッセージを転送するため，全てのメッセー
ジは XMLstanza [4] を標準として，パッケージされる．

2 関連技術
2. 3 Openfire
2. 1 Android ベースのアプリケーション

Openfire [5] とは，XMPP に基づくインスタントメッセージ

Android [2] とは，Google が開発したモバイルオペレーティを利用しているサーバの一つである．操作が簡単で，基本的なングシステムである．Linux カーネル及びオープンソースソフ通信機能が付いており，プラグインがサポートできるため，拡トウェアがベースで，主にスマートフォン等に向けにデザイン張性が高い．

されている．最も人気のあるモバイルオペレーティングシステ

Openfire は Apache MINA [6] を使用しているため，メッセー—1—

ジの受け取り及びタイプの判断と処理が別々に行われる．開発者はソケット (socket) と NIO（Java new I/O）の複雑な操作を考えず，処理の機能やロジックに集中することができる．

Openfire はフェデレーションというサーバ間の接続方式がある．フェデレーション [7] により，独立のデータベースを使用するサーバ同士が XMPP ネットワークになる．この XMPP
ネットワーク中のサーバはピアサーバと呼ばれる．ピアサーバ
同士は発信，受信及び情報の交換が自由にできるようになる．
本研究ではプラグインを作成し，Openfire サーバに災害時に合う機能を追加する．

2. 4 DTN 技術
DTN(Delay Tolerant Networking) [10] は，従来の TCP/IP
図 2 ユーザ管理の提案

技術を拡張させた，遅延耐性のネットワークである．現在，様々な研究領域に応用させている．

DTN 技術は蓄積形転送のため，バンドル (Bundle) 層と吸収

3. 1 ユーザ管理の提案

層 (Convergence Layer) を従来の TCP/IP 技術に引き込んで図 2 のように，ユーザの管理対策を提案する．

いる．移動端末（フェリーノード）を用い，発信者からの情報各避難所で，サブサーバはユーザに通信サービスを提供する．

集を保管し，目的地の受信者に運搬し，届きそうな端末にデータを転送する．
現在の TCP/IP 通信技術は，インターネット・インフラに依存している技術であり，災害時のインターネット・インフラが壊れたことによる通信途絶に対応できなくなる．本研究ではDTN 技術を用い，災害時の通信が途絶えた状況下の情報共有の手段として検討する．

ユーザはアプリケーションでデータの収集を行う．
そのため，アプリケーションは「登録とログイン」，「情報管理」，「掲示板」や「チャット」の４つの仕組みを導入する．

1 「登録とログイン」
スマートフォンを持たない人でも使えるようになるため，登録とログインの仕組みを導入する．

2 「情報管理」
利用者にシステムの通信範囲やサーバの関連情報を届ける．

3 提案手法図 1 のように情報支援システムの管理対策を提案する．
管理者と利用者の２種類を想定し，それぞれ支援者と被災者に対応する．アプリケーションによって通信サービスを提供し，ユーザを管理する．そして，管理サーバとサブサーバの２種類を想定し，それぞれ災害対策本部や避難所に分散して設置する．又，避難所同士の接続を管理するため，接続認証手法を提案する．
続いて，ユーザの管理対策や接続の認証手法を詳しく説明する．

さらに，被災者は自らの被災程度を支援者に届けるため，情報管理の仕組みを導入する．

3 「掲示板」
災害時の情報類別が多く，多数の避難者が取得したい情報は災害関連情報，避難関連情報，医療関連情報及び生活支援情報のように分けられる．類別によって，発信者が違う．そのため，情報類別によって，専門的な発信者を指定し，被災者に情報支援が提供される掲示板の機能を導入する．

4 「チャット」
避難者は，各々の状況によって需要が違う．問い合わせのため，一対一のチャット機能を導入する．

3. 2 情報共有の提案
災害時の劣悪なネットワーク環境下，情報支援のため，対応できる情報共有手法が欠かせない．しかし，災害の規模によって，被災地のインフラの被害状況が異なり，情報共有の手法も異なる．そのため，本研究では２つの情報共有手法を提案する．
災害によって，バックボーン・ネットワークは強い影響を受けるが，通信可能の一部分が存在している場合に，こちらのネットワーク・インフラを利用し，接続セキュリティを守る上に，情報共有の可能範囲を広げる接続認証手法を提案する．
図 1 情報支援システムの提案手法

又，大規模な災害による通信途絶えが発生した場合に，DTN技術を用いて，情報を運搬・伝送するという情報共有の手法を提案する．
次に，２つの提案手法を詳しく説明する．

—2—

3. 2. 1 接続認証手法
図 3 のように，避難所同士の接続方式を提案する．
災害時の不安定な接続環境に対応するため，接続認証が必要である．管理サーバはサブサーバの追加と削除及び情報の共有を責任とする．そして，分散されたサブサーバ同士の接続セキュリティを守ることや情報共有の可能な範囲を守るバランスをとるため，以下のように接続認証手法を提案する．

図 4 DTN を用いた情報の運搬・共有手法の提案

図 3 避難所同士の接続方式(1) 管理サーバは認証したサブサーバを「Server-List」に追加し，ピアサーバ同士に知らせる．

(2) ピアサーバとは，「Server-List」に追加したサブサーバである．全てのピアサーバは同じ「Server-List」を持つ．

(3) 管理サーバが稼働している場合に，管理サーバはピア

図 5 サブサーバ１-ノード-サブサーバ２の間データ通信の流れサーバの間での直接接続リクエスト及び，サブサーバの追加・削除を管理する．ピアサーバは同期させたい情報を管理サーバへ送信し，管理サーバは受け取った情報を整理して各ピアサーバに送信する．

ることである．SE(”send-end”) と表記させる．受信完了とは，受信完了を返信することである．RE(”receive-end”) と表記させる．

(4) 管理サーバが遮断された場合に，情報を共有するため，データの送信を行う前に，サブサーバはノードからの索引を「Server-List」によって，ピアサーバの間で直接接続を行う．こ

受け取り，情報集を識別することができる．一つの索引は一つの場合に，サブサーバの追加・削除ができなくなる．の情報集に対応し，データの重複を防ぐことができるようにする．

3. 2. 2 DTN を用いた情報共有の手法
接続認証手法はインターネットに強く依存しないが，基礎的4 実験環境なネットワークインフラが必要である．通信が途絶えた場合に，情報共有ができなくなると考えられる．そのため，次に，DTNを用い，情報の運搬・伝送という情報共有の手法を提案する．
前に述べた情報支援システムの構成によって，図 4 のように，ノードサーバを用いた情報共有の方式を提案する．
情報を運搬する際に，サブサーバ１-ノード-サブサーバ２を一例として，データ通信の流れを図 5 に示す．
送信準備とは，送信リクエストを伝送するというメッセージである．データのサイズ，受信者アドレス，発信者アドレス等の情報を含め，SR(”send-ready”) と表記させる．受信準備とは，RR(”receive-ready”) と表記される受信リクエストである．ノードサーバは受信用の索引 (”index”) を送信し，受信を準備する．情報集の送信とは，共有情報を伝送することである．

S(”sending”) と表記させる．送信終了とは，送信完了を通知す

多数のサーバと端末機の使用を想定しているため，全て実物を用いることは難しい．そのため，本研究では図 6 のように，MacPC や PowerEdgeR430 を用い，実験環境を構築した．

Virtualbox を利用し，管理者と利用者の端末機２台及び管理サーバ１台とサブサーバ９台の仮想環境を構築した．
仮想端末機は異なる IP アドレスを持ち，実際のネットワーク空間とつながっている．仮想マシンは GNS3 [8] 内のサーバと接続されており，仮想空間にあるものとする．そして，GNS3は仮想のネットワーク空間と実際のネットワーク空間が接続されている．
端末機はアンドロイドに基づき，作成したアプリケーションを実装した．各サーバは Openfire4.1.5 や独立なデータベースを搭載し，それぞれのプラグインを実装した．
実験環境の仕様は図 1 に示す．

—3—

て，被災者は自らの被災程度をシステムに報告することもできるようになる．

(3) 図 10 は掲示板機能を示す．
災害時に，避難情報，生活応援情報や医療情報等の様々な情報の類別がある．人によって選びたい情報の類別が違うが，同じ類別の情報で共有部分がある．作業効率を上げるため，掲示板の仕組みを作成した．内容によって，重要な情報を掲示板に載せ，ユーザに公開され，知りたい情報を選ぶことができるようになる．
又，情報の信憑性を考え，掲示板を作る前に，身元確認を行う必要がある．こちらは特別な識別子を入力するように設定される．同時に，掲示板の発信内容の説明も一緒にサブサーバへ送信する．
掲示板を作成したら，図 11 のように発信ができるようになる．「掲示板リスト」によって，同じサブサーバに登録した掲
図6 実験環境表1 仕様示板であっても，異なるサブサーバに登録した掲示板であっても，見えるようになる．

(4) 図 12 はチャットの仕組みを示す．
被災者によって欲しい情報が異なるため，掲示板に情報を載せるだけでは足りないという可能性を考えた．問い合わせが必要となることから，チャット機能を作成した．
真ん中の図のように，全ての管理者が連絡先リストに追加さ
図 7 のように，それぞれのプラグインを示す．

れ，同じサブサーバの管理者であっても，異なるサブサーバの管理者であっても，自由に連絡ができるようになる．

図 7 作成したプラグイン
図 8 アプリケーションのログイン機能と登録機能5 実験結果
5. 1 アプリケーションの細部
各避難所のユーザはアプリケーションで情報を収集する．作
成されたアプリケーションの仕組みは以下通りである．

(1) 図 8 は登録とログイン機能を示す．
登録する際に，管理者にするか，利用者にするかを選ベる仕5. 2 共有情報の同期
表 2 のように，３つの情報が同期され，システム内に共有されている．これにより，ネットワーク環境の安定時に，被災者は全システム内の管理者と自由に通信ができるようになる．
表 2 共有情報の内容と対応するアプリ組みを作った．身元確認のため，管理者として登録した場合，特別な識別子を入力する必要がある．
そして，ログインする際に，一つのアカウントは一人のユーザと対応しているため，スマートフォンを持たない人でも本アプリケーションを使うことができるようになる．

(2) 図 9 は情報管理の仕組みを示す．
情報管理の仕組みによって，システムの情報が見える．そし—4—

バ同士に知らせる．情報を転送する際や接続と再接続を行う際に，「サーバリスト」によって，相手を確認することができる．

3 「掲示板メッセージ」
掲示板メッセージリストには，掲示板のメッセージが記入されている．このシステムを利用しているユーザは，何時でも重要な情報を見逃さないようになる．

5. 3 管理サーバのウェブページ
図 13 に，管理サーバのウェブページを示す．

1 「管理者リスト」「管理者リスト」から，登録した管理者の情報や掲示板を管理することができるようになる．
図 9 アプリケーションの情報管理機能

2 「サブサーバの管理」「サブサーバの管理」から，新たなサブサーバの追加や削除を管理することができるようになる．

3 「サーバリスト」「サーバリスト」とは，システム内のピアサーバの詳しい接続状況が見えるようになる．
これにより，被災対策本部の係員はシステムを管理することができるようになる．

図 10 アプリケーションの掲示板機能 1

図 11 アプリケーションの掲示板機能 2

図 13 管理サーバのウェブページ

5. 4 接続認証の評価実験
非常時の不安定なネット環境に応じ，様々な状況を考えなければならない．表 3 のように主に四つの可能性を考え，表を作成した．結果は接続環境が安定した後にシステム内の通信可能なサーバの台数として示す．
図 12 アプリケーションのチャット機能

この表によって，管理サーバであっても，サブサーバであっても，インフラなどの原因により，実際に遮断された時だけ，

1 「管理者情報」
管理者リストとは，システム内の全ての管理者の情報やそれぞれ作成した掲示板の説明が表示されているリストである．

2 「サーバ情報」
サーバリストには，システム内のピアサーバが記入され，サー接続が回復できなくなる．他の場合には，システム内の接続が自動的に回復することができる．又，新たなサーバがシステムに追加される際に管理サーバが必要である．
本接続認証手法によって，接続セキュリティが守られる上，状況が許す限り情報の共有範囲を限定せず，管理サーバが利用可能な場合には，拡大する可能性がある．

—5—

表 3 接続管理の評価実験

でも，情報の運搬・共有ができることがわかる．そこで，災害によって，通信が途絶えた場合でも，本提案手法は有効に働くことが期待できる．

6 まとめと今後の課題
災害時に，情報支援に対応するため，被災者と支援者が繋がることのできるシステムの管理対策を提案した．この提案は２つの部分から成る．ユーザ管理に対し，各避難所でアプリケーションによる通信サービスが提供することを提案した．そして，

5. 5 DTN を用いた情報共有手法の実装実験

各避難所同士で情報の交換ができるようにするため，又，分散された避難所同士の接続セキュリティと情報共有の可能範囲を

図 14 のように，接続されていないサブサーバ１とサブサー守るバランスが取れるようにするため，接続認証方式を提案しバ２の間で，情報を共有するため，ノードサーバを介し，情報た．最後に，仮想環境で，システムを実装し，接続認証の評価の運搬・共有実験を行う．又，情報集のデータサイズを変化さ実験を行った．

せ，実験を繰り返す．

今後は実物を利用し，システムの評価実験を行う．又，提案した接続認証方式と DTN を用いた情報共有方式の性能を改善する．

謝

辞

本研究で UCLA の高井峰生先生から有用なアドバイスをいただきました．また，本研究は一部，JST CREST JPMJCR1503の支援を受けたものです．ここに感謝の意を表します.

文
図 14 シミュレータ環境下の実験環境

ノードサーバが受信準備のリクエストを受け取った時から，ファイルがノードに格納されるまでの時間はアップロード時間とする．目的地のサブサーバが受信準備のリクエストを受け取った時から，ファイルが格納されるまでの時間はダウンロード時間とする．アップロード時間とダウンロード時間を合算したものは伝送時間とする．
結果は図 15 のように示す．

献[1] XMPP technology, urlhttps://en.wikipedia.org/wiki/XMPP,2018 年 2 月参照．
[2] What is android, 2011 , urlhttp://www.academia.edu/download/30551848/andoid–tech.pdf , 2018 年 2 月参照．
[3] XEP-0029: Definition of Jabber Identifiers (JIDs), 1999
2017, Craig Kaes, urlhttps://xmpp.org/extensions/xep0029.html, 2017 年 10 月参照．
[4] XEP-0226:Message Stanza Profiles, Justin Karneges, PeterSaint-Andre, 1999 2017 XMPP Standards Foundation,
urlhttps://xmpp.org/extensions/xep-0226.html , 2018 年 2月参照．
[5] Openfire, a real time collaboration (RTC) server, urlhttps://www.igniterealtime.org/projects/openfire/, 2017 年10 月参照．
[6] Apache MINA is a network application framework whichhelps users develop high performance and high scalability
network applications easily. urlhttps://mina.apache.org/,
2017 年 10 月参照．
[7] Trust Management of XMPP Federation, Simon N. Foley and Wayne Mac Adams, urlhttp://www.cs.ucc.ie/ simon/pubs/manfed2011.pdf ,2018 年 2 月参照.
[8] ”The Book of GNS3: Build Virtual Network Labs Using
Cisco, Juniper, and More”, Jason C. Neumann,pp51-58,2015 , 2018 年 8 月参照．
[9] Genymotion, urlhttps://www.genymotion.com/ , 2018 年 8月参照.
[10] DTN 技術の現状と展望,@2011 , 鶴 正人, 内田 真人, 滝根 哲哉,
永田 晃, 松田 崇弘, 巳波 弘佳, 山村 新也, ,2018 年 12 月参照.

図 15 実装実験の結果

このグラフから，DTN 技術を用い，直接接続されない場合—6—