IP-basierter Transport von Daten aus Sensornetzwerken

Inhaltsverzeichnis

1) Einführung

2) Entwurf des Gateway Systems
2.1) Mögliche Wide-Area Übertragungstechniken
2.2) Umsetzung der Datenformate

3) Analyse der Einsatzszenarien
3.1) Standalone Einsatz mit WLAN-Zugriff
3.2) Standalone Einsatz mit Zugriff per LAN
3.3) Standalone Einsatz im Netzwerk, Datensenke im gleichen Netz
3.4) Standalone Einsatz im Netzwerk, Datensenke in fremdem Netz
3.5) Standalone Einsatz in unbekanntem Netzwerk
3.6) Datenquelle in einem Mesh Netzwerk, Zugriff per WLAN
3.7) Datenquelle in einem Mesh Netzwerk, Zugriff aus fremdem Netzwerk
3.8) Zusammenfassung

4) Implementierung
4.1) Auswahl der Hardware
4.2) Betriebssystem
4.3) USBBridge
4.4) Tunnel
4.5) Routing
4.6) Tools

5) Evaluierung des IP-basierten Transportes
5.1) Aufbau des Tests
5.2) Erzeugung des Traffics
5.3) Zugriff per LAN
5.4) Direkter WLAN-Zugriff
5.5) Zugriff über Mesh-Netzwerk

6) Anwendungen
6.1) XBridge
6.2) Büroüberwachung über Mesh-Netzwerk
6.3) Heimüberwachung

7) Zusammenfassung und Ausblick
Danksagung
Literaturverzeichnis
Anhang

A) Konfigurationen des Gateways

B) Tools für den Betrieb des Gateways

1) Einführung

In verteilten Sensornetzwerken, die beispielsweise mit den verschiedenen am TecO entwi­ckelten Particles aufgebaut werden können, entstehen größere Mengen an Meßdaten. Diese müssen zwecks Verarbeitung und Archivierung zu leistungsfähigen Backend-Systemen transportiert werden, da die Verarbeitung und Speicherung der gewonnenen Daten auf den Sensorknoten aufgrund der sehr eingeschränkten Prozessorleistung und Speicherkapazität nur sehr eingeschränkt möglich ist.

Ein direkter Transport der Daten von den Sensorknoten bis hin zu den Backend-Systemen ist hierbei aufgrund der verschiedenen Netzwerksysteme auf dem Weg vom Sensorknoten zum Backendrechner nicht praktikabel. Die Daten müssen daher in der un­mittelbaren Um­gebung der ausgebreiteten Sensor­knoten gesammelt und mit leistungsfä­higeren Systemen zu den Backend-Systemen trans­portiert werden.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 1.1: Einordnung des Gateways in die vorhandene Infrastruktur

Abbildung 1.1 zeigt die Einordnung des neu zu entwerfenden Systems in die vorhandene Infrastruktur. Um die Daten eines bestimmten Sensorknotens zu einem Zielrechner weiter­zuleiten werden diese Daten lokal in der nähe des Sensorknotens vom Gateway empfangen und über eine vorhandene Infrastruktur zum Zielrechner hin weitergeleitet.

Im Rahmen dieser Studienarbeit soll ein neues System entwickelt werden, mit dem das Einsammeln und Transportieren der durch die Sensorknoten gewonnenen Daten auch ohne bestehende Netzwerkinstallation möglich ist, falls vorhanden soll diese aber auch ge­nutzt werden können. Das Hauptaugenmerk soll hierbei auf den verbreiteten Technologien LAN für die kabelgebundene Weiterleitung und WLAN / Wifi für die kabellose Weiterlei­tung liegen.

Um die Nutzung von WLAN und LAN zu ermöglichen und um die Daten über diese Sy­steme zu den Backendrechnern transportieren zu können, muss das neue System nicht nur eine physikalische Umsetzung der Daten vom Particle Funkverkehr auf LAN und WLAN ermöglichen, sondern auch die Datenpakete vom proprietären Particle Paketformat auf standardkonforme IP-basierte UDP- oder TCP-Pakete übersetzen können.

Ziel der Studienarbeit ist es, durch eine Kombination von verteilten Sensorknoten, die mit sehr kleiner Funkstärke kommunizieren, und einer Wide-Area Kommunikationstechnik ei­nen weiträumigeren Transport der Sensordaten ohne Kabelbindung zu ermöglichen. Das Vorgehen wird dabei sein, zuerst die in Frage kommenden Wide-Area Übertragungstech­niken zu sondieren und ein geeignetes System auszuwählen. Vor der eigentlichen Imple­mentierung des Systems werden dann die gewünschten Einsatzszenarien diskutiert, welche Voraussetzungen während der Implementierung geschaffen werden müs­sen, um den Be­trieb im jeweiligen Szenario zu ermöglichen. Nach einer anschließenden Evaluierung der Übertragungsleistung des Systems wird das neue Gateway abschließend in einigen Anwen­dungsfällen auch praktisch getestet.

2) Entwurf des Gateway Systems

2.1) Mögliche Wide-Area Übertragungstechniken

Auch wenn es in den letzten Jahren eine Vielzahl an neuen Technologien für die kabellose Datenübertragung gegeben hat, so kommt doch nur ein sehr kleiner Anteil dieser Tech­niken für das gewünschte Einsatzszenario in Frage. DECT (Digital Enhanced Cordless Te­lecommunications) war zwar allgemein für die kabellose Datenübertragung geschaffen und würde die für das Gateway benötigten Entfernungen überbrücken können, hat sich jedoch nur im Bereich von schnurlosen Telefonen durchsetzen können und findet im Bereich Computer keine Anwendung.

Weniger geeignet für den gewünschten Einsatz ist die Datenübertragung über eine auf In­frarot basierenden Kom­munikationstechnik. Zwar gibt es hier mit IrDA einen aner­kannten und verbreiteten Stan­dard, für den heute quasi jeder PC die benötigte Schnittstelle „on Board“ hat, doch die technischen Daten sind für den gewünschten Einsatz nicht ausrei­chend. Die Reichweite wird lt. Spezifikation mit maximal 100cm angegeben, der Abstrahl­winkel mit lediglich 30° [04].

Ein deutlich besser geeignetes System stellt Bluetooth dar. Dies zeigt sich nicht zuletzt an der Tatsache, dass Bluetooth von der ETH Zürich für ein ähnliches Szenario wie das in die­ser Studienarbeit angestrebte verwendet wird. Bei ihrem BTnode Projekt [01] hat die ETH Zürich eine derartige Kombination aus low- und high-Power Funksystem realisiert, in dem ein Chipcon CC1000 Baustein auf einer Platine kombiniert mit einem Bluetooth System aus dem Hause Zeevo. Problematisch beim Einsatz von Bluetooth ist jedoch die Tatsache, dass die Daten mehrmals umgesetzt werden müssen, bis diese an den Backendrechnern verarbeitet werden können: Zuerst vom Sensorfunk Protokoll in Bluetooth und später nochmals von Bluetooth auf IP.

Weitaus besser fällt die Bestandsaufnahme bei WLAN aus. Das System kann mit Rund­strahlantennen, einer Reichweite von bis zu 300 Metern (mit Richtantennen sogar noch deutlich mehr) und Datenraten von 11 Mbit/s und mehr nicht nur auf der technischen Seite überzeugen. Durch die inzwischen extrem hohe Verbreitung von WLAN Hardware und der damit einhergehenden Vielzahl verschiedener Geräte lassen sich gleich von mehreren Her­stellern passende WLAN-Router finden, die alle hardwareseitigen Voraussetzungen mit­bringen um das gewünschte Gateway ohne Hardwareneuentwicklung entwerfen zu kön­nen. Die große Vielzahl an WLAN-Routern auf dem Markt bringt auch eine gewisse Zu­kunftssicherheit des neuen Gateways mit sich. Die WLAN-Technologie ist inzwischen eta­blierte und weit verbreitet, die Verfügbarkeit der entsprechenden Hardware somit sehr gut.

Interessant ist WLAN auch, da es auf dieser Technik basierend mehrere Projekte gibt, in denen Netzwerke aus WLAN-Routern erstellt wurden. Im Linyphi Projekt an der Universi­tät Karlsruhe wurde beispielsweise ein IPv6 peer-to-peer Netzwerk realisiert, das auf WLAN-Routern läuft.

Als WLAN-Technik wird daher WLAN ausgewählt. Ein WLAN-Router wird die Basis des neuen Gateways bilden und sowohl eine LAN- als auch eine WLAN-Schnittstelle zur Kommunikation zur Verfügung stellen.

2.2) Umsetzung der Datenformate

Durch die Auswahl eines WLAN-Routers als Basis für das Gateway ergibt sich der in Ab­bildung 2.1 skizzierte Entwurf für die Kommunikation des Gateways. Wichtig ist hierbei, dass die Datenpakete aus dem dem Sensornetz auf dem Gateway in LAN und WLAN ge­rechte IP-basierte Pakete umgesetzt werden müssen. Eine weitere Betrachtung, ob hier­bei UDP oder TCP zum Einsatz kommen soll, wird später erfolgen.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.1: Entwurf der Kommunikation des Gateways

Daraus ergeben sich gleich mehrere Anforderungen an das Gateway. Auf der einen Seite muss das Gateway in der Lage sein, mit den Sensorknoten auf Basis deren proprietären Pro­tokollen zu kommunizieren, wofür die entsprechende Schnittstelle und eine Implemen­tierung des WSN-Protokolls notwendig sind, auf der anderen Seite muss die IP-basierte Kom­munikation mit den Backend-Systemen möglich sein, wofür ebenfalls sowohl die Schnitt­stelle als auch eine Implementierung des Protokolls benötigt werden. Dazu muss das Gate­way die Pakete in beide Kommunikationsrichtungen umsetzen können.

Während die WLAN- und LAN-Schnittstellen sowie die Implementierung sowohl des In­ternet Protocols (IP) als auch der darauf basierenden Protokolle TCP und UDP auf einem WLAN-Router bereits vorhanden sind, muss die Schnittstelle zur Kommunikation mit dem Sensornetzwerk sowie das dazugehörige Protokoll im Rahmen der Studienarbeit hinzuge­fügt werden. Ebenso muss die Umsetzung der WSN-Pakete auf TCP- bzw. UDP-Pa­kete auf dem neuen Gateway implementiert werden.

Eine Gegenüberstellung typischer WSN-Protokolle mit den auf IP basierenden Technolo­gien zeigt dabei die deutlichen Unterschiede auf, sowohl in Hinblick auf das Paketformat, als auch in Hinblick auf die Art und Weise der Paketweiterleitung und der Adressierung einzelner Endgeräte.

Große Differenzen gibt es bereits beim Aufbau der Pakete. Während bei WSN-Paketen üb­licherweise aus Effizienzgründen nur kleine Paketheader vorhanden sind und diese zum Teil von mehreren Schichten des Übertragungsprotokolls gemeinsam genutzt werden, er­zeugt bei IP-Paketen jede einzelne Schicht des IP-Referenzmodells [05] ihre eigenen Hea­der, auf den nur die jeweilige Schicht Zugriff hat. Diese von den Schichten des IP-Proto­kolls erzeugten Header sind dabei größer als die Header der Sensorpakete. Es entsteht so­mit ein relativ großer Overhead an Verwaltungsdaten. Gleiches gilt für die Kon­trolle der Übertragungsfehler: Während bei der IP-basierten Übertragung jede Schicht ei­nen eigenen CRC berechnet und überträgt genügt bei den verbreiteten WSN-Protokollen ein einziger CRC für alle Schichten.

Ähnlich groß sind die Differenzen, wenn es um die Größe der Pakete geht. Bei IP-Paketen ist deren maximale Größe lediglich durch das zu Grunde liegende Übertragungsmedium beschränkt (bei der Übertragung über Ethernet beispielsweise auf 1500 Byte), Mechanis­men zur Fragmentierung von größeren Datenblöcken sind jedoch standardmäßig vorgese­hen. Die Datenpakete in Sensornetzwerken dagegen sind deutlich kleiner. Das populäre Sensorknoten-Betriebssystem TinyOS [09] verwendet beispielsweise standardmä­ßig Paket­längen von 35 Byte (davon 29 Byte für Nutzdaten), eine Fragmentierung zur Übertragung größerer Datenblöcke muß auf Anwendungsebene realisiert werden, da dies vom Übertra­gungsprotokoll her nicht vorgesehen ist.

Doch nicht nur beim Paketaufbau, auch bei der Organisation des Pakettransportes gibt es Unterschiede. Ist bei IP-Netzwerken eine eindeutige Adressierung eines End­gerätes mög­lich, so haben Sensorknoten meist keine ID, anhand derer Daten­pakete eindeutig an sie adressierbar wären. Nimmt man die schon erwähnten Pakete von TinyOS als Bei­spiel he­ran, wird auch schnell klar warum darauf verzichtet wird: Bei ange­nommenen 4 Byte für die Adressierung (IPv4) würde der 6 Byte große Header fast verdop­pelt, zu lasten des klei­nen Payloads. Anstatt adressierte Pakete zu versenden werden die Pakete in WSNs daher per Broadcast versendet, was zwar einerseits zu einer ein­facheren Organi­sation führt, ande­rerseits aber eine deutlich höhere Belastung der Infra­struktur mit sich bringt, da die Pakete grundsätzlich immer per Broadcast versendet werden.

Ebenfalls unterschieden wird bei der Verbindungsart zwischen den an der Übertragung be­teiligten Komponenten. Mit Hilfe des TCP-Protokolls lassen sich in IP-Netzwerken gesi­cherte Verbindungen aufbauen, mit deren Hilfe sich für die Anwendungsschicht sichtbare Paketverluste bei der Übertragung ausschließen lassen. Da hierzu jedoch eine eindeutige Adressierung der beteiligten Geräte nötig ist, lässt sich eine derart gesicherte Übertragung in Sensornetzwerken nur auf Anwen­dungsebene realisie­ren.

Weitere Differenzen sind bei der Adressvergabe sowie dem Aufbau der Netzwerke zu fin­den. In IP-basierten Netzwerken gibt es mit DHCP (Dynamic Host Configuration Protocol, ein Dienst zur automatischen Vergabe von IP-Adressen an Endgeräte) einen Standard für die automatische Adressvergabe für die Endgeräte. In den Sensornetzwerken gibt es keinen vergleichbaren Standard. Während die Sensornetze meist aus identischen Komponenten bestehen sind IP-basierte Netze aus heterogenen Komponenten aufgebaut. Ein IP-Netzwerk besteht aus verschiedenartiger Komponenten wie z. B. Routern, Arbeitsstationen oder auch Servern verschiedener Hersteller.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.1: Zusammenfassung einiger Merkmale von WSN- und IP-basierter Kommunikation

3) Analyse der Einsatzszenarien

Das im Rahmen der Studienarbeit zu entwickelnde Gateway soll sich durch ein möglichst breites Spektrum von Anwendungsmöglichkeiten auszeichnen. Um dies sicherzustellen, wurden verschiedene Szenarien erstellt, deren Anforderungen bei der Implementierung be­achtet werden sollen und an denen das Gateway nach der Fertigstellung getestet werden soll.

3.1) Szenario 1: Standalone Einsatz mit WLAN-Zugriff

Im ersten, in Abbildung 3.1 skizzierten, Szenario fungiert das Gateway als einfache Daten­quelle, auf das von einem Note­book, einem PDA oder einer anderen Datensenke aus per WLAN zugegriffen wird. Das Szenario ermöglicht es gerade bei der Installation eines Sen­sornetzes, über den direkten Zugriff auf die Bridge direkt vor Ort die Funktionalität des Sy­stems zu prüfen.

Zu beachten ist bei diesem Szenario, dass die gesamte Konfiguration des Gateways manu­ell geschehen muß, sowohl die IP- als auch die WLAN-Konfiguration müssen vor dem in Betrieb nehmen von Hand vorgenommen werden.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 3.1: Direkter Zugriff per Laptop über WLAN

3.2) Szenario 2: Standalone Einsatz mit Zugriff per LAN

Das zweite Szenario ist dem ersten sehr ähnlich. Der Unterschied im Aufbau besteht in der Art und Weise des Zugriffs auf das Gateway, der in diesem Szenario, im Gegensatz zum drahtlosen Zugang in Szena­rio 1, über eine kabel­gebundene Netzwerkverbindung ge­schieht. Abbildung 3.2 zeigt den skizzierten Aufbau von Szenario 2.

Wie in Szenario 1 muß auch hier die IP-Konfiguration manuell vorgenommen werden.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 3.2: Direkter Zugriff per Laptop über LAN

3.3) Szenario 3: Standalone Einsatz im Netzwerk, Datensenke im gleichen Netz

Dem in Abbildung 3.3 dargestellten Einsatz des Gateways in einem Netzwerk wird später eine relativ große Bedeutung zukommen. Die Verbindung vom Gateway als Datenquelle zur Datensenke wird dabei im Gegensatz zu den ersten beiden Szenarien nicht direkt herge­stellt, sondern erfolgt indirekt über eine vorhandene Netzwerkinstallation, an die sowohl die Datenquelle- als auch Daten­senke angeschlossen werden.

Zur Konfiguration muß das Gateway in Szenario 3 lediglich seine IP-Konfiguration über einen DHCP-Server beziehen.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 3.3: Indirekter Zugriff auf das Gateway über eine vorhandene Netzwerkinstallation

3.4) Szenario 4: Standalone Einsatz im Netzwerk, Datensenke in fremdem Netz

Aufbauend auf das vorhergehende Szenario soll es mit dem neu entworfenen Gateway nicht nur möglich sein, aus dem gleichen Netzwerk heraus auf die Datenquelle zuzugrei­fen. Es soll ferner möglich sein, die Daten an einer Senke in einem zweiten Netzwerk emp­fangen zu können. Dies soll bei­spielsweise ermöglichen, vom Büro aus oder aus dem Ur­laub die private Wohnung zu überwachen oder aus der Firmenzentrale den Status verschie­dener Produktions- und Lager­stätten zentral zu überwachen.

Das Problem, welches dabei auftritt, ist, dass die Daten nun nicht nur innerhalb eines Netz­werkes weitergeleitet werden müssen, sondern dass diese auch zwischen den beiden Betei­ligten Netzen ausgetauscht werden müssen. Mit den in den ersten drei Szenarien verwende­ten UDP-Paketen ist dies jedoch nicht möglich. Stattdessen müssen die Datenpakete in TCP-Pakete umgesetzt werden, die dann auch über Netzwerkgrenzen hinweg gezielt an ei­nen bestimmten Rechner adressiert gesendet werden können. Um dies zu realisieren.

[...]