LoRa経由FOTAが困難な理由とSymphony Linkによる解決

LoRaWANを使用したバッテリー駆動ノードへのファームウェア・オーバー・ジ・エア（FOTA）は、ほぼ不可能です。

LoRa Allianceは、クラスBおよびCデバイスでのみ利用可能なマルチキャストフレームでファームウェアを運べると指摘しますが、これはほとんどの展開で使用されるクラスAデバイスの実用的制約を解決しません。The Things Network、Libeliumなどのコミュニティフォーラムでも、標準LoRaWAN FOTAは非現実的と確認されています。Symphony Linkは、FOTAを念頭に構築された独自LoRaプロトコルで、実証済みのソリューションを提供します。

• ファームウェア・オーバー・ジ・エアの主要ビジネスメリット

なぜLoRaWANでのFOTAが困難なのか

1. 非協調的なゲートウェイ送信 — ゲートウェイがネットワークをリッスンせずにファームウェアセグメントをブロードキャスト。ノードはゲートウェイ送信中であることを検知できず、その期間に送信したパケットを喪失。
2. クラスA向けマルチキャスト機能なし — マルチキャストはクラスB/C向けに街路灯制御など機能サポート目的で追加されたもの。バッテリー駆動クラスAノードはマルチキャストを受信できず、FOTAが不可能。
3. デューティサイクル制限 — ETSI管轄地域ではゲートウェイ送信は時間の1%に制限。その大半がACKとMACトラフィックで消費され、マルチキャストダウンリンクに事実上余裕なし。米国ではデューティサイクル制限がないため、大量ダウンリンク時にネットワークが崩壊。

Symphony Linkによるファームウェア・オーバー・ジ・エア

Symphony Linkは、アクセスポイントから単一ノードまたはノードグループへ最大256 KBのファイルを配信可能。インフラストラクチャビーコン（IB）期間を一時的に延長することで、アクセスポイントがファームウェア転送用の追加ダウンリンク容量を得ながら、ネットワークはアップリンクトラフィックで機能し続けます。更新完了後、アクセスポイントは通常のIBスケジュールに戻ります。

OTAファイル転送初期化

初期化時に、アクセスポイントが関連エンドノードへ新ファームウェアファイルを通知。その後一時停止し、応答を待機。事前定義基準——最小ノード数または割合が準備完了、またはタイムアウト——が満たされると、アクセスポイントがファイルをセグメント単位で送信開始。

OTAファイル転送プロセス

スループット最大化のため、アクセスポイントは1フレームで複数ファイルセグメントを送信。通常のダウンリンク——ノードあたり1メッセージまたは1ブロードキャストのみ——と異なり、複数セグメントを集約。ノードが受信し、セグメントを結合。各フルバースト後、ノードが欠落セグメントを報告。

アクセスポイントはノード報告に基づき再送リストを作成し、欠落セグメントを送信。このストップ・アンド・ウェイト確認・再送（ARQ）サイクルが、全ノードが正常受信を確認するか、失敗閾値に達するまで継続。

OTAファイル転送終了

ノードが正常受信を報告すると、アクセスポイントからApply Fileコマンドを受信するまで覚醒状態を維持。このコマンドが更新を確定し、ファームウェアアクティベーションをトリガー。

結論

Symphony LinkのOTAメソッドは、アプリケーションコード、スクリプト、設定データ、暗号鍵、データベース、モジュールファームウェアを転送可能。標準LoRaWANでは以前不可能だった、産業およびエンタープライズユースケースを解放します。