Belegarbeit Einführung in Contiki-OS

Transkript

1 Belegarbeit Einführung in Contiki-OS Implementierungsaspekte und Netzwerk-Stack Angelos Drossos und Hermann Lorenz Belegarbeit im Modul Sensornetze des Masterstudienganges Angewandte Informationstechnologien betreut durch Prof. Dr.-Ing. Jörg Vogt im Wintersemester 2012/2013 Hochschule für Technik und Wirtschaft Dresden Fakultät Informatik/Mathematik

2 Vorwort Das von Professor Vogt betreute Forschungsseminar Sensornetze hat als Zielstellung die Konzipierung einer freien Hausautomatisierung. In diesem Bereich existieren schon verschiedene proprietäre (z. B. ZigBee und HomeMatic) und auch freie Lösungsansätze (z. B. Hexabus), die aber die Anforderungen an eine freie, erweiterbare Hausautomatisierung nicht erfüllen. Proprietäre Lösungen haben den Nachteil, dass sie aufgrund der geschlossenen Technik oder aufgrund unnötiger Lizenzkosten für Drittanbieter unattraktiv sind. Freie Systeme sind meist Ein-Mann-Projekte, die zu spezielle Lösungsansätze verfolgen oder nur unzureichend dokumentiert sind. Ziele für die Entwicklungen im Forschungsseminar sind: quelloffene Module existierende Standardtechnologien nutzen, wie IPv6 over Low power Wireless Personal Area Networks (6LoWPAN) ausführliche Dokumentationen die Möglichkeit andere, evtl. auch proprietäre, Systeme mit einzubinden Im Rahmen dieser Arbeit für das Mastermodul Sensornetze soll im Bezug auf das Forschungsseminar das freie Betriebssystem Contiki-OS analysiert und vorgestellt werden. Da für das Forschungsseminar der Einsatz von 6LoWPAN als Funktechnologie und dem ATmega128RFA1 als Hardwareplattform vorgesehen ist, werden in diesem Dokument vorwiegend die im Forschungsseminar eingesetzten Technologien betrachtet. Andere Funktechnologien werden nur beiläufig erwähnt. Dennoch soll insbesondere aus dem Kapitel 3 hervorgehen, wie neue Funktechnologien integriert werden können. ii

3 Inhaltsverzeichnis Abbildungsverzeichnis Tabellenverzeichnis iv iv 1. Einleitung 1 2. Implementationsaspekte Protothreads Konzept Umsetzung Bewertung IPC-Mechanismen Events und Polling Semaphore Protosockets Speicherverwaltung Network Stack Implementation Anforderungen an den Netzwerk-Stack in Contiki Grundlagen der drahtlosen Kommunikation in Sensornetzen Aufgaben der Netzprotokolle Unterschied zu herkömmlichen Netzprotokollen Konzept des Contiki NetStacks Funktionsweise Radio Driver Framer RDC Driver MAC Driver Network Driver Senden und Empfangen von Nachrichten Empfangen einer 6LoWPAN-Nachricht Versenden einer 6LoWPAN-Nachricht Hinweise zum Contiki NetStack Schlussbemerkungen 26 A. Contiki Dokumentation 28 iii

4 B. GitHub-Repositorys 29 B.1. Contiki B.2. HexaBus C. Beispielprojekt 30 Abbildungsverzeichnis 1.1. Contiki-Schichten Zusammenspiel von Events und Polling Verbotener Zyklus von synchronen Events Contiki NetStack Konzept C.1. Verkabelung für das Beispielprojekt Tabellenverzeichnis 2.1. Vergleich der Mechanismen zur Speicherverwaltung Überblick zu den implementierten Treibern in Contiki Contiki NetStack Beispiel iv

5 Abkürzungsverzeichnis 6LoWPAN IPv6 over Low power Wireless Personal Area Networks CCA CoAP CoAP CRC Clear Channel Assessment Constrained Application Protocol Constrained Application Protocol Cyclic Redundancy Code CSMA/CA Carrier Sense Multiple Access with Collision Avoidance CSMA CTDMA FCS FFD IPC IP ISR LLC LPP MAC NetStack RDC RFD SP TDMA UDP uip Carrier Sense Multiple Access Code Time Division Multiple Access Frame Check Sequence Full Function Device Inter-Prozess Communication Internet Protocol Interrupt Service Routine Logical Link Control Low Power Probing Medium Access Control Netzwerk-Stack Radio Duty Cycle Reduced Function Device Sensornet Protocol Time Division Multiple Access User Datagram Protocol micro IP, open-source TCP/IP-Stack v

6 1. Einleitung Drahtlose Sensornetze helfen beim Katastrophenschutz, Ereignisse wie Waldbrände rechtzeitig zu erkennen und zu bekämpfen. Aber auch beim Militär finden Sensornetze seit Jahren Anwendung. Ein recht junger Trend ist der Einsatz von Sensornetzen im (privaten) Haushalt. Angenommen, ein Hausbesitzer möchte sein Gartenhäuschen aus der Ferne überwachen, so muss dieser das Sensornetz mit dem Internet verbinden. Der Wunsch, Sensornetze mit dem Internet zu verbinden, hat dazu geführt, dass sich das Internet der Dinge hervorgetan hat. Hierbei besteht das Internet nicht nur aus menschlichen Teilnehmern, sondern auch aus Dingen wie die einzelnen Sensorknoten. So ein Sensornetz mit dem Internet zu verbinden, erfordert einen Internet Stack, der auf ressourcenarmen Minicomputern Platz findet. Hierzu bietet es sich an, ein Betriebssystem zu nutzen, das leichtgewichtige Technologien nutzt und auf neue Plattformen portierbar ist. Neben dem Open-Source-Betriebssystem TinyOS hat sich auch Contiki-OS als Betriebssystem für drahtlose Sensornetze in den letzten Jahren etabliert. Contiki beschreibt sich selber als The Open Source Operating System for the Internet of Things [AUTOCITE(contiki)] und wird under der 3-Klausel-BSD-Lizenz entwickelt. Als Zielplattform sind eingebette, batteriebetriebene Systeme vorgesehen, die über Funk (oder andere Netzwerke) miteinander kommunizieren. Contiki bietet eine Reihe von Modulen, die es für den Einsatz in einem drahtlosen Sensornetz prädestiniert. Dazu gehören: speicherschonendes Multithreading durch Protothreads viele bereits implementierte Netzwerkprotokolle (IPv6, CoAP, usw.) bereits auf verschiedene Hardwareplattformen portiert (Mikrocontroller von Texas Instruments, AVR und einige ARM-Geräte) Mechanismen zur Energieüberwachung ein eigens für Mikrocontroller entwickeltes Dateisystem Seine Module teilt Contiki in einzelne Schichten, die in Abbildung 1.1 gezeigt sind, ein: Die Treiber kümmern sich dabei um die hardwarespezifischen Probleme. Die Kernmodule stellen die einzelnen Funktionalitäten, wie Multitasking oder fertige Timer, bereit. Services nutzen diese Kernmodule, um z. B. Netzwerkprotokolle bereitzustellen, die von Anwenderprogrammen genutzt werden können. Durch das angestrebte Einsatzgebiet (eingebettete, batteriebetriebene Systeme) ergeben sich zwei wichtige Anforderungen an das Betriebssystem: 1

7 1. Einleitung Applikationen Services Webserver FTP Telnet... eigene Kern Process Timer Netzwerk ELF-Loader... Tools Treiber Plattform CPU Abbildung 1.1.: Contiki-Schichten nach [AUTOCITE(dreier10contikiblackfin)] Speicher Da auf den Mikrocontrollern nur wenige kb Speicher zur Verfügung stehen (z. B. für den ATmega128RFA1 16 kb), muss das Betriebssystem mit möglichst wenig Speicher auskommen, damit für die eigentlichen Anwendungsprogrammen noch genug Speicher zur Verfügung steht. Energie Die Wartung der Hardware soll möglichst gering sein. Dazu muss ein Netzwerkknoten auch über Jahre mit nur einem Satz Batterien auskommen. Um dies gewährleisten zu können, muss das Betriebssystem die Stromsparmechanismen der Hardware unterstützen und optimal nutzen. Der Aufbau dieses Dokuments gliedert sich daher wie folgt: In Kapitel 2 wird das Konzept der Protothreads und die damit einhergehenden Möglichkeiten des Multitaskings sowie seine Beschränkungen als zentrales Programmiermodell in Contiki vorgestellt. In Kapitel 3 wird speziell der Netzwerkstack von Contiki erklärt und analysiert. Abschließend wird in Kapitel 4 ein Fazit zum Contiki-OS gegeben. 2

8 2. Implementationsaspekte 2.1. Protothreads Betriebssysteme im Embedded-Bereich werden meistens ereignisgesteuert oder threadbasiert implementiert. threadbasiert Ein Programm wird linear durchlaufen. Dabei kann es zwar durch einen Scheduler unterbrochen werden bzw. selbständig die CPU abgeben, der Kontrollfluss allerdings bleibt linear. Der Vorteil besteht darin, dass es eine intuitive Programmierung ermöglicht. Für jeden Thread muss dabei ein eigener Stack im Hauptspeicher angelegt werden. Der Großteil des Stacks wird nie benutzt, muss aber im Hauptspeicher reserviert vorgehalten werden. Da der Hauptspeicher bei eingebetteten System aber sehr klein ist beim ATmega128RFA1 z. B. nur 16 kb sind so nur wenige Threads gleichzeitig möglich. Dem kann theoretisch mit einem größeren Hauptspeicher entgegengewirkt werden, allerdings geht mit einem größeren Hauptspeicher auch ein erhöhter Energiebedarf einher. Dies steht der Notwendigkeit entgegen, den Mikrocontroller so energieeffizient wie möglich zu betreiben. ereignisgesteuert Bei ereignisgesteuerten Systemen entfallen die Stacks für einzelne Threads es existiert nur ein globaler Stack. Durch die ereignisgesteuerte Programmierung sind allerdings keine linearen Programmabläufe direkt möglich. Sie müssen mittels einer Zustandsmaschine umgesetzt werden. Das ist zum einen fehleranfällig und zum anderen vergrößert sich dadurch unnötig der auszuführende Code, der wieder Platz im Speicher benötigt und natürlich durch längere Ausführungszeiten wieder mehr Energie benötigt. Adam Dunkels, der Entwickler von Contiki, hat sich als Lösung diese Problematik das Konzept der Protothreads ausgedacht. Sie sind in Anlehnung an die Coroutinen in C von Simon Tatham entstanden und ermöglichen ein kooperatives Multitasking mit nur einem gemeinsamen Stack [AUTOCITE(Contiki:UnderTheHood)] Konzept Als Konzept wird jeder Prozess zu einer Funktion, die aus einem einzigen Switch-Block besteht (siehe Listing 2.1). Die einzelnen Case-Marken stellen dabei die möglichen Positio- 3

9 2. Implementationsaspekte Listing 2.1: Grundkonzept eines Contikiprozesses int process (int start) { switch(start) { case 0:... case 1:... return 2; case 2:... case 3:... case 4: return 0; } } // Kontextwechsel Listing 2.2: Abgabe der CPU ohne eine Bedingung zur weiteren Abarbeitung switch(start) {... return 123; case 123:... } nen eines Kontextwechsels dar. Wird dem Prozess vom Scheduler die CPU zugewiesen, so wird die Prozessfunktion mit der jeweiligen Sprungmarke aufgerufen, an der der Prozess fortgesetzt werden soll. Bei der Abgabe der CPU wird die Prozessfunktion verlassen und dem Scheduler mitgeteilt, an welcher Sprungmarke bei der nächsten CPU-Zuteilung die Funktion fortgesetzt werden soll. Dabei ist es sehr einfach möglich, die CPU abzugeben, um anderen Prozessen die Abarbeitung zu ermöglichen (siehe Listing 2.2) bzw. auf ein bestimmtes Ereignis/eine Bedingung zu warten (siehe Listing 2.3). Der Switch-Block erlaubt es dabei auch direkt in einen Schleifenblock oder in einen Listing 2.3: Abgabe der CPU mit einer Bedingung zur weiteren Abarbeitung switch(start) {... case 123: if (! bedingung_erfuellt()) return 123;... } 4

10 2. Implementationsaspekte Listing 2.4: Grundgerüst eines Contiki-Prozesses /* */ PROCESS(example_process, "example process"); AUTOSTART_PROCESSES(&example_process); /* */ PROCESS_THREAD(example_process, ev, data) { PROCESS_BEGIN(); do_something(); PROCESS_PAUSE(); do_something_else(); PROCESS_WAIT_UNTIL(temperatur > 30); do_something_completely_else(); PROCESS_END(); } /* */ If-Else-Block zu springen. [AUTOCITE(dunkels06protothreads,duff:loops)] Damit ist ein Kontextwechsel an den verschiedensten Stellen in der Prozessfunktion möglich. Nachteilig ist hier, dass dieser Mechanismus nur direkt in den Threads einsetzbar ist. Ein Kontextwechsel in einer aufgerufenen Funktion ist nicht möglich. Ist eine Funktion so umfangreich, dass man einen Kontextwechsel während der Laufzeit vorsehen möchten, dann kann man die Funktion in einen eigenen Thread auslagern. Dieser Thread wird dann gestartet und der Prozess wartet auf die Beendigung des Threads. Im Thread kann dann aber wieder ein Kontextwechsel an den passenden Stellen vorgenommen werden Umsetzung Das Konzept der Protothreads kann von jedem Programmierer auch von Hand umgesetzt werden. Der Vorteil der Protothreadimplementierung in Contiki besteht darin, dass die Komplexität des Switch-Blocks durch Precompilermakros gekapselt wird (siehe Listing 2.4). Zu sehen, was die Makros letztendlich machen ist nur noch schwer möglich und möchte man etwas am Prozess-/Threadsystem ändern, so ist dies mit einem hohen Aufwand verbunden. Für den Anwender der Protothreads wird die Arbeit aber bedeutend leichter. Der Code wird les- und wartbar. Contiki stellt neben der bedingungslosen CPU-Abgabe bzw. einer eigenen Bedingung auch weitere Funktionen zum Kontextwechsel bereit. Etwa um auf Events (siehe Unterabschnitt 2.2.1) des Betriebssystems zu warten. Diese weiteren Kontextwechsel ermöglichen die Mittel des Betriebssystems effizient zu nutzen und sind in der Dokumentation (siehe [PARENCITE(Contiki:Doc)] Contiki processes) erklärt. Für die Label der Case-Marken wird von Contiki die aktuelle Zeilennummer des Quellcodes eingesetzt. Diese ist damit in der Datei und damit in dem Prozess einzigartig, sofern der Programmierer keine zwei Kontextwechsel in einer Codezeile vorsieht. 5

11 2. Implementationsaspekte Bewertung Die Protothreads ermöglichen relativ viele kooperative Threads mit einem nur geringen Speicher zu betreiben, da nur ein einziger Stack verwendet wird. Die Kontextwechsel sind mit einem nur geringen Aufwand zur Sicherung des Kontextes verbunden. Die Verwendung der Protothreadbibliothek ist relativ simpel. Eine Überführung von linearen Abläufen in Zustandsmaschinen ist nicht notwendig. Konzeptbedingt gibt es aber ein paar Nachteile, die bei der Programmierung zu beachten sind. In einem Thread können keine Switch-Blöcke verwendet werden. Variablen eines Threads, die ihren Wert über einen Kontextwechsel behalten sollen, müssen als static oder als globale Variable deklariert werden. Im letzteren Fall sollte die Variable volatile gesetzt werden, falls verschiedene Threads und/oder Interrupt Service Routinen (ISRs) darauf zugreifen. Kontextwechsel müssen vom Programmierer explizit angegeben werden es findet kein präemptiver Entzug der CPU-Ressource statt. Bei Algorithmen mit hoher Laufzeit muss daher regelmäßig ein Kontextwechsel vorgesehen werden. Dafür weiß der Programmierer aber wann das Programm unterbrochen werden kann und kann hier Aufwand für Zustandssicherungen einsparen. Ein Kontextwechsel ist nur in Threads möglich. Wird ein Teil des Programmes in eine Funktion ausgelagert, so ist dort kein Kontextwechsel möglich. Ist eine Auslagerung notwendig, so kann man einen weiteren Thread mit der Aufgabe starten, der wiederum selbständig Kontextwechsel vorsehen kann IPC-Mechanismen Contiki bietet eine Reihe von IPC-Mechanismen zur Kommunikation und Synchronisierung zwischen den einzelnen Prozessen an Events und Polling Unter Contiki können Prozessen zwei verschiedene Signale zugestellt werden: Events und Polling Events Events können von einem Prozess zu einem anderen Prozess zugestellt werden. Sie werden dabei in einer Warteschlange (Event-Queue) einsortiert und dann der Reihe nach den jeweiligen Prozessen zugestellt. Polling Neben Events kann bei jedem Prozess ein Polling-Flag gesetzt werden. Bevor der Scheduler die Event-Queue abarbeitet, schaut er bei jedem Prozess, ob das Polling- Flag gesetzt ist. Ist dieses Flag gesetzt, so wird direkt der Polling-Handler ausgeführt. Erst wenn alle Polling-Flags abgearbeitet sind, wird das erste Event aus der Queue ausgeliefert. 6

12 2. Implementationsaspekte Hardware Interrupt Event ISR Polling-Handler Thread Poll Event zeitkritisch Abbildung 2.1.: Zusammenspiel von Events und Polling Das Polling-Flag wird dadurch notwendig, dass ISRs möglichst kurz sein sollen. In ihnen sollen nur die notwendigsten Maßnahmen vorgenommen werden, um z. B. ein eingegangenes Signal nicht zu verlieren. Dieses Signal wird in der ISR in einen Cache geschrieben und der Prozess, der das Signal eigentlich verabeiten soll, wird über das Polling-Flag benachrichtigt, dass ein neues Signal vorliegt. Events sind also dafür da, dass bestimmte Signale nicht verloren gehen. Das Polling hingegen sorgt dafür, dass Signale, die dringend bearbeitet werden müssen ausreichend schnell zwischengespeichert werden könne, so dass bei häufig eingehenden Signalen keine Signale verloren gehen. (siehe Abbildung 2.1) Beispielsweise könnte eine ISR ein eingehendes Zeichen auf der seriellen Verbindung in einer globalen Variablen zwischenspeichern und einem Prozess A per Polling mitteilen, das dort ein neues Zeichen vorliegt. Dadurch, das sich der Polling-Handler des Prozesses A vor die Events in der Event-Queue schiebt, kann hier etwas aufwändiger das Zeichen in einen größeren Puffer eingefügt werden und dem Prozess A das Event zugestellt werden, dass ein weiteres Zeichen im Puffer wartet. Damit ist mit nur sehr wenigen Maschineninstruktionen die ISR abgehandelt und die Interrupts sind alle wieder verfügbar. Während jetzt der Polling-Handler (aufwändig) das eingegangene Zeichen in einen Cache einfügt und das Event auslöst, kann z. B. trotzdem ein weiterer Interrupt, z. B. diesmal des Analog-Digital-Wandlers, behandelt werden. Die Trennung von Polling und Events erlaubt damit die Trennung von Entgegennahme eines Signals (ISR), aufwändiger Zwischenspeicherung eines Signals (Poll) und eigentlicher Verarbeitung des Signals (Event). Programmierung Polling Ein Pollingsignal wird mittels process_poll(struct process * p) abgesetzt. Der Pollinghandler wird in der Definition des Prozessthreads bekannt gegeben. (siehe Listing 2.5) 7

13 2. Implementationsaspekte Listing 2.5: Installation eines Polling-Handlers void my_handler(void) {... } /* */ PROCESS(example_process, "example process"); AUTOSTART_PROCESSES(&example_process); /* */ PROCESS_THREAD(example_process, ev, data) { PROCESS_POLLHANDLER(myhandler()); PROCESS_BEGIN();... PROCESS_END(); } /* */ process_post_synch(...) C A process_post_synch(...) B process_post_synch(...) Abbildung 2.2.: Verbotener Zyklus von synchronen Events Aufgrund der Makroimplementierung kann man den auszuführenden Code auch direkt dem Makro PROCESS_PROLLHANDLER() übergeben. Dies ist aber aus Gründen der Lesbarkeit eher abzulehnen. Programmierung Events Events können synchron oder asynchron übergeben werden. Die asynchrone Methode funktioniert, wie oben bereits beschrieben und erfolgt mit der Funktion process_post(...). Die synchrone Methode funktioniert dabei etwas anders. Hierbei wird durch den Aufruf von process_post_synch(...) sofort die Kontrolle an den jeweiligen anderen Prozess abgegeben. Hierbei muss aber darauf geachtet werden, dass keine wechselseitigen synchronen Aufrufe auftreten bzw. sich ein Ring bildet. (siehe Abbildung 2.2) Die Möglichkeiten für Prozesse auf ein bestimmtes oder ein beliebiges Event zu warten sind vielfältig. Diese und die konkreten Parameter für das Absetzen eines Events können in der Dokumentation von Contiki nachgelesen werden (siehe [PARENCITE(Contiki:Doc)] Contiki processes). 8

14 2. Implementationsaspekte Semaphore Für Semaphore stehen die drei Makros PT_SEM_INIT(), PT_SEM_WAIT() und PT_SEM_SIGNAL() zur Verfügung. Sie greifen jeweils auf ein Struct vom Typ struct pt_sem zu und ermöglichen damit die Synchronisierung zwischen verschiedenen Prozessen (siehe [PARENCI- TE(Contiki:Doc)] Protothreads semaphores). Die Semaphore der Protothreads haben den Nachteil, dass sie nur für Threads zur Verfügung stehen. Sie können also weder in ISRs noch in Event-Handlern eingesetzt werden. Wird eine Variable nicht nur zwischen Threads geteilt, dann muss hier ein alternativer Mechanismus gesucht werden. Für ISRs muss verhindert werden, dass ISRs überhaupt ausgeführt werden können, da ein Warten in der ISR aufgrund der Anforderung an die Kürze einer ISR nicht möglich ist. Die Variable muss also an allen anderen Stellen mit cli() und sei() oder einem ähnlichen Mechanismus gesperrt werden. In einem Event-Handler darf ebenfalls kein PT_SEM_WAIT verwendet werden, da dieses intern auf PT_WAIT zurückgreift, was in einem Handler nicht verwendet werden darf. Ein weiteres kleines Manko ist es, dass eine Try-Funktion fehlt, die entweder den kritischen Abschnitt betritt oder mit einem Fehlerwert sofort zurückkehrt, statt an dieser Stelle zu warten Protosockets Contiki bietet zur Kommunikation zwischen Prozessen die Protosockets. Sie sind eine leichtgewichtige Implementation, die ein Interface ähnlich der BSD-Sockets anbieten. (PSOCK_INIT, PSOCK_SEND_STR, PSOCK_READBUF,...) Da die Implementierung der Protosockets auf Protothreads zurückgreift, sind sie mit den selben Problemen behaftet. So sind sie z. B. an einen Protothread geknüpft. Auf einem Protosocket kann also nie mehr als ein Protothread arbeiten (siehe [PARENCITE(Contiki:Doc)] Protosockets library) Speicherverwaltung Das dynamische Anfordern von Speichersegment ist auf eingebetteten System wenig üblich, da der Speicher sowieso knapp ist und das dynamische Anfordern zusätzlichen Speicher für die Verwaltung der Segmente verbraucht. Trotzdem bietet Contiki drei verschiedene Möglichkeiten, falls es unbedingt benötigt wird. memb Über das Memory Block Management wird zur Compilezeit über MEMB eine feste Anzahl gleichgroßer Speichersegmente reserviert. Diese können dann zur Laufzeit über memb_alloc angefordert und über memb_free freigegeben werden (siehe [PARENCITE(Contiki:Doc)] Memory block management functions). 9

15 2. Implementationsaspekte Tabelle 2.1.: Vergleich der Mechanismen zur Speicherverwaltung Mechanismus Blockgrößen Fragmentierung Addressierung memb fest nein direkt memm beliebig nein indirekt malloc beliebig ja direkt mmem Der Managed Memory Allocator erlaubt es zur Laufzeit zu entscheiden, wie groß ein angefordert Speicherbereich sein soll (z. B. für Strings). Um den Speicherbedarf klein zu halten, werden auch nach der Anforderung die Speicherbereiche automatisch umsortiert. Daher ist hier dann eine indirekte Adressierung des gewünschten Speicherbereiches notwendig (siehe [PARENCITE(Contiki:Doc)] Managed memory allocator). malloc Zusätzlich stehen in der stdlib.h die bekannten C-Funktionen malloc, calloc, realloc und free zur Verfügung. Die angeforderten Speicherbereiche werden im Gegensatz zu memm nicht umsortiert, müssen also nicht indirekt adressiert werden. Der Speicher wird mittels eines Heaps verwaltet. Dadurch kann es zur Fragmentierung und damit zum unnötigen Speicherverbrauch kommen. Deshalb sollte auf diese Funktionen möglichst nicht zurückgegriffen werden [AUTOCITE(ContikiWiki:malloc)]. Generell sind memb und memm zu bevorzugen. Die Entscheidung für einen der Mechanismen muss jedoch von Fall zu Fall erfolgen. (siehe Tabelle 2.1) 10

16 3. Network Stack Implementation Dieses Kapitel behandelt den Netzwerk-Stack (NetStack) und seine Implementationsweise. Dieser nimmt in Contiki-OS eine besondere Stellung ein, weswegen die Anfordrungen an den NetStack zuerst behandelt werden. Da die Kommunikation der Sensorknoten untereinander bestimmte Eigenschaften erfordert, werden im folgenden Abschnitt Grundlagen der Kommunikation in Sensornetzen vermittelt. Danach wird das Konzept bzw. der Aufbau des NetStacks gezeigt sowie deren Funktionalitäten erläutert. Zuletzt wird der Ablauf beim Versenden und Empfangen einer Nachricht beispielhaft demonstriert. Bei der Analyse des Contiki NetStacks ist vor allem der Quelltext von Contiki [AUTOCI- TE(Contiki:GitHub:2.6rc0)] analysiert worden, da der Ablauf aus diesem am besten zum Ausdruck kam. Nichtsdestotrotz existieren auch wissenschaftliche Arbeiten über Teilbereiche des Contiki NetStacks. Über das ContikiMAC Radio Duty Cycling Protokoll findet sich beispielsweise viel Material [AUTOCITE(dunkels11contikimac, ko12pragmatic, duquennoy11lossy)]. Aber auch allgemein zur Kommunikation zwischen Sensorknoten wird viel geforscht [AUTOCITE(lunden11politecast, dunkels11announcement, durvy08making)] Anforderungen an den Netzwerk-Stack in Contiki Da Contiki ein internetfähiges Betriebssystem darstellen soll, benötigt es einen Netzwerk- Stack. Ferner ist Contiki für verschiedene eingebettete Systeme mit unterschiedlichsten Hardware-Ausstattungen gedacht. Das eine eingebettete System möchte lediglich einen IPv4-Stack benutzen, das andere wiederum einen IPv6-Stack, ein weiteres soll lediglich Mesh-under-Routing-Funktionalität bieten. Hierzu bietet Contiki einen Netzwerk-Stack (NetStack), der sich flexibel auf verschiedene Bedürfnisse anpassen lässt. Dennoch soll die Flexibilität nicht all zu groß sein, sonst wirkt sich dieses negativ auf die Überschaubarkeit aus. Damit dieses Kapitel nicht den Rahmen sprengt, wird lediglich der Netzwerk-Stack behandelt, nicht aber die uip-implementation oder die Routing-Protokolle Grundlagen der drahtlosen Kommunikation in Sensornetzen Mehrere drahtlos kommunizierende Sensorknoten bilden ein drahtloses Sensornetz (engl. wireless sensor network ). Dabei formen die Sensorknoten ein infrastruktur-basiertes oder sich selbst organisierendes Ad-hoc-Netz. Diese Ad-hoc-Netze sind vermascht (engl. mesh ), d. h. jeder Knoten ist mit einem oder mehreren anderen Knoten verbunden. Zu übertragene Informationen werden über Sensorknoten, welche Routing-Funktionalitäten (Routing-Knoten) 11

17 3. Network Stack Implementation besitzen, weitergereicht, bis diese Informationen ihr Ziel erreicht haben. Es findet somit eine Multi-Hop-Kommunikation statt. Oft wird ein Sensorknoten zum Coordinator des Sensornetzes ernannt, der dann die Aufgabe hat, das Übertragungsmedium zu organisieren. Da es sehr viele Knoten in einem solchen Netz gibt und Anzahl sowie Standorte dieser Knoten variieren können, muss man von einem unvorhersagbaren und dynamischen Verhalten der Knoten ausgehen. Zum einen können neue Knoten während des Betriebes hinzukommen, andere können ausfallen. Damit ist die Netztopologie nicht sicher, wodurch Netzprotokolle für Sensornetze genau diese Eigenschaft berücksichtigen müssen. Aus diesem Grund wird zur Zeit im Bereich Sensornetze zu den Netzprotokollen sehr viel geforscht Aufgaben der Netzprotokolle Zusammen mit den Eigenschaften der Sensorknoten muss eine Kommunikation geschaffen werden, die mindestens folgende Aufgaben erfüllt: Daten so effizient wie möglich übermitteln Energiereserven der Sensorknoten schonen, d. h. (batteriebetriebene) Knoten sollten möglichst lange Schlafzeiten haben energieintensive Bauteile wie den Funksensor so oft wie möglich ausschalten bei Ausfall von Routing-Knoten Alternativwege verwenden, sofern vorhanden Daten vorhalten, bis Ziel erreichbar ist klassische Kommunikationsprobleme in Rechnernetzen auf ein Minimum reduzieren Da man nicht allen Aufgaben gerecht werden kann, gilt es Netzprotokolle zu finden, die ein Optimum für die jeweiligen Systemanforderungen darstellen. Beispielsweise besitzt ein Sensornetz zur Hausautomatisierung andere Systemanforderungen als ein Sensornetz, das die Kommunikation innerhalb eines Roboterschwarms sicher stellt. Das Verhalten der Netzknoten lässt sich dabei in vier Schritte gliedern: Initialisierung, Tagesablauf, Kommunikationsschema sowie Routing. Initialisierung Neue Netzknoten integrieren sich in das Sensornetz, indem sie ihre Nachbarn detektieren. Die Netztopologie wird verändert. Hierbei ist ein Verfahren gefordert, welches ein erfolgreiches Routing verspricht. Tagesablauf Der Wach-Schlaf-Zyklus (engl. duty cycle ) bestimmt den Tagesablauf eines (batteriebetriebenen) Netzknotens. Das Ziel des Duty-Cycling ist es, möglichst lange Schlafzeiten zu erreichen. Wenn benachbarte Knoten eines Senders beteiligt werden, obwohl sie nicht Empfänger der Nachricht sind, spricht man von Overhearing. Overhearing ist in Sensornetzen zu vermeiden, weil das Mithören Zeit und Energie kostet. Es gibt in der Forschung Bestrebungen, Duty-Cycling und Overhearing sinnvoll zu verbinden: CITETITLE(Thesis:VereinbarkeitRDCOverhearing) [AUTOCITE(Thesis:VereinbarkeitRDCOverhearing)]. 12

18 3. Network Stack Implementation Kommunikationsschema Dieses Schema beschreibt, wie ein einzelner Datenaustausch zwischen zwei Sensorknoten abläuft, wobei die Übertragungsgeschwindigkeit und auch Fehlerfreiheit wichtige Kriterien sind. Zusätzlich dürfen sich die Netzknoten nicht gegenseitig stören. Routing Im Gegensatz zum Kommunikationsschema beschreibt Routing den Pfad durch das Sensornetz vom Sender zum Empfänger. In einem vermaschten Netz können dazu mehrere Pfade existieren. Das Ziel des Routings sollte vor allem die ausgewogene Netzauslastung sein, d. h. es muss nicht immer der kürzeste Pfad gewählt werden, sonst kann es zur einseitigen Netzbelastung und sogar zum Ausfall wichtiger Netzknoten kommen Unterschied zu herkömmlichen Netzprotokollen Untersuchungen haben gezeigt, dass herkömmliche Netzprotokolle wie IEEE oder CSMA die Lebensdauer der Netzknoten stark herabsenkt: In herkömmlichen Netzprotokollen wird erwartet, dass ein Empfänger ständig empfangsbereit ist. Nutzloses Mithören (engl. idle listening ) am Medium verschwendet viel Energie, weil der Sensorknoten während dieser Zeit nicht schlafen kann. Wenn eine Kollision auftritt und damit das Paket erneut übertragen wird, steigt der Energieverbrauch und auch die Latenz, insbesondere, wenn es sich um ein großes Paket handelt. Auch ist der Overhead durch Kontrollpakete gering zu halten, da Kontrollpakete keine Sensordaten enthalten und alle Sensorknoten ein gemeinsames Primärziel verfolgen. Aufgrund der Anforderung, dass ein Sensornetz ein Gesamtziel verfolgt, hebt es sich zusätzlich von anderen Ad-hoc-Netzen ab. Es existieren somit nicht viele verschiedene Anwendungen, die um die gemeinsame Ressource, den Übertragungskanal, konkurrieren, sondern nur eine einzige. Anders formuliert bedeutet dieses, dass die Sensornetz- Anwendung quasi mit sich selbst konkurriert. Damit besteht nur ein geringes Bestreben, Fairness zwischen allen Netzknoten zu erreichen Konzept des Contiki NetStacks Da ein eingebettetes Betriebssystem wie Contiki-OS auf unterschiedlichsten Sensor- Platformen sowie unterschiedlichsten Bedürfnissen an den Netzwerk-Stack (NetStack) zum Einsatz kommen soll, wurde auf ein flexibles Netzwerk-Stack-System Wert gelegt. Vor allem die unteren, transportorientierten Schichten des OSI-Schichtenmodells sind entscheidend, um das Sensorsystem optimal an die Systemanforderungen anzupassen. Diese transportorientierten Schichten lösen die Aufgaben des Netzprotokolls, die in Unterabschnitt beschrieben sind. Bitübertragungsschicht Die physikalische Schicht (Bitübertragungsschicht) steuert den Funksensor (Radio) an und nennt sich Radio Driver. 13

19 3. Network Stack Implementation Sicherungsschicht Über der physikalischen Schicht befindet sich die Data Link-Schicht (Sicherungsschicht). Beide Schichten steuern den Zugriff auf das Übertragungsmedium. Die zu versendenen und empfangenen Nachrichten werden häufig in Frames gepackt, welche Größe und weitere Eigenschaften der Nachricht in einem Header speichern. Hierzu kommt in Contiki der Framer zum Einsatz. Die Sicherungsschicht besteht wiederum aus den Schichten Logical Link Control (LLC) und Medium Access Control (MAC): Medium Access Control (MAC) Da in eingebetteten Systemen die Energieeffizienz besonders wichtig ist, wurde das MAC-Protokoll in zwei Ebenen eingeteilt: Der untere Layer ist für den Radio Duty Cycle (RDC) verantwortlich und sorgt damit für das Sparen der Energie. Der obere ist für die Steuerung des Zugriffs auf das Übertragungsmedium zuständig. Logical Link Control (LLC) Für die LLC-Schicht ist in Contiki kein separate Ebene bereitgestellt worden. Einige Netzwerk-Stacks wie das ZigBee Protocol benötigen die LLC-Schicht nicht, weil eine leichtgewichtige Netzwerkarchitektur gefordert war. Das Sensornet Protocol (SP) nutzt einen SP-Adaption Sublayer, der sich im Prinzip auf der selben Höhe der LLC-Schicht befindet. Dadrüber befindet sich das Sensornet Protocol, welches als eine Bridge angesehen werden kann, um eine Koexistenz mehrerer Netzwerk-Protokolle zu erreichen. [AUTOCI- TE(he2007implSPforContiki)] Vermittlungsschicht Die dritte OSI-Schicht ist die Netzwerk-Schicht (Vermittlungsschicht) und stellt auch in Contiki netzübergriefende Adressen bereit und organisiert das Routing zwischen Netzknoten. Zusammenfassend gliedert sich die Implementation des Contiki NetStacks in folgende fünf Schichten (engl. layer ): Radio Driver, Framer, RDC Driver, MAC Driver und Network Driver. Ein Vergleich zwischen dem OSI-Referenzmodell und den Contiki NetStack Schichten ist in Abbildung 3.1 zu sehen. Da der Netzwerk-Stack in fünf voneinander losgelösten Schichten konzipiert ist, die über vorgegebenen APIs miteinander kommunizieren. Dadurch ist die Implementation einer Schicht von den anderen Schichten unabhängig austauschbar und der Contiki NetStack flexibel auf unterschiedliche Anwendungen anpassbar. Alle über der Netzwerk-Schicht liegenden Schichten sind nicht direkt Teil des Netzwerk- Stacks, da sich ihre Implementationen sehr stark unterscheiden und damit keine sinnvolle API gebildet werden kann. Bei der Erstellung des anwendungsspezifischen Netzwerk-Stacks müssen die verwendeten Protokolle auf Kompatiblität zueinander geprüft werden. Auch ist es sinnvoll, alle Netzknoten eines Sensornetzes mit dem gleichen Netzwerk-Stack auszustatten. 14

20 3. Network Stack Implementation 3 Vermittlung (Network) Network Driver 2 Sicherung (Data Link) 1 Bitübertragung (Physical) MAC Driver RDC Driver Framer eingehende Nachricht ausgehende Nachricht Radio Driver Abbildung 3.1.: Contiki NetStack Konzept 3.4. Funktionsweise In diesem Abschnitt wird jeder der fünf Contiki Netzwerkschichten und ihre Aufgaben beschrieben. Ziel ist es hierbei, ein Verständnis für den Aufgabenumfang eines Treibers im Contiki NetStack zu entwickeln. Im folgenden Abschnitt 3.5 wird dann am Beispiel eines konkreten Contiki NetStacks das Empfangen und Versenden einer Nachricht demonstriert Radio Driver Der Radio Driver steuert den Funksensor an und ist im Allgemeinen für das Senden und Empfangen von Nachrichten zuständig. Der Funksensor ist dabei entweder direkt im Mikrocontroller integriert (1-Chip-Lösung) oder über ein allgemeines Interface am Mikrocontroller angeschlossen (2-Chip-Lösung). Daher ist ein Radio Driver keine CPU- oder platformunabhängige Implementation. Die meisten Hersteller von Funksensoren implementieren einen größeren Funktionsumfang, als es nötig wäre. So können bestimmte Funk-Funktionalitäten, wie das automatische Senden eines Ack-Signal zur Mitteilung des Erhalts eines Pakets, an die Hardware übergeben werden. So muss dieses nicht in der Software gelöst werden, was zur Folge hat, dass Funksensoren i. A. für bestimmte Standards ausgelegt sind: Der Funksensor AT86RF230 ist beispielsweise besonders für die Standards IEEE , ZigBee, 6LoWPAN (und weitere) geeignet. Er besitzt einen besonderen IEEE Hardware Support und erleichert die Software um folgende Funktionalitäten: Clear Channel Assessment (CCA), Energy Detection, Berechnung der Frame Check Sequence (FCS, CRC), automatisches CSMA/CA, 15

21 3. Network Stack Implementation automatische, erneute Übertragung eines Frames, automatisches Bestätigen des Erhalts eines Frames (ACK-Signal), automatisches Filtern von Adressen. Das Umsetzen solcher Funktionalitäten auf der Hardwareebene erfordert einen besonderen Umgang im Netzwerk-Stack. Höhere Schichten müssen herausfinden, ob diese Funktionalitäten auf der Hardware umgesetzt werde können. In C können hierzu einfach Makros verwendet werden, welche con Contiki auch genutzt werden, um einzelne Hardwarefunktionen zu aktivieren Framer Bei eingehenden Nachrichten hat der Framer die Aufgabe, den Payload der Nachricht vom Frame zu separieren sowie die Informatonen, die im Frame stecken, lesbar in einem Nachrichten-Puffer für die Netzwerk-Schichten aufzubereiten. Im Framer selbst werden diese Informationen nicht verarbeitet. Dies geschieht dann in den jeweilig zuständigen Schichten. Bei ausgehenden Nachrichten werden die Informationen, die die Netzwerk-Schichten im Nachrichten-Puffer vorbereiet haben, in ein Frame verpackt, so dass der Framer des Empfängers diese Informationen lesen kann. Daher ist es wichtig, auf allen Netzknoten denselben Framer zu verwenden. Deswegen wurde in Bezug auf Sensornetze der Standard IEEE entwickelt, um einen einheitlichen Nachrichtenaustausch (auf den unteren zwei Netzwerk-Schichten) sicherzustellen. Da IEEE sowohl auf der Bitübertragungsschicht sowie auf der Sicherungsschicht arbeitet, muss der Framer eng mit der MAC-Schicht sowie der RDC- Schicht zusammenarbeiten RDC Driver Der Radio Duty Cycling Driver kümmert sich darum, dass der Funksensor i. d. R. nicht länger als nötig in Betrieb ist. Der Funksensor wird also so oft wie möglich aus- und zu entsprechenden Zeiten wieder eingeschaltet. Um einen energiesparsamen Betrieb zu gewährleisten und um regelmäßig emfangsbereit zu sein, gibt es in der Forschung viele Protokollansätze, die unter dem Begriff Radio Duty Cycling Protokolle oder auch Low Power MAC Protokolle fassen kann. Einige dieser Ansätze sind nur in bestimmten Sensornetzanwendungen sinnvoll, weshalb es in Contiki für diese Funktionalität eine extra Netzwerk-Schicht, die RDC-Schicht, gibt. Der RDC Driver liegt folglich zwischen dem Radio Driver und dem MAC Driver. Weil der Radio Driver hardwareabhängig implementiert ist und der RDC Driver hardwareunabhängig, ist es sinnvoll, dass der RDC Driver den Framer anweist, das Nachrichtenpaket zu parsen oder in eine Frame zu verpacken. In Contiki gibt es für den RDC Driver verschiedene implementierte Protokolle: Eines dieser so genannten Low Power MAC-Protokolle ist ContikiMAC, welches i. A. in Contiki 16

22 3. Network Stack Implementation als Standardpotokoll verwendet wird. Es befindet sich in Contiki aber auch ein Protokoll, das das Low Power Probing (LPP) umsetzt, sowie das weiter verbreitete X-MAC und die kompaktere Variante CX-MAC. Im Gegensatz zu den Low Power MAC-Protokollen gibt es in Contiki auch Implementierungen, die keinen Radio Duty Cycle verwenden: In diesem Bereich ist die NullRDC Implementierung die aktuellste. Gleichfalls existiert eine Variante, welche weder einen RDC verwendet noch einen Framer einsetzt: der NullRDC NoFramer. Bei diesen (einfachen) Protokollen bleibt der Funksensor i. A. dauerhaft eingeschaltet, wodurch kein energieeffizientes Arbeiten sichergestellt ist. Deshalb sind diese nicht auf Energieeffizienz bedachten Protokolle nur bei einem Full Function Device (FFD) einzusetzen, da sie i. d. R. nicht batteriebetrieben sind. Ein Reduced Function Device (RFD) unterscheidet sich dadurch vom FFD, dass es nicht den vollen standardisierten Funktionsumfang bieten muss, wodurch allerdings keine Kommunikation mit einem anderen RFD möglich ist. Allgemein gewinnen in der Informatik energiebewusste Technologien immer mehr an Bedeutung, wodurch ein Radio Duty Cycle auch bei einem Full Function Device eingesetzt werden sollte MAC Driver Der MAC Driver setzt die Anforderungen der MAC-Schicht um, d. h. er muss sich um die Organisation des Übertragungsmediums kümmern. Hierbei ist es sinnvoll die Funktionalitäten des Radio Drivers einzubeziehen, um bereits in Hardware implementierte Funktionen zu verwenden. In Sensornetzen mit batteriebetriebenen Netzknoten wird es immer wieder vorkommen, dass Netzknoten nicht erreichbar sind, weil sie gerade schlafen. Diese Schlafzyklen werden schließlich vom RDC Driver bestimmt, so dass dieser der MAC-Schicht Informationen zukommen lassen kann, wie die eigenen Schlafzyklen sich verhalten. Aber er kann auch schätzen, wie sich das Schlafverhalten der anderen Netzteilnehmer verhält, da man i. d. R. davon ausgehen kann, dass alle Netzteilnehmer das gleiche RDC- Protokoll verwenden. Hieraus kann der MAC Driver bestimmen, wann es sinnvoll ist unter Einhaltung der Funk-Zeiten des MAC-Protokolls, dem Empfänger die Nachricht zu schicken. So kann in Zusammenarbeit mit dem RDC Driver, die Funkkommunikation auf ein Mindestmaß reduziert werden. Auf der anderen Seite arbeitet der MAC Driver mit dem Network Driver zusammen: Dieser nimmt zum einen von Network Driver zu versendene Nachrichtenpakete entgegen und leitet sie zu bestimmten Zeiten an den RDC Driver weiter. Zum anderen werden empfangene Nachrichten an den Network Driver weitergeleitet, sofern die empfangenen Nachrichten für den eigenen Netzknoten bestimmt sind. 17

23 3. Network Stack Implementation Tabelle 3.1.: Überblick zu den implementierten Treibern in Contiki 2.6 Network MAC RDC Framer Radio SicsLoWPAN CSMA ContikiMAC IEEE AVR rf230 (bb) 2 RIME TDMA 1 X-MAC NullMAC TI cc2430 rf CTDMA 1 CX-MAC TI cc2530 rf RIME UDP LPP ARM stm32w NullMAC NullRDC NullRDC NoFramer Die hier vorgestellten Implementationen wurden nicht auf Vollständigkeit getestet. 1 TDMA und CTDMA wurden seit Version 2.6.x aus Contiki entfernt [CITE(Contiki:GitHub)]. 2 rf 230_bb ist die überarbeitete Version des Funkmoduls rf Network Driver Der Netzwerk Driver stellt die Funktionalität der Vermittlungsschicht bereit. Hierzu zählt insbesondere das Bereitstellen von netzwerkübergreifender Adressen, das Routing und Verwalten von Routingtabellen sofern gewünscht sowie allgemein der Aufbau von Paketen. Da Nachrichten länger als die im Framer festgelegte, maximale Breite sein können, müssen diese Nachrichten in Fragmente unterteilt werden. Das Einteilen in Fragmente, sofern erforderlich, sowie das Zusammenfügen einer Reihe von empfangener Fragmente übernimmt der Network Driver. Hierzu bietet sich in Contiki der weit verbreitete Standard 6LoWPAN. Eine Alternative ist der RIME Stack. der einen Satz leichtgewichtiger Kommunikationsprimitiven bietet: von best-effort anonymous local area broadcast bis hin zu reliable network flooding [AUTOCI- TE(dunkels07adaptive)] Senden und Empfangen von Nachrichten Mit der Entwicklung von IPv6 ist es möglich geworden, jedem Gerät (Ding ) eine eigene Internet-Adresse zu geben. Das Internet der Dinge (engl. Internet of Things ) ermöglicht also, das komplette Sensornetz mit dem Internet zu verbinden. Dieses Sensornetz wird dann zum Wireless Embedded Internet. Damit die Anbindung möglichst transparent ist, wurde versucht, IPv6 auf Sensorknoten zu implementieren. Da aber das komplette Internet Protokoll sehr umfangreich ist, wäre der Energieverbrauch und auch der Speicherplatzbedarf der Implementierung drastisch gestiegen. Daher wurde eine leichtgewichtige Variante des IPv6 entwickelt: IPv6 over Low power Wireless Personal Area Networks (6LoWPAN). Da dieses Protokoll sich weitgehend durchgesetzt hat, wird das Senden und Empfangen von Nachrichten anhand der 6LoWPAN-Implementierung erläutert. Um genauer zu sein, wird der in Tabelle 3.2 gezeigte Netzwerk-Stack betrachtet. 18

24 3. Network Stack Implementation Tabelle 3.2.: Contiki NetStack Beispiel. Zu sehen ist der Vergleich zwischen dem 6LoWPAN- Stack und die Implementation in Contiki. 6LoWPAN NetStack Contiki NetStack OSI-Schicht Protokoll Contiki-Schicht Implementation 4 Transport UDP uip-udp 3 Vermittlung IPv6 / ICMPv6 Network Driver SicsLoWPAN (uipv6) - Adaptation 1 6LoWPAN Adaptation 2 Sicherung IEEE MAC MAC Driver CSMA RDC Driver X-MAC 2 1 Bitübertragung IEEE PHY Framer Framer Radio Driver rf 230_bb 1 6LoWPAN fügt in das OSI-Referenzmodell eine neue Schicht ein: der Adaptation Layer. 2 6LoWPAN definiert keinen genauen RDC. In Contiki wird oft ContikiMAC als Default verwendet Empfangen einer 6LoWPAN-Nachricht Radio Driver Jeder Empfang einer Nachricht wird mit einem Interrupt beim AVR-Mikrocontroller eingeleitet. Dadurch weiß der Radio Treiber rf230 bb, dass im Nachrichten-Puffer des Funksensors die Nachricht zum Lesen bereitliegt. In Contiki ist es sinnvoll, hierfür einen Prozess zu erstellen, der sich um den Empfang und die weitere Verarbeitung der Nachricht kümmert. Die ISR pollt diesen Prozess, wodurch der Interrupt möglichst schnell verlassen wird und die CPU für andere wichtige Aufgaben wieder zur Verfügung steht. Sobald der Empfangsprozess an der Reihe ist, wird der Paket-Puffer geleert und das Paket aus dem Nachrichten-Puffer des Funksensors in den Paket-Puffer gelesen. Die read-operation ist ein kritischer Abschnitt, in welchem Interrupts kurzfristig deaktiviert werden müssen. Damit wird verhindert, dass die ISR nicht den gleichen Puffer beschreibt, von dem gerade gelesen werden soll. Nun wird die RDC-Schicht über die Ankunft einer neuen Nachricht mittels input- Callbacks informiert. RDC Driver Nach Tabelle 3.2 kommt nun die X-MAC-Implementation zum Einsatz. Der input-callback ruft also die Funktion input_packet auf. Diese Funktion muss zuerst die empfangene Nachricht parsen, weshalb nun der Framer zum Einsatz kommt. Wenn man beispielsweise den RDC Driver NullRDC NoFramer verwendet, dann erwartet der Empfänger, dass die Nachricht wie der Name besagt in keinem Frame-Format vorliegt. 19

25 3. Network Stack Implementation Nach dem Parsen der Nachricht durch den Framer untersucht der Empfänger mit Hilfe eines Packet Dispatchers, um welche Art von Paket es sich handelt: Im Falle von X-MAC kann dies ein Strobe-, ein Strobe-ACK-, ein Announcement- oder Data-Paket sein: Letzteres beinhaltet die eigentliche Nachricht und die ersten drei koordinieren den Datenaustausch zwischen zwei Sensorknoten. Wann welches Paket verschickt wird und wie der Schalf-Rhythmus aussieht, wird im Kommunikationsschema festgelegt. Wenn der Paket-Typ festgestellt wurde, wird bei einigen Paket-Typen die Zieladresse überprüft. Wenn diese nicht mit unserer übereinstimmt oder die Nachricht kein Broadcast war, so wird das Paket ebenfalls verworfen. Data-Paket Bei einem Data-Paket wird die Sequenznummer mit den letzten paar empfangenen Paketen verglichen, damit doppelte Pakete sofort verworfen werden können. Außerdem wird der Funksensor deaktiviert, um Energie zu sparen. Sobald das Paket verarbeitet wurde, kann der gesamte Mikrocontroller sich schlafen legen. Strobe-Paket Bei einem Strobe-Paket ohne Empfängeradresse wird bei X-MAC davon ausgegangen, dass ein Broadcast-Paket folgt, so dass in diesem Fall der Funksensor aktiv bleibt bzw. angeschaltet wird. Announcement-Paket Da regelmäßige Beacon-Pakete sehr energieaufwändig sind, um ein Sensornetz zu organisieren, ist die Idee eines Announcemnt Layers [AUTO- CITE(dunkels11announcement)] entstanden. Hierbei werden vor allem mehrere Beacons in einem Announcement-Paket gesammelt, um die Anzahl der Übertragungen zu minimieren und somit Energie zu sparen. Dieses Feature kann auch bei X-MAC in Contiki aktiviert werden, ist für diese Betrachtung aber nicht relevant. Da bei RDC Protokollen auch Low power MAC-Protokolle genannt i. d. R. davon ausgegangen wird, dass sowohl Empfänger als auch Sender das gleiche Protokoll verwenden, ist es ausreichend, nur Data-Pakete an den eigentlichen MAC Driver weiterzureichen. Es ist durchaus denkbar, dass weitere Eigenschaften an höhere Schichten weitergegeben werden können wie beispielsweise der akkumulierte Energieverbrauch beim Senden und Empfangen. Framer Nach Tabelle 3.2 ist der Framer verwendet worden. Der Empfanger erwartet folglich, dass die Nachricht im IEEE Format vorliegt. Der Parser stellt fest, ob die PAN-ID in der Nachricht der eigenen entspricht oder ob es sich um eine Broadcast-PAN-ID handelt. Wenn die Nachricht nicht die eigene oder die Broadcast-PAN-ID enthält, wird das Paket verworfen. Andernfalls ist die Nachricht entweder für das PAN-Netzwerk 1 bestimmt oder es handelt 1 Nach IEEE wird die PAN-ID dazu benutzt, um das Netzwerk in unterschiedliche Cluster einzuteilen. Jeder Cluster hat seinen eigenen PAN-Coordinator. Daneben gibt es noch einen First-PAN-Coordinator, der alle Cluster koordiniert. 20

26 3. Network Stack Implementation sich um einen Broadcast. In beiden Fällen wird der Paket-Puffer mit den in der Nachricht befindlichen Informationen gefüllt: Hierzu zählt die Adresse des Senders und Empfängers, die Paket-ID sowie ein Prending-Flag. Nun wird die Länge des IEEE Overheads 2 an den RDC Driver zurückgegeben, damit dieser sofort entsprechende Maßnahmen ergreifen kann, falls die Länge des Overheads nicht dem Standard entspricht oder ein Fehler aufgetreten ist. MAC Driver Beim Empfangen einer Nachricht hat der CSMA MAC Driver nicht viel zu tun: Er nimmt lediglich die Information vom RDC Driver entgegen, dass eine Nachricht eingegangen ist und leitet diese direkt an die Netzwerk-Schicht weiter. Network Driver Der Network Driver SicsLoWPAN kann nun das 6LoWPAN-Paket verarbeiten und im Falle einer fragmentierten Nachricht den kompletten Nachrichten-Payload wieder zusammensetzen. Das Fragmentieren und Wiederzusammensetzen ist die Aufgabe des 6LoWPAN- Adaptation Layers, welcher damit in den Network Driver integriert ist. Sofern ein Prozess einen Callback hinterlegt hat, so wird dieser Prozes nun über eine neue, eingehende Nachricht informiert, Danach wird der TCP/IP-Prozess benachrichtigt, indem die tcpip_input-funktion ein PACKET_INPUT-Event beim TCP/IP-Prozess erzeugt. Höhere Schichten Die Netzwerk-Schicht hat damit die Kontrolle über das Paket an die Transport-Schicht abgegeben, welche wiederum die jeweiligen Anwendungsschichten informiert. Beispielsweise könnte ein Sender dem Empfänger eine Nachricht mittels UDP an den Port der CoAP-Anwendung geschickt haben Versenden einer 6LoWPAN-Nachricht Höhere Schichten Angenommen wir haben eine Anwendung, die das Constrained Application Protocol (CoAP) verwendet. Dann möchte diese Anwendung mittels UDP eine Nachricht versenden. Mittels der Funktion uip_udp_packet_send wird eine CoAP-Nachricht an einen bestimmten Port eines anderen Netzknoten gesendet. Wenn IPv6 aktiviert ist, dann wird tcpip_ipv6_output aufgerufen, welche die Nachricht an den Network Driver über einen Callback weitergibt. Dieser Callback wird beim Initialisieren des Network Drivers übergeben: Die TCP/IP- Schnittstelle definiert den Callback outputfunc, welcher mit der Funktion output des Network Drivers 6LoWPAN verbunden ist. Network Driver Der 6LoWPAN-Network Driver nimmt mit Aufruf der Funktion output das IP-Paket entgegen und formatiert es so, dass es über ein IEEE Netzwerk versendet werden 2 Die Länge des IEEE Overheads errechnet sich durch die Länge der Nachricht minus der Länge des Payload. 21