Die meisten BLE-Gateway-Vergleiche beginnen mit übersichtlichen Tabellen: Reichweite, Bandbreite, Stromverbrauch, Kosten.

Feldeinsätze scheitern jedoch selten, weil jemand eine Tabelle in einer Broschüre falsch interpretiert hat. Sie scheitern vielmehr, weil das Gateway zu häufig scannt. Oder weil eine kleine BLE-Nutzlast zu 15 Beacon-Datensätzen pro Uplink führt. Oder weil das Mobilfunksignal auf einem Smartphone einwandfrei aussieht, dann aber in einem Metallgehäuse zusammenbricht. Oder weil der Kunde Echtzeitalarme von einem Leistungsprofil erwartet, das für den Energiesparmodus ausgelegt ist.

Das ist die sinnvollere Methode, um die BLE-Gateway-Backhaul-Verbindung zu vergleichen. Anstatt zu fragen “Welches Funkmodul ist das beste?”, sollte man sich folgende Frage stellen: Welcher Backhaul-Pfad ist am wenigsten anfällig für Ausfälle, wenn die Standortbedingungen unübersichtlich werden?

Bei Lansitec ist diese Frage von Bedeutung, weil Bluetooth-Gateways Sie befinden sich an der komplexen Schnittstelle zwischen lokaler BLE-Datenerfassung und Weitverkehrsverbindungen. Ein BLE-Beacon kann UUID, Major- und Minor-ID sowie weitere Informationen senden., RSSI, Sensordaten, Panikereignisse, Temperatur, Bewegung und mehr. Das Gateway muss dann entscheiden, welche Daten weitergeleitet werden, wie oft und über welches Netzwerk.

Lansitec unterstützt dies durch mehrere Backhaul-Familien: LoRaWAN, NB-IoT/LTE-M und Cat-1. Die richtige Wahl hängt weniger von der Funktheorie als vielmehr von den Gegebenheiten der Installation ab.

Lasst uns darüber reden, was tatsächlich kaputt geht.

Zunächst einmal: Was genau macht das BLE-Gateway?

Bei einer Bereitstellung im B-Mobile-Stil, Bluetooth-Beacons werden an Gegenständen befestigt oder von Personen getragen. Bluetooth-Gateway Es befindet sich an einem festen Standort, empfängt die Nachrichten der nahegelegenen Beacons, strukturiert die Daten um und leitet sie über ein Backhaul-Netzwerk an den Server oder die Anwendung weiter. (Lansitec-System) LoRaWAN B-Mobile-Architektur, das heißt BLE zum Gateway, Gateway zu LoRaWAN Vom Gateway geht es dann weiter über 4G oder Ethernet zum Netzwerkserver und zur App.

In der NB-IoT/LTE-M-Version überspringt das Gateway das lokale Netzwerk. LoRaWAN Die Infrastruktur wird eingerichtet und die restrukturierten BLE-Daten werden direkt über das Mobilfunknetz des Betreibers an einen MQTT- oder HTTP-Server weitergeleitet.

Das Gateway muss fünf Dinge in Einklang bringen:

1. BLE-Scanfenster
2. Backhaul-Berichtsintervall
3. Nutzlastgröße
4. Energiebudget
5. Wiederherstellung nach einem Ausfall

Wenn man einen Fehler macht, mag das System in der Demoversion zwar noch funktionieren. Nach der Markteinführung wird es dann aber teuer, langsam, störungsanfällig oder wartungsintensiv.

Fehlermodus 1: Die Leistungsaufnahme wurde für das Funkgerät berechnet, nicht für die Aufgabe.

Die Leistung der Backhaul-Verbindung hängt nicht nur vom Funkmodul ab.

Es ist der gesamte Ablauf des Gateways: aufwachen, BLE scannen, Daten filtern, senden, gegebenenfalls auf eine Bestätigung warten, bei Bedarf wiederholen, wieder in den Ruhemodus wechseln. Ein Gateway, das kontinuierlich scannt und häufig meldet, führt zwei ressourcenintensive Aufgaben gleichzeitig aus.

Genau da liegt das Problem vieler Projekte.

LoRaWAN: Stark bei kleinen und disziplinierten Meldungen

LoRaWAN ist bekanntermaßen sparsam, aber nur, wenn man das Nutzlast- und Sendezeitmodell beachtet. Es funktioniert gut, wenn das Gateway kompakte Ereignisse sendet: Beacon-ID, RSSI, Gateway-ID, Zeitstempel und ausgewählte Sensorbytes.

