MeshCore Network Topology Best Practices

MeshCore Network Topology Best Practices

Backbone vs. Client Layer

A well-designed MeshCore network is organized into two distinct layers:

• Backbone layer: dedicated repeaters placed on elevated sites with clear line-of-sight between them. These form the routing backbone that carries traffic across the network. They are the infrastructure - always on, high antenna, fixed location.
• Client layer: user devices (phones, handhelds, base stations) that connect to the nearest backbone node. ClientsIn MeshCore, companion (client) nodes are endpoints, not relays - theyper the MeshCore FAQ, clients do not forwardrepeat traffic for other nodes.

This two-layer separation meanskeeps backbonethe trafficforwarding isload predictableon the backbone. Clients add no forwarding load, but they still transmit their own messages, advertisements, and high-performance.path-discovery Addingfloods moreon clientthe nodesshared channel, all of which consume airtime. So adding clients does not degradeadd backbonerelay performance,load becauseto clientsthe contributebackbone, nobut forwardinga load.very dense client population can still congest the shared channel and indirectly affect performance.

Repeater Placement Guidelines

The numbers below are rules of thumb for planning, not protocol limits - tune them to your terrain and traffic.

• Aim for 3 - 5 repeaters per coverage zone, each with line-of-sight to at least 2 others in the backbone.
• Avoid single points of failure - if one repeater goes offline, the network should remain functional via alternate paths.
• Ensure overlapping coverage between adjacent repeaters so that clients are never more than 1 hop from the backbone.
• High sites (hilltops, building rooftops, water towers) dramatically extend backbone range - prioritize elevation over raw transmit power.

Hop Budget

MeshCore supports up to 64 hops.hops In(the practice,protocol planceiling). As a planning rule of thumb, aim for no message traversing more than 6 - 8 backbone hops. Beyond this:

• Per-hop latency accumulates noticeably.
• Each additional hop adds another potential failure point.
• Route re-discovery after a link failure takes longer with more hops in the chain.

For wide-area networks that would otherwise require long hop chains, use room servers as message hubs rather than relying on extended peer-to-peer relay chains.

Advertisement Tuning

• Flood advertisements (visible network-wide) should be infrequent - every 12 hours is appropriate for stable infrastructure nodes. Frequent floods waste airtime and provide no benefit when the topology is static.
• Zero-hop advertisements (local only, for client discovery) can be more frequent - every few minutes is reasonable.
• Review your advertisement intervals if you observe unexplained airtime congestion on the channel.

Mesh Segmentation for Large Networks

In a very large network (50+ repeaters), avoid trying to relay everything peer-to-peer across the entire mesh. Instead:

• Use room servers as message hubs for cross-region delivery. Room servers provide message storage and delivery confirmation.
• Segment the mesh into regional clusters, each with its own backbone, connected via room servers at the regional boundaries.
• This reduces the hop count needed for cross-region delivery and localizes the impact of any regional topology change.

Monitoring Topology Health

The MeshCore app includes a network map feature that shows which repeaters a node can see and the routes between them. Use this to:

• Verify backbone connections are healthy after deployment.
• Identify repeaters that have lost contact with their neighbors (indicates a failure or coverage gap).
• Confirm that new repeaters have been discovered and integrated into the routing fabric.
• Check hop counts for key routes and identify bottleneck nodes carrying disproportionate traffic.