How does a LoRa mesh network work, and how is it different from LoRaWAN?

A LoRa mesh network passes each message from radio to radio until it reaches its destination, while LoRaWAN sends every message in a single hop to a gateway, and that one difference changes range, power use, cost and reliability.

The short answer: hop by hop instead of straight to a gateway

A LoRa mesh network works by letting ordinary nodes relay each other's packets, so a message can travel several short radio hops to reach a node or gateway that is out of direct range. LoRaWAN, the most common way LoRa radios are networked, does not do this. It is a single-hop star-of-stars design: every end device must be within radio range of a gateway, and the gateway forwards traffic over an internet backhaul to a network server.

Both use the same LoRa radio layer. The difference is entirely in who is allowed to forward traffic, and that choice decides how far a network can reach, what it costs to build, and how much battery each node burns.

Why LoRaWAN's single hop runs out of road

In LoRaWAN, a device far from a gateway has two options: more gateways, or slower, more robust transmissions. Gateways need power and backhaul, which can be scarce on farms and other remote sites, and the Purdue team behind one hybrid mesh design notes they normally cost from hundreds to thousands of dollars. Reaching long distances in one hop means high spreading factors and transmit power. That keeps each packet on the air far longer, lowers the data rate and raises the energy spent per useful bit.

Shared airtime is the other limit. LoRaWAN devices transmit in an uncoordinated, ALOHA-like way, so as more devices join, more packets collide. Duty-cycle rules in many regions also cap how often each device may transmit.

How a flooding mesh like Meshtastic routes messages

Meshtastic, a popular open-source LoRa mesh firmware, uses managed flooding for broadcasts. Every packet carries a hop limit, and each node that relays it decrements that count; a node that receives a packet with a hop limit of zero does not repeat it. To avoid every node shouting at once, a node waits before rebroadcasting, and the wait depends on how strong the received signal was. Distant nodes, which heard a weaker signal, get a shorter window and go first, while nearby nodes that then hear the rebroadcast stay quiet. This pushes the message outward with fewer redundant transmissions.

Hearing a neighbor rebroadcast your packet also serves as an implicit acknowledgment for broadcasts. Since firmware version 2.6, direct messages are smarter: the first attempt floods, the sender learns which relay carried the reply, and later packets are handled only by that next-hop node, falling back to flooding if the relay goes quiet. Nodes set to router roles always rebroadcast, which makes them useful as fixed repeaters on hills or rooftops.

Mesh that stays compatible with LoRaWAN

Another approach keeps LoRaWAN intact and adds relays in front of it. The LIMA protocol, described by researchers from goTenna and collaborators, places self-organizing routers between end devices and a gateway. A router that hears a device wraps its LoRaWAN frame, forwards it hop by hop to a mesh-aware gateway, and the gateway unwraps it for an unmodified network server. Devices need no changes. In simulation, the authors report more than five times the packet delivery of standard LoRaWAN at 100 devices and four to six times lower device energy, and a single router nearly doubled range in outdoor tests in Brooklyn.

A Purdue design took a scheduled route instead: a hub computes a collision-free time-slot plan for the LoRa backbone so nodes can sleep between slots. A five-node, four-hop chain on a farm covered about 3 km at the fast SF7 setting with over 98 percent delivery, and on a campus most nodes beat 96 percent, against 51.5 percent for an SF12 single-hop reference node at the same spot.

What is hard about LoRa mesh

Relaying is not free. Every extra hop adds latency and another chance for packets to collide, and simple flooding sends the same packet many times, eating into a shared channel with very little capacity. Relay nodes must also listen, and receiving costs energy, so the busiest relays drain fastest. Time-synchronized designs suffer when clocks drift, and LIMA's own results show packet loss rising at higher traffic as collisions and duty-cycle limits bite.

The practical rule that emerges from these designs is that several short, fast hops can beat one long, slow hop on energy and reliability, as long as traffic stays light and the relays are well placed. For sparse sensors, off-grid messaging and sites without backhaul, that trade is often worth making.