ComparisonIoT & Smart Cities
LoRaWAN vs NB-IoT vs LTE-M: choosing connectivity for city sensors
LoRaWAN suits sensors a city wants to own the network for, sending small readings on unlicensed spectrum through gateways it controls. NB-IoT and LTE-M suit devices that need operator coverage, deep indoor reach or mobility, paid for by subscription. Wi-SUN mesh fits mains-powered assets such as streetlights and meters. Most cities end up mixing them, chosen per device class, under one data platform.
On this page
- LoRaWAN, NB-IoT, LTE-M and Wi-SUN on the criteria cities argue about
- Classify devices by what they send, how often and from where
- Downlink, ownership and lifecycle: where LPWAN decisions are made
- Matching each class of city device to a network
- Hypothetical: a mid-size city connects parking, waste and air quality
- Questions and answers
- Sources
LoRaWAN, NB-IoT, LTE-M and Wi-SUN on the criteria cities argue about
| Criterion | LoRaWAN | NB-IoT | LTE-M | Wi-SUN mesh |
|---|---|---|---|---|
| Spectrum and standard | Unlicensed bands; LoRa Alliance specification1 | Licensed cellular; 3GPP standard2 | Licensed cellular; 3GPP standard2 | Unlicensed; IEEE 802.15.4-based mesh4 |
| Who runs the network | The city, a community or an operator1 | A mobile operator | A mobile operator | Usually the asset owner or utility |
| Downlink and firmware updates | Limited; plan updates carefully | Possible but slow | Better suited to regular updates | Good two-way control |
| Moving assets | Weak | Weak; designed for static devices | Supports handover between cells | Not designed for it |
| Basements, pits and metal enclosures | Depends on gateway density you build | Strong where the operator has deployed coverage extensions | Good, slightly less than NB-IoT | Depends on mesh density |
| Battery-powered devices | Very well suited | Very well suited with power-saving modes | Suited; more power when active | Usually mains-powered nodes |
| Cost structure | Capital for gateways, then operations | Per-device subscription | Per-device subscription | Capital for the mesh, then operations |
| Lifecycle risk | Network server and gateway vendor choice | Operator support horizon | Operator support horizon | Vendor certification and ecosystem |
Qualitative comparison only. Range and battery life depend on terrain, building materials, payload and reporting interval, so test with your own devices on your own streets.
Classify devices by what they send, how often and from where
Connectivity choices go wrong when they start from a technology preference. Start instead with a device register: for each sensor type, write down the payload, how often it reports, whether it needs commands back, whether it moves, whether it has mains power and where it physically sits.
A typical city register falls into a few classes. Parking bay and water meter sensors are battery-powered, report small events and often sit underground or in pits. Waste bin fill-level sensors report a few times a day from inside metal containers. Air-quality stations send more data, more often, and usually have mains or solar power. Streetlight controllers are mains-powered and need reliable commands for dimming and switching. Buses, bikes and maintenance vehicles move. Each class points to a different answer.
Downlink, ownership and lifecycle: where LPWAN decisions are made
Downlink. If a device must receive commands, configuration or firmware regularly, LoRaWAN's limited downlink becomes the constraint, and LTE-M or a mesh is usually the better fit. Plan firmware updates for any LPWAN device as a scheduled, staged operation, not an afterthought.
Ownership. LoRaWAN lets a city own gateways and run its own network server, including open-source options such as ChirpStack5, or buy service from a community or commercial network. That removes subscriptions but adds site leases, power, backhaul and on-call maintenance. NB-IoT and LTE-M move that work to an operator, in exchange for recurring fees and dependence on the operator's coverage map and roadmap.
Lifecycle. Street assets often stay in place longer than a radio technology's commercial life. Operators decide when to retire a network generation, so ask each one for its stated support horizon for NB-IoT and LTE-M in writing, and prefer modules that support both. For LoRaWAN, the question is whether you can move devices to another network server without re-provisioning them in the field. Newer options, such as 5G reduced-capability devices standardized from 3GPP Release 173, may matter for higher-bandwidth sensors later; they are not a reason to delay a battery sensor rollout today.
Matching each class of city device to a network
- If
Battery sensors report small, infrequent readings from fixed locations across a district.
ThenUse LoRaWAN, on a city-owned or community network where coverage can be planned around the sensors.
No per-device subscription, and gateways can be placed where sensors actually are.
- If
Sensors sit deep underground or inside buildings the city cannot install gateways near.
ThenTest NB-IoT from an operator with confirmed coverage at those addresses.
Operator coverage extensions can reach places a new gateway network would struggle to.
- If
Devices move, or need regular firmware and configuration updates.
ThenUse LTE-M, or dual-mode LTE-M and NB-IoT modules.
LTE-M supports handover and carries more data when updates are needed.
- If
Assets are mains-powered and need dependable two-way control, such as streetlights or meters.
ThenConsider a Wi-SUN mesh, or the lighting controller's own standards-based network.
Mains power removes the battery constraint and mesh routing gives command reliability.
- If
Devices send video, large files or high-rate data.
ThenUse fiber, Wi-Fi or full cellular instead of any LPWAN.
LPWANs are built for small payloads; forcing larger data through them fails.
Hypothetical: a mid-size city connects parking, waste and air quality
Questions and answers
Can a city run its own LoRaWAN network?
Yes. LoRaWAN can run as a private, public or community network, and a city can own the gateways and operate the network server itself or through a contractor. Budget for site agreements, power, backhaul, monitoring and security patching, and make sure devices can be exported to another network server if you change operator.
Should we wait for 5G RedCap instead of deploying NB-IoT or LTE-M?
Usually not for battery sensors. Reduced-capability 5G targets devices such as wearables and industrial sensors that need more bandwidth than LPWAN provides. Small, infrequent city readings are well served by LoRaWAN, NB-IoT or LTE-M today. Revisit RedCap when a device class genuinely needs higher data rates and operators in your area support it.
How long will NB-IoT and LTE-M networks be supported?
It depends on the operator and the country, so ask each operator for its stated support horizon in writing before buying devices. Prefer dual-mode modules that can fall back between LTE-M and NB-IoT, and keep device provisioning and data models independent of the network so a forced migration does not touch the platform.
Can one city sensor use more than one network?
Yes. Some modules combine LoRaWAN with cellular, and many cellular modules support both LTE-M and NB-IoT. Multi-radio devices cost more and use more power, so reserve them for assets where a connectivity failure is expensive, such as safety-related monitoring, rather than fitting them everywhere.
Sources
- About LoRaWAN — LoRa Alliance · checked 10 October 2026
- Standardization of NB-IoT completed — 3GPP · checked 10 October 2026
- RedCap — 3GPP · checked 10 October 2026
- Wi-SUN Alliance — Wi-SUN Alliance · checked 10 October 2026
- ChirpStack open-source LoRaWAN Network Server — ChirpStack · checked 10 October 2026