はじめに

IoTプラットフォームを提供するSORACOMに最初からあったサービスは２つ。
１つはコンソールやWebAPIで携帯回線を自由にコントロールできるSORACOM Air、
もう１つはデバイスからソラコムはSIMで認証された安全なネットワークで通信し、ソラコムで安全なプロトコルに変換して外部にアクセスするSORACOM Beamです。

両方素晴らしいのですが、僕は特にSORACOM Beamに感銘を受けました。
https://soracom.jp/services/beam/
SORACOM Beamでは以下を実現することができます。

• 軽量な平文通信を暗号通信に変換
• 通信先をクラウド側で設定可能
• SIMで認証された認証情報をクラウドで付与

これは、安全なキャリア網とインターネットを接続するポジションにいる通信会社だからこそできるサービスです。

通信サービスの提供と言った場合、通常はカバー率や安定した速度、安さなどを売りにします。土管屋などと言われてはいますが、それはそれで大事なことです。ですがSORACOM Beamでは従来無かった方法で通信に付加価値を与えることができており、しかもそれは価格、電力などの面で制約の大きいデバイスを安全に通信させるというIoTの用途にマッチしています。こんなやり方があったのかと感心したものです。

これらの機能によってデバイスは

• 暗号化や検証などの高負荷な処理をしなくてもよい
• サーバー、クライアント証明書のやりとりなどのオーバーヘッドの大きな通信をしなくてよい
• 認証情報を保存、送信しなくても良い

といった恩恵を受けます。この結果通信量を大幅に削減することができます。（他にも色々な効果がありますがそれは後日のネタにします）通信量が削減されると何が良いのでしょうか？

まず当然ですが通信料金を下げることができます。特にIoT SIM(グローバルSIM)の場合、通信量を下げる努力はされているもののローミングであるため通信量単価は高く、例えば日本では$0.20/MBです。（¥じゃ無いですよ）月に1GB通信するとしたら$200かかり、ランニングコストがとても高くなりますね。

Beamの価格は1リクエストあたり$0.000009、実際はデバイス-ソラコム間とソラコム-サーバー間の２回発生するので$0.000018です。これは90byte分の通信量にあたるので、Beamを使うことにより90byte通信量が削減できればBeamを使った方がコスト的に有利です。あとで実測しますが、このくらいの削減は余裕です。

このように、通信料単価が高いグローバルでの通信においてBeamなどによる通信量の削減はほぼ必須であり、逆にこれができるところにソラコムの強みがあります。

また通信量が下げられると、電波を送信している時間が下げられるため、消費電力を小さくすることが出来ると期待できます。消費電力は特にバッテリーや乾電池、コイン電池などで動作するデバイスの動作時間を決定する要素で、文字通り死活問題ですね。電池駆動機器のハードウェア・ファームウェア担当は1μAでも消費電力を落とせるよう日々鎬を削っています。SORACOM Beamでの通信量削減が消費電力低減につながれば面白いですね。

それでは、どの程度通信量が削減できるのかを検証していきましょう

通信量の計測方法

計測にはtcpdumpによるパケットキャプチャを用いて、パケットサイズを合計することとします。
計測環境としてはRaspberry Pi 3 Model B+を用います。手元にあるからです。ラズパイ４欲しい。
たとえばSORACOM Air メタデータサービスからの情報取得の場合、

sudo tcpdump -i ppp0 -w metadata.pcap
としてキャプチャを仕掛けた上で、
curl http://metadata.soracom.io/v1/subscriber
とすると、

pi@raspberrypi:~ $ sudo tcpdump -i ppp0 -w metadata.pcap
tcpdump: listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
^C14 packets captured
14 packets received by filter
0 packets dropped by kernel

こんな感じで取得されます。14パケット。。結構多いですね。0 packets dropped by kernel、となっているので、取りこぼしもなさそうです。

保存されたmetadata.pcapをWiresharkで確認するとこんな感じです。

あ、DNSが入っちゃってますね。しかも何回やってもDNSされる。うーむ、どうやら初期状態のRaspberry Pi(というかLinuxでは割と一般的に？)ではDNSキャッシュはしないみたいです。ある意味実動作に近いのですが、今回はDNS部分を無くして算出するため、dnsmasqをインストールしてキャッシュしておきます。こういうの地味な積み重ねが通信量削減に効くのですね。

