Geographic Routing using a Cell Structure in Wireless Ad-hoc Networks

UNIVERSIDAD CARLOS III DE MADRID

INGENIERÍA DE TELECOMUNICACIÓN

PROYECTO FIN DE CARRERA

Geographic Routing using a Cell Structurein Wireless Ad-hoc Networks

Autora:Inés María Bebea González

Tutores:Celeste Campo VázquezDpto. Ingeniería Telemática

Universidad Carlos III de Madrid

Stefan RührupHeinz Nixdorf Institut

Universidad de Paderborn

Octubre de 2007

A mamá

III

Agradecimientos

Hoy es un día importante. No ya por la defensa de este Proyecto en sí y por el extensotrabajo realizado, sino porque viene a ser además el fin formal de una larga etapa de mivida. Junto a la nostalgia que a todo final acompaña y los recuerdos difuminados por el pa-so del tiempo, que me quiten lo bailaoo y la inquietante expectativa ante lo que queda por vivir.

Me siento enormemente afortunada por haber tenido acceso a la formación académica queahora termina y a la gran cantidad de vivencias que la han acompañado en estos seis años.Gracias ante todo a mi familia por su confianza y apoyo en todo momento y, sobre todo, pordejarme soñar.

A todos aquellos que he encontrado en el camino aquí y allá, junto a los que he aprendido ycompartido alegrías y algún disgusto, bailes, paseos, laboratorios, risas, debates, bibliotecas,éxitos y fracasos, viajes, luchas, sueño y sueños... GRACIAS.

V

Resumen

Contexto

El presente Proyecto Final de Carrera es el resultado de dos años de trabajo que se han desa-rrollado en las Universidades de Paderborn (Alemania) y Carlos III, de ahí que el grueso delproyecto se presente en lengua inglesa. Durante el primer año el proyecto fue desarrollado enAlemania y tutelado principalmente por Stefan Rührup, con el cual se llevó a cabo el diseñode CGFP de manera conjunta. El segundo año continuó dicho trabajo con Stefan ahora a dis-tancia desde la Universidad Carlos III con el apoyo de Celeste Campo. El producto final detan prolongados esfuerzos es la tesis que se presenta a continuación.

Motivación

Una red ad-hoc inalámbrica consta de una colección de nodos dispersos geográficamenteque se comunican entre sí mediante ondas electromagnéticas propagándose en el aire. Lasredes ad-hoc se caracterizan además porque son redes distribuidas y generalmente los nodosson aparatos con memoria y batería limitadas, lo cual fuerza al ahorro energético a todacosta. Las comunicaciones inalámbricas gozan de gran interés debido a la dificultad paraencontrar rutas fiables entre pares de nodos comunicantes. Un nodo emisor generalmentedeberá enviar un mensaje a través de varios nodos intermedios hasta alcanzar su destino,debido a que el radio de cobertura de cada nodo es limitado y no cubre ni mucho menos todoel área dispuesto para la red. El problema adquiere mayor complejidad al considerar nodosmóviles, ya que la topología de la red cambiará constantemente. Sin embargo, es crucialpoder asegurar que todos los mensajes generados en la red se entregarán a sus destinos: éstaes la tarea de los protocolos de enrutado. Este Proyecto se centra en protocolos de enrutadobasados en posicionamiento para redes ad-hoc inalámbricas, en los cuales se asume los nodosson capaces de determinar su localización geográfica. En anteriores investigaciones se ha

VII

demostrado que el reenvío de paquetes utilizando información geográfica no es complicado.Sin embargo, existen situaciones más complicadas, como regiones de baja densidad de nodoso topologías inconexas que disparan la pérdida de paquetes. Para estos casos se ha de procedercon otras decisiones para encontrar rutas alternativas.

Las redes ad-hoc han recibido un interés creciente en los últimos años y se han expandido enmultitud de campos incluida la interconexión de dispositivos electrónicos personales comoportátiles, móviles y PDAs, redes de comunicación para emergencias y desastres naturales,redes de sensores, infraestructura básica de comunicaciones en regiones aisladas del planeta,etc. Su diseño y perfeccionamiento envuelve diversos campos de la ingeniería desde eldesarrollo hardware, construyéndose cada vez dispositivos de menor tamaño aunque mayorcapacidad y prestaciones, a desarrollo software en aplicaciones y estrategias de comunicaciónmás avanzadas. Sin embargo, la mayor limitación de los dispositivos ad-hoc es su consumoenergético, el cual viene principalmente de la comunicación: potencia de transmisión yrecepción. Es posible encontrar una extensa bibliografía al respecto acerca de diseño deantenas para redes ad-hoc, diseños de circuitería electrónica, técnicas de acceso al medio yestrategias de enrutado pensados para reducir al mínimo dicho consumo.

Como ya se ha comentado, el radio de transmisión de los nodos en redes ad-hoc es limitado,por lo que se han desarrollado estrategias de enrutado multisalto. Existen multitud de algorit-mos para controlar la topología de la red de modo que cada nodo pueda encontrar rutas hacialos demás. Se puede distinguir entre protocolos centralizados o localizados. Los primerosasignan a ciertos nodos un conocimiento más extenso o total de la red mientras los demásnodos han de consultarlos, aunque esto hace que ciertos nodos sean críticos. Los segundossólo precisan la interacción de los nodos con sus vecinos próximos para lograr objetivosglobales. También cabe diferenciar entre estrategias proactivas, basadas en tablas de rutaspermanentemente actualizadas, y reactivas, donde la topología se construye sólo como pasoprevio a la comunicación. En protocolos geográficos o basados en posicionamiento el hechode disponer de una visión tan reducida de la red se complementa con el conocimiento delas posiciones geográficas. Dichos algoritmos son localizados y no manejan tablas de rutas,ya que esto tiene un coste elevado. Dado que se conoce dónde se encuentra el destinatario,los paquetes se envían trazando una ruta que implique progreso en cada salto, esto es, encada salto el paquete estará más cerca del destinatario. En esto consiste el método greedy deenrutado.

VIII

En ocasiones no es posible progresar, y el paquete se queda bloqueado en algún nodo o segeneran bucles en regiones de la red más despobladas. Para recuperarse de estas situacionesexisten varios métodos recovery. Uno de ellos consiste en planarizar la topología y así parapoder bordear el área hueca siguiendo la regla de la mano derecha. Ésta es la técnica desa-rrollada en GPSR [KK00], Greedy Perimeter Stateless Routing, y que se estudia en detalle eneste Proyecto, incluyéndose la implementación de dicho protocolo. Sin embargo, precisamen-te debido a la planarización se inutilizan numerosos enlaces, sobrecargando algunos nodos dela red. Por ello se ha diseñado a lo largo de este Proyecto un nuevo protocolo basado en unaestructura celular de la red, Cell-based Geographic Forwarding Protocol, basado en las indi-caciones propuestas por Rührup [RS05] En este protocolo todos los enlaces en la topología dered son susceptibles de ser utilizados en la creación de rutas.

Objetivos

El objetivo central de este proyecto es el diseño de un protocolo de enrutado basado en unaestructura cuadriculada y su implementación y evaluación de prestaciones mediante el uso deuna herramienta de simulación de redes. Para ello se debe desarrollar un amplio estudio sobrelas técnicas de enrutado en redes ad-hoc y más concretamente sobre enrutado geográfico.Asimismo ha de conocer el algoritmo GPSR e implementarlo en la herramienta de simulaciónescogida, y por tanto, aprender a manejar dicho simulador. Esta implementación se compararácon aquella del nuevo protocolo para así realizar un estudio comparativo de prestaciones,haciendo más fiable la validación del protocolo propuesto.

Estado del Arte

En esta sección se realiza una descripción del estado del arte de las técnicas de enrutadogeográfico, en especial GPSR, y de las herramientas de simulación de redes.

En routing geográfico, las decisiones de reenvío se basan en la posición del destinatario y laposición de vecinos intermedios a un salto de distancia (1-hop neighbors). Greedy PerimeterStateless Routing, GPSR, es una estrategia que utiliza tan sólo información local en losnodos. Un nodo conoce las posiciones de sus vecinos tras haberlas recibido en sucesivosbroadcasts llamados beacons. GPSR utiliza generalmente la regla greedy y una técnica

IX

recovery para sortear barreras o huecos cuando greedy falla. Existen varios métodos greedy,pero el implementado en GPSR es MFR, Most Forwarding wirhin Radius, que decide por elvecino que consigue más progreso hacia el destinatario.

Cuando hay baja densidad nodal en una zona de la red, se dice que encontramos una barrera.En estos casos, puede suceder que el nodo que tiene el paquete sea el más próximo de entresus vecinos, y la regla greedy se bloquea. Para ello GPSR bordea la barrera siguiendo la reglade la mano derecha (ver Figura 2.1). En ocasiones esta estrategia puede incurrir en bucles,cuando entre varios nodos hay enlaces que se cruzan. Esto se evita planarizando la topologíade la red y eliminando de éstos los enlaces más largos. La planarización se basa en que latopología puede ser representada como un grafo donde los nodos son los vértices y las aristasse dibujan entre nodos conectados directamente, esto es, si la distancia euclídea entre ellos escomo mucho el radio de transmisión común a ambos. En general los grafos son no planares,por lo que es necesario realizar una conversión que puede aplicarse localmente. GPSR utilizados tipos de planarización: Gabriel Graph y Relative Neighborhood Graph. Entonces, GPSRaplica su técnica recovery frente a barreras sobre la topología previamente planarizada.

Desafortunadamente, la planarización priva al enrutado de los enlaces más largos entre nodos,de modo que elimina la posibilidad de encontrar la ruta más corta entre emisor y destinatario.Por esta razón, Rührup [RS05] propone una herramienta de control topológico local que evitaesta desventaja. La idea es construir una estructura virtual de clusters gegráficos que contieneinformación de los vecinos de segundo salto (2nd-hop) en cada nodo. Los nodos clasificanlas celdas que "ven"según haya vecinos, enlaces o barreras. Esta estructura se construyelocalmente en cada nodo y contiene la información necesaria para aplicar las técnicas greedy

y recovery.

El diseño de protocolos de comunicaciones debe ser evaluado mediante técnicas de modela-do y simulación. En la actualidad existen modelos simplificados que permiten definir dichosprotocolos utilizando lenguajes orientados a objetos como Java o C++, que facilitan la exten-sión y adaptación de los modelos. Existen muchos simuladores de redes y probablemente elmás extendido es ns-2, un simulador de eventos discretos. Sin embargo, la implementaciónen este entorno es ardua y apenas se puede extender a redes no IP. OMNeT++ sin embargoes un simulador de eventos discretos mucho más manejable, ya que se compone de módulosjerárquicos y se programa en lenguaje C++. En OMNeT un nodo de la red puede definirse

X

como un módulo que se compone de submódulos para los diversos niveles de comunicación:aplicación, transporte, red y enlace. Cada uno de ellos se programa por separado como unaclase C++, y todos los nodos de la red son instancias de este módulo. OMNeT incluye ademáslibrerías soporte para enrutado. Al tratarse se una herramienta de código abierto, otros desa-rrolladores pueden ampliar sus librerías fácilmente. Para el desarrollo de este Proyecto ha sidocrucial la existencia de las librerías de la extensión Mobility Framework como soporte paranodos inalámbricos y móviles. Sin embargo, OMNeT tiene aún mucho trabajo por delante, ylas herramientas de procesado estadístico son algo pobres. Aun así, se puede complementarcon programas de cálculo como Matlab, para realizar cálculos y representaciones gráficas máselaboradas.

Cell-based Geographic Forwarding Protocol

El diseño e implementación del protocolo CGFP, Cell-based Geographic Forwarding Proto-col, ha consumido los mayores esfuerzos en el desarrollo del presente Proyecto. CGFP generauna estructura celular (cell structure) que es una abstracción de la red en tanto representauna clasificación de las diferentes regiones del territorio de red en una cuadrícula virtual(ver Figura 3.1). Dicha estructura se compone de celdas enlace (link cells) y celdas barrera(barrier cells), las cuales indican en qué regiones es posible la comunicación y en cuáles no.Cada división en la cuadrícula se denomina celda, su tamaño es directamente proporcional alradio de transmisión y cada celda es identifica de forma unívoca por sus coordenadas celulares.

CGFP asume que la localización geográfica de los nodos es conocida mediante un cierto ser-vicio de posicionamiento. Como el tamaño de las celdas es conocido, resulta inmediato paratodos los nodos traducir sus coordenadas geográficas en coordenadas celulares globales. Losnodos de la red almacenan información sobre el área que los rodea también en forma de es-tructura celular, pero esta vez indexada por coordenadas celulares locales relativas a la celdadonde se encuentra dicho nodo, i.e. este nodo en su propia estructura celular se encuentra enla celda (0,0). Cada nodo clasifica las celdas a su alrededor en 3 tipos:

– link cells, aquéllas contenidas en la mitad del radio de transmisión de cualquier nodo oaquéllas cortadas por una arista,

– barrier cells, contenida en el radio de transmisión,

– unclassified cells, exterior al radio de transmisión o más cercana a algún vecino.

XI

Como CGFP es un algoritmo distribuido, cada nodo almacena una lista de sus vecinos ytambién dos vistas (Views). Las vistas son estructuras celulares que contienen celdas basadasen información de vecinos a uno o dos saltos de distancia respectivamente. La primeravista , View 1, posee información de primera mano que cada nodo difunde periódicamentejunto a la lista de vecinos, mientras que la segunda, View 2 es utilizada localmente en elproceso de enrutado. Las vistas (Views) se inicializan en cada nodo al desplegarse la red. Sinembargo, estas estructuras han de ir actualizándose a medida que se recibe información delos vecinos y, en redes móviles, cuando el propio nodo se desplaza. La tarea de actualizar lasestructuras celulares requiere gran cuidado, ya que si fallamos, el enrutado también quedaráinservible. En la implementación surgieron problemas concretos con estas actualizacionesque se comentan e ilustran con ejemplos en el capítulo 3.

En el protocolo CGFP las rutas de paquetes se construyen basándose en la estructura celular yutilizando estrategias de reenvío greedy y recovery con la regla de la mano derecha. Cada vezque un nodo recibe un paquete cuyo destinatario es otro, debe reenviarlo. Si el destinatario seencuentra entre sus vecinos, entonces deberá entregar el paquete al vecino correspondiente,y en caso contrario deberá escoger un vecino situado en la posición más prometedora. Esteprocedimiento es análogo a GPSR, salvo que la decisión se realiza ahora en base a la estruc-tura celular. El paquete recibido contiene información acerca de la celda actual, donde residevirtualmente. Desde dicha celda, el nodo construye una ruta virtual entre celdas ortogonalesen View 2 aplicando greedy o recovery hasta encontrar una celda perteneciente a un vecino,al cual se reenvía físicamente el paquete. Este procedimiento se repite en cada salto hasta quelos paquetes son entregados a los destinatarios correspondientes.

Implementación

OMNeT++ es un simulador de eventos discretos basado en jerarquías modulares. Los módulosse especifican utilizando un lenguaje propio de OMNeT, NED, y sus funciones se programanposteriormente utilizando clases C++. Los parámetros fijos en cada módulo se pueden definira priori en las simulaciones mediante los archivos de inicialización, omnetpp.ini. También loscampos las cabeceras de mensajes intercambiables entre nodos de la red se pueden codificaren archivos MSG, cuya arquitectura se importa desde los diferentes módulos para generar yencapsular paquetes.

XII

En las simulaciones de redes utilizando OMNeT se han definido:

– escenario: un área rectangular de simulación donde se sitúan los nodos de la red.

– nodos: las características de los nodos de la red: protocolos de comunicación, movili-dad...

– formato de mensaje: cabeceras y datos contenidos en los paquetes de comunicación.

– parámetros relativos al modelo comunicativo a nivel físico, temporizadores, etc.

– generación de estadísticas: recolección de los eventos importantes sucedidos durante lasimulación para caracterizar y evaluar el comportamiento de los protocolos implemen-tados.

La implementación de los protocolos de enrutado geográfico GPSR y CGFP depende de laconstrucción de una pila de protocolos, similar a los niveles OSI, que defina el comportamien-to de los nodos desde el nivel físico al de aplicación. A nivel físico las ondas electromagnéticasrecibidas por el aire se han de convertir en información digital. En un nivel superior se hande implementar técnicas de control acceso al medio, MAC, para evitar colisiones entre lastransmisiones de nodos cercanos que se comunican en el medio inalámbrico. Estas dos capasse implementan en el Mobility Framework como un único módulo nic, network interfacecontrol. Existe en estas librerías una implementación del estándar IEEE 802.11 para WLANs,que es el utilizado como capa de enlace en las simulaciones de este Proyecto por tres simplesrazones: es un estándar bien definido, la implementación existente de GPSR aunque en ns-2utiliza este estándar, y además está ya programado en OMNeT++/MF. Tanto GPSR comoCGFP son los responsables de garantizar la entrega de paquetes en la red siempre que existauna ruta entre emisor y destinatario. Por ello, estos protocolos se han implementado en nivelde red, esto es, en el módulo net. En nivel superior se encontrarían los niveles de transportey aplicación, que se han simplificado en un único módulo appl capaz de generar y absorbertráfico. Además de estos tres submódulos de comunicación, un nodo definido en MF contieneademás otros dos submódulos: blackboard y mobility, encargados de pasar información entremódulos y proporcionar movilidad al nodo e información sobre su posición geográfica enel escenario respectivamente. El paquete WLAN contenido en la versión de Mobility Fra-mework 1.0a5 utilizado en este Proyecto es todavía muy básico y no soporta retransmisionesni colisiones en zonas muy densamente pobladas. Por ello sólo ha sido posible experimentarcon escenarios estáticos.

De manera esquemática, las funciones que realiza GPSR son:

XIII

– difusión de beacons,

– encontrar una ruta hacia la posición del destinatario,

– mantener la información local actualizada, esto es, la lista de vecinos.

En CGFP se ha creado un módulo específico, denominado cellstr, que gestiona la estructuracelular: actualizaciones y descubrimiento de rutas en celdas. Dicho módulo realiza las siguien-tes tareas complementarias a las antes mencionadas para también GPSR:

– encontrar una ruta virtual en la estructura celular hacia la posición del destinatario,

– actualizar las estructuras celulares (Views).

Con el fin de ilustrar de forma práctica el funcionamiento de CGFP en OMNeT++, el ejemplosiguiente muestra la generación de tráfico en un nodo:

