Choosing the network for an IoT monitoring site: LoRaWAN, NB-IoT, LTE-M, Wi-Fi or Ethernet

01

Start from the site, not from the technology

Before comparing radios, describe the place. An indoor production hall has metal racks, concrete and machines that already sit on a wired network. An open yard or car park is wide, mostly line of sight and often has no power outlets where sensors are needed. A remote mast or pumping point may be kilometres from the nearest building and depend entirely on a battery or a small solar panel. One company often has all three, and forcing a single network on all of them is the most common source of cost and frustration.

Walk the site with a floor plan and mark each measurement point with three facts: what is measured, where power is available and what infrastructure is already there. That map is the input for every decision that follows, and it becomes part of the site survey we hand over.

02

Payload size and reporting interval decide more than range

A temperature sensor that reports a few bytes every ten minutes and a vibration sensor that streams a spectrum several times per second are different problems. Low-power wide-area networks such as LoRaWAN are built for small, infrequent messages and impose duty-cycle limits on how often a node may transmit. NB-IoT and LTE-M carry more data per message and allow more frequent traffic, at the cost of higher power draw and a mobile subscription. Wi-Fi and Ethernet carry almost anything, provided the building already has them.

Write the expected message size and interval for each sensor group, then add the worst case: what happens during an incident, when you may want readings every few seconds instead of every few minutes. A network that cannot handle the incident case will fail exactly when the data matters most. Where high-rate signals are needed, process them at the edge and send summaries, features or events instead of raw samples.

03

Range, building penetration and coverage

LoRaWAN uses unlicensed sub-gigahertz spectrum and can reach several kilometres in open terrain, much less through walls and basements. Its big advantage is that you own the gateway: coverage is something you build, test and extend yourself. NB-IoT and LTE-M ride on mobile operators’ networks, so coverage depends on the operator in that area. NB-IoT tends to reach deeper indoors and into basements; LTE-M offers lower latency, higher throughput and support for devices that move between cells.

Do a short coverage survey before ordering hardware. For LoRaWAN, place a temporary gateway and measure signal quality at every marked point. For cellular options, test with SIMs from the operators you would actually contract, at the real mounting height. Record the results in the site survey so later changes can be compared against a baseline.

04

Power budget and maintenance visits

Battery life is the hidden cost of an IoT system. Every unplanned visit to swap a battery costs more than the battery. Transmission power, interval, retries and the time the radio stays awake all count. LoRaWAN class A devices sleep most of the time and can run for years on a battery when the interval is reasonable. NB-IoT and LTE-M use power-saving modes that bring them close, but frequent reconnections in poor coverage drain cells quickly. Wi-Fi is usually a poor match for battery nodes.

We calculate a power budget for each node type, covering mains, battery and solar options, including winter conditions for solar. The budget sets the reporting interval, not the other way round. If the business needs more frequent readings than the budget allows, the answer is a different power source, not a hope that the battery will last.

05

Equipment already on the floor

Many sites already have meters, PLCs and controllers that expose data over RS-485/Modbus or OPC UA. Replacing them with new wireless sensors is rarely sensible. A gateway reads these interfaces locally and forwards the values together with the wireless readings, under the same device identity and security rules. The OPC Foundation describes OPC UA as a platform-independent, secure way to exchange information between industrial systems, which makes it a good bridge between the shop floor and the monitoring platform.

List existing interfaces in the same site map. They often decide where gateways go, because a gateway near the control cabinet can serve both the wired equipment and the wireless nodes around it.

06

A comparison table you can copy

Use the table below as a starting point and adjust it after the coverage survey. It is a summary of typical behaviour, not a guarantee for a specific site.

07

Mix networks behind one gateway and one platform

The right answer for a real company is usually a mix: wired links in the hall, LoRaWAN across the yard and a cellular link for the remote point. What keeps this manageable is that all of them end in the same MQTT ingestion, the same time-series store and the same rules. A reading looks the same on the dashboard whether it arrived over LoRaWAN or Ethernet, and the same threshold can open a maintenance order in the RDCopilot ERP or notify the technician in the mobile app.

This is how we deliver IoT monitoring as a standard service: a site survey with the floor plan, coverage measurements, power budgets and the network comparison; the platform with dashboards, alerts and exports; and connections to ERP, reports and the mobile app. A one-off implementation fee covers architecture, installation support and configuration, and a monthly subscription covers EU hosting, updates, monitoring and support.

• Site map with measurement points, power and existing interfaces
• Message size, interval and incident-mode rate for each sensor group
• Coverage survey with the real gateway position and operator SIMs
• Power budget per node type, including winter for solar nodes
• Network comparison recorded in the site survey