Un BLE tag a saut unique atteint 10-30 metres de portee en interieur. Dans un entrepot de 20 000 m2, cela signifie des dizaines de passerelles pour une couverture totale. Les reseaux mesh inversent le modele : les tags relayent les paquets entre eux, etendant la portee saut par saut jusqu’a ce que les donnees atteignent une passerelle. BLE Mesh 1.0 (2017) a introduit le relay par flood gere ; Mesh 1.1 (2023) a ajoute le directed forwarding. Pour le suivi d’actifs, mesh resout trois problemes : extension de couverture sans cout proportionnel de passerelles, tolerance aux pannes via des chemins redondants et degradation progressive lorsque des tags individuels se deconnectent.
Cet article dissèque les reseaux mesh du point de vue des tags d’actifs alimentes par batterie. Nous couvrons les internals du protocole, la selection des noeuds relay, les calculs de budget d’energie, la latence et le debit, les limites de scalabilite de 100 a 5000+ noeuds, le provisionnement a grande echelle, l’architecture de securite et la comparaison des stacks de fabricants.
1. Pile de Protocole BLE Mesh
BLE Mesh fonctionne entierement sur les canaux d’advertising (37/38/39 a 2402/2426/2480 MHz) avec des PDU sans connexion. La pile a cinq couches :
| Couche | Fonction | Parametres Cles |
|---|---|---|
| Bearer | Transport sur ADV ou GATT | ADV: PDU 31 octets, 3 canaux; GATT: proxy, MTU 20 octets |
| Reseau | Adressage, relay, TTL | PDU 29 octets, TTL 7-bit, SEQ 24-bit, unicast 15-bit |
| Transport Inferieur | Segmentation, reassemblage | Segment 12 octets, ack 20s |
| Transport Superieur | Chiffrement app key | Chiffrement payload access, transMIC 4 octets |
| Access | Messages de modele, opcodes | Vendor 3 octets, SIG 2 octets |
La PDU reseau est compacte : 1 octet TTL, 3 octets SEQ (sequence 24-bit pour la protection contre les replays), 2 octets SRC, 2 octets DST et jusqu’a 12 octets de payload transport. La PDU entiere est chiffree avec la network key 128 bits. Les noeuds relay transferent les paquets sans dechiffrer le payload applicatif.
Pour les tags d’actifs, le bearer ADV est la seule option pratique. Les connexions GATT consomment 3-5 mA pendant les evenements de connexion, insoutenable pour les tags a pile bouton. Le mecanisme relay fonctionne exclusivement sur le bearer ADV.
2. Managed Flood : Comment Fonctionne le Relay
BLE Mesh utilise le relay par managed flood, pas de tables de routage. Chaque noeud avec la fonction relay activee retransmet les messages recus, soumis a trois controles :
- TTL (Time To Live) : Compteur 7-bit, decremente a chaque saut. Quand il atteint 0, le message s’arrete. TTL par defaut : 5-7 pour les entrepots, 10+ pour les campus.
- Cache de Messages : Chaque noeud stocke les messages recents vus, identifies par (SRC, SEQ). Minimum 2 entrees ; les implementations pratiques utilisent 32-256. Les messages dupliques sont silencieusement abandonnes, prevignant les boucles.
- Correspondance Network Key : Seuls les messages chiffres avec une network key connue sont relayes.
Timing de retransmission relay : apres avoir recu un message, le relay attend 3,5 ms (backoff fixe) plus 0-10 ms de delai aleatoire, puis retransmet sur les trois canaux d’advertising. Latence par saut : environ 4-15 ms.
Pourquoi managed flood au lieu du routage ? Les protocoles mesh traditionnels (Zigbee, Thread) utilisent des tables de routage qui necessitent de la memoire (8-16 octets par entree), des mises a jour periodiques de route (consommant de l’energie) et un temps de convergence quand la topologie change (secondes a minutes). Pour les tags d’actifs mobiles, la convergence des tables de routage est impraticable. Le managed flood evite les trois : pas d’etat de routage, pas de mises a jour de route, adaptation instantanee du chemin. Le cout est une duplication de messages et une utilisation de canal plus elevees.
3. Selection des Noeuds Relay pour Tags d’Actifs
Tous les tags ne devraient pas etre relay. La fonction relay ajoute 200-500 uA au courant moyen, catastrophique pour les tags a pile bouton. La strategie : designer les noeuds d’infrastructure comme relays, tandis que les tags d’actifs operent comme publieurs non-relay.
| Critere | Relay Eligible | Non-Relay |
|---|---|---|
| Source d’alimentation | Secteur ou grosse batterie | CR2032, CR2477 |
| Mobilite | Infrastructure fixe | Tags d’actifs mobiles |
| Position | Plafonds, couloirs, entrees | Aleatoire sur actifs |
| Environnement radio | RSSI stable (> -70 dBm) | Variable par mouvement |
Les deploiements de production utilisent 20-30 noeuds relay alimentes sur secteur pour la couverture de backbone mesh, tandis que 500-2000 tags d’actifs publient des donnees en tant que noeuds non-relay. Le ratio relay-vers-tag depend de l’echelle :
| Echelle | Relays | Tags | Ratio |
|---|---|---|---|
| Petit (2 000 m2) | 5-8 | 50-100 | ~10% |
| Moyen (10 000 m2) | 15-25 | 300-500 | ~5% |
| Grand (30 000 m2) | 40-60 | 1000-2000 | ~3% |
| Campus | 80-150 | 3000-5000 | ~2-3% |
4. Budget d’Energie : Relay vs Non-Relay
Tag Non-Relay (nRF52840)
| Etat | Courant | Intervalle | Moyenne |
|---|---|---|---|
| Sleep (retention RAM) | 1,5 uA | – | 1,5 uA |
| RC32K + RTC | 0,2 uA | – | 0,2 uA |
| Advertiser TX (+4 dBm) | 4,6 mA | 100 ms | 24,3 uA |
| Advertiser RX | 5,2 mA | 100 ms | 23,4 uA |
| Lecture capteur (SHT40) | 0,9 mA | 10 s | 0,18 uA |
| Total | – | – | ~49,6 uA |
CR2032 (175 mAh utile), intervalle 100 ms :
Duree de vie = 175 000 uAh / 49,6 uA = 3 528 h = 147 joursIntervalle 1 seconde (mode basse consommation) :
Total moyen = 6,5 uA
Duree de vie = 175 000 / 6,5 = 26 923 h = 3,1 ansTag Relay (nRF52840, scan continu)
| Etat | Courant | Duty | Moyenne |
|---|---|---|---|
| Sleep | 1,5 uA | – | 1,5 uA |
| Scanner RX (3 canaux) | 5,2 mA | 30% | 1 560 uA |
| Relay TX | 4,6 mA | 0,5% | 23 uA |
| Advertising propre | 4,6 mA | 0,05% | 2,3 uA |
| Total | – | – | ~1 592 uA = 1,59 mA |
CR2032 : 175 000 / 1 592 = 110 heures = 4,6 jours (impraticable)
4x AA (2 500 mAh) : 2 500 000 / 1 592 = 1 571 h = 65 jours
Secteur : illimite
Conclusion : les noeuds relay necessitent une alimentation externe. Les tags a pile bouton ne doivent jamais activer le relay. Les deploiements de production utilisent une infrastructure relay dediee alimentee par le secteur.
5. Latence et Debit des Messages
Latence par Saut
Chaque saut relay ajoute : traitement du recepteur (1-3 ms) + backoff relay (3,5 + 0-10 ms) + evenement advertising (1,1 ms) = 5-16 ms typique, 20 ms pire cas.
5 sauts : 25-80 ms typique, 100-150 ms pire cas
10 sauts : 50-160 ms typique, 200-300 ms pire casCongestion du Canal
| Charge (msgs/s) | Utilisation | Taux de Perte | Notes |
|---|---|---|---|
| 50 | ~1% | <0,1% | Propre |
| 200 | ~4% | 0,5-1% | Normal pour 500 noeuds |
| 500 | ~10% | 2-5% | Limite approche |
| 1000 | ~21% | 8-15% | Congestion |
| 2000 | ~42% | 25-40% | Non fiable |
Pour mesh de 500 noeuds, 5% relays, TTL=7, 1 msg/10s :
Original : 500 x 0,1 = 50 msgs/s
Amplification relay : x3,3
Total : 165 msgs/s, utilisation 3,4%, perte <0,5%A 1 msg/s (suivi en temps reel) :
Total : 1 650 msgs/s, utilisation 34%, perte 15-25% (subnetting requis)6. Analyse de Scalabilite
| Noeuds | Relays | TTL | Charge | Perte | P95 | Verdict |
|---|---|---|---|---|---|---|
| 100 | 5 | 5 | 33/s | <0,1% | 40 ms | Excellent |
| 500 | 25 | 7 | 165/s | 0,5% | 80 ms | Bon |
| 1000 | 50 | 7 | 330/s | 2-3% | 120 ms | Acceptable |
| 2000 | 100 | 10 | 660/s | 5-8% | 200 ms | Marginal |
| 5000 | 250 | 10 | 1650/s | 15-25% | 500 ms | Subnet requis |
| 5000 (5 subnets) | 250 | 7 | 330/sub | 2-3% | 120 ms | Bon |
Strategie de Subnetting
- Geographique : Un subnet par etage/batiment. Noeuds pont aux entrees.
- Fonctionnel : Un subnet par application. Reduit le trafic croise.
- Hierarchique : Subnet backbone (relay seulement, secteur) connectant les subnets de tags. Le plus scalable.
Chaque subnet supporte 32 767 adresses unicast. La vraie contrainte est l'utilisation du canal, pas l'espace d'adressage.
7. Directed Forwarding (Mesh 1.1)
Mesh 1.1 (2023) a introduit le directed forwarding : des chemins pre-calcules pour les messages unicast au lieu du managed flood. Seuls les noeuds sur le chemin transferent le message.
Avantages : 60-80% moins d'utilisation de canal pour le trafic unicast, 5000+ noeuds par subnet sans subnetting, 20-30% de latence en moins.
Compromis : memoire de table de routage (0,4-3,2 Ko RAM), convergence de chemin (2-10s lors de changement topologique), necessite stack Mesh 1.1.
Recommande : activer le directed forwarding sur les noeuds relay d'infrastructure fixe, maintenir le managed flood pour les tags mobiles.
8. Provisionnement a Grande Echelle
Le provisionnement assigne l'adresse unicast, la network key, l'app key et l'IV index. Utilise PB-ADV (3-8s par dispositif) ou PB-GATT (10-20s).
Provisionnement par lot avec sessions paralleles :
Sequentiel : 1000 x 5s = 83 minutes
Lot (10) : 8,3 minutes
Lot (20) : 4,2 minutesLimite pratique : 20 sessions paralleles avant que la congestion cause des echecs.
Allocation d'Adresses
| Plage | Objectif | Nombre |
|---|---|---|
| 0x0001-0x00FF | Provisionneurs | 255 |
| 0x0100-0x0FFF | Relay/infrastructure | 3 840 |
| 0x1000-0x7EFF | Tags d'actifs | 28 160 |
| 0x7F00-0x7FFF | Reserve | 256 |
9. Architecture de Securite
| Cle | Portee | Objectif |
|---|---|---|
| Device Key (128-bit) | Par dispositif, provisionneur seulement | Configuration, reset de noeud |
| Network Key (128-bit) | Par subnet, tous les noeuds | Chiffrement couche reseau |
| App Key (128-bit) | Par application | Couche access, donnees capteur |
Les noeuds relay transferent les messages avec la network key mais ne peuvent pas dechiffrer le payload applicatif. Un relay compromis obtient l'acces reseau mais pas aux donnees de capteur.
Mise a jour IV
Le SEQ 24-bit fournit la protection contre les replays. L'IV index (32-bit) s'incremente pour reinitialiser l'espace SEQ. Intervalle minimum : 96 heures. A 1 msg/10s par tag, le debordement SEQ prend 1 942 jours (5,3 ans). Les mises a jour IV sont rares pour les tags d'actifs.
Isolation Multi-Tenant
Des cles d'application multiples fournissent une isolation logique. Chaque tenant obtient une app key unique ; les tags ne peuvent pas lire les donnees des autres meme en partageant la meme network key et l'infrastructure relay.
10. BLE Mesh vs Thread vs Zigbee
| Parametre | BLE Mesh | Thread | Zigbee 3.0 |
|---|---|---|---|
| Debit PHY | 1-2 Mbps | 250 kbps | 250 kbps |
| Relay | Managed flood/directed | Routage RPL | Arbre + mesh |
| Etat de routage | 0 Ko | 1-4 Ko | 2-8 Ko |
| Max noeuds | 1000-5000/subnet | 250-500 | 250-500 |
| Courant sleep | 1,5-5 uA | 3-10 uA | 2-5 uA |
| TX (+4 dBm) | 4,6 mA | 8,0 mA | 8,0 mA |
| Noeud mobile | Excellent | Faible | Faible |
BLE Mesh gagne pour les tags d'actifs sur trois dimensions : courant TX le plus bas (PHY 1 Mbps vs 250 kbps), adaptation instantanee des noeuds mobiles (flood vs convergence de routage) et compatibilite native de radio BLE.
11. Integration de Passerelle
Une passerelle mesh participe au mesh (detient la network key) et a une connectivite IP (Ethernet, Wi-Fi, cellulaire). Elle recoit les messages mesh et les transfere au cloud via MQTT ou HTTPS.
Deux conceptions : (1) Passerelle proxy utilisant le service proxy GATT pour un acces ad hoc ; (2) Passerelle embarquee (nRF52840 + Wi-Fi) fonctionnant 24/7 avec un pont MQTT.
Densite de passerelle : 1 pour 200-500 noeuds mesh. Des passerelles multiples fournissent la redondance ; le cloud deduplique par (SRC, SEQ).
Tag --> Relay --> Relay --> Passerelle --> MQTT --> Dashboard
Bout-en-bout : 200-800 ms12. Comparaison des Stacks Mesh
| Fabricant | SDK | SoC | Mesh 1.1 | RX | Notes |
|---|---|---|---|---|---|
| Nordic | NCS 2.5+ | nRF52840/nRF5340 | Oui | 5,2 mA | Meilleure doc, Zephyr |
| Silicon Labs | GSDK 4.3+ | EFR32BG22/BG24 | Oui | 4,8 mA | RX plus bas, BG24 96Ko |
| TI | BLE-STACK 5.x | CC2642R/CC2652R | Partiel | 5,9 mA | SimpleLink |
| Espressif | ESP-IDF | ESP32-C3/C6 | Non (1.0) | 8-12 mA | Passerelle Wi-Fi+BLE |
Pour les tags d'actifs, Nordic nRF52840 est le defaut : stack mature, meilleure documentation, plus bas courant combine sleep+scan. SiLabs EFR32BG24 est solide pour le directed forwarding (plus de RAM). ESP32-C3/C6 excelle pour les passerelles necessitant le Wi-Fi.
13. Exemples de Code
Configuration Relay (nRF Connect SDK / Zephyr)
#include
static void configure_relay_node(uint16_t addr)
{
int err;
uint8_t count, intvl;
err = bt_mesh_cfg_relay_set(net_key_idx, addr,
BT_MESH_RELAY_ENABLED,
BT_MESH_TRANSMIT(1, 10),
&count, &intvl);
if (err) {
printk("Relay set failed: %d", err);
return;
}
err = bt_mesh_cfg_ttl_set(net_key_idx, addr, 7);
} Publication de Donnees de Capteur
#define SENSOR_DATA_OP BT_MESH_MODEL_OP_2(0x12, 0x00)
struct __attribute__((packed)) sensor_payload {
int16_t temperature;
uint16_t humidity;
uint16_t battery_mv;
};
static int publish_sensor(int16_t temp, uint16_t hum, uint16_t batt)
{
struct sensor_payload p = { temp, hum, batt };
struct bt_mesh_msg_ctx ctx = {
.addr = 0xC001,
.send_ttl = 7,
.app_idx = app_key_idx,
};
BT_MESH_MODEL_BUF_DEFINE(buf, SENSOR_DATA_OP, sizeof(p));
bt_mesh_model_msg_init(&buf, SENSOR_DATA_OP);
net_buf_simple_add_mem(&buf, &p, sizeof(p));
return bt_mesh_model_publish(&sensor_model);
}Python: Estimateur de Scalabilite
class MeshScalability:
def __init__(self, n_nodes, relay_ratio, ttl, msg_interval_s, subnets=1):
self.n = n_nodes
self.relays = int(n_nodes * relay_ratio)
self.ttl = ttl
self.interval = msg_interval_s
self.subnets = subnets
self.capacity = 4800
def relay_amp(self):
return 1 + self.relays * 0.3 * min(self.ttl / 7.0, 1.0)
def total_load(self):
per_subnet = self.n / self.subnets
return (per_subnet / self.interval) * self.relay_amp()
def utilization(self):
return self.total_load() / self.capacity
def loss(self):
u = self.utilization()
if u < 0.04: return u * 0.1
elif u < 0.10: return 0.004 + (u - 0.04) * 0.3
elif u < 0.21: return 0.022 + (u - 0.10) * 0.5
else: return 0.077 + (u - 0.21) * 1.2
m = MeshScalability(500, 0.05, 7, 10)
print(f"Load: {m.total_load():.0f} msgs/s, Loss: {m.loss()*100:.1f}%")14. Debogage et Diagnostic
- Sniffer mesh : Utiliser nRF Sniffer pour Bluetooth LE dans Wireshark. Filtrer par type advertising mesh (0x2B). Inspecter la decrement TTL, les retransmissions relay et les cache hits.
- Monitoring heartbeat : Configurer la publication heartbeat depuis les noeuds relay. La destination recoit des messages periodiques avec TTL et RSSI pour la visibilite de la sante du reseau.
- Statistiques relay : Suivre le comptage relay par noeud, le taux de cache hit et les echecs de retransmission. Un taux de cache hit eleve indique une bonne couverture ; un taux faible suggere des lacunes.
- Problemes courants : Epuisement TTL (augmenter TTL ou ajouter des relays), debordement de cache (augmenter la taille), congestion de canal (reduire le taux de publication ou subnet), timeout de provisionnement (reduire la taille du lot).
15. Checklist de Conception de Production
- [ ] Determiner le ratio relay vs non-relay (cible 3-10%)
- [ ] Calculer le budget d'energie : les noeuds relay doivent avoir une alimentation externe
- [ ] Definir le TTL : 5-7 un batiment, 10+ campus
- [ ] Configurer le cache de messages : minimum 32 entrees (192 octets RAM)
- [ ] Planifier l'architecture subnet pour les deploiements >1 000 noeuds
- [ ] Concevoir le flux de provisionnement par lot (max 20 paralleles)
- [ ] Configurer la hierarchie network/app key pour l'isolation multi-tenant
- [ ] Definir l'intervalle de publication : 10s monitoring, 1s temps reel (requiert subnetting)
- [ ] Stress test sous congestion : injecter 2x le trafic attendu et mesurer la perte
- [ ] Planifier la densite de passerelle : 1 pour 200-500 noeuds, avec redondance
- [ ] Activer le monitoring heartbeat
- [ ] Verifier la compatibilite Mesh 1.1 directed forwarding si >2 000 noeuds
- [ ] Tester le comportement des tags mobiles : verifier l'adaptation de chemin entre zones
- [ ] Documenter la procedure de mise a jour IV et le calendrier de key refresh
- [ ] Planifier l'OTA firmware : utiliser la distribution via modele mesh pour les mises a jour massives
Conclusion
Les reseaux mesh BLE transforment le suivi d'actifs d'un modele a saut unique sature de passerelles en un reseau scalable et auto-reparable. Les decisions d'ingenierie cles sont : (1) utiliser une infrastructure alimentee par le secteur pour les noeuds relay, jamais des tags a pile bouton ; (2) dimensionner le ratio relay-vers-tag a 3-10% selon la disposition physique ; (3) surveiller l'utilisation du canal et sous-reseauter avant de depasser 1 000 noeuds actifs ; (4) exploiter le directed forwarding de Mesh 1.1 pour la scalabilite du backbone ; (5) planifier le provisionnement par lot et la redondance de passerelle pour le deploiement de production.
L'analyse du budget d'energie est sans pitie : un tag CR2032 avec relay dure 4,6 jours, tandis qu'un tag non-relay a 1 seconde dure 3,1 ans. Cette difference de 2 400x dicte l'architecture : relays d'infrastructure avec secteur, tags a batterie comme publieurs non-relay. Separez cela correctement, et le mesh gere le reste. Que ce soit 50 tags dans un entrepot ou 5 000 dans un campus industriel, ces principes aident a architecturer un reseau mesh de BLE tag qui fonctionne en production.