Was ist BLE-Payload-Filterung?

Die BLE-Payload-Filterung ist der Prozess, bei dem nur die nützlichen Daten aus Bluetooth-Werbeanzeigen ausgewählt werden, bevor sie gesendet werden. LoRaWAN, wodurch die Nutzung von Gesprächszeit, der Akkuverbrauch und unnötiger Netzwerkverkehr reduziert werden.

Warum ist die Nutzlastfilterung wichtig in LoRaWAN?

Die Nutzlastfilterung reduziert LoRaWAN Die Sendezeit wird verlängert, die Akkulaufzeit des Gateways verbessert, die Netzwerküberlastung verringert und Tracking-Systemen geholfen, aussagekräftige Ereignisse anstelle wiederholter roher Bluetooth-Pakete zu senden.

Warum das Senden jedes BLE-Pakets Probleme im LoRaWAN-Netzwerk verursacht

Ein Bluetooth-Beacon ist von Natur aus kommunikativ. Er sendet Signale und wiederholt diese ständig. Genau deshalb eignet sich BLE so gut für die Ortung von Ausweisen, Inventaretiketten, Schlüsselanhängern, Armbändern und Umweltsensoren. Sensoren, Panikknöpfe und Bewegungsmelder sind integriert. Ein Scanner in der Nähe muss keine Verbindung herstellen. Er empfängt einfach die Werbedaten und entscheidet dann, wie er damit umgeht.

Dieser letzte Punkt ist entscheidend. In einem BLE-zu-LoRaWAN-Trackingsystem ist das Gateway nicht nur eine Datenleitung. Es fungiert als Übersetzer, Sortierer und kann mitunter den Unterschied zwischen einem reibungslosen Tracking-Betrieb und einem störungsanfälligen System ausmachen, das unnötig Sendezeit verbraucht.

In Lansitecs B-Mobile Architektur, Bluetooth-Beacons werden von Personen getragen oder an Gegenständen befestigt, während Bluetooth-Gateways an festen Standorten sitzen und empfangene Informationen weiterleiten durch LoRaWAN an den Server. Der Server berechnet dann den Standort anhand der Gateway-Koordinaten und RSSI.

In einem realen, komplexen Einsatz ändert sich das Bild jedoch und es wird schnell eng. Auf einem Krankenhausflur befinden sich dann beispielsweise Rollstühle, Infusionspumpen, Mitarbeiterausweise und Temperaturmessgeräte. Sensoren, und Notrufknöpfe, die alle in der Nähe Werbung machen. Ein Autohaus kann Schlüssel, Fahrzeuge, Werkstattplätze und Gateway-Abdeckung überlappen. In einem Lagerhaus können Tags durch Bereiche mit schwachem Signal gesendet werden, wobei die Signalüberlagerung aus benachbarten Räumen mehr Pakete verursacht, als die Anwendung tatsächlich benötigt.

Wenn das System jedes Byte aus jeder BLE-Werbung weiterleitet, LoRaWAN wird zum Flaschenhals. Nicht weil LoRaWAN ist schwach. Nein, ist es nicht. Es eignet sich hervorragend für Telemetrie über große Entfernungen mit geringem Stromverbrauch. Es ist jedoch für kleine, nützliche Nachrichten konzipiert, nicht für das Auslesen roher Bluetooth-Pakete.

BLE vs. LoRaWAN: Warum die Nutzlastoptimierung wichtig ist

Die herkömmliche BLE-Werbung bietet der Anwendung einen kompakten Nutzdatenbereich. Die Bluetooth-Dokumentation von Silicon Labs beschreibt die Werbenutzdaten des Primärkanals als 0 bis 31 Byte, strukturiert in Werbedatenelemente wie Flags, Dienst-UUIDs, lokale Namen und herstellerspezifische Daten. ⁽¹⁾

Einunddreißig Bytes klingen nicht nach viel. Aber multiplizieren Sie es.

