Technische Universität Ilmenau Fakultät für Elektrotechnik und ...

Technische Universität Ilmenau 

Fakultät für Elektrotechnik und Informationstechnik 

Diplomarbeit 

Entwurf und Implementierung einer Testumgebung zur 

Anbindung von Sensornetzwerken an IP-basierte 

Kommunikationssysteme 

vorgelegt von: André Hesse 

eingereicht am: 30. 03. 2006 

geboren am: 

Studiengang: Medientechnologie 

Studienrichtung: Audiovisuelle Technik 

Anfertigung im Fachgebiet: Kommunikationsnetze 

Fakultät für Elektrotechnik und Informationstechnik 

Verantwortlicher Professor: Prof. Dr. rer. nat. habil. Jochen Seitz 

Wissenschaftlicher Betreuer: Dipl.-Ing. Florian Evers

Danksagung 

Während der Ausarbeitung dieser Diplomarbeit konnte ich auf die Hilfe vieler Personen 

zurück greifen. 

Zu allererst gilt mein großer Dank meinem Betreuer Herrn Dipl.-Ing Florian Evers 

für die exzellente Unterstützung. Seine konstruktiven aber auch kritischen Anmerkung 

haben zum Gelingen dieser Arbeit in großem Maße beigetragen. 

Herrn Prof. Dr. rer. nat. habil. Jochen Seitz, der nicht nur diese Diplomarbeit, son- 

dern auch das Hauptseminar und mein Medienprojekt betreute, danke ich für die 

Vergabe dieses spannenden Themas. 

Frau Daniela Steffen und Herrn Björn Sörensen danke ich für die kritische Durchsicht 

meiner Diplomarbeit. Ihr habt viele Rechtschreibfehler abgefangen, die mir erst bei 

einer späteren Durchsicht aufgefallen wären. Habt vielen Dank. 

Frau Birthe Tralau hat mich nicht nur durch den besten Kaffee immer wieder moti- 

vieren können. Ich freu mich schon auf den nächsten 1. Januar. 

Meiner Freundin Yvonne möchte ich für ihr großes Verständnis während den letzten 

Wochen danken. In den Nachtschichten während der Bearbeitung dieser Arbeit hat sie 

oft auf mich verzichten müssen. Wir holen das alles nach. Bestimmt. 

Meiner Schwester Angela, ihrem Mann und der kleinen Jelena danke ich für ihre 

liebenswürdige Art. 

I also would like to thank Prof. Nigel Davies at Lancaster University, who supported 

me during my year abroad. I’m really exited doing a PhD with you guys at Infolab. I 

also trained my pool. 

Ein besondere Dank geht an meine Mutter, Frau Elke Hesse. Ohne ihre beständige 

Arbeit wäre mein schulischer Werdegang nicht möglich gewesen. Viele Ziele hätte ich 

so nicht erreichen können. Danke, dass Du immer an mich glaubst.

Kurzfassung 

Auf dem Gebiet drahtloser Sensornetzwerke wird seit einiger Zeit sehr viel Forschungs- 

arbeit geleistet. Diese Sensornetzwerke sind auf die verteilte Datenerfassung speziali- 

siert. 

Oft werden neue Übertragungstechniken eingesetzt. Im Rahmen der Hausautomati- 

sierung fallen in Sensornetzwerken nur geringe Datenmengen an, weshalb die Verwen- 

dung von etablierten, aber stark energiebedürftigen Technologien wie Bluetooth oder 

WLAN selten umgesetzt wird: Sensorknoten sollen mehrere Monate oder Jahre mit 

einer Batterie oder Akkumulator-Ladung auskommen. Das IP-Protokoll, der Quasi- 

Standard im Internet, wird von den meisten Sensornetzwerken nicht unterstützt, da 

dessen Nutzung die Rechenkapazität der eingesetzten Sensorknoten überfordert. 

Diese Arbeit beschäftigt sich mit der Kopplung eines Sensornetzwerkes an ein IP- 

Netzwerk, um die Nutzung vorhandener Computertechnik zur Steuerung des Sensor- 

netzwerkes zu ermöglichen. Dabei wurde der Einsatz eines ” transparenten Proxyser- 

vers“ gewählt. Dieser nimmt eine Protokollumsetzung zwischen beiden Technologien 

vor. Außerdem wird die direkte Adressierung eines Sensorknotens mit einer IP-Adresse 

unterstützt.

Inhaltsverzeichnis i 

Inhaltsverzeichnis 

1 Problemstellung 1 

1.1 Sensoren, überall... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 

1.2 Kopplung von Sensornetzwerken an IP-basierte Kommunikationssysteme 2 

2 IP-basierte Kommunikationssysteme 5 

2.1 Das Internet-Referenzmodell . . . . . . . . . . . . . . . . . . . . . . . . 5 

2.2 Das IP-Protokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 

2.2.1 Adressierung im Internet Protokoll . . . . . . . . . . . . . . . . 11 

2.2.2 Routing in IP-Netzwerken . . . . . . . . . . . . . . . . . . . . . 12 

2.2.3 Klassenbasierte Adressierung . . . . . . . . . . . . . . . . . . . . 16 

2.2.4 Classless Interdomain Routing (CIDR) . . . . . . . . . . . . . . 17 

2.3 Transmission Control Protocol TCP . . . . . . . . . . . . . . . . . . . . 18 

2.4 Network Address Translation NAT . . . . . . . . . . . . . . . . . . . . 21 

2.5 Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 

2.6 Transparenter Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 

3 Sensornetzwerke 29 

3.1 Historische Entwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . 29 

3.2 Einsatz von drahtlosen Sensornetzwerken . . . . . . . . . . . . . . . . . 31 

3.3 Besondere Sprachregelung bei Verwendung des Begriffes ” drahtloses Sen- 

sornetzwerk“ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 

3.4 Beispiele für drahtlose Sensornetzwerke . . . . . . . . . . . . . . . . . . 32 

3.5 ZigBee als drahtlose Übertragunstechnik in Sensornetzwerken . . . . . 33 

3.5.1 Koordination in ZigBee-Netzwerken . . . . . . . . . . . . . . . . 34 

3.5.2 Unterstützte Netztopologien . . . . . . . . . . . . . . . . . . . . 35 

3.5.3 Adressierung in ZigBee-Sensornetzwerken . . . . . . . . . . . . . 36 

3.5.3.1 IEEE-Adresse . . . . . . . . . . . . . . . . . . . . . . . 37 

3.5.3.2 NWK-Adresse . . . . . . . . . . . . . . . . . . . . . . 37 

3.5.3.3 Binding . . . . . . . . . . . . . . . . . . . . . . . . . . 38 

Diplomarbeit André Hesse

ii Inhaltsverzeichnis 

3.5.4 Profilunterstützung in ZigBee . . . . . . . . . . . . . . . . . . . 40 

4 Kopplung von Sensornetzwerken an IP-basierte Kommunikationssysteme 41 

4.1 Mögliche Ansätze zur Kopplung . . . . . . . . . . . . . . . . . . . . . . 42 

4.1.1 Implementierung der TCP/IP-Suite in Sensornetzwerke . . . . . 44 

4.1.2 Protokollumsetzer . . . . . . . . . . . . . . . . . . . . . . . . . . 46 

4.1.2.1 OSGi-Alliance . . . . . . . . . . . . . . . . . . . . . . 46 

4.1.2.2 TinyOS und TinyDB . . . . . . . . . . . . . . . . . . . 48 

4.2 Nutzung eines Transparenten Proxyservers zur Kopplung . . . . . . . . 49 

4.2.1 Umsetzung eines transparenten Proxyservers mit Linux . . . . . 52 

4.2.2 Die Adressinformationen eingehender Verbindungen manipulieren 55 

4.2.3 Die Adressinformationen ausgehender Verbindungen manipulieren 56 

5 Der Prototyp 59 

5.1 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 

5.1.1 Vorbetrachtungen zum Prototypen . . . . . . . . . . . . . . . . 60 

5.1.1.1 ZigBee-Profil-Unterstützung . . . . . . . . . . . . . . . 60 

5.1.1.2 Adressierung im Prototyp . . . . . . . . . . . . . . . . 62 

5.1.1.3 Nutzung von XML . . . . . . . . . . . . . . . . . . . . 63 

5.1.1.4 XML-Verarbeitung . . . . . . . . . . . . . . . . . . . . 65 

5.1.1.5 Authentifizierung im Prototypen . . . . . . . . . . . . 65 

5.2 Der Proxyserver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 

5.2.1 AddressBook . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 

5.2.2 AuthManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 

5.2.3 Die Manager und Connectoren . . . . . . . . . . . . . . . . . . . 72 

5.2.4 Der Weg einer Nachricht im Proxyserver . . . . . . . . . . . . . 73 

5.2.5 Aufbau von Proxyserver-Proxyserver-Verbindungen . . . . . . . 74 

5.2.6 Annahme von Client-Verbindungen im Proxyserver . . . . . . . 75 

5.2.7 Aufbau von Client-Verbindungen durch den Proxyserver . . . . 76 

5.3 Der Sensornetzwerk-Simulator . . . . . . . . . . . . . . . . . . . . . . . 77 

5.3.1 Configurator . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 

5.3.1.1 Erstellung eines neuen Netzwerkes . . . . . . . . . . . 78 

5.3.1.2 Start des Sensornetzwerkes . . . . . . . . . . . . . . . 81 

5.4 Der Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 

5.5 Kopplung über das Internet durch den Einsatz eines VPNs . . . . . . . 85 

5.6 Unterstützte Netztopologien . . . . . . . . . . . . . . . . . . . . . . . . 88 


Inhaltsverzeichnis iii 

6 Evaluierung des implementierten Prototyps 91 

6.1 Mögliche Lösungsansätze . . . . . . . . . . . . . . . . . . . . . . . . . . 91 

6.1.1 Implementierung des IP-Protokolls im Sensornetzwerk . . . . . . 92 

6.1.2 Einsatz eines Gateways als Protokollumsetzer . . . . . . . . . . 93 

6.2 Der Prototyp auf Basis eines transparenten Proxys . . . . . . . . . . . 93 

6.2.1 Vergleich mit OSGi . . . . . . . . . . . . . . . . . . . . . . . . . 95 

6.3 Probleme beim Rückruf mit einer falschen IP-Adresse . . . . . . . . . . 96 

7 Zusammenfassung 99 

8 Ausblick 101 

A Konfigurationsdateien 105 

A.1 ProxyServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 

A.2 Sensornetzwerk-Simulator . . . . . . . . . . . . . . . . . . . . . . . . . 111 

A.3 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 

B Kommunikationsprotokoll 115 

B.1 Vorbetrachtung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 

B.2 Authentifizierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 

B.3 Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 

B.4 Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 

C Darstellung der ZigBee-Attribute im Prototyp 129 

C.1 Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 

D Installation des Prototyps 133 

Literaturverzeichnis 137 

Abbildungsverzeichnis 143 

Tabellenverzeichnis 147 

Abkürzungsverzeichnis und Formelzeichen 149 

Thesen zur Diplomarbeit 151 

Erklärung 153 


iv Inhaltsverzeichnis 


1 Problemstellung 

1.1 Sensoren, überall... 

Sensoren sind aus unserem täglichen Leben nicht mehr wegzudenken. In vielen Be- 

reichen unterstützen sie den Menschen. Dabei agieren Sensoren meist im Hintergrund 

und werden als solche gar nicht vom Menschen wahrgenommen. 

Abgeleitet aus dem Lateinischen von dem Wort ” sensus“, bedeutet Sensor ” Fühler“. 

Für nahezu jede Anwendung sind Sensoren entwickelt worden. Sie können Licht, Bewe- 

gungen, Temperaturen, Geräusche detektieren oder die chemische Zusammensetzung 

von Gasen, Flüssigkeiten und Festkörpern bestimmen. Ebenso können sie Gewichte 

ermitteln, Entfernungen mit Hilfe von Radar (radio detecting and ranging) messen 

oder genetische Materialien vergleichen. 

Sensoren werden fast überall eingesetzt. Sie veranlassen automatische Türen zum 

Öffnen und schalten nach Registrierung einer Bewegung, bzw. einer zu schwachen Licht- 

situation, Leuchtmittel ein. Auch im Auto werden Sensoren eingebaut. Hier greifen sie 

ungeübten Fahrern während des Einparkens unter die Arme, indem sie die Entfernung 

zu Objekten, wie anderen Autos oder Laternenpfähle, akustisch vermitteln. 

In den letzten 20 Jahren wurden neue Einsatzgebiete für Sensoren erforscht. Man 

verbindet in so genannten Sensornetzwerken mehrere Sensoren mittels Netzwerktech- 

nologien. Die einzelnen Knoten eines solchen Netzwerkes nennt man Sensorknoten. 

Dabei muss beachtet werden, dass einige dieser Knoten nicht nur als Sensorelement 

arbeiten, sondern auch aktiv in ihre Umwelt eingreifen können. 

Ein Einsatzgebiet für Sensornetzwerke ist die Hausautomatisierung. Dabei wird im 

Haus ein drahtloses Sensornetzwerk aufgebaut. Alle elektrisch steuerbaren Elemen- 

te, wie Leuchten, Heizungen oder Alarmanlagen, sowie Steuerelemente, wie Schalter, 

Licht- und Temperatursensoren, Bewegungs- und Rauchmelder, werden in das Sensor- 

netzwerk integriert. 

Sämtliche angeschlossene Elemente des Hauses können über Computer oder Per- 

sonal Digital Assistants (PDA) ferngesteuert werden. Die Sensorknoten sollen von 

einfacher Bauweise sein, batteriebetrieben, wenig Energie verbrauchen und möglichst 

1 


2 1 Problemstellung 

kostengünstig produziert werden. 

Gerade die Anforderung, wenig Energie zu verbrauchen, schließt etablierte Funk- 

techniken wie Wireless Local Area Network (WLAN) 1 oder Bluetooth zur Datenüber- 

tragung aus. Deshalb wurde von der internationalen Standardisierungsorganisation In- 

stitute of Electrical and Electronics Engineers (IEEE) der Standard 802.15.4 entworfen 

[Inst]. Dieser definiert eine drahtlose Zugangstechnologie mit geringen Datenraten, die 

jedoch für den Einsatzzweck in Sensornetzwerken ausreichend ist. Eine Allianz von Fir- 

men baute auf diesen Standard eine Sensornetzwerklösung names ZigBee auf [ZigB]. 

Will man Computer miteinander (in einem so genannten ” Local Area Network“ 

(LAN)) oder mit dem Internet verbinden, wird meist das Internet Protocol (IP) ver- 

wendet. 

Leider unterstützt ZigBee dieses Protokoll nicht. Damit ist eine direkte Kopplung 

eines Sensornetzwerkes an vorhandene LANs nicht direkt möglich. 

1.2 Kopplung von Sensornetzwerken an IP-basierte 

Kommunikationssysteme 

Die vorliegende Diplomarbeit beschäftigt sich mit der Kopplung von drahtlosen Sensor- 

netzwerken an IP-basierte Kommunikationssysteme. Die begrenzten Energieressourcen 

der batterie- oder akkumulatorbetriebenen Sensorknoten stellen ein zentrales Problem 

für den Einsatz des IP-Protokolls dar. Weiterhin sollen Knoten drahtloser Sensornetz- 

werke besonders kostengünstig produziert werden, daher werden Bauteile eingesetzt, 

die die Rechenkapazität dieser Knoten beschränken. 

In den meisten drahtlosen Sensornetzwerken wird daher das IP-Protokoll nicht un- 

terstützt. 

Im Rahmen der Hausautomatisierung werden drahtlose Sensornetzwerke zur Steue- 

rung von Hausfunktionen installiert. In vielen Haushalten sind ein oder mehrere Com- 

puter vorhanden, die das IP-Protokoll nutzen, um eine Verbindung dem Internet her- 

zustellen. Es ist wünschenswert, diese vorhandene Computertechnik zur Kontrolle des 

drahtlosen Sensornetzwerkes zu nutzen. 

Die benötigten Grundlagen der Vermittlungs- und Transporttechniken in IP-Netzwerken 

werden in Kapitel 2 dargestellt. In Kapitel 3 werden Sensornetzwerke grundlegend be- 

schrieben. 

1 Der Begriff WLAN hat sich in der Literatur sowie in der Industrie als Synonym für die IEEE 

Standardfamilie 802.11 durchgesetzt. 


1.2 Kopplung von Sensornetzwerken an IP-basierte Kommunikationssysteme 3 

Zur Lösung der Aufgabe, die Kopplung beider Systeme zu ermöglichen, existieren 

bereits mehrere Ansätze. Diese werden in Kapitel 4 aufgezeigt, bevor ein eigener Ansatz 

vorgestellt wird. 

Dieser basiert auf der Anwendung eines ” transparenten Proxys“. In die Kommunika- 

tion zwischen einem Anwender der einen Computer eines IP-Netzwerkes benutzt und 

einem Sensornetzwerk wird ein Proxyserver eingeschliffen. Dieser vergibt für jeden Sen- 

sorknoten eine eigene IP-Adresse unter denen die Sensorknoten angesprochen werden 

können. Dabei arbeitet der Proxyserver transparent, d.h. es ist für den Anwender nicht 

ersichtlich, dass dieser nicht direkt mit den Sensorknoten kommuniziert. 

Zur Veranschaulichung dieses Ansatzes wurde ein Prototyp erstellt, der in Kapitel 

5 ausführlich beschrieben wird. Da kein reales Sensornetzwerk zur Verfügung stand, 

wurde dieses durch die Programmierung einer entsprechende Komponente simuliert. 

Abschliessend wird im sechsten Kapitel der entwickelte Prototyp mit vorhandenen 

Lösungen verglichen. 


4 1 Problemstellung 


2 IP-basierte Kommunikationssysteme 

Sollen zwei oder mehrere Computersysteme miteinander Daten austauschen, müssen 

bestimmte Absprachen getroffen werden, wie die Kommunikation erfolgen soll. Diese 

Absprachen werden als Protokoll bezeichnet. Man kann Protokolle mit menschlicher 

Kommunikation vergleichen. Wollen sich zwei Menschen unterhalten, müssen sie die 

gleiche Sprache sprechen. Ohne einen gemeinsamen Nenner können sonst leicht Miss- 

verständnisse auftreten. Diese können fatale Folgen nach sich ziehen. 

In der digitalen Welt werden Informationen mit Hilfe der zwei Symbole ” 0“ und “1“ 

ausgedrückt. Jeder Computer, Server oder Router arbeitet intern damit. Sollen zwei 

Computer unterschiedlicher Bauart miteinander Informationen austauschen, müssten 

sie vom jeweiligen Partner wissen, wie dieser intern seine Daten strukturiert, damit 

der Datenaustausch fehlerfrei stattfinden kann. Da dies bei der großen Vielfalt von 

Computern schier unmöglich ist, werden fest definierte Protokolle verwendet. 

Eines dieser Protokolle ist das Internet Protocol IP. Das weltweit verbindende Inter- 

net 1 basiert auf diesem Protokoll. Will man heutzutage online mit anderen Anwendern 

Informationen austauschen, kann man zwangsläufig die Nutzung von IP nicht vermei- 

den. Allerdings ist IP nicht das einzige Protokoll zur Adressierung in Computernetz- 

werken. Andere sind z.B. Apple Talk oder Internetwork Packet Exchange (IPX). 

2.1 Das Internet-Referenzmodell 

1983 wurde das OSI-Referenzmodell (Open Systems Interconnection) vorgestellt [DaZi83]. 

Dieses abstrakte Modell basiert auf einem Vorschlag der International Organization 

for Standardization (ISO) und ist auf nahezu jedes technische Kommunikationssys- 

tem anwendbar. Das ISO-OSI-Referenzmodell gliedert die Kommunikation in mehrere 

1 Anmerkung: der Ausdruck ” das Internet“ ist ein wenig unpräzise. Er suggeriert eine physikalische 

Einheit. Diese ist nicht gegeben. Vielmehr besteht das Internet aus einer Vielzahl von abgeschlossenen 

Netzwerken, die mit Hilfe so genannter Gateways miteinander verbunden sind (Siehe auch 

[Tane03]). Dabei können Daten, die von einem Computer des Netzes A an einen entfernten Computer 

des Netzes B gesendet werden sollen, den Weg durch mehrere andere Netzwerke nehmen. 

Den Anwendern bleibt dieses Routing im Normalfall verborgen. 

5 


6 2 IP-basierte Kommunikationssysteme 

Schichten. In Abbildung 2.1 ist das vereinfachte Referenzmodell für IP-basierte Kom- 

munikationssysteme dargestellt. 

Anwendung 

Transport 

Vermittlung 

Sicherung 

Bitübertragung 

Funk 

Vermittlung Vermittlung 

Sicherung 


Sicherung 


Ethernet 

Abbildung 2.1: Das Internet-Referenzmodell 

Anwendung 

Transport 

Vermittlung 

Sicherung 


Der Vorteil einer geschichteten Kommunikation ist die Unabhängigkeit von einzelnen 

physikalischen Zugangstechnologien. Auf unterster Ebene können verschiedene Über- 

tragungsmedien wie WLAN oder Ethernet verwendet werden. Wichtig ist, dass zwei 

direkt miteinander verbundene Systeme (hier Notebook und Router bzw. Router und 

Computer) das selbe Medium verwenden. 

Werden auf den höheren Schichten die selben Protokolle verwendet, können auch 

Computer die mit unterschiedlichen Medien an das Kommunkationsnetz angebunden 

sind, über Zwischensysteme miteinander kommunizieren [Schi03]. 

Sollen Anwendungen mit Anwendungen anderer Computer Daten austauschen, neh- 

men sie die Dienste der darunter liegenden Schichten in Anspruch. In [Schi03] und 

[Tane03] ist die Funktionalität der einzelnen Schichten ausführlich beschrieben, wes- 

halb hier nur kurz darauf eingegangen werden soll. 

Die unterste Schicht, die Bitübertragungsschicht (Physical Layer) ist für die Umset- 

zung eines Bitstroms in Signale verantwortlich. Die Art und Form der Signale wird 

durch das Medium vorgegeben. In einem Lichtleiter werden diese Signale zum Beispiel 

als Lichtimpuls übertragen. Im Coaxialkabel oder über Funk werden Signale in Form 


2.1 Das Internet-Referenzmodell 7 

elektro-magnetischer Wellen gesendet. 

Den Medienzugriff regelt die Sicherungsschicht (Data Link Layer). Wie der (deut- 

sche) Name schon vermuten lässt, sind hier auch Mechanismen zur Erkennung und 

Behebung von Übertragungsfehlern implementiert. 

In der Vermittlungsschicht (Network Layer) wird die Wegewahl von Datenpaketen 

in Kommunikationsnetzen realisiert. Der ” Quasi-Standard“ 2 ist hierbei das Internet 

Protocol IP. Im Abschnitt 2.2 wird IP ausführlich behandelt. 

Die Funktionalität, eine Ende-zu-Ende-Verbindung aufzubauen, wird durch die Trans- 

portschicht (Transport Layer) erbracht. In IP-basierten Kommunikationssystemen wer- 

den meist das Transmission Control Protocol (TCP) oder das User Datagram Protocol 

(UDP) verwendet. Beide wurden durch die Internet Engineering Task Force (IETF) 

standardisiert und sind in den Request for Comments (RFC) RFC 793 [Post81c] und 

RFC 768 [Post80] niedergeschrieben. 

Als oberste Schicht fungiert die Anwendungsschicht (Application Layer) als Binde- 

glied zwischen den Anwendungen und den Netzwerkfunktionen. Hier werden die unter- 

schiedlichsten Protokolle unterstützt. Für das Versenden und Empfangen von E-Mails 

können die Protokolle Post Office Protocol (POP-3) oder Internet Message Access Pro- 

tocol (IMAP) verwendet werden. Will man Webseiten im World Wide Web (WWW) 

abrufen, kann man dazu einen Webbrowser verwenden, der das Hypertext Transfer 

Protocol (HTTP) unterstützt. 

In Abbildung 2.2 ist die so genannte Datenkapselung dargestellt. Eine Schicht kann 

Dienste der jeweils darunter liegenden Schicht in Anspruch nehmen. Beim Senden von 

Daten werden diese von oben nach unten durchgereicht, wobei jede Schicht eigene 

Header (und Trailer) anfügt. In diesen werden Informationen für die Schichten des 

jeweiligen direkten Kommunikationspartners gespeichert. Werden Daten empfangen, 

entfernt jede Schicht die sie betreffenden Header und Trailer und reicht die restlichen 

Daten an die jeweils höhere Schicht weiter. Dieses Vorgehen wird im Referenzmodell 

als Datenkapselung bezeichnet. 

Die Gesamtheit der Protokolle der einzelnen Schichten wird mit dem Begriff Proto- 

kollstapel umschrieben. Will z.B. ein Anwender des Notebooks in Abbildung 2.1 mit 

dem Computer auf der rechten Seite Daten austauschen, müssen beide Computer den 

vollen Protokollstapel unterstützen. Sind beide nicht direkt miteinander verbunden, ist 

2 Neben IP finden auch andere Protokolle, wie das Address Resolution Protocol (ARP), Reverse Address 

Resolution Protocol (RARP), Internet Control Message Protocol (ICMP) oder das Dynamic 

Host Configuration Protocol (DHCP) in der Vermittlungsschicht Verwendung. 



bzw. 

TCP-Header 

UDP-Header 

IP-Header TCP/UDP-Header 

MAC/LLC-Header IP-Header TCP/UDP-Header 

MAC/LLC-Header IP-Header Bits TCP/UDP-Header 

Daten Anwendungsschicht 

Daten 

Daten 

Daten 

Daten 

Trailer 

Daten Trailer 

Transportschicht 

Vermittlungsschicht 

Sicherungsschicht 

Bitübertragungschicht 

Abbildung 2.2: Datenkapselung am Beispiel des Internetreferenzmodells 

es unerheblich, welche Protokolle in der Bitübertragungsschicht und der Sicherungs- 

schicht verwendet werden. Nur direkt miteinander verbundene Kommunikationspartner 

müssen hier die selben Protokolle verwenden. Manche Systeme, wie das in Abbildung 

2.1 in der Mitte abgebildete Zwischensystem, sind in der Lage, Daten zwischen ver- 

schiedenen Medien auszutauschen. Als reines Übermittlungssystem muss es nicht den 

gesamten Protokollstapel unterstützen. 

Im Internet verwenden alle Kommunikationspartner in der Vermittlungsschicht das 

IP-Protokoll. Welche Protokolle in den darunter liegenden Schichten verwendet werden, 

ist für eine Kommunikation zwischen nicht direkt miteinander verbundenen Computer 

unerheblich. So können trotz unterschiedlichen Netzzugangstechnologien wie Ethernet, 

WLAN oder Bluetooth, Daten miteinander ausgetauscht werden. 

Die Funktionalität der einzelnen Schichten bleibt dem Anwender meist verborgen. 

Ist der Computer erst einmal erfolgreich an das vorhandene Netzwerk angeschlossen, 

kann mit der Verwendung der unterschiedlichsten Anwendungen begonnen werden. Der 

Anwender kann so seine E-Mails in einem Programm seiner Wahl schreiben oder für 

das Abrufen von Webinhalten im Internet einen beliebigen Webbrowser nutzen. Wie 

die Daten dann versendet bzw. empfangen werden, ist für den Anwender unerheblich. 

2.2 Das IP-Protokoll 

Das Internet Protocol wird in der Vermittlungsschicht eingesetzt. Will man zwei oder 

mehrere Computer miteinander verbinden, wird man auf dieses Protokoll zurückgrei- 


2.2 Das IP-Protokoll 9 

fen. Nahezu jedes moderne Betriebssystem unterstützt IP. 

Das Internet, welches aus unzähligen Teilnetzen besteht, beruht auf IP. Standar- 

disiert wurde es von der IETF. Es ist in der RFC 791 [Post81b] beschrieben. Zwei 

verschiedene Versionen des IP-Protokolls werden im Internet verwendet. Die zur Zeit 

meistverbreitete Version ist Version 4. Man schreibt kurz IPv4. Seit mehreren Jahren 

wird der Übergang zu der neueren Version 6 (IPv6) vollzogen. Man kann jedoch nicht 

von einem Tag auf den Anderen die Protokolle im gesamten Internet umstellen. Die 

Investitionskosten zur Umstellung auf IPv6 sind schier unermesslich, müsste doch je- 

der Knoten IPv6 verstehen können. Laut [Dura01] [Wilj02] und [WaCh02] wird die 

Umstellung deshalb noch einige Jahre dauern. Manche Wissenschaftler glauben, dass 

der Übergang nie vollzogen werden wird [Weis01]. 

In dieser Arbeit wird der Fokus auf IPv4 gelegt. Die folgenden Angaben beziehen 

sich deshalb auf diese Version. Der Einfachheit halber wird der Zusatz ” v4“ weggelas- 

sen. Bei Ausnahmen wird explizit darauf hingewiesen. 

Anwendungsdaten werden in IP-basierten Netzwerken nicht zusammenhängend über- 

tragen. Sie werden in Dateneinheiten aufgeteilt und mittels so genannter IP-Pakete 

transportiert. Man kann die Verwendung von IP-Paketen gut mit der herkömmlichen 

Briefpost vergleichen. Will man z.B. einen dreiseitigen Text verschicken, kann aber pro 

Brief nur eine Seite versenden, kann man den Text auf drei Seiten aufteilen und jede 

einzeln in einem Brief versenden. Damit die Post die Briefe erfolgreich zustellen kann, 

müssen die Umschläge der Briefe die Absender- und Empfangsadresse enthalten. Sollte 

auf dem Übertragungsweg keiner der Briefe verloren gehen, kann der Empfänger den 

Text aus den drei Seiten wieder zusammensetzen (Abbildung 2.3). 

Das IP-Protokoll arbeitet ähnlich. Will man z.B. eine E-Mail versenden, wird das 

E-Mail-Programm den Inhalt an die Transportschicht weitergeben. In der Transport- 

schicht werden hauptsächlich die Protokolle TCP und UDP verwendet, auf die an die- 

ser Stelle allerdings nicht näher eingegangen werden soll. Es soll nur kurz festgehalten 

werden, dass TCP eine Ende-zu-Ende-Verbindung zwischen zwei kommunizierenden 

Endpunkten realisiert. 

Dabei werden die Daten, die versendet werden sollen, in Datagramme aufgeteilt. 

TCP versieht jedes Datagramm mit einem Header, in dem eine Sequenznummer ent- 

halten ist. Anschliessend werden die Datagramme an die Vermittlungsschicht weiter- 

gegeben. Diese verpackt die einzelnen Datagramme in IP-Pakete. Durch Angabe einer 

Zieladresse werden diese IP-Pakete durch das Netz zum Zielsystem versendet (Ab- 

schnitt 2.2.2). 



Absender: 

André Hesse 

Campus 

03677 Ilmenau 

Quell-IP: 10.0.0.1 

Ziel-IP: 10.0.0.12 

Empfänger: 

Herta Meier 

Tal der Ahnungslosen 

01097 Dresden 

Daten 

Absender: 

André Hesse 

Campus 


Empfänger: 

Herta Meier 


01097 Dresden 

Daten 

Quell-IP: 10.0.0.1 

Ziel-IP: 10.0.0.12 

IP-Header IP-Header 

Absender: 

André Hesse 

Campus 


Daten 

Empfänger: 

Herta Meier 


01097 Dresden 

Transportschicht 

(TCP, UDP) 

Vermittlungsschicht 

(IP) 

Abbildung 2.3: Vergleich zwischen herkömmlicher Briefpost und IP-Paketvermittlung 

Auf der Empfängerseite werden aus den empfangenen Paketen die enthaltenen Da- 

tagramme extrahiert. Anhand der durch das TCP-Protokoll vergebenen Sequenznum- 

mern kann die exakte Reihenfolge der Daten wiederhergestellt werden 3 . 

Für jedes erfolgreich übertragene Datagramm wird eine Quittung an den Sender 

ausgestellt. Diese Quittungen werden mit IP-Paketen an den ursprünglichen Sender 

geschickt. Bei Ausbleiben einer Quittung wird das entsprechende Datagramm erneut 

versendet. So sorgt TCP für eine fehlerfreie Übertragung von Daten im Internet. Die 

Transportschicht im Empfänger reicht die komplett empfangenen E-Mail-Daten an die 

entsprechende Anwendung weiter. In diesem Beispiel würde ein E-Mail-Programm dem 

Anwender anzeigen, dass eine neue Nachricht für ihn angekommen ist. 

Ein Unterschied zwischen IP-Paketen und der Briefpost besteht aber. Bei einem 

3 IP-Pakete können im Internet unterschiedliche Wege nehmen. Die Laufzeiten können stark variieren. 

Es ist auch möglich, dass einige Pakete unterwegs verloren gehen oder dupliziert werden (Siehe 

Abschnitt 2.2.2). 



normalen Brief kann man die Absenderadresse weglassen. Im Internet ist dies nicht 

zulässig. IP-Pakete ohne Absenderadresse werden von den meisten Systemen verworfen. 

2.2.1 Adressierung im Internet Protokoll 

Ein jedes IP-Paket beinhaltet neben den eigentliche Daten der nächst höheren Schicht 

(also TCP- oder UDP-Datagramme) einen IP-Header. Abbildung 2.4 zeigt den Aufbau 

für des IP-Headers der IP-Version 4. Die Bedeutung der einzelnen Felder kann [Doyl99] 

Bit 

0 

3 

7 

15 

Version IHL Diensttyp Gesamtlänge 

Identifikation Flags Fragment-Offset 

Lebenspanne Protokoll 

Header-Prüfsumme 

Quelladresse 

Zieladresse 

Optionen 

Daten 

Abbildung 2.4: Header eines IPv4-Paketes 

oder [Post81b] entnommen werden. An dieser Stelle soll nur auf die Felder ” Quell- und 

Zieladresse“ eingegangen werden. In ihnen müssen der Absender und der Empfänger 

eines jeden IP-Paketes angegeben werden. Im Headerfeld ” Gesamtgröße“ wird die Grö- 

ße von Header und eigentlichen Daten des IP-Paketes angegeben. IP-Pakete können 

maximal 65535 Byte groß sein. 

Jeder Knoten in einem IP-Netzwerk muss über eine eigene IP-Adresse verfügen. 

Diese müssen eindeutig vergeben sein. Jeder Computer oder Router der eine Schnitt- 

stelle an das Internet hat, muss eine solche IP-Adresse verwenden. Dabei bekommt 

jede Schnittstelle eine eigene Adresse. Soll ein Computer oder Router mit mehr als 

einer Schnittstelle an ein (oder mehrere) IP-Netzwerk(e) angeschlossen sein, muss er 

entsprechend viele IP-Adressen besitzen. 

In Version 4 des IP-Protokolls sind IP-Adressen 32-Bit lang. Damit sind theoretisch 

bis zu 4,3 Milliarden Adressen verfügbar. Praktisch ist aber nicht die volle Menge 

verwendbar. 

31 

IP-Header 



IP-Adressen werden als Folge von ” 0“ und ” 1“ dargestellt. Um für den Menschen ei- 

ne bessere Lesbarkeit zu gewährleisten, werden IP-Adressen in der RFC 790 [Post81a] 

durch eine dezimale Notation standardisiert. Danach wird eine IP-Adresse aus vier 

Blöcken, bestehend aus je einer Zahl zwischen ” 0“ und ” 255“ gebildet. Getrennt wer- 

den die Blöcke durch das Zeichen ” .“. In Tabelle 2.1 ist eine IP-Adresse beispielhaft 

dargestellt. 

Bitweise Darstellung: 

Dezimaldarstellung: 

WWW-Adresse: 

1000 1101 

141. 

0001 1000 

24. 

www.tu-ilmenau.de 

0000 0100 

4. 

1010 0010 

Tabelle 2.1: IP-Adressnotation für Version 4 (IPv4). Die hier gezeigte IP-Adresse verweist 

auf den Web-Auftritt der TU-Ilmenau. 

Intern arbeiten Computer und Router mit der bitweisen Schreibweise. Viele An- 

wendungen zeigen dem Anwender aber die lesbare Dezimalform an. Im Internet kann 

mittels des HTTP-Protokolls auf Webinhalte zugegriffen werden. Um nicht für jede 

Internetpräsenz die IP-Adresse einzugeben, wurde das Domain Name System (DNS) 

[Mock87] entwickelt, welches im Internet den Einsatz logischer Namen erlaubt. An- 

stelle 141.24.4.163 einzugeben, kann die Homepage der TU Ilmenau über den Aufruf 

von www.tu-ilmenau.de erfolgen. Mit DNS wird dieser logische Namen in die ent- 

sprechende IP-Adresse des Computers, der den Webdienst erbringt, umgewandelt. Die 

in Tabelle 2.1 verwendete Adresse 141.24.4.162 verweist auf den Web-Server der TU- 

Ilmenau 4 . 

Jede der in einem Netzwerk verwendeten IP-Adressen muss eindeutig vergeben sein, 

d.h. zwei Systeme dürfen nicht die selbe IP-Adresse verwenden. Die Regelung, wer wel- 

che IP-Adresse verwendet, wird durch die Internet Corporation for Assigned Names 

and Numbers (ICANN) geregelt. Dabei vergibt die ICANN nicht jede Adresse ein- 

zeln, vielmehr werden bestimmte Adressbereiche an verschiedene regionale Behörden 

vergeben. Diese regulieren dann die Vergabe an Internet Service Provider (ISP) und 

Unternehmen [Tane03]. 

2.2.2 Routing in IP-Netzwerken 

In Bezug auf das ISO-OSI Referenzmodell (Siehe Abschnitt 2.1) wird im Internet (als 

Protokoll der Vermittlungsschicht) das IP-Protokoll verwendet (Abschnitt 2.2). Da- 

bei werden Daten, die durch das Netzwerk übertragen werden sollen, in IP-Pakete 

4 Stand: 17. Februar 2006 

Diplomarbeit André Hesse 

162


verpackt. Sind die Daten zu groß für ein IP-Paket, werden sie auf entsprechend viele 

Pakete aufgeteilt. Jedem Paket wird ein so genannter IP-Header vorangestellt (Ab- 

bildung 2.4). In diesem werden unter anderem die Quell- und Zieladresse angegeben. 

Pakete, denen eine der beiden Informationen fehlen, werden als nicht standardgemäß 

von den meisten Systemen verworfen. 

Jeder Computer, Server oder Router in einem Netzwerk pflegt mindestens eine so 

genannte Routingtabelle. In ihr wird verzeichnet, wie IP-Pakete mit einer bestimmten 

Zieladresse weitergeleitet werden sollen. 

In einem abgeschlossenen Netzwerk, wie das auf der linken Seite der Abbildung 2.5 

dargestellte, kennt jeder Knoten seine Nachbarknoten. Die Routingtabellen der Kno- 

141.24.92.196 

141.24.92.197 

141.24.92.198 

TKM-Pool 

FG Komm.netze 

141.24.95.254 

Internet 

148.88.1.1 

148.88.1.27 

Abbildung 2.5: Routing im Internet 

1 

2 

3 

4 

5 

17.254.3.183 

www.apple.com 

www.lancs.ac.uk 

148.88.1.11 

ten 141.24.92.196, 141.24.92.196 und 141.24.92.196 des Netzwerkes ” TKM-Pool“ 

enthalten zunächst die jeweiligen Adressen der anderen Knoten dieses Netzes sowie die 

des Knotens 141.24.95.254. Ausserdem ist verzeichnet, wie die jeweiligen Knoten zu 

erreichen sind. Dabei wird festgelegt, an welchen Computer ein Paket geschickt werden 

soll, welches über eine bestimmte Ziel-IP-Adresse verfügt. 

Soll ein Paket z.B. vom Computer mit der IP-Adresse 141.24.92.196 an das Note- 

book mit der Adresse 141.24.92.198 verschickt werden, kann dies direkt geschehen. 



Der Computer 141.24.92.196 wird sein Paket über die Leitung versenden. Alle Kno- 

ten in diesem Netz empfangen dieses Paket. Sie überprüfen die IP-Header-Angaben. 

Kann eine Übereinstimmung der Adressangaben gefunden werden, wird der Inhalt die- 

ses Paketes an die nächst höhere Schicht weitergegeben. Dort wird entschieden, was 

mit dem Inhalt geschehen soll. 

Nun soll der Computer 141.24.92.168 aus dem ” TKM-Pool“-Netz an den Computer 

148.88.1.27 im Netz der Universität Lancaster (Abbildung 2.5, rechts unten) Daten 

senden. Da beide nicht im selben Netzwerk arbeiten, müssen die IP-Pakete durch 

ein oder mehrere Zwischensysteme geleitet werden. Diese Systeme werden meist als 

Router 5 bezeichnet. Jede Vermittlung eines Paketes über einen Router wird als ” Hop“ 

bezeichnet. 

Der Computer in diesem Beispiel überprüft in seiner Routingtabelle, ob er einen pas- 

senden Routingeintrag zum Erreichen des Ziels 148.88.1.27 finden kann. Dazu wird 

vermerkt, an wen der Computer Pakete mit einer Zieladresse 148.88.1.27 schicken 

soll. In diesem Fall wird als erstes der Router mit der Adresse 141.24.95.254 vermerkt 

sein. Bei diesem speziellen Router handelt es sich um ein Gateway. Gateways sind Netz- 

knoten, die mit mehr als einem Netzwerk verbunden sind. Sie besitzen deshalb mehr 

als eine IP-Adresse. Diese ermöglichen ihnen, IP-Pakete zwischen den einzelnen Netzen 

zu transportieren. Werden in den Netzwerken unterschiedliche Vermittlungsprotokolle 

eingesetzt, können die Gateways Daten zwischen diesen Protokollen transformieren. 

Das Gateway ermittelt aus den empfangenen Paketen die Quell- und Zieladresse. Es 

führt selbst eine Routingtabelle, aus der es einen Routingeintrag für die Zieladresse 

heraussuchen kann. Die IP-Pakete werden an den nächsten Router im Internet wei- 

tergeleitet. Im Beispiel ist dies der Router Nr. 1. So werden die Pakete immer weiter 

durch das Netz geleitet, bis sie zum Gateway der Domaine ” lancs.ac.uk“ angelangen. 

Auch dieses vergleicht die empfangenen Pakete mit seiner Routingtabelle und leitet 

die Pakete direkt an den Zielcomputer weiter. 

Ein Problem wird schnell ersichtlich: Bei der großen Anzahl von Netzknoten, die 

direkt an das Internet angeschlossen sind, kann nicht jeder Knoten alle anderen in seiner 

Routingtabelle aufführen. Die Tabellen würden so große Ausmaße annehmen, dass das 

Nachschlagen für eine bestimmte Route viel zu viel Rechenkapazität brauchen würde. 

Ausserdem wären die Endknoten ständig damit beschäftigt, ihre Routingtabellen zu 

aktualisieren. Sobald ein Knoten aus dem Netz entfernt würde, müssten alle anderen 

die Route zu diesem Knoten löschen. 

5 Auch normale Personal Computer (PC) können als Zwischensystem verwendet werden, sie erbringen 

in diesem Fall Routingdienste. 



Anstatt komplette Adressen in die Routingtabellen aufzunehmen, werden nur Regeln 

für bestimmte Adressteile vermerkt. Im Beispiel wird das Gateway des ” TKM-Pool“- 

Netzes alle Pakete, deren IP-Adresse nicht mit 141.24.92 beginnen, an den Router 1 

im Internet leiten. Dieser wiederum hat entsprechende Routingeinträge, die besagen, 

dass er Pakete, die mit 148 beginnen über Router 2, 3 und 4 weiterleiten kann. Die 

nachfolgenden Router können die Adresse immer genauer auflösen. Im Beispiel verfügt 

Router 2 über entsprechende Routingeinträge, in denen festgelegt ist, dass dieser Rou- 

ter Pakete deren Adresse mit 148.88 beginnen über Router 3 zustellen kann. Dieser 

stellt alle Pakete deren IP-Adressen 148.8.1 enthalten, an den Computer 148.88.1.1 

zu. Letztendlich kann dieser die volle Adresse auflösen. 

Somit müssen die Router nur über bestimmte Teile der Adresse bescheid wissen. 

Nicht jeder Router kennt also jeden Computer im Internet. Untereinander tauschen 

Router über eigene Protokolle Routinginformationen aus. 

Im häufigsten Fall sollen Knoten aber Pakete weiterleiten, deren Route sie selbst 

nicht bestimmen können. Als Ausweg bietet sich der Eintrag eines Standardgateways in 

der Routingtabelle des entsprechenden Knotens an. Jedes Paket, für dessen Zieladresse 

kein passender Routingeintrag gefunden wird, wird an dieses Standardgateway geleitet. 

Kann dort ebenfalls kein passender Eintrag gefunden werden, wird es das Paket nun 

seinerseits seinem Standardgateway zusenden. Dieses hat entweder selber eine Route 

zum Ziel oder leitet die Pakete an sein Standardgateway weiter. Handelt es sich bei 

der Ziel-IP-Addresse um eine tatsächlich im Internet vorhandene Adresse, können die 

Pakete aber in der Regel korrekt ausgeliefert werden. 

IP-Pakete einer Kommunikation müssen im Internet nicht die selben Wege nehmen. 

Die dezentrale Struktur des Internets erlaubt eine vielfältige Wegewahl. Somit kann ein 

Teil der Pakete um die halbe Welt laufen, während andere den kürzesten Weg nehmen. 

Die Frage, welcher der kürzeste Weg ist, ist ein sehr anspruchsvolles Problem. Aufgrund 

der immens hohen Anzahl an Knoten und Netzwerken im Internet ist nicht immer klar, 

welches der kürzeste Weg ist. Auch haben politische und finanzielle Faktoren einen 

großen Einfluss auf die Wegewahl. 

Mehrere verschiedene Algorithmen und Protokolle wurden entwickelt und finden 

ihre Anwendungen. Eine gute Beschreibung zu den gängigen Protokollen lässt sich in 

[Tane03] und in [Doyl99] finden. 



2.2.3 Klassenbasierte Adressierung 

Anfänglich verwendete man eine klassenbasierte IP-Adressierung, die das Internet in 

so genannte Klassen einteilte. Abbildung 2.6 stellt dies dar. 

Klasse 

A 

B 

C 

D 

E 

0 1 2 4 8 16 24 31 

0 Netz-ID Knoten-ID Knoten-ID 

max. 126 Subnetze mit max. je 16777214 Knoten 

1 0 Netz-ID Knoten-ID Knoten-ID 

max. 16384 Subnetze mit max. je 65534 Knoten 

1 1 0 

Netz-ID Knoten-ID 

max. 2097152 Subnetze mit je 254 Knoten 

1 1 1 0 

1 1 1 1 0 

Multicast-Adresse Multicast-Adresse 

Reserviert Reserviert für für zukünftige Anwendungen 

Abbildung 2.6: Klassenbasierte IP-Adressierung 

Knoten-Adressbereich 

1.0.0.0 - 

127.255.255.255 

128.0.0.0 - 

191.255.255.255 

192.0.0.0 - 

223.255.255.255 

224.0.0.0 - 

239.255.255.255 

240.0.0.0 - 

255.255.255.255 

Die IP-Adressen werden in Klassen eingeteilt. Dabei bezieht sich die Angabe einer 

Klasse auf die Anzahl der Bits der IP-Adresse die einem bestimmten Netzwerk zuge- 

ordnet werden. Man unterscheidet die IP-Adresse in Netzwerk-ID und Knoten-ID. Alle 

Adressen, deren erstes Bit ” 0“ ist, haben eine 8 Bit lange Netzwerk-ID, die Knoten-ID 

ist dann 24 Bit lang. Diese IP-Adressen stellen ein Klasse-A-Netzwerk dar. 

Die ersten beiden Bits von Klasse-B-Adressen sind mit ” 10“ belegt. Solche Adressen 

enthalten eine 16 Bit lange Netzwerk-ID. Dies lässt für die Knoten-ID nur noch 16 Bit 

zu. Entsprechend fangen IP-Adressen der Klasse C mit ” 110“ an. Hier bilden 24 Bit 

die Netz-ID und nur 8 Bit verbleiben für die Knoten-ID. Damit sind 2097152 Subnetze 

mit je 254 Knoten adressierbar. 

Die Adressbereiche in den Klassen A, B und C unterstützen ein wenig mehr als die 

in Abbildung 2.6 angezeigten Anzahlen an Subnetzen und Knoten. Einige Adressen 

wie die 0.0.0.0, 255.255.255.255 sowie der Adressbereich 127.x.x.x fallen jedoch 

weg, da sie anderweitig verwendet werden [Tane03]. 

Nach der klassenbasierten Adressierung muss jedes Subnetz, das an das Internet 

angeschlossen ist, eine eigene eindeutige Netz-ID besitzen. Je nach Klasse werden in 



einem solchen Subnetz nur eine bestimmte Anzahl an Knoten, sprich IP-Adressen, 

unterstützt. Will nun jemand ein eigenes Netzwerk an das Internet anbinden, braucht 

er für jeden Computer dieses Netzwerkes eine IP-Adresse. Werden mehr als 254 IP- 

Adressen benötigt, muss eine Netzwerk-ID aus dem Adressbereich der Klassen A oder 

B zugewiesen werden. Die in diesem Subnetz enthaltenen IP-Adressen sind in anderen 

Netzwerken nicht mehr verwendbar. Werden in einem Klasse-B Netzwerk nur 1000 IP- 

Adressen verwendet, verbleiben die restlichen möglichen 64534 IP-Adressen ungenutzt. 

Router im Internet haben in ihren Routing-Tabellen nicht Regeln für jeden einzelnen 

Knoten vermerkt, sondern nur für bestimmte Netzwerk-ID’s. Je nachdem, wie diese 

gestaltet ist, wird das Routing durchgeführt (2.2.2). 

Betrachtet man die rasante Entwicklung des Internets in den letzten 10 Jahren, 

erkennt man leicht das Dilemma, welches mit der Verwendung von IPv4 einhergeht: 

Dem Internet gehen die Adressen aus. 

Ein Ausweg aus diesem Problem ist die Einführung von IPv6. 1990 wurde durch die 

IETF die Arbeit an der neuen Version begonnen. Jedoch dauert die Standardisierung 

eines neuen Protokolls zunächst mehrere Jahre, bevor im großen Maße die Umstellung 

eines Systems auf einen neuen Standard begonnen werden kann. Die Umstellung auf 

IPv6 selber dauert schon mehrere Jahre an. Sie ist mit immensen Investitionen verbun- 

den. Einige Wissenschaftler gehen sogar davon aus, das die Umstellung nie vollständig 

vollzogen wird [Weis01]. 

Aus diesem Grund wurden andere Wege zur Lösung des Adressproblems gesucht. 

Ein Ansatz ist das so genannte Classless Interdomain Routing (CIDR), welches in der 

RFC 1519 [FLYV93] definiert ist. Ein anderer Ansatz ist Network Address Translation 

(NAT). 

2.2.4 Classless Interdomain Routing (CIDR) 

Die Verwendung der klassenbasierten Adressierung in IP-Netzwerken ist mit dem ra- 

santen Wachstum des Internets unbrauchbar geworden. Der hohen Anzahl an Netz- 

werken im Internet wird die klassenbassierte Adressierung nicht mehr gerecht. In RFC 

1519 [FLYV93] wurde deshalb ein neuer Ansatz gewählt. 

Die IP-Adressen werden nicht mehr in Klassen unterteilt. Zusätzlich zur IP-Adresse 

wird eine so genannte Subnetzmaske eingeführt. Sie ist ebenfalls 32 Bit lang und ist 

wie eine IP-Adresse formatiert. Sie adressiert aber keine Knoten, sondern gibt an, wie 

viele Bits der IP-Adresse als Netz-ID dienen sollen. Die Grenzen zwischen Netz-ID und 

Knoten-ID der klassenbasierten Adressierung sind somit nicht mehr fest zugeordnet. 



Die Länge der Netz-ID kann somit durch die Subnetzmaske ermittelt werden. 

Sind alle Bits der Subnetzmaske auf 1 gesetzt, dies entspricht ” 255.255.255.255“ 

ist genau die zugehörige IP-Adresse eindeutig gemeint. Entsprechen die ersten 16 Bit 

der Subnetzmaske ” 1“ (255.255.0.0), werden die ersten 16 Bit der IP-Adresse als 

Netz-ID interpretiert. 

Die Router im Internet haben Regeln für Pakete die mit bestimmten Subnetzmasken 

übereinstimmen. Entsprechend diesen Regeln wird die Routingentscheidung für Pakete 

getroffen. Die Router leiten dann die Pakete an die entsprechenden Stellen weiter. 

2.3 Transmission Control Protocol TCP 

In der Literatur findet man häufig den Begriff TCP/IP-Suite, wenn die Protokol- 

le im Internet kurz beschrieben werden sollen. Bezieht man sich auf das ISO-OSI- 

Refernzmodell, werden zahlreiche Protokolle in der Transport- und der Vermittlungs- 

schicht angewendet. Am häufigsten werden dabei IP in der Vermittlungsschicht und 

TCP in der Transportschicht eingesetzt, so dass sich der Begriff TCP/IP-Suite einge- 

bürgert hat. 

Im Gegensatz zu IP ist TCP ein verbindungsorientiertes Protokoll, das auf der Nut- 

zung von IP aufbaut. Im IP-Protokoll werden IP-Pakete durch ein Netzwerk oder das 

Internet geroutet. Dabei können Pakete, die die selbe Zielbestimmung haben, unter- 

schiedliche Wege nehmen. Diese variieren je nach Auslastung, politischen, finanziellen 

oder baulichen Gegebenheiten, oder der aktuellen Tageszeit. IP-Pakete können un- 

terwegs verloren gehen oder dupliziert werden. Werden mehrere Pakete nacheinander 

abgeschickt, kann es passieren, dass sie zu unterschiedlichen Zeiten beim Empfänger 

eintreffen. Der Absender erhält keinerlei Informationen, ob die von ihm abgesendeten 

IP-Pakete auch wirklich beim Empfänger angekommen sind. 

TCP nutzt die Transportdienste von IP, um zwischen zwei Netzknoten eine virtuelle 

Ende-zu-Ende-Verbindung aufzubauen. Wie dabei die zum Transport von TCP-Daten 

genutzten IP-Pakete durch das Netz geroutet werden, ist für den Anwender irrelevant. 

Wie in Abbildung 2.2 dargestellt, werden zu versendende Daten von Anwendungen an 

die Transportschicht und in diesem Fall an das TCP-Protokoll übergeben. Diese teilt 

die zu versendenden Daten in so genannte Datagramme auf. Zusätzlich wird jedem 

TCP-Paket ein Header vorangestellt, der in Abbildung 2.7 dargestellt ist. Insgesamt 

darf die Größe des TCP-Headers und des TCP-Datagrammes nicht mehr als 65515 

Byte betragen. Ansonsten würde die maximale IP-Paketgröße überschritten werden. 

Jedoch hat sich als Größe der TCP-Datagramme ein Wert von unter 1500 Bytes 


2.3 Transmission Control Protocol TCP 19 

Bit 

0 16 

31 

TCP- 4 bit TCP 

Head.- header 

länge length 

Source Quellport Port 

Destination ZielportPort 

6 bit 

unused 

Sequence Sequenznummer Number 

Piggyback Bestätigungsnummer 

Acknowledgement 

U A E 

R S 

F R 

CK 

O 

ST 

Y 

I 

G 

M 

N 

N 

Fenstergröße Window 

Prüfsumme Checksum 

Zeiger Urgent auf Vorrangdaten 

Pointer 

