Es wird immer wieder scharf kritisiert dass LoRaWAN(R) keinen passenden Downlink Kanal zu Verfügung stellt. Wir werden in diesem Artikel diesem Umstand Rechnung tragen und das Thema aufgreifen. In verständlichen Worten versuchen wir hier ein paar Fakten wiederzugeben.
Vorneweg Sensoren die immer auf Empfangsbereitschaft eingestellt sind können niemals so sparsam betrieben werden, wie solche die nach dem verschicken ihrer Daten in eine Art Winterschlaf (Deep Sleep) gehen. In diesem Artikel werden also alle Betrachtungen bezüglich Energieeffizienz zurückgestellt. Solche Betrachtungen müssen immer in Zusammenhang mit der jeweiligen Anwendung analysiert werden.
LoRa – ohne dem WAN – beschreibt weitgehend die Funkmodulation, als wie z.B. ein LoRa Funk Sender mit einem anderen Empfänger über die Luftschnittstelle kommunizieren kann. Begriffe wie: Modulation, Funkkanal, Duty Cycle ,… . Wo hingegen LoRaWAN dem gesamten Netzwerk Protokoll Aufbau definiert und vorschreibt.
LoRaWAN® als LPWAN (Low Power Wide Area Network) wird in den allermeisten fällen als sternförmiges Funknetzwerk betrieben, ähnlich einem Wifi Netzwerk bei denen sich alle Clients (Notebooks, Tablets, …) auf einen (oder unter Umständen meheren) Accesspoint(s) verbinden. Im Falle von LoRaWAN reden wir von Gateways (GW) die wiederum mit dem zentralen LoRaWAN Netzwerkserver verbunden sind.
In unserem Fall kann es aber vorkommen, dass ein Sensor oder End-Node gleich mehrere Gateways erreicht, speziell im städtischen Umfeld wird hier ganz bewusst eine Überdeckung gewünscht. Im Networkserver kann dann hier die notwendige Filter Logik implementiert werden.
Ergänzend ist dieses Funknetzwerk nach dem ALOHA Verfahren aufgebaut, alle Sensoren versuchen ihre Daten über Funk zu übertragen dabei kann es passieren dass die Pakete von einem Sensor in einem der 8+2 Kanäle durch einen anderen Sensor gestört werden. Nach einer „Zufallszeit“ versucht er es erneut und hofft dass diesmal der Kanal nicht gestört ist.
LoRaWAN definiert zehn Kanäle, von denen 8 eine Mehrfachdatenrate von 250 bps bis 5,5 kbps haben, ein einzelner LoRaWAN-Kanal mit hoher Datenrate bei 11 kbps und einen einzigen FSK-Kanal von 50 kbps.
LoRaWAN Sensor Klassen
LoRaWAN definiert jetzt drei Arten von Sensoren / End Nodes, speziell in Hinblick auf den Downlink Kanal, also vom Gateway zum End Node
End Nodes der Klasse A können nur in einem definierten Zeitfenster nach einem Uplink z.B. nachdem Bodenfeuchtigkeitswerte an die „Zentrale“ übermittelt wurden Werte aus derselben empfangen. Dieses Receive (Rx) Zeitfenster, typische Werte sind 1 sec., muss der LoRa Transceiver (Sende / Empfangselektronik) aktiv bleiben und verbraucht in dieser Zeit mehr Energie. Wichtig: Downlink Nachrichten können nur nach einem Uplink empfangen werde, die Latenzzeit für diesen Downlink kann sehr hoch sein. Manchmal werden kleine Statusmeldungen – also kurze Uplinks – vom Sensor dazu verwendet um Downlink Daten zu bekommen.
End Nodes der Klasse B umgehen dieses Problem des notwendigen Uplinks indem hier das Gateway ein periodisches Referenzsignal (alle 128 Sek.), einen sogenannten Beacon (BCN) ausstrahlt und das End Node (also der Sensor) darauf hin Empfangsfenster (Ping Solots, PNG) öffnet. Zwischen zwei Beacon Signalen die 128 Sekunden auseinander liegen, werden 4096 Ping Slots vom End Node eingefügt. Jeder Ping Slot kann dann vom Network Server verwendet werden um einen Downlink zu initiieren. Damit wird die Latenzzeit auch um ein vielfaches verbessert, der Energieverbauch steigt zwar aber auch hier muss im Vorfeld eine Architektur Analyse die Downlink Notwendigekeiten definieren. In dem Beacon Signal (BCNPayload) wird auch ein Zeitstempel (UTC like) mitgeschickt, darüber lassen sich dann auch End nodes wieder Zeit synchronisieren.
End Nodes der Klasse C sind ähnlich den Klasse B End Nodes aufgebaut, nur sind diesie hier immer Empfangsbereit (solange sie nicht etwas übertragen!). sie haben zwar die geringste Latenzzeit allerdings auch den höchsten Energieverbrauch.
Conclusio:
Der jeweilige Anwendungsfall (mit)entscheidet welche End Node Klasse zum Einsatz kommen sollte. In den allermeisten fällen muss die Latenzzeit gegen einen eventuell höheren Stomverbrauch abgewogen werden. End Nodes können sowohl Sensoren, also primär Uplink lastig, also auch Aktuatoren (Stellglied z.B. Ventil, Relais, …) sein. In letzterem Fall kann man eine hohe Latenzzeit nicht bedingungslos akzeptieren. Hier müssen Klasse B oder C End Nodes realisiert werden
