f:id:aptpod_tech-writer:20201211185209j:plain

研究開発グループのエンジニアの酒井 (@neko_suki)です。

aptpod Advent Calendar 2020 の14日目を担当します。

研究開発グループでは、TCP/QUIC/UDP などのトランスポートプロトコルの製品適用に向けた検証を行っています。

今回の記事は前回の「5Gのネットワークを計測してみた」の続きになります。

tech.aptpod.co.jp

今回の記事では、以下の2つを紹介します。

モバイルルーターをWi-Fi STATION SH-52A に固定して行った4G/5G のping/iperf3 の計測結果
4G/5G でのTCP/QUIC/UDP の計測結果

計測機材の紹介
計測場所の紹介
ネットワーク計測の結果
トランスポートプロトコルの評価
まとめ

計測機材の紹介

計測機材は前回と同じ機材を使用しています。

計測用のクライアントは組み込み製品を想定しRaspberry Pi4を使用しました。計測用のサーバは、AWS上でEC2のm5.xlargeのUbuntuインスタンスを使用しました。Raspberry Pi側はUbuntu 20.04、サーバ側はUbuntu 18.04 を使用しています。

また、5G/4Gの接続にはDocomoから販売されているモバイルルーター Wi-Fi STATION SH-52A を使用しています。SH-52Aは「5G/4G/3G」で接続するモードと「4G/3G」で接続するモードを選択可能です。「5G/4G/3G」モードでは5Gの接続に固定されるわけではありませんが、今回計測を行った場所では安定して5Gに接続が可能でした。

以下のような構成で計測をします。

f:id:aptpod_tech-writer:20201209175648p:plain:w200

前回の記事の再掲になりますが、計測に使った機器は以下のように接続しています。

f:id:aptpod_tech-writer:20201209175705j:plain

計測場所の紹介

前回の記事で計測を行った場所と同じ日産スタジアム東ゲート付近の広場で、12/4に計測を行いました。

f:id:aptpod_tech-writer:20201202094656j:plain

ネットワーク計測の結果

pingの計測

pingの計測では、pingコマンドを使って1秒間隔で60秒間RTT (Round Trip Time)を計測しました。

比較のために、12/4 に計測した結果と前回の記事の計測結果の両方を載せます。前回の記事では4Gの計測はモバイルWi-FiルーターL-01G というモバイルルーターを使っていました。

以下の表には、前回の結果と今回の計測結果の、平均値、10パーセンタイル値、50パーセンタイル値、90パーセンタイル値を載せています。

	4G(2020/12/4計測)	5G(2020/12/4計測)	4G(2020/12/2掲載)	5G(2020/12/2掲載)
平均値	40.3msec	43.3msec	74.5msec	38.5msec
10パーセンタイル値	31.7msec	32.9msec	65.2msec	30.4msec
50パーセンタイル値	40.5msec	44.0msec	75.6msec	39.15msec
90パーセンタイル値	47.9msec	52.12msec	83.9msec	46.09msec

前回の記事では、5Gの方が4GよりもRTTが小さいと紹介しましたが、モバイルルーターをSH-52Aに統一した結果を見ると、4Gと5GのどちらもRTTには差分がなさそうです。

L-01G を使用した場合のみ大きく違う値が出ていますが、この原因は今後調査を行い機会があればお伝えしたいと思います。

iperf3の計測

iperf3の計測では、UDPとTCP（輻輳制御はBBRを使用）のそれぞれについて、クライアントからサーバに20秒間データを送信する計測を3回行いました。

UDPの結果

UDPの計測は律速するまで帯域を上げています。4Gは25Mbps、5Gは50Mbpsを設定しています。

	4G(2020/12/4計測)	5G (2020/12/4計測)	4G(2020/12/2掲載)	5G (2020/12/2掲載
1回目	20.9 Mbps	45.2 Mbps	17.4Mbps	45.2Mbps
2回目	21.2 Mbps	18.4 Mbps	24.6Mbps	47.0Mbps
3回目	20.7 Mbps	39.4 Mbps	25.0 Mbps	47.0 Mbps

このように、おおむね5Gの方が高いスループットを得られています。 UDPの2回目の時は、未到達のパケットがかなり多かったため4G側より低い値になっていますが、ネットワークの変動によるものではないかと思います。

TCPの結果

TCPの場合はビットレートを指定しなくても流せる上限まで流そうとするのでビットレートの指定はしません。計測結果は以下のようになりました。

	4G(2020/12/4計測)	5G (2020/12/4計測)	4G(2020/12/2掲載)	5G (2020/12/2掲載
1回目	10.3 Mbps	40.3 Mbps	9.33Mbps	15.9Mbps
2回目	13.6 Mbps	43.4 Mbps	11.1Mbps	17.8Mbps
3回目	16.2 Mbpbs	34.2 Mbps	12.3 Mbps	34.4 Mbps

おおむね5Gの方が高いスループットが出ています。ただし、5Gの結果は前回の記事の結果と今回の結果で大きく差が出ています。したがって、変動の影響はありうると考えるのがよさそうです。

トランスポートプロトコルの評価

ここからは、トランスポートプロトコルの評価についてお伝えします。実験では、

TCP（輻輳制御はCUBICを使用）
QUIC（輻輳制御はCUBICを使用）
UDP

をそれぞれ4G/5Gで評価しています。

計測は4G/5Gに対してそれぞれ5回ずつ行いました。

実験内容

実験は、高頻度なデータの塊をクライアントからサーバに伝送するユースケースを設定します。

送信するデータは1unit (データの単位)を8byteとします。これを1000 unit/secで送信します。そのために1msec毎に1unitのデータをクライアント側で生成します。

弊社製品のintdashでは、IPやTCPヘッダのオーバーヘッドを低減するために、一定期間のユニットをバッファリングして送信する仕組みを導入しています。

なので、それに倣って10個の連続したデータを一つの塊として送信します。このバッファリングしたデータ単位はflush*1と呼ばれています。

以下の図のように、送信時刻までの10msec分のデータが1つのflushとしてまとめて送信されます。

f:id:aptpod_tech-writer:20201210163852p:plain — flush

クライアント-サーバ間の送信遅延を評価するために、データがクライアントで生成された時刻とサーバ側で受信した時刻の差分を遅延時間として定義します。サーバでは1flush分のデータをまとめて受信します。そのため、flushの先頭のunitは、ネットワークの上りの遅延+10msec程度の遅延が発生します。

f:id:aptpod_tech-writer:20201210164238p:plain — クライアントとサーバ間のデータのやり取り

この場合、遅延時間は以下のようになります。

	生成時刻	受信時刻
1unit	0msec	ネットワークの上りの遅延 + 10msec
2unit	1msec	ネットワークの上りの遅延 + 9msec
3unit	2sec	ネットワークの上りの遅延 + 8msec
...	...	...
10unit	9msec	ネットワークの上りの遅延+1msec