Lansitecs LoRaWAN Makro Bluetooth-Gateway ist ein gutes Beispiel für die batteriezentrierte Designphilosophie. Es verwendet zwei 19.000-mAh-Li-SoCl2-Akkus und listet 83 Monate Betrieb mit einem Meldeintervall von 5 Minuten. Dieselbe Produktfamilie unterstützt konfigurierbare Bluetooth-Nutzdatenfilterung, sodass das Gateway nicht jedes empfangene Byte weiterleiten muss.

Genau darum geht es. LoRaWAN Die beste Leistung erbringt das System, wenn es sich wie ein Ereignismeldesystem verhält und nicht wie ein reines BLE-Paketstreaming-System.

NB-IoT/LTE-M: geringer Stromverbrauch, aber das Verhalten des Bedieners ist wichtig

NB-IoT und LTE-M sind für das zellulare IoT konzipiert, verhalten sich aber nicht gleich.

NB-IoT eignet sich am besten für stationäre Geräte, geringe Datenmengen, lange Ruhephasen und hohe Abdeckung in Innenräumen. LTE-M ist besser geeignet, wenn sich das Gerät bewegt, eine reaktionsschnellere Downlink-Verbindung benötigt oder praktische Firmware-Updates unterstützt werden müssen. Die GSMA-Richtlinien für Mobile IoT positionieren NB-IoT und LTE-M als komplementäre LPWA-Technologien. LTE-M ist im Allgemeinen besser für mobile und interaktive Anwendungsfälle geeignet, während NB-IoT typischerweise für kleine, seltene Nachrichten mit hoher Abdeckung verwendet wird. ⁽¹⁾

Der Haken ist, dass die Mobilfunkleistung stark von der Signalqualität abhängt. Ein Gateway mit schlechter Netzabdeckung verbraucht möglicherweise mehr Energie für Verbindungsaufbau, erneute Verbindungsversuche oder um das Modem aktiv zu halten. Theoretisch sieht das Akkumodell gut aus. In der Praxis funktioniert es aber nicht.

Wir haben festgestellt, dass Kunden annehmen, Mobilfunk bedeute Vorhersehbarkeit. Das stimmt nicht. Es bedeutet lediglich eine vom Betreiber unterstützte, lizenzierte Spektrumverbindung, und das ist etwas anderes.

Cat-1: kein LPWAN, aber manchmal betrieblich sauberer

Cat-1 ist nicht die energiesparendste Option. Das sollten wir ehrlich zugeben.

Es bietet jedoch einen anderen Vorteil: Es verhält sich eher wie herkömmliches LTE. Es ermöglicht eine höhere Nutzlastkapazität, geringere Latenz, einfachere IP-Kommunikation und eine unkompliziertere Firmware- bzw. Konfigurationsabwicklung. Quectel positioniert LTE Cat-1 bis als Mittelweg zwischen LPWA und höheren LTE-Kategorien. Es bietet eine stärkere Mobilität, geringere Latenz und mehr Bandbreite als NB-IoT/LTE-M und vermeidet gleichzeitig die Komplexität von LTE-Modulen höherer Kategorien. ⁽²⁾

Für BLE Gateways, Das kann nützlich sein. Nicht etwa, weil Cat-1 auf magische Weise effizient wäre, sondern weil eine kurze, erfolgreiche Sitzung besser sein kann als eine langsame, instabile, wenn die Anwendung viele Nachrichten sendet.

Lansitecs Cat-1 Makro-Bluetooth-Gateway zeigt, wie dies in einem Gateway-Produkt aussieht: Cat-1-Backhaul, BLE-Filterung, Bluetooth-Datenkomprimierung und eine Liste 5 Jahre Akkulaufzeit bei 5 Sekunden Bluetooth-Empfang Dauer und 240-Sekunden-Berichtsintervall.

Diese Zahl ist nur deshalb sinnvoll, weil das Gateway Cat-1 nicht wie eine kontinuierliche Verbindung behandelt. Es verwendet weiterhin Duty-, Filter- und Reporting-Regeln.

Feldregel

• Wenn das Gateway ständig Scans durchführt, sollten Sie nur sparsam Berichte erstellen.
• Wenn es häufig Meldungen gibt, scannen Sie es gezielt.
• Wenn beides aggressiv gemacht wird, wird die Batterie zum Wartungsplan.

Fehlermodus 2: Die Abdeckung wurde als Karte und nicht als Standortverhalten behandelt

Die Abdeckungskarten sind beruhigend. Gebäude hingegen nicht.

Ein Telefon, das Signalbalken anzeigt, ist keine Mobilfunkstandortanalyse. LoRaWAN Die Reichweitenangabe ist nicht LoRaWAN Standortbesichtigung. BLE “150 m Sichtlinie” bedeutet nicht 150 m durch Regale, Beton, nasse Wände, Maschinen, Personen und geparkte Lastwagen.

Die Entscheidung für den Rücktransport wird an drei Orten konkret: Kellern, Laderampen und Metallräumen.

Die LoRaWAN-Abdeckung ist steuerbar, aber man muss sie planen.

Der große Vorteil von LoRaWAN ist die Kontrolle. Wenn der Kunde Eigentümer der Website ist, können Sie die LoRaWAN Platzieren Sie das Gateway dort, wo es hingehört, optimieren Sie die Bereitstellung und halten Sie die laufenden Netzwerkkosten niedrig.

Das funktioniert hervorragend in Fabriken, Lagerhallen, auf Campusgeländen und Parkplätzen. Eine Lansitec B-Mobile LoRa-Implementierung kann Folgendes nutzen: Bluetooth-Gateways im Arbeitsbereich, dann ihre BLE-Berichte über ein Backhaul-Netzwerk senden. LoRaWAN Gateway-Verbindung über 4G oder Ethernet.

Die Bereitstellungsrichtlinien von Lansitec empfehlen die Platzierung des LoRaWAN Das Eingangstor sollte, wenn möglich, auf dem Dach eines Gebäudes oder, bei einer einzelnen Fabrik, an einer hochgelegenen Stelle im Inneren angebracht werden. Es wird außerdem darauf hingewiesen, dass … LoRaWAN Das Gateway selbst benötigt 4G oder Ethernet. Für 4G-Projekte empfiehlt sich ein Datentarif von 2 GB, da der SIM-Kartenverbrauch je nach Projekt variiert.

Eine LoRaWAN BLE-Gateway-Implementierung umfasst weiterhin zwei Netzwerkschichten:

Schicht	Was kann scheitern?
BLE zu Bluetooth-Gateway	Wände, Räume, RSSI Blutung, Scan-Zeitpunkt
Bluetooth-Gateway Zu LoRaWAN Tor	LoRa-Abdeckung, Spreizfaktor, Kapazität, Gateway-Platzierung
LoRaWAN Tor zur Cloud	Ethernet-Ausfall, 4G-Ausfall, SIM-Karten-Tarif, Netzwerkserverpfad

Die NB-IoT/LTE-M-Abdeckung ist einfacher bereitzustellen, aber schwieriger zu steuern.

NB-IoT/LTE-M entfernt die standorteigene LoRaWAN Eingang. Das ist attraktiv. Nein. LoRaWAN Gateway-Planung. Keine lokalen LoRaWAN Serverentscheidung. Kein Kunde fragt nach dem Montageort der Antenne.

Der Kompromiss besteht in der Abhängigkeit.

Verfügt der Anbieter am Standort des Gateways über eine starke NB-IoT- oder LTE-M-Abdeckung, ist das optimal. Andernfalls stehen Ihnen weniger Stellschrauben zur Verfügung. Sie können die Antennenposition optimieren, ein besseres SIM-Profil auswählen, eSIM/eUICC-Strategien nutzen oder den Anbieter wechseln. Die Basisstation selbst haben Sie jedoch nicht unter Kontrolle.

NB-IoT eignet sich zudem tendenziell schlecht für bewegliche Geräte oder schnelle Interaktionen. Lansitecs eigene LoRaWAN Im Vergleich zu NB-IoT wird festgestellt, dass NB-IoT für bewegliche Geräte nicht geeignet ist, LoRaWAN Unterstützt Mobilität und adaptive Datenraten.

Die Cat-1-Abdeckung ist breit gefächert, aber Leistung und Kosten müssen sorgfältig abgewogen werden.

Cat-1 nutzt eine ausgereifte LTE-Infrastruktur. Das erleichtert oft den Einsatz in gemischten oder temporären Umgebungen, insbesondere dort, wo die Verfügbarkeit von LTE-M oder NB-IoT uneinheitlich ist.

Es ist zudem flexibler für MQTT-, HTTP(S)-, TCP- und UDP-Workflows. In Gebäuden, in denen die IT-Abteilung keinen Ethernet-Zugang gewährt oder WLAN für IoT-Geräte nicht erlaubt ist, kann Cat-1 die praktische Lösung sein.

Die entscheidende Frage lautet nicht: “Kann ein Cat-1-Kabel angeschlossen werden?” Normalerweise ja. Die Frage lautet vielmehr: Kann sich das Projekt den von Cat-1 geförderten Energie- und Datenverbrauch leisten? Wenn die Antwort Ja lautet, ist das eine gute Option.

Fehlermodus 3: Nutzlastbeschränkungen wurden ignoriert, bis das Dashboard leer aussah.

