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プロキシと呼称する．

マルチパス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によるリレーを担う中継サーバ，および映像を受信する遠隔操作端末より構成される．

車載通信器は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に示すように車内後方に設置する．

試験車による走行は，映像伝送を有効にした状態で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に示す．

これらの結果は本評価に用いたモバイル回線のそれぞれの特性を示す．それぞれのモバイル回線は10–35%前後のロスが発生し，最大で4秒程度のRTTを示す．一方でRTTの第三四分位数は，既存研究[18], [19]にて許容値とされる100 msを往復で超えていない．

5.2　マルチパスUDPトランスポートの評価

車載通信器のMUPクライアントが各パスへ送信したトラフィックのスループットを図7に示す．このトラフィックはWebRTCの通信を受けて発生したものである．MUPクライアントは，path0とpath1およびpath2に同量のトラフィックを送信している．MUPクライアントは，複数回線を冗長したマルチパス利用を行っているといえる．

MUPクライアントが各パスへ送信したトラフィックは，異なるネットワークを経由して中継サーバに到着する．中継サーバ上のMUPサーバが受信した各パスのトラフィックのスループットを図8に示す．path0およびpath1の受信スループットは最大で6.2 Mbpsを示したが，path2は定常的に120 kbps程度を推移していた．

図8より，MUPサーバはMUPクライアントが送信したトラフィックを3つの回線より受信していることが確認できる．本システムは複数回線を冗長したマルチパス利用を行っているといえる．

図7は各パスで同量の送信スループットを示していたが，図8は各パスで異なる受信スループットを示している．path0と比較して，path1は同程度の受信スループットを示している．一方でpath2は定常的に低い値を示している．path2はモバイルネットワーク内で帯域制限を受けていたと考えられる．このように一部の回線が充分な可用帯域を提供できない場合においても映像伝送が行えていることから，マルチパスにより可用性が向上したといえる．

評価期間中にMUPクライアントが各パスへ送信したパケット数とMUPサーバが受信したパケット数，および5秒ごとの送受信パケット数の差に基づくロス率の統計を表2に示す．評価期間全体でMUPクライアントからMUPサーバへ送信されたパケットのパケットロス率はそれぞれpath0，path1，path2で1.1%，1.5%，83.9%であった．この結果は表1に示したPing計測のロス値と異なる．path0，path1においてパケットロス率がPing計測結果より低いのは，表2に示されるパケットの送信がモバイル回線へのアップロード通信のみ行う一方で，Ping計測はダウンロード通信を伴うため差が生じていると考えられる．また表2中の5秒ごとの統計値に示されるように，評価期間中全体のパケットロス率と比較して時間ごとのパケットロス率は各回線で大きく変動している．Ping計測のパケットロス率は，ダウンロード通信でのパケットロスおよび時間ごとに異なるアップロード通信でのパケットロスにより生じていると考えられる．一方で，path2のパケットロス率は表2において83.9%であり表1の34.1%よりも大きい．これはPing計測で送信されるパケットサイズとメディア伝送に用いられるパケットサイズの違いや送信間隔の違い，当該回線が帯域制限を受けていた影響によりモバイル網側のQoS制御等によると考えられる．

MUPサーバでの集約処理にあたりアプリケーションへの通信に採用された各パスの累積パケット数を図9に示す．本評価では，path1およびpath0にて採用パケットが多く観測された．一方で1.2%のパケットは，定常的に低帯域を示していたpath2から採用された．本稿では複数回線を冗長併用しているため，パス間でパケットを補い合う動作がなされたことが確認できる．

図10は，MUPサーバで観測したシーケンス番号の欠損パケット数を示す．全体の受信パケット数に対してシーケンス番号の欠損は11327回，1.0%発生していた．モバイル通信環境では各パスのネットワークの遅延，可用帯域の特性が変動する．各パスのパケットロスおよび到着順序の入れ替わりにより，シーケンス番号の欠損が発生していたといえる．これは単一回線のみを用いた場合のパケットロスの発生回数に相当する．

