This document specifies a LoRa-based, fully decentralized emergency messaging scheme that:
- Requires no hardware changes to existing single-radio LoRa nodes
- Uses only firmware / MAC-layer changes
- Is compatible in principle with current Meshcore/Meshtastic-class devices
- Targets hundreds of users per channel at realistic emergency-traffic rates
It is written to be explicit enough that another LLM or RF engineer cannot misunderstand it.
- Stay on a single LoRa channel (same frequency, SF, BW, CR).
- Keep everything decentralized – no central coordinator, no “tower”.
- Use only one radio per node (multi-radio is optional future work).
- Increase usable throughput by ~2–3× over current “random delayed repeat” meshes.
- Prioritize emergency preparedness (EP) traffic, where:
- Most users read more than they transmit
- Typical usage is ≤ 1 message per 5–10 minutes per user
- Latency of a few seconds is acceptable
- Remain physically plausible under LoRa PHY and information-theory constraints.
There are two core mechanisms:
-
SOR – Simultaneous Offset Repeat
All repeaters that hear a packet retransmit it once, in one shared repeat window, instead of at random times. -
ARB – Aggressive Random Backoff
End-user devices (clients) use large, randomized contention windows (3–6 seconds) when the channel is busy, to strongly reduce collisions between original transmissions.
These target two different collision sources:
- SOR fixes repeater vs repeater chaos.
- ARB fixes client vs client chaos (and reduces client vs repeater collisions).
SOR replaces “each repeater repeats after its own random delay” with:
All repeaters that decide to repeat a given packet transmit in a single repeat window that starts at a fixed offset from the original.
Concretely:
- Let T_pkt be the airtime of a single LoRa packet (e.g., ~300 ms).
- A client transmits at time t = 0.
- Repeaters receive this packet from t = 0 → T_pkt.
- All repeaters schedule their retransmission to start at:
t = T_pkt + Δ_repeat
Where:
- Δ_repeat is a fixed delay (e.g., 50–100 ms for processing margin).
- All repeaters use the same Δ_repeat for that message.
Result:
All repeaters transmit the same packet within a single, contiguous repeat window, instead of spreading their transmissions over many separate windows.
We recommend:
- Total repeat window length ≤ T_pkt (so the cluster is effectively one “airtime hit”).
In practice, hardware and firmware jitter will cause micro-offsets of a few milliseconds between repeaters. That is acceptable and expected.
SOR does not:
- Change frequency. All repeaters still transmit on the same frequency and LoRa settings.
- Change spreading factor.
- Use multiple channels or CDMA.
- Use FDMA.
- Require tight GPS-level time sync across the mesh.
SOR is not:
- “Different frequencies per repeater.”
- “Different spreading factors per repeater.”
- “Full TDMA.”
It is simply:
One repeat window per hop, shared by all repeaters for that packet.
When multiple repeaters transmit the same LoRa packet on the same frequency at nearly the same time:
- Receivers see multiple co-channel signals.
- Due to capture effect, the receiver will lock onto the strongest signal at its location, provided it is sufficiently stronger (typically 6–10 dB) than the others.
- In many topologies, one repeater will be notably closer/stronger for a given receiver.
- In pathological cases where several repeaters are exactly equal at a receiver, that receiver may fail to decode that repeat; this is no worse (and often better) than random collision chaos.
This is not “free capacity”; it is a better use of airtime:
- Today: N repeaters = N separate airtime slots.
- SOR: N repeaters ≈ 1 airtime slot (one repeat window).
Let:
- T_pkt = 300 ms
- N = number of repeaters that decide to repeat a given packet
Each repeater applies a random delay and then transmits:
- Original client: 300 ms
- Repeater 1: +300 ms
- Repeater 2: +300 ms
- ...
- Repeater N: +300 ms
Total airtime consumed by that one message (network-wide):
T_total_current ≈ (N + 1) × T_pkt
Example N = 3:
- T_total_current ≈ 4 × 300 ms = 1200 ms
Example N = 5:
- T_total_current ≈ 6 × 300 ms = 1800 ms
- Original client: 300 ms
- All N repeaters: one shared 300 ms repeat window
Total airtime:
T_total_SOR ≈ 2 × T_pkt = 600 ms
For N = 3:
- 1200 ms → 600 ms (2× improvement)
For N = 5:
- 1800 ms → 600 ms (3× improvement)
Real deployments often have 2–4 effective repeaters per packet, so realistic savings are around 1.5–3×.
ARB is applied to client-originated transmissions only, not to repeater repeats.
When a client wants to send:
- It listens to the channel.
- If the channel is idle for a small clear-channel assessment (CCA) time (e.g., 50–100 ms), it transmits immediately.
- If the channel is busy, it chooses a random backoff slot in a large window and waits.
We define:
- Window length: 3–6 seconds
- Slot size: ≈ T_pkt (e.g., 300 ms)
- This yields roughly 10–20 virtual slots.
Clients pick a random integer slot in that range and schedule their transmission start accordingly.
Without ARB, multiple clients may try to transmit:
- At almost the same time, causing direct collisions.
- During repeater windows, causing collisions with repeats.
- In bursts, causing “pile-ups” after busy periods.
With a large backoff window:
- Clients that see the channel busy will distribute themselves across 10–20 slots.
- Even if many users try to send at once (e.g., right after an alert), their actual transmissions will be spread across several seconds.
- Collisions become much rarer, especially among nodes that can hear each other.
Yes, ARB adds seconds of latency in the worst case:
- Average added delay ≈ window_length / 2 ≈ 1.5–3 seconds.
- Multi-hop adds more, but each hop is still in the same order of seconds.
For emergency preparedness messaging (check-ins, status, short updates), this latency is acceptable:
- We are not doing voice.
- We are not doing real-time chat.
- A 2–10 second end-to-end delay is fine for “I’m OK” or “Road blocked here” type messages.
We explicitly trade latency for reliability and capacity, which is the correct trade in EP contexts.
-
SOR: “Compresses” repeater traffic into a single repeat window per hop.
- Saves airtime: 1.5–3× improvement vs naive random repeat.
- Stops the “N repeaters = N slow collisions” problem.
-
ARB: Randomizes client attempts over multiple seconds when busy.
- Sharp reduction in client-originated collisions.
- Sharp reduction in hidden-node collisions (not elimination, but big improvement).
- Reduces collision with repeater windows.
Assumptions:
- T_pkt ≈ 300 ms
- One original + one repeat window → 2 × 300 ms = 600 ms per end-to-end message (best case, no retries).
- Theoretical max: 60,000 ms / 600 ms ≈ 100 msgs/min (hard upper bound).
- With protocol overhead, occasional retries, and safety margin:
- Realistic safe throughput ≈ 60–80 msgs/min.
Compare:
- Current random delayed repeat meshes often become unstable around 15–25 msgs/min effective throughput due to collision-induced retries and chaos.
- SOR + ARB aims for 60–80 msgs/min stable.
That is a ~3× improvement in realistic usable capacity, not a “magic” information-theory violation.
Let:
- R_net = safe network throughput ≈ 60 msgs/min (conservative mid-range).
- r_user = average messages per user per minute.
- N_users = number of users.
We require:
N_users × r_user ≤ R_net
-
r_user = 1 msg/min
N_users ≤ 60
→ ≈ 60 active users -
r_user = 1 msg/2 min (0.5 msg/min)
N_users ≤ 120
→ ≈ 100–120 active users -
r_user = 1 msg/5 min (0.2 msg/min)
N_users ≤ 300
→ ≈ 300–500 active users realistic, given non-uniform traffic -
r_user = 1 msg/10 min (0.1 msg/min)
N_users ≤ 600
→ 600–1000+ users, depending on how bursty things are
These numbers align with:
- Physics (single-channel airtime)
- The SOR+ARB gains (about 3× vs today)
- Realistic safety margins
Characteristics:
- Delayed random repeat per repeater
- Small backoff windows
- No strict separation of client vs repeater timing behavior
Consequences:
- Many collisions among repeaters
- Many collisions among clients
- Channel saturates quickly
- Effective throughput: ~15–25 msgs/min before it gets ugly
- Practical user counts:
- 1 msg/min → ~15–25 users
- 1 msg/5 min → ~75–125 users
- SOR compresses repeater transmissions into one repeat window.
- ARB aggressively spreads client attempts in time.
- Throughput: ~60–80 msgs/min realistic.
- Practical user counts:
- 1 msg/min → ~60 users
- 1 msg/2 min → ~100–120 users
- 1 msg/5 min → ~300–500 users
- 1 msg/10 min → ~600–1000+ users
This is roughly a 3× improvement in usable simultaneous user capacity at realistic emergency messaging rates.
- None beyond standard single-radio LoRa nodes.
SOR and ARB are purely MAC/firmware behaviors:
- SOR just defines how repeaters schedule their retransmissions (one repeat window).
- ARB just defines how clients handle contention (large randomized backoff).
- Multi-radio infrastructure nodes (e.g., separate “backbone” and “access” channels).
- Multiple data channels with a control-plane channel (“Reggie multi-channel system”).
- TDMA inside a cell.
- Region/cell-aware routing.
These can further increase capacity but are outside the scope of this base proposal.
No.
SOR runs entirely on one channel (same frequency, SF, BW, CR).
The improvement comes from compressing repeater transmissions into one repeat window, not from adding channels.
Not exactly.
- It is co-channel interference.
- But when one repeater is significantly stronger at a receiver, capture effect lets that receiver decode the strongest packet.
- Where signal strengths are close and decoding fails, performance will be similar to or slightly worse than today for that specific receiver, but network-wide airtime use is still much lower.
- Overall, we trade some pathological-local cases for much better average behavior.
ARB adds seconds of latency, yes. That is intentional.
- This is acceptable for EP messaging, where 2–10 seconds delay is fine.
- It would be annoying for high-rate interactive chat, but that is not the design goal.
- If someone wants low-latency real-time chat, LoRa is the wrong tool.
No.
- The theoretical per-channel airtime bound is still obeyed.
- T_pkt and frequency are unchanged.
- We simply waste less airtime on random repeated packets and collisions.
- Replacing (N+1) packets with 2 packets for the same coverage is exactly how we get a 1.5–3× improvement in many topologies.
The Reggie Mesh proposal for a single-channel LoRa network:
-
Simultaneous Offset Repeat (SOR)
- All repeaters repeat a given packet in one shared repeat window at a fixed offset from the original transmission.
- Airtime per message goes from (N+1) × T_pkt → 2 × T_pkt.
- This yields roughly 1.5–3× better airtime efficiency in realistic topologies.
-
Aggressive Random Backoff (ARB)
- Clients use a 3–6 second randomized backoff window when the channel is busy.
- Collisions between origins are greatly reduced.
- Latency increases but remains acceptable for emergency use.
-
Combined effect
- Moves practical single-channel capacity from:
- ~15–25 msgs/min → ~60–80 msgs/min
- Supports:
- ~60 active users at 1 msg/min, or
- ~300–500 users at 1 msg/5 min, or
- ~600–1000+ users at 1 msg/10 min
- Moves practical single-channel capacity from:
-
No hardware changes required
- Works with existing LoRa radios in principle.
- All changes are in firmware and MAC behavior.
This is not magic, not CDMA, and not a violation of Shannon.
It is simply better use of the same airtime, tuned for emergency preparedness traffic rather than constant chat.