複数回線を冗長併用する通信技術のWebRTC映像伝送への適用と評価
Applying and Evaluating Multipath Redundant Communication Technology for WebRTC-based Video Streaming
1. 背景と目的
モバイルネットワークの普及および性能の向上を承けて通信機能を備えた自動車であるコネクティッドカーの普及が進んでいる．コネクティッドカーはWi-Fiやモバイル網に接続する機能を持ち，テレマティクスサービスやオペレータサービスを可能としている．車載通信機能が提供するメディア伝送に充分な通信帯域を活用して，遠隔監視のみならずメディア伝送を行い遠隔運転に活用する検討がなされている．既存のモバイル通信サービスは端末からのアップロード通信において数十Mbps程度の可用帯域で利用が可能である[1]．この帯域幅は，例としてIntel RealSense*1でサポートされる1080 pの映像を複数伝送するのに充分な帯域幅である．
一方で，移動体であるコネクティッドカーの通信環境は常に変動し続け，遠隔運転に充分な通信品質を維持できないことがある[2]．コネクティッドカーは公道を中心とした環境での稼働が想定されており，通信手段は3G/4G/5Gモバイル通信サービスに依存している．これらの通信サービスでは基地局との距離や見通し，エリアを同じくする他の通信端末，モバイル網およびゲートウェイの通信状況によりパケットのロスや遅延，可用帯域が変化する．
このような環境下で遠隔運転システムを実現するためには，遠隔からの操作に用いる車両の視覚情報および聴覚情報を，遠隔地のオペレータに対して品質を高く，かつ可用性を高く伝送する仕組みが必要である．本稿では，「品質が高い」とは視覚情報および聴覚情報が高精細であり低遅延に届くこと，「可用性が高い」とは伝送が途切れることなく安定していることと定義する．音声・映像情報をやりとりするメディア伝送には，DASH（Dynamic Adaptive Streaming over HTTP） [3]やSRT（Secure Reliable Transport） [4]といった様々なプロトコルおよび技術が存在している．これらの技術の中で最も低遅延なフレームワークとしてWebRTCがある．WebRTCは従来のサーバ・クライアント型の技術とは異なり，メディア伝送をサーバを介さずにP2Pで実施することで音声・映像伝送の低遅延化を実現している．WebRTCを利用することで遠隔運転に必要な低遅延なメディア伝送を実現できる可能性がある．
しかし，前述のとおり車両の通信環境は移動に伴い変化しづつけるため，1つの通信手段では車両とオペレータ端末間の通信品質を維持できない．通信の可用性を向上するためには，複数の異なる通信手段を利用し通信状況に応じて使い分けるなどの仕組みが必要である．一方で，従来のTCPやUDPといった通信プロトコルは1つの通信手段を想定しているため複数の通信手段が利用できる状況下でもそれらを活用できない問題がある．そこで筆者らは，複数の通信手段を併用する技術であるマルチパス通信技術を採用したトランスポート層以下の通信の可用性向上を目指す．マルチパス通信技術は複数の通信手段にまたがった連続的な通信により可用性を向上し，品質を補い合うことでパケットロスを低減し可用帯域を増加させ通信品質の向上を可能とする．また，マルチパス通信技術は通信制御の柔軟性向上が可能である．本稿では，「通信制御の柔軟性」とはそれぞれの通信手段が提供する可用帯域や遅延特性などの通信資源をアプリケーションの需要に応じて分配できることと定義する．WebRTCをこのマルチパス通信技術のうえで利用することで，遠隔運転システムが必要とする視覚情報・聴覚情報の低遅延な伝送と高い可用性といった通信要件を実現できると考えられる．
筆者らは，低遅延メディア伝送が可能なWebRTC技術に対してマルチパス通信技術を組み合わせ通信品質およびメディア伝送品質の向上を可能とする手法の提案を文献[5]にて行った．文献[5]ではマルチパス技術とWebRTCとの連携を実現し，提案手法がWebRTCのメディアストリームごとに通信手段を選択でき通信制御の柔軟性向上に寄与することを示した．提案したマルチパス通信手法の骨子は，1. IP ToS値を用いたメディアストリームの識別，2．マルチパス通信技術導入による通信選択肢の多様化，3．メディアストリームごとのパス利用形態制御，の3点である．
本稿では，マルチパス通信技術を複数回線による冗長化に用いる検証を，文献[5]では実施できなかった遠隔運転システムが対象とする環境を模擬して行った．市街地を走行する自動車から映像伝送を実施する実験と評価を行った．
本稿の構成は以下のとおりである．2章では関連研究を紹介する．3章では提案する手法およびシステムについて述べる．4章で提案手法の評価環境について述べる．5章では評価結果のまとめと考察を行う．最後にまとめと今後の課題について整理する．
2 関連研究
マルチパス通信技術および研究の代表的な例として，Multipath TCP（MPTCP） [6]，MP-QUIC [7]，MP-DCCP [8]が存在する．既存の研究では，トランスポート層が輻輳制御および再送制御を実装している．本研究は，WebRTCのトランスポートプロトコルであるUDPを対象としてマルチパス技術を導入する．輻輳制御および再送制御はWebRTCが搭載するGoogle Congestion Control（GCC） [9]に一任し，マルチパス制御のみを行う点が異なる．
文献[10]が提案するMP-UDPは，本研究と同様にUDPを対象としたマルチパス技術を提案し，シミュレーションによる検証を行っている．本研究では，車載走行環境でWebRTCを対象に検証を行う点が異なる．
文献[11]は，移動する鉄道列車環境において複数のモバイル通信回線を併用するためにMPTCPを適用している．本研究は，同じく複数のモバイル通信回線を用いて走行環境を対象とした検証を行う．一方で，自動車の走行環境を対象としている点，UDPトラフィックおよびWebRTCを対象とする点，アップロード通信におけるマルチパス技術の適用および検証を行う点が異なる．
文献[12]は，ビデオ配信システムにモバイル通信とWi-Fiを対象にしたMP-QUICの利用を提案しており，本研究と同じくマルチパス通信技術をメディア伝送に用いる．本研究は，複数モバイル通信回線環境を対象とする点，輻輳制御機能を備えたQUICではなくWebRTCをアプリケーションとしてUDPを対象とする点，車載環境にあるモバイル通信端末からのWebRTCを用いたアップロード方向のメディア伝送を対象とする点が異なる．モバイル通信環境で端末からみたダウンロードとアップロードの実効スループット特性は異なるため[1]，マルチパス技術の適用においても異なる手法が求められると考えられる．
文献[13]は，複数の通信手段を用いるMulti-Connectivity（MC）技術のサーベイを行っており，複数回線併用を実現するレイヤ，活用するダイバーシチおよび併用が行われるホップ数に基づいた分類を行っている．本研究の提案手法はMC技術の1つであり，複数のモバイル通信回線を用いて周波数ダイバーシチおよび空間ダイバーシチを活用し，同じ無線通信技術（3G/4G/5G）を併用する．本研究は，通信サービス事業者ごとに異なるネットワークを経由しマルチホップ環境での複数回線併用を行う．また本研究は，トランスポート層でMC技術を実現し，パケット複製の検証を行う．モバイル通信回線を想定してパケット複製を行うMC技術として3GPP Dual Connectivity技術の研究[14]-[16]が存在する．本研究と異なりDual Connectivity技術は，ネットワーク層よりも下の層で実現され1つのモバイル事業者の網内を対象としている．本研究では，複数の異なるモバイル通信事業者のサービスを組み合わせることでカバレッジエリアおよび通信品質の補い合いを行う．
3. 提案手法
3.1 システム構成
筆者らが文献[5]において提案するシステムの構成を図1に示す．本システムはWebRTCを対象としてマルチパス技術を導入するため，プロキシ方式で実装する．マルチパス通信を行う端末（クライアント端末）と中継サーバのそれぞれにおいてUDPプロキシを動作させることで，プロキシ間の通信路の制御を可能とする．本UDPプロキシを，マルチパスUDPプロキシと呼称する．
Fig. 1 Block diagram of proposed multipath proxy system.
マルチパスUDPプロキシはクライアントとサーバから構成される．プロキシのクライアント側はアプリケーションから受信したトラフィックをIP ToSにより識別し，端末が備える通信手段を1つ以上用いてサーバへ転送する．サーバは，クライアントから転送された通信の集約制御と順序制御を行い，プロキシ先のアプリケーションに転送する．本稿では，マルチパスUDPプロキシのクライアント側をMultipath UDP Proxy（MUP）クライアント，サーバ側をMUPサーバと呼称する．
車載通信環境で用いられるWebRTCを対象としてマルチパスUDPプロキシを導入する場合，車側にMUPクライアントを導入し，端末間通信の中継に用いるTraversal Using Relay around NAT（TURN）サーバ機能を提供する中継サーバ端末にMUPサーバを導入する．
3.2 回線の冗長利用
本研究は，複数回線を冗長し可用性と品質を向上するためにマルチパス技術を用いる．MUPクライアントは，アプリケーションから受信したUDPパケットをそれぞれの通信手段へ複製して送出し，MUPサーバへ転送する．本研究ではこの動作を回線の冗長利用と呼称する．プロキシは転送時に各パケットにシーケンス番号を付与する．MUPサーバは，シーケンス番号が常に増加するよう古いパケットおよび重複パケットの排除を行い，アプリケーションに転送する．複数のパスから同一のパケットが到来する場合，最初に受信したパケットが採用される．MUPサーバは受信パケットのシーケンス番号が1つずつ増加することを期待する．これに反して2つ以上増加する場合，パケットが受信できずシーケンス番号の欠損が発生していると本稿では呼称する．MUPサーバはシーケンス番号が欠損した場合，未受信のシーケンス番号を記録する．MUPサーバは，未受信として記録された古いシーケンス番号を持つパケットが後から到着した場合，最初のパケットを採用する．これらのシーケンス番号が古いパケットの受信を，本研究ではアウトオブオーダー[17]受信と呼称する．
WebRTCはトランスポートプロトコルとしてUDPを用いており，輻輳制御および再送制御はGCCが実施する．低遅延メディア伝送を目的として再送制御および順序制御はマルチパスUDPプロキシでは実施しない．本システムでは機能を重複させないこととしそれらの制御はWebRTC側に一任し，マルチパス制御のみを行う．
4. 評価
本システムの回線冗長利用の効果を確認するために，遠隔運転システムを想定する環境での評価を行う．遠隔運転環境を模倣するため，本システムを搭載する自動車（試験車）を用意する．試験車は通信を行う車載通信器を備え，遠隔操作端末へ映像伝送を行う．本稿では，車体に前方および左右の合計3つのカメラを備える遠隔運転を想定し，試験車から遠隔端末へ各カメラから1ストリームずつ合計3ストリームの映像伝送を行う．遠隔運転の通信状況を模すため，試験車は市街地を走行する．走行中に映像伝送を行い，車載通信器が1つの通信手段のみを用いる場合（シングルパス構成）と複数の通信手段を冗長利用する場合（マルチパス構成）とで，通信制御を行うトランスポート層およびメディア伝送を行うWebRTC層の統計情報を比較し，提案手法の有効性を評価する．
本稿で用いた評価環境のネットワーク構成を図2に示す．評価環境は，試験車に搭載される車載通信器，マルチパス集約とTURNによるリレーを担う中継サーバ，および映像を受信する遠隔操作端末より構成される．
Fig. 2 Network diagram of evaluation environment.
車載通信器はdocomo（BIGLOBE MVNO），au，SoftBankの3G/4G回線を提供するモバイルルータをそれぞれ1つずつ，合計3つ備える．それぞれの回線を以降path0，path1，path2と呼称する．モバイルルータは富士ソフトFS030W（docomo，SoftBank）とSpeed Wi-Fi NEXT W05（au）を用いる．モバイルルータはUSBテザリングを有効にしネットワークインタフェースとして認識される．車載通信器は，マルチパス構成の評価を行う場合はpath0およびpath1とpath2の3回線をすべて用い，シングルパス構成の評価を行う場合はpath0のみを用いる．
車載通信器は，Ubuntu 20.04.3を導入したラップトップPCを利用し，MUPクライアントプログラム，およびWebRTCに用いるGoogle Chrome 93.0.4577.82を動作させる．車載通信器は，遠隔操作端末に対して仮想カメラから入力される3つの映像をWebRTCを用いて伝送する．本稿では映像素材として車載カメラで録画した映像をAVIファイルとして用意する．走行中はv4l2loopback*2を用いて3つのAVIファイルから800x600 15fpsの映像をブラウザおよびWebRTCに入力する．
遠隔操作端末は，Ubuntu 20.04.3を導入したラップトップPCを利用し，WebRTCに用いるGoogle Chrome 93.0.4577.82を動作させ映像の受信を行う．遠隔操作端末は，安定した固定回線のあるオフィス環境に設置する．
中継サーバはAWS EC2上の仮想サーバとして構築する．中継サーバではTURNサーバとしてcoturn*3 4.5.1.2を用い，MUPサーバプログラムを動作させる．
車載通信器は図3のように試験車へ搭載する．車載通信器に接続するモバイルルータは図4に示すように車内後方に設置する．
Fig. 3 Inside test car: vehicular communication device.
Fig. 4 Inside test car: mobile routers.
試験車による走行は，映像伝送を有効にした状態で1時間から2時間程度実施する．評価に用いる統計情報としてPingによる遅延，トランスポート層，およびWebRTCの情報を収集する．利用した通信回線の特性比較のため，評価中に各パスを対象としてMUPクライアントとMUPサーバ間でPing計測を行う．PingはMUPクライアントがMUPサーバに対して5秒ごとに送信する．5秒以内にサーバから応答がない場合はロスとみなす．Ping統計値およびトランスポート層の統計情報は，車載通信器上のMUPクライアントおよび中継サーバ上のMUPサーバから5秒ごとに採取する．WebRTCの統計情報は，車載通信器および遠隔操作端末のブラウザからWebRTC Statistics APIを用いて，1秒ごとに採取する．
回線の冗長利用がトランスポート層へ与える影響を，Ping計測から得られる各回線のRTT統計値およびMUPクライアントとMUPサーバの送受信スループット，送受信パケット数，シーケンス番号の欠損パケット数とアウトオブオーダー受信との差を元に評価する．RTT統計値により，各回線の遅延特性を評価する．MUPクライアントの送信スループットおよびMUPサーバの受信スループットから，複数の通信回線にトラフィックが複製され回線の冗長利用が行われていることを評価する．MUPサーバが各回線から受信しアプリケーションへ転送したパケット数により，複数の通信回線からパケットを補い合う動作がなされていることを評価する．またMUPサーバが観測したシーケンス番号の欠損パケット数，およびアウトオブオーダー受信パケット数との差により，ある通信回線で発生するパケットロスに対してアウトオブオーダー受信により別の通信回線からの補填がなされていることを評価する．
複数回線の冗長利用がWebRTC層へ与える影響を，WebRTCが映像ストリームごとに計測するRTT，ジッタ，ロスの割合（fraction lost）と，WebRTC層でのパケットロス数および受信スループットにより評価する．本研究ではシングルパス構成とマルチパス構成の統計値をそれぞれ採取し比較することで，回線の冗長利用が与える影響を評価する．WebRTCのRTTにより，回線の冗長利用がアプリケーションが行う通信の低遅延化に与える影響を評価する．WebRTCのジッタおよびfraction lostにより，回線の冗長利用がWebRTCの輻輳制御に与える影響を評価する．WebRTCのパケットロス数により，回線の冗長利用がWebRTC層のパケットロス低減に有効であるかを評価する．WebRTC受信スループットにより，回線の冗長利用がWebRTCの輻輳制御および利用帯域に与える影響を評価する．
5. 結果と考察
本章では，本システムの走行時通信評価の結果をまとめ，考察を行う．まず利用した通信回線のRTT推移を明らかにする．次にトランスポート層の評価結果を示す．最後にWebRTCの統計情報から，マルチパスUDPトランスポート層がメディア伝送に与える影響をまとめる．
5.1 利用した通信回線のRTT推移の評価
Ping計測の結果として各パスのRTTの推移を図5に示す．Ping計測の統計を表1に示す．既存研究[18], [19]にて，遠隔操作環境の一方向遅延の許容値と例示される100 msのRTTを想定して200 msを上限とする範囲の，RTTの分散を図6に示す．
Fig. 5 Driving environment: logarithm RTT for each path.
Table 1 Ping statistics on each path.
Fig. 6 Distribution of RTT for each path（under 200 ms）.
これらの結果は本評価に用いたモバイル回線のそれぞれの特性を示す．それぞれのモバイル回線は10–35%前後のロスが発生し，最大で4秒程度のRTTを示す．一方でRTTの第三四分位数は，既存研究[18], [19]にて許容値とされる100 msを往復で超えていない．
5.2 マルチパスUDPトランスポートの評価
車載通信器のMUPクライアントが各パスへ送信したトラフィックのスループットを図7に示す．このトラフィックはWebRTCの通信を受けて発生したものである．MUPクライアントは，path0とpath1およびpath2に同量のトラフィックを送信している．MUPクライアントは，複数回線を冗長したマルチパス利用を行っているといえる．
Fig. 7 MUP Client: Tx throughput for each path.
MUPクライアントが各パスへ送信したトラフィックは，異なるネットワークを経由して中継サーバに到着する．中継サーバ上のMUPサーバが受信した各パスのトラフィックのスループットを図8に示す．path0およびpath1の受信スループットは最大で6.2 Mbpsを示したが，path2は定常的に120 kbps程度を推移していた．