Ein Gateway kann in einem dicht besiedelten Gebiet Dutzende oder Hunderte von Werbebotschaften pro Sekunde empfangen. Das Lansitec Kompaktes Bluetooth-Gateway, Beispielsweise kann ein einzelner Beacon-Sender 100 Beacon-Nachrichten innerhalb einer Sekunde empfangen, während ein einzelner Beacon-Sender dies nicht kann. LoRaWAN Das Paket kann bis zu 15 Beacon-Nachrichten senden. Es unterstützt außerdem konfigurierbare Bluetooth-Datenfilterung und Nutzlastberichterstattung, einschließlich des Filterns bestimmter Datenbytes aus einer BLE-Nutzlast vor der Berichterstattung. LoRaWAN.

Das Gateway sollte nicht fragen: “Was habe ich gehört?” Es sollte fragen: “Was hat sich geändert, was ist wichtig und was muss der Server tun, um zu handeln?”

In den meisten Anwendungsfällen der Ortung ist die Antwort deutlich kleiner als die reine BLE-Nutzlast. BLE-Geräte können Daten wie Temperatur, Luftfeuchtigkeit oder Herzfrequenz in iBeacon- oder Eddystone-Nutzlasten übertragen, aber LoRaWAN Unterstützt eine begrenzte Anzahl von Bytes pro Uplink und Downlink. Es wird empfohlen, das Gateway so zu konfigurieren, dass es nur nützliche Informationen sendet, typischerweise ID, Parameter plus RSSI.

Was ist BLE-Nutzlastfilterung?

Die Filterung der Nutzdaten ist nicht dasselbe wie die Verkürzung des Berichtsintervalls. Ein kürzeres Intervall bedeutet, seltener Daten zu senden, während die Filterung bedeutet, nur die benötigten Daten zu senden.

Ein Lansitec Bluetooth-Gateway kann die BLE-Nutzdaten untersuchen, die relevanten Bytes auswählen und nur die von der Anwendung benötigten Teile weiterleiten. In der Praxis bedeutet das:

• Beacon-Identität: UUID, Haupt-/Neben-ID, MAC-basierte ID oder konfigurierte Asset-ID
• Kontext: RSSI, Gateway-ID, Zeitstempel, Zone oder Ein-/Ausgangsstatus
• Sensorwerte: Temperatur, Luftfeuchtigkeit, Schrittzahl, Herzfrequenz, Bewegungserkennung, Status des Panikknopfes, Sperr-/Entsperrstatus
• Ereignislogik: Nur melden, wenn ein Beacon eintritt, austritt, seinen Zustand ändert oder einen Schwellenwert überschreitet.

Für einen Anwendungsfall zur Schlüsselverfolgung benötigt die Anwendung möglicherweise nur die Schlüssel-ID + Gateway-ID + RSSI. 

Für einen Kühlschrank werden möglicherweise Sensor-ID + Temperatur + Alarmflag benötigt. 

Für einen Alleinarbeiterausweis werden möglicherweise Ausweis-ID + Panikstatus + benötigt. RSSI + zuletzt gesehenes Gateway.

Alles andere ist teure Dekoration. Diesen Fehler beobachten wir häufig in Planungsgesprächen: Teams konzentrieren sich obsessiv auf die Gateway-Reichweite und vernachlässigen dabei das Payload-Design. Doch die Reichweite liefert Pakete. Filterung wandelt diese Pakete in nutzbare Ereignisse um.

Wie die BLE-Nutzlastfilterung die LoRaWAN-Sendezeitnutzung reduziert

LoRaWAN bietet eine große Reichweite bei geringem Stromverbrauch, aber Nutzlastgröße und Flugzeit spielen weiterhin eine Rolle.

Bei EU863-870 variiert die maximale Anwendungsnutzlast je nach Datenrate: 51 Byte bei DR0 bis DR2, 115 Byte bei DR3 und 222 Byte bei DR4 bis DR7, wenn FOpts nicht verwendet wird. Auf derselben Seite wird darauf hingewiesen, dass höhere Spreizfaktoren zu niedrigeren Bitraten führen, während niedrigere Spreizfaktoren höhere Bitraten bewirken. ⁽²⁾

In Europa regeln die Duty-Cycle-Regeln auch die Sendehäufigkeit von Geräten. Es gibt ETSI-Teilbandgrenzen wie 1% für 865–868 MHz und 868–868,6 MHz, 0,1% für einige benachbarte Teilbänder und 10% für 869,4–869,65 MHz. Zu beachten ist außerdem, dass die Richtlinien öffentlicher Netze strengere Grenzwerte festlegen können, wie beispielsweise die TTN Sandbox mit 30 Sekunden Uplink-Sendezeit pro Knoten und Tag. ⁽²⁾

Das bedeutet nicht, dass jede private Lansitec-Implementierung durch die Sandbox-Richtlinie von TTN eingeschränkt ist. Es bedeutet jedoch, dass Käufer aufhören sollten, Lansitec-Systeme so zu behandeln, als ob sie nicht mehr im privaten Bereich eingesetzt würden. LoRaWAN Uplinks sind kostenlos, weil keine SIM-Karte benötigt wird. Keine SIM-Karte, super. Allerdings müssen Gesprächszeit, Gateway-Kapazität und Akkuleistung weiterhin berücksichtigt werden.

Beispiel für die Anlagenverfolgung in einem Krankenhaus mithilfe von BLE-Payload-Filterung

Stellen Sie sich einen Krankenhausflügel vor, in dem Rollstühle, Infusionspumpen, tragbare Monitore, OP-Tische, CT-Zubehör, Mitarbeiterausweise und Temperaturmessgeräte mit BLE-Tags ausgestattet sind. Sensoren, und Notrufarmbänder.

Ein Gateway empfängt ein Beacon-Paket. Die direkte Weiterleitung würde alles Empfangene ungefiltert weiterleiten. Dazu könnten beispielsweise Felder gehören, die das Krankenhaus-Dashboard nie verwendet, wiederholte Pakete von Geräten, die sich nicht bewegt haben, und schwache Signale aus dem Nachbarraum.

Ein gefiltertes Ereignis sieht anders aus:

Asset-ID + Gateway-ID + RSSI + Bewegungsflag + Batterieflag

Oder, für einen Sensor:

Sensor-ID + Temperatur + Alarmstatus + RSSI

Das Dashboard benötigt nicht jedes Mal die vollständige BLE-Ankündigung. Es muss lediglich wissen, dass sich Pumpe 1842 in der Nähe des Flurs von Station B befindet, dass Gefrierschranksensor 12 einen Temperaturschwellenwert überschritten hat oder dass ein Panikknopf gedrückt wurde.

Lansitecs Solar-, Makro-, Mikro-, Kompakt-, Innen- und SocketSync-Geräte Bluetooth-Gateways Alle im Produktkatalog enthaltenen Funktionen umfassen konfigurierbare Bluetooth-Datenfilterung und Nutzlastberichterstattung, wobei die wiederkehrende Funktion als Filtern von Datenbytes in einer Bluetooth-Nutzlast und Melden ausgewählter Daten beschrieben wird. LoRaWAN. Dies ist keine Nebensache. Es ist ein wesentlicher Bestandteil der Funktionsweise von BLE-zu-LoRaWAN-Systemen, die auch in großem Umfang nutzbar bleiben.

Wie die Nutzlastfilterung die Akkulaufzeit des Gateways verlängert

