Scopes in drahtlosen Sensornetzwerken

Technische Universität Darmstadt
Fachbereich Informatik
Scopes in drahtlosen
Sensornetzwerken
Diplomarbeit
von
Daniel Jacobi
Juni 2006
Betreuer: Jan Stean
Eingereicht bei Prof. Alejandro P. Buchmann
FG Datenbanken und Verteilte Systeme
Fachbereich Informatik
Technische Universität Darmstadt
ii
Ehrenwörtliche Erklärung
Hiermit versichere ich, die vorliegende Diplomarbeit ohne Hilfe Dritter und nur mit den
angegebenen Quellen und Hilfsmitteln angefertigt zu haben. Alle Stellen, die aus den
Quellen entnommen wurden, sind als solche kenntlich gemacht worden. Diese Arbeit
hat in gleicher oder ähnlicher Form noch keiner Prüfungsbehörde vorgelegen.
Darmstadt, den 23. Juni 2006
Daniel Jacobi
iv
Danksagung
Ich möchte an dieser Stelle meinem Betreuer Jan Stean für die Unterstützung in jeder
Phase dieser Arbeit danken. Ebenso danke ich Professor Alejandro P. Buchmann und
Dr.-Ing. Mariano Cilia, die diese Arbeit überhaupt erst möglich machten.
Ganz besonders danke ich: Meiner Freundin Sonja. Sie musste sich die letzten Wochen immer wieder mit mir rum plagen, vielen Dank für deine Unterstützung. Und
natürlich meinen Eltern. Ohne sie hätte sich mein Studium wohl etwas komplizierter
gestaltet.
v
vi
Zusammenfassung
Die vorliegende Arbeit beschäftigt sich mit Scopes in drahtlosen Sensornetzwerken. Heutige Sensornetzwerke werden in der Regel für eine spezielle Anwendung entwickelt. Das
Ziel des Ansatzes von Scopes sind Mehrzweck-Sensornetze, die mehrere Anwendungen
gleichzeitig bedienen können. Dazu wird das Sensornetz während der Laufzeit anhand
von bestimmten Eigenschaften in Gruppen (den sog. Scopes ) unterteilt. In den Scopes
können dann Aufgaben unabhängig vom Rest des Sensornetzwerks erledigen werden.
Im Rahmen dieser Arbeit wurde das Verfahren der Scopes für Sensornetzwerke implementiert. Dazu wurde ein an die Bedürfnisse von Scopes angepasster Routing-Algorithmus
speziziert und implementiert. Im Folgenden wurde dann durch Simulationen überprüft,
ob Scopes auf heutigen Sensorknoten einsetztbar sind.
vii
viii
Inhaltsverzeichnis
1 Einleitung
1
1.1
Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2
Ziele
2
1.3
Aufbau der Arbeit
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Grundlagen und Existierende Ansätze
3
5
2.1
Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.2
Drahtlose Sensornetze
5
2.3
2.2.1
Hardware der Sensorknoten
2.2.2
Beispiele und Szenarien für drahtlose Sensornetze
8
10
Routingverfahren
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.3.1
Multicast
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.3.2
Directed Diusion . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.3.2.1
Interests und Gradienten . . . . . . . . . . . . . . . . .
15
2.3.2.2
Datenübertragung
17
2.3.2.3
Reinforcements zum Anlegen und Unterbrechen von Pfa-
2.3.3
2.5
. . . . . . . . . . . . . . . . . . . .
. . . . . . . .
den
2.4
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
Gradient-Based Routing
. . . . . . . . . . . . . . . . . . . . . .
Verfahren zur Gruppierung von Sensorknoten
17
19
. . . . . . . . . . . . . .
19
2.4.1
Lokale Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
2.4.2
Rollen
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
2.4.3
Region Streams . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
2.4.4
Multicast
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
ix
x
INHALTSVERZEICHNIS
3 Architektur für drahtlose Mehrzweck-Sensornetze
23
3.1
Einführung
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
3.2
Scopes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
3.2.1
Spezizierung von Scopes
24
3.2.2
Ausbreitung und Wartung von Scopes
3.2.3
Scopes in Beispielen
3.3
3.4
. . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . .
26
. . . . . . . . . . . . . . . . . . . . . . . .
27
Das SOS Betriebssystem . . . . . . . . . . . . . . . . . . . . . . . . . .
27
3.3.1
Module
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
3.3.2
Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
3.3.3
Speicherverwaltung . . . . . . . . . . . . . . . . . . . . . . . . .
31
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
4 Realisierung
35
4.1
Entwicklungsumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
4.2
Basisimplementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
4.2.1
Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
4.2.2
Probleme
39
4.3
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Erweiterte Implementierung
4.3.1
4.3.2
. . . . . . . . . . . . . . . . . . . . . . . .
39
Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
4.3.1.1
Multihop-Routing
. . . . . . . . . . . . . . . . . . . .
41
4.3.1.2
Die Scope Module
. . . . . . . . . . . . . . . . . . . .
51
. . . . . . . . . . . . . . . . . . . . . . . . . . .
53
Verbesserungen
5 Simulation eines Drahtlosen Sensornetzes
55
5.1
Einführung
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
5.2
Simulationsumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
5.2.1
SOS-native
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
5.2.2
Avrora . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
5.3
Simulationen
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
5.4
Auswertung der gesammelten Daten . . . . . . . . . . . . . . . . . . . .
60
5.4.1
Simulation auf Nachrichtenebene
. . . . . . . . . . . . . . . . .
60
5.4.2
Simulation auf Instruktionsebene
. . . . . . . . . . . . . . . . .
63
5.4.3
Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
INHALTSVERZEICHNIS
xi
6 Zusammenfassung und Ausblick
67
6.1
Umgesetzte Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . .
67
6.2
Oene Probleme und Verbesserungsmöglichkeiten
68
. . . . . . . . . . . .
A Material auf der CD
A.1
71
Inhalt
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
A.1.1
CD Hauptverzeichnis . . . . . . . . . . . . . . . . . . . . . . . .
71
A.1.2
tud/modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
A.1.3
tud/contrib
72
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B Einrichten der Arbeitsumgebung
73
B.1
Einführung
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
B.2
SOS Betriebssystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
B.3
CVS-Baum dieser Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . .
75
C Moduldiagramme und -variablen
77
C.1
scope_tester -Modul . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
C.2
scope_member -Modul
. . . . . . . . . . . . . . . . . . . . . . . . . . .
77
C.3
scope -Modul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
C.4
multihop_routing -Modul . . . . . . . . . . . . . . . . . . . . . . . . . .
79
Literaturverzeichnis
81
xii
INHALTSVERZEICHNIS
Tabellenverzeichnis
2.1
Die Entwicklung der Mica-Motes
. . . . . . . . . . . . . . . . . . . . .
11
4.1
simple_scope Nachrichtenheader
. . . . . . . . . . . . . . . . . . . . .
37
4.2
Multihop-Routing Nachrichtenheader . . . . . . . . . . . . . . . . . . .
44
4.3
Scope-Modul Nachrichtenheader . . . . . . . . . . . . . . . . . . . . . .
51
xiii
xiv
TABELLENVERZEICHNIS
Abbildungsverzeichnis
1.1
Anbringen von Sensorknoten an Mammutbäumen
. . . . . . . . . . . .
2
2.1
Aufbau eines Sensorfelds . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.2
Ein Mica2 Sensorknoten
. . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.3
Vereinfachtes Schema von Directed Diusion . . . . . . . . . . . . . . .
17
3.1
Scope Schichtenmodell
. . . . . . . . . . . . . . . . . . . . . . . . . . .
25
3.2
Modell der Zugrie auf Module in SOS . . . . . . . . . . . . . . . . . .
30
4.1
Übersicht über Module der erweiterten Variante . . . . . . . . . . . . .
40
4.2
Routingbaumaufbau für einen Request
. . . . . . . . . . . . . . . . . .
42
4.3
Datentransfer durch das Sensornetz . . . . . . . . . . . . . . . . . . . .
48
4.4
Löschen eines Scopes/Requests
. . . . . . . . . . . . . . . . . . . . . .
50
5.1
Simuliertes Sensorfeld . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
5.2
Beispiel eines Routingbaums mit zugehörigem Scope . . . . . . . . . . .
59
5.3
Anzahl der versendeten Pakete bei unterschiedlichen Gröÿen des Netzwerks
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
5.4
Simulation von 50 Knoten mit variablem Sendeinterval in scope_tester
62
5.5
Simulation von zwei verschachtelten Scopes
63
5.6
Vergleich versendeter Packete in Avrora und der SOS-Simulation
5.7
. . . . . . . . . . . . . . .
. . .
Benötigte Rechenzeit der Sensorknoten bei unterschiedlichen Gröÿen des
Netzwerks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.8
64
65
Benötigte Energie der Sensorknoten bei unterschiedlichen Gröÿen des
Netzwerks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
xv
66
xvi
ABBILDUNGSVERZEICHNIS
Kapitel 1
Einleitung
1.1 Motivation
Drahtlose Sensornetze bestehen aus vielen kleinen, separaten Computern, den so genannten Sensorknoten. Sie sind in der Regel kleiner als eine Zigarettenschachtel und
verfügen über weniger Prozessorkapazität als beispielsweise ein aktueller Game Boy.
Dafür besitzen sie eine lange Lebensdauer und kommen mit der Leistung von zwei
Mignon Batterien häug bis zu einem Jahr aus. Kommunizieren können diese kleinen
Maschinen über eine Funkschnittstelle miteinander. Das alles macht Sensorknoten sehr
billig und exibel in der Anwendung. Durch ihre beschränkten Ressourcen müssen die
für sie entwickelten Anwendungen allerdings stark spezialisiert und auf Ezienz optimiert werden. Daher werden Sensornetze meist für eine einziges Szenario entwickelt.
Dies geht auf Kosten der Flexibilität und führt zudem zu einer starken Kostensteigerung. Dennoch stellen viele Anwendungsgebiete für Sensornetzwerke einen hohen Anspruch gerade an die Flexibilität. Überwachung ist z.B. eine der Killerapplikationen für
Sensornetze (vgl. [36]): Es können die unterschiedlichsten Daten, über lange Zeiträume
z.B. in den unzugänglichsten Gebieten, überwacht werden. Während der Laufzeit kann
auf neue Entwicklungen reagiert werden oder es können die Überwachungsparameter
geändert werden, wenn andere Sensorwerte interessant werden. Dies ist mit Sensornetzen, die für ein Szenario entworfen worden sind, nicht möglich. Eine Lösung für
dieses (Flexibilitäts-)Problem sind Mehrzweck-Sensornetze, die auf Kosten von etwas
leistungsfähigerer Hardware, die benötigte Flexibilität wieder bereitstellen und durch
das Einführen einer zusätzlichen Abstraktionsschicht die Entwicklung von Anwendungen vereinfachen.
Einen Teil dieser Flexibilität stellt das gezielte Ansprechen einer Gruppe von Knoten
dar. Dies kann mit Hilfe von Scopes sogar während der Laufzeit erreicht werden. Über
frei denierbare Eigenschaften können auf diese Weise Knoten zu Gruppen (sog. Scopes )
zusammengefasst werden. Das Festlegen der Eigenschaften eines Scopes geschieht auf
dem sogenannten Wurzelknoten, von dem die Erstellung des Scopes dann auch ausgeht.
Die Scopes ermöglichen es auf aktuelle Ereignisse oder geänderte Überwachungspara-
1
2
KAPITEL 1.
EINLEITUNG
Abbildung 1.1: Anbringen von Sensorknoten an Mammutbäumen in den USA [11]
meter im Sensornetz exibel zu reagieren.
Da Sensornetze in vielen Fällen (wie in Abbildung 1.1 z.B. an Mamutbäumen) an nur
schwer zugänglichen Orten angebracht sind, sind die angesprochenen Laufzeiten ein
wichtiges Kriterium, da nicht alle paar Tage jemand auf Bäume klettern kann, um Batterien zu wechseln. Genauso wichtig ist auch das Erweitern oder Umprogrammieren des
Sensornetzes im laufenden Betrieb.
1.2 Ziele
Das Ziel dieser Arbeit ist die Demonstration der Realisierbarkeit und Einsetzbarkeit
von Scopes. Probleme bei der Durchführung sollen identiziert und die Möglichkeiten
aktueller Hardware berücksichtigt werden.
Für die Demonstration wird, neben den Scopes, ein entsprechendes Routing benötigt.
Dieses soll den Nachrichten Transport an die Scopes und aus den Scopes heraus an den
Wurzelknoten ermöglichen.
1.3.
AUFBAU DER ARBEIT
3
1.3 Aufbau der Arbeit
In Kapitel 2 werden die Grundlagen dieser Arbeit erörtert. Zuerst soll dargestellt werden, was man allgemein unter einem drahtlosen Sensornetzwerk versteht und wie sich ein
Sensorknoten zusammensetzt. Anschlieÿend werden einige Einsatzszenarien vorgestellt.
Danach folgen die verwendeten Algorithmen und Mechanismen. Von grundlegendem
wie Multicast zu Directed Diusion und Gradient-based-routing, sowie eine Übersicht
über verwandte Ansätze zu Scopes.
In Kapitel 3 wird die Architektur der Scopes von theoretischer Seite her beleuchtet und
das SOS Betriebssystem für die Sensorknoten besprochen.
In Kapitel 4 kommen zwei Implementierungen der Scopes in Sensornetzwerken im Detail zur Sprache. In einem ersten Schritt wird eine Basisvariante vorgestellt, die zum
Transport der Daten nur Flooding verwendet, und in einem zweiten Schritt wird die
erweiterte Version vorgestellt, deren Scope-Implementierung modularisiert ist und um
ein verbessertes Routing ergänzt wurde. Kapitel 5 widmet sich schlieÿlich den durchgeführten Simulationen der erweiterten Scope-Implementierung.
Das Abschlusskapitel, Kapitel 6, fasst noch einmal alle Ergebnisse zusammen und gibt
zudem einen Ausblick auf zukünftige Möglichkeiten von Scopes in Sensornetzwerken.
4
KAPITEL 1.
EINLEITUNG
Kapitel 2
Grundlagen und Existierende Ansätze
2.1 Einleitung
Was ist ein Sensornetzwerk? Was ein Sensorknoten? Und wie werden sie eingesetzt,...?
Das sind alles Fragen, die zu klären sind, bevor sich Details dieser Arbeit gewidmet
werden kann. Daher werden in diesem Kapitel alle Grundlagen und Verfahren vorgestellt, die für das Verständnis dieser Arbeit wichtig sind.
Nach einem Überblick über Sensornetze nach [29], wie sie aufgebaut sind (nach [11]
und [34] Kapitel 4) und ihre Einsatzmöglichkeiten, werden in Abschnitt 2.3 die grundlegenden Verfahren für das in dieser Arbeit entwickelte Routing erläutert. Es folgt in
Abschnitt 2.4 eine kurze Übersicht über bestehende Verfahren zum Gruppieren von
Sensorknoten.
2.2 Drahtlose Sensornetze
Erste Ansätze für Sensornetzwerke nden sich schon zur Zeit des Kalten Krieges. Damals entstand ein System zum aufspüren von U-Booten, das vom US-Militär entwickelt
wurde (u. a. das Sound Surveillance System, SOSUS ) [19]). Um 1980 wurde das Thema von der Defense Adanced Research Projects Agency (DARPA) in dem Programm
Distributed Sensor Networks (DSN) wieder aufgenommen. In seiner momentanen Ausprägung wurden die Sensornetze von Mitarbeitern der Universität von Kalifornien in
Berkeley (UCB) publik gemacht. Dort entwickelte Sensorkonten werden später in dieser
Arbeit (siehe Abschnitt 2.2.1) im Detail vorgestellt.
Die Weiterentwicklung der Mikroelektronik in den Bereichen Chipdesign und Miniaturisierung, in den letzten Jahren, hat es ermöglicht die grundlegenden Bestandteile eines Computers auf die Gröÿe eines Zigarettenpäckchens oder einer Streichholzschachtel
5
6
KAPITEL 2.
Internet, Satellitenverbindung, ...
GRUNDLAGEN UND EXISTIERENDE ANSÄTZE
Senke
B
A
C
D
Management
Knoten
Benutzer
Sensorfeld
Sensorknoten
Abbildung 2.1: Aufbau eines Sensorfelds
zu komprimieren. Diese Kleinstcomputer bestehen aus einem Prozessor, Schaltungen
zur Kommunikation mit ihrer Umgebung, Sensoren und einer unabhängigen Stromversorgung. Solche Sensorknoten können in drahtlosen Sensornetzen (Wireless sensor
networks, WSN) zu hunderten auf groÿer Fläche verteilt werden, um diese zu überwachen. Dies geschieht ohne andere Prozesse zu beeinussen. In einem Verband von nur
wenigen Knoten können auf diese Weise unbemerkt Grundstücke o.ä. Überwacht und
das Betreten von Unbefugten sofort gemeldet werden.
Ein Sensornetz besteht nach [3] aus dem Sensorfeld (Abbildung 2.1), das überwacht
wird und in dem die Sensorknoten platziert werden, und einer Verbindung nach auÿen.
1
Jeder Sensorknoten kann seine gesammelten Daten zurück an die Senke
schicken. Die
Daten werden meist über eine infrastrukturlose, multihop Architektur geroutet. Die
Verbindung nach auÿen kann eine kontinuierliche Verbindung z.B. mit dem Internet
sein oder ein Mitarbeiter ruft Daten in bestimmten Intervallen vor Ort ab. In diesem
Fall muss die Senke oder das Sensornetz die Daten entsprechend zwischenspeichern.
Erfassen, verarbeiten und weiterleiten von Sensordaten sind grundlegende Funktionen
eines Sensorknotens. Das Sensornetz ist, wegen der Interaktion der vielen einzelnen
1
Damit wird in der Regel der anfragende Knoten bezeichnet.
2.2.
DRAHTLOSE SENSORNETZE
7
Sensorknoten und ihrem dynamischen Verhalten aufgrund von Umwelteinüssen oder
anderen Problemen, um einiges komplexer. Meist kann eine Eigenschaft eines Phänomens nur durch die Kooperation vieler Sensorknoten überwacht werden. Bewegt sich
zum Beispiel ein Fahrzeug durch ein überwachtes Gebiet, kann im Zusammenspiel mehrerer Sensorknoten die Richtung und Geschwindigkeit des Fahrzeugs erfasst werden.
Das Design eines Sensornetzes wird, nach [3], durch viele Faktoren beeinusst. Sensorknoten können aufgrund von zu geringer Energie, Umwelteinüssen oder Beschädigungen ausfallen. Ebenso besteht die Möglichkeit, dass neue Knoten hinzukommen oder
aktive Knoten bewegt werden. Auf diese Weise können zum Beispiel auch ausgefallenen
Knoten ersetzt werden. Dieses dynamische Verhalten der Knoten sollte der Funktion
des Sensornetzes nicht schaden: Fehlertoleranz ist für ein robustes Netz unerlässlich.
In vielen Szenarien werden mehrere hundert oder tausend Knoten eingesetzt, um die
gestellten Aufgaben bewältigen zu können. Die verwendeten Algorithmen müssen also zum einen mit der schieren Menge der Knoten zurechtkommen und zum anderen
müssen sie bei den unterschiedlichsten Dichten und Platzierungen ein ezientes Netz
bilden können. Je nach Gröÿe des Gebiets und Menge der Knoten sind die Kosten für
ein solches Netz ein zusätzlich zu berücksichtigender Faktor. In einem solchen MultihopSensornetzwerk sind die einzelnen Knoten durch ein drahtloses Medium verbunden. In
den meisten Fällen werden Funkverbindungen verwendet, aber es nden auch alternative Verbindungsarten per Infrarot oder Laser
2 3
Verwendung (vergleiche [11]). Da die
Knoten in der Regel von begrenzten Energiequellen, wie Batterien o. ä., abhängig sind,
muss dieser Faktor besondere Berücksichtigung nden. So muss sowohl die Hardware
(Sensoren, Prozessoren, Sender/Empfänger), wie auch die Software (Betriebssystem,
Protokolle) möglichst Energieezient arbeiten.
Die in Sensornetzen verarbeiteten Daten beruhen auf physikalischen Ereignissen und so
ist die Signalverarbeitung ein wichtiger Teil, der zur Verringerung des Datenvolumens
beiträgt. Statt die Sensorrohdaten über das Netz zu verschicken, werden die Daten vorverarbeitet und die für die jeweilige Anwendung interessanten Werte herausgeltert.
Daten von verschiedenen Quellen, die sich im Laufe des Transfers auf einem Knoten
treen, können bei starker Ähnlichkeit zusammengefasst oder gesammelt werden, bevor
sie weiter gesendet werden. So wird aus einer groÿen Menge von Rohdaten mit relativ
wenig Informationsgehalt eine kleine Menge Daten mit sehr hohem Informationsgehalt
generiert. Entsprechend dieser Datenkompression, sollte die Informationsverarbeitung
idealerweise direkt im Sensornetz geschehen. Diese Kompressionsverfahren sind oft auf
die spezielle Anwendung zugeschnitten.
In traditionellen verteilten Systemen werden die einzelnen Knoten mit einem Namen
oder einer festen Adresse angesprochen. In Sensornetzwerken hingegen ist die Adressierung des einzelnen Knotens nicht entscheidend. Es besteht die Möglichkeit den einzelnen
Sensorknoten keine direkte Identizierung zuzuordnen, wie etwa eine Adresse; Solche
2 sowohl Infrarot, wie auch das Laserverfahren benötigen Sichtkontakt zur Kommunikation zwischen
Sender und Empfänger.
3 http://www-bsac.eecs.berkeley.edu/archive/users/warneke-brett/SmartDust/
8
KAPITEL 2.
GRUNDLAGEN UND EXISTIERENDE ANSÄTZE
nicht benannten Knoten werden über ihre physikalische Position oder den Typ und den
Inhalt ihrer Daten identiziert. Ausgefallene Knoten können so durch einen anderen
Knoten in unmittelbarer Nähe mit ähnlichen Sensoren problemlos ersetzt werden.
Ein weiterer Unterschied zu bekannten verteilten Systemen betreen die Eigenschaften der ausgetauschten Daten. Da diese von umliegenden Knoten sehr ähnlich sind,
können sie für Kompression (Eliminierung von Redundanz), Robustheit (benachbarte
Knoten müssen ähnliche Daten liefern) und Sicherheitsmechanismen (Erkennung von
eingeschleusten Missinformationen) genutzt werden. Das Verlieren von Paketen kann in
den meisten Fällen toleriert werden und durch eine spätere Sensorabfrage kompensiert
werden. So sind klassische Kommunikationsprotokolle wie TCP/IP mit Ende-zu-EndeGarantien beim Datentransfer oft nicht nötig oder wegen des erhöhten Nachrichtenaufkommens sogar unerwünscht und ungeeignet.
Um ein Sensornetzwerk betreiben zu können, sind mehrere Softwarekomponenten erforderlich: Ein Betriebssystem, Routingprotokolle, Treiber für Sensoren und die eigentliche
Anwendung.
Es gibt mehrere Betriebssysteme für Sensorknoten. Das bekannteste und weitverbrei-
4
teste ist TinyOS . SOS
5
ist eine Neuentwicklung des Networked and Embedded Systems
Lab (NSCL) an der UCLA. Betriebssysteme für Sensorknoten unterscheiden sich eindeutig von gängigen Betriebssystemen. Sie müssen mit den eingeschränkten Ressourcen
auskommen und die speziellen Anforderungen der Sensornetze erfüllen. Neben einer
einheitlichen API stehen bei SOS noch grundlegende Mechanissmen zur dynamischen
Neuprogrammierung von ausgesetzten Knoten und zur gleichzeitigen Nutzung des Sensornetzes von mehreren Anwendungen im Vordergrund.
2.2.1 Hardware der Sensorknoten
Inzwischen gibt es mehrere Sensorknotendesigns. Zum Beispiel die Mica Motes
7
UCB, XYZ
8
6
der
der Universität Yale oder Tmote von Moteiv . Die Motes der UCB sind die
9
bekanntesten und bilden die Basis für kommerzielle Produkte von Xbow
und Intel
10
.
Der, für diese Diplomarbeit, angefertigte Sourcecode ist für Mica2 Motes entwickelt
worden; Daher wird die Mica2 Plattform als typisches Beispiel für einen Sensorknoten
im Folgenden vorgestellt.
Ein Mica2 Sensorknoten (siehe Abbildung 2.2) setzt sich, wie die meisten Sensorkno-
http://webs.cs.berkeley.edu/tos
http://nesl.ee.ucla.edu/projects/SOS/
6 http://webs.cs.berkeley.edu
7 http://www.eng.yale.edu/enalab/XYZ/
8 http://www.moteiv.com/
9 http://www.xbow.com/
10 http://www.intel.com/research/exploratory/motes.htm
4
5
2.2.
DRAHTLOSE SENSORNETZE
9
Abbildung 2.2: Ein Mica2 Sensorknoten
ten, aus verschiedenen Modulen zusammen. Das Basismodul mit Rechen- und Kommunikationseinheit beherbergt also Mikrocontroller, Funkkomponenten, LEDs und einen
Erweiterungssteckverbinder für Sensormodule oder ähnliches.
In der Mica-Serie wird nach dem Datenblatt [9] als Prozessor der Atmel Atmega128
Mikrocontroller verwendet. Er leistet 8 MIPS und ist mit 128 kB Programmspeicher
und 4 kB RAM ausgestattet. Zusätzlich bietet ein Micaknoten 512 kB nicht üchtigen Speicher. Mit dieser Leistung ist an gröÿere Berechnungen, wie sie etwa für im
PC-Bereich gängige Algorithmen der starken Kryptograe benötigt würden, nicht zu
denken. Dementsprechend ist auch der Energieverbrauch recht niedrig. Bei Volllast von
Prozessor (ca. 8 mAh) und Dauernutzung der Funkkomponenten (ca. 8-30 mAh) halten
die zwei Standard Mignonzellen (je ca. 1-2,5 Ah, vgl. [5]), die direkt am Basismodul
angebracht sind, mindestens 52h. Da ein Sensorknoten, abhängig von der jeweiligen
Anwendung, den gröÿten Teil seiner Zeit im Sleep-Modus verbringt und mit energieefzienten Schaltungen darauf lauscht, ob ein Paket für ihn ankommt, liegt der Energieverbrauch dann im
µA
Bereich. Damit wird eine Lebensdauer von bis zu einem Jahr
möglich. Mit dem 51-Pin Erweiterungssteckverbinder lässt sich eine groÿe Anzahl von
externen Modulen anschlieÿen, die über analoge Eingänge, digitale E/A, I2C, SPI und
UART mit dem Mica Basismodul kommunizieren können. Die Reichweite der Funkkomponenten ist begrenzt. Von wenigen Metern in Gebäuden, bis zu 30m im Freien, es
ist alles eine Frage der Energie und der Umgebungsbedingungen. Die einzigen für den
Menschen sichtbaren Signale von einem Mica Basismodul sind seine drei LEDs. [9]
Sensormodule, die an die Sensorknoten angeschlossen werden können, gibt es in einer
groÿen Vielfalt: Die Spanne reicht von einfachen Sensoren, die die Luftfeuchtigkeit oder
die Lichtintensität messen, bis hin zu GPS-Empfängern oder RFID Lesegeräten.
Neben den Mica Sensorknoten gibt es auch neuere Entwicklungen, wie den Telos Sen-
10
KAPITEL 2.
sorknoten oder Smart Dust
11
GRUNDLAGEN UND EXISTIERENDE ANSÄTZE
. Beide wurden an der UC Berkeley entwickelt. Telos ist
der Nachfolger der Mica-Serie mit neuem Mikrocontroller und verbessertem Funkmodul. Smart Dust ist ein sehr kleiner Sensorknoten, er ist kleiner als ein Fingernagel und
besitzt kein Funkmodul, da dieses zu groÿ wäre und kommuniziert so mit einem Laser
basierten System.
Tabelle 2.1 gibt nochmal einen Überblick über die Mica-Serie und ihre Entwicklung
über die letzten Jahre.
2.2.2 Beispiele und Szenarien für drahtlose Sensornetze
Die eben vorgestellten Sensorknoten sind nicht auf reine Laborumgebungen beschränkt,
sondern werden produktiv in vielen Projekten rund um die Welt eingesetzt. In den
meisten Szenarien geht es um das, was ein Sensornetzwerk besonders gut kann: Werte
messen, verarbeiten und zugänglich machen. Zum Beispiel gibt es in den USA Netze, die
eine Produktionshalle samt aller Maschinen bei Intel
12
oder die Umweltbedingungen in
einem Wald aus Mamutbäumen (vgl. [11]) überwachen. Hierzulande sind genauso Anwendungen für Sensornetzwerke vorhanden, wie etwa das überwachen einer Kuhherde
(vgl. [11]) oder das Messen der Umweltbedingungen in einem Gewächshaus [30]. Ein
weiteres Szenario für Sensornetze ist das sogenannte Containerhafen-Szenario [11]. In
ihm werden die Vorteile von Sensornetzwerken für groÿe Verteilzentren, wie etwa Hochseehäfen, aufgezeigt.
Auf die Möglichkeiten von Scopes in den folgenden Szenarien wird dann in Abschnitt
3.2.3 noch einmal genauer eingegangen.
Der Einsatz eines Sensornetzwerks in einem Gewächshaus, läuft seit Ende 2004 in einer
Anlage in der Nähe von Duisburg. Durchgeführt wird dieses Projekt vom FraunhoferinstitutIMS
13
und der GREATech GmbH
14
in Zusammenarbeit mit der Landwirtschaftskam-
mer.
Was und wie viel eine Panze braucht um schnellst- oder bestmöglich zu wachsen ist
schon lange bekannt. Die Umgebung den entsprechenden Panzen anzupassen aber ist
schon etwas komplizierter. Man benötigt dazu nicht nur die Geräte, mit denen sich
Temperatur, Lichteinfall oder Luftfeuchte in einem Gewächshaus regeln lassen, sondern auch geeignete Messinstrumente, um den Istzustand zu erfassen. Bisher war es
nur möglich punktuell Werte in einem Gewächshaus zu messen. Mit dem installierten
Sensornetzwerk lassen sich diese Werte jetzt nicht nur ächendeckend, sondern auch
an den Panzen direkt messen. Damit kann eine optimale Versorgung der Panzen
gewährleistet und so der Ertrag an Panzen erhöht werden. Zudem kann der Energieverbrauch für die Gewächshäuser reduziert werden, da zum Beispiel nur soviel geheizt
werden muss, wie es von den Panzen benötigt wird. Bei einem Anteil von 90 Prozent
http://www-bsac.eecs.berkeley.edu/archive/users/warneke-brett/SmartDust/
http://www.intel.com/research/exploratory/wireless_sensors.htm#vibration
13 http://www.ims.fraunhofer.de/
14 http://www.greatech.de
11
12
Microcontroller
Type
Program memory (KB)
RAM (KB)
Active Power (mW)
Sleep Power (µW)
Wakeup Time (µs)
Nonvolatile storage
Chip
Connection type
Size (KB)
Communication
Radio
Data rate (kbps)
Modulation type
Receive Power (mW)
Transmit Power at 0dBm (mW)
Power Consumption
Minimum Operation (V)
Total Active Power (mW)
Programming and Sensor Interface
Expansion
Communication
Integrated Sensors
Mote Type
Year
René
1999
Tabelle 2.1: Die Entwicklung der Mica-Motes [35]
24
2.7
27
TR1000
40
ASK
12
36
Mica
2001
2.7
44
89
33
75
180
Mica 2
2002
CC1000
38.4
FSK
29
42
AT45DB041B
SPI
512
8
75
180
ATmega128
128
4
Mica2Dot
2002
10-pin
USB
yes
1.8
41
CC2420
250
O-QPSK
38
35
ST M24M01S
I2 C
128
TI MSP430
60
2
3
6
6
Telos
2004
DRAHTLOSE SENSORNETZE
1
Table 1: The family of motes preceeding Telos and their capabilities
51-pin 51-pin
none
51-pin
19-pin
51-pin
IEEE 1284 (programming) and RS232 (requires additional hardware)
no
no
no
yes
no
no
no
none
2.7
TR1000
10
OOK
9
36
Dot
2000
ATmega163
16
1
15
45
36
René 2
2000
24LC256
I2 C
32
AT90LS8535
8
0.5
15
45
1000
WeC
1998
2.2.
11
12
KAPITEL 2.
GRUNDLAGEN UND EXISTIERENDE ANSÄTZE
(vgl. [30]) des Energieverbrauchs einer Gärtnerei kann hier eine deutliche Einsparung
erreicht werden. Zudem ist geplant, dass das Sensornetz in Zukunft die Regelung im
Gewächshaus vornimmt.
Mit Scopes können die Sensorknoten, die für die gleiche Panzenart zuständig sind, in
einer Gruppe (dem Scope) zusammengefasst werden und so die für diese Art spezischen Eckdaten erfassen und eventuelle Grenzwerte überwachen. Ist das Sensornetzwerk
in der Lage die Regelung im Gewächshaus vorzunehmen, so kann es direkt auf Veränderungen reagieren, in dem bei erhöhter Sonneneinstrahlung zum Beispiel für mehr
Kühlung gesorgt wird.
Im Containerhafen-Szenario werden die Container eines groÿen Frachters vernetzt. Diese Schie beherbergen heutzutage einige tausend Container. An jedem dieser Container
wird ein Sensorknoten angebracht, genauso an jeder Palette, die innerhalb eines Containers untergebracht ist. Dabei bilden alle Knoten innerhalb eines Containers ein Sensornetzwerk und alle Knoten, die an einem Container angebracht sind bilden ebenso ein
Sensornetz. Das Sensornetzwerk innerhalb der Container kann dann zum Beispiel die
per RFID ermittelte Ladung an das Container-Sensornetz melden oder andere Werte,
wie etwa Temperatur, Luftfeuchtigkeit oder ob der Container während des Transports
geönet wurde, weiterleiten.
Im Hafen kann so vom Zoll über einen dieser Containerknoten das gesamte Netz angesprochen werden und Anfragen an sämtliche Knoten auf dem Schi gestellt werden.
Nach einer Anfrage bauen die Sensorknoten von einem Knoten zum nächsten usw. einen
15
Routingbaum auf und beantworten die Anfrage. Über eine Anwendung wie TinyDB
der UC Berkeley können die Daten der einzelnen Knoten im Containernetzwerk wie
in einer Datenbank erfasst und abgerufen werden. Darüber können dann Ladelisten,
Herkunfts- und Zielorte bestimmt oder der Zeitpunkt der letzten Önung der Container abgefragt werden.
Scopes können hier den einzelnen Speditionen schnell und einfach einen Überblick über
die eigenen Container geben. So könnte ein Scope alle Container einer Spedition zusammenfassen. Dabei ist durch den Scope gewährleistet, dass nur die eigenen Container
antworten. Damit diese Gruppierung nicht von Konkurenten miÿbraucht werden kann,
muss natürlich eine sichere Verbindung und eine sicherer Verwaltung der Scopes gewährleistet sein.
2.3 Routingverfahren
Damit eine eziente und zuverlässige Kommunikation zwischen den einzelnen Knoten
gewährleistet ist werden spezialisierte Routingverfahren verwendet. Die Kommunikation zwischen einzelnen Knoten und einer Gruppe von Knoten, wird allgemein unter dem
Begri Multicast zusammengefasst. In Anschnitt 2.3.1 wird Multicast im Kontext von
15
http://telegraph.cs.berkeley.edu/tinydb/
2.3.
ROUTINGVERFAHREN
13
drahtlosen Sensornetzen nach [7] vorgestellt.
Wie man [2] entnehmen kann, existieren viele Routingverfahren für drahtlose Sensornetzwerke. Eines dieser Verfahren ist das in Abschnitt 2.3.2 vorgestellte Directed Dif-
fusion. Es unterstützt das gruppierte Ansprechen von Knoten und ist so für den Einsatz mit Scopes sehr gut geeignet. Allerdings unterstützt Directed Diusion nur die
Kommunikation aus der Gruppe zum Wurzelknoten und ein recht komplexes Verfahren
zum Verstärken von Verbindungen wird genutzt. Um die, für den Einsatz von Directed Diusion mit Scopes, benötigten Änderungen und Erweiterungen zu vereinfachen,
wurde auf ein leicht abgewandeltes Directed Diusion zurückgegrien. Es nennt sich
Gradient-based Routing und wurde in [37] beschrieben (eine kurze Zusammenfassung
ist in Abschnitt 2.3.3 vorhanden).
2.3.1 Multicast
Multicasting is the transmission of datagrams to a group of hosts identied by a single
destination address and hence is intended for group-oriented computing [7]
Für konventionelle drahtbasierte Netzwerke gibt es eine Reihe etablierter Routingprotokolle, die ein robustes und ezientes Multicast ermöglichen. Der gröÿte Teil der drahtlosen Anwendungen sind in Gebieten angesiedelt, für die ein schnelles und dynamisches
Rekongurieren nötig ist und eine verdrahtete Infrastruktur nicht zur Verfügung steht.
Zum Beispiel in Katastrophen-, Bergungsgebieten oder auch Konferenzen.
Das Übertragen von herkömmlichen Multicastprotokollen auf eine drahtlose Umgebung
scheint wenig erfolgversprechend, da diese Protokolle mit der Beweglichkeit der Knoten
und den daraus resultierenden häugen Topologiewechseln nur schwer klar kommen.
Zusätzlich würde die Mobilität der einzelnen Knoten den Verwaltungsaufwand drastisch erhöhen.
Die meisten mobilen Geräte werden mit Batterien betrieben und so müssen Routingprotokolle die Menge an Kontrollinformationen möglichst klein halten. Im drahtlosen
Medium ist es existenziell, überüssiges Versenden von Nachrichten oder allgemeiner
den Energiebedarf, möglichst weit zu senken. Multicast kann die Ezienz einer Funkverbindung verbessern. Wenn mehrere Kopien einer Nachricht versendet werden oder mehrere Nachbarn in Reichweite Daten erhalten sollen, indem die grundlegende BroadcastEigenschaft des Mediums ausgenutzt wird.
Die gröÿten Herausforderungen von drahtlosem mobilem Multicast nach [18] sind die
Verwaltung der Routingstrukturen und die Zuverlässigkeit. Die Verwaltung ist nicht
nur wegen der dynamischen Gruppenzugehörigkeit, sondern auch wegen der Mobilität
der Knoten eine der gröÿten Probleme. Beim Bewegen der Knoten können Loops bei
der Rekonguration der Routingstrukturen entstehen oder Pakete verloren gehen bzw.
Mehrfach empfangen werden. Daher ist das nden und aufrechterhalten einer optimalen
Routingstruktur eine schwierige Sache und das Rekongurationsschema sollte möglichst
14
KAPITEL 2.
GRUNDLAGEN UND EXISTIERENDE ANSÄTZE
einfach gehalten werden, um den Overhead zu verringern.
Eine Variante Multicast in Funknetzen zu ermöglichen, ist Flooding. Dabei werden
sämtliche Pakete durch das gesamte Netzwerk gesendet. Jeder Knoten, der ein Paket
empfängt sendet es per Broadcast einmal an seine umliegenden Nachbarn. In hoch mobilen Netzen ist Flooding ein gangbarer Weg für zuverlässiges Multicast. Der Nachteil
an Flooding, ist der hohe Overhead: eine hohe Zahl an Paketduplikaten und -kollisionen.
Basierend auf der Art der Routingstrukturen werden Multicastprotokolle in vier Kategorien eingeteilt:
Baum-basiertes Routing
dies ist ein stark verbreitetes und etabliertes Konzept. Die
meisten Multicastprotokolle in herkömmlichen Netzwerken basieren auf diesem
Ansatz. Für drahtlose Netze beinhalten die Meisten Protokolle spezielle Verfahren
zum aunden ausgefallener Knoten oder zur Bestimmung der eigenen Position
und der, der Nachbarknoten.
Mesh-basiertes Routing
Im Unterschied zu den Baum-basiertem Multicast, kann
es bei Mesh-basiertem mehrere Pfade zwischen einem Quelle/Senke-Paar geben.
Baum-basierte Ansätze sind nur schlecht gerüstet für häuge Topologiewechsel,
im Gegensatz dazu ist es bei Mesh-basierten Protokollen wahrscheinlich, dass eine
unterbrochene Verbindung nicht gleich zu einer Rekongurierung führt. Meshes
übertreen Baum-basierte Ansätze, wegen der vorhandenen alternativen Pfade.
Diese erlauben das Zustellen eines Datagramms selbst bei Ausfall einer Verbindung.
Stateless-Multicast
Baum- und Mesh-basiertes Multicast erzeugt Overhead für die
Verwaltung der Baum- oder Mesh-Strukturen. Sich bewegende Knoten erhöhen
diesen Overhead zusätzlich. Um solche Eekte zu minimieren werden bei Stateless Multicast explizit Zieladressen im Paketheader angegeben. Das zielt auf so
genanntes smallgroup Multicast ab und setzt voraus, dass das benutzte Routingprotokoll die Daten entsprechend der Headerinformationen zustellt.
Hybride Ansätze
Baum-basierte Ansätze haben eine hohe Eektivität beim Weiter-
leiten von Daten, aber sind wenig Robust. Mesh-basiertes Multicast ist robuster,
hat aber einen höheren Overhead beim Weiterleiten und eine höhere Netzwerklast. Hybride Ansätze versuchen die Vorzüge von Baum- und Mesh-basiertem
Multicast zu vereinen.
2.3.2 Directed Diusion
In einem Sensornetzwerk mit vielen zufällig verteilten Knoten ist es nicht praktikabel
jeden Konten einzeln direkt anzusprechen. So ist es schwierig mit einer bestimmte Region des Netzwerks zu kommunizieren. Eine einfache Variante wäre das Versenden der
2.3.
ROUTINGVERFAHREN
type = wheeled
location =
vehicle
[234:12]
timestamp = 0 1 : 4 3 : 0 0
15
// Typ
des
Fahrzeugs
//
Position
des
//
Zeitstempel
Knotens
Listing 2.1: Beispiel für Attribut/Werte-Paare in Directed Diusion
Daten über den Flooding-Algorithmus. Dies führt zu einem groÿen Overhead an Nachrichten im Netzwerk. Um das Routing ezienter zu gestalten und den Energieverbrauch
zu reduzieren wurden Algorithmen entwickelt, die eine Gruppe von Sensorknoten ansprechen und die Daten auf ihrem Weg durch das Sensornetz aggregieren können.
In einem datenzentrierten Routingalgorithmus wie Directed Diusion [15, 23, 24] sendet
die Senke Anfragen an das Sensornetz und wählt so Sensorknoten des Netzwerks aus.
Nachdem die Sensoren der entsprechenden Knoten ihre Werte ermittelt haben werden
diese an die Senke zurück gesendet.
Directed Diusion besteht aus mehreren Elementen, wie: Interests, Daten, Gradienten
und Reinforcements. Ein Interest ist eine Anfrage für Daten, die vom Benutzer benötigt
werden. Er besteht in Directed Diusion aus Attribut/Werte-Paaren (für ein Beispiel
siehe Listing 2.1), die die benötigten Daten beschreiben. Es können aber auch andere
Bezeichnungsschemata verwendet werden, wie zum Beispiel intentional names (vergleiche [1]). Die Beschreibung der Daten kann eine Ortsbestimmung, Frequenz, Zeitspanne
oder anderes enthalten. Daten in einem Sensornetzwerk sind typischerweise gesammelte
und verarbeitete Informationen über ein physisches Phänomen. Eine kurze Beschreibung eines Phänomens wird Event genannt. In Directed Diusion werden benannte
Daten angefragt, das wird durch das oben beschriebene Benennungsschema erreicht.
Eine Anfrage für Sensordaten wird also per Interest durch das Netzwerk verschickt.
Während des Transfers des Interests werden im Sensornetzwerk Gradienten angelegt,
die die erfassten Events zurück an den Ursprung des Interests und damit den anfragenden Knoten leiten. Die Richtung der Gradienten wird auf den Knoten von dem der
Interest empfangen wurde gelegt. Damit können die Events zum Initiator des Interest
über mehrere Gradient-Pfade zurück ieÿen. Im Sensornetzwerk werden dann ein oder
mehrere dieser Pfade per Reinforcements verstärkt, je nach Qualität und Geschwindigkeit der Verbindung. Dieser Ablauf wird für eine bestimmte Anfrage unter dem Begri
Task zusammengefasst.
Im Folgenden wird Directed Diusion noch etwas detaillierter nach [24] beschrieben, da
dieser Algorithmus die Basis des im Folgenden verwendeten Multihop-Routing bildet.
2.3.2.1
Interests und Gradienten
Interests können an einem beliebigen Punkt des Sensornetzwerks eingebracht werden.
Der Knoten, der die Interests in das Netz aussendet wird Senke genannt. Knoten, die
16
KAPITEL 2.
GRUNDLAGEN UND EXISTIERENDE ANSÄTZE
die Angefragten Informationen liefern können, werden Quelle genannt.
Wie werden Interests durch das Sensornetzwerk verbreitet: Für jeden aktiven Task
broadcastet die Senke periodisch einen Interest an jeden Nachbarn. Durch den ersten
Interest werden die Knoten veranlasst zu prüfen, ob sie einen gesuchten Event erfassen
(siehe Abbildung 2.3a); Dafür wird anfangs nur eine geringe Datenrate in dem Interest angegeben. Die Interests werden periodisch von der Senke mit einem aktualisierten
Zeitstempel erneuert. Dies ist nötig, da Interests nicht zuverlässig durch das Sensornetzwerk transportiert werden. Die Erneuerungsrate ist ein Designparameter des Protokolls
und spiegelt den Kompromiss zwischen Overhead an neu gesendeten Interests, um die
Robustheit zu erhöhen, und dem Verlust von Nachrichten wieder.
Jeder Knoten verwaltet seinen eigenen Interestcache. Jeder Eintrag entspricht einem,
aufgrund seiner Attribute, eindeutigen Interest. Angesichts dessen kann man also auch
Interests aggregieren, wenn die Attribute übereinstimmen. Zum Beispiel, wenn die gleichen Daten in einer Unterregion eines bestehenden Interests Angefragt werden (alles
was noch anzupassen ist, ist die Datenrate). Die Cacheeinträge enthalten keine Informationen über den Pfad zur Senke oder die Senke an sich, sondern nur über die direkt
vorhergehende Etappe. So hat jeder Eintrag mehrerer Gradienten-Felder und eine Laufzeit aus der die ungefähre Lebensdauer des Interests berechnet wird. Verstreicht die
Lebensdauer eines Gradienten wird er gelöscht. Bei mehreren Quellen wird der Eintrag
erst nach Ablauf der Lebensdauer aller Gradienten gelöscht.
Wenn ein Knoten einen Interest empfängt wird zuerst geprüft, ob bereits ein Cacheeintrag existiert. Falls nicht wird ein neuer Eintrag angelegt, die Informationen aus dem
Interest werden in ihm gespeichert und die zugehörigen Gradienten erzeugt. Nachbarn
müssen also eindeutig identizierbar sein, um Gradienten für sie anlegen zu können.
Die Identizierung kann zum Beispiel per 802.11 MAC Adressen [22] oder Bluetooth
Cluster Adressen [40] erfolgen. Existiert ein Cacheeintrag wird der zugehörige Gradient erzeugt oder aktualisiert. Zuletzt wird der Zeitstempel des Eintrags erneuert. Nach
dem Bearbeiten des Interests kann er an eine Untermenge der Nachbarn des Sensorknotens weiterversendet werden. Das Weiterversenden kann unterdrückt werden, wenn
ein passender Interest erst vor kurzem weitergeleitet worden ist. Das Weiterleiten von
Interests kann per Broadcast, senden zu einem speziellen Nachbarn, geographischem
Routing oder anderen Verfahren erfolgen.
Beim Anlegen der Gradienten wird von jedem Nachbarpärchen ein Gradient zum jeweils
anderen angelegt (siehe Abbildung 2.3b). Wenn ein Knoten einen Interest empfangen
hat kann er nicht erkennen, ob er eine Antwort auf einen vorhergehenden Interest empfangen hat, oder aber von einer Senke auf der anderen Seite dieses Nachbarn stammt. Im
ungünstigsten Fall erhält der Knoten von jedem seiner Nachbarn die gleichen Eventdaten. Dies kann zu einer schnelleren Wiederherstellung von zusammengebrochenen
Pfaden genutzt werden.
2.3.
ROUTINGVERFAHREN
(a)
17
(b)
(c)
Abbildung 2.3: Vereinfachtes Schema von Directed Diusion: (a) Interest Verbreitung,
(b) Erzeugen der Gradienten, (c) Datentransfer über verstärkten Pfad
2.3.2.2
Datenübertragung
Nach der oben beschriebenen Bearbeitung der Empfangenen Interests fragt der Sensorknoten die entsprechenden Sensoren ab und beginnt mit der Auswertung der Daten.
Wenn etwas entdeckt wurde, wird zuerst ein passender Interesteintrag gesucht. Wenn
ein Eintrag existiert wird der Sensor mit der angegebenen Datenrate abgefragt und die
Daten an die Senke über den entsprechenden Gradienten zurück geschickt (siehe Abbildung 2.3c).
Nachdem ein Knoten ein Datenpaket empfangen hat wird der passende Cacheeintrag
gesucht. Wird kein Eintrag gefunden, wird das Paket verworfen. Ansonsten wird der
Datencache auf einen passenden Eintrag überprüft. Dieser Cache enthält Informationen
über die zuletzt versendeten Pakete, um Loops zu verhindern. Wird also ein Eintrag
gefunden, wird das Paket abermals verworfen. Andernfalls wird das Paket an einen
Nachbarknoten weitergeleitet und ein Eintrag im Datencache angelegt. Durch das Überprüfen der relevanten Gradienten kann der Knoten die benötigte Datenrate erfahren.
Ist die Datenrate der eintreenden Daten höher, als die Datenrate der ausgehenden Daten kann der Knoten entweder Pakete verwerfen oder die Daten vor dem Weiterleiten
abhängig von den Gradienten interpolieren.
2.3.2.3
Reinforcements zum Anlegen und Unterbrechen von Pfaden
Nachdem ein Pfad per Interests und Gradienten angelegt wurde, ist das Sensornetzwerk
bereit, die gestellten Aufgaben zu erledigen. Entdeckt ein Knoten ein passendes Phenomen in seiner Umgebung sendet er einen Event zur Senke, möglicherweise auch über
mehrere Pfade. Die Senke verstärkt nun einen Pfad von dem sie den Event empfangen
18
KAPITEL 2.
GRUNDLAGEN UND EXISTIERENDE ANSÄTZE
hat per Reinforcement und nimmt diesen damit verstärkt in Anspruch. Dieses Verstärken (engl. reinforcement) wird durch das Erhöhen oder Absenken des Datenratefelds im
entsprechenden Gradienten erreicht. Dazu wird der Original-Interest mit verändertem
Intervallfeld an den entsprechenden Knoten geschickt. Es gibt zwei Arten von Reinforcements: positive und negative. Positive Reinforcements erhöhen die Datenrate und
negative senken diese ab. Mit dieser Technik können sehr komplexe Aufgaben erledigt
werden, hier ein kurzer Überblick:
•
Anlegen eines Pfades mittels positivem Reinforcement
Jeder Nachbar, von dem die Senke eine neue Nachricht bekommen hat, wird positiv verstärkt. Die Nachbarn wiederum verstärken ihre Nachbarn, bis die neue
Datenrate erreicht ist. Dies wird fortgesetzt, bis die Quelle erreicht ist und mehr
Daten geliefert werden.
•
Anlegen eines Pfades mit mehreren Quellen und/oder Senken
Wenn zwei Quellen einen angeforderten Event entdecken, senden beide ihre Beobachtung an die Senke. Auf dem Weg zur Senke kann es vorkommen, dass sich die
Pfade der beiden Nachrichten kreuzen. Dann werden beim Verstärken von Pfaden
beide Pfade verstärkt und nicht nur einer.
Fragt ein Knoten die gleichen Daten an, die schon von einem anderen Knoten per
Interest angefragt wurden. Und so schon ein Pfad zwischen den Quellen und der
ersten Senke besteht, braucht die neue Senke nur noch den Pfad bis zur bestehenden Verbindung aufzubauen. Durch die Möglichkeit zwei gleiche Interests zu
aggregieren kann der bestehende Pfad der alten Verbindung vom Kreuzungspunkt
ab mitbenutzt werden.
•
Lokales Reparieren eines unterbrochenen Pfads
Erkennt ein Knoten auf dem Pfad zwischen Quelle und Senke ein Problem mit
dem bisherigen Pfad, kann er einen neuen Pfad wählen und diesen positiv verstärken. Der bisherige, problematische Pfad wird negativ verstärkt, um ihn zu
unterbrechen (siehe nächster Punkt).
•
Unterbrechen eines Pfads mittels negativem Reinforcement
Analog zum positiven Reinforcement beim Anlegen von Pfaden, wird negatives
Reinforcement dazu genutzt Pfade zu unterbrechen, die nur bereits bekannte
Nachrichten liefern.
•
Entfernen von Loops mittels negativem Reinforcement
Neben dem Unterbrechen von Pfaden auf denen Pakete verloren gehen oder hohe
Verzögerungen auftreten, verhindert negatives Reinforcement auch automatisch
Loops, denn Loops können keine neuen Pakete transportieren.
2.4.
VERFAHREN ZUR GRUPPIERUNG VON SENSORKNOTEN
19
2.3.3 Gradient-Based Routing
Gradient-Based Routing (GBR) [37] erweitert Directed Diusion. Im Gegensatz zum
oben beschriebenen Verlauf ändert sich folgendes an der Behandlung von Interests und
Gradienten:
Wenn ein Interest durch das drahtlose Sensornetz geutet wird, speichert der Interest
die Anzahl von Knoten, die er durchlaufen hat. Das ermöglicht es jedem einzelnen Knoten den kürzesten Weg zur Senke zu nden. Diese Anzahl an Hops nennt sich Höhe eines
Knotens. Der Unterschied zwischen der eigenen Höhe und der eines Nachbarn ist der
Gradient der Verbindung. Ein Event wird dann über die Verbindung mit dem höchsten
Gradienten weitergeleitet.
2.4 Verfahren zur Gruppierung von Sensorknoten
Betrachtet man die Entwicklung der Sensornetze und deren Programmierung im speziellen, dann stellt man fest, dass es eine starke Tendenz zur Abstrahierung und damit
zur Verringerung des Programmieraufwands gibt. In den Anfängen der Sensornetzwerke
und auch noch bei heutigen Projekten werden die einzelnen Knoten für ihre spezielle
Aufgabe programmiert und ausgerüstet. Eine dynamische Reprogrammierung einzelner
Knoten oder gar des ganzen Netzes gab es anfangs allerdings noch nicht. Da die direkte Neuprogrammierung des Sensornetzwerks auch heute noch mit immensem Aufwand
verbunden ist, wird vielfach versucht Sensorknoten in Gruppen zusammenzufassen und
so die Teile eines Netzes zu isolieren, die zum Beispiel eine neue Anwendung ausführen
sollen. In [39] wird eine kleine Übersicht über Verfahren gegeben, die sich als Ziel die
Gruppierung von Sensornetzwerken gesetzt haben:
•
Lokale Cluster
•
Generic Role Assignments
Region Streams
•
Abstract Regions
Rollen
•
Hood
Regiment
Multicast
Die Verfahren werden im Folgenden kurz erläutert. Der nächste Schritt ist jetzt ein
Sensornetzwerk, das zur Laufzeit mehrere Anwendungen gleichzeitig bedienen und neue
20
KAPITEL 2.
GRUNDLAGEN UND EXISTIERENDE ANSÄTZE
Anwendungen aufnehmen kann. Vor allem aber, die Möglichkeit einer Netzwerkweiten
Auswahl der Sensorknoten und einer Einschränkung von Anwendungen auf eine solche
Gruppe bietet. Mit den hier beschriebenen Verfahren ist das noch nicht Möglich bzw.
sind nur Teile dieser Anforderungen erfüllt. Mit Scopes wird dies möglich sein.
2.4.1 Lokale Cluster
Viele Anwendungen erzeugen lokale Cluster zur Datensammlung. Aus dieser Beobachtung entstanden die Ansätze für Hood [45] und Abstract Regions [44]. Beide nutzen
sogenannte Nachbarschaften, die im Falle von Hood durch 'One Hop'-Broadcasts zustande kommen und bei Abstract Regions auch gröÿere Entfernungen umfassen können.
Sie werden etwa über einen Radius oder eine höhere Hopanzahl deniert und kommunizieren zum Beispiel mittels Meshes oder Trees untereinander. Innerhalb der Nachbarschaften werden Daten ausgetauscht, aggregiert oder anderweitig Vorverarbeitet. Dabei
sind die Knoten in der Regel in mehreren Nachbarschaften gleichzeitig aktiv. Die Software, die auf den einzelnen Knoten läuft, ist dabei überall gleich; Eine Dierenzierung
der Knoten ndet erst zur Laufzeit statt, die von den Knoten in der Nachbarschaft
abhängt.
2.4.2 Rollen
Ein Weg das Neuprogrammieren zu umgehen wurde in [36] mit generic role assing-
ments vorgestellt. Hier werden die Knoten mit einer Anzahl vorgefertigter Rollen und
dazugehörenden Aufgaben programmiert, die dann abhängig von vorgegebenen Umständen aktiv werden. Im Gegensatz zu Hood und Abstract Regions können die Knoten
hier Netzwerkweit angesprochen werden, es existiert allerdings keine Funktion mehrere
Knoten direkt zu gruppieren.
2.4.3 Region Streams
Regiment [33] ist eine funktionale Makroprogrammiersprache, die mit Hilfe von Region
Streams [44], aus der programmierten Anwendung das Verhalten der einzelnen Sensorknoten eines Sensornetzwerks erzeugt. In dieser Sprache kann der Programmierer etwa
eine Gruppe von Knoten über ihre geographische Position oder eine andere Eigenschaft
ansprechen und der daraus resultierende Region Stream repräsentiert die Sensordaten
der angesprochenen Knoten. Auf Region Streams können weitere Operationen ausgeführt werden, wie zum Beispiel das Aggregieren der Daten.
2.5.
ZUSAMMENFASSUNG
21
2.4.4 Multicast
Multicastverfahren für Sensornetzwerke, wie etwa aus [7, 28], bieten gleichfalls die Möglichkeit einer Gruppierung. Sie übernehmen das aus draht-basierten Netzwerken bekannte Vorgehen, in dem der Knoten selbst entscheidet, ob und zu welcher Gruppe er gehört.
Dies wird durch das Anschlieÿen an die entsprechende Gruppe bzw. deren Multicast
Id erreicht. Dieses Vorgehen widerspricht insofern dem in Sensornetzen verwendeten
Schema, Knoten über ihre Eigenschaften auszuwählen, dass hier die einzelnen Knoten
selbst über ihre Mitgliedschaft entscheiden.
2.5 Zusammenfassung
Sensornetze bestehen aus vielen, kleinen, batteriebetriebenen Sensorknoten, die in der
Regel über eine Funkschnittstelle miteinander kommunizieren können. Die Sensorknoten
sind je nach Anwendung mit den verschiedensten Sensoren ausgerüstet. Die Einsatzbereiche der Sensornetze liegen meist im Überwachen von Gebieten oder auch Maschienen.
Die Software für Sensorknoten muÿ mit den begrenzten Ressourcen und den Besonderheiten des Funkmediums klar kommen.
Für drahtlose Sensornetze sind viele eziente Routingverfahren bekannt. Mit Directed
Diusion wurde schon ein Algorithmus veröentlicht, der dem unter Scopes benötigten
sehr nahe kommt. Es bildet, mit der Erweiterung von Gradient-based Routing, die Basis
für das im Folgenden beschriebenen Multihop Routing.
Auch für die Gruppierung von Knoten in Sensornetzen existieren schon die unterschiedlichsten Verfahren. Die Meisten verfügen über einzelne Bestandteile, der in Scopes vorhandenen Möglichkeiten. Wie etwa die Gruppierung von Knoten während der Laufzeit
in Hood, dies aber nur im Umfeld eines Knotens und nicht in gesamten Sensornetz.
22
KAPITEL 2.
GRUNDLAGEN UND EXISTIERENDE ANSÄTZE
Kapitel 3
Architektur für drahtlose
Mehrzweck-Sensornetze
3.1 Einführung
Scopes sind für Informatiker keine Unbekannten. In den meisten wenn nicht in allen
modernen objektorientierten Programmiersprachen haben Variablen einen gewissen
Gültigkeitsbereich, scope genannt. So sind lokale Variablen zum Beispiel nur innerhalb
ihres Codeblocks, globale Variablen innerhalb der gesamten Datei erreichbar. Diese
Gültigkeitsbereiche sind ineinander schachtelbar, das heiÿt ein Scope kann beliebig viele weitere Scopes enthalten. So ist in einer Klasse je ein Scope für jede Methode und
ihre lokalen Variablen eingebettet.
Dieses Muster wurde von Fiege et. al. in [16] auf verteilte Systeme übertragen und von
Stean et. al. [38, 39] auf drahtlose Sensornetze angewandt. Diese Umsetzung führt zu
Mehrzweck-Sensornetzen, die auch während der Laufzeit neue oder geänderte Anwendungen ausführen können. Diese sollen im Folgenden erläutert werden.
Damit die Sensorknoten arbeiten können wird noch ein Betriebssystem benötigt. Wie
im letzten Kapitel schon beschrieben sind heutzutage zwei bekannte Betriebssysteme
für Sensornetze verfügbar: TinyOS und SOS. Für diese Arbeit wurde SOS ausgewählt,
da es bereits von Hause aus über das Netzwerk nachladbare Module unterstützt und die
weiteren Leistungsdaten, wie Energieverbrauch oder Beanspruchung der CPU, TinyOS
ebenbürtig sind [20].
23
24KAPITEL 3. ARCHITEKTUR FÜR DRAHTLOSE MEHRZWECK-SENSORNETZE
3.2 Scopes
Grundsätzlich bezeichnet ein Scope eine Gruppe von Sensorknoten, die über ihre Eigenschaften ausgewählt werden. Ein Scope kann mehrere Male, für unterschiedliche Anfragen und Aufgaben, wiederverwendet werden. Die Architektur der Scopes ist grob in
vier Schichten aufgeteilt (siehe Abbildung 3.1). Die unterste Schicht stellt die Hardware
abstrahiert dar, wie sie von Sensornetzwerkbetriebssystemen für Netzwerk und Sensoren bereitgestellt werden. Die oberste Schicht ist für das Multitasking auf Knotenebene
zuständig; Zum Beispiel den Lebenszyklus einer Anwendung oder das Speichermanagement, dass für das Ausführen und instantiieren mehrerer gleichzeitiger Tasks benötigt
wird. Diese Schicht ist unabhängig von den verbleibenden zwei Scope-Schichten. Diese
setzen sich aus der Scope Schicht und der Routing Schicht zusammen. In der Scope
Schicht wird der Status der Scopemitgliedschaften für den jeweiligen Knoten erfasst. In
der Routing Schicht wird das Versenden und Empfangen von Anfragen und Nachrichten
behandelt.
3.2.1 Spezizierung von Scopes
Ein Scope ist also eine Gruppe in der alle Knoten die entsprechenden Voraussetzungen erfüllen. Der zentrale Teil einer Sprache zur Spezizierung von Scopes, ist die Fähigkeit, diese Voraussetzungen zu beschreiben. Die Voraussetzungen basieren auf den
Eigenschaften des lokalen Knotens. Diese Eigenschaften, können je nach Einsatzszenario variieren und werden deshalb als austauschbare Module implementiert. Sie können
sowohl statischen, als auch dynamischen Charakter haben. Dynamische Eigenschaften
sind deshalb interessant, da hier z. B. eine Änderung der Umgebung zu einer neuen Auswertung der Zugehörigkeitsbedingungen eines Scopes führt. So kann das Wegfallen eines
Nachbarknotens dazu führen, dass z. B. die Bedingung mindestens drei Nachbarknoten nicht mehr erfüllt ist und somit der Knoten auch nicht mehr dem entsprechenden
Scope angehört. Die dynamischen Eigenschaften werden in spezialisierten Modulen implementiert, die einen Event auslösen, sollte sich eine solche Eigenschaft ändern.
Zum Ansprechen der einzelnen Eigenschaften wird ein hierarchischer Namensraum verwendet, wie etwa
one.two.three.
Dadurch werden einzelne Implementierungen un-
terscheidbar und szenariospezische Eigenschaften können ohne Probleme hinzugefügt
werden. Dabei wird der erste Teil im Namen der Eigenschaft für das Modul verwendet,
dass die entsprechende Eigenschaft zur Verfügung stellt. Um die geringen Ressourcen
auf Sensorknoten zu schonen wird der Bezeichner beim kompilieren in einen Bytecode
umgesetzt.
Für eingebettete Scopes wird ein Basisscope deniert, dessen Mitgliedsknoten Kandidaten für den neuen Scope sind. Dabei werden die Nachrichten für die Erzeugung des
neuen Scopes beim Versenden auf den Basisscope eingeschränkt. Um den ersten Scope
zu erzeugen wird ebenso ein Basisscope benötigt, deshalb gibt es einen globalen Basisscope, der alle Knoten umfasst und mit world bezeichnet wird. Dies alles führt zu einer
3.2.
SCOPES
Anwendungsebene
25
Lebenszyklus
Anwendungen
Task 1
Scopeebene
Aktueller Scope
Task 2
Auswertung
...
Task n
Eigenschaften
Zustand
Dynamische
Eingenschaften
Auswahl der Route
Routing
Empfangen,
Weiterleiten,
Senden
Hardwareabstraktion
Module
Module
Betriebssystemfunktionen,
Low-level Zugriff, ...
Abbildung 3.1: Scope Schichtenmodell
26KAPITEL 3. ARCHITEKTUR FÜR DRAHTLOSE MEHRZWECK-SENSORNETZE
höheren Eektivität bei der Ausbreitung von Nachrichten und der Scopeverwaltung.
Der Lebenszyklus eines Scope umfasst Mechanismen zur Scopeerzeugung und -löschung.
Erzeugt werden kann ein Scope von jedem Knoten in einem Sensornetzwerk, der eine
entsprechende Nachricht versendet. Dieser wird dann als Wurzel des Scopes bezeichnet. Das Entfernen eines Scopes kann auf zweierlei Arten geschehen: Entweder wird der
Scope regulär durch eine Nachricht vom Wurzelknoten des Scopes gelöscht oder seine
Lebensdauer läuft ab. Scopes werden mit einer entsprechenden Lebensdauer erzeugt, die
bei Bedarf auch verlängert werden kann. Ist diese überschritten wird der Scope gelöscht.
Das hat den Vorteil, dass mit der lokalen Entscheidung des Knotens kein weiterer Kommunikationsaufwand entsteht und kein veralteter Scope in einem, z.B. abgeschnittenen
Teil, des Netzwerks weiterexistiert. Die Länge der Lebensdauer kann je nach Szenario
oder Art der Daten angepasst werden.
3.2.2 Ausbreitung und Wartung von Scopes
Während der Ausbreitung einer Nachricht zur Scopeerzeugung wird ein Routingbaum
aufgebaut, der vom Wurzelknoten aus alle Mitglieder des neuen Scopes umfasst. Während der Lebensdauer des Scope müssen die Verbindungen des Routingbaums und die
Mitgliedschaften im Scope verwaltet werden. Die Hauptaufgabe des Routingbaums ist
das Verteilen von Anfragen oder neuen Modulen und die Übertragung von Ergebnissen
oder Events zurück zum Wurzelknoten des Scope. Die Ausbreitung lässt sich durch das
Nutzen von Mitgliedschaftseigenschaften, wie etwa geograscher Position oder Hops
zum Wurzelknoten, des Scopes optimieren.
Empfängt ein Knoten ein Paket zur Scopeerzeugung und er erfüllt die Mitgliedschaftsbedingungen, dann werden die Scope Id und -bedingungen lokal gespeichert. Solange
der Knoten Mitglied des Scopes und die Lebensdauer nicht abgelaufen ist, nimmt der
Knoten Nachrichten für diesen Scope an und verarbeitet sie ggf. weiter.
Knoten, die beim Empfang solch einer Nachricht die Bedingungen nicht erfüllen und
die Bedingungen dynamische Eigenschaften beinhalten, speichern die Informationen
ebenfalls und prüfen bei Änderung dieser Eigenschaften, ob inzwischen die Mitgliedschaftsbedingungen erfüllt sind.
Sind die Bedingungen für die Mitgliedschaft nicht erfüllt, der Knoten liegt aber auf einem Pfad zwischen dem Wurzelkonten und einem Mitgliedsknoten, müssen die entsprechenden Informationen genauso gespeichert werden, um das Routen von Nachrichten
zu gewährleisten.
Bekommt ein Knoten einen neuen Nachbarknoten, der im globalen Basisscope liegt,
werden zuerst alle Scopes mit ihren Bedingungen ausgetauscht. So wird auch mit sämtlichen Subscopes verfahren.
3.3.
DAS SOS BETRIEBSSYSTEM
27
3.2.3 Scopes in Beispielen
Die in Abschnitt 2.2.2 für drahtlose Sensornetzwerke eingeführten Beispiele können vom
Einsatz von Scopes protieren. Wie vorhin schon angekündigt werden hier einige denkbare Vorteile vorgestellt.
Wenn in dem Gewächshaus Projekt Scopes eingesetzt werden, kann zum Beispiel für
jede Panzensorte ein eigener Scope eingerichtet werden. So werden dann nur die für
die entsprechende Panzensorte wichtigen Eckdaten gesammelt und überwacht.
Genauso kann ein Scope für die Temperaturüberwachung die Knoten über den Panzen miteinander verbinden und die Abfrage der Temperaturdaten wird nur an die daran
beteiligten bzw. dafür ausgerüsteten Knoten weitergeleitet. Dies hat zur Folge, dass unbeteiligte Knoten nicht behelligt werden und somit weniger Energie verbrauchen.
Auch im Container-Szenario ergeben sich denkbare Vorteile. So kann ein Spediteur,
ohne auf das Schi gelangen zu müssen, prüfen, ob seine Ladung unversehrt und komplett an Board ist. Natürlich muss durch entsprechende Sicherheitsmechanismen [39]
verhindert werden, dass Konkurrenten diese Informationen bekommen. Genauso kann
ein LKW-Fahrer oder ein Polizist überprüfen, ob die Frachtpapiere des Containers korrekt sind, ganz einfach über das Auslesen der von den Sensornetzen gelieferten Daten
über den Bestand im Container. Ein weiterer Vorteil wäre das leichte Aunden von
vergessenen oder über Board gegangenen Containern, wenn die Sensorknoten an den
Containern eine Positionsbestimmung z. B. per GPS beherrschen.
3.3 Das SOS Betriebssystem
Das SOS Betriebssystem besteht nach [20] aus dem Kernel und verschiedenen Modulen,
die die eigentliche Funktionalität eines Sensorknotens ausmachen. Neben den grundsätzlichen Funktionen, wie zum Beispiel Nachrichtentransport, stellt der Kernel erweiterte
Services, wie nachladbare Module, exibles Priority scheduling und ein einfaches dynamisches Speichersubsystem zur Verfügung. Änderungen am Kernel sind in der Regel
nicht nötig, um eine Anwendung oder ein Protokoll zu implementieren. Für diese Zwecke
werden Module verwendet, die auf den Knoten vorgeladen sein können oder während
der Laufzeit über das drahtlose Netz verteilt, aktualisiert und auch wieder entfernt
werden können. In den Modulen können zum Beispiel Treiber für Sensoren, Routingprotokolle oder auch Anwendungen implementiert werden. Die Module kommunizieren
untereinander entweder über versendete Nachrichten oder mittels eines direkten Funktionsaufrufs (siehe Abbildung 3.2). Um die Robustheit zu erhöhen und den Verlust des
dynamischen Speichers zu minimieren ist SOS mit einem primitiven Garbage collector
ausgestattet, der nach dem Entfernen eines Moduls die noch belegten Ressourcen des
Moduls wieder frei gibt.
28KAPITEL 3. ARCHITEKTUR FÜR DRAHTLOSE MEHRZWECK-SENSORNETZE
3.3.1 Module
Module sind positionsunabhängige Binaries, die eine bestimmte Funktion oder Aufgabe erledigen. Die meisten Entwicklungsaufgaben werden in Modulen bearbeitet. Eine
Veränderung des SOS Kernel ist nur nötig, wenn spezielle Hardware angesprochen oder
das Ressourcemanagement verändert werden soll. Eine Anwendung besteht in der Regel
aus mehreren interagierenden Modulen. Um die Modularität zu gewährleisten werden
nur denierte Schnittstellen zum SOS Kernel und zu anderen Modulen verwendet.
Die Struktur eines Moduls (siehe Listing 3.1) enthält mindestens den Modulheader und
den Messagehandler. Im Modulheader wird angegeben, was das Modul benötigt und
was es anbietet. So wird die Struktur und Gröÿe des Modulstatus festgelegt, die Anzahl der benötigten Timer angegeben und die von anderen Modulen genutzten und die
selbst zur Verfügung gestellten Funktionen aufgelistet. Kommt eine neue Nachricht für
ein Modul an, wird der Messagehandler mit der Nachricht und dem Modulstatus aufgerufen. Der Modulstatus ist die einzige Möglichkeit für ein Modul Informationen von
einem Aufruf in den Nächsten mitzunehmen, da der Modulstatus im RAM auÿerhalb
des Moduls gespeichert wird. Der Messagehandler muss mindestens die Nachrichten
init und nal behandeln, also die Initialisierung nach dem Laden des Moduls und das
Freigeben belegter Ressourcen vor dem Entladen des Moduls. Neben diesen kann er
noch Nachrichten von Sensoren, von Timern und selbst denierten Nachrichten bzw.
Nachrichten von anderen Modulen handhaben. Ist die Behandlung einer Nachricht abgeschlossen wird der Messagehandler und das Modul wieder verlassen. Dieser Ablauf
wird auch als asynchrones Ansprechen eines Moduls bezeichnet, da die Nachrichten erst
die priority queue durchlaufen, bevor sie verarbeitet werden.
Der synchrone Weg, ist das direkte Ansprechen einer im Kernel registrierten Modulfunktion (Abbildung 3.2). Das Registrieren im Kernel geschieht über das Angeben der
Funktion im Modulheader. Ein Handler für eine Funktion eines anderen Moduls zu bekommen funktioniert genauso. Die Funktion wird mit den Parametern im Modulheader
angegeben und beim Laden des Moduls wird der Handler an eine Variable im Modulstatus übergeben. Mit diesem Handler und dem Funktionsprototyp (und eventuellen
Parametern) kann die Methode dann genutzt werden. Beim Entladen des Moduls werden die Handler und die Registrierung von Funktionen automatisch entfernt. [32]
Zum Laden eines Moduls über das Netzwerk, wird ein spezielles Protokoll initiiert. Die
Knoten lauschen auf ein advertisement für ein neues oder aktualisiertes Modul und prüfen nach dem Empfang eines solchen, ob ein lokales Modul aktualisiert werden muss oder
ob der Knoten noch Platz für ein weiteres Modul hat. Trit eine dieser Bedingungen
zu fordert der Knoten das Modul von dem Nachbarn an, von dem er das advertisement
empfangen hat. Die heruntergeladenen Daten bestehen aus dem Modul an sich und einigen Metadaten, wie etwa der eindeutigen Id des Moduls, Versionsinformationen und
die Gröÿe seiner lokalen Statusstruktur. Ist für alles genug Platz vorhanden, wird das
Modul gespeichert. Beim Einfügen des Moduls wird eine Struktur mit der eindeutigen
3.3.
1
DAS SOS BETRIEBSSYSTEM
#include
29
<module . h>
2
3
4
//
Modulstatus
typedef struct
5
6
{
sos_pid_t
}
pid ;
app_state_t ;
7
8
9
//
Modulheader
static
mod_header_t
mod_header SOS_MODULE_HEADER = {
10
. mod_id
= DFLT_APP_ID0,
11
. state_size
=
12
. num_timers
= 0,
13
. num_sub_func
= 0,
14
. num_prov_func
= 0,
15
. m o d u l e _ h a n d l e r = module ,
16
s i z e o f ( app_state_t ) ,
};
17
18
//
Messagehandler
19
static
20
{
21
int8_t
module (
app_state_t
22
,
= ( app_state_t
Message
∗)
∗ msg )
state ;
switch ( msg−>t y p e ) {
case MSG_INIT :
23
24
25
{
s −>p i d = msg−>d i d ;
26
return
27
28
SOS_OK ;
}
29
case
30
{
MSG_FINAL :
return
31
32
SOS_OK ;
}
default :
33
34
35
return −EINVAL ;
}
36
return
37
38
∗s
void ∗ s t a t e
SOS_OK ;
}
Listing 3.1: Beispiel eines einfachen SOS Moduls
30KAPITEL 3. ARCHITEKTUR FÜR DRAHTLOSE MEHRZWECK-SENSORNETZE
Vom SOS
Scheduler
Aus dem Rest
des Systems
Nachricht
SOS Funktions-Kontroll-Block
Liste
Message
Handler
FCB #1
...
...
Init
Handler
Final
Handler
...
Timer
Handler
Registrierte
Funktion #m
...
Nachricht #n
Handler
...
Module
Abbildung 3.2: Modell der Zugrie auf Module in SOS
3.3.
DAS SOS BETRIEBSSYSTEM
31
Id des Moduls erzeugt und schlieÿlich wird das Modul durch eine init Nachricht initialisiert. Das verwendete Verteilungsprotokoll ist vom SOS Kernel unabhängig und kann
so bei Bedarf leicht modiziert oder ausgetauscht werden. Das Löschen eines Moduls
wird vom Kernel durch das Versenden der nal Nachricht angestoÿen. Darauf hin hat
das Modul die Möglichkeit reservierte Ressourcen freizugeben. Hat der Messagehandler seine Arbeit beendet und das Modul verlassen, werden vom Kernel noch belegte
Ressourcen freigegeben und das Modul entfernt. Für das Verhalten bei Fehlern im Zusammenhang mit Modulen vergleiche [20].
3.3.2 Scheduling
Das Nachrichten Scheduling wird in SOS durch eine priority queue realisiert. Nachrichten einer bestimmten Priorität werden zu einer einfachen, verketteten Liste zusammengefasst. Dadurch, dass jede Nachricht die kompletten Informationen über Herkunft und
Ziel beinhaltet, können sowohl lokale, wie auch über das Netzwerk empfangene Nachrichten direkt in die Liste eingefügt werden. Die Nachrichten enthalten einen Pointer
auf die enthaltenen Nutzdaten, die zum Beispiel Parameter oder komplexere Strukturen
zwischen den Modulen transportieren. Zu diesem Zweck stellt SOS einen Mechanismus
bereit die Zugehörigkeit von dynamisch reserviertem Speicher zwischen verschiedenen
Modulen zu transferieren. Sind nur wenige Bytes zu transferieren braucht dafür kein
neuer Speicher reserviert zu werden, sondern sie können direkt im Header einer Nachricht mittransportiert werden. Zudem verfügt der Header über einige Flags, die die
Priorität der Nachricht beschreiben, die Herkunft der Nachricht (lokal, drahtloses Netzwerk, I2C,...) und wie mit dem reservierten Speicher der Nutzdaten umgegangen werden
soll. Diese Flags erlauben einen einfachen Transfer von reserviertem Speicher zwischen
Modulen und vereinfachen das Freigeben von Speicher nach dem versenden der Nachricht.
In SOS werden hohe Prioritäten in Nachrichten zur Behandlung von Interrupts und
Timern zeitkritischer Tasks verwendet. Priority queues haben in SOS dazu geführt,
dass nur kurze Zeit in einem Interruptkontext gearbeitet wird, denn die Interrupthandler wurden so entworfen, dass sie möglichst schnell eine Nachricht mit hoher Priorität
verfassen und an den Scheduler weiterreichen. Dadurch werden Beeinträchtigungen der
regulären Verarbeitung, zum Beispiel durch das Ändern von Puern aus dem Interruptkontext heraus, gering gehalten.
3.3.3 Speicherverwaltung
In den bisherigen Versionen von SOS (bis Februar 2006) wurde der dynamisch reservierbare Speicher über einfache Speicherblöcke fester Gröÿe realisiert. Bei dem Versuch
Speicher zu reservieren wurde geprüft, welche der drei Basisgröÿen (16, 32 und 128
32KAPITEL 3. ARCHITEKTUR FÜR DRAHTLOSE MEHRZWECK-SENSORNETZE
Byte) der Anforderung am Besten entspricht, und ein Pointer auf die entsprechende
Speicherseite zurück geliefert. Ist keine Speicherseite mehr frei, die groÿ genug ist, wird
ein Null-Pointer zurückgeliefert. Wenn also zum Beispiel 4 Byte benötigt wurden, aber
nur noch eine 128 Byte Speicherseite verfügbar war, wurde diese reserviert. Alle Speicheranforderungen des SOS Kernel passen in die kleinste Speichergröÿe, von der es auch
die meisten Seiten gibt. Die einzelnen verfügbaren Seiten werden jeweils in verketteten
Listen für jede der Gröÿen verwaltet. Insgesamt konnten maximal 52 Speicherseiten
reserviert werden.
In aktuelleren Versionen von SOS (ab Februar 2006) wird eine neu implementierte
Speicherverwaltung verwendet, sie basiert auf [27], einem doppelt verlinkted Speicher
Manager, und bietet folgende Neuerungen: Keine Limitierung der Gröÿe des zu reservierenden Speichers (abgesehen von der Heapgröÿe). Die Möglichkeit reservierte Speicherbereiche im Nachhinein zu vergröÿern und automatische Speicherdefragmentierung. Die
Speicherzuordnung zu einem Modul und Erkennung von Fehlzugrien auf den Speicher
blieben erhalten. Intern setzt sich der Speicher immer noch aus Speicherblöcken fester
Gröÿe zusammen, allerdings alle mit der gleichen Gröÿe. Diese variiert je nach Prozessor,
ebenso die zu der zu reservierenden Gröÿe hinzukommenden Verwaltungsinformationen.
Für Atmel Prozessoren (wie etwa bei der Mica-Serie benutzt) liegt die Blockgröÿe bei 8
Byte und die Meta-Daten bei 4 Byte. Das bedeutet für mein 4 Byte Beispiel von vorhin
keinen Verlust an Speicherkapazität (4 + 4
=8
Byte). Natürlich kommt es auch hier zu
Verlusten. Aber durch die kleinere Blockgröÿe kommt es zu weniger Verlusten und so
kann letztendlich mehr Speicher reserviert werden, als mit der Vorgängerverwaltung.
[21]
Reservierter Speicher wird einem bestimmten lokalen Modul zugeordnet. Diese Information wird beim Reservieren des Speichers gesetzt und wird vom SOS Kernel dazu
verwendet einen einfachen Garbage collector bereit zu stellen, der nach dem Entfernen
eines Moduls den von diesem reservierten Speicher wieder frei gibt. Module können
Speicherbereiche über diese Zuordnungen auch untereinander transferieren.
3.4 Zusammenfassung
Scopes ermöglichen es, ein Sensornetzwerk zu unterteilen und Anwendungen nur in einem bestimmten Unterabschnitt des Sensornetzwerks zu verteilen. Zudem können diese
Unterteilungen während der Laufzeit erzeugt, geändert und auch wieder entfernt werden. Die Möglichkeit der dynamischen Eigenschaften für einen Scope führt sogar zu
einer automatischen Änderung der Mitgliedschaft in einem Scope, wenn sich die Bedingungen für eine Eigenschaft im Laufe der Zeit ändern. Wie aus den Szenarien zu ersehen
ist, ergeben sich hier neue Anwendungsgebiete, die die Einsatzmöglichkeiten von Scopes
erweitern (z.B. das Containerhafen-Szenario, 2.2.2 und 3.2.3) oder Anwendungen, die
nur noch in den Bereichen des Sensornetzwerks arbeiten, in denen sie auch arbeiten
sollen (siehe das Gewächshaus-Szenario, 2.2.2 und 3.2.3).
Um den Programmierern von Anwendungen für Sensornetze eine einheitliche Program-
3.4.
ZUSAMMENFASSUNG
33
mierumgebung zur Verfügung zu stellen und nicht grundlegende Funktionen für jeden
Typ von Sensorknoten erneut implementieren zu müssen, wurden Betriebsysteme für
Sensorknoten entwickelt. Mit SOS, als einem Vertreter dieser Art von Betriebsystem,
bieten sie, neben grundlegenden Schnittstellen zur Kommunikation, LEDs und weiteren
Hardwarekomponenten der Sensorknoten, auch Komfortfunktionen, wie einen Scheduler
für versendete und empfangene Nachrichten und eine Speicherverwaltung mit einfachem
Garbage collector, die das Reservieren und Freigeben von dynamischem Speicher überhaupt erst ermöglicht.
34KAPITEL 3. ARCHITEKTUR FÜR DRAHTLOSE MEHRZWECK-SENSORNETZE
Kapitel 4
Realisierung
4.1 Entwicklungsumgebung
Zur Entwicklung der folgenden Implementierungen stand ein Arbeitsplatz PC mit AMD
AthlonXP 2000+ Prozessor, genügend Festplattenkapazität zur Verfügung. Auf dem PC
lief ein Debian 3.1 (Sarge) Linux mit folgender Software, die zur Erstellung dieser Arbeit eingesetzt wurde (Version der .deb-Pakete, soweit vorhanden):
•
Compiler-Toolchain (x86)
•
binutils (Version 2.15-6)
libc6 (Version 2.3.2.ds1-22sa)
gcc-avr (Version 3.4.3-2)
binutils-avr (Version 2.15-3)
avr-libc (Version 1.2.3-3)
gdb-avr (Version 6.3-2)
Debuging
•
gdb (Version 6.3-6)
Compiler-Toolchain (avr)
•
gcc-3.3 (Version 3.3.5-13)
gdb (Version 6.3-6)
kdbg (Version 1.9.7-1)
Simulation
35
36
KAPITEL 4.
REALISIERUNG
avrora (Versionen 1.6.0 - 1.7.56, immer aktuelle CVS-Versionen bis Ende Mai
2006)
SOS Betriebssystem (Versionen 0.8 - 1.3, immer aktuelle CVS-Versionen bis
Ende Mai 2006)
•
Visualisierung
python (Version 2.3.5-2)
1
tetex (Version 2.0.2c-8, mit einigen aktualisierten Komponenten )
eclipse (Version 3.1.2)
Java SDK (Version 1.5.0_06)
Neben diesen Programmen wurden noch diverse Standardprogramme, wie Texteditoren,
CVS, der Gnome Desktop und diverse Internetanwendungen genutzt, die aber keinen
direkten Einuss auf die Programmierung hatten.
4.2 Basisimplementierung
Die Basisimplementierung hatte zum Ziel eine erste, einfache Version der Scopes zur
Verfügung zu stellen, ohne groÿen Aufwand für das Routing oder komplizierte Mitgliedseigenschaften. Sie sollte in einer ersten Näherung zeigen, ob sich Scopes auf aktuell verfügbaren Sensorknoten überhaupt betreiben lassen. Die Basisversion wurde noch
für SOS 0.8 entworfen und ist aufgrund von Änderungen am Modulaufbau mit der
aktuellen Version nicht mehr kompatibel.
4.2.1 Aufbau
Die erste Implementierung wurde in zwei Module aufgetrennt. Ein Routing-Modul und
das simple_scope -Modul. Für das Routing wurde das in SOS enthaltene Modul Flooding
benutzt, das Nachrichten im Netzwerk per Broadcast verbreitet. Das Scope-Modul vereint alle grundlegenden Funktionen: Behandlung der An- und Abgehenden Nachrichten,
Verwaltung der Scopeinformationen und die Überprüfung der Mitgliedschaftsbedingungen. Es war noch nicht vorgesehen, dass dieses Modul von Anwendungen verwendet
wird. Daher existieren keine Methoden, um von auÿen einen Scope zu erzeugen, zu
löschen oder Nachrichten zu versenden. Zum Testen der Implementierung wurde ein
Timer im Scope-Modul verwendet, der in bestimmten Intervallen eine Nachricht auslöst und so den gesamten Lebenszyklus vom Erzeugen bis zum Entfernen eines Scopes
1
auf der beiliegenden CD enthalten
4.2.
20
BASISIMPLEMENTIERUNG
typedef struct
37
{
21
uint16_t
id ;
//
22
uint16_t
subscope ;
//
Subscope
//
Länge
//
Scopeeigenschaften
//
Id
int s p e c _ l e n ;
void ∗ s p e c ;
23
24
25
26
uint16_t
}
root_addr ;
Scope
d.
Id
der
Id
Scopeeigenschaften
Wurzelknotens
scope_creation_t ;
Listing 4.1: scope_creation Header
28
typedef struct
{
29
uint16_t
id ;
//
Scope
Id
30
uint16_t
root ;
//
Id
Wurzelknotens
//
Länge
//
Nutzdaten
int d a t a _ l e n ;
void ∗ d a t a ;
31
32
33
}
d.
der
Nutzdaten
scope_data_t ;
Listing 4.2: scope_data Header
35
typedef struct
36
37
38
}
{
uint16_t
id ;
//
Scope
Id
uint16_t
subscope ;
//
Subscope
Id
scope_removal_t ;
Listing 4.3: scope_removal Header
Tabelle 4.1: simple_scope Nachrichtenheader
durchläuft.
Das simple_scope -Modul kennt drei Phasen, die während der Lebensdauer eines Scopes durchlaufen werden. Die Scopeerzeugung, in der das Routing alle Informationen
sammelt, die es benötigt, um Nachrichten transportieren zu können. Danach folgt die
Phase der Datenübertragung, in der alle beteiligten Knoten Nachrichten an den Wurzelknoten bzw. an die Knoten im Scope versenden können. Am Schluÿ folgt dann noch
das Löschen des Scope, bei dem die Routinginformationen für diesen Scope und der
entsprechende Scope gelöscht werden.
Zu diesem Zweck wurden drei Nachrichtentypen implementiert: scope_creation, sco-
pe_data und scope_removal (siehe Tabelle 4.1). Durch diese Teilung können die Pakete
möglichst klein gehalten und so nur die nötigsten Daten versendet werden.
Empfängt ein Knoten nun eine scope_creation Nachricht, wird zuerst geprüft, ob der
Basisscope existiert und die Id des neuen Scopes nicht schon vergeben ist. Der Ba-
sisscope bezeichnet dabei den Scope, über den die aktuelle Nachricht versandt wurde.
Wenn der Knoten Mitglied im Basisscope ist und die Überprüfung der Mitgliedskriterien erfolgreich verläuft, wird der neue Scope angelegt. Ist dies nicht der Fall, wird zwar
38
11
KAPITEL 4.
typedef struct
uint16_t
supersid ;
//
Basisscope
uint16_t
root ;
//
Wurzelknoten
//
Mitgliedsstatus
13
14
15
bool
}
{
//
uint16_t
16
scope_table_t
sid ;
12
member ;
REALISIERUNG
Scope
Id
Id
Id
scope_table_t ;
Listing 4.4: Eintrag in der Scope Tabelle (simple_scope )
ein Eintrag für den Scope vorgenommen, aber es wird vermerkt, dass der Knoten kein
Mitglied in diesem Scope ist. Trit eine der Vorbedingungen nicht zu, wird das Paket
verworfen.
Soll ein Scope gelöscht werden, wird eine scope_removal Nachricht vom Wurzelknoten versendet. Dabei wird der Basisscope angegeben, über den die Nachricht versendet
wird und der zu löschende Scope. Jeder Empfänger prüft darauf hin, ob ihm der Scope
bekannt ist und löscht die betreenden Einträge. Beim Löschen eines Scopes werden
auch alle eingebetteten Subscopes gelöscht, da diese ohne ihren Basisscope nicht weiter
existieren können.
Ist die Erzeugung eines Scope abgeschlossen, können Nachrichten über diesen versendet
werden. Dies können Anwendungsdaten oder Daten zur Scopeverwaltung (Erzeugen/Löschen von Scopes) sein. Ein Knoten erkennt an der Art des Pakets, um welche Daten
es sich dabei handelt. scope_data Nachrichten enthalten anwedungsspezische und die
anderen beiden Pakettypen scopespezische Informationen. Wird nun ein Paket mit
Anwendungsdaten empfangen, so wird geprüft, ob der Scope bekannt und ob der Knoten ein Mitglied des Scopes ist. Ist dies der Fall könnten die enthaltenen Daten an eine
Anwendung weitergereicht und eventuell weiterversendet werden. Ansonsten wird das
Paket verworfen.
Zur Speicherung der Informationen über einen Scope hält jeder Knoten eine Tabelle, mit fester Gröÿe, vor. Pro Eintrag enthält die Tabelle die Id des Scope, die Id des
Basisscope, die Adresse des Wurzelknotens und den aktuellen Mitgliedsstatus, wie man
in Listing 4.4 sieht. Die Scope Id '0' ist für den globalen Scope world reserviert, der
alle Knoten eines Netzes enthält. Durch die Speicherung der Basisscope Id besteht die
Möglichkeit Subscopes anzulegen. Die Gröÿe der Scope-Tabelle ist ein Designparameter
und je nach Hardware und anderer Randbedingungen leicht einzustellen.
Die Prüfung, ob ein Knoten nun Mitglied eines Scopes wird oder nicht, ist in dieser Variante noch als einfache Funktion realisiert und macht die Mitgliedschaft eines Knotens
von seiner Adresse abhängig.
4.3.
ERWEITERTE IMPLEMENTIERUNG
39
4.2.2 Probleme
Die Basisimplementierung hat gezeigt, dass sich Scopes auf den aktuell verfügbaren
Sensorknoten implementieren lassen und hat einige Anhaltspunkte für die Weiterentwicklung des Scope-Moduls gegeben. Allerdings weist diese sehr einfache Variante noch
einige Probleme auf. Diese sind,
•
dass alle Nachrichten per Broadcast durch das gesamte Sensornetzwerk zu jedem
Knoten geutet werden.
•
dass die Tabelleneinträge der Scopes keine vorgegebene Lebensdauer besitzen,
sondern solange bestehen, wie sie nicht gelöscht werden.
•
dass ein neues Szenario auch neue Scopeeigenschaften mitbringen kann.
Die Verwendung des Flooding -Moduls bringt den Nachteil mit sich, dass durch das uten jeder Knoten, jede Nachricht bekommt. Egal, ob die Knoten einem Scope angehören
oder nicht. So kommt die Reduzierung der zu verschickenden Nachrichten, die einer der
Vorteile der Scopes sind, noch nicht zum Tragen.
Dadurch, dass die Einträge der Scopes nicht nach einer bestimmten Zeit automatisch
gelöscht werden, kann es zum einen passieren, dass ein Scope zwar gelöscht wurde, aber
die Nachricht auf dem Transportweg durch Störungen von auÿen so stark verändert
oder überlagert wird, dass sie von einem anderen Knoten nicht mehr verstanden werden kann. Dann existiert der Scope auf diesem Knoten weiter und ein späteres Erzeugen
eines neuen Scopes mit der gleichen Id und neuen Eigenschaften schlägt fehl. Zum anderen kann durch den Ausfall einiger Knoten das Sensornetz in mehrere Teile getrennt
werden und wiederum erreicht die scope_removal Nachricht nicht alle Knoten. Es entsteht das gleiche Problem wie eben, wenn das Netz wieder eine Verbindung herstellen
kann.
Neue Eigenschaften einers neuen Szenarios bringen insofern Probleme, dass für jede
neue Eigenschaft die Methode zur Überprüfung der Scopemitgliedschaft angepasst werden muss. So bedingt eine neue Eigenschaft auch ein neu angepasstes Scope-Modul.
Dieser Anpassungsaufwand sollte durch Scopes verringert werden.
4.3 Erweiterte Implementierung
In der erweiterten Version wurde das grundlegende Konzept der Basisversion beibehalten. Neben einem verbesserten Routing, wurde das simple_scope-Modul in mehrere
40
KAPITEL 4.
REALISIERUNG
Anwendung(en)
Scope Modul
Scope
membership
Routing (MHR)
Sensorknoten
Abbildung 4.1: Übersicht über Module der erweiterten Variante
einzel Module aufgegliedert, siehe Abbildung 4.1. Die Scopes wurden bis auf die erweiterten Scope Eigenschaften, wie dynamische Eigenschaften und die Sprache zur Scopespezizierung, implementiert, da diese separat vom Rest der Scopes in eigenen Modulen
implementiert werden können.
4.3.1 Aufbau
Die Trennung von Routing- und Scope-Modul wurde auch in der erweiterten Implementierung beibehalten und sogar noch vertieft (entsprechend Abbildung 4.1). In der
Basisversion besteht die Trennung zwischen Scopes und Routing aus der Trennung in
Module und damit der Beschränkung der Kommunikation auf den Aufruf einer Methode. In der erweiterten Version wird eine neue, separate Schnittstelle für die Anbindung
des Routings eingeführt, die von dem verwendeten Routing-Modul implementiert werden muss. So wird das Routing aus der Sicht des Scope-Moduls austauschbar und kann
verschiedenen Umweltbedingungen oder Anwendungen angepasst werden.
So stehen jetzt zwei Routing Module zur Verfügung. Einmal das an die neue Schnittstelle angepasste Flooding aus der Vorgängerversion und ein ezienteres, speziell für
Scopes angepasstes Multihop-Routing. Im, auf Directed Diusion und Gradient-basedRouting (siehe 2.3.2 und 2.3.3) aufbauenden, Multihop-Routing wird das Routing über
eine Multicast-Baumstruktur realisiert.
Das Scope-Modul wurde, wie in [39] beschrieben, weiter aufgesplittet und erweitert.
Somit erhält die Routine zur Prüfung der Scopezugehörigkeit ein eigenes Modul. Es
lassen sich so mit wenig Aufwand mehrere Module zur Zugehörigkeitsprüfung nutzen.
4.3.
ERWEITERTE IMPLEMENTIERUNG
4.3.1.1
41
Multihop-Routing
Im Multihop-Routing existieren vier Nachrichtentypen. Angelehnt an ihre Verwandten
aus Directed Diusion sind dies: Requests, Daten, Acknowledges und Rejects. Requests
haben eine ähnliche Funktion, wie Interests in Directed Diusion. Sie werden beim Erzeugen eines Scopes mit den Eigenschaften des neuen Scopes bestückt und durch das
Netz an alle Knoten ihres Basisscopes versendet. Da es bei Scopes nicht um Events
geht, sondern um die Zugehörigkeit zu einem Scope wurden Gradienten und Reinforcements komplett umgearbeitet und mussten einem einfachen Acknowledge/Reject
Mechanismus Platz machen. Gehört nun ein Knoten zu einem neuen Scope sendet er
ein Acknowledge an den Knoten mit den wenigsten Hops zum Wurzelknoten. Laufen
schon zu viele Verbindungen über diesen Knoten, kann er die neue Verbindung durch
ein Reject ablehnen. In dem Fall wird ein neues Acknowledge an den Knoten mit der
nächst kleineren Hopanzahl versendet. Ist der Aufbau des Routingbaums auf diese Weise beendet, können Daten von der Wurzel an alle Knoten im Scope versendet werden
und von den Knoten im Scope Nachrichten an die Wurzel. Das Entfernen eines Scopes
erfolgt über das Senden einer entsprechenden Nachricht.
Im Gegensatz zu den Scopes, bei denen es drei verschiedene Paketheader gibt, werden
beim Multihop-Routing nur zwei unterschieden. Nämlich zum einen Nachrichten, die
die Baumverwaltung betreen und zum anderen Nachrichten, die Daten transportieren. D.h. Requests, Acknowledges und Rejects nutzen den gleichen Nachrichtenheader
(path_message, siehe Tabelle 4.2), nur das Handling und eventuell angehängte Informationen unterscheiden sich. Nachrichten, die Anwendungsinformationen transportieren,
nutzen, egal in welche Richtung sie verschickt werden, einen gemeinsamen Header (da-
ta_header, siehe Tabelle 4.2). Die drei Nachrichten zum Anlegen des Routingbaums
wurden nicht in Unterschiedliche Header unterteilt, da sie zum einen sehr änhliche
Daten in ihrem Header benötigen. Zum anderen würde eine weitere Unterteilung nur
wenige Byte Gewinn bringen (nämlich 1-2 Byte), dafür die Übersichtlichkeit des ohnehin schon komplexen Codes weiter stark verringern.
Im Folgenden kommen einige Zeitintervalle, z.B. Intervalle, in denen Nachrichten nicht
weitergeleitet werden, oder zahlenmäÿige Begrenzungen, etwa eine maximale Anzahl
von Knoten in einer Liste, vor. Diese Parameter lassen sich an die Struktur des Sensornetzes und die Ansprüche der Anwendungen anpassen (vgl. Anhang C).
Requests und Acknowledges
Um einen Routingbaum für einen neuen Scope auf-
zubauen, wird auf dem Wurzelknoten vom Scope-Modul eine scope_creation Nachricht mit Informationen, wie Basisscope, neuer Scope Id und Scopeeigenschaften, an
das Routing-Modul versendet. Das Routing versendet darauf hin eine neue RequestNachricht mit den erhaltenen Informationen an sich selbst und startet damit die Verarbeitung des Requests. Die einzelnen Phasen des Routings sind an entsprechenden
Stellen sowohl als Pseudocode, wie auch als Message-Sequence-Chart (MSC) zur besseren Verständlichkeit dargestellt. In den MSCs werden drei Knoten dargestellt, die alle
in dem angenommenen Scope teilnehmen.
42
KAPITEL 4.
REALISIERUNG
msc MHR Scopeerzeugung
Knoten 1
Knoten 2
Knoten 3
1
2
3
REQ
S in
REQ
REQ
S in
ACK 0
ACK 6
REQ
S in
ACK 0
ACK 6
Abbildung 4.2: Routingbaumaufbau für einen Request. Knoten 1 ist der Wurzelknoten.
Sämtliche Requests werden hier als Broadcast versendet. S in ist der Eintritt in den
Scope. ACK 0 ist das Acknowledge für den world -Scope. ACK 6 ist das Acknowledge
des neuen Scopes.
4.3.
ERWEITERTE IMPLEMENTIERUNG
43
Algorithmus 1 Verarbeitung eines empfangenen Requests
Eingang: Ein Request wird empfangen
1: if Request hat einen Eintrag im Requestcache then
2: if Sender nicht in Vorgängerliste then
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
Füge Sender der Liste hinzu
else
Lasse Knoteninformation in der Liste altern
Aktualisiere Höhe des Senderknotens
end if
Aktualisiere Zeitstempel für Request und Request des Superscopes
else
Lege neuen Cacheeintrag für Request an
Füge Sender der Vorgängerliste hinzu
Aktualisiere Zeitstempel des Basisscope Requests
end if
if Request kein Duplikat und kein Request vor kurzem gesendet then
Erzeuge create_scope Nachricht aus Nutzdaten des Request
Sende neue Nachricht an lokales Scope Modul
Hole Liste der Nachfolgerknoten aus Cacheeintrag
if
Request nicht über den world -Scope versenden
then
Sende Request an jeden Knoten aus der Liste
else
Sende Request per Broadcast
end if
if Noch kein Acknowlege für den world -Scope versendet then
Sende Acknowledge world an Sender
end if
if Noch keine Daten über diesen Request erhalten then
Sende Acknowledge Request an Sender
end if
end if
44
69
KAPITEL 4.
typedef struct
//
Scope
uint8_t
subscope_id ;
//
Subscope
uint8_t
path_len ;
//
Pfadlänge
/ Höhe
uint8_t
data_len ;
//
Länge
Nutzdaten
uint8_t
71
72
73
}
{
scope_id ;
70
74
path_message_t
REALISIERUNG
Id
Id
der
path_message_t ;
Listing 4.5: path_message Header
79
typedef struct
data_header_t
80
uint8_t
81
uint16_t
82
uint16_t
bool
84
sos_pid_t
85
uint8_t
86
}
//
Ziel
snode ;
//
Sender
seqno ;
// Sequenznummer
dest_scope ;
83
{
send_to_root ;
dst_pid ;
dst_msg_type ;
Scope
Id
//
Senderichtung
//
Ziel
Prozess
//
Ziel
Nachrichten
Id
Typ
data_header_t ;
Listing 4.6: data_header
Tabelle 4.2: Multihop-Routing Nachrichtenheader
Um Requests überhaupt handhaben zu können hat jeder Knoten einen Requestcache.
Dieser hat eine einstellbare Obergrenze an Einträgen, je nachdem wie der Bedarf an
Speicher der anderen Anwendungen, die auf den Knoten laufen sollen, ist. In dem
Cache wird für jeden Routingbaum, der über diesen Knoten verläuft, ein Eintrag gespeichert. In den Einträgen werden unter anderem Scope id, Basisscope id, Vorgänger/Nachfolgerknoten, Zeitstempel, empfangene Daten und bei Wurzelknoten die Eigenschaften des zugehörigen Scopes gespeichert (siehe Listing 4.7). Die Liste der Vorgängerknoten enthält alle Knoten, von denen der aktuelle Knoten einen Request erhalten
hat. Im Gegensatz dazu stehen in der Nachfolgerliste alle Knoten von denen für den entsprechenden Scope ein Acknowledge empfangen wurde. Die Zeitstempel spalten sich in
drei Einträge auf. Es gibt jeweils einen für empfangene Request und Acknowledge Nachrichten und einen, der den Zeitstempel der letzten Nachricht über diesen Routingbaum
enthält. Dieser Zeitstempel kann von jeder Nachrichtenart stammen. Der Datencache
enthält Knoten Id und Sequesznummer der letzten empfangenen Nachrichten, um das
erneute Versenden einer Nachricht und damit Loops zu unterbinden. Neben den oben
genannten Einträgen gibt es noch einige weitere, die aber nur für die interne Verwaltung
der Informationen wichtig sind.
Wird nun ein Request empfangen (siehe Algorithmus 1), wird zuerst geprüft, ob im Requestcache schon ein Eintrag für den angegebenen Scope existiert. Ist dies nicht der Fall,
wird ein neuer Eintrag angelegt, die Daten für Scope, Basisscope usw. darin gespeichert.
Die Listen für Vorgänger- und Nachfolgerknoten, sowie der Datencache werden initialisiert. Der Sender der Requests wird in die Liste der Vorgängerknoten aufgenommen.
Nach dem Setzten der Zeitstempel im Eintrag wird dieser in den Cache eingefügt und
4.3.
76
ERWEITERTE IMPLEMENTIERUNG
typedef struct
request_cache_t
45
{
77
uint8_t
scope_id ;
//
Scope
78
uint8_t
super_id ;
//
Basisscope
79
bool
//
Ist
//
Vorgängerknotenliste
//
Position
//
Nachfolgerknotenliste
is_origin ;
struct
80
81
node_list_t
uint8_t
∗ prev_nodes ;
prev_pos_new ;
Id
dies
Id
die
in
Wurzel
Liste
82
struct
83
uint8_t
ack_pos_new ;
//
Position
84
uint32_t
timestamp ;
//
Nachrichten
Zeitstempel
85
uint32_t
ack_ts ;
//
Acknowledge
Zeitstempel
uint32_t
request_ts ;
86
node_list_t
∗ ack_nodes ;
in
//
Request
//
Datencache
Liste
Zeitstempel
87
struct
88
uint8_t
data_pos_new ;
// Pos .
89
uint8_t
status ;
//
Requeststatus
90
uint8_t
∗ spec ;
//
Eigenschaften
//
Länge
//
nächster
91
uint8_t
struct
92
93
}
data_cache_t
∗ dcache ;
spec_len ;
request_cache_t
∗ next ;
in
Datencache
der
d.
Scopes
Eigenschaften
Request
request_cache_t ;
Listing 4.7: Eintrag im Requestcache
die Zeitstempel für den Basisscope Request aktualisiert. Ist ein Eintrag vorhanden und
der Sender ist in der Vorgängerlist enthalten, werden seine Informationen aktualisiert
und neue Zeitstempel gesetzt. Ist der Sender allerdings noch nicht in der Liste wird er
hinzugefügt.
Hat der Knoten schon länger keinen Request mehr für diesen Scope versendet, wird der
empfangene Request weitergeleitet. Das path_len Feld, das die Anzahl der passierten
Knoten angiebt, wird um eins erhöht und es wird als erstes eine create_scope Nachricht
erstellt und an das lokale Scope-Modul gesendet. Dies geschieht mit allen Requests, da
diese Nachrichten im Scope-Modul dafür sorgen, dass die Zeitstempel für den entsprechenden Eintrag aktualisiert werden. Die Anzahl an Knoten, die von einer Nachricht
passiert wurden, die Höhe, wird als Gradient verwendet. Im Gegensatz zum Gradientbased Routing, im dem die Dierenz der eingenen Höhe und der Höhe des Nachbarn
den Gradienten der Verbindung ausmachen, vergleiche [37]. Danach wird der Request
über den Basisscope weiterverschickt. Ist der Basisscope der world Scope wird der Request per Flooding durch das gesamte Sensornetzwerk geschickt. Ist der Basisscope ein
anderer, wird der Request an jeden Knoten verschickt, der dem aktuellen Knoten ein
Acknowledge gesendet hat, und somit in der Nachfolgerliste aufgeführt ist. Ist der Request über den world Scope versendet worden, wird am Schluÿ noch ein Acknowledge an
den Sender geschickt, da jeder Knoten Mitglied des world Scope ist. Wurde über diesen
Request noch keine Daten versendet, wird für diesen Request auch ein Acknowledge
versendet. Das stellt sicher, das der Vorgängerknoten das Acknowledge auch enrhält.
Hat das Scope-Modul nun die Scopeeigenschaften geprüft und angenommen, dann wird
die Funktion scope_inserted(. . . ) aufgerufen. Damit wird dem Routing mitgeteilt, dass
46
KAPITEL 4.
REALISIERUNG
der Knoten Mitglied in diesem Scope ist und zukünftige Datenpakete an das ScopeModul weitergeleitet werden sollen. Gleichzeitig wird eine Acknowledge Nachricht für
diesen Scope erzeugt und an den Messagehandler des Routings versendet.
Algorithmus 2 Verarbeitung eines empfangenen Acknowledges
Eingang: Ein Acknowledge wird empfangen
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
Hole passenden Requestcacheeintrag
if
Sender nicht in der Nachfolgerliste
if
Platz in der Liste
then
then
Füge Sender mit Gradient und Zeitstempel hinzu
else
Sende Reject
end if
else
Aktualisiere Gradient des Senders
Aktualisiere Zeitstempel des Requests
end if
if kein
then
Duplikat und kein Acknowledge vor kurzem für diesen Request gesendet
13: Erhöhe path_len um 1
14: Hole Liste der Vorgängerknoten aus Requesteintrag
15: Versende Acknowledge über Knoten mit der geringsten Höhe
16: end if
Empfängt ein Knoten nun eine Acknowledge Nachricht (siehe Algorithmus 2), egal ob
lokal oder per Netzwerk, wird zuerst geprüft, ob der zugehörige Routingbaum für diesen
Scope bekannt ist. Ist dies nicht der Fall, wird die Nachricht verworfen. Anderenfalls
wird geprüft, ob der Knoten schon einmal ein Acknowlege von diesem Sender empfangen hat. In diesem Fall werden der Gradient für den Sender und der Zeitstempel
für Acknowledges im Cacheeintrag aktualisiert. Ist der Sender des Acknowledges noch
unbekannt, wird er in die Liste der Knoten, die ein Acknowledge geschickt haben, eingefügt und mit dem zugehörigen Gradienten gespeichert. Im Anschluÿ wird noch der
entsprechende Zeitstempel aktualisiert. Wurde, beim Versuch den Sender in die Liste
einzufügen, bemerkt, dass die Liste voll ist, so wird an den Sender ein Reject geschickt.
Das hat zur Folge, dass dieser sich an den Knoten mit dem nächst besten Gradienten
wendet.
Ist das Acknowledge ein Duplikat, d.h. die gleiche Nachricht wurde schon einmal verarbeitet, wird sie nur erneut versendet, falls noch keine Daten für den Scope eingetroen
sind. Dies stellt sicher, dass das Acknowledge bei dem Knoten gegenüber ankommt,
ansonsten ist der Messagehandler fertig. Ist das Acknowledge kein Duplikat, wird aus
der Liste der Vorgängerknoten der Knoten mit dem kleinsten Gradienten bestimmt und
das Acknowledge, mit erhöhtem Gradienten, an diesen Knoten weitergeleitet.
Sind alle Request und Acknowledge Nachrichten ausgetauscht, kann der Routingbaum
4.3.
ERWEITERTE IMPLEMENTIERUNG
47
zum Versenden von Nachrichten genutzt werden. Der Wurzelknoten eines Scope versendet periodisch immer wieder einen Request für seinen Scope, um die Zeitstempel des
Scopes, solange er nicht entfernt wurde, regelmäÿig zu erneuern und um zu gewährleisten, dass das gesamte Netz von den Requests erreicht worden ist. Denn Mechanissmen,
dass eine versendete Nachricht auch ankommt, wie bei TCP/IP, gibt es in drahtlosen
Sensornetzen nicht.
Findet kein regelmäÿiges Erneuern der Zeitstempel statt, kann es passieren, dass zu
viel Zeit zwischen zwei Nachrichten vergangen ist und die Gültigkeit der Einträge im
Requestcache abgelaufen ist. Diese werden dann entfernt. Mit der Folge, dass keine
Nachrichten für diesen Request mehr angenommen werden. Damit Knoten, bei denen
die scope_remove Nachricht nicht angekommen ist, keine ungültigen Daten vorhalten
und so unnütz ein erheblicher Teil des Speichers belegt wird, wird so verfahren.
Datentransfer
Ist der Routingbaum für einen Scope nach dem obigen Schema auf-
gebaut, können Anwendungen Nachrichten versenden. Welche, wie groÿ und wie häug
Nachrichten versendet werden ist abhängig von der jeweiligen Anwendung.
Soll eine Nachricht versendet werden, wird ein Paket mit den entsprechenden Daten
Algorithmus 3
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
Verarbeitung einer empfangenen Daten-Nachricht
Daten Nachricht empfangen
Hole entsprechenden Requestcacheeintrag
if
Noch kein Acknowlege für Request empfangen
then
Speichere Nachricht zwischen und probiere später nochmal
end if
Prüfe, ob Nachricht Duplikat und füge sie ggf. zu Datencache hinzu
Aktualisiere Zeitstempel des Request
if
Kein Duplikat
then
Setzte Request-Status auf 'Daten erhalten'
if
Nachricht an Wurzelknoten
then
Hole Liste der Vorgängerknoten aus Requesteintrag
Sende Nachricht an Knoten mit der geringsten Höhe
else
Hole Liste der Nachfolgerknoten
Sende Nachricht an alle Knoten aus der Liste
end if
if Nachricht an Scope und (Knoten in Scope oder Wurzelknoten des Scope) then
Sende Nutzdaten an lokales Scope-Modul
end if
end if
und Headerinformationen erstellt. Dieses wird dann wie bei Requests und Acknowledges
auch erst an den lokalen Messagehandler geschickt und von dort aus dann ins Sensornetzwerk weitergesendet.
48
KAPITEL 4.
REALISIERUNG
msc Datentransfer im Scope
Knoten 1
Knoten 2
Knoten 3
1
2
3
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
Abbildung 4.3: Datentransfer durch das Sensornetz. Der obere Teil zeigt den Transfer
von der Wurzel in den Scope. Der untere Teil zeigt den Transfer vom Scope zur Wurzel
(Hier sendet auch die Wurzel, Knoten 1, sich selbst eine Nachricht, da sie dem Scope
angehört).
4.3.
ERWEITERTE IMPLEMENTIERUNG
49
Empfängt ein Knoten nun eine Datennachricht (siehe Algorithmus 3), wird zuerst ein
passender Eintrag im Requestcache gesucht. Wird kein Eintrag gefunden, wird die Behandlung der Nachricht abgebrochen und das Paket verworfen. Wurde ein Eintrag gefunden, wird geprüft, ob für diesen Request schon ein Acknowledge empfangen wurde.
Ist dies nicht der Fall, wird die Nachricht zwischengespeichert und zu einem späteren
Zeitpunkt (standardmäÿig nach 2 Sekunden) erneut verarbeitet. Die Nachricht wird
nun mit dem Datencache abgeglichen. Für den Abgleich werden Knotenadresse und Sequenznummer der Pakete verglichen. Ist die Nachricht im Datencache enthalten, wird
die Verarbeitung wiederum abgebrochen, denn das Paket wurde dann schon einmal
verschickt. Ist das Paket nicht im Datencache wird es im Cache eingetragen und die
Zeitstempel für den zugehörigen Requestcache Eintrag aktualisiert. Ist nun sichergestellt, dass die Nachricht weiter versendet werden kann, wird der Status des Requests
neu gesetzt und dann geprüft, ob die Nachricht an die Knoten im Scope geht, oder ob
die Nachricht für den Wurzelknoten des Scope bestimmt ist. Dazu existiert im Nachrichtenheader das send_to_root -ag, das die Senderichtung vorgibt. Je nach Richtung wird
für die Bestimmung der nächsten Empfänger die Liste der Vorgängerknoten (für Nachrichten an den Wurzelknoten) oder die Lister der Nachfolgerknoten, (für Nachrichten
an die Knoten im Scope) aus dem Requestcacheeintrag genutzt. Bevor die Nachricht an
die Nachbarn des Knoten geht, wird noch geprüft, ob er selbst Mitglied des Scopes ist
und entsprechend die Nachricht lokal an das Scope-Modul weitergeleitet wird. Danach
wird die Nachricht, wenn sie an die Knoten des Scopes gerichtet ist, an alle Knoten aus
der Nachfolgerliste gesendet, da ja jeder dieser Knoten entweder selbst in dem Scope
enthalten ist oder Knoten hinter ihm. Ist die Nachricht an den Wurzelknoten gerichtet,
wird sie an den Knoten mit dem kleinsten Gradienten weitergeleitet und die Verarbeitung ist abgeschlossen.
Das Löschen eines Requests verläuft analog zum Versenden von Daten, vergleiche die
Abbildungen 4.3 und 4.4. In den Nutzdaten ist eine scope_removal Nachricht enthalten,
die dann an das lokale Scope-Modul weitergeleitet wird. Nach dem Löschen des Scope
wird die scope_removed(. . . ) Methode aufgerufen und dem Routing damit signalisiert,
dass der zugehörige Request ebenfalls gelöscht werden kann.
Rejects in groÿen Sensornetzen und Sonderbehandlungen
In besonders dich-
ten Netzen kann es leicht vorkommen, dass ein Knoten mehr Nachbarn hat, als er in
seinen Nachbarschaftslisten unterbekommt. Das ist besonders im Falle der Acknowledge Nachrichten fatal, denn wenn diese Nachricht von ihrem Empfänger aufgrund einer
zu vollen Liste verworfen wird, wird der Knoten, der die Nachricht gesendet hat von
den kommenden Nachrichten des Scopes abgeschnitten, obwohl er sein Interesse durch
den Acknowledge bekundet hatte. Um dieses Problem zu umgehen, wird eine Reject
Nachricht an den ursprünglichen Sender zurückgesandt und dieser kann sich an den
nächsten Nachbarn wenden.
Kommen neue Knoten zum Netz hinzu brauchen die im Netz vorhandenen Requests
nicht explizit ausgetauscht zu werden, da in gewissen Intervallen alle Requests neu ver-
50
KAPITEL 4.
msc Löschen eines Scopes
Knoten 1
Knoten 2
Knoten 3
1
2
3
DATA
DATA
S out
DATA
DATA
S out
DATA
S out
Abbildung 4.4: Löschen eines Scopes/Requests
REALISIERUNG
4.3.
56
ERWEITERTE IMPLEMENTIERUNG
typedef struct
{
id ;
//
uint16_t
subscope ;
//
Subscope
uint16_t
spec_len ;
//
Länge
57
uint16_t
58
59
60
}
51
Scope
Id
Id
der
Scopeeigenschaften
scope_creation_t ;
Listing 4.8: scope_creation Header
62
typedef struct
{
63
uint16_t
64
bool
int
65
66
}
//
id ;
to_root ;
data_len ;
Scope
Id
// An W u r z e l k n o t e n ?
//
Länge
der
Daten
scope_data_t ;
Listing 4.9: scope_data Header
68
typedef struct
{
69
uint16_t
id ;
//
Scope
70
uint16_t
subscope ;
//
Subscope
71
}
Id
Id
scope_removal_t ;
Listing 4.10: scope_removal Header
Tabelle 4.3: Scope-Modul Nachrichtenheader
sendet werden und so neue Knoten automatisch alle Requests übernehmen.
Problematischer ist das Verschwinden von Knoten aus dem Sensornetz, da diese sich
nicht aus dem Netz abmelden, sondern einfach abhanden kommen. Um solchen Knoten
auf die Schliche zu kommen ist für die Knotenlisten ein einfaches Altern der Gradienten
implementiert, die pro empfangener Nachricht um einen gewissen Betrag erhöht werden. Wird also über einen Zeitraum von einem Knoten keine Nachricht mehr empfangen
steigt sein Gradient kontinuierlich an und wird letztendlich aus der Liste entfernt.
4.3.1.2
Die Scope Module
Wie oben beschrieben besteht die Scope Schicht in der erweiterten Variante aus zwei
Modulen. Als Grundlage wurde das simple_scope Modul der Basisimplementierung
genommen und erweitert.
Als erstes wurden die Einträge der Scope-Tabelle überarbeitet, um einigen Änderungen Rechnung zu tragen (vergleiche Listing 4.11). Das Member-Feld, das eine Aussage
über die Zugehörigkeit eines Knotens zu einem Scope traf, wurde entfernt, da nur noch
Scopes eingetragen werden, zu denen der aktuelle Knoten gehört. Informationen über
52
50
KAPITEL 4.
typedef struct
scope_table_t
{
51
uint16_t
sid ;
//
52
uint16_t
supersid ;
//
Basisscope
53
bool
//
Wurzelknoten ?
54
uint32_t
//
Gültigkeitsdauer
55
}
is_root ;
leasetime ;
REALISIERUNG
Scope
Id
Id
des
Scope
scope_table_t ;
Listing 4.11: Eintrag in der Scopetabelle
Scopes zu denen der Knoten nicht gehört sind nur für das Routing interessant und daher
wurden diese Einträge dorthin ausgelagert. Der Eintrag für den Wurzelknoten wurde,
entsprechend [39], entfernt und dafür ein Flag aufgenommen, um sich merken zu können,
bei welchen Scopes der Knoten selbst Wurzelknoten ist. Es gibt auch noch ein neues
Feld in der Scope-Tabelle, nämlich das leasetime Feld, das, ähnlich der Zeitstempel im
Multihop-Routing, angibt wie lange der Scope noch gültig ist. Mit der Anpassung der
Scope-Tabelle gingen auch leichte Änderungen an den Scopenachrichten einher. Diese
sind aber minimal und beschränken sich auf Einträge über den Wurzelknoten des Scopes.
Das bisher verwendete Flooding wurde durch eine Schnittstelle von drei Methoden ersetzt, die es erlauben die verwendeten Routingalgorithmen leicht auszutauschen. Die
drei Methoden umfassen eine zum Versenden von Nachrichten und je eine, um das
Routing zu informieren, dass der Knoten in einem Scope Mitglied ist bzw. ein Scope
gelöscht wurde. Vom Routing muss dass Versenden von Nachrichten behandelt werden,
die anderen beiden Methoden müssen zwar bereitgestellt werden, aber ob sie mit den
Informationen etwas anfangen ist dann den Algorithmen überlassen.
So wird beim Multihop-Routing etwa, das lokale Zustellen von Nachrichten aus dem
Netz und das Entfernen von Routingeinträgen von den letzten beiden Methoden grundlegend beeinusst. Bei dem angepassten Flooding
2
hingegen, haben diese beiden Me-
thoden überhaupt keinen Einuss, da jede Nachricht an jeden Knoten geht.
Um eines der Design bedingten Probleme der Basisimplementierung zu entschärfen,
wurde die Prüfung der Scopemitgliedschaft in ein eigenes Modul ausgelagert. Die Überprüfung im scope_member Modul ist recht einfach gehalten: An eine Methode werden
die, bei der Scopeerzeugung empfangenen, Mitgliedschaftsbedingungen übergeben und
als Ergebnis liefert die Methode ein Wahr oder Falsch zurück.
In der Methode kann eine beliebig komplexe Verarbeitung ablaufen oder auch weitere
Module mit zusätzlichen Prüfungen aufgerufen werden. Die aktuelle Version beschränkt
sich auf zwei Eigenschaften und eine Liste, in der für jeden Knoten der Zustand der
Eigenschaft festgehalten ist. Dadurch, dass die Mitgliedschaftsbedingungen als unformatierter Datenblock an das scope_member Modul übergeben werden, kann jede Anwendung sein eigenes Format und damit auch jede benötigte Art von Eigenschaft selbst
2 Die Anpassung an dem Floodingalgorithmus beschränken sich auf die Addition der Schnittstellenmethoden.
4.3.
ERWEITERTE IMPLEMENTIERUNG
53
denieren bzw. mitbringen, was zu einer hohen Flexibilität führt.
Zum Beispiel ist es leicht Möglich die aktuelle Version des scope_member Moduls soweit
zu ändern, dass neue Eigenschaften und Prüfroutinen über zusätzliche Module eingebunden werden können.
Da die Basisvariante noch nicht für die Verwendung mit Anwendungen konzipiert war,
hatte sie auch noch keine Möglichkeiten Nachrichten von Anwendungen entgegen zu
nehmen und zu versenden. Dies wurde jetzt nachgeholt, die neue Version des ScopeModuls beinhaltet drei Methoden: Je eine zum Erstellen und Löschen von Scopes und
zum Datentransport. Die zur Simulation und zum Testen verwendeten Teile des alten
simple_scope wurden in ein neues Modul (scope_tester ) ausgegliedert und bilden so
die erste (Test-)Anwendung.
4.3.2 Verbesserungen
Als erstes wurden die Probleme der Basisvariante behoben. So wurde das Flooding
durch das oben beschriebene Multihop-Routing ersetzt, das für den Nachrichtentransport einen Multicastbaum verwendet. Um den Scopes eine Lebensdauer zu geben wurden jedem Scope eine Leasetime zugeordnet, nach deren Ablauf der Scope ungültig
und damit gelöscht wird. Damit neue Anwendungen auch neue Eigenschaften mitbringen können, oder generell die Eigenschaften von Scopes während der Laufzeit erweitert
werden können, wurde die Prüfung der Eigenschaften auf ein eigenes Modul ausgelagert, das dann gegebenenfalls separat aktualisiert werden kann.
Das Multihop-Routing wurde noch für die alte Speicherverwaltung geschrieben (siehe 3.3). Daher wurde, um Speicher zu sparen, nur für die einzelnen Routingeinträge
eine verlinkte Liste verwendet. Für die Tabellen der Vorgänger-, Nachfolgerknoten und
dem Datencache wurden Ringpuer verwendet. So werden nur die ältesten Einträge
überschrieben. Die Funktion der Ringpuer der Vorgänger- und Nachfolgerknoten wurde etwas erweitert, um neue Knoten solange aufzunehmen, bis der Puer voll ist. Sollen
weitere Knoten aufgenommen werden, wird das innerhalb eines bestimmten Intervalls
abgelehnt und wie oben beschrieben das Senden eines Rejects ausgelöst. Dieses Verhalten ermöglicht es, die Routinginformationen bei jedem Aurischen eines Requestcacheeintrags zu erneuern und doch nur die schnellsten Knoten in die Listen aufzunehmen.
Ein wichtiger Punkt im Umgang mit beschränkten Ressourcen, wie dem Speicher, ist
neben einer sparsamen Allokierung, auch eine penible Verwaltung des Speichers, damit
dieser nach der Nutzung wieder frei gegeben werden kann. Da es in SOS synchrone
und asynchrone Zugrispfade gibt (vergleiche Abschnitt 3.3) muss hier ab und zu getrickst werden, um keinen Speicher zu verlieren. Die synchrone Speichernutzung ist
die gebräuchlichste Form. Im Modul wird an einer Stelle Speicher allokiert und an einer
anderen Stelle wieder freigegeben. Die asynchrone Nutzung läuft über die ankom-
54
KAPITEL 4.
REALISIERUNG
menden oder abgehenden Nachrichten und ihren angehängten Nutzdaten. SOS sieht
hier zwar die Möglichkeit vor, durch das abgeben der Rechte an dem entsprechenden
Speicherbereich, diesen nach dem versenden der Nachricht automatisch wieder freizugeben. Problematisch wird es aber, wenn beim Versenden von mehreren Nachrichten
mit den gleichen Nutzdaten, da ein Referenz-Zähler fehlt. Wird eine vorher bekannte
Anzahl an Nachrichten versendet, kann durch die in SOS integrierte priority queue zur
Nachrichtenverarbeitung, der eben beschriebene Mechanismus verwendet werden. Ist
aber im Vorhinein nicht klar wie viele Nachrichten versendet werden müssen, wie im
Multihop-Routing beim Versenden der Daten-Nachrichten, dann können Nachrichten
in der Queue sein und gleichzeitig muÿ der verbliebene Speicherblock freigegeben werden, da keine weiteren Nachrichten mehr versendet werden sollen. Um dieses potentielle
Speicherleck zu umgehen musste ein Workaround implementiert werden. Hier wird eine
zusätzliche Nachricht, an das lokale Multihop Routing Modul, gesendet, um die empfangenen Nutzdaten gefahrlos freigeben zu können. Durch die priority queue sind alle
anderen Nachrichten bereits versandt worden.
Kapitel 5
Simulation eines Drahtlosen
Sensornetzes
5.1 Einführung
Zum Test des Codes dieser Arbeit wurde hauptsächlich der Simulationsmodus des SOS
Betriebssystems genutzt. Um einen Überblick über das Verhalten in einem realen
drahtlosen Sensornetzwerk und den Energieverbrauch zu erhalten, wurde gegen Ende
der Entwicklung verstärkt Avrora eingesetzt, da mit diesem Simulator eine realistischere
Simulation möglich ist. Allerdings sind beide Programme in aktiver Entwicklung und
so kam es mehrfach zu sehr unangenehmen Überraschungen.
Im Folgenden werden die Simulationsumgebungen mit ihren Vor- und Nachteilen näher erläutert. Danach werden dann in Abschnitt 5.3 die vorgenommenen Simulationen
vorgestellt und in Abschnitt 5.4 ausgewertet.
5.2 Simulationsumgebung
Die Umgebung in der die Simulationen liefen, war die gleiche, die schon in Kapitel 4.1
beschrieben wurde. Benutzt wurden Avrora und SOS in den dort angegebenen Versionen.
55
56
KAPITEL 5.
SIMULATION EINES DRAHTLOSEN SENSORNETZES
5.2.1 SOS-native
Mit dem SOS Betriebssystem wird eine einfache, aber zur Überprüfung des programmierten Codes sehr sinnvolle, Simulationsmöglichkeit mitgeliefert. Der für SOS Module
geschriebene C-Code kann einfach per make -target als ausführbare Binärdatei kompiliert und auf dem PC direkt gestartet werden. Dazu kommt noch die Möglichkeit mit
Debuggern, wie etwa gdb, die Ausführung überwachen zu können und die Möglichkeit
einfacher Textausgaben. Zum Starten und Beenden der Simulation sind Skripte vorhanden, die die einzelnen Knoten mit den entsprechenden Knoten Ids aufrufen und wieder
beenden. Leider werden Änderungen an den LEDs nicht auf der Konsole ausgegeben.
Damit die einzelnen Knoten untereinander kommunizieren können, werden Nachrichten, die auf den Sensorknoten per Funk versendet worden wären, auf dem PC per UDP
und Loopback-Interface zwischen den einzelnen Instanzen des Knotenprogramms ausgetauscht.
Dies hat sich im Laufe der Entwicklung als kleines Problem herausgestellt. Denn die
Anzahl der gleichzeitig versendeten Nachrichten, die dann auch zugestellt werden, ist
abhängig von der Prozessorkapazität. Bei dem hier verwendeten System lag die Obergrenze an gleichzeitig simulierbaren Sensorknoten ohne Verlust von Nachrichten bei ca.
60. Für das Simulieren von groÿen Sensornetzwerken wird also entweder ein Leistungsstarker Rechner benötigt oder man verwendet besser einen separaten Simulator, wie
etwas Avrora, für den SOS auch direkte Unterstützung mitbringt. In Form eines weiteren make -targets.
Für die Sicherstellung des korrekten Verhaltens eines Moduls ist diese Simulation mit
ihren Debug-Möglichkeiten und dem in kleinen simulierten Sensornetzen verlustfreien Nachrichten Transport optimal. Als eine realistische Simulation eines Sensornetzes
taugt sie allerdings nicht, denn in der Realität ist gerade der drahtlose Transport von
Nachrichten anfällig für Störungen und damit Verlust von Nachrichten. Auch ohne
Umwelteinüsse können sich zwei Sensorknoten gegenseitig so stören, dass Nachrichten
verloren gehen. Z.B. wenn beide anfangen zu senden und sich ihre Nachrichten dabei
überlagern. Des Weiteren kann auch über den Energieverbrauch keine Aussage getroen
werden, was in separaten Simulatoren, wie Avrora, möglich ist.
5.2.2 Avrora
Avrora
1
wurde wie das SOS Betriebssystem von der UCLA entwickelt, allerdings von
einer anderen Gruppe, und bendet sich ebenfalls in aktiver Weiterentwicklung. Der
Simulator ist in Java geschrieben und kann so auf vielen Plattformen eingesetzt werden. Er nutzt zur Simulation das für den Sensorknoten erzeugte Image oder die Ausgabe
von avr-objdump (das disassemblierte Image). Dabei unterstützt er nicht nur die von den
Mica-Motes bekannten Atmel-Prozessoren (avr ), sonder auch msp430 er (siehe [43]).
Avrora simuliert auf Instruktionsebene. Da er direkt Maschinencode ausführt, kann
1
http://compilers.cs.ucla.edu/avrora/
5.3.
SIMULATIONEN
57
Avrora jedes Programm, das für die entsprechenden Mikroprozessoren erzeugt wurde, simulieren und ist so unabhängig von der verwendeten Programmiersprache oder
dem verwendeten Betriebssystem. Die einzelnen Knoten werden nach [41] als separater
Thread ausgeführt, die sich bei Bedarf synchronisieren. Die Synchronisierung wird nur
benötigt, um das globale Timing und die Reihenfolge der versendeten Nachrichten sicherzustellen. Die eziente Ausführung der Anwendungen wird durch eine Event-Queue
geregelt. Damit ermöglicht Avrora das simulieren von Sensornetzwerken mit mehreren
hundert oder gar tausend Knoten. Mit dem in Avrora integrierten Energiemodell sind
Leistungsproling und eine Lebensdauervorhersage für Sensornetzwerke möglich. [41]
Die Simulation in Avrora ist schon um einiges näher an der Realität, als mit dem nativen Modus in SOS. Neben den oben genannten Vorteilen ist in Avrora auch eine
einfache Implementierung des Transportmediums Luft integriert, die z.B. sich überlagernde Nachrichten per XOR verknüpft. Somit können diese Nachrichten von den
Empfangenen Knoten nicht mehr korrekt verarbeitet werden (zumindest im Überlappungsbereich). Ein Nachteil von Avrora sind die geringen Ausgaben zum Debugging.
Zwar hat es eine Debuggingschnittstelle für den gdb, diese ist allerdings nur im Simulationsmodus für einen einzelnen Knoten nutzbar.
5.3 Simulationen
Beide oben vorgestellten Simulationsmöglichkeiten werden im Folgenden verwendet. Die
Simulation mittels SOS ndet auf Nachrichten-Ebene statt und mit Avrora wird der
komplette Sensorknoten im Sensornetzwerk simuliert.
Für Simulationen wird in SOS eine Topologie Datei mitgeliefert, die die Positionen der
einzelnen Knoten vorgibt. Sie verteilt über einen Bereich von 10 mal 10 Einheiten bis
zu 100 Sensorknoten. Die Verteilung der Knoten ist sehr gleichförmig, so dass bei einer
Simulation mit 10 oder auch 80 Knoten die Fläche immer möglichst ausgenutzt wird.
So können dann auch Simulationen in dünn besiedelten und sehr dichten Sensornetzen
vorgenommen werden. In Abbildung 5.1 ist das Sensorfeld mit dem hier verwendeten
Maximum von 70 Knoten abgebildet.
Für die Simulationen kann also bei wechselnden Scope-Mitgliedschaften und unterschiedlicher Anzahl von Knoten, die an einer Simulation teilnehmen, eine groÿe Anzahl
von verschiedenen Szenarien abgedeckt werden.
Um für die Auswertung vergleichbare Informationen zu erhalten, wurden die Scopeeigenschaften für die folgenden Simulationen nicht verändert. Die Knoten, die zu den
Scopes gehören sind über das gesamte Netz verteilt, wie man in Abbildung 5.2 sehen
kann. Die Knoten, die zum simulierten Scope gehören, bewegen sich zwischen den Id's 0
und 20. Somit ändert sich die Gröÿe des Scopes bei Netzen mit 20 bis 70 Knoten nicht.
Neben der Simulationen mit SOS wurde die Topologie auf Avrora übertragen, um
die gleichen Simulationen zum Vergleich durchführen zu können. Durch die erweiterten
Möglichkeiten von Avrora können hier auch Aussagen über Energieverbrauch und Rechenzeit der einzelnen Knoten getroen werden.
58
KAPITEL 5.
SIMULATION EINES DRAHTLOSEN SENSORNETZES
10
44
1
28 24
13
19
9
16
65
8
12 23 15
7
69
18
31
66
5
8
4
62
49
2
59
6
21
43
52
5
29
70
33 54
20
34
56
7
0
6
53
48
4
46
30
50
32
3
55
47
22
3
14
42
36
649
57
2667
51 25
38
27
39
2
68
41
10
60
35
40
1
63
61
11
17
0
58
0
1
2
3
45
4
37
5
6
7
8
Abbildung 5.1: Simuliertes Sensorfeld
9
10
5.3.
SIMULATIONEN
59
10
28 24
1
13
19
9
16
65
8
12 23 15
7
69
18
31
66
5
8
4
62
49
2
59
6
21
29
33 54
43
52
5
20
56
7
0
6
34
53
48
4
46
30
50
32
3
55
47
22
3
14
42
36
649
57
2667
2
51 25
38
27
39
68
41
10
60
35
40
1
63
61
11
17
0
58
0
1
2
3
45
4
37
5
6
7
8
9
10
Abbildung 5.2: Beispiel eines Routingbaums mit zugehörigem Scope (fett umrandet,
Knoten 44 zur besseren Übersicht ausgeblendet)
60
KAPITEL 5.
SIMULATION EINES DRAHTLOSEN SENSORNETZES
Die durchgeführten Simulationen wurden mit der erweiterten Version der Scopes (siehe
Abschnitt 4.3) vorgenommen. Als Routingalgorithmen wurden sowohl Flooding, wie
auch das Multihop Routing verwendet. Das Multihop Routing wurde noch in zwei verschiedenen Varianten simuliert, einmal mit einer Requesterneuerung alle 5 Sekunden
und einmal ganz ohne Requesterneuerung. Bei Avrora lieÿ sich das Requestintervall
leider nicht über die Simulationszeit hinweg erweitern. So konnte hier eine einzelne Requesterneuerung nicht verhindert werden. Daher sind die Werte für die Simulation mit
Avrora leicht erhöht in Bezug auf die Anzahl der Pakete und damit auch bei Rechenzeit
und Energieverbrauch.
Um ein möglichst gleiches Verhalten in alles Simulationen zu erreichen, wurde, wie oben
schon erwähnt, die Simulation über das Modul scope_tester per Timer gesteuert. In fast
alles Simulationen wurde dieser Timer auf ein Intervall von einer Sekunde eingestellt.
Das Modul simuliert das Erzeugen eines Scopes. Danach werden 250 Byte Nutzdaten
an den Scope gesendet und nach kurzem weitere 250 Byte von jedem Knoten im Scope
an den Wurzelknoten zurück gesendet. Als letztes wird der Scope wieder gelöscht.
Für die Simulation der geschachtelten Scopes wurde diese Simulation nur leicht verändert. Es werden beide Scopes erzeugt und statt 250 Byte an oder aus dem Scope
zu senden, werden 100 Byte an bzw. aus den ersten Scope und 150 Byte an bzw. aus
dem geschachtelten Scope gesendet. Im Endeekt also gleiche Mengen, nur dass der
geschachtelte Scope weniger Mitglieder hat als der erste und sich somit die Menge der
versendeten Nachrichten verringern sollte. Am Schluss werden auch hier beide Scopes
gelöscht.
5.4 Auswertung der gesammelten Daten
5.4.1 Simulation auf Nachrichtenebene
Die erste Simulation in Abbildung 5.3 sollte klären, wie ezient Multihop Routing gegenüber dem Floodingalgorithmus ist. Wie man in der Grak sehr schön sieht, steigt
das Nachrichtenaufkommen bei der Verwendung von Flooding mit der Zahl an Knoten
im Sensornetzwerk sehr steil an. Multihop Routing kann, mit und ohne regelmäÿigem
erneuern der Requests, die Anzahl der versendeten Nachrichten vergleichsweise gering
halten. Wie vorhin schon angesprochen kann man bei den Werten für die Sensornetze
mit weniger als 20 Knoten sehen, wie stark die Anzahl der versendeten Pakete auch
von der Gröÿe des Scopes abhängt. Bei konstanter Gröÿe des Scope (ab 20 Knoten im
Sensornetz) bleibt der Aufwand für das Versenden der Daten relativ gleich. Durch die
Vergröÿerung des Netzes erhöht sich allerdings der Aufwand für den Aufbau und Erhalt
der Routingstrukturen, deshalb steigert sich auch oberhalb dieser Gröÿe des Netzes die
Anzahl der versendeten Nachrichten linear. Im Graphen für das Multihop Routing ohne
Erneuerung der Requests ist der Erneuerungsfaktor ausgeschlossen und die Steigerung
5.4.
AUSWERTUNG DER GESAMMELTEN DATEN
61
3000
flooding
Multihop-Routing (5sec refresh)
Multihop-Routing (no refresh)
Insgesamt versendete Nachrichten
2500
2000
1500
1000
500
0
0
10
20
30
40
Anz. Knoten im Sensornetzwerk
50
60
70
Abbildung 5.3: Anzahl der versendeten Pakete bei unterschiedlichen Gröÿen des Netzwerks
ergibt sich nur noch aus dem ebenfalls erhöhten Aufwand für das Anlegen des Scopes.
Da im Multihop Routing für das Erneuern der Routinginformationen, zumindest im
world -Scope, die Nachrichten geooded werden, ist zu klären, ab wann das erneuern
seiner Routingstrukturen mehr Nachrichten in Anspruch nimmt, als das Flooding der
Nutzdaten. In der Simulation, von konstant 50 Knoten, wurde eine Erneuerungsfrequenz
von 5 Sekunden im Multihop Routing eingestellt, wie auch schon in der vorherigen Simulation. Durch das Verlängern des Sendeintervalls des scope_tester -Moduls wird die
Datendichte über den Simulationszeitraum kontinuierlich gesenkt. Wie in Abbildung 5.4
zu sehen ist, ist das Multihop Routing solange noch ezienter bei der Anzahl der versendeten Nachrichten im Gegensatz zum Flooding, solange Nahrichten häuger versendet
werden, wie die Requests erneuert werden. Dies bedeutet, dass zeitnahe Aufgaben bzw.
Tasks mit hohem Nachrichten aufkommen eektiv transportiert werden können. Hingegen auf lange Schlafzeiten angelegte Tasks einen hohen Overhead verursachen. Beim,
auf Directed Diusion basierenden, Multihop Routing war dieses Verhalten zu erwarten, da die Requestverteilung fast unverändert aus Directd Diusion (vergleiche [24])
stammt.
Zur Simulation von verschachtelten Scopes wurde, wie in Abschnitt 5.3 schon beschrieben, ein neuer Scope in den, aus den vorherigen Simulationen, bestehenden Scope
eingebettet. In Abbildung 5.5 sind, neben den Zahlen aus der ersten Simulation für
62
KAPITEL 5.
SIMULATION EINES DRAHTLOSEN SENSORNETZES
3500
flooding
Multihop-Routing (5sec refresh)
Insgesamt versendete Nachrichten
3000
2500
2000
1500
1000
500
0
2
4
6
Sendeintervall (Sekunden)
8
10
Abbildung 5.4: Simulation von 50 Knoten mit variablem Sendeinterval in scope_tester
5.4.
AUSWERTUNG DER GESAMMELTEN DATEN
63
800
Multihop-Routing
Multihop-Routing (2 Scopes)
Insgesamt versendete Nachrichten
700
600
500
400
300
200
100
0
0
10
20
30
40
Anz. Knoten im Sensornetzwerk
50
60
70
Abbildung 5.5: Simulation von zwei verschachtelten Scopes
einen Scope, die versendeten Nachrichten für die beiden verschachtelten Scopes abgebildet. Dadurch, dass der zweite Scope weniger Mitglieder hat, ist die Anzahl der
versendeten Pakete generell geringer, als die Werte der ersten Simulation mit einem
Scope. Desweiteren kann man an der gleichbleibenden Dierenz zwischen den beiden
Kurven sehen, dass die Gröÿe des Sensornetzes keinen Einuÿ auf den Aufwand zum
Anlegen von Subscopes hat, wenn der Ursprungsscope gleich groÿ bleibt.
5.4.2 Simulation auf Instruktionsebene
Um Aussagen über benötigte Rechenzeit und den Energieverbrauch treen zu können,
wurden die weiteren Simulationen in Avrora durchgeführt. Es wurden wieder Scopes mit
Flooding, Multihop Routing und Multihop Routing ohne Requesterneuerung simuliert.
Da Avrora auch das Transportmedium Luft simuliert kommt es mit steigender Zahl an
Nachrichten, auch zu stark steigenden Verlusten von Nachrichten. Ein direkter Vergleich
der Anzahl versandter Nachrichten ndet sich in Abbildung 5.6. In zwei Simulationen
die hier in Avrora gemacht wurden, liegen die versendeten Nachrichten über denen der
SOS Simulation. Dies resultiert aus unterschiedlichen Timings der beiden Simulationen. In diesen zwei Avrora Simulationen wurden kurz vor dem Löschen des Scopes noch
64
KAPITEL 5.
SIMULATION EINES DRAHTLOSEN SENSORNETZES
3000
flooding
Multihop-Routing (5sec refresh)
Multihop-Routing (no refresh)
Avrora flooding
Avrora Multihop-Routing (5sec refresh)
Avrora Multihop-Routing (no refresh)
Insgesamt versendete Nachrichten
2500
2000
1500
1000
500
0
0
10
20
30
40
Anz. Knoten im Sensornetzwerk
50
60
70
Abbildung 5.6: Vergleich versendeter Packete in Avrora und der SOS-Simulation
eine Requesterneuerung gestartet. Da bei jedem Erneuern jeder Knoten einen Request
sendet sind jeweils soviele Nachrichten wie Knoten im Sensornetzvorhanden sind zuviel.
Da das Multihop Routing keine Verteilung der Nachrichten vornimmt, sondern immer
in der aufgebauen Baumstruktur bleibt, gibt es sowohl beim Energieverbrauch (Abbildung 5.8), wie auch bei der Rechenzeit (Abbildung 5.7) Knoten die viel beschäftigt sind
und Knoten, die wenig zu tun haben. Die vielbeschäftigten Knoten liegen hierbei entweder auf dem Pfad zu einem Scope oder in einem Scope. Die Knoten, die kaum etwas
zu tun haben, liegen auÿerhalb des Scope. Auf den ersten Blick scheint eine ähnliche
Streuung bei Verwendung des Flooding als Falsch, aber da beim Flooding viele Pakete
verloren gehen, haben die Knoten, die näher an der Wurzel eines Scope liegen mehr zu
tun, als Knoten, die am Rand des Sensornetzes, weit weg vom Wurzelknoten liegen.
In beiden Graken sind die Minimum und Maximum Werte für den Rechenzeit- und
Energieverbrauch dargestellt. Der errechnete Durchschnitt wurde über alle im Netzwerk vorhandenen Knoten erhoben. Bei der Simulation des Multihop Routing ohne
Requesterneuerung, ist bei 30 Knoten einer der Sensorknoten aus der Art geschlagen
und nicht mehr in den Sleepmodus gewechselt. Da Avrora kaum Überwachungsmöglichkeiten während der Simulation bietet, konnte nicht geklärt werden wodurch dieser
Ausschlag zustande kam. In den Graken liegen dann beide Verfahren sehr eng beieinander, allerdings mit einem kleinen Vorsprung für das Multihop Routing.
5.4.
AUSWERTUNG DER GESAMMELTEN DATEN
65
110000
flooding
Multihop-Routing (5sec refresh)
Multihop-Routing (no refresh)
Rechenzeit (TZyklen)
Simulationszeit: 442.368 TZyklen
100000
90000
80000
70000
60000
50000
40000
30000
0
10
20
30
40
50
Anz. Knoten im Sensornetzwerk
60
70
80
Abbildung 5.7: Benötigte Rechenzeit der Sensorknoten bei unterschiedlichen Gröÿen
des Netzwerks
5.4.3 Fazit
Im Endeekt lässt sich sagen, dass Scopes auf heutigen Sensorknoten durchaus einsetzbar sind. Allerdings hat sich bei der Durchführung der Simulationen gezeigt, dass
Scopes einiges an Speicher benötigen, um Scopes und Routinginformationen zu verwalten. Zudem müssen je nach Anwedung das Request-Erneuerungs-Intervall und die
Leasetime passend gewählt werden.
Neben den Vorteilen, die Scopes mit ihrer Funktionalität bieten, hat das Multihop Routing die Vorteile weniger Nachrichten zu versenden. Damit treten weniger Verluste in
den realeren Simulationen von Avrora auf und der Energieverbrauch, wie auch die Rechenzeit liegen im Durchschnitt unter denen der Flooding-Simulationen.
66
KAPITEL 5.
SIMULATION EINES DRAHTLOSEN SENSORNETZES
2.54
flooding
Multihop-Routing (5sec refresh)
Multihop-Routing (no refresh)
2.52
2.5
Energieverbrauch (Joule)
2.48
2.46
2.44
2.42
2.4
2.38
2.36
2.34
0
10
20
30
40
50
Anz. Knoten im Sensornetzwerk
60
70
80
Abbildung 5.8: Benötigte Energie der Sensorknoten bei unterschiedlichen Gröÿen des
Netzwerks
Kapitel 6
Zusammenfassung und Ausblick
6.1 Umgesetzte Anforderungen
Diese Arbeit sollte die Realisierbarkeit von Scopes unter Berücksichtigung der Kapazitäten aktueller Sensorknoten-Hardware prüfen. Dazu wurden die in [39] beschriebenen
Scopes umgesetzt und mit Multihop Routing ein geeignetes Routingverfahren entworfen.
Zu Beginn wurde eine einfache Variante der Scopes entwickelt, die die grundlegenden
Funktionen der Scopes enthielt. Mit ihr konnte die generelle Machbarkeit demonstriert
werden. Allerdings war diese Variante für Anwendungen noch ungeeignet.
In einer zweiten Phase wurde die einfache Scope Variante rund um verbessert. Das Routing wurde durch eine Schnitstelle ersetzt, so dass das Routing austauschbar wurde. In
einem späteren Schritt wurde das Flooding dann durch das Multihop Routing ersetzt.
Die Mitgliedschaftsprüfung von Scopes wurde in ein separates Modul ausgegliedert, um
ein nachträgliches Ändern der Eigenschaften zu ermöglichen. Desweiteren wurden nach
der Spezikation der Scopes Zeitstempel in der Scopeverwaltung eingefügt, die einen
Zeitraum beschreiben, in dem die Scopeinformationen gültig sind. Zuguterletzt wurden
noch Methoden eingefügt und Anpassungen vorgenommen, damit Anwendungen Nachrichten über die Scopes versenden und empfangen können.
Nachdem das Multihop Routing so weit war, dass es das Flooding ersetzen konnte,
wurde das neue Routing ausgiebig getestet und auf seine korrekte Funktion geprüft.
Dies war ein sehr zeitintensiver Prozess. Doch wie man in Kapitel 5.4 sieht lieÿ sich das
Nachrichtenvolumen im Vergleich zu Flooding drastisch senken.
Mit dem neuen Multihop Routing ist es möglich vom Wurzelknoten eines Scopes aus
Nachrichten an alle Knoten des Scopes zu schicken und von einem Knoten aus dem
Scope eine Nachricht an den Wurzelknoten wieder zurück zu senden. Dazu wird beim
Anlegen des Scopes ein Multicastbaum aufgebaut, der Informationen für das Routing
in beide Richtungen beinhaltet.
67
68
KAPITEL 6.
ZUSAMMENFASSUNG UND AUSBLICK
Mit der Funktionsfähigkeit des Routings und der Scope-Module konnte mit den Simulationen begonnen werden. Am Ende stand dann die Erkenntnis, dass Scopes auf
heutigen Sensorknoten durchaus einsetztbar sind. Allerdings verhindert besonders der
beschränkte RAM noch ein Ausschöpfen der Möglichkeiten von Scopes. Denn neben
den Anwendungen, benötigen auch die Scopes selbst einen groÿen Teil des Speichers für
das Routing und die Verwaltung der Scopes.
Insgesamt kann festgehalten werden, dass das entwickelte Routing einen Groÿteil an
Nachrichten gegenüber Flooding einspart. Es skaliert sehr gut mit steigender Anzahl
von Knoten. Durch die geringere Anzahl an Nachrichten gegenüber Flooding halten sich
die Verluste in der Avrora Simulation in Grenzen. Durch den erhöhten Verwaltungsaufwand des Routings kann zwar keine drastische Einsparung an Energie und Rechenzeit
gemessen werden, allerdings bleibt das Multihop Routing noch unter den Werten des
Flooding.
6.2 Oene Probleme und Verbesserungsmöglichkeiten
Ein oener Punkt bei der Umsetzung von Scopes sind dynamische Eigenschaften. Sie
sind sehr komplex zu realisieren und verlangen nach mehr Speicher, da auch Informationen für Scopes gespeichert werden müssen, in denen der lokale Knoten (noch)
kein Mitglied ist. Desweiteren wurde zwar keine dezidierte Spezikationssprache für
Scopes entworfen, allerdings lässt sich ein ähnliches Verhalten in C leicht durch entsprechend benannte Konstanten in den Eigenschaftsmodulen erreichen. Das ist in dem
hier verwendeten Modul (scope_membership ) bereits geschehen. Zwar kann so über den
Eigenschaftsnamen kein Modul zur Auswertung der Eigenschaften ausgewählt werden,
da das Format der Eingenschaftsdaten frei ist, lieÿe sich dieses Verhalten nachbilden.
Das auf Basis von Directed Diusion und Gradient-based Routing entwickelte Multihop Routing verwendet wie auch Directed Diusion in [24] Flooding, um einen neuen
Scope im world -Scope anzulegen. Des weiteren werden auch die folgenden Requesterneuerungen mittels Flooding ausgeführt. Dieses Verhalten lieÿe sich durch ein geeigneteres Routingverfahren noch verbessern und damit weitere Nachrichten einsparen.
Zwar werden doppelte Nachrichten des Routings und der Scopes nicht weiter versendet, aber das bezieht sich nicht auf die Nutzdaten. Um nun die Menge an Nutzdaten
zu verringern, könnte man ein Aggregationsverfahren in das Routing integrieren. Da
Aggregation aber stark von der Art der Nutzdaten und damit der Anwendung abhängt,
ist es fraglich, ob eine solche Optimierung generisch möglich ist.
Verbesserungen des bestehenden Routings könnten durch eine bessere Wahl des RequestErneuerungs-Intervalls erreicht werden. Hier wäre eine dynamische Berechnung des Intervalls wünschenswert. Denn bei Veränderungen der Umweltbedingungen (etwa bei
starkem Regen) könnte durch die dynamische Anpassung des Intervalls die Zuverlässig-
6.2.
OFFENE PROBLEME UND VERBESSERUNGSMÖGLICHKEITEN
69
keit des Routings erhöht werden.
In der aktuellen Implementierung werden Nachrichten im Scope an jeden Nachbarn
separat per Unicast versendet. Eine andere Möglichkeit wäre, den Versand per Broadcast durchzuführen und jeden Nachbarn für sich entscheiden zu lassen, ob die jeweilige
Nachricht für ihn interessant ist. Dies verringert zwar den Aufwand beim Versenden,
dafür müssen mehr Knoten die Nachricht empfangen und verarbeiten. So verschiebt
sich der Energie-/Rechenzeitverbrauch vom Sender auf die Nachbarknoten des Senders.
Um die Möglichkeiten des Routings zu verbessern, könnte die Mitgliedschaftsbedingungen der Scopes als zusätzliche Informationsquelle dienen. So könnte das Routing auf
Positionsdaten zurückgreifen, die dann ein geographisches Routing ermöglichen.
In den Simulationen zu dieser Arbeit, wurden die Module der erweiterten Implementierung in zwei Umgebungen getestet. Einer, auf Nachrichten bezogen, Verlust freien
Umgebung und einer mit Verlust von Nachrichten. Dieser Verlust kommt durch die
Simulation des Transportmediums Luft zustande, da es passieren kann, dass sich zwei
oder mehr Nachrichten überlagern. Dazu wurden allerdings immer statische Sensornetze verwendet. Ohne äuÿere Störungen, Mobilität von Knoten, Hinzukommen von neuen
oder auch Ausfall von vorhandenen Knoten. Zwar sind Mechanismen zur Behandlung
dieser Vorkommnisse vorhanden, diese wären aber noch zu untersuchen. Auch die Einüsse auf die Ezienz wären hier interessant.
70
KAPITEL 6.
ZUSAMMENFASSUNG UND AUSBLICK
Anhang A
Material auf der CD
A.1 Inhalt
Auf der beiliegenden CD sind sämtliche für diese Arbeit erstellten Programme, Skripte
und Dateien enthalten. Dies umfasst unter anderem, die für die Scopes entwickelten
SOS-Module, die Skripte und Programme zur Visualisierung, die verwendeten Sourcen
für Avrora und das SOS Betriebssystem, sowie die Quellen für diese Ausarbeitung.
A.1.1 CD Hauptverzeichnis
Archive
Enthält alles in verschiedenen Archiven
avrora
Enthält avrora
sos-1.x
Enthält sos v1.x
text
Enthält alles Sourchen der Ausarbeitung dieser Arbeit
tud
Enthält alle in dieser Arbeit entwickelten Skripte, Programme
A.1.2 tud/modules
Dieses Verzeichnis enthält alle SOS Module, die implementiert wurden.
71
72
ANHANG A. MATERIAL AUF DER CD
ood_routing
Flodding für das scope Modul
multihop_routing
Multihor Routing für das scope Modul
scope
Erweiterte Scope Implementierung
scope_member
Scopeeigenschaftsauswertung für das scope Modul
scope_tester
(Test-)Applikation für das scope Modul
scope_tester_mult (Test-)Applikation für geschachtelte Scopes
simple_scope
Basisimplementierung der Scopes
A.1.3 tud/contrib
Dieses Verzeichnis enthält einige Visualisierungs Programme/Skripte für die erweiterte
Scopes Implementierung.
Java
Enthält eine Java-Visualisierung für SOS Simulationen der er-
sim2animation
Erzeugt aus einer Simulation ein Tex-Dokument
sim2tex
Erzeugt aus einer Simulation ein Tex-MSC
weterten Scopes Implementierung
topo2tex
Erzeugt eine Tex-Grak aus der SOS-Topologie Datei
topo2topo
Erzeugt aus einer SOS-Topologie Datei eine Avrora-Topologie
Datei
Anhang B
Einrichten der Arbeitsumgebung
B.1 Einführung
In diesem Abschnitt wird die Einrichtung der Arbeitsumgebung dieser Arbeit beschrieben. Dies soll einen einfachen und schnellen Start für eventuelle Weiterentwicklungen
gewährleisten. Für die einzelnen Aufgaben verwendete Programme sind in Abschnitt 4.1
aufgeführt. Die Meisten von ihnen bedürfen keiner besonderen Behandlung und können
über die entsprechende Linux-Distribution oder die Webseite des Programms bezogen
werden. Auf die Kernbestandteile SOS Betriebssystem und den in dieser Arbeit erzeugten CVS-Baum werde ich im Folgenden näher eingehen.
B.2 SOS Betriebssystem
Wird eine aktualisierte Version von SOS verwendet, als die in dieser Arbeit verwendete,
sollte die Website des Projekts für eventuelle Änderungen der Einrichtung überprüft
werden.
Das SOS Betriebsystem kann über die Website des Projekts
1
oder von der beiliegenden
CD bezogen werden. Ist das Archiv entpackt muss eine Umgebungsvariable gesetzt
werden, die angibt, wo SOS sich bendet. Diese Variable nennt sich SOSROOT:
#~> export SOSROOT=~/sos-1.x
Dies ist nötig, um die Simulationsmöglichkeiten von SOS zu nutzen. Um sich die Simulation zu vereinfachen sind im
1
$SOSROOT/tools/admin Verzeichnis zwei Scripte enthalten,
http://nesl.ee.ucla.edu/projects/SOS/
73
74
ANHANG B.
EINRICHTEN DER ARBEITSUMGEBUNG
sim.sh und end_sim.sh. Um diese Scripte nutzen zu können sollte dieses Verszeichnis
zum Systempfad hinzugeführt werden:
#~> export PATH=$PATH:$SOSROOT/tools/admin
Im SOS Verzeichnis gibt es mehrere Unterverzeichnisse. In kernel, platform, prozessor
und driver sind die Kernkomponenten des Betriebssystems enthalten. modules enthält
mitgelieferte Beispielmodule für Routing, Tests und mehr. In cong sind Kongurationen für verschiedene Images vorhanden, mit denen die Sensorknoten mit dem Betriebssystem und Modulen bestückt werden können. In den Verzeichnissen contrib und tools
sind einige hilfreiche Skripte und Programme zusammengefasst.
Über make können Images für verschiedene Zwecke erzeugt werden. Neben Images für
verschiedene Prozessoren und Platformen (wie zum Beispiel die mica2 Platform), können auch Images für die Simulation unter Linux oder auch avrora erzeugt werden. Für
die Simulation unter Linux (auf der simulierten mica2 Platform):
#~/sos-1.x/config/blink> make sim EMU_PLATFORM=mica2
Für die Simulation unter Avrora:
#~/sos-1.x/config/blink> make avrora
Nachdem ein Image für die Simulation unter Linux erstellt wurde kann mit den Skripten sim.sh die Simulation gestartet und mit end_sim.sh wieder beendet werden. Der
Aufruf von sim.sh erwartet als Parameter das zu simulierende Image, die Id des ersten
Sensorknotens und die Anzahl an Knoten.
#~/sos-1.x/config/blink> sim.sh ./blink_app.exe 0 10
... Simulation ...
#~/sos-1.x/config/blink> end_sim.sh
Ist ein Image für avrora erstellt worden, kann Avrora entweder die *.elf Datei direkt,
oder die disassemblierte Datei *.od, simuliert werden. Dabei ist das simulieren der *.od
Datei zu bevorzugen, da Avrora hier die Id der simulierten Knoten automatisch festlegen kann.
Für weitere Möglichkeiten von SOS sind auf der Website einige Tutorials, Dokumentationen und eine FAQ zu nden.
B.3.
CVS-BAUM DIESER ARBEIT
75
B.3 CVS-Baum dieser Arbeit
Um nun den CVS-Baum dieser Arbeit mit SOS nutzen zu können, entpackt man ihn
von der CD in das SOS Hauptverzeichnis. Dabei wird ein neues Verzeichnis mit dem
Namen tud angelegt. In diesem Verzeichnis muÿ noch ein Symbolischer Link auf das
tools Verzeichnis von SOS erzeugt werden, falls dieser nicht schon existiert.
#~/sos-1.x/tud> ln -s ../tools
Dieser Link wird beim erzeugen der in den Unterverzeichnissen enthaltenen Images und
Modulen benötigt. Damit ist die Einrichtung auch schon komplett. Die Namen der Unterverzeichnisse orientieren sich an denen der SOS Distribution. Das apps Verzeichnis
weicht als einziges ab und enthält die Konguration für Images die noch auf SOS 0.8
basieren. Die neuen Images können also wie oben beschrieben erzeugt und simuliert
werden.
76
ANHANG B.
EINRICHTEN DER ARBEITSUMGEBUNG
Anhang C
Moduldiagramme und -variablen
In diesem Anhang werden Diagramme der einzelnen Module der erweiterten Implementierung gezeigt. Falls der Code dieser Arbeit einmal weiter verwendet wird, können diese
Diagramme zur besseren Übersicht über die einzelnen Module, ihre Sourcedateien und
die Zugrie untereinander beitragen.
C.1
scope_tester -Modul
scope_tester
scope
Modul
- module(void *state, Message *msg):int8_t
C.2
scope_member -Modul
scope
Modul
Indicator
Meaning
0..1
Zero or one
1
0..*
1..*
scope_member
One only
- module(void
*state, Message *msg):int8_t
0 or
more
+ check_scope_membership(func_cb_ptr p, uint16_t len, void *spec): bool
0..n
1 or more Buy SmartDraw !- purchased copies print this
Only n (where n > 1) document without a watermark .
Visit
www .smartdraw .com or call 1-800-768-3729.
Zero to n (where
n >1)
1..n
One to n (where n > 1)
n
77
78
ANHANG C.
MODULDIAGRAMME UND -VARIABLEN
scope -Modul
C.3
scope_member
scope_tester
scope_table
+ scopes: scope_table_t*
scope
+ init_scope_table(): void
+ is_scope_known(uint16_t sid): bool
+ get_scope_entry(uint16_t sid): scope_table_t*
+ insert_scope(uint16_t sid, uint16_t ssid, bool is_root): bool
+ remove_scope(uint16_t sid): bool
+ clear_table_timeouts(): void
+ renew_lease(uint16_t sid): void
+ send_scope_create(...): void
+ send_scope_data(...): void
+ send_scope_remove(...): void
scope_routing
<<interface>>
+ scope_send_data(...): bool
+ scope_inserted(uint16_t scope): void
+ scope_removed(uint16_t scope): void
Routing
Indicator
Meaning
Im scope-Modul sind folgende Konstanten enthalten:
Datei
Name
scope.c
ROUTING_PID
1
scope_table.h
MAX_SCOPES
0..1
0..*
Zero
or one
Beschreibung
Modul
One
only
Id des verwendeten Routingmoduls
Maximale Anzahl an Scopes in der Scope0 or more
table
STD_LEASE_TIME
Standard
Gültigkeitsdauer eines Scopes
1..*
1 or
more
n
Only n (where n > 1)
0..n
Zero to n (where n
>1) Buy
1..n
SmartDraw !- purchased copies print this
watermark .
call 1-800-768-3729.
document without a
One to n (where n >
1)Visit www .smartdraw .com or
C.4.
MULTIHOP_ROUTING-MODUL
C.4
79
multihop_routing -Modul
data_cache
<<type>>
scope
Modul
request_cache
+ init_request_cache(): void
+ free_request_cache(): void
+ remove_request(request_cache_t *prev, request_cache_t *request_pos): bool
+ get_known_request_entry(uint16_t scope_id): request_cache_t*
+ is_node_in_list(node_list_t *l, uint16_t node): node_list_t*
+ insert_request(Message *m): request_cache_t*
+ insert_ack(Message *m): request_cache_t*
+ insert_data(Message *m): bool
+ get_request_prev_list(request_cache_t *ientry): node_list_t*
+ get_request_ack_list(request_cache_t *ientry): node_list_t*
+ get_next_request(request_cache_t *pos): request_cache_t*
+ cleanup(uint32_t timestamp):void
+ find_smallest_gradient(node_list_t *l): node_list_t*
+ has_my_ack(node_list_t *l): bool
+ find_gradient(node_list_t *l, int smallest): node_list_t*
+ insert_new_node(request_cache_t *entry, node_list_t *list,
uint16_t node_id, uint16_t gradient): node_list_t*
+ free_node_cache(request_cache_t *entry, node_list_t *list): void
+ remove_node_from_list(node_list_t *l, uint16_t node): void
multihop_routing
Im multihop_routing-Modul sind folgende Konstanten enthalten:
Datei
Name
Beschreibung
multihop_routing.c
RESEND_TIMEOUT
Indicator
Meaning
0..1
Zero or one
FORWARD_TIMEOUT
1
One only
0..*
0 or more
1..*
1 or more
Zeitintervall nach dem ein
Request erneuert wird
Zeitintervall in dem keine
Requests für den gleichen
Buy SmartDraw !- purchased
copies print this
Scope versendet
werden
n
Only n (where n > 1)
document without a watermark .
0..n
Zero to n (where n >1)
DATA_RETRY_TIMEOUT
diesem
Zeitintervall
Visit www .smartdraw Nach
.com or call
1-800-768-3729.
1..n
One to n (where n > 1)
wird erneut versucht zwischengespeicherte daten zu
versenden
request_cache.h
MAX_REQUESTS
Maximale Anzahl an Einträgen im Requestcache
MAX_CLIENTS
Maximale Anzahl an Einträgen
in
den
Vorgänger-
und Nachfolgerlisten
MAX_DATA
Maximale Anzahl an Einträgen im Datencache
request_cache.c
NODE_INFO_AGING
Wert, um den ein Gradien
pro Durchlauf altert
80
ANHANG C.
MODULDIAGRAMME UND -VARIABLEN
Literaturverzeichnis
[1]
Adjie-Winoto,
William ;
Schwartz,
Elliot ;
Balakrishnan,
Hari ;
Lilley,
Jeremy: The Design and Implementation of an Intentional Naming System. In: Pro-
ceedings of ACM Symposium on Operating Systems Principles (SOSP '99) Bd. 34.
Charleston, SC, Dezember 1999, 186201
[2]
Akkaya,
Kemal ;
Younis,
Mohamed: A Survey on Routing Protocols for Wireless
Sensor Networks. 2003. [3]
Akyildiz,
Ian F. ;
Su,
Weilian ;
Sankarasubramaniam,
Yogesh ;
Cayirci,
Erdal: Wireless sensor networks: a survey. In: Computer Networks 38 (2002), S.
393422
[4]
Berkeley WEBS: Home of Wireless embeded systems.
Website.
cs.berkeley.edu/
[5]
Brösel,
Joe: Kapazität von Batterien. HIFI-Forum.
de/viewthread-42-70.html.
[6]
Coffin,
Daniel A. ;
http://webs.
http://www.hifi-forum.
Version: Mai 2005
Van Hook,
Daniel J. ;
McGary,
Stephen M. ;
Kolek,
Ste-
phen R.: Declarative ad-hoc sensor networking. In: Proceedings of SPIE Integrated
Command Environments. San Diego, California, July 2000
[7]
Cordeiro,
Carlos de Morais ;
Gossain,
Hrishikesh ;
Agrawal,
Dharma P.:
Multicast over Wireless Mobile Ad Hoc Networks: Present and Future Directions.
In: IEEE Network 17 (2003), Januar/Februar, Nr. 1, S. 29
[8]
Crossbow Technology, Inc.: Crossbow Technology - Wireless Sensor Networks. Website.
[9]
[10]
http://www.xbow.com/
Crossbow Technology, Inc.: Mica2 Datasheet.
Crossbow
Technology,
Inc.:
Mica
http://www.xbow.com, 2002
Product
Feature
Reference.
http://www.xbow.com, 2005
[11]
Culler,
David E. ;
Mulder,
Hans: Kollektive Intelligenz der Kleinstcomputer.
In: Spektrum der Wissenschaft 10 (2004), Oktober, S. 8693
81
82
[12]
LITERATURVERZEICHNIS
Deering,
Steve: Multicast Routing in a Datagram Network. Palo Alto, California,
Stanford University, Ph.D. thesis, December 1997
[13]
Elson,
Jeremy ;
Estrin,
Deborah: Random, Ephemeral Transaction Identiers
in Dynamic Sensor Networks. In: Proceedings of the 21st International Conference
on Distributed Computing Systems. Phoenix, Arizona, USA, April 2001
[14]
Embedded Networks and Applications Lab, Yale University: The XYZ
Website. Website.
[15]
Estrin,
http://www.eng.yale.edu/enalab/xyz/
Deborah ;
Govindan,
Ramesh ;
Heidemann,
John ;
Kumar,
Satish:
Next Century Challenges: Scalable Coordination in Sensor Networks. In: Procee-
dings of the 5th annual ACM/IEEE international conference on Mobile Computing
and Networking (MobiCom '99). Seattle, WA, August 1999, S. 263270
[16]
Fiege, Ludger ; Mezini, Mira ; Mühl, Gero ; Buchmann, Alejandro P.: Engineering Event-based Systems with Scopes. In: Magnusson, B. (Hrsg.): Proceedings
of the European Conference on Object-Oriented Programming (ECOOP'02) Bd.
2374. Springer-Verlag, 309333
[17] Fraunhofer-Institut für Mikroelektronische Schaltungen und Systeme:
Infoblatt
Drahtlose Sensornetze
[18]
Gossain,
Hrishikesh ;
Cordeiro,
Carlos de Morais ;
Agrawal,
Dharma: Mul-
ticast: Wired to Wireless. In: IEEE Communications Magazine 40 (2002), June,
Nr. 6, S. 116123
[19]
Thomas:
Sensornetworks.
http://www.informatik.
uni-mannheim.de/~haensel/sn_book/sensor_networks.pdf.
Version: April
Haenselmann,
2006. [20]
Han, Chih-Chieh ; Rengaswamy, Ram K. ; Shea, Roy ; Kohler, Eddie ; Srivastava, Mani: A dynamic operating system for sensor networks. In: Proceedings
of the 3rd International Conference on Mobile Systems, Applications, And Services
(Mobisys '05), ACM Press, 2005
[21]
Han,
Simon ;
Rengaswamy,
Ram K.: SOS-User Mailinglist: [Sos-user] New mal-
http://nesl.ee.ucla.edu/pipermail/sos-user/
2006-February/thread.html. Version: Februar 2006
loc implementation. Website.
[22] Institute of Electrical and Electronics Engineers:
IEEE Computer Society LAN
MAN Standards Committee. Wireless LAN Medium Access Control (MAC) and
Physical Layer (PHY) Specications. IEEE Std 802.11-1997. 1997
[23]
Intanagonwiwat,
Chalermek ;
Govindan,
Ramesh ;
Estrin,
Deborah: Direc-
ted Diusion: A Scalable and Robust Communication Paradigm for Sensor Networks.
In: Proceedings of the Sixth Annual International Conference on Mobile
Computing and Networking (MobiCOM '00), 2000
LITERATURVERZEICHNIS
[24]
83
Intanagonwiwat, Chalermek ; Govindan, Ramesh ; Estrin, Deborah ; Heidemann, John ; Silva, Fabio: Directed Diusion for Wireless Sensor Networking.
In: IEEE/ACM transactions on networking 11 (2003), Februar, Nr. 1, S. 216
[25]
Intel Corporation: Intel Mote - Sensor Nets / RFID.
Website.
intel.com/research/exploratory/motes.htm
[26]
Ko,
Young-Bae ;
Vaidya,
Nitin H.:
http://www.
Location-Aided Routing (LAR) in mobile
ad hoc networks. In: Proceedings of the Fourth Annual ACM/IEEE International
Conference on Mobile Computing and Networking (MobiCOM '98). Dallas, Texas,
1998, S. 6675
[27]
[28]
Kreymborg,
http://www.
Ron: A Doubly Linked Memory Manager. Website.
jennaron.com.au/avr/DoublyLinkedMemory.html.
Version: November 2005
Lee,
Mario ;
Sung-Ju ;
Su,
William ;
Hsu,
Julian ;
Gerla,
Bagrodia,
Rajive:
A Performance Comparison Study of Ad Hoc Wireless Multicast Protocols.
In:
INFOCOM (2), 565574
[29]
Mattern,
Friedemann ;
Römer,
Kay:
Drahtlose Sensornetze.
In: Informatik
Spektrum 26 (2003), Juni, Nr. 3, S. 191194
[30]
mcc@wir4:
(R-)Evolution von der Natur lernen! In: mcc@wir4 mobile com-
munication cluster wir4.print special Juni 2005 (2005), Juni, Nr. 6, S. 812
[31]
Moteiv Corporation: moteiv: wireless sensor networks.
Website.
moteiv.com/
[32]
[33]
http://www.
Networked and Embedded Systems Lab (NESL) at UCLA: SOS operating
system. Website.
http://nesl.ee.ucla.edu/projects/SOS/.
Newton,
Welsh,
Ryan ;
03.05.2006
Matt: Region Streams: Functional Macroprogramming
for Sensor Networks. In: Proceedings of the First Workshop on Data Management
for Sensor Networks (DMSN 2004). Toronto, Canada, August 2004
[34]
Polastre,
Joseph R.: Design and Implementation of Wireless Sensor Networks
for Habitat Monitoring, University of California at Berkeley, Research Project,
2003.
http://www.cs.berkeley.edu/~polastre/papers/masters.pdf.
Elek-
tronische Ressource
[35]
Polastre,
Joseph R.:
Hotchips 2004: Mote table. Website.
berkeley.edu/papers/hotchips-2004-mote-table.pdf.
[36]
Römer,
Kay ;
Frank,
Christian ;
Marron,
11th ACM SIGOPS European Workshop.
712
Version: Juli 2004
Pedro Jose ;
Generic Role Assignment for Wireless Sensor Networks.
http://webs.cs.
Becker,
Christian:
In: Proceedings of the
Leuven, Belgium, September 2004, S.
84
[37]
LITERATURVERZEICHNIS
Schurgers,
Curt ;
Srivastava,
Mani B.:
Energy ecient routing in wireless
sensor networks. In: MILCOM Proceedings on Communication for Network-Centric
Operations: Creating the Information Force. McLean, VA, 2001
[38]
Steffan,
Jan ;
Fiege,
Ludger ;
Cilia,
Mariano ;
Buchmann,
ping in wireless sensor networks: A position paper.
Alejandro P.: Sco-
In: Proceedings of the 2nd
Workshop on Middleware for Pervasive and Ad-hoc Computing, ACM Press, Oktober 2004, S. 167171
[39]
Steffan,
Jan ;
Fiege,
Ludger ;
Cilia,
Mariano ;
Buchmann,
Alejandro P.: To-
wards Multi-Purpose Wireless Sensor Networks. In: Systems Communications 2005
(ICW / ICHSN / ICMCS / SENET 2005). Montreal, Canada : IEEE Computer
Society, August 2005, S. 336341
[40]
The Bluetooth Special Interest Group: Bluetooth V1.0b Specication.
http://www.bluetooth.com/, 1999
[41]
Titzer,
Ben L. ;
Lee,
Daniel ;
Palsberg,
Jens: Avrora: Scalable Sensor Network
Simulation with Precise Timing. In: Proceedings of IPSN'05, Fourth International
Conference on Information Processing in Sensor Networks. Los Angeles, 2005
[42]
UC Berkeley:
TinyOS Community Forum.
Website.
berkeley.edu/tos/
[43]
[44]
http://webs.cs.
UCLA Compilers Group: Avrora: The AVR Simulation and Analysis Framework. Website.
http://compilers.cs.ucla.edu/avrora/
Welsh,
Mainland,
Regions.
Matt ;
Geo: Programming Sensor Networks Using Abstract
In: Proceedings of the rst USENIX/ACM Symposium on Networked
Systems Design and Implementation (NSDI '04), 2004, S. 2942
[45]
Whitehouse,
Kamin ;
Sharp,
Cory ;
Brewer,
Eric ;
Culler,
David: Hood:
A Neighborhood Abstraction for Sensor Networks. In: MobiSYS '04: Proceedings
of the 2nd international conference on Mobile systems, applications and services.
Boston, Massachusetts, USA, Juni 2004, S. 99100
[46]
Yu,
Yan ;
Govindan,
Ramesh ;
Estrin,
Deborah:
Geographical and Energy
Aware Routing: a recursive data dissemination protocol for wireless sensor networks
/ University of California. Los Angeles, August 2001 (UCLA/CSD-TR-01-0023).
Forschungsbericht