BVR - Beacon Vector Routing auf SunSPOTs

Transkript

1 Fachhochschule Wiesbaden Fachbereich Design Informatik Medien Studiengang Allgemeine Informatik Multimedia Kommunikationssysteme Wintersemester 2008/2009 BVR - Beacon Vector Routing auf SunSPOTs vorgelegt von: Ralph Erdt Markus Fischer Betreuer: Prof. Dr. Martin Gergeleit

2 II

3 Inhaltsverzeichnis 1 Einleitung 1 2 Funktionsweise des Routing Protokolls Der Beacon Vektor Weiterleitung von Nachrichten Beacon Maintenance Implementierung Software Architektur Überblick genutzte Pattern BVR Beacon Handling Nachbarschafts Handling ARP Senden Routing Pakete Hilfsklassen TODO Threads Details zur Stabilisierung des Netzes Störquellen Lösungen Anwendung III

4 3.3.1 Anzeigen des Netzes Inizialisation Empfang Anzeige Identifizieren von Knoten Traceroute Steuerung des Knoten Fazit Theorie vs Realität Nachbarschaften Bewertung unserer Implementierung Literaturverzeichnis 29 IV

5 Abbildungsverzeichnis 2.1 Beacon Vektoren in den Knoten (Bild der Stationen aus [ope]) Erste Routing-Schritt einer Nachricht von {0,2,5} nach {4,2,1} (Bild der Stationen aus [ope]) Routing Pseudocode ähnlich [FRC + 05] Pseudocode zur Wartung der Beacons ähnlich [FRC + 05] SunSPOTs, Experimentalsensorknoten von Sun Threads in einem Knoten Empfangsstärken Messung, d=5cm, max=2m Antenne eines SunSPOTs Schema von Richtcharaktaristika, B empfängt A, aber A nicht B Unbemerkte Kollision der Übertragungen von A und B V

6 VI

7 Tabellenverzeichnis 2.1 Paket-Header nach [FRC + 05] VII

8 VIII

9 Kapitel 1 Einleitung In der Vertiefungsveranstaltung Multimedia Kommunikationssysteme wurden verschiedene Ad Hoc Routing Protokolle implementiert. Wir haben uns für das hier vorgestellte Beacon Vector Routing Protokoll entschieden und frei nach [FRC + 05] implementiert. Als Zielplattform standen dabei SunSPOTs zur Verfügung. Die vorliegende Arbeit ist in zwei Hauptbereiche gegliedert. Kapitel 2 erklärt die Grundlegende Funktionsweise des BVR Routing Protokolls. Kapitel 3 beschreibt detailliert unsere Umsetzung der in Kapitel 2 vorgestellten Methoden. Den Abschluss bildet Kapitel 4 mit einem Fazit. 1

10 2 Kapitel 1. Einleitung

11 Kapitel 2 Funktionsweise des Routing Protokolls In diesem Kapitel wird die Funktionsweise des Beacon Vector Routing (BVR) Protokolls vorgestellt. Als Referenz für die Implementierung des BVR diente [FRC + 05]. Hierzu wird zunächst in Abschnitt 2.1 der Beacon Vektor eingeführt, der auf jedem Knoten gehalten wird und eine zentrale Bedeutung für das Routing hat. Wie das Routing, also das Weiterleiten der Nachrichten im Detail arbeitet, wird in Abschnitt 2.2 erläutert. Die Regulierung, wieviele Beacon-Knoten in einem Netzwerk aktiv sind, wird in Abschnitt 2.3 erläutert. 2.1 Der Beacon Vektor Das Routing mittels BVR passiert über die Abstände zu bestimmten Knoten, sogenannten Beacon-Knoten, im Netzwerk. Welche Knoten zu Beacon-Knoten werden, ist nicht statisch festgelegt. Eine statische Festlegung, welche Knoten zu Beacon-Knoten werden, würde keinen Sinn machen, da es sich bei BVR um ein Ad hoc Routing Protokoll handelt. Das bedeutet also, die Knoten sollen auf einer Fläche verteilt werden können und sich dann dynamisch zu einem kommunikationsfähigen Netzwerk mit Routing Funktionalität selbst konfigurieren. Der Algorithmus für die Entscheidung, ob ein Knoten sich selbst zum Beacon-Knoten ernennt, wird in Abschnitt 2.3 vorgestellt. Dieser Algorithmus ist so gewählt, dass bestimmte Knoten zu Beacon-Knoten werden, unabhängig davon, ob nur ein paar Beacon-Knoten im Netzwerk ausgefallen sind oder ob noch gar keine Beacon-Knoten im Netzwerk existieren. Wie viele Knoten zu Beacon-Knoten werden, ist in [FRC + 05] als Konstante r definiert. 3

