How System 5 Works

The Big Picture

Every routing protocol answers one question: when node A wants to send a message to node Z, which intermediate nodes should carry it?

Current Meshtastic uses managed flooding: every node rebroadcasts every message, hoping it reaches the destination. This works for small networks but creates a bandwidth explosion at scale — 100 nodes means ~100 transmissions per message.

System 5 takes a fundamentally different approach: nodes self-organize into geographic clusters, discover multi-hop routes, and send each message along a specific computed path. The cost per message is proportional to the number of hops, not the number of nodes.

The following sections explain every step in detail.

Step 1: Boot — What Happens When a Node Turns On

When a System 5 node powers up, it doesn't know anything about the network yet. Here's the exact sequence:

1. Hardware init: LoRa radio starts listening on the configured frequency (EU 868MHz). GPS module begins acquiring satellites (if available).
2. Position acquisition: The node tries three methods in order:
   • Real GPS — best option, accurate to ~5m (T-Beam, RAK4631 with GPS module)
   • RSSI triangulation — if no GPS but 3+ neighbors with known positions, estimate position from signal strength
   • Cluster inheritance — if neither works, adopt the cluster ID of the strongest neighbor
3. Geohash computation: GPS coordinates are converted to a geohash string (e.g., "u33d"). The first 4 characters define the node's cluster. Nodes with the same 4-char prefix are in the same cluster.
4. OGM broadcast: The node sends its first Originator Message (OGM) — a small packet announcing: "I exist, here's my position, battery level, and cluster ID."

Step 2: Neighbor Discovery via OGM

Each node periodically broadcasts an OGM (Originator Message) — a lightweight packet (~12 bytes) containing:

When a node receives an OGM, it:

1. Measures RSSI/SNR of the received signal → determines link quality to the sender
2. Adds/updates the sender in its neighbor table (max 16 neighbors per node)
3. Notes the cluster ID — if the sender is in a different cluster, this node might be a border node

Link Quality Is Asymmetric

A critical detail: the link from A→B can have different quality than B→A. A mountaintop node with clear line-of-sight might send to a valley node with quality 0.95, but the valley node (surrounded by buildings) can only reach back with quality 0.3. System 5 tracks both directions independently.

Step 3: Geo-Clustering — Self-Organizing Geography

After a few OGM rounds (~1-2 minutes), nodes have discovered their neighbors. Now the network self-organizes into geographic clusters.

How Clustering Works

There is no central coordinator. Each node independently:

1. Computes its geohash from its GPS position
2. Takes the first 4 characters as its cluster ID
3. Nodes with the same 4-char prefix are automatically in the same cluster

This is completely decentralized — no node needs to "know" the full network. If you turn on a new node in Munich, it computes its geohash ("u281"), and it's automatically part of the Munich cluster. It doesn't need permission or coordination.

Border Nodes — The Bridges Between Clusters

A border node is any node that has neighbors in a different cluster. Border nodes are critical — they're the bridges for inter-cluster routing.

System 5 limits bridge links to 2 per cluster pair to prevent route explosion. The two strongest links between each pair of adjacent clusters are selected.

Why This Scales

Each node only needs to know:

• Full topology within its own cluster (direct neighbor knowledge, ~20-50 nodes)
• Border nodes to adjacent clusters (2 per pair × ~8 neighbor clusters = 16 nodes)
• Cluster-level routes for distant clusters (abstract — "to reach cluster u33e, go through border node E")

A node in San Francisco doesn't need to know every individual node in Oakland. It just needs to know: "to reach Oakland, route through border node #47 on the Bay Bridge ridge."

Step 4: Route Computation — Distance-Vector with Multi-Path

Once clusters and border nodes are known, each node builds a routing table with up to 2 routes (primary + backup) to every reachable destination in its cluster view.

The Algorithm: Distance-Vector (not BFS)

Routes are not computed by running a graph algorithm on the node. Instead, they emerge incrementally from OGM data — similar to how RIP and B.A.T.M.A.N. build their routing tables:

1. When node A receives an OGM from neighbor B, it learns: "B can reach node Z in 3 hops with quality 0.8"
2. A updates its routing table: "I can reach Z via B in 4 hops, quality = 0.8 × q(A→B)"
3. If A later hears from neighbor C that C can reach Z in 2 hops with quality 0.9, it records a second (better) route
4. The routing table converges after a few OGM cycles — each node knows 1-2 next-hops per destination

