Forschungsbericht fur das Fach¨ Sensornetzewiki_sn/images/c/c0/...Sofern das Symbol DEBUG LED deﬁniert ist, wird nach dem booten von Contiki die erste LED angeschaltet. Diese wird

Hochschule für Technik und Wirtschaft Dresden

Fakultät für Mathematik/Informatik

Forschungsbericht für das FachSensornetze

im Master-Studiengang Angewandte Informationstechnologien,Studienrichtung Intelligente Informations- und

Kommunikationstechnologien

Thema:Gruppe 1

eingereicht von: Andreas Salwasser

eingereicht am: 29. Juni 2015

Betreuer: Prof. Dr.-Ing. Jörg Vogt

Inhaltsverzeichnis

1 Support für USB, LEDs und Buttons 11.1 USB-Kommunikation mit Host-PC . . . . . . . . . . . . . . . . . . . . . 11.2 Ansteuerung LEDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Verwendung Buttons . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Conditional Observe 42.1 Button . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3 Test für Langzeitstabilität 5

4 Messung von RSSI-Werten 6

5 Beheben einer endlosen Reboot-Schleife bei Aktivierung externangeschlossener Sensoren 8

6 Unterstützung für Onboard-I2C-Sensoren 9

7 Untersuchung von Contikimac und Stromverbrauch des Radiomodules 107.1 Messungen mit 8-MHz-Clock . . . . . . . . . . . . . . . . . . . . . . . 117.2 Messungen mit 16-MHz-Clock . . . . . . . . . . . . . . . . . . . . . . . 13

8 Untersuchung Konfiguration Parameter für RPL 15

Literaturverzeichnis 18

i

Abbildungsverzeichnis

4.1 RSSI-Werte in Abhängigkeit zur Entfernung . . . . . . . . . . . . . . . . 6

7.1 Messung Timings für 8 MHz . . . . . . . . . . . . . . . . . . . . . . . . 117.2 Messung Spannungsverlauf für 8 MHz . . . . . . . . . . . . . . . . . . . 127.3 Messung Timings für 16 MHz . . . . . . . . . . . . . . . . . . . . . . . 137.4 Messung Spannungsverlauf für 16 MHz . . . . . . . . . . . . . . . . . . 13

ii

1 Support für USB, LEDs undButtons

Aufgabe: Die Kommunikation des Boards mit einem PC soll über USB ermöglichtwerden, um ein einfaches Logging für Debugging-Zwecke zu ermöglichen. Desweiterensollen die LEDs sowie die Buttons über CoAP per get bzw set gesetzt bzw. abgefragtwerden.

Lösung: Der Quellcode für den nativen Support der aufgeführten Komponentendes deRFnode-Boards wurde aus den Beispielprogrammen der dresden elektronikngenieurtechnik gmbh für ihre Boards Sensor Terminal Board, deRFnode/deRFgatewayentnommen, vgl. [2]. An diesem Quellcode wurden alle Codesegmente entfernt, die fürdie Ausführung auf anderen Boards bestimmt waren.

1.1 USB-Kommunikation mit Host-PC

Das USB-Interface für die AVR-Variante verwendet einen FTDI-Chip. DieUSB-Schnittstelle verwendet die gleichen Pins, wie die zweite serielle SchnittstelleRS232 PORT 1, daher darf diese nicht verwendet werden. [9] Die USB-Kommunikationwird durch den Aufruf der Funktion usb io init() initialisiert, ihr Aufruf istdurch eine Abfrage umschlossen, ob eine Spannung am USB-Port vorhanden ist.Sofern dies nicht der Fall ist, wird die USB-Schnittstelle auch nicht initialisiert.Die Initialisierungsfunktion setzt die Standard-Datenströme stdout und stdin,daher können regulär die C-Funktionen für jegliche Ein- und Ausgabe über dieUSB-Verbindung verwendet werden.

Sofern der Sensorknoten per USB angeschlossen ist, kann man nun seineDebug-Ausgaben mitverfolgen. Dafür sind die folgenden Schritte notwendig: Zu aller erstmuss das Kernel-Modul ftdi sio geladen werden, war root-Rechte benötigt. Dies erfolgtmit der Eingabe von:modprobe ftdi_sio

