DEIM Forum 2019 I7-2

災害時のインターネット非接続環境におけるWebRTCを活用した臨時ネットワークの実現

田中 有彩† 前野 誉†† 大和田泰伯††† 高井 峰生††††,††††† 小口 正人†

† お茶の水女子大学 〒 112-8610 東京都文京区大塚 2-1-1

†† 株式会社スペースタイムエンジニアリング 〒 101-0025 東京都千代田区神田佐久間町 3-27-3

††† 情報通信研究機構 〒 980-0812 宮城県仙台市青葉区片平 2-1-3

†††† UCLA Computer Science Department 3803 Boelter Hall, Los Angeles, CA 90095-1596, USA

††††† 大阪大学 〒 565-0871 大阪府吹田市山田丘 1-5

E-mail: †{tanaka.arisa,oguchi}@is.ocha.ac.jp, ††tmaeno@spacetime-eng.com, †††yowada@nict.go.jp,

††††mineo@ieee.org

あらまし 災害時，ネットワークの通信不能などは多くの人々に不安と困惑を招く恐れがある．また現場のニーズとして，避難所においてサブネットが集まった際に，それらをネットワークの再設定なしで繋げたいというものがあった．そこで本研究ではこの環境を利用した，非常時に寄り集まったサブネット間による臨時ネットワークの実現，そして災害時に有用な情報通信システムの構築を目的とする．本稿では中でもWebRTCを活用し，インターネットに繋がっていない環境下にも対応した通信基盤の構築，そしてその上に乗せるアプリケーションの開発を行った．そして実際に，インターネットに繋がっていない環境下での実験を行った．キーワード WebRTC，災害，P2P

Realization of Temporary Network Utilizing WebRTC

in Disconnected Internet Environment in Case of Disaster

Arisa TANAKA†, Taka MAENO††, Yasunori OWADA†††, Mineo TAKAI††††,†††††, and Masato

OGUCHI†

† Ochanomizu University　 2-1-1 Otsuka, Bunkyouku, Tokyo 112-8610 JAPAN

†† Space-Time Engineering　 KandaSakumacho 3-27-3, 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 Computer Science Department 3803 Boelter Hall, Los Angeles, CA 90095-1596, USA

††††† Osaka University　 1-5 Yamadaoka, Suita-city, Osaka 565-0871 JAPAN

E-mail: †{tanaka.arisa,oguchi}@is.ocha.ac.jp, ††tmaeno@spacetime-eng.com, †††yowada@nict.go.jp,

††††mineo@ieee.org

1. は じ め に

現在，インターネットは人々にとって欠かせない生活の一部となっており，重要な情報インフラとして広く普及している．中でも多くの人が通話や電子メール，SNSなど，他の人と連絡を取る手段としてインターネットを利用している．そのため，災害時のネットワーク設備の物理的破損による通信不能や，多

数の人が一斉に安否を確かめるために発生する輻輳などの通信障害などは多くの人々に不安と困惑を招いてしまう．特に地震大国である日本にとって，その影響は大きいと言える [1]．通信障害の主な原因は，基地局や基幹ネットワークである [2]．基地局や基幹ネットワークが災害により破損，機能不全となってしまうとインターネットに繋がらない，もしくは衛星回線等によりインターネット接続回線が非常に細くなることにより，通

— 1 —

信による情報共有ができなくなってしまう．また現場のニーズとして，避難所においてサブネットが集まった際に，それらを繋げていきたいというものがあった．そこで，非常時に寄り集まったサブネット間でインターネットワーキングの構成を実現し，大規模災害時に有用な情報通信システムが必要だと考えた．特に今回は無線 LANに参加している端末同士がメッセージ・ファイルなどのデータ共有を行えるような情報共有システムに着目した．通常，既存の個人や小規模な組織単位で利用されるネットワー