12 2.2. Weiterleitung von Nachrichten Kapitel 2. Funktionsweise des Routing Protokolls Der Abstand zu einem Beacon-Knoten wird in Hop-Anzahl gemessen und auf jedem Knoten im Beacon-Vektor gespeichert. Somit kennt jeder Knoten den Abstand zu den Beacon- Knoten. Abbildung 2.1 zeigt ein Beispiel mit einem Netzwerk, das aus 13 Knoten besteht. In diesem Beispiel ist die Anzahl Beacons r auf drei gesetzt. Die Beacon-Knoten sind in Rot dargestellt und ihre ID ist rechts neben dem Knoten im Bild eingezeichnet. Beispielhaft betrachtet hat der Knoten mit der ID 1 zu sich selbst eine Hop-Anzahl von 0, zu dem Beacon-Knoten mit der ID 2 eine Hop-Anzahl von 2 und zu dem Beacon-Knoten mit der ID 3 eine Hop-Anzahl von 5. Da zwei Knoten einen identischen Abstand zu den Beacon-Knoten haben können (Abbildung 2.1 die Knoten {3,1,2}), ist es wichtig, dass zur eindeutigen Identifizierung der Knoten auch immer eine eindeutige Knoten ID vorhanden ist. Ein weiterer Punkt ist der, dass der Vektor sich verändern kann, eine eindeutige Knoten ID jedoch hat eine dauerhafte Gültigkeit. Um nun Routing-Entscheidungen durchzuführen, ist es erforderlich, dass alle Knoten ihren Beacon-Vektor und ihre eindeutige ID an ihre Nachbarknoten verteilen. Ein Knoten, der eine Nachricht an einen andern Knoten verschicken will, kennt zunächst nur dessen eindeutige ID. Um die in Kapitel 2.2 vorgestellten Routing-Entscheidungen zu treffen, muss aber der Beacon-Vektor des Zielknotens bekannt sein. Für diese Zuordnung wird in [FRC + 05] grob ein Location Directory beschrieben, bei dem das Mapping von Knoten ID auf zugehörigen Beacon-Vektor bei den Beacon-Knoten geregelt wird. Diese vorgehensweise erschien uns wenig praktikabel, aus diesem Grund wird auf diese Art von Location Directory nicht weiter eingegangen. Weitere Details zu unserer Lösung für das Mapping-Problem finden sich in Abschnitt Weiterleitung von Nachrichten Die Weiterleitung der Nachrichten basiert auf einer Distanzfunktion δ(p, d). Diese Distanzfunktion bewertet, wie nützlich ein potentieller nächster Knoten p für die Weiterleitung einer Nachricht mit dem Ziel d ist. Als Eingabeparameter dienen die Beacon- Vektoren (siehe 2.1) des Knotens p und des Zielknotens d. δ + (p, d) = max(p i d i, 0) i C k (d) δ (p, d) = max(d i p i, 0) i C k (d) 4

13 Kapitel 2. Funktionsweise des Routing Protokolls 2.2. Weiterleitung von Nachrichten Abbildung 2.1: Beacon Vektoren in den Knoten (Bild der Stationen aus [ope]) C k (d) sind die k Hop-technisch nächsten Beacon-Knoten zum Zielknoten d. k ist also die Anzahl der Beacon-Knoten, die für die Weiterleitung der Nachrichten zum Zielknoten relevant sind. Dies ist wichtig, damit die Zieladressen in den Paketen nicht zu groß/lang werden. δ + ist also die Summe der Abstände eines möglichen nächsten Knotens p zu Beacon-Knoten, die näher an der Zieladresse d sind. δ hingegen ist die Summe der Abstände eines möglichen nächsten Knoten p, der weiter entfernt von den Beacon-Knoten ist, die näher am Zielknoten d liegen. Grundsätzlich ist es aber wichtiger, Nachrichten zu Knoten hin zu schicken, die näher an Beacon-Knoten sind, die auch zu d nahe sind. Also versucht der Algorithmus primär einen neuen Weiterleitungsknoten zu finden, der einen minimalen δ + Wert im Vergleich zu den andern Nachbarn hat. Lässt sich so kein eindeutiges Minimum finden, wird δ ebenfalls ausgewertet. In [FRC + 05] wird für die praktische Umsetzung eine einfache Gewichtung mittels der folgenden Formel empfohlen: δ k = A δ + k + δ k Für den Gewichtungsfaktor A wird in [FRC + 05] der Wert 10 gewählt. Diese Formel liegt dem Beispeil in Abbildung 2.2 zu Grunde. Der Knoten mit der ID 1 berechnet die δ-werte für seine benachbarten Knoten, in der Abbildung in den grünen Kästen dargestellt. Der Knoten mit dem Beacon-Vektor {1,1,4} hat das kleinere Ergebnis für δ, also wird die Nachricht dorthin weitergeleitet. Der Knoten mit dem Beacon-Vektor 5

14 2.2. Weiterleitung von Nachrichten Kapitel 2. Funktionsweise des Routing Protokolls Abbildung 2.2: Erste Routing-Schritt einer Nachricht von {0,2,5} nach {4,2,1} (Bild der Stationen aus [ope]) FELD dst P (dst) δ min BESCHREIBUNG Eindeutige Zielknoten ID Beacon-Vektor des Zielknotens Minimaler Kostenwert des bisherigen Paketpfades Tabelle 2.1: Paket-Header nach [FRC + 05] {1,1,4} führt dann die gleiche Berechnung für seine Nachbarknoten durch und leitet die Nachricht entsprechend weiter. Tabelle 2.2 zeigt den BVR-Paket-Header, bestehend aus eindeutiger Zielknoten ID, Beacon-Vektor des Zielknotens, sowie δ min. Der Wert von δ min ist der minimale Kostenwert eines bisher genommenen Pfades des Pakets. Abbildung 2.3 zeigt den Pseudocode aus [FRC + 05] mit ein paar kleineren Änderungen, die nur kosmetischer Natur sind. Wenn ein zu routendes Paket P an die Methode BVR_FORWARD des Knotens curr übergeben wird, wird zunächst P.δi min (siehe Tabelle 2.2) aktualisiert. Die Konstante k folgt dabei der bereits vorgestellten Definiton, k ist also die Anzahl Beacons, die für das Routing der jeweiligen Nachricht verwendet werden. Das Update von P.δ min i ist wichtig, um Schleifen in den Routen zu vermeiden. Dann wird die Entfernung aller curr-nachbarknoten zu P.dst berechnet. Der Nachbar mit der kleinsten Entfernung zu P.dst wird in next gespeichert. Findet sich nun ein next- Knoten mit einer kleineren Entfernung zum Ziel des Paketes P.dst, die kleiner ist als P.δ min, so wird P dorthin weiter geleitet. Im ersten Schritt wird dieser Vergleich mit allen 6

