← RFC

North Georgia scope-waste study — result

Status: Result. Date: 2026-06-16. Script: sim/experiments/scope_waste.py. Figure: scope_waste.png. Data: sim/data/malla_ng_calibration.csv (real Malla per-packet receptions: distance_km, portnum, obs_hops, 19,873 rows, two independent gateway sets).

Quantifies, from real data, how far North-Georgia traffic actually propagates vs how far it needs to, and how much relay airtime the over-propagation costs — the empirical case for the data-driven propagation-scope idea (relevance-scoping-note.md).

Method

For each observed reception we have the straight-line origin→gateway distance, the relay depth (obs_hops), and the traffic type (portnum). Airtime per packet is time_on_air_ms(size, MediumFast) using representative PHY payload sizes per type (scenarios/north_georgia.py TYPE_SIZE_B; the CSV payload_len is decoded-text length and is invalid for airtime, per the calibration caveat). MediumFast (SF9/BW250) is the channel North Georgia actually runs. Traffic is split into DIRECTED (text, routing — may legitimately travel) vs machine/broadcast (position, telemetry, nodeinfo, traceroute, unknown — local relevance; a position beacon has no recipient tens of km away). "Relay airtime" weights each observed hop by its packet's ToA.

Findings

1. Almost everything is relayed, and it travels absurdly far. - 94.3% of receptions are multi-hop (≥1 relay). Hop distribution peaks at 2–3, tail to 7. - Median origin distance: 69 km. Max: 474 km. For receptions ≥3 hops (46% of all), median 82 km.

2. Almost all of it is machine/broadcast traffic with purely local relevance.

type	n	%	mean hops	p50 km	p90 km	% >2 hops	class
UNKNOWN	10440	52.5	2.59	81.5	164.1	48.3	local
POSITION	3470	17.5	2.55	62.9	156.0	52.7	local
NODEINFO	3269	16.4	2.38	69.1	114.9	34.5	local
TELEMETRY	1802	9.1	2.37	66.3	210.9	44.8	local
TRACEROUTE	769	3.9	2.09	50.7	82.2	37.2	local
TEXT_MESSAGE	86	0.4	2.99	118.1	205.4	69.8	DIRECTED
ROUTING	28	0.1	2.39	65.1	159.2	50.0	DIRECTED

99.4% of traffic is machine/broadcast; text is 0.4%. Position/telemetry/nodeinfo beacons are being flooded a median ~65–80 km from origin — to nodes that have no use for them.

3. Relaying dominates airtime, and most of it is recoverable by scope. Relaying is ~71% of observed channel airtime (mean ~2.5 hops per packet). Recoverable relay airtime if machine traffic is capped at a per-type scope:

scope (hops)	recoverable relay airtime
≤1	61.8%
≤2	29.2%
≤3	11.2%
≤4	3.6%

Capping machine/broadcast traffic at ≤2 hops recovers ≈29% of relay airtime ≈ 21% of total channel airtime — by changing one policy field, with text/routing left untouched.

Interpretation

• This is the MeshCore-regions problem measured in real data: traffic routinely floods 5–7 hops and tens-to-hundreds of km past any local relevance, and ~99% of it is machine broadcast that never needed to leave its neighborhood. Regions/hop-limits exist to stop this but go unused for lack of guidance.
• Loomwave structurally avoids most of it: directed messages are coordinator-routed (they don't flood at all), so this entire waste is the broadcast/discovery flood — exactly what data-driven scope targets. And the cheapest lever, scope-by-traffic-class (one TC field: machine ≤2 hops, text wider), captures a ~21%-of-channel airtime recovery with zero per-operator configuration — the thing manual regions can't deliver. This is the first concrete number for the Level-1 recommendation engine.

Caveats (this is real but imperfect data)

• Reception-weighted, not a TX ledger. One packet heard by K gateways is K rows; the CSV has no packet ID, so we can't dedup. This over-weights widely-flooded packets — but those are the wasteful ones, so it's a defensible proxy for where airtime goes. The hop/distance distributions are exact; the airtime percentages are modeled estimates under this weighting.
• Survivorship bias: gateways log only CRC-decoded, MQTT-uplinked packets, so the farthest/weakest reach is under-counted — the real over-propagation is if anything worse.
• UNKNOWN_APP is encrypted-channel traffic (mostly machine; some could be text), but decoded text is ≤0.5%, so even a generous reassignment doesn't move the conclusion.
• distance_km is straight-line origin→gateway; high-site gateways see a wide footprint.
• It's a Meshtastic flood network — which is the point: it's the behavior Loomwave's coordinator routing + scoped broadcast is designed to avoid.

Sim delivery-preserving check (companion)

Script: sim/experiments/scope_delivery_check.py. Figure: docs/figures/scope_delivery_check.png. Does scoping cost real delivery, or only waste? On the real 47-node NG metro cluster, the validated flooding model was run at hop_limit ∈ {2,3,4,6} (3 seeds, 1 h each), measuring channel utilisation and delivery to the within-2-hop audience of each origin (the "relevant" audience, defined on the mean-path-loss reachability graph) vs. total reach:

hop_limit	channel util	relevant delivery (≤2 hops)	total reach
2	0.012	0.981	0.935
3	0.024	0.997	0.989
4	0.026	1.000	0.999
6	0.025	1.000	1.000

H=6 → H=2: channel utilisation −54%, total airtime −57%, while within-scope (relevant) delivery only moves 1.000 → 0.981 (−1.9 pts). The reach given up (total 1.000 → 0.935) is the far audience that didn't need the message. So scoping the flood to the relevance radius roughly halves channel airtime and keeps local delivery at ~98% — the saved airtime is almost all redundant relay reach, not useful delivery.

Caveat (this sim's scope): it's one compact cluster (~16×31 km), so it measures intra-cluster redundant-relay reduction. The larger inter-cluster over-propagation the Malla data shows (median 69 km, many clusters) isn't captured here — a multi-cluster run (roadmap S3) would show a bigger cut. This is a conservative lower bound on the airtime scope recovers.

Next steps

1. ✅ Delivery-preserving sim check (above) — done; confirms scope cuts airtime without losing relevant delivery.
2. Multi-cluster sim (roadmap S3) to capture the inter-cluster waste the single cluster can't.
3. Spec scope-by-TC — machine classes get a tight default hop scope; the highest-leverage, lowest-risk piece of relevance-scoping-note.md (needs no reputation system or aggregator).
4. Feed these numbers into the Level-1 aggregator recommendation design.