Geocasting in Mobile Ad Hoc Networks

Seminar Middleware für mobile Systeme (WS 2002/2003)

 

Referent: Daniel Nofftz

Inhalt:

 

1. Einführung:

1.1 Was ist  Geocast?

1.2 Motivation

1.3 Exkurs: Broadcast Storm Problem

2. Geocasting Protokolle

2.1 Allgemeines

2.2 Location Based Multicast

2.3 GeoGRID

2.4 GeoTORA

3. Abschließende Bewertung

4. Herkunftsverzeichnis der Grafiken

5. Literaturverzeichnis

 

 

 

 

 

1. Einführung

 

1.1 Was ist Geocast ?

In einem Geocast sendet ein Knoten (Sendeknoten) eine Nachricht (Datenpaket) an eine Empfängergruppe, die durch ihre geografische Position bestimmt ist (Geocast-Gruppe bzw. Zielgruppe). Die Idee des Geocastings wird zuerst von Jiang und Camp [1] erwähnt und dort als Erweiterung  des Internets vorgeschlagen, und nicht als Anwendung für Mobile Ad-Hoc Netzwerke. Es wird dort beschrieben, wie man Nachrichten (Datenpakete) an Knoten innerhalb eines Polygons oder Kreises, definiert durch Breiten und Längenangaben, sendet.

 

Grundsätzlich hat Geocasting eine große Ähnlichkeit zu einem Multicast, nur dass anstatt einer Multicast-Adresse eine geografische Region (z.B. definiert durch Längen- und Breitenangabe) adressiert wird. Dabei tritt man einer Geocasting-Gruppe bei, indem man ein bestimmtes Gebiet betritt, und verläst die Gruppe, indem man das Gebiet wieder verläst. (Im Gegensatz zu einem Multicast, in dem man einer Multicast-Gruppe durch abbonieren einer bestimmten Multicast-Adresse beitritt).

 

Geocasting setzt natürlich voraus, dass die Knoten des Netzwerkes ihre eigene Position kennen (siehe hierzu Vortrag „Bestimmung der eigenen Position“ in der gleicher Seminarreihe).

 

1.2 Motivation

Bereits heute erreichen PDA’s und Notebooks eine immer größere Verbreitung. In naher Zukunft wird dieser Umstand sicherlich noch zunehmen und weitere mobile computergestützte Geräte wie Smartphones, Wearable’s , usw. mit einschließen. Dazu wird in diesen Geräten die Fähigkeit zur kabellosen Kommunikation mit anderen Geräten immer selbstverständlicher werden, genauso, wie immer mehr dieser Geräte über die Fähigkeit verfügen werden ihre Position möglichst genau zu bestimmen (z.B. über GPS).

Dies wird ganz neue Anforderungen mit sich bringen, aber auch ganz neue Möglichkeiten der Kommunikation in kabellosen Netzwerken. Eine dieser neuen Möglichkeiten ist Geocasting: das Versenden von Nachrichten (Datenpaketen) in bestimmte geografische Zielregionen.

 

Mögliche Anwendungsgebiete für Geocasting sind:

 

1.3 Exkurs: Broadcast Storm Problem

Broadcasting ist in Netzwerken eine verbreitete Operation zum Lösen vieler Aufgaben (z.B. ARP-Requests). In mobilen Ad-Hoc-Netzen wird durch die hohe Mobilität die Verwendung von Broadcasting noch stärker ausgeprägt sein, als das in normalen Netzwerken schon der Fall ist (z.B. zum Pflegen von Routing-Tabellen oder um einen Überblick über die „Nachbarschaft“ zu behalten).

 

Genau hier entsteht aber ein großes Problem:  Da sich Funksignale überlappen bzw. überlagern können, wird einfaches Broadcasting eine teure Operation u.a. mit vielen redundanten Datensendungen, Paketkollisionen und hoher Netzlast, welche natürlich auch einen hohen Energieverbrauch mit sich bringen. Diesen (vereinfacht dargestellten) Umstand nennt man das „Broadcast Storm Problem“ [3].

 

Da gerade beim Geocasting nahezu jedes Protokoll in irgendeiner Weise Broadcasting in Form von Flooding einsetzt, sollte ein Ziel der Protokollansätze sein, unnötiges Broadcasting/Flooding zu vermeiden.

 

 

2 Geocasting Protokolle

 

2.1 Allgemeines

Die in den letzten Jahren vorgestellten Geocasting Protokolle lassen sich grob in zwei Kategorien einteilen: floodingbasierte und routenerzeugende Protokolle.

 

Floodingbasierte Protokolle:

Floodingbasierte Protokolle nutzen Flooding (oder eine Variante davon) um die Nachricht/Nachrichten ins Ziel zu übermitteln. Das Ziel ist dabei, eine möglichst hohe Zuverlässigkeit der Datenübertragung zu erreichen. Zuverlässigkeit bedeutet, Möglichst viele der potenziellen Zielknoten sollen erreicht werden. Insbesondere wird keine Route zum Zielgebiet erstellt.

Vorteile des floodingbasierten Ansatzes sind u.a., dass kein Overhead für das Erstellen und Verwalten von Routen anfällt, und gleichzeitig eine hohe Zuverlässigkeit erreicht wird. Der größte Nachteil liegt sicherlich in der meist erheblich höheren Netzlast, die diese Protokolle erzeugen.

Von den floodingbasierten Protokollen werden Location Based Multicast (LBM) und   GeoGRID vorgestellt.

 

Routenerzeugende Protokolle:

Routenerzeugende Protokolle erstellen zuerst eine Route zum Zielgebiet und nutzen diese dann zum übermitteln der Daten in die Zielregion. Der größte Vorteil dieses Ansatzes liegt  darin, dass wesentlich weniger Netzlast anfällt, dafür muss aber der erhöhte Aufwand für das Erstellen und Pflegen der Routen in Kauf genommen werden.

Von den routenerzeugenden Protokollen wird GeoTORA vorgestellt.

 

 

 

Grundliegende Eigenschaften:

Um die Vorstellung der Protokolle zu vereinfachen, werden folgende Eigenschaften als gegeben angesehen:

1. Jeder Knoten muss seine eigene Position kennen. Das kann z.B. durch GPS oder andere Techniken geschehen.

2. Wenn ein Knoten in der Zielregion ein Geocast Paket erhält, flooded er es zu allen anderen Knoten im Zielgebiet. Da der Overhead des eigentlichen Geocasts aber in der Regel wesentlich größer sein sollte als das lokale Flooding im Zielgebiet und man so im Zielgebiet den Vorteil des Floodings, nämlich die hohe Zustellsicherheit nutzt, ist es eine naheliegende Methode.

3. Die Knoten bzw. das eingesetzte Netzmedium müssen über eine  Methode verfügen, um Kollisionen von Übertragungen zu vermeiden. Da dies bei der heutigen WLAN-Realisierung gegeben ist, muss man sich um dieses Problem bei der Realisierung der einzelnen Protokolle keine Gedanken mehr machen.

4. Mit Ausnahme von Ticket-based GeoGRID (s.u.) broadcastet jeder Knoten ein Paket nur einmal während eines Geocasts. (Dies ist natürlich nur eingeschränkt möglich, da aufgrund des begrenzten Speicherplatzes eine Mitprotokollierung nur für einen begrenzten Zeitraum möglich ist, also immer nur eine Liste z.B. über die letzten X Pakete existiert.)  Durch diesen Umstand vermeidet man das Auftreten von Ping-Pong oder Loop Effekten, also dass sich zwei oder mehr Knoten ständig gegenseitig die Pakete hin und herwerfen oder dass die Pakete im Kreis herumgereicht werden.

Punkt 3 und 4 entschärfen unter anderem auch die Broadcast Storm Problematik ein wenig.

 