BLE kann eine Menge lokaler Daten erzeugen.

Ein Gateway kann Dutzende von Geräuschen hören Leuchtfeuer. Jeder Beacon kann mehrere Kennungen oder Sensorfelder übertragen. Das Anwendungsteam fragt dann: “Können wir einfach alles weiterleiten?”

Normalerweise nicht.

Oder zumindest nicht, wenn die Rückfracht LoRaWAN und das Projekt erwartet eine lange Batterielebensdauer.

LoRaWAN Die Nutzdatengröße ist regions- und datenratenabhängig. In der Dokumentation von The Things Network für das EU863-870-Frequenzband werden maximale Nutzdatengrößen von 51 Byte (DR0 bis DR2), 115 Byte (DR3) und 222 Byte (DR4 bis DR7) angegeben. Außerdem wird die Empfehlung zum 1%-Tastverhältnis im europäischen Frequenzband erwähnt. ⁽³⁾

Die LoRa Alliance verwaltet diese regionalen Beschränkungen getrennt vom Kernsystem. LoRaWAN Spezifikation, wobei RP002-1.0.5 am 8. Oktober 2025 veröffentlicht wurde. ⁽⁴⁾

Deshalb ist Filtern so wichtig.

Lansitecs LoRaWAN Bluetooth-Gateways Die Funktionen umfassen wiederholt konfigurierbare Bluetooth-Datenfilterung und Nutzlastberichterstattung. Das Gateway kann bestimmte Datenbytes aus einer BLE-Nutzlast filtern und nur die relevanten Informationen weiterleiten. LoRaWAN. Die Solar- und Makroebene LoRaWAN Bluetooth-Gateway Die Spezifikationen sind auch aufgeführt 105 max Leuchtfeuer unterstützt Und maximal 15 Beacon-Nachrichten in einem LoRaWAN Paket bei SF9.

Eine BLE-Gateway-Backhaul-Strategie sollte Nutzlastebenen definieren:

Nutzlastebene	Beispielinhalt	Optimale Rücklast-Passform
Minimale Präsenz	Beacon-ID, Gateway-ID, RSSI	LoRaWAN, NB-IoT
Ereignis plus Sensor	Beacon-ID, RSSI, Temperatur, Bewegung, Alarmbit	LoRaWAN mit Filterung, LTE-M
Rich Gateway Report	Mehrere Beacon-Datensätze, Diagnosedaten, Batteriestand, Zeitstempel	LTE-M, Kat. 1
Wartungsnutzlast	Protokolle, Firmware-Teile, erweiterte Diagnosen	LTE-M, Kat. 1

Das schlechteste Design ist ein unpräzise: “Beacon-Daten senden”.”

Welche Beacon-Daten? Jedes einzelne Paket? Jede eindeutige ID pro Intervall? Jede RSSI Stichprobe? Durchschnitt RSSI? Wann wurde man zuerst und zuletzt gesehen? Die 3 Stärksten LeuchtfeuerNur Alarmereignisse?

Diese Entscheidungen prägen alles und sollten vor der Installation getroffen werden.

Fehlermodus 4: Das Ausfallverhalten war nicht vorgesehen, sondern wurde nur erhofft.

Jedes Netzwerk versagt. Interessant ist, wie es versagt.

LoRaWAN-Ausfälle

In einem LoRaWAN Bei BLE-Gateway-Architektur kann die lokale BLE-Datenerfassung auch dann noch erfolgen, wenn die LoRaWAN Die Internetanbindung des Gateways ist gestört. Die Anwendung erhält möglicherweise erst dann neue Daten, wenn die Verbindung zum Gateway wiederhergestellt ist.

Wenn das Problem LoRa RF ist, verschieben Sie das LoRaWAN Ein Gateway oder eine optimierte Antennenplatzierung können Abhilfe schaffen. Wenn das Problem am Gateway liegt, ... LoRaWAN 4G-Backhaul des Gateways, dann BLE Gateways Das mag in Ordnung sein, und der Flaschenhals ist die Verbindung zwischen Gateway und Cloud.

Diese Unterscheidung ist wichtig. Ohne Diagnose sieht es in beiden Fällen so aus, als sei das Gateway offline.

NB-IoT/LTE-M-Ausfälle

Ausfälle bei NB-IoT und LTE-M sind üblicherweise auf das Signal, den Netzbetreiber, die SIM-Karte oder das Leistungsprofil zurückzuführen.

