802.11ahは、現在の920MHz帯通信規格の多くができなかった「末端までTCP/IP通信」ができる画期的な規格で、特にIoT環境への採用が広まるのではないかと考えていました。しかし802.11ahには送信時間に制限があって、これは802.11b/g/nのような「末端までLANが届く」感覚とはちょっと違って手ごわいかもしれないぞ、が前回お話したところ(https://qiita.com/Cente_mw/items/83d3af116cb4df06553c )です。
今回は、そんな送信時間制限がある状態で本当にTCP/IP通信が使い物になるのか？あたりを考えていきます。
■通信制限おさらい
日本の920MHz帯通信では「1時間あたりの送信時間の総和が360秒まで」という守るべきルールがあります。参照：
「920MHz 帯小電力無線システムの広帯域化に係る技術的条件」 情報通信審議会報告書 P.8
https://www.soumu.go.jp/main_content/000800021.pdf
通信距離が約1kmという広範囲に飛ぶものなので、それに比例して同じ周波数帯で通信する機器も増えるからです。こういう制限でもかけないと、輻輳して使い物にならなくなるからでしょう。
■通信制限の実際
当初「1時間あたりの送信時間の総和が360秒まで」と聞いたとき、「1台あたり、6分(360秒)間の送信可能時間帯と54分の送信不可時間帯がある」とイメージしたので、それって使い物になるのか？と心配したのですが、全然違うようです。ここで、送信時間を計測する時間（「1時間あたりの...」であれば1時間）のことを単位時間と呼ぶとすると、ルールの解釈としては
「1台あたり、通信スピードの1/10の帯域が使える。それを超えたデータは次の単位時間まで送信が待たされる。」であると読みました。
この解釈が正しければ、たとえば通信スピードが1Mbpsだとして、その1/10の100Kbpsまでなら通信制限はかからず、ずっと送信しつづけられることになります。単位時間を1秒とすると、100Kbit=約10Kbyteまでなら1秒間の間にパケットを送り切ることができますが、それを超えた分は次の1秒まで送信が待たされる、ということです。同様に、単位時間を1時間とすると約3.6Mbyteまでなら1時間の間にパケットを送り切ることができますが、それを超えた分は次の1時間まで送信が待たされる、と考えることができます。
本当にそうなるか、実験してみました。
前回構築した環境において、BR-100AHのduty windowを1に設定し、一方のPCから他方のPC宛に10msec間隔で100byteのデータを持つUDPパケットを100個送信した結果です。
きれいに1秒間に100パケット送り切れていることがわかります。100byteのデータを持つUDPパケットのサイズは100（データ)+8（UDP）+20（IP）+14（802.3）=142byteで、これを1秒間に100個送ったので消費帯域としては142Kbps程度です。この程度では通信制限に引っかからない、ということですね。
次に、同じ条件でデータサイズを200byteにしてみました。
一部パケットが次の単位時間に送信されていることがわかります。200byteのデータを持つUDPパケットのサイズは242byteで、100個中84個が単位時間に送信できているということは、消費帯域としては200Kbps程度です。外からはわかりませんが、この実験環境では通信スピードが2Mbpsくらいだ、と言えると思います。
実験によって私の解釈が正しそうだということがわかりましたが、この動き、実は「細い帯域（数百Kbps）の経路上で通信を行う」のと何ら変わらないことにお気づきでしょうか。それであれば古くはISDN（128Kbps）上でTCP/IP通信をやっていた我々の知識・経験が役立ちそうです。
■細い帯域でのTCP/IP通信
もともとTCP/IPは米国国防総省の研究機関で開発されたARPANETがベースになっています。Wikipedia
https://ja.wikipedia.org/wiki/ARPANET
によると拠点間は50Kbpsの専用線接続だったそうです。また、専用線と言えども当時はパケットの消失やデータ化け、場合によっては重複や到達順序の逆転なんてことが多かったはずです。そんな過酷な通信環境でも目的に応じた通信ができるよう設計されたTCP/IPなので、細い帯域向けに新たに何か仕組みを入れる必要はありません。目的にあったプロトコルを選んで、パラメータを変えたり運用を工夫すると使える状態になるはずです。
■UDPとTCP
ところで、ユーザデータを送信する目的でも2つのプロトコルがあります。UDP ... 手紙型。パケット単位で送信し、到達確認はなされない。（DHCP、DNS、TFTP、SNMP、RTPなど）
TCP ... 電話型。送信の前に接続を行い、シーケンス番号とACK番号によって一度だけ確実に順序通りデータが届くことが保障される。（HTTP、SMTP、FTP、SSH、MQTTなど）
UDPは実装がシンプルでスループットは高いですが、相手先にパケットが届いたかどうかは送信元では確認できません。UDP上のプロトコルで到達確認や再送の仕組みを持つか、多少パケットが経路上で失われても構わないアプリケーションで使われます。経路の帯域にフィットさせる仕組みもないため、アプリケーションの運用で意識する必要があります。
一方TCPは処理が複雑でスループットが稼げないというデメリットがありますが、相手先にデータを一度だけ確実に順序通り届くことを保証しています。ですからTCP上のプロトコルでは到達確認や再送の仕組みが不要で、純粋に必要な処理だけをすると良いです。なお、TCPにはデータ送信後ACKを受信するまでのラウンドトリップ時間を計測して一度に送信するデータサイズを調整する機能があります。ただ、802.11ah環境は本当に帯域が狭いわけではないのでラウンドトリップ時間は通信スピードそのもので返り、うまく機能しません。具体的には、接続後徐々に送信データ量を増やして通信スピードをフルに使おうとし、通信制限に引っかかって一旦送信停止、TCPの再送機能が動作してまた少しづつ送信するデータを増やしていく...のような動きとなります。
では、次に利用シーンからどう運用するのが良さそうか考えていきます。
■センサーデータ(数byte～数十byte）を定期的に送りたい
まずは最も802.11ahが利用されそうな、IoTデバイスからクラウドにセンサーデータを上げるシーンを考えます。上記のとおり通信スピードが1Mbpsとすると1/10の100Kbpsまでなら制限なしに通信できますので、1秒間で見ると約10Kbyte送信できます。毎秒定期的に数byte～数十byteのセンサーデータを送信することは全く問題ありません。なお、この目的によく使われるプロトコルはTCP上のMQTTです。上記のとおりTCPはデータそのものより到達確実性を担保する仕組みなどで送信byte数がかさみ、MQTTでもプロトコル上データ以外の情報が追加されますが、それらの増分を考慮しても十分余裕があると言えます。次回は、もっと大きなデータを送るケースや映像などストリーミングについて書いていきます。
■今日の閑話
昔、TCPの実装は当時のCPUにとっては「重い」ものだったので、シンプルなUDPとその上のプロトコルで必要最低限の再送機構、という使われ方が多かったんだと思います。それがCPUやネットワークの高速化、メモリの大容量化などが進み、TCP実装のハードルが下がると、やはり通信信頼性の面でTCP通信が主流になってきました。特に動画/音声のストリーミングなんてまだまだUDP/RTPでしかできないだろうと高をくくっていたので、TCP通信を使ったYoutubeやUstreamが出たとき時代の切り替わりを感じたことを覚えています。
Cente：
https://www.cente.jp/
お問合せはこちら：
https://www.cente.jp/otoiawase/