AWS IoT 再入門ブログリレー AWS IoT Core for LoRaWAN 編

昨年のre:Invent 2020 で発表された「AWS IoT Core for LoRaWAN」について、LoRaWAN の全体像を探ってみました。

AWS IoT再入門2021

#AWS IoT Core

#AWS IoT

#AWS

市田善久

2021.07.07

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

この記事の趣旨

本企画は、弊社の IoT 事業部メンバーが初心に返って IoT サービスについて学びなおし解説してみようというものです。本エントリーでは「LoRaWAN デバイスを AWS に接続・管理できる」サービスである「 AWS IoT Core for LoRaWAN」について紹介します。

LoRaWAN とは？

「そもそも LoRaWAN とは何？」という点ですが、簡単に言うと次のような特徴を持った無線のネットワーク規格のことです。

低消費電力

LoRaWAN は LPWA という省電力長距離通信の一種で、LPWA を英語で表すと Low-Power Wide-Area Network です。この表記の通り、LoRaWAN はデータ送信時の電力消費が Wi-Fi などに比べると非常に小さいという特徴があります。
そのため電源を確保できないような屋外でも、条件次第で電池だけで数年間稼働させることができたりします。

長距離通信

WAN という名前が示すように長距離での通信が可能で、ゲートウェイからデバイス間は最大約10km とされていますが、更に長距離の通信に成功した事例もあるようです。
実際には、障害物や天候などの条件次第で距離は変わるため、市街地であれば屋外で 2〜3km が現実的な距離になりそうです。
通信距離が長いため小数のゲートウェイでデータを送ることができるといったメリットがあります。

このように、低消費電力で長距離通信が可能という点から、IoT 向きなネットワーク規格として注目を集めています。またオープンなネットワーク規格であるため、自前で LoRaWAN ネットワークを構築することも可能です。一方で The Things Network (TTN) のような事業者が提供するサービスを利用することも可能です。

LoRaWAN の一般的な構成

一般的に LoRaWAN を利用する場合、その構成要素は下記のようになります。

diagram-generic

ネットワークサーバ

LoRaWAN デバイスから無線で LoRaWAN ゲートウェイを経由して、ネットワークサーバにデータが送られます。ネットワークサーバは、デバイスとのコネクティビティ、LoRaWANプロトコルの処理などを行います。

ジョインサーバ

ネットワークサーバーとアプリケーションサーバーの認証やセッションキーの生成など、LoRaWANへの参加フローを処理します。

アプリケーションサーバ

AES-128で暗号化されて送られくるデータ（ペイロード）の復号化（や暗号化）、後段のアプリケーションとの連携を行います。

LoRaWAN の利用（AWS IoT Coreを使わない場合）

LoRaWAN を実際に利用したい場合、対応デバイスやゲートウェイの他に、ネットワークサーバ、ジョインサーバ、アプリケーションサーバを自前で構築・運用する必要があります。なお、ゲートウェイは自前で用意したり、共有ゲートウェイとして公開されているものを利用することも可能です。

SORACOM 社でもサービス展開されている「共有ゲートウェイ」というものがありますが、過去には弊社の大阪オフィスや札幌オフィスで共有型のゲートウェイを設置していました。
（大阪では今はコロナ禍の関係による諸事情で撤去しており利用できませんが…）

ネットワークサーバもゲートウェイと同様で、自前で用意したり TTN (The Things Network) のようなコミュニティで提供されているものを利用することができます。

AWS IoT Core for LoRaWAN の構成

AWS IoT Core for LoRaWAN を利用する場合は下記の様な構成になります。

diagram-aws

先程の図と比べると分かりますが、AWS IoT Core for LoRaWAN の場合はネットワークサーバやジョインサーバ等が AWS マネージドなリソースとして提供されるので、ユーザーはサーバインフラの管理や運用を行わなくてよくなります。また、AWS 側でデバイスやゲートウェイも管理することが可能です。

また、デバイスから送られたデータは、IoT Rules を用いて後段の各種サービス等に連携することができるので、アプリケーションサーバを自前で構築・運用するよりも簡単にデータ活用できるようになるかと思います。

ザックリとデータの流れを説明すると下記のようになります。

（通常は）デバイスからバイナリデータがAES128で暗号化されて送信
暗号化されたバイナリデータは AWS IoT Core for LoRaWAN で復号化
復号化されたバイナリデータは AWS IoT Core for LoRaWAN で Base64 エンコード
Base64 でエンコードされたバイナリデータは指定の IoT Rule へペイロードとして送信
IoT Rule に紐づく Lambda でバイナリデータを Base64 デコード
デコードされたセンサーデータを他のアプリケーションに連携

実際にLambdaでバイナリデータを Base64 デコードするサンプルが、認定デバイス別に下記で公開されているので実装時の参考になるかと思います。

LoRaWAN ゲートウェイ

LoRaWAN ゲートウェイのソフトウェア要件として、LoRaBasics™Station というLoRaパケットフォワーダが必要（Ver 2.0.4 以上）になります。LoRaBasics™Station は Semtech 社によって管理されている OSS です。

このパケットフォワーダにより、デバイスからのデータをネットワークサーバに転送します。

下記のワークショップでは、補足的な既述として上記の Basic Station を使った自前のゲートウェイを作成する手順が紹介されています。ここでは、RAK2245 Pi HAT + Raspberry Pi を利用していますが、RAK2245 Pi HAT 自体に技適が通っていないため国内で利用する場合は注意が必要です。

