One meter, three radios: NB-IoT, BLE and LoRa

A radio is also a decision about who runs the network

NB-IoT removes the site gateway from the architecture because the mobile operator has already built the access network. That is useful for a sparse fleet spread across towns. It also means roaming, coverage extensions, paging behavior, SIM lifecycle, and feature support depend on the operator. The GSMA deployment guide devotes separate sections to PSM, eDRX, paging, coverage extension, power class, and firmware upgrade support for a reason: a standards-compliant radio still depends on network configuration.[1]

Bluetooth LE puts the collector close to the meter. That collector may be a phone during a technician visit, a mains-powered gateway in a building, or an embedded concentrator in another product. Bluetooth LE was designed so that the better-powered central device can carry more of the communication work.[3] This is excellent when a collector already exists. Building and maintaining a collector fleet solely to save money on meter radios is a different business case.

LoRaWAN uses a star-of-stars topology. Gateways relay packets between end devices and the network server, and more than one gateway may hear the same uplink.[6] A private campus can own this network. A utility can subscribe to a public one. The choice determines who handles gateway placement, backhaul, network-server upgrades, keys, and failed-site diagnosis.

Give all three radios the same job

Radio comparisons become fiction when one candidate sends a tiny daily counter and another maintains a live, remotely commanded session. Our worked example is a battery-powered gas meter. It records consumption every fifteen minutes, sends a 96-byte application report every hour, raises tamper and valve alarms without waiting for the next batch, and stores seven days locally. A remote valve command must carry an identifier, expiry time, acknowledgement, and observed valve state.

The example is deliberately awkward. Hourly reporting exposes cellular session overhead. An alarm path exposes the cost of sleeping. A command exposes downlink reachability. Seven-day storage separates radio failure from data loss. The same payload schema, security requirement, antenna volume, and battery derating apply to every candidate.

Report age matters more than packet arrival

The platform should preserve sample time, report time, and ingest time. A meter that reconnects after six hours has delivered new packets containing old measurements. Billing may accept that. Leak detection may require current data. The application must state which decisions use event time and which need current reachability.

Measure charge per useful report, including the failed ones

Peak current does not predict battery life. Neither does sleep current. The useful quantity is charge consumed across the complete state machine: wake, measure, attach or scan, transmit, receive, retry, store, and return to sleep. Multiply each state current by its duration, then add regulator loss, sensor load, battery self-discharge, temperature derating, and a field margin.

The table below is a transparent sensitivity model. It isolates radio charge so the architectural difference is visible; it does not predict service life. The assumed NB-IoT session draws 220 mA for eight seconds. The LoRaWAN Class A report uses a 45 mA, 0.4-second uplink plus two receive windows. The Bluetooth LE meter advertises for 6 ms every five seconds at 8 mA. Sleep current is 5 µA for the cellular case and 2 µA for the local radios. Replace every number with a current trace from the intended module, antenna, SIM, firmware, battery, and network.

The absurdly long nominal life produced by some radio-only calculations is the warning. It means the radio is no longer the limiting load, so battery shelf life, pulse capability, temperature, leakage, the metrology front end, and valve actuation take over. A ten-year label cannot be obtained by dividing amp-hours by an average current and stopping there.

NB-IoT offers a large link budget. 3GPP material gives a 164 dB maximum coupling loss target for standalone NB-IoT and identifies PSM and extended idle-mode DRX as power-saving mechanisms.[2] Deep coverage often requires repetitions, longer active time, and higher energy. Test the tail of the distribution. The median meter is rarely the one that forces a battery truck roll.

Range claims collapse inside cupboards, pits, and basements

A link budget belongs to the installed antenna, enclosure, frequency, wall construction, mounting height, interference, and receiver. Bluetooth SIG notes that range is a tradeoff among transmit power, receiver sensitivity, antenna gain, and the propagation environment. Typical LE Coded implementations can achieve receiver sensitivity around -103 dBm, but Coded PHY reduces application data rate.[4] The Core specification also makes LE Coded optional, so a product cannot assume every phone or gateway supports it.[5]

LoRaWAN trades data rate for transmission duration. Adaptive Data Rate can tune data rate and power for stable devices, while regional parameters define the legal and interoperable channel plans.[6][7] A slow uplink may close a difficult link, but it occupies the channel longer and spends more energy. Confirmed uplinks add downlink load and can make a weak network weaker if used as a blanket reliability setting.

Downlink is where the product contract becomes visible. An NB-IoT device in PSM is unreachable until its next wake event; eDRX trades more listening for shorter paging delay. A LoRaWAN Class A device opens two receive windows after its own uplink. Class B adds scheduled receive slots. Class C keeps the receiver open and is generally a mains-powered choice. A sleeping Bluetooth LE peripheral depends on its advertising or connection schedule and on the collector being present.

Count the network people have to operate

Procurement usually compares module, antenna, certification, and subscription. Operations pays for the omissions: gateway surveys, SIM suspension, key recovery, failed backhaul, battery visits, replacement collectors, firmware campaigns, and support calls caused by an unclear failure boundary between the meter, local radio, gateway, carrier, and cloud path.

Security also has an operating cost. Bluetooth LE provides pairing, bonding, encryption, and attribute permissions, but the product team must select and implement the relevant security level. Bluetooth SIG recommends authenticated LE Security Mode 1 Level 4 where the threat model requires it.[9] LoRaWAN and cellular have different key and identity lifecycles. The cost model must include secure manufacturing injection, ownership transfer, revocation, and a field recovery route that does not become a universal backdoor.

Choose the failure mode you are equipped to manage

The winner changes with the organisation's network assets and tolerance for operational work. The strongest radio is the one whose dependency chain the operator can see, test, and repair.

Hybrids are legitimate. A meter can use Bluetooth LE for commissioning and NB-IoT for routine service. A LoRaWAN estate can retain local optical or BLE access for diagnostics. The extra radio earns its place only when it removes a specific field burden. Otherwise it adds certification, firmware, antenna, security, and support work for the life of the product.

Make the losing radio fail before procurement

A two-week radio trial can eliminate a bad architecture if it uses production enclosures, production batteries, real network accounts, and the worst installation positions. Bench range and average current are useful development measurements. They are weak procurement evidence.

Standards and original sources

The standards describe protocol capabilities and constraints. The charge figures are a worked sensitivity model for this article and must be replaced by measurements from the chosen hardware, firmware, battery, antenna, network, and installation.

1. [1]NB-IoT Deployment Guide to Basic Feature Set Requirements, Version 3 · GSMA
2. [2]3GPP Standards for the Internet of Things · 3GPP
3. [3]The Bluetooth Low Energy Primer · Bluetooth SIG
4. [4]Understanding Bluetooth Range · Bluetooth SIG
5. [5]Bluetooth Core Specification, Low Energy Physical Layer · Bluetooth SIG
6. [6]TS001-1.0.4 LoRaWAN L2 Specification · LoRa Alliance
7. [7]LoRaWAN Technical Specifications and Regional Parameters · LoRa Alliance
8. [8]TR007 Developing LoRaWAN Devices v1.0.0 · LoRa Alliance
9. [9]Bluetooth Security and Privacy Best Practices Guide · Bluetooth SIG