図11に，シーケンス番号の欠損パケット数とアウトオブオーダー受信による補填回数の差を示す．この差は複数回線の冗長利用によって補填できなかったパケットロスの数を示す．評価中の走行期間において，121回のパケットロスが発生しており，シーケンス番号の欠損パケット数の1.0%（全体の受信パケット数に対して0.014%）であった．このことから，複数回線の冗長利用およびアウトオブオーダー受信の有効化はPing計測にて10–35%，トランスポート層にて1–84%のロス率を示していた各回線を組み合わせることで，トランスポート層でのパケットロスを0.014%に低減したといえる．

アウトオブオーダー受信はパケット到着時間および到着間隔を変動させ，受信側GCCの遅延ベース輻輳制御器に影響を与える可能性がある．そのため，WebRTC通信などパケット到着間隔や時間に制約をもつリアルタイム通信プロトコルでは，遅延時間の増加に対するトレードオフを考慮しつつ順序制御機構の導入が有効と考えられる．

5.3　WebRTCの品質評価

車載通信器が観測したWebRTCのRTT（googRTT）の分散を図12に示す．図示される各分散は伝送した3映像のメディアストリームの各RTTと対応する．Google ChromeはWebRTCレイヤでRTCP（RTP Control Protocol）を用いた端末間のRTT計測の仕組みを備えており，SSRC（Synchronization Source）で識別されるメディアストリームごとにRTT計測を行っている．計測結果のRTTは，メディアストリーム送信側のブラウザにてSSRCのRTCStatsReportのgoogRTTとして得られる．本評価では，3つのメディアストリームのRTTはそれぞれの取得時にストリーム間で同じ値を示していた．本稿で利用したGoogle Chromeの実装では，メディアストリームで共通の値が得られるものと考えられる．

WebRTCのRTTはマルチパス構成にて平均65.0 ms，最大101 ms，シングルパス構成にて平均83.5 ms，最大595 msを示した．マルチパス構成はシングルパス構成に比して低いRTTと狭い分散を示している．複数の回線によるパケットの補填がRTTの低減に貢献している．

車載通信器のWebRTCが受信したジッタの分散を図13，fraction lostの分散を図14に図示する．メディア受信側のブラウザ（WebRTC）は，メディアの送信元にRTPパケットの到着時間のジッタおよびロスの割合（fraction lost）をRTCPにより定期的に送信する．これらはGCCが送信スループットを制御する際に用いるパラメータである．ジッタは映像受信側の遅延ベース輻輳制御器，fraction lostは送信側のロスベース輻輳制御器により利用される．fraction lostが0.1以上の値となる事象は，シングルパス構成では映像1で16回，映像2で16回，映像3で21回，マルチパス構成では映像1で35回，映像2で22回，映像3で30回発生した．

ジッタはマルチパス構成でより大きな値を示すことが観測された．受信側の輻輳制御器が輻輳と判断する傾向が，シングルパス構成と比較して高いと考えられる．マルチパス構成では，図9に示されるように複数パスからパケットが流入する．通信の特性がパケット単位で変化することによりジッタ特性が大きく変化すると考えられる．

ジッタを観測するアプリケーションに対してはMUPサーバでのペーシングが有効と考えられる．あるいはジッタの増大および可用帯域の減少が発生しない範囲で他のパスからの補填を抑制する機構が有効と考えられる．

シングルパス構成のfraction lostの最大値はマルチパス構成の最大値よりも大きくなることが観測された．一方でそれぞれの映像でfraction lostが0.1以上を示した回数は，マルチパス構成がシングルパス構成よりも多く観測された．

