Why we chose LoRaWAN for terrain that has no signal
Transmission corridors run exactly where cellular coverage does not. That single constraint decided most of our architecture.
Most IoT architecture decisions are trade-offs between things you would like. Ours started with something closer to a wall.
Transmission corridors are routed for electrical and land-access reasons, not for connectivity. They cross ridgelines, gorges and forest where there is no mains supply at the tower, no cellular coverage worth depending on, and no realistic prospect of either arriving. Whatever we deployed had to work there, unattended, through a Dinaric winter.
That constraint eliminated most of the option space before we got to preferences.
What the constraint rules out
Cellular (LTE-M / NB-IoT). Excellent where there is coverage. The coverage is the problem — and there is a second-order issue that matters more than it first appears: cellular networks degrade during exactly the events you most want visibility into. Storms, fires and wide-area power disruption take out base stations. A monitoring system that goes quiet during a crisis is worse than no monitoring, because it trains people to expect data that will not arrive.
Wi-Fi or short-range mesh. Range is wrong by orders of magnitude for assets spaced hundreds of metres to kilometres apart.
Satellite uplink per node. Technically viable, but the power and cost budget per node does not survive contact with a network of thousands of towers.
What LoRaWAN buys
LoRaWAN is a deliberately unambitious radio, and that is the point. Chirp spread spectrum modulation trades data rate for link budget, which yields kilometre-scale range at milliwatt transmit power.
For our payload that trade is nearly free. We are not streaming video. We are sending small, structured telemetry — inclination, vibration signatures, EMF, temperature, humidity, pressure — at an interval measured in minutes. A few dozen bytes, periodically, is a workload LoRaWAN is almost purpose-built for.
The consequences compound:
- Battery life measured in years, not months, so maintenance does not reintroduce the site-visit cost we set out to remove.
- Independent infrastructure. A private gateway is ours to place and ours to keep running. No dependency on a mobile operator’s coverage decisions or their outage.
- Graceful density. Adding nodes along a corridor does not require adding backhaul at each one.
Where it is genuinely awkward
It would be dishonest to present this as free.
Duty cycle limits in the EU ISM bands cap how often a node may transmit. That is a real design constraint, and it means the system is built around periodic reporting plus event-triggered messages, not continuous high-rate streaming. If your application needs sub-second telemetry, LoRaWAN is the wrong answer and you should use something else.
Payload sizes are small, so anything expensive to express has to be computed at the edge and sent as a result rather than as raw data. Uplinks are unacknowledged by default, which means the platform has to treat missing readings as normal rather than as an error — an assumption that has to be designed in from the start, not patched on.
And LoRaWAN gives you the link, not the answer. A radio that reaches a mountain ridge tells you nothing about whether a tilt reading of 0.4° matters. That is what the per-asset baselining and anomaly detection are for, and that is where most of the actual difficulty lives.
The part that generalises
The reason this decision transferred cleanly to port infrastructure is that the underlying constraint transferred: assets that are expensive to reach, in environments hostile to conventional connectivity, where the value of the data is in its continuity rather than its resolution.
Pick the radio that survives the environment, then do the hard work in software. It is a less exciting architecture than the alternatives. It is also the one still reporting in February.