Grundlagen zur LoRa LoraWAN Technik und zum TheThingsNetwork. Es werden die Grundlegenden technischen und rechtlichen Rahmen beschrieben, so wie die unterschiedlichen Kommunikationsmodelle der Node gezeigt. Die Anmeldeprozeduren OTAA und ABP werden vorgestellt und ihre unterscheide gezeigt.

1. Grundlagen LoRaWAN
Workshop Visualisierung
Havetoft 2018

2. INTERNET OF THINGS
 Das Internet der Dinge ist ein Netzwerk in dem
physikalische Dinge miteinander reden können.
 Bis 2020 werden wahrscheinlich 25 Milliarden Geräte
miteinander reden können.
 Diese Geräte nutzen unterschiedliche Zugangswege in
das Netz, einer davon ist LoRa/LoRaWAN

3. Datenrate zu Reichweite
 LoRa, Sigfox und NB-IoT
 erreichen nur eine geringe
Übertragungsrate, dafür aber eine
sehr gute Reichweite.
 Wifi als eines der interessanten
Übertragungswege erreicht zwar
deutlich höhere Datenraten, die
Reichweite ist aber auf wenige
Meter begrenzt.
 Die Mobilfunknetze können zwar
Flächendeckend genutzt werden,
sie sind aber kostenpflichtig.

4. SEMTECH
 LoRa wurde von einem französischen StartUp Cycleo
entwickelt.
 2012 wurde Cycleo von Semtech aufgekauft.
 Das LoRa Radio und die Modulation ist Patentiert und
damit keine freie Software.
 Semtech lizenziert die Produktion an diverse Hersteller,
darunter der uns bekannte HopeRF welche die RFM9x
Radios unserer Sensoren herstellen.

5. Anwendungsbeispiele für LORA
 Smarte Geräte
Füllstände und Temperaturen
 Gesundheit und Hygiene
Abfallwirtschaft und Umweltdaten
 Sicherheit
Straßenbeleuchtung nach Notwendigkeit
 Effizienzsteigerung und Logistik
Wo steht meine Palette, Wie voll sind die Tanks von Baumaschinen
 Landwirtschaft
Heu- Strohmonitoring, Bodenwerte
 Smarte Städte und Regionen

6. Was bedeutet LoRa
 LoRa steht als Akronym für Long Range und es
bezeichnet den Physikalischen Layer
 Es besteht aus mindestens einem Node und einem
Gateway als Gegenstelle
 So wie einer notwendigen Serverstruktur die diese Daten
verarbeiten kann

7. LoRa und LoRaWAN
Wo befindet sich LoRa und LoRaWAN im Protokoll Stack
LoRaWAN
LoRa

8. Das LoRaWAN Netzwerk

9. Exkurs LoRa ohne Gateway
 Da LoRaWAN keine direkte Kommunikation zwischen zwei
Nodes ermöglicht hilft mal wieder die Community
 Das Stichwort ist RadioHead. Es gibt zwar kein offizielles
Repo dafür aber einige haben die Libs gecloned.
 Mehr Infos findet ihr unter
https://www.airspayce.com/mikem/arduino/RadioHead/

10. Regeln und Vorschriften
Das schönste Spielzeug funktioniert nicht ohne Spielregeln.
 LoRa arbeitet im ISM (Industrial, Scientific and Medical) Funkbereich.
 In Europa ist dies zur Zeit der 868 MHz die EU hat sich aber darauf geeinigt
auch den Bereich von 915 MHz freizugeben. Somit sind dann fast weltweite
Anwendungen im selben Funkbereich möglich.
 ISM darf Lizenzfrei von allen genutzt werden.
 Die Nachteile im ISM Band sind die geringe Datenrate und die vielen
Interferenzen. Um dies Band für viele Nutzbar zu halten darf LoRa nur eine
eingeschränkte Airtime belegen.

11. ISM Band EU Regeln

 Der Uplink darf maximal mit 25mW (14dBm) senden.
 Der Downlink maximal 0,5W (27dBm)
 Es existiert ein 0,1% und 1% Grenzwert der Airtime am
Tag.

12. TTN FAIR USE
 Die Uplink-Sendezeit ist auf 30 Sekunden pro Tag (24
Stunden) pro Knoten begrenzt.
 Die Downlink-Nachrichten sind auf 10 Nachrichten pro Tag
(24 Stunden) pro Knoten beschränkt.

13. Exkurs Airtime und Duty cycle
TX RadioTX Radio RX Radio
Sende
r
Empfäne
r
T =
airtime
Airtime
Die Zeit zwischen Sender und
Empfänger wird als Airtime
bezeichnet
Duty cycle
Der Arbeitszyklus ist der Anteil der Zeit,
während der sich eine Komponente, ein Gerät
oder ein System befindet betrieben.
Das Tastverhältnis kann als Verhältnis oder als
Prozentsatz ausgedrückt werden.
Wie bereits erwähnt, gibt es in Europa einen
Arbeitszyklus von 0,1% und 1,0% pro Tag
abhängig vom Kanal.

14. Berechnung des Arbeitszyklus
Signal Signal
Wartezeit
Signal Signal
Wartezeit
Beispiel
Airtime
530mS
Arbeitszyklus
1%
Beispiel
Airtime
530mS
Arbeitszyklus
0,1%
99 x 530 = 52,47 Sekunden
99%
530m
S
1%
530m
S
0,1%
999 x 530 = 529,47 Sekunden
99,9%

15. LoRa Geräteklassen
Klasse Beschreibung
A Batterie betriebenes Gerät. Jedem Sendezyklus zum Gateway folgen zwei
kurze Empfangsfenster um Daten im Downlink zu erhalten.
B Das selbe wie A nur öffnet diese Gerät zusätzlich zu bestimmten Zeiten
ein Empfangsfenster. Das Gateway muss dazu ein Beacon aussenden.
C Das selbe wie ein A Gerät aber es ist zusätzlich zu jederzeit bereit Daten
zu empfangen. Da dadurch deutlich mehr Energie benötigt wird sind diese
Geräte meistens mit einem Netzanschluss ausgestattet.

16. Class A
TX
Übertragung
RX
Slot 1
RX
Slot 2
t1
t2
 Der Node kann zu jeder Zeit eine Datenübertragung starten (tx). Nach dieser
Übertragung lauscht der Node auf eine Antwort vom Gateway.
 Der Node öffnet zwei Empfangsfenster zu t1 und t2 wenige Sekunden nach
dem Senden einer Nachricht.
 Das Gateway kann das erste oder das zweite Fenster nutzen um eine Nachricht
zum Node zu senden, aber niemals beide.
 Class B und C müssen immer auch Class A unterstützen

17. Class A
Class B
TX
Node RX RX
Ping
Time
Beacon
Time
 Zusätzlich zu den Class A rx Fenstern öffnen Class B Nodes zu bestimmten
Zeiten zwischen zwei Beacon die vom Gateway gesendet werden zusätzlich rx
Fenster
 Die Beacon der Gateways dienen der Synchronisation, so kann auch das
Gateway die rx Fenster der Nodes berechnen.
 Class A und B Nodes unterstützen dabei aber keine Class C Funktionalität
RX RX RX RX

18. Class A
Class C
TX
Node RX RX
 Zusätzlich zu den Class A rx Fenstern öffnen Class C Nodes bis zum nächsten
Daten senden ein offenes rx Fenster. Somit hört ein Class C Node sehr lange
auf eine Nachricht des Gateways
 Class A und C Nodes unterstützen dabei aber keine Class B Funktionalität.
 Diese Funktionalität verbietet den Schlafmodus eines Nodes und verbraucht
viel Energie so das ein Akku Betrieb nicht sinnvoll ist.
RX Fenster offen bis zum nächsten TX
TX
Node

19. Ausbreitung von Funkwellen
 Funkwellen breiten sich nicht linear zwischen Sender und
Empfänger aus. Sie verlieren durch das zu durchdringende
Medium an Kraft, das Signal wird schwächer je weiter ein
Sender vom Empfänger entfernt ist.
 Um eine mögichst gute Übertragung zu erhalten ist nicht
nur eine möglichst freie Strecke existieren sonder auch
eine sogenannte Fresenellzone muss frei sein. Dies ist der
Bereich unter und über der direkten Linie zwischenTX und
RX

20. Link Budget

21. Fachbegriffe im TTN Tracker
 RSSI
Received Signal Strength Indication
Dies ist im Endeffekt die Signalstärke die beim Empfänger noch ankommt und muss
bei LoRaWAN besser als -120 dBm sein. Schlechtere Signale können nicht mehr
empfangen werden.
 SNR
Signal-to-Noise Ratio
Der Signal Rausch Abstand einer typischen LoRa Verbindung liegt im Bereich von
+10 bis -20 dBm. Schlechtere Signale können nicht mehr aus dem
Hintergrundrauschen heraus gefiltert werden um noch ein Signal zu decodieren.
Positive Werte bedeuten das Signal liegt noch oberhalb des Hintergrundrauschens,
negative Werte bedeuten das ein Signal von Hintergrundrauschen überlagert wurde.

22. Aktivierungstechniken von Nodes
 Jeder Node muss sich im Netzwerk anmelden, damit seine
Applikation gefunden werden kann und die Übertragung
entsprechend verschlüsselt wird.
 Es existieren zur Zeit zwei Methoden, um einen Node zu
aktivieren.
 OTAA Over the Air Activation
 ABP Aktivation by Peronalisation

23. OTAA
 OTAA ist die empfohlene Methode, um einen Node zu
aktivieren. Hierbei wird die höchste Sicherheit in der
Übertragung gewährleistet.
 Der Node muss nur die DevEUI, AppEUI und den AppKey
kennen.
 Der Netzwerkserver muss den selben AppKey gespeichert
