A standard Bluetooth Beacon just broadcasts. It wakes from a timer, pushes an advertising packet, and goes back to sleep. The model assumes a gateway or smartphone is within radio range to hear it. That assumption breaks the moment you have a 40,000 m² warehouse, a multi-floor hospital, a freight yard, or a tunnel — anywhere a single gateway can’t see every corner. The cheap fix is a relay beacon: a node that listens for other beacons’ packets and re-transmits them, hopping the signal toward a gateway that is actually reachable.
This article is about what a relay beacon really is, why the naive “everyone repeats everything” design explodes, and the engineering rules that keep a relay network stable.
What a relay beacon actually does
A relay beacon is a dual-role device. Unlike a pure broadcaster, it runs in observer (scanner) mode to receive advertising packets, then switches to broadcaster mode to send them again. Three distinct jobs:
1. Scan the three advertising channels (37/38/39) for packets from target beacons or upstream relays.
2. Decide whether a packet should be forwarded (dedup, hop-limit, signal-strength rules).
3. Re-broadcast a (usually identical, sometimes enriched) packet on the advertising channels.
The relay does not decode an application payload the way a gateway does. It typically forwards the raw advertising PDU — MAC, payload, and RSSI it measured — unchanged. That is the whole point: it is a dumb, fast extender, not a sink.
Relay vs the alternatives
| Role | RX needed? | TX needed? | Sleeps? | Sits in path? | Typical power |
|---|---|---|---|---|---|
| Standard beacon | No | Yes | Yes (99%+) | No | 5–50 µA avg |
| Relay beacon | Yes | Yes | Rarely | Yes | 1–10 mA avg |
| BLE Mesh node | Yes | Yes | No (relay) | Yes | 2–15 mA avg |
| Gateway | Yes | Maybe | No | Terminus | Mains / PoE |
The brutal line in that table is power. A transmit-only beacon spends ~0.5–2 ms per 100 ms advertising interval actually on the radio and sleeps the rest, averaging single-digit µA. A relay must keep the radio in RX almost continuously to avoid missing packets, and RX on a Cortex-M4 BLE SoC runs ~4–6 mA. At 5 mA continuous that is 120 mAh per day — a CR2032 (220 mAh) dies in under two days. Real relay nodes are mains, PoE, USB, or at minimum a D-cell / Li-SOCl₂ pack with a multi-year target.
The broadcast storm trap
The single most common relay failure is the flood. If every relay forwards every packet it hears, and every other relay then forwards that, the network enters exponential amplification:
- Beacon A sends 1 packet.
- Relays B and C both hear it and each send 1 → 2 packets on air.
- B and C hear each other’s repeats, and D/E hear those → 4, then 8, then the channel saturates.
With N relays each repeating at 10 Hz, the on-air packet rate is not 10 Hz, it is 10 × N × (N−1) / something ugly. Advertising channels are 1 Mbit/s but a BLE advertising packet is ~50–350 µs plus 150 µs inter-frame; realistically a channel sustains only a few hundred packets/sec before collisions dominate. A storm collapses the whole segment.
Control rules that prevent the storm
Every production relay firmware implements four mechanisms:
1. Deduplication cache. Keep a ring buffer of recently seen (TxAdd MAC, SeqNum) pairs — say 64–256 entries. If a packet’s key is in the cache, drop it. This alone stops 90% of loops.
2. Hop counter / TTL. Stamp a hop field in the payload (or reuse an unused byte). Increment on each relay. Drop at hop ≥ H (typically 4–8). This bounds the network diameter and prevents infinite loops between A↔B.
3. Hold-off / jitter. After deciding to forward, wait a random 20–100 ms before transmitting. This de-synchronizes relays so they don’t all fire on the same slot, and gives the dedup cache time to populate across neighbors.
4. RSSI gating (selective relay). Only forward packets whose measured RSSI is below a threshold (e.g., < −75 dBm). Strong packets are already near a gateway and don’t need relaying; weak ones do. This cuts redundant repeats by 50–80%.
A minimal decision pseudocode:
on_packet(pkt):
if pkt.hop >= MAX_HOP: drop
if (pkt.mac, pkt.seq) in dedup_cache: drop
dedup_cache.add((pkt.mac, pkt.seq))
if pkt.rssi > RSSI_GATE: drop # already strong enough
pkt.hop += 1
schedule_tx(pkt, random_delay(20,100))
Latency and loss across hops
Store-and-forward relay adds delay per hop. With a 100 ms hold-off window and ~5 ms processing, one hop costs roughly 25–105 ms (mean ~60 ms). Three hops therefore add 150–300 ms of latency to a location update. That is fine for asset tracking but fatal for real-time control.
Packet loss also compounds. If a single relay hop delivers with probability p, an N-hop path delivers with p^N. At p = 0.9 (already optimistic in a noisy warehouse), 4 hops → 0.66. You must either over-deploy relays (denser than pure coverage needs) or accept gaps. This is why relay depth is usually capped at 3–5 hops in practice.
Real range math
A relay extends range linearly with hop count, but each hop is limited by the weaker of its two links. Indoor, a single BLE hop is often 15–40 m through walls; outdoor line-of-sight 80–150 m. So:
- 1 relay: reach ~2× single-hop ≈ 30–80 m indoor around a dead zone
- 3 relays: ~4× single-hop, but watch latency and loss above
- Practical ceiling: ~5 hops before loss/latency make it useless
Range also depends on antenna, Tx power, and channel. Relays placed at corridor junctions and stairwells outperform relays thrown in open rooms.
Hardware and firmware notes
- SoC: You need a dual-role part. nRF52840 / nRF5340 and ESP32 (HCI mode) both scan and advertise. A beacon-only nRF52810 cannot relay.
- Scan window vs interval: To catch a beacon advertising at 100 ms interval, the relay scan window must sum across the three channels to ≥ the beacon’s on-air time. A 100% duty scan (window = interval) never misses but burns max power; a 30–50% duty scan trades some miss rate for battery.
- Channel rotation: BLE advertises on ch 37/38/39. A relay must scan all three; skipping one drops a third of packets.
- Clock drift: If relays use low-power RC oscillators, scan timing drifts and windows slip. TCXO or a calibrated sleep clock reduces missed packets.
Security
A relay is a trust boundary. Because it forwards raw PDUs, an attacker can:
- Inject forged beacons that get relayed straight to the gateway (spoofed asset positions).
- Replay a captured packet repeatedly to create a storm or fake movement.
- Suppress by flooding the channel so real packets collide.
Mitigations: sign or encrypt beacon payloads (and have the gateway verify, not the relay), rate-limit per MAC at the relay, and whitelist trusted beacon MAC prefixes. Relay nodes themselves should be physically secured and, where possible, authenticated to the network.
When not to use a relay
If you can place a gateway every ~30 m, do that — gateways are simpler and terminate the chain. Relays win only when pulling Ethernet/PoE to every corner is impossible (heritage buildings, yards, tunnels) and you need coverage, not high fidelity. For high-accuracy RTLS, relays add multipath and ambiguity; prefer more gateways or AoA.
Bottom line
A Bluetooth Beacon relay is the cheapest way to push coverage past a gateway’s radio horizon, but it is a power and flooding problem disguised as a range problem. Get the dedup cache, hop limit, hold-off jitter, and RSSI gate right, cap depth at 3–5 hops, and feed the node from mains or a big cell. Done wrong, it takes down the segment it was meant to save.