Ein Gateway, das weniger, kleinere und qualitativ bessere Nachrichten sendet, benötigt weniger Zeit für die Übertragung. Das ist besonders wichtig bei batteriebetriebenen Geräten. Gateways. Das Lansitec Macro Bluetooth-Gateway, Beispielsweise verwendet es einen 38.000 mAh Li-SoCl2-Akku und ist für Langzeiteinsätze konzipiert, bei denen keine Stromversorgung verfügbar ist. Es verfügt über Bluetooth-Nutzdatenfilterung, einstellbare Positionsmeldeintervalle, Heartbeat-Intervalle, Bluetooth-Datenkomprimierung, TDMA-Unterstützung und maximal 15 Beacon-Nachrichten in einem einzigen LoRaWAN Paket bei SF9.

Diese Funktionen arbeiten zusammen. Filterung reduziert die Nutzdaten. Komprimierung verdichtet die verbleibenden Daten. TDMA und Berichtssynchronisierung unterstützen mehrere Prozesse. Gateways Das Verhalten ist vorhersehbarer. Dank anpassbarer Intervalle kann der Installateur entscheiden, ob die Website eine nahezu Echtzeit-Transparenz oder lediglich zuverlässige Zustandsänderungen benötigt.

Ein stark frequentiertes Portal in einem Lagergang sollte nicht alle paar Sekunden dasselbe statische Palettenetikett melden, nur weil es es erfassen kann. Sinnvoller ist es, Ein- und Ausgänge, den letzten sichtbaren Standort sowie relevante Statusänderungen zu melden.

Warum mehr Tracking-Daten nicht immer zu besserer Transparenz führen

Ein Käufer könnte fragen: “Können wir alle fünf Sekunden Updates erhalten?” Manchmal ja. Lansitec-Gateways Unterstützung konfigurierbarer Berichtsintervalle und mehrere LoRaWAN Die Modelle geben 5s xn als einstellbares Positionsmeldeintervall an. Die wichtigere Frage ist jedoch szenarioabhängig:

• Benötigen Sie einen fünfsekündigen Standortstream oder müssen Sie wissen, wann ein markiertes Objekt einen Sperrraum betritt?
• Benötigen Sie jede einzelne Armbandwerbung oder nur die Ereignisse „Panikknopf“, „Überschreitung des Aufenthalts“ und „Zonenüberschreitung“?
• Benötigen Sie kontinuierliche Rohtemperaturwerte oder nur normale Herzschläge zuzüglich Schwellenwertausnahmen?

Hier wird die Nutzlastfilterung zu einem Thema der Produktentwicklung und nicht zu einem Detail der Firmware.

Bei einem Besucherausweis ist eine Aktualisierung alle fünf Sekunden möglicherweise unnötig. Bei einem Gabelstapler-Näherungsalarm ist der Zeitpunkt des Ereignisses entscheidend. Bei einem Gefrierschranksensor ist das Überschreiten eines Schwellenwerts wichtiger als die genaue Position. Bei Autoschlüsseln in einem Autohaus reicht es unter Umständen aus, dass die Anwesenheit im Raum erfasst wird, bis jemand nach einem bestimmten Schlüssel sucht und dadurch einen Alarm auslöst. Senden Sie das Ereignis und halten Sie den Alarm lokal.

Wie die BLE-Nutzlastfilterung in Lansitec B-Mobile Tracking funktioniert

Im B-Mobile, Bluetooth-Gateway ist fixiert, und der Beacon bewegt sich. Das Gateway empfängt BLE-Nachrichten in der Nähe, strukturiert die Daten um und leitet sie weiter. LoRaWAN. Die LoRa-Lösung von Lansitec hat Leuchtfeuer Werbung UUID, Major, Minor, Temperatur oder andere Daten, während die Bluetooth-Gateway empfängt und restrukturiert diese Daten, bevor sie an die LoRaWAN Gateway und Anwendung.

In diesem Kontext bedeutet “Restrukturierung”, dass das System zahlreiche rohe BLE-Werbedaten in anwendungsfertige Tracking-Daten umwandeln kann. In der Praxis benötigt das Backend üblicherweise Folgendes:

