概要
LoRaWANデバイスの開発や運用において、以下のようなことを思うことがたまにあるはず。
- デバイスがJoinしない / 何がダメなのかよくわからん
- ゲートウェイまで電波が届いているのか確証がない
- LNSまで届いてるのかどうかもわからない
こういったときにAWS IoT Core for LoRaWAN の Network Analyzerが多少なりとも役に立つ。
これを用いることで、LoRaWANの通信状況（Joinプロセス、アップリンク/ダウンリンク、信号強度など）をリアルタイムに可視化できる。
本ページではその使い方についてざっくり説明する。
AWS IoT Network Analyzer とは
AWS IoT Network Analyzerは、LoRaWANデバイスやゲートウェイの通信リソースをモニタリングし、接続の問題をリアルタイムで特定するための機能である。
主な特徴:
- リアルタイムトレース: 直近の通信イベント（Join Request, Uplink data等）をコンソール上で即座に確認可能。
- ログの集約: 複数のデバイスやゲートウェイをまとめて監視設定できる。
- 詳細なメタデータ: RSSI（受信信号強度）、SNR（信号対雑音比）、周波数などの無線情報を容易に確認できる。
手順1: Network Analyzer の設定を作成する
まずは監視用の設定（Configuration）を作成する。
- AWSマネジメントコンソールで AWS IoT Core を開く。
- 左メニューから [ワイヤレス接続] (Wireless connectivity) > [ネットワークアナライザー] (Network Analyzer) を選択する。
- [設定を作成] (Create configuration) をクリックする。
設定の詳細入力
-
名前: 任意の名前（例:
MyLoRaWAN-Debug）を入力。 -
リソース:
重要- ワイヤレスゲートウェイ: 通信経路となるゲートウェイを選択
- ワイヤレスデバイス: デバッグ対象のLoRaWANデバイスを選択
注意！！
後述もするのだが、Network Analyzerはパケットキャプチャする機能ではない。ここで指定したゲートウェイやデバイスのメッセージしか表示されない。つまり、ゲートウェイを指定するが対象のデバイスを指定しない...場合だと、一切なにもメッセージが可視化されない、という事態に陥ってしまうので注意。
手順2: リアルタイムモニタリングを開始する
設定が完了したら、あとはいつでも任意のタイミングで分析が可能になる。
- 作成した設定（
MyLoRaWAN-Debug）をクリックして詳細画面を開く。 - [ワイヤレスデバイスのトレースメッセージ] タブにある トレースメッセージングを有効か をクリックし、トレースを開始する。
この状態でLoRaWANデバイスを再起動したり、データを送信したりすると、画面にリアルタイムでログが流れてくる。
例: Join過程
以下はJoinさせたときのログだが問題なく成功していれば、このようにRequest -> Acceptの流れがよくわかる。
具体的に流れたデータもわかるのですごく便利。
どんなメッセージなのか？ どのGWを通ったのか？ そのGWから見てどんなRSSIやSNRだったのか？ どんなペイロードが含まれていたのか？ などがばっちりわかる。ここまでわかればだいぶ役に立つ。
実践：よくあるかもしれないケース
ケース1: データは届くがパケットロスしてる
たまに届くなど「散発的にデータが欠落する」という場合、電波環境に問題があるケースが大半だと思う。
その場合はトレースログの RSSI と SNR の列に注目するとよいかもしれない。
| 指標 | 目安 | 判定 |
|---|---|---|
| RSSI (受信信号強度) | -100dBm 〜 -30dBm | 良好 〜 普通 |
| -120dBm 以下 | 危険（到達限界に近い） | |
| SNR (信号対雑音比) | 0dB 以上 | 良好 |
| -10dB 以下 | ノイズ過多 / 信号微弱 |
対策としては、ぶっちゃけどうしようもない部分が大きく、ゲートウェイやノードの位置変更ぐらいしかない。
あるいは、流すペイロードを小さく分割して送信する…というのもアリ。理論上もそうだし、経験則でもそうだが、小さいペイロードのほうが通りやすい。ADRまかせではなく、手動でSF12に設定してやりとりする…というやり方も考えられる。
ケース2: ペイロードの中身が不正
あまりないケースかもしれないが、アプリケーション側から見て意図したデータ担ってない、と言ったケースも考えられる。このときは Network Analyzerで見てそもそもどんなペイロードが届いているか？を確認することで切り分けになる。そもそもここでbase64デコードしたときに正しいデータになっているのなら問題ないし、正しくないならそもそもノード側からおかしなペイロードで投げている…というのが考えられる。
-
UnconfirmedDataUpなどのイベントをクリックする。 - PayloadData を確認する。これは Base64 文字列であるのでデコードしてみて、意図したものかどうか確認する。
ここで意図したデータになっていれば、その後の Lambda や IoT Rule の処理（バイナリデコードなど）に問題があると切り分けられる。
ケース3: デバイスがJoin（参加）できない
LoRaWANにおいて最も頻発するトラブルの一つが そもそもジョインできない！というケースだと思う。
が・・・非常に残念なことにこのケースでは Network Analyzer はあまり役に立たない。
というのも、この機能はパケットキャプチャのような機能とは少し異なり、あくまでリソースとして指定された紐づくゲートウェイやLoRaWANノードの通信を可視化するものである。
つまり、そもそもジョインが失敗 -> そもそも正当なデバイスではない、というものに対しては何も表示されない。
本来はLNSたるAWS IoT Coreまで届いてはいるのだが、不正なパケットとして暗黙的に破棄され何も表示されない。
こういうケースでの調査に役立てたいユースケースはめちゃくちゃあるのと思うのだが、残念ながらうまくいかない。
AWS IoTの観点ではほぼどうしようもなくて、ゲートウェイ側のログを見て参考にするのが一番有用だと思う。私はいつもそうしている。
ちなみに逆にいえば、AWS IoT観点で見て全く何も見えないのなら、それは
- そのDevEUIなどで登録されてない / LNSかノードのどちらかで値を間違っている
- あるいはGWでフィルタリングされている可能性もある / そこの指定を間違っている
- AppKeyなどが間違っている
どちらかであろうといえる。
備考
- ログレベルを変えたり、リソース指定でフィルタリングすることが可能
- 莫大なトラフィックが流れうるケースの場合は意図的に絞ってあげたほうが明らかに見やすくなるはず
- CSVやJSONのエクスポートが可能なので必要に応じてどうぞ
まとめ
LoRaWAN通信はどこで何が起きているか、どんな問題が起きているか？が結構わかりにくい。慣れるとアタリがつけられるのだが、検証初期などだと全然わからん！となりがち。
そんなとき、Netowork Analyzerは非常に有用なツールになりえる。少なくともLNSに入り込む時点でどう流れているのか？を可視化できるのは非常に強い。
是非うまく使って切り分けに使って欲しい。私も未だにお世話になっている。