Ein einzelner Bluetooth Beacon ist nur ein Funkgerät, das Pakete in die Luft schreit. Der eigentliche Wert — Position, Anwesenheit, Telemetrie — entsteht in der Gateway- und Edge-Schicht, die diese Pakete empfängt, filtert und weiterleitet. Dieser Artikel beschreibt, wie man eine Beacon→Gateway-Pipeline aufbaut, wo man die Rechenleistung platziert und wie man Bandbreite und Latenz in großem Maßstab im Griff behält.

Was das Gateway tatsächlich tut

Ein Gateway ist ein BLE-Scanner mit Uplink. Für jedes Werbepaket, das es hört, muss es:

1. Deduplizieren (gleiche MAC + Sequenz kann bei 3 überlappenden Gateways ankommen).

2. Zeitstempel mit synchronisierter Uhr (NTP/PTP), damit die Trilateration konsistent bleibt.

3. RSSI normalisieren (jedes Funkmodul hat unterschiedliche Front-End-Verstärkung).

4. Pro Tag über ein Fenster (z. B. 1 s) zu einem Datensatz aggregieren.

5. Über den Uplink weiterleiten.

Edge vs. Cloud

Alles in der Cloud zu machen bedeutet, jedes Rohpaket zu senden. Bei 500 Tags mit 1 Hz erzeugst du ~500 Pakete/s. Das site-übergreifend zu schicken ist verschwenderisch. Das Edge-Gateway sollte *einen aggregierten Datensatz pro Tag pro Sekunde* ausgeben und so das Volumen um die Zahl der Gateways teilen, die jeden Tag hören.

Datenfluss

<strong><a href="https://www.tecksay.com/category/products/bluetooth-beacon/">Beacon</a></strong> ADV ──▶ Gateway (BLE scanner)
├─ dedupe + timestamp
├─ RSSI smoothing (Kalman / moving avg)
└─ aggregate 1 Hz record
│
▼
MQTT broker  (topic: site/floor/tag/uid)
│
▼
Cloud ingestion ──▶ dashboard / alerting

Edge-Filter-Mathematik

Dedupe-Schlüssel = (mac, seq). Halte eine gleitende Menge; verwirf Wiederholungen innerhalb T_dedup (ca. 5 s). RSSI-Glättung pro Tag:

rssi_smoothed = α·rssi_new + (1-α)·rssi_prev     (α ≈ 0.3)

Das entfernt Einzelpaket-Spitzen, die einen Positionssprung vortäuschen würden.

Uplink-Protokoll

MQTT ist die naheliegende Wahl: Gateways publizieren auf tecksay///beacon/, die Cloud abonniert einmal. HTTP POST ist leichter zu debuggen, braucht aber eine Keep-Alive-Verbindung. CoAP passt für sehr eingeschränkte Gateways.

Bandbreiten-Mathematik

500 Tags, 1 Hz, jeder Tag im Schnitt von 2,5 Radios gehört, Nutzlast 120 B nach Aggregation:

  • Roh zur Cloud: 500 × 120 B × 2,5 = 150 KB/s (dupliziert, verschwenderisch).
  • Aggregiert im Edge: 500 × 120 B = 60 KB/s, eine Kopie.

Diese 2,5× Ersparnis wächst mit der Gateway-Dichte.

Latenz-Budget

Ereignis am Tag → Gateway hört es innerhalb eines Werbeintervalls (≤1 s) → Edge-Aggregation 1 s → MQTT-Hop ~50 ms → Dashboard. Ende-zu-Ende typischerweise 2–3 s, dominiert vom Werbeintervall, nicht vom Netz.

Pufferung bei Cloud-Ausfall

Gateways dürfen keine Daten verlieren. Halte einen lokalen Ringpuffer (z. B. letzte 1 h). Bei Reconnect Wiedergabe mit exponentiellem Backoff. Markiere wiedergegebene Datensätze, damit die Cloud nach (gateway, seq) deduplizieren kann.

Sicherheit

  • TLS für den Uplink; sende RSSI nicht im Klartext außerhalb des Standorts.
  • Auth-Token pro Gateway (kein geteiltes Geheimnis).
  • Signiere jeden Datensatz `sig = HMAC(k, payload)`, damit ein gefälschtes Gateway keine falschen Positionen einspeist.
  • Rotiere Gateway-Schlüssel nach Zeitplan.

Deployment-Topologie

Überlappe Gateways zu 20–30%, damit jeder Tag von ≥2 Radios gehört wird (nötig für Trilateration). Mehr Überlappung = bessere Genauigkeit, aber mehr Dedupe-Last. Handoff zwischen Gateways ist implizit: Die Cloud fusioniert einfach die neuesten Datensätze der Radios, die den Tag gehört haben.

Checkliste

  • [ ] Gateway-Uhr synchronisiert (NTP, ±50 ms)
  • [ ] Dedupe-Schlüssel = mac+seq, T_dedup gesetzt
  • [ ] RSSI im Edge geglättet
  • [ ] Aggregierter 1-Hz-Datensatz, nicht Rohpakete
  • [ ] MQTT mit Topic-Hierarchie pro Standort
  • [ ] Lokaler Ringpuffer + Wiedergabe bei Ausfall
  • [ ] TLS + pro Gateway signierte Datensätze
  • [ ] 20–30% Gateway-Überlappung