Un Bluetooth Beacon seul n’est qu’une radio qui crie des paquets dans l’air. La vraie valeur — position, présence, télémétrie — est créée par la couche gateway et edge qui écoute, filtre et transmet ces paquets. Cet article explique comment architecturer un pipeline Beacon→gateway, où placer le calcul et comment garder bande passante et latence raisonnables à l’échelle.

Ce que fait réellement le gateway

Un gateway est un scanner BLE avec uplink. Pour chaque paquet publicitaire reçu il doit :

1. Dédupliquer (même MAC + séquence peut arriver sur 3 gateways qui se chevauchent).

2. Horodater avec une horloge synchronisée (NTP/PTP) pour que la trilatération reste cohérente.

3. Normaliser le RSSI (chaque radio a un gain de front-end différent).

4. Agréger par tag sur une fenêtre (ex. 1 s) en un seul enregistrement.

5. Transmettre via l’uplink.

Edge vs cloud

Tout faire dans le cloud revient à envoyer chaque paquet brut. Avec 500 tags à 1 Hz tu génères ~500 paquets/s. Les envoyer entre sites est du gaspillage. Le gateway edge doit émettre *un enregistrement agrégé par tag par seconde*, divisant le volume par le nombre de gateways entendant chaque tag.

Flux de données

<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

Mathématiques du filtrage edge

Clé de déduplication = (mac, seq). Garde un ensemble glissant ; écarte les répétitions dans T_dedup (environ 5 s). Lissage RSSI par tag :

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

Cela élimine les pics d’un seul paquet qui simuleraient un saut de position.

Protocole d’uplink

MQTT est le choix naturel : les gateways publient sur tecksay///beacon/, le cloud s’abonne une fois. HTTP POST est plus simple à déboguer mais nécessite une connexion keep-alive. CoAP convient aux gateways très contraints.

Mathématiques de la bande passante

500 tags, 1 Hz, chaque tag entend par 2,5 radios en moyenne, payload 120 B après agrégation :

  • Brut vers le cloud : 500 × 120 B × 2,5 = 150 KB/s (dupliqué, gaspillé).
  • Agrégé en edge : 500 × 120 B = 60 KB/s, une seule copie.

Cet économie de 2,5× croît avec la densité de gateways.

Budget de latence

Événement sur le tag → le gateway l’entend dans un intervalle de publicité (≤1 s) → agrégation edge 1 s → saut MQTT ~50 ms → dashboard. Bout en bout typiquement 2–3 s, dominé par l’intervalle de publicité, pas par le réseau.

Tampon en cas de chute du cloud

Les gateways ne doivent pas perdre de données. Garde un tampon circulaire local (ex. dernière 1 h). À la reconnexion, rejoue avec backoff exponentiel. Marque les enregistrements rejoués pour que le cloud déduplique par (gateway, seq).

Sécurité

  • TLS pour l’uplink ; n’envoie pas le RSSI en clair hors du site.
  • Jeton d’auth par gateway (pas de secret partagé).
  • Signe chaque enregistrement `sig = HMAC(k, payload)` pour qu’un gateway usurpé ne puisse pas injecter de fausses positions.
  • Rotate les clés de gateway selon un calendrier.

Topologie de déploiement

Chevauche les gateways à 20–30% pour que chaque tag soit entendu par ≥2 radios (nécessaire à la trilatération). Plus de chevauchement = meilleure précision mais plus de charge de déduplication. Le handoff entre gateways est implicite : le cloud fusionne simplement les derniers enregistrements des radios ayant entendu le tag.

Checklist

  • [ ] Horloge de gateway synchronisée (NTP, ±50 ms)
  • [ ] Clé de déduplication = mac+seq, T_dedup réglé
  • [ ] RSSI lissé en edge
  • [ ] Enregistrement agrégé 1 Hz, pas de paquets bruts
  • [ ] MQTT avec hiérarchie de topics par site
  • [ ] Tampon circulaire local + rejeu en panne
  • [ ] TLS + enregistrements signés par gateway
  • [ ] Chevauchement des gateways 20–30%