Route Quality

Route quality is the estimated end-to-end delivery probability, computed incrementally as each hop's OGM propagates quality information:

This naturally penalizes long paths (more hops = more quality multiplications < 1.0) and paths with weak links.

Memory Budget

Even with 70 destinations (large cluster view), total memory is ~2 KB — well within nRF52's ~64 KB usable RAM.

Step 5: Sending a Message — Weighted Route Selection

When node A wants to send a message to node Z, this is the exact decision process:

Is this message's priority high enough for the current network health? (See Step 6)

Look up all cached routes to destination Z. Typically 2-5 routes.

Remove routes where any intermediate node has died (battery = 0) or any link is broken.

For each surviving route, compute a weight that balances three factors:

This is a critical design choice. System 5 does not always pick the best route. It selects routes probabilistically, proportional to their weight:

Example: If route 1 has weight 0.8 and route 2 has weight 0.4:

• Route 1 is selected ~67% of the time (0.8 / 1.2)
• Route 2 is selected ~33% of the time (0.4 / 1.2)

This keeps secondary routes "warm" — traffic occasionally flows through them, so the network knows they still work. If route 1 fails, route 2 is immediately available with recent quality data.

The message is sent along the selected path, one hop at a time:

1. A sends to B (first hop in the path)
2. If B receives it → B forwards to D (next hop)
3. If B doesn't receive it → A retries (up to 3 times for good links, 5 for poor links)
4. If all retries fail → try the next cached route (up to 5 route attempts)
5. If all routes fail → fall back to scoped cluster flooding

Backpressure — Automatic Congestion Avoidance

When an intermediate node's queue is filling up, System 5 applies gradual backpressure:

This prevents cascading overload: when a node starts getting congested, traffic naturally redistributes to other paths before the node drops packets.

Step 6: QoS — Priority Under Pressure

Not all messages are equal. System 5 uses a Network Health Score (NHS) per cluster to throttle low-priority traffic when the network is stressed.

NHS Calculation (Locally Computed)

NHS is a value from 0.0 to 1.0 representing the cluster's health as seen by this node. It requires no extra traffic — it's computed entirely from data already present in received OGMs:

• Average link quality to this node's direct neighbors (measured via RSSI/SNR)
• Number of neighbors responding vs. expected (based on previous OGM rounds)
• This node's own queue utilization

NHS is not a global cluster metric — each node computes its own local view. This avoids any extra polling or cross-node aggregation traffic.

Priority Gating

Priority 0 = SOS/Emergency — always gets through, regardless of network state. This ensures that in a disaster scenario, critical messages are never blocked by routine telemetry.

Step 7: Fallback — When All Routes Fail

If all 5 cached routes fail (after retries on each), System 5 doesn't give up. It falls back to scoped cluster flooding — a targeted mini-flood along the corridor between source and destination.

How Scoped Flooding Works

1. Find the cluster-level path: Follow the cluster adjacency table from source cluster to destination cluster (built from border-node OGM exchanges)
2. Define the corridor: Source cluster + destination cluster + all border nodes along the cluster path
3. Flood only within the corridor: Message is broadcast only to nodes in the corridor — not the entire network

This is dramatically cheaper than full-network flooding. In a 500-node network with 10 clusters, a full flood touches all 500 nodes. A scoped corridor flood touches ~100 nodes (2 full clusters + border nodes).

Broadcast Routing — Cluster-Distributor Model

The previous steps describe unicast routing (one sender, one receiver). But in Meshtastic, ~98% of traffic is broadcast — position beacons, node info, telemetry. This is where the biggest efficiency gains are.

The Problem with Broadcast Flooding

In managed flooding, a single broadcast message triggers O(n) transmissions — every node that receives it rebroadcasts to all neighbors. In a 200-node network, one position beacon generates hundreds of transmissions, saturating the channel.

Cluster-Distributor: Wave Propagation

System 5 replaces blind broadcast flooding with structured wave propagation through elected cluster distributors:

Each cluster elects one distributor node — a valley-level node with high local connectivity but low cross-cluster leakage. Selection criteria:

• Coverage: How many cluster members can it reach directly?
• Containment: What fraction of its neighbors are inside the cluster? (High = less wasted airtime)
• Tier preference: Valley nodes preferred over hill/mountain (they reach local nodes, not distant clusters)

