Wi-Fi HaLow (802.11ah) vs LoRaWAN vs LTE-M: Long-Range IoT Selection Guide

Most long-range IoT selection guides rank radios by range and battery life, and then quietly assume every device sends a few dozen bytes a day. That assumption is exactly where Wi-Fi HaLow changes the answer. HaLow, the Wi-Fi Alliance name for IEEE 802.11ah, is the only one of the three technologies in this comparison that is a native IP link with megabit-class rates, yet it still runs in sub-GHz spectrum with kilometre-scale reach and sleep schedules measured in hours.

That matters now because HaLow silicon, certified modules and regulatory approvals have moved from sampling to shipping, while LoRaWAN duty-cycle limits and cellular sunset plans keep squeezing the other two options at the edges. A plant engineer deciding between a gateway-based LPWAN, a carrier subscription and a new Wi-Fi flavour is really choosing a payload profile, an ownership model and an operations burden.

This guide gives you the physical-layer mechanics of 802.11ah, a worked link budget, a power model built on target wake time, and a decision matrix you can defend in a design review.

What this covers: the 802.11ah PHY and MAC, how it differs from LoRaWAN and LTE-M, a worked link budget, a code-level energy comparison, failure modes, and a selection procedure for industrial deployments.

Context and Background

Long-range IoT has historically been a three-way split. Unlicensed LPWANs such as LoRaWAN trade throughput for sensitivity: a 125 kHz LoRa channel at spreading factor 12 carries 250 bit/s, and in the EU868 plan the highest-rate setting reaches 5,470 bit/s with SF7 (values from the LoRaWAN Regional Parameters as published in The Things Network documentation). Cellular LPWANs, principally LTE-M (Cat-M1) and NB-IoT, inherit licensed spectrum and operator roaming but charge per device and depend on a tower being in range.

Wi-Fi never competed in this space because 2.4 GHz and 5 GHz radios die at tens of metres and burn too much power idling. IEEE 802.11ah, ratified in 2016 and amended into the base 802.11 standard, was designed to remove both limits. It moves the radio below 1 GHz, narrows the channels to 1, 2, 4, 8 or 16 MHz, shortens the headers, and adds a power-save toolkit including target wake time (TWT) and the restricted access window (RAW). The Wi-Fi Alliance markets the result as Wi-Fi HaLow and describes it as roughly 1 km range with good wall penetration, months to years of coin-cell battery life, and native IP support with no proprietary hub.

The academic overview by Khorov et al., IEEE 802.11ah: The Wi-Fi Approach for M2M Communications, remains the clearest summary of the design targets: outdoor range up to 1 km, up to 8,191 stations per access point from a 13-bit association identifier (against 2,007 in legacy 802.11), and a MAC header cut from 28 to 18 bytes. Its Table 1 lists 0.15 to 4 Mbps at 1 MHz and 0.65 to 7.8 Mbps at 2 MHz, which gives you the realistic order of magnitude for a narrowband deployment.

For the incumbent comparison, our earlier piece on LoRaWAN vs NB-IoT vs LTE-M for industrial IoT covers the two incumbents in depth, and the LoRaWAN protocol technical guide explains the MAC, classes and adaptive data rate. This article assumes you know those and focuses on where HaLow slots in.

A note on evidence quality. HaLow range numbers in marketing material are best-case, line-of-sight figures, and I have not found an independent, vendor-neutral field study that I can cite for industrial interiors. Where this article gives a distance, it is the output of a stated model, not a measurement, and it is labelled as illustrative.

How Wi-Fi HaLow Actually Works

Wi-Fi HaLow is 802.11 OFDM scaled down by a factor of ten in clock rate relative to 802.11ac, which is why the same ideas that give Wi-Fi its throughput now yield narrower channels and more robust symbols. The result is a link that behaves like Wi-Fi from the IP layer upward and like a sub-GHz LPWAN from the antenna down.

Figure 1: A Wi-Fi HaLow deployment. Stations speak IP directly to an access point that bridges onto ordinary Ethernet, so no protocol translation layer sits between the sensor and the broker.

Figure 1 shows the architectural difference that matters most. The access point is a layer-2 bridge, not a gateway that unwraps radio frames and re-encodes them for a network server. A sensor can open a TCP or TLS connection to an MQTT broker the same way a laptop does, and standard tooling (DHCP, DNS, VLANs, 802.1X, packet captures) continues to work.

