Bachelorarbeit paul gerber.pdf

Integration des RACA-Frameworks in die
OMNeT++ - Simulationsumgebung
Bachelorarbeit
zur
Erlangung des akademischen Grades
B.Sc.
Fakultät für Informatik
Professur Technische Informatik
Eingereicht von: Paul Gerber
Matrikel Nr.: 340249
Einreichungsdatum: 12.12.2018
Betreuer: Prof. Dr. Wolfram Hardt
Dipl.-Inf. Mirko Lippmann

Abstract
In der vorliegenden Bachelorarbeit soll ein Framework zur Umsetzung des Resource-
based Application Clustering Approach in die OMNeT++/INET Simulationsumge-
bung integriert werden. Der Ansatz verfolgt das Ziel, Anwendungen in einem ver-
teilten Sensornetzwerk in einem Cluster geeigneter Knoten zu verteilen. Ausgewählt
werden sollen diejenigen Knoten, die über die besten Ressourcen verfügen. Als
Grundlage für die Integration dient eine Implementierung auf einem Mikrocontroller-
basierten Demonstrator. Dieses Framework wurde erfolgreich in die INET-
Modellbibliothek integriert. Als Ergebnis entsteht auërdem ein Szenario, indem ein
Netzwerk Anwendung durch das integrierte Framework verteilt. Die vorliegende Ar-
beit kann als Grundlage für die weitere Evaluierung des Resource-based Application
Clustering Approach genutzt werden.
Sensornetzwerk, Clustering, Simulation, OMNeT++, INET
2

Inhaltsverzeichnis
Inhaltsverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Abbildungsverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Tabellenverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Listings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Abkürzungsverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2 Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2 Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1 Sensornetzwerke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.1 Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.2 Einsatzgebiete . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.1.3 Herausforderungen und Probleme . . . . . . . . . . . . . . . . 20
2.1.4 Aktuelle Lösungen . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2 Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2.1 Was ist Simulation? . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2.2 Das Simulations-Framework OMNeT++ . . . . . . . . . . . . 27
3 Integration des RACA-Frameworks . . . . . . . . . . . . . . . . . . . . . 36
3.1 Die Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.2 Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.2.1 Die RacaFramework-Klasse . . . . . . . . . . . . . . . . . . . 41
3.2.2 Das RacaNode-Modul . . . . . . . . . . . . . . . . . . . . . . 51
4 Modellierung eines Szenarios . . . . . . . . . . . . . . . . . . . . . . . . 55
4.1 Beschreibung des Szenario . . . . . . . . . . . . . . . . . . . . . . . . 55
4.2 Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.2.1 Die Anwendungsklassen . . . . . . . . . . . . . . . . . . . . . 57
4.2.2 Das Sensormodul . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.2.3 Das Netzwerk . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3

INHALTSVERZEICHNIS
5 Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.1 Initialisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.2 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
6 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Literaturverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Anhang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4

Abbildungsverzeichnis
2.1 Sensor-Aktuator-Kreis . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2 Aufbau eines Sensorknotens, Modell . . . . . . . . . . . . . . . . . . . 14
2.3 Sensornetzwerk mit Gateway . . . . . . . . . . . . . . . . . . . . . . . 15
2.4 OSI-Referenzmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.5 Schematischer Vergleich gerichteter und ungerichteter Antennen . . . 22
2.6 Vergleich von kontinuierliche und diskreter Wertänderung . . . . . . . 27
2.7 Die grundlegende OMNeT++ Modulstruktur . . . . . . . . . . . . . . 29
2.8 Struktur der INET Modell-Bibliothek . . . . . . . . . . . . . . . . . . 31
2.9 Das Basis-Radio-Modul . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.10 Die INET-Paket-Struktur . . . . . . . . . . . . . . . . . . . . . . . . 33
2.11 Das Sensorknoten-Modell der INET-Bibliothek . . . . . . . . . . . . 34
3.1 Die Klasse RacaFramework als Schnittstelle zwischen Simulationsum-
gebung und den Komponenten . . . . . . . . . . . . . . . . . . . . . . 41
3.2 Das NodeBase-Modul . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.3 Das Ieee802154NarrowbandInterface-Modul . . . . . . . . . . . . . . . 52
3.4 Das RacaNode-Modul . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.1 Grundriss des Szenarios . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.2 TempControl: handleMessage, Überblick . . . . . . . . . . . . . . . . 60
4.3 TempMeasure: handleMessage, Überblick . . . . . . . . . . . . . . . . 62
4.4 Temperaturkarte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.5 Netzwerk mit 100 Sensorknoten . . . . . . . . . . . . . . . . . . . . . 66
5.1 Aufteilung der Szenariofläche . . . . . . . . . . . . . . . . . . . . . . 69
5.2 Stromaufnahme Sensorknoten mit Wakeup-Receiver . . . . . . . . . . 70
5.3 Stromaufnahme Sensorknoten ohne Wakeup-Receiver . . . . . . . . . 71
5.4 Anwendungsverteilung unter Nutzung des RACA-Frameworks . . . . 72
5.5 Netzwerk ohne Anwendungsverteilung . . . . . . . . . . . . . . . . . . 73
5

Tabellenverzeichnis
3.1 Coordinator-App-Entry-Struktur . . . . . . . . . . . . . . . . . . . . 37
3.2 Application-Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.3 Paket-Typen im RACA-Framework . . . . . . . . . . . . . . . . . . . 40
6

Listings
2.1 Interface-Beispiel in NED . . . . . . . . . . . . . . . . . . . . . . . . 29
2.2 Beispiel für Vererbung in NED . . . . . . . . . . . . . . . . . . . . . . 30
2.3 Beispiel für Implementierung der Kernel-Schnittstellen . . . . . . . . 30
3.1 Modulreferenzen im Konstruktor der RacaFramework-Klasse . . . . . 42
3.2 Timer-Initialisierung im Konstruktor der RacaFramework-Klasse . . . 42
3.3 Die sendPacket-Methode Teil 1 . . . . . . . . . . . . . . . . . . . . . 43
3.4 Die sendPacket-Methode Teil 2 . . . . . . . . . . . . . . . . . . . . . 44
3.5 Die enterSleep-Methode . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.6 Modifikation der sendUp-Methode . . . . . . . . . . . . . . . . . . . . 47
3.7 Die scheduleTimer- und die cancelTimer-Methode . . . . . . . . . . . 48
3.8 Die getMacAddress-Methode . . . . . . . . . . . . . . . . . . . . . . . 49
3.9 Parameterzuweisungen im RacaNode-Modul . . . . . . . . . . . . . . 53
4.1 Die setPositions-Methode . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.2 Die SimpleCcEnergyConsumer-Klasse . . . . . . . . . . . . . . . . . . 63
4.3 Die rgbToTemp-Methode . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.1 omnet.ini Teil 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.2 omnet.ini Teil 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
7

Abkürzungsverzeichnis
ASIC Application-Specific Integrated Circuit
DHCP Dynamic Host Configuration Protocol
FPGA Field-Programmable Gate Array
RACA Ressource-based Application Clustering Approach
HTML Hypertext Markup Language
RAM Random Access Memory
SQL Standard Query Language
WLAN Wireless Local Area Network
8

1 Einleitung
1.1 Motivation
Sensornetzwerke sind ein sehr flexibles Instrument zur Datenmessung in sehr großen,
schwer zu erreichenden oder gefährlichen Gebieten.
Ein sehr wichtiger Aspekt beim Entwurf und Betrieb von Sensornetzwerken ist die
effiziente Nutzung der vorhandenen Ressourcen. Der in [14] und [15] beschriebene
Resource-based Application Clustering Approach (RACA) hat das Ziel, Ressourcen
durch die Verteilung einer Anwendung optimal zu nutzen. E sollen zunächst die Be-
griffe Anwendung und Cluster geklärt werden.
Die Anwendung, die ein Sensornetzwerk ausführt, ist allgemein die Erhebung von
Messwerten. Eine Anwendung kann durch Parameter genauer charakterisiert wer-
den. Sie könnte demnach u.a. Messwerte in einem bestimmten Bereich erheben,
Messwerten einer bestimmten physikalischen Größe erheben, oder nur Messwerte an
eine Datensenke senden, die einen Referenzwert überschreiten.
Clustering bedeutet, dass mehrere Sensorknoten zu Clustern, auf deutsch Bündel,
zusammengefasst werden. Ein Cluster kann z.B. durch nahe beieinander liegende
Knoten gebildet werden, oder durch Knoten die für die Ausführung einer Anwen-
dung geeignet sind.
Werden in einem Sensornetzwerk Anwendungscluster mit geeigneten Knoten gebil-
det, müssen diese nicht notwendigerweise räumlich nah beieinander liegen. In einem
solchen Anwendungscluster kann eine Anwendung verteilt werden. Jeder Knoten ist
zur Ausführung geeignet, aber es müssen eventuell nicht alle Knoten die Anwen-
dung ausführen, um die erwünschten Ergebnisse zu erzeugen. Es können diejenigen
Knoten ausgewählt werden, die über die besten Ressourcen verfügen. Durch diese
Verteilung soll eine optimale Ausnutzung der Ressourcen und somit auch eine länge-
re Lebenszeit erreicht werden. Die Lebenszeit de Netzwerks ist die Zeit, in der es
alle Anwendungen ausführen kann. Dies ist dann nicht mehr gegeben, wenn in einem
Anwendungscluster kein aktiver Knoten mehr ist.
Damit gezeigt werden kann, dass dieser Ansatz die Laufzeit eines Sensornetzwerks
verbessert, muss er über einen ausreichend langen Zeitraum an einem Netzwerk ge-
testet werden. Um dies schneller und kostengünstiger zu testen, als mit einem realen
Netzwerk, gibt es Simulatoren. Diese ermöglichen es, Sensornetzwerke zu modellie-
ren und deren Betrieb zu simulieren. Dabei können auch große Zeitspannen in relativ
kurzer Zeit simuliert werden.
In dieser Arbeit soll ein Framework, das RACA auf einem Mikrocontroller-basierten
Demonstrator implementiert, in die OMNeT++-Modellbibliothek INET [2] inte-
9

1 Einleitung
griert werden. Das bestehende Framework ist in C geschrieben, die Simulations-
bibliothek OMNeT++ [5] jedoch in C++. Bei der Integration soll das RACA-
Framework C-kompatibel bleiben, um Änderungen und Erweiterungen leicht auf
eine Mikrocontroller-basierte Umgebung zurück zu übertragen.
Zusätzlich wird in dieser Arbeit ein Szenario erstellt, in dem ein Sensornetzwerk
modelliert wird, welches nach dem Resource-based Application Clustering Approach
Anwendungscluster bilden und Anwendungen darin verteilen wird. Dazu wird das in-
tegrierte Framework genutzt. Mit dem Szenario soll gezeigt werden, wie das RACA-
Framework genutzt werden kann und welche Auswirkungen es auf das Verhalten des
Netzwerks hat.
1.2 Aufbau der Arbeit
In diesem Abschnitt wird der Aufbau dieser Arbeit beschrieben und die Inhalte der
Kapitel kurz zusammengefasst.
In Kapitel 1 wird eine Einführung in das Thema der Arbeit gegeben und das Ziel
der Arbeit dargestellt.
Kapitel 2 ist in zwei Teile gegliedert. Teil 1 betrachtet den Aufbau von Sensoren,
Sensorknoten und Sensornetzwerken sowie die Einsatzgebiete von Sensornetzwerken
und möglichen Probleme und Lösungsansätze beim Einsatz von Sensornetzwerken.
In Teil 2 wird die zur Simulation genutzte C++-Bibliothek OMNeT++ und die
Modellbibliothek INET vorgestellt.
Die Integration des RACA-Frameworks in die INET-Modellbibliothek wird in Kapi-
tel 3 beschrieben. Das Kapitel startet dazu mit einer Beschreibung der im Framework
verwendeten Komponenten. Es folgt die Erklärung der implementierten Schnittstel-
len zwischen den Modulen der OMNeT++/INET Bibliothek und den C-kompatiblen
Komponenten des RACA-Frameworks.
In Kapitel 4 wird ein Szenario beschrieben, welches das integrierte RACA-Framework
nutzt. Es zeigt die Anwendung der in Kapitel 3 implementierten Schnittstellen. An-
hand dieses Szenarios soll die Funktionsweise des RACA-Frameworks simuliert und
nachvollzogen werden können.
Zur Veranschaulichung der Funktionsweise, werden in Kapitel 5 ausgewählte Ergeb-
nisse vorgestellt. Kapitel 6 fasst das Vorgehen und die Ergebnisse in dieser Arbeit
abschließend kurz zusammen und gibt einen Ausblick, wie diese Ergebnisse weiter
genutzt werden können.
10

