DEIM Forum 2019 I7-2 WebRTC, UCLA Computer Science Department 3803 Boelter Hall, Los Angeles, CA

(1)

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]．基地局や基幹ネットワークが災害により破損，機能不全となってしまうとインターネットに繋がらない，もしくは衛星回線等によりインターネット接続回線が非常に細くなることにより，通

(2)

信による情報共有ができなくなってしまう．また現場のニーズとして，避難所においてサブネットが集まった際に，それらを繋げていきたいというものがあった．そこで，非常時に寄り集まったサブネット間でインターネットワーキングの構成を実現し，大規模災害時に有用な情報通信システムが必要だと考えた．特に今回は無線LANに参加している端末同士がメッセージ・ファイルなどのデータ共有を行えるような情報共有システムに着目した．通常，既存の個人や小規模な組織単位で利用されるネットワークの多くは，プライベートネットワークを構成し，NAT(Network Address Translator)ルータを介してインターネットに接続されている．そこでこれらのプライベートネットワークには何も手を加えず，NATルータ同士がインターネットを介さずにアドホックに自律的にネットワークを構成し，接続できる通信基盤の構築を提案する．その際，他のプライベートネットワークのノード同士で電話やメッセージ等のP2P通信を実現する手法を検討する．例としては，現場のニーズとして避難所においてサブネットが集まった際や発生した緊急車両間のプライベートネットワーク同士，災害時に臨時に構築した避難所間のプライベートネットワーク同士をアドホックに接続した場合などを想定している．解決策として，震災時にはNATルータに端末が繋がっている環境がいくつも孤立しているため，その孤立したプライベートネットワーク間を繋げ，端末間での通信による情報共有を提案する．そのためNATルータに仕掛けを作ることで通信基盤の構築を行い，そしてNAT越え技術を応用し，孤立したプライベートネットワーク同士をチャットシステムで繋げられるような仕組みを作るのが現実的に最も有用であると考えられる（図 1）．図 1 目標図

2.

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ルータを利用して端末同士の通信を可能とする．しかしプライベートネットワーク下にあるアドレスには外部

(3)

ネットワークからの直接接続が不可能であるため，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）という．

(4)

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に繋がっている端末同士が情報共有を行うことが可能になる．現在，このような通信環境を想定した実験環境を構築した．その実験環境を次の章で紹介する．

(5)

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] 中村功．”大規模災害と通信ネットワーク –東日本大震災に思う–”

(6)

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 月．

DEIM Forum 2019 I7-2 WebRTC, UCLA Computer Science Department 3803 Boelter Hall, Los Angeles, CA