MeshCore vs Meshtastic Routing: A Technical Comparison
MeshCore vs Meshtastic Routing: A Technical Comparison
MeshCore and Meshtastic are both LoRa-based mesh networking systems but make fundamentally different architectural choices for packet routing. This page provides a detailed side-by-side comparison across twelve dimensions for networking engineers and protocol designers evaluating which system fits a given deployment scenario.
Routing Architecture Summary
Meshtastic: Controlled Flooding
Meshtastic uses a controlled flood as its primary propagation mechanism. Every node that receives a packet evaluates whether to retransmit, governed by a hop limit field (default 3 decremented by each forwarder and dropped at zero), a recently-seen packet hash cache for duplicate suppression, and role-based forwarding (CLIENT nodes do not forward by default; ROUTER and REPEATER role nodes forward aggressively). There is no route discovery phase and no route state. A sender does not know the path a packet will take.
MeshCore: On-Demand Path Discovery (RREQ/RREP)
MeshCore uses an on-demand path-vector protocol. Before data is sent, a Route Request flood discovers a path to the destination. The destination replies with a Route Reply unicasted back along the discovered path. Subsequent data flows only along the discovered path. Route state is distributed across repeaters and maintained until routes expire or Route Errors invalidate them.
Detailed Comparison Table
| Dimension | Meshtastic (Flooding) | MeshCore (Path-Based) |
|---|---|---|
| Routing mechanism | Controlled flood with hop limit and duplicate suppression | On-demand RREQ/RREP path discovery; unicast data delivery |
| Control plane overhead | Minimal: no routing state; overhead is data retransmissions | RREQ/RREP per new destination; RERR on link failure; advertisement floods for peer discovery |
| Data plane overhead | High: each message transmitted O(N) times in N-node network | Low: data transmitted once per hop on the discovered path only |
| Broadcast amplification factor | Up to (hop_limit)^2 in worst case; typically 6 to 12x for hop_limit=3 in dense networks | 1x per hop on path; RREQ floods once per route discovery and is amortised over all data messages using that route |
| Store-and-forward semantics | Nodes with STORE_AND_FORWARD role buffer messages for offline recipients up to a configurable TTL; limited by device RAM | Not implemented in the routing layer; undelivered messages are dropped after retry limit |
| ACK handling | Implicit ACK via overhearing own retransmission from a neighbour; optional application-layer ACK; Meshtastic 2.x adds hop-by-hop ACKs via managed flood | Explicit per-hop ACK on unicast data frames; source-level delivery confirmation after end-to-end ACK chain completes |
| Network diameter | Hard-limited by hop_limit field (default 3, max 7); messages cannot span more than 7 hops regardless of topology | Limited by route table size and RREQ hop limit; practically supports 10 or more hops with appropriate configuration |
| Performance in dense networks (>50 nodes) | Degrades significantly: broadcast storm, high collision rate, effective throughput decreases rapidly with density | Scales better: airtime per message is bounded by path length not network size; route table growth is the primary constraint |
| Performance in sparse networks (<10 nodes) | Excellent: overhead minimal, no route discovery latency, simplicity is an advantage | Adequate: RREQ overhead noticeable for first messages but amortises quickly; marginal overhead versus flooding in small networks |
| Convergence after topology change | Fast: flooding adapts immediately; a packet will take any available path in the current topology without reconfiguration | Slower: stale cached routes must expire or RERR must propagate before new paths are used; recovery is 10 to 60 seconds per link failure |
| Routing state required at nodes | None: stateless forwarding; any node can enter the network and immediately forward packets correctly | Route table per repeater; newly joined repeaters have no routes until RREQ/RREP traffic populates them |
| Suitability for mobile nodes | Good: flooding handles mobility naturally with no stale route problem | Moderate: mobile nodes cause frequent route invalidations and RREQ floods; performance degrades when many nodes are simultaneously mobile |
Broadcast Amplification Factor: A Quantitative Example
In a fully-connected 30-node network where every node is within range of every other, a Meshtastic message with hop_limit=3 results in approximately 3 times 30 equals 90 total transmissions before all propagating copies exhaust their hop limits. The single transmission that reaches every node directly would suffice, but flooding retransmits the message 89 additional times.
In contrast, MeshCore path-based routing for the same 30-node network requires: one RREQ flood (approximately 30 transmissions), one RREP unicast (1 to 7 transmissions depending on path length), then each subsequent data message consumes only 1 transmission per hop. For a 2-hop path that is 2 transmissions per message indefinitely, with the RREQ and RREP cost amortised across the entire conversation.
Scalability Threshold: When to Choose Which
- 1 to 15 nodes, stable topology: Meshtastic simplicity is a clear advantage. No routing infrastructure to maintain, instant connectivity, large device and app ecosystem.
- 15 to 50 nodes: Either protocol functions. MeshCore provides better throughput efficiency but Meshtastic larger ecosystem may offset this for general-purpose deployments.
- 50 or more nodes, or high message volume: MeshCore path-based routing provides significantly better network utilisation. The broadcast storm problem becomes acute in dense Meshtastic networks at this scale.
- High-mobility scenarios: Meshtastic stateless flooding handles mobility better. MeshCore route cache invalidation overhead increases with node mobility rate, generating additional RREQ flood traffic during topology changes.
No comments to display
No comments to display