HaLert: 災害時におけるHaLowデータ＋LoRa制御の有効性

September 2025

本稿で扱うHaLertは、災害後の通信を想定したアーキテクチャであり、ユーザおよびセンサーのデータを**Wi-Fi HaLow（IEEE 802.11ah）**メッシュで運び、LoRaを用いたフラッディング型メッシュで制御信号を流す構成を採用している。制御系はSoftware-defined Networking（SDN）コントローラが管理する。¹

実証は、市販モジュールを用い、標高差や見通し外経路を含む屋内外混在のキャンパス環境で実施され、リンク品質、遅延、スループット、制御プレーンの到達率が報告されている。これらの測定値は、公衆インターネット回線を前提としない現場端末にとって参考になる。短文メッセージや行政側のワークフローは継続可能であり、機器の再設定などの制御操作はLoRa経由で維持された。^[2]

デザイン: データと制御の分離

データプレーンは、HaLowによる802.11sメッシュ^[3]とキャプティブポータルを組み合わせ、住民チャット、告知、MQTTテレメトリを運ぶ構成である。制御プレーンはLoRa上で動作し、設定変更、ヘルスチェック、装置への指示などを担当する。この分離により、データ系が負荷状態や部分断のときでも、制御系のトラフィックが競合を避け、遅延を一定水準に保ちやすくなる。^[4]

制御メッセージはコンパクトに設計されている。SDNコントローラは、送信元、宛先、メッセージ種別、アクションの4つの整数をProtocol Buffersで符号化し、ペイロードは通常 約40～50バイト に収まる（従来の80～100バイト程度に比べ削減）。小さいパケットは、ビットレートの低い回線において送信時間と衝突確率を下げる効果がある。EU868帯内での時間的な周波数ホッピング計画により、多数ノードが再送する状況でも、同一チャネル・同一タイミングでの衝突を減らす工夫がなされている。^[5]

実証に用いられた構成

実証では、HaLow側にNRC7292ベースのモジュール、LoRa側にE220クラスの無線機^[6]、端末にはRaspberry Pi 3Bを用い、DHT11を接続した「スマートセンサー」とRGB LEDを用いた「スマート信号機」を構成した。キャプティブポータルにはMikroTik製APを用いている。HaLowは863.5 MHz帯近傍の1 MHzチャネルで動作し、LoRaメッシュは短いACK付きでSDNの制御メッセージをフラッディングする構成だった。ゲートウェイは単独で動作でき、インターネットが利用可能なときは上位回線を活用する方式である。

端末は3台を配置し、建物や階をまたぐ構成とした。そのうち1経路は見通し外（NLOS）である。HaLowとLoRaのゲートウェイは窓際に併設され、実際の外壁やポール設置に近い条件が再現されている。評価手法は、RSSI／SNR取得、64バイトICMP RTT（リンクごとに20回×3セット）、TCP iPerfによるスループット測定（60秒×3回）、およびSDN APIから取得した1時間分のLoRa送信・受信・破棄・エラーのカウンタである。^[7]

結果

遅延と損失 HaLowの弱い経路（センサー→ゲートウェイ）は、RSSI −91 dBm、SNR 2 dB という条件ながら、試験中のパケット損失は0％であり、RTT平均は54.8 ms（最小 7.8 ms、最大 269 ms）であった。強い経路（信号機ノード）は、RSSI −84 dBm、SNR 15 dB、RTT平均 15.0 ms（最小 7.8 ms、最大 49.8 ms）と報告されている。この範囲の遅延と損失特性であれば、メッセージング、テレメトリ、行政側のメディア送出（適切に間引いた形）に対応可能である。

スループット 持続的なTCP通信速度は経路品質の差を反映し、非見通しのセンサー経路では上り134 Kbit/s・下り117 Kbit/s、良好な経路では上り726 Kbit/s・下り682 Kbit/sとなった。狭帯域および障害物によりピーク速度は抑えられるが、短文テキスト、位置情報、小さな画像などには十分な帯域といえる。

制御プレーン LoRaによるフラッディングメッシュのメッセージ成功率は**88.7～99％（平均94.96％）**であった。端末側ではゲートウェイに比べて約3倍の受信エラーが観測されており、距離と遮蔽物の影響が示唆される。ゲートウェイは制御フレームの起点となるが再送は行わず、再送は周辺ノードが担当する設計である。

システム挙動 HaLow側がユーザトラフィックを処理している間も、LoRa経由での機器再設定は機能し続けた。MQTT^[8]テレメトリはダッシュボードに到達し、キャプティブポータルと行政コンソールは、上位インターネットの有無に関わらず稼働した。リンク余裕がある場合には、圧縮画像、音声、短い動画も転送されている。^[9]

限界と示唆

本実証ではノード数が少なく、HaLowの「メッシュ」は実質的にスター構成に近い挙動となっている。多段中継時の性能、経路の多様性、ノードの出入りに対する自己修復性などは、より大規模な検証が必要である。スループットのばらつきは環境要因とNRC7292スタック固有の特性が混在している可能性があり、他の802.11ahチップセットでは異なる結果となる余地がある。

LoRaは設計上、制御および疎なテレメトリ伝送に用途を絞って用いられており、エアタイム制限と法令上のデューティ比により、住民向けメディア配信など大量データには適さない。^[10]

運用者への示唆

結果から、設置場所の工夫が最も大きく効いていることがわかる。人が集まりやすい広場、駐車場、校庭などに対して見通しが取りやすい位置や高所を選ぶことで、スループットと遅延の安定性が向上した。HaLowとLoRaのアンテナを物理的に離すことで、自己干渉を抑えられることも確認されている。

ポータルアプリと認証情報をあらかじめゲートウェイ側にキャッシュしておくことで、インターネットがない状態からでも起動できた。端末側では、クライアント側でのデータ圧縮やチャット履歴の上限設定により、性能の低い機器でもメモリ使用量を安定させている。

都市部でのパイロットにおける検証ポイント

都市でのパイロットを設計するうえで、次の2点を測定しておくと規模設計に役立つ。

1. アクセスポイント（AP）1台あたりのサービス容量 実際の利用に近い組合せ: テキスト＋位置情報のみ、写真の集中送信、現場からの短い音声・動画メモ: に対してどの程度耐えられるかを測り、その結果をもとに、代表的な避難場所（体育館、駐車場など）ごとに「100人あたり必要なAP密度」に換算する。

2. 複数ホップを含むHaLowメッシュ 起伏や建物配置が異なる環境、異なる802.11ahチップセットを組み合わせて、多段中継、相互接続性、障害発生時の自己修復挙動を確認する。

LoRa側では、コントローラの冗長構成やゲートウェイのフェイルオーバーを検証し、制御メッシュの一部が劣化した際の復旧時間の上限を見極めることが重要となる。

まとめ

本研究は、災害対応機器向けの「分離されたプレーン」モデルを裏付ける独立データを提供している。HaLowは、検証された経路において損失率を低く抑え、RTTを数十ミリ秒程度に維持しながら、住民・センサーのデータを運ぶレイヤとして機能した。LoRaは、フラッディング試験で約95％の成功率を示し、コンパクトで信頼性の高い制御信号の伝達経路として有効だった。

運用設計としては、ユーザトラフィックを制御チャネルに載せないこと、制御系のエアタイムを最小限に抑えること、ゲートウェイは見通しと高所を優先して設置し、遅延のばらつきを抑えることが重要になる。