1. El módulo de aplicación genera un mensaje para un destinatario aleatorio tras un even-to de timeout. El módulo mobility proporciona información acerca de la posición deldestinatario y la clase cTopology de OMNeT calcula la longitud de la ruta si es queexiste. Los datos del mensaje se encapsulan en una cabecera que contiene identificadory posición del destinatario. El paquete se pasa al nivel inferior.

2. El módulo net recibe el paquete. Si el destinatario está registrado en la lista de vecinos,entonces se encapsula y se entrega al módulo nic para que lo reenvíe a dicho vecino. Encaso contrario, el paquete se pasa al módulo cellstr para que descubra el camino virtualen View 2 y, consecuentemente, el nodo de siguiente salto.

3. Una función en cellstr comienza a descubrir rutas, en modo greedy o recovery segúncorresponda, y al llegar a una celda donde no puede avanzar, almacena en el mensajelas coordenadas de dicha celda y el vecino a que pertenece. El paquete se devuelve almódulo net, que lo reenviará al vecino correspondiente.

4. El módulo net encapsula el mensaje incluyendo información para el enrutado virtual enel siguiente nodo. El paquete se entrega al módulo nic, para que inicie el algoritmo decontienda que transmitirá la información evitando colisiones.

Con el objetivo de asegurar la fiabilidad de los resultados obtenidos, se han realizado múlti-ples simulaciones variando ciertos parámetros y generando escenarios diversos permitiendoun grado controlable de aleatoriedad, que permite que se repitan exactamente las mismassituaciones con ambos protocolos, facilitando la comparación de sus prestaciones. Durantelas simulaciones se han recogido datos acerca de la longitud de las rutas trazadas por cada

XIV

protocolo, la complejidad de los escenarios propuestos en cuando a la dificultad de sortearbarreras y la memoria consumida en los nodos para almacenar información local. Lasejecuciones se automatizaron usando scripts y awk, mientras los cálculos estadísticos y lasgráficas se generaron con MATLAB.

Para conocer en profundidad las implementaciones presentadas en este Proyecto se remite allector al anexo B que incluye una breve documentación de las clases implementadas para elprotocolo CGFP. El CD-ROM que acompaña este texto contiene el código completo escritopara la simulación de GPSR y CGFP, así como código adicional empleado en el procesado delas muestras estadísticas.

Resultados

En este apartado se explican las experiencias obtenidas con cada protocolo por separado,así como un estudio comparativo de ambos. En primer lugar, se muestran los estadísti-cos correspondientes a las simulaciones de GPSR: una comparación de las longitudes delas rutas descubiertas utilizando dos planarizaciones diferentes: Gabriel Graph y RelativeNeighborhood Graph, y el detalle de las rutas recovery para los escenarios propuestos. Estaexperiencia muestra que en situaciones de alta densidad nodal, un porcentaje mínimo depaquetes necesitan la técnica recovery, como es de esperar ya que apenas existen barreras.Esto se aplica a escenarios estáticos donde los nodos se han colocado aleatoriamente. En estassimulaciones se observa cómo se pueden encontrar escenarios más complejos que ponen aprueba las técnicas recovery.

A continuación se realizan los mismos experimentos para CGFP, obteniendo conclusionessimilares. Adicionalmente se presenta una comparación de las rutas obtenidas en diversassimulaciones variando el parámetro del factor de celda, CF, que determina el tamaño de lacuadrícula base para la estructura celular. También en este caso se observa con claridad locomentado anteriormente respecto a la complejidad de los escenarios.

Posteriormente se han comparado ambos protocolos y su funcionamiento separado en modogreedy o recovery. En los resultados obtenidos se observa que la respuesta de GPSR para lospaquetes greedy es siempre ligeramente mejor, ya que el método MFR aporta más progreso

XV

que el enrutado de celdas. Por otro lado, en los paquetes recovery se distinguen dos patrones:CGFP funciona bien en escenarios aleatorios, mientras GPSR resulta más satisfactorio en losescenarios laberínticos. Esto se debe a que estas topologías son cuasi-planares y GPSR utilizatodos los enlaces posibles, luego CGFP no se beneficia de su mayor ventaja sobre GPSR.

Conclusiones y trabajo futuro

A lo largo de este Proyecto Final de Carrera se han implementado dos protocolos de enru-tado geográfico y se han analizado y comparado sus prestaciones. Este trabajo incluye unestudio detallado de la estrategias empleadas típicamente en redes ad hoc, especialmenteGPSR, así como el diseño de un nuevo protocolo, CGFP, basado en una estructura celular.CGFP, Cell-based Geographic Forwarding Protocol, se presenta en este texto y culminacon la copublicación de un informe técnico junto a Stefan Rührup [BR06]. Además ambosprotocolos han sido implementados y simulados en OMNeT++, una herramienta de códigoabierto para la simulación de redes. El trabajo desarrollado en este proyecto ha implicado, portanto, el estudio de la bibliografía existente y aprendizaje de diversas herramientas softwareincluyendo OMNeT++ y librerías adicionales, repositorios CVS, scripts.

Los resultados experimentales, que pretenden resumir una comparación entre los protocolosGPSR y CGFP, han demostrado que el protocolo propuesto CFGP es más eficiente en casosen los que la topología de red contiene barreras, mientras GPSR tiene una respuesta casiperfecta en redes sin barreras. Por este motivo se propone como trabajo futuro la combinaciónde la estrategia MFR utilizada por GPSR como técnica greedy y la mejora de la técnica deenrutado celular propuesta por CGFP en zonas con barreras. Por otro lado, cabe destacar quelas aspiraciones iniciales de experimentar con diversos patrones de tráfico y redes móviles sehan visto limitadas por la simplicidad de las funciones proporcionadas por OMNeT++/MF.En futuros trabajos seguramente muchos de las limitaciones encontradas queden solventadaspor el avance de estas y otras herramientas de simulación.

XVI

Acrónimos

ACK Acknowledgment message

AODV Ad hoc On-Demand Distance Vector Routing

AWK Programming language for processing text-based data

CDMA Code Division Multiple Access

CF Cell Factor for cell coordinate conversion in CGFP

CGFP Cell-based Geographic Forwarding Protocol

DREAM Distance Routing Effect Algorithm for Mobility

DSDV Destination-Sequenced Distance-Vector routing

DSR Dynamic Source Routing

FDMA Frequency Division Multiple Access

GG Gabriel Graph

GPS Global Positioning System

GPSR Greedy Perimeter Stateless Routing

INET INET Framework support for for wired, wireless and mobile simulations in OMNeT++

MAC Medium Access Control

MF Mobility Framework support for wireless and mobile simulations in OMNeT++

MFR Most Forward within Radius

NED Network topology description language for OMNeT++

NFP Nearest with Forward Progress

OMNET++ Objective Modular Network Test-bed in C++ simulation tool

PED Personal Electronic Device

RNG Relative Neighborhood Graph

XVII

SDMA Space Division Multiple Access

TDMA Time Division Multiple Access

UDG Unit Disk Graph

WLAN Wireless Local Area Network

WSN Wireless Sensor Network

XVIII

Índice general

1. Introduction 1

1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3. Thesis Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2. State of the art 9

2.1. Geographic Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.1. The Greedy Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1.2. Barriers and Perimeters . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.1.3. Greedy Perimeter Stateless Routing (GPSR) . . . . . . . . . . . . . . 12

2.1.4. The Cell-based approach . . . . . . . . . . . . . . . . . . . . . . . . 18

2.2. Simulation Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.2.1. OMNeT++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.2.2. Mobility Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.2.3. Statistical Data Collection and Processing . . . . . . . . . . . . . . . 24

3. The Cell-based Geographic Forwarding Protocol 25

3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2. The cell structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.2.1. Global and local coordinates . . . . . . . . . . . . . . . . . . . . . . 27

3.2.2. Classification of cells . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.2.3. Local information at nodes . . . . . . . . . . . . . . . . . . . . . . . 29

3.2.4. Initializing the cell structure . . . . . . . . . . . . . . . . . . . . . . 31

3.2.5. Updating the cell structure . . . . . . . . . . . . . . . . . . . . . . . 31

3.2.6. The problem of barrier classification . . . . . . . . . . . . . . . . . . 35

3.3. Forwarding messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

XIX

Índice general

4. Implementations 434.1. Details on the implementation of GPSR and CGFP . . . . . . . . . . . . . . 434.2. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.3. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.4. Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534.5. Validation and Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.6. Obtaining the results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5. Experimental Results 635.1. Statistics on GPSR protocol. . . . . . . . . . . . . . . . . . . . . . . . . . . 635.2. Statistics on CGFP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735.3. Path length comparison between GPSR and CGFP. . . . . . . . . . . . . . . 745.4. Path deviation comparison for greedy messages. . . . . . . . . . . . . . . . . 785.5. Path deviation comparison for recovery messages. . . . . . . . . . . . . . . . 815.6. Comments on the results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

6. Project History 876.1. Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 876.2. Project Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 886.3. Budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

7. Conclusions and further work 91

A. Notation in the pseudocode 93

B. Documentation 95B.1. CellStructure Class Reference . . . . . . . . . . . . . . . . . . . . . . . . . 95B.2. Cell Class Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97B.3. CellCoord Class Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . 98B.4. cNeighbor Class Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . 101B.5. cNetwLayer Class Reference . . . . . . . . . . . . . . . . . . . . . . . . . . 102B.6. cApplLayer Class Reference . . . . . . . . . . . . . . . . . . . . . . . . . . 104

XX

Índice de figuras

2.1. Local minima and perimeter recovery possibilities . . . . . . . . . . . . . . . 132.2. Greedy forwarding rule pseudocode. . . . . . . . . . . . . . . . . . . . . . . 142.3. RNG and GG planarizations. . . . . . . . . . . . . . . . . . . . . . . . . . . 152.4. For a full list of its neighbors, N, node u removes non-RNG links. . . . . . . 162.5. Right-hand rule: loop caused by crossing edges. . . . . . . . . . . . . . . . . 162.6. Main methods in GPSR for perimeter forwarding. . . . . . . . . . . . . . . . 172.7. Effects of planarization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.8. Wireless network with randomly positioned nodes generated using the Mobility Fra-

mework. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.9. Structure of a host in OMNeT++ using Mobility Framework. . . . . . . . . . . . . 23

3.1. Unit Disk Graph and grid subdivision for the same network region . . . . . . 263.2. CGFP solves the problem of crossing edges without the need of planarization. 263.3. Local coordinates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.4. Cell coordinate system. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.5. Directions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.6. Classification of cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.7. Classification of cells based only on the positions of the direct neighbors . . . 343.8. Enlarged view of node v (View 2). . . . . . . . . . . . . . . . . . . . . . . . 353.9. Incorrect classification of barrier cells at View 1. . . . . . . . . . . . . . . . 353.10. Solution to the problem of barrier classification. . . . . . . . . . . . . . . . . 373.11. Example on cell path construction in the presence of a barrier . . . . . . . . . 38

4.1. Simplified flowchart and state diagram for a node . . . . . . . . . . . . . . . 454.2. Modules in OMNET++ representing protocol stack of GPSR (left) and CGFP

(right). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.3. Description of main modules and classes of a CGFP host in OMNeT++. . . . 474.4. A host’s neighbor list in the simulations GUI. . . . . . . . . . . . . . . . . . . . 484.5. A node’s View 1 in the simulations GUI. . . . . . . . . . . . . . . . . . . . . . . 484.6. Random placement of 50 hosts in a small playground. . . . . . . . . . . . . . 504.7. Easy labyrinth scenario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.8. Random placement of 50 hosts in a large playground. . . . . . . . . . . . . . 514.9. Faulty grid with a wide deployed area. . . . . . . . . . . . . . . . . . . . . . 514.10. Example paths for a query and a reply. . . . . . . . . . . . . . . . . . . . . . 534.11. Simplest scenarios: one-row scenario and a disconnected topology. . . . . . . 55

XXI

Índice de figuras

4.12. GUI user-defined representation for View 1 suitable for error debug in the cellstructure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.13. Cell path construction in CGFP. . . . . . . . . . . . . . . . . . . . . . . . . 584.14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584.15. OMNeT++ windows describing network situation at a host. . . . . . . . . . 59

5.1. GPSR 50 nodes, small playground. . . . . . . . . . . . . . . . . . . . . . . . . 655.2. GPSR 50 nodes, medium playground. . . . . . . . . . . . . . . . . . . . . . . . 675.3. GPSR 50 nodes, large playground. . . . . . . . . . . . . . . . . . . . . . . . . . 685.4. GPSR 100 nodes, medium playground. . . . . . . . . . . . . . . . . . . . . . . 695.5. GPSR 100 nodes, large playground. . . . . . . . . . . . . . . . . . . . . . . . . 705.6. GPSR Easy Labyrinth. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715.7. GPSR Faulty Grid. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725.8. CGFP analysis for decreasing-density scenarios. . . . . . . . . . . . . . . . . 735.9. Path length Comparison. 50 nodes, small playground. . . . . . . . . . . . . . . . 745.10. Path length Comparison. 50 nodes, medium playground. . . . . . . . . . . . . . . 755.11. Path length Comparison. 50 nodes, large playground. . . . . . . . . . . . . . . . . 755.12. Path length Comparison. 100 nodes, medium playground. . . . . . . . . . . . . . 765.13. Path length Comparison. 100 nodes, large playground. . . . . . . . . . . . . . . . 765.14. Path length Comparison. Easy Labyrinth. . . . . . . . . . . . . . . . . . . . . . 775.15. Path length Comparison. Faulty grid. . . . . . . . . . . . . . . . . . . . . . . . 775.16. 50 nodes, small playground. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785.17. Greedy deviation Comparison. 50 nodes, medium playground. . . . . . . . . . . . 795.18. Greedy deviation Comparison. 50 nodes, large playground. . . . . . . . . . . . . . 795.19. Greedy deviation Comparison. 100 nodes, medium playground. . . . . . . . . . . 805.20. Greedy deviation Comparison. 100 nodes, large playground. . . . . . . . . . . . . 805.21. Greedy deviation Comparison. Easy Labyrinth. . . . . . . . . . . . . . . . . . . 815.22. Greedy deviation Comparison. Faulty grid. . . . . . . . . . . . . . . . . . . . . . 815.23. Recovery deviation Comparison. 50 nodes, small playground. . . . . . . . . . . . 825.24. Recovery deviation Comparison. 50 nodes, medium playground. . . . . . . . . . . 835.25. Recovery deviation Comparison. 50 nodes, large playground. . . . . . . . . . . . . 835.26. Recovery deviation Comparison. 100 nodes, medium playground. . . . . . . . . . 845.27. Recovery deviation Comparison. 100 nodes, large playground. . . . . . . . . . . . 845.28. Recovery deviation Comparison. Easy Labyrinth. . . . . . . . . . . . . . . . . . 855.29. Recovery deviation Comparison. Faulty grid. . . . . . . . . . . . . . . . . . . . 85

XXII

1. Introduction

1.1. Motivation

A Wireless Ad Hoc Network consists of a collection of geographically dispersed nodes thatcommunicate with each other over a wireless medium. First, it may be interesting to highlightsome crucial properties of such networks:

The communication environment is not wired and may include mobility also.

Decentralized. No node is more important than another and packets can be rerouted overany of them. The main difference is then that ad hoc networks do not rely on expensiveinfrastructure of base stations throughout the usage area. Instead, data packets hop fromone node to another until destination is reached.

Hosts are power constrained, as soon as they carry power limited batteries which arecostly to be replace, i.e. sensor nodes are hardly accessible in some sensor networksscenarios (earthquakes, forest-fire monitoring, etc.).

Communications in wireless networks are of particular interest due to the difficulty of dis-covering liable paths between pairs of hosts. A source node would typically send a messagethrough several intermediate nodes until it reaches some other destination node. The wirelessenvironment must be taken into account as soon as the network topology is variable whenconsidering mobility. Moreover link connectivity depends on factors such as the transmissionradius or signal attenuation. These details are beyond the scope of this thesis and thereforethey are considered as node parameters. However, it is a matter of routing to ensure packetdelivery in such scenarios. Networks are traditionally modeled using graphs and shortest pathalgorithms - Dijkstra or Floyd-Warshall are commonly computed. Although this can be easilyimplemented in wired networks, our routing problem requires now more specific solutions.Then approaches rely on on-line route discovery or the maintenance of routing tables.

1

1. Introduction

Multiple applications are being developed for ad hoc networks in recent years. The expansionon the use of various personal electronic devices (PEDs) follow the demand of interconnectingthem in an ad hoc fashion. These networks can also be used in disaster relief, such as fire,flood and earthquake, communications between vehicles, conference environments, tacticalcommunications and law enforcement (search and rescue). Other contexts include ad hocnetworks as auxiliary networks used in case of failure of the wired system, such as rooftopnetworks, static networks with nodes placed on top of buildings. A particularization of adhoc networks which receives an special interest are the so called Wireless Sensor Networks(WSN). Such networks are constituted by hundreds or thousands of small motes that areable to sense their environment in different manners: temperature, velocity, lightness, sound,etc. One could say that while ad hoc networks are in general node centric, WSN are datacentric, as communication is based on the interest of collect specific information in a certainregion and not to communicate a couple of determined users. WSN are oriented to potentialcommercial applications such as emergency response, real time or building safety monitoring.Also developing countries can benefit from the autonomy of ad hoc networks. Seoane et al.[SOSM06] suggest the design of a solar-powered wireless node for low costs static meshnetworks. Other applications which are still under development, are ad hoc access to WLANInternet access points, packet radio networks, etc.

Ad hoc networks have received growing interest in recent years and they involve variousfields in Telecommunications engineering, from hardware development in terms of antennadesign, high frequency and electronic circuitry to topology, routing or application schemes.

The main restriction in ad hoc networks design is to reduce power consumption of thenetwork. Nodes mainly have a small power supply unit, an antenna, a processor, localmemory and some peripherals, such as a photo diode for light measurement in a sensornetwork. The activity that consumes more energy at node is communication: transmitting andreceiving power. Thus, two main different techniques have been proposed: reduce numberof transmissions per communication link between pairs of nodes while maintaining powertransmission level for all nodes, or adjust transmission power level and redirect the antenna tothe destination node. The first goal is achieved using topology control ensuring connectivitywith minimal transmission power for each node and for the second goal, technical approacheson smart antennas for mobile ad hoc networks exist.

2

1.1. Motivation

Nodes that share a wireless medium need techniques of channel multiple access: TimeDivision Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), CodeDivision Multiple Access (CDMA) and Space Division Multiple Access (SDMA). This workdiscusses routing protocols over the medium access control (MAC) protocol of the IEEE802.11 Wireless Local Area Network (WLAN) Standard, based on a TDMA schedule.

Because, by definition, the responsibilities of organizing and controlling an ad hoc networkare distributed to each node, efficient routing protocols must be designed in a distributedmanner and also be independent of topology. This work focuses on position-based routing inwireless ad-hoc networks, where each node has the ability to determine its own geographicalposition. Geographical routing improvements focus on consuming minimum node storage andenergy, and choosing the good direction in order to bring the packet nearer to its destination.Previous researches [BMSU01, KWZ02, GS04, KSU99] demonstrated that forwardingpackets towards a destination is not complicated using geographical information of certainareas in the network. However, one must also consider other special cases, i.e. low nodedensity or disconnected graphs increase packet losses because a path does not necessarilyexist for every pair of nodes in the network. In those cases other routing decisions follow inorder to recover from the cul-de-sac and find another path.

Limited transmission radius leads to multi-hop routing schemes because in general, directcommunication between source host and destination is not feasible. Frequently, in ad hocnetworks hosts are both end-terminals and routers at the same time. As said before, both hostmobility and also variable node activity produce topology changes.

Various topology control schemes have been proposed in order to have a fast response overtopology variations. The most basic requirements for an ad hoc network are connectivity andenergy efficiency, e.g. if a node moves away from the neighbor which is connected to thegraph then a handover to a new neighbor occurs. A rough classification distinguishes betweencentralized or localized algorithms, and proactive or on-demand. Centralized protocols fortopology update need to know conditions at every point in the network and those nodes areof higher importance than the rest. Consequently a failure occurring on a critical node maycause serious problems on protocol functionality. On the other hand, localized algorithmsonly require interaction of the nodes with neighbors in close proximity in order to achieveglobal objectives. Secondly, both routing and topology schemes can also be proactive (e.g.

3

1. Introduction

DSDV [PB94]) or on-demand (e.g. DSR [JM96]). For the first ones, the routing tables areperiodically updated with recent changes on the network or on the nodes, and also uptodateroutes are stored. In contrast, on-demand algorithms build the topology only when a pairof nodes want to communicate, i.e. flooding schemes. Routing protocols presented in thisthesis are localized and relay on a proactive topology control of the neighborhood (based onbeaconing) and on-demand routing. Thus reduced ’visual fieldóf nodes is complemented byknowledge of geographical positions.

The traditional routing approach based on IP addressing leads to huge overhead and lowscalability when considering ad hoc networks. Addressing is still a matter of research in suchwireless environments. For now, let hosts know their own position. The Global PositioningSystem as an example for obtaining location of nodes is not so preposterous, as tiny and lowcost GPS receivers are already commercial. This document assumes positioning informationis accurate, although real systems poses some problems in terms of reliability. Thus a routingscheme which uses such information would address network nodes with respect to theirposition. Note that the combination of localized topology techniques with position-basedrouting causes that a node is only conscious of the sub-topology of its neighborhood, which isa subgraph where the node itself and their neighbors are included. This solution is both logicaland effective, as soon as it supports scalability and robustness to mobility. As an example,in sensor networks, the useful information one expects to collect from a host is interestingbecause certain measurements must be done in a given area, but the node itself is unimportant.

Position-based or geographical routing does not manage tables of routes. Such a task invol-ves a high cost and thus on-demand routes are traced using node’s own position, positionof neighbors and destination’s location1. Then progress consists of forwarding a packet to aneighboring node which is closer to the destination, that is, in each hop the packet is nearer todestination. The position of neighbors is typically learned by means of one-hop broadcast. Allnodes periodically send these beacons containing the position of sending node. Three mainrouting strategies are distinguished in [WMHF02]: greedy forwarding, directed flooding andhierarchical routing. For these schemes, a given packet is forwarded to one (greedy) or mo-re (directed flooding) one-hop neighbors that are closer to the destination. The third strategyforms a hierarchy that scales to a large number of nodes; it typically combines position-basedrouting with hierarchical topology control or other protocols regarding on hierarchical levels.

1The position of the target node is supposed to be known via a location service, which provides positioninginformation, e.g. by a hierarchical approach [LJC+00] or by using hash functions [RKY+02].

4

1.2. Objectives

If each node broadcasts its own position to the neighbors at regular intervals, then a nodeis able to choose the next node that minimizes the distance to the destination. This greedyforwarding strategy fails, if the packet gets stuck in a local minimum. In this case a recoverystrategy is applied to find a way out of the dead end. Known recovery strategies guide the pa-cket around this region using the right-hand rule. Such strategies require a planarization of thenetwork topology to prevent routing loops. For planarization several subgraph constructionshave been proposed like neighborhood graphs or delaunay triangulations.

Greedy Perimeter Stateless Routing (GPSR) proposed by [KK00] combines greedy forwar-ding and perimeter traversal on a planar graph. In GPSR a packet which encounters a barrier orhole (absence of intermediate nodes to forward to), starts bordering this empty area followingthe righthand rule on a planarized graph. This procedure avoids routing loops caused bycrossing edges. However, planarization removes longer edges in the graph, thus discardingshorter paths that could be also used in routing. This is the basis for the approach exposed byRührup et al. [RS05]: here all edges are susceptable of being used even in perimeter traversal.The key is the combination of a network grid together with virtual orthogonal forwardingamong cells and accesibility to larger view of the neighborhood (based on 2-hop neighborinformation).

1.2. Objectives

The main subject of this work is to present the design, implementation and evaluationof the Cell-based Geographic Forwarding Protocol (CGFP). Stefan Rührup and ChristianSchindelhauer, co-tutors of this thesis, present in [RS05] a strategy for routing packets inwireless ad hoc networks using a cell structure, which is the basis for this protocol. The designof CGFP has been developed together with S. Rührup and updated and improved during itsimplementation and simulations. This work also includes the co-publication of a TechnicalReport [BR06] which constitutes a detailed specification of CGFP.

The development of this thesis involves work efforts which can be divided into a set of maingoals and phases of investigation and experimentation in order to clarify the global vision ofthe project.

5

1. Introduction

As it has been described before, wireless ad hoc networks count on little specific pro-perties that must be studied in detail throughout this thesis. Therefore, a wide preliminarinvestigation on the state of the art of actual routing strategies regarding ad hoc networksis necessary. The theoretical basis of this thesis also includes mathematical notions aboutgraphs, network topologies and greedy and recovery approaches. It is also crucial a goodunderstanding of the principles of GPSR, Greedy Perimeter Stateless Routing, [KK00]and an intensive study of its implementation.

Once previous knowledge is adquired, the Cell-based approach presented in [RS05]grounds the pilars for the design of an innovative position-based routing protocol: theCell-based Geographic Routing Protocol (CGFP).

Simulation environments performed with OMNET++ as network simulator must beused in order to validate and evaluate the functionalities of both protocols. For this pur-pose, a preliminar phase consisting of testing easy pre-defined protocols and scenariosis needed. As OMNET++ is thought to simulate wired networks, for the wireless envi-ronment is necessary to add the Mobility Framework tool. Tests simulating all togethermust follow.

Both protocols, GPSR and CGFP, are being implemented and evaluated using the ne-twork simulator. The implementation of GPSR in C++ using OMNET++ libraries willboth serve as test-bed for masterizing in the use of OMNET++ and MF and the simula-tion scenarios. The design and implementation of CGFP are planned to be simultaneous,so bugs on theoretical protocol functionality are corrected and validated at once.

Definition of parameters, metrics and simulation experiments needed to build a compa-rison of GPSR and CGFP protocols.

Evaluate the behaviour of the protocols in various scenarios. Determine the complexityof each scenario from the point of view of the difficulty of a routing scheme that mustensure packet delivery in any case. Experiment with both static and mobile scenarios.

Masive simulation experiments must be executed in order to obtain collections of statis-tics for further processing. As the data processing tools in OMNET++ is little poor, datacollected in vectors must be imported by a tool such as Matlab for statistical evaluationand representation.

Due to the circumstances under which this work is developed, it will also be necessaryto perfect auxiliary tools, such as the use of LATEX, CVS repositories and Visual Studio

6

1.3. Thesis Contents

for C-programming under Windows O.S.

1.3. Thesis Contents

This thesis is an intensive study on position-based routing protocols, but not an evaluation ofexisting protocols. Furthermore, an implementation of a new approach together with an expe-rimental evaluation, and the design of a new protocol are submitted here. Present introductionintends to be an overview on fundamentals of mobile ad hoc networks and routing based onpositioning. In Chapter 2 greedy and recovery techniques are introduced in order to fix impor-tant concepts that are the basis of GPSR (Greedy Perimeter Stateless Routing) protocol. Thisprotocol is further studied in detail, implemented and simulated. Then that chapter englobesthe state of the art of geographic routing strategies and the simulation environments availablefor validating those protocols. The focus of this thesis is developed in Chapter 3, where a newapproach on geographical routing for ad hoc networks, and specially for wireless sensor ne-tworks, is considered. A new protocol, CGFP (Cell-based Geographic Forwarding Protocol),based on this approach has been designed and implemented, and a detailed specification in-cluding pseudo-code is given. Chapter 4 focuses on the implementation of GPSR and CGFPprotocols and simulations under OMNeT++. Simulation results in Chapter 5 show statisticalcollections that intend to be a comparison between both protocols. Finally, the evolution ofthis project is exposed in Chapter 6. A reflection on conclusions and further work closes thisdocument.

7

1. Introduction

8

2. State of the art

2.1. Geographic Routing

Geographic routing, also called position-based routing, uses position information of thenodes to deliver a message to a target location. Forwarding decisions are based on a packet’sdestination position and the position of intermediate 1-hop neighbors. This scheme hasbeen studied by several authors [WMHF02, GS02, Sto02, BMSU01]. Three main differentclasses of position-based schemes can be distinguished: progress methods (i.e. greedy),directional flooding and hierarchical algorithms. Hierarchical algorithms are highly scalableand usually combine low level non-position based approaches and high level position basedcommunications, and as a result, the complexity of tasks assigned to most nodes gets reduced.In directional flooding a node A forwards a message to all neighbors which are closer to thedestination than A. This scheme is very robust but needs the memorization of past traffic(e.g. message number or paths used) in order to control data flows and loops and it alsoincreases network load. However, the combination of different techniques can yield a bet-ter performance, i.e. a single path progress method uses flooding when no progress is possible.

Some properties are highly desirable for a good performance of routing in a wireless ad-hoc network. Giordano and Stojmenovic [GS04] give a list of patterns related to the specificbehavior and limitations of such networks.

Communication complexity refers to the number of radio-transmissions that is requi-red to send a packet from a source to a position-known destination.

Loop freedom. Avoid packets spinning around the network after no destination is found.Timeouts and past traffic memorization help to solve this. Loops caused by mobility aretemporal in general and are not considered.

Distributed. In localized algorithms, only local decision based on 1-hop information is

9

2. State of the art

needed to achieve global objectives. A possible solution improvement of performancewould be the exchange of 2-hop information (neighborsñeighbors).

