802.11ah(WiFi HaLow)で本当にTCP/IP通信できるの？ その2

前回は802.11ahが、IoTの王道とも言える「センサーデータ(数byte～数十byte）を定期的に送りたい」という環境なら問題なく使えそうだ、というお話をしました。今回はその他の使い方を2つほど考えてみます。

■任意のタイミングで大きなファイル（数Mbyte～数十Mbyte）を一気に送りたい

FTPでもHTTPでも良いので、とにかく送りたいときに大きなファイルを一気に送り切りたい、というパターンです。残念ながらこれは802.11ahと相性があまり良くないと考えています。前回も書いた通り、もともとTCPに備わっている送信速度調整機能はデータ送信後ACKを受信するまでのラウンドトリップ時間を計測することで実現しています。802.11ahでは通信スピード自体はたとえば1Mbpsで、送信制限によって見た目の帯域を1/10にしているだけです。この場合TCPはACKが返ってきた時間から「1Mbpsでやりとりできる帯域だ」と認識して1Mbps相当まではACKを待たず一度にデータを送るようになります。どこかの時点で1Mbpsの1/10分を送り切って送信制限に引っかかり、次の単位時間まで待たされることになります。
例えば通信スピードが1Mbpsだとして、単位時間の取り方で何が起きるか考えてみましょう。

●単位時間＝60分
「1時間あたりの送信時間の総和が360秒まで」を目いっぱい使うパターンです。1Mbpsの帯域を60分の1/10である360秒使うと送信可能データサイズは36Mbyteです。802.3、IP、TCPのオーバーヘッド分を考慮したとしても34Mbyteくらいのファイルなら送り切れそうです。しかし、1byteでも超えてしまうと、次の1時間まで一切送信できません。当然その間にTCP接続もタイムアウトしてしまい、ファイル転送は失敗するでしょう。運よく1つのファイルを送れたとしても、次のファイルをすぐに送っても大丈夫か1時間待つ必要があるのかは、使う方では不明です。これで運用するのは相当難しいと思います。

●単位時間＝1分
1Mbpsの帯域を60秒の1/10である6秒使うと、送信可能データサイズは600Kbyteです。これも結局その制限を超えると、次の1分まで送信できません。前のパターンと違うのは、単位時間が1分なのでTCP接続が再送で持ちこたえる可能性がある、という点です。TCPの再送時間は輻輳防止のために最初は1秒前後でも次は2秒、4秒...のように間隔が再送回数とともに長くなります。1分なら4回程度の再送が発生するでしょう。送信制限に引っかかったパケットとそれに続く再送パケットが、次の1分で一気に流れ、通信が復活した後また送信制限に引っかかって1分途絶える、ということを繰り返すことになると思います。このままで使う場合(A)と、以前の記事にtenmyoさんからコメントいただいたとおりTCPレイヤまたはユーザレイヤで「わざとゆっくり送る」という工夫を入れた場合(B)とどちらがトータル転送時間が短くなるか想像できますでしょうか。おそらく数回の再送パケット送信で帯域を消費する分だけ、(A)の方が若干送信時間がかかるものと考えています。
また、「持ちこたえる可能性がある」と書いた通り、環境によってはTCP接続をキープするタイムアウトが1分未満かもしれません。全く意識せずに使えるかというと微妙です。

●単位時間＝1秒
1Mbpsの帯域を1秒の1/10である0.1秒使うと、送信可能なデータサイズは10Kbyteです。1460byteのデータを持つTCPパケットなら6個程度しか送れません。しかし、TCPの再送間隔を考えると、次の単位時間までに再送が発生しても1回、タイミングによっては再送が発生する前に次の1秒で送信が復活します。ここまで来ると案外帯域自体が細い状態に近くなり、TCPでもユーザでも特に意識する必要はない（相応の転送速度に近い時間で運用できる）ように思います。

結局、送信ファイルサイズと送信間隔をユーザレベルで相当意識できるなら単位時間を長くとる方が一回あたりのファイル送信時間は短くできそうですが、そんな運用は現実的ではないように思います。通信スピードの1/10程度の速度となっても安定動作させるため、単位時間をできるだけ短くして運用した方が良いだろう、が私の意見です。

■動画を送りたい

802.11ah環境で動画のストリーミングができると監視カメラ的な使い方ができて便利そうですが、果たして現実的なのでしょうか。 画像サイズ、フレームレートを変えて試したかったので、いろいろ制限がありそうな市販のネットカメラは使わず自前で作ってしまいました！

　　
　　
上図の組込機器に相当する部分は手元にあったルネサスSHのCPU基板を使いました。
CPU基板上で動作するファームウエアとしては、USBカメラと通信を行うためのUSBドライバ、RTPストリーミングを行うミドルウエア、TCP/IPプロトコルスタックミドルウエア、Ethernetドライバなど一式が全部入っていて、画像サイズ、フレームレートを自由に設定できます。ITRON OS以外は全て自前で用意しているミドルウエアなので、ファームウエア作成作業も数十分オーダです！
PCにはVLC Medeia Player（https://www.videolan.org/vlc/index.ja.html） を入れて、ストリーミングを受けて表示させます。

★Centeでは...
本実験で、TCP/IPプロトコルスタックは以下の製品を使っています。
Cente TCP/IPv4（https://www.cente.jp/product/cente-middle/tcpip/tcp-ipv4/tcpipv4/）
Ethernetドライバもいくつか含まれていますので対応している基板を使えばその日のうちにTCP/IP通信が可能になります。
なお、音声や動画をストリーミングを行うRTPミドルウエアについては、要求仕様に強く依存するため汎用ミドルウエア製品としてはご用意しておりません。ご要望に応じた仕様とすることは可能ですので、お問合せいただければと思います。

前回の記事で書いた通り、弊社実験環境では通信スピードは2Mbps相当のようなので、単位時間を1秒にすると毎秒20Kbyteを送信できるはずです。RTPには送信速度調整する機能はありませんので、使う側が画像サイズとフレームレートを調整するしかありません。実際調整してみると、例えば160x120pixelという小さいJPEGなら20Kbyte未満になり、1FPSで安定してVLCで画像を見ることができました。もちろんJPEGは画像内容によって圧縮率が変わるものなので、この環境でも画像内容によっては20Kbyteを超えてしまい、受信側では画像データの一部が次の単位時間まで送信が待たされます。それがどんどん蓄積していくとどこかの時点でフレーム落ちが発生するでしょう。それも考慮して使う側がパラメータ調整する必要がある、ということかと思います。

なお、RTPで画像データを送信する場合、複数のUDPパケットに分割して送信します（20Kbyteなら15個くらいのUDPパケットに分割）。受け取った方では20Kbyteの画像データに再構築した後表示をさせるため、1パケットでも欠けると画像が表示されないことになります。そのため、通信品質がよくなかったり上記のようにオーバーフローしてときどきパケットが欠けてしまうと、どんどんRTPパケットが届くのに一切画像が表示されない、ということになるので注意が必要です。

■最後に

いかがでしたでしょうか。802.11ahについての投稿は今回で一旦終わりますが「802.11ah上でこのプロトコルにどんな影響があるんだろう？」のような疑問がありましたら、本記事にコメントいただければわかる範囲でお答えしたいと思います。

■今日の閑話

RTPと言えば、2000年前後だったと思いますが組込機器からQuickTime Playerに動画のRTPストリーミングをやりたいと考えて試作したときのことを思い出します。当時私は本社とは別の建物で開発していて、手元のLAN上でようやく動画が表示されたので本社にいる先輩に内線で報告しました。
「え？じゃあこっちのQuickTimeでそっちの映像が見れるってこと？」
「はい、URLにrtsp://(IPアドレス)って打ち込んでみてください。」
「どれどれ...あっ見え（プツッ）.......」
「あれ？見えました？もしもーし？」
実は当時内線もVoIPで、建物間のIP通信回線が細かったので突然の大容量RTPストリーミングの負荷に耐えられなかったようでした。今、社内LANでこんなことをやったら情シスにこっぴどく叱られるでしょうね。

Cente：
https://www.cente.jp/

お問合せはこちら：
https://www.cente.jp/otoiawase/