なお、このワークショップでは、動作確認済みの認定ゲートウェイの利用を推奨しています。認定ゲートウェイは下記の AWSパートナーデバイスカタログ から参照することが可能です。
繰り返しになりますが、カタログにあるデバイスについても技適の有無は事前に確認が必要になります。

また、ゲートウェイが「AS923-1」という日本向けの周波数帯をサポートしているかどうかという点にも注意が必要になります。

国内の EC サイトなどで検索すると、いくつか LoRaWAN ゲートウェイが見つかりますが、技適が通っていないものが販売されているケースがあったり、LoRaBasics™Stationに対応しているかどうか不明なケースが多くありました。そのため、上記のデバイスカタログを元に国内の販売代理店などに確認して購入されることが望ましいと思います。

LoRaWAN デバイス

LoRaWAN デバイスの要件としては下記の2点になります。

LoRaWAN 仕様バージョン 1.0.x および 1.1 のサポート
アクティベーション方式 OTAA および ABP のサポート
- 両方、あるいはいずれか

アクティベーションとは「認証」のことです。認証方式には「OTAA」と「ABP」という２種類が存在します。
デバイスとネットワークサーバでは、予め事前共有鍵( PSK ) を持ち AES でデータを暗号化します。この鍵は「ネットワークセッションキー」と「アプリケーションセッションキー」の2つから構成されます。この2つの「セッションキー」と「デバイスアドレス」を使ってジョインサーバで LoRaWAN への参加フローが処理されますが、セッションキーとデバイスアドレスの使われ方が「OTAA」と「ABP」の各方式で異なります。

ABP ( Activation by Personalization )認証方式

ABP 方式では各セッションキーを直接デバイスに書き込む方式になります。事前発行されたキー情報をデバイスに書き込むことで、キー交換のハンドシェイクが不要で最初から暗号化したデータ送信を行います。

下記は、Arduino ベースのデバイスで ABP 方式を使う場合のサンプルです。コード中に直接それぞれのセッションキーを記載しています。

#include <lmic.h>
#include <hal/hal.h>
#include <SPI.h>
#include "DHT.h"
#include "CayenneLPP.h"
#define dht_dpin A0 // Use A0 pin as Data pin for DHT11.
#define DHTTYPE DHT11 // DHT 11

// LoRaWAN NwkSKey, network session key
static const PROGMEM u1_t NWKSKEY[16] = { set network session key };

// LoRaWAN AppSKey, application session key
static const u1_t PROGMEM APPSKEY[16] = { set application session key };

上記は、Arduino ベースのデバイスに DHT11 という温度センサーモジュールをつなげて温度データを取得する想定のプログラム（の一部）です。

OTAA ( Over the air activation )認証方式

ABP 方式と同様に、セッションキーとデバイスアドレスが必要となる点は変わりません。
異なる点としては、事前に「別の情報」をデバイスに書き込んでおいて、実際に LoRaWAN ネットワークに接続するタイミングでセッションキーとデバイスアドレスが動的に生成される点です。

「別の情報」とは、次のような情報になります。これらの情報はデバイス購入時に同梱されていたり購入元から入手することができるようになっています。

DevEUI：16桁16進数のデバイス識別子
- 製造メーカーによって割り当てられたグローバルな一意のID
AppEUI：16桁16進数の一意のアプリケーション識別子
- OTAA v.1.1では JoinEUI に名前が変更
AppKey：32桁16進数のデバイス固有値

なお、OTAA 方式の方がよりセキュアであるといった観点から OTAA 方式が推奨されていますが、AWS IoT Core for LoRaWAN ではどちらのアクティベーション方式も利用することができます。

それぞれの方式の詳細については、下記に詳しく説明されています。

対応ハードウェアを国内で入手するには

実際に LoRaWAN を使ってみたいときに個人的に最初の課題と感じたのは、AWS IoT Core for LoRaWAN 対応の国内向けデバイスとゲートウェイの調達でした。
（実際には購入に至っていないので調査までとなります）

どのメーカーのものであれば確実に利用できるのか判断しづらく、自前でゲートウェイを作るにしても、ラズパイ用のハットが技適に対応していなかったり、ハットだけで1万円を超えるといった問題がありました。

クリアすべき課題としては下記のようなものがありました。

技適の認証が通っていること
日本向けの周波数帯をサポートしていること
ゲートウェイは LoRaBasics™Station に対応していること
あまり高額ではないこと
- 検証するのにあまりに高いコストは払えないので…

色々調べている中で、Dragino 社のゲートウェイ/デバイスが、最近になって技適の認証を取り、LoRaBasics™Station モードに対応したことで、AWS でも利用できることが分かりました。

ゲートウェイ：Dragino LoRaWANゲートウェイ

このゲートウェイは AWS パートナーデバイスカタログにも掲載されています。

（Draginoダイレクトショップでは在庫が無いようですが…）

デバイス：LoRaWAN対応温度湿度センサモジュール LHT65-JP-E3

このゲートウェイとデバイスであれば、安心して国内で利用できそうなのと比較的安価に揃えることができそうです。
ちなみに、先日の IoT Deep Dive #4 で実践されたデモでは、丸文株式会社さんからデバイス一式をお借りしていたそうです。

対応リージョンについて

2021年7月7日時点では、AWS IoT Core for LoRaWAN は東京リージョンは未サポートです。技適や周波数帯の問題がクリアできているのであれば、バージニア北部リージョンなどで試すことができます。
海外リージョンで試す場合は、国内のゲートウェイから該当リージョンのエンドポイントにインターネットでデータを転送することになります。

2021年7月9日のアップデートで東京リージョンでも利用できるようになりました！