Thesis - Institut für Informatik

Computer and Communication Systems
Lehrstuhl für Technische Informatik
Leo Höckner
Experimentelle Umsetzung von Routing in
Sensornetzen basierend auf virtuellen
Koordinaten
Bachelorarbeit im Fach Informatik
29. Oktober 2012
Please cite as:
Leo Höckner, “Experimentelle Umsetzung von Routing in Sensornetzen basierend auf virtuellen Koordinaten,” Bachelor
Thesis (Bachelorarbeit), University of Innsbruck, Institute of Computer Science, October 2012.
University of Innsbruck
Institute of Computer Science
Computer and Communication Systems
Technikerstr. 21a · 6020 Innsbruck · Austria
http://ccs.uibk.ac.at/
Experimentelle Umsetzung von Routing in
Sensornetzen basierend auf virtuellen
Koordinaten
Bachelorarbeit im Fach Informatik
vorgelegt von
Leo Höckner
geb. am 3. Jänner 1990
in Braunau am Inn
angefertigt am
Lehrstuhl für Technische Informatik
Computer and Communication Systems
Institut für Informatik
Leopold-Franzens-Universität Innsbruck
Betreuer:
Abgabe der Arbeit:
Christoph Sommer
Falko Dressler
29. Oktober 2012
Erklärung
Ich versichere, dass ich die Arbeit ohne fremde Hilfe und ohne Benutzung anderer
als der angegebenen Quellen angefertigt habe und dass die Arbeit in gleicher oder
ähnlicher Form noch keiner anderen Prüfungsbehörde vorgelegen hat und von dieser
als Teil einer Prüfungsleistung angenommen wurde.
Alle Ausführungen, die wörtlich oder sinngemäß übernommen wurden, sind als
solche gekennzeichnet.
Declaration
I declare that the work is entirely my own and was produced with no assistance
from third parties.
I certify that the work has not been submitted in the same or any similar form for
assessment to any other examining body and all references, direct and indirect, are
indicated as such and have been cited accordingly.
(Leo Höckner)
Innsbruck, 29. Oktober 2012
Abstract
In this Bachelorthesis Virtual Cord Protocol, a new routing protocol for sensor networks based on virtual coordinates, developed at the University of Erlangen, will
be investigated. There was already a test of this protocol with the simulation tool
OMNeT++, but in this thesis the aim is to test the protocol on real devices in a real
environment.
Therefore the protocol has to be implemented for TelosB Sensor Nodes, which are
working with the operating system Contiki. The main parts of the implementation
were building up the network, local routing and Inter-Domain routing, which means
communication between two different domains. Afterwards there were some tests
about the performance.
In order to keep the development simple, it was first implemented and tested with
the Contiki simulator environment Cooja, the final tests were made in Cooja as well
as on the real nodes.
iii
Kurzfassung
In dieser Bachelorarbeit wird das Virtual Cord Protocol, ein Netzwerkprotokoll für
Sensornetze basierend auf virtuellen Koordinaten, welches an der Universität Erlangen entwickelt worden ist, untersucht. Nachdem das Protokoll bereits in früheren
Tests mit der Simulationssoftware OMNeT++ seine Stärken bewies, sollte nun auch
ein Test in einer realen Umgebung, auf echten Knoten, erfolgen.
Hierfür wurde das Protokoll für TelosB Sensorknoten, welche mit dem Betriebssystem Contiki betrieben werden, implementiert. Die wichtigsten Schritte dabei waren
der Aufbau des Netzwerkes, lokales Routing und Inter-Domain-Routing, die Kommunikation zwischen verschiedenen Netzwerken. Anschließend wurde das Protokoll
einigen Leistungstests unterzogen.
Für die Entwicklung und die ersten Tests wurde der Contiki Simulator Cooja verwendet, die abschließenden Tests wurden sowohl im Simulator als auch auf den
realen Knoten durchgeführt.
iv
Inhaltsverzeichnis
Abstract
iii
Kurzfassung
iv
1 Routing in Sensornetzen
1
1.1 Sensornetze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2 Virtual Cord Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.2.1 Aufbau des Netzwerk . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.2.2 Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.2.3 Inter-Domain Routing . . . . . . . . . . . . . . . . . . . . . . . . .
4
2 Verwendete Plattform
5
2.1 TelosB Knoten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.2 Contiki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.3 Cooja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
3 Funktionsweise der Implementierung
3.1 Kordelaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
9
3.1.1 Zwei aufeinanderfolgende Konten in Nachbarschaft . . . . . . 12
3.1.2 Start- oder Endknoten bekannt . . . . . . . . . . . . . . . . . . . 14
3.1.3 Virtuelle Knoten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2 Lokales Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3 Globales Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3.1 Verbreiten von Gateway Informationen . . . . . . . . . . . . . . 19
3.3.2 Versenden von globalen Nachrichten . . . . . . . . . . . . . . . . 20
4 Verifikation und Leistungsbewertung
22
4.1 Kordelaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1.1 Kordelaufbau entlang einer Line . . . . . . . . . . . . . . . . . . 23
4.1.2 Kordelaufbau im Grid . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2 Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
v
Inhaltsverzeichnis
vi
4.2.1 Kommunikation entlang einer Line . . . . . . . . . . . . . . . . . 26
4.2.2 Kommunikation im Grid . . . . . . . . . . . . . . . . . . . . . . . 26
4.2.3 Parallele Nachrichten . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2.4 Inter-Domain Nachrichten . . . . . . . . . . . . . . . . . . . . . . 29
5 Zusammenfassung
31
Literaturverzeichnis
36
Kapitel 1
Routing in Sensornetzen
Seit einigen Jahren boomt drahtlose Kommunikation. In nahezu jeder Wohnung ist
mittlerweile ein WLAN zu finden und kaum jemand kann es sich vorstellen ohne
Mobiltelefon und Kommunikation per GSM/UMTS unterwegs zu sein. In diesen
drahtlosen Netzwerken gibt es jeweils eine Base-Station, über die jedes der Geräte
mit dem Netzwerk verbunden ist. Interessanter wird es dann, wenn ein Netzwerk
ohne diese Infrastruktur auskommen und sich selbst organisieren muss, wie es bei
Sensornetzen der Fall ist.
1.1
Sensornetze
Durch aktuelle technische Entwicklungen werden immer kleinere Geräte hergestellt,
welchen durch eine Funkeinheit die Möglichkeit zur Kommunikation mit der nahen
Umgebung gegeben wird. Ein typisches Sensornetzwerk besteht aus einigen Knoten,
die als Quellen arbeiten und mit Hilfe von Sensoren Umgebungsdaten aufnehmen,
welche zu Datensenken gesendet werden.
Das Senden von Nachrichten innerhalb eines Sensornetzes ist jedoch ein herausforderndes Problem. Einem direkten Nachbarn eine Nachricht zu senden, ein
sogenannter Singlehop, siehe Abbildung 1.1, ist noch die einfachere Aufgabe: Nachdem ein geeignetes MAC1 Protokoll gefunden wurde, welches nicht nur die üblichen
Voraussetzungen zum Durchsatz oder Fehlerrate erfüllt, sondern im Besonderen
Energieeffizient sein muss, wie zum Beispiel MACAW [1], IEEE 802.15.4 [2] oder
das darauf basierende ZigBee [3], braucht das Paket nur mehr auf den Kanal gelegt
werden und der Zielknoten kann es empfangen.
Schwieriger wird es, wenn der Zielknoten nicht in der direkten Umgebung liegt. In
1
MAC - Media access control
1
1.1 Sensornetze
2
(a) Singlehop
(b) Multihop
Abbildung 1.1 – Vergleich von Single- und Multihop
diesem Fall kann das Paket nur per Multihop zu ihm gelangen, was bedeutet, dass
die Daten zuerst an einen Zwischenknoten gesendet werden und dieser die Daten
wiederum weitersendet, bis sie am Ziel sind. Damit das Paket weder verloren geht
noch ewig in einem Zykel weitergeleitet wird, wird ein Routingprotokoll benötigt.
Bei diesen Verfahren ist es für Sensornetze nicht nur entscheidend, dass die Daten
sicher und möglichst schnell am Ziel ankommen, es gibt auch eine Menge anderer
Aspekte zu beachten [4]:
• Sensorknoten werden meist per Batterie betrieben, Energie ist wertvoll
• Speicher und Rechenleistung sind begrenzt
• In vielen Fällen bewegen sich die Knoten, die Topologie des Netzwerks ändert
sich ständig
• Die Anzahl der Knoten in einem Netzwerk kann riesig werden, das Verfahren
muss skalieren
Grundsätzlich lassen sich Routingprotokolle in Proactive und Reactive einteilen.
Beim Proaktiven Routing ist die Route von der Quelle zum Ziel ständig bekannt.
Das bedeutet, dass jeder Knoten eine Routingtabelle besitzt, in der die möglichen
Senken aufgelistet sind, deswegen wird dieses Verfahren auch Table-Driven genannt.
Der Vorteil ist, dass ein Paket sofort ohne das Ermitteln der Route und dem daraus
resultierenden Zeitaufwand gesendet werden kann. Dies geschieht jedoch zu dem
Preis, dass bei jeder Topologieänderung die Routingtabellen upgedatet werden müssen und somit ein riesiger Overhead entsteht. Eines der bekanntesten proaktiven
Routingverfahren ist Destination-Sequence Distance Vektor [5].
Im Gegensatz dazu stehen reaktive Verfahren. Bei diesen wird die Route nur dann
ermittelt, wenn sie benötigt wird. Die Vor- und Nachteile sind umgekehrt wie beim
Proactiven: Kaum Overhead, da nur im Bedarfsfall die Route berechnet wird, dafür
kann das Paket deswegen nicht sofort gesendet werden. Ein bekannter Vertreter von
1.1 Sensornetze
3
reaktivem Routing ist Dynamic Source Routing [6].
Die hier genannten Verfahren sind leider nicht ideal, da bei größeren Netzwerken
entweder die ganze Topologie bekannt sein muss oder die Kommunikation sehr viel
Zeit in Anspruch nimmt und somit die Protokolle nicht skalieren.
Daneben gibt es noch viele weitere Verfahren, angefangen bei Hybriden zwischen
den beiden gerade beschriebenen Techniken, über hierarchischen Verfahren bis hin
zu Verfahren, welche die aktuellen GPS Daten ermitteln und damit eine optimale
Route zum Ziel berechnen [7]. Diese Verfahren skalieren gut, jedoch ist die Abfrage
der aktuellen Position, wenn überhaupt möglich, sehr teuer und dadurch für viele
Anwendungen nicht geeignet [8].
1.2
Virtual Cord Protocol
Ein anderer Ansatz zum Routing besteht darin, virtuelle Koordinaten zu verwenden. Hierfür wird jedem Knoten eine virtuelle Adresse zugewiesen und somit ein
Overlay-Netzwerk erzeugt [9]. Im konkreten Fall von VCP entspricht diese virtuelle
Adresse einer Position. Dadurch lässt sich das gesamte Netzwerk als eine Kordel mit
Anfangsknoten und Endknoten vorstellen. Durch die Position ist es möglich, Pakete
im virtuellen Overlay-Netzwerk entlang der Kordel zum Ziel zu routen. Dies hilft,
Routingtabellen sehr klein zu halten, hat jedoch den Nachteil, dass beim Erstellen
des Overlay-Netzwerks die physikalische Struktur nicht betrachtet wird und somit
das Routing entlang der virtuellen Positionen eventuell längere Distanzen zu bewältigen hat.
1.2.1
Aufbau des Netzwerk
Zu Beginn ist nur ein Startknoten im Netzwerk. Dieser muss im Voraus bereits als
Startknoten initialisiert werden. Jeder Knoten innerhalb der Kordel sendet periodische Hello-Messages via Broadcast aus, mit Hilfe derer andere Knoten Informationen
über das Netzwerk erhalten.
Sobald ein neuer Knoten genug Informationen über das Netzwerk erhalten hat, versucht er sich in die Kordel einzugliedern. Hierfür gibt es verschiedene Algorithmen,
welche im Paper [10] aufgelistet sind.
1.2 Virtual Cord Protocol
1.2.2
4
Routing
Da jeder Knoten in der Kordel seinen virtuellen Vorgänger und Nachfolger kennt, ist
es einfach, ein Paket entlang der Kordel zu seinem Ziel zu transportieren. Dies ist
nicht immer die effektivste Methode, da es sein kann, dass der Zielknoten in direkter
physikalischer Nachbarschaft liegt, die virtuelle Position aber am anderen Ende der
Kordel. Hierfür gibt es im Virtual Cord Protocol das Konzept des Greedy Forwarding,
durch welches das Paket an den physikalischen Nachbarn mit der nächsten Position
zum Zielknotens weitergeleitet wird.
1.2.3
Inter-Domain Routing
Da es mehrere verschiedene Kordeln geben kann, muss auch eine Kommunikation
zwischen den Kordeln ermöglicht werden. Dies wird mit Gateways realisiert [11].
Jeder Knoten, in dessen physikalischer Nachbarschaft sich Knoten einer anderen
Kordel befinden, fungiert als Gateway und sendet diese Information in der gesamten
Kordel aus. Alle anderen Knoten empfangen diese Informationen und speichern sie
ab. Möchte nun ein Knoten ein Paket in eine andere Kordel schicken, so durchsucht
er die empfangenen Informationen nach einem passenden Gateway, an den er das
Paket sendet. Der Gateway leitet das Paket an sein Gegenüber der anderen Kordel
weiter, dieser wiederum sorgt dafür, dass es beim Empfänger landet. Abbildung 1.2
veranschaulicht das Konzept.
99
1
12
50
75
40
1
25
90
99
92
Abbildung 1.2 – Idee des Inter-Domain Routings, Knoten 12 bzw 50 fungieren
als Gateway mit Knoten 40
Kapitel 2
Verwendete Plattform
Im folgenden Abschnitt wird die Plattform vorgestellt, für welche das Virtual Cord
Protocol implementiert wurde. Außerdem wird kurz auf den Simulator, mit dem ein
Großteil der Entwicklung durchgeführt wurde, eingegangen.
2.1
TelosB Knoten
Als Programmierplattform wurde in diesem Projekt TelosB (Abbildung 2.1), ein IEEE
802.15.4 kompatibler Sensorknoten, gewählt. Entwickelt wurde diese Plattform an
der University of California, Berkeley, sie wird sowohl von MEMSIC 2 als auch von
Sentilla 3 , jedoch unter dem Namen TMote Sky, vertrieben. Die Plattform wurde
für die Entwicklung von Niedrig-Energie Anwendungen sowie für Experimente mit
Sensornetzen entwickelt und ist dadurch kein Massenprodukt und somit auch relativ
teuer.
Das Herzstück der Plattform bildet ein MSP430 16bit-Mikrocontroller mit 10kB
2
3
http://www.memsic.com
http://www.sentilla.com
Abbildung 2.1 – TelosB Knoten
5
2.1 TelosB Knoten
6
RAM, welcher von Texas Instruments für Anwendungen mit niedrigstem Stromverbrauch entwickelt wurde [12]. Der Mikrocontroller ist direkt mit einem CC2420
Radio Transceiver verbunden, welcher eine Datenübertragung mit bis zu 250 kbps
ermöglicht [13].
Darüber hinaus sind auf dem Knoten zwei Sensoren verbaut, einerseits ein Sensirion SHT11 [14], Temperatur- und Luftfeuchtigkeitssensor, sowie ein Hamamatsu
S1087 [15], ein Licht- und Infrarotsensor.
Zur Programmierung und auch als Energiequelle ist eine USB-Schnittstelle verbaut.
Eine weitere Möglichkeit zur Energieversorgung ist der aufgebaute Batterieblock,
womit der Knoten mit zwei AA-Batterien betrieben werden kann.
Als Debug-Werkzeug stehen eigentlich nur ein Taster und drei Dioden in unterschiedlichen Farben zur Verfügung. Jedoch ist es möglich, eine JTAG4 Schnittstelle
anzubauen, mit Hilfe derer ein angenehmes Debuggen ermöglicht wird.
2.2
Contiki
Die im letzten Abschnitt beschriebenen TelosB Knoten werden im Projekt mit dem
Betriebssystem Contiki [16] betrieben. Contiki ist ein freies Betriebssystem für 8-Bit
Mikrocontroller, welches vom Team um Adam Dunkels am SICS 5 entwickelt wurde.
Das Ziel bei der Entwicklung von Contiki war es, ein leichtgewichtiges Betriebssystem zu entwickeln, welches mit wenig Energie und mit wenig Speicher auskommt.
Um sowohl dieses Ziel als auch Nebenläufigkeit zu erreichen, wurde der Kernel
eventbasiert mit Hilfe von Protothreads [17] entwickelt. Protothreads ermöglichen
einen sehr leichtgewichtigen Mechanismus zur nebenläufigen Programmierung, da
diese im Gegensatz zu normalen Threads über keinen eigenen Stack verfügen. Dies
bringt jedoch die Einschränkung, dass lokale Variablen bei einem Contextswitch
nicht gesichert werden können. Somit ist beim Programmieren darauf zu achten,
diese statisch oder global anzulegen. Ein wichtiger Aspekt von Protothreads ist
außerdem, dass der Contextswitch nur dann durchgeführt werden kann, wenn der
aktuell laufende Thread dazu bereit ist. Gibt dieser die Kontrolle nie ab, degeneriert
das System zu einem Single-Thread System.
Contiki bietet bereits eine Vielzahl von implementierten Netzwerkprotokollen. Angefangen bei dem für Sensornetzwerke typischen Broadcast, breitgestellt durch
den RIME-Stack, sowie dem darauf aufbauenden Unicast bis hin zu komplexeren
Protokollen für Sensornetzwerke wie Netflood, Tickle oder auch Mesh. Um eine
Anbindung zum Internet zu ermöglichen, gibt es zusätzlich bereits Protokolle wie
4
5
Joint Test Action Group, auch bekannt als IEEE 1149.1
Swedish Institue of Computer Science http://www.sics.se
2.2 Contiki
7
IPv4 und IPv6, implementiert durch den uIP Stack6 .
Zusätzlich wird bei der kabellosen Datenübertragung Energie gespart, indem auf
Idle Listening, das bekannterweise sehr teuer ist, verzichtet wird. Um trotzdem eine
fehlerfreie Kommunikation zu ermöglichen, lauscht jeder Knoten kontinuierlich,
ob Daten anliegen. Möchte ein Knoten Daten senden, muss er diese mindestens
für die Dauer eines Zeitschlitzes senden, sodass garantiert ist, dass während des
Sendevorgangs jeder Knoten die Möglichkeit hat, die Daten zu empfangen.
Um Daten auf Flashspeichern permanent zu speichern, ohne sich über diverse Sektoren im Speicher Gedanken machen zu müssen, bietet Contiki das sogenannte Coffee
Filesystem an, welches Anwendungen erlaubt, Dateien am Flash einfach zu öffnen,
zu schließen, zu lesen und zu schreiben.
2.3
Cooja
Um nicht jeden einzelnen Programmierschritt aufwendig auf den realen Knoten
testen zu müssen, wurde ein Simulator, Cooja, entwickelt. Cooja wurde in Java
entwickelt, wobei die grafische Oberfläche mittels Java Swing realisiert wurde.
Nachdem eine neue Simulation erstellt worden ist, können beliebig viele verschiedene Knoten zur Simulation hinzugefügt werden. Dies geschieht entweder
durch eine bereits compilierte Sky-Datei oder nur durch eine normale C-Datei, welche vom Simulator aus compiliert wird. Sobald ein Knoten auf diese Weise erstellt
worden ist, lassen sich konkrete Instanzen des Knotens hinzufügen.
Durch diverse Einstellmöglichkeiten lässt sich der aktuelle Zustand eines Knotens
darstellen. Hierzu gehören grundlegende Eigenschaften wie der Name bzw. die
Adresse eines Knotens, aber auch andere Zustände wie die aktuelle Nachbarschaft
und die Reichweite des Radios. Natürlich ist es auch möglich den vorhandenen
Button zu klicken und die angebrachten LEDs anzuzeigen.
Zusätzlich verfügt Cooja über einen Log Listener, welcher die Ausgaben aller Knoten
aggregiert anzeigt und einer Timeline, in der verschiedene Zustände, wie die aktuellen LEDs oder die Radioaktivität der Knoten, grafisch dargestellt werden.
In Abbildung 2.2 sind die verschiedenen Panel zu sehen. In der linken oberen Ecke
befindet sich das Control Panel, mit dem sich die Ausführungsgeschwindigkeit einstellen lässt. Hierbei sind Werte von Keine Verzögerung bis zu einem Step in jeder
Sekunde möglich. Im Bild ist Real Time eingestellt, mit dem die reale Verarbeitungszeit simuliert wird.
Rechts davon ist der Simulation Visualizer zu sehen, in dem die Anordnung der
6
micro IP, Open-Source TCP/IP Stack
2.3 Cooja
8
Abbildung 2.2 – Screenshot Cooja
Knoten eingestellt werden kann. Links von den Knoten ist der aktuelle Zustand
zu sehen und der grüne bzw. der graue Kreis verdeutlichen die Reichweite des
Knotens 7. Der grüne Kreis zeigt die Entfernung, in der Kommunikation zwischen
Knoten möglich ist, im grauen Bereich ist keine Kommunikation mehr möglich,
jedoch treten Interferenzen auf.
Der Log Listener in der Mitte des Bildes sammelt die Ausgaben der Knoten, welche
mittels printf() ausgegeben werden. Darunter ist noch die Timeline sichtbar, in der
diverse Zustände über einen längeren Zeitraum grafisch dargestellt werden. Hier ist
auch zu sehen, wie in Contiki Idle Listening umgangen wird. Bei den kurzen grünen
und roten Erscheinungen lauschen die Knoten, bei der langen blauen von Knoten 4
sendet dieser. Das Senden wird so lange durchgeführt, bis garantiert werden kann,
dass jeder Knoten während dieser Zeit mindestens einmal auf den Kanal hört.
Zur Entwicklung der vorliegenden Bachelorarbeit war dieser Simulator sehr nützlich,
da auf einfache Weise ermöglicht wurde, verschiedene Netzwerke aufzubauen und
das aktuelle Programm in diesen Netzwerkstrukturen zu testen.
Kapitel 3
Funktionsweise der Implementierung
Implementiert wird ein Netzwerkprotokoll, welches einer Menge von Knoten ermöglichen soll, sich selbst zu organisieren und untereinander zu kommunizieren.
Weiters soll möglich sein, mehrere Netzwerke aufzubauen und auch zwischen diesen
zu kommunizieren.
Dafür sind im Wesentlichen drei Schritte nötig:
• Selbstorganisierender Netzwerkaufbau
• Lokales Routing
• Inter-Domain Routing, also Routing zwischen verschiedenen Netzwerken
3.1
Kordelaufbau
Zu Beginn gibt es in jeder vorhanden Kordel einen vorprogrammierten Knoten, der
als Startknoten fungiert. Dieser besitzt am Anfang die in der eigenen Headerdatei
definierte Position START_POSITION.
Damit die unterschiedlichen Knoten ihre Netzwerkumgebung erkunden können, sendet jeder Knoten, der sich bereits in einer Kordel befindet, so genannte
Hello-Messages via Broadcast aus. Diese Nachrichten enthalten Informationen über
die eigene Position, die eigene Kordel und die Positionen sowie physikalischen Adressen des Vorgängers und des Nachfolgers.
Da sich diese Informationen ändern können und auch jederzeit neue Knoten
in die Umgebung kommen können, werden Hello-Messages (Tabelle 3.1) kontinuierlich alle TH_SECONDS gesendet. Sobald sich ein Knoten für längere Dauer
9
3.1 Kordelaufbau
10
Byte
1-9
10 - 11
12
13 - 14
15 - 16
17 - 18
19 - 20
Feld
VCP_HELLO
OWN_POS
OWN_DOM
SUCC_RIME
SUCC_POS
PRED_RIME
PRED_POS
Beschreibung
Header
Eigene Position
Eigene Domain
RIME Adresse Nachfolger
Position Nachfolger
RIME Adresse Vorgänger
Position Vorgänger
Tabelle 3.1 – Protokoll für Hello-Messages
TH_INIT_TIME, in der Kordel befindet, wird das Intervall der Hello-Messages vergrößert. Dadurch muss der Knoten nicht mehr so oft Nachrichten versenden, es
verringert sich das Datenaufkommen und es wird Energie eingespart.
Wird eine Hello-Message zum ersten Mal von einem Knoten empfangen (Abbildung 3.1), so speichert der Empfänger die Informationen über diesen Knoten
in einer Liste ab (Listing 3.1). Da es sein kann, dass der sendende Knoten wieder
verschwindet, startet der Empfänger einen Timer, welcher den Knoten aus der Liste
entfernt, wenn innerhalb TIME_DELETE_NEIGHBOR keine neue Nachricht gekommen ist.
Wird die Nachricht bereits zum wiederholten Mal empfangen, werden die empfangen Informationen aktualisiert und der Timer wieder auf die Ausgangszeit zurückgesetzt.
Es existiert ein zweiter Timer, der TPS-Timer, welcher vorgibt, wie lange nach
dem ersten Empfang einer Hello-Message mindestens gewartet werden muss, bis ein
neuer Knoten versuchen darf, sich in die Kordel einzubinden. Dieser Timer wird
beim ersten Empfang einer Hello-Message eines beliebigen Knotens gestartet und
läuft nach TPS_SECONDS ab.
Wird eine weitere Hello-Message empfangen, ist die eigene Position noch nicht definiert und somit auf dem Wert NO_POSITION. Ist der TPS-Timer bereits abgelaufen,
versucht der neue Knoten sich in die Kordel einzubinden (Abbildung 3.2). Außerdem
wird der TPS-Timer erneut gestartet, sodass zwischen zwei Einbindungsversuchen
eines neuen Knotens mindestens TPS_SECONDS vergehen müssen.
Um Inter-Domain-Routing zu ermöglichen, existieren zwei verschiedene Listen
von Nachbarschaftsknoten. In der ersten Liste werden die Knoten der eigenen Kordel gespeichert. Alle anderen Knoten werden in der zweiten Liste gespeichert, auf
3.1 Kordelaufbau
11
Abbildung 3.1 – Ablauf beim Erhalt einer Hello-Message
welche im Abschnitt 3.3.1 genauer eingegangen wird.
Befindet sich ein Knoten noch in keiner Kordel, so werden alle Knoten in der
Nachbarschaft in die interne Liste gespeichert. Sobald der neue Knoten eine Position
in einer Kordel einnimmt, werden die externen Knoten auch in der externen Liste neu
gespeichert. Da der oben beschriebene Timer für beide Listen autonom läuft, fallen
die externen Knoten nach spätestens TIME_DELETE_NEIGHBOR aus der internen
Liste.
1
2
struct n e i g h b o r _ i n f o r m a t i o n {
struct n e i g h b o r _ i n f o rm a t i o n * next ;
as a link - list type */
/* to use this struct &
3
rimeaddr_t * own_rime ;
POSITION_TYPE own_position ;
POSITION_TYPE own_domain ;
4
5
6
7
rimeaddr_t * succ_rime ;
POSITION_TYPE succ_position ;
8
9
10
rimeaddr_t * pred_rime ;
POSITION_TYPE pred_position ;
11
12
13
struct ctimer * d e l e t e _ n e i g h b o r _ t i m e r ;
14
15
};
Listing 3.1 – Struktur; Information über physikalischen Nachbar
3.1 Kordelaufbau
12
Abbildung 3.2 – Ablauf zum Eingliedern in Kordel
3.1.1
Zwei aufeinanderfolgende Konten in Nachbarschaft
Dieser Fall beschreibt die einfachste Form zum Eingliedern in eine bestehende Kordel. Befinden sich in der Intern-List eines neuen Knoten zwei innerhalb einer Kordel
aufeinander folgende Knoten, kann sich der neue Knoten zwischen diesen beiden
platzieren. Zwei Knoten sind aufeinanderfolgend, wenn entweder der Vorgänger
oder der Nachfolger von Knoten1 gleich Knoten2 ist.
Für diesen Fall berechnet sich der neue Knoten als erstes seine eigene neue Position,
welcher sich aus der Hälfte der Position von Knoten1 + Position von Knoten2 ergibt,
und speichert diese Position zwischen. Wichtig hierbei ist eine Kontrollabfrage, ob
die Differenz der beiden bereits vorhanden Positionen mindestens 2 beträgt, da es
ansonsten nicht möglich ist, sich dazwischen zu positionieren und es zu Inkonsistenzen kommen würde.
Zusätzlich werden die physikalischen und virtuellen Adressen des Vorgängers
und Nachfolgers gespeichert.
Anschließend wird an die beiden Knoten ein Request (Tabelle 3.2) zum Einbinden in
die Kordel versendet. In diesem sind die Domain, die eigene (berechnete) Position
und die Positionen des Vorgängers und Nachfolgers zur Kontrolle enthalten.
3.1 Kordelaufbau
13
: New Node
: Node A
: Node B, Successor of A
: between_request()
: between_request()
: between_ack()
: is_not_locked()
: safety_check()
: is_not_locked()
: safety_check()
: between_ack()
: store_position()
: between_ack()
: between_ack()
: change_successor()
: change_predecessor()
Abbildung 3.3 – Erfolgreicher Ablauf beim Eingliedern zwischen zwei Knoten
Byte
1 - 15
16
17 - 18
19 - 20
21 - 22
Feld
VCP_REQ_BETWEEN
OWN_DOM
OWN_POS
PRED_POS
SUCC_POS
Beschreibung
Header
Domain
Position für neuen Knoten
Position Vorgänger
Position Nachfolger
Tabelle 3.2 – Protokoll für Request zum Eingliedern zwischen zwei Knoten
Diese Nachricht wird an den Vorgänger und Nachfolger versendet, anschließend
wird auf die Acknowledgments (Tabelle 3.3) gewartet. Werden die beiden Acknowledgments nicht innerhalb der TPS Zeit, somit bis zum nächsten Request, empfangen,
wird der Request verworfen.
Empfängt ein Knoten einen Request zum Eingliedern zwischen zwei Knoten,
wird zuerst kontrolliert, ob der Knoten gerade gelockt ist.
Um Inkonsistenzen zu vermeiden, wenn zeitgleich oder in kurzem zeitlichen Abstand verschiedene Requests bei einem Knoten eintreffen, wird dieser beim ersten
Request für alle anderen Requests gesperrt. Hierbei wird zwischen eigenem Lock und
fremdem Lock unterschieden. Wie die Namen schon sagen, sperrt sich der Knoten
bei einem Eigenem Lock selbst, da er gerade einen Request für Start/Endübernahme
oder für einen Virtuellen Node, Abschnitt 3.1.3, versendet hat.
Nach einer gewissen Zeit, TIME_WAIT_LOCK, werden die Locks wieder freigegeben.
Ist nun der Knoten beim Empfang des Request noch gelockt, egal ob durch sich
selbst oder durch einen anderen Knoten, wird der Request sofort verworfen.
Ansonsten wird der Knoten Fremd-gelockt und ein Timer gestartet, der diesen Lock
3.1 Kordelaufbau
14
wieder freigibt. Nun beginnt die eigentliche Verarbeitung des Requests. Am Anfang
stehen einige Sicherheitsüberprüfungen, welche darauf ausgelegt sind, dass der
neue Knoten die richtigen Werte empfangen und gespeichert hat.
Fallen dieses Tests positiv aus, so wird ein Acknowledgment wieder zurück an den
neuen Knoten gesendet. Hierbei ist wichtig zu beachten, dass noch keine Werte fix
geändert werden.
Empfängt wiederum der neue Knoten die Acknowledgments von beiden Knoten,
so speichert er seine neue Position und die Domain und sendet dieselbe Nachricht
wieder zurück an die beiden anderen Knoten.
Erst beim Empfangen dieser Nachricht ändern diese Knoten ihre Vorgänger bzw.
Nachfolger so, dass der neue Knoten in der Kordel eingebunden ist (Abbildung 3.3).
3.1.2
Start- oder Endknoten bekannt
Findet ein neuer Knoten in seiner Umgebung keine zwei aufeinander folgende Knoten, aber den Start- oder Endknoten einer Kordel, so kann er sich über einen dieser
beiden in die Kordel einbinden (Abbildung 3.4).
Im Folgenden wird das Verfahren für den Startknoten beschrieben, für den Endknoten läuft es vice versa.
Will sich der neue Knoten über den Startknoten einbinden, so wird dieser zum neuen
Startknoten und der bisherige Startknoten bekommt eine höhere Position. Für die
Berechnung der neuen Position wird unterschieden, ob der Startknoten der bisher
einzige Knoten in der Kordel ist, oder ob sich bereits mehrere Knoten in der Kordel
befinden, was bedeutet, dass der Startknoten einen Nachfolger besitzt.
Ist der Startknoten der einzige, so wird seine neue Position die des Endknotens
werden, ansonsten berechnet sich die neue Position durch die Hälfte von START
addiert mit der Position des Nachfolgers.
Ähnlich wie im ersten Fall berechnet der neue Knoten die neue Position des Startknotens, packt diese in eine Request-Message (Tabelle 3.4) und sendet sie an den
Startknoten.
Byte
1 - 15
16
17 - 18
19 - 20
21 - 22
Feld
VCP_ACK_BETWEEN
OWN_DOM
OWN_POS
PRED_POS
SUCC_POS
Beschreibung
Header
Domain
Position für neuen Knoten
Position Vorgänger
Position Nachfolger
Tabelle 3.3 – Protokoll für Acknowledgment zum Eingliedern zwischen zwei
Knoten, einziger Unterschied zu Request ist geänderter Header
3.1 Kordelaufbau
15
: New Node
: StartNode
: bound_request()
: Successor of Start
: is_not_locked()
: lock_request()
: is_not_locked()
: lock_ack()
: safety_check()
: change_position()
: bound_ack()
: store_position()
Abbildung 3.4 – Erfolgreicher Ablauf beim Übernehmen des Startknotens
Byte
1 - 13
14
15 - 16
17 - 18
19 - 20
21 - 22
Feld
VCP_REQ_BOUND
OWN_DOM
OLD_NEXTBOUND
NEW_NEXTBOUND
OLD_CURBOUND
NEW_CURBOUND
Beschreibung
Header
Domain
Bisherige Pos. neuer Knoten; NO_POSITION
Neue Pos. für neuen Knoten; START_POSITION
Bisherige Pos. Startknoten; START_POSITION
Neue Pos. für Startknoten
Tabelle 3.4 – Protokoll für Request bei Übernahme des Startknotens
Sobald der bisherige Startknoten den Request erhält, prüft er, ob er gelockt ist.
Ist das der Fall, verwirft er den Request, ansonsten sperrt er sich selbst, sodass keine
weiteren Requests behandelt werden.
Der Request wird zwischengespeichert, und der Startknoten versucht, seinen direkten Nachfolger zu sperren. Ist der Knoten der bisher einzige in der Kordel, kann
dieser Schritt übersprungen werden.
Um den Nachfolger zu sperren, wird ein Lock Only Request an ihn versendet. Ist der
Nachfolger nicht gesperrt, sperrt er sich selbst und schickt ein Lock Only Acknowledgment zurück. Wie in den vorherigen Fällen wird der Request im Falle eines gesperrten
Knotens verworfen, sowie der Lock mittels Timer nach TIME_WAIT_LOCK wieder
freigegeben.
Erhält nun der bisherige Startknoten ein Acknowledgment (Tabelle 3.5) seines Nachfolgers, werden die diversen gesendeten Werte aus dem Request des neuen Knotens
extrahiert und mit einem Sicherheitscheck überprüft. Fällt diese Überprüfung positiv aus, ändert der alte Startknoten seine Position, speichert seinen Vorgänger ab
und informiert seinen Nachfolger über seine neue Position. Abschließend wird ein
Acknowledgment an den neuen Knoten geschickt, der ab jetzt den Startknoten der
3.1 Kordelaufbau
16
Kordel darstellt.
Sobald der neue Knoten das Acknowledgment erhält, speichert er seine eigene
Position, Domain und den bisherigen Startknoten als Nachfolger ab.
3.1.3
Virtuelle Knoten
Befinden sich in der Nachbarschaft eines neuen Knotens weder zwei zusammenhängende Knoten noch ein Start- oder Endknoten, ist keines der beiden oben beschriebenen Verfahren möglich. In diesem Fall bittet der neue Knoten einen bereits
vorhandenen, einen Virtuellen Knoten zu erstellen, zwischen welchen sich der neue
einordnen kann. Dies ist die 4. und letzte Möglichkeit, sich in eine bestehenden
Kordel einzubinden. Hierfür muss der neue Knoten in seiner Nachbarschaft nur
mindestens einen Knoten kennen, der sich bereits in einer Kordel befindet.
Da durch Virtuelle Knoten das Netzwerk komplexer wird, ist für diesen Fall ein
weiterer Timer eingebaut. Beim ersten Versuch eines neuen Knoten, einen Virtual
Node Request zu versenden, wird der TVPS Timer gestartet, welcher TVPS_SECONDS
läuft und verhindert, dass vor dem Ablauf ein Request für einen Virtuellen Knoten
verschickt wird.
Ist der Timer abgelaufen und findet der neue Knoten in seiner Nachbarschaft noch
immer nur einzelne Knoten, sendet er an einen dieser Knoten einen Virtual Node
Request (Tabelle 3.6).
Beim Empfangen eines Virtual Node Request wird, wenn der Knoten nicht gesperrt ist, genauso wie im vorhergehenden Fall versucht, den Nachfolger zu sperren.
Da der Virtuelle Knoten eine höhere Position als der reale Knoten erhalten wird, ist
es nicht nötig, den Vorgänger zu sperren. Dieser kann seine Position währenddessen
verändern, das beeinflusst das Erstellen des Virtuellen Knoten nicht.
Empfängt der Knoten das Acknowledgment eines Nachfolgers, berechnet er als erstes
die Position des Virtuellen Knotens, welche sich wieder aus der Hälfte der eigenen
Byte
1 - 13
14
15 - 16
17 - 18
19 - 20
21 - 22
Feld
VCP_ACK_BOUND
OWN_DOM
OLD_NEXTBOUND
NEW_NEXTBOUND
OLD_CURBOUND
NEW_CURBOUND
Beschreibung
Header
Domain
Bisherige Pos. neuer Knoten; NO_POSITION
Neue Pos. für neuen Knoten; START_POSITION
Bisherige Pos. Startknoten; START_POSITION
Neue Pos. für Startknoten
Tabelle 3.5 – Protokoll für Acknowledgment bei Übernahme des Startknotens,
einziger Unterschied zum Request ist der Header
3.1 Kordelaufbau
17
: New Node
: virtual_node_request()
: Node A
: Node B, Successor of A
: is_not_locked()
: lock_request()
: is_not_locked()
: lock_ack()
: create_virtual_node()
: virtual_node_ack()
: store_position()
Abbildung 3.5 – Erfolgreicher Ablauf beim Erstellen eines Virtuellen Knotens
Byte
1 - 11
Feld
VCP_CVN_REQ
Beschreibung
Header
Tabelle 3.6 – Protokoll für Request zum Erstellen eines Virtuellen Knotens
Position plus der Position des Nachfolgers ergibt. Die Position für den neuen Knoten
befindet sich genauso zwischen bereits vorhandenem und Virtuellem Knoten.
Die Informationen über alle eigenen Virtuellen Knoten werden, ähnlich wie bei den
physikalischen Nachbarn, in einer Liste von struct neighbor_information gespeichert.
Der neu erzeugte Virtuelle Knoten erhält als Nachfolger die bisherigen Nachfolgerwerte des realen Nodes und als Vorgänger die Daten des neuen Nodes. Der Timer,
welcher das Löschen der physikalischen Nachbarn ermöglicht, wird für diesen Fall
einfach frei gelassen.
Anschließend wird das Acknowledgement für den neuen Node zusammengebaut,
und an diesen versendet. Zusätzlich wird der bisherige Nachfolger über seinen neuen
Vorgänger, den Virtuellen Knoten, informiert und die eigenen Nachfolgerwerte auf
den neuen Knoten angepasst.
Der neue Knoten erhält das Acknowledgment, speichert wieder alle Werte ab
und befindet sich somit ab jetzt in der Kordel (Abbildung 3.5).
Kein Problem ist es, dass ein Knoten mehrere Virtuelle Knoten besitzt. Wird ein
Byte
1 - 11
12
13 - 14
15 - 16
17 - 18
Feld
VCP_CVN_ACK
OWN_DOM
OWN_POS
PRED_POS
SUCC_POS
Beschreibung
Header
Domain
Position für neuen Knoten
Position Vorgänger (realer Knoten)
Position Nachfolger (Virtueller Knoten)
Tabelle 3.7 – Protokoll für Request zum Eingliedern zwischen zwei Knoten
3.1 Kordelaufbau
18
neuer Virtueller Knoten erstellt, bekommt dieser eine Position zwischen realem
Knoten und dem ersten Virtuellen Knoten.
Alle Fälle haben gemeinsam, dass nach einem Request zum Eingliedern in eine
Kordel ein Timer gestartet wird. Erst wenn dieser Timer abgelaufen ist, ist es dem
Knoten wieder möglich, einen neuen Request zu versenden. Dadurch soll verhindert
werden, dass ein Knoten ständig Requests verschickt, da diese eine gewisse Zeit zur
Abarbeitung brauchen.
3.2
Lokales Routing
Um Nachrichten innerhalb der eigenen Kordel zu verschicken, ist es nötig, an die
Nachricht die Zielposition, die Quellposition und die Länge der Nachricht hinzuzufügen (Tabelle 3.8).
Das erstmalige Senden und das Weiterleiten von Nachrichten erfolgt auf die
selbe Art und Weise. Damit die Prozedur nicht zweimal implementiert werden muss,
wird beim Senden einer lokalen Nachricht simuliert, dass diese empfangen wurde
und einfach weitergeroutet werden muss.
Sobald eine Nachricht empfangen wurde, wird als erstes die Zielposition untersucht,
um zu wissen, ob die Nachricht für den eigenen Knoten bestimmt ist. Hierbei ist es
wichtig, nicht nur die eigene Position zu betrachten, sondern auch die Positionen
aller Virtuellen Knoten, da auch diese vom Knoten empfangen werden müssen.
Ist die Nachricht weder für den realen Knoten noch für einen der Virtuellen Knoten
bestimmt, muss sie weitergeleitet werden. Damit die Nachricht nicht jeden Knoten in
der Kordel passieren muss, ist es möglich, Abkürzungen zu nehmen. Ist zum Beispiel
der Zielknoten einer Nachricht nicht der direkte Nachfolger des Knotens, jedoch in
seiner Nachbarschaft, so wird die Nachricht gleich zum Zielknoten geschickt und
nicht der Umweg über den Nachfolger und eventuell noch weitere Knoten gemacht,
siehe Abbildung 3.6.
Byte
1 - 13
14 - 15
16 - 17
18 - 19
20 -
Feld
VCP_MSG_LOCAL
OWN_POS
OWN_POS
LENGTH
Message
Beschreibung
Header
Position Empfänger
Position Sender
Länger der Nachricht
Eigentliche Nachricht
Tabelle 3.8 – Protokoll für lokale Nachrichten
3.2 Lokales Routing
19
1
12
25
92
99
90
40
50
75
Abbildung 3.6 – Greedy Forwarding, anstatt die lange Schleife zu wählen,
sendet Knoten 25 direkt an Knoten 90
Zum Weiterleiten der Nachricht werden alle physikalischen Nachbarn untersucht. Dem Knoten, welcher virtuell am nächsten zum Ziel ist, wird die Nachricht
weitergeleitet. Dabei ist es egal, ob dieser Knoten in der Kordel eventuell schon über
das Ziel hinaus ist, es zählt nur, dass er die geringste Distanz zum Ziel hat.
3.3
3.3.1
Globales Routing
Verbreiten von Gateway Informationen
Befindet sich ein Knoten in der Nachbarschaft eines Knotens einer anderen Kordel,
so kann er als Gateway fungieren. Damit nicht nur der jeweilige Knoten Nachrichten
in die andere Kordel schicken kann, sondern die ganze Kordel, muss die Information
über den Gateway in der Kordel verbreitet werden. Hierfür durchsucht jeder Knoten
alle TIME_GATEWAY_INFO seine Liste von externen Nachbarn und sendet gegebenenfalls, wenn Nachbarn vorhanden sind, eine Liste (Tabelle 3.9) durch seine Kordel.
Um die Nachbarn zu informieren, baut der Knoten eine Nachricht zusammen,
in der seine direkten Verbindungen in andere Kordeln gespeichert werden. Da die
Anzahl variabel ist, wird auch diese an die Nachricht angehängt, es können jedoch
maximal Informationen über 12 andere Kordeln innerhalb einer Nachricht versendet
werden.
Hierfür iteriert der Knoten durch die gesamte Liste der externen Nachbarn. Sobald ein Nachbar einer neuen Kordel betrachtet wird, wird diese der Nachricht
angefügt. Zum Schluss werden noch die Anzahl der Knoten und die Position des
Gateways, also die eigene, angehängt. Ist die Anzahl 0, also hat der Knoten keine
Nachbarn in anderen Kordeln, wird das Paket verworfen. Außerdem wird noch die
3.3 Globales Routing
Byte
1-6
7-8
9 - 10
11
12
13
Feld
GWINFO
OWN_POS
FROM_POS
AMOUNT
GW1
GW2
20
Beschreibung
Header
Position des Gateways
Position des letzten Senders dieser Nachricht
Anzahl von Gateways in Nachricht
Externe Domain 1
Externe Domain 2
Tabelle 3.9 – Protokoll für Nachrichten zum Verbreiten von Gateway Informationen, es sind bis zu 12 externe Domains möglich
Adresse des Senders hinzugefügt, welche bei jedem Knoten aktualisiert wird. Dies
ist notwendig, damit bei Virtuellen Knoten keine Zyklen entstehen.
Diese Nachricht wird an den direkten Vorgänger und Nachfolger gesendet, ein Greedy
Forwarding, wie bei normalen Nachrichten, ist hier nicht möglich, da jeder Knoten
einer Kordel über den Gateway in Kenntnis gesetzt werden muss.
Empfängt ein Knoten diese Nachricht, iteriert er über alle mitgeschickten Gateway Informationen und aktualisiert, bzw. erstellt diese in seiner Liste von bekannten
Gateways. Die Gateway Informationen werden, wenn nicht rechtzeitig aktualisiert,
nach TIME_GATEWAY_DELETE wieder gelöscht. Dieser Zeitwert wurde ein wenig
über dem doppelten Wert von TIME_GATEWAY_INFO festgesetzt, sodass im Falle
eines Paketverlustes nicht sofort die Information über den Gateway entfernt werden.
3.3.2
Versenden von globalen Nachrichten
Die Idee hinter dem Routing zwischen zwei Kordeln ist, dass der Sender die Nachricht als globale Nachricht zu einem Gateway versendet, dieser die Nachricht zu
einer lokalen transformiert und seinem Gegenüber in der anderen Kordel weiterleitet
(Abbildung 3.7). Der Gateway der anderen Kordel sendet diese Nachricht als lokale
Nachricht zum Empfänger.
Beim Senden einer globalen Nachricht wird zuerst ein Gateway zur Kordel des
Empfängers gesucht. Hierfür wird die eigene Liste der externen Nachbarn durchsucht, um festzustellen, ob der sendende Knoten bereits ein richtiger Gateway ist.
Wird in dieser Liste kein passender Knoten gefunden, wird die Liste der bekannten
Gateways durchsucht. Wird auch hier kein Gateway gefunden, wird der Sendevorgang abgebrochen.
Nun werden alle nötigen Informationen, siehe Tabelle 3.10, angefügt. Ähnlich wie
beim lokalen Routing wird simuliert, dass eine globale Nachricht zum Weiterleiten
3.3 Globales Routing
21
99
1
12
50
75
40
25
1
90
99
92
Abbildung 3.7 – Ablauf von globalem Routing, blau ist die globale Nachricht,
grün die lokale und rot der Übergang zwischen den Kordeln
empfangen wurde.
Wird eine globale Nachricht empfangen, untersucht der Knoten zuerst, ob die
Nachricht für ihn bestimmt ist. Hierbei ist zu beachten, dass nicht die eigentliche
Zieladresse, sondern die des Gateways untersucht werden muss.
Ist die Nachricht nicht für den Knoten bestimmt, wird sie genau wie beim lokalen
Routing per Greedy Forwarding weitergeleitet. Falls der Knoten der Gateway ist,
wandelt dieser die Nachricht in eine lokale Nachricht, indem der Header und die
benötigten Felder verändert werden, und sendet diese direkt an sein Gegenüber in
der anderen Kordel. Dieser empfängt die Nachricht bereits als lokale Nachricht und
routet sie zum Zielknoten.
Byte
1 - 13
14
15
16 - 17
18 - 19
19 - 20
21 - 22
23 -
Feld
VCP_MSG_GLOBA
DEST_DOM
SRC_DOM
OWN_POS
OWN_POS
GATEWAY_POS
LENGTH
Message
Beschreibung
Header
Zieldomain
Quelldomain
Position Empfänger
Position Sender
Position Gateway
Länger der Nachricht
Eigentliche Nachricht
Tabelle 3.10 – Protokoll für globale Nachrichten
Kapitel 4
Verifikation und Leistungsbewertung
Als Abschluss dieser Bachelorarbeit sollte das implementierte Protokoll auf seine
Leistungsfähigkeit getestet werden. Hierfür wurden einige Szenarien ausgearbeitet
und getestet, welche sowohl den Kordelaufbau als auch die anschließende Kommunikation untersuchen.
Bei den Tests mit Cooja wurde jeder Durchlauf 20 mal wiederholt, bei den Tests auf
den realen Knoten 10 mal. Der Mittelwert der Ergebnisse wird in den nachfolgenden
Säulendiagrammen dargestellt. Auf der x-Achse befindet sich jeweils die Anzahl der
Knoten des Tests in aufsteigender Reihenfolge, die y-Achse beschreibt, wenn nicht
anders angegeben, die benötigte Dauer in Sekunden.
Die Plots wurden mittels GNU R 7 , einer Programmiersprache für statistische Grafiken erstellt. Es bedarf der Einarbeitung, doch die geplotteten Graphen rechtfertigen
diesen Aufwand.
Um nicht jeden Test manuell durchführen zu müssen, wurde die Möglichkeit von
Cooja verwendet, eigene Plugins miteinzubinden. Mit Hilfe eines kleinem Plugins
ist es möglich, Buttonklicks zu simulieren und die Ausgaben der Knoten in eine
Textdatei umzuleiten. Zusätzlich können eigene Simulationen ohne grafische Oberfläche ausgeführt werden. Durch eine Kombination aus diesen beiden Features ist es
möglich, die Simulation auf der CLI8 zu starten und erst nach Ablauf die Textdatei
auszuwerten.
Da es sehr schwierig bis nahezu unmöglich ist, mit realen Knoten die Nachbarschaftsverhältnisse von Szenarien wie Line oder Grid aufzubauen, wurde die Nachbarschaft
softwaremäßig nachgestellt. Um dies zu erreichen, verwirft ein Knoten einfach alle
Pakete, die er erhält, aber laut Szenario nicht erhalten soll. Dies bedeutet, dass physikalisch jeder Knoten jeden anderen sieht, was an der Funktionalität des Protokolls
nichts ändert. Zu beachten ist jedoch, dass dadurch mehr Interferenzen entstehen,
7
8
http://www.r-project.org
CLI: Command Line Interface; Steuerung eines Programms im Textmodus
22
4 Verifikation und Leistungsbewertung
23
welche sich bei den Tests auf ihre Dauer auswirken.
Zur Zeitmessung auf den realen Knoten wurde ein Supernode eingerichtet, welchen
alle Knoten innerhalb von einem Hop erreichen können. Bei jedem Ereignis, bei dem
die Zeit gemessen werden muss, sendet der jeweilige Knoten eine Nachricht an den
Supernode. Damit wird das Problem, dass auf jedem Knoten ein unterschiedlicher
Zeitwert aktuell ist [18], eliminiert. Bei den Ergebnissen ist aber zu beachten, dass
bei jeder Messung dieser Hop miteinberechnet ist.
4.1
Kordelaufbau
Um den Kordelaufbau bewerten zu können, gibt es zwei Szenarien: der Aufbau
entlang einer Line und der Aufbau in einem Grid.
4.1.1
Kordelaufbau entlang einer Line
In diesem Szenario, abgebildet in Abbildung 4.1, hat jeder Knoten außer den Randknoten zwei physikalische Nachbarn. Dadurch ist der Aufbau der Kordel nur auf
eine Art möglich.
Wie in Abbildung 4.2 zu sehen ist, nimmt die Dauer für den Aufbau mit Anzahl
der Knoten linear zu. Außerdem ist die Standardabweichung zwischen den einzelnen Durchläufen erwartungsgemäß gering, da wie erwähnt, der Ablauf ident ist.
Abbildung 4.1 – Line-Szenario; jeder Knoten hat zwei physikalische Nachbarn
24
100
4.1 Kordelaufbau
60
40
0
20
Dauer [Sekunden]
80
Cooja
Reale Knoten
4
6
8
10
12
14
16
Anzahl Knoten
Abbildung 4.2 – Messergebnisse Kordelaufbau im Line-Szenario; Die größere
Dauer auf den realen Knoten lässt sich durch Interferenzen erklären, da jeder
Knoten technisch mit jedem anderen kommunizieren kann; Der Fehlerbalken
beschreibt die Standardabweichung der verschiedenen Testdurchläufe
4.1.2
Kordelaufbau im Grid
Ein ganz anderes Verhalten als beim Line Szenario ist zu erwarten, wenn die Knoten
in einem Grid angeordnet sind. Für diesen Test wurden symmetrische Grids erstellt,
wobei ein Knoten jeweils mit seinen insgesamt 8 direkten Nachbarn (Abbildung 4.3)
kommunizieren kann.
Da nur eine begrenze Anzahl an realen Knoten vorhanden war, gibt es für das 5x5
Grid Szenario nur ein Ergebnis in Cooja.
Abbildung 4.3 – Grid-Szenario; jeder Knoten hat acht physikalische Nachbarn
4.1 Kordelaufbau
25
Den Initialknoten bildet in diesem Szenario der Knoten 1, welcher sich in der
linken oberen Ecke befindet. Nun gibt es unzählige Möglichkeiten, auf welche Weise
sich die Kordel aufbaut. In den Tests dieses Projekts gab es sämtliche Möglichkeiten,
von Fällen in denen sich alle Knoten zwischen zwei anderen eingegliedert haben
bis hin zu Durchläufen, bei denen mehrere Virtuelle Knoten erstellt wurden. Diese
vielfältigen Möglichkeiten sind nun auch bei den Ergebnissen der Dauer zu sehen,
wodurch eine sehr breite Standardabweichung entstanden ist.
Ein Aufbau, wie er bei einem der Tests entstanden ist, kann in Abbildung 4.6
betrachtet werden. Hier sind zwei negative Aspekte zu beobachten:
• Virtuelle Knoten, obwohl jeder Knoten genug physikalische Nachbarn hat
• Die Aufteilung der Positionen: zwischen 1 und 1250 befinden sich 5 Knoten,
zwischen 3750 und 5000 nur 2.
Wie in Abbildung 4.4a gut sichtbar ist, nimmt die Dauer für den Aufbau abhängig
von der Knotenanzahl gleichmäßig zu.
Auffällig bei allen Ergebnissen ist, dass der Aufbau relativ viel Zeit in Anspruch
nimmt. Dies ist auf die Einstellung der Zeiten (Tabelle 4.1) zurück zu führen.
Sollte der Kordelaufbau schneller realisiert werden, sind diese Werte kleiner zu
wählen. Dies führt aber zu mehr Netzwerkkommunikation und zu mehr Kollisionen
und verschwendet somit mehr Energie. Beim eigenen Einsatz muss zwischen diesen
beiden Extrema ein Kompromiss gefunden werden, welcher den Ansprüchen des
4
Cooja
Reale Knoten
3
0
1
2
Anzahl Hops
100
50
0
Dauer [Sekunden]
150
200
Netzwerks bzw. der Knoten entspricht. Außerdem ist hier die Wartezeit zum Erstel-
2x2
3x3
4x4
Anzahl Knoten
(a) Kordelaufbau
5x5
2x2
3x3
4x4
5x5
Anzahl Knoten
(b) Nachrichtenversand
Abbildung 4.4 – Messergebnisse: Dauer Kordelaufbau im Grid-Szenario und
Nachrichtenversand. Beim Nachrichtenversand beschreibt die Säule die Anzahl
der idealen Hops, der Fehlerbalken die real benötigten Hops. Der Fehlerbalken
beim Kordelaufbau ist die Standardabweichung der verschiedenen Durchläufe;
5x5 Szenario aufgrund begrenzter Anzahl von realen Knoten nur in Cooja
4.1 Kordelaufbau
Zeit
TH_INIT
TH_AFTER
TH_INIT_TIME
TPS
NO_REQUEST
TVPS
WAIT_LOCK
26
Dauer
1 Sek.
6 Sek.
20 Sek.
2 Sek.
10 Sek.
30 Sek.
5 Sek.
Beschreibung
Hello-Messages Intervall vor TH_INIT_TIME
Hello-Messages Intervall nach TH_INIT_TIME
siehe ersten zwei Zeilen
Mindest-Wartezeit vor erstem Request
Mindestintervall zwischen zwei Requests
Wartezeit vor Erstellen eines Virtuellen Knotens
Dauer, die ein Knoten gelockt wird
Tabelle 4.1 – Einstellungen der Zeiten bei den diversen Testdurchläufen
len eines Virtuellen Knotens relativ hoch gewählt. Dies bewirkt, dass das Netzwerk
einfach gehalten wird, da länger die Möglichkeit besteht, noch von weiteren Knoten
zu erfahren, welche eventuell ein einfacheres Eingliedern ermöglichen.
4.2
Kommunikation
Im zweiten Teil der Tests geht es um die Kommunikation innerhalb des Netzwerks,
wenn die Kordel bereits fertig aufgebaut ist.
Bei diesen Tests wird die Zeit zu einem großen Teil davon beeinflusst, ob der
Übertragungskanal gerade belegt ist bzw. wie lange mit der Übertragung gewartet
werden muss. Da dieser Wert bei jedem Test anders ist, entsteht eine relativ große
Standardabweichung.
4.2.1
Kommunikation entlang einer Line
Dieses Szenario baut auf dem Kordelaufbau in Abbildung 4.1 auf, bei dem jeder
Knoten nur seinen direkten Vorgänger und Nachfolger sieht. Dadurch sind keine
Abkürzungen, Greedy Forwarding, möglich.
Die linearen Ergebnisse, abgebildet in Abbildung 4.10, entsprechen den Erwartungen. Die einzige Auffälligkeit ist eine relativ große Standardabweichung, welche
durch den bereits vorhandenen Netzwerktraffic zustande kommt und in allen Kommunikationstests auftritt.
4.2.2
Kommunikation im Grid
Bei der Kommunikation im Grid sollte die Dauer im Vergleich zur Line nur einen
Bruchteil betragen, da hier das Konzept des Greedy Forwarding ausgenützt wird.
Dies erlaubt dem Knoten, die Nachricht nicht strikt entlang der Kordel zu versenden,
sondern gegebenenfalls an einen Knoten in der Nachbarschaft, welcher sich näher
27
0.8
0.6
0.0
0.2
0.4
Dauer [Sekunden]
1.0
1.2
1.4
4.2 Kommunikation
8 Hz
32 Hz
Kein Duty−Cycle
Duty−Cycle Frequenz
Abbildung 4.5 – Vergleich von verschiedenen Duty-Cycle Frequenzen bei der
Kommunikation im 5x5 Grid-Szenario. Durch eine höhere Frequenz ist eine
schnellere Kommunikation möglich. Bei Kein Duty-Cycle ist das Radio immer
eingeschaltet, die Nachricht kann sofort (wenn der Kanal frei ist) gesendet
werden
am Ziel befindet.
Die Nachrichten für diesen Test wurden von der linken oberen Ecke zur virtuellen
Position 1 versendet. Der maximale Wert, der im Idealfall eintreten kann, wenn sich
p
Position 1 in der rechten unteren Ecke befindet, beträgt somit Knotenanzahl − 1.
Da jedoch dieses Protokoll keine Informationen über die realen Positionen und somit
der realen Distanz zum Zielknoten besitzt, sondern nur die virtuellen Positionen
betrachtet, ist der Idealfall nicht immer möglich.
Bei diesem Szenario ist wichtig, ob das Protokoll eine gute Route mit möglichst
wenigen Hops findet. Da die Übertragungszeit hier zu sehr vom aktuellen Datenaufkommen abhängt, gibt es nur einen Vergleich der gewählten Route zur idealen
Route, was zeitunabhängig ist. Um sich die ungefähre Zeit vorstellen zu können,
wird diese für ein Szenario in Abbildung 4.5 aufgelistet.
In Abbildung 4.4b ist der Durchschnitt der ideal zurückzulegenden Hops in den
Säulen aufgelistet. Im Vergleich dazu sind die real zurückgelegten Hops als Fehlerbalken aufgetragen. Es ist gut zu sehen, dass die reale Anzahl nur wenig über der
idealen liegt, was bedeutet, dass die Route sehr gut gewählt ist. Beim 2x2 Szenario
ist der Wert der selbe, da die Anzahl zu jedem Knoten immer 1 Hop ist.
Beim 5x5 Grid wurde ein Versuch mit höherer Duty-Cycle Frequenz durchgeführt.
Der Contiki Standardwert hierfür ist 8 Hertz, was bedeutet, dass jeder Knoten 8 mal
pro Sekunde sein Radio einschaltet und hört, ob der Kanal frei ist. Beim Versuch in
Abbildung 4.5 wurde dieser Wert auf 32 Hertz vergrößert. Dies verbraucht mehr
4.2 Kommunikation
28
Energie, jedoch verringert sich das Datenaufkommen, was dazu führt, dass die Daten
zwischen den einzelnen Knoten schneller versendet werden können. Der Extremwert
hierfür wäre, Duty-Cycle zu deaktivieren. In diesem Fall horcht das Radio immer
und somit kann jeder Knoten sofort senden, sofern nicht gerade ein anderer sendet.
Hierfür ist der Zeitwert winzig, was zeigt dass die Übertragungsverzögerung im
MAC-Layer und nicht beim Routing Protokoll entsteht.
4.2.3
Parallele Nachrichten
In einem weiteren Versuch wurde getestet, wie sich das Netzwerk verhält, wenn
mehrere Knoten an einen Knoten Daten senden möchten. Hierfür senden, dargestellt
in Abbildung 4.7, jeweils n Knoten eine Nachricht an Knoten 50. Bei 2 gleichzeitig
sendenden Nodes sind dies die Knoten 1 und 99, bei 8 gleichzeitig sendende Nodes 1
bis 25 sowie 90 bis 99.
Damit das Senden wirklich gleichzeitig erfolgt, warten alle Knoten auf einen Buttonklick und senden, sobald dieser erfolgt. In Cooja ist es einfach zu simulieren,
dass die Buttons aller Knoten gleichzeitig gedrückt werden. Auf den realen Knoten
ist dies fast unmöglich. Aus diesem Grund gibt es für diesen Test nur Ergebnisse
vom Simulator.
10000
2500
3750
3437
1250
5000
3125
3281
625
157
6250
6484
313
1
6406
6562
Abbildung 4.6 – Ein möglicher Aufbau des 4x4 Grid Szenarios. Der Knoten
5000 hat einen Virtuellen Knoten (7500) über welchen Knoten 6250 in die
Kordel integriert ist
4.2 Kommunikation
1
5
29
12
40
25
50
75
92
90
95
99
Abbildung 4.7 – Parallele Nachrichten; 4 gleichzeitig sendende Nodes: Node
1, 5, 95 und 99 senden an Node 50
Die Ergebnisse in Abbildung 4.8 zeigen, dass es einen geringen Einfluss hat,
wieviele Knoten gleichzeitig eine Nachricht senden, da die Dauer nur leicht steigt.
Das liegt auch daran, dass die Nachricht, welche die meisten Hops bewältigen muss,
gleich bleibt. Da in der Nachbarschaft eines Knotens immer nur ein Knoten senden
kann, müssen, in dem Fall dass mehrere Knoten gleichzeitig senden wollen, alle anderen warten. Dies führt zu einer langen Dauer und einer großen Standardabweichung.
4.2.4
Inter-Domain Nachrichten
Beim abschließenden Test wird die Leistungsfähigkeit von Inter-Domain Nachrichten
untersucht. Hierfür wurde das Szenario wie in Abbildung 4.9 erstellt.
Der sendende Knoten sendet seine globale Nachricht an den Knoten 1 der roten
Kordel. Hierfür muss die Nachricht an den Gateway, Knoten 99, gesendet werden.
Da die Nachricht, sobald sie in der Zielkordel angekommen ist, als lokale Nachricht
weitergeleitet wird, und dieses Szenario bereits diskutiert wurde, wird hier nur die
4
3
0
1
2
Dauer [Sekunden]
5
6
7
Weiterleitung bis zur Zielkordel betrachtet.
4
6
8
10
Anzahl Knoten
Abbildung 4.8 – Messergebnisse Parallele Nachrichten in Cooja; Der Fehlerbalken beschreibt die Standardabweichung der verschiedenen Testdurchläufe.
Die x-Achse beschreibt die Anzahl gleichzeitig sendender Knoten
4.2 Kommunikation
30
1
40
90
25
1
99
92
2.5
Abbildung 4.9 – Inter Domain Szenario; Knoten 99 stellt Gateway dar
1.5
1.0
0.0
0.5
Dauer [Sekunden]
2.0
Cooja
Reale Knoten
4
6
8
10
12
14
16
Anzahl Knoten
Abbildung 4.10 – Messergebnisse Inter-Domain Routing bzw. Kommunikation
im Line Szenario; Der Fehlerbalken beschreibt die Standardabweichung der
verschiedenen Testdurchläufe
Es war zu erwarten, dass das Ergebnis dem des Kommunikation entlang einer
Line ähnelt, da die Pakete gleich weitergeleitet werden. Die gemessenen Werte
entsprachen diesen, deshalb wird hierfür kein weiteres Diagramm erstellt.
Kapitel 5
Zusammenfassung
In der vorliegenden Arbeit wurde das Virtual Cord Protocol implementiert. Der
wesentliche Bereich war der Aufbau des Netzwerks, wobei darauf zu achten war,
dass keine Inkonsistenzen auftreten, was durch Locking, dem kurzfristigen Sperren
eines Knotens für neue Request, erreicht wurde. Sobald ein Netzwerk besteht, ist das
Routing von Nachrichten die wesentliche Aufgabe. Dies funktioniert mit Hilfe von
virtuellen Koordinaten, sodass die Nachricht wie an einer Kordel weitergeleitet wird.
Zusätzlich ist es möglich Abkürzungen zu wählen, falls sich ein dem Ziel näherer
Knoten in der direkten Umgebung befindet. Das Routing wurde um Inter-Domain
Routing erweitert, sodass ein Knoten auch Nachrichten in eine andere Kordel versenden kann. Dies geschieht über Gateways, in deren direkten Umgebung sich Knoten
einer anderen Kordel befinden.
Die Entwicklung wurde hauptsächlich mit dem Simulator Cooja durchgeführt, was
den großen Vorteil hatte, dass die aktuellen Änderungen nicht bei jedem Entwicklungsstand auf viele Knoten programmiert werden musste, sondern zuerst getestet
werden konnte.
Zum Abschluss wurde die Implementierung auf den realen TelosB Knoten auf ihre
Leistungsfähigkeit getestet. Dafür wurden zwei Szenarien entwickelt, einerseits ein
Line-Szenario, bei dem jeder Knoten nur mit seinem Vorgänger bzw. Nachfolger
kommunizieren kann. Die Ergebnisse dieses Szenarios zeigen sowohl beim Aufbau
als auch bei der Kommunikation einen linearen Zeitanstieg abhängig von der Knotenanzahl.
Beim zweiten Szenario wurde ein symmetrisches Grid aufgebaut, wobei es den Knoten möglich war mit den 8 direkten Nachbarn kommunizieren. Hierbei ist weniger
die Zeit bei der Kommunikation sondern vielmehr die Anzahl der benötigten Hops
interessant. Diese waren nur um einen Bruchteil höher als die ideal mögliche Anzahl
der Hops, was bedeutet dass durch das Routingprotokoll gute Wege von der Quelle
zur Senke gewählt werden.
31
5 Zusammenfassung
32
Momentan ist Inter-Domain Routing nur mit einer Kordel möglich, die sich in direkter
Umgebung eines beliebigen Knotens der eigenen Kordel befindet. Diese Einschränkung aufzuheben und ein Routing über mehrere Kordeln hinweg zu realisieren
könnte der Inhalt einer zukünftigen Arbeit sein. Außerdem könnte in einer weiteren
Arbeit ein Verfahren entwickelt werden, in dem die Aufteilung der Knoten gleichmäßig verteilt wird. Dadurch könnte korrigiert werden, wenn sich die Knoten so
eingliedern, dass sich zwischen erstem und zweitem Knoten die gleiche Positionsdistanz wie zwischen zweitem und 25. Knoten ergibt.
Abbildungsverzeichnis
1.1 Vergleich von Single- und Multihop . . . . . . . . . . . . . . . . . . . . .
2
1.2 Idee des Inter-Domain Routings, Knoten 12 bzw 50 fungieren als
Gateway mit Knoten 40 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.1 TelosB Knoten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.2 Screenshot Cooja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
3.1 Ablauf beim Erhalt einer Hello-Message . . . . . . . . . . . . . . . . . . 11
3.2 Ablauf zum Eingliedern in Kordel . . . . . . . . . . . . . . . . . . . . . . 12
3.3 Erfolgreicher Ablauf beim Eingliedern zwischen zwei Knoten . . . . . 13
3.4 Erfolgreicher Ablauf beim Übernehmen des Startknotens . . . . . . . . 15
3.5 Erfolgreicher Ablauf beim Erstellen eines Virtuellen Knotens . . . . . 17
3.6 Greedy Forwarding, anstatt die lange Schleife zu wählen, sendet
Knoten 25 direkt an Knoten 90 . . . . . . . . . . . . . . . . . . . . . . . . 19
3.7 Ablauf von globalem Routing, blau ist die globale Nachricht, grün die
lokale und rot der Übergang zwischen den Kordeln . . . . . . . . . . . 21
4.1 Line-Szenario; jeder Knoten hat zwei physikalische Nachbarn . . . . . 23
4.2 Messergebnisse Kordelaufbau im Line-Szenario; Die größere Dauer
auf den realen Knoten lässt sich durch Interferenzen erklären, da
jeder Knoten technisch mit jedem anderen kommunizieren kann; Der
Fehlerbalken beschreibt die Standardabweichung der verschiedenen
Testdurchläufe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3 Grid-Szenario; jeder Knoten hat acht physikalische Nachbarn . . . . . 24
4.4 Messergebnisse: Dauer Kordelaufbau im Grid-Szenario und Nachrichtenversand. Beim Nachrichtenversand beschreibt die Säule die
Anzahl der idealen Hops, der Fehlerbalken die real benötigten Hops.
Der Fehlerbalken beim Kordelaufbau ist die Standardabweichung der
verschiedenen Durchläufe; 5x5 Szenario aufgrund begrenzter Anzahl
von realen Knoten nur in Cooja . . . . . . . . . . . . . . . . . . . . . . . 25
33
Abbildungsverzeichnis
34
4.5 Vergleich von verschiedenen Duty-Cycle Frequenzen bei der Kommunikation im 5x5 Grid-Szenario. Durch eine höhere Frequenz ist eine
schnellere Kommunikation möglich. Bei Kein Duty-Cycle ist das Radio
immer eingeschaltet, die Nachricht kann sofort (wenn der Kanal frei
ist) gesendet werden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.6 Ein möglicher Aufbau des 4x4 Grid Szenarios. Der Knoten 5000 hat
einen Virtuellen Knoten (7500) über welchen Knoten 6250 in die
Kordel integriert ist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.7 Parallele Nachrichten; 4 gleichzeitig sendende Nodes: Node 1, 5, 95
und 99 senden an Node 50 . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.8 Messergebnisse Parallele Nachrichten in Cooja; Der Fehlerbalken beschreibt die Standardabweichung der verschiedenen Testdurchläufe.
Die x-Achse beschreibt die Anzahl gleichzeitig sendender Knoten . . . 29
4.9 Inter Domain Szenario; Knoten 99 stellt Gateway dar . . . . . . . . . . 30
4.10 Messergebnisse Inter-Domain Routing bzw. Kommunikation im Line
Szenario; Der Fehlerbalken beschreibt die Standardabweichung der
verschiedenen Testdurchläufe . . . . . . . . . . . . . . . . . . . . . . . . . 30
Tabellenverzeichnis
3.1 Protokoll für Hello-Messages . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2 Protokoll für Request zum Eingliedern zwischen zwei Knoten . . . . . 13
3.3 Protokoll für Acknowledgment zum Eingliedern zwischen zwei Knoten, einziger Unterschied zu Request ist geänderter Header . . . . . . 14
3.4 Protokoll für Request bei Übernahme des Startknotens . . . . . . . . . 15
3.5 Protokoll für Acknowledgment bei Übernahme des Startknotens, einziger Unterschied zum Request ist der Header . . . . . . . . . . . . . . 16
3.6 Protokoll für Request zum Erstellen eines Virtuellen Knotens . . . . . 17
3.7 Protokoll für Request zum Eingliedern zwischen zwei Knoten . . . . . 17
3.8 Protokoll für lokale Nachrichten . . . . . . . . . . . . . . . . . . . . . . . 18
3.9 Protokoll für Nachrichten zum Verbreiten von Gateway Informationen,
es sind bis zu 12 externe Domains möglich . . . . . . . . . . . . . . . . 20
3.10 Protokoll für globale Nachrichten . . . . . . . . . . . . . . . . . . . . . . 21
4.1 Einstellungen der Zeiten bei den diversen Testdurchläufen . . . . . . . 26
35
Literaturverzeichnis
[1] V. Bharghavan, A. Demers, S. Shenker, and L. Zhang, “MACAW: A Media Access
Protocol for Wireless LAN’s,” in ACM SIGCOMM 1994, London, UK, September
1994, pp. 212–225.
[2] IEEE, Part 15.4: Low-Rate Wirless Personal Are Networks (LR-WPANs), Institute
of Electrical and Electronics Engineers, Inc., Juny 2011.
[3] “ZigBee Specification r17,” ZigBee Alliance, Data Sheet, January 2008.
[4] I. F. Akyildiz, W. Su, Y. Sankarasubramaniam, and E. Cayirci, “A Survey on
Sensor Networks,” IEEE Communications Magazine, vol. 40, no. 8, pp. 102–116,
August 2002.
[5] C. E. Perkins and P. Bhagwat, “Highly Dynamic Destination-Sequenced
Distance-Vector Routing (DSDV) for Mobile Computers,” Computer Communications Review, pp. 234–244, 1994.
[6] D. B. Johnson, Y. Hu, and D. A. Maltz, “The Dynamic Source Routing Protocol
(DSR) for Mobile Ad Hoc Networks for IPv4,” RFC 4728, Internet Engineering
Task Force, Tech. Rep., February 2007.
[7] K. Akkaya and M. Younis, “A survey on routing protocols for wireless sensor
networks,” Ad Hoc Networks, vol. 3, pp. 325–349, 2005.
[8] A. Awad, C. Sommer, R. German, and F. Dressler, “Virtual Cord Protocol (VCP):
A Flexible DHT-like Routing Service for Sensor Networks,” in 5th IEEE International Conference on Mobile Ad-hoc and Sensor Systems (MASS 2008). Atlanta,
GA: IEEE, September 2008, pp. 133–142.
[9] M. Caesar, M. Castro, E. B. Nightingale, G. O’Shea, and A. Rostron, “Virtual
ring routing: Network routing inspired by dhts,” ACM SIGCOMM Computer
Communication Review, vol. 36, pp. 351–362, October 2006.
[10] A. Awad, R. German, and F. Dressler, “Exploiting Virtual Coordinates for Improved Routing Performance in Sensor Networks,” IEEE Transactions on Mobile
Computing, vol. 10, no. 9, pp. 1214–1226, September 2011.
36
Literaturverzeichnis
37
[11] F. Dressler, A. Awad, R. German, and M. Gerla, “Enabling Inter-Domain Routing
in Virtual Coordinate Based Ad Hoc and Sensor Networks,” in 15th ACM International Conference on Mobile Computing and Networking (MobiCom 2009),
Poster Session.
Beijing, China: ACM, September 2009.
[12] “MSP430 - Mixed Signal Microcontrollers Datasheet,” Texas Instruments, Data
Sheet, December 1998.
[13] “CC2420 Preliminary Datasheet,” Chipcon, Data Sheet, Juny 2004.
[14] “Datasheet SHT1x,” Sensirion, Data Sheet, December 2011.
[15] “S1087/S1133 series Datasheet,” Hamamatsu Photonics K.K., Data Sheet,
April 2001.
[16] A. Dunkels, B. Groenvall, and T. Voight, “Contiki - a lightweight and flexible
operating system for tiny networked sensors,” in LCN ’04 Proceedings of the 29th
Annual IEEE International Conference on Local Computer Networks, November
2004, pp. 455–462.
[17] A. Dunkels, O. Schmidt, and T. Voigt, “Using protothreads for sensor node
programming,” in In Proceedings of the REALWSN 2005 Workshop on RealWorld
Wireless Sensor Networks, 2005.
[18] A. S. Tanenbaum and M. van Steen, Distributed Systems: Principles and Paradigms, 2nd ed.
Prentice Hall International, 2007.