latex-templates/thesis/sections/solutions.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