Meistens werden Sensordaten im LoRaWAN-Netzwerk als "unconfirmed Uplink" gesendet. Dabei wird das Datenpaket vom Sensor ausgesendet, jedoch erfolgt keine Prüfung, ob das Datenpaket auch tatsächlich von einem Gateway empfangen wurde. Für die meisten Geräte wie beispielsweise Wetterstationen, GPS-Tracker oder Smartmeter ist dies auch nicht erforderlich. LoRaWAN bietet aber auch die Möglichkeit, Datenpakete als "confirmed Uplink" bzw. "confirmed Downlink" zu senden, sodass die Gegenstelle (Gateway bzw. Endgerät) eine Empfangsbestätigung zurücksendet und somit den Datenempfang bestätigt. Diese Funktion ist für kritische Sensoren wie Alarmanlagen oder Rauchmelder vorgesehen, wo eine Alarmierung entsprechend bestätigt werden soll. In diesem Artikel geht es grundlegend um das Thema "cofirmed Uplink" mit einem Praxisbeispiel für das Heltec ESP32 LoRa Board auf Basis der LMIC-MCCI Library.

Wie funktioniert ein confirmed Uplink?

Jedes LoRaWAN Datenpaket besitzt einen MAC-Header. Im Header von einem LoRaWAN Datenpaket befindet sich zum Beispiel die Device-Address, Framecounter aber auch ein Message-Type (Nachrichtentyp). Damit wird definiert, um welche Art von LoRaWAN-Nachricht es sich bei dem ausgesendeten Datenpaket handelt. Dies kann ein JOIN-Request, JOIN-Accept oder eben auch Uplink/Downlink sein. Darüber hinaus wird auch genau definiert, ob es sich um einen "confirmed Uplink", "unconfirmed Uplink", "confirmed Downlink" oder "unconfirmed Downlink" handelt.

Angenommen es handelt sich beim Endgerät um einen Rauchmelder, wo soeben der Sensor Rauch detektiert hat. Daraufhin wird der Rauchmelder ein Alarm-Datenpaket mit dem Message-Type "Confirmed Uplink" im Header aussenden. Erreicht dieses Datenpaket ein Gateway, so wird dieses zum Netzwerkserver weitergeleitet. Der Netzwerkserver erkennt, dass es sich dabei um einen "confirmed Uplink" handelt und sendet ein "ACK" (Acknowledgement, Deutsch: Empfangsbestätigung) zurück. Der LoRaWAN Standard sieht vor, dass nach jeder Aussendung (egal ob als "confirmed" oder "unconfirmed" markiert), dass Endgerät für einen kurzen Zeitraum empfangsbereit bleibt. Dabei handelt sich um das sogenannte RX-Zeitfenster, wo Daten vom LoRaWAN Netzwerk zum Endgerät gesendet werden können. Es wird nun vom Netzwerkserver ein Downlink-Paket mit einem "ACK" im Header zum Endgerät zurückgesendet. Wird auch der ACK-Downlink vom Endgerät empfangen, so ist die Datenübertragung aus der Sicht des Endgerätes abgeschlossen.

Erreicht das Alarm-Datenpaket das Gateway bzw. den Netzwerk-Server nicht, so wird das Endgerät auch kein "ACK" in den RX-Zeitfenstern empfangen. Daraufhin wird meistens vom Endgerät das gleiche Datenpaket erneut ausgesendet. Wie oft dieser Sendevorgang wiederholt wird bzw. ob bei erneuter Aussendung auch die Sendeparameter (Sendeleistung, Spreading-Faktor etc.) geändert oder angehoben werden, entscheidet der Hersteller.

Wird mit der LMIC-MCCI Library gearbeitet, kann frei entschieden werden, ob der Uplink als "confirmed" oder "unconfirmed" gesendet wird. Wenn der Uplink als "confirmed" gesendet wird und es kommt keine Antwort mit einem "ACK", so wird standardmäßig das gleiche Datenpaket noch bis zu sieben Mal ausgesendet, bevor die Aussendung von diesem Datenpaket endgültig eingestellt wird. Diese Einstellung kann in der Library angepasst werden.

Folgende Zeile im Beispielcode sendet einen "unconfirmed Uplink" aus:

 LMIC_setTxData2(1, mydata, sizeof(mydata) - 1, 0);

Folgende Zeile im Beispielcode sendet einen "confirmed Uplink" aus:

 LMIC_setTxData2(1, mydata, sizeof(mydata) - 1, 1);

Beispielprojekt Heltec ESP32 Board

Um die Funktionalität von "confirmed Uplinks" testen zu können, gibt es für das Heltec ESP32 LoRaWAN Board einen Beispielcode. Dabei wird auch das Display verwendet, wo der aktuelle Status der Versuchsaussendung angezeigt wird. Der Beispielcode versucht unmittelbar nach dem JOIN im minütlichen Intervall einen "confirmed Uplink" auszusenden. Der Beispielcode und alle Details zu den verwendeten Bibliotheken gibt es hier: Beispielcode Confirmed Uplink