2 Grundlagen
2.1 Sensornetzwerke
2.1.1 Aufbau
Sensoren
Die Sensoren sind die namensgebende Komponente von Sensornetzwerken und sol-
len deshalb zunächst separat betrachtet werden.
Die Aufgabe eines Sensors ist das Sammeln von Informationen aus seiner Umge-
bung, das Messen von Daten. Diese Informationen treten in der Umwelt als Energie
auf. Es gibt verschiedene Energieformen, zum Beispiel thermische, potentielle oder
kinetische Energie, aus denen Informationen gewonnen werden können. Damit die
Informationen durch Prozessoren weiter verarbeitet werden können, müssen diese in
elektrische Energie umgewandelt werden.
Zwischen der Umwandlung der Energie durch den Sensor und der Verarbeitung der
Information durch einen Prozessor erfolgen noch zwei weitere Schritte. Zum einen
wird die elektrische Energie in Form eines Signals aufbereitet. Das bedeutet zumeist
die Anpassung der Stärke des Signals und die Filterung des Signals um ungewünsch-
te Frequenzen zu entfernen. Zum anderen muss das analoge Signal des Sensors durch
einen Analog-Digital-Wandler in ein digitales Signal konvertiert werden [8].
Sensoren können nach der Art der Datenmessung in zwei Gruppen eingeteilt werden.
Die erste Gruppe sind passive Sensoren. Sie lassen sich nochmals unterteilen nach
gerichteten und ungerichteten Sensoren. Ein typischer gerichteter Sensor ist eine
Kamera. Sie kann nur erfassen, was innerhalb des Sichtfeldes liegt. Ungerichtete
Sensoren können dagegen Daten in jede Richtung messen. Dazu gehören zum Bei-
spiel Thermometer, Feuchtigkeitssensoren, Mikrophone oder Strahlungsmesser.
Zu der zweiten Gruppe zählen aktive Sensoren. Sie senden selbst Energie aus, um
Informationen der Umwelt als Antwort zu erhalten. Genutzt werden unter anderem
Mikrowellen, Schall oder mechanische Vibrationen [8, 12].
Oftmals haben Sensorknoten nicht nur Sensoren sondern auch Aktuatoren, wie in
Abbildung 2.1 dargestellt. Sie sind das Gegenstück der Sensoren und die Signalver-
arbeitungskette läuft bei ihnen in entgegengesetzter Richtung. Ein vom Prozessor
generiertes digitales Signal wird zunächst durch einen Digital-Analog-Wandler in
ein analoges Signal umgewandelt und danach entsprechend verstärkt oder abge-
schwächt. Durch das Signal setzt der Aktuator eine Änderung in Gang. Dies kann
beispielsweise die Steuerung eines Motors oder ein Ventil sein [8].
11

2 Grundlagen
In dem Kreislauf in Abbildung 2.1 ist nicht die Umwelt, sondern ein Prozess darge-
stellt. Werden in einem Sensornetzwerk auch Aktuatoren eingesetzt, so wird oft ein
Prozess in der Umwelt überwacht, indem der Sensor Werte misst und der Aktuator
diese gezielt verändert.
Abbildung 2.1: Sensor-Aktuator-Kreis [8]
Da im Allgemeinen oft nur von Sensornetzwerken gesprochen wird und eine genaue
Betrachtung von Aktuatoren für die Fragestellung dieser Arbeit irrelevant ist, soll
auch hier der Begriff Sensornetzwerk stellvertretend für Sensor-Aktuator-Netwerke
stehen.
Sensorknoten
Sensornetzwerke bestehen aus Sensorknoten. Doch was sind Sensorknoten? Die Fra-
ge soll in diesem Abschnitt kurz beantwortet werden.
Sensorknoten sind Einheiten, die aus mehreren Komponenten bestehen. Eine Über-
sicht ist in Abbildung 2.2 dargestellt. Je nach Anwendung müssen die verschiedenen
Komponenten unterschiedliche Anforderungen erfüllen. Manche Sensorknoten sollen
besonders klein sein, andere dürfen nur eine bestimmte Menge Strom verbrauchen
oder eine Kostengrenze nicht überschreiten. Grundsätzlich gilt aber für jeden Sen-
sorknoten, dass das Verhältnis zwischen den Fähigkeiten eines Knotens und den
Kosten wirtschaftlich sein muss.
Da die Sensoren bereits im vorherigen Abschnitt besprochen wurden, sind sie hier
nicht noch einmal genannt.
Controller Der Controller ist die zentrale Verarbeitungseinheit des Knotens. Er
koordiniert die Kommunikation mit anderen Knoten, empfängt Sensordaten und
kann verschiedene Programme ausführen um die Daten zu verarbeiten. Die wich-
tigsten Kriterien für den Controller sind seine Rechenleistung, Flexibilität, Energie-
verbrauch und die Kosten [8].
Die flexibelsten und am leichtesten zu nutzenden Controller sind Mehrzweck-Prozessoren
für eingebettete Systeme. Sie sind Desktop-Prozessoren ähnlich, jedoch im Bezug auf
12

2 Grundlagen
Energieverbrauch und Anschlussmöglichkeiten auf diese eingebetteten Systeme spe-
zialisiert. Sie werden am häufigsten genutzt, da sie sich veränderten Bedingungen
und Aufgaben am besten anpassen können [8].
Ist ein Sensornetzwerk jedoch so ausgerichtet, dass sich seine Aufgaben während des
Betriebs nicht oder nur selten ändern, dann können auch spezialisierte Controller
eingesetzt werden. Das sind zum Beispiel FPGAs oder ASICs.
FPGAs können spezielle Aufgaben schneller und effizienter bearbeiten als ein Mi-
kroprozessor, da sie diese direkt in Hardware lösen. Ihre Rekonfiguration ist aber
zeit- und energieintensiver. Sie sind weniger flexibel als Mikroprozessoren und soll-
ten genutzt werden, wenn sich die Bedingungen und Aufgaben im Sensornetzwerk
nur selten ändern [8, 12].
Noch spezialisierter sind ASICs. Sie lassen sich nicht konfigurieren, bieten aber die
beste Performance und Energieeffizienz. Sie werden nur genutzt, wenn sie in großen
Mengen produziert werden können, damit sich die hohen Entwicklungskosten rela-
tivieren, oder mit einem Mikroprozessor zusammen arbeiten, um die Vorteile beider
zu kombinieren [8, 12].
Speicher Die wichtigste Speicherform für die Sensorknoten ist der RAM. In ihm
werden alle Werte gespeichert, die der Knoten während der Betriebszeit benötigt.
RAM ist sehr schnell, aber nicht persistent. Das heißt, ohne Stromversorgung kann
er nicht speichern. Als dauerhafter Speicher kann Flash-Speicher genutzt werden.
Wie viel jeweiliger Speicher installiert werden soll, muss von Anwendung zu Anwen-
dung entschieden werden. Die Speicherkapazität wirkt sich auf Produktionskosten
und Energieverbrauch aus [12].
Netzwerkschnittstelle Um die Sensorknoten zu einem Netzwerk zu verbinden,
brauchen sie eine Schnittstelle über die sie kommunizieren können.
Als Übertragungsmedium stehen verschiedene Möglichkeiten zu Auswahl. Das Kabel
wird hier nicht diskutiert, da in dieser Arbeit drahtlose Sensornetzwerke betrach-
tet werden. Das am häufigsten genutzte Verfahren ist die Übertragung von Radio-
Funkwellen, da es für die meisten Sensornetzwerke vorteilhaft ist und somit auch
für diese Arbeit genutzt wird. Es bietet hohe Reichweiten und Datenraten sowie
geringe Fehlerraten und Energieverbrauch. Andere Verfahren setzen auf optische Si-
gnalübertragung, Ultraschall oder magnetische Induktion [12].
Ein Sensorknoten muss sowohl Netzwerkpakete senden als auch empfangen können.
Eine Komponente die beides vereint, ist der sogenannte Transceiver. Die Wahl des
Transceivers wirkt sich auf den Energieverbrauch des gesamten Knotens aus. In ihm
liegt ein großes Potential zur Erhöhung der Energieeffizienz. So verfügen Transcei-
ver üblicherweise über 4 Zustände. 2 Zustände zum Senden bzw. Empfangen, einen
Leerlaufzustand und einen Schlaf-Zustand. Im Leerlaufzustand werden einige Teile
des Transceivers abgeschalten, aber er ist weiterhin in der Lage, Pakete zu Emp-
fangen. Beim Schlafzustand werden weitere Teile abgeschalten, ein Empfangen von
Paketen ist nicht mehr möglich und es kann verschiedene Stufen des Schlafzustands
geben [12].
13

2 Grundlagen
Energieversorgung Die Komponente die für die Energieversorgung zuständig ist,
hat einen hohen Stellenwert. Da sie in fast allen Fällen nur begrenzt Energie liefert,
ist die Lebensdauer eines Sensorknoten unmittelbar an sie gebunden.
Die klassische Komponente ist die Batterie, entweder wiederaufladbar oder nicht.
Wichtige Kenngrößen für die Batterie in einem Sensorknoten sind u. a. die Kapa-
zität, wobei besonders die Energiedichte, d.h. die Energie pro Volumen, interessant
ist, und die Selbstentladung. Ein alternativer Ansatz mit sehr guter Energiedichte
sind Brennstoffzellen. Diese sind jedoch aufgrund der Größe kaum einsetzbar [12].
Ein Lösungsansatz, der bereits eingesetzt wird, ist die Aufladung der Batterie durch
die in der Umwelt des Sensorknotens vorhandene Energie. Es gibt verschiedene Vari-
anten, dies zu realisieren. Zum einen bieten Solarzellen die Möglichkeit, Lichtenergie
in elektrische Energie umzuwandeln, zum anderen können dafür Temperaturunter-
schiede genutzt werden. Auch mechanische Energie in Form von Vibrationen oder
Druck ist eine potenzielle Energiequelle [12].
Abbildung 2.2: Aufbau eines Sensorknotens, Modell [12]
Sensornetzwerke
Sensorknoten die zu einem Netzwerk verbunden sind, bilden ein Sensornetzwerk.
Sensornetzwerke sind Ad-hoc-Netzwerken, die als kabellos verbundenes autonomes
System mobiler Hosts beschrieben werden, sehr ähnlich [9]. Ein Merkmal eines Ad-
hoc-Netzwerks ist u.a., dass es keine feste Infrastruktur zur Kommunikation gibt.
Einige Architekturen und Algorithmen, die in Ad-hoc-Netzwerken genutzt werden,
sind auch auf Sensornetzwerke übertragbar. Allerdings sind die Hosts, also die Sen-
sorknoten, bei Sensornetzwerken, im Gegensatz zu Ad-hoc-Netzen, nicht mobil [9].
Einige Aspekte der Netzwerkstruktur, die für Sensornetzwerke wichtig sind, sollen
in diesem Abschnitt untersucht werden.
Datenfluss Sensornetzwerke unterscheiden sich in ihrem Datenfluss. Die Quelle der
Daten ist der Sensorknoten, der wie oben beschrieben, Energie in der Umwelt in
14

2 Grundlagen
interpretierbare Daten umwandelt. Das Ziel der Daten kann jedoch variieren.
Das Ziel kann im Sensornetzwerk selbst enthalten sein, z.B. ein Aktuatorknoten, der
auf die Daten reagiert, oder je nach Ansatz, bzw. Aufgabe eine Basisstation [8]. Es
kann sich aber auch außerhalb des Netzwerks befinden. Dabei lässt sich zwischen
einem Endgerät, beispielsweise einem Smartphone und einem Zugang zu einem an-
deren Netzwerk, vor allem dem Internet, unterscheiden. Letzteres bietet die höchste
Flexibilität, ist aber auch schwierig umzusetzen. Ein sogenanntes Gateway, ein spe-
zieller Knoten oder die Basisstation im Sensornetzwerk, wird dafür benötigt, siehe
Abbildung 2.3 [12].
Es können zwei Seiten des Gateways betrachtet werden. Auf der einen Seite ist die
Kommunikation des Sensornetzwerks mit dem Internet, wobei es drei wesentliche
Probleme gibt. Erstens, wie kann ein Gateway, das Teil des Sensornetzwerks ist,
im Netzwerk gefunden werden? Dazu ist ein Routing-Service innerhalb des Sensor-
netzwerks erforderlich. Zweitens, wie wird bei mehreren verfügbaren Gateways eine
Entscheidung getroffen? Und drittens, wie kann die IP-Adresse des Ziels bestimmt
werden?
Abbildung 2.3: Sensornetzwerk mit Gateway [12]
Eine Ursache dieser Probleme ist u.a., dass in Sensornetzwerken typischerweise kein
Internetprotokoll genutzt wird. Ein Gateway muss also zwischen den im Sensornetz-
werk genutzten Protokollen bzw. Informationen und dem Internetprotokoll überset-
zen [12].
Single-hop und Multi-hop Bei der Übertragung der Daten von der Quelle zum
Ziel, gibt es die beiden Varianten Single-hop und Multi-hop. Single-hop ist der pri-
mitive Weg, bei dem jeder Knoten direkt mit dem Ziel kommuniziert, also in einem
Schritt. Dies ist möglich, solange das Ziel innerhalb der Sendereichweite eines Kno-
tens liegt und es keine Hindernisse gibt, die Funkwellen abschirmen. Beides ist für
den Einsatz von drahtlosen Sensornetzwerken oftmals nicht gegeben, da diese große
Flächen abdecken können deren Gegebenheiten vorher nicht bekannt sein müssen.
Deshalb wird das Multi-hop-Verfahren genutzt, welches wesentlich flexibler ist. Ein
15

2 Grundlagen
Sensorknoten sendet seine Daten nicht direkt zum Ziel, sondern zu einem Nachbar-
knoten. Dieser leitet sie an den nächsten Knoten weiter, bis das Ziel erreicht ist. Die
Übertragung erfolgt in mehreren Schritten [12].
Die Multi-hop-Kommunikation ermöglicht nicht nur die Übertragung von Daten
über große Distanzen und um Hindernisse herum, sondern verbessert auch die Ener-
gieeffizienz der Übertragung. Die Sendereichweiten der einzelnen Knoten müssen nur
so groß ausgelegt sein, dass sie einen Nachbarknoten erreichen. Es ist somit nicht
notwendig, Energie in eine große Reichweite zu investieren, um das Ziel direkt zu er-
reichen. Dabei muss jedoch beachtet werden, dass auch das Weiterleiten von Paketen
Energie kostet. Das Verhältnis von Energieaufwand im Knoten, der Pakete weiter-
leitet, und Energieeinsparung durch die geringere Sendereichweite in der Quelle soll
immer zugunsten der Einsparung ausfallen. Dafür sind ausreichend große Distanzen
zwischen den Knoten erforderlich. Sind Quelle und Ziel zu nah beieinander, kostet
es mehr Energie, die Kommunikation über dritte Knoten umzuleiten, als die Sende-
reichweite der Quelle zu erhöhen [12].
In einigen Fällen kann die Multi-hop-Kommunkation optimiert werden. Die Grun-
didee ist, dass es in einem Sensornetzwerk Knoten gibt, die die Daten von mehreren
anderen Knoten weiterleiten. Diese Knoten können dann Aggregatfunktionen, z.B.
den Durchschnittswert oder Minimum/Maximum, nutzen, um aus den Daten an-
derer Knoten und den eigenen nur einen oder zwei Werte zu berechnen, die weiter
geschickt werden. Je kleiner die zu sendende Datenmenge ist, desto weniger Energie
wird benötigt. Dies geht nur dann, wenn die Werte der Aggregatfunktionen für die
Erfüllung der Aufgabe des Sensornetzwerks, beispielsweise Temperaturmessung in
einem Gebiet, ausreichend sind [12].
Aufgrund der einfacheren Modellierung wird in dieser Arbeit ein Single-hop Netz-
werk erstellt, bei dem jedes Paket direkt an den Zielknoten gesendet wird. Dennoch
erlaubt die Struktur des Resource-based Application Clustering Approach die Nut-
zung von Aggregatfunktionen.
Daten-Zentralisierung Im Unterschied zu typischen Ad-hoc-Netzwerken stehen
bei Sensorknoten die Daten im Zentrum. Dies ist ein entscheidendes Kriterium für
die Adressierung der Knoten. In anderen Netzwerken werden Daten von konkreten
Knoten, im allgemeinen Fall sind das alle mit dem Netzwerk verbundenen Hosts,
abgefragt. Dafür muss genau dieser Knoten adressiert werden. In Sensornetzwerken
erfolgt die Abfrage nicht nach Knoten, sondern nach Daten. Diese Daten können
Messwerte sein, z.B. die aktuelle Temperatur in einem Gebiet, oder ein Ereignis,
z.B. eine Erschütterung. Die Anfrage richtet sich nicht an jeden einzelnen Knoten,
sondern an das gesamte Sensornetzwerk, bzw. einen Teil davon. Jeder Knoten der
die Anfrage beantworten kann, sendet seine Daten an das Ziel. Hier ist mit dem
oben beschriebenen Verfahren der Aggregation eine Reduzierung der zu sendenden
Datenmenge möglich [12].
Zur Implementierung der Daten-Zentralisierung gibt es verschiedene Varianten. Die
erste Variante ist die Nutzung verteilter Hash-Tabellen. Dabei wird den Daten über
eine Hash-Funktion ein Schlüssel zugeordnet. Über diesen Schlüssel wird bzw. wer-
16

2 Grundlagen
den der oder die Quellknoten identifiziert. Das Verfahren ist jedoch problematisch,
da es zwei Knoten immer als benachbart annimmt und die bei einer Multi-hop-
Struktur dazwischen liegenden Knoten vernachlässigt. An Lösungen zu diesem Pro-
blem wird geforscht [12].
Eine bereits funktionierende Lösung ist die Implementierung des Publish/Subscribe-
Prinzips. Dabei kann jeder Zielknoten, der an bestimmten Daten interessiert ist,
diese Daten subscriben, also abonnieren. Quellknoten, die Daten der Umwelt mes-
sen, können diese publishen, also veröffentlichen. An alle Knoten, die die Daten
abonniert haben, werden diese geschickt. Die Vorteile dieses Konzepts sind, dass es
asynchron ist, das Abonnement und die Veröffentlichung sind zeitlich unabhängig
von einander, und dass die Quelle das Ziel nicht kennen muss und das Ziel die Quelle
nicht. Zur Abgleichung der Publish- und Subscribe-Daten werden Filter der Form
(Attribut, Wert, Operator) genutzt. Das Attribut ist dabei ein Schlüsselwort oder
eine Eigenschaft, z.B. Temperatur. Der Wert ist eine Vergleichsgröße, wie eine kon-
krete Zahl im Fall der Temperatur, oder ein Platzhalter wie alle, kein und andere.
Effiziente Methoden zum Senden der Publish- bzw. Subscribe-Nachrichten in ver-
teilten Netzwerken werden erforscht [12].
Ein dritter Ansatz sieht Sensornetzwerke als Datenbanken. Alle verfügbaren Sen-
soren werden in eine Tabelle zusammengefasst und die Datenabfrage kann dadurch
wie eine SQL-Abfrage formuliert werden. Vorteilhaft ist, dass die Sensoren über ihre
Eigenschaften gruppiert werden können. Somit sind Abfragen in einem speziellen
räumlichen Gebiet möglich, indem nur Knoten abgefragt werden, deren Eigenschaft
Ort mit dem gewünschten Ort übereinstimmt. Es ist jedoch noch nicht klar, wie
dieses Verfahren in den Netzwerkprotokollen eines Sensornetzwerks implementiert
werden kann [12].
17

2 Grundlagen
2.1.2 Einsatzgebiete
Nachdem der Aufbau eines Sensornetzwerks erklärt wurde, wird nun an einigen aus-
gewählten Beispielen gezeigt, wo Sensornetzwerke eingesetzt werden.
Überwachung von Gebäuden In Hochhäusern oder Brücken können verteilte
Sensornetzwerke helfen, frühzeitig gefährliche Risse in den Strukturen zu erkennen.
Dort werden unter anderem Temperatursensoren und Beschleunigungssensoren an-
gebracht, die Daten an den Stellen messen können, an denen kabelgebunden oder
sperrige Geräte keinen Zugang haben. Des weiteren können die Sensoren in großer
Menge angebracht werden. Das ermöglicht eine gute Approximation der Messwerte
über die gesamte Struktur des Gebäudes zu erhalten. Damit wird die Erkennung
kritischer stellen deutlich vereinfacht [8, 9].
Steuerung von Gebäuden Sensornetzwerke können nicht nur die Bausubstanz
von Gebäuden überwachen, sondern auch die Nutzräume. In Großraumbüros, wo
Luftfeuchtigkeit und Temperatur durch Klimaanlagen geregelt werden, können Sen-
sornetzwerke genutzt werden, um die Klimaanlagen zu steuern. Die Sensoren erfas-
sen in den jeweiligen Räumen Daten zu Temperatur und Luftfeuchtigkeit. Dabei
können sie in großer Dichte angebracht werden, um genaue Daten zu erhalten und
sie ermöglichen Monitoring in Echtzeit. Das Ziel ist, eine möglichst energieeffiziente
und komfortable Klimaregelung zu etablieren [12].
Verkehrsüberwachung Auch im Straßenverkehr werden Sensoren genutzt, um die
Menge von Fahrzeugen auf einer Straße und deren Geschwindigkeit zu registrieren.
Eine Möglichkeit dafür sind Induktionsschleifen, wie sie zum Beispiel vor Ampeln zur
intelligenten Steuerung genutzt werden. Dabei messen Sensoren die Änderung des
Stromes und der Spannung innerhalb der Schleife. Daraus lassen sich Rückschlüsse
auf die Masse und die Geschwindigkeit des Fahrzeugs ziehen.
Die Nutzung von magnetischen Sensoren ist eine zweite Möglichkeit, um das Ver-
kehrsaufkommen zu registrieren. Diese messen direkt die Änderung des Erdmagnet-
feldes, die durch ein fahrendes Auto hervorgerufen wird. Es können dabei sogar
mehrere Fahrzeugtypen voneinander unterschieden werden.
Die beiden oben genannten Möglichkeiten werden zusätzlich mit Temperatur- und
Feuchtigkeitssensoren kombiniert. Beim Einsatz vieler verteilter Sensoren in einem
Sensornetzwerk lassen sich Verkehrsstaus vorhersagen und vermeiden. Die Fahrer
können bei einer Staugefahr informiert und umgeleitet werden.
Die in die Fahrbahn integrierten Sensoren haben den Vorteil, dass die Auswertung
der Daten keinen menschlichen Einsatz erfordert und im Gegensatz zu optischen
Sensoren mit Kameras unabhängig vom Wetter erfolgen kann [8].
Pipelines Eine andere, sicherheitsrelevante Anwendung von Sensornetzwerken ist
die Überwachung von Pipelines. Im Inneren einer Pipeline werden Druck- und Tem-
peratursensoren angebracht, über deren Messdaten ein eventuelles Leck gefunden
werden kann. So deutet bei einer Pipeline die Flüssigkeit führt eine heiße Stelle auf
ein Leck hin. Bei einer gasführenden Pipeline hingegen eine kalte Stelle, da dort
aufgrund des Lecks der Gasdruck abnimmt. Die Sensoren können die Pipeline im
18

2 Grundlagen
laufenden Betrieb, was für andere Messgeräte nicht möglich ist, und auf auf ganzer
Länge überwachen, da sie in ausreichend großer Menge vorhanden sind.
Bei einem Prototyp-Versuch in städtischen Wasserleitungen wurde diese Aufgabe
mit der Überwachung der Wasserqualität mit pH-Sensoren verbunden [8].
Landwirtschaft In der Landwirtschaft können Sensornetzwerke eingesetzt werden,
um einen effizienten Umgang mit Dünger, Herbiziden und Pestiziden sowie Wasser
zu realisieren. Die verteilten Sensoren sollen dabei helfen, Daten in einer agrarwirt-
schaftliche Nutzfläche zu messen. Diese Daten sind zum Beispiel Bodenart, Feuch-
tigkeit des Bodens oder Nährstoffgehalt. Durch die Daten ist es möglich, einzelne
Bereiche der Fläche zu differenzieren, anstatt sie als homogene Fläche anzusehen.
So können Ressourcen wie Wasser oder Dünger gezielt eingesetzt werden [8].
Vulkane Zur Untersuchung aktiver Vulkane Geräte genutzt, die sehr teuer und oft
nur schwer im Vulkan zu manövrieren sind. Einfacher kann dies mit einem Netzwerk
aus verteilten Sensoren gehen. Sie sind auch in großer Menge ökonomisch, schnell
und selbstorganisierend. Durch die hohe Anzahl können große Flächen differenziert
abgedeckt werden und das Sensornetzwerk erfordert kaum Wartung [8].
Unterirdische Minen Ein letztes Anwendungsgebiet, das kurz betrachtet werden
soll, sind unterirdische Minen. Dort sollen Sensornetzwerke Menschen auf verschie-
dene Art und Weise vor Gefahren schützen oder in Notsituationen retten. Sensoren
können genutzt werden, um Menschen unterirdisch zu finden, zum Beispiel bei ei-
nem Einsturz der Mine. Des weiteren können ähnlich wie bei Gebäuden und Brücken
seismische Aktivitäten gemessen und Erdbeben vorausgesagt werden. So ließen sich
Minenarbeiter rechtzeitig in Sicherheit bringen. Außerdem sind Sensoren in der La-
ge, den Gehalt verschiedener Gase, zum Beispiel Methan und Kohlenstoffdioxid, in
der Luft messen.
Der Einsatzort ist aber problematisch. In den Mienengängen ist eine Kommunikati-
on der Sensoren sehr schwierig bis unmöglich, da Signale an den Wänden reflektiert
und gebrochen werden. Dazu kommt eine hohe Luftfeuchtigkeit, wodurch die Signale
stärker absorbiert werden als an der Oberfläche [8].
Es gibt noch viele weitere Anwendungsfälle, bei denen Sensornetzwerke die effizi-
ente Lösung sind. Ein Vorteil der Sensoren ist die Größe. Sie können an Stellen
angebracht werden, die für andere Messgeräte unerreichbar sind. Zum anderen sind
verteilte Sensoren sehr flexibel, sie decken große Flächen ab und sind trotzdem sehr
genau. Da die Herstellung von Sensorknoten sehr ökonomisch ist, lassen sie sich
in ausreichend großer Menge herstellen, um eine hohe Dichte für die Genauigkeit
zu gewährleisten. Der vierte Vorteil ist die Wartungsarmut der Sensoren. Einmal
installiert, muss der Mensch sehr selten bis nie in den Betrieb eingreifen. Je nach
Stromverbrauch haben sie eine hohe Lebensdauer und organisieren sich im Netzwerk
selbst.
Neben diesen Vorteilen werfen Sensornetzwerke auch Probleme und Herausforderun-
gen auf, mit denen man im praktischen Einsatz umgehen muss. Auf diese soll im
nächsten Abschnitt eingegangen werden.
19

2 Grundlagen
2.1.3 Herausforderungen und Probleme
Um die positiven Aspekte der Sensornetzwerke für neue Anwendungen zu erschlie-
ßen und für bestehende zu optimieren, müssen einige Probleme gelöst werden. Diese
Probleme beinträchtigen zum Beispiel die Flexibilität und Wartungsarmut der Net-
ze. Die Reihenfolge der möglichen Probleme stellt keine Wertigkeit dar. Die Relevanz
eines Aspekts muss für jede konkrete Anwendung separat bestimmt werden.
Servicequalität Die erste Herausforderung betrifft die Qualität des Service im
Netzwerk. Damit sind die Anforderungen gemeint, die an die Datenübertragung in-
nerhalb des Netzwerk und auch nach außen gestellt werden. Für den konkreten Ein-
satz eines Sensornetzwerks muss klar sein, wie zum Beispiel mit verlorenen Paketen
umgegangen wird. Werden sie erneut geschickt, oder ist der Ausfall eines Pakets irre-
levant? Wie hoch ist überhaupt die Wahrscheinlichkeit, dass ein Paket verloren geht?
Ein weiteres Kriterium ist die bei der Übertragung auftretende Verzögerung. Gibt es
Realzeitanforderungen an das Netzwerk? Das heißt, müssen Pakete bis zu einem fest
definierten Zeitpunkt beim Empfänger ankommen? Algorithmen und Architekturen
zur allgemeinen Lösung dieses Problems sind noch weitgehend unerforscht [9].
Bandbreite und Skalierbarkeit Ein weiteres Problem ist die physikalische Be-
grenzung der Verbindungen des Netzwerks. Bei drahtlosen Sensoren sind es die An-
tennen, die bei sehr großen Netzwerken an ihre Grenzen stoßen. Je größer das Netz-
werk wird, das heißt, je mehr Knoten beteiligt sind, desto weniger Bandbreite steht
für jeden einzelnen Knoten zur Verfügung. Der Faktor ist in der Größenordnung von
1
√
n
, wobei n die Anzahl der Sensorknoten ist. Hat beispielsweise ein Sensornetzwerk
100 Knoten, so kann ein Knoten ungefähr 1
10
der gesamten Bandbreite nutzen.
Da die physikalische Bandbreite begrenzt ist, sind Kommunikations- und Routing-
protokollen entsprechend zu entwerfen. Es ist unabdingbar, das bei der Kommu-
nikation im Netzwerk nicht nur die reinen Nutzdaten übermittelt werden, sondern
auch zusätzliche Informationen. Das sind zum Beispiel Informationen über den Ort
des Empfängers und des Senders der Daten. Oder auch Schlüsselinformationen für
eine verschlüsselte Kommunikation. Die Protokolle müssen die Menge an Zusatzin-
formationen so gering wie möglich halten, um die begrenzte Bandbreite nicht noch
weiter einzuschränken [9].
Für die Praxis bedeutet dies, dass sich ein Sensornetzwerk nicht beliebig skalieren
lässt. Wird die Anzahl der Knoten zu groß, ist eine stabile Kommunikation nicht
mehr möglich.
Organisation im Netzwerk Die zumeist dezentrale Organisation der Sensorkno-
ten ist eine andere problematische Eigenschaft. Eine typischer Aufbau eines Netz-
werks folgt dem Client-Server-Prinzip, bei dem ein oder mehrere Server Dienste
bereit stellen, oder die Clients koordinieren. In verteilten Sensornetzwerken gibt es
dagegen oft keine zentrale Station. Das stellt vor allem an die genutzten Algorith-
men neue Anforderungen.
In einem Sensornetzwerk kann es Dienste geben, deren Anbieter von Zeit zu Zeit
wechselt, dennoch müssen die einzelnen Knoten wissen, wo der Dienst zu finden
20

2 Grundlagen
ist. Auch Routing, also das finden von Wegen im Netzwerk, ist erforderlich. Ein
klassischer Algorithmus läuft über einen zentralen Server, der die Positionen der
einzelnen Knoten kennt und so den optimalen Weg zwischen zwei Knoten ermitteln
kann. Dafür sind allerdings Informationen nötig, die über die Nutzdaten hinausge-
hen, sogenannter Overhead.
Bei einem denzentralen Routing-Algorithmus gibt es keine Station, die alle Informa-
tionen hat. Die Knoten können nur begrenzte Daten nutzen, etwa, wer ihre Nach-
barknoten und deren Nachbarknoten sind. Das Ergebnis das ein solcher Algorithmus
liefert ist vielleicht nicht optimal, aber er erzeugt auch weniger Overhead [8, 9].
Es gilt also abzuwägen, welcher Ansatz im konkreten Fall das beste Kosten-Nutzen-
Verhältnis liefert.
Eigenmanagement Sensornetzwerke werden oft dort eingesetzt, wo sie durch Men-
schen nur schlecht oder gar nicht erreichbar sind. In einigen Situationen ist vor der
Inbetriebnahme unklar, in welchem genauen Umfeld die Sensoren sein werden oder
welche von ihnen überhaupt funktionieren. Dies kann zum Beispiel dann der Fall
sein, wenn sie aus einem Flugzeug über einem Gebiet abgeworfen werden. Die Sensor-
knoten müssen dann eigenständig Nachbarknoten finden und Verbindungen zu ihnen
etablieren. Die Position eines Knotens und die seiner Nachbarn kann darüber ent-
scheiden, welche Funktion der Knoten im Netzwerk erfüllen soll. Außerdem müssen
sie auf Änderungen der Umwelt reagieren, in dem sie sich beispielsweise vor ihnen
Schützen oder ihnen anpassen [8].
Sicherheit Das drahtlose Netzwerk ist eine Infrastruktur, die anfällig gegen Angrif-
fe ist. Ein potentieller Angreifer kann leicht die Kommunikation zwischen zwei oder
mehreren Parteien mitschneiden. Informationen werden durch die Luft übertragen,
sind also für jeden zugänglich, der einen entsprechenden Empfänger hat.
In anderen Drahtlos-Netzwerken, zum Beispiel einem zu Hause genutzten WLAN,
gibt es Mechanismen, die eine sichere Kommunikation gewährleisten. Doch diese
Mechanismen brauch zumeist eine Speicherkapazität und Rechenleistung, die auf
Sensorknoten nicht zur Verfügung steht.
Für Sensornetzwerke bedarf es neuer Lösungen, die mit den gegeben Ressourcen zu
realisieren sind. Obwohl die Sicherheit ein enorm wichtiger Aspekt ist, sind kaum
Ansätze zur Verbesserung vorhanden. Das mag daran liegen, dass es für die Schich-
ten unterhalb der Sicherheitsanwendungen keine einheitlichen Standard gibt [8, 9].
Energie Eines der im Allgemeinen wichtigsten Probleme ist der Energiehaushalt
der einzelnen Sensoren. Da diese zumeist mit Batterien oder Akkumulatoren be-
trieben werden, ist die Ressource Energie begrenzt. Ist die Batterie leer, muss sie
gewechselt, oder im Falle des Akkumulators, neu geladen werden. Es gibt aber auch
Sensoren, bei denen das Wechseln der Batterie nicht möglich ist. Bei diesen Sensoren
bedeutet eine leere Batterie das Ende der Lebensdauer. Ein klares Ziel ist also, die
Lebensdauer einzelner Knoten sowie des gesamten Netzwerks zu erhöhen.
21

2 Grundlagen
2.1.4 Aktuelle Lösungen
In diesem Abschnitt sollen Verfahren und Best Practices vorgestellt werden, um die
oben genannten Probleme zu bewältigen.
Der Protokoll-Stack von Sensornetzwerken folgt dem OSI-Referenzmodell, siehe Ab-
bildung 2.4. In jeder der Schichten des Modells gibt es Ansätze, um die Installation
und den Betrieb eines Sensornetzwerks effizienter zu gestalten oder in bestimmten
Szenarien überhaupt erst möglich zu machen, siehe 2.1.2. Dabei sind u.a. die Kosten
der Produktion und der Energieverbrauch während des Betriebs interessant.
Abbildung 2.4: OSI-Referenzmodell [7]
Gerichtete Antennen Gerichtete Antennen können genutzt werden, um die Band-
breite und damit die Skalierbarkeit eines Sensornetzwerks zu erhöhen.
(a) Ungerichtete Antennen (omnidirek-
tional)
(b) Gerichtete Antennen (direktional)
Abbildung 2.5: Schematischer Vergleich von ungerichteten Antennen (a) und gerich-
teten Antennen (b) [9]
Diese können im Gegensatz zu ungerichteten Antennen, für die die oben genannte
Verkleinerung der Bandbreite gilt, gezielt in eine Richtung strahlen. Dadurch ergibt
sich eine höhere Reichweite und, aufgrund der gezielten Nutzung, eine höhere Band-
breite. Die Verbindungen werden außerdem stabiler, da das Signal auf eine Rich-
tung fokusiert werden kann und somit stärker ist. Und Interferenzen mit Nachbar-
22

2 Grundlagen
knoten werden vermieden, was die Kollisionswahrscheinlichkeit von Pakten deutlich
verringert. In Abbildung 2.5 wird die Wirkungsweise gerichteter und ungerichteter
Antennen gegenübergestellt. Obwohl gerichtete Antennen viele Vorteile im Einsatz
bringen, sind ist die Entwicklung und Produktion aufwendig und teuer. Außerdem
ist eine Anpassung auf fast allen Schichten des Protokoll-Stacks notwendig, damit
Sensorknoten effizient mit gerichteten Antennen arbeiten können [9].
Wakeup-Receiver Ein Sensorknoten hat verschiedene Aufgaben, allen voran das
Sammeln von Daten aus der Umwelt und die Bereitstellung dieser Daten in einer
Form, die von Computern weiter verarbeitet werden kann. Dazu kommt in einem
Netzwerkverbund auch die Aufgabe der Kommunikation mit anderen Knoten. Diese
Kommunikation ist die energieaufwändigste Aufgabe [17].
Es ist daher naheliegend, die Kommunikation im Netzwerk energieeffizienter zu ge-
stalten. Ein Ansatzpunkt dafür ist der Transceiver, der Pakete empfängt und ver-
sendet. Typischerweise ist die Menge und Größe der Pakete in einem Sensornetzwerk
klein, da z.B. bei der oft genutzten Publish/Subscribe-Implementierung der Daten-
zentralisierung, siehe Abschnitt 2.1.1, nur Datenpakete gesendet werden, wenn ein
bestimmtes Ereignis ausgelöst oder ein Kriterium erfüllt wurde. Ein Transceiver, der
in der Zwischenzeit weder Pakte empfangen noch senden muss, verbraucht im Leer-
laufzustand trotzdem Energie. Das Ziel sollte also sein, die wesentlichen Funktionen
des Transceivers nur dann zu aktivieren, wenn diese gebraucht werden.
An dieser Stelle kann ein Wakeup-Receiver eingesetzt werden. Der Wakeup-Receiver
ist während der mitunter langen Leerlaufphasen in einem Sensornetzwerk aktiv,
kann also ankommende Pakete empfangen. Der Haupt-Transceiver wird in dieser
Zeit abgeschaltet oder in einen sehr energiesparenden Schlafzustand versetzt. In der
einfachsten Form aktiviert der Wakeup-Receiver den Haupt-Transceiver bei jedem
ankommenden Paket, wohingegen intelligentere Lösungen die Paketinformationen
auswerten und den Haupt-Transceiver nur aktivieren, wenn das Paket für den jewei-
ligen Knoten bestimmt ist und möglicherweise zusätzlich noch von einem bestimm-
ten Typ ist. Es handelt sich dann um ein sogenanntes Wakeup-Paket. Ein Ansatz
der das Wakeup-Konzept nutzt, wird in [22] beschrieben. Der Zustand eines Sensor-
netzwerks wird dabei in zwei Modi eingeteilt. Im ersten Modus sind hauptsächlich
die Sensormodule aktiv, Kommunikation findet nur auf lokaler Ebene im Notfall
statt. Die Kommunikationshardware ist deaktiviert. Im zweiten Modus findet glo-
bale Kommunikation statt. Die gesammelten Messwerte werden an eine Datensenke
übertragen. Um diesen Modus zu aktivieren, sendet die Datensenke typischerweise
ein Wakeup-Paket. Dieses Prinzip soll auch in dieser Arbeit vereinfacht umgesetzt
werden.
Bestehende Wakeup-Receiver-Implementierungen können bei der Leistungsaufnah-
me im aktiven Zustand in der Größenordnung eines Tausendstels der Leistungsauf-
nahme eines Haupt-Transceivers liegen: Letztere benötigen im Durchschnitt meh-
rere 10 Milliwatt, wohingegen Wakeup-Receiver bei ca. 1 bis 10 Mikrowatt liegen
[12, 17, 20].
23

2 Grundlagen
Clustering-Ansatz Der Clustering-Ansatz nutzt die Beobachtung, dass an nah bei
einander liegenden Punkten einer physikalischen Umgebung ähnliche physikalische
Werte gemessen werden können. In einem Sensornetzwerk, dass ein Gebiet abdeckt,
um in diesem Gebiet Messwerte zu erheben, bedeutet das für nah bei einander lie-
gende Sensorknoten, dass diese ähnliche Werte messen werden. Senden alle Knoten
ihre Messwerte an eine Datensenke, werden viele Pakete redundante Information
enthalten, wenn sich ihre Absender nah sind. Redundante Informationen machen
das Netzwerk zwar ausfallsicher, aber das Senden von Paketen ist auch eine sehr
energieintensive Aufgabe. Mit der Energie, die benötigt wird, um ein Bit über ei-
ner größere Distanz zu übertragen, können verhältnismäßig viele Rechenoperationen
ausgeführt werden.
Beim Clustering-Ansatz werden nah bei einander liegende Knoten zu Gruppen, den
sogenannten Clustern zusammengefasst und es entsteht eine Hierarchie. Die Kno-
ten im Cluster, genannt Cluster-Members, kommunizieren nur mit einem speziel-
len Knoten im Cluster, dem Cluster-Head. Dieser Cluster-Head kann mit anderen
Cluster-Heads oder der Datensenke kommunizieren. Der entscheidende Schritt zur
Reduzierung der Datenübertragung und des Energieverbrauchs ist die Anwendung
von Aggregatfunktionen, die bereits in Abschnitt 2.1.1 erwähnt wurden. Aggregat-
funktionen werden vor allem im Bereich von Datenbankabfragen eingesetzt, um die
Werte mehrerer Datensätze zusammenzufassen oder einen bestimmten Wert aus der
Wertemenge zu erhalten. Diese Prinzip lässt sich auch auch auf Cluster in Sen-
sornetzwerken anwenden, wenn man die Messergebnisse der Sensorknoten als Da-
tensätze ansieht. Alle Sensorknoten in einem Cluster senden ihre Messwerte an den
Cluster-Head, dieser führt auf den Messwerten die im Anwendungsfall benötigte Ag-
gregatfunktion aus und übermittelt das Ergebnis weiter an eine Datensenke.
Bei diesem Verfahren werden viele Pakete zwischen Cluster-Members und Cluster-
Head gesendet, die nach dem Clustering-Prinzip nah bei einander liegen, aber nur
ein Paket zwischen dem Cluster-Head und einer weiter entfernten Datensenke. Die
Nutzung der Aggregatfunktion ist im Bezug auf den Energieverbrauch wesentlich
billiger als die direkte Übermittlung der Messergebnisse von Cluster-Members zur
Datensenke.
24

2 Grundlagen
2.2 Simulation
2.2.1 Was ist Simulation?
Die Simulation ist ein Verfahren, bei dem ein Experiment am Modell durchgeführt
wird.
Ein Modell ist ein Abbild der Realität. Dabei bildet das Modell im Allgemeinen
dicht alle Aspekte der Realität ab, sondern nur diejenigen die für das Experiment
benötigt und relevant sind.
Das Experiment kann verschiedene Formen annehmen, z.B. Funktionstest eines neu-
en Verfahrens oder Evaluation eines Verfahrens an verschiedenen Modellen. Im Kon-
text dieser Arbeit wird die Simulation von Computernetzwerken, speziell verteilten
Sensornetzwerken, über einen gewissen Zeitraum betrachtet. Das heißt, das einge-
setzte Modell wird ein Sensornetzwerk abbilden. Die Simulation ist hierbei eine
Softwaresimulation, d.h. das Modell wird als Software konstruiert und das Experi-
ment entspricht dem Ausführen der Software.
Die Simulation bietet neben dem praktischen Test in der Realität und der rein for-
malen, theoretischen Betrachtung einen dritten Weg zur Validierung oder Evaluation
eines Verfahrens. Im Folgenden sollen dir Vor- und Nachteile der Simulationsmetho-
de im Vergleich zum realen Test diskutiert werden. Die rein theoretische Betrachtung
wird hier zu Validierung ausgeschlossen, da die Komplexität verteilter Sensornetz-
werke dafür zu groß ist [16].
Die Simulation kann eingesetzt werden, wenn das reale System noch in der Entwurfs-
phase ist. Das ermöglicht schon im Vorfeld den Test diverser Parameter, welche die
Funktionalität des realen Systems beeinflussen, und anschließend die Auswahl der
am besten geeigneten Werte für diese Parameter. Hierbei konkurriert die Simula-
tionsmethode nicht mit dem Realtest, sondern bietet eine zusätzliche, vorgelagerte
Evaluationsmöglichkeit [16].
Ein zweiter Punkt ist, dass die Simulation eine kostengünstigere und einfachere Al-
ternative ermöglichen kann. Das gilt aber nur für Systeme, in denen zur Durchführung
des Experiments verhältnismäßig komplizierte und/oder teure Anpassungen not-
wendig sind. Denn auch die Erstellung einer geeigneten Simulation ist mit einem
nicht unerheblichen Aufwand verbunden, siehe dazu weiter unten. Um diesen Auf-
wand einzugrenzen, stehen für Simulationsumgebungen bereits vorgefertigte Modell-
Suiten zur Verfügung, z.B. INET zur Netzwerkmodellierung [16, 19, 10].
Des Weiteren kann eine Simulation eingesetzt werden, um alternative Einstellun-
gen und Verfahren zu evaluieren, ohne dabei in das Produktivsystem eingreifen zu
müssen. Soll z. B. ein Firmennetzwerk, das permanent benötigt wird, effizienter
gestaltet werden, so muss ein Modell des Netzwerks erstellt werden, um die Ände-
rungen durch Simulation zu testen [16].
Ein letzter entscheidender Vorteil, der hier genannt werden soll, ist die Möglichkeit,
den Ablauf der Zeit zu steuern. Es kann zum einen sehr langsam simuliert wer-
den, um einzelne Verarbeitungsschritte oder den Paketverkehr im Netzwerk nach zu
vollziehen. Zum anderen können bei einer sehr schnellen Simulation mehrere Tage
25

2 Grundlagen
in wenigen Minuten durchlaufen werden. Somit kann auch das Langzeitverhalten
eines Netzwerks in vergleichsweise kurzer Zeit simuliert werden. Gerade für Sensor-
netzwerke, in denen die Zeit, die das System ohne Eingriff laufen kann, eine sehr
interessante Eigenschaft ist, bietet die Simulation eine Möglichkeit, diese Eigenschaft
zu testen [16].
Die Vorteile, welche die Simulationsmethode mit sich bringt, bringen auch Nachteile
mit sich. Zuerst sei dabei die Schwierigkeit genannt, ein geeignetes Modell für die
Simulation zu finden. Geeignet heißt dabei, dass die Ergebnisse der Simulation das
Verhalten im realen System gut approximieren müssen. Dafür gilt es zu beachten,
dass die Vereinfachung, die die Simulation ermöglicht, dadurch erreicht wird, dass
nicht all Aspekte der Realität modelliert werden und auch nicht modelliert werden
können. Bei der Erstellung des Modells müssen also die für die zu testende Funktio-
nalität entscheidenden Eigenschaften erfasst und abgebildet werden. Andere Aspekte
der Realität werden dann nur vereinfacht oder gar nicht dargestellt. Die Qualität
des Modells ist entscheidend für die Verwertbarkeit der Simulationsergebnisse [16].
Ein anderes Problem ist die Auswertung und Interpretation der Messwerte. Dieser
Schritt ist zwar auch bei einem Test in der Realität notwendig, aber bei der Simulati-
on kommt noch hinzu, dass die Beschaffenheit des Modells die Ergebnisse zusätzlich
beeinflussen kann. Ist das Modell schlecht gewählt oder gar die Simulationsumge-
bung fehlerhaft, sind die Ergebnisse nicht auf die Realität zu übertragen. Auch hier
bieten vorgefertigte und anerkannte Simulationsmodelle eine Vereinfachung [16].
Simulationen können im Wesentlichen in drei Gesichtspunkten kategorisiert werden.
Eine erste Unterscheidung ist zwischen statischen und dynamischen Simulationen zu
treffen. Bei einer statischen Simulation hat die Zeit keinen Einfluss auf das Verhal-
ten des simulierten Systems, es ist zeitunabhängig. Bei dynamischen Simulationen
ist die Zeit hingegen ein bestimmender Faktor. Computernetzwerke fallen in diese
Kategorie. Man kann weiterhin differenzieren zwischen Zeit-gesteuerter Simulati-
on, hier wird die Zeit bei jeder Iteration um eine feste Zeitspanne erhöht, oder
Ereignis-gesteuerter Simulation. Dabei wird die Zeit soweit erhöht, dass das nächs-
te Ereignis stattfinden kann [16]. Eine weitere Einteilung von Simulationen erfolgt
nach ihrem Verhalten. Es gibt Simulationen, die sich deterministisch verhalten, d.h.
bei gleicher Eingabe und dem gleichen Startzustand des Modells, entstehen immer
die gleichen Ergebnisse, reicht ein Lauf der Simulation. Im Gegensatz dazu können
die Ergebnisse einer stochastischen Simulation von Lauf zu Lauf variieren. Das liegt
daran, dass in stochastischen Simulationen bestimmte Eigenschaften oder Parameter
zufällig gewählt werden. Im Kontext einer Netzwerksimulation sind z.B. Ankunfts-
zeiten von Paketen oder Servicezeiten zufällig. Das stochastische Verhalten liefert
ein besseres Abbild der Realität, jedoch ist auch eine wiederholte Ausführung nötig,
um ein Ergebnisspektrum zu erhalten [16, 19].
Die dritte Kategorie zur Einteilung ist die Charakteristik der Zustandsänderung des
Systems, die zum einen kontinuierlich und zum anderen diskret erfolgen kann, siehe
Abbildung 2.6. Bei einer kontinuierlichen Simulation ändern sich die Zustandsvaria-
26

2 Grundlagen
Abbildung 2.6: Vergleich von kontinuierliche und diskreter Wertänderung
blen kontinuierlich, was im Modell durch betragmäßig sehr kleine Änderungen der
Werte abgebildet wird. Bei diskreten Simulationen können die Werte nur diskrete
Zustände annehmen, d.h. es gibt keine Werte zwischen zwei Zuständen. Computer-
netzwerke fallen unter die zweite Kategorie, da hier eine Zustandsänderung nur beim
Empfangen und Versenden einer Nachricht erfolgt und nicht in Abhängigkeit vom
Vergehen der Zeit [16, 19].
Zur Erstellung von Simulationen stehen verschieden Plattformen zur Verfügung. Im
nächsten Abschnitt soll die Plattform OMNeT++ näher betrachtet werden.
2.2.2 Das Simulations-Framework OMNeT++
Warum OMNeT++?
Im Bereich der Netzwerkforschung ist die Simulation eine oft genutzte Methode und
im Laufe der Jahre wurden viele Simulationswerkzeuge entwickelt. Es werden nun
zunächst einige wichtige Plattformen kurz dargestellt und gezeigt, warum für diese
Arbeit OMNeT++ genutzt wird.
ns-3 Der ns-3-Simulator ist eine oft genutzte Plattform und fällt in die Kategorie
der diskreten, Ereignis-basierten Simulatoren. Er ist unter der Lizenz GNU GPLv2
frei verfügbar. Implementiert ist ns-3 in C++ und Python. ns-3 bietet eine sehr
gute Gesamt-Performance, jedoch keine integrierte GUI. Netzwerk-Topologien und
Simulationsergebnisse lassen sich mit Hilfsprogrammen visualisieren. Windows wird
von ns-3 nur experimentell unterstützt [13, 4].
SimANet Die an der TU Chemnitz entwickelte Simulationsumgebung SimANet
eignet sich vor allem für mobile Ad Hoc und Sensornetzwerke. Die in Java geschrie-
bene Plattform ist sehr effizient und für Simulationen mit vielen Knoten ausgelegt.
SimANet hat eine integrierte GUI zur Bearbeitung von Netzwerk-Topologien, kann
aber auch über die Kommandozeile gesteuert werden. Anpassungen auf Anwen-
dungsebene sind nur begrenzt möglich, das Hauptaugenmerk liegt auf einer hoch
27

2 Grundlagen
skalierbaren Modellierung der Transport-orientierten Netzwerkschichten [6, 23].
NetSim Die Netzwerk-Simulationssoftware NetSim ist für viele Einsatzgebiete ge-
eignet, darunter auch drahtlose Sensornetzwerke. NetSim verfügt über eine GUI zur
Erstellung von Netzwerken und Ausführung von Simulationen. Des weiteren können
die Ergebnisse über integrierte Hilfsmittel oder externe Programme grafisch darge-
stellt werden. Der C-Quellcode kann angepasst und erweitert werden. Allerdings ist
NetSim nicht frei erhältlich und an der TU Chemnitz nicht verfügbar [3].
Neben den oben genannten gibt es noch viele weitere Simulationswerkzeuge, die
hier nicht alle genannt und verglichen werden können. Ungeeignet für diese Ar-
beit sind Plattformen, die den Bereich der drahtlosen Sensornetzwerke nicht aus-
reichend abdecken. Hier spielt vor allem das Protokoll IEEE 802.15.4 eine große
Rolle. Außerdem soll das Simulationsmodell angepasst und erweitert werden, be-
sonders auf der Anwendungsebene einzelner Netzwerkknoten. Somit fällt die SimA-
Net-Simulationsumgebung weg. Nicht in Erwägung wurden auch alle Plattformen
gezogen, dich für ein Forschungsprojekt nicht frei verfügbar sind, darunter fällt auch
NetSim. Von Vorteil ist darüberhinaus die Implementierung des Simulationsmodells
in C oder C++, da das zu integrierende RACA-Framework in C geschrieben ist und
weitgehend unverändert bleiben soll. Die Entscheidung für OMNeT++ fiel letztend-
lich, da OMNeT++ die oben genannten Bedingungen erfüllt, über eine umfangreiche
GUI verfügt, die das Verständis der einzelnen Schritte im Netzwerk deutlich verein-
facht und das Arbeiten mit OMNeT++ bereits bekannt ist. Zusätzlich besteht die
Möglichkeit, die Ergebnisse dieser Arbeit mit den Ergebnissen anderer Arbeiten
([18]), die ebenfalls in OMNeT++ erstellt wurden, zu kombinieren.
Im nächsten Abschnitt erfolgt eine kurze Einführung in den Aufbau von OMNeT++
und der Modell-Bibliothek INET.
OMNeT++
OMNeT++ ist ein Objekt-orientiertes, modulares Netzwerk-Simulations-Framework,
das mit diskreten Ereignissen arbeitet. Es besteht aus einer C++-Bibliothek zur Er-
stellung von Simulatoren und einer IDE, die eine für die Simulation angepasste
Variante der Eclipse IDE ist. Die Bibliothek stellt dabei nur die Komponenten zur
Verfügung, aus denen ein Simulationsmodell erstellt werden kann. Diese Kompo-
nenten werden in OMNeT++ Module genannt und können in einem hierarchischen
System kombiniert werden. An der obersten Stelle der Hierarchie steht das Sys-
tem Module, oder auch Network, das aus Submodulen besteht, welche wiederum aus
Submodulen bestehen können. Module die Submodule enthalten werden Compound
Module genannt. Module die keine Submodule enthalten nennt man Simple Module,
siehe Abbildung 2.7.
Die Module kommunizieren über Messages. Als Schnittstelle stehen dafür Gates be-
reit, die über Connections verbunden sind. Die Messages können beliebige Daten-
strukturen enthalten und nicht nur zwischen Komponenten ausgetauscht, sondern
auch als Self-Message erstellt werden, um z.B. einen Timer zu modellieren. Messa-
28

2 Grundlagen
ges werden vom Anwender definiert oder stehen in einer Modell-Bibliothek bereit.
Um auch die Übertragungen im Netzwerk anpassen zu können stehen Channels,
Kanäle zu Verfügung, denen Parameter wie die Datenrate oder Fehlerraten überge-
ben werden können. Messages die zwischen Netzwerkknoten ausgetauscht werden,
sind typischerweise durch die von Message abgeleitete Packet-Struktur modelliert.
Parameter, z.B. Adresse des Knotens oder Leistungsaufnahme können das Verhal-
ten eines Moduls oder eines Kanals beeinflussen. Sie können aber auch die Topologie
des Netzwerks bestimmen, indem sie den Typ eines Submoduls bestimmen. Die Pa-
rameter für eine Simulation werden in der ini-Datei festgelegt, dabei können auch
default-Werte überschrieben werden [21].
Abbildung 2.7: Die grundlegende OMNeT++ Modulstruktur [21]
Zur Beschreibung der Struktur der Komponenten wird die Network Description
(NED) Sprache verwendet. Die Eigenschaften der NED Sprache erlauben die leich-
te Handhabung auch groß skalierter Netzwerkstrukturen. Sie ist hierarchisch, was
die Beschreibung von Strukturen nach dem Teile und Herrsche-Prinzip ermöglicht.
Da die in NED erstellen Komponenten gut wieder verwendet werden können, sind
Modell-Bibliotheken wie INET entstanden. Ein weiteres Prinzip, welches die NED-
Sprache flexibel macht, sind Interfaces. Sie ermöglichen die Erstellung von Com-
pound Modules mit abstrakten Submodulen, die über Parameter mit konkreten Mo-
dulen ersetzt werden können. So kann beispielsweise eine Netzwerkknoten-Komponente
aus einer Bibliothek durch die Angabe des Energiespeicher-Typs angepasst werden,
siehe Listing 2.1. Der default-Wert wird genutzt, falls kein anderer Wert für den
typename-Parameter definiert wird. Der display-Parameter bestimmt u.a. die Posi-
tion des Moduls im übergeordneten Modul.
submodules:
energyStorage: <default(" SimpleEpEnergyStorage ")>
like IEnergyStorage
{
parameters:
@display("p=125 ,320; is=s");
}
Listing 2.1: Interface-Beispiel in NED
29

2 Grundlagen
Das Prinzip der Vererbung ist ebenfalls in NED enthalten. Module und Kanäle
können durch neue Parameter oder Submodule erweitert werden oder es können
generische Basismodule durch die Angabe konkreter Werte für Parameter speziali-
siert werden. In Listing 2.2 wird das StandardHost-Modul zum WirelessHost-Modul
erweitert. Der numWlanInterdfaces-Parameter, der weiter oben in der Vererbungs-
Hierarchie definiert ist, wird auf den Standardwert 1 gesetzt
module WirelessHost extends StandardHost
{
parameters:
numWlanInterfaces = default (1);
@display("i=device/wifilaptop");
}
Listing 2.2: Beispiel für Vererbung in NED
Zur Organisation verschiedener Module wird eine Java-ähnliche Package-Struktur
verwendet. Über diese verzeichnisartige Struktur können Module anderer Packages,
z.B. aus einer Komponenten-Bibliothek, eingebunden werden. Module die im selben
Package-Pfad liegen, sind funktional der gleichen Kategorie zuzuordnen [21].
Mit der NED-Sprache kann keine Funktionalität, sondern nur die Struktur beschrie-
ben werden. Funktionalität entsteht durch die Algorithmen, die in C++ als Me-
thoden der Simple Modules oder Channels implementiert sind. Die dazugehörigen
C++-Klassen sind cSimpleModule, abgeleitet von cModule und cChannel. Beide
sind abgeleitet von cComponent. Diese Basisklassen deklarieren Methoden, welche
die Schnittstelle zwischen dem Simulations-Kernel und den einzelnen Komponenten
bilden. In den Komponenten-Bibliotheken sind diese Methoden durch die jeweiligen
Module und Kanäle implementiert. Sie können auch in vom Anwender abgeleiteten
Modulen überschrieben werden.
class INET_API TcpAppBase :
public cSimpleModule , public TcpSocket :: ICallback
{
...
protected:
virtual void initialize(int stage) override;
virtual void handleMessage(cMessage *msg) override;
virtual void finish () override;
...
}
Listing 2.3: Beispiel für Implementierung der Kernel-Schnittstellen
Listing 2.3 zeigt drei dieser Methoden. Die INET-Klasse TcpAppBase ist direkt
von cSimpleModule abgeleitet und implementiert die virtuellen Methoden initiali-
30

2 Grundlagen
ze, handleMessage und finish. Die initialize-Methode wird aufgerufen, nachdem das
Modell durch den Simulator erstellt wurde. Die handleMessage-Methode wird immer
dann aufgerufen, wenn eine Message am Modul eintrifft. Hier wird die eigentliche
Funktionalität des Moduls beschrieben. Wenn die Simulation erfolgreich beendet
wird, ruft der Simulator die finish-Methode auf. Sie wird genutzt, um die Simulati-
onsergebnisse abzuspeichern [21].
OMNeT++ stellt grundlegende Klassen und Module zur Verfügung, mit denen ein
Netzwerkmodell erstellt werden kann. Da die richtige Zusammenstellung eines sol-
chen Modells sehr schwierig und aufwendig ist, siehe Abschnitt 2.2.1, wird auf die
Modell-Bibliothek INET zurückgegriffen. INET bietet Implementierungen für wich-
tige Netzwerkprotokolle, darunter IEEE 802.11, IEEE 802.15.4, IPv4 und IPv6,
TCP und UDP, Mobilitäts- und Energie-Modelle sowie vor gefertigte Netzwerkkno-
ten. Die Bibliothek kann im C++-Quellcode und den NED-Strukturbeschreibungen
angepasst und erweitert werden [10].
INET
In diesem Abschnitt wird die Struktur der INET Modell-Bibliothek erklärt , vor
allem die Bestandteile, die im 3. und 4. Kapitel modifiziert werden. Neben den
eigentlichen Modell-Quellen, liefert die Bibliothek auch Beispiele, die zeigen, wie die
Komponenten kombiniert werden können. Zusätzlich bringt INET neue Grafiken
und Templates, die das Erstellen neuer Komponenten vereinfachen. Im Folgenden
wird ausschließlich das src/inet-Verzeichnis der Bibliothek betrachtet, in dem sich
alle Quellen befinden (Abbildung 2.8).
Abbildung 2.8: Struktur der INET Modell-Bibliothek
physicallayer In diesem Verzeichnis sind Komponenten der Bitübertragungsschicht
zu finden, z.B. Radio-Module. Das Basis-Radio–Modul in Abbildung 2.9 setzt sich
zusammen aus einer Antenne, einem Receiver, einem Transmitter und einem Ener-
gieverbraucher. Jedes der vier Submodule ist ein Typ von Komponenten, die eben-
falls in diesem Verzeichnis definiert sind. Für das im Rahmen dieser Arbeit betrach-
tete Protokoll IEEE 802.15.4 steht ein spezialisiertes Radio-Modul
Ieee802154NarrowbandScalarRadio zur Verfügung, das einen ebenfalls spezialisierten
31

2 Grundlagen
Receiver und Transmitter nutzt. Das Radio-Modul ist für das Senden und Empfan-
gen von Packets zuständig. Das Radio-Modul verwaltet außerdem die Zustände von
Receiver und Transmitter. Es ist entweder im Receiver-Zustand oder im Transceiver-
Zustand, modelliert also das Verhalten eines Transceivers.
Der Energieverbraucher für das Radio-Modul ist ebenfalls in diesem Verzeichnis de-
finiert, da er sich am Zustands-basierten Verhalten des Moduls orientiert. Je nach
Zustand modelliert er einen anderen Energieverbrauch. Darüber hinaus bietet INET
für die Bitübertragungsschicht Algorithmen zur Antennenmodulation und Modelle
zur Simulation von Umwelteinflüssen.
Abbildung 2.9: Das Basis-Radio-Modul
linklayer Das linklayer-Verzeichnis enthält Protokolle und Mechanismen der zwei-
ten Schicht des OSI-Netzwerkstacks [7]. Der Sicherungsschicht-Anteil des Protokolls
IEEE 802.15.4 ist in der Klasse Ieee802154Mac implementiert. Beim Senden eines
Pakets erstellt die Klasse einen Header, der vorne an den Kopf des Paketes angefügt
wird. Bei einem empfangen Paket prüft sie, ob es korrekt empfangen wurde, d.h.
ohne Bitfehler, und die Zieladresse des Pakets mir der Adresse des Knotens, auf
dem das Paket verarbeitet wird, übereinstimmt. Wenn das empfangen Paket wei-
terverarbeitet werden kann, wird der 802.15.4-Header entfernt und das Paket an die
nächsthöhere Schicht übergeben.
networklayer und transportlayer Die in diesen Verzeichnissen implementierten
Netzwerk- und Transportprotokolle, z.B. IPv4 und IPv6, bzw. UDP und TCP, wer-
den in dieser Arbeit nicht benötigt. Jedoch verlangt die Ieee802154Mac-Klasse ein
Netzwerkprotokoll, weshalb in Kapitel 3 ein Platzhalter-Protokoll eingefügt wird.
applications Im applications-Verzeichnis wird der Großteil dieser Arbeit implemen-
tiert. Es enthält Anwendungsmodelle, welche die auf den Schichten 1 bis 4 bereitge-
stellten Protokolle nutzen. Dazu gehören u.a. ein DHCP-Server und DHCP-Client
32

2 Grundlagen
sowie ein HTML-Browser.
Die generische Basis-Klasse ApplicationBase wird in Kapitel 4 durch spezialisierte
Anwendungs-Klassen erweitert, die das RACA-Framework nutzen. Die entsprechen-
den Anwendungs-Module implementieren dabei das IApp-Interface.
common Dieses Verzeichnis enthält diverse Werkzeuge, welche die Arbeit mit der
INET Modell-Bibliothek vereinfachen, und grundlegende Datenstrukturen, auf de-
nen andere Komponenten aufbauen. Dazu gehört z. B. die oft genutzte Packet-
Klasse, die eine Spezialisierung der OMNeT++-Klasse cPacket ist. Packet hat eine
dreireilige Struktur, siehe dazu Abbildung 2.10 und einige nützliche Methoden. Dar-
unter Abfrage der Länge des Pakets, Einfüge- und Entferne-Operationen, jeweils am
Anfang und Ende des Pakets, Serialisierung zu und Deserialisierung von einer Bit-
folge sowie peek und pop Methoden, die einen Teil des Pakets zurückgeben, ohne
diesen zu löschen.
Abbildung 2.10: Die INET-Paket-Struktur
Die pop Methode verschiebt zusätzlich den front- bzw. back pointer, die jeweils auf
den Anfang und das Ende des data parts zeigt. Die Methode wird genutzt, wenn
das Paket mehrere Protokolle durchläuft, die alle ihre eigenen Header oder Trailer
verarbeiten. Diese verarbeiteten Segmente fallen dann in den front popped part oder
back popped part. Der data part enthält die nicht verarbeiten Segmente.
Eine zweite mächtige Datenstruktur, die in INET genutzt wird, sind Chunks. Sie
repräsentieren Daten, z.B. Protokollheader innerhalb eines Pakets. Der Vorteil der
Chunk-Klasse ist die Eigenschaft, dass sie Daten sehr flexibel darstellen und kom-
binieren kann. Chunks lassen sich als Folge von Bits oder Bytes darstellen, können
zu SequenceChunks kombiniert und auf mehrere kleinere Chunks aufgeteilt werden.
Der Anwender kann Chunks mit diversen Einträgen oder Feldern definieren. Ein
solcher Chunk heißt FieldsChunk. In Kapitel 3 werden die RACA-Paketstrukturen
durch FieldsChunks implementiert.
Das common-Verzeichnis enthält außerdem u.a. Datenstrukturen für physikalische
Einheiten und eine Protocol-Klasse, die alle verfügbaren Protokolle verwaltet.
environment Klassen zur Modellierung der physikalischen Umwelt werden sind im
environment-Verzeichnis zu finden. Das ist z.B. die Material-Klasse, die Eigenschaf-
ten wie Durchläsigkeit beschreibt, oder wie ein Radio-Signal an dem modellierten
Material gebrochen wird. Umwelteinflüsse werden in dieser Arbeit nicht explizit be-
trachtet.
33

2 Grundlagen
mobility In diesem Verzeichnis befinden sich die Mobilitäts-Modelle von INET, wel-
che die Bewegung von Netzwerkknoten beschreiben. Das mobility-Verzeichnis wird
nicht weiter vertieft, da diese Arbeit ein statisches Netzwerk nutzt.
node Das node-Verzeichnis enthält ausschließlich NED-Dateien, die einige Arten
von Netzwerkknoten, durch das Zusammensetzen geeigneter Submodule definieren.
Abbildung 2.11 zeigt das Sensorknoten-Modell der INET-Bibliothek. Die Kom-
ponenten auf der linken Seite sind allen Netzwerkknoten gemeinsam. Der Rest
der Abbildung zeigt die Implementierung des Netzwerkstacks. Die unterste Ebe-
ne stellt verschiedene Netzwerkschnittstellen zur Verfügung, die ihrerseits wiederum
die Bitübertragungs- und Sicherungsschicht implementieren. Der Sensorknoten hat
eine Loopback- und eine WLAN-Schnittstelle. Letztere nutzt das Protokoll IEEE
802.15.4.
Auf der nächsten Ebene können das IPv4, IPv6 oder ein generisches Netzwerkpro-
tokoll genutzt werden. Standardmäßig nutzt der Sensorknoten IPv4.
Die dritte Ebene bildet die Transportschicht. Der Sensorknoten nutzt vorkonfigu-
riert UDP und TCP. Die Verwendung von SCTP kann, wie die Nutzung anderer
gegebener Komponenten, vom Anwender in der ini-Datei angepasst werden.
Die oberste Ebene enthält die Anwendungen, die auf dem Sensorknoten laufen sol-
len. Im default-Wert wird die Anzahl der Anwendungen auf null gesetzt und in einem
konkreten Modell durch den numApps-Parameter bestimmt.
In Kapitel 3 wird ein spezieller Sensorknoten nach diesem Vorbild erstellt, dessen
Stack nur aus Bitübertragungs-, Sicherungs- und Anwendungsschicht besteht.
Abbildung 2.11: Das Sensorknoten-Modell der INET-Bibliothek
power Komponenten, welche die Energiemodellierung betreffen sind im power-
Verzeichnis. Hier existieren im Wesentlichen vier Konzepte. Das erste ist der Ener-
giespeicher. Er besitzt einen Kapazität und ist typischerweise genau einmal in einem
Netzwerknoten verfügbar. Das zweite Konzept ist der Energieverbraucher, der die
34

2 Grundlagen
Leistungsaufnahme einer Komponente beschreibt. Es kann verschiedene Verbraucher
in einen Knoten geben. Ein Verbraucher ist meist dem Radiomodul, genauer, dem
Transceiver zugeordnet und wird im physicallayer-Verzeichnis definiert. Für diese
Arbeit wird ein weiterer Verbraucher erstellt, der den Energieverbrauch des Sensors
modelliert.
Ein weiteres Konzept ist der Energiegenerator, der umgekehrt analog zum Verbrau-
cher funktioniert. Indem er Leistung generiert, kann er den Energiespeicher aufladen.
Das letzte Konzept ist der Energiemanager. Er kann dafür sorgen , dass ein Netz-
werkknoten aktiviert wird, wenn sein Energiespeicher über ausreichend Kapazität
Energie verfügt, bzw. deaktiviert wird, wenn das Energieniveau des Speichers unter
ein angegebenes Level sinkt.
routing Im routing-Verzeichnis sind einige Routing-Protokolle enthalten, darunter
AODV und DSDV. Da in dieser Arbeit keine Routingverfahren genutzt werden, wird
das routing-Verzeichnis nicht weiter vertieft.
visualizer In diesem Verzeichnis finden sich Klassen, die 2D- und 3D-Komponenten
sowie Signale grafisch darstellen. Das in dieser Arbeit erstellte Netzwerk nutzt einen
Visualisierer, um Paketübertragungen in der OMNeT++-GUI darzustellen.
Im nächsten Kapitel wird gezeigt, wie das RACA-Framework in die INET-Bibliothek
integriert wird.
35

3 Integration des RACA-Frameworks
3.1 Die Komponenten
Das RACA-Framework ist modular aufgebaut. In diesem Abschnitt werden zunächst
die einzelnen Module, oder Komponenten, vorgestellt. Die Funktionsweise der Kom-
ponenten und die verwendeten Datenstrukturen werden erklärt.
Die Implementierung des Resource-based Application Clustering Approach, die dieser
Arbeit als Grundlage dient, wurde auf einem Mikrocontroller in C umgesetzt. Die
einzelnen Komponenten sind aufgrund der Eigenschaften der Programmiersprache
C nicht in Klassen gekapselt, sondern lediglich in Dateien. Um eine eventuelle Por-
tierung des geänderten und erweiterten Frameworks zurück in eine Mikrocontroller-
Umgebung einfach zu gestalten, wird darauf verzichtet, eine Kapselung in Klassen
nach dem Objekt-orientierten Schema vor zu nehmen. Der bestehende C-Code soll
nur angepasst werden, um eine neue Anwendung zu nutzen, da ursprünglich nur die
Steuerung einer LED auf einem Sensorknoten umgesetzt war.
Der Resource-based Application Clustering Approach ist ein hierarchisches System,
bei dem den Netzwerkknoten Rollen zugeordnet werden. Ein Knoten kann dabei
auch mehrere Rollen annehmen.
Jeder Netzwerkknoten ist auf der untersten Ebene immer ein Application Node, also
ein Knoten, der eine Anwendung unmittelbar ausführt. In dieser Arbeit handelt es
sich dabei immer um das Messen eines physikalischen Wertes.
Auf der zweiten Hierarchieebene steht der App Master, der einmalig im Anwen-
dungscluster (siehe Abschnitt Coordinator) ist, aber mehrfach im gesamten Netz-
werk auftreten kann.
An der Spitze des Systems steht der Coordinator. Er ist, im Gegensatz zu den an-
deren Rollen, einmalig im gesamten Netzwerk. Obwohl die Rolle des Coordinators
grundsätzlich nicht an einen festen Knoten gebunden ist, wird in dieser Arbeit darauf
verzichtet, die Auswahl des Coordinators in das RACA-Framework zu integrieren.
Es existieren Algorithmen zur Auswahl eines geeigneten Knotens, ein Beispiel findet
sich in [11]. Der Coordinator wird deshalb für ein Modell festgelegt und ändert sich
während der Simulation nicht. Seine Adresse ist allen anderen Knoten im Netzwerk
bekannt.
Der Ansatz unterscheidet zwischen globalen Anwendungen, die das gesamte Netz-
werk umfassen, und lokale Anwendungen, die nur auf Sensorknoten laufen.
Coordinator Als oberster Knoten der Hierarchie steht der Coordinator auch als
erster Knoten in der Verarbeitungskette eines Ereignisses. Dieses Ereignis kann dabei
von einem externen oder internen Knoten ausgelöst werden, der nicht Bestandteil
36

des RACA-Frameworks sein muss. Im Allgemeinen ist ein solches Ereignis eine Auf-
gabe, die durch das Sensornetzwerk zu erfüllen ist, die globale Anwendung. Dazu
gehören z.B. das Erheben von Messwerten in einem bestimmten Bereich oder die
Ausführung einer anderen Anwendung, die auf dem Knoten läuft. Die Funktion, die
ein Ereignis verarbeitet, heißt receiveEvent. Im Wesentlichen gibt es zwei Varianten,
die bei dieser Funktion auftreten können.
Bei der ersten Variante gibt es im Netzwerk keine laufende Anwendung, die für das
Ereignis geeignet ist. In diesem Fall soll eine neue Anwendung gestartet werden. Da-
bei sendet der Coordinator ein NodeRequest-Paket an alle Knoten. Alle Knoten die
geeignet sind, antworten auf diese Anfrage. Geeignete Knoten sind alle Knoten, die
über ausreichend Ressourcen und die passende Position verfügen, um die angefor-
derte Anwendung auszuführen. Am Beispiel der Erhebung von Messdaten in einem
bestimmten Bereich heißt das, der Knoten muss in diesem Bereich liegen, damit er
geeignet ist. Diese Knoten bilden einen Anwendungscluster und werden in der Node
Entry List gespeichert, deren Elemente Node Entry heißen. Ein Node Entry enthält
die ID des Knotens und Informationen über die Ressourcen, die dem Knoten zur
Verfügung stehen.
Im zweiten Fall läuft bereits eine Anwendung, die zu dem ausgelösten Ereignis passt.
Diese Anwendung wird dann aktualisiert, indem ein Application-Update-Paket an
den App Master gesendet wird.
Die zweite Aufgabe des Coordinators ist, aus den für das Ereignis geeigneten Kno-
ten, den App Master zu wählen. Als App Master wird der Knoten mit der größten
Restenergie gewählt.
Der Coordinator verwaltet die im Netzwerk laufenden Anwendungen in der Coordi-
nator App List. Diese ist ein Feld mit Elementen vom Typ Coordinator App Entry,
siehe Tabelle 3.1.
Variablenname Bedeutung
globalAppId Im gesamten Netzwerk gültige ID der Anwendung.
status Status der Anwendung (u.a. RUN, REQUEST APP,
DONE).
masterId Knoten-ID des App Masters der Anwendung.
masterIdAlt Knoten-ID eines alternativen App Masters.
event Event-Nummer.
timestamp Zeit der letzten Änderung in Millisekunden.
Tabelle 3.1: Coordinator-App-Entry-Struktur
App Master Der App Master steht in der Hierarchie unter dem Coordinator. Der
App Master ist einmalig in einem Anwendungscluster, aber im gesamten Netzwerk
kann es mehrere App Master geben.
Die Hauptaufgabe dieser Komponente ist die Auswahl der am besten geeigneten
Knoten aus dem gesamten Anwendungscluster. Das Kriterium, nachdem diese Aus-
37

wahl getroffen wird, sind die dem Knoten verfügbaren Ressourcen. Es wird in dieser
Arbeit davon ausgegangen, dass alle Sensorknoten über die gleiche Hardware ha-
ben. Die entscheidende Ressource ist die Restenergie der Knotens. Die Anzahl der
Knoten, die durch den App Master ausgewählt werden, ist vom Anwender konfigu-
rierbar. An die ausgewählten Knoten wird ein Application-Paket gesendet, um die
lokale Anwendung auf den Knoten zu starten.
In dieser Arbeit bekommt der App Master außerdem die Aufgabe, die Messergebnisse
der Knoten zusammenzufassen und das Ergebnis an eine Datensenke zu übermit-
teln. Die Datensenke bleibt während der Simulation unverändert und ist identisch
mit dem Knoten, der das Ereignis ausgelöst hat.
Um die Messwerte zu speichern, die durch verschiedene Knoten gesammelt werden,
nutzt der App Master die Result List.
Die folgenden Komponenten beschreiben keine expliziten Rollen, sondern kommen
auf jedem Knoten zum Einsatz.
Application Die Application-Komponente ist für die Ausführung der lokalen An-
wendung zuständig. Anhand einer übergebenen ID, die die Anwendung lokal iden-
tifiziert, entscheidet die Komponente, welche der auf dem Knoten registrierten An-
wendungen auszuführen ist.
App Manager Der App Manager verwaltet alle auf einem Sensorknoten regis-
trierten Anwendungen. Diese sind in der App List organisiert. Sie besteht aus
Application-Elementen, siehe Tabelle 3.2, welche die wichtigsten Informationen zu
einer Anwendung enthalten. Der App Manager selbst führt fast keine Operationen
an der App List aus, sondern veranlasst den App Scheduler, Änderungen vorzuneh-
men.
Variablenname Bedeutung
id Interne ID, einmalig für jeden Eintrag der Liste.
appId Lokale ID, identifiziert die Art der Anwendung (z.B.
Temperatur messen, Luftdruck messen, ...), kann mehr-
fach vergeben werden.
status Status der Anwendung, z.B. READY, DONE, REMO-
VE.
count Anzahl der Ausführungen, Null heißt unbegrenzte
Ausführung.
master App Master der Anwendung.
parameterA Optionaler Parameter, kann beliebig genutzt werden.
parameterB Optionaler Parameter, kann beliebig genutzt werden.
start Startzeit der Anwendung in Millisekunden.
delay Verzögerung bis zur nächsten Ausführung.
Tabelle 3.2: Application-Struktur
38

App Scheduler Die App-Scheduler-Funktionen nehmen konsistente Änderungen
an der App List vor. Da die App List eine nach den Startzeiten der Anwendungen
geordnete Struktur ist, heißt das, die Funktionen des App Schedulers müssen diese
Ordnung aufrecht erhalten. Diese Funktionen werden vor allem über den App Ma-
nager aufgerufen.
Im App Scheduler sind die Listenoperationen Einfügen und Entfernen implemen-
tiert. Für das Einfügen gilt nach der genannten Bedingung, dass die neue Anwendung
an der richtigen Position eingeordnet werden muss. Beim Entfernen einer Anwen-
dung gilt, dass nachfolgende Einträge entsprechend verschoben werden müssen.
Packet Processor Diese Komponente ist die Schnittstelle des RACA-Frameworks
für alle eingehenden Pakete. Der Packet Processor wandelt die zur Übertragung
genutzten generischen Pakete in den richtigen Paket-Typ um und leitet sie an die
entsprechende Komponenten weiter. Tabelle 3.3 zeigt die verschiedenen Paket-Typen
und den Verteilungsmechanismus. Die gezeigten Pakete werden als Strukturvaria-
blen definiert. Der Packet Processor prüft außerdem die Time-to-live, kurz TTL, des
eingehenden Pakets. Diese wird genutzt, um die Laufzeit des Pakets im Netzwerk zu
begrenzen. Ist sie größer als Null, wird sie um eins verringert und das Paket weiter
gegeben. Ist sie bereits Null, wird das Paket nicht weiter verarbeitet. Die TTL ist
als Hop-Counter implementiert. Ein Hop ist die Übertragung des Pakets von einem
Knoten zum anderen. Ein Paket kann also nur so oft gesendet werden, wie die TTL
vorgibt. Da in dieser Arbeit nur Single-hop Netzwerke betrachtet werden (vgl. Ab-
schnitt 2.1.1) und die TTL standardmäßig auf 16 gesetzt ist, wird es nicht dazu
kommen, dass die Lebensdauer eines Pakets endet.
Resource Manager Der Resource Manager verwaltet die Ressourcen eines Kno-
tens. Er ist die Komponenten, die die Eignung eines Knotens für die Ausführung
einer Anwendung feststellt. Dazu verarbeitet er das Node Request Packet und prüft,
ob die benötigten Ressourcen frei sind und die Position des Knotens für die gefor-
derte Anwendung richtig ist. Wenn eine Anwendung gestartet werden soll, teilt der
Resource Manager der Anwendung die notwendigen Ressourcen zu. Umgekehrt gibt
er die Ressourcen wieder frei, wenn die Anwendung beendet wurde.
Die Verwaltungsstruktur für Ressourcen ist die Resource Map. Jeder Resource Map
Eintrag wird über eine App ID aufgerufen, die eine Anwendung eindeutig bestimmt.
Zu jeder Anwendung finden sich in der Resource Map Informationen über die benötig-
ten Ressourcen, benötigte Energie, Dauer und CPU-Auslastung. In der vorliegenden
Implementierung wird jedoch nur die Information über die benötigten Ressourcen
verwendet. Die Resource Map kann statisch angelegt werden, aber es wird in dieser
Arbeit auch eine Schnittstelle geschaffen, über die sich jede Anwendung mit den
benötigten Ressourcen in die Resource Map eintragen kann.
Timer Die Timer-Komponente verwaltet die Timer des RACA-Frameworks und
den internen Zeitzähler. Ein Timer besteht aus einer ID und einem Zeitwert, der die
nächste Verarbeitung des Timers festlegt. Die Timer-Komponente stellt zunächst
eine Funktion bereit, die es erlaubt, den Wert eines Timers zu ändern. Der Wert
kann gelöscht, also auf Null gesetzt, auf einen bestimmten Wert gesetzt oder um
39

Packet-Typ Bedeutung Weitergeleitet an
Generic Packet Ethält allgemeine Informationen wie Quelle,
Ziel, Packet-Typ und 100 Byte Speicherplatz
für die Informationen der anderen Packet-
Typen bereitstellt. Für Übertragung genutzt.
—
Event Packet Enthält das Event codiert als Zahl. Coordinator
Node Request Packet Anfrage an einen Knoten, ob er geeignet ist,
eine Anwendung auszuführen.
Resource Manager
Node Response Packet Antwort eines Knotens:
”
Knoten geeignet“
oder
”
Knoten nicht geeignet“.
Coordinator
App Master Request
Packet
Paket, das die ID der zu startenden Anwen-
dung und Informationen über alle für die An-
wendung geeigneten Knoten entält.
App Master
Application Execute
Packet
Übermittelt alle wichtigen Parameter einer
Anwendung an einen Knoten und .
App Manager
Application Update
Packet
Wird gesendet, wenn eine laufende Anwen-
dung aktualisiert werden soll.
App Manager
Application Result
Packet
Paket, welches das Ergebnis der Anwendung
enthält, z.B. Messwert.
App Master
App Master Response
Packet
Dieses Paket informiert den Coordinator
darüber, obeine Anwendung gestartet wurde.
Coordinator
App Master Summary
Packet
Zusammenfassung der Ergebnisse einer ver-
teilt ausgeführten Anwendung.
externe Datensenke
Tabelle 3.3: Paket-Typen im RACA-Framework
einen Wert erhöht und direkt auf einen Versatz zur aktuellen Zeit gesetzt werden.
Der Coordinator Request Timer, wird gesetzt, wenn der Coordinator ein Event
empfängt und nach geeigneten Knoten sucht. Der Timer-Wert wird dabei auf die
aktuelle Zeit plus die Coordinator-Request-Timeout-Zeit gesetzt, die über die so be-
nannte Konstante definiert ist. Zu dem Zeitpunkt, der dem Timer-Wert entspricht
wird eine Aktion ausgelöst. In diesem Fall heißt das, dass bis dahin alle geeigneten
Knoten geantwortet haben müssen und aus diesen der App Master gewählt wird,
an den dann das App Master Request Packet gesendet wird.
Der nächste Timer ist der Application Timer, der genutzt wird, um eine Anwendung
zu starten. Sein Timer-Wert wird immer auf die Startzeit der ersten Anwendung in
der App List gesetzt, also der Anwendung, die als nächstes gestartet werden soll.
Der dritte Timer ist der Sleep-Timer. Zu dem Zeitpunkt, der seinem Timer-Wert
entspricht, wechselt der Knoten in den Schlaf-Modus, d.h der Haupt-Transceiver
ist inaktiv und der Wakeup-Receiver wird genutzt. Ab diesem Zeitpunkt kann der
Knoten keine Pakete außer einem speziellen Wakeup-Paket empfangen. Dieser Ti-
mer wird zur Modellierung des Wakeup-Konzepts genutzt, die genaue Implemen-
tierung wird im nächsten Abschnitt beschrieben. Obwohl die Timer-Komponente
intern mehrere Timer verwalten kann, repräsentiert sie nach ausßen nur einen Ti-
mer, den sogenannten System Timer. Das funktioniert, indem sie dem System Timer
immer die ID und den Wert des nächsten Timer-Events zuweist.
40

3.2 Implementierung
3.2.1 Die RacaFramework-Klasse
Nachdem im letzten Abschnitt die Komponenten des RACA-Frameworks betrach-
tet wurden, wird in diesem Abschnitt gezeigt, wir die Komponenten in die INET-
Modellbibliothek integriert werden.
Die C++-Quelldateien des Frameworks befinden sich in der INET-Bibliothek unter
dem Ordner src/inet/applications/raca/framework, siehe dazu Abschnitt 2.2.2. In
dem dort enthaltenen src-Ordner sind die Funktionen der oben genannten Kom-
ponenten definiert. Im inc-Ordner sind Header-Dateien, welche die im Framework
verwendeten Datentypen, Strukturen und Konstanten definiert werden. Um die ein-
zelnen Komponenten möglichst portabel zu gestalten, sind alle darin vorgenomme-
nen Änderungen C-kompatibel.
Um das RACA-Framework in die Objekt-orientierte Struktur von OMNeT++/INET
zu integrieren, werden alle Komponenten in die RacaFramework-Klasse gekapselt.
Die Anwendung die auf einem Sensorknoten laufen soll , muss eine Instanz dieser
Klasse erzeugen. Sie bildet die Schnittstelle zwischen der Simulationsbibliothek und
den RACA-Komponenten, siehe Abbildung 3.1. Die Methoden, die mit der Simulati-
onsbibliothek interagieren sind in der Datei RacaFramework.cc definiert und werden
im Folgenden erklärt.
Abbildung 3.1: Die Klasse RacaFramework als Schnittstelle zwischen Simulations-
umgebung und den Komponenten
Konstruktor
Die Konstruktor-Methode ruft die init-Funktionen der Komponenten auf, um die
Datenstrukturen zu initialisieren, die bereits aus diesen bekannt sind. Dem Kon-
struktor wird ein cSimpleModule-Objekt übergeben, das die Anwendung repräsen-
tiert, die auf dem Sensorknoten läuft. Über diese Modul werden dem RACA-Objekt
drei weitere Module bekannt gemacht. Die baseHost-Variable referenziert das Host-
Modul der Anwendung, also das gesamte Knotenmodul. Von diesem Modul aus kann
auf zwei weitere wichtige Module zugegriffen werden. Zum einen auf Energy-Storage-
Submodul des Knotens und zum anderen auf das Radio-Submodul.
41

RacaFramework :: RacaFramework(cSimpleModule* baseApp , int socketOut)
{
this ->baseApp = baseApp;
this ->baseHost = FindModule <>:: findHost(baseApp);
this ->energyStorage
= (power :: SimpleCcEnergyStorage *) baseHost -> getModuleByPath (".
energyStorage");
this ->radio
= (physicallayer :: Radio *) baseHost -> getModuleByPath (".wlan.
radio");
this ->socketOut = socketOut;
...
}
Listing 3.1: Modulreferenzen im Konstruktor der RacaFramework-Klasse
Dafür stellt die cModule-Klasse der OMNeT++-Bibliothek die Methode getModule-
ByPath zur Verfügung. Der angegebene Pfad beschreibt die Position des gesuchten
Moduls in der Modulstruktur, die durch die NED-Sprache beschrieben wird. Ein
Pfad, der wie in Listing 3.1 mit einem Punkt beginnt, wird relativ zu dem Modul
interpretiert, von dem die Methode aufgerufen wird. Dem Konstruktor wird außer-
dem die Nummer des Gates übergeben, über das die Pakete gesendet werden sollen.
Des Weiteren erstellt der Konstruktor, wie in Listing 3.2 gezeigt, ein Objekt vom Typ
cMessage. Dieses Objekt entspricht dem System Timer. Ihm werden zwei Parameter
zugewiesen. Erstens, eine ID, die den internen Timer identifiziert, siehe Abschnit 3.1
und zweitens, den Wert des unter erstens zugewiesenen Timers. Der System Timer
repräsentiert alle Timer, die intern unterschieden werden, in einer Instanz.
Dem internen Zeitzähler, der Membervariable ticks, wird die aktuelle Simulationszeit
über die Funktion simTime zugewiesen. Über die Methode inUnit kann die Zeitein-
heit bestimmt werden. Hier wird die Einheit Millisekunde gewählt. SIMTIME MS
ist der Wert des der Vorsilbe
”
Milli“ entsprechenden Exponenten, -3.
RacaFramework :: RacaFramework(cSimpleModule* baseApp , int socketOut)
{
...
sysTimer = new cMessage("sysTimer");
sysTimer ->addPar("timerId");
sysTimer ->addPar("timerValue");
...
updateTickCounter (simTime ().inUnit(SIMTIME_MS));
...
updateTimer(TIMER_ID_SLEEP_TIMER , TIMER_TYPE_OFFSET , sleepTimeout
+ baseApp ->uniform (0, 1) * pow(10, SIMTIME_MS));
}
Listing 3.2: Timer-Initialisierung im Konstruktor der RacaFramework-Klasse
42

Abschließend wird im Konstruktor der Sleep Timer auf den Wert der aktuellen Zeit
plus sleepTimeout plus einer Zufallszahl zwischen 0 und 1 gesetzt, die Einheit ist
Millisekunde. Die Membervariable sleepTimeout wird standardmäßig mit der sym-
bolischen Konstante DEFAULT SLEEP TIMEOUT, also 1000 Millisekunden, in-
itialisiert. Die Nutzung eines Zufallswertes bewirkt, dass nicht alle Netzwerkknoten
zeitgleich in den Schlafmodus wechseln. Dieses Verhalten wäre nicht realistisch. Zu-
sammengefasst hat diese Funktion zur Folge, dass ein Knoten ca. eine Sekunde nach
Start der Simulation den Haupt-Transceiver deaktiviert und den Wakeup-Receiver
nutzt.
sendPacket
Die sendPacket-Methode kapselt die im Raca-Framework genutzten Paketstrukturen
in die von INET bereitgestellte Packet-Klasse. Zu Beginn der Methode wird geprüft,
ob die TTL des zu senden Paktes bereits abgelaufen ist. Wenn ja, wird das Paket
nicht gesendet.
Andernfalls erstellt die Methode ein neues Packet-Objekt mit dem Namen
”
gene-
ricPacket“ und ein Chunk-Objekt vom Typ RacaGenericChunk. Dieser Chunk-Typ
ist im Ordner src/inet/applications/raca/packets in der entsprechenden Message-
Datei definiert. Er enthält exakt die gleichen Felder, die auch die GENERIC PACKET
Struktur enthält, die im framework-Ordner definiert ist. Dem Chunk-Objekt werden
die entsprechenden Werte aus dem Generic Packet zugewiesen, siehe dazu Listing
3.3.
void RacaFramework :: sendPacket(GENERIC_PACKET * myPacket , unsigned
short destinationNode )
{
...
Packet* genericPacket = new Packet("genericPacket");
auto genericChunk = makeShared <RacaGenericChunk >();
genericChunk ->setTtl(myPacket ->ttl);
genericChunk ->setSubType(myPacket ->subType);
genericChunk ->setPacketType(myPacket ->packetType);
genericChunk ->setPayloadsize (myPacket ->payloadsize);
genericChunk ->setSrcId(myPacket ->srcId);
...
}
Listing 3.3: Die sendPacket-Methode Teil 1
Nachdem der Chunk zusammengestellt wurde, wird er an das Ende des Pakets an-
gehängt. Darauf folgend werden in Listing 3.4 drei Tags zum Paket hinzugefügt. Die-
se Tags beinhalten Informationen für die Netzwerkschichten, die das Paket durchläuft.
Die darauf agierenden Protokolle können so wesentliche Informationen abrufen und
hinzufügen, ohne dabei das komplette Paket entpacken zu müssen.
43

Der MacAddressReq-Tag beinhaltet die Quell- und Ziel-MAC-Adresse eines aus-
gehenden Pakets. Die Zieladresse muss immer angegeben werden, die Quelladresse
kann auch unbestimmt bleiben. Anhand der in diesem Tag angegebenen Zieladresse
entscheidet das Sicherungsschicht-Protokoll bei einem ankommenden Paket, ob das
Paket für den aktuellen Knoten bestimmt ist. Wenn nicht, wird das Paket verwor-
fen.
Bei der Zuweisung der Zieladresse wird darauf geachtet, ob der Parameter desti-
nationNode die Broadcast-Adresse ist, oder einen speziellen Knoten adressiert. Im
ersten Fall wird dem Tag die in der MacAddress-Klasse statisch definierte Broadcast-
Adresse zugewiesen. Im zweiten Fall wird die Methode getMacAddress mit dem Pa-
rameter destinationNode aufgerufen. Diese Methode übersetzt die ID des gegebenen
Knotens in seine MAC-Adresse. Diese Methode ist Bestandteil der RacaFramework-
Klasse und wird später erklärt. Der zweite Tag, der PacketProtocolTag, gibt das
Protokoll an, welches das Paket weiter verarbeiten soll. Üblicherweise ist das ein
Netzwerkprotokoll auf dem Zielknoten. Da in der vorliegenden Implementierung des
RACA-Frameworks kein Netzwerk- und kein Transportprotokoll genutzt werden,
das MAC-Modul der INET-Bibliothek aber ein Protokoll verlangt, wurde ein Platz-
halter eingefügt. In der Protocol-Klasse, die im Ordner src/inet/common zu finden
ist, gibt es dafür einen neuen Eintrag, der NoProtocol heißt. Dieser Eintrag ist, wie
alle anderen Protokolle, ein statischer Member der Protocol-Klasse. Außerdem muss
das Protokoll noch der Protokoll-Gruppe ethertype zugeordnet werden. Dazu wird
ebenfalls ein NoProtocol-Eintrag in der entsprechenden Gruppe der Klasse Proto-
colGroup im selben Ordner vorgenommen.
Der InterfaceReq-Tag bestimmt das Interface, über welches das Paket gesendet wer-
den soll. Das Interface, in diesem Fall das WLAN-Interface wird über eine ID zuge-
ordnet.
void RacaFramework :: sendPacket(GENERIC_PACKET * myPacket , unsigned
short destinationNode )
{
...
genericPacket ->insertAtBack(genericChunk);
if(destinationNode == BROADCAST_ADDR )
genericPacket ->addTagIfAbsent <MacAddressReq >()
->setDestAddress (MacAddress :: BROADCAST_ADDRESS );
else
genericPacket ->addTagIfAbsent <MacAddressReq >()
->setDestAddress (getMacAddress( destinationNode ));
genericPacket ->addTagIfAbsent <PacketProtocolTag >()
->setProtocol (& Protocol :: noProtocol);
genericPacket ->addTagIfAbsent <InterfaceReq >()
->setInterfaceId (wlanInterface ->getInterfaceId ());
44

Bachelorarbeit paul gerber.pdf

Bachelorarbeit paul gerber.pdf

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Bachelorarbeit paul gerber.pdf

Ähnlich wie Bachelorarbeit paul gerber.pdf (20)

Mehr von wissem hammouda

Mehr von wissem hammouda (6)

Bachelorarbeit paul gerber.pdf