Ein Standard-Bluetooth Beacon sendet nur. Er wacht per Timer auf, sendet ein Advertising-Paket und schläft wieder. Dieses Modell setzt voraus, dass ein Gateway oder Smartphone in Funkreichweite ist, um es zu hören. Diese Annahme bricht sofort, sobald man ein 40 000 m² großes Lager, ein mehrstöckiges Krankenhaus, einen Güterhof oder einen Tunnel hat — überall dort, wo ein einzelnes Gateway nicht jede Ecke sieht. Die günstige Lösung ist ein Relay-Beacon: ein Knoten, der die Pakete anderer Beacons empfängt und erneut sendet und so das Signal zu einem tatsächlich erreichbaren Gateway hoppt.
Dieser Artikel behandelt, was ein Relay-Beacon wirklich ist, warum das naive Design „jeder wiederholt alles” explodiert, und die Engineering-Regeln, die ein Relay-Netz stabil halten.
Was ein Relay-Beacon tatsächlich tut
Ein Relay-Beacon ist ein Dual-Role-Gerät. Anders als ein reiner Sender läuft es im Observer-Modus (Scanner), um Advertising-Pakete zu empfangen, und wechselt dann in den Broadcaster-Modus, um sie erneut zu senden. Drei klare Aufgaben:
1. Scannen der drei Advertising-Kanäle (37/38/39) nach Paketen von Ziel-Beacons oder Upstream-Relays.
2. Entscheiden, ob ein Paket weitergeleitet wird (Deduplizierung, Hop-Limit, Signalstärke-Regeln).
3. Wiederaussenden eines (meist identischen, manchmal angereicherten) Pakets auf den Advertising-Kanälen.
Das Relay dekodiert die Application-Payload nicht wie ein Gateway. Es leitet normalerweise die rohe Advertising-PDU — MAC, Payload und den selbst gemessenen RSSI — unverändert weiter. Genau das ist der Punkt: es ist ein dummes, schnelles Verlängerungsglied, kein Senke.
Relay im Vergleich zu Alternativen
| Rolle | RX nötig? | TX nötig? | Schläft? | In der Route? | Typ. Leistung |
|---|---|---|---|---|---|
| Standard-Beacon | Nein | Ja | Ja (99%+) | Nein | 5–50 µA Mittel |
| Relay-Beacon | Ja | Ja | Selten | Ja | 1–10 mA Mittel |
| BLE-Mesh-Knoten | Ja | Ja | Nein (Relay) | Ja | 2–15 mA Mittel |
| Gateway | Ja | Evtl. | Nein | Ende | Netz / PoE |
Die harte Zeile in dieser Tabelle ist die Leistung. Ein reiner Sende-Beacon ist ~0,5–2 ms pro 100 ms Advertising-Intervall auf der Funkeinheit und schläft den Rest, im Mittel einstellige µA. Ein Relay muss das Funkmodul fast durchgehend in RX halten, um nichts zu verpassen, und RX eines Cortex-M4-BLE-SoC verbraucht ~4–6 mA. Bei 5 mA durchgehend sind das 120 mAh pro Tag — eine CR2032 (220 mAh) ist in unter zwei Tagen leer. Echte Relay-Knoten hängen am Netz, PoE, USB oder mindestens an einer D-Zelle / Li-SOCl₂-Zelle mit Mehrjahres-Ziel.
Die Broadcast-Storm-Falle
Der häufigste Relay-Fehler ist die Flut. Wenn jedes Relay alles weiterleitet, was es hört, und jedes andere Relay das wieder weiterleitet, gerät das Netz in exponentielle Verstärkung:
- Beacon A sendet 1 Paket.
- Relays B und C hören es und senden je 1 → 2 Pakete in der Luft.
- B und C hören die Wiederholungen des anderen, und D/E hören diese → 4, dann 8, bis der Kanal sättigt.
Bei N Relays, die je mit 10 Hz weiterleiten, ist die Paketrate in der Luft nicht 10 Hz, sondern 10 × N × (N−1) / etwas Hässliches. Advertising-Kanäle sind 1 Mbit/s, aber ein BLE-Advertising-Paket dauert ~50–350 µs plus 150 µs Inter-Frame; real hält ein Kanal nur einige hundert Pakete/s, bevor Kollisionen dominieren. Ein Sturm legt das ganze Segment lahm.
Kontrollregeln gegen den Sturm
Jede Relay-Firmware in Produktion implementiert vier Mechanismen:
1. Deduplizierungs-Cache. Halte einen Ringpuffer kürzlich gesehener (TxAdd-MAC, SeqNum)-Paare — etwa 64–256 Einträge. Ist der Schlüssel des Pakets im Cache, verwerfe es. Das allein stoppt 90 % der Schleifen.
2. Hop-Zähler / TTL. Stemple ein Hop-Feld in die Payload (oder nutze ein ungenutztes Byte). Inkrementiere bei jedem Relay. Verwerfe bei hop ≥ H (meist 4–8). Das begrenzt den Netzdurchmesser und verhindert Endlosschleifen zwischen A↔B.
3. Hold-off / Jitter. Nach der Weiterleit-Entscheidung warte zufällig 20–100 ms vor dem Senden. Das desynchronisiert Relays, damit sie nicht alle im selben Slot feuern, und gibt dem Deduplizierungs-Cache Zeit, sich bei Nachbarn zu füllen.
4. RSSI-Gatter (selektives Relay). Leite nur Pakete weiter, deren gemessener RSSI unter einem Schwellenwert liegt (z. B. < −75 dBm). Starke Pakete sind schon nahe einem Gateway und brauchen kein Relay; schwache schon. Das schneidet redundante Wiederholungen um 50–80 %.
Minimaler Entscheidungs-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 # schon stark genug
pkt.hop += 1
schedule_tx(pkt, random_delay(20,100))
Latenz und Verlust über Hops
Store-and-Forward-Relay fügt pro Hop Latenz hinzu. Bei 100 ms Hold-off-Fenster und ~5 ms Verarbeitung kostet ein Hop etwa 25–105 ms (Mittel ~60 ms). Drei Hops addieren also 150–300 ms Latenz auf ein Positions-Update. Für Asset-Tracking in Ordnung, für Echtzeitsteuerung tödlich.
Verlust akkumuliert ebenfalls. Liefert ein einzelner Relay-Hop mit Wahrscheinlichkeit p, liefert ein N-Hop-Pfad mit p^N. Bei p = 0,9 (im lauten Lager schon optimistisch) → 4 Hops 0,66. Man muss entweder Relays überdimensionieren (dichter als Abdeckung nötig) oder Lücken akzeptieren. Daher wird Relay-Tiefe in der Praxis auf 3–5 Hops begrenzt.
Echte Reichweiten-Mathematik
Ein Relay verlängert die Reichweite linear mit der Hop-Zahl, aber jeder Hop ist durch den schwächeren seiner beiden Links begrenzt. Innen liegt ein einzelner BLE-Hop oft bei 15–40 m durch Wände; außen bei Sichtlinie 80–150 m. Also:
- 1 Relay: erreicht ~2× Einzelhop ≈ 30–80 m Innen um eine Funklücke
- 3 Relays: ~4× Einzelhop, aber auf obige Latenz/Verlust achten
- Praktisches Limit: ~5 Hops, bevor Verlust/Latenz es unbrauchbar machen
Reichweite hängt auch von Antenne, TX-Leistung und Kanal ab. Relays an Flurknoten und Treppenhäusern übertreffen Relays, die man in offene Räume wirft.
Hardware- und Firmware-Hinweise
- SoC: Man braucht ein Dual-Role-Teil. nRF52840 / nRF5340 und ESP32 (HCI-Modus) können scannen und advertisieren. Ein reiner Sende-nRF52810 kann nicht relayen.
- Scan-Fenster vs. Intervall: Um ein Beacon mit 100 ms Intervall zu fassen, muss die Scan-Fenstersumme über die drei Kanäle mindestens die Luftzeit des Beacons erreichen. 100 % Duty-Scan (Fenster = Intervall) verpasst nichts, verbrennt aber Maximalleistung; 30–50 % Duty handelt Verlust gegen Batterie.
- Kanalrotation: BLE advertist auf ch 37/38/39. Ein Relay muss alle drei scannen; eine überspringen kostet ein Drittel der Pakete.
- Taktdrift: Nutzen Relays stromsparende RC-Oszillatoren, driftet das Scan-Timing und die Fenster rutschen. TCXO oder eine kalibrierte Sleep-Clock reduziert verpasste Pakete.
Sicherheit
Ein Relay ist eine Vertrauensgrenze. Da es rohe PDUs weiterleitet, kann ein Angreifer:
- Injizieren: gefälschte Beacons, die direkt zum Gateway relayed werden (fake Asset-Positionen).
- Replay: ein gefangenes Paket wiederholt senden, um einen Sturm oder Fake-Bewegung zu erzeugen.
- Unterdrücken: den Kanal fluten, damit echte Pakete kollidieren.
Gegenmaßnahmen: Beacon-Payload signieren oder verschlüsseln (und das Gateway, nicht das Relay, prüft), Rate-Limit pro MAC am Relay, und Whitelist vertrauenswürdiger Beacon-MAC-Präfixe. Relay-Knoten selbst sollten physisch gesichert und, wo möglich, im Netz authentifiziert sein.
Wann man kein Relay nutzen sollte
Kann man alle ~30 m ein Gateway setzen, tu das — Gateways sind simpler und beenden die Kette. Relays gewinnen nur, wenn man Ethernet/PoE in jede Ecke zu ziehen unmöglich ist (Denkmalgebäude, Höfe, Tunnel) und Abdeckung, nicht Hochpräzision, nötig ist. Für hochpräzises RTLS fügen Relays Multipath und Ambiguität hinzu; lieber mehr Gateways oder AoA.
Fazit
Ein Bluetooth Beacon-Relay ist der günstigste Weg, Abdeckung über den Funkhorizont des Gateways zu schieben, aber es ist ein Leistungs- und Flut-Problem, verkleidet als Reichweiten-Problem. Kriege den Deduplizierungs-Cache, das Hop-Limit, den Hold-off-Jitter und das RSSI-Gatter hin, begrenze die Tiefe auf 3–5 Hops, und speise den Knoten aus dem Netz oder einer großen Zelle. Falsch gemacht, legt es das Segment lahm, das es retten sollte.