Spectrum and channel widths

The S1G (sub-1 GHz) PHY uses whatever licence-exempt spectrum a region allows. The Khorov overview lists Europe at 863 to 868 MHz, the United States at 902 to 928 MHz and Japan at 916.5 to 927.5 MHz, with China, South Korea and Singapore also holding allocations. Channel width is regulatory-dependent: 1 and 2 MHz channels are the widely adopted ones, while 4, 8 and 16 MHz channels exist in the standard and are allowed in some countries.

This is the first practical consequence for a global product. The US 26 MHz span fits several 2, 4 or 8 MHz channels, so a US plant can run wide channels for throughput. The European 5 MHz span at 863 to 868 MHz leaves room for only a few narrow channels shared with other short-range devices, so European HaLow is a 1 and 2 MHz story. A device certified for one region is not automatically usable in another, and module vendors ship regional variants.

PHY: tones, modulation and rate

The PHY uses OFDM with 32 or 64 tones spaced 31.25 kHz apart, the downclocked relative of Wi-Fi’s 312.5 kHz spacing. Modulation across the MCS table runs from BPSK at MCS0, through QPSK for MCS1 and MCS2, 16-QAM for MCS3 and MCS4, 64-QAM for MCS5 to MCS7, and 256-QAM for MCS8 and MCS9. The standard also defines a repetition mode for the 1 MHz channel that trades throughput for extra robustness, which is what pushes the floor down to the low-hundreds-of-kbit/s regime the Khorov paper cites (0.15 Mbps at 1 MHz, and a design requirement of at least 100 kbit/s).

Compare that with LoRa’s chirp spread spectrum. LoRa buys sensitivity by spreading energy over time, so each doubling of the spreading factor roughly halves the bit rate, and SF12 uses 250 bit/s. HaLow buys sensitivity by narrow channels and low-order modulation, and then gives you a ladder of rates that climbs into megabits when the link is good. That ladder is the central trade: LoRa has a deeper floor, HaLow has a much higher ceiling and a much smoother rate adaptation curve.

MAC: shorter frames, huge station counts, and RAW

The 802.11ah MAC cuts overhead because every byte at 150 kbit/s hurts. The header shrinks from 28 to 18 bytes, and null-data packets and compressed addressing reduce the cost of acknowledgements and polls. In the Khorov simulation set, a typical sensor payload is around 100 bytes, an ACK or PS-Poll is 14 bytes and a TIM beacon is 62 bytes, which shows how much of airtime is protocol, not data.

Scaling to thousands of stations needs a way to avoid a collision storm when they all wake at once. The restricted access window (RAW) divides the beacon interval into slots and assigns groups of stations to specific slots, so only a subset contends at a time. RAW does not remove contention. It spreads it, and tuning group size and slot duration is the main knob when a site grows beyond a few hundred devices.

Target wake time: the power-save contract

Target wake time (TWT) is a negotiated schedule. A station and the access point agree when the station will next wake, how long it will stay awake and how often, and the station sleeps in between without listening to beacons. TWT originated in 802.11ah and was later reused in 802.11ax (Wi-Fi 6), which is why you will see it discussed in Wi-Fi 6 material.

Figure 2: A TWT agreement. The station negotiates a wake interval, sleeps deeply, wakes only to transmit and collect buffered downlink, and returns to sleep.

Without TWT, a station in classic power-save mode must wake for beacons and check the traffic indication map, which caps sleep at a few beacon intervals. With TWT the sleep interval can be minutes or hours, and the Khorov paper notes that long sleep periods can be set at association to very long intervals. That is the feature that moves HaLow from “low-power Wi-Fi” to a contender against LPWANs.

The Comparison: Architecture, Link Budget and Throughput

The short answer to “which one wins” is that none does across all axes. LoRaWAN wins on sensitivity and gateway economics for tiny payloads, LTE-M wins on mobility and zero infrastructure, and Wi-Fi HaLow wins on throughput, latency and IP-native integration when you own the site.

Figure 3: LoRaWAN architecture. Uplinks are received by every gateway in range and de-duplicated by the network server, which also runs adaptive data rate and the join procedure.

Three different network models

