Scope: Each candidate MAC approach for Loomwave, with the airtime budget math required by
the project brief: packet sizes, airtime per packet at the target modulation, expected
frequency, and resulting channel utilization at target network sizes. This document turns the
qualitative verdicts of hidden-node-analysis.md §5 into numbers. The recommendation feeds
/workspace/docs/design-decision.md in Stage 2 (after sim validation) — nothing here is
final until the sim confirms it.
LoRa time-on-air (Semtech SX127x/SX126x datasheet formula, as implemented behind
Meshtastic's RadioInterface::getPacketTime → RadioLib getTimeOnAir,
RadioLibInterface.h:176):
Tsym = 2^SF / BW # symbol time (BW in kHz → ms)
Tpreamble = (n_preamble + 4.25) · Tsym
payloadSym = 8 + max( ceil( (8·PL − 4·SF + 28 + 16·CRC − 20·IH) / (4·(SF − 2·DE)) ) · (CR+4), 0 )
Tpayload = payloadSym · Tsym
ToA = Tpreamble + Tpayload
PL = payload bytes, CRC=1, IH=0 (explicit header), DE=1 when Tsym>16 ms (low-data-rate opt),
CR∈{1..4} for 4/5..4/8. We use n_preamble = 16 to match Meshtastic
(RadioInterface.h:preambleLength=16).
Airtime per packet (ms), computed from the model:
| Preset (SF/BW/CR) | Tsym | 16 B | 32 B | 64 B | 128 B | 237 B |
|---|---|---|---|---|---|---|
| LongFast SF11/250/4·5 | 8.19 ms | 354 | 477 | 723 | 1215 | 2034 |
| LongMod SF11/125/4·8 | 16.38 ms | 987 | 1511 | 2429 | 4264 | 7410 |
| LongSlow SF12/125/4·8 | 32.77 ms | 1974 | 2761 | 4334 | 7741 | 13509 |
| MediumFast SF9/250/4·5 | 2.05 ms | 99 | 140 | 212 | 355 | 601 |
| ShortFast SF7/250/4·5 | 0.51 ms | 30 | 40 | 63 | 112 | 191 |
| ShortTurbo SF7/500/4·5 | 0.26 ms | 15 | 20 | 32 | 56 | 96 |
LongFast is Meshtastic's default and our conservative/long-range baseline;
ShortFast/MediumFast are the levers for higher capacity where range permits. Raw channel
capacity (packets/s, 32 B) is simply 1000/ToA: LongFast 2.1/s, MediumFast 7.2/s,
ShortFast 24.9/s. This ceiling bounds every MAC below — no MAC can deliver more 32 B
packets/s than this, it can only control how much of it is wasted on collisions and control.
LongFast is the right baseline for worst-case range/capacity, but it is not what real
dense networks actually run. The North Georgia Meshtastic network
(north-georgia-data-characterization.md) is 224/244 nodes on MediumFast (SF9/BW250), with
only 19 still on LongFast. Per the network's operators, the metro Atlanta area (and other
dense pockets) migrated LongFast → MediumFast specifically once LongFast became saturated —
trading range for ~3.4× the on-air capacity. This is direct field corroboration of the capacity
argument in this document: operators hit the LongFast ceiling and respond exactly as the math
predicts.
This document therefore carries two baselines, and the realistic dense scenarios ("dense-event", "neighbourhood", "north_georgia_metro") are evaluated at MediumFast:
| Metric (32 B data) | LongFast SF11 (range / worst-case) | MediumFast SF9 (dense, real-world) |
|---|---|---|
| Airtime per packet | 477 ms | 140 ms |
| Raw channel capacity | ~2.1 pkt/s | ~7.2 pkt/s |
| Flood collapse (1 msg/min, util 0.37) | ~6.8 nodes | ~12.6 nodes |
| TDMA collision-free, 47-node metro cluster | 2.5 msg/node/min | 9.2 msg/node/min |
| TDMA slot (32 B) / efficiency | 480 ms / 99% | 143 ms / 98% |
The qualitative conclusions are identical at either preset — flooding collapses at low double-digit node counts, TDMA restores ~99% efficiency and removes hidden-node loss, control overhead stays ~1–3%. MediumFast simply shifts every threshold ~3.4× more favourably, which is why it is the realistic operating point for dense scenarios. The sections below quote LongFast numbers (the conservative case); for the MediumFast equivalent, multiply capacity by ~3.4× (or divide airtime/latency by ~3.4×), or read the MediumFast column already present in the §1, §3.2, and §3.3 tables.
Mechanism: broadcast + managed rebroadcast, randomised CW back-off, CAD before TX. No
coordination (meshtastic-routing-analysis.md §3–4).
Budget. Every broadcast is rebroadcast by ~all reachable rebroadcasters, so one originated message costs up to N transmissions. With every node sending one 32 B message per interval T:
Channel load L ≈ N² · ToA / T (ToA = 0.477 s, LongFast 32 B)
Saturation (L→util): N_sat = sqrt(util · T / ToA)
New to
N²·ToA/T? The derivation and the "why N²" intuition (two factors of N — more senders × flooding's per-message relay multiplier) are inmeshtastic-routing-analysis.md§8.1.
| T | util=1.0 | util=0.37 (good CSMA) | util=0.18 (ALOHA-like) |
|---|---|---|---|
| 30 s | 7.9 | 4.8 | 3.4 |
| 60 s | 11.2 | 6.8 | 4.8 |
| 300 s | 25.1 | 15.3 | 10.6 |
Verdict: collapses between ~5 and ~11 nodes at 1 msg/min on LongFast. Hidden-node
losses (hidden-node-analysis.md §3) sit on top of this. Disqualified as the data plane;
retained only as the discovery plane and the infrastructure-free fallback.
Airtime budget table (LongFast, N=50, 1 msg/node/60 s):
| Packet type | Size | ToA | Freq (per node) | TX/node/min | Net TX/min (×N, ×flood) | Channel util |
|---|---|---|---|---|---|---|
| Broadcast data | 32 B | 477 ms | 1/60 s | 1 | 50 originate × ~50 relays = 2500 | 1988% (collapsed) |
Mechanism: INFRA broadcasts a slot schedule beacon; clients transmit only in assigned
slots, referenced to the INFRA beacon clock (hidden-node-analysis.md §5.2). Collisions → 0
by construction within the collision domain.
Guard must cover clock drift since last beacon + propagation (≤30 km ⇒ ≤0.1 ms) + Tx/Rx turnaround (~0.4 ms) + processing (~2 ms):
| Crystal | Beacon interval | Drift | Guard total |
|---|---|---|---|
| 20 ppm | 10 s | 0.20 ms | 2.7 ms |
| 20 ppm | 30 s | 0.60 ms | 3.1 ms |
| 40 ppm | 60 s | 2.40 ms | 4.9 ms |
So a ~3 ms guard suffices with a 30 s beacon and ordinary crystals — no GPS required, per the brief. Guard overhead on a 477 ms LongFast slot is <1%.
slot = ToA(data) + guard; slots/frame = frame / slot; efficiency = ToA/slot.
| Preset | data | slot (32 B) | efficiency | data slots/s (channel-wide) |
|---|---|---|---|---|
| LongFast | 477 ms | 480 ms | 99% | 2.08 |
| MediumFast | 140 ms | 143 ms | 98% | 6.90 |
| ShortFast | 40 ms | 43 ms | 93% | 23.1 |
msgs/node/min = (1000/slot)·60 / N:
| N | LongFast | MediumFast | ShortFast |
|---|---|---|---|
| 10 | 12.5 | 41 | 139 |
| 50 | 2.5 | 8.3 | 27.7 |
| 100 | 1.25 | 4.1 | 13.9 |
| 500 | 0.25 | 1.4 | 4.6 |
Verdict: TDMA makes the channel fully usable (≈99% efficiency vs flooding's collapse) and eliminates hidden-node collisions. But it cannot beat the raw ceiling: on LongFast, 500 nodes share 2.08 slots/s ⇒ 1 msg / 4 min each. For the brief's targets: - sparse-rural (10 nodes): 12.5 msg/node/min on LongFast — abundant. - dense-event (100 nodes): 1.25 msg/node/min on LongFast; MediumFast (4.1) or ShortFast (13.9) needed for headroom — viable if range allows the faster SF. - 500 nodes: requires faster SF and/or spatial reuse (§5).
INFRA beacon (16–32 B) carrying the slot map:
| Preset | beacon ToA | every 10 s | every 30 s |
|---|---|---|---|
| LongFast | 354 ms | 3.5% | 1.2% |
| MediumFast | 99 ms | 1.0% | 0.3% |
| ShortFast | 30 ms | 0.3% | 0.1% |
A 30 s beacon costs ~1.2% of channel on LongFast — well within the brief's "<40% control overhead is the line" and comparable to Reticulum's 2% ANNOUNCE_CAP. Beacon overhead is not the constraint; the raw airtime ceiling is.
Mechanism: INFRA periodically broadcasts a short busy/grant beacon both hidden nodes hear,
loosely serialising them (hidden-node-analysis.md §5.3). Cheaper and looser than TDMA.
Budget. Beacon overhead identical to §3.4 (~1–3% LongFast). No slot bookkeeping, so it scales to unknown client populations without per-client assignment — but it cannot prevent collisions that begin between beacons, so residual hidden-node loss persists, bounded by the beacon period relative to airtime:
residual collision risk ≈ fraction of a 2·ToA window not covered by the most recent grant
With LongFast 2·ToA ≈ 954 ms and a 1 s beacon, coverage is coarse and residual loss is only modestly better than CSMA. With a 250 ms beacon, overhead rises to ~14% but residual loss drops sharply. Verdict: a good fallback / sparse-rural mode (low state, no assignment), strictly weaker than TDMA at density. Use where client count is small or highly dynamic and full scheduling is not worth its bookkeeping.
Mechanism: assign the same time slot to nodes in non-overlapping coverage zones so
they transmit simultaneously without colliding (hidden-node-analysis.md §5.4). Requires a
topology/link-state view, which INFRA nodes can build from announces
(reticulum-routing-analysis.md §4).
Budget. Capacity multiplies by the spatial-reuse factor R (number of simultaneously non-interfering zones):
delivered/node/min = (1000/slot)·60·R / N
| R=1 | R=2 | R=3 | R=4 | |
|---|---|---|---|---|
| LongFast, N=100 | 1.25 | 2.5 | 3.75 | 5.0 |
| LongFast, N=500 | 0.25 | 0.5 | 0.75 | 1.0 |
| MediumFast, N=500 | 1.4 | 2.8 | 4.1 | 5.5 |
R is set by topology (how many disjoint zones the deployment actually has); the neighbourhood scenario (6 INFRA scattered on high ground) is precisely the geometry that yields R≈3–6. Verdict: the path to hundreds of nodes. Higher control cost (topology maintenance, slot colouring) and only meaningful with multiple INFRA nodes. Phase 2 once single-domain TDMA is validated in sim.
Mechanism (the brief's option, and the convergent conclusion of all three codebase analyses): - Discovery plane: flood/CSMA for adverts/announces only, rate-capped à la Reticulum ANNOUNCE_CAP (≤2% channel), fewer-hops-first. Lost adverts self-heal next cycle. - Data plane: TDMA (Option B) when an INFRA/time reference exists; spatial-TDMA (Option D) where topology supports it; graceful fallback to CSMA (Option A) when no coordinator is present (pure-LoRa mandate).
Combined budget (LongFast, dense-event N=100, target 1 msg/node/min):
| Plane | Packet | Size | ToA | Rate | Channel util |
|---|---|---|---|---|---|
| Discovery | advert | 32 B | 477 ms | capped | ≤ 2.0% |
| Coordination | slot beacon | 32 B | 477 ms | 1/30 s | 1.2% |
| Data | scheduled msg | 32 B | 477 ms | 100/min total | 79.5% (100·477 ms / 60 s) |
| Total | ≈ 83% — fits, collision-free |
Contrast the same offered load under pure flooding: ~1988% (§2) — i.e. a ~24× reduction in required channel from moving data off the flood and onto a schedule, while also eliminating hidden-node loss. The control overhead (discovery + coordination ≈ 3.2%) is an order of magnitude under the brief's 40% red line.
Verdict: recommended architecture. TDMA data plane solves hidden node and unlocks ~99% channel efficiency; the capped CSMA discovery plane keeps cold-start and churn cheap; CSMA fallback honours the infrastructure-free requirement.
| MAC option | Hidden node solved? | LongFast cap (N=100) | Control overhead | Needs INFRA/time? | Role |
|---|---|---|---|---|---|
| A. Pure flood/CSMA | ✗ | collapses (<11 nodes) | none (but storms) | no | fallback / discovery only |
| B. INFRA TDMA | ✓ (in domain) | 1.25 msg/node/min | ~1.2% | yes (beacon) | data plane (primary) |
| C. INFRA-LBT beacon | partial | between A and B | 1–14% | yes | sparse/dynamic fallback |
| D. Spatial TDMA | ✓ + reuse | 1.25·R | higher (topology) | yes (multi) | scale (phase 2) |
| E. Hybrid (A-discovery + B/D-data) | ✓ | ≈83% util fits 1/min | ~3.2% | degrades w/o | recommended |
routing-options.md,
security-options.md) is spent against the budget — ~2.1 packets/s on LongFast, ~7.2 on
MediumFast (the realistic dense baseline, §1.1).These numbers are model-derived and must be confirmed in the SimPy PHY/MAC sim (Stage 2) with realistic collision and capture modelling before any are treated as final.