NB-IoT eignet sich hervorragend für verzögerungstolerante Berichte. Es ist weniger geeignet, wenn die Anwendung eine sofortige Downlink-Verbindung erwartet. LTE-M ist in der Regel die sicherere Wahl für mobile Geräte, Alarme und Firmware-Updates, da es eine bessere Mobilität und ein reaktionsschnelleres Downlink-Verhalten bietet. ⁽¹⁾

Ausfälle der Kategorie 1

Cat-1 stellt sich üblicherweise auf die gewohnte LTE/IP-Art wieder her. Dies ist hilfreich, wenn das Gateway gepufferte Datenpakete hochladen, die MQTT-Verbindung wiederherstellen oder Konfigurationsänderungen schnell empfangen muss.

Es kann aber auch zu einem gewaltigen Herdenproblem führen.

Stell dir 300 vor Gateways Nach einem Stromausfall am Standort wird die Stromversorgung wiederhergestellt. Jedes Gateway aktiviert sich, verbindet sich, überprüft die Konfiguration, lädt einen Backlog hoch und fordert die Zeitsynchronisierung an. Wenn die Firmware kein randomisiertes Backoff-Verfahren verwendet, führt die Wiederherstellung zu einem zweiten Ausfall.

Feldregel

Das Ausfallverhalten sollte vor dem Ausfall festgelegt werden.

Ein nützliches BLE-Gateway sollte Folgendes können:

• Ausgewählte Ereignisse lokal puffern
• Wiederholen mit Backoff, nicht Panik
• Berichten Sie, warum es Schwierigkeiten hatte, und nicht nur, dass es Schwierigkeiten hatte.
• Vermeiden Sie es, nach der Wiederherstellung der Stromversorgung alle Geräte gleichzeitig aufzuwecken.

Welche Backhaul-Verbindung passt zu welchem Einsatzgebiet?

Nun können wir den Vergleich anstellen, ohne so zu tun, als wären alle Projekte gleich.

1. Nur mit Batterie betriebenes Indoor-Gerät

Optimale Passform: LoRaWAN Makro oder Mikro Bluetooth-Gateway

Mögliche Passform: NB-IoT/LTE-M-Makro-Gateway, sofern die Netzabdeckung durch den Betreiber nachgewiesen ist

Verwenden Sie Kat.-1, wenn: Die Nutzdaten sind umfangreicher, die Downlink-Leistung ist wichtig oder das Meldeintervall ist nicht extrem aggressiv.

Der Einsatz von batteriebetriebenen Systemen in Innenräumen ist problematisch, da Techniker den Batteriewechsel an Gateways in Gebäuden fast genauso ungern durchführen wie im Freien. Deckenmontagen, Säulen in Lagerhallen, beengte Räume und Produktionsbereiche erschweren die Arbeit zusätzlich.

LoRaWAN ist die naheliegende erste Wahl, wenn der Standort eine private oder verwaltete Umgebung unterstützt. LoRaWAN Gateway. Lansitecs Macro Bluetooth-Gateway ist für den Einsatz in Innenräumen oder halb-Außenbereichen konzipiert, in denen keine externe Stromversorgung verfügbar ist, und verfügt über einen 38.000 mAh Akku, ein IP66-Gehäuse, einstellbare Intervalle und BLE-Nutzdatenfilterung.

NB-IoT/LTE-M ist sinnvoll, wenn der Kunde nicht möchte LoRaWAN Infrastruktur. Wählen Sie die Standorte jedoch nicht anhand einer Abdeckungskarte. Testen Sie die tatsächlichen Gateway-Positionen, insbesondere wenn sich das Gerät in der Nähe von Aufzügen, Stahlregalen, Stahlwänden, unterirdischen Bereichen oder Technikräumen befindet.

Cat-1 kann funktionieren, insbesondere mit großen Akkus und moderater Benachrichtigungsleistung. Wenn es aber nur darum geht, “zuletzt gesehen in Raum A”, ist Cat-1 wahrscheinlich überdimensioniert.

Unsere Einschätzung: Für die rein batteriebetriebene Indoor-Präsenz beginnen Sie mit LoRaWAN Es sei denn, die Eigentümerstruktur oder die Betreiberabdeckung zwingen Sie zu einem anderen Standort.

2. Solar-Außenbereich

Optimale Passform: LoRaWAN Solar Bluetooth-Gateway für private Websites

Mögliche Passform: NB-IoT/LTE-M oder Cat-1 Solar-Bluetooth-Gateway wo die Mobilfunkabdeckung stabil ist

Hauptrisiko: Autonomie bei Regenwetter plus Wiederholungsverhalten

Solaranlagen im Außenbereich sehen einfach aus, bis das Wetter umschlägt.

