Which IoT network is best for local government?

We are often asked this question. In truth you’re probably already using several: WiFi and Bluetooth sensors somewhere in your buildings, a different system for people stuck in lifts to raise the alarm, another network for managing your lighting, and something else again in adult social care for monitoring when vulnerable residents have fallen.

So the question isn’t really “which is best” – it’s “which ones do we need for what, and who’s going to run them?”. There’s an important third question too – “…and how do we make best use of the data?” which I’ll address in a separate post. For now, let’s look at the first two.

Two decisions

When councils ask us about IoT networks, they usually start with the technology: LoRaWAN vs NB-IoT vs WiFi vs whatever else. But there are actually two decisions wrapped up together here:

Decision 1 (technical): Does this technology actually work for what we’re trying to do? Range, power, data requirements, and – critically – can we actually buy the sensors we need?

Decision 2 (strategic): Who runs and maintains this network? The council, a specialist network provider like Netmore, or the mobile phone companies?

Get the first wrong and your sensors don’t work. Get the second wrong and you’re locked in or overpaying for many years.

The 4 main IoT network technologies (and what they’re good for)

LoRaWAN

Long range: the advertising says 10km but realistically 1-2km range in a built up area. Extremely low power (some sensors can run for 5-10 years on a battery), very low data rate.

Best for: wide-area sensor networks like smart litter bins, car park space occupancy, air quality monitoring, flood sensors, road temperature, etc. Also used extensively in buildings on retrofit projects (energy performance monitoring, damp/mould warning, office space utilisation) because of low cost and ease of installation.

Don’t use for: anything sending video, images; or anything sending data continuously; or anything needing an immediate response (for example to control the exit gate on a car park).

Who controls the network coverage: You do.

Sensor availability: Excellent – mature ecosystem, hundreds of sensor types available.

Bluetooth (BLE)

Short range (10-50m), low power, operates either as paired devices or as a mesh network of sensors and BLE enabled devices.

Best for: Indoor or dense urban environments – desk occupancy in buildings, asset tracking in a depot, environment monitoring, several social care/healthcare examples.

Don’t use for: anything requiring longer range.

Who controls the network coverage: You do – sensors may be paired with a BLE enabled device (typically a mobile phone), or part of a mesh network.

Sensor availability: Very good – lots of proven people-counting and beacon solutions.

WiFi

Short range (50m-100m), higher power consumption, high data rate.

Best for: Buildings and yards, where wifi coverage and power are readily available and you need higher bandwidth – some CCTV applications, building management systems, several social care/healthcare examples.

Don’t use for: anything requiring longer range, or powered by battery unless it is short term

Who controls the network coverage: You do – by installing Wifi access points

Sensor availability: Excellent – it’s established infrastructure technology.

Cellular (NB-IoT / LTE-M / 5G)

UK-wide coverage wherever mobile signal exists, medium-to-low power depending on the flavour, variable data rates.

Best for: Projects needing coverage immediately, high value/scale use cases, or where you don’t want to manage infrastructure yourself.

Who controls the network coverage: Mobile operators.

Sensor availability: Improving, but check your specific sensors exist before committing.

Important note on sensor availability: Choosing a network without proven sensors for your use case means expensive custom development or project failure. Always check the sensors exist first.

Who should run your network?

Once you know which technology fits, you need to decide who’s actually running it.

Option A: You run it yourself (DIY)

Technologies: LoRaWAN, WiFi, Bluetooth

You buy the gateways, you manage it, you control everything.

Pros: No monthly fees per sensor, full control, your data stays on your servers.

Cons: Upfront capital expenditure, you need internal skills or a support contract.

Best for: Councils with IT capacity, regard the IoT network as a strategic investment, data sovereignty requirements.

Option B: A specialist provider runs it

Technologies: LoRaWAN (companies like Netmore, North, Comms365)

They deploy and manage the network, you pay per sensor per month.

Pros: No infrastructure to buy, faster deployment, it’s a managed service.

Cons: Monthly fees add up, less control, provider dependency.

Best for: Councils who want LoRaWAN benefits but do not have internal capacity / desire to manage infrastructure. Do have good contract managers.

Option C: Mobile operators run it

Technologies: NB-IoT, LTE-M, 5G

You buy sensors with SIM cards, operators provide coverage where it exists.

Pros: Zero infrastructure, uses existing mobile coverage.

Cons: Monthly SIM fees forever, coverage gaps, especially in rural areas, no control when networks get upgraded or switched off.

Best for: Projects where mobile coverage already works, mostly outdoor use cases, or where assets may move nationwide. Mobile phone operators primarily set up for high volume use cases.

The trade-off: Control, limited use cases (but improving), and long-term cost savings vs. simplicity and speed of deployment.

Example use cases

Building energy performance monitoring (250 buildings, retrofit project)

This is a hot topic – councils need to reduce their energy bills and their carbon footprint, grants to improve building performance are available, but you need objective data to measure the improvement.

Technical choice: LoRaWAN or NB-IoT / LTE-M. Both work well for retrofit because there’s no wiring needed, so installation is very quick, and the battery-powered sensors run for years, so very little maintenance required.

Strategic choice:

  • LoRaWAN DIY if you’re also deploying sensors across the borough for parking, air quality, or other use cases – you can share the gateway infrastructure costs.
  • NB-IoT/LTE-M if this is your only IoT project or you need coverage immediately.

Note on network coverage: indoor coverage is harder to achieve than outdoor coverage. If you deploy your own LoRaWAN network then you can add coverage where needed. You do not have this option with NB-IoT/ LTE-M, although Vodafone, O2, EE etc do generally provide good coverage in densely populated areas.

Availability: It’s a big enough market that there are several solution providers for either network technology. Temperature, humidity, CO₂, occupancy sensors are widely available and proven.

Visitor counting at a tourist attraction (a castle or lido)

Technical choice: WiFi or LoRaWAN – visitor counting needs a sensor to be permanently on, because you never know when a visitor will arrive or leave. So for reliability, the sensor would be plugged into a power supply, making WiFi a realistic prospect if you can get wifi network coverage at every entrance/exit.

Strategic choice:

  • WiFi is familiar technology and a good cost-effective choice.
  • LoRaWAN if you are already running other LoRaWAN sensors, and want to use the same infrastructure and dashboard platform.

Availability: Excellent – several solution providers exist on either technology.

Smart bins (3,000 bins across the borough)

Technical choice: LoRaWAN – wide coverage needed, long battery life, outdoor.

Strategic choice: LoRaWAN DIY if you have IT capacity and a long-term view. Managed provider if you don’t have capacity/desire run your own network – but keep an eye on the subscription fees.

Availability: Good – mature air quality sensor ecosystem for LoRaWAN.

Want to talk about your specific project?

We’ve helped many councils across the UK work out which combination of technologies and providers makes sense for their projects.

Book a call: hello@thingitude.com

Related guides: