Wireless Protocol for IoT: BLE, Wi-Fi, Zigbee, LoRa, NB-IoT

Every connected product has to answer the same question early: which wireless protocol for IoT should it use? It looks like a part-number decision. It is closer to an architecture decision, because it shapes board size, battery, antenna and enclosure, firmware, cloud design, certification and the running cost of every unit you ship.

There is no best protocol, only the one that fits your constraints. This guide goes through the main options for a product designed in Norway: what each one is for, where it fails, and the Norwegian and EU facts that change the answer.

Start with five questions, not a protocol

Where does the data go? To a phone nearby, to a router in the building, or straight to the cloud from a field with no infrastructure.
How is it powered? Mains, a rechargeable battery, or a battery that must last as long as the product does. This single answer removes many of the options.
How much data, and how often? A reading every hour, a firmware update, a live stream and a voice call are different problems.
Does it move? A fixed sensor and an asset that travels across cell boundaries need different radios.
Who runs the network? You, the customer, a phone, or an operator you pay per device. Every choice has a different cost and failure mode.

Bluetooth Low Energy (BLE)

Good for: wearables, battery sensors, accessories and any product where the phone is the screen and the gateway.

BLE runs in the 2.4 GHz band on 40 channels. The Bluetooth SIG lists four PHY options: 2 Mb/s, 1 Mb/s, and the coded PHY at 500 kb/s and 125 kb/s, which trades speed for range. Newer versions add mesh networking and channel sounding for centimetre-level distance measurement. The big advantage is the installed base: phones already carry the radio, so your product needs no infrastructure at the customer.

The trade-offs:

Short range. Real range depends on antenna, enclosure, body and the PHY you choose. Test it in the final housing and ignore the best datasheet number.
Modest data rate. Good for readings, settings and updates. Not for continuous high-rate streams.
No direct internet. Without a phone or gateway nearby, the data stays on the device.

BLE is also how Matter devices are set up, whatever network they then run on. Our own Tally Keys concept, a small keypad that logs one thing per day, pairs a Bluetooth Low Energy keypad with a local-first phone app.

Wi-Fi

Good for: mains-powered products near a router: cameras, displays, appliances, hubs, anything that moves a lot of data or needs easy cloud access and firmware updates.

The device joins the customer's existing network, so there is no extra hardware to buy. Wi-Fi 6 added Target Wake Time, which the Wi-Fi Alliance says improves network efficiency and device battery life, and Wi-Fi 6E extends Wi-Fi 6 to the 6 GHz band alongside 2.4 and 5 GHz. A Wi-Fi radio is still among the more power-hungry options, so battery products need a very low duty cycle, and you need to measure real consumption on your hardware rather than rely on a datasheet.

Needs the customer's network. Setup (credentials, captive networks, guest networks) is the part users struggle with, so design the onboarding with the app.
Not for places without coverage. Fields, forests and many industrial sites have no Wi-Fi.

Zigbee, Thread and Matter

Good for: smart-home and building products with many small nodes, where a mesh extends range.

Zigbee and Thread both use the IEEE 802.15.4 radio, in practice in the 2.4 GHz band. The difference is the network stack above it. Zigbee is a mature standard from the Connectivity Standards Alliance. Thread is an IPv6-based mesh network with no single point of failure that can self-heal. Matter is an application layer on top: the Connectivity Standards Alliance says it uses Bluetooth LE for setup and Wi-Fi, Thread and Ethernet for connecting devices. So Matter does not mean Thread; a Matter device can be a Wi-Fi device.

A border router or hub is needed to connect a Thread or Zigbee network to the internet. Check which controllers your target customers already own.
2.4 GHz is crowded. BLE, Wi-Fi, Thread and Zigbee all share it. Coexistence needs testing early, not on the last week.

LoRa and LoRaWAN

Good for: battery sensors that send small messages from places with no other network: agriculture, environmental monitoring, utility metering, asset tracking at a site.

LoRaWAN is a low-power wide-area specification for connecting battery-operated devices to the internet in regional, national or global networks. Devices talk to gateways in a star-of-stars layout, in unlicensed ISM bands, with end-to-end security built in. The LoRa Alliance cites range of up to 15 km in rural areas. Sub-GHz signals also tend to get through walls and vegetation better than 2.4 GHz.

What to plan for:

Small, infrequent messages. It is a protocol for "report in now and then", not for streaming or interaction.
Transmission-time limits in Norway. The Norwegian regulation on general frequency permits (fribruksforskriften) limits both power and airtime in the 863 to 870 MHz range. For example, 25 mW e.r.p. and 1% transmission time in 868.0 to 868.6 MHz, 0.1% in 868.7 to 869.2 MHz, and 500 mW and 10% in 869.4 to 869.65 MHz. Your message rate has to fit inside these limits.
Who provides the gateways. The Things Network has 16 communities in Norway, and its gateways are community-run. For a product that customers depend on, plan for your own gateway or a contracted network, and verify coverage at the real sites.
Firmware updates are slow. LoRaWAN supports multicast for firmware-over-the-air updates, but with small messages and airtime limits, an update takes far longer than on BLE or Wi-Fi. Design the updatable part to be small, or plan a site visit.

Airtime limits and battery life are decided together in firmware: sleep modes, duty cycles and radio timing. See our firmware service.

Cellular IoT: NB-IoT and LTE-M

Good for: remote or mobile products that need to reach the cloud directly, with no gateway and no customer network.

Both run inside the operators' 4G and 5G networks. They differ in speed and mobility. NB-IoT peak rates are about 26 kb/s down and 66 kb/s up in its first release (Cat-NB1) and about 127 and 159 kb/s in the second (Cat-NB2). It is aimed at fixed devices, because handover between cells is not its strength. LTE-M is faster, supports seamless handover and also supports voice, which makes it the one for devices that move. Both offer power saving modes, and the right one for your product depends on how often it must report.

