In verteilten Sensornetzwerken 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 unmittelbaren Umgebung der ausgebreiteten Sensorknoten gesammelt und mit leistungsfähigeren Systemen zu den Backend-Systemen transportiert werden.
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 genutzt werden können. Das Hauptaugenmerk soll hierbei auf den verbreiteten Technologien LAN für die kabelgebundene Weiterleitung und WLAN / Wifi für die kabellose Weiterleitung liegen.
Um die Nutzung von WLAN und LAN zu ermöglichen und um die Daten über diese Systeme zu den Backendrechnern transportieren zu können, muss das neue System nicht nur eine physikalische Umsetzung der Daten aus dem proprietären Sensorknoten-Transportprotokoll auf LAN und WLAN ermöglichen, sondern auch die Datenpakete 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 einen weiträumigeren Transport der Sensordaten ohne Kabelbindung zu ermöglichen. Das Vorgehen wird dabei sein, zuerst die in Frage kommenden Wide-Area Übertragungstechniken zu sondieren und ein geeignetes System auszuwählen. Vor der eigentlichen Implementierung des Systems werden dann die gewünschten Einsatzszenarien diskutiert, welche Voraussetzungen während der Implementierung geschaffen werden müssen, um den Betrieb im jeweiligen Szenario zu ermöglichen. Nach einer anschließenden Evaluierung der Übertragungsleistung des Systems wird das neue Gateway abschließend in einigen Anwendungsfällen auch praktisch getestet.
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 entwickelten 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 unmittelbaren Umgebung der ausgebreiteten Sensorknoten gesammelt und mit leistungsfähigeren Systemen zu den Backend-Systemen transportiert 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 weiterzuleiten 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 genutzt werden können. Das Hauptaugenmerk soll hierbei auf den verbreiteten Technologien LAN für die kabelgebundene Weiterleitung und WLAN / Wifi für die kabellose Weiterleitung liegen.
Um die Nutzung von WLAN und LAN zu ermöglichen und um die Daten über diese Systeme 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 einen weiträumigeren Transport der Sensordaten ohne Kabelbindung zu ermöglichen. Das Vorgehen wird dabei sein, zuerst die in Frage kommenden Wide-Area Übertragungstechniken zu sondieren und ein geeignetes System auszuwählen. Vor der eigentlichen Implementierung des Systems werden dann die gewünschten Einsatzszenarien diskutiert, welche Voraussetzungen während der Implementierung geschaffen werden müssen, um den Betrieb im jeweiligen Szenario zu ermöglichen. Nach einer anschließenden Evaluierung der Übertragungsleistung des Systems wird das neue Gateway abschließend in einigen Anwendungsfä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 Techniken für das gewünschte Einsatzszenario in Frage. DECT (Digital Enhanced Cordless Telecommunications) 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 Infrarot basierenden Kommunikationstechnik. Zwar gibt es hier mit IrDA einen anerkannten und verbreiteten Standard, 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 ausreichend. Die Reichweite wird lt. Spezifikation mit maximal 100cm angegeben, der Abstrahlwinkel 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 dieser 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 Rundstrahlantennen, 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 Herstellern passende WLAN-Router finden, die alle hardwareseitigen Voraussetzungen mitbringen um das gewünschte Gateway ohne Hardwareneuentwicklung entwerfen zu können. Die große Vielzahl an WLAN-Routern auf dem Markt bringt auch eine gewisse Zukunftssicherheit des neuen Gateways mit sich. Die WLAN-Technologie ist inzwischen etablierte 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 Universitä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 Abbildung 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 gerechte IP-basierte Pakete umgesetzt werden müssen. Eine weitere Betrachtung, ob hierbei 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 Protokollen zu kommunizieren, wofür die entsprechende Schnittstelle und eine Implementierung des WSN-Protokolls notwendig sind, auf der anderen Seite muss die IP-basierte Kommunikation mit den Backend-Systemen möglich sein, wofür ebenfalls sowohl die Schnittstelle als auch eine Implementierung des Protokolls benötigt werden. Dazu muss das Gateway die Pakete in beide Kommunikationsrichtungen umsetzen können.
Während die WLAN- und LAN-Schnittstellen sowie die Implementierung sowohl des Internet 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 hinzugefügt werden. Ebenso muss die Umsetzung der WSN-Pakete auf TCP- bzw. UDP-Pakete auf dem neuen Gateway implementiert werden.
Eine Gegenüberstellung typischer WSN-Protokolle mit den auf IP basierenden Technologien 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 üblicherweise aus Effizienzgründen nur kleine Paketheader vorhanden sind und diese zum Teil von mehreren Schichten des Übertragungsprotokolls gemeinsam genutzt werden, erzeugt bei IP-Paketen jede einzelne Schicht des IP-Referenzmodells [05] ihre eigenen Header, auf den nur die jeweilige Schicht Zugriff hat. Diese von den Schichten des IP-Protokolls erzeugten Header sind dabei größer als die Header der Sensorpakete. Es entsteht somit ein relativ großer Overhead an Verwaltungsdaten. Gleiches gilt für die Kontrolle der Übertragungsfehler: Während bei der IP-basierten Übertragung jede Schicht einen 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), Mechanismen zur Fragmentierung von größeren Datenblöcken sind jedoch standardmäßig vorgesehen. Die Datenpakete in Sensornetzwerken dagegen sind deutlich kleiner. Das populäre Sensorknoten-Betriebssystem TinyOS [09] verwendet beispielsweise standardmäßig Paketlä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 Übertragungsprotokoll 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 Endgerätes möglich, so haben Sensorknoten meist keine ID, anhand derer Datenpakete eindeutig an sie adressierbar wären. Nimmt man die schon erwähnten Pakete von TinyOS als Beispiel heran, wird auch schnell klar warum darauf verzichtet wird: Bei angenommenen 4 Byte für die Adressierung (IPv4) würde der 6 Byte große Header fast verdoppelt, zu lasten des kleinen Payloads. Anstatt adressierte Pakete zu versenden werden die Pakete in WSNs daher per Broadcast versendet, was zwar einerseits zu einer einfacheren Organisation führt, andererseits aber eine deutlich höhere Belastung der Infrastruktur mit sich bringt, da die Pakete grundsätzlich immer per Broadcast versendet werden.
Ebenfalls unterschieden wird bei der Verbindungsart zwischen den an der Übertragung beteiligten Komponenten. Mit Hilfe des TCP-Protokolls lassen sich in IP-Netzwerken gesicherte 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 Anwendungsebene realisieren.
Weitere Differenzen sind bei der Adressvergabe sowie dem Aufbau der Netzwerke zu finden. 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 beachtet 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 Datenquelle, auf das von einem Notebook, einem PDA oder einer anderen Datensenke aus per WLAN zugegriffen wird. Das Szenario ermöglicht es gerade bei der Installation eines Sensornetzes, über den direkten Zugriff auf die Bridge direkt vor Ort die Funktionalität des Systems zu prüfen.
Zu beachten ist bei diesem Szenario, dass die gesamte Konfiguration des Gateways manuell 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 Szenario 1, über eine kabelgebundene Netzwerkverbindung geschieht. 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 hergestellt, sondern erfolgt indirekt über eine vorhandene Netzwerkinstallation, an die sowohl die Datenquelle- als auch Datensenke 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 zuzugreifen. Es soll ferner möglich sein, die Daten an einer Senke in einem zweiten Netzwerk empfangen zu können. Dies soll beispielsweise ermöglichen, vom Büro aus oder aus dem Urlaub die private Wohnung zu überwachen oder aus der Firmenzentrale den Status verschiedener Produktions- und Lagerstätten zentral zu überwachen.
Das Problem, welches dabei auftritt, ist, dass die Daten nun nicht nur innerhalb eines Netzwerkes weitergeleitet werden müssen, sondern dass diese auch zwischen den beiden Beteiligten Netzen ausgetauscht werden müssen. Mit den in den ersten drei Szenarien verwendeten 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 einen bestimmten Rechner adressiert gesendet werden können. Um dies zu realisieren.
[...]
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen.