LPWAN protocol comparison

LoRaWAN vs NB-IoT vs Sigfox: which LPWAN fits your 2026 project?

LoRaWAN leads for private-network IoT, smart-building and smart-city; NB-IoT wins on operator-grade coverage and regulated metering; Sigfox (UnaBiz) is in managed decline.

Last updated: June 20265 sections

Low-power wide-area networking (LPWAN) has been the quiet backbone of the IoT decade — enabling water meters, parking sensors, soil probes and building comfort sensors to run for ten years on a coin cell while transmitting across a city. In 2026, three technologies still appear on LPWAN shortlists: LoRaWAN, NB-IoT and Sigfox. But the competitive dynamics have shifted sharply.

LoRaWAN, specified by the LoRa Alliance (500+ members), runs on unlicensed ISM spectrum and supports fully private gateway deployments — making it the natural choice for smart-building integrators, municipalities and industrial operators who want end-to-end data sovereignty without a carrier contract. NB-IoT, standardised by 3GPP Release 13 as LTE Cat-NB1 (Cat-NB2 in Release 14), operates on licensed operator spectrum with deep-indoor coverage gains (+20 dB MCL vs GSM), mandatory carrier dependency and native PSM/eDRX power-saving modes defined in the 3GPP stack. Sigfox — the French UNB pioneer acquired by Singapore's UnaBiz in April 2022 — remains operational but is losing ground on new project awards as its 12-byte uplink ceiling and 140-messages-per-day cap fail to meet modern IoT requirements.

This guide compares LoRaWAN and NB-IoT in depth; Sigfox is covered as a market reference and the historical third option. Our 2026 verdict: LoRaWAN for private-network deployments, smart-building / GTB integrations and cost-sensitive large-scale IoT; NB-IoT for nation-scale rollouts with operator SLA, regulated metering and deep-indoor requirements; Sigfox only for existing fleets where migration cost is prohibitive.

CriterionLoRaWANNB-IoT
SpectrumUnlicensed ISM — EU868 (863-870 MHz), US915, AU915, AS923, IN865 and othersLicensed operator spectrum — LTE bands 700/800/850/900 MHz; carrier contract required
Standard bodyLoRa Alliance LoRaWAN 1.0.4 / 1.1, open specification3GPP Release 13 LTE Cat-NB1; Release 14 Cat-NB2; Release 15+ enhancements
Deep-indoor coverageMCL ~157 dB at SF12 — good indoor penetration, improved by private indoor gatewaysMCL ~164 dB — +20 dB gain vs GSM, HARQ repetitions; superior basement/metal-cabinet coverage
Private network optionYes — deploy your own gateways (Kerlink, RAK, Multitech) + open-source LNS (ChirpStack, TTI)No — endpoints can only attach to a carrier eNodeB; no private base-station option
Battery power managementClass A: radio off between uplinks (deep sleep 1-2 µA); Class C: continuous RX, mains onlyPSM (Power Saving Mode) and eDRX (Extended DRX) natively defined in 3GPP; 10+ year battery feasible
Downlink latencyClass A: variable (seconds to hours); Class C: < 1 s (mains power required)With PSM: depends on PSM timer (minutes to hours); without PSM: < 10 s
Payload limitsMax 242 bytes at SF7; max 51 bytes at SF12 (EU868); 1% duty-cycle cap on uplinksUp to 1 600 bytes uplink; no duty-cycle regulator restriction (licensed spectrum)
Sigfox (reference)UNB 100 Hz, 12 bytes uplink max, 4 bytes downlink, 140 messages/day; operated by UnaBiz (since 2022)
Spreading / modulationChirp Spread Spectrum (CSS), SF7-SF12, BW 125/250 kHz; Semtech SX126x/SX127x chipsetsOFDMA uplink, SC-FDMA downlink; single 180 kHz resource block within LTE carrier
RoamingLoRaWAN 1.1 passive roaming rolling out between TTN, Helium, Everynet; not universal yetLTE native roaming; pan-European inter-carrier roaming via SIM on many carrier plans
Typical deployment costCAPEX: $150-$500/gateway; no per-device carrier fee on private network; public LNS from ~$1-$5/device/yearNo gateway CAPEX; carrier subscription required — typically $2-$20/device/year depending on volume and SLA
Primary use casesWater/gas metering, parking, smart-city, agriculture, smart-building / BMS, asset trackingElectricity metering (next-gen smart meters), critical asset tracking, alarm panels, large-scale urban IoT with carrier SLA

Network architecture: private LoRaWAN vs carrier-dependent NB-IoT

The sharpest distinction between LoRaWAN and NB-IoT is not radio performance — it is who owns and operates the network.

LoRaWAN's ISM-band operation means any organisation can deploy gateways without a spectrum licence or carrier agreement. A standard 8-channel LoRaWAN gateway (Kerlink Wirnet iFemtoCell, RAK Wireless WisGate Edge, Dragino DLOS8) costs £150-$500, covers several square kilometres outdoors or several floors indoors, and connects to a Network Server you control — ChirpStack (open source, self-hosted) or The Things Industries (managed SaaS). This architecture gives the project team complete data sovereignty: every uplink flows through infrastructure you operate. For a smart-building integrator deploying LoRaWAN sensors across a commercial estate, this is a strong argument — no carrier contract, no per-device SIM, no dependency on a third party's coverage map.

NB-IoT terminals attach only to licensed eNodeB infrastructure operated by carriers. In the UK that means BT/EE, Vodafone and Three; in the US, T-Mobile, AT&T and Verizon; in Australia, Telstra and Optus. The carrier handles network management, coverage guarantees and SLAs. For a utility deploying 500 000 electricity meters across a national territory, that is the right trade-off — the project does not need to build or maintain radio infrastructure, and the carrier SLA covers coverage gaps. But for a property manager instrumenting a single office campus, a carrier subscription per device adds operational cost and a third-party dependency that a private LoRaWAN gateway eliminates.

For smart-building and BMS integrations — the CertifBus core audience — LoRaWAN consistently wins. Sensors connect to an on-site gateway; data flows via MQTT to a building management platform (Schneider EBO, Siemens Desigo CC, Tridium Niagara); no carrier involvement. NB-IoT is relevant when the building is large, geographically dispersed, or when the client insists on carrier-SLA coverage rather than managing a private gateway fleet.

Battery life in practice: LoRaWAN Class A versus NB-IoT PSM

Both technologies are designed for ten-year battery life — the engineering paths diverge.

LoRaWAN Class A is the simplest energy profile in LPWAN. The radio is fully off between uplinks. A Semtech SX1262 in deep sleep draws ~1.5 µA. The only energy expenditure is the TX burst (20-130 mA, 50-1 500 ms depending on SF) plus the two short RX windows that follow. At an hourly uplink cadence with SF9 in EU868, a device on two AA Li-SOCl2 cells (2 400 mAh each = 4 800 mAh total) conservatively delivers 10-14 years. Vendor datasheets bear this out: Diehl Metering Hydrus cites 12 years, Itron Cyble cites 10 years, Sagemcom Siconia cites 15 years at daily cadences. The profile is predictable and vendor-independent — any Class A implementation on any network delivers the same energy envelope.

NB-IoT PSM works differently. The device registers with the carrier network, sends its data, then requests a PSM timer via AT+CPSMS (3GPP TS 27.007). The network grants a T3412 value — often 1 to 24 hours — during which the device is unreachable but draws ~3-10 µA in deep sleep (some modules, like Quectel BC660K-GL, achieve ~2 µA). PSM suits use cases where messages are infrequent but must carry larger payloads: a monthly meter report with 20 index values, an alarm with a 500-byte event log, or a firmware delta-patch. The 1 600-byte payload limit means NB-IoT can send meaningful data in a single message where LoRaWAN SF12 would need fragmentation across several 51-byte frames.

eDRX (Extended Discontinuous Reception) is the complementary NB-IoT mode for devices that need faster downlink response without fully waking: the device stays registered but only checks the paging channel every few minutes or hours rather than every 1.28 seconds (LTE default). Combined with PSM, a smart-meter can spend most of its life in PSM and shift to eDRX for configuration windows.

Sigfox achieves similar battery life through extreme protocol simplicity: one 12-byte UNB message costs ~20 mA for ~2-6 ms. With 140 messages per day at that budget, a D-cell battery lasts many years. The constraint is not energy — it is the 12-byte ceiling and the one-way nature of the network in practice.

Deep-indoor coverage and the smart-metering case

Coverage depth is often the deciding factor when comparing LoRaWAN and NB-IoT for utility metering.

The key metric is MCL (Maximum Coupling Loss) — the maximum signal attenuation the link can survive end-to-end. NB-IoT targets 164 dB MCL (the 3GPP Release 13 design goal), compared to roughly 157 dB for LoRaWAN at SF12 in EU868. That 7 dB difference translates to an ability to reach devices in deeper basements, metal enclosures and thick-concrete buildings that occasionally lose LoRaWAN connectivity.

NB-IoT achieves this through HARQ repetitions: a device can retransmit the same subframe up to 128 times (Release 14 adds even more). The network coherently combines energy across repetitions, effectively trading latency for coverage. For a gas meter bolted inside a metal utility cabinet in a basement, that repetition budget matters.

LoRaWAN's answer is density: deploying an additional indoor gateway. A £200 LoRaWAN indoor concentrator hung in a building's utility room turns a marginal link into a strong one. For a landlord with 200 apartments in the same block, one indoor gateway adds coverage without any carrier negotiation.

In smart-electricity-metering, NB-IoT holds the high ground. Enedis's next-generation Linky meter program (Linky NG, target 2027-2030 rollout) is planned around NB-IoT with Orange, leveraging operator-grade MCL and national coverage without private gateway infrastructure. For gas and water in UK and Australian deployments, LoRaWAN with indoor gateways dominates new tenders — Arqiva Smart Metering (UK), Telstra IoT (AU) and most municipal water deployments use LoRaWAN.

Sigfox in 2026: a managed transition, not a live choice

Sigfox deserves an honest assessment rather than a dismissal. It was genuinely pioneering: the first LPWAN to achieve national coverage (France, 2013), the first to prove that a 12-byte message from a sensor buried in a field could reach a cloud endpoint reliably. The technology — UNB (Ultra-Narrow Band) at 100 Hz channel spacing — is elegant: simple, power-efficient, and excellent at avoiding interference.

The business case collapsed for reasons that had little to do with the radio. Sigfox's proprietary network required capital-intensive deployment in each country and generated device-subscription revenue only; the IoT market scaled more slowly than projected, and LoRaWAN's open ecosystem took volume. Sigfox filed for insolvency in January 2022. UnaBiz, a Singapore-headquartered LPWAN operator, acquired the assets in April 2022 and has maintained the network since.

In 2026 the Sigfox network is live in France and approximately 70 countries. UnaBiz has announced a 0G branding strategy and is building NB-IoT / LoRaWAN bridges. However, the protocol ceiling of 12 bytes uplink and 140 messages per day is not a carrier decision — it is baked into the radio standard. You cannot FUOTA a Sigfox device. You cannot send a 100-byte configuration payload. You cannot reliably trigger an actuator (4-byte downlink, maximum 4 per day).

Practical guidance: If you have an existing Sigfox fleet under contract with UnaBiz and your application genuinely fits within 12 bytes and a few messages per day, renewing is defensible. For greenfield deployments starting in 2026, Sigfox is not the right starting point — LoRaWAN and NB-IoT offer better protocol flexibility and clearer long-term ecosystem support.

Smart-building, BMS and the role of LoRaWAN as the wireless IoT layer

CertifBus covers the building automation and industrial IoT protocols that real professionals get certified on. LoRaWAN sits at the intersection of these worlds as the dominant wireless sensing layer in smart-building deployments.

A typical modern commercial building instruments at two levels. At the control layer: KNX or BACnet/MSTP for wired actuators — lighting, blinds, HVAC zone valves, access control. At the sensing layer: LoRaWAN for wireless sensors — room temperature/humidity/CO₂ (Elsys ERS-CO2, Milesight EM300-MCS, Adeunis Comfort), desk occupancy, sub-metering of electricity, heat and water. The two layers are bridged at the building controller (Schneider EcoStruxure Building Operation, Siemens Desigo CC, Tridium Niagara N4) via MQTT or a protocol gateway. KNX handles the deterministic real-time actuation; LoRaWAN handles the distributed, battery-powered sensing.

NB-IoT is a poor fit for in-building sensor networks: it requires a carrier SIM per device (cost and complexity), does not support private gateways (coverage inside a building depends entirely on carrier signal through walls), and adds carrier contract management to a building operator's IT stack. Inside a 50 000 m² office campus, a private LoRaWAN gateway deployed per floor outperforms any carrier-NB-IoT coverage at a fraction of the total cost.

The LoRaWAN Airtime Calculator (available free on CertifBus) helps system designers verify that their payload sizes and transmit intervals respect EU868 duty-cycle rules before deployment — a practical tool for smart-building IoT specification.

When to choose

LoRaWAN

  • You need a private network with data sovereignty — no carrier contract, no per-device SIM fee, no third-party coverage dependency
  • Your deployment is smart-building, BMS, smart-city infrastructure or precision agriculture where you control the gateway placement
  • Your devices are battery-powered sensors (Class A profile, 10+ year battery life) with moderate message rates and payloads under 242 bytes
  • You want to integrate with a KNX, BACnet or Modbus BMS via MQTT — LoRaWAN gateways feed directly into standard IoT middleware
When to choose

NB-IoT

  • You are deploying nationally or across a wide geography without the ability to install and manage gateways — carrier coverage is the only realistic option
  • Your use case demands deep-indoor MCL guarantees (dense basement meter installations, metal enclosures) that indoor gateway deployment cannot cover economically
  • Payload size matters: you need to send 100-1 600 bytes in a single message (event logs, firmware patches, meter data with multiple indexes)
  • NB-IoT also covers the Sigfox migration case: if you are moving off Sigfox, NB-IoT and LoRaWAN are both valid destinations — choose based on whether you want private-gateway control (LoRaWAN) or operator-managed coverage (NB-IoT)