What matters in Norway

2G is going away. Telenor says it will close 2G on 31 December 2027, postponed from 2025, and Telia began its own shutdown in August 2025 according to Telecom Review Europe. Ask both operators for the dates that apply to your SIMs. A new product should not depend on 2G. Telenor describes 4G/5G-based IoT, meaning NB-IoT and LTE-M, as its route to full national IoT coverage, including Svalbard.
Coverage is the operator's claim. Telenor says it runs NB-IoT and LTE-M on the 800 MHz band, with 900 MHz in places. Check coverage at your real sites and roaming terms for products that leave Norway.
Recurring cost per device. Every unit needs a SIM or eSIM and a subscription. Ask operators for IoT pricing at your volume, because it enters your business case for the product's whole life.
Module and antenna. Cellular modules cost more than BLE or Wi-Fi modules, and need a proper antenna design and often more board space and power budget. Get a quote for the module you intend to use rather than relying on a general range.

What decides cost and schedule later

Antenna and enclosure

Every radio needs an antenna, and the antenna needs space, ground and clearance from metal and batteries. Module vendors specify this. Espressif, for example, recommends at least 15 mm of clearance around its on-board PCB antenna. A metal enclosure blocks RF, so you need a plastic window or an external antenna. These choices reach the mechanical design early. We cover the board-level side in our guide to PCB design mistakes.

Certification and RED

A radio product sold in the EU is assessed under the Radio Equipment Directive, and Norway applies it through the EEA. Since 1 August 2025, RED also sets cybersecurity requirements (Article 3(3)(d), (e) and (f)): protecting the network, protecting personal data and privacy, and protecting against fraud in payments. They apply to internet-connected radio equipment, and the privacy requirement also covers toys, childcare equipment and wearables. The harmonised standards are EN 18031-1, -2 and -3. According to Nkom, applying them without restrictions allows internal production control; where restrictions apply, a notified body is needed. Nkom also notes that RED's cybersecurity requirements are to cease applying from 11 December 2027, when the Cyber Resilience Act takes over. The CRA's duty to report actively exploited vulnerabilities has applied since 11 September 2026. Check the EEA status of the CRA before you rely on these dates in Norway.

We give no cost ranges here because the price depends on your product, your module and your test lab. Ask your module vendor which certificates it already covers, and get a lab quote before you commit to a protocol. Our guide to taking a product to market covers where certification fits in the schedule.

Updates

Plan how fixes will reach devices in the field before you pick the radio. The update path is limited by data rate, airtime limits and power: easy on Wi-Fi, slower on BLE through a phone, and slowest on LoRaWAN. A bootloader and over-the-air update path belongs in the first design, not the second.

How to choose a wireless protocol for IoT: a decision framework

Battery, near a phone → BLE.
Mains power, near a router, much data → Wi-Fi.
Many small nodes in a home or building → Thread or Zigbee, usually with Matter. Decide by the controllers your customers own.
Fixed, battery-powered, small messages, no other network → LoRaWAN if you can run the gateways and stay inside the airtime limits; NB-IoT if you want the operator to run the network.
Moves, no local infrastructure → LTE-M.
Two radios → common and often right: BLE for setup plus Wi-Fi or cellular for the cloud. It adds board area, certification scope and coexistence work, so make it a decision, not a default.

How we work on this in projects

We choose the radio with the power budget, the antenna position and the enclosure in front of us, because they decide each other. We choose between Bluetooth LE, LoRa, Wi-Fi and cellular links during scoping, and design the app and back end they talk to together with the device. ARCIVE is an example: we built the firmware for a wireless capture device with a far-field microphone array, together with the apps and the back end it feeds. We start from the constraints above, build a first radio test on the bench with real hardware, and measure range and current draw in the real enclosure before anything is locked.

Frequently asked questions

Which wireless protocol is best for low-power IoT devices?

There is no single answer. BLE for phone-connected devices, LoRaWAN or NB-IoT for small, infrequent messages from fixed devices, and Thread or Zigbee for mesh networks in buildings. What decides it is how often the device must talk, to whom, and from where.

BLE or Wi-Fi: which should my product use?

BLE if the phone is the interface and the device runs on a battery. Wi-Fi if the device is mains-powered, near a router, and moves a lot of data or needs easy cloud access.

Is Thread better than Zigbee?

They share the same 802.15.4 radio, but Thread is IP-based and is one of the networks Matter runs over. Zigbee has an established base of devices. Matter does not interoperate natively with Zigbee, only through a bridge, so choose by the ecosystem you are targeting.

Is Zigbee dead?

We do not have market-share data to answer that. What we can say: Zigbee and Matter are separate protocols, Matter can bridge Zigbee devices, and existing Zigbee devices keep working. New products should decide from the controllers customers have.

What is the difference between NB-IoT and LTE-M?

LTE-M is faster, supports handover while moving and supports voice. NB-IoT has much lower data rates and suits fixed devices that send little data. Both use the operator's network and need a SIM.

What is the difference between NB-IoT and LoRaWAN?

NB-IoT runs on an operator's cellular network and needs a SIM, so the operator runs the network. LoRaWAN uses unlicensed bands and gateways that you or a community run, and has to stay within local airtime limits.

What is LoRaWAN and how does it work?

A low-power, wide-area network specification. End devices send small messages by radio to gateways, which pass them to a network server over the internet. It runs in unlicensed bands, so you also need to follow the local airtime limits.

Choosing a radio for a product?

See how we work on electronics and PCB design and firmware, or book a short call and tell us how the product will be used. We will tell you which radio we would start with, and why.

Sources

Checked on 2 October 2026: