LoRaWAN mit TTN v3 - Quick Start

Diese Informationsseite soll dir einen schnellen Einstieg in das Themengebiet LoRaWAN geben. Es kann jedoch nicht deine eigene, ausführliche Recherche ersetzen sondern stattet dich lediglich mit den notwendigsten Grundlagen aus, damit du dich zurechtfindest.

Eine weitaus ausführlichere Zusammenfassung findest du unter:

https://lora-developers.semtech.com/documentation/tech-papers-and-guides/lorawan-class-a-devices/

The Thinks Network (aktuell Version 3, auch The Things Stack TTS) ist ein globales LoRaWAN-IoT-Netzwerk, das in der Community-Version frei genutzt werden kann und über zahlreiche freiwillige Gateway-Betreiber seine weltumspannende Reichweite erlangt. Das fiktive Unternehmen LIFtOff GmbH betreibt selbst ein solches Gateway.

Eine Landkarte mit derzeit aktiven Gateways findet man hier.

Am Beispiel eines Temperatursensors wird hier der Kommunikationsverlauf Schritt für Schritt nachvollzogen.

Bild: Typische LoRaWAN-Netzwerk-Implementierung

1. Der Temperatursensor (Endgerät) verschickt in regelmäßigen Zeitabständen ein LoRa-Paket, in dem die Messwerte enthalten sind.
2. Befindet sich der Sensor in Reichweite eines Gateways, dann empfängt dieses das LoRa-Paket. Es überträgt die Daten weiter an den LoRaWAN-Netzwerkserver. Dabei ist es egal, wer das Gateway betreibt, solange es mit dem TTN verbunden ist.
3. Vom Netzwerkserver wird das Paket an den Applikationsserver weitergeleitet. Dort kann es anhand des beiliegenden Schlüsselmaterials einer bestimmten Applikation zugeordnet werden.
4. Die Applikation auf dem Applikationsserver verarbeitet die eingegangenen Daten und stellt sie auf verschiedene Arten berreit.
5. Unter anderm publiziert die Applikation die eingegangenen Daten auf dem MQTT-Broker des TTN.
6. Dein eigener MQTT-Client auf deinem Node-RED-Server kann das zugehörige Topic abonnieren und erhält dadurch umgehend die eigegangenen Daten.

Der ebenfalls abgebildete Join Server spielt eine Rolle bei der Anmeldung von Endgeräten am Netzwerk.

Endgeräte können auf zwei verschiedene Arten am Netzwerk angemeldet werden. Die einfachere aber auch weniger flexible und weniger sichere Variante ist Activation by Personalization (ABP). Dabei werden auf dem Endgerät und im Netzwerk feste Schlüssel eingetragen (AppSKey, NwkSKey). Diese bleiben über die gesamte Lebensdauer des Gerätes gleich.

Die bevorzugte Methode ist Over-the-Air Activation (OTAA). Dabei meldet sich ein Endgerät zuerst beim Join Server. Verläuft die Authentifizierung erfolgreich, können die Sitzungschlüssel (AppSKey, NwkSKey) ausgetauscht und regelmäßig erneuert werden.

Die wichtigsten Schlüssel und IDs im Umgang mit LoRaWAN-Endgeräten finden Sie hier tabellarisch zusammengefasst.

Wie oben bereits geschildert, stellt eine TTN-Applikation die eingehenden Daten ihrer Endgeräte unter anderem über MQTT bereit.

Die Adresse des Servers lautet eu1.cloud.thethings.network und zu Port 8883 kann eine TLS-verschlüsselte Verbindung aufgebaut werden. Der Benutzername setzt sich aus dem Applikationsnamen und der Erweiterung @ttn zusammen. In unserem Fall also beispielsweise: liftoff-beispiel@ttn

Als Kennwort wird ein extra erzeugter API-Key verwendet. Mit ihm können in der TTN-Konsole bestimmte Berechtigungen verbunden werden, z. B. Uplink Messages zu lesen (vom Endgerät zur Applikation) und Downlink Messages zu publizieren (von der Applikation zum Endgerät).

Wie du bereits weißt, sind die Informationen bei MQTT nach Topics gegliedert. Im TTN ist eine feste Struktur vorgegeben. Der erste Teil der Topics, die ein bestimmtes Endgerät betreffen, folgt diesem Schema:

v3/<Applikations-ID>@ttn/devices/<Geräte-ID>/

Dahinter ist dann mit weiteren Verzweigungen die eigentliche Kommunikation nachvollziehbar. Das Topic up enthält die vom Endgerät gesendeten Daten, das Topic down enthält die Topics sent und qeued mit gesendeten und zu sendenden Downlink-Nachrichten und außerdem die Topics push und replace um Downlink-Nachrichten in die Warteschlange einzureihen oder die Schlange damit zu ersetzen.

Das Topic für die Uplink-Nachrichten mit den gemessenen Temperaturwerten für den Sensor aus dem Beispiel rechts könnte so lauten:

v3/liftoff-beispiel@ttn/devices/temp-innen/up

Der Payload für eine Downlink-Nachricht könnte folgendermaßen aussehen:

{
  "downlinks": [
    {
      "f_port": 1,
      "confirmed": false,
      "frm_payload": "MjoxMzoyNSBQTQ=="
    }
  ]
}

Ein besonders hilfreiches Werkzeug ist hier der MQTT-Explorer.

Damit der Energieverbrauch bei LoRa-Geräten gering gehalten werden kann, verbringen Sie grundsätzlich den Großteil ihrer Zeit im Schlafzustand. In diesem Zustand sind sie auch nicht in der Lage Downlink-Nachrichten zu empfangen. Dies trifft vor allem auf Klasse-A-Geräte zu. Klasse-B-Geräte bieten zusätzlich regelmäßige Zeitfenster an um Nachrichten zu empfangen und Klasse-C-Geräte sind ständig auf Empfang und daher meist nicht batteriebetrieben.

Klasse-A-Geräte können nur Nachrichten empfangen, nachdem sie selbst eine Uplink-Nachricht versendet haben. Deshalb werden Downlink-Nachrichten auch in eine Warteschlange eingereiht. Eine bestimmte Zeit nach dem Ende der Uplink-Nachricht wartet ein Klasse-A-Gerät bis zu zwei mal auf eingehende DownlinkNachrichten.

Bild: Empfangszeitfenster Rx1 und Rx2 wenn keine Downlink-Nachrichten eingehen

Bild: Empfangszeitfenster Rx1, wenn im ersten Zeitfenster eine Downlink-Nachricht eingeht

Bild: Empfangszeitfenster Rx1 und Rx2 wenn im zweiten Zeitfenster eine Downlink-Nachricht eingeht

Ein Gerät sendet erst dann wieder Uplink-Nachrichten, wenn

• es im Zeitfenster Rx1 eine Downlink-Nachricht erhalten hat oder
• die Übertragung im Zeitfenster Rx2 vollständig ist oder
• Rx2 verstrichen ist.