Pontificia Universidad Javeriana
Facultad de Ingeniería electrónica
Proyecto final de carrera
TÍTULO:
Evaluación de los protocolos de enrutamiento AODV y OLSR en redes VANET
AUTOR:
Santiago Chirinos Cadavid
DIRECTOR:
Luis Carlos Trujillo Arboleda
i
ii
Así que no temas, porque yo estoy contigo; no te angusties, porque yo soy tu Dios. Te fortaleceré y te ayudaré; te sostendré con mi diestra victoriosa. Todos los que se enardecen contra ti sin duda serán avergonzados y humillados; los que se oponen serán como nada, como si no existieran. Aunque busques a tus enemigos, no los encontrarás. Los que te hacen la guerra serán como nada, como si no existieran. Porque yo soy el SEÑOR, tu Dios, que sostiene tu mano derecha; yo soy quien te dice “No temas, yo te ayudaré” Isaías 41:10-1.
AGRADECIMIENTOS
En primer lugar agradecer al Dios omnipresente por darme la oportunidad de existir y de permitirme desarrollar mi vocación hacia las comunicaciones siendo en todo momento mi pan, mi luz y mi oración.
A mis padres porque siempre creyeron en mí, dándome ejemplos dignos de perseverancia y lucha. Gracias a ellos hoy puedo ver alcanzada una meta más: ser profesional; junto con mis hermanos quienes han sido mis guías y modelos, estuvieron siempre impulsándome tanto en momentos difíciles de mi carrera como felicitándome en momentos satisfactorios. Debido a ese orgullo que sienten por mí pude llegar hasta el final. Esto es por ellos, por lo que son, por lo que valen porque admiro su fortaleza y toda una vida de dedicación y por lo que han hecho de mí puedo decir: familia han cumplido su tarea con creces. A mis tías y primos gracias por haber fomentado en mí el deseo de superación y el anhelo de triunfo en la vida.
También quiero agradecer al director de este proyecto, el Ing. Luis Carlos Trujillo Arboleda, por darme la oportunidad de realizarlo, por su paciencia, disposición y su efectivo conocimiento prestado en todo momento ya que sin ello este trabajo de grado no hubiera sido posible.
A todos mis compañeros de la Pontificia Universidad Javeriana con los que he pasado tantos momentos durante estos años de universidad muchas gracias, y a mis amigos de toda la vida por estar ahí en los momentos de ocio tan necesarios para llevar a cabo esta carrera y un proyecto como éste.
iii
Tabla de contenido
1. INTRODUCCIÓN ... 1
2. OBJETIVOS ... 3
2.1 General ... 3
2.2 Específicos ... 3
3. INTRODUCCIÓN A LAS REDES AD HOC ... 4
3.1 ¿Qué son las redes ad hoc? ... 4
4. INTRODUCCIÓN A LAS REDES VANET ... 5
4.1 ¿Qué es una red VANET? ... 5
4.2 Características de una red VANET ... 5
4.3 Aplicaciones de las redes VANET ... 6
4.3.1 Vehicle-to-Vehicle Services (V2V) ... 6
4.3.2 Vehicle-to-Infrastructure Services ... 7
4.3.3 Portal Based Services ... 8
5. MODELO DE MOVILIDAD ... 9
5.1 Concepto de modelo de movilidad ... 9
5.2 Topología del modelo de movilidad ... 10
5.3 Modelo de movilidad Manhattan ... 13
6. HERRAMIENTAS DE SIMULACIÓN ... 15
6.1 Simulation for Urban Mobility (SUMO) ... 15
6.1.1 ¿Por qué SUMO? ... 16
6.1.2 Características ... 16
6.2 Network Simulator 2 (NS2) ... 18
6.2.1 ¿Por qué NS2? ... 18
6.2.2 Características ... 18
6.3 MObility model generator for VEhicular networks (MOVE) ... 20
6.3.1 ¿Por qué MOVE? ... 20
6.3.2 Características ... 21
6.4 Tracegraph y scripts ... 22
7. PROTOCOLOS DE ENRUTAMIENTO ... 23
7.1 Ad hoc On-demand Distance Vector (AODV) ... 24
7.1.1 Funcionamiento general [22] [39] ... 24
7.1.2 Estructura de datos o trama ... 26
iv
7.2.1 Funcionamiento general [22] [39] ... 28
7.2.2 Estructura de datos o trama ... 30
8. PARÁMETROS DE EVALUACIÓN ... 32
8.1 Parámetros de rendimiento ... 32
9. PROCESO DE SIMULACIÓN ... 34
9.1 Casos a evaluar ... 35
9.2 Estándar IEEE 802.11: capa física y enlace de datos [29] ... 37
9.3 Modelo de radiopropagación [39] ... 37
9.4 Protocolos de transporte [40] ... 38
9.5 Parámetros de la simulación ... 39
10. EVALUACIÓN DEL PROCESO DE SIMULACIÓN ... 41
11. RESULTADOS ... 46
12. CONCLUSIONES ... 50
13. BIBLIOGRAFÍA ... 51
v
Índice de ilustraciones
Ilustración 1 Red ad hoc ... 4
Ilustración 2 Escenario urbano de red VANET ... 5
Ilustración 3 Logotipo del consorcio C2CCC ... 6
Ilustración 4 Características básicas de una OBU ... 7
Ilustración 5 Patrón básico de radiación de una OBU ... 7
Ilustración 6 Logotipo del CVIS ... 7
Ilustración 7 Logotipo del consorcio GST ... 8
Ilustración 8 Variables de un modelo de movilidad real ... 9
Ilustración 9 Variables más relevantes de un modelo de movilidad ... 9
Ilustración 10 Próximo estado de un vehículo ... 10
Ilustración 11 Topología del escenario urbano ... 11
Ilustración 12 Porción del centro de Bogotá D.C. ... 12
Ilustración 13 Modelo de movilidad Manhattan ... 13
Ilustración 14 Definición del modelo de movilidad Manhattan... 14
Ilustración 15 Simulación microscópica de SUMO ... 16
Ilustración 16 Logotipo de SUMO y de la agencia nacional aeroespacial alemana ... 16
Ilustración 17 Proceso de simulación utilizando SUMO... 18
Ilustración 18 Integración de NS2 y NAM ... 19
Ilustración 19 Herramienta Network Animator, NAM ... 19
Ilustración 20 Interfaz gráfica de MOVE ... 21
Ilustración 21 Arquitectura de MOVE ... 21
Ilustración 22 Herramienta tracegraph ... 22
Ilustración 23 Protocolos proactivos ... 23
Ilustración 24 Protocolos reactivos ... 24
Ilustración 25 (a) Ruta inversa (b) Ruta directa ... 25
Ilustración 26 Representación del protocolo reactivo AODV ... 25
Ilustración 27 Inundación tradicional vs inundación optimizada... 29
Ilustración 28 Ejemplo de OLSR ... 29
Ilustración 29 Continuación del ejemplo de OLSR ... 30
Ilustración 30 Diagrama de flujo del proceso de simulación ... 35
Ilustración 31 Representación simplificada del escenario urbano con Guisim ... 36
Ilustración 32 Representación gráfica de los vectores sobre una red de 25 nodos ... 41
vi
Índice de tablas
Tabla 1 Tráfico UDP en función del número de vehículos y el % de fuentes ... 36
Tabla 2 Tráfico TCP en función del número de vehículos y el % de fuentes ... 36
Tabla 3 Parámetros de la herramienta NS2 ... 39
Tabla 4 Protocolo AODV y OLSR: Porcentaje de éxito ... 46
Tabla 5 Protocolo AODV y OLSR: Retardo extremo a extremo. ... 46
Tabla 6 Protocolo AODV y OLSR: Throughput ... 47
Tabla 7 Protocolo AODV y OLSR: Overhead ... 47
Tabla 8 Protocolo AODV y OLSR: Porcentaje de éxito ... 48
Tabla 9 Protocolo AODV y OLSR: Retardo extremo a extremo ... 48
Tabla 10 Protocolo AODV y OLSR: Throughput ... 49
Tabla 11 Protocolo AODV y OLSR: Overhead. ... 49
1
1.
INTRODUCCIÓN
Durante la última década las redes inalámbricas han venido realizando una revolución en la forma en cómo las personas interactúan entre sí mediante el intercambio de algún tipo de datos, definiendo un nuevo paradigma: “siempre, en cualquier lugar, estar conectados” [1]. Dentro de este paradigma las comunicaciones en entornos vehiculares han abierto un novedoso campo de investigación en toda la comunidad científica y universitaria, que se encuentra en pleno desarrollo, dando como resultado hasta el momento soluciones diseñadas especialmente para este tipo de escenario.
Dentro del ámbito de las redes inalámbricas tipo MANET (Mobile Ad hoc Network) se encuentra un tipo de red denominada VANET o Vehicular Ad hoc NETwork. Esta se define como una red ad hoc móvil independiente de infraestructura donde sus nodos tienen correspondencia con vehículos y estos a su vez están en constante movimiento con las dificultades intrínsecas que esto supone [2].
Los continuos e impredecibles cambios en la topología de red como consecuencia de la movilidad de sus nodos, hacen de la red VANET su principal reto, es por esto la importancia en la utilización de protocolos de enrutamiento eficientes que permitan superar este problema.
Hace unos años se estaban evaluando entre la comunidad investigadora cerca de 60 propuestas diferentes de enrutamiento para redes VANET [3]. Sin embargo, solamente las siguientes cuatro propuestas han resistido la fuerte competencia: el protocolo “Ad hoc On demand Distance Vector”
(AODV) [4], el protocolo “Dynamic Source Routing for Protocol Mobile Ad hoc Networks” (DSR)
[5], el protocolo “Optimized Link State Routing” (OLSR) [6], y el protocolo “Topology Broadcast
based on Reverse-Path Forwarding” (TBRPF) [7]. De estos cuatro, los protocolos AODV y OLSR han alcanzado el nivel de RFC (Request for Comment). Estas RFC son avaladas por la IETF (Internet Engineering Task Force), organización mundialmente conocida por ser la entidad que regula las propuestas y los estándares de Internet. Por ello en este proyecto, se describen los aspectos más relevantes relacionados con las características y funcionamiento de estos dos protocolos, sometiéndolos a la simulación y estableciendo una comparativa de rendimiento bajo un escenario común.
Con este propósito el trabajo se ha estructurado en una primera parte de conceptualización, en donde el capítulo 3 y 4 especifican las definiciones y aplicaciones más importantes sobre las redes ad hoc y VANET. Seguidamente se describe, en el capítulo 5, el modelo de movilidad utilizado en la simulación el cual es una parte importante para el diseño de este tipo de redes. El objetivo de este capítulo es definir un modelo de movilidad que permita establecer un entorno urbano ideal para la evaluación de los protocolos de enrutamiento Ad hoc On-demand Distance Vector (AODV) y Optimized Link State Routing (OLSR).
2
A continuación, el capítulo 7, explica los protocolos de enrutamiento AODV y OLSR utilizados para llevar a cabo la comunicación entre los nodos y en el capítulo 8 se determinan los factores claves que inciden en la evaluación de los protocolos de enrutamiento en un entorno VANET, en este caso caracterizando sus parámetros más importantes. El capítulo 9 describe el proceso de simulación en donde se pone en contexto los casos a evaluar en la red VANET. Luego, el capítulo 10, presenta un método de evaluación para la simulación de acuerdo a los resultados teóricos esperados.
3
2.
OBJETIVOS
2.1
General
Evaluar el desempeño de los protocolos de enrutamiento AODV y OLSR en Vehicular Ad-Hoc Networks.
2.2
Específicos
Establecer un modelo de movilidad que permita definir un entorno urbano ideal para la evaluación de los protocolos.
Determinar los factores claves que inciden en el análisis y evaluación de los protocolos de enrutamiento en un entorno VANET, con el fin de caracterizar sus parámetros más importantes.
Implementar los protocolos de enrutamiento AODV y OLSR por medio de una herramienta de simulación de red.
4
3.
INTRODUCCIÓN A LAS REDES AD HOC
3.1
¿Qué son las redes ad hoc?
Una red ad hoc es un sistema autónomo de nodos móviles conectados mediante enlaces inalámbricos que no dependen de una infraestructura preexistente, desplegándose de una manera espontánea [8]. En consecuencia cada nodo opera como un enrutador para retransmitir los paquetes. Lo más interesante de este tipo de redes es la posibilidad de establecer una red entre dispositivos aislados sin la necesidad de tener estaciones base, routers fijos, etc. o tener un administrador del propio sistema porque las redes ad hoc son adaptativas y pueden autoconfigurarse [9].
Como se mencionó anteriormente en el escenario ad hoc algunos nodos también actuarán como enrutadores, esto con la finalidad de comunicar dos dispositivos que no se encuentran directamente conectados mediante su propio radio de cobertura de enlace, a lo que se denomina red inalámbrica multisalto, pudiendo existir centenares de nodos donde cada uno sería capaz de cubrir cierta distancia dependiendo del protocolo de capa Phy (Physical) y MAC (Medium Access Control) utilizado.
Ilustración 1 Red ad hoc [8]
Las redes ad hoc presentan topologías dinámicas donde los nodos se pueden desplazar en el espacio de manera arbitraria, teniendo como dificultad y reto la gran variabilidad y la imprecisión que ofrece el medio de propagación, en este caso, el aire (fading, jitter, atenuación, multicamino, ruido, etc.) obligando por tanto a este dinamismo frente a cambios repentinos e inesperados como enlaces bidireccionales o unidireccionales, restricción del throughput, caída y recuperación de ruta, etc.
5
4.
INTRODUCCIÓN A LAS REDES VANET
A continuación se profundizará en un tipo de red ad hoc denominada red VANET, objeto de estudio del proyecto.
4.1
¿Qué es una red VANET?
Una red VANET o Vehicular Ad hoc Network es un conjunto de nodos (vehículos) que se comunican entre sí mediante enlaces inalámbricos, sin la necesidad de una infraestructura de red fija [1]. Cada nodo actúa como un enrutador y va encaminando los distintos paquetes entre los diferentes terminales sin la necesidad de que exista un alcance directo entre la fuente y el destino. Para efectos de estudio de este tipo de redes el comportamiento del tráfico se realiza mediante un modelo de movilidad el cual establece la forma como los vehículos se desplazan de acuerdo a la topología.
Ilustración 2 Escenario urbano de red VANET [1]
Actualmente todo lo que envuelve el tema de las redes VANET está en pleno desarrollo e investigación. Algunos de los consorcios que exploran este tema son el VSC (USA), C2CCC (Europa), Internet ITS (Japón), Sigmobile (USA) [10] y el propio IEEE que conjuntamente con el European Car-to-Car Communication Consortium ha desarrollado el protocolo IEEE 802.11p visto como una adaptación del propio estándar IEEE 802.11 y equivalente al estándar DSRC o Dedicated Short Range Communication utilizado en Estados Unidos [11].
4.2
Características de una red VANET
Las principales características de una red VANET son [1]:
Autonomía: Cada nodo se considera autónomo por la capacidad de procesar la información que se intercambia en la red. El control de la red no depende de una infraestructura externa sino que se distribuye en todos sus nodos siendo más tolerante a fallos.
6
tanto, es necesario definir nuevos protocolos de enrutamiento capaces de soportar esta característica.
Topología de red variable: En una red MANET los nodos se pueden desplazar de manera arbitraria. Esa característica se debe matizar en el caso de las redes VANET ya que los vehículos suelen seguir cierto patrón de movimiento. Aun así, los vehículos se mueven de forma más rápida que un terminal en una red móvil clásica. Debido a esa variabilidad de posición se pueden producir pérdidas importantes de paquetes. Serán necesarios mecanismos que detecten estas circunstancias para minimizar sus efectos.
Capacidad variable de los enlaces: Esta característica tiene cabida en todas las comunicaciones inalámbricas porque es intrínseca al medio de transmisión pero sus efectos se agravan más en las redes VANET por la alta movilidad de sus nodos.
Terminales limitados: En la mayoría de los casos los nodos de este tipo de redes serán terminales ligeros instalados en los vehículos con capacidades limitadas de procesamiento y comunicación por lo que es primordial que los protocolos utilizados optimicen estos dos recursos.
4.3
Aplicaciones de las redes VANET
A continuación se presentan algunas de las aplicaciones más prometedoras de este tipo de redes mencionando también los grupos de trabajo vinculados a la investigación y desarrollo de estas [2].
4.3.1 Vehicle-to-Vehicle Services (V2V)
Este tipo de servicio es el más ligado a la seguridad. Tiene como finalidad prevenir accidentes, evitar colapsos, permitir la localización de vehículos, el intercambio de las condiciones de la carretera, mantener las distancias de seguridad de los vehículos [11].
Por otro lado, uno de los retos de esta tecnología y por lo tanto su estudio y desarrollo por parte del C2CCC (Car 2 Car Communication Consortium) es la de ofrecer un entorno escalable permitiendo comunicaciones a altas velocidades, ofreciendo seguridad y privacidad en las comunicaciones [12].
Este proyecto utiliza para efectos de la construcción del escenario de red VANET una aplicación V2V denominada Vehicle Tracking System (VETRAC) [13]. Consiste en la ubicación de un vehículo utilizando la red VANET. Al ser el GPS una tecnología de localización costosa en implementación, VETRAC, permite una solución más recursiva haciendo uso de la red vehicular. Un ejemplo de uso puede ser cuando un vehículo es hurtado y se quiere saber su ubicación para recuperarlo. Esta aplicación en este proyecto se utiliza sólo para definir el tamaño del paquete requerido para una comunicación de este tipo que en este caso es de 512 bytes según el artículo IEEE Location Identification and Vehicle Tracking using VANET (VETRAC) [13].
7
Los vehículos llevan instalado un dispositivo llamado OBU (On Board Unit) el cual se puede alimentar directamente de la batería del vehículo o de una batería interna del equipo. A continuación se muestra un esquema de las características básicas de la unidad y su patrón de radiación ideal [14]:
Ilustración 4 Características básicas de una OBU [14]
Ilustración 5 Patrón básico de radiación de una OBU[14]
4.3.2 Vehicle-to-Infrastructure Services
Este servicio está pensado como refuerzo del anterior, aparte de ofrecer un intercambio exclusivo de datos entre vehículos la idea es introducir una serie de estaciones base que puedan ofrecer por ejemplo la información climatológica de una fuente externa o la información del tráfico, entre otros. A parte de poder extender el radio de amplitud de la red ad hoc formada cuenta con la posibilidad de poder enviar a un servicio de emergencia un mensaje de auxilio ya que cabría la posibilidad que en esa parte de la carretera no hubiera más vehículos en ese momento. Actualmente el grupo de trabajo que profundiza en su estudio y sus posibles aplicaciones es el CVIS o Cooperative Vehicle-Infrastructure Systems [15].
8
4.3.3 Portal Based Services
Éste es quizá el servicio con más expectativas en el futuro dentro de las redes VANET en el contexto del ocio y empresarial.
Este sistema consiste en ofrecer a los vehículos servicios basados en infraestructura bajo una plataforma de servicios telemáticos, como podría ser una conexión a internet desde los vehículos, pagar por tiempo conducido por parte de las aseguradoras ofreciendo otro tipo de tarificación en el mercado, la creación de portales Web de las ciudades donde se podría consultar en tiempo real el estado de los puestos de estacionamiento, hoteles, restaurantes, entre otros. [11].
El principal grupo de trabajo que lidera el desarrollo y estudio de este tipo de servicio es el GST o Global System of Telematics [16], un consorcio formado entre 49 compañías de automóviles (BMW, Fiat, Audi, Renault, Volvo, entre otros.) que pretenden crear un estándar de facto [12].
9
5.
MODELO DE MOVILIDAD
5.1
Concepto de modelo de movilidad
Un modelo de movilidad se define como el patrón de movimiento que tienen los vehículos dentro de un escenario topológico específico. Uno de los retos para el estudio de las redes VANET es poder hacer un análisis de ellas haciendo uso de herramientas de simulación, se ha de tener presente que será muy difícil acercarse a la generación de modelos de movilidad realistas porque se está en un ambiente donde los nodos existentes se mueven con características arbitrarias y sus enlaces van cambiando de estado a través del tiempo dependiendo del entorno. En definitiva existe un gran número de variables al momento de implementar un modelo de movilidad real [17]. A continuación se muestra un diagrama de bloques de todas estas variables [18]:
Ilustración 8 Variables de un modelo de movilidad real [18]
Para simplificar, las variables más importantes a tener en cuenta y que definirán la simulación en mayor medida son la conjunción entre el comportamiento del conductor, el movimiento del vehículo, el estado de la comunicación inalámbrica de cada enlace existente todo esto relacionado al tipo de aplicación que se está usando. [18].
Ilustración 9 Variables más relevantes de un modelo de movilidad [18]
Application Behavior
Wireless Communicati
on Network
Vehicle Movement Driver
10
El movimiento de los vehículos se realiza mediante un simulador de tráfico microscópico. Un simulador de red permitirá establecer la comunicación inalámbrica implementando el modelo de radiopropagación, las características de acceso del canal, la corrección de errores, el enrutamiento, entre otros. La aplicación hace referencia al contexto en que se va a utilizar la red VANET y el comportamiento del conductor consiste en las decisiones que él toma para llegar al destino basado en el tráfico vehicular y otros agentes externos.
En teoría para modelar el movimiento de un vehículo, o bien su próximo estado, se deben tener en cuenta los siguientes factores:
Ilustración 10 Próximo estado de un vehículo [18]
Este tipo de modelo en general se denomina Car Following Models (CFMs). Se caracteriza por adaptar la dinámica de un vehículo de acuerdo a una regla definida con el fin de prevenir cualquier contacto con otro. Cada conductor debe tener la capacidad de percibir o detectar los cambios que hacen los diferentes vehículos presentes en la vía para de esta manera tomar una decisión, realizando acciones que afectan la dinámica del auto con el fin de evitar una colisión. La regla de este modelo se llama
“Pipe´s Rule” [18] y consiste en tener una distancia de seguridad mínima entre dos vehículos de por lo menos la longitud de un auto por cada 16 km/h de velocidad. Dentro de la categoría de CFMs se
encuentra el modelo “Krauss Model” [18] del cual hace uso por defecto la herramienta de simulación de tráfico SUMO utilizada en este proyecto y descrita más adelante.
5.2
Topología del modelo de movilidad
11
Ilustración 11 Topología del escenario urbano
Cabe anotar de la ilustración anterior que al ser un escenario urbano ideal se restringe el efecto de la radiopropagación a un ambiente sin pérdidas, por lo tanto, en cada cuadro blanco no existen edificios y como se mencionará más adelante los vehículos tienen línea de vista. Esta decisión se tomó teniendo en cuenta que al incluir los efectos de la radiopropagación se hace necesario hacer un análisis profundo del comportamiento y la afectación de este en la comunicación, además, de un modelamiento de las estructuras físicas alrededor de las calles lo cual desenfoca los objetivos cuyo centro son la evaluación de los protocolos de enrutamiento AODV y OLSR en un entorno urbano ideal. Por lo tanto algún modelo de radiopropagación distinto al ideal está fuera del alcance de este proyecto
12
Ilustración 12 Porción del centro de Bogotá D.C.
Otra razón por la cual se escoge esta topología son los diferentes artículos IEEE que hacen referencia a este escenario para la simulación de redes VANET como lo son: CityMob: a mobility model pattern generator for VANET`s [19] y Study of the Feasibility of VANET [20] and it`s Routing Protocols. Este tipo de artículos reflejan el buen comportamiento de esta topología al utilizarla en entornos de simulaciones urbanas los cuales dan la posibilidad de realizar comparaciones de protocolos de enrutamiento más confiables y equitativos una vez obtenidos los resultados.
13
5.3
Modelo de movilidad Manhattan
El modelo de movilidad seleccionado para la implementación de los protocolos de enrutamiento es el Manhattan [21]. Se caracteriza por restringir el movimiento de los vehículos por una topología con estructura de malla, haciéndolos circular por las rectas predefinidas para cada caso. El nombre de este modelo es muy intuitivo de identificar ya que simula ser un escenario como el que puede darse en ciudades como Manhattan o el Eixample de Barcelona. El área de simulación forma parte de una sección o zona centro de una ciudad.
Las razones por las cuales se escoge este modelo de movilidad son en primer lugar su simplicidad al momento de simular y en segundo lugar porque es adecuado para la topología ya que tiene en cuenta en cada intersección una probabilidad de giro. Sus principales características son [22]:
Es un modelo microscópico porque se enfoca en la descripción del flujo vehicular a través de entidades discretas individuales y atómicas que interactúan unas con otras. Por la razón anterior también se le considera como un modelo discreto. Por lo general tienen en cuenta una gran cantidad de variables para de esta forma asemejarlo más a la realidad, por lo tanto, se le categoriza como un modelo granular. La velocidad adoptada por los vehículos puede ser aleatoria o predeterminada por el usuario.
Es un modelo estocástico porque considera en cada intersección una probabilidad de giro cuyo resultado cambia con el tiempo. Cuando un vehículo llega a una intersección ya sea que esta cuente con semáforo o no tiene un 50% de probabilidad de seguir en la misma dirección (en línea recta), 25% de girar a la derecha y por ende 25% de girar a la izquierda.
14
Ilustración 14 Definición del modelo de movilidad Manhattan [22]
Para describir la próxima característica se debe tener en cuenta la ilustración 14: en un tiempo t, � � y � � representan respectivamente la posición y la velocidad del vehículo i. Los índices i + 1 y i – 1 representan respectivamente el vehículo inmediatamente en frente y detrás del vehículo i con posiciones �+ � y �− � , y con velocidad �+ � y �− � . La distancia bumper-to-bumper entre el vehículo i y i + 1 en el instante t se representa por ∆� � . Los índices j + 1 y j –1 representan vehículos en la calle adyacente en frente o detrás del vehículo i. Sus posiciones en un instante t son
�+ � y �− � , mientras que su velocidad en el mismo instante son �+ � y �− � . Si se
considera la aceleración instantánea para un vehículo i en un instante t se denota como � .
Este modelo cuenta con dos importantes premisas que son: (a) la velocidad de cada vehículo es temporalmente dependiente de su velocidad previa y (b) la velocidad del vehículo i no puede exceder la velocidad del vehículo i+1. En forma de ecuación se tiene:
(a) � � + ∆� = � � + � ∗ ∗ ∆ � donde � es el tiempo de reacción del conductor en segundos y
(b) Si ∆� � > ∆�sa entonces � � ≤ �+ � ∀� donde ∆�sa es la distancia mínima de seguridad en metros entre dos vehículos.
15
6.
HERRAMIENTAS DE SIMULACIÓN
Para la implementación de este proyecto se han seleccionado un conjunto de herramientas de libre distribución y de código abierto. Esta elección se ha hecho considerando la amplia aceptación que reciben entre los grupos de trabajo para el desarrollo de protocolos en redes MANET. El hecho de que un programa sea muy utilizado implica que ha pasado por varios procesos de evolución y validación permitiendo la continua mejora de sus características. Esto supone diversas ventajas como por ejemplo la disposición de numerosos protocolos preestablecidos, de documentación y de foros de usuarios. Entre las herramientas elegidas se encuentra el simulador de red NS2 (Network Simulator 2) [23], el cual, permite la simulación de los protocolos de enrutamiento AODV y OLSR estableciendo comunicaciones entre diferentes nodos de la red.
Junto al Network Simulator 2 se suele utilizar un animador gráfico de redes llamado NAM (Network Animator) [24] que no aporta datos cualitativos a la simulación pero es interesante en el momento de poder observar de manera visual el flujo de datos y los movimientos de los vehículos. Por ejemplo se puede detectar el momento donde ocurren pérdidas de paquetes en un envío de datos.
Para la creación de la topología y el modelo de movilidad de la red VANET se utilizan los programas SUMO (Simulation for Urban Mobility) [25] y MOVE (MObility model generator for VEhicular networks) [26].
A continuación se describen en mayor detalle cada una de las herramientas utilizadas.
6.1
Simulation for Urban Mobility (SUMO)
Esta herramienta permite la creación y visualización de topologías para entornos de redes VANET así como la generación de tráfico vehicular para el establecimiento del modelo de movilidad.
La definición formal de SUMO es la de un simulador de tráfico microscópico que trabaja en espacio continuo y en tiempo discreto, desarrollado en lenguaje C++ [2] [27].
16
Ilustración 15 Simulación microscópica de SUMO
SUMO trabaja en espacio continuo y tiempo discreto en el sentido en que en cualquier instante de tiempo la posición de cada vehículo está perfectamente definida. Por tanto, la simulación en su conjunto se utiliza en tiempo discreto.
6.1.1 ¿Por qué SUMO?
Una gran parte de la comunidad que han evaluado diferentes simuladores de tráfico coinciden en afirmar que SUMO es una herramienta que ofrece resultados óptimos para la evaluación de protocolos de ruteo [27] y además, es un programa de código abierto (mucha documentación, gratuito, etc.) frente a la mayoría de opciones existentes de pago. Como pasa en todo el software de licencia pública cada uno tiene la posibilidad de poner su grano de arena para ir mejorando y desarrollándolo aún más. SUMO ya se encuentra entre una de las principales herramientas por parte del sector científico. Este programa permite poner en funcionamiento y visualizar el modelo de movilidad de una manera relativamente sencilla a través de MOVE. Por ende, es aquí donde se tiene la posibilidad de ver el diagrama topológico descrito previamente en este proyecto. Estas razones hacen de SUMO la herramienta de simulación escogida.
6.1.2 Características
SUMO es un generador de tráfico vehicular desarrollado por la DLR o Deutsche Gesellschaft für Luft undRaumfahrt, el centro aeroespacial nacional alemán [2].
Ilustración 16 Logotipo de SUMO y de la agencia nacional aeroespacial alemana
17
Esta herramienta computa las rutas de los vehículos antes de realizar la simulación, una vez en ella, los vehículos llegan al destino predeterminado por el usuario o configurado aleatoriamente. Cabe destacar que en un escenario donde actuase un número elevado de vehículos (unos pocos miles de vehículos) esto podría causar congestión de tráfico en las calles arteriales del mapa digital utilizado. Para evitar
esto, se utiliza un algoritmo denominado “dynamic user assignment” desarrollado por Christian
Gawron [28]. Al tener preestablecidas las rutas de cada vehículo antes de la simulación sin la utilización de ningún tipo de compresión, se necesita un gran uso de memoria del sistema, cosa que se agrava bastante en escenarios donde interviene un gran número de vehículos. Este es uno de los aspectos que se están mejorando.
SUMO es una aplicación que se ofrece en paquete, así que se puede bien hablar de una compilación de pequeñas aplicaciones cada una con un propósito claramente definido y que la suma de sus funciones permite crear, gestionar y explotar complejas redes de vehículos. A continuación se citan los principales programas que incluye el paquete [29]:
Netconvert: Se encarga de hacer la conversión de los archivos importados de otras herramientas como OpenStreetMap y de generar redes a partir de archivos de nodos y ejes definidos previamente.
Netgen: Generador de redes aleatorias. SUMO permite crear 3 tipos de redes con características aleatorias: redes con forma de parrilla, redes con forma de tela de araña y redes totalmente aleatorias.
Duarouter: Este programa permite definir las rutas que seguirán los vehículos mediante flujos. De este modo, se definen varios grupos de vehículos con un origen y un destino común, así como las características de la velocidad y el tiempo de salida.
Jtrrouter: Este genera las rutas de forma aleatoria mediante un parámetro R acotado entre 0 y 1. Da la posibilidad de establecer probabilidad de giro en una intersección.
Dfrouter: Se trata de otra herramienta de generación de rutas de vehículos donde se indican características como el identificador, tiempo de salida, origen, destino, tipo de vehículo, etc. que se aplicarán a la totalidad de los vehículos del tipo definido.
SUMO: Es el simulador en sí mismo. Una vez se hayan usado las otras aplicaciones y se tenga disponible un escenario, definidos los vehículos y sus rutas se puede simular con SUMO y estudiar los resultados.
Guisim: Es una aplicación que permite visualizar los escenarios creados. Permite ver los movimientos de los vehículos, detener la simulación en cualquier instante, centrarse en un punto concreto de la red y ampliarlo para estudiarlo de forma particular.
18
Ilustración 17 Proceso de simulación utilizando SUMO
Para una consulta más detallada de la herramienta SUMO se puede dirigir a la página web oficial del proyecto con todo tipo de documentación [25].
6.2 Network Simulator 2 (NS2)
Esta herramienta corresponde al simulador de red. Permite la obtención de resultados basándose fundamentalmente en el protocolo de enrutamiento y en el modelo de movilidad establecido.
6.2.1 ¿Por qué NS2?
NS2 es el corazón del proceso de simulación porque es en esta herramienta donde se integra todo un estudio y trabajo previo al cual se le añaden las últimas características tan importantes como los protocolos de enrutamiento. Probablemente se trata del simulador de red más extendido tanto en el ámbito de la investigación como para objetivos docentes [2]. Es un simulador en tiempo discreto cuya elaboración se inició en 1989 con el desarrollo de REAL Network Simulator. Una de las principales razones que lo hace tan popular es el hecho de que la distribución posee licencia GPL, condición que impulsa el libre desarrollo del mismo. Para el proyecto se escogió esta herramienta porque es de fácil instalación en el sistema operativo Ubuntu, es ampliamente utilizado con fines docentes, posee el código fuente del protocolo AODV y a través de un patch permite la instalación del código fuente del protocolo OLSR. Por último, tiene una buena compatibilidad de archivos con las herramientas SUMO y MOVE lo que lo hace más fácil de manejar.
6.2.2 Características
19
Uno de sus mejores aspectos es la gran funcionalidad pues resulta capaz de simular la inmensa mayoría de protocolos de comunicación existentes en diversos entornos (LAN o Local Area Network, entornos inalámbricos, comunicaciones satelitales, etc.), además, de poseer packs adicionales con nuevos protocolos que se incorporan gracias al desarrollo y soporte de la comunidad científica [22].
NS2 también integra las diferentes capas del modelo OSI (física, acceso al medio, enlace, red, transporte, aplicación) pudiendo modificar algunas características de cada una de ellas apoyándose en dos lenguajes de programación para su correcto funcionamiento. Por un lado, el usuario introduce las especificaciones del escenario a simular a través del lenguaje OTcl, versión extendida de tcl. Por otro lado, el desarrollo de los protocolos se escribe en C++ en caso de requerirse alguna modificación de los mismos.
Una de las herramientas complementarias de NS2 como se ha mencionado es NAM o Network Animator, basado en el lenguaje Tcl/Tk (Tool Command Language), desarrollado por Sun Microsystems cuya función no es otra que la de dar un aspecto gráfico y animar los escenarios emulados mediante NS2.
Ilustración 18 Integración de NS2 y NAM [22]
NS2 registra cada paquete de datos que atraviesa la red junto a sus características principales como por ejemplo, el instante de emisión, el número de secuencia, el tipo de paquete, entre otros. Estos forman un archivo o traza como resultado de todo el procedimiento en NS2.
20
6.3 MObility model generator for VEhicular networks (MOVE)
MOVE es una interfaz gráfica que funciona sobre el simulador de micro-tráfico SUMO. Consta de dos componentes principales: un editor de mapas y un editor de tráfico de vehículos [29].
El editor de mapas se usa para generar la topología de la red. Esta puede ser implementada de tres formas distintas: creada manualmente por el usuario, generada automáticamente o importada a partir de mapas reales. El editor de tráfico de vehículos permite al usuario definir uno o varios destinos dentro del mapa mediante flujos haciendo uso del modelo de movilidad. MOVE finalmente genera un fichero de traza .tcl, que puede ser tratado por un programa de simulación de redes como NS2.
6.3.1 ¿Por qué MOVE?
Se ha optado por MOVE debido a que ofrece la comunicación entre NS2 y SUMO de una manera sencilla e integral, además, se implica directamente en la simulación y automatiza mediante su interfaz gráfica algunos de los procesos necesarios para generar la simulación, como son la configuración de rutas, tipos de vehículos, probabilidad de giro, entre otros, que ahorran al usuario realizar códigos de programación.
21
Ilustración 20 Interfaz gráfica de MOVE [29]
6.3.2 Características
Entre sus características principales destaca la posibilidad de importar mapas reales a través de OpenStreetMap, configurar los movimientos de los vehículos, velocidades, número de vehículos, capacidad de tráfico y prioridad del mismo para cada calle, etc. [2].
Ilustración 21 Arquitectura de MOVE [2]
22
6.4 Tracegraph y scripts
Las trazas generadas por NS2 proporcionan toda la información sobre la simulación pero su extenso formato dificulta la extracción de resultados de forma manual. Por esto se utilizan programas capaces de obtener los principales parámetros de rendimiento de red tales como el porcentaje de éxito, retardo, throughput, overhead para mostrarlos de forma gráfica. TraceGraph [30] es una herramienta de código libre que permite convertir trazas NS2 en gráficas 2D y/o 3D. Sin embargo, cuando los ficheros son de gran tamaño (unas cuantas gigas) tracegraph solicita a la máquina más recursos de los que podría ofrecer. Por esta razón se descarta esta herramienta para este proyecto. Como solución a este problema se utilizan cuatro scripts para determinar los resultados de cada parámetro (definidos posteriormente) y a partir de allí comenzar la pertinente evaluación de los protocolos de enrutamiento AODV y OLSR.
23
7.
PROTOCOLOS DE ENRUTAMIENTO
En las redes VANET el enrutamiento de paquetes entre cualquier par de nodos llega a convertirse en una tarea comprometedora por el constante dinamismo de los nodos dentro de la red. Un camino que se consideraba óptimo en un punto dado del tiempo podría no funcionar en absoluto en unos pocos segundos después. Como consecuencia, una característica especialmente importante de los protocolos de encaminamiento para redes ad hoc es poder adaptarse rápidamente a los cambios continuos de la red con el fin de mantener las rutas entre los nodos que se están comunicando.
En relación a las redes cableadas, las redes ad hoc presentan cambios de topología frecuentes e impredecibles debido a la movilidad de sus estaciones. Estas características impiden la utilización de protocolos de encaminamiento desarrollados para redes cableadas.
De manera general, los protocolos de encaminamiento para redes ad hoc se clasifican en dos categorías principales [22]: proactivos y reactivos, aunque también existen otras clasificaciones [31].
En los protocolos proactivos, periódicamente se envía información de enrutamiento para que en cualquier momento cualquier nodo pueda comunicarse con cualquier otro de la red. Esta característica proporciona una respuesta rápida y eficaz ante solicitudes de ruta y ofrece un buen comportamiento en situaciones donde la tasa de movilidad es alta. Sin embargo, la sobrecarga que se introduce en la red con información de control es alta. El protocolo proactivo escogido para el proyecto es el Optimized Link-State Routing (OLSR).
Ilustración 23 Protocolos proactivos [22]
En los protocolos reactivos sólo se crean rutas cuando es necesario. Son protocolos bajo demanda donde la sobrecarga es mucho menor, pero los retrasos para establecer rutas son más altos. El protocolo reactivo escogido para el proyecto es el Ad hoc On-Demand Distance Vector (AODV).
24
Ilustración 24 Protocolos reactivos [22]
7.1 Ad hoc On-demand Distance Vector (AODV)
Ad hoc On-demand Distance Vector está descrito en la RFC 3561 [32]. Es un protocolo reactivo construido para mejorar el rendimiento del protocolo Destination Sequenced Distance Vector (DSDV), en el cual, la ruta es creada justo en el momento en que es necesaria. Sólo se establece una única ruta entre emisor y receptor por lo tanto se dice que no es un protocolo multipath. Al ser un protocolo de vector distancia su métrica es el número de saltos. El algoritmo que utiliza este protocolo para calcular la mejor ruta es el Bellman-Ford.
AODV minimiza el número de paquetes broadcast requeridos para crear rutas, ya que al ser bajo demanda, los nodos que están en el camino de la comunicación no tienen que previamente tener establecida su tabla de enrutamiento para encontrar una ruta [31]. A pesar de ser un protocolo reactivo, AODV tiene la característica de emitir mensajes alertando sobre su presencia de forma periódica mediante una técnica llamada Link Layer Feedback. Esa técnica permite que los nodos una vez creada la ruta tengan conocimiento de sus vecinos más cercanos y mantengan sus tablas actualizadas reflejando los cambios en la topología cercana [3].
7.1.1 Funcionamiento general [22] [39]
25
Ilustración 25 (a) Ruta inversa (b) Ruta directa [22]
Cuando el mensaje llega a un nodo que dispone de la ruta hacia D, se comprueba el número de secuencia para el destino D. Si éste es mayor que el incluido en el mensaje, se ha encontrado una ruta válida hacia D. El nodo que dispone de la entrada hacia D manda un mensaje de respuesta, ROUTE REPLY (RREP) de vuelta hacia S siguiendo la ruta creada durante la inundación y un ROUTE REPLY ACKNOWLEDGEMENT (RREP-ACK) debe ser enviado por S como respuesta y establecimiento. En este mensaje se incluye el último número de secuencia recibido por el emisor del mensaje RREP. Los nodos que reciben el RREP guardan una entrada hacia D que apunta al nodo que les ha transmitido el mensaje, por lo cual solo se guarda en la tabla el siguiente salto y no la ruta entera. Si pasado un cierto tiempo no se ha recibido ningún RREP, S considera que no hay ruta válida hacia D en ese momento. Una representación del proceso de establecimiento de una ruta se muestra a continuación:
Ilustración 26 Representación del protocolo reactivo AODV [22]
Las tablas se mantienen actualizadas mientras esté en uso el enlace. Si un nodo origen se mueve, él mismo reinicia el proceso de descubrimiento de rutas. Si un nodo intermediario se mueve, su vecino anterior (en el sentido directo origen-destino) propaga hasta S, un RREP no solicitado con un número de secuencia mayor y con valor de saltos al destino infinitos. De esa manera, S sabe que si quiere seguir usando el mismo enlace tiene que iniciar de nuevo el proceso de descubrimiento de ruta. Cuando un nodo se torna inalcanzable debido a por ejemplo la ruptura del enlace, se genera un ROUTE ERROR (RERR).
26
solicitados, cuyo número de secuencia es igual al del último RREP enviado y con un TTL = 1 para no inundar la red sino informar sólo el vecindario. Cuando durante más de tres segundos no se ha recibido ningún HELLO de parte de un vecino se considera el enlace roto y se borra la entrada correspondiente en la tabla de enrutamiento correspondiente. En la especificación de AODV se sugiere la posibilidad de utilizar datos de la capa de enlace o física para determinar el estado de los enlaces, como puede ser por ejemplo escuchar las retransmisiones realizadas por los nodos vecinos. Cada vez que se borra una entrada por rotura del enlace se debe indicar a los nodos que lo usaban como siguiente salto hacia una ruta que deben reanudar el proceso de descubrimiento de rutas. Esto se consigue mediante el UNSOLICITED ROUTE REPLY que contiene un valor infinito como distancia hacia el destino y un número de secuencia igual al del último RREP enviado.
7.1.2 Estructura de datos o trama
Los campos más relevantes de los paquetes utilizados en este protocolo son los siguientes [32]:
Route Request (RREQ)
Type 1
RREQ ID
Número de secuencia único que identifica un RREQ particular cuando es utilizado en conjunto con la dirección IP del nodo origen.
Destination IP Address Dirección IP del nodo destino.
Destination Sequence Number
Último número de secuencia recibido en el pasado por el origen para cualquier ruta hacia el destino.
Originator IP Address Dirección IP del nodo que origina el Route Request.
Originator Sequence Number
27 Route Reply (RREP)
Type 2
A Determina si el link por el cual se envía el paquete es inalcanzable o unidireccional.
Prefix Size
Si no es cero, el tamaño de 5 bits del prefijo especifica el siguiente salto, indicando que puede ser utilizado el mismo por todos los nodos.
Destination IP Address Dirección IP del destino.
Destination Sequence Number Número de secuencia destino asociado a la ruta.
Originator IP Address Dirección IP origen.
Lifetime Tiempo en milisegundos donde los nodos que reciben el RREP consideran la ruta válida.
28
Type 3
N Cuando un nodo ha realizado una reparación local del enlace estos no borran la ruta.
DestCount Número de destinos inalcanzables incluidos en el mensaje. Debe ser al menos de 1.
Unreachable Destination IP Address
Dirección IP del nodo destino que ha sido inalcanzable debido a la ruptura del enlace.
Unreachable Destination Sequence Number
Número de secuencia en la entrada de la tabla de rutas para un destino listado en el campo previo Unreachable Destination IP Address.
Route Reply Acknowledgement (RREP-ACK)
Type 4
Reserved Enviado como 0. Ignorado en la recepción.
Para obtener información más detallada sobre el funcionamiento y el significado de la estructura de los mensajes del protocolo de enrutamiento AODV dirigirse a la RFC 3561 [31].
7.2 Optimized Link State Routing (OLSR)
Optimized Link State Routing está descrito en la RFC 3626 [33]. Es un protocolo de enrutamiento proactivo basado en el algoritmo de estado-enlace (Link State Algorithm, LSA) conocido como Dijkstra donde su métrica es el costo del enlace. Este costo está definido por el ancho de banda del enlace inalámbrico.
7.2.1 Funcionamiento general [22] [39]
29
Ilustración 27 Inundación tradicional vs inundación optimizada [22]
Existen diferentes maneras de escoger los multipoint relays de un nodo pero independientemente de la forma de elección, el conjunto de MPR`s de un nodo debe verificar que son capaces de alcanzar a todos los vecinos situados a una distancia de 2 saltos del nodo que los calcula. Esto se conoce como el criterio de cobertura de MPR. Los nodos intercambian periódicamente mensajes HELLO con sus vecinos permitiendo detectar la presencia de un nodo vecino recogiendo información relativa al estado del enlace con dicho vecino. En los mensajes HELLO se puede incluir información indicando que el nodo es un nodo MPR. Utilizando esa información cada nodo elige dentro de su conjunto de vecinos un subconjunto el cual se denomina subconjunto MPR. Así, cada nodo tiene conocimiento de un subconjunto de nodos MPR que le permite tener conectividad con todos los nodos distantes de uno o dos saltos.
Ilustración 28 Ejemplo de OLSR [22]
En el ejemplo anterior, los mensajes de HELLO son usados para establecer los vecinos, determinar el estado del enlace y calcular (y notificar) los MPR`s. Los MPR`s están encerrados en llaves.
30
Ilustración 29 Continuación del ejemplo de OLSR [22]
Incluir en las tablas de enrutamiento sólo los enlaces a los nodos MPR reduce el tamaño de las mismas, lo que a su vez permite disminuir el ancho de banda consumido durante su intercambio. Al mismo tiempo posibilita que las rutas que se vayan creando a posteriori sean óptimas en cuanto al número de saltos ya que sólo usan los nodos MPR. OLSR se adapta bien a redes con un gran número de nodos y a una alta movilidad [3].
7.2.2 Estructura de datos o trama
El formato básico de cualquier paquete utilizado en OLSR omitiendo la cabecera IP y UDP es el siguiente [33]:
31
Packet Lenght Tamaño del paquete en bytes
Packet Sequence Number Son usados con el propósito de evitar bucles evitando la recepción de mensajes fuera de orden.
Vtime Indica por cuánto tiempo más un nodo luego de la recepción del mensaje debe considerar su información como válida.
Originator Address Contiene la dirección del nodo original. Este campo nunca cambia en las retransmisiones.
Time To Live Contiene el máximo número de saltos que un paquete puede recorrer al ser transmitido antes de ser descartado.
Hop Count Cuenta el número de saltos por lo que un paquete ha pasado al ser transmitido. Se va incrementando en uno cada vez que pasa por un nodo.
Message Sequence Number Mientras se está generando el mensaje, el nodo origen asigna un número de identificación único a cada uno de ellos. Es incrementado cada vez en uno por mensaje originado.
32
8.
PARÁMETROS DE EVALUACIÓN
Este capítulo presenta los parámetros considerados para evaluar el rendimiento de los protocolos de enrutamiento AODV y OLSR. La elección se realizó luego de analizar diferentes artículos IEEE como el Performance Evaluation of ad hoc On Demand Distance Vector in Manets with Varying Network Size Using NS2 Simulation [34] y el Performance Comparison of AODV and OLSR in VANETs Urban Environments Under Realistic Mobility Patterns [35], en los cuales se proponen varios parámetros para evaluar el rendimiento de los protocolos de enrutamiento.
8.1 Parámetros de rendimiento
Cuando se trabaja con redes es de suma importancia conocer la manera como se comunican los nodos y la forma como se envían y tratan los datos, para realizar un análisis que permita determinar no sólo la calidad del enlace sino también la efectividad del protocolo de enrutamiento utilizado. Para esto es necesario analizar el comportamiento de la red estimando su rendimiento, debido a que una red mal configurada o con un pobre desempeño puede ocasionar grandes pérdidas de tiempo, bajas en la productividad, etc. mucho más en sistemas de comunicación de gran tamaño.
El tipo de aplicación sobre la cual está funcionando un protocolo de enrutamiento es también un punto a tener en cuenta al momento de sacar conclusiones.
Para poder resolver los problemas que se puedan presentar en la red es necesario de alguna forma hacer un monitoreo para medir algunos parámetros que permitan detectar cualquier anomalía. Con las siguientes cuatro herramientas se puede hacer un diagnóstico acertado de cualquier tipo de eventualidad con el propósito de poder corregirla a tiempo. Los parámetros más comunes para chequear el comportamiento de una red son el throughput y el retardo que sufren los paquetes debido a las congestiones que pueden encontrar entre el origen y el destino, entre otros [36] [37] [38].
Sin embargo, los parámetros que evaluarán los protocolos de enrutamiento en este proyecto son: el porcentaje de éxito, el retardo extremo a extremo, el throughput y el overhead. A continuación se define y describe la importancia de cada uno de ellos:
8.1.1 Porcentaje de éxito
El porcentaje de éxito o Packet Delivery Fraction (pdfr) es el porcentaje de paquetes enviados desde el origen que llegan al destino. Un paquete enviado se puede perder bien porque el retardo de transmisión es tal que no llega a tiempo y se considera como perdido, o bien porque se ha dañado y los mecanismos de control del destino lo rechazan. El porcentaje de éxito es un buen indicador para obtener una comparativa relativa a las tasas de pérdidas de un protocolo. Un protocolo con tasas de pérdida altas no es satisfactorio ya que los rendimientos de red empeoran.
8.1.2 Retardo extremo a extremo
33
8.1.3 Throughput
Mide la cantidad de datos enviados al nodo destino, generalmente en paquetes por segundos o bits por segundo. Es también conocido por medir la tasa de transferencia de datos y se utiliza como medida de la eficiencia de la velocidad de transmisión que incluye el desempeño de los sistemas de transmisión y del protocolo mismo.
8.1.4 Overhead
Son los paquetes de control generados por cada protocolo para su funcionamiento. Es normal que un protocolo introduzca overhead al ser un mecanismo de control. Sin embargo, un protocolo que introduce una sobrecarga excesiva para la búsqueda o mantenimiento de ruta influye de forma muy negativa sobre el rendimiento de la red, ya que para mandar un paquete de datos útil se tendrá que mandar más paquetes de control, consumiendo precioso ancho de banda.
34
9.
PROCESO DE SIMULACIÓN
Los pasos para la realización de la simulación de redes VANET están definidos de manera general y se enumeran a continuación. Sin embargo, para lograr un mayor detalle en la descripción del proceso de simulación en el anexo 1 se encuentra el documento Metodología aplicada en el uso de las herramientas de simulación.
1. Generación de la topología o escenario con MOVE: Inicialmente se define la cuadrícula proporcionando las coordenadas como si de un plano cartesiano se tratara, señalando número de carriles, velocidad máxima en la calle, probabilidad de giro, entre otros. Posteriormente de tener los puntos en el plano cartesiano se procede a unirlos dando lugar a las calles.
2. Creación de los flujos de vehículos con MOVE: Se definen los movimientos o flujo del tráfico vehicular a través de las calles, especificando el punto de partida y destino, número de vehículos, velocidad máxima del vehículo y tiempo durante el cual transcurre la simulación.
3. Simulación de tráfico con SUMO: Consiste en ejecutar la simulación de tráfico vial con el mapa y unas condiciones de tráfico definidas. El simulador SUMO mostrará de forma gráfica el comportamiento de los vehículos de modo que se puede visualizar si corresponde con lo esperado. A la vez que se ejecuta la simulación se crea un fichero con las trazas de movimiento de los vehículos que será utilizado por el simulador de red NS2.
4. Simulación de red con NS2: Usando el patrón de movimiento creado en el paso anterior y utilizando MOVE, se definen las comunicaciones entre los diferentes vehículos de acuerdo al protocolo de transporte TCP y UDP. Como resultado se crea un archivo .tcl que también define la tecnología de radio, el tipo de antena, el modelo de propagación, el protocolo de enrutamiento, el protocolo de capa física, de acceso al medio y de transporte. Este archivo es ejecutado en la herramienta de simulación de red NS2 obteniendo dos trazas: una interpretable por el animador gráfico NAM y otra con las trazas en formato de archivo de texto plano para ser analizadas posteriormente.
5. Análisis de los resultados: Mediante cuatro sencillos scripts se procesa cada traza del punto anterior y se extraen los resultados numéricos teniendo en cuenta cada parámetro de evaluación. Al cabo de este paso se pretende concluir acerca del desempeño de los protocolos de enrutamiento AOVD y OLSR, objetivo general de este proyecto.
35
Ilustración 30 Diagrama de flujo del proceso de simulación [26]
A continuación se describen los casos a evaluar en cada simulación, una breve definición de los protocolos utilizados en la capa física, de acceso al medio y de transporte del modelo OSI (Open
System Interconnection), el modelo de radiopropagación y por último los parámetros utilizados en la
herramienta NS2. No existe una configuración referente a los anteriores de forma correcta o equivocada, sino que existen diferentes soluciones y posibilidades válidas dependientes de los rasgos a evaluar.
9.1 Casos a evaluar
El estudio de los protocolos de enrutamiento se realiza sobre un escenario urbano con las siguientes características:
48 manzanas 59 intersecciones 63 nodos
26 semáforos
220 calles de 100 metros cada una y de doble carril en ambos sentidos 4.800 metros cuadrados
36
Para la simulación se establecen densidades de tráfico de 100 y 150 vehículos respectivamente. Estos dos casos se subdividen en términos del número de nodos emitiendo: 50% y 100% y del tipo de protocolo de transporte: TCP y UDP.
Los casos a evaluar haciendo uso de la herramienta de simulación para la evaluación de cada protocolo son los siguientes:
Caso 1: Tráfico UDP en función del número de vehículos y el % de fuentes.
Número de vehículos % de fuentes
Caso 1.1 100 50 - 100
[image:43.595.102.551.123.345.2]Caso 1.2 150 50 - 100
Tabla 1 Tráfico UDP en función del número de vehículos y el % de fuentes
Caso 2: Tráfico TCP en función del número de vehículos y el % de fuentes.
Número de vehículos % de fuentes
Caso 2.1 100 50 - 100
Caso 2.2 150 50 - 100
Tabla 2 Tráfico TCP en función del número de vehículos y el % de fuentes
Para cada uno de los 8 casos anteriores se harán 3 simulaciones dejando como patrón el movimiento de los vehículos y generando comunicaciones o envío de datos entre nodos distintos. Los tres resultados permiten tener una estimación confiable del comportamiento debido a que se caracterizan por tener una proyección lineal ascendente, descendente o constante sin ningún punto de inflexión. Las simulaciones son ponderadas (promedio) para obtener un único resultado. Teniendo en cuenta esto, son un total mínimo de 48 simulaciones.
37
9.2 Estándar IEEE 802.11: capa física y enlace de datos [29]
802.11 es el estándar del IEEE (Institute of Electrical and Electronics Engineers) para redes inalámbricas, enviando paquetes de datos Ethernet a través del medio físico que en este caso es el aire. El estándar permite la integración inalámbrica con cableado IEEE 802.3, red Ethernet, usando dispositivos llamados puntos de acceso (Acces Point) o estaciones base. Esto significa que el estándar inalámbrico IEEE 802.11 soporta todos los estándares de protocolos de red Ethernet incluyendo TCP/IP, AppleTalk, NetBEUI e IPX. Este es el estándar sobre el que funciona NS2 para entornos inalámbricos. El estándar data de 1997, tiene velocidades de 1 hasta 2 Mbps y trabaja en la banda de frecuencia de 2,4 GHz.
Para minimizar los problemas del canal inalámbrico se envían dos tipos de tramas: ACK (Acknowledgment) y RTS/CTS (Request to Send/Clear to Send). La trama ACK es un reconocimiento positivo que se envía cuando la trama transmitida se ha recibido correctamente. De esta manera, si el emisor deja de recibir una trama ACK, puede detectar la pérdida de una trama. El envío de la trama ACK no puede ser interrumpido por la transmisión de datos de otra estación. La trama RTS tiene varios propósitos: además de reservar el radio enlace para transmisión, también silencia a las otras estaciones que la oigan. Si la estación destino recibe un RTS, esta responde con un CTS. Al igual que la trama RTS, la trama CTS silencia las estaciones en la inmediata vecindad. Una vez que el intercambio RTS/CTS esta completado, el nodo A puede transmitir sus tramas sin preocuparse de las interferencias producidas por nodos ocultos. Los nodos ocultos que se encuentren más allá de la zona de la estación emisora son silenciados por el CTS del receptor.
El control de acceso al medio inalámbrico se hace mediante dos funcionalidades básicas: el DCF (Distributed Coordination Function) y el PCF (Point Coordination Function) El DCF proporciona un acceso al medio basado en contienda y utiliza el mecanismo CSMA/CA (Sense Multiple Access/Collision Avoidance). En cambio el PCF proporciona un acceso al medio libre de contienda y centralizado. El modo PCF requiere un punto de control central (punto de acceso), con lo que resulta inviable trabajar en modo ad hoc, que es distribuido. Por lo tanto, las redes ad hoc utilizarán el modo DCF. El DCF se encuentra en el nivel inferior de la capa MAC y se basa en técnicas de acceso aleatorias de contienda. El tráfico que se transmite es asíncrono, ya que al utilizar estas técnicas se introducen retardos aleatorios que no son soportados por servicios síncronos. El algoritmo que usa es el CSMA/CA (Carrier Sense Múltiple Access with Collision Avoidance).
9.3 Modelo de radiopropagación [39]
Se entiende como radiopropagación la transmisión de ondas de radio de un punto sobre la Tierra a otro, o en varias partes de la atmósfera. La propagación de las ondas se puede ver afectada por diversos fenómenos como la reflexión, la refracción, la difracción, la absorción, la polarización y la dispersión.
En este proyecto se utiliza el modelo de radiopropagación de espacio libre (Free Space Model) porque define un entorno ideal de propagación, es decir, no se tienen en cuenta las pérdidas ocasionadas por los fenómenos antes mencionados y donde existe línea de vista entre el transmisor y el receptor. La finalidad de este trabajo es la evaluación del rendimiento de los protocolos de enrutamiento AODV y OLSR a través de parámetros establecidos en un ambiente urbano ideal lo cual es consecuente con el modelo de radiopropagación escogido. Este modelo se encuentra implementado dentro de la herramienta de simulación NS2.
38
�� � = �� � �� � ��
Donde ��es la potencia de la señal transmitida, � y � son la ganancia de la antena transmisora y receptora. L son las pérdidas del sistema, d es la distancia y � es la longitud de onda.
En el modelo de radiopropagación de espacio libre el rango de comunicación básicamente se representa como un círculo alrededor del transmisor. Si el receptor está dentro del círculo recibirá los paquetes enviados, de lo contrario se perderán.
9.4 Protocolos de transporte [40]
Los protocolos seleccionados para la simulación de red VANET son el TCP y el UDP, pertenecientes al modelo TCP/IP. Son ampliamente conocidos y usados por la mayoría de investigadores en el ámbito de estas redes.
9.4.1 Protocolo TCP (Transport Control Protocol)
TCP es un protocolo orientado a conexión, es decir, permite a dos máquinas que estén comunicadas el control del estado de la transmisión.
Las principales características del protocolo TCP son las siguientes:
TCP permite colocar los datagramas nuevamente en orden cuando vienen del protocolo IP. TCP permite que el monitoreo del flujo de los datos y así evitar la saturación de la red.
TCP permite que los datos se formen en segmentos de longitud variada para "entregarlos" al protocolo IP.
TCP permite multiplexar los datos, es decir, que la información que viene de diferentes fuentes (por ejemplo, aplicaciones) en la misma línea pueda circular simultáneamente.
Por último, TCP permite comenzar y finalizar la comunicación amablemente.
Con el uso del protocolo TCP, las aplicaciones pueden comunicarse en forma segura (gracias al sistema de acuse de recibo del protocolo TCP) independientemente de las capas inferiores. Esto significa que los enrutadores (que funcionan en la capa de red) sólo tienen que enviar los datos en forma de datagramas, sin preocuparse con el monitoreo de datos porque esta función la cumple la capa de transporte (o más específicamente el protocolo TCP).
Durante una comunicación usando el protocolo TCP, las dos máquinas deben establecer una conexión. La máquina emisora (la que solicita la conexión) se llama cliente, y la máquina receptora se llama servidor. Las máquinas de dicho entorno se comunican en modo en línea, es decir, que la comunicación se realiza en ambas direcciones.
Respecto al modelo de flujo de datos de la red, se ha definido la aplicación con FTP (File Transfer Protocol) el cual opera sobre agentes de protocolo TCP especificados en cada nodo.
Existen varias versiones del protocolo TCP como el TCP Tahoe, escogido para este proyecto, el cual utiliza los algoritmos Slow-Start, Congestion Avoidance y Fast Retransmit como métodos para manejar la congestión del canal de comunicaciones y la retransmisión de paquetes.
9.4.2 Protocolo UDP (User Datagram Protocol)
