Entwicklung eines Nachrichtensystems basierend auf einem Ad-Hoc LoRa Netzwerk

Entwicklung eines Nachrichtensystems basierend auf einem Ad-Hoc LoRa Netzwerk Masterarbeit Name des Studiengangs Angewandte Informatik Fachbereich IV vorgelegt von Marvin Rausch Datum: Berlin, 28.10.2024 Erstgutachter: Prof. Dr.-Ing. Thomas Schwotzer Zweitgutachter: Prof. Dr. Alexander Huhn Abstract Das Ziel dieser Masterarbeit ist die Entwicklung eines Systems für den Nachrichtenaustausch zwischen Teilnehmern über eine Punkt-zu-Punkt-Verbindung auf Basis des LoRa-Funkstandards. Durch die Kombination von LoRa (OSI-Schicht 2) mit dem Routing-Protokoll ASAP (OSI-Schicht 3) können Ad-hoc-Netzwerke mit großer Flächenausdehnung realisiert werden. Hierzu werden Softwarekomponenten für die OSI-Schichten 2 bis 4 entwickelt, die eine Integration von ASAP ermöglichen. Abb. 1.: Systemübersicht: Hardund Softwarekomponenten für den Datenaustausch über eine LoRa-Punkt-zu-Punkt-Verbindung Die Hardwarebasis bildet das LoRa-Funkmodul HIMO-01M, das über eine serielle Schnittstelle mit einem Raspberry Pi verbunden wird. Jeder Raspberry Pi, kombiniert mit einem Modem, repräsentiert dabei einen Knoten im Netzwerk. Endgeräte, die sich im selben Netzwerk wie der Raspberry Pi befinden, können über TCP/IP eine Verbindung zu diesem herstellen. Dies ist beispielsweise der Fall, wenn die Endgeräte mit demselben Access Point (AP) wie der Raspberry Pi verbunden sind (siehe Abb. 1). Durch die Multi-Hop-Unterstützung von ASAP können diese Endgeräte die LoRa-Punkt-zu-Punkt-Verbindung zwischen den Raspberry Pis für den Datenaustausch nutzen. ii Abstract (english) The goal of this master’s thesis is to develop a system for message exchange between participants using a point-to-point connection based on the LoRa radio standard. By combining LoRa (OSI Layer 2) with the routing protocol ASAP (OSI Layer 3), it is possible to create ad-hoc networks that cover large areas. To achieve this, software components for OSI Layers 2 to 4 are developed to integrate ASAP. Abb. 2.: System Overview: Hardware and Software Components for Data Exchange via a LoRa Point-to-Point Connection The hardware base is the LoRa radio module HIMO-01M, which is connected to a Raspberry Pi via a serial interface. Each Raspberry Pi, combined with a modem, represents a node in the network. Devices in the same network as the Raspberry Pi can connect to it via TCP/IP. This is the case, for example, if the devices are connected to the same access point (AP) as the Raspberry Pi (see Fig. 2). With the multi-hop support of ASAP, these devices can use the LoRa point-to-point connection between the Raspberry Pis to exchange data. iii Abkürzungsverzeichnis LoRa Long Range ASAP Asynchronous Semantic Ad-hoc Protocol IP Internet Protocol TCP/IP Transmission Control Protocol/Internet Protocol SSH Secure Shell JVM Java Virtual Machine UART Universal Asynchronous Receiver Transmitter CRC Cyclic Redundancy Check CAD Carrier Activity Detection RSSI Received Signal Strength Indicator CSS Chirp Spread Spectrum ETSI European Telecommunications Standards Institute MCU Microcontroller Unit PDU Protocol Data Unit POM Project Object Model MAC Medium Access Control CSMA/CA Carrier Sense Multiple Access/Collision Avoidance CI/CD Continuous Integration/Continuous Deployment iv Inhaltsverzeichnis 1. Einleitung 1 1.1. Motivation ................................. 1 1.2. Problemstellung und Zielsetzung .................... 2 1.3. Aufbau der Arbeit ............................. 3 2. Grundlagen 4 2.1. Ad-hoc-Netzwerke ............................ 4 2.2. ASAP .................................... 5 2.3. ASAPPeer ................................. 5 2.4. ASAP Encounter ............................. 6 2.5. ASAPJava ................................. 6 2.6. ASAPAndroid ............................... 8 2.7. ASAPHub ................................. 8 2.8. LoRa .................................... 9 2.8.1. Abgrenzung zu LoRaWAN .................... 10 2.8.2. Regionale Parameter (EU) .................... 11 2.8.3. LoRa Trägerprüfung ....................... 12 2.8.4. Aufbau LoRa-Paket ........................ 12 2.9. UART ................................... 13 2.10.Base64 ................................... 14 2.11.AT-Befehle ................................. 14 2.12.Medienzugriffsverfahren ......................... 15 2.12.1.ALOHA .............................. 16 2.12.2.CSMA/CA ............................. 16 2.13.Testabdeckung .............................. 17 2.14.Entwurfsmuster Schablonenmethode .................. 18 3. Analyse 19 3.1. Stand der Forschung ........................... 19 3.2. Vorarbeiten ................................ 19 3.2.1. Verteilung des ASAPHubs über ein LoRa Multi-Hop-Netzwerk 19 3.2.2. Kommunikation zwischen zwei Android-Smartphones mittels LoRa-Funkmodulen ....................... 21 v 3.2.3. Entwicklung einer Peer-Komponente für Langstrecken-Ad-hocNetzwerke ............................. 22 3.3. Anforderungen .............................. 22 3.3.1. Zielgruppe ............................ 22 3.3.2. funktionale Anforderungen an das Funkmodul ........ 23 3.3.3. funktionale Anforderungen an das System für den Datenaustausch über LoRa ......................... 23 3.3.4. nicht-funktionale Anforderungen an das Funkmodul ..... 24 3.3.5. nicht-funktionale Anforderungen an das System für den Datenaustausch über LoRa ..................... 24 4. Entwurf und Implementierung 25 4.1. Verwendete Hardware .......................... 26 4.2. Projektstruktur .............................. 27 4.3. Konfiguration der Anwendung ...................... 29 4.4. Interface für den Zugriff auf das Funkmodul (OSI-Schicht 2) ..... 30 4.5. Implementierung der Softwarekomponente für den Zugriff auf das Funkmodul (OSI-Schicht 2) ....................... 31 4.5.1. Konfiguration der Softwarekomponente ............ 32 4.5.2. Implementierung der seriellen Kommunikation mit dem Funkmodul ............................... 33 4.6. Interface für ein Layer-3-Protokoll zur Kommunikation über LoRa . . 36 4.7. Softwarekomponente für ein Layer-3-Protokoll zur Kommunikation über LoRa ................................. 37 4.7.1. Einsatz des Entwurfsmusters der Schablonenmethode . . . . 38 4.7.2. Wahl des Medienzugriffsverfahrens ............... 39 4.7.3. Konfiguration der Softwarekomponente ............ 39 4.7.4. Nachrichtenstruktur des Layer-3-Protokolls .......... 40 4.7.5. Aufbau einer Verbindung zwischen den Teilnehmern . . . . . 43 4.7.6. Nachrichtenaustausch zwischen Teilnehmern ......... 46 4.8. Softwarekomponente für streambasierte Kommunikation über eine LoRa-Punkt-zu-Punkt-Verbindung (OSI-Schicht 4) ........... 48 4.8.1. Ablauf streambasierter Datenaustausch über Layer-3-Protokoll 49 4.8.2. Behandlung von Verbindungsproblemen ............ 50 4.8.3. Schließen der Verbindung auf Anwendungsebene ....... 51 4.9. Integration von ASAP ........................... 52 4.10.Erweiterung der ASAPAndroid-Bibliothek ................ 55 vi 5. Testing 57 5.1. Unit-Tests ................................. 57 5.1.1. Beispiel für die Verwendung von Mockito innerhalb eines JUnit-Tests ............................ 58 5.2. Analysetools für Codequalität ...................... 59 5.2.1. Tool zum Messen der Testabdeckung .............. 59 5.2.2. Tool für die statische Code-Analyse ............... 59 5.3. CI/CD-Pipeline .............................. 60 5.3.1. Ablauf der CI/CD-Pipeline .................... 60 5.4. Praxistest ................................. 61 5.4.1. Durchführung eines Praxistests ................. 62 5.5. Integrationstest (Ende-zu-Ende) ..................... 63 5.5.1. Testaufbau und benötigte Komponenten zur Testausführung . 63 5.5.2. Ablauf Integrationstest ...................... 64 5.5.3. Workaround für Multi-Hop-Routing-Fehler ........... 66 6. Zusammenfassung und Bewertung der Ergebnisse 67 6.1. Vergleich zu Vorarbeiten ......................... 68 6.2. Limitationen und Ausblick ........................ 69 Literatur 70 Abbildungsverzeichnis 72 Tabellenverzeichnis 75 List of Listings 76 A. Appendix 77 A.1. Link zum Quellcode der Software .................... 77 vii Einleitung 1 1.1 Motivation In Krisengebieten besteht häufig die Herausforderung einer mangelnden Kommunikationsinfrastruktur, insbesondere wenn bestehende Mobilfunkmasten und Telefonleitungen durch Umweltkatastrophen oder andere Ereignisse beschädigt wurden. In solchen Situationen ist es für örtliche Hilfsorganisationen entscheidend, schnellstmöglich ein funktionierendes Kommunikationsnetzwerk aufzubauen. Auch für Privatpersonen ist die Nutzung dezentraler Netze von Interesse. Das Thema Datenschutz und Datensicherheit ist in der heutigen Gesellschaft immer wichtiger geworden, sodass die Nutzung dezentraler Netze für unterschiedlichste Personengruppen von Nutzen ist. Für diesen Zweck kann das Asynchronous Semantic Ad-hoc Protocol ( ASAP ) verwendet werden. Für den Datenaustausch über ASAP ist eine Punkt-zu-Punkt-Verbindung zwischen den Teilnehmern erforderlich. Derzeit lassen sich solche Verbindungen lediglich über kurze Distanzen mittels Ad-hoc-Netzwerken aufbauen, die auf Bluetooth oder Wi-Fi Direct basieren. Über größere Distanzen ist es bislang notwendig, auf eine Transmission Control Protocol/Internet Protocol ( TCP/IP )-Verbindung zurückzugreifen, die in der Regel über Infrastrukturnetze wie das Internet erfolgt. Im Rahmen dieser Arbeit soll mit dem Funkstandard LoRa eine weitere Möglichkeit geschaffen werden, infrastrukturlose Punkt-zu-Punkt-Verbindungen aufzubauen. LoRa-Funkmodule ermöglichen es, Ad-hoc-Netzwerke aufzubauen, welche nicht nur im Nahbereich funktionieren, sondern auch für den Datenaustausch über größere Distanzen geeignet sind. Unter Verwendung des LoRa-Funkstandards kann zwischen zwei Teilnehmern eine Reichweite von bis zu 15 km überbrückt werden [11, vgl. S. 28]. Durch die Unterstützung von Multi-Hop-Routing in ASAP kann die Flächenabdeckung durch den Einsatz mehrerer Teilnehmer, die LoRa für die Kommunikation nutzen, deutlich erhöht werden. Auf diese Weise wäre es möglich, über ganze Stadtgebiete hinweg zu kommunizieren. 1 1.2 Problemstellung und Zielsetzung Das Ziel dieser Arbeit besteht darin, ein System zu entwickeln, das es ermöglicht, eine Langstreckenfunkverbindung zwischen Teilnehmern in ASAP herzustellen. Für die Etablierung einer Punkt-zu-Punkt-Verbindung zwischen den Teilnehmern muss ein Protokoll entwickelt werden, das sowohl den Verbindungsaufbau als auch den Datenaustausch regelt. In der Java-Implementierung von ASAP werden Inputund Outputstreams für die Kommunikation zwischen den Teilnehmern verwendet. Eine Herausforderung besteht darin, dass die Kommunikation in ASAP auf Streams basiert, während die Funkkommunikation über LoRa paketorientiert ist. Daher müssen die Daten, die über den Stream gesendet werden, seitens des Senders in Datagramme aufgeteilt und beim Empfänger wieder in der richtigen Reihenfolge zusammengesetzt werden. Dieser Prozess muss für die Teilnehmer in ASAP transparent sein, sodass keine Unterschiede zwischen der Verwendung von LoRa für den Nachrichtenaustausch oder einer direkten TCP/IP-Verbindung bestehen. Ein Teilnehmer soll die Möglichkeit haben, mehrere Punkt-zu-Punkt-Verbindungen zu anderen Teilnehmern über LoRa herstellen zu können. Dazu muss dem Teilnehmer für jede Funkverbindung ein separater Stream bereitgestellt werden, der jeweils eine Verbindung repräsentiert. Daraus ergibt sich die Notwendigkeit, dass Nachrichten, die über LoRa empfangen werden, dem korrekten Stream zugeordnet werden müssen. Beim Datenaustausch über LoRa kann es zu Signalstörungen und (temporären) Verbindungsabbrüchen kommen. Daher müssen Mechanismen zur Fehlererkennung und Fehlerkorrektur implementiert werden, um die Zuverlässigkeit der Datenübertragung sicherzustellen. 1.2 Problemstellung und Zielsetzung 2 Der ASAPHub läuft als Prozess auf einem Server und funktioniert ähnlich wie ein TCP-Relay-Server. Normalerweise benötigt ein ASAPPeer zur Herstellung einer TCP/IP-Verbindung die IP-Adresse und den Port des Ziel-Peers. Bei der Nutzung des ASAPHubs ist dies nicht notwendig. Hier müssen die Peers lediglich die IP-Adresse und den Port des ASAPHubs kennen, nicht jedoch die spezifischen IP-Adressen und Ports aller beteiligten Peers. Zudem müssen Peers, die den ASAPHub nutzen, keinen eigenen TCP-Port für den Verbindungsaufbau öffnen, was aus IT-Security-Sicht empfehlenswert ist. Nachdem eine Verbindung zwischen zwei Peers etabliert ist, erfolgt die Weiterleitung der Daten über den Hub. Ab diesem Zeitpunkt fungiert der Hub als reines Relay. Das Hub-Protokoll muss nicht zwingend über TCP/IP laufen. Zukünftig könnte der Hub dahingehend erweitert werden, dass die Verbindung über ein alternatives Netzwerkprotokoll hergestellt wird. 2.8 LoRa Bei Long Range ( LoRa ) handelt es sich um ein proprietäres Übertragungsverfahren auf Ebene der Bitübertragungsschicht, welches von dem Unternehmen Semtech entwickelt wurde. LoRa verwendet als Modulationstechnik Chirp Spread Spectrum ( CSS ). Hierbei handelt es sich um ein Frequenzspreizverfahren, das als Symbole Chirps verwendet. Chirp-Impulse sind Signale mit zeitlicher Frequenzänderung. Dabei wird zwischen Signalen mit zunehmender Frequenz (positive Chirps) und Signalen mit abnehmender Frequenz (negative Chirps) unterschieden. Die Spreizfaktoren von SF7 bis SF12 bieten die Möglichkeit, die Reichweite zu optimieren. Der Spreizfaktor bildet ein „[...] Zieldreieck aus Energieverbrauch, Übertragungsgeschwindigkeit und Reichweite“ [11, S. 30]. Um die Reichweite zu steigern, kann ein höherer Spreizfaktor eingesetzt werden. Dieser erhöht die Empfindlichkeit des Empfängers, was wiederum die Reichweite vergrößert. Dadurch sinkt jedoch die Datenrate und die Übertragungszeit (Time-On-Air) erhöht sich. Wegen der längeren Übertragungszeit wird mehr Energie benötigt. Dieser Zusammenhang wird noch einmal durch Abbildung 2.1 verdeutlicht. Je nach Bandbreite, Frequenz und Spreizfaktor können Datenraten zwischen 300 Bit/s und 50 kBit/s erreicht werden. LoRa verwendet ein lizenzfreies ISM-Band. „ISMBänder stehen für industrial, scientific and medical Band und werden in der Industrie, Wissenschaft und Medizin eingesetzt“ [11, S. 111]. Diese Bänder können auch für 2.8 LoRa 9 Abb. 2.1.: Veranschaulichung des Spannungsdreiecks bestehend aus Energieverbrauch, Datenrate und Reichweite bei Funkübertragungen den privaten Gebrauch genutzt werden. „In Europa werden die Frequenzbänder 433 MHz sowie 868 MHz verwendet“ [11, S. 13]. Aufgrund der Orthogonalität der Spreizfaktoren kollidieren Nachrichten, die gleichzeitig mit unterschiedlichen Spreizfaktoren gesendet werden, nicht. Die Verwendung unterschiedlicher Spreizfaktoren ermöglicht gleichzeitiges Senden mehrerer Endgeräte im selben Kanal. Damit zwei LoRa-Modems miteinander kommunizieren können, müssen neben der Trägerfrequenz und der Bandbreite auch die Spreizfaktoren identisch sein. 2.8.1 Abgrenzung zu LoRaWAN Die Begriffe LoRa und LoRaWAN werden oft synonym verwendet, jedoch ist es wichtig, sie voneinander abzugrenzen. Wohingegen es sich bei LoRa um die Bitübertragungsschicht handelt, definiert LoRaWAN die Sicherungsschicht des LoRaProtokollstacks (siehe Abb. 2.2). Abb. 2.2.: Übersicht über den LoRa-Protokollstack[@1] 2.8 LoRa 10 Es legt das Kommunikationsprotokoll und die Systemarchitektur für das Netzwerk fest, das die LoRa-Modulation auf der Bitübertragungsschicht verwendet. Die durch LoRaWAN definierte Netzwerkarchitektur und ihr Protokoll sind hauptsächlich verantwortlich für den energieeffizienten Betrieb des Netzwerks [9, vgl. S. 193]. 2.8.2 Regionale Parameter (EU) Ein LoRa-Modem wird als SRD (Short Range Device, dt.: Funkanwendungen geringer Reichweite) eingestuft und darf somit in ISM-Bändern senden. Die Bundesnetzagentur legt für die von LoRa verwendeten Frequenzbänder Frequenznutzungsbestimmungen fest. Diese Bestimmungen werden durch das European Telecommunications Standards Institute ( ETSI ) europaweit harmonisiert, sodass die Regelungen länderübergreifend einheitlich sind. Für den Frequenzbereich von 868 MHz bis 870 MHz werden neben der maximalen Strahlungsleistung auch Beschränkungen bezüglich des Arbeitszyklus vorgegeben (siehe Tabelle 2.1). Frequenzbereich Arbeitszyklus 863 MHz - 865 MHz 0,1% 865 MHz - 868 MHz 1% 868 MHz - 868,6 MHz 1% 868,7 MHz - 869,2 MHz 0,1% 869,4 MHz - 869,65 MHz 10% 869,7 MHz - 870 MHz 1% Tab. 2.1.: Arbeitszyklus für die EU868-Subbänder nach ETSI EN300.220 [14] Der Arbeitszyklus ist ein Prozentsatz, der angibt, wie viel Zeit ein einzelnes Sendegerät aktiv ist, basierend auf einer einstündigen Beobachtungszeit. Im 433-MHz-Frequenzband (433,050 MHz - 434,790 MHz) gibt es keine Beschränkungen hinsichtlich eines Arbeitszyklus. Dieses Band wird von verschiedenen Geräten verwendet, insbesondere für Anwendungen wie Fernsteuerungen, drahtlose Sensornetzwerke und Smart-Home-Geräte. Durch Geräte, die im selben Frequenzbereich arbeiten, kann es zu Interferenzen kommen, die die Zuverlässigkeit der Kommunikation beeinträchtigen können. 2.8 LoRa 11 2.8.3 LoRa Trägerprüfung LoRa-Modems können auf zwei unterschiedliche Arten prüfen, ob der Kanal frei ist [15, vgl. S. 4]. Eine Möglichkeit besteht darin, den Received Signal Strength Indicator ( RSSI ) als Anhaltspunkt zu nehmen. Der RSSI -Wert gibt an, wie stark das vom Modem empfangene Funksignal ist, ohne zwischen einem mit LoRa modulierten Signal und anderen Signalen zu unterscheiden. Diese Methode ist nur geeignet, wenn das empfangene Signal stark genug ist. Aufgrund der CSS -Modulation von LoRa ist der Empfänger in der Lage, Signale unterhalb des Grundrauschens zu demodulieren. Daher ist diese Methode für die Langstreckenkommunikation nicht zuverlässig genug [16, vgl. S. 3]. Bei der zweiten Variante handelt es sich um Carrier Activity Detection ( CAD ). CAD wurde entwickelt, um die Präambel eines LoRa Pakets unterhalb des Grundrauschens des Empfängers erkennen zu können. Bevor ein Gerät Daten überträgt, wechselt es in den Empfangsmodus und prüft, ob aktuell eine Präambel übertragen wird. Das Verfahren arbeitet energieeffizient, da erst kurz vor der Übertragung in den Empfangsmodus gewechselt wird und der Kanal nicht dauerhaft überwacht wird [23, vgl. S. 4]. Die CAD-Dauer hängt von den konfigurierten Sendeparametern ab und kann mittels folgender Formel berechnet werden: TCAD =2SF + 32 BW Wobei: TCAD: Dauer der CAD in Sekunden SF : Spreizfaktor BW : Bandbreite Während dieses Zeitraums können keine LoRa-Pakete empfangen werden. Bei CAD handelt es sich nicht um eine vollständige Trägerprüfung, da das Verfahren hauptsächlich zur Präambelerkennung entwickelt wurde. Versuche haben gezeigt, dass CAD zwar auch in der Lage ist, Payload-Chirps einer laufenden Übertragung zu erkennen, jedoch nimmt die Zuverlässigkeit mit zunehmender Entfernung zwischen Sender und Empfänger ab [3, vgl. S. 93]. 2.8.4 Aufbau LoRa-Paket Ein LoRa-Paket beginnt mit einer Präambel (siehe 2.2). Die Präambel besteht aus einer Folge einer konfigurierbaren Anzahl von Up-Chirps, gefolgt von zwei Down2.8 LoRa 12 Chirps, welche mit einem Viertel-Up-Chirp beendet wird. Der Empfänger verwendet die Präambel, um sich mit dem Sender zu synchronisieren [3, vgl. S.70]. Preamble Header Header_CRC Payload Payload_CRC Tab. 2.2.: Aufbau eines LoRa-Pakets auf Ebene der Bitübertragungsschicht (Explizit Header Mode) Das Feld Header enthält die Länge der Nachricht in Bytes und Informationen darüber, ob Cyclic Redundancy Check ( CRC )-Daten zur Fehlerkorrektur vorhanden sind. Falls vorhanden, wird die CRC-Prüfsumme des Headers im optionalen Feld Header_CRC gespeichert. Anschließend folgt das Feld für die Nutzdaten, welches Daten mit einer maximalen Größe von 255 Bytes enthalten kann. Auch für die Nutzdaten gibt es ein optionales Feld zur Fehlerkorrektur. Diese Struktur entspricht dem Explizit Header Mode. Wenn die Nutzdaten eine konstante Länge haben, kann der Implicit Header Mode verwendet werden. Da die Länge der Nutzdaten bekannt ist, entfällt die Notwendigkeit, den Header zu übertragen. Dadurch verkürzt sich die Übertragungsdauer und der Energieverbrauch sinkt. 2.9 UART Der Begriff Universal Asynchronous Receiver Transmitter ( UART ) bezeichnet eine elektronische Schaltung, die eine asynchrone serielle Schnittstelle realisiert [@4]. Asynchron bedeutet in diesem Zusammenhang, dass für die Kommunikation über eine UART-Schnittstelle kein Taktsignal über eine separate Steuerleitung übertragen werden muss, um Sender und Empfänger zu synchronisieren. Die Synchronisierung erfolgt stattdessen über die Rahmenlänge und die eingestellte Baudrate. Abb. 2.3.: Verkabelung einer UART-Schnittstelle Die UART-Schnittstelle verfügt über zwei Anschlüsse für den Datenaustausch. Von dem TxD-Anschluss (Transmit Data) aus werden Daten an den Kommunikationspartner gesendet. Der RxD-Anschluss (Receive Data) wird verwendet, um Daten vom 2.9 UART 13 Kommunikationspartner zu empfangen. Der TxD-Pin des einen Gerätes wird mit dem RxD-Pin des zweiten beteiligten Gerätes verbunden (siehe Abb. 2.3). 2.10 Base64 Base64 ist ein Verfahren, das 8-Bit-Binärdaten in eine Zeichenfolge bestehend aus ASCII-Zeichen umwandelt. Für die Kodierung werden jeweils drei Byte (entspricht 24 Bits) der Binärdaten in vier 6 Bits lange Blöcke aufgeteilt [12, vgl. S. 771]. Durch die Kodierung erhöht sich der Platzbedarf der Binärdaten um den Faktor 4/3, wodurch ein Overhead von 33% entsteht [6, vgl. S. 209]. Bei einem n Byte langen Bytestrom kann der Platzbedarf für den Base64-kodierten Inhalt mit der folgenden Formel berechnet werden: z= 4 ·n 3 2.11 AT-Befehle Bei dem AT-Befehlssatz handelt es sich um einen von der Firma Hayes entwickelten Befehlssatz zur Steuerung von Modems [24, vgl. S. 2]. Die Befehle dieses Befehlssatzes beginnen immer mit einem „AT“ (Attention). Im Folgenden werden die für dieses Projekt relevanten AT-Befehle zur Steuerung des LoRa-Funkmoduls HIMO-01M aufgelistet: Befehl Antwort Beschreibung AT+CFG=[Konfigurationsparameter] AT,OK Ändert die Konfiguration des Modems AT+DEST=[Zieladresse] AT,OK Setzt die Zieladresse der Nachrichten AT+ADDR=[Adresse] AT,OK Setzt die Adresse des Modems 2.10 Base64 14 AT+ADDREN=0 AT,OK Deaktiviert das Filtern eingehender Nachrichten nach der ModemAdresse, sodass die Teilnehmer unabhängig von Übereinstimmung der Quellund Zieladresse alle Nachrichten empfangen. AT+SEND=[Länge der Nutzdaten] AT,OK Versetzt das Modem in den Sende-Modus Daten der zuvor angegebenen Länge AT,SENDING Modem beginnt mit der Datenübertragung AT,SENDED Übertragung abgeschlossen LR,[Quelladresse],[Länge],[Daten] Format der Antwort vom Modem bei Empfang einer Nachricht Tab. 2.3.: Übersicht der für diese Arbeit relevanten AT-Befehle des Funkmoduls HIMO-01M 2.12 Medienzugriffsverfahren Von der Bitübertragungsschicht des OSI-Modells aus betrachtet, ist ein drahtloses Netz grundsätzlich ein Broadcast-Medium. Daher muss ein drahtloses Netzwerk das Problem lösen, das entsteht, wenn mehrere Übertragungen gleichzeitig stattfinden, da dies zu Kollisionen und somit zu Paketverlusten führen würde [26, vgl. S. 98]. Protokolle, die den Zugriff auf einen Mehrfachzugriffskanal steuern, gehören zu einer Teilschicht der Sicherungsschicht, die als Medium Access Control ( MAC ) bezeichnet wird [26, vgl. S. 304]. In den folgenden Abschnitten werden zwei Protokolle vorgestellt, die den Zugriff auf das geteilte Medium koordinieren. 2.12 Medienzugriffsverfahren 15 2.12.1 ALOHA ALOHA ist ein Verfahren zum Zugriff auf ein geteiltes Medium ohne vorherige Trägerprüfung. Die Teilnehmer dürfen jederzeit mit der Übertragung beginnen, wodurch es selbstverständlich zu Kollisionen kommt [26, vgl. S. 309]. Wenn ein Teilnehmer ein Datenpaket sendet, muss er feststellen, ob es während der Übertragung zu einer Kollision gekommen ist. Dies geschieht durch das Warten auf eine Bestätigungsnachricht vom Empfänger. Bleibt diese Bestätigung aus, geht der Sender davon aus, dass eine Kollision stattgefunden hat. In diesem Fall wartet der Sender eine zufällig gewählte Zeitspanne, die als BackoffZeit bezeichnet wird, bevor er versucht, die Nachricht erneut zu senden. Die BackoffZeit muss zufällig sein, um wiederholte Kollisionen derselben Datenpakete zu vermeiden. Der maximale Durchsatz des hier beschriebenen reinen ALOHA-Verfahrens beträgt etwa 18% der Kanalkapazität [26, vgl. S. 312]. 2.12.2 CSMA/CA Carrier Sense Multiple Access/Collision Avoidance ( CSMA/CA ) ist ein Protokoll für den Mehrfachzugriff auf einen Kanal mit Trägerprüfung [26, vgl. S. 314]. Im Gegensatz zum ALOHA-Protokoll können Teilnehmer nicht jederzeit mit der Übertragung beginnen, sondern müssen erst überprüfen, ob der Kanal frei ist. Wie bei ALOHA wartet der Sender eines Datenpakets auf eine Empfangsbestätigung, um sicherzustellen, dass die Übertragung erfolgreich war. Es gibt drei Varianten von CSMA. Im Folgenden werden zwei davon vorgestellt, die sich in ihrem Verhalten bei einem belegten Kanal unterscheiden. Die dritte Variante, die auf der Nutzung von Zeitscheiben basiert und eine synchronisierte Uhr erfordert, ist für diese Arbeit nicht relevant. 1-persistentes CSMA Wenn ein Teilnehmer ein Datenpaket übertragen möchte, prüft er zuerst, ob der Kanal frei ist. Ist der Kanal frei, beginnt der Teilnehmer mit dem Sendevorgang. Wenn der Kanal dagegen belegt ist, prüft der Teilnehmer fortlaufend den Kanal, bis dieser frei wird, und beginnt dann direkt zu senden. 2.12 Medienzugriffsverfahren 16 Falls bei der Übertragung eine Kollision auftritt, wartet der Teilnehmer eine zufällige Backoff-Zeit und beginnt von vorn. Nach dem Senden wartet der Teilnehmer, wie bei ALOHA, auf eine Empfangsbestätigung. Diese Variante des Protokolls heißt 1-persistent, da ein Teilnehmer mit einer Wahrscheinlichkeit von 1 sendet, wenn der Kanal frei ist. Wenn zwei Teilnehmer sendebereit werden, während der Kanal durch einen dritten Teilnehmer belegt ist, warten beide bis zum Ende der Übertragung und starten dann gleichzeitig mit dem Senden, was zu einer Kollision führt. Nicht-persistentes CSMA Bei dieser Variante des Protokolls wird der Versuch unternommen, etwas weniger gierig zu sein [26, vgl. S. 315]. Wie bei der ersten Variante überprüft der Teilnehmer den Kanal, bevor er mit dem Senden beginnt. Ist der Kanal frei, beginnt der Teilnehmer zu senden. Ist der Kanal jedoch belegt, überprüft die Station den Kanal nicht kontinuierlich, um direkt mit dem Senden zu beginnen, sobald der Kanal frei wird. Stattdessen wird eine zufällige Backoff-Zeit gewartet, nachdem der Kanal als belegt erkannt wurde, und der Vorgang wird dann wiederholt. Nach dem Senden wartet der Teilnehmer ebenfalls auf eine Empfangsbestätigung, um die erfolgreiche Übertragung zu verifizieren. „Dieser Algorithmus führt zu einer besseren Kanalauslastung, aber zu längeren Wartezeiten als beim 1-persistenten CSMA“ [26, S. 315]. 2.13 Testabdeckung Bei der Testabdeckung (Code Coverage) handelt es sich um eine Metrik in Softwaretests, die misst, welcher Anteil des Codes eines Softwareprojekts durch automatisierte Tests abgedeckt wird [@7]. Die Testabdeckung kann mittels unterschiedlicher qualitativer Methoden (Arten der Testabdeckung) gemessen werden. Die folgenden Arten der Testabdeckung sind für diese Arbeit relevant: • Line Coverage: Jede mindestens einmal erreichte Zeile wird als abgedeckt markiert. 2.13 Testabdeckung 17 • Branch Coverage: Nicht nur jede Zeile, sondern auch jede Verzweigung innerhalb einer Zeile muss erreicht werden. Die Testabdeckung allein ist jedoch kein ausreichender Indikator für eine gute Softwarequalität, da sie keine Aussage über die Qualität der Unit-Tests trifft. Es muss zusätzlich sichergestellt werden, dass die Tests relevante Prüfungen (Assertions) umfassen. Stattdessen sollte eine niedrige Testabdeckung als Hinweis auf mögliche Schwächen in der Qualitätssicherung der Unit-Tests dienen. 2.14 Entwurfsmuster Schablonenmethode Das Verhaltensmuster der Schablonenmethode (engl. template method pattern) definiert das Skelett eines Algorithmus und delegiert die Implementierung einzelner Schritte an Unterklassen. Dadurch können Unterklassen bestimmte Schritte des Algorithmus überschreiben, ohne dessen Grundstruktur zu verändern [13, vgl. S. 33]. Die unveränderlichen Teile des Algorithmus werden dabei einmal festgelegt, während die Unterklassen das variierende Verhalten implementieren. AbstractClass templateMethod() methodA() methodB() methodC() methodD() ... methodA() methodB() methodC() methodD() ... ConcreteClass methodC() methodD() Abb. 2.4.: Klassendiagramm zur Veranschaulichung des Entwurfsmusters Schablonenmethode Ein Beispiel hierfür ist die Klasse AbstractClass , die die Schablonenmethode templateMethod definiert (siehe Abb. 2.4). Diese Methode umfasst einen Algorithmus, der aus einem invarianten und einem variierenden Teil besteht. Der invariante Teil wird durch die in der Basisklasse definierten Methoden methodA und methodB abgedeckt. Der variierende Teil hingegen wird durch die abstrakten Methoden methodC und methodD dargestellt, die von Unterklassen, wie beispielsweise der Klasse ConcreteClass , implementiert werden. In der Schablonenmethode templateMethod werden sowohl die Methoden des invarianten als auch die des variierenden Teils aufgerufen. 2.14 Entwurfsmuster Schablonenmethode 18 Entwurf und Implementierung 4 In diesem Kapitel werden der Entwurf und die Implementierung des Systems zur Nachrichtenübertragung über eine LoRa-Funkverbindung beschrieben. Die Hardwarekomponenten des Systems bestehen aus einem Raspberry Pi und einem Funkmodul. Das Funkmodul wird über eine serielle Schnittstelle mit dem Raspberry Pi verbunden (siehe Abb. 4.1). Die Auswahl der Hardwarekomponenten wird in Abschnitt 4.1 erläutert. Abb. 4.1.: Übersicht der Softund Hardwarekomponenten des zu entwickelnden Systems, einschließlich der Zuordnung zu den OSI-Schichten. Die Softwarekomponenten sind blau umrahmt. Das System besteht aus mehreren Softwarekomponenten, die nach den OSI-Schichten unterteilt sind. Diese Softwarekomponenten laufen auf dem Raspberry Pi (siehe Abb. 4.1). Die Softwarekomponente Himo01Modem wurde entwickelt, um den Zugriff auf das Funkmodul zu ermöglichen, das die Kommunikation über den Funkstandard LoRa (OSI-Schicht 2) erlaubt (siehe Abschnitt 4.5). Diese Komponente realisiert die Schnittstelle LoRaModem (siehe Abschnitt 4.4). Darauf aufbauend stellt die Softwarekomponente LoRaProtocol ein Layer-3-Protokoll für den paketorientierten Datenaustausch bereit (siehe Abschnitt 4.7). Diese Komponente realisiert die Protocol-Schnittstelle (siehe Abschnitt 4.6). Um eine streambasierte Kommunikation (OSI-Schicht 4) über das paketorientierte Layer-3-Protokoll zu ermöglichen, wurde die Softwarekomponente LoRaTCPSocket entwickelt (siehe Abschnitt 4.8). 25 Zusätzlich läuft auf dem Raspberry Pi ein ASAPPeer, der die ASAPJava-Bibliothek als Abhängigkeit nutzt. Die Integration in das Gesamtsystem erfolgt über die Softwarekomponente ASAPLoRa , die den Datenaustausch mit anderen ASAPPeers über LoRa ermöglicht (siehe Abschnitt 4.9). Endgeräte im selben Netzwerk können über TCP/IP eine Verbindung zum ASAPPeer auf dem Raspberry Pi herstellen, um die LoRa-Punkt-zu-Punkt-Verbindung für die Kommunikation zu nutzen. Damit ASAPAndroid-basierte Apps diese LoRaVerbindung verwenden können, wird in Abschnitt 4.10 die Erweiterung der ASAPAndroidBibliothek zur Etablierung einer TCP/IP-Verbindung zum ASAPPeer auf dem Raspberry Pi beschrieben. 4.1 Verwendete Hardware Zur drahtlosen Kommunikation zwischen den Teilnehmern wird das im Fachbereich bereits eingesetzte LoRa-Funkmodul HIMO-01M des Herstellers Himalaya verwendet. Es basiert auf dem Transceiver SX1278 von SEMTECH und verfügt über eine integrierte Mikrocontroller-Einheit (MCU). Der Hersteller gibt eine maximale Funkreichweite von bis zu 10 km an [@10]. Die Firmware des Funkmoduls ermöglicht die Konfiguration von Hardware-Adressen, wodurch die funktionale Anforderung der Adressierbarkeit erfüllt wird. Das Modul lässt sich über AT-Befehle steuern, wobei die Kommunikation über eine UART-Schnittstelle erfolgt. In Deutschland regelt der Frequenzplan der Bundesnetzagentur die Nutzung der verschiedenen Frequenzbereiche des elektromagnetischen Spektrums. Aufgrund der funktionalen Anforderungen soll für die Übertragung ein Frequenzband gewählt werden, dessen Nutzung im Rahmen einer Allgemeinzuteilung bereits erlaubt ist. Zudem sollte der Arbeitszyklus des Bands nicht limitiert sein. Das ISM-Band im Bereich von 433,05 MHz bis 434,79 MHz erfüllt diese Bedingungen [2, vgl. S. 2]. Das verwendete Funkmodul lässt sich für die Nutzung dieses Frequenzbereichs konfigurieren, sodass diese Anforderung erfüllt ist. Für den Betrieb der Softwarekomponenten des Systems zum Nachrichtenaustausch über LoRa ist ein Endgerät erforderlich, das ein Betriebssystem unterstützt, welches Java-Programme mithilfe der Java Virtual Machine ( JVM ) ausführen kann. Zudem sollte das Endgerät über ausreichende Hardware-Ressourcen verfügen, um die Software auszuführen, sowie über eine UART-Schnittstelle, um das Funkmodul anschließen zu können. 4.1 Verwendete Hardware 26 Für diese Arbeit wird der Einplatinencomputer Raspberry Pi 5 verwendet. Er verfügt über eine UART-Schnittstelle zur Kommunikation mit dem Funkmodul und bietet ausreichende Hardware-Ressourcen zur Ausführung der Software. Der Raspberry Pi 5 ist zudem kostengünstig und hat eine geringe Leistungsaufnahme, wodurch er gut für Projekte geeignet ist, die den Betrieb mehrerer Instanzen erfordern, welche über einen längeren Zeitraum laufen sollen. 4.2 Projektstruktur Um den Build-Prozess zu automatisieren, wird in dieser Arbeit das Projektund Build-Management-Tool Apache Maven verwendet. Maven basiert auf dem Konzept eines Project Object Models (POM). Das POM enthält alle Informationen über ein Projekt, einschließlich der Abhängigkeiten, Konfigurationen und Build-Anweisungen. Durch die Automatisierung des gesamten Build-Prozesses stellt Maven sicher, dass der Build-Prozess jederzeit reproduzierbar und konsistent abläuft. Da auf jedem Raspberry Pi ein ASAPPeer initialisiert wird, der das in dieser Arbeit zu entwickelnde System für den Nachrichtenaustausch über LoRa nutzt, wird die ASAPJava-Bibliothek als externe Abhängigkeit benötigt. Die ASAPJava-Bibliothek ist nicht im zentralen Maven-Repository verfügbar und wird daher als .jar -Datei im lib-Ordner des Projektrepositories gespeichert. 1<plugins> 2<plugin> 3<artifactId>maven−install−plugin</artifactId> 4<configuration> 5<file>${basedir}/lib/ASAPJava.jar</file> 6<localRepositoryPath>local−maven−repo</localRepositoryPath> 7</configuration> 8<executions> 9<execution> 10 <phase>validate</phase> 11 </execution> 12 </executions> 13 </plugin> 14 </plugins> 15 16 <repositories> 17 <repository> 18 <url>file:///${basedir}/local−maven−repo</url> 4.2 Projektstruktur 27 19 </repository> 20 </repositories> Listing 4.1: Einbinden der ASAPJava-Bibliothek aus dem lokalen Maven-Repository Um eine Abhängigkeit in Form einer .jar -Datei in Maven nutzen zu können, muss diese zuerst im lokalen Maven-Repository des entsprechenden Rechners installiert werden. Dazu wird das maven-install-plugin verwendet, welches die Abhängigkeit während der validate -Phase des Build-Prozesses in das lokale MavenRepository installiert (siehe Zeilen 2-13 in 4.1). In den Zeilen 16-20 der POM-Datei wird das lokale Maven-Repository definiert, in dem ASAPJava installiert wurde. Dadurch wird sichergestellt, dass Maven die Abhängigkeit ASAPJava im lokalen Repository und nicht im zentralen Maven-Repository sucht. Zusätzlich zu ASAPJava werden in der POM folgende für das Projekt benötigten Abhängigkeiten definiert: • jSerialComm: bietet eine plattformunabhängige API zur seriellen Kommunikation mit dem Funkmodul (Kapitel 4.5) • dotenv-java: ermöglicht es, Umgebungsvariablen aus einer .env -Datei zu laden (Kapitel 4.3) • Log4j: Logging-Framework, um Fehler zu protokollieren und die Anwendungsaktivität zu überwachen • JUnit: Framework zum Testen von Java-Programmen mittels Unit-Tests (Kapitel 5.1) • Mockito: Framework zur Erstellung von Mock-Objekten in Unit-Tests (Kapitel 5.1) •JaCoCo: Tool zur Messung der Testabdeckung (Kapitel 5.2) • Checkstyle: Tool, das Code auf die Einhaltung von Codierungsstandards überprüft (Kapitel 5.2) 4.2 Projektstruktur 28 4.3 Konfiguration der Anwendung Um die Möglichkeit zu bieten, die Konfiguration des zu entwickelnden Systems für den Nachrichtenaustausch über LoRa anzupassen, wurde die abstrakte Klasse ConfigFromEnv entworfen. Diese Klasse ermöglicht das Lesen von Konfigurationswerten aus .env -Dateien. Zum Einlesen der Konfiguration verwendet die Klasse die API der Bibliothek dotenv1. In den .env -Dateien werden die Parameter in Form von Schlüssel-Wert-Paaren definiert. Ein Beispiel für das Format der Parameter ist in 4.2 abgebildet. STRING_VAR="Beispielwert" INT_VAR=1 Listing 4.2: Beispiel für die Definition von Variablen in einer Konfigurationsdatei Von der Klasse ConfigFromEnv abgeleitete Klassen können einen Dateinamen übergeben, aus dem die Konfiguration gelesen wird. Anschließend lassen sich die Methoden der ConfigFromEnv -Klasse nutzen, um Konfigurationswerte unterschiedlicher Datentypen (z. B. Strings und Integers) auszulesen (siehe Abb. 4.2). ConfigFromEnv String getStringValue(String key) String getIntValue(String key) String getBooleanValue(String key) Himo01Config LoRaProtocolConfig Abb. 4.2.: Klassendiagramm der abstrakten Klasse ConfigFromEnv zum Laden von Konfigurationsdaten Innerhalb der Softwarekomponenten Himo01Modem (Abschnitt 4.5) und LoRaProtocol (Abschnitt 4.7) wurden Klassen entwickelt, die von ConfigFromEnv abgeleitet sind, um Konfigurationsparameter zu laden. Werte, die in den Konfigurationsdateien gespeichert sind, können durch das Setzen gleichnamiger Umgebungsvariablen überschrieben werden. Um die Anforderung zu erfüllen, dass das System für den Nachrichtenaustausch ohne Konfiguration durch den Nutzer verwendet werden kann, werden vordefinierte 1https://github.com/cdimascio/dotenv-java (letzter Zugriff: 28.10.2024) 4.3 Konfiguration der Anwendung 29 Konfigurationsdateien bereitgestellt. Diese können durch Editieren der Konfigurationsdateien oder durch Setzen von Umgebungsvariablen überschrieben werden. 4.4 Interface für den Zugriff auf das Funkmodul (OSI-Schicht 2) In diesem Abschnitt wird der Entwurf des Interfaces LoRaModem erläutert (siehe Abb. 4.3). Das Interface dient als Vorlage zur Implementierung einer Softwarekomponente, die den Zugriff auf das Funkmodul ermöglicht und den Austausch von Daten über LoRa (OSI-Schicht 2) erlaubt. Abb. 4.3.: Einordnung der Schnittstelle LoRaModem ins Gesamtsystem Es definiert Methoden sowohl zum Senden und Empfangen von LoRa-Datenpaketen als auch zur Initialisierung und Konfiguration des Funkmoduls (siehe Abb. 4.4). Der Einsatz eines Interfaces ermöglicht eine lose Kopplung zwischen der Implementierung der Schnittstelle für ein konkretes Funkmodul und den restlichen Komponenten des Systems. LoRaModem void initializeModem() void sendMessage(byte[]) BlockingQueue<byte[]> getPayloadQueue() void setAddr(String) void setTargetAddr(String) String getAddr() int getMaxPacketSize() Abb. 4.4.: Klassendiagramm des Java-Interfaces LoRaModem Diese lose Kopplung erfüllt die nicht-funktionale Anforderung, zukünftig auch weitere Funkmodule unkompliziert anbinden zu können. Ein neues Funkmodul lässt sich durch Implementierung des LoRaModem -Interfaces integrieren, ohne Änderungen 4.4 Interface für den Zugriff auf das Funkmodul (OSI-Schicht 2) 30 an anderen Systemkomponenten vornehmen zu müssen. So kann künftig auch ein anderes Funkmodul als das in diesem Projekt eingesetzte HIMO-01M verwendet werden. 4.5 Implementierung der Softwarekomponente für den Zugriff auf das Funkmodul (OSI-Schicht 2) In diesem Abschnitt wird die Implementierung der Softwarekomponente Himo01Modem erläutert. Diese Softwarekomponente ermöglicht den Zugriff auf das HIMO-01MFunkmodul über die UART-Schnittstelle des Raspberry Pi, um mithilfe des LoRaFunkstandards (OSI-Schicht 2) kommunizieren zu können (siehe Abb. 4.5). Abb. 4.5.: Einordnung der Softwarekomponente Himo01Modem zur Anbindung des LoRaFunkmoduls ins Gesamtsystem Die Implementierung erfolgt in der Klasse Himo01Modem , die sich im Java-Package himo01 befindet. Die Klasse realisiert das in Abschnitt 4.4 beschriebene LoRaModem - Interface. Zum Laden von Konfigurationsdaten verwendet die Himo01Modem -Klasse die Klasse Himo01Config (siehe Abb. 4.6). Das Laden der Konfigurationsdaten wird in Abschnitt 4.5.1 beschrieben. Zur Kommunikation über die UART-Schnittstelle mit dem Funkmodul wird die JavaBibliothek jSerialComm2 eingesetzt. Diese plattformübergreifende Java-Bibliothek bietet Entwicklern eine einheitliche API für den Zugriff auf serielle Kommunikationsschnittstellen. Die Kommunikation mit dem Funkmodul wird in Abschnitt 4.5.2 betrachtet. Entwickler können das himo01 -Paket als Black-Box betrachten, da es das LoRaModem - Interface unterstützt und keine Abhängigkeiten zum restlichen Quellcode hat. Es wird nur benötigt, wenn das HIMO-01M-Funkmodul verwendet wird, und kann 2https://github.com/Fazecast/jSerialComm (letzter Zugriff: 28.10.2024) 4.5 Implementierung der Softwarekomponente für den Zugriff auf das Funkmodul (OSI-Schicht 2) 31 him01 Himo01Modem Himo01Config LoRaModem jSerialComm (library) needs use API for UART communication Abb. 4.6.: Klassenstruktur der Softwarekomponente zur Anbindung des HIMO-01MFunkmoduls durch eine alternative Implementierung von LoRaModem ersetzt werden, falls ein anderes Funkmodul zum Einsatz kommt. 4.5.1 Konfiguration der Softwarekomponente Die Softwarekomponente für den Zugriff auf das HIMO-01M-Funkmodul verwendet die in Abschnitt 4.3 beschriebene Implementierung zum Laden von Konfigurationsparametern. Diese Parameter werden in der Datei himo01_config.env definiert, die sowohl die Konfiguration des LoRa-Modems als auch die Verbindungsparameter für die UART-Kommunikation zwischen dem Raspberry Pi und dem Funkmodul umfasst. 1### LoRa modem config ### 2CARRIER_FREQUENCY=433500000 3TRANSMIT_POWER=20 4MODULATION_BANDWIDTH=8 5SPREADING_FACTOR=7 6ERROR_CODING=2 7CRC=1 8IMPLICIT_HEADER_ON=0 9RX_SINGLE_ON=0 10 FREQUENCY_HOP_ON=0 11 HOP_PERIOD=0 12 RX_PACKET_TIMEOUT=3000 13 PAYLOAD_LENGTH=8 14 PREAMBLE_LENGTH=4 15 16 ### UART config ### 17 COM_PORT=/dev/ttyUSB0 18 BAUD_RATE=115200 19 PARITY=0 20 FLOW_CONTROL=0 4.5 Implementierung der Softwarekomponente für den Zugriff auf das Funkmodul (OSI-Schicht 2) 32 21 STOP_BITS=1 22 DATA_BITS=8 Listing 4.3: Standardwerte für die Konfigurationsdatei himo01_config.env Die Konfigurationsdatei enthält im oberen Abschnitt (Zeile 2–14) die Einstellungen für das LoRa-Modem, während im unteren Abschnitt (Zeile 17–22) die Parameter für die UART-Verbindung festgelegt werden (siehe 4.3). 4.5.2 Implementierung der seriellen Kommunikation mit dem Funkmodul Vormann hat in den Vorarbeiten von Rausch und Hartmann die verwendete Base64Kodierung als Schwachstelle identifiziert. Diese ist auf die Implementierung der seriellen Kommunikation mit dem Funkmodul zurückzuführen. Aus diesem Grund soll in diesem Unterabschnitt die Implementierung der seriellen Kommunikation über die UART-Schnittstelle mit dem Funkmodul im Detail betrachtet werden. Schreibender Zugriff auf das HIMO-01M-Funkmodul über UART Zum Ausführen von AT-Befehlen auf dem HIMO-01M-Funkmodul muss ein schreibender Zugriff auf die UART-Schnittstelle erfolgen. Im Folgenden wird der Ablauf zur Ausführung des AT-Befehls zum Senden eines LoRa-Nachrichtenpakets beschrieben. Um ein Nachrichtenpaket über LoRa zu senden, muss das Funkmodul in den Sendemodus versetzt werden. Dazu muss der Befehl AT+SEND , unter Angabe der Länge der zu sendenden Nachricht, in die serielle Schnittstelle geschrieben werden (siehe Abb. 4.7). Als Trennzeichen am Ende jedes Befehls erwartet das HIMO-01M-Funkmodul ein Carriage Return gefolgt von einem Newline-Zeichen ( \r\n ). Dieses wird vor dem Schreibvorgang dem Ende des Befehls hinzugefügt. Das Funkmodul wechselt in den Sendemodus, und die Nachricht „Hello“ kann über die serielle Schnittstelle geschrieben werden. Nachdem das Funkmodul die Nachricht gelesen hat, wird sie per LoRa versendet. In der in Kapitel 3.2 vorgestellten Arbeit von Hartmann wurde eine Base64-Kodierung verwendet, um sicherzustellen, dass das Senden von Daten mit enthaltenen Trennzeichen nicht vorzeitig abgebrochen wird. Dies ist jedoch nicht notwendig, da beim 4.5 Implementierung der Softwarekomponente für den Zugriff auf das Funkmodul (OSI-Schicht 2) 33 Himo01Modem.java LoRa module HIMO-01M write "AT+SEND=5" append delimiter "\r\n" send "AT+SEND=5\r\n" via UART enter sending mode write "Hello" append delimiter "\r\n" send "Hello\r\n" via UART send "Hello" via LoRa Abb. 4.7.: Ausführen der Befehle zum Senden einer Nachricht auf dem HIMO-01MFunkmodul unter Verwendung der UART-Schnittstelle Start des Sendevorgangs die Anzahl der zu übertragenden Bytes an das Funkmodul übergeben wird. Das Funkmodul liest alle Daten bis zur angegebenen Länge, unabhängig vom Inhalt. Lesezugriff auf das HIMO-01M-Funkmodul über UART Es gibt zwei Situationen, in denen das Funkmodul Daten in die serielle Schnittstelle schreibt, die anschließend vom Raspberry Pi gelesen werden: 1. Beim Empfang eines Nachrichtenpakets über LoRa (OSI-Schicht 2). 2. Als Rückmeldung, nachdem ein AT-Befehl vom Funkmodul ausgeführt wurde. Im Folgenden wird das Lesen der seriellen Schnittstelle nach dem Empfang eines LoRa-Pakets betrachtet. Nachdem eine Nachricht über LoRa empfangen wurde, schreibt das Funkmodul die Daten in die serielle Schnittstelle (siehe Abb. 4.8). Innerhalb der Himo01Modem -Klasse wird kontinuierlich aus der seriellen Schnittstelle gelesen, bis das Trennzeichen erreicht wird. Nach dem Auftreten des Trennzeichens wird überprüft, ob die Daten vom Funkmodul eine Antwort auf einen AT-Befehl oder ein empfangenes LoRa-Paket darstellen. 4.5 Implementierung der Softwarekomponente für den Zugriff auf das Funkmodul (OSI-Schicht 2) 34 Empfänger der PDU zu identifizieren. Diese Basisstruktur kann von den jeweiligen PDUs um zusätzliche Felder erweitert werden. MESSAGE_TYPE TARGET_ADDR ADDITIONAL_FIELDS 1 Byte [addr length] Byte n Byte Tab. 4.1.: Übersicht zur Basis-Nachrichtenstruktur aller PDUs Da es insgesamt vier unterschiedliche Arten an PDUs gibt, ist für die Speicherung des Nachrichtentyps ein Feld mit einer Größe von einem Byte ausreichend. Die Länge der Zieladresse ist abhängig vom verwendeten Funkmodul. Das im Rahmen dieser Arbeit eingesetzte Funkmodul HIMO-01M verwendet Hardware-Adressen mit einer Länge von vier Bytes, sodass sich für die Basisstruktur aller PDUs eine Größe von fünf Bytes ergibt. Hello-PDU Hello-PDUs informieren andere Teilnehmer in der Umgebung über die Verfügbarkeit eines neuen Teilnehmers und seine Bereitschaft zur Etablierung einer Punkt-zuPunkt-Verbindung. Die Hello-PDU enthält ein Feld, das den Typ der PDU bestimmt, sowie ein Feld für die Zieladresse (siehe 4.2). MESSAGE_TYPE TARGET_ADDR Hello Broadcast-Adresse Tab. 4.2.: Übersicht über die Felder der Hello-PDU Als Zieladresse für die Hello-PDU wird die Broadcast-Adresse gesetzt, sodass sie an alle Teilnehmer im Empfangsbereich gesendet wird. Hello-Response-PDU Die Hello-Response-PDU wird als Antwort auf den Empfang einer Hello-PDU gesendet und ist Teil des Prozesses zur Etablierung einer Punkt-zu-Punkt-Verbindung zwischen den Teilnehmern. Der Ablauf wird im nachfolgenden Abschnitt 4.7.5 anhand eines Sequenzdiagramms erläutert. Die Hello-Response-PDU enthält ein Feld, das den Typ der PDU bestimmt, sowie ein Feld für die Zieladresse (siehe 4.3). 4.7 Softwarekomponente für ein Layer-3-Protokoll zur Kommunikation über LoRa 41 MESSAGE_TYPE TARGET_ADDR Hello-Response Absender der Hello-PDU Tab. 4.3.: Übersicht über die Felder der Hello-Response-PDU Data-PDU Zum Austausch von Nutzdaten zwischen den Teilnehmern wurde die Data -PDU entworfen. Diese PDU hat neben den Feldern, die den Typ der PDU und die Zieladresse festlegen, ein Feld für eine Nachrichten-ID und ein Feld für die zu sendenden Nutzdaten (siehe 4.4). MESSAGE_TYPE TARGET_ADDR MESSAGE_ID PAYLOAD Data Empfängeradresse Sequenznummer Nutzdaten Tab. 4.4.: Übersicht über die Felder der Data-PDU Die Nachrichten-ID ist eine inkrementelle Sequenznummer, die vom Absender verwaltet wird. Da die Sequenznummer zusammen mit der Absenderadresse verwendet wird, kann sie der Absender dezentral verwalten. Die maximale Länge der Nutzdaten, die mit einer Data-PDU übertragen werden kann, ergibt sich aus der Differenz zwischen dem durch die PDU verursachten Overhead und der maximalen Paketgröße, die über das verwendete Funkmodul mittels LoRa (OSI-Schicht 2) übertragen werden kann. Der durch die PDU verursachte Overhead setzt sich zusammen aus: • 1 Byte für den Nachrichtentyp • 4 Byte für die Zieladresse • 1 Byte für die Nachrichten-ID Bei Verwendung des HIMO-01M-Funkmoduls, das pro LoRa-Paket maximal 250 Bytes Daten übertragen kann, ergibt sich die maximale Nutzdatenlänge einer Data - PDU wie folgt: P ayloadM ax = 250Byte −6Byte = 244Byte Daher können mittels einer Data -PDU maximal 244 Bytes Nutzdaten übertragen werden. 4.7 Softwarekomponente für ein Layer-3-Protokoll zur Kommunikation über LoRa 42 ACK-PDU ACK-PDUs (Acknowledgement-PDUs) sind notwendig, um den Empfang von HelloResponse-PDUs und Data-PDUs zu bestätigen. Diese PDU enthält neben den Feldern, die den Typ der PDU und die Zieladresse festlegen, ein optionales Feld für eine Sequenznummer (siehe 4.5). MESSAGE_TYPE TARGET_ADDR MESSAGE_ID ACK Absender der Data-PDU zu bestätigende Sequenznummer Tab. 4.5.: Übersicht über die Felder der ACK-PDU Das Feld für die Sequenznummer wird ausschließlich verwendet, um den Empfang von Data-PDUs zu bestätigen. In dieses Feld wird die Sequenznummer der zu bestätigenden Data-PDU eingetragen. Das Zusammenspiel zwischen Data-PDUs und ACK-PDUs wird im letzten Abschnitt dieses Kapitels 4.7.6 anhand eines Sequenzdiagramms erläutert. 4.7.5 Aufbau einer Verbindung zwischen den Teilnehmern Dieser Unterabschnitt beschreibt den Prozess zur Etablierung einer Punkt-zu-PunktVerbindung zwischen zwei Teilnehmern aus der Sicht der OSI-Schicht 3, um anschließend den paketbasierten Datenaustausch zwischen ihnen zu ermöglichen. Wie in 4.11 zu Beginn des Abschnitts dargestellt, laufen die Layer-2und Layer-3Komponenten für jeden Teilnehmer auf einem Raspberry Pi, der mit einem Funkmodul verbunden ist. Standardmäßig ist jeder Teilnehmer mit genau einem weiteren Teilnehmer über LoRa verbunden. 3 Die Anzahl der LoRa-Verbindungen pro Teilnehmer sollte niedrig gehalten werden, da mit jeder zusätzlichen Verbindung die Wahrscheinlichkeit von Kollisionen steigt, was die Effizienz des Systems beeinträchtigt. Ablauf Verbindungsaufbau zwischen Alice und Bob Der Prozess des Verbindungsaufbaus zwischen den Teilnehmern Alice und Bob wird durch den Aufruf der start -Methode gestartet (siehe Abb. 4.14). Als Erstes wird 3 Die Konfiguration kann mit dem in 4.7.3 beschriebenen Parameter MAX_LORA_CONNECTIONS angepasst werden. 4.7 Softwarekomponente für ein Layer-3-Protokoll zur Kommunikation über LoRa 43 das LoRa-Funkmodul initialisiert, wobei dem Funkmodul eine zufällige HardwareAdresse zugewiesen wird, sodass keine manuelle Konfiguration erforderlich ist. Sollte es vorkommen, dass zwei Teilnehmer dieselbe Adresse erhalten, wird keine Verbindung aufgebaut, da Nachrichten von Teilnehmern mit identischer Adresse ignoriert werden. Diese Adresskonflikte können in den Log-Dateien nachvollzogen werden und lassen sich durch einen Neustart des Protokolls beheben. Peer Alice Layer-3-Protocol Peer Bob Layer-3-Protocol Initialization start() start() initialize modem initialize modem start P2P connection establishment start sending Hello-PDUs start sending Hello-PDUs received Hello-PDU from Alice while [ Hello-Response not acknowledged & retries < maxRetries] Bob answers with Hello-Response-PDU send ACK-PDU for Hello-Response-PDU ready for communication Abb. 4.14.: Ablauf des Verbindungsaufbaus zwischen Alice und Bob Nach der Initialisierung senden Alice und Bob zur Etablierung einer Punkt-zuPunkt-Verbindung in zufälligen Intervallen von 5 bis 10 Sekunden Hello-PDUs an alle Teilnehmer in Reichweite, um sich bekannt zu machen (siehe Abb. 4.14). Dieses Intervall ist standardmäßig festgelegt, kann jedoch, wie in Abschnitt 4.7.3 beschrieben, angepasst werden. 4 Die zufälligen Sendeabstände sollen verhindern, dass die Nachrichten der Teilnehmer dauerhaft kollidieren. Empfängt ein Teilnehmer, in diesem Fall Bob , eine Hello-PDU, so antwortet er mit einer Hello-Response-PDU. Der Empfang dieser Hello-Response-PDU muss anschließend von Alice bestätigt werden, um sicherzustellen, dass sie weiterhin bereit ist, eine Verbindung mit Bob einzugehen. Bob sendet so lange Hello-Response-PDUs, bis Alice die Nachricht mittels einer ACK-PDU bestätigt hat oder die maximale Anzahl an Versuchen erreicht ist und der Verbindungsaufbau fehlschlägt. 4 In Umgebungen mit vielen Teilnehmern kann eine Anpassung des Intervalls sinnvoll sein, um den Nachrichtenverkehr zu reduzieren und Kollisionen zu vermeiden. 4.7 Softwarekomponente für ein Layer-3-Protokoll zur Kommunikation über LoRa 44 Für Alice ist der Verbindungsaufbau mit Bob abgeschlossen, sobald sie die ACK-PDU gesendet hat; für Bob endet der Prozess mit dem Empfang dieser ACK-PDU. Nach erfolgreicher Etablierung der Punkt-zu-Punkt-Verbindung können zwischen Alice und Bob Nutzdaten in Form von Data-PDU ausgetauscht werden. Fehler beim Verbindungsaufbau Im Folgenden wird der Fehlerfall betrachtet, in dem ein Teilnehmer keine Antwort auf eine Hello-Response-PDU erhält. Zur Veranschaulichung dient ein Beispiel mit den drei Teilnehmern Alice, Bob und Clara. Das Layer-3-Protokoll ist so konfiguriert, dass jeder Teilnehmer nur eine LoRa-Punkt-zu-Punkt-Verbindung zu einem anderen Teilnehmer herstellen kann. Peer Alice Layer-3-Protocol Peer Bob Layer-3-Protocol Peer Clara Layer-3-Protocol start sending Hello-PDUs start sending Hello-PDUs start sending Hello-PDUs received Hello-PDU from Alice received Hello-PDU from Alice send Hello-Response-PDU send Hello-Response-PDU send ACK-PDU for Hello-Response-PDU Peer Alice is now connected to Peer Bob ignore Hello-Response-PDU from peerC while [ retries < maxRetries] send Hello-Response-PDU connection establishment failed Abb. 4.15.: Fehler beim Verbindungsaufbau zwischen den Teilnehmern Clara und Alice Alle drei Teilnehmer starten den Verbindungsaufbau und senden Hello-PDUs (siehe Abb. 4.15). Bob und Clara empfangen jeweils eine Hello-PDU von Alice und antworten mit einer Hello-Response-PDU. Alice empfängt zuerst die Hello-Response-PDU von Bob und kurz darauf diejenige von Clara. Da Alice zuerst die Hello-Response-PDU von Bob empfangen hat, antwortet sie zunächst Bob mittels einer ACK-PDU. Es besteht nun eine Punkt-zu-Punkt-Verbindung zwischen Alice und Bob. 4.7 Softwarekomponente für ein Layer-3-Protokoll zur Kommunikation über LoRa 45 Anschließend verarbeitet Alice die Hello-Response-PDU von Clara. Da Alice bereits eine Verbindung zu Bob aufgebaut hat, verwirft sie die PDU und etabliert keine Verbindung zu Clara. Wenn Clara nach mehreren Sendeversuchen keine Bestätigung von Alice erhält, bricht sie den Verbindungsaufbau ab. Solange das Timeout für den Verbindungsaufbau nicht erreicht ist, hat Clara die Möglichkeit, eine Verbindung zu einem anderen Teilnehmer herzustellen. Sollte Clara bis zum Ablauf des Timeouts keine Verbindung aufbauen können, gilt der Verbindungsaufbau als fehlgeschlagen.5 4.7.6 Nachrichtenaustausch zwischen Teilnehmern Im Folgenden wird der Ablauf des paketorientierten Nachrichtenaustauschs mittels des Layer-3-Protokolls zwischen Alice und Bob beschrieben. Dies erfolgt, nachdem die Teilnehmer, wie in 4.7.5 gezeigt, eine Verbindung aufgebaut haben. Um Nutzdaten an Bob zu übertragen, sendet Alice eine Data-PDU mit der Sequenznummer „1“, die die zu übermittelnden Nutzdaten enthält 6 . Sobald Bob die Data-PDU von Alice empfängt, antwortet er mit einer ACK-PDU, die die Sequenznummer der empfangenen Nachricht enthält, um den Empfang der Nachricht zu bestätigen (siehe Abb. 4.16). Nachdem Alice die ACK-PDU empfangen hat, ist der Sendevorgang abgeschlossen. Alice Layer-3-Protocol Bob Layer-3-Protocol send Data-Message-PDU with message-id 1 answer with ACK-Message-PDU with message-id 1 ready to send next message send Data-Message-PDU with message-id 2 Abb. 4.16.: Ablauf des Sendens einer Nachricht von Alice zu Bob 5 Die Dauer des Timeouts kann mittels des in Abschnitt 4.7.3 beschriebenen Parameters PAIRING_TIMEOUT festgelegt werden. 6 Die Sequenznummer „1“ wird verwendet, da es sich um die erste Nachricht nach dem Verbindungsaufbau handelt 4.7 Softwarekomponente für ein Layer-3-Protokoll zur Kommunikation über LoRa 46 Um die Flusskontrolle sicherzustellen, wird erst nach Empfang der Bestätigungsnachricht das nächste Nachrichtenpaket gesendet. Alice fährt nun mit dem Senden der nächsten Data-PDU mit der Sequenznummer „2“ fort. Ausbleiben der Empfangsbestätigung Beim Datenaustausch zwischen den Teilnehmern kann es vorkommen, dass eine Empfangsbestätigung ausbleibt. Dies kann zwei Ursachen haben: Entweder hat Bob die Data-PDU nicht empfangen, oder die ACK-PDU ist während der Übertragung verloren gegangen. Im in Abbildung 4.17 dargestellten Szenario sendet Alice eine Data-PDU an Bob, erhält jedoch keine ACK-PDU als Bestätigung zurück. Anschließend wartet Alice eine zufällig bestimmte Backoff-Zeit und wiederholt den Sendevorgang. Dies wird so lange fortgesetzt, bis Alice eine Empfangsbestätigung erhält oder die maximale Anzahl von Fehlversuchen erreicht ist.7 Alice Layer-3-Protocol Bob Layer-3-Protocol send Data-PDU with message-id 2 ACK-PDU with message-id 2 received no acknowledge Data-PDU was not received by Bob or ACK-PDU was lost while [ not acknowledged & retries < maxRetries] wait random backoff time resend Data-PDU with message-id 2 ACK-PDU with message-id 2 if [ not acknowledged ] close connection Abb. 4.17.: Ausbleiben einer Empfangsbestätigung beim Datenaustausch zwischen Alice und Bob Sollte der Empfang der Nachricht nach Erreichen der maximalen Anzahl an Fehlversuchen noch nicht von Bob bestätigt worden sein, wird von einem dauerhaften 7 Die Backoff-Zeit und die Anzahl der Versuche können mittels der in 4.7.3 beschriebenen Konfigurationsparameter angepasst werden. 4.7 Softwarekomponente für ein Layer-3-Protokoll zur Kommunikation über LoRa 47 Verbindungsproblem ausgegangen. Es besteht somit keine Verbindung mehr zwischen den Teilnehmern. Versucht Bob anschließend, eine Nachricht an Alice zu senden, wird auch er keine Empfangsbestätigung erhalten. Auf diese Weise erfährt auch Bob, dass keine Verbindung zu Alice mehr besteht. Damit wieder Daten ausgetauscht werden können, muss ein erneuter Verbindungsaufbau zwischen den Teilnehmern erfolgen. 4.8 Softwarekomponente für streambasierte Kommunikation über eine LoRa-Punkt-zu-Punkt-Verbindung (OSI-Schicht 4) Um die LoRa-Punkt-zu-Punkt-Verbindung für den streambasierten Datenaustausch zwischen Teilnehmern nutzen zu können, wurde die Softwarekomponente TCPLoRaSocket entwickelt. Diese baut auf dem Layer-3-Protokoll auf, das lediglich eine paketorientierte Kommunikation über die LoRa-Verbindung ermöglicht, und bietet einen TCP-Socket (OSI-Schicht 4) an, um streambasiert Daten über LoRa austauschen zu können (siehe Abb. 4.18). Abb. 4.18.: Einordnung der Softwarekomponente TCPLoRaSocket für die streambasierte Kommunikation über eine LoRa-Punkt-zu-Punkt-Verbindung in das Gesamtsystem Die Implementierung dieser Komponente erfolgt in der abstrakten Klasse TCPLoRaSocket , die sich im Java-Package stream_based befindet. Um eine Anwendung zu erstellen, die streambasiert über das Layer-3-Protokoll kommuniziert, muss eine Klasse implementiert werden, die von TCPLoRaSocket erbt (siehe Abb. 4.19). In dieser abgeleiteten Klasse ist es erforderlich, die Methode connectionEstablished zu implementieren, die nach erfolgreicher Einrichtung einer Punkt-zu-Punkt-Verbindung einen Socket für die streambasierte Kommunikation übergibt. 4.8 Softwarekomponente für streambasierte Kommunikation über eine LoRa-Punkt-zu-Punkt-Verbindung (OSI-Schicht 4) 48 stream_based TCPLoRaSocket void connectionEstablished(String targetAddr, Socket socket) Application Abb. 4.19.: Klassendiagramm zur abstrakten Klasse TCPLoRaSocket 4.8.1 Ablauf streambasierter Datenaustausch über Layer-3-Protokoll Im Folgenden werden die Schritte zur Bereitstellung eines Sockets für den streambasierten Datenaustausch über LoRa aus der Perspektive der OSI-Schicht 4 beschrieben. Zudem wird erläutert, wie eine Anwendung diesen Socket nutzen kann, um Daten zu senden und zu empfangen. Die TCPLoRaSocket -Klasse wird als Listener beim Layer-3-Protokoll registriert, um auf dessen Ereignisse reagieren zu können (siehe Abb. 4.20). Anschließend wird das Layer-3-Protokoll gestartet, wodurch der Prozess zur Etablierung einer LoRa-Punktzu-Punkt-Verbindung initiiert wird. Daraufhin wird innerhalb der TCPLoRaSocket - Klasse ein TCP-Server-Socket erstellt. Nachdem eine Punkt-zu-Punkt-Verbindung zu einem anderen Teilnehmer über LoRa aufgebaut wurde, benachrichtigt das Layer-3-Protokoll die TCPLoRaSocket -Klasse. Daraufhin wird innerhalb der TCPLoRaSocket-Klasse ein TCP-Client-Socket erstellt, der eine Verbindung zu dem zuvor erstellten Server-Socket herstellt. Der Client-Socket und die Adresse des Zielteilnehmers werden an eine Anwendung übergeben, die diese für die streambasierte Kommunikation über LoRa nutzen kann, um Daten zu senden und zu empfangen.8 Wenn die Anwendung Daten in den Client-Socket schreibt, werden diese über TCP/IP an den Server-Socket innerhalb der TCPLoRaSocket -Klasse gesendet. Die TCPLoRaSocket -Klasse liest die Daten anschließend aus dem Server-Socket. Sind die Daten größer als die maximale zulässige Nutzdatenlänge pro Nachrichtenpaket (Data-PDU), werden die Daten in separaten Paketen nacheinander gesendet. Die Flusskontrolle wird sichergestellt, indem erst dann die nächsten Daten aus dem 8 Da es möglich ist, LoRa-Verbindungen zu mehreren Teilnehmern herzustellen, wird dieser Vorgang für jede etablierte LoRa-Punkt-zu-Punkt-Verbindung wiederholt. Für jede Verbindung wird der Anwendung ein separater Socket zur Kommunikation übergeben. 4.8 Softwarekomponente für streambasierte Kommunikation über eine LoRa-Punkt-zu-Punkt-Verbindung (OSI-Schicht 4) 49 application (layer 5-7) TCPLoRaSocket (layer-4) LoRaProtocol (layer-3) connection establishment register as listener start layer-3-protocol start connection establishment create TCP server socket Established connection to target peer via LoRa notify P2P connection established create TCP client socket connect to server socket pass TCP client socket and target address send data write data to socket read [max payload bytes] from socket send message send data via LoRa receive data received data from another peer notify message received write data to socket data transferred via TCP Abb. 4.20.: Streambasierter Datenaustausch über das Layer-3-Protokoll unter Verwendung der TCPLoRaSocket-Klasse Socket gelesen werden, wenn das vorherige Datenpaket erfolgreich über LoRa zugestellt und vom Empfänger bestätigt wurde. Beim Empfang einer Data-PDU über LoRa übergibt das Layer-3-Protokoll die empfangenen Daten an die TCPLoRaSocket -Klasse. Die Daten werden dann in den Server-Socket geschrieben, sodass sie von der Anwendung über den Client-Socket gelesen werden können. 4.8.2 Behandlung von Verbindungsproblemen Wenn es in der LoRa-Punkt-zu-Punkt-Verbindung zwischen den Teilnehmern zu einem dauerhaften Verbindungsproblem kommt, informiert das Layer-3-Protokoll die Klasse TCPLoRaSocket , dass keine Verbindung mehr zum Zielteilnehmer besteht (siehe Abb. 4.21). 4.8 Softwarekomponente für streambasierte Kommunikation über eine LoRa-Punkt-zu-Punkt-Verbindung (OSI-Schicht 4) 50 Testing 5 In diesem Kapitel wird beschrieben, wie die korrekte Funktionsweise der in Kapitel 4erläuterten Softwarekomponenten mithilfe unterschiedlicher Testmethoden nachgewiesen wurde. Zunächst werden die Unit-Tests vorgestellt. Diese dienen dazu, die einzelnen Softwarekomponenten unabhängig voneinander zu überprüfen und deren korrekte Funktionalität sicherzustellen. Daraufhin wird der Einsatz von Softwaretools zur Codequalitätsanalyse beschrieben. Zusätzlich wird die Implementierung einer CI/CD-Pipeline erläutert, die kontinuierlich die Codequalität überprüft und die aktuelle Version der Anwendung baut. Es folgt der Praxistest, der das System unter realen Bedingungen erprobt. Abschließend erfolgt der Integrationstest, der die Ende-zu-Ende-Funktionalität des Systems demonstriert und das korrekte Zusammenspiel aller Softwarekomponenten zeigt. 5.1 Unit-Tests Mit JUnit wurden die in Kapitel 4beschriebenen Softwarekomponenten der OSISchichten 2 bis 4 sowie die Integration der ASAPJava-Bibliothek getestet. JUnit ist ein Framework zur Durchführung automatisierter Unit-Tests in Java-Programmen. Zusätzlich kam das Mockito-Framework zum Einsatz, das eine API zur Erstellung von Mock-Objekten bereitstellt. Mock-Objekte ersetzen in Unit-Tests reale Objekte und simulieren externe Abhängigkeiten, sodass das Verhalten einzelner Komponenten getestet werden kann, ohne dass externe Systeme oder Schnittstellen tatsächlich vorhanden sein müssen. 57 5.1.1 Beispiel für die Verwendung von Mockito innerhalb eines JUnit-Tests Das Mockito-Framework wurde unter anderem zum Testen der Softwarekomponente verwendet, die zur Anbindung des LoRa-Funkmoduls (OSI-Schicht 2) entwickelt wurde. Diese Softwarekomponente kommuniziert über eine serielle Schnittstelle mit dem Funkmodul. Um die Softwarekomponente unabhängig von der Hardware testen zu können, wurde ein Mock-Objekt für die serielle Schnittstelle erstellt. Als Beispiel wird ein Testfall betrachtet, der das Lesen eines empfangenen LoRaPakets aus der seriellen Schnittstelle überprüft (siehe Listing 5.1). 1@Test 2public void readLoRaPackageFromUART() { 3String msg = "LR,0130,05,hello\r\n"; 4SerialPortEvent serialPortEvent = mock(SerialPortEvent.class); 5when(serialPortEvent.getReceivedData()).thenAnswer(msg.getBytes()); 6 7himo01Modem.serialEvent(serialPortEvent); 8 9assertEquals("hello",new String(payloadQueue.poll().payload())); 10 assertEquals("0130", payloadQueue.poll().sourceAddr()); 11 } Listing 5.1: JUnit-Test zur Überprüfung des Empfangs von LoRa-Paketen über eine gemockte serielle Schnittstelle Zuerst wird ein String erstellt, der ein empfangenes LoRa-Paket repräsentiert (Zeile 3). Anschließend wird unter Verwendung der API des Mockito-Frameworks ein Mock-Objekt der Klasse SerialPortEvent erstellt (Zeile 4). Objekte dieser Klasse werden erzeugt, wenn Daten über die serielle Schnittstelle empfangen werden. Das Mock-Objekt wird so konfiguriert, dass seine Methode getReceivedData den Wert des Strings in der Variablen msg zurückgibt (Zeile 5). Daraufhin wird die Methode serialEvent() der zu testenden Softwarekomponente mit dem Mock-Objekt als Argument aufgerufen (Zeile 7). Abschließend wird überprüft, ob der Payload des empfangenen LoRa-Pakets und die Quelladresse des Pakets korrekt sind (Zeilen 9–10). Mit der Mockito-API lässt sich das Verhalten eines Mock-Objekts dynamisch und mit wenigen Codezeilen konfigurieren. Ohne Mockito müssten hingegen Mock-Klassen manuell implementiert werden, was mehr Aufwand bedeutet. 5.1 Unit-Tests 58 5.2 Analysetools für Codequalität Zur Sicherstellung einer hohen Codequalität kommen in diesem Projekt zwei Analysetools zum Einsatz: eines zur Messung der Testabdeckung und eines zur statischen Codeanalyse, die im Folgenden näher vorgestellt werden. 5.2.1 Tool zum Messen der Testabdeckung Zur Messung der durch Unit-Tests erreichten Testabdeckung wird das Open-SourceTool JaCoCo 1 (Java Code Coverage) eingesetzt. JaCoCo erfasst sowohl die LineCoverage als auch die Branch-Coverage. Für JaCoCo gibt es ein Maven-Plugin, das es ermöglicht, die Testabdeckung automatisiert während des Build-Prozesses zu ermitteln. Die Ergebnisse werden als .html -Bericht gespeichert und können anschließend im Webbrowser angezeigt werden. Aktuell liegt die durch Unit-Tests erreichte Line-Coverage bei 86% und die BranchCoverage bei 77%.2 5.2.2 Tool für die statische Code-Analyse Für die statische Code-Analyse wird das Open-Source-Tool Checkstyle 3 verwendet. Checkstyle überprüft den Java-Quellcode auf die Einhaltung von Codierungsrichtlinien und Konventionen. Das Tool analysiert dabei Aspekte wie die Formatierung (z. B. Einrückungen und Leerzeichen), Namenskonventionen und Regeln für Kommentare. Auf diese Weise wird sichergestellt, dass der Code konsistent und gut lesbar bleibt, was die Wartbarkeit und Verständlichkeit des Codes verbessert. Für Checkstyle gibt es ebenfalls ein Maven-Plugin, sodass die Code-Analyse automatisch während des Build-Prozesses ausgeführt wird. Die Ergebnisse werden als Bericht in Form einer .html-Datei bereitgestellt. 1https://www.jacoco.org (letzter Zugriff: 28.10.2024) 2 Der vollständige Coverage Report ist unter https://marvin_rausch.gitlab.io/lora-messenger/ jacoco/ (letzter Zugriff: 28.10.2024) abrufbar. 3https://checkstyle.sourceforge.io (letzter Zugriff: 28.10.2024) 5.2 Analysetools für Codequalität 59 5.3 CI/CD-Pipeline In diesem Projekt wird der Code mittels der git-basierten Versionsverwaltung GitLab verwaltet. GitLab bietet die Möglichkeit, eine Continuous Integration/Continuous Deployment ( CI/CD )-Pipeline 4 für Repositories einzurichten. Eine CI/CDPipeline ist ein automatisierter Prozess, der in einer von GitLab bereitgestellten Cloud-Infrastruktur ausgeführt wird, um Softwareanwendungen kontinuierlich zu integrieren, zu testen und bereitzustellen. Dazu können in der Datei .gitlab-ci.yaml Jobs definiert werden, die unter festgelegten Bedingungen bei jedem Commit ins Repository ausgeführt werden. Im Folgenden wird der Ablauf der für dieses Projekt implementierten CI/CD-Pipeline anhand eines Aktivitätsdiagramms erläutert. 5.3.1 Ablauf der CI/CD-Pipeline Die CI/CD-Pipeline wird nur dann ausgeführt, wenn Änderungen im Source-Code der Anwendung vorliegen. Daher wird zunächst geprüft, ob Änderungen im SourceCode vorhanden sind (siehe Abb. 5.1). Falls keine Änderungen festgestellt werden, wird die Ausführung der CI/CD-Pipeline übersprungen. Enthält ein Commit Änderungen im Source-Code der Anwendung, wird als Erstes das Maven-Projekt gebaut, um sicherzustellen, dass alle Abhängigkeiten aufgelöst und der Quellcode erfolgreich kompiliert werden kann. Anschließend werden die Unit-Tests sowie Tools zur Messung der Testabdeckung und zur statischen Codeanalyse ausgeführt. Sollte die Line-Coverage unter den aktuellen Wert von 86% fallen, schlägt die Pipeline fehl. Dadurch wird sichergestellt, dass die Testabdeckung durch zukünftige Änderungen nicht abnimmt. Wenn die Anwendung später im Produktivbetrieb eingesetzt wird, kann dieser Wert erhöht werden, um den gestiegenen Anforderungen an die Codequalität gerecht zu werden. Im nächsten Schritt wird die Quellcodedokumentation mithilfe von Javadoc erstellt. Dieses Tool generiert die Dokumentation auf Basis spezieller Kommentare direkt im Quellcode. Die resultierende Dokumentation umfasst unter anderem Beschreibungen von Klassen, Methoden und Konstruktoren und wird als HTML-Datei zur Verfügung gestellt. 4https://docs.gitlab.com/ee/ci (letzter Zugriff: 28.10.2024) 5.3 CI/CD-Pipeline 60 Commit code to repository Source code or tests changed? no yes skip CI/CD build maven project run unit tests and code analysis tools build Javadoc documentation deploy results to GitLab Pages Abb. 5.1.: Aktivitätsdiagramm zum Ablauf der CI/CD-Pipeline nach dem Committen von Änderungen Abschließend werden die Berichte der Code-Analysetools und die Javadoc-Dokumentation über GitLab Pages veröffentlicht. GitLab Pages ist eine Funktion von GitLab, die es ermöglicht, statische Websites direkt aus einem Git-Repository zu erstellen und zu hosten. Dadurch können die neuesten Ergebnisse der Code-Analysetools sowie die aktuelle Javadoc-Dokumentation in der README-Datei des Repositories als Link hinterlegt und direkt im Browser aufgerufen werden.5 Durch den Einsatz der CI/CD-Pipeline wird sichergestellt, dass jede Änderung des Codes automatisiert überprüft wird, einschließlich der Testabdeckung, der statischen Codeanalyse und der Ausführung von Unit-Tests. Dies minimiert das Risiko, dass fehlerhafter Code integriert wird, und gewährleistet die kontinuierliche Einhaltung der Codequalität. 5.4 Praxistest Um die Funktionsfähigkeit des entwickelten Systems unter realitätsnahen Bedingungen zu überprüfen, wurde eine Kommandozeilen-Chat-Applikation entwickelt. 5https://gitlab.com/marvin_rausch/lora-messenger/-/blob/main/README.md (letzter Zugriff: 28.10.2024) 5.4 Praxistest 61 Diese Applikation, im Folgenden als Demo-App bezeichnet, wird als zusätzliche Softwarekomponente auf dem Raspberry Pi gestartet. Die Demo-App baut auf der Softwarekomponente ASAPLoRa auf, die einen ASAPPeer und alle in Abbildung 5.2 dargestellten Komponenten initialisiert. Abb. 5.2.: Integration der Demo-Applikation in das Gesamtsystem Die Demo-App kann entweder direkt auf dem Raspberry Pi bedient werden, wenn Tastatur und Bildschirm angeschlossen sind, oder sie kann remote über Secure Shell ( SSH ) gesteuert werden. Die Implementierung befindet sich in der Klasse ASAPMessenger im Package app des Projekts. 6 Sie verwendet die vom ASAPPeer bereitgestellten Methoden zum Senden und Empfangen von Nachrichten. Die Nachrichten werden von der Demo-App über die Konsole eingelesen und anschließend über LoRa übertragen. Nachrichten, die von anderen Teilnehmern über LoRa empfangen werden, werden auf der Konsole angezeigt, einschließlich der Angabe der zurückgelegten Hops. Die Demo-App kann verwendet werden, um Ad-hoc-Netzwerke mit einer beliebigen Anzahl von Teilnehmern aufzubauen. Dadurch lässt sich auch die Zuverlässigkeit des Systems bei einer größeren Anzahl von Teilnehmern prüfen und mögliche Schwachstellen identifizieren. Die Demo-App eignet sich nicht nur für Testzwecke, sondern auch zur Demonstration der Funktionsweise des Systems. 5.4.1 Durchführung eines Praxistests Unter Verwendung der Demo-App wurde ein Ad-hoc-Netzwerk mit vier Teilnehmern aufgebaut. Das System wurde so konfiguriert, dass jeder Teilnehmer bis zu drei LoRa-Verbindungen aufbauen konnte. Dadurch entstand ein vollständig vermaschtes 6 Beim Build-Prozess des Projekts wird eine ausführbare .jar -Datei für die Demo-App erstellt, die sich unter target/ASAPLoRa.jar befindet. 5.4 Praxistest 62 Netzwerk, in dem jeder Teilnehmer mit jedem anderen verbunden war (siehe Abb. 5.3). Abb. 5.3.: Aufbau eines LoRa-Ad-hoc-Netzwerks mit vier Teilnehmern Die Teilnehmer wurden in unterschiedlichen Räumen verteilt, wobei die maximale Entfernung zwischen den Teilnehmern etwa 20 Meter betrug. Einerseits wurde getestet, ob alle Teilnehmer nach dem Starten der Demo-App eine Verbindung zueinander aufbauen. Zudem wurde überprüft, wie zuverlässig das Senden von Nachrichten unterschiedlicher Größe, im Bereich von 5 bis 500 Bytes, funktioniert. Dieses Szenario wurde mehrfach wiederholt, wobei sich zeigte, dass der Verbindungsaufbau zuverlässig innerhalb weniger Sekunden erfolgte und die gesendeten Nachrichten unmittelbar bei den anderen Teilnehmern eintrafen, wobei kaum eine Latenz auftrat. 5.5 Integrationstest (Ende-zu-Ende) In diesem Abschnitt wird die korrekte Funktionsweise aller Softwarekomponenten Ende-zu-Ende mittels eines Integrationstests demonstriert. Zunächst werden in Abschnitt 5.5.1 der Testaufbau und die zur Testausführung benötigten Komponenten erläutert. Anschließend wird in Abschnitt 5.5.2 der Ablauf des Integrationstests anhand eines Sequenzdiagramms beschrieben. 5.5.1 Testaufbau und benötigte Komponenten zur Testausführung Ein Ende-zu-Ende-Szenario in der Praxis wäre der Nachrichtenaustausch zwischen zwei mobilen Endgeräten über eine LoRa-Punkt-zu-Punkt-Verbindung. Um dieses Szenario mittels eines automatisierten Integrationstests abzudecken, werden keine mobilen Endgeräte verwendet, sondern zwei ASAPPeers, die auf demselben Rechner laufen (siehe Abb. 5.4). 5.5 Integrationstest (Ende-zu-Ende) 63 Abb. 5.4.: Überblick über den Aufbau des Integrationstests Für den Integrationstest werden zwei Raspberry Pis benötigt, die jeweils mit einem LoRa-Funkmodul verbunden sind. Auf den beiden Raspberry Pis laufen die ASAPPeers Peer-C und Peer-D , die über LoRa eine Verbindung miteinander herstellen. Zum Starten der ASAPPeers sowie der Softwarekomponenten zur Etablierung einer LoRa-Punkt-zu-Punkt-Verbindung auf den Raspberry Pis kann die im Abschnitt Praxistest beschriebene Demo-App verwendet werden, die als ausführbare .jar-Datei verfügbar ist. Neben den Raspberry Pis wird ein zusätzlicher Rechner benötigt, auf dem der Integrationstest ausgeführt wird. Der Integrationstest ist in der JUnit-Testklasse LoRaIntegrationTest implementiert worden.7 Innerhalb dieses Integrationstests werden die ASAPPeers Peer-A und Peer-B auf dem Rechner gestartet. Beide ASAPPeers stellen jeweils eine TCP/IP-Verbindung zu einem Raspberry Pi her. Damit die Verbindung erfolgreich aufgebaut werden kann, muss sich der Rechner im selben TCP/IP-Netzwerk wie die Raspberry Pis befinden. 5.5.2 Ablauf Integrationstest Am Integrationstest sind die in 5.4 dargestellten Teilnehmer Peer-A , Peer-B , Peer-C und Peer-D beteiligt. Ziel des Tests ist es zu überprüfen, ob Peer-B die Nachricht von Peer-A erhält, die mithilfe der Multi-Hop-Funktion von ASAP über die Teilnehmer Peer-C und Peer-D weitergeleitet wird. 7Die Klasse befindet sich im integration_test-Package im Testverzeichnis des Projekts. 5.5 Integrationstest (Ende-zu-Ende) 64 Zunächst werden die ASAPPeers auf den Raspberry Pis ( Peer-C und Peer-D ) gestartet, die anschließend über LoRa eine Verbindung zueinander aufbauen (siehe Abb. 5.5). Daraufhin bauen die ASAPPeers auf dem Rechner ( Peer-A und Peer-B ) jeweils eine TCP/IP-Verbindung zu einem ASAPPeer auf einem Raspberry Pi auf. Nun besteht zwischen den ASAPPeers eine Multi-Hop-Verbindung, wie in Abbildung 5.4 dargestellt. Peer-A and Peer-B (PC) Peer-C (Raspberry Pi) Peer-D (Raspberry Pi) establish connections establish connection via LoRa to Peer-D establish connection via LoRa to Peer-C initialize ASAPPeers Peer-A and Peer-B establish connection via TCP/IP to Peer-C establish connection via TCP/IP to Peer-D send message Peer-A sends message via TCP/IP Peer-C forwards message to Peer-D via LoRa Peer-D forwards message to Peer-B via TCP/IP Peer-B received message from Peer-A received message is equal to original message from Peer-A [received message is not equal] test success test failed Abb. 5.5.: Ablauf eines Integrationstests für den Nachrichtenaustausch zwischen Teilnehmern über TCP/IP und LoRa Nachdem die Verbindungen zwischen den beteiligten ASAPPeers erfolgreich etabliert worden sind, sendet Peer-A eine Nachricht. Die Nachricht wird über TCP/IP an Peer-C übertragen. Peer-C leitet die Nachricht anschließend über LoRa an Peer-D weiter. Nachdem Peer-D die Nachricht empfangen hat, leitet er diese über TCP/IP zu Peer-B weiter. Nachdem Peer-B die Nachricht empfangen hat, wird innerhalb des Integrationstests überprüft, ob die von Peer-B empfangene Nachricht mit der ursprünglich von Peer5.5 Integrationstest (Ende-zu-Ende) 65 A gesendeten Nachricht identisch ist. Wenn die Nachrichten übereinstimmen, wird der Test als erfolgreich gewertet; andernfalls schlägt der Test fehl. Der ASAPPeer, der die Nachricht sendet, und der ASAPPeer, der die Nachricht schlussendlich empfängt, werden in derselben Testklasse initialisiert. Aus diesem Grund kann dieser Integrationstest auch als Grundlage für zukünftige Performancetests zur Messung der Verzögerung und des Datendurchsatzes verwendet werden. 5.5.3 Workaround für Multi-Hop-Routing-Fehler Bei der Ausführung des Integrationstests wurde ein Fehler in der ASAPJava-Bibliothek entdeckt. Zu diesem Fehler wurde ein Issue im GitHub-Projekt von ASAPJava erstellt.8 Der Fehler betrifft die Multi-Hop-Kommunikation von ASAP. Im konkreten Testaufbau bedeutet dies, dass Peer-C die Nachricht von Peer-A empfängt, sie jedoch aufgrund des Fehlers nicht an Peer-D weiterleitet (siehe Abb. 5.6). Dadurch empfängt Peer-B die Nachricht nie, was zum Scheitern des Tests führt. Abb. 5.6.: Fehler in der ASAPJava-Bibliothek: Empfangene Nachrichten werden nicht weitergeleitet Die Fehleranalyse ergab, dass ASAPPeers Nachrichten nur dann weiterleiten, wenn diese vor dem Verbindungsaufbau zu einem zweiten ASAPPeer empfangen wurden. Um dennoch die korrekte Funktionsweise aller Softwarekomponenten Ende-zu-Ende demonstrieren zu können, wurde ein Workaround für den Verbindungsaufbau der ASAPPeers auf den Raspberry Pis implementiert, der diese Erkenntnis nutzt. Dieser Workaround besteht darin, dass Peer-C und Peer-D erst dann eine Verbindung zu einem zweiten ASAPPeer herstellen, nachdem sie die weiterzuleitende Nachricht empfangen haben. 8https://github.com/SharedKnowledge/ASAPJava/issues/5 (letzter Zugriff: 28.10.2024) 5.5 Integrationstest (Ende-zu-Ende) 66 4.10. Überblick über die Schnittstelle Protocol zur Implementierung eines Layer-3-Protokolls .............................. 36 4.11. Einordnung der Softwarekomponente LoRaProtocol innerhalb des Gesamtsystems, die das Layer-3-Protokoll implementiert .......... 37 4.12. Übersicht über die Klassenstruktur der Softwarekomponente zur Implementierung des Layer-3-Protokolls ..................... 37 4.13. Verwendung des Entwurfsmusters der Schablonenmethode innerhalb der abstrakten Klasse ProtocolBase .................... 38 4.14. Ablauf des Verbindungsaufbaus zwischen Alice und Bob ......... 44 4.15. Fehler beim Verbindungsaufbau zwischen den Teilnehmern Clara und Alice ..................................... 45 4.16. Ablauf des Sendens einer Nachricht von Alice zu Bob .......... 46 4.17. Ausbleiben einer Empfangsbestätigung beim Datenaustausch zwischen Alice und Bob ................................ 47 4.18. Einordnung der Softwarekomponente TCPLoRaSocket für die streambasierte Kommunikation über eine LoRa-Punkt-zu-Punkt-Verbindung in das Gesamtsystem .............................. 48 4.19. Klassendiagramm zur abstrakten Klasse TCPLoRaSocket ......... 49 4.20. Streambasierter Datenaustausch über das Layer-3-Protokoll unter Verwendung der TCPLoRaSocket-Klasse .................... 50 4.21. Auftreten von Verbindungsproblemen beim streambasierten Datenaustausch über das Layer-3-Protokoll ..................... 51 4.22. Schließen der streambasierten Verbindung auf Anwendungsebene . . . 51 4.23. Einordnung der Softwarekomponente ASAPLoRa zur Integration des ASAPPeers ins Gesamtsystem ........................ 52 4.24. Übersicht über die Klassenstruktur der Softwarekomponente ASAPLoRa innerhalb des Java-Packages asap_lora .................. 53 4.25. Verbindungsaufbau des ASAPPeers auf dem Raspberry Pi: Eine Verbindung zu einem ASAPPeer über LoRa und eine weitere Verbindung zu einem zweiten ASAPPeer über TCP/IP ................... 54 4.26. Die ASAPPeers auf den Raspberry Pis fungieren als Gateways, um einzelne Endgeräte oder Teilnetze über LoRa miteinander zu verbinden. . 55 4.27. Einordnung der Erweiterung der ASAPAndroid-Bibliothek ins Gesamtsystem .................................... 55 5.1. Aktivitätsdiagramm zum Ablauf der CI/CD-Pipeline nach dem Committen von Änderungen ............................. 61 5.2. Integration der Demo-Applikation in das Gesamtsystem ......... 62 5.3. Aufbau eines LoRa-Ad-hoc-Netzwerks mit vier Teilnehmern ....... 63 Abbildungsverzeichnis 73 5.4. Überblick über den Aufbau des Integrationstests ............. 64 5.5. Ablauf eines Integrationstests für den Nachrichtenaustausch zwischen Teilnehmern über TCP/IP und LoRa .................... 65 5.6. Fehler in der ASAPJava-Bibliothek: Empfangene Nachrichten werden nicht weitergeleitet ............................. 66 Abbildungsverzeichnis 74 Tabellenverzeichnis 2.1. Arbeitszyklus für die EU868-Subbänder nach ETSI EN300.220 [14]. . . 11 2.2. Aufbau eines LoRa-Pakets auf Ebene der Bitübertragungsschicht (Explizit Header Mode) ................................. 13 2.3. Übersicht der für diese Arbeit relevanten AT-Befehle des Funkmoduls HIMO-01M .................................. 15 4.1. Übersicht zur Basis-Nachrichtenstruktur aller PDUs ............ 41 4.2. Übersicht über die Felder der Hello-PDU .................. 41 4.3. Übersicht über die Felder der Hello-Response-PDU ............. 42 4.4. Übersicht über die Felder der Data-PDU ................... 42 4.5. Übersicht über die Felder der ACK-PDU ................... 43 75 List of Listings 2.1. Senden einer Nachricht mit ASAPJava ................... 6 2.2. Registrierung eines ASAPMessageReceivedListeners für den Empfang von Nachrichten .................................. 7 2.3. Aufruf der asapMessagesReceived-Methode nach Empfang neuer Nachrichten ..................................... 8 4.1. Einbinden der ASAPJava-Bibliothek aus dem lokalen Maven-Repository . 27 4.2. Beispiel für die Definition von Variablen in einer Konfigurationsdatei . . 29 4.3. Standardwerte für die Konfigurationsdatei himo01_config.env ..... 32 4.4. Standardwerte für die Konfigurationsdatei lora_protocol_config.env 39 5.1. JUnit-Test zur Überprüfung des Empfangs von LoRa-Paketen über eine gemockte serielle Schnittstelle ........................ 58 76 Appendix A A.1 Link zum Quellcode der Software Der Quellcode der entwickelten Software sowie die zugehörige Dokumentation sind im folgenden GitLab-Repository zu finden: https://gitlab.com/marvin_rausch/lora-messenger Die Erweiterungen der ASAPAndroid-Bibliothek befinden sich im GitHub-Repository von ASAPAndroid: https://github.com/SharedKnowledge/ASAPAndroid 77 Eidesstattliche Erklärung Hiermit erkläre ich an Eides statt, dass ich die Ihnen vorliegende Bachelorarbeit selbstständig und ohne Nutzung anderer als der aufgeführten Hilfsmittel erstellt habe. Die direkte oder indirekte Übernahme von Gedanken aus fremden Quellen ist als solche kenntlich gemacht. Die Arbeit hat in gleicher oder ähnlicher Form noch keiner anderen Prüfungsbehörde vorgelegen und wurde auch noch nicht veröffentlicht. Berlin, den 28.10.2024 Marvin Rausch