← RFC

Hidden Node Analysis

Scope: A precise statement of the hidden-node problem for LoRa mesh, the LoRa-specific physics that make it hard, quantification of its severity, and an evaluation of candidate solutions. This document is the problem statement that mac-layer-options.md then turns into an airtime budget for each MAC approach. It is the central technical challenge named in the project brief.

1. The problem, stated precisely

Three nodes: A, B, R. A and B can both reach R, but A and B cannot hear each other. A and B are hidden from one another behind R.

Any carrier-sense scheme works by listening before transmitting. But A listening finds the channel clear with respect to what A can hear — and A cannot hear B. So A and B can both sense "clear" and transmit at overlapping times. Their signals collide at R, and (absent a large power difference — see §2.3 capture) both packets are lost. Neither A nor B can detect this: they hear only their own transmission, and a missing acknowledgement is the only (delayed, ambiguous) symptom.

This is not a corner case for Loomwave — it is the expected operating regime, because of the architecture the brief mandates:

"INFRA nodes at elevation can hear many clients that cannot hear each other."

An elevated INFRA/REPEATER node is, by design, a node that maximises the hidden-node population: it is placed precisely so that many clients who cannot hear each other can all hear it. The very thing that makes an elevated relay useful is the thing that makes the hidden-node problem dominate. Adding a high-site relay to a naïve CSMA mesh can increase collisions, because it gathers together transmitters that would otherwise never have contended. This is consistent with the documented community failure reports of "Meshtastic at scale" once a high relay is introduced.

2. Why LoRa makes it worse than classic Wi-Fi hidden-node

2.1 Half-duplex: a transmitter is deaf

LoRa radios (SX127x/SX126x/LR11xx) are half-duplex: while transmitting, the radio cannot receive. So a node has zero awareness of the channel during its own (long) transmission. Collision detection (CSMA/CD, as in wired Ethernet) is physically impossible; only collision avoidance (CSMA/CA) is available, and avoidance fails for hidden nodes by definition.

2.2 Airtime is enormous — the vulnerability window is huge

The probability of a hidden-node collision scales with how long a packet occupies the channel. In unslotted ALOHA, a packet is vulnerable for 2× its airtime (a colliding transmission can start any time from one airtime before to one airtime after). LoRa airtimes (Meshtastic LongFast, SF11/BW250, 16-symbol preamble, CR4/5):

Payload	Airtime	2× vulnerability window
16 B	354 ms	708 ms
32 B	477 ms	954 ms
64 B	723 ms	1446 ms
237 B	2034 ms	4068 ms

Compare Wi-Fi, where a frame is tens of microseconds. A LoRa node sits exposed ~10⁴× longer per packet. The hidden-node collision probability is correspondingly enormous.

2.3 Capture effect — a partial, unreliable mitigation

LoRa can sometimes capture the stronger of two overlapping signals if it arrives first and is ≥ ~6 dB stronger (co-SF) — the weaker is treated as noise and the strong one survives. This helps an elevated node that hears one client much louder than another, but it is asymmetric and unreliable: it cannot be designed around, it silently starves the weaker (often more distant, more important) node, and it disappears when powers are comparable. We treat capture as occasional luck, not a mechanism.

2.4 Orthogonal SFs are not a free fix

Different spreading factors are quasi-orthogonal, so same-SF collisions are the dominant concern. But a Loomwave network must interoperate on a common SF for the mesh to connect; SF diversity is a frequency/diversity planning tool for INFRA (the brief asks us to evaluate multi-radio INFRA), not a per-packet collision solution for a single logical channel.

2.5 Duty-cycle regulation interacts badly with retransmission

EU 868 limits a node to ≤1% (or 10% on some sub-bands; Meshtastic uses 10% for routers). When a hidden-node collision forces a retransmission, the retransmit competes with the duty-cycle budget — so collisions don't just cost airtime, they consume the node's regulatory allowance, throttling legitimate traffic. In the US (no hard duty limit) the constraint is softer, but FHSS / dwell-time rules still bound long packets.

3. How severe is it? (quantified)

Model the canonical case: an elevated INFRA node hears K clients that are mutually hidden, each transmitting 1 packet per period. Treat arrivals at the INFRA receiver as independent (the worst case — no coordination). Unslotted-ALOHA survival probability of a given packet is P = e^(−2·λ·T), where λ = K/period is the aggregate arrival rate at the receiver and T is the packet airtime (0.477 s for a 32 B LongFast packet).

K (hidden clients)	period	aggregate pkts/s	P(delivered)	collision loss
5	60 s	0.083	0.924	7.6%
10	60 s	0.167	0.853	14.7%
20	60 s	0.333	0.728	27.2%
50	60 s	0.833	0.452	54.8%
100	60 s	1.667	0.204	79.6%
50	300 s	0.167	0.853	14.7%
100	300 s	0.333	0.728	27.2%

Reading: with 20 mutually-hidden clients each sending once a minute, >27% of packets are lost to collision at the shared INFRA node before any routing, flooding amplification, or retransmission storms are considered. At the dense-event scale (100 clients), a naïve CSMA mesh loses ~80% of packets to hidden-node collisions at 1 msg/min. Slowing to one message every 5 minutes only buys back roughly one severity tier. This is the failure mode that caps every flood-based system well below the brief's 500-node target, and it is the quantitative justification for moving away from pure CSMA.

(These are loss rates at a single receiver from hidden peers. They compound with the N² flooding load from meshtastic-routing-analysis.md §8.1 — flooding both adds more transmitters and makes each retransmission another exposure.)

4. Why the obvious fix (RTS/CTS) is too expensive

The textbook hidden-node solution is RTS/CTS: A sends a short Request-To-Send; R replies with Clear-To-Send, which B can hear (B hears R); B now defers. This converts the hidden node into an exposed one.

On LoRa it is unaffordable. RTS and CTS are themselves packets with full preamble + headers (~12–16 B minimum), so each costs roughly a minimum-size airtime:

Preset	RTS+CTS airtime	data airtime	control overhead of the exchange
LongFast	708 ms	477 ms	60%
MediumFast	198 ms	140 ms	59%
ShortFast	60 ms	40 ms	60%

A two-way handshake before every data packet spends ~60% of the exchange's airtime on control and triples the number of transmissions on the channel — which, with long LoRa airtimes, increases total contention. RTS/CTS is rejected for Loomwave data traffic (confirming the brief's prompt to "evaluate alternatives"). It might survive only as a rare, reservation-style mechanism for unusually large transfers, not the common path.

5. Candidate solutions, evaluated

For each, the question is: does it actually break the hidden-node mechanism (transmitters coordinating despite not hearing each other), and at what airtime cost? Detailed airtime budgets are in mac-layer-options.md; this section is the qualitative verdict.

5.1 Pure CSMA / LBT + CAD (what Meshtastic and MeshCore do)

Mechanism vs hidden node: none. Carrier sense cannot detect an unheard transmitter.
What it does help: the exposed-node and same-neighbourhood redundant-rebroadcast cases (via SNR-weighted back-off, meshtastic-routing-analysis.md §4, MeshCore calcRxDelay §6).
Verdict: necessary as a baseline/fallback, insufficient as the solution. This is exactly the gap Loomwave must close.

5.2 TDMA with distributed slot assignment (INFRA broadcasts schedule)

Mechanism vs hidden node: solves it by construction. If A and B transmit in different time slots, they cannot collide at R regardless of whether they hear each other — collisions go to ~0 (§3 last row). The shared resource that A and B both trust is R's clock/beacon, which both can hear; that common reference is what carrier sense lacked.
Cost: requires time sync (INFRA beacon as reference; GPS optional, not required per brief) and slot-assignment control traffic. Slot guard times must cover clock drift + LoRa propagation (≤30 km ⇒ ≤100 µs, negligible vs ms slots) + Tx/Rx turnaround.
Risk: depends on an INFRA/time reference being present; must degrade gracefully to CSMA when absent (pure-LoRa, infrastructure-free mandate).
Verdict: the primary candidate for the data plane where an INFRA/REPEATER beacon exists. Quantified in mac-layer-options.md.

5.3 Listen-Before-Talk with INFRA "channel busy" beacon

Mechanism vs hidden node: partial. If R broadcasts a short "busy/grant" beacon that A and B both hear, it can serialise them through R's knowledge. This is RTS/CTS with R as the coordinator and amortised over many packets rather than per-packet.
Cost: cheap (periodic small beacon), but imprecise — beacon latency vs long airtimes means windows are coarse; cannot prevent collisions that begin between beacons.
Verdict: a useful cheap middle ground / fallback, weaker than TDMA but far better than nothing. Good for the sparse-rural case where full TDMA scheduling is overkill.

5.4 Spatial TDMA / reuse (slots assigned by topology)

Mechanism vs hidden node: solves it where it matters while allowing non-interfering nodes in different coverage zones to transmit simultaneously, recovering capacity TDMA otherwise wastes. Requires link-state/topology knowledge (which INFRA nodes can build from announces — see reticulum-routing-analysis.md).
Cost: needs a topology view and a colouring/assignment computation; more control state. Natural fit for INFRA-present scenarios; impractical without a coordinator.
Verdict: the scale play — the way to push toward hundreds of nodes without the channel-capacity ceiling of single-collision-domain TDMA. Phase 2 target once basic TDMA is validated in sim.

5.5 Hybrid: flood/CSMA for discovery, scheduled MAC for data (brief's option)

Mechanism vs hidden node: discovery is rare, small, idempotent (a lost advert is re-sent next cycle) so its hidden-node losses are tolerable and rate-capped (Reticulum ANNOUNCE_CAP); data, which must be reliable, runs on the scheduled MAC that does solve hidden node. Best of both: no time sync needed to find neighbours, coordination used where reliability is required.
Verdict: recommended architecture. It matches the conclusions of all three codebase analyses (confine flooding to control; route/schedule data) and is the design this analysis package points toward. Detailed budgets in mac-layer-options.md and routing-options.md.

6. Implications for Loomwave node roles

INFRA (elevated, always-on, possibly GPS): the natural time reference and slot authority. It hears the most hidden pairs, so it is also the node that benefits most from coordinating them. Multi-radio INFRA (brief's open question) could additionally separate uplink/downlink or SF zones to reduce the collision domain it presents.
REPEATER: participates in the schedule; relays scheduled data; can serve as a secondary time reference (beacon relay) so coordination degrades gracefully across the mesh, not just within one INFRA's range.
CLIENT: transmits only in assigned/contended slots; sleeps otherwise (power mandate). CLIENT_RELAY submode participates in relaying but still under the schedule.
Infrastructure-free fallback: with no INFRA present, the network must fall back to CSMA + SNR-weighted back-off (§5.1) — accepting the §3 loss rates — until a coordinator appears. The MAC must detect "coordinator present/absent" and switch. This is the single most important behavioural requirement the MAC spec must nail.

7. Open questions for the MAC design (carried into `mac-layer-options.md`)

Slot time vs airtime: at LongFast a 32 B packet is 477 ms; slots must be ≥ packet airtime + guard. How many slots fit a usable frame, and how does that bound clients/INFRA?
Time-sync budget: what drift does an INFRA beacon achieve without GPS, and what guard time does that force? (Cheap crystals drift ~10–40 ppm ⇒ ~36–144 ms/hour — beacon cadence must bound this below the guard.)
Coordinator handoff: how do nodes agree on which INFRA is the slot authority when several are in range, and how fast does the schedule re-form when it leaves?
Discovery/data split ratio: how much channel for the CSMA discovery plane (ANNOUNCE_CAP-style) vs the scheduled data plane, per scenario class?
Graceful degradation: exact trigger and hysteresis for CSMA↔TDMA mode switching to avoid flapping.

Source grounding

Severity and cost figures use the LoRa airtime model verified against Meshtastic's implementation (RadioInterface.cpp:getPacketTime:615 → RadioLib getTimeOnAir; slot model computeSlotTimeMsec:1172) and the modem-preset table (MeshRadio.h:modemPresetToParams, LongFast = SF11/BW250/CR4-5, 16-symbol preamble). The "elevated relay increases hidden-node contention" claim follows directly from Meshtastic's CSMA-only design (meshtastic-routing-analysis.md §9) and MeshCore's CAD-only Dispatcher (meshcore-routing-analysis.md §8). The ALOHA e^(−2λT) model is the standard unslotted result; the TDMA "collisions→0 by construction" claim is definitional given non-overlapping slots and adequate guard time.