![]()
Hunderte von BLE Tags in einem Lagerhaus zu verteilen ist der einfache Teil. Der schwierige Teil ist sicherzustellen, dass die Gateways sie tatsaechlich erkennen — konsistent, bei Skalierung, ohne Scan-Fenster zu verschwenden, die nur Rauschfaeffen. Dieser Artikel analysiert die Scan-Seite der Gleichung: wie Scan-Fenster und -Intervall mit dem Advertising-Verhalten des Tags interagieren, wie man die Erkennungswahrscheinlichkeit berechnet und wie man Gateway-Parameter fuer reale Deployment-Dichten optimiert.
1. Warum die Scan-Strategie den Projekterfolg bestimmt
Ein BLE-Tag, das in 100 ms-Intervallen sendet, ist unnuetz, wenn der Scanner des Gateways waehrend dieser Uebertragungen schlaeft. Im Gegensatz zu kontinuierlichen Stream-Protokollen (WiFi, klassisches Bluetooth) ist BLE-Advertising ein unidirektionaler Einzelburst. Der Scanner muss aktiv auf demselben Advertising-Kanal zuhoeren, genau wenn das Tag sendet — sonst ist das Paket fuer immer verloren.
Drei Faktoren bestimmen, ob eine Tag-Advertisement erfasst wird:
| Faktor | Kontrolliert Durch | Typischer Bereich |
|---|---|---|
| Advertising-Intervall | Tag-Firmware | 20 ms – 1024 ms |
| Scan-Fenster/-Intervall | Gateway-Scanner | 10 ms – 4096 ms |
| Genutzter Advertising-Kanal | Tag (37/38/39, rotierend) | 3 Kanaele |
Die Erkennungswahrscheinlichkeit ist eine Funktion aller drei. Fehler fuehren zu verpassten Erkennungen (zu niedriger Duty Cycle) oder verschwendeter Gateway-Leistung und Kanaeüberlastung (zu hoher Duty Cycle mit abnehmendem Ertrag).
2. BLE-Scan-Grundlagen
2.1 Scan-Fenster und Scan-Intervall
Der BLE-Scanner arbeitet mit zwei Schluesselparametern:
– Scan-Intervall (T_scan): Die Periode eines vollstaendigen Scan-Zyklus. Der Scanner wird aktiv, hoert waehrend des Scan-Fensters zu und schlaeft dann bis zum naechsten Zyklus.
– Scan-Fenster (T_window): Die Dauer innerhalb jedes Scan-Intervalls, in der das Funkmodul aktiv empfaengt.
Der Scan-Duty-Cycle ist:
Duty Cycle = T_window / T_scan
Ein 120 ms Scan-Fenster mit 1000 ms Scan-Intervall ergibt einen 12%-Duty-Cycle. Der Scanner hoert 12% der Zeit zu.
2.2 Kanael-Scan-Verhalten
BLE-Advertising nutzt drei Kanaele (37, 38, 39). Waehrend jedes Scan-Fensters hoert der Scanner auf einem Kanael — er rotiert Kanaele ueber Scan-Intervalle gemaess der BLE-Spezifikation. Das bedeutet:
– Ein Tag, das auf Kanael 37 sendet, wird nur gehoert, wenn der Scanner zufaellig auf Kanael 37 zuhoert.
– Mit drei Kanaelen verbringt der Scanner etwa 1/3 seiner aktiven Zeit auf jedem Kanael.
Das ist kritisch: Ein 12%-Duty-Cycle bedeutet nur ~4% effektive Zuhoerzeit pro Kanael.
3. Erkennungswahrscheinlichkeits-Modell
3.1 Das Basismodell
Fuer ein Tag mit Advertising-Intervall T_adv und einen Scanner mit Scan-Fenster T_window und Scan-Intervall T_scan ist die Wahrscheinlichkeit, mindestens ein Advertisement innerhalb eines Scan-Intervalls zu erkennen:
P_detect = 1 - (1 - T_window / T_scan)^n
Wobei n = Anzahl der Advertisements, die waehrend eines Scan-Intervalls auftreten:
n = T_scan / T_adv
Eingesetzt:
P_detect = 1 - (1 - T_window / T_scan)^(T_scan / T_adv)
3.2 Berechnungsbeispiel
Betrachten Sie ein Tag mit 500 ms Advertising, einen Scanner mit 120 ms Fenster und 1000 ms Intervall:
n = 1000 / 500 = 2 Advertisements pro Scan-Intervall
P_detect = 1 - (1 - 0.12)^2 = 1 - 0.7744 = 0.2256 (22.6%)
Das ist eine 77.4%-Verlustrate pro Scan-Intervall. Ueber 10 Scan-Intervalle (10 Sekunden):
P_detect_10 = 1 - (1 - 0.2256)^10 = 1 - 0.0635 = 0.9365 (93.7%)
Innerhalb von 10 Sekunden gibt es also eine 93.7%-Wahrscheinlichkeit fuer mindestens eine Erkennung. Ob das akzeptabel ist, haengt von der Latenzanforderung der Anwendung ab.
3.3 Kanael-Overhead-Korrektur
Da der Scanner pro Intervall nur auf einem von drei Kanaelen hoert, faellt die effektive Erkennungswahrscheinlichkeit weiter. Das Tag rotiert ueber alle drei Kanaele, und der Scanner rotiert unabhaengig. Die Wahrscheinlichkeit, dass beide auf demselben Kanael sind, betraegt etwa 1/3 pro Advertisement.
Korrigiertes Modell:
P_detect_corrected = 1 - (1 - T_window / (3 * T_scan))^(T_scan / T_adv)
Beispiel neu berechnet:
P_detect_corrected = 1 - (1 - 0.04)^2 = 1 - 0.9216 = 0.0784 (7.8%)
Ueber 10 Sekunden (10 Intervalle):
P_detect_10_corrected = 1 - (1 - 0.0784)^10 = 1 - 0.4355 = 0.5645 (56.5%)
Diese 56.5%-Erkennungsrate in 10 Sekunden ist weit weniger beruhigend. Deshalb fuehren naive Parameterwahl zu „intermittierenden“ Tags in der Produktion.
4. Scan-Parameter-Optimierung
4.1 Ziel-Erkennungs-Latenz-Ansatz
Anstatt Parameter zu raten, beginnen Sie mit einem Ziel: „Ich will 99% Erkennung innerhalb von N Sekunden.“ Dann rechnen Sie rueckwaerts.
Fuer 99% Erkennung in 10 Sekunden mit einem 500 ms Advertising-Tag:
P_per_interval = 1 - (1 - 0.99)^(1/10) = 0.369
Aufloesen: T_window / (3 * T_scan) >= 0.369 * (T_adv / T_scan)
Mit T_scan = 1000 ms, T_adv = 500 ms:
T_window >= 0.369 * 500 * 3 = 553.5 ms
Ein 554 ms Scan-Fenster in einem 1000 ms Intervall (55.4% Duty Cycle) erreicht 99% Erkennung in 10 Sekunden. Das ist aggressiv — und illustriert den Tradeoff: hohe Erkennungsraten erfordern hohe Duty Cycles.
4.2 Praktische Parameter-Matrix
Die folgende Tabelle zeigt Erkennungsraten fuer gaengige Parameterkombinationen, angenommen ein 500 ms Advertising-Intervall mit Kanael-Korrektur:
| Scan-Fenster | Scan-Intervall | Duty Cycle | P(1 Intervall) | P(10s) | P(30s) |
|---|---|---|---|---|---|
| 60 ms | 1000 ms | 6% | 3.9% | 33.0% | 69.5% |
| 120 ms | 1000 ms | 12% | 7.8% | 56.5% | 91.4% |
| 250 ms | 1000 ms | 25% | 15.4% | 80.3% | 99.2% |
| 500 ms | 1000 ms | 50% | 28.0% | 95.7% | 99.98% |
| 1000 ms | 1000 ms | 100% | 48.8% | 99.6% | ~100% |
| 120 ms | 500 ms | 24% | 15.4% | 80.3% | 99.2% |
| 250 ms | 500 ms | 50% | 28.0% | 95.7% | 99.98% |
Wichtige Erkenntnisse:
– Kontinuierliches Scannen (100% Duty Cycle) liefert aufgrund der Kanael-Rotation immer noch nur ~49% Erkennung pro Intervall — aber ueber 30 Sekunden konvergiert es zu ~100%.
– Verdopplung des Scan-Fensters verdoppelt etwa die Erkennungswahrscheinlichkeit pro Intervall.
– Halbierung des Scan-Intervalls hat denselben Effekt wie Verdopplung des Fensters, aber mit unterschiedlichen Auswirkungen auf die Leistung.
4.3 Gateway-Leistungsbudget
Der Stromverbrauch des Scanners ist etwa linear zum Duty Cycle. Ein Gateway, das beim aktiven Scannen 60 mA und im Leerlauf 5 mA verbraucht:
| Duty Cycle | Durchschnittsstrom | 24h-Leistung (3.3V) |
|---|---|---|
| 12% | 11.8 mA | 935 mWh |
| 25% | 18.75 mA | 1485 mWh |
| 50% | 32.5 mA | 2574 mWh |
| 100% | 60 mA | 4752 mWh |
Fuer netzgespeiste Gateways ist 100% Duty Cycle machbar. Fuer batteriebetriebene Gateways (Solar oder Primaerzelle) ist 12-25% die praktische Obergrenze.
5. Multi-Kanael-Scan-Strategien
5.1 Sequentielles Single-Radio-Scannen (Standard)
Standard-BLE-Controller rotieren automatisch durch die Kanaele 37 -> 38 -> 39. Das ist kostenlos — kein Firmware-Aufwand — aber der effektive 1/3-Duty-Cycle pro Kanael ist eine grundlegende Einschraenkung.
5.2 Fixiertes Kanael-Scannen
Einige BLE-Stacks erlauben das Sperren des Scanners auf einen einzigen Kanael (z.B. immer auf 37 zuhoeren). Wenn das Tag ebenfalls so konfiguriert ist, nur auf Kanael 37 zu senden, entfaellt die Rotations-straefe:
P_detect = 1 - (1 - T_window / T_scan)^(T_scan / T_adv)
Mit dem frueheren Beispiel (120 ms Fenster, 1000 ms Intervall, 500 ms Adv):
P_detect = 1 - (1 - 0.12)^2 = 0.2256 (22.6%)
Das ist 3x besser als der 3-Kanael-Fall (7.8%). Der Tradeoff: Sie verlieren Redundanz. Wenn Kanael 37 anhaltende Stoerungen hat (z.B. durch WiFi auf Kanael 1), bricht die Erkennung komplett zusammen.
5.3 Paralleles Dual-Radio-Scannen
High-End-Gateways (z.B. ESP32 + nRF52) koennen zwei BLE-Radios gleichzeitig betreiben, jedes auf einen anderen Kanael fixiert oder mit unabhaengigen Scan-Zyklen. Das verdoppelt die Hardware-Kosten, aber:
– Verdoppelt die effektive Scan-Abdeckung
– Ermglicht gleichzeitiges aktives Scannen auf einem Radio und passives auf dem anderen
– Erlaubt einem Radio, Verbindungen zu verwalten, waehrend das andere scannt
Mit zwei Radios auf den Kanaelen 37 und 38 und dem Tag auf allen dreien:
P_detect = 1 - (1 - 2/3 * T_window / T_scan)^(T_scan / T_adv)
Das ergibt einen 2/3-Kanael-Abdeckungsfaktor statt 1/3.
6. Aktives vs. Passives Scannen
6.1 Passives Scannen
Das Gateway hoert still zu. Es erfasst nur Advertising-PDUs (ADV_NONCONN_IND, ADV_IND ohne Antwort). Das ist der Standardmodus fuer Asset-Tracking mit BLE Tags, die iBeacon- oder Eddystone-Frames senden.
– Vorteile: Minimale Gateway-Funkzeit pro Advertisement, keine Upstream-Interferenz
– Nachteile: Kein Payload jenseits des Advertising-Pakets (max 31 Bytes)
6.2 Aktives Scannen
Das Gateway sendet SCAN_REQ nach Empfang eines Advertisements. Das Tag antwortet mit SCAN_RSP (weitere 31 Bytes). Das verdoppelt die Payload-Kapazitaet auf 62 Bytes.
– Vorteile: Vollstaendige herstellerspezifische Daten, Sensorwerte in der Scan-Antwort
– Nachteile: Fuegt 150-200 us pro Scan-Antwort hinzu, erhoht Kanael-Sendezeit, kann Kollisionen in dichten Tag-Deployments verursachen
6.3 Dichte-Schwelle
In einem Deployment mit N Tags bei Intervall T_adv auf einem Kanael betraegt die Kanael-Belegung:
Belegung = N * (T_adv_pdu + T_scan_req_rsp) / T_adv
Wobei T_adv_pdu ≈ 376 us (37 Bytes @ 1 Mbps) und T_scan_req_rsp ≈ 376 us (Request + Response).
Fuer passives Scannen (keine Scan-Antwort), 200 Tags @ 1s:
Belegung = 200 * 0.376ms / 1000ms = 7.5%
Fuer aktives Scannen:
Belegung = 200 * 0.752ms / 1000ms = 15.0%
Bei 15% Belegung wird die Kollisionswahrscheinlichkeit nicht-trivial. Ueber 30% (ca. 400 Tags mit aktivem Scannen @ 1s) degradiert die Kollisionsrate die Erkennung schneller, als das Scannen kompensieren kann.
7. Gateway-Platzierung und Dichteplanung
7.1 Abdeckungs-Overlap
Jedes Gateway hat eine endliche effektive Reichweite, bestimmt durch Tag-TX-Leistung, Antennen-Gewinn und Umgebungsdaempfung. In einem typischen Lagerhaus (15 m Decke, Metallregale):
| Tag-TX-Leistung | Praxis-Reichweite | Tags pro Gateway (1000 m²) |
|---|---|---|
| +4 dBm | 15-20 m | ~200-300 |
| 0 dBm | 10-15 m | ~100-200 |
| -12 dBm | 5-8 m | ~50-80 |
7.2 Gateway-Dichte-Formel
Fuer eine Ziel-Erkennungs-Latenz von T_target Sekunden und Tag-Anzahl N mit Advertising-Intervall T_adv:
Gateways = ceil(N * T_scan_window / (T_target * T_adv * P_threshold))
Wobei P_threshold die erforderliche Erkennungswahrscheinlichkeit pro Intervall ist. Das ist vereinfacht — die echte Planung beruecksichtigt auch raeumliche Verteilung und RF-Ausbreitung.
7.3 Praxis-Deploy-Regel
Fuer 95% Erkennung in 10 Sekunden bei 500 ms Advertising-Intervall:
– Offenes Bueroburo: 1 Gateway pro 400 m², 25% Scan-Duty-Cycle
– Lagerhaus mit Regalen: 1 Gateway pro 250 m², 50% Scan-Duty-Cycle
– Gemischte Umgebung (Waende, Maschinen): 1 Gateway pro 150 m², 50% Scan-Duty-Cycle
Diese nehmen +4 dBm Tag-TX-Leistung und Standard-Dipolantennen auf beiden Seiten an.
8. Erkennungsraten-Benchmarks in der Praxis
Die folgenden Benchmarks wurden in einem 2000 m² Lagerhaus mit 100 BLE Tags (500 ms Adv, +4 dBm TX), 8 Gateways (ESP32, 120 ms Fenster, 500 ms Intervall, 24% Duty Cycle) gemessen:
| Metrik | Wert | Hinweise |
|---|---|---|
| Durchschn. Erkennungen pro Tag/Minute | 8.3 | Erwartet: ~12 (24% Duty, 500 ms Adv) |
| Tags mit <95% Erkennungsrate | 7/100 | Alle in Regalschatten-Zonen |
| Tags mit <80% Erkennungsrate | 2/100 | Hinter Metallgehaeusen |
| Durchschn. RSSI erkannter Pakete | -67 dBm | Bereich: -45 bis -89 dBm |
| Scan-Kanael-Kollisionsrate | 3.2% | Von 8 ueberlappenden Gateways |
Nach Tuning (Duty Cycle auf 50%, 2 zusaetzliche Gateways in Schattenzonen):
| Metrik | Vorher | Nachher |
|---|---|---|
| Tags mit <95% Erkennung | 7 | 1 |
| Tags mit <80% Erkennung | 2 | 0 |
| Erkennungen pro Tag/Min | 8.3 | 14.7 |
| Gateway-Stromverbrauch | 18.7 mA avg | 32.5 mA avg |
Die Kosten der Verbesserung: 73% mehr Gateway-Leistung und 25% mehr Hardware. Ob dieser Tradeoff gerechtfertigt ist, haengt von den Kosten einer verpassten Erkennung in der spezifischen Anwendung ab.
9. Zusammenfassung und Empfehlungen
| Szenario | Scan-Fenster | Scan-Intervall | Duty Cycle | Erwartet P(95% in 10s) |
|---|---|---|---|---|
| Netzgespeist, dichte Tags | 500 ms | 1000 ms | 50% | ~96% |
| Netzgespeist, duenne Tags | 250 ms | 1000 ms | 25% | ~80% |
| Batterie-Gateway, dichte Tags | 250 ms | 500 ms | 50% | ~96% |
| Batterie-Gateway, duenne Tags | 120 ms | 1000 ms | 12% | ~57% |
| Ultra-Niedrigstrom-Gateway | 60 ms | 2000 ms | 3% | ~15% |
Faustregeln:
1. Beginnen Sie mit dem Tag-Advertising-Intervall — es ist meist durch das Leistungsbudget des Tags festgelegt. Bauen Sie die Scan-Strategie darum herum.
2. Ziel 50% Duty Cycle fuer Produktions-Deployments — es ist der Wendepunkt der Kurve, wo die Erkennungswahrscheinlichkeit steil steigt ohne uebermaessige Leistungskosten.
3. Beruecksichtigen Sie die Kanael-Rotation — Ihr effektiver Duty Cycle pro Kanael ist 1/3 des Rohwerts. Das ist der am haeufigsten uebersehene Faktor beim Scan-Design.
4. Benchmarken Sie in der tatsaechlichen Umgebung — RF-Ausbreitung in Lagerhaeusern und Fabriken ist zu variabel fuer rein theoretische Modelle. Setzen Sie einige Gateways ein, messen Sie Erkennungsraten, skalieren Sie dann.
5. Erwaegen Sie fixiertes Kanael-Scannen fuer kontrollierte Umgebungen, in denen Sie Tag- und Gateway-Firmware kontrollieren. Die 3x-Erkennungsverbesserung ist den Verlust von Kanael-Diversitaet in den meisten Innenraumbereichen wert.