Optionen Options (0 (0 oder mehr 32-bit-Worte) 

Daten 

... 

Abbildung 2.7: Der TCP-Header 

eingebürgert. Lange Zeit wurde als Medium ” Ethernet“ verwendet. In der Sicherungs- 

schicht werden Daten in so genannten Rahmen übertragen, die bei Ethernet meist 

eine Größe von 1500 Byte haben. In Bezug auf die Datenkapselung (siehe Abschnitt 

2.1) passen viele Computersysteme daher die Größe der IP-Pakete an diese Rahmen- 

größe an. IP stellt den zu transportierenden Daten (TCP-Datagramme) selber einen 

Header voran, der eine bestimmte Größe hat. Die Header von IP und TCP sowie die 

eigentlichen Daten sollen somit zusammen nicht größer als 1500 Byte sein. 

TCP (und auch UDP) erweitern die Adressierung des IP-Protokolls durch eine ” Port- 

nummer“. Dabei handelt es sich um eine 16 Bit lange Zahl. Wie die IP-Adresse es er- 

möglicht IP-Pakete einen bestimmten Knoten zuzuordnen, kann TCP (UDP) mit der 

Portnummer eine bestimmte Anwendung in diesem Knoten adressieren. 

Will ein Anwender zum Beispiel den Webauftritt der Firma ” Apple“ abrufen, wird 

er in seinen Browser die Adresse www.apple.de eingeben. Mittels des DNS wird der 

logische Namen www.apple.de in eine IP-Adresse umwandeln. In diesem Fall wird 

DNS die IP-Adresse 17.254.3.122 zurückgeben 6 . Der Webbrowser versucht nun, eine 

TCP-Verbindung zu diesem Server aufzubauen. Dabei wird als Zielport im Normalfall 

der Port 80 eingetragen. Kommt die Verbindung zustande, wird der Webserver der 

Firma Apple eine HTML-Seite an den Browser übermitteln. Dieser stellt den Inhalt in 

seiner Oberfläche dar. Der Anwender kann den Webauftritt betrachten. 

Im TCP-Header werden Angaben über den Quell- und den Zielport aufgezeichnet. 

6 Stand 20.02.2005. 

TCP-Header 



Viele Protokolle der Anwendungsschicht wie HTTP oder POP-3 werden über einen 

Standardport angesprochen. Webserver halten ihre Inhalte am Port 80 bereit. E-Mails 

können mittels POP-3 am Port 110 abgerufen werden. Die ” Internet Assigned Numbers 

Authority“ (IANA) führt eine Liste mit so genannten ” Well Known Ports (Bekannte 

Portnummern)“. In dieser sind für die meisten Anwendungsprotokolle die verwendeten 

Portnummern verzeichnet. Unter [IANA] kann diese Liste eingesehen werden. Dabei 

werden nur die Ports ” 0-1023“ als ” Well Known Ports“ deklariert. Die restlichen können 

frei vergeben werden. 

Eigentlich waren die ” Well Known Ports“ in einer RFC durch die IETF reglementiert 

(RFC 1700), man ist aber inzwischen dazu übergegangen, die Liste durch die IANA in 

einer Onlinedatenbank zu führen. Die Vergabe der Ports ist nicht durch einen Standard 

reglementiert. Die Vorgabe der ” Well Known Ports“ ist nur eine Empfehlung. Damit 

ist es möglich, z.B. einen Webserver, der normalerweise auf Port 80 Anfragen bedient, 

auch auf einem anderen Port laufen zu lassen. 

Im Allgemeinen halten sich die Diensteanbieter im Internet aber an die Vorgaben 

der IANA. 

TCP nummeriert alle versendeten Datagramme eines Datenstromes. Im Headerfeld 

” Sequenznummer“ wird die aktuelle Nummer eines Datagramms angegeben. Kommen 

beim Empfänger die IP-Pakete zu verschiedenen Zeitpunkten an, kann dessen TCP- 

Software die Ordnung anhand der Sequenznummern der TCP-Datagramme wieder- 

herstellen. Dann können die Daten in der richtigen Reihenfolge an die entsprechende 

Anwendung gegeben werden. Dazu muss auf dem TCP-Zielport eine Anwendung Daten 

entgegennehmen. Diese Anwendung muss mit den empfangenen Daten etwas anfangen 

können, d.h. das Anwendungsprotokoll des Senders verstehen. Für Standarddienste wie 

HTTP oder E-Mail wird daher oft ein “Well Known Port“ verwendet. 

Zusätzlich enthält jeder TCP-Header eine Prüfsumme. Diese wird vom Sender unter 

anderem aus Angaben des TCP-Headers, des Datagrammes sowie den Angaben der 

IP-Quell- und Zieladresse gewonnen. Der Empfänger bildet seinerseits ebenfalls diese 

Prüfsumme und vergleicht diese mit der im TCP-Header enthaltenen. Stimmen beide 

überein, kann von einer erfolgreichen Übertragung ausgegangen werden. 

Eine Besonderheit von TCP ist die Quittierung der Datagramme. Für jedes er- 

folgreich empfangene TCP-Datagramm wird eine Bestätigung an den Sender zurück 

geschickt. Empfängt der Sender eines TCP-Datagramms nicht innerhalb einer gewis- 

sen Frist die Bestätigung, geht er davon aus, dass das entsprechende Datagramm nicht 


2.4 Network Address Translation NAT 21 

beim Empfänger angekommen ist. Das Datagramm kann dann erneut gesendet werden. 

Somit ist eine erfolgreiche Datenübertragung gesichert. Der Anwender kann davon aus- 

gehen, dass seine Daten auch sicher (d.h. unverändert) auf der Gegenseite ankommen. 

2.4 Network Address Translation NAT 

Das rasante Wachstum des Internet war bei der Entwicklung des Internet Protokolls 

IP nicht vorauszusehen. Zwar sind in IPv4 bei der Verwendung 32 Bit langer Adressen 

theoretisch 4,2 Milliarden adressierbare Knoten denkbar, praktisch können diese aber 

nicht alle adressiert werden. Viele Adressen fallen trotz des Einsatzes von CIDR weg. 

Der Umstieg auf IPv6 mit seinen 128 Bit langen Adressen wird vollzogen, ist aber noch 

lange nicht abgeschlossen. 

In vielen Unternehmen und privaten Netzwerken muss nicht jeder Computer per- 

manent an das Internet angeschlossen sein. Oft werden nur zeitweise Informationen 

aus dem Internet benötigt. Die meisten Netzwerke werden gebildet, um innerhalb ei- 

ner Firma oder eines Privathaushaltes Ressourcen wie Drucker oder Fileserver durch 

mehrere Anwender zu nutzen. Ausserdem möchte man mit anderen Anwendern eines 

Netzwerkes Daten austauschen. Nutzt man das IP-Protokoll innerhalb seines Netzwer- 

kes, stehen einem sämtliche Adressen zur freien Verfügung. Das heißt man kann alle 

Adressen beliebig (eindeutig) vergeben, solange kein Computer dieses Netzes an das 

öffentliche Internet angeschlossen ist. Geschieht dies, kann es zu Adresskonflikten kom- 

men. Wird eine IP-Adresse mehrmals vergeben, kann ein erfolgreiches Routing nicht 

mehr gewährleistet werden. 

Aus diesem Grund hat die IETF bestimmte Adressbereiche zur Verwendung in priva- 

ten Computernetzen 7 reserviert (Siehe RFC 1597 [RMKG94]). Die reservierten Adress- 

bereiche sind in Tabelle 2.2 angegeben. 

Adressbereich 

10.0.0.0 - 10.255.255.255 

172.16.0.0 - 172.31.255.255 

192.168.0.0 - 192.168.255.255 

Kurznotation maximale Hostanzahl 

10.0.0.0/8 

172.16.0.0/12 

192.168.0.0/16 

16777216 

1048576 

65536 

Tabelle 2.2: Reservierte Adressbereiche im IPv4 Protokoll 

Aus diesen Adressbereichen sollte mit bis zu 16 Millionen Adressen ein hinreichend 

großer Spielraum für private Netzwerke gegeben sein. Im Internet dürfen diese Adressen 

7 Die Klassifizierung ” privat“ bezeichnet hier ein ” Nicht-öffentliches“ Netzwerk. Vom Internet abgeschlossene 

Unternehmensnetzwerke sind demnach auch als ” privat“ einzustufen. 



auf keinen Fall verwendet werden. 

Um nun auch Knoten eines privaten Netzwerkes einen Internetzugang zu bieten, kann 

ein Routert eingesetz werden. Wie in Abschnitt 2.2.2 beschrieben, könnte dieser Pakete, 

die aus dem privaten Netzwerk kommen, an das Internet weiterleiten. Allerdings ergibt 

sich hierbei ein Problem: Die Pakete der Knoten des privaten Netzwerkes hätten als 

Absenderadressen Adressen aus dem reservierten Adressbereich eingeschrieben. Diese 

dürfen jedoch nicht im Internet verwendet werden. Ihre Vergabe erfolgt auch nicht 

durch eine Organisation wie der ICANN, so dass durchaus mehrere Knoten mit der 

gleichen Adresse auftreten könnten. Damit kann eine richtige Zustellung möglicher 

Antwortpakete nicht gewährleistet werden. Als Empfänger würden ja mehrere Knoten 

in Frage kommen. 

Die IETF hat zur Umgehung dieser Problematik in der RFC 1631 [EgFr94] das 

Network Address Translation (NAT) eingeführt. NAT erlaubt die Manipulation der 

Absender- und Ziel-IP-Adressen eines IP-Paketes nach bestimmten Regeln. Will man 

ein privates Netzwerk an das Internet anschliessen, kann man einen NAT-Router als 

Gateway zwischen Internet und Netzwerk einfügen. In Abbildung 2.8 ist ein solches 

Szenario dargestellt. 

Der Computer mit der IP-Adresse 192.168.0.5 aus dem privaten Netz will eine 

Anfrage an den Computer 141.24.92.97 senden. Als Gateway ist in diesem Privatnetz 

der NAT-Router in der Mitte eingetragen. Dieser hat 2 Netzwerkschnittstellen. Im 

privaten Netz ist er durch die IP-Adresse 192.168.0.1 zu erreichen. Über das Netzwerk 

eines Internet Service Providers (ISP) ist der NAT-Router aus dem Internet mit der 

Adresse 84.184.245.99 ansprechbar. 

Soll er Pakete aus dem internen Netzwerk an das Internet leiten, tauscht der NAT- 

Router die Quelladresse aus. Anstatt der originalen Quelladresse (192.168.0.5) trägt 

er seine extern vom ISP vergebene IP-Adresse (84.184.245.99) ein. In einer so ge- 

nannten NAT-Tabelle vermerkt er dabei die original Quell- und Zieladresse der ur- 

sprünglichen Pakete. Für die Router im Internet und den Empfänger ist nun der NAT- 

Router der Sender der betreffenden IP-Pakete. Deshalb werden die Antworten an den 

NAT-Router adressiert. 

Empfängt der NAT-Router Pakete aus dem Internet, die an ihn adressiert sind 

(84.184.245.99), überprüft er seine Tabelle. Hat er zuvor eine zur Antwort gehörende 

Anfrage registriert, kann er die Antwort dem Computer aus dem privaten Netzwerk 

zuordnen und an diesen weiterleiten. Dazu verändert der NAT-Router nun die Ziel- 

adressen der Antwortpakete. Er trägt die Adresse des Computers (192.168.0.5) ein, 

der die ursprüngliche Anfragen gestellt hatte. 


2.4 Network Address Translation NAT 23 

Anfrage 

192.168.0.5 

192.168.0.7 

Antwort 

192.168.0.5 

192.168.0.7 

privates Netzwerk ISP-Netzwerk / Internet 

vor Übersetzung 

Quelle: 192.168.0.5 

Ziel: 141.24.92.197 

Daten 

nach Übersetzung 

Quelle: 141.24.92.197 

Ziel: 192.168.0.5 

Daten 

nach Übersetzung 

Quelle: 84.184.245.99 

Ziel: 141.24.92.197 

Daten 

192.168.0.1 84.184.245.99 84.184.0.1 

NAT-Router 

vor Übersetzung 

Quelle: 141.24.92.197 

Ziel: 84.184.245.99 

Daten 

192.168.0.1 84.184.245.99 84.184.0.1 

NAT-Router 

Abbildung 2.8: Network Address Translation im Einsatz 

Allerdings ergibt sich ein Problem, würde der NAT-Router nur die IP-Informationen 

auswerten und verändern. Wenn zwei Computer aus dem privaten Netzwerk gleichzeitig 

Anfragen an die selbe Adresse im Internet senden, würde NAT so wie es geschildert 

wurde, nicht funktionieren. 

Der NAT-Router müsste zwei Einträge in seiner Tabelle anlegen, deren einziger 

Unterschied die Quell-IP-Adressen der sendenden Computer ist. Kommt nun entspre- 

chende Antworten zurück, muss der NAT-Router entscheiden, an welche der beiden 

Originaladressen er die Antwort leiten soll (also in welche Adresse er die Zieladresse 

der Antwort umschreiben soll). Allein mit Hilfe des IP-Protokolls kann er dies nicht 

eindeutig entscheiden. Wäre im IP-Header ein zusätzliches Feld für die original Quell- 



oder Zieladresse vorhanden, könnte ein NAT-Router dieses auslesen und seine Rou- 

tingentscheidung danach treffen. Aber ein solches Feld existiert nicht. Man kann auch 

nicht einfach zusätzliche Headerdaten anfügen. Zwar ist Platz im IP-Header dafür vor- 

handen, diesen kann man aber nicht für diesen Zweck nutzen. Denn dafür müsste jedes 

Endsystem im Internet den Einsatz von NAT erkennen, was nur mit der Änderung der 

IP-Protokollimplementierung auf allen Systemen im Internet möglich wäre. Dies ist, 

wie die Umstellung auf IPv6, mit immensen Kosten verbunden 8 . 

Man bedient sich bei NAT daher eines Tricks. Für die Veränderung der IP-Quell- und 

Zieladresse werden Angaben aus der darüber liegenden Schicht genutzt. Die meisten 

Protokolle der Anwendungsschicht nutzen die Protokolle TCP oder UDP der Trans- 

portschicht [Tane03]. 

In Abschnitt 2.3 wurde die Verwendung von Ports im TCP-Protokoll besprochen. 

Ein NAT-Router verändert bei einem ausgehenden Paket nicht nur die Quelladresse im 

IP-Header sondern auch den Quellport des TCP- oder UDP-Headers. Der veränderte 

Quellport wird dabei mittels einer Indexfunktion aus der originalen Quelladresse und 

dem originalen Quellport gebildet. Zusätzlich müssen die Prüfsummen in den Headern 

(IP und TCP oder UDP) neu berechnet werden. Werden Antwortpakete empfangen, 

können aus den Angaben Zieladresse und Zielport sowie aus dem Eintrag der NAT- 

Tabelle die Originaldaten extrahiert werden. Die Pakete werden entsprechend abgeän- 

dert. Die Prüfsummen werden neu berechnet und letztlich an den richtigen Computer 

des internen Netzwerkes weitergeleitet. 

Obwohl NAT inzwischen durch die IETF als RFC-Standard anerkannt ist, wurde 

seine Einführung kontrovers diskutiert. Das Schichten-Modell wird in einer grundle- 

genden Weise verletzt. Eigentlich darf eine Schicht keine Annahmen über den Inhalt 

der Nutzdaten einer höheren Schicht bilden. Durch das Verändern des TCP/UDP- 

Headers durch die Vermittlungsschicht wird diese Regel verletzt. NAT funktioniert 

auch nur für Verbindungen die mittels TCP oder UDP 9 aufgebaut werden. 

Lange war die Nutzung des File Transfer Protocol (FTP) nicht möglich, da hier im 

Nutzdatenstrom die originalen IP-Adressen mitversendet werden. Diese stimmen dann 

8 Und würde auch keinen Sinn machen. Denn wenn man zur Unterstützung von NAT in allen Systemen 

das IPv4 Protokoll aktualisieren wollte, könnte man ja auch gleich alle Systeme auf IPv6 

umstellen. 

9 UDP selber ist ein verbindungsloses Protokoll. Hier wird keine direkte Verbindung aufgebaut, sondern 

einzelne UDP-Pakete an einen Empfänger versendet. Im UDP-Header gibt es daher auch 

keine Sequenznummern. UDP-Pakete werden nicht quittiert. Bei Verlust eines UDP-Paketes wird 

der Sender darüber nicht informiert. UDP wird meist von Anwendungen benutzt, bei denen es auf 

eine schnelle Auslieferung der Daten ankommt. Solche Anwendungen sind zum Beispiel Audiooder 

Videostreaming. 


2.5 Proxy 25 

natürlich nicht mit den IP-Adressen eines veränderten Paketes überein. Inzwischen 

sind aber die meisten NAT-Router in der Lage, auch solche Verbindungen korrekt zu 

routen. 

Will man selber ein Protokoll entwickeln und über das Internet Daten damit versen- 

den, kann dies am Einsatz von NAT scheitern. Dieser Umstand ist bei der Implemen- 

tierung neuer Protokolle zu beachten. 

NAT hat allerdings klare Vorteile: In vielen privaten Netzen wird es heute eingesetzt. 

Kleine Netzwerke können so den Internetzugang miteinander teilen. Oftmals reicht ein 

in Deutschland in vielen Orten verfügbarer Digital Subscriber Line-Zugang (DSL) aus, 

mehrere Computer z.B. einer Wohngemeinschaft an das Internet anzubinden. 

Es soll angemerkt werden, dass NAT auch durchaus mehrfach hintereinander ange- 

wendet werden kann. So ist es möglich, dass das Gateway eines ISP selbst Teil eines 

nicht öffentlichen Netzwerkes ist. Ebenso wie der Endkunde, der seinen DSL-Anschluss 

mittels NAT auf mehrere Computer aufteilt, könnte auch der ISP NAT verwenden, um 

mehrere Kunden an das Internet anzubinden. 

2.5 Proxy 

In vielen größeren Firmen- oder Universitätsnetzwerken sollen Computer auf Dienste 

im Internet zugreifen können. Dabei können diese Computer durch den Einsatz von 

NAT private IP-Adressen aus den Bereichen 10.0.0.0, 172.16.0.0 oder 192.168.0.0 

verwenden. Die Anbindung des Netzwerkes an das Internet findet dabei mittels eines 

Gateways statt. Dieser verfügt über NAT-Fähigkeiten und kann Verbindungswünsche 

aus dem internen Netzwerk nach Außen realisieren. Die Internetanbindung teilen sich 

dabei alle Computer des internen Netzwerkes. Sollen viele Computer gleichzeitig das 

Internet benutzen, sinkt für den Einzelnen schnell die Datenübertragungsrate. 

Wollen zwei oder mehrere Computer eines internen Netzwerkes, wie in Abbildung 

2.9 gezeigt, die selbe Website abrufen, wird entsprechend oft eine Anfrage durch das 

Gateway geleitet. 

Das Gateway ändert gemäß seiner Konfiguration die Anfragen ab und vermerkt, von 

welchen Quellen sie kommen (Abschnitt 2.4). Dann wird der Server, auf dem die ange- 

forderte Website liegt, den Inhalt entsprechend oft an das Gateway zurücksenden. Sind 

auf der Website Medieninhalte wie Bilder, Audioelemente oder gar Videos enthalten, 

werden diese mehrfach übertragen. Das Gateway wendet seinen NAT-Algorithmus auf 

die ankommenden Pakete der Verbindung an und leitet die Daten an die ursprünglichen 

Computer zurück. 



Notebook 1 

192.168.0.2 

t 

Desktop 1 

192.168.0.2 

NAT Router 

192.168.0.1 / 

88.5.31.22 

Request www.apple.com Request www.apple.com 

Response www.apple.com 

(HTML + jpg/mp3...) 

Request 

www.apple.com 

Response 

www.apple.com 


NAT 

NAT 

NAT 

NAT 



Request 

www.apple.com 

Response 

www.apple.com 


Abbildung 2.9: Mehrfaches Abrufen einer Webseite 

WebServer 

www.apple.com 

17.254.3.183 

Viele Webseiten ändern sich aber nur relativ selten, so dass eine erneute Übertra- 

gung eigentlich unnötig ist. Die Internet Service Provider berechnen ihren Kunden die 

Nutzung des Internets meist auf Basis des übertragenen Datenvolumens. Würden nun 

Anfragen an das selbe Ziel im Internet gesammelt und nur einmalig ausgeführt werden, 

könnten leicht Kosten eingespart werden. 

Um dies zu erreichen, wird häufig ein Webproxy eingesetzt. Dieser hat einen Spei- 

cher, in den besuchte Webseiten abgelegt werden. Wird eine Seite erneut angefordert, 

kann sie aus dem Speicher genommen werden und muss nicht erneut aus dem Internet 

übertragen werden. In Abbildung 2.10 ist dies dargestellt. 

So können schnell mehrere Megabyte eingespart werden. Erfolgt die Abrechnung vo- 

lumenbasiert, wird sich die Rechnung entsprechend verringern. Aber auch in Bezug auf 

die Übertragungsgeschwindigkeit kann ein Webproxy von Vorteil sein. Die Daten, die 

intern aus dem Speicher entnommen werden, müssen nicht auf der Internetleitung über- 

tragen werden. Gleichzeitig stattfindende Datenübertragungen anderer Verbindungen 

aus oder an das Internet können so ein wenig schneller ausgeführt werden. Für ein 

kleines Netzwerk macht der Einsatz eines Webproxys aus diesen Gründen vielleicht 

keinen Sinn. Sollen sich aber sehr viele Computer eine Internetanbindung teilen, ist 


2.5 Proxy 27 

Notebook 1 

192.168.0.2 

t 

Request www.apple.com 



Desktop 1 

192.168.0.2 

Request 

www.apple.com 

Response 

www.apple.com 


WebProxy 

192.168.0.1 / 

88.5.31.22 

im Speicher 

vorhanden? 

>> Nein 

NAT 

NAT 

Kopie in 

den Speicher 

im Speicher 

vorhanden? 

>> Ja 

NAT 

Request www.apple.com 



Abbildung 2.10: Die Arbeitsweise eines Webproxys 

der Einsatz eines Webproxys durchaus rentabel. 

WebServer 

www.apple.com 

17.254.3.183 

Durch einen Webproxy können auch bestimmte Seiten gesperrt werden, etwa um 

Jugendschutzbestimmungen einzuhalten 10 . 

Um einen Webproxy zu verwenden, muss jedem Computer eines Netzwerkes, der 

diesen Nutzen soll, die Existenz des Webproxys mitgeteilt werden. Dafür muss man 

den verwendete Webbrowser des Anwenders entsprechend konfigurieren. Dies erfor- 

dert gerade in großen Netzwerken einen erheblichen Administrationsaufwand, da den 

meisten Anwendern eine solche Konfiguration nicht zu zumuten ist. Auch die Viel- 

zahl der erhältlichen Webbrowser und deren unterschiedliche Versionen erschweren die 

Konfiguration. Werden in einem Netzwerk, in dem ein Webproxy zur Zumgang in 

das Internet eingesetzt wird, die Proxyinformationen in einem Computer falsch oder 

gar nicht gesetzt, kann dieser Computer meist nicht auf die im Internet angebotenen 

10 Dies kann aber auch negative Auswirkungen habe. So wird in einigen totalitär regierten Ländern, 

wie China oder Nordkorea, die Nutzung des Internets dahingehend erschwert, dass auf bestimmte 

Webseiten nicht zugegriffen werden kann. Dies betrifft oft dem politischen System der Länder 

kritisch eingestellte Webseiten. 



Dienste zugreifen. Denn der Netzbetreiber hat oft entsprechende Schutzmaßnahmen 

(Firewalls) getroffen, um sein Netzwerk zu sichern. 

2.6 Transparenter Proxy 

Um den Aufwand der Konfiguration der Webbrowser zur Nutzung eines Proxys zu 

verringern, wurden Transparente Proxys entwickelt. Von der Funktionalität arbeiten 

sie grundsätzlich wie herkömmliche Proxys. Der Vorteil dabei ist, dass dem Anwender 

der Einsatz eine solchen Proxys nicht bewusst ist. Auch müssen am Betriebssystem 

, bzw. dem Webbrowser, des Anwenders keine Änderungen vorgenommen werden, da 

auch für diese der Einsatz des Proxys nicht sichtbar ist. 

Der Anwender ruft auf seinem Computer mit seinem Webbrowser eine Seite im In- 

ternet auf. Normalerweise wird dazu eine TCP-Verbindung über Port 80 aufgebaut. 

Unbemerkt vom Anwender wird diese Anfrage im Proxy behandelt. Hat dieser in sei- 

nem Speicher eine aktuelle Version der Webseite, sendet der Proxy diese dem Anwender 

zurück. Der transparente Proxy verwendet dabei die Absenderadresse des ursprünglich 

angesprochenen Webservers. Der Anwender bekommt von diesem Vorgang nichts mit. 

Untersucht er die IP-Pakete und die TCP-Datagramme, welche zu der Verbindung 

gehören, wird er keine Unregelmässigkeiten erkennen können. Daher auch der Name 

“transparenter“ Proxy. Das Vorhandensein bleibt dem Anwender verborgen. 


3 Sensornetzwerke 

3.1 Historische Entwicklung 

Wie so viele technische Errungenschaften, wurde die Entwicklung von Sensoren durch 

militärische Einrichtungen initiiert. Während des Kalten Krieges ließ die amerikani- 

sche Regierung das ” Sound Surveillance System“ (SOSUS) entwickeln. Dieses System 

besteht aus mehreren Unterwassersensoren, so genannten Hydrophone, die an strate- 

gisch wichtigen Punkten im Nordatlantik und im Pazifik angebracht wurden. Unter 

Wasser erzeugt die Bewegung eines jeden größeren Objektes, wie z. B. eines Untersee- 

bootes, bestimmte Ultraschallgeräusche, die von den Hydrophonen registriert werden 

können. Die Daten der einzelnen Hydrophone werden per Seekabel an Auswertesys- 

teme weitergeleitet. Dort werden die Daten analysiert und zur weiteren Auswertung 

aufbereitet. Feindliche Unterseeboote können so geortet und ihre Routen nachvollzo- 

gen werden [Whit05]. Inzwischen wird dieses System friedlich genutzt und ermöglicht 

Wissenschaftlern, die Ozeane auf seismische Aktivitäten zu untersuchen sowie den Zug 

von Walen und anderen großen Meerestieren zu beobachten [NiCo94]. 

Der technologische Fortschritt der Halbleiterindustrie ermöglichte den Bau immer 

speziellerer Sensoren. Waren die ersten Sensoren nur reine ” Datensammler“, kristalli- 

sierte sich Anfang der 80 Jahre des letzten Jahrhunderts eine neue Betrachtungsweise 

heraus. Einerseits wollte man mehrere Sensoren miteinander verbinden. Dabei sollten 

die Sensoren untereinander Daten austauschen. Andererseits sollte die Datenauswer- 

tung, die bislang extern ausgeführt wurde, direkt an einzelne Sensorknoten delegiert 

werden. 

Eines der ersten Forschungsprojekte dieser Art war das ” Distributed Sensor Net- 

works“ -Programm (DSN) der amerikanischen ” Defense Advanced Research Projects 

Agency“ 

(DARPA). Die DARPA untersteht dem ” Department of Defense“ (DoD), dem ameri- 

kanischen Verteidigungsministerium. 1 

1 Sie ist jene Einrichtung, die unter anderem mit der Entwicklung des ARPANET die Grundlagen 

des heutigen Internets legte. 

29 


30 3 Sensornetzwerke 

Robert Kahn, einer der Entwickler des TCP/IP-Protokolls, war die Leitung dieses 

Projektes übertragen worden. Er arbeitete die Anforderungen heraus, die noch heute 

für die meisten modernen Sensornetzwerke gelten. Die Kernfunktionen eines Sensor- 

netzwerk wurden 1978 auf einem internationalen Workshop der Carnegie Mellon Uni- 

versity, Pittsburgh definiert. Das Thema dieses Workshops lautete ” Distributed Sensor 

Nets“ [proc78]. 

Die technologischen Anforderungen an ein Sensornetzwerkes wurden nach [ChKu03] 

auf vier wichtige Punkte reduziert: 

• Sensorfunktionalität, d.h. Detektion von Umgebungsvariablen 

• Kooperative Kommunikation der Sensorknoten 

• Verarbeitung der gewonnenen Daten 

• Bildung Verteilter Systeme 

Der hier eingeführte Begriff ” Verteiltes System“ lässt sich nach [TavS03] so definieren: 

” Ein verteiltes System ist eine Menge voneinander unabhängiger Computer, die dem 

Benutzer wie ein einzelnes, kohärentes System erscheinen.“ 

Nicht mehr ein einzelner Sensor steht im Interesse der Forschung, sondern der Ver- 

bund mehrerer Sensoren zu einem Netzwerk. 

Sieht man die vorgestellten Anforderungen im geschichtlichen Kontext, kann man 

die Herausforderung für die Entwicklung erkennen. Die einzelnen Komponenten waren 

so nicht vorhanden. Wie so oft skizzierten die Wissenschaftler Systeme, die technisch 

ihrer Zeit weit voraus waren. 

Erst 1969 war es gelungen, mehrere Computer über Telefonleitungen erfolgreich mit- 

einander zu koppeln [LCCK + ]. Die dabei verbundenen Computer waren Hochleistungs- 

rechner. Nun sollten viele kleine Sensoren miteinander gekoppelt werden, eine Aufgabe 

die zu diesem Zeitpunkt unlösbar erschien. 

Ein weiterer wichtiger Aspekt des DSN-Projektes war das so genannte ” distributed 

problem-solving“, was übersetzt soviel wie ” Verteiltes Problem-Lösen“ bedeutet. Meh- 

rere Arbeiten über dieses Problem entstanden. Nicht nur Wissenschaftler der Carnegie 

Mellon University waren involviert. Auch am Massachusetts Institute of Technology, 

Cambridge und an der University of Massachusetts, Amherst wurden Lösungen für die- 

se Probleme entwickelt. Mit [LeCo81] und [WHRBS + 81] sollen hier nur einige Vertreter 

aufgeführt werden. 


3.2 Einsatz von drahtlosen Sensornetzwerken 31 

Der Auftraggeber des DSN-Projektes, das amerikanische Verteidigungsministerium 

DoD, erkannte sehr schnell die strategischen Vorteile der Verwendung von Sensor- 

netzwerken. Am DoD wurde ein eigenes Programm zur Entwicklung von Sensornetz- 

gestützter Kriegsführung erschaffen. Diese ” neue“ Kriegsführung wurde mit dem Begriff 

” Network Centric Warfare“ umschrieben. Eine Abhandlung über dieses Programm 

beschreibt [AlGS99]. Die Autoren stellen darin den Einsatz von Sensornetzen als Mei- 

lenstein in der Geschichte moderner Kriegsführung dar. 

Ein Beispiel ist ” Cooperative Engagement Capability“ (CEC) der U.S. Navy [Team95]. 

Dieses System besteht aus mehreren Knoten, von denen einige mittels Radar Daten 

über mögliche feindliche Flugobjekte sammeln. Die gesammelten Daten werden von 

anderen Knoten des selben Netzes verarbeitet und liefern so Zieldaten an verbundene 

Abwehrstationen (Flugzeuge, Schiffe, Bodenstationen) aus. 

Neben dem militärischen Einsatz von Sensornetzwerken wurde auch im zivilen Sektor 

Forschungs- und Entwicklungsarbeit erbracht. Vorhandene Systeme werden im nächs- 

ten Abschnitt aufgezeigt. 

3.2 Einsatz von drahtlosen Sensornetzwerken 

In der Industrieautomation steuern Sensoren Arbeitsabläufe und ermöglichen so die 

automatisierte Produktion. 

Drahtlose Sensornetzwerke können auch zur Überwachung von land- und forstwirt- 

schaftlichen Gebieten eingesetzt werden. In Waldflächen können weitläufig viele kleine 

Sensoren ausgebracht werden, die stündlich die Temperatur messen. Wird von mehre- 

ren Sensoren ein sprunghafter Temperaturanstieg gemeldet, kann daraus auf ein ent- 

stehendes Feuer geschlossen und entsprechende Gegenmaßnahmen eingeleitet werden 

[SiSa03]. 

Ein Landwirt könnte seine Wiesen mit Regensensoren ausstatten, die einmal täg- 

lich die Niederschlagsmenge melden. Aufgrund dieser Daten kann der Landwirt dann 

entscheiden, ob er seine Wiesen bewässern muss oder ob die natürliche Bewässerung 

ausreichend ist. 

Auf der ” Great Duck Island“ im US Bundesstaat Maine wurde nach dieser Arbeit 

[MPSC + 02] ein Sensornetzwerk aus mehreren Sensorknoten aufgebaut, welches Biolo- 

gen einen tieferen Einblick in die Brutgewohnheiten der dort ansässigen Wasservögel 

erlaubte. 

In dieser Diplomarbeit soll ein anderes Einsatzgebiet von Sensornetzwerken, die 

Hausautomatisierung, betrachtet werden, auch wenn das zu untersuchende Problem 



leicht auf andere Einsatzgebiete ausgeweitet werden kann. 

Zur Hausautomatisierung werden Sensornetzwerke verwendet, um die Steuerung und 

Automation von elektrischen Systemen im Haus zu ermöglichen. Im intelligenten Haus 

sind alle elektrischen Geräte wie Lichtschalter und Leuchten, Temperatursensoren und 

Heizkörper oder Alarmsensoren miteinander durch ein drahtloses Sensornetzwerk ver- 

bunden. Der Anwender kann alle Funktionen per Computer fernsteuern. Es können 

einige Sensorknoten vorhanden sein, die selbst keine sensorischen Daten liefern, aber 

auf solche reagieren können. So sind intelligente Lichtschalter denkbar, die bei Registra- 

tion einer bestimmten Schwellhelligkeit angeschlossene Leuchten an- oder ausschalten. 

Dabei kann die Helligkeit durch den Lichtschalter mittels eines eigenen Lichtsensensors 

selbst ermittelt oder von einem anderen Sensorknoten bezogen werden. 

3.3 Besondere Sprachregelung bei Verwendung des 

Begriffes ” drahtloses Sensornetzwerk“ 

An dieser Stelle soll darauf hingewiesen werden, dass die Bezeichnung ” Sensorknoten“ in 

Verbindung mit ” Sensornetzwerken“ allgemein ein wenig unpräzise ist. Einzelne Sensor- 

knoten eines Netzes beinhalten hier nicht nur die ” sensorische“ Funktionalität, sondern 

können selbst auch als aktives Element fungieren. Zusätzlich müssen sie Netzwerk- 

funktionalität unterstützen, um untereinander Daten austauschen zu können. Spricht 

man von einem Sensornetzwerk, wird meist davon ausgegangen, dass es sich bei der 

eingesetzten Kommunikationstechnik um eine drahtlose Zugangstechnik handelt. Man 

lässt jedoch diesen Aspekt bei der Bezeichnung weg und spricht nur von einem Sen- 

sornetzwerk. 

In der Literatur hat sich diese Art der Definition durchgesetzt. Dieser Sprachregelung 

schliesst sich der Autor dieser Diplomarbeit an. Bei Abweichungen soll explizit darauf 

hingewiesen werden. 

3.4 Beispiele für drahtlose Sensornetzwerke 

Sucht man in der Literatur nach Beispielen für drahtlose Sensornetzwerke, stößt man 

zu allererst auf die ” Berkeley Motes“ und das damit verbundene ” Smart Dust“ Projekt. 

Als Projekt der DARPA wurde ” Smart Dust“ an der University of California Berke- 

ley entwickelt [PiKa]. Viele nachfolgende Systeme setzen die Weiterentwicklungen der 

” Berkeley Motes“ ein. Mit dem TinyOS“, welches in Abschnitt 4.1.2.2 näher beschrie- 

” 


3.5 ZigBee als drahtlose Übertragunstechnik in Sensornetzwerken 33 

ben wird, wurde das Betriebsystem dieser Knoten als OpenSource-Software 2 öffentlich 

gemacht. 

An der FU Berlin wurde ein eigener Sensor entwickelt [Berl]. Mehrere Netzwerke 

wurden damit aufgebaut. In Abschnitt 4.1.1 wird eine TCP/IP-Implementierung vor- 

gestellt, die es erlaubt, Sensoren in IP-basierte Netzwerke zu integrieren. 

Im folgenden Abschnitt soll ZigBee, eine auf dem IEEE-802.15.4-Standard aufbau- 

ende Spezifikation, näher beschrieben werden. 

3.5 ZigBee als drahtlose Übertragunstechnik in 

Sensornetzwerken 

Jede Datenübertragung in Computernetzwerken erfordert die Vereinbarung eines be- 

stimmten Übertragungsprotokolls [Tane03]. Alle Kommunikationspartner müssen die- 

ses verwenden, damit eine Datenübertragung stattfinden kann. 

Je nach Protokoll wird eine gewisse Menge an Protokolldaten generiert und der 

Übertragung der Nutzdaten hinzugefügt. Das Verhältnis zwischen Nutz- und Proto- 

kolldaten wird Protocol Overhead genannt. Ist dieses Verhältnis sehr viel größer als 1, 

ist der Protocol Overhead gering. Die Übertragung mit dem eingesetzten Protokoll ist 

optimal. In Bezug auf Energie fallen nur wenige zusätzliche Kosten an. 

WLAN und Bluetooth ermöglichen je nach Version, das Senden mit hohen Datenra- 

ten und sind somit für die Übertragung großer Datenmengen geeignet. Moderne LANs 

mit Anschluss an das Internet profitieren davon. Man kann gleichzeitig im WWW 

surfen, E-Mails lesen oder per FTP Dateien mit Anderen austauschen. 

Für ein Sensornetzwerk mit seinen anfallenden geringen Datenmengen sind sie jedoch 

überdimensioniert. Im Szenario ” Hausautomatisierung“ fallen bei den meisten Sensor- 

knoten nur minimale Datenmengen an. Im einfachsten Fall sendet ein Lichtschalter in 

unregelmäßigen Zeitabständen seinen Status in Form von ” AN“ oder ” AUS“. Dies kann 

durch wenige Bytes realisiert werden. 

Würde man in Sensornetzen WLAN oder Bluetooth zur Datenübertragung einsetzen, 

wäre der Protocol Overhead sehr groß. Man müsste sehr viel Energie aufwenden, ob- 

wohl nur wenige Nutzdaten zu übertragen sind. 

Man möchte aber kleine, energiesparende und möglichst kostengünstige Sensorknoten 

verwenden. Diese sollen meist mittels einer Batterie oder eines Akkumulators betrie- 

2 OpenSourc-Programme sind Programme, deren Quellcode frei verfügbar ist. Entwickler auf der 

ganzen Welt können ohne rechtliche Einschränkungen an diesem Code arbeiten und eigene Veränderungen 

einbringen (solange das Resultat ebenfalls als OpenSource eingestuft wird). 



ben werden. 

Deshalb wurde von der IEEE im Jahr 2003 der Standard ” IEEE 802.15.4“ für Perso- 

nal Area Network’s (PAN) freigegeben [Inst]. In diesem ist eine drahtlose Netzwerk- 

technologie für die Übertragung mit geringen Datenraten definiert. Trotz dieser Ein- 

schränkung ist IEEE 802.15.4 für Sensornetzwerke ideal. Ein Vorteil sind die geringen 

Energieanforderungen an die Sensorknoten. Allerdings ist die Reichweite, d.h. der ma- 

ximale Abstand zwischen zwei Kommunikationspartnern, sehr gering. Nur wenige 10 

Meter können ohne weitere Techniken, wie Repeater, überbrückt werden. Kommunika- 

tionspartner, die WLAN oder Bluetooth einsetzen, können durchaus mehrere hundert 

Meter voneinander entfernt sein. 

In der Hausautomatisierung sind jedoch einige wenige Meter ausreichend, durch den 

Einsatz entsprechender Repeater ist dieser Wert leicht zu vergrößern. 

Die ZigBee-Alliance entwickelte die ZigBee-Spezifikation [ZigB], die auf dem IEEE 

802.15.4 Standard aufbaut. Der ZigBee-Alliance gehören viele namhafte Firmen wie 

” Chipcon“, “Freescale“ oder ember“ an. Eine vollständige Übersicht kann unter [ZigB] 

” 

gefunden werden. Mit ZigBee können gerade in der Hausautomatisierung leicht kleine 

Netzwerke aufgebaut werden. Die Entwicklung von ZigBee ist noch nicht vollstän- 

dig abgeschlossen. Die Hersteller arbeiten ständig an der Verbesserung der ZigBee- 

Spezifikation. 

3.5.1 Koordination in ZigBee-Netzwerken 

In jedem ZigBee-Netzwerk muss ein Knoten als Koordinator arbeiten. Er kümmert sich 

um die Vergabe der Adressen der Vermittlungsschicht des ZigBee-Protokollstapels. Der 

Koordinator wird als ” Personal Area Network“ -Coordinator (PAN) bezeichnet. Grund- 

sätzlich können alle Knoten eines Netzes diese Funktion übernehmen. Jeder Knoten 

sucht nach seiner Initialisierung seine Umgebung nach vorhandenen Netzwerken ab. 

Findet er keines, kann er, falls er die Fähigkeiten besitzt, ein neues Netzwerk starten. 

Er würde dann als PAN-Coordinator fungieren. 

Wird ein weiterer Knoten in seiner Nähe aktiv, kann dieser dem Netzwerk beitreten. 

Der PAN-Coordinator wird entsprechende Maßnahmen ergreifen, um dem neuen Kno- 

ten eine gültige Adresse zu zuweisen (Siehe Abschnitt 3.5.3). Anschließend werden die 

beiden Knoten untereinander ihre Fähigkeiten austauschen. Werden weitere Knoten in 

das Netzwerk integriert, finden die selben Mechanismen statt. Der PAN-Coordinator 

weiß am Ende über die Fähigkeiten jedes einzelnen Knotens bescheid. 



3.5.2 Unterstützte Netztopologien 

In Abbildung 3.1 sind mögliche Netztopologien dargestellt. 

Stern Cluster-Tree 

Mesh 

PAN Koordinator Full Function Device (FFD) Reduced Function Device (RFD) 

Abbildung 3.1: Mögliche Topologien in ZigBee-Netzen (nach [ZigB]) 

Im einfachsten Fall ist ein ZigBee-Netzwerk sternförmig aufgebaut. Zentral nimmt 

der PAN-Coordinator alle Anfragen einzelner Knoten entgegen. Er ist bei jeder Kom- 

munikation zwischen den Knoten involviert. Eine direkte Verbindung zwischen zwei 

Knoten existiert nicht. Netzwerke, die einer solchen Topologie folgen, sind besonders 

anfällig gegenüber Ausfällen. Reagiert der PAN-Coordinator nicht mehr, kann auch 

das Netzwerk nicht mehr arbeiten. 

Die zweite Netztopologie wird als “Cluster Tree“-Topologie bezeichnet. An einen 

PAN-Coordinator können mehrere Knoten sternförmig angeschlossen werden, die wie- 

derum selber der zentrale Punkt einer Sterntopologie sind. Wollen zwei entfernte Kno- 

ten miteinander kommunizieren, werden ihre Daten entsprechend durch das Netz ge- 

routet. 

Können alle Knoten untereinander ohne Zuhilfenahme des PAN-Koordinators Daten 

austauschen, spricht man von einer Mesh- oder Peer-to-Peer-Topologie. Zwar ist auch 

hier ein PAN-Coordinator für die Vergabe von Adressen zuständig, die eigentliche 

Kommunikation zwischen den Knoten regeln diese aber selbstständig. 

In Abbildung 3.1 wird eine weitere Unterscheidung deutlich. ZigBee Knoten werden 

in die zwei Arten ” Full Function Device“ (FDD) und ” Reduced Function Device“ (RFD) 

unterschieden. Ein FDD kann mehrere Funktionen gemäß der ZigBee-Spezifikation er- 

bringen, während die Funktionalität von RFDs eingeschränkt ist. Die Rolle des PAN- 

Coordinator kann immer nur ein FDD übernehmen [ZigB]. In den Netztopologien 

” Cluster-Tree“ und Mesh“ können einige der Knoten auch Routingfunktionen über- 

” 

nehmen. Sie leiten dann Daten durch das Netzwerk. Dazu führen sie Routingtabellen, 



in denen die kürzesten Wege beschrieben werden 3 . 

Die gezeigten Topologien müssen aber nicht mit den physikalischen Gegebenheiten 

übereinstimmen. So kann es durchaus vorkommen, dass zwei Knoten räumlich neben- 

einander liegen. Beide können jedoch je nach Topologie nicht direkt miteinander kom- 

munizieren, sondern müssen unter Umständen einen weit entfernten PAN-Coordinator 

beanspruchen. 

3.5.3 Adressierung in ZigBee-Sensornetzwerken 

Das im Kapitel 2 eingeführte Schichtenmodell kann auch für ZigBee angewendet wer- 

den. Die IEEE hat in ihrem IEEE 802.15.4 Standard die unteren beiden Schichten, die 

Bitübertragungs- und die Netzwerkschicht definiert. Darauf aufbauend wurden durch 

die ZigBee-Alliance zwei weitere Schichten festgelegt. Abbildung 3.2 zeigt vereinfacht 

den ZigBee-Protokollstapel. 

Anwendungsschicht 

Netzwerkschicht 

NWK Sicherheits- 

Management 

Sicherungsschicht 

Bitübertragungsschicht 

Anwendung 

868/915 MHz Funkzugriff 

Anwendungsumgebung 

Anwendungsunterstützung 

NWK Nachrichten- 

Management 

ZigBee 

Device Objects 

(ZDO) 

NWK Routing- 

Management 

2.4 GHz Funkzugriff 

Abbildung 3.2: Der ZigBee-Protokollstapel (nach [ZigB]) 

3 Auch der PAN-Coordinator muss eine solche Tabelle vorhalten, schließlich ist er vor allem in der 

Stern-Topologie für das Routing von Daten verantwortlich. 



Abweichend vom Internetreferenzmodell sind insgesamt nur vier Schichten definiert. 

Die genaue Funktionsweise kann der Spezifikation [ZigB] entnommen werden. An dieser 

Stelle soll nur auf einige Punkte hingewiesen werden. 

In ZigBee-Netzwerken können die einzelnen Knoten über verschiedene Methoden 

adressiert und angesprochen werden. Sowohl der IEEE-Standard als auch die darauf 

aufbauende ZigBee-Spezifikation führen eigene Adressen ein. Mit diesen kann sowohl 

ein Knoten als auch ein logischer Endpunkt an diesem Knoten eindeutig identifiziert 

werden. 

3.5.3.1 IEEE-Adresse 

In der Netzwerkschicht (OSI-Schicht 2) werden 64 Bit lange Adressen verwendet, wel- 

che dem IEEE EUI-64 Format entsprechen [IEEE]. Eine solche Adresse könnte etwa 

ca:ed:84:ff:ff:32:54:76 sein. Diese Adressen kann man mit den ” Medium Access 

Control“ -Adressen des Internetreferenzmodells vergleichen. Auch hier wird jedem Kno- 

ten, der auf das Funkmedium zugreifen will, eine eindeutige Adresse zugewiesen. Die 

Vergabe erfolgt, ähnlich wie bei der MAC-Adresse von Internetsystemen, durch den 

Hersteller. Somit soll garantiert werden, dass kein Knoten dieselbe IEEE-Adresse wie 

ein anderer erhält. 

3.5.3.2 NWK-Adresse 

Auf der nächst höheren Schicht, der Vermittlungsschicht, werden durch die ZigBee 

Alliance 16-Bit lange, so genannte Network-Adressen (NWK) definiert 4 . Vergleicht 

man den ZigBee Protokollstapel mit dem TCP/IP Protokollstapel, könnte man die 

NWK-Adresse mit der IP-Adresse gleichsetzen. Beide werden in der selben Schicht 

eingesetzt. Allerdings treten Unterschiede in den verwendeten Protokollen auf. Eine 

NWK-Adresse wird hexadezimal ausgeben und kann im Bereich von 0x00 bis 0xff 

liegen. 

Die Vergabe der NWK-Adresse erfolgt zentral durch den PAN-Coordinator. Wäh- 

rend der Kommunikation in einem ZigBee-Netz wird nicht immer die IEEE-Adresse 

verwendet. Stattdessen wird die Adressierung mit Hilfe der NWK-Adresse durchge- 

führt. Die Routingtabellen des PAN-Coordinators und der ZigBee-Router können so 

4Der englische Begriff Network-Address kann in der deutschen Übersetzung leicht zu Verwirrung 

führen. Im ISO-OSI Referenzmodell heißt Schicht 2 Data Link Layer“, wird aber im Deutschen mit 

” 

” Sicherungsschicht“ übersetzt. Die dritte Schicht, im Englischen mit Network Layer“ bezeichnet, 

” 

wird im Deutschen als Vermittlungsschicht“ bezeichnet. Da ZigBee ein relativ neuer Standard ist, 

” 

lassen sich kaum deutsche Literaturangaben finden. In dieser Arbeit wird deshalb der englische 

Begriff Network-Address“ oder kurz NWK-Adresse“ verwendet. 

” ” 



verkleinert werden, wodurch sowohl Speicherplatz als auch Energie eingespart werden 

können. 

3.5.3.3 Binding 

In ZigBee-Netzwerken muss nicht jeder physikalische Endpunkt einen eigenen Zugang 

zum drahtlosen Netzwerk haben. Einzelne Knoten eines Netzwerkes können durch- 

aus mehrere Endpunkte verwalten. Diese Endpunkte teilen sich den Medienzugriff. Im 

Beispiel, welches in der Abbildung 3.3 dargestellt ist, können die beiden Schalter auf 

dem linken Sensorknoten verschiedene Leuchten eines anderen Sensorknotens steuern. 

Damit ein Schalter eine der Leuchten ansprechen kann, muss er diese adressieren kön- 

Funkzugriff 

Schalter 1 

Schalter 2 

Funkzugriff 

Leuchte 1 Leuchte 2 Leuchte 3 

Abbildung 3.3: Endpunkte in ZigBee (nach [ZigB]) 

nen. Durch die bislang erläuterten Adressen (IEEE- und NWK-Adresse) ist dies nicht 

eindeutig möglich. Der Schalter kann zwar den Knoten, auf dem sich die zu kontrollie- 

rende Leuchte befindet, identifizieren und ansprechen, aber die direkte Steuerung der 

Leuchte allein mit den IEEE- und NWK-Adressen ist nicht möglich. 

Um dieses Problem zu Lösen, wurde ein dem Portkonzept des TCP/UDP-Protokolls 

(siehe Abschnitt 2.3) ähnlicher Ansatz gewählt. Zum besseren Verständnis soll noch 

einmal die Schicht 4 des ZigBee-Protokollstapels genauer betrachtet werden (Abbildung 

3.4). 

Die Anwendungsschicht ist in verschiedene Elemente aufgeteilt. Der ” Application 

Support Sublayer“ (APS) gewährleistet die Dienstnutzung der Vermittlungsschicht für 



Anwendungsschicht 

Anwendung 

Anwendungsumgebung 

Application Support Sublayer (APS) 

Anwendungsunterstützung 

ZigBee 

Device Objects 

(ZDO) 

Abbildung 3.4: Die Anwendungsschicht im ZigBee Protokollstapel 

die beiden Elemente ” ZigBee Device Objects“ (ZDO) und “Application Frameworks“ 

(AF). Jeder Knoten besitzt ein ZDO. In diesem wird festgehalten, wie der Knoten ar- 

beitet (FDD oder RFD, PAN-Coordinator oder normaler Knoten) und welche Einstel- 

lungen getroffen wurden. Ebenfalls ist eine Schnittstelle zu den Sicherheitsfunktionen 

im ZDO integriert. 

Das interessante an ZigBee ist das Application Framework. Hier können mehrere 

Anwendungen auf einem Knoten ausgeführt werden. Diese Anwendungen können für 

den Anwender dann die Funktionalität eines Schalters, einer Lampe (deren Steuerung) 

oder eines Temperatursensors bieten. 

Jeder Anwendung wird dabei eine eigene Endpunktnummer (EndPoint ID) vergeben. 

Dies geschieht durch das ZDO. Insgesamt sind 255 Nummern vorhanden (Länge 8 Bit). 

Dabei ist Nummer 0 standardmäßig dem ZDO zugeordnet. Die Nummern 241-255 sind 

reserviert, so dass maximal 240 Anwendungen (Endpunktnummer 1-240) pro Knoten 

realisierbar sind. 

Ein jeder Knoten eines Netzwerkes führt eine so genannte Binding-Tabelle, in der die 

Beziehungen der einzelnen Endpunkte untereinander verzeichnet sind. Dabei können 

auch ” Verbindungen“ zu Endpunkten anderer Knoten vorhanden sein. Anhand dieser 

Tabellen können Daten und Kommandos zwischen den einzelnen Endpunkten ausge- 

tauscht werden. 



3.5.4 Profilunterstützung in ZigBee 

Um eine reibungslose Zusammenarbeit der einzelnen Knoten und damit der einzelnen 

Anwendungen zu gewährleisten, wurde der Einsatz von Profilbeschreibungen festge- 

legt. Die ZigBee-Alliance überwacht die Erstellung solcher Profile. In ihnen sind alle 

Funktionalitäten festgelegt, über die ein Endpunkt verfügt. 

Vereinfacht lassen sich die Profil wie folgt beschreiben: Eine Leuchte könnte zum Bei- 

spiel das Profile ” Einfache Leuchte“ unterstützen. Damit wissen alle anderen Anwen- 

dungen, dass eine solche Leuchte zwei Funktionen hat: ” An“ und ” Aus“. Eine technisch 

fortgeschrittenere Leuchte ist vielleicht dimmbar. Dann könnte sie das Profil “Dimm- 

bare Leuchte“ unterstützen. Dieses erlaubt vier Funktionen: ” An“, ” Aus“, “Aufhellen“ 

und ” Abdunkeln“. 

Indem sich alle Hersteller von ZigBee-konformer Hardware an diese Profile halten 

müssen, sollen Inkompatibilitäten vermieden werden. 

Natürlich kann jeder Hersteller eigene Profile entwickeln und bei der ZigBee-Alliance 

zur Bestätigung einreichen. Ist dies erfolgreich, wird das Profil in die Spezifikation 

aufgenommen und kann auch von anderen Herstellern genutzt werden. 

Jeder Knoten kann dabei bis zu 240 verschiedene Profile unterstützen, die jeweils im 

Application Framework durch die Endpunktnummern adressiert werden können. 


4 Kopplung von Sensornetzwerken an 

IP-basierte Kommunikationssysteme 

Ist ein Haus mit einem Sensornetzwerk ausgestattet, liegt der Wunsch nahe, dieses auch 

per Computer fernzusteuern. Vielfältige Szenarien bieten sich an: So könnten Eltern 

bequem vom Sofa aus mittels eines PDA’s überprüfen, ob die Kinder im Stockwerk 

darüber auch wirklich die Lichter gelöscht haben 1 . Lohnt sich der Weg in den Keller 

oder ist die Buntwäsche noch nicht fertig gewaschen? 

Im Urlaub könnten misstrauische Zeitgenossen überprüfen, ob die Reinigungskraft 

auch wirklich zur später abgerechneten Zeit im Haus war. Oder ob es sich bei der 

Meldung eines Bewegungssensors um den Raub der Hausjuwelen handelt. Im letzten 

Fall könnte das vernetzte Heim automatisch ein auf Grund einer Bewegungsmeldung 

aufgenommenes Bild des mutmaßlichen Täters an die lokalen Polizeidienststellen wei- 

terleiten. 

Für drahtgebundene Sensornetzwerke gibt es zahlreiche Ansätze, eine direkte Kopp- 

lung an Computernetzwerke durchzuführen, welche auf dem IP-Protokoll basieren. Im 

Bereich der drahtlosen Sensornetzwerke, die Gegenstand dieser Arbeit sind, ist dies 

aber ungleich schwerer. 

Bei der Entwicklung von Sensornetzwerktechnologien werden folgende Forderungen 

an die einzelnen Knoten gestellt: 

• Energieeffizienz und lange Laufzeiten 

• Kompakte Bauweise 

• Kostengünstige Herstellung 

Der wichtigste Punkt ist die Forderung nach einer guten Energieeffizienz [ChKu03] 

[EsRGK99] . In drahtlosen Netzwerken sind die meisten Knoten ohne feste Anbindung 

an das Stromnetz konzipiert. Diese Knoten arbeiten dabei mit Einwegbatterien oder 

1 Inwieweit dies rechtlich zu bewerten ist (Eingriff in die Privatsphäre der Kinder), ist nicht Gegen- 

stand dieser Arbeit. 

41 


42 4 Kopplung von Sensornetzwerken an IP-basierte Kommunikationssysteme 

Akkumulatoren. Da man nicht ständig die Batterien austauschen will, sollten die Kno- 

ten sehr energiesparend arbeiten. Durch diese Forderung verfügen die Knoten oft nur 

über eingeschränkte Rechenfähigkeiten. Dabei werden Abstriche bei der Ausstattung 

des Arbeitsspeichers und den verwendeten Prozessoren gemacht. Es wird nur soviel 

investiert, wie für die eigentlichen Aufgaben notwendig ist. 

4.1 Mögliche Ansätze zur Kopplung 

Sollen Knoten zweier verschiedener Netzwerke miteinander kommunizieren können, 

müssen sie sich auf die Verwendung eines Protokolls verständigen. Kann dies nicht 

vereinbart werden, ist eine direkte Kommunikation nicht möglich (Abbildung 4.1a.). 

Um dieses Problem zu lösen, gibt es prinzipiell nur zwei Möglichkeiten: 

Ein Weg ist die Implementierung eines der Protokolle in beiden Netzwerken (Ab- 

bildung 4.1b.). Zusätzlich zum eigentlichen Protokoll können die Knoten des einen 

Netzwerks auch das Protokoll des anderen benutzen. Damit können alle Knoten der 

beiden Netzwerke miteinander kommunizieren. 

Die zweite Möglichkeit führt zur Integration eines Protokollumsetzers. Dieser fun- 

giert als Mittler zwischen den Knoten der beide Netzwerke und wird in ihre Kommuni- 

kation eingeschleift (Abbildung 4.1c.). Der Protokollumsetzer hat zwei Schnittstellen. 

Beide unterstützen jeweils ein Protokoll. Will ein Knoten aus dem einen Netzwerk mit 

einem Knoten aus dem anderen kommunizieren, wird der Protokollumsetzer die Daten 

und Kommandos in die entsprechenden Strukturen des anderen Protokolls transformie- 

ren und in das zweite Netzwerk weiterleiten. In Gegenrichtung wird die Transformation 

umgekehrt durchgeführt. 

Für beide Möglichkeiten sind verschiedene Lösungsansätze in der Literatur zu finden, 

von denen einige beispielhaft im Folgenden aufgezeigt werden sollen. 


4.1 Mögliche Ansätze zur Kopplung 43 

a.) 

b.) 

c.) 

IP 

