Path-Based Routing: RREQ and RREP

MeshCore path-based routing is a fundamental architectural departure from the flooding model used by Meshtastic and many other low-power mesh networks. Understanding the mechanics of route discovery through the Route Request (RREQ) and Route Reply (RREP) messages is essential for diagnosing connectivity issues, planning repeater deployments, and understanding network behaviour under load.

Flooding vs. Path-Based Routing: The Fundamental Contrast

Flooding (Meshtastic Model)

In a pure flooding model, every node that receives a packet retransmits it. The packet propagates outward through the network like ripples from a stone dropped in water. Every node within radio range of any retransmitter eventually receives a copy. The destination receives the message after some number of hops; all intermediate nodes receive and retransmit it whether or not they are on the optimal path.

The broadcast amplification factor for flooding is approximately N transmissions per message in an N-node network before duplicate suppression. In dense networks this creates a broadcast storm: airtime is consumed by redundant retransmissions on overlapping frequencies, dramatically reducing effective throughput. Meshtastic mitigates this with duplicate packet filtering by hash, a hop limit field, and role-based forwarding, but the fundamental characteristic remains that every message propagates to the entire reachable mesh regardless of destination.

Path-Based Routing (MeshCore Model)

MeshCore discovers a specific path between source and destination before transmitting data, then sends data only along that path. The control overhead of RREQ and RREP is incurred once per route discovery; all subsequent messages to the same destination travel only the path nodes. Nodes not on the path do not retransmit data frames at all. This is conceptually similar to AODV (Ad hoc On-Demand Distance Vector) routing in 802.11 wireless mesh networks, adapted for LoRa constraints: low data rate, half-duplex operation, and high collision sensitivity.

Route Request (RREQ)

A Route Request is broadcast when a source node wants to reach a destination for which it has no route cache entry. The RREQ frame contains:

Source address: 4-byte identifier of the originating node
Destination address: 4-byte identifier of the target node
Sequence number: monotonically increasing counter used to detect and discard duplicate RREQs at any forwarding node
Hop count: incremented by each intermediate node to limit RREQ propagation range
Path accumulator: each forwarding node appends its own 4-byte address, building a record of the path from source to current forwarder

The RREQ is broadcast by the source; intermediate repeaters receive it, check their duplicate-suppression cache for this sequence number (discarding if already seen), increment the hop count, append their address to the path accumulator, and rebroadcast. This controlled flood continues until the RREQ reaches the destination or the hop limit is exhausted. Only repeaters forward RREQs; client nodes in default configuration do not.

Route Reply (RREP)

When the destination node receives a RREQ, it generates a Route Reply sent unicast back to the source along the reverse of the path accumulated in the RREQ. This is the key efficiency distinction: the RREQ floods outward, but the RREP travels only the discovered path.

The RREP frame contains the original source address, the responding node address, the full ordered path sequence, and the route lifetime. Each intermediate node on the return path receives the RREP, installs the route entry in its local route table, and forwards the RREP to the next hop toward the source. By the time the RREP reaches the original source, every node along the path has a route entry for this source-destination pair, enabling them to forward subsequent data frames without broadcasting.

Route Table Maintenance

Every MeshCore repeater maintains a route table mapping destination addresses to next-hop addresses and full path records. Entries include: destination address, next hop address, full path, sequence number of the most recent RREQ or RREP that established this route, timestamp of last use, and route metric (currently hop count; RSSI-weighted metrics are possible in future versions).

Route tables are stored in RAM and are lost on reboot. After a repeater restarts, active node communication repopulates the route table through normal RREQ/RREP traffic. The main impact of a repeater restart is a brief period of elevated RREQ traffic as all routes through that repeater must be rediscovered.

Route Expiry and Rediscovery

Routes expire after a configured lifetime of inactivity. Expiry prevents the route table from growing unboundedly and ensures that routes to nodes that have moved or gone offline are eventually flushed. When a source node wants to send a message and the route has expired or was never established, it initiates a new RREQ cycle, typically buffering the outbound data frame for immediate transmission after the RREP is received and the route is installed.

What Happens When a Repeater on a Cached Route Goes Offline

When a repeater in the middle of an established route powers down, moves out of range, or fails:

Immediate delivery failure. The first data frame sent along the now-broken route will not be acknowledged. The sending node waits for an ACK timeout.
RERR generation. The node adjacent to the failure (whose next-hop is now unreachable) generates a Route Error (RERR) message identifying the failed link and sends it upstream toward the original source.
Route invalidation. Nodes that receive the RERR remove the affected route from their tables.
RREQ retrigger. If the source still has data to send, it immediately initiates a new RREQ for the destination. If an alternate path exists through a different repeater, the RREQ succeeds and routes around the failure.
Recovery time. Approximately: ACK timeout plus RERR propagation time plus new RREQ/RREP round-trip time. With typical LoRa parameters this is on the order of 10 to 60 seconds depending on hop count and airtime per packet.

If no alternate path exists, the RREQ will time out without a RREP. The source retries a configured number of times, then reports the destination as unreachable. The destination remains unreachable until the repeater comes back online or a new repeater providing an alternate path joins the mesh. This underlines the importance of path diversity: critical links should have at least two independent repeater paths, and repeater placement should treat route redundancy as a first-class requirement.