← RFC

Channel/group traffic — MeshCore/Meshtastic flood vs Loomwave membership-scoped multicast

Status: Result (airtime-budget model). Date: 2026-06-16. Script: sim/experiments/channel_traffic.py. Figure: docs/figures/channel_traffic.png.

Answers: how does channel ("group") traffic work in MeshCore, and how does that impact a Loomwave network? Companion to relevance-scoping-note.md and scope-waste-result.md — channel traffic is the case those notes' "broadcast scope" question gets hard, because a group message must reach every subscriber wherever they are.

How MeshCore (and Meshtastic) handle channel traffic

From MeshCore's own FAQ (5.5) and firmware (src/Mesh.h GroupChannel, src/Packet.h PAYLOAD_TYPE_GRP_TXT 0x05): group/channel messages flood the entire mesh. A group "is A to B, so there is no defined path — it has to flood." Channels are a 1-byte channel hash + a shared secret; any node with the key decrypts. The only control is a manual per-repeater hop cap (flood.max), set by each operator with no guidance — the same underused manual "region" knob this project keeps running into.

The consequence: every channel message is carried by every relay in the mesh, regardless of where the channel's members are. In the North-Georgia data ~99% of traffic is exactly this kind of broadcast (scope-waste-result.md), and it's why the channel floods dominate airtime.

Why this is the hard case — and where a hop cap is wrong

For a directed message Loomwave just routes (no flood). For a channel message there is no single destination — but there is a membership: the cells that have a subscriber. That distinction is the whole game: - A hop-radius cap (MeshCore flood.max) is the wrong tool for channel traffic: it drops a subscriber three cells away who genuinely wants the message. You can't fix a membership problem with a distance limit. - Loomwave can do what neither flood mesh can: membership-scoped multicast — carry the channel message over the INFRA backbone only to the cells that have a subscriber, and deliver locally with one scheduled coordinator broadcast per cell (not a flood storm). Reaches exactly the members, at a fraction of the air.

Model

Airtime-budget model (same style as the v4/v5 scaling analyses; to be DES-confirmed). Unit = one channel packet's time-on-air T at MediumFast (48 B → 170 ms). M = 20 relay-capable nodes per cell. - Flood (MeshCore/Meshtastic): managed flood = every node rebroadcasts once → ≈ N_total · T per message, independent of where members are. - Loomwave scoped: ≈ 2c · T for a channel with members in c cells (≈c backbone hops + one coordinator broadcast per member-cell). Independent of M — the coordinator broadcasts once per cell.

Findings

1. Flood scales with the whole mesh; scoped scales with membership.

cells	nodes	flood / msg	scoped (public)	scoped (topic, 20% cells)	public ×cheaper	topic ×cheaper
8	160	27.3 s	2.7 s	0.68 s	10×	40×
32	640	109 s	10.9 s	2.4 s	10×	46×
64	1280	218 s	21.8 s	4.4 s	10×	49×

Even for the worst case — the universal "public" channel everyone subscribes to — scoped multicast is ~10× cheaper, purely because local delivery is one coordinator broadcast per cell instead of 20 nodes flooding (the M factor). For a topic channel in 20% of cells it compounds to 40–49× (the network never carries the channel into cells with no members). The flood cost grows with total nodes; the scoped cost grows only with the channel's cell footprint.

2. The manual hop cap can't win the trade. On a 32-cell line, public channel:

flood.max H	airtime	member delivery
3	23.9 s	0.22
8	58.0 s	0.53
16 (full)	109 s	1.00
Loomwave scoped	10.9 s	1.00

To deliver to all members the cap must be wide open (= full flood, 109 s); tighten it and distant members fall off (H=8 → only 53% delivered). Loomwave scoped multicast gets full delivery at 10.9 s — 10× less than the full flood and reaching everyone — escaping the trade entirely.

Impact on a Loomwave network (design implications)

• Channel traffic is the dominant scaling risk — it's the one thing that must reach many nodes — and it's where Loomwave's coordinator/membership model pays off most. Plain flood (the MeshCore/Meshtastic model) would make channel airtime grow with the whole mesh and re-introduce the broadcast-storm collapse the data plane was designed to avoid.
• The mechanism to build: coordinators advertise per-channel membership/interest over the backbone (coarse: which channels their cell has subscribers for — same interest-advertisement as relevance-scoping-note.md Level 2); a channel message is routed as a backbone multicast to member-cells only, then delivered by each coordinator as a single scheduled in-cell broadcast.
• The default "public" channel is the case to manage. When everyone subscribes, scoping gives no footprint benefit (every cell has a member) — but Loomwave still wins ~M× by replacing the in-cell flood storm with one coordinator broadcast. Worth steering communities away from one giant default channel (a product/onboarding nudge), since that single channel is the worst-case load.
• Channel scope ≠ hop scope. For machine/telemetry broadcast, a tight hop scope is right (scope-waste-result.md); for channel traffic, membership-scoped multicast is right. Loomwave needs both, selected by traffic class.

Caveats

• Airtime-budget model, not DES (consistent with how v4/v5 scaling was first framed). Assumptions: managed flood = one rebroadcast per node; scoped = 2c transmissions with one coordinator broadcast per cell; the hop-cap panel uses cells in a line. M=20 is a parameter; real cells vary. The 2c backbone term is conservative (an aggregated multicast tree can be cheaper).
• Next: DES-confirm on a multi-cell topology (roadmap S3) with channel-tagged traffic and the scoped-multicast delivery path; sweep membership concentration and the default-channel-everyone case.