16日目担当の榮枝です。ソリューションアーキテクトという職種でSEのような仕事をしています。出張経費精算で領収書をなくして怒られたりしてます。そんな中で社内イベントでモバイル通信環境を計測する機会がありましたのでその話をします。0.前置き弊社ではテレメトリという領域を軸に様々なプロジェクトを行っています。車両の操作といった遠隔制御したり、といったプロジェクトが多く、その中で、周回コース※などの特定の環境下を車を走らせながらデータを上げたい、といった要望があがってくることがあります。※そういったコースは、通信環境が悪い街外れにあることが多いです。「その環境下で一定時間におおよそどれだけのデータをアップロードできるのか」という調査データがシステム設計のために必要になって来ます。急に調査需要が出てくることもあり、調査の際にあたふたしていました。サーキットを貸し切って自社製品を触ってみよう、という社内イベントがありちょうどよい機会だったので、このモバイル通信環境計測の作業手順を整理する意味で、準備~計測~評価までを行ってみました。「通信にどれだけのレイテンシが発生しているのか」の準備〜評価も並行して行いました。apdpodでよく使う装置のためこれを利用しています。PowerHouse車載コンピュータ用電力源。今回は6台の車載コンピュータを並行して利用するために用意しました。構成によっては車のシガーソケット供給でも良いです。計測時間x消費電力x台数を満たせる容量と出力があることは要確認。(今回のケースでは問題ないことを事前に確認してもらっています。)車載器6台に電力供給できるように、シガーソケットからの電力分岐ケーブルをHWチームに突貫で作成してもらいました。レイテンシ測定用)通信帯域幅測定用simはデータ容量に注意、計測時間にもよりますが、数十GBは欲しいところです。実際計測した際は写真を撮ってなかったので、この記事用に改めて録りました。当時の状況と若干異なります。iperfコマンドを利用して計測します。iperfでは、対応するiperfサーバが必要になります。安定的に利用するには不向きなため、自前で用意する必要があります。<ポート>の結果をパースして、GPSデータと合わせて(厳密にはGPSとは別のパケットで送るのですが、詳細は省略・・)弊社のintdashサーバに送ります。「レイテンシ測定」pingコマンドを使うこと以外は、帯域幅測定とほぼ同じです。ping受け側サーバは、iperfと違ってサービスを用意したりは不要です。intdashについてintdashとはaptpod社製の「高速・大容量かつ安定的にストリーミングするための双方向データ伝送プラットフォーム」で、高いリアルタイム性を維持しつつ、データの完全回収性(リアルタイムで送れなかったデータを後回収する)システムです。今回のような計測を行う場合、「計測完了してみたらデータが取れていなかった」といったことが起きがちなのですが、intdashを使うことで、データの計測状況をモニタリングすることができます。通信回線が弱くリアルタイムに送れなかった分の計測データも、後から自動でサーバ側に回収されるため、データの取り扱いも非常に楽に行えます。Visualizer)という可視化ツールも揃っているため、グラフ化作業や、データ比較も非常に簡単に行えます。計測時は電源を入れる以外に特にやることはありません。(可視化ツールのVM2Mで動作状況を確認するぐらい)弊社オフィスそばの駐車場から茂原サーキットへ向かう道中と、茂原サーキットで数周走行して計測しました。計測結果をどういった軸で評価するか(評価指標)は、プロジェクトによって変わるのですが、よくある/今後欲しくなりそうな指標として以下2種を考え、それぞれについて計算してみました。(なお、VM2MからはAPIやCSVとしてダウンロードするなどしてデータを取り出すことができ、今回はCSV出力したデータを元に計算しました)「帯域幅」1.平均送受信量この評価指標が求められるケース:計測機器から発生するデータをおおよそリアルタイムに上げきることができるか?を知りたい時。通信帯域の計測結果と、計測機器が発生させる秒間データ量の見積もりなどを比較を、設計の参考にします。計算方法:帯域幅の平均値(一部-1と出ているところは0として計算)注意:千葉県茂原サーキットやその周辺は、非常に電波状況が悪いため、この結果も一般的な通信帯域幅よりだいぶ低い値になっています。9.2Mbit/sec2.帯域安定度この評価指標が求められるケース:恒常的にリアルタイム通信ができるか?を求められるケース平均送受信量では、通信が悪い時にデータがエッジに溜まり、良い時に回収され、後からデータが流れてくる、といった形になりますが、リアルタイムにデータ送受信できる必要性が高い場合はこの安定度が必要になります。9.7Mbit/sec→正直平均値に対して、標準偏差が大きすぎて、、、通信状況の良い東京と、アクアラインの地下や、ほとんど通信できなかった茂原付近等をまとめて計算するとだめですね。1.4Mbit/secDown偏差:1.2Mbit/secだったので、特定の範囲無いだけを評価するのは良さそうです。「レイテンシ」レイテンシも平均と標準偏差を出してみました。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チーム、サーバチーム、エンべ(組み込みソフト)チーム各所にご協力頂いて計測実験ができました。部署横断的に、急遽お願いして協力して頂いたのですが、即座に対応してくれて大変助かりました。25日目=最終日の記事です。(1)月別アーカイブスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。