haben.
 EUI steht dabei für Extended Unique Identifier und ist ein

24. OTTA
 Die DevEUI ist die eindeutige Identifizierungsnummer
eines Endgerätes, vergleichbar mit der MAC Adresse.
Einige Nodes werden schon mit einer eigenen DevEUI
ausgeliefert.
 Die AppEUI ist die eindutige Identifizierung einer
Applikation, die in etwa mit einem Port vergleichbar ist.
 Der AppKey ist eine AES ((Advanced Encryption Standard)
128bit langer Schlüssel. Dieser wir benutzt, um einen
Message Integrity Code (MIC) zu erstellen. Dieser MIC

25. OTAA
 Das Endgerät generiert die DevNonce, die eine zufällig
generierte Nummer ist. Dieses verhindern, dass Angreifer
den Join-Request erneut abspielen können.
 Das Endgerät erstellt eine Nachricht, die DevNonce,
AppEUI und DevEUI enthält.Über diese Nachricht wird der
Message Integrity Code (MIC) vom AppKey generiert.
 DevNonce, AppEUI und DevEUI werden vom AppKey nicht
verschlüsselt.
 Das Endgerät kann sich nun selbst aktivieren, indem es

26. OTAA
 Nachdem der Netzwerkserver die Join-Request-Nachricht
erhalten hat, wird geprüft, ob die DevNonce bisher noch
nicht verwendet wurde.
 Der Netzwerkserver authentifiziert das Endgerät mit dem
MIC-Wert. Wenn er es akzeptiert, werden die folgenden
Werte vom Netzwerkserver generiert:
 DevAddr (Geräteadresse)
Der DevAddr ordnet das DevEUI einer netzwerkinternen
kürzeren Adresse (32 Bit) in zu um den Protokollaufwand in
übertragenen Frames zu reduzieren. Der DevAddr ähnelt einer

27. OTAA
 Der Netzwerkserver erstellt eine Nachricht, die DevAddr,
AppNonce und NetID enthält und einige
Netzwerkeinstellungen.
 Diese Netzwerkeinstellungen sind:
 Download Settings (DLSettings)
 Receive Delay (RXDelay)
 Channel Frequency List (CFList)

28. OTAA
 Über diese Nachricht wird der Message Integrity Code
(MIC) vom AppKey generiert.
 Die Nachricht selbst wird mit dem AppKey verschlüsselt.
 Der Netzwerkserver sendet eine Join-Accept-Antwort an
das Endgerät zurück mit der verschlüsselte Nachricht und
dem MIC.
 Jetzt teilen sich das Endgerät und der Netzwerkserver das
gleiche AppNonce und DevNonce.

29. OTAA
 Das Endgerät und der Netzwerkserver verwenden
AppNonce und DevNonce zum Generieren zwei
Sitzungsschlüssel: der Netzwerksitzungsschlüssel
(NwkSKey) und die Anwendungssitzung Schlüssel
(AppSKey).
 Der Netzwerkserver sendet den AppSKey und den
DevAddr an den Anwendungsserver.
 Der NwkSKey wird vom Endgerät und vom
Netzwerkserver zur Berechnung und Überprüfung der

30. OTAA
 Die Nutzdaten werden Ende-zu-Ende zwischen Endgerät
und Anwendung verschlüsselt, aber sie sind nicht auf
Integrität geschützt.
 Dies bedeutet, dass ein Netzwerkserver möglicherweise
den Inhalt der Datennachrichten im Transit ändern kann .
Netzwerkserver gelten als vertrauenswürdig.

31. ABP
 Activation-By-Personalisation (ABP) ist die zweite
Möglichkeit einen Node zu aktivieren.
 Es werden keine Join Nachrichten ausgetauscht.
 Der Node kann sofort mit den festgelegten Keys mit dem
Netzwerk kommunizieren

32. ABP
 Das Endgerät speichert DevEUI, AppEUI und AppKey
nicht.
 Der Netzwerkserver speichert den AppKey nicht.
 Stattdessen wird das Endgerät mit DevAddr, AppSKey und
NwkSKey vorgeladen.

33. LORAWAN SECURITY
 Alle LoRaWAN-Geräte müssen ihre Nutzdaten und Header
mit dem AES-Algorithmus (Advanced Encryption Standard)
mit 128-Bit-Schlüsseln verschlüsseln
 Das LoRaWAN-Protokoll bietet zwei Sicherheitsebenen:
 Der Payload wird vom Endgerät zum Netzwerkserver
verschlüsselt.
 Auf der Netzwerkschicht wird die Integrität einer Nachricht
durch die Message-Integrität-Code (MIC) mit dem NwkSkey

34. Über uns
 Den Nucleon e.V. findet ihr im Netz unter:
https://nucleon-ev.eu/
 Direkten Kontakt könnt ihr in der Matrix mit uns
aufnehmen.
https://matrix.to/#/#iotde:matrix.ffslfl.net
 Oder per Mail
Vorstand@nucleon-ev.eu