15 Kapitel 2. Funktionsweise des Routing Protokolls 2.2. Weiterleitung von Nachrichten BVR_FORWARD(node curr, packet P ) // update packet header for ( i=1 to k ) do = min(p.δi min P.δ min i, δ i (curr.p.dst) // try greedy forwarding for ( i=k to 1 ) do next = min(δ i (NeighbourOf(curr), P.dst)) if(δ i (next, P.dst < P.δi min ) then unicast p to next // fail, fallback mode fallback_beacon = closest Beacon to P.dst if(f allback_beacon! = curr) then unicast P to fallback_beacon // fallback failed, use flooding broadcast P with scope P.P (dst)[fallback_beacon] Abbildung 2.3: Routing Pseudocode ähnlich [FRC + 05] k Beacons durchgeführt, wird jedoch kein Nachbar mit einer kleineren Entfernung zum Zielknoten gefunden, so werden Schritt für Schritt weniger Beacons in die Berechnung mit einbezogen. Da es vorkommen kann, dass kein besserer Knoten gefunden werden kann, ist ein Fallback-Mode enthalten. Im Fallback-Mode wird das Paket in der Richtung des Beacons versendet (f allback_beacon), der am nächsten zum Zielknoten P.dst ist. Kommt das Paket beim f allback_beacon an und findet dieser immer noch keine Möglichkeit, das Paket weiter zum Zielknoten zu leiten, kommt ein scoped flooding zum Einsatz. Der f allback_beacon kann für das scoped flooding eine maximale Anzahl Hops festlegen, nämlich genau die Anzahl Hops, die in P.P (dst) für den f allback_beacon selbst angegeben ist. Durch diese Begrenzung der Hops, wird der durch das Flooding entstehende Netzwerkverkehr zumindest auf eine kleinere Region des gesamten Netzwerks beschränkt. 7

16 2.3. Beacon Maintenance Kapitel 2. Funktionsweise des Routing Protokolls BEACON_ELECT_MYSELF(r, B) // invoked periodically // B is the current set of Beacons if( B < r) then set Timer T = log(myid) log(maxid(b)) T max + jitter TIMER_T_EXPIRES(r, B) if( B < r) then Announce myself as a beacon BEACON_SURPRESS_MYSELF(r, B) if(myid B) & ( B > r) & (myid > r th guested(b)) then Stop announcing myself as beacon Abbildung 2.4: Pseudocode zur Wartung der Beacons ähnlich [FRC + 05] 2.3 Beacon Maintenance Der Algorithmus zur Beacon Maintenance ist in Abbildung 2.4 dargestellt. Dieser Algorithmus wird verwendet, um die Anzahl der Beacon-Knoten, die im Netzwerk aktiv sind, zu steuern. Dabei ist es unerheblich, ob das Netzwerk gerade erst hochgefahren wird und somit noch gar keine Knoten als Beacon-Knoten aktiv sind oder ob ein Beacon-Knoten im laufenden Betrieb ausfällt. Bedingt durch die Ausfälle können kurzzeitig Fehler im Beacon-Vektor auftreten, dadurch bedingt ist der hier vorgestellte Algorithmus zur Beacon Maintenance keineswegs perfekt [FRC + 05]. Der in Abschnitt 2.2 vorgestellte Weiterleitungsalgorithmus kann aber auch mit weniger als r Beacon-Knoten ein Routing durchführen, insofern ist der hier vorgestellte einfache Algorithmus zur Beacon Maintenance aus [FRC + 05] durchaus akzeptabel. Der Aus- oder Wegfall eines (Beacon-)Knotens kann im Sensornetzumfeld oft vorkommen (Batteriekapazität erschöpft, Kommunikationsstörungen usw), aus diesem Grund ist es besonders wichtig solche Fälle abzufangen. Die Funktionen aus Abbildung 2.4 werden im folgenden näher erläutert. BEACON_ELECT_MYSELF Überprüft regelmäßig ob genug Beacon-Knoten im Netzwerk aktiv sind. Wenn nicht, wird ein Timer gestartet, dessen Laufzeit T von folgender Formel abhängt: T = log(myid) log(maxid(b)) T max + jitter 8

17 Kapitel 2. Funktionsweise des Routing Protokolls 2.3. Beacon Maintenance Die eigene eindeutige Knoten ID wird mit in die Berechnung der Laufzeit von T einbezogen um zu verhindern, dass mehrere Knoten zur gleichen Zeit die Funktion TI- MER_T_EXPIRES ausführen, da diese Funktion sofort nach Ablauf von T gestartet wird. TIMER_T_EXPIRES Läuft der Timer T also ab, so wird überprüft, ob immer noch nicht genug Beacon- Knoten im Netzwerk aktiv sind und wenn das der Fall ist, beginnt der Knoten selbst als Beacon aktiv zu werden. BEACON_SURPRESS_MYSELF Alle Knoten überprüfen periodisch mit dieser Funktion, ob sie weiterhin als Beacon- Knoten aktiv sein müssen. Folgende drei Kriterien müssen dafür erfüllt sein: 1. Eigene Knoten ID (myid) muss in der Liste der Beacons B enthalten sein. 2. B > r Die tatsächliche Anzahl Beacons B ist größer als die vorgegebene Anzahl Beacons r. 3. myid > r th guested(b) Unter den Beacon-Knoten existieren r Knoten IDs, die kleiner sind als die eigene Knoten ID. Sind diese drei Kriterien erfüllt, so beendet der Knoten seine Aktivität als Beacon-Knoten. 9

18 2.3. Beacon Maintenance Kapitel 2. Funktionsweise des Routing Protokolls 10

19 Kapitel 3 Implementierung Für die Implementierung standen SunSPOTs als Sensorkonten zur Verfügung. Abbildung 3.1: SunSPOTs, Experimentalsensorknoten von Sun Diese Knoten werden komplett mir Java 1.4 programmiert. Als virtuelle Maschine gibt es die Squawk VM. Zur Funkkommunikation nutzt es , also die gleiche Hardware wie Zigbee. Die Rechweite ohne Umweltstörungen beträgt fünf bis zehn Meter, wobei ab fünf Meter die Paketverlustrate zunimmt. 3.1 Software Architektur Überblick Neben den zentralen Klassen, die die BVR Logik implementieren, gibt es die Klassen BVRPaket und Beacon. 11

