LoRaWAN vs LoRa Mesh for Structural Monitoring: A Topology Decision Guide

LoRaWAN and LoRa mesh are two ways of approaching how a wireless monitoring sensor can communicate their data to the final destination of a data receptor. Both approaches share the same radio chip but impose different rules on every sensor in the network. The choice between them comes down to three site-specific variables: how far each sensor sits from a viable gateway position, how many years it must run unattended, and what it costs to send a crew when something needs replacing.

Three site variables decide the topology

An engineer specifying wireless sensors for a bridge or tunnel does not start with protocol specs. The starting point is the physical constraint set. A tilt sensor bolted under a cable-stayed bridge deck, 40 meters above water, demands a different connectivity strategy than one embedded in a tunnel lining with vehicle access every 500 meters.

Gateway placement drives most of the decision. If a gateway can be installed with line-of-sight, or near it, to every sensor, a single-hop architecture works. If the structure blocks that path, hops are required.

How LoRaWAN keeps sensors simple

LoRaWAN uses a star-of-stars architecture: each sensor transmits directly to one or more gateways in a single hop. The gateway forwards raw packets to a network server, which handles deduplication, scheduling, and application routing.

The sensor itself knows nothing about the network. It measures, transmits, and sleeps. What that means in practice is that a sensor with no networking logic has fewer failure modes and a power draw that can be modeled before it leaves the lab.

That predictability creates very good battery gains. LoRaWAN sensors on a typical SHM duty cycle, periodic tilt or crack-width readings every 15 to 60 minutes, achieve multi-year battery life on a single cell. The power budget for LoRaWAN becomes deterministic and is easily a calculation of sleep current plus a fixed number of transmission windows per day. Exact duration depends on payload size and transmission interval, but in general this type of transmission allows to plan ahead in a fairly secure manner.

LoRa operates at sub-GHz frequencies: 868 MHz in Europe, 915 MHz in the US. On a bridge, one consequence is that a single gateway often covers the full span, including sensors on piers and abutments. A 200-meter bridge can sit under one 868 MHz gateway where a 2.4 GHz network would need repeaters every 30 to 50 meters. Documented LoRaWAN transmission distances in infrastructure applications reach up to 15 km in favorable conditions.

LoRaWAN is an open standard maintained by the LoRa Alliance. Gateways from different manufacturers connect to the same network server. This is a point worth noting: a project commissioned today does not depend on a single vendor still existing in 2034.

Where LoRa mesh earns its complexity

LoRa mesh does something LoRaWAN cannot: it extends coverage through multi-hop relay. Devices forward traffic from neighbors toward a gateway or sink node, discovering routes automatically and rerouting around failed links.

The strongest case for mesh comes from underground environments, and it is backed by hard data. Research comparing LoRaWAN star topology with LoRa mesh for sub-surface nodes found an average five-fold higher packet loss rate for the star configuration. The study concluded that LoRa mesh outperforms standard LoRaWAN techniques on packet delivery reliability when transmitting from range-critical locations. When a sensor sits behind meters of rock or reinforced concrete with no line-of-sight to any gateway, relay is the crucial part of getting the packet to its destination.

Meshtastic, the most widely deployed LoRa mesh protocol, gives a useful reference point. It is open source, operates on 868/915 MHz bands, and supports up to roughly 80 nodes per network. It works well for communication relaying but is not optimized for the low-power, high-reliability telemetry cycles that SHM demands.

A 2024 study on synchronous LoRa sensor nodes for footbridge vibration monitoring showed that cost-effective modal identification is achievable with LoRa, though the study used carefully synchronized nodes rather than a general-purpose mesh protocol. The takeaway is that LoRa hardware is capable; the protocol layer determines whether it suits a given monitoring use case.

Power, reliability, and standardization tradeoffs

Relay nodes must keep their radios active to listen for packets to forward. This breaks the deep sleep cycling that gives LoRaWAN its multi-year battery life. The power a relay node draws depends on traffic volume, which depends on topology, which can shift as the network self-organizes. The result is that battery life projections for relay nodes require traffic assumptions that are hard to validate before deployment.

Packet delivery also compounds across hops. If each link delivers 90% of packets, a three-hop path delivers about 73%. A four-hop path drops to 66%. In dense meshes, a relay node forwarding for three neighbors multiplies its active radio time by four, and every additional node increases the collision probability across the shared channel. Mesh networks need careful traffic engineering, especially when sensor counts grow.

Standardization is the other cost. Meshtastic, Digi Mesh, and various proprietary implementations each define their own routing, firmware, and management tooling. Switching between them means replacing firmware and potentially hardware. For a monitoring contract spanning a decade, that is a form of lock-in that LoRaWAN's open standard avoids.

Matching topology to structure type

Bridges are linear and largely open. Sensors distribute along the span, on piers, and at abutments with minimal RF obstruction. One or two LoRaWAN gateways cover the deployment. For very long viaducts, a second gateway midway is preferable to introducing mesh complexity.

Buildings and facades present a vertical surface. Sub-GHz signals handle floor-to-floor transitions well enough that rooftop or ground-level gateways reach sensors distributed across a facade. LoRaWAN fits here.

Tunnels change the picture considerably. A tunnel acts as a waveguide for short distances, but signal attenuation over the full length of a road or rail tunnel can be severe. A LoRa star topology can work inside tunnel environments, but only with carefully placed gateways. Segmented LoRaWAN with gateway repeaters along the tunnel preserves sensor-side battery advantages while solving the coverage gap. Adoption remains limited, though: only 23% of tunnel monitoring technology users surveyed reported using LoRa-based systems.

Underground structures (metro tunnels, mines, multi-level parking) present the hardest case. They involve complex geometry, heavy concrete between levels, and limited gateway power and backhaul options. The five-fold packet loss data for sub-surface LoRaWAN nodes makes the case clearly: these environments need relay. Mesh is the right topology here, and its power costs are justified by the alternative, which is no data at all.

Maintenance over a decade

Topology choice shows up not in procurement but in the operational budget, year after year. And the differences add up.

A 10-year bridge monitoring contract with LoRaWAN sensors lasting five years per battery means one scheduled replacement per sensor. If mesh relay nodes last two to three years under variable traffic load, that becomes three to four replacements. Each replacement requires a crew, access equipment, and potentially lane closures or rail possessions. On a bridge pier 30 meters above water, the battery costs less than getting someone to it.

Battery-free LoRaWAN sensors, where applicable, eliminate this line item entirely. Energy harvesting is not yet viable for every sensor type or mounting location, but for nodes in the most access-constrained positions, it changes the maintenance math fundamentally.

Here is the key difference: with LoRaWAN, replacement cycles can be planned during contract negotiation because the power budget is deterministic. With mesh, the estimate rests on topology assumptions that may not hold once the network is live.

Where neither topology wins cleanly

Rail tunnels exceeding several kilometers may need more LoRaWAN gateways than is practical to install and power. A hybrid approach, LoRaWAN sensors where gateway coverage exists and mesh relay segments where it does not, is technically viable but adds system complexity. In practice that means two protocol stacks, two firmware variants, two sets of operational assumptions.

MyMove handles part of this by normalizing data from different LoRaWAN network servers into a single monitoring view. At the radio layer, however, a hybrid deployment is still two systems, and the integration work becomes necessary.

Deep underground environments push harder still. Gateway power and backhaul connectivity may be as difficult to provision as sensor power. Mesh's ability to self-organize without fixed infrastructure is a genuine advantage in these conditions, and the power cost is justified by the alternative.

There is no universally correct topology for these cases. The right approach depends on how many gateways can realistically be deployed, what backhaul exists, and whether relay nodes sit in locations where battery replacement is feasible.

The input that makes both protocols legible

For most surface infrastructure, bridges, buildings, retaining walls, LoRaWAN's predictable power and open standardization fit the monitoring mission. For enclosed and obstructed environments where gateway placement alone cannot solve coverage, mesh has a real and growing role.

The gap between these two worlds is narrowing. The reality today is that engineers building monitoring systems are choosing between two very interesting systems that work best when their advantages are used.

‍