When a node wants to broadcast, it sends the message via unicast to its cluster's distributor — 1-3 hops, ~1-3 TX. No flooding.

The distributor performs a mini-flood within its cluster only. Since clusters are small (20-30 nodes), this is cheap: ~20-30 TX to reach all cluster members.

Border nodes that receive the message relay it to the distributor of the adjacent cluster via unicast. The wave propagates cluster by cluster until all clusters are covered.

Results

Airtime Budget (EU868)

EU868 mandates a 1% duty cycle — each node can transmit at most 36ms per 3.6s, or ~360ms per 36s. Here's how the budget works for a 25-node cluster:

At the adaptive 60s OGM interval (typical for moderate density), a node uses ~0.8% of its 1% duty cycle for maintenance traffic — leaving headroom for actual data. With managed flooding, a single broadcast storm can consume the entire duty budget of every node in the cluster.

Step 8: Self-Maintenance — Keeping Routes Fresh

Networks change constantly: nodes move, batteries drain, links degrade. System 5 maintains itself through several mechanisms:

Route Quality Decay (Pheromone Model)

Inspired by ant colony optimization: at each OGM cycle (adaptive interval, see Step 2), all cached route qualities decay by 5%:

Routes that are actually used get their quality refreshed from real link measurements. Routes that are never used gradually fade to zero and are eventually replaced. This ensures the routing table always reflects current network conditions, not stale historical data.

Route Feedback

After each message delivery attempt:

• Success: Route quality boosted by 5% (capped at 1.0). Fail count reset to 0.
• Failure: Route quality halved. Fail count incremented. After 3 failures, route is excluded from selection until refreshed by the next OGM round.

Neighbor Eviction

When a node discovers a new neighbor but its table is full (16 entries), it evicts the neighbor with the lowest link quality. This ensures the routing table always contains the best available connections.

Dynamic Hop Limit

Unlike Meshtastic's fixed 3-7 hop limit, System 5 uses a dynamic limit that scales with network size:

For a 100-node network: max_hops = √100 × 3 = 30. For a 1000-node network: max_hops = 40 (capped). This allows messages to traverse large networks without artificial limits, while preventing infinite loops.

The Half-Duplex Problem (Bay Area Discovery)

This is the single most important real-world constraint that simulators typically ignore. LoRa radios are half-duplex: a node cannot transmit while it is receiving.

Why This Matters for Flooding

Consider a mountaintop router at 2000 ft elevation that can hear 100 nodes. When a message floods through the network:

1. Node A sends a message. The mountaintop hears it (now in RX state).
2. 10 rooftop nodes near A also hear it and rebroadcast simultaneously.
3. The mountaintop is still receiving those 10 rebroadcasts — it cannot transmit.
4. 4 long-range router nodes also rebroadcast. The mountaintop is still stuck in RX.
5. By the time the mountaintop can transmit, the managed flooding algorithm's suppression timer has expired — it either rebroadcasts (causing more collisions) or suppresses (message dies).

Result: 5% actual utilization becomes 50% channel utilization at the mountaintop, and messages fail to propagate beyond the first hop.

Why System 5 Survives Half-Duplex

With directed routing, the mountaintop node receives one targeted packet (not 14 simultaneous rebroadcasts). It processes it, waits for a clear TX window, and forwards to the next hop. The radio state machine is simple:

Simulation Results

We built a Bay Area-style simulation with 235 nodes in 3 elevation tiers and half-duplex radio modeling. The results confirm the real-world observations:

Half-duplex collapses flooding from ~87% → ~6% delivery. System 5 holds at ~74%. Try the Bay Area scenario in the live simulator →

Memory Footprint — Can This Run on nRF52?

Real-world mesh devices have tight memory constraints. The nRF52840 (used in RAK4631 solar routers) has 256KB RAM, with ~64KB available after BLE and LoRa stacks. System 5 is designed to fit comfortably.

Data Structures (Revised)

With distance-vector routing and compact route entries (12 bytes instead of full path caching at 410 bytes), memory requirements are dramatically lower than initially estimated:

Scaling with Network Size

The key insight: geo-clustering means a node only tracks its own cluster + border routes, and distance-vector means each route is just 12 bytes (destination + next-hop + metadata), not a full path. Even a 10,000-node network uses only ~5.4 KB for routing — leaving >90% of available RAM for the application.

