Entwicklung einer Managementkomponente für Langstrecken-AdHoc-Netzwerke unter Android
Abschlussarbeit
zur Erlangung des akademischen Grades:
Bachelor of Science (B.Sc.)
an der
Hochschule für Technik und Wirtschaft (HTW) Berlin Fachbereich 4: Informatik, Kommunikation und Wirtschaft
StudiengangAngewandte Informatik
1. Gutachter: Prof. Dr.-Ing. Thomas Schwotzer 2. Gutachter: Prof. Dr. Alexander Huhn
Eingereicht von Benjamin Felix Willy Hartmann [559347]
9. März 2021
Ziel dieser Bachelorarbeit ist die Anbindung eines Langstrecken-Funkmodems für die Implementation desASAP-Protokolls für Android-Smartphones.
Hierzu soll eine JAVA-Komponente entstehen, welche (Halb-)Duplex-Kommunikation über LoRa zwischen zwei Android-Smartphones mittels eines Funkmoduls ermöglicht.
Dieses Funkmodul soll entworfen und prototypisch aufgebaut werden. Für das Funk- modul ist eine Firmware zu entwickeln.
Die Kommunikation zwischen Funkmodul und Android-Smartphone soll über Blue- tooth erfolgen. Das Funkmodul erhält hierfür einen Microcontroller (ESP32), welcher wiederum über eine serielle Schnittstelle an das Langstreckenfunkmodem (HIMO-01P beziehungsweise HIMO-01M) angebunden ist.
Abbildung 0.1.:Schematischer Aufbau der Kommunikationsstrecke
Abstract (English)
Goal of this bachelor thesis is the integration of a long-range radio module for the implementation of theASAPprotocol for Android smartphones.
For this purpose, a JAVA component is to be developed, enabling (half-)duplex commu- nication via LoRa between two smartphones, using a radio module. This radio module is to be designed and prototyped. Firmware is to be developed for the radio module.
Communication between the radio module and the Android smartphone is to ta- ke place via Bluetooth. The radio module will be equipped with a microcontroller (ESP32), which will be connected to the long-distance radio module (HIMO-01P / HIMO-01M) via a serial interface.
Abbildung 0.2.:Schematic structure of the transmission line
Abstract i
Abstract (English) ii
1 Einleitung 1
1.1 Hintergrund der Arbeit 1
1.2 Problem- und Zielstellung 2
1.3 Aufbau der Arbeit 3
2 Vergleichbare Projekte 4
2.1 LoRaHAM 4
2.2 Meshtastic 4
2.3 CellSol 5
3 Grundlagen 6
3.1 LoRa 6
3.1.1 Aufbau einesLoRaFrames 6
3.1.2 Abgrenzung zuLoRaWAN 6
3.1.3 Carrier Activity Detection 6
3.2 ALOHA 7
3.3 Listen before Talk / Polite Spectrum Access 7
3.4 Carrier Sense Multiple Access 7
3.4.1 CSMA 7
3.4.2 CSMA/CA 8
3.5 Round Trip Time des Transmission Control Protocol 8
3.6 ASAPLoRaBTModul 8
3.7 ASAP 9
3.7.1 ASAPJava 9
3.7.2 ASAPPeer 9
3.7.3 ASAPSession 9
3.7.4 ASAPAndroid 10
3.7.5 MacLayerEngine 10
3.8 Best-Effort Dienstgüte 10
3.9 Visitor Pattern 10
Inhaltsverzeichnis
3.10 Static Factory Method 10
3.11 AT-Befehle (eine Auswahl) 11
3.12 OpenSCAD 11
4 Methodologie 12
4.1 Ergebnisartefakte 12
4.2 Datenschutzaspekte 12
4.3 Ethische Aspekte 13
5 Nutzer- und Systemanforderungen 14
5.1 Funktionale Anforderungen 14
5.1.1 ... an das Modem 14
5.1.2 ... an die Firmware desASAPLoRaBTModul 14
5.1.3 ... an die Android-Komponente 15
5.2 Nicht-funktionale Anforderungen 15
6 Entwurf des ASAPLoRaBTModul 16
6.1 Auswahl der Hardware 16
6.1.1 Auswahl der Funktechnologie für den Langstreckenfunk zweier
Module 16
6.1.2 Auswahl der Technologie für die Nahbereichsverbindung zwi-
schen Modul und Android-Smartphone 16
6.1.3 Auswahl des Microcontroller für dasASAPLoRaBTModul 17
6.1.4 Auswahl der Stromversorgung 17
6.2 Schaltplan 18
6.3 Platinendesign 19
6.3.1 Revision 1 19
6.3.2 Revision 2 20
6.3.3 Revision 3 21
7 Message-Architektur 22
7.1 DSCVR 23
7.2 DVDCR 23
7.3 RCNCT[:<Adresse>] 24
7.4 MSSGE 24
7.5 IDEMP:<Token> 25
8 Softwarearchitektur der Firmware des ASAPLoRaBTModul 26
8.1 Programmumgebung 26
8.2 LoRaCommManager 26
8.2.1 LORA_CLOSED 27
8.2.2 LORA_IDLE 27
8.2.3 LORA_AWAITING_COMMAND_RESULT 27
8.2.5 LORA_AWAITING_MESSAGE_COMMAND_RESULT 27
8.2.6 LORA_AWAITING_MESSAGE_RESPONSE 28
8.3 Kollisionsbehandlung 29
9 Softwarearchitektur der Android-Komponente 31
9.1 LoRaEngine 32
9.2 AbstractASAPLoRaMessage 32
9.3 LoRaCommunicationManager 33
9.4 LoRaBTListenThread 33
9.5 LoRaBTInputOutputStream 33
9.5.1 LoRaBTInputStream / LoRaBTOutputStream 34
9.5.2 LoRaASAPInputStream / LoRaASAPOutputStream 34
10 Implementierung 36
10.1 ...der Firmware desASAPLoRaBTModul 36
10.1.1 setup() 36
10.1.2 loop() 38
10.2 ...der Android-Komponente 38
11 Test 40
11.1 JUnit Tests des ASAPLoRaBTModul 40
11.1.1 BasicCommunicationTest 40
11.1.2 SimultaneousCommunicationTest 41
11.2 JUnit Tests der Androidkomponente 42
11.2.1 AbstractASAPLoRaMessageFactoryTest 42
11.2.2 LoRaASAPInputStreamTest 42
11.2.3 LoRaBTInputOutputStreamTest 43
11.3 Integrationstests 43
11.3.1 Verbindungsaufbau 43
11.3.2 ASAPSession 44
11.3.3 Reichweitentest 44
12 Entwicklung des Gehäuses 46
13 Zusammenfassung und Bewertung der Ergebnisse 47
13.1 Vergleich zu ähnlichen Projekten 47
13.2 Limitationen und Ausblick 48
Quellenverzeichnis 50
A Appendix I
A.1 Abkürzungsverzeichnis / Glossar I
A.2 Quell-Code II
Abbildungsverzeichnis
0.1 Schematischer Aufbau der Kommunikationsstrecke i 0.2 Schematic structure of the transmission line ii
6.1 Schaltplan desASAPLoRaBTModul 18
6.2 Revision .01 derASAPLoRaBTModul-Platine 19
6.3 Revision .02 derASAPLoRaBTModul-Platine (Render des Gerberfile) 20
6.4 Revision .03 derASAPLoRaBTModul-Platine 21
7.1 Discovery eines anderenASAPLoRaBTModulund Versand einer Nachricht 25
8.1 Statusübergänge desLoRaCommManager 28
8.2 Screenshot ausSDRSharpmit der sichtbaren Kollision, rot markiert 29 9.1 Übersicht Klassenstruktur der Androidkomponente 31 9.2 Übersicht Klassenstruktur der Subtypen vonAbstractASAPLoRaMes-
sage 32
9.3 Interaktion des LoRaCommunicationManager mit dem LoRaBTIn-
putStream 34
9.4 Interaktion desLoRaCommunicationManagerund demLoRaASAPIn-
putStream 35
9.5 Interaktion derOutputStreams des LoRaBTInputOutputStream 35
11.1 JUnit Testlauf des BasicCommunicationTest 41
11.2 JUnit Testlauf des SimultaneousCommunicationTest 41 11.3 JUnit Testlauf des AbstractASAPLoRaMessageFactoryTest 42
11.4 JUnit Testlauf desLoRaASAPInputStreamTest 42
11.5 JUnit Testlauf desLoRaBTInputOutputStreamTest 43 11.6 Foto des ASAPLoRaBTModul mit grüner LED und der Ausgabe des
seriellen Monitors im StatusLORA_IDLE 44
11.7 Karte mit eingezeichneter Strecke des Reichweitentests, © luftlinie.org /
OpenStreetMap contributors 45
12.1 Foto der 3D-gedruckten Halbschalen des Gehäuses und der einzusetzen-
den Hardware 46
Tabellenverzeichnis
3.1 Relevante AT-Befehle des HIMO01P Modems 11
10.1 Farbcodes der Status-LED 37
Listings
10.1 Unterbrechen des read()-Aufrufs eines LoRaASAPInputStream . . . . 39 10.2 Benachrichtigen eines wartendenread()-Aufrufs . . . 39
1.1 Hintergrund der Arbeit
Im Schwerpunkt mobile Anwendungen des Fachbereich 4 der HTW Berlin sind unter der Leitung von Professor Dr.-Ing. Thomas Schwotzer diverse dezentrale Anwendun- gen für Android auf Grundlage des von ihm entwickelten Layer-3 Routing-Protokoll AsynchronousSemanticAd-hocProtocolbeziehungsweise der Service-Implementation für AndroidASAPAndroidentstanden. Als Beispiel sei hier SharkNet21genannt.
Für die Kommunikation mitASAPist eine Punkt-zu-Punkt Verbindung erforderlich.
Dies ist auf verschiedene Arten möglich, unter anderem durch den Aufbau von AdHoc- Netzen mit Bluetooth oder WiFiDirect. In dieser Arbeit soll mit LoRa eine weitere Möglichkeit für das Herstellen einer infrastruktorlosen Punkt-zu-Punkt Verbindung im ASAPAndroid-Projekt präsentiert werden.
Möchte man eine ASAP-Umgebung aus einem der vielen Gründe2 ohne die Nut- zung bestehender Infrastruktur aufbauen, kann eine größere Reichweite dies erleich- tern. Bereits die Erweiterung in den einstelligen Kilometerbereich bewirkt durch die asynchrone Natur desASAP-Protokolls selbst bei kleinen Gruppengrößen eine hohe Flächenabdeckung.
1https://github.com/SharedKnowledge/SharkNet2Android/wiki
2beispielsweise Kosten der Nutzung oder Bereitstellung (insbesondere bei geringen Datenmengen), Zuverlässigkeit im Katastrophenfall oder Zensur in autoritären Staaten
1. Einleitung
1.2 Problem- und Zielstellung
Kern der Zielstellung ist die Entwicklung einer Management-Komponente für Langstre- ckenfunk imASAPAndroidProjekt3, welches einen Android Service bereitstellt, um die ASAPauf Android-Smartphones laufen zu lassen. Da gängige Android Smartphones neben den infrastrukturabhängigen GSM-Modems4keine Langstreckenfunkeinheiten bieten, muss die Anbindung an ein externes Modem realisiert werden. Um Kommuni- kationskanäle aufzubauen, ist es erforderlich, alle in Reichweite befindlichen (aktiven) Modems erkennen zu können. Hierzu muss ein Discovery-Verfahren entwickelt werden.
Die Kommunikation inASAPist streambasiert und wird in der Java-Implementation über Input/OutputStreams abgebildet[33] - hieraus ergibt sich die Teilproblematik die Funkkommunikation, welche als OSI-Layer-2 inhärent blockbasiert ist, für die darüber liegende Anwendung transparent in einzelne Datagramme aufzuteilen. Hierbei ist zu beachten, dass die Reihenfolge dieser Datagramme relevant ist. Für diese Arbeit soll ein Best-Effort Ansatz ausreichend sein; die tatsächliche Sicherung der Übertragung bleibt der nicht behandelten Transportschicht überlassen.
Ebenfalls aus dem Vorgehen der Nachrichtenverwaltung als Streams ergibt sich die Teilproblematik, dass Nachrichten welche über Langstreckenfunk empfangen werden dem jeweiligen logischen Stream inASAPzugeordnet werden müssen. Hierzu muss der Verbindungskanal zum externen Funkmodul in je zwei weitere Streams (1x Input- Stream, 1x OutputStream) pro verbundenem Teilnehmer aufgeteilt werden.
Um Teilnehmer zu identifizieren und zu adressieren müssen diese eindeutige Hardware- Adressen zugeteilt bekommen. Bei den imASAPAndroid-Projekt zuvor implementierten Funktechnologien übernimmt die vom Hersteller vergebene Hardware-Adresse des Modems diese Aufgabe; hierzu muss ein Äquivalent geschaffen werden.
3https://github.com/SharedKnowledge/ASAPAndroid
4und deren Nachfolgetechnologien UMTS/LTE/5G
1.3 Aufbau der Arbeit
Zunächst wird ein Modem für die Langstrecken-Funkübertragung und eine geeignete Ansteuerungselektronik gewählt. Hierzu passend wird eine geeignete Kommunikati- onstechnologie für den Nahbereich zwischen Android-Smartphone und Funkmodem gewählt.
Die gewählten Technologien und ihre Hardware-Implementationen werden zusammen mit einer Stromversorgung auf einem zu entwerfenden Printed Circuit Board (PCB) platziert. Gemeinsam bildet dies die Entwicklungsumgebung für den weiteren Prozess.
Für die Vermittlung der Kommunikation zwischen Android-Smartphone und Funk- modul entsteht eine Software, die das Senden über Langstreckenfunk kontrolliert.
Insbesondere hat diese Software die Aufgabe der Vermittlung der Kommunikation über ein gemeinsames Medium.
Im letzten Schritt entsteht die Android-Komponente, welche die entstandene Soft- ware an dasASAPAndroid-Projekt anbindet. Für diese - beziehungsweise die testbaren Unterkomponenten - werden Tests entwickelt, anhand welcher die Funktionalität, wie im vorherigen Abschnitt beschrieben, entwickelt und getestet wird.
Final erfolgen Tests mit der bestehenden Beispielanwendung desASAPAndroidProjekts.
2. Vergleichbare Projekte
2.1 LoRaHAM
Auf Basis des Adafruit Feather M01hat ein Team um den GitHub-Nutzertravisgoodspeed ein LoRa Mesh Netz im 70cm-Band unter dem Namen LoRaHAM2 entwickelt. Das 70cm-Band ist ein international für Amateurfunkanwendungen reserviertes Funkband von 430 MHz bis 440 MHz. [14]
Das LoRaHAM Projekt kennt drei Typen von Peers. Ein Beaconist ein Peer, welcher als Datenquelle ausschließlich Nachrichten im Simplexbetrieb sendet.Terminalssind LoRaHAM-Stationen, die sowohl Sender als auch Empfänger (beispielsweise der Daten einesBeacon) sein können. Identifiziert werden diese über ihr in der Firmware verge- benes Callsign.3Zuletzt Gateways, genanntDigipeater, die, entweder über ein anderes Medium oder erneut über das LoRa Modem,Beacon-Pakete weiterleiten. [16]
2.2 Meshtastic
Das ProjektMeshtasticbildet LoRa Meshnetzwerke für Chatgruppen mit einem floo- dingbasierten Multi-Hop System. [8]
Zur Teilnahme installieren Nutzer eine Android-App und verbinden sich via Bluetooth mit einem von drei verschiedenen Funkmodulen. Mit dieser App kann ein Nutzer einer Gruppe beitreten. Nachrichten in einer Gruppe werden von denMeshtasticFunkmodu- len weitergeleitet, auch wenn die App auf dem Smartphone nicht aktiv ist. Hierdurch ist eine Erreichbarkeit der beiden entferntesten Nutzer einer Gruppe mit durchgehender Verbindung möglich. [9]
1https://www.adafruit.com/product/3179
2Das 70cm-Band wird in den USA auch als HAM-Radio band bezeichnet
3im deutschen "Rufzeichen", bezeichnet einen eindeutigen Kenner einer Funkstation
2.3 CellSol
CellSol ist eine Chatplattform die eine routingfreie, also floodingbasierte, Meshkom- munikation ermöglicht. Sie besteht aus sogenanntenPylons, welche entweder mobil als persönliche Ausrüstung getragen oder statisch als Infrastrukturknoten positioniert werden. [22]
Aktuell existieren im Projekt zwei Typen vonPylons: einerseits derWiFi Pylon(auch pocket pylon), welcher als persönlicher Knoten gedacht ist; andererseits der Repeater Py- lon(auchfixed pylon), welcher als Infrastrukturknoten gedacht ist. Die Hardwaredesigns unterscheiden sich in Stromverbrauch und bereitgestellten Services (Repeater Pylons können nicht ohne zusätzlichenWiFi Pylongenutzt werden, da sie kein Nutzerinterface bereitstellen), sind sonst aber austauschbar. Die Stromversorgung ist so gestaltet, dass ein Solarpanel mit Pufferbatterie ohne zusätzliche Elektronik genutzt werden kann. [23]
3. Grundlagen
3.1 LoRa
LoRa- beziehungsweise derLoRaPhysical LayerLoRaPHY- ist ein proprietäres Funk- protokoll, welches auf Frequenzspreizungsmodulation basiert. Hierbei werden Up/- Downchirps in einer Bandbreite von bis zu 500kHz durch Veränderung der Frequenz moduliert. Als OSI-Layer-2 Protokoll ist es framebasiert und verbindungslos. Der Medien-Zugriff erfolgt konkurrierend. [2]
3.1.1 Aufbau einesLoRaFrames
EinLoRaFrame beginnt mit einer Präambel: eine Folge von Upchirps beliebiger Länge, die mit 2.25 Downchirps beendet wird. Dies stellt den Synchronisationsteil desLoRa Frames dar. [19] Auf die Präambel folgt ein optionaler Header, CRC-Informationen zur Fehlerkorrektur und schließlich die Payload, welche bis zu 255 Byte groß ist. [2]
3.1.2 Abgrenzung zuLoRaWAN
Wenn in dieser Arbeit vonLoRaoderLoRaPHYgesprochen wird, meint dies den Physical Layer desLoRa-Protokolls, nicht das LoRaWANNetzwerk, welches darüberliegende OSI-Layer 3 mit verschiedenen Geräteklassen definiert. [20, 5]
3.1.3 Carrier Activity Detection
Carrier Activity Detection (CAD) ist ein Teil desLoRaPHYProtokolls, der dazu dient die Präambel einesLoRaFrames zu erkennen. Da LoRa Frames auch bei Signalstärken unterhalb des Grundrauschens empfangen werden können, ist es nicht ausreichend exklusiv auf die gemessene Signalstärke eines Kanals zu prüfen, um zu evaluieren, ob dieser belegt ist. CAD prüft hierzu ob aktuell eine Präambel übertragen wird.
Ist das der Fall, meldet das LoRa Modem dies und kann in den Empfangsmodus wechseln. Die Dauer der CAD hängt von den konfigurierten Sendeparametern ab (32/Brandbreite+2SF/BandbreiteSekunden) und darf für die Kollisionsvermeidung nicht außer Acht gelassen werden. [5]
3.2 ALOHA
ALOHA ist eine bekannte Strategie für den Medienzugriff bei einem geteilten Über- tragungsmedium, wie es in dieser Arbeit der Fall ist. Bei ALOHA sendet ein Kommu- nikationspartner ohne vorherige Prüfung und wartet auf eine Bestätigungsnachricht des Empfangs seines Datenpakets. Bleibt diese aus, geht der Kommunikationspartner von einer Kollision auf dem geteilten Medium aus und erhöht seine Backoff-Zeit um einen zufälligen Wert. Der andere Kommunikationspartner, sofern dieser ebenfalls nach dem ALOHA Prinzip sendet, tut dasselbe. Sofern sich die Backoff-Zeit um mindestens die Dauer der Übertragung (Time on Air) unterschieden hat, ist bei dem folgenden Sendeversuch keine Kollision zu erwarten. [1]
3.3 Listen before Talk / Polite Spectrum Access
Listen before Talk, auch Polite Spectrum Access genannt, ist ein Überbegriff für Zu- griffsstrategien auf ein geteiltes Medium, bei denen vor dem Versenden eines Datenpa- kets zunächst die Kanalfreiheit geprüft wird. Dies kann durch verschiedene Verfahren1 erfolgen, welche als Clear Channel Assessment (CCA) bezeichnet werden. [40]
Für LoRa erfüllt die CAD die Funktion des CCA, wie in Unterabschnitt 3.1.3: Car- rier Activity Detectionbeschrieben.
3.4 Carrier Sense Multiple Access 3.4.1 CSMA
Carrier Sense Multiple Access (CSMA) ist eine alternative Strategie für den geteilten Medienzugriff. Ähnlich wie bei Abschnitt 3.2: ALOHA sollen so Kollisionen durch (zufälliges) erhöhen der Backoff-Zeit nach Erkennung einer Kollision aufgelöst werden.
Zusätzlich wird durch vorherige Prüfung, ob der zu belegende Kanal bereits belegt ist (CCA), eine bevorstehende Kollision erkannt. Es gibt drei Arten von CSMA - die Strategien unterscheiden sich durch den Zeitpunkt der Kollisionsprüfung oder des CCA: kontinuierlich, in Zeitscheiben oder durch eine Kombination aus kontinuierlicher Prüfung und zufälliger Wartezeiten. [25, 36]
Da für die Nutzung von Zeitscheiben eine gemeinsame Uhr notwendig ist, sind für diese Arbeit nur die Varianten mit kontinuierlicher Prüfung relevant.
1wie die oben genannte Methode, die aktuelle Signalstärke auf dem Kanal zu messen
3. Grundlagen
3.4.2 CSMA/CA
Da in Funknetzwerken eine Kollision nur durch das Ausbleiben einer Bestätigungsnach- richt erkannt werden kann, ist es möglich durch Warten eines bestimmten Zeitraums, genannt Interframe Space, und dann erneuter Prüfung auf Kanalfreiheit, eine Verringe- rung der Anzahl an Kollisionen erreicht werden. Dieses Verfahren wird Carrier Sense Multiple Access / Collision Avoidance (CSMA/CA) genannt. [25]
Wie in Unterabschnitt 3.1.3: Carrier Activity Detectionbeschrieben, ist es möglich mit LoRa zu prüfen, ob das gemeinsame Medium zum aktuellen Zeitpunkt frei ist. Damit ist CSMA/CA zumindest theoretisch ein mögliches Verfahren für die Kommunikation viaLoRa. [21]
3.5 Round Trip Time des Transmission Control Protocol
Die Round Trip Time (RTT) des Transmission Control Protocol (TCP) ist nach dem ursprünglichen RFC 793 [17] derDARPAdie Zeit zwischen Senden eines Datagramms und dem Empfang einer Bestätigungsnachricht für dieses Datagramm. Das Wissen um diese Zeit wird genutzt, um die Frist für den Empfang der Bestätigungsnachricht und damit den Zeitpunkt des erneuten Sendens des Datagramms zu bestimmen (Retrans- mission Timeout).
Damit in der Approximation der realen durchschnittlichen RTT einzelne Ausreißer der gemessenen RTT den Retransmission Timeout nicht zu sehr beeinflussen, wird die Smoothed Round Trip Time (SRTT) gebildet. Diese gewichtet die aktuelle Messung der RTT gegenüber der bisher gebildeten SRTT über den Faktorα:
SRTT = (α∗SRTT) + ((1−α)∗RTT)
Der Retransmission Timeout (RTO) berechnet sich daraus abgeleitet aus einer unte- ren/oberen Schranke (LBOUND / UBOUND) und einem Zufallsanteilβ:
RTO =min[LBOUND,max[LBOUND,(SRTT∗β)]]
Die RFC793 gibt fürαeinen Wert von 0,8 bis 0,9 an, fürβ1,3 bis 2,0.
3.6 ASAPLoRaBTModul
AlsASAPLoRaBTModul, vorhergehend als Funkmodul bezeichnet, wird im Rahmen dieser Arbeit die notwendige Hardware für die Bereitstellung des Langstreckenfunks für Smartphones verstanden, deren Zusammensetzung in Abschnitt 6.1: Auswahl der Hardwarebeschrieben wird.
3.7 ASAP
Asynchronous SemanticAd-hoc Protocol ist ein OSI-Layer-3 Routingprotokoll, welches von unzuverlässigen, nicht dauerhaft bestehenden und unter Umständen nur sehr kurzzeitigen Verbindungen ausgeht.ASAPeignet sich besonders für adhoc-Netzwerke, funktioniert aber auch in Infrastrukturnetzen. [29]
Als grundlegendes Prinzip besteht eineASAP-Umgebung aus mehreren Teilnehmern, welche untereinander Punkt-zu-Punkt Kommunikationskanäle aufbauen und darüber Nachrichten austauschen können. [27] Dabei wird nicht davon ausgegangen, dass diese Kommunikationskanäle dauerhaft oder zuverlässig bestehen. Ein angeforderter Nach- richtenaustausch erfolgt sobald möglich; das kann (bei aktivem Kommunikationskanal) sofort oder bei der nächsten Begegnung in Reichweite zueinander sein. [30]
Eine umfassende Beschreibung des ASAP-Protokolls ist im Rahmen dieser Arbeit nicht leistbar, daher folgen hier nur einige im Weiteren relevante Begriffsbestimmungen.
Dem interessierten Leser seien das ASAPJava Wiki2und die Projektwebsite3empfohlen.
3.7.1 ASAPJava
ASAPJava ist die Java-Implementierung des ASAPProtokolls. Als Implementierung eines OSI-Layer-3 Protokoll stelltASAPJavakeine OSI-Layer-2 Funktionalitäten bereit.
Diese werden von anderen Komponenten, genanntPlatform Support, implementiert. [29]
3.7.2 ASAPPeer
EinASAPPeerist die Repräsentation eines Teilnehmers inASAPJavaund stellt Funk- tionalitäten zum Empfang und Senden von Nachrichten bereit. Nachrichten werden asynchron ausgetauscht, d. h. das Senden einer Nachricht ist nicht gleichbedeutend mit der tatsächlichen Übertragung zu einem entferntenASAPPeer. Dies kann zu einem späteren Zeitpunkt erfolgen. [31]
3.7.3 ASAPSession
EineASAPSessionist die Herstellung einer Punkt-zu-Punkt Verbindung zweier ASAP- Peers (auchASAPEncounter). EinASAPPeerwird durch Übergabe je eines Input/Output- Streams einer hergestellten Punkt-zu-Punkt Verbindung zum Beginn einerASAPSession aufgefordert und beginnt den tatsächlichen Austausch von Nachrichten, welche durch dieASAPPeers gesendet wurden. EineASAPSessionendet mit Abbruch der Punkt-zu- Punkt Verbindung. [28]
2https://github.com/SharedKnowledge/ASAPJava/wiki
3http://www.sharksystem.net/
3. Grundlagen
3.7.4 ASAPAndroid
ASAPAndroidbezeichnet denPlatform SupportvonASAPJavafür Android. [26]
3.7.5 MacLayerEngine
Klassen zur Bereitstellung von Punkt-zu-Punkt Verbindungen, die topologisch die Sicherungsschicht fürASAPdarstellen, werden inASAPAndroidvon der KlasseMacLaye- rEngineabgeleitet. DieMacLayerEngineverwaltet die Verbindungsaufnahme zwischen entferntem und lokalem ASAPPeer. Wird ein neuerASAPPeer erkannt, prüft sie die Notwendigkeit der Verbindungsaufnahme gegen eine Liste der bestehendenASAPSes- sions und löst gegebenenfalls diese durch Übergabe der zur Verbindung gehörenden Input- und OutputStreams aus. [34]
3.8 Best-Effort Dienstgüte
Die Angabe einer Best-Effort Dienstgüte ist eine in der Netzwerktechnik gängige Dienst- güteklasse (d. h. einer Sammlung an Aussagen über die Qualität bestimmter Parameter eines Dienstes, wie z.B. Fehlerrate, Geschwindigkeit oder Stabilität), bei der keine oder nur partielle Garantien gegeben werden. [35]
Im Rahmen dieser Arbeit, in Zusammenhang mit dem Transport überLoRa, bezieht sich die Angabe einer Best-Effort Dienstgüte auf die Fehlerrate bei der Übertragung vonASAPPeerzuASAPPeerwährend einerASAPSession.
3.9 Visitor Pattern
Das Visitor Pattern ist ein Entwurfsmuster, das dazu dient, in einer Gruppe von ähnli- chen Objekten ähnliche Aufgaben durchzuführen, ohne große Konditionalstrukturen über die Objekttypen zu nutzen. Hierzu implementieren die Objekttypen eine Methode, die die agierende Klasse (den Besucher) übergeben bekommt. Diese Methode löst die für den Objekttyp passenden Operationen aus. [15]
3.10 Static Factory Method
Static Factory Method ist ein Entwurfsmuster zum Ersatz des Konstruktors einer Klasse. Hierbei wird der Klasse eine statische Methode hinzugefügt, welche diese instantiiert (beziehungsweise instantiieren kann, vgl. Singleton Pattern). Gegenüber einem Konstruktor hat dies den Vorteil, dass auch Subtypen der Klasse instantiiert und zurückgegeben werden können. Im Vergleich zum Factory Method Entwurfsmuster stellt eine Klasse seine eigene Factory dar; der Unterschied findet sich somit im Wegfall einer zusätzlichen Factory-Klasse. [4, 10]
3.11 AT-Befehle (eine Auswahl)
Der AT-Befehlssatz ist ein verbreitetes Steuerprotokoll für Modems und vergleichbare Technologien, welche über eine serielle Schnittstelle kommunizieren. Befehle und Be- fehlsresultate beginnen mit der Zeichenkette AT, gefolgt von einem Trennzeichen und dem Kenner des auszuführenden Befehls. [39]
Im Rahmen dieser Arbeit werden folgende Befehle, jeweils terminiert mit einem Newline-Character, relevant: [38]
Tabelle 3.1.:Relevante AT-Befehle des HIMO01P Modems
Befehl Antwort Beschreibung
AT+RX AT,OK Setzt das Modem in Empfangszustand
AT+CFG=XXX AT,OK Konfiguriert das Modem
AT+ADDR=XXXX AT,OK Setzt die lokale Adresse des Modems AT+ADDREN=1 AT,OK Aktiviert das Filtern eingehender Pakete auf
die lokale Adresse
AT+DEST=XXXX AT,OK Setzt die Zieladresse der Übertragungen AT+SEND=XXX AT,OK Startet das Senden eines XXX byte Paket XXXXXXXX AT,SENDING Nach Übertragen von XXX byte startet das
Modem das Senden
- AT,SENDED Bestätigt den erfolgten Versand
- LR,XXXX,XX,... Eingehende Pakete beginnen mit LR, gefolgt von der entfernten Adresse XXXX und der Länge der folgenden Daten als Hexadezimal- zahl XX. Anschließend folgen die Daten.
3.12 OpenSCAD
OpenSCADist eine freie Software4 zum Erstellen von 3D-Modellen mit Fokus auf tech- nische Zeichnung. Im Gegensatz zu traditionellen CAD5-Programmen bietetOpenSCAD keine Zeichenoberfläche, sondern wird über eine Skriptsprache gesteuert. Über diese können 3D-Körper definiert und transformiert oder 2D-Geometrien extrudiert werden.
Dies erleichtert das Arbeiten mit parametrisierten Designstrategien. [24]
4Im Sinne der GNU GPLv2:http://www.gnu.org/licenses/old-licenses/gpl-2.0.html
5Hier: Computer Aided Design.
4. Methodologie
4.1 Ergebnisartefakte
Als Ergebnis dieser Arbeit sollen drei Artefakte entstehen:
• Ein Prototyp (ASAPLoRaBTModul) einer bestückten Platine mit – einem Modem für Langstreckenfunk,
– einer Verbindungsmöglichkeit zu einem Android-Smartphone, – einem Akkumulator und einer Ladeelektronik.
• Die Firmware für das zuvor genannteASAPLoRaBTModul.
• Eine Android-Komponente für die Verwaltung der Verbindung über dasASAPLoRaBTModul.
Zusätzlich soll ein 3D-druckbares OpenSCAD-Modell einer Einhausung für das ASAPLoRaBTModulentstehen.
4.2 Datenschutzaspekte
Die zum derzeitigen Stand imASAPAndroid-Projekt implementierten MacLayerEngi- neshaben beide eine Form der Autorisierung und Verschlüsselung der Kommunikation.
WiFi-Direct unter Android nutzt WPS Push Button Connect um eine WPA2-Verbindung auszuhandeln. [11] Dies stellt die Autorisierung des Verbindungsaufbaus sicher, da nur nach manueller Bestätigung auf dem Gerät ein Verbindungsaufbau möglich ist. [25]
Für die Bluetoothkommunikation ist in jedem Fall vorab ein Pairing unter mindestens 2 Geräten notwendig. Dieses erfolgt ebenfalls nur nach manueller Bestätigung durch den Nutzer und handelt entweder über das Numeric Comparison Protocol oder das Just Works Protocol ein gemeinsames Geheimnis aus, das fortan für verschlüsselte Kommunikation1verwendet werden kann. [25]
Im Gegensatz hierzu erfolgt der Verbindungsaufbau in der geplanten Langstreckenfunk- komponente ohne vorherige Autorisierung oder Verschlüsselung der Kommunikation.
Durch Ableiten der Sendeparameter (oder durch Ausprobieren aller Kombinationen) ist es möglich, die gesendeten Daten zu demodulieren und im Klartext mitzulesen. [19]
1für jedes übertragene Paket wird ein eigener Schlüssel aus dem gemeinsamen Geheimnis und weiteren Parametern generiert
Die Transportverschlüsselung bleibt damit Aufgabe der Anwendungsschicht. Dies muss vor dem Entwickeln einer potentiell datenschutzkritischen Anwendung fürASAPAn- droidbedacht werden.
4.3 Ethische Aspekte
In einem infrastrukturlosen Netzwerk, wie im Rahmen dieser Arbeit beschrieben, mit geringen Einstiegshürden, liegt die Frage nach dem Eindämmen von Teilnehmern dieses Netzwerks mit bösen Absichten nahe. Ein solches Netzwerk kann nicht, oder nur sehr schwer, reguliert werden, da es im Vergleich z. B. zu Mobilfunk- oder Internetpro- vidern weder Autorisierung noch Authentifizierung erfordert, um einen Netzzugang zu erhalten.
Während sich in Adhocnetzwerken, die Funktechnologien im relativen Nahbereich verwenden, das Schadenspotential hauptsächlich auf diesen beschränkt, vergrößert die höhere Reichweite die Netzabdeckung und damit auch das Schadenspotential expo- nentiell - sowohl für das Netzwerk an sich, man denke an klassische Netzwerkattacken wie Flooding, als auch die Auswirkung einer bösartigen Verwendung2 des Netzes.
In Verbindung des in dieser Arbeit entstehenden Netzzugangs mit hoher Reichweite und der entstandenen Gruppenschlüsselverwaltung fürASAP3 könnte zum Beispiel ein stadtweites verschlüsseltes soziales Netz entstehen, in dem Regularien wie das NetzDG4 praktisch nicht umsetzbar wären. Zudem lassen solche Regularien oft Dienste in in- frastrukturlosen Netzen völlig außer Acht, bei denen die Frage, wer Diensteanbieter5 ist oder ob ein solches Netz unter die Regularien fällt6, sich nicht immer offensichtlich und/oder eindeutig klären lässt.
Solche Regulierungslücken oder potentielle Haftungsfragen sollten vor Entwicklung einer Anwendung mit ASAPüber LoRa bedacht werden, können hier aber nicht er- schöpfend diskutiert werden.
2Für die an dieser Stelle aus offensichtlichen Gründen keine Beispiele genannt werden.
3siehe „Entwicklung eines Protokolls zur Erzeugung von Gruppenschlüssel in Ad-Hoc-Netzwerken“ [37]
4Gesetz zur Verbesserung der Rechtsdurchsetzung in sozialen Netzwerken (Netzwerkdurchsetzungsge- setz - NetzDG):https://www.gesetze-im-internet.de/netzdg/BJNR335210017.html
5Oder: Diensteanbieter mit Gewinnerzielungsabsicht i.S.d. NetzDG
6Das NetzDG wird für „Plattformen im Internet“ ab 2 Mio. registrierter Nutzer angewendet - Nutzer in einem pseudonymen oder anonymen, dezentralen Netz zu zählen scheint jedoch schwer bis unmöglich.
5. Nutzer- und Systemanforderungen
5.1 Funktionale Anforderungen 5.1.1 ... an das Modem
Um das Ziel der erhöhten praktischen Nutzbarkeit durch höhere Abdeckung zu errei- chen, muss die Reichweite der Funktechnologie größer als die Reichweiten bisheriger implementierter Funktechnologien (WiFi-Direct und Bluetooth) sein. Für diese Arbeit soll eine Reichweite im einstelligen Kilometerbereich ausreichend sein.
Einzelne Module sollen über ihre Hardware-Adresse identifizierbar sein.
Des Weiteren soll der Funk in einem Funkband stattfinden, in dem keine Einzel- genehmigung oder Frequenzzuteilung notwendig ist. Der Bandzugriff sollte nicht durch Regularien zeitlich beschränkt sein.
Zuletzt muss das Modem in einem möglichst geringen Kostenrahmen und ausrei- chender Stückzahl verfügbar sein.
5.1.2 ... an die Firmware desASAPLoRaBTModul
Die Firmware für das ASAPLoRaBTModul ist verantwortlich für die Steuerung der Funkkommunikation. Diese muss auf der geteilten - und damit nur im Wechselbetrieb nutzbaren - physischen Schicht nach einer Best-Effort Dienstgüte koordiniert werden.
Hierzu muss die Reihenfolge und Idempotenz aller Datagramme sichergestellt werden.
Nicht gesichert wird die Übertragung generell.
Außerdem muss dasASAPLoRaBTModulandereASAPLoRaBTModule in Funkreichweite erkennen können. Es ist ausreichend, wenn diese Erkennung auf Anforderung der Androidkomponente per Rundruf erfolgt.
5.1.3 ... an die Android-Komponente
Die Android-Komponente stellt die Verbindung zwischen ASAPLoRaBTModul und ASAPPeer her. Sie muss Nachrichten des ASAPPeers entgegennehmen, adressieren und an das ASAPLoRaBTModul zur Bearbeitung senden. Dies muss in separierten Datenpaketen geschehen.
Datenpakete, welche von einemASAPPeerzumASAPLoRaBTModulübergeben werden, müssen in ein zu entwickelndes Protokoll eingebettet werden. Gegebenenfalls muss eine Transportenkodierung der Nutzdaten erfolgen.
In Gegenrichtung, vonASAPLoRaBTModulzuASAPPeer, muss auf ankommende Nach- richten gewartet werden. Diese müssen gelesen, gegebenenfalls dekodiert und dann in den zur entfernten Hardware-Adresse gehörenden Stream geschrieben werden. So wird erreicht, dass die Nutzlast der passendenASAPSessionüberstellt wird.
Außerdem ist die Android-Komponente für das periodische Auslösen eines Rundrufs nach (unbekannten) weiterenASAPPeers über dasASAPLoRaBTModulverantwortlich.
Zu neu entdecktenASAPPeers wird der Aufbau einerASAPSessionausgelöst. Vormals verbundene entfernteASAPPeers werden aus der Liste der offenen Verbindungen ent- fernt, wenn diese wiederholt nicht durch den Rundruf entdeckt werden können.
5.2 Nicht-funktionale Anforderungen
Für die Entwicklung der Android-Komponente existiert die nicht-funktionale Anfor- derung, die Umsetzung möge ausschließlich mit Standard-Bibliotheken erfolgen, um Lizenzproblematiken und externe Abhängigkeiten desASAP-Projekts zu vermeiden.
6. Entwurf des ASAPLoRaBTModul
6.1 Auswahl der Hardware
6.1.1 Auswahl der Funktechnologie für den Langstreckenfunk zweier Module In Deutschland reguliert die Bundesnetzagentur im Frequenzplan die Nutzung der verfügbaren Funkbänder. Aus den funktionalen Anforderungen an das Funkband ergibt sich die Wahl einer Frequenz, deren Nutzung im Rahmen einer Allgemeinzuteilung bereits gestattet ist. InAllgemeinzuteilung von Frequenzen zur Nutzung durch Funkanwen- dungen geringer Reichweite (SRD)[6] erfolgt eine Frequenzzuteilung „[...] zur Nutzung durch die Allgemeinheit für Funkanwendungen (Geräte) geringer Reichweite [...]“, un- ter anderem für den Frequenzbereich von 433,050 MHz bis 434,790 MHz. Das Band von 434,040 MHz bis 434,790 MHz ist für die Nutzung von Datenfunk bei einer maximalen effektiven Strahlungsleistung von 10 mW und einer maximalen belegten Bandbreite von 25 kHz ohne Beschränkung des Tastgrads1in ganz Europa, vorbehaltlich regionaler Regulierung, zur Nutzung freigegeben. [7, 13]
Für die Datenübertragung in diesem Frequenzbereich bietet sich das Transceivermodul SX1278 der Firma SEMTECH an. Dieses kann auf die zuvor genannten Parameter beschränkt werden. [32]
Als Hardware-Package wird der im Fachbereich bereits genutzteHIMO-01Pder Firma Widora gewählt. Bei Nutzung der proprietärenLoRaPHYModulation wird eine Reich- weite von bis zu 10km angegeben. Zu beachten ist, dass die Nutzdatenlänge bei dieser auf 250 Byte beschränkt ist. Die funktionale Anforderung der Hardware-Adresse kann durch eine einmalige, eindeutige Zuteilung in der Firmware desASAPLoRaBTModul erfüllt werden. [38]
6.1.2 Auswahl der Technologie für die Nahbereichsverbindung zwischen Modul und Android-Smartphone
Als gängige Verbindungstechnologien stehen bei typischen modernen Smartphones Bluetooth, WLAN/802.11 und USB zur Verfügung. Von einer kabelgebundenen Verbin- dung über USB wird aus Gründen der Praktikabilität abgesehen.
1d.h. der gemittelten zeitlichen Belegung des Mediums
Gegen die Verbindung über WLAN/802.11 beziehungsweise WiFi-Direct spricht, dass derzeit nur eine einzelne Verbindung zu einem Zeitpunkt aufrechterhalten werden kann. Anwender könnten somit dasASAPLoRaBTModulund beispielsweise einen Inter- netzugang via WLAN nicht parallel nutzen.
Damit fällt die Wahl auf Bluetooth als Verbindungstechnologie für den Nahbereich zwischenASAPLoRaBTModulund Android-Smartphone.
6.1.3 Auswahl des Microcontroller für dasASAPLoRaBTModul
Um das Modem anzusteuern, wird eine serielle Schnittstelle benötigt.[38] Zusätzlich ist eine weitere serielle Schnittstelle wünschenswert, um eine Fehlerprotokollierung zu ermöglichen. Um den Microcontroller mit dem Smartphone zu verbinden, soll eine Bluetoothschnittstelle genutzt werden.
Der ESP32 von Espressif bietet sowohl ein Bluetoothmodul als auch drei UART- Schnittstellen. [12] In der gewählten Ausführung alsWemos D1 Mini ESP32-WROOM-32 wird eine UART Schnittstelle über eineCP2104 USB to UART bridge vonSilicon Labs bereitgestellt, was das Verbinden zum Programmieren des Microcontrollers oder Ausle- sen der Fehlerprotokollierung erleichtert. [3]
Es wurde erwogen und getestet anstatt eines separaten Microcontrollers einen Blue- tooth zu UART Adapter2zu verwenden. Dies wurde zugunsten der höheren Flexibilität der im folgenden beschriebenen Firmware verworfen.
6.1.4 Auswahl der Stromversorgung
Die Stromversorgung wird über eine Lithium Ionen Zelle realisiert. Solche Zellen dür- fen nicht direkt an einen Verbraucher angeschlossen werden, sondern benötigen eine Schutzbeschaltung gegen Tiefentladung, ein Battery Management System (BMS). Für diese Aufgabe wurde der für Prototypanwendungen hinlänglich bekannte TP4056-Chip auf einem Breakout-Board verwendet, da dieser zusätzlich eine Ladeelektronik für die LiIon-Zelle bereitstellt.
2Getestet wurde dasHC-06 Bluetooth Wireless RF Transceiver Module.
6. Entwurf des ASAPLoRaBTModul
6.2 Schaltplan
Mithilfe des ProgrammsEasyEDAwurden zunächst alle inAbschnitt 6.1: Auswahl der Hardwaregewählten Komponenten auf einem Schaltplan platziert und je ein +5V und ein GND Netz an den Ausgängen des TP4056 begonnen. Zwischen GND-Out des TP4056und dem GND-Netz wurde ein Header für einen Ein-/Aus-Schalter platziert.
Die Netze wurden ebenfalls an den Pins für die Stromversorgung der Komponenten angeschlossen. An die Inputs desTP4056wurde ein18650LiIon-Akkumulator ange- schlossen.
RX und TX von UART2 des ESP32 (Pin 16 und 17) wurden mit TX und RX des HIMO-01P(Pin 12 und 11) verbunden.
Zusätzlich zu den bereits genannten Komponenten wurde ein Header zum Anschluss einerWS2812B-LED geschaffen. Dieser wurde an die +5V und GND-Netze angeschlos- sen. Der Datenpin wurde über eine Diode an Pin 18 desESP32verbunden. Durch das Parallelschalten der +5V-Versorgung über einen Widerstand wird die 3,3V-LVTTL des ESP32 auf 5V-TTL Spannung der WS2812B-LED gehoben. Die Diode verhindert ein Rückfließen des Stroms und damit die Zerstörung desESP32.
Abbildung 6.1.:Schaltplan des ASAPLoRaBTModul
6.3 Platinendesign 6.3.1 Revision 1
Für das Platinendesign wurden alle Komponenten entsprechend des Schaltplans plat- ziert und mit Traces verbunden. Für Traces, die das +5V Netz mit VIN-Pins einer Komponente verbinden, wurde 1 mm Breite gewählt; für solche, die mehr als eine Komponente mit einer Stromversorgung verbinden, wurde die Breite auf 1.6 mm er- höht. Alle Traces wurden in Winkeln, die nicht größer als 45° zueinander gebeugt sind, gesetzt. Für das GND-Netz wurde eine Ground Plane als Copper Area auf der Oberseite des PCB platziert.
Anschließend wurden Gerber-Files generiert und ein Prototyp in Auftrag gegeben.
Abbildung 6.2.:Revision .01 der ASAPLoRaBTModul-Platine
6. Entwurf des ASAPLoRaBTModul
6.3.2 Revision 2
Beim Zusammensetzen der Revision 1 wurde festgestellt, dass nicht ausreichend Frei- raum für die Halterung des LiIon-Akkumulators eingeplant war und dieser mit dem BMS kollidiert. Zudem war der Widerstand R1 zu nah an dem LiIon-Akkumulator und verhinderte das Einsetzen.
Für das Platzieren einer Buchse in die Header der LED und des Ein/Aus Schalters war ebenfalls nicht ausreichend Freiraum.
Dies wurde korrigiert, indem ein größerer Freiraum zwischen BMS und Zellhalte- rung geschaffen und der Widerstand R1 auf der Oberseite des PCB platziert wurde.
Abbildung 6.3.:Revision .02 der ASAPLoRaBTModul-Platine (Render des Gerberfile)
6.3.3 Revision 3
Da während des Testens des PCBs der Revision 1 auffiel, dass der MicroUSB-Port und damit der Serielle Port zur Ausgabe des Fehlerprotokolls nicht zugänglich war, wurde das PCB für Revision 3 noch einmal überarbeitet, bevor ein weiterer Prototyp bestellt wurde.
Der ESP32 wurde um 180° gedreht platziert, sodass der MicroUSB-Port im einge- bauten Zustand genutzt werden kann. Da dies dazu führte, dass die Antenne des ESP32 und die Antenne des LoRa-Moduls direkt nebeneinander lagen, wurde das HIMO-01PModul ebenfalls um 180° gedreht. Die Ground Plane wurde halbiert, um einen freien Bereich unterhalb der Antenne desHIMO-01PModuls zu schaffen und die Ausbreitung der Funkwellen nicht unnötig zu stören.
Abbildung 6.4.:Revision .03 der ASAPLoRaBTModul-Platine
7. Message-Architektur
Die Kommunikation zwischenASAPLoRaBTModulund derMacLayerEnginefürLoRa (LoRaEngine) wird als serielle Schnittstelle abgebildet. Um eine solche zu emulieren, wird das Serial Port Profile (0x1101) der Bluetooth Specification genutzt. Zwischen dem LoRa Modem und dem Microcontroller wird ebenfalls eine serielle Schnittstelle zur Kommunikation verwendet.
Ursprünglich sollten die Nachrichten zwischen derLoRaEngineundASAPLoRaBT- Modulals JSON kodiert ausgetauscht und durch das Deserialisierungsfeature1 in die jeweilige Repräsentation der Klassen, dieASAPLoRaMessageInterface2implemen- tieren, übersetzt werden. Aufgrund des Aufkommens der nicht-funktionalen Anforde- rung, keine nicht-standard Bibliotheken zu nutzen, wurde dies jedoch verworfen. Als Ersatz werden nun Newline-terminierte Strings folgenden Formats als Datagramme verwendet:
<Be f ehl >[:< Adresse>][:< Idempotenztoken>][:< Daten>]LF
Ein Datagramm besteht aus 5 Zeichen, die das Kommando repräsentieren, gefolgt von einer optionalen 4-stelligen Hexadezimalzahl, welche die Ziel- oder Quelladresse des Datagramms enthält. Sofern zutreffend, wird ein zufällig generiertes, 10-stelliges Idempotenztoken der Nachricht hinzugefügt. Abschließend folgen, sofern zutreffend, die zu transportierenden Daten. In jedem Fall wird das Datagramm von einem Newline- Character beendet.
Damit Datagramme durch den Transport von Daten mit enthaltenem Newline-Symbol nicht vorzeitig abgebrochen werden, sind die Daten im Datagramm Base64-kodiert zu übergeben. Dies führt zur Einschränkung, dass 33% mehr Zeichen übertragen werden als tatsächliche Nutzdaten gesendet werden sollen, da nach RFC4648 [18] je 24 bit3 durch vier Zeichen des Base64-Alphabets im kodierten String repräsentiert werden.
1Polymorphic Type Handling: https://github.com/FasterXML/jackson-docs/wiki/
JacksonPolymorphicDeserialization
2SieheAbstractASAPLoRaMessage
3also 3 Zeichen a 8 bit
Bei nicht in 24bit-Blöcke aufteilbaren Zeichenketten wird der letzte Block vor dem Kodieren durch null-Bits aufgefüllt. Die genaue Länge ergibt sich somit als:
Length=4∗ dn 3e
Wie inAbschnitt 6.1: Auswahl der Hardwarebeschrieben, darf die maximale Länge einer Nachricht 250 Zeichen nicht überschreiten. Da der Protokolloverhead bis zu 17 Zeichen4 beträgt, ergeben sich 233 Zeichen maximale Länge der Base64-kodierten Nutzdaten.
Die maximale Länge n einer zu kodierenden Nachricht lässt sich durch Lösen der Ungleichung bestimmen:
233≥4∗ dn3e |: 4
⇔ 2334 ≥ dn3e |y≥ dxe ⇔ byc ≥x
⇔ b2334 c ≥ n3 | ∗3
⇔ 3∗ b2334 c ≥n
⇔ 3∗58≥n
⇔ 174≥n (7.1)
Daraus folgt, dass die Länge einer unkodierten Nachricht 174 Zeichen nicht überschrei- ten darf.
7.1 DSCVR
Der BefehlDSCVRwird als Broadcast-Nachricht definiert und steht somit immer ohne optionale Anteile der Befehlsstruktur. Die Firmware des Microcontrollers sendet einen solchen Befehl immer an die reservierte Adresse FFFF. In der Androidkomponente wird diese Nachricht von der KlasseDiscoverASAPLoRaMessagerepräsentiert.
7.2 DVDCR
Wenn einASAPLoRaBTModuleinenDSCVRBefehl empfängt, antwortet es mit dem Befehl DVDCR. Zusätzlich wird der verbundenen LoRaEngine der Befehl DVD- CR:<Adresse>, mit der Adresse desDSCVR-sendendenASAPLoRaBTModuls, übermittelt.
Empfängt ein ASAPLoRaBTModul den DVDCR-Befehl, ergänzt es ebenfalls die Ab- senderadresse und übermittelt den Befehl an die verbundeneLoRaEngine. In dieser wird dieser Befehl durch die KlasseDeviceDiscoveredASAPLoRaMessageabgebil- det.
45 Zeichen für den Befehl, 10 Zeichen für das Idempotenztoken und 2 Zeichen für die Trennsymbole „:“.
7. Message-Architektur
7.3 RCNCT[:<Adresse>]
Ein ASAPPeer prüft periodisch, ob eine aufgebaute Verbindung weiterhin aufrecht- erhalten ist. Die Emulation einer Verbindung zweier LoRa Modems, sodass sie ver- gleichbar mit Bluetooth-Sockets sei, kann über den Versand eines RCNCT-Befehls erfolgen. DieLoRaEnginefordert einen Verbindungsversuch durch das Senden eines RCNCT:<Adresse>-Befehls an. Ein entferntes ASAPLoRaBTModul beantwortet einen empfangenenRCNCT-Befehl ebenfalls mitRCNCT, was derLoRaEnginedurch Über- mittlung vonRCNCT:<Adresse>bestätigt wird.
Die Implementierung dieses Teils des Protokolls wurde später verworfen, da die periodi- sche Versendung desDSCVR-Broadcast nahezu dieselbe Funktionalität bereitstellt. Die Emulation der Verbindungshaftigkeit wird stattdessen über eine Liste der Zeitpunkte des letzten Nachrichtenaustauschs imLoRaCommunicationManagerrealisiert.
7.4 MSSGE
Der BefehlskennerMSSGEkennzeichnet den Austausch von Nutzdaten und kann in zwei Kontexten genutzt werden. Zum einen im Austausch von Nachrichten zwischen ASAPLoRaBTModul und LoRaEngine; hierbei wird die Nachricht folgendermaßen aufgebaut:
MSSGE:< Adresse>:< Daten>LF
Die Adresse entspricht je nach Sende- oder Empfangsrichtung dem Adressaten oder dem Absender der Nachricht.
Zum anderen in der Kommunikation zwischen zweiASAPLoRaBTModulen. Hier ist die Sender-/Empfängeradresse Teil des LoRaPHY-Protokolls und wird daher nicht zusätzlich in der Nachricht übergeben. Zur Sicherstellung der Idempotenz der Nach- richten wird ein zufällig generiertes, 10-stelliges, alphanumerisches Idempotenztoken der Nachricht angefügt.
MSSGE:< Idempotenztoken>:< Daten>LF
7.5 IDEMP:<Token>
Empfängt einASAPLoRaBTModulein Datagramm desMSSGE-Typs, extrahiert es das Idempotenztoken und bestätigt den Empfang durch Antwort mit demIDEMP-Befehl und dem empfangenen Idempotenztoken:
IDEMP:< Idempotenztoken> LF
Abbildung 7.1.:Discovery eines anderen ASAPLoRaBTModul und Versand einer Nachricht
8. Softwarearchitektur der Firmware des ASAPLoRaBTModul
Die Firmware desASAPLoRaBTModulbesteht aus 2 Teilen: einerseits dem Programm zur Initialisierung und Konfiguration der Umgebung, andererseits einer zu entwickeln- den KlasseLoRaCommManagerfür die Steuerung desHIMO01P-Modem.
8.1 Programmumgebung
Für die Entwicklung wird dieArduino-Umgebung genutzt.Arduino-Programme werden in C++ entwickelt und haben zwei Standardmethoden:setup(), die einmalig bei Start des Microcontrollers aufgerufen wird, und loop(), die nach dem ersten Lauf von setup()kontinuierlich aufgerufen wird, solange der Microcontroller aktiv ist.
In der setup()-Methode wird die Bluetooth-Verbindung zum Smartphone einge- richtet und derLoRaCommManager instanziiert. Inloop()werden kontinuierlich die Methoden zum Verarbeiten der Nachrichten der Bluetoothschnittstelle und desLoRa- CommManageraufgerufen.
8.2 LoRaCommManager
DerLoRaCommManagersteuert den Ablauf der Befehle zum Nachrichtenversand und -empfang mithilfe desHIMO01P-Modems. Wenn in diesem Kapitel von Versand einer Nachricht gesprochen wird, meint dies die Übermittlung eines Pakets des inKapitel 7:
Message-Architekturbeschriebenen Protokolls überLoRa, welches die Bestätigung über einIDEMP-Paket erwartet. Ist von der Übermittlung eines Befehls an dasHIMO01P- Modem (oder dem Empfang einer Antwort auf einen Befehl) die Rede, so meint dies die Übermittlung einesAT-Befehls über die serielle Schnittstelle (sieheAbschnitt 3.11:
AT-Befehle (eine Auswahl)).
Nachdem dasHIMO01P-Modem initialisiert und konfiguriert wurde, befindet es sich im Empfangszustand. Damit kann entweder auf neu eingehende Nachrichten reagiert oder Nachrichten versendet werden. Da der Programmablauf der Android-Umgebung auf dem ESP32singlethreaded ist, muss die Firmware geringstmöglich blockierend arbeiten. Andernfalls besteht die Gefahr, dass die Buffer der seriellen Schnittstellen des ESP32 überlaufen und Nachrichten (teilweise) verloren gehen.
Für die Ablaufsteuerung werden drei FIFO-Queues angelegt. Die erste für zu ver- sendende Nachrichten, welche über Bluetooth empfangen und demLoRaCommManager übergeben wurden; die zweite für auszuführende Befehle; die dritte für zu verarbeiten- de, zum empfangenen Zeitpunkt nicht verarbeitbare, eingehende Nachrichten.
Diese Queues werden während der Laufzeit kontinuierlich gefüllt und abgearbei- tet. Zur Koordination wird eine Statemachine mit spezifischen Zuständen entworfen, welche in den nachfolgenden Unterkapiteln beschrieben sind.
8.2.1 LORA_CLOSED
Sofern kein Smartphone mit demASAPLoRaBTModule verbunden ist, befindet sich die Statemachine in diesem Zustand. Neu eingehende Nachrichten und Befehlsantworten desHIMO01P-Modems werden in diesem Zustand verworfen.
8.2.2 LORA_IDLE
Dies ist der Standardzustand - von diesem aus können empfangene Nachrichten verarbeitet werden, von derLoRaEnginebeauftragte Nachrichten versendet werden oder nicht-nachrichtenbezogene Befehle an dasHIMO01P-Modem geschickt werden.
8.2.3 LORA_AWAITING_COMMAND_RESULT
Nachdem ein Befehl, welcher nicht zum Versand einer Nachricht dient, an das HI- MO01P-Modem übermittelt wurde, befindet sich die Statemachine in diesem Zustand.
Nachdem das Bestätigen des Befehls durch dasHIMO01P-Modem erfolgt ist, geht die Statemachine inLORA_IDLEüber.
8.2.4 LORA_SENDING_MESSAGE
Nachdem die für den Versand einer Nachricht relevanten Befehle in die Befehlsqueue geschrieben wurden, wechselt die Statemachine in diesen Zustand.
8.2.5 LORA_AWAITING_MESSAGE_COMMAND_RESULT
Nachdem ein Befehl, welcher zum Versand einer Nachricht dient, an dasHIMO01P- Modem übermittelt wurde, befindet sich die Statemachine in diesem Zustand. Wenn das Bestätigen des Sende-Befehls durch das HIMO01P-Modem erfolgt ist, geht die Statemachine erneut inLORA_SENDING_MESSAGEüber. Sind alle Befehle eines Nach- richtenversands ausgeführt, erfolgt der Übergang in den ZustandLORA_AWAITING_- MESSAGE_RESPONSE.
8. Softwarearchitektur der Firmware des ASAPLoRaBTModul
8.2.6 LORA_AWAITING_MESSAGE_RESPONSE
Nach dem Versand einer Nachricht befindet sich die Statemachine bis zum Ablauf des RTO oder dem Empfang der Empfangsbestätigung in diesem Zustand. Danach erfolgt der Übergang zuLORA_IDLE.
Abbildung 8.1.:Statusübergänge des LoRaCommManager
8.3 Kollisionsbehandlung
Während der ersten Tests mit der Example-App des ASAPAndroid-Projekts wurde festgestellt, dass die Nachrichten zum Aufbau einerASAPSessionnicht ausgetauscht werden.
Es wurde vermutet, dass diese durch Kollisionen auf dem geteilten Medium verloren gehen, was durch Entwicklung des JUnittestsSimultaneousCommunicationTest und der Beobachtung mitSDRSharp1verifiziert wurde.
Abbildung 8.2.:Screenshot aus SDRSharp mit der sichtbaren Kollision, rot markiert
Der Versand desDSCVRBefehl, beziehungsweise der Empfang desDVDCR Befehl, stellt einen Synchronisationspunkt in der Kommunikation zweierASAPPeers über das ASAPLoRaBTModuldar. Dies führt dazu, dass die Nachrichten zum Aufbau einerASAP- Sessionnahezu immer zum gleichen Zeitpunkt gesendet werden und damit kollidieren.
1eine populäre Software für Software-Defined Radios:https://airspy.com/download/
8. Softwarearchitektur der Firmware des ASAPLoRaBTModul
Für die Behebung dieses Problems wäre eine gängige Strategie das oben beschriebe- neCSMA/CA. Da jedoch das CCA von LoRa,Carrier Activity Detection, welches eine Grundvoraussetzung für das CSMA/CA-Verfahren ist, von der aktuellen2 Firmware desHIMO01P-Modems nicht bereitgestellt wird, ist dies nicht möglich. Eine hilfsweise Nutzung der gemessenen Signalstärke ist mangels Firmwareunterstützung für die Messung ohne vorherigen Nachrichtenempfang ebenfalls nicht möglich.
Daher beschränken sich die Möglichkeiten auf ALOHA beziehungsweise Varianten davon. Das ALOHA-Verfahren wird für den vorliegenden Anwendungsfall um eine Strategie, ähnlich der inAbschnitt 3.3: Listen before Talk / Polite Spectrum Accessbeschrie- benen, ergänzt.
Als Backoff-Zeit verwenden wir den in Abschnitt 3.5: Round Trip Time des Transmis- sion Control Protocolbeschriebenen RTO, verzichten jedoch darauf, ihn nach oben oder unten zu beschränken, da die Time on Air von der Modemkonfiguration und Paketgrö- ße abhängt und stark variieren kann. Hierfür definieren wir die zu messende RTT als den Zeitraum zwischen dem ersten Übergang vonLORA_IDLEinLORA_SENDING_- MESSAGEbis zur Bestätigung durch Empfang des IDEMP-Befehls und dem daraus folgenden Übergang nachLORA_IDLE. Für Alpha wählen wir 0.5, für Beta einen Zu- fallswert zwischen 1.0 und 5.0 - diese Werte wurden experimentell bestimmt.
Zunächst erfolgt der Sendeversuch (sieheAbschnitt 8.2: LoRaCommManager) bei beiden Teilnehmern. Sofern keine Bestätigung innerhalb des RTO erfolgt, wird die letzte Nach- richt erneut gesendet. Hier wird nun, abweichend vom gängigenALOHA-Verfahren, ein ZählerBackoffCycleinkrementiert und der RTO mit diesem multipliziert. So wird erreicht, dass nach einer angenommenen3 Kollision der Effekt des zufälligen Anteils Beta verstärkt und ein erfolgreicher Versand im nächsten Versuch wahrscheinlicher wird.
Nach Empfang und Bestätigung einer Nachricht durch den IDEMP-Befehl wird - davon ausgehend, dass weitere Nachrichten auf diese folgen werden - auf dem empfan- gendenASAPLoRaBTModuldie einfache SRTT abgewartet, um eine potentielle Kollision zu vermeiden.
2v0.6 zum Zeitpunkt dieser Arbeit, siehe das in [38] referenzierteGitHub-Repository:https://github.
com/eboxmaker/STM8L_Lora/tree/master/03.utility/firmware
3Ein weiterer Grund für das Ausbleiben der Bestätigung wäre, dass der designierte Empfänger nicht mehr in Reichweite ist.
Android-Komponente
Die Androidkomponente besteht aus drei Teilkomponenten. DerLoRaEngine, d. h.
der MacLayerEngine für LoRa, dem LoRaCommunicationManager und dem LoR- aBTInputOutputStream. Letztgenannte teilt sich in Subklassen zusätzlich auf in InputStreams und OutputStreams.
Abbildung 9.1.:Übersicht Klassenstruktur der Androidkomponente
9. Softwarearchitektur der Android-Komponente
9.1 LoRaEngine
Die vonMacLayerEngineabgeleitete KlasseLoRaEnginestartet einen Thread der Klas- seLoRaCommunicationManagerund stoppt diesen im Fall des Endes der Lifetime der LoRaEngine.
Die Methoden tryReconnect() und checkConnectionStatus()bilden in ver- bindungsbehafteten MacLayerEngines die Verbindungsverwaltung ab. Da LoRa ein verbindungsloses Protokoll ist, werden diese nur durch leere Methoden implementiert.
9.2 AbstractASAPLoRaMessage
Die abstrakte Klasse AbstractASAPLoRaMessage bildet das in Kapitel 7: Message- Architekturbeschriebene Protokoll zwischen derLoRaEngineund demASAPLoRaBT- Modul in Java ab. Mit ihren abgeleiteten Klassen und der MethodecreateASAPLo- RaMessage() bildet sie eine static factory, welche, je nach Art der Nachricht des ASAPLoRaBTModul, eine passende Instanz einer Klasse, die ASAPLoRaMessageIn- terfaceimplementiert, erzeugt.
Abbildung 9.2.:Übersicht Klassenstruktur der Subtypen vonAbstractASAPLoRaMessage
9.3 LoRaCommunicationManager
Die KlasseLoRaCommunicationManagerverwaltet die Verbindung zumASAPLoR- aBTModul. Hauptaufgabe ist das Vermitteln der Kommunikation zwischen den verschie- denen Input/OutputStreams. Eine weitere Aufgabe ist, periodisch zu prüfen, wann die letzte Nachricht eines entferntenASAPPeers empfangen wurde und die Streams diesesASAPPeers zu schließen, sofern die konfigurierte Zeit überschritten ist. Auch das periodische Auslösen des Rundrufs zur Erkennung weiterer ASAPPeers ist Aufgabe desLoRaCommunicationManager. Zur Erfüllung dieser Aufgaben wird die Klasse Threaderweitert und damit das InterfaceRunnableimplementiert.
Um die Verwaltung der Verbindungen, beziehungsweise der bekannten direkten Kom- munikationsstrecken zu anderenASAPPeers, zu ermöglichen, erstellt derLoRaCommu- nicationManagereine Instanz der KlasseLoRaBTInputOutputStream.
Beim Erstellen desLoRaCommunicationManagermuss eine Instanz der KlasseBlue- toothDeviceübergeben werden, welches ein gepairtesASAPLoRaBTModulrepräsen- tiert. DerLoRaCommunicationManagererstellt einen seriellen Socket zu diesem und übergibt ihn der Instanz vonLoRaBTInputOutputStream.
9.4 LoRaBTListenThread
Damit derLoRaCommunicationManagerdie periodischen Aufgaben erfüllen kann, wird bei Aufruf der run()-Methode ein weiterer Thread LoRaBTListenThread gestartet. Dieser übernimmt die Aufgabe des blockierenden Lesens auf demLoRaB- TInputStream1 und übergibt eingehendeAbstractASAPLoRaMessages derLoRa- CommunicationManager-Instanz.
9.5 LoRaBTInputOutputStream
Im LoRaBTInputOutputStreamwird die 1-zu-n Beziehung zwischen physischem Bluetooth-Kommunikationskanal und den logischen Kommunikationskanälen pro er- kanntemASAPPeer, also je einem Input/OutputStream, abgebildet.
Hierzu werden 4 innere Klassen entworfen, wie in den nachfolgenden Unterkapi- teln beschrieben.
1SieheUnterabschnitt 9.5.1:LoRaBTInputStream / LoRaBTOutputStream
9. Softwarearchitektur der Android-Komponente
9.5.1 LoRaBTInputStream / LoRaBTOutputStream
EinerseitsLoRaBTInputStreamundLoRaBTOutputStream(im folgenden alsLoR- aBTStreamsbezeichnet), welcheFilterInputStreambeziehungsweiseFilterOut- putStreamerweitern und Objekte vom TypAbstractASAPLoRaMessagelesen und schreiben können. Diese bilden den physischen Kommunikationskanal ab.
Abbildung 9.3.:Interaktion desLoRaCommunicationManagermit demLoRaBTInputStream
9.5.2 LoRaASAPInputStream / LoRaASAPOutputStream
AndererseitsLoRaASAPInputStreamundLoRaASAPOutputStream(im folgenden als LoRaASAPStreams bezeichnet), welche InputStream beziehungsweise Output- Streamerweitern und ein Attribut zum Vorhalten der zugehörigenLoRa-Hardware- Adresse haben. Diese bilden zusammen einen logischen Kommunikationskanal eines ASAPPeers überLoRaab. Daten derASAPPeers werden von byte-Arrays in 174 Zeichen2 langeASAPLoRaMessages mit der hinterlegten Hardware-Adresse des Streams gewan- delt und in denLoRaBTOutputStreamgeschrieben. Für das Verarbeiten eingehender Nachrichten durch den LoRaCommunicationManager wird eine Möglichkeit des Anhängens von byte-Arrays an denLoRaASAPInputStreamgeschaffen.
Die Klasse erhält weiterhin zwei Datenstrukturen, die alle erstellten Instanzen vonLo- RaASAPInputStreambeziehungsweiseLoRaASAPOutputStreamvorhalten. Sofern der Zugriff auf einenLoRaASAPStreamversucht wird, dieser aber noch nicht besteht, erstelltLoRaBTInputOutputStreamden jeweiligen Stream. Wird erkannt, dass ein ASAPPeernicht mehr erreichbar ist, werden die zugehörigenLoRaASAPStreams entfernt.
2SieheKapitel 7: Message-Architektur
Abbildung 9.4.:Interaktion des LoRaCommunicationManager und dem LoRaASAPInputStream
Abbildung 9.5.:Interaktion derOutputStreams desLoRaBTInputOutputStream
10. Implementierung
Im Sinne der Übersichtlichkeit wird in diesem Kapitel nur auf die Kernpunkte ein- gegangen. Für eine vollständige Kommentierung der Implementierung sei auf das in Abschnitt A.2: Quell-Codebeziehungsweise im Appendix verlinkte Repository verwiesen.
10.1 ...der Firmware desASAPLoRaBTModul
Wie in Kapitel 8: Softwarearchitektur der Firmware des ASAPLoRaBTModulbeschrieben, besteht die Programmumgebung aus zwei Hauptteilen: der Initialisierungsmethode setup()und der kontinuierlich aufgerufenen Methodeloop().
10.1.1 setup()
Insetup()wird zunächst derLoRaCommManagerinitialisiert. Hierfür wird die Me- thode setupLoRaBoard() mit den im Headerfile ASAPLoRaConfig.h gesetzten define-Compilermacro define LORA_ADDRESS und define LORA_MESSAGING_- CONFIG aufgerufen. Ersteres enthält die global einmalig zwischen 1000 und FFFE zu vergebende Adresse des ASAPLoRaBTModuls und muss bei jedem neu mit der Firmware ausgestatteten Modul geändert werden.1 Zweiteres enthält die kommage- trennten Einstellungen desHIMO01P-Modems: dieses wird auf eine Carrierfrequenz von 434052500 konfiguriert, das entspricht der Mittenfrequenz des ersten 25kHz Bands des inUnterabschnitt 6.1.1: Auswahl der Funktechnologie für den Langstreckenfunk zweier Modulegewählten Frequenzbereichs. Die Übertragungsenergie wurde auf 10 beschränkt (entspricht 10mW eingespeiste Leistung2) und die Modulationsbreite auf 3 (was einer genutzten Bandbreite von 20.8kHz entspricht) gesetzt. Die sonstigen Parameter wurden in den Standardeinstellungen belassen. Der konkrete Aufbau des Parameters kann [38]
entnommen werden.
1Die Wahl eines define statt einer const rührt daher, dass defines auch per Parameter -D name=value an den gcc-Compiler beziehungsweise Präprozessor übergeben werden können und so der Aufbau einer Buildqueue erleichtert würde.
2Achtung: hier ist gegebenenfalls der Antennengewinn noch einzurechnen - wir gehen mit dieser Einstellung von einem Halbwellendipol als Antenne aus!
Für die serielle Schnittstelle zwischen Smartphone undESP32wird die KlasseBlue- toothSerial aus der Arduino-ESP32 Library3 von espressif genutzt. Diese wird durch den Aufruf von begin() mit der Übergabe eines weiteren define, der den Namen desASAPLoRaBTModulenthält, initialisiert. Des Weiteren wird ein Callback angemeldet, welcher bei Aufbau beziehungsweise Trennung der Verbindung den jewei- ligen Zustand der seriellen Schnittstelle inASAPLoRaBTStatusfesthält.
DemLoRaCommManagerwird ein Callback übergeben, welches dieser aufruft, wenn eine Nachricht empfangen wurde, die die Übergabe der Nutzdaten an das Smartphone nötig macht. Diese Daten werden durch die Callbackfunktion an dieBluetoothSeri- al-Instanz übergeben.
Ein weiterer Callback wird registriert, welcher Statusübergänge der Statemachine, die inAbschnitt 8.2: LoRaCommManagerbeschrieben wurde, übergeben bekommt. Diese werden genutzt, um die Status-LED desASAPLoRaBTModuleinen Farbcode für den jeweiligen Zustand anzeigen zu lassen.
Tabelle 10.1.:Farbcodes der Status-LED Farbe Status
Gelb Initialisierung desASAPLoRaBTModul Rot LORA_CLOSED
Grün LORA_IDLE
Magenta LORA_AWAITING_COMMAND_RESULT
Cyan LORA_AWAITING_MESSAGE_COMMAND_RESULT Blau LORA_SENDING_MESSAGE
Orange LORA_AWAITING_MESSAGE_RESPONSE
3https://github.com/espressif/arduino-esp32/tree/master/libraries/
BluetoothSerial
10. Implementierung
10.1.2 loop()
Sofern die Verbindung derBluetoothSerial-Instanz geschlossen ist, wird dieclo- se()-Methode des LoRaCommManager aufgerufen. Sofern dieser sich im Zustand LORA_IDLEbefindet, folgt der Statusübergang inLORA_CLOSED.
Andernfalls wird zuerst geprüft, ob Daten im Empfangsbuffer der BluetoothSe- rialSchnittstelle verfügbar sind. Solange dies der Fall ist, werden diese zeilenweise eingelesen undASAPLoRaMessage-Objekte mit der Zieladresse und den Nutzdaten erstellt. Diese werden demLoRaCommManagerübergeben, welcher diese in die zugehö- rige FIFO Queue legt. Anschließend wird dieopen()-Methode desLoRaCommManager aufgerufen.
In jedem Fall wird diehandleMessages()-Methode desLoRaCommManageraufgeru- fen, welche die Statusübergänge entsprechend der inAbschnitt 8.2: LoRaCommManager beschriebenen Statemachine steuert.
10.2 ...der Android-Komponente
Die Androidkomponente wurde entsprechend dem Entwurf ausKapitel 9: Softwarear- chitektur der Android-Komponenteimplementiert. Während derIntegrationstestswurde festgestellt, dass obwohl die Nutzdaten erfolgreich zwischen den Smartphones ausge- tauscht werden konnten, diese nicht von denASAPPeers verarbeitet wurden. Daher wurde ein weiterer JUnit-TestLoRaBTInputOutputStreamTestentwickelt, mithilfe dessen dieser Fehler identifiziert werden konnte:
Damit der Zugriff auf die LoRaASAPInputStream / LoRaASAPOutputStream threadsicher erfolgen kann, waren die Methoden appendData() und read() als synchronized gekennzeichnet. Dies führte jedoch dazu, dass appendData nie aufgeru- fen werden konnte, sobald einASAPPeerread()aufgerufen hat und damit die Instanz vonLoRaASAPInputStreamin einen Deadlockzustand gebracht hat.
Behoben wurde dies, indem eine Monitorobjekt threadLock als Eigenschaft von LoRaASAPInputStreameingeführt wurde, welche stattdessen die Threadsicherheit sicherstellt. Alle schreibenden Zugriffe auf die byte-Arrays werden in synchronized- Blöcke eingebettet und die Methoderead()ruft.wait()des Monitorobjekts auf, um die Ausführung zu unterbrechen, sofern keine zurückzugebenden Daten vorhanden sind.
1 synchronized ( t h i s . threadLock ) {
2 while ( t h i s . a v a i l a b l e ( ) < 1 ) {
3 [ . . . ]
4 t r y {
5 t h i s . threadLock . wait ( LoRaBTInputOutputStream . READ_WAIT_TIMEOUT) ;
6 } c a t c h ( I n t e r r u p t e d E x c e p t i o n e ) {
7 /* NOOP, l e t s check our conditions again . */
8 }
9 }
10
11 [ . . . ]
12 }
Listing 10.1:Unterbrechen desread()-Aufrufs eines LoRaASAPInputStream
Werden nun mittels appendData() neue Daten an den LoRaASAPInputStream übergeben, ruft dieser notify() des Monitorobjekts auf, um die Ausführung der read()-Methode fortzusetzen.
1 synchronized ( t h i s . threadLock ) {
2 t h i s . inputStreams . add ( new ByteArrayInputStream ( data ) ) ;
3 t h i s . threadLock . n o t i f y ( ) ;
4 }
Listing 10.2:Benachrichtigen eines wartendenread()-Aufrufs
11. Test
Das Testen der entstandenen Komponente erfolgt in drei Schritten, anhand welcher gezeigt wird, dass der Aufbau einerASAPSessionzweierASAPPeers über LoRa möglich und damit das Ziel dieser Arbeit erreicht ist.
Zunächst werden JUnit-Tests für die Nachrichtenübertragung über das ASAPLoR- aBTModulentwickelt und so die Existenz einer Punkt-zu-Punkt Verbindung, die Grund- voraussetzung zum Aufbau einerASAPSession, gezeigt. Nachfolgend werden die Teil- komponenten der Android-Komponente einzeln getestet. Abschließend erfolgt ein Integrationstest mit der Beispielanwendung desASAPAndroid-Projekts, bei dem der praktische Aufbau derASAPSessiongezeigt wird.
11.1 JUnit Tests desASAPLoRaBTModul
Für die Tests desASAPLoRaBTModul werden 2ASAPLoRaBTModule mit einem An- droidsmartphone per Bluetooth gepaired. Die Tests gehen davon aus, dass es sich um die ersten zwei hergestellten Module mit den Adressen 1000 und 1001 handelt. In der @BeforeClass-Methode werden 2 Sockets geöffnet, welche im Folgenden die Teilnehmer Alice und Bob repräsentieren.
11.1.1 BasicCommunicationTest
Dieser Test enthält drei Prüfmethoden:deviceDiscoveryTest()testet den Broadcast- Discovery-Mechanismus wie in Abschnitt 7.1: DSCVR beschrieben; simpleAlice- ToBobMessageTest() testet das Übertragen einer Nachricht über das inKapitel 7:
Message-Architekturbeschriebene Protokoll;simpleBobToAliceMessageTest()prüft die Kommunikation in Gegenrichtung. Damit ist der Aufbau einer Punkt-zu-Punkt Verbindung gezeigt.