Anschließend kann der Sensorknoten dem Kernel-Modul bekannt gemacht werden.Dafür muss die Vendor-ID und Product-ID (durch dmesg herausfindbar) in einebestimmte Datei ge-’echo’-ed werden. Für die deRFnode-Boards ist die Vendor-ID 1cf1und die Prodkct-ID 001d. Der Aufruf von echo sieht dabei folgenderweise aus:echo 1cf1 001d > /sys/bus/usb-serial/drivers/ftdi_sio/new_id

Abschließend kann dem Sensorknoten durch ein einfaches cat gelauscht werden (indiesem Beispiel wurde der Sensorknoten unter /dev/ttyUSB1 eingehängt):

1

cat /dev/ttyUSB1

Um die Debug-Ausgaben über USB zu aktivieren, muss in der Dateiproject/coap-sensornode/project.conf das Marko DEBUG USB definiert werden.Sollte dies geschehen sein und die USB-Verbindung nicht ausgelesen werden, blockiertder Mikrocontroller bis man die Verbindung auch tatsächlich ausliest.

Der Quellcode für die USB-Ansteuerung befindet sich in denDateien platform/avr-atmega128rfa1/usb-de-rfnode.c undplatform/avr-atmega128rfa1/usb.h.

1.2 Ansteuerung LEDs

Sofern das Symbol DEBUG LED definiert ist, wird nach dem booten von Contikidie erste LED angeschaltet. Diese wird nachdem ein Nachbar gefunden wurdewieder ausgeschaltet, verantwortlich dafür ist ein Stück Code in der Funktionuip ds6 nbr add() in der Datei core/net/uip-ds6-nbr.c. Jede LED lässt sich durchCoAP an- und ausschalten, dafür zuständig ist die Funktion (leds onboard handler).Die entsprechende Ressource lautet actuators/leds onboard, Sie hateinen Parameter namens number, der die Werte 0, 1 und 2 annehmen kann,entsprechend ist damit die erste, zweite oder dritte LED gemeint. Als Modusstehen on, off und toggle zur Ausweihl, respektive um die LED an-, aus-oder umzuschalten. Der Handler dieser Ressource befindet sich in der Dateiproject/coap-sensornode/coap-sensornode.c. Um bei CoAP-Anfragen inder Lage zu sein, ob sich durch eine Abfrage der Zustand der LEDs geändert hat,wurde dem Quellcode von dresden elektronik ngenieurtechnik gmbh die Funktionleds onboard get() hinzugefügt, um eine bereits bestehende Zustands-Variable nachaußen ausgeben zu können.

Der Quellcode für die Ansteuerung der LEDs befindetsich unter platform/avr-atmega128rfa1/io access.c undplatform/avr-atmega128rfa1/io access.h.

1.3 Verwendung Buttons

Der Zustand der beiden Buttons wird jede Sekunde durchden Process-Thread rest server example in der Dateiproject/coap-sensornode/coap-sensornode.c durch einen Event-Timerabgefragt. Sollte einer der beiden Buttons als gedrückt erkannt werden, wird entsprechenddie zweite respektive dritte LED angeschaltet. Durch drücken des ersten Buttons wirdausserdem der Watchdog-Timer aktiviert und auf 15ms gesetzt, dies hat ein sofortigesrebooten zufolge. Sollte der zweite Button als ungedrückt erkannt werden, wird die dritteLED ausgeschaltet.

Desweiteren kann der Zustand des zweiten Buttons als Ressource durchCoAP abgefragt werden. Zuständig hierfür ist der Ressourcen-Handlerfür die Ressource sensors/button1, welcher sich auch in der Dateiproject/coap-sensornode/coap-sensornode.c befindet. An diesem RessourcenHandler ist zu beachten, dass er, neben der eigentlichen Frequenz mit der der Zustand des

2

Buttons abgefragt wird (hier einmal X Sekunden), einen Timer verwendet (der Länge YSekunden) und sich den letzten Zustand des Buttons in einer statischen Variablen merkt.Dadurch wird es möglich, bei einer Observierung nach einer erkannten Zustandsänderunginnerhalb von maximal X Sekunden ein Packet zu senden, oder nach Y Sekunden ohneZustandsänderung. Dieses Verhalten realisiert ein Conditional Observe.

Der Quellcode für die Ansteuerung der LEDs befindetsich unter platform/avr-atmega128rfa1/io access.c undplatform/avr-atmega128rfa1/io access.h.

3

2 Conditional Observe

Aufgabe: Es soll der Aktuellen Stand von Conditional Observe von CoAP recherchiertwerden.

