IoT 向け無線ネットワーク技術とAWS アーキテクチャの接続方法を学ぶ

無線ネットワーク技術はユースケースに合わせて選択するのが現状です。この分類には  2 つの軸があります。1 つ目の軸は「通信速度と消費電力」です。2 つ目は「通信距離」です。

IoT センサーが扱うデータは数キロバイト程度で、高速大容量は不要なことが多いのです。それよりも IoT では省電力性が重視されます。電力消費が小さければ、バッテリーを小さくして製品を小型化したり、動作時間を長くできたりと、価値の高い製品が作れます。小型スマートウォッチ等に BLE が採用される理由の 1 つです。

長距離でも省電力が可能なカテゴリーがあります。それが「LPWA - 省電力長距離無線通信」(図 1 の右下) です。Low Power Wide Area-network (LPWAN とも略される) の頭文字が由来です。具体的な技術名としては、LTE を省電力化した LTE-M (LTE Cat.M1) や NB-IoT (LTE Cat. NB1)、他には LoRaWAN や Sigfox があります。

LPWA は、すでに商用利用されています。株式会社 MIXI の見守りサービス「みてねみまもりGPS」では LTE-M によって、充電頻度を 1 ヵ月〜 2 ヵ月というレベル で実現しています。Sigfox は、ニチガスの愛称でも知られる日本瓦斯株式会社のスマート検針器「スペース蛍」における 10 年間の自律稼働 を支えています。

様々な技術を紹介しました。選定はユースケースと特性から見極めるのが王道ではありますが、基準の 1 つには「使ってみたことがある」というのも無視できない要素です。そこでここからは、それぞれの通信技術を利用するために必要なものや、AWS クラウドとつなげる方法について解説していきます。

Wi-Fi、セルラー、LoRaWAN、Sigfox の 4 つを取り上げます。これらは商用でも利用され、開発環境が入手しやすいためです。

まず Wi-Fi とセルラーです。Wi-Fi はアクセスポイントとインターネット回線を準備することで、クラウドとの通信が確保できます。セルラーはアクセスポイント等は不要ですが、代わりに回線契約が必要です。この契約を一意に識別する、いわば認証情報が「SIM」(Subscriber Identity Module) に入っています。

AWS クラウドの利用という視点では、両者は同じです。MCU (マイコン) 上に AWS SDK や認証情報をインストールして、それらを利用してプログラミングします。この構成の代表格は、小型のコンピューター「Raspberry Pi」があります。AWS SDK が AWS IoT Greengrass Core に代わる場合もありますが、基本的な考え方は同じです。

MCU へ AWS SDK や認証情報をインストールする手法はオーソドックスではあるものの、デバイスの数が増えるにつれ、これらの作業が増える傾向があります。

そこで AWS IoT ExpressLink です。AWS IoT ExpressLink に準拠した通信モジュールには、AWS IoT Core へ接続するための MQTTS ライブラリ (SDK 相当) や X.509 証明書 (認証情報) がインストールされた状態で出荷されています。インストールの手間を軽減しつつ、AWS クラウドの利用ができます。

AWS IoT ExpressLink については、JAWS-UG IoT 専門支部で実施した 勉強会での資料 もご覧ください。

ここでは LPWA の通信である LoRaWAN と Sigfox を取り上げます。LoRaWAN は長距離無線ではあるものの、構成は Wi-Fi と似て、アクセスポイント (ゲートウェイ) が必要です。Sigfox はセルラーに似ている構成です。ただし、それぞれ「IP 化バックエンド」というサーバーが存在します。

AWS クラウドへの接続という点では、Wi-Fi やセルラーとは異なります。これらの通信は 1 回あたり 11〜12 バイト (注: MB や KB ではなく “バイト”) と、超低速であるため、SDK を用いた AWS クラウドとのやり取りは、かなり困難になります。

そこで登場するのが「IP 化バックエンド」です。LoRaWAN では「ネットワークサーバー」、Sigfox では「Sigfox Backend」と呼ばれます。これはバイナリで送られてきたデータを JSON 等に変換して、所定のシステムへ転送する機能があります。そのため、Wi-Fi やセルラーの時には MCU へインストールしていた SDK や認証情報は、IP 化バックエンドにインストールして利用します。

LoRaWAN のネットワークサーバーは、構築や運用の手間が発生する「サーバー」そのものです。

AWS IoT Core for LoRaWAN は、 AWS IoT Core に、 LoRaWAN のネットワークサーバー機能を持たせたものです。いわば、マネージド LoRaWAN ネットワークサーバーになります。

運用の手間を削減できる上、IoT Core と統合されていることから、次に紹介するアーキテクチャ作りも容易になります。

ここまでで、IoT デバイスから AWS クラウドまでの通信を紹介してきました。では、AWS クラウド側ではどのように受けたら良いのでしょうか ? 最後は、プロトコルから紐解く AWS サービスの違いとアーキテクチャをご紹介します。

特に IoT には、AWS IoT Core を使用した並列型アーキテクチャ (Fanout パターン) をおすすめします。

Fanout パターンとは、一つの入力を複数の出力へ展開する構成の事で、図にすると扇のようになります。こちらのブログ では、Amazon Simple Notification Service (SNS) を利用した Fanout パターンが紹介されていますが、AWS IoT Core は「ルールアクション」を利用することで、同様の構成をコードを書かずに構築できます。

例えば最初は Amazon Simple Storage Service(S3) へ保存する「ルール A」でスタートしたところ、高速な取り出し要求が発生したため、Amazon DynamoDB へ保存する「ルール B」を追加できます。ポイントなのは、ルール Aへの影響をゼロにしつつルール Bを始められる事です。今後も例えば AI/ML の活用としてルール C を作ったり、また効果が見込めなかったので当該ルールを停止するといったことも容易です。

このような背景から、AWS IoT Core を IoT データの受け口サービスとして活用いただければと思います。このあたりの具体的な挙動や IoT Core の操作は、AWS Dev Day 2022 Japan の私のセッション「AWSとラズパイで「作らずに創る」IoT のハジメ」(19 分ごろ)で紹介しているので、併せてご覧ください。

事例で紹介した株式会社 MIXI のようにクラウド寄りの企業が、自社サービス拡大のためにハードウェアへチャレンジする例が増えており、IoT は Web と同様に不可避な技術になると私は考えています。

昨今では、小型マイコン「Arduino UNO」の最新版 “R4” に Wi-Fi 搭載モデル が出たり、また、USB 型のセルラーモデム や Sigfox モジュール も入手しやすい状況です。LoRaWAN もハードウェアカタログ があり、利用のハードルが下がっていると言えるでしょう。ネットワークは重要ではありますが、実は容易に体験できるものである事を感じていただければ、嬉しく思います。

今回の記事が、皆さんの IoT の学びや興味の一歩になれば幸いです。