Infrastructure Nodes, Routing Priorities, and Best Practices in Meshtastic
Electronics MeshtasticPart I: Meshtastic Node Roles and Network Design: Building an Efficient LoRa Mesh
Part II: Infrastructure Nodes, Routing Priorities, and Best Practices in Meshtastic
Part III: Relay Policies, Power Management, and Practical Node Configuration in Meshtastic
Why Infrastructure Nodes Require Careful Planning
Infrastructure roles are often misunderstood by newcomers. Many users assume that placing a router on the highest available rooftop will automatically improve network coverage. In reality, infrastructure nodes influence retransmission timing across the entire mesh, and poor placement can reduce network performance instead of enhancing it.
Unlike ordinary client nodes, infrastructure devices participate in packet forwarding using elevated scheduling priorities. Because LoRa operates on a shared medium with relatively low bandwidth, every unnecessary transmission consumes valuable airtime that could otherwise be used for new traffic.
For this reason, infrastructure nodes should be deployed only when they solve a clearly defined network problem.
ROUTER
The ROUTER role is intended for backbone infrastructure.
Whenever a packet is received, a ROUTER schedules its retransmission before ordinary client devices have an opportunity to forward the same packet. This early retransmission suppresses duplicate forwarding by surrounding nodes, reducing overall traffic while extending coverage.
When positioned correctly, a ROUTER becomes the preferred forwarding point for a large section of the mesh.
Typical deployment locations include:
- mountain ridges connecting isolated valleys
- tall communication towers
- hilltops overlooking multiple settlements
- buildings that provide line-of-sight to several independent clusters
The key objective is not simply achieving long range but connecting separate parts of the network that would otherwise remain isolated.
A well-positioned ROUTER effectively becomes the backbone of the mesh.
ROUTER_LATE
ROUTER_LATE serves a very different purpose.
Instead of transmitting immediately, it deliberately waits until ordinary clients have completed their forwarding attempts. Only after higher-priority retransmissions have finished does it decide whether another copy of the packet is still worthwhile.
This delayed behavior allows ROUTER_LATE to provide additional coverage without aggressively suppressing normal client routing.
Its primary applications include:
- filling coverage gaps
- extending communication into valleys
- supporting isolated neighborhoods
- improving reliability at the edge of the mesh
Because retransmission occurs only after other nodes have had an opportunity to respond, ROUTER_LATE behaves much more like an ordinary client under normal operating conditions.
However, unlike a CLIENT, it attempts to forward nearly every packet it receives.
That distinction becomes important in busy networks.
Why REPEATER Should No Longer Be Used
Earlier firmware versions included the REPEATER role as a simple infrastructure node.
Its operation was intentionally straightforward. The device listened for packets, retransmitted everything once, and spent the remaining time in an aggressive power-saving mode. To simplify deployment, repeaters were hidden from the visible node database.
Although attractive in theory, this behavior proved problematic in real deployments.
Because repeaters retransmitted traffic indiscriminately and with very high priority, they frequently generated packet collisions and unnecessary duplicate traffic.
Modern Meshtastic releases have largely replaced this functionality with ROUTER and ROUTER_LATE, which provide significantly better control over retransmission scheduling.
Current deployments should avoid REPEATER entirely.
Understanding Retransmission Priority
One of the most important concepts in Meshtastic is retransmission scheduling.
When multiple nodes receive the same packet simultaneously, they do not immediately begin transmitting. Instead, each node waits for a short randomized interval known as the contention window.
During this waiting period, nodes monitor the channel.
If another device successfully forwards the packet first, many nodes suppress their own retransmission because forwarding would no longer provide additional value.
Different device roles enter this contention process with different priorities.
A simplified ordering looks like this:
- ROUTER
- CLIENT_BASE (favorite nodes)
- Standard CLIENT
- ROUTER_LATE
Because ROUTER enters the retransmission queue first, surrounding client nodes often cancel their own forwarding attempts after hearing the router’s transmission.
ROUTER_LATE performs the opposite function.
It intentionally waits until everyone else has finished before deciding whether another retransmission is still necessary.
This scheduling system significantly reduces duplicate traffic when infrastructure nodes are deployed correctly.
Why ROUTER Placement Matters
Many operators incorrectly install ROUTER nodes wherever high elevation is available.
Height alone is not enough.
A ROUTER should occupy a location that naturally bridges major sections of the network.
Imagine two towns separated by a mountain range.
Users inside each town communicate perfectly with one another, but no packets cross the mountains.
Installing a ROUTER on the ridgeline creates a bridge between both communities.
Now consider a different scenario.
Suppose a ROUTER is installed on a residential rooftop inside a neighborhood that already has dozens of interconnected nodes.
Because the ROUTER forwards packets before everyone else, nearby clients frequently suppress their own retransmissions.
Instead of improving coverage, the router may actually reduce routing diversity while contributing little additional range.
Infrastructure nodes should therefore solve connectivity problems rather than simply occupy elevated locations.
When ROUTER_LATE Makes Sense
ROUTER_LATE excels where standard routing struggles.
Examples include:
- neighborhoods hidden behind terrain
- valleys with poor line-of-sight
- industrial sites located beyond the primary mesh
- isolated buildings at the edge of coverage
In these situations, delayed retransmission increases the probability that weak signals eventually reach the destination.
However, this benefit comes with an important tradeoff.
Because ROUTER_LATE attempts to retransmit almost every packet it receives, total channel utilization increases.
In small networks this effect is often negligible.
In large urban deployments it can become significant.
Monitoring Channel Utilization
Every LoRa network has finite capacity.
Meshtastic exposes two useful metrics for evaluating network health.
Channel Utilization (ChUtil)
Channel Utilization measures how much total airtime is occupied by all transmissions on the configured frequency.
As utilization increases, available bandwidth decreases.
Higher utilization also raises the probability of packet collisions.
Air Utilization TX (AirUtilTX)
AirUtilTX measures how much airtime is consumed by the local node itself.
Unlike ChUtil, this metric reflects only the transmissions generated by a single device.
Monitoring both values provides valuable insight into whether a node contributes positively or negatively to overall network performance.
If channel utilization remains consistently high while a ROUTER_LATE node contributes a significant portion of transmissions, reconsidering its deployment may improve network reliability.
Choosing the Right Role for Common Deployments
Most Meshtastic users fall into one of several common scenarios.
Single Portable Device
If an existing community mesh already provides good coverage and you simply want to participate, CLIENT_MUTE is usually the best choice.
Your device remains fully connected while avoiding unnecessary retransmissions.
Home Station with an Outdoor Antenna
If you install an elevated antenna that significantly improves coverage, the standard CLIENT role is generally appropriate.
The node contributes to routing naturally without assuming infrastructure responsibilities.
Personal Two-Node Network
Many operators own both a portable radio and a permanently installed base station.
In this configuration:
- rooftop node: CLIENT_BASE
- handheld node: CLIENT_MUTE
After adding each node to the other’s Favorites list, the rooftop installation automatically prioritizes forwarding for the portable device while behaving normally for everyone else.
This configuration offers excellent coverage with minimal impact on unrelated traffic.
Community Infrastructure
Only after carefully analyzing network topology should ROUTER or ROUTER_LATE be introduced.
Infrastructure roles should solve measurable routing deficiencies rather than simply increase transmission activity.
General Recommendations
The Meshtastic documentation consistently recommends using CLIENT or CLIENT_MUTE unless there is a specific technical reason to select another role.
This advice reflects years of real-world deployments.
An efficient mesh is not created by maximizing retransmissions. It is created by ensuring that every retransmission contributes meaningful additional coverage.
Thoughtful node placement, restrained use of infrastructure roles, and careful observation of network behavior will almost always outperform aggressive routing configurations.
In large deployments, fewer well-positioned infrastructure nodes generally provide better results than many poorly located ones.