Routingfehler und Nachrichtenverlust

Abbildungen 6.3 bis 6.8 zeigen die Nachrichtenverlustraten aufgeschlüsselt nach allen Simulationsparametern. Jeder Messwert wurde als Mittelwert von fünf Simulationsläufen mit den angegebenen Parametern errechnet. Die Fehlerfälle sind grob in vier Klassen einzuteilen: Geocast-Routingprobleme, Unicast-Routingprobleme, Kollisionen und verzögerte Nachrichten.

6.4 Ergebnisse

Verzögerte Nachrichten sind strenggenommen keine verlorenen Nachrichten. Wird jedoch die Latenz bei der Auslieferung zu hoch, wird ein Benutzer eine Nachricht dennoch als verloren ansehen. Die Akzeptanzgrenze wurde in diesem Graphen auf60Sekunden gesetzt.

Bei Untersuchungen zum Unicast-Traffic ist zu beachten, dass Verbindungen knotenweise generiert wurden. Daraus resultiert, dass z.B. in der Unicast-Stufe „low“ bei100mobilen Knoten deutlich mehr Unicast-Verbindungen angefordert werden als bei nur30Knoten.

Reaktiver Geocast

Die Werte bei reaktivem Geocast sind wie folgt zu interpretieren:

Keine Geocast-Route beim Absender Der Knoten, der eine Geocast-Sendeanforderung er-halten hat, konnte keine Route ins Zielgebiet finden.

Keine Geocast-Route auf Zwischenknoten Ein weiterleitender Knoten konnte eine Nach-richt nicht per Geocast-Routing weiterleiten. Der Next-Hop auf der Route ins Zielgebiet war nicht mehr verfügbar und die Bestimmung einer alternativen Route ist fehlgeschla-gen.

Keine Unicast-Route Ein Knoten konnte ein Paket aufgrund einer fehlenden Unicast-Route nicht weiterleiten. Tritt bei reaktivem Geocast nicht auf, da das Routing ausschließlich auf Geocast-Routen beruht.

Kollision EinGEO-DATA-Paket ist durch eine Kollision beim Versand verloren gegangen.

Paket verzögert Die Nachricht wurde erst mehr als60Sekunden nach der Sendeanforderung im Zielgebiet ausgeliefert.

Es fällt zunächst auf, dass kaum Routingprobleme auf Zwischenknoten auftreten, d.h. wenn eine Route einmal aufgebaut ist, ist diese sehr stabil. Der Fall der auf Zwischenknoten unterbrochenen Route berücksichtigt nur Geocast-Routingfehler, die nicht behoben werden konnten. Ebenfalls auffällig ist, dass reaktiver Geocast mit nur wenigen Infrastrukturknoten vergleichsweise viele Nachrichten verspätet ausliefert. Die wahrscheinlichste Erklärung ist, dass durch die Mobilität der Knoten Routen doch häufig abreißen und somit bei einer Auslieferung die Route unter Umständen mehrfach repariert werden muss.

Weiterhin ist zu beobachten, dass Paketverluste und Probleme bei der Routensuche oft in ähnlichem Maße wachsen. Gründe für das Nichtauffinden einer Route können Netzpartitio-nierungen, Mobilität von Knoten während der Routensuche und Verlust der Routing-Pakete sein. Während Netzpartitionierungen gerade bei den Simulationen mit30und50mobilen Knoten relativ häufig auftreten, ist die Mobilität ein eher vernachlässigbarer Faktor. Zum einen bewegen sich stets nur einzelne Knoten, zum anderen sollte das mehrfache Aussenden derGEO-RREQ-Nachrichten beim Expanding Ring Search ausreichend Redundanz bieten, um Knoten, die sich während der Routensuche wegbewegen, zu umgehen und eine Route ins Zielgebiet zu finden.

6 Evaluierung

6.4 Ergebnisse

6 Evaluierung

6.4 Ergebnisse

Als einziger Grund verbleibt also das Problem der Paketverluste. Da für den Aufbau einer Route zunächst ein Round-Trip – GEO-RREQ zum Zielgebiet und GEO-RREP zurück zum Sender – erforderlich ist, bevor ein GEO-DATA-Paket auf die Reise gehen kann, ist leicht ersichtlich dass in nicht-partitionierten Netzen Routingfehler beim Absender und der Verlust vonGEO-DATA-Paketen durch Kollisionen in ähnlichen Größenordnungen liegen müssen.

AODV-basierter Geocast ist auf eine vollständige Infrastruktur angewiesen. Bei 30 bzw.