Path strategy. Two main possibilities exist: single path, i.e. greedy and recovery strate-gies, and multi-path, i.e. flooding (see section 2.1.1.

Low energy consumption: minimum hop count, referred to the number of retransmis-sions on a route, and optimization of power consumption, when adjustment of transmis-sion power is possible. Hop count assumes delay is proportional to path length and alsothat the cost of retransmission is high in both energy and bandwidth.

Reduced storage. Memorize routes and past traffic are affected by node queue size,node activity and mobility.

Message delivery. Measures ratio of received messages at destination and messagessent by senders. Collisions at medium access is a disadvantage.

Scalability. Protocols must response for arbitrary number of nodes, e.g. huge quantityon sensor networks. A simplification defines a scalable network as it is loop free, loca-lized and single-path.

Robustness. It is highly desirable that routing schemes are robust against topology chan-ges, i.e due to mobility. One problem to be considered is the accuracy of destinationposition, given by an specific device. In mobile scenarios, routing assumes a target nodecan deviate from a known position. Another challenge is the message delivery in pre-sence of obstacles or noisy areas, where the unit disk graph assumption is violated.

As a resume, most important features of a position-based protocol are to ensure a gooddelivery rate and average hop count. Note that density, defined as the number of nodes in thenetwork, closely affects both parameters. Also node activity can save energy and maintain lowoverhead. So it is desirable that nodes are not receiving, transmitting or processing, and stay inan idle state all time they can. In fact, the WLAN standard defines two modes of operation fornodes in a wireless environment: idle and sleep states. A node in idle state can react to networkactivity by changing between receiving and transmitting modes. A node in sleep state cannotbe activated by neighbors and can only change to idle by its own. This functionality is directlyrelated to the goal of keeping low power consumption at nodes. Just for having an idea, nodesin ad hoc networks spend about 20 % more energy when receiving than in idle state and about60 % more in transmit than in idle mode [GS04]. Idle power consumption can be considered

10


as large as that of receiving data. Then the number of retransmissions necessary for commu-nicating a pair of nodes becomes even more important than just worrying about network delay.

2.1.1. The Greedy Rule

Greedy forwarding is a local forwarding strategy that always tries to achieve a progresstowards the target. The notion of progress appears in several position based approachesalready in the 80s. Given a transmitting node S, progress to a neighboring node A is defined asthe orthogonal projection of the distance S-A onto the line connecting S and the final destina-tion D [GS04]. Otherwise the transmission is said to be in backward direction. This criterion isthen used by several methods in order to select the next hop among all neighbors, i.e. a randomneighbor with forward progress is selected. A more restrictive condition is proposed by Finn1987 [Fin87]: select a progress node closest to the destination . Greedy schemes are widelyused in ad hoc networks because they are simple, efficient and scalable, and try to providesolutions similar to the shortest path. Then a packet is forwarded to a 1-hop neighbor closerto destination than the current node. This procedure is repeated until the destination is reached.

Often more than one neighbor is suitable of forwarding a packet using the greedy rule. Thereare different criteria for this decision: in Most Forward within Radius, MFR [TK84] thepacket would be forwarded to the neighbor that makes most progress towards destination,and thus the number of hops of the packet would be minimized, Nearest with ForwardProgress, NFP [HL86] supposes nodes can adjust their transmission power and thus decidefor a neighbor which makes progress but is closest to current node, because then low poweris consumed and reduced signal strength prevents from interfering other communications, inCompass Routing [KSU99] neighbor selected is the closest to the straight line between senderand destination.

Greedy algorithms are shown to be loop-free in static networks, if there are no local minima(see section 2.1.2). However, in the presence of mobility loops occur because of outdatedinformation of neighbor’s position or destination’s position. Some approaches of directedflooding like DREAM [BCSW98], update destination’s position in order to get more accurateinformation as the packet gets closer to destination, thus independently of the location serviceused. Duplication of packets may occur when in IEEE 802.11 MAC scheme an ACK gets

11

2. State of the art

lost.

2.1.2. Barriers and Perimeters

Greedy algorithms may also fail on delivering a packet although a path actually exists betweensource and destination. They incur the problem of local minima, that is, a packet gets stuckwhen no node is closer to destination than the current one and the protocol has to recover

from that point. Several solutions have been proposed in order to ensure message delivery insuch situations: send packet to least backward neighbor, flooding all nodes until a node closerto destination is found, perimeter traversal following the right hand rule, drop message if ithas to return to the node where it came from. The first solution raises the problem of routingloops and the second requires that the past traffic is memorized (either sequence numbers bythe nodes or path information in the packet) in order to avoid overloading the network. GPSRsolves the problem of local minima. Description follows in section 2.1.3.

Local minima are found at nodes near to a region with lower density or near to a significantnumber of nodes which failed for some cause. Such regions where nodes are depleted arebarriers or holes, also called communication voids. A barrier is characterized by its perimeteror boundary, a close cycle of nodes with no self-intersections that bounds an empty region.Fang et al. [FGG04] suggest the a priori identification of those nodes on the network wherepackets can stuck because they bounder a barrier. Such infrastructure can be very efficient insensor networks but limits its functionality to quasi-static sensor networks. Information aboutbarriers can be especially useful for some applications. Forest fire alarms are an example:sensor nodes are destroyed in the fire region and then detecting the boundary helps getting adefinition of the affected area.

2.1.3. Greedy Perimeter Stateless Routing (GPSR)

B. N. Karp and Kung [KK00] propose the Greedy Perimeter Stateless Routing (GPSR)protocol that combines two modes of operation: greedy forwarding and perimeter traversalon a planar graph, thus achieving the same connectivity as the original network. GPSR usesMFR for next hop selection in greedy mode, and beaconing for learning the neighborhood.

12


Figura 2.1.: Local minima at node x and perimeter recovery possibilities [Kar00].

Perimeter traversal can incur in loops because the right-hand rule bordering the barrier canfind crossing edges that bring the message back to an already visited node. This approachperforms a planar graph when a local minimum is reached, thus avoiding loops, as someedges in the graph are discarded and prohibited in forwarding. The packet would be greedyforwarded again after reaching a node which is closer to destination than the node wherelocal minimum was found. For a better understanding of this perimeter strategy, also a briefintroduction to the graph-theoretical basics is given.

2.1.3.1. Beaconing.

The position of neighbors in ad hoc networks is typically learned by periodic broadcasts sentat each host. In GPSR, position information of 1-hop neighbors is announced by sendingbeacons. These beacons contain the identifier or address of sender node and its geographicalcoordinates.

beacon

Field Type Description

ID address ID/network address of the senderpos position geographic position of the sender

GPSR also avoids synchronization of beacons, and therefore collisions at access to medium,by jittering each beacon’s transmission in an uniform distribution U[0.5B,1.5B], being B the

13

2. State of the art

Figura 2.2.: Greedy forwarding rule pseudocode.

mean inter-beacon transmission interval. A timeout T is also implemented, such that if no bea-con was received from a certain neighbor for time T, then corresponding node assumes that theneighbor has failed or left its area of influence. A timeout of T=4.5B has been used in [Kar00].

Also a promiscuous network interface can be used. In this case, nodes include its position inall data packets they forward, so all hosts within range can update this node’s position. Thisfunctionality can be relevant in mobility scenarios, where updating local information can becrucial for message delivery.

2.1.3.2. Greedy Forwarding.

At this point the first part of GPSR is defined: greedy forwarding. Packets are marked by theiroriginator with their destinations’locations. Then at a forwarding node, the locally optimalchoice for next hop is the neighbor geographically closest to the packet’s destination. Thealgorithm must then calculate distances from neighbors to destination and decide for the best,i.e. the most promising neighbor. Now suppose the header of a packet p contains fields p.a, theaddress of the packet’s destination, and p.l, the location of the packet’s destination. Assumealso that each node has a neighbor table N, each of whose entries is a pair of a neighbornode’s address (a) with that neighbor’s location (l). Also node’s own address and location aredenoted by self.a and self.l in pseudocode for the greedy algorithm shown in Figure 2.2.

14


u vw

u vw

Figura 2.3.: RNG (left) and GG (right) planarizations. For edge u− v to be included in theplanar graph, node w should be out of the shaded area.

2.1.3.3. Planarizing Network Topology.

In wireless communications a basic graph model is widely used to model the behavior ofnetworks. The set of nodes in a network can be understood as a graph where wireless nodesare the vertices and edges are drawn between directly connected nodes. The unit disc graphmodel (UDG) is defined in [GS04] as follows: ’two nodes A and B in the network areneighbors (and thus joined by an edge) if the Euclidean distance between their coordinatesin the network is at most R, where R is the transmission radius which is equal for all nodesin the network’. Some variations of this scheme have been also defined and may includeobstacles, nodes each one with particular transmission radii or unidirectional links. However,many implementations benefit from the simplicity of using the unit graph model.

Planar1 graphs are graphs with no intersecting edges. So in general graphs representing adhoc networks are non-planar, but there exist algorithms for obtaining planar subgraphs fromnon-planar graphs by removing some edges and ensuring that no subset of vertices getsdisconnected. Most important is that some of them can be applied locally.

The implementation of GPSR in [KK00] includes two different types of planarization: Gabriel

Graph (GG) and Relative Neighborhood Graph (RNG). Then GPSR includes an algorithmfor removing edges in the network graph which are not part of GG or RNG (see Figure 2.4).It is clear that removing edges from the graph to reduce it to planar, must not disconnect thegraph, as this would be equivalent to divide the network. Figure 2.3 shows how reduction ismade in both schemes: both graphs consider edge u,v out of the planar graph, since node w

1Actually plane graphs: the embedding in the plane has no crossing edges.

15

2. State of the art

Figura 2.4.: For a full list of its neighbors, N, node u removes non-RNG links.

Figura 2.5.: Right-hand rule: loop caused by crossing edges.

lies inside the shadowed region. Then crossing edges are avoided while connectivity is stillguaranteed via path u−w− v.

2.1.3.4. Perimeter Traversal.

As said before, when a barrier is found, a potential message should border it somehowand then keep on making progress until it reaches the destination. Perimeter Forwarding isnecessary only when barriers are close. This recovery method in GPSR utilizes the righthandrule, in order to border the barrier. The protocol firstly forwards to closer faces in the planargraph. The packet may cross internal and external faces, so it must be stored if the packetchanged the face already for not incurring into loops (see Figure 2.5).

Then, when a packet enters perimeter mode, GPSR records in the packet the location Lp,which is the site where greedy forwarding failed. This location is used at subsequent hopsto determine whether the packet can be returned to greedy mode. GPSR forwards the packeton progressively closer faces of the planar topology. A planar graph has two types of faces:interior faces are the closed polygonal regions bounded by the graph’s edges and exterior

16


Figura 2.6.: Main methods in GPSR for perimeter forwarding.

17

2. State of the art

Figura 2.7.: Full graph of wireless network (left). GG subset of the full graph (middle). RNGsubset of full and GG graphs (right) [KK00].

faces are the one unbounded face outside the outer boundary of the graph. On each face,the traversal uses the right-hand rule to reach an edge that crosses the line between initialperimeter node and destination. Changing faces amounts to treating the next hop on thecurrent face as the previous hop, and applying the right-hand rule again. It is also possiblethat single node borders multiple edges that cross the line to the destination, so the treatmentof faces is indeed complicated. The pseudocode for the GPSR forwarding algorithm is shownin Figure 2.6, where RIGHT-HAND-FORWARD and PERI-INIT-FORWARD determinenext hop host dictated by the right-hand rule, FACE-CHANGE determines whether thepacket has reached an edge that crosses the line to destination and GPSR-FORWARD isthe top-level forwarding function called for all arriving packets. This detailed specificationon GPSR will further serve in this project for the implementation of this protocol (seeSection 4.1).

2.1.4. The Cell-based approach

Unfortunately, the planarization cancels out the long edges of the original topology (seeFigure 2.7), such that the routing progress is reduced just in the case when the effective greedystrategy fails. [RS05] propose a local topology control strategy that avoids the disadvantagesof the planarization. The idea is to construct a virtual geographical cluster structure thatcontains the information about the 2-hop-neighborhood of each node. This structure canbe constructed locally and provides each node with the necessary information for greedy

18

2.2. Simulation Environment

forwarding and recovery. Each host uses its positioning capabilities to determine to which cellit belongs. It can also assign its neighbors to the cells within its transmission range, based ontheir position coordinates. Thus, one can abstract from the view of a host’s environment byclassifying the cells. This classification leads to a formal description of barriers.

The cell structure is a tool for describing efficient algorithms, not merely an end in itself. Thisstructure gives an abstract view on the network and represents regions where nodes reside(node cells), regions that can be used for the communication flow (link cells) and regions thatcannot be bridged due to the restricted transmission range (barrier cells). The cell sizes arechosen such that locality ensures communication, and [RS05] prove that the cell path usingnode cells and link cells is equivalent to the optimum path connecting two nodes up to aconstant factor.


Modeling and simulation are traditional methods used to evaluate network designs. Althoughmathematical modeling play an important role in the design of wireless, mobile and adhoc networks, but with growing complexity such models become too complicated and lesspractical [BB04]. In these cases simulation is a helpful tool for engineers in order to obtainand compare the crucial performance characteristics. However, detailed simulations of thesenetworks may require large amounts of CPU time. Therefore, the development of methods tospeed up simulations has received recent interest. This advances together with the fact thattoday most of the models can be defined using object-oriented languages, such as Java, C/C++or OTcl/Tk, make it easier to extend and adapt existing models in new simulation projects.

2.2.1. OMNeT++

Several publicly available network simulators exist and probably the most widely used sof-tware in the recent years has been ns-2, a discrete event simulator. However, ns-2 furthers highinterdependence between modules due to its object oriented design and thus ns-2 might be agood choice for simulating traditional IP networks as a reduced number of protocols is widelyused (i.e. TCP, IEEE 802.11). One problem arises when developing ad hoc networks, as the

19

2. State of the art

implementation of one algorithm is closely related to the specific application and it is alsohardly extendable. The simulation environment chosen for this work is OMNeT++ [Var05](Objective Modular Network Test-bed in C++) version 3.1. OMNeT++, is a public-source,component-based, modular simulation framework. Mallanda et al. [MES+05] have identifieda list of challenge features of OMNeT++ in detriment of other simulators as a platform fordeveloping wireless sensor networks, also applicable for us:

Flexible. Simulation modules can be easily combined and reused.

Hierarchical, built on nested modules.

Base classes in the simulation kernel can be extended due to object-orientation.

Friendly GUI interface for tracing messages and debugging and a command line inter-face for batch execution.

Libraries provide also statistics, input/output, data collection, data number generatorsand data structures.

Simulation kernel uses C++ performing well in large applications.

Own language for describing topology (NED) and initialization file (omnetpp.ini) sim-plifies configuration for various simulations.

OMNeT++ is a general-purpose tool for discrete event simulations, i.e. state changes (events)happen at discrete instances in time, and events take zero time to happen. It is assumed thatnothing relevant occurs between two consecutive events, that is, no state change takes placein the system between the events (in contrast to continuous systems where state changes arecontinuous). Computer networks are typically seen as discrete event systems with events suchas start of a packet transmission, end of a packet transmission and expiry of a retransmis-sion timeout. This model is then complete and accurate enough for the purpose of this thesis.OMNeT++ general structure can be resumed as follows:

Modules implement application-specific functionality

Modules can be connected by connections

Modules communicate by exchanging messages via connections. Arrival of a messageat a module is an event.

20


Modules are implemented as C++ objects, using support functions from a simulationlibrary. This is, all modules are instances of certain classes representing module types

User-defined module types can be used to derive new module types via standard inheri-tance techniques

Topology of module connections is specified using an OMNeT++ specific languagecalled NED

However, two different mechanisms exist in OMNeT++: HandleMessage and Activity. TheActivity scheme permits coding modules much like an operating system process or a thread.The main problem here is that it does not scale because every module needs a separaterouting stack and this involves too much memory in the end. It has also been observed thatActivity does not encourage a good programming style. This process-style description isconvenient only when the process has many states but transitions are limited. When oneexpect modules to be used in large simulations, involving several modules, HandleMessage ismore convenient to program. The idea is that at each event (message arrival) one simply callsa user-defined function. For example, module appl (see Figure 2.9) representing applicationlayer at a host receives a timeout message and generates a packet, then module appl sends amessage to net module posting the packet and necessary additional information so net moduleexecutes appropriate routing tasks.

OMNeT supports developing including pre-defined classes that facilitate programing. As atool for supporting routing in telecommunication networks, OMNeT++ includes the cTopo-logy class, which stores an abstract representation of the network in graph form: modules arenodes and links are edges in the graph. One can then specify which node types to include,e.g. Host. Then cTopology functions permits calculations such as shortest paths among hosts(following Dijkstra’s algorithm), the total number of nodes in the network and the number ofneighbors of a certain node. This tool is crucial in order to automate the comparison of theperformance of packets routed by a given protocol with the ideal response.

By today there is an increasing number of various mobile, ad-hoc and sensor simulation fra-meworks based in OMNeT++:

Mobility Framework 1.0a5 is currently the reference platform for doing mobile and ad-hoc simulations with OMNeT++. MF includes a 802.11 model (ad-hoc mode only) butno routing protocols are implemented, only flooding.

21

2. State of the art

Figura 2.8.: Wireless network with randomly positioned nodes generated using the Mobility Fra-mework.

INET Framework also includes support for mobile and ad-hoc networks based on codeported from the MF-1.0a5 release. Mobility, physical and MAC layer have been portedto INET and significantly improved. MF and INET are largely comparable. Beyond IPand UDP/TCP there is 802.11, Ethernet, PPP, IPv6, OSPF, RIP, MPLS with LDP andRSVP-TE signalling, and other protocols.

AODV Framework contains a simplified AODV protocol implementation. It includesseveral mobility models not compatible with those of MF/INET.

NesCT allows running TinyOS programs in OMNeT++ for wireless sensor networks.

MACSimulator is a model of various different energy-efficient MAC protocols for wi-reless sensor networks: T-MAC, S-MAC, L-MAC and simple CSMA.

SENSIM also concentrates on sensor networks: it includes 802.11 and a directed diffu-sion model.

This work has been developed using the Mobility Framework 1.0a5 [LW05] library package,which contains the wireless environment for nodes and an implementation of IEEE 802.11for WLANs.

22


2.2.2. Mobility Framework

The Mobility Framework 1.0a5 (MF) includes the necessary architecture for mobility supportand connections update. The structure of a wireless mobile host consists of 3 submodulescorresponding to the communication tasks: the application (appl module), network (net

module) and physical-MAC layers (nic module), and another 2 submodules: one as platformfor the inter-layer communication (blackboard) and one to cover changeable positioningcoordinates of the host (mobility).

Figura 2.9.: Structure of a host in OMNeT++ using Mobility Framework.

As said in the Introduction, physical and link layers constitute an absolutely wide field ofstudy in relation to electromagnetic propagation, antenna and circuitry design, and alsochannel modeling and link layer implementation. These areas compete to several fields of Te-lecommunications Engineering, but lay out of the contents of this thesis. The communicationmodel developed in MF is much simpler:

Wireless transmission is determined by the generation of electrical signals that are translatedinto radio waves and propagated over the air. The simplest model is considered here, that is,free space propagation. Nodes are characterized by isotropic antennas and transmit a certainpower. Such signal power is attenuated inverse proportionally to the distance up to someexponent (2 is commonly used), following the Friis formula. Then the distance among nodesin the network determines which pairs of nodes can directly communicate over the air. Thenthe sensitivity at the receiver indicates the minimum signal level required to ensure reliablecommunications. A node receives the signal and decides at its physical layer about its Signal

23

2. State of the art

to Noise Ratio (SNR). The IEEE 802.11a WLAN standard recommends a noise figure at thereceiver of 10 dB or better. Afterwards, also a calculation of the bit error rate is done, and thedata reaches MAC layer. Such a simple model is implemented in OMNeT++ and followed inthis work. Both physical and MAC layers are one existing module of the Mobility Framework.A wide margin is left for developing routing and application schemes at each host, regardingno extra effort than programming common OMNeT++ simulations.

2.2.3. Statistical Data Collection and Processing

OMNeT++ includes a friendly GUI interface which is useful for validating and debuggingstep by step packet exchanges and processing at nodes in a certain simulation. Also datacan be collected and plotted using statistics and distribution estimation provided in theabstract base class cStatistic, where OMNeT++ includes Output Vectors and Output Scalars

for storing simulation results from simple modules and Plove and Scalars for drawing thisdata into graphs. Output vectors capture the transient behaviour of the simulation run, whileoutput scalars are more useful to compare model behaviour under various parameter settings.However, for a large number of repeated experiments, it is more appropriate to executeOMNeT++ using the command-line interface and user-defined scripts and then automateprocessing of vectors and scalars. One can use numerical packages such as Octave, Matlabor the statistics package R, as in addition to their support for statistical computations, theycan also create various plots. Other open-source programs include Gnuplot, Grace or ROOT.Because Matlab is a well-known tool used in previous lectures, scripts written in this languageare being used to present experimental results in this thesis.

24

3. The Cell-based GeographicForwarding Protocol

This chapter presents the complete algorithm based on the Cell-based approach presented byS. Rührup and C. Shindelhauer [RS05]. Then a new protocol called Cell-based GeographicRouting Protocol is presented and its global functionalities are specified in the following sec-tions.

3.1. Overview

The cell structure is an abstraction from the network, i.e. it represents a classification of alldifferent regions in the network area in a virtual grid. The cell structure is composed of linkcells and barrier cells, which indicate regions where communication is possible and regionswhere no nodes reside. The classification of these cells is performed by CGFP in a local anddistributed manner. As for GPSR, the cell-based approach assumes the Unit Disk Graph modelas communication model and also positioning capabilities for nodes.

The strategy of the cell structure helps identifying local minima for greedy forwarding, andimproves recovery schemes because it has no need to care about crossing edges and planari-zation, so all edges in the network are available for being used in forwarding. Avoiding loopscaused by intersecting edges is done by an implicit geographic clustering (see Figure 3.2).Although this is a proactive model, cell grids are not built on the fly to be used in routing,but in advance thanks to the information compiled from neighboring nodes. Then, a 2-hop-proactive mechanism is used as communication pattern: 1st hop compiles the coordinates ofneighbors and 2nd hop collects the information about neighbors of neighbors. Therefore, thecell structure can be established in a distributed manner thus using only local information.

25

3. The Cell-based Geographic Forwarding Protocol

Figura 3.1.: Unit Disk Graph with transmission radius r and grid subdivision for the same networkregion.

Figura 3.2.: CGFP solves the problem of crossing edges without the need of planarization.

26

3.2. The cell structure

One of the principal ideas in [RS05] is to represent the network area as a global grid. Eachgrid square is called cell and its side length is a constant factor of the transmission radius. For`≤ 1

2

√38 r then paths in the network and cell routes are equivalent.

Choosing an appropriate cell size, routing can be as efficient as in the UDG with a constantloss factor in performance. Before physically forwarding a message, a node would thenvirtually forward the message from cell to cell until a barrier prevents from going ahead or itstransmission range is exceeded.


Supposed the network area is seen by all nodes as a large squared grid, such that each noderesides in one of those square cells. Then each node also constructs a map of the area coveredby its transmission radius, thus creating an own view of its neighborhood. The cells in this cell

structure are classified in order to determine which regions can be used in routing and whichcannot. The cell size is determined by the transmission radius and given to the protocol as aparameter.

3.2.1. Global and local coordinates

The geographical position of the nodes is known via some kind of location service. Since thecell size l is an input, it is trivial for a node to convert its geographical position (px, py) into acell position (cx,cy), given by cx = bpx/`c and cy = bpy/`c. These coordinates are consideredto be global, as they are absolute and unique in the whole network grid.

(-2,-2) (-1,-2) (0,-2) (1,-2) (2,-2)(-2,-1) (-1,-1) (0,-1) (1,-1) (2,-1)(-2,0) (-1,0) (0,0) (1,0) (2,0)(-2,1) (-1,1) (0,1) (1,1) (2,1)(-2,2) (-1,2) (0,2) (1,2) (2,2)

Figura 3.3.: Local coordinates

As nodes also store information about their environment, they map this information into local

27


cell structures1 (see Views in Section 3.2.3). Cells in views are referenced in relation to thenode’s coordinates. An easy way to notate these local coordinates, is to number the cell thatcontains the node itself as (0,0). Then the global position of a particular cell in a certain Viewcan be obtained by simply adding an offset equal to the node’s cell position.

Figura 3.4.: Cell coordinate system.

For all 2-D coordinates, CGFP assumes that positive x-axis points to the right (to the east) andpositive y-axis points downwards (to the south). In the routing phase, the protocol builds a cellpath for forwarding. Thus messages make progress in the cell path by adding a direction to itscurrent cell position. Figure 3.5 shows how directions are defined.

North

West(0,-1)

(-1,0) (0,0) (1,0)(0,1)

East

South

Figura 3.5.: Directions

3.2.2. Classification of cells

A given node v classifies cells into 3 different types

– link cell, if it lies completely within half of the transmission radius of v or any neighbo-ring node (half radius rule) or if it is intersected by an edge (edge intersection rule).

1From now on, cell structure refers to every kind of view at a node, but not to the whole network grid.

28


– barrier cell, if all of the following conditions are fulfilled: It lies completely within thetransmission radius r of v, it is nearer to v than to any other neighboring node and it isnot a link cell.

– unclassified, if it is not covered by the transmission radius, or if it is not a link cell, buta neighboring node is nearer to it than v.

It might be intuitive thinking that every cell which lies within the transmission radius of anode v, should be a cell useful for forwarding messages, at least in UDG networks. Indeed ifanother node u is placed in that area, it would be able to listen to any transmission comingfrom v. However, the cell structure goes one step ahead: classification of cells must coincidefor every node in every area of unitary radius, as it is defined in UDG. Node v can only beabsolutely sure that cells within its half-radius are link cells. But if u is further than half-radius, then v cannot classify as link those cells in u’s surroundings, because it is obvious thatthis nodes have more accurate information. If node v does not respect the information comingfrom u, routing paths may be altered inducing loops.

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

link cell

r/2

u

w

x

v

r

barrier cell

unclassified cell

Figura 3.6.: Classification of cells [Rüh06].

A cell is completely defined by the following attributes2.

3.2.3. Local information at nodes

Analog to other distributed algorithms, a node stores a list of its direct neighbors, but alsothe classification of cells in its surroundings. The information about cells is stored into twomatrices called views, used in beaconing and virtual forwarding.

2See data types in appendix A, Notation in the pseudo-code.

29


cell_infoField Type Descriptioncell_pos cell_coord local cell coordinates,type cell_type type of the cell,owner address ID of the node that reported the information

or the node itself (“me”)

3.2.3.1. List of neighbors

The neighbor list is sorted by nodesÍDs and contains the following record for each neighbor:

neighbor_info


ID address ID/network address of the neighboring nodepos position its geographical positiontime time timestamp of the last beacon message received

3.2.3.2. Views

For the cell classification two views are used: View 1 contains the set of cells within theradius r and their classification. This classification is based on the positions of the direct (1-hop) neighbors. The information of this view is given to the neighboring nodes in the beaconmessages. View 2 is the enlarged view of a node. It contains the cells classified by oneself(View 1) and by the classifications of other nodes, which are known from the received beaconmessages. View 2 is the basis for routing: It facilitates virtual forwarding of the message ona cell path, before the protocol physically decides to transmit the message. It is not includedin the beacon and sent to other nodes! Otherwise, multi-hop information would be propagatedthrough the network and this information may become inconsistent. The cells in View 1 andView 2 are numbered relatively, where the own cell of the node has the (cell) position (0,0).The dimension of the array for View 1 is 2dr/`e+1 cells in height and also in width. View 1and View 2 are arrays, where each field represents a cell characterized by cell_info .

3.2.3.3. Summary

The following table summarizes the local information stored at a node:

30


Local Information


ID address ID/network address of the nodepos position geographical positioncell_pos cell_coord global cell positionneighbor_list list of neighbor_info information about direct neighborsview1 array of cell_info classification of cells within the transmission radiusview2 array of cell_info enlarged view based on 2-hop informationtime time current time

To distinguish between these fields and the fields of a packet, the local information of a nodeis indicated with "me"(e.g. me.cell_pos) where it might be not clear.

3.2.4. Initializing the cell structure

The first step for building the cell structure at a node is to set up the views. View 1 is a grid,whose side length is 2br/`c+1 such that the the complete transmission radius is covered. Unitfor the dimension is the side length of a cell `. View 2 should cover also the transmission rangeof potential neighbors, therefore a side length of 4br/`c+ 1 is chosen. All cells in this gridare initially set to unclassified cells. This is done by the function INITIALIZECELLS whichinitializes both views. Then, the surrounding cells that are completely within a half-radiusdistance are set to link cells. Cells between half-radius and transmission radius are set tobarrier cells, if no other neighbor is nearer to them. After this step, cell status is updated whenbeacons arrive.

INITIALIZECELLS calls the function GETDISTANCE(position p, cell_coord lc), which returnsthe maximum distance from position p to any of the corners of the cell lc.

3.2.5. Updating the cell structure

There are two situations for which views have to be updated

(a) if neighbors appear, move or disappear or

(b) if the node that hosts the view moves away.

31


Algorithm 1 INITIALIZECELLS

Require: neighbor_list must be empty1: dim = ceil(r/`)2: view1 = new array[-dim..dim][-dim..dim] of cell_info // each cell is initially unclassified3: for each cell in view1 do4: if GETDISTANCE(me.pos,cell) <r/2 then5: cell.set(type:link, owner:me)6: else if GETDISTANCE(me.pos,cell) <r then7: cell.set(type:barrier, owner:none)8: else9: cell.set(type:unclassified, owner:none)

10: end if11: end for12: cell[0,0].set(type:node, owner:me)13: view2 = new array[-2*dim..2*dim][-2*dim..2*dim] of cell_info14: copy all cells from view1 to view2

When a node moves to an adjacent cell its views get modified because link cells within halfradius and those produced by edges must be updated in order to ensure cell connectivity. ThenView 1 is rebuilt using position information stored in the neighbor list. This node is thenresponsible of notifying its neighbors about its new location and cell structure. Modificationsin the environment close to a node are recognized by processing beacon messages and handlingtimeouts. Beacon messages are broadcasted at regular intervals. A beacon message containsthe following information:

beacon


ID address ID/network address of the senderpos position geographic position of the senderview array of cell_info View 1 of the sendertime time timestamp set by the sender

Handling of an incoming beacon message is done as in PROCESSBEACON . If a node receivesa beacon message, it updates the views as follows:

1. If a neighbor is already known and if he has moved, then delete the old information inView 1 (reset cells owned by the neighbor). If a neighbor is new, then it must also beadded to the neighbor list.

2. Construct the link cells (half radius rule and edge intersection rule) in View 1.

32


3. Copy information about cells in View 1 owned by the neighbor to View 2.

4. Copy classified cells from the beacon into View 2.

Nevertheless, not all cells that are non-link cells may be classified as barrier cells (seeSection 3.2.6 for an introduction to this problem). A node v leaves a cell unclassified, if all ofthe following conditions are true:

It is inside the transmission radius r of node v.

It lies outside the half-radius of node v.

It lies outside the half-radius of any neighbor (i.e. it is not a link cell).

The distance from c to a neighbor is smaller than the distance to v.

Then if a neighbor disappears, each cell that was owned by this neighbor and would be resetto a barrier cell (see RESETCELLS) has to be checked whether another neighbor is nearer tothis cell than to the node itself. In this case it will become unclassified.

View 2 is constructed by taking the information from the beacon (see UPDATECELLS). Assu-me that the beacon was sent by a neighbor x at time t. Then the node can not overwrite theinformation in its View 2, if one of the following conditions is true:

The owner of cell is the node itself.

The timestamp of the owner of the cell is newer than t.

The cell in beacon.view is of type unclassified.

The cell in beacon.view is of type barrier while the cell is a link cell.

Otherwise, the classification is adopted and the owner is node x. Let’s see an example of a cellclassification based on network shown in figure 3.6. Figure 3.7 shows View 1 of nodes v andx. Figure 3.8 shows View 2 of node v after it has received beacon messages of all its neighbors.

33


��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

r

x

u

v

w r/2��

��

��

��

��

��

��

��

��

��

��

��

��

y

v

x

��

unclassified

unclassified(not owner)

barrier cell

link cell

(out of range)

Figura 3.7.: Node v (left) and node x (right) and the classification of cells based only on thepositions of the direct neighbors (View 1).

Algorithm 2 PROCESSBEACON(beacon)1: neighbor = neighbor_list.lookup(beacon.ID)2: if neighbor 6= nil then // if neighbor is in neighbor_list3: neighbor_list.update(beacon.ID, beacon.pos, beacon.time);4: if POS2CELL(neighbor.pos) 6= POS2CELL(beacon.pos) then // if cell pos. has

changed5: RESETCELLS(neighbor) // reset cells owned by the neighbor6: end if7: else8: neighbor_list.insert(beacon.ID, beacon.pos, beacon.time);9: end if

10: UPDATECELLS(beacon)

Auxiliary functions used by the update algorithms in this section (see [BR06] for a detaileddescription):

UPDATEVIEW1(cell, new_type, new_owner) assigns type and owner to the cell inView 1. A cell of the same type is only overwritten if the position of the new owner iscloser to the cell than the old owner.

UPDATEVIEW2(cell, new_type, new_owner) works analog to UPDATEVIEW1. It for-bids that unclassified cells overwrite cells of another type by another owner in View 2.

SETLINKCELLS(cell_coord cell1, cell2; address neighbor) sets all cells between thisnode (me) and a neighbor to link cells (with the specified neighbor as owner), if thecurrent owner is not “me”. So in View 1 the node itself remains owner of the link cellswithin radius r/2. It can be implemented by Bresenham’s line drawing algorithm with amodification, such that the link cells (which are “drawn”) are orthogonally connected.

GETDISTANCE(position p, cell_coord lc) returns the maximum distance from the glo-bal position p to any of the corners of the cell lc (specified by local coordinates).

GETGLOBALCELLPOS(cell_coord localp) and GETLOCALCELLPOS(cell_coordglobalp) convert local to global cell coordinates and vice versa.

POS2CELL(position p) returns the global cell coordinates of the given position.34


��

��

��

��

��

��

��

��

��

��

��

��

��

w

x

v

u

Figura 3.8.: Enlarged view of node v (View 2).

3.2.6. The problem of barrier classification

Assume four nodes u, v, w and x placed on a line as shown in Figure 3.9. Node w knows onlyv to the west. Node u is beyond its range, and it can only be reached by node v. But w doesnot know this. It marks the cells west of node v as barrier cells (in View 1, beyond v’s halfradius) and sends this information eastward to node x. So in View 2 of node x there are onlybarrier cells to the west of v. Then, node x would not attempt to physically forward the packetin that direction, though there exists a route. This problem can even occur, if the two nodes inthe middle (v and w) are in the same cell.

w xu v

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

u v w x

��

��

��

��

��

�� xv w

��

unclassified

unclassified(not owner)

barrier cell

link cell

(out of range)

Figura 3.9.: Incorrect classification of barrier cells at View 1 of node v (left), View 1 of nodew (middle) and View 1 of node x (right)

Thus, a node has to be sure that a cell is a barrier cell, i.e. that there must be other node thatcould classify this cell differently. This means for View 1: a cell is classified as barrier cell, if

35


Algorithm 3 RESETCELLS(address neighbor)1: for each cell in view1 do2: if cell.owner = neighbor then3: cell.set(type:barrier, owner:none)4: d = GETDISTANCE(me.pos, cell)5: for each node in neighbor_list do // check if another node is nearer6: dist_to_node = GETDISTANCE(neighbor.pos, cell)7: if dist_to_node <d then8: cell.set(type:unclassified, owner:node)9: d = dist_to_node

10: end if11: end for12: end if13: end for14: for each cell(x,y) in view2 do15: if cell.owner = neighbor then16: if cell is not existing or unclassified in view1 then17: cell.set(type:unclassified, owner:none)18: else19: cell.set(view1[x,y].type, view1[x,y].owner)20: end if21: end if22: end for

no other node is nearer to this cell. Otherwise they are marked as unclassified.

The correct classification for the example is shown in Figure 3.9 middle and right. Node w

does not classify the cells to the west of v as barrier cells. So beyond the link cells around v

there are only unclassified cells. This information is passed to x and used to create View 2 (seeFigure 3.10). If x performs the virtual cell forwarding in View 2, it reaches the unclassifiedcells and then it has to hand over the packet to node w. Node w looks into its View 2, where ithas the information about u, and will forward the message further in this direction.

If u and v are deleted from the picture, then there are no other nodes to the west of w. Then thecells in the west can be classified as barrier cells, because there is no other node nearer than w.With this information, x looks into View 2, there are only barriers in the west and the packetis not forwarded to w.

36


Algorithm 4 UPDATECELLS(beacon)1: neighbor = beacon.ID2: neighbor_cell = local cell containing beacon.pos3: for each cell(x,y) in view1 do4: if cell.owner 6= me and GETDISTANCE(me.pos,cell) <r then5: d = GETDISTANCE(beacon.pos,cell) // distance from cell to neighbor6: if d <r/2 then7: UPDATEVIEW1([x,y], type:link, owner:neighbor)8: else // if there are barrier cells that are closer to the neighbor:9: if cell.type = barrier and (cell.owner = none or cell.owner = neighbor)

and d <GETDISTANCE(me.pos,cell) then10: UPDATEVIEW1([x,y], type:unclassified, owner:neighbor)11: end if12: end if13: end if14: end for15: SETLINKCELLS([0,0], neighbor_cell, neighbor)16: for each cell(x,y) in view1 do // copy updated cells into View 2:17: if cell.owner = neighbor and (cell.type6=barrier or view2[x,y].type6=link) then18: UPDATEVIEW2([x,y], cell.type, cell.owner)19: end if20: end for21: for each bcell(x,y) in beacon.view do // adopt cell classification from the beacon22: vcell = view2[x+neighbor_cell.x, y+neighbor_cell.y]23: if vcell.owner6=me and bcell.owner6=me

and (bcell.type6=unclassified or vcell.owner = neighbor)and (bcell.type6=barrier or vcell.type6=link) then

24: UPDATEVIEW2([x,y], bcell.type, owner:neighbor)25: end if26: end for

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

w xv

Figura 3.10.: Solution: View 2 of node x (containing the information of View 1 of node v)

37


3.3. Forwarding messages

The Cell-based Geographic Forwarding Protocol constructs routing paths based on the cellstructure by a greedy forwarding strategy with right-hand recovery. Then every time a nodereceives a packet and it is not the destination, it has to forward this packet to another node.If the destination node of the packet is already among its neighbors, it can simply forwardthe packet to this neighbor. Otherwise it has to select a neighbor who has the most promisinggeographical position (see PROCESSPACKET). This is the same procedure as GPSR untilhere, but this decision is made by means of the cell structure: The received packet containsthe information about the current cell (where it virtually resides). From this cell the nodeconstructs a cell path in View 2 by applying a greedy and recovery strategy until a cell isreached that is owned by a neighbor, to whom the packet is forwarded.

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

u

w

v

x

Figura 3.11.: Example on cell path construction in the presence of a barrier [Rüh06].

A routing packet contains the following information:

38


packet


source address ID/network address of the sendersource_pos cell_coord geographic position of the senderdest address destination addressdest_pos position geographic position of the destinationcell_pos cell_coord current global cell position of the packetmode {greedy,recovery} forwarding mode, either greedy or recoveryrec_cell cell_coord global cell position when entering recovery moderec_dir direction direction when recovery was starteddir direction current direction of the packetjustTurnedRight boolean flag for handling a special case in the recovery mode

In greedy mode a packet is virtually forwarded from one cell to a neighboring one, onlyorthogonal directions allowed. If a cell on the east is nearer to destination than current cell,then the packet goes there. Otherwise the right hand rule follows and a northern cell ischecked, etc. By definition, if two nodes are connected, there exists a cell path between them.Thus if a barrier on the path to destination is found, then recovery forwarding is needed. Theprotocol finds a cell path along the border of the barrier until the packet reaches a cell whichis nearer to the destination than that one where recovery started. Once the packet reaches thelast classified cell, it has to be physically forwarded to the neighbor, that owns a cell, as it isregistered in the cell structure. This classified cell is stored at the packet, so neighbor startscell forwarding from there.

Algorithm 5 PROCESSPACKET(packet)1: if packet.dest = me.ID then2: hand over packet to application layer3: else if packet.dest in list of neighbors then4: SEND(packet, packet.dest)5: else6: FORWARDPACKET(packet)7: end if

39


Algorithm 6 FORWARDPACKET(packet)1: current_cell = GETLOCALCELLPOS(packet.cell_pos)2: dest_cell = POS2CELL(packet.dest_pos)3: stop = false4: while not stop do5: if packet.mode = greedy then6: next_cell = GETNEXTGREEDYCELL(packet, current_cell)7: else8: next_cell = GETNEXTRECOVERYCELL(packet, current_cell)9: end if

// if a cell is traversed twice in the same direction, then the destination is unreachable:10: if next_cell = packet.rec_cell and

packet.rec_dir = (next_cell – current_cell) then11: drop packet12: end if13: if next_cell.owner 6= me or next_cell is unclassified in view2 then14: stop = true // stop if the own cells are left15: if packet.mode = recovery and justTurnedRight then16: TURNLEFT(packet.dir)17: end if18: else19: current_cell = next_cell // go one step ahead20: end if21: end while22: packet.cell_pos = GETGLOBALCELLPOS(current_cell)23: SEND(packet, view2(current_cell).owner) // send pkt. to owner of this cell

Auxiliary functions used in this section (see [BR06] for a detailed description):

SEND(packet, address) sends the packet physically to the node with the specified ad-dress.

GETDIRECTION(cell_coord source_cell, current_cell, dest_cell) returns the next celltowards dest_cell on a straight line between source_cell and dest_cell. The output isin { (1,0),(0,1),(-1,0),(0,-1) } (if the given positions are not equal).

TURNLEFT(direction dir) or TURNRIGHT(direction dir) return the direction after a90-degree turn to the left (counter-clockwise) or to the right (clockwise).

40


Algorithm 7 GETNEXTGREEDYCELL(packet, current_cell)1: source_cell = POS2CELL(packet.source_pos)2: dest_cell = POS2CELL(packet.dest_pos)3: packet.dir = GETDIRECTION(source_cell, current_cell, dest_cell)4: next_cell = current_cell + packet.dir // next_cell = pos. of the cell one step ahead5: if view2[next_cell.x,next_cell.y].type = barrier then6: packet.mode = recovery7: packet.dir = TURNLEFT(packet.dir) // turn left in front of a barrier8: packet.rec_dir = packet.dir // direction for starting recovery9: packet.rec_cell = GetGlobalCellPos(current_cell) // store current cell

10: return current_cell11: end if12: return next_cell

Algorithm 8 GETNEXTRECOVERYCELL(packet, current_cell)1: packet.dir = TURNRIGHT(packet.dir) // turn right, then the barrier is ahead2: justTurnedRight = true; // remains true if there is no further turn3: next_cell = current_cell + packet.dir4: while view2[next_cell.x,next_cell.y].type = barrier do5: justTurnedRight = false;6: packet.dir = TURNLEFT(packet.dir) // barrier is to the right after first turn left7: next_cell = current_cell + packet.dir8: end while9: if GETDISTANCE(dest_pos,next_cell) <GETDISTANCE(dest_pos,packet.rec_cell) then

10: packet.mode=greedy // resume greedy if progress condition fulfilled11: end if12: return next_cell

41


42

4. Implementations

4.1. Details on the implementation of GPSR and

CGFP

For network simulations in OMNeT++ one must define:

- a scenario, which is the rectangular playground where communication hosts are placed.- host type, the characteristics of a host. Communication protocols must be programmed

here in order to determine the behavior of the host in the network.- packet format, definition of header fields in messages being used in communication

algorithms.- parameters regarding communication model at the physical layer, timeouts of commu-

nication protocols, etc.- statistics collection, i.e. a tool for obtaining numerical and statistical data that represents

the behaviour of the network.

Modules are defined using the NED language and programmed in OMNeT++ using C++classes. Parameters of modules are pre-defined in the simulations in the initialization file om-netpp.ini. Therefore, a wide family of ini files describe the different scenarios experimented,and other protocol parameters such as the cell factor in CGFP.

Example of ini file inheritance:

