LoRaWANの仕様とネットワークアーキテクチャー

カテゴリーコネクティビティ

株式会社ソラコムが提供する技術者向けのオンラインセミナー SORACOM Bootcamp にて先日LoRaWANをテーマに行われました。LoRaWANの仕様や特徴をソラコムの事業開発マネージャである大槻よりご紹介します。

SORACOM Bootcamp はIoT通信プラットフォームSORACOMの、IoTシステム構築に役立つ機能やTIPSを紹介する技術者向けのオンラインセミナーです。ソラコムのFacebookページからライブストリーミングを使ってお届けするため、PC、スマホとインターネット環境があれば、どなたでもどこからでもご参加いただけます。

LoRaWAN の仕様を解説

LoRaWANは、LPWAと呼ばれる無線規格の一つです。LPWAはLow Power Wide Areaの略称で、名前のとおり、低消費電力で、かつ長距離通信が特徴です。従来IoTの通信は、3GやLTEを使った、いわゆるセルラー通信で実現していたケースが多かったですが、LoRaWANはIoTに特化して使うために作られたところが特徴となっています。技術仕様は、LoRa Allianceという標準化団体が存在し、そこの中に様々なOEMさん、キャリアさん、チップベンダーさん等が参画し、仕様の協議がされています。LoRa Allianceのページから無料でスペックをダウンロードできるようになっています。他の規格に比べても、比較的グローバルで、かつオープンな通信方式といえます。Alliance加入のメンバーは、現時点で、400社以上の会社が加入しています。LoRaのもともとの変調方式の開発をされていたSEMTECHさんをはじめ、各キャリアさん、ヨーロッパのKPNや、bouygues、オレンジ、アジアのSK Telecom、ハードウェアベンダーからは、STマイクロ、MICROCHIP、CISCOといった大手のベンダーさんも参画しています。
ソラコムは、出資をしているM2Bコミュニケーションズ社と技術提携することによって、最新のLoRaの仕様をキャッチアップしている状況です。LoRaWANの仕様体系は、LoRaWAN Specification中で規定されています。

LoRaとLoRaWANの違いとは？

LoRaという名前で呼ぶと、一般的にはLoRaの変調方式を指します。そして、LoRaWANという呼び方をするときは、プロトコル体系を、MACレイヤーを含んだ仕様全体を指します。LoRaWANとLoRaは必ずしもイコールではない可能性がありますので、その点にはご注意ください。従来の規定は、欧米系の周波数帯、ヨーロッパで言う868MHz帯、433MHz帯、あとはUS用915MHz帯が中心でしたが、昨年の秋、バージョン1.0.2というリリースから、日本も含むアジアの十数カ国についても、対象の仕様となりました。日本ではアンライセンスバンドと一般的に呼ばれている、サブギガの920MHz帯を、ARIBの規定に準じて利用し、運用することになっています。

LoRaWANの6つの特徴

こちらは実際のLoRaWANの概要になります。

上の二つ、広域通信、低消費電力は、一般的なLPWAの仕様です。三つ目以降が比較的LoRaの特徴になり、基本的に常にデバイスから通信が始まります。アップリンクがトリガーとなり、つまりデバイス側からの通信から始まる点が特徴です。IoTに特化した規格だからこその動きになります。そして、二つ目は、低データレートです。例えばSF10という設定で運用した場合のデータレートは、976bpsになります。日本の場合は、更にARIBの規定が入るため、キャリアセンスや送信休止時間等を含めると実際は約4.4秒に1回送れます。その際に送れるデータが、11バイトです。
実際のネットワーク構成は、メッシュ型です。マルチホップを想定したメッシュ型ではなく、スター型の構成になります。あくまで、デバイスとゲートウェイは、一対一でつながる環境である必要性があります。
LoRaWANの体系は、もともとレイヤー2、MACのレイヤーまでしか規定がないため、IPではなくて、デバイスIDで管理します。IPのEndがLoRaデバイスではない点も、一つの特徴になっています。

