23 Wi-Fi HaLow (802.11ah) for IoT
Wi-Fi HaLow, 802.11ah, sub-1 GHz Wi-Fi, long reach Wi-Fi for IoT, HaLow IoT design review
23.1 Start With the Wireless Story
HaLow starts with a trade: less peak speed for longer range and many sleepy devices. Check sub-1 GHz spectrum, channel width, association scale, RAW scheduling, security, gateway support, and regional rules before treating it as ordinary Wi-Fi.
23.2 In 60 Seconds
Wi-Fi HaLow is the Wi-Fi family path based on IEEE 802.11ah. It uses sub-1 GHz license-exempt spectrum instead of the normal 2.4, 5, or 6 GHz Wi-Fi bands. That can make it useful when an IoT system needs longer reach, better obstruction tolerance, private access point ownership, and IP-based service behavior.
HaLow is not normal Wi-Fi with a longer antenna. Existing 2.4, 5, or 6 GHz clients cannot connect to a HaLow access point unless they have a HaLow radio. It is also not automatically better than LoRaWAN, NB-IoT, LTE-M, Thread, Zigbee, Ethernet, or conventional Wi-Fi. The right answer depends on device radio support, regional spectrum rules, channel plan, antenna placement, service traffic, power behavior, security, operations, and installed-site evidence.
Use this chapter to decide whether HaLow is a candidate and what evidence must be collected before approving it.
Phoebe’s Why
The speed lock \(c=f\lambda\) means HaLow’s sub-1 GHz band stretches wavelength to nearly triple ordinary 2.4 GHz Wi-Fi’s – that is why a HaLow monopole is a noticeably bigger piece of metal than a 2.4 GHz chip antenna. But wavelength does a second job this chapter does not spell out: an antenna’s gain figure in dBi is a ratio against an isotropic radiator, and the isotropic radiator’s own effective catching area grows with \(\lambda^2\). So two antennas rated at the identical gain – one built for 915 MHz, one for 2.4 GHz – do not intercept the same amount of an incoming wavefront. The lower-frequency antenna physically catches more, purely from geometry, before either radio’s transmit power or the access point’s RAW scheduling enters the picture at all.
The Derivation
Speed lock:
\[\lambda = \frac{c}{f}\]
Effective aperture of an antenna with gain \(G\) (isotropic aperture \(\lambda^2/4\pi\) scaled by \(G\)):
\[A_e = \frac{G\lambda^2}{4\pi}\]
Friis transmission between two antennas of gain \(G_t\), \(G_r\) at distance \(d\):
\[P_r = P_t\,G_t\,G_r\left(\frac{\lambda}{4\pi d}\right)^2\]
Holding \(G_t\), \(G_r\), \(P_t\), \(d\) fixed and comparing two bands, the frequency-only penalty is:
\[\Delta\mathrm{FSPL}(\mathrm{dB}) = 20\log_{10}\frac{f_2}{f_1}\]
Worked Numbers: This Chapter’s Own Bands
- This chapter’s HaLow center, 915 MHz: \(\lambda=3.00\times10^{8}/915\times10^{6}=0.328\) m \(= 32.8\) cm; quarter-wave monopole \(=32.8/4=8.20\) cm.
- This chapter’s comparison band, 2.4 GHz: \(\lambda=0.125\) m \(=12.5\) cm; quarter-wave monopole \(=12.5/4=3.13\) cm – the size difference behind “HaLow is not normal Wi-Fi with a longer antenna.”
- Same-gain aperture ratio: \((\lambda_{915}/\lambda_{2400})^2=(32.8/12.5)^2=6.88\), i.e. \(10\log_{10}(6.88)=8.38\) dB more captured power for antennas of equal dBi gain at the same distance.
- Cross-check against Friis directly: \(\Delta\mathrm{FSPL}=20\log_{10}(2400/915)=8.38\) dB – the same number, confirming the aperture argument and the spreading-loss argument are two views of one effect.
- Honest finding, this chapter’s own 902-928 MHz US allocation: the in-band spread is only \(20\log_{10}(928/902)=0.247\) dB. Channel choice inside the HaLow band barely moves the link budget; the RAW group and TWT wake-window choices this chapter reviews matter far more than which 1 MHz channel is picked.
23.3 Learning Objectives
By the end of this chapter, you will be able to:
- explain what changes when Wi-Fi moves to a sub-1 GHz 802.11ah path
- separate HaLow feature claims from installed deployment evidence
- identify when HaLow-specific client and access point support is required
- compare HaLow with conventional Wi-Fi, LPWAN, and cellular IoT paths without using one universal ranking
- review power behavior using wake windows, retries, updates, and support workflows
- record a bounded HaLow decision with retest triggers
23.4 HaLow Fit Map
Use Figure 23.1 to decide whether HaLow deserves a full review.
The map keeps the decision narrow:
- if ordinary Wi-Fi already covers the site with the required power behavior, HaLow may add complexity
- if the device does not have a HaLow radio, it cannot join a HaLow network
- if the local sub-1 GHz rules do not support the planned channel and transmit profile, the design is not ready
- if the traffic needs continuous high bandwidth, a narrower long-reach Wi-Fi path may not fit
- if the team cannot operate access points, backhaul, security, monitoring, updates, and support reset, the radio choice is incomplete
23.5 HaLow Evidence Record
Use Figure 23.2 when a team needs to record why HaLow was accepted, deferred, or rejected.
A useful record answers:
- which device class, service path, and site are being reviewed
- which HaLow client and access point capabilities were confirmed
- which regional spectrum and channel constraints apply
- where the access point, antenna, and backhaul will live
- what installed coverage, retry, latency, and throughput evidence was collected
- how sleep, wake, command, failure recovery, and update windows behave
- how identity, onboarding, segmentation, revocation, and support reset are handled
- what changes require retesting
23.6 What HaLow Changes
HaLow changes the Wi-Fi review in five practical ways.
First, the radio band changes. HaLow uses sub-1 GHz spectrum. Lower frequency can help range and obstruction behavior, but it also brings regional channel, transmit, coexistence, and certification constraints.
Second, the client requirement changes. A phone, laptop, 2.4 GHz Wi-Fi module, or ordinary Wi-Fi sensor cannot join a HaLow access point unless it includes a compatible HaLow radio path.
Third, the capacity question changes. HaLow includes mechanisms for large station populations, grouping, and scheduled access, but the design still needs installed evidence for airtime, retries, wake windows, and operational load.
Fourth, the power question changes. HaLow can support low average energy through scheduled communication, but battery life depends on join attempts, retry behavior, message size, firmware update windows, network availability, and sleep leakage.
Fifth, the comparison set changes. HaLow is often reviewed against conventional Wi-Fi, LoRaWAN, cellular IoT, Thread, Zigbee, and wired backhaul. The strongest comparison is based on the service behavior, not on a single range or data-rate claim.
23.7 When HaLow Is A Strong Candidate
HaLow deserves a serious review when several conditions line up:
- the site is larger, more obstructed, or more distributed than ordinary Wi-Fi can serve cleanly
- the team needs a private IP network rather than a translation-heavy low-rate gateway path
- endpoints can use HaLow-specific radios and antennas
- traffic is moderate, intermittent, or scheduled rather than continuous high-bandwidth streaming
- access point placement and backhaul can be controlled
- regional rules support the intended band, channel width, transmit profile, and certification scope
- operations can manage security, monitoring, updates, and replacement over the product lifetime
Good candidate examples include distributed building sensors, industrial yard monitoring, utility sites, greenhouse or campus telemetry, and local video or image snapshots where installed throughput is proven.
23.8 When Another Path May Be Better
Choose ordinary Wi-Fi when the site is already covered, endpoints already support the needed band, traffic is local and higher bandwidth, and power behavior is acceptable.
Choose LoRaWAN or another LPWAN path when messages are very small, sparse, long range, and gateway or network-server behavior is acceptable.
Choose NB-IoT, LTE-M, or another cellular IoT path when the device must roam beyond a private site or when operator-managed wide-area coverage is part of the requirement.
Choose Thread, Zigbee, or another 802.15.4-family path when local low-power mesh behavior is more important than direct Wi-Fi-style IP service at each endpoint.
Choose wired Ethernet, fiber, or a point-to-point backhaul when high sustained throughput, fixed equipment, power availability, or deterministic operations matter more than battery radio reach.
23.9 Regional Spectrum Review
HaLow planning starts with local rules, not with a product brochure.
Record:
- the region where the product will operate
- the allowed sub-1 GHz band and channel choices
- the access point and client radio profiles supported in that region
- antenna, enclosure, and installation constraints
- coexistence with other sub-1 GHz systems on the site
- certification scope for prototype, pilot, and release builds
Do not reuse a HaLow decision across regions without checking the radio profile again. The same application can need different channel, antenna, power, and validation evidence in different markets.
23.10 Coverage And Traffic Evidence
A HaLow coverage review should not stop at association success.
Check:
- where association succeeds and where it fails
- retry behavior at the edge of coverage
- uplink and downlink service behavior
- command latency during normal and busy periods
- firmware update feasibility
- behavior after access point restart, backhaul loss, battery recovery, and credential changes
- whether a single access point creates an operating risk that should be reduced with overlap or fallback
For traffic, classify the flow:
- telemetry: small periodic messages
- event alerts: rare messages that must arrive promptly
- commands: downlink control that needs bounded response
- diagnostics: larger but occasional transfers
- images or video snapshots: heavier transfers that require measured evidence
- firmware updates: large maintenance traffic that may need a separate window
23.11 Power Behavior
HaLow power review belongs in the installed design, not only in the data sheet.
Target Wake Time and Restricted Access Window style scheduling can reduce idle listening and contention when the access point and clients are configured correctly. The power plan still needs evidence for:
- cold boot and association energy
- scan time after a missed access point
- retry behavior during interference or weak signal
- scheduled wake windows for telemetry and commands
- update windows for larger transfers
- support reset and recommissioning
- battery behavior at expected temperatures and enclosure conditions
A good power answer states the operating pattern. A weak answer says “HaLow gives years of battery life” without showing the wake schedule, failure behavior, and maintenance traffic.
23.12 Security And Operations
HaLow does not remove the normal Wi-Fi security review.
Review:
- how devices are provisioned without exposing shared secrets
- whether device identity is unique and revocable
- how the HaLow network is segmented from other services
- how access point management is protected
- how firmware updates are delivered and audited
- how lost, replaced, or decommissioned devices are removed
- how support teams recover a device without weakening the fleet
Operations evidence should include monitoring, alert routing, spare access point strategy, configuration backup, and the owner for retesting after firmware, antenna, enclosure, site, or regional profile changes.
23.13 Worked Review: Greenhouse Monitoring
Scenario:
- a greenhouse site has rows of low-rate environmental sensors
- ordinary Wi-Fi reaches only part of the site after doors, glass, frames, and equipment are considered
- the operating team owns the site network and can place a dedicated access point
- the sensors need IP-based telemetry, occasional commands, and maintenance updates
Review:
- Confirm that endpoint modules and the access point support the same regional HaLow profile.
- Measure association, retries, telemetry delivery, and command response at representative rows.
- Test the firmware update path during a maintenance window.
- Compare HaLow against LPWAN if the traffic can be reduced to sparse uplinks.
- Record support reset and device replacement steps before release.
Bounded decision:
- HaLow is a candidate if installed coverage, wake behavior, command response, update behavior, and operations evidence are acceptable.
- It is not approved by the word “greenhouse” or by a range claim alone.
23.14 Worked Review: Warehouse Retrofit
Scenario:
- a warehouse needs sensors on doors, containers, and mobile service points
- metal shelving changes the propagation path
- ordinary Wi-Fi already exists for handheld terminals
- some endpoints need only alerts, while others need diagnostic transfers
Review:
- Split endpoint classes before choosing a radio.
- Test HaLow in aisles, loading areas, and obstructed corners rather than extrapolating from an open-space test.
- Check coexistence with other sub-1 GHz systems used on the site.
- Keep ordinary Wi-Fi for devices that already have strong coverage and higher throughput needs.
- Use HaLow only where its reach and obstruction behavior solve a measured gap.
Bounded decision:
- A mixed design may be stronger than a single-radio replacement.
- The review should prove where HaLow helps and where it adds unnecessary operational surface.
23.15 Worked Review: Outdoor Utility Yard
Scenario:
- equipment is fixed across an outdoor yard
- sensors need telemetry, event alerts, and occasional configuration commands
- the owner wants a private network with local backhaul
Review:
- Confirm line-of-sight and obstructed paths separately.
- Test after access point restart and backhaul outage.
- Measure command response at the edge of coverage.
- Confirm that battery or power budgets include missed joins and retries.
- Compare cellular IoT if ownership, movement, or off-site expansion changes the requirement.
Bounded decision:
- HaLow can be appropriate when private IP reach, local ownership, and installed evidence line up.
- Cellular or wired backhaul may win when the site boundary, mobility, or operations model changes.
23.16 Knowledge Check: HaLow Client Support
23.17 Knowledge Check: Choosing The Comparison
23.18 Match Evidence To Review Area
23.19 Order A HaLow Review
23.20 Common Mistakes
Treating HaLow as long-range ordinary Wi-Fi:
- Problem: the design assumes existing Wi-Fi clients can join.
- Repair: confirm HaLow-specific client and access point support first.
Approving from a range statement:
- Problem: the team uses a marketing or lab range claim instead of installed evidence.
- Repair: test the actual antenna, enclosure, access point placement, backhaul, and obstruction conditions.
Ignoring regional spectrum:
- Problem: a result from one country or pilot profile is reused in another release region.
- Repair: check the allowed band, channel plan, transmit profile, certification scope, and local coexistence again.
Skipping power failure behavior:
- Problem: the review counts only normal wake intervals.
- Repair: include missed joins, retries, command windows, firmware updates, and support reset.
Replacing a mixed design with one radio:
- Problem: HaLow is forced onto every endpoint even when ordinary Wi-Fi, LPWAN, cellular, or wired paths fit some classes better.
- Repair: split device classes and approve HaLow only where it solves a measured problem.
23.21 Final Checklist
Before approving HaLow, confirm that you have:
- named the device class, service path, owner, and site boundary
- verified HaLow radio support on both client and access point
- checked the regional spectrum and release scope
- measured coverage, retries, latency, throughput, and failure recovery at the installed site
- reviewed wake windows, commands, updates, and support workflows
- compared the strongest non-HaLow alternatives for the same traffic
- documented security, segmentation, monitoring, and operations ownership
- recorded retest triggers for firmware, antenna, enclosure, access point profile, region, site, and traffic changes
23.22 Wi-Fi That Trades Speed for Range and Scale
Wi-Fi HaLow is the Wi-Fi Alliance name for IEEE 802.11ah, a version of Wi-Fi built for IoT rather than laptops. Instead of the crowded 2.4/5 GHz bands, it runs in sub-1-GHz license-exempt spectrum, such as the 902–928 MHz band used by many US designs. That lower frequency can reduce path loss and improve obstruction tolerance, so an installed HaLow link may cover outdoor yards, long corridors, greenhouses, or utility rooms that would need many ordinary 2.4 GHz access points. The word may matters: walls, antennas, allowed transmit profiles, regional channel rules, and interference still decide the real link budget.
The design goals are the opposite of mainstream Wi-Fi: longer reach, low average energy, and large station populations at modest data rates. A single HaLow access point is designed to serve thousands of sensors, but that scale is not a promise that every station can talk whenever it wants. The access point must shape who wakes, who contends, which traffic is buffered, and when maintenance traffic is allowed.
Think of HaLow as an IP access network for constrained site devices, not as a magic range extender. It can be attractive when the team owns the access point, can place antennas deliberately, wants private addressing and security controls, and has endpoints with real 802.11ah radios. It is weak when the requirement is high-rate video, broad consumer-device compatibility, roaming across public networks, or a region where the selected sub-GHz profile is not available. A defensible review names both sides: the measured gap ordinary Wi-Fi could not cover, and the operating evidence that HaLow can carry the actual traffic.
HaLow in a line: sub-GHz Wi-Fi for longer-range, lower-duty-cycle IoT stations — useful when radio capability, regional rules, power scheduling, and site evidence all line up.
Overview Knowledge Check
23.23 Narrow Channels and Massive Association
HaLow’s PHY uses narrow channels — 1, 2, 4, 8, or 16 MHz (regions with little sub-GHz spectrum use mainly 1 and 2 MHz). Narrow channels concentrate power and are robust over distance; the 1 MHz mode reaches farthest at sub-Mbit/s rates, while 16 MHz trades range for tens of Mbit/s. This is the same width-vs-reach trade as mainstream Wi-Fi, shifted down in both frequency and rate.
To serve thousands of devices, 802.11ah widened the association ID (AID) to 13 bits, allowing up to 8191 stations per AP, and reorganised the paging (TIM) structure hierarchically so the AP can signal buffered traffic to that many devices efficiently without a bloated beacon.
A practitioner review should start with a device-class table rather than a radio slogan. For each class, record the message size, reporting interval, required downlink latency, update size, battery target, enclosure, antenna position, and support workflow. Then choose the candidate HaLow channel width and access point placement that match those classes. If some devices need continuous diagnostics, local images, or fast firmware updates, they may need a different class, a second channel plan, or ordinary Wi-Fi kept beside HaLow.
The field test should measure more than coverage. At representative near, mid, and edge positions, record association time, retry rate, RSSI/SNR or vendor-equivalent quality, uplink and downlink latency, throughput for the largest legitimate transfer, and behavior after access point restart or backhaul loss. Repeat the test with the intended enclosure and antenna orientation. A bench result from an exposed radio module is not release evidence for a sealed sensor mounted behind metal shelving.
Worked example. A smart-agriculture site spreads 2000 soil sensors across several hectares. Ordinary 2.4 GHz Wi-Fi cannot cover the range or the device count from one AP. A single HaLow AP on a 1 MHz channel may reach the far fields and, thanks to the 13-bit AID and hierarchical TIM, track all 2000 sensors. Each station wakes briefly to report soil moisture at sub-Mbit/s, which is ample for a few bytes per reading. The approval still depends on measured edge retries, command latency, battery recovery after missed joins, and a maintenance window for larger updates.
Practitioner Knowledge Check
23.24 RAW Tames Contention Among Thousands
Thousands of stations sharing one channel would collide constantly under ordinary CSMA/CA — the moment they all wake to report, contention explodes. 802.11ah’s key mechanism against this is the Restricted Access Window (RAW). The AP divides stations into groups and assigns each group its own time window; a station may only contend during its group’s RAW slot. This slices a stampede of thousands into orderly, small contention pools.
RAW pairs with Target Wake Time (TWT), which lets each station negotiate exactly when to wake, so a sensor can sleep for minutes and rise only for its scheduled window. TWT protects the battery; RAW protects the shared channel. The access point can also buffer downlink frames and advertise which groups need to wake, so quiet sensors do not spend energy listening to every beacon as if they were always-active laptops.
The hidden engineering detail is that scheduling must follow the service model. Telemetry-only stations can tolerate long sleep intervals and narrow RAW windows. Alarm devices need faster downlink reachability or a separate wake pattern. Firmware updates need a maintenance phase because the normal sensor window may be too small for large transfers. If every station is placed in the same window, or if a support workflow requires immediate downlink to sleeping sensors, the design has not actually used HaLow’s scheduling model.
Worked example. At the top of each reporting cycle all 2000 soil sensors would otherwise contend at once. With RAW, the AP places them in 20 groups of 100 and hands each group a separate window; only 100 sensors ever contend at a time, so collisions stay lower and each report has a realistic chance to clear quickly. Scheduled TWT wakeups keep every radio off between its windows. The release test should prove the timing with real logs: group assignment, missed-window recovery, buffered downlink behavior, and battery cost when interference forces retries.
Under-the-Hood Knowledge Check
23.25 Summary
Wi-Fi HaLow is a useful IoT option when sub-1 GHz Wi-Fi reach, private IP networking, and controlled access point operation solve a measured problem. It is not a drop-in upgrade for existing Wi-Fi clients and it is not a universal LPWAN replacement.
A strong HaLow decision connects radio capability, regional rules, installed coverage, traffic behavior, power scheduling, security, operations, and retest triggers to the actual scenario.
23.26 Key Takeaway
Wi-Fi HaLow (802.11ah) For IoT should match Wi-Fi standard, band, channel plan, airtime, density, security, power profile, and deployment evidence to the IoT use case.
23.27 What’s Next
Use Wi-Fi Standards Evolution to place HaLow inside the wider Wi-Fi standards path.
Use Wi-Fi Bands & Channels for spectrum and channel-planning evidence.
Use Wi-Fi Power Consumption for sleep, wake, retry, command, and update behavior.
Use Wi-Fi Deployment Planning for installed validation and operations.
Use Wi-Fi Certification Reference for claims, release scope, and certification evidence.
Use LoRaWAN Overview or NB-IoT Fundamentals when the comparison should include LPWAN or cellular IoT paths.
Use Wi-Fi Hands-On Labs and Exercises when you need practical Wi-Fi evidence-gathering skills.