802.11ah HaLow: Sub-GHz WiFi for IoT

Sub-GHz WiFi

Every WiFi standard you have used operates at 2.4GHz or above. 802.11ah - marketed as WiFi HaLow (pronounced "halo") - breaks that pattern by operating below 1GHz. Specifically, it uses the 900MHz ISM band in most regions, with exact frequencies varying by country.

Lower frequency means longer wavelength. Longer wavelength means better penetration through walls, trees, and terrain. It also means longer range for a given transmit power. Where standard 2.4GHz WiFi reaches 50 meters indoors and perhaps 100 meters outdoors with a clear line of sight, HaLow can reach 1 kilometer or more outdoors and penetrate multiple building walls.

The trade-off is bandwidth. The 900MHz band is narrow - most regions allocate 26MHz or less to the ISM band at these frequencies. Compare that to the 80MHz or more available at 5GHz or the 1200MHz at 6GHz. HaLow's narrow channels (1MHz, 2MHz, 4MHz, 8MHz, or 16MHz) limit maximum throughput to 86.7 Mbps under ideal conditions with the widest channel and highest MCS. Realistic throughput for typical IoT deployments runs from 150 kbps to a few Mbps.

The 900MHz ISM Band

The sub-GHz ISM band allocation varies significantly by region:

United States: 902-928 MHz (26MHz of spectrum). This is the most generous allocation and allows up to 16MHz channels.

Europe: 863-868 MHz (5MHz of spectrum). Much narrower, limiting maximum channel width to 2MHz or 4MHz. European HaLow deployments have lower throughput ceilings.

Japan: 916.5-927.5 MHz (11MHz of spectrum). Intermediate allocation with regulatory restrictions on duty cycle and transmit power.

Australia, South Korea: Various allocations in the 915-928 MHz range with region-specific power and duty cycle limits.

The regulatory fragmentation means HaLow devices are not universally compatible across regions. A US-market HaLow AP will not work in Europe because the frequency bands do not overlap. This is one reason adoption has been slower than other WiFi standards - manufacturers must design region-specific hardware.

graph TD
    subgraph "WiFi Frequency Spectrum"
        HALOW["802.11ah HaLow
900MHz band
Up to 1km range"] --> GAP1["..."]
        GAP1 --> WIFI24["802.11b/g/n/ax
2.4GHz band
~50m indoor range"]
        WIFI24 --> WIFI5["802.11a/ac/ax
5GHz band
~30m indoor range"]
        WIFI5 --> WIFI6E["802.11ax/be
6GHz band
~20m indoor range"]
    end
    subgraph "Range vs Throughput Trade-off"
        LOW_F["Lower Frequency"] --> LONG_R["Longer Range"]
        LOW_F --> LOW_BW["Lower Bandwidth"]
        HIGH_F["Higher Frequency"] --> SHORT_R["Shorter Range"]
        HIGH_F --> HIGH_BW["Higher Bandwidth"]
    end

HaLow operates far below traditional WiFi frequencies - gaining range at the cost of throughput

Range and Throughput

HaLow's range advantage comes from physics. Radio waves at 900MHz diffract around obstacles more effectively than 2.4GHz signals. They penetrate concrete walls with less attenuation. They propagate further through foliage and terrain. For outdoor deployments, HaLow can cover agricultural fields, parking lots, and campuses with a single access point where traditional WiFi would need dozens.

The throughput options in 802.11ah scale from minimal to moderate:

1MHz channel, MCS 0: 150 kbps. Enough for a temperature sensor sending a reading every few seconds. Maximum range - up to 1km or more.

4MHz channel, MCS 7: About 7.8 Mbps. Sufficient for low-resolution video from a security camera. Range drops to a few hundred meters.

16MHz channel, MCS 9: Up to 86.7 Mbps. Competitive with older WiFi standards for throughput but limited to US-market deployments with enough spectrum and much shorter range.

For most IoT use cases, the low-bandwidth modes are the relevant ones. A soil moisture sensor, a weather station, a smart water meter, a structural health monitor - these devices send kilobytes of data at intervals measured in minutes or hours. HaLow's 150 kbps minimum is overkill for these applications, and the range advantage at low MCS rates is exactly what they need.

HaLow Network Architecture

HaLow uses the same infrastructure BSS model as regular WiFi. An AP serves multiple client STAs. The AP sends beacons, clients associate, and data flows through the AP. The familiar WiFi topology applies - just at a different frequency.

HaLow introduces some modifications for IoT efficiency:

Restricted Access Window (RAW): The AP divides time into restricted windows and assigns groups of clients to specific windows. This prevents hundreds of sensors from contending simultaneously, reducing collision overhead in networks with many low-traffic devices.

Short beacons: Traditional WiFi beacons carry extensive capability information and can exceed 300 bytes. HaLow defines short beacons (around 40 bytes) to reduce overhead on narrow channels where beacon transmission consumes a significant fraction of airtime.

Relay mode: HaLow supports AP-managed relay stations that extend range beyond a single hop. A relay device receives frames from distant clients and forwards them to the AP, enabling coverage beyond the single-AP range limit.

IoT Applications

Smart agriculture: Soil sensors, weather stations, irrigation controllers, and livestock trackers spread across large fields. HaLow's range covers hectares from a single AP. The low data rates match the periodic measurement patterns.

Industrial monitoring: Vibration sensors on machinery, pressure gauges on pipelines, temperature sensors in warehouses. These environments often have thick concrete walls and metal structures that attenuate higher-frequency signals. HaLow's penetration helps.

Smart cities: Parking sensors, air quality monitors, street lighting controllers, waste bin level sensors. A city-wide sensor network needs long range, low power, and low cost per node. HaLow competes with LoRa and NB-IoT in this space.

Building management: HVAC sensors, occupancy detectors, and energy meters across large commercial buildings. HaLow can cover a multi-story building with fewer APs than 2.4GHz WiFi.

The IP-Native Advantage

HaLow's strongest argument against competitors like Zigbee, Z-Wave, and LoRa is its IP-native stack. HaLow is WiFi. It carries standard IP packets. TCP and UDP work natively. HTTP, MQTT, CoAP, and every other IP-based protocol works without translation.

Zigbee and Z-Wave use their own network layer protocols and require a gateway to translate between their protocol and IP. This gateway is an extra device to buy, power, maintain, and secure. It is also a single point of failure. If the gateway goes offline, the entire sensor network loses connectivity to the IP world.

LoRa/LoRaWAN has a similar gateway dependency, plus its network architecture requires a network server for device management and data routing. The infrastructure complexity is significantly higher than WiFi's simple AP-client model.

HaLow sensors connect directly to a WiFi AP and receive IP addresses. They can communicate with cloud services, local servers, or other IP devices without any intermediate translation layer. Existing IT infrastructure - DHCP servers, DNS, firewalls, monitoring tools - works without modification.

graph TD
    subgraph "Zigbee/Z-Wave - Gateway Required"
        ZS1[Zigbee Sensor] -->|Zigbee protocol| ZGW[Zigbee Gateway]
        ZS2[Zigbee Sensor] -->|Zigbee protocol| ZGW
        ZGW -->|Protocol translation| IP1[IP Network]
        IP1 --> CLOUD1[Cloud/Server]
    end
    subgraph "HaLow - IP Native"
        HS1[HaLow Sensor] -->|WiFi/IP native| HAP[HaLow AP]
        HS2[HaLow Sensor] -->|WiFi/IP native| HAP
        HAP -->|Standard IP routing| IP2[IP Network]
        IP2 --> CLOUD2[Cloud/Server]
    end
    subgraph "LoRaWAN - Complex Infrastructure"
        LS1[LoRa Sensor] -->|LoRa radio| LGW[LoRa Gateway]
        LGW -->|IP backhaul| LNS[Network Server]
        LNS -->|Application routing| CLOUD3[Application Server]
    end

HaLow sensors speak IP natively - no gateway translation layer needed unlike Zigbee, Z-Wave, or LoRaWAN

Security in HaLow

802.11ah supports the full WiFi security stack, including WPA3. This gives HaLow a meaningful advantage over competing IoT protocols where security is often an afterthought or limited by constrained resources.

Zigbee uses 128-bit AES encryption but has a network-wide key that, if compromised, exposes all traffic. Z-Wave uses Security 2 (S2) with per-device keys but has had implementation vulnerabilities. LoRaWAN v1.1 improved security over v1.0 but the upgrade path has been slow.

HaLow devices running WPA3 get SAE (Simultaneous Authentication of Equals) key exchange, 128-bit or 192-bit encryption, and Protected Management Frames by default. These are the same security mechanisms used by enterprise WiFi networks, applied to IoT devices. The computational overhead of WPA3 is manageable on modern microcontrollers - the constraint is power, not processing.

Adoption Status in 2026

HaLow has been slow to gain traction since the 802.11ah standard was finalized in 2017. Silicon availability was limited for several years, with only a handful of chipmakers (Morse Micro, Newracom/now part of Renesas) producing HaLow radios. As of 2026, more silicon options exist and several HaLow access points and modules are commercially available.

The competitive field is crowded. LoRa has a large installed base in LPWAN applications. NB-IoT and LTE-M use licensed cellular spectrum with carrier support. Thread (based on 802.15.4) is gaining momentum in smart home through Matter. WiFi HaLow offers a unique combination of range, IP-native operation, and strong security, but must overcome the incumbents' head start.

HaLow and the BLEShark Nano

The BLEShark Nano's ESP32-C3 radio operates on 2.4GHz WiFi and BLE. It cannot receive or transmit on the sub-GHz frequencies used by 802.11ah. HaLow traffic is completely invisible to the Nano - the frequency bands do not overlap.

This is worth stating explicitly because "WiFi" in the name might create confusion. HaLow is a WiFi standard that shares the 802.11 frame format and protocol logic with regular WiFi, but it uses entirely different radio hardware operating at entirely different frequencies. You need a dedicated sub-GHz radio to interact with HaLow networks.

That said, understanding HaLow is useful context for anyone working with wireless IoT. If you are scanning a facility with the BLEShark Nano and see fewer WiFi devices than expected, some of those "missing" devices might be on a HaLow network operating below the Nano's frequency range. Similarly, the BLE scanner on the Nano can detect BLE-based IoT devices (Zigbee coordinators, Thread border routers) that coexist with HaLow deployments in multi-protocol environments.