プロトコルについて

LoRa変調と呼んでる部分は、スペクトル拡散通信の一種であるチャープ拡散を活用しています。SFはSpreading Factorと呼び、拡散率を上げることで、実際のノイズに対する耐性を考慮し、高いインクバジェットゲインを得ることができます。要するに、受信の感度が上がることで、遠くにも電波が届くようになり、LPWAのロングレンジをカバーすることができます。しかし、伝送距離を稼ぐため拡散率を上げると、送信距離は長くなるが、その分スループットは落ちる相関関係があることを覚えてください。

Spreading Factor SF10という設定を、バンド幅を125kHz、Coding Rateを4/5の設定にした場合、ビットレートは、976bpsです。ただし、日本の場、920MHz帯のレギュレーション上、連続して無線出力可能な時間が最大400msecという規定があります。逆に言うと、これ以上電波を出してはいけないという動きになります。これらのレギュレーションに従い、実際にデータを送ってみると、ヘッダーを除いた部分のペイロードは、11バイトまで送れます。先ほど4.4秒に1回というお話をしたのは、ARIBの規定の中に電波を出した時間に対して、その10倍待たなければいけないというルールがあるため、例えば400msec限界まで送った場合、その10倍の4000msec、つまり4秒は待たないといけません。足し算すると、4.4秒に1回が実際の連続送信できる間隔になります。こちらは実際の拡散率を変えた場合は、変更になるため、あくまで例示というご認識をいただければと思います。

LoRaWANのクラス

レイヤー2で規定のあるクラスは、クラスA、B、Cという3種類があります。基本的にはクラスAがメイン、クラスB、Cという二つの追加のクラスがあります。

クラスが下にいくにつれて、デバイスが利用する無線間隔が広がっていきます。つまり、無線を長く使うため、その分電池を消耗します。クラスAは、デバイス自らのデータをアップリンクとして送ります。特定の時間軸を経過した後に、一定の時間だけ受信のスロットをデバイス側は開けます。逆に言うと、このタイミングで下りのデータを受けられるような枠を設けることができるようになっています。クラスAでは、そのチャンスを二つ持っていて、Rx1とRx2という二つのスロットを使うことで、下りの通信が可能になっています。下りのスロットが必要であれば、こちらのスロットを使う双方向の仕様です。逆に、下りの通信がなければ、こちらは受信しないという動きになります。また、Rx1、Rx2以外の時間軸は、デバイスは受信用の無線を使わないため、電力を抑えられます。
クラスCは、先ほどクラスAの動きと似ていますが、送受信時以外は、基本的に受信のスロットを常時開けることができるようになります。そのため、決められた時間軸でしか受けられなかったクラスAに比べて、いつでも下りのパケットを受けるチャンスがある点が異なります。デバイスは常に無線を開けている状態になるため、消費電力は増大します。クラスCは、常時給電ができるような環境、例えば自動販売機や、車などのユースケースで使えるのではと想定されています。
最後にクラスBという規格は、Beaconという特殊なパケットを下りの通信として送ることができます。冒頭でお話しした、LoRaWANがアップリンク、上りの通信から必ずしないといけないというところの唯一の例外が、このクラスBという動きになります。クラスBを使うことによって、このBeaconのパケットが定期的にデバイスには降ってくるようになり、デバイスは決められたタイミングのインターバルで下りのスロットを受けることができるようになります。セルラーで使うようなPagingのような、一方的にネットワークから投げるような動きができるようになるというのがクラスBです。ただし、現状この辺りの仕様が、LoRaWANのスペックの中でも、グレーな部分があり使用ケースは少ないといったところが実情にはなっております。

LoRaネットワークアーキテクチャー