IP: 10.8.0.1 

IP 

IP: 10.8.0.1 

IP 

IP: 10.8.0.1 

IP: 10.8.0.2 

IP: 10.8.0.2 

IP ZigBee 

IP 

IP ZigBee 

Protokollumsetzer 

ZigBee 

NWK: 1xaa 

ZigBee 

NWK: 1xaa 

NWK: ax22 

ZigBee + IP 

NWK: 1xaa 

IP: 10.8.0.5 

NWK: ax22 

IP: 10.8.0.6 

IP: 10.8.0.2 NWK: ax22 

NWK: 0x3c 

NWK: 0x3c 

IP: 10.8.0.7 

NWK: 0x3c 

Abbildung 4.1: Mögliche Ansätze zur Kopplung von Systemen, hier am Beispiel von 

IP- und ZigBee-Netzwerken 

a.) Beide Netzwerke nutzen unterschiedliche Protokolle. Eine direkte 

Kommunikation zwischen den Netzwerken ist nicht möglich 

b.) Im ZigBee-Netzwerk (rechts) wurde das IP-Protokoll implementiert. 

Die ZigBee-Knoten erscheinen als Knoten im IP-Netzwerk 

c.) Ein Protokollumsetzer transformiert die Protokolldaten der Knoten 

der beiden Netzwerke in das jeweils andere Protokoll 



4.1.1 Implementierung der TCP/IP-Suite in Sensornetzwerke 

In der Literatur wird häufig argumentiert, dass die Anforderungen an die Knoten eines 

drahtlosen Sensornetzwerks energieeffizient und kostengünstig zu arbeiten, die Nutzung 

der TCP/IP-Protokollsuite nicht erlaubt [Dunk03], [ZhGu04]. Die meisten drahtlosen 

Sensornetzwerke sind so ausgelegt, dass die vorhandene Rechenkapazität der einzelnen 

Knoten nicht ausreicht, die komplexen Routingalgorithmen zu verarbeiten. 

Am ” Swedish Institute of Computer Science“ wurde federführend von Adam Dun- 

kels die Implementierung der TCP/IP-Protokollsuite in Sensornetzwerke vorgestellt. 

In [Dunk03] wurde zunächst der TCP/IP-Protokollstapel angepasst, um ihn auch 

auf 8-Bit-Systemen ausführen zu können. Der original TCP/IP-Code ([Post81b] und 

[Post81c]) umfasst einige hundert Kilobyte, die Verarbeitung erfordert ebenso eini- 

ge hundert Kilobyte Arbeitsspeicherkapazität. Somit müssen zur Verarbeitung von 

TCP/IP Verbindungen mehrere hundert Kilobyte Arbeitsspeicher vorhanden sein. Die 

meisten Sensorknoten sollen aber mit weniger als hundert Kilobyte Arbeitsspeicher aus- 

kommen. Damit schliesst sich die Nutzung der herkömmlichen TCP/IP-Implementierungen 

aus. 

Dunkels stellt in [Dunk03] und [DuAV04] 2 eigene Implementierungen vor. Die eine 

wird als lwIP (lightweight IP) bezeichnet. Sie integriert die Protokolle IP, ICMP, UDP 

und TCP in vereinfachter Form. Dabei wurde der frei erhältliche Code der originalen 

Protokolle neu geschrieben und durch geeignete Programmierung vereinfacht. Durch 

diese Vereinfachungen konnte er auch auf einem 8-Bit System laufen. Als Testsystem 

wurde ein an der FU Berlin entwickeltes ” Embedded Sensor Board“ [Berl] verwen- 

det, obgleich auch andere Hardware inzwischen diesen Protokollstapel unterstützen 

[DFGV04]. In der zweiten Implementierung uIP wird eine noch stärkere Verringerung 

des Speicheraufwands erreicht, indem nur die notwendigsten Fähigkeiten implementiert 

wurden [Dunk03]. 

Ein weiterer Nachteil, der gegen den Einsatz der TCP/IP-Suite in Sensornetzwerken 

spricht, ist der in Abschnitt 3.5 schon angeführte Protokolloverhead. Mit minimalen 

Headergrößen von 28 Byte bei Verwendung von IP/UDP (20 Byte (IP) + 8(UDP)) 

bzw. sogar 40 Byte bei IP und TCP (je mind. 20 Byte) fällt der Protokolloverhead bei 

Sensordatenmengen von wenigen Bytes sehr hoch aus. Durch geeignete Mechanismen 

zur Headerkompression, die in den RFC’s 2507 [DeNP99] und RFC 1144 [Jaco90] 

beschrieben werden, kann der Protokolloverhead vermindert werden. Dies setzt jedoch 

voraus, dass alle beteiligten Knoten diese Kompressionen unterstützen. 

Dies stellt auch einen Kritikpunkt an der Implementierung dar. Im Internet nutzen 

längst nicht alle Knoten TCP/IP-Headerkompression. Die beiden angeführten RFC’s 



sind auch nicht als Standard bewertet, sondern haben noch den Status ” Proposed 

Standard“ (Vorgeschlagener Standard). Wann und ob sie sich als Standard durchsetzen 

bleibt vorerst ungewiss. Somit ist eine direkte Kopplung der Sensorknoten, die den 

lwIP- oder uIP-Protokollstapel nutzen, an das Internet nicht gegeben. 

Ein nächstes Problem, das sich ergibt, ist die Vergabe der notwendigen IP-Adressen. 

Die in etablierten Netzwerken eingesetzten Protokolle ARP, RARP und DHCP zur 

automatischen Adressvergabe werden in Dunkels Arbeiten nicht unterstützt. So bliebe 

nur eine manuelle Adressvergabe. 

Dunkels bietet einen interessanten Ausweg an. Dieser wird als ” Spatial IP-Address 

Assignment“ (am ehesten mit ” IP-Adress-Vergabe auf Basis der Position“ zu über- 

setzen) bezeichnet ([DuAV04] und [DFGV04]). Dabei wählen sich die Knoten ihre 

IP-Adresse durch ihre gegenwärtige Position. In Abbildung 4.2 soll dies verdeutlicht 

werden. 

4 

3 

2 

1 

0 

B 10.0.1.3 

A 

10.0.0.1 

C 10.0.4.2 

0 1 2 3 4 

4 

3 

2 

1 

0 

A 

10.0.0.1 

B 10.0.3.4 

C 10.0.3.1 

0 1 2 3 4 

Abbildung 4.2: Spatial IP-Address Assignment [DuAV04] 

Verändert ein Knoten seine Position, soll er auch automatisch seine IP-Adresse än- 

dern. Dabei sollen die letzten beiden Tupel der IP-Adresse die Lage in einem virtuellen 

X-Y Koordinatensystem darstellen. Die einzelnen Knoten sollen ihre Position mittels 

geeigneter Technologien, wie dem Global Positioning System (GPS), ermitteln. 

Leider werden verschiedene Probleme, die sich durch dieses Modell ergeben, nicht nä- 

her erläutert. So bleibt unklar, wie die Änderung der IP-Adresse bei einer Bewegung ei- 

nes Knotens stattfindet. Vergleicht man dies mit einem Handover in Mobilfunk-Netzen 

müssen auch hier Ping-Pong-Effekte vermieden werden. 

Unklar bleibt auch, wie der Fall behandelt wird, dass sich zwei Knoten an einem 

gleichen Ort befinden bzw. sich dorthinbegeben wollen. Wer bekommt dann die IP- 

Adresse? 

Schließlich wird ein wichtiger Aspekt komplett vernachlässigt. Der beschriebene An- 

satz wird nur für eine Verteilung der Knoten auf einer Ebene beschrieben. Eine Be- 

trachtung der 3. Dimension wird nicht aufgezeigt. 



Wird ein Sensorknoten mit einer entsprechenden IP-Implementierung an ein IP- 

Netzwerk angekoppelt, muss er jedes eingehende IP-Paket untersuchen. Dazu wird der 

Header analysiert und die Adressangaben ausgewertet. Betreffen die Pakete diesen 

Knoten werden sie entsprechend weiterverarbeitet. Anderen Falls werden die Pakete 

verworfen. In einem größeren Netzwerk können so schnell einige 100 Pakete pro Sekun- 

de eintreffen. Der Knoten muss alle Pakete auswerten, was zu einer ständigen Belastung 

der Energieressourcen führt. Da Sensorknoten in drahtlosen Sensornetzwerken meist 

mit Batterien oder Akkumulatoren betrieben werden, sind die Energieressourcen da- 

durch begrenzt. Sensorknoten sollen aber mit einer Batterie bzw. Akkuladung mehrere 

Monate oder Jahre auskommen. 

Diese Umstände sprechen gegen eine Implementierung des IP-Protokolls in drahtlose 

Sensornetzwerke. 

4.1.2 Protokollumsetzer 

In vielen Arbeiten haben Forscher die Umsetzung von Protokollen zur Kopplung zwei- 

er Systeme untersucht. Zahlreiche Produkte für jeden Anwendungsfall sind auf dem 

Markt verfügbar. Im Allgemeinen werden im Sensornetzwerk ein oder mehrere Gate- 

ways installiert. Diese Gateways haben, wie in Abschnitt 2.5 schon beschrieben, die 

Aufgabe, die Daten und Kommandos des Sensornetzwerkes in ein anderes Protokoll 

umzuwandeln. Nachfolgend sollen zwei Ansätze aufgezeigt werden. 

4.1.2.1 OSGi-Alliance 

Die ehemals mit dem Namen Open Services Gateway Initiative auftretende OSGi- 

Alliance [OSGia], ist eine Kooperation verschiedener Firmen. Als Beispielmitglieder 

sollen hier nur die ” BMW Group“, ” Deutsche Telekom“, ” IBM“, ” Intel“ und ” Nokia“ 

genannt werden. Eine vollständige Auflistung kann unter [OSGib] eingesehen werden. 

Das Ziel der OSGi-Alliance ist, eine offene Service-Plattform für verschiedenste An- 

wendungen zu erschaffen. Dabei sollen alle gängigen Netzwerktechnologien unterstützt 

werden. Sowohl in der Heimautomation, im Fahrzeugbetrieb und im mobilen Umfeld 

kann OSGi eingesetzt werden. 

OSGi definiert ein Framework, welches durch entsprechende Implementierungen auf 

nahezu jeder Hardware eingesetzt werden kann. Als Entwicklungsumgebung wird der 

offene Industriestandard Java der Firma Sun eingesetzt [Sun]. Abbildung 4.3 stellt das 

Framework von OSGi dar. 

Vergleicht man diese Struktur mit dem ISO-OSI-Referenzmodell können Ähnlichkei- 



Logging 

Dienstübersicht 

OSGi Framework 

verwaltete 

Anwendungen 

und Dienste 

Eigenschaften 

Nutzeradministration 

OSGi-kompatible Java- 

Laufzeitumgebung (z.B. J2ME) 

Endgerät Betriebssystem 

(z.B. Windows Mobile, Embedded Linux) 

Endgerät Hardware / Netzzugang 

andere 

Dienste 

Abbildung 4.3: OSGi Framework Architektur für OSGi Anwendungen [OSGia] 

ten festgestellt werden. Für die Anwendungen im OSGi-Framework ist es unerheblich, 

mit welchen Netzwerktechnologien ihre Daten zu OSGi-Anwendungen in anderen Sys- 

temen transportiert werden. 

Ein weiterer Vorteil bei der Verwendung von OSGi ist die Erweiterbarkeit durch 

Modularität. Im OSGi-Framework sind die Anwendungen als Plugins realisiert. Damit 

kann man sich für die jeweilige Aufgabe das entsprechende Plugin heraussuchen und 

integrieren. Die Plugins lassen sich im laufenden Betrieb des Systems hinzuladen, ter- 

minieren und warten. Durch entsprechende Schnittstellen der OSGi-Implementation 

wird dies erreicht. Hinzu kommt, dass nicht nur Java-Anwendungen laufen können 2 , es 

ist auch möglich, native Anwendungen auszuführen. Damit können die Besonderheiten 

der eingesetzten Hardware beachtet werden. 

OSGi-Anwendungen, die in diesem Framework arbeiten, können über entsprechende 

Hardwareschnittstellen mit Anwendungen auf anderen OSGi-Geräten kommunizieren. 

Dabei fungiert ein OSGi-fähiges Gateway als Protokollumsetzer zwischen den verschie- 

2 Der Vorteil von Java ist die Universalität der Programme. Java ist eine plattformunabhängige 

Sprache. Für nahezu jede Hardwareplatform stehen Java-Implementierungen zur Verfügung. Java- 

Programme können ohne Neukompilierung auf jeder Java-Implementation laufen. 



denen Netzwerktechnologien (Abbildung 4.4). 

OSGi-Gateway 

OSGi-LAN OSGi-Telefonnetzwerk 

OSGi-Sensornetzwerk 

Abbildung 4.4: Kommunikation zwischen Endgeräten mit einem OSGi-Gateway 

Mit entsprechenden Komponenten ausgerüstet, könnte solch ein Gateway auch durch- 

aus über das Internet angesprochen werden. So bietet unter anderem die Firma ProSyst 

[GmbH], selbst ein Mitglied der OSGi-Alliance, eine Lösung an, das eigene Heim über 

das Internet fernzusteuern. Dabei können alle OSGi-fähigen Endgeräte des Hauses mit 

gängigen Protokollen wie HTTP, E-Mail oder per Short Message Service (SMS) mit 

einem Mobiltelefon angesprochen werden. 

Wie die Daten repräsentiert werden, bleibt dem Entwickler des OSGi-Plugins über- 

lassen. So könnte der Zustand eines Sensornetzwerkes graphisch dargestellt werden. 

Die Attribute der einzelnen Sensorknoten könnten angezeigt und, so weit dies Sinn 

macht, auch verändert werden. 

Für nahezu jeden Anwendungsfall gibt es auf den OSGi-Spezifikationen basierende 

Systeme. 

Während der Erarbeitung dieser Diplomarbeit, war nicht zu erkennen, ob es eine Im- 

plementierung des OSGi-Frameworks für Sensornetzwerke, die der ZigBee-Spezifikation 

folgen, geben wird. Gerade der Umstand, dass Knoten eines ZigBee-Netzwerkes nur 

über eingeschränkte Hardwarefunktionen verfügen, lässt den Autor diesen Schritt be- 

zweifeln. 

4.1.2.2 TinyOS und TinyDB 

In vielen experimentellen und in einigen kommerziell verfügbaren Sensornetzwerken 

wird als Betriebssystem ” TinyOS“ eingesetzt. Dieses OpenSource-System wurde an 


4.2 Nutzung eines Transparenten Proxyservers zur Kopplung 49 

der Universität Berkeley (UC Berkeley) entwickelt. TinyOS ist inzwischen für viele 

Plattformen erhältlich, unter anderem für ” Berkeley Motes“, ” Mica“, ” Mica2Dot“ und 

” Telos“. Eine Auflistung kann der Projekthomepage [UC Bb] entnommen werden. Laut 

Aussage der UC Berkeley wird TinyOS in mehr als 500 verschiedenen Projekten einge- 

setzt. Firmen wie Crossbow [Cros] haben TinyOS durch ausgereifte Produkte weltweit 

bekannt gemacht. Die Sensornetzwerke werden für vielfältige Aufgaben eingesetzt. Das 

in Abschnitt 3.2 angesprochene ” Great Duck Island“-Projekt wurde mit ” Berkeley Mo- 

tes“ und ” TinyOS“ realisiert. 

Um die Kommunikation mit den Knoten eines Netzwerkes, in dem TinyOS eingesetzt 

wird, zu vereinfachen, wurde TinyDB entwickelt [UC Ba]. Diese Erweiterung bildet die 

Sensordaten in einer Datenbank ab. Unter Zuhilfenahme von SQL-ähnlichen Komman- 

dos kann der Status des Sensornetzwerkes abgefragt werden. Einzelne Attribute eines 

jeden Sensorknotens oder eine Visualisierung des kompletten Netzwerkes sind damit 

darstellbar. Da TinyDB ebenfalls unter der OpenSource-Lizenz steht, ist eine eigene 

Anpassung möglich. Die Abbildungen 4.5 und 4.6 stellen eine Anfrage an ein Sen- 

sornetzwerk und die entsprechende Antwort dar. Dabei wurde die Antwort graphisch 

dargestellt. 

Abbildung 4.5: Anfrage an ein Sensornetzwerk mit TinyDB (Quelle: [UC Ba]) 

4.2 Nutzung eines Transparenten Proxyservers zur 

Kopplung 

Knoten in Sensornetzwerken verfügen meist nur über geringe Rechenkapazitäten. Pri- 

mär haben sie die Aufgabe, Daten über ihre Umgebung zu sammeln oder selbst auf 



Abbildung 4.6: Visualisierung von Sensordaten mit TinyDB (Quelle: [UC Ba]) 

Änderungen solcher Daten zu reagieren. Dafür reicht die verfügbare Rechenkapazität 

meist aus. 

Damit die Sensorknoten sinnvoll eingesetzt werden können, muss eine Kommuni- 

kation in ein externes Netzwerk oder direkt über eine Schnittstelle möglich sein, die 

vom Menschen erfassbar ist. Will man ein externes Netzwerk ansprechen, wird man 

die Nutzung der TCP/IP-Suite in Betracht ziehen. Diese habt sich als Quasi-Standard 

durchgesetzt. Das weltumspannenden Internet beruht auf diesen Protokollen. 

Betrachtet man die in diesem Kapitel vorgestellten beiden prinzipiellen Möglichkei- 

ten zur Kopplung von Sensornetzwerken an IP-basierte Kommunikationssysteme noch 

einmal genauer, lassen sich folgende Eigenschaften erschließen: 

Aufgrund der geringen Hardwarefunktionen ist eine TCP/IP-Implementierung nur 

bedingt möglich. Die in Abschnitt 4.1.1 vorgestellten Ansätze sind vielversprechend. 

Mit den geringen Datenmengen, die in der Heimautomation 3 anfallen, ergibt sich leider 

das Problem des Protokolloverheads, der durch die Nutzung von TCP/IP entsteht. Mit 

geeigneten Verfahren zur Headerkompression ist der Protokolloverhead zwar reduzier- 

bar, erfordert aber eine Veränderung der TCP/IP-Implementierung in allen beteiligten 

Instanzen. 

Die zweite Möglichkeit zur Kopplung ist die Nutzung eines Gateways, der eine 

Protokollumsetzung vornimmt. Dieser Ansatz ist die verbreitetste Lösung. Das Ga- 

teway wandelt entweder die Sensordaten und -kommandos in ein anderes Protokoll 

um oder nutzt zum Transport ein gängiges Protokoll der TCP/IP-Suite. Anschließend 

muss die Wandlung der Sensordaten im Empfänger vorgenommen werden. Im Beispiel 

3 Die Anwendung ” Videoüberwachung“ wird hierbei ausgenommen. Bei den dabei anfallenden Datenmengen 

wäre die Betrachtung des Protokolloverheads unerheblich. Vielmehr sollen einfache 

Anwendungen wie Licht- und Heizungssteuerung betrachtet werden. 



der OSGi-Alliance wird TCP/IP zum Transport der OSGi-Daten verwendet. TinyDB 

ermöglicht den Zugriff mittels SQL-ähnlicher Anfragen an eine Datenbank, die im Ga- 

teway das Sensornetzwerk repräsentiert. 

Eine Lösung, die beide Ansätze integriert, ist in dieser Form noch nicht öffentlich 

untersucht worden. Dieser Ansatz umfasst die Nutzung eines transparenten Proxys. 

Der Proxy funktioniert sowohl als Protokoll- als auch als Adressumsetzer. 

In die Kommunikation von IP- und Sensornetzwerk wird ein Proxy als Gateway 

eingeschleift. Das Gateway hat durch die Unterstützung des IP-Protokolls eine Verbin- 

dung in das IP-Netzwerk. Zusätzlich verfügt es über eine direkte Verbindung in das 

Sensornetzwerk. Diese könnte zum Beispiel mit einem Hardwaredongle auf USB-Basis 

realisiert werden. Für die Knoten im Sensornetzwerk würde das Gateway als normaler 

Sensorknoten erscheinen. Das Gateway kann durch entsprechende Mechanismen den 

Zustand der einzelnen Sensorknoten abfragen. Jedem Sensorknoten weist das Gate- 

way eine IP-Adresse zu. Diese IP-Adressen müssen der in Abschnitt 2.2.1 gestellten 

Anforderung der Eindeutigkeit genügen. Häufig wird man daher IP-Adressen aus dem 

privaten Adressbereich (siehe Abschnitt 2.4) wählen. 

Im IP-Netzwerk werden diese Knoten dann als IP-Knoten betrachtet. Aus Sicht der 

realen IP-Knoten sind die Sensorknoten nicht als solche zu erkennen. Das Gateway 

arbeitet als transparenter Proxy. 

Obwohl die Sensorknoten das IP-Protokoll nicht beherrschen, sind sie aus dem IP- 

Netzwerk ansprechbar. Soll eine Verbindung zu einer nicht existierenden IP-Adresse 

aufgebaut werden, die in den überwachten Adressbereich des Gateways fällt, wird 

dieses die Verbindung annehmen. Dabei scheint für den Initiator der Verbindung der 

real nicht existierende IP-Knoten zu antworten. Abbildung 4.7 zeigt die Idee dieses 

Ansatzes. 

Ein Verbindungsaufbau ist aber auch in umgekehrter Richtung möglich. Hat ein 

Sensorknoten ein wichtiges Ereignis registriert, sollte der Anwender darüber benach- 

richtigt werden. Dieses Ereignis könnte zum Beispiel die Meldung eines Alarmsensors 

sein. Das Gateway erkennt diese Meldung und wird versuchen, sofern es vorher kon- 

figuriert wurde, eine Verbindung zu dem Anwender aufzubauen. Dabei wird es als 

Absender nicht die eigene IP-Adresse verwenden, sondern die für den Sensorknoten 

vergebene IP-Adresse. Kann die Verbindung zustande gebracht werden, erscheint es 

dem Anwender so, als ob die Verbindung von dem betreffenden Sensorknoten initi- 

iert wurde. Wiederum ist für den Anwender nicht ersichtlich, dass ein Gateway in der 

Kommunikation involviert war. 



IP 

IP: 10.8.0.1 

a.) 

b.) 

Protokoll 

umsetzung 

IP ZigBee 

ZigBee 

NWK: 1xaa 

IP: 10.8.0.2 NWK: ax22 

Adress-Umsetzung: 

IP 10.8.0.10 ~ NWK 1xaa 

IP 10.8.0.11 ~ NWK 0x3c 

IP 10.8.0.12 ~ NWK ax22 

IP 

IP: 10.8.0.1 

IP: 10.8.0.2 

IP: 10.8.0.10 

IP: 10.8.0.12 

IP: 10.8.0.11 

NWK: 0x3c 

Abbildung 4.7: Einsatz eines transparenten Proxyservers 

a.) Der Proxyserver wird als Protokollumsetzer eingesetzt und adressiert 

gleichzeitig die Sensorknoten mit IP-Adressen. 

b.) Die Knoten des IP-Netzwerkes können nicht erkennen, dass die Sensorknoten 

keine echten IP-Knoten sind. 

4.2.1 Umsetzung eines transparenten Proxyservers mit Linux 

Um die Funktion eines transparenten Proxyservers anzubieten, muss man in der Lage 

sein, bereits auf Betriebssystemebene sowohl die IP-Adressen als auch die TCP/UDP- 

Ports ein- und ausgehender Pakete zu verändern. Unter dem frei erhältlichen Betriebs- 

system Linux [Org.] ist dies mit einfachen Mitteln möglich. Linux enthält seit der Ker- 

nelversion 2.4 den integrierten Paketfilter Netfilter [netf]. Dieser erlaubt es durch das 

festlegen von Regeln ein- und ausgehende IP-Pakete eines Computers zu manipulieren 

und umzuleiten. Da Netfilter nicht nur auf der Vermittlungsschicht ansetzt, sondern 

auch die Transportschicht umfasst, wird es häufig als Firewall auf solchen Computern 



eingesetzt. Mit Netfilter sind vielfältige Manipulationen möglich. So können ankom- 

mende Verbindungswünsche schon im Kernel blockiert werden, wenn deren Initiierung 

nicht von einem lokalen Prozess angefodert worden ist. Durch entsprechende Konfigu- 

ration kann man seinen Computer mit Netfilter sicher vor Angriffen aus dem Internet 

schützen. 

Für diese Diplomarbeit wurde Netfilter anderweitig verwendet. Die Zieladressen 4 

eingehender Verbindungen sowie die Quelladressen ausgehender Verbindungen werden 

verändert, um einen transparenten Proxy zu realisieren. 

Um zu verstehen wie Netfilter arbeitet, ist zunächst der Weg eines IP-Paketes 

im Linuxkernel aufzuzeigen. In Abbildung 4.8 ist die prinzipielle Paketbehandlung mit 

Netfilter dargestellt. Netfilter behandelt Pakete in drei so genannten Ketten 5 . In 

ankommende 

Pakete 

PREROUTING FORWARD 

POSTROUTING 

INPUT Lokaler Prozess 

OUTPUT 

Abbildung 4.8: Paketbehandlung mit Netfilter [netf] 

ausgehende 

Pakete 

jeder Kette können Regeln erstellt werden. Diese Regeln definieren, was mit einem 

Paket passieren soll. Sind in einer Kette mehrere Regeln definiert, werden diese Schritt 

für Schritt abgearbeitet. Stimmt eine Regel mit einem Paket überein, wird dieses ent- 

sprechend der Regel behandelt. Ansonsten wird das Paket mit der nächsten Regel 

verglichen. Stimmt die letzte Regel nicht überein, wird eine Standardaktion auf sie an- 

gewendet. Diese Standardaktionen können die Pakete entweder verwerfen oder gemäß 

ihrer Zieladresse weiterleiten. 

So könnte man zum Beispiel eine Regel erstellen, die alle ausgehenden Verbindungen 

über TCP-Port 80 zulässt, alle anderen Ports jedoch sperrt. Pakete, die zu TCP- 

Verbindungen gehören, die nicht über TCP-Port 80 abgehen, werden dann verworfen. 

4 Diese umschließen die Port-Nummern des verwendeten TCP-Protokolls mit ein. 

5 Im englischen Original werden diese Ketten als ” Chains“ bezeichnet. ” Kette“ bietet sich als beste 

Übersetzung an. 



Für den Anwender würde das bedeuten, dass er nur Webinhalte abrufen kann, jedoch 

keine E-Mails empfangen und senden kann 6 . 

Standardmäßig sind die drei Ketten INPUT, FORWARD und OUTPUT definiert. 

In der Kette INPUT existieren Regeln für Pakete, die an den eigenen Computer adres- 

siert sind. Regeln der FORWARD-Kette sind für Pakete definiert, die nicht an den 

eigenen Computer adressiert sind, sondern weitergeleitet werden sollen. Pakete, die 

vom eigenen Computer erstellt und/oder versendet werden sollen, werden mit Regeln 

in der OUTPUT-Kette verglichen. 

Die Einteilung, ob ein ankommendes Paket durch Regeln der INPUT- oder der 

OUTPUT-Kette behandelt wird, wird durch die Funktion PREROUTING bestimmt. 

Wie der Name suggeriert, wird hier eine erste Routing-Entscheidung getroffen. Ist das 

Paket an eine IP-Adresse gerichtet, die gleich der eigenen IP-Adresse ist, wird die- 

ses Paket mit Regeln der INPUT-Kette verglichen. Je nach Konfiguration kann hier 

das Paket an ein lokal arbeitendes Programm weitergeleitet oder verworfen werden. 

War das Paket nicht für den eigenen Computer bestimmt, wird es mit Regeln der 

Kette FORWARD behandelt. Im einfachsten Fall wird das Paket direkt an den Rou- 

tingalgorithmus POSTROUTING geleitet. Dieser wird das Paket entsprechend seiner 

Zieladresse ausliefern. 

Pakete, die von einem lokalen Prozess erstellt wurden und versendet werden sollen, 

durchlaufen zunächst die Regeln der OUTPUT-Kette. Hier werden sie entweder ver- 

worfen, verändert oder an die POSTROUTING-Funktion weitergegeben. Diese wird 

eine abschließende Routingentscheidung treffen. 

Hierbei ist anzumerken, dass der Netfilter durchaus mit mehreren Netzwerk- 

schnittstellen umgehen kann. Ankommende Pakete eines Netzwerkinterfaces können 

über ein anderes den Computer wieder verlassen. Auf Grund der Struktur des Net- 

filters ist ein wiederholter Durchlauf eines Paketes durch den Paketfilter möglich. 

Pakete, die z.B. in der OUTPUT-Kette landen, können durch die Veränderung ihrer 

Zieladresse in die Loop-Back-Adresse später wieder in der INPUT-Kette auftauchen. 

Netfilter realisert gleich mehrere Funktionen: Routing, Network Address Trans- 

lation (NAT) und die Blockierung von Paketen. Dabei werden nicht nur die Informa- 

tionen der Vermittlungsschicht benutzt bzw. manipuliert, sondern auch Informationen 

der Transportschicht verarbeitet. Ist eine Verbindung erst einmal aufgebaut, müssen 

Pakete, die zu dieser Verbindung gehören nicht erneut mit den Regeln abgeglichen 

6 Auf TCP-Port 80 wird ein Computer normalerweise Webanfragen eines Internetbrowsers behandeln. 

E-Mails werden mit den Protokollen POP/SMTP oder IMAP empfangen und gesendet. Diese 

Protokolle laufen auf von Port 80 verschiedenen Ports. Sind diese Ports gesperrt, können mit 

diesen Protokollen keine Verbindungen aufgebaut werden. 



werden. Netfilter wird automatisch die entsprechenden Manipulationen oder Rou- 

tingentscheidungen ausführen. 

Um neue Filterketten zu erstellen oder um Regeln zu ändern, haben die Netfil- 

ter-Entwickler das Programm iptables entwickelt. Mit diesem Kommandozeilenpro- 

gramm kann der Netfilter konfiguriert werden. 

4.2.2 Die Adressinformationen eingehender Verbindungen 

manipulieren 

Durch die Eingaben der zwei Kommandos in Abbildung 4.9 werden zwei Regeln für 

den Netfilter erstellt. 

iptables -A PREROUTING -p tcp -d 10.8.0.0/16 --dport 6000 -j DNAT \ 

--to-destination 192.168.0.180:8000 

iptables -A OUTPUT -p tcp -d 10.8.0.0/16 --dport -j DNAT \ 

--to-destination 192.168.0.180:8000 

Abbildung 4.9: Aufruf eines iptables-Kommandos 

Die erste Regel bezieht sich auf ankommende Verbindungen. Beginnen deren IP- 

Adressen mit 10.8 und wird das Protokoll TCP eingesetzt, dann wird die Zieladresse 

der Pakete in die Adresse 192.168.0.180 verändert. Der TCP-Zielport wird auf Port 

8000 geändert. Anschliessend durchlaufen die Pakete den in Abbildung 4.8 dargestell- 

ten Weg. Ist die Adresse 192.168.0.180 die eigene Adresse des Computers, würden die 

Pakete an die INPUT-Kette weitergeleitet und hier den Regeln entsprechend behan- 

delt. Wird dort die Verbindung gestattet, wird der Kernel versuchen die Verbindung 

am TCP-Port 8000 herzustellen. Lauscht ein lokaler Prozess auf diesem auf eingehende 

Verbindungen, kann dieser Prozess nun diese Pakete annehmen und die Verbindung 

aufbauen. Die zweite Regel bewirkt dieselbe Funktion für lokal generierte Pakete, deren 

Zieladresse mit 10.8 beginnt. 

Um einen transparenten Proxy zu realisieren, können solche Regeln verwendet wer- 

den. Der im nächsten Kapitel vorgestellte Prototyp vergibt für Sensorknoten Adres- 

sen aus dem Bereich 10.8.0.0/16. Will nun zum Beispiel ein Anwender eine TCP- 

Verbindung von extern oder lokal zu einem Knoten mit der Adresse 10.8.0.5 auf- 

bauen, wird der Netfilter die Pakete dieses Verbindungswunsches ändern. Dieses 

Verfahren heißt NAT und wurde in Abschnitt 2.4 bereits eingeführt. 



Der Prototyp lauscht am lokalen TCP-Port 8000, registriert den Verbindungswunsch 

und wird die Verbindung annehmen und aufbauen. Entsprechende Antwortpakete wer- 

den durch den Netfilter wiederum verändert, so dass der Anwender Pakete erhält, 

die als Absender die Adresse 10.8.0.5 ausweisen. Der Prototyp muss dem Initiator 

der Verbindung nun nur noch die Funktionen des Sensorknotens erbringen. 

Wenn man jedoch noch einmal die Problematik NAT in Abschnitt 2.4 betrachtet, 

wird man sehr leicht ein Problem für den Prototypen erkennen. Da der Netfilter die 

Zieladresse und den Zielport geändert hat, erscheint die Verbindung für den Prototypen 

so, als ob sie direkt an ihn gerichtet war. Die originale Zieladresse 10.8.0.5 kann der 

Prototyp mit herkömmlichen Mitteln nicht feststellen, da diese ja in den Paketen der 

Verbindung nirgends verzeichnet worden ist. Damit NAT ordnungsgemäß funktioniert, 

hat der Netfilter ebenso die Prüfsummen der Header der IP- und TCP-Pakete (Ab- 

schnitt 2.4) korrigiert. Für den Prototypen ist nicht ersichtlich, dass NAT angewendet 

wurde. 

Der Netfilter führt intern eine Tabelle, in der die einzelnen Adressänderungen 

verzeichnet sind, damit sie rückwärtig angewendet werden können. Der Vorteil, den 

die Netfilter-Implementierung bietet ist die, dass es lokalen Programmen ermöglicht 

wird, in diese Tabellen Einsicht zu nehmen. Der in dieser Arbeit implementierte Pro- 

totyp kann eine Anfrage an den Netfilter stellen, ob NAT für eine angenommene 

Verbindung durchgeführt wurde. Wenn dies bejaht werden kann, wird der Prototyp 

die originalen Adressinformationen erhalten. 

Jetzt muss der Prototyp ” nur“ noch eine Protokollumsetzung vornehmen und kann 

als Sensorknoten antworten. 

Die genaue Funktionsweise des Netfilters mit allen Einzelheiten zu erläutern wür- 

de den Rahmen dieser Arbeit sprengen. Es ist hier auf die Projekthomepage [netf] zu 

verweisen, wo stets die aktuellen Versionen zum Download bereit stehen. In [Zieg03] 

ist die Einrichtung einer Firewall mit Netfilter sowie dessen weitere Einsatzmöglich- 

keiten sehr ausführlich beschrieben. 

4.2.3 Die Adressinformationen ausgehender Verbindungen 

manipulieren 

Damit der Prototyp auch auf wichtige Ereignisse eines Sensorknotens reagieren kann 

und damit einen Anwender über ein solches Ereignis informieren kann, soll eine TCP- 

Verbindung zu diesem aufgebaut werden. Normalerweise wird bei einem Verbindungs- 

aufbau die IP-Adresse des Computers, auf dem das initiierende Programm läuft, als 



Quell-Adresse verwendet. 

Mit der Nutzung herkömmlicher Mittel kann man angeben, welchen TCP-Port das 

Programm als Quellport verwenden soll. Aber die Quell-IP-Adresse direkt zu ändern, 

ist nicht möglich. Der Anwender weiß aber im besten Fall ja nicht, dass ein Proxy die 

eigentliche Abbildung der Sensorknoten übernimmt. Er wäre überrascht, wenn plötz- 

lich eine Verbindung hergestellt werden soll, die eine für ihn unbekannte Quelladresse 

besitzt. 

Also muss die Quell-IP-Adresse verändert werden. Leider ist dies nicht so einfach 

durchzuführen, wie in der umgekehrten Reihenfolge. 

Zwar könnte man mit iptables Regeln erstellen, die zum Beispiel lokal initiierte 

Verbindungen von IP-Adresse 192.168.0.180, TCP-Port 7000 umschreiben auf die 

IP-Adresse 10.8.0.5, TCP-Port 7000. Damit wäre aber nur für diesen einen Fall aus- 

gesorgt. Hat der zu imitierende Sensorknoten eine andere IP-Adresse erhalten, müsste 

für diese ebenfalls eine entsprechende Regel definiert worden sein. Man kann im eigenen 

Programm iptables-Aufrufe realisieren, die die entsprechenden Regeln im laufenden 

Betrieb setzen (und löschen). Der Rechenaufwand wäre dafür aber sehr hoch. 

Bei wenigen Sensorknoten und den damit wenigen anfallenden Regeln stellt dies kein 

Problem dar. Denkt man aber an mehrere hundert Sensorknoten würden die Filterta- 

bellen sehr schnell sehr groß werden. Da die Pakete neu aufzubauender Verbindungen 

den kompletten Regelsatz durchlaufen müssen bis entweder eine Übereinstimmung ge- 

funden bzw. das Ende der Filterkette erreicht wird, wird dies bei vielen Regeln sehr 

viel Rechenzeit in Anspruch nehmen. 

Will eine Anwendung eine TCP- oder UDP-Verbindung aufbauen, wird sie einen 

Socket erstellen. Ein Socket ist eine Einheit aus IP-Adresse und Portnummer des Trans- 

portprotokolls. Das Betriebssystem verwaltet die Portnummern. Soll ein Socket erstellt 

werden, der schon belegt ist, d.h. die Portnummer ist schon anderweitig in Verwen- 

dung, kann dieser Socket nicht erstellt werden. Ist jedoch die gewünschte Portnummer 

frei, wird der Socket erstellt und exklusiv der Anwendung, die den Socket erstellt hat, 

zur Verfügung gestellt. Nun werden alle Pakete die an diesen Socket gerichtet sind, 

vom Betriebssystem an diese Anwendung weitergeleitet. 

Viele TCP/IP-Implementationen beinhalten die ” Bind“-Funktion. Mit dieser kann 

angegeben werden, welcher Port für eine ausgehende Verbindung benutzt werden soll. 

In der Linuxkernel-Version 2.2 war es möglich, neben der Portnummer auch die zu 

verwendende IP-Adresse anzugeben. Damit konnte eine Verbindung mit einer falschen 

Absender-IP-Adresse aufgebaut werden. Aus welchen Gründen auch immer, wurde 



