Fahrzeug-zu-Fahrzeug-Kommunikation. Umfassender Überblick über den Stand der Forschung und Entwicklung eines Prototypensystems

InhaItsverzeichnis

1 Einleitung
1.1 Zielsetzung
1.2 Aufbau der Arbeit

2 Grundlagen von Fahrzeug-zu-Fahrzeug-Netzwerken
2.1 Anwendungen
2.1.1 Informationsverbreitung
2.1.2 Eehtzeitfahrerassistenz
2.1.3 Infotainmentapplikationen
2.1.4 Sonstige Anwendungen
2.1.5 Sehlussfolgerungen
2.2 Xetzwerktypen
2.2.1 Mobile Ad-Hoe-Xetze
2.2.2 Sensornetze
2.2.3 Fahrzeug-zu-Fahrzeug-Xetze
2.3 Funkhardware
2.4 Medienzugriffsverfahren in Funknetzen
2.4.1 IEEE 802.11 Medienzugriffskontrolle
2.4.2 Verbesserung der Gleiehbereehtigung
2.4.3 Einsatz mehrerer Funkkanäle
2.4.4 Intelligente Antennen
2.4.5 Besonderheiten beim Rundfunk
2.4.6 Sehlussfolgerungen

3 Höhere Netzwerkfunktionalität in VANETs
3.1 Routingprotokolle
3.1.1 Proaktive Routingprotokolle
3.1.2 Hierarehisehe Routingprotokolle
3.1.3 Reaktive Routingprotokolle
3.1.4 Hybride Routingprotokolle
3.1.5 Positionsbasierte Routingprotokolle
3.1.6 Optimierungsansätze
3.1.7 Sehlussfolger ungen
3.2 Xaehbarsehaftsprotokolle
3.3 Dienstgüte
3.4 Mehrpunktverbindungen
3.5 Transportprotokolle
3.5.1 Verhalten von TCP in VAXETs
3.5.2 Verbesserungen von TCP für VAXETs
3.5.3 Sehlussfolgerungen
3.6 Adressierung
3.7 Gleiehbereehtigung
3.8 Sieherheit
3.9 Energiesparen
3.9.1 Stromsparender Medienzugriff
3.9.2 Energiesparendes Routing
3.9.3 Sehlussfolgerungen
3.10 Informationsverbreitung
3.11 Weitere Besonderheiten in VAXETs
3.11.1 Zeitsynehronisierung
3.11.2 Unidirektionale Verbindungen
3.11.3 Internetintegration
3.11.4 Simulationen
3.12 Projekte und Standards
3.12.1 FleetXet
3.12.2 PReVEXT
3.12.3 Car2Car Communieation Consortium
3.12.4 IEEE 802.11p WLAX
3.12.5 Protokoll-Standardisierungen

4 Aufbau eines Prototypensystems
4.1 Zielstellungen
4.2 Konzeption
4.2.1 Grundlegende Architektur
4.2.2 Softwaremodell
4.3 Implementierung
4.3.1 VAXET Prototyping Framework
4.3.2 VAXET Prototyping System
4.4 Versuehsaufbau
4.4.1 Verwendete Hardware
4.4.2 Visualisierung der Radarsehirmdaten
4.4.3 Praktisehe Erfahrungen
4.5 Ergebnisse

5 Ergebnisse und Ausblick

Danksagung

Die Erstellung dieser umfangreichen Diplomarbeit war eine persönliche Herausforderung, die zwar oft anstrengend aber auch spannend und interessant war. Bei Professor Jörg Roth möchte ich mich für die Übernahme der Betreuung meiner Arbeit bedanken, sowie für den Gestaltungs­freiraum den er mir bei der Bearbeitung gegeben hat. Mein Dank geht auch an Wolfgang Zeitler von der Elektrobit Automotive GmbH für die Ermöglichung dieser Diplomarbeit und die Bereit­stellung der notwendigen Ressourcen, Bei meinem guten Freund Daniel, meinem Kommilitonen Stephan sowie meinem Arbeitskollegen David bedanke ich mich herzlich für das Korrekturlesen meiner Arbeit, Weiterhin danke ich meinen Eltern für die Unterstützung in dieser schwierigen Zeit.

Zusammenfassung

Diese Arbeit behandelt das Thema der Fahrzeug-zu-Fahrzeug-Kommunikation, Viel Forschung wurde bereits im Bereich der mobilen Ad-Hoe-Xetzwerke und Fahrzeug-zu-Fahrzeug-Xetzwerke durehgefiihrt. Dabei werden zahlreiche spezialisierte Teilgebiete behandelt. Im Rahmen dieser Arbeit werden hingegen keine neuen Vorschläge zu der Theorie von Fahrzeug-zu-Fahrzeug- Kommunikation gemacht, sondern es soll ein zusammenhängender Gesamtüberblick über die Thematik und den Stand der Forschung gegeben werden. Dabei werden alle Xetzwerksehieh- ten und die besonderen Herausforderungen und Lösungsansätze bei deren Implementierung in Fahrzeug-zu-Fahrzeug-Xetzwerken beleuchtet. Dies umfasst unter anderem die Themengebie­te Medienzugriff, Routingprotokolle und Transportprotokolle aber auch erweiterte Xetzwerk- funktionalität wie Dienstgüte und Mehrpunktverbindungen, Darüber hinaus werden spezifische Aspekte von Fahrzeug-zu-Fahrzeug-Xetzwerken behandelt: Applikationsklassen, Adressierung, Gleichberechtigung, Sicherheit und weitere Besonderheiten, die für die Praxisumsetzung solcher Xetzwerke von Bedeutung sind. Aus den gesammelten Erkenntnissen werden Grundzüge identi­fiziert, die für die Konzeption eines Gesamtsystems zur Fahrzeug-zu-Fahrzeug-Kommunikation elementare Bedeutung haben. Dies betrifft insbesondere alle wesentlichen Unterschiede zu kon­ventionellen Xetzwerken, Im praktischen Teil dieser Arbeit wird mit Hilfe der Schlussfolgerungen aus der Theorie ein Vorschlag für die Entwicklung eines Prototypensystems zur Fahrzeug-zu-Fahrzeug-Kommuni- kation erarbeitet und umgesetzt. Dieses Prototypensystem soll zur Implementierung beliebiger Protokollstapel für Fahrzeug-zu-Fahrzeug-Xetzwerke im Rahmen der Forschung und Entwick­lung dienen, sowie die Evaluierung von Ergebnissen der Theorie in der Praxis ermöglichen.

Abbildungsverzeichnis

2.1 Mögliche Bildschirmansicht einer Radarschirmanwendung

2.2 Single-Hop und Multi-Hop-Kommunikation

2.3 Xetzwerktopologie mit Gefahr der Partitionierung

2.4 Beispiel für ein Sensornetzwerk

2.5 OSI Schichtenmodell

2.6 Versteckte und ausgelieferte Xetzwerkknoten

2.7 CSMA in IEEE 802.11 WLAX

2.8 CSMA/CA mit Kontrollnaehriehten

2.9 Ungleichberechtigung in IEEE 802.

2.10 Einsatzszenario für empfängerbasierte Medienzugriffskontrolle

2.11 Kommunikation mit mehreren Funkfrequenzen

2.12 Kollision bei direktionaler Übertragung

2.13 Das MMAC Protokoll

2.14 Direktionale RTS-Xaehriehten

2.15 Überblick über Rundfunkklassen

2.16 Broadcast Medium Window Protokoll

3.1 DSDV' Routingalgorithmus

3.2 CGSR Routingalgorithmus

3.3 DSR Routingalgorithmus

3.4 AODV' Routingalgorithmus

3.5 ZRP Routingalgorithmus

3.6 Lücken beim GPSR Routingalgorithmus

3.7 GPSR Routingalgorithmus: Einsatz bei Strafśennetztopologie

3.8 Multipfade

3.9 Reparatur von Routen

3.10 Ablauf eines Xaehbarsehaftsprotokolls

3.11 Xaehbarsehaftsprotokoll in einer Kreuzungssituation

3.12 Beispiel zur Berücksichtigung von Dienstgüte auf der Vermittlungsschicht , , , .

3.13 Aufspannender Baum bei einer Mehrpunktverbindung

3.14 Beispiel zum RDG-Mehrpunktprotokoll

3.15 Überlastkontrolle bei TCP

3.16 Dezentrale IP-Adressierung in MAXETs

3.17 Priorisierung von Paketübertragungen durch Xutzenbewertung

3.18 Angriffsmögliehkeiten auf Routing- und Xaehbarsehaftsprotokolle

3.19 Kryptographie durch Nutzung getrennter Kommunikationpfade

3.20 Ermittlung der optimalen Übertragungsstärke durch COMPOW

3.21 Nutzung eines asynchronen Stromsparmodus

3.22 Gefahrenwarnung durch Informationsverbreitung

3.23 Unidirektionale Verbindungen

3.24 Erkennung von Internetschnittstellen

4.1 Darstellung möglicher Xetzwerkarchitekturen

4.2 Unterteilung der Softwarearchitektur in zwei Ebenen (VPF und VPS)

4.3 Softwarearchitektur des Prototypensystems

4.4 Übersieht über Schnittstellen des VPF

4.5 Konzept der Xetzwerkagenten im VPF

4.6 Paketflussmodell im VPF

4.7 Speicherverwaltungsmodell im VPF

4.8 Verzeigerung einer voll ausgefüllten Paket-Datenstruktur

4.9 Protokollformate

4.10 Aufbau und Konfiguration der VPS-Implementierung

4.11 Startprozess des VPS

4.12 Hilfetext des externen Werkzeugs vpsconfig

4.13 Ausgabe der eigenen GPS Position mit Hilfe von vpsconfig

4.14 Ausgabe der eigenen Xachbarschaftstabelle mit Hilfe von vpsconfig

4.15 Ausgabe der Radarschirmapplikation

4.16 Notebook-Hardware für den Versuchsaufbau

4.17 FMB-Plattform ohne Gehäuse

4.18 FMB-Plattform im Aluminiumgehäuse mit 5.5 Zoll Tastbildschirm

4.19 Schnittstellen im FMB-Gehäuse

4.20 Die beiden FMB-Einheiten beim Betrieb des VPS

4.21 3D-Visualisierung der Radarschirmdaten

4.22 2D-Visualisierung der Radarschirmdaten (nahe Ansicht)

4.23 2D-Visualisierung der Radarsehirmdaten (entfernte Ansieht)

Tabellenverzeichnis

2.1 Anforderungen und Eigenschaften der Anwendungsklassen

2.2 Übersieht über Sensoren im Fahrzeug

2.3 Ad-Hoc-Xetzwerkklassen im Vergleich

2.4 IEEE 802.11 Standards (nur physikalische Schicht)

3.1 Verschiedene Geschwindigkeitsstufen des IEEE 802.11 Standards

3.2 TCP und UDP im Vergleich

4.1 Generische GPS-Datenstruktur

4.2 Schnittstellenspezifikation für die Gerätetreiberschicht

4.3 Generische Paket-Datenstruktur

4.4 Konfiguration und Hardwarekomponenten der Systeme im Versuchsaufbau ...

1 Einleitung

Mobile Netzwerke spielen in vielen Bereiehen der Kommunikation eine immer größere Rolle, Nachdem das drahtgebundene Internet im Alltag allgegenwärtig geworden ist, möehten vie­le Mensehen aueh unterwegs nicht mehr auf ihre Xetzwerkanbindung verzichten, um deren Kommunikations- und Informationsmöglichkeiten zu nutzen, Aueh der Mobilfunk als Vertre­ter eines mobilen Netzwerkes ist nahezu unverzichtbar im gesellschaftlichen Leben geworden, Technologien wie WLAX zur Erweiterung existierender, kabelgebundener Computernetze und Bluetooth zur drahtlosen Anbindung von Peripheriegeräten sind inzwischen Massenproduk­te geworden, die jedermann mit wenig Aufwand einsetzen kann. Die große Verbreitung von drahtloser Xetzwerktechnologie in den vergangenen Jahren in diesen und anderen Bereiehen hat aueh der Idee, Fahrzeuge im Straßenverkehr mit Funktechnologie auszustatten, um zwi­schen den Verkehrsteilnehmern ein Netzwerk aufbauen zu können, verstärkte Aufmerksamkeit zukommen lassen.

Die Forschung auf dem Gebiet der Fahrzeug-zu-Fahrzeug-Kommunikation wird bereits seit fünf bis zehn Jahren kontinuierlich betrieben. Das Interesse insbesondere der Automobilindus­trie, aber aueh aus den Reihen der Politik, an dieser Technologie ist groß. Dies liegt an den vielfältigen Anwendungsmöglichkeiten, die die Existenz eines solchen Netzwerks mit sieh brin­gen kann. Die Erhöhung der Sicherheit im Straßenverkehr, verbesserte Informationsflüsse von verkehrsrelevanten Daten in Echtzeit sowie Komfortapplikationen auf Basis solcher Xetzwerk- technik versprechen eine neue Dimension bei der Entwicklung von Diensten für den Straßen­verkehr und den individuellen Verkehrsteilnehmer.

Die Charakteristiken von Fahrzeugnetzwerken weisen jedoch im Vergleich zu konventionellen Netzwerken grundlegend veränderte Ausgangsbedingungen auf, für die die bisherigen Verfahren und Erkenntnisse im Gebiet der Computernetzwerke nur noch bedingt verwertbar sind. Dieses Themengebiet weist daher viel neue Komplexität auf und gestaltet sieh genauso vielfältig wie die potentiellen Möglichkeiten, die es verschaffen soll. Diese Arbeit beschäftigt sieh mit diesem Thema in der Hoffnung, einen Beitrag auf dem Weg zur Umsetzung von Fahrzeug-zu-Fahrzeug- Netzwerken von der Theorie in die Praxis zu leisten.

1.1 Zielsetzung

Viele wissenschaftliche Arbeiten behandeln bereits Fragestellungen zu Fahrzeug-zu-Fahrzeug- Xetzwerken und mobilen Ad-Hoe-Xetzwerken¹, Dabei werden verschiedenste Aspekte der Xetz- werkentwieklung berührt — von den Fähigkeiten der Funkhardware bis zur konkreten Appli­kation, Xur wenige Arbeiten zeichnen jedoch ein Gesamtbild der zahlreichen Aspekte und Pro­blemstellungen, die bei der Realisierung eines Fahrzeug-zu-Fahrzeug-Xetzwerks berücksichtigt werden müssen, Stattdessen werden oft einzelne Teilgebiete isoliert betrachtet und weitreichende Annahmen getroffen, die weiterführende Fragestellungen ausblenden. Dies ist nachvollziehbar, da es sieh hier um die Entwicklung einer Xetzwerkarehitektur für eine völlig neue Klasse von Xetzwerken handelt. Der Aufwand und die Komplexität sind hier in etwa vergleichbar mit der Entwicklung des digitalen Mobilfunks (GSM, Global System for Mobile Communications).

Diese Diplomarbeit hat deshalb zum Ziel, einen Überblick über die für die Xetzwerkarehitek­tur von Fahrzeug-zu-Fahrzeug-Xetzwerken relevanten Aspekte zu geben. Dabei sollen Einblicke in die Ideen, die bisher verfolgt wurden, um den Charakteristiken eines solchen Xetzwerks Rechnung zu tragen, verschafft werden. Um dieses umfangreiche Themengebiet zu begrenzen, wird in dieser Arbeit der Fokus auf die grundsätzliche, funktionale. Realisierung eines Fahrzeug- zu-Fahrzeug-Xetzwerks gelegt. Darüber hinausgehende Themen, wie zum Beispiel Sieherheits- meehanismen im Xetzwerk, sind kein integraler Bestandteil, Es wird versucht die Querver­bindungen, die zwischen den einzelnen Xetzwerkkomponenten bestehen, herauszuarbeiten. Die aus der Theorie gewonnenen Erkenntnisse dienen dazu ein Gesamtkonzept für die Realisierung eines prototypisehen Systems zur Fahrzeug-zu-Fahrzeug-Kommunikation zu erarbeiten. Dabei wird das Fahrzeugzu-Fahrzeug-Xetzwerk nicht, wie es manchmal der Fall ist, als ein erweiterter Anwendungsfall existierender Xetzwerke betrachtet, sondern als eigene Xetzwerkklasse mit individuellen Anforderungen.

Sehliefślieh wird das entwickelte Konzept im Rahmen eines konkreten Prototypensystems und eines Versuehsaufbaus umgesetzt, welches zur weiteren Forschung und Entwicklung im Rahmen von Feldtests dienen soll. Als Zielplattform für die Implementierung dieses Systems und der darauf aufbauenden Applikationen wird eingebettete Hardware angenommen, die nur über geringe Leistungsreserven verfügt. Bezüglich des Einsatzgebietes für ein solches Xetzwerksystem liegt das Augenmerk in dieser Arbeit insbesondere auf Fahrerassistenzapplikationen.

1.2 Aufbau der Arbeit

Der verbleibende Teil dieser Arbeit gliedert sieh in folgende Kapitel auf: Im anschließenden Kapitel 2 werden die Grundlagen von mobilen Ad-Hoc-Xetzwerken und Fahrzeug-zu-Fahrzeug- Xetzwerken im Besonderen behandelt. Dies umfasst die Betrachtung der Anwendungsgebiete solcher Netzwerke sowie eine Klassifizierung verwandter Xetzwerkklassen, Aufśerdem wird der Medienzugriff, der eine besondere Problemstellung in Fahrzeug-zu-Fahrzeug-Xetzwerken dar­stellt, ausführlich betrachtet. In Kapitel 3 wird ein umfassender Überblick über erweiterte Funk­tionalität in diesen Netzwerken gegeben. Es befasst sieh mit Problemstellungen und aktuellen Forschungergebnissen bezüglich aller höheren Xetzwerkschichten. Das Kapitel 4 leitet aus dem Wissensstand der beiden vorangehenden Kapitel ein Konzept für ein prototypisches Software­system zur Fahrzeug-zu-Fahrzeug-Kommunikation ab und beschäftigt sieh mit der konkreten Implementierung des daraus hervorgehenden Softwarekonzepts auf prototypischen Plattformen im Rahmen eines Versuchsaufbaus. Im Kapitel 5 werden die Ergebnisse der Arbeit noch einmal zusammengefasst dargestellt und ein Ausblick auf die weitere Entwicklung des Themas gegeben.

2 Grundlagen von Fa hrzeug-zu-Fahrzeug-Netzwerken

Fahrzeug-zu-Fahrzeug-Xetzwerke (engl, Car2Car Communication (C2CC) Networks) oder au­tomobile Ad-Hoe-Xetze basieren auf der Idee ein Netzwerk zu bilden, indem einige oder alle Fahrzeuge im Straßenverkehr mit Funkhardware ausgestattet werden. Jedes Fahrzeug soll da­durch die Fähigkeit erhalten, mit einem beliebigen anderen Fahrzeug im Netzwerk zu kommu­nizieren, Damit sollen neuartige Anwendungen möglich werden, die unter anderem zu erhöhter Sicherheit im Straßenverkehr beitragen und den Komfort für den Fahrer verbessern. Ein solches Netzwerk soll eigenständig lauffähig und selbstorganisierend sein. Es muss insbesondere keine dedizierte Infrastruktur, wie fest installierte Server oder Router existieren, damit das Netz­werk funktionsfähig ist. Der Hauptgrund für diese Bedingung liegt darin, dass entweder eine dedizierte Xetzwerkinfrastruktur aufgebaut werden müsste, die das Straßennetz weitgehend ab- deekt, was mehrere Milliarden Euro kosten würde, wie dies auch schon bei Mobilfunknetzen wie GSM oder UMTS (Universal Mobile Telecommunications System) der Fall war bzw, ist, Oder es müsste ein existierendes, infrastrukturbasiertes Netzwerk an die Fahrzeug-zu-Fahrzeug- Kommunikation angepasst und ggf, erweitert werden, was ebenso Investitionskosten mit sieh bringt. Darüber hinaus entstehen bei Einsatz von Infrastrukturnetzwerken auch Xutzungsge- biihren, die bei der großen Anzahl von Fahrzeugen hohe Kosten verursachen würden. Da es sieh bei Fahrzeug-zu-Fahrzeug-Xetzwerken im Gegensatz zum Mobilfunk um große und reine Funk­netzwerke handelt, die einen spezialisierten Einsatzbereieh abdeeken, wären die Investitions­und Betriebskosten nicht wirtschaftlich. Durch die Nutzung der Ad-Hoe-Kommunikation zwi­schen Fahrzeugen in einem nicht lizenzpfliehtigen ISM-Frequenzband (Industrial, Scientific and Medical) hingegen entstehen keine weiteren Kosten als die für die Hard- und Software, die direkt im Fahrzeug zum Einsatz kommt.

Daraus resultieren allerdings auch die speziellen Anforderungen und Probleme von Fahrzeug- zu-Fahrzeug-Xetzen, Solche Ad-Hoe-Xetzwerke werden bei ausreichend hoher Ausstattungsquo­te unter den Fahrzeugen schnell aus mehreren tausend Xetzwerkteilnehmern bestehen. Alle diese Teilnehmer sind gleichberechtigt und müssen sieh kooperativ untereinander organisieren. Diese Netzwerkstruktur unterscheidet sieh stark von existierenden infrastrukturbasierten Netzwerken wie dem Internet oder Funknetzen wie GSM oder UMTS.

In den Folgenden Abschnitten werden die Grundlagen von Fahrzeug-zu-Fahrzeug-Xetzwerken behandelt. Zunächst erfolgt eine Beschreibung der möglichen Anwendungen und Einsatzszena­rien solcher Xetzwerkteehnologie, Des weiteren werden Grundzüge erläutert, die für alle Ebenen der Xetzwerkarehitektur von Bedeutung sind. Der Typus der Fahrzeug-zu-Fahrzeug-Xetzwerke wird klassifiziert und verwandte Xetzwerktypen beschrieben. Auch auf die in Frage kommen­de Funkhardware für ein solches Netzwerk wird eingegangen. Im weiteren Verlauf werden die besonderen Problemstellungen beim Medienzugriff in Fahrzeug-zu-Fahrzeug-Xetzwerken um­fassend betrachtet.

2.1 Anwendungen

Um eine bessere Vorstellung von Fahrzeug-zu-Fahrzeug-Xetzwerken zu erhalten, ist es sinnvoll, die Zielapplikationen für solche Netzwerke zu betrachten. Mit Hilfe der Fahrzeug-zu-Fahrzeug- Kommunikation sind eine Reihe von Anwendungen denkbar, die den individuellen Fahrzeugin­sassen aber auch dem gesamten Netzwerk bzw, Strafsenverkehr zu Gute kommen. Hierbei lassen sich verschiedene Applikationsklassen ausmachen. Die Konzeption eines Fahrzeug-zu-Fahrzeug- Xetzwerks sollte sich an diesen orientieren, um einen hohen Funktionsgrad zu erreichen. Es gibt verschiedene Ansätze, Applikationen zu Klassen zusammenzufassen, wie etwa nach dem Grad des Sicherheitseinflusses oder der Art der Funktionalität, Im Rahmen dieser Arbeit wird eine Klassifizierung nach den Anforderungen der Applikationen an das Netzwerk vorgenom­men, Dies kommt einer funktionalen Unterscheidung sehr nahe, da Anwendungen mit ähnlicher Funktionalität auch ähnliche Anforderungen an das Netzwerk haben. Die hierbei identifizierten Anwendungsklassen sind Informationsverbreitung, Echtzeitfahrerassistenz und Infotainment. Diese werden im Folgenden näher beschrieben.

2.1.1 Informationsverbreitung

Im Rahmen von Fahrerassistenzanwendungen können über Fahrzeug-zu-Fahrzeug-Xetzwerke Informationen weiträumig zwischen Verkehrsteilnehmern ausgetauscht werden. Dies ermöglicht die Übertragung von Verkehrsflussinformationen zu bestimmten Streckenabschnitten, Auch Un­fallzonen in der näheren Umgebung, in denen Staugefahr besteht, können mitgeteilt werden. Mit solchen Informationen lässt sich zum Beispiel ein Xavigationssystem erweitern, dass diese Zusatzinformationen in den Wegfindungsprozefś mit einfliefśen lässt, um das Fortkommen des Fahrers zu seinem individuellen Ziel zu optimieren. Gegenüber konventionellen, zentralisier-ten Verkehrsinformationsmechanismen wie TMC (Traffic Message Channel) wäre diese Art der Informationsverbreitung deutlich zeitnäher und detaillierter. Eine weitere, einfache Form der Informationsverbreitung stellt eine Art Radarschirm dar, der alle Verkehrsteilnehmer in der näheren Umgebung des Fahrzeugs auf einer Karte anzeigt, so dass der Fahrer eine weiträumige Verkehrsübersicht erhält und vorausschauend agieren kann. Besondere Fahrzeuge können auf dieser Karte eigens ausgezeichnet werden, um über die Position von ausgewählten Fahrzeugen (z. B. Begleitfahrzeuge) informiert zu sein oder Spezialfahrzeuge wie Busse und Bahnen zu er­kennen. So kann das Fahrverhalten der dargestellten Verkehrslage angepasst werden. Abbildung 2.1 zeigt eine mögliche Ansicht der Benutzerschnittstelle für diese Funktionalität.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1: Mögliche Bildschirmansicht einer Radarschirmanwendung

Der Informationshorizont für den Fahrer eines Fahrzeugs wird durch solche Anwendungen wesentlich erweitert, da verkehrsrelevante Ereignisse und Informationen über andere Verkehrs­teilnehmer über große Entfernungen hinweg übermittelt werden können. Die Anwendungsge­biete der Informationsverbreitung gehen auch über reine Verkehrsflussoptimierung hinaus. So könnten Rettungsfahrzeuge besondere Warnnachrichten aussenden, so dass die Fahrbahn für diese schon im Vorfeld geräumt werden kann oder eine Unfallzone von unbeteiligtem Verkehr be­freit wird. Gleichzeitig kann das Fahrzeug-zu-Fahrzeug-Netzwerk die Rettungsfahrzeuge über die genaue Position eines Einsatzortes aufklären und sie so schneller zum Ziel führen. Dass solche Verkehrssteuerungsmaßnahmen prinzipiell möglich sind, zeigt eine simulative Analyse [EOSK05]. Nach dem selben Muster lassen sich andere spezielle Fahrzeugklassen behandeln, beispielsweise LKWs oder öffentliche Verkehrsmittel, um die Sicherheit zu erhöhen und den Verkehrsfluss zu steuern.

Mit Hilfe von Informationsverbreitung können Fahrzeuge außerdem Gefahren im Straßenver­kehr erkennen und anderen Netzwerkteilnehmern mitteilen (LDW - Local Danger Warning). Bei diesen lokalen Gefahren könnte es sich etwa um Glatteis oder eine Ölspur auf der Fahr­bahn handeln. Ein Fahrzeug erkennt eine solche Gefahrensituation durch Auswertung seiner Sensoren, erstellt eine Warnmitteilung und sendet diese an seine Xachbarfahrzeuge. Auf diese Weise können Warnnachrichten dauerhaft im Netzwerk erhalten bleiben und den Verkehrsteil­nehmern präventiv mitgeteilt werden. Die Fahrer nachfolgender Fahrzeuge werden dann von einer Fahrerassistenzanwendung auf die Gefahr hingewiesen und können ihr Fahrverhalten der gemeldeten Situation anpassen. Der Informationsstand des Fahrers könnte also dadurch noch weiter erhöht werden und Unfallgefahren würden reduziert.

Informationsverbreitung kann auch in Zusammenarbeit mit Infrastruktur durchgeführt wer­den, Zu nennen ist hier die Parkplatzsuche: Parkuhren oder Parkautomaten können sieh am Fahrzeug-zu-Fahrzeug-Xetzwerk beteiligen und Informationen über zur Verfügung stehende Parkplätze in bestimmten Stadtgebieten übermitteln und den Verkehrsteilnehmern die Park­platzsuche erleichtern. Solche Hilfsinformationen können vielfältiger Art sein. Vorstellbar sind auch Daten über freie Hotelzimmer bis hin zu Werbeinformationen, die von kommerziellen Anbietern versendet werden.

Die Anwendungen aus dem Bereich der Informationsverbreitung beziehen sieh meist auf grofśe Areale und betreffen viele Verkehrsteilnehmer, Die Kommunikation findet anonym und großflä­chig statt, Ende-zu-Ende-Verbindungen zwischen Fahrzeugen werden für solche Applikationen nicht aufgebaut. Die verbreiteten Informationen sind oft langfristig von Bedeutung und ih­re Verbreitung und regelmäfsige Aktualisierung kann je nach Informationsart einige Minuten oder auch Stunden andauern. Im Falle eines Staus, der eine halbe Stunde dauert, behält die Staumeldung so lange ihre Relevanz und muss neu in den Verbreitungsbereich eintretenden Verkehrsteilnehmern mitgeteilt werden bzw, die Gültigkeit der Information erneuert werden. Ein detaillierter Einblick in die Umsetzung von Informationsverbreitungsanwendungen wird in 3.10 gegeben.

2.1.2 Echtzeitfahrerassistenz

Jenseits der Informationsverbreitung ist echtzeitkritische Fahrerassistenz denkbar, die striktere Anforderungen an die Reaktions- und Verarbeitungszeit von Informationen und eine andere Zielsetzung hat. Diese Anwendungen beschränken sieh meist auf die unmittelbare Umgebung des Fahrzeugs und die beteiligten Informationen sind nur sehr kurzfristig von Interesse bevor sie veraltet sind. Vorstellbar sind hier Bremsassistenten, Unfallwarnung, Kreuzungsassisten­ten oder zeitkritische Kommunikation mit Verkehrsinfrastruktur, Ein Bremsassistent kann mit Fahrzeugen im direkten Umfeld des eigenen Fahrzeugs Geschwindigkeits- und Positionsinfor­mationen austauschen und bei gefährlichen Konstellationen automatisch einen Bremsvorgang auslösen oder den Fahrer warnen, Unfallwarnung oder -Vermeidung bezieht sieh allgemein auf gefährliche Verkehrskonstellationen unter Berücksichtigung der Verkehrsregeln und der Ver­kehrssituation, die sieh aus den gesammelten Informationen der Xaehbarfahr zeuge sowie der eigenen Sensoren ergibt, Kreuzungsassistenten können in uniibersiehtliehen Kreuzungssitua­tionen dem Fahrer assistieren. Ein Szenario für die Kommunikation mit Infrastruktur könnte ein intelligentes Ampelsystem sein, welehes die aktuelle Ampelphase und den Zeitpunkt des Übergangs in die nächste Phase an Fahrzeuge in der Umgebung bekannt gibt. So könnte das Fahrzeug den Fahrer warnen, wenn nicht mehr genug Zeit bleibt die Ampel zu passieren, bevor die Ampelphase gewechselt wird. Auch denkbar ist es, Ampelphasen dynamisch an die aktuelle Verkehrssituation anzupassen, indem jedes Fahrzeug seine Position und seinen Fahrtweg an das Ampelsystem übermittelt.

Möglich werden könnte auch dauerhafte Kooperation zwischen Fahrzeugen, Ein Konvoi von Fahrzeugen kann sieh so organisieren, dass alle einem führenden Fahrzeug folgen bzw, innerhalb einer Fahrzeugkette jedes Fahrzeug seinem Vordermann folgt. Das Folgeverhalten könnte sieh auf das Anpassen der Route im Xavigationssystem beschränken. Aber auch eine (semi-) auto­matische Steuerung eines folgenden Fahrzeugs wäre etwa in Kombination mit Kamerasystemen möglich. In diesem Fall ist die dauerhafte Übermittlung von Fahrtziel und Fahrverhalten des vorausfahrenden Fahrzeugs notwendig. Einige dieser Anwendungen sind bereits durch Sensoren wie Kamerasysteme oder Radar abgedeekt. Jedoch könnte die Umsetzung mittels Fahrzeug­kommunikation günstiger und zuverlässiger sein oder die Zuverlässigkeit in Kombination mit vorhandenen Sensoren erhöhen. Da die Sensoren im Fahrzeug immer nur eine lokale Sieht haben, eröffnet die Möglichkeit der Kommunikation zwischen Fahrzeugen hier ganz neue Möglichkeiten, Dazu gehören solche Formen der Kooperation von Fahrerassistenzsystemen.

Den beschriebenen Applikationen sind enge Reaktionsgrenzen gesetzt. Ein Bremsassistent zum Beispiel, der mit hoher Verzögerung reagiert, wäre nutzlos wenn nicht sogar kontrapro­duktiv, Daher sind hier besondere Vorkehrungen notwendig, um definierte Reaktions- und Ant­wortzeiten zu erreichen, wie dies bei allen Eehtzeitapplikationen der Fall ist. Die Tatsache, dass die Eehtzeitanforderungen sieh hier auch auf ein Xetzwerk erstrecken, ist ein besonderes Erschwernis für deren Erfüllung, Dennoch sollte diese Klasse von Fahrerassistenzanwendungen unbedingt auch berücksichtigt werden, da diese Anwendungen einen hohen Mehrwert für die aktive Sicherheit durch Fahrerassistenz im Strafsenverkehr darstellen.

2.1.3 Infotainmentapplikationen

Eine Anwendungskategorie, die nicht direkt dem Strafsenverkehr und dessen Sicherheit oder Effizienz zugute kommt, sondern Unterhaltung und Komfort der Fahrzeuginsassen dient, sind sogenannte Infotainmentapplikationen, Häufig wird hier als Beispiel der Internetzugang über das Fahrzeug-zu-Fahrzeug-Xetzwerk genannt. Über Vermittlungsstellen in der Xetzwerkinfra-Struktur kann das Fahrzeug-zu-Fahrzeug-Xetzwerk sich an das reguläre Internet anbinden und den Fahrzeuginsassen somit dessen ganze Funktionsbreite zur Verfügung gestellt werden. Die Internetanbindung kann um ortsbezogene Dienste erweitert werden, wie zum Beispiel der Auf­ruf von Internetseiten zu Sehenswürdigkeiten oder Geschäften in der direkten Umgebung des Fahrzeugs, Auch erweiterte Funktionalität wie IP-Telefonie über das Internet ist theoretisch denkbar.

Eine Infotainmentapplikation, die unabhängig von Internetanbindung und Infrastruktur ist, ist die Einrichtung von Audio- oder Videoverbindungen, um kostengünstige Kommunikation zwischen zwei oder mehreren Verkehrsteilnehmern zu ermöglichen. Verallgemeinert betrachtet können beliebige Direktverbindungen zwischen Fahrzeugen aufgebaut werden, um Daten aus­zutauschen, Dazu gehört auch die Möglichkeit, Xetzwerkspiele anzubieten, an denen Insassen verschiedener Fahrzeuge teilnehmen können, Dateitauschsysteme nach dem Vorbild im Inter­net werden ebenfalls für Fahrzeug-zu-Fahrzeug-Xetzwerke diskutiert |LPYPG06|, Eine mögli­che Zusatzfunktion, die jenseits des mobilen Strafsenverkehrs zum Einsatz kommen kann, ist die Möglichkeit vom heimischen PC aus per Funkverbindung zum Beispiel Musikdateien auf ein geparktes Fahrzeug zu übertragen. Weitere Komfortanwendungen und Verwaltungsmetho­den über die drahtlose Schnittstelle vom heimischen PC zum Fahrzeug können implementiert werden. Diese Form der Kommunikation wird auch als CarSHome Kommunikation bezeichnet.

Infotainmentapplikationen stellen zwar nur noch bedingt Fahrerassistenzanwendungen dar. Trotzdem müssen sie berücksichtigt werden, da gerade diese Anwendungen die wirtschaftliche Vermarktung erleichtern. Dies liegt an der hohen Interaktion des Xutzers mit diesen Applika­tionen und dem dadurch enstehenden subjektiven Mehrwert, Die Anforderungen von Infotain­mentapplikationen sind nicht so kritisch wie bei Echtzeitanwendungen, Dafür werden häufig Ende-zu-Ende-Verbindungen zwischen Fahrzeugen benötigt und auch eine gewisse Dienstgüte ist notwendig, um einige dieser Dienste sinnvoll zu betreiben.

2.1.4 Sonstige Anwendungen

Einige Anwendungen die sich nicht direkt einer der vorgestellten Kategorien zuordnen lassen, verbleiben. Es handelt sich dabei eher um Sonderfälle der Kommunikation, die den mobilen Strafsenverkehr und die Fahrzeuginsassen nicht unmittelbar betreffen. Durch die Präsenz ei­ner Funkschnittstelle wird auch drahtloser Zugriff auf den kabelgebundenen Fahrzeugbus (zum Beispiel CAX (Controller Area Xetwork), MOST (Media Oriented Systems Transport)) mög­lich, Für Dienstleister in der Automobilbranche bedeutet dies die Möglichkeit, drahtlos per Funk Fehleranalysen von Fahrzeugen durchzuführen. Dies könnte im einfachsten Fall in der Werkstatt geschehen, um Aufwand zu reduzieren (der Anschluss von Lesegeräten an der Elek- tronik im Fahrzeug ist nicht notwendig). Eine solche Analyse könnte aber auch über größere Entfernung mit Hilfe des Fahrzeug-zu-Fahrzeug-Xetzes durchgeführt werden, bei Existenz von Infrastruktur sogar per Internet, Dies wäre im Fall einer Autopanne hilfreich, um über große Entfernungen Fehleranalysen durchführen zu können und so der Pannenhilfe schon vorab hilf­reiche Informationen zu verschaffen. Schließlich könnten auch Aktualisierungen der Software­systeme im Fahrzeug über die drahtlose Schnittstelle realisiert werden. Im äußersten Fall wäre es sogar denkbar, dass solche Aktualisierungen dezentral im Fahrzeug-zu-Fahrzeug-Xetzwerk verteilt und somit Wartungsbesuche in der Werkstatt vermieden werden können.

Ein Fahrzeug-zu-Fahrzeug-Xetzwerk bietet ebenfalls neue Wege für Bereiche der Fahrerassis­tenz, die nicht unmittelbar mit dem Xetzwerk in Verbindung stehen. Da das Xetzwerk große Areale ab deckt und jeder Teilnehmer selbst Daten aus seinem unmittelbaren Umfeld erfassen kann, besteht die Möglichkeit verteilte Anwendungen zu realisieren. Eine Idee könnte sein, die kollektiv von den Xetzwerkteilnehmern gesammelten Daten zu nutzen, um Kartenmaterial für die Fahrzeugnavigation oder andere Assistenzanwendungen zu optimieren, Hersteller von digita­lem Kartenmaterial betreiben einen hohen Aufwand, um ihre Daten aktuell zu halten. Dennoch ist die Aktualität des Kartenmaterials begrenzt (z, B, bei Änderung der Straßenführung durch Baustellen oder Umleitungen), Durch Fahrzeug-zu-Fahrzeug-Xetzwerke könnte man die aktu­ellen Daten der Verkehrsteilnehmer auswerten, um die Qualität der digitalen Straßenkarte zu erhöhen.

Weiterhin können mit Hilfe eines Fahrzeug-zu-Fahrzeug-Xetzwerks vielfältige Formen der drahtlosen Kostenabrechnung umgesetzt werden. Durch ein elektronisches Bezahlsystem lassen sieh etwa Mautgebühren für die Xutzung von bestimmten Straßenabschnitten abbuchen. Aber auch beliebige andere Dienste sind mit dem Fahrzeug elektronisch abrechenbar, wie in der Autowaschanlage, Tankstelle oder der kostenpflichtige Parkplatz.

2.1.5 Schlussfolgerungen

Die Zielapplikationen für Fahrzeug-zu-Fahrzeug-Xetzwerke sind sehr vielfältig. Einen Über­blick über die Kerneigenschaften der betrachteten Anwendungsklassen bietet Tabelle 2.1, Auf­grund der vollkommen neuen Möglichkeiten und wegen fehlenden Erfahrungswerten lässt sieh nur schwer abschätzen, welche Anwendungen tatsächlich umsetzbar sind. Dies wird sieh erst in der Praxis zeigen. Die Xutzbarkeit der Anwendungen hängt auch stark von der Ausstat­tungsquote der Fahrzeuge mit Funksystemen ab. Die ersten Fahrzeuge, die damit ausgestattet werden, werden zunächst kaum Anwendungen aus der Kategorie Informationsverbreitung oder Echtzeitfahrerassistenz nutzen können, da es kaum Xetzwerkteilnehmer geben wird. Deshalb werden eher Anwendungen aus dem Bereich Infotainment oder der sonstigen Anwendungen in der Einführungsphase zum Einsatz kommen. Besonders Car2Home-Anwendungen, elektro­nische Kostenabrechnung oder vereinfachte Wartung durch Funkkommunikation werden hier in Frage kommen. Mit steigender Ausstattungsquote werden nach und nach auch komplexere Anwendungen möglich werden. Ab einer Ausstattungsquote von ea, fünf Prozent werden erste Informationsverbreitungsanwendungen sinnvoll nutzbar |Adler06|, Für die Xetzwerkarehitek- tur von Fahrzeug-zu-Fahrzeug-Xetzwerken spielen nur die Anwendungen eine Rolle, bei denen Gruppen von Teilnehmern unter Mobilität beteiligt sind. Die drei Klassen Informationsverbrei­tung, Eehtzeitfahrerassistenz und Infotainment sind deshalb eine geeignete Richtschnur für die Entwicklung von Protokollen und Algorithmen für Fahrzeug-zu-Fahrzeug-Xetzwerke.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.1: Übersieht über die Anforderungen und Eigenschaften der Anwendungsklassen

Um die notwendigen Daten für viele der beschriebenen Applikationen zu beschaffen, benötigt das Fahrzeug entsprechende Sensoren, die Informationen aus der Umgebung erfassen. Einige dieser Sensoren sind bereits heute in den meisten Fahrzeugen verbaut. Gängige Sensoren sind in Tabelle 2.2 aufgeführt. Eine wichtige Information für Anwendungen im Bereich der Fahrzeug- zu-Fahrzeug-Kommunikation ist die geographische Position der Xetzwerkteilnehmer, Diese kann beispielsweise über einen GPS-Empfänger (Global Positioning System) ermittelt werden, GPS- Empfänger sind heute schon in Xavigationssysteme integriert und ein standardmäfsiger Einbau in künftige Fahrzeuge zum Zweck der Fahrzeug-zu-Fahrzeug-Kommunikation ist als machbar zu betrachten. Da die GPS-Positionierung jedoch Ungenauigkeiten unterworfen ist und sie nicht in allen Verkehrssituationen verfügbar ist (etwa in einem Tunnel), werden noch weitere Tech­nologien zur akkuraten Positionierung benötigt. Auch künftige Positionierungssysteme, wie etwa das europäische Galileo-System, können den temporären Ausfall der Positionierung nicht

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.2: Übersieht über Sensoren, die in Fahrzeugen angetroffen werden können

verhindern. Darüber hinaus kann es notwendig sein, schnellere Positionierungsintervalle zu rea­lisieren, GPS-Empfänger liefern typischerweise jede Sekunde eine neu berechnete Position, Da sieh bei hohen Geschwindigkeiten die Position innerhalb einer Sekunde stark verändern kann (z, B, bei 200 km/h ca. 55 m/s) und zeitkritische Fahrerassistenzanwendungen auf aktuelle Daten angewiesen sind, müssen ggf, kürzerere Intervalle von der Positionierung realisiert wer­den, Als Lösung kann hier ein Dead Reckoning (dt,: Koppelnavigation) Algorithmus eingesetzt werden |DR|, welcher es ermöglicht auch bei Abriss der GPS-Verbindung auf Basis der letzen gültigen GPS-Position und weiteren Sensoren, wie z, B, einem Beschleunigungssensor, die aktu­elle Position abzuschätzen. Solche Verfahren können auch genutzt werden, um bei vorhandener GPS-Verbindung die Positionierungsgenauigkeit und -intervalle weiter zu verbessern, Neben der Positionierung ist auch digitales Kartenmaterial für viele Applikationen von Bedeutung, um Algorithmen mit Informationen über die Strafśennetzstruktur zu versorgen. Mit Hilfe dieser Daten können viele logische Schlüsse und verbesserte Annahmen getroffen werden, die sowohl für Fahrerassistenzapplikationen als auch für die reine Xetzwerklogik von hoher Bedeutung sind. In den Betrachtungen dieser Arbeit wird davon ausgegangen, dass sowohl ein präzises, weit­gehend ausfallsicheres Positionierungssystem als auch digitale Kartendaten in jedem Fahrzeug zur Verfügung stehen.

2.2 Netzwerktypen

In diesem Abschnitt werden Fahrzeug-zu-Fahrzeug-Netzwerke näher kategorisiert und verwand­te Netzwerktypen dargestellt, die Ähnlichkeiten aufzeigen.

2.2.1 Mobile Ad-Hoc-Netze

Beschreibung

Allgemein bezeichnet man Netzwerke, in denen alle Teilnehmer drahtlos und ohne besondere In­frastruktur miteinander verbunden sind als mobile Ad-Hoc-Netzwerke oder abgekürzt MANETs (Mobile Ad-hoc Networks). Alle oder die meisten Knoten des Netzwerks sind dabei fähig, sich räumlich zu bewegen.

Verbindungen zwischen zwei Knoten im Netzwerk können entweder durch eine direkte Funk­verbindung zustande kommen, wenn sie gegenseitig in Kommunikationsreichweite liegen, oder indirekt über andere Knoten, die den Verkehr weiterleiten. Diese beiden Verbindungsarten bezeichnet man als Single-Hop bzw. Multi-Hop Kommunikation. Unter einem Hop versteht man den Datenverkehr zwischen genau zwei Teilnehmern ohne Zwischenstationen im draht­losen Netzwerk. Liegt eine Route vor, die durch drei Zwischenknoten vom Quellknoten zum Zielknoten führt, handelt es sich um eine 4-Hop-Route, da vier individuelle Datenverbindungen aufgebaut werden müssen, bevor das Paket des Quellknoten den Zielknoten erreicht. Abbildung 2.2 zeigt auf der linken Seite die Knoten A, B und C, die direkt miteinander kommunizieren können. Auf der rechten Seite können Knoten A und C nur dann miteinander kommunizie­ren, wenn B den Verkehr zwischen ihnen weiterleitet. Es besteht also ein 2-Hop-Pfad zwischen Knoten A und C.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2: Single-Hop und Multi-Hop-Kommunikation

Die Anzahl der beteiligten Knoten im MANET ist grundsätzlich nicht beschränkt. Es ist vorab nicht bekannt, wer teilnimmt und welche Verbindungen überhaupt möglich sind. Durch die freie Beweglichkeit der Knoten ändert sich zudem typischerweise kontinuierlich die Topolo­gie des Netzwerks. Deshalb werden einmal aufgebaute Routen verhältnismäßig häufig ungültig und es müssen neue Routen ermittelt werden. Da jeder Knoten im Netzwerk potentiell Verkehr anderer Knoten weiterleiten muss — also als Router fungiert — muss im gesamten MANET ko­operiert werden. Mangels Infrastruktur gibt es keine besonders leistungsfähigen und dedizierten Maschinen zur Netzwerkorganisation oder zuverlässige Datenkanäle. Verweigern einzelne Kno­ten die Kooperation, tritt entweder Überlastung bei den verbleibenden, kooperativen Knoten auf oder Teile des Netzwerks brechen zusammen. Durch die Bewegung aller Teilnehmer kann es auch auftreten, dass die Netzwerktopologie sich in zwei oder mehrere Teile aufspaltet. In diesem Fall spricht man von Netzwerkpartitionen. Es gibt dann separate Knotenmengen innerhalb de­rer die Knoten noch miteinander kommunizieren können. Die Knotenmengen zueinander haben jedoch keine Verbindungsmöglichkeit mehr. In Abbildung 2.3 ist eine Netzwerktopologie dar­gestellt, die in zwei Partitionen zerfällt, wenn die Knoten A und B sich voneinander entfernen und folglich nicht mehr miteinander kommunizieren und somit auch nicht den Datenverkehr der anderen Knoten in ihrer Partition an die andere Partition weiterleiten können.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.3: Netzwerktopologie mit Gefahr der Partitionierung

Die Netzwerktopologie eines MANETs lässt sich mathematisch als gerichteter oder unge­richteter Graph darstellen. Die Knoten im Graphen stellen die Netzwerkteilnehmer dar und die Kanten zwischen den Knoten mögliche Direktverbindungen zwischen zwei Netzwerkteilneh­mern. Zur Vereinfachung wird oft angenommen, dass Verbindungen immer bidirektional sind und folglich das Netzwerk als ungerichteter Graph modelliert werden kann. Die Darstellung als Graph ermöglicht die Anwendung der umfangreichen Algorithmen aus der Graphentheorie auf beliebige Netzwerktopologien von MANETs. In Anlehnung an diese Graphenform werden Netzwerkteilnehmer meist allgemein als Netzwerkknoten bezeichnet.

In MANETs kann es optional eine Anbindung an vorhandene Infrastruktur geben, so z. B. über eine Basisstation eine Verbindung an das fest installierte lokale Netzwerk. Da die Knoten im MANET initial keine Kenntnis über die Topologie und angebundene Infrastruktur haben, ist es notwendig Mechanismen zur Verfügung zu stellen, um vorhandene Dienste im Netzwerk ausfindig zu machen. Dies geschieht über Diensterkennungsstechniken (engl, Service Discovery).

Da die mobilen Knoten im MAXET meist nur über beschränkte Stromversorgungskapazitäten (z.B, Xotebook/Laptop, PDA) verfügen, die Funkhardware für die drahtlose Kommunikation aber einen vergleichsweise hohen Strombedarf hat, muss auch ein effizienter Umgang mit der verfügbaren Stromkapazität sichergestellt werden.

Anwendungsfälle

Als Anwendungsbeispiele für allgemeine MAXETs werden oft spontane Zusammenschlüsse von mobilen Geräten wie Xotebooks und PDAs (Personal Digital Assistant) betrachtet. Dies kann etwa der Fall sein, wenn sich mehrere Einzelpersonen und Gruppen zu einer Besprechung ein­finden und keine geeignete Infrastruktur besteht. So können über das MAXET die Teilnehmer miteinander Dokumente und sonstige Daten austausehen. Vor allem bei grofśeren Konferenzen oder Ereignissen, auf Messen oder im Freien können MAXETs von Interesse sein. Der bestim­mende Faktor für oder gegen den Einsatz eines MAXETs wird hier die Fragestellung sein, wie aufwändig es ist, stattdessen ein Infrastrukturnetzwerk anzubieten. Gerade bei Grofsveran- staltungen sind es nicht unerhebliche Kosten, die notwendige Infrastruktur zur Verfügung zu stellen.

MAXETs sind auch von Bedeutung für sogenannte Bürgernetze, bei denen es darum geht, dy­namische Xetzzusammensehlüsse zwischen Privatnutzern zu realisieren. So können diese Xutzer untereinander Daten austausehen und kommunizieren aber auch einen gemeinsamen Internet­zugang nutzen, was bei den grofśen Bandbreiten von Internetzugängen auch im privaten Bereich besonders attraktiv ist, um Kosten zu sparen. Auf diese Weise können sich Bürgernetze über ganze Städte aber auch im ländlichen Bereich, wo es ggf, keine Breitbandinternetanbindung gibt, verbreiten. Da Xutzer sich dynamisch und drahtlos dem Xetzwerk ansehliefśen und sich wieder abkoppeln, handelt es sich hier prinzipiell auch um ein Ad-Hoe-Xetzwerk, Mobilität kann in Form von Xutzern mit mobilen Geräten Einfluss finden, ist aber nicht Hauptbestandteil von Bürgernetzen.

Ein weiterer Anwendungsfall von MAXETs ist der Einsatz im militärischen Umfeld, Im Mili­tärbereich werden MAXETs schon deutlich länger erforscht als im zivilen Bereich, Tatsächlich waren digitale Funknetzwerke schon im Einsatz bevor kabelgebundene Computernetzwerke wie Ethernet und das Internet sich durchgesetzt haben. Das Interesse des Militärs an MAXETs begründet sich vor allem in der Tatsache, dass Militäroperationen oftmals ohne oder mit man­gelhafter Infrastruktur auskommen müssen, Einsätze in infrastrukturarmen und infrastruktur­feindlichen Umgebungen sind die Regel, In schwer zugänglichen Regionen lässt sich Infrastruk­tur auch mit Hilfe mobiler Komponenten nur langsam und aufwändig aufbauen. Zudem ist sie leicht angreifbar, da sie von zentralen Komponenten abhängig ist, Eingreiftruppen und Ge­rätschaften des Militärs wie auch autonome Fahrzeuge und Flugzeuge können mit Hilfe von MAXET-Teehnik ohne Infrastruktur miteinander in Kommunikation treten, Soldaten können etwa direkt Bildinformationen von unbemannten Einheiten, die zur Aufklärung in kritischen Situationen dienen, beziehen oder diese auch Stenern, Dies hat weiterhin den Vorteil, dass Ein­heiten lokal Entscheidungen treffen und Vorgehen können, ohne das alle Informationen über eine zentrale Stelle fließen und vermittelt werden müssen.

Ähnliche Bedingungen gelten in Katastrophengebieten, Xaeh Xatnrkatastrophen oder ande­ren schwerwiegenden Ereignissen kann auch in entwickelten Gebieten und Städten die Infra­struktur zum Erliegen kommen. In diesen Fällen können mobile Rettungskräfte und Wiederauf­bautrupps über MAXETs miteinander in Verbindung bleiben. Auch hier können unbemannte Fahrzeuge wie Bergungsroboter zum Einsatz kommen, um in gefährliche Gebiete vorzudringen. Grundsätzlich sind MAXETs also für jene Einsatzgebiete interessant, wo Infrastruktur entweder zu aufwändig und zu teuer einzurichten ist, oder aufgrund der Umstände nicht schnell genug aufgebaut werden kann.

2.2.2 Sensornetze

Beschreibung

Ein Spezialfall eines MAXETs sind Sensornetzwerke, sogenannte SAXETs (Sensor Ad-Hoe Xet- works). Ein SAXET besteht aus einer Gruppe von meist sehr kleinen und eigenständig lauf­fähigen Sensoreinheiten, die miteinander mittels Funkschnittstelle in Verbindung stehen. Das Hauptmerkmal dieser Einheiten ist, dass sie aufgrund ihrer Größe besonders wenig Energiereser­ven zur Verfügung haben, Ihre Mobilität hingegen ist meist eher gering bis gar nicht vorhanden.

Eine weitere Besonderheit von Sensornetzen ist, dass oft einer oder wenige Knoten im SAXET eine Sonderrolle übernehmen. Diese sammeln die Daten aller Knoten im SAXET, werten die­se ggf, mittels Techniken der Sensorfusion aus und legen eine Historie der gemessenen Daten an (zur späteren Abholung), bzw, übermitteln die Daten an eine entfernte Infrastruktur (sie­he Beispiel in Abbildung 2.4), Aufgrund der Sensorverarbeitung im Xetzwerk ist eine präzise Zeitsynehronisierung zwischen den Knoten notwendig, denn um Sensordatenfusion durchführen zu können, muss der Zeitpunkt der Datenerhebung, die in jedem einzelnen Knoten individuell vorgenommen wird, bekannt und zwischen den verschiedenen Knoten vergleichbar sein.

Abbildung in dieser Leseprobe nicht enthalten

Anwendungsfälle

Für Sensornetze lassen sich ebenfalls Beispiele in der Militärtechnik finden. Etwa zur Über­wachung eines nicht erschlossenen Geländeabschnitts können einige Dutzend oder Hundert Er­schütterungssensoren über dem Gebiet verteilt (zum Beispiel per Flugzeug abgeworfen) werden. Das SANET nimmt automatisch seinen Betrieb auf und die Sensoren melden ihre gemessenen Daten an den Hauptknoten im SANET. Dieser reagiert nun auf Ereignisse: Indizieren die Da­ten, dass ein Fahrzeug vorbeigefahren ist, kann der Hauptknoten diese Information weitersenden (etwa per Satellit). Die Sensoren können sich entweder aus einem kleinen Energiespeicher (Bat­terie) speisen oder mittels regenerativer Energie wie Solarzellen mit Energie versorgen. Der Hauptknoten kann aufgrund seiner erweiterten Aufgabe ggf. größere Energiereserven und Re­chenkapazitäten besitzen. Solche Sensornetze können theoretisch auch über eine längere Zeit von mehreren Monaten oder Jahren operieren, wenn die Lebensdauer bzgl. Haltbarkeit und Energiereserven ausreichend ist. Ähnliche Ansätze kann man sich in der Wetterforschung vor­stellen, in der die Sensoren Wetterdaten aufzeichnen und regelmäßig melden.

SANETs finden sich auch in Form von sogenanntem Smart Dust (intelligenter Staub) wieder. Dabei handelt es sich um stark miniaturisierte Sensoreinheiten, die nur wenige Quadratmil­limeter groß sind. Der Strom für den Betrieb insbesondere der Funkschnittstelle kann durch passiven Funk realisiert werden. Hierbei wird die Energie direkt aus der Umgebung, z. B. durch Wärme, bezogen. Eine mögliche Anwendung von Smart Dust kann man bei Geheimdien- sten sehen, die die "Staubwolke" bei einer Zielperson einschleusen. Die Sensoren können dann Akkustik oder elektromagnetische Strahlung messen, um die Zielperson abzuhören. Ähnlich wie vorher beschrieben sammelt ein Hauptknoten die Informationen und verschickt sie an einen ex­ternen Teilnehmer. Ein weiteres Anwendungsgebiet wäre die Medizin, wo die Sensoreinheiten innerhalb des menschlichen Körpers eingesetzt werden könnten, um Diagnose zu betreiben. Die Smart Dust Technologie ist noch in den Anfängen und ein Forschungsthema, doch sind die potentiellen Anwendungsmöglichkeiten vielfältig.

Bei SAXETs wird der Kooperationsaspekt von MAXETs besonders ersichtlich. Die Verwandt­schaft zu verteilten Rechnersystemen zeichnet sieh auch ab, da jeder Knoten ein individuel­les Arbeitspaket hat und die Ergebnisse schließlich zusammengefasst werden. Im Vergleich zu MAXETs sind SAXETs nicht so sehr von der Mobilität betroffen, dafür aber umso stärker vom Mangel an Stromkapazität. Aufśerdem kommt die Xotwendigkeit der Zeitsynchronisation hinzu. Diese beiden Aspekte sind zentrale Fragestellungen in SAXETs.

2.2.3 Fahrzeug-zu-Fahrzeug-Netze

Beschreibung

Fahrzeug-zu-Fahrzeug-Xetzwerke, die Gegenstand dieser Arbeit sind, sind genauso wie Sen­sornetze eine Sonderform von mobilen Ad-Hoc-Xetzwerken. Konsequent werden sie auch als VAXETs (Vehicular Ad-Hoe Xetworks) bezeichnet. Der Hauptunterschied von VAXETs ge­genüber MAXETs oder gar SAXETs ist, dass die Mobilität der Xetzwerkknoten in VAXETs wesentlich höher ist. Grundsätzlich sind die Xetzwerkknoten in VAXETs mit einer geeigneten Funkschnittstelle ausgestattete Fahrzeuge. Dies sind typischerweise Fahrzeuge im Strafsenver- kehr. Es können aber auch als Spezialform unbemannte Fahrzeuge, Luftfahrzeuge wie Flugzeuge und Hubschrauber oder maritime Einheiten Teilnehmer im Xetzwerk sein. Im Rahmen dieser Arbeit werden nur Fahrzeuge im Strafsenverkehr angenommen, von Personenfahrzeugen bis hin zu Lastkraftwagen oder Sonderfahrzeugen wie öffentlichen Verkehrsmitteln und Xotfallfahrzeu­gen.

Einen Überblick über die typischen Eigenschaften von MAXETs, SAXETs und VAXETs gibt Tabelle 2.3. In wissenschaftlichen Arbeiten werden oftmals nur allgemeine MAXETs als über­greifende Xetzwerkklasse behandelt und keine Sonderformen wie SAXETs oder VAXETs, vor allem wenn es um grundlegende Xetzwerkfunktionalität wie zum Beispiel Routing geht. Hier muss jedoch beachtet werden, dass die Spezialformen von MAXETs wesentliche Eigenschaften aufweisen, die sie von allgemeinen MAXETs unterscheiden. Bei VAXETs herrscht hohe Mobi­lität, so dass die Xetzwerktopologie sieh sehr schnell ändert. Weiterhin ist die Teilnehmerzahl

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.3: Vergleich der typischen Eigenschaften der drei betrachteten Xetzwerkklassen

und räumliche Größe von VAXETs potentiell sehr groß. Ein Fahrzeugnetz kann eine ganze Stadt oder einen ganzen Landstrich abdecken. Mehrere tausend bis zehntausend Teilnehmer können ein solches Xetzwerk bilden, wobei permanent Knoten aus dem Xetzwerk verschwinden und neue Knoten hinzukommen. Während insbesondere in SAXETs aber auch in MAXETs der sparsame Umgang mit Energieressourcen eine wichtige Rolle spielt, ist dieser Aspekt für VAXETs vernachlässigbar, da innerhalb von Fahrzeugen genug Energie zur Verfügung steht. Diese enorm hohe Dynamik und unterschiedlichen Ausgangsbedingungen von VAXETs gegen­über MAXETs haben zur Folge, dass Algorithmen und Methoden, die für bestimmte MAXETs gut geeignet sind, in VAXETs schlechter oder gar nicht funktionieren können.

Anwendungsgebiete

Die Anwendungsgebiete von VAXETs wurden bereits in 2.1 ausführlich beschrieben.

2.3 Funkhardware

Für Fahrzeug-zu-Fahrzeug-Xetzwerke sind prinzipiell verschiedenste Fnnknetztypen geeignet. Von Mobilfnnknetzen wie GSM oder UMTS bis hin zu Allzwecknetzen wie Bluetooth, WLAX (Wirless Local Area Xetwork) oder HIPERLAX (High Performance Radio Local Area Xetwork) könnte jeder Standard zum Einsatz kommen. Zu berücksichtigen ist jedoch, dass VAXETs ohne Infrastruktur miskommen sollen. Der Funkstandard muss also einen Ad-Hoe-Modus umsetzen, der es Knoten im Xetzwerk erlaubt, direkt miteinander ohne zentrale Instanz, wie einer Ba­sisstation, zu kommunizieren. Dies ist nur bei Bluetooth, HIPERLAX und WLAX der Fall, Im Projekt FleetXet wurde trotzdem UMTS vorgesehen |FleetXet|, wobei davon ausgegangen wurde, dass ein geeigneter Ad-Hoe-Modus zusätzlich implementiert werden kann (siehe dazu auch 3.12.1).

Die Eigenschaften des Funknetzes sollten aufśerdem hohe Reichweiten und Bewegungsge- sehwindigkeiten erlauben. Mehrere hundert Meter Funkreiehweite bei direkter Siehtverbindung sollten möglich sein, um eine hohe Konnektivität im VAXET zu gewährleisten, Bewegungsge- sehwindigkeiten von bis zu 200 ^250 km/h (Autobahn) dürfen die Xutzbarkeit des Funknetzes nicht negativ beeinflussen. In Ausnahmefällen (Flugzeuge) müssten auch wesentlich höhere Ge­schwindigkeiten berücksichtigt werden, wovon in dieser Arbeit jdeoeh nicht ausgegangen wird.

Aus ökonomischen Gründen ist ein Frequenzband nötig, das lizenzfrei ist, also in einem ISM- Frequenzband liegt. Insgesamt deuten alle Anzeichen darauf hin, dass eine Funktechnik auf Basis der IEEE 802.11 WLAX-Teehnologie für Fahrzeug-zu-Fahrzeug-Xetzwerke zum Einsatz kommen wird, WLAX bietet den notwendigen Ad-Hoe-Modus, kann hohe Reichweiten realisie­ren und hohe Bewegungsgesehwindigkeiten kompensieren |Sehwingensehlögl04|, |Koseh05|, Die Tatsache, dass WLAX in den letzten Jahren enorme Verbreitung gefunden hat und dadurch die Kosten für WLAX-Hardware verhältnismäfsig gering sind, sowie die Reife der Technik, sind weitere Vorteile für den Einsatz von WLAX für Fahrzeug-zu-Fahrzeug-Kommunikation, Andere Funkstandards eignen sieh hingegen weniger. Bluetooth ist für andere spezialisierte Einsatzge­biete (PAXs - Personal Area Xetworks) konzeptioniert worden. Die Bandbreite und Reichweite sind deutlich geringer als bei WLAX, HIPERLAX hingegen wäre zwar prinzipiell auch geeignet, doch existiert in der Praxis kaum Hardware, die diesen Standard implementiert.

Auch die Mehrheit der wissenschaftlichen Arbeiten und Forsehungsaktivitäten, die sieh mit MAXETs und VAXETs beschäftigen gehen davon aus, dass IEEE 802.11 Hardware zum Einsatz kommt. Die Tabelle 2.4 bietet eine Übersieht über die derzeit verabschiedeten und geplanten IEEE 802.11 Hardwarespezifikationen, Im Rest dieser Arbeit wird von einem zu IEEE 802.11 kompatiblen WLAX zur Durchführung der Fahrzeug-zu-Fahrzeug-Kommunikaton ausgegangen.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.4: IEEE 802.11 Standards (nur physikalische Schicht)

2.4 Medienzugriffsverfahren in Funknetzen

Gemäß dem OSI-Referenzmodell (Open Systems Interconnection, siehe Abbildung 2.5) beginnt die Betrachtung der Netzwerkarchitektur von VANETs auf der zweiten Schicht, der Sicherungs­schicht. Die Bitübertragungsschicht wird vollständig durch die Hardware vorgegeben, die in diesem Fall durch den IEEE 802.11 Standard definiert ist. Auf der Sicherungsschicht ist für VANETs vor allem die Medienzugriffskontrolle von Bedeutung. Aufgrund deren besonderen Rolle wird diese auch als eigene Unterschicht der Sicherungsschicht (Medienzugriffskontroll- schicht) betrachtet.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.5: OSI Schichtenmodell (Schichten 5-7 zur Anwendungsschicht zusammengefasst)

Bei der Medienzugriffskontrolle geht es darum festzulegen, welche Knoten im Netzwerk wann Zugriff auf ein gemeinsam genutztes Medium erhalten und sicherzustellen, dass Übertragungen auf dem Medium korrekt beim Empfänger ankommen. Auf einem Medium wie einem Kabel oder einem Funkkanal darf immer nur ein Netzwerkteilnehmer gleichzeitig senden, da sich sonst die Übertragungen gegenseitig stören und nicht erfolgreich sind. Operieren lediglich zwei Xetzwerkknoten auf einem Medium und ist Voll-Duplex-Kommunikation durchführbar (d.h, es kann über die Verbindung gleiehzeitig gesendet und empfangen werden), dann besteht keine Gefahr der Übersehneidung von Übertragungen, Operieren jedoeh mehrere Knoten auf dem sel­ben Medium oder zwei Knoten auf einer Halb-Duplex-Verbindung, kann dieser Fall eintreten, was als Kollision bezeiehnet wird, Knoten in einem Netzwerk mit gemeinsam genutztem Medi­um müssen deshalb ein Verfahren implementieren, um sicherzustellen, dass ihre Übertragungen korrekt beim Empfänger ankommen und nicht mit Übertragungen anderer Xetzwerkknoten kollidieren. Dabei gibt es Methoden die eine kollisionfreie Kommunikation ermöglichen, d.h, es treten niemals Kollisionen bei der Übertragung auf. Andere Methoden ermöglichen es lediglich, dass Kollisionen erkannt werden können wenn sie auftreten und die betroffenen Übertragungen werden wiederholt, bis sie erfolgreich sind.

Kollisionsfreie Medienzugriffskontrolle wird in der Praxis derzeit kaum eingesetzt. Sie ist vor allem in konventionellen, kabelgebundenen Netzwerken gut durchführbar. Sie ermöglicht effiziente und vollständig kollisionsfreie Kommunikation auf einem gemeinsam genutzten Me­dium und verschiedene Algorithmen stehen dafür zur Verfügung |Tanenbaum03|, In kabelge­bundenen Netzwerken wird die Problematik des Medienzugriffs jedoeh zunehmend durch die ausschließliche Nutzung von exklusiven Punkt-zu-Punkt-Verbindungen umgangen (d.h, es liegt kein gemeinsam genutztes Medium mehr vor). Das ist zum Beispiel bei Gigabit Ethernet der Fall, wo nur noch Switches zur Verbindung der Teilnehmer vorgesehen sind, bei denen kei­ne Kollisionen auftreten. Dies ist in drahtlosen Ad-Hoc-Xetzen nicht ohne weiteres möglich. Die Funkkommunikation hat immer einen Rundfunkcharakter und alle Teilnehmer in Funk­reichweite müssen sieh einen gemeinsamen Kanal teilen, um miteinander kommunizieren zu können, Funknetzwerke sind gegenüber vielen kabelgebundenen Netzwerken auch meist nur zur Halb-Duplex-Kommunikation fähig und können deshalb nicht gleiehzeitig Daten senden und die Übertragung auf dem Kanal auf Korrektheit überprüfen. Die Fehleranfälligkeit der Kommuni­kation ist bei Nutzung eines Funkmediums insgesamt erheblich höher als bei Kabelnetzwerken, Aus diesen Gründen stellt der Medienzugriff für Funknetzwerke eine deutlich gröfsere Heraus­forderung dar als für kabelgebundene Netzwerke.

Dies gilt insbesondere für Ad-Hoc-Xetzwerke, da hier alle Knoten direkt und ohne Infrastruk­tur miteinander kommunizieren. Daraus ergeben sieh beim Medienzugriff weitere Probleme, die bei infrastrukturgestützten Netzwerken nicht auftreten. Bei Mobilfunknetzen etwa teilt eine Basisstation den Xetzteilnehmern innerhalb der Funkzelle exklusive Sendezeiträume auf einem Kommunikationskanal zu. In IEEE 802.11 Funknetzen im Ad-Hoc-Modus wird jedoeh nur ein Kanal zur Kommunikation verwendet und es existiert keine priviligierte Instanz, die den Kno­ten eine Sendeerlaubnis zuteilt. Deshalb müssen alle beteiligten Knoten kooperativ sicherstellen, dass individuelle Zugriffe auf das gemeinsame Medium gelingen.

Da anders als in einem Kabelnetzwerk, in dem alle Knoten an das Medium angesehlossen sind und sieh gegenseitig erreiehen können, beim Funknetzwerk nicht alle Nutzer des Mediums direkt miteinander kommunizieren können, hat jeder Teilnehmer einen anderen Informationshorizont über die Belegung des Mediums, Im Rahmen der Medienzugriffskontrolle muss daher verhindert werden, dass im Bereich eines Empfängers zwei oder mehr Übertragungen parallel auf dem Medium stattfinden. Da der Sender einer Nachricht jedoch eine andere Knotenmenge erreicht als der Empfänger, reicht es nicht aus, dass sieh der Sender mit seinen Nachbarknoten beim Medienzugriff abspricht. Ein typisches Verfahren, um den Medienzugriff zu koordinieren, ist CSMA (Carrier Sense Multiple Access), Dabei hört ein Sender vor der Durchführung einer Übertragung den Funkkanal ab und sendet nur dann, wenn der Kanal frei ist. Zwei Probleme bei dieser Form der Medienzugriffskontrolle in Funknetzen sind versteckte und ausgelieferte Knoten im Netzwerk, Das Problem der verstecken Knoten ist in Abbildung 2.6 (a) skizziert. Hier möchten die Knoten A und C zu gleicher Zeit eine Nachricht an Knoten B senden, Knoten A hört den Funkkanal ab und stellt fest, dass er frei ist. Deshalb beginnt er mit seiner Übertragung an B, Knoten C hört ebenfalls den Funkkanal ab und hört keine Übertragung, da Knoten C nicht im Senderadius von Knoten A liegt. Deshalb beginnt auch Knoten C mit der Übertragung an B, Bei Knoten B jedoch tritt eine Kollision der Übertragung von Knoten A und C auf. Das Problem des ausgelieferten Knoten wird in Abbildung 2.6 (b) dargestellt. Hier sendet Knoten A an Knoten B eine Nachricht, Knoten C möchte zur gleichen Zeit eine Übertragung an Knoten D durchführen, C prüft jedoch den Funkkanal auf Übertragungen, hört den Kommunikationsvorgang von A an B und führt seine Übertragung deshalb nicht durch. Dennoch könnte die Übertragung von Knoten C and Knoten D erfolgen, da der Empfang der Nachricht von Knoten A bei Knoten B durch die Übertragung von C an D nicht gestört werden würde. Versteckte Knoten sorgen also für fehlerhafte Übertragungen, die wiederholt werden müssen und ausgelieferte Knoten können die volle Bandbreite des Netzes nicht ausnutzen, da aus ihrer Sieht das Medium belegt ist.

Um diese Probleme abzumildern existieren erweiterte Algorithmen für die Medienzugriffs­kontrolle in Funknetzen, Diese weisen jedoch Probleme für den Einsatz in grofśen Ad-Hoe-Netz- werken wie einem VANET auf. Diese Probleme werden im Folgenden anhand des Medienzu­griffsalgorithmus von IEEE 802.11 verdeutlicht, Ansehliefśend werden alternative Algorithmen und Verbesserungsmögliehkeiten für den Medienzugriff vorgestellt.

2.4.1 IEEE 802.11 Medienzugriffskontrolle

Aufgrund der hohen Verbreitung von Funkhardware auf Basis des IEEE 802.11 Standards wird dieser auch meistens bei Betrachtungen der Medienzugriffskontrolle in MANETs als Grundlage

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.6: (a) Problem des versteckten Knotens (b) Problem des ausgelieferten Knotens

herangezogen. Im Folgenden wird ein Überblick über die Funktionsweise der Medienzugriffs­kontrolle, wie sie in IEEE 802.11 durchgeführt wird, gegeben.

Funktionsweise

Bei IEEE 802.11 wird im Ad-Hoc-Modus das CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance) Protokoll für die Kontrolle des Medienzugriffs verwendet [IEEE802.il]. Dieses definiert zwei unterschiedliche Verfahrensweisen.

Im Basismodus wird CSMA wie oben beschrieben durchgeführt. Ein Knoten, der eine Über­tragung durchführen möchte, prüft, ob der Kanal gerade frei ist. Um sicherzustellen, dass der Kanal tatsächlich frei ist und nicht nur eine kurze Übertragungspause stattfindet, wird für ei­ne konstante Dauer abgehört, ob das Medium frei ist. Diese Dauer wird durch die sogenannte IFS-Wartezeit (Interframe Space) vorgegeben (dabei handelt es sich um die minimale Wartezeit zwischen zwei Übertragungen). Ist das Medium für diese Dauer tatsächlich unbelegt, darf der Knoten seine Übertragung durchführen. Ist dies jedoch nicht der Fall, wartet der Knoten so lange ab, bis das Medium für die Dauer eines IFS frei wird. Zu diesem Zeitpunkt ist die Kol­lisionsgefahr auf dem Medium am größten, da es wahrscheinlich ist, dass mehrere Knoten mit Übertragungswunsch auf das Freiwerden des Mediums gewartet haben. Würden diese nun alle sofort mit ihrer Übertragung beginnen, würden leicht Kollisionen auftreten. Deshalb kommt ein Verzögerungsalgorithmus zum Einsatz, der den Wettbewerb der Knoten um das Medium auflösen soll. Dabei handelt es sich um den BEB-Algorithmus (Binary Exponential Backoff), welcher auch bei IEEE 802.3 Ethernet Verwendung findet. Der Algorithmus definiert Zeitschlit­ze geeigneter Länge. Jeder Knoten mit Sendewunsch berechnet eine Zufallszahl die im Intervall [wmin, wmax] liegen muss. Der Knoten wartet so viele Zeitschlitze lang, wie die Zufallfszahl vorgibt. Nach dieser Wartezeit prüft der Knoten erneut, ob das Medium frei ist und führt erst dann seine Übertragung durch. Da diese Wartezeit zufällig gewählt wird, ist die Gefahr, dass zwei oder mehr Knoten gleichzeitig mit der Übertragung beginnen, reduziert. Der Knoten mit der kürzesten Wartezeit erhält den Medienzugriff und die anderen Knoten stellen zu einem späteren Zeitpunkt fest, dass das Medium bereits wieder belegt- ist und müssen wieder in die Wettbewerbsphase eintreten. Es können natürlich weiterhin Kollisionen zwischen gleichzeitigen Übertraungen auftreten. Tritt eine Kollision auf, wird das Intervall aus dem Zufallszahlen ge­wählt werden vergrößert. Die Wahrscheinlichkeit, dass zwei Sender knoten wieder den selben Zeitschlitz wählen, sinkt in diesem Fall also durch das größere Intervall weiter. Die Länge des Intervalls wächst exponentiell mit der Anzahl der Kollisionen. Bei der n — ten Kollision in Folge wird wmax auf 2n — 1 gesetzt. Die Größe des Intervalls ist jedoch auf maximal 1023 Zeitschlitze begrenzt. Nach zehn Kollisionen (n = 10) in Folge wird es also nicht mehr weiter vergößert. Nach 16 erfolglosen Sendeversuchen wird ein Übertragungsfehler gemeldet und die Übertragung verworfen. In Abbildung 2.7 ist der Medienzugriff mittels CSMA und BEB in grafischer Form dar gestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.7: Ablauf einer Übertragung beim CSMA Verfahren von IEEE 802.11

Der erweiterte Modus von CSMA/CA sieht zusätzlich zu dem gerade beschriebenen Ver­fahren den Einsatz von RTS, CTS und ACK Nachrichten (Request To Send, Clear To Send, Acknowledge) auf der Ebene der Sicherungsschicht vor. Ein beispielhafter Kommunikationsvor­gang dazu wird in Abbildung 2.8 dar gestellt. Knoten A möchte an Knoten B eine Nachricht senden. Bevor er die eigentliche Übertragung beginnt sendet er eine RTS-Nachricht an B. Diese fordert von B eine Bestätigung, um mit der eigentlichen Datenübertragung beginnen zu kön­nen. Diese Bestätigung erfolgt durch die Übertragung einer CTS-Nachricht von B an A. Die RTS und CTS-Pakete enthalten ein Feld, das die Dauer der Belegung des Mediums durch die folgende Übertragung angibt. Die an der Kommunikation unbeteiligten Knoten im Funkradius des Knoten A und B lauschen die RTS- und CTS-Nachrichten mit und können aus den darin mitgelieferten Informationen abschätzen, wie lange das Medium belegt sein wird. Aus den so erhaltenen Daten wird ein Zähler für eine Wartezeit verwaltet, während der kein Medienzugriff für die unbeteiligten Knoten möglich ist. Es ist also kein aktives Abhören des Mediums in dieser Zeit notwendig, um festzustellen, ob der Kanal frei ist. Nach dem Empfang der CTS-Nachricht beginnt der Knoten A schließlich mit der Übertragung der Nutzdaten an den Empfänger B. Ist der Sendevorgang abgeschlossen, wartet A eine bestimmte Zeit lange auf die Empfangsbe­stätigung des Knoten B durch eine ACK-Nachricht. Trifft diese nicht rechtzeitig ein, wird die gesamte Übertragung durch eine weitere RTS-Nachricht von A and B wiederholt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.8: IEEE 802.11 CSMA/CA mit Kontrollnachrichten

Durch den erweiterten Modus mit Steuerpaketen wird das rein zufällige CSMA-Verfahren um die explizite Bekanntmachung von Übertragungsvorgängen erweitert. Dies reduziert das Auftreten von Kollisionen. Erhält der Senderknoten die CTS-Nachricht vom Empfängerkno­ten, weiß er, dass alle anderen Netzwerkteilnehmer im eigenen Umkreis sowie im Umkreis des Empfängerknotens über die Übertragung informiert sind und nicht auf das Medium zugrei- fon. Durch diese sender- und empfängerorientierte Medienzugriffskontrolle wird das Problem der versteckten Knoten deutlich reduziert. Wird keine CTS-Xaehrieht vom Empfängerknoten empfangen, weifś der Senderknoten, dass eine Kollision oder ein Übertragungsfehler vorliegt. Dies ist jedoch weniger schwerwiegend als wenn die gesamte Datenübertragung verloren ge­gangen wäre. Das Verfahren erzeugt aber auch Mehraufwand bei der Datenübertragung durch die zusätzlichen Verwaltungsnachrichten. Insgesamt versucht das CSMA/CA-Verfahren, Kolli­sionen lediglich nachträglich aufzulösen bzw. unwahrscheinlicher zu machen. Eine tatsächliche Verhinderung von Kollisionen ist so nicht möglich.

Da Funknetze im Gegensatz zu Kabelnetzwerken unter häufigen Übertragungsfehlern leiden, sieht IEEE 802.11 auch Fragmentierung vor. Da die Wahrscheinlichkeit eines Übertragungs­fehlers mit der Länge der zu übertragenden Xaehrieht steigt, kann ein Paket in kleinere Teile zerlegt werden, die separat übertragen werden. Dies hat den Vorteil, dass bei einem Übertra­gungsfehler nur ein Teil des ursprünglichen Pakets neu übertragen werden muss und nicht das vollständige Paket. Bei Xutzung des RTS/CTS-Verfahrens können diese Paketfragmente auch in Folge übertragen werden ohne für jedes Fragment einen eigenen RTS-Zyklus einzuleiten. Lediglich ACK-Xachrichten werden separat für jedes Fragment übermittelt.

Sowohl das RTS/CTS-Verfahren als auch der Einsatz von Fragmentierung sind gemäfs IEEE 802.11 optional. Entsprechende Parameter können für eine 802.11 Ad-Hoe-Zelle ausgehandelt werden. Dazu gehört die Grofśe der Paketfragmente für das Fragmentierungsverfahren sowie eine Grenze für die Paketgrofśe, ab der das RTS/CTS-Verfahren eingesetzt wird. Letztere ist sinnvoll, da sich für kleine Pakete das RTS/CTS-Verfahren nicht lohnt, da die Kollisions- und Fehler­gefahr gering und das erhöhte Datenaufkommen durch die Steuerpakete relativ zur Paketgrofśe hoch ist. Unter Umständen kann es auch sinnvoll sein, kleinere Pakete zu einer Übertragung zusammenzufassen, um die Anzahl der separaten Medienzugriffe zu reduzieren (nicht bei IEEE 802.11 vorgesehen). Hier muss abgewägt werden, ob die Kollisionsgefahr beim Medienzugriff für viele kleine Pakete schwerer wiegt als die Gefahr der Übertragungsfehler bei grofśeren Paketen.

Probleme von CSMA/CA mit Kontrollnachrichten

Die erweiterte Medienzugriffskontrolle mit RTS/CTS-Kontrollnachrichten soll gegenüber dem einfacheren Verfahren insbesondere die Probleme mit versteckten Xetzwerkknoten auflösen. Mit Hilfe der Kontrollnachrichten wird diese Konstellation entschärft, da sowohl der Sender als auch der Empfänger ein Kontrollpaket versenden, um die umliegenden Knoten auf die Übertragung aufmerksam zu machen. In VAXETs jedoch bleibt dieses Problem unter Umständen weiterhin bestehen, da die Knoten sehr mobil sind und die Xetzwerktopologie sich ständig ändert. Weiter­hin sind Übertragungsfehler im Funkverkehr abhängig von Ort und Zeit. Es kann also der Fall eintreten, dass der Austausch von Kontrollpaketen zweier Knoten erfolgreich verläuft aber ein unbeteiligter Knoten aufgrund von Übertragungsfehlern in seinem Empfangsbereich eine RTS- oder CTS-Xaehrieht nicht empfangen konnte. Dieser würde dann ggf, mangels Kenntnis des Übertragungsvorgangs trotzdem auf das Medium zugreifen und somit Kollisionen verursachen. Das Problem des ausgelieferten Xetzwerkknoten wird mit Hilfe des CSMA/CA-Verfahrens nicht entschärft. Da ein Knoten nicht feststellen kann, ob sein Übertragungswunsch die Kommunika­tion einer bereits ablaufenden Übertragung beeinflusst, muss er weiterhin davon ausgehen, dass keine Übertragung möglich ist so lange der fremde Kommunikationsvorgang nicht abgeschlossen ist.

Ein weiterer Problempunkt von CSMA/CA ist die mangelnde Gleichberechtigung unter den Knoten im Ad-Hoe-Xetzwerk |MOkM06|, |GlaW04|, |KKB2000|, |Gruber05|, |Gikaru04|, Für ein VAXET ist es essenziell, dass alle Knoten gleich behandelt werden und gleiehmäfsig Zugriff auf das Medium erhalten. Diese Gleichberechtigung ist durch CSMA/CA nicht gegeben. Der BEB-Algorithmus bevorzugt beim Wettbewerb um den Zugriff auf den Funkkanal den Knoten der zuletzt eine Übertragung erfolgreich durehgeführt hat. Konkurrieren zu einem Zeitpunkt mehrere Knoten um den Kanal warten die beteiligten Knoten immer längere Intervalle ab, um danach zu prüfen, ob der Zugriff nun möglich ist. Ein Knoten jedoch, der den Medienzugriff erhalten und seine Übertragung abgeschlossen hat, kann in den Wettbewerb um den Medien­zugriff sofort wieder mit minimaler Wartezeit eintreten, d.h, er kann sofort den Zugriff auf den Kanal versuchen. Da die anderen Knoten, die sieh schon zuvor im Wettbewerb um den Kanal befunden haben, noch eine Wartezeit ablaufen lassen, weil der Kanal belegt war, haben diese eine geringere Chance, den Zugriff auf den Kanal zu erhalten. Darüber hinaus hängt der gleich­berechtigte Medienzugriff auch von der Position eines Knotens in der Xetzwerktopologie ab, Xaturgemäfs erhalten die Knoten, die sieh in räumlich besonders dicht mit Knoten besiedelten Regionen befinden, weniger Medienzugriff gegenüber Knoten, die sieh in Xetzwerkteilen aufhal­ten, in denen weniger Konkurrenz um den Medienzugriff herrscht, Aufśerdem sorgen die Effekte der versteckten und ausgelieferten Knoten dafür, dass manche Knoten kaum zur Übertragung kommen, weil diese mit den Übertragungen anderer Knoten kollidieren, die sieh gegenseitig nicht hören können und deshalb der RTS/CTS-Meehanismus an dieser Stelle nicht greift.

Ein Aspekt, der besonders VAXETs betrifft, ist der Einfluss von Rundfunknachrichten auf die Medienzugriffskontrolle, Rundfunknaehriehten sind an alle Knoten gleichzeitig gerichtet, die die Xaehrieht hören können. Der Anteil von Rundfunknaehriehten wird in VAXETs aufgrund der Xatur des Xetzwerks und seiner Applikationen sehr hoch sein. In diesem Fall können RTS/CTS- Steuerpakete nicht mehr verwendet werden, weil es keinen einzelnen Empfänger mehr gibt, der mit CTS- und ACK-Xaehriehten antworten kann. Deshalb fällt CSMA/CA bei Rundfunknaeh- richten auf den einfacheren CSMA-Modus zurück, Kollisionen können bei Rundfunk weiterhin nicht erkannt werden, da Übertragungsfehler bei jedem Empfängerknoten individuell auftreten können. Der Sender einer Rundfunknachricht kann also nicht feststellen, welche seiner Xaeh- barknoten seine Xaehrieht tatsächlich erhalten haben und welche nicht. Da die Rundfunknach­richten ohne Ankündigung mittels RTS versendet werden, können diese leichter den regulären Datenverkehr, der mit RTS/CTS-Kontrollnaehriehten gesichert ist, stören.

Analysen in |GlaW04| ergeben, dass Medienzugriffsprotokolle ohne Kollisionsvermeidung grundsätzlich schlechter abschneiden als diejenigen mit Kollisionsvermeidung, Dies gilt insbe­sondere für Übertragungen von grofśen Paketen, da bei diesen der Medienzugriff länger dauert und die Gefahr einer Kollision gröfser ist als für kleine Datenpakete, Trotz des Mehraufwands, der durch die Kollisionsvermeidung entsteht, ist laut der Analyse das RTS/CTS-Verfahren selbst bei kleinen Paketen noch vorteilhaft gegenüber einfachem CSMA, Trotz dieser Feststellung zeigt sich, dass die Kollisionsvermeidung mit RTS/CTS-Paketen sehr schlecht skaliert. Selbst wenn von einer perfekten Kollisionsvermeidung ausgegangen wird (d.h, es wird angenommen, dass CSMA/CA alle Kollisionen verhindern kann), sinkt der Durchsatz drastisch mit der Erhöhung der Teilnehmerzahl, Dies liegt daran, dass mit zunehmender Teilnehmerzahl immer mehr Zeit mit Selbstverwaltung verbraucht wird. Es erhöht sich mit der Teilnehmerzahl auch die Anzahl der versteckten und ausgelieferten Knoten, Dadurch verbringt die Kollisionsvermeidung immer mehr Zeit in der Wettbewerbsphase und Bandbreite bleibt ungenutzt. Das RTS/CTS-Verfahren leidet weiterhin unter der Mobilität in VAXETs, da sich die lokale Xetzwerktopologie ständig ändert. Es kann damit häufiger Vorkommen, dass die RTS/CTS-Xaehriehten nicht gehört wer­den, weil zum Beispiel ein Xaehbarknoten sich gerade erst in die Funkreichweite bewegt hat.

Dass IEEE 802.11 im Ad-Hoe-Modus nur sehr schlecht mit steigender Teilnehmerzahl skaliert, zeigen auch weitere Auswertungen, Schon ab einer Xetzwerkdiehte von fünf bis zehn Knoten im Funkradius bricht der Durchsatz deutlich ein |GlaW04|, |WGla04|, |MOkM06|, In |RLP2000| wird darüber hinaus gezeigt, dass die Wahl des Medienzugriffsalgorithmus relevanten Einfluss auf höher liegende Xetzwerksehiehten wie die Vermittlungssehieht und deren Routingprotokolle hat. Da in VAXETs bei Funkreichweiten von mehr als hundert Metern im dichten Strafsenver- kehr schnell mehr als hundert Teilnehmer in unmittelbarer Funkreichweite zueinander liegen, kann das IEEE 802.11 Medienzugriffsverfahren nicht eingesetzt werden. Die Kommunikation würde voraussichtlich aufgrund der hohen Anzahl von Kollisionen und einem hohen Mehrauf­wand durch Kontrolldaten vollständig zum Erliegen kommen. Zudem ist es nicht tragbar, dass Ungleichbehandlung der Knoten beim Medienzugriff herrscht. Da VAXETs von der gemeinsa­men Kooperation aller Xetzwerkknoten leben, muss allen Knoten gleiehermafśen der Medien­zugriff ermöglicht werden. Es müssen also andere Verfahren für die Medienzugriffskontrolle in VAXETs gefunden werden.

Das für gröfsere Ad-Hoe-Xetze ungeeignete Medienzugriffsverfahren von IEEE 802.11 lässt sieh wohl damit erklären, dass die primäre Anwendung von IEEE 802.11 WLAX in der Kom­munikation mit einer Basisstation liegt. Es stellt damit eher eine drahtlose Erweiterung exi­stierender, auf Ethernet basierender LAXs dar. Bei der Kommunikation mit einer Basisstation übernimmt diese die Zuteilung der Sendezeiten an die vorhandenen Teilnehmer und der gesamte Funkverkehr läuft über sie ab. Der Ad-Hoe-Modus, in dem die Teilnehmer direkt miteinander kommunizieren, wird hingegen eher als Sonderfall vernaehlässigt. In den folgenden Absehnitten werden nun mögliehe Verbesserungen an CSMA/CA sowie alternative Verfahren zur Medien­zugriffskontrolle vorgestellt, die den Anforderungen von VAXETs entgegenkommen.

2.4.2 Verbesserung der Gleichberechtigung

Änderung des BEB-Algorithmus

Eine Möglichkeit, Durchsatz und Gleichberechtigung der Medienzugriffskontrolle von IEEE 802.11 zu verbessern, wird in |MOkM06| beschrieben und in einer Simulation untersucht. Die Idee ist, lediglich den Verzögerungsalgorithmus auszuwecheln, der immer dann zum Zu­ge kommt, wenn Wettbewerb um den Kanalzugriff entsteht. Der in 2.4.1 beschriebene BEB- Algorithmus wurde durch einen logarithmischen Verzögerungsalgorithmus ersetzt. Bei diesem wird im Gegensatz zu BEB die Wartezeit nicht exponentiell sondern lediglich logarithmisch erhöht, wenn der Zugriff auf das Medium nicht gelingt.

Dieser Ansatz verringert die Gefahr von Ungleichbehandlung der Knoten im Xetzwerk, da die Wartezeiten nicht so extrem wachsen wie bei BEB, Ein Knoten, der erfolgreich übertragen hat und mit dem Initialwert für die Wartezeit wieder in Konkurrenz mit den anderen bereits wartenden Knoten tritt, hat daher keinen so starken Vorteil mehr. Der vorgeschlagene Algorith­mus zeigt im simulativen Vergleich mit dem originalen BEB-Algorithmus ein gleiehmäfsigeres, stabileres Verhalten und in vielen Situationen einen etwas höheren Durchsatz im Xetzwerk, Das Grundproblem, dass dieses Medienzugriffsverfahren schlecht mit der Anzahl der Knoten im Xetzwerk skaliert, bleibt jedoch unverändert. Die Ergebnisse dieses Ansatzes zeigen, dass bereits geringe Änderungen am Verhalten der Knoten in der Wettbewerbsphase eine gleichmä- Isigere Verteilung des Medienzugriffs über die Knoten erlauben. Auch die Leistungsfähigkeit des Ad-Hoc-Xetzes wird durch die Art und Weise des Wettbewerbs um den Kanal — wenn auch in diesem Fall gering — beeinflusst.

Überarbeitung von 802.11

In [GlaW04] wird ein umfassendes Rahmenwerk zur Verbesserung der Gleichbehandlung in IEEE 802.11 vorgeschlagen. Dieses besteht aus vier Komponenten. Zum einen wird der Aus­tausch von Datenflussinformationen zwischen den Knoten vorgeschlagen. Eine Anpassung des BEB-Algorithmus ähnlich dem Vorschlag im vorherigen Abschnitt gehört ebenfalls dazu. Wei­terhin wird eine Erweiterung der senderbasierten Kollisionsvermeidung um eine empfänger­basierte Kollisionsvermeidung vorgesehen. Die letzte Komponente des Rahmenwerks ist der Umgang mit Zwei- Wege-Datenflüssen.

Der Austausch von Datenflussinformationen soll verhindern, dass durch verstecke Knoten und ähnliche ungünstige Netzwerktopologien Ungleichberechtigung entsteht. Die Notwendigkeit dessen wird in Abbildung 2.9 gezeigt. In dieser Topologie kann C alle Übertragungen von Knoten A, B und D hören. Daher weiß Knoten C, dass sowohl Knoten A als auch Knoten D Senderknoten sind. Jedoch wissen A und D bzw. B und D nichts voneinander. Deshalb kommt es zu Kollisionen bei C durch die Übertragungen von A und D, die sich nicht mittels RTS/CTS abstimmen können, da die RTS-Nachricht von Knoten D von A und B nicht gehört wird und diese ggf. auch Knoten C aufgrund der auftretenden Kollisionen nur schwierig erreicht. Würde jedoch Knoten C sein Wissen um die Datenflüsse zwischen A und B sowie D und C mit seinen Nachbarn austauschen, könnten die Kollisionen und damit auch die Ungleichbehandlung zwischen den Übertragungen reduziert werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.9: Netzwerktopologie, die unter Ungieichberechtigung bei Einsatz des RTS/CTS- Mechanismus leidet. Beispiel übernommen aus [GlaW04]

Für die Anpassung des BEB-Algorithmus wird vorgeschlagen, dass die Erkenntnisse die durch den Austausch von Datenflussinformationen entstehen, eingesetzt werden, um den Algorithmus an die tatsächliche Situation im Netzwerk anzupassen. Dazu wie Dauer des Medienzugriffs, die die verschiedenen Datenflüsse erhalten genutzt, um den Datenflüssen den Vorzug zu geben, die bisher weniger Medienzugriff erhalten haben. Ein solcher adaptiver BEB-Algorithmus verspricht wesentlich bessere Gleichberechtigung als das statische Verfahren des Standardalgorithmus.

Eine Konstellation, in der empfängerbasierte Kollisionsvermeidung sinnvoller ist als sender­basierte, ist in Abbildung 2.10 zu finden. Der Datenfluss von Knoten A nach Knoten B erleidet in dieser Topologie deutliche Ungleichberechtigung, da Knoten C die CTS-Nachrichten von Knoten D erfolgreich empfängt, während die RTS-Nachrichten von Knoten A bei Knoten B mit den Übertragungen von Knoten C kollidieren. Würde jedoch nun nicht Knoten A die Kol­lisionsvermeidung für seinen Datenfluss an B übernehmen, sondern der Empfänger Knoten B, dann könnte die Aufteilung des Medienzugriffs zwischen den beiden konkurrierenden Datenflüs­sen besser gelingen, da Knoten B direkt mit Knoten C kommunizieren kann. Deshalb zielt das Rahmenwerk aus [GlaW04] auf einen dynamischen Wechsel zwischen herkömmlicher, sender­basierter Kollisionsvermeidung und einer empfängerbasierten Kollisionsvermeidung ab. Dieser Wechsel ist abhängig davon, ob der Sender oder der Empfänger die geeignetere Position zur Regelung des Medienzugriffs besitzt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.10: Einsatzszenario für empfängerbasierte Medienzugriffskontrolle zur Verbesse­rung der Gleichberechtigung. Beispiel übernommen aus [GlaWO lJ

Die letzte Komponente des Rahmenwerks, der Umgang mit Zwei-Wege-Datenflüssen, be­zieht sich auf das Verhalten von Transportprotokollen wie TCP. Beim TCP-Protokoll werden neben den reinen Datenübertragungen zusätzlich Bestätigungspakete verschickt, um die erfolg­reiche Datenübertragung mitzuteilen und den Datenfluss zu kontrollieren. Diese Pakete sind ähnlich den ACIv-Paketen beim RTS/CTS-Verfahren auf der Medienzugriffsschicht lediglich auf der höheren Transportschicht, weshalb diese speziellen Bestätigungspakete für das Medi­enzugriffsprotokoll nicht von normalen Datenübertragungen unterscheidbar sind. Aufgrund des Medienzugriffs entsteht jedoch oftmals der Zustand, dass zwar der Nutzdatenteil einer Über­tragung, die auf der Ebene der Transportschicht vorgenommen wurde, erfolgreich übermittelt werden konnte. Aufgrund der Konkurrenz um den Kanal für die Übertragung des Bestätigungs­pakets vom Empfänger zurück an den Sender ist jedoch für längere Zeit kein Medienzugriff mehr möglich. Dies bedeutet für den Sender auf der Transportschicht, dass er mit seiner Über­tragung nicht fortfahren kann, bis der Empfänger den Medienzugriff erhalten hat und somit das Bestätigungspaket versenden kann. Diese Verzögerung sorgt für einen deutlichen Einbruch des Durchsatzes von Transportprotokollen in Ad-Hoe-Xetzwerken (siehe auch Abschnitt 3.5), Deshalb sieht das Rahmenwerk für den Medienzugriff vor, dass die Transportsehieht der Si- eherungssehieht mitteilt, wenn zu einer Datenübertragung noch eine zweite Übertragung vom Empfänger zurück an den Sender zugehörig ist. Dabei handelt es sieh um einen sogenannten Zwei-Wege-Datenfluss, Wenn die Sieherungssehieht über diesen Sachverhalt Kenntnis hat, kann sie diese Information an die Xaehbarknoten mitteilen, damit der Empfängerknoten des ersten Teils der Übertragung sofort nach Empfang seiner Daten seinerseits Zugriff auf das Medium erhält, um das (verhältnismäßig kleine) Bestätigungspaket an den Sender zuriiekzusehieken. Dadurch erhält das Transportprotokoll sofort die Möglichkeit wieder um den Medienzugriff zur Fortsetzung der Datenübertragung zu konkurrieren und es tritt keine Verzögerung ein.

Die konkrete Implementierung der vier Komponenten dieses Rahmenwerks zu beschreiben, würde den Rahmen dieser Arbeit sprengen. Die Grundideen sind sehr vielversprechend und Si­mulationen der Autoren zeigen eine deutliche Verbesserung der Gleiehbehandlung beim Medi­enzugriff im Vergleich zum normalen IEEE 802.11 Protokoll, Während beim Standardverfahren einige Knoten nahezu gar keinen Zugriff auf das Medium erhalten, ermöglichen die erweiterten Mechanismen des Rahmenwerks einen gleichmäßigen Zugriff für alle Xetzwerkknoten, Insbe­sondere das Transportprotokoll TCP zeigte ein deutlich besseres Verhalten, Der absolute Da- tendurehsatz war zwar etwas geringer als beim Standardverfahren, doch ist diese Verringerung gegenüber der Herstellung der Gleichberechtigung zu vernachlässigen.

2.4.3 Einsatz mehrerer Funkkanäle

Um den Wettbewerb auf dem Funkkanal zu verringern, kann man die Kommunikation auf mehr als eine Funkfrequenz ausdehnen. Dies kann geschehen, indem man beispielsweise das existie­rende Frequenzband in mehrere, kleinere Frequenzbänder einteilt, die unabhängig voneinander verwendet werden können. Dies muss natürlich die verwendete Funkhardware unterstützen. Darüber hinaus ist für die Verwendung mehrerer Frequenzbänder jedoch üblicherweise Basis­stationen und damit Infrastruktur notwendig, die den Teilnehmern freie Kanäle über einen gemeinsamen Steuerkanal zuteilen. Dies geschieht im Mobilfunk (GSM) auf diese Weise.

Da ein VAXET ohne Infrastruktur auskommen soll, der Einsatz mehrerer Kanäle jedoch viel­versprechend für die Optimierung des Medienzugriffs ist, werden auch Möglichkeiten betrachtet, die Kanäle dezentral und kooperativ in einem Ad-Hoe-Xetzwerk zuzuteilen. Ein Vorschlag für ein solches Verfahren findet sieh in |KMRKS03|, Darin wird über der geographischen Fläche des VAXETs eine Zellstruktur definiert, die allen Knoten im Xetzwerk bekannt ist. Über die Position eines Knotens im VAXET können jedem Knoten eine oder mehrere Zellen zugeordnet werden. Jeder dieser Zellen ist ein bestimmer Kommunikationkanal zugewiesen. Diesen Kom- munikationskanal verwendet der Knoten während seines Aufenthalts innerhalb einer Zelle, um Daten an andere Knoten innerhalb der Zelle zu senden. Um Daten mit Nachbarknoten in an­grenzenden Zellen auszutauschen muss der Teilnehmer auf den Kanälen kommunizieren, die den Zellen zugeordnet sind in denen sich der jeweilige Zielknoten befindet. Abbildung 2.11 zeigt ein Beispiel für dieses Medienzugriifsverfahren. Dort existieren vier Zellen mit vier unterschiedli­chen Frequenzen, die den vier Farben entsprechen.

Je kleiner die Zellen in diesem Ansatz gewählt werden, desto weniger Konkurrenz um das Medium entsteht. Im Optimalfall werden die Zellen so klein gewählt, dass jede Zelle genau einen Teilnehmer enthält und damit gar keine Konkurrenz mehr um den der Zelle zugeteilten Funkkanal herrscht. Auf der anderen Seite sollten die Zellen aber groß genug sein, dass ein Knoten im VANET die Gelegenheit bekommt, für eine angemessene Dauer den Kanal verwenden zu können bevor er sich in einer neuen Zelle befindet. Deshalb können auch mehrere Teilnehmer pro Zelle existieren, die ihrerseits in lokal begrenzte Konkurrenz um den Kanal treten, z. B. über das CSMA/CA Verfahren.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.11: Beispiel der Kommunikation mit mehreren Funkfrequenzen. Hier existieren vier Zellen mit vier unterschiedlichen Funkfrequenzen (entsprechend den Far­ben).

Die Autoren schlagen die Begrenzung auf einen Teilnehmer pro Zelle vor. Bei hohen Be­wegungsgeschwindigkeiten sind so nur noch geringe Ubertragungsraten zwischen Teilnehmern möglich, bevor die Zelle eines Knotens und damit der Funkkanal gewechselt wird. Es wird hier argumentiert, dass für sicherheitskritische Anwendungen nur Übertragungen in der Größenord­nung von einigen hundert Bytes notwendig sind und diese Beschränkung folglich hinnehmbar ist. Weiterhin wird die Notwendigkeit beschrieben, dass innerhalb der Kommunikationsreich- weite eines Teilnehmers der Kanal, der der Zelle dieses Teilnehmers zugewiesen wurde, nicht noch einmal in einer anderen Zelle eingesetzt werden darf. Dies ist notwendig, um Kollisio­nen in entfernten Zellen zu vermeiden. Entweder man setzt eine genügend grofśe Anzahl von verschiedenen Funkkanälen ein, um diese Bedingung zu erfüllen, oder der Sender passt seine Übertragungsstärke an, um nicht mit entfernten Zellen mit gleichem Funkkanal zu kollidieren. Das vorgeschlagene Protokoll löst tatsächlich mehrere Problemstellungen herkömmlicher Me­dienzugriffverfahren, Die Konkurrenz um das Medium kann ganz umgangen oder nach oben beschränkt werden. Dies sorgt für die notwendige Skalierbarkeit, die für VAXETs notwendig ist, Kollisionen werden damit weitgehend vermieden und die Zuverlässigkeit des Netzes steigt, Mobilität wird vom Verfahren berücksichtigt, wobei jedoch das Problem der geringen maxi­malen Kommunikationsdauer auf einem Kanal mit der Bewegungsgeschwindigkeit der Knoten zunimmt. Insbesondere zeigt der Ansatz, dass die dezentrale Zuweisung von Funkkanälen an Xetzwerkteilnehmer effizient möglich sein kann, auch ohne unnötige Komplexität zu erzeugen.

2.4.4 Intelligente Antennen

Eine weitere vielversprechende Möglichkeit, um die Leistungsfähigkeit von VAXETs zu erhöhen, ist der Einsatz von sogenannten intelligenten Antennen, Intelligente Antennen unterscheiden sieh von konventionellen Antennen dadurch, dass ihr Verhalten dynamisch gesteuert werden kann. Dies bezieht sieh einmal auf die Übertragung stärke und damit auf die Reichweite einer Übertragung, Weiterhin kann nicht mehr nur im Rundfunk, also omnidirektional, sondern auch direktional gesendet und empfangen werden. Dies hat zum einen den Vorteil, dass der direktio- nale Funk höhere Reichweiten realisieren kann als der omnidirektionale, da mehr Energie für das Senden in die spezifische Richtung zur Verfügung steht und der Antennengewinn steigt. Der Hauptvorteil für den Medienzugriff ist jedoch, dass sieh die Belegung des Mediums und damit dessen Sperrung für andere Knoten im Netzwerk nicht mehr auf das gesamte Umfeld eines Senderknotens erstreckt, sondern nur noch auf den räumlichen Bereich, der tatsächlich für die Kommunikation zwischen Sender und Empfänger benötigt wird. Als Ergebnis hat man eine wesentlich höhere räumliche Wiederverwendung des Funkmediums, Auch die Drosselung der Übertragungsenergie kann sieh in diesem Zusammenhang als sinnvoll erweisen, wenn etwa mit einem Xachbarknoten kommuniziert wird, der nicht weit entfernt ist.

An entsprechender Funkhardware, die solche Möglichkeiten mitbringt wird geforscht bzw, diese ist teilweise bereits verfügbar. Im Fall von VAXETs können natürlich keine mechanisch steuerbaren Antennen verwendet werden. Hingegen muss die Steuerung der Antenne vollständig elektronisch ablaufen. Die Grofśe der Antenne darf die von herkömmlichen Antennen nicht wesentlich überschreiten, um die Integrierbarkeit in das Fahrzeug und vorhandene Systeme zu gewährleisten, Probleme können bei der direktionalen Kommunikation mit Abstrahlungen in andere Richtungen auftreten. Die Übertragung vollständig auf eine Richtung zu beschränken, kann sieh schwierig gestalten, so dass in geringem Mals auch in andere Richtungen Energie abgestrahlt wird. Die Art der direktionalen Übertragung kann entweder in Stufen vorliegen, d.h, es existieren z, B, acht 45 Grad Winkel von denen man einen auswählen kann, oder es kann stufenlos eine Senderichtung konfiguriert werden. Im Folgenden wird davon ausgegangen, dass bei der Hardware keine Beschränkungen bestehen, also Übertragungsenergie und -richtung beliebig gewählt werden können.

Für das RTS/CTS-Verfahren zur Kollisionsvermeidung stellt die Verwendung von intelli­genten Antennen zunächst eine Erhöhung der Komplexität dar. Würden nur noch direktional Steuernachrichten zwischen Knoten ausgetauscht, dann wüssten nicht mehr alle Teilnehmer in der Umgebung von einer bevorstehenden oder ablaufenden Übertragung, In der Folge kön­nen Kollisionen auftreten, wenn sieh zwei direktionale Übertragungen überschneiden. Deshalb besteht die Möglichkeit, die Kontrollpakete auf herkömmliche Weise omnidirektional zu über­tragen, während der eigentliche Datenverkehr nur direktional übertragen wird. Dies hätte zur Folge, dass nicht mehr jeder Xaehbarknoten im Netzwerk, der eine RTS-Xachricht empfängt, nicht auf das Medium zugreifen darf, da ja nur eine direktionale Übertragung angekündigt wird. Die Xaehbarknoten werden dadurch lediglich darüber informiert, dass ein bestimmter räumlicher Bereich im Netzwerk durch eine direktionale Datenübertragung belegt ist, was nur einige Knoten in der Umgebung betreffen wird. Würde der Steuerverkehr hingegen direktional nur in die Richtung gesendet, in der der Empfänger sieh befindet, könnten andere Xaehbarkno­ten nicht mehr mit Sicherheit feststellen, ob sie in einem bestimmten Xetzwerkbereich derzeit senden dürfen. Dies ist in Abbildung 2.12 verdeutlicht. Bei C entsteht eine Kollision durch die gleichzeitige direktionale Übertragung von A und D, Da RTS/CTS-Xachrichten nur direktional gesendet wurden, konnte D keine Kenntnis über den Übertragungsvorgang zwischen A und B haben.

In |KK04| werden verschiedene Medienzugriffsverfahren für intelligente Antennen disku­tiert, Es existieren vielfältige Ansätze, um das direktionale Senden ausnutzen und gleichzeitig die zusätzlichen Kollisionsgefahren, die dadurch entstehen können, zu lindern. In RTS/CTS- Xachrichten, die im omnidirektionalen Modus versendet werden, können die Positionskoordi­naten von Sender und Empfänger eingebettet werden, so dass umliegende Knoten feststellen können, ob sie von der bevorstehenden Kommunikation betroffen sind oder nicht. Andere Ansät­ze mischen omni- und direktionales Senden von RTS und CTS-Xachrichten. RTS-Xachrichten können zum Beispiel immer direktional versendet werden, während die CTS-Xachrichten om­nidirektional versendet werden. Alle Knoten, die die CTS-Xachricht hören, merken sieh die

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.12: Kollision, die bei rein direktionalem Senden von Kontroli- und Nutzdatenver­kehr entsteht

Richtung in der sie deshalb nicht kommunizieren können. Dieses Vorgehen sorgt daher nur beim Empfängerknoten für Kollisionsvermeidung, weil in seiner Umgebung auch das größte Risiko für Kollisionen durch Übertragungen anderer Knoten besteht. Dennoch bleibt die Ge­fahr bestehen, dass aufgrund der direktionalen RTS-Naehricht eine Reihe von Knoten in der Umgebung des Senders nichts von der ablaufenden Übertragung wissen und beim Empfänger­knoten eine Kollision verursachen. Deshalb besteht die Möglichkeit die RTS-Nachricht optional auch omnidirektional zu versenden für den Fall, dass derzeit keine Richtung der Antenne durch RTS/CTS-Nachrichten als blockiert gemerkt ist.

Neben der geringeren räumlichen Blockierung durch direktionale Kommunikation bietet auch die höhere Reichweite, die dadurch realisiert werden kann einige Vorteile. Netzwerkpartitionen, die bei ausschließlich omnidirektionalem Datenaustausch auftreten würden, können gegebe­nenfalls durch die höhere Reichweite direktionaler Kommunikation wieder zusammengeführt werden. Für Routing- und Rundfunkmechanismen würde die höhere Reichweite zudem kürzere Routen bzw. schnellere Verbreitung von Nachrichten im Netz bedeuten. Jedoch führt dies zu einer weiteren Problemstellung: Werden omnidirektionale und direktionale Übertragungsverfah­ren wie zuvor beschrieben gemischt, kommt es vor, dass einige Knoten zwar die direktionalen Nachrichten mit hoher Reichweite empfangen können, jedoch nicht die omnidirektionalen. Dies führt zu weiterer Kollisionsgefahr z. B. durch nicht erhaltene omnidirektionale Kontrollnach- richten weit entfernter Knoten, die mittels direktionaler Übertragung eine Kollision verursachen können.

Schließlich bringt das direktionale Empfangen von Nachrichten weitere Eigenheiten in der Funkkommunikation mit sich. Während zwei Knoten bereits einen Kommunikationsvorgang im direktionalem Modus durchführen, sind diese für eine Reihe anderer Knoten nicht erreich- bar, was als Taubhe.it der betroffenen Knoten bezeichnet wird. Diese entsteht dadurch, dass beide Knoten ihre Antenne auf direktionalen Empfang in der Richtung ihres Kommunikati­onspartners ausgerichtet haben. Möchte nun ein dritter Knoten außerhalb dieses direktionalen Empfangbereichs mit einem der beiden Knoten kommunizieren und sendet eine RTS-Xachricht, wird der angesprochene Knoten diese Nachricht nicht hören können. Das führt dazu, dass der dritte Knoten aufgrund der fehlenden Antwort davon ausgeht, dass es eine Kollision gab (gern, IEEE 802.11 Protokoll) und wird in die Wettbewerbsphase eintreten, um weitere vermeint­liche Kollisionen zu vermeiden. Dauert die direktionale Kommunikation zwischen den beiden ersten Knoten länger an, wird der dritte Knoten nach einiger Zeit davon ausgehen, dass der gewünschte Knoten im Netzwerk nicht erreichbar ist und die Übertragung abbrechen.

In |WGla04| wird ein mathematisches Modell zur Bewertung von omnidirektionalen, gemischt omnidirektional und direktionalen sowie rein direktionalen Übertragungswegen in Ad-Hoc- Netzwerken erarbeitet und die Ergebnisse in einer Simulation überprüft. Die Autoren kommen zu dem Ergebnis, dass es sieh am meisten lohnt ausschließlich direktionalen Datenverkehr (also auch für Steuernachrichten) zu verwenden, da in diesem Fall der Durchsatz, die Latenzzeit und die Kollisionsrate wesentlich besser sind als bei ausschließlicher oder gemischter Verwendung von omnidirektionaler Kommunikation, Insbesondere in Situationen mit einer großen Knoten­dichte in der Umgebung, in denen das IEEE 802.11 Protokoll sehr schlecht skaliert, zeigen sieh in der Simulation für die rein direktionalen Verfahren Verbesserungen um den Faktor fünf und höher bei Durchsatz und Latenz, Außerdem zeigt sieh, dass eine geringere Übertragungsreich­weite ebenfalls deutliche Vorteile für den Medienzugriff mit sieh bringt. Weiterhin untersucht die Arbeit den Einfluss von notwendigerweise omnidirektional übertragenen Rundfunknachrich­ten auf den Durchsatz direktionaler Verbindungen, was für VAXETs von besonderer Bedeutung ist, da dort ein hoher Anteil an Rundfunknachrichten beim Datenverkehr vorliegt. Die Simu­lationen ergeben, dass der Durchsatz beim direktionalen Verkehr mit der Erhöhung der Rund­funkverkehrs nur linear abnimmt. Untersucht wurden Rundfunkanteile von bis zu 30 Prozent am Gesamt verkehr. Dieser Anteil könnte bei VAXETs jedoch noch deutlich höher liegen.

Im Folgenden werden einige konkrete Ansätze zur optimierten Anwendung von intelligenten Antennen vorgestellt.

Multi-Hop RTS MAC Protocol (MMAC)

Das MMAC Protokoll |CYRV02|, |KK04| versucht die Vorteile der erhöhten Reichweite und erhöhten räumlichen Nutzbarkeit des Mediums durch den Einsatz intelligenter Antennen zu maximieren, während die beschriebenen Probleme wie Kollisionen und Taubheit ignoriert wer­den, Hierbei soll die Kommunikationsreichweite noch weiter dadurch erhöht werden, dass nicht nur direktional gesendet wird, sondern auch direktional empfangen wird. Dies erhöht die reali­sierbare Reichweite weiter, erfordert jedoch, dass ein weit entfernter Empfänger seine Antenne in die korrekte Empfangsrichtung ausrichtet. Zu Beginn eines Ubertragungsvorgangs weiß der Empfängerknoten zunächst nichts vom Ubertragungswunsch des Senderknotens. Der Sender kann den Empfänger ggf. omnidirektional aufgrund einer zu hohen Entfernung nicht erreichen. Direktional ist auch keine Kommunikation mit dem Empfänger möglich, weil dieser erst seine Antenne korrekt ausrichten muss. Deshalb wird bei einem Kommunikationswunsch zweier weit voneinander entfernten Knoten zunächst eine omnidirektionale Nachricht über Nachbar knoten vom Sender zum Empfänger weitergeleitet. Diese weitergeleitete Nachricht enthält die Auffor­derung an den Empfängerknoten, seine Antenne auf den Senderknoten auszurichten, um eine beiderseitige direktionale Kommunikation zu ermöglichen. Ist dies geschehen kann eine direktio- nale Übertragung der beiden Knoten, unter Maximierung der Reichweite und Minimierung der belegten Fläche des Funkmediums statthnd3n. Ein Beispiel für dieses Protokoll ist in Abbildung 2.13 aufgeführt. Knoten A möchte mit Knoten D kommunizieren, welcher jedoch außerhalb der omnidirektionalen Reichweite liegt. Deshalb sendet Knoten A eine omnidirektionale Nachricht über B und C an D mit der Anforderung einer direktionalen Übertragung. Richtet D nun seine Antenne nach A aus, kann A direktional und direkt an Knoten D übertragen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.13: Das MMAC Protokoll: Multi-Hop-Übertragungen werden eingesetzt, um den Empfänger zum Ausrichten der direktionalen Antenne aufzufordern

Die simulative Analyse dieses Algorithmus hat ergeben, dass Netzwerktopologien, die in Li­nien oder Gittern angeordnet sind, mit diesem Verfahren aufgrund der zusätzlichen Kollisionen und Taubheit wenig Vorteile erfahren, während zufällig strukturierte Topologien bessere Ergeb­nisse zeigen. Dies lässt befürchten, dass gerade in VANETs, in denen die Netzwerktopologie sich am Straßennetz ausrichtet, keine so starken Vorteile zu erwarten sind. Im Optimalfall jedoch konnten Durchsatzsteigerungen um den Faktor drei bis vier gegenüber herkömmlichen Anten­nen erreicht werden, was das grundsätzliche Potential von intelligenten Antennen verdeutlicht. Das hier angewendete Verfahren, das von direktionalem Empfangen ausgeht, weist jedoch ver­mutlich zu viel Komplexität auf. Dies gilt besonders für VANETs, in denen durch die hohe Mobilität solche Komplexität nur noch schwierig unter Kontrolle zu bekommen ist.

Verhindern des Taubheiteffekts

Ein weiterer Vorschlag, der in [KK04] diskutiert wird, nutzt die Möglichkeit, alle Nachbarn in der Umgebung mit direktionalen RTS-Nachrichten über Ubertragungsvorgänge zu informieren. Dies verhindert Kollisionen durch anderweitig fehlendes Wissen von nur direktional erreichbaren Nachbarn. Da eine direktionale Übertragung nur einen Teilbereich des gesamten direktionalen Funkradius abdeckt, müssen m RTS-Nachrichten in m direktionale Sektoren gesendet wer­den, damit der komplette Umkreis des sendenden Knotens abgedeckt ist. Jedoch können die RTS-Nachrichten nicht in jene Sektoren gesendet werden in denen derzeit ein Kommunikations­vorgang abläuft der vorher mittels einer empfangenen RTS- oder CTS-Nachricht angekündigt wurde. Dennoch können durch diesen Ansatz die Taubheit und auch Kollisionseffekte deut­lich, wenn auch nicht vollständig, reduziert werden. Der offensichtliche Nachteil der Technik ist, dass eine wesentliche Erhöhung der Latenzzeit und ein Mehraufwand bei der Übertragung von Kontrollnachrichten entsteht, da nicht mehr nur ein RTS-Paket sondern m Pakete übertra­gen werden müssen. Dieser Vorgang ist in Abbildung 2.14 skizziert, wo Knoten A direktionale RTS-Nachrichten für eine Übertragung an Knoten D versendet. Die Sektoren zwischen Knoten B und C können jedoch wegen einer zwischen diesen Knoten ablaufenden Übertragung nicht abgedeckt werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.14: Übertragung direktionaler RTS-Nachrichten in alle freien direktionalen Sekto­ren

Zeitscheibenverfahren statt CSMA

|KK04| stellt auch den Ansatz ans |BGla02| vor, in dem ein auf Zeitscheiben basierender Zugriff auf das Funkmedium mit Hilfe von intelligenten Antennen umgesetzt wird, Zeitseheibenverfah­ren benötigen üblicherweise eine zentrale Instanz oder Infrastruktur, die den beteiligten Knoten im Netzwerk entsprechende Zeitseheiben zuteilt, wie dies etwa bei GSM der Fall ist. Da im Ad- Hoe-Xetzwerk jedoch keine solche Instanz vorhanden ist, muss eine dezentrale Zuteilung von Knoten zu Zeitseheiben realisiert werden. Ein solches Verfahren mit der Bezeichnung ROMA (Receiver-oriented Multiple Access) wurde in |BGla02| entwickelt, Zeitseheibenverfahren kön­nen Kollisionen besser verhindern als zufallsbasierte Zugriffverfahren wie CSMA.

Für das ROMA-Protokoll wird angenommen, dass eine Antenne zur Verfügung steht, die in mehrere Richtungen gleichzeitig senden aber nur einfach empfangen kann. Dies soll mittels sogenannter MBAA (Multi-Beam Antenna Arrays) möglich werden, welche laut den Autoren durch den technologischen Fortschritt im Bereich der Signalverarbeitung in Zukunft denkbar sind. Die Zeit wird für dieses Protokoll in zusammenhängende Zeitseheiben eingeteilt. Damit die korrekte Zuteilung von Xetzwerkteilnehmern zu Zeitsehreiben möglich ist, müssen alle Teil­nehmer über eine miteinander synchronisierte Uhrzeit verfügen. Von der Existenz einer solchen Synchronisierungsmöglichkeit wird im Rahmen des Protokolls ausgegangen.

Um Informationen über die Topologie im Umkreis zu erhalten, tauschen alle Knoten in­itial Informationen über ihre direkte Nachbarschaft untereinander aus. Diese Informationen werden mittels herkömmlicher omnidirektionaler Kommunikation ausgetauscht. Dadurch hat jeder Knoten Kenntnis über seine 2-Hop-Xaehbarsehaft, Über einen Algorithmus berechnet je­der Knoten Priotitätswerte für sieh und seine Xaehbarknoten, die über alle Knoten hinweg gleich berechnet werden. Für jeden Antennensektor kann so bestimmt werden, wer zu welchem Zeitpunkt senden und empfangen darf.

Das vorgeschlagene Verfahren ist vollständig Kollisionsfrei und erlaubt dadurch hohen Da- tendurehsatz auch in dichten Ad-Hoe-Xetzwerken, Jedoch berücksichtigt es keinerlei Mobilität im Ad-Hoe-Xetzwerk, was den Ansatz für VAXETs ungeeignet macht. Dennoch zeigt sieh, dass jenseits der typischen Zufallszugriffverfahren wie CSMA andere Ansätze vielversprechend sein können. Die zwei größten Problemfelder beim Einsatz von Zeitseheibenverfahren sind hierbei die gemeinsame Zeitsynchronisation sowie die Entwicklung eines geeigneten Algorithmus zur kooperativen Zeitscheibenzuteilung.

Schlussfolgerung

Insgesamt zeigt sieh ein gespaltenes Bild bei der Benutzung von intelligenten Antennen, Die prinzipielle Idee, den Durchsatz zu erhöhen indem die von Kommunikation belegten Flächen des Funkmediums auf die notwendigen Funkstrecken beschränkt werden, ist ein sinnvoller Schritt, Auch die Dynamik von hochmobilen VAXETs lässt sieh so durch erhöhte Funkreichweiten abfedern. Die neuartigen Probleme, die sieh jedoch bezüglich des Medienzugriffs dabei ergeben, erhöhen die Komplexität des Medienzugriffverfahrens weiter. Die tatsächlichen Möglichkeiten hängen weiterhin von den konkreten Fähigkeiten der Funkhardware ab.

Die Nutzung rein direktionaler Datenübertragung scheint trotz der zusätzlichen Problemfälle bezüglich versteckter Knoten oder dem Taubheitseffekt das gröfste Verbesserungspotential zu bieten. In der Realität werden rein direktionale Netzwerke aber unwahrscheinlich sein. Intelli­gente Antennen verursachen Mehrkosten, so dass nicht alle Teilnehmer damit ausgestattet sein werden, Aufśerdem haben unterschiedliche Antennen unterschiedliche Eigenschaften hinsichtlich Reichweite und Steuerbarkeit der Sende- und Empfangsrichtung sowie der Übertragungsstär­ke, Wie sieh mobile Ad-Hoc-Xetze mit intelligenten Antennen tatsächlich verhalten, unterliegt weiterhin realen Tests und komplexen Simulationen, In vielen Arbeiten zum Thema werden idealisierte Simulationsmodelle verwendet, die die Ergebnisse in Bezug auf die Realität ver­zerren, Annahmen wie die Kenntnis der Positionen aller Nachbarn im Netzwerk sind je nach Verfahren ggf, nur schwierig zu realisieren, da zum Austausch dieser Positionsinformationen bereits ein Medienzugriff oder aber ein weiteres Kommunikationsmedium notwendig wird. Was auch bedacht werden muss ist, dass zur vollen Ausschöpfung der Möglichkeiten von intelligen­ten Antennen auch die höheren Xetzwerkschichten die neuen Eigenschaften ausnutzen sollten, was insbesondere für Routingalgorithmen auf der Vermittlungsschicht gilt.

2.4.5 Besonderheiten beim Rundfunk

Bei Rundfunk (engl, Broadcasting) handelt es sieh um Übertragungen, die nicht nur an einen bestimmten sondern an alle Empfänger in Kommunikationsreichweite adressiert sind. Das Ver­senden von Rundfunknachrichten spielt in VAXETs eine besondere Rolle, Routingalgorithmen basieren fast ausschließlich auf Rundfunkübertragungen, Informationsverbreitungsanwendun­gen operieren ebenfalls primär mit Rundfunk, Schließlich arbeiten auch viele sonstige Dienste, wie z, B, Xachbarschaftsprotokolle auch mit Rundfunkpaketen, Rundfunk kommt immer dann zum Einsatz, wenn Informationen gnßfläehig oder sogar im gesamten Ad-Hoc-Xetzwerk ver­breitet werden müssen.

Auch in konventionellen Netzwerken findet viel Rundfunkkommunikation statt. In VAXETs jedoch stellt sie einen noch wichtigeren, essentiellen Teil der Kommunikation dar. Da es kei­ne zentralen Strukturen gibt, müssen die Knoten im Network kooperativ arbeiten, was häufig auf Rundfunkkommunikation hinausläuft, da alle Knoten im Netzwerk anonym sind und im Voraus nicht bekannt ist, welcher Xachbarknoten einen bestimmten Dienst erfüllen kann. In lokalen Netzen wird Rundfunk eher für Sonderzweeke eingesetzt, so zum Beispiel zum ein­maligen Auffinden von Kommunikationspartnern (z, B, zur Diensterkennung), Ein Beispiel ist das DHCP-Protokoll (Dynamie Host Configuration Protoeoi), das zur Initialkonfiguration ei­nes neu zum Netzwerk hinzugetretenen Teilnehmers eingesetzt wird. In VANETs kann unter Umständen die gesamte Kommunikation mittels Rundfunk ablaufen. Auch findet hier Rund­funkkommunikation bereits intensiv auf tieferen Netzwerkschichten, wie der Vermittlungs- oder der Sicherungsschicht, statt.

Rundfunkklassen

In VANETs gibt es verschiedene Rundfunkvarianten, von denen einige in konventionellen Netz­werken nicht eingesetzt werden. Diese resultieren vor allem daraus, dass der Aspekt der räumli­chen Verbreitung von Informationen in VANETs eine wichtige Rolle spielt. In kabelgebundenen Netzwerken ist die räumliche Position oder Entfernung von Kommunikationspartnern ohne be­sonderen Stellenwert, Alle Teilnehmer können sieh dauerhaft gegenseitig erreichen, bewegen sieh nicht und nehmen Dienste und Anwendungen weitgehend unabhängig von der räumlichen Position in Anspruch, Dies ist in VANETs in vielen Fällen anders. Wo Kommunikationspartner sieh befinden, wie Informationen sieh im Netzwerk räumlich bewegen oder verteilen ist hier von grofśer Wichtigkeit.

Funknetze, in denen omnidirektional gesendet wird, haben bereits von sieh aus einen Rund­funkcharakter inne. Ein Paket, das von einem Knoten versendet wird, kann prinzipiell unab­hängig davon, ob es als Rundfunkpaket vorgesehen ist oder nicht, immer von allen Knoten in Funkreichweite gehört werden. Für die verschiedenen Rundfunkarten in VANETs gibt es in der Literatur unterschiedliche Namensgebungen oder sie werden gar nicht explizit voneinander unterschieden. Im Folgenden werden deshalb die Rundfunkarten in VANETs voneinander abge­grenzt, um die weitere Verwendung der Begrifflichkeiten im Rest dieser Arbeit zu ermöglichen.

Der Rundfunk, wie er in IEEE 802.11 definiert ist und der das Gegenstück zum Rundfunk in konventionellen Netzwerken darstellt, wird als lokaler Rundfunk oder einfach Rundfunk be­zeichnet, Ein Paket das in 802.11 als Rundfunkpaket verschickt wird, enthält eine besondere Zieladresse, die alle Nachbarn, die die Übertragung hören können, dazu veranlasst, das Pa­ket zu verarbeiten. Jedoch werden bei IEEE 802.11 Rundfunkpakete nicht mit der maximalen Übertragungsrate sondern nur mit der niedrigeren Datenrate von 1 MBit übertragen. Dies liegt darin begründet, dass sieh für die höheren Übertragunsraten Empfänger und Sender auf die konkreten Parameter für die Übertragung einigen müssen, was bei mehreren, beliebigen Empfängern so nicht möglich ist. Beim lokalen Rundfunk werden alle direkt auf dem Medium erreichbaren Nachbarn mit einem Rundfunkpaket angesproehen. Die auf diesem Weg empfan- genen Rundfunkpakete werden dann im Netzwerkstapel der Empfänger verarbeitet, aber nicht weiterversendet.

Der netzweite Rundfunk ist ein erweitertes Rundfunkverfahren für VANETs, das dafür sorgt, dass das Rundfunkpaket im gesamten Netzwerk verbreitet wird. Dies wird dadurch erreicht, dass jeder Empfänger eines Rundfunkpakets dieses seinerseits nochmals als Rundfunkpaket wei­terverschickt. Auf diese Weise wird das komplette, zusammenhängende Ad-Hoc-Netzwerk mit dem Rundfunkpaket versorgt. Diese Art des Rundfunks wird auch als Fluten des Netzwerks bezeichnet. Der begrenzte Rundfunk funktioniert prinzipiell genauso wie der netzweite Rund­funk, mit dem Unterschied, dass jede Weiterleitung des Pakets im Paketkopf mitgezählt wird. Wird ein bestimmter Grenzwert überschritten, verbreiten die Knoten im Netzwerk das Paket nicht mehr weiter. So lässt sich ein Paket in einem n-Hop-Radius im Netzwerk verbreiten.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.15: Die verschiedenen Rundfunkklassen: normaler Rundfunk, netzweiter Rundfunk und geographischer Rundfunk

Eine letzte Sonderform des Rundfunks in VANETs ist der geographische Rundfunk (engl. Geocasting). Eine Übertragung im geographischen Rundfunk ist nur für ein bestimmtes geo­graphisches Gebiet bestimmt. Möchte man etwa eine Information in einem bestimmten Um­kreis (z. B. 2 Kilometer) verbreiten oder nur auf Autobahnen, nur innerhalb der Stadt oder eines bestimmten Gefahrenraums, kommt der geographische Rundfunk zum Einsatz. Bei geo­graphischem Rundfunk werden wie beim netzweiten Rundfunk die Rundfunkpakete von dem Empfängern weitervermittelt, jedoch nur dann, wenn sieh der Empfänger noch in dem im Pa­ketkopf spezifizierten Zielgebiet befindet (bzw, wenn der Empfänger aufgrund seiner Position in der Xetzwerktopologie das Paket in Richtung Zielgebiet transportieren kann). Geographi­scher Rundfunk ist besonders für Informationsverbreitungsanwendungen interessant, um Daten gezielt im Netzwerk zu verbreiten. In Abbildung 2.15 ist der Verbreitungsweg bei den verschiede­nen Rundfunkklassen skizziert, Teil (a) zeigt den herkömmlichen Rundfunk, (b) den netzweiten Rundfunk und (e) den geographischen Rundfunk.

Insgesamt ist in einem VAXET von mindestens einem bis zwei Drittel Rundfunkanteil am Gesamtdatenverkehr auszugehen, abhängig von den konkreten Anwendungen, Routingalgorith­men und Medienzugriffsalgorithmen, die zum Einsatz kommen, Rundfunkverkehr wird also tendentiell einen höheren Anteil haben als der Verkehr auf Ende-zu-Ende-Verbindungen, Dies unterstreicht die Wichtigkeit einer zuverlässigen Umsetzung der beschriebenen Rundfunkme- ehanismen.

Medienzugriff beim Rundfunk

Das Medienzugriffverfahren von IEEE 802.11, wie in 2.4.1 beschrieben, verwendet Kontrollpa- kete, um Kollisionen zu vermeiden und den Sender eines Pakets darüber in Kenntnis zu setzen, ob das Paket beim Empfänger angekommen ist. Dies ist bei Rundfunkpaketen so nicht mög­lich, Da die Kontrollpakete RTS, CTS und ACK immer an einen einzelnen Teilnehmer gerichtet sind, schlägt dieses Vorgehen im Falle von Rundfunkpaketen fehl.

Ein RTS-Paket könnte vom Sender einer Rundfunknaehrieht noch gesendet werden, um die Xaehbarn in seinem Umkreis über die Übertragung zu informieren. Ein CTS-Paket kann jedoch nicht zuriiekgesehiekt werden, da es mehrere Empfänger gibt. Auch eine ACK-Xaehrieht müsste nach Erhalt der Xaehrieht von mehreren Empfängern zuriiekgesehiekt werden. Da der Sender nicht weifś, wie viele potentielle Empfänger es gibt könnte er auch nicht feststellen, ob und wann alle Xaehbarn das Paket empfangen haben, IEEE 802.11 versendet Rundfunkpakete deshalb mit einfachem CSMA: Der Sender prüft lediglich, ob der Kanal frei ist und sendet sein Rundfunk­paket, Die Kollisionsgefahr steigt dadurch natürlich gegenüber normalen Paketübertragungen, Da der Rundfunkverkehr in VAXETs hoch ist, ist dieser Mangel besonders schwerwiegend, Aufśerdem werden in IEEE 802.11 Rundfunkpakete nur mit niedriger Bitrate übertragen. Das bedeutet, dass mit Rundfunkübertragungen Teilnehmer erreicht werden können, die mit unidi- rektionalen Übertragungen nicht erreicht werden können, weil die Übertragung mit niedrigerer Bitrate stabiler ist. Dies kann logische Probleme bei der Verarbeitung von Protokollen und Applikationen ergeben.

Broadcast Storm und weitere Medienzugriffsprobleme Die beschriebene Problematik ver­stärkt sieh noch weiter bei beschränktem oder netzweitem Rundfunk, Da hierbei die Rundfunk­pakete von den Empfängern weiterverbreitet werden, ist die Gefahr von Kollisionen besonders hoch. Würde man eine naive Umsetzung von netzweitem Rundfunk wählen, dann würden alle Empfänger eines Rundfunkpakets zur nahezu gleichen Zeit versuchen, mittels CSMA das Rund­funkpaket weiter im Netzwerk zu verteilen. Da zunächst für alle der Kanal frei ist, würden viele Empfänger zu gleicher Zeit mit der Übertragung beginnen, Aufśerdem verstärken sieh hierbei die Phänomene versteckter und ausgelieferter Knoten, Folglich ist bei einem solchen Vorgehen eine zuverlässige Übertragung nicht mehr gegeben und Kollisionen treten mit sehr hoher Wahr­scheinlichkeit auf. Dieses, bei netzweitem Rundfunk auftretende Problem, wird auch als engl, Brodcast Storm bezeichnet.

Zur Linderung der Kollisionsgefahr in dieser Situation ist es ein übliches Vorgehen, dass je­der Empfänger eines Rundfunkpakets eine zufällige Zeit lange wartet, bevor er versucht das Rundfunkpaket weiterzuverbreiten. Dadurch wird die Gleichzeitigkeit der Weiterverbreitung reduziert, Kollisionen können jedoch weiterhin auftreten. Durch die Wartezeit steigt weiterhin die Latenz bis die Nachricht im gesamten Netzwerk verbreitet ist, was je nach Anwendung eine negative Auswirkung haben kann. Viele Ansätze versuchen auch die Übertragung unnötiger Rundfunkpakete zu unterbinden. Dies ist besonders in dicht besiedelten Netzwerken häufig der Fall, Die Weiterverbreitung einer Rundfunknaehrieht durch bestimmte Knoten bringt keinen Mehrwert mehr für die Verbreitung der Nachricht im Netzwerk, da diese keine neuen Kno­ten erreichen können, die die Nachricht nicht bereits kennen. Da diese Knoten dennoch am Wettbewerb um das Medium teilnehmen, besteht hier ein Optimierungspotential.

Ein geeignetes Verfahren zur Umsetzung der verschiedenen Rundfunkarten muss sieherstellen, dass Kollisionen weitgehend verhindert werden. Darüber hinaus stellt sieh die Frage wie Rund­funkverkehr bei gleichzeitiger Existenz von Punkt-zu-Punkt-Verkehr behandelt wird, um die Gleiehbehandlung zwischen unterschiedlichen Übertragungsarten zu bewahren. Die Abdeckung des gewünschten Zielbereiehs sollte durch das Rundfunkverfahren ebenso gewährleistet sein. Einige Lösungsansätze dazu werden im Folgenden vorgestellt.

Medienzugriffsprotokoll für zuverlässigen Rundfunk In |TG01| wird die fehlende Absiche­rung von Rundfunkverkehr in Ad-Hoe-Netzwerken ebenfalls erkannt und ein neues Protokoll für den Rundfunk namens BMW (Broadcast Medium Window) vorgesehlagen. Im Rahmen dieses Protokolls verwaltet jeder Knoten im Netzwerk eine Liste aller seiner Nachbarn indem Daten­verkehr zwischen anderen Knoten abgehört wird. Wird ein bestimmter Knoten eine gewisse Zeit lange nicht mehr gehört, wird er aus der Naehbarliste gelöscht.

Um Datenpakete eindeutig zu identifizieren, werden einheitlich laufende Nummern für die- so verwendet. Die Nummern der Pakete sowie die Pakete selbst, die ein Knoten sendet oder empfängt bzw, mithört, werden als Historie in einer entsprechenden Datenstruktur gespeichert. Um nun eine Rundfunkübertragung durchzuführen, wird in einem Rundlaufverfahren genau ein Xaehbarknoten gewählt, dem ein RTS-Kontrollpaket gesendet wird. Dieses Kontrollpaket enthält die Information, welche Paketnummern bereits gesendet wurden und welche die aktu­elle Paketnummer für das neue Datenpaket ist. Der Empfänger prüft anhand der mitgeteilten Paketnummern nach Empfang des RTS-Pakets, ob er bereits alle Pakete empfangen hat, die der Sender empfangen hat. Im CTS-Antwortpaket teilt der Empfänger dem Sender schließlich mit, ob er das neue Datenpaket senden kann oder ob eines der älteren Pakete, die der Sender in der Historie abgelegt hat, noch fehlt und er dieses senden soll. Entsprechend der Informatio­nen im CTS-Kontrollpaket versendet der Sender die fehlenden Pakete an den Empfänger, Der Empfänger sendet bei erfolgreichem Empfang ein ACK-Paket an den Sender zurück, um den erfolgreichen Empfang zu quittieren.

Dieser Prozess wird nun so lange zwischen diesem Sender-/Empfängerpaar wiederholt, bis der Empfänger das neueste Datenpaket erhalten hat und damit auch evtl, verlorengegangene Datenpakete aus der Historie des Senders erhalten hat, Sender und Empfänger haben in diesem Moment den selben Informationsstand bzgl, Rundfunkübertragungen, Der Rundfunkeharakter wird dadurch erfüllt, das alle anderen Nachbarn, die nicht direkt an dieser Kommunikation beteiligt sind, dennoch die Paketnummern- und inhalte mitlausehen und entsprechend ihre eigenen Datenstrukturen auffüllen. Bei der nächsten Rundfunkübertragung wählt der Sender gemäfs dem Rundlaufverfahren einen anderen Xaehbarknoten als Empfänger, Auf diese Weise kann jeder Xaehbarknoten, der ein Paket aufgrund von Übertragungsfehlern oder Kollisionen nicht erhalten hat, nach gewisser Zeit dieses aus der Historie des Senders erhalten.

In Abbildung 2.16 wird der Ablauf der Kommunikation beim BMW-Protokoll aufgezeigt. Zu Beginn möchte Knoten A ein neues Paket mit der Nummer 5 an seine Xaehbarknoten versenden. Im Rahmen des Rundlaufverfahrens hat er Knoten B als direkten Kommunikationspartner für die nächste Rundfunkübertragung gewählt. Er sendet an Knoten B mittels RTS-Übertragung die Information, dass er derzeit die Pakete mit den Nummern 1 bis 4 in der Historie hat und dass er ein neues Paket mit der Nummer 5 Übertragen möchte, Knoten B antwortet mit der Information, dass ihm noch die Pakete 3 und 4 fehlen. Deshalb sendet Knoten A nacheinander die Pakete 3, 4 und 5 an B und B sendet ACK-Pakete zur Bestätigung an A zurück. Während diesem Vorgang hört auch Knoten C das Paket 4 mit, weil ihm dieses Paket auch noch in der Historie gefehlt hat. Das Paket Nummer 5 hören sowohl Knoten C als auch Knoten D mit, weil es sieh hierbei um ein neues Paket handelt. Bei der nächsten Rundfunkübertragung würde Knoten A z, B, Knoten C als Kommunkationspartner wählen. Auf diese Weise werden Pakete. die bestimmte Knoten im Netzwerk nicht erreicht haben, im Laufe der Zeit nochmals versendet.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.16: Rundfunkverbreitung von Paketen beim Broadcast Medium Window Protokoll

Simulationen des Protokolls in [TG01] ergeben, dass die Zustellrate von Rundfunkpaketen gegenüber dem Standardprotokoll erheblich verbessert wird. Jedoch bleiben einige Fragen of­fen. Der Protokollvorschlag beschäftigt sich nur mit Rundfunkverkehr. Wie Punkt-zu-Punkt- Ubertragungen in das Protokoll eingebaut werden können, ist nicht definiert. Weiterhin wird auch nicht beschrieben, wie die einheitliche Vergabe von Sequenznummern für die Datenpa­kete in einem großen Ad-Hoc-Netzwerk realisiert werden kann. Auch stellt sich die Frage des Ressourcenbedarfs für die Verwaltung der notwendigen Datenstrukturen. Vorgeschlagen wurde, mindestens so viele Pakete in der Historie vorzusehen, wie ein Knoten maximal an Nachbarkno­ten haben kann. Dieser Wert ist für ein VANET schwierig zu bestimmen und müsste deshalb mit Reserve nach oben dimensioniert werden. Schließlich wird leider nicht auf den Einfluss von Mobilität auf das Protokoll eingegangen.

Vermeidung von Redundanz Anstatt den Medienzugriff leistungsfähiger und robuster zu gestalten, beschäftigen sich einige Arbeiten auch mit der Herangehensweise, die Redundanz beim Fluten des Netzwerks durch Rundfunk zu verringern. Dies erscheint sinnvoll, da eine hohe Anzahl der Nachrichten bei beschränkten bzw. netzweiten Rundfunkübertragungen unnötig ist, weil sie keinen Mehrwert für die Verbreitung der Information im Netzwerk haben. Dies gilt im besonderen für VANETs. In [IvoschOö] wird auf die Eigenschaft der Straßentopologie in VANETs hingewiesen, dass es genügt, die Nachrichten entlang den Straßen weiterzuleiten. So lässt sich die unnötige Weiterverbreitung einer Rundfunknachricht bei vielen Knoten vermeiden. Solche Rundfunktechniken, die versuchen nur sinnvolle Rundfunkübertragungen durchzuführen werden auch als intelligenter Rundfunk bezeichnet.

Aufsetzend auf existierenden Rundfunkverfahren, die sieh daran orientieren, wie viel neue Flä­che durch eine individuelle Rundfunkübertragung im Netzwerk erreicht wird, schlägt |Koseh05| vor, als Kriterium die Länge der neu erreichten Strafśenabsehnitte zu wählen. Dies ist eine lo­gische Schlussfolgerung aus den Umfeldbedingungen in VAXETs, da Strafśennetze sieh nicht in der Fläche ausbreiten sondern in einer graphenähnlichen Struktur, Besonders geeignet für die Weiterverbreitung von Rundfunknachrichten sind demnach einerseits Nachbar knoten, die möglichst weit entfernt sind, da diese die gröfsten neuen Strafśenabsehnitte ab decken werden, Aufśerdem sind Knoten, die sieh in der Nähe von Kreuzungen befinden, vorteilhaft für die Weiterverbreitung, da diese die Nachricht auch in QuerstrafSen transportieren können.

In einem Wettbewerbsverfahren ähnlich dem BEB-Algorithmus des IEEE 802.11 Standard­protokolls wird dann zwischen mehreren Knoten, die sieh als geeignet für die Weiterverbreitung einer Rundfunknachricht erkennen, entschieden, welcher Knoten tatsächlich den Medienzugriff erhält. Jeder Knoten verzögert seine Weiterverbreitung um eine Zeit, die abhängig vom in­dividuellen Vorteil der Weiterverbreitung durch den jeweiligen Knoten ist. Ist dieser Vorteil grofś, fällt die Wartezeit gering aus und die vorteilhaften Übertragungen bekommen den Vor­zug gegegeniiber den anderen. Nachdem ein Knoten seine Nachricht versendet hat, berechnen die verbleibenden, zuvor miteinander konkurrierenden Knoten den Vorteil durch ihre Weiter­verbreitung der Nachricht erneut und senden in der Folge evtl, ihre Nachricht nicht nochmals aus, wenn der vorherige Knoten bereits genug Strafśenabsehnitte abgedeckt hat.

Da im Strafśennetz oft Zyklen und vielfach miteinander verbundene Wege existieren, wandern die Rundfunkinformationen auf verschiedenen Pfaden, welche sieh an Kreuzungen wieder treffen können. Diese multiplen Verbreitungswege sorgen dafür, dass die Abdeckungsrate bei diesem Rundfunkverfahren dennoch hoch ist. Zur Durchführung eines solchen Verfahrens müssen jedoch die durch Rundfunk erreichten Strafśenabsehnitte akkurat bestimmt werden können. Dies gilt besonders für die Kreuzungsabschnitte, bei denen es darum geht, wie viel der Seitenstrafśe(n) abgedeckt werden kann. Das Ergebnis hängt hier davon ab, wie die physikalischen Eigenschaften der Umgebung (z, B, Bebauung), der Funkhardware etc. sind.

Nutzung von intelligenten Antennen Intelligente Antennen können auch zur Optimierung von Rundfunkübertragungen eingesetzt werden. Viele Arbeiten zu diesem Thema gibt es al­lerdings leider nicht. In |KK04| werden Vorschläge aus |HHH03| diskutiert. Dort werden drei verschiedene Varianten für direktionalen Rundfunk vorgestellt. Ein Ansatz sieht vor, dass alle Knoten im Netzwerk feststellen können, aus welcher Richtung Pakete empfangen wurden. Wird ein Rundfunkpaket empfangen sendet der Knoten nur noch in die Richtungen weiter, aus der das Paket nicht empfangen wurde. Dies ist auch auf den Fall erweiterbar, dass dasselbe Paket ans mehreren Richtungen bereits empfangen wurde. Dies kann bis dahin führen, dass der Emp­fänger das Rnndfnnkpaket gar nicht mehr weiterleitet, weil es bereits durch die Xaehbarn im gesamten Umkreis verbreitet wurde.

Ein weiteres Verfahren das auf dem gerade vorgestellten aufbaut, wählt für jede noch nicht mit der Rundfunknaehrieht versorgten Antennenriehtung einen Weiterleitungsknoten aus der möglichst weit entfernt ist. Dadurch wird das Netzwerk räumlich schneller geflutet und unnüt­ze Weiterleitungen an Knoten die die Information bereits erhalten haben, werden verringert. Allerdings benötigt der Sender auch Informationen über die Positionen aller Xaehbarn, um die besten Weiterleitungsknoten für Rundfunkpakete zu identifizieren.

Eine letzte Vorgehensweise sieht vor, dass das Rundfunkpaket zwar in alle Richtungen ver­sendet wird. Dies geschieht jedoch mit variabler Zeitverzögerung, In Richtungen die den gröfsten Gewinn für die Verbreitung des Rundfunkpakets versprechen, wird zuerst gesendet. Die Rich­tungen, aus denen das Paket ursprünglich empfangen wurde, werden zuletzt versorgt. Dadurch wird durch Priorisierung versucht, den Medienzugriff zu verbessern und gleichzeitig die Aus­breitung der Pakete im Netzwerk zu sichern.

Simulationen der drei vorgesehlagenen Verfahren zeigen, dass das priorisierte Verfahren die beste Abdeckung beim Fluten erreicht, jedoch eine hohe Latenzzeit aufgrund der zeitverzöger­ten Übermittlung aufweist. Das zweite Verfahren mit den Weiterleitungsknoten realisiert die geringste Latenzzeit doch auch die schlechteste Abdeckung, wie zu erwarten war. Beim ersten Verfahren hingegen sind die Kollisionsraten am geringsten. Jedes der Verfahren zeigte bessere Eigenschaften als herkömmlicher, omnidirektionaler Rundfunk, Das erste Verfahren überzeugt jedoch aufgrund seiner Simplizität und Stabilität auch in mobilen Netzen.

Intelligente Antennen versprechen also auch beim Rundfunk Vorteile für VAXETs, Einge­hende Analysen auch in der Praxis müssen jedoch erst zeigen, wie diese Verfahren sieh in der Realität schlagen. Insbesondere die Tatsache, dass die Strafśennetztopologie in VAXETs we­sentliche Unterschiede für die Effektivität solcher Ansätze bedeuten, lässt Fragen bezüglich der Eignung für VAXETs offen. Bezüglich der Reduktion der Redundanz, wie im letzten Abschnitt beschrieben, bieten intelligente Antennen ebenso grofśes Potential gegenüber herkömmlichen Antennen.

Ergebnisse Insgesamt lassen sieh gemäfs |Adler06| folgende Mechanismen für die Realisierung von netzweitem Rundfunk identifizieren: Einfaches Fluten des Netzes sowie deterministische, probabilistische und positionsbasierte Rundfunkprotokolle, Beim einfachen Fluten des Netzes verbreitet jeder Knoten grundsätzlich das Rundfunkpaket weiter. Deterministische Rundfunk­protokolle, wie das oben vorgestellte BMW-Protokoll, stellen weitgehend sicher, dass Rund­funkpakete auch tatsächlich im gesamten Netzwerk verbreitet werden. Probabilistische Rund­funkprotokolle versuchen mit einer gewissen Wahrscheinlichkeit die Verbreitung von Paketen durchzuführen und dadurch einerseits die Redundanz zu verringern aber andererseits die Ab­deckungsrate hoch zu halten. Die positionsbasierten Rundfunkprotokolle entscheiden anhand der eigenen und der Positionen der Xaehbarknoten sowie der Strafśennetztopologie, ob eine Weiterverbreitung der Rundfunknachricht sinnvoll ist.

Für die Informationsverbreitung macht ein positionsbasierter Ansatz wie in |Koseh05| verwen­det am meisten Sinn, weil hierbei nicht blind Nachrichten versendet werden, sondern nur geeig­nete Knoten die Nachricht verbreiten. Gleichzeitig wird durch diesen Ansatz die Abdeckung der Xachrichtenverbreitung hoch genug gehalten, um das gesamte Netzwerk zu erreichen. Je nach dem Grund für Rundfunkübertragungen (z, B, Xaehbarsehaftsprotokoll, Routing, Anwendung) kann es jedoch möglich sein, dass ein positionsbasiertes Verfahren nicht oder nur schwierig möglich ist. Deshalb ist es sinnvoll auch konventionelle bzw, alternative Rundfunkmethoden anzubieten.

2.4.6 Schlussfolgerungen

Bei der Betrachtung der Sicherungsschicht bezüglich Medienzugriff bei Punkt-zu-Punkt- und Rundfunkiibertagungen zeigt sich deutlich, dass der Algorithmus wie er in IEEE 802.11 fest­gelegt ist für VAXETs nur sehr bedingt geeignet ist. Die schlechte Skalierbarkeit der Ad-Hoe- Kommunikation muss durch einen effizienteren Medienzugriffsalgorithmus wesentlich verbessert werden. Auch die mangelnde Gleichberechtigung beim Medienzugriff muss behoben werden, um der kooperativen Natur von VAXETs Rechnung zu tragen. Beim Rundfunk ergibt sich ein noch schlimmeres Bild, weil diese Kommunikationsform in VAXETs intensiv eingesetzt werden wird, aber von IEEE 802.11 gar keine Kollisionsvermeidung mehr beim Rundfunk durchgeführt wird. Dies zeigt deutlich die Ausrichtung von IEEE 802.11 auf Infrastrukturkommunikation mit einer Basisstation und einer eher geringen Zahl von Teilnehmern, die konventionelle TCP/IP- Kommunikation durchführen. Für die erkannten Probleme gibt es einige generische Lösungen, wie zum Beispiel den Einsatz intelligenter Antennen und Lösungen, die spezifisch für bestimmte Anwendungsfälle wie netzweite Rundfunkübertragungen ausgelegt sind. Übergreifend muss zu den vorgestellten Vorschlägen jedoch festgestellt werden, dass nur die wenigsten dieser Ansätze die hohe Mobilität von VAXETs hinreichend berücksichtigt.

Die Gleichberechtigungsprobleme von IEEE 802.11 lassen sich bereits mit relativ einfachen Änderungen am Protokoll abschwächen und wie im Rahmenwerk aus |GlaW04| gezeigt wurde auch umfassend lösen. Für die Erreichung einer höheren Skalierbarkeit bestehen verschiedene Ansätze, die schnell erhöhte Komplexität erzeugen, jedoch oft nur unwesentlich mehr Effizienz einbringen. Eine Kombination vorhandener Lösungsansätze mag sinnvoll sein. Als eine effek­tive Lösung zur Schaffung der notwendigen Skalierbarkeit zeigt sieh der Einsatz von mehr als einem Funkkanal durch dezentrale Zuweisung von Kanälen zu Xetzwerkknoten, Insbesondere für die Klasse der echtzeitkritischen Anwendungen wird ein solcher skalierbarer Medienzugriff mit geringer Kollisionsrate und Latenz ausschlaggebend sein. Leider gestaltet sieh dieser An­satz tendentiell konträr zu den höheren Anforderungen an Bandbreite, wie sie zum Beispiel von Infotainmentanwendungen gewünscht ist. Weiterhin vielversprechend ist die Nutzung von intel­ligenten Antennen, Diese könnten einige der erkannten Probleme lindern und Lösungsansätze verbessern helfen. Dies hängt jedoch stark von den tatsächlichen Fähigkeiten der Funkhardware ab sowie von der Auswahl geeigneter Verfahren, um mit den intelligenten Antennen umzugehen. Diese können schnell sehr komplex werden aufgrund der vielfältigen Möglichkeiten und auch neuen Problemstellungen, die intelligente Antennen mit sieh bringen. Gerade bei der Anwen­dung intelligenter Antennen stellt sieh denn auch die Frage, wie sehr sieh die hohe Mobilität in VAXETs auf deren Einsatzfähigkeit auswirkt.

Die Überlegungen bezüglich der Abänderung des Medienzugriffsprotokolls bringen mit sieh, dass neue Protokolle oftmals nicht mehr kompatibel zum standardisierten IEEE 802.11 Pro­tokoll sein werden. Bliebe das Frequenzband jedoch dasselbe wie bei IEEE 802.11, drohen Konflikte mit konventionellen IEEE 802.11 Netzwerken. Um diese Konflikte zu vermeiden, wird es sinnvoll sein, ein anderes Frequenzband für VAXETs zu finden. Dies könnte auch Störun­gen durch andere fremde Sender reduzieren. Aus Kostengründen müsste aber weiterhin ein ISM-Frequenzband eingesetzt werden, für das keine exklusive Nutzung durch VAXETs möglich ist. Auch ist zu bedenken, dass die Medienzugriffsalgorithmen meist in der Hardware imple­mentiert sind und deshalb angepasste VAXET-Funkhardware hergestellt werden müsste, was den Kostenvorteil durch die große Verbreitung von IEEE 802.11 wieder teilweise neutralisieren könnte.

Da VANETs eine so hohe Dynamik inne haben, erscheint es sinnvoll, dass auch das Medi­enzugriffsprotokoll an diese Dynamik angepasst wird. Verschiedene Szenarien mit besonders hoher oder niedriger Teilnehmerdichte könnten zum Beispiel eine Änderung der Medienzugriff­strategie sinnvoll machen. Weiterhin können im Rahmen der VAXET-Kommunikation immer wieder relativ kleine Pakete auftreten für die es sieh gar nicht lohnt Kollisionsvermeidung mit RTS und CTS-Kontrollpaketen durchzuführen, da die sofortige Übertragung des kleinen Pakets sicherer ist und außerdem die Kontrollnachrichten in Bezug auf das Paket einen hohen rela­tiven Mehraufwand aufweisen. Andererseits könnten auch mehrere kleine Pakete zu größeren zusammengefasst werden, um den aufwändigen Medienzugriff weniger häufig durchführen zu müssen.

Es muss insgesamt davon ausgegangen werden, dass durch Kollisionen, hohe Kommunikati­onsentfernung und die ständige Änderung der physikalischen Eigenschaften der Umgebung im Strafsenverkehr, insbesondere bei hoher Teilnehmerdichte die realisierbare Bandbreite von IEEE 802.11 deutlich unter den üblichen Werten liegen wird. Dies betrifft vor allem Infotainment­anwendungen, Da jedoch auch die Latenz von den Problemen des Medienzugriffs betroffen ist, leiden auch sicherheits- und echtzeitkritische Anwendungen darunter. Für diese ist es unter sol­chen Umständen sinnvoll einen Medienzugriffsmechanismus umzusetzen, der die Priorisierung von verschiedenen Kommunikationstypen erlaubt.

3 Höhere Netzwerkfunktionalität in VANETs

In diesem Kapitel wird eine große Bandbreite von erweiterten Xetzwerktechniken betrachtet. Die besonderen Problemstellungen bei deren Realisierung in VAXETs werden her ansgearbeitet. Dazu wird beispielhaft auf mögliche Methoden, diesen Problemen zu begegnen, eingegangen. Zu den Themen gehören Routing-, Xaehbarsehafts- und Transportprotokolle. Darüber hinaus werden Gebiete wie Dienstgüte, Mehrpunktverbindungen, Adressierung, Gleichberechtigung, Sicherheit und Energiesparen behandelt. Ein eigener Abschnitt stellt Techniken vor, die bei der Realisierung von Informationsverbreitungsanwendungen genutzt werden, welche eine Be­sonderheit von VAXETs darstellen. Abschließend werden letzte Besonderheiten von VAXETs aufgegriffen und ein Überblick über aktive Forschungsprojekte und Standardisierungsbestre­bungen im Bereich der Fahrzeug-zu-Fahrzeug-Kommunikation gegeben.

3.1 Routingprotokolle

Beim Medienzugriff, welcher sieh auf der Sicherungsschicht abspielt, wurde nur unmittelba­re Kommunikation zwischen benachbarten Knoten im Ad-Hoc-Xetzwerk betrachtet. In diesem Abschnitt wird Routing behandelt, welches auf der Vermittlungsschicht (siehe Abbildung 2.5) stattfindet. Dabei geht es darum, Informationen zwischen entfernten Teilnehmern auszutau­schen, die nicht direkt miteinander kommunizieren können. Um dies zu erreichen, werden zwi­schen solchen Teilnehmern Ende-zu-Ende-Verbindungen aufgebaut, die durch einen oder meh­rere Zwischenknoten verlaufen. Da es keine Infrastruktur in VAXETs gibt, muss jeder Knoten im Xetzwerk am Routingprozess teilnehmen , um Ende-zu-Ende-Verbindungen zu ermöglichen. Jeder Knoten kann deshalb in seiner Funktion auch als Router bezeichnet werden. Aufgrund der schwierigen Verhältnisse in VAXETs, wozu insbesondere die Mobilität zählt, gestaltet sieh der Routingprozess hier besonders komplex und anspruchsvoll. Routingkonzepte, die aus kabel­gebundenen Xetzwerken bekannt sind, können daher kaum auf VAXETs angewendet werden.

Routing in VAXETs bietet gegenüber den Medienzugriffsalgorithmen noch mehr Abstrak- tiens- und Variationsmögliehkeiten, da Routingalgorithmen weitgehend unabhängig von der verwendeten Hardware sind und nicht mehr auf die lokale Sieht eines Knoten im Netzwerk be­schränkt sind, sondern beliebige Verbindungen im gesamten Netzwerk behandeln müssen. Dies erklärt die umfangreiche Auswahl an Routingalgorithmen, die im Laufe der Zeit vorgeschlagen wurden. Über 50 verschiedene Protokolle stehen für das Routing in (allgemeinen) MANETs zur Verfügung, Diese gliedern sieh mehrheitlich in eine von vier Klassen, Das sind die proaktiven, re­aktiven, hierarchischen sowie 'positionsbasierten Protokoll typen. Als Mischform existieren noch hybride Protokolle, die sowohl proaktive als auch reaktive Elemente beinhalten, Routingalgo­rithmen für MANETs lassen sieh nach verschiedensten Kriterien kategorisieren. Dies wurde im Rahmen der Betrachtung einer Vielzahl von Routingalgorithmen in |Lang06| getan. In die­ser Arbeit wird die Einteilung in die vier gewählten Protokollklassen beibehalten. Diese vier Typen sowie die hybriden Verfahren werden im Folgenden näher vorgestellt und jeweils an ty­pischen Protokollen dieser Art veranschaulicht, Die besonderen Vor- und Nachteile sowie die grundsätzlichen Problemstellungen von Routing in VANETs werden dabei herausgearbeitet.

3.1.1 Proaktive Routingprotokolle

Da kein Knoten im Netz Initialwissen über die Netzwerktopologie hat und sieh die Topologie aufgrund der Mobilität der Teilnehmer ständig ändert, muss ein Weg gefunden werden, die Informationen über die möglichen Routingpfade im Netzwerk zu verteilen, Proaktive Protokolle stellen die einfachste Art dar, dieses Wissen im Netzwerk zu verbreiten und damit Routing zu ermöglichen. Der proaktive Charakter rührt daher, dass diese Protokolle unabhängig von tatsächlichen Routinganfragen permanent ein aktuelles Gesamtbild über die Netzwerktopologie aufrecht erhalten. Das bedeutet, dass jeder Knoten im Netzwerk jederzeit einen optimalen, aktuellen Pfad zu jedem entfernten Knoten kennt und damit im Falle einer Routinganfrage sofort einen Weg zum Zielknoten zur Verfügung hat und Daten an diesen verschicken kann.

Um dies zu erreichen wird in proaktiven Protokollen oft das gesamte Netzwerk mit Rund­funknachrichten geflutet, um alle Knoten über den Zustand der Topologie auf dem laufenden zu halten. Aus diesen Informationen wird eine vollständige oder partielle Routingtabelle ab­geleitet, Deshalb bezeichnet man proaktive Protokolle auch als tabellengesteuerte Protokolle, Das Vorgehen proaktiver Algorithmen schafft kurze Latenzen und hohe Zuverlässigkeit mit dem Nachteil, dass ein hoher Mehraufwand durch das Aktuellhalten der Routinginformation für alle Knoten im Netzwerk entsteht.

DSDV - Highly Dynamic Destination-Sequenced Distance-Vector Routing

Ursprünglich in |PB94| vorgeschlagen gehört das DSDV-Protokoh zu einem der ersten Verfahren für Routing in reinen Ad-Hoe-Xetzwerken, Der Algorithmus läuft dabei folgendermafśen ab: Je­der Knoten im Netzwerk kennt seine direkten Nachbarn und ersteht daraus eine lokale Routing­tabelle, Diese teilt er seinen Nachbarn durch Rundfunkübertragungen mit. Die Tabelle enthält die Adressen der Xaehbarknoten sowie deren Entfernung in Hops (da es sich zunächst nur um direkte Nachbarn handelt, sind diese alle einen Hop weit entfernt). Weiterhin wird für jede neu versendete Routingtabehe eine laufende Nummer vergeben, die jeweils um eins erhöht wird, da­mit die Nachbarn die Aktualität von Routinginformationen beurteilen können, Ahe Nachbarn, die nun eine solche Routingtabehe empfangen, merken sich alle Einträge zu Zielknoten, die noch nicht bekannt sind sowie Einträge, die einen kleineren Hop-Zähler bieten, als bereits bekannte Routen, Somit wissen alle Xaehbarknoten, welche Knoten sie über den Versender der Routing­tabelle über 2 Hops erreichen können. Die so erhaltenen, verbesserten Routinginformationen werden bei der nächsten Rundfunkübertragung ebenfalls weiterverbreitet. Nach vollständigem Informationsaustausch erhält so jeder Knoten die Information, welche die kürzesten Routen zu allen anderen Zielknoten im Netzwerk sind. Durch Vergleich der laufenden Nummer, die jeder versendeten Routingtabehe zugeordnet ist, können ältere Routinginformationen zuverlässig mit neuen überschrieben werden.

Jeder Knoten verbreitet seine Routinginformationen in regelmäfšigen Zeitintervallen sowie als Reaktion auf Ereignisse, wie z, B, den Verlust einer Verbindung zu einem Nachbarn oder die Verfügbarkeit einer neuen Verbindung, Dies ist wichtig, damit keine ungültigen oder sub­optimalen Routen im Netzwerk verwendet werden. Ungültige Verbindungen werden mit einem Hop-Zähler von unendlich bekannt gegeben, um die anderen Knoten im Netzwerk daran zu hindern, diese Route weiterhin zu nutzen. Dadurch, dass jeder Knoten jede seiner möglichen Verbindungen, als auch die Verbindungsmögliehkeiten seiner Nachbarn in seiner Tabelle ablegt und diese weiterverbreitet, kennt nach vollständiger Ausbreitung und Abgleich dieser Infor­mationen jeder Knoten im Netzwerk seinen optimalen Routingpfad zu jedem anderen Knoten, Möchte nun ein beliebiger Teilnehmer im Netzwerk ein Paket zu einem entfernten Knoten sen­den, dann prüft er seine Routingtabelle und sendet das Paket über den Xaehbarknoten, der Teil der kürzesten Route zum Zielknoten ist.

In Abbildung 3.1 ist eine Beispieltopologie dargesteht. Zu jedem Knoten ist die zugehörige Routingtabehe nach vollständiger Informationsverbreitung durch DSDV abgebildet. Die Ein­träge in den Routingtabehen haben folgendes Format: Zielknoten, Vermittlungsknoten sowie die Anzahl der Hops für diese Route, Am Beispiel von Knoten A findet folgender Ablauf statt: Zunächst kennt Knoten A nur seinen direkten Xaehbarknoten B, Im ersten Schritt von DSDV erhält A von B dessen Routingtabelle mit der Information, dass er über B Routen zu C und G mit Hop-Anzahl 2 aufbauen kann. Gleichzeitig erhält Knoten B von G und C die Informa­tion, dass er Knoten D und E über die Knoten C und G mit Hop-Anzahl 2 erreichen kann. Im zweiten Schritt dringt diese Information von B nach A durch, weshalb A nun weiß, dass er die Knoten D und E mit Hop-Anzahl 3 über Knoten B erreicht. Schließlich erfährt Knoten B auch von der Route zu Knoten F, die sowohl über Knoten C als auch über Knoten G mit der Hop-Anzahl 3 aufgebaut werden kann. Auch diese Information erreicht schließlich Knoten A, der damit eine 4-Hop-Route über Knoten B nach Knoten F kennt. Knoten A selbst kann für das Netzwerk keine sinnvollen Routinginformationen beitragen, da er nur den direkten Pfad zu Knoten B kennt, der für diesen jedoch trivial ist.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.1: Routingtabellen nach vollständiger Informationsausbreitung gemäß DSDV- Algorithmus. Nur sinnvolle Übertragungswege sind dargestellt

DSDV schafft für jeden Knoten vollständige Transparenz über optimale Routen in der Netz­werktopologie. Dies wird erreicht, indem jeder Knoten regelmäßig seinen Nachbarn seine Rou­tinginformationen mitteilt und im Falle einer Änderung der Topologie das gesamte Netzwerk geflutet wird. Um geänderte Informationen unter allen Knoten zu verbreiten und die neuen op­timalen Routen zu berechnen, sind jedoch in großen Netzwerken viele Nachrichtenaustausche notwendig, was eine hohe Latenz bis zur gesamten Aktualisierung im Netzwerk zur Folge hat. Die Probleme des Medienzugriffs beim Rundfunk kommen dabei noch hinzu (vgl. 2.4.5). Die notwendige Anzahl der Übertragungen kann etwas abgeschwächt werden, indem bei Änderungen von Routinginformationen diese nicht sofort weiterverbreitet werden, wenn es wahrscheinlich ist, dass die Information noch instabil ist, aufgrund der folgenden Übertragungen von ande­ren Xaehbarknoten die günstigere Routen ergeben. Bei hoher Mobilität, wie sie in VAXETs gegeben ist, würde jedoch das Aktualisierungsintervall sehr kurz gewählt werden müssen bzw, die ständigen Ereignisse in Form von verlorenen und neuen Direktverbindungen zu Xaehbarn würden den Verkehr durch Routing enorm in die Höhe treiben bis hin zur Unbenutzbarkeit des Xetzwerks aufgrund von Überlastung oder ungültigen Routen, Daraus folgt, dass DSDV nur schlecht mit einer wachsenden Anzahl von Knoten im Xetzwerk skaliert.

Weitere proaktive Ansätze

Es gibt eine Vielzahl proaktiver Protokolle für Routing in MAXETs, von denen viele vom Prin­zip dem DSDV-Algorithmus ähneln. In |MGla96| wird das Wireless Routing Protocol (WRP) vorgestellt, welches nicht die vollständige Xetzwerktopologie unter den Knoten verbreitet, son­dern lediglich für jeden Knoten den minimal aufspannenden Baum des zum Xetzwerk gehören­den Graphen aufbaut. Dadurch werden aussehliefślieh die kürzesten Pfade zu allen Xaehbarn bekannt gemacht und der Datenverkehr zum verteilen unnützer Routinginformationen wird un­terbunden, Das Optimized Link State Routing Protocol (OLSR) |CJ03| versucht ebenfalls, die Anzahl der Übertragungen von Routinginformationen zu reduzieren. Der Vorschlag basiert in diesem Fall darauf, dass nur eine definierte Menge von Xaehbarknoten die verbreiteten Rou­tinginformationen auch weiterverbreitet. Diese Menge wird so berechnet, dass weiterhin das gesamte Xetzwerk mit den aktualisierten Informationen versorgt wird aber möglichst keine unnötigen Übertragungen mehr stattfinden.

Insgesamt eignen sieh proaktive Protokolle wegen mangelnder Skalierbarkeit und Unabhän­gigkeit von der Mobilität aus den beschriebenen Gründen nur für kleine VAXETs oder MAXETs mit geringer Mobilität, In solchen Fällen ist die Einfachheit der Umsetzung sowie die hohe Zu­verlässigkeit und geringe Latenzzeit von proaktiven Ansätzen als positiv herauszuheben. Für VAXETs jedoch, die naturgemäfs sehr grofś und mobil sind, werden proaktive Protokolle keine akzeptable Lösung darstellen.

3.1.2 Hierarchische Routingprotokolle

Einige Protokolle gehen auch den Weg, eine hierarchische Struktur über die Xetzwerktopologie zu legen, um Mehraufwand durch Routingnaehriehten einzusparen sowie die Komplexität des Routingprozesses zu auf mehreren Stufen zu abstrahieren. Diese hierarchischen Protokolle kön­nen als eigene Klasse von Routingprotokollen betrachtet werden. Sie basieren jedoch in Teilen meist auf proaktiven, reaktiven oder hybriden Protokollen.

Ein Beispiel eines proaktiven, hierarehisehen Protokolls ist das Cluster-head Gateway Switch Routing Protokoll (CGSR) |CGSR|. In diesem Protokoll werden Cluster auf der Xetzwerktopo- logie definiert. Jeder dieser Cluster besitzt genau einen Hauptknoten, Alle Knoten in Kommu­nikationsreichweite dieses Hauptknoten bilden einen Cluster und sind zu diesem Hauptknoten zugehörig. Globale Routinginformationen werden nun ausschließlich in einem Verfahren ähn­lich DSDV zwischen den Hauptknoten der Cluster und Schnittstellenknoten zwischen Clustern ausgetauscht. Schnittstellenknoten sind solche Knoten, die Pakete zwischen zwei angrenzenden Clustern weiterleiten können. Jeder Hauptknoten eines Clusters baut darüber hinaus eine lo­kale Routingtabelle auf, die den eigenen Cluster abdeckt. Die globale Routingtabelle wird von jedem Hauptknoten auch lokal, innerhalb des Clusters weiterverbreitet. Aufgrund dieser Re­duktion der an Routing beteiligten Knotenmenge müssen weniger detaillierte Routingtabellen ausgetauscht werden und die Hauptknoten eines Clusters verwalten zentral die Routinginfor­mationen für alle ihre Clustermitglieder, Jedoch muss ein Knoten, der ein Paket übermitteln will, den Cluster kennen in dem der Zielknoten sieh befindet, um Daten übertragen zu können. Deshalb müssen Abbildungstabellen von Knoten auf Cluster im Netzwerk ausgetauscht werden.

Ein Beispiel für CGSR findet sieh in Abbildung 3.2, Dort sind zwei Cluster abgebildet: Der Cluster CI der durch Hauptknoten A und der Cluster C2 der durch den Hauptknoten B gebildet wird. Der Knoten 3 ist ein Schnittstellenknoten, da er zwischen Cluster A und B vermitteln kann. Möchte nun Knoten 1 eine Nachricht an Knoten 5 schicken, stellt Knoten 1 zunächst in der Clusterabbildungstabelle fest, dass sieh Knoten 5 im Cluster CI befindet. Da nur die Routen zu den Hauptknoten der Cluster bekannt sind, muss nun die Nachricht an den Hauptknoten von Cluster CI, also an Knoten A gesendet werden. Dazu wird die kürzeste Route gewählt, die über den Schnittstellenknoten 3 zu Knoten A führt, Knoten A erhält nun die Nachricht von Knoten 1 an Knoten 5, Da Knoten A alle lokalen Routen für seinen Cluster kennt, kann er die Nachricht auf dem kürzesten Weg innerhalb des Clusters an Knoten 5 weiterleiten (in diesem Fall also direkt an Knoten 5), Der Weg von Knoten 5 zurück zu Knoten 1 verläuft entsprechend über Knoten 3 zu Knoten B zum Zielknoten 1.

Probleme, die bei diesem Verfahren auftreten, sind die geeignete Wahl von Hauptknoten für Cluster, so dass häufige Änderungen des Hauptknoten eines Clusters verhindert werden. Ändern sieh die Hauptknoten zu häufig, müssen viele Verwaltungsnachrichten im Netzwerk ausgetauscht werden, um diese Änderung in der Routingtopologie bekannt zu geben. Auch der Aufbau einer Abbildungstabelle von Knoten zu Clustern erzeugt einen gewissen Verwal­tungsaufwand, Aufgrund der nicht mehr vollständigen Transparenz über die Xetzwerktopologie werden durch CGSR auch leicht suboptimale Routen gewählt, wie im Beispiel erkennbar ist.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.2: Hierarchisches Routingprotokoll CGSR

Der Nachteil von hierarchischen Routingansätzen wie in CGSR ist weiterhin, dass die Gleich­artigkeit der Knoten im MANET aufgehoben wird, was in der Regel auch eine Aufhebung der Gleichbehandlung der Knoten mit sich bringt. Ein Hauptknoten in CGSR hat zum Beispiel wesentlich mehr Routingverkehr weiterzuleiten als normale Knoten. Weiterhin bedarf jegliche hierarchische Struktur, die auf der Netzwerktopologie aufgesetzt wird der Pflege und Verwal­tung. Gerade in hochmobilen Netzwerken wie VANETs wird der Vorteil durch die Hierarchie schnell durch überproportionale Anteile von Verwaltungsnachrichten aufgehoben, da sich die hierarchische Struktur ständig der sich ändernden Netzwerktopologie anpassen muss.

Das Internet-Protokoll (IP) nutzt ebenfalls ein hierarchisches, proaktives Verfahren, um Rou­ting im modernen Internet durchzuführen [Tanenbaum03]. Dass diese Verfahren so gut im Internet funktionierten ist wohl der Grund, weshalb zunächst vor allem proaktive und hierar­chische Protokolle für MANETs vorgeschlagen wurden. Dies zeigt gleichzeitig die grundsätz­lich unterschiedlichen Eigenschaften von kabelgebundenen Netzwerken und drahtlosen Ad-Hoc- Netzwerken. Im Internet existiert eine feste Infrastruktur, die sich nicht häufig ändert und damit eine fixe Netzwerktopologie definiert. Das größte Problem ist dabei die Größe des Netzwerks, weshalb eine hierarchische Struktur gewählt wurde, um die Routingtopologie zu abstrahieren und damit den Aufwand für den Austausch von Routingnachrichten zu verringern. All dies trifft für MAXETs nicht mehr zu: Es gibt keine Infrastruktur und die Topologie ändert sieh ständig, weshalb sieh ein grofśes MAXET nicht effizient durch eine Hierarchie abstrahieren lässt.

3.1.3 Reaktive Routingprotokolle

Reaktives Routing versucht nicht wie das proaktive Routing ein permanentes und zeitnahes Ge­samtbild der Xetzwerktopologie für jeden Knoten im Xetzwerk aufrecht zu erhalten. Hingegen zeichnet es sich dadurch aus, dass eine Route im Xetzwerk erst in dem Moment ermittelt wird in dem ein konkreter Verbindungswunseh von einem Quellknoten zu einem Zielknoten geaufśert wird. Dies führt gegenüber proaktiven Protokollen zu einer höheren Latenzzeit zu Beginn der Übertragung, da die Route nicht vorab bekannt ist und erst dynamisch aufgebaut werden muss. Der Vorteil davon ist jedoch, dass nur so viel Verwaltungsverkehr für das Routing entsteht, wie auch tatsächlich aufgrund von bestehenden Verbindungen notwendig ist. Daher versprechen reaktive Routingverfahren eine deutlich höhere Effizienz.

Reaktive Routingprotokolle haben viel Aufmerksamkeit erfahren und es gibt einige beson­ders intensiv analysierte Umsetzungen, Zwei der wohl populärsten Protokolle dieser Art sind Dynamic Source Routing (DSR) und Ad-hoe On-Demand Distance Vector Routing (AODV), Für beide gibt es RFCs (Request For Comments) bei der IETF (Internet Engineering Task Force) |JMH04|, |PR03|, Diese beiden Protokolle werden im Folgenden stellvertretend für die Klasse der reaktiven Routingprotokolle näher betrachtet.

Dynamic Source Routing (DSR)

DSR setzt quellknoten- bzw, senderbasierendes Routing um. Der Sender einer Xaehrieht kennt die vollständige Route zum Ziel zunächst nicht, Routen, die ein Knoten einmal ermittelt hat, speichert dieser in einem lokalen Zwischenspeicher zur potentiellen späteren Wiederverwendung, Da initial überhaupt keine Information über Routen im Xetzwerk existiert, muss ein Knoten bei Verbindungswunsch zu einem entfernten Knoten erst einen Routenermittlungsprozess einleiten, um den Pfad zum Zielknoten zu erfahren. Dazu wird über eine netzweite Rundfunkübertragung das gesamte Netzwerk mit einer Routenanfrage geflutet. Damit die Anfrage zugeordnet werden kann und Anfragen nicht doppelt verarbeitet werden, enthält jede Routenanfrage eine laufende Identifikationsnummer, die vom Quellknoten vergeben wird.

Ein Knoten, der diese Anfrage empfängt aber selbst keine Information über den Pfad zum Zielknoten hat, sendet die Anfrage per Rundfunk weiter, nachdem er seine eigene Adresse in die Anfragenachricht eingetragen hat. Kennt ein Knoten, der die Routenanfrage erhält, bereits eine Route zum gewünschten Ziel (aus seinem Zwischenspeicher) oder ist der Knoten selbst der ge­suchte Zielknoten, sendet dieser eine Routenantwort-Xaehrieht an den anfragenden Quellknoten zurück. Dies geschieht über die in der Anfragenachricht aufgebaute Adressliste der Zwischenk­noten, über die die Anfrage vom Quellknoten bis zum Ziel- oder Zwischenknoten gewandert ist. Die so ermittelte vollständige Route zum Zielknoten wird auch wieder in die Antwortnachricht eingebettet. Auf dem Weg der Antwortnachricht zurück zum Quellknoten wird die ermittelte Route von jedem Zwischenknoten in den Routen-Zwischenspeicher abgelegt, um bei späteren Routenanfragen zusätzliche Information zur Verfügung zu haben. Kommt die Antwortnachricht beim Senderknoten an, dann kennt er die vollständige Route zu seinem gewünschten Ziel.

Beim Routenermittlungsprozess von DSR kann der Fall auftreten, dass mehrere gültige Rou­ten ermittelt werden. In diesem Fall beantwortet der Zielknoten nur die erste eintreffende Rou­tenanfrage und die restlichen Anfragen werden verworfen. Ebenso können mehrere Antwort­pakete beim Quellknoten eintreffen, weil zum Beispiel der Zielknoten aber auch verschiedene Zwischenknoten, die sich eine geeignete Route im Zwischenspeicher gemerkt haben, eine Ant­wort an den Quellknoten zurückschicken. Auch der Quellknoten wertet in diesem Fall nur die erste eintreffende Antwort aus und die restlichen werden ignoriert. Durch dieses Vorgehen wer­den nur die Routen mit der kürzesten Latenzzeit genutzt. Diese werden in der Regel auch die Routen mit der geringsten Hop-Anzahl sein. Hat der Quellknoten schließlich die Route ermit­telt, wird in folgende Nachrichten zum Zielknoten immer die vollständige Route zum Ziel in das Paket eingebettet, damit Zwischenknoten unter allen Umständen den korrekten Pfad zum Ziel kennen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.3: Ablauf der Routenermittlung beim DSR Protokoll

Im Beispiel in Abbildung 3.3 wird der Routenermittlungsprozess von DSR illustriert, Knoten A möchte in der dargestellten Topologie eine Verbindung mit Knoten F aufbauen. Keiner der Xetzwerkknoten hat vorab Informationen über Routingpfade gespeichert, Knoten A sendet eine Routenanforderung RREQ (Route Request) per Rundfunk, welche von den Knoten B und D empfangen wird, B und D tragen jeweils ihre eigenen Adressen in die RREQ-Xaehrieht ein und leiten die Anfrage ebenfalls per Rundfunk weiter. Die Weiterleitung der Anfrage von Knoten B wird von den Knoten C und F erhalten, C leitet die Anfrage weiter doch erreicht keine neuen Knoten durch seine Übertragung, F jedoch stellt fest, dass er der gesuchte Zielknoten ist. Aus der RREQ-Xaehrieht lässt sieh nun die Route konstruieren: Von Knoten A zu Knoten F gelangt man über Knoten B, Deshalb sendet Knoten F eine Routenantwort RREP (Route Reply) über Knoten B an Knoten A zurück und die Route ist aufgebaut. Bei Knoten F kommt des weiteren dieselbe Routenanfrage über die Knoten D und E noch einmal an. Da F jedoch bereits die Anfrage beantwortet hat, verwirft er diese alternative Route.

Hat ein Senderknoten eine so ermittelte Route bereits einige Zeit verwendet, kann es auf­grund von Topologieänderungen passieren, dass sie ungültig wird. In diesem Fall kann ein Paket des Quellknotens, das über die Route übermittelt werden soll, ab einem bestimmten Weiter­leitungsknoten nicht mehr weitergesendet werden. Dieser Weiterleitungsknoten sendet dann eine Routenfehler-Xaehrieht an den Quellknoten zurück, um diesen über die ungültige Route zu informieren. Alle Knoten, die von dieser Fehlernaehrieht auf dem Pfad zurück zur Quelle Kenntnis erlangen, löschen in der Folge ihre zwisehengespeieherten Routendaten, die davon betroffen sind, um künftig keine fehlerhaften Routen mehr aufzubauen. Erhält der Quellknoten Kenntnis von der fehlerhaften Route, muss dieser einen neuen Routenermittlungsprozess ansto- fśen, um die Ende-zu-Ende-Verbindung zum Zielknoten wiederherzustellen und seine Xaehrieht übermitteln zu können.

Der Gedanke, die dynamisch ermittelten Routeninformationen in einen Zwischenspeicher ab­zulegen, kann noch erweitert werden. Dies geschieht über passives Mithören, Knoten, die an einem Routingprozess gar nicht beteiligt sind, können die Routinginformationen, die in DSR- Paketen eingebettet sind, mitlausehen und auch diese Informationen in ihrem lokalen Zwischen­speicher ablegen. Auf diese Weise werden vor allem stark frequentierte Routen im Xetzwerk implizit aktuell gehalten, ohne dass regelmäfsig das gesamte Xetzwerk geflutet werden muss. Jedoch birgt dieses umfassende Zwisehenspeieherungskonzept auch eine Gefahr: Auch ungültige Routen können in einzelnen Phasen des Routingprozesses zwisehengespeiehert werden. Wie un­gültige Routen dauerhaft und zuverlässig aus den Zwischenspeichern der Knoten im Xetzwerk wieder entfernt werden können, ist im DSR-Protokoll nicht definiert.

Jenseits der Behandlung von ungültigen Routen besteht bei DSR auch weiterhin das Pro- blem, dass wie in proaktiven Protokollen das gesamte Netzwerk geflutet wird, um Routen zu ermitteln. Zwar geschieht dies wesentlich seltener, da dieses Vorgehen nur zur initialen Routen­ermittlung dient. Wird die Route zu einem späteren Zeitpunkt unterbrochen, kann eine neue Route durch die Zwischenspeicherung schneller ermittelt werden. Dennoch verbreitet sieh auch in diesem Fall die erneute Routenanfrage im gesamten Netzwerk, Bei einem hohen Kommu­nikationsaufkommen auf Ende-zu-Ende-Verbindungen in einem mobilen Netzwerk wie einem VANET entsteht dadurch aufgrund der Topologieänderungen leicht eine Menge Mehraufwand durch unnötige Rundfunkübertragungen und ungültige Routinginformationen, Dies wird ver­schärft durch den Speichermehraufwand in den DSR-Paketen, Da in jedem DSR-Paket die ge­samte Route zum Ziel eingetragen sein muss, vergröfsert sieh das Paket nicht unerheblich. Bei 48-Bit MAC-Adressen hat eine 10-Hop-Route bereits 480 Bit und damit 60 Byte Mehraufwand, der mit jedem Paket mitverschickt wird. Die Latenz für noch gültige, bereits bekannte Routen befindet sieh auf demselben Niveau wie bei proaktiven Protokollen, Ist die Route noch un­bekannt, besteht im schlimmsten Fall eine Latenzzeit der Gröfsenordnung der eineinhalbfachen Rundlaufzeit (RTT, Round Trip Time): Einmal die Zeit, bis die Routenanfrage beim Zielknoten ankommt (wenn davon ausgegangen wird, dass kein Zwischenknoten eine gültige Route zum Ziel kennt), die Zeit bis die Antwort mit der neuen Route beim Quellknoten ankommt und schließlich die Zeit bis das eigentliche Nutzdatenpaket über die neu ermittelte Route beim Ziel angekommen ist. Noch weiter verschlimmert sieh die Latenz im Fall von ungültigen Routen, weil hier vor der Neuermittlung der Route noch für den noch gültigen Teil der unterbrochenen Route Latenzzeit hinzukommt bis der Quellknoten über den Routingfehler informiert ist und einen neuen Routenermittlungsprozess anstöfst. Um einige dieser Probleme von DSR zu ver­bessern, wurde eine Reihe von Verbesserungsvorschlägen für DSR erarbeitet, welche in |MD04| zusammengefasst sind.

Der DSR-Algorithmus verspricht trotz seiner spezifischen Nachteile eine bessere Skalierbar- keit als die meisten proaktiven Routingalgorithmen und ist damit auch für gröfsere Netzwer­ke geeignet. Während proaktive Protokolle für das gesamte Netzwerk alle möglichen Routen aktuell halten, unabhängig davon welche Routen tatsächlich genutzt werden, wird ein reak­tives Protokoll in VANETs meist bessere Ergebnisse liefern. Ist die Mobilität hoch, werden Routen regelmäfsig ungültig. Im Fall von DSR werden jedoch nur die Routen neu berechnet, die tatsächlich auch benötigt werden, während bei proaktiven Protokollen immer alle Routen die von Topologieänderungen betroffen sind neu berechnet werden. Da in VANETs der Anteil des Routingsverkehrs voraussichtlich nicht allzu hoch sein wird, verspricht DSR hier bessere Eigenschaften, In grofśen, hochmobilen Netzwerken mit viel Routingverkehr gleichen sieh die Eigenschaften von reaktiven Protokollen wie DSR jedoch denen von proaktiven Protokollen an.

Auf der anderen Seite sehwanken die Verbindungsparameter bei DSR aufgrund dessen dyna- miseher Xatur stärker als bei proaktiven Protokollen, Dies trifft insbesondere auf die Latenz von Ende-zu-Ende-Verbindungen zu. Für echtzeitkritische Anwendungen ist die schlechte Voraus- sagbarkeit der Gültigkeit von Routen und die damit verbundene, temporär erhöhte Latenzzeit ein grofśes Problem, Aus konzeptioneller Sieht nutzt DSR die dezentrale, kooperative Struktur und andere Eigenschaften von VAXETs, wie den Rundfunkeharakter gut aus.

Ad-hoc On-Demand Distance Vector Routing

AODV verfolgt im Gegensatz zu DSR nicht das Ziel, dass Knoten die vollständige Route zu anderen Zielknoten kennen. Hingegen wird ein stärker verteder Algorithmus eingesetzt, der in jedem Knoten nur einen Bruchteil der Gesamtinformation erzeugt und verwaltet, AODV erzeugt auch eine Xaehbarsehaftstabelle, um zeitnäher feststellen zu können, welche Knoten sieh in direkter Umgebung befinden und wann bestimmte Knoten aufśer Reichweite sind, Initial existiert genau wie bei DSR keinerlei Information über Routen im Xetzwerk, Wird eine Route angefragt, wird ebenfalls eine netzweite Routinganfrage per Rundfunk versendet. Damit diese Anfragen nicht mehrfach von Xaehbarn verarbeitet werden, werden sie mit laufen­den Xummern versehen. Jeder Knoten, der die Anfrage erhält, merkt sieh Quelle und Ziel der Route sowie von welchem Nae.hbarknote.n die Anfrage weitergeleitet wurde, in seiner lokalen Routingtabelle, Wird das Ziel oder ein Knoten, der eine gültige Route zum Ziel kennt, erreicht, wird eine Antwortnaehrieht zum Quellknoten zuriiekgesendet. Da im Gegensatz zu DSR nicht die gesamte Route in der Anfragenaehrieht eingebettet wird, kennt der Zielknoten nicht die voll­ständige Route zurück zur Quelle, Deshalb sendet der Zielknoten die Antwortnaehrieht an den Knoten zurück von dem er die Anfrage erhalten hat. Da die Vorgängerknoten sieh in ihren Rou­tingtabellen die Xummer der Routinganfrage und woher diese stammte gemerkt haben, kann so jetzt jeder Zwisehenknoten eindeutig entscheiden, an welchen Vorgängerknoten die Antwort­naehrieht gesendet werden muss, damit die Antwort wieder am Quellknoten ankommt. Auf dem Weg zurück zum Quellknoten merkt sieh nun jeder Knoten, von welchem Xaehbarknoten er die Antwortnaehrieht erhalten hat. Dadurch hat jeder Zwisehenknoten die Kenntnis, welcher der vorherige und welcher der nächste Knoten für eine bestimmte Route ist. Kein Knoten — auch nicht der Quell- oder Zielknoten — kennt die gesamte Route, sondern jeder hat nur den für ihn lokal interessanten Teil der Route gespeichert. Durch die Xaehbarsehaftstabelle überwacht jeder Knoten, ob die Verbindung zu Routenmitgliedern für die gespeicherten Routen noch möglich ist. Bewegt sieh der vorherige oder nächste Knoten einer Route, schicken beide Knoten an der Bruchstelle eine Fehlernaehrieht die sieh damit sowohl zur Quelle als auch zum Ziel ausbreitet. Die ungültigen Routeneinträge werden somit gelöscht und der Quellknoten muss einen erneuten

Routenermittlungsprozess einleiten, um mit dem Zielknoten zu kommunizieren.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.4: Ablauf der Routenermittlung beim AODY Protokoll

Ein Beispiel zur Routenermittlung in AODV ist in Abbildung 3.4 gegeben. Knoten A fordert eine Route zu Knoten F an. Knoten B und C erhalten diese Anforderungsnachricht und merken sich, dass für die Route von A nach F der lokale Vorgängerknoten der Knoten A ist. Knoten B sendet die Anfrage weiter, die nun Knoten E erhält. Er merkt sich B als Vorgängerknoten und leitet die Anfrage an Knoten F weiter. Da er der Zielknoten ist, erzeugt er eine Antwortnachricht und merkt sich, dass für diese Route E der Nachfolger knoten ist (für den Rückkanal). Wenn Knoten E diese Antwortnachricht erhält, ergänzt er seine Information und weiß nun, dass für die Route A nach F der Vorgänger knoten B und der Nachfolgerknoten F ist. Selbiges geschieht bei Knoten B. Knoten A erhält schließlich die Antwort und hat nun Kenntnis davon, dass die Route nach Knoten F über Knoten B verläuft. Damit ist der Routenermittlungsprozess abgeschlossen und A kann nun Packete über B nach F versenden. Der zweite Verbreitungsweg von A über C nach D wird von Knoten E ignoriert, da er die Routenanfrage für A nach F bereits beantwortet hat.

Vorteile von AODV gegenüber DSR sind, dass kein von der Routenlänge abhängiger Mehr­aufwand entsteht, weil die Routeninformation nicht im Paket, sondern verteilt über alle an einer Route beteiligten Knoten gespeichert wird. Die aktive Überwachung aller Knoten in einer Rou- to auf Unterbrechungen sorgt dafür, dass Quell- und Zielknoten zeitnah über eine fehlerhafte Route informiert werden und nicht erst dann, wenn ein Paket an die Gegenseite geschickt wer­den soll. Da kein agressives Zwischenspeichern von Routinginformationen durchgeführt wird, reinigt sieh durch die Fehlerbenachrichtigung in AODV die Routeninformation in den betroffe­nen Knoten, Gleiehermafśen wie DSR wendet AODV jedoch netzweite Rundfunkübertragungen an, um initial Routen zu ermitteln. Die Latenzzeit kann durch den Ermittlungsprozess deutlich gesteigert werden, was aber charakteristisch für reaktive Protokolle ist.

AODV ist also gegenüber DSR in einigen Punkten schlanker und effizienter, was sieh auch in den meisten Leistungsvergleichen zwischen den beiden Protokollen zeigt |MD04|, |Lang06|, Dennoch wird AODV für hochmobile, grofśe Netze nicht vollständig geeignet sein und die man­gelnde Eignung von DSR gilt auch für AODV bezüglich zeitkritischer Anwendungen.

3.1.4 Hybride Routingprotokolle

Die Klasse der hybriden Routingprotokolle stellt eine Mischform aus proaktiven und reaktiven Protokollen dar. Die Idee ist dabei, die besonderen Vorteile der beiden Formen miteinander zu kombinieren, um insgesamt ein überlegenes Protokoll zu erhalten. Um dies zu realisieren, werden zum Beispiel Zonen oder Strukturen definiert, zwischen denen ein reaktives Verfah­ren angewandt wird, während innerhalb ein proaktiver Ansatz herrscht. Dadurch sollen der geringere Mehraufwand von reaktiven Verfahren mit der geringeren Latenzzeit und höheren Zuverlässigkeit von proaktiven Verfahren in einem Protokoll vereinigt werden.

Zone Routing Protocol (ZRP)

Das Zone Routing Protocol (ZRP) |Beijar02|, |ZRP-RFC| teilt die Xetzwerktopologie für jeden Knoten im Netzwerk in drei Teile auf: Eine lokale Zone, die Nachbarn im Radius von bis zu n Hops enthält. Die Nachbarn, die genau n Hops entfernt sind, sind Grenzknoten. Der dritte Teil sind die Knoten, die weiter als n Hops entfernt sind. Die Topologie der lokalen Zone wird über ein proaktives Protokoll für alle darin enthaltenen Nachbarn ermittelt. Das heilst, dass jeder Knoten eine vollständige Routingtabelle für alle Knoten in bis zu n Hop Entfernung aufbaut. Muss nun eine Verbindung zu einem externen Knoten aufśerhalb der lokalen Zone aufgebaut werden, wird ein reaktives Protokoll verwendet. Dieses führt eine Art Fluten des Netzwerks durch. Allerdings wird nicht tatsächlich das gesamte Netzwerk geflutet, sondern lediglich die Grenzknoten der eigenen Zone erhalten die Routinganforderung, Diese Grenzknoten leiten die Routinganfrage wiederum an ihre eigenen Grenzknoten weiter. Da jeder Knoten eine Routingtabelle über die n- Hop-Xaehbarsehaft besitzt, kann auf diese Weise eine Route zu jedem Knoten gefunden werden, ohne dass die Routinganfrage tatsächlich an jeden Knoten im Netzwerk weitergeleitet wird. Die Route wird bei diesem Verfahren ähnlich wie beim DSR-Algorithmus in den Paketdaten gemerkt und schließlich in einer Antwortnachricht zurück an den Quellknoten gesendet.

In Graphik 3.5 wird ein Beispiel zu ZRP gegeben. Der Radius n ist hier 2. Die Zeichnung stellt die lokale Zone für Knoten A dar. Knoten A verwaltet proaktiv für alle Knoten innerhalb dieser Zone eine Routingtabelle. Die Knoten in 2 Hop Entfernung sind die Grenzknoten (grün). Möchte A mit einem Knoten außerhalb der lokalen Zone kommunizieren (z. B. mit Knoten C), dann wird eine reaktive Routinganfrage an alle Grenzknoten gesendet. Da der Grenzknoten B seinerseits eine lokale 2-Hop Routingtabelle hat, kennt er den direkten Weg zu Knoten C und antwortet Knoten A mit dem vollständigen Netzwerkpfad zu Knoten C. Alle anderen Grenzknoten, die den Pfad zu Knoten C nicht kennen, senden die Anfrage an ihre eigenen Grenzknoten weiter, bis das ganze Netzwerk (teil-)geflutet ist.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.5: Aufteilung in lokale Zone, Grenzzone und externe Zone bei ZRP

Der Radius n der lokalen Zone ist ein Parameter, der sich dynamisch den Netzwerkbedin­gungen anpassen kann. Je nachdem, wie hoch die Teilnehmerdichte, die Mobilität und das Kommunikationsaufkommen ist, kann ein größerer oder kleinerer Radius gewählt werden. Bei Wahl von n = 0 wird das ZRP zu einem rein reaktiven Protokoll. Für n = oo hingegen entsteht ein rein proaktives Verhalten. Der Parameter könnte gar im gleichen Netzwerk für verschiedene Knoten unterschiedlich gewählt werden, wenn etwa die Netzwerkbedingungen in verschiedenen Bereichen des Netzwerks unterschiedlich sind. Während solche Parameter für die Adaptivität insbesondere in VAXETs vorteilhaft sind, stellt sieh gleiehzeitig aneli die Frage naeh welchen Kriterien die Wahl vorgenommen wird. Die korrekte Wahl und Anpassung dieses Parameters ist entsprechend ausschlaggebend fiir die Leistungsfähigkeit und Zuverlässigkeit des ZRP.

Andere hybride Routingprotokolle nutzen z, B, disjunkte Zonen zur Aufteilung der proakti­ven und reaktiven Verfahren, Einen guten Überblick über weitere Algorithmen dieser Art ver­schafft |Gikaru04|, Das ZRP vermeidet das regelmäfsige Fluten des gesamten Netzwerks durch das proaktive Protokoll, indem es nur innerhalb eines beschränkten Radius proaktiv arbeitet. So wird das Skalierbarkeitsproblem von proaktiven Algorithmen umgangen. Bei entfernten Kno­ten wird ein reaktives Protokoll hinzugezogen, das nur fallweise zum Einsatz kommt. Dabei wird sogar ein vollständiges Fluten des Netzes im Gegensatz zu DSR und AODV vermieden, indem das lokale Wissen der Grenzknoten ausgenutzt wird. Hier kann man sieh interessante Modifikationen vorstellen, die die Effizienz noch weiter erhöhen. Etwa zur Informationsverbrei­tung könnte dieses Verfahren für einen angepassten netzweiten Rundfunk verwendet werden, der nicht unter den in 2.4.5 beschriebenen Nachteilen leidet.

Auch wenn auf den ersten Blick der Eindruck entstehen könnte, dass das ZRP Ähnlichkeiten zu hieraehisehen Protokollen hat, handelt es sieh bei diesem hybriden Ansatz um ein zu den hierarchischen Ansätzen klar abgegrenztes Verfahren, Während in Protokollen wie CGSR glo­bale Strukturen verwaltet werden die allen bekannt sind, hat bei ZRP jeder Knoten nur einen lokalen Blick auf die Zonenstruktur, Weiterhin kommen bei hierarchischen Protokollen nur proaktive bzw, reaktive Algorithmen zum Einsatz, während hier explizit beide Möglichkeiten kombiniert werden.

Im Vergleich zu reinen proaktiven oder reaktiven Protokollen versprechen hybride Ansätze gerade für grofśe und mobile Netze wie VAXETs mehr Skalierbarkeit und Effizienz, Beson­ders geeignet scheint diese Mischung für die Integration von Eehtzeitanwendungen: Für den lokalen Umkreis hat jeder Knoten eine stets aktuelle Routingtabelle, so dass die Latenz und Zuverlässigkeit an dieser Stelle relativ hoch ist. Damit lassen sieh, beschränkt auf das lokale Umfeld, zeitkritische Anwendungen eher durchführen als mit anderen Protokollklassen, Dies ist für zeitkritische Fahrerassistenzanwendungen in der Regel ausreichend, da sieherheitsrelevan- te Ereignisse meist eine lokale Ursache haben, wie zum Beispiel der Vorder- und Hintermann im Strafsenverkehr oder vorbeifahrende Fahrzeuge im Umfeld, Trotz dieser positiven Aspek­te von hybriden Protokollen wie ZRP muss beachtet werden, dass ZRP für ein Netzwerk in freier Fläche betrachtet wurde, wie die meisten anderen Routingprotokolle auch. In VAXETs jedoch treten freie Flächen selten auf. Kreisförmige Zonen wie in ZRP vorgesehen bilden sieh insbesondere im Stadtgebiet aufgrund der Bebauungstruktur eher selten, Stattdessen entste­hen eher kanalförmige Gruppen entlang der St ralseti und Kreuzungen, Was dieser wesentliche Unterschied für einen Einfluss auf die praktische Eignung von ZRP für VAXETs hat, müsste zunächst anhand von geeigneten Simulationen oder im Feldtest evaluiert werden.

3.1.5 Positionsbasierte Routingprotokolle

Positionsbasiertes Routing stellt eine weitere Klasse von Protokollen dar. Sie entscheiden primär anhand der geographischen Positionen der Xetzwerkknoten, wie Routing dnrehgefiihrt wird. Um dies nmznsetzen, ist ein Xaehbarsehaftsprotokoll wie in 3.2 beschrieben notwendig, um die Exi­stenz und Position der direkten Nachbarn in Erfahrung zu bringen. Darüber hinaus wird oft die Existenz eines Ortungsdienstes vorausgesetzt, der einem Knoten den geographischen Aufent­haltsort eines entfernten Knoten mitteilen kann, um mit dieser Information positionsbasiertes Routing durchführen zu können. Dieser Ortungsdienst wird im Rahmen der Routingprotokol­le oft als gegeben angenommen oder in simpler Form, z, B, durch vollständiges Fluten des Netzwerks mit Positionsinformationen durchgeführt.

Distance Routing Effect Algorithm for Mobility (DREAM)

Das DREAM Protokoll ist ein solcher Fall, in dem der Ortungsdienst so gestaltet ist|DREAM|, dass jeder Knoten regelmäfsig das gesamte Netzwerk mit seiner Positionsinformation flutet. Da dieser Vorgang sehr ineffizient ist, versucht man den Mehraufwand dadurch zu reduzieren, dass für entfernte Knoten die Aktualisierungsrate geringer ist als für nahe Knoten, Das heilst. dass häufiger eine begrenzte Rundfunkübertragung durchgeführt wird, die nur einige Hops weit reicht und seltener eine vollständige, netzweite Rundfunkübertragung, Dies wird aus der Erkenntnis gegründet, dass entfernte Knoten sich relativ zu nahen Knoten langsamer bewegen und deshalb die Aktualisierung für entfernte Knoten weniger kritisch ist (daher die Benennung "Distance Routing Effect"), Weiterhin wird die Aktualisierung von der eigenen Bewegungsgeschwindigkeit des Knotens abhängig gemacht — bewegt der Knoten sich langsam, dann sind nicht so viele Aktualisierungen notwendig, da sich die Position nicht so stark verändert.

Das eigentliche Routing wird nun durchgeführt indem eine geographische. Rundfunkübertra­gung in Richtung des gewünschten Knoten vorgenommen wird. Die Übertragung soll eine be­grenzte Fläche um die bekannte Position des Zielknoten herum abdecken, um Ungenauigkeiten der Positionsinformation durch Latenz oder verlorengegangene Aktualisierungspakete des Or­tungsdienstes auszugleichen. Diese gerichtete Rundfunkübertragung ist wesentlich effizienter als ein Fluten des gesamten Netzwerks, Es sind nur Knoten auf dem Weg zum Ziel sowie ei­nige Knoten im Umkreis des Zielknotens davon betroffen. Ist das Ziel sehliefślieh durch diese Rundfunkübertragung gefunden worden, wird die ermittelte Route an den Quellknoten zurück­gesendet und künftige Übertragungen auf der Route werden direkt durch die Routingtabelle und nicht mehr positionsbasiert durehgeführt.

DREAM verhält sieh im Grunde wie ein reaktives Routingprotokoll, Es hält keine Routen vor, sondern führt auf Anfrage eine Routenermittlung durch. Diese Routenermittlung wird dadurch optimiert, dass im Rahmen des Ortungsdienstes in einem proaktiven Verfahren Positionsinfor­mationen der Knoten im Netzwerk verteilt werden. Der Versuch, das Fluten des Netzes durch positionsbasierte Ermittlung von Routen zu lindern, ist sinnvoll. Jedoch leidet jeder Ansatz, den Ortungsdienst durch ein regelmäfsiges netzweites Fluten umzusetzen, unter den selben Skalie­rungsproblemen wie ein proaktiver Routingalgorithmus, Es zeigt sich damit, dass das Problem des Flutens des Netzwerks bei positionsbasierten Routingalgorithmen in den Ortungsdienst ausgelagert wird. Die Eignung von positionsbasierten Protokollen hängt damit primär von der Implementierung dieses Dienstes ab. Für die Gröfse und Mobilität eines VANETs wird DREAM abhängig von der Parameterwahl entweder zu unzuverlässig sein, weil Positionsinformationen zu selten aktualisiert werden, oder das Netzwerk wird durch zu häufiges Fluten überlastet und ineffizient. Aufgrund der hohen Latenz für Verbindungsaufbauten durch die reaktive Natur des Protokolls, ist es auch für Echtzeitanwendungen und Multimediaanwendungen weniger gut ge­eignet, DREAM war eines der ersten Routingprotokolle, das sich auf Positionsinformationen stützt und zeigt prinzipiell auf, wie Routing mit Hilfe von Positionsdaten verbessert werden kann. Andere positionsbasierte Algorithmen sind jedoch vielversprechender.

Greedy Perimeter Stateless Routing (GPSR)

Während DREAM eher die Erweiterung eines reaktiven Protokolls um positionsbasierte Aspek­te darstellt, handelt es sich bei GPSR um ein rein positionsorientiertes Protokoll |GPSR| , Auch GPSR benötigt einen Ortungsdienst, Im Gegensatz zu DREAM wird über dessen Realisierung jedoch keine Angabe gemacht. Es kann also ein beliebiger Ortungsdienst eingesetzt werden und GPSR geht einfach davon aus, dass die Positionen aller Knoten im Netzwerk bekannt sind.

Das Routing wird über einen Greedy-Algorithmus realisiert, Soll ein Paket zu einem entfern­ten Knoten gesendet werden, wird es vom Quellknoten an den Nachbarn weitergeleitet, der die gröfste räumliche Nähe zur Position des Zielknoten hat. Alle Knoten, die das Paket zur Weiter­leitung erhalten, gehen genauso vor. Der Prozess wird fortgeführt bis der Zielknoten erreicht ist. Hier werden wesentliche Unterschiede zu proaktiven und reaktiven Verfahren deutlich: Es werden — abgesehen von einem nicht näher spezifizierten Ortungsdienst — keine Routinginfor­mationen vorab ausgetauscht. Es wird auch keine konkrete Route ermittelt, weder im Ganzen noch in Teilen, Stattdessen wird in jedem Weiterleitungsschritt die aktuelle Topologie berück­sichtigt, indem jene Knoten als Zwischenknoten ausgewählt werden, die den gröfsten räumlichen Fortschritt auf dem Weg zum Zielknoten ermöglichen.

Ein Nachteil, der bei allen Greedy-Algorithmen besteht ist die Gefahr von lokalen Minima und Maxima, Dies äußert sieh bei GPSR insofern, dass das Paket zwar immer weiter in die Richtung des Zielknoten übermittelt wird. Es kann aber leicht passieren, dass eine Sackgasse oder Lücke in der Xetzwerktopologie erreicht wird, in der es keinen Knoten mehr gibt, der einen Fortschritt in Richtung des Zielknoten ermöglicht. In diesem Fall sind Reparaturmechanismen notwendig, um das Paket trotzdem zum Ziel zu transportieren, GSPR wechselt in diesem Fall zum Perimeter Routing, welches versucht, das Routingpaket aus der Problemzone zu bewegen, indem die Topologie im Umkreis der Fehlerstelle auf alternative Routen untersucht wird, die das Paket zum Zielknoten transportieren können. Ist eine Fehlerstelle überwunden, wechselt GPSR wieder zum Greedy Routing, um den Zielknoten zu erreichen. Das Perimeter-Routing ist im Gegensatz zum Greedy Routing kein optimales Verfahren und kann zu unnötig längeren Routen führen. Es gibt deshalb auch modifizierte GPSR-Algorithmen, die andere Reparaturver­fahren einsetzen, die effizienter sein sollen. Das Problem von Lücken in der Xetzwerktopologie bei GPSR ist in Abbildung 3.6 verdeutlicht. Hier soll der Knoten A ein Paket an Knoten F weiterleiten. Der punktierte Kreis hat den Radius der Strecke von A zu F, Der durchgängige Kreis stellt die Kommunikationsreiehweite von Knoten A dar. Ein Knoten, der vom Greedy- Algorithmus von GPSR ausgewählt werden soll, müsste nun in der Sehnittmenge dieser beiden Kreise liegen. Wäre der Knoten außerhalb der Kommunikationsreiehweite von A, könnte das Paket nicht an diesen Knoten weitergeleitet werden. Wäre der Knoten hingegen außerhalb des punktierten Kreises, dann würde der Knoten das Paket nicht näher zu Knoten F transpor­tieren, Da diese Sehnittmenge im Beispiel keine Knoten enthält, liegt eine Lücke vor und der Greedy-Algorithmus versagt.

GPSR hat also zwei Problempunkte: Den Ortungsdienst und den Reperaturmeehanismus für den Fall des Versagens von Greedy Routing, Der Ortungsdienst wird bei GPSR ausgeblendet. Jedoch zeigt der Ansatz von DREAM, dass gerade der Ortungsdienst wesentlichen Mehrauf­wand erzeugt, der nur schwierig unter Kontrolle zu bekommen ist. Der Reperaturmeehanismus kann die Latenz negativ beeinflussen. Die Gesamtidee von GPSR ist jedoch sehr vielverspre­chend, Es werden nicht mehr aufwändig Routen berechnet, die in hoehmobilen Xetzen ohnehin nur eine geringe Lebensdauer haben, Stattdessen wird bei jedem Paket die Route unter Einsatz des lokalen Wissens jedes beteiligten Knoten verteilt berechnet. Dies bedeutet jedoch auch, dass beim Auftreten von Lücken in der Xetzwerktopologie der Greedy-Algorithmus bei jedem Paket, das über die Route gesendet wird, aufs Xeue versagt. Blendet man die konkrete Im­plementierung des Ortungsdienstes bei der Bewertung aus, handelt es sieh bei GPSR um ein Protokoll, das auch in sehr großen Netzwerken noch skaliert und hohe Mobilität abfangen kann. Für Eehtzeitanwendungen dürfte es grundlegend geeignet sein, da hierfür nur die Nachbarn im

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.6: Problem von Lücken bei GPSR (Beispiel übernommen aus [GPSR])

lokalen Umkreis eines Knoten von Bedeutung sind. Ein Versagen des Greedy-Algorithmus sollte in geringen Entfernungen keine große Gefahr darstellen. Da keine Routen ermittelt werden müs­sen, gibt es auch keine initiale Latenz beim Verbindungsaufbau. Für längere Routen stellt sich jedoch in VANETs die Frage, wie effizient Greedy Routing noch ist. Die Straßennetztopologie weist im Vergleich zu einer unstrukturierten bzw. zufälligen Topologie besonders viele Sackgas­sen und Lücken auf, die ein häufiges Versagen des Algorithmus wahrscheinlich machen. Diese Problematik ist in Abbildung 3.7 dargestellt. Sowohl der Knoten A als auch Knoten C würden Knoten B mit Greedy Routing nicht erreichen können, da der direkte Weg zu Knoten B in eine Sackgasse führt (unter der Annahme das die Straßen von Gebäuden umgeben sind, so das keine Funkverbindung jenseits der Straßen möglich ist). Bei Knoten C ist es offensichtlich, dass das Routing über die rechte Verbindungsstraße notwendig wäre. Für den Greedy-Algorithmus jedoch wäre dieser Weg zunächst eine Entfernung vom Zielknoten B und so wird das Paket stattdessen in die Sackgasse bei Knoten A weitergeleitet. Wenn in der Sackgasse der Repe- raturalgorithmus angewendet wird, muss das Paket die gesamte Strecke bis zum Knoten C zuriickwandern, um diesmal die korrekte Route zu nehmen, was eine erhöhte Latenzzeit und vergeudete Ressourcen bedeutet.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.7: Probleme mit Lücken in der Straẞennetztopologie

Die Eignung von positionsbasierten Routingverfahren wie GPSR hängt also sehr stark an der effizienten Umsetzung eines Ortungsdienstes sowie der Optimierung des Greedy-Verfahrens bzw. seiner Reperaturmechanismen ab. Trotz dieser noch bestehenden Probleme haben einige Arbeiten positionsbasiertes Routing bereits als einzig sinnvolle Lösung für VANETs identifiziert [FM01]. Dies ist nachvollziehbar, da positionsorientierte Verfahren als einzige die räumliche Struktur und Mobilität von VANETs berücksichtigen. Erst die Kenntnis und Nutzung der Positionsinformationen der Knoten im Netzwerk schafft überhaupt die Möglichkeit, auf diese spezifischen Eigenschaften einzugehen.

3.1.6 Optimierungsansätze

Wie der Überblick über die verschiedenen Protokollklassen und deren Vertreter zeigt, gibt es verschiedenste Verfahrensweisen, um in Ad-Hoc-Netzwerken Ende-zu-Ende-Verbindungen zu realisieren. Alle bringen spezifische Vor- und Nachteile mit sich, zeichnen sich durch geringe Latenzen, wenig Mehraufwand oder gute Skalierbarkeit bezüglich Netzwerkgröße und Mobilität aus. Trotz der vielen Untersehiede in der Umsetzung gibt es einige allgemeine Optimierungs- mögliehkeiten, die sieh für viele Routingalgorithmen anwenden lassen und zu Verbesserungen führen können. Einige viel versprechende Methoden werden im Folgenden erläutert.

Mehrfachpfade und Routenauswahl

Eine Möglichkeit, die Zuverlässigkeit einer Route zu erhöhen ist es, die Strategie bei der Auswahl von Routen zu optimieren, Ad-Hoe-Xetzwerke haben Eigenschaften von Masehennetzwerken, da es oftmals mehrere mögliche Routingpfade in der Xetzwerktopologie gibt, um von einem Quell­knoten zu einem Zielknoten zu gelangen. Da sieh aufgrund der Mobilität die Topologie ständig ändert und damit die Gefahr hoch ist, dass eine beliebig gewählte Route nach einiger Zeit nicht mehr funktional ist, ergibt es Sinn, die parallel vorhandenen Routingpfade auszunutzen um die Ausfallsieherheit zu erhöhen.

Zunächst einmal stellt sieh die Frage, anhand welchen Merkmals eine Route überhaupt ausge­wählt wird. Einige Protokolle wie DSR und AODV wählen die Route, die die kürzeste Latenzzeit und damit in den meisten Fällen auch die geringste Hop-Anzahl, also den kürzesten Pfad, auf­weist, Hier können auch andere Kriterien gewählt werden. Die verfügbare Energie der beteiligten Knoten auf einer Route spielt etwa in MAXETs und SAXETs eine Rolle, Für VAXETs könnte die Xetzwerkdiehte auf der Route von Bedeutung sein, da dichte Regionen gute Konnektivität aber auch einen schwierigeren Medienzugriff bedeuten. Die Stabilität einer Route kann weiterhin anhand der Signalstärke der einzelnen Verbindungen auf der Route abgesehätzt werden. Sind Positionsinformationen verfügbar, könnten bei der Auswahl der Route auch die Entfernungen zwischen den Knoten der Route berücksichtigt werden. Eine hohe Entfernung zwischen zwei Knoten, die vielleicht schon an der Grenze des Funkradius liegt, könnte darauf hindeuten, dass die Route nicht mehr lange gültig ist, Ximmt man an dieser Stelle noch Gesehwindigkeits- und Riehtungsinformationen der Knoten hinzu, lässt sieh eine Bewegungsabsehätzung durchführen und somit auf die Lebensdauer einer Route Rückschlüsse ziehen.

Mehrfaehpfade, also mehrfach in der Xetzwerktopologie vorhandene Routen von einem Quell- zu einem Zielknoten kann man in disjunkte und nicht, disjunkte Mehrfaehpfade unterscheiden. Disjunkte Mehrfaehpfade sind Pfade, die keine Knoten aufśer den Quell- und den Zielknoten gemeinsam haben, Xieht disjunkte Pfade hingegen teilen einige gemeinsame Knoten auf der Route, Die Idee der Ermittlung sinnvoller Pfade, wie z, B, aussehliefślieh disjunkter Mehrfaeh­pfade, scheint attraktiv. Wird eine Route ungültig, wählt man eine bereits ermittelte, alternative Route, die über andere Knoten verläuft als die ungültig gewordene. Ein Beispiel zu Multipfa­den ist in Abbildung 3.8 gegeben. Dort sind drei alternative Routen zwischen Knoten A und B aufgezeigt. Die rote und die orange Route sind zwei zueinander disjunkte Routen, die beide die kürzeste Pfadlänge bieten und damit optimal sind. Würden von Knoten A beide ermittelt und in der Routingtabelle abgelegt-, könnte er bei Ausfall der primären Route die zweite benutzen, ohne das ein erneuter Routenermittlungsprozess notwendig wäre. Die schwarze und die rote Route hingegen sind zwei nicht disjunkte Routen, wobei die schwarze Route nicht optimal ist. Bei Ausfall des gemeinsamen ersten Knoten auf der Route wären beide Routen gleichermaßen ungültig.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.8: Beispiel für Multipfade

In [GruberO5] werden Lebenszeiten von Routen und Multipfaden im Detail betrachtet und mathematische Analysen durchgeführt. Die Ergebnisse werden weiterhin in Simulationen nach­vollzogen. Das überraschende Ergebnis ist, dass die Nutzung von ausschließlich disjunkten Mehrfachpfaden kein besseres Ergebnis ergibt, als die Nutzung von beliebigen Mehrfachpfa­den, sondern sogar etwas weniger Effizient ist. Dies ist dadurch begründet, dass es nicht so viele disjunkte Mehrfachpfade gibt und außerdem mehr Aufwand betrieben werden muss, um diese zu ermitteln. Weiterhin wird festgestellt, dass die durchschnittliche Lebensdauer einer Route in MANETs (mit zufälligen Netzwerktopologien) allgemein gering ist. Sie sinkt nega­tiv exponentiell mit der Länge der Route. Bei Pfadlängen von mehr als sechs Hops sinkt die Lebensdauer einer Route enorm auf durchschnittlich unter 20 Sekunden. Kürzere Routen hin­gegen bringen es auf mehr wenn auch deutlich unter 100 Sekunden Lebensdauer. Die Nutzung von Mehrfachpfaden kann die durchschnittliche Lebenszeit von Routen um 50 Prozent erhö­hen, Jede weitere redundante Route jedoch bringt weniger positiven Effekt, Schon die zweite Alternativroute bringt nur noch rund 10 Prozent erhöhte Lebenszeit, Mehr als ein oder zwei alternative Routen auf einmal lohnen sieh also nicht, sondern wirken eher wieder negativ auf­grund verlorener Zeit für die Erkennung und Verwaltung von unnützen Routen, Allerdings sorgen Mehrfachpfade auch für erhöhten Mehraufwand einerseits beim Auffinden der Route - es müssen mehr Knoten bei der Routenermittlung einbezogen werden, um alternative Routen zu finden — und andererseits bei Benutzung einer nicht optimalen Route — es werden längere Pfade als nötig verwendet. In hochdynamischen Netzwerken zeigt sieh in der Simulation, dass die Mehrfachpfade nicht viel mehr oder sogar weniger Zuverlässigkeit ergeben. Für VAXETs würde dies bedeuten, dass nicht in allen Situationen Mehrfachpfade sinnvoll sind, wie z, B, auf Autobahnen.

Der tatsächliche Mehrwert von Mehrfachpfaden in MAXETs hängt von vielen Parametern wie der Xetzwerkdiehte, der Funkreichweite und der Mobilität ab. Da in |Gruber05| keine durch das Strafśennetz beeinflusste Xetzwerktopologie berücksichtigt wurde und Mobilität nur im Rahmen von Geschwindigkeiten bis zu 10 Metern in der Sekunde betrachtet wurde, sind die Ergebnis­se auch nicht direkt für VAXETs übertragbar. Dennoch zeigt diese Arbeit, dass es weitere Möglichkeiten gibt, charakteristische Eigenschaften von MAXETs gewinnbringend einzusetzen. Von Bedeutung ist die allgemeine Feststellung, dass zu lange Ende-zu-Ende-Verbindungen in MAXETs schon bei geringer bis mittlerer Mobilität nicht mehr effektiv nutzbar sind. Dies führt zu der Empfehlung, für Routing eine Hop-Beschränkung einzuführen, so dass keine Verbind­ungen über einer bestimmten Hop-Anzahl überhaupt zustande kommen können, Verbindungen mit mehr Hops sorgen dann nämlich nur für unnötigen Mehraufwand durch ausfallende Rou­ten, die wieder aufgebaut werden und die für die Teilnehmer des Netzwerks aufgrund der kaum gegebenen Konnektivität auch keinen Mehrwert haben.

Schließlich können Mehrfachpfade nicht nur zur Erhöhung der Ausfallsicherheit herangezogen werden. Zwei disjunkte Routen könnten verwendet werden, um einen getrennten Hin- und Riiekkanal vom Quell- zum Zielknoten zu erreichen. Dies könnte insofern Sinn machen, dass die Xetzwerklast gleiehmäfsiger oder effizienter verteilt wird und damit der Durchsatz oder die Gleichbehandlung der Knoten im Netzwerk erhöht wird. Ein solches Vorgehen führt jedoch zu einer höheren Gefahr der Unterbrechung der Route, weil doppelt so viele Zwischenknoten an der Route beteiligt sind.

Für VAXETs sind die Kriterien zur Auswahl von Routen auch jenseits der Mehrfachpfade von Interesse, also auch wenn nur eine Route genutzt werden soll. Über Algorithmen zur Berechnung des wahrscheinlichsten Fahrtweges kann jedes Fahrzeug im Netzwerk für sieh ermitteln, wohin es sich derzeit bewegt. Ggf, kann dies auch von einem Navigai ionssvstem (das eine Zielvorgabe vom Fahrer erhalten hat) unterstützt werden. Erhält mm der Quellknoten bei einer Routinganfrage mehrere Routen mit entsprechenden Zusatzinformationen, kann er anhand der Mobilitätsdaten aller beteiligten Knoten abschätzen, welche dieser Routen besonders zu bevorzugen ist. Dies erlaubt die Auswahl eines stabilen Pfades mit akzeptabler Lebensdauer oder die rechtzeitige Neuberechnung der Route bevor ein Routingfehler auftritt.

Reparaturmechanismen

Ein weiteres Instrument zur Erhöhung von Leistungsfähigkeit und Zuverlässigkeit von Rou­tingprotokollen ist der Einsatz von Reparaturmechanismen für Routen, Die meisten Protokolle verwerfen beim Fehler einer Route diese einfach und beginnen einen erneuten Routenermitt­lungsprozess, Dies hat oft eine hohe Latenzzeit und hohen Mehraufwand zur Folge, Bei DSR etwa wird zunächst ein Datenpaket über die Route gesendet von der geglaubt wird, dass sie noch funktional ist. Irgendwo auf dem Datenpfad erkennt sehliefślieh ein Vermittlungsknoten, dass der nächste Knoten in der Route nicht mehr erreichbar ist. Daher schickt er eine Fehlernaeh- rieht an den Quellknoten zurück. Dieser erzeugt in der Folge eine neue Routenanfrage und flutet dadurch das Netzwerk, Erst wenn nun eine Antwortnachricht vom Quellknoten zurückkommt, kann dieser erneut ein Datenpaket versenden.

Ein effizienteres Verhalten könnte zum Beispiel über einen lokalen Reparaturmechanismus erreicht werden. An der Stelle, an der eine Route unterbrochen ist, kann der letzte gültige Kno­ten selbstständig versuchen, die Route zu reparieren, indem er umliegende Knoten über den Aufenthaltsort des nächsten Vermittlungsknoten auf der Route oder des Zielknoten befragt. Nachdem die Route kurz zuvor noch existiert hat, ist es wahrscheinlich, dass ein geeigneter Weiterleitungsknoten weiterhin in der Nähe ist. Wird ein neuer Weg zum Zielknoten gefunden, kann das Paket vom Quellknoten dennoch zum Zielknoten zugestellt werden. Der Zielknoten kann dann die reparierte Route an den Quellknoten zurückmelden, damit die fehlerhafte Route nicht mehr weiter verwendet wird. Auch durch einen solchen Reparaturmechanismus entsteht erhöhte Latenzzeit, Doch wird so das Paket dennoch vom Quellknoten zum Zielknoten zuge­stellt und der Quellknoten erhält eine neue Route, ohne überhaupt eine neue Anfrage erzeugt haben zu müssen. Die Unterbrechung der Route ist somit zu einem gewissen Grad transparent für die Endpunkte auf der Verbindung, In Abbildung 3.9 ist ein Beispiel für diese Form der Routenreperatur gegeben, Knoten A hatte bisher eine gültige Route zu Knoten D, Knoten C, der Teil dieser Route war, hat sich jedoch aufśerhalb der Reichweite seines Vorgängerknotens B auf der Route bewegt. Sendet Knoten A nun ein Paket über die Route findet Knoten B seinen Xaehfolgerknoten nicht mehr und müsste eine Fehlerbenaehriehtung an Knoten A zurücksen- den. Würde Knoten B jedoch eine lokale Routenreparatur durchführen, könnte er feststellen, dass er nun über Knoten E den ehemaligen Nachfolger knoten C erreichen kann. Ist diese Kor­rektur vorgenommen, ist die Route von A nach D wieder gültig. Das Paket von A kann an D zugestellt werden und die modifizierte Route kann auf dem Rückweg von D nach A allen beteiligten Knoten mitgeteilt werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.9: Beispiel für die transparente, lokale Reparatur von Routen

Es besteht jedoch der begründete Einwand, dass eine auf diesem Weg reparierte Route im Vergleich zu einer vollständig neu aufgebauten Route eine geringere Stabilität hat, weil nur ein Teil der Route neu ermittelt wurde und der alte Teil eine wachsende Gefahr der Unterbrechung durch Mobilität aufweist. Außerdem könnte es sich inzwischen um eine suboptimale Route handeln, die mehr Hops als notwendig aufweist, wie dies auch in Abbildung 3.9 der Fall ist. Deshalb könnte man auch einen anderen Weg einschlagen. Zunächst würde man wie beschrieben an der Bruchstelle der Route versuchen, das Paket durch Reparaturmechanismen dennoch zum Zielknoten zu befördern. Der Zielknoten führt nun von sich aus eine Routenanfrage zurück zum Quellknoten aus. So wird die Route auf dem Rückweg zum Quellknoten neu ermittelt. Der Vorteil eines so gearteten Vorgehens wäre, dass das Paket zum Zielknoten zugestellt wurde und eine neue, frische Route zum Quellknoten kommt, ohne das der Datenpfad dauerhaft unterbrochen wurde. Die Latenzzeit und Mehraufwand könnten so verringert werden.

Neben Reperaturmaßnahmen ist auch die Bereinigung von Routingtabellen von hoher Bedeu­tung, um unnötigen Mehraufwand zu vermeiden. Hier sind Verfahren wie bei AODV sinnvoll, die bei Erkennung einer fehlerhaften Route explizit Fehlernachrichten entlang der Route ver­breiten, damit alle beteiligten Knoten die ungültige Informationen entfernen können und das Versenden von weiteren Daten so schnell wie möglich unterbunden wird.

Bei bestimmen Anwendungen kann es von Bedeutung sein, Daten überhaupt zuzustellen, unabhängig von der Verzögerung bei der Zustellung der Informationen. Da es in einem VANET häufiger Situationen geben kann, in denen ein Zielknoten gar nicht mehr erreicht werden kann. weil zum Beispiel eine Partitionierung des Netzwerks stattgefunden hat, könnte man an dieser Stelle Routenanfragen für längere Zeit Zwischenspeichern. Dies könnten insbesondere diejeni­gen Knoten tun, die sieh in der Nähe der Bruchstelle der Route oder des letzten bekannten Aufenthaltorts des Zielknoten befinden. Wird der gesuchte Knoten nach einiger Zeit wieder gefunden, kann eine solche zurückgehaltene Routinganfrage wieder aktiviert werden und dem Quellknoten eine aktuelle Route auch nach längerer Zeit noch mitgeteilt werden.

Eine analytische oder simulative Betrachtung der Effekte verschiedener Reparaturmechanis­men etwa als Erweiterung von DSR oder AODV, ist nicht bekannt. Es lässt sieh aber abschätzen, dass auch diese Form der Protokolloptimierung von Vorteil für Latenzzeit, Mehraufwand und Lebensdauer von Routen sein wird.

Mehraufwand der durch Routingprotokolle entsteht, ist einer der Hauptgründe für schlechte Skalierbarkeit, hohe Latenzen und verringerte Bandbreite in MAXETs, Dies gilt vor allem für sehr mobile Netze, in denen sieh die Topologie ständig ändert. Allgemeine Techniken, um den Mehraufwand zu verringern, können hier helfen. Die Tatsache, dass Protokolle die hohen Mehraufwand verursachen schlechtere Leistungsdaten haben als andere, wurde in |Gikaru04| zum Anlafś genommen, Konzepte zur Erweiterung von existierenden Routingalgorithmen für MAXETs zu entwickeln, die den Mehraufwand reduzieren.

Ein Vorschlag dieser Arbeit sieht vor, dass Positions- und Bewegungsinformationen von Quell- und Zielknoten einer Route regelmäfsig an die Gegenseite übermittelt werden. Vermittlungskno­ten auf der Route merken sieh diese Informationen mit einem Zeitstempel. Ist eine Route nun ungültig geworden, oder wurde sie schon länger nicht mehr benutzt, dann besitzen alle Knoten auf der ungültigen Route Informationen darüber, wo sieh der gesuchte Knoten zuletzt aufge­halten hat und welche Bewegungsmuster er aufwies. Dadurch kann ein Reperaturmechanismus umgesetzt werden, der versucht, den aktuellen Aufenthaltsort des Zielknotens zu identifizieren und dadurch die Route schnell wieder operabel zu bekommen. Diese Idee kann vom Umfang her noch erweitert werden, indem Knoten grundsätzlich Positions- und Bewegungsdaten von Nachbarn bis zu einer gewissen Verfallszeit protokollieren. Dies kann oftmals den netzweiten Rundfunk verhindern, der notwendig ist, um neue Routen zu ermitteln. Der Rundfunk wird so kanalisiert, indem nur zu den Knoten weitergeleitet wird, die Informationen über den Verbleib des Zielknotens haben. Durch gute Bewegungsabschätzungsalgorithmen wird dieser begrenzte Rundfunk gezielter und der Mehraufwand durch nutzlose Rundfunkübertragungen geringer.

Die Idee, Positionen und Bewegungsinformationen von Xachbarknoten zwischenzuspeichern, um Routenermittlungsvorgänge zu beschleunigen und zu verschlanken, ist für die Klasse der reaktiven Protokolle eine vielversprechende Optimierung. Besonders für VAXETs scheint dieses Schema geeignet, da hier die notwendigen Sensoren bereits vorliegen und Bewegungen durch die

Strafśentopologie besonders gut vorhersagbar sind, Simulationen mit einem um diese Optimie­rung erweiterten AODV-Protokoll in |Gikaru04| zeigen besonders bei hoher Knotendichte im Netzwerk Reduktion von Mehraufwand von bis zu einem Viertel, Dies erklärt sieh dadurch, dass bei hoher Knotendichte die zwischengespeicherten Positionsinformationen besonders zahlreich im Netzwerk vorhanden sind.

3.1.7 Schlussfolgerungen

Die Betrachtung der verschiedenen Routingprotokollklassen zeigt, dass reine proaktive oder re­aktive Algorithmen eher ungeeignet für VANETs sind, Proaktive Ansätze skalieren sehr schlecht mit der Grofśe des VANETs, Reaktive zeigen zwar eine höhere Skalierbarkeit, dafür jedoch auch eine höhere Latenz, Der Verwaltungsaufwand nimmt bei reaktiven Protokollen mit der Mobilität und der Zahl der Verbindungen im Netzwerk wieder stark zu. Hierarchische Proto­kolle haben wohl die schlechtesten Eigenschaften für VANETs, da die zusätzliche Verwaltung von Routingstrukturen bei der gegebenen Mobilität im VANET kaum mehr durchführbar er­scheint, Hybride Protokolle die proaktive und reaktive Elemente zusammenführen, kommen dem Nutzungsprofil von VANETs eher entgegen. Mit Nachbarknoten in räumlicher Nähe wer­den Anwendungen häufiger Ende-zu-Ende-Verbindungen aufbauen als mit weiter entfernten Knoten, da nähere Knoten meist von höherem Interesse sind als weit entfernte Knoten, So wird die kurze Latenzzeit von proaktiven Protokollen für die nahe gelegenen Nachbarn umgesetzt während die Skalierbar keit bei Verbindungen über längere Strecken durch reaktive Umsetzung gewährleistet wird.

Das gröfste Potential weisen jedoch positionsbasierte Algorithmen auf. Besonders die Einfach­heit des Prinzips sowie die Eignung für grofśe Netze und hohe Mobilität spricht für einen solchen Ansatz, Die etwa bei GPSR festgestellten Probleme fallen für VANETs weniger schwerwiegend aus als für allgemeine MANETs, Der Ortungsdienst etwa ist in Fahrzeugnetzen nicht so kritisch zu sehen. Lediglich die Positionen der umliegenden Nachbarn, die im Rahmen eines Nachbar­schaftsprotokolls für Fahrerassistenzanwendungen ohnehin benötigt werden, sind wichtig. Die Position eines Zielknotens wird nur sehr selten explizit ermittelt werden müssen. Bei VANETs handelt es sieh um grofśe, anonyme Netzwerke, Die Benutzer setzen das Netzwerk kaum interak­tiv ein, wie dies in konventionellen Netzwerken der Fall ist. Das heilst sie suchen keine speziellen Kommunikationspartner im Netzwerk, Hingegen wird über Diensterkennungstechniken festge­stellt, welche anderen Teilnehmer im Netzwerk für Anwendungen interessant sein können. In diesem Fall werden die Positionen von Zielknoten implizit über ein Diensterkennungsprotokoll ermittelt. Auch das Problem von Sackgassen beim Greedy-Algorithmus von GPSR kann in VANETs effizienter gelöst werden. Da das Netzwerk einer vorgegebenen Strafśennetztopologie unterliegt, gibt es Sinn, den Algorithmus mit digitalen Kartendaten zu unterstützen. Ist die Straßentopologie und die Positionen von Quell- und Zielknoten bekannt, können Saekgassen schon im Voraus vermieden werden indem zum Beispiel zunächst über Hauptstraßen weiterge­leitet wird, auf denen in der Regel viele Xetzwerkteilnehmer sind und kaum Lücken auftreten. Lücken durch Häuser- und Bebauungsstruktur können so ebenfalls a priori umgangen werden, Routing wird dann ähnlich wie von einem Xavigationssystem vom Standort des Quellknoten zum Standort des Zielknoten über das Straßennetz vorgenommen, Xur bei geringer Knoten­dichte und in entlegenen Straßenabschnitten droht noch eine erhöhte Gefahr dafür, dass der so modifizierte Greedy-Algorithmus versagt.

Insgesamt zeigt sieh, dass Routingverfahren, die stark auf das dezentrale, lokale Wissen der einzelnen Knoten zurückgreifen für VAXETs am besten geeignet sind. Die Berücksichtigung der Positionen der Knoten, deren Bewegungsverhalten und der Straßennetzstruktur sind da­bei Möglichkeiten, die sieh ständig ändernde Topologie und Mobilität der Teilnehmer unter Kontrolle zu bringen. Viele Aspekte der vorgestellten Verfahren und Techniken deuten auch darauf hin, dass ein gutes Routingprotokoll sieh stark an die Verhältnisse im Xetzwerk adap­tieren muss. Dies gilt vor allem für die Knotendichte und die Mobilität der Knoten, die sieh im VAXET deutlich zwischen verschiedenen Situationen unterscheiden können. Als Anhalts­punkte dazu können Sensoren wie die Positionierung, digitales Kartenmaterial oder die Uhrzeit herangezogen werden. Auf Autobahnen ist die Mobilität und Knotendichte beispielsweise sehr verschieden zu der Situation im Stadtverkehr, Xachts ist die Verkehrsdichte typischerweise we­sentlich geringer als tagsüber. Durch ein Xachbarschaftsprotokoll kann festgestellt werden, wie viele Xaehbarn derzeit im Umfeld bekannt sind und wie hoch die lokale Knotendichte derzeit ist. All dies sind Hinweise, die für die der Wahl der optimalen Strategie beim Routing hilfreich sein können.

Über die spezifischen Probleme und Lösungen der Routingprotokollklassen hinaus wurden in diesem Kapitel allgemeiner anwendbare Optimierungsmethoden für Routingverfahren vor­gestellt, Die Xutzung der oft gegebenen Mehrfachpfade zur Erhöhung der Ausfallsicherheit, intelligente Routenauswahl sowie Reperaturmechanismen für unterbrochene Routen bieten vor allem für proaktive und reaktive Ansätze viel Verbesserungspotential, Für positionsbasiertes Routing spielen diese Möglichkeiten keine Rolle, wenn wie bei GPSR keinerlei Routentabel­len und statische Routenermittlung verwendet werden. Die Reduktion von Mehraufwand durch Routingprotokolle ist ein weiterer generischer Gedanke zur Verbesserung der Skalierbarkeit und des Verhaltens von Ende-zu-Ende-Verbindungen in VAXETs, indem für den Mehraufwand be­sonders verantwortliche Mechanismen erkannt und durch effizientere Lösungen ersetzt oder um diese ergänzt werden.

Wichtig ist aber auch die Erkenntnis, dass Ende-zu-Ende-Verbindungen in einem hochmo­bilen und grofśen Ad-Hoe-Xetzwerk wie einem VAXET nur über eine relativ geringe Anzahl von Hops realistisch ist. Mit steigender Anzahl von Hops steigt die Gefahr des Verbindungsab­bruchs durch Topologieänderungen stark an. Gleichzeitig sinkt der Durchsatz der Route deutlich |Schwingenschlögl04|, Hier ist es sinnvoll, die maximale Länge von Routen grundsätzlich ab­hängig von den gegebenen Betriebsbedingungen zu beschränken, um unnötigen Mehraufwand im Xetzwerk vorab zu vermeiden |Gruber05|, Die geringe Lebensdauer einer Route, abhängig von deren Länge und Xetzwerkparametern wie der Mobilität aller Knoten auf einer Verbin­dung, sollte direkte Konsequenzen für die Entwicklung von auf Ende-zu-Ende-Verbindungen aufbauenden Applikationen haben. Diese können hier nicht von einem so hohen Grad der Zu­verlässigkeit ausgehen wie dies in kabelgebundenen Xetzwerken wie LAXs oder dem Internet der Fall ist.

Ein Teilgebiet der Vermittlungssehieht das in diesem Abschnitt nicht betrachtet wurde, ist die Überlastkontrolle, Dabei geht es um die Problemstellung, dass durch die sich ständig verändern­den Verbindungspfade im Xetzwerk und dem sich dadurch ändernden Datenverkehrsaufkommen an beliebigen Stellen in der Xetzwerktopologie, Überlastung auftreten kann. Dies bedeutet, dass ein oder mehrere Knoten die an sie gestellten Anfrangen zur Übermittlung von Daten nicht mehr erfüllen können. In der Folge tritt meist ein umfassender Einbruch der Leistung im Xetzwerk ein, bis sich der Stau wieder aufgelöst hat, Methoden zur Vermeidung und Auflösung von Stausituationen durch Überlastkontrolle spielen bereits in konventionellen Xetzwerken wie dem Internet eine wesentliche Rolle und stellen eine Herausforderung dar |Tanenbaum03|, In VAXETs kommt noch die dezentrale Struktur und sich ständig ändernde Topologie erschwerend hinzu, Arbeiten zum Thema Überlastkontrolle in VAXETs bzw, MAXETs gibt es nur wenige. Eine Behandlung des Themas findet sich z, B, in |WR05|, Diese Arbeit sieht eine Priorisierung der Datenpakete vor, indem ein Mals für deren Xutzen für das gesamte Xetzwerk eingeführt wird. Übermittelt werden in Stausituationen dann nur die Pakete, die einen hohen Xutzen für das Xetzwerk aufweisen.

Betrachtet man VAXETs aussehliefślieh als Grundlage für Fahrerassistenzapplikationen, wie z, B, zur Informationsverbreitung, ist überhaupt kein Routing notwendig, da keine Ende-zu- Ende-Verbindungen benötigt werden. Solche Ansätze verfolgen einige Arbeiten wie |Koseh05| und |Adler06|, Die Unterstützung für Ende-zu-Ende-Verbindungen sollte jedoch schon in einem gewissen Umfang für VAXETs in Betracht gezogen werden, da sie vor allem Infotainment­Applikationen, Internetanbindung sowie evtl, einige spezielle Fahrerassistenzanwendungen er­möglichen werden, die einen hohen subjektiven Mehrwert für den Käufer einer solchen Technolo­gie haben. Gerade in den ersten Jahren einer möglichen Einführung von VAXET-Unterstiitzung in Serienfahrzeugen wird eine geringe Teilnehmerdichte herrschen, die Informationsverbrei­tungsanwendungen nur begrenzt erlauben wird, Infotainmentanwendungen, die in begrenzten Szenarien auch Ende-zu-Ende-Verbindungen nutzen, könnten hier den notwendigen Mehrwert für den Kunden darstellen, der ein Fahrzeug mit VAXET-Unterstiitzung erwirbt.

3.2 Nachbarschaftsprotokolle

Viele Routingalgorithmen setzen voraus, dass jeder Knoten im VAXET die Positionen seiner di­rekten Xaehbarn kennt. Auch einige Medienzugriffsverfahren und viele VAXET-Applikationen benötigen zeitnah die geographische Position des eigenen Fahrzeugs und der Fahrzeuge in der direkten oder näheren Umgebung, Jeder Knoten im Xetzwerk bedarf deshalb eines Überblicks über seine Xaehbarn, die ebenfalls am Xetzwerk teilnehmen. Im Rahmen des Medienzugriffs können Positionen der Xaehbarn benötigt werden, um die direktionale Kommunikation mit Xaehbarknoten bei Verwendung von intelligenten Antennen zu ermöglichen (siehe 2.4.4), Rou­tingalgorithmen brauchen diese Informationen, damit sie geeignete Weiterleitungsknoten für eine Route identifizieren können, Anwendungen vor allem aus dem Bereich der Fahrerassistenz setzen die Kenntnis der Xaehbarpositionen voraus, um kritische Situationen zu erkennen oder Informationen korrekt zu verbreiten. Auch müssen neu auftretende Teilnehmer, zum Beispiel ein Fahrzeug, das gerade in Betrieb genommen wurde, schnell als neue Mitglieder erkannt und eingebunden werden, Gleiehermafśen müssen Xaehbarknoten, die aufśerhalb der Kommunikati- onsreiehweite sind oder abgesehalten werden, erkannt werden, um die Xetzwerklogik an diese neue Situation anzupassen.

Um nun regelmäfsig Informationen über Existenz und Position der Xaehbarn zu erhalten, wird üblicherweise ein Xaehbarsehaftsprotokoll implementiert. Dieses operiert so, dass in re- gelmäfsigen Intervallen, zum Beispiel jede Sekunde, jeder Knoten eine Rundfunknaehrieht mit seiner Positionsinformation und, abhängig von den Anforderungen der Xetzwerksehiehten und Applikationen, einige Zusatzinformationen versendet. Alle Xaehbarn, die diese Xaehrieht hö­ren, merken sieh die enthaltene Information und bauen daraus eine Xaehbarsehaftstabelle mit einem Eintrag für jeden direkten Xaehbarn auf (siehe Abbildung 3.10), Dieser Mechanismus kann noch erweitert werden: Indem jeder Knoten die Einträge aus seiner Xaehbarsehaftstabelle als Rundfunknaehrieht verschickt, erhält jeder Teilnehmer im Xetzwerk die Positionsinforma­tionen seiner 2-Hop-Xaehbarsehaft, Dieses Vorgehen könnte auf noch gröfsere Hop-Radien er­weitert werden. Dies wird aber üblicherweise nicht gemacht, da der Kommunikationsaufwand dabei stark ansteigt. Die Xaehriehten, die auf diese Weise ausgetauseht werden, werden als Beacons (Funkfeuer, Signalfeuer) oder HALLO-Xaehriehten bezeichnet, was einerseits auf den sich wiederholenden, signalisierenden Aspekt und andererseits auf den Begrüßungscharakter der Nachrichten hinweist.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.10: Beispiel für den Austausch von HALLO-Nachrichten durch ein Nachbar­schaftsprotokoll

Leider verursachen Nachbarschaftsprotokolle einen nicht unerheblichen Ubertragungsauf­wand im Netzwerk [FWMH03]. Das Verkehrsaufkommen durch die Beacon-Pakete ist dabei konstant bei gleichbleibendem Sendeintervall. Die Datenmenge, die durch die Beacons im Netz­werk entsteht, ist noch hinnehmbar. Die Beacon-Pakete sind klein und bewegen sich im einfach­sten Fall in der Größenordnung von 20 Bytes. Jedoch entsteht durch die regelmäßigen Über­tragungen auch die Notwendigkeit, regelmäßig Zugriff auf das Medium zu erhalten. Besonders schwerwiegend ist dies aufgrund der fehlenden Kollisionsvermeidung bei Rundunkfunkübertra- gungen beim IEEE 802.11 Medienzugriffsprotokoll, wie in 2.4.5 ausgeführt wurde. Die Regel­mäßigkeit und dadurch drohende Gleichzeitigkeit der Übertragung von HALLO-Nachrichten mehrerer Knoten erhöht die Gefahr von Kollisionen. Würde hingegen ein Rundfunkverfahren mit Kontrollpaketen eingesetzt, wäre der Mehraufwand um einige Faktoren höher, da die Kon- trollpakete in Summe sogar größer sein könnten als die Beacons selbst. Dadurch würde auch die Dauer des Medienzugriffs erhöht, was die Gefahr für nicht abgefangene Kollisionen wieder erhöht und auch eine höhere Latenzzeit mit sich bringt. Bei kleineren Paketen ist die Chan­ce, dass das Beacon-Paket kollisionsfrei übertragen werden kann durch die geringe Größe des Pakets höher als bei großen Datenpaketen. Dennoch droht insbesondere in Situationen mit ei­ner hohen Teilnehmerdichte im Netzwerk die Gefahr, dass eine große Anzahl von Kollisionen durch die Beacons auftritt. Neben der dadurch sinkenden Leistung im Netzwerk schadet die mangelnde Information über die Nachbarschaft durch verlorengegangene Beacon-Pakete den Netzwerkprotokollen und Anwendungen durch ungenaue Informationen.

Sich deutlich unterscheidende Verfahren zur generischen Bereitstellung von Nachbarschafts- informationell sind nur wenige bekannt. Einzelne Arbeiten beschäftigen sieh mit der Beseitigung der Notwendigkeit des Austausehs von Xachbarschaftsinformationen fiir spezielle Routingalgo­rithmen (zum Beispiel für GPSR: |FWMH03|). Ein Optimierungsansatz von Xachbarschaftspro- tokollen für beliebige Routingalgorithmen wird in |Gikaru04| aufgezeigt. Die Idee ist, hier neben Verbindungs- und Positionsinformationen auch Mobilitätsinformationen zu übermitteln. Dazu gehören Daten wie Geschwindigkeit und Bewegungsrichtung. Auf Basis dieser Informationen führt nun jeder Knoten eine Bewegungsvorhersage für sieh und alle seine direkten Xaehbarn durch. Dies ermöglicht eine Vorhersage über die Verfügbarkeit von Verbindungen mit Xachbar- knoten. Die Beobachtung, dass im Rahmen von Routingprotokollen vor allem deshalb periodisch Beacon-Pakete übermittelt werden müssen, damit Unterbrechungen in Routen schnell erkannt werden können, führt zu der Idee, dass mit Hilfe der Vorhersage von drohenden Verbindungsab- briichen durch Mobilitätsinformationen, Beacons weniger häufig gesendet werden müssen. Ein Knoten sendet nur ein Beacon, wenn er feststellt, dass eine seiner direkten Xachbarverbindun- gen abzubrechen droht. Dadurch ist das Xachbarschaftsprotokoll nicht mehr intervallbasiert sondern ereignisbasiert und folglich wird Mehraufwand reduziert. Weiterhin wird das Proto­koll stärker an die Bedingungen im Netzwerk angepasst, da bei hoher Mobilität mehr dieser Ereignisse auftreten und damit mehr Beacon-Pakete übertragen werden als bei geringer Mo­bilität, Bekommen Xaehbarn Pakete vom Xachbarschaftsprotokoll, wissen sie jetzt, dass eine Änderung der lokalen Topologie wahrscheinlich ist und können über ihre eigenen Vorhersageal­gorithmen feststellen, wie die Topologie sieh verändert. Die Routingalgorithmen können dann entsprechend informiert werden.

Dieser Vorschlag zur Optimierung des Xachbarschaftsprotokolls ist isoliert für Routingpro­tokolle betrachtet ein sehr guter Ansatz, Jedoch wird man in VAXETs, wie bereits festgestellt wurde, die Notwendigkeit, periodisch die Positionsinformationen und sonstigen Sensordaten zu übermitteln kaum umgehen können, weil von diesen Informationen viele Applikationen abhän­gen. Während es für einen Routingalgorithmus ausreichend ist dann eine Aktualisierung von Positionsdaten über seine Xaehbarn zu erhalten, wenn sieh die Xetzwerktopologie zu ändern droht ist dies für Fahrerassistenzapplikationen nicht hinnehmbar. Eine Frage, die bei diesem Ansatz aufśerdem offen bleibt ist, wie auf das Ereignis eines neu in den Kommunikationsradius tretenden Xachbarknoten ohne Austausch von Xachbarschaftspaketen zeitnah reagiert werden kann. Obwohl zu vermuten ist, dass bei hoher Mobilität durch die stetigen Topologieänderungen der diskutierte Vorschlag nicht mehr so hohe Einsparungen gegenüber einem herkömmlichen Xachbarschaftsprotokooll aufweist, ergeben Simulationen in |Gikaru04| mit einem um dieses Xachbarfschaftsprotokoll erweiterten AODV Routingprotokolls eine Einsparung von rund 90 Prozent der Xachbarschaftspakete. Diese Einsparung soll sogar weitgehend unabhängig von der Geschwindigkeit oder der Knotendichte im Netzwerk sein.

Solche spezialisierten Xaehbarsehaftsprotokolle zeigen immerhin auf, wie der Mehraufwand durch Beacons prinzipiell reduziert werden könnte. Um die negativen Effekte durch Beacons abzumildern, sollte das Xaehbarsehaftsprotokoll sieh an die jeweiligen Bedingungen im VAXET adaptieren. Vor allem bei hohen Geschwindigkeiten ist ein kürzeres Übertragungsintervall sinn­voll, da sieh die Position des Fahrzeugs schnell ändert. Die Geschwindigkeit von Xetzwerkknoten kann in VAXETs auf Autobahnen bei 50 Metern in der Sekunde liegen, weshalb hier eine Ak­tualisierungsrate von einer Sekunde nicht mehr als ausreichend einzustufen ist, um zeitkritische Fahrerassistenzapplikationen zu realisieren. Ein Intervall im Bereich von wenigen hundert Mil­lisekunden und weniger ist hier realistischer. Hohe Geschwindigkeiten setzen aber einerseits voraus, dass das Fahrzeug sieh nicht im Stadtgebiet befindet und andererseits, dass keine hohe Verkehrsdichte herrscht, weil sonst die hohe Geschwindigkeit kaum zu realisieren wäre. Von daher ist das verkürzte Meldeintervall des Xaehbarsehaftsprotokolls nicht allzu kritisch für den lokalen Medienzugriff im Netzwerk. Im Stadtverkehr hingegen, wo die Spitzengeschwindigkeiten eher gering sind und Fahrzeuge oft anhalten müssen, ändert sieh die Position nicht so schnell und das Intervall kann auf eine Sekunde oder auch höher gesetzt werden, wenn das Fahrzeug sieh zum Beispiel gar nicht bewegt, weil es an einer Ampel wartet. Dies federt insbesondere Situationen mit besonders hohen Verkehrsdichten im Stadtgebiet ab.

Weiterhin sollte das Xaehbarsehaftsprotokoll auch logische Aspekte berücksichtigen. Wird ein Beacon von einem Knoten ausgesendet hat dies für die Nachbarn, die es erstmalig empfangen, eine wesentliche Bedeutung, Es hat zur Folge, dass der Senderknoten von seinen Nachbarn als möglicher Kommunikationspartner für den Aufbau von Ende-zu-Ende-Verbindungen oder von Applikationen berücksichtigt wird. Wird ein Beacon nun in einer ungünstigen Verkehrssituation ausgesendet, kann es einen negativen Einfluss auf die Xetzwerklogik haben. Ein Beispiel ist der Fall in dem ein Knoten sein Beaeon-Paket aussendet während er gerade eine Kreuzung mit hoher Geschwindigkeit passiert. Ein solcher Fall ist in Abbildung 3.11 dargestellt, Knoten A passiert mit hoher Geschwindigkeit die Kreuzung und überträgt ein Beaeon-Paket in diesem Moment, In diesem Fall empfangen auch die an der Kreuzung still stehenden Knoten die Beaeon-Xaehrieht, für die der Senderknoten jedoch keine Relevanz hat, da er aufgrund seiner Geschwindigkeit und Bewegungsriehtung nicht als (dauerhafter) Kommunikationspartner in Frage kommen wird. Versuchen diese Xaehbarknoten dennoch, den Senderknoten z, B, für Routing einzusetzen, muss erst aufwändig festgestellt werden, dass der Xaehbarknoten gar nicht mehr erreichbar ist und dieser wieder aus der Xaehbarsehaftstabelle gelöscht werden. Daher sollte das Aussenden von Beaeon-Xaehriehten auch an die konkreten Verkehrssituationen und Xetzwerktopolgien angepasst werden oder durch Hinzufügen von Mobilitätsinformationen wie Geschwindigkeit und Bewegungsrichtung zum Beacon-Paket sowie den Einsatz von digitalen Kartendaten bestimmte Beacon-Informationen gar nicht erst in die Nachbarschaftstabelle aufgenommen werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.11: Beispiel für negative Effekte einer Beacon-Übertragung in einer Kreuzungssi­tuation

Da das größte Problem von Beacon-Paketen nicht deren Größe sondern der notwendige Me­dienzugriff und die dadurch gegebene Kollisionsgefahr ist, können Beacon-Informationen auch implizit in andere Rundfunkübertragungen eingebettet werden, die ohnehin stattfinden. Die­se Zusammenfassung kleinerer Rundfunkpakete zu größeren Gesamtübertragungen kann den Medienzugriff effizienter gestalten. Allerdings kann dadurch eine erhöhte Latenz auftreten, was die Aktualität der Beacon-Information nicht beeinträchtigen und die Zustellung von anderen Rundfunkübertragungen nicht verzögern sollte. Eine Priorisierung verschiedener Datenklassen wäre deshalb sinnvoll, um solche Optimierungstechniken nur bei Paketen anzuwenden, die eine gewisse Verzögerung erlauben können, was zum Beispiel bei Echtzeitapplikationen nicht der Fall ist.

Zusammenfassend lässt sich sagen, dass Nachbarschaftsprotokolle mit periodischen Beacon- Ubertragungen voraussichtlich unumgänglich für ein voll funktionales VANET sind, gleichzeitig aber ein nicht unerhebliches Daten- bzw, Medienzugriffsaufkommen produzieren, das so gut wie möglich optimiert werden muss, um die Funktionalität des Netzwerks in allen Situationen aufrecht zu erhalten.

3.3 Dienstgüte

Bei der Dienstgüte in Netzwerken geht es darum, bestimmte Garantien für Verbindungsparame­ter einhalten zu können, um besondere Klassen von Anwendungen zu ermöglichen. Die wichtig­sten Verbindungsparameter, die hierbei betrachtet werden, sind der Datendurchsatz, die Latenz­zeit, die Paketverlustrate sowie die Schwankung der Latenzzeit (engl. Jitter) |Tanenbaum03|, Applikationen, die solche Garantien benötigen, sind insbesondere Multimedia- und Echtzeitan­wendungen. Bei Multimediaanwendungen, die Video- und Audiodaten verarbeiten, sind mög­lichst stabile Verbindungsparameter wünschenswert, um geeignete Puffergrößen und damit un­terbrechungsfreie Wiedergabe zu ermöglichen. Für Echtzeitanwendungen sind einerseits Ga­rantien für Latenzzeiten von großer Bedeutung, um innerhalb einer definierten Zeit reagieren zu können. Andererseits können auch Paketverluste negative Auswirkungen für Echtzeitanwen­dungen haben. Anwendungen, die auch in VAXETs Anforderungen an die Dienstgüte haben, sind denkbar, so z. B. echtzeitkritische Fahrerassistenzanwendungen oder Infotainmentanwen­dungen wie Sprach- oder Videoverbindungen zwischen Fahrzeugen. Besteht eine Integration des VAXETs mit dem Internet, könnten auch Multimediainhalte über Teile des VAXETs übermit­telt werden, so dass hier ebenfalls eine gewisse Dienstgüte geboten werden muss.

Dienstgüte zu ermöglichen ist in TCP/IP-basierten, konventionellen Netzwerken bereits eine herausforderne Aufgabe. Zur Sicherstellung der Dienstgüte ist es etwa wünschenswert, die not­wendigen Ressourcen für eine Verbindung auf dem Xetzwerkpfad im Voraus zu reservieren. Da das IP-Protokoll jedoch nicht verbindungsorientiert ist, ist eine Reservierung von Ressourcen für Verbindungen mit Anforderungen an die Dienstgüte nicht einfach umzusetzen. Für kon­ventionelle Netzwerke gibt es deshalb eine Reihe von Methoden, um bestimmte Aspekte der Dienstgüte zu verbessern. Wie es bereits in anderen Gebieten der Fall ist, gilt jedoch auch hier für VAXETs eine noch deutlich schwierigere Ausgangslage sowie die mangelnde Anwendbarkeit etablierter Techniken zur Herstellung der Dienstgüte. Aufgrund der bekannten Eigenschaften von VAXETs, wie Dezentralität und schwierigen Kommunikationsverhältnissen, deren Entwick­lung kaum vorhersagbar ist, müssen die Anforderungen an Dienstgüte in VAXETs reduziert werden.

Während in konventionellen Netzen die Dienstgüte vor allem auf der Vermittlungsschicht betrachtet wird, muss in VAXETs bereits auf der Sicherungsschicht Dienstgüte berücksichtigt werden, da der Medienzugriff wesentlichen Einfluss auf die Dienstgüte hat. Auf der Vermitt­lungsschicht müssen besondere Vorkehrungen getroffen werden, um über alle Zwischenknoten auf einer Verbindung Dienstgüte zu erlauben und die häufigen Verbindungsabbriiche durch To­pologieänderungen abzufedern. Aufgrund der ungünstigen Ausgangsbedingungen beschränken sieh die meisten Arbeiten zu Dienstgüte in VAXETs auf sogenannte weiche Garantien. Das heißt es werden nur Intervalle für Verbindungsparameter definiert, die einer Applikation garantiert werden und nicht harte, also feste Werte, Die Parameter können dann innerhalb des gegebenen Intervalls schwanken, sollten dieses aber nicht verlassen. Dies hat zur Folge, dass diese Form von Dienstgüte für sicherheitskritische Anwendungen nur bedingt in Frage kommt, weil hier im Gegensatz zu Multimediaanwendungen keine flexible Abstufung der Qualität stattfinden kann.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3.1: Verschiedene Geschwindigkeitsstufen des IEEE 802.11 Standards

In |Sinha04| wird die Notwendigkeit der Berücksichtigung von Dienstgüte sogar bereits auf der physikalischen Xetzwerksehieht gesehen. Ein Aspekt von IEEE 802.11, der Dienstgüte be­trifft, ist demnach die Wahl der Übertragungsrate durch die Funkhardware, abhängig von den Bedingungen auf dem Funkkanal, Die Übertragungsgeschwindigkeiten, die gemäfs IEEE 802.11 und seiner Erweiterungen gewählt werden können, sind in Tabelle 3.1 aufgelistet. Der Stan­dard legt jedoch nicht fest, wie die Datenrate konkret gewählt werden soll, |Sinha04| betrachtet deshalb verschiedene Methoden, die Übertragunsrate auszuwählen, welche jedoch lediglich eine Maximierung der Datenrate zu erreichen versuchen. Für Dienstgüte müsste hingegen ein Ver­fahren umgesetzt werden, das häufige Schwankungen vermeidet und dennoch eine möglichst hohe Datenrate erreicht.

Auf der Sieherungssehieht gibt es bereits die IEEE-Erweiterung 802.11c für WLAX, die Dienstgüte in Form von unterschiedlichen Prioritäten für Datenverkehr umsetzt. Diese Prioritä­ten werden realisiert, indem der Wettbewerb um den Medienzugriff für die höheren Prioritäten erleichtert wird, Aufśerdem wird versucht, die Ungleiehbehandlung beim herkömmlichen IEEE 802.11 Medienzugriff abzulindern (vgl, 2.4.1), was damit erreicht werden soll, dass jeder Knoten ein von der Übertragungspriorität abhängiges Zeitintervall zugeteilt bekommt, in dem er exklu­sives Zugriff auf das Medium erhält. Sollte auch Verwaltungs- und Kontrollverkehr im VAXET priorisiert übertragen werden, ist hier jedoch Vorsicht angebracht. Wird etwa eine Route mit priorisierten Paketen berechnet, droht die Gefahr, dass die ermittelte Route nur für priorisierte Daten optimal ist und nicht für normalen Datenverkehr, Der Routingalgorithmus würde also durch die Priorisierung ein falsches Bild des Netzwerks als Grundlage für die Berechnung von Routen annehmen.

Dienstgüte auf der Vermittlungssehieht muss auf Basis der Einzelverbindungen auf einer Route durehgefiihrt werden. Die Qualitätsmerkmale jeder Einzelverbindung auf der Route be­stimmten die Qualität des gesamten Pfades, Als Beispiel zu der Problemstellung soll Abbildung 3.12 dienen. Ein Routingalgorithmus soll hier eine Route von Knoten A zu Knoten G ermitteln.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.12: Beispiel zur Berücksichtigung von Dienstgüte auf der Vermittlungsschicht

die eine möglichst geringe Latenzzeit aufweist. Die kürzeste Route ist die, die über Knoten C und E verläuft. Diese weist eine gesamte Latenzzeit von 330 ms auf. Die längere Route über B, D und F hingegen bietet die kürzere Latenzzeit von 195 ms, obwohl sie länger ist. Um die Dienstgüte bezüglich der Latenzzeit zu optimieren, müsste der Routingalgorithmus also letztere Route wählen. Dies zeigt, dass die Erfüllung von Dienstgüte auch durchaus Mehraufwand zur Folge haben kann, da in diesem Fall eine eigentlich unnötige, zusätzliche Übertragung auf der gewählten Route durchgeführt wird. Aufgrund der Mobilität im VANET ändern sich natürlich ständig die Eigenschaften jeder Einzelverbindung auf einer Route. Will der Routingalgorithmus dauerhaft eine bestimmte Dienstgüte gewährleisten, muss er also die Veränderung der Parame­ter beobachten und ggf. auch proaktiv alternative Routen daraufhin untersuchen, ob sie bessere Parameter für die Dienstgüte erreichen können. Ein Vorgehen, dass in der Topologie aus Abbil­dung 3.12 auch umgesetzt werden könnte, ist die Nutzung beider vorhandener Routen parallel, um die Fehlerrate zu reduzieren.

Dienstgüte umzusetzen bedeutet auch, dass die Netzwerkschichten miteinander über diese verhandeln müssen. Voraussetzung dazu ist zunächst, dass alle Schichten ein Verständnis von Dienstgüte haben. Die Notwendigkeit von Dienstgüte entsteht auf der Applikationsschicht. Eine Applikation die bestimmte Anforderungen an eine Verbindung hat, muss diese an der niedri- goren Schicht, der Transportschicht anfordern. Die Anfrage wandert ggf, bis zur physikalischen Schicht, um festzustellen, ob die Anforderung erfüllt werden kann. Kann sie nicht erfüllt wer­den, kann ein alternatives Angebot an die Applikation gemacht werden. Die Applikation kann dann entscheiden, ob die gebotene Dienstgüte für die Anwendung ausreicht und wie sie auf geringere Garantien reagiert.

Dienstgüte in einem VAXET ist schwierig zu erreichen, weil das Netzwerk von Xatur aus sehr fehleranfällig ist. Aufgrund der Ergebnisse in Kapitel 2.4 und 3.1 kann man davon ausgehen, dass hohe Anforderungen an die Dienstgüte nur in einigen Situationen erfüllt werden können, wie zum Beispiel wenn die Mobilität im Netzwerk gering ist, oder wenn nur sehr kurze Datenpfade vorliegen (Direktverbindungen oder Routen über sehr wenige Hops), Zu bedenken ist auch, dass die besondere Behandlung von Kommunikation im Rahmen der Dienstgüte konträr zu den in 3.7 formulierten Zielen der Gleiehbehandlung sein kann. Andererseits kann die Priorisierung von Verkehr unter Umständen auch niedrigere Schichten wie die Vermittlungssehieht unterstützen. Eine sorgfältige Abstimmung der verschiedenen Interessen ist in jedem Fall notwendig, um das VAXET als Gesamtnetzwerk funktional und stabil zu gestalten.

3.4 Mehrpunktverbindungen

Bei Mehrpunktverbindungen (engl. Multicasting) handelt es sieh um eine Technik, mit der sieh Daten effizient an eine dynamische Gruppe von Knoten im Netzwerk senden lassen. Statt an eine Gruppe mit n Knoten n mal ein Paket mit gleichem Inhalt zu verschicken, wird nur ein Paket verschickt, das an alle n Gruppenmitglieder zugestellt wird. Im Gegensatz zum Fluten des Netzes durch Rundfunkübertragungen wird das Paket aber nicht im gesamten Netzwerk verbreitet, sondern nur in den Teilen des Netzwerks, die notwendig sind, um alle n Mitglie­der der Gruppe zu erreichen. Dies erhöht die Effizienz bei Gruppenkommunikation erheblich, Mehrpunktverbindungen lohnen sieh dann, wenn dieselbe Information von einem Mitglied der Gruppe an alle anderen Mitglieder übermittelt werden soll. Ist die Anzahl der Gruppenmit­glieder gering, lohnt sieh der Mehraufwand für die Verwaltung einer Mehrpunktverbindung in der Regel nicht. Dasselbe gilt für den Fall, dass die Empfängergruppe sehr groß ist, d.h, einen großen Anteil am Gesamtnetzwerk hat, weil in diesem Fall das Fluten des Netzwerk mit Rundfunknaehriehten einfacher ist, auch wenn einige der Empfänger die Information gar nicht benötigen.

Im konventionellen Netzwerken werden Mehrpunktverbindungen oft eingesetzt, um Multime­diainhalte wie z, B, Fernsehübertragungen an eine Gruppe von Abonnenten zu übermitteln. Im VAXET sind denkbare Applikationen hierfür etwa Sprach- oder Bildverbindungen, an denen mehrere Teilnehmer im Rahmen einer Konferenz teilnehmen. Es können aber auch Fahreras­sistenzapplikationen davon profitieren. Mögliche Gruppierungsmerkmale sind Fahrzeuge eines bestimmten Herstellers oder Typs, Fahrzeuge auf bestimmten Straßenkategorien wie Autobah­nen, zusammengehörige Reisegruppen (Konvois) etc. Im Fall eines Konvois könnte es sinnvoll sein, dass alle Teilnehmer gegenseitig über den Aufenthaltsort und weitergehende Informationen auf dem Stand gehalten werden, auch wenn sich die Mitglieder räumlich voneinander entfernen. Schließlich können sich VANET-Teilnehmer auch an kommerziellen Diensten anmelden, die von Infrastruktur gestützt werden und Mehrpunktverbindungen benötigen, um alle Dienstnehmer zu erreichen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.13: Aufspannender Baum über der Netzwerktopologie für eine Mehrpunktverbin­dung

Die Umsetzung von Mehrpunktverbindungen findet auf der Vermittlungsschicht statt. Es handelt sich im wesentlichen um ein erweitertes Routingverfahren, das anstatt die Zustellung eines Pakets über eine Route an einen eindeutigen Empfänger die Verwaltung eines Teilnetzes vornehmen muss, um Pakete an alle zu einer Gruppe zugehörigen Teilnehmer übermitteln zu können. Außerdem müssen Mechanismen implementiert werden, um Gruppen für Mehrpunkt­verbindungen anzulegen, zu löschen und die es einzelnen Knoten im Netzwerk erlauben sich einer Gruppe anzuschließen bzw. sich von ihr wieder abzumelden. In konventionellen Netzwerk­en werden zur Implementierung von Mehrpunktverbindungen z. B. die aufspannenden Bäume über der Routertopologie berechnet, so dass dieser Baum alle Router erreicht, die mit Mitglie­dern einer Gruppe verbunden sind, Abbildung 3.13 stellt ein Beispiel dar für einen aufspannen­den Baum, der die Mehrpunktgruppe A.B.C.D abdeekt (grüne Kanten), Ein Mehrpunktpaket würde von Knoten A aus an Knoten B sowie in Richtung der Knoten C und D gesendet und die gesamte Gruppe somit abgedeekt. Für VAXETs gelten hier die typischen Beschränkungen, d.h, es existiert keine Infrastruktur und die Topologie ist hoehdynamiseh. Die Verwaltungsauf­gaben für Mehrpunktverbindungen können also in VAXETs nicht auf Infrastruktur beschränkt werden und einmal ermittelte Kommunikationspfade werden regelmäfsig ungültig und müssen neu berechnet werden. Konventionelle Ansätze zur Realisierung von Mehrpunktverbindungen können also nicht für VAXETs übernommen werden und es herrschen ähnliche Probleme wie bei herkömmlichen Routingalgorithmen, wie sie in Kapitel 3.1 behandelt wurden.

In |MLG04| wurden verschiedene Ansätze identifiziert, die helfen können, die Instabilität von Routen in MAXETs für Mehrpunktverbindungen abzufedern. Eine Möglichkeit ist es, die Mehr­punktrouten redundant auszulegen, damit Änderungen der Topologie nicht sofort die Gruppen­mitglieder voneinander trennt. Im Gegensatz dazu kann auch versucht werden, die Gruppengrö- fśen für Mehrpunktverbindungen zu beschränken. Dahinter steht die Überlegung, dass bei weni­ger beteiligten Knoten auch der Aufwand sinkt, die Verbindungen zwischen ihnen im Xetzwerk aufrecht zu erhalten. Weiterhin können nur möglichst stabile (d.h, sieh langsam oder gar nicht bewegende) Knoten als Weiterleitungsknoten für Mehrpunktverbindungen gewählt werden in der Hoffnung, dass sieh dann die Topologie für Mehrpunktverbindungen nicht so stark ändert. Ebenso vielversprechend ist der Ansatz, gar keine feste Struktur für Mehrpunktverbindungen im Xetzwerk aufzubauen und damit Verwaltungsaufgaben nicht explizit an Zwisehenknoten im Xetzwerk auszulagern, sondern die benötigten Informationen in die Mehrpunktpakete einzubet­ten, Dadurch kann jeder beliebige Knoten als Weiterleitungsknoten fungieren, was Änderungen der Xetzwerktopologie weniger schwerwiegend macht.

Die Ansätze, die eine fixe Teilmenge der Xetzwerkknoten als Weiterleitungsknoten für Mehr­punktverbindungen wählen, sind für VAXETs als eher ungeeignet zu betrachten. Diese spe­ziellen Mehrpunkt-Weiterleitungsknoten bilden ein eigenes Teilnetz, das sieh durch die hohe Mobilität der Knoten ständig verändert und durch VerwaltungsmafSnahmen aufrecht erhalten werden muss, Methoden bei denen alle Knoten gleichartig behandelt werden, passen sieh den VAXET-Eigensehaften zumeist besser an. Bei solchen Verfahren handelt es sieh um zustands­lose Mehrpunktprotokolle. Bei diesen werden zum Beispiel Verwaltungsdaten in die Kopfdaten von Mehrpunktpaketen eingebettet. So kann jedes Mehrpunktpaket an jeden beliebigen Kno­ten weitergeleitet und die tatsächliche Topologie immer berücksichtigt werden, ohne dass der Mehraufwand für die Verwaltung eines Mehrpunkt-Subnetzes im VAXET in Kauf genommen werden muss. Der Mehraufwand durch die Ablage der Verwaltungsdaten in den Kopfdaten von Mehrpunktpaketen sorgt zwar dafür, dass diese Methode nicht gut mit der Anzahl der Grup­penmitglieder skaliert. Doch in VAXETs werden aller Voraussicht nach keine besonders grofśen Multicast Gruppen entstehen bzw, realisierbar sein, so dass dieses Problem zu vernachlässigen ist.

Ein Beispiel für ein Mehrpunktprotokoll, das auch für hoehdynamisehe Ad-Hoe-Xetzwerke wie VAXETs geeignet ist, ist Route Driven Gossip (RDG) |LEH03|, Dabei handelt es sieh um ein probabilistisches Protokoll, das die dezentrale Verteilung von Information nutzt, um Fehler im Xetzwerk auszugleiehen und eine gewisse Zuverlässigkeit bei der Zustellung von Mehrpunkt­paketen realisiert, RDG setzt direkt auf einem beliebigen, herkömmlichen Routingprotokoll auf. Die Autoren selbst gehen von DSR als Routingalgorithmus aus. Jeder Knoten in einer Gruppe für Mehrpunktverbindungen verwaltet für RDG zwei Listen: Eine mit aktiven Gruppenmit­gliedern, zu welchen der Knoten mindestens eine gültige Route kennt und eine mit passiven Gruppentmitgliedern zu denen kein Xetzwerkpfad bekannt ist. Will ein Knoten zu einer Gruppe hinzu- oder aus einer Gruppe austreten, flutet er eine entsprechende Anforderungsnaehrieht im gesamten Xetzwerk, Erhalten Mitglieder der Gruppe die Anmeldenaehrieht eines neuen Knoten, fügen Sie den neuen Knoten in ihre Liste der aktiven Knoten ein und beantworten die Anfrage mit einer bestimmten Wahrscheinlichkeit, Der neue Knoten erstellt anhand der empfangenen Antworten der Gruppenmitglieder seine eigene Liste der aktiven Knoten, Die Verfügbarkeit von Routen zu Gruppenmitgliedern aus der Liste der aktiven und passiven Mitglieder wird regel- mäfsig von jedem beteiligten Knoten geprüft und die Listen entsprechend aktualisiert. Sollte die Anzahl der Einträge in der Liste der aktiven Knoten unter einen Grenzwert fallen, wird eine neue Anforderungsnaehrieht ins Xetzwerk geflutet, um neue aktive Gruppenmitglieder zu ermitteln.

Jedes Gruppenmitglied speichert Mehrpunktpakete in einem von zwei Zwischenspeichern für neue und alte Pakete, Pakete werden so lange als neue Pakete betrachtet, bis eine Mindestan­zahl an Übertragungen des Pakets stattgefunden hat. Danach wird das Paket als altes Paket betrachtet. Jedes Mitglied sendet nun regelmäfsig seine neuen Mehrpunktpakete an eine zu­fällige Teilmenge der Knoten aus der Liste der aktiven Gruppenmitglieder, Für die Pakete werden für die Mehrpunktgruppen eindeutige, laufende Xummern angenommen, die aus der Gruppenadresse, der Knotenadresse und einer Paketnnummer bestehen. Zusammen mit den Paketen wird auch die aktuellste Paketnummer mitgesendet, die der Senderknoten vom jeweili­gen Empfängerknoten vermisst. Die Empfängerknoten fügen empfangene Mehrpunktpakete in ihren Zwischenspeicher für neue Pakete ein, falls sie das Paket noch nicht kennen. Der Emp­fänger prüft nun, ob das vom Sender vermisste Paket sieh noch im Zwischenspeicher für neue

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.14: Beispiel zum RDG-Mehrpunktprotokoll

Pakete befindet. Ist dies der Fall, bestellt die Möglichkeit, dass das Paket durch einen der fol­genden, regelmäßigen Sendevorgänge ohnehin zum Sender geschickt wird. Ist das Paket jedoch bereits im Zwischenspeicher für alte Pakete, dann wird das fehlende Paket explizit an den Sender übertragen.

Ein Beispiel zu RDG ist in Abbildung 3.14 dargestellt. Im Beispiel existiert die Mehrpunkt­gruppe 1 mit den Mitgliedern A, B, C und D. Die Knoten B und D haben aktive Routen zu allen anderen Gruppenmitgliedern. Zwischen den Knoten A und C ist jedoch durch eine Topologieänderung die Route unterbrochen worden und deshalb befindet sich C in der Liste der inaktiven Knoten von A und andersherum. Baut der zugrunde liegende Routingalgorithmus eine neue gültige Route auf, werden diese Einträge wieder angepasst. Die Paketnummern haben die Form eines Tripels bestehend aus Gruppenadresse, Knotenadresse und Paketnummer. Da A und C sich derzeit nicht gegenseitig erreichen können, fehlt dem Knoten C das aktuelle Paket von Knoten A, (1, A, 3). Knoten D hat eine vorhergehende Übertragung von Knoten A, das Paket (1, A, 2) bisher nicht erhalten. Nun beginnt Knoten D mit seiner regulären Übertragung der neuen Mehrpunktpakete. Da D ein neues Paket (1, D, 2) erzeugt hat, wird dieses in diesem

Durchgang übermittelt. Als Empfängerknoten wählt Knoten D eine zufällige Menge mit zwei Elementen aus der Liste seiner aktiven Knoten, In diesem Fall überträgt er an die Knoten A und B (rote Pfeile), In die Kopfdaten der Übertragung trägt Knoten D ein, dass ihm das Paket (1, A, 2) bisher noch fehlt. Erreicht diese Übertragung die Knoten A und B, fügen sie das neue Paket (1, D, 2) in ihren Zwischenspeicher für neue Pakete ein, Knoten A stellt fest, dass das Paket (1, A, 2), das Knoten D noch fehlt, sich bereits in seinem Zwischenspeicher für alte Pakete befindet. Deshalb sendet er dieses Paket an Knoten D zurück, damit dieser die Lücke füllen kann (grüne Pfeile), Xaeh diesem Muster wird der Algorithmus fortgeführt und die Mehrpunktpakete verteilen sich allmählich unter allen Mitgliedern der Gruppe.

Der Vorteil des RDG ist, dass kein zusätzliches Mehrpunktnetz auf der Xetzwerktopologie ver­waltet wird. Auch werden nicht alle Gruppenmitglieder in die Kopfdaten von Mehrpunktpaketen eingetragen. Dies wird dadurch möglich, dass gar nicht versucht wird, mit jeder Übertragung eines Mehrpunktpakets alle anderen Gruppenmitglieder zu erreichen, Stattdessen wird direkt auf den herkömmlichen Routingalgorithmus aufgesetzt und immer nur an eine zufällige Teil­menge der Gruppenmitglieder übertragen. Da fehlende Pakete von den Senderknoten bekannt gegeben werden, verteilen sich alle Mehrpunktpakete nach und nach unter den Mitgliedern der Gruppe, Die sich verändernde Xetzwerktopologie wird durch dieses Verfahren abgefedert. Je­doch sorgt die probabilistische Xatur für erhöhte, stark gestreute Latenzen bei der Zustellung von Mehrpunktpaketen, was für Multimediaanwendungen nicht wünschenswert ist.

Insgesamt bestehen bei Mehrpunktverbindungen ähnliche Problemstellungen wie bei norma­len Ende-zu-Ende-Verbindungen, Der Hauptunterschied besteht darin, dass die Gruppeninfor­mationen zusätzlich verwaltet werden müssen. Ansonsten gelten hier dieselben Schlüsse wie im Abschnitt 3.1: Grofśe Mehrpunktgruppen werden bei der hohen Dynamik in VAXETs nur sehr schwierig zu realisieren sein und die Zuverlässigkeit dieser Verbindungen wird deutlich schlechter sein als in konventionellen Xetzwerken.

3.5 Transportprotokolle

Wie in konventiellen Computernetzwerken ist es auch in VAXETs wünschenswert, den Appli­kationen ein Transportprotokoll anzubieten. Das Transportprotokoll soll die Eigenschaften des physischen Netzwerks sowie der tieferliegenden Xetzwerksehiehten weiter abstrahieren und einen komfortablen und portablen Zugriff auf Xetzwerkfunktionalität gewährleisten. Die Transport­schicht ist die vierte Xetzwerkschicht und liegt über der Vermittlungsschicht. Sie ist die direkte Schnittstelle von Applikationen auf den Xetzwerkstapel (siehe Abbildung 2.5), Transportprotokolle werden in verbindungslose und verindungsorientierte Protokolle unterschieden.

Verbindungslose Protokolle wie UDP (User Datagram Protocol) aus der TCP/IP-Familie implementieren nur wenig zusätzliche Funktionalität, UDP prüft die Korrektheit der übertra­genen Daten mittels einer Prüfsumme, Aufśerdem werden mehrere logisch getrennte Datenflüsse in einem Multiplexverfahren zusammengeführt und über das Netzwerk übertragen, um dann beim Empfänger wieder an die richtigen, lokalen Empfängerapplikationen zugestellt zu werden. Dies geschieht über sogenannte Portnummern, welche eindeutig einem lokalen Applikations­prozess des Empfängerknoten zugeordnet werden. Bei der Datenübertragung übernimmt UDP die Eigenschaften der tieferliegenden Xetzwerksehiehten, Da das IP-Routingprotokoll (Inter­net Protocol) keine zuverlässige Datenübertragung anbietet und Pakete verlorengehen oder in unterschiedlicher Reihenfolge wieder beim Empfänger ankommen können, gilt dasselbe auch für Übertragungen, die über UDP durchgeführt werden. Möchte eine Applikation, die UDP als Transportprotokoll nutzt, höhere Zuverlässigkeit bei der Datenübertragung erreichen, muss diese selbst geeignete Logik implementieren, um verlorene Datenpakete zu erkennen und erneut zu versenden, sowie die Pakete in die richtige Reihenfolge zu bringen.

Verbindungsorientierte Protokolle wie TCP (Transmission Control Protocol) hingegen stellen einen umfangreichen Xetzwerkdienst zur Verfügung, der der Applikationsschicht solche Auf­gaben abnimmt, TCP baut dauerhafte Verbindungen zwischen Kommunikationspartnern auf. Verlorengegangene Pakete werden durch Austausch von Kontrollpaketen erkannt und erneut übertragen. Durch Nummerierung der Übertragungen werden beim Empfänger eintreffende Pakete in die richtige Reihenfolge gebracht. Weiterhin wird Flusskontrolle ausgeführt. Diese dient dazu, die Übertragungsgeschwindigkeit zwischen Sender und Empfänger anzugleichen, damit nicht mehr Daten gesendet werden als der Empfänger verarbeiten kann. Gleichzeitig wird die Übertragungsgeschwindigkeit im Rahmen der Uberlastkontrolle an die Kapazität des Netzwerks angepasst, um dieses nicht zu überlasten und einen möglichst gleiehmäfsigen Datenfluss zu er­möglichen.

Für die Applikationen bedeutet dies, dass das TCP wesentlich komfortabler ist, da es alle Eigenheiten des Netzwerks abstrahiert und die Applikationsebene von Vorgängen auf den tieferen Xetzwerksehiehten abkapselt. So muss sieh eine Applikation nur noeh um das Verarbeiten von Xutzdaten kümmern und diese über die Transportsehieht lesen und sehreiben, TCP ist in modernen Xetzwerken das dominierende Protokoll, da es die Realisierung von Xetzwerkappli- kationen wesentlich vereinfacht, UDP hingegen wird eher in begrenzten Gebieten eingesetzt, in denen entweder die Leistung (Rechenleistung und Xetzwerkdurchsatz) im Vordergrund steht, der Mehraufwand durch zusätzliche Kontrollpakete auf der Transportsehieht sieh nicht lohnt oder stärkerer Einfluss auf die Handhabung der Xetzwerkverbindung genommen werden muss, Tabelle 3.2 gibt einen Überblick über die Charakteristiken von TCP und UDP, TCP ist ein komplexes Protokoll, das gewissen Rechenaufwand darstellt und auch Mehraufwand bei der Datenübertragung bedeutet. Es erhöht die Latenz gegenüber verbindungsloser, unzuverlässi­ger Kommunikation über UDP, Weiterhin muss TCP, um den hohen Grad an Abstraktion für die Applikation zu erreichen, ein möglichst allgemeingültiges Xutzungsprofil implementieren. Dieses erfüllt nicht immer die Anforderungen von speziellen Applikationen, so dass in diesen Fällen auf UDP ausgewichen wird, UDP wird daher vor allem dann eingesetzt, wenn der Mehr­aufwand für Datenübertragungen so gering wie möglich sein soll oder Echtzeitanforderungen gegeben sind bzw, eine bestimmte Dienstgüte benötigt wird.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3.2: TCP und UDP im Vergleieli

TCP und UDP stellen Referenzimplementierungen für verbindungsorientierte und verbin­dungslose Transportprotokolle dar. Dies resultiert aus der starken Verbreitung der TCP/IP- Protokollfamilie im Internet und lokalen Xetzwerken, Sie werden deshalb naturgemäfs auch für VAXETs vorgesehen, um dieselbe Funktionalität der Transportsehieht wie in konventionellen Netzwerken zur Verfügung zu stellen. Bei UDP stellt das kein besonderes Problem dar, da es sieh nur um eine dünne Protokollsehieht handelt, die die Eigensehaften der tieferliegenden Xetz- werksehiehten annimmt und keine besondere, eigene Logik implementiert. Bei TCP hingegen ist dies nicht so problemlos machbar. Obwohl aufgrund der Trennung der verschiedenen Xetz- werksehiehten gemäfs dem OSI-Modell eine weitgehende Unabhängigkeit der Transportsehieht von den tieferen Xetzwerksehiehten herrschen sollte, ist dies in der Praxis nicht uneingeschränkt der Fall, Das TCP-Protokoll setzt, um seine umfassenden Dienste zu realisieren, implizit einige Xetzwerkeigensehaften voraus, die in VAXETs so nicht mehr gegeben sind. Diese Probleme mit dem Einsatz von TCP in Fahrzeug-zu-Fahrzeug-Xetzwerken werden im Folgenden näher betrachtet und mögliche Lösungsansätze vorgestellt.

3.5.1 Verhalten von TCP in VANETs

Überlastkontrolle bei TCP

Zum besseren Verständnis der Problemstellungen von TCP in VAXETs wird zunächst der Al­gorithmus zur Überlastkontrolle des TCP näher vorgestellt, TCP setzt ein Verfahren zur Fluss- und Überlastkontrolle um, das dafür Sorge tragen soll, dass die maximal mögliche Bandbreite der Verbindung zu einem Kommunikationspartner ausgenutzt wird |Tanenbaum03|, Die Über- tragungsgesehwindigkeit wird abhängig vom Übertragungserfolg festgelegt. Gründe für Eng­pässe bei der Datenübertragung können entweder der Empfängerknoten sein, der ankommende Daten nicht schnell genug verarbeiten kann, Oder das Netzwerk kann die Daten nicht schnell genug vom Sender zum Empfänger befördern, d.h, auf der Route gibt es einen Engpass und Überlastung tritt auf.

TCP verwaltet zur Bestimmung der maximalen Übertragungsgesehwindigkeit zwei Fenster- gröfsen, Eine FenstergröfSe wird vom Empfänger vorgegeben und bestimmt, wie viel Daten der Empfänger verarbeiten kann. Die andere FenstergröfSe gibt vor, wie viel Daten das Netz­werk maximal zum Empfänger transportieren kann. Das Minimum dieser beiden FenstergröfSen bestimmt die tatsächliche Obergrenze der Datenmenge, die auf einmal durch TCP zum Kom­munikationspartner übertragen wird. Die aktuelle FenstergröfSe des Empfängers teilt dieser im Bestätigungspaket regelmäfsig mit, so dass der Sender immer weils. wie viel Daten an den Emp­fänger gegenwärtig gesendet werden können. Die FenstergröfSe für die Xetzwerkkapazität wird in einem Selbsttaktungsverfahren bestimmt, das in zwei Phasen arbeitet. Im Folgenden wird an­genommen, dass die Übertragungsgesehwindigkeit allein von der Xetzwerkkapazität und nicht von der Verarbeitungskapazität des Empfängers abhängt.

Zu Beginn einer TCP-Verbindung liegt die Fenstergröße für die Überlastkontrolle bei der Größe eines TCP-Segments. Ein TCP-Segment ist die maximale Größe eines einzelnen TCP- Pakets, wie es an die tieferliegenden Schichten im Netzwerkstapel übertragen werden kann. Die maximale Größe eines Segments hängt von den Eigenschaften der anderen Netzwerkschichten und den physikalischen Eigenschaften des Netzwerks ab. Für jedes TCP-Segment, das der Sen­der überträgt, wird vom Empfänger ein Bestätigungspaket (ACK) zurückgesendet. Wird nach der ersten Übertragung von einem TCP-Segment das Bestätigungspaket rechtzeitig (vor einer Zeitüberschreitung) vom Sender erhalten, erhöht er die Größe des Übertragungsfensters um die Größe eines weiteren TCP-Segments. Die Dauer bis zur Zeitüberschreitung orientiert sich an der RTT der Verbindung. Im weiteren Verlauf dieses Verfahrens wird für jedes erhaltene Bestäti­gungspaket die Fenstergröße um eine Segmentgröße erhöht. D.h. wenn das Übertragungsfenster bei 32 Segmentgrößen liegt- und die folgende Übertragung von 32 Segmenten wird erfolgreich 32 mal bestätigt dann wird die Fenstergröße auf 64 Segment großen erhöht. Es handelt sich also um ein exponentielles Wachstum der Übertragungsgeschwindigkeit. Diese erste Phase des Verfahrens ist die sog. slow-start (dt. etwa: langsamer Beginn) Phase.(zum Beispiel 64 Kilobyte), Liegt die Fenstergröße über diesem Grenzwert, wechselt das Verfah­ren in die zweite Phase, die Überlastvermeidungsphase, In dieser Phase wächst das Fenster nur noch in linearer Geschwindigkeit weiter, d.h, um eine Segmentgröße je erfolgreicher Gesamtüber­tragung in Höhe der Fenstergröße, Geht man davon aus, dass die Verarbeitungskapazität des Empfängers größer ist als die Übertragungskapazität des Netzwerks, erreicht die Übertragungs­geschwindigkeit schließlich eine Höhe, die vom Netzwerk nicht mehr gehandhabt werden kann. Eines oder mehrere Pakete werden dann nicht mehr oder zu spät beim Empfänger ankommen und folglich auch keine Bestätigungspakete dazu vom Sender erhalten, bevor eine Zeitüber­schreitung stattfindet. In diesem Fall wird der Grenzwert für den Wechsel von der slow-start Phase in die Überlastvermeidungsphase auf die Hälfte der gegenwärtigen Fenstergröße gesetzt, die neue Fenstergröße wird auf die Größe eines TCP-Segments zurückgesetzt und das Verfahren wechselt wieder in die slow-start Phase mit exponentiellem Wachstum.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.15: Überlastkontrolle bei TCP (Beispiel übernommen aus [Tanenbaum03]) Diese Phase wird so lange fortgesetzt, bis ein Grenzwert für die Fenstergröße erreicht wird

Abbildung 3.15 stellt den Wachstumsverlauf des Übertragungsfensters für die Überlastkon­trolle dar. Die maximale Größe eines TCP-Segments ist hier ein Kilobyte, Bei jeder Übertragung wird die volle Größe des Übertragungsfensters ausgenutzt. Zu Beginn wird die einfache TCP- Segmentgröße übertragen. Da sieh der Algorithmus in der slow-start Phase befindet, wächst das Fenster exponentiell auf 2, 4, 8, 16 und schließlich 32 Kilobyte, Bei 32 Kilobyte liegt der initiale Grenzwert, weshalb der Algorithmus in die zweite Phase wechselt und nur noch linear um eine Segmentgröße je Übertragung wächst. Dies geschieht bis zu einer Fenstergröße von 36 Kilobyte, Bei dieser Übertragung findet eine Zeitüberschreitung statt. In der Folge wird der Grenzwert von der aktuellen Fenstergröße von 36 Kilobyte auf 18 Kilobyte halbiert. Die Fenstergröße wird gleichzeitig auf die einfache Segmentgröße von einem Kilobyte zurückgesetzt. Nun beginnt das Wachstum wieder exponentiell bis zur neuen Größe des Grenzwertes und schließlich setzt es sieh linear fort.

Der Grundgedanke dieses Algorithmus ist, dass zu Beginn ein hohes Wachstum herrscht, so dass schnell eine hohe Auslastung der möglichen Netzwerkkapazität erreicht wird. Ab dem Grenzwert, der dynamisch an die Kapazität des Netzwerks angepasst wird, wird nur noch ein langsames Wachstum der Geschwindigkeit durchgeführt, um keine Überlastung zu provozieren.

Probleme der Überlastkontrolle in VANETs

Wie in |SPS04| aufgezeigt wird, bringt dieser Algorithmus zur Überlastkontrolle in MANETs einige Probleme mit sieh. Die Berechnung geeigneter Werte für die Zeitüberschreitung von Be­stätigungspaketen etwa gestaltet sieh bereits in konventionellen Netzwerken nicht einfach. Wird der Wert für die Zeitüberschreitung zu niedrig angesetzt, werden viele Pakete fälschlicherweise als verloren angenommen und neu übertragen, während der Algorithmus zur Überlastkontrol- le mit einer Reduktion des Übertragungsfensters auf die Gröfse eines TCP-Segments und der Halbierung des Grenzwerts reagiert. Wird die Grofśe jedoch zu hoch gewählt, wird unnötig lange auf die Ankunft bereits verlorener Pakete gewartet, was den Datendurchsatz ebenfalls schmälert. Die Orientierung der Zeitüberschreitung an der RTT erfordert, dass die RTT auch über einen langen Zeitraum stabil bleibt. Die RTT hat jedoch schon in konventionellen Netz­werken eine hohe Streuung, Deshalb wird in TCP die Gröfse des Wertes zur Zeitüberschreitung dynamisch an die Entwicklung der RTT angepasst |Tanenbaum03|, In VAXETs jedoch ist die Streuung der RTT aufgrund der dynamischen Xatur des Netzwerks noch deutlich höher als in konventionellen Netzen, Diese Streuung resultiert aus dem hohen und schwankenden Wett­bewerb um den Medienzugriff, hohe Hop-Zahlen bei Ende-zu-Ende-Verbindungen und die sieh permanent ändernde Xetzwerktopologie, Aus der hohen Schwankung der RTT resultiert, dass TCP in VAXETs dazu tendiert, sehr hohe Zeitiibersehreitungswerte zu wählen, was für den Durchsatz und die Latenz von TCP-Verbindungen schlecht ist, wenn tatsächlich ein Paket­verlust auftritt. Die Zeitiibersehreitungswerte von TCP können in VAXETs sogar Werte von mehreren Sekunden annehmen.

Ein weiteres Problem für TCP ist die Ungleiehbehandlung, die der Medienzugriff von IEEE 802.11 mit sieh bringt (vgl, 2.4.1), Durch die Ungleiehbehandlung kann die Bandbreite für eine Verbindung im Netzwerk vorübergehend höher erscheinen, als sie tatsächlich ist, TCP passt in diesem Fall seine FenstergröfSe für die Überlastkontrolle an die höhere Bandbreite an. Bei nachfolgenden Übertragungen, wenn der Knoten keinen oder weniger Zugriff auf das Medium erhält, sorgt dies für ein Rückfällen der TCP-Überlastkontrolle in die slow-start Phase.

Das Zuriieksetzen der FenstergröfSe bei der Überlastkontrolle in der slow-start Phase auf die einfache TCP-SegmentgröfSe stellt in kabelbasierten Netzwerken kein Problem dar, weil TCP davon ausgeht, dass der gröfste Teil der Zeit in der zweiten Phase, der Überlastvermeidung verbracht wird. Diese Annahme trifft auf diese Netzwerke zu. Da in VAXETs jedoch wesentlich häufiger Fehler bei der Datenübertragung und Veränderungen in der Verbindungsgüte auftro­ten, droht, dass das TCP in VAXETs die meiste Zeit in der slow-start Phase verbringt, was ungenutzte Bandbreite bedeutet. Denn obwohl in dieser Phase ein exponentielles Wachstum der Übertragungsgesehwindigkeit herrscht, benötigt der Algorithmus mehrere Rundlaufzeiten, bis die optimale Bandbreite wieder erreicht ist. Weiterhin setzt TCP in der slow-start Phase ein aggressives Verhalten um, das schlechte Eigenschaften bezüglich der Gleichberechtigung im Netzwerk aufweist. Bessere Eigenschaften der Gleiehbehandlung werden hingegen in der Phase der Überlastvermeidung erreicht.

Eine Grundannahme der Überlastkontrolle von TCP ist die, dass Paketverluste fast aus- sehlielslieh auf eine Überlastung des Netzwerks zuriiekzuführen sind |Tanenbaum03|, |SPS04|.

Diese Annahme ist in MAXETs nicht mehr erfüllt, da hier ans der Mobilität der Knoten re­sultiert, dass sehr häufig Routingfehler auftreten. Auch ist die Qualität von drahtlosen Xetz- werkverbindungen gegenüber Übertragungen über kabelgebundene Medien deutlich niedriger. Während in modernen Kabelnetzwerken kaum mehr Übertragungsfehler auftreten, kommen diese in Funknetzwerken durchaus häufig vor und haben einen grofśen Anteil an der Zahl der nicht übermittelten Pakete im Netzwerk. TCP verhält sieh dennoch in jedem Fall so als sei eine Überlastung des Netzwerks eingetreten. Das hat zur Folge, dass TCP auch bei Routenfehlern die Ermittlung der Xetzwerkkapazität von Vorne beginnt. Da die Routen in MAXETs jedoch wie in 3.1.6 dargestellt, wurde oft nur sehr kurze Lebenszeiten haben, erreicht der Algorithmus zur Überlastkontrolle oft gar nicht die maximale Bandbreite der Verbindung bevor die Route fehlerhaft wird und TCP deshalb sein Übertragungsfenster wieder drosselt.

Weitere problematische Aspekte lassen sieh bei den Bestätigungspaketen von TCP ausma- ehen, TCP sendet Bestätigungspakete als eigenständige, separate Pakete, Diese konkurrieren deshalb direkt um das Medium, Da die Bestätigungs- und Datenpakete auf demselben Pfad verlaufen, konkurrieren diese stark miteinander. Die Bestätigungspakete werden jedoch zur Steuerung der Datenübertragungsgesehwindigkeit herangezogen, weshalb dieser Mechanismus für TCP ein verzerrtes Bild erzeugt. Weiterhin führen die Bestätigungspakete zu deutlichem Mehraufwand, da beim CSMA/CA Verfahren von IEEE 802.11 (siehe 2.4.1) zusätzlich noch auf der Sieherungssehieht Kontrollpakete versendet werden, so dass hier doppelter Mehraufwand entsteht.

Der schwierige Medienzugriff in Ad-Hoe-Xetzwerken sorgt direkt für eine Verschlechterung der Situation beim Einsatz von TCP, Bei hoher Knotendichte kann es lange Zeit dauern bis auf der Sieherungssehieht aufgrund von Kollisionen eine Anzahl von erneuten Sendeversuehen durehgefiihrt wurde. Während dieser Zeit sendet TCP jedoch weiterhin Daten über diese Ver­bindung, bis das Übertragungsfenster von TCP ausgesehöpft ist. Bricht eine Verbindung auf der Sieherungssehieht sehliefślieh ab, weil ein Kommunikationspartner aufśer Kommunikations­reichweite ist, sind die gesamten Daten auf der Sieherungssehieht verloren und müssen ggf, von höheren Schichten über eine neue Route versendet werden. Da das TCP keine Unterscheidung zwischen unterschiedlichen Gründen für Übertragungsfehler vornimmt, führt auch ein solcher Fehler zur Zeitüberschreitung der Antwortzeit des Empfängers, obwohl in diesem Fall in keiner Weise die Xetzwerkkapazität berührt ist, sondern die Verbindung zum Empfänger nicht mehr aufrecht steht. Da Routenbereehnungen in MAXETs mehrere Sekunden benötigen können, be­steht bei Routenfehlern also ein grofśes Zeitfenster während dem die Vermittlungssehieht gar keine Pakete versenden kann, TCP erfährt in dieser Zeit viele Zeitüberschreitungen und fällt da­mit durch die Überlastkontrolle zum minimalen Übertragungsfenster und geringen Grenzwerten zurück. Weiterhin werden die Zeitüberschreitungswerte unnötig erhöht.

3.5.2 Verbesserungen von TCP für VANETs

Um den erkannten Problemen von TCP in MAXETs bzw, VAXETs entegegenzuwirken, gibt es einige Verbesserungsmögliehkeiten, In |SPS04| werden drei Ansätze identifiziert, das Transport­protokoll an die veränderten Betriebsbedingungen anzupassen. Dazu gehört die Modifikation von TCP, um auf spezifische Merkmale von Ad-Hoe-Xetzwerken einzugehen, die Anpassung der Sicherungs- und Vermittlungssehieht, um die problematischen Eigenschaften von MAXETs für TCP auszublenden, sowie die Entwicklung eines vollständig neuen Transportprotokolls, das die­selben Dienste wie TCP für Ad-Hoe-Xetzwerke zur Verfügung stellt. Für jeden dieser Ansätze wurde eine konkrete Implementierung vorgestellt und im Rahmen einer Simulation mit dem herkömmlichen TCP verglichen.

Für das modifizierte TCP wurde folgende Änderung vorgenommen: Wird eine Route unter­brochen, wird vom betroffenen Zwischenknoten eine Verbindungsfehlermeldung an alle Quell­knoten von TCP Verbindungen, die auf dieser Route verlaufen, zurückgesendet. Diese Meldung wird dem TCP mitgeteilt. Dieses friert nun seinen Status für die betroffene Verbindung ein, wozu die FenstergröfSen der Überlastkontrolle sowie Zeitüberschreitungszähler gehören. Gleich­zeitig berechnet das Routingprotokoll eine neue Route, TCP sendet in regelmäfsigen Intervallen Testpakete an das Verbindungsziel, um zu prüfen, wann die Route wiederhergestellt ist. Wird sehliefslieh ein Bestätigungspaket erhalten, wird die Verbindung mit den eingefrorenen Parame­tern fortgesetzt. Wird hingegen die Route innerhalb einer Grenzzeit nicht wiederhergestellt wird die Verbindung trotzdem fortgesetzt und die übliche Fehlerbehandlung von TCP findet statt bis hin zur Unterbrechung der Verbindung durch Zeitüberschreitungen, Diese Veränderungen erlauben es TCP, auch nach Routenfehlern mit hoher Bandbreite die Verbindung fortzusetzen. Die Simulation zeigt für diese Modifikation geringere Paketverluste, da bei fehlerhaften Routen TCP nicht weiterhin versucht, Pakete zu übermitteln, Aufserdem ist der Durchsatz höher als bei normalem TCP, Insgesamt sind die Verbesserungen jedoch eher gering.

Auch die Anpassung der Sicherungs- und Vermittlungsschicht bei Beibehaltung des normalen TCP wurde durchgeführt. Hierbei wurde der DSR-Routingalgorithmus dahingehend erweitert, dass nur symmetrische Routen für Ende-zu-Ende Verbindungen verwendet werden. Das heilst. der Weg vom Sender zum Empfänger ist in jedem Fall derselbe wie der Weg vom Empfänger zum Sender, Dies muss im herkömmlichen DSR-Algorithmus nicht der Fall sein. Der Xaeh- teil von asymmetrischen Routen ist, dass die Ausfallwahrscheinlichkeit einer beliebigen Kom­munikationsrichtung wesentlich erhöht ist, für TCP jedoch schon der Ausfall einer beliebigen Übertragungsrichtung gleichermafśen schwerwiegend ist. Weiterhin wird versucht, Routenfehler vorherzusagen und sehen bevor eine Route fehlerhaft wird eine neue zu bereehnen, um das Zeitfenster während dem keine Verbindung zum Zielknoten besteht zu minimieren bzw, zu eliminieren, Sehliefślieh werden Routenfehlernaehriehten von DSR nicht mehr nur an den Sen­derknoten zurückgesendet, der ein Paket übermitteln wollte, sondern an alle Knoten, die eine Route durch die Fehlerstelle im Einsatz haben. Solche proaktiven Fehlermeldungen für Routen verkürzen weiterhin die Zeit während der gar keine Verbindung zum Zielknoten besteht, wenn die Vorhersage von Routenfehlern versagt hat. Die Simulation dieser Anpassungen zeigt deut­liche Besserungen gegenüber normalem DSR mit TCP, Vor allem die Skalierbarkeit bzgl, der Mobilität ist deutlich verbessert.

Sehliefślieh wird auch ein Transportprotokoll betrachtet, das explizit für Ad-Hoe-Xetzwerke entwickelt wurde. Das Ad-Hoc Transport Protocol (ATP) setzt wesentliche Elemente um, die notwendig sind, um mit den Eigenschaften von Ad-Hoc-Xetzwerken umzugehen, ATP setzt Überlastkontrolle ein, die im Gegensatz zu TCP die gesamte Route mit einbezieht, Parameter zur Xetzlast werden in jedem ATP-Paket mitgesendet und jeder an der Route beteiligte Knoten passt die Werte gemafś seiner lokalen Daten an. Der Empfänger reagiert sehliefślieh mit einem Antwortpaket zurück an den Sender, in dem die gemittelte Xetzwerklast auf der Route enthalten ist, ATP reagiert auf diese Informationen mit einer Anpassung der Sendegesehwindigkeit, die in drei Stufen erfolgen kann: Erhöhung, Reduktion oder Beibehaltung der Geschwindigkeit, Dies erlaubt bereits nach dem ersten Riiekmeldepaket die vollständige Aussehöpfung der Bandbreite auf der Route, im Gegensatz zum Verfahren von TCP, Statt normaler Bestätigungspakete werden selektive Bestätigungspakete ähnlich wie bei der TCP-SACK-Erweiterung (Selektive Acknowledge) verwendet, bei denen im Fehlerfall nicht immer eine ganze Fenstergrofśe neu gesendet werden muss, sondern nur einzelne Pakete, die verloren gegangen sind. Die weiteren Mechanismen von ATP lehnen sieh weitgehend an TCP an. Die Simulationsergebnisse von ATP gegenüber TCP sind sehr gut. Es entsteht ein sehr gleiehmafśiger Datenfluss und die verfügbare Bandbreite wird die meiste Zeit über ausgenutzt. Der Durchsatz ist über ein Drittel höher als bei TCP.

Eine weitere Optimierungsanalyse wurde in |DB01| durehgefiihrt. Dort werden zwei Modifika­tionen von TCP untersucht: Wie bereits in ATP werden auch hier selektive Bestätigungspakete verwendet, die verhindern, dass bei Fehlern immer das ganze Übertragungsfenster wie in TCP neu übertragen werden muss. Weiterhin wird ein konstanter Zeitiibersehreitungswert für Bestä­tigungen eingeführt, wenn Routingfehler auftreten. Um eine Unterscheidung zwischen Routing­fehlern und einer Überlastung des Xetzwerks zu ermöglichen, wird eine Heuristik angewandt, die bei mehrfach nacheinander auftretenden Zeitüberschreitungen von einem Routenfehler ausgeht und sonst von einer Überlastung des Xetzwerks, Die Modifikationen werden mit Standard-TCP beim Einsatz von drei verschiedenen Routingprotokollen verglichen. Die selektiven Bestäti­gungspakete zeigten dabei nur minimale Vorteile, während der feste Zeitüberschreitungswert deutliche Verbesserungen bei der Latenz gezeigt hat.

Eine Möglichkeit, die Sicherungsschicht für TCP-Verbindungen zu optimieren, wurde be­reits in 2.4.2 aufgezeigt, die den Austausch von Informationen über Zwei-Wege-Datenfliisse von Transportprotokollen beim Medienzugriff vorsieht, um die Verzögerung bis zum Eintreffen der Bestätigungspakete bei einem TCP-Senderknoten zu reduzieren.

3.5.3 Schlussfolgerungen

Die Analysen und Messungen zeigen deutlich, dass das TCP in der bekannten Form kein geeig­netes verbindungsorientiertes Transportprotokoll für VAXETs ist. Aus der Xatur von VAXETs folgt, dass Fehler nicht Ausnahmen darstellen sondern regelmäfsige Ereignisse sind. Dies führt zu Fehleinschätzungen der Logik von TCP und teilweise zur Unbenutzbarkeit von Verbind­ungen, In jedem Fall jedoch führt es zu mangelndem Durchsatz und hoher Latenz, TCP sieht zwar eine dynamische Anpassung der Verbindungsparameter an die Bedingungen im Xetzwerk vor. Diese Anpassungen gehen jedoch nicht davon aus, dass sieh die Xetzwerkeigenschaften innerhalb kurzer Zeit radikal ändern oder Verbindungen vorübergehend überhaupt nicht mehr möglich sind.

Viele Arbeiten halten dennoch gerne an TCP als Protokoll für VAXETs bzw, MAXETs fest. Oft wird damit argumentiert, dass die Internetintegration von MAXETs erfordert, dass das TCP zum Einsatz kommt. Für VAXETs spielt dies kaum eine Rolle, Die Schnittstellen für Ap­plikationen ändern sieh auch beim Einsatz neuartiger Transportprotokolle nicht grundlegend. Die Kompatibilität zum Internet kann durch Schnittstellenknoten, die VAXETs mit dem In­ternet verbinden, hergestellt werden. Die Idee, dass ein VAXET auf derselben Ebene wie das Internet agiert, ist illusorisch, da die Eigenschaften beider Xetzwerktypen extreme Unterschiede aufweisen. Deshalb müssen entsprechende Umsetzungsmeehanismen implementiert werden, die die Unterschiede zwischen den Xetzen an deren Schnittstellen voneinander abkapseln.

Ein verbindungsorientiertes Transportprotokoll, das VAXET-Applikationen den Komfort wie TCP in konventionellen Xetzen bietet, wird dennoch notwendig sein. Der Grofśteil der Kommu­nikation im Internet etwa spielt sieh über TCP ab. Es bedeutet eine Vereinfachung der Applika- tionsentwieklung, was den Einsatz von TCP so attraktiv macht. Gerade in VAXETs bietet ein gutes Transportprotokoll die Möglichkeit, die Applikation von den Eigenheiten des Xetzwerks stärker abzusehirmen. Um ein geeignetes Transportprotokoll für VAXETs zu erhalten, eignet sieh die Form eines weitgehend eigenständig entwickelten und an Ad-Hoe-Xetzwerken orien­tierten Transportprotokolls, Dies ist gegenüber modifizierten Varianten von TCP sicher als die sinnvollste Lösung zu erachten. Die Optimierung niedrigerer Xetzwerksehiehten hinsichtlich ei­nes solchen Transportprotokolls ist in Teilen auch als sinnvoll zu betrachten. Darunter fällt etwa die Unterscheidung zwischen Paketverlust durch Überlastung oder Routenfehler, die für höhere Xetzwerksehiehten nachvollziehbar sein sollte. Dies erlaubt die wesentlich gezieltere und damit effizientere Steuerung von Datenflüssen auf der Transportsehieht, Jedoch muss dabei darauf geachtet werden, dass sieh Schnittstellen zwischen Xetzwerksehiehten nicht an den konkreten Implementierungen von Xetzwerkprotokollen orientieren dürfen, um ein hohes Abstraktions­niveau beizubehalten. Für Applikationen sollte auch ein eigenes VAXET-Transportprotokoll keinen wesentlichen Unterschied bei den Schnittstellen zum Xetzwerkstapel bedeuten. Aus Ap­plikationssieht handelt es sieh weiterhin um ein verbindungsorientiertes, zuverlässiges Protokoll, das die Aufgaben der Xetzwerkverwaltung übernimmt.

Die mangelhafte Eignung des TCP für MAXETs zeigt auch die Grenzen des Anspruchs des OSI-Sehiehtenmodells, dass Protokollsehiehten beliebig austauschbar sein sollen. Wenn­gleich TCP in vielen kabelbasierten Xetzwerken, sowie im Infrastrukturmodus von IEEE 802.11 WLAX gleiehermafśen funktioniert, sind die Grundvoraussetzungen von MAXETs derart ver­schieden von herkömmlichen Xetzwerken, dass es nicht mehr möglich ist, TCP hier sinnvoll einzusetzen. Dies liegt daran, dass das TCP implizit Eigenschaften der tieferliegenden Xetz­werksehiehten angenommen hat, wie zum Beispiel, dass die Topologie sieh nicht schnell ändert und deshalb Routen dauerhaft bestehen. Wie schon in 2.4.1 erkannt wurde, hat auch die Art des Medienzugriffs nicht unwesentlichen Einfluss auf Funktionalität von höheren Schichten wie die Transportsehieht.

3.6 Adressierung

Die Adressierung von Knoten in VAXETs ist ein selten behandeltes Thema, Viele Arbeiten gehen — angelehnt an konventionelle Xetzwerke — in VAXETs von IP-Adressen für jeden Knoten aus. Hier stellt sieh die zunächst die Frage, welche Teile der TCP/IP-Protokollfamilie noch für ein VAXET von Bedeutung sind. Das TCP-Protokoll, das IP-Adressen einsetzt, ist wie im vorigen Kapitel behandelt wurde nicht für VAXETs geeignet. Das Routingprotokoll IP sieht Adressen vor, die primär dem Routing sowie der eindeutigen Benennung von Knoten im Xetzwerk dienen. Das Routing in VAXETs wird von Algorithmen durehgefiihrt, die vom IP vollkommen verschiedenen sind, so dass die Routinglogik des IP hier keine Rolle mehr spielt. Die IP-Adressen dienen im Rahmen von IP auch als Gruppierungselement, um logische Struk­turen über die Xetzwerktopologie zu legen. Durch sie werden Subnetze oder Spezialadressen für Rundfunk und Mehrpunkt Verbindungen definiert. Im VAXET jedoch gibt es keine Gruppen mehr, die sieh im Adressierungsschema von IP abbilden lassen. Die Topologie ändert sieh ständig Infrastruktur gibt es nicht und somit auch keine festen Subnetze, Eine eindeutige Adresse be­sitzt jeder Knoten schon durch die in IEEE 802.11 definierte 48-Bit MAC-Adresse, wie sie auch im konventionellen Ethernet nach IEEE 802.3 eingesetzt wird. Für die potentielle Internetan­bindung eines VAXETs können Schnittstellenknoten die MAC-Adressen von VAXET-Knoten transparent in IP-Adressen umsetzen.

Der Einsatz von IP-Adressen in VAXETs bringt also keine Vorteile, Werden IP-Adressen dennoch genutzt, ergibt sieh hingegen ein zusätzliches Problem für die Xetzwerkorganisation: Da es keine zentralen Instanzen im Xetzwerk gibt, können auch keine IP-Adressen an Knoten zugewiesen werden. Es muss also eine Möglichkeit gefunden werden, IP-Adressen dezentral zu vergeben, ohne dass doppelte Adressen vergeben werden, die im Xetzwerk kollidieren. Ein Ansatz zur dezentralen IP-Adressvergabe in MAXETs wird in |JT06| vorgestellt. In allgemeinen MAXETs haben IP-Adressen eine höhere Bedeutung als in VAXETs, weil dort die Xähe zu IP-Xetzwerken gröfser sein kann, Aufśerdem herrscht dort eine gröfsere Interaktivität mit dem Xetzwerk und Benutzer müssen die Möglichkeit haben, mit einfachen Adressen im Xetzwerk zu agieren.

In |JT06| wird die reduzierte Rolle von IP-Adressen in MAXETs erkannt und es wird auf ein rein namensbasiertes Adressierungsschema gesetzt. Der Benutzer adressiert andere Knoten im Xetzwerk nur noch durch seinen Xamen, Jeder Knoten weist anderen Knoten im Xetzwerk, mit denen er in Kontakt steht, eine beliebige, lokal gewählte IP Adresse zu, die nur lokal ein­deutig ist. Dadurch hat jeder Knoten eine eigene Sieht auf die IP-Adressen der Knoten im Xetzwerk, die durch XAT-Übersetzungstabellen (Xetwork Address Translation) repräsentiert wird. Tatsächlich werden Knoten nur über den Xamen identifiziert. Die IP-Adressen dienen dabei lediglich dem Zweck, herkömmlichen, IP-basierten Applikationen eine IP-Adresse vorzu­geben, Die Kommunikation und das Routing verlaufen über MAC-Adressen, Ein Beispiel hierzu ist in Abbildung 3.16 gegeben. Wie dort deutlich wird hat jeder Knoten eine eigene Adressta­belle über die Knoten im Xetzwerk, die lokal verwaltet wird, d.h, wenn ein neuer Knoten im Xetzwerk auftritt, teilt dieser seinen Xamen mit und ihm wird eine beliebige IP-Adresse von jedem anderen Knoten zugewiesen. Versendet mm z, B, Knoten A ein Paket an Knoten C, erzeugt er IP-Kopfdaten mit der Adresse 192.168.5.3 als Absenderadresse und 192.168.2.3 als Empfängeradresse, Da die IP-Adressen nicht für Routing und Kommunikation eingesetzt wer­den, werden sie von der Sieherungs- und Vermittlungssehieht ignoriert. Kommt das Paket bei Knoten C an, dann stellt er fest, dass das Paket von Knoten A stammt und ersetzt deshalb die Absenderadresse mit der 192.168.1.5 und die Empfängeradresse mit 192.168.1.7, In dieser Form wird das Paket an die höheren Schichten weitergereicht, so dass die Applikation nicht bemerkt. dass die IP-Adressen eigentlich gar nicht eindeutig sind. Auch doppelte Adressvergabe steht so kein Problem dar, so dass wie im Beispiel Knoten B und C beide für sich die selbe IP-Adresse 192.168.0.3 vergeben können, ohne dass ein Problem entsteht.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.16: Dezentrale IP-Adressierung in MANETs

Für die Namensvergabe werden die herkömmlichen DNS-Namen (Domain Name System) vorgesehen. Da auch hier Namenskollisionen auftreten können, wird damit argumentiert, dass es Routingprotokolle gibt, die das Problem mehrfach vorkommender Namen umgehen können, indem sie in diesem Fall lokale Bezeichnungen für die doppelt vorkommenden Namen verge­ben. Für VANETs könnte aus Gründen dieser IP-Kompatibilität ein solches Schema adaptiert werden. Ein vollständig von IP-Adressen befreites VANET würde diesen Mehraufwand jedoch vollständig beseitigen, ohne an Funktionalität einbüßen zu müssen. Der Einsatz unmodihzierter IP-basierter Applikationen in VANETs wird hier keine besondere Bedeutung haben.

Ein Aspekt der Adressierung der von größerer Bedeutung für VANETs ist, ist die Anonymi­tät der Fahrzeuge im Netzwerk. MAC-Adressen bringen zwar alle notwendigen Eigenschaften für den Betrieb in VANETs mit. Doch sind diese global und dauerhaft eindeutig. Man könnte durch Verfolgung der MAC-Adressen in mitgelauschten Paketen Bewegungsprofile von Fahr­zeugen erstellen oder sie verfolgen. Eine zufällige Zuweisung von MAC-Adressen an Knoten im VANET wäre aus Gründen des Datenschutzes also sinnvoll. Dies würde jedoch wieder die Problematik der eindeutigen Konfiguration der Adressen aller Knoten im VAXET mit sieh brin­gen, Weiterhin stellt sieh die Frage, inwiefern eine temporäre und zufällige MAC-Adresse das Datensehutzproblem tatsächlich umfassend löst. Dennoch würde eine zufällige MAC-Adresse das Problem zumindest abmildern. Da MAC-Adressen von den Hardwareherstellern reserviert und für ihre Produkte vergeben werden, besteht auch die Fragestellung, inwieweit es rechtlich durchführbar ist, MAC-Adressen zufällig zu vergeben.

Insgesamt zeigt sieh, dass für VAXETs im einfachsten Fall keine Elemente von TCP/IP mehr für VAXETs zum Einsatz kommen müssen, da diese für die veränderten Ausgangsbedingungen von VAXETs nicht mehr geeignet sind. Die Beschränkung auf MAC-Adressen zur Adressierung bietet eine Vereinfachung bei der Implementierung, Fragen des Datenschutzes durch dauerhaft und global eindeutige Adressierung von Xetzwerkknoten bieten Raum für weitere Forschung in diesem Gebiet.

3.7 Gleichberechtigung

Die Gleiehbehandlung aller Knoten spielt eine wichtige Rolle in VAXETs, In konventionellen Netzwerken tritt mangelnde Gleichberechtigung aufgrund der vorhandenen Infrastruktur kaum auf. In VAXETs hingegen muss jeder Knoten gleiehermafśen dafür Sorge tragen, dass einerseits eine gleiehmäfsige Auslastung der Ressourcen im Netzwerk stattfindet und andererseits auch jeder Knoten Zugriff auf Ressourcen erhält, Gleichberechtigung erstreckt sieh in MAXETs auf verschiedenen Ebenen, die teilweise bereits in anderen Teilen dieser Arbeit Erwähnung gefun­den haben. Beim Medienzngriff auf der Siehernngssehieht bezieht sieh die Gleiehbehandlung auf den gleiehmäfsigen Zugriff aller Knoten auf das Medium, ohne dass bestimmte Knoten dabei be­vorzugt werden. Spezielle Probleme beim Medienzngriff von IEEE 802.11 und Lösnngsansätze dazu wurden bereits in 2.4.2 behandelt, Leiden tiefere Schichten unter Ungleiehbereehtignng, wirkt sieh dies auch deutlich auf höhere Schichten ans |LXG03|, Beim Routing ist das Ziel der Gleichberechtigung, dass nicht einige Knoten zum Beispiel wegen ihrer günstigen Lage in der Topologie mit Xetzwerkverkehr überlastet werden. Auf der Transportsehieht kann etwa das TCP-Protokoll in der Slow-Start-Phase iibermafśig viel Bandbreite im Netzwerk für sieh bean­spruchen, da die Übertragnngsgesehwindigkeit ohne Rücksicht auf andere Xetzwerkteilnehmer exponentiell erhöht wird.

Da die Gleichberechtigung nahezu alle Schichten im Xetzwerkstapel betrifft, ist es sinnvoll, diese übergreifend zu betrachten. Der Grund für die Wichtigkeit der Gleichberechtigung aller Knoten liegt darin begründet, dass VAXETs so stark dezentral und kooperativ organisiert sind. Dies erfordert es, dass Knoten gleiehermafśen Zugriff auf Ressourcen erhalten bzw, mit Ver­waltungsaufgaben im Netzwerk betraut sind. Andernfalls wird es einigen Knoten nicht mehr möglich sein, in vollem Umfang zu operieren und dadurch sinkt die Funktionsfähigkeit für das gesamte Netzwerk, Deshalb kann es sein, dass ein Knoten eine individuell naehteilhafte Entscheidung treffen muss, um den globalen Nutzen zu erhöhen. Tritt Ungleiehbehandlung auf, dann kann dies nicht nur einzelne Knoten betreffen. Wird etwa ein Knoten durch den viele Rou­tenpfade verlaufen überlastet, leiden alle Nutzer dieser Routen unter mangelndem Durchsatz und geringer Konnektivität, Durch solche Konstellationen können auch Xetzwerkpartitionierun- gen auftreten, weil Verbindungsknoten zwischen zwei Partitionen überlastet werden, was sehr leicht passieren kann, wenn nur wenige solcher Verbindungsknoten existieren. Insofern ist die Überlastkontrolle, wie sie z, B, vom TCP-Protokoll durehgefiihrt wird, auch als Teil der Gleieh- bereehtigungsmeehanismen zu betrachten. Von besonders hoher Bedeutung ist die Erreichung der Gleiehbehandlung im VAXET auch für sieherheits- und echtzeitkritische Kommunikation.

Da die Gleichbehandlungseigenschaften des gesamten Xetzwerkstapels sehr stark von den konkreten Implementierungen auf den jeweiligen Schichten abhängen, gibt es kaum allgemeine

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.17: Beispiel zur Priorisierung von Paketübertragungen durch Nutzenbewertung

Ansätze zu deren Optimierung. Letztlich tragen auch die Applikationen Verantwortung dafür, dass keine Überbelastung bestimmter Knoten oder von Teilen des Netzwerks stattfindet. Für Routingalgorithmen sind Lastverteilungsmechanismen denkbar, die allerdings bewirken, dass von optimalen Routen abgewichen werden könnte[HS01]. Ein sinnvoller Ansatz, der auf viele Netzwerkschichten und Protokolle angewendet werden kann, wird in [WR05] vor geschlagen. Die Arbeit beschäftigt sich konkret mit Überlastkontrolle für VANETs. Dabei wird für jedes Paket, das von einer Anwendung übertragen werden soll, ein Nutzwert berechnet. Die Berechnung des Nutzwerts erfolgt über anwendungsspezifische Funktionen. Damit jeder Knoten im Netzwerk den Nutzen eines Pakets zu jeder Zeit berechnen kann, unabhängig davon ob auf dem Knoten eine Applikation aktiv ist, die den Nutzen berechnen kann, wird die Nutzenfunktion mit dem Paket zusammen in den Kopfdaten übertragen. Die Höhe des Nutzwerts eines Pakets wird als Priorität bei der Übertragung herangezogen. Pakete mit hoher Priorität werden zuerst über­tragen. Tritt ein Überlauf in der Paketwarteschlange auf, dann werden Pakete mit niedriger Priorität zuerst verworfen. Wenn also Überlast in einem Teil des Netzwerks herrscht, werden die nützlichen Pakete noch übertragen, während die weniger wichtigen Pakete verfallen. Dies ermöglicht eine gute Steuerung der Übertragungsvorgänge abhängig vom tatsächlichen Wert der Paketinhalte, Die Xutzenfunktionen sollten so gestaltet sein, dass sie den Nutzen für das gesamte Netzwerk berechnen. Bei der Übertragung einer Staumeldung kann man den Nutzen daran orientieren, wie aktuell die Meldung ist (z, B, ob die Information bereits bekannt ist) und für welche Empfänger im Netzwerk die Übertragung interessant ist. Auch wenn der Vor­schlag sieh vor allem auf die Applikationssehieht bezieht, kann man dasselbe Prinzip auch für Übertragungen anwenden, die auf tieferen Schichten ihren Ursprung haben bzw, der Nutzwert könnte auch auf ganze Verbindungen auf der Vermittlungs- und Transportsehieht angewendet werden.

Ein Beispiel für den möglichen Ablauf der durch Xutzenbewertung priorisierten Paketiiber- mittlung wird in Abbildung 3.17 gegeben. Die Knoten A bis D sind mit ihren Bewegungsvek­toren sowie deren Wartesehlagen für die Paketübertragung abgebildet. Angenommen, jeder der Knoten betreibt ein Xaehbarsehaftsprotokoll (siehe 3.2), das jede Sekunde ein Beaeon-Paket übermitteln möchte. Für die Beaeon-Übertragung wird eine Xutzenfunktion ausgewertet, die abhängig von der Veränderung der Knotenposition gegenüber der letzten Übertragung und eventuellen Abbriiehen von Direktverbindungen mit Nachbarn den Nutzen berechnet. Jeder Knoten hat eine Wartesehlange für bis zu fünf Pakete, Die Pakete werden in der Reihenfolge der Ankunft in der Wartesehlange abgelegt. Die Nutzwerte für die Pakete in der Wartesehlange liegen im Intervall [0.1], Die roten Einträge in der Wartesehlange sind jeweils die Beaeon-Pakete, die vom Xaehbarsehaftsprotokoll versendet wurden. Für Knoten D, der sieh derzeit nicht be­wegt, erhält das Beaeon-Paket einen Xutzenwert von 0, da für Nachbarn keine neue Informa­tion zur Verfügung steht. In der Wartesehlange würden demnach alle anderen Pakete vor dem Beaeon-Paket übertragen, da sie einen höheren Nutzwert haben. Würde ein weiteres Paket in die Wartesehlange gelegt, das einen höheren Nutzwert als 0 hat, dann würde das Beaeon-Paket verworfen werden, sofern die Wartesehlange nicht schnell genug geleert werden kann, Knoten D hat eine relativ geringe Bewegungsgesehwindigkeit und erhält deshalb für sein Beaeon-Paket den Nutzwert 0.2, Obwohl das Beaeon-Paket als erstes in die Wartesehlange aufgenommen wurde, werden die beiden anderen Pakete mit den Werten 0.6 und 0.4 zuerst versandt, Knoten B hat ei­ne höhere Bewegungsgesehwindigkeiti, für die ein Nutzwert von 0.5 berechnet wurde. Aufgrund der hohen Geschwindigkeit hat die Übertragung mehr Bedeutung für die umliegenden Nach­barn, In diesem Fall würde das Beaeon-Paket vor allen anderen übertragen, da es die höchste Priorität besitzt, Knoten A sehliefślieh hat zwar eine geringere Geschwindigkeit als Knoten B, doch hat dieser Knoten festgestellt, dass aufgrund seines Bewegungsvektors seine Verbindung zu Knoten D abzubreehen droht. Aus diesem Grund wurde die Priorität des Beaeon-Pakets auf 0.9 eingestuft, um den Nachbarn den Verlust dieser Verbindung mitzuteilen. Dieses Ereig­nis könnte nämlich unterbrochene Routen zur Folge haben oder für andere Applikationen von Bedeutung sein.

Eine erweiterte bzw, abgewandelte Form dieses Prinzips stellt es dar, virtuelle Geldeinheiten zu verwenden, um Gleichberechtigung herzustellen. Das heilst statt mit einer Xutzenfunktion wird mit einer Kostenfunktion bestimmt, welche Pakete übertragen werden und welche nicht. Jeder Knoten bekommt in regelmäfsigen Zeitabständen ein gewisses Guthaben, das ihn berech­tigt, Übertragungen durehzuführen. Andererseits erhalten Knoten auch Geldeinheiten wenn sie für anderen Knoten Dienste erfüllen, wie z, B, die Weiterleitung eines Pakets auf einer Rou­te, Ein solches Prinzip ist vielversprechend, da nicht nur eine reine Priorisierung wie bei der Berechnung des Nutzwerts durchgeführt wird, sondern auch der Verbrauch und die Bereitstel­lung von Ressourcen im Netzwerk konkret einfließen und so eine stärkere Gleichberechtigung ermöglichen, da einzelne Knoten nicht mehr Ressourcen verbrauchen können, als die virtuellen Geldeinheiten es ihnen erlauben.

Gleichberechtigung in VAXETs ist in jedem Fall von hoher Bedeutung und sie sollte bei der Entwicklung jeder Xetzwerkschicht und von Applikationen immer integraler Bestandteil sein. Nur so kann die dezentrale und kooperative Natur des Netzwerks erfolgreich unterstützt und genutzt werden.

3.8 Sicherheit

Diese Arbeit beschäftigt sieh vordergründig mit der Herstellung der grundlegenden Funktio­nalität eines VAXETs und vernachlässigt Sicherheitsaspekte, um die Komplexität der zahlrei­chen und vielfältigen Problemgebiete nicht noch weiter zu erhöhen. In diesem Abschnitt wird dennoch eine kurze Einführung in die Problemstellungen bei der Sicherheitsarchitektur von VAXETs gegeben, um eine Vorstellung dieses umfangreichen Themengebiets zu vermitteln VAXETs weisen eine Vielzahl von Eigenschaften auf, die Angriffsflächen für böswillige Teil­nehmer im Netzwerk darstellen und nicht mit den Sicherheitsbedingungen in konventionellen Netzwerken vergleichbar sind. Die fehlende Infrastruktur, und damit fehlende zentrale, vertrau­enswürdige Instanzen im Netzwerk, die notwendige Kooperation und Homogenität aller Knoten im VAXET sowie die ausschließliche Nutzung von Funkverbindungen stellen enorme Schwie­rigkeiten für die Entwicklung einer Sicherheitsarchitektur dar und sorgen dafür, dass die aus konventionellen Netzwerken bekannten Sicherheitsmechanismen nahezu vollständig unbrauch­bar werden. Mögliche Sicherheitslücken werden zunächst grob in aktive und passive eingeteilt, Aktive Lücken erfordern das aktive Handeln eines Angreifers, indem er sieh dem VAXET an- schlicßt und schädliches Verhalten umsetzt. Passive Lücken sind aufgrund des Funkmediums besonders schwierig zu unterbinden: Hierbei hört ein Angreifer lediglich den im VAXET ab­laufenden Datenverkehr ab, um Informationen für sieh zu gewinnen, Dureh das Abhören der Kommunikation können zum Beispiel leicht Bewegungsprofile bestimmter Knoten erstellt wer­den, Bei Nutzung von Audio- oder Videoübertragungen können diese Informationen ebenfalls ausgewertet werden. Je nach konkreter Anwendung gestaltet sieh die Gefahr unterschiedlich grofś.

Zu den aktiven Attacken gehört die Manipulation von Routingprotokollen, Routen kön­nen fehlgeleitet oder in Schleifen geführt geführt werden, Pakete zur Weiterleitung — sowohl Routing- als auch Rundfunkpakete — können grundsätzlich oder zufällig verworfen werden. Der Routingalgorithmus kann auch ausgenutzt werden, um einen kompromitierten Knoten als optimalen Weiterleitungsknoten darzustellen und so Verkehrsströme umzuleiten. Dies kann zur Folge haben, dass der kompromitierte Knoten überlastet wird oder das der Verkehr auf einen anderen Knoten umgeleitet wird, um diesen zu überlasten. Auch kann so der Verkehr vieler Knoten abgehört werden. Ein Beispiel dazu findet sieh in Abbildung 3.18 (a): Knoten A flutet eine Routenermittlungsanfrage für Knoten B, die der bösartige Knoten F unmittelbar positiv beantwortet, während die eigentliche Antwort von Knoten B zu einem späterem Zeitpunkt von Knoten A verworfen wird, Knoten F kann in dieser Konstellation nun entweder den Routingver­kehr verwerfen, verändern und an Knoten B weiterleiten oder an einen anderen Knoten senden, um diesen zu überlasten. Um das gesamte VAXET zu verwirren kann ein Angreifer einem Kno­ten mehrere Identitäten geben, die nach aufśen kommuniziert werden. So werden verschieden­ste Mechanismen im VAXET unbrauchbar gemacht, Xaehbarsehaftsprotokolle sind auch dureh Angreifer ausnutzbar, indem falsche Xaehbarsehaftsnaehriehten verbreitet werden. Indem die Übertragungsstärke erhöht wird, können davon eine Vielzahl von Knoten betroffen sein. Dies ist in Abbildung 3.18 (b) dargestellt, Knoten F sendet dort mit wesentlich höherer Übertragungs­stärke eine Xaehbarsehaftsnaehrieht, Die herkömmliche Übertragungsreiehweite ist wesentlich geringer (grüne Fläche), Alle Knoten, die die Xaehbarsehaftspakete von F empfangen, gehen davon aus, dass dieser ein direkter Xaehbar ist und versuchen Daten an ihn zu senden, obwohl er nicht erreicht werden kann bzw, sieh bösartig verhalten wird. Subtileres, aber ebenso wir­kungsvolles Sehadverhalten kann sein, dass ein Knoten nicht mit dem VAXET kooperiert aber die Dienste des VAXETs in Anspruch nimmt. Dies führt zu erheblicher Ungleiehbehandlung (siehe 3.7), Auf der Applikationsebene können des weiteren etwa falsche Verkehrsmeldungen verbreitet oder Gefahrensituationen vorgespiegelt werden.

VAXETs haben also umfassende Angriffsflächen, welche das gesamte Netzwerk oder einzelne Knoten im Netzwerk zum Erliegen bringen sowie die Vertrauenswürdigkeit von Informationen im Netzwerk kompromittieren können, bis hin zur Beeinflussung des Fahrverhaltens von Ver­kehrsteilnehmern, Aufśerdem herrscht mangelnder Datenschutz, da Informationen von jedem Mithörer gelesen und ausgewertet werden können. In [SchwingenschlögKM] wird festgesteht, dass jeder Lösungsansätz die beiden folgenden Aspekte berücksichtigen muss: Werden die si­cherheitsbezogenen Funktionen auf einen oder wenige Knoten im Netzwerk konzentriert, genügt ein Überlastungsangriff auf diese(n) Knoten, um die Sicherheit des Netzwerks auszuschalten und damit entweder ein unsicheres oder ein inoperables Netzwerk zu erreichen. Weiterhin muss da­von ausgegangen werden, dass immer einige der Knoten im Netzwerk kompromittiert sind. Die teilnehmenden Knoten in MANETs und VANETs unterliegen überlicherweise keiner Kontrol­le. Fahrzeuge können nahezu beliebig modifiziert werden. Sicherheitsansätze, die sich auf die Gutartigkeit aller Knoten im Netzwerk verlassen, sind also ebenfalls ungeeignet. Stattdessen ist eine übliche Annahme, dass zwar nicht alle, aber die Mehrheit der Knoten im VANET gutartig ist und auf dieser Basis Sicherheitsmaßnahmen umgesetzt werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.18: Angriffsmöglichkeiteil auf Routing- und Nachbarschaftsprotokolle

Die beiden grundsätzlichen Sicherungsmechanismen für VANETs sind wie in jedem Netzwerk einerseits die Signierung von Nachrichten, so dass die Herkunft und Richtigkeit des Inhalts ve­rifiziert werden kann. Andererseits bedarf es der Verschlüsselung des Datenverkehrs, um ein un­befugtes Abhören von Daten zu verhindern. Da sich diese Funktionen nicht auf einzelne Knoten beschränken dürfen, ist die Anwendung von verteilten, dezentralen Algorithmen notwendig. Er­schwerend hinzu kommt die notwendige Selbstkonfignration der Knoten bei der Anwendung der Sieherheitsmeehanismen, So stellt sieh zum Beispiel oft die Frage, wie die Vertrauenswürdigkeit unbekannter, anonymer Kommnnikationspartner eingestuft wird.

|Sehwingensehlögl04| stellt hierfür das Konzept verteder Geheimnisse und Funktionen vor. Statt das ein einzelner Knoten einen geheimen Schlüssel berechnet, wird die Funktion zur Erzeugung des Schlüssels in t Teile aufgespalten. Jedes dieser t Teile gehört zu einem von t Knoten im Netzwerk. Ein neuer Schlüssel wird erzeugt, indem diese t Knoten t Schlüsselteile erzeugen und diese Schlüsselteile in einem Knoten zusammengeführt werden. Dieser Kombiniert diese Schlüsselteile und erhält den Gesamtschlüssel. Nach dem selben Prinzip kann man zur Erzeugung von Signaturen Vorgehen, Durch solche verteilten Mechanismen hat kein einzelner Knoten die Fähigkeit, Schlüssel zu fälschen und der gesamte Schlüssel ist erst bei dem Nutzer des Schlüssels vorhanden. Um nun einen falschen Schlüssel zu erzeugen, müsste ein Angreifer alle t Knoten kompromittieren, was eine deutliche Erschwernis darstellt.

Entsprechende kryptographische Verfahren sind auch für Mehrpunktverbindungen (siehe 3.4) notwendig. Es soll vielleicht nicht möglich sein, dass beliebige Netzwerkknoten sieh einer Grup­pe für Mehrpunktkommunikation ansehliefśen können, ohne sieh vorher zu authentifizieren, Soll Mehrpunktkommunikation verschlüsselt werden, muss ein Gruppenschlüssel zu Einsatz kom­men, so das jedes Mitglied der Gruppe Kommunikation vor- und entschlüsseln kann, Eigenschaf­ten von VANETs können aber auch positiv eingesetzt werden, um die Sicherheit zu erhöhen. Die Existenz von disjunkten Multipfaden auf Ende-zu-Ende-Verbindungen (siehe 3.1.6) könnte etwa genutzt werden, um über einen Pfad die verschlüsselten Daten und über einen anderen Pfad den geheimen Schlüssel zu übertragen (Abbildung 3.19 (a)). Auf diese Weise würden die verschlüsselten Daten und der zugehörige Schlüssel nur beim Sender- und Empfängerknoten gleichzeitig existieren. Natürlich müsste für ein solches Verfahren auch sichergestellt sein, dass die Zwischenknoten eines Pfades sieh nicht innerhalb der Funkreichweite von Zwischenkno­ten des anderen Pfades befinden. Dieses Problem könnte wiederum mit intelligenten Antennen und gerichteten Funkübertragungen gelöst werden. Eine Möglichkeit, um zu verhindern, dass bösartige Knoten im Netzwerk unbemerkt Inhalte von Paketen abändern stellt es dar, dass der Senderknoten das Paket mit einem einmaligen, temporären Schlüssel verschlüsselt, das Pa­ket übermittelt, und erst nach Ankunft des Pakets beim Empfänger der zugehörige Schlüssel ebenfalls zum Empfänger übermittelt wird (Abbildung 3.19 (b)). Auf diese Weise hätte kein Zwischenknoten die Möglichkeit den Inhalt des Pakets zu verändern, ohne dass dem Empfän­gerknoten die mangelnde Integrität der Daten auffällt. An diesem Beispiel zeigt sieh, dass sieh in VANETs gänzlich neue Verfahren zur Schaffung von Sicherheit anbieten.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.19: Räumlich (a) und zeitlich (b) getrennte Übermittlung der kodierten Nachricht c und des geheimen Schlüssels x, um die Nachricht m sicher bzw. unverfälscht zu übermitteln

In [ZL04] wird stärker auf die vorbeugende Analyse des Netzwerks Wert gelegt, um auch potentiell neue Angriffe vorzeitig erkennen und Gegenmaßnahmen einleiten zu können. Der Ge­danke an unbedachte Angriffsformen ist ernst zu nehmen, wenn man bedenkt, wie vielfältig die Sicherheitslücken im Protokollstapel und auf Anwendungsebene im Internet sind. Ein öffentli­ches VANET stellt eine neue Netzwerkform dar, mit der noch kaum Erfahrung im Praxiseinsatz besteht. Vorbeugende Sicherheitstechniken machen für VANETs also durchaus Sinn. [ZL04] schlägt dazu ein Einbruchserkennungssystem vor, das auf verschiedene Ebenen den Netzwerk­verkehr auf Auffälligkeiten untersucht. Dieses soll durch Lernalgorithmen unterstützt werden. Diese können mit korrektem Netzwerkverkehr gespeist werden, woraus schließlich Datenmuster extrahiert werden. Im realen Einsatz werden diese Datenmuster dann mit dem Netzwerkverkehr verglichen. Weiterhin werden zu überwachende Kriterien festgelegt, so z. B. bestimmte Para­meter und Werte die von Routingalgorithmen verwendet werden. Auffälligkeiten werden nach weiteren Indizien untersucht und wenn sich der Grund zur Annahme bildet, dass das Netzwerk bzw. der Knoten angegriffen wird oder kompromittiert ist, werden Gegenmaßnahmen eingelei- tot. Dazu gehören Aktionen wie der Sehliisseltauseh für Signatur und Versehliisselung oder eine sonstige Rekonfiguration des Netzwerks, Können konkrete Knoten als verdäehtig identifiziert werden, kann aueh ein Aussehlufś dieser Knoten aus dem Netzwerk erfolgen. Solche Einbruchser­kennungssysteme können aueh mit verteilten Mechanismen erweitert werden, so dass Anzeichen für Sicherheitsbedenken zwischen den Knoten ausgetauscht werden und somit eine gemeinsame Entscheidung darüber gefällt wird, ob eine Gefahr besteht und Aktionen ausgeführt werden.

Viele der offensichtlichen Angriffsgefahren lassen sieh bereits auf logischer Ebene ausschlie- fśen, Verhält sieh ein Knoten unkooperativ oder versendet er ersichtlich ungültige Nachrichten, können die Nachbarknoten dieses Fehlverhalten protokollieren und einen Auffälligkeitswert für den betroffenen Knoten festlegen. Überschreitet dieser Wert eine gewisse Schranke, wird ein bösartiges Verhalten angenommen. Diese Informationen können wiederum mit anderen Nach­barn ausgetauscht werden und sieh damit gegenseitig verstärken. So können kompromittierte und unkooperative Knoten auf kooperative Art vom Netzwerk ausgeschlossen werden, indem ihnen keine Ressourcen des Netzwerks mehr zugesprochen und ihre Nachrichten nicht mehr verarbeitet werden.

Nicht zu vergessen ist aueh die Verantwortung der Applikationen in VANETs für die Gewähr­leistung der Sicherheit, Gerade die Bestrebungen zu gröfstmöglieher Kompatibilität zu beste­henden Netzen wie dem Internet könnte dazu verleiten, bestehende Softwareteile ungeprüft für VANETs zu übernehmen. Nachdem schon in konventionellen Netzwerken die Netzwerkapplika­tionen einen der häuftigsten Gründe für Sicherheitslücken darstellen, und VANETs aueh noch vollkommen veränderte Betriebsbedingungen mit sieh bringen, sollten aueh die Applikationen sieh an die veränderte Ausgangslage anpassen und entsprechende Sieherungsmafśnahmen für ihre individuellen Dienste und ihren Datenverkehr einführen. Hier ist aueh eine höhere Inter­aktion und damit Kooperation zwischen den verschiedenen Netzwerkschichten denkbar. Die Rückkopplung von tieferen Schichten des Protokollstapels mit Informationen über Auffällig­keiten im Netzwerk oder einzelner Knoten könnte hier schließlich aueh den Schluss für die Applikation bedeuten, dass sie ihr Verhalten ebenfalls adaptiert und andersherum. Denn es ist gerade dann, wenn tiefere Schichten entscheiden, dass ein Knoten ausgeschlossen wird sinnvoll, dieses Vorgehen der Anwendungsschicht transparent mitzuteilen. Sollte die Applikation ihrer­seits vertrauliche Daten verarbeitet haben, könnte es für sie aueh notwendig sein, ihre Integrität zu prüfen und Sieherungsmafśnahmen zu erneuern oder ggf, den Benutzer zu informieren. Nicht zuletzt kann eine stärkere Interaktion der Anwendungsschicht mit den niedrigeren Schichten aueh deshalb sinnvoll sein, weil Anwendungen unterschiedliche Anforderungen an Datenschutz und Vertrauenswürdigkeit haben. Nachdem Sicherheitsmechanismen aueh die Leistungsfähig­keit eines VANETs (sowie die Rechenkapazität der Knoten) negativ beeinflussen können, kann es schließlich sinnvoll sein, nur selektiv Verschlüsselung und Signierung einzusetzen, wie dies auch in konventionellen Netzwerken der Fall ist.

Aufgrund der naturgegebenen Anfälligkeit von VAXETs für Angriffe, und da die Proto­kollschichten ohnehin weitgehend neu konzeptioniert und implementiert werden müssen, sollte schon von Anfang an der Sicherheitsgedanke in die Architektur von VAXETs einfließen und deren integraler Bestandteil werden. Anders als in konventionellen Netzwerken, wo aus Komp- tabilitätsgriinden oft Altlasten mitgeführt werden müssen, besteht hier die Möglichkeit, ein in­einander greifendes Konzept von Sicherheitsmaßnahmen auf jeder Schicht des Protokollstapels einzuführen. Dabei bleibt noch die Frage offen, ob es sinnvoller ist, schon in der Forschungsphase grundsätzlich Sicherheitsmaßnahmen einzuführen oder erst überhaupt für VAXETs geeignete Protokolle zu entwickeln und diese nachträglich um eine Sicherheitsarchitektur zu erweitern. Diese Arbeit geht letzteren Weg indem die reine Xetzwerkfunktionalität von der Sicherheit isoliert betrachtet wird, Angesichts der bereits so gegebenen Komplexität und des Umfangs des Themengebiets gibt es Sinn diese Komplexität an Stellen wie dieser einzuschränken, ins­besondere, da die Entwicklung von Sicherheitsmechanismen vergeudete Arbeit ist, wenn sieh herausstellt, dass die eigentlichen Xetzwerkprotokolle gar nicht für VAXETs geeignet sind.

Dieses Kapitel gab nur einen allgemeinen Überblick über Sicherheitsfragen in VAXETs, Zahl­reiche Arbeiten zum Thema existieren, um sieh näher mit diesem großen Feld zu beschäftigen. Die Absicherung der VAXET-Operationalität gegen Angriffe auf allen Ebenen ist eines der zentralen Elemente, um VAXETs wirtschaftlich erfolgreich umzusetzen. Ein VAXET-Svstem, das jederzeit gestört und mißbraucht werden kann, lässt sieh nicht durchsetzen. Dies gilt umso mehr, wenn sicherheitskritische Fahrerassistenzanwendungen zum Einsatz kommen und An­greifer damit Einfluss auf das Fahrverhalten von Fahrzeugen nehmen können. Auch für reine Informationsverbreitungsanwendungen ist dies bereits ein nicht hinnehmbarer Zustand, Durch gefälschte Warnnachrichten könnte der Verkehrsfluss fehlgeleitet werden, was auch volkswirt­schaftlichen Schaden verursachen kann.

Schließlich muss aber auch gesehen werden, dass alle Sicherheitsmaßnahmen ihre Grenzen ha­ben, Diese Grenzen werden bei VAXETs vor allem durch das Funkmedium gezogen. Während in kabelgebundenen Netzwerken der physische Zugang zum Medium eine deutliche Barriere darstellt, kann ein Funkkanal auch über große Entfernungen hinweg zugegriffen werden. Gegen eine physische Störung des Funkkanals wird sieh kaum eine Lösung finden lassen. Schon allein das unkoordinierte Zugreifen auf das Medium kann dafür sorgen, dass Xachbarknoten nicht mehr kommunizieren können, Angriffe, die also auf die Störung der Kommunikation hinauslau­fen, lassen sieh nur schwierig verhindern. Daher wird sieh die Sicherheitsarchitektur vor allem auf Datenschutz, Vertrauenswürdigkeit und Kooperation beschränken müssen.

3.9 Energiesparen

In MAXETs und SAXETs ist die Energiekapazität der Knoten eine kritisehe Grofśe, weil es sieh um autonome, vom Stromnetz getrennte Einheiten handelt, bei denen nur sporadiseh oder gar nicht die Möglichkeit besteht, ihre Energiereserven aufzufüllen. Da das Funkmodul, das zur Kommunikation verwendet wird, im Vergleich zu anderen Komponenten des Systems besonders viel Energie verbraucht, ist es ein wichtiges Anliegen, den Stromverbrauch durch Kommuni­kation so gering wie möglich zu halten. In VAXETs ist dies im allgemeinen kein Hindernis, weil Fahrzeuge während des Betriebs genügend Strom produzieren, um das VAXET-System zu versorgen. Dennoch können sieh Konstellationen ergeben, in denen die verfügbare Energie be­schränkt ist. Ein Gedanke wäre, dass auch parkende, inaktive Fahrzeuge weiterhin am VAXET teilnehmen, um die Stabilität und Konnektivität des Xetzes zu erhöhen. Dies könnte in Stadtge­bieten von Vorteil sein, vor allem in Regionen, in denen wenig Verkehr herrscht (Seitenstrafśen) oder Zeiträumen die eine geringe Verkehrsdichte aufweisen (z, B, Xaehts, Feiertags), Aber auch wenn von solchen Mechanismen nicht Gebrauch gemacht wird, können Energiebesehränkungen eine Rolle spielen. Ein voll ausgebautes VAXET kann nämlich auch für nicht motorisierte Teil­nehmer wie Fahrradfahrer oder für Fufsgänger interessant sein. Da dies auch Verkehrsteilnehmer sind, betreffen sie genauso die Verkehrssicherheit wie Automobile und sind relevante Objekte für die Fahrerassistenz, Bietet ein VAXET noch zusätzliche Infrastruktur wie Internetschnitt­stellen, so wird das Xetzwerk auch für nicht Verkehrsteilnehmer attraktiv, da die Möglichkeit des Internetzugangs für mobile Geräte wie Xotebooks oder PDAs besteht. In allen diesen Fällen bestehen nur beschränkte Energieressourcen. Deshalb wird in diesem Abschnitt ein Überblick über Möglichkeiten des Energiesparens in VAXETs gegeben.

Da sieh die meisten Arbeiten zu Energiespartechniken mit MAXETs und SAXETs beschäf­tigen, in denen alle Knoten gleiehermafśen von der Energiebeschränkung betroffen sind, wird auch im Folgenden davon ausgegangen, dass ein VAXET mit homogenen, energiebeschränk­ten Knoten vorliegt. Hier stellt sieh zunächst die Frage, wie die Lebensdauer des Xetzwerks definiert wird. In SAXETs, die wenig mobil sind, kann die Lebensdauer des Xetzes dadurch definiert werden, wie lange eine wichtige Route im Xetzwerk existiert. Auch die Zeit bis der erste Knoten in Xetzwerk wegen Energiemangel ausfällt kann als Lebensdauer herangezogen werden. In VAXETs sind die meisten Teilnehmer mobil und der Verlust einer Route ist nicht so bedeutungsvoll, Stattdessen ist es von Bedeutung, dass alle Knoten möglichst lange am Xetzwerk teilnehmen können, da sie sonst ihre Informationen und Ressourcen nicht mehr dem Xetzwerk zu Verfügung stellen können und Applikationen wie Fahrerassistenz nicht mehr in vollem Umfang stattfinden können.

Energieverbrauch durch Funkkommunikation variiert zwischen verschiedenen Betriebsmodi. Den größten Verbrauch zeigt das Funkmodul beim Senden von Nachrichten. Auch das Empfan­gen und Abhören des Funkkanals benötigt Energie. Das Funkmodul kann meist auch in einen Schlafmodus versetzt werden, in dem es weder Daten senden noch empfangen kann und daher deutlich weniger Strom benötigt.

Das größte Einsparpotential besteht darin, so wenige Nachrichten wie möglich zu versen­den. Dies bedeutet, dass insbesondere Mehraufwand etwa von Routingalgorithmen sieh nicht nur auf die Leistungsfähigkeit des Netzwerks sondern auch auf dessen Lebensdauer negativ auswirkt. Neben dieser logischen Ebene gibt es auf der Übertragungsebene, d.h. auf der Siche­rungsschicht, Möglichkeiten Energie einzusparen. In |KS04| werden zwei grundlegende Tech­niken dazu vorgestellt. Dabei handelt es sieh um die Steuerung der Übertragungsstärke sowie um Verbrauchsregelung durch Nutzung des Schlafmodus der Funkhardware. Bei ersterem geht es darum, die Übertragungsstärke beim Senden von Nachrichten zu regulieren, um unnötigen Stromverbrauch zu eliminieren. Bei letzterem ist die Idee das Funkmodul nur dann aktiv zu schalten, wenn tatsächlich Übertragungen auf dem Medium stattfinden sollen.

3.9.1 Stromsparender Medienzugriff

Steuerung der Übertragungsstärke

Die Steuerung der Übertragungsstärke nutzt die Möglichkeit, die Übertragungsleistung abhän­gig vom Kommunikationsvorgang dynamisch zu regeln. Dies beeinflusst die Funkreichweite, die realisiert werden kann. Die Funkhardware muss diese Technik unterstützen (siehe auch Abschnitt 2.4.4 über intelligente Antennen). Da nicht immer die maximale Kommunikations­reichweite ausgenutzt werden muss, um den Zielknoten zu erreichen, lässt sieh durch diese Technik Energieverbrauch verringern, indem nur so stark übertragen wird, dass der Empfän­ger die Übertragung gerade noch korrekt empfangen kann. Es besteht auch die Möglichkeit, statt einer oder weniger stromintensiven Übertragungen über große Strecken und wenige Hops, mehrere Übertragungen über kurze Strecken und mehr Hops durchzuführen, die weniger Strom benötigen.

Mit Hilfe dieser Technik kann nun sogenannte Topologiesteuerung durchgeführt werden. Da die Übertragungsstärke und damit die Kommunikationsreichweite jedes Knoten individuell ge­regelt werden kann, wird die Netzwerktopologie nicht mehr nur durch Mobilität verändert, sondern auch durch die Wahl der Übertragungsstärke. Das Ziel von Stromsparalgorithmen ist es nun, eine Topologie zu finden, die den Energieverbrauch jedes Knoten minimiert, während die Ausfallsicherheit des Netzes aber erhalten bleiben soll. Dazu gibt es zwei unterschiedliche Ansätze: Die Nutzung derselben Übertragungsstärken und damit Kommunikationsreichweiten für alle Knoten oder heterogene Übertragnngsstärken, die für jeden Knoten individuell gewählt werden.

Da Wiederholungen von fehlerhaften Übertragungen ebenfalls negativ zum Stromverbraneh beitragen, ist es sinnvoll, bei der Wahl einer homogenen Übertragnngsstärke kleine Xaehbar- sehaftszellen entstehen zu lassen, Teilen nur wenige Xaehbarn das Medium, ist die räumliehe Wiederverwendung höher und die Kollisionsgefahr geringer (vgl, 2.4.4), Eine geringere Anzahl von Kollisionen bedeutet dann aueh einen geringeren Stromverbraueh.

Der COMPOW Algorithmus |XKSK02|, |KS04| versucht eine Topologie mit homogener Über­tragungsstärke zu finden indem zunächst mit maximaler Übertragungsstärke geprüft wird, wel­che Xaehbarknoten jeder individuelle Knoten im besten Fall erreichen kann. Dann beginnt er mit geringster Übertragungsstärke zu prüfen, welche Knoten noch erreichbar sind. Da eine ge­meinsame Übertragungsstärke gefunden werden muss, müssen die Knoten untereinander Infor­mationen darüber austausehen, ob die gewählte Übertragungsstärke für alle Knoten ausreichend ist. Die Übertragungsstärke wird nun so lange erhöht bis jeder Knoten all die Knoten erreichen kann, die er aueh mit maximaler Übertragungsstärke erreichen konnte. So wird die Topolo­gie der maximalen Übertragungsstärke bei geringerem Stromverbraueh erhalten. In Abbildung 3.20 ist ein Beispiel zu COMPOW gegeben. Bei maximaler Übertragungsstärke (4) erreicht der Knoten A die Knoten B und C, Xun beginnt Knoten A von der geringsten Übertragungsstär­ke (1) an zu prüfen, welche Knoten er noch erreichen kann. Die optimale Übertragungsstärke (3) erlaubt dem Knoten A ebenfalls die Knoten B und C zu erreichen, spart jedoch Energie ein. Denselben Prozess führen aueh die Knoten B, C und D aus. Das Maximum der ermittel­ten Übertragungsstärke aller Knoten wird sehliefślieh als neue gemeinsame Übertragungsstärke gewählt, COMPOW berücksichtigt jedoch keinen Pufferbereieh, der die Unterbrechung von Verbindungen bei veränderten physikalischen Gegebenheiten oder Mobilität abmildert.

Der Xaehteil von homogenen Übertragungsstärken ist, dass der am ungünstigsten in der To­pologie gelegene Knoten die Übertragungsstärke für alle anderen Knoten dominiert und somit die Effizienz des Gesamtnetzwerks geringer ist, als wenn jeder Knoten eine lokale Optimierung vornimmt. Ein Algorithmus zur Topologiesteuerung mit heterogenen Übertragungsstärken ist Cone-Based Topology Control (CBTC) |BW01|, |KS04|, CBTC teilt den Umkreis jedes Knoten in Keulen von jeweils α Grad ein. Beginnend mit der geringsten Übertragungsstärke wird diese für jeden Bereich stufenweise erhöht, bis mindestens ein Knoten in diesem Bereich erreicht wird (oder festgestellt wird, dass in dem Bereich keine Xaehbarknoten erreicht werden können). Die tatsächliche Übertragungsstärke des Knoten wird nun so gewählt, dass in jedem Bereich min­destens ein Knoten erreicht werden kann (sofern überhaupt ein Knoten erreicht werden kann). Ist dieser Algorithmus für jeden Knoten ausgeführt, berechnet CBTC noch Alternativrouten

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.20: Ermittlung der optimalen Übertragungsstärke durch COMPOW

zu Nachbar knoten. Ist es für bestimmte Nachbarknoten günstiger, über einen anderen Knoten zu routen statt direkt mit ihm zu kommunizieren, wird die direkte Kommunikationsverbin­dung entfernt bzw. ignoriert. Dies verbessert den Medienzugriff weiter, da bestimmte räumliche Areale von weniger Knoten in Anspruch genommen werden.

Die aus dem Algorithmus resultierenden unterschiedlichen Kommunikationsreichweiten sor­gen jedoch für erschwerte Kollisionsvermeidung, da sich Probleme mit versteckten Knoten ver­schärfen. Die Erhöhung der räumlichen Wiederverwendung des Mediums sollte jedoch mehr positiven als negativen Einfluss auf den Durchsatz im Netzwerk haben (siehe 2.4.4).

Nutzung eines Stromsparmodus

IEEE 802.11 WLAN definiert einen Stromsparmodus, den die Funkhardware umsetzen muss. In diesem Modus ist der Stromverbrauch der Hardware auf ein Minimum reduziert, aber es können auch keine Pakete mehr empfangen oder gesendet werden. Die Umsetzung dieses Modus ist vor allem für den Einsatz im Infrastrukturmodus unter Kontrolle einer Basisstation vorgesehen. In diesem Fall sind Zeiträume beim Medienzugriff definiert, in denen die schlafenden Knoten im Netzwerk sich aktivieren und von der Basisstation mitgeteilt bekommen, ob ein Kommunikati- onswunseh besteht. Besteht dieser Wunseh, dann bleibt die Hardware aktiv. Andernfalls kann der Sehlafmodns wieder aktiviert werden.

Fiir VAXETs müssen mangels Infrastruktur jedoch dezentrale Mechanismen gefunden wer­den, um den Medienzugriff bei Existenz von schlafenden Knoten zu regeln. Eine Methode, die dies ermöglicht, ist das periodische Aufwachen von Knoten, um zu überprüfen, ob Kommuni­kationsanfragen vorliegen. Dieser Ansatz lässt sieh gemäfš |KS04| in synchrone und asynchro­ne Lösungen aufteilen. Synchrones, periodisches Aufwachen erfordert, dass alle Knoten eine gemeinsame Zeit besitzen, um zum gleichen Zeitpunkt aufwaehen und miteinander Verwal­tungsdaten austausehen zu können. Der asynchrone Ansatz hingegen sieht nur vor, dass jeder Knoten regelmäfsig aber unabhängig von anderen Knoten, aktiv ist, um Verwaltungsdaten zu empfangen.

Im synchronen Fall lässt sieh ein Zeitraum festlegen zu dem alle Knoten aktiv sind, Kommuni­kationsanforderungen werden ausgetauseht und die Knoten, die an Kommunikation teilnehmen bleiben aktiv, während die anderen wieder in den Stromsparmodus zuriiekkehren. Eine synchro­nisierte Uhrzeit ist jedoch ggf, nur schwierig herzustellen. Deshalb sind asynchrone Techniken hier flexibler. Asynchrone Verfahren sind so gestaltet, dass jeder Knoten in regelmäfsigen Inter­vallen aktiv ist. Hat ein Knoten einen Kommunikationswunseh, so muss sein Aktivitätsintervall mit dem des Zielknoten zusammenfallen (Abbildung 3.21), Da bei konstant gewähltem Aktivi­tätsintervall auf diese Weise bestimmte Knoten niemals miteinander kommunizieren könnten, wird der Beginn des Aktivitätszeitraums immer wieder zufällig oder in jedem Durchlauf um einen bestimmten Wert verschoben gewählt, so dass alle Knoten irgendwann miteinander eine Verbindung aufbauen können. Bei diesem Ansatz muss der Aktivitätszeitraum jedoch höher gewählt werden als im synchronen Verfahren, damit die Wahrscheinlichkeit höher wird, dass Knoten zur gleichen Zeit aktiv sind. Dies verringert den Stromspareffekt.

Alternativ besteht die Möglichkeit der ereignisbasierten Aktivierung von schlafenden Kno­ten, Dazu ist ein zweiter Kommunikationskanal mit geringer Bandbreite und geringem Strom­verbrauch notwendig, über den Steuerverkehr ausgetauseht wird. Besteht ein Kommunikations­wunseh, wird der Hauptkanal aktiviert. Obwohl dieser Ansatz sehr vielversprechend ist, besteht das Problem, dass ein zweites Funkmodul Mehrkosten verursacht und darüber hinaus andere Funkeigensehaften aufweisen wird. Ist etwa die Reichweite geringer als die des Hauptkanals, können nicht alle potentiellen Kommunikationspartner eine Steuernaehrieht übermitteln.

3.9.2 Energiesparendes Routing

Auch das Routingprotokoll sollte energiebewusst arbeiten, um das gesamte Netzwerk zu scho­nen, Routen werden normalerweise hinsichtlich Stabilität, Latenz oder Bandbreite gewählt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.21: Koordination der Kommunikation bei Nutzung eines asynchronen Stromspar­modus. Beispiel angelehnt an [KS04].

Mit Blick auf die Energie sollten jedoch Routen gewählt werden, die besonders günstig für die Energiereserven der beteiligten Knoten sind. In [KS04] werden zwei Ansätze dazu vorgestellt. Der erste Ansatz wählt Routen aus, die die geringste Energie verbrauchen. Dies hat jedoch den Nachteil, dass Knoten, die Bestandteil vieler solcher günstiger Routen sind, stärker bela­stet werden und damit schneller ausfallen. Deshalb sieht der zweite Ansatz vor, dass auch die verbleibende Stromkapazität jedes Knoten beim Routing berücksichtigt wird. Dadurch wird die Energieversorgung der Knoten im Netzwerk gleichmäßiger aufgebraucht und die Lebens­dauer des gesamten Netzes erhöht. Jedoch kann es dadurch passieren, dass Routen gewählt werden müssen, die mehr Energie benötigen als die optimale Route. Daher gibt es auch hybride Ansätze, die Routen mit minimalen Stromverbrauch wählen so lange die Stromkapazität der beteiligten Knoten nicht einen Schwellwert unterschritten hat. Ist dieser Wert unterschritten, wird auf das alternative Verfahren zurückgegriffen, um die verbleibenden Energiereserven der betroffenen Knoten zu schonen.

3.9.3 Schlussfolgerungen

Dieser Abschnitt stellt nur eine Einführung in Stromspartechniken dar. Doch schon diese Ein­führung zeigt, dass Energiesparmaßnahmen in VANETs viel neue Komplexität schaffen. Ob die Aufnahme von energiebeschränkten Knoten in das Netzwerk diesen Aufwand rechtfertigt­bleibt abzuwägen. Andererseits gibt es auch Aspekte des Stromsparens, die mit den funktionalen Zielen des VANETs harmonieren. Die Minimierung des Datenverkehrs ist sowohl für den Strom­verbrauch als auch für die Optimierung der Netzwerkleistung sinnvoll. Dies ist der Fall, weil damit der Medienzugriff einfaeher und Latenzen für wichtige Nachrichten kürzer werden. In die­sem Zusammenhang kann auch die Reduktion der Übertragungsstärke in bestimmten Szenarien von VAXETs eine wertvolle Maßnahme sein, um den Medienzugriff und den Stromverbrauch gleichermaßen zu optimieren. Dies gilt vor allem für Fälle in denen eine hohe Xetzwerkdichte herrscht.

Die Stromverbrauehsminimierung durch Topologiesteuerung jedoch zieht kaum Mobilität in Betracht, Hier droht die Gefahr, dass die Dynamik des VAXETs so viel Verwaltungsverkehr notwendig macht, dass die positiven Effekte neutralisiert werden und der Energieverbrauch so­gar noch erhöht wird. Die Technik, die das größte Einsparpotential bietet, nämlich das Nutzen des Stromsparmodus der Funkhardware, bringt leider auch die größten Probleme mit sieh. Ins­besondere für Routingalgorithmen und Transportprotokolle kann die Sieht auf die Topologie durch nicht erreichte, schlafende Knoten falsch interpretiert werden, Xachbarschaftsprotokolle, die regelmäßig Daten übertragen, würden ebenso unter der nicht mehr garantierten Erreich­barkeit von Xachbarknoten leiden. Dies trifft vor allem für sicherheitskritische Anwendungen zu, bei denen Verzögerungen oder Fehlinterpretationen dieser Art nicht tolerierbar sind. Die Effizienz des Gesamtnetzwerks würde zu sehr leiden, während die Komplexität der Netzwerk­Steuerung weiter steigt. Ein genereller Einsatz von Stromspartechniken für VAXETs kommt also eher nicht in Frage, Für eingeschränkte Funktionalität können Knoten wie parkende Fahrzeuge vorgesehen werden, die nur passiv am Netzwerk teilnehmen, um zum Beispiel die Informations­verbreitung zu verbessern, jedoch nicht, um an bandbreitenintensiven oder echtzeitkritischen Applikationen teilzunehmen.

Da ein Mischbetrieb von in der Energiekapazität beschränkten und unbeschränkten Knoten im VAXET herrscht, ergeben sieh hier neue Ansätze Energiesparmaßnahmen umzusetzen, Routen können zum Beispiel bevorzugt über nicht energiebeschränkte Knoten geleitet werden, Knoten, die immer aktiv sind, könnten so etwa auch Steuerungsaktivitäten für die schlafenden Xachbarknoten übernehmen, ähnlich wie dies die Basisstation im Infrastrukturmodus von IEEE 802.11 auch tut. Dies bietet Raum für weitere Forschung in diesem Themengebiet.

3.10 Informationsverbreitung

Informationsverbreitungsanwendungen stellen die typischen und primären Applikationen in VAXETs dar und spielen für die Fahrerassistenz eine wichtige Rolle, Anwendungen dieser Ka­tegorie setzen Kommunkationsmuster voraus, die in konventionellen Netzwerken in dieser Form nicht Vorkommen, Aufgrund dieser Wichtigkeit und Neuartigkeit der Informationsverbreitung geht dieser Abschnitt näher auf die besonderen Anforderungen von Informationsverbreitungs­ funktionalität ein und wie diesen begegnet werden kann. Wie bereits in 2.1.1 besehrieben, geht es bei der Informationsverbreitung darum, Informationen nahezu in Echtzeit im Netzwerk zu verbreiten, um damit dem Fahrer mehr Transparenz über die Verkehrslage und verkehrsrele­vante Ereignisse zu verschaffen. Dadurch entsteht ein deutlich erweiterter Informationshorizont für den Fahrer, der durch konventionelle Techniken in dieser Form nicht zu erreichen wäre. Die resultierenden Informationen dienen der Optimierung und Steuerung des Verkehrsflusses, sowie der Gefahrenwarnung, Andere Einsatzgebiete, wie etwa die Interaktion mit Infrastruktur für spezielle Dienste, sind denkbar. Da die verbreiteten Informationen vielfältiger Art und vielfäl­tigen Ursprungs sein können, und jeweils unterschiedliche Verbreitungsgebiete und -gruppen aufweisen, ist eine sorgfältige Implementierung der entsprechenden Applikationen notwendig, um das Netzwerk nicht mit Datenverkehr zu überlasten und einen echten Mehrwert für den individuellen Fahrer und alle Verkehrsteilnehmer zu generieren.

Eine wesentliche Eigenschaft der Informationsverbreitung ist es, dass keinerlei Routing benö­tigt wird, weil keine bidirektionale Kommunikation notwendig ist, Stattdessen müssen Informa­tionen effizient und zuverlässig unter einer dynamischen Knotenmenge im Netzwerk verbreitet werden. Dazu werden erweiterte Rundfunkmeehanismen eingesetzt. Eine wichtige Erkenntnis ist, dass Informationen situationsbasiert verbreitet werden. Eine situationsbezogene Informa­tion von Bedeutung ist es etwa, wenn ein Fahrzeug sieh im Stau oder zähfliefsendem Verkehr befindet. Ein Ereignis von Interesse könnte auch die Erkennung einer Gefahrensituation wie Glatteis oder ein Hindernis auf der Strecke darstellen. Dies sind Informationen die für ande­re Verkehrsteilnehmer wertvoll sind, Staus können so von anderen Fahrzeugen gemieden oder Gefahrensituationen im Voraus erkannt werden. Da der Fahrer jedoch nicht selbst die Analyse und Verbreitung einer solchen Information anstofśen kann, muss das Fahrzeug bzw, eine entspre­chende Fahrerassistenzapplikation autonom feststellen, wenn Ereignisse von Interesse auftreten und wie resultierende Informationen im VANET zu verbreiten sind.

Dazu verfügen Fahrzeuge bereits heute über eine Vielzahl von Sensoren für Daten wie die Fahrgeschwindigkeit, Bodenhaftung, Fahrzeugposition und viele mehr. Die korrekte Auswertung dieser Sensordaten, um daraus Rückschlüsse auf Verkehrssituationen zu ziehen, ist wesentlich für die praktische Umsetzung von Informationsverbreitungsanwendungen, Insbesondere müs­sen Sensordaten immer kontextsensitiv ausgewertet werden, damit eine hohe Qualität bei der Klassifizierung von Situationen erreicht werden kann. Dieser Informationskontext muss durch weitere Sensoren wie digitalen Kartendaten und der Fahrzeugposition ermittelt werden. Da für einen Mefśwert ggf, mehrere Sensoren zur Verfügung stehen, ist hier auch der Einsatz von Sensorfusion denkbar, um die Qualität der Sensordaten zu erhöhen. Genügt die Information eines Fahrzeugs nicht aus, um eine Situation zu erkennen und zu klassifizieren, müssen Sensor- daten zwischen mehreren benachbarten Fahrzeugen eines VAXETs ansgetanseht und fusioniert werden. Bestimmte Daten müssen grundsätzlich kooperativ ermittelt werden, wie zum Beispiel die Dnrehsehnittsgesehwindigkeit der Fahrzeuge auf einem bestimmten Strafśenabsehnitt, nm festzustellen wie der tatsächliche Verkehrsfluss ist. Diese Sensorverarbeitung weist Parallelen zu SAXETs aufn in denen die Knoten ebenfalls ihre Sensorwerte austausehen und zusammenfüh­ren, um Entscheidungen zu fällen. Diese Form der kooperativen Klassifikation von Situationen anhand von Sensordaten erfordert geeignete Schnittstellen der VAXET-Applikationen zu den Sensoren im Fahrzeug, Insbesondere muss die Kompatibilität bzw, eine Schnittstelle zwischen den Sensoren verschiedener Fahrzeughersteller und -typen geschaffen werden, um die koopera­tive Verarbeitung von Sensordaten überhaupt zu ermöglichen. Ist eine Applikation nicht in der Lage, eine Situation korrekt zu klassifizieren, droht die Ausbreitung von fehlerhaften Xaehrieh- ten in grofśen Teilen des Xetzwerks, Hier muss eine hohe Qualität der Applikationslogik gewähr­leistet sein und übergreifende Sehutzmeehanismen müssen im Xetzwerk getroffen werden, um zu verhindern, dass fehlerhafte Meldungen ungeprüft von anderen VAXET-Teilnehmern wei­tergeleitet werden. Im Strafsenverkehr treten vielfältige Situationen auf, die ggf, nur schwierig zuverlässig von Software zu erkennen sind. Ist eine Applikation weder in der Lage, eine Situati­on autonom noch kooperativ mit anderen Xetzwerkknoten zu klassifizieren, ist es denkbar, dem Fahrer zum Beispiel Bild- oder Videoaufzeichnungen von relevanten Strafśenabsehnitten zu prä­sentieren, so dass der Fahrer manuell eine Klassifikation der Situation vornehmen und geeignete Schlüsse ziehen kann, Techniken aus dem Bereich der künstlichen Intelligenz wie Fuzzy-Logik oder neuronale Xetzwerke bieten sieh hier an, um eine gewisse Lernfähigkeit der Software und bessere Ergebnisse zu erreichen.

Ist eine Situation erfolgreich klassifiziert, muss die Anwendung entscheiden, ob die daraus resultierende Information von Mehrwert für andere Knoten im Xetzwerk ist. In diesem Fall wird eine geeignete Xaehrieht erzeugt, für die weitere logische Parameter ermittelt und gesetzt werden. Diese Parameter umfassen etwa ein geeignetes Verbreitungsgebiet sowie eine sinnvol­le Lebensdauer für die Xaehrieht, Verbreitungsgebiete können relativ spezifiziert werden, so z, B, die Übermittlung der Information an alle entgegenkommenden Fahrzeuge, alle vor oder hinter dem Fahrzeug befindlichen Teilnehmer oder im Umkreis eines bestimmten Entfernungs­oder Hop-Radius, Eine absolute Spezifikation eines Gebiets kann die Wahl von bestimmten Streckenabschnitten sein, auf denen die Xaehrieht Verbreitung finden soll, Sehliefślieh können konkret geographische Regionen spezifiert werden, die mit geometrischen Primitiven beschrie­ben werden so z, B, durch Rechtecke, Kreise oder Polygone |Adler06|, Die Verbreitung der Xaehriehten findet nach Wahl der Parameter durch selektiven Rundfunk bzw, geographischen Rundfunk statt (vgl, 2.4.5), Ein Beispiel ist in Abbildung 3.22 gegeben: Der rote Knoten hat

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.22: Beispiel zur Gefahrenwarnung mit Hilfe von Informationsverbreitung

eine Ausnahmesituation erkannt, die den blau gefärbten Straßenbereich betrifft (z. B. Glatteis, Regen). Deshalb erstellt der Knoten eine Warnnachricht für andere Verkehrsteilnehmer, die das Gefahrengebiet beschreibt. Für diese Nachricht spezifiziert er ein Verbreitungsgebiet, das die Gefahrenzone weiträumig umschließt (rot gepunktetes Rechteck). Fahrzeuge, die sich nun in diesem Verbreitungsgebiet aufhalten, erhalten diese Nachricht, sind dadurch vor ge warnt und können ihre Fahrweise entsprechend anpassen.

[KoschOö] und [AdlerOG] beschäftigen sich ausführlich mit den Thema Informationsverbrei­tung in VANETs. [KoschOö] erkennt die Probleme beim Medienzugriff in Funknetzen bei Rund­funk (vgl. 2.4.5). Zur Milderung der Probleme beim Medienzugriff wird bereits auf der Logike­bene der Applikation angesetzt. Durch Unterstützung mit Positions- und digitalen Kartendaten kommt ein Medienzugriffsverfahren zum Einsatz, das Weiterleitungsknoten für Rundfunkpakete selektiv bestimmt, so dass nicht jeder Knoten empfangene Rundfunkpakete wahllos weiterver­breitet. Die Logik, die hier zum Einsatz kommt, betrachtet, wie viele neue Knoten durch die individuelle Rundfunkübertragung die Information erhalten. Abhängig von diesem Nutzen wird eine Verzögerungszeit bis zur Übertragung des Rundfunkpakets festgelegt. Dies entsprieht einem Wettbewerbsverfahren in dem diejenigen Knoten die den gröfsten Vorteil durch die Übertragung des Rundfunkpakets erreiehen können (durch ihre geographisehe Position in der Xetzwerkto- pologie), die kürzeste Wartezeit erreiehen und damit die anderen Knoten, die weniger Vorteil durch ihre Übertragung realisieren können, verdrängen. Um dieses Verfahren der Strafśentopo- logie anzupassen, werden bevorzugt an Kreuzungen Weiterleitungsknoten ausgewählt, da hier in der Regel neue Verbreitungswege im Strafśennetz erreicht werden.

In IAdler06| wird die Notwendigkeit der Abstraktion von Informationen beschrieben. Da aufgrund der Gröfse von VAXETs und der vielfältigen Informationen, die verbreitet werden können, eine grofśe Anzahl von Nachrichten im Netzwerk kursiert, muss Abstrahierung durch Zusammenfassung von Nachrichten vorgenommen werden, um einerseits den anstehenden Da­tenverkehr zu beherrschen und andererseits die Nutzbarkeit der Informationen für den Fahrer zu verbessern. Als Beispiel seien von Infrastruktur gestützte Anwendungen genannt, die die Zahl der freien Parkplätze und Hotelzimmer in verschiedenen Gebieten einer Stadt mitteilen. Für ein Fahrzeug aufśerhalb der Stadt sind diese Informationen nicht in so hohem Detaillie­rungsgrad interessant, wie für Verkehrsteilnehmer im Stadtzentrum, Diese Daten können daher auf verschiedenen Stufen zusammengefasst werden. Der Detaillierungsgrad kann dabei von der konkreten St raise, über Daten zu Stadtvierteln bis hin zu gesamten Städten variiert werden. Unterschiedliche Detaillierungsgrade von Nachrichten können auch dann zum Einsatz kommen, wenn die Leistungsfähigkeit des Netzwerks gering ist, um Bandbreite bzw, Medienzugriffe ein­zusparen, Informationen müssen auch aggregiert werden können, Ereignisse und Situationen im Strafsenverkehr werden naturgemäfs von mehreren Fahrzeugen gleichzeitig bzw, sukzessive erkannt. Würde nun jedes dieser Fahrzeuge individuell seine Sensordaten auswerten, eine Nach­richt generieren und im Netzwerk verbreiten, würden mehrere Nachrichten von logisch äquiva­lentem Inhalt verbreitet, ohne Mehrwert für das VAXET, Deshalb müssen Weiterleitungsknoten neue Nachrichten mit bereits verbreiteten Nachrichten vergleichen, erkennen wenn diese logisch gleichwertig sind und als Konsequenz diese nicht weiterleiten. Ggf, können auf diese Art auch Nachrichten zusammengefasst oder in der Genauigkeit verbessert werden. Bei diesem Prozess handelt es sieh um die Verarbeitung und Veränderung von Paketinhalten innerhalb des Netz­werks während der Verbreitung der Information (engl, in-network processing, |TmFH06|), Dies bedeutet, dass die Xutzdaten eines zu übertragenden Pakets nicht als unbekannte Information gehandhabt werden, die lediglich im Netzwerk verbreitet werden muss, Stattdessen beeinflusst der Inhalt der Nachricht die konkrete Weiterverarbeitung des Pakets im Xetzwerkstapel, Auf­grund der erweiterten Informationen der Informationsverbreitungsanwendung kann der Inhalt des Pakets auch vor der Weiterverbreitung verändert oder Verbreitungsparameter angepasst werden (z, B, Lebensdauer oder Verbreitungsgebiet), Es handelt sieh hierbei deshalb nicht um ein paketorientiertes Weiterleiten von Informationen, sondern um ein nachrichtenorientiertes Weiterleiten, da die Inhalte des Pakets zunächst logisch verarbeitet werden müssen, bevor eine Weiterleitungsentscheidung getroffen werden kann.

Neben dieser neuen Sichtweise auf die Verarbeitung von Paketen im Protokollstapel sind wei­tere angepasste Mechanismen für die Informationsverbreitung notwendig. Es muss eine Priori- sierungsmöglichkeit für Nachrichten vorgesehen werden, da bestimmte Nachrichten eine höhere Bedeutung haben als andere und ggf, schneller oder anders verbreitet werden müssen. Ei­ne einfache Unterscheidung wäre etwa die in Verkehrsflussnachrichten und sicherheitsrelevante Nachrichten, Des weiteren können Nachrichten auch nicht immer isoliert voneinander betrachtet werden, sondern können sieh auch aufeinander beziehen. Eine Staumeldung etwa muss wieder zurückgezogen werden wenn erkannt wird, dass der Verkehr wieder fließt. Andernfalls würden dem Fahrer auf Dauer veraltete und ungültige Informationen von der Fahrerassistenzanwen­dung mitgeteilt werden. Da ein VANET nicht immer vollständig zusammenhängend ist und Partitionen bilden kann, neue Knoten immer wieder hinzutreten oder sieh in andere Netzwerk­partitionen bewegen, können sieh Informationen nicht immer sofort im gesamten Netzwerk bzw, dem vorgesehenen Verbreitungsgebiet ausbreiten. Aus diesem Grund muss das sogenann­te Store-and-Forward-Verfahren umgesetzt werden. Dieses Verfahren sieht für bestimmte Pakete vor, dass sie von denjenigen Knoten, die die Nachricht bereits erhalten haben in einem Zwi­schenspeicher vorgehalten werden. In regelmäfsigen Intervallen, oder als Reaktion auf Ereignisse (wenn neue Teilnehmer im VANET erkannt werden), können diese gespeicherten Nachrichten nochmals zu einem späteren Zeitpunkt weiterverbreitet werden. Auf diese Weise werden langle­bige Informationen auch neu hinzutretenden Teilnehmern übermittelt bzw, ein Fahrzeug kann die Information in neue Netzwerkpartitionen transportieren und dort bekannt machen. Die verzögerte Weiterverbreitung von Paketen kann deshalb anhand der geographischen Position im Netzwerk vorgenommen werden aufgrund der Annahme, dass an einem anderen Ort im Netzwerk die Nachricht vielleicht noch nicht angekommen ist. Um Nachrichten dauerhaft in bestimmten Verbreitungsregionen am Leben zu erhalten, kann es notwendig sein, dass der ei­gentliche Verbreitungsbereich einer Nachricht vergröfsert werden muss. Dies ist dann notwendig, wenn nur ein kleiner Verbreitungsbereich vorliegt, in dem sieh keine oder nur wenige Teilneh­mer befinden bzw, wenn die Fahrzeugdichte im Zielgebiet sehr gering ist. Andernfalls droht die Gefahr, dass Nachrichten verloren gehen und für Fahrzeuge, die später das Zielgebiet erreichen, nicht zur Verfügung stehen. Dies geht auch aus Abbildung 3.22 hervor: Verlassen hier alle Kno­ten das Verbreitungsgebiet der Warnnachricht, erhält ein später in den Bereich neu eintretender Knoten keine Warnung mehr.

Neben der automatischen Verbreitung von Informationen im Netzwerk durch VANET-App- likationen gibt es auch Informationsarten, die nicht proaktiv verbreitet sondern zum Beispiel nur auf Anfrage anderer Teilnehmer mitgeteilt werden. Dies ist der Fall, wenn die Information nicht generell für alle Verkehrsteilnehmer interessant ist, sondern nur für eine beschränkte Gruppe, In diesem Fall kann zum Beispiel eine Mehrpunktgruppe eingerichtet werden, unter deren Mitgliedern die entsprechenden Informationen verbreitet werden.

Die Effektivität von Informationsverbreitungsanwendungen hängt stark von der Anzahl der Teilnehmer im VANET ab. Herrscht nur eine sehr geringe Fahrzeugdiehte, verbreiten sieh In­formationen nur sehr langsam oder gar nicht und Fahrerassistenzanwendungen können nicht mehr sinnvoll betrieben werden. Zwischen der Fahrzeugdiehte und der Kommunikations- bzw, Verbreitungsreiehweite herrscht ein logarithmiseher Zusammenhang, Mit der Verdoppelung der Fahrzeugdiehte im VANET erreicht man etwa viermal weiter entfernte Teilnehmer mit Infor- mationsverbreitungsnaehriehten. Daraus lässt sieh auch eine kritische Höhe der Fahrzeugdiehte ableiten, ab der auch hohe Entfernungen leicht iiberbriiekt werden können und die Konnek­tivität zwischen Netzwerkpartitionen gut ist |Koseh05|, Durch geeigneten Einsatz von Logik bei der Verbreitung von Informationen kann die Verbreitungsgesehwindigkeit zum Zielgebiet einer Nachricht noch optimiert werden, Informationen können etwa über entgegenkommenden Verkehr geleitet werden, damit die Information sieh in der entsprechenden Richtung verbreitet. In diesem Fall kann daher die Mobilität der Knoten im VANET positiv ausgenutzt werden, um die Ziele der Applikationen zu erfüllen.

Die Klasse der Informationsverbreitungsapplikationen zeigt die umfangreichen Aufgaben, die Fahrerassistenznanwendungen in einem VANET durchführen müssen. Eine starke Bindung die­ser Anwendungen zu den niedrigeren Netzwerksehiehten wird notwendig sein |TmFH06|, um die notwendige Effizienz, Zuverlässigkeit und Funktionalität zu erreichen. Denn einerseits benötigt die Informationsverbreitungsanwendung Daten über den Netzwerkzustand (Teilnehmerdiehte, Signalstärke zu Naehbarknoten, etc.) sowie Einfluss auf Verbreitungsparameter (Zielregionen, Lebenszeiten), und andererseits kann die Anwendung den Netzwerksehiehten wichtige Anhalts­punkte über die weitere Behandlung der zu übertragenden Information liefern. Die besonde­ren Anforderungen von Informationsverbreitung müssen also bei der Konzeptionierung eines VANET-Systems Berücksichtigung finden.

3.11 Weitere Besonderheiten in VANETs

Die Eigenschaften und Aspekte von VANETs sind sehr vielfältig und bieten Raum für viele Spezialgebiete und Sonderbetraehtungen, Diese Arbeit konzentrierte sieh bisher auf zentrale Themengebiete, die für VAXETs und deren Einsatz im Rahmen von Fahrerassistenzanwendun­gen von hoher Bedeutung sind. In diesem Abschnitt werden nun einige relevante Spezialthemen Umrissen, deren ausführliche Behandlung den Umfang dieser Arbeit sprengen würden. Dennoch sollen diese nicht unerwähnt bleiben, um ein Gesamtbild von VAXETs zu ermöglichen.

3.11.1 Zeitsynchronisierung

Einige Algorithmen für VAXETs benötigen eine gemeinsame, synchronisierte Zeit unter allen Knoten im Xetzwerk, Meistens handelt es sieh dabei um Algorithmen zum Medienzugriff, da hier Zeitsehlitze von sehr kurzer Dauer koordiniert werden müssen. Aber auch Applikationen brauchen je nach Typ eine zuverlässige Uhrzeit aller Knoten, um korrekte Aussagen treffen zu können wenn Xaehriehten anderer Knoten verarbeitet werden. Dies trifft zum Beispiel zum Teil auf Informationsverbreitungsanwendungen zu, die Sensordaten kooperativ verarbeiten. Dabei muss nicht unbedingt die tatsächliche Uhr zeit verwendet werden, sondern es kann eine eigene Uhrzeit für VAXETs eingeführt werden, wie dies auch bei GSM der Fall ist. Die Xotwendigkeit der Synchronisation bleibt dennoch bestehen.

Es gibt Arbeiten, die sieh aussehliefślieh mit der Zeitsynehronisation in Ad-Hoe-Xetzwerken beschäftigen. Diese betreffen vor allem SAXETs, da Sensornetzwerke aufgrund ihrer kooperati­ven Sensordatenverarbeitung besonders auf zuverlässige Zeit angewiesen sind. Eine ausführliche Behandlung dieses Themas findet sieh zum Beispiel in |Meier06| und |Blum04|, Die Genauigkeit der gemeinsamen Uhrzeit muss jedoch auch für VAXETs hoch sein. Beim Medienzugriff müs­sen Genauigkeiten im Mikrosekundenbereieh gegeben sein, wenn die Uhrzeit zur Koordination verwendet werden soll. Da in VAXETs die Knoten nach Voraussetzung ein Positionierungssy­stem haben müssen, besteht die Möglichkeit, etwa bei Xutzung von GPS-Positionierung, die GPS-Uhrzeit zur Synchronisation zu nutzen. Bei GPS kann eine Genauigkeit der Uhrzeit im Xanosekundenbereieh (50 ns) erreicht werden, da die GPS-Satelliten mit Atomuhren ausgestat­tet sind. Wie diese Genauigkeit allerdings in der Praxis erreicht werden kann, bedarf näherer Untersuchung, Dies hängt unter anderem von der Genauigkeit des GPS-Empfängers, der Häu­figkeit der Synchronisation und der Genauigkeit der internen Uhr des VAXET-Systems ab. Im Optimalfall erleichtert ein Positionierungssystem wie GPS die Problematik der Zeitsynehronisie- rung deutlich. Jedoch muss bei der satellitengestützten Positions- und Zeitbestimmung immer bedacht werden, dass die Qualität und Verfügbarkeit dieser von den Umgebungsbedingungen abhängt. In Tiefgaragen, Tunneln und ungünstigen Konstellationen kann die Qualität sieh stark verringern oder die Verfügbarkeit ganz einbreehen. Ist das VAXET-System nicht in der Lage solche Schwankungen und Ausfallzeiten zu überbrüeken, ist im Falle des synchronisierten Me­dienzugriffs keine zuverlässige Kommunikation mehr möglich, Aufśerdem könnten auch einige Knoten ohne Positioniernngssystem am VAXET teilnehmen. Eine hybride Strategie, die neben der Nutzung des Positionierungssystems auch Techniken der dezentralen Zeitsynchronisierung in Betracht zieht, erscheint daher sinnvoll.

3.11.2 Unidirektionale Verbindungen

Ein Problem, das in Arbeiten zu VAXETs zur Vereinfachung meistens ignoriert wird, ist die Existenz von unidirektionalen Verbindungen im Ad-Hoc-Xetzwerk. Unidirektionale Verbind­ungen entstehen, wenn Knoten im Netzwerk unterschiedliche Kommunikationsreichweiten ha­ben oder die physikalischen Eigenschaften des Kanals die Kommunikation nur in eine Richtung ermöglichen (Abbildung 3.23 (a)). Diese unidirektionalen Verbindungen stellen ein Problem dar, weil Routingprotokolle und Anwendungen davon ausgehen, dass Knoten, die sie erreichen können, auch den Riiekkanal nutzen können. Andererseits sorgt dieser Effekt auf Medienzu­griffsebene für Verzögerungen und Kollisionen, da Kontrollverkehr von einem der beteiligten Knoten nicht empfangen werden kann. Ein weiterer Effekt dieser Art entsteht durch unter­schiedliche Übertragungsarten zwischen Rundfunk- und Xormalverkehr, In IEEE 802.11 werden Rundfunkpakete mit geringer Datenrate übertragen, was für gröfsere Stabilität und Reichwei­te der Übertragung sorgt, Punkt-zu-Punkt-Übertragungen werden hingegen mit der maximal möglichen Datenrate durchgeführt, was schlechtere Eigenschaften mit sieh bringt (Abbildung 3.23 (b)) |Schwingenschlögl04|. So kann es etwa auftreten, dass das Xachbarschaftsprotokoll, das Rundfunkpakete einsetzt, einen Nachbarn erkennt der aber nicht durch Punkt-zu-Punkt- Übertragungen erreichbar ist.

In |RP99| wird gezeigt, dass für Routingalgorithmen wie DSDV in einem Ad-Hoc-Xetzwerk mit n Knoten 0(n² ) Nachrichten ausgetauscht werden müssen, um alle unidirektionalen Ver­bindungen in der Topologie zu identifizieren. Da dieser Vorgang aufgrund der Mobilität in VAXETs häufig wiederholt werden müsste, ist er nicht effizient. Die Notwendigkeit und der Aufwand des Vorgangs hängt vom konkreten Routingalgorithmus ab. Für VAXETs würde es meist genügen, die direkten unidirektionalen Verbindungen zu erkennen, um diese zu meiden und Fehlverhalten von Algorithmen zu verhindern. Andererseits bieten unidirektionale Verbind­ungen auch potentielle Vorteile für das VAXET, da diese bessere Routen für Ende-zu-Ende- Verbindungen oder mehr Kommunikationspartner für Applikationen bieten könnten. Dieses Potential zu nutzen setzt aber ebenfalls die Erkennung dieser unidirektionalen Verbindungen voraus.

Andererseits stellt sieh die Frage, wie stabil eine unidirektionale Verbindung in einem VAXET ist. Davon ausgehend, dass die Kommunikationsreichweiten der Knoten im VAXET nicht stark voneinander abweichen, würde die Existenz einer unidirektionalen Verbindung darauf hindeu-ten, dass die beiden beteiligten Knoten sich an der Grenze ihres Kommunikationsradius befin­den. Entfernen sich zwei solche Knoten weiter voneinander, droht die Verbindung vollständig zu abzubrechen. Die Knoten können sich aber auch annähern. In diesem Fall wird eine unidirek­tionale Verbindung nach einiger Zeit zu einer bidirektionalen. Genauso können bidirektionale Verbindungen zu unidirektionalen werden. Ob sich der Aufwand lohnt, diese Zustände zu er­kennen und auszunutzen, ist eher Zweifelhaft, weil dadurch unnötig mehr Komplexität entsteht.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.23: (a) Unidirektionale Verbindung (b) Verbindung die nur mit Rundfunkübertra­gungen zustande kommt

Um die Nutzung unidirektionaler Verbindungen zu vermeiden, schlägt [SchwingcnschlöglO l] vor, die Nachbarschaftslisten, die das Nachbarschaftsprotokoll ermittelt, unter den Nachbarn im Netzwerk per Rundfunkübertragungen auszutauschen. So kann jeder Knoten, der eine un­idirektionale Verbindung hat, feststellen, dass er selbst nicht in der Nachbarschaftsliste des unidirektional erreichbaren Knoten enthalten ist. Dies ist ein einfaches Verfahren, das die Pro­blematik unidirektionaler Verbindungen sicher umgeht. Jedoch entsteht dadurch auch erhöhter Mehraufwand durch die Rundfunkübertragungen (vgl. 3.2).

Es steht fest, dass unidirektionale Verbindungen in der Praxis eine Rolle spielen werden. Wie groß der negative Einfluss durch die fehlende Kenntnis und die daraus folgende fehlerhafte Nutzung dieser Verbindungen für Routingprotokolle und Anwendungen in VANETs ist, kann im Rahmen von Simulationen oder Praxistests evaluiert werden. Ein effizientes Verfahren, das nnidirektionale Verbindungen fiir Algorithmen und Anwendungen ansblendet, könnte die beste Lösung fiir die Stabilisierung von VAXETs sein.

3.11.3 Internetintegration

Viele Arbeiten betraehten die Möglichkeit der Integration von VAXETs in das Internet als zentrale Fragestellung fiir deren Erfolg in der Praxis, Deshalb werden oft auch Teile der Inter- netarehitektnr fiir die Umsetzung von VAXETs vorgesehen. Die Internetintegration mag ans ökonomischer Sieht einen wichtigen Aspekt darstellen. Ans technischer Sieht macht es jedoch keinen Sinn, die Entwicklung der VAXET-Algorithmen und -Protokolle an die Internetarehi- tektur und TCP/IP anzulehnen. Die Charakteristiken des infrastruktur- und kabelbasierten Internets sind zu verschieden zu denen eines kooperativen, dezentralen Ad-Hoe-Funknetzes, um sieh daran zu orientieren. Dies zeigt sieh in vielen Bereichen, die in diesem Kapitel an- gesproehen wurden. Auf allen Ebenen des Protokollstapels haben VAXETs wesentlich andere Eigenschaften und Anforderungen als dies im Internet der Fall ist. Die naturgegebene Fehler­anfälligkeit des Mediums, der schwierigere Medienzugriff sowie die komplexe und beschränkte Realisierung von Routingalgorithmen zeigen dies. Eine direkte Verbindung von VAXET-Knoten mit Internetknoten über TCP/IP würde insbesondere die in 3.5 festgestellten Probleme mit sieh bringen. Aber auch die Adressierung wie in 3.6 beschrieben ist in VAXETs grundlegend anderer Xatur.

Deshalb ist es sinnvoll, die Architektur des VAXETs vollständig von Kompatibilitätsaspekten unbelastet auf dessen eigene Anforderungen auszuriehten, Schnittstellenknoten, die als zusätz­liche Infrastruktur in VAXETs zur Verfügung gestellt werden, übersetzen dann zwischen den beiden Xetzwerken und verdecken dabei gleichzeitig problematische Eigenschaften der beiden Xetztypen voreinander, um Verbindungsabbriiehe auf der Internetseite aufgrund des fehler­anfälligen VAXETs und eine ungeeignete Xutzung der Ressourcen des VAXETs durch das Internetprotokoll zu verhindern.

Bei der Internetintegration ergeben sieh noch weitere Problemstellungen wie das effiziente Auffinden von Internetschnittstellen durch VAXET-Teilnehmer, Entsprechende Diensterken- nungsteehniken in kabelbasierten Xetzen gründen meist auf dem Verhalten, dass die Dienst­nehmer eine Rundfunkanfrage im (lokalen) Xetzwerk verbreiten, um verfügbare Diensteanbieter zu ermitteln (Abbildung 3.24 (a)). Aufgrund der Mobilität in VAXETs müsste dieses Anfrage regelmäfsig wiederholt werden. Angenommen, es besteht eine hohe Interaktion der VAXET- Knoten mit dem Internet, Dann entsteht ein grofśer Mehraufwand durch die Knoten, die neue Internetschnittstellen in ihrer Umgebung suchen. Dies kann man durch Zwisehenspeieherung ab-mildern, indem Knoten sieh Schnittstellen in ihrer Umgebung merken und direkt auf Anfragen anderer Knoten antworten können, ohne dass diese bis zum eigentlichen Schnittstellenknoten durchdringen müssen. Eine grundsätzlich andere Herangehensweise präsentiert [BWSF03] mit dem DRIVE-Protokoll (DiscoveRy of Internet gateways from VEhicIes). Dieses sieht vor, dass die Schnittstellenknoten ihren Dienst selbst proaktiv unter den Knoten im VANET bekannt machen. So werden die Rundfunknachrichten auf die verhältnismäßig wenigen Internetschnitt­stellen beschränkt und die mobilen Knoten müssen nur noch den Verkehr abhören, um Informa­tionen über Internetzugang in der Umgebung zu erhalten (Abbildung 3.24 (b)). Das Protokoll berücksichtigt auch die Auswahl von einem Schnittstellenknoten aus mehreren Alternativen. Dazu wird ein Ansatz mit Fuzzy-Logik verfolgt, der Größen wie die Wahrscheinlichkeit des Verbindungsabbruchs, Eignung für bestimmte Dienstgüteklassen und verfügbare Bandbreite in den Entscheidungsprozess mit einbezieht.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.24: (a) Konventionelles Diensterkennungsverfahren (b) Diensterkennungsverfahren gemäß DRIVE

Insgesamt sollte die Realisierung der Internetanbindung von VANETs losgelöst werden von der Entwicklung der VANET-Architektur und die Aufgabe der Verbindung der unterschiedli­chen Netztypen an die Infrastruktur, d.h. die Schnittstellenknoten delegiert werden. Aus die­sem Blickwinkel stellt die Internetintegration keine herausragende Schwierigkeit dar und die

VAXET-Arehitektur kann sich vollständig auf die Lösung der VAXET-spezifisehen Probleme konzentrieren.

3.11.4 Simulationen

Mit Hilfe von Xetzwerksimnlatoren können grofśe VAXETs simuliert werden. Zahlreiche Arbei­ten verwenden solche Simulatoren, um Algorithmen zu implementieren und deren potentielles Verhalten in der Praxis zu analysieren, Simlatoren werden so ausgiebig verwendet, weil ein ech­ter Versuchsaufbau einen erheblichen Ressourcenaufwand mit sich bringt. Schon für ein kleines VAXET sind mehrere Fahrzeuge notwendig. Je Fahrzeug werden weiterhin ein bis zwei Perso­nen benötigt, um das Fahrzeug zu steuern und ggf, das VAXET-System zu bedienen oder zu kontrollieren. Selbst wenn der Aufwand betrieben wird, so einen Versuchsaufbau zu organisieren und zu finanzieren, ist es nur schwer möglich einmal durchgeführte Versuche mit veränderten Parametern oder Algorithmen zu wiederholen, da genau dieselben Bewegungsmuster und phy­sikalischen Konstellationen hergestellt werden müssten. Dies ist praktisch kaum durchführbar. Weiterhin lassen sich viele Fragestellungen nur in grofsfläehigen VAXETs mit vielen Teilnehmern beantworten.

Simulatoren hingegen erlauben die Modellierung gesamter Xetzwerke und des Datenverkehrs, der zwischen den Knoten abläuft, Beispiele für häufig eingesetzte Xetzwerksimulatoren sind |XS2| und |GloMoSim|, Diese werden in wissenschaftlichen Arbeiten gerne eingesetzt, weil sie quelloffen und frei verfügbar sind und sich so gut zum Vergleich verschiedener Algorithmen auch über die Grenzen einzelner Arbeiten hinweg eignen. Darüber hinaus gibt es noch einige kom­merziell verfügbare Xetzwerksimulatoren, die gelegentlich zum Einsatz kommen. Die meisten Xetzwerksimulatoren implementieren gemäfs dem OSI-Sehiehtenmodell jede Xetzwerksehieht separat als Modul, So lassen sich einzelne Module wie Routingalgorithmen oder Medienzu­griffsalgorithmen austausehen und durch individuelle Algorithmen ersetzen. Diese Module wer­den üblicherweise in einer Skriptsprache implementiert, um den Entwieklungsaufwand gering zu halten.

Da es sich um die Simulation eines ganzen Xetzwerks handelt, müssen natürlich noch weitere Eigenschaften simuliert werden. Im Falle von VAXETs muss eine geographische Fläche definiert werden, auf der sich die Knoten des Xetzwerks positionieren lassen. Da Knoten in VAXETs mobil sind, muss auch die Möglichkeit bestehen, die Knotenpositionen zu verändern, Xaehdem Funk als Kommunikationsmedium zum Einsatz kommt, muss auch ein Kommunikationsmo­dell umgesetzt werden, das bestimmt wann Knoten miteinander kommunizieren können. Die Wahl dieser Eigenschaften sind Gründe dafür, dass Simulationen oftmals nicht sehr realitäts­nah durchgeführt werden. Viele Arbeiten wählen ein sehr vereinfachtes Modell: Eine rechteckige Fläche auf der Knoten zufällig verteilt werden. Jeder Knoten bewegt sieh in zufälligen Bahnen, indem er sieh für einige Sekunden in eine zufällig gewählte Richtung bewegt und dann eine neue Richtung wählt. Als Funkausbreitungsmodell kommen oft Siehtmodelle zum Einsatz, bei denen alle Knoten den selben Kommunikationsradius haben und wenn zwei Knoten innerhalb ihres Radius sind, können sie kommunizieren, sonst nicht. Darüber hinaus wird auch oft der sogenannte Gottmodus von Simulatoren genutzt, der es erlaubt, in Algorithmen beliebig Daten und Zustände anderer Knoten im Netzwerk abzufragen und zu manipulieren, die in der Realität nicht verfügbar wären.

Diese Eigenschaften kommen schon den Bedingungen von allgemeinen MAXETs nicht sehr nahe, bei denen meist davon ausgegangen wird, dass es sich bei den Knoten um Menschen mit mobilen Geräten auf einem Gelände oder in einem Gebäude handelt. Für VAXETs jedoch sind diese Modelle absolut ungeeignet und verzerren die Simulationsergebnisse deutlich gegenüber dem Realfall, Zur Abhilfe lässt sich der Xetzwerksimulator mit einem Verkehrssimulator koppeln |GGDCI06|, |CB05|, |TG05|, Verkehrssimulatoren empfinden das Mobilitätsverhalten von Fahr­zeugen im Strafsenverkehr nach. Die Bewegungsmuster basieren meist auf digitalen Kartendaten oder Stadtplanmodellen, in denen Knoten nur auf St ralseti positioniert werden können. Das Mo­bilitätsmodell der Verkehrssimulatoren kann dabei beliebig komplex werden, indem Kreuzungs­verkehr, Ampeln und erhöhtes Verkehrsaufkommen auf Hauptstrafśen gegenüber Seitenstrafśen berücksichtigt werden. Bei Verkehrssimulatoren handelt es sich um aufwändige Software, die fast aussehliefslieh kommerziell oder im Rahmen der Konzernforschung von grofśen Automobil­herstellern verfügbar ist. Die Verbindung von Xetzwerksimulator und Verkehrssimulator stellt abhängig von den beiden konkreten Komponenten eine gewisse Schwierigkeit dar, da diese na­türlich geeignete Schnittstellen benötigen, über die sie miteinander interagieren können. Der Verkehrssimulator übernimmt dann die Positionierung der Knoten auf Strafśenelementen, führt die Bewegungen der Knoten gemäfs dem Mobilitätsmodell durch und meldet die Positionen an den Xetzwerksimulator, welcher weiterhin die Simulation des Datenverkehrs übernimmt.

Wenn durch einen Verkehrssimulator bereits Kartendaten zur Simulation zur Verfügung ste­hen, liegt es nahe, auch ein angepasstes Funkausbreitungsmodell einzuführen, das die Dämp­fung der Funkwellen durch Gebäude und Umwelteinflüsse in die Simulation mit einfliefśen lässt. Dass die korrekte Simulation der Funkausbreitung wesentlichen Einfluss auf das Verhalten von Protokollen haben, wurde in |DRS06| festgestellt. Mit Hilfe eines solchen umfassenden Simula­tionsmodells, das Strafśenkarten, korrekte Mobilität und Funkausbreitung berücksichtigt, lassen sich darüber hinaus auch verschiedene Umgebungen simulieren, wie z, B, Autobahn-, Stadt­oder Landszenarien, Städte mit homogenen Bebauungsplan (Schachbrettmodell) oder heteroge­ner Bebauung, Weiterhin macht eine solche Simulationsinfrastruktur erst möglich, dass neben des reinen Xetzwerkverhaltens aneli logisehe Effekte auf das Verkehrsverhalten dnreh Inhalte von Xaehriehten beriieksiehtigt werden. So lässt sieh etwa feststellen, ob eine Stauwarnungs- meldnng im VAXET überhaupt den gewiinsehten Effekt auf den Verkehrsfluss hat und wie sieh das Verhalten optimieren lässt, Solehen Fragestellungen wurde in |SDKOS05| naehgegangen.

Intelligente und realitätsnahe Simnlationsmodelle für Verkehrsfluss und Funkwellenausbrei­tung sind wesentliche Eigenschaften, die eine Simnlationsinfrastrnktnr für VAXETs bieten muss. Andernfalls haben die Simnlationsergebnisse nur geringe Aussagekraft, Jedoch bestehen auch in Simulationen Beschränkungen der Möglichkeiten, Bei der Xetzwerksimnlation kommen enor­me Datenmengen auf. Geht man davon ans, dass jeder Knoten in der Simulation konstant 500 KBit/'s Bandbreite ausnutzt, entstehen für jede Minute Simulation und jeden Knoten 3.75 Me­gabyte Datenverkehr, Für 100 Knoten sind dies bereits 375 MB, Möchte man eine Simulation von 15 Minuten Dauer durchführen, entstehen also über 5 GB Daten, Um diese Daten zu ver­arbeiten, müssen sie in den Arbeitsspeicher des Simulationssystems geladen werden, der hier schnell erschöpft ist, Aufśerdem benötigt die Berechnung des Xetzwerkverkehrs zwischen den Knoten im Xetzwerk geraume Zeit, Bereits Simulationen mittlerer Grofśe und Dauer können so mehrere Stunden Bereehnungszeit in Anspruch nehmen. Es zeigt sieh also, dass selbst mit Hilfe von Simulatoren grofśe VAXETs mit mehreren hundert oder tausend Knoten nur schwierig über längere Zeiträume getestet werden können.

Letztlich werden Simulationen der Realität natürlich immer in gewissem Grad naehstehen, weshalb auch Praxistests notwendig sein werden. Der optimale Testablauf für VAXET-Systeme wäre der Weg von der Theorie zur grofsfläehigen Simulation bis hin zum experimentellen Feld­test, So können effizient Erkenntnisse erlangt werden die wieder in Forschung und Entwicklung zuriiekfliefśen können. Auch hybride Simulationen sind denkbar, bei denen ein Teil des Xetz- werks aus echten Fahrzeugen besteht und der Rest des Xetzwerks nur in der Simulation existiert.

3.12 Projekte und Standards

Das Themengebiet der Fahrzeug-zu-Fahrzeug-Kommunikation stößt auf politischer Ebene und in der Automobilindustrie auf großes Interesse, Vor allem die Umsetzung aktiver Sicherheits­systeme zur Reduktion von Verkehrsunfällen, sowie die Optimierung des Verkehrsflusses durch Informationsverbreitungsanwendungen, sind hier antreibende Ideen, Vor diesem Hintergrund wurden und werden große Forschungsprojekte gegründet und gefördert. Federführende Institu­tionen sind dabei die europäische Union sowie die deutsche Bundesregierung, Aber auch in den USA und in Japan wird Forschung in diesem Gebiet betrieben. In |Franz04| wird ein Überblick über eine Reihe internationale Forschungsprogramme gegeben.

Neben den Forschungs- und Entwicklungsaktivitäten sind Standardisierungsbestrebungen von wesentlicher Bedeutung für den Erfolg von Systemen zur Fahrzeug-zu-Fahrzeug-Kommu- nikation. Neben den Softwareschnittstellen zwischen VANET-Systemen in Form von Protokol­len und Anwendungen müssen auch für die Hardware im Fahrzeug offene Standards gefunden werden. Dies betrifft vor allem die Funkhardware, aber auch Sensoren im Fahrzeug, da diese intensiv von VANET-Systemen genutzt werden (vgl, 3.10), Eine klar definierte, einheitliche und offene Architektur von Software- und Hardwarekomponenten wird für VANETs unumgänglich sein, um Fahrzeuge verschiedenster Hersteller und Infrastrukturkomponenten interoperabel zu machen. Einige bedeutende Projekte im Bereich Fahrzeug-zu-Fahrzeug-Netzwerke und Stan­dardisierungsaktivitäten werden im Folgenden kurz vorgestellt.

3.12.1 FleetNet

Das Projekt FleetNet war in den Jahren von 2000 bis 2003 in der Forschung zur Fahrzeug­kommunikation aktiv IFleetNet|, Es wurde vom Bundesministerium für Bildung und Forschung gefördert und Konzerne und Institutionen wie die Daimler Chrysler AG, das Fraunhofer Insti­tut Fokus und die Siemens AG waren Partner des Projektes, Für die Fahrzeug-zu-Fahrzeug- Kommunikation wurden im FleetNet-Projekt unterschiedliche Funksysteme betrachtet: Ein auf UMTS basierendes System von Siemens, Radarsysteme sowie IEEE 802.11 WLAN-Systeme, Da im Laufe des Projektes IEEE 802.11-basierte Funkhardware eine immer stärke Marktdurchdrin­gung erreicht hat, wurde diese Hardware schließlich in den Fokus gerückt. Als Routingverfahren wurden ausschließlich positionsbasierte Algorithmen (vgl, 3.1.5) betrachtet, Integration von In­frastruktur und Internetzugang im Netzwerk waren weitere wesentliche Aspekte der Projektar­beiten, Eine Praxisdemonstration der Forschungsergebnisse wurde durch die Entwicklung von FleetNet Routingeinheiten realisiert, die in eine Flotte von Smart-Fahrzeugen integriert wurde |HFMF03|, Ein wichtiges Arbeitsgebiet im Projekt waren die Routingalgorithmen |FWMH03|, |FM01|. Beibehalten wurde die TCP/IP-kompatible Kommunikation, Eine Zusammenfassung der Projektergebnisse findet sieh in |FFHSS04|.

Als Xaehfolgeprojekt von FleetXet gilt Xetwork On Wheels |XOW|, das seit 2004 aktiv ist. Dieses wird, wie bereits zuvor das FleetXet Projekt, vom Bundesministerium für Bildung und Forschung gefördert. Als Ziel steht hier die Spezifikation einer Kommunikationsplattform im Mittelpunkt, aufśerdem die Entwicklung von Kommunikationsprotokollen zur Übertragung von Sensordaten, Eine Reihe von Arbeiten, die im Rahmen von Xetwork On Wheels entstanden sind |XOW-P|, beschäftigt sieh im Vergleich mit FleetXet mit einer gröfseren Bandbreite an The­men wie Medienzugriff, Gleichberechtigung, Systemarehitektur und Sieherheitsmeehanismen in VAXETs, Als Routingalgorithmen werden weiterhin positionsbasierte Protokolle entwickelt, Xähere Informationen über die konzeptionelle Gestaltung der XOW-Plattform stehen derzeit nicht zur Verfügung.

3.12.2 PReVENT

PReVEXT ist ein Projekt, das von der europäischen Union gefördert wird mit dem Ziel, durch intelligente Fahrerassistenzsysteme die Zahl der Verkehrsunafälle zu reduzieren |PReVEXT|, Das Projekt beschäftigt sieh mit der ganzen Bandbreite der Fahrerassistenz und erarbeitet auch Standards und Spezifikationen, Fahrzeug-zu-Fahrzeug-Kommunikation wird im Rahmen dieses Projektes als Mittel zur Übertragung von Warnmeldungen betrachtet und ist als eigenes Unterprojekt von PReVEXT organisiert |WILLWARX|, Hier gibt es aufśer Arbeiten zu Ein­zelthemen derzeit keine weitergehenden Informationen zu den bisherigen Projektergebnissen.

Ein weiteres Unterprojekt von PReVEXT ist das MAPS&ADAS Projekt |MAPSADAS|, Dieses beschäftigt sieh mit dem Einsatz von digitalen Kartendaten als Sensor für Fahreras­sistenzsysteme, Dazu wurde insbesondere eine Sehnittstellenspezifikation für den generischen Zugriff auf digitale Kartendaten im Fahrzeug erarbeitet. Ebenso bearbeiten die Unterprojekte ProFusionl und ProFusion2 den Zugriff auf wichtige Sensoren im Fahrzeug |PROFUSIOX|, Die übergreifende Bedeutung von Sensoren für Fahrerassistenzanwendungen, die Fusion von Sensordaten sowie der generische Zugriff auf Sensoren wurden erkannt und der konzeptionelle Aufbau von Multi-Sensor-Svstemen wird betrachtet.

3.12.3 Car2Car Communication Consortium

Das Car2Car Communication Consortium ist eine Organisation |C2CC|, die von europäischen Automobilherstellern ins Leben gerufen wurde. Dieses Konsortium beschäftigt sieh auch stärker mit den wirtschaftlichen und politischen Aspekten von Fahrzeug-zu-Fahrzeug-Kommunikation.

Arbeitsfelder umfassen die Standardisierung von Komponenten für die Fahrzeug-zu-Fahrzeug- Kommunikation, um die Interoperabilität zwisehen versehiedenen Fahrzeugherstellern herzu­stellen. Weiterhin wird angestrebt, ein lizenzfreies, dediziertes Frequenzband für die Fahrzeug- zu-Fahrzeug-Kommunikation auf politiseher Ebene für Europa zu erreiehen. Die weltweite Har­monisierung der Standards gehört aueh zu den erklärten Zielen. Die Spezifizierung und Demon­stration von Fahrerassistenzanwendungen auf Basis von VAXETs wird angestrebt. Sehliefślieh werden Gesehäftsmodelle und Strategien zur Einführung von VAXET-Teehnologie im Automo­bilsektor entwickelt. Das Konsortium hat jedoch erst im Juli 2005 die Arbeit aufgenommen und erste Ergebnisse werden laut Zeitplan erst bis Ende des Jahres 2008 erwartet.

3.12.4 IEEE 802.11p WLAN

Die Standardisierung von Funkhardware, die für Fahrzeug-zu-Fahrzeug-Kommunikation opti­miert ist, ist eine der wichtigsten Aufgaben für die praktische Umsetzung von VAXETs. Wie in dieser Arbeit bereits dargestellt wurde, besteht gerade auf der Bitiibertragungs- und Medienzu- griffssehieht grofśes Verbesserungspotential für den Betrieb von VAXETs (vgl. 2.4.1). Ohne einen akzeptierten Standard, der möglichst kompatibel zum bisherigen IEEE 802.11 Funkverfahren ist, drohen jedoch Inkompatibilitäten zwisehen versehiedenen Systemen und hohe Herstellungs­kosten für die Hardware. Eine Lösung dieses Problems könnte die IEEE 802.11p Erweiterung darstellen |IEEE802.11p|. Diese ergänzt die bisherige 802.11 Spezifikation um Funktionen und Eigenschaften für die Kommunikation im Fahrzeugbereieh, Laut der Projektbesehreibung wird insbesondere Fahrzeug-zu-Infrastruktur-Kommunikation (zum Beispiel zur Mautabreehnung) berücksichtigt. Aueh die Einbindung von Schienen- und Wasserfahrzeugen in solche Xetzwerke wird vorgesehen. Das Funkmodul soll dabei bei Bewegungsgesehwindigkeiten von bis zu 200 km/h immer noch zuverlässig Kommunikationsreiehweiten von 1000 Metern erreiehen. Das ver­wendete ISM-Frequenzband liegt im 5.8 und 5.9 GHz Bereich.

Welchen Umfang diese Erweiterung tatsächlich haben wird, lässt sieh derzeit leider nicht ab­sehätzen, da die bisherigen Ergebnisse der Standardisierungsarbeiten nicht frei zugänglich sind und kaum Details über die konkrete Implementierung verfügbar sind. Die Änderungen an der Bitiibertragungs- und Medienzugriffssehieht sollen jedoch nach Voraussetzung des Projekts so gering wie möglich gehalten werden. Andererseits soll der Xotwendigkeit Rechnung getragen werden, dass sehr geringe Latenzen in diesem Umfeld benötigt werden, um die teilweise sehr kurzen Kommunikationsfenster zwisehen Teilnehmern auszunutzen bzw. zeitkritische Kommu­nikation zu ermöglichen. Der Fokus der IEEE 802.11p Erweiterung scheint jedoch nicht auf dezentraler Ad-Hoe-Kommunikation zu liegen, so dass zu befürchten ist, dass der Medienzugriff an dieser Stelle nicht verbessert wird. Inwiefern echtzeitkritische Applikationen vorgesehen sind und evtl, ein eigenständiger Kontrollkanal vorgesehen wird, ist ebenfalls nicht in Erfahrung zu bringen. Da der Standard erst im Jahr 2008 verabschiedet werden soll, werden sieh einige dieser Fragen wohl erst noch im Laufe der Zeit entscheiden.

3.12.5 Protokoll-Standardisierungen

Neben der Standardisierung der Hardware sind auch standardisierte Routing- und Transport­protokolle von Bedeutung für VAXETs, Routingprotokolle werden in der IETF MAXET Wor­king Group seit mehreren Jahren betrachtet und in experimentellen Standards niedergelegt |IMWG|, In diesem Rahmen wurden auch Algorithmen wie AODV, DSR oder GPSR spezifi­ziert, Viele der Vorschläge sind inzwischen verfallen, doch einige Protokolle werden auch stetig verbessert und es gibt immer noch gültige experimentelle RFCs für sie (zum Beispiel DSR und AODV, siehe 3.1), Zu Transportprotokollen sind derzeit keine Standardisierungsaktivitä­ten bekannt. Dies mag darin begründet sein, dass viele Arbeiten zu VAXETs sieh derzeit auf TCP/IP-Kompatibilität beschränken.

4 Aufbau eines Prototypensystems

In den letzten beiden Kapiteln wurden die wesentlichen und iibergreifenden Problemfelder aufgezeigt, die beim Aufbau von VAXETs von Bedeutung sind. Mit Hilfe der daraus gewon­nenen Erkenntnisse wird nun ein System entwickelt, das den flexiblen Aufbau von Prototypen erlaubt. Dieses System soll die Entwicklung und Demonstration von VAXET-Funktionalität vereinfachen und beschleunigen, ohne Einschränkungen bei der Wahl der konkreten Bausteine des Prototypensystems einzuführen. Um dies zu erreichen, werden im Folgenden die konkreten Zielstellungen für dieses System beschrieben. Dann wird aus Ergebnissen aus der Theorie in Kapitel 2 und 3 ein Konzept zum Aufbau eines solchen Systems abgeleitet, Schließlich wird eine konkrete Implementierung des Prototypensystems durchgeführt, ein praktischer Versuchsauf­bau realisiert und die Ergebnisse der praktischen Arbeit vorgestellt.

4.1 Zielstellungen

Das Ziel des praktischen Teils dieser Arbeit ist es, ein System zu entwickeln, das sieh zum Aufbau vielfältiger Prototypen für Versuchsaufbauten und Demonstratoren von Fahrzeug-zu- Fahrzeug-Kommunikation eignet. Dies soll es ermöglichen, einen vollständigen VAXET-Proto- kollstapel in der Praxis zu testen, Testapplikationen sollen umsetzbar sein, die auf einen solchen Protokollstapel aufsetzen. Das Verhalten von einzelnen Xetzwerkschichten als auch die Inter­aktion der Elemente des gesamten Systems soll unter Praxisbedingungen analysiert werden können. Beliebige Konfigurationen des Protokollstapels sollen daher einfach möglich sein. Die Konzeption des Systems soll sieh an den Bedingungen des Produktiveinsatzes im Fahrzeug ori­entieren, Als Plattform für das System ist mobile PC-Hardware, wie Xotebooks oder sogenannte Fahrzeug-PCs in Teilen geeignet. Diese Plattformen bieten hohe Rechenkapazitäten und eine Standard-PC-Plattform für die Softwareentwicklung. Für den dauerhaften Einbau im Fahrzeug kommt jedoch nur ein eingebettetes System in Frage, das mit deutlich geringeren Ressourcen miskommen muss. Die Entwicklung des Prototypensystems wird daher von Anfang an auch auf eingebettete Plattformen und einen gewissen Grad der Plattformunabhängigkeit ausgerichtet.

Als Funkmodul für ein solches System wird IEEE 802.11 WLAX-Hardware vorgesehen, Ei- nerseits kommt diese Hardware den Anforderungen von Fahrzeug-zu-Fahrzeug-Kommunikation am näehsten (siehe 2.3), Andererseits gibt es eine grofśe Auswahl an soleher Hardware und aueh die Treiberunterstützung für versehiedene Betriebsysteme ist bei dieser Hardware am besten. Daher ist die Nutzung von IEEE 802.11-kompatibler Hardware in der Praxis am einfachsten durchführbar. Im Feldtest werden aufgrund von hohen Kosten und Aufwand nicht sehr viele Prototypensysteme am Netzwerk teilnehmen können. Diese Form des Praxistests kann also nur experimentelle Ergebnisse in beschränktem Rahmen zurückliefern, da reale Verkehrssituationen mit einer geringen Teilnehmeranzahl nur bedingt hergestellt werden können. Für erste prakti­sche Tests eines vollständigen Protokollstapels und von Applikationen eignet sieh ein soleher Versuchsaufbau jedoch gut. Insbesondere erlauben Feldtests die experimentelle Überprüfung von Ergebnissen aus der Theorie und der Simulation, so dass hier wertvolle Rückkopplungsin­formationen entstehen. Es soll durch diese Praxistests ein besserer Eindruck von den Anforde­rungen an die Gesamtarchitektur von VANETs enstehen. Weiterhin können so in der Theorie oder Simulation unberücksichtigte Probleme, die im realen Test auftreten, identifiziert werden. Neben der reinen Netzwerkfunktionalität sollte das Prototypensystem daher aueh Mechanismen zur einfachen Analyse und Auswertung von Laufzeitdaten der verschiedenen Netzwerkschich­ten und Applikationen vorsehen. Dies erlaubt es, das Verhalten und die Eigenschaften von Netzwerkprotokollen und deren Interaktion mit anderen Systemkomponenten in der Praxis zu erfassen.

Um die Flexiblität des Testsystems zu gewährleisten, müssen alle Komponenten des VANET- Protokollstapels modular ausgestaltet werden. Eine Festlegung auf bestimmte Routing- oder Transportprotokolle macht keinen Sinn, da noch keine optimalen, endgültigen Protokolle für Fahrzeug-zu-Fahrzeug-Netzwerke feststehen. Hingegen zeigen die Ergebnisse aus Kapitel 3, dass nahezu alle Netzwerkschichten, und damit der gesamte Netzwerkstapel, für VANETs neu im­plementiert werden müssen. Sowohl die Medienzugriffsalgorithmen, Routingalgorithmen und die Transportprotokolle müssen für VANETs angepasst werden. Das System soll es einerseits erlauben, diese verschiedenen Komponenten individuell testen und weiterentwickeln zu können. Andererseits sollen versehiedene Protokolle bzw, Ausprägungen von Protokollen im Kontext ei­nes beliebigen Protokollstapels eingebettet werden können. Dazu müssen die Implementierungen von Komponenten innerhalb des Softwaresystems beliebig austauschbar sein. Die Modifikation von Hardwareelementen sprengt den Rahmen dieser Arbeit, Die Bitübertragungsschicht wird deshalb vom System nicht berücksichtigt, Aueh die Austauschbarkeit von Medienzugriffsalgo­rithmen ist von dieser Beschränkung betroffen. Die Art und der Ort der Implementierung des Medienzugriffsalgorithmus ist abhängig von der konkreten IEEE 802.11 Hardware, Die Me­dienzugriffslogik kann direkt in der Hardware oder im Gerätetreiber auf Betriebsystemebene realisiert sein. Es existiert demnach keine einheitliche Schnittstelle, um den Medienzugriff zu modifizieren. Selbst wenn der Medienzugriff im Gerätetreiber implementiert ist, müssten Än­derungen der Algorithmen im Betriebsystembereich erfolgen, was eine wesentliche Erhöhung der Entwicklungskomplexität mit sieh bringt. Zudem wären die Änderungen auf den jeweiligen Gerätetreiber und das Betriebsystem beschränkt. Aus diesen Gründen umfasst das anvisier­te System nur die Protokollschichten über der Sicherungsschicht (siehe Abbildung 2.5), Um jedoch zu einem späterem Zeitpunkt andere Funkhardware, einen modifizierten Gerätetreiber oder ein anderes Betriebsystem einsetzen zu können, soll das Prototypensystem von diesen plattformabhängigen Komponenten durch eine geeignete Schnittstelle gekapselt sein, so dass deren Austausch ohne unverhältnismäfšigen Aufwand möglich ist.

4.2 Konzeption

4.2.1 Grundlegende Architektur

Ein generischer Protokollstapel, der alle Formen von MAXETs ermöglicht, ist kaum zu reali­sieren |XKSW02|, Dies trifft insbesondere auf Routingprotokolle zu, die sieh sehr unterschied­lich für grofśe oder kleine, hoch oder gering mobile MAXETs eignen, VAXETs als Spezialform von MAXETs weisen jedoch darüber hinaus sieh zur Laufzeit verändernde Eigenschaften auf. In VAXETs können Situationen zwischen geringer Mobilität und hoher Knotendichte (Stau, Stadtverkehr) und hoher Mobilität und geringer Knotendichte (Autobahn, Xachts) auftreten. Daher lassen sieh für die Xetzwerkschichten in VAXETs (insbesondere Medienzugriff- und Rou­tingprotokolle) ggf, gar keine einzelne Implementierung finden, die sieh für alle Bedingungen gut eignet. Es besteht also die Möglichkeit, dass verschiedene Implementierungen der Protokoll­Schichten abhängig von den Xetzwerkbedingungen eingesetzt werden müssen. Des weiteren gibt es viele Parameter, die entweder einmal festgelegt oder gemäfš einer geeigneten Logik an die Laufzeitbedingungen angepasst werden müssen. Zu diesen Parametern gehören z, B, die Sende­intervalle des Xachbarschaftsprotokolls, Hop-Grenzen für Routing und netzweiten Rundfunk, die Steuerung von Übertragungsstärke und -richtung beim Einsatz von intelligenten Antennen, sowie weitere Parameter, deren Präsenz abhängig von den eingesetzten Xetzwerkprotokollen ist. Solche Parameter haben direkten Einfluss auf die Stabilität und Skalierbarkeit des gesamten VAXETs in verschiedenen Situationen.

Wie sieh in den Kapiteln 2 und 3 gezeigt hat, benötigt ein VAXET-Protokollstapel umfas­sende Schnittstellen zwischen den Xetzwerkschichten, damit jede individuelle Schicht korrekte Entscheidungen fällen kann, Daten die für fast jede VAXET-Protokollsehieht von Bedeutung sind, sind zum Beispiel die aktuelle Knotendichte in der lokalen Umgebung, die Liste der akti- ven Xaehbarknoten oder Charakteristiken des Fnnkkanals und damit die Erfolgswahrseheinlieh- keit von Datenübertragungen, Rontingprotokolle müssen die Anforderungen der Applikationen beziiglieh Priorität, Dienstgüte, Gleiehbereehtignng etc. kennen und auch mit den anderen Xetzwerksehiehten über diese Parameter verhandeln können, da die Erfüllung der Dienstgüte zum Beispiel auch von den Gegebenheiten beim Medienzngriff abhängt. Das Transportprotokoll hingegen benötigt Rückmeldungen über Ursachen von Zeitüberschreitungen von Bestätigungs­paketen und fehlerhaften Übertragungen von den tieferen Schichten, Gründe hierfür können zum Beispiel eine unterbrochene Route, schwieriger Medienzngriff oder Überlastung des Xetz- werks sein. Bei Einsatz von Informationsverbreitnngsanwendnngen können Xetzwerksehiehten Entscheidungen zur Behandlung von Xetzwerkverkehr auch nicht immer eigenständig fällen, sondern benötigen Unterstützung durch das Wissen und die Logik der zugehörigen Applikatio­nen (in-network processing, siehe 3.10), Sehliefślieh bringen VAXETs gänzlich neuartige Elemen­te mit sieh, die in konventionellen Xetzwerken nicht Vorkommen, Das Xaehbarsehaftsprotokoll etwa stellt eine Komponente dar, die keiner der Schichten ans dem OSI-Referenzmodell eindeu­tig zngeordnet werden kann. Die erweiterten Rundfunktechniken wie netzweiter Rundfunk oder geographischer Rundfunk sind auch nicht mehr als elementare Funktionen der Siehernngssehieht kategorisierbar. Die starke Verknüpfung der Xetzwerksehiehten mit externen Sensordaten wie der Fahrzengposition oder digitalen Kartendaten stellt ebenso ein Xovum dar.

Es ist ans diesen Gründen ersichtlich, dass die Mechanismen, die ans TCP/IP und dem OSI- Referenzmodell bekannt sind, nicht ohne weiteres auf ein VAXET-System übertragen werden können, |FTmTFH05| erkennt dies und leitet ans den Anforderungen von VAXETs die Xot- wendigkeit ab, eine nene Systemarehitektnr für die Organisation der Xetzwerkkomponenten zu finden, die diesen Umständen gerecht wird. Zunächst wird dazu der klassische Ansatz gemäfs dem OSI-Sehiehtenmodell betrachtet (Abbildung 4.1 (a)). Bei diesem Ansatz existieren klar definierte Schnittstellen zwischen den jeweils benachbarten Schichten, Zugriff auf externe In­formationen wie Sensordaten müsste in diesem Fall für jede Schicht individuell geschehen, was Inkonsistenzen verursachen kann, da keine einheitliche Schnittstelle und Sieht auf die Sensor­daten besteht. Eine Schicht kann hier Daten mit nicht direkt benachbarten Schichten nicht austausehen, sondern die Kommunikation bzw, die Daten müssten durch die dazwischenliegen­den Xetzwerksehiehten durehgereieht werden. Ein starker Gegensatz zum OSI-Sehiehtenmodell ist eine vollständig schichtlose Struktur (Abbildung 4.1 (b)), Funktionen werden in diesem Fall nicht mehr einzelnen Schichten zugeteilt, sondern alle Komponeten liegen auf derselben Ebene als Module vor. Die Schnittstellen zwischen diesen Modulen sind nahezu beliebig und ermögli­chen eine hohe Flexibilität, Dadurch lässt sieh eine hohe Interaktion zwischen den verschiedenen Komponenten, sowie ein gemeinsamer Zugriff auf externe Daten und Dienste herstellen. Die Au- toren von |FTmTFH05| sehen diesen Gegenvorschlag jedoch als zu komplex an, da die gesamte Xetzwerkfunktionalität in einem monolithischen System zusammengefasst werden muss. Ein sol­ches System kann zwar einmalig realisiert werden, die Verschränkungen zwischen den Modulen sind jedoch so groß, dass der Austausch einer logisch zusammenhängenden Xetzwerkkomponen- te, wie im Schichtenmodell, nicht mehr ohne weiteres möglich wäre. Auch sind die Datenpfade bei einer solchen Architektur nicht mehr so leicht nachvollziehbar. Als Mischlösung wird hin­gegen ein Modell vorgeschlagen, das prinzipiell dem OSI-Schichtenmodell nachempfunden ist, jedoch im Gegensatz zu diesem auf jeder Xetzwerkschicht zusätzlich eine direkte Schnittstelle zur Applikationsschicht ermöglicht. Damit hat weiterhin jede Schicht definierte Schnittstellen zu anderen Schichten, Es entsteht dadurch ein Stufenmodell im Gegensatz zum reinen Schich­tenmodell bei OSI (Abbildung 4.1 (e)). Der Datenfluss bleibt dabei weiterhin vertikal durch die Xetzwerkschichten und klar abgegrenzte Xetzwerkschichten bleiben bestehen, Xeben der Erweiterung des Schichtenmodells zum Stufenmodell wird eine Datenverbindungsschicht ein­geführt, die externe Sensordaten zusammenführt und den Xetzwerkschichten eine gemeinsame Schnittstelle auf diese anbietet. Schließlich ist noch eine Verwaltungsschicht vorgesehen, die langfristige und übergreifende Parameter des VAXET-Svstems zur Laufzeit kontrollieren und an die Betriebsbedingungen adaptieren soll.

Die Erweiterung des Schichtenmodells zu einem Stufenmodell kommt zentralen Eigenschaf­ten von VAXETs entgegen. Die Applikationsschicht kann so gezielt mit einer tieferen Xetz­werkschicht kommunizieren und Anfragen müssen nicht mehr durch alle Schichten durchge­reicht werden, Anwendungen können so besser Einfluss auf die Verarbeitung von Paketen im Protokollstapel nehmen, was in einem hochdynamischen VAXET von Vorteil ist. Eine Appli­kation kann bei diesem Modell zum Beispiel ihre individuellen Pakete direkt an die Sicherungs­schicht senden bzw, von dieser abgreifen. Dies ist sinnvoll, wenn die Applikation eine spezielle Logik umsetzen muss, die die regulären Xetzwerkstufen nicht zur Verfügung stellen können. Ein normales Datenpaket hingegen durchläuft den herkömmlichen Pfad durch alle Xetzwerk­schichten. Informationsverbreitungsanwendungen profitieren von einer solchen Architektur, da sie so direkt Rundfunkpakete versenden können und die hierfür nicht benötigte Vermittlungs­und Transportschicht umgangen werden kann, Infotainmentanwendungen hingegen erhalten die Möglichkeit, direkt mit der Vermittlungsschicht über Dienstgüteanforderungen zu verhandeln, |SFTE06| führt den in |FTmTFH05| vorgestellten Ansatz weiter aus und zeigt die Xotwendig- keit der Interaktion zwischen Applikationen und tieferen Xetzwerkschichten am Beispiel der Informationsverbreitung auf.

Die klar definierten Schnittstellen des OSI-Referenzmodells werden durch das Stufenmodell erweitert, aber bleiben bestehen. So bleibt die Möglichkeit erhalten, einzelne Schichten ohne großen Aufwand auszutauschen. Eine gemeinsame Schnittstelle auf externe Daten ist eben­so sinnvoll, um eine konsistente Sieht auf Sensordaten für alle Schichten zu realisieren. Die aus diesem Modell entstehenden flexibleren Schnittstellen und die gleichzeitige Beibehaltung der klaren Trennung zwischen logischen Xetzwerkschichten scheint gut als Grundlage für das geplante Prototypensystem geeignet. Deshalb wird im Folgenden eine auf dieser Grundidee aufbauende Xetzwerkarehitektur entwickelt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4.1: Darstellung möglicher Netzwerkarchitekturen

Da das anvisierte Prototypensystem dafür vorgesehen ist, zahlreiche verschiedene Protokolle und Applikationen zu testen und weiterzuentwickeln, gibt es außerdem Sinn, den Gedanken eines Rahmenwerks in die Softwarearchitektur zu transportieren. Dieser Gedanke wird auch in |XKSW02| aufgegriffen — allerdings beschränkt auf die Entwicklung von Routingprotokollen. Die Idee eines Rahmenwerks ist es, dass gemeinsam und häufig benötigte Funktionalität ver­schiedener Module in einem System generisch von einem Rahmenwerk zur Verfügung gestellt werden. Dies umfasst etwa typische Datenstrukturen wie Wartesehlagen, Listen und Tabel­len, die von vielen Modulen gleichermaßen benötigt werden. Auch der Umgang mit Xetzwerk- adressen, Bitoperationen auf Protokollebene, Speieherverwaltung, Stoppuhren usw, sind immer wieder auftretende Funktionen, die über alle Xetzwerkkomponenten hinweg eingesetzt werden müssen. Auch komplexere Algorithmen, wie etwa die Umsetzung eines generischen Xaehbar- sehaftsprotokolls für Routingalgorithmen, können von einem Rahmenwerk zur Verfügung ge­stellt werden. Der Vorteil solcher gemeinsam von allen VAXET-Komponenten genutzten Soft­wareteile ist, dass einerseits die Entwicklungszeit für neue Algorithmen reduziert wird, da diese Elemente nicht für jede Komponente erneut entwickelt werden müssen. Weiterhin steigt da­durch auch die Zuverlässigkeit des Systems, da Funktionalität nicht mehrfach implementiert werden muss und damit weniger Fehler auftreten und die Qualität der gemeinsam genutzten Programmteile steigt. Für die Umsetzung des Prototypensystems wird deshalb die Berücksich­tigung eines solchen Rahmenwerks vorgesehen.

4.2.2 Softwaremodell

In diesem Abschnitt wird das konkrete Softwaremodell für das Prototypensystem vorgestellt. Da das Prototypensystem zunächst nur die Grundlage für konkrete Implementierungen von Protokollstapeln und Applikationen sein soll, wird die entstehende Software in zwei aufeinan­der aufbauende Ebenen unterteilt. Die untere Ebene gibt die Systemarehitektur und generische Komponenten vor, ohne Annahmen über die tatsächlich verwendeten Protokolle, Applikationen, das Betriebsystem oder die Hardware zu treffen. Dies beinhaltet insbesondere die Elemente des beschriebenen Rahmenwerks, sowie die Definition von abstrakten Schnittstellen zwischen den abstrakten Softwarekomponenten. Die zweite, höhere Ebene stellt die Implementierung eines Prototypensystems dar, welches alle Komponenten des Systems in einer konkreten Ausprägung, mit Hilfe des von der unteren Ebene bereitgestellten Rahmenwerks, sowie der Schnittstellenspe­zifikationen, implementiert. So soll die Schnittstellenspezifikation und generische Komponen­ten auf der unteren Ebene vollständig von der individuellen Implementierung von Elementen des VANET-Systems auf der höheren Ebene getrennt werden, was die Austauschbarkeit der Systemkomponenten sicherstellt. Die untere Ebene bildet somit die Basis für beliebige Kon­figurationen von VANET-Systemen. Diese Ebene wird im Folgenden als VANET Prototyping Framework (VPF) bezeichnet, während die Implementierungsebene mit VANET Prototyping System (VPS) benannt wird (siehe Abbildung 4.2).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4.2: Unterteilung der Softwarearchitektur in zwei Ebenen (VPF und VPS)

In Abbildung 4.3 ist die detaillierte Softwarearchitektur des VPF dargestellt. Die Kernelemen­te die im letzten Abschnitt identifiziert wurden, sind in dieses Modell eingeflossen. Dies äußert sich durch die Erweiterung des OSI-Schichtenmodells zu einem Stufenmodell. Den Hauptteil des VPF stellt die grün gefärbte Schicht dar. Das VPF setzt einen zentralen Datenspeicher um, in dem Sensordaten und andere systemübergreifende Datenstrukturen abgelegt werden. Das Rahmenwerk stellt generische Algorithmen und Datenstrukturen zur Verfügung, die zur Implementierung von Netzwerkkomponenten genutzt werden können. Des weiteren spezifiziert das VPF Schnittstellen für alle Komponenten des Systems. Da die Sicherungsschicht wie oben beschrieben nicht modifiziert werden kann, setzt das System erst auf dieser auf. Es wird da­von ausgegangen, dass das Betriebsystem eine abstrakte, hardwareunabhängige Schnittstelle anbieten kann, die den direkten Zugriff auf den IEEE 802.11 Gerätetreiber ermöglicht, um Pakete von der Sicherungsschicht zu empfangen und auch direkt an diese zu senden. Diese Funktionalität wird auf der zweiten Schicht des VPF durch eine plattformunabhängige Geräte­treiberschicht nochmals abstrahiert, um Unabhängigkeit vom Betriebsystem zu erreichen. Alle blau gefärbten Schichten in Abbildung 4.3 werden im VPF nur als abstrakte Schnittstellen vorgesehen. Die Gerätetreiberschnittstelle sieht auch zahlreiche Methoden vor, um Parameter der IEEE 802.11 Hardware zu beeinflussen. Die Sicherungsschicht kann zwar nicht direkt ver­ändert werden, da jedoch eine direkte Schnittstelle zum Gerätetreiber existiert, kann immerhin eine Erweiterung der Sicherungsschicht vorgenommen werden. Diese Erweiterungen können auf der Kontrollschicht des VPF einfließen, Mögliche Maßnahmen, die auf dieser Schicht getroffen werden könnten, sind Algorithmen zur Fragmentierung oder Zusammenfassung von Paketen, Je nach Charakteristik des Funkkanals kann es sinnvoll sein, große Pakete in kleinere zu stückeln oder kleine Pakete zu größere Paketen zusammenzufassen, um den Medienzugriff zu optimieren. Die Pakete können dann in dieser veränderten Form an die Gerätetreiberschnittstelle übergeben werden. Es besteht jedoch aus Sieht des VPF kein Wissen darüber, in welcher Form der Geräte­treiber die auf diese Weise erhaltenen Pakete seinerseits behandelt. Da im Gerätetreiber bereits Fragmentierung gemäß IEEE 802.11 vorgenommen wird, ist es schwierig zu sagen, wie sinnvoll solche Erweiterungen sind und wie sie sieh beim Einsatz unterschiedlicher Funkhardware und Gerätetreiber auswirken.

Um den Anforderungen von VAXETs Rechnung zu tragen, wird eine eigene Rundfunkschicht als erste Xetzwerkschicht über der Kontrollschicht vorgesehen. Diese Rundfunkschicht kann erweiterte Rundfunktechniken realisieren, wie sie in 2.4.5 definiert sind. Für Xicht-Rundfunk- pakete reicht diese Schicht die Pakete einfach weiter an die tiefere bzw, höhere Schicht, Die nächsten beiden Schichten, die Vermittlungs- und Transportschicht, entsprechen den konven­tionellen Schichten aus dem OSI-Referenzmodell, Gemäß dem Stufenmodell kann die Applika­tionsschicht auf jede beliebige tiefere Schicht direkt zugreifen. Eine Informationsverbreitungs­anwendung zum Beispiel könnte direkt mit der Rundfunkschicht kommunizieren, da für diese Anwendungskategorie keine bidirektionalen Verbindungen benötigt werden.

Als neue konzeptionelle Komponente wurden Netzwerkagenten in die Architektur des VPF aufgenommen. Bei Xetzwerkagenten handelt es sieh um eine besondere Form von Applikationen, die integraler Bestandteil des Protokollstapels sind. Dies äußerst sieh dadurch, dass Xetzwerk­agenten Dienste für den Protokollstapel zur Verfügung stellen bzw, ausführen. Ein Beispiel dazu ist etwa das Xachbarschaftsprotokoll. Die Xachbarschaftstabelle ist eine elementare Datenstruk­tur, die für nahezu alle Schichten des Xetzwerkstapels von Bedeutung ist. Deshalb sieht das Softwaremodell nicht vor, dass das Xachbarschaftsprotokoll einer Xetzwerkschicht zugeordnet wird. Dies wäre unpassend, da das Xaehbarsehaftsprotokoll nicht für eine einzelne Schicht zu­ständig ist und auch nicht am regulären Paketfluss des Xetzwerkstapels teilnimmt, Stattdessen agiert das Xaehbarsehaftsprotokoll proaktiv, wie eine Applikation, Aus diesem Grund werden Xetzwerkagenten als privilegierte Applikationen betrachtet, die wichtige Dienste für das Ge­samtsystem zur Verfügung stellen. Genau wie Applikationen haben Xetzwerkagenten ebenfalls auf alle anderen Xetzwerksehiehten Zugriff, Zusätzlich erhalten sie schreibenden Zugriff auf den Datenspeicher des VPF, Am Beispiel eines Xaehbarsehaftsprotokollagenten zeigt sieh hier der Vorteil eines gemeinsamen Datenspeichers im VPF-System: Der Agent kann eine zentral zugreif­bare Xaehbarsehaftstabelle pflegen, auf die jede andere Xetzwerksehieht lesend zugreifen kann, so dass eine saubere, definierte Schnittstelle auf Xaehbarsehaftsinformationen von jeder Stelle des Systems aus existiert. Ein weiterer denkbarer Xetzwerkagent wäre ein Sieherheitsagent, der als beobachtende Instanz Einbruehserkennung durchführt. Der Vorteil der Implementierung als Xetzwerkagent ist hier, dass der Agent von der lokalen Sichtweise einer Xetzwerksehieht los­gelöst ist und sieh übergreifend um die Systemsieherheit kümmern kann, indem er mit jeder einzelnen Xetzwerksehieht sieherheitsrelevante Informationen austauseht. Auch ein Hardware­agent ist ein Beispiel für einen Xetzwerkagenten, Dieser könnte die IEEE 802.11 Parameter des Gerätetreibers sowie Kanaleigensehaften überprüfen und anpassen, so dass die optimale Funktion des Systems gewährleistet wird, Abbildung 4.5 stellt einige Beispiele für Xetzwerk­agenten und deren Interaktion mit dem Protokollstapel dar. Die Xetzwerkagenten machen die in |FTmTFH05| (Abbildung 4.1) vorgesehene Verwaltungssehieht obsolet. Durch das generische Konzept von Xetzwerkagenten können beliebige solche Funktionalitäten umgesetzt werden, die systemweite Parameter verwalten. Die dienstorientierte Architektur mit Xetzwerkagenten ist für VAXETs eher geeignet. Sie erlaubt die flexible Konfiguration von Agenten für jede VPS- Implementierung, VAXETs benötigen mehrere dieser Dienste, die eng mit dem Xetzwerkstapel Zusammenarbeiten müssen, so dass hier eine statische Architektur mit einer Verwaltungssehieht zu wenig Flexibilität bieten würde.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4.3: Softwarearchitektur des Prototypensystemes (VPF)

Das VPF übernimmt auch die Rolle der Datenverbindungssehieht, die in |FTmTFH05| vorge- sehlagen wurde. Um die Anbindung der Sensoren an das System zu ermöglichen, ist pro Sensor ein eigenes, systeminternes Modul vorgesehen. Da Sensoren unterschiedlichste Schnittstellen haben können, lässt sieh hier keine generische Schnittstelle nach aufśen Umsetzern Stattdessen wird innerhalb des Systems eine fixe Schnittstelle eingeführt, die das Format z, B, für digitale Kartendaten oder GPS-Informationen vorgibt. Ein Sensormodul ist dann dafür zuständig, die Daten von einem konkreten Sensor abzufragen und in das vom VPF vorgegebene Format umzu­setzen, Dies erlaubt es, für das System transparent, verschiedene GPS-Empfänger an das System anzubinden, die über Bluetooth, die serielle Schnittstelle oder andere Wege angesproehen wer­den und unterschiedliche Übertragungsformate kennen. Für jeden konkreten GPS-Sensor muss lediglich ein Sensormodul im VPS implementiert sein, das mit diesem umgehen kann. Das Sen­sormodul bringt die GPS-Informationen in das vom VPF spezifizierte Format und schreibt die resultierenden Daten in den gemeinsamen Datenspeicher des Systems, Von dort können nun alle anderen Komponenten des VPS die aktuelle Fahrzeugposition abfragen.

Eine weitere externe Schnittstelle, die im VPF vorgesehen ist, ist die Interprozesskommuni­kation zu externen Verwaltungs- und Steuerungswerkzeugen, Da der Protokollstapel als solcher ein autonomes System darstellt, auf das man zur Laufzeit keinen unmittelbaren Einfluss hat, gibt es Sinn, externe Programme nutzen zu können, um zur Laufzeit das Verhalten des Sta­pels zu beeinflussen, Parameter zu verändern oder Informationen abzufragen. Auch statistische Daten können auf diesem Weg abgefragt werden, wie die Anzahl der verarbeiteten Pakete auf den verschiedenen Schichten, der Datendurehsatz, Latenzzeiten, Routingtabellen etc. Da diese Werkzeuge individuell für das System entwickelt werden, kann hier eine zentrale Schnittstelle vorgesehen werden, an der sieh alle externen Programme orientieren müssen. Die konkrete Form der Interprozesskommunikation wird im VPF offen gelassen, um keine unnötigen Abhängigkei­ten einzuführen. Lediglich das Format der auszutauschenden Nachrichten wird vorgegeben. Der Aufruf eines Moduls zur Interprozesskommunikation wird in der Hauptschleife der Kon- trollschicht vorgenommen. Das Kommunikationsmodul setzt die Anfragen bzw, Kommandos der externen Prozesse um, indem es die von externen Programmen empfangenen Nachrichten an den richtigen Empfänger im Protokollstapel weiterleitet. Ein Überblick über die externen Schnittstellen im VPF wird in Abbildung 4.4 gegeben.

Da ein Protokollstapel eine anspruchsvolle und komplexe Software darstellt, muss darauf ge­achtet werden, dass klare Datenflüsse und Aufrufketten im System stattfinden, da sonst diese Komplexität nur noch schwierig beherrscht werden kann, Aufśerdem muss der Protokollstapel gleichzeitig in der Lage sein, eine grofśe Zahl von Paketen in sehr kurzer Zeit zu verarbeiten, um die Kapazitäten der zu Grunde liegenden Hardware voll ausnutzen zu können. Hierbei handelt es sieh tendentiell um konträre Ziele, Da es sieh beim VPF um ein Prototypensystem handelt und IEEE 802.11 vergleichsweise geringe Datenraten im Vergleich zu kabelbasierten Netzwerk­en aufweist, wurde die Architektur stärker auf Programmqualität und -Sicherheit ausgerichtet als auf Leistungsfähigkeit, Besonders da das Prototypensystem dazu dienen soll, permanent Änderungen an der Implementierung des Protokollstapels vorzunehmen, ist eine auf Stabilität ausgelegte Softwarearchitektur von hoher Bedeutung, um den Entwicklungsaufwand zu redu­zieren, Deshalb wurde auf eine strikte Definition von Schnittstellen zwischen den Komponenten im VPF und einen hohen Grad der Abstraktion Wert gelegt.

Das gesamte Prototypensystem ist zur Implementierung in einem einzelnen Prozess im Be-nutzerbereich (engl. Userspace) des Betriebsystems vorgesehen. Bezüglich der Paketverarbei­tung im Protokollstapel wurde das Softwaremodell an die Architektur des μΐΡ Protokollstapels angelehnt [Dunkels2003], [UIP-ΜΑΝ]. Der μΐΡ Protokollstapel ist eine sehr schlanke Implemen­tierung von TCP/IP, die für den Einsatz auf eingebetteten 8-Bit-Systemen vorgesehen ist, die starke Beschränkungen bei Speicher- und Rechenkapazität haben. Ein Aspekt von μΐΡ, der für das VPF übernommen wurde ist, dass für den gesamten Protokollstapel (abgesehen von Appli­kationen und Netzwerkagenten) nur ein Ausführungsstrang (engl. Thread) zum Einsatz kommt. Dieser geht von der Hauptschleife auf der Kont rollschicht aus. In der Hauptschleife wird der Gerätetreiber auf neu eingegangene Pakete abgefragt und Sendewünsche der höheren Schichten werden erfüllt. Dazu verwaltet die Hauptschleife bzw. Kontrollschicht eine eigene Warteschlange für ausgehende Pakete, deren Inhalt regelmäßig an den Gerätetreiber übergeben wird. Wird ein Paket empfangen, wandert dieses im selben Ausführungsstrang im Protokollstapel nach oben, bis zur Applikation. Dies bedeutet, dass es für die Applikationen keine abstrakte Schnittstel­le zur Interprozesskommunikation mit dem Protokollstapel, wie etwa Sockets, gibt. Deshalb müssen Applikationen gegen das VPS gelinkt werden und können nicht als eigenständige Pro­gramme ausgeführt werden. Dies schafft natürlich eine starke Bindung der Applikationen an das VPS, was im Rahmen eines Prototypensystems jedoch hinnehmbar ist. Um die Umsetzung von Applikationen zu erleichtern und diesen mehr Eigenständigkeit zu ermöglichen, erhalten diese im Gegensatz zum /dP-Konzept einen eigenen Ausführungsstrang. Beim Versenden von Paketen wandert daher der Ausführungsstrang der Applikation bis hinunter zur Kontrollschicht, wo die Pakete in die Warteschlange übergeben werden. Der Ausführungsstrang des Protokollstapels übernimmt dann die Übergabe der Pakete aus der Warteschlange an den Gerätetreiber. Beim Empfangen hingegen verläuft eine Aufrufkette im Ausführungsstrang des Protokollstapels von der Kontrollsehieht bis zur Applikationssehieht, Der Aufruf in die Applikationssehieht sollte nur dazu dienen, die empfangenen Daten in einem Applikationsspeieherbereieh abzulegen. Die eigentliche Verarbeitung sollte der Ausführungsstrang der Applikation vornehmen, damit keine grofśen Verzögerungen bei der Paketverarbeitung auf dem Protokollstapel auftreten, Xeben den Applikationen erhalten naturgemäfs auch Xetzwerkagenten einen eigenen Ausführungsstrang, Sensormodule können optional einen eigenen Ausführungsstrang erhalten — sie könnten aber auch regelmäfsig von der Kontrollsehieht aus aufgerufen werden, um neue Sensordaten abzu­fragen, Bei umfangreichen Sensordaten kann auch hier ein eigener Ausführungsstrang für das zuständige Sensormodul von Vorteil sein.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4.4: Übersicht über Schnittstellen des VPF

Da Applikationen im VPF ein integraler Bestandteil des Xetzwerkstapels sind, haben sie Zugriff auf viele systeminterne Datenstrukturen und Methoden, die nur für tiefere Xetzwerk- sehiehten vorgesehen sind. Hier muss die Konvention gelten, dass Applikationen nur die vorge­sehenen Schnittstellen zu tieferen Schichten nutzten. Insbesondere darf auch kein schreibender Zugriff von Applikationen auf den globalen Datenspeicher stattfinden. Dies soll aussehliefślieh den tieferen Xetzwerksehiehten und Xetzwerkagenten erlaubt sein, die aufgrund ihrer Aufgabe im VAXET-System auch globale Datenstrukturen anlegen oder verändern dürfen. Die typischen Kommunikationswege beim Betrieb eines VPS sind von Bedeutung, um die Verarbeitungswe­ge besser zu verstehen. Wie die Paketflüsse im VPF-Protokollstapel vorgesehen sind, ist in Abbildung 4.6 illustriert. Dort ist auch ersichtlich, dass auf jeder Schicht im Protokollstapel entschieden werden muss, ob das Paket an die nächsthöhere Xetzwerksehieht oder direkt an eine Applikation bzw, einen Xetzwerkagenten geliefert werden soll. Dies resultiert direkt aus dem Stufenmodell, das hier Anwendung findet. Das heilst, dass jede Xetzwerksehieht ein (De-) Multiplexverfahren anwenden muss, um Pakete zum richtigen Empfänger zuordnen zu kön­nen, In konventionellen Xetzwerkstapeln wird dies üblicherweise nur auf der Transportsehieht durehgefiihrt, weil dort nur diese eine direkte Schnittstelle zur Applikationssehieht hat.

Das in diesem Abschnitt vorgestellte Softwaremodell erlaubt die Realisierung eines flexiblen Protokollstapels für VAXETs im Benutzerbereieh des Betriebsystems, Dabei müssen keine we­sentlichen Xachteile bei der Stabilität, Funktionalität oder Effizienz des Xetzwerkstapels hin­genommen werden. Das Modell ist in zwei Ebenen aufgeteilt von denen eine implementierungs­unabhängige Programmteile und Sehnittstellenspezifikationen enthält. Die andere Ebene stellt, auf die erste Ebene aufbauend, die konkrete Konfiguration und Implementierung eines Pro­totypensystems zur Verfügung, Dies erlaubt es einer so tief im System verankerten Software, eine dennoch relativ hohe Unabhängigkeit vom Betriebsystem und der Funkhardware zu er­reichen, sowie die Austauschbarkeit von Systemkomponenten sieherzustellen. Die Erweiterung des Sehiehtenmodells zum Stufenmodell entspricht den Gegebenheiten in VAXETs besser und ermöglicht den Applikationen deutlich mehr Einfluss auf die Verarbeitung im Protokollstapel, Ein gemeinsames Rahmenwerk und ein globaler Datenspeicher als Basis fiir Implementierungen von Systemkomponenten beschleunigt die Entwicklung und erlaubt einfachen und definierten Zugriff auf zentrale Datenstrukturen. Die Einführung einer eigenen Rundfunkschicht und von Xetzwerkagenten erlaubt die logisch korrekte Einordnung von VAXET-spezifischen Komponen­ten in den Protokollstapel, Das Konzept zur Anbindung beliebiger Sensoren an das Prototy­pensystem und die Interprozesskommunikation mit externen Verwaltungsprogrammen bieten weiterhin definierte Schnittstellen nach aufśen. Schließlich hilft das Schema von Netzwerkagen­ten, viele neuartige, systeminterne Dienste, die in VAXETs benötigt werden, auf einfache Art und Weise in das System zu integrieren.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4.5: Konzept der Netzwerkagenten im VPF

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4.6: Paketflussmodell im VPF

4.3 Implementierung

Um das vorgestellte Softwaremodell in die Praxis umzusetzen, wird das VPF mit allen in Ab­bildung 4.3 dargestellten generischen Systemkomponenten und abstrakten Schnittstellen im­plementiert, Für das VPS ist eine einfache Konfiguration und Implementierung des Systems gewählt worden, bei der die Vermittlungs- und Transportsehieht ausgelassen sind, um den Ent- wieklungsaufwand gering zu halten, Stattdessen ist dieses VPS auf die Entwicklung von Infor­mationsverbreitungsanwendungen ausgerichtet, welche diese beiden höheren Schichten ohnehin nicht benötigen. Zur Demonstration aller Elemente des Softwaremodells wird ein Sensormodul, ein Xetzwerkagent und ein einfaches, externes Steuerungswerkzeug realisiert. Als Testapplika­tion ist eine Radarsehirmanwendung vorgesehen (siehe 2.1.1).

Für die Implementierung dieses Systems wurde die Programmiersprache C gewählt. Diese bietet einerseits die notwendige Plattformunabhängigkeit und andererseits ausreichend Struk­turierungselemente, um die Logik des Softwaremodells umzusetzen. Weiterhin ermöglicht C auch die Speicher- und laufzeiteffiziente Programmierung, die für einen Protokollstapel unum­gänglich ist. Da das Prototypensystem auch auf eingebetteter Hardware lauffähig sein soll, ist die weite Verbreitung von geeigneten Compilern auf verschiedensten Plattformen ein weiteres Argument für die Wahl dieser Sprache.

4.3.1 VANET Prototyping Framework

Das Rahmenwerk des VPF umfasst für diese erste Implementierung Klassen zur Behandlung von MAC-Adressen, Erzeugung von Ausführungssträngen, Logausgabe auf Konsole und Datei­en, Dateibearbeitung, Entwurfsmuster wie Singletons (Einzelstücke) und Mutexe, Datenstruk­turen zur Paketverwaltung, GPS-Informationen oder Xachrichtenformate zur Interprozesskom­munikation sind ebenso im VPF spezifiziert. Die in Abbildung 4.3 definierten Schnittstellen für die verschiedenen Xetzwerkschichten, Xetzwerkagenten und Sensormodule sind als virtuelle, abstrakte Basisklassen realisiert worden, von denen eine konkrete Implementierung später im VPS erben muss.

Der globale Datenspeicher des VPF besitzt Schnittstellen für Positionsinformationen und eine Xachbarschaftstabelle. Darüber hinaus gibt es auch noch einen globalen Objektspeicher, der alle zentralen Objekte des VPF-Systems enthält. Über diesen Objektspeicher kann auf jede Komponente des Systems einfach zugegriffen werden. In Tabelle 4.1 ist beispielhaft die gene­rische Datenstruktur für GPS-Positionsdaten dargestellt. Sie enthält eine Datenschnittmenge, die jeder GPS-Sensor liefern können sollte. Dazu gehören der Längen- und Breitengrad sowie die Bewegungsrichtung und -geschwindigkeit als Gleitkommazahlen, Das Attribut valid gibt in Form eines booleschen Wertes an, ob die Empfangsqualität beim Empfangen dieser Positionsda­ten hinreichend war oder nicht. Der zusammengesetzte Datentyp GPSTime enthält schließlich noch einen Zeitstempel, der angibt, wann die Position empfangen wurde. Diese Datenstruktur orientiert sieh am minimalen Datensatz des XMEA 0183 Formats (National Marine Electronics Association), welches viele GPS-Empfänger unterstützen. Das VPF definiert diese Datenstruk­tur und entsprechende abstrakte Schnittstellen, an die sieh ein konkretes GPS-Sensormodul halten muss. Egal in welchem Format der konkrete GPS-Empfänger also seine Informationen liefert, dass Sensormodul muss diese Daten in das Format gern, Tabelle 4.1 bringen. Eine Liste solcher GPS-Datensätze befindet sieh im globalen Datenspeicher des VPF, In dieser Liste wird eine Reihe der letzten GPS-Positionen inklusive der aktuellsten GPS-Position abgelegt. Da­durch, dass auch ältere Positionen im Datenspeicher vorgehalten werden, können zum Beispiel Bewegungsmuster berechnet werden, um höhere Logik umzusetzen.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 4.1: Generische GPS-Datenstruktur

Als Beispiel für eine Sehnittstellenspezifikation der VPF-Implementierung ist in Tabelle 4.2 ein Überblick über die Methoden der abstraken Klasse OSLayer gegeben. Diese Klasse gibt die Schnittstellen der Gerätetreibersehieht (siehe Abbildung 4.3) vor. Die Aufgabe dieser Schnitt­stelle ist es, einen einheitlichen Zugriff auf IEEE 802.11 Parameter der Funkhardware und die Kommunikation mit der Sieherungssehieht anzubieten. Dieses Beispiel zeigt die dringende Not­wendigkeit von abstrakten Schnittstellen für das System, Der Gerätetreiber der IEEE 802.11 Hardware ist plattform- und hardwarespezifiseh und es gibt unterschiedlichste Möglichkeiten, diese Methoden umzusetzen. Diese Schnittstelle schafft daher eine weitgehende Unabhängig­keit des Prototypensystems von der Funkhardware, dem Betriebsystem und dem Gerätetreiber.

Lediglich die Implementierung der Schnittstelle im VPS muss abhängig von der zu Grunde he­genden Hard- und Software angepasst werden und der Rest des Systems bleibt von diesen Änderungen unbeeinflusst.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 4.2: Sehnittstellenspezifikation für die Gerätetreibersehieht

Das VPF gibt auch implizit die Speicherverwaltung im Protokollstapel vor. Einer der kriti­schen Aspekte für die Leistungsfähigkeit eines Protokollstapels ist es, wie oft Daten im regulären Paketfluss durch den Stapel kopiert werden müssen. Im Optimalfall wird ein Paket, das vom Gerätetreiber empfangen wird nur einmal kopiert, bis es auf der Empfängersehieht im Stapel angekommen ist. Genauso wäre es optimal, wenn Pakete, die von einer Applikation versendet werden, nur einmal auf der Ebene des Gerätetreibers kopiert werden. In der Praxis gestaltet sieh die Speieherverwaltung jedoch schwierig und Kopieroperationen können häufiger auftro­ten. Da sieh alle Komponenten des Prototypensystems im selben Prozess befinden, lässt sieh dieses Problem im VPS gut mit Zeigern lösen. Eine entsprechende Datenstruktur, die im VPF definiert ist, ist in Tabelle 4.3 aufgelistet. Diese Datenstruktur weist für die Kopfdaten jeder Schicht im Protokollstapel einen eigenen Zeiger auf. Das Attribut data ist für die Xutzda- ten der Applikation vorgesehen. Für jeden Paketteil ist zusätzlich die Gröfse in Bytes in der Datenstruktur vermerkt. Mit Hilfe dieser Datenstruktur lassen sieh Kopiervorgänge nun mi­nimieren, Versendet eine Applikation ein Paket, wird ein Zeiger auf die Xutzdaten zunächst im Attribut data abgelegt. Jede am Versenden des Pakets beteiligte Schicht reserviert nun für ihre jeweiligen Kopfdaten Speicher, auf den im zugehörigen Attribut verwiesen wird. Erst auf der Kontrollsehieht werden alle Kopfdaten und die Xutzdaten sehliefślieh in einen zusam­menhängenden Speicherbereich kopiert, wenn die Paketdatenstruktur aus der Wartesehlange entnommen wird. Das zusammenhängende Paket wird dann an die Gerätetreibersehieht und von dieser direkt an die Sieherungssehieht übergeben, wo es ggf, ein weiteres Mal vom Geräte­treiber kopiert wird. Beim Versenden treten also zwei Kopiervorgänge des Pakets auf, einmal beim Zusammenlegen von Kopf- und Xutzdaten und einmal um das Paket vom Speicherbereich des VPS in den Speicherbereich des Gerätetreibers zu kopieren. Beim Empfangen eines Pakets von der Sieherungssehieht verweist das Attribut data auf die zusammenhängenden Paketdaten inklusive aller Kopfdaten, Wenn das Paket im Protokollstapel nach oben wandert, analysiert jede Schicht ihre Kopfdaten, auf die zunächst das daia-Attribut zeigt. Jede Schicht setzt dann die Zeiger auf die Xutz- und Kopfdaten entsprechend um, so dass keine Daten kopiert werden müssen. Erst wenn die Datenstruktur die Applikationssehieht erreicht, müssen die Xutzdaten einmal in den Speicherbereich der Applikation kopiert werden. Beim Empfangen von Paketen treten also auch rund zwei Kopiervorgänge auf. Hier Helsen sieh ggf, noch stärkere Optimie­rungen finden. Doch muss auch gesehen werden, dass der hochoptimierte Einsatz von Zeigern eine hohe Fehleranfälligkeit in die Software transportieren kann. Für das Prototypensystem sollte ein Mittelweg gefunden werden, der Effizienz und Sicherheit vereint. Dies wurde mit dem Einsatz dieser Datenstruktur versucht zu erreichen. In Abbildung 4.7 ist die Verarbeitung der Paket-Datenstruktur beim Senden und Empfangen von Paketen im Protokollstapel nochmals dargestellt, Abbildung 4.8 stellt die Verzeigerung einer voll aufgebauten Paket-Datenstruktur dar.

Da das VPF die Basis für viele verschiedene Konfigurationen von Prototypensystemen sein soll, ist besondere Sorgfalt bei dessen Implementierung angebracht. Die Grundgedanken die hier einfliefśen, beeinflussen das Design der konkreten Implementierung im VPS wesentlich. Die Spe­zifikationen von Schnittstellen und Datenstrukturen im VPF stellen das wesentliche Element dar, um die Plattformunabhängigkeit und die Austauschbarkeit einzelner Komponenten des VPS zu erreichen. Die hier vorgestellte Implementierung ist eine erste Umsetzung, Die Schnitt-stellen müssen ggf, noeh überarbeitet werden, da deren Stabilität von besonderer Wichtigkeit ist.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 4.3: Generisehe Paket-Datenstruktur

4.3.2 VANET Prototyping System

Das im letzten Abschnitt umgesetzte VPF stellt nur den Sockel für die Implementierung eines Prototypensystems dar und ist eigenständig nicht lauffähig. Das VPS stellt nun ein voll lauf­fähiges Prototypensystem dar, dass die Grundlagen, die vom VPF vorgegeben werden, nutzt, um eine spezielle Konfiguration von Protokollsehiehten, Sensormodulen, externen Verwaltungs­werkzeugen, Xetzwerkagenten und Applikationen zu realisieren. An dieser Stelle muss auch die Wahl der konkreten Zielplattform für das System getroffen werden, da die Gerätetreibersehieht, die Sensormodule und die Interpozesskommunikation sieh nicht plattformunabhängig realisie­ren lassen. Für die hier vorgestellte Implementierung wurde das freie Betriebsystem Linux als Plattform gewählt. Diese Wahl ist dadurch begründet, dass Linux besondere Stärken bei der Xetzwerkfunktionalität aufweist. Weiterhin liegen unter Linux alle Schnittstellen und Geräte­treiber offen vor. Für ein Softwaresystem, das so tief im Betriebsystem ansetzt und nah an der Funkhardware operiert, kann diese Offenheit von grofśer Bedeutung sein. Ein weiterer Vorteil von Linux ist, dass der einfache Wechsel der zu Grunde liegenden Hardwareplattform von einem PC auf eingebettete Hardware möglich ist. Der Linux-Kernel ist für eine Vielzahl von Hard- warearehitekturen verfügbar und weist unter allen Architekturen dieselben Systemaufrufe auf. Dadurch kann doppelter Entwieklungsaufwand für plattformabhängige Komponenten des VPS aufgrund des Wechsels von der PC-Hardware auf eingebettete Hardware vermieden werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4.7: Speicherverwaltungsmodell im VPF

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4.8: Verzeigerung einer voll ausgefüllten Paket-Datenstruktur

Gerätetreiberschicht

Die Gerätetreiberschnittstelle kann unter Linux einfach mittels der sogenannten Packet Sockets umgesetzt werden. Packet Sockets bieten einen direkten Einsprungspunkt auf die Sicherungs­schicht. Pakete können über sie empfangen werden direkt bevor sie an den regulären TCP/IP- Protokollstapel übergeben werden. Beim Senden von Paketen über diese Schnittstelle gehen diese direkt an den Gerätetreiber des zuständigen Netzwerkgeräts. Der einzige Parameter für die Kommunikation über Packet Sockets ist daher die MAC-Adresse des Ziel- bzw. Quellknotens. Packet Sockets sind hardwareunabhängig. Sie müssen lediglich an ein konkretes Netzwerkgerät gebunden werden, da sonst Pakete von allen Netzwerkadaptern im System empfangen werden. Das Arbeiten mit IEEE 802.11 Parametern, wie es die Schnittstellenspezifikation in Tabelle 4.2 vergibt, wird mit Hilfe hardwareunabhängiger Systemaufrufe durehgefiihrt. Diese Systemaufru­fe sind für alle IEEE 802.11-kompatible Funkhardware unter Linux verfügbar. Es handelt sieh dabei um die Wireless Extensions von Linux, Diese Systemaufrufe werden dureh die im VPF definierte Schnittstelle der Gerätetreiberschicht komfortabel gekapselt.

Kontrollschicht

Die Kontrollschicht ist im VPS der Einsprungspunkt des Protokollstapels und kontrolliert des­sen Ausführungsstrang, Auf dieser Schicht wird eine Wartesehlange mit frei konfigurierbarer Grofśe implementiert, in der ausgehende Pakete zwisehengespeiehert werden. In der Haupt­schleife der Kontrollschicht wird nacheinander geprüft, ob neue Pakete eingetroffen sind, indem die Empfangsmethode der Gerätetreiberschicht aufgerufen wird, Xeu empfangene Pakete wer­den sofort im Xetzwerkstapel verteilt. Sind keine neuen Daten mehr verfügbar, werden Pakete aus der Wartesehlange über die Gerätetreiberschicht versendet. Ist eine Iteration des Sende- und Empfangsprozesses durchlaufen, besteht die Möglichkeit, Sensormodule aufzurufen, um neue Sensordaten abzufragen oder das Modul zur Interprozesskommunikation auszuführen, um auf externe Anfragen zu reagieren. Danach wird mit der nächsten Iteration fortgefahren. Da auf jeder Schicht im Protokollstapel (De-)Multiplexing durehgefiihrt werden muss, muss auch die Kontrollschicht eigene Kopfdaten an ausgehende Pakete anhängen bzw, bei eingehenden Pake­ten verarbeiten, um das Paket an den korrekten Empfänger im System zuordnen zu können (siehe Abbildung 4.9 (a)), Xatiirlich könnte die Kontrollschicht noch erweiterte Funktionalität umsetzen, wie in 4.2.2 beschrieben. Zur verbesserten Analyse und Fehlersuche wurde auf der Kontrollschicht und auch auf allen höheren Schichten eine laufende Paketnummer mit 32 Bit Länge in die Kopfdaten aufgenommen. Um Pakete zum richtigen Empfänger zuordnen zu kön­nen, wird jeder Ausprägung einer Xetzwerksehieht im VPS eine konstante Protokollkennung zugewiesen. Diese Kummer wird in die Kopfdaten eingetragen. Für diese Protokollkennung sind 16 Bit vorgesehen. Diese Kummer ist vergleichbar mit der Portnummer bei TCP/IP, Jedoch kann sie nicht nur zwischen verschiedene Applikationen, sondern auch zwischen verschiede­nen Protokollsehiehten und Xetzwerkagenten unterscheiden. Dies macht es besonders einfach, mehrere Protokolle parallel auf einer Xetzwerksehieht zu betreiben. Existieren zum Beispiel zwei Implementierungen eines Routingalgorithmus auf der Vermittlungssehieht, lässt sieh im­mer eindeutig zuordnen, welches Protokoll der Empfänger eines Pakets ist. Beim Senden kann entweder eine Applikation, ein Xetzwerkagent oder die Rundfunksehieht ein Paket an die Kon- trollsehieht übergeben. Die Entität, die das Paket an die Kontrollschicht übergibt, muss gemäfs den Schnittstellen und Datenstrukturen, die im VPF definiert sind, auch ihre Protokollkennung angeben. Diese Protokollkennung wird dann von der Kontrollschicht in die Kopfdaten einge­tragen. Beim Empfänger dieses Pakets kann die Kontrollsehieht über die Protokollkennnng mm die Zielentität bestimmen. Die Protokollkennnngen müssen natiirlieh über versehiedene Systeme hinweg gleieh gewählt werden. Ist die Entität mit der Protokollkennnng nicht auf dem Empfän­gersystem vorhanden oder aktiv, kann das Paket verworfen bzw, eine Fehlernachricht an den Absender gesendet werden. Schließlich fügt die Kontrollsehieht noch ein Feld für die Xachrich- tengriße in die Kopfdaten mit ein. Diese definiert die Grofśe der gesamten Nachricht in Bytes abzüglich der Kopfdaten der Kontrollsehieht, Für die Xaehriehtengröfse sind 16-Bit vorgesehen, was eine maximale Xaehriehtengröfse von 64 Kilobyte erlaubt. Da die MTU (Maximum Transfer Unit) der IEEE 802.11 Hardware bei 1500 Bytes liegt, wird diese Xaehriehtengröfse jedoch nicht ansgereizt werden können. Bei der Entwicklung der VPS-Protokollformate wurden allerdings alle Protokollfelder auf Bytegrenzen gesetzt, um die erhöhte Verarbeitungskomplexität durch Bitoperationen im Protokollstapel zu vermeiden.

Rundfunkschicht

Auf der Rundfunkschicht wurde für das VPS ein Protokoll für erweiterten Rundfunk entwickelt (siehe Abbildung 4.9 (b)). Dieses implementiert konventionellen Rundfunk, begrenzten Rund­funk und netzweiten Rundfunk, Die ersten beiden Felder in den Kopfdaten des Rundfunk­protokolls sind eine laufende Xachrichtennummer und die Protokollkennung, genauso wie auf der Kontrollsehieht, Eine eigene laufende Nummer auf der Rundfunkschicht ergibt Sinn, um äquivalente Rundfunkpakete zu erkennen, die vom System bereits verarbeitet und weiterver­breitet wurden. Diese Duplikate können so von der Rundfunkschicht verworfen werden, ohne dass sie in höhere Schichten wandern und erhöhten Mehraufwand produzieren. Das dritte Pro­tokollfeld bezeichnet den Typ der Rundfunknachricht und ist 8 Bit breit. Dies ermöglicht es, versehiedene Rundfunktechniken zu unterscheiden. Handelt es sieh um eine Punkt-zu-Punkt- Übertragung oder ein herkömliches Rundfunkpaket, folgen keine weiteren Felder in den Kopf­daten des Rundfunkprotokolls, Liegt begrenzter oder netzweiter Rundfunk vor, dann folgen erweiterte Kopfdaten, Dazu gehört die MAC-Adresse des Quellknoten einer Rundfunkübertra­gung, Da bei Multi-Hop-Übertragungen die Quelladresse, die von der Sicherungsschicht mitge­teilt wird, keine Aussage mehr darüber erlaubt, von wem das Paket ursprünglich stammt, muss diese Ursprungsadresse auf der Rundfunkschicht eingetragen werden. Die Kombination die­ser Ursprungsadresse und der Xachrichtennummer des Rundfunkpakets erlaubt eine eindeutige Identifikation von Rundfunknachrichten, so dass doppelte Pakete verworfen werden können. Das nächste Protokollfeld ist ein Hop-Zähler, der bei jeder Weiterverbreitung des Rundfunkpakets inkrementiert wird. Dieser Hop-Zähler erlaubt bei netzweitem Rundfunk ggf, logische Schlüsse auf der Applikationsebene, Im Falle einer begrenzten Rundfunkübertragung wird schließlich noch eine Hop-Grenze in den Kopfdaten vermerkt. So lässt sieh feststellen, wann der maximale Hop-Radius erreicht ist und das Paket wird nicht mehr weiterverbreitet. Für die Hop-Gröfsen sind jeweils 16 Bit vorgesehen, was auch für sehr grofśe VAXETs noch ausreiehen sollte.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4.9: Protokollformate der implementierten Komponenten

Nachbarschaftsprotokollagent

Als Beispiel für einen Xetzwerkagenten wurde ein Xaehbarsehaftsprotokollagent implementiert. Dieser pflegt mit Hilfe eines Xaehbarsehaftprotokolls eine Tabelle lokaler, direkt erreichbarer Xaehbarn im VAXET (siehe 3.2), Das Protokollformat (Abbildung 4.9 (e)) sieht wie auf der Rundfunkschicht zunächst 8-Bit für den Typ der Xaehrieht vor. Gegenwärtig wird nur ein Xaehriehtentyp verwendet, der die eigene Position mitteilt. Es könnten aber weitere Xaehrieh- tentypen realisiert werden, wie zum Beispiel eine Abmeldenachricht, wenn ein Teilnehmer sich aus dem VAXET ausklinkt. Auch ein Xaehriehtentyp zur Übertragung der gesamten Xaehbar- sehaftstabelle wäre denkbar, um somit insgesamt eine Liste aller 2-Hop-Xaehbarn aufzubauen, Sehliefślieh wären auch reine Hallo-Xaehriehten denkbar, die keine Positionsdaten enthalten. Der hier vorgesehene Xaehriehtentyp zur Übermittlung der eigenen Positionsdaten, sieht ein 8 Bit Feld für einen Qualitätsindikator der Sensordaten vor. Dieser wird in der vorliegenden Implementierung nur auf Xull oder Eins gesetzt, für schlechte bzw, gute Qualität, Die vier Folgenden Felder sind die Positionsdaten für Breiten- und Längengrad, Bewegungsrichtung und -geschwindigkeit gemäfs der GPS-Datenstruktur in Tabelle 4.1, Für diese prototypische Implementierung werden die 64 Bit Gleitkommazahlen binär im Xetzwerk übermittelt. Für eine plattformunabhängige Implementierung müsste hier jedoch entweder eine Umwandlung in ein Ganzzahlenformat erfolgen oder die Gleitkommazahl als Zeichenkette übertragen wer­den, Die Darstellung von Gleitkommazahlen ist nämlich nicht plattformunabhängig. Auf den GPS-Zeitstempel gern, Tabelle 4.1 wurde für den Xaehbarsehaftsprotokollagenten verzichtet, Stattdessen merkt sich der Empfänger eines Xaehbarsehaftpakets einfach die Empfangszeit des Xaehbarsehaftspakets, Auf diese Art kann jedoch vom Empfänger nicht festgestellt werden, ob Sensordaten veraltet sind. Für den Praxiseinsatz muss deshalb auch der GPS-Zeitstempel in das Protokoll integriert werden. Der Xaehbarsehaftsprotokollagent sendet nun in einem regelmäfsi- gen Intervall eine solche Protokollnaehrieht mit der aktuellen GPS-Position aus dem gemeinsa­men Datenspeicher des VPF als konventionelle Rundfunknaehrieht an seine 1-Hop-Xaehbarn, Da der Agent eigenständig tätig ist, benötigt er auch einen eigenen Ausführungsstrang, Die Länge des Intervalls ist ein dynamisch konfigurierbarer Parameter dieses Xetzwerkagenten, Da alle Teilnehmer im VAXET diesen Xaehbarsehaftsprotokollagenten ausführen, werden von allen 1-Hop-Xaehbarn entsprechende Xaehbarsehaftsnaehriehten erhalten. Aus diesen Xaehriehten lässt sieh nun eine 1-Hop-Xaehbarsehaftstabelle aufbauen und verwalten. Diese Tabelle wird im globalen Datenspeicher des VPF abgelegt, damit alle anderen Schichten und Anwendun­gen Zugriff auf diese Daten erhalten. Ein ebenfalls konfigurierbarer Zeitüberschreitungswert dient dazu, veraltete Xaehbarsehaftsinformationen aus der Tabelle zu entfernen. Der Xaehbar- sehaftsprotokollagent erfüllt damit alle Eigenschaften eines Xetzwerkagenten: Er führt keine eigenständige Anwendung aus die für sieh steht, sondern erfüllt einen Dienst für alle anderen Schichten und Anwendungen des VPS, Er benötigt außerdem privilegierten Zugriff auf den gemeinsamen Datenspeicher, um diese Funktion auszuführen. Die Xaehbarsehaftstabelle wird dann von vielen anderen Entitäten im System benötigt. Die Rundfunkschicht benötigt Xaeh­barsehaftsinformationen etwa für intelligenten oder geographischen Rundfunk, Routing- und Transportprotokolle brauchen die Daten für logische Entscheidungen, Anwendungen aus dem Bereich Fahrerassistenz brauchen ebenso fast immer diese Xaehbarsehaftsinformationen.

GPS-Sensormodul

Um einen GPS-Empfänger an das VPS anzubinden, wurde ein GPS-Sensormodul implemen­tiert, Bei der GPS-Hardware handelt es sieh in diesem Fall um einen GPS-Empfänger, der draht­los über Bluetooth kommuniziert. Die Anbindung erfolgt dabei über das Bluetooth RFCOMM (Radio Frequency Communication) Protokoll, dass eine serielle Schnittstelle über Bluetooth emuliert. Unter dem Linux Betriebsystem wird diese serielle Schnittstelle über eine zeichen­orientierte Gerätedatei angesprochen, welche sieh wie eine herkömmliche Datei verhält und byteweise ausgelesen und geschrieben werden kann. Das GPS-Sensormodul des VPS wird ent­sprechend mit dem Pfad zur Gerätedatei konfiguriert. Das Modul öffnet diese Datei, konfiguriert den GPS-Empfänger, damit er das korrekte XMEA-Format übermittelt und liest fortlaufend die Positionierungsdaten vom Empfänger aus. Der Empfänger liefert jede Sekunde eine neue Position, Wenn das Sensormodul die Position verarbeitet hat, schreibt es diese in den globalen Datenspeicher des VPF und wartet auf die nächste Position, Auch dieses Sensormodul operiert in einem eigenen Ausführungsstrang des VPS-Systems, Da sieh die zum GPS-Empfänger gehö­rige Gerätedatei wie eine normale Datei verhält, konnte das Sensormodul auch einfach um eine GPS-Simulation erweitert werden. Dazu müssen lediglich einmal vom GPS-Empfänger aufge­zeichnete Datensätze in eine normale Datei kopiert werden. Wird das GPS-Sensormodul nun mit dieser Datei als Gerätepfad konfiguriert, können diese aufgezeiehenten GPS-Spuren transpa­rent wiederverwendet werden. Das Sensormodul muss hier lediglich an einigen wenigen Stellen eine Fallunterscheidung treffen, damit nicht versucht wird, in die aufgezeichnete GPS-Spur eine Konfigurationsnachricht zu schreiben und um die Datei erneut zu öffnen, wenn das Dateiende erreicht ist. Dies ermöglicht es, auf einfache Art und Weise auch ohne reale GPS-Positionsdaten Tests mit dem VPS durchzuführen.

Interprozesskommunikation

Die Interprozesskommunikation wurde in dieser VPS-Konfiguration über eine Linux-Xaehrieh- tensehlange realisiert, Xaehriehtensehlangen ermögliehen den Austauseh von beliebigen, eher kleineren Xaehriehten zwisehen Prozessen über eine Datenstruktur im Betriebsystemkern, Die hierfür implementierte Klasse zur Interprozesskommunikation erhält keinen eigenen Laufzeit­strang, sondern wird regelmäfsig von der Hauptsehleife auf der Kontrollsehieht des Xetzwerksta- pels aus aufgerufen. Dies ist vertretbar, da die Interprozesskommunikation nicht viel Rechenzeit in Anspruch nimmt, Xatiirlich könnte auch diese Funktionalität in einem eigenen Laufzeitstrang ausgeführt werden. Das VPS erzeugt während des Starts eine neue Xachrichtenschlange, mit­tels der andere Prozesse Anfragen an das System senden können. Die Implementierung der Xachrichtenschlange prüft bei jedem Aufruf, ob neue Anforderungen von anderen Prozessen vorliegen, verarbeitet diese indem die notwendigen Aufrufe im VPS vorgenommen werden und sendet die resultierenden Daten oder eine Bestätigung an den externen Prozess zurück.

Um die Interprozesskommunikation exemplarisch zu implementieren, wurde ein einfaches Konsolenwerkzeug namens vpsconfig entwickelt, das es erlaubt, das VPS von aufśen interaktiv zu beenden oder neu zu starten, Aufśerdem ermöglicht es ein Auslesen der eigenen GPS-Position, sowie der Xachbarschaftstabelle, die der Xachbarschaftsagent aufgebaut hat. Beliebige Erweite­rungen dieses Zugriffs von aufśen sind möglich, Verhaltensweisen von Protokollen, Algorithmen und globale Systemparameter können auf diese Weise beeinflusst oder statistische Auswertung­en vorgenommen werden.

Radarschirmapplikation

Um schließlich die Funktionalität des Gesamtsystems zu demonstrieren, ist eine Radarschirman­wendung umgesetzt worden. Die Applikation führt gemafś der vom VPF vorgegebenen Schnitt­stelle einen eigenen Laufzeitstrang aus. Die Funktionalität der Anwendung umfasst das Versen­den der eigenen GPS-Daten und aller Einträge aus der Xachbarschaftstabelle des VPS, Diese Daten werden per netzweiter Rundfunkübertragung im gesamten Xetzwerk verbreitet. Folglich erhält dadurch die Radarschirmanwendung jedes Knoten im VAXET die vollständige Kenntnis über alle anderen Teilnehmer im Xetzwerk und deren Positionsdaten, Knoten, die durch die Radarschirmanwendung bekannt werden, aber nicht bereits durch das Xachbarschaftsprotokoll abgedeckt sind, sind alle Knoten, die nur über Multi-Hop-Übertragungen erreichbar sind. Diese Multi-Hop-Knoten legt die Applikation in einer eigenen Radartabelle ab.

Die gesammelten Positionsdaten aus dem VAXET, die sieh aus der eigenen Position, der Xachbarschaftstabelle und der eigenen Radartabelle zusammensetzen, bietet die Radarschirm­applikation nun anderen Prozessen nach aufśen an. Ein externer Prozess kann die Daten aus­lesen, um sie zu visualisieren und eine Strafśenkarte mit einer Übersieht über alle anderen Fahrzeuge im Netzwerk zu erstellen. Die vorliegende Implementierung setzt für diesen Daten­austausch ebenfalls den Mechanismus der Xaehriehtensehlangen ein. Hierbei handelt es sieh jedoch um eine von der allgemeinen Xaehriehtensehlange für Interprozesskommunikation mit externen Werkzeugen separate Xaehriehtensehlange, Die allgemeine Interprozesskommunikation des VPS sollte nicht von Applikationen eingesetzt werden, da diese für privilegierte Operationen auf dem Xetzwerkstapel vorgesehen ist und dabei nur relativ kleine Nachrichten ausgetauseht werden, Applikationen hingegen sollten ihre Funktionalität möglichst stark von der des restli­chen Systems trennen. Zudem ist die Interprozesskommunikation der Radarsehirmanwendung zum automatischen Austausch zwischen zwei Prozessen ausgelegt, während die Xaehriehten­sehlange des VPS für interaktive Aufrufe angedaeht ist.

Das Protokoll zum Austausch der Radarsehirmdaten ist in Abbildung 4.9 (d) aufgeführt. Die Anwendung überträgt die gesammelten Daten als eine grofśe Tabelle, Dazu findet sieh im ersten Protokollfeld mit 8 Bit Grofśe die Anzahl der Tabelleneinträge, Dies erlaubt maximal 255 Einträge, was für den prototypisehen Einsatz ausreichend ist. Für grofśe VAXETs müssten ohnehin mehrere Teilnaehriehten übermittelt werden, da die MTU der WLAX-Hardware keine solch grofśen Pakete erlaubt. Für jeden Tabelleneintrag sind im Protokoll die MAC-Adresse des betreffenden Knoten und seine Positionsdaten in Form von Längen- und Breitengrad, Ge­schwindigkeit und Bewegungsriehtung als 64 Bit Gleitkommazahlen, sowie einem 8 Bit Quali­tätsindikator enthalten.

In Abbildung 4.10 ist der gesamte Aufbau der hier vorgestellten VPS-Implementierung noch­mals dargestellt. Das Treppenmodell wird in diesem Fall nicht ausgenutzt. Obwohl die Radar­sehirmanwendung oder der Xaehbarsehaftsprotokollagent direkt auf die Kontrollsehieht zugrei­fen könnten, besteht dazu kein Grund, da beide die Funktionalität der Rundfunksehieht nutzen müssen. Der Xaehbarsehaftsagent befindet sieh auf derselben Ebene wie die Radarsehirmappli- kation, hat jedoch eine herausgestellte Position, da er auch Daten in den Datenspeicher schrei­ben darf. Die GPS-Sensorsehnittstelle ruft in der Regel aussehliefślieh den Datenspeicher auf, um die aktuellen Sensordaten dort abzulegen. Das Modul zur Interprozesskommunikation über eine Xaehriehtensehlange hat nur eine direkte Schnittstelle zur Kontrollsehieht und bezieht ggf, Daten aus dem Datenspeicher, Diese VPS-Implementierung demonstriert die wichtigsten Mechanismen des VPF- und VPS-Modells, Eine Erweiterung dieser VPS-Konfiguration durch weitere Sensormodule, Applikationen, Xetzwerkagenten, Kommandozeilenprogramme oder eine Vermittlungs- und Transportsehieht stellt kein Problem dar.

Der Startprozess des VPS-Systems ist in Abbildung 4.11 dargestellt. Dort ist zu entnehmen, dass das VPS-System zunächst eine Konfigurationsdatei ausliest und versucht, das ausgewählte WLAN-Netzwerkadapter zu konfigurieren. Ist dies erfolgreich geschehen, werden die Ausfüh­rungsstränge für das GPS-Sensormodul, den Nachbarschaftsagenten und die Radarschirmapp­likation erzeugt. Danach ist der Netzwerkstapel voll einsatzbereit und der Nachbarschaftsagent sowie die Radarschirmapplikation können den Betrieb aufnehmen. In Abbildung 4.12 ist der Hil­fetext des vpsconfig Kommandozeilenwerkzeugs abgebildet, welcher die derzeit implementierten Kommandos auflistet, die an das VPS-System gesendet werden können. Die Abbildungen 4.13 und 4.14 zeigen beispielhaft den Abruf der eigenen Position und des Inhalts der Nachbarschaft­stabelle im VPS-System durch das vpsconfig-Werkzeug. In Abbildung 4.15 ist schließlich die Textausgabe der Radarschirmapplikation dargestellt, die in diesem Fall auch einen Multi-Hop­Eintrag in der Radartabelle aufweist.

VANET Prototyping System

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4.10: Aufbau und Konfiguration der VPS-Implementierung

4.4 Versuchsaufbau

In diesem Abschnitt wird ein Versuchsaufbau vorgestellt, der zur praktischen Demonstration des VPS dient. Im Folgenden wird die in diesem Versuchsaufbau eingesetze Hardware vorgestellt und erläutert, wie die Daten der Radarschirmapplikation visualisiert werden. Schließlich werden erste Ergebnisse aus den praktischen Tests mit diesem Versuchsaufbau vorgestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4.11: Startprozess des VPS

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4.12: Hilfetext des externen Werkzeugs vpsconfig

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4.13: Ausgabe der eigenen GPS Position mit Hilfe von vpsconfig

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4.14: Ausgabe der eigenen Nachbarschaftstabelle mit Hilfe von vpsconfig

4.4.1 Verwendete Hardware

Für den Versuchsaufbau wurden vier Teilnehmer vorgesehen, zwei davon in Form von mo­biler PC-Hardware und zwei in Gestalt von fahrzeugtauglicher, eingebetteter Hardware. Als PC-Hardware sind konventionelle Notebooks gewählt worden. Diese bieten eine hohe Kompati­bilität mit dem Linux-Betriebsystenr und sind relativ klein und leicht (2 Kilogramm), so dass sie sich gut für den mobilen Einsatz eignen (Abbildung 4.16). Die WLAN-Hardware in diesen Note­books unterstützt IEEE 802.11 a/b/g und damit die gesamte Bandbreite der derzeit verfügbaren physikalischen Übertragungsstandards. Es handelt sich dabei um Intel PRO/Wireless 3945ABG Funkmodule. Das zugehörige Treibermodul unter Linux ist ipw39Ą5. In den Notebooks ist auch ein Bluetooth-Adapter integriert, über den der externe Bluetooth GPS-Empfänger angespro­chen werden kann. Als konkretes Betriebsystem wird auf diesen Notebooks die Gentoo Linux Distribution mit einem distributionspezifischen Linux-Kernel in der Version 2.6.18 verwendet [GENTOO].

Als eingebettete Hardware kommt eine Plattform zum Einsatz, die von der Firma Kurz Industrie-Elektronik angeboten wird [KURZ]. Diese Plattform nennt sich FMB (Flexible Main­board) und ihr Herzstück ist ein ARM Prozessor mit 200 MHz Taktfrequenz. Die Hardware ist hochintegriert und vereint auf einer Platine mit den Abmessungen von 10 mal 13 cm zahlrei­che Schnittstellen wie USB (Universal Serial Bus), Ethernet, CAX-Bus, eine serielle Schnitt­stelle oder auch einen IDE-Anschluss (Integrated Drive Electronics), Dem Prozessor sind 64 Megabyte Arbeitsspeicher zur Seite gestellt und 16 Megabyte Flash-Speicher dienen zur dau­erhaften Ablage von Daten, Die Platine ist in Abbildung 4.17 abgebildet. Zur Erweiterung der Plattform um IEEE 802.11 WLAX und Bluetooth wurden die vorhandenen USB-Sehnittstellen genutzt. Die Auswahl der WLAX-Hardware ist für die FMB-Plattform sehr beschränkt, da nur wenige WLAX-Gerätetreiber zur Verfügung stehen. Ein kompatibler USB-WLAX-Adapter ist der ZyXEL ZyAIR B-220, der gemäfs IEEE 802.11b Spezifikation operiert. Dieses Adapter erfüllt die WLAX-Funktionalität auf dem FMB, Der zugehörige Linux-Treiber ist zdlSOl. Bei Bluetooth-Adaptern besteht eine breite Auswahl an Hardware für die eingebettete Plattform, In diesem Fall wurden D-Link DBT-122 USB-Bluetooth-Dongles ausgewählt. Da die 16 MB Flash­Speicher des FMB für den prototypisehen Einsatz kaum ausreichen, wurden sehliefślieh noch USB-Speichersticks mit einem Gigabyte Kapazität an die Hardware angebunden. Die FMB- Plattform kann direkt mit der 12 Volt Stromspannung im Fahrzeug versorgt werden und ist schlüsselstartfähig. Für den mobilen, autonomen Einsatz wurden die FMB-Platinen von Kurz Industrie-Elektronik in ein robustes Aluminiumgehäuse verbaut, bei dem die notwendigen An­schlüsse und Schnittstellen nach aufśen geführt sind (siehe Abbildung 4.18 und 4.19), In das Gehäuse ist auch ein 5.5 Zoll Tastbildschirm integriert der eine Auflösung von 320x240 Pixeln hat. Mit Hilfe dieses Bildschirms kann die Interaktion von VPS-Applikationen mit dem Benutzer stattfinden. In Tabelle 4.4 findet sich eine Übersicht über die relevanten Hardwarekomponen­ten der PC-Xotebooks und der FMB-Einheiten im Versuchsaufbau, Als Betriebsystem auf den eingebetteten Geräten kommt ein individuelles Linux für eingebettete Systeme zum Einsatz, Der Linux-Kernel in der Version 2.6.15 mit einigen plattformspezifischen Anpassungen kommt dabei zum Einsatz.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4.15: Ausgabe der Radarschirmapplikation

Als Bluetooth GPS-Empfänger kommen vier baugleiche RoyalTek RBT 2001 Sirf III X mini zum Einsatz, Diese stellen die GPS-Informationen gemäfs der XMEA-Spezifikation zur Verfü­gung, Es muss darauf hingewiesen werden, dass die Bluetooth-Kommunikation zwischen den Systemen und den GPS-Empfängern auf einer ähnlichen Frequenz wie die IEEE 802.11b Hard­ware operiert, die für die VPS-Kommunikation verwendet wird. Dies könnte zu einer Störung oder Verschlechterung der WLAX-Verbindungen führen. Eine genaue Untersuchung des gegen­seitigen Einflusses zwischen Bluetooth- und WLAX-Kommunikation wurde nicht vorgenommen. Es zeigten sich jedoch in der Praxis keine erkennbaren Effekte, Um sichere Störungsfreiheit zu gewährleisten, könnten auch serielle GPS-Empfänger verwendet werden, um die Positionie­rungsdaten ermitteln.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4.16: Notebook-Hardware für den Versuchsaufbau

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4.17: FMB:Plattform ohne Gehäuse

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4.18: FMB-Plattform im Aluminiumgehäuse mit 5,5 Zoll Tastbildschirm

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4.19: Schnittstellen im FMB-Gehäuse

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4.20: Die beiden FMB-Einheiten beim Betrieb des VPS

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 4.4: Konfiguration und Hardwarekomponenten der Systeme im Versuchsaufbau

4.4.2 Visualisierung der Radarschirmdaten

Wie oben beschrieben wurde, bietet die Radarschirmapplikation, die im VPS aktiv ist, die gesammelten Positionsdaten aller Teilnehmer im VAXET über eine Xachrichtenschlange nach außen an. Um die so nach außen geführten Daten zu visualisieren, kommt eine modifizierte Ver­sion der Xavigationssoftware der Elektrobit Automotive GmbH zum Einsatz |EBA|, Bei dieser Xavigationssoftware namens Street Director handelt es sieh um eine vollständige Xavigations- lösung, die für den Einsatz beim Endkunden sowie den festen Einbau im Fahrzeug vorgesehen ist |SD|, Die hier eingesetzte Variante dieser Software ist eine Linux-Portierung, die zur Ent­wicklung von Prototypen im Fahrerassistenzumfeld modifiziert wurde. Sie bietet insbesondere generischen Zugriff auf digitale Kartendaten.

Die Xavigationssoftware wurde um ein Kommunikationsmodul erweitert, das über die Inter­prozesskommunikation die Positionsdaten der Radarsehirmanwendung aus dem VPS abfragt. Diese Daten werden innerhalb der Xavigation dazu verwendet, die digitalen Kartendaten im Umkreis der eigenen Fahrzeugposition abzufragen. Mit diesen Kartendaten und den Positionsin­formationen wird dann eine digitale Straßenkarte gezeichnet, auf der alle VAXET-Teilnehmer visualisiert sind. Auf der PC-Hardware existierte zur Visualisierung bereits eine dreidimen­sionale Darstellung, die mit der OpenGL (Open Graphics Library) implementiert worden ist [OpenGL]. Die Benutzerschnittstelle erlaubt in diesem Fall drei unterschiedliche Kameramo­di. Diese ermöglichen eine frei positionierbare Kamerasicht, die Sicht aus der Vogelperspektive oder eine Verfolgerkamera mit Sicht auf die aktuelle Fahrzeugposition. Die Größe des darge­stellten Fahrzeugnetzes kann beliebig verändert werden. Verschiedene Straßenklassen (wie z. B. Autobahn, Bundesstraße, Schnellstraße, Stadtstraße, Fußweg, Eisenbahn) werden in unter­schiedlichen Farben dargestellt und können auch interaktiv ein- und ausgeblendet werden. Die Positionen der VANET-Teilnehmer sind in unterschiedlichen Farben dargestellt, die den vier Teilnehmern im Versuchsaufbau mittels einer MAC-Adressen-Abbildung fest zugeteilt werden (siehe Abbildung 4.21). Auch die Anzeige der Fahrzeugpositionen kann einzeln aktiviert oder deaktiviert werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4.21: 3D-Visualisierung der Radarschirmdaten

Für die FMB-Einheiten ist hingegen eine neue, zweidimensionale Visualisierung realisiert worden, da auf der eingebetteten Hardware nicht genügend Ressourcen zum Betrieb der be­reits existenten grafischen Oberfläche zur Verfügung stehen. Die neue Visualisierung ist mit Hilfe der SDL-Bibliothek (Simple Direct Media Layer) umgesetzt [SDL]. Bei der SDL handelt es sich um eine einfache Grafikbibliothek mit einer dünnen Abstraktionsschicht, die auch den direkten Zugriff auf den Bildspeicher der eingebetteten Hardware erlaubt, so dass kein umfang­reiches Grafiksystem im Hintergrund aktiv sein muss, um die Visualisierung zu ermöglichen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4.22: 2D-Visualisierung der Radarschirmdaten (nahe Ansicht)

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4.23: 2D-Visualisierung der Radarschirmdaten (entfernte Ansicht)

Im Gegensatz zur dreidimesionalen grafisehen Oberfläehe ist bei dieser Implementierung nur die Sieht aus der Vogelperspektive möglieh (siehe Abbildung 4.22 und 4.23), Die restliehen Interaktionsmögliehkeiten bleiben aber erhalten. Zur Interaktion mit der Anwendung auf den FMB-Einheiten ist derzeit noeh der Ansehlufś einer konventionellen PC-Tastatur notwendig, da der Tastbildsehirm auf dem System noeh nicht angebunden wurde. Eine Erweiterung in der Zukunft sollte jedoch keine Schwierigkeit darstellen.

Auf den PC-Xotebooks ist zum Betrieb des VPS und der Benutzeroberfläche der Radar- sehirmapplikation der manuelle Start beider Applikationen notwendig. Die FMB-Einheiten hingegen wurden voll autonom konfiguriert, Xaeh dem Herstellen der Stromversorgung wird das Betriebsystem gestartet. Sobald das Betriebsystem fertig geladen ist wird der Bluetooth- Adapter konfiguriert, damit eine Verbindung mit dem GPS-Empfänger möglieh wird. Danach wird das VPS gestartet. Das VPS konfiguriert die WLAX-Hardware mit Einstellungen für die Kanalnummer und den Xamen der Ad-Hoe-Zelle, die für alle vier Systeme im Versuehsaufbau gleich gewählt werden müssen. In einem produktiven VAXET wird es in der Regel nur einen Kanal (bzw, einen Steuerkanal) und nur eine gemeinsame Zelle geben, so dass die statische Kon­figuration der WLAX-Parameter im Versuehsaufbau keinen Xaehteil darstellt. Hat das VPS die Hardware konfiguriert, ist der Xetzwerkstapel einsatzbereit und der Xaehbarsehaftsprotokoll- agent beginnt mit der Arbeit und versendet Beaeon-Pakete an andere Teilnehmer im Xetzwerk, Ebenso versendet die Radarsehirmapplikation ihre Rundfunkpakete im gesamten Xetzwerk, Ist das VPS erfolgreich gestartet, wird die angepasste Xavigationssoftware hoehgefahren, um die Daten, die von der Radarsehirmapplikation geliefert werden, zu visualisieren. Der gesam­te Startprozess auf den FMB-Einheiten dauert ea, 40 bis 50 Sekunden, Die Optimierung der Startzeit stand im Rahmen dieses Prototypensystems nicht im Vordergrund, Eine Reduktion auf 20 bis 30 Sekunden sollte deshalb unproblematisch sein.

4.4.3 Praktische Erfahrungen

Die Portierung des VPS auf die ARM-Architektur der FMB-Einheiten verlief erfreulich ein­fach, Aufśer marginalen Anpassungen waren keine Änderungen am Programmeode notwendig und der Protokollstapel funktionierte einwandfrei. Die Abfrage der Kartendaten und Visuali­sierung aller Informationen innerhalb der Xavigationssoftware verläuft überraschend zügig auf der eingebetteten Hardware, Die Leistungsfähigkeit und Portabilität der Softwarearehitektur ist also gegeben. Im produktiven Einsatz muss jedoch von noeh weniger Ressourcen ausgegangen werden, Plattformen mit 100 MIPS (Million Instructions per Second, etwa 100 MHz) sind im Fahrzeugumfeld nicht uniiblieh. Da es sieh hier jedoch um ein Prototypensystem handelt, ist die grundsätzliche Eignung für eingebettete Systeme bereits hinreichend, da für Produktivsoftware ohnehin umfangreiche Optimierungen und Anpassungen vorgenommen werden müssen.

Als teilweise schwierig stellte sieh der Betrieb der USB-WLAX-Hardware auf den FMB- Einheiten heraus. Der Gerätetreiber verhielt sieh dort im Vergleich zur x86-Version anfälliger und konnte nicht immer erfolgreich geladen werden. Der Startprozess des Betriebsystems, des VPS und der Xavigationssoftware auf den FMB-Einheiten war dadurch leider nicht immer deterministisch. In der Endkonfignration des Versiiehsanfbans stabilisierte sieh das Verhalten jedoch und der autonome Betrieb gelang zuverlässig, Xaeh einem Warmstart der Hardware oder wenn der Gerätetreiber mehrmals geladen und wieder abgemeldet wurde, zeigten sieh weiterhin Schwierigkeiten.

Allgemein zeigte die IEEE 802.11 WLAX-Hardware auf Gerätetreiber- und Hardwareebene Probleme im Detail, Die Intel- und ZyXEL-Hardware konnte nicht immer erfolgreich miteinan­der kommunizieren, Znm Beispiel war es nicht möglich, Kommunikation mit Kontrollpaketen gemäfs dem CSMA/CA-Verfahren von IEEE 802.11 anznwenden. Wurde der Kontrollverkehr aktiviert, erreichten Pakete der Intel-Hardware zwar noch die ZyXEL-Hardware aber nicht andersherum. Erst bei deaktiviertem Kontrollverkehr war eine fehlerfreie, bidirektionale Kom­munikation uneingeschränkt möglich. Dies betraf sowohl die Kommunikation im VPS als auch konventionelle Übertragungen über den TCP/IP-Protokollstapel, Doch auch ohne aktivierten Kontrollverkehr war die Initialverbindnng zwischen den beiden Hardwaretypen nicht immer deterministisch möglich. Dies zeigte sieh inbesondere dann, wenn nur zwei Teilnehmer an der Kommunikation teilnahmen. Bei mehreren Teilnehmern ergab sieh hingegen meist eine gute Konnektivität auch bei der Initialverbindnng mit der Ad-Hoe-Zelle.

Sehliefslieh gab es auch unterschiedliche Verhaltensweisen bei der Ausführung von Systemanf- rnfen zur Steuerung von IEEE 802.11 Parametern, Diese Systemanfrnfe, die gemäfs den Wireless Extensions im Linnx-Kernel spezifiziert sind, werden vom Betriebsystemkern lediglich an den zuständigen Gerätetreiber weitergeleitet. Die konkrete Implementierung und damit die Verhal­tensweise bei diesen Systemanfrnfen hängt also vom Gerätetreiber der Hardware ab. Einige Gerätetreiber implementieren znm Beispiel manche Methoden von IEEE 802.11 gar nicht. So gibt es Hardware bzw, Gerätetreiber, die nur im Infrastrnktnrmodns, jedoch nicht im Ad-Hoe- Modus operieren kann. Da diese Systemanfrnfe derart hardwarenah sind, fällt das Verhalten in der Praxis entsprechend unterschiedlich ans. Ein konkreter Fall dazu ist die Auswahl der Ad- Hoe-Zelle, Die Ad-Hoe-Zelle wird üblicherweise über einen Xamen spezifiziert. Das Fnnkmodnl prüft, ob eine Zelle mit diesem Xamen bereits existiert. Existiert sie bereits, schliefst sieh das Fnnkmodnl der Zelle an. Die Zelle wird über eine MAC-Adresse identifiziert, damit Verkehr zwischen unterschiedlichen Zellen im WLAX unterschieden werden kann. Führt man mm den Systemanfrnf znm Setzen der Ad-Hoe-Zelle auf der ZyXEL-Hardware ans, sucht der Gerätetrei- ber rund fünf Sekunden lange naeh einer bereits existenten Ad-Hoe-Zelle mit diesem Xamen, Findet er keine solche, dann eröffnet er eine neue Zelle und weist ihr eine MAC-Adresse zu. Während dieser Zeit nimmt der Gerätetreiber die meisten Systemaufrufe nicht mehr entgegen, sondern quittiert diese mit einer unspezifisehen Fehlernaehrieht. Erst nachdem er sieh einer Zelle angesehlossen oder eine neue eröffnet hat, sind alle Systemaufrufe an den Gerätetreiber wieder möglich. Dieser Zustand lässt sieh von aufśerhalb des Gerätetreibers nur dadurch feststellen, indem die Adresse der Ad-Hoe-Zelle vom Gerätetreiber abgefragt wird. Dieser Systemaufruf ist weiterhin möglich. Befindet sieh der Gerätetreiber noch im Suehmodus, liefert er als MAC­Adresse für die Ad-Hoe-Zelle die Adresse ’fffffffffffF zurück, Xur durch diese Abfrage lässt sieh feststellen, wann mit der Konfiguration der WLAX-Hardware fortgefahren werden kann. Die Intel-Hardware hingegen zeigt hier ein gänzlich anderes Verhalten: Wird eine neue Ad-Hoe- Zelle ausgewählt, schliefst sieh der Gerätetreiber sofort einer existierenden Zelle an. Ansonsten wählt er überhaupt keine Zelle aus. Wird keine Zelle gefunden, liefert der Gerätetreiber die Zellenadresse ;000000000000; zurück. Diese beiden deutlich unterschiedlichen Verhaltensweisen lassen sieh nur sehr schwierig in der Gerätetreibersehieht des VPS abstrahieren. Insbesondere müssen diese Verhaltensweisen investigativ bei jedem neuen WLAX-Gerätetreiber in Erfah­rung gebracht werden. Im schlimmsten Fall können diese Unterschiede nur dadurch behandelt werden, dass für jeden Gerätetreiber eine eigene Logik an den entsprechenden Stellen der Ge­rätetreibersehieht umgesetzt wird.

Diese Uneinheitlichkeit auf der Gerätetreiberebene der IEEE 802.11 Hardware resultiert wohl vor allem daraus, dass die WLAX-Hardware meistens interaktiv konfiguriert wird. Der Benut­zer eines PCs wählt manuell eine WLAX-Basisstation oder Ad-Hoe-Zelle aus und konfiguriert alle notwendigen Parameter, Selbst wenn der Gerätetreiber einige Sekunden braucht, um sieh erfolgreich zu verbinden, wie dies bei der ZyXEL-Hardware der Fall ist, kann der Benutzer dies abfangen, da er einfach so lange abwartet, bis die Verbindung erfolgreich ist. Eine vollauto­matische Konfiguration der WLAX-Parameter hingegen leidet unter diesen Verhaltensweisen sehr stark. Für den Aufbau von Prototypensystem ist es zu empfehlen WLAX-Hardware zu finden, für die gute Gerätetreiber zur Verfügung stehen. Eine gute Dokumentation sowie eine hohe Kompatibilität zum IEEE 802.11 Standard und den Systemaufrufen des Betriebsystems sind Anhaltspunkte für die Qualität des Gerätetreibers, Hier erweist sieh aber auch die Quell­offenheit des Linux-Betriebsystems als Vorteil: Die unterschiedlichen Verhaltensweisen können identifiziert und angepasst werden, indem die Gerätetreiber analysiert und entsprechend modi­fiziert werden. Dies setzt jedoch gute Kenntnisse im Bereich der Linux-Kernelprogrammierung voraus.

Eine spezielle Funktionalität von IEEE 802.11 WLAX, die für VAXETs interessant ist, ist es den Verkehr anderer Knoten im Netzwerk abzuhören, an dem das eigene Funkmodul nicht beteiligt ist. Ein solcher Mechanismus wird etwa beim Routingalgorithmus DSR angenommen (siehe 3.1.3), der fremde Routinginformationen auf diese Weise mitlauscht. Leider gestaltet sieh die Nutzung dieser Funktionalität in der Praxis nicht so einfach, Aufśer Rundfunkpaketen, die ohnehin von allen Teilnehmern empfangen werden, können Punkt-zu-Punkt-Übertragungen von unbeteiligten Knoten nur dann abgehört werden, wenn sieh deren Funkmodul in einem besonderen Uberwachungsmodus befindet. Dieser Überwachungsmodus (engl, Monitor Mode) erlaubt aber nur noch das Abhören von Paketen und das Senden von Daten ist nicht mehr möglich. Das Funkmodul ist in diesem Modus auch nicht mehr Teil einer bestimmten Ad-Hoc- Zelle, Dass dies nicht anders möglich ist liegt daran, dass die Punkt-zu-Punkt-Übertragungen zwischen den beiden Kommunikationsteilnehmern individuell ausgehandelt werden. Ein unbe­teiligter Mithörer muss deshalb die Justierung auf die entsprechende Funkfrequenz vornehmen, um die Daten erfolgreich abzuhören. Nur vereinzelte IEEE 802.11 Hardware ist in der Lage, gleichzeitig Fremdkommunikation abzuhören und dabei selbst noch Kommunikationsfähig zu sein.

Die Analyse des Datendurchsatzes des VPS-Protokollstapels zeigte leider sehr niedrige Wer­te, Die durchschnittliche Datenübertragungsrate liegt bei 10 bis 50 Kilobyte in der Sekunde, wobei der Wert stark schwankt. Bei dem hier zum Einsatz kommenden IEEE 802.11b Proto­koll wären mindestens mehrere hundert Kilobyte/s zu erwarten gewesen. Eine weitergehende Analyse zeigte jedoch, dass der Engpass nicht im VPS-Protokollstapel liegt, sondern dass die Linux Packet Sockets ein eigenartiges Verhalten bei deren Nutzung über WLAN-Geräte aufwei­sen, Eine direkte Funkübertragung von beliebigen Rohdaten über einen Packet Socket zeigte dieselbe Datenrate von 10 bis 50 Kilobyte/s, Dieselbe Übertragung über Fast Ethernet Hard­ware hingegen lag nah an der theoretischen Grenze von 100 MBit/s, Bei der Nutzung von WLAN-Hardware zeigte sieh weiterhin, dass der Datendurchsatz zunächst sehr hoch war - offenbar bis die Warteschlange im Gerätetreiber voll war, und dieser damit began die Daten an die Hardware zu übermitteln. Danach sank die Datenrate kontinuierlich bis auf den ermit­telten Durchschnittswert, Recherchen nach diesem Phänomen ergaben bisher keinen Hinweis auf die Ursache für diese schlechte Leistungsfähigkeit von Packet Sockets beim Einsatz von WLAN-Hardware, Umfassendere Untersuchungen dieses Problems sind noch notwendig. Der im Prototypensystem erreichte Datendurchsatz ist für Informationsverbreitungsanwendungen zunächst ausreichend. Die Analyse des theoretischen Durchsatzes des VPS-Protokollstapels (d.h, es wurden Testdaten im Stapel verarbeitet, ohne tatsächlich von der Hardware zu emp­fangen oder an sie zu senden) ergab einen Durchsatz von 2 Megabyte/s, Das weist darauf hin, dass selbst IEEE 802.11g Hardware noch zu einem guten Teil mit dem VPS-Stapel ausgela- stet werden könnte, Doeh zeigt sieh aneli, dass die Ansriehtnng des Protokollstapels auf die Leistungsfähigkeit in Prodnktivsystemen eine wichtige Rolle spielt. Bereits geringe Verände­rungen an den Programmteilen, die den typischen Paketfluss im Stapel betreffen, zeigten sieh deutliche Änderungen am theoretischen Durchsatz des Stapels, Das VPS wurde jedoch explizit als Prototypensystem entwickelt, das ein hohes Abstraktionsniveau aufweist. Die Abstraktions­mechanismen von C , wie die Objektorientierung oder virtuelle Funktionen, fordern bereits deutliche Leistungseinbufśen zum Beispiel gegenüber reinem C-Programmeode.

4.5 Ergebnisse

Die Konzeption und Umsetzung der Softwarearchitektur für das VAXET-Prototypensystem in diesem Kapitel orientierte sieh vor allem an der Möglichkeit, umfangreiche Funktionalität möglichst einfach in das System integrieren zu können und gleichzeitig eine hohe Unabhän­gigkeit der Systemkomponenten voneinander und der gesamten Software vom Betriebsystem und der Hardwareplattform zu erreichen. Dieses Ziel wurde weitgehend erreicht und in Form eines konkreten Versuchsaufbaus demonstriert, der zwar zunächst nur einfache Protokollimple­mentierungen einsetzt, aber einfach erweiterbar ist. Die Realisierung des Systems auf PC- und eingebetteter Hardware funktionierte reibungslos.

Positiv hervorzuheben ist, dass die Stabilität des VPS hoch ist. Trotz dessen, dass aufgrund der Xatur eines Xetzwerkstapels viele Zeiger im Programm eingesetzt werden müssen, die ty­pischerweise eine hohe Fehleranfälligkeit zur Folge haben, sind während der Entwicklung und den Tests des VPS kaum schwerwiegende Fehler aufgetreten. Dies zeigt, dass die strikte De­finition von Modulen und Schnittstellen für solch einen Xetzwerkstapel hilft, die Komplexität zu beherrschen und die Programmqualität zum Vorteil zu beeinflussen. Die starke Modularisie­rung unterstützt auch die Portierung der Software auf andere Betriebsysteme und Plattformen, da lediglich die Implementierungen der externen Schnittstellen, d.h, die Gerätetreiberschnitt­stelle, Sensorsehnittstellen und Interprozesskommunikationssehnittstelle ausgeweehselt werden müssen, während die Schnittstellen zum Xetzwerkstapel gleich bleiben und an den anderen Mo­dulen somit auch keine Änderungen vorgenommen werden müssen. Eine Portierung auf andere Betriebsysteme als Linux hängt im wesentlichen nur davon ab, ob das Zielbetriebsystem eine Funktionalität anbietet, die den Linux Packet Sockets entspricht, um direkt mit dem WLAX- Gerätetreiber kommunizieren zu können.

Die hier vorgestellte VPS-Implementierung soll nur die grundsätzliche Machbarkeit eines voll­ständigen Prototypensystems demonstrieren. Vielmehr soll die Grundlage, die mit dem VPF gelegt wurde, als Basis dafür dienen, beliebige Protokollstapel zu entwickeln. Im VPS könnte nun zum Beispiel die Rundfunksehieht noch um geographischen und intelligenten Rundfunk erweitert werden, eine Vermittlungsschicht mit einem geeigneten Routingalgorithmus sowie ein für VAXETs geeignetes Transportprotokoll auf der Transportschicht hinzuentwickelt werden. Zur Optimierung des Stapels kann weiterhin eine Überarbeitung hinsichtlich Leistungsfähigkeit und Speichernutzung erfolgen. Wünschenswert wäre es gewesen, auch eine modifizierbare Si­cherungsschicht in das Prototypensystem aufzunehmen, um mit den Medienzugriffsalgorithmen die gesamte Bandbreite an Protokollen und Algorithmen, die VAXETs betreffen, innerhalb des Systems entwickeln zu können. Unter der Voraussetzung, dass WLAX-Hardware und -Treiber gefunden werden, die den Medienzugriff vollständig in Software implementieren, wäre es hier denkbar, den Medienzugriffsalgorithmus auch in den Benutzerbereich des Betriebsystems aus­zulagern, Obwohl das VPF-Konzept auf VAXETs ausgerichtet ist, könnte es prinzipiell auch zur Entwicklung beliebiger Xetzwerkstapel herangezogen werden. Das Treppenstufenmodell, das gewählt wurde, kann wieder zu einem reinen Schichtenmodell spezialisiert werden und zum Beispiel für Prototypen von SAXETs, MAXETs oder konventionellen TCP/IP-Stapeln dienen. Das Prototypensystem wurde klar auf einfache Entwicklung und Erweiterbarkeit ausgelegt. Die Umsetzung mit der objektorientierten Sprache C erlaubte die ausdrucksstarke Umset­ zung des Softwaremodells, wobei gleichzeitig durch die Mächtigkeit von C viele Möglichkeiten der Optimierung beibehalten werden. Während Xetzwerkstapel aus Gründen der Leistungsfä­higkeit typischerweise im Betriebsystemkern implementiert sind, hat man mit dem VPS die Möglichkeit, auch zur Laufzeit grofśen Einfluss auf den Stapel zu nehmen, ohne spezialisierte Kenntnisse in der Betriebsystementwicklung haben zu müssen.

Der vorgestellte Versuchsaufbau, der auch eingebettete Systeme integrierte, zeigt weiterhin, dass das vorgestellte Prototypensystem auch für Systeme mit beschränkten Ressourcen geeig­net ist. Das Prototypensystem ist damit bereits nah an einem realen Einsatzszenario für seri- enmäfsige VAXET-Systeme, Um den Aufbau der eingebetteten Systeme weiter zu optimieren, sollte noch über den Austausch der Bluetooth-GPS-Empfänger durch serielle GPS-Empfänger nachgedacht werden, damit Bluetooth und WLAX-Kommunikation hier garantiert keinen Ein­fluss aufeinander haben kann. Wünschenswert wäre weiterhin eine externe Antenne für die WLAX-Hardware für optimale Konnektivität, Mit diesen Modifikationen könnte die eingebet­tete Hardware auch fest in Testfahrzeuge integriert werden. Das VPS und die Visualisierung der Radarschirmapplikation starten auf den FMB-Einheiten vollständig autonom und begin­nen ohne manuellen Eingriff ihren Betrieb, trotz der teilweise schwierigen Verhaltensweisen der WLAX-Hardware und -Gerätetreiber, Durch den in die Einheiten integrierten Tastbild­schirm ist auch eine grafische Benutzeroberfläche für Applikationen und Steuerungsprogramme umsetzbar.

5 Ergebnisse und Ausblick

In Kapitel 2 wurde in dieser Arbeit zunächst eine Einführung in die Grundlagen von Fahrzeug- zu-Fahrzeug-Xetzwerken und Ad-Hoe-Xetzwerken im Allgemeinen gegeben. In Kapitel 3 sind höhere Xetzwerksehiehten und erweiterte Funktionalität von VAXETs behandelt worden. Insge­samt wurde so versucht, im theoretischen Teil der Arbeit einen weitreichenden Überblick über die besonderen Anforderungen von VAXETs und den Stand der Forschung zu geben. Dazu wurden einerseits alle Xetzwerksehiehten und deren VAXET-spezifisehe Herausforderungen be­leuchtet, Ein wichtiges Anliegen war es aber auch, die Verbindungen zwischen den Komponenten eines VAXETs herauszuarbeiten und ein Gesamtbild zu zeichnen. Dabei konnten wesentliche Aspekte identifiziert werden, die die Entwicklung jeglicher Xetzwerklogik für VAXETs beein­flussen sollten. Dazu zählt zum Beispiel die in VAXETs immer präsente Fehler Unfähigkeit, die als Xormalfall betrachtet und entsprechend damit umgegangen werden sollte. Aus dieser in­härenten Unzuverlässigkeit von VAXETs erwächst eine deutlich gröfsere Komplexität, aus der folgt, dass nur noch schwierig alle Parameter in VAXETs gleichzeitig optimiert werden kön­nen, Daraus und auch aus der Tatsache, dass die Betriebsbedingungen in VAXETs ständig Änderungen unterworfen sind, resultiert, dass Protokolle deutlich adaptiver und intelligenter werden müssen als sie in konventionellen Xetzwerken sind. Weitere Erkenntnisse sind, dass die Dezentralität und Kooperativität wesentliche Eigenschaften von VAXETs sind, an denen sieh Protokolle und Algorithmen orientieren müssen.

Zu vielen Fragestellungen gibt es noch keine endgültigen Antworten, Bei VAXETs handelt es sieh ganz deutlich immer noch um ein Forsehungsthema, Aufśer isolierten Anwendungen wird es naher Zukunft wohl keine umfassende, praktische Realisierung von VAXETs geben können. Auf der Ebene der Bitiibertragungs- und Sieherungssehieht ist die Schaffung eines ei­genen Standards für geeignete Funkhardware notwendig. Prinzipiell ist die vorhandene IEEE 802.11-kompatbile Hardware zwar geeignet, doch sind im Detail viele Anpassungen notwendig. Zumindest der Medienzugriff muss grundsätzlich überarbeitet werden. Der deutliche Einbruch des Datendurehsatzes ab einer Anzahl von 5 bis 10 Teilnehmern im Ad-hoe-Xetzwerk bei 802.11- Hardware ist für den produktiven Einsatz ein Aussehlusskriterium, Sollen auch sieherheits- und echtzeitkritische Anwendungen über das VAXET realisiert werden, sind voraussichtlich weitere Modifikationen auf der Hardwareebene notwendig. Ein geeigneter Standard hierfür ist unum- gänglieh, wenn die Interoperabilität zwischen verschiedenen Fahrzeugen gewährleistet werden soll.

Der Bereich der Vemittlnngssehieht ist bisher offensichtlich am stärksten von der Forschung behandelt worden. Obwohl eine Vielzahl von Rontingalgorithmen existiert zeigt sieh, dass sieh fiir VAXETs der Einsatz eines positionsorientierten Rontingprotokolls am ehesten eignet. Auch hybride Rontingalgorithmen bieten fiir VAXETs interessante Eigenschaften, Ein Schluss ans 3.1 ist aber auch, dass Ende-zn-Ende-Verbindungen nicht in beliebigem Ausmafś in VAXETs realisiert werden können, Zn lange Routen weisen auch bei Einsatz der gut geeigneten Rou­tingprotokolle eine grofśe Fehlerhänfigkeit auf, die bis zur Unbenntzbarkeit der Verbindung­en führen kann, Zn der Transportsehieht gibt es nicht so viele Arbeiten, wie zu den tieferen Komponenten im Xetzwerkstapel, Doch auch hier sind VAXET-spezifisehe Anpassungen un­bedingt notwendig, sofern ein komfortables, verbindungsorientiertes Transportprotokoll zum Einsatz kommen soll. Hierbei wurde festgestellt, dass das Festhalten an Komponenten des konventionellen TCP/IP-Stapels keinen Sinn für VAXETs ergibt und daher eine vollständig eigene Protokollfamilie entwickelt werden muss. Weder das IP-Routing noch die Adressierung oder das TCP-Transportprotokoll sind für VAXETs geeignet. Die Interoperabilität zwischen VAXETs und anderen Xetzwerken wie dem Internet hingegen muss über Übersetzungsproto­kolle an Schnittstellenknoten geschehen.

Spezielle Xetzwerkfunktionalitäten wie Dienstgüte oder Mehrpunktverbindungen stellen für Fahrzeug-zu-Fahrzeug-Xetzwerke eine besondere Herausforderung dar. Die Anforderungen müs­sen hier gegenüber konventionellen Xetzwerken reduziert werden, da die Fehleranfälligkeit sehlieht nicht die dieselbe Qualität und Zuverlässigkeit erlaubt. Hingegen treten in VAXETs noch andere Anforderungen auf, die von hoher Bedeutung sind. Darunter fällt etwa die Her­stellung von Gleichberechtigung unter allen Knoten, um der kooperativen Struktur entgegen­zukommen, Aber auch Xaehbarsehaftsprotokolle sind ein wesentliches Element von VAXETs, das Berücksichtigung finden muss. Ein Aspekt, der in konventionellen Xetzwerken in der Form ebenfalls fehlt, ist die Bedeutung von externen Sensordaten wie Positionsinformationen oder digitalen Kartendaten für viele Protokolle und Anwendungen, Dabei gibt es eine ganze Klasse von Applikationen, die Informationsverbreitungsanwendungen, die sieh primär auf Positions­und Sensorinformationen stützt.

Im praktischen Teil dieser Arbeit in Kapitel 4 wurde sehliefślieh ein Konzept für ein VAXET- Prototypensystem entwickelt und implementiert. Dazu wurde eine Softwarearchitektur konzep- tioniert, die es erlaubt, flexibel verschiedene Konfigurationen eines VAXET-Protokollstapels zu entwickeln und zu evaluieren. Um den neuartigen Elementen von VAXETs zu entsprechen, wur­de das OSI-Schichtenmodell zu einem Stufenmodell erweitert, das den Applikationen erlaubt auf beliebige, tiefere Schichten zuzugreifen. Das Konzept von Xetzwerkagenten erlaubt die enge Kopplung von dem Netzwerk immanenten Diensten an den Protokollstapel, Die Integration eines Rahmenwerks und einer klaren Schnittstellen- und Modulspezifikation im VPF erlaubt eine gewisse Plattformunabhängigkeit und die leichte Austauschbarkeit verschiedener VAXET- Protokollschichten in konkreten Implementierungen von VAXET-Protokollstapeln, Das model­lierte System wurde mit einfachen Protokollen für die Rundfunkschicht, den Xachbarschafts- agenten und einer Radarschirmanwendung demonstrativ in die Praxis umgesetzt und in einem Versuchsaufbau sowohl auf PC-Hardware, als auch auf eingebetteter Hardware mit vier Teilneh­mern getestet. Dieses Prototypensystem erlaubt die Überführung von theoretischen Konzepten in die Praxis, um neue Erfahrungen gegenüber der Theorie oder reinen Simulationsumgebungen zu gewinnen.

VAXETs bleiben weiterhin ein spannendes Thema und ein Forschungsgebiet in dem noch viel Gestaltungsspielraum besteht. Wird eine Realisierung von VAXETs in grofśem Umfang gelingen, bestehen völlig neue Möglichkeiten für die Verkehrsregelung und für Fahrerassistenz, die den Strafsenverkehr noch deutlich sicherer und angenehmer gestalten werden, als es derzeit der Fall ist.

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Index

Überlastkontrolle, 84, 102, 116

Anwendungen

Fahrzeugnetze, 18

militärische, 15

Sensornetze, 16

Anwendungsklassen, 5, 10

Applikationen

Ausstattungsquote, 10

Echtzeitfahrerassistenz, 7, 70, 91

Informationsverbreitung, 5, 84, 130

Infotainmentapplikationen, 8, 91

Ausführungsstrang, 160

Benutzerbereich, 160

Datenverbindungsschicht, 159

Dead Reckoning, 11

Funkreichweite, 20, 36

Gefahrenwarnung, 6, 132

Gerätetreiberschnittstelle, 156

Gleichberechtigung, 29, 31, 100, 114

in-network processing, 134, 151

Infrastruktur, 4, 7, 14, 140

intelligente Antennen, 36, 42, 50, 125

intelligenter Staub, 17

Internet

Adressierung, 110

Internetzugang, 8, 91, 140

Interprozesskommunikation, 160

Kooperation, 13, 18, 30, 117

Koppelnavigation, 11

Dezentralitât, 66

Diensterkennung, 14, 140

Dienstgüte, 91

digitale Kartendaten, 11, 72, 142

direktionaler Funk, 36

Einbruchserkennung, 120

Frequenzband

ISM, 20

Funkausbreitung, 142

Funkhardware, 20

Medienzugriff

ausgelieferter Knoten, 24

Einfluss auf TCP, 33

Flussinformationen, 32, 106

Fragmentierung, 28

IEEE 802.11

Medienzugriff, 25

Kollision, 22

Kollisionsvermeidung, 25, 30

empfängerbasierte, 33

Kontrollnachrichten, 26

Medienzugriff bei Rundfunk, 29

räumliche Wiederverwendung, 38

Rundfunk, 43, 46

Broadcast Storm, 46

Skalierbarkeit, 28

Taubheit, 39, 41

unidirektionale Verbindungen, 138

versteckter Knoten, 24

Wettbewerb um das Medium, 25

Zeitscheibenverfahren, 42

Zellenaufteilung, 34

Mehraufwand, 49, 59, 64, 80, 88, 106

Mobilfunk, 4, 20, 34

Mobilitätsmodell, 142

Multi-Hop Kommunikation, 13

Xaehbarsehaftsprotokoll, 85, 116

Beacons, 85

HALLO-Xaehriehten, 85

Xavigationssystem, 5

Xetzwerkagent, 157

Xetzwerkgraph, 14

Xetzwerkpartitionen, 13

Xutzenbewertung, 116

omnidirektionaler Funk, 36

OSI Modell, 22, 151

passiver Funk, 17

Positionierung, 11, 13, 85, 137

Protokollformate, 170

Rahmenwerk, 155

Routing

Cluster, 60

Gruppenkommunikation, 94

hierehisehe Protokolle, 59

hybride Protokolle, 68

Lücken, 73

Latenz, 79, 91

Lebenszeit von Routen, 77

Mehrfachpfade, 76

Mehrpunkt Verbindungen, 94

Ortungsdienst, 71

passives Mithören, 64

Pfadlänge, 76

positionsbasierte Protokolle, 71

proaktive Protokolle, 56

Protokollklassen, 55

reaktive Protokolle, 62

Reparaturmechanismen, 79

Routenselektion, 76

Sackgassen, 73

stromsparendes, 128

tabehengesteuerte Protokolle, 56

Zwischenspeicher, 62

Rundfunk

Broadcast Strom, 46

Fluten, 46

geographischer, 45, 132

intelligenter, 49

Klassen, 44

lokaler, 44

Medienzugriff, 46

netzweiter, 45, 51, 70

positionsbasierter, 52

Rundfunkschicht, 157

Schichtenmodell, 153

Sensoren, 7, 11, 16, 87, 131, 151

Simulator

Xetzwerksimulator, 142

Verkehrssimulator, 142

Smart Dust, 17

Store&Forward, 135

Stromkapazität, 15, 18, 124, 128

Stufenmodell, 153

Teilnehmer dichte, 30

Verkehrssteuerung, 6

VPF, 155 VPS, 155

Literaturverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

---

¹ Fahrzcugnctzworko sind eine Form von mobilen Ad-Hoe-Xetzwerken