-
Notifications
You must be signed in to change notification settings - Fork 0
/
lorawan.tex
211 lines (159 loc) · 16.5 KB
/
lorawan.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
\chapter{LoRaWAN}
Mittels \gls{LoRaWAN} können über LoRa kommunizierende Endgeräte in ein Netzwerk eingebunden werden und bilden damit ein Wide Area Network (WAN).
LoRaWAN gibt dabei die Systemarchitektur und die zur Kommunikation genutzten Protokolle vor.
\section{Architektur}
Der grundlegende Architektur von LoRaWAN ist in \autoref{img.lorawan-architecture} dargestellt.
Die Komponenten sind von links nach rechts mit steigender Abstraktion von der eigentlichen LoRa-Kommunikation angeordnet.
Eine Nachricht vom Endgerät zur Applikation hin wird als \gls{Uplink}, eine Nachricht von der Applikation zum Endgerät hin als \gls{Downlink} bezeichnet.
\cite{lorawanarchitecture}
\image{lorawan-architecture}{img.lorawan-architecture}{\textwidth}{Systemarchitektur bei LoRaWAN}{Systemarchitektur bei LoRaWAN}{bearbeitet aus Zerynth srl, https://www.zerynth.com/wp-content/uploads/2017/05/lorawan-architecture.jpg}
Im folgenden werden die einzelnen Komponenten von LoRaWAN näher erläutert und jeweils deren Verhalten bei einem Up- und Downlink beschrieben.
\subsection{Endgerät}
Endgeräte, auch als \glspl{Node} bezeichnet, werden über das LoRaWAN vernetzt und können Daten zur Applikation senden bzw. von dieser empfangen.
Nodes kommunizieren ausschließlich über LoRa mit dem LoRaWAN, müssen also über die dafür notwendige Hardware (LoRa-Chip, Antenne) verfügen.
Häufig sind Nodes auf besonders energiesparsamen Betrieb ausgelegt und batteriebetrieben.
Um die in \autoref{sec.lora.basics} beschriebenen gesetzlichen Vorgaben einzuhalten, sind die Sendeintervalle vergleichsweise hoch (Minuten bis Stunden oder Tage).
\subsubsection{Uplink}
Ein Node kann Daten per LoRa senden.
Dazu wird auf die Nutzdaten (\gls{Payload}) zuerst die Applikationsverschlüsselung angewendet, darauf wiederum die Netzwerkverschlüsselung.
Per LoRa gesendete Pakete können von allen Nodes und Gateways im Sendebereich empfangen werden.
\subsubsection{Downlink}
Nodes können in verschiedene Geräteklassen eingeteilt werden (siehe \autoref{sec.lorawan.classes}) und sind davon abhängig zu unterschiedlichen Zeiten empfangsbereit.
Wird während eines Empfangsfensters eine an den Node adressierte Nachricht vom Gateway empfangen, so erfolgt die Entfernung der verschiedenen Verschlüsselungsschichten und anschließend die Verarbeitung der Nutzdaten.
\subsection{Gateway}
Ein \gls{Gateway} bildet die Schnittstelle zwischen der Funkkommunikation per LoRa und den restlichen Komponenten des Netzwerks.
LoRa zur Datenübertragung wird somit lediglich zwischen Endgeräten und Gateways genutzt.
In einem LoRaWAN können beliebig viele Gateways genutzt werden.
Durch hinzufügen von Gateways an bisher wenig nicht oder schlecht angebundenen Orten, kann auf einfache Weise die Netzabdeckung verbessert werden.
\subsubsection{Uplink}
Ein Gateway empfängt die von den Endgeräten über LoRa gesendeten Nachrichten.
Außerdem werden Metadaten wie Signalstärke und \gls{SNR} der empfangenen Signale bestimmt.
Die Nutzdaten der LoRa-Nachricht und die Metadaten werden vom Gateway an den Netzwerkserver weitergeleitet, üblicherweise per Internet.
\subsubsection{Downlink}
Ebenso kann das Gateway Daten vom Netzwerkserver empfangen.
Diese werden per LoRa gesendet und können von Endgeräten in Reichweite des Gateways empfangen werden.
\subsection{Netzwerkserver}
Der \gls{Netserver} bildet im LoRaWAN das zentrale Element für das Routing der von Endgeräten empfangenen und an diese zu sendenden Nachrichten. Es gibt genau einen Netzwerkserver im LoRaWAN.
\subsubsection{Uplink}
Der Netzwerkserver verarbeitet die von den Gateways empfangenen Nachrichten.
Wie in \autoref{img.lorawan-architecture} unten links dargestellt, kann die gesendete Nachricht eines Endgeräts von mehreren Gateways gleichzeitig empfangen werden.
Dabei leitet jedes Gateway die Nachricht an den Netzwerkserver weiter.
Durch Vergleich des (teilw. verschlüsselten) Dateninhalts der Nachricht können mehrfach empfangene Nachrichten im Netzwerkserver zu einer einzigen Nachricht zusammengefasst werden.
Dies wird auch als Deduplizierung bezeichnet.
Außerdem wird für jedes Endgerät gespeichert, über welches Gateway die Signalqualität der empfangenen Daten am besten ist.
Sofern das Endgerät, von dem die Nachricht empfangen wurde, im Netzwerk aktiviert ist (siehe \autoref{sec.lorawan.activation}), kann die Netzwerkverschlüsselung der Nachricht entfernt werden.
Die entschlüsselten Daten werden an den Applikationsserver weitergeleitet, der für dieses Endgerät festgelegt wurde.
\subsubsection{Downlink}
Ebenso kann der Netzwerkserver Downlinkpakete vom Applikationsserver empfangen.
Diese werden zunächst in einer Warteschlange gespeichert (Downlink-Queue).
Abhängig von der Geräteklasse des adressierten Endgeräts erfolgt die weitere Verarbeitung direkt oder durch bestimmte Auslöser (siehe \autoref{sec.lorawan.classes}).
In der Weiterverarbeitung werden die Paketdaten zunächst der Netzwerkverschlüsselung unterzogen.
Außerdem wird für das adressierte Endgerät das Gateway bestimmt, welches aktuell wahrscheinlich die besten Übertragungsbedingungen zum Endgerät hat.
Dies wird anhand der gespeicherten Daten über die Signalqualität vorheriger Uplinks durchgeführt.
Anschließend werden die verschlüsselten Daten an das ermittelte Gateway weitergeleitet.
Ein Paket im Downlink wird also immer nur über genau ein Gateway gesendet.
\subsection{Applikationsserver}
Ein \gls{Appserver} dient der Ent- bzw. Verschlüsselung der Applikationsdaten und ist die Schnittstelle des LoRaWAN zu den eigentlichen Anwendungen.
Im LoRaWAN kann es beliebig viele Applikationsserver geben.
\subsubsection{Uplink}
Ein Applikationsserver empfängt vom Netzwerkserver gesendete Daten.
Dabei wird zunächst die Applikationsverschlüsselung entfernt.
Anschließend sind die eigentlichen vom Endgerät gesendeten Daten (\gls{Payload}) im Klartext verfügbar und können beliebig verarbeitet werden.
Die Metadaten der LoRa-Kommunikation, welche durch die Gateways erfasst wurden (z.\,B. \gls{SNR}), sind ebenso Bestandteil der im Applikationsserver verfügbaren Daten.
Die weitere Verarbeitung der Uplinks ist allerdings nicht mehr Bestandteil der Architektur von LoRaWAN.
\subsubsection{Downlink}
Im Applikationsserver können außerdem Downlinks gestartet werden, also Nachrichten zum Endgerät gesendet werden.
Dabei werden die Daten der Applikationsverschlüsselung unterzogen und das Paket an den Netzwerkserver gesendet.
\subsection{Join-Server}
Damit eine Kommunikation mit Endgeräten im LoRaWAN möglich ist, müssen diese aktiviert werden (siehe \autoref{sec.lorawan.activation}).
Ein Teil des Aktivierungsprozesses erfolgt dabei über den \gls{Joinserver}, insbesondere die Verteilung der Sitzungsschlüssel für die Netzwerk- und Applikationsverschlüsselung.
Im Join-Server wird außerdem der Root-Key für die Verschlüsselung verwaltet, aus dem die genannten Sitzungsschlüssel abgeleitet werden.
Der Join-Server bildet damit ein wichtiges Element zur Sicherstellung der verschlüsselten Kommunikation.
Daher ist dieser insbesondere aus dem Netzwerkserver ausgegliedert, um ein Mitlesen der Applikationsdaten durch den Betreiber des Netzwerkserver zu verhindern.
Im LoRaWAN kann es beliebig viele Join-Server geben, die Zuordnung eines Endgeräts zu einem Join-Server muss allerdings eindeutig sein.
\section{Verschlüsselung}
Nachrichten im LoRaWAN verfügen über mehrere Schichten der Verschlüsselung, um nur denjenigen Komponenten Zugriff auf Daten zu gewähren, wie zum Betrieb des Netzwerks notwendig sind.
Im folgenden sind die Schritte für einen Uplink beschrieben, im Falle eines Downlinks ist die Reihenfolge entsprechend umgekehrt und Ver- und Entschlüsselung sind vertauscht.
Die Anwendungsdaten (\gls{Payload}) werden mit dem 128\,Bit-AES-Applikationssitzungsschlüssel im Endgerät verschlüsselt.
Diese verschlüsselten Daten werden (zusammen mit weiteren für den Netzwerkserver relevanten Daten) im Endgerät mit dem 128\,Bit-AES-Netzwerksitzungsschlüssel verschlüsselt und (ergänzt um zur Adressierung notwendige Daten) per LoRa gesendet.
Geräte, die diese ausgesendeten Daten mithören, haben aufgrund der Verschlüsselung keinen Zugriff auf die Daten, lediglich die Geräteadresse wird unverschlüsselt übertragen.
Auch Gateways können den Inhalt der durch sie weitergeleiteten Pakete nicht mitlesen.
Im Netzwerkserver erfolgt die Entschlüsselung mit dem Netzwerksitzungsschlüssel und der Netzwerkserver erhält Zugriff auf die benötigten Daten.
Die Anwendungsdaten sind allerdings weiterhin verschlüsselt und somit nicht durch den Netzwerkserver lesbar.
Im Applikationsserver erfolgt schlussendlich die Entschlüsselung mit dem Applikationssitzungsschlüssel.
Damit erhält neben dem Endgerät nur der Applikationsserver Zugriff auf die Anwendungsdaten.
\section{Aktivierung}\label{sec.lorawan.activation}
Damit ein Endgerät im LoRaWAN erfolgreich kommunizieren kann, muss es aktiviert sein.
Die Aktivierung dient insbesondere dazu, die für die Ver- und Entschlüsselung notwendigen Sitzungsschlüssel an die zuständigen Komponenten zu verteilen und dem Endgerät eine in diesem LoRaWAN eindeutige Adresse zuzuweisen.
Im folgenden werden die beiden verfügbaren Aktivierungsmethoden beschrieben.
In \autoref{tab.lorawan-activation} sind diese zum Vergleich dargestellt.
\cite{loraactivation}
\begin{singlespacing}
\begin{table}[htbp]
\begin{tabular}{l|l|l}
& \textbf{Activation by Personalization (ABP)} & \textbf{Over-the-Air Activation (OTAA)} \\ \hline
\textbf{Sitzung} & eine statische Sitzung & dynamisch, beliebig oft neu \\ \hline
\textbf{Schlüssel} & \begin{tabular}[c]{@{}l@{}}Sitzungsschlüssel fest\\ einprogrammiert\end{tabular} & \begin{tabular}[c]{@{}l@{}}Aushandlung für Sitzung,\\ Ableitung aus Root-Key\end{tabular} \\ \hline
\textbf{Beitritt} & Kommunikation direkt möglich & Beitrittsprozess nötig \\ \hline
\textbf{Sicherheit} & geringer & hoch
\end{tabular}
\caption{Vergleich der Methoden für die Aktivierung von Endgeräten}
\label{tab.lorawan-activation}
\end{table}
\end{singlespacing}
\subsection{Activation by Personalization (ABP)}
Bei \gls{ABP} werden die Sitzungsschlüssel vor Inbetriebnahme des Geräts berechnet und eine freie Geräteadresse bestimmt.
Diese statischen Sitzungsdaten werden zum einen fest in das Endgerät einprogrammiert und zum anderen an die zuständigen Server verteilt (Netzwerksitzungsschlüssel und Geräteadresse an Netzwerkserver, Applikationssitzungsschlüssel an Applikationsserver).
Damit wurde eine Sitzung etabliert und eine Kommunikation mit diesem Gerät ist sofort möglich.
Nachteil von \gls{ABP} ist die eingeschränkte Sicherheit, da bei Kompromittierung der Schlüssel keine neue Sitzung mit anderen Schlüsseln gestartet werden kann und die Verschlüsselung dann gebrochen ist.
\gls{ABP} wird vor allem beim Debugging während der Entwicklung von Endgeräten eingesetzt, da nach einem Neustart direkt ohne einen Aktivierungsprozess kommuniziert werden kann.
\subsection{Over-the-Air Activation (OTAA)}
Bei \gls{OTAA} erfolgen die Berechnung der Sitzungsschlüssel und die Zuweisung der Geräteadresse dynamisch.
Dabei wird vor Inbetriebnahme des Geräts eine (möglichst) weltweit eindeutige ID für das Gerät (DevEUI) und ein Root-Key festgelegt.
Diese Daten werden im Gerät fest einprogrammiert und im Join-Server hinterlegt.
Im Gerät wird außerdem die ID des zuständigen Join-Servers (JoinEUI) hinterlegt.
Zur Aktivierung wird der in \autoref{img.lorawan-OTAA} dargestellte Beitrittsprozess durchlaufen.
Das Endgerät sendet seine Geräte-ID DevEUI und die ID des Join-Servers JoinEUI unverschlüsselt an das Netzwerk.
Anhand der JoinEUI erfolgt im Netzwerkserver die Weiterleitung an den zuständigen Join-Server.
Dieser wählt eine zufällige Nonce und berechnet daraus anhand des für dieses Endgerät hinterlegten Root-Keys neue Sitzungsschlüssel.
Diese Sitzungsschlüssel werden vom Join-Server an die jeweils dafür zuständigen Server verteilt.
Der Netzwerkserver bestimmt eine für diese Sitzung gültige Adresse für das Endgerät und leitet diese zusammen mit der Nonce des Join-Servers an das Endgerät weiter.
Die Sitzungsschlüssel werden demzufolge nicht per LoRa gesendet und können daher nicht abgehört werden.
Das Endgerät berechnet die Sitzungsschlüssel anhand der Nonce und des Root-Keys über denselben Algorithmus wie der Join-Server.
In der Abbildung sind die Berechnungsschritte in Schritt 4 und 9 demzufolge identisch.
\image{lorawan-OTAA}{img.lorawan-OTAA}{\textwidth}{Beitrittsprozess Over-the-Air Activation}{Beitrittsprozess Over-the-Air Activation}{eigene Darstellung}
Die Sicherheit von \gls{OTAA} ist höher als die von \gls{ABP}, da jederzeit eine neue Sitzung mit neuen Sitzungsschlüsseln initiiert werden kann.
Nachteilig bei \gls{OTAA} ist die Komplexität des Beitrittsprozesses.
\section{Geräteklassen}\label{sec.lorawan.classes}
Endgeräten im LoRaWAN wird eine Geräteklasse zugewiesen.
Anhand dieser Einstellung werden die zeitlichen Intervalle festgelegt, zu denen das Gerät empfangsbereit ist.
In diesen sogenannten Empfangsfenstern kann das Endgerät einen Downlink vom Gateway empfangen, zu allen anderen Zeitpunkten ist ein Empfang durch das Gerät nicht möglich.
Je nach benötigter Latenz einer Nachricht von der Anwendung zum Endgerät wird dem Endgerät die passende Klasse zugewiesen.
\cite{loraclasses}
\image{lorawan-classes}{img.lorawan-classes}{\textwidth}{Empfangsfenster der Geräteklassen bei LoRaWAN}{Geräteklassen bei LoRaWAN}{https://witekio.com/wp-content/uploads/2018/01/Lora-wan-class.png}
In \autoref{img.lorawan-classes} sind die Empfangsfenster im zeitlichen Verlauf nach einem Uplink des Endgeräts dargestellt.
Allen Klassen gemein ist das Empfangsfenster "`RX1"', welches (abhängig von den Einstellungen des LoRaWAN) üblicherweise 1 Sekunde nach dem Senden einer Nachricht für kurze Zeit geöffnet wird.
In Klasse A und B wird nach einer weiteren kurzen (vom Netzwerk abhängigen) Verzögerung noch das Empfangsfenster "`RX2"' geöffnet.
Danach ist ein Gerät der Klasse A erst wieder nach dem nächsten Uplink erreichbar, die Latenz ist entsprechend am größten und entspricht maximal der Dauer zwischen zwei Uplinks.
Geräte der Klasse B öffnen periodisch ein Empfangsfenster, welches durch vom Gateway gesendete Beacons gesteuert wird.
Die maximale Latenz beträgt hierbei die eingestellte Periodendauer.
Geräte der Klasse C sind (außer wenn sie selber senden) immer empfangsbereit, es gibt entsprechend keine Latenz.
Währends eines offenen Empfangsfensters wird Energie für das Betreiben des LoRa-Chips benötigt.
Der Energiebedarf der Endgeräte ist also abhängig von der eingestellten Klasse.
Bei Klasse C ist der Energiebedarf am höchsten, da der LoRa-Chip dauerhaft aktiviert sein muss.
Der Energiebedarf ist dagegen am geringsten, wenn das Gerät in Klasse A ist, da nur während kurzer Zeitfenster Energie für den Empfang benötigt wird.
\section{Adaptive Data Rate (ADR)}\label{sec.lorawan.adr}
In \autoref{sec.lora.sf} wurde die Konkurrenz zwischen Airtime, Energiebedarf und Reichweite bei Nutzung verschiedener Spreading Factors beschrieben.
LoRaWAN löst dieses Problem mittels des Verfahrens \gls{ADR}, welches eine Möglichkeit zur automatischen Optimierung dieser Werte bietet.
Die Nutzung des Verfahrens kann durch das Endgerät gesteuert werden und sollte bei stabilen Umgebungsbedingungen (der Funkübertragung) aktiviert werden.
\cite{loraadr}
\image{lorawan-ADR}{img.lorawan-ADR}{\textwidth}{Ablauf ADR}{Ablauf ADR}{eigene Darstellung}
In \autoref{img.lorawan-ADR} ist der Ablauf von ADR dargestellt.
Nach jeder vom Endgerät empfangenen Nachricht wird das vom Gateway ermittelte \acrlong{SNR} durch den Netzwerkserver gespeichert.
Für die Initialisierung werden 20 Nachrichten benötigt.
In der Betriebsphase wird nach jeder empfangenen Nachricht der Durchschnitt des SNR der letzten Nachrichten berechnet.
Anschließend wird die Differenz zum mindestens nötigen SNR für erfolgreichen Empfang gebildet.
Bei einer hohen Differenz gibt es einen SNR-Überschuss und das Endgerät sollte die Sendeleistung reduzieren oder den Spreading Factor verringern (führt zu Erhöhung Datenrate und Verringerung Airtime).
Bei einem SNR-Defizit sollte das Endgerät entsprechend die Sendeleistung oder den Spreading Factor erhöhen (führt zu Verringerung Datenrate und Erhöhung Airtime).
Der Netzwerkserver sendet die passende Kontrollnachricht an das Gerät mit der Information, entsprechend den Spreading Factor zu verändern.
Für die Berechnung wird der Durchschnitt mehrerer Messungen verwendet, damit der Regelkreis nicht durch kurzzeitig auftretende Störungen instabil wird.