Lösung: Zum Zeitpunkt des schreibens sind dem Author zwei Papers überConditional Observe in CoAP bekannt, einerseits das Paper Facilitating the creationof IoT applications through conditional observations in CoAP ([8]), sowie das Paper”Conditional observe in CoAP” ([6]). Da zu dem Paper [8] ein Github-Repository einesForks von Contiki gehört ([7]), wurde an dieser Stelle der Inhalt des anderen Paper nichtweiter betrachtet.

Die Änderungen dieses Branches wurden mit den Änderungen des Forks desForschungsseminas gemerged und in dem Branch condobs abgelegt. In dem Branchwurden weiterhin der Beispiel-Client und Server unter examples/er-rest-exampleso modifiziert, dass sie unter der Plattform minimal-net ausfuehrbar sind und miteinanderverbunden werden koennen. Dafür muss nach dem starten des Servers und des Clientsnoch eine Bridge zwischen den beiden Interfaces der Contiki-Instanzen gelegt werden:brctl addbr br0

brctl addif br0 tap0

brctl addif br0 tap1

ifconfig br0 up

Möglich ist dies dadurch, dass Client und Server andere tap-Interfaces verwendenund jeweils bei der Compilierung eine andere IP-Adresse zugewiesen bekommen haben.Die Zuweisung von verschiedenen tap-Interfaces wurde durch bedingte Kompilierungin der Datei cpu/native/net/tapdev.c erreicht, die Zuweisung von verschiedenenIP-Adressen durch Variablen im Makefile.

2.1 Button

In Abschnitt 1.3 wurde erwähnt, dass die Ressource sensor/button1 observiert werdenkann und sich durch Verwendung eines zusätzlichen Timers verhält, als wenn auf esein Conditional Observe angewendet wurde. Diese Lösung wurde gewählt, da zumZeitpunkt des Schreibens dieser Lösung der verwendete CoAP-Client von Californiumein Conditional Observe nicht unterstützt.

4

3 Test für Langzeitstabilität

Aufgabe: Es soll das Langzeitverhalten eines Sensorknotens bezüglich seiner Stabilitätbei ständigen Ping-Anfragen überprüft werden, da vermutet wird, der Sensorknotenwürde nach ca. 2 Tagen von dauerhaften Ping-Abfragen abstürzen.

Lösung: Es wurde ein einfacher Langzeit-Ping-Test ausgeführt, wobei alle 3 Minutenein Ping der Standardgröße von 64 Bytes gesendet wurde. Der Befehl hierfür lautet:ping6 aaaa::221:2eff:ff00:2250 -i 180

Dieser Test lief über 62 Stunden. Das Resultat kann aus Listing 3 entnommen werden.Die Vermutung konnte nicht bestätigt werden.--- aaaa::221:2eff:ff00:2250 ping statistics ---

1577 packets transmitted , 1541 received , 2% packet loss, time

283805753ms

rtt min/avg/max/mdev = 81.031/192.645/1426.444/134.818 ms

5

4 Messung von RSSI-Werten

Aufgabe: Es soll eine CoAP-Ressource implementiert werden, um per CoAP Aussagenüber die Qualität einer Verbindung machen zu können, in der Form von RSSI-Werten.Desweiteren RSSI-Werte sollen für verschiedene Entfernungen gemessen werden.

Lösung: Contiki berechnet für jedes eingegangene Packet einen RSSI-Wert.Der verwendete Treiber für den verwendeten Microcontroller ATmega128RFA1lautet rf230bb. Dieser Radio-Treiber ünterstützt kein Callback-Interface, wie andereRadio-Treiber von Contiki, aber speichert den zuletzt berechneten RSSI-Wert in einerVariablen. Daher wurde ein einfacher CoAP-Handler namens rssi für (periodische)Ressourcen implementiert, welcher den Wert der Variablen rf2300bb last rssiausgibt. Damit können RSSI-Werte durch eine CoAP-Abfrage auf die Ressourcesensors/rssi gemessen werden.

Um die Messung von RSSI-Werten für verschiedene Entfernungen wurde folgenderVersuchsaufbau gewählt. Der Sensor-Knoten wurde per Batterie betrieben ständigangepingt, gleichzeitig wurde ein Observe auf die Ressource sensors/rssidurchgeführt. Da ein Observe nur ein Packet schickt, müssen, um auf verschiedeneEntfernungen jeweils aktuelle RSSI-Werte zu bekommen, ständig neue Packeteempfangen werden. Dafür ist das Pingen zuständig.

-90

-80

-70

-60

-50

-40

-30

-20

-10

0 10 20 30 40 50 60 70 80

RSS

Iin

dBm

Entfernung in m

Abbildung 4.1: RSSI-Werte in Abhängigkeit zur Entfernung

Aus Grafik 4.1 lassen sich die Werte ablesen. Zu beachten dabei ist, dass derWertebreich realistisch [−90;−10] dBm beträgt, soll heissen: es können eigentlich keine

6

RSSI-Werte mit mehr als −10 oder weniger als −90 dBm auftreten. Die eigentlichenzurückgegebenen Werte befinden sich im Bereich [0; 84] dBm, sie müssen daherumgerechnet werden, was durch eine einfache Subtraktion von 90 geschieht.

Bei der Durchführung dieses Experimentes herrschten 2 ◦ C Aussentemperatur undkeine bis leichte Bewölkung. Das Experiment wurde auf einem Feld mit Bäumen inder Nähe durchgeführt. Border-Router und Sensorknoten waren auf ca. 1m Höhe undihre Antennen aufeinander ausgerichtet. Es wurden ca. 5 Messungen pro Punkt auf derAbszissenachse durchgeführt. Die Messung der Entfernung war sehr Ungenau (Zählenvon Schritten) und die Messungen der RSSI-Werte streuen stark.

7

5 Beheben einer endlosenReboot-Schleife bei Aktivierungextern angeschlossener Sensoren

Aufgabe: Der Sensorknoten rebootet sich ständig. Dieses Fehl-Verhalten soll behobenwerden.

Lösung: Die Aktivierung der extern angeschlossenen Sensoren SHT21 undBMP085 funktioniert über eine I2C-Abfrage mit einem eventuellen Timeout.Sofern ein Timeout bei der Aktivierung auftritt, gilt der jeweilige Sensorals nicht vorhanden. Dieses Verhalten funktioniert nicht bei eingeschaltetemWatchdog-Timer. Zur Lösung dieses Problems wurde jeweils ein Aufruf der Funktionenwatchtod stop und watchdog start um die Aktivierung der Sensoren in der Dateicontiki/project/coap-sensornode/coap-sensornode.c eingefügt, um währenddes warten auf einen eventuellen Timeout der I2C-Abfrage auf den jeweiligen Sensorkein Neustart durch den Watchdog-Timer herbeizuführen.

8

6 Unterstützung fürOnboard-I2C-Sensoren

Aufgabe: Das Board deRFnode besitzt einige I2C-Sensoren die sich onboard befinden.Diese sollen als CoAP-Ressourcen zur Verfügung stehen.

Lösung: Zum ansprechen der Sensoren wurde Quellcode von dresden elektronik[2]übernommen, es handelt sich dabei um folgende Dateien:

• platform/avr-atmega128rfa1/i2c sensors.c

• platform/avr-atmega128rfa1/i2c sensors.h

• platform/avr-atmega128rfa1/i2c sensors interface.h

• platform/avr-atmega128rfa1/twi master.c

• platform/avr-atmega128rfa1/twi master.h

Zusätzlich wurden Init-Aufrufe in die main-Methode in der Dateiplatform/avr-atmega128rfa1/contiki-main.c platziert sowieentsprechende CoAP-Handler für die einzelnen Sensoren in der Dateiproject/coap-sensornode/coap-sensornode.c hinzugefügt.

Diese Lösung ist Sub-optimal, da der Quellcode von dresden elektronik seine eigeneI2C-Protokoll-Implementierung verwendet, welche redundant gegenüber der bereitsvorhandenen von Contiki ist. Desweiteren ist das Interface für die Ansteuerung nicht derArt wie es für die Sensoren ist die von Contiki bereits unterstützt werden.

9

7 Untersuchung von Contikimac undStromverbrauch des Radiomodules

Aufgabe: Es soll das Timing-Verhalten des Contikimac-Mechanismus überprüft werden.Es besteht die Vermutung, dass das Radio-Modul länger als nötig angeschaltet ist unddaher unnötig viel Strom verbraucht. Daher soll auch der Stromverbrauch gemessenwerden.

Lösung: Es wurden jeweils Messungen für eine 8-MHz-Konfiguration (Fuses: L:C2H:91 E:FF) und eine 16-MHz-Konfiguration (Fuses: L:D7 H:91 E:FF) vorgenommen.Gemessen wurde alles mit einem PC-Oszilloskop der Marke PicoScope und derdazugehörigen Software vom Hersteller pico Technology.

