Die meisten Bluetooth-Modul in der Produktion bedienen heute keinen einzelnen Peer — sie verwalten 3, 5 oder sogar 20 gleichzeitige Verbindungen zu Sensoren, Smartphones, Gateways und Aktuatoren. Multi-Verbindungs-Verwaltung ist der Punkt, an dem Junior-BLE-Ingenieure entdecken, dass Verbindungsintervall, Slave-Latenz, MTU-Groesse, PHY-Rate und Data Length Extension keine unabhaengigen Knoepfe sind, sondern ein eng gekoppeltes Planungsproblem. Ein Fehler fuehrt zu intermittenten Trennungen, 400-ms-Latenzspitzen oder Durchsatz, der nie 30 kbps uebersteigt trotz 2-Mbps-PHY. Dieser Artikel zerlegt das Scheduler-Modell, leitet Durchsatz- und Latenzbudgets aus ersten Prinzipien ab und vergleicht reales Silizium.
1. Das BLE-Verbindungsereignis-Modell
Eine BLE-Verbindung ist keine kontinuierliche Verbindung — sie ist ein periodischer Termin. Master (Central) und Slave (Peripheral) einigen sich auf ein Verbindungsintervall (T_interval), und innerhalb jedes Intervalls gibt es ein Verbindungsereignis, in dem beide Funkeinheiten aktiv sind. Der Master sendet zuerst, der Slave antwortet, und sie koennen mehrere PDUs in einem Ping-Pong innerhalb dieses Ereignisses austauschen. Wenn keine Daten mehr vorhanden sind oder das Ereignis sein Zeitlimit ueberschreitet, schlafen die Funkeinheiten bis zum naechsten Intervall.
Schluesselparameter in LL_CONNECTION_PARAM_REQ:
- Verbindungsintervall (connInterval): 7,5 ms bis 4,0 s, in 1,25-ms-Schritten.
- Slave-Latenz (connLatency): 0 bis 499. Der Peripheral darf so viele aufeinanderfolgende Ereignisse ueberspringen, ohne getrennt zu werden.
- Supervision-Timeout (supervisionTimeout): 100 ms bis 32 s. Muss gelten: supervisionTimeout > (1 + connLatency) × connInterval × 2.
2. Multi-Verbindungs-Planung: Zeitteilung
Wenn ein Modul als Central mit N Peripherals agiert, muss der Scheduler N Verbindungsereignisse innerhalb jedes Intervalls platzieren. Die grundlegende Einschraenkung ist, dass zu jedem Zeitpunkt nur eine Funktransaktion stattfindet. Bei 4 Verbindungen mit 30 ms und 5-ms-Ereignissen betraegt die aktive Zeit 20 ms / 30 ms = 67% Duty Cycle. Bei 8 Verbindungen wuerden 40 ms Ereignisse das 30-ms-Intervall ueberlaufen und einige Ereignisse ins naechste Intervall verschieben, was ihre Latenz effektiv verdoppelt.
2.1 Maximale gleichzeitige Verbindungen nach Chip
| Chip | Central Max | Peripheral Max | Gesamt Max | Limit |
|---|---|---|---|---|
| nRF52840 | 20 | 20 | 20 | RAM (8 KB/Verb.) |
| 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 |
Jede Verbindung verbraucht ~8 KB RAM fuer Link-Layer-Kontext, TX/RX-Puffer und L2CAP-Zustand. Bei 20 Verbindungen sind das 160 KB von 256 KB RAM. ESP32-C3 mit NimBLE erreicht 9 Verbindungen in 60 KB Heap — deutlich speichereffizienter.
3. Durchsatzbudget-Berechnung
Jede Daten-PDU traegt 10 Bytes Overhead (Preamble 1 + Access Addr 2 + Header 2 + Length 2 + CRC 3). Bei 2 Mbps dauern 10 Bytes 40 us. Fuer 251-Byte-Payload (DLE max): PDU-Zeit = (10+251)×8/2.000.000 = 1,044 ms. Overhead = 3,8%. Aber fuer 20 Bytes (Default) = 33%.
IFS (Inter-Frame Space) = 150 us Totzeit zwischen Master- und Slave-PDU. Zyklus fuer 251 Bytes bei 2M: 1,044+0,150+1,044+0,150 = 2,388 ms. Durchsatz = 251×8/2,388ms = 840 kbps — 42% der rohen 2 Mbps. Bei 4 Verbindungen, 30 ms, 5-ms-Ereignissen: Durchsatz pro Verbindung = 244×8×3/30ms ≈ 195 kbps. Aggregiert = 780 kbps.
4. Latenzanalyse
Best case: Daten bereit kurz vor Ereignis. Latenz ≈ 1-3 ms. Worst case: Daten bereit kurz danach. Latenz ≈ connInterval. Durchschnitt = connInterval / 2. Bei connLatency > 0: effektives Intervall = connInterval × (1 + connLatency). Unter Multi-Verbindungs-Contention kann Worst-Case 2× connInterval erreichen. Bei 4 Verbindungen, 30 ms: 62 ms. Bei 7,5 ms: 15 ms, aber 4× Duty Cycle.
5. Verbindungsparameter-Verhandlung
Central setzt Initialparameter, aber jede Seite kann Aenderung via LL_CONNECTION_PARAM_REQ anfordern. iOS ist restriktiv: 15-30 ms Intervall, Latenz ≤ 29, Timeout 2-6 s. Android ist flexibler, aber einige OEMs lehnen <10 ms ab. Verfahren: Initiator sendet Parameter + Instant → Responder akzeptiert oder kontert → wirksam nach 6 Ereignissen.
6. PHY-Update und Data Length Extension
LL_PHY_REQ erlaubt PHY-Wechsel. Coded PHY (125/500 kbps) tauscht Durchsatz gegen Reichweite. 2M PHY verdoppelt Bruttorate. DLE erhoht max Payload von 27 auf 251 Bytes. Kritisch: MTU und DLE sind unabhaengige Verhandlungen — beide muessen erhoeht werden. Nur MTU → 9 Fragmente, 90 Bytes verschwendet. Nur DLE → L2CAP fragmentiert bei 23 Bytes. Beide → 244 Bytes in einer PDU, minimaler Overhead.
7. Channel Map und AFH
BLE nutzt 37 Datenkanaele, hoppt pro Ereignis. Central liefert Channel Map via LL_CHANNEL_MAP_REQ. Bei Wi-Fi-Koexistenz: Kanaele die mit Wi-Fi 1 (BLE 0-10), 6 (11-20), 11 (21-30) ueberlappen als ungenutzt markieren. Mit 37 Kanaelen: ~2% Packet Loss. Mit 7: ~8%, aber keine Wi-Fi-Interferenz.
8. Scheduler-Konfliktloesung
| Strategie | Beschreibung | Pro | Contra |
|---|---|---|---|
| Strikte Prioritaet | Hoechste Prioritaet gewinnt immer | Vorhersagbar fuer kritische Links | Starvation niedriger Prioritaet |
| Fair Round-Robin | Slots rotieren | Keine Starvation | Unvorhersagbare Latenz |
| Earliest Deadline First | Verbindung naehester Deadline bedienen | Minimiert Trennungen | Komplex |
nRF52 nutzt modifiziertes Fair Round-Robin. ESP32 Bluedroid nutzt strikte Prioritaet — die 9. Verbindung hat 2× Latenz der 1. NimBLE implementiert EDF mit 15-20% besserer Latenzverteilung unter Last.
9. Stromverbrauch bei Multi-Verbindung
nRF52840 0 dBm 1M: RX 5,4 mA, TX 4,6 mA. 3-ms-Ereignis ≈ 15 μC. 4 Verbindungen bei 30 ms: mittlerer Strom ≈ 2,0 mA. CR2032: 4,6 Tage. Mit Latency=3, 100 ms: 0,15 mA, 61 Tage. Aber Worst-Case-Latenz = 400 ms. Optimal fuer Sensornetzwerke wo 400 ms akzeptabel ist.
10. Praxis-Benchmark: 4-Verbindungs-Hub
| Metrik | 1 Verb. | 2 Verb. | 4 Verb. |
|---|---|---|---|
| Durchsatz/Verb. | 712 kbps | 681 kbps | 523 kbps |
| Aggregiert | 712 kbps | 1.362 kbps | 2.092 kbps |
| Mittlere Latenz | 16 ms | 19 ms | 28 ms |
| P99 Latenz | 31 ms | 45 ms | 72 ms |
| Trennungen/Std | 0 | 0 | 0,3 |
11. Haeufige Design-Fehler
- 2M PHY mit MTU 23 → Overhead 33%, Gewinn nur ~15%
- Slave Latency ohne Supervision-Timeout-Pruefung → haeufige Trennungen
- ConnInterval = Latenz annehmen → Worst-Case 2× mit Offsets
- Parameter waehrend Datentransfer verhandeln → 2× Latenz fuer 6 Ereignisse
- iOS-Beschraenkungen vergessen → 15-30 ms Pflicht
- Alle Verbindungen bei Offset 0 → konzentrierte Contention
12. Design-Checkliste
- [ ] Intervall 15-100 ms je nach Latenz/Leistung-Balance
- [ ] Latency 0 fuer Echtzeit, 3-9 fuer Low-Power
- [ ] Supervision-Timeout ≥ (1+Latency)×Intervall×3
- [ ] MTU 247 bei Verbindungsaufbau
- [ ] DLE 251 bei Verbindungsaufbau
- [ ] 2M PHY bei BLE 5.0+
- [ ] Offsets ueber Intervall verteilen
- [ ] Channel Map ohne Wi-Fi-Kanaele
- [ ] iOS-Kompatibilitaet (15-30 ms)
- [ ] Latenzbudget = 2×Intervall×(1+Latency)
- [ ] Durchsatz pro Verbindung, nicht nur aggregiert
- [ ] Timeout erhoehen bei >4 Verbindungen
- [ ] Strom bei Vollast messen
13. Fazit
Multi-Verbindungs-BLE-Design ist im Kern ein Planungsproblem. Die rohe PHY-Rate ist die uninteressanteste Zahl — der reale Durchsatz wird durch PDU-Overhead, IFS, Event-Packing und Anzahl der Verbindungen bestimmt. Latenz ist nicht connInterval sondern bis zu 2× unter Contention. Leistung skaliert linear mit aktiven Verbindungen und umgekehrt zum Intervall. Die Aufgabe des Ingenieurs ist es, connInterval, connLatency, MTU, DLE und PHY als gekoppeltes System zu waehlen. Ein 4-Verbindungs-Hub (30 ms / MTU 247 / DLE 251 / 2M PHY) erreicht 523 kbps pro Verbindung bei 28 ms mittlerer Latenz. Fuer Ihren naechsten Bluetooth-Modul beginnen Sie mit der Durchsatzformel, nicht mit der Datasheet-Ueberschrift.