Bewertungskriterien:

Die erstrebenswerten Ziele bei der Realisierung von Geocasting-Protokollen, und damit auch die Kriterien, an denen sich die einzelnen Protokolle messen müssen, sind:

1. Niedrige Netzlast: Niedrige Netzlast heißt letztlich auch niedrigeren Stromverbrauch für die mobilen Knoten, weniger Speicherverbrauch, weniger Auslastung des Netzwerkmediums; also generell ein niedriger Ressourcenverbrauch. Dies ist gerade in mobilen Ad-Hoc Netzwerken sehr wichtig.

2. Hohe Zuverlässigkeit: Es müssen möglichst viele der Knoten in der Zielregion tatsächlich erreicht werden.

 

2.2 Location Based Multicast (LBM)

 

Location Based Multicast ist das älteste vorgestellte Protokoll [4] (1999) für mobile Ad-Hoc-Netze. Es handelt sich dabei um eine Erweiterung des Location-aided Routing [5] (1998) für Geocasting.

 

Bei LBM sind zwei verschiedene Methoden möglich, mit denen man das Geocasting realisieren kann:

 

Methode 1: Hier wird eine sogenannte ‚Forwarding Zone’ definiert, in welcher dann Flooding benutzt wird um die Datenpakete ins Zielgebiet zu übermitteln. Nur Knoten innerhalb der Forwarding Zone flooden die Pakete weiter, Knoten welche sich außerhalb der Forwarding Zone befinden, flooden die Pakete nicht weiter.

 

In der Regel wird als Forwarding Zone das kleinste Rechteck genommen (Beispiel: Abbildung 1 (b)), welches sowohl das Zielgebiet als auch den Sendeknoten umfasst. Andere Formen können durchaus auch zur Realisierung der Forwarding Zone gewählt werden, auch wenn diese experimentell bis jetzt nicht evaluiert worden sind. Als Beispiel für andere geometrische Formen zur Realisierung der Forwarding Zone nennt der Autor z.B. einen Konus (zu sehen in Abbildung 1a), in welchem der Sendeknoten in der Spitze sitzt und die Zielregion das obere Ende des Konus einnimmt.

 

Textfeld: Abbildung 1: Darstellung einer konusförmigen (a) und einer rechteckigen Forwarding Zone (b).

Ein Problem  dieses Ansatzes kann z.B. sein, dass sich innerhalb der Forwarding Zone kein Weg zum Zielgebiet befindet, dafür aber knapp außerhalb der Forwarding Zone. In Abbildung 1a zu sehen: Zielknoten Y ist innerhalb der Forwarding Zone nicht erreichbar, obwohl knapp außerhalb ein Weg existiert. Um diesen Umstand etwas abzuschwächen, kann man die Forwarding Zone auch in jede Richtung um x Meter erweitern, um so auch etwas indirektere Wege abzudecken.

 

 

 

Methode 2: Hier wird die Entscheidung, ob ein Knoten ein Geocasting-Paket weiterleitet (bzw. floodet) nicht anhand einer Zone gefällt, sondern anhand eines Distanzvektors zum rechnerischen Mittelpunkt.

Um das Problem lokaler Minima („greedy routing Fehler“) zu umgehen, leiten dabei nicht nur Knoten das Paket weiter, welche näher an der Zielregion sind, sondern auch Knoten, welche nicht mehr als x Meter weiter vom Ziel entfernt sind, als der Knoten, von welchem das Datenpaket empfangen wurde.

 

 

 

 

Textfeld: Abbildung 2: LBM Methode 2

 

 

 

 

Methode 1 ist die Methode, welche am häufigsten zitiert wurde. Die meisten Simulationen werden in der Regel mit der Methode 1 verglichen.

 

Abschließende Bewertung:

Die Simulationsergebnisse zeigen, dass beide Methoden in ihrer Zuverlässigkeit nur geringfügig niedriger sind als pures Flooding. Gleichzeitig ist die Gesamtnetzlast erheblich niedriger!