Für die Timing-Angaben wurden jeweils an bestimmten Stellen Ausgabepins desMicrocontrollers auf High oder Low geschaltet. Um die Ausgabepins zu konfigurierenwurde folgender Code-Schnipsel in die initialize()-Methode in der Dateicontiki/platform/atmega128rfa1/confiki-main.c hinzugefügt, sowie derCode für die LED-Initialisierung auskommentiert. Dies ist nötig da für die Messungendie Pins PB3 und PB4 verwendet wurden, die normalerweise vom LED-Modulverwendet werden. Die Konfiguration dieser Pinks erfolgte über folgenden Code:DDRB |= (1

der Microcontroller nur im Batteriebetrieb und ohne angeschlossenen Programmiereroder zweiten angeschlossenen Kanal des Oszilloskops lauffähig war. Daher konntezwischen den Messungen der Timings und den Messungen der Spannungsverläufe keindirekter Bezug dazu hergestellt werden, wobei sich der Zusammenhang erahnen lässt.

Die gemessenen Ströme liegen dabei nahe den erwarteten Strömen, vgl. [1, S. 4].

7.1 Messungen mit 8-MHz-Clock

Abbildung 7.1: Messung Timings für 8 MHz

Angemerkt zur Messung 7.1 soll die Unterschiedliche Dauer der radio on()-Routinesein. Das Datenblatt sagt dazu aus, dass unter bestimmten Vorraussetzungen derRadio-Transceiver schneller in den Zustand TRX OFF aus dem Zustand SLEEPwechselt.[1,S. 40]

11

Abbildung 7.2: Messung Spannungsverlauf für 8 MHz

Zuert wird die Zeit aufsummiert, über die ein Spannungswert ungleich Null gemessenwurde:

370 µs + 393 µs + 43 µs + 59 µs + 338 µs + 779 µs + 46 µs + 377 µs + 890 µs = 3295 µs

Anschließend wird der durchschnittliche Spannungswert berechnet:

6.5 mV · 370 µs + 8.7 mV · 393 µs + 56.8 mV · 43 µs+16.5 mV · 59 µs + 30.7 mV · 338 µs + 6.5 mV · 779 µs+

16.5 mV · 46 µs + 30.7 mV · 377 µs + 6.5 mV · 890 µs3295 µs

= 12.99 mV

Bei einem Shunt-Widerstand von 2 Ω ergibt dies in mA:

12.77 mV2 Ω

= 6.49 mA

Nun wird die Zeit berechnet, die das Radiomodul in einer Zeitspann an ist. Dafür wird dieZeit in der ein Spannungswert ungleich Null gemessen wurde multipliziert mit 8 für dieAnzahl an solchen Messungen pro Sekunde und mit zwei mal 60, um auf die Zeitspannepro Stunde zu kommen, die das Radiomodul an ist:

3255 · 8 · 60 · 601000 · 1000 = 94.896 s

Dies ergibt pro Monat eine An-Zeit von:

94.896 s · 24 · 3060 · 60 = 18.98 h

Als letztes wird nun der Verbrauch in mAh pro Monat berechnet:

6.49 mA · 18.98 h = 123.18mAh

12

7.2 Messungen mit 16-MHz-Clock

Abbildung 7.3: Messung Timings für 16 MHz

Abbildung 7.4: Messung Spannungsverlauf für 16 MHz

Da die Berechnung für die 16-MHz-Konfiguration analog zur 8-MHz-Konfigurationabläuft, wird an dieser Stelle auf Kommentare verzichtet.

1388 µs + 279 µs + 42 µs + 73 µs + 178 µs + 429 µs + 36 µs + 231 µs + 527 µs = 3183 µs

2.5 mV · 1388 µs + 10.5 mV · 279 µs + 59.3 mV · 42 µs+19.5 mV · 73 µs + 33.9 mV · 178 µs + 10.5 mV · 429 µs+

19.5 mV · 36 µs + 33.9 mV · 231 µs + 10.5 mV · 527 µs3183 µs

= 10.97 mV

13

10.97 mV2 Ω

= 5.49 mA

3183 µs · 8 · 60 · 601000 · 1000 = 91.67 s

91.67 · 24 · 3060 · 60 = 18.334 h

5.49 mA · 18.334 h = 100.65mAh

Mit der 16-MHz-Konfiguration ergibt dies einen monatlichen Verbrauch von 100.65 mAh,18.3% weniger als in der 8-MHz-Konfiguration.

14

8 Untersuchung KonfigurationParameter für RPL

Aufgabe: Im Wintersemester 2014/2015 hat Thomas Herrlich die Kommunikationinnerhalb des Netzwerkes mit Hilfe eines Sniffers überprüft und dabei festgestellt,dass bestimmte Packete periodisch und häufig gesendet werden und dahinter eineFehlkonfiguration vermutet.[4, S. 22 ff.] Aufgabe ist es, zu recherchieren wie RPLvon Contiki konfiguriert bzw. implementiert ist und festzustellen, ob das beobachteteVerhalten sinnvoll ist oder Resultat einer Fehlkonfiguration ist.

Lösung: Zuerst werden die verwendeten Termini erläutert sowie wofür siebei RPL grebraucht werden. Ein DODAG ist ein Ziel-gerichteter gerichteterazyklischer Graph, bestehend aus RPL-Knoten. Man Travestiert den Graph voneinem Blatt-Knoten zu der Wurzel hinauf, dementsprechend von der Wurzel zueinem Blatt-Knoten hinunter. RPL-Knoten konstruieren und warten DODAGs durchDODAG-Informations-Objekt-Nachrichten (DIO). [10, S. 16] Knoten annoncieren ihrePräsenz, ihre Zugehörigkeit zu einem DODAG, Routing-Kosten und dazugehörigeMetriken durch versenden von Link-lokalen Multicast-DIO-Nachrichten zu allenRPL-Knoten. Dementsprechend hören alle Knoten auf DIO-Nachrichten und nutzenderen Informationen um einem neuen DODAG beizutreten (und damit sich neueDODAG-Eltern aussuchen) oder um in ihrem derzeitigen DODAG zu verbleiben.RPL verwendet “Destination Advertisement Objects”-Nachrichten (DAO) umabwärts-gerichtete Routeneinzurichten. [10, S. 19] Dabei wird noch zwischenverschiedenen Modi unterschieden, nämlich Storing- und Non-Storing-Modus. ImStoring-Modus wird die DAO-Nachricht unicasted vom Kind zu den selektiertenEltern geschickt. Im Non-Storing-Modus wurd die DAO-Nachricht unicasted zu derDODAG-Wurzel geschickt. [10, S. 41]

Nach Herrlich werden sowohl von den Knoten als auch vom Border-Router alle paarSekunden DIO-Objekte 32 mal hintereinander gesendet, jedesmal mit dem gleichenInhalt, bei einer insgesamten Sendedauer von 125 ms.[4, S. 24] Diese Sendedauer passtzu dem ContikiMAC-Mechanismus, bei dem ein Knoten mehrmals pro Sekunde aufwachtum zu lauschen was auf dem Kanal liegt und sich sonst schlafen lägt.[3] In der derzeitigenKonfiguration liegt dies bei 8 Hz, also wacht ein Knoten alle 125 ms auf.

RPL-Knoten verschicken DIO-Nachrichten nach einem Trickle-Timer[10, S. 74],daher soll an dieser Stelle vorerst auf den Trickle-Algorithmus eingegangen werden.Die Grundidee des Trickle-Algorithmus ist denkbar einfach: gelegentlich sendet einKnoten Daten, ausser es hört die Nachrichten von anderen Knoten die daraufhinweisen, dass die eigene Nachricht redundant ist.[5, S. 3] Ein Trickle-Timer läuft

15

eine definierte Interval-Länge, die durch drei Konfigurations-Parameter charackterisiertist: der kleinsten Intervall-Länge Imin, der maximalen Intervall-Länge Imax und eineRedundanz-Konstante k. Die kleinste Intervall-Länge Imin ist als eine Zeit-Einheitdefiniert, die maximale Intervall-Länge als das 2n-Fache der kleinsten Intervall-Länge.Die Redundanz-Konstante k ist eine positive ganze Zahl. Dazu zusätzlich werden dreiVariablen verwaltet: I, die derzeitige Intervall-Größe, t, eine Zeit innerhalb des derzeitigenIntervalls und c, ein Zähler.

Der Trickle-Algorithmus besteht aus den folgenden sechs Regeln:

1. Während des Startens des Algorithmus wird I aus dem Intervall [Imin, Imax]gewählt. Dann beginnt der Algorithmus mit dem ersten Intervall.

2. Wenn ein Intervall beginnt, wird der Zähler c auf 0 gesetzt und t zu einem zufälligenZeitpunkt im Intervall [I/2, I] gewählt.

3. Wenn Trickle eine Übertragung hört, die konsistent mit der eigenen ist, wird derZähler c inkrementiert.

4. Zur Zeit t wird ein Packet übertragen genau dann wenn c ≤ k.

5. Wenn das Intervall I ausläuft, wird die Intervall-Länge verdoppelt. Wenn dadurchI > Imax, wird I = Imax gesetzt.

6. Wenn Trickle eine inkonsistente Übertragung hört und I ist größer als Imin, wird derTrickle-Timer zurückgesetzt. Dazu wird I = Imin gesetzt und ein neues Intervallgestartet wie in Schritt 2.

[5, S. 5 ff.]

Anhand dessen kann man sehen das der Trickle-Algorithmus die Packet-Anzahlentsprechend der Dichte eines Netzwerkes skaliert. Ein einzelner, unverbundener Knotenverschickt dann Packete mit der Trickle-Kommunikations-Rate. In einem idealisiertenVerlustfreien, Single-Hop Netzwerk der Größe n ist die Trickle-Kommunikations-Rate(Summe der Anzahl der Nachrichten die vom Trickle-Algorithmus in einem Intervalversendet bzw. empfangen wurden) jedes einzelnen Knotens gleich der Summe derTrickle-Übertragungs-Raten (Summe der Anzahl der Nachrichten die in einem Intervallvom Trickle-Algorithmus versendet wurden) aller Knoten. Der Trickle-Algorithmusbalanziert die Last in einem solchen Szenario, so dass die Trickle-Übertragungs-Rategleich das 1/n-Fache der Trickle-Kommunikations-Rate ist. Spärlich besetzte Netzwerkebenötigen damit mehr Übertragungen pro Knoten, aber die Belegung des gewähltenÜbertragungsmediums erhöht sich nicht. [5, S. 4]

In Contiki werden diese Parameter konfiguriert in der Dateicore/net/rpl/rpl-conf.h. Die kleinste Intervall-Länge wird angegeben durchdie Konstante RPL DIO INTERVAL MIN und beträgt 12, also 212 ms = 4096 ms. Diemaximale Intervall-Länge wird durch die Konstante RPL DIO INTERVAL DOUBLINGSangegeben und beträgt 8, daher beträgt die maximale Intervall-Länge 212+8 ms =1048576 ms = 1048.576 s, was ca. 17 1/2 Minuten entspricht. Die Redundanz-Konstantewird durch die Konstante RPL DIO REDUNDANCY festgelegt, derzeit beträgt sie 10. Im

16

Kommentar über der Definition der Konstante ist vermekrt, dass es unklar ist auf welcheGrundlage dieser Wert gewählt wurde.

Ob eine Nachricht als inkonsistent mit der eigenen Nachricht angesehen wird hängtdabei von der DIO-Versions-Nummer ab.

Nach Herrlich werden auch DAO-Objekte periodisch alle paar Sekunden gesendet.[4,S. 24] DAO-Nachrichten werden generiert, wenn ein Knoten selber eine DAO-Nachrichterhalten hat, bei Änderungen in dem Set von Eltern an die er DAO-Nachrichtenschickt oder als Antwort auf andere externe Ereignisse, wie das Auslaufen einerzugehörigen Präfix-Lebensdauer.[10, S. 79] Die dazugehörige Contiki-Funktion lautetrpl schedule dao() und befindet sich in der Datei core/net/rpl/rpl-timers.c.Sie wird nur an drei Code-Stellen aufgerufen, nämlich in den Funktionenrpl select dag(), rpl join instance() und rpl process dio(), welchesich in der Datei core/net/rpl/rpl-dag.c befinden. Daraus lässt sich schliessen,dass DAO-Nachrichten nicht von sich aus periodisch gesendet werden sollten, sondernnur als Antwort auf andere Ereignisse.

Die Einhaltung dieses theorethischen Timing-Verhaltens wurde praktisch mit einemPacketsniffer verifiziert. Für das Sniffen der Packete wurde ein RZUSBstick verwendet inVerbindung mit µracoli in der Version 0.4.2. Nach der Messung der Packete viel auf,dass bis zu einer bestimmten Intervallgröße sich die Timer wie nach den theorethischenÜberlegungen verhalten, jedoch nach überschreiten dieser Intervallgröße sich abruptdie Zeitspannen zwischen den Sendungen der DIO-Packete verkürzen und bei ca20 Sekunden verbleiben.

Grund dafür ist die derzeitige Konfiguration des Variablentyps clock time t inder Datei platform/avr-atmega128rfa1/contiki-conf.h, sie wird als unsignedshort definiert und hat damit eine Größe von 2 Bytes. Bei der Berechnung derTicks für die Timer wird die Intervalllänge statt ein Vielfaches der Zahl Zweinormal als Zahl dargestellt, was bei überschreiten der Intervallgröße von 216 mseinen Integer-Overflow verursacht. Um dies zu verhindern bietet es sich an, diealternative Definition des Variablentyps clock time t zu verwenden, welcher auch inder Datei platform/avr-atmega128rfa1/contiki-conf.h geschrieben steht. Mitdieser Definition wird der Variablentyp als unsigned long definiert. Dafür muss nurdas Argument der umgebenden #if-Präprozessor-Direktive der ersten Definition von 1auf 0 geändert werden.

17

Literatur

1. Datenblatt ATmega128RFA1.

2. deRFnative Examples. Online erhältlich unter http : / / www . dresden -elektronik.de/fileadmin/Downloads/Software/deRFnativeExamples_

v1_11.exe; Abgerufen am 12. Januar 2015.

3. Dunkels, Adam (2011). ”The contikimac radio duty cycling protocol“. In:

4. Herrlich, Thomas (2015). ”Abschlussbericht Forschungsseminar “Sensornetze”Teil 2“. In:

5. Levis, Philip u. a. (2011). ”The Trickle Algorithm“. In: Internet Engineering TaskForce, RFC6206.

6. Li, ST, J Hoebeke und AJ Jara (2012). ”Conditional observe in CoAP“. In:Constrained Resources (CoRE) Working Group, Internet Engineering Task Force(IETF), work in progress, draft-li-core-conditional-observe-03.

7. Teklemariam, Girum Ketema. condobs. Online erhältlich unter https://github.com/girumk/contiki; Abgerufen am 12. Januar 2015.

8. Teklemariam, Ketema u. a. (2013). ”Facilitating the creation of IoT applicationsthrough conditional observations in CoAP“. In: EURASIP Journal on WirelessCommunications and Networking.

9. User Manual deRFnode / deRFgateway. Online erhältlich unter http://www.dresden-elektronik.de/fileadmin/Downloads/Dokumente/Produkte/3_

Development_Boards/deRFnode_deRFgateway-BHB-en.pdf; Abgerufen am12. Januar 2015.

10. Winter, T u. a. (2012). ”RPL: IPv6 Routing Protocol for Low-Power and LossyNetworks“. In: Internet Engineering Task Force, RFC6550.

18

http://www.dresden-elektronik.de/fileadmin/Downloads/Software/deRFnativeExamples_v1_11.exehttp://www.dresden-elektronik.de/fileadmin/Downloads/Software/deRFnativeExamples_v1_11.exehttp://www.dresden-elektronik.de/fileadmin/Downloads/Software/deRFnativeExamples_v1_11.exehttps://github.com/girumk/contikihttps://github.com/girumk/contikihttp://www.dresden-elektronik.de/fileadmin/Downloads/Dokumente/Produkte/3_Development_Boards/deRFnode_deRFgateway-BHB-en.pdfhttp://www.dresden-elektronik.de/fileadmin/Downloads/Dokumente/Produkte/3_Development_Boards/deRFnode_deRFgateway-BHB-en.pdfhttp://www.dresden-elektronik.de/fileadmin/Downloads/Dokumente/Produkte/3_Development_Boards/deRFnode_deRFgateway-BHB-en.pdf

Support für USB, LEDs und ButtonsUSB-Kommunikation mit Host-PCAnsteuerung LEDsVerwendung Buttons

Conditional ObserveButton

Test für LangzeitstabilitätMessung von RSSI-WertenBeheben einer endlosen Reboot-Schleife bei Aktivierung extern angeschlossener SensorenUnterstützung für Onboard-I2C-SensorenUntersuchung von Contikimac und Stromverbrauch des RadiomodulesMessungen mit 8-MHz-ClockMessungen mit 16-MHz-Clock

Untersuchung Konfiguration Parameter für RPLLiteraturverzeichnis

Documents

Forschungsbericht fur das Fach¨ Sensornetzewiki_sn/images/c/c0/...Sofern das Symbol DEBUG LED deﬁniert ist, wird nach dem booten von Contiki die erste LED angeschaltet. Diese wird