include cellproto_025.ini #imports CGFP protocol initialization with Cell Factor=0.25

include easy.ini #imports Easy Laberynthic scenario initialization

#where to store output data for the statistics

output-scalar-file = ../results/cell025_easy.sca

output-vector-file = ../results/cell025_easy.vec

Fields of messages exchanged in the simulation must also be coded in MSG files. Theexample below presents the headers of a routing packet for the GPSR protocol: includes

43

4. Implementations

information of location, perimeter and faces, but it also stores data about the routing path thatwill be collected at the destination of the packet.

Message header example:

message NetwPkt

fields:

double DestLX =-1; //destination location coordinate x

double DestLY =-1; //destination location coordinate x

int destAddr = -1; //destination address

int prevHop = -1; //previous hope address

double LpktX =-1; //location packet entered perimeter mode x

double LpktY =-1; //location packet entered perimeter mode y

double LfaceX =-1; //point where packet entered current face coord x

double LfaceY =-1; //point where packet entered current face coord x

double e0ini =-1; //first edge traversed on current face represented by the

double e0end =-1; //addresses of both extrems!

int mode =0; //packet mode: greedy =0 or perimeter =1

//values for the statistics

long realHopCount =0; //number of hops to reach destination

long idealPathLength =0;//ideal path calculated with Dijkstra

long periHopCount =0; //number of hops made while in perimeter mode

long numSegments =0; //number of perimeter segments travelled or number of switches

long segments[]; //list of segments length in perimeter mode

The implementation of GPSR and the Cell-based Geographic Forwarding Protocol rely onbuilding a complete communication stack, similar to the ISO standard, at each host. A phy-sical layer translates the electromagnetic waves coming over the air into digital information.Above this previous level, MAC controls possible collisions in an medium characterizedby omnidirectional transmissions. Both are treated as the network interface (nic module inOMNeT++) and follow the Wireless LAN standard, which is also known as IEEE 802.11. AWLAN (IEEE 802.11) MAC Layer has been used for the simulations in this thesis for 3 mainreasons: it is a well-defined standard, which keeps growing and supports improved featuresand which is also widely used in wireless networks; second, the existing implementation ofGPSR protocol has been proposed in conjunction with WLAN, and an existing implementa-tion was provided by OMNeT++/MF as the nic module.

As GPSR and CGFP are responsible of delivering packets from every given source to everypotential destination (if a path exists between such hosts), then they have the task of routingover the network. For this reason, these protocols are placed at the network layer (net). Anupper layer would generate traffic depending on the application for which the network hasbeen designed (appl module). A more complex scheme could also include a transport layer

44

4.1. Details on the implementation of GPSR and CGFP

Figura 4.1.: Simplified flowchart and state diagram for a node. Circles represent the node’s state anda major description on the processing phase is represented as a flowchart. A locationservice (LS) determines the node’s own position and provides the location of a potentialtarget.

to care about quality of service as an example. Then a host defined in the implementationsis fully defined with modules: appl, net, nic and also blackboard and mobility (rememberFigure 2.9). Figure 4.1 represents the schematic operation of a host for defined states: idle,receiving and sending, plus the processing functions that each state implies.

The network module of a GPSR host has three different tasks:

- beaconing,

- find a path towards target location,

- keep local information uptodate.

The network layer of CGFP’s communication stack has same tasks plus:

- find a cell path towards target location,

- manage the cell structure.

Therefore, the implementation of a CGFP host clearly differentiates functions related to themanagement of the cell structure, e.g. managing the list of neighbors and views, and those

45

4. Implementations

operations which imply communication to other communication layers and to the locationservice. Figure 4.2 shows the layout of a node in the simulations. The location service isimplemented in OMNeT++ through a module called mobility which is a nested module ateach host module. Mobility permits the network and application modules to store accurateand updated position of the host in the simulation scenario.

Figura 4.2.: Modules in OMNET++ representing protocol stack of GPSR (left) and CGFP(right).

Figure 4.3 represents modules and classes implicated in the implementation of CGFP: mo-dules are drawn as boxes and classes as round-squared boxes. Then each host in the networkwould have the configuration of a CGFP Host. CGFP needs that each host finds equivalencebetween cell coordinates and real coordinates in the simulation playground. Class CellCoord

translates from geographical to cell coordinates and also from global to local coordinates andvice versa. Therefore it is consulted by both the Cell Structure and Network Layer. Class

cNeighbor is a structure for neighbor_info and similarly, class Cell is for cell_info , as theyhave been defined in Chapter 3. In the CellStr module, a host stores an array of neighborsand two arrays of Cells, which are the views. This module also maintains the cell structureuptodate, thanks to beacons, and process virtual forwarding of packets along a cell path.Separately, the network module cares of routing and beaconing, which are the same tasksit has at GPSR implementation. In CGFP, routing simply implies forwarding to neighbordecided by cellStr: in fact, the network module implements PROCESSPACKET while allother functions described in Chapter 3 are implemented in cellStr. However, in GPSR the net

module functions process the complete algorithms for greedy and perimeter forwarding.

In order to have a more practical idea on how the implementation works, the following exam-ple shows the packet generation at a node for the CGFP routing protocol. The procedure for asender node to generate a packet and forward it towards the target somewhere in the network

46

4.1. Details on the implementation of GPSR and CGFP

Figura 4.3.: Description of main modules and classes of a CGFP host in OMNeT++.

can be resumed in the following steps:

1. The application module wakes up after a timeout event that indicates that current hostmust generate traffic. A function in appl generates a packet to be sent to a target. Posi-tion of the target is provided by the mobility module and also the theoretical path lengthis calculated using cTopology. Data is encapsulated and the header contains the geo-graphical position of the destination and its identifier or address. A message is sent tothe network module including the application packet.

2. The network module receives the packet from upper layer. First, if the destination hostis stored in the list of neighbors (see cell array in Figurefig:neighlist), then the neigh-bor’s identifier is stored in the packet as next hop, encapsulated and delivered to the nic

module. Otherwise, the packet is given to the Cell Structure (cellstr module), which isresponsible for finding a cell path using View 2.

3. A cell structure function starts virtually forwarding from local coordinates (0,0) andwhen it finds a cell where it cannot go further, the coordinates of this cell and the cell’sowner are stored in the packet. The packet is turned back to the network module, readyto be forwarded physically to chosen neighbor (which is the owner of the current cell).

47

4. Implementations

Figura 4.4.: A host’s neighbor list in the simulations GUI.

Figura 4.5.: A node’s View 1 in the simulations GUI.

48

4.2. Scenarios

4. The network module then encapsulates the message which includes information for vir-tually forwarding at the next hop. The packet is sent to the nic module.

Similarly to the timeout at the application module, also the network module performs atimer to produce an event for beaconing. The beaconing timer follows timeslots describedin GPSR and calls a function with generates a broadcasting packet containing host’s currentposition, identifier and View 1 (see Table below), so neighbors can construct their local viewof the network. Typically, the reception of a forwarding packet at an intermediate host in thenetwork would obtain the packet at nic module and send it to the network module. There thehost would process the packet as it was indicated in point 2 of previous example.

Node Array of View 1

ID (X ,Y ) Time Cell at (X1,Y1) Cell at (X2,Y2) . . . Cell at (XK,YK)

For more detailed information on CGFP please see Annex B which includes generated docu-mentation for the code written for simulations. A CD-ROM attached to this thesis containsfull code for the simulations of the GPSR and CGFP routing protocols, plus auxiliary codeused in result data processing.

4.2. Scenarios

In this thesis a static model for 2-dimensional scenarios is tested. Bi-dimensional areas arethe most used because they allow us to map a potential user path in a flat geographicalarea. Thus, every portion of a 2-D geographical region can be mapped on a 2-D grid with(x,y) coordinates varying in the limiting ranges given by the playground area of the simulation.

Random placement is actually a good choice for routing schemes. Therefore, also other sce-narios with barriers which are difficult to traverse are studied. The following static scenariosare proposed:

Random placement of nodes. Three different densities are tested, as it is shown in table.

Labyrinth (see Figure 4.7).

49

4. Implementations

Faulty grid. Actually other type of labyrinth, more complex and with a specially tediousbarrier (see Figure 4.9).

The transmission radius for all nodes is 250 meters. Then, the following table shows the den-sities simulated for the networks where nodes are placed randomly.

Size vs. number of hosts 50 nodes 100 nodes

small 1500 m × 300 m 1 node / 9000 m2 –medium 1500 m × 600 m 1 node / 18000 m2 1 node / 9000 m2

large 1340 m × 1340 m 1 node / 35912 m2 1 node / 17956 m2

Figura 4.6.: Random placement of 50 hosts in a small playground.

Figura 4.7.: Easy labyrinth scenario.

50

4.2. Scenarios

Figura 4.8.: Random placement of 50 hosts in a large playground.

Figura 4.9.: Faulty grid with a wide deployed area.

51

4. Implementations

4.3. Parameters

General parameters for the simulations in OMNeT++ have been set as the predefined in theMobility Framework or in other basic simulations given in the tutorials. Parameters are set inthe omnetpp.ini file, so they are common to all simulations performed in this work excludingthe ones specific for each routing scheme. The protocols simulated in this thesis have thefollowing parameters.

Parameters for GPSR are:

Parameter Description

beacon_interval time between sending beacon messagestimeout_interval lifetime for local information about neighboring nodesGG, RNG algorithm for graph planarization: Gabriel Graph or

Relative Neighborhood Graph

Parameters for CGFP are:

Parameter Description

r transmission range` side length of a cellbeacon_interval time between sending beacon messagestimeout_interval lifetime for local information about neighboring nodes

The side length of the cells should be chosen depending on the transmission range. If` ≤ 1