Lansitecs LoRaWAN Solar Bluetooth-Gateway verwendet ein 3-W-Solarpanel und ein 5300 mAh wiederaufladbarer Akku. Der Produktkatalog listet einen Monat lang ununterbrochen Regentage mit kontinuierlichem Bluetooth-Empfang und 60 Sekunden LoRaWAN Meldeintervall. Es unterstützt außerdem Bluetooth-Nutzdatenfilterung, TDMA und Datenkomprimierung.

Das ist ein starkes Outdoor-Profil.

Solaranlagen scheitern jedoch, wenn die Teams die Wiederherstellungsfähigkeit überschätzen. Ein Gateway mag zwar mehrere Tage mit Bewölkung überstehen, aber wenn es trotz schlechter Netzabdeckung aggressiv neue Verbindungen versucht, zu häufig meldet oder unnötigerweise ständig auf Verbindungen wartet, verringert sich die Reserve.

Mobilfunk Gateways sind nützlich, wenn LoRaWAN Die Infrastruktur ist nicht verfügbar. Cat-1 eignet sich besonders für abgelegene Grundstücke, Freilager, Gerätehöfe und temporäre Standorte, an denen der Kunde eine direkte Cloud-Anbindung wünscht.

Unsere Einschätzung: Bei Solaranlagen im Außenbereich geht es nicht nur um die Größe der Paneele. Es geht auch um die Disziplin, nach Unwettern Meldungen zu erstatten.

3. Gebäude mit ständiger Stromversorgung

Optimale Passform: LoRaWAN Indoor, SocketSync, NB-IoT/LTE-M Indoor oder Cat-1 Compact, je nach IT-Zugang

Hauptrisiko: Nicht Macht, sondern Netzwerkpolitik

Gebäude mit permanenter Stromversorgung verändern die Entscheidung.

Wenn Strom verfügbar ist, verlagert sich die Diskussion um die Backhaul-Verbindung von der Akkulaufzeit hin zu den Implementierungsproblemen. Kann Ethernet verwendet werden? Ist WLAN erlaubt? Wird das IT-Team ausgehende MQTT-Verbindungen genehmigen? Können Sie einen LoRaWAN Gateway auf dem Dach? Sind SIM-Karten einfacher als VLAN-Tickets?

In elektrisch betriebenen Innenräumen, LoRaWAN bleibt attraktiv, wenn der Standort ein lokales Gateway unterstützen kann. Lansitecs LoRaWAN Bluetooth-Gateway für den Innenbereich unterstützt 5V/1A Stromversorgung und kann empfangen 100 Beacon-Nachrichten innerhalb von 1 Sekunde, wobei maximal 15 Beacon-Nachrichten in einem Paket versendet werden.

NB-IoT/LTE-M oder Cat-1 bieten eine sauberere Lösung, wenn das Gebäudenetzwerk abgesichert ist. Krankenhäuser, Einkaufszentren, Logistikzentren und Einzelhandelsketten bevorzugen häufig Mobilfunk, da dieser interne Netzwerkgenehmigungen umgeht.

Unsere Einschätzung: Bei Gebäuden mit eigener Stromversorgung sollte die Backhaul-Verbindung so gewählt werden, dass sie der Kunde auch tatsächlich warten kann, und nicht diejenige, die hardwareseitig am günstigsten erscheint.

4. Temporäre Veranstaltungen, Mietflotten und Pop-up-Standorte

Optimale Passform: Cat-1 Compact oder NB-IoT/LTE-M Compact

Mögliche Passform: LoRaWAN Kompakt, wenn LoRaWAN Es besteht bereits eine Abdeckung.

Hauptrisiko: Einrichtungszeit und Wiederherstellungsverhalten

Temporäre Einsätze bestrafen infrastrukturintensive Lösungen.

Benötigt ein Kunde BLE-Abdeckung für eine Wochenendveranstaltung, eine Mietzone, ein temporäres Lager, eine Messe oder eine temporäre medizinische Versorgungsstation, ist direktes Mobilfunk oft die bessere Wahl. Cat-1 ist besonders nützlich, wenn das Gateway schnell online gehen, umfangreichere Daten übertragen und normale IP-Workflows unterstützen muss.

LoRaWAN Kompakt kann dennoch die bessere Wahl sein, wenn der Standort bereits über entsprechende Funktionen verfügt. LoRaWAN Abdeckung. Falls nicht, Einsatz einer LoRaWAN Ein Gateway, das lediglich zur Unterstützung einer zweitägigen Veranstaltung dient, könnte übertrieben sein.

Unsere Einschätzung: Bei temporären Standorten sollte die Einrichtung auf Zuverlässigkeit optimiert werden. Etwas höhere Datenkosten sind oft günstiger als ein zweiter Standortbesuch.

