The trade-offs

Every radio in an IoT device is a compromise between four things:

  • Range: how far apart the device and the receiver can be, through walls and floors.
  • Power: how much energy each message costs, and whether the device can sleep between messages.
  • Bandwidth: how many bytes per second, and how many messages per day, the link carries.
  • Cost: the radio chip, the infrastructure it needs (an access point, a hub, a gateway, a mobile subscription) and any fees per device.

Physics makes these pull against each other. A receiver can pick up a weaker signal if the data comes more slowly, so long range at low power means low data rates. Higher transmit power gives more range but empties the battery. And lower frequencies travel further: in the textbook formula for free-space path loss, the loss grows with the square of the distance and with the square of the frequency, and lower frequencies also pass walls better. The example compares 868 MHz, used in Europe by LoRaWAN and sub-GHz Zigbee, with 2.4 GHz, used by Wi-Fi, Bluetooth, Zigbee and Thread. It uses the general textbook formula for open space; buildings add much more loss.

import math


def free_space_loss_db(distance_km, frequency_mhz):
    """Free-space path loss: the general textbook formula, no walls or obstacles."""
    return 20 * math.log10(distance_km) + 20 * math.log10(frequency_mhz) + 32.44


for distance_km in (0.1, 1.0, 10.0):
    sub_ghz = free_space_loss_db(distance_km, 868)
    wifi = free_space_loss_db(distance_km, 2400)
    print(f"{distance_km:>5} km: 868 MHz {sub_ghz:5.1f} dB, "
          f"2.4 GHz {wifi:5.1f} dB, difference {wifi - sub_ghz:.1f} dB")
  0.1 km: 868 MHz  71.2 dB, 2.4 GHz  80.0 dB, difference 8.8 dB
  1.0 km: 868 MHz  91.2 dB, 2.4 GHz 100.0 dB, difference 8.8 dB
 10.0 km: 868 MHz 111.2 dB, 2.4 GHz 120.0 dB, difference 8.8 dB

Every 6 dB of extra loss halves the range in open space, so 8.8 dB means that, with the same transmitter and receiver, an 868 MHz link reaches about 2.8 times as far (2400 / 868). In the United States the same kind of radio uses 902–928 MHz instead of 868 MHz, which gives about 2.6 times the range of 2.4 GHz. Frequencies are shared by many users; see frequency bands for how Wi-Fi uses them. The radios on this page work in license-free bands, except cellular, which uses the operators' licensed spectrum.

Wi-Fi

Wi-Fi is the obvious choice for a device in a home or office: the network already exists, data rates are high, and the device gets an IP address and talks to anything. Most IoT chips, including the ESP32 family, use the 2.4 GHz band, which reaches further indoors than 5 GHz; the ESP32-C5 is one of the chips that also supports 5 GHz (Wi-Fi 6).

The drawback is energy. Joining a network and keeping a connection costs far more than the protocols below, which is why Wi-Fi suits mains-powered devices or devices that wake rarely (see the energy budget on Power and Batteries). Two newer developments help: Wi-Fi 6's Target Wake Time lets a device agree with the access point when it will wake, so it can sleep longer, and Wi-Fi HaLow uses sub-1 GHz frequencies for a range of about 1 km, at lower data rates.

Kestrel Energy's Kestrel Home pilot, which started in September 2026, uses Wi-Fi for its P1 dongle: it is powered by the meter's P1 port (or by USB on older DSMR 4 meters), so energy is no issue, and the household's own Wi-Fi carries the readings to the internet. The weak spot is the location. Meter cupboards are often in a hallway or basement, far from the router and behind walls, and a weak Wi-Fi signal there is a common reason why a P1 reader keeps dropping out.

Bluetooth Low Energy

Bluetooth Low Energy (BLE, Bluetooth LE) is the low-power part of the Bluetooth standard, designed for devices that send small amounts of data now and then and run for months or years on a coin cell. It uses the 2.4 GHz band from 2.402 to 2.480 GHz, divided into 40 channels of 2 MHz: 3 advertising channels and 37 data channels.