• Wer oder was wurde entdeckt?
• Welches Gateway hat es gehört?
• Wie stark das Signal war
• Ob sich der Staat geändert hat
• Welcher Sensorwert oder welches Alarmsignal ist relevant?

B-Mobile hebt außerdem hervor, dass Gateways können Leuchtfeuersignale aus benachbarten Räumen empfangen, oft mit viel schwächeren RSSI, und dass RSSI Die Leistung kann aufgrund von 2,4-GHz-Interferenzen und Mehrwegeausbreitung variieren. Filter können die physikalischen Gegebenheiten der Funkfrequenztechnik nicht wiederherstellen, aber sie können verhindern, dass schwache, irrelevante oder wiederholte Pakete die Anwendungsschicht überfluten.

Bewährte Verfahren für die BLE-Nutzdatenfilterung

Ein guter BLE-zu-LoRaWAN-Payload-Plan ist meist unspektakulär. Das ist ein Kompliment. Beginnen Sie mit einem kleinen Ereigniswörterbuch. Definieren Sie, was die Anwendung tatsächlich verwendet, und ordnen Sie dann jedes Ereignis Bytes zu. Halten Sie den Server-Decoder einfach, versioniert und dokumentiert. Trennen Sie in gemischten Umgebungen Asset-IDs, Personal-IDs, Sensor-IDs und Infrastruktur klar voneinander. Leuchtfeuer.

Hier sind drei praktische Schnittmuster, die uns gefallen:

Häufige Fehler bei der BLE-Nutzdatenfilterung, die Sie vermeiden sollten

Eine Warnung sei jedoch angebracht: Die Filterung sollte den Diagnosewert nicht zerstören.

Während der Inbetriebnahmephase benötigen Sie möglicherweise umfangreichere Nutzdaten: Rohdaten RSSI, Mehrere Gateway-Beobachtungen, Akkustand, Firmware-Version und gegebenenfalls ein Fehlercode für das gesendete Ereignis. Sobald sich die Website stabilisiert hat, können Sie die Nutzdaten optimieren.

Ein guter Rollout weist oft zwei Profile auf:

• Inbetriebnahmemodus: Mehr Daten, kürzere Diagnosefenster, einfachere Fehlersuche.
• Betriebsmodus: Gefilterte Ereignisse, schlanke Nutzlasten, längere Akkulaufzeit, weniger Uplinks.

Wir haben gesehen, dass sich dies bei Projekten auszahlt, bei denen die erste Woche mit der Feinabstimmung verbracht wird. RSSI Schwellenwerte, Raumgrenzen und Gateway-Platzierung. Danach kann das System in den Ruhemodus wechseln und melden, welche Vorgänge tatsächlich erforderlich sind.

Wie man ein skalierbares BLE-zu-LoRaWAN-Trackingsystem baut

Die BLE-zu-LoRaWAN-Verfolgung funktioniert am besten, wenn das Gateway mehr tut, als nur zuzuhören. Es sollte Entscheidungen treffen.

Die Payload-Filter- und Berichtsfunktion von Lansitec ist eines jener praktischen Details, die im ersten Gespräch mit potenziellen Käufern oft nicht zur Sprache kommen. Dabei sollten sie es. Denn sobald eine Website Hunderte von Tags, verschiedene Sensortypen und Gateway-Überschneidungen aufweist, LoRaWAN Aufgrund von Nutzlastbeschränkungen und batteriebetriebener Infrastruktur wird das reine Weiterleiten schnell ineffizient.

Sende die ID. Sende den Parameter. Sende die RSSI. Den Alarm auslösen. Den Lärm hinter sich lassen.

Literaturhinweise und weiterführende Literatur

1. Silicon Labs: Grundlagen der Bluetooth-Werbedaten
2. The Things Network: EU863-870 Richtlinien zu maximaler Nutzlast und Betriebszyklus