Bay Area Topology — The Real-World Stress Test

Based on feedback from Bay Area Mesh operators, we built a simulation that models the actual network structure:

Three-Tier Elevation Model

What Makes This Scenario Hard

• Extreme asymmetry: Mountain→Valley quality ~1.0 (clear line-of-sight), Valley→Mountain quality ~0 (urban terrain + distance)
• Half-duplex blocking: Mountain nodes hear every transmission within 45km — they're permanently in RX state during flooding
• Collision cascade: 10+ nodes transmitting simultaneously at the mountaintop → capture effect only helps if one signal is 6dB stronger
• Hidden terminal: Two valley nodes can't hear each other but both transmit to the same mountaintop simultaneously

Try this scenario in the Live Simulator → — select "Bay Area Mesh (235 nodes, 3-tier elevation)" from the dropdown.

Read the full Q&A with Bay Area Mesh community →

Node Silencing — Muting Redundant Nodes

One of the most impactful v2.0 features, inspired by Bay Area Mesh feedback. The core insight: in a 235-node network, most valley nodes are redundant — their neighbors can all be reached via other paths. Every time these redundant nodes rebroadcast, they add collision noise at mountaintop receivers without contributing to message delivery.

How It Works

1. Redundancy scoring: For each node, check every neighbor — can that neighbor be reached by at least 2 other alive nodes? If yes, this neighbor connection is "redundant." The node's redundancy score = fraction of redundant neighbor connections (0.0 = critical, 1.0 = fully replaceable).
2. Critical bridge protection: Border nodes with few alternatives (≤3 other bridges to the same cluster pair) get their score heavily penalized. Mountain nodes and essential hill nodes are never silenced.
3. Battery-weighted priority: silence_priority = redundancy × 0.6 + (1 - battery) × 0.4. Low-battery nodes are silenced first. Solar nodes (always 100%) stay active longest.
4. Per-cluster application: Within each cluster, the top 60% of candidates (by priority) are silenced. At least 2 nodes always remain active per cluster.

What Silenced Nodes Do (and Don't)

Battery-Fair Rotation

The same nodes can't be silenced forever — their batteries would last longer, but the active nodes would drain faster. System 5 rotates the silent set every 10 minutes:

1. All expired silences are lifted
2. Redundancy scores are recomputed (nodes may have moved, died, or changed load)
3. A new set of nodes is selected for silencing, weighted by current battery level

Result: every node spends roughly equal time active and silent. Battery drain is distributed evenly across the network.

Results

Emergency Re-Route — Last Resort Before Flooding

When all 5 cached routes fail (every hop was tried with retries), the original System 5 immediately triggered scoped corridor flooding. This was expensive — in the Bay Area scenario, 73 out of 200 messages triggered fallback floods.

The v2.0 improvement adds one more step before flooding:

1. Collect all intermediate nodes from the failed routes into a failed_nodes set
2. Run a fresh BFS from source to destination, excluding all failed nodes
3. If a new path is found, try it once (directed, not flooding)
4. Only if this emergency path also fails → trigger corridor flooding

This is cheap (one BFS computation, no extra TX unless the path works) and often succeeds because the failed nodes were the actual problem — the rest of the network may have perfectly good paths.

Sequence Numbers — Detecting Missing Messages

Multi-path routing can deliver messages out of order. If messages A, B, C are sent via three different paths with different latencies, the receiver might see C, B, A — or worse, C, A (B lost on a failed path).

The v2.0 wire protocol adds a 2-byte sequence counter (uint16_t seq) per (source, destination) pair:

• The sender increments seq for each message to a given destination
• The receiver tracks the last seen sequence number per source
• Gaps are detectable: "received seq 3, then seq 5 — seq 4 is missing"
• Out-of-order is detectable: "received seq 5, then seq 4 — reorder"

The sequence counters are stored efficiently in firmware: neighbor-indexed array for known neighbors (32 bytes) + LRU cache for others (96 bytes) = 128 bytes total, regardless of network size.

Packet Format — What Goes Over the Air

Every System 5 packet has a 22-byte header:

System 5 vs. Everything Else

* Next-hop only works for direct messages after a learning flood. First message still floods.
** GPS required for clustering, but RSSI triangulation and cluster inheritance provide fallbacks.