LoRaWAN, shown in Figure 3, is a star-of-stars. Devices broadcast, any gateway in range forwards the frame to a central network server, and that server de-duplicates, enforces the MAC and routes the payload to an application server. This is excellent for sparse, low-rate uplinks, because devices need no association and gateway placement can be iterated. The cost is that gateways are protocol translators, the radio is ALOHA-style, and downlink capacity is scarce.

LTE-M is a carrier service. The device holds a SIM, attaches to an eNodeB, and rides the operator’s core network, with roaming agreements providing coverage abroad. You do not run radio infrastructure, but you inherit the operator’s pricing, SIM management and technology roadmap, including network-sunset schedules for legacy generations that you should check per country and operator.

Wi-Fi HaLow is closest to a private enterprise wireless LAN. You deploy access points, you own the spectrum plan within regulatory limits, and the devices join a standard 802.11 BSS with WPA3-class security. There is no per-device subscription. The trade is that coverage is yours to design, and you carry the operations burden of RF planning.

Headline parameters side by side

Values below come from the sources cited in this article; anything else is marked as typical or illustrative.

Parameter	Wi-Fi HaLow (802.11ah)	LoRaWAN (EU868)	LTE-M (Cat-M1)
Spectrum	Licence-exempt sub-GHz (863-868 MHz EU, 902-928 MHz US)	Licence-exempt sub-GHz	Licensed LTE bands
Channel width	1, 2, 4, 8, 16 MHz	125 kHz typical	UE bandwidth about 1.08 MHz (1.4 MHz carrier)
Rate range	0.15 to about 4 Mbps at 1 MHz; 0.65 to 7.8 Mbps at 2 MHz	250 to 5,470 bit/s at 125 kHz	Up to about 1 Mbps class; far lower in deep coverage
Max app payload	IP MTU scale (about 1,500 bytes)	51 bytes at DR0 to 222 bytes at DR4 and DR5	IP MTU scale
Duty cycle	Regional rules, typically not the binding limit	0.1% to 10% by sub-band	Operator-managed
Topology	AP with bridged IP	Gateways plus network server	Operator core
Stations per cell	Up to 8,191 per AP (standard limit)	Gateway-limited by airtime	Operator-limited
Subscription	None	None (private) or network operator	Per-device

The LoRaWAN rows come from the regional-parameters tables: DR0 is SF12 at 250 bit/s with a 51-byte application payload, DR3 is SF9 at 1,760 bit/s with 115 bytes, and DR4 and DR5 reach 3,125 and 5,470 bit/s with 222 bytes. The LTE-M peak figure is a standards-class number, and the GSMA coverage-analysis white paper is the right place to see how quickly rate collapses at the edge.

A worked link budget

Link budgets are where claims about range become checkable. I will use a deliberately simple model so you can reproduce it, and I label every input as an assumption.

The path loss model is log-distance with a 1 m reference: PL(d) = FSPL(1 m, f) + 10 n log10(d) + M. At 900 MHz, free-space loss at 1 m is 20 log10(0.001 km) + 20 log10(900 MHz) + 32.44, which equals 31.5 dB. Assume a path-loss exponent n of 3.0 for a semi-cluttered industrial yard, and a fade-and-penetration margin M of 15 dB.

Receiver sensitivity is the thermal noise floor plus noise figure plus the required SNR. Thermal noise is -174 dBm/Hz plus 10 log10(bandwidth). For HaLow at 1 MHz that is -114 dBm; add a 5 dB noise figure and assume the most robust mode needs about 0 dB SNR (assumption), giving roughly -109 dBm. For LoRa at 125 kHz the floor is -123 dBm; add 6 dB noise figure and the SF12 demodulation SNR of about -20 dB (typical figure from Semtech transceiver datasheets, quoted from memory, so treat as approximate), giving roughly -137 dBm.

Item	HaLow 1 MHz	LoRa SF12	LTE-M
TX power	20 dBm (assumed)	14 dBm (assumed EU limit)	23 dBm UE class
Sensitivity or MCL	about -109 dBm	about -137 dBm	MCL 164 dB (GSMA simulation)
Maximum allowed path loss	129 dB	151 dB	164 dB (UE side, simulated)
Distance at n = 3.0, M = 15 dB	about 560 m	about 3.0 km	about 8 km (tower power differs)

