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 EngineeringKandaSakumacho 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 JAPANE-mail: †{tanaka.arisa,oguchi}@is.ocha.ac.jp, ††tmaeno@spacetime-eng.com, †††yowada@nict.go.jp,††††mineo@ieee.org

1. は じ め に数の人が一斉に安否を確かめるために発生する輻輳などの通信障害などは多くの人々に不安と困惑を招いてしまう．特に地震

現在，インターネットは人々にとって欠かせない生活の一部大国である日本にとって，その影響は大きいと言える [1]．通信となっており，重要な情報インフラとして広く普及している．

障害の主な原因は，基地局や基幹ネットワークである [2]．基

中でも多くの人が通話や電子メール，SNS など，他の人と連絡地局や基幹ネットワークが災害により破損，機能不全となってを取る手段としてインターネットを利用している．そのため，しまうとインターネットに繋がらない，もしくは衛星回線等に災害時のネットワーク設備の物理的破損による通信不能や，多よりインターネット接続回線が非常に細くなることにより，通—1—

信による情報共有ができなくなってしまう．また現場のニーズprotocol) の誰でもホームネットワーク内の内部ノードにアクとして，避難所においてサブネットが集まった際に，それらをセスできてしまうという課題に対し，サービス単位でグルーピ繋げていきたいというものがあった．そこで，非常時に寄り集ングすることにより，外部ノードからのアクセス制御と内部まったサブネット間でインターネットワーキングの構成を実現ノードが提供するサービスの制御を同時に実現できることが示し，大規模災害時に有用な情報通信システムが必要だと考えた．

されている．

特に今回は無線 LAN に参加している端末同士がメッセージ・[4] では，DNS サーバと NAT ルータを利用して両者を協調ファイルなどのデータ共有を行えるような情報共有システムにさせることにより NAT 越えを実現する方式が提案されている．

着目した．

その提案方式は NTS(NAT-Traversal Support) システムと呼通常，既存の個人や小規模な組織単位で利用されるネットワー

ばれており，DNS サーバを改造した NTS サーバ，NAT ルータ

クの多くは，プライベートネットワークを構成し，NAT(Networkを改造した NTS ルータ，実行するプロトコルとして NTS プロ

Address Translator) ルータを介してインターネットに接続さトコルが使用されている．また端末の機能追加が必要な NAT-f

れている．そこでこれらのプライベートネットワークには何もとは異なり，一般のユーザ端末に機能を追加することなく，か手を加えず，NAT ルータ同士がインターネットを介さずにアつエンドエンドで NAT 越えを実現できる方式である．

ドホックに自律的にネットワークを構成し，接続できる通信基[5] では，STUN では本来対応することができないシンメト盤の構築を提案する．その際，他のプライベートネットワークリック型 NAT を STUN を拡張することで超えて，NAT の外のノード同士で電話やメッセージ等の P2P 通信を実現する手側から TCP 通信を開始する手法の実装が行われている．

法を検討する．例としては，現場のニーズとして避難所においどの関連研究も NAT ルータとは別にサーバを用意することてサブネットが集まった際や発生した緊急車両間のプライベーで，NAT 超えを行なっており，またプライベートネットワーク

トネットワーク同士，災害時に臨時に構築した避難所間のプラ同士での NAT 超えではなくプライベートネットワークと外部イベートネットワーク同士をアドホックに接続した場合などをのネットワーク間での NAT 超えとなっている．そのため，本想定している．

研究の特徴とも言える NAT ルータ自体に仕掛けを作るという解決策として，震災時には NAT ルータに端末が繋がっている環境がいくつも孤立しているため，その孤立したプライベー点・またプライベートネットワーク同士での NAT 超えは非常に有益だと考えられる．

トネットワーク間を繋げ，端末間での通信による情報共有を提案する．そのため NAT ルータに仕掛けを作ることで通信基盤の構築を行い，そして NAT 越え技術を応用し，孤立したプライ

3. 提案システム

ベートネットワーク同士をチャットシステムで繋げられるよう提案するシステムは，災害などによりインターネットが使えな仕組みを作るのが現実的に最も有用であると考えられる（図ず相手と連絡が取れない状況において，無線 LAN に参加して1）．

いる端末同士がメッセージ・ファイルなどのデータ共有を可能にするものである．このシステムの実現のため，通信基盤の構築・その上で使用するアプリケーションの開発を行った．