Gerade Methode 1, bietet dabei sicherlich noch einige Optimierungsmöglichkeiten, ein Ansatz hierzu ist GeoGRID.

 

2.3 GeoGRID

GeoGRID ([6], 2000 , GRID: [7], 2001) unterteilt das Netzwerk in Kästchen der Größe d * d Meter. Als bester Wert hat sich in den Simulationen dabei der Wert sqrt(2) * r/3 erwiesen, wobei r dem Senderadius der Knoten entspricht. Bei diesem Wert deckt der Senderadius eines Knoten im Mittelpunkt eines Kästchen komplett die Kästchen über, unter und neben dem Kästchen ab, diagonal liegende Kästchen werden dagegen nur teilweise abgedeckt.

In jedem Kästchen übernimmt nun nur noch ein einzelner Knoten (der Gateway) das Weiterleiten der Daten.

 

Gateway Election:

Wichtig für GeoGRID ist eine vernünftige Wahl des Gateways. Optimal wäre dabei natürlich ein Gateway der möglichst nahe am Mittelpunkt des Kästchens ist (wegen der besseren Abdeckung der Nachbarkästchen durch den Senderadius). Deshalb ist es wichtig auf das Verfahren der Gateway-Wahl einzugehen.

 

Textfeld: Abbildung 3: Ein Geocasting Beispiel für GeoGRIDZuerst einmal bleibt ein Gateway, wenn er erst einmal gewählt wurde, solange Gateway, wie er sich in dem Kästchen aufhält. Dies geschieht, um einen Ping-Pong Effekt zu vermeiden. Dabei nehmen sich ein oder mehrere Knoten gegenseitig immer wieder die Aufgabe als Gateway ab, weil gerade einmal der eine näher am Mittelpunkt ist, und gleich darauf der andere wieder.

 

Ein Gateway meldet sich periodisch bei allen Knoten (Paket: GATE(g,loc), mit g = Koordinaten des Kästchens und loc = Position des Knotens). Wenn ein Knoten zu lange nichts mehr von dem Gateway seines Kästchens gehört hat, schlägt er sich spontan selbst als Gateway vor (Paket: BID(g, loc)). Darauf meldet sich entweder der richtige Gateway (mit seinem GATE-Paket), oder ein anderer Knoten, welcher näher am Mittelpunkt liegt, schlägt sich vor.

Passiert weder das eine, noch das andere, erklärt sich der Knoten zum Gateway und gibt dies (mit dem entsprechenden GATE-Paket) bekannt.

 

Wenn ein Gateway den Bereich seines Kästchens verläst, tritt er als Gateway explizit zurück, indem er ein RETIRE(g,T) sendet (T = Routing-Tabelle). Dabei sollte jeder Knoten nach Möglichkeit die Gatewaysituation in den Nachbarfeldern überwachen und sich beim Betreten eines scheinbar leeren Feldes direkt als Gateway vorschlagen.

 

 

Auch bei GeoGRID  gibt es zwei Realisierungsansätze:

 

Flooding-Based-GeoGRID:

Dieser Ansatz funktioniert im Grunde genauso wie LBM/Methode 1, nur mit dem Unterschied, das hier lediglich die Gateways die Pakete weiterflooden. Als Forwarding Zone kommt das kleinste Rechteck, welches sowohl den Sendeknoten als auch die Zielregion enthält zum Einsatz.

 

Ticket-Based-GeoGRID:

Hier wird ein weiterer Schritt unternommen, um die Netzlast innerhalb des Flooding-Bereiches bzw. der Forwarding Zone möglichst gering zu halten. Der Sendeknoten flooded  nicht einfach drauf los, sondern gibt eine bestimmte Anzahl von „Tickets“ heraus. Jedes Ticket stellt dabei sozusagen einen nummerierten Zustellungsbefehl dar, welcher jeweils für die Zustellung einer Kopie des Geocasting-Paketes in die Zielregion zuständig ist.

Der entscheidende Unterschied zum Flooding-Based GeoGRID ist, dass beim Ticket-Based-GeoGRID ein Gateway ein Paket unter Umständen auch dann weiterleitet, wenn er eine Kopie dieses Geocasting Paketes schon einmal weitergeleitet hat, nämlich dann, wenn dieses ein für ihn neues Ticket besitzt.

 

Die Tickets welche ein Gateway erhält, werden von dem Gateway möglichst gleichmäßig an alle Nachbarkästchen verteilt, welche näher zum Ziel liegen (sofern dort ein Gateway bzw. ein Knoten existiert).

Bei der Anzahl der zu vergebenden Tickets ist natürlich ein Trade-off zwischen Netzlast und Zuverlässigkeit nötig. Der Autor schlägt eine Anzahl von n+m Tickets vor, wobei n und m die Seitenlängen der Zielregion, gemessen in Kästchen, sind.

 

Bewertung:

Die gelieferten Simulationsergebnisse zeigen, dass beide Formen des GeoGRID eindeutig weniger Netzlast erzeugen als LBM/Methode 1. Gleichzeitig erreichen  sie aber eine Zuverlässigkeit, welche sehr nahe an LBM liegt.

Zusätzlich zeigt sich, dass die Zuverlässigkeit von Ticket-Based GeoGRID kaum niedriger als die von Flooding-Based GeoGRID ist, gleichzeitig aber die geringere Netzlast von beiden Ansätzen erzeugt.

GeoGRID ist somit eine gelungene Weiterentwicklung der LBM-Idee und ist diesem Protokoll gegenüber vorzuziehen. Dabei empfiehlt sich vor allem die Verwendung von Ticket-Based-GeoGRID, da dieses gemessen an dem Trade-off zwischen Zuverlässigkeit und Netzlast die bessere Wahl darstellt.

 

2.4 GeoTORA

GeoTORA gehört zu den routenerzeugenden Geocasting Protokollen und versucht durch das Erstellen einer Route (bzw. mehrerer alternativer Routen) eine hohe Zuverlässigkeit zu wahren und gleichzeitig die Netzlast entscheidend zu reduzieren.

 

TORA, das Unicast-Protokoll auf welchem GeoTORA aufbaut, hat einige grundliegende Eigenschaften, die kurz skizziert werden sollen: TORA versucht redundante Routen zum Ziel zu finden, so dass in einem optimalen Fall gleich mehrere Routen existieren, aus welchen der Sendeknoten wählen kann. Diese redundanten Routen werden dadurch gewonnen, dass das Protokoll einen gerichteten azyklischen Graphen aufbaut, in welchem alle Kanten Richtung Ziel zeigen. Hierzu verwendet TORA den Begriff der „Höhe“, welcher grob der Anzahl der Hops (also Sprünge von Knoten zu Knoten) entspricht, welche bis zum Zielknoten zurückzulegen sind (eine genaue Beschreibung des Höhebegriffes erfolgt weiter unten). Dabei zeigt eine Kante immer von dem Knoten mit größerer Höhe zu dem Knoten mit der niedrigeren Höhe.

Ein Vorteil von TORA ist, dass sich recht einfach das wegfallen eines Links (Link-Failure) oder eine Netzpartition feststellen lassen und die Routen entsprechend angepasst werden.

 

Routenerstellung:

Den Mechanismus, mit welchem GeoTORA eine Route zum Zielgebiet generiert, wir nun genauer betrachtet: Zuerst sendet der Ursprungsknoten (also der, von dem die Nachricht ins Zielgebiet übermittelt werden soll) per Flooding einen Anycast mit dem Hinweis darauf, dass er eine Route ins Zielgebiet sucht, an die Zielregion. D.h. er will mindestens einen Knoten im Zielgebiet erreichen und dabei ist es ihm vollkommen egal, welcher Knoten im Zielgebiet das ist. Hier muss besonders darauf hingewiesen werden, dass die Verwendung von Flooding in diesem Fall nicht annähernd so ressourcenkonsumierend ist wie im Falle der floodingbasierten Algorithmen, da es sich hier nur um Kontrollpakete handelt und nicht um große Datenpakete.

Textfeld: Abbildung 4: Routenerstellung in TORA (A sucht Route zu G)Erhält ein Knoten im Zielgebiet die Anycast-Nachricht, wird ein Mechanismus in Gang gesetzt, mit welchem die Route rückwärts (Link-reversal) aufgebaut wird. Dies geschieht folgendermaßen:

Der Empfangsknoten in der Zielregion gibt sich selbst die Höhe 0 und gibt allen Knoten in seiner Umgebung seine Höhe bekannt. Andere Knoten in der Zielregion geben sich ebenfalls die Höhe Null und verfahren ebenso. Sie sind damit die niedrigsten Knoten.

Jeder Knoten außerhalb der Zielregion setzt nun seine eigene Höhe um eins höher als die Höhe  seines „niedrigsten“ Nachbarn. Und gibt seine eigene Höhe wiederum bekannt.

Sollte sich zu einem späteren Zeitpunkt seine Höhe ändern, z.B. in dem ein Knoten die Zielregion betritt oder verlässt, oder einen „niedrigeren“ Nachbarn bekommt, (oder seinen niedrigsten Nachbarn verliert, worauf er seine Höhe evtl. neu bestimmen muss) passt er seine Höhe an und gibt die neue Höhe bekannt.

 

So entsteht nach und nach ein dynamischer Graph, welcher sich ständig an das sich verändernde Netz anpasst. Die Kanten in diesem Graphen sind gerichtet, aber um die Richtung der Kanten zu bestimmen, muss erst noch der Höhenbegriff  genauer erläutert werden.

 

 

Die Höhe besteht aus dem Vektor (t, oid, r, h, i), wobei gilt:

t = Zeitpunkt des Linkfehlers

oid  = Name/Identifikation des Knotens mit dem Linkfehler

r = Reflektionsindikator

h = eigentliche Höhe

i = Name/Identifikation des Knoten

t, oid, r sind nur im Falle eines Link-Fehlers  nötig

h ist der Höhenwert von dem bis jetzt gesprochen wurde.

 

Eine Kante läuft nun jeweils von einem Knoten mit einer höheren Höhe zu einem Knoten mit einer niedrigeren Höhe. Zwischen zwei Knoten welche die gleiche Höhe h haben, gilt der Knoten mit dem höheren Namen als der insgesamt höhere Knoten. D.h. Wenn Knoten X und A den Wert h = 3 besitzen läuft die Kante zwischen den beiden Knoten von X nach A[1].

 

Damit entsteht ein gerichteter azyklischen Graph, in welchem alle Kanten Richtung Zielregion zeigen. Erreicht die sich rückwärts-aufbauende Route nun den ursprünglichen Sendeknoten, muss dieser einfach nur die zu übermittelnden Datenpakete dem „Gefälle“ nach, also der Kantenrichtung nach, senden.

 

Geocasting mit GeoTORA:
Wie vollführt GeoTORA nun einen Geocast ?

1. Route zum Zielgebiet aufbauen

2. Sobald Route steht: Pakete dem „Gefälle“ nach zum Zielgebiet übermitteln

3. Wie auch bei den anderen Protokollen, übermittelt der Knoten im Zielgebiet, welcher als

erstes die Geocasting-Pakete erhält, diese per Flooding an alle anderen Knoten im Zielgebiet.

 

Bewertung von GeoTORA:

Leider bietet der Autor nur Simulationsergebnisse im Vergleich zu LBM/Methode 1. Die Ergebnisse zeigen, dass GeoTORA eine hohe Zuverlässigkeit besitzt, wenn auch nicht so hoch wie LBM. Gleichzeitig ist der Overhead im Vergleich zu den floodingbasierten Verfahren signifikant niedriger, da nur am Anfang einmal ein Flooding mit (kleinen) Kontrollpaketen stattfindet.

 

Einer der Hauptgründe für die im Vergleich zu LBM schlechtere Zuverlässigkeit ist, dass GeoTORA die Nachrichten nur auf einem Weg in die Zielregion sendet.  Wenn nun das Netz innerhalb der Zielregion partitioniert ist, wird nicht die ganze Zielregion erreicht.

 

3. Abschließend

 

Generell lässt sich feststellen, dass ein Trade-Off zwischen Netzlast und Zuverlässigkeit nötig ist. Hohe Zuverlässigkeit wird meist mit erhöhter Netzlast erkauft und wenn möglichst wenig Netzlast entstehen soll, geht dies auf Kosten der Zuverlässigkeit.

Es währe in diesem Zusammenhang interessant, wenn vergleichbare Simulationsergebnisse für Ticket-based GeoGRID und GeoTORA existieren würden.

 

 

 

 

 

4. Herkunftsverzeichnis der Grafiken:

 

Abbildung 1:    Aus [4], Seite 4

 

Abbildung 2:    Aus [4], Seite 6

 

Abbildung 3:    Aus [1], Seite 4

 

Abbildung 4:    Aus [8], Seite 4

 

 

 

5. Literaturverzeichnis/Verweise:

[1]       Xia Jiang und Tracy Camp: A Review of Geocasting Protocols for a Mobile Ad Hoc Network, Proceedings of the Grace Hopper Celebration (GHC), 2002

[2]       J.C. Navas und T. Imielinski: Geocast – geographic adressing and routing. In

Proceedings of the ACM/IEEE International Conference on Mobile Computing and

Networking (Mobicom), 1997

[3]       S.-Y. Ni, Y.-C. Tseng und J.-P. Sheu. The broadcast storm problem in a mobile ad

            hoc network. In Proceedings of the ACM/IEEE International Conference on Mobile

Computing and Networking (Mobicom), Seiten 151-162, 1999

[4]       Y. Ko und N.H. Vaidya, Geocasting in mobile ad hoc networks: Location-based multicast algorithms. In Proceedings of the 2nd IEEEE Workshop on Mobile Computing Systems and Applications (WMCSA), 1999

[5]       Y. Ko und N.H. Vaidya, Location-aided routing (LAR) in mobile ad hoc networks. In Proceedings of the ACM/IEEE International Conference on Mobile Computing and Networking (Mobicom), Seiten 66-75, 1998

[6]       W.-H. Liao, Y.-C- Tseng, K.-L. Lo und J.-P. Sheu. Geogrid: A Geocasting protocol for mobile ad hoc networks based on grid. Journal of Internet Technology, 1(2):Seiten 23-32, 2000

[7]       W.-H. Liao, Y.-C- Tseng und J.-P. Sheu. Grid: A fully location-aware routing protocol for mobile ad hoc networks.. Telecommunication Systems, 18(1):Seiten 37-60, 2001

[8]       Y. Ko und N.H. Vaidya. GeoTORA: A protocol for Geocasting in mobile ad hoc networks. 8th International Conference on Networking Protocols (ICNP), November 2000

[9]       Vincent D. Park und M. Scott Corson. A Highly Adaptive Distributed Routing Algorithm for Mobile Wireless Networks, 2001

[10]     V. Park und S. Corson. Temporally-ordered routing algorithm (TORA) version 1 functional specification. Internet Draft: draft-ietf-manet-tora-spec-04.txt, July 2001



[1] wenn man X als größeren „Wert“ betrachtet als A ... das hängt natürlich von der Realisierung ab. In der Praxis könnte man z.B. die MAC Adresse des Netzwerkadapters nutzen,  und diese als Bitvektoren miteinander vergleichen