Wie viele Bluetooth-Beacons kann ich an einem Ort haben?
Immer wieder fragt jemand, wie viele RuuviTag Bluetooth-Sensor-Beacons er im Bereich eines einzelnen Gateways haben kann. Ist es machbar, jede Kiste in einem Lagerhaus zu überwachen? Jede einzelne Milchpackung in diesen Kisten?
Es stellt sich heraus, dass es keine exakte Antwort gibt, da die Daten in eigenständigen Paketen gesendet werden. Die Frage lautet: Mit welcher Rate können Bluetooth Low-Energy (BLE)-Pakete empfangen werden?
Theoretisches Maximum von Bluetooth-Beacons
Bluetooth-Advertisements werden auf drei separaten Frequenzkanälen gesendet, bekannt als 37, 38 und 39. Texas Instruments hat eine ausgezeichnete Einführung zu den Kanälen und zum Advertising, falls du an tiefergehenden Details interessiert bist.
Die minimale Größe eines Advertisement-Pakets beträgt 80 Bit (oder 10 Byte) und enthält:
- Präambel: 1 Byte
- Zugriffsadresse: 4 Byte
- Header: 2 Byte
- CRC: 3 Byte
Angenommen, wir wollen das Spektrum nur mit gültigen BLE-Advertisement-Daten füllen und irgendwie alle Geräte perfekt synchronisieren, könnten wir diese Pakete auf jedem Kanal senden und jeden Kanal separat empfangen. Der limitierende Faktor wäre die Datenrate von BLE 4, die
1 Mbit / s beträgt.
Insgesamt wären das 1.000.000 Bit / s geteilt durch 80 Bit / s mal 3 Kanäle, oder
37.500 Übertragungen pro Sekunde. Es gibt jedoch zahlreiche praktische Grenzen, angefangen bei unserem Gateway, das wahrscheinlich nur auf einem Kanal scannt.
Praktische Grenzen der Paketrate bei Bluetooth
Kanäle
Da die Sensor-Beacons als einzelne Komponente und nicht als integriertes System geliefert werden, müssen wir auf allen Kanälen werben, um sicherzustellen, dass wir den Kanal treffen, auf dem unser Gateway gerade lauscht. Da wir auf jedem Kanal dieselbe Werbung senden müssen, können wir kein Multiplexing über drei Kanäle verwenden, und die 37.500 Übertragungen werden durch drei auf 12.500 reduziert.
Datengröße
Unsere ursprüngliche Annahme war, dass die Datengröße eines Pakets 80 Bit beträgt. Das ist jedoch überhaupt nicht nützlich – diese 80 Bit enthalten nicht einmal die MAC-Adresse des Beacons. Seien wir vorsichtiger mit der Schätzung der Datengröße und verwenden wir die vollen 376 Bit eines BLE 4 Advertisements. Dies begrenzt uns auf 2.659 Pakete pro Sekunde.
Synchronisation
Bluetooth verfügt über keinen Mechanismus zur Synchronisierung der Beacons, um die Bandbreite gleichmäßig auf alle Geräte aufzuteilen. Die Beacons senden stattdessen zu zufälligen Zeitpunkten, in der Hoffnung, andere Störungen zumindest die meiste Zeit zu vermeiden. Natürlich sinkt die Wahrscheinlichkeit, andere Pakete zu verpassen, wenn der Datenverkehr in den Bändern zunimmt. Nordic Devzone hat eine ausgezeichnete Antwort zur Schätzung der Kollisionswahrscheinlichkeit: Im Wesentlichen gehen wir davon aus, dass, wenn zwei Pakete auf einem Kanal kollidieren, beide verloren gehen. Die Kollisionswahrscheinlichkeit wird zwischen zwei Advertisern basierend auf der Sendezeit eines Pakets und dem Übertragungsintervall berechnet.
Während das theoretische Modell, das auf der Modulationsgeschwindigkeit basiert, vorhersagt, dass eine einzelne Übertragung auf einem einzelnen Kanal 376 Mikrosekunden dauert, werden wir etwas praktischer und messen die Zeit vom Stromanstieg bis zum Stromabfall in einem Advertisement. Die Ergebnisse variieren etwas, da sie vom genauen Zeitpunkt der Probenahme abhängen, aber wir wählen 650 Mikrosekunden als unseren gemessenen Wert.
Wir wählen eine Sekunde als unser Intervall, da wir herausfinden wollen, wie viele Advertisements wir in einer Sekunde empfangen können. Unsere Wahrscheinlichkeit, Pakete zu kollidieren P(Treffer) beträgt 2 * 65e-5 / 1, was 0,13 % entspricht. Unsere Wahrscheinlichkeit, andere Pakete nicht zu treffen P(Verpassen) ist dann 1 – P(Treffer), oder 99,87 %.
Da die Beacons unabhängig sind, können wir die Wahrscheinlichkeit, keines der N Beacons zu treffen, als zusammengesetzte Wahrscheinlichkeit berechnen, ein Beacon nicht zu treffen: P(alle_verpassen) = P(verpassen)^N-1. Wir werden den Gesamtdurchsatz von Beacons, die Pakete einmal pro Sekunde senden, mit Scilab plotten.
N = 1:1:5000;
throughput = zeros(1, 5000);
Pmiss = 1 - (2*65*10^-5);
for i=1:1:length(N)
Pmiss_all = Pmiss^(i-1);
throughput(1, i) = i * Pmiss_all;
end
plot(N, throughput)
[v, i] = max(throughput)
a = gca();
a.font_size = 5;
a.x_label.text = string("Anzahl der Beacons") ;
a.x_label.font_size = 6;
a.y_label.text = "Durchsatz (N/s)";
a.y_label.font_size = 6;
e=gce();
p1=e.children(1);
t=datatipCreate(p1,769);
t.font_size = 5;
Gateway und Hintergrundrauschen
Zusätzlich zu den Beacons selbst gibt es immer ein gewisses Hintergrundrauschen, das die Anzahl der Pakete begrenzt, die wir empfangen können. Ebenso könnte das Gateway selbst eine gemeinsame Antenne für Wi-Fi und Bluetooth verwenden. In der Praxis habe ich Gateways gesehen, die unter ansonsten guten Bedingungen 5 % bis 50 % Paketverlust aufweisen. Angenommen, das Gateway kann 100 % der Advertisements abhören und der Hintergrund ist ansonsten ruhig, könnten wir 95 % der nicht kollidierenden Pakete oder 268 Übertragungen pro Sekunde empfangen – ein ziemlicher Unterschied zum theoretischen Maximum von 37.500!
Backend und Konnektivität
Während die Bluetooth-Nutzdatenrate keineswegs extrem ist – im obigen Fall nur etwa 12 kB/s – kann der tatsächliche Internetverkehr viel höher sein, insbesondere wenn Daten mit separaten Verbindungen für jeden Datenpunkt geschrieben werden, anstatt ein paar tausend Punkte auf einmal zu übertragen. Die Leistung verschiedener Backend-Lösungen liegt jedoch außerhalb des Rahmens dieses Beitrags.
Wie viele Bluetooth-Beacons kann ich also letztendlich einsetzen?
Es gibt keine einfache Antwort, daher müssen wir sagen: „Es kommt darauf an“. Die obige Grafik deutet darauf hin, dass selbst bei 5.000 Beacons, die einmal pro Sekunde Daten senden, einige Daten durchkommen würden, aber die Wahrscheinlichkeit, dass eine Übertragung empfangen wird, beträgt nur 0,15 %. Im Durchschnitt würde eine von 668 Übertragungen empfangen – das sind 11 Minuten. Der limitierende Faktor wird, wie lange ich warten kann, um eine Übertragung mit ausreichend hoher Sicherheit zu empfangen.
Nehmen wir an, wir überwachen Temperatur und Luftfeuchtigkeit in einem Lagerhaus. 11 Minuten Wartezeit könnten völlig sicher sein, da sich diese Werte unter normalen Bedingungen nicht schnell ändern. Wenn die Beacons hingegen zur Bestandsverfolgung in einem Lagerhaus verwendet werden, haben wir möglicherweise nur 10 Sekunden in der Nähe des Gateways, bevor die Waren abtransportiert werden.
Wir wählen 2 Schwellenwerte für die Sicherheit der Erkennung eines Tags innerhalb einer bestimmten Zeit: strenge 99,99999 % für die mobile Bestandsverfolgung und viel entspanntere 99 % für die Verfolgung der Bedingungen eines statischen Assets. Legen wir auch die anderen Variablen fest.
- Übertragungszeit: 650 Mikrosekunden
- Intervall: 1 Sekunde
- Gateway, Hintergrundrauschen: 5 % der Pakete gehen verloren
Als Nächstes berechnen wir eine Matrix der Erkennungswahrscheinlichkeiten innerhalb einer bestimmten Zeit, finden die erste Zeit, die eine größere Wahrscheinlichkeit als unser Schwellenwert aufweist, und plotten die Zeiten in Scilab.
Ttransmission = 65e-5;
Tinterval = 1;
Penvironment = 0.95;
Ntags = 1:1:5000;
Pmiss = 1 - (2*Ttransmission/Tinterval);
Pmiss_all = Pmiss^(Ntags - 1) * Penvironment;
Pnot_miss_all = 1-Pmiss_all;
Nbroadcasts = 1000;
for i=1:1:Nbroadcasts
Pnot_detect(i, :) = Pnot_miss_all^i;
end
Pdetect = 1 - Pnot_detect;
th1 = 0.99;
th2 = 0.9999999;
[idx, idy] = find(Pdetect > th1);
[uniq, map] = unique(idy);
plot(1:1:length(map), idx(map));
[idx2, idy2] = find(Pdetect > th2);
[uniq2, map2] = unique(idy2);
plot(1:1:length(map2), idx2(map2), 'g');
a = gca();
a.font_size = 5;
a.x_label.text = string("Anzahl der Beacons") ;
a.x_label.font_size = 6;
a.y_label.text = "Zeit bis zur Erkennung mit Wahrscheinlichkeit (s)";
a.y_label.font_size = 6;
hl = legend(["99 %", "99.99999 %"], 2);
hl.font_size = 5;
Jetzt können wir einige Beispiele für Beacon-Dichten auswählen. In einem Lagerszenario, in dem wir die Beacon-Daten einmal pro Minute mit 99 %iger Sicherheit erkennen möchten, können wir etwa 1.900 Beacons haben, die einmal pro Sekunde senden.
In einem Szenario zur Bestandsverfolgung, in dem wir die Übertragung in 10 Sekunden mit 99,99999 %iger Sicherheit erkennen möchten, können wir 100 Beacons in Reichweite haben.
Überprüfung der Schätzungen
Jede gute Theorie kann auf ihre Richtigkeit überprüft werden. Die Überprüfung dieser Beispiele sollte nicht allzu schwierig sein, alles, was wir brauchen, ist ein Raspberry Pi und ein paar tausend RuuviTags.
Glücklicherweise können wir die Zahlen etwas anpassen, um die Grundidee zu überprüfen, sodass wir nicht Tausende von Tags kaufen müssen. Wir beschleunigen alles und verwenden ein Intervall von 100 ms und prüfen, ob wir mindestens eine Übertragung pro Sekunde von den Tags erhalten.
Wir programmieren 16 Beacons so, dass sie in einem Intervall von 100 ms senden, und platzieren sie neben einem Raspberry Pi und einem ESP32-Dongle, die die Daten an InfluxDB weiterleiten. Der Raspberry Pi ist über Ethernet und der ESP32 über Wi-Fi verbunden.
Das Endergebnis ist ziemlich enttäuschend: Die Backend-Verbindung ist bei etwa 150 Samples pro Sekunde Spitzenwert gesättigt, und es können keine weiteren Daten empfangen werden.
Unser nächster Versuch hat eine lokale Datenbank, die auf einem PC läuft, was den Backend-Engpass beseitigen sollte. Hier stoßen wir jedoch auf einen Engpass beim Scannen: Selbst wenn nur ein Tag aktiv ist, erhalten wir weniger als 10 % der Advertisements. Eine schnelle Suche im Internet zeigt, dass dies mit der Mac OSX BLE-Scanning-Firmware und -Hardware zusammenhängen könnte, die die Antenne mit Wi-Fi teilt und nicht 100 % der Zeit scannt.
Optisch scheint der Gesamtdurchsatz bei einem Tag 0,75, bei 8 Tags 4,5 und bei 16 Tags 11 zu betragen. Der Durchsatz eines einzelnen Tags war die ganze Zeit über ziemlich konstant 0,75.
Verfeinerung des Modells
Ein Vorteil unseres theoretischen Modells ist, dass es Gateway-Unvollkommenheiten berücksichtigt. Wir aktualisieren unsere Schätzungen mit einem Gateway-Verlust von 92 % und schätzen die Empfangsrate mit 51 Tags. Zur besseren Messung verwenden wir auch das tatsächliche durchschnittliche Übertragungsintervall von 105 ms, das die durchschnittliche zufällige Verzögerung in unserer Vorhersage berücksichtigt.
Ein erster Durchlauf zeigt, dass das Modell eine schnellere Kollisionszunahmerate aufweist, als wir sie bei einer Übertragungszeit von 650 Mikrosekunden sehen, und daher setzen wir die Übertragungszeit auf 450 Mikrosekunden, was etwas über der theoretischen Zeit liegt, die sich aus der Modulationsgeschwindigkeit ergibt. Nun stimmt unser Modell ziemlich gut mit dem Experiment überein, zumindest im Bereich von 1 bis 16 Beacons. Die Ergebnisse des ersten Durchlaufs lassen wir der Kürze halber weg.
N = 1:1:60;
throughput = zeros(1, length(N));
Tinterval = 0.105
Ttx = 65*10^-5
Pmiss = 1-(2*Ttx/Tinterval);
Penvironment = 0.080;
for i=1:1:length(N)
Pmiss_all = Pmiss^(i-1);
throughput(1, i) = i * Pmiss_all * Penvironment / Tinterval;
end
plot(N, throughput)
[v, i] = max(throughput)
a = gca();
a.font_size = 5;
a.x_label.text = string("Anzahl der Beacons") ;
a.x_label.font_size = 6;
a.y_label.text = "Durchsatz (N/s)";
a.y_label.font_size = 6;
e=gce();
p1=e.children(1);
t=datatipCreate(p1,1);
t.font_size = 5;
t=datatipCreate(p1,8);
t.font_size = 5;
t=datatipCreate(p1,16);
t.font_size = 5;
Jetzt haben wir ein verfeinertes Modell, das einigermaßen gut mit den gemessenen realen Daten übereinstimmt. Es ist Zeit zu sehen, wie sich das Modell verhält, wenn wir insgesamt 51 Tags hinzufügen.
Die hier verwendeten Tags sind Fabrikausschuss, faire Vorführmuster usw. Bei diesem Experiment wurden keine Ruuvis beschädigt. Da einige der von uns zum Testen verwendeten Tags unsere Produktionstests nicht bestanden haben, sendeten zwei der Tags überhaupt nichts. Die endgültige Gesamtzahl der Sender betrug 49.
N = 1:1:60;
throughput = zeros(1, length(N));
throughput_single = zeros(1, length(N));
throughput_measured = [ 3, 6.5, 9.1, 11.2, 16.9, 20, 24.6, 27.2, 29.5, 31.9 ];
throughput_samples = [ 5, 10, 14, 18, 25, 30, 35, 40, 45, 49 ];
Tinterval = 0.105
Ttx = 45*10^-5
Pmiss = 1-(2*Ttx/Tinterval);
Penvironment = 0.080;
for i=1:1:length(N)
Pmiss_all = Pmiss^(i-1);
throughput(1, i) = i * Pmiss_all * Penvironment / Tinterval;
throughput_single(1, i) = Pmiss_all * Penvironment / Tinterval;
end
plot(N, throughput)
plot(throughput_samples, throughput_measured, 'g')
a = gca();
a.font_size = 5;
a.x_label.text = string("Anzahl der Beacons") ;
a.x_label.font_size = 6;
a.y_label.text = "Durchsatz (N/s)";
a.y_label.font_size = 6;
hl = legend(["Geschätzt", "Gemessen"], 2);
hl.font_size = 5;
Merkwürdigerweise gibt es keinen merklichen Effekt, dass weniger Pakete empfangen werden, wenn wir mehr Beacons hinzufügen. Vielleicht begrenzt die Firmware meines Macbooks die Ergebnisse, wenn sie mit extremer Rate eingehen, und wir empfangen weiterhin Pakete mit der maximalen Rate, die von meiner Hardware unterstützt wird?
Wir können einen anderen Ansatz wählen, um die Zuverlässigkeit zu bestimmen. Wir lassen 46 Beacons über Nacht eingeschaltet und überprüfen die Anzahl der 10-Sekunden-Intervalle, in denen mindestens ein Beacon nicht gesehen wurde.
Im Laufe von 10 Stunden gibt es 3.600 10-Sekunden-Intervalle, und wir haben 46 Beacons für insgesamt 165.600 Samples eines Beacons, das 10 Sekunden lang Daten sendet. Bei 70 dieser Samples wurden keine Daten empfangen.
Ein Zuverlässigkeitsrechner gibt uns eine 99,99%ige Sicherheit für eine 99,94%ige Zuverlässigkeit des Datenempfangs innerhalb eines 10-Sekunden-Intervalls. Wir werden dieses Ergebnis mit unserem früheren Zuverlässigkeitsschätzer überprüfen.
Ttransmission = 65e-5;
Tinterval = 0.1;
Penvironment = 0.95;
Ntags = 1:1:50;
Pmiss = 1 - (2*Ttransmission/Tinterval);
Pmiss_all = Pmiss^(Ntags - 1) * Penvironment;
Pnot_miss_all = 1-Pmiss_all;
Nbroadcasts = 1000;
for i=1:1:Nbroadcasts
Pnot_detect(i, :) = Pnot_miss_all^i;
end
Pdetect = 1 - Pnot_detect;
th1 = 0.9994;
[idx, idy] = find(Pdetect > th1);
[uniq, map] = unique(idy);
plot(1:1:length(map), idx(map));
a = gca();
a.font_size = 5;
a.x_label.text = string("Anzahl der Beacons") ;
a.x_label.font_size = 6;
a.y_label.text = "Zeit bis zur Erkennung mit Wahrscheinlichkeit (s)";
a.y_label.font_size = 6;
hl = legend(["99.94 %"], 2);
hl.font_size = 5;
Merkwürdigerweise stimmt unser Zuverlässigkeitsschätzer genau mit den Messungen überein, während die Paketverlustrate stark abwich. Eine mögliche Ursache ist, dass die Macbook BLE-Firmware mehrere Übertragungen von derselben MAC-Adresse in einem Batch sammelt und nur ratenbegrenzte Ergebnisse an höhere Ebenen des Betriebssystems und der Anwendungen meldet.
Fazit
Die ursprüngliche Frage war: Wie viele Beacons kann ich in einem Bereich haben? Für die meisten Leute können wir mit Zuversicht sagen: Genug. Wir hatten bis zu 46 Beacons, die in einem Intervall von 100 ms sendeten, und wir konnten sie alle mit relativ hoher Geschwindigkeit und guter Zuverlässigkeit hören.
Wenn die Ergebnisse auf langsamere Intervalle und eine größere Anzahl von Beacons skaliert werden können, könnten wir schätzen, dass 460 Beacons, die in einem Intervall von 1 s senden, innerhalb von 100 Sekunden gehört werden könnten und 4.600 Beacons, die in einem Intervall von 10 s senden, innerhalb von 1.000 Sekunden mit ziemlich guter Zuverlässigkeit gehört werden könnten. Diese Schätzung wird jedoch nicht durch ein Experiment untermauert.
Modelle für Paketverluste konnten nicht verifiziert werden, da die meisten Pakete aus noch unbekannten Gründen nicht von unserer Empfangshardware empfangen wurden. Eine Nachuntersuchung mit dedizierter Scan-Hardware und -Software muss durchgeführt werden, um diese Schätzungen zu überprüfen.
Bleib dran für einen Folgebeitrag mit dedizierten nRF52-Scannern und Tags, die mehrere MAC-Adressen senden, um präzisere Ergebnisse zu den Grenzen der Sender in diesem Bereich zu erhalten.
Vielen Dank an Lauri Jämsä.