aptpod Advent Calendar 2019 16日目担当の榮枝です。
aptpod でソリューションアーキテクトという職種でSEのような仕事をしています。
システムの全体設計をしたり、見積書を書いたり、プロジェクト管理？みたいなことをしたり、
出張経費精算で領収書をなくして怒られたりしてます。。
さて、そんな中で社内イベントでモバイル通信環境を計測する機会がありましたのでその話をします。
0.前置き
弊社ではテレメトリという領域を軸に様々なプロジェクトを行っています。
モバイル回線を通して
車両のCANデータ・各種センサーデータ・動画データ等を遠隔から高いリアルタイム性を保ちつつ監視・計測したり、
車両の操作といった遠隔制御したり、
といったプロジェクトが多く、その中で、周回コース※などの特定の環境下を車を走らせながらデータを上げたい、といった要望があがってくることがあります。
※そういったコースは、通信環境が悪い街外れにあることが多いです。
その際、
「(そのプロジェクトで入手/利用できる範囲で)最適構成の通信機器やキャリア」を見つけつつ、
「その環境下で一定時間におおよそどれだけのデータをアップロードできるのか」という調査データがシステム設計のために必要になって来ます。
ただ、たまにかつ急に調査需要が出てくることもあり、調査の際にあたふたしていました。。。
そんな折、先日千葉県茂原のサーキットを貸し切って自社製品を触ってみよう、という社内イベントがありちょうどよい機会だったので、このモバイル通信環境計測の作業手順を整理する意味で、準備~計測~評価までを行ってみました。
また、せっかくの機会だったので、
「通信にどれだけのレイテンシが発生しているのか」
の準備〜評価も並行して行いました。
1.用意するもの
プロジェクトによって比較対象とする通信機器は異なってくるのですが、今回は計測手法自体が目的のため特別な通信機器は用意せず、弊社の標準構成 + 3キャリアで計測してみました
- 車載コンピュータ(通信モジュール内蔵)
- 写真のもの、通信計測のためだけには大仰な装置ですが apdpodでよく使う装置のためこれを利用しています。
- Anker PowerHouse
- 車載コンピュータ用電力源。今回は6台の車載コンピュータを並行して利用するために用意しました。構成によっては車のシガーソケット供給でも良いです。
- 計測時間x消費電力x台数を満たせる容量と出力があることは要確認。（今回のケースでは問題ないことを事前に確認してもらっています。)
- 車載器6台に電力供給できるように、シガーソケットからの電力分岐ケーブルをHWチームに突貫で作成してもらいました。
- sim x 3社 x 各2枚(通信帯域幅測定用 & レイテンシ測定用)
- 通信帯域幅測定用simはデータ容量に注意、計測時間にもよりますが、数十GBは欲しいところです。
2.事前設定
「帯域幅測定」
iperfコマンドを利用して計測します。
iperfでは、対応するiperfサーバが必要になります。
公開サーバもありますが、どこかの誰かが同時に使っていたりする可能性もあり、
安定的に利用するには不向きなため、自前で用意する必要があります。
iperfコマンド:
iperf3 -t 5 -i 2 -c <自社で用意したiperfサーバドメイン> -p <ポート>
の結果をパースして、GPSデータと合わせて(厳密にはGPSとは別のパケットで送るのですが、詳細は省略・・)弊社のintdashサーバに送ります。
「レイテンシ測定」
pingコマンドを使うこと以外は、帯域幅測定とほぼ同じです。
ping受け側サーバは、iperfと違ってサービスを用意したりは不要です。
pingコマンド:
ping -c 1 <サーバ側IPアドレス>
2-補足 intdashについて
intdashとはaptpod社製の
「⾼速・⼤容量かつ安定的にストリーミングするための双⽅向データ伝送プラットフォーム」
で、高いリアルタイム性を維持しつつ、データの完全回収性(リアルタイムで送れなかったデータを後回収する)システムです。
今回のような計測を行う場合、「計測完了してみたらデータが取れていなかった」といったことが起きがちなのですが、intdashを使うことで、データの計測状況をモニタリングすることができます。
また、通信回線が弱くリアルタイムに送れなかった分の計測データも、後から自動でサーバ側に回収されるため、データの取り扱いも非常に楽に行えます。
更に、データを見比べる際、取得したCSVデータをエクセルでグラフ化して、、、といった作業をよくやりますが、intdashを使うとVM2M(Visual M2M Data Visualizer)という可視化ツールも揃っているため、グラフ化作業や、データ比較も非常に簡単に行えます。
intdash便利です！
(以上、intdashの宣伝でした)
3.計測
前述の車載器に電源を入れると自動的に計測開始されるように設定しているため、
計測時は電源を入れる以外に特にやることはありません。
(可視化ツールのVM2Mで動作状況を確認するぐらい)
弊社オフィスそばの駐車場から茂原サーキットへ向かう道中と、茂原サーキットで数周走行して計測しました。
4.評価
計測結果をどういった軸で評価するか(評価指標)は、プロジェクトによって変わるのですが、
よくある/今後欲しくなりそうな指標として以下2種を考え、それぞれについて計算してみました。
(なお、VM2MからはAPIやCSVとしてダウンロードするなどしてデータを取り出すことができ、今回はCSV出力したデータを元に計算しました)
「帯域幅」
1.平均送受信量
この評価指標が求められるケース：
計測機器から発生するデータをおおよそリアルタイムに上げきることができるか？を知りたい時。
通信帯域の計測結果と、計測機器が発生させる秒間データ量の見積もりなどを比較を、設計の参考にします。
計算方法：
帯域幅の平均値
(一部-1と出ているところは0として計算)
注意：千葉県茂原サーキットやその周辺は、非常に電波状況が悪いため、この結果も一般的な通信帯域幅よりだいぶ低い値になっています。
キャリアA UP平均: 2.3Mbit/sec Down平均: 2.1Mbit/sec
キャリアB UP平均: 11.8Mbit/sec Down平均: 10.7Mbit/sec
キャリアC UP平均: 10.4Mbit/sec Down平均: 9.2Mbit/sec
2.帯域安定度
この評価指標が求められるケース：
恒常的にリアルタイム通信ができるか？を求められるケース
平均送受信量では、通信が悪い時にデータがエッジに溜まり、良い時に回収され、後からデータが流れてくる、といった形になりますが、
リアルタイムにデータ送受信できる必要性が高い場合はこの安定度が必要になります。
計算方法： 標準偏差(ケースによっては最小値)
キャリアA UP偏差: 4.8Mbit/sec Down偏差: 4.4Mbit/sec
キャリアB UP偏差: 10.1Mbit/sec Down偏差: 9.3Mbit/sec
キャリアC UP偏差: 10.7Mbit/sec Down偏差: 9.7Mbit/sec
→正直平均値に対して、標準偏差が大きすぎて、、、通信状況の良い東京と、アクアラインの地下や、ほとんど通信できなかった茂原付近等をまとめて計算するとだめですね。。。。
茂原サーキットのみのデータで、安定して測定できたキャリアCだと
UP平均: 6.2Mbit/sec Down平均: 5.4Mbit/sec UP偏差: 1.4Mbit/sec Down偏差:1.2Mbit/sec
だったので、特定の範囲無いだけを評価するのは良さそうです。
「レイテンシ」
レイテンシも平均と標準偏差を出してみました。
- 計測できなかった時に丸め値として出る0値を除いて計算
- 10sec近く掛かることもあり、平均値を大きく引っ張るため、100msec以上のものを除外した平均も計算しています
キャリアA 全平均：73.1msec 除外平均：48.8msec 標準偏差：263.4msec
キャリアB 全平均：45.3msec 除外平均：41.2msec 標準偏差：101.1msec
キャリアC 全平均：57.3msec 除外平均：46.8msec 標準偏差：178.3msec
異常値を除いた平均レイテンシは各キャリアあまり変わらなそうですね。
若干キャリアBがよいかな？ぐらい。
異常値が少ない、という点でも今回の計測の範囲内ではキャリアBが良さそうです。
まとめと感想
分析はもっと時間をかけて、じっくりやれば色々見えてくるものはありそうです。
せっかくとったデータを活かしきれてない感覚が残り、データアナリティクス的な知識をもうちょっとつけておけば、、と反省です。
ただ、計測手法や、大まかな分析方法は見えたので、今後同様の事例があった時は慌てずに済みそうです！
今回、aptpodのHWチーム、サーバチーム、エンべ(組み込みソフト)チーム各所にご協力頂いて計測実験ができました。
部署横断的に、急遽お願いして協力して頂いたのですが、即座に対応してくれて大変助かりました。
中の人間の自画自賛ですが、この様に広い分野の課題に対して部署横断的にすぐ動けるのもaptpodの強いところです！！
