124 lines
5.2 KiB
TeX
124 lines
5.2 KiB
TeX
% lösungsansätze
|
|
% Mit welchen Methoden soll das Problem bearbeitet werden?
|
|
|
|
Im vorherigen Abschnitt wurden die Architektur und Komponenten von LoRaWAN und
|
|
Matrix eingeführt.
|
|
In diesem Abschnitt werden Lösungsmöglichkeiten für die Kombination der beiden
|
|
Prokotolle beschrieben.
|
|
|
|
\subsection{Server im low-bandwidth Modus}
|
|
|
|
% \begin{figure}
|
|
% \centering
|
|
% \includegraphics[width=0.8\textwidth]{images/solution-ulb.png}
|
|
% \caption[Matrix mit CoAP-Proxy und Chirpstack]{Matrix low-bandwidth mode mit CoAP-Proxy und
|
|
% Chirpstack\protect}
|
|
% \label{fig:matrix-ulb-chirpstack}
|
|
% \end{figure}
|
|
|
|
Wie in \ref{subsub:matrix_stateoftech} beschrieben, wurde 2019 ein
|
|
\emph{low-bandwidth Modus} für Matrixserver experimentell umgesetzt.
|
|
Eine Variante einen Matrixserver Daten über LoRaWAN übertragen zu lassen, könnte
|
|
man den Server im low-bandwidth Modus betreiben und den daran angeschlossenen
|
|
\ac{CoAP}-Proxy als Application mit dem \emph{Application Server} des Chirpstack
|
|
verknüpfen (siehe Abb.\ref{fig:matrix-ulb-chirpstack}).
|
|
|
|
Dafür könnten die bestehenden Softwarekomponenten mit entsprechender
|
|
Konfiguration wiederverwendet werden.
|
|
Die prototypischen Impelemntierungen sowohl im Matrixserver als auch dem
|
|
CoAP-Proxy müssten ausgebaut und gewartet werden.
|
|
|
|
\subsection{Matrix Bridge als LoRaWAN Applikation}
|
|
|
|
% \begin{figure}
|
|
% \centering
|
|
% \includegraphics[width=0.8\textwidth]{images/solution-bridge.png}
|
|
% \caption[Matrix Bridge LoRa mit CoAP-Proxy und Chirpstack]{Matrix Bridge
|
|
% LoRa mit CoAP-Proxy und
|
|
% Chirpstack\protect}
|
|
% \label{fig:matrix-bridge-lora}
|
|
% \end{figure}
|
|
|
|
Eine Alternative wäre die Entwicklung einer Matrix Bridge für das LoRaWAN
|
|
Protokoll.
|
|
Diese kann über einen CoAP Proxy mit dem \emph{Application Server} des
|
|
Chirpstack verknüpft werden (siehe Abb.\ref{fig:matrix-bridge-lora}).
|
|
|
|
Für die Umsetzung könnten Ideen und Implementierungsansätze des
|
|
\emph{low-bandwidth Modus} wiederverwendet werden.
|
|
Vorteil an dieser Variante ist, dass bestehende Matrixserver keiner Änderung
|
|
bedürfen, sondern die Übertragung mittels LoRaWAN von einem registierten Client
|
|
übernommen wird.
|
|
Eine solche Bridge erfordert weniger Wartungsaufwand.
|
|
Außerdem kann durch Beitreten und Verlassen von Räumen explizit diese ausgewählt
|
|
werden, welche relevant für die Übertragung über die LoRaWAN Verbindung
|
|
stattfinden soll.
|
|
|
|
% Mit Hilfe der Kombination von \emph{Meshsim} und \emph{CoAP-Proxy} werden zwei
|
|
% Matrix-Applikationsserver installiert und verknüpft.
|
|
|
|
% Der Chirpstack wird zum Aufbau einer privaten Experimentierplattform und
|
|
% Simulation einer LoRaWAN Umgebung genutzt.
|
|
|
|
% Durch möglichst minimale Anpassung an den jeweiligen Softwarekomponenten sollen
|
|
% Matrix-Anwendungsdaten über das simulierte LoRaWAN Netzwerk übertragen werden.
|
|
% % - p2p matrix https://matrix.org/blog/2020/06/02/introducing-p-2-p-matrix/
|
|
% over https://libp2p.io/
|
|
|
|
Ein weiterer Aspekt ist die Art der Datenübertragung im LoRaWAN Funknetzwerk.
|
|
|
|
% \newpage
|
|
\subsection{bidirektionale Verbindung mit Geräteklasse C}
|
|
|
|
Die Kombination aus LoRaWAN Gateway und Endknoten kann so gewählt werden, dass
|
|
einer der im Verbund teilnehmenden Matrixserver die Rolle das Netzwerkservers
|
|
übernimmt und mittels Chirpstack an ein LoRaWAN Hardware Gateway angeschlossen.
|
|
Alle anderen Matrixserver werden an Endknoten angeschlossen.
|
|
|
|
Diese Endknoten müssen zwangsweise als Klasse C Geräte konfiguriert werden,
|
|
sodass sie ständig Daten vom Gateway empfangen können.
|
|
Die Datenübertragung um LoRaWAN findet somit bidirektional (Gateway->Endknoten
|
|
und Endknoten->Gateway) statt.
|
|
|
|
% \improvement[inline]{in welchen Fällen ist das günstig?}
|
|
|
|
% architecture: https://www.chirpstack.io/project/architecture/
|
|
|
|
% based on https://github.com/brocaar/chirpstack-docker
|
|
|
|
% \begin{itemize}
|
|
% \item{run the stack twice}
|
|
% \item{connect them either with a packet forwarder or the gateway bridge}
|
|
% \item{Whats the smallest easiest thing to test this???}
|
|
% % \item{connect both application servers with a dendrite/synapse each}
|
|
% \end{itemize}
|
|
|
|
% node simulation (+server, monitor):
|
|
% - simulation https://github.com/devlaam/lora_simulator/tree/master/src/main/scala
|
|
|
|
\subsection{unidrektionale Verbindung}
|
|
|
|
Eine unidirektionale Funkverbindung mit Endknoten der Klasse A oder B könnte
|
|
alternativ umgesetzt werden.
|
|
In dieser Variante würde jeder Matrixserver mit einem Chirpstack verknüpft und
|
|
jeder Chirpstack erhält ein Gateway und einen Endknoten.
|
|
Die Endknoten werden ausschließlich zum Versenden von Daten genutzt.
|
|
Die Gateways ausschließlich zum Empfang von Daten.
|
|
Das bedeutet beide Geräte übertragen die Daten jeweils unidirektional.
|
|
|
|
%\impvement[inline]{welche funktechnischen problem können hier auftreten?}
|
|
|
|
In dieser Konstellation können einfachere Endknoten (Klasse A oder B statt
|
|
Klasse C) genutzt werden, jedoch benötigt jeder teilnehmende Matrixserver auch
|
|
ein LoRaWAN Hardware Gateway.
|
|
% Uni- oder Bidirektional?\cite{pop2017does}
|
|
|
|
% \subsection{libp2p}
|
|
|
|
% kritik: libp2p zwar 2020, aber für unseren anwendungsfall nicht möglich, da
|
|
% service discovery/rendevouz server über lorawan in diesem rahmen nicht
|
|
% umgesetzt werden kann (und existiert noch nicht)
|
|
|
|
% will not work because of service/server discovery impossible without IP based
|
|
% relay/rendevouz server
|