These distances are the output of a model, not field data. The relative order is robust: LoRa SF12 buys about 22 dB over HaLow’s most robust rate, which at an exponent of 3 is a factor of roughly 5.4 in range. HaLow’s honest range claim for a mixed industrial site is therefore a few hundred metres at its lowest rate and shorter at the high-rate MCS values, not the line-of-sight 1 km of the marketing figure.

Here is the same arithmetic as runnable Python, so you can substitute your own site’s exponent and margin.

import math

def fspl_1m(freq_mhz: float) -> float:
    # free-space loss at 1 m reference distance, in dB
    return 20 * math.log10(0.001) + 20 * math.log10(freq_mhz) + 32.44

def sensitivity_dbm(bw_hz: float, nf_db: float, snr_db: float) -> float:
    return -174 + 10 * math.log10(bw_hz) + nf_db + snr_db

def max_distance_m(tx_dbm, sens_dbm, freq_mhz, n=3.0, margin_db=15.0):
    mapl = tx_dbm - sens_dbm            # maximum allowed path loss
    budget = mapl - margin_db - fspl_1m(freq_mhz)
    return 10 ** (budget / (10 * n))

links = {
    "HaLow 1 MHz robust": (20, sensitivity_dbm(1e6, 5, 0)),
    "LoRa SF12 125 kHz":  (14, sensitivity_dbm(125e3, 6, -20)),
}
for name, (tx, sens) in links.items():
    d = max_distance_m(tx, sens, 900)
    print(f"{name}: sens {sens:.1f} dBm, range {d:.0f} m")

Running it gives about 560 m for HaLow and about 3,000 m for LoRa. Change n to 2.5 for a rural line-of-sight yard and both numbers grow substantially; change it to 3.5 for dense machinery and they shrink. The lesson is to measure your exponent with a site survey before trusting any vendor range.

What the throughput gap really buys

A single 125 kHz LoRa channel at SF12 moves 250 bit/s, so a 200-byte payload would need fragmentation into several 51-byte frames and several seconds of airtime each. At EU868’s 1% duty cycle a device gets 864 seconds of airtime per day, and The Things Network’s fair-use policy is stricter at 30 seconds per day for uplinks. If one 51-byte SF12 frame occupies on the order of 2 to 3 seconds (approximate, from the Semtech time-on-air formula), you can send only a few hundred such frames per day at most.

A HaLow link at even MCS0 on 1 MHz is hundreds of times faster, so the same 200 bytes plus TLS and TCP overhead goes out in tens of milliseconds. That difference decides whether firmware-over-the-air updates, vibration waveforms, thermal images or edge-inference results are practical. It also decides whether the digital twin can request data on demand, which LoRaWAN Class A downlinks barely permit.

Power, Certification and Ecosystem: The Deeper Analysis

Battery life is where the three technologies converge in marketing and diverge in practice, because each defines “years” under a different traffic assumption. The honest way to compare them is an energy-per-report model, which you can adapt to your own duty profile.

An energy-per-report model

A report costs three things: the wake-up and association overhead, the transmit energy over the airtime, and the sleep current integrated over the reporting interval. With LoRaWAN Class A there is no association, which makes a single short uplink cheap. With HaLow plus TWT the station keeps its association state (or resumes it cheaply), so a report is a wake, a short TCP or UDP exchange, and sleep. With LTE-M the modem uses power saving mode (PSM) and extended discontinuous reception (eDRX) to keep the registration alive while the radio is off.

The script below is a deliberately transparent model. Every current and time is an assumption chosen to be plausible for a sub-GHz radio, not a measured figure from a datasheet, so replace the numbers with those from your module’s datasheet before drawing conclusions.

def battery_years(capacity_mah, sleep_ua, report_s, tx_ma, tx_ms, overhead_ma, overhead_ms):
    """Average-current model for periodic reporting. All inputs are assumptions."""
    per_report_mas = tx_ma * tx_ms / 1000 + overhead_ma * overhead_ms / 1000
    avg_ma = sleep_ua / 1000 + per_report_mas / report_s
    hours = capacity_mah / avg_ma
    return hours / 8760

