LoRaWAN for water utilities: where it fits alongside SCADA

What LoRaWAN is

LoRa is a radio modulation technique that trades data rate for range and sensitivity. LoRaWAN is the open network protocol, maintained by the LoRa Alliance, that sits on top of it and defines how devices, gateways and servers talk to each other. It runs in licence-exempt spectrum: the 902–928 MHz band in North America and the 868 MHz band in Europe. It is designed for short, infrequent messages from devices that must last years on a battery.

That design explains both its strengths and its limits. Messages are small, reporting is occasional, and the network shares licence-exempt spectrum with other users. For a utility with assets spread across large territories, which describes much of Canada, that is often exactly the right trade.

How the pieces fit together

A LoRaWAN deployment has four building blocks:

• End devices: meters, pressure loggers, level sensors and other battery-powered instruments with a LoRa radio.
• Gateways: radios that receive device transmissions and forward them over an IP connection (Ethernet, fibre or cellular). Devices are not paired with one gateway; any gateway in range can pick up a message.
• Network server: removes duplicate copies of a message received by several gateways, checks authenticity, manages data rates and schedules any messages sent back to devices.
• Application server: decrypts and decodes the payload into engineering values and passes them on to the systems that use them.

Device classes

LoRaWAN defines three device classes, which differ in when a device can receive messages. The choice is mostly a trade between power and responsiveness.

Range, battery life and data rate

LoRa uses spreading factors, from SF7 to SF12. A higher spreading factor reaches further and tolerates weaker signals, but it sends data more slowly, keeps the radio on longer, uses more battery and occupies more of the shared channel. The network server can adjust each device's data rate according to link quality, which is why a device near a gateway should use far less energy than one at the edge of coverage.

Real range depends on antenna height, terrain, building density and obstructions. Some meters sit in below-grade pits with concrete lids, which can be far harder to reach by radio than a pole-mounted sensor. Payloads are small: roughly a dozen bytes at the slowest data rates, up to a couple of hundred at the fastest. Regulations also limit how long and how often devices may transmit, so reporting intervals must be planned for the whole fleet, not one device.

Multi-year battery life is realistic with infrequent reporting, but it depends on the reporting interval, spreading factor, battery chemistry and temperature. Cold reduces usable capacity in many battery types, so for devices that must run through Canadian winters, ask the manufacturer for performance data at low temperature and keep antennas clear of snow cover where possible.

Where LoRaWAN fits

• Smart metering: regular consumption readings, with night-flow analysis to help find leakage.
• Pressure monitoring: readings at several points in a network, with exception-based alerts.
• Tank and reservoir level: ultrasonic or radar sensors at elevated tanks, cisterns and other storage where running cable is not practical.
• Remote stations: status, intrusion, flood and power-fail alarms from small lift stations, valve chambers and wellheads.
• Environmental and agricultural sensing: soil moisture, canal levels and weather data across large areas.
• Equipment condition: periodic vibration and temperature summaries from smaller pumps.

Small municipalities, rural water co-operatives and industrial sites spread across large areas often benefit most. A few gateways on existing towers or buildings can digitize assets that would be expensive to reach with trenched cable or licensed radio.

When not to use LoRaWAN

LoRaWAN is not a control network. Standard uplinks are not guaranteed to arrive, latency is measured in seconds, downlink capacity is limited, and the spectrum is shared. That rules out:

• closed-loop control, such as level-based pump starts that must act reliably;
• safety interlocks and emergency shutdowns;
• high-rate data such as vibration waveforms, audio or images;
• anything where a missing message creates unacceptable risk.

Those functions belong to a PLC or RTU with a deterministic link to SCADA. Confirmed uplinks improve reliability but cost battery life and network capacity, so they are a tool for selected messages, not a way to make LoRaWAN behave like a control bus. A sound rule: if an operator would be uncomfortable losing one message, do not rely on LoRaWAN for it alone.

Security

LoRaWAN uses AES-128 cryptography with unique keys for each device. Network session keys protect message integrity and authenticity, and a separate application session key encrypts the payload itself. Frame counters help prevent replay of captured messages. Good practice builds on that foundation:

• Prefer over-the-air activation (OTAA), which generates fresh session keys when a device joins, over activation by personalization (ABP), which uses fixed keys.
• Protect root keys during provisioning, and never reuse them across devices.
• Carry gateway backhaul over a VPN or TLS, and secure the network and application servers like any other critical system.
• Use authenticated, encrypted links (for example MQTT over TLS) when forwarding data to other systems.
• Plan device lifecycle: key rotation, replacement and decommissioning.

A utility can also choose a private network, with its own gateways and servers, rather than a shared public one. That gives more control over coverage, security and data location, including the option to host the servers in Canada if policy requires it, at the cost of more to operate.

Integrating with SCADA and historians

The usual pattern is for the application server to publish decoded values by MQTT or HTTP to an integration layer. That layer either writes into a historian or time-series database, or exposes values to SCADA as OPC UA or Modbus tags through a gateway. Three details deserve attention:

• Timestamps: record the time the measurement was taken, not only the time the message arrived.
• Stale data: LoRaWAN values update every few minutes or hours, not every second. SCADA screens should show the last update time and mark old values as stale, so operators do not mistake an old reading for a live one.
• Alarm ownership: decide whether alarms are generated in the LoRaWAN platform or in SCADA, and avoid doing both.

This is why we describe LoRaWAN as complementary. It extends what SCADA can see by bringing more digitized assets into view, without asking SCADA to change how it controls.

A short planning checklist

• Run a coverage survey and test the hardest locations first, such as pits and basements.
• Site gateways with reliable power and backhaul, and overlap coverage for redundancy.
• Set reporting intervals for the whole fleet, and write payload decoders early.
• Define how devices are provisioned, monitored, updated and retired.
• Test the full path to SCADA or the historian, including stale-data behaviour, before scaling.