20 3.1. Software Architektur Kapitel 3. Implementierung Alle zu sendenden / empfangenen Nachrichten werden in BVRPaket gespeichert. Die Informationen über Beacons (Adresse, Hopabstand) werden in der Klasse Beacon gespeichert. Netzwerk Da das ansprechen des physikalischen Layers nicht nach unseren Vorstellungen funktioniert hatte, wurde die Kommunikation mittels Datagrammen realisiert. Das entspricht UDP bei TCP/IP. Dazu werden zwei Kommunikationsverbindungen geöffnet, eine zum senden, eine zum empfangen. Alle Nachrichten werden auf der Schicht generell gebroadcastet, um möglichst Hardwarenah zu implementieren. Entscheidungen, ob das Paket geroutet, akzeptiert, geflutet oder ignoriert werden muss, macht die Implementation. Optische Rückmeldung Die erste LED leuchtet grün auf, wenn das Programm in der Empgangsroutine ist, also wenn die empgangenen Daten verarbeitet werden. Die letzte LED leuchtet rot, wenn Daten gesendet werden. Adressen Broadcast gehen an die Adresse 0. Diese werden grundsätzlich nicht geflutet, das Fluten übernimmt dann die Anwendung. Ursprünglich wurde angedacht, das die entsprechende Anwendung dafür sorgt, das keine Braodcaststürme auftreten. Allerdings musste im Zuge der ACK Implementierung ein Schutz gegegn doppelte Pakete implementiert werden, so das nun auch die Anwendungen davon profitieren. Als weitere Spezialadresse wird die -1 genutzt. Diese wird als letzte Möglichkeit eingesetzt, wenn beim Routen kein nächster Hop ermittelt werden kann. Dann Routen alle Knoten, die dieses Paket empfangen haben, das Paket weiter. Als Adresse werde die MAC-Adressen der SunSPOTs genutzt. Allerdings findet die gesamte Kommunikation in Klartext statt (Byte-Stream), ohne die vorhandene Hilfsklassen zu verwenden. Die Adresse ist 64 Bit (8 Byte) groß. Im Dezimalschreibweise sind das mehr als 19 Stellen, als hexadezimal codiert immernoch 16 Stellen. Um die NAchricht un den Speicherverbrauch niedrig zu halten, wurden als Adresse nur die letzten 2 Byte genommen, da die ersten 6 Bytes auf usneren Spots immer gleich sind. 12

21 Kapitel 3. Implementierung 3.1. Software Architektur Konstanten Im Paper [FRC + 05] werden viele Konstanten genutzt R, k, etc. ohne diese genauer zu bestimmen. Diese Konstanten werden alle gesammelt in einer extra Klasse definiert. Zusätzlich werden diese dynamisch änderbar gemacht. Dazu siehe aber Kapitel genutzte Pattern Singelton Java ist eine objektorientierte Sprache. Allerdings werden die zentralen Routinen nur einmal gebraucht, so das sich da ein Singelton Pattern anbietet. Ein Singeltonpattern benötigt aber leicht erhöhten Codeaufwand, und man muss entweder die Objektreferenz durchschleifen, oder implementiert ein getobjekt, das immer nur ein Objekt zurückgibt. Um hier aber ein Quäntchen mehr Geschwindigkeit und Übersicht zu erhalten, wurden alle Variablen und Methoden der zentrale Klassen als static definiert, so das zum Zugriff nur <Klasse>.<Methdode> ausreicht. Der Nachteil ist, das dadurch die Variablen nicht garantiert in einen definierten Zustand sind. Da aber die komplette Umgebung / das komplette Programm unter unserer Kontrolle steht, und das keine Produktivimplementation sein soll, ist das akzeptabel. Listener Die Nachrichten können verschiedener Typen sein. Beacon, ARP, Nachbarschaft, etc. Daher bekommt jede Nachricht den Typ mit. Und jede Routine, die einen Typ empfangen will, registriert sich beim BVR als Listener. Da aber die meissten Klassen aufgrund der static Sache keine Objekte sind, wird die Empfangsmehtode als einzige nicht static deklariert, und das Objekt einmal erstellt und an den Listener übergeben BVR Die Zentrale Klasse ist BVR. Diese öffnet die Kommunikationskanäle, empfängt und sendet also Pakete. Hier werden auch die Entscheidungen getroffen, wie mit einem empfangenen Paket umzugehen ist. Auch hier ist die Listenerverwaltung implementiert. Hier ist auch die Distancefunktion implementiert. 13

22 3.1. Software Architektur Kapitel 3. Implementierung Beacon Handling Im ersten Schritt geht es um die Ermittlung einer Adresse in Form des Beacon-Vektors. Alle nötigen Verarbeitungen dazu sind in der Klasse BeaconHandling implementiert. Ein Vektor, wie im Paper beschrieben, ist aber nicht geeignet, da man nicht weis, welcher Beacon welcher Stelle entspricht, und vor allen: welche Beacons sind gerade aktiv? Daher wurde dafür eine Hashmap verwendet, die die Adresse (als String) auf ein Beacon-Objekt abbildet. Bestimmung von Beacons Die Implementation des Beacon Maintaince nach [FRC + 05], Absatz Beacon Maintenance, geschieht mit Timern. Ein Timer überprüft regelmäßig BEACON ELECT MYSELF und BEACON SUPPRESS MYSELF (Methode: testegenugbeacons).dort wird regelmäßig die Anzahl der Beacons geprüft. BEACON ELECT MYSELF Sollte die Anzahl der Beacons niedriger als R sein, und der aktuelle Knoten ist kein Beacon, dann wird ein weiterer Timer (T) angestartet. Die Zeit ist das Verhältnis zwischen der maximalen ID aller Beacons und der ID des Knotens. So werden Knoten mit niedriger ID bevorzugt. Im Paper wird die log Funktion verwendet, die aber nicht in der Javaversion zur Verfügung steht. Da damit nur das Verhältnis ausgedrückt werden soll, wurde einfach auf die Funktion verzichetet. Wenn noch kein Beacon aktiv ist (was bei dem ersten Starten des Netzes gegeben ist), so ist die MaxID nicht ermittelbar. In diesem Fall ist die ID = 1. Um zu verhindern, das die Knoten beliebig lange warten, wurde eine maximale Wartezeit definiert. BEACON SUPPRESS MYSELF Im gleichen Timer wird auch überprüft, ob es mehr Beacons als R gibt, und ob der aktuelle Knoten ein Beacon ist. Danach wird geprüft, ob die ID des Knoten größer als die R-kleinsten IDs aller Beacons ist. Wenn ja, wählt sich der Knoten als Beacon ab. Wenn der Knoten sich abwählt, dann flutet dieser Knoten eine Nachricht, das er kein Beacon mehr ist. 14

23 Kapitel 3. Implementierung 3.1. Software Architektur TIMER T EXPIRES Der in BEACON SUPPRESS MYSELF angestartet Timer überprüft wieder, ob es zuwenig Beacons sind. Wenn ja, wählt sich der Knoten als Beacon. Senden der Beacons Wenn der Knoten sich als Beacon gewählt hat, dann sendet der Knoten regelmäßig die Beacon-Pakete. Empfang der Beacon-Pakete Die Klasse meldet sich als Empfänger für B (wie Beacon) an. Damit bekommt es alle Beacon-Pakete. Bei jedem Beacon wird in der Liste nachgesehen, und das zugehörige Beacon-Objekt geholt. Sollte keines da sein, so wird eines neu angelegt. Solle es aber da sein, so wird der Hop-Counter verglichen. Ist der neue Counter kleiner, dann werden die Daten geupdatet, der Hop counter im empfangenen Beacon-Paket höher gesetzt und das Paket wird weitergebroadcastet. Ist der gespeicherte Hopcounter gleich dem Hopcounter im Paket, dann wird die Seqenznummer verglichen. Ist die Sequenzenummer im empfangenem Paket größer, dann werden die Daten geupdatet, der Hop counter im empfangenen Beacon-Paket höher gesetzt und das Paket wird weitergebroadcastet. Prüfung der Seqenznummer auf ungleich reicht nicht, da es sein kann, das ein Beacon- Paket noch im Netz verzteilt wird, wenn schon ein neues Paket gesendet wird. Zum erkennen von toten Beacons wird die Liste gegelmäßig (per Timer) geprüft. Dazu wird jedesmal eine timeout Variable hochgesetzt. Die Variable wird bei jedem update des Beacons zurückgesetzt. Sollte die Variable also einen zu hohen Wert annehmen, so ist dieser Beacon tot, und wird aus der Liste genommen. Optische Rückmeldung Ob der Knoten als Beacon agiert, zeigt dieser mir der zweiten LED an. Leuchtet diese blau, so ist dieser Knoten ein Beacon. Wenn nun noch die rote Komponente in dieser LED zusätzlich aufleuchtet, sendet der Knoten gerade das Beacon-Paket. 15

24 3.1. Software Architektur Kapitel 3. Implementierung Nachbarschafts Handling Das Nachbarschaftshandling ist ähnlich des Beaconhandlings. Jeder Knoten brodcastet regelmäßig seinen Beacon Vector. Alle Empfänger speichern diesen an. Aufgrund der Ähnlichkeit zu dem Beacon-Handling ist dieses auch in der Klasse BeaconHandling implementiert ARP Eine Adressauflösung, die einer (gekürzten) MAC-Adresse auf einen Beacon-Vector abbildet ist zwingend notwendig. Der Beacon-Vector steht nicht statisch fest. Auch können mehrere Knoten den gleichen Beacon-Vektor haben. Daher wird mit den MAC-Adressen gearbeitet, und der Beacon-Vector wird nur zum Routen verwendet. Im Paper gibt es nur einen Vorschlag, der uns nicht gefällt. Einerseits sieht es uns nach einer hohen Belastung des Namensserver aus, so das dieser wesentlich früher ausfallen dürfte. Und dann bricht das Netz zusammen, da es keinen weiteren Knoten gibt. Zusätzlich wurde die Frage nicht geklärt, wie denn ein Knoten an den Beacon-Vector des Namensservers kommt, um sich zu registrieren oder den Vector des Zieles (Namensserver?) nachzusehen. Das Paper betont aber ausdrücklich, das das ARP kein Thema der Arbeit ist, und das obige nur ein Vorschlag. Daher waren wir so frei, und haben ein TCP/IP ähnliches ARP Protokoll implementiert: Jeder Knoten, der eine Adresse sucht, flutet diese Anfrage im Netzwerk (muss von jedem Knoten weitergeleitet werden). Als Nutzlast sendet der Knoten seinen eigenen Beacon- Vector mit. Das Ziel merkt nun, das jemand seine Adresse sucht. Den Beacon-Veactor des Absenders wird in den Cache gelegt, und dann diesen Absender eine Antwort gesendet, wobei dieses schon geroutet werden kann. Im Gegensatz zu TCP/IP ARP antwortet nicht jedes System, das die Adresse kennt. Einerseits würde so der Absender von Antworten überschüttet werden, andererseits - wer weis, wie alt die Daten sind. Zusätzlich sind die Adressen mit einem Timout versehen, so das diese nach einiger Zeit verfallen, und der Knoten die Adresse neu erfragen muss. Das wurde implementiert, damit Änderungen im Netz auch durchkommen. 16