profiles = {
    # name: (sleep uA, tx mA, tx ms, overhead mA, overhead ms)
    "LoRaWAN SF9 (assumed)": (2, 45, 250, 10, 50),
    "HaLow TWT (assumed)":   (15, 120, 20, 40, 60),
    "LTE-M PSM (assumed)":   (5, 150, 400, 60, 1500),
}
for name, p in profiles.items():
    for interval in (600, 3600):
        yrs = battery_years(2400, p[0], interval, p[1], p[2], p[3], p[4])
        print(f"{name:24s} every {interval:5d}s -> {yrs:5.1f} years")

With these assumptions LoRaWAN lasts longest at long intervals because its sleep current and short frames dominate, HaLow sits in the middle, and LTE-M pays for its connection overhead each time it leaves PSM. The result I want you to take from it is structural rather than numeric: HaLow’s sleep current is typically higher than a purpose-built LPWAN radio because the baseband keeps more state, so its advantage appears when the payload is big enough that airtime, not sleep, dominates.

That crossover is easy to compute. A 10 kB report at 150 kbit/s takes about 0.55 s on air before overhead, while the same data on LoRa SF9 at 1,760 bit/s would need roughly 47 seconds and about 90 separate frames at the 115-byte maximum, far beyond any duty-cycle budget. For large payloads the faster radio finishes sooner and returns to sleep, so energy per bit favours HaLow. For a 12-byte temperature reading the opposite is true.

Security and IP integration

HaLow inherits Wi-Fi’s security stack, and the Wi-Fi Alliance describes it as offering the latest Wi-Fi security, which in current certification practice means WPA3. I did not find a statement on its HaLow page naming specific modes, so check the certificate of a given product for exact security requirements. LoRaWAN uses AES-128 session keys derived at join, with network and application session keys held in separate servers in version 1.1. LTE-M rides carrier-grade SIM authentication.

Because HaLow endpoints are ordinary IP nodes, publishing telemetry is the same code you would write for any device. This minimal client uses the standard paho-mqtt library over TLS, and nothing in it knows the radio underneath.

import json, ssl, time
import paho.mqtt.client as mqtt

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="press-07")
client.tls_set(ca_certs="ca.pem", cert_reqd=ssl.CERT_REQUIRED)
client.username_pw_set("press-07", "REDACTED")
client.connect("broker.plant.local", 8883, keepalive=3600)
client.loop_start()

payload = {"ts": int(time.time()), "vib_rms": 0.42, "temp_c": 61.3}
client.publish("plant/line2/press-07/telemetry", json.dumps(payload), qos=1)
client.loop_stop()
client.disconnect()

The same device on LoRaWAN would need a payload codec at the network server, a gateway-to-MQTT integration and a frame size under 51 bytes at the slowest rate. That is not a flaw, but it is an extra system to run, and for a digital twin platform it is an extra mapping layer that must be kept in sync with firmware. On the other hand, a LoRaWAN fleet scales from one gateway to thousands of sensors with almost no per-device network cost.

Certification status and silicon

The Wi-Fi Alliance’s HaLow page dates the technology to 2017 and promises multi-vendor interoperability, and the certification programme debuted in November 2021, according to Morse Micro’s announcement of the first certified reference design. That matters because interoperability is the entire reason to choose Wi-Fi over a proprietary sub-GHz stack; an uncertified module is a bet on one vendor’s firmware.

On the silicon side, Morse Micro’s MM6108 is the widely cited HaLow system-on-chip, and Quectel’s FGH100M module is built on it. According to a January 2024 Business Wire release, the FGH100M was described as the first HaLow module to achieve both European CE and US FCC certification. That release gives no benchmark figures and calls the MM6108 the fastest, smallest, lowest-power and longest-range HaLow chip, which is a vendor self-description rather than a measured comparison. Newracom is another HaLow silicon vendor whose material discusses the technology, but I did not verify its current product line this run, so check availability directly.

Two practical consequences follow. First, HaLow modules exist as certified, drop-in parts, so you are not doing RF design from scratch. Second, the ecosystem is far smaller than LoRaWAN’s or cellular’s, meaning fewer sensors with HaLow built in, fewer gateway-class access points, and fewer field-proven integrators. Expect to bridge from existing sensors through a HaLow-equipped microcontroller board.

Coexistence and spectrum realities