3. 1 通 信 基 盤
具体的には，Wi-Fi AP 兼 NAT ルータ (以降 Wi-Fi ルータと呼ぶ) を用い，そこから無線 LAN を飛ばすことで基地局や基幹ネットワークなどの影響を受けないプライベートネットワー
クを Wi-Fi ルータごとに構築し，プライベートネットワークを通して通信を行う．つまり Wi-Fi ルータ同士のモバイル・アドホックネットワーク (MANET) を構築する．ここで，MANETとは基地局や固定網に依存せず，移動端末を構成要素とする自律分散形のネットワークである [6]．既存の施設や設備を必要とせずにネットワークを構成できるという利点にも関わらず，なかなか実用化はされていない．これは，MANET を利用した
図1 目

標 図

多くのものが，端末側での事前準備を必要とする方式であったことが一因であると言える．そこで通常の MANET は端末同士間でネットワークを構成することが多いが，今回は先ほど述2. 関 連 研 究
現在，NAT の外部から内部のネットワークへ通信を開始できないという NAT 越え問題に対する研究が多くなされている．

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

べたように 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 超えを実現する仕組

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

みなどが含まれている．しかしウェブブラウザは全てに対応しておらず，Chrome，Firefox などと限られてはいるが，専用ア
プリケーションのインストールの不要，大量のデータを高速に送ることができる，通信は DTLS が採用されており暗号化がなされているといった利点を持つ．これにより，無線 LAN に参加している端末同士のメッセージ・ファイルなどのデータ共有を可能にする．

3. 2 アプリケーションアプリケーションとして，WebRTC による無線 LAN に参加している端末同士でのメッセージ・ファイルなどのデータ共有を目的としてチャットシステムを開発した．図 2 は実際の画面となっており，図 3 が使用している画面となっている．またこ
図 3 実際に使用している様子

れはパソコンからアクセスすることを想定している．大まかな使用方法は以下の通りである．
（ 1 ） AP から出ている無線 LAN に接続（ 2 ） ブラウザ（Chrome または Firefox）を開き，サイトを開く（ 3 ） ユーザ名を入力し，Connect ボタンを押すことで通信が開始

図 4 P2P 方 式（ 4 ） メッセージを入力し，リアルタイムで繋げている通信
相手が ”Send to 名前” というふうにボタンに現れるため，通信したい相手へのボタンを押し送信（ 5 ） ファイルの場合は，通信相手の名前が書いてある枠の中にある接続というボタンをもう一度押し，通信の成功を待つ（ 6 ） 成功したら送りたいファイルを入れ，相手の承認を待ち，許可されたら送信が行われる

4. P2P (Peer to Peer) 方式

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

P2P 方式とは，ネットワーク上で対等な関係にある端末間を相互に直接接続し，データを送受信する方式 (図 4) である．ま5. NAT 越え技術と WebRTC

た，そのような方式を用いて通信するソフトウェアやシステムの総称でもある．特定のサーバを用意して情報をやり取りする

5. 1 NAT 越え

クライアント・サーバ方式 (図 5) などと対比される用語で，利多くの端末はプライベートネットワークに所属して NAT 配用者間を直接繋いで音声やファイルを交換するシステムが実用下にあり，端末から外のネットワークへ通信をすることが通常化されている．これにより，特定のサーバを介さずに，端末同である．しかし逆に，外から NAT 配下の端末へ直接通信する士の通信を可能にする．

ことはできない．
この問題を解決する手法を NAT 越え（NAT Traversal）という．

—3—

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

図 6 STUN による P2P 通信る．しかしすべての通信を TURN サーバ経由で行うため，P2P通信ではなくなり，またサーバにも高負荷が掛かってしまう．
表 1 NAT の種類
種類名NAT が割り当てたポートにアク利用制限の厳しさセスできるインターネット側の端末の制限
フルコーン型

どの端末でもアクセス可

緩やか制限コーン型

NAT 配下の端末がアクセスした

厳しめ

端末からアクセス可
ポート制限コーン型 NAT 配下の端末がアクセスした 制限コーン型より厳しい端末とポート番号からだけアクセス可シンメトリック型

通信元の端末と通信先の端末が 1

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

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

5. 3 WebRTC
WebRTC(Web Real-Time Communications) とは， ブラウ
ザでリアルタイムコミュニケーションを実現するための仕組みである．つまり，P2P 通信を利用して端末間の相互接続が可能

6. 想 定 環 境
災害時の通信環境を想定したものを図 8 に示す．この時，プである．プロトコルには UDP が使われているため，高速な通ライベートネットワーク同士が NAT ルータを介してアドホッ信ができる．WebRTC による P2P 通信をするためには，シグクに接続した際に自律的にシグナリングサーバ，STUN/TURNナリングと ICE(Interactive Connectivity Establishment) がサーバを一意に検出し，NAT 越えの P2P 通信による情報共有必要である．

が行える仕組みを備えた Wi-Fi ルータを用いることを想定してシグナリングとは，通信相手の IP アドレス情報やポート番いる．

号等の情報を解決する手法である．ICE は後述する NAT 越え

災害時においてインターネットに繋がらない状況でも，この通信のためのセッション確立のための情報交換を行うプロトコ

NAT ルータの Wi-Fi につなぐことで，Wi-Fi に繋がっているルである．

端末同士が情報共有を行うことが可能になる．現在，このよう

5. 4 NAT 越えと P2P 通信
WebRTC を用いてプライベートネットワーク内の端末同士な通信環境を想定した実験環境を構築した．その実験環境を次の章で紹介する．の P2P 通信を行うためには， NAT 越えが必要となる．この時，シグナリングと ICE という仕組みが利用される．端末同士が P2P セッションを確立するには，シグナリングにより通信相手の IP アドレスや接続ポート番号等の情報を互いに交換しなければいけないため，どちらの端末からもアクセスできるシグナリングサーバが必要となる．

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

図8 想定環境—4—

7. ローカル環境における実験
インターネットが遮断された中で，アプリケーションが実際に動くかを確認するため，次のような実験を行った．そこでまず使用するエッジサーバについて説明する．

7. 1 使用するエッジサーバ

無線 LAN を搭載したエッジサーバ 2 台にそれぞれ hostapdをインストールし，Wi-Fi ルータとして動作させた．これにより 2 つの異なるプライベートネットワークを作成している．

Client としては Android スマートフォン 1 台・PC1 台をそれぞれ別のエッジサーバに繋げて設置した．IP アドレスはそれぞれ DHCP によって取得する．

現在使用しているエッジサーバは以下の通りである (図 9)．

サーバとして，片方のエッジサーバのポート番号 8080 に開発

また DTN 技術については今後新たなシステムの開発を考慮ししたシグナリングサーバ，ポート番号 3478 に STUN サーバ，そているため，含んでいる．

してポート番号 3479 に TURN サーバである coturn をそれぞ•

OS は Debian GNU/Linux を利用れ構築した．またシグナリングサーバにおける STUN/TURN•

シグナリング・STUN/TURN を搭載

サーバの設定は，同サーバ内のポート番号 3478・3479 とした．

•

実システムの構築とシステム解析・連携をサポートする

2 台のエッジサーバは無線 LAN でつなぎ，同じネットワーク内汎用的なプラットフォームとなっているため，ネットワークは全部で青・赤・緑の 3 つと•ネットワークを自律的に構築なっている．そして，サーバはクライアントがお互いにチャッ•

DTN 技術より実システム間での情報同期を可能とするトができるかどうかを判断する．これらを通して，インターネットがない状況下においてでも，チャットが可能であるかを確認する．

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

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

けるチャットシステムが通信可能であり，使用出来る事が確認

本研究では，先ほど紹介したアプリケーション， STUN 兼できた．

TURN サーバが構築できるオープンソースソフトウェアであ

今後の課題は，まずはローカル通信になってしまったため，る coturn，そして上記のエッジサーバを用い，実験用のローカ

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

ル環境を構築した．またエッジサーバはローカル環境のサーバサーバによる管理について考察していく．特にローカル通信にとして機能させている．その環境を図 10 に示す．これにより，ついて，よりネットワーク環境に着目し，詳しく検討していく．

災害時などのインターネットが遮断された中での実験を模擬的に行う．

謝

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

文

図 10 実 験 環 境

献[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 andRouters,” RFC5555, IETF, 2009.
[8] R. Moskowitz, T. Heer, P. Jokela, and T. Henderson, ”HostIdentity 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 Developers．
[13] 本橋 史帆，高井 峰生，大和田 泰伯，前野 誉，小口 正人: 「サーバ機能付き Wi-Fi AP を利用した平常時/非常時の情報共有システムの提案と検討」，DEIM2016，B8-6，2016 年 3 月．

—6—