25 Kapitel 3. Implementierung 3.1. Software Architektur Senden Soll nun ein gerichtetes Paket geschickt werden, also ein Paket an einen bestimmten Empfänger, dann wird zuerst geprüft, ob denn der Beacon-Vector des Zieles bekannt ist. Wenn der Vector nicht bekannt ist, dann wird das Paket erstmal in einen Cache zwischengespeichert, und ein ARP durchgeführt. Sobald die ARP-Antwort kommt, werden alle gechachten Pakete zu dieser Adresse gesendet Routing Das Routing ist in der Klasse BVR implementiert. Da dieses nach dem Paper implementiert wurde, ist hier kaum etwas weiter zu erwähnen. Nur bei der letzte Möglichkeit, wenn kein nächster Hop ermittelt werden kann, wird das Paket gebraoadcastet. Als Adresse wird bei nexthop die -1 eingetragen, da bei der Adresse 0 jeder Knoten das Paket verarbeitet Pakete Die versendeten Pakete werden in Objekten der Klasse BVRPaket gehalten. Die Objekte können sich selbst zu einem String serialisieren, der beim Senden zu einen Bytestrom umgewandelt wird. Auch kann die Klasse ein BVRPaket aus einem Bytestrom erstellen, so das empfangene Daten zu einem Objekt umgewandelt werden. Als Nutzdaten hat es ein Array von Strings, und entsprechende Methoden, um einfach darauf zugreifen zu können. Um zum Beispiel weitere Daten anzuhängen, übergibt man als Position -1, und es wird eine weitere Stelle im Array angelegt und der String gespeichert. Als Kopfdaten sind diese Felder immer drin: Art: Welcher Art ist das Paket? B eacon, D aten, A RP Ziel ( finaldestination ): Die MAC-Adresse des Empfängers. Absender: Die MAC-Adresse des Absenders nexthop: Der nächste Hop, also der Knoten, der Routen soll. 17

26 3.1. Software Architektur Kapitel 3. Implementierung vorhop: Von diesem Knoten kommt das Paket. (Für das ACK senden, Kapitel Beaconliste: Die Liste der k nächsten Beacons des Ziels. Anhand dieser Inforamtion wird geroutet. δ min : Die minimalsten Kosten, die bisher aufgetreten sind (nach Paper) Das sind wesentlich mehr Kopfdaten als für das Routing erforderlich. Aber die Umgebung macht das erforderlich Hilfsklassen Zusätzlich gibt es diese Klassen: Interface IEmpfang : Für den Listener. Jedes Objekt, das Pakete empfangen will, muss dieses Interface implementieren. Beacon: Speicherklasse für einen Beacon. Speichert Adresse, Hopcount, Timeout. Const: Alle Konstanten. LEDs: Klasse um die LEDs zu steuern. StartApplication: Das ist die Klasse, die als erstes gestartet wird TODO Die Implementierung ist zwar grob vollständig, aber es fehlen noch einige Wartungsroutinen. Also z.b. wird der SendeCache (die Pakete, die auf eine ARP Auflösung warten) nicht regelmäßig gereinigt. Dieses ist für eine Produktivumgebung zwingend erforderlich, aber unserer Implementation dient nur akademischen Zwecken, daher wurde die Priorität dieser Aufgaben niedrig eingestuft, und erstmal vernachlässigt Threads Abbildung 3.2 zeigt die verschiedenen Threads die in einem Knoten aktiv sind. Jeder durch eine gestrichelte Linie dargestellte Kasten stellt einen Thread dar. In dem Kasten 18

27 Kapitel 3. Implementierung 3.1. Software Architektur Abbildung 3.2: Threads in einem Knoten ist die jeweilige Worker-Funktion aufgeführt. Die Threads lassen sich in drei Kategorien einteilen. Erstens Threads für die Klasse BVR: BVR.empfang: Empfängt die Nachrichten vom Netzwerk und aktiviert die Listener BVR.emfpangsCacheMaintaince: Wartet den Empfangscache mittels Timeouts für Nachrichten. BVR.resendPakete: Wiederholt Nachrichten wenn kein ACK eingetroffen ist innerhalb eines Timeouts Zweitens Threads für die Klasse BeaconHandling: BeaconHandling.testeGenugBeacons: Überprüft periodisch ob genug Beacon-Knoten im Netzwerk aktiv sind. BeaconHandling.testeToteBeacons: Überprüft ob Beacon-Knoten ausgefallen sind. BeaconHandling.NachbarnFrage: Fordert eine Nachbarschaftsupdate von den Nachbarn an. BeaconHandling.BeaconSenden: Sendet die Beacon-Nachricht des Knotens, sofern dieser als Beacon-Knoten arbeitet. Drittens Threads für allgemeine Aufgaben: Datenversand.versendeDaten: Verschickt die Nachrichten ans Netzwerk. 19

28 3.2. Details zur Stabilisierung des Netzes Kapitel 3. Implementierung ARP.HashtabplesMaintaince: Wartet den ARP-Cache und entfernt veraltete Werte. Steuerunsgeingang: Reagiert auf die Eingabe der zwei Taster an den SunSPOTs. 3.2 Details zur Stabilisierung des Netzes Die Arbeiten zur Stabiliserung des Netzes war das aufwendigste in der ganzen Entwicklung Störquellen Die kabellose Funktübertragung ist im äußersten Fall undeterministisch. Einmal kann ein Paket auf zehn Meter gesendet werden, und mal ist man froh, wenn es zwei Meter schafft. Das Bild 3.3 zeigt eine Messung von Empfangsstärken in 5 Zentimeter Abstand auf zwei Metern. Abbildung 3.3: Empfangsstärken Messung, d=5cm, max=2m Es wurde so gemessen: Zwei Knoten in entsprechenden Abstand auf Säulen, und dann schickt ein Knoten 50 Pakete an den anderen Knoten. Wie man sehen kann, schwankt die Stärke beträchtlich, ohne das sich der Knoten bewegt. In diesen Messungen gibt es kein Paketverlust, dieser ist aber durchaus bei größeren Entfernungen gegeben. 20

29 Kapitel 3. Implementierung 3.2. Details zur Stabilisierung des Netzes Abbildung 3.4: Antenne eines SunSPOTs Das Bild 3.4 ist ein Foto der Antenne eines SunsPOTs. Diese sind die Leitungen oberhalb des Metallschirms. Diese ist nicht symetrisch, und daher liegt die Vermutung nahe, das die Sendereichtung sehr asymetrische ist, also eine starke Richtcharakteristika hat. Durch die Richtcharakteristika ist die Gegenseitigkeit der Kommunikation nicht gegeben. Siehe dazu Bild 3.5. Wenn der Knoten B den Knoten A hören kann, ist durchaus möglich, das der Knoten A nicht den Knoten B hören kann. Zusätzlich kommt das Problem, das es Kollsisionen gibt, ohne das die beteidigten Sender es merken. Siehe dazu das Bild 3.6. Der Knoten A und B senden gleichzeitig, ohne die mitbemommen, das sie eine andere Übertragung stören. Knoten C kann deswegen beide Übertragungen nicht empfangen Lösungen zu Stärke Das Problem mit den schwankenden Empfangstärken wurde mit Schwellwerten gelöst. Beacons und Nachbarschaften werden nur akzeptiert, wenn die Empfangsstärke größer eines Schwellwertes ist, bzw. wenn schonmal Beacons / Nachbarschaften so akzeptiert wurden. Dadurch, das man einen hohen Schwellwert vorgibt, kann man hoffen, das alle späteren Pakete zumindest noch ohne Probleme empfangbar sein werden. 21

30 3.2. Details zur Stabilisierung des Netzes Kapitel 3. Implementierung B A Abbildung 3.5: Schema von Richtcharaktaristika, B empfängt A, aber A nicht B Abbildung 3.6: Unbemerkte Kollision der Übertragungen von A und B zu gegenseitiger Verbindung Bei den Nachbarschaften ist das Problem, das der Knoten A seine Information sendet, und der Knoten B speichert dieses. Nun will der Knoten B ein Paket an Knoten A routen. Aber es ist nicht gegeben, das die Verbindung auch auf den Rückweg funktioniert. Um das zu lösen, wurden eine zwei-schritt Kommunikation eingeführt. Zuerst broadcastet der Knoten A ein NachbarschaftsLookup. Jeder Knoten, der das empfängt prüft nun, ob die Empfangsstärke über einer gewissen Schwelle liegt. Wenn ja, antworten die Knoten mit einem NachbarschaftsReply, der an den Sucher gerichtet ist. Als Nutzdaten wird der Beacon-Veacor versandt. Der Anfrager prüft nun nochmal, ob die Antwort stark genug ist. Erst wenn das gegeben ist, wird diese Nachbarschaft aufgebaut. Um nun Auf jedenfall Antworten von Nachbarn zu erhalten, die man schon eingetragen hat, werden an dem NachbarschaftsLookup zusätzlich noch die Adressen aller Nach- 22

31 Kapitel 3. Implementierung 3.3. Anwendung barn eingetragen. Diese Nachbarn antworten auf jeden Fall, auch wenn die Empfangsstärke den Schwellwert nicht übersteigt. zu Paket loss Um Paketloss zu verhindern wurde auch ein ACK Mechanismus implementiert. Jedes gerichtet gesendete Paket (also Pakete mit einem Empfänger) wird in einer Tabelle zwischengespeichert. Der Empfänger eines gerichteten Paketes cached dieses (zur Duplikatevermeidung) und schickt ein ACK zurück. Der Sender empfängt nun dieses ACK und trägt das Paket aus der Liste aus. Sollte nach einiger Zeit kein ACK empfangen worden sein, so wird das Paket erneut gesendet. Das ganze n mal (z.zt. drei mal). 3.3 Anwendung Da viele Konstanten wie z.b. R oder k nicht näher definiert sind, brauchte man eine Möglichkeit, um diese Konstanten nachträglich im laufenden Betrieb zu ändern. Auch brauchte man ein Tool, um das Netz zu Debuggingzwecken zu visualisiseren und zu steuern. Dieses Tool wurde in der Vertiefung Technische Visualisiserung implementiert. Mit dem Tool hat man also eine Möglichkeit das Netz zu testen. Es sind diese Anwendungsmöglichekten implementiert: Anzeigen des Netzes Inizialisation Das Tool soll das Netz anzeigen. Dazu muss jeder Knoten seine Adresse und Nachbarschaftsinformation an das Tool senden. Dazu verbindet man einen beliebeigen Knoten mit einem Linux Rechner. Nun sollte das Device /dev/ttyacm0 erstellt werden. Mit diesem Device kommuniziert die Anwendung mit dem Knoten. 23

32 3.3. Anwendung Kapitel 3. Implementierung Nun muss man dem Netz sagen, das dieser Knoten die zentrale Stelle ist. Dazu gibt es einen Knopf in dem Programm. Wenn man diesen betätigt, wird ein definierter Byte- Strom an den Knoten gesendet. Dieser Knoten hat einen Automaten, der den Byte-Strom entgegennimmt. Sobald alles gesendet wurde, erstellt der Knoten eine Daten Nachticht (Typ D), in dem nur steht, das der Absender zentrale Stelle ist. Diese Nachricht wird im Netz geflutet. Alle Knoten starten nun einen Timer an, der die Daten (Beacon-Vector, Nachbarschaftsinformationen) regelmäßig an die zentrale Stelle schickt Empfang Der zentrale Knoten nimmt nun alle Pakete entgegen und schreibt diese an USB raus. Die Anwendung nimmt die entgegen, und zeigt diese an Anzeige Obwohl das in die Vertiefung Technische Visualisierung gehört, hier der Vollständigkeit halber eine kurze Erläuterung der Anzeige. Alle Knoten werden mit Kreisen dargestellt. Im Normalfall sind diese schwarz. Rote Kreise sind Knoten, die als Beacon agieren. Blaue Kreise sind Knoten, die seit einiger Zeit keine Daten geschickt haben. Die Verbindung zwischen denen zeigt an, das einer eine Verbindung zu dem anderen hat. Die Schrift unter den Kreisen ist rot, wenn die Knoten die LED aktiviert haben. Siehe dazu das Kapitel Identifizieren von Knoten Um sowohl einzelne Knoten zu identifizieren, als auch das Routing vom Zentralknoten zu den einzelnen Knoten zu testen wurde die Identifizierungs LED eingebaut. In der Anwendung kann man einen Knoten auswählen und dann auf Toggle LED klicken. Wenn alles klappt, dann wird die fünfte LED auf diesen Knoten getoggelt, das heisst: Entweder an oder ausgeschaltet. Die LED kann auch mit dem Knoten an oder ausgeschaltet werden. Dazu siehe das Kapitel Knoten, deren LED aktiv ist, werden in der Übersicht mit roter Schrift dargestellt. 24

33 Kapitel 3. Implementierung 3.3. Anwendung Traceroute Um die Route der Nachrichten anzuzeigen wurde ein Traceroute implementiert. Dazu wählt man im Programm zwei Knoten an, und drückt dann den Knopf Traceroute. Jetzt schickt der zentrale Knoten ein Paket an den ersten Knoten. Dieser schickt das Paket an den zweiten Knoten weiter, und setztein Flag. Alle Knoten, die das Paket routen, hängen ihre Adresse an das Paket an. Der Zielknoten schickt dann das Paket zurück an den zentralen Knoten. Das Programm zeigt nun die Route mit roten Strichen an Steuerung des Knoten Der Knoten muss meherere Nutzereingaben entgegen nehmen, hat aber nur zwei Taster. Daher wurde ein Automat eingebaut. Die LEDs drei bis sechs nutzt der Automat. 3: Beschleunigungssensor kalibrieren 4: Beschleunigungssensor aufzeichnen 5: BVR aktivieren 6: Identitäts LED Die Beschleunigungsfunktionen sind noch nicht implementiert. Diese werden für die Positionsberechnung bei der Anzeige gebraucht. Die BVR-LED leuchtet am Anfang rot. Das heisst, auf dem Knoten ist noch kein BVR aktiviert. Erst wenn man dieses aktiviert, wird BVR und die ganze Kommunikation gestartet. Wenn die LED Grün leuchtet, ist BVR aktiv. Das kann nicht mehr zurückgenommen werden. Die Identitäts-LED dient zur Identifizierung des Knotens in der Anzeige. Wenn die LED aktiviert wurde, leuchtet die weis, und in der Anzeige wird die ID des Knotens rot geschrieben. Mit der linke Taste wechselt man die Optionen, und mit der rechten Taste werden diese aktiviert / deaktiviert. 25

34 3.3. Anwendung Kapitel 3. Implementierung 26

35 Kapitel 4 Fazit 4.1 Theorie vs Realität Das Protokoll wurde erfolgreich implementiert. Da das BVR Protokoll aber nicht die physikalischen Gegebenheiten berücksichtigt, musste das Protokoll stark erweitert werden (Kapitel 3.2). Bei dem BVR sind die Ermittlung von Beaconadresse und die Ermittlung der Nachbarn zwei getrennte Vorgänge, ohne Beziehung. So wurde es auch implementiert. Allerdings kann es so sein, das so die Beacon-Pakete über andere Stecken geleitet werden, als Nachbarschaften aufgebaut wurden (Knoten B akzeptiert BeaconPakete von Knoten A, aber eine Nachbarschaft zwischen diesen beiden wurde nicht gebildet). So können nun die zu routende Pakete in ein lokales Minimum fallen, und müssen weitergebroadcastet werden, was zu einer enormen Erhöhung an Kommunikation führt. Überlegenswert wäre es, im ersten Schritt die Nachbarschaften aufzubauen, um dann im zweiten Schritt die Beacon-Pakete mit dieser gebildeten Struktur zu verteilen. 4.2 Nachbarschaften Wie im Kapitel 3.2 beschrieben, haben die von uns verwendeten Sensorknoten eine Richtcharakteristik. Wenn man die Nachbarschaftsinformationen streng nach Paper austauscht, so wird es nicht klappen, da der Rückweg nicht gegeben ist. Daher prüfen wir in unserer Implementation, ob eine gegenseitige Kommunikation gegeben ist. So wird aber viel Potential 27

36 4.3. Bewertung unserer Implementierung Kapitel 4. Fazit vergeben, da das Protokoll nur eine Richtung zum Routen macht. Wenn ein Knoten zufällig in die richtige Richtung zeigt, wieso das nicht nutzen, um eine große (räumliche) Entfernung zu überwinden? Eine Möglichkeit wäre es, wenn der Knoten B (in Bild 3.5) Broadcastet, das er Knoten A empfängt. Wenn per Hopcounter nun dafür gesorgt wird, das diese Information lokal bleibt, ist die Kommunikation zwar immernoch hoch, aber es wird nicht geflutet. 4.3 Bewertung unserer Implementierung Die Implementation dient nur akademischen Zwecken, ist in der Form nicht für ernsthafte Anwendungen zu gebrauchen. Einerseits wird viel Speicher gebraucht, da viele Objekte im Speicher gehalten werden müssen. Das ist einerseits dem BVR geschuldet, da BVR das halten viele Daten verlangt (Beaconadressen und der Hopcounts, Nachbarschaften). Dazu kommt noch implizit notwendiger Speicher. Z.B. müssen Nachrichten, deren Ziel- Beacon-Adresse noch nicht bekannt ist, gechached werden. Zusätzlich verlangt die Netzwerkstabilisierung weiteren Speicherplatz, wie z.b. der Empfangspuffer, um den Empfang doppelter Nachrichten zu verhindern. Andererseits ist die Implementierung an einige Stellen stark verbesserungswürdig, da Sie in der vorliegenden Form sehr viel Rechenleistung brauchen dürften. Zum Beispiel wird beim BVRPaket immer das komplette Array kopiert, wenn ein neues Datum angehängt wird. Dieses ist aber den beschränkten Möglichkeiten der Squawk-VM geschuldet, das viele High-Level Objekte und Konstrukte nicht kann, wie z.b. Listen oder generische Typen. 28

37 Kapitel 5 Literaturverzeichnis [FRC + 05] FONSECA, Rodrigo ; RATNASAMY, Sylvia ; CULLER, David ; SHENKER, Scott ; STOICA, Ion: Beacon vector routing: Scalable point-to-point routing in wireless sensornets. In: In NSDI, 2005 [ope] 29