Warum die Wahl des Broadcast-Protokolls wichtig ist
Jeder Bluetooth Beacon sendet kontinuierlich ein kleines Advertising-Paket — typischerweise 30 Byte oder weniger — das Empfänger zur Identifikation und Entfernungsmessung nutzen. iBeacon (Apple, 2013) und Eddystone (Google, 2015) sind die dominierenden Protokolle.
Paketformat-Vergleich
| Feld | iBeacon | Eddystone-UID |
|---|---|---|
| Präambel | 9 Byte | 8 Byte |
| UUID | 16 Byte (128-Bit) | 10 Byte (Namespace) |
| Instanz / Major+Minor | 4 Byte | 6 Byte (Instance) |
| Tx Power | 1 Byte (bei 1 m) | 1 Byte (bei 0 m) |
| Gesamtpayload | 30 Byte | 20 Byte |
iBeacon nutzt 16-Byte-UUID plus Major/Minor (je 2 Byte). Eddystone-UID nutzt 10-Byte-Namespace und 6-Byte-Instance — mehr Instanzgranularität, weniger Namespace-Raum.
Eddystones drei Frame-Typen
- Eddystone-UID: Geräteidentifikation — funktional äquivalent zu iBeacons UUID/Major/Minor.
- Eddystone-TLM: Telemetrie — Batteriespannung, Temperatur und Advertising-Zähler in 14 Byte. Fleet-Monitoring ohne Verbindung.
- Eddystone-URL: Komprimierte URL (bis 17 Byte) für Physical Web. Keine App nötig.
Typische Konfiguration: UID alle 100 ms, TLM alle 10 s. Zusätzlicher Energieaufwand vernachlässigbar.
Entfernungsmessung: Tx-Power-Kalibrierung
RSSI(d) = TxPower - 10·n·log10(d)
n = Pfadverlustexponent (2,0 Freiraum, 2,7–3,5 Indoor). Kritisch: iBeacon gibt Tx Power bei 1 m, Eddystone bei 0 m. Kontrollierte Tests mit 50 Beacons (n ≈ 2,8): Medianfehler 0,9 m bei beiden Protokollen.
Sicherheit: Eddystone-EID
Eddystone-EID rotiert den Identifier per zeitbasierter Krypto-Funktion. 8-Byte-EID-Wert ändert sich alle paar Sekunden — Spoofing und Replay ohne Schlüssel unpraktikabel. iBeacon hat keinen Sicherheitsmechanismus; statische UUID/Major/Minor sind trivial klonbar.
| Sicherheitsfunktion | iBeacon | Eddystone-EID |
|---|---|---|
| Identifikatorrotation | Keine (manuell) | Automatisch, zeitbasiert |
| Krypto-Primitiv | — | AES-128 ECB |
| Replay-Resistenz | Nein | Ja (ephemer) |
| Schlüsselverteilung | N/A | Provisioning über sicheren Kanal |
Stromverbrauch
nRF52832 bei 0 dBm:
| Intervall | iBeacon (30B) | Eddystone-UID (20B) | UID+TLM Rotation |
|---|---|---|---|
| 100 ms | 6,8 µA | 5,9 µA | 6,1 µA |
| 500 ms | 1,8 µA | 1,6 µA | 1,7 µA |
| 1000 ms | 1,1 µA | 0,9 µA | 1,0 µA |
Eddystone-UID spart ca. 0,5–0,9 µA. TLM addiert nur 0,1–0,2 µA. Bei CR2477 (1000 mAh) entspricht die Differenz ca. 2 Monaten Batterielebensdauer.
Plattformunterstützung
iBeacon: nativ iOS (Core Location ohne Drittanbieter-SDK). Android 12+ nativ. Eddystone: nativ Android (Nearby API), kein natives iOS — Core Bluetooth für 0xFEAA-Scan und Frame-Parsing erforderlich. Diese Asymmetrie ist der Hauptgrund für Dual-Protokoll-Betrieb.
Dual-Protokoll-Broadcasting
Die meisten modernen Bluetooth Beacon unterstützen iBeacon + Eddystone-Rotation. Häufiger Kompromiss: 100 ms iBeacon + 100 ms Eddystone-UID + 1000 ms TLM.
Entscheidungsrahmen
| Anforderung | Empfohlenes Protokoll |
|---|---|
| Nur iOS, Regionsüberwachung | iBeacon |
| Nur Android, Physical Web/Nearby | Eddystone |
| Fleet-Monitoring | Eddystone + TLM |
| Anti-Spoofing | Eddystone-EID |
| Cross-Plattform, maximale Reichweite | Dual-Protokoll |
| URL-basiertes Engagement, keine App | Eddystone-URL |
Wahl nach Plattformziel, Sicherheitsanforderungen und Telemetriebedarf. Im Zweifel: Dual-Protokoll kostet kaum Energie und bietet breiteste Kompatibilität.