Fachgebiet Kommunikationsnetze - TU Ilmenau
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Fachgebiet Kommunikationsnetze
Philipp Zenker
Over-the-Air-Programmierung in Mesh-Netzwerken
basierend auf Bluetooth 5.0
Masterarbeit im Studiengang Elektrotechnik und Informationstechnik
13. Juni 2018
Bitte zitieren als:
Philipp Zenker, ”Over-the-Air-Programmierung in Mesh-Netzwerken basierend auf Bluetooth 5.0”, Masterarbeit,
Technische Universität Ilmenau, Fakultät für Elektrotechnik und Informationstechnik, Juni 2018.
Technische Universität Ilmenau
Fakultät für Elektrotechnik und Informationstechnik
Fachgebiet Kommunikationsnetze
Helmholtzplatz 2 · 98693 Ilmenau · Deutschland
http://www.tu-ilmenau.de/kn
Over-the-Air-Programmierung in
Mesh-Netzwerken basierend auf Bluetooth 5.0
Masterarbeit im Studiengang Elektrotechnik und Informationstechnik
vorgelegt von
Philipp Zenker
angefertigt am
Fachgebiet Kommunikationsnetze
Fakultät für Elektrotechnik und Informationstechnik
Technische Universität Ilmenau
Betreuer: Prof. Dr. rer. nat. Jochen Seitz
Abgabe der Arbeit: 13. Juni 2018
Erklärung Ich versichere, dass ich die Arbeit ohne fremde Hilfe und ohne Benutzung anderer als der angegebenen Quellen angefertigt habe und dass die Arbeit in gleicher oder ähnlicher Form noch keiner anderen Prüfungsbehörde vorgelegen hat und von dieser als Teil einer Prüfungsleistung angenommen wurde. Alle Ausführungen, die wörtlich oder sinngemäß übernommen wurden, sind als solche gekennzeichnet. (Philipp Zenker) Ilmenau, 13. Juni 2018
Danksagung Ich bedanke mich zunächst bei den Mitarbeitern der senTec Elektronik GmbH, welche mich bei dieser Arbeit stets unterstützt haben. Besonders gedankt seien außerdem Univ.-Prof. Dr. rer. nat. Jochen Seitz und Dipl.-Ing. Michael Binhack, welche mir die Möglichkeiten gegeben haben, diese Arbeit zu verwirklichen. Masterarbeit Philipp Zenker iii
Abstract The modern world is becoming smarter. More and more parts of our daily lifes become technologically enhanced and connected. The speed with which electronic applications have become commonplace has increased drastically over the last few years. The high number of device and the speed of technological change demand new approaches to networking and reprogramming devices over-the-air. Bluetooth Mesh is a new addition to the widely-used Bluetooth Low Energy Standard, allowing for multi-hop networks containing potentially thousands of nodes. This work finds and analyses methods to program devices over the air in these networks. To that end this work examines potential applications for their unique requirements and investigated error sources as well as security vulnerabilities in order to design a comprehensive concept for over-the-air programming in Bluetooth Mesh networks. This procedure proves itself to be capable of distributing even larger amounts of data throughout Bluetooth Mesh networks and able to deal with highly variable circumstances and requirements. Masterarbeit Philipp Zenker iv
Kurzfassung Die moderne Welt wird intelligenter. Immer mehr Teile unseres alltäglichen Lebens wer- den technologisch aufgewertet und vernetzt. Die Geschwindigkeit, mit der elektronische Anwendungen dabei in unserem Umfeld Fuß fassen, ist in den letzten Jahren zunehmend angestiegen. Die hohe Menge an Geräten und der schnelle technische Wandel fordern neue Ansätze für ihre Vernetzung und zur Umprogrammierung Over-the-Air. Bluetooth Mesh ist eine neue Erweiterung des weitverbreitetem Bluetooth Low Energy Standards für Multi-Hop-Netzwerke mit potentiell Tausenden an Geräten. Für diese Netzwerke sol- len nun Methoden zur Over-the-Air-Programmierung gefunden und untersucht werden. Dazu wurden die dazugehörigen Anforderungen in möglichen Anwendungen analysiert, potentielle Fehlerquellen und erforderliche Sicherheitsanforderungen ergründet und ba- sierend darauf ein umfassendes Konzept entwickelt und in einer ersten Implementation getestet. Das Verfahren erweist sich dabei als tauglich, um auch größere Datenmenge in Bluetooth Mesh-Netzwerken zu verteilen und mit einer Vielzahl an unterschiedlichen Umständen und Anforderungen umzugehen. Masterarbeit Philipp Zenker v
Inhaltsverzeichnis
Abstract iv
Kurzfassung v
1 Einleitung 1
1.1 Einordnung des Themas . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Präzisierung der Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . 2
2 Grundlagen 3
2.1 Mesh-Netzwerke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Over-The-Air Programmierung . . . . . . . . . . . . . . . . . . . . . . . 4
2.2.1 Bootloader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2.2 Kodierung & Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.3 Verteilungsstrategien . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.1 MNP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.2 Deluge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.3 FireCracker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.4 Sprinkler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.5 Aqueduct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4 Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4.1 Bluetooth Low Energy . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4.2 Bluetooth 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4.3 Bluetooth Mesh . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3 Anwendungsfälle 17
3.1 Netzwerkeigenschaften . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2 Anforderungskriterien . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Masterarbeit Philipp Zenker viInhaltsverzeichnis
3.3 Anwendungsszenarien . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3.1 Smart Home . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3.2 Industrie 4.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3.3 Wireless Sensor Network . . . . . . . . . . . . . . . . . . . . . . . 26
3.3.4 Beacon Network . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4 Problemfälle und Sicherheit 31
4.1 Fehlerquellen und -behandlung . . . . . . . . . . . . . . . . . . . . . . . 31
4.2 Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5 Implementierung 38
5.1 Konzeption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.1.1 Grundsätze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.1.2 Das Meta-Datenpaket . . . . . . . . . . . . . . . . . . . . . . . . 39
5.1.2.1 Generelle Parameter . . . . . . . . . . . . . . . . . . . . 40
5.1.2.2 Sicherheitsoptionen . . . . . . . . . . . . . . . . . . . . 44
5.1.2.3 Verteilungsspezifische Einstellungen . . . . . . . . . . . 44
5.1.3 Verteilungsstrategien . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.1.3.1 Native . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.1.3.2 Virtual Neighborhood . . . . . . . . . . . . . . . . . . . 48
5.1.4 Ablauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.2 Durchführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.2.1 Topologie und Konfiguration . . . . . . . . . . . . . . . . . . . . 55
5.2.2 Interferenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.2.3 Virtual Neighborhood . . . . . . . . . . . . . . . . . . . . . . . . 67
5.3 Auswertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6 Evaluation an Anwendungsszenarien 72
6.1 Smart Home . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.2 Industrie 4.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.3 Wireless Sensor Network . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.4 Beacon Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
7 Zusammenfassung 76
8 Ausblick 78
Literaturverzeichnis 84
Masterarbeit Philipp Zenker viiKapitel 1 Einleitung 1.1 Einordnung des Themas Unsere Umwelt wird immer intelligenter. Im Zuge des Internet of Things (IoT) wer- den immer mehr vernetzte Geräte und Sensoren in Betrieb genommen. Bei manchen Schätzungen werden bis zum Jahr 2020 Stückgrößen von circa 20 [1] bis 33 Milliarden [2] IoT-Geräten weltweit vorhergesagt. Dabei gewinnt die Form der Mesh-Netzwerke zunehmend an Beliebtheit. Hierbei handelt es sich um einen Netzwerk-Typ, bei dem alle Geräte mit allen physikalisch erreichbaren Netzwerkteilnehmern in Verbindung stehen. Auch eine Industriegröße wie die Bluetooth Special Interest Group (SIG) hat mit ihrer neuen Bluetooth 5.0 Version [3] und dem „Bluetooth Mesh“-Protokoll [4] eine für IoT aufgerüstete, mesh-fähige Lösung herausgebracht. Dem Vormarsch der neuen vernetzten Welt scheinen alle Wege geebnet zu sein. Jedoch ist die Zahl der Negativ-Meldungen inzwischen ebenfalls stark angestiegen. Sicherheitslücken und Probleme sind bei IoT-Produkten keine Seltenheit. Das Risiko unzureichend getesteter, bzw. erprobter Technologie und die teilweise hohen Kosten von Geräten aus der „smarten“ Generation schrecken noch viele Käufer von IoT-Produkten ab [5]. Doch in diesem sich rapide entwickelndem und schnell wandelndem Markt sind den Herstellern nicht nur die Kundenzufriedenheit, sondern eben auch eine schnelle Produkteinführungszeit sehr wichtig. Umso wichtiger wird die Möglichkeit, Sicherheitsupdates, Bugfixes und Patches bei bereits verkauften und sich im Einsatz befindlichen Geräten aufspielen zu können. Was bei Computer, Smartphone und Großelektronik schon lange zum Standard gehört, gestaltet Masterarbeit Philipp Zenker 1
1 Einleitung sich bei großen Netzwerken kleiner Elektroniken, oftmals unverkabelt und mobil oder schwer erreichbar und mit nur geringen verfügbaren Ressourcen, schon weitaus schwieriger. Möglichkeiten zu Firmwareupdates mittels Over-the-Air-Programming (OTAP) ist hier ein Muss. Die meisten bestehenden Protokolle für OTAP sind allerdings hardwarespezifisch und meistens auch nur für Single-Hop-Anwendungen gedacht, welche aufgrund ihrer Nutzerun- freundlichkeit eher zu Abneigung führen würde. Zudem wurden auch hier Problemfällen und Sicherheitsvorkehrungen oftmals zu wenig Beachtung geschenkt. Erschwerend kommt hinzu, dass je nach Anwendungszweck und Eigenschaften des Netzwerkes unterschiedli- che Anforderungen an den OTAP-Prozess gestellt werden, weswegen nicht von einem einzigen optimalen und universell einsetzbaren Verfahren ausgegangen werden kann. 1.2 Präzisierung der Aufgabenstellung Ziel dieser Arbeit ist es eine Lösung für die Over-the-Air-Programmierung in auf Blue- tooth 5.0 basierten „Bluetooth Mesh“-Netzwerken zu entwickeln. Dafür sollen zunächst anhand realistischer Anwendungsszenarien die Anforderungen an ein solches Verfahren ermittelt werden. Mögliche Verteilungsstrategien sollen dann auf ihre Tauglichkeit in den Szenarien getestet und evaluiert werden. Daraufhin muss auch auf die Behandlung möglicher Problemfälle sowie Sicherheitsvorkehrungen eingegangen werden. Mithilfe dieser Vorarbeit soll dann ein Konzept für OTAP in Bluetooth 5.0 entwickelt und in einer Beispielapplikation implementiert und validiert werden. Anhand dieser Implementierung soll anschließend die Verwendung in den besprochenen Anwendungsszenarien bewertet werden. Masterarbeit Philipp Zenker 2
Kapitel 2
Grundlagen
2.1 Mesh-Netzwerke
Mit Mesh-Netzwerk wird eine Netzwerktopologie bezeichnet, bei welcher alle Netzwer-
knoten mit jeweils allen anderen physikalisch erreichbaren Knoten verbunden sind, wie in
Abbildung 2.1 zu sehen ist. Innerhalb des Mesh-Netzwerkes können die einzelnen Knoten
die Funktionen eines Routers und Repeaters übernehmen. Dadurch werden Multi-Hop-
Übertragungen durch das gesamte Netzwerk möglich. Mesh-Strukturen haben vor allem
Abbildung 2.1 – Topologie eines Mesh Netzwerkes
Masterarbeit Philipp Zenker 32 Grundlagen im Zuge des Internet of Things erneute Beliebtheit gewonnen. Grund dafür sind eine Reihe von positiven Eigenschaften, die Mesh-Netzwerke mit sich bringen: Mittels Multi-Hop-Übertragung ermöglichen Mesh-Netzwerke eine große Anzahl an Teilnehmern über große Reichweiten zu verbinden. Sie lassen sich theoretisch sehr gut skalieren, wobei dies natürlich stark vom verwendeten Protokoll abhängig ist. Die Skalierung des Netzwerkes kann dabei Einfluss auf die Netzwerkkapazität sowie Dauer und Stabilität der Übertragungen haben. Aufgrund seiner „Selbstkonfigurierbarkeit“ ist der Umbau von Mesh-Netzwerken, bzw. das Hinzufügen oder Entfernen von Netzwerkknoten sehr simpel. Mesh-Netzwerke haben grundlegend außerhalb der Erreichbarkeit des Nachbarn keine weiteren Ansprüche an die Infrastruktur des Netzes und bilden üblicherweise selbstständig Routen mit anderen Knoten in ihrer Reichweite. Dazu fungieren Knoten im Netzwerk grundsätzlich auch als Repeater. Aufgrund des- sen gelten Mesh-Netzwerke als sehr anpassungsfähig und stabil. Die große Anzahl an möglichen Kommunikationsrouten gibt dem Netzwerk ein großes Maß an Redundanz und verhindert „single points of failures“, sofern keine funktechnischen Engpässe, auch „Bottlenecks“ genannt, vorliegen. Ein „Bottleneck“ entsteht, wenn einzelne Knoten die einzigen sind, welche physikalisch verschiedene Gruppen von Knoten im Netzwerk erreichen können. Mesh-Netzwerke werden oftmals auch als „selbst-heilend“ bezeichnet, da aufgrund ihrer Struktur mit der bereits erwähnten hohen Anzahl an möglichen Kommunikationsrouten bei Versagen einer Route einfach auf einen alternativen Kommunikationsweg ausgewichen werden kann. Die dynamische, autonome und selbstkonfigurierbare Natur von Mesh-Netzwerken ist ebenso wie die grundlegende Skalierbarkeit für viele der anvisierten modernen Anwen- dungen von IoT und „Smart Technology“ ideal [6] [7], weswegen Forschungen in diesem Bereich zugenommen haben. 2.2 Over-The-Air Programmierung 2.2.1 Bootloader Over-the-Air Programmierung erfolgt mittels eines „Bootloaders“, einem kleinem Stück Firmware auf dem zu programmierenden Gerät, welches das Over-The-Air-Update Masterarbeit Philipp Zenker 4
2 Grundlagen
(OTAU) regelt und anwendet. Dabei kann sich die Art des Bootloaders je nach Hardware
und Methodik unterscheiden.
Klassisch ist der Bootloader ein kleines Stück Firmware auf dem zu programmierendem
Gerät, welches nach einem Geräteneustart (daher „Boot“) entscheidet, ob die bestehen-
de Applikation geladen wird oder ob in den Update-Modus gewechselt werden muss.
Normalerweise wird dieser Update-Modus durch einen Funkbefehl in der Applikation
ausgelöst. In diesem Modus wird dann die bestehende Firmware (minus des Bootloaders
und Funkstacks) durch eine neu erhaltene ersetzt, wie in Abbildung 2.2 zu sehen ist.
Dieses Verfahren erweist sich zwar als einfach und ressourcensparend, da der üblicher-
weise kleine Bootloader die einzige zur Applikation zusätzliche Speicheranforderung
darstellt, ist jedoch auch sehr risikobehaftet. So können Verbindungsabbruch, Kom-
munikationsfehler oder ein ungeplanter Neustart (zum Beispiel durch Stromausfall)
zum Versagen des OTA-Updates führen, was zur Folge hat, dass das Gerät mit einer
nicht-funktionellen oder fehlerbehafteten Firmware startet. Im schlimmsten Fall kann
dies zum Totalversagen beim Gerät führen. (Im Englischen nennt man dieses dann
„bricked“, d.h. es kann nicht mehr als ein Stein.) Die Möglichkeit zur Wiederherstellung
des vorherigen Firmwarestandes („Rollback“) ist bei diesem Verfahren nicht gegeben.
Abbildung 2.2 – Beispiel einer Bootloader-Architektur
Masterarbeit Philipp Zenker 52 Grundlagen
Ein weiterer Nachteil besteht darin, dass das Gerät seine gewünschte Funktion während
des Updates nicht ausführen kann.
Eine weitere Möglichkeit ist es, Updatefunktionen nicht in einem extra Modus zu
implementieren, sondern in die eigentliche Applikation zu übernehmen. Dies ist möglich,
wenn die Firmware extern gespeichert ist. Aufgrund der besseren Verfügbarkeit größerer
Speicher ist heutzutage ein anderes Verfahren üblich. Anstatt die bestehende Firmware
zu ersetzen, verfügt das Gerät über einen zweiten Applikationsspeicher. Mittels des
Bootloaders kann zwischen den zwei Speichern gewechselt werden, wie Abbildung 2.3
zeigt. Dies ermöglicht nicht nur, die Anwendung während des Updates weiterlaufen
zu lassen, sondern behält auch den derzeitigen Firmwarestand während des Updates
bei, sodass nach einem Versagen des Firmware-Downloads oder bei Fehlern im neuen
Firmwarestand zur alten Version zurück gewechselt werden kann. Dies macht Over-
the-Air Programmierung nicht nur robuster sondern auch weitaus benutzerfreundlicher.
Allerdings ist die Speicheranforderung natürlich signifikant größer, da nicht nur ein
Bootloader, sondern auch doppelt so viel Anwendungsspeicher vorgesehen werden muss.
Abbildung 2.3 – Bootloader-Architekturen mit mehreren Applikationen
Masterarbeit Philipp Zenker 62 Grundlagen 2.2.2 Kodierung & Scope Auch in der Kodierung des Updates gibt es Unterschiede [8]. Klassisch wird die komplette Firmware „as is“ übertragen. Eine mögliche Verbesserung ist dagegen das Nutzen von differenziellen Updates. Anstatt den kompletten, neuen Firmwarestand zu senden, wird stattdessen nur ein Delta zum alten Softwarestand verschickt. Dies ist vor allem bei geringfügigen Änderungen nützlich, da sich die zu versendenden Daten und damit auch die Updatedauer stark verkürzt. Wenn anstatt des gesamten Firmwarestandes nur Differenzen gespeichert werden, könnte auch der benötigte Speicher verringert werden. Allerdings wäre dann der Umfang des Updates eingeschränkt. Zudem erhöht sich bei diesem Verfahren im Vergleich zum vorher genannten die Komplexität, da Geräte die neue, erwünschte Firmwareversion erst noch errechnen müssen. Ein weiterer großer Nachteil ergibt sich bei dynamischen oder verlustbehafteten Netzwerken, bei denen einzelne Geräte womöglich vorherige Updates verpasst haben könnten. Hier würden ihnen die zwischengelagerten Differenzen fehlen. Ab dieser Stelle müssten entweder die verpassten Updates nachgeholt werden oder je nach bestehender Firmwareversion ein neues Datenset zur Verfügung gestellt werden. Ein noch höheres Maß an Effizienz wird bei der Verwendung einer Virtual Machine erreicht. Hier wird ein Skript in einer Programmiersprache eines höheren Levels gesendet, welches dann vom Gerät interpretiert und übernommen werden muss. Der darunter- liegende Interpreter und Funkstack bleiben dabei unangetastet. Dies stellt jedoch ein höheres Maß an Komplexität dar und die Updatemöglichkeiten sind begrenzt: Die im Skript enthaltenen Funktionen müssen bereits im darunter liegenden Stack implementiert sein. Es dient also lediglich zu einem Funktionswechsel im Gerät. Zudem ist die Virtual Machine selber sehr ressourcenlastig. Eine weitere Klassifizierung von OTA-Updates stellt der Scope des Updates dar. Dahinter steht die Idee, nur gewisse Teile der Firmware zu ersetzen. Wenn zum Beispiel Funkstack, bzw. Protokollbibliotheken [9] von der darauf-liegenden Applikation klar getrennt sind (zum Beispiel durch die Definition eines „Application Space“ im Speicher), reicht es oft nur die Applikation selber zu erneuern. Dies kann unabhängig von der weiteren Methodik des Over-the-Air-Programmierung-Verfahrens geschehen. 2.2.3 Verteilungsstrategien Die Methodik des OTA-Updates ist normalerweise stark hersteller- und hardwarespezi- fisch. Größere Freiheit und Varianz gibt es dagegen bei der Verteilungsstrategie von den Masterarbeit Philipp Zenker 7
2 Grundlagen
(a) Neighborhood-by-Neighborhood (b) Routing
(c) Flood
Abbildung 2.4 – Verteilungsstrategien in Mesh-Netzwerken
Firmwaredaten, welche allerdings vom Funkprotokoll abhängig sind. Bei den meisten
Standards ist die OTA-Programmierung nur auf eine One-Hop-Verteilung ausgelegt. Es
gibt allerdings auch Konzepte für Multi-Hop-Verteilungen in größeren Netzen. Dies hat
den Vorteil eine höhere Anzahl Geräte in einem Zug flashen zu können. Bisher hat dies
vor allem bei Sensornetzen (Wireless Sensor Networks), welche oft eine hohe Anzahl
an Teilnehmerknoten mit schlechter Zugänglichkeit aufweisen, Anklang gefunden. Dies
fügt dem Verfahren allerdings ein höheres Maß an Komplexität hinzu. Verlustbehaftete
Kommunikationswege und sich ändernde Netzwerkbedingungen erfordern einen hohen
Aufwand bei Fehlerbehandlung und Kontrollen, sowie ein durchdachtes Konzept für
Sicherheitsvorkehrungen. Im Zuge der Visionen des Internet of Things wird eine Multi-
Hop-Verteilung allerdings nicht zu umgehen sein. Für ein Multi-Hop-OTAP-Verfahren
benötigt es an einer effizienten Verteilungsstrategie. Wie in Abbildung 2.4 zu sehen gibt
es dabei mehrere Ansätze [10]:
• Neighborhood-by-Neighborhood: Beim Neighborhood-Verfahren handelt es
sich praktisch um ein Single-Hop-Verfahren was rekursiv erweitert wird. Ein Gerät
mit den benötigten Programmdaten (Source) sendet diese an im Netz benachbarte
Knoten (Receiver) weiter. Ist dies geschehen, werden die ehemaligen Receiver
Masterarbeit Philipp Zenker 82 Grundlagen
ebenfalls zu Source-Knoten. Ein beliebiger Mechanismus wählt dann einige der
neuen Source-Knoten aus, um die Daten weiterzutragen.
• Routing: Bei Routing-Verfahren werden vor der Übertragung durch einen beliebig
gearteten Algorithmus Sendewege und dafür verantwortliche Repeater-Knoten
ausgewählt. Dies macht die eigentliche Übertragung sehr effizient und möglichst
redundanzfrei. Durch die Wegefindung und aufgrund der Anforderung Netzwerk-,
Knoten- und Nachbarinformationen oder Routingtabellen zu speichern kommt es
allerdings zu einem zusätzlichen Maß an Overhead im Verfahren. Zudem ist es
meist komplexer geartet, nimmt mehr Zeit in Anspruch und braucht längere Zeit
um auf Veränderungen im Netzwerk zu reagieren.
• Flood: Flooding bezeichnet ein simples Verfahren, bei welchem gesendete Nach-
richten von allen Knoten, die diese zum ersten mal hören weitergeleitet werden.
Es zeichnet sich durch seine hohe Redundanz aus, was zwar den Overhead erhöht,
jedoch auch die Stabilität der Übertragung erhöhen kann. Da die Netzwerkkapa-
zität jedoch aufgrund der vielen Wiederholungen stark begrenzt ist, kann es zu
Funktionsbeeinträchtigungen und Skalierungsproblemen kommen.
2.3 Standards
2.3.1 MNP
Multihop Network Reprogramming Protocol (MNP) [11] ist ein für Mica-2/XSM ent-
wickeltes Protokoll zur netzwerkweiten Programmierung über mehrere Hops. MNP ist
für homogene Netzwerke entworfen worden und unterstützt keine selektiven Updates.
Es verfolgt eine Neighborhood-by-Neighborhood-Strategie und umfasst mehrere Modi.
Im ersten Modus werben sogenannte „Source Nodes“ (also Geräte, welche das Update
bereits erhalten haben) in der Advertising Phase mit ihrem Update. Geräte, welche
dieses benötigen senden daraufhin einen Download Request. Sowohl Advertisement als
auch Download Request enthalten dabei die Anzahl der von der Source Node erhalte-
nen Download Requests. Bemerkt eine „Source Node“ dadurch eine andere „Source“
mit einer höheren Anzahl an Requests, legt sie sich schlafen und setzen die folgende
Download Phase aus, wodurch Netzwerküberlastungen vermieden werden. Nach einer
vorgegebenen Anzahl an Advertisements beginnt die Download Phase, in der Source
Nodes das Update an alle in direkter Hörreichweite befindlichen Geräte ausliefern.
Masterarbeit Philipp Zenker 92 Grundlagen Im zweiten Modus, welcher für größere Netzwerke ausgelegt ist, werden die Updatedateien in Segmente aus einer konstanten Anzahl an Paketen unterteilt. Diese Segmente werden dann sequentiell versendet. Download Requests enthalten außerdem ein Bitfeld für die benötigten Pakete des gewünschten Segmentes. Dadurch werden nur die Pakete versendet, welche bei umliegenden Geräten noch fehlen. 2.3.2 Deluge Deluge [12] verfolgt ebenfalls ein Neighborhood-by-Neighborhood-Verfahren. Geräte im Netzwerk senden regelmäßig einen Broadcast mit ihrer Firmwareversion. Stellt ein Netzwerkknoten fest, dass ein Nachbar veraltet ist, antwortet er ihm. Anhand der Antwort kann der veraltete Knoten nun ermitteln, welche Daten ihm fehlen und diese bei dem neueren Knoten anfragen. Die Daten sind dabei in verschiedene „Pages“ zerteilt, welche sequentiell angefragt und übermittelt werden müssen. Knoten, die bereits einzelne Pages haben, können diese auch schon weitervermitteln, um „spatial multiplexing“ zu ermöglichen. Dadurch werden Einzelteile des Updates bereits in anderen Netzwerkteilen weitervermittelt, bevor der komplette Updatevorgang durchlaufen ist. Deluge verfügt außerdem über Mechanismen zum Backoff (also dem Auslassen von Repeats) und eine dynamische Anpassung der Advertisingrate, um die Netzwerkauslastung gering zu halten. Ebenso wie MNP ist Deluge nur für rein homogene Netzwerke gedacht. Es gibt eine hohe Anzahl an möglichen Erweiterungen und Verbesserungen für Deluge, wie zum Beispiel Seluge [13], welches verschiedene Sicherheitslücken im Protokoll schließen soll. 2.3.3 FireCracker FireCracker [14] ist eine vorgeschlagene Kombination aus Routing und Neighborhood-by- Neighborhood-Verfahren. Zunächst soll das Update über einen Routingalgorithmus an mehrere Knoten übermittelt werden. Diese Knoten starten dann als Source-Knoten ein beliebiges Neighborhood-by-Neighborhood-Verfahren. Die Idee ist es durch die Verwen- dung eines Routingverfahrens eine Anzahl an im Netzwerk verteilten Startpunkten für die spätere Verteilung zu haben, um die Robustheit und Geschwindigkeit des Verfahrens zu steigern. Masterarbeit Philipp Zenker 10
2 Grundlagen 2.3.4 Sprinkler Bei Sprinkler [15] müssen zunächst durch einen Algorithmus eine Menge an Source- Knoten ermittelt werden, sodass jeder Knoten im Netzwerk nur maximal einen Hop von einem der Source-Knoten entfernt ist. Jeder Knoten sucht sich den am nächsten liegenden Source-Knoten als Parent aus. Transmissionen sind über ein Time Division Multiple Access (TDMA)-Schema geregelt. Ähnlich wie bei FireCracker werden dann in der sogenannten „Streaming Phase“ die Daten zunächst an die Source-Knoten verteilt. Dies geschieht mittels Broadcasts, wobei die benachbarten einfachen Knoten ebenfalls mithören. Source-Knoten, die Pakete nicht oder fehlerhaft bekommen haben, können diese per Negative Acknowledgement (NACK) neu anfordern. Wenn alle Source-Knoten die Daten vollständig erhalten haben, wird in die „Recovery Phase“ gewechselt. Hier kann ein Knoten per NACK verpasste Pakete vom Parent beantragen. Es ist ebenso wie MNP und Deluge für homogene Netzwerke entwickelt. 2.3.5 Aqueduct Aqueduct [16] basiert auf Deluge und erweitert das Protokoll für die Verwendung in heterogenen Netzwerken. Dies erreicht Aqueduct mittels eines Routing-Algorithmus, welcher verschiedene Nachbarschaften verbinden soll. Dabei wird zwischen „Member“- und „Forwarding“-Knoten unterschieden, also Geräten, welche ein spezifisches Update benötigen und solchen, die es lediglich weiterleiten können. Die Advertisements der Firmwareversion werden bei Aqueduct durchs komplette Netzwerk geflutet, wobei die mi- nimale Hop-Distanz zu einem Knoten mit der aktuellen Firmware-Version vermerkt wird. Benötigte Updates werden dann über diesen Weg minimaler Hop-Distanz übermittelt. 2.4 Bluetooth 2.4.1 Bluetooth Low Energy Bluetooth Low Energy (BLE) erschien mit der Bluetooth Spezifikation 4.0 und dient als energiesparende Alternative zum klassischen Bluetooth. Wie in Abbildung 2.5 zu sehen ist, verfügt es über 40 Kanäle im 2.4GHz ISM-Band, welche in 37 Daten-Kanäle (Kanäle 0-36) und drei Advertising-Kanäle (Kanäle 37-39) unterteilt sind. Jeder Kanal hat eine Bandbreite von 2 MHz, im Gegensatz zu der 1 MHz Bandbreite im klassischen Bluetooth. Die Advertising-Kanäle werden für Broadcasts und zur Herstellung von Masterarbeit Philipp Zenker 11
2 Grundlagen
Abbildung 2.5 – Bluetooth Kanäle im Vergleich zu ausgewählten WLAN Kanälen
nach [17]
Master-Slave-Verbindungen, welche mittels TDMA & Frequency Hopping auf den 37
Daten-Kanälen laufen, verwendet.
Die physikalische Übertragungsrate bei BLE beträgt maximal 1 Mbit/s, was einem
Anwendungsdurchsatz von ca. 0,27 Mbit/s entspricht. Bluetooth Low Energy ist eine
On/Off-Technologie, d.h. dass es sich einen Großteil der Zeit im Schlafmodus befindet,
um den Stromverbrauch zu minimieren. Die Reichweiten bei Bluetooth LE liegen
typischerweise bei bis zu 100 Metern im freien Feld, sowie zwischen 10 und 20 Meter im
Gebäude. BLE unterstützt bei Advertisements Payloadgrößen von bis zu 31 Bytes.
Ursprünglich erlaubte BLE nur den Aufbau von Punkt-zu-Punkt-Verbindungen (1 Master
& 1 Slave) oder Stern-Netzwerken (1 Master & mehrere Slaves). Diese Verbindungen sind
durch das Generic Access Protocol (GAP) geregelt und werden mittels Advertisements
aufgebaut. Die Kommunikation innerhalb der Verbindung erfolgt synchronisiert in beim
Verbindungsaufbau ausgehandelten Zeitschlitzen.
Kern des Kommunikationsprotokolls ist hier das sogenannte Generic Attribute Profile
(GATT). GATT definiert „Services“ und die darin enthaltenen „Characteristics“, also
Datenfelder in simplen „look-up“ Tabellen, welche ausgelesen oder beschrieben werden
können. Die GATT-Zugriffe dienen dann bei Master-Slave-Verbindungen als Basis für die
Kommunikation. Die Bluetooth SIG verwaltet dabei eine Datenbank an vordefinierten
Services und GATT-Profilen, welche von Entwicklern genutzt werden können, um schnell
und interkompatibel Kommunikationsprofile auf ihren Geräten zu erstellen.
2.4.2 Bluetooth 5
Die aktuelle Version der Bluetooth Spezifikation (Bluetooth 5 [3]) wurde am 16. Juni
2016 veröffentlicht. Sie enthielt hauptsächlich Aufrüstungen der Kapazitäten des Blue-
tooth Low Energy Standards, um diesen für IoT-Anwendungen attraktiver zu gestalten.
Bluetooth 5 ist nicht kompatibel mit Chips der Bluetooth 4.x Generation und benötigt
Masterarbeit Philipp Zenker 122 Grundlagen
daher ein Hardware-Upgrade. Der Kernpunkt des neuen Bluetooth 5 Standards sind zwei
neue, in Tabelle 2.1 verglichene Sendemodi: den schnelleren 2 Mbit/s Modus (genannt
2M Phy im Gegensatz zum klassischen 1M Phy) und Bluetooth 5 Coded. Die beiden
Modi können nicht zusammen genutzt werden.
Der 2 Mbit/s Modus ermöglicht die doppelte Bitrate in der Datenübertragung [19].
Dabei büßt er allerdings ein Fünftel seiner effektiven Reichweite ein. Für den 2 Mbit/s
Modus wurde eigens die Modulation im physikalischen Kanal angepasst. Die Modulation
nutzt Gaussian Frequency Shift Keying, bei dem die Symbole als Verschiebungen in
der verwendeten Frequenz moduliert werden. Beim neuen 2 Mbit/s Modus wurde die
Verschiebung von den vorherigen 185 kHz auf mindestens 370 kHz angehoben [3], um
die schnellere Senderate zu unterstützen. Die Sendeleistung bleibt im Vergleich zum
klassischen 1M Phy Modus die selbe, weswegen durch die schnellere Datenübertragung
sogar Strom gespart werden kann.
Der Bluetooth 5 Coded Modus dagegen, soll für die Datenübertragung bei einer geringeren
Bitrate bis zu vierfach größere Reichweiten ermöglichen [18]. Dabei gibt es wiederum
zwei verschiedene Modi, den 500 kbit/s Modus für theoretisch doppelte Reichweite
und den 125 kbit/s Modus, der die mögliche Kommunikationsdistanz vervierfachen soll.
Die Signalreichweite bei Bluetooth meint dabei die effektive Reichweite, bei der bei
einem gegebenen Noise-Level eine Bit Error Rate (BER) von 0,1% nicht überschritten
wird. Bluetooth 5 Coded nutzt zur Erweiterung dieser Signalreichweite einen Forward
Error Correction Code (FEC), um die BER zu reduzieren. Durch diesen Code wird die
physikalisch gesendete Symbolmenge pro Bit an übertragener Dateninformation im Paket
vom vorherigen „unkodierten“ einzelnen Symbol pro Bit auf 2 beziehungsweise 8 Symbole
pro Bit erhöht. Durch die Erhöhung der Symbolmenge erklärt sich dementsprechend
auch die Reduzierung der Bitrate bei gleichbleibender Symbolrate.
Auch die maximale Payloadgröße bei Advertisements wurde erhöht: von den vorherigen
31 auf nun 255 Byte. Dies kann Overhead reduzieren und eignet sich besser zum
1M Phy 2M Phy Coded (S = 2) Coded (S = 8)
Symbolrate 1 Ms/s 2 Ms/s 1 Ms/s 1 Ms/s
Datenrate 1 Mbit/s 2 Mbit/s 500 Kbit/s 125 Kbit/s
Fehlererkennung CRC CRC CRC CRC
Fehlerkorrektur - - FEC FEC
Distanzmultiplikator 1 0.8 2 4
Tabelle 2.1 – Bluetooth 5 Modi [18]
Masterarbeit Philipp Zenker 132 Grundlagen Senden größerer Datenmengen. Die Payloaderhöhung gilt aber nicht für klassische Advertisements, sondern setzt die Nutzung von den neuen sekundären Advertising- Kanäle voraus. Diese „sekundären Advertising-Kanäle“ sind nichts anderes als die 37 Datenkanäle, welche nun auch für Advertisements genutzt werden können, nachdem diese Übertragungen auf den drei primären Advertising-Kanälen angekündigt wurden. Dadurch wird die Belastung der drei Kanäle gesenkt, ohne eine höhere Anzahl von Kanälen scannen zu müssen. Weitere Änderungen bei den Advertisements sind die Möglichkeiten zum „Advertising Packet Chaining“, also einer Segmentierung größerer Datenmenge in mehrere Advertising- Pakete und High Duty Cycle Non-Connectable Advertising, welches das minimale Advertising Interval auf 20ms reduziert. 2.4.3 Bluetooth Mesh Die „Bluetooth Mesh Networking“-Erweiterung des Bluetooth Low Energy Standards wurde am 13. Juli 2017 übernommen [4]. Es handelt sich hierbei grundlegend um eine „Flood Mesh“-Erweiterung von BLE. Bluetooth Mesh Pakete werden als Broadcasts auf den drei Advertising-Kanälen gesendet und von Empfängern im Netzwerk wiederholt, sofern diese als Relay-Knoten konfiguriert sind, wodurch Multi-Hop-Übertragungen ermöglicht werden. Um die Payload-Größe zu erhöhen wird außerdem ein Segmentation and Reassembly Mechanism (SAR), also ein Segmentierungs und Reassemblierungs- Mechanismus, verwendet. Dabei sind Pakete mit maximal 32 Segmenten (mit einer 12 Byte großen Payload pro Segment) erlaubt. Dieses entspricht ohne Header einer Payload- Größe zwischen 377 und 379 Byte. Als Zuordnung zu einem Netzwerk dient bei Bluetooth Mesh die Verschlüsselung der Pakete: Jedes Netzwerk hat seinen eigenen individuellen Netzwerkschlüssel, der als Basis zur Codierung der Pakete dient. Netzwerke können auch Subnetzwerke mit ihren eigenen Netzwerkschlüsseln sowie Applikationsschlüssel, welche nur für spezifische Anwendungen gelten, enthalten. Somit können Nachrichten selbst innerhalb des Netzwerks sicher verschlüsselt übertragen werden. Jedes Gerät erhält bei der Zuordnung zum Netzwerk mindestens eine netzwerkinterne Adresse. Es ist aber auch möglich einem Gerät mehrere Adressen beziehungsweise mehrere „Knoteninstanzen“ zuzuweisen. Dies ist zum Beispiel bei Lampenanordnungen relevant, bei denen jede Leuchte einzeln geschaltet werden kann. Masterarbeit Philipp Zenker 14
2 Grundlagen
Wie in Abbildung 2.6 zu sehen, unterstützt Bluetooth Mesh weiterhin auch das Senden
von Nachrichten über einen Proxy mittels GATT anstatt Advertisements, um auch die
Kommunikation mit Geräten, welche Bluetooth Mesh nicht unterstützen, zu ermöglichen.
Da die Kommunikation über Advertisements asynchron abläuft, sind Teilnehmer dazu
gezwungen einen Großteil der Zeit nach Paketen im Netzwerk zu scannen. Aufgrund
dessen bleibt die Energiesparsamkeit, welche größtenteils durch die Schlafzyklen gewon-
nen wurde, nicht erhalten. Jedoch können „Low Power Nodes“, also Geräte, welche auf
die sparsame Natur BLEs angewiesen sind, durch das „Friend feature“ an das Mesh
Netzwerk angebunden werden. Dabei bauen sie eine Verbindung mit einem vollwertigen
Knoten im Netzwerk auf, dem sogenannten „Friend Node“, über welchen Sie dann die
Pakete im Mesh-Netzwerk erhalten und senden können. Die „Friend Node“ speichert
dabei alle Nachrichten, welche an die verbundene „Low Power Node“ gehen, bis diese
von ihr abgefragt werden. Die Unterstützung des „Friend Features“ ist dabei allerdings
optional.
Abbildung 2.6 – Topologie im Bluetooth Mesh Netzwerk [4]
Wie auch schon bei Bluetooth Low Energy mit GATT-Profilen gibt es bei Bluetooth Mesh
eine Reihe von der Bluetooth SIG definierten Models, welche bestimmte weitverbreitete
Funktionalitäten enthalten. Zum Beispiel gibt es das Licht-Model, welches zur Einstellung
von Leuchten und Lampen dient oder das Schalter-Model, welches einen einfachen On/Off-
Mechanismus implementiert. Zusätzlich gibt es auch noch die von Herstellern selber frei
definierten Vendor Models. Bluetooth Mesh Pakete enthalten einen Model Identifier zur
Zuordnung zu den verschiedenen Models, welcher entweder 16 Bit für die Bluetooth
Standard Models oder 32 Bit für die Vendor Models groß ist. Innerhalb eines Models
werden Nachrichten anhand des ebenfalls im Paket inbegriffenen Opcodes unterschieden,
welcher je nach Typ 1 bis 3 Byte groß ist.
Masterarbeit Philipp Zenker 152 Grundlagen „Flood Mesh“-Netzwerke leiden oftmals unter einem als „Broadcast Storm“ bekanntem Problem. Damit wird die endlose Übertragung eines einzelnen Paketes bezeichnet wenn es im Netzwerk von Knoten ständig wiederholt wird. Um das „Broadcast Storm“- Problem zu vermeiden, also die Wiederholung der Pakete einzugrenzen, gibt es zwei Mechanismen: Time-to-live (TTL) und Message Caching. TTL ist eine im Mesh-Paket mitgesendete Zahl, die bei jeder Paketwiederholung herunter gezählt wird. Es begrenzt also die maximale Anzahl an Hops, die ein Paket durch das Netzwerk nehmen kann. Dies dient zum einem als harte Grenze für die Lebensdauer des Paketes, kann aber auch zur lokalen Eingrenzung von Übertragungen genutzt werden. Dies kann bei sehr großen Netzwerken Anwendung finden, um die Netzwerkkapazitäten nicht übermäßig zu beanspruchen. Mit Message Caching wird das temporäre Speichern empfangener Mesh-Pakete bezeich- net, welche mit neu-empfangenen Paketen verglichen werden können, um ein doppeltes Weitersenden zu verhindern. Der Speicherplatz hierfür ist natürlich begrenzt, weswegen die Message Caching Methode auch nur temporär hilft. Bei einem späteren Empfang einer alten Nachricht jedoch greift die Message Replay Protection. Diese bezeichnet den Schutz gegen das wiederholte Senden des gleichen Paketes. Dies dient primär nicht zum Schutz gegen redundante Nachrichtenwiederholungen sondern vor allem gegen sogenannte Replay Attacken (siehe Sektion 4.2). Der offizielle Bluetooth Mesh Standard ist nicht nur für Bluetooth 5 entworfen worden und kann auch mit den älteren BLE 4.0/4.1/4.2 Versionen verwendet werden. Dies stellt die Frage wie viele der neuen Bluetooth 5 Kapazitäten überhaupt bei Bluetooth Mesh Anwendung finden. Die Verwendung des 2M Phy Modus oder von Bluetooth 5 Coded, sowie der sekundären Advertisements sind zwar nicht explizit ausgeschlossen, aber doch klar zum Zweck der Kompatibilität derzeit noch nicht Teil des Konzeptes von Bluetooth Mesh. Masterarbeit Philipp Zenker 16
Kapitel 3
Anwendungsfälle
3.1 Netzwerkeigenschaften
Um ein Konzept für OTAP in Bluetooth 5 Mesh-Netzwerken zu entwickeln, sollten
zunächst die konkreten Ansprüche daran geklärt werden. Dazu ist es hilfreich eine
Reihe von möglichen Anwendungen zu definieren und zu besprechen. Zur Beschreibung
der Anwendungsfälle sollten jedoch zunächst konkrete Eigenschaften festgelegt werden,
anhand derer die Herausforderungen bei einem OTAP-Mechanismus geklärt werden
können. Dabei sind einige für die zu besprechenden Anwendungen von besonderer
Relevanz:
• Netztopologie: Mit Netztopologie sei die Anzahl und Verteilung der Bluetooth-
Knoten gemeint. Höhere Entfernungen zwischen einzelnen Geräten führen (abhän-
gig vom Umfeld) aufgrund der Freiraumdämpfung zu schwächeren Kommunikati-
ons-Links, was diese anfälliger für Störungen macht. Sind die Geräte jedoch nah
beieinander, sprich das Netzwerk hat eine höhere Dichte, so sind zwar gesendete
Pakete am Empfänger stärker zu sehen, aber die höhere Anzahl an Nachbarn kann
auch zu vermehrten Kommunikationskonflikten innerhalb des Netzwerkes führen
[20]. Dies ist vor allem bei Flutverfahren wie Bluetooth Mesh der Fall. Dasselbe
Problem ergibt sich auch bei größeren Knotenmengen. Allerdings steigen bis zu
einem gewissen Punkt die Abdeckung und Übertragungssicherheit des Netzwer-
kes. Es gilt jedoch: Desto mehr Geräte im Netzwerk, umso mehr machen sich
Skalierungsprobleme bemerkbar. Da bei Bluetooth Mesh Pakete von Teilnehmern
wiederholt werden, wird das Netzwerk bei einer größeren Anzahl an Geräten von
einem einzelnen Paket auch stärker belastet. Das bedeutet, dass die Netzwerkka-
Masterarbeit Philipp Zenker 173 Anwendungsfälle
pazität sinken kann, wenn sich die Anzahl an Geräten und die Netzwerkdichte
erhöhen.
• Netzgebrauch: Hierbei ist die Funktionalität im Normalbetrieb des Netzwerkes
gemeint. Wichtigster Punkt hierbei sind die Kommunikationen. Ist die Kommu-
nikationsmenge zum Beispiel sehr hoch, lässt das weniger freie Kapazitäten für
weiteren Datenaustausch über. Durch das Update können Kommunikationen durch
Interferenzen gestört und damit der Datenaustausch verlangsamt oder komplett
verhindert werden. Je nach Anwendung kann sich die Dringlichkeit und Wichtigkeit
der Kommunikationen für die Aufgaben des Netzwerkes unterscheiden. Hierbei
muss entschieden werden, ob Kommunikationsstörungen und Ausfälle im Netzwerk
vertretbar sind. Aber auch die Zeiten und Periodizität der Kommunikation sind
von Bedeutung. Zum Beispiel könnte das Netzwerk je nach Funktion bestimmte
Zeiten hoher Aktivität haben (zum Beispiel tagsüber), danach allerdings ruhig
bleiben, was wiederum als Zeit für die Updates genutzt werden kann. Ein weiterer
Punkt können Aufgaben der zu programmierenden Netzwerkteilnehmer sein, die
eventuell durch Empfang, Weiterleitung und Verarbeitung der Updatedaten unter-
brochen werden könnten. Vor allem zeit- und rechenleistungsintensive Aufgaben
sind hier empfindlich für Störungen. Aber auch Funktionen mit engen Timings,
wie zum Beispiel serielle Kommunikationen oder gewisse Messaufgaben könnten
beim Update-Prozess unter- oder abgebrochen werden. Wenn die Funktionalität
auch während des Updates aufrechtgehalten werden soll, müssen dementsprechend
an die vorliegenden Bedingungen angepasste Vorkehrungen getroffen werden.
• Netzmanagement: Hiermit seien die vorhandenen Methoden und das erwartbare
Knowhow zur Verwaltung des Netzwerkes gemeint. Im Konsumerbereich zum Bei-
spiel ist das Knowhow eher gering und Funktionen müssen größtenteils autonom
und automatisch ablaufen. Auch die Informationen über die im Netz befindlichen
Geräte und deren Anforderungen können größtenteils unbekannt sein. Im industri-
ellen Bereich dagegen sind Netzwerke typischerweise mehr durchgeplant. Geplante
Netzwerke können auf verschiedene Weisen optimiert sein. Im Falle von Flood-
Mesh-Netzwerken wie Bluetooth Mesh ist dies zum Beispiel durch die Selektion von
Relay-Knoten der Fall. Bei zu vielen Relay-Knoten können sich diese gegenseitig
stören und die Netzwerkkapazität beschränken. Bei zu wenigen dagegen kann die
Übertragungssicherheit oder die physikalische Abdeckung im Raum beeinträchtigt
sein. Weiterhin können Bottlenecks und Funklöcher vermieden werden. Über die
Netzwerkplanung hinaus erlaubt ein aktives Netzwerkmanagement Anpassungen
der Updateprozedur vorzunehmen, um diese optimal für die entsprechende An-
Masterarbeit Philipp Zenker 183 Anwendungsfälle
wendung zu gestalten. So können zum Beispiel Updatezeiten so angepasst werden,
um kommunikationsintensive Zeiten im Netzwerk zu vermeiden.
• Umfeld: Auch das Umfeld des Netzwerkes kann starken Einfluss auf seine Kommu-
nikationen nehmen. Hierbei gibt es zwei Hauptpunkte die betrachtet werden müs-
sen. Als erstes wäre das tatsächliche physikalische Umfeld zu nennen. Durch dieses
kommt es hier zu räumlichen Unterschieden in den Signalstärken, beziehungsweise
den Rauschstärken. Dies wird als Signal-to-Noise-Ratio (SNR) zusammengefasst.
Hierbei nimmt das physikalische Umfeld auf verschiedene Arten Einfluss. Durch
Hindernisse, wie Wände, werden Signale gedämpft. Durch Reflexionen und Bre-
chungen kommt es zur Multipfadausbreitung, was wiederum das Signal stören
kann. Je nach Standort kann das Umfeld mehr oder weniger dynamisch sein. In
einem bewohnten Haus zum Beispiel werden durch sich bewegende Menschen
und Öffnen oder Schließen von Türen und Fenstern die Verhältnisse im Raum oft
verändert. Der zweite Hauptpunkt ist die Koexistenz zu anderen Funktechnologien.
Dies fällt ins Gewicht, wenn die von der Anwendung genutzten Frequenzbänder
auch durch andere Funktechnologien genutzt werden. Dies kann schnell zu Stö-
rungen führen. Neben anderen Funktechnologien können vor allem im 2,4 GHz
Band auch anderweitig Störsender entstehen. Als klassisches Beispiel gelten hier
Mikrowellen, welche ebenfalls mit Frequenzen von 2,4 GHz funktionieren. Das
klassische Bluetooth verlässt sich dabei auf „Frequency Hopping“, also dem ra-
piden Wechsel der Kanäle. Im Falle von Bluetooth Mesh werden jedoch nur die
drei Advertising-Kanäle genutzt, was weniger Spielraum zum Ausweichen anderer
Funkanwendungen lässt. Die drei Kanäle sind jedoch an unterschiedlichen Stellen
im 2,4 GHz Band und so gewählt, um den üblicherweise genutzten WLAN-Kanälen
zu entgehen. Wie in Abbildung 2.5 zu sehen ist, wurden dabei jedoch hauptsächlich
die in der USA üblichen (1, 6 und 11) anstatt der in Europa genutzten Kanäle (1,
5, 9 und 13) beachtet.
• Mobilität: Hiermit sei gemeint, wie schnell und oft sich die Netztopologie durch
hohe Mobilität bei den Geräten ändert. Dies kann dazu führen, dass sich Kom-
munikationswege im Netzwerk rapid ändern. Die Funkverbindungen zwischen
Teilnehmern können in ihrer Übertragungsqualität stark schwanken oder zu Zeiten
sogar komplett verschwinden oder neu hinzukommen. Aufgrund der Nutzung aller
möglichen Kommunikationswege, ist die eigentliche Position eines Gerätes im
Netzwerk bei „Flood Mesh“-Netzwerken von geringer Relevanz. Das Updatever-
fahren jedoch muss damit umgehen können, dass ein Gerät zeitweise nicht mehr
zu erreichen ist.
Masterarbeit Philipp Zenker 193 Anwendungsfälle
3.2 Anforderungskriterien
Um mögliche Anwendungsfälle analysieren zu können, muss zunächst geklärt werden,
welche Bewertungskriterien bei einem OTAP-Verfahren Beachtung finden sollen. Inner-
halb dieser Kriterien müssen dann für die unterschiedlichen Szenarien Gewichtungen
und Ansprüche definiert werden. Die Bewertung findet anhand folgender Eigenschaften
statt:
• Updatedauer: Die Zeit welche für einen OTAP-Vorgang benötigt wird. Dies ist
abhängig von der Größe des Updates und der Größe des Netzwerkes, bzw. der
Anzahl an zu programmierenden Geräten. Ein Multi-Hop-OTAP-Verfahren kann
vor allem bei größerer Anzahl an zu programmierenden Geräten einen Vorteil
gegenüber herkömmlichen Methoden über Punkt-zu-Punkt-Verbindungen aufwei-
sen, wobei dieses stark von der Skalierbarkeit des Verfahrens und des Netzwerkes
abhängig ist.
• Robustheit: Mit Robustheit oder Störresistenz ist die Fähigkeit des Verfahrens
gemeint, mit Fehlerfällen umzugehen. Dies umfasst den Umgang mit schlechten
und sich verändernden Netzwerkverbindungen, Ausfällen von Netzwerkteilnehmern
und korrupter oder fehlerbehafteter Firmware. Das Verfahren muss in der Lage sein
selbstständig etwaige Fehler erkennen und beheben zu können. Die Möglichkeit
zum Rollback zur vorherigen Firmware-Version oder einem speziellem Backup-
Image im „Worst Case“ ist dabei ein wichtiges Mittel, um zu verhindern, dass das
Gerät unbenutzbar wird. Am entscheidendsten ist dabei die Aufrechterhaltung
des Update-Verfahrens.
• Netzauslastung: Die Updates in OTAP-Verfahren können sehr groß sein. Daraus
folgt natürlich eine hohe Anzahl an zu versendenden Paketen. Hinzu kommt eine
durch das Verfahren geforderte Menge an Overhead (z. Bsp. Acknowledgements
oder Advertisements). Dadurch kann es zu einer hohen Auslastung der Netzwerk-
kapazitäten kommen. Es muss darauf geachtet werden, diese Kapazitäten nicht
übermäßig zu beanspruchen, da dies Kommunikationsstörungen innerhalb des
Netzwerkes verursachen kann.
• Netzfunktionalität: Während des Update-Vorganges kann es zu Einschränkun-
gen oder sogar zum Totalausfall der Netzwerkfunktionen kommen. In manchen
Anwendungen ist aber die Weiterführung der Netzwerkfunktion erwünscht oder
sogar unbedingt erforderlich. Dabei muss auch auf eine geringe Netzauslastung
Masterarbeit Philipp Zenker 203 Anwendungsfälle
geachtet werden und steht normalerweise im Widerspruch zu Anforderungen an
die Updatedauer.
• Selektivität: Eventuell muss bei Anwendungen eine Selektivität des Updates
ermöglicht sein. Dies ist bei heterogenen Netzwerken, d.h. Netzwerke aus Geräten
mit unterschiedlicher Hardware oder Funktionen, immer der Fall, da sich hier die
benötigte Firmware unterscheidet. Aber auch bei homogenen Netzen kann daran
gelegen sein, nur bestimmten Gruppen ein Update zu übermitteln. Dies muss im
Vorgehen beachtet werden.
• Autonomie: Vor allem bei Konsumelektronik bedarf es ein hohes Maß an Auto-
nomie im Verfahren. Das heißt, dass der Nutzer selbst möglichst wenig manuell
bedienen muss. Der Updatevorgang sollte größtenteils automatisch ablaufen. Daher
wird ein gewisses Maß an Selbstkonfigurierbarkeit vor und während des Upda-
tes benötigt. Aber vor allem auch im Fehlerfall müssen die Geräte selbstständig
handeln können.
• Ressourcenbedarf: Sensormodule und batteriebetriebene Elektroniken sind
meist aus Kostengründen eher ressourcensparend ausgelegt. Hohe Speicheranforde-
rungen können deshalb störend wirken. Auch lange Rechenzeiten bei Verwendung
von Kodierungs- und Verschlüsselungsverfahren sowie lange Scan- und Sendezeiten
müssen bei batteriebetriebenen Geräten aufgrund des Stromverbrauchs beachtet
werden.
• Komplexität: Komplexität stellt zwar in den Anwendungen selber direkt weniger
ein Kriterium dar, wohl aber im Entwicklungsprozess der Geräte. Dort bedeu-
tet höhere Komplexität oftmals auch höhere Kosten. Bei Geräten mit geringen
Ressourcen oder Konsumelektronik, bei denen kurze Markteinführungszeiten und
Entwicklungskosten wichtige Punkte darstellen, ist das Ausmaß der Komplexität
des Verfahren durchaus relevant.
• Sicherheit: Im Zuge des Internet of Things wurde dieser kritische Punkt bereits oft
erwähnt. Vorkehrungen gegenüber bösartigen Angriffen auf das Netzwerk sind meist
unbedingt erforderlich. Da diese Sicherheitsvorkehrungen jedoch oftmals extra
Overhead und Prozeduren erfordern, muss auch an dieser Stelle Sinn und Zweck
mit den Nachteilen der dadurch hinzugewonnenen Komplexität abgewogen werden.
Aufgrund der Verwendung eines geteiltes Mediums kann die Funkkommunikation
jedoch nie vollständig gegen Störungen gesichert werden.
Masterarbeit Philipp Zenker 213 Anwendungsfälle
• Kompatibilität: Eine der grundlegenden Charakteristiken von Bluetooth ist
die Anforderung an Kompatibilität zwischen verschiedenen Bluetoothprodukten
verschiedener Hersteller. Derselbe Anspruch kann auch beim Update-Verfahren
eine hohe Bedeutung spielen.
• Skalierbarkeit: Mit Bluetooth Mesh sollen Netzwerke von potentiell Tausenden
an Geräten möglich werden. Dies erfordert besondere Aufmerksamkeit beim Design
des OTAP-Verfahrens. Eventuell müssen Vorkehrungen getroffen werden, um auch
bei sehr großen Netzwerken fehlerfrei arbeiten zu können.
3.3 Anwendungsszenarien
Zur Konzeption eines passenden Update-Verfahrens muss geklärt werden, in welchen
Anwendungen Bluetooth Mesh am wahrscheinlichsten eingesetzt wird. Dazu werden
verschiedene Anwendungsszenarien erstellt und die daraus resultierenden Anforderungen
erfasst. Die möglichen Anwendungen für Bluetooth Mesh sind vielfältig. Besonders
geeignet ist Bluetooth Mesh für Anwendungen mit geringen zu übertragenden Daten-
mengen, flexiblen und/oder großen Netzwerken und gewünschtem Smartphone-Zugriff.
Die folgenden Anwendungen sollen nicht die Gänze an Möglichkeiten abdecken, sondern
die für Bluetooth Mesh charakteristischsten Beispielszenarien darstellen.
3.3.1 Smart Home
Die typische IoT-Anwendung liegt im Bereich der Gebäudeautomatisierung, dem „Smart
Home“ [21]. Wie in Abbildung 3.1 dargestellt ist, werden durch eine Vielzahl an Sensoren
und Kontrollelementen unter anderem Beleuchtung, Lüftung und Heizung selbststän-
dig eingestellt. Die Geräte, welche Teil des „Smart Home“-Netzwerkes sind, werden
„kontextbewusst“, d.h. sie können automatisch Entscheidungen anhand des Zustandes
ihrer Umgebung treffen. Zum „Smart Home“-Umfeld gehören auch sicherheitsrelevante
Anwendungen, wie Rauch- und Feuermelder, Alarmsysteme und elektronische Türschlös-
ser. Auch Online-Anbindungen über Gateways oder entsprechend aufgerüstete Router,
beziehungsweise eine Anbindung an einen internetfähigen Rechner sind nicht unüblich.
Obwohl es sich beim klassischen „Smart Home“-Beispiel um einen Privathaushalt han-
delt, sind „Smart Home“-Anwendungen auch zum Beispiel bei öffentlichen Gebäuden
oder Geschäften denkbar. So könnte beispielsweise ein Hotel von Automatisierung und
Masterarbeit Philipp Zenker 22Sie können auch lesen