遠隔操作端末が観測したWebRTCパケットロスの累積値の推移を図15に示す．パケットロス数はWebブラウザが提供するRTCReceivedRtpStreamStatsのpacketsLostから得られる．パケットロスの発生回数はマルチパス構成が平均で13.8%低い値を示しており，fraction lostの示す結果と矛盾する．これは，マルチパス構成で有効にしたアウトオブオーダー受信による補填が，WebRTCのfraction lostの低減に対して有効でないためと推察される．図10と図11の差から，発生したシーケンス番号の欠損はアウトオブオーダー受信により11206回補填されたことが観測される．一方で，パケット到着順序は評価中にこの回数前後していたと考えられる．WebRTCが有効なパケットとして受信しない場合があったと推察される．また，マルチパス構成のパケットロス数は評価期間中の4分11秒から7分28秒および10分6秒から19分48秒の期間でシングルパス構成よりも大きな値を示しており，最大でそれぞれ25パケットおよび46パケットの差が観測される．マルチパス構成でシングルパス構成と比較して一時的に多くのパケットロスが観測される原因として，アウトオブオーダー受信がパケット順序の入れ替わりおよびジッタを発生させWebRTCレイヤでのパケットロス低減を充分に抑制できなかったと考えられる．シーケンス番号の欠損は，図10にみられるように継続的に発生しており，図11にみられるようにアウトオブオーダー受信によりパケットの補填が行われている．MUPサーバへの順序制御導入による改善の検証が必要と考えられる．

遠隔操作端末上のブラウザが受信したWebRTCトラフィックのスループットを図16に示す．スループットは毎秒得られるRTCTransportStats.byteReceivedの差分より算出した．スループットの分散を図17に示す．

両図からWebRTCでの受信スループットは，シングルパス構成のほうがマルチパス構成に比べて全体的に高い値を示している．マルチパス構成におけるスループットの低減はWebRTCあるいはトランスポート層のUDPでの発生が考えられる．トランスポート層については，図7と図8のMUPクライアントとMUPサーバ間の送受信スループットの結果から，path2をのぞいてpath0，path1ともにMUPクライアントの送信スループットとMUPサーバの受信スループットが一致しており，トランスポート層でのスループット低減は発生していないと考えられる．そのため，WebRTCでのスループット低減が発生していると考えられる．WebRTCのGCCが送信スループットを低減させる契機としては，可用帯域の減少，遅延ジッタの増加，fraction lostが0.1以上になるという3つの原因が考えられる．可用帯域の減少については，前述のトランスポート層でのスループット低減が発生していないことから今回の事象とは関連がないと考えられる．遅延ジッタについては，図13の結果からマルチパス構成においてシングルパスよりもジッタが大きいことが分かる．またfraction lostは，図14からマルチプロキシ構成のほうが分散は小さいものの，fraction lostが0.1を超えた回数はシングルパス構成よりもマルチパス構成の通信のほうが多かった．GCCは通信遅延のジッタおよびfraction lostから送信帯域を決定することが知られており[9]，fraction lostが0.1以上の場合に帯域を抑制し，0.02以下の場合に緩和する．そのため，ジッタとfraction lostの増加によりGCCの帯域制御が発生し送信帯域が抑制されることにより，WebRTCの受信スループットがシングルパス構成よりもマルチパス構成のほうが低くなったと考えられる．

6.　まとめと今後の課題

本研究では，WebRTCのメディアストリームトラフィックにマルチパス通信技術を導入する手法を提案した．また本システムを搭載した試験車での市街地走行中に遠隔操作端末への映像伝送を通した評価を行った．単一通信手段と複数通信手段併用時の特性を比較することで提案手法の有効性を確認した．Ping計測で10–35%，トランスポート層で1–84%のパケットロス率を示していたそれぞれの通信手段を冗長併用することで，可用性が向上し，トランスポート層のパケットロス率を0.014%に低減し，WebRTCレイヤの遅延（RTT）の最大値を101 ms以内に低減することを確認した．

今後の課題を以下に述べる．第5.3節で述べたように，シングルパス利用に比べてWebRTCの送信帯域が低減する事象がみられた．これはジッタやfraction lostの増加，トランスポート層のアウトオブオーダー受信によるものと考えられる．WebRTCのパケットロス数とfraction lostの関係性，およびアウトオブオーダー受信による影響の調査が必要である．またこれらのパラメータを改善する手法として，順序制御の導入と検証が今後の課題となる．

文献[5]にて述べたように，本システムではトラフィックの回線への分配が可能であり，マルチパスの実用にあたっては異なる回線に異なる通信内容を送信し可用帯域の向上が可能である．本研究では回線冗長併用を検証したが，分配方式による可用帯域向上への寄与評価およびオーバーヘッドの検証が必要である．

謝辞　本研究はウーブン・プラネット・ホールディングス株式会社との共同研究により実施されたものである．