では改めて取得します。DNSがなければ10パケットになってるはず。結果はこんな感じで、きれいに取れました。

ひとつのパケットは、

1. L2(???)
2. L3(IPヘッダ)
3. L4(TCP/UDPヘッダ)
4. L5-7(ペイロード)

で構成されています。Ｌ２を???としたのは、LinuxのtcpdumpだとL2がPPPのはずがLinux cooked captureになってしまいちゃんと取得されていない(https://wiki.wireshark.org/SLL 参照)ということと、そもそもソラコムに届いている時点でL2がどうなってるかは不明であるためです。（どなたかソラコムではL2の長さをどう計算しているかご存じですか？）今回はやや不正確にはなりますが、L2はLinux cooked caputerの16byteとします。

IPヘッダはIPv4なので20byte+オプション、TCPヘッダは20byte+オプション、UDPヘッダは8byteです。ということは例え中身の無いTCPパケットでも最低56byteは使っているということですね。このキャプチャを見る限り、最低は68byteのようです。

通信全体を見ると、

1. 3wayハンドシェイク部(76 + 76 + 68 = 220byte)
2. HTTP部(164 + 68 + 1008 + 68 = 1308byte)
3. 通信終了部(68 + 68 + 68 = 204byte)

で合計1732byteとなります。さらにHTTPの中にはリクエストヘッダ(96byte)とレスポンスヘッダ(143byte)があり、ペイロードであるメタデータは797byteです。センサーデータなどと比べると大きめのペイロードですが、それでもヘッダや通信開始、終了などのオーバーヘッドが半分以上ということがわかりますね。極端な話1byteのデータ１個アップロード、みたいな場合でも、同じだけのオーバーヘッドは発生します。

では計測方法も決まったところで、実際の計測に進みます。

通信量削減の計測

状況として以下のJSONファイル(温度を12点測定してタイムスタンプつきでアップロードする適当なJSON。200byte)をAWS S3にアップロードする状況を想定し、以下の５種類で通信量を計測、比較します。

{"temp1":17.89,"temp2":-23.64,"temp3":0.92,"temp4":39.51,"temp5":33.07,"temp6":46.43,"temp7":-15.19,"temp8":16.37,"temp9":-46.8,"temp10":-42.97,"temp11":-16.76,"temp12":47.8,"timestamp":1576276812744}

1. デバイスから直接AWS CLIでアップロードする
2. HTTPエントリポイントでアップロードする
3. TCP → HTTPSエントリポイントでアップロードする
4. UDP → HTTPSエントリポイントでアップロードする
5. UDP → HTTPSエントリポイントでバイナリパーサーを使ってアップロードする

では早速行きましょう。

1. デバイスから直接AWS CLIでアップロードする

サーバーやPCからでは普通に行われているこの操作にどれくらい通信量がかかっているでしょうか？

pi@raspberrypi:~ $ aws s3 cp traffic.json s3://traffic-amount/traffic.json
upload: ./traffic.json to s3://traffic-amount/traffic.json 

39個のパケットがキャプチャされました。中を見てみましょう。

またDNSが入ってしまった。S3バケットのレコードはキャッシュできないのかな。。とりあえずこれは手動で除外しておきます。また、再送とその影響も出ていますね。(No4、7、8)今回はこれも除外しておきます。現実にはこういうのが積み重なって、割と馬鹿にならない通信が発生しているのかも知れません。

これらを除外した合計は7301byteです。$0.20/1MB換算で$0.00139(約¥0.153)

ペイロード200byte(2.74%)でオーバーヘッドが7101byte(97.26%)。特に目を引くのがやはりNo.9〜30までのTLSハンドシェイク。これだけで5332byte(73.03%)あります。よく見るとNo17のCertificate(サーバー証明書の取得)はNo.13とNo.15と合わせて３分割されており、3304byteかかっていますね。TLSハンドシェイクのオーバーヘッドは大きいと聞いていたがこれほどとは。。これがなくなるだけで通信量を格段に落とせる予感がひしひしとしますね。だって73%ですよ？

また、No.31のApplication Data(暗号化されている)は認証かな？中身見られないのでわかりませんが。Beamの認証情報でデバイス認証を代行すれば、ここも削減できそうですね。

あとは除外してしまったけどインターネットを通らないBeamに送ることでTCP再送が起こりにくくなる効果もあるかも。これは評価が難しいところですが。

それではまずこのTLSハンドシェイクを無くしましょう。HTTPエントリポイントです。

2. HTTPエントリポイントでアップロードする

HTTPエントリポイントはBeamが受け取った平文のHTTPをHTTPSに変換して、指定したエンドポイントに中継してくれる機能です。ソラコムのネットワークを安全な大きなLANと考えると、LANの中にあるプロキシと考えてそれほど間違いでは無いと思います。

まずS3をアップロードさせるためのエンドポイントを用意しなければなりません。まあFunnel→Kinesis→S3でもいいのですが、Beamでやると書いてしまったのでBeamでやります。簡単な構成としてはBeam → API Gateway → Lambdaですかね。今回はここが本題ではないので準備部分は飛ばして、https://XXXXXXXXXX.execute-api.ap-northeast-1.amazonaws.com/v0 にPOSTしたらS3に保存されるようにしました。

BeamのHTTPエンドポイントを設定します。

設定は見たままなのですが、Beamの署名ヘッダをONにしておくのがお勧めです。これをやっておくとデバイスの認証や認証トークンの送信といった部分の通信量を削減できます。（もちろんデバイスに認証情報を持たなくて良いという大きなメリットもあります。これについては後日５回シリーズくらいでやりたい）

それでは実行してみましょう！
curl -H "Content-Type: application/json" -d '{ペイロード200byte}' http://beam.soracom.io:8888/
OKが返ってきました。パケット数は10!良い感じです。

pi@raspberrypi:~ $ sudo tcpdump -i ppp0 -w beam-http.pcap
tcpdump: listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
^C10 packets captured
10 packets received by filter
0 packets dropped by kernel

パケットキャプチャ結果は、、

合計は1518byte、$0.20/1MB換算で$0.000290(約¥0.0318)、1.からの削減率はなんと79.2%!
いきなりすごい効果出ちゃいましたね。そりゃそうだ、さっきのTLSハンドシェイク5332byteが全部無くなったんだから。

ちょっと気になるのはNo.6の"OK"しか返していないはずのHTTPレスポンスが552byteとやけに大きいこと。中を見るとAPI Gatewayからのレスポンスヘッダがいっぱい入ってるようです。こういうサーバーがデバイスでは使わない情報を付加してくるのが通信量削減の課題になります。次はここが大きなオーバーヘッドですね。

それはどうにかなるのか？といえばなるんですね。それでは次のTCP→HTTPSエントリポイントに進みましょう。

3. TCP → HTTPSエントリポイントでアップロードする

TCP → HTTPSエントリポイントはTCPで送信した内容をペイロードとして、指定したHTTPSエンドポイントに対してPOSTメソッドでアクセスしてくれる機能です。

BeamでTCP → HTTPSエントリポイントを設定しましょう。

設定項目は先ほどとほぼ同じですので省略します。「ステータスコードを省略」の項目はとりあえずOFFにしました。
それでは実行してみましょう。

pi@raspberrypi:~ $ nc beam.soracom.io 23080
{ペイロード200byte}
200 "OK"

キャプチャしたパケット数は先ほどと同じ10パケット。内容を見ると、

素晴らしく「単なるTCP通信」ですね。HTTPヘッダのような余計なものが入っていない。No.6に先ほど残したステータスコードとスペース(200 )が入っているのですが、まあこの程度は許容できるでしょう。

合計は906byte、$0.20/1MB換算で$0.000173(約¥0.0190)、1.からの削減率は87.6%
1kBを切りました。ペイロード率も22.1%とかなり向上しています。(1.では2.74%)

しかしこれ以上なにかできるんでしょうか。この中で意味のあるパケットはNo.4のデータ送信(269byte)とNo.6(77byte)の応答だけなのですが、TCPである以上は3wayハンドシェイクやACK(合計560byte)を省くことはできません。。ん？TCPである以上は？

ということで次はUDP→HTTPSエントリポイントに行ってみましょう！

4. UDP → HTTPSエントリポイントでアップロードする

UDP → HTTPSエントリポイントはUDPで送信した内容をペイロードとして、指定したHTTPSエンドポイントに対してPOSTメソッドでアクセスしてくれる機能です。TCPと違い、3wayハンドシェイクもありませんし、ACK応答もありません。またヘッダサイズがわずか8byteとTCPの最低20byte(ここまでのキャプチャ結果を見ると32byteか40byteになることが多い)に比べ格段に小さいです。これは期待できそうですよ！

それではBeamのUDP→HTTPSエントリポイントの設定をしましょう。一番下にあります。最強感が出てて良いですね。

設定項目は先ほどとほぼ同じですので省略します。今度は「ステータスコードを省略」の項目をONにしてみました。

それでは実行してみましょう。

pi@raspberrypi:~ $ nc -u beam.soracom.io 23080
{ペイロード200byte}
"OK"

キャプチャしたパケット数は、、、

pi@raspberrypi:~ $ sudo tcpdump -i ppp0 -w beam-udp.pcap
tcpdump: listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
^C2 packets captured
2 packets received by filter
0 packets dropped by kernel

２個!。鳥肌立ってきましたね。パケットの内容は、

データの送信とその応答しかない！理想的です。しかもこれ対サーバーに対してはちゃんと認証付きのTLS通信されてますからね。
合計は293byte、$0.20/1MB換算で$0.0000559(約¥0.00615)、1.からの削減率は96.0%

ただしこれは諸刃の剣ではあります。TCPまではまあ信頼性には影響を与えない構成だったのですが、UDPを使うと送達確認はアプリ側でやらなければなりません。逆にいえばそれが許容できるのであれば、UDP→HTTPSは通信量削減の強力な武器になります。

さて、そろそろここが限界ですかね。さすがにもうなんともならんやろ。パケットはもう2個しかないし、残っているのは必須のヘッダとペイロードだけだし、ペイロードに手をつけるわけには。。って思うじゃないですか。でもまだ最後の一手があるんです。それがバイナリパーサーです。

5. UDP → HTTPSエントリポイントでバイナリパーサーを使ってアップロードする

バイナリパーサー(https://dev.soracom.io/jp/docs/binary_parser/ )は

バイナリパーサーとは SORACOM Air でご利用いただけるバイナリデータをJSONデータに変換する機能です。

という機能です。要はペイロードがJSONフォーマットというサイズ大きめのフォーマットになっているのが問題で、同じ意味のバイナリであればもっと小さく出来ます。でもサーバー側でバイナリを直接扱うのはやっかいで、サーバー側としてはJSONで受け取りたいです。そこでその中間にいるソラコムが、バイナリをデバイスから受け取って、JSONに変換してサーバーに送ってくれる、という機能です。

それでは試してみましょう。バイナリパーサーはAirの設定にあります。

この「フォーマット」という欄にバイナリパーサーの指定を書いていくのですが、正直ここはちょっと難しいです。
開発者サイトの記載(https://dev.soracom.io/jp/docs/binary_parser/ )と、
実験できるページ(https://binary-parser-playground.soracom.io/ )をもとに、
試しながら作成しました。

例えば"temp1":17.89の部分は17.89は小数なのですが、固定小数としてあつかっているので2byte(16bit)の整数としてパースして1/100するようにしており、その指定がtemp1:0:int:16:/100です。そのように各温度とタイムスタンプをパースする設定を作ります。これにより、JSONテキストでは200byteだったペイロードを32byteにまで削減する事が出来ました。ただし、タイムスタンプが64bit整数なのですが、バイナリパーサーが対応しているbitが32までだったため、timestamp_highとtimestamp_lowに分割しています。

さて実測です。ncコマンドでバイナリを送る方法が分からなかったので、適当なrubyコードを作って送るようにします。

pi@raspberrypi:~ $ cat udp_send.rb 
require 'socket'
require 'timeout'
binary = [1789, -2364, 92, 3951, 3307, 4643, -1519, 1637, -468, -4297, -1676, 478].pack('n12') + [1576276812744].pack('Q')
udp = UDPSocket.open()
sockaddr = Socket.pack_sockaddr_in(23080, 'beam.soracom.io')
udp.send(binary, 0, sockaddr)

Timeout.timeout(5) do
  udp_recv = udp.recv(4096)
  p udp_recv
end
udp.close
pi@raspberrypi:~ $ ruby udp_send.rb
"\"OK\""

OK応答があり、lambdaにもバイナリ化前と同じbodyが入ってくるのを確認しました。(CloudWatchLogsのログの抜粋)

"body": "{\"temp1\":17.89,\"temp2\":-23.64,\"temp3\":0.92,\"temp4\":39.51,\"temp5\":33.07,\"temp6\":46.43,\"temp7\":-15.19,\"temp8\":16.37,\"temp9\":-4.68,\"temp10\":-42.97,\"temp11\":-16.76,\"temp12\":4.78,\"timestamp_high\":367,\"timestamp_low\":23815112}"

そしてパケットの内容

送信のペイロードは32byteになりました。なにかもはや寂しささえ感じますね。
合計は124byte、$0.20/1MB換算で$0.0000237(約¥0.00260)、1.からの削減率は98.1%
ということになりました。

ソラコムのサービスを駆使すれば、IoTの通信量は1/50程度にまで下げる事ができる、ということは言えそうですね。
とりあえず僕の理解ではここまでが限界です。他の技があったら教えてください。

通信量、通信料金削減の結果

通信量削減の結果をまとめます。コスト計算は、$0.20/1MB、$1 = ¥110、ひと月は31日、5分に１回200byteのデータをS3などのクラウドサービスに送信するというケースで計算しています。この場合、Beamの使用料金は¥17.7程度です。

IoT SIM(グローバルSIM)、特にLow Data Volumeプランを使う場合、Beamの活用を考えないともったいないですね。
色々難しいところはありますが、HTTPSをHTTPにするだけでもかなりの効果があります。まずはこのあたりから試してみましょう。

なお、これは小さいデータを多数送るような場面で特に効果を発揮します。データが大きな場合は全体に対するペイロードの比が最初から高いため、ここまで改善しない可能性が高いです。ただし、今まではオーバーヘッドがあるから仕方なくデータをまとめていたが、オーバーヘッドが小さくなることで細かく送ってリアルタイム性を上げる、という方向には使えると思います。

またMQTTSをを使用している場合は、初回はTLSハンドシェイクがかなり重いものの、以降は常時接続であること、MQTTのヘッダがかなり小さい事から、TCP → HTTPSエントリと同程度の通信量になります。すでにMQTTSで構築できているならそれはそれでいいかもしれません。これはどちらかというとMQTTSより単なるTCPの方が扱いが簡単で、実装・保守がしやすいという方がメリットですかね。（ただし常時接続の場合です。MQTTSはクライアント証明書認証も行うため、TLSハンドシェイクがさらに大きくなり、接続・切断を繰り返すような場面には向かないと思います）

以上です！

消費電力の削減効果の計測がしたい。よね？

ここで終わるつもりだったんですよ。もう１万文字越えてますし、もうやることも無いかなって。
でも気付いてしまったんです。僕はなんかとにかくすごい電力計を開発・製造・販売している計測器メーカーに在籍しているということに。こんなすごそうなものがあるなら、ラズパイやらWioLTEやらの電力測って、省電力効果を数値として出せますよね。

ということでまだやることありました。むしろこれやらないとダメだろ、と思いまして、お隣の部署に借りに行きました。

僕「趣味のブログ書くのに使いたいので、良い感じの電力計を貸してください！」

開発リーダーのTさん「どういうことですか？」

僕「今使ってるサービスの効果にこれ使えば省電力にできる、って謳っているものがあって、それを試してやろうかと。ウチの電力計ってそういう省電力の効果測定とかの用途でよく使われてるんですよね？」

Tさん「わかりやすいところでは家電の消費電力評価なんかにはよく使われてますね。というか自分のところの製品もこれで評価してるでしょ。で、それはどういうパターンの電力消費なんですか？電力計といっても色々あるので」

僕「うーん、電池での動作が想定されていて、普段はほとんど消費しない状態でスリープしてるんだけど、たまに立ち上がって携帯電波の送信のために100mAを越えるくらいの電力を一時的に消費して、終わったらまたスリープ状態に入るような感じです」

Tさん「なかなか難しいこと言いますね。。スリープ時の小さい電力の測定と動作時の大きな電力の測定を両立させられるのは、結構上のクラスの電力計が必要なんですよね」

僕「（そうなんだ。。）」

Tさん「じゃあこれしばらく使ってていいですよ。これはPW3335っていう電力計で、待機時の電力も測れることに注力してるモデルなので。多分これなら測れるはずです。」

僕「ありがとうございます！」

ということで借りてきました！しばらく使えます。

とりあえず何もつながっていない状態のラズパイ。電力は2.353W。思ったより消費電力大きいな。。

測定の方法としては、５分間の積算電力（電力消費を一定時間加算した合計を出すもの。単位はWh。1Wの電力消費が1時間続いたら1Wh）を5分で割って消費電力(W)を算出します。本当は１時間で測定していたいですが、時間かかりますので。

ラズパイの消費電力測定

先ほどのパターンの通信を5秒おきにさせた場合と、参考としてUSBモデム(AK-20)を挿していない状態、挿しただけでなにもしていない状態で計測しました。測定の様子を動画で見せられないのが残念ですが、通信してる時には電力がぐっと上がっているのが目に見えて分かります。

結果はこちら！

これは、、効果あり！ですよね？

直接CLI >> HTTPエントリ >≅ TCP → HTTPSエントリ > UDP → HTTPSエントリ ≅ UDP + バイナリパーサー > USBモデム挿しただけ > USBモデム挿していない

という感じですね。なるほどね〜。

HTTPエントリとTCP → HTTPSエントリがほぼ同じ、UDP → HTTPSエントリとUDP + バイナリパーサーがほぼ同じになることから考えて、通信量そのものよりもパケット数、つまり通信回数が主要なファクターと考えられます。バイナリパーサーはバイナリにすることでパケットを分割しなくて済む、という場合に効果を発揮する事になりますね。直接CLIはパケット数がすごく多いということと、おそらく暗号化や署名といった重い処理が高いCPU負荷になっていることも一因なのでしょう。

あとちょっと疑問を感じた動きがありまして、USBモデム挿しただけの場合は2.67W程度なのですが、1回でもパケット送信をするとその後送信して無くてもその後1分ちょっと程度の時間2.9W近くに上がったままになるんですよね。1分ちょっと過ぎればまた2.67W程度に戻る。これはUSBモデムが送信後しばらくは受信待ち状態みたいな感じになっているのでしょうか？あるいはpppdがそういう制御をしている？これが送信完了を確認したらスパッと切れるようになれば、もう少し改善できそうです。こうすれば良いんじゃ無い？という情報があればコメントにでも書いていただければ試してみたいと思います。

Wio LTEの消費電力測定

「ラズパイはもとから電力消費高くてどうせ電源供給必須なんだからあんまり消費電力は気にしてない。それよりも電池駆動の組み込みボードでどうなるか知りたいよね。」というご意見もあると思います。

僕もそう思って、金曜の昼過ぎにGrove IoT Starter kit for SORACOMをポチったのですが、
土曜の午前中にもう届きました。早すぎる。

ということで取りかかりましたがWio LTEというかArduinoの使い方が良く分からないので苦戦しています。というかこれでHTTPSできるのか？
こちらはまた結果が出たら追記します。電力計借りてる間に！

まとめ

SORACOM Beamを使うことで、クラウドにデータをアップロードするといった良くあるユースケースでも98%もの通信量ができることが測定できました。これにより通信料金も98%削減できることがわかりました。（今回のような場合はですが）

また通信回数を減らすことにより、消費電力の削減にも確実に効果があることが測定できました。これは素晴らしいですね。
SORACOMをうまく使っていいプロダクトを作りましょう！

最後に、突然の謎の依頼にも関わらず電力計を貸してくれたTさんに感謝を捧げます。
それでは！