diese Fähigkeit in den dem Kernel 2.2 folgenden Versionen 2.4 und 2.6 7 entfernt. Für 

Netfilter existiert jedoch ein Patch, der diese Funktionalität wieder ermöglicht. Unter 

[ScKo] kann die Dokumentation und der Patch namens ” TPROXY“ heruntergeladen 

werden. Da der Patch direkt in den Kernel hereinkompiliert werden muss, und auch 

Änderungen an iptables erforderlich sind, ist die Installierung dieses Patches mit ei- 

nigen Schwierigkeiten verbunden und sollte nur von geübten Anwendern vorgenommen 

werden. 

Hat man den Patch installiert, kann eine Verbindung mit einer fremden Absen- 

deradresse durchgeführt werden. Dazu verändert der TPROXY-Patch dynamisch die 

NAT-Tabelle des Netfilter, ohne dass dazu neue Regeln angelegt bzw. bestehende 

verändert werden. Dies wird immer nur einmal pro Verbindung durchgeführt. Weitere 

Pakete dieser Verbindung erfahren automatisch die selben Änderungen. Somit hält sich 

der Rechenaufwand sehr in Grenzen, auch bei einer größeren Anzahl von Verbindungen. 

An dieser Stelle soll darauf hingewiesen werden, dass der TPROXY-Patch zum Auf- 

bau einer TCP-Verbindung mit einer gefälschten IP-Adresse einen freien TCP-Port auf 

dem Rechner benötigt, auf dem die Verbindung initiiert wurde. Beim Verbindungsauf- 

bau müssen folgende Angaben getroffen werden: Die Ziel-IP-Adresse sowie der Ziel 

TCP-Port, die originale IP-Adresse des Systems, von dem die Verbindung aufgebaut 

werden soll sowie ein freier TCP-Port. Dieser Port wird benötigt, um zurückkommende 

Pakete dieser Verbindung zuzuordnen. Zusätzlich müssen die zu fälschende IP-Adresse 

und ein TCP-Port angegeben werden. Am Zielsystem erscheint die Verbindung vom 

Gerät mit den letzten beiden Adressangaben zu kommen. 

Wendet man die in Abschnitt 4.2.2 angebenen iptables-Kommandos an, muss man 

beachten, auch wirklich nur benötigte TCP-Ports umzuleiten. Wird auch der TCP- 

Port einer eingehenden Verbindung umgeleitet, der dem TCP-Port gleicht, den der 

TPXOY-Patch zum Verbindungsaufbau nutzt, werden die Pakete dieser Verbindung 

nicht mehr richtig zugestellt. Zwar versucht das System, eine Verbindung mit einer 

gefälschten Adresse aufzubauen, die rückläufigen Pakete können aber nicht mehr aus- 

geführt werden. Damit ist ein Verbindungsaufbau nicht möglich. 

7 Bei der Nummerierung der Kernel-Version wird eine Unterscheidung in stabile und instabile Versionen 

gemacht. Stabile Versionen werden durch eine gerade Nachkommazahl angegeben und können 

von allen Anwendern verwendet werden. Instabile werden nicht offiziell für alle Anwender empfohlen, 

sondern sollten nur von Entwicklern eingesetzt werden. 


5 Der Prototyp 

5.1 Architektur 

Die Kopplung eines Sensornetzwerkes auf Basis der ZigBee-Spezifikation an ein IP- 

basiertes Kommunikationssystem soll in dieser Diplomarbeit durchgeführt werden. Da- 

zu sollte ein Prototyp entwickelt und implementiert werden. Dieser Prototyp wurde 

auf Basis des in den Abschnitten 4.2 ff vorgestellten Ansatzes ” transparenter Proxy“ 

entwickelt. Da ein reales Sensornetzwerk nicht zur Verfügung stand, sollte dieses nur 

funktionell simuliert werden. 

Der Prototyp besteht aus drei Komponenten die in Abbildung 5.1 schematisch dar- 

gestellt sind. Eine Teilung in drei Bestandteile wurde bewusst vorgenommen. Durch 

Client 

Frontend 

Backend 

Proxyserver 

Client- 

Manager 

Client 

Connector 

Auth 

Manager 

Proxy 

Manager 

Proxy 

Connector 

Address 

Book 

Snw. 

Manager 

Snw. 

Connector 

Abbildung 5.1: Die Struktur des Prototyps 

Sensornetwork 

Simulator 

Frontend 

Backend 

eine räumliche Trennung können einzelne Komponenten des Prototyps leicht ausge- 

tauscht werden. Damit ist es einfach möglich, anstatt eines Sensornetzwerk-Simulators 

ein echtes Sensornetzwerk anzukoppeln. Hierzu muss lediglich die entsprechende Kom- 

ponente austauschen und kann die anderen beibehalten. Auf Grund der Kürze der 

59 


60 5 Der Prototyp 

Bearbeitungszeit wurde auf eine graphische Gestaltung des Frontends der Client- und 

Sensornetzwerk-Komponente verzichtet. Beide werden über ein Text-Menu auf Kom- 

mandozeilenebene bedient. Später können beide durch entsprechende graphische Pen- 

dants ersetzt werden. 

Die Schnittstelle zwischen den einzelnen Komponenten wurde in dieser Diplomarbeit 

definiert und ist erweiterbar. Dazu wurde ein eigenes Protokoll entwickelt. Im Anhang 

B.1 dieser Diplomarbeit sind die einzelnen Meldungen dieses Protokolls aufgezeigt. 

Die Programmierung der einzelnen Bestandteile wurde zum größten Teil mit der 

Entwicklungsumgebung Xcode 2.2 unter dem Betriebssystem Mac OS X auf einem 

Apple Mac vorgenommen [Appl]. Als Programmiersprache wurde C++ gewählt. Die 

Client- und Sensornetzwerk-Komponenten sind ohne Einschränkungen sowohl unter 

Mac OS X als auch unter Linux lauffähig. Unter Linux wurde die Entwicklungsumge- 

bung KDevelop genutzt [kdev]. 

Leider unterstützt bislang nur Linux die in Abschnitt 4.2.1 vorgestellte Umsetzung 

eines ” transparenten Proxys“. Weder mit dem Betriebssystem Mac OS X noch unter 

Microsoft Windows ist ein Eingriff in den Paketfilter in dem Umfang wie unter Linux 

möglich. Damit ist der Proxy mit allen Funktionen nur unter Linux lauffähig. 

Auch dieser Umstand sprach für eine Dreiteilung des Prototyps. Denn eine spätere 

Umsetzung der Client- und Sensornetzwerkkomponente für andere gängige Betriebs- 

systeme ist denkbar. 

Bevor die einzelnen Komponenten näher beschrieben werden, müssen zunächst einige 

Vorbetrachtungen getätigt werden. 

5.1.1 Vorbetrachtungen zum Prototypen 

5.1.1.1 ZigBee-Profil-Unterstützung 

Bevor mit der Programmierung begonnen wurde, musste zunächst ein Darstellungsmo- 

del für die Sensorknoten entwickelt werden. Jeder Sensorknoten verfügt über bestimmte 

Eigenschaften. Die Übertragungstechnologie ZigBee definiert so genannte ” Profile“, in 

denen die genauen Fähigkeiten eines Sensorknotens festgeschrieben sind (Siehe dazu 

Abschnitt 3.5.4). Da ZigBee eine relativ neue Technologie ist, sind bislang nur einige 

wenige Profile erhältlich. Für diese Diplomarbeit stand nur das Profil ” Home Control, 

Lighting 1.00“ zur Verfügung. Jedes Profil beschreibt in so genannten ” Device Descrip- 

tions“ mehrere Gerätearten. Jedes Gerät hat bestimmte Attribute und Funktionen, die 

durch entsprechende Bitfolgen repräsentiert werden. Einzelne Attribute eines Gerätes 


5.1 Architektur 61 

werden in Gruppen, so genannten ” Clustern“, angeordnet und in einer festgelegten No- 

tation übertragen. In den ” Device Descriptions“ sind die Bedeutungen der einzelnen 

Attribute und ihre Darstellung verzeichnet. 

Das Profil ” Home Control, Lighting“ beschreibt sechs verschiedene Geräte. Jedes 

Gerät kann Daten und Kommandos von anderen Geräten dieses Profils annehmen bzw. 

an andere Geräte weitergeben. In Tabelle 5.1 sind die einzelnen Gerätearten und ihre 

Beziehungen zueinander aufgeführt. Es stellte sich die Frage, ob die Beschreibungen der 

Gerätebezeichung 

(englisch) 

Switch Remote Control 

Switching Load Controller 

Occupancy Sensor 

Light Sensor Monochromatic 

Dimmer Remote Control 

Dimming Remote Controller 

Gerätebezeichung 

(deutsch) 

Schalter 

Schaltbare Last 

(z.B. Leuchte) 

Belegungssensor 

Lichtsensor 

Dimmer 

Dimmbare Last 

(z.B. Leuchte) 

Verbindung von / zu Gerät 

Ausgang: Switching Load Controller 

Eingang: Switch Remote Control 

Eingang: Light Sensor Monochromatic 

Eingang: Occupance Sensor 


Ausgang:Dimming Load Controller 


Ausgang: Dimming Load Controller 

Ausgang: Dimming Load Controller 

Eingang: DimmerRemote Control 

Eingang: Light Sensor Monochromatic 

Eingang: Occupance Sensor 

Tabelle 5.1: Die Gerätearten des ZigBee-Profils ” Home Control, Lighting“ 

Geräte dieses Profils direkt in den Code des Prototypen integriert werden sollten. Dies 

bedeutet, für jedes Gerät würde eine Klasse angelegt, deren Objekte die entsprechenden 

Eigenschaften des Gerätes repräsentieren. 

Aus Gründen der Erweiterbarkeit wurde jedoch ein anderer Weg gewählt. Hätte 

man das Profil in den Code integriert, wäre der Prototyp nur für Geräte aus dem 

Profil ” Home Control, Lighting“ anwendbar gewesen. Werden neue Profile durch die 

ZigBee-Alliance veröffentlicht, müsste der Code des Prototyps ergänzt werden. Um 

dies zu vermeiden, werden die Profilbeschreibungen aus einer externen Datei beim Pro- 

grammstart eingelesen. Für jede Gerätebeschreibung wird ein ” Master-Objekt“ erstellt. 

Soll ein Sensorknoten integriert werden, der einem bekannten Gerät eines bekannten 

Profils entspricht, wird eine Instanz des betreffenden ” Master-Objektes“ erstellt. Dieses 

repräsentiert dann diesen Sensorknoten. 



5.1.1.2 Adressierung im Prototyp 

Die Frage, wie man einen Sensorknoten am Besten adressieren sollte, ist eine Problem- 

stellung dieser Diplomarbeit. Aus den in Abschnitt 2.2.1 abgeleiteten Forderungen nach 

der Eindeutigkeit von IP-Adressen wurde schnell ersichtlich, dass eine Verwendung glo- 

baler IP-Adressen ausschied. Als Privatperson wird man kaum mehrere hunderte oder 

gar tausende öffentlich verwendbare IP-Adressen zur Verfügung gestellt bekommen. 

Wenn doch, dann wäre dies mit einem großen finanziellen Aufwand verbunden. 

Prinzipiell kann man in seinem eigenen abgeschlossenen Netzwerk Adressen beliebig 

vergeben. Jedoch sollte man sich an die Vorgaben der ICANN (bzw. der IANA) halten. 

In dieser Arbeit wurde der Einsatz von IP-Adressen aus dem privaten Bereich (Vgl. 

Abschnitt 2.4) gewählt. Der Bereich 10.0.0.0/8 bietet sich dafür an. 

Eine zweite Frage, die beim Einsatz von ZigBee als Sensornetzwerktechnologie auf- 

trat, ist die Adressierung einzelner Endpunkte. Die ZigBee-Spezifikation sieht vor, dass 

pro Sensorknoten bis zu 240 Endpunkte ansprechbar sind. Jedem Endpunkt wird ein 

bestimmtes Profil zugeordnet, dessen Funktion dieser Endpunkt dann erbringt. So ist 

ein Knoten denkbar, der auf Endpunkt 1 das Profil ” Home Control, Lighting; Switch 

Remote Control“ und auf Endpunkt 2 das Profil ” Home Control, Lighting; Switching 

Load Controller“ anbietet. 

Man hat mehrere Möglichkeiten, die Adressierung zu realisieren. Setzt man als Trans- 

portprotokoll TCP oder UDP ein, könnte man deren Port-Mechanismus zur Adressie- 

rung nutzen (Siehe Abschnitt 2.4). 

Jedem Sensorknoten wird eine IP-Adresse und jedem Endpunkt dieses Knotens ei- 

ne eigene Portnummer zugewiesen. Damit wäre mit der Angabe 10.8.0.1:5002 zum 

Beispiel der 2. Endpunkt des Knotens mit der IP-Adresse 10.8.0.1 ansprechbar. Der 

Proxyserver muss bei jedem Verbindungswunsch ermitteln, welcher Port angespro- 

chen wurde. Damit kann er den entsprechenden Endpunkt darstellen und die Funktion 

” Schalter“ oder Leuchte“ erbringen. 

” 

Dieser Ansatz hat jedoch einen Nachteil. Um diesen aufzuzeigen soll noch einmal 

die eigentliche Aufgabe der Ports betrachtet werden. Die Ports der Transportschicht 

werden genutzt, um die unterschiedlichsten Anwendungsprotokolle eines Netzknotens 

anzusprechen (siehe Abschnitt 2.3). TCP-Port 80 wird beispielsweise für den Abruf 

von Webseiten verwendet. Dazu wird das HTTP-Potokoll verwendet. Mit dem FTP- 

Protokoll können Daten mit anderen Anwendern über die Ports 20 und 21 mit aus- 

getausch werden. Sind diese Ports anderweitig verwendet, kann der Proxyserver nicht 

schon einfach schon beim Aufruf einer IP-Adresse das Protokoll ermitteln. 

Beispielsweise stellt die Adresse 10.8.0.1 einen Sensorknoten dar. Durch die Ein- 



gabe http://10.8.0.1 in einem Webbrowser wird eine Übersicht über dessen Funk- 

tionen angezeigt. Im Hintergrund setzt der Webbrowser eine solche Anfrage mit dem 

HTTP-Protokoll meist auf Port 80 um. 

Spricht man nun einen Endpunkt, der durch einen Port adressiert wird, mit dem 

Aufruf http://10.8.0.1:5002 im Webbrowser an, funktioniert dies nicht mehr. Der 

Webbrowser würde versuchen, eine HTTP-Verbindung auf Port 5002 herzustellen. 

Ordnet man aber mögliche Anwendungsprotokolle bestimmten Ports zu, kann die 

Zuordnung des Protokolls im Prototypen vereinfacht werden. Auf Port 80 wird zum 

Beispiel immer im HTTP-Protokoll kommuniziert, auf Port 6000 findet das in dieser 

Arbeit entwickelte Protokoll seinen Einsatz. 

Damit ist es möglich, später auch andere Formate zu unterstützen. Eine Unterstüt- 

zung von FTP, E-Mail oder sogar Instant Messaging ist vorstellbar. 

Aus Zeitgründen wurde in den Prototypen nur das eigene Protokoll eingebunden. 

Durch die Modularität der Programmierung ist eine Einbindung eines anderen Proto- 

kolls (z.B. E-Mail-Benachrichtigung bei Detektion eines Einbruches ins eigene Heim) 

möglich. 

In dieser Diplomarbeit wird für jeden (belegten) Endpunkt eines Sensorknotens eine 

eigene IP-Adresse vergeben. So kann es vorkommen, dass ein Knoten, auf dem alle End- 

punkte durch ein entsprechendes Profil belegt sind, über 240 IP-Adressen verfügt. Dem 

Anwender des Clients soll die wahre Natur des ZigBee-Knotens nicht aufgezeigt wer- 

den. Es erscheint nur logisch, wenn ein Schalter und eine Lampe mit unterschiedlichen 

IP-Adressen angesprochen werden, auch wenn diese in einem einzigen Hardwareobjekt 

integriert sind. 

Durch die Vergabe von privaten Adressen ist eine direkte Kopplung des Sensor- 

netzwerkes an das Internet nicht möglich. Zwar kann der Proxyserver (und damit die 

Sensorknoten) eine Verbindung an einen bekannten Kommunikationspartner im Inter- 

net aufbauen. Der umgekehrte Weg ist jedoch auf Grund des eingesetzten NAT (Siehe 

Abschnitt 2.4) nicht möglich. Will man Knoten direkt aus dem Internet ansprechen, 

müssen diese über eine globale Adresse verfügen. Der Einsatz von NAT versagt in die- 

sen Fall. Daher bietet sich der Einsatz eines Virtual Private Network Servers (VPN) 

an. Dieser Ansatz wird in Abschnitt 5.5 beschrieben. 

5.1.1.3 Nutzung von XML 

Zur Umsetzung der ZigBee-Profile bot sich die Verwendung der Extensible Markup 

Language (XML) an. XML ist eine textbasierte Beschreibungssprache, die vom World 

Wide Web Consortium (W3C) definiert wurde und deren Definition unter [W3C] ge- 



funden werden kann. In XML-verfasste Dokumente folgen einer Baumstruktur. Dabei 

repräsentiert jeder Ast eines solchen Baumes eine bestimmte Eigenschaft. Die Äste 

werden durch frei definierbare Beschreibungen (tags) gekennzeichnet. Für fast jede 

Programmiersprache gibt es geeignete Parser, die die Daten aus diesen Beschreibun- 

gen extrahieren können. Abbildung 5.2 zeigt den Auszug aus einer XML-Datei. 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Abbildung 5.2: Auszug aus einer XML-Datei 

Für den Prototypen wurde eine XML-Datei namens ” profiles.conf“ angelegt, die von 

der Proxyserver- und der Sensornetzwerkkomponente eingelesen wird. Jede Geräte- 

art wird aufgeführt und mit allen Attributen abgebildet. Zusätzlich werden ZigBee- 

Standardattribute sowie einige andere Eigenschaften, wie z.B. die IP- oder IEEE- 

Adresse vermerkt. 

Die genaue Beschreibung kann im Anhang nachgeschlagen werden. Es bleibt darauf 

hinzuweisen, dass diese Beschreibung nur die möglichen Attribute anführt. Selbstver- 

ständlich müssen diese auch mit reellen Werten gefüllt werden. Dies geschieht einerseits 

im Sensornetzwerk-Simulator bei der Konfiguration eines neuen Sensornetzwerkes. Spä- 

ter im Betrieb können einzelne Attribute, sofern eine Änderung sinnvoll erscheint, auch 

verändert werden. 

Die einzelnen Komponenten des Prototypen tauschen untereinander Nachrichten 

aus. Dafür wurde ein eigenes Protokoll entwickelt. Dieses nutzt als Format ebenfalls 

XML. Eine mögliche Meldung ist die in Abbildung 5.3 dargestellte Nachricht. 



 

 

 

 

 

5.1.1.4 XML-Verarbeitung 

Abbildung 5.3: Auszug aus einer XML-Datei 

Damit nicht an jeder Stelle, an der XML in den Programmen verwendet wird, eine 

erneute Parsingfunktion integriert werden muss, wurde eine eigene Klasse zum Le- 

sen und Schreiben von XML-Dateien oder Nachrichten erstellt. Objekte dieser Klasse 

namens ItemHandler bieten über die Methode readXML() die Möglichkeit, eine XML- 

Datei oder eine XML-Zeichenkette zu lesen. Um die Daten zu extrahieren, muss der 

Funktion ein einzelnes Item-Objekt und eine Liste von Objekten der Container-Klasse 

Item übergeben werden. In diese Liste werden für jedes XML-Objekt ein Item-Objekt 

erstellt, welches mit den extrahierten Daten der XML-Datei bzw. -Zeichenkette gefüllt 

wird. Jedes Objekt der Item-Klasse kann beliebig viele Einträge verschiedener Formate 

beinhalten. Zur Zeit werden die Formate ‘string’, ‘integer’, ‘bool’, ‘time_t’ (Datum) 

sowie ‘bitset’ und ‘bitset’ unterstützt. Durch einfache Erweiterungen sind 

andere Formate denkbar. Eine Darstellung dieser Abstraktion ist in Abbildung 5.4 ge- 

geben. Zum Schreiben von XML-Dateien oder -Nachrichten wurde eine zweite Methode 

namens writeXML() geschrieben. 

5.1.1.5 Authentifizierung im Prototypen 

Im Prototypen muss sich aus Gründen der Sicherheit jeder beteiligte Kommunikations- 

partner gegenüber dem anderen authentifizieren. Dabei wird die Angabe eines Anwen- 

dernamens und eines zugehörigen Passwortes verwendet. Will sich z.B. ein Client an 

einem Proxyserver 1 anmelden, fragt der Client zunächst den Anwendernamen und das 

Passwort vom Anwender ab. Soll die Verbindung zum Proxyserver hergestellt werden, 

wird dieser den Client um die entsprechenden Angaben bitten. Anschliessend sendet 

der Proxyserver seine eigenen Anmeldungsdaten an den Client. Dieser muss diese mit 

den für den angesprochenen Proxyserver gespeicherten Daten vergleichen. Erst wenn 

beide, Client und Proxyserver, den jeweils anderen authentifizieren konnten, wird die 

1 Aus Sicht des Clients meldet sich dieser nicht an einem Proxyserver, sondern direkt an einem 

Sensorknoten an. Die eigentliche Verbindung wird aber mit einem Proxyserver hergestellt. 



XML-Datei / 

XML-String 

Item: Header 

Item 

string ID 

ItemEntry 

+ 

Item-Liste 

Item 

string ID 

ItemEntry 

ItemHandler 

::readXML 

::writeXML 

Item: Header 

Item 

string ID 

ItemEntry 

+ 

Item-Liste 

Item 

string ID 

ItemEntry 

ItemHandler XML-Datei / 

XML-String 

::readXML 

::writeXML 

Abbildung 5.4: Die Abstrakte Datendarstellung. Der ItemHandler kann mit den Funktionen 

readXML und writeXML Objekte der Klasse Item aus einer XML- 

Datei oder einem -String lesen bzw. diese Objekte in eine XML-Datei 

oder einen -String schreiben. 

Verbindung zum Datentransfer freigegeben. Andernfalls wird die Verbindung geschlos- 

sen. Der Ablauf einer Authentifizierung ist in Abbildung 5.5 dargestellt. 

Dem Autor ist das Risiko, das diesem Modell folgt, durchaus bewusst. Da die Daten 

ohne Verschlüsselung im Klartext übertragen werden, ist ein Abhören der Authentifi- 

zierungsdaten ohne Schwierigkeiten möglich. Wird pro Proxyserver nur ein Authenti- 

fizierungsdatenpaar erstellt, ist es auch ohne Problem möglich, einem anderen Client 

diesen Proxyserver vorzuspielen. 

Aus Zeitgründen wurde dieses Modell gewählt. Natürlich ist eine Implementierung 

kryptographischer Verschlüsselungen der einzelnen Verbindungen sowie die Nutzung ei- 

nes hinreichend sicheren Authentifizierungsalgorithmus 2 empfohlen. Da diese Diplom- 

arbeit jedoch nicht vorrangig das Thema Sicherheit in Datennetzen behandelt, wurde 

2 Beispielsweise Data Encryption Standard (DSA) oder Advanced Encryption Standard (AES). 



Daten gültig? 

Nein 

Ja 

SocketClient SocketServer 

close 

ClientSendUserData 

Verbindungsaufbau 

ClientUserData(UserName,Password) 

AuthFailed 

ServerUserData(UserName,Password) 

AuthSuccess 

AuthFailed 

AuthSuccess 

close 

close 

.getOriginalDest() 

AddressBook-> 

.checkDeviceIP() 

IP nicht bekannt 

IP bekannt 

Daten gültig? 

Abbildung 5.5: Der Ablauf der Authentifizerung. Hinweis: die Begriffe SocketClient 

und SocketServer geben in dieser Darstellung an, wer den Verbindungswunsch 

initiiert hat. Der SocketClient ist nicht mit der in diesem Prototyp 

vorgestellten Programmkomponente Client gleichzusetzen. Ein 

SocketClient kann in diesem Falle auch ein Proxyserver sein, der sich 

gegenüber einem Sensornetzwerk authentifiziert. Der Aufbau der TCP- 

Verbindung wird vorausgesetzt und wird in dieser Abbildung nicht gezeigt. 

dieser Kompromiss gewählt. Es ist jedoch später möglich, die Authentifizierungskom- 

ponente entsprechend zu modifizieren und das gegenwärtige Modell auszutauschen. 

Der in Abschnitt 5.5 vorgeschlagene Ansatz eines VPN-Servers relativiert dieses 

Sicherheitsproblem. Dieser VPN-Server erlaubt eine gesicherte Verbindung über das 

Internet. Ein Abhören ist damit zumindest bei einer Verbindung über das Internet 

kaum möglich. 

Nein 

Ja 

t 



5.2 Der Proxyserver 

Als Hauptkomponente des Prototyps dieser Diplomarbeit wurde der größte Anteil der 

Entwicklungszeit in die Proxyserver-Komponente investiert. Aufgrund der Modularität 

können einige Bestandteile in den anderen Komponenten wiederverwendet werden, was 

den Programmierungsaufwand insgesamt vereinfacht. 

Der Proxyserver ist vom Anwender nur durch Konfigurationsdateien steuerbar, so 

dass auf ein Frontend verzichtet wurde. Als Programm, welches auf der Kommandozeile 

ausgeführt wird, zeigt es jedoch vielfältige Statusmeldungen an. Diese können an einen 

externen LoggingServer weitergegeben werden. 

Zum Programmstart werden die einzelnen Komponenten Listener, AddressBook, 

AuthManager, LoggingClient sowie drei Manager (Client, Proxyserver, SensorNet- 

work) gestartet. Alle Komponenten werden als eigener Thread 3 gestartet. Abbildung 

5.6 zeigt die Struktur des Proxyservers. 

5.2.1 AddressBook 

Das Addressbook bildet den Kern des Proxyserver. Es hält Informationen über jeden im 

Proxyserver bekannten Sensorknoten bereit. Wird der Proxyserver gestartet, liest das 

AddressBook zunächst die in Abschnitt 5.1.1.3 angesprochene Profildatei ein. Zusätz- 

lich wird eine weitere XML-Datei namens ” usergroups.conf“ eingelesen. Die erste wird 

verwendet, um dem Programm alle möglichen ZigBee-Gerätearten mitzuteilen. Da bei 

Erstellung dieser Datei durchaus Fehler auftreten können, versucht das AddressBook 

nicht nur, diese Datei zu interpretieren, sondern wird auch mögliche Fehler finden. 

Ein Fehler in der Gerätebeschreibung könnte im Programmablauf nicht vorhergesehe- 

ne Ereignisse hervorrufen. Daher wird das AddressBook bei Entdeckung eines Fehlers 

das komplette Programm sofort beenden. Dieser Schritt ist nötig, um eine korrekte 

Funktion des Prototyps zu gewährleisten. 

Bei der Anmeldung eines Sensornetzwerkes oder eines anderen Proxyservers werden 

diese aufgefordert, alle Daten über die verwalteten Endpunkte an das Proxyserver zu 

senden. Das AddressBook führt dazu eine Liste, in der alle Endpunkte aufgeführt sind. 

Für jeden Endpunkt werden einige wichtige Daten verzeichnet, wie die IP-Adresse und 

die IEEE-Addresse. 

3 Ein Thread ermöglicht in Multitasking-Systemen die gleichzeitige Ausführung mehrerer Aufgaben. 

So muss zum Beispiel ein Anwender nicht auf die Vollendung eines Druckauftrages warten, wenn 

dieser als eigener Thread gestartet wurde. Während der Drucker druckt, kann der Anwender andere 

Arbeiten mit dem Computer durchführen. Der Druckauftrag blockiert nicht das gesamte System. 


5.2 Der Proxyserver 69 

Client 

Proxy 

SNW 

Loggin 

Server 

Proxyserver 

Listener 

Listener 

Listener 

Logging 

Client 

ClientManager 

.spreadMessage() 

Connector 

.processMessage() 

Liste 

IP-Adressen 

AuthManager 

.new() 

Authenticator 

AddressBook 

.checkDeviceIP() 

.addAndCheckDevice() 

Profile 

IP-Address 

IEEE-Address 

ID 

Device 

IP-Address 

IEEE-Address 

ID 

Attribut Attribut 

.registerAuthSocket() 



new new new 

AuthSocket 

AuthSocket 

Authentifiziert 

ProxyManager 


Connector 


Liste 

IP-Adressen 

AuthSocket 

SensorNW.-Manager 


Connector 


Liste 

IP-Adressen 

AuthSocket 

Client Proxy SNW 

Abbildung 5.6: Die Struktur des Proxyservers. Man erkennt die einzelnen Threads Listener, 

LoggingClient, AuthManager, AddressBook und die drei Manager 

(Client, Proxyserver und Sensornetwork) 

Es muss sichergestellt werden, dass jeder Endpunkt eine eindeutige IP-Adresse ver- 

wendet. Daher überprüft das AddressBook die übermittelte IP-Adresse für jeden neu 

hinzuzufügenden Endpunkt. Wird diese schon im System verwendet, wird das 

AddressBook eine entsprechende Fehlermeldung an den entsprechenden Kommunika- 

tionspartner senden und diesen Endpunkt ignorieren. 

Auf Grund der Komplexität wurde kein System entwickelt, das eine automatische 

IP-Adressvergabe wie etwa DHCP oder ARP ermöglicht. 

Es wurde zwar ein Algorithmus entwickelt, der eine freie IP-Adresse aus einem vorge- 

gebenen Bereich ermitteln kann, allerdings stellte sich heraus, dass dieser Algorithmus 



bei einer großen Anzahl an vergebenen IP-Adressen sehr langsam wird. 

Bei einer manuellen 4 Konfiguration eines neuen Knotens kann es akzeptiert werden, 

wenn eine freie Adresse erst nach kurzer Zeit (


4.2.1). 

Konnte dies erfolgreich durchgeführt werden, wird eine Anfrage an das AddressBook 

gestellt, ob diese IP-Adresse im System bekannt ist. Ist dies nicht der Fall, wird 

der Socket geschlossen. Kann die Anfrage bejaht werden, wird ein Objekt des Typs 

Authenticator erstellt und diesem der Socket und die original Adressdaten übergeben. 

Dieser Authenticator führt die in Abschnitt 5.1.1.5 beschriebene Authentifizierung 

durch. 

Der AuthManager führt eine Liste, in der die Authenticatoren vermerkt werden. 

Diese Objekte werden durch einen eigenen Thread realisiert. 

Dadurch kann der AuthManager im Hintergrund weiter auf andere Verbindungswün- 

sche warten. 

Jeder Authenticator hat eine Lebenszeit von wenigen Sekunden. Kann in dieser Zeit 

die Authentifizierung nicht erfolgreich beendet werden, wird die Verbindung abgebaut 

und der Authenticator terminiert. 

Zusätzlich wurde die Anzahl an gleichzeitig lebendigen Authenticatoren auf 25 

festgelegt. 

Mit diesen zwei Mechanismen wird verhindert, dass das Gesamtsystem durch einen 

bösartigen Angriff stillgelegt wird. Jede offene TCP-Verbindung benötigt Ressourcen 

des Betriebssystems. Antwortet der Initiator einer Verbindung nicht auf die Komman- 

dos des Authenticators kann davon ausgegangen werden, dass der Initiator entweder 

in böser Absicht handelt oder selbst abgestorben ist. Damit die Verbindung nicht für 

unbestimmte Zeit offengehalten wird, wird sie nach der maximalen Lebensspanne des 

Authenticators terminiert. 

Mit der Limitierung auf 25 gleichzeitig lebendigen Authenticatoren können be- 

stimmte Angriffe abgewehrt werden. So ist es denkbar, dass jemand ständig in sehr 

kurzen Zeitabständen versucht, eine Verbindung zum Proxyserver aufzubauen. Zwar 

können solche Angriffe nicht verhindert werden, aber zumindest wird der Proxyserver 

dadurch nicht ausgebremst. 

Konnte eine Authentifizierung erfolgreich durchgeführt werden, wird ein neues Ob- 

jekt der Klasse AuthenticatedSocket erstellt. Diesem wird der SocketServer überge- 

ben. Anhand des original TCP-Ports wird entschieden, ob es sich bei dem Kommunika- 

tionspartner um einen Client, ein Sensornetzwerk oder um einen anderen Proxyserver 

handelt 6 . 

Aufgrund dieser Angabe wird der AuthenticatedSocket an den betreffenden Ma- 

6 Natürlich kann man diese Entscheidung auch durch eine zusätzliche Angabe im Authentifizierungsprozess 

realisieren. Aus Gründen der Einfachheit wurde hier aber dieser Weg gewählt. 



nager weitergegeben. Dazu wird dessen Methode .registerAuthenticatedSocket() 

aufgerufen. Wie dieser mit dem AuthenticatedSocket verfährt, wird im folgenden 

Abschnitt beschrieben. 

Damit der Proxyserver auch eine eigene Verbindung zu anderen Partnern aufbauen 

kann, wurde im Authmanager eine weitere Methode realisiert. Dieser Methode wird 

die Zieladresse und die ID des aufrufenden Connectors übergeben. Optional kann eine 

” falsche“ Absenderadresse angegeben werden. Diese wird benötigt, damit der Proxyserver 

einen Client als Leuchte 3“ mit der IP-Adresse 10.8.5.6 ansprechen kann. 

” 

Der Authentifizerungsprozess wird in der oben geschilderten Weise durchlaufen, je- 

doch mit dem Unterschied, dass der Proxyserver jetzt als ” SocketClient“ fungiert. Im 

Authentifizierungsprozess wird stets die Serverseite als erste beginnen, Daten zu sen- 

den. 

5.2.3 Die Manager und Connectoren 

Zu jedem Proxyserver können sich sowohl Clients, Sensornetzwerke als auch andere 

Proxyservers verbinden. Der Proxyserver verfügt über drei entsprechende Manager. 

Diese verwalten je eine Liste mit Connectoren. 

Nachdem eine neue Verbindung durch den AuthManager authentifiziert wurde, wird 

dem betreffenden Manager der AuthenticatedSocket übergeben. Wurde im Authen- 

tifizierungsprozess zusätzlich die ID des Kommunikationspartners mitgeteilt, ist diese 

im AuthenticatedSocket verzeichnet. Anhand dieser ID kann der Manager ermitteln, 

ob in seiner Connector-Liste schon ein Connector existiert dessen ID der mitgeteilten 

ID entspricht. Wenn eine Übereinstimmung gefunden werden kann, wird dem betref- 

fendem Connector der AuthenticatedSocket übergeben. 

Gibt es keinen Connector mit einer solchen ID oder wurde keine ID mitgeteilt, wird 

ein neuer Connector erstellt. 

Je nach Typ des Kommunikationspartners werden unterschiedliche Startaktionen 

ausgeführt. Einem Client wird zunächst eine Information geschickt, um welche Art 

von Sensorknoten es sich bei der angesprochenen IP-Adresse handelt. Kommunikati- 

onspartner vom Typ ” Proxyserver“ oder ” Sensornetzwerk“ werden aufgefordert, alle 

ihre Sensordaten zu übersenden. 

Jeder Connector hat eine Liste für ein- und ausgehende Nachrichten. Werden Nach- 

richten mit dem AuthenticatedSocket empfangen, werden sie zur Auswertung an die 

Liste eingehender Nachrichten angehängt. Der Connector muss diese Nachricht dann 

auswerten. 



Es treten zwei mögliche Ereignisarten auf: Die Nachricht könnte einerseits nur für den 

Connector bestimmt sein. Ein Client könnte zum Beispiel ein ” LogOutAndCallBack“ 

senden. Dieses Kommando veranlasst den Connector die Verbindung mit dem Client 

zu trennen. Der Connector selbst bleibt aber noch eine gewisse Zeit aktiv. Findet in 

dieser Zeit ein Ereignis statt, über welches der Client informiert werden sollte, kann 

der Connector versuchen, über den AuthManager den Client zu erreichen. 

Die zweite Ereignisart betrifft mehrere Connectoren. So könnte ein Connector, der 

ein Sensornetzwerk anbindet, eine Nachricht über die Statusänderung eines Knotens 

erhalten. Diese Meldung kann für mehrere Clients oder andere Proxyserver interessant 

sein. Deshalb werden solche Nachrichten verteilt. 

5.2.4 Der Weg einer Nachricht im Proxyserver 

Die Abbildung 5.7 zeigt den Weg eingehender Nachrichten im Proxyserver. 

SNW 

SensorNetworkManager 


Connector 

.registerIncomingMessage(string) 

AuthenticatedSocket 

.send() 

.recv() 

SocketServer 

SocketClient 

FIFO 

new 

Message 

.registerXML() 

.processMessage(Message) 

Abbildung 5.7: Der Weg einer eingehenden Nachricht 

Sendet ein Client, ein Sensornetzwerk oder ein anderer Proxyserver an diesen Proxy- 

server eine Nachricht, wird diese im jeweiligen Connector von dessen Authenticated- 

Socket entgegengenommen. Dieser registriert die Nachricht im Connector in einer War- 

teschlange. Diese beruht auf dem ” First In - First Out“-Prinzip. Bis zu dieser Stelle 

ist die Nachricht noch eine XML-Zeichenkette. Es wird ein neues Objekt vom Typ 

Message erstellt. Konnte dieses die XML-Zeichenkette erfolgreich parsen, wird das Ob- 

jekt an die Methode processMessage() weitergegeben. Diese interpretiert den Inhalt 

und wird entsprechende Reaktionen erzeugen. Der Weg einer ausgehenden Nachricht 

ist in Abbildung 5.8 dargestellt. 



Client 

ClientManager 


Connector 

.registerIncomingMessage(string) 

AuthenticatedSocket 

.send() 

.recv() 

SocketServer 

SocketClient 

.registerOutgoingMessage(Message) 




Liste der IP-Adressen 

von Interesse 

Prüfe auf Treffer 

Message 

.getContent() 

FIFO 

.spreadMessage(Message) 

Abbildung 5.8: Der Weg einer ausgehenden Nachricht 

Jeder Manager stellt die Methoden spreadMessageToOtherManagers() und 

spreadMessage() bereit. Mit diesen können Nachrichten intern an alle Connectoren 

dieses und der anderen Manager gesendet werden. 

Alle Connectoren besitzen eine Liste für zu überprüfende Nachrichten. In diese wer- 

den Nachrichten vom Manager angehängt. Die Connectoren vergleichen den Inhalt der 

Nachrichten mit ihrer Liste der ZigBee-Endpunkte von Interesse. Betrifft eine Nachricht 

einen solchen Connectors, wird die Nachricht in eine XML-Zeichenkette umgewandelt. 

Anschließend wird diese Zeichenkette mit der send-Methode des AuthenticatedSockets 

verschickt. War die Nachricht für den Connector nicht von Interesse, wird sie einfach 

verworfen. 

5.2.5 Aufbau von Proxyserver-Proxyserver-Verbindungen 

Jeder Proxyserver kann Verbindungen zu anderen Proxyservern aufbauen. 

Dazu liest der Proxyserver-Manager beim Start des Programms eine Konfigurati- 

onsdatei ein. In dieser können die Adressinformationen anderer Proxyservers verzeich- 

net sein. Konnten diese erfolgreich gelesen werden, wird ein eigener Proxyserver- 

Connector erstellt. Dieser wird gestartet und versucht, eine Verbindung zum angege- 

benen Proxyserver aufzubauen. Dieser Verbindungsaufbau wird periodisch wiederholt, 

bis eine Verbindung erfolgreich (inklusive Authentifizierung) aufgebaut werden konnte. 



Dann tauschen beide Proxyserver die Daten ihrer angeschlossenen Sensornetzwerke 

aus. Diese Daten werden in den jeweiligen AddressBook-Objekten vermerkt. Ansch- 

liessend können sich Clients auch zu ZigBee-Endgeräten verbinden, die nicht direkt 

in dem zwischengeschalteten Proxyserver registriert sind. Entsprechende Nachrichten 

werden zwischen den Proxyservern weitergeleitet. 

5.2.6 Annahme von Client-Verbindungen im Proxyserver 

Jedes ZigBee-Endpunkt besitzt eine eigene IP-Adresse, die im Prototypen aus dem 

Bereich 10.8.0.0 vergeben wird. Die Endpunkte stellen im Prototyp einzelne ZigBee- 

Geräte wie Schalter, Leuchten oder Dimmer dar. Will ein Anwender Anfragen an ein 

solches Gerät stellen, kann der entwickelte Client verwendet werden. Dieser versucht, 

eine Verbindung zur IP-Adresse des gewünschten Gerätes aufzubauen. Dabei ist dem 

Client nicht ersichtlich, dass die Gegenstelle ein Proxyserver ist. 

Der Computer, auf dem der Proxyserver läuft, muss unter dem Betriebssystem Linux 

betrieben werden. Zusätzlich müssen die in den Abschnitten 4.2.1 und 4.2.2 vorgestell- 

ten Einstellungen vorgenommen werden. Dazu müssen die iptables-Befehle mit der 

Umleitung der betreffenden IP-Bereiche ausgeführt werden. 

Will sich nun ein Client zu einer IP-Adresse aus dem 10.8.0.0-Bereich verbin- 

den 7 , modifiziert der netfilter diese Pakete und ersetzt die Zieladresse durch die des 

Proxyservers. Der TCP-Port wird ebenfalls verändert. Die Verbindung wird an die neue 

Adresse umgeleitet, in diesem Fall an den ClientListener-Port des Proxyservers. Hier 

lauscht der Proxyserver auf eingehende Verbindungen und nimmt diese entgegen. Die 

Modifikation der IP-Adresse ist an sich nichts besonderes, jedoch ist die Möglichkeit, 

dass Programme die NAT-Tabelle auslesen können, ein Vorteil von Linux. 

Der Proxyserver wird nun versuchen, die originale Zieladresse herauszufinden. Ist dies 

erfolgt, wird der Proxyserver diese mit seinem AddressBook abgleichen. Ist die ange- 

rufene IP-Adresse im System verzeichnet, wird die Authentifizierung nach Abschnitt 

5.1.1.5 durchgeführt. Der Client kann nicht erkennen, dass er mit dem Proxyserver 

verbunden ist. Für ihn scheint es, als ob er wirklich mit dem aufgerufenen Gerät ver- 

bunden ist. Betrachtet man die IP-Pakete und TCP-Datagramme, ist eine Modifikation 

nicht ersichtlich. 

Nach erfolgreicher Authentifizierung sendet der Proxyserver dem Client alle Infor- 

mationen, die über den aufgerufenen ZigBee-Endpunkt verfügbar sind. Dabei sendet 

der Proxyserver nur Informationen, für die der Client freigeschaltet wurde. Diese “Frei- 

7 Als Transportprotokoll wird im Prototypen TCP verwendet. 



schaltung“ erfolgt mit der Anwendergruppe die im Authmanager des Proxyservers für 

jeden Anwender angegeben ist. 

Hat der Client alle Attribute des ZigBee-Gerätes erhalten, wird dem Anwender dies 

angezeigt. Der Anwender kann sich nun diese Attribute anzeigen lassen. Manche Attri- 

bute eines ZigBee-Gerätes lassen sich auch verändern. Dies könnte beispielsweise die 

Funktion “An/Aus“ eines Schalters sein. Sind solche Attribute vorhanden, kann der 

Anwender eine Veränderung vornehmen. Erfolgt diese, wird eine betreffende Nachricht 

an das ZigBee-Gerät, also in Wahrheit den Proxyserver, versendet. 

Dieser leitet die Nachricht intern an alle Connectoren weiter. Dort wird die Nach- 

richt ausgewertet. Ist ein Connector betroffen, wird dieser die Nachricht an seine Kom- 

munikationspartner weiterleiten. Dieser ist entweder der betreffende Sensornetzwerk- 

Simulator, zu dem die Nachricht geleitet werden sollte, oder ein weiterer Proxyserver. 

Im ersten Fall wird der Sensornetzwerk-Simulator die Nachricht verarbeiten. Dabei 

wird das verändernde Attribut ausgelesen und mit den Sensorknoten abgeglichen. Ist 

eine Änderung berechtigt, wird diese ausgeführt und eine neue Nachricht über die 

Änderung zurückgesendet. Diese Antwort durchläuft dieselben Mechanismen und wird 

zwangsläufig auch beim Client ankommen. Dort wird sie dem Anwender angezeigt. 

Im zweiten Fall ist der Connector einem weiteren Proxyserver zugeordnet, der zum 

Beispiel über das Internet mit diesem Proxyserver verbunden ist. Ist an dem zweiten 

Proxyserver ein Sensornetzwerk-Simulator angekoppelt, wird der zweite Proxyserver 

bei Übereinstimmung die Nachricht an dieses weiterleiten. Werden von diesem Ant- 

worten generiert, werden diese an denursprünglichen Proxyserver weitergeleitet, der 

den enstprechenden Client informiert. Somit sind vielfältige Netztopologien möglich, 

die in Abschnitt 5.6 noch besprochen werden. 

5.2.7 Aufbau von Client-Verbindungen durch den Proxyserver 

Wurde das Linux-Hostsystem, auf dem der Proxyserver ausgeführt wird, mit dem in 

Abschnitt 4.2.3 vorgestellten ” TPROXY“-Patch modifiziert, ist ein Verbindungsaufbau 

mit einer falschen IP-Adresse aus einem eigenen Programm möglich. Der Prototyp 

nutzt die Funktionalität, die dieser Patch bietet. Hat sich ein Anwender mit einem Cli- 

ent an einem Proxyserver angemeldet, verzeichnet dieser die angerufenen IP-Adresse 

sowie die Quell-Adresse. Der Anwender kann nun mit dem ZigBee-Endgerät intera- 

gieren, welches hinter der angerufenen IP-Adresse steckt (Siehe Abschnitt 5.2.6). Vor 

dem Abbauen einer Verbindung durch den Anwender kann dieser angeben, ob er über 

Änderungen, die in Abwesenheit am Endgerät auftreten, informiert werden soll. Der 


5.3 Der Sensornetzwerk-Simulator 77 

entsprechende Connector im Proxyserver vermerkt dies und wartet auf Nachrichten des 

ZigBee-Endgerätes. Trifft eine solche ein, wird der Connector über den Authmanager 

einen Verbindungsaufbau starten. 

Dabei wird als Quell-Adresse die Adresse des betroffenen ZigBee-Endgerätes ver- 

wendet. Die Zieladresse ist die Adresse des Clients, die zuvor verzeichnet wurde. Kann 

eine Verbindung aufgebaut werden, wird erneut eine Authentifizierung durchgeführt. 

Ist diese erfolgreich wird der Client über die Attributänderung des ZigBee-Knotens 

informiert. Der Anwender am Client kann nun erneut mit dem ZigBee-Endgerät inter- 

agieren. 

Festzuhalten ist, dass für den Client eine Verbindung von einem Netzknoten mit 

einer Adresse aus dem Bereich 10.8.0.0 aufgebaut wurde. Für den Client ist nicht 

ersichtlich, dass in Wahrheit der Proxyserver die Verbindung initiiert hat. 

5.3 Der Sensornetzwerk-Simulator 

In Abbildung 5.9 ist der Aufbau des Sensornetzwerk-Simulators dargestellt. Er besteht 

aus einem Front- und einem Backend. Viele Teile der Proxyserver-Komponente konnten 

wiederverwendet werden. Die Authentifizierung wird wie beim Proxyserver von so ge- 

nannten Authenticator-Objekten durchgeführt. Die Funktionalität des AuthManagers 

wird durch den Configurator erbracht. Für das Einlesen und Schreiben von XML- 

Konfigurationsdateien und das Erstellen von Nachrichten wurden ebenso die entspre- 

chenden Klassen der Proxyserver-Komponente integriert. 

5.3.1 Configurator 

Wie im Proxyserver liest der Configurator zunächst einige Konfigurationsdateien ein. 

Zuerst wird die Profildatei mit den Beschreibungen der möglichen ZigBee-Gerätearten 

interpretiert. Zusätzlich wird eine Datei mit den Angaben der Binding-Möglichkeiten 

der ZigBee-Gerätearten eingelesen. Diese beinhaltet die Aussagen, die in Tabelle 5.1 

angegeben sind. Konnten beide Dateien erfolgreich eingelesen werden, wird ein Text- 

Menu angezeigt. Mit diesem kann der Anwender auswählen ob ein Sensornetzwerk neu 

erstellt oder die Konfiguration eines bereits erstellten Netzwerkes eingelesen werden 

soll. 



SensorNetzwerk-Simulator 

Configurator 

.createNewSNW() 

.createDevice() 

.registerOutgoingSocket() 

Authenticator 

Backend 

Frontend 

Profile 

IP-Address 

IEEE-Address 

ID 

Attribut 

IO-Manager 

SensorNetwork 


.updateDeviceAndSpread() 

.checkUpdateBounded() 

Device 

IP-Address 

IEEE-Address 

ID 

Attribut 

.alterDeviceAttribute() 

AuthSocket 

Abbildung 5.9: Die Struktur des Sensornetzwerk-Simulators 

5.3.1.1 Erstellung eines neuen Netzwerkes 

Proxy 

Soll ein neues Sensornetzwerk erstellt werden, muss zunächst der Name des neuen Sen- 

sornetzwerkes eingegeben werden. Vom Configurator werden zusätzlich die Address- 

Informationen jenes Proxyservers kopiert, zu dem sich das Sensornetzwerk später ver- 

binden soll. Diese Angaben können später in der Konfigurationsdatei leicht verändert 

werden. 

Anschliessend können die einzelnen ZigBee-Endgeräte erstellt werden. Als erstes 

Endgerät werden Eigenschaften des PAN-Koordinators abgefragt. Abbildung 5.10 zeigt 

die Auswahl des Geräte-Typs des PAN-Koordinators. Nachdem der Typ festgelegt 

wurde, können nun nacheinander alle Attribute festgelegt werden. Die Angabe, wel- 

ches Gerät über welche Attribute verfügt, wurde beim Start des Programmes durch 

das Einlesen der Profil-Datei festgelegt. Manche Attribute erfordern die Eingabe einer 

Zeichenkette (z.B. Name des Endgerätes) oder eines Zahlenwertes (z.B. Lichtstärke in 

Lux). Einige Attribute bieten die Auswahl aus vordefinierten Zuständen an. In Abbil- 

dung 5.11 wurde als Geräte-Typ ein ” Switch Remote Control“ gewählt. Dieser Typ hat 

ein Attribut ” OnOffSRC“, welches den Zustand ” On“, ” Off“ oder ” Toggle Output“ anneh- 

men. Nun kann der Anwender angeben, welchen Wert dieses Attribut haben soll. Nach 



--- PAN Knoten Profile auswaehlen --- 

1: Switch Remote Control 

2: Switching Load Controller 

3: Occupancy Sensor 

4: Light Sensor Monochromatic 

5: Dimmer Remote Control 

6: Dimming Load Controller 

0: Zurueck 

-------------------------------- 

Abbildung 5.10: Programmausgabe: Auswahl des Typs eines ZigBee-Endgerätes 

--- PAN Knoten bearbeiten --- 

OnOffSRC: 

ON or OFF commands for Switch Remote Control 

0: On: ON Command for Switch Remote Control 

1: Off: OFF Command for Switch Remote Control 

2: Toggle Output: Used for 3 Way Switches 

Abbildung 5.11: Programmausgabe: Änderung eines Attributes bei der Konfiguration 

und nach werden alle Attribute abgefragt. Ein wichtiges ist dabei die IP-Addresse, die 

dieses Endgerät verwenden soll. In der Konfigurationsdatei wird zur Ermittlung einer 

freien IP-Adresse der verwendete Bereich angegeben. Mit Hilfe dieser Informationen 

ermittelt der Configurator eine freie Adresse und markiert die vergebene als belegt. 

Wird ein weiteres Endgerät hinzugefügt, wird eine andere Adresse vergeben. Sind alle 

Angaben eines Endgerätes aufgenommen, wird diese in eine Liste angehängt. 

In einem ZigBee-Knoten können mehrere Endgeräte realisiert werden. Diese Endge- 

räte haben dann einige gleiche Attribute wie z.B. die 64-Bit IEEE-Adresse, die NWK- 

Adresse oder den Batteriezustand. Deshalb kann nach der Konfiguration eines ZigBee- 

Knotens angegeben werden, ob ein ” Kind-Endgerät“ angelegt werden soll. Für dieses 

werden die entsprechenden gleichen Attribute gesetzt, sodass sie nicht erneut eingege- 

ben werden müssen. Da nur maximal 240 Endgeräte in einem Knoten realisiert werden 

können (Siehe Abschnitt 3.5.3.3), wird der Configurator dies beachten. 

Hat man alle ZigBee-Knoten/Endgeräte eingegeben, wird der Configurator nun 

noch die ” Binding“-Beziehungen abfragen (Siehe Abschnitt 3.5.3.3). Die zuvor erstellte 

Geräteliste wird abgearbeitet. Dabei werden nur sinnvolle Verbindungen zugelassen 

(Siehe Tabelle 5.1). Wurde ein Gerät schon mit einem anderen verbunden, wird dies 

ebenfalls angezeigt. Abbildung 5.12 zeigt die Auswahl eines Endgerätes an. 



Dieses Device is bereits mit folgenden Device’s verbunden: 

IP: 10.8.10.1 

DeviceID: Leuchte 7 IP-Adresse: 10.8.10.2 

DeviceType: Switching Load Controller 

Bitte geben sie an mit welchem Knoten dieses \ 

Device verbunden werden soll. 

1: 10.8.10.3 

0: keine Auswahl 

Abbildung 5.12: Programmausgabe: Binding-Tabelle konfigurieren 

Aus der ZigBee-Spezifikation ist nicht ersichtlich, ob auch das Binding zwischen 

Knoten verschiedener ZigBee-Netzwerke möglich ist. Es ist aber denkbar, dass einige 

ZigBee-Knoten als Gateway zwischen zwei Netzwerken fungieren könnten und dann 

Nachrichten zwischen beiden austauschen könnten. 

Im Beispiel der Hausautomatisierung wäre es möglich, dass auf den verschiedenen 

Etagen eines Hauses einzelne ZigBee-Netzwerke aufgebaut werden, die über solche Ga- 

teways miteinander kommunizieren können. Im ZigBee-Configurator wurde auf eine 

Integration der Funktion ” Binding zu externen Endgeräten“ verzichtet. Jedoch ist es 

möglich, in der gespeicherten Konfigurationsdatei (Siehe Anhang A.9) per Hand die 

Einträge zu ergänzen. Zu beachten ist, dass dies bei beiden Endgeräten vorgenom- 

men wird. Abbildung 5.13 zeigt einen solchen Bindingeintrag auszugsweise. Werden 

... Auszug der Konfigurationsdatei sensornetwork.conf ... 

 

 

 

 

 

 

Abbildung 5.13: Binding-Information in der Konfigurationsdatei 

später im laufenden Betrieb Nachrichten zwischen dem Sensornetzwerk-Simulator und 

einem Proxyserver oder zwischen zwei Proxyservern ausgetauscht, werden die Binding- 

Informationen beachtet. Somit kann ein Endgerät aus Sensornetzwerk A ein Endgerät 

aus Sensornetzwerk B steuern. 

Hat man durch einen nachträglichen Eintrag zwei Endgeräte miteinander verbun- 

den, die laut der Profilbeschreibung keine Daten miteinander austauschen können, 



wirkt sich dies auf den Programmablauf nicht nachträglich aus. Zwar werden ent- 

sprechende Attribut-Änderungs-Nachrichten an die betroffenen Endgeräte (also die 

Sensornetzwerk-Simulatoren) versendet, diese überprüfen aber, ob die Attributände- 

rung überhaupt zum Typ des Endgerätes passt. Wenn dies nicht der Fall ist, wird die 

Nachricht verworfen. 

Hat man auch die Binding-Informationen vollständig eingegeben, kann das erstellte 

Sensornetzwerk gespeichert werden. 

5.3.1.2 Start des Sensornetzwerkes 

Nach erfolgreichem Anlegen eines neuen Sensornetzwerkes oder nach dem Einlesen ei- 

nes zuvor gespeicherten Sensornetzwerkes kann dieses gestartet werden. Das Objekt 

SensorNetwork versucht über den Configurator eine Verbindung zu einem Proxy- 

server herzustellen. Gelingt dies nicht, wird periodisch ein neuer Verbindungsversuch 

initiiert, bis eine Verbindung hergestellt werden kann oder das Programm beendet wird. 

Zusätzlich wird der IO-Manager gestartet. Als eigener Thread nimmt er Eingaben vom 

Anwender entgegen. 

Zunächst sind nur die Funktionen ” Status Ändern“ und ” Speichern des Zustandes 

des Netzwerkes“ implementiert. Abbildung 5.14 zeigt dieses Menu. 

--- SensorNetwork running --- 

Ihre Optionen... 

1: Status eines Devices aendern 

4: Aktuellen Zustand des Netzwerkes speichern 

5: Beenden 

----------------------------- 

Abbildung 5.14: Programmausgabe: Auswahlmenu nach Start des Sensornetzwerkes 

Hat man ” Status Ändern“ gewählt, wird eine Auflistung aller Endgeräte dieses Netz- 

werkes angezeigt, aus denen eines gewählt werden kann. Anschließend werden alle ver- 

änderbaren Attribute dieses Endgerätes aufgelistet. Hat der Anwender eines selektiert, 

kann dieses verändert werden. In Abbildung 5.15 wurde wieder das Attribut ” OnOffS- 

RC“ gewählt. 

Wurde die Änderung durchgeführt, wird das veränderte Attribut vom SensorNetwork 

verarbeitet. Dabei wird zunächst das betreffende Endgerät aktualisiert. Anschließend 

werden die Binding-Einträge ausgewertet und die betreffenden Endgeräte dieses Sen- 

sornetzwerkes aktualisiert, sofern dies sinnvoll ist. Für jedes veränderte Endgerät wird 

eine Nachricht mit der Attributänderung an den Proxyserver verschickt. Dort werden 



Sie haben OnOffSRC ausgewaehlt 

ON or OFF commands for Switch Remote Control 

Der aktuelle Wert ist: Toggle Output 

Sie koennen folgende Werte setzen... Abbrechen mit xxx 

0: On: ON Command for Switch Remote Control 

1: Off: OFF Command for Switch Remote Control 

2: Toggle Output: Used for 3 Way Switches 

Abbildung 5.15: Programmausgabe: Änderung eines Attributes im laufenden Betrieb 

diese Nachrichten dann verteilt. Dem Anwender wird die erfolgreiche Änderung ebenso 

angezeigt. 

Im Hintergrund wartet das SensorNetwork auf ankommende Nachrichten. 

Diese können einerseits eine Statusanforderung über bestimmte Attribute 8 einzelner 

Endgeräte sein. 

Ein weiterer Nachrichtentyp ist die Information über die Statusänderung eines At- 

tributes in einem externen Endgerät (siehe Anmerkung zum externen Binding in Ab- 

schnitt 5.3.1). Diese Nachricht muss ausgewertet werden und betreffende Endgeräte 

des eigenen Netzwerkes unter Umständen aktualisiert werden. 

Schließlich ist noch ein Attributänderungswunsch für ein Endgerätes im eigenen 

Sensornetzwerk möglich. Diese Nachricht wird von einem Client gesendet und muss 

überprüft werden, ob eine solche Änderung für das betreffende Endgerät sinnvoll er- 

scheint. 

5.4 Der Client 

Die Abbildung 5.16 zeigt den Aufbau des Client-Programmes. Dieser besteht aus ei- 

nem Front- und einem Backend. Wie im Sensornetzwerk-Simulator wurden mehrere 

Programmteile des Proxyserver-Programmes wiederverwendet. 

Die Funktionalität des AuthManagers wird durch den ClientManager erbracht. Für 

das Einlesen und Schreiben von XML-Konfigurationsdateien und das Erstellen von 

Nachrichten wurden die entsprechenden Klassen der Proxyserver-Komponente inte- 

griert. 

Nach dem Starten des Programms werden die drei Komponenten ClientManager, 

Client und der IO-Manager gestartet. Der ClientManager liest eine Konfigurations- 

8 Durch die Unterstützung von Anwendergruppen im Proxyserver wird dieser nur bestimmte Attri- 

bute abfordern. 


5.4 Der Client 83 

Client 

Listener 

Backend 

Frontend 

ClientManager 

.setUserData() 

.registerOutgoingSocket() 

.registerIncommingSocket() 

Authenticator 

IO-Manager 

Client 

showAttribute() 

.changeAttirbute() 

.connectToZigBeeMaster() 

.connectToZigBeeByIP() 

AttributListe 

IP-Address 

Attribut 

AuthSocket 

Abbildung 5.16: Die Struktur des Clients 

Proxy 

datei ein, in der die eigenen Adressinformationen enthalten sind. Ausserdem kann die 

Adresse eines ZigBee-Auskunftsdienstes angegeben werden. Der IO-Manager zeigt dem 

Anwender ein Auswahlmenu an, welches in Abbildung 5.17 dargestellt ist. 

--- ZigBee-Netzwerk-Kontrolle --- 

Ihre Optionen... 

1: Zum ZigBee-Auskunftsdienst verbinden 

2: Zu einem ZigBee-Geraet direkt verbinden 

3: Beenden. 

----------------------------- 

Abbildung 5.17: Programmausgabe: Startmenu des Clients 

Durch Auswahl von ” Zum ZigBee-Auskunftsdienst verbinden“ wird der Client ver- 

suchen, sich zu dem ZigBee-Auskunftsdienst zu verbinden. Die IP-Adresse des ZigBee- 

Auskunftsdienstes ist wie die der ZigBee-Endgeräte real im Netzwerk nicht vorhanden. 

Es wird eine Verbindung zu einem Proxyserver mit einer Zieladresse aus dem 10.8.0.0- 

Adressbereich aufgebaut. Dieser Proxyserver fungiert dann als Auskunftsdienst. 

Zuerst wird die Authentifizierung 9 durchgeführt. War diese erfolgreich, wird der 

Proxyserver (als ZigBee-Auskunftsdienst) eine Liste aller bekannten ZigBee-Endgeräte 

9 Nach dem Starten des Clients müssen nur beim ersten Verbindungswunsch die Anwenderdaten 

eingegeben werden. Für jeden weiteren Verbindungswunsch werden diese dann automatisch verwendet. 



an den Client zurücksenden. Die Verbindung wird danach abgebaut. 

Dem Anwender wird diese Auswahl angezeigt. Er kann dann den Client veranlassen, 

sich zu einem dieser ZigBee-Endgeräte zu verbinden. War dies erfolgreich, sendet der 

Client eine Nachricht an das ZigBee-Endgerät. 

Mit dieser Nachricht wird das Endgerät aufgefordert, dem Client alle Attribute zu 

übermitteln. Der Proxyserver, zu dem die Verbindung ja in Wahrheit besteht, wird 

nun alle Attribute übersenden, für die der Anwender freigeschaltet ist. Die aktuellen 

Zustandswerte wird der Proxy durch entsprechende Nachrichten von dem betroffenen 

Sensornetzwerk-Simulator abfordern. 

In jedem Attribut ist zusätzlich angegeben, ob diese Attribut auch verändert werden 

kann. Dazu werden im Proxyserver die Informationen der Anwendergruppen verwendet 

(Siehe Abschnitte 5.2.1 und 5.2.6). 

Anschließend wird dem Anwender der erfolgreiche Aufbau einer Verbindung zu die- 

sem Endgerät angezeigt. Der Anwender kann nun verschieden Aktionen ausführen. Er 

kann sich den Status des Endgerätes anzeigen lassen oder Attribute des Endgerätes 

verändern. Zusätzlich kann der Anwender die Verbindung abbauen, zuvor dem Endge- 

rät aber anzeigen, dass dieses ihn bei einem Ereignis (Attributänderung) zurückruft. 

Abbildung 5.18 zeigt das Optionen-Menu an. 

Verbunden mit 10.8.5.6 

--- Ihre Optionen... --- 

1: Status anzeigen 

2: Attribut aendern 

3: Ein anderes Geraet aufrufen 

4: Ausloggen und auf Rueckruf durch den Sensorknoten warten 

5: Beenden 

----------------------------- 

Abbildung 5.18: Programmausgabe: Optionen-Menu im Client nach erfolgreicher Verbindung 

Die Änderung eines Attributes geschieht in ähnlicher Weise wie im Sensornetzwerk- 

Simulator. Es werden die selben Eingabemöglichkeiten angezeigt. 

Hat ein Anwender ein Attribut geändert, schickt der Client eine Nachricht an den 

Proxyserver. Dort wird diese zum entsprechenden Sensornetzwerk-Simulator vermit- 

telt. 

Dieser gleicht die Attributänderung mit den Attributen des betreffenden Endgerätes 

ab. Dieser Mechanismus ist in Abschnitt 5.3.1.2 bereits beschrieben worden. Konnte die 

Attributänderung durchgeführt werden, wird eine entsprechende Änderungsnachricht 


5.5 Kopplung über das Internet durch den Einsatz eines VPNs 85 

generiert. Diese wird an alle betreffenden Komponenten geschickt und wird letztlich 

auch im Client ankommen. 

Dieser zeigt die Änderung dem Anwender an. Ebenso werden dem Anwender Attri- 

butänderungen angezeigt, die dieser selber nicht veranlasst hat. Ein Schalter könnte 

z.B. von zwei Anwendern an zwei Clients geschaltet werden, oder von der Änderung 

eines anderen Endgerätes betroffen sein (Siehe Abschnitt 5.3.1.2). In Abbildung 5.19 

ist eine solche Änderung abgebildet. 

Nachricht erhalten: Ein Attribut wurde geaendert... 

Name des Attributes: OnOffSRC 

Beschreibung: ON or OFF commands for Switch Remote Control 

Neuer Wert: On 

Abbildung 5.19: Anzeige einer Attributänderung 

Hat der Anwender eine Rückrufnachricht an das Endgerät gesendet, wird die Ver- 

bindung abgebaut. Der Proxyserver registriert den Rückrufwunsch und wird bei einem 

entsprechenden Ereignis versuchen, den Client zurückzurufen. Dabei wird als Quell- 

Adresse die IP-Adresse des ZigBee-Endgerätes verwendet. Kann eine Verbindung auf- 

gebaut werden (Siehe Abschnitt 5.2.7), wird dem Anwender des Clients die in Ab- 

bildung 5.20 dargestellte Nachricht angezeigt. Der Anwender kann dann die bereits 

geschilderten Aktionen ausführen. 

Verbindung von Endgeraet 10.8.5.6 angenommen 

--------------------------------------- 

Abbildung 5.20: Programmausgabe: Rückruf durch ein Engerät 

5.5 Kopplung über das Internet durch den Einsatz 

eines VPNs 

Damit ein Anwender eines Clients eine Verbindung zu einem Proxyserver aufbauen 

kann (unter Verwendung der ZigBee-Endgeräte IP-Adressen) müssen der Client und 

der Proxy im selben privaten Netzwerk angekoppelt sein. Man könnte zwar auf dem 

Computer auf dem der Client ausgeführt wird Routingeinträge vornehmen, die diese 

Anfragen an einen Knoten eines anderen Netzwerkes weiterleiten, sind beide Netzwerke 

aber über das öffentliche Internet verbunden, können die IP-Pakete nicht weitergeleitet 

werden. 



Der Proxyserver bildet die ZigBee-Endgeräte mit IP-Adressen aus dem privaten 

Adressbereich 10.8.0.0 ab. Diese IP-Adressen dürfen aber aufgrund der Forderung 

nach der Eindeutigkeit von IP-Adressen im Internet nicht verwendet werden (Siehe 

Abschnitt 2.2.1). 

Um trotzdem die Funktionalität des Prototypen zu realisieren, kann ein ” Virtual 

Private Network-Server“ (VPN) eingesetzt werden. VPNs werden von vielen Unterneh- 

men eingesetzt, um mehrere Netzwerke über das Internet miteinander zu verbinden. 

In Abbildung 5.21 ist die Kopplung zweier Netzwerke mittels einer VPN-Verbindung 

dargestellt. 

Netzwerk 1 Netzwerk 2 

192.168.0.5 192.168.0.122 192.168.0.9 

192.168.0.180 192.168.0.190 

192.168.0.1 

192.168.0.7 

VPN Server 

NAT (Software) 

10.8.0.1 

NAT 

89.67.33.11 

148.24.55.9 

Internet 

Abbildung 5.21: VPN-Verbindung 

VPN Tunnel 

VPN Client 

(Software) 

10.8.0.2 

Dabei werden in beiden Netzen VPN-Gateways installiert. Diese Gateways werden 

durch eine Software realisiert und müssen nicht direkt an das Internet angeschlossen 

sein, sondern können auch hinter einem NAT-Router angesiedelt sein. Ein Gateway 

fungiert als Server, das andere als Client. Zwischen beiden wird ein Tunnel aufge- 

baut, durch den entsprechende Pakete der Computer in diesen Netzwerken geleitet 

werden. Dazu erstellen die VPN-Gateways eine eigene virtuelle Netzwerkschnittstelle 

auf dem Computer, auf dem diese Anwendungen ausgeführt werden. Diese Schnittstelle 

bekommt eine eigene IP-Adresse. 

Damit ein anderer Computer aus diesem Netzwerk dieses Gateway nutzen kann, 

müssen entsprechende Routingeinträge vorgenommen werden. Dann können Anfragen 


5.5 Kopplung über das Internet durch den Einsatz eines VPNs 87 

transparent durch den VPN-Tunnel geleitet und auf der anderen Seite dieses Tunnels 

von dem entsprechenden VPN-Gateway entgegengenommen werden. Diese wird dann 

versuchen, die empfangenen Pakete an lokale Rechner auszuliefern. 

Beide Seiten können eigene Verbindungen durch den Tunnel aufbauen. Damit können 

die gängigen Protokolle der Vermittlungs-, Transport- und Anwendungsschicht durch 

den Tunnel genutzt werden. 

Je nach Konfiguration sind alle Knoten in beiden Netzwerken in der Lage, die ande- 

ren Knoten zu erkennen. So könnte zum Beispiel ein Anwender im Netzwerk 1 auf die 

Druckerfreigabe eines Computers im Netzwerk 2 zugreifen. Da der Tunnel transparent 

arbeitet, ist es für die Anwender unter Umständen nicht einmal ersichtlich, dass zwei 

Netzwerke gekoppelt wurden. Für die Anwender scheint es, als ob sich alle Knoten im 

selben Netzwerk befinden. 

Ein weiterer Vorteil ist, dass dieser Tunnel unter Zuhilfenahme von hinreichend 

starken Verschlüsselungstechniken sicher gegenüber Angreifern von außen ist 10 . Sowohl 

der VPN-Client als auch der VPN-Server müssen sich gegenseitig authentifizieren und 

authentisieren. Dabei werden oft Schlüssel-Zertifikate verwendet. 

Der Prototyp kann durch die Nutzung eines VPNs bereichert werden. Das Protokoll, 

welches im Prototypen zur Kopplung von Clients, Proxyservern und Sensornetzwerken 

verwendet wird, kann über einen VPN geroutet werden. Somit kann auf ein ZigBee- 

Netzwerk auch über das Internet zugegriffen werden. 

Zum Test wurde auf einem Rechner ein VPN-Server aufgesetzt. Dabei kam ” OpenV- 

PN“ zum Einsatz. Diese OpenSource-Anwendung kann unter [Open] heruntergeladen 

werden. 

In der beiliegenden Dokumentation ist die Installation hervorragend beschrieben. 

Die Konfiguration eines eigenen VPN-Netzwerkes ist damit innerhalb kürzester Zeit 

möglich. Die Nutzung von OpenVPN ist kostenlos. 

Auf einem Computer wurde ein OpenVPN-Server installiert, auf einem Notebook ein 

OpenVPN-Client. Der Computer war in einem lokalen Netzwerk mittels eines NAT- 

Routers ans Internet angebunden. Am Notebook wurde eine Verbindung ins Internet 

über ein Mobiltelefon hergestellt. Nach der Initialisierung des VPN-Tunnels konnten 

beide Computer auf den jeweils anderen zugreifen. 

Auf dem Notebook wurde ein Proxyserver sowie ein Sensornetzwerk-Simulator gest- 

artet. Das Betriebssystem des Notebooks wurde durch entsprechende Routingeinträge 

10 Jedoch nur so lange, wie kein Computer durch eine andere Verbindung kompromittiert wurde. Hat 

ein Angreifer erst einmal Zugriff auf einen Rechner im Netzwerk erhalten, kann dessen VPN- 

Verbindung genutzt werden um auch auf andere Computer dieses VPN-Netzwerkes zuzugreifen. 

Daher sollte der Zugang zum VPN-Netzwerk mit Bedacht reglementiert werden. 



angewiesen, Anfragen an Knoten mit IP-Adressen aus dem Bereich 10.8.0.0 über den 

VPN-Client zu versenden. 

Innerhalb kürzester Zeit konnte sich ein Client (des Prototyps) an einem Proxyserver 

ankoppeln. Dabei sinkt die Verarbeitungszeit zwar merklich ab, was aber auf die Ver- 

wendung des Mobiltelefons zurückzuführen ist. Der Prototyp ist aber in seinem vollen 

Umfang nutzbar. 

Ein weiterer Vorteil ist die Verschlüsselung der Kommunikation im VPN-Tunnel. Im 

Prototypen ist zwar eine Authentifizierung implementiert, allerdings werden alle Daten 

des entwickelten Protokolls im Klartext übertragen. Verwendet man ein Programm, 

welches den Netzwerkverkehr protokollieren kann, wie z.B. ethereal [Ethe], können alle 

Informationen mitgelesen werden. 

Durch den Einsatz der OpenVPN-Technik ist dies nicht mehr möglich, da deren 

Tunnel verschlüsselt wird. 

5.6 Unterstützte Netztopologien 

Die Struktur des Prototypen erlaubt es, vielfältige Netztopologien aufzubauen. In Ab- 

bildung 5.22 sind beispielhaft 3 Topologien aufgezeigt. 

Die ZigBee-Endgeräte wurden schematisch zusammengefasst, in der Annahme dass, 

jeder Sensornetzwerk-Simulator mehrere Knoten verwalten kann. 

Im einfachsten Fall (Abbildung 5.22 a.) befinden sich Client, Proxy und Sensornetz- 

werk-Simulator in einem abgeschlossenen Netzwerk. Der Client kann über den Proxy- 

server auf alle ZigBee-Endgeräte zugreifen. 

Im zweiten Fall (Abbildung 5.22 b.) sind zwei Proxyserver von zwei privaten Netzwer- 

ken miteinander gekoppelt. Alle Clients in beiden Netzwerken können auf alle ZigBee- 

Endgeräte in beiden Netzwerken zugreifen. Eine besonderer Fall ist hier nicht aufge- 

zeigt. Sind die beiden Netzwerke an das Internet angeschlossen und wird einer der 

Proxyserver auf einem Computer ausgeführt, der direkt aus dem Internet adressierbar 

ist, kann eine Verbindung zwischen beiden Proxyservern aufgebaut werden. Dazu kann 

der Proxyserver, der aus dem Internet adressiert werden kann, einen Verbindungs- 

wunsch von dem anderen Proxyserver annehmen. 

Allerdings soll nocheinmal ausdrücklich auf die Tatsache hingewiesen werden, dass 

die Verbindungen im Prototypen nicht verschlüsselt werden. Damit kann jeder Router 

im Internet, über den eine solche Verbindung geroutet wird, die Kommunikation mit- 

protokolieren. Daher sollte ” immer“ eine VPN-Verbindung bei der Kopplung über das 

Internet verwendet werden. 


5.6 Unterstützte Netztopologien 89 

IP-Netz 1 

Client 

Client 

a.) 

IP-Netz 1 

Client 

IP-Netz 2 

Client 

b.) 

IP-Netz 1 

Client 

IP-Netz 2 

Client 

IP-Netz 5 

Client 

c.) 

VPN 

VPN 

VPN 

Proxyserver 

Proxyserver 

Proxyserver 

IP-Netz 3 

Proxyserver 

VPN 

Proxyserver 

IP-Netz 4 

Abbildung 5.22: Mögliche Netztopologien des Prototyps 

Sensornetzwerk- 

Simulator 


Simulator 


Simulator 


Simulator 