Sub-GHz ISM bands are shared. In the EU868 plan the same 863 to 870 MHz region hosts LoRaWAN, Sigfox, Zigbee-class devices and utility metering, and Europe’s duty-cycle rules apply to every transmitter. The IEEE 802.19 coexistence working group has published materials on coexistence methods between 802.11 and 802.15.4-based systems in the sub-1 GHz bands, which indicates that regulators and standards bodies treat the overlap as a real engineering problem rather than a theoretical one.

In practice, a HaLow access point at 1 MHz in Europe sits among narrowband LoRa channels, so a site that already operates a LoRaWAN fleet should survey the band before adding HaLow. In the United States the 26 MHz span of 902 to 928 MHz gives more room, but LoRaWAN US915 uses wide hopping sets across the same range. Run a spectrum survey and plan HaLow channels around the gateways you already have.

Trade-offs, Gotchas, and What Goes Wrong

The failure modes below are the ones that surprise teams after pilot, not before. None is fatal, and each has a mitigation, but each should be tested during the pilot rather than assumed away.

Figure 4: A selection flow. Start with whether cellular coverage is both available and acceptable, then payload size, then the need for native IP and low latency.

Range disappoints at high rates. The 1 km figure is a lowest-MCS, clear-line-of-sight number. At MCS7 with 64-QAM the required SNR rises by well over 20 dB, so the practical radius of a high-rate link can be a fraction of the robust-mode radius. Rate adaptation hides this on paper but not in throughput measurements, so a map of coverage by MCS is more useful than a single range circle.

Uplink-heavy networks suffer contention. Thousands of stations per access point is a protocol ceiling, not a deployment target. Without RAW tuning, a power-restoration event that wakes every station simultaneously produces a thundering herd. Stagger TWT schedules deliberately and plan the numbers per access point using airtime, not association identifiers.

TWT needs both sides to behave. Power savings depend on the access point honouring agreements and the station’s firmware actually reaching deep sleep. In early deployments, many apparent battery problems come from a network stack that keeps the radio on for DHCP renewals, ARP traffic or mDNS chatter. Pin the lease length, use static addressing where policy allows, and disable chatty discovery protocols on battery nodes.

Cellular has hidden operating costs. LTE-M removes the radio plan but adds SIM logistics, per-device recurring fees, and a dependency on an operator’s roadmap. Deep indoor placements may need the coverage-enhancement repetition modes, and the GSMA analysis shows what that costs: at 164 dB maximum coupling loss the simulated downlink physical-layer rate drops to 1,400 bit/s with 512 repetitions and the uplink to 250 bit/s with 1,536 repetitions. A basement meter that attaches fine can still report slowly and burn battery.

LoRaWAN downlink and duty-cycle limits. Class A devices receive only after an uplink, so commands wait. At EU868’s 1% limit, 864 seconds of airtime per day is the legal ceiling and 30 seconds is the community-network fair-use cap. Confirmed uplinks, join retries and adaptive-data-rate changes all spend that budget, and a gateway outage can turn a retry storm into a compliance problem.

Region-locked hardware. HaLow modules are regional. A device built for 902 to 928 MHz cannot be shipped to Europe’s 863 to 868 MHz allocation, so a multinational rollout needs several SKUs, regulatory testing and firmware that enforces channel plans. The CE and FCC certification of a module does not cover your end product, which needs its own conformity assessment.

Ecosystem immaturity. The biggest honest risk for HaLow in 2026 is ecosystem depth, not physics. Fewer off-the-shelf sensors, fewer managed-service options, and thinner tooling mean more integration engineering for you. For a fleet of 50,000 soil sensors that should live ten years on a battery and send 12 bytes daily, that engineering cost is not justified.

Practical Recommendations

Choose by traffic profile and ownership model first, and by range second. The three technologies overlap only in a narrow band of requirements, and the overlaps are where people burn time on proofs of concept that could have been settled on paper.

Pick LoRaWAN when payloads are tiny (tens of bytes), reports are infrequent, battery life is the dominant requirement and you can place gateways. Pick LTE-M when devices move, when sites are numerous and geographically scattered, when you cannot place infrastructure, or when voice-class or mobility features matter, and when you accept a per-device subscription. Pick Wi-Fi HaLow when you own the site, want IP-native endpoints, need kilobytes per report or on-demand polling, must cross walls or steel at moderate range, or want firmware updates over the air.