A BLE device can simply advertise: broadcast a short packet every so often that any nearby receiver picks up, without a connection. Many thermometers and beacons work this way. Or it accepts a connection from a phone or hub and exchanges data. Because almost every phone speaks BLE, it is also the usual way to set up a new device from a phone app; Matter and Zigbee Direct both use it to bring devices into their networks. The limitation is range and reach: a BLE device needs a phone, hub or gateway nearby to get its data to the network. As of October 2026 the current Bluetooth Core specification is version 6.3 (May 2026).

Zigbee, Thread and Matter

Zigbee and Thread both build on the same low-power radio standard, IEEE 802.15.4, and both form a mesh: mains-powered devices such as smart plugs and lamps act as routers that pass messages on, so the network grows with every device and messages can find another path when one router fails. Battery devices such as sensors and switches stay end devices that sleep most of the time and only talk to their nearest router.

Zigbee

Zigbee is a low-power mesh networking standard on IEEE 802.15.4 for home and building automation: lamps, switches, sensors and smart plugs, managed by a coordinator in a hub. It has its own network layer (not IP), so a hub or gateway translates between Zigbee and the rest of the network. Zigbee 4.0, announced in November 2025, is backward compatible with Zigbee 3.0 and adds sub-GHz operation under the name Suzi (800 MHz in Europe, 900 MHz in North America) for longer range, better key management and Zigbee Direct for setting devices up from a phone over BLE.

Thread

Thread is a low-power mesh networking protocol on IEEE 802.15.4 that carries IPv6, compressed to fit the small radio packets (6LoWPAN). Every Thread device has its own IPv6 address and can be reached like any other IP device; a border router (often built into a smart speaker, a TV box or a hub) connects the Thread mesh to the home's Wi-Fi or Ethernet. The current version is Thread 1.4 (September 2024). The name has nothing to do with a thread in programming.

Matter

Matter is not a radio. It is an application standard for smart home devices that defines what a lamp, lock or thermostat is and how apps and hubs from different vendors control it, locally and without a cloud. It runs over Wi-Fi, Thread and Ethernet, uses BLE to set devices up, and since version 1.6 (June 2026) also NFC. A Matter lamp on Thread and a Matter plug on Wi-Fi can be controlled from the same app. More on Matter, hubs and Home Assistant is on Smart Home and Building Automation.

LoRa and LoRaWAN

LoRa (from "long range") is a radio modulation, chirp spread spectrum, that lets a receiver decode very weak signals, so small amounts of data travel several kilometers on little energy. It is only the physical layer: how bits become radio waves.

LoRaWAN is the network protocol on top of LoRa: it defines how devices send messages to gateways, how gateways forward everything they receive over the internet to a network server, how devices join the network with keys, and how the network adapts each device's data rate. The LoRa Alliance puts it plainly: "LoRa" is not short for "LoRaWAN". A LoRaWAN device does not connect to one gateway; every gateway that hears it forwards the message, and the network server removes duplicates. Networks are run by operators (in the Netherlands, KPN offers LoRa) or by communities such as The Things Network.

LoRaWAN defines three device classes, which trade energy for how quickly the network can reach the device:

  • Class A (all devices): after each uplink the device listens for a reply in two short windows, then sleeps. Lowest power; the network can only answer, never start a conversation.
  • Class B: adds receive slots at scheduled times, synchronized by beacons from the gateways.
  • Class C: listens all the time except while transmitting. Lowest delay for commands, highest power use, usually for mains-powered devices.

The data rate is set by the spreading factor, from SF7 (fastest, shortest range) to SF12 (slowest, longest range). Each step up roughly doubles the time a message spends on the air.

Duty-cycle and airtime limits

License-free bands are shared by everyone, so the law limits how much each transmitter may use them. A duty-cycle limit is a legal maximum on the fraction of time a radio transmitter may send in a given frequency band, so that no single device can occupy a shared band. Which limit applies depends on the region and its band:

In Europe, the 863–870 MHz band used by LoRaWAN is divided into sub-bands, each with its own limit (ETSI EN 300 220-2):

Sub-band Frequencies Duty-cycle limit
K 863–865 MHz 0.1%
L 865–868 MHz 1%
M 868.0–868.6 MHz 1%
N 868.7–869.2 MHz 0.1%
P 869.4–869.65 MHz 10%
Q 869.7–870 MHz 1%

A 1% limit means 36 seconds of transmitting per hour in that sub-band, and after a message that took t on the air, the device waits until 100 × t has passed since it started. In several sub-bands the rules allow listen-before-talk with adaptive frequency agility as an alternative to the duty cycle; LoRaWAN devices in practice use the duty cycle.