Simulator 

Abbildung 5.22 c.) zeigt schließlich eine Kopplung mehrere Clients an mehrere Proxy- 

server und Sensornetzwerk-Simulatoren. Die Verbindungen der Programmkomponen- 

ten der einzelnen Netzwerke erfolgt dabei unter Einsatz von OpenVPN. In der Ab- 

bildung wurde aus Gründen der Übersichtlichkeit auf die Darstellung der VPN-Server 



und -Clients verzichtet. 

An dieser Stelle soll nocheinmal besonders auf die Möglichkeit der Kopplung meh- 

rerer Proxyserver miteinander eingegangen werden. Diese tauschen alle Informationen 

über die ihnen bekannten ZigBee-Endgeräte aus. Der Anwender eines Clients kann alle 

Endgeräte direkt mit ihrer IP-Adresse ansprechen. 

Dies setzt aber voraus, dass auf allen Computern, auf denen die Proxyserver gest- 

artet werden, die entsprechenden Netfilter-Regeln ausgeführt wurden. Diese Regeln 

müssen dieselben Zieladressbereiche (z.B. 10.8.0.0) umfassen. Damit ein Rückruf rea- 

lisiert werden kann, muss ebenso auf allen Proxyserver-Computern der TPROXY-Patch 

installiert sein. Ohne ihn ist kein Rückruf möglich. 

Der Proxyserver kann aber auch ohne die beiden Funktionen ausgeführt werden. Die 

Entwicklung des Prototyps wurde hauptsächlich unter dem Betriebssystem OS X auf 

einem Mac durchgeführt. 

Alle drei Programmkomponenten sind daher sowohl unter Linux als auch unter Mac 

OS X lauffähig. Allerdings ist hier die Funktionalität des Proxyservers eingeschränkt. 

Er kann dann keine Verbindungen zu einer ” nicht existierenden“ IP-Adresse annehmen 

oder aufbauen. 

Damit können an diesem Proxyserver keine Clients angemeldet werden. Jedoch 

können Sensornetzwerk-Simulatoren angekoppelt werden. Dann können deren ZigBee- 

Endgeräte für Clients die an anderen Proxyservern angemeldet sind, zur Verfügung 

gestellt werden. 


6 Evaluierung des implementierten 

Prototyps 

6.1 Mögliche Lösungsansätze 

Eine der Aufgaben, die im Rahmen dieser Diplomarbeit durchgeführt werden soll, ist 

der Vergleich des selbst entwickelten Ansatzes mit vorhandenen Lösungen. 

Ziel ist die Kopplung eines drahtlosen Sensornetzwerkes auf Basis der ZigBee-Tech- 

nologie an IP-basierte Kommunikationssysteme. IP ist der Quasi-Standard zur Vernet- 

zung von Computern im Internet. 

Dass eine Kopplung eines drahtlosen Sensornetzwerkes an solche IP-Netzwerke sinn- 

voll und wünschenswert ist, kann nicht bestritten werden. Ein Sensornetzwerk kann 

gerade in der Hausautomatisierung nur dann sinnvoll eingesetzt werden, wenn auch 

ein Zugriff auf dieses Netzwerk durch Anwender möglich ist. 

In vielen Haushalten sind mehrere Computer vorhanden. Viele Anwender können 

mit mobilen Geräten wie PDAs und Notebooks durch den Einsatz eines WLANs Ver- 

bindungen in das Internet und zu lokalen Computern aufbauen. Es bietet sich daher 

an, auch ein installiertes drahtloses Sensornetzwerk mit herkömmlichen Computern 

fernzusteuern. 

In Sensornetzwerken fallen meist nur sehr wenige Daten an. Ein Schalter oder eine 

Leuchte können durch die Übertragung eines einfachen Kommandos wie ” An“ oder 

” Aus“ ihren Status ändern und die betreffenden Funktionen auslösen. Die übertragenen 

Kommandos können mit sehr kurzen Byte-Folgen realisiert werden. Dabei sollen die 

Knoten eines drahtlosen Sensornetzwerkes sehr energiesparsam arbeiten, da sie meist 

mit einer Batterie oder einem Akkumulator betrieben werden. Einem Sensorknoten 

stehen damit nur beschränkte Energieressourcen zur Verfügung. 

Zur Lösung der Anforderung, ein drahtloses Sensornetzwerk an ein IP-basiertes Sys- 

tem zu koppeln, gibt es Prinzipiell nur zwei Möglichkeiten. 

Die Eine ist die Implementierung eines der beiden Protokolle (IP oder das im Sen- 

sornetzwerk verwendete) im jeweils anderen Netzwerk. Die andere ist die Verwendung 

91 


92 6 Evaluierung des implementierten Prototyps 

eines Gateways als Protokollumsetzer. 

6.1.1 Implementierung des IP-Protokolls im Sensornetzwerk 

Man kann das IP-Protokoll in die Knoten des zu koppelnden Sensornetzwerkes im- 

plementieren. Jedoch sprechen mehrere Umstände dagegen. Die Anforderungen an 

Energieeffizienz schliesst eine direkte Verwendung des IP-Protokolls aus. Im paket- 

vermittelnden IP-Protokoll wird jedem Datenpaket ein Header vorangestellt, der die 

Adressinformation enthält. Dieser Header ist mindestens 20 Byte groß. 

Sollen aber nur wenige Bytes Nutzdaten übertragen werden, wird schnell ein Problem 

ersichtlich. Der so genannte Protokolloverhead wäre sehr groß. Da jede Datenübertra- 

gung Energieressourcen verbraucht, ist es daher wünschenswert, den Protokolloverhead 

so klein wie möglich zu gestalten. 

Sensorknoten in drahtlosen Sensornetzwerken wie ZigBee werden ausserdem unter 

der Prämisse entwickelt, kostengünstig produziert werden zu können. Deshalb werden 

meist leistungsarme Prozessoren und Bauteile verwendet. 

Das Routing in IP-Netzwerken ist mit einigem Rechenaufwand verbunden, der für 

handelsübliche Computer kein Problem darstellt. Die Sensorknoten können aber leicht 

damit überfordert werden. 

Ein weiteres Problem, das gegen eine direkte Implementierung des IP-Protokolls 

spricht, ist die Tatsache, dass ein Sensorknoten, der direkt an ein IP-Netzwerk ge- 

koppelt ist, alle ankommenden IP-Pakete auswerten muss. Selbst wenn diese nicht 

für ihn bestimmt sind, muss er diese Tatsache durch die Auswertung des IP-Headers 

erst einmal feststellen. Sind mehrere Sensorknoten und Computer in einem Netzwerk 

verbunden, können so schnell einige hundert IP-Pakete pro Sekunde eintreffen. 

Die Auswertung aller eintreffenden IP-Pakete erfordert einen gewissen Anteil der 

begrenzten Energieressourcen. Sensorknoten sollen aber mehrere Monate oder sogar 

mehrere Jahre mit einer Batterie bzw. einer Akkuladung auskommen. 

In vielen Fällen wird ein Sensorknoten nur zu unregelmässigen Zeitpunkten aktiv. 

Das An- oder Abschalten einer Leuchte wird an einem Tag meist nur wenige Male aus- 

geführt. Daher wird der größte Teil ankommender IP-Pakete für diesen Sensorknoten 

nicht von Interesse sein. Solange keine ergiebigeren Energiequellen genutzt werden kön- 

nen, ist daher eine Implementierung des IP-Protokolls in drahtlosen Sensornetzwerken 

nur unter Umständen sinnvoll. 

Der umgekehrte Weg, das Sensornetzwerkprotokoll im IP-Netzwerk zu implementie- 

ren ist zwar realisierbar, scheidet jedoch als Lösung aus. Man kann nicht alle Knoten 


6.2 Der Prototyp auf Basis eines transparenten Proxys 93 

eines IP-Netzwerkes, gerade in Bezug auf das Internet, um das Sensornetzwerkprotokoll 

erweitern. 

6.1.2 Einsatz eines Gateways als Protokollumsetzer 

In vielen Anwendungen wird daher ein anderer Ansatz gewählt. Zwischen Sensornetz- 

werk und IP-Netzwerk wird ein Gateway eingeschleift. Dieses nimmt eine Protokoll- 

umsetzung vor. Der Zustand des Sensornetzwerkes, und damit der einzelnen Knoten 

wird durch das Gateway dargestellt. Viele verschiedene Umsetzungen sind realisiert 

worden. Eine Umsetzung ist TinyDB. Dabei werden die Zustände der Sensorknoten in 

einer Datenbank abgelegt, auf die der Anwender mit SQL-ähnlichen Abfragen zugreifen 

kann. 

Einen anderen Ansatz realisiert die OSGi-Alliance. Dieser Zusammenschluss meh- 

rerer Firmen stellt ein Framework bereit, in dem Anwendungen ausgeführt werden 

können. Über enstprechende Schnittstellen können diese Anwendungen mit andere- 

ren Knoten kommunizieren. Der Vorteil der OSGi-Architektur ist die Unterstützung 

von Plugins. Im laufenden Betrieb kann so die Funktionalität eines Knotens verändert 

werden. 

Für viel Anwendungsfälle sind OSGi-Programme erhältlich. Auch zur Kopplung von 

drahtlosen Sensornetzwerken in der Hausautomation sind Produkte verfügbar. 

Die Nutzung des OSGi-Frameworks kann für die Steuerung eines Sensornetzwerk 

sicherlich als Ideal-Lösung angesehen werden. Viel Protokolle wie HTTP, E-Mail oder 

FTP werden unterstützt 

Die vorgestellte OSGi-Architektur oder die Verwendung von TinyOS und TinyDB 

sind sicherlich eine gute Lösung zur Kopplung von Sensornetzwerken an IP-basierte 

Kommunikationssysteme. Durch die langjährige Entwicklungszeit dieser Lösungsansät- 

ze sind die erhältlichen Produkte sehr leistungsfähig. Es soll jedoch angemerkt werden, 

dass man zur Nutzung dieser Ansätze immer ein spezielles Programm oder Protokolle 

verwenden muss. Dieses kann entweder durch den Anwender direkt ausgeführt werden 

oder durch das Gateway realisert sein. 

6.2 Der Prototyp auf Basis eines transparenten Proxys 

In dieser Diplomarbeit wurde ein Prototyp auf Basis eines transparenten Proxys rea- 

lisiert. Dabei wird jedem Knoten bzw. Endgerät 1 eine eigene IP-Adresse aus dem pri- 

1 Bei ZigBee kann ein Knoten mehrere Endgeräte-Funktionen erfüllen. 



vaten IP-Adressbereich 10.0.0.0 vergeben. 

Diese IP-Adresse kann von einem Client direkt angesprochen werden. Allerdings 

antwortet nicht das Endgerät, sondern ein Proxyserver, der transparent dazwischen 

geschliffen ist. Dem Client ist die Existenz des Proxyservers nicht bewusst. Die Adres- 

sumsetzung wird dabei durch die Verwendung des Paketfilters Netfilter unter dem 

Betriebssystem Linux durchgeführt. 

Schließlich ist auch ein Rückruf des ZigBee-Endgerätes an den Client möglich. Dieser 

Rückruf kann durch eine Veränderung des Zustandes im Endgerät ausgelöst werden. 

Konnte eine Verbindung zum Client aufgebaut werden, kann dieser über die Änderung 

im Endgerät informiert werden. 

Das besondere ist, dass die eigentliche Verbindung zum zwischengeschliffenen Proxy- 

server für den Client nicht ersichtlich ist. Für diesen scheint die Verbindung direkt zu 

dem Endgerät zu bestehen. Das ZigBee-Netzwerk wird durch einen Netzwerk-Simulator 

dargestellt. Dadurch ist eine spätere Kopplung an ein reales Sensornetzwerk möglich. 

Dieses kann z.B. durch einen Computer angeschlossen werden, der eine Verbindung in 

das ZigBee-Netzwerk mit einem USB-Adapter hält. 

Die Struktur des Prototypen erlaubt eine Skalierung auch über mehrere Netzwerke. 

In Verbindung mit einem VPN-Server ist damit auch eine direkte Kommunikation mit 

dem Sensornetzwerk über das Internet möglich. 

ZigBee erlaubt die Verwendung so genannter Profile, mit denen die möglichen Funk- 

tionen eines Endgerätes realisiert werden können. Momentan ist nur das Profil ” Home 

Control, Lighting“ erhältlich [ZigB]. Diese Profil ist nicht direkt in den Programmcode 

des Prototyps integriert, sondern wird aus einer XML-Datei beim Start der Kom- 

ponenten ProxyServer und Sensornetzwerk-Simulator eingelesen. Dadurch müssen die 

Programme nicht verändert werden 2 , sondern lediglich die Konfigurationsdatei ange- 

passt werden. 

Durch die Unterstützung von Anwendergruppen können gezielt bestimmte Attribu- 

te eines Endgerätetyps für einen Anwender einer bestimmten Anwendergruppe ausge- 

schlossen oder freigeschaltet werden. Ein Anwender der Gruppe ” Normaler Anwender“ 

wird so z.B. bei einer Leuchte nur den Zustand ” An/Aus“ erfahren können. Ein An- 

wender aus der ” Admin“-Gruppe könnte sich einen Gesamtüberblick aller Attribute 

dieses Endgerätes angeben lassen. 

Aufgrund der eingeschränkten Bearbeitungszeit wurde jedoch auf die Erstellung gra- 

phischer Frontends in der Client- und Sensornetzwerk-Simulator-Komponente verzich- 

2 Eine Integration der Profilbeschreibung in den Code der Programme hätte zur Folge, das dieser 

Code verändert werden müßte, sollen neuen ZigBee-Profile unterstützt werden. 


6.2 Der Prototyp auf Basis eines transparenten Proxys 95 

tet. Alle drei Programmteile sind als Konsolenanwendung realisiert. Durch die Er- 

stellung eines Kommunikationsprotokolls und durch die Teilung in drei Komponenten 

können später einzelne Komponenten leicht ausgetauscht werden. 

So ist die Entwicklung eines graphischen Clients unter Linux oder Mac OS X möglich. 

Alle drei Komponenten sind unter den Betriebssystemen Linux und Mac OS X lauffä- 

hig. Allerdings kann nur unter Linux eine Adressumsetzung mit falschen IP-Adressen 

vorgenommen werden. 

6.2.1 Vergleich mit OSGi 

Der entwickelte Prototyp ist von seiner Funktionalität sicherlich nicht mit denen ei- 

ner marktreifen Lösung, wie sie z.B. die OSGi-Alliance anbietet, zu vergleichen. Viele 

Funktionen die diese bieten, sind im Prototypen nur rudimentär realisiert. 

So werden zum Beispiel bei der Auswertung von Attributänderungen eines Endgerä- 

tes keine Prioritäten gesetzt. Jede Nachricht wird gleich behandelt. Ein Anwender kann 

nicht angeben, dass er nur im Falle einer Alarmregistrierung von einem Alarmsensor 

informiert werden soll. Hat dieser weitere Attribute, für die der Anwender freigeschaltet 

wurde, wird er über alle betreffenden Änderungen informiert. 

Der Client erlaubt auch nur eine Verbindung zu einem Endgerät zu einem Zeitpunkt. 

Damit wird er nur über die Änderung dieses einen Endgerätes informiert. Um zu zei- 

gen, dass eine Adressvergabe mit einem transparenten Proxy funktioniert, ist diese 

Einschränkung aber sinnvoll. Warum sollte ein Endgerät, das direkt mit einer eigenen 

IP-Adresse angerufen wurde, über die Zustandsänderung in einem Endgerät berichten? 

Betrachtet man den Prototypen in Bezug auf Usability, wird zuerst das Fehlen der 

graphischen Frontends in der Client- und der Sensornetzwerk-Simulator-Komponente 

negativ auffallen. Jedes Endgerät verfügt über mehrere Attribute. Diese werden zwar 

im Client angezeigt, allerdings muss sich der Anwender durch ein Text-Menu durchar- 

beiten. Daher ist die Entwicklung eines graphischen Frontends anzuraten. 

Ein Vorteil des in dieser Diplomarbeit entwickelten Ansatzes ist jedoch der Zugang 

zu den Sensorknoten bereits auf der Vermittlungsschicht. Während Anwendungen wie 

TinyDB oder OSGi erst einen Zugriff auf der Transportschicht sowie der darüberlie- 

genden Anwendungsschicht bieten, können mit dem entwickelten Ansatz auch andere 

Protokolle der Vermittlungsschicht verwendet werden. 

So ist es denkbar, den Prototypen durch die Integration des Protokolles ICMP zu 

erweitern. Dann könnte mit einem einfachen Konsolenbefehl ermittelt werden, ob ein 

ZigBee-Endgerät noch funktioniert. Der Prototyp könnte diese ICMP-Anfragen entge- 



gennehmen und nur im Falle, dass das betreffende Endgerät arbeitet, mit einer ent- 

sprechenden ICMP-Nachricht antworten. 

Ein weiteres Protokoll das in vielen Netzwerken angewendet wird, ist das DHCP- 

Protokoll zur automatischen Adressvergabe. Bislang werden die Knoten im Prototyp 

mit einer festen IP-Adresse vergeben. Unterstützt man DHCP, könnte ein vorhandener 

DHCP-Server diese Adressen zuweisen. 

Viele Betriebssysteme zeigen dem Anwender benachbarte Computer in einer so 

genannten ” Netzwerkumgebung“ an. Die dafür verwendeten Protokolle könnte man 

ebenso im Prototypen unterstützen. Damit wäre ein Szenario denkbar, alle ZigBee- 

Endgeräte in der Netzwerkumgebung anzuzeigen. 

Integriert man das HTTP-Protokoll in den Prototypen, ist eine Bedienung des Sen- 

sornetzwerkes mit einem herkömmlichen Webbrowser möglich. Der Anwender könnte 

so z.B. durch die Eingabe der Adresse 10.8.5.6 in den Webbrowser direkt die Status- 

informationen des betreffenden ZigBee-Endgerätes in Erfahrung bringen. Dazu muss 

auf seinem Computer keine Änderung am Betriebssystem oder dem Webbrowser vorge- 

nommen werden. Der Anwendercomputer muss lediglich wissen, wohin solche Pakete 

geleitet werden sollen. Dazu ist die Angabe des Standardgateways nötig. Installiert 

man den Proxyserver auf dem Computer, der sowieso als Standardgateway für den 

Computer des Anwenders fungiert, sind keine weiteren Einträge nötig. 

6.3 Probleme beim Rückruf mit einer falschen 

IP-Adresse 

Der in Abschnitt 4.2.3 beschriebene Ansatz, eine ausgehende Verbindung durch die 

Installation eines Patches zu realisieren, führt nicht immer zum Erfolg. In den meisten 

Fällen ist im Proxyserver der Aufbau einer Verbindung möglich, mitunter funktioniert 

dies aber nicht. In der Regel ist der Aufbau von zwei oder drei Verbindungen pro 

Sitzung möglich. Normalerweise soll der Proxyserver in solchen Fällen, dass der Cli- 

ent nicht erreichbar ist 3 , einen weiteren Verbindungsaufbau unterlassen und mit der 

normalen Arbeitsweise fortfahren. 

In einigen Fällen stoppt dann jedoch die Nachrichtenverteilung im Proxyserver. Da- 

mit wird auch die Weiterleitung von Nachrichten zu anderen Teilnehmern nicht mehr 

durchgeführt. 

Bis zum Ende der Bearbeitungszeit dieser Diplomarbeit konnte die Ursache dieses 

3 Dies könnte ja auch dadurch beding sein, dass der Anwender den Client beendet hat. 


6.3 Probleme beim Rückruf mit einer falschen IP-Adresse 97 

Problems nicht geklärt werden. Es scheint jedoch ein Fehler in der Implementierung 

des Patches zu sein. Der eigene Code wurde dem Beispielprogramm, welches dem Patch 

beiliegt angepasst und sollte somit den Vorgaben entsprechen. 

Beobachtet man den ein- und ausgehenden Paketverkehr des betroffenen Computers 

mit einem Protokoll-Analyzer wie ethereal [Ethe], kann man erkennen, dass einige Pa- 

kete mit der angegebenen Quelladresse versendet werden. Diese haben jedoch teilweise 

falsche Einträge und werden somit nicht weitergeleitet. Noch schlimmer ist jedoch, dass 

auch Pakete anderer Verbindungen dieses Computers nicht mehr dem entsprechenden 

Format genügen. Dies ist unabhängig davon, ob diese Verbindungen vom Proxyserver 

aufgebaut oder angenommen wurden oder zu anderen Prozessen gehören. 

Es scheint so als ob die Verwendung der Patch-Funktionen den Netfilter durch- 

einander bringt. Erst durch einen Neustart des Netzwerkes kann dessen Funktionalität 

wiederhergestellt werden. 

Bis zur Klärung dieses Problems sollte daher der Rückruf unterbunden werden. Da- 

her wurde im Proxyserver noch eine Abfrage integriert. Wird in der Konfigurationsda- 

tei der Schlüssel ” UseTPROXY“ auf den Wert ” 0“ gesetzt, ignoriert der Proxyserver 

entsprechende Anforderungen. 




7 Zusammenfassung 

In der vorliegenden Diplomarbeit wurde der Einsatz eines transparenten Proxys zur 

Kopplung von Sensornetzwerken an IP-basierte Kommunikationssysteme am Beispiel 

der Hausautomatisierung untersucht. Als Sensornetzwerktechnologie wurde exempla- 

risch ZigBee verwendet. Da ein reales ZigBee-Netzwerk nicht zur Verfügung stand, 

wurde ein Simulator erstellt, der im entwickelten Prototypen die Funktionalität des 

ZigBee-Netzwerkes bereitstellt. 

Eine Ankopplung eines Sensornetzwerkes an ein IP-Netzwerk in der Hausautomation 

ist ein lohnenswertes Ziel. Viele Haushalte verfügen über ein oder mehrere Computer. 

Viele Anwender können auch mit einem Notebook oder einem PDA drahtlos auf das 

Internet zugreifen. Es bietet sich daher an, auch die Endgeräte eines vorhandenen 

ZigBee-Netzwerk zu steuern. Die Aufgabenstellung fordert, dass keine Änderung an 

der Hard- oder Software der verwendeten Clientcomputer durchgeführt wird. 

Zur Ankopplung von Sensornetzwerken an IP-Netzwerke wurden mehrere Ansätze 

aufgezeigt. 

In dieser Arbeit wurde ein Prototyp auf Basis eines ” transparenten Proxy“ realisiert. 

Dieser vergibt für jedes ZigBee-Endgerät eine eigene IP-Adresse, über die die ZigBee- 

Endgeräte aus einem IP-Netzwerk ansprechbar sind. Allerdings antwortet nicht ein 

ZigBee-Endgerät direkt auf einen Anfrage, sondern ein zwischengeschalteter Proxyser- 

ver. Dieser setzt die Anfragen der Clients transparent um. Damit ist es für die Clients 

nicht ersichtlich, dass diese nicht mit dem ZigBee-Endgerät direkt kommuniziert. 

Der implementierte Prototyp besteht aus drei Programmen, die die Aufgaben Client, 

Proxyserver und Sensornetzwerk-Simulator erfüllen. Durch die Teilung sind für eine 

spätere Verbesserung einzelne Komponenten austauschbar. Alle drei Programme sind 

unter dem Betriebssystem Linux ausführbar. Mit Einschränkung der Funktionalität 

des Proxyservers sind alle drei Programme auch auf einem Apple Mac unter dem 

Betriebssystem OS X lauffähig. Eine Portierung auf Microsoft Windows wurde nicht 

vorgenommen, sollte aber aufgrund der Verwendung der Programmiersprache C++ 

und dem Verzicht auf graphische Frontends, leicht möglich sein. Allerdings unterstützt 

auch Windows, wie OS X, eine Adressmanipulation nicht in dem Maße, wie sie für die 

99 


100 7 Zusammenfassung 

Funktion des Proxyserver notwendig ist. 

Für die Kommunikation des einzelnen Programme wurde ein eigenes Protokoll auf 

Basis von XML entwickelt. Dieses ist erweiterbar. Momentan unterstützt der Proto- 

typ nur 6 verschiedene ZigBee-Endgerätetypen. Deren Funktionalität wurde allerdings 

nicht direkt in den Programmcode integriert, sondern wird durch mehrere Konfigurati- 

onsdateien realisiert. Damit ist der Prototyp offen für eine spätere Integration anderer 

ZigBee-Endgerätetypen. 

Es ist auch denkbar, nicht nur die ZigBee-Spezifikation, sondern auch andere Sen- 

sornetzwerktechnologien, zu unterstützen. Es ist allerdings zu prüfen, ob diese mit dem 

Format der Konfigurationsdateien abbildbar sind. 

Mit dem entwickelten Prototyp sind vielfältige Netzwerk-Topologien möglich. Je- 

der Proxyserver erlaubt eine Kopplung mehrerer Sensornetzwerk-Simulatoren und Cli- 

ents. Außerdem kann durch die Ankopplung anderer Instanzen des Proxyservers ein 

weitmaschiges Netzwerk aufgebaut werden. Die Daten einzelner Sensorknoten werden 

transparent durch die Proxyserver-Proxyserver-Verbindungen geleitet. Somit können 

alle verbundenen Clients auf alle Sensornetzwerke zugreifen. 

Durch die Verwendung eines VPN-Servers sind sogar Client-Proxyserver-Verbin- 

dungen über das Internet möglich. Im Internet dürfen die im Prototyp vergebenen 

IP-Adressen nicht verwendet werden, da diese aus dem privaten Adressbereich ge- 

wählt wurden. Hat man einen VPN-Tunnel zwischen den Computern, auf denen der 

Client und Proxyserver ausgeführt werden, aufgebaut, kann der Client auf die Knoten 

des vom Proxyserver verwalteten Sensornetzwerkes zugreifen. 


8 Ausblick 

Der im Rahmen dieser Diplomarbeit entwickelte Prototyp erlaubt eine Ankopplung 

eines Sensornetzwerkes an ein IP-basiertes Kommunikationssystem. Da kein reales 

Sensornetzwerk zur Verfügung stand, wurde ein Simulator erstellt. Dieser simuliert 

mehrere ZigBee-Endgeräte. 

Bei der Entwicklung des Clients und des Sensornetzwerk-Simulators wurde auf die 

Erstellung graphischer Frontends verzichtet. Beide Programme sind über die Komman- 

dozeile zu bedienen. Aus Usability-Sicht ist dies nicht immer von Vorteil. Daher sollten 

in einer späteren Ausbaustufe graphische Frontends für beide Komponenten entwickelt 

werden. 

Die Antwortzeiten im Prototypen sind sehr kurz. Löst ein Anwender eines Clients 

eine Statusänderung eines ZigBee-Endgerätes aus, wird diese Änderung fast augen- 

blicklich an das betreffende ZigBee-Netzwerk übergeben. Dort wird die Änderung, 

sofern sie sinnvoll erscheint, binnen kürzester Zeit eingepflegt. Eine Updatenachricht 

wird erstellt und an alle Komponenten des Prototyps verschickt. Der Anwender, der 

diese Änderung an einem Client ausgelöst hat, wird die Antwort innerhalb weniger 

Augenblicke erhalten. Der Prototyp ist skalierbar. In der Testumgebung wurde aller- 

dings nur ein sehr kleines Netzwerk realisert. In diesem wurden zwei Proxyserver, zwei 

Sensornetzwerke und wenige Clients ausprobiert. Es bleibt zu untersuchen, wie sich 

der Aufbau eines größeren Netzwerkes auf die Verarbeitungsgeschwindigkeit auswirkt. 

Die Komponente Sensornetzwerk-Simulator kann durch ein reales Sensornetzwerk 

ersetzt werden. Wie lange dann aber eine Änderungsbearbeitung eines Attributes eines 

Endgerätes dauert, ist im Moment nicht abzusehen. Es ist nicht bekannt, wie schnell 

ein reales Sensornetzwerk auf Eingaben reagiert. 

Durch die Integration anderer Protokolle der Vermittlungs-, Transport und Anwen- 

dungsschicht sind mit dem vorgestellten Ansatz vielfältige Möglichkeiten gegeben. So 

ist die Steuerung des Sensornetzwerkes durch die Eingabe einer IP-Adresse in einen 

Webbrowser vorstellbar. 

Das in Abschnitt 6.3 geschilderte Problem bei der Verwendung des TPROXY-Patches 

ist zu Untersuchen. 

101 


102 8 Ausblick 


Anhang 

103 


A Konfigurationsdateien 

Kommentare werden in den Konfigurationsdatein mit \\gekennzeichnet. Diese Kom- 

mentare dürfen in den Konfigurationsdateien nicht enthalten sein! Bei längeren Zeilen 

wird ein Umbruch durch das Zeichen \angezeigt. Die nächste Zeile wird dann nahtlos 

angefügt. 

Angaben des Ports beziehen sich auf das Protokoll TCP. 

A.1 ProxyServer 

OwnIP 192.168.0.190 \\ IP-Addresse des Proxyservers 

ClientPort 6000 \\ Client-Port verbinden 

ProxyPort 6001 \\ Proxyserver-Port verbinden 

SensorNetworkPort 6002 \\ Sensornetzwerk-Simulator-Port 

LoggingServerIP 127.0.0.1 \\ IP optionaler Logging Server 

LoggingServerPort 2500 \\ Port optionaler Logging Server 

ZigBeeMasterDeviceIP 10.8.1.1 \\ Adresse des ZigBee-Auskunftsdienst 

ProfilesFile profiles.conf \\ die Profil-Datei 

UserGroupFile usergroups.conf \\ die Anwendergruppen-Datei 

AuthManagerConfigFile authmanager.conf \\ die AuthManager-Datei 

ProxyManagerConfigFile proxymanager.conf \\ \\ die ProxyManager-Datei 

StandardConnectorTimeOut 86400 \\ der ConnectorTimeout in Sekunden 

UseTPROXY 0 \\ soll der TPROXY-Patch verwendet werden? 

Abbildung A.1: Proxyserver: Konfigurationsdatei main.conf 

105 


106 A Konfigurationsdateien 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

... weitere Anwender ... 

 

 

Abbildung A.2: Proxyserver: Konfigurationsdatei authmanager.conf. Neue Anwender 

können im XML-Knoten ValidUsers angelegt werden. 


A.1 ProxyServer 107 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

... weitere Proxyserver ... 

 

 

Abbildung A.3: Proxyserver: Konfigurationsdatei profiles.conf. Verbindungen zu 

anderen Proxyservern können im XML-Knoten Proxies angelegt werden. 

Dieser Proxyserver wird versuchen sich zu den hier angebenen 

Proxyservern verbinden. 



 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

... weitere Attributknoten der "BasicAttributes" ... 

 

 

 

 

 

 

 

 

 

 

 

 

... wird fortgesetzt ... 

Abbildung A.4: Proxyserver: Konfigurationsdatei profiles.conf. In dieser Datei sind 

alle bekannten ZigBee-Gerätetypen beschrieben. Die erstellte Konfigurationdatei 

für das Profile ” Home Control, Lighting“ ist über 1200 

Zeilen lang. Im Abschnitt C.1 wird die Benutzung der Attributknoten 

näher erläutert. 


A.1 ProxyServer 109 

... Forsetzung ... 

 

 

 

 

 

... weitere Attributknoten der "‘ExtendedAttributes"’ ... 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

... weitere Attribute des ZigBee-Gerätetyps "’Switch Remote Control"’ 

 

... weitere ZigBee-Gerätetypen 

 

 

Abbildung A.5: Proxyserver: Fortsetzung Konfigurationsdatei profiles.conf. 



 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

... weitere ZigBee-Endgeräte-Typen ... 

 

... weitere Anwendergruppen ... 

 

 

Abbildung A.6: Proxyserver: Auszug der Konfigurationsdatei usergroups.conf. Für 

jede Anwendergruppe können die abrufbaren Attribute der unterstützten 

ZigBee-Endgeräte angegeben werden. Im Abschnitt C.1 wird die 

Benutzung der Attributknoten näher erläutert. 


A.2 Sensornetzwerk-Simulator 111 

A.2 Sensornetzwerk-Simulator 

Hinweis: Die Datei profiles.conf wird auch vom Sensornetzwerk-Simulator verwen- 

det. Sie ist identisch mit der im Proxyserver verwendeten. Daher ist sie an dieser Stelle 

nicht nocheinmal aufgeführt. 

OwnIP 192.168.0.190 \\ IP-Adresse des SNW-Simulators 

OwnPort 7000 \\ Port des SNW-Simulators 

ProxyIP 192.168.0.190 \\ IP-Adresse des Proxyservers 

ProxyPort 6002 \\ Port des Proxyservers 

LoggingServerIP 127.0.0.1 \\ IP-Adresse optionaler Logging-Server 

LoggingServerPort 32002 \\ Port optionaler Logging-Server 

OwnUserName SensorNetz \\ Eigener Anwendername 

OwnPassword SensorNetz \\ Eigenes Passwort 

ProxyUserName Proxy \\ Proxyserver Anwendername 

ProxyPassword Proxy \\ Proxyserver Passwort 

ConfigFile sensornetwork.conf \\ Sensornetzwerk-Datei 

ProfilesFile profiles.conf \\ Profil-Datei 

BindingsFile profiles_bindings.conf \\ Bindings-Datei 

IP_Manual 0 \\ Manuelles Eingeben von IP-Adressen erlauben 

IP_fixedBits 16 \\ Die Netzwerk-ID 

IP_FirstTupel 10 \\ Das erste IP-Tupel 

IP_SecondTupel 8 \\ Das zweite IP-Tupel 

IP_ThirdTupel 10 \\ Das dritte IP-Tupel 

IP_FourthTupel 0 \\ Das erste IP-Tupel 

IP_ThirdTupelGap 5 \\ Aus 10.8.5.1 bis 10.8.10.254 IP vergeben 

StandardConnectorTimeOut 86400 \\ maximale Lebensdauer 

Abbildung A.7: Sensornetzwerk-Simulator: Konfigurationsdatei main.conf 



 

 

 

 

\ 

 

\ 

 

 

 

 

 

 

 

 

 

 

 

 

 

\ 

 

 

... weitere "BindingDescription" ... 

 

 

Abbildung A.8: Sensornetzwerk-Simulator: Konfigurationsdatei 

profiles_binding.conf. Für jedes unterstützte Endgerät kann angegeben, 

zu welchen anderen Endgeräten ein “Binding“ durchgeführt 

werden kann. 


A.2 Sensornetzwerk-Simulator 113 

 

 

 

 

 

\ 

 

 

\ 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

... viele Attribute ... 

 

 

 

 

... weitere Attribute ... 


A.3 Client 

OwnIP 192.168.0.190 \\ IP-Adresse des Clients 

OwnPort 25020 \\ Port des Clients 

ZigBeeMasterIP 10.8.1.1 \\ IP-Adresse des ZigBee-Auskunftsdienst 

ZigBeeMasterPort 6000 \\ Port des ZigBee-Auskunftsdienst 

ZigBeeUserName Proxy \\ Proxyserver Anwendername 

ZigBeePassword Proxy \\ Proxyserver Passwort 

UseTPROXY 0 \\ soll der TPROXY-Patch verwendet werden? 


Abbildung A.10: Client: Konfigurationsdatei main.conf

B Kommunikationsprotokoll 

B.1 Vorbetrachtung 

Das entwickelte Kommunikationsprotokoll wurde auf Basis der Extensible Markup 

Language (XML) enwickelt. Einige Nachrichten können aufgrund ihre Größe hier nicht 

vollständig angezeigt werden. Entsprechende Anmerkungen wurden in die Darstellun- 

gen eingefügt. Die Inhalte der Nachrichten ResponseAllSensorNetworkData, 

ResponseCommandGET, RequestCommandSET und UpdateDeviceAttribut entsprechen 

im wesentlichen den Konfigurationsdateien profiles.conf und sensornetwork.conf. 

115 


116 B Kommunikationsprotokoll 

B.2 Authentifizierung 

 

 

 

 

 

 

 

Abbildung B.1: ClientSendUserData: Der Server fordert die Anwenderdaten vom Client 

an. 

 

 

 

 

 

 

 

 

 

Abbildung B.2: ClientUserData: Der Client sendet seine Anwenderdaten 

 

 

 

 

 

 

 

 

 

 

Abbildung B.3: ServerUserData: Der Server sendet seine Anwenderdaten 


B.2 Authentifizierung 117 

 

 

 

 

 

 

 

Abbildung B.4: AuthSuccess: Die Anwenderdaten konnten von einem Kommunikationspartner 

erfolgreich überprüft werden. Die Verbindung wird erst 

zum Datentransport freigegeben, wenn beide Kommunikationspartner 

diese Nachricht versendet und empfangen haben. 

 

 

 

 

 

 

 

Abbildung B.5: AuthFailed: Die Anwenderdaten konnten von einem Kommunikationspartner 

nicht bestätigt werden. Die Verbindung wird abgebaut. 

 

 

 

 

 

 

 

 

Abbildung B.6: SetDeviceID: Der Empfänger soll die angegebene DeviceID verwenden. 



B.3 Setup 

 

 

 

 

 

 

 

Abbildung B.7: LogOut: Die Verbindung soll abgebaut werden, aber der betreffende 

Connector (Proxyserver)lebendig gehalten werden. 

 

 

 

 

 

 

 

Abbildung B.8: LogOutAndTerminate: Die Verbindung soll abgebaut werden. Der betreffende 

Connector (Proxyserver) kann terminiert werden. 

 

 

 

 

 

 

 

 

 

Abbildung B.9: LogOutAndSetCallBack: Diese Nachricht wird vom Client an den 

Proxyserver versendet. Dieser soll einen Rückruf (CallBack) starten, 

wenn einem Ereignis auftritt, welches diesen Client interessiert. Die 

verwendeten Quell-Adressdaten entsprechen denen des Endgerätes, an 

dem der Client momentan angemeldet ist. 


B.3 Setup 119 

 

 

 

 

 

 

 

Abbildung B.10: RequestAllSensorNetworkData. Diese Nachricht wird vom Proxyserver 

an den Sensornetzwerk-Simulator und an andere Proxyserver 

versendet. Als Antwort wird eine ResponseAllSensorNetworkData- 

Nachricht erwartet. 



 

 

 

 

\ 

 

 

 

 

 

 

 

 

 

 

... viele Attribute ... 

 

 

 