Frequently asked questions

Which LPWAN should I choose for smart water metering in 2026?
It depends on scale and control preference. For a **municipal deployment** where you manage a defined building stock or geographic area, LoRaWAN with private indoor gateways is typically more cost-effective and gives you full data control. Deployments by UK water utilities (Anglian Water, Thames Water pilots), Australian councils and French bailleurs sociaux consistently choose LoRaWAN with ChirpStack or TTI. For a **national utility rollout** across hundreds of thousands of meters where carrier SLA and managed coverage are more valuable than gateway control, NB-IoT with a carrier agreement is the right architecture. Sigfox is not recommended for new water meter deployments in 2026.
Is Sigfox dead in 2026?
Not dead, but in managed decline for new projects. UnaBiz operates the network and has existing customers under multi-year contracts. The protocol constraints — 12-byte uplink, 4-byte downlink, 140 messages/day — are hard limits baked into the UNB radio standard, not network policy choices. For any IoT application that needs configurable payloads, firmware updates, or reliable downlinks, Sigfox cannot compete with LoRaWAN or NB-IoT. For the narrow use case of periodic one-byte status reports from a device that never needs reconfiguring, it still works. For everything else, design with LoRaWAN or NB-IoT from the start.
How does LoRaWAN Class A battery life compare to NB-IoT PSM?
Both deliver 10+ years on two AA Li-SOCl2 cells at realistic IoT message rates, but the mechanisms differ. LoRaWAN Class A turns the radio completely off between uplinks — simple, predictable, and independent of network configuration. NB-IoT PSM keeps the device logically registered with the carrier but in deep sleep until a configured timer expires; it then wakes, sends data, and re-enters PSM. The critical difference is payload: NB-IoT PSM can send 1 600 bytes in one wake cycle; LoRaWAN SF12 is capped at 51 bytes. If your device needs to transmit more than 51 bytes occasionally, NB-IoT PSM is more efficient. If your payload is always small and you want zero carrier dependency, LoRaWAN Class A is the simpler and often cheaper choice.
Can LoRaWAN and NB-IoT devices coexist in the same IoT platform?
Yes. Most enterprise IoT platforms — AWS IoT Core, Azure IoT Hub, Actility ThingPark, The Things Industries — ingest data from both LoRaWAN gateways and NB-IoT carrier connections via standard MQTT or HTTPS APIs. The radio protocol is abstracted by the time data reaches the application layer. A smart-city deployment might run LoRaWAN for on-street parking sensors and environmental sensors (private gateways, low per-device cost) while using NB-IoT for mobile assets and out-of-coverage areas (carrier SIMs, roaming). Both streams are normalised into the same device management and analytics layer.
What is the LoRaWAN spreading factor and why does it affect payload size?
LoRaWAN uses Chirp Spread Spectrum (CSS) modulation with Spreading Factors from SF7 (fastest, shortest range) to SF12 (slowest, longest range). Higher SF means more processing gain but longer time-on-air. In EU868, regulatory duty-cycle limits (1%/hour per sub-band) mean a single SF12 transmission occupies ~1.5 seconds of airtime — consuming most of the hourly allowance. The 3GPP payload relationship is the reverse of what engineers expect: higher SF means **shorter maximum payload** in LoRaWAN (51 bytes at SF12 vs 242 bytes at SF7) because the LoRaWAN MAC enforces a fixed maximum time-on-air per frame. Design your payload for the worst-case SF (SF11-SF12) to ensure reliable delivery at edge-of-coverage.
How does CertifBus help with LoRaWAN exam preparation?
CertifBus EN provides structured LoRaWAN exam preparation covering device classes (A/B/C), network architecture (End-Device, Gateway, Network Server, Application Server), activation modes (OTAA vs ABP), ADR (Adaptive Data Rate), regional plans (EU868, US915, AU915, AS923), security (LoRaWAN 1.0.4 vs 1.1, NwkSKey/AppSKey separation) and smart-building use cases. The mock exam reproduces the MCQ format of LoRa Alliance ATC (Authorized Testing Centre) style assessments. The free LoRaWAN Airtime Calculator lets you verify payload and SF choices against EU868 duty-cycle constraints before sitting an exam — or before specifying a deployment.

Go deeper

Practice now

See how exam-ready you really are

10 real certification questions, no account needed. Find your gaps in under 5 minutes — free.

Independent editorial comparison. Protocol names cited are trademarks of their respective owners; CertifBus is not affiliated with any of them.

Last updated: June 2026

Put this knowledge into practice
Catalogue