In the United States, LoRaWAN uses the 902–928 MHz band ("US915"), and there is no duty-cycle limit. The FCC rules for this band (47 CFR 15.247) limit how long a transmitter stays on one channel instead:

  • A frequency-hopping system with channels narrower than 250 kHz must hop over at least 50 channels and may occupy each channel for at most 0.4 seconds within any 20 seconds (the dwell time).
  • A digitally modulated system must use a bandwidth of at least 500 kHz, with a limit on power per 3 kHz.
  • Maximum conducted output power is 1 watt (with an antenna gain of up to 6 dBi).

The 400 ms dwell time caps the airtime of each 125 kHz LoRa frame, so in practice US915 uplinks reportedly use SF7 to SF10 only, and at SF10 the payload must stay small: the 25-byte frame in the example below, at 411.6 ms, would already be too long.

In the United Kingdom, the same bands and limits apply as in the EU, set by Ofcom's interface requirement IR 2030 for license-exempt short-range devices (latest version published 7 April 2026). For example, 868.0–868.6 MHz allows 25 mW e.r.p. with listen-before-talk or a duty cycle of at most 1%, and 869.40–869.65 MHz allows 500 mW e.r.p.

A 1% limit means 36 seconds of transmitting per hour in that sub-band, and after a message that took t on the air, the device waits until 100 × t has passed since it started.

Networks can add their own rules on top: The Things Network's fair-use policy allows each device 30 seconds of uplink airtime per day and 10 downlink messages per day.

Airtime therefore decides how often a device may send. The example computes it with Semtech's formula for LoRa frames (125 kHz bandwidth, coding rate 4/5, an 8-symbol preamble, explicit header and CRC, low-data-rate optimization at SF11 and SF12) for a 12-byte sensor reading plus 13 bytes of LoRaWAN headers and integrity check:

import math


def lora_airtime_ms(payload_bytes, sf, bw_hz=125_000, coding_rate=1, preamble=8,
                    explicit_header=True, crc=True):
    """Time on air of one LoRa frame (Semtech's formula, coding rate 4/(4+coding_rate))."""
    low_rate_opt = 1 if sf >= 11 and bw_hz == 125_000 else 0
    t_symbol = 2 ** sf / bw_hz
    t_preamble = (preamble + 4.25) * t_symbol
    bits = 8 * payload_bytes - 4 * sf + 28 + 16 * crc - 20 * (not explicit_header)
    symbols = 8 + max(math.ceil(bits / (4 * (sf - 2 * low_rate_opt))) * (coding_rate + 4), 0)
    return (t_preamble + symbols * t_symbol) * 1000