2(√

3− 1)r ≈ 0,366r, then the connectivity property is fulfilled, i.e. there is always aconnection between the nodes that own two adjacent cells [RS05]. Thus, the cell structure isequivalent to the original network topology and a correct message delivery can be guaranteedfor static networks. In the simulation results the side length of the cell is described by the cellcoefficient CF: ` = CF · 1

2(√

3− 1)r. The smaller the cell coefficient is the smaller the cellsare in relation to the transmission radius.

For the simulation to be reliable, beacon_interval and timeout_interval must be the samefor both protocols, because it has important influence on performance (especially in mobilescenarios).

The following table shows events and actions for CGFP:

52

4.4. Metrics

Event Action / Invoked method

initialization INITIALIZECELLS

reception of beacon PROCESSBEACON

reception of data packet PROCESSPACKET

timer event: beacon_interval send beacon messageneighbor timeout RESETCELLS

Network traffic must also be specified in the simulation environment. Here, it is generatedat the application layer for both schemes. Indeed both are network layer protocols being im-plemented using the same communication stack, i.e. application and MAC layers are similar.Only one packet is generated at each host and received in every simulation. This data packetis sent to a randomly chosen destination D, common to all nodes, and answered by D to theoriginal source S. Figure 4.10 shows how a pair of nodes with a query and corresponding re-ply draw the contour of a certain barrier, which also affects many other nodes. This procedurelets us explore the complete network and test all possible types of paths (direct or borderingbarriers). Whether the network is capable for carrying huge amounts of traffic is not the objectof investigation. But finding good paths in the presence of barriers is a challenge even withoutthe occurrence of high traffic.

Figura 4.10.: Example paths for a query and a reply.

4.4. Metrics

Several metrics involve a detailed functionality of a protocol in wireless networks. As saidbefore, both GPSR and CGFP have been simulated using the same physical, MAC and

53

4. Implementations

application layers. Therefore, only metrics related to the performance of these protocolsat network layer are compared here. Some interesting routing metrics were shown at thebeginning of Chapter 2.

Data collected for both protocols is listed below.

– Path length. Also path deviation from Dijkstra’s shortest path for messages which tra-veled only following the greedy rule, and for those which encountered a barrier andfurthered a strategy for recovery.

– Time is measured as the total number of cell hops a message needs to arrive at destina-tion. It refers to how long it takes for CGFP to deliver packets in a certain network.

– Estimation on scenario complexity. Measurement of the perimeters of barriers by sum-ming the lengths of segments in recovery schemes, gives us an idea on the difficulty totraverse a certain scenario, i.e. a network situation with large barriers causes a messageto deviate a big distance from the direct line towards the target. For recovery packets,a segment is the portion of path the packet was forwarded in recovery mode. Then, thelength of a segment (number of hops in segment) gives us the perimeter of a portion ofthe barrier and the number of segments of a message indicates the number of occasionsit found a new barrier or a new face in a visited barrier.

– Storage at nodes. Measure the memory each protocol requires to store local information.

4.5. Validation and Tests

GPSR has been implemented in C++ language following the algorithms presented in Karp’sthesis [KK00], which were also commented in Section 2.1.3. The process of routing packet aruns appropriately greedy or perimeter forwarding. In order to check that the implementationfollows desired patterns, the GUI interface, Tkenv, lets us run the simulation event by eventso printed out messages at each module can be observed separately. This mode of executionis useful in order to debug processing at hosts. Stored information in the form of simulationattributes at each module can also be seen in GUI mode. As an example, one can followall changes in the list of neighbors at a host in order to verify whether local data such asthe list of neighbors is managed properly. GPSR has been firstly simulated under simplerscenarios (see Figure 4.11) and also those shown in this Chapter. Such scenarios were crucialfor determining a well performance of the protocol in perimeter traversal and changing faces.

54


The Statistics module in OMNeT helps measuring the interesting resulting data and collectthem into statistic distributions and percentages. In the simulations, this module has beenprogrammed such that it is independent of any hosts and will collect data from all nodes. The-se are the printed out data I used to obtain in intermediate tests at the end of one simulation run:

Figura 4.11.: Simplest scenarios: one-row scenario and a disconnected topology.

********** GPSR Statistics *********Simulated time: 13.8899 sec

Sent messages: 21

Hopefully Sent messages: 21

Greedy Received messages: 17

Perimeter Received messages: 1

Dropped messages: 0

Total Received messages: 18

55

4. Implementations

Hop count, min: 1

Hop count, max: 21

Hop count, mean: 4.55556

Hop count, stddev: 4.47506

Ideal path, min: 1

Ideal path, max: 11

Ideal path, mean: 3.94444

Ideal path, stddev: 2.43678

Greedy deviation, min: 0 %

Greedy deviation, max: 0.166667 %

Greedy deviation, mean: 0.00980392 %

Greedy deviation, stddev: 0.0404226 %

Perimeter deviation, min: 0.909091 %

Perimeter deviation, max: 0.909091 %

Perimeter deviation, mean: 0.909091 %

Perimeter deviation, stddev: 0 %

Hop count in perimeter mode, min: 0

Hop count in perimeter mode, max: 11

Hop count in perimeter mode, mean: 0.611111

Hop count in perimeter mode, stddev: 2.59272

Number of perimeter segments, min: 0

Number of perimeter segments, max: 1

Number of perimeter segments, mean: 0.0555556

Number of perimeter segments, stddev: 0.235702

Perimeter segments length, min: 11

Perimeter segments length, max: 11

Perimeter segments length, mean: 11

Perimeter segments length, stddev: 0

Storage at a node, min: 1

Storage at a node, max: 18

Storage at a node, mean: 8.82

Storage at a node, stddev: 4.19326

The implementation of CGFP, as it started with no pseudocode available, required a morecomplex process of debug and error detection. Highest complexity in protocol design consistsof the management and update of the cell structure. For this purpose specific GUI repre-sentations have been defined for the Views, as crucial data structures used by hosts to buildtheir knowledge of the network, and therefore, their routing decisions. Figure 4.12 shows thegraphical representation of View 1. A legend follows.

56


Cell type Legend

Unclassified UBarrier BLink XNode N

Figura 4.12.: GUI user-defined representation for View 1 suitable for error debug in the cellstructure.

Screen messages serve in following the whole processes at network layer since a packet arri-ves. The creation of a cell path step by step as it is shown in Figure 4.13.

In some cases also simple printed out messages are enough to determine if the protocol suc-ceed. Or at least to identify the simulation time at which a failure occurs in order to simulatewith the GUI interface until that instant and then check all affected variables. Figure 4.14shows printed out messages on the commandline for dropped packets in the network. Onethen may check whether dropped messages are caused by a disconnected topology or consti-tute the result of a routing break.

Once a dropped packet is detected, one must reproduce the situation for which that happened.Figure 4.15 presents GUI representations used for debugging a loop produced by a bad defi-nition of the cell structure or the forwarding rules. OMNeT’s main window shows simulationtime and processing actions at a host. Typical printed out messages serve in the purge ofthe implementations, as it is common in program development works. Others represent the

57

4. Implementations

Figura 4.13.: Cell path construction in CGFP.

Figura 4.14.:

58


Figura 4.15.: OMNeT++ windows describing network situation at a host.

59

4. Implementations

subnetwork where the host is placed, so one can check the real topology the host confronts,and local information: list of neighbors and views. In many cases the view of one or morehosts’local data is not sufficient for finding protocol failures. So the views only help whenplotted one after another in a gridded multicoloured paper and manual calculations of pathscorroborate desired functionality in the end.

4.6. Obtaining the results

Various random seeds have been established in order to prove statistical independence ofthe results in the simulations. All network topologies presented in previous sections havebeen simulated, and at least 50 runs for each simulation scenario have been performed. Thenthe last step in protocol debug has been to ensure packet delivery for all those hundredsof simulations. Data collected during the simulations is stored output vectors and scalars,which are text files including large data columns. One vector or scalar file is created for eachsimulation, but what is interesting for us is to obtain a certain measurement per file for thedifferent scenarios, i.e. if 50 simulation runs are executed for one scenario it is interestingto have all samples for the hop count metric stored in the same file, and not having 50different files with all measurements together. For this reason, the automatization of thesimulation requires some scripts which have the function of converting OMNeT output filesinto measurement files: AWK tool is useful for this task. Code below presents an example ofthese scripts that were executed under Linux at multiprocessor machines at the University ofPaderborn in order to reduce huge time consumption of simulations.

stats: automatization of several simulation runs

foreach f (../ini_files/cell_rnd*.ini)

rm *.out

rm results/$f:t:r/*.log

echo "Starting simulation $f..."

set i = 1

while ($i <= 50)

nice +15 ./cellproto -f $f -r $i >> $f:t:r.out

echo "Run #$i Organizing statistics"

cd results/$f:t:r

splitvec *.vec

foreach vector (*.vec)

awk -f ../../awk_cmd.txt $vector

end

rm *.vec

60

4.6. Obtaining the results

cd ../..

@ i = $i + 1

end

end

echo "End of simulations. Please see results/"

awk_cmd: extraction of measurements from vectors into new files

# awk command file

(NR == 1){ #first input line

name = $5

name = substr (name, 2, length(name)-2)

name = name ".log"

printf "\tWriting data to %s\n", name

}

NR >1 {

printf "\t%s\n", $2 >> name

}

The execution of previous code results in the generation of multiple files with extension ".log".Such files are many and large thus the manipulation of data inside conforms a tedious work.These files where then imported in MATLAB 7.14 and data samples for each measurementhave been used as arrays for statistical processing. Working with data arrays makes graphicgeneration with such tool immediate.

61

4. Implementations

62

5. Experimental Results

The incomplete MAC Layer of the Mobility Framework 1.0a5, which does not support packetretransmissions or avoid collisions, causes loss of messages in high density areas. This mayhappen with high traffic on routing packets but also in beacon broadcasting. Therefore it wasnot possible to test many different traffic flows, as it would have been desirable. Collisionsbetween beacons may produce incomplete neighbor tables at nodes, that can cause routingloops. This Mac Layer leak demanded to divide the simulations for static scenarios intotwo parts: learning the neighborhood and communicating. In the first part only beaconsare broadcasted, stopping this procedure at the beginning of the communication phase forinformation exchange. Also in mobility scenarios, a necessity to separate dropped packetsexists: some may be lost due to mobility and others because of collisions between beaconsand routing packets. For this reason, mobility is still a matter of study and therefore, it isproposed as further work over CGFP.

This section describes the results obtained for the static networks proposed in Section 4.2.First, some statistical results appear for GPSR and CGFP separately. Then, a brief comparisonof these protocols follows. Conclusions on each of the experiments are further explainedtogether with the graphics.

5.1. Statistics on GPSR protocol.

The results presented in this section show the performance of GPSR (see Section 2.1.3). Thegraphics represent the path length for all packets in the network as a comparison with theideal path calculated as Dijkstra’s shortest path, given the graph of the network. This firststatistic is expressed as a box and whisker plot, showing a box with lines at the lower quartile,median, and upper quartile values and whiskers showing the extent of the rest of the data.

63


Outliers are drawn beyond the ends of the whiskers.

It has been introduced in Chapters 3 and 2, that the greedy rule works, and is basicallyused in both GPSR and CGFP, but most difference come from the strategy to traverseholes or barriers. Therefore, selected paths in these recovery schemes are different, so alsostatistics on this are calculated. The number of hops in perimeter mode must be understoodas the total path length, i.e. from source to destination, for a packet that reached a localminimum at some point and was forwarded for some time using a recovery rule. Then, thesegment length is the number of hops given in recovery mode and the number of segments

is the number of times the packet had to change from greedy to recovery strategy duringits travel. The last three measurements are represented as histograms, as it is important forfurther comparisons, that one can see the percentage of packets sent with recovery forwarding.

In the following figures, it can be seen that the highest density of nodes, corresponding to asmall scenario with a fixed number of nodes (see figure 5.1), has the lowest rates of packetstraveling in recovery mode. The reason for this is that high density does not leave free spacefor barriers, so the greedy rule is applicable in most cases. As already mentioned in Sec-tion 4.2, random scenarios are good choices for most routing approaches. "Tricky"scenariosas those from Figures 5.6 and 5.7 result in larger boxes, which means that a significant part ofthe messages usually takes more hops to reach the target. These scenarios are more complex,because shortest paths are difficult to find.

Figure 5.1 (up) shows that for that high density scenario, GPSR finds shortest paths equal tothe theoretical shortest path calculated with Dijkstra in most situacions. Such messages con-tained in the boxplots correspond to greedy messages, while most outliers refer to perimetermessages. However, histograms below show that only 1 % of total messages sent in currentnetwork scenario travelled in perimeter mode, i.e. the topology contains few barriers. Evenmore information can be extracted from this: there is only one large barrier, as soon as numberof segments is one for all perimeter cases. But how can a large barrier exist inside such hichdensity of nodes? The explanation for this result is that the limits of the network also conforma barrier. Imagine a packet which encountered a small barrier and started bordering it usingthe right-hand rule. This action of perimeter traversal deviates its initial path and leaves itat a node which lies at the topology border. The packet ignores this and continues travellingfollowing the right-hand rule, so it borders the whole network until it arrives at a node where

64


Figura 5.1.: GPSR 50 nodes, small playground.

65


it can turn back to greedy forwarding. Above described situation is not common, but it alsoinevitable. Although other random scenarios also encounter this situation, it can be consideredan exceptional case for which all algorithms using the right-hand rule get affected.

In Figures 5.2, 5.3 and 5.5 lower density scenarios have been simulated. Here a higestpercentage of perimeter packets exist, which encountered one or more barriers with variableperimeter length.

Figure 5.4 shows simulation results for a random scenario with node density similar to that ofFigure 5.1. Therefore, graphics represent a similar behaviour regarding perimeter messages.Most packets are greedy forwarded so shortest paths are discovered and a tiny pertentage ofpackets is sent in perimeter mode.

66


Figura 5.2.: GPSR 50 nodes, medium playground.

67


Figura 5.3.: GPSR 50 nodes, large playground.

68


Figura 5.4.: GPSR 100 nodes, medium playground.

69


Figura 5.5.: GPSR 100 nodes, large playground.

70


Figura 5.6.: GPSR Easy Labyrinth.

71


Figura 5.7.: GPSR Faulty Grid.

72

5.2. Statistics on CGFP

5.2. Statistics on CGFP

In the previous section it has been seen that some scenarios are more complex for routingthan others. The extraction of similar statistics for CGFP would not give new insights, but it isinteresting to know the number of cell hops a message has to travel if the destination is acces-sible. Then, Figure 5.8 represents the evolution of time response of the protocol depending onthe scenario, for four different cell sizes (defined by the cell coefficient, CF).

Figura 5.8.: CGFP analysis for decreasing-density scenarios. Legend: (1) 50 nodes, small (2) 100nodes, medium (3) 50 nodes, medium (4) 100 nodes, large (5) 50 nodes, large (6)EasyLabyrinth (7) Faulty Grid

73


5.3. Path length comparison between GPSR and

CGFP.

Protocols considered in this thesis determine different paths for messages in the network.The following figures represent as box plots the intervals where most of the messages resideconcerning their path length.

Figure 5.9 shows that the path length found by CGFP is not dependent on the cell size forthis specific situation. Also most messages are delivered within a few hops in GPSR1 but theupper bound for the path length is higher than in CGFP. Please note that this scenario is theone with highest node density and therefore most messages only need greedy forwarding. Asit was explained before, the main differences between protocols come from the observation ofisolated recovery messages. This can be seen later in Sections 5.4 and 5.5.

Figura 5.9.: Path length Comparison. 50 nodes, small playground.

Figures 5.10 and 5.11 show a better global performance of GPSR, while networks with highernumber of nodes (Figures 5.12 and 5.13) reach a maximum path length when GPSR runs.

1In further comparisons, results for GPSR use RNG planarization.

74

5.3. Path length comparison between GPSR and CGFP.

Figura 5.10.: Path length Comparison. 50 nodes, medium playground.

Figura 5.11.: Path length Comparison. 50 nodes, large playground.

75


Figura 5.12.: Path length Comparison. 100 nodes, medium playground.

Figura 5.13.: Path length Comparison. 100 nodes, large playground.

76

5.3. Path length comparison between GPSR and CGFP.

Figura 5.14.: Path length Comparison. Easy Labyrinth.

Figura 5.15.: Path length Comparison. Faulty grid.

77


5.4. Path deviation comparison for greedy messages.

Path deviation is measured as the additional number of hops a routing protocol needs in rela-tion to the shortest path, i.e. it is calculated as the difference between the path length reachedby the protocol and the shortest path. From the observation of the following statistics, it canbe seen that GPSR, by applying MFR in greedy mode, always finds the shortest path with aminimum rate of exceptional cases, which imply only 1 or 2 extra hops. As CGFP first virtua-lly forwards inside the cell structure, it does not always forward to the neighbor which makesmost progress. Moreover, CGFP uses a cell-based greedy forwarding, where the physical han-dover takes place when the half-radius is left, so one expects that GPSR needs less hops thanCGFP. The following figures also show a common pattern in CGFP: greedy messages takelonger paths when using larger cells.

Figura 5.16.: 50 nodes, small playground.

The results obtained for labyrinthine scenarios differ from previous ones. Note that these ne-tworks (Figure 4.9) contain an wide barrier, so a few direct paths can be drawn without en-countering the barrier. Then, all protocols have the same response because greedy paths arereally short.

78

5.4. Path deviation comparison for greedy messages.

Figura 5.17.: Greedy deviation Comparison. 50 nodes, medium playground.

Figura 5.18.: Greedy deviation Comparison. 50 nodes, large playground.

79


Figura 5.19.: Greedy deviation Comparison. 100 nodes, medium playground.

Figura 5.20.: Greedy deviation Comparison. 100 nodes, large playground.

80

5.5. Path deviation comparison for recovery messages.

Figura 5.21.: Greedy deviation Comparison. Easy Labyrinth.

Figura 5.22.: Greedy deviation Comparison. Faulty grid.

5.5. Path deviation comparison for recovery

messages.

In order to solve the problem of local minima in front of a barrier, GPSR uses the right-handrule on a planarized subgraph in recovery mode. In contrast, CGFP performs a cell-based ba-rrier traversal, which also uses the right-hand rule. The following graphics for the comparisonshow which protocol is more appropriate in the situations observed. The table below resumesthese observations by extracting the average number of hops of the deviation. Bold quantitiesrepresent the most promising result while italics are the second best option.

Protocol vs. scenario GPSRCGFP CGFP CGFP CGFP

(CF=0.25) (CF=0.5) (CF=0.75) (CF=1.0)

Random 50 nodes, small 41.55 10.10 8.41 14.62 17.59Random 50 nodes, medium 14.04 14.80 12.96 15.28 9.78Random 50 nodes, large 20.41 18.45 20.49 24.20 13.61Random 100 nodes, medium 22.55 18.12 20.95 17.57 5.15Random 100 nodes, large 21.60 11.52 12.09 13.55 10.12Easy Labyrinth 10.89 18.07 13.23 11.43 12.10

Faulty Grid 8.87 28.31 19.17 15.95 17.69

This result finds an explanation in the fact that, especially in high density scenarios, theplanarization in GPSR removes long crossing edges and preserves the short ones. This

81


produces a larger hop count for messages forwarded by GPSR in recovery mode. On theother hand, in labyrinth scenarios GPSR obtains the best paths. A reason for this is that bothscenarios are planar or quasi-planar, so GPSR uses all edges in the network and only the righthand rule is applied. This hypothesis is reinforced by statistics shown in figures 5.6 and 5.7,where results obtained for two different planarizations (RNG, GG) are exactly the same afterseveral simulations, so one can deduce that planarization executed by GPSR is not relevant insuch networks. In these cases, the cell-based strategy of CGFP takes no advantage.

Figura 5.23.: Recovery deviation Comparison. 50 nodes, small playground.

5.6. Comments on the results.

The results obtained in the simulations show that the strategy of MFR, used by GPSR, is moreefficient when the network contains no barriers, than the scheme used by CGFP, which is acell-based greedy forwarding. GPSR achieves a better performance in greedy mode, becausethe algorithm uses MFR as progress rule, i.e. the next hop is selected among all reachableneighbors whereas the progress rule of CGFP restricts this to the nodes inside the half-radius.However, simulations for messages that use a recovery rule to border the perimeter of a barrierdemonstrate that CGFP performs better in random scenarios with low node density.

82


Figura 5.24.: Recovery deviation Comparison. 50 nodes, medium playground.

Figura 5.25.: Recovery deviation Comparison. 50 nodes, large playground.

83


Figura 5.26.: Recovery deviation Comparison. 100 nodes, medium playground.

Figura 5.27.: Recovery deviation Comparison. 100 nodes, large playground.

84


Figura 5.28.: Recovery deviation Comparison. Easy Labyrinth.

Figura 5.29.: Recovery deviation Comparison. Faulty grid.

85


86

6. Project History

6.1. Context

This Proyecto Final de Carrera is the result of two years work developed in two differentEuropean Universities: University of Paderborn (Germany) and University Carlos III (Spain).First year 2004/05 took place within the Erasmus European Exchange Program under a9-month grant. Simultaneously to other lectures I decided to participate in an academic ex-perience which was not feasible to have at my home university: a Project Group about Large

Scale Ad Hoc Networks based on Mica Motes and TinyOS technology, lead by professorsChristian Schindelhauer and Holger Karl. A Project Group is an annual lecture compoundby a couple of professors and a team of 10 students that simulate a real-life work from thedefinition, investigation and implementation to deployment and marketing. The experimentconstituted a great personal experience and attracted me to the ad hoc world. From this recentknowledge I got also practices tutored by Stefan Rührup at Heinz Nixdorf Institute in thematter of developing SAHNE, a simulator for mobile ad hoc networks, and could also developmy Technological Study about Topology Control for Mobile Ad Hoc Sensor Networks based

on Clustering.

Such background urged me to start a deeper investigation about topological strategies linkedsomehow to the work developed by Christian and Stefan that concluded with the publicationof [RS05]. So I started expanding my knowledge about topological and routing strategiesbased on position. This thesis also required some training on simulations that were runat my laptop and also at computer rooms at the University. There Stefan and I installed aCVS repository in order to facilitate the co-design of the Cell-based Geographic ForwardingProtocol. Later this initiative was crucial for the implementations as I came back to Spain,which happened at the beginning of academic year 2005/6. At this point GPSR was alreadyimplemented and tested but the new CGFP protocol was little further than an outline. So wecontinued the development of the project during whole 2005/6. Because I returned to a full

87

6. Project History

lecture calendar and Stefan was also working at his doctorate, project evolution delayed morethan predicted in a fulltime project. My work was then supervised and supported by Stefanthrough emails, IP phone calls and the repository. Thesis writing finally concluded currentyear with the help of Celeste Campo and Carlos Garcia Rubio at Telematics Department atUniversity Carlos III.

6.2. Project Development

In this context we established at University of Paderborn a fixed purpose to design and im-plementation of the Cellbased Geographic Forwarding Protocol in order to evaluate the pro-position in [RS05]. Work development initiated in Germany can be resumed in the followingpoints:

1. Investigation and reading about related work and specialized bibliography.

2. Deep insight into GPSR.

3. Decision for a simulation environment. First experiences with the simulation tool: OM-NeT++. Installation under both Windows (Visual Studio) and Linux and test of examplesfor beginners.

4. Decision for Mobility Framework or INET. Expansion of OMNeT++ with the MobilityFramework libraries and examples. Tests for basic configurations.

5. Start writing a State of the Art text in order to document in detail all progress and bugs.

6. Implement GPSR in OMNeT.

7. Program test scenarios and metrics.

8. Configure statistics collection.

9. Outlines of CGFP: schematic desired functionalities and management of local informa-tion of the cell structure based on [RS05].

10. Implement CGFP in OMNeT and purify.

11. Automatization of several independent simulations. Learning and programing awk andexecutables.

88

6.3. Budget

12. Study of statistic programs for calculations and plots. Program sample data processingin MATLAB.

13. Thesis writing in English.

Thanks to previous research on ad hoc networks, first readings constituted lightest tasks.However, the comprehension of GPSR together with the learning from zero level of a newsimulation tool conformed a huge amount of work and dedication that lasted 5 months. Af-terwards I was close to leave the University of Paderborn, and the possibility of continuingthe project far away did not really seem to succeed. Hardest work war still to be done, as thegestation of an original strategy for CGFP meant the duplication of work in relation to whathad been done for GPSR. Despite on-line working has been slow some times or frustratingsome others, the project went on and today I am proud to say the work is finished.

6.3. Budget

The development of this Proyecto Final de Carrera involved both human and material resour-ces, which are considered in this section from an economical point of view. Regarding materialresources, the following list resumes computing equipment and other tools necessary:

Laptop running Windows XP

2 multi-processor PC’s running Linux O.S.

Non-free literature.

Software:

• Windows XP

• Linux Kubuntu distribution (free)

• Microsoft Visual Studio .NET 2003

• OMNeT++ version 3.1 plus MF package (free)

• MATLAB 7 and Statistics Toolkit

• MikTeX/WinEdt for LATEXedition under Windows

• Kile for LATEXedition in Kubuntu (free)

89

6. Project History

• TortoiseCVS client (free)

Therefore, total budget invested in equipment amounts to:

Material budget

Equipment Price (�)

Laptop 900

Pc’s 4.000

Literature 200

MS Visual Studio 200

MATLAB 7 2.000

WinEdt 40

TOTAL 7.340

Human resources comprise work realized by tutors and me. Honoraries have been calculatedfrom ranges given by COIT (Colegio Oficial de Ingenieros de Telecomunicaciones). Total timeinverted in this thesis summarizes 5 months in Germany and 8 months in Spain, working about3 hours a day, five days a week. This altogether amounts to a total of 780 hours aproximately.Normal work hour is charged at 65� and a correction factor must be applied to this quantityaccording to work complexity. A corrector coeficient of CF=0.6 is valid for us. Now thisscheme is accurate for time invested at University Carlos III in Madrid, so let’s add a 15 %extra income for time spent in Paderborn. Finally, honoraries amount to 32.175�. But humanresources also comprise direction and support provided by tutors, that can be estimated as 7 %of honoraries each. Also 16 % of IVA taxes must be calculated.

Honoraries (�)

Execution 32.175

Direction 4.505

Total 36.680

Then total budget would be:

Total Budget (�)

Equipment 7.340

Honoraries 36.680

Total 44.020

Total (taxes incl.) 51.063

90

7. Conclusions and further work

In this Proyecto Final de Carrera, two geographic routing protocols have been implementedand their performances have been compared. This work involves a deep study of the forwar-ding strategies typically used in ad Hoc networks, especially geographic forwarding focusingon GPSR. Great efforts have been dedicated to the comprehension of GPSR and its imple-mentation in order to emulate their work and construct a reliable evaluation of the protocol.However, the most original contribution of this thesis is the design of a new protocol, CGFP,based on a position-based approach that uses a cell structure. The Cell-based GeographicForwarding Protocol, CGFP, is presented in this thesis and results in the co-publication withStefan Rührup of its specification [BR06]. The design of CGFP constituted a master workin the definition of a routing protocol at each of its several functions: forwarding decisions,perimeter strategies, management of local information in a distributed manner, timeoutsmanagement, routing loops avoiance. Moreover, both protocols have been implemented,simulated and compared under a widely used public-source tool: OMNeT++.

The project has been developed in two main phases that implicated different complexity.Firstly at University of Paderborn I had the opportunity to collaborate the group leaded by C.Schindelhauer which is specialized in ad hoc networks and furthers several investigations inpartnership with Heinz Nixdorf Institut. Also the paper in which CGFP is based [RS05] waswritten in this context so I was able to learn its basics directly supported by the authors, whatof course is a privilege. Even my training in the use of OMNeT and the Mobility Frameworkcounted with the experience of Holger Karl, who is one of the ideologues of MF libraries.The second part of the project lasted one year more and its main difficulty has been on-lineworking. This situation forced me to profit in the use of CVS repositories and to widelydocument on-going work. As a result this project brought me knowledge of various tools thatmay be useful in the future, such as LATEX, CVS repositories, AWK and linux scripts, togetherthe use of OMNeT. However, time consumed in the elaboration of this thesis has been hugefor a Proyecto Final de Carrera even more because at my return many lectures were scheduled

91

7. Conclusions and further work

simultaneously to my work on the project.

The results obtained in the thesis show that the strategy of MFR, used by GPSR, is moreefficient when the network contains no barriers, than the scheme used by CGFP, which is acell-based greedy forwarding limited to half-radius. However, simulations for messages thatuse a recovery rule to border the perimeter of a barrier demonstrate that CGFP performs betterin scenarios with random placement of nodes in the network and low node density. From theseresults, further work would be the implementation of a combined strategy that implementsMFR in greedy mode and cell-based forwarding for recovery from local minima. Anotherpossibility is to improve the function getDirection, which obtains a virtual cell path towardsthe target. In the current implementation this function is very simple, but could also use theBresenham’s line drawing algorithm, because links to other nodes in the cell structure aredrawn using this rule. In fact the design of function setLinkCells caused hardest bugs duringprotocol tests and this is a crucial matter for achieving desired behaviour of CGFP becausecell paths only use node or link cells. In any case, a necessary improvement passes under therevision of the cell paths constructed by CGFP in some scenarios where the rate of deliveredpackets does not achieve the totality. For this problem getDirection may be the key again.

From all objectives set in the beginning of the project and presented in the Introduction, onlymobile simulations could not be achieved. Limitations imposed by the implementation of theWLAN physical layer provided by the simulation tool, restricted the experiments to staticnetworks. Probably newest versions of OMNeT/MF frameworks solve these problems. BothGPSR and CGFP are capable of handling such situations, but no implementation is yet donefor CGFP in mobile networks. In such case, nodes have to update the cell structure also be-cause of their own movement. Mobility of nodes can also create temporal loops because linksbetween pairs of nodes are constantly changing. A possibility for avoiding could be to restartgreedy forwarding when local loops are detected.

92

A. Notation in the pseudocode

For the pseudocode we use the following notation: Function names are typeset in smallcapitals, data types are slanted, and comments are typeset in italics:

GETDIRECTION function namecell_type type// the local position comment

For referring to the cells in the views we use a simplified notation: “foreach cell in view1”where cell can be regarded as pointer to a field in the array. We also write “view1(cell)”instead of “view1[cell.x, cell.y]” as a simplified notation for two-dimensional arrays. Forupdating cell information we use the notation “cell.set(cell_type type, address owner)”.The following table shows the basic data types used in the pseudocode:

Type Description

address integer (network address)cell_type {node, link, barrier, unclassified}cell_coord pair of integer; we use c.x and c.y to refer to the componentsposition pair of double; we use p.x and p.y to refer to the componentsdirection {(0,1),(0,-1),(1,0),(-1,0),(0,0)}

direction is used to point at an orthogonally neighboring cell (Fig. 3.5)time time format

93

A. Notation in the pseudocode

94

B. Documentation

Generated by Doxygen 1.4.7. Only main functions and attributes are included.

B.1. CellStructure Class Reference

This module manages the cell structure: View 1 and View 2.

Public Member Functions

virtual void initialize (int)

Initialization of the module and some variables.

void handleMessage (cMessage ∗)

Called every time a message arrives. Arrival of messages causes events to occur.

void finish ()void resetCells (int)

Resets cells that belong to a neighbor which has dissappeared.

void cellCopy (void)

Copies updated cells in View 1 into View 2.

CellCoord getLocalCellPos (int, int)

Translates from global to local coordinates.

CellCoord getGlobalCellPos (CellCoord)

Translates from local to global coordinates.

95

B. Documentation

void updateView1 (CellCoord, int, int, cNeighbor ∗)

Updates View 1.

void initializeView1 (CellCoord, int, int)

Initializes View 1 to unclassified cells.

void updateView2 (CellCoord, int, int, cNeighbor ∗)

Updates View 2.

void initializeView2 (CellCoord, int, int)

Initializes View 2 to unclassified cells.

void updateCells (BeaconCellsData ∗)

Updates the views using information at received beacon.

void setLinkCells (CellCoord, CellCoord, int, cNeighbor ∗)

Draws a path of link cells between current host and one neighbor.

void findCellPath (cNetwPkt ∗)

Finds a cell path to a cell closer to the destination.

CellCoord getNextGreedyCell (cNetwPkt ∗, CellCoord)

Virtually forwards the packet in greedy mode one cell hop ahead.

CellCoord getNextRecoveryCell (cNetwPkt ∗, CellCoord)

Virtually forwards the packet in recovery mode one cell hop.

Protected Attributes

int sidegateIn

Gate identifier. These gates allow communication with the module of the Network Layer.

View ∗ view1

96

B.2. Cell Class Reference

View 1. Local information to broadcast in beacons.

View ∗ view2

View 2. Used for virtually forwarding.

double radius

Transmission Radius.

double cellside

Size of cell side.

B.2. Cell Class Reference

This class describes the information stored at a cell.


Cell (char ∗s, CellCoord c)

Constructor. Initializes type to unclassified and owner to no_owner.

Cell ()

Constructor. Initializes type to unclassified and owner to no_owner.

void set (int _type, int _owner)

Sets type and owner of cell.

void copyFrom (Cell ∗c)

Copies data from other cell to this cell.

void initialize (CellCoord _c, int _type, int _owner)

Initializes to given parameters.

bool isFwdCell ()

97

B. Documentation

Returns whether a cell can be used for virtually forwarding.

int getType ()

Returns cell type.

int getOwner ()

Returns cell owner.

CellCoord getCoord ()

Returns cell coordinates.

void setCoord (CellCoord cc)

Modifies cell coordinates.

Public Attributes

CellCoord coordinates

Coordinates of the cell.

int type

Type of the cell {Link, Barrier, Unclassified}.

int owner

Owner of the cell.

cNeighbor ∗ neighbor

Pointer to owner of the cell in the list of neighbors. Necessary to know the timestamp.

B.3. CellCoord Class Reference

Class for storing host positions in relation to a cell grid.

98

B.3. CellCoord Class Reference


CellCoord ()

Constructor. Initializes coordinates to (0,0).

CellCoord (const CellCoord &pos)

Constructor. Initializes coordinates.

void swap ()

Swaps the two coordinates.

void setCoord (int _x, int _y)

Sets given cell coordinates.

void setCoord (CellCoord c)

Sets given cell coordinates.

CellCoord (double _x, double _y, double cell_side)

Translates geographical coordinates to cell coordinates.

void getCoord (Coord ∗a, double cell_side)

Translates geographical coordinates to cell coordinates.

void operator ∗ (int n)

Multiplies an integer times a coordinate.

CellCoord operator= (CellCoord a)

Assigns given cell coordinates to this.

CellCoord operator+= (CellCoord a)

Adds given coordinates. Useful for translating from local to global coordinates.

CellCoord operator-= (CellCoord a)

Subtracts given coordinates. Useful for translating from global to local coordinates.

99

B. Documentation

void turnLeft ()

Calculates coordinates of cell to the left, given current cell coordinates and direction.

void turnRight ()

Calculates coordinates of cell to the right, given current cell coordinates and direction.

int distance (CellCoord a)

Calculates the distance from this cell to another at given coordinates.

Public Attributes

int x

Horizontal coordinates of the cell.

int y

Vertical coordinates of the cell.

Friends

CellCoord operator+ (CellCoord a, CellCoord b)

adds two coordinate vectors.

CellCoord operator- (CellCoord a, CellCoord b)

Subtracts two coordinate vectors.

bool operator== (CellCoord a, CellCoord b)

Tests whether two coordinate vectors are equal.

bool operator!= (CellCoord a, CellCoord b)

Tests whether two coordinate vectors are not equal. Negation of the operator==.

CellCoord getDirection (CellCoord a, CellCoord b)

100

B.4. cNeighbor Class Reference

Given the coordinates of current cell and coordinates of cell where the target is, findsdirection {North, East, South, West} of next cell hop towards the target.

double distance2corners (Coord p, CellCoord gc, double cellside)

Finds the distance from a geographic position to all corners in a cell.

B.4. cNeighbor Class Reference

This class describes the information of a neighbor stored as local information in the list of neighbors.


cNeighbor (char ∗s, int i, Coord c, CellCoord cc, double _time)

Constructor. Initializes neighbor information from information given (comes from beaco-ning).

Public Attributes

int node_id

Identifier or network address of node.

CellCoord ccoord

Cell (p. 97) coordinates of neighbor.

Coord location

Global geographical coord.

double timestamp

Timestamp of the instant when this information was stored.

int expiry

After this time information expires and is not reliable anymore.

101

B. Documentation

B.5. cNetwLayer Class Reference

This module defines the Network layer for the CGFP Protocol.




void handleMessage (cMessage ∗)

Called every time a message arrives.

virtual int getMacAddr (int)

Translate network address into MAC address.

virtual const int myNetwAddr ()

Returns network address of this host.

Protected Member Functions

virtual void handleSelfMsg (cMessage ∗)

Handle self messages such as timer...

virtual void handleUpperMsg (cNetwPkt ∗)

Handle messages from upper layer.

virtual void handleLowerMsg (cMessage ∗)

Handle messages from lower layer.

void addNeighbor (int, Coord, CellCoord, double)

Adds a neighbor to the list of neighbors.

void deleteNeighbor (int)

Removes a neighbor from the list of neighbors.

102

B.5. cNetwLayer Class Reference

void controlNeighbors (void)

Checks for timers in the list of neighbors. If there is no updated information from a neigh-bor in some time, it must be removed from the list.

void handleMyBeaconTimer (void)

A timer schedules when this host has to broadcast its own beacon.

void sendBEACONframe (void)

Broadcasts a beacon.

void forwardPacket (cNetwPkt ∗)

Forwards packet.

cNetwPkt ∗ encapsMsg (cApplPkt ∗)

Encapsulate the ApplPkt into an NetwPkt.

void sendDown (cNetwPkt ∗, int, int)

Sends a message to the lower layer; waits delay seconds before sending.

void sendUp (cNetwPkt ∗)

Sends a message to the upper layer; waits delay seconds before sending.

void sendDelayedDown (cNetwPkt ∗, double, int, int)

Sends a message to the lower layer.

void sendDelayedUp (cNetwPkt ∗, double)

Sends a message to the upper layer.

const char ∗ getNeighborName (int addr)

Function to get the logName of the sender of a message.

103

B. Documentation


cNetwPkt ∗ netwPrototype

Prototype that defines a Network Packet.

CellChannelControl ∗ cc

Pointer to CellChannelControl for translating MAC and network addresses, know trans-mission radius for cell coordinates calculations.

Statistics ∗ st

Pointer to Statistics for recording data results.

int sidegateIn

Gate identifiers Gate identifiers. These gates allow communication with the module ofthe cell structure.

int uppergateIn

Gate identifiers. These gates communicate with upper and lower layers of the communi-cation stack.

B.6. cApplLayer Class Reference




Protected Member Functions

virtual void handleSelfMsg (cMessage ∗)

Handle self messages such as timer...

104

B.6. cApplLayer Class Reference

virtual void handleLowerMsg (ApplPkt ∗)

Handle messages from lower layer.

void generatePkt (int)

Generates data packets.

int findRndDest (void)


ChannelControl ∗ cc

Pointer to ChannelControl for accessing all nodes positions.

Statistics ∗ st

Pointer to Statistics for recording data results.

int nHosts

Total number of hosts in the neighbor (all of them are posible destinations).

double data_interval

Time interval between two generated data user packets.

double initial_data_int

Time when data communication starts and beaconing stops.

cTopology topo

Dijkstra element to calculate shortest path.

105

B. Documentation

106

Bibliografía

[BB04] Azzedine Boukerche and Luciano Bononi. Simulation and modeling of wireless, mobileand ad hoc networks. In Stefano Basagni, editor, Mobile ad hoc networking, pages 373–409. John Wiley & Sons, 2004.

[BCSW98] Stefano Basagni, Imrich Chlamtac, Violet R. Syrotiuk, and Barry A. Woodward. A dis-tance routing effect algorithm for mobility (DREAM). In Proceedings of the 4th An-nual ACM/IEEE International Conference on Mobile Computing and Networking (Mobi-Com’98), pages 76–84. ACM Press, 1998.

[BMSU01] Prosenjit Bose, Pat Morin, Ivan Stojmenovic, and Jorge Urrutia. Routing with guaranteeddelivery in ad hoc wireless networks. Wireless Networks, 7(6):609–616, 2001.

[BR06] Inés Bebea González and Stefan Rührup. The cell-based geographic forwarding proto-col, Specification. Technical Report TR-RSFB-06-79, University of Paderborn, Germany,2006.

[FGG04] Q. Fang, J. Gao, and L. Guibas. Locating and bypassing routing holes in sensor networks.In Proc. of the 23rd Conference of the IEEE Communications Society (Infocom), pages2458–2468, 2004.

[Fin87] Gregory G. Finn. Routing and addressing problems in large metropolitan-scale interne-tworks. Technical Report ISI/RR-87-180, University of Southern California, March 1987.

[GS02] Silvia Giordano and Ivan Stojmenovic. Position-based ad hoc routes in ad hoc networks.In Mohammad Ilyas, editor, The Handbook of Ad Hoc Wireless Networks, chapter 16.CRC Press, 2002.

[GS04] Silvia Giordano and Ivan Stojmenovic. Position based routing algorithms for ad hocnetworks: A taxonomy. In Xiuzhen Cheng; Xiao Huang; Ding-Zhu Du, editor, Ad HocWireless Networking, pages 103–136. Kluwer, 2004.

[HL86] Tingh-Chao Hou and Victor Li. Transmission range control in multihop packet radionetworks. IEEE Transactions on Communications, 34(1):38–44, January 1986.

[JM96] D. B. Johnson and D. A. Maltz. Dynamic Source Routing in Ad Hoc Wireless Networks.In T. Imielinski and H. Korth, editors, Mobile Computing, pages 152–181. Kluwer Aca-demic Publishers, 1996.

[Kar00] Brad Karp. Geographic Routing for Wireless Networks. PhD thesis, Harvard University,Cambridge, MA, October 2000.

[KK00] Brad Karp and H. T. Kung. GPSR: greedy perimeter stateless routing for wireless ne-tworks. In Mobile Computing and Networking, pages 243–254, 2000.

107

Bibliografía

[KSU99] Evangelos Kranakis, Harvinder Singh, and Jorge Urrutia. Compass routing on geometricnetworks. In Proc. 11th Canadian Conference on Computational Geometry, pages 51–54,Vancouver, August 1999.

[KWZ02] Fabian Kuhn, Roger Wattenhofer, and Aaron Zollinger. Asymptotically optimal geometricmobile ad-hoc routing. In Proceedings of the 6th international workshop on Discretealgorithms and methods for mobile computing and communications, pages 24–33. ACMPress, 2002.

[LJC+00] Jinyang Li, John Jannotti, Douglas S. J. De Couto, David R. Karger, and Robert Morris. Ascalable location service for geographic ad hoc routing. In Proceedings of the 6th AnnualACM/IEEE International Conference on Mobile Computing and Networking (MobiCom2000), pages 120–130, New York, NY, USA, 2000. ACM Press.

[LW05] Marc Löbbers and Daniel Willkomm. A Mobility Framework for OMNeT++, Version1.0a5, User Manual, 2005. http://mobility-fw.sourceforge.net/.

[MES+05] C. Mallanda, S. Else, A. Suri, V. Kunchkarra, S.S. Iyengar, R. Kannan, and A. Durresi.Simulating wireless sensor networks with OMNeT++. IEEE Computer, 2005.

[PB94] Charles E. Perkins and Pravin Bhagwat. Highly dynamic destination-sequenced distance-vector routing (dsdv) for mobile computers. In Proceedings of the ACM Conference onCommunications architectures, protocols and applications (SIGCOMM ’94), pages 234–244, 1994.

[RKY+02] S. Ratnasamy, B. Karp, L. Yin, F. Yu, D. Estrin, R. Govindan, and S. Shenker. Ght: Ageographic hash table for data-centric storage in sensornets. In Proceedings of the FirstACM International Workshop on Wireless Sensor Networks and Applications (WSNA’02),September 2002.

[RS05] Stefan Rührup and Christian Schindelhauer. Competitive time and traffic analysis ofposition-based routing using a cell structure. In Proceedings of the 5th IEEE Inter-national Workshop on Algorithms for Wireless, Mobile, Ad Hoc and Sensor Networks(IPDPS/WMAN’05), page 248, 2005.

[Rüh06] Stefan Rührup. Position-based Routing Strategies. PhD thesis, University of Paderborn,Germany, 2006.

[SOSM06] J. Simó, P. Osuna, J. Seoane, and A. Martínez. An IEEE 802.11 static mesh networkdesign for isolated rural areas in developing regions. IEEE INFOCOM 2006, Barcelona,2006.

[Sto02] Ivan Stojmenovic. Position based routing in ad hoc networks. IEEE CommmunicationsMagazine, 40(7):128–134, July 2002.

[TK84] Hideaki Takagi and Leonard Kleinrock. Optimal transmission ranges for randomly dis-tributed packet radio terminals. IEEE Transactions on Communications, 32(3):246–257,March 1984.

[Var05] András Varga. OMNeT++ Discrete Event Simulation System, Version 3.1, User Manual,2005. http://www.omnetpp.org/.

108

Bibliografía

[WMHF02] Jörg Widmer, Martin Mauve, Hannes Hartenstein, and Holger Füßler. Position-basedrouting in ad-hoc wireless networks. In Mohammad Ilyas, editor, The Handbook of AdHoc Wireless Networks, chapter 12. CRC Press, 2002.

109

Geographic Routing using a Cell Structure in Wireless Ad-hoc Networks

Documents

Transcript of Geographic Routing using a Cell Structure in Wireless Ad-hoc Networks