ここからが実際のネットワークアーキテクチャーになります。実際のアーキテクチャーは、ゲートウェイの後ろに、更にネットワークサーバーというノードが存在しています。こちらは実際にデバイスのIDの管理や、データのルーティング、データの暗号化、復号化等の全てのパケットの制御をしています。ゲートウェイは、LoRaという先ほどの変調方式の変調作業、復調作業、レイヤー2で飛んできているLoRaのMACレイヤーの転送を制御します。そのため、ゲートウェイとデバイスだけあれば通信できるかというと、実際にはそうではなく、ネットワークサーバーというコアネットワークが必要になります。また、必要に応じて、アプリケーションサーバーと連携することも、可能にはなっています。LoRaWANのアーキテクチャーは、ネットワークサーバーといったノードを含めたソリューションである点を、ご認識いただければと思います。

デバイスとネットワークサーバーは、あらかじめ決められたPre-Shared-Keyのキーを持つことになっています。実際に、レイヤー2のMACレイヤーは、こちらのキーを使って、AESベースでデータを暗号化します。そして、Integry Checkとして、MACパケットを付けて、完全性の確認を行います。同様の処理をアプリケーションレイヤーでも行えるようになり、アプリケーションレイヤーも、アプリケーション用のキーを使い、セキュリティーを担保します。実際のセキュリティーの終端というのは、ゲートウェイではなく、ネットワークサーバーとデバイス間、デバイスとアプリケーションサーバー間といった動きになります。つまり、ゲートウェイはあくまで無線の中継をし、セキュリティーはネットワークサーバー側で行っているため、ゲートウェイ側で取っているデータは、ゲートウェイ側からは見ることができない状態です。そしてネットワークサーバーは不正なパケットを受信した場合は、基本的には受け捨てる動きをし、不正なデバイスからのアクセスや、不正な鍵のデバイス、偽装したようなデバイスからのアクセスを遮断することができます。
LoRaWANの仕様の中では、ネットワークセッションキーとアプリケーションセッションキーという名で呼ばれています。標準ベースでは、AESの128の事前共有鍵のような位置付けになっています。鍵のActivation方法は2種類あり、一つは、ABP、Activation by Personalizationで、Personalization、要するに、工場出荷時にあらかじめ二つの鍵を格納しておく方式です。もちろん端末には周波数とConfigurationも入れておくという状態です。もう一つのパターンは、OTAAというところで、Over the air activationというやり方になります。名前のとおり、実際にベンダーさんから工場出荷時に、仮の鍵を保管しておきます。その後、実際にLoRaのネットワークにつなぐタイミングでJOINろというProcedureを実行するようになっています。この仮の鍵をベースに認証作業をして、認証が通れば、ネットワークセッションキーとアプリケーションセッションキーという二つの鍵を本鍵として、後から発行することができます。こちらは、実際にデバイスを製造するロールの会社と、ネットワークを提供する会社というのが別のプレイヤーだった場合は、基本的にはOTAAの方式が有効です。逆にデバイスを作る人とネットワークサーバーを持っている会社が同じ場合は、ABPでもOKとなります。
LoRaWANの通信方式のクラスAのデータ方式には、Unconfirmed-DataとConfirmed-Dataという2種類が存在しています。こちらは、UDPとTCPといったようなイメージをしていただけると分かりやすいです。Unconfirmed-Dataは、デバイスは基本的にネットワークからACKを一切待ちません。そのため例えばセンサーで取ったデータを送りっぱなしても、そのデータが届いたかどうかの確認は一切しません。信頼性の担保というところはできませんが、その分、トラフィックとしては少なく済ませることができます。もう一つのConfirmed-Dataは、デバイスが送ったデータに対するACKを待つモードになります。このため、仮にネットワーク要因や、無線要因で、データが届かなかった場合に、デバイスはACKが受け取れなかったことによって、再送制御を行う実装を入れることができます。データの確からしさがほしい場合は、Confirmed-Dataを指定することで、デバイスが再送制御を入れることができます。