PAYLOAD = 12 + 13      # 12 bytes of sensor data + 13 bytes of LoRaWAN overhead
print(" SF   airtime   uplinks/day in 30 s   1% duty cycle: next start after")
for sf in range(7, 13):
    ms = lora_airtime_ms(PAYLOAD, sf)
    per_day = int(30_000 // ms)
    cycle_s = ms / 0.01 / 1000
    print(f"{sf:>3} {ms:>7.1f} ms {per_day:>12} {cycle_s:>25.1f} s")
 SF   airtime   uplinks/day in 30 s   1% duty cycle: next start after
  7    61.7 ms          486                       6.2 s
  8   113.2 ms          265                      11.3 s
  9   205.8 ms          145                      20.6 s
 10   411.6 ms           72                      41.2 s
 11   823.3 ms           36                      82.3 s
 12  1482.8 ms           20                     148.3 s

A device near a gateway at SF7 may send a reading every few minutes within the fair-use policy; a device far away at SF12 gets 20 uplinks per day, roughly one every 72 minutes. That is plenty for a water meter or a soil sensor, and nowhere near enough for a live power reading every second. LoRaWAN is for small, infrequent messages.

Cellular IoT: NB-IoT and LTE-M

Where there is no Wi-Fi and no LoRaWAN gateway, devices can use the mobile network. Two variants of 4G (LTE) were standardized for devices in 3GPP Release 13, completed in June 2016:

  • LTE-M (LTE for machines, also called LTE Cat-M1 or eMTC) is a cellular standard for IoT devices that uses a narrow 1.4 MHz slice of an LTE network. It supports moderate data rates, handover between cells for moving devices, and voice; it suits trackers, alarm panels and wearables.
  • NB-IoT (Narrowband IoT) is a cellular standard for IoT devices that uses an even narrower channel of 180 to 200 kHz. It reaches deep indoors and underground, at low data rates and with longer delays; it suits fixed devices that send small amounts, such as meters and parking sensors.

Both have power-saving features that change how you troubleshoot them. In power saving mode (PSM) the device stays registered with the network but switches its radio off and cannot be reached, for up to about 413 days; it behaves almost like it is off, but does not have to join the network again when it wakes. With extended discontinuous reception (eDRX), the device checks for messages only every so often, up to about 44 minutes on LTE-M and about 175 minutes on NB-IoT. A command sent to such a device can take that long to arrive.

Each cellular device needs a SIM (often a built-in eSIM) and a subscription, and its lifetime depends on the operator's network. In the Netherlands, as of October 2026: KPN has switched off 3G and will switch off 2G on 1 December 2027, and offers LTE-M, NB-IoT and LoRa for IoT; VodafoneZiggo has switched off 3G and will not switch off 2G before the end of 2026; Odido has switched off 2G and announced that 3G would run at least until 1 August 2026, with six months' notice before it stops, so check its current status. Devices that rely on 2G or 3G need a replacement plan.

Dutch smart meters are a large example. A smart meter reports to its grid operator over its own mobile connection: older meters over 2G (GPRS), replacement meters over 4G, and a separate group over CDMA on 450 MHz (see Private LTE and 5G). Because of the 2G switch-off, grid operators are replacing about 2.6 million meters that use 2G. None of this involves the customer's Wi-Fi: a P1 reader like Lotte's only listens to the meter's local port. How readings travel from the meter to the supplier is on Smart Meters and the P1 Port.

Comparing the options

A rough chart of range against data rate. Wi-Fi sits at short range with high data rates. Bluetooth Low Energy sits at the shortest range with moderate data rates. Zigbee and Thread sit at short range with low data rates, extended by their mesh. LTE-M and NB-IoT cover long distances through the operator's network with low to moderate rates. LoRaWAN covers kilometers at the lowest data rates. The positions are qualitative. typical range a room a building a district a region high low data rate Wi-Fi Bluetooth LE Zigbee, Thread (mesh) LTE-M, NB-IoT LoRaWAN
Rough positions only: real range depends on transmit power, antennas, buildings and, for cellular, the operator's coverage.
Range Power Data Needs
Wi-Fi a home or office high high (Mbit/s) an access point; device gets its own IP address
Bluetooth LE a room to a house very low small amounts a phone, hub or gateway nearby
Zigbee a house or building, via the mesh very low for end devices small amounts a hub (coordinator); mains devices as routers
Thread a house or building, via the mesh very low for end devices small amounts, IPv6 a border router; mains devices as routers
LoRaWAN kilometers very low a few bytes, few times a day a gateway in range and a network server
LTE-M, NB-IoT wherever the operator has coverage low with PSM and eDRX small to moderate a SIM and a subscription

Choosing a radio

Work through these questions in order:

  1. Where does the energy come from? Mains or the P1 port: Wi-Fi is fine. Battery for years: BLE, Zigbee, Thread, LoRaWAN or cellular with power saving.
  2. How much data, how often? A value per second rules out LoRaWAN; a value per hour fits everything.
  3. How far, and through what? Within a house: Wi-Fi, BLE or a mesh. Across a field or a city: LoRaWAN or cellular.
  4. What infrastructure exists? Wi-Fi and a phone are almost always there; a Zigbee hub, a Thread border router or a LoRaWAN gateway may need to be added; cellular needs a subscription for every device, for its whole life.
  5. Must the device receive commands quickly? Battery devices that sleep cannot; plan for delays, or keep the receiving side on mains power.

Lotte Kortenhoeve's two devices show the difference. Her P1 reader sends a value every second and is powered by the meter: Wi-Fi. For the temperature sensor in her garden shed, her own energy budget gave a Wi-Fi board on batteries about a year at best. Her plan is a ready-made Zigbee sensor, with a Zigbee USB adapter on the Raspberry Pi that runs her Home Assistant and a Zigbee smart plug in the kitchen as a router between the house and the shed.