HaLert — evidence for HaLow data + LoRa control in emergencies
September 2025
A recent study evaluates HaLert, a post-disaster architecture that uses a Wifi HaLow (IEEE 802.11ah) mesh for user and sensor data and a LoRa flooding mesh for out-of-band control under a Software-defined networking (SDN) controller. The deployment ran on commodity modules across a mixed indoor/outdoor campus with elevation changes and non-line-of-sight paths, then reported link quality, latency, throughput, and control-plane delivery. The measurements are relevant for field devices that must operate without public Internet backhaul: short-message traffic and authority workflows remained feasible while device reconfiguration stayed available through LoRa.
Design: separating data and control
The data plane carries citizen chat, alerts, and MQTT telemetry over a HaLow 802.11s mesh and captive portal. The control plane runs on LoRa and handles configuration pushes, health probes, and device actions. This split prevents control traffic from competing with user traffic during load or partial partitions, and it keeps control latency predictable when people are using the network.
Control messages are compact: the SDN controller encodes four integers (source, destination, message type, action) via Protocol Buffers, typically ≈40-50 bytes rather than ~80-100. Smaller packets reduce airtime and collision probability on low-bitrate links subject to duty-cycle limits. A temporal frequency-hopping plan within EU868 further reduces repeated clashes when many nodes rebroadcast.
What was deployed
The trial used NRC7292-based HaLow modules, E220-class LoRa radios, Raspberry Pi 3B endpoints (a DHT11 “smart sensor” and an RGB-LED “smart traffic light”), and MikroTik APs for the captive portal. HaLow operated with 1 MHz channels around 863.5 MHz; the LoRa mesh flooded SDN actions with short ACKs. Gateways worked stand-alone and used upstream Internet opportunistically when present.
Three endpoints were placed across buildings and floors. One link was non-line-of-sight. HaLow and LoRa gateways were co-located near a window, akin to a façade/pole installation. Methods included RSSI/SNR sampling, 64-byte ICMP RTTs (3×20 per link), TCP throughput via iPerf (3×60 s), and one-hour windows of LoRa send/receive/ignore/error counters from the SDN API.
Results
Latency and loss. The weaker HaLow path (sensor→gateway) held RSSI −91 dBm and SNR 2 dB, yet reported 0% packet loss across trials, with 54.8 ms average RTT (min 7.8 ms, max 269 ms). The stronger path (traffic-light node) measured RSSI −84 dBm, SNR 15 dB, 15.0 ms average RTT (min 7.8 ms, max 49.8 ms). These ranges accommodate messaging, telemetry, and paced authority media.
Throughput. Sustained TCP rates reflected path quality: 134 / 117 Kbit/s up/down on the non-LOS sensor path and 726 / 682 Kbit/s on the stronger path. Narrow channels and obstructions depress peak rate but links remained usable for short text, coordinates, and small images.
Control plane. The LoRa flooding mesh achieved 88.7-99% message success (94.96% mean). Edge devices saw ~3× more receive errors than the gateway, consistent with longer distances and obstructions. Gateways originated but did not retransmit control frames; rebroadcast was left to peers, as designed.
System behavior. Device reconfiguration over LoRa worked while the HaLow plane served users. MQTT telemetry reached dashboards; the captive portal and authority console operated with or without upstream Internet; compressed images, audio, and short video transferred when link budgets allowed.
Limits and what they imply
The node count was small, so the HaLow “mesh” functioned close to a star in this trial; multi-hop performance, path diversity, and healing under churn need larger tests. Throughput variance likely mixes environment with the specific NRC7292 stack; results may differ with other 802.11ah chipsets. LoRa was used as a control/telemetry path by design; airtime and regulatory duty-cycle caps rule out citizen media at scale.
Operator takeaways
Placement dominated outcomes. Line-of-sight to likely congregation points (plazas, parking lots, school grounds) and elevation improved throughput and tails. Physical separation between HaLow and LoRa antennas reduced self-interference. Pre-caching the portal app and credentials on gateways enabled cold start without Internet. On endpoints, client-side compression and bounded chat history kept memory stable on low-end hardware.
What to test in a city pilot
Two measurements enable sizing: (1) per-AP service capacity under realistic mixes—text+location only; photo bursts; short voice/video notes from responders—converted into AP density per 100 people for common venues; and (2) multi-hop HaLow meshes across varied terrain and chipsets to surface interoperability and healing behavior. Controller redundancy and gateway failover on the LoRa side would bound time-to-repair when parts of the control mesh degrade.
Bottom line
Independent data supports a split-plane model for emergency devices: HaLow for citizen/sensor data with stable loss and RTTs in the tens of milliseconds on tested paths, and LoRa for compact, reliable control actions with ~95% success in flooding tests. Keep user traffic off the control channel, minimize control airtime, and place gateways for line-of-sight and elevation to gain predictable tails.