Eine praktische Auswahlmatrix

Einsatzszenario	LoRaWAN	NB-IoT/LTE-M	Katze-1
Nur mit Batteriebetrieb für den Innenbereich	Stärkste Passform, wenn LoRaWAN Infrastruktur ist möglich	Gut geeignet, wenn die Abdeckung getestet wurde und die Nutzlasten gering sind.	Vorsicht verwenden, am besten mit größerem Akku oder moderater Berichterstattung.
Solaranlage im Außenbereich	Hervorragend geeignet für private Standorte und niedrige laufende Kosten	Gut geeignet, wo die Mobilfunkabdeckung zuverlässig ist.	Stark geeignet für umfangreichere Nutzlasten und direkte Cloud-Anbindung
Gebäude mit ständiger Stromversorgung	Stark, wenn LoRaWAN Die Platzierung von Gateways ist zulässig	Gut geeignet, wenn der Zugang zum Gebäudenetzwerk blockiert ist.	Stark, wenn IP-Verhalten, MQTT/HTTP(S) und Reaktionsfähigkeit eine Rolle spielen.
Bewegliches Tor	Hängt davon ab LoRaWAN Abdeckungsplan	LTE-M ist besser als NB-IoT.	Passt perfekt
Hohes Nutzlastvolumen	Filterung und Komprimierung erforderlich	Besser als LoRaWAN, weiterhin profilabhängig	Stärkste Passform
Firmware-Updates	Funktioniert für Gateway-seitiges BLE FOTA Arbeitsabläufe sind wichtig, aber die Nutzlaststrategie zählt.	LTE-M ist besser als NB-IoT.	Die einfachste der drei
Niedrigste wiederkehrende Verbindungskosten	Oft am stärksten	SIM-Kosten erforderlich	Kosten für die SIM-Karte und erforderlicher Datentarif

Was wir protokollieren würden, bevor wir dem Radio die Schuld geben.

Hier ist eine schmerzhafte Lektion: “Offline” ist keine Diagnose.

Ein Gateway kann aufgrund von BLE-Scanning, Payload-Packing, Signalqualität, Backhaul-Verbindungszeit, Serverablehnung, SIM-Karten-Tarifbeschränkungen, Stromausfällen oder einer fehlerhaften Wiederholungsschleife ausfallen. Ohne die richtigen Protokolle wird jeder dieser Fehler zu einem Verbindungsproblem.

Bei BLE-Gateway-Projekten würden wir mindestens Folgendes protokollieren:

Protokolleintrag	Warum es wichtig ist
BLE-Scandauer und -intervall	Unterscheidet “fehlendes Beacon-Signal” von “fehlendem Uplink-Signal”.”
Anzahl der Beacons pro Bericht	Zeigt, wann die Nutzlastverpackung zum Problem wird
Nutzlastgröße	Enthüllt LoRaWAN Tarifdruck oder Datenvolumen-Anstieg
RSSI/SNR/SF für LoRaWAN	Hilft bei der Diagnose von Abdeckung, Kapazität und Ausbreitungsverhalten
RSRP/RSRQ/SINR für Mobilfunk	Zeigt an, ob der Stromverbrauch des Mobilfunknetzes durch ein schwaches Signal verursacht wird.
Zeitaufwand und Anzahl der Wiederholungsversuche hinzufügen	Zeigt Probleme auf Modem- und Betreiberseite auf
Batteriespannung vor und nach dem Uplink	Prüft, ob die Ausfälle strombedingt sind.

Hier erweisen sich langweilige Dashboards als wertvoll. LoRaWAN Ein Gateway, das bei SF12 festhängt, ein LTE-M-Gateway mit langen Verbindungszeiten und ein Cat-1-Gateway, das nach einem TLS-Fehler MQTT erneut versucht, mögen aus der Ferne alle ähnlich aussehen.

Die Payload-Strategie: Was sollte ein BLE-Gateway tatsächlich senden?

Ein gutes BLE-Gateway leitet nicht alles weiter. Es leitet nur das weiter, was die Anwendung nutzen kann. Für die meisten Tracking- und Präsenzanwendungen empfiehlt es sich, mit vier Nachrichtentypen zu beginnen:

1. Präsenzaktualisierung
   Beacon-ID, Gateway-ID, RSSI, Zeitstempel, Batteriestatus (falls vorhanden).
2. Ereignisaktualisierung
   Eintritts-, Ausgangs-, Panik-, Bewegungs-, Manipulations-, Überschreitungs- oder Alarmzustand.