50mobilen Knoten ist das Netz ohne Infrastrukturknoten zu dünn, um Routen finden zu können. Bei100mobilen Knoten verkehrt sich diese Eigenschaft allerdings ins Gegenteil:

Wird das Netz zu dicht, werden deutlich weniger Routen gefunden. Ohne die Mesh-Router an jeder Lokation ist die Routenfindung mit 100 mobilen Knoten deutlich zuverlässiger.

Der Grund hierfür dürfte sein, dass bei einem Broadcast in einem dichteren Netz die Kollisionswahrscheinlichkeit höher ist, d.h. dass mehrGEO-RREQ-Pakete verloren gehen.

Weiterhin kann man erkennen, dass AODV-basierter Geocast sehr empfindlich gegenüber der Gesamtlast des Netzes ist. Wenn mehr Unicast-Verbindungen angefordert werden oder mehr Geocast-Routen gesucht werden müssen, steigt der Anteil von Routingfehlern und Kollisionen extrem an. Die Bewegungsgeschwindigkeit von Knoten spielt dagegen kaum eine Rolle.

Insgesamt scheint AODV-basierter Geocast am besten geeignet für Netze mit einer mittleren Knotendichte und geringem Verkehrsaufkommen.

Hierarchischer Geocast

Die Werte bei hierarchischem Geocast sind wie folgt zu interpretieren:

Keine Geocast-Route beim Absender Falls der Absender ein DR ist, kennt er keine Route zu einem anderen DR, der sich näher am Zielgebiet befindet. Ist der Absender kein DR, kennt er keinen DR für seinen Präfix.

Keine Geocast-Route auf Zwischenknote Ein DR, der eine Nachricht von einem anderen Knoten weiter durch den Routing-Baum leiten sollte, kennt keinen anderen DR, der sich näher am Zielgebiet befindet.

Keine Unicast-Route Ein Knoten, der eine Nachricht weiterleiten sollte, kennt keine Unicast-Route zum Ziel der Nachricht.

Kollision Die Nachricht ist aufgrund einer Kollision beim Versand verloren gegangen.

Paket verzögert Die Nachricht wurde erst mehr als60Sekunden nach der Sendeanforderung im Zielgebiet ausgeliefert.

Routingfehler bei Absendern, die keine DRs sind, werden nicht gesondert aufgeführt. Zum einen tritt dieser Fehler in den Simulationen vernachlässigbar selten auf, zum anderen kann er sehr einfach behoben werden: Jeder Nicht-DR muss eine Sendeanforderung solange

6 Evaluierung

6.4 Ergebnisse

6 Evaluierung

6.4 Ergebnisse

aufbewahren, bis er wieder einen DR kennenlernt. Üblicherweise passiert dies, nachdem ein Knoten für einige Sekunden an einer Lokation verweilt.

Insgesamt sehen die OLSR-Ergebnisse deutlich schlechter aus als die Ergebnisse von AODV:

Die Nachrichtenverlustrate liegt nur sehr selten unter 70%. Leicht zu erkennen ist, dass nahezu alle Nachrichten, die nicht durch Routingfehler verworfen werden, durch Kollisionen verloren gehen. Dies ist der hohen Grundlast durch OLSR zuzuschreiben. Da Knoten ständig hello- undTC-Nachrichten generieren und versenden, ist der Übertragungskanal bereits stark belastet.

Wie bei reaktivem Geocast gibt es auch in diesem Fall mehrere Gründe für Routingfeh-ler: Netzwerkpartitionierungen, Mobilität und der Verlust von Routing-Informationen. Da sich die Menge der Routingfehler mit der Knotenanzahl kaum ändert, sind Netzwerkpar-titionierungen hier wohl kaum ein Problem. Dass Mobilität ein starker Faktor ist, wird daraus ersichtlich, dass sich bei Simulationen ohne vollständige Infrastruktur der Anteil der Routingfehler in etwa verdoppelt. Die verbleibenden Fehlerfälle verteilen sich in etwa gleichmäßig auf Unicast- und Geocast-Routingfehler, was darauf hindeutet, dass sehr viele TC- bzw.DRA-Pakete verloren gehen.

Im Vergleich zu AODV fällt auch auf, dass in OLSR-Simulationen der Anteil verspäteter Nachrichten sehr gering ist. Allerdings ist die statistische Signifikanz dieses Wertes in den OLSR-Simulationen durchaus anzuzweifeln, da nur verhältnismäßig wenige Nachrichten ihr Zielgebiet erreicht haben.