← RFC

Scenario-Class Suite — Measured Result (closes Stage-2 "done" criteria #2 & #3)

Status: Stage 2 result. Date: 2026-06-09. Tag: sim-result-v7. Reproduce: cd sim && python3 -m experiments.scenario_suite.

Closes the two literal CLAUDE.md Stage-2 "done" criteria that were still open: - #2 — the sim runs all three scenario classes (sparse-rural, dense-event, neighborhood) without errors. (The fourth, north_georgia, is the real-data gate, v2.) - #3 — produces delivery ratio, latency CDF, and channel utilisation for ≥2 MAC variants (flooding+CSMA vs hybrid TDMA) on each. (The ≥2 routing variants are v5, routing-control-result.md.)

Each scenario runs under both MACs on identical topology + traffic — every client offers one telemetry packet/min to its nearest INFRA — so the metrics are apples-to-apples.

Result (600 s runs, seed 1)

Scenario (nodes / INFRA / preset)	MAC	delivery	latency p50	latency p90	channel util
sparse-rural (10 / 2 / LongFast)	flood	1.000	0.48 s	2.44 s	58.5%
	tdma	0.990	5.43 s	7.83 s	7.9%
dense-event (100 / 4 / MediumFast)	flood	0.346	4.14 s	7.62 s	99.2%
	tdma	0.961	16.2 s	27.0 s	24.7%
neighborhood (50 / 6 / MediumFast)	flood	0.877	2.43 s	6.56 s	99.2%
	tdma	0.980	7.32 s	11.9 s	12.7%

Reading (the honest tradeoffs)

• At scale, TDMA wins decisively. Dense-event flooding collapses to 0.35 (channel pinned at 99%); coordinated TDMA holds 0.96 at 25% util. Neighborhood: 0.98 vs 0.88, and TDMA uses ⅛ the channel. This is the scenario-level confirmation of v1/v3.
• Below the collapse knee, flooding is the right tool. At sparse-rural's 10 nodes, flooding delivers everything at sub-second latency; TDMA matches delivery (0.99) but adds latency for no benefit. The design's "never worse than flood, strictly better where a coordinator helps" stance is exactly this: TDMA earns its keep at density, not at trivial scale. (Loomwave would run the CSMA/contention plane here.)
• TDMA trades latency for reliability — and that latency is the single-domain frame. A coordinated schedule with one global frame makes a client wait up to N_clients × slot for its turn: dense-event's 100-slot MediumFast frame is ~14 s, hence the ~16 s p50. This is precisely what spatial reuse relieves (v4): splitting those 100 nodes into 4 parallel INFRA cells of ~25 shortens the frame ~4× (≈3.6 s) and cuts latency with it. So v4 is not only a capacity lever — it is the latency lever for the coordinated plane.
• Channel efficiency is the quiet headline. TDMA carries the same load at 8–25% channel utilisation where flooding saturates at 58–99% — the airtime it doesn't burn is headroom for more nodes, higher rates, or lower power.

Model notes (what "tdma" means here, honestly)

• This is the coordinated single-domain TDMA: every client gets a globally-unique slot from a shared frame clock (the INFRA backbone / relayed time references the design posits), so transmissions never overlap — collision-free even where INFRA cells overlap. (An earlier naive per-cell wiring let overlapping cells' independent schedules collide; that was a modeling artifact, not the design, and is fixed here.)
• Spatial reuse across separated cells — the capacity/latency multiplier — is measured separately in adaptive-modulation-result.md (v4); this suite deliberately isolates the single-domain coordinated plane so the MAC comparison is clean.
• The coordinated plane assumes a shared frame clock reaches every client (backbone + relayed time). Where it doesn't, a client falls back to the contention/epoch-hash plane (v6); modelling that multi-hop time distribution is a follow-up.