La plupart des module Bluetooth en production aujourd’hui ne servent pas un seul pair — ils gerent 3, 5 ou meme 20 connexions concurrentes vers des capteurs, smartphones, passerelles et actionneurs. La gestion multi-connexion est le moment ou les ingenieurs BLE juniors decouvrent que l’intervalle de connexion, la latence esclave, la taille MTU, le debit PHY et l’extension de longueur de donnees ne sont pas des regles independantes mais un probleme de planification etroitement couple. Une erreur et vous obtenez des deconnexions intermittentes, des pics de latence de 400 ms ou un debit qui ne depasse jamais 30 kbps malgre un PHY a 2 Mbps. Cet article decompose le modele du planificateur, derive les budgets de debit et de latence a partir des premiers principes et compare du silicium reel.
1. Le Modele d’Evenement de Connexion BLE
Une connexion BLE n’est pas un lien continu — c’est un rendez-vous periodique. Le maitre (central) et l’esclave (peripherique) s’accordent sur un intervalle de connexion (T_interval), et dans chaque intervalle il y a un evenement de connexion ou les deux radios sont actives. Le maitre transmet d’abord, l’esclave repond, et ils peuvent echanger plusieurs PDUs en ping-pong dans cet evenement. Quand il n’y a plus de donnees ou que l’evenement depasse son temps alloue, les radios dorment jusqu’au prochain intervalle.
Parametres cles dans LL_CONNECTION_PARAM_REQ :
- Intervalle de connexion (connInterval) : 7,5 ms a 4,0 s, par pas de 1,25 ms.
- Latence esclave (connLatency) : 0 a 499. Le peripherique peut sauter ce nombre d’evenements consecutifs sans etre deconnecte.
- Timeout de supervision (supervisionTimeout) : 100 ms a 32 s. Doit satisfaire : supervisionTimeout > (1 + connLatency) × connInterval × 2.
2. Planification Multi-Connexion : Division du Temps
Quand un module agit comme central avec N peripheriques, le planificateur doit placer N evenements dans chaque intervalle. La contrainte fondamentale est qu’une seule transaction radio se produit a chaque instant. Avec 4 connexions a 30 ms et des evenements de 5 ms, le temps actif total est 20 ms / 30 ms = 67% de duty cycle. Avec 8 connexions, 40 ms d’evenements deborderaient de l’intervalle de 30 ms, repoussant certains evenements au prochain intervalle et doublant leur latence.
2.1 Connexions Concurrentes Maximales par Chip
| Chip | Central Max | Peripherique Max | Total Max | Facteur Limitant |
|---|---|---|---|---|
| nRF52840 | 20 | 20 | 20 | RAM (8 KB/conn) |
| nRF52832 | 7 | 7 | 7 | RAM (64 KB) |
| CC2640R2F | 8 | 3 | 8 | TI-RTOS |
| BGM220SC | 8 | 4 | 8 | Gecko |
| ESP32-C3 | 9 | 3 | 9 | NimBLE |
| ESP32 (dual) | 15 | 4 | 15 | Bluedroid |
Chaque connexion consomme ~8 KB de RAM pour le contexte link layer, les buffers TX/RX et l’etat L2CAP. A 20 connexions, cela fait 160 KB sur 256 KB de RAM. L’ESP32-C3 avec NimBLE atteint 9 connexions dans 60 KB de heap — nettement plus efficace en memoire.
3. Calcul du Budget de Debit
Chaque PDU de donnees porte 10 bytes d’overhead (preamble 1 + access addr 2 + header 2 + length 2 + CRC 3). A 2 Mbps, 10 bytes = 40 us. Pour un payload de 251 bytes (DLE max) : temps PDU = (10+251)×8/2.000.000 = 1,044 ms. Overhead = 3,8%. Mais pour 20 bytes (defaut) = 33%.
IFS (inter-frame space) = 150 us de temps mort entre PDU maitre et esclave. Cycle pour 251 bytes a 2M : 1,044+0,150+1,044+0,150 = 2,388 ms. Debit = 251×8/2,388ms = 840 kbps — 42% du 2 Mbps brut. Avec 4 connexions a 30 ms / evenements 5 ms : debit par connexion = 244×8×3/30ms ≈ 195 kbps. Agrege = 780 kbps.
4. Analyse de Latence
Meilleur cas : donnees pretes juste avant l’evenement. Latence ≈ 1-3 ms. Pire cas : donnees pretes juste apres. Latence ≈ connInterval. Moyenne = connInterval / 2. Avec connLatency > 0 : intervalle effectif = connInterval × (1 + connLatency). Sous contention multi-connexion, le pire cas peut atteindre 2× connInterval. Avec 4 connexions a 30 ms : 62 ms. A 7,5 ms : 15 ms, mais duty cycle 4× superieur.
5. Negociation des Parametres
Le central fixe les parametres initiaux, mais chaque cote peut demander un changement via LL_CONNECTION_PARAM_REQ. iOS est restrictif : intervalle 15-30 ms, latence ≤ 29, timeout 2-6 s. Android est plus flexible mais certains OEMs refusent <10 ms. Procedure : initiateur envoie parametres + instant → repondeur accepte ou contre-proposition → effectif en 6 evenements.
6. Mise a jour PHY et Data Length Extension
LL_PHY_REQ permet le changement de PHY. Coded PHY (125/500 kbps) echange debit contre portee. 2M PHY double le debit brut. DLE augmente le payload max de 27 a 251 bytes. Critique : MTU et DLE sont des negociations independantes — les deux doivent etre augmentes. MTU seul → 9 fragments, 90 bytes gaspilles. DLE seul → L2CAP fragmente a 23 bytes. Les deux → 244 bytes en une PDU, overhead minimal.
7. Channel Map et AFH
BLE utilise 37 canaux de donnees, sautant par evenement. Le central fournit la channel map via LL_CHANNEL_MAP_REQ. En coexistence Wi-Fi : marquer les canaux chevauchant Wi-Fi 1 (BLE 0-10), 6 (11-20), 11 (21-30) comme inutilises. Avec 37 canaux : ~2% de perte de paquets. Avec 7 : ~8%, mais sans interference Wi-Fi.
8. Resolution des Conflits du Scheduler
| Strategie | Description | Avantages | Inconvenients |
|---|---|---|---|
| Priorite Stricte | Connexion prioritaire gagne toujours | Previsible pour liens critiques | Starvation basse priorite |
| Round-Robin Equitable | Rotation des slots | Pas de starvation | Latence imprevisible |
| Earliest Deadline First | Servir connexion la plus proche du timeout | Minimise deconnexions | Complexe |
nRF52 utilise round-robin equitable modifie. ESP32 Bluedroid utilise priorite stricte — la 9e connexion a 2× la latence de la 1ere. NimBLE implemente EDF avec 15-20% de meilleure distribution de latence sous charge.
9. Consommation en Multi-Connexion
nRF52840 0 dBm 1M : RX 5,4 mA, TX 4,6 mA. Evenement 3 ms ≈ 15 μC. 4 connexions a 30 ms : courant moyen ≈ 2,0 mA. CR2032 : 4,6 jours. Avec latency=3, 100 ms : 0,15 mA, 61 jours. Mais latence pire cas = 400 ms. Optimal pour reseaux de capteurs ou 400 ms est acceptable.
10. Benchmark Reel : Hub 4 Connexions
| Metric | 1 Conn | 2 Conn | 4 Conn |
|---|---|---|---|
| Debit/conn | 712 kbps | 681 kbps | 523 kbps |
| Agrege | 712 kbps | 1 362 kbps | 2 092 kbps |
| Latence moy. | 16 ms | 19 ms | 28 ms |
| P99 latence | 31 ms | 45 ms | 72 ms |
| Deconnexions/h | 0 | 0 | 0,3 |
11. Pieges de Design Courants
- 2M PHY avec MTU 23 → overhead 33%, gain seulement ~15%
- Slave latency sans verifier supervision timeout → deconnexions frequentes
- Assumer connInterval = latence → pire cas 2× avec offsets
- Negocier parametres pendant transfert → 2× latence pendant 6 evenements
- Oublier restrictions iOS → 15-30 ms obligatoire
- Toutes les connexions a offset 0 → contention concentree
12. Checklist de Design
- [ ] Intervalle 15-100 ms selon equilibre latence/puissance
- [ ] Latency 0 temps-reel, 3-9 faible consommation
- [ ] Supervision timeout ≥ (1+latency)×intervalle×3
- [ ] MTU 247 a l’etablissement
- [ ] DLE 251 a l’etablissement
- [ ] 2M PHY si BLE 5.0+
- [ ] Offsets distribues sur l’intervalle
- [ ] Channel map sans canaux Wi-Fi
- [ ] Compatibilite iOS (15-30 ms)
- [ ] Budget latence = 2×intervalle×(1+latency)
- [ ] Debit par connexion, pas seulement agrege
- [ ] Timeout augmente pour >4 connexions
- [ ] Courant mesure en pleine charge
13. Conclusion
Le design BLE multi-connexion est fondamentalement un probleme de planification. Le debit PHY brut est le nombre le moins interessant — le debit reel est determine par l’overhead PDU, l’IFS, le packing d’evenements et le nombre de connexions. La latence n’est pas connInterval mais jusqu’a 2× sous contention. La puissance escalade lineairement avec les connexions actives et inversement avec l’intervalle. Le travail de l’ingenieur est de choisir connInterval, connLatency, MTU, DLE et PHY comme un systeme couple. Un hub 4 connexions (30 ms / MTU 247 / DLE 251 / 2M PHY) atteint 523 kbps par connexion avec 28 ms de latence moyenne. Pour votre prochain module Bluetooth, commencez par la formule de debit, pas par le titre de la fiche technique.