Hybrid designs are common and sensible. A plant can run LoRaWAN for hundreds of low-rate environmental sensors, HaLow for a few dozen vibration or camera nodes that need throughput, and LTE-M for mobile assets such as trailers. A digital twin platform should ingest all three through a normalised telemetry model, a topic we also touch on in the Wi-Fi protocols technical comparison.

Use this checklist before committing:

• Measure your path-loss exponent with a survey and recompute the link budget with your own margin.
• Count the bytes per report including TLS or codec overhead, and compute airtime on each candidate.
• Verify the module has current Wi-Fi Alliance HaLow certification and regional regulatory approval for every target country.
• Model battery life from datasheet currents, not from marketing years, and test TWT sleep on real firmware.
• Survey existing sub-GHz occupancy, especially if LoRaWAN gateways already operate on site.
• Price three-year total cost: devices, access points or gateways, subscriptions and integration labour.
• Plan the pilot with at least 50 nodes at the worst coverage spots, not the best.

Frequently Asked Questions

What is Wi-Fi HaLow and how is it different from regular Wi-Fi?

Wi-Fi HaLow is the Wi-Fi Alliance name for IEEE 802.11ah, a Wi-Fi variant that runs in licence-exempt sub-GHz spectrum instead of 2.4 or 5 GHz. It uses narrow 1 to 16 MHz channels, shorter MAC headers and power-save features such as target wake time. The result is longer range, better wall penetration and far lower power than conventional Wi-Fi, at the cost of lower data rates, while still carrying native IP traffic.

How far can Wi-Fi HaLow reach compared with LoRaWAN?

The Wi-Fi Alliance cites roughly 1 km with good wall penetration, a best-case figure. In the worked link budget above, a robust 1 MHz HaLow link at 20 dBm reaches about 560 m with an exponent of 3 and 15 dB margin, while LoRa SF12 at 14 dBm reaches about 3 km under the same model. LoRaWAN has the deeper sensitivity floor; HaLow trades it for much higher throughput. These are modelled, not measured, figures.

What is target wake time and why does it matter for battery life?

Target wake time is a negotiated schedule in which a station and its access point agree when the station will next wake and for how long. Between those windows the radio sleeps without listening to beacons. It originated in 802.11ah and was later adopted in 802.11ax. Long agreed sleep intervals are what let a Wi-Fi device compete with LPWANs on battery life, provided the firmware really reaches deep sleep.

Is Wi-Fi HaLow certified and available in modules today?

Yes. The Wi-Fi Alliance certification programme debuted in November 2021 according to Morse Micro, and certified reference designs and modules followed. In January 2024 Quectel and Morse Micro announced the FGH100M module, based on the MM6108 chip, as the first HaLow module with both European CE and US FCC certification. Verify current certificates and regional approvals for any specific product before purchase.

When should I choose LTE-M instead of HaLow or LoRaWAN?

Choose LTE-M when devices move, are scattered across many sites, or sit where you cannot install your own access points or gateways. It uses licensed spectrum, carrier roaming and SIM authentication, so you avoid radio planning. You pay for it with per-device fees, dependence on operator coverage and roadmap, and reduced rates in deep-coverage repetition modes, where the GSMA analysis shows simulated physical-layer rates falling to the hundreds of bit/s.

Can HaLow and LoRaWAN run on the same site?

Yes, and many sites should. LoRaWAN suits hundreds of tiny low-rate sensors, while HaLow suits the few nodes that need kilobytes per report or IP-native access. Both use shared sub-GHz spectrum, so survey occupancy first, especially in Europe’s narrow 863 to 868 MHz allocation, and plan HaLow channels around existing gateways. Feed both into one normalised telemetry model on the digital twin platform.

Further Reading

• LoRaWAN vs NB-IoT vs LTE-M for industrial IoT in 2026 for the incumbent comparison.
• LoRaWAN protocol: the complete technical guide for classes, adaptive data rate and security.
• Wi-Fi protocols: a complete technical comparison for how HaLow relates to Wi-Fi 6 and 7.
• Khorov et al., IEEE 802.11ah: The Wi-Fi Approach for M2M Communications, the standard design overview.
• The Things Network, LoRaWAN EU868 regional parameters, for data rates and duty-cycle sub-bands.
• GSMA, Coverage Analysis of LTE Cat-M1, for coverage-enhancement behaviour.

By Riju — about