3. Sensoraktualisierung
   Temperatur, Luftfeuchtigkeit, Vibration, Türstatus, Schrittzahl oder andere ausgewählte Daten.
4. Gesundheitsupdate
   Gateway-Batterie, Signalqualität, Firmware-Version, Anzahl der Meldungen, Anzahl der Wiederholungsversuche.

Die genaue Zusammensetzung hängt vom Rücktransport ab.

LoRaWAN Sie sollten kompakte Ereignis- und Statusdaten übertragen. NB-IoT/LTE-M verträgt mehr Sensorkontext, insbesondere bei seltenen Meldungen. Cat-1 kann umfangreichere Datenpakete und Diagnosedaten verarbeiten, profitiert aber dennoch von einer sauberen Filterung.

Lansitec-Produktpassung nach Installationstyp

Installationstyp	Lansitec-Passform	Warum
Nur mit Batteriebetrieb für den Innenbereich	LoRaWAN Makro Bluetooth-Gateway	Großer 38.000-mAh-Akku, konfigurierbare BLE-Filterung, lange Meldeintervalle
Kleine, mit Strom versorgte Innenräume	LoRaWAN Bluetooth-Gateway für den Innenbereich	5V/1A Stromversorgung, hohe BLE-Empfangskapazität, kompakte Installation
Solaranlage im Freien, privater Standort	LoRaWAN Solar Bluetooth-Gateway	3-W-Solarpanel, 5300-mAh-Akku, LoRaWAN Backhaul, Nutzlastfilterung
Solaranlage im Außenbereich ohne LoRaWAN	NB-IoT/LTE-M oder Cat-1 Solar-Bluetooth-Gateway	Direkte Betreiber-Netzwerk-Backhaul-Verbindung
Temporärer Standort oder Veranstaltung	Cat-1 Kompaktes Bluetooth-Gateway	Tragbar, zellular, geeignet für schnelle Einrichtung
Direkt-zu-Cloud-Gateway	NB-IoT/LTE-M- oder Cat-1-Familie	MQTT/HTTP-Serverpfad ohne lokale LoRaWAN Tor

Hier kommt die Produktpalette von Lansitec ins Spiel. Wir müssen nicht für jede Installation dieselbe Backhaul-Verbindung erzwingen. Ein Parkplatz, ein Krankenhausflur, ein Minengelände und eine spontane Veranstaltung erfordern unterschiedliche Lösungen.

Abschließende Empfehlung: Wählen Sie den Fehlermodus, den Sie beherrschen können.

LoRaWAN, NB-IoT/LTE-M und Cat-1 können alle für BLE-Gateway-Backhaul funktionieren. Sie fallen nur auf unterschiedliche Weise aus.

LoRaWAN Das System scheitert, wenn Teams Sendezeit, Nutzlastgröße, Spreizfaktor oder Gateway-Platzierung außer Acht lassen. Bei guter Planung bietet es jedoch eine ausgezeichnete Akkulaufzeit, hohe Kontrollierbarkeit und niedrige laufende Verbindungskosten.

NB-IoT/LTE-M versagt, wenn die Netzabdeckung, das Roaming, die Latenz und das Downlink-Verhalten des Betreibers angenommen statt getestet werden. Es ist jedoch sehr nützlich, wenn Kunden eine direkte Mobilfunk-Backhaul-Verbindung wünschen, ohne dafür ein eigenes Netzwerk aufbauen zu müssen. LoRaWAN Infrastruktur.

Cat-1 versagt, wenn Teams es wie LPWAN behandeln. Für umfangreichere Datenmengen ist mobiles Internet jedoch besser geeignet. Gateways, Dank schneller Einrichtung, direkter IP-Workflows und reaktionsschneller Wiederherstellung ist es möglicherweise die beste Wahl.

Die praktische Regel ist also einfach: Wählen Sie die Rückholvorrichtung, die Sie auch unter schlechten Bedingungen bedienen können, nicht die, die unter perfekten Bedingungen am besten aussieht.

Eine gut funktionierende BLE-Gateway-Implementierung wird nach der Installation etwas eintönig. Das Gateway scannt regelmäßig, filtert die empfangenen Daten, meldet die relevanten Informationen, wiederholt den Vorgang bei Bedarf und liefert der Plattform genügend Diagnosedaten, um Probleme zu beheben, bevor überhaupt jemand eine Leiter besteigen muss.

Referenzen und weiterführende Literatur:

1. GSMA: Leitfaden zur Bereitstellung mobiler IoT-Geräte
2. Quectel: LTE Cat 1 bis Module
3. The Things Network: EU863-870 MHz-Band
4. LoRa Alliance: RP002-1.0.5 LoRaWAN Regionalparameter