クの多くは，プライベートネットワークを構成し，NAT(Network

Address Translator)ルータを介してインターネットに接続されている．そこでこれらのプライベートネットワークには何も手を加えず，NATルータ同士がインターネットを介さずにアドホックに自律的にネットワークを構成し，接続できる通信基盤の構築を提案する．その際，他のプライベートネットワークのノード同士で電話やメッセージ等の P2P通信を実現する手法を検討する．例としては，現場のニーズとして避難所においてサブネットが集まった際や発生した緊急車両間のプライベートネットワーク同士，災害時に臨時に構築した避難所間のプライベートネットワーク同士をアドホックに接続した場合などを想定している．解決策として，震災時には NATルータに端末が繋がってい

る環境がいくつも孤立しているため，その孤立したプライベートネットワーク間を繋げ，端末間での通信による情報共有を提案する．そのため NATルータに仕掛けを作ることで通信基盤の構築を行い，そしてNAT越え技術を応用し，孤立したプライベートネットワーク同士をチャットシステムで繋げられるような仕組みを作るのが現実的に最も有用であると考えられる（図1）．

図 1 目 標 図

2. 関 連 研 究

現在，NATの外部から内部のネットワークへ通信を開始できないという NAT越え問題に対する研究が多くなされている．

[3] では，外部ノードとホームゲートウェイが連携することにより NAT 越え問題を解決する従来の NAT-f(NAT-free

protocol) の誰でもホームネットワーク内の内部ノードにアクセスできてしまうという課題に対し，サービス単位でグルーピングすることにより，外部ノードからのアクセス制御と内部ノードが提供するサービスの制御を同時に実現できることが示されている．

[4]では，DNSサーバと NATルータを利用して両者を協調させることにより NAT越えを実現する方式が提案されている．その提案方式は NTS(NAT-Traversal Support) システムと呼ばれており，DNSサーバを改造したNTSサーバ，NATルータを改造した NTSルータ，実行するプロトコルとして NTSプロトコルが使用されている．また端末の機能追加が必要な NAT-f

とは異なり，一般のユーザ端末に機能を追加することなく，かつエンドエンドで NAT越えを実現できる方式である．

[5]では，STUNでは本来対応することができないシンメトリック型 NATを STUNを拡張することで超えて，NATの外側から TCP通信を開始する手法の実装が行われている．どの関連研究も NATルータとは別にサーバを用意することで，NAT超えを行なっており，またプライベートネットワーク同士での NAT超えではなくプライベートネットワークと外部のネットワーク間での NAT超えとなっている．そのため，本研究の特徴とも言える NATルータ自体に仕掛けを作るという点・またプライベートネットワーク同士での NAT超えは非常に有益だと考えられる．

3. 提案システム

提案するシステムは，災害などによりインターネットが使えず相手と連絡が取れない状況において，無線 LANに参加している端末同士がメッセージ・ファイルなどのデータ共有を可能にするものである．このシステムの実現のため，通信基盤の構築・その上で使用するアプリケーションの開発を行った．3. 1 通 信 基 盤具体的には，Wi-Fi AP兼 NATルータ (以降Wi-Fiルータと呼ぶ)を用い，そこから無線 LANを飛ばすことで基地局や基幹ネットワークなどの影響を受けないプライベートネットワークをWi-Fiルータごとに構築し，プライベートネットワークを通して通信を行う．つまりWi-Fiルータ同士のモバイル・アドホックネットワーク (MANET)を構築する．ここで，MANET

とは基地局や固定網に依存せず，移動端末を構成要素とする自律分散形のネットワークである [6]．既存の施設や設備を必要とせずにネットワークを構成できるという利点にも関わらず，なかなか実用化はされていない．これは，MANETを利用した多くのものが，端末側での事前準備を必要とする方式であったことが一因であると言える．そこで通常の MANETは端末同士間でネットワークを構成することが多いが，今回は先ほど述べたようにWi-Fiルータ同士でネットワークを構成する．つまり，この仕組みを端末自体に作るのではなく，Wi-Fiルータ自体に作ることで，Wi-Fiルータ同士の MANETを構築し，端末側に手を加えること無くWi-Fiルータを利用して端末同士の通信を可能とする．しかしプライベートネットワーク下にあるアドレスには外部

— 2 —

ネットワークからの直接接続が不可能であるため，NAT超え技術を利用する．今回の NAT超え技術として STUN/TURN

サーバ・シグナリングサーバを利用する．端末は通信相手を特定するため，STUN/TURNサーバ，シグナリングサーバをアドホックに見つけ出し，NAT越え通信を実現する．続いて端末同士で P2P 通信を行うシステムには We-

bRTC(Web Real-Time Communication) を用いた．これはブラウザ上でビデオ通話などのリアルタイムコミュニケーションを実現するためのフレームワークである．WebRTCを用いることで，プラグインなしでウェブブラウザ間のボイスチャット，ビデオチャット，ファイル共有などが利用可能である．また直接相手と通信する P2P型通信，NAT超えを実現する仕組みなどが含まれている．しかしウェブブラウザは全てに対応しておらず，Chrome，Firefoxなどと限られてはいるが，専用アプリケーションのインストールの不要，大量のデータを高速に送ることができる，通信は DTLSが採用されており暗号化がなされているといった利点を持つ．これにより，無線 LANに参加している端末同士のメッセージ・ファイルなどのデータ共有を可能にする．3. 2 アプリケーションアプリケーションとして，WebRTCによる無線 LANに参加している端末同士でのメッセージ・ファイルなどのデータ共有を目的としてチャットシステムを開発した．図 2は実際の画面となっており，図 3が使用している画面となっている．またこれはパソコンからアクセスすることを想定している．大まかな使用方法は以下の通りである．

（ 1） APから出ている無線 LANに接続（ 2） ブラウザ（Chromeまたは Firefox）を開き，サイトを開く（ 3） ユーザ名を入力し，Connectボタンを押すことで通信が開始（ 4） メッセージを入力し，リアルタイムで繋げている通信相手が ”Send to 名前” というふうにボタンに現れるため，通信したい相手へのボタンを押し送信（ 5） ファイルの場合は，通信相手の名前が書いてある枠の中にある接続というボタンをもう一度押し，通信の成功を待つ（ 6） 成功したら送りたいファイルを入れ，相手の承認を待ち，許可されたら送信が行われる

4. P2P (Peer to Peer)方式

P2P方式とは，ネットワーク上で対等な関係にある端末間を相互に直接接続し，データを送受信する方式 (図 4)である．また，そのような方式を用いて通信するソフトウェアやシステムの総称でもある．特定のサーバを用意して情報をやり取りするクライアント・サーバ方式 (図 5)などと対比される用語で，利用者間を直接繋いで音声やファイルを交換するシステムが実用化されている．これにより，特定のサーバを介さずに，端末同士の通信を可能にする．

図 2 情報共有アプリケーション

図 3 実際に使用している様子

図 4 P2P 方 式

図 5 クライアント・サーバ方式

5. NAT越え技術とWebRTC

5. 1 NAT越え多くの端末はプライベートネットワークに所属して NAT配

下にあり，端末から外のネットワークへ通信をすることが通常である．しかし逆に，外から NAT配下の端末へ直接通信することはできない．この問題を解決する手法を NAT越え（NAT Traversal）と

いう．

— 3 —

5. 2 STUNと TURN

STUN (Session Traversal Utilities for NATs) とは，NAT

越えの方法の一つである．通信するホストが STUN サーバにUDP接続を行い，NATが割り当てたグローバル IPアドレスとポート番号を取得する．NATの種類にはフルコーン型・制限コーン型・ポート制限コーン型・シンメトリック型と全部で4種類ある (表 1)．STUNが対応できる NATは，フルコーン型・制限コーン型・ポート制限コーン型の 3つに限られる．表 1から分かるように，表が下に行くほど利用制限が厳しく

なっている．特に一番厳しいシンメトリック型は STUNで対応できない．そのため，シンメトリック型には TURN(Traversal

Using Relay NAT)を使用することで，全ての NATに対応する．しかしすべての通信をTURNサーバ経由で行うため，P2P通信ではなくなり，またサーバにも高負荷が掛かってしまう．

表 1 NAT の種類　種類名 NAT が割り当てたポートにアク

セスできるインターネット側の端末の制限

利用制限の厳しさ

フルコーン型 どの端末でもアクセス可 緩やか制限コーン型 NAT 配下の端末がアクセスした

端末からアクセス可厳しめ

ポート制限コーン型 NAT 配下の端末がアクセスした端末とポート番号からだけアクセス可

制限コーン型より厳しい

シンメトリック型 通信元の端末と通信先の端末が 1

対 1 の場合にしか使えないかなり厳しい

5. 3 WebRTC

WebRTC(Web Real-Time Communications)とは，ブラウザでリアルタイムコミュニケーションを実現するための仕組みである．つまり，P2P通信を利用して端末間の相互接続が可能である．プロトコルには UDPが使われているため，高速な通信ができる．WebRTCによる P2P通信をするためには，シグナリングと ICE(Interactive Connectivity Establishment) が必要である．シグナリングとは，通信相手の IPアドレス情報やポート番

号等の情報を解決する手法である．ICEは後述する NAT越え通信のためのセッション確立のための情報交換を行うプロトコルである．

5. 4 NAT越えと P2P通信WebRTCを用いてプライベートネットワーク内の端末同士

の P2P 通信を行うためには， NAT 越えが必要となる．この時，シグナリングと ICEという仕組みが利用される．端末同士が P2Pセッションを確立するには，シグナリングにより通信相手の IPアドレスや接続ポート番号等の情報を互いに交換しなければいけないため，どちらの端末からもアクセスできるシグナリングサーバが必要となる．ICEとは STUNや TURNなどの NAT越えの手順をまとめ

たものであり，通信できそうな候補を集め，シグナリングにより相手とその候補を交換し，相手との通信を試みる仕組みである．また，通常のネットワークにおける STUNによる P2P通信を図 6に，TURNによる通信を図 7に示す．

図 6 STUN による P2P 通信

図 7 TURN によるサーバ経由通信

6. 想 定 環 境

災害時の通信環境を想定したものを図 8に示す．この時，プライベートネットワーク同士が NATルータを介してアドホックに接続した際に自律的にシグナリングサーバ，STUN/TURN

サーバを一意に検出し，NAT越えの P2P通信による情報共有が行える仕組みを備えたWi-Fiルータを用いることを想定している．災害時においてインターネットに繋がらない状況でも，この

NATルータのWi-Fiにつなぐことで，Wi-Fiに繋がっている端末同士が情報共有を行うことが可能になる．現在，このような通信環境を想定した実験環境を構築した．その実験環境を次の章で紹介する．

図 8 想 定 環 境

— 4 —

7. ローカル環境における実験

インターネットが遮断された中で，アプリケーションが実際に動くかを確認するため，次のような実験を行った．そこでまず使用するエッジサーバについて説明する．7. 1 使用するエッジサーバ現在使用しているエッジサーバは以下の通りである (図 9)．

また DTN技術については今後新たなシステムの開発を考慮しているため，含んでいる．

• OSは Debian GNU/Linux を利用• シグナリング・STUN/TURNを搭載• 実システムの構築とシステム解析・連携をサポートする

汎用的なプラットフォーム• ネットワークを自律的に構築• DTN技術より実システム間での情報同期を可能とする

図 9 使用しているエッジサーバ

7. 2 実 験 環 境本研究では，先ほど紹介したアプリケーション， STUN兼

TURN サーバが構築できるオープンソースソフトウェアである coturn，そして上記のエッジサーバを用い，実験用のローカル環境を構築した．またエッジサーバはローカル環境のサーバとして機能させている．その環境を図 10に示す．これにより，災害時などのインターネットが遮断された中での実験を模擬的に行う．

図 10 実 験 環 境

無線 LANを搭載したエッジサーバ 2台にそれぞれ hostapd

をインストールし，Wi-Fiルータとして動作させた．これにより 2つの異なるプライベートネットワークを作成している．Clientとしては Androidスマートフォン 1台・PC1台をそ

れぞれ別のエッジサーバに繋げて設置した．IP アドレスはそれぞれ DHCPによって取得する．サーバとして，片方のエッジサーバのポート番号 8080に開発

したシグナリングサーバ，ポート番号 3478に STUNサーバ，そしてポート番号 3479に TURNサーバである coturnをそれぞれ構築した．またシグナリングサーバにおける STUN/TURN

サーバの設定は，同サーバ内のポート番号 3478・3479とした．2台のエッジサーバは無線 LANでつなぎ，同じネットワーク内となっているため，ネットワークは全部で青・赤・緑の 3つとなっている．そして，サーバはクライアントがお互いにチャットができるかどうかを判断する．これらを通して，インターネットがない状況下においてでも，チャットが可能であるかを確認する．7. 3 実 験 結 果結果として，クライアント同士での P2P 通信にはならず，

クライアントとエッジサーバ間での TCPによるローカルな通信となった．そのため，STUN/TURNは使用されていなかったが，チャット・ファイル同士の通信は可能であることが分かった．

8. まとめと今後の課題

災害時などのネットワークが切れてしまった際，各サブネットが集まった時にどのように対応していくかという背景に対し，災害時に有用な情報通信システムの提案・構築を行った．中でも NAT越えによる避難者同士のチャットシステムを考案し，それに対応するため通信基盤の構築・アプリケーションの開発を行った．そしてネットワークが切れてしまった環境を模擬的に実現した実験を行った．結果として，ローカル環境におけるチャットシステムが通信可能であり，使用出来る事が確認できた．今後の課題は，まずはローカル通信になってしまったため，

STUN/TURN が使用されない原因の究明，そして親玉 NAT

サーバによる管理について考察していく．特にローカル通信について，よりネットワーク環境に着目し，詳しく検討していく．

謝 辞

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

CREST JPMJCR1503の支援を受けたものである．　

文 献[1] 内閣府防災情報．”首都直下地震の被害想定と対策について”

http://www.bousai.go.jp/jishin/syuto/taisaku_wg/pdf/

syuto_wg_report.pdf．[2] 中村 功．”大規模災害と通信ネットワーク –東日本大震災に思

う–”

— 5 —

http://nakamuraisao.a.la9.jp/CIAJ.pdf．[3] 鈴木秀和，渡邊晃” 通信グループに基づくサービスの制御が可能

な NAT 越えシステム”，マルチメディア，分散，協調とモバイル (DICOMO2009) シンポジウム，pp.372-378，2009年 7月．

[4] 宮崎悠，鈴木秀和，渡邊晃” 端末に依存しない NAT 越えシステムの提案と実装”，マルチメディア，分散，協調とモバイル(DICOMO2008) シンポジウム，pp.587-592，2008 年 7 月．

[5] 黒田隼之輔，中山泰一” TCP における STUN を用いた対称型NAT 越え手法の実装と評価”，情報処理学会全国大会講演論文集，73rd，p.3.421-3.422，(2011)．

[6] 間瀬憲一”モバイル・アドホックネットワーク”，シンポジウム(47)，pp.13-26，2002 年 3 月．

[7] H. Soliman, ”Mobile IPv6 Support for Dual Stack Hosts and

Routers,” RFC5555, IETF, 2009.

[8] R. Moskowitz, T. Heer, P. Jokela, and T. Henderson, ”Host

Identity Protocol Version 2 (HIPv2),” RFC7401, IETF,

2015.

[9] WebRTC

https://webrtc.org/．[10] coturn

https://github.com/coturn/coturn．[11] Sam Dutton.(2013,November 4).WebRTC in the real world:

STUN, TURN and signaling.

[12] ”Real time communication with WebRTC” Google Devel-

opers．[13] 本橋 史帆，高井 峰生，大和田 泰伯，前野 誉，小口 正人: 「サー

バ機能付き Wi-Fi AP を利用した平常時/非常時の情報共有システムの提案と検討」，DEIM2016，B8-6，2016 年 3 月．

— 6 —