... weitere Attribute ... 

 

... weitere ZigBee-Endgeräte ... 

 

 

Abbildung B.11: ResponseAllSensorNetworkData: Antwort auf 

RequestAllSensorNetworkData-Nachricht. Der Inhalt bildet alle im 

Sender bekannten ZigBee-Endgeräte ab. 


B.3 Setup 121 

 

 

 

 

 

 

 

 

Abbildung B.12: ProfileUnknown: Wurde eine 

ResponseAllSensorNetworkData-Nachricht empfangen, wird diese 

im Proxyserver ausgewertet. Wird ein ZigBee-Endgerät übermittelt, 

dessen Profil diesem Proxyserver nicht bekannt ist, wird die 

ProfileUnknown-Nachricht an den Sender zurückgesendet. Die IP- 

Adresse des betreffenden Endgerätes ist angegeben. 

 

 

 

 

 

 

 

 

Abbildung B.13: DeviceIPAllreadyAssigned: Wurde eine 

ResponseAllSensorNetworkData-Nachricht empfangen, wird diese 

im Proxyserver ausgewertet. Wird ein ZigBee-Endgerät übermittelt, 

dessen verwendete IP-Adresse in diesem Proxyserver schon vergeben 

wurde, wird die DeviceIPAllreadyAssigned-Nachricht an den Sender 

zurückgesendet. Die IP-Adresse des betreffenden Endgerätes ist 

angegeben. Das betreffende Endgerät wird aus der Endgeräteliste des 

Proxyservers gelöscht. Entsprechende Nachrichten über diese Endgerät 

werden ignoriert. 



 

 

 

 

 

 

 

 

Abbildung B.14: SetInteresstedDeviceIP: Ein Client übermittelt die Adresse des 

Endgerätes, über dessen Statusänderungen er informiert werden soll. 

Der Proxyserver wird darauf hin an das Sensornetzwerk Nachrichten 

vom Typ RequestCommandGET (Siehe Abbildung B.15) versenden. Dabei 

werden nur die Attribute des betreffenden Endgerätes angefordert, 

für die Anwendender des Clients freigeschaltet ist. 


B.4 Service 123 

B.4 Service 

 

 

 

 

 

 

 

 

 

Abbildung B.15: RequestCommandGET: Nachdem sich ein Client am Proxyserver angemeldet 

hat (Siehe Abbildung B.14), wird der Proxyserver die Attribute 

des Endgerätes vom Sensornetzwerk-Simulator anfordern. Dabei 

werden nur die Attribute angefordert, für die der Anwender freigeschaltet 

ist. Als Antwort wird eine ResponseCommandGET-Nachricht 

mit dem angeforderten Attribut erwartet. 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Abbildung B.16: ResponseCommandGET: Antwort des Sensornetzwerk-Simulators auf 

eine RequestCommandGET-Nachricht des Proxyservers. Dieser leitet 

die Nachricht an den Client weiter. 



 

 

 

 

 

 

 

 

Abbildung B.17: AllResponseCommandGETSended: Wurden von einem Proxyserver 

alle ResponseCommandGET-Nachrichten an den Client übermittelt, 

für die dieser freigeschaltet ist, wird der Proxyserver die 

AllResponseCommandGETSended-Nachricht an den Client senden. 

Dieser wird darauf hin dem Anwender anzeigen, dass eine Verbindung 

erfolgreich aufgebaut werden konnte. Der Anwender kann dann 

mit dem Endgerät interagieren und entsprechende Aktionen ausführen. 

 

 

 

 

 

 

 

 

Abbildung B.18: RequestZigBeeDeviceList: Ein Client hat sich zum ZigBee- 

Auskunftsdienst verbunden. Diese Nachricht fordert die Liste aller 

im Proxyserver bekannten Endgeräte an. Als Antwort wird eine 

ResponseZigBeeDeviceList-Nachricht erwartet. 



 

 

 

 

 

 

 

 

 

 

 

 

\ 

 

 

 

 

 

\ 

 

 

 

 

 

 

 

 

 

 

Abbildung B.19: RequestCommandSET: Ein Client will eine Attributänderung anzeigen. 

Der Proxyserver wird diese Nachricht an den Sensornetzwerk- 

Simulator weiterleiten. Dort wird überprüft ob die Änderung durchgeführt 

werden kann. Ist dies möglich, wird der Sensornetzwerk- 

Simulator eine UpdateDeviceAttribute-Nachricht mit der übernommenen 

Änderung aussenden. 

Im Abschnitt C.1 wird die Benutzung der Attributknoten näher erläutert. 



 

 

 

 

 

 

 

 

 

 

 

 

 

\ 

 

 

 

 

 

\ 

 

 

\ 

 

\ 

 

 

 

 

 

 

 

Abbildung B.20: UpdateDeviceAttribute: Diese Nachricht wird generiert, wenn ein 

Attribut eines Endgerätes im Sensornetzwerk-Simulator verändert 

wurde. Diese Änderung kann durch drei Ereignisse bedingt sein: 

1. Ein Client hat eine RequestCommandSET-Nachricht geschickt. Diese 

Attributänderung konnte ausgeführt werden. 

2. Eine Attributänderung wird durch die Attributänderung eines anderen 

Endgerätes notwendig. 

3. Im Sensornetzwerk-Simulator wird eine Attributänderung vom Bediener 

vorgenommen. 

Im Abschnitt C.1 wird die Benutzung der Attributknoten näher erläutert. 



 

 

 

 

 

 

 

 

 

 

 

 

 

... weitere Device-Einträge ... 

 

 

Abbildung B.21: ResponseZigBeeDeviceList: Wurde ein 

RequestZigBeeDeviceList-Nachricht empfangen kann mit dieser 

Nachricht die Liste aller bekannten Endgeräte übermittelt werden. 




C Darstellung der ZigBee-Attribute 

im Prototyp 

C.1 Attribute 

Zur Darstellung der durch die ZigBee-Alliance vorgegebenen Profilbeschreibungen wur- 

den diese in den entsprechenden Konfigurationsdateien eingepflegt (Siehe Abschnitte 

A.4 und A.9). An dieser Stelle soll die Bedeutung der Attribute aufgezeigt werden. 

Prinzipiell sind zwei Attributtypen möglich: Einige Attribute können beliebige Wer- 

te annehmen. Diese Werte könnten vom Typ ” string“, ” integer“, ” date“ und ” bool“ 

sein. Zusätzlich werden die Typen ‘bitset’ und ‘bitset’ unterstützt, die 

allerdings in den Konfigurationsdateien bislang nicht verwendet werden. Bei dem an- 

dereren Attributtyp können nur festgelegte Werte eingenommen werden. Oft ist eine 

Auswahl von drei oder mehr Optionen möglich. 

In in Abbildung C.1 ist ein einfaches Attribut dargestellt, welches einen beliebigen 

Wert annehmen kann. 

 

 

 

 

 

 

 

 

 

 

Abbildung C.1: Ein Attribut mit beliebigen Werten 

129 


130 C Darstellung der ZigBee-Attribute im Prototyp 

Die einzelnen Einträge haben die folgenden Bedeutungen: 

AttributeID : Der Name des Attributes. 

AttributeDescription : Die Beschreibung des Attributes. 

AttributeUnit : Die Einheit des Attributes. Diese ist nur gesetzt bei Attributen deren 

Werte vom Typ “integer“ sind. 

AttributeCurrentValue : Der momentane Wert des Attributes. Das zweite XML- 

Node-Attribut “type“ gibt den Typ des Wertes dieses Attributes wieder. 

AttributeDirectionINPUT : Dieser ” Bool“ gibt an, ob sich ein Attribut aufgrund ex- 

terner Attributänderung anpasst. 

AttributeDirectionOUTPUT : Dieser ” Bool“ gibt an, ob ein Attribut nach einer Än- 

derung an andere Geräte gemeldet werden soll. 

CommandGET : Ist ein solcher Eintrag vorhanden, kann das Attribut extern abgefragt 

werden. Als Zusatz wird der Name des Attributes angehängt. 

CommandSET : Ist ein solcher Eintrag vorhanden, kann das Attribut extern gesetzt wer- 

den. Als Zusatz wird der Name des Attributes angehängt. 

Abbildung C.2 zeigt ein Attribut, welches fest vorgegeben Werte unterstützt. 

 

 

 

 

\ 

 

 

 

 

 

 

 

 

 

 

 


Abbildung C.2: Ein Attribut mit optionalen Werten

C.1 Attribute 131 

Die Bedeutung der Einträge AttributeID, AttributeDescription, AttributeUnit, 

AttributeCurrentValue AttributeDirectionINPUT, 

AttributeDirectionOUTPUT, CommandGET und CommandSET entsprechen den schon auf- 

gezeigten Einträgen. Zusätzlich werden die Einträge AttributeValue und 

AttributeValueDescription verwendet. 

AttributeValue bezeichnet eine Option und ihren Wert. Dazu muss ein entspre- 

chender AttributeValueDescription Eintrag vorhanden sein, dem der Wert des 

AttributeValue angehängt ist. Wird im Prototyp ein solches Paar gefunden, werden 

dieses als Auswahlmöglichkeit angegeben. 


132 C Darstellung der ZigBee-Attribute im Prototyp 


D Installation des Prototyps 

Der Client, der Proxyserver und der Sensornetzwerk-Simulator müssen vor Benutzung 

auf dem eigenen Computer installiert und aus den Quelltexten übersetzt werden. Es 

bietet sich an, die mitgelieferten Projekt zu verwenden. Für ein Linux-System wurde 

ein Projekt der IDE KDevelop mitgeliefert. In diesem kann die Übersetzung gestar- 

tet werden und das entsprechende Programm anschliessend gestartet werden. Unter 

einem Mac mit dem Betriebssystem Mac OS X können die Programme direkt in die 

Entwicklungsumgebung Xcode integriert werden. 

Will man die Quelldateien von Hand compilieren, muss beachtet werden dass ei- 

nige Linker- und C-Flags gesetzt werden müssen, da die Bibliothek ” libxml2“ zur 

Verarbeitung der XML-Daten verwendet wurde. Diese Flags können sich unterschei- 

den. Hat man diese Bibliothek installiert, kann man durch Eingabe des Kommandos 

xml2-config das in den Abbildungen D.1 und D.2 gezeigt ist, die Flags in Erfahrung 

bringen und entsprechend anwenden. 

equinox:~ jeanluc$ xml2-config --libs 

-L/sw/lib -lxml2 -lz -lpthread -L/sw/lib -liconv -lm 

equinox:~ jeanluc$ 

Abbildung D.1: Ermittlung der Linker-Flags 

equinox:~ jeanluc$ xml2-config --cflags 

-I/sw/include/libxml2 -I/sw/include 

equinox:~ jeanluc$ 

Abbildung D.2: Ermittlung der Linker-Flags 

Nun können die Programme installiert werden und die Konfigurationsdateien ent- 

sprechend angepasst werden. Die Adressangaben müssen mit den eigenen Gegebenhei- 

ten abgeglichen werden. Zur Funktion des Proxyservers muss der TPROXY-Patch wie 

in Abschnitt 4.2.3 installiert werden. Dazu muss allerdinge der Kernel neu übersetzt 

werden, was nur dem geübten Anwender empfohlen wird. 

133 


134 D Installation des Prototyps 

Ohne diesen Patch sind keine ausgehenden Verbindungen mit einer falschen IP- 

Adresse möglich (CallBack). 

Schliesslich müssen noch die iptables-Kommandos wie in Abschnitt 4.2.2 (entspre- 

chend angepasst) eingegeben werden. 

Anschliessen können die Programme durch Eingabe von “pussinboots main.conf“, 

“redridinghood main.conf“ und “snowwhite main.conf“ 1 gestartet werden. Einem 

ausgiebigen Test sollte nun nichts mehr im Wege stehen. Abbildung D.3, zeigt den 

Start des Proxyservers. 

1 Die einzelnen Programmkomponenten wurden bei der Entwicklung mit Codenamen versehen. PussInBoots 

(der gestiefelte Kater) ist der Name des Proxyservers. RedRidingHood (Rotkäppchen) 

erfüllt die Funktionalität des Sensornetzwerk-Simulators. Schließlich ist Snowwhite (Schneewittchen) 

der erstellte Client. Der Autor dieser Arbeit hatte zuerst angedacht, das entwickelte Protokoll 

BGP zu nennen: das ” Brothers Grimm Protocol“. Aufgrund der Verwendung dieser Abkürzung 

für das ” Border Gateway Protocol“, wurde aber davon abgesehen. 


equinox:~ jeanluc$ pussinboots main.conf 

jeanluc$ ./pussinboots main.conf 

ProxyServer gestartet 

Versuche Config-Datei main.conf einzulesen... 

Betrete Hauptschleife 

Main: Versuche ConfigFiles einzulesen 

C_AddressBook::readProfilesFile(): Profil-Datei erfolgreich \ 

eingelesen, Versuche zu interpretieren... 

C_AddressBook::readProfilesFile(): BasicAttributes gefunden 

C_AddressBook::readProfilesFile(): ExtendedAttributes gefunden 

C_AddressBook::readProfilesFile(): Profil: ’Switch Remote Control’, \ 

’Home Control, Lighting’ zur ProfilListe hinzugefuegt 

C_AddressBook::readProfilesFile(): Profil: ’Switching Load Controller’, \ 


C_AddressBook::readProfilesFile(): Profil: ’Occupancy Sensor’, \ 


C_AddressBook::readProfilesFile(): Profil: ’Light Sensor Monochromatic’, \ 


C_AddressBook::readProfilesFile(): Profil: ’Dimmer Remote Control’, \ 


C_AddressBook::readProfilesFile(): Profil: ’Dimming Load Controller’, \ 


C_AddressBook::readUserGroupFile(): UserGroup ’Insane’ hinzugefuegt. 

C_AddressBook::readUserGroupFile(): UserGroup ’Normal User’ hinzugefuegt. 

C_AuthManager::readConfigFile(): ConfigFile erfolgreich eingelesen! 

ClientManager::run(): ClientManager gestartet 

ProxyManager::run(): ProxyManager gestartet 

SensorNetworkManager::run(): SensorNetworkManager gestartet 

ProxyManager::readConfigFile: ConfigFile erfolgreich eingelesen! 

Abbildung D.3: Programmausgabe nach Start des Proxyservers 

135 


136 D Installation des Prototyps 



Literaturverzeichnis 

[AlGS99] D. S. Alberts, J. J. Garska und F. P. Stein. Network Centric Warfa- 

re: Developing and Leveraging Information Superiority. http://www. 

dodccrp.org/publications/pdf/Alberts_NCW.pdf, 1999. 

[Appl] Apple Computer Inc. Xcode. Xcode 2.2 is Apple’s tool suite and integra- 

ted development environment (IDE) for creating Mac OS X universal 

binaries that run natively on PowerPC and Intel-based Macintosh com- 

puters. http://developer.apple.com/tools/xcode/. 

[Berl] CST Group FU Berlin. Scatterweb Embedded Sensor Board. http: 

//www.scatterweb.com. 

[ChKu03] Chee-Yee Chong und Srikanta P. Kumar. Sensor Networks: Evolution, 

Opportunities and Challenges. In Proceedings of the IEEE, Band 91. 

IEEE, August 2003, S. 1247–1256. 

[Cros] Crossbow Technology Inc. Crossbow. Crossbow Technology Inc., www. 

xbow.com. 

[DaZi83] J.D Day und H. Zimmermann. The OSI Reference Model. In Proceedings 

of the IEEE, Band 71. IEEE, 1983, S. 1334–1340. 

[DeNP99] M. Degermark, B. Nordgren und S. Pink. RFC 2507: IP Header Com- 

pression, Februar 1999. Status: PROPOSED STANDARD. 

[DFGV04] Adam Dunkels, Laura Marie Feeney, Björn Grönvall und Thiemo Voigt. 

An integrated approach to developing sensor network solutions. In 

Proceedings of the Second International Workshop on Sensor and Ac- 

tor Network Protocols and Applications, Boston, Massachusetts, August 

2004. 

[Doyl99] Jeff Doyle. Routing TCP/IP: umfassendes Handbuch zu allen internen 

Routing-Protokollen. Cisco Press (Markt und Technik), München. 1999. 


138 Literaturverzeichnis 

[DuAV04] Adam Dunkels, Juan Alonso und Thiemo Voigt. Making TCP/IP Via- 

ble for Wireless Sensor Networks. Proceedings of the First European 

Workshop on Wireless Sensor Networks (EWSN’04), work-in-progress 

session, Berlin, 2004. 

[Dunk03] Adam Dunkels. Full TCP/IP for 8-Bit Architectures. In Proceedings 

of The First International Conference on Mobile Systems, Applications, 

and Services (MOBISYS ‘03), San Francisco, 2003. 

[Dura01] A. Durand. Deploying IPv6. In IEEE Internet Computing, Band 5. 

IEEE, Januar/Februar 2001, S. 79–81. 

[EgFr94] K. Egevang und P. Francis. The IP Network Address Translator (NAT). 

RFC 1631 (Informational), Mai 1994. Obsoleted by RFC 3022. 

[EsRGK99] D. Estrin, J. Heidemann R. Govindan und S. Kumar. Next Century 

Challenges: Scalable Coordination in Sensor Networks. In Proceedings 

of the ACM/IEEE Internation Conference on Mobile Computing and 

Networking, Seattle, WA, August 1999. S. 263–270. 

[Ethe] Ethereal Inc. Ethereal Ethereal. http://www.ethereal.com. 

[FLYV93] V. Fuller, T. Li, J. Yu und K. Varadhan. Classless Inter-Domain Routing 

(CIDR): an Address Assignment and Aggregation Strategy. RFC 1519 

(Proposed Standard), September 1993. 

[GmbH] ProSyst GmbH. ProSyst. http://www.prosyst.com. 

[IANA] IANA, http://www.iana.org/assignments/port-numbers. Assigne- 

ment of Port Numbers. 

[IEEE] IEEE. Guidelines for 64-BIT global itentifier (EUI-64) Registration 

Authority. http://standards.ieee.org/regauth/oui/tutorials/ 

EUI64.html. 

[Inst] Institute of Electrical and Electronics Engineers. IEEE Homepage on 

802.15 (WPAN). IEEE, http://www.ieee802.org/15/pub/TG4.html. 

[Jaco90] V. Jacobson. RFC 1144: Compressing TCP/IP headers for low-speed 


serial links, Februar 1990. Status: PROPOSED STANDARD.


[kdev] kdevelop.org. KDevelop. KDE Development Environment. http:// 

www.kdevelop.org/. 

[LCCK + ] Barry M. Leiner, Vinton G. Cerf, David D. Clark, Robert E. Kahn, 

Leonard Kleinrock, Daniel C. Lynch, Jon Postel, Lawrence G. Roberts 

und Stephen Wolff. A Brief History of the Internet. 

[LeCo81] V. R. Lesser und D. D. Corkill. Functionally accurate, cooperative 

distributed systems. In IEEE Transactions on Systems, Man, and Cy- 

bernetics, Band 11. IEEE, Januar/Februar 1981, S. 81–96. 

[Mock87] P.V. Mockapetris. Domain names - concepts and facilities. RFC 1034 

(Standard), November 1987. Updated by RFCs 1101, 1183, 1348, 1876, 

1982, 2065, 2181, 2308, 2535, 4033, 4034, 4035, 4343. 

[MPSC + 02] Alan Mainwaring, Joseph Polastre, Robert Szewczyk, David Culler und 

John Anderson. Wireless Sensor Networks for Habitat Monitoring. In 

ACM International Workshop on Wireless Sensor Networks and Appli- 

cations (WSNA’02), Sep 2002. 

[netf] netfilter.org. Netfilter. Firewalling, NAT, and packet mangling for Li- 

nux. netfilter.org, http://www.netfilter.org. 

[NiCo94] C.E. Nishimura und D.M. Conlon. IUSS dual use: Monitoring whales 

and earthquakes using SOSUS. In Marine Technology Society Journal, 

Band 27, 1994, S. 13–21. 

[Open] OpenVPN Solutions LLC. OpenVPN. http://openvpn.net/. 

[Org.] Kernel Org. Linux. The Kernel Org. Organization, Inc., http:// 

kernel.org. 

[OSGia] OSGi-Alliance. OSGi-Alliance. OSGi-Alliance, http://osgi.org. 

[OSGib] OSGi-Alliance. OSGi-Alliance Members. OSGi-Alliance, http://osgi. 

org/about/member_list.asp?section=1. 

[PiKa] Kris Pister, Joe Kahn und Bernhard Boser et al. Smart Dust - Autono- 

mous sensing and communication in a cubic millimeter. University of 

California Berkeley, http://robotics.eecs.berkeley.edu/~pister/ 

SmartDust/. 



[Post80] J. Postel. User Datagram Protocol. RFC 768 (Standard), August 1980. 

[Post81a] J. Postel. Assigned numbers. RFC 790 (Historic), September 1981. 

Obsoleted by RFC 820. 

[Post81b] J. Postel. Internet Protocol. RFC 791 (Standard), September 1981. 

Updated by RFC 1349. 

[Post81c] J. Postel. Transmission Control Protocol. RFC 793 (Standard), Sep- 

tember 1981. Updated by RFC 3168. 

[proc78] Proceedings of the Distributed Sensor Nets Workshop. Department of 

Computing Science, Carnegie Mellon Unversity, 1978. 

[RMKG94] Y. Rekhter, B. Moskowitz, D. Karrenberg und G. de Groot. Address 

Allocation for Private Internets. RFC 1597 (Informational), März 1994. 

Obsoleted by RFC 1918. 

[Schi03] Jochen Schiller. Mobilkommunikation. Pearson Studium. 2. Auflage, 

2003. 

[ScKo] Balazs Schneider und Krisztian Kovacs. TPROXY. This page is dedi- 

cated to our efforts of creating a transparent proxy solution portable ac- 

cross several operating systems. http://www.balabit.com/products/ 

oss/tproxy/. 

[SiSa03] Slobodan Simic und Shankar Sastry. Distributed Environmental Moni- 

toring Using Random Sensor Networks. In IPSN, 2003, S. 582–592. 

[Sun] Sun. Sun Developer Network. Sun, http://java.sun.com. 

[Tane03] Andrew Tanenbaum. Computernetzwerke. Pearson Studium. 4. Auflage, 

2003. 

[TavS03] Andrew Tanenbaum und Marten van Steen. Verteilte Systeme: Grund- 

lagen und Paradigmen. Pearson Studium. 1. Auflage, 2003. 

[Team95] Johns Hopkins APL Team. The cooperative engagement capability. 

Johns Hopkins Applied Physics Laboratory Technical Digest Band 4, 

1995. 

[UC Ba] UC Berkeley. TinyDB. University of California Berkeley, http: 


//telegraph.cs.berkeley.edu/tinydb/screenshots.htm.


[UC Bb] UC Berkeley. TinyOS. University of California Berkeley, www.tinyos. 

net. 

[W3C] W3C. Extensible Markup Language (XML). World Wide Web Consor- 

tium, http://www.w3.org/XML/. 

[WaCh02] D.W. Waddington und F. Chang. Realizing the Transition to IPv6. In 

IEEE Communications Magazine, Band 40. IEEE, Juni 2002, S. 138– 

148. 

[Weis01] Marc Weiser. Whatever Happended to the Next Generation Internet? 

In Communication of the ACM, Band 44, September 2001, S. 61–68. 

[Whit05] Edward C. Whitman. SOSUS - The Secret Weapon of Undersea Sur- 

veillance, 2005. 

[WHRBS + 81] R. B. Wesson, F.A. Hayes-Roth, J. W. Burge, C. Stasz und C. A. Suns- 

hine. Network structures for distributed situation assessment. In IEEE 

Transactions on Systems, Man, and Cybernetics, Band SMC-11. IEEE, 

Januar/Februar 1981, S. 5–23. 

[Wilj02] J. Wiljakka. Transition to IPv6 in GPRS and WCDMA Mobile Net- 

works. In IEEE Communications Magazine, Band 40. IEEE, April 2002, 

S. 134–140. 

[ZhGu04] Feng Zhao und Leonidas Guibas. Wireless Sensor Networks. Morgan 

Kaufmann Publisher. 1. Auflage, 2004. 

[Zieg03] Robert Ziegler. Linux-Firewalls. Konzeption und Implementierung für 

Netzwerke und PCs. Markt+Technik. 2003. 

[ZigB] ZigBee Alliance. The Hompeage of the the ZigBee Alliance. http: 

//www.zigbee.org. 





Abbildungsverzeichnis 

2.1 Das Internet-Referenzmodell . . . . . . . . . . . . . . . . . . . . . . . . 6 

2.2 Datenkapselung am Beispiel des Internetreferenzmodells . . . . . . . . . 8 

2.3 Vergleich zwischen herkömmlicher Briefpost und IP-Paketvermittlung . 10 

2.4 Header eines IPv4-Paketes . . . . . . . . . . . . . . . . . . . . . . . . . 11 

2.5 Routing im Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 

2.6 Klassenbasierte IP-Adressierung . . . . . . . . . . . . . . . . . . . . . . 16 

2.7 Der TCP-Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 

2.8 Network Address Translation im Einsatz . . . . . . . . . . . . . . . . . 23 

2.9 Mehrfaches Abrufen einer Webseite . . . . . . . . . . . . . . . . . . . . 26 

2.10 Die Arbeitsweise eines Webproxys . . . . . . . . . . . . . . . . . . . . . 27 

3.1 Mögliche Topologien in ZigBee-Netzen . . . . . . . . . . . . . . . . . . 35 

3.2 Der ZigBee-Protokollstapel . . . . . . . . . . . . . . . . . . . . . . . . . 36 

3.3 Endpunkte in ZigBee . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 

3.4 Die Anwendungsschicht im ZigBee Protokollstapel . . . . . . . . . . . . 39 

4.1 Mögliche Ansätze zur Kopplung von Systemen . . . . . . . . . . . . . . 43 

4.2 Spatial IP-Address Assignment . . . . . . . . . . . . . . . . . . . . . . 45 

4.3 OSGi Framework Architektur für OSGi Anwendungen . . . . . . . . . . 47 

4.4 Kommunikation zwischen Endgeräten mit einem OSGi-Gateway . . . . 48 

4.5 Anfrage an ein Sensornetzwerk mit TinyDB . . . . . . . . . . . . . . . 49 

4.6 Visualisierung von Sensordaten mit TinyDB . . . . . . . . . . . . . . . 50 

4.7 Einsatz eines transparenten Proxyservers . . . . . . . . . . . . . . . . . 52 

4.8 Paketbehandlung mit Netfilter . . . . . . . . . . . . . . . . . . . . . 53 

4.9 Aufruf eines iptables-Kommandos . . . . . . . . . . . . . . . . . . . . 55 

5.1 Die Struktur des Prototyps . . . . . . . . . . . . . . . . . . . . . . . . . 59 

5.2 Auszug aus einer XML-Datei . . . . . . . . . . . . . . . . . . . . . . . 64 

5.3 Auszug aus einer XML-Datei . . . . . . . . . . . . . . . . . . . . . . . 65 

5.4 Die abstrakte Datendarstellung . . . . . . . . . . . . . . . . . . . . . . 66 


144 Abbildungsverzeichnis 

5.5 Der Ablauf der Authentifizerung . . . . . . . . . . . . . . . . . . . . . . 67 

5.6 Die Struktur des Proxyservers . . . . . . . . . . . . . . . . . . . . . . . 69 

5.7 Der Weg einer eingehenden Nachricht . . . . . . . . . . . . . . . . . . . 73 

5.8 Der Weg einer ausgehenden Nachricht . . . . . . . . . . . . . . . . . . . 74 

5.9 Die Struktur des Sensornetzwerk-Simulators . . . . . . . . . . . . . . . 78 

5.10 Programmausgabe: Auswahl des Typs eines ZigBee-Endgerätes . . . . . 79 

5.11 Programmausgabe: Änderung eines Attributes bei der Konfiguration . . 79 

5.12 Programmausgabe: Binding-Tabelle konfigurieren . . . . . . . . . . . . 80 

5.13 Binding-Information in der Konfigurationsdatei . . . . . . . . . . . . . 80 

5.14 Programmausgabe: Auswahlmenu nach Start des Sensornetzwerkes . . 81 

5.15 Programmausgabe: Änderung eines Attributes im laufenden Betrieb . . 82 

5.16 Die Struktur des Clients . . . . . . . . . . . . . . . . . . . . . . . . . . 83 

5.17 Programmausgabe: Startmenu des Clients . . . . . . . . . . . . . . . . 83 

5.18 Programmausgabe: Optionen-Menu im Client nach erfolgreicher Verbin- 

dung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 

5.19 Anzeige einer Attributänderung . . . . . . . . . . . . . . . . . . . . . . 85 

5.20 Programmausgabe: Rückruf durch ein Engerät . . . . . . . . . . . . . . 85 

5.21 VPN-Verbindung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 

5.22 Mögliche Netztopologien des Prototyps . . . . . . . . . . . . . . . . . . 89 

A.1 Proxyserver: Konfigurationsdatei main.conf . . . . . . . . . . . . . . . 105 

A.2 Proxyserver: Konfigurationsdatei authmanager.conf . . . . . . . . . . 106 

A.3 Proxyserver: Konfigurationsdatei profiles.conf . . . . . . . . . . . . 107 

A.4 Proxyserver: Konfigurationsdatei profiles.conf . . . . . . . . . . . . 108 

A.5 Proxyserver: Fortsetzung Konfigurationsdatei proxymanager.conf . . . 109 

A.6 Proxyserver: Auszug Konfigurationsdatei usergroups.conf . . . . . . . 110 

A.7 Sensornetzwerk-Simulator: Konfigurationsdatei main.conf . . . . . . . 111 

A.8 Sensornetzwerk-Simulator: Konfigurationsdatei profiles_binding.conf 112 

A.9 Sensornetzwerk-Simulator: Konfigurationsdatei sensornetwork.conf . 113 

A.10 Client: Konfigurationsdatei main.conf . . . . . . . . . . . . . . . . . . 114 

B.1 Authenticating: ClientSendUserData . . . . . . . . . . . . . . . . . . . 116 

B.2 Authenticating: ClientUserData . . . . . . . . . . . . . . . . . . . . . 116 

B.3 Authenticating: ServerUserData . . . . . . . . . . . . . . . . . . . . . 116 

B.4 Authenticating: AuthSuccess . . . . . . . . . . . . . . . . . . . . . . . 117 

B.5 Authenticating: AuthSuccess . . . . . . . . . . . . . . . . . . . . . . . 117 

B.6 Authenticating: SetDeviceID . . . . . . . . . . . . . . . . . . . . . . . 117 



B.7 Setup: LogOut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 

B.8 Setup: LogOutAndTerminate . . . . . . . . . . . . . . . . . . . . . . . . 118 

B.9 Setup: LogOutAndSetCallBack . . . . . . . . . . . . . . . . . . . . . . 118 

B.10 Setup: RequestAllSensorNetworkData . . . . . . . . . . . . . . . . . . 119 

B.11 Setup: ResponseAllSensorNetworkData . . . . . . . . . . . . . . . . . 120 

B.12 Setup: ProfileUnknown . . . . . . . . . . . . . . . . . . . . . . . . . . 121 

B.13 Setup: DeviceIPAllreadyAssigned . . . . . . . . . . . . . . . . . . . . 121 

B.14 Setup: SetInteresstedDeviceIP . . . . . . . . . . . . . . . . . . . . . 122 

B.15 Service: RequestCommandGET . . . . . . . . . . . . . . . . . . . . . . . . 123 

B.16 Service: ResponseCommandGET . . . . . . . . . . . . . . . . . . . . . . . 123 

B.17 Service: AllResponseCommandGETSended . . . . . . . . . . . . . . . . . 124 

B.18 Service: RequestZigBeeDeviceList . . . . . . . . . . . . . . . . . . . . 124 

B.19 Service: RequestCommandSET . . . . . . . . . . . . . . . . . . . . . . . . 125 

B.20 Service: UpdateDeviceAttribute . . . . . . . . . . . . . . . . . . . . . 126 

B.21 Service: ResponseZigBeeDeviceList . . . . . . . . . . . . . . . . . . . 127 

C.1 Ein Attribut mit beliebigen Werten . . . . . . . . . . . . . . . . . . . . 129 

C.2 Ein Attribut mit optionalen Werten . . . . . . . . . . . . . . . . . . . . 130 

D.1 Ermittlung der Linker-Flags . . . . . . . . . . . . . . . . . . . . . . . . 133 

D.2 Ermittlung der Linker-Flags . . . . . . . . . . . . . . . . . . . . . . . . 133 

D.3 Programmausgabe nach Start des Proxyservers . . . . . . . . . . . . . . 135 


146 Abbildungsverzeichnis 


Tabellenverzeichnis 147 

Tabellenverzeichnis 

2.1 IP-Adressnotation für Version 4 (IPv4) . . . . . . . . . . . . . . . . . . 12 

2.2 Reservierte Adressbereiche im IPv4 Protokoll . . . . . . . . . . . . . . 21 

5.1 Die Gerätearten des ZigBee-Profils ” Home Control, Lighting“ . . . . . . 61 


148 Tabellenverzeichnis 


Abkürzungsverzeichnis und Formelzeichen 149 

Abkürzungsverzeichnis und 

Formelzeichen 

AES . . . . . . . . . . . . . . . Advanced Encryption Standard 

ARP . . . . . . . . . . . . . . . Address Resolution Protocol 

ATM . . . . . . . . . . . . . . . Asynchronous Transfer Mode 

bzw. . . . . . . . . . . . . . . . beziehungsweise 

CIDR . . . . . . . . . . . . . . Classless InterDomain Routing 

DARPA . . . . . . . . . . . . Defense Advanced Research Projects Agency 

DES . . . . . . . . . . . . . . . Data Encryption Standard 

DHCP . . . . . . . . . . . . . Dynamic Host Configuration Protocol 

DoD . . . . . . . . . . . . . . . Department of Defense (Amerikanisches Verteidigungsministe- 

rium) 

FTP . . . . . . . . . . . . . . . File Transport Protocol 

GPS . . . . . . . . . . . . . . . Global Positioning System 

HTTP . . . . . . . . . . . . . Hypertext Transfer Protocol 

IANA . . . . . . . . . . . . . . Internet Assigned Numbers Authority 

ICANN . . . . . . . . . . . . Internet Corporation for Assigned Names and Numbers 

ICMP . . . . . . . . . . . . . . Internet Control Message Protocol 

IEEE . . . . . . . . . . . . . . . Institute of Electrical and Electronics Engineers 

IETF . . . . . . . . . . . . . . . Internet Engineering Task Force 

IMAP . . . . . . . . . . . . . . Internet Message Access Protocol 

IP . . . . . . . . . . . . . . . . . . Internet Protocol 

IPX . . . . . . . . . . . . . . . . Internetwork Packet Exchange 

ISO . . . . . . . . . . . . . . . . International Organization for Standardization 

ISP . . . . . . . . . . . . . . . . Internet Service Provider 

LAN . . . . . . . . . . . . . . . Local Area Network 

NAT . . . . . . . . . . . . . . . Network Address Translation 

OSI . . . . . . . . . . . . . . . . Open Systems Iinterconnection 

PAN . . . . . . . . . . . . . . . Personal Area Network 


150 Abkürzungsverzeichnis und Formelzeichen 

PC . . . . . . . . . . . . . . . . . Personal Computer 

PDA . . . . . . . . . . . . . . . Personal Digital Assistant 

POP-3 . . . . . . . . . . . . . Post Office Protocol 

Radar . . . . . . . . . . . . . . Radio detection and ranging 

RARP . . . . . . . . . . . . . Reverse Address Resolution Protocol 

RFC . . . . . . . . . . . . . . . Request For Comments 

SMS . . . . . . . . . . . . . . . Short Message Service 

SOSUS . . . . . . . . . . . . . Sound Surveillance System 

SQL . . . . . . . . . . . . . . . . Structured Query Language 

TCP . . . . . . . . . . . . . . . Transmission Control Protocol 

UDP . . . . . . . . . . . . . . . User Datagram Protocol 

W3C . . . . . . . . . . . . . . . World Wide Web Consortium 

WLAN . . . . . . . . . . . . . Wireless Local Area Network 

WWW . . . . . . . . . . . . . World Wide Web 

XML . . . . . . . . . . . . . . . eXtensible Markup Language 

z.B. . . . . . . . . . . . . . . . . zum Beispiel 


Thesen zur Diplomarbeit 151 

Thesen zur Diplomarbeit 

1. Die Vermittlungs- und Transportprotokolle die im Internet ihre Anwendung fin- 

den, sind nicht für den Einsatz in Sensornetzwerken geeignet. 

2. Die Kopplung eines Sensornetzwerkes an IP-basierte Kommunikationssysteme ist 

ein lohnenswertes Ziel. 

3. Die Implementierung der TCP/IP-Suite in Sensornetzwerke ist aus Gründen des 

Protokolloverheads mit hohen Energieanforderungen verbunden. 

4. Durch die Implementierung eines transparenten Proxys können Sensornetzwerke 

an IP-basierte Kommunikationssyteme gekoppelt werden. 

5. Dabei ist der Einsatz des transparenten Proxys dem Anwender nicht ersichtlich. 

6. Herkömmliche Anwendungs- und Transportprotokolle können unterstützt wer- 

den. Damit wäre ein Zugriff auf die Knoten des Sensornetzwerkes mit vorhande- 

nen Anwendungen möglich. Der Zugriff kann ohne Eingriffe in das Betriebssystem 

oder die Anwendungen des Clients durchgeführt werden. 

Ilmenau, den 30. 03. 2006 André Hesse 


152 Thesen zur Diplomarbeit 


Erklärung 153 

Erklärung 

Die vorliegende Arbeit habe ich selbstständig ohne Benutzung anderer als der ange- 

gebenen Quellen angefertigt. Alle Stellen, die wörtlich oder sinngemäß aus veröffent- 

lichten Quellen entnommen wurden, sind als solche kenntlich gemacht. Die Arbeit ist 

in gleicher oder ähnlicher Form oder auszugsweise im Rahmen einer oder anderer Prü- 

fungen noch nicht vorgelegt worden. 

Ilmenau, den 30. 03. 2006 André Hesse

Technische Universität Ilmenau Fakultät für Elektrotechnik und ...

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?