Pourquoi le choix du protocole de diffusion est important
Chaque Bluetooth Beacon transmet en continu un petit paquet publicitaire — généralement 30 octets ou moins — que les récepteurs à proximité utilisent pour identifier et mesurer la distance. iBeacon (Apple, 2013) et Eddystone (Google, 2015) sont les deux protocoles dominants.
Comparaison du format de paquet
| Champ | iBeacon | Eddystone-UID |
|---|---|---|
| Préambule | 9 octets | 8 octets |
| UUID | 16 octets (128 bits) | 10 octets (Namespace) |
| Instance / Major+Minor | 4 octets | 6 octets (Instance) |
| Tx Power | 1 octet (à 1 m) | 1 octet (à 0 m) |
| Charge utile totale | 30 octets | 20 octets |
iBeacon divise son identité en un UUID de 16 octets plus Major/Minor (2 octets chacun). Eddystone-UID utilise un Namespace de 10 octets et une Instance de 6 octets — plus de granularité d’instance mais moins d’espace de namespace.
Les trois types de trame Eddystone
- Eddystone-UID : Identification de l’appareil — fonctionnellement équivalent à l’UUID/Major/Minor d’iBeacon.
- Eddystone-TLM : Télémétrie — diffuse la tension de batterie, la température et le compteur de publicité en 14 octets. Surveillance de flotte sans connexion.
- Eddystone-URL : Code une URL compressée (jusqu’à 17 octets) pour le Physical Web. Aucune app requise.
Configuration typique : UID toutes les 100 ms, TLM toutes les 10 s. Coût énergétique supplémentaire négligeable.
Précision de mesure : Calibration Tx Power
RSSI(d) = TxPower - 10·n·log10(d)
n = exposant de perte de trajet (2,0 espace libre, 2,7–3,5 intérieur). iBeacon spécifie Tx Power à 1 m, Eddystone à 0 m. Tests avec 50 balises (n ≈ 2,8) : erreur médiane 0,9 m pour les deux protocoles correctement calibrés.
Sécurité : Eddystone-EID
Eddystone-EID fait tourner l’identifiant via une fonction cryptographique basée sur le temps. La valeur EID de 8 octets change toutes les quelques secondes — usurpation et rejeu impossibles sans la clé. iBeacon n’a aucun mécanisme de sécurité intégré.
| Fonctionnalité | iBeacon | Eddystone-EID |
|---|---|---|
| Rotation d’identifiant | Aucune (manuelle) | Automatique, basée sur le temps |
| Primitive cryptographique | — | AES-128 ECB |
| Résistance au rejeu | Non | Oui (éphémère) |
| Distribution de clés | N/A | Provisionnement via canal sécurisé |
Consommation d’énergie
nRF52832 à 0 dBm :
| Intervalle | 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 économise ~0,5–0,9 µA vs iBeacon. TLM n’ajoute que 0,1–0,2 µA. Sur CR2477 (1000 mAh), la différence est ~2 mois d’autonomie.
Support de plateforme
iBeacon : natif iOS (Core Location sans SDK tiers). Android 12+ natif. Eddystone : natif Android (Nearby API), pas de support natif iOS — Core Bluetooth pour scanner 0xFEAA. Cette asymétrie explique l’utilisation fréquente des deux protocoles.
Diffusion double protocole
La plupart du matériel Bluetooth Beacon moderne supporte iBeacon + Eddystone en rotation. Compromis courant : 100 ms iBeacon + 100 ms Eddystone-UID + 1000 ms TLM.
Cadre de décision
| Exigence | Protocole recommandé |
|---|---|
| iOS uniquement, surveillance de région | iBeacon |
| Android uniquement, Physical Web/Nearby | Eddystone |
| Surveillance de flotte | Eddystone + TLM |
| Anti-usurpation requis | Eddystone-EID |
| Cross-plateforme, portée maximale | Double protocole |
| Engagement basé URL, sans app | Eddystone-URL |
Choisissez selon plateforme, sécurité et télémétrie. En cas de doute : le double protocole coûte presque rien en énergie et offre la compatibilité maximale.