proyecto fin de carrera - servidor de la biblioteca de ingeniería. universidad de...

i

s

Proyecto Fin de Carrera

Ingeniería de Telecomunicación

Evaluación de Protocolos de Encaminamiento

Para Redes Vehiculares (VANET)

Autor: José Manuel García Campos

Tutor: Daniel Gutiérrez Reina

Dept. de Ingeniería Electrónica

Escuela Técnica Superior de Ingeniería

Universidad de Sevilla

Sevilla, 2014

Proyecto Fin de Carrera

Ingeniería de Telecomunicación

Evaluación de Protocolos de Encaminamiento Para Redes

Vehiculares (VANET)

Autor:

José Manuel García Campos

Tutor:

Daniel Gutiérrez Reina

Dept. Ingeniería Electrónica

Escuela Técnica Superior de Ingeniería

Universidad de Sevilla

Sevilla, 2014

Proyecto Fin de Carrera: Evaluación de Protocolos de Encaminamiento Para Redes Vehiculares (VANET)

Autor: José Manuel García Campos

Tutor: Daniel Gutiérrez Reina

El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros:

Presidente:

Vocales:

Secretario:

Acuerdan otorgarle la calificación de:

Sevilla, 2014

A mi familia

1. Resumen

El presente proyecto fin de carrera incluye un estudio comparativo de los protocolos de

encaminamiento: AODV, DSDV, DSR, OLSR, DYMO, ZRP y AOMDV sobre tres escenarios que

describen el tráfico vehicular urbano en la ciudad de Manhattam, Tokio, Madrid y Nueva York. El

primero de ellos ha sido generado con Boomotion y el resto con Citymob for Roadmaps (C4R)

usando mapas reales.

La red ad-hoc vehicular (VANET) ha sido configurada con interfaces inalámbricas bajo el estándar

IEEE 802.11p.

La evaluación de la VANET se efectúa bajo las métricas: Troughput (rendimiento), PDF (relación

de entrega de paquetes), Average End to End Delay (retardo promedio), NRL (Carga de

enrutamiento normalizada) y número de paquetes perdidos, las cuales se presentan como

resultado de las simulaciones; mediante tablas y gráficas. El desempeño de la red resulta óptimo

cuando se obtienen altos niveles de Troughput y PDF, con bajos niveles de retardo y NRL.

vii

2. ÍNDICE

1. Resumen vi

2. Índice vii

3. Índice de figuras 9

4. Índice de tabla 12

5. Glosario de Acrónimos 13

1. Redes ad-hoc inalámbricas 15 Introducción 15 1. Definición 15 2. Aplicaciones 16 3. Encaminamiento ad hoc 17 4. Clasificación de los protocolos de encaminamiento para redes ad hoc 17 5.5.1. Planificación 19 5.2. Modelo de información de estado 19 5.3. Modelo de transmisión 20 5.4. Direccionamiento 20 5.5. Estructura 21 5.6. Modelo de comunicación 21 5.7. Modos de actualización 21 5.8. Número de caminos buscados 22 5.9. Método de cálculo de rutas 22 Estudio comparativo 22 6. Eficiencia de encaminamiento 24 7.

2. Redes VANET 31 Introducción 31 1. Características 31 2. Tecnologías inalámbricas usadas en redes VANETS 32 3.3.1. Tecnología IEEE 802.11 32 3.2. 802.11a 32 3.3. 802.11p 32 3.4. Bluetooh 33 3.5. UWB 33 3.6. ZigBee 34 Protocolos de encaminamiento 34 4.4.1. Protocolos Broadcast 35 4.2. Protocolos Unicast 37 4.3. Protocolos Geocast 41 Seguridad 45 5.5.1. Ataques en redes Vanets 45 5.2. Control de acceso 46 5.3. Sistema de detección de intrusos 46 5.4. Seguridad en el encaminamiento 47 5.5. Cifrado y gestión de claves 47 Aplicaciones 48 6.6.1. Seguridad activa 50 6.2. Servicio público 51 6.3. Negocios/Entretenimiento 52 Calidad de servicio 54 7.7.1. Modelos de calidad de servicio 55 7.2. Señalización para la reserva de recursos 55 7.3. Calidad de servicio ligada a encaminamiento 55 Factores que afectan a una VANET 56 8.

3. Protocolos de encaminamiento bajo estudio 58 Protocolos Reactivos 58 1.I. AODV 58

viii Evaluación de Protocolos de Encaminamiento Para Redes Vehiculares (VANET)

II. DSR 67 III. AOMDV 72 IV. DYMO 72 Protocolos Proactivos 75 2.I. DSDV 75 II. OLSR 78 Protocolos Híbridos 79 3.

4. Modelos de movilidad 82 Introducción 82 1. Descripción de los modelos de movilidad 83 2.Movimiento a velocidad constante 83 Manhattan Grid Model (ManhattanGrid) 83 Modelo de Kerner 84 Modelo de Krauβ 84 Modelo de conducción inteligente 85 Herramientas para la generación de los modelos de movilidad 86 3.BonnMotion 86 Citymob for Roadmaps (C4R) 87

5. Entorno de trabajo 92 1. Modelado 92 2. Herramienta de simulación de red 94

2.1. Comparativa de heramientas de simulación de red 94 2.2. Justificación de la elección del simulador de red ns-2 95 Metodología de trabajo 98 4.

6. Evaluación de resultados 101 Métricas 101 1. Evaluación de métricas para Manhattangrid 101 2.1. Análisis de densidad (Variando el número de nodos) 101 2. Análisis de congestión (Variando el número de conexiones) 111 Evaluación de métricas para diferentes escenarios 122 3.Parámetros de simulación 122 Resultados de la simulación 123

4. Comparación con otros estudios 146

7. Conclusiones y vías futuras 147

8. Apéndice 149 Modelado del escenario 149 1. Procesado de los ficheros de traza 151 2. Procesado de la métrica 153 3. Script maestro 157 4.

9. Referencias 163

9

3. ÍNDICE DE FIGURAS

Ilustración 1 Clasificación de los protocolos de encaminamiento en redes ad hoc 18

Ilustración 2 Problema del terminal escondido 33

Ilustración 3 Mecanismo NES 36

Ilustración 4 Mecanismo CDS 37

Ilustración 5 Ejemplo de Expected zone 38

Ilustración 6 LAR con nodo origen fuera de la RZ 39

Ilustración 7 Esquema funcionamiento TORA 40

Ilustración 8 Esquema LBM box 41

Ilustración 9 Esquema LBM step 42

Ilustración 10 Funcionamiento de GEOTORA 43

Ilustración 11 Esquema GEOGRID 44

Ilustración 12 Zona de forwarding GAMER 45

Ilustración 13 Inundación con mensajes RREQ 61

Ilustración 14 Generación de caminos de vuelta potenciales 62

Ilustración 15 Reenvio de mensajes RREP 63

Ilustración 16 Diagrama de flujo para la actualización de rutas en los nodos intermedios durante la fase de formación del camino de ida 64

Ilustración 17 Envio de paquetes de datos sobre el camino de ida seleccionado 64

Ilustración 18 Descubrimiento de ruta AODV I 65

Ilustración 19 Descubrimiento de ruta AODV II 65

Ilustración 20 Descubrimiento de ruta AODV III 66

Ilustración 21 Decubrimiento de ruta AODV IV 66

Ilustración 22 Descubrimiento de ruta AODV V 66

Ilustración 23 Descubrimiento de ruta AODV VI 67

Ilustración 24 Ejemplo formación de camino de ida para DSR 69

Ilustración 25 Ejemplo de camino de vuelta para DSR 69

Ilustración 26 Envio de datos establecido la ruta. DSR 70

Ilustración 27 Carga de señalización en Dsdv 77

Ilustración 28 Envio de un paquete de señalización DSDV 77

Ilustración 29 Mecanismo de inundación en OLSR 79

Ilustración 30 Protocolo ZRP 80

Ilustración 31 Ejemplo de escenario Manhattan Grid 87

Ilustración 32 Barra menú-Selección de mapa 87

Ilustración 33 Vista de un mapa cargado con OpenStreetMap 88

Ilustración 34 Adición de vehículos aleatoriamente 88

Ilustración 35 Configuración modelo aleatorio 88

Ilustración 36 Configuración del modelo manual 89

Ilustración 37 Configuración de vehículos especiales 89

Ilustración 38 Configurar centro de atracción 89

10 Evaluación de Protocolos de Encaminamiento Para Redes Vehiculares (VANET)

Ilustración 39 Configuración del centro de atracción 89

Ilustración 40 Configurar modelo de movilidad 90

Ilustración 41 Modelo de simulación de redes de sensores 93

Ilustración 42 Modelo de nodo 93

Ilustración 43 Perspectiva de ns-2 desde el punto de vista de usuario 96

Ilustración 44 Esquema flujo de trabajo 98

Ilustración 45 PDF-Manhattan 102

Ilustración 46 PDF-Manhattan sin ZRP 103

Ilustración 47 Paquetes Perdidos-Manhattan 104

Ilustración 48 Average End to End Delay - Manhattan 105

Ilustración 49 NRL- Manhattan 106

Ilustración 50 NRL - Manhattan sin ZRP 106

Ilustración 51 Troughput- Manhattan 107

Ilustración 52 Simulación con herramienta NAM 110

Ilustración 53 PDF - Análisis congestión 112

Ilustración 54 Dropp Packet - Análisis congestión 113

Ilustración 55 Paquetes perdidos en Bufffer - Análisis congestión 114

Ilustración 56 Dropp Packet sin DSR - Análisis congestión 114

Ilustración 57 End to End Delay - Análisis congestión 115

Ilustración 58 NRL - Análisis congestión 116

Ilustración 59 NRL sin ZRP - Análisis congestión 116

Ilustración 60 Troughput - Análisis congestión 117

Ilustración 61 PDF - Ciudad Regular – Todos los protocolos 123

Ilustración 62 Paquetes perdidos - Ciudad Regular – Todos los protocolos 123

Ilustración 63 Average End to End Delay - Ciudad Regular – Todos los protocolos 124

Ilustración 64 NRL - Ciudad Regular – Todos los protocolos 124

Ilustración 65 Troughput - Ciudad Regular – Todos los protocolos 125

Ilustración 66 PDF - Ciudad Compleja – Todos los protocolos 126

Ilustración 67 Paquetes Perdidos - Ciudad Compleja – Todos los protocolos 126

Ilustración 68 Average End to End Delay - Ciudad Compleja – Todos los protocolos 127

Ilustración 69 NRL - Ciudad Compleja – Todos los protocolos 127

Ilustración 70 Troughput - Ciudad Compleja – Todos los protocolos 128

Ilustración 71 PDF - Ciudad Simple – Todos los protocolos 129

Ilustración 72 Paquetes Perdidos - Ciudad Simple – Todos los protocolos 129

Ilustración 73 Average End to End Delay - Ciudad Simple – Todos los protocolos 130

Ilustración 74 NRL - Ciudad Simple – Todos los protocolos 130

Ilustración 75 Troughput - Ciudad Simple – Todos los protocolos 131

Ilustración 76 PDF - AODV - Ciudades 135

Ilustración 77 PDF - DSR - Ciudades 135

Ilustración 78PDF - DSDV - Ciudades 136

Ilustración 79 PDF - AOMDV - Ciudades 136


Ilustración 80 PDF - ZRP - Ciudades 136

Ilustración 81 PDF - DYMO - Ciudades 137

Ilustración 82 Paquetes Perdidos - AODV - Ciudades 137

Ilustración 83 Paquetes Perdidos - DSR - Ciudades 137

Ilustración 84 Paquetes Perdidos - DSDV - Ciudades 138

Ilustración 85 Paquetes Perdidos - AOMDV - Ciudades 138

Ilustración 86 Paquetes perdidos - ZRP - Ciudaddes 138

Ilustración 87 Paquetes perdidos - DYMO - Ciudaddes 139

Ilustración 88 Average End to End Delay - AODV - Ciudades 140

Ilustración 89 Average End to End Delay - DSR - Ciudades 140

Ilustración 90 Average End to End Delay - DSDV - Ciudades 140

Ilustración 91 Average End to End Delay - AOMDV - Ciudades 141

Ilustración 92 Average End to End Delay - ZRP - Ciudades 141

Ilustración 93 Average End to End Delay - Dymo - Ciudades 141

Ilustración 94 NRL - AODV - Ciudades 142

Ilustración 95 NRL - DSR - Ciudades 142

Ilustración 96 NRL - DSDV - Ciudades 142

Ilustración 97 NRL - AOMDV - Ciudades 143

Ilustración 98 NRL - ZRP - Ciudades 143

Ilustración 99 NRL - Dymo - Ciudades 143

Ilustración 100 Troughput- AODV - Ciudades 144

Ilustración 101 Troughput- DSR - Ciudades 144

Ilustración 102 Troughput- AODV - Ciudades 144

Ilustración 103 Troughput- AOMDV - Ciudades 145

Ilustración 104 Troughput- AOMDV - Ciudades 145

Ilustración 105 Troughput - Dymo - Ciudades 145


4. ÍNDICE DE TABLA

Tabla 1 Campos de aplicación de las tecnologías inalambricas ad hoc 17

Tabla 2 Estudio comparativo de los protocolos de encaminamiento ad hoc proactivos 27

Tabla 3 Estudio comparativo de los protocolos de encaminamiento ad hoc reactivos 29

Tabla 4 Características de las tecnologías inalámbricas consideradas 34

Tabla 5 Características de los protocolos 35

Tabla 6 Aplicaciones VANET 49

Tabla 7 Parámetros para simular el comportamiento de tres tipos de conductores y de conductor de camión 86

Tabla 8 Comparativa PDF – Manhattan 108

Tabla 9 Comparativa Troughput – Manhattan 108

Tabla 10 Comparativa NRL – Manhattan 108

Tabla 11 Comparativa Dropp packet – Manhattan 109

Tabla 12 Comparativa Average end to end delay – Manhattan 109

Tabla 13 Elección de protocolos por métricas – Análisis de densidad 109

Tabla 14 Comparativa Eficiencia – Manhattan 110

Tabla 15 PDF Comparativa - Análisis congestión 118

Tabla 16 Troughput comparativa - Análisis congestión 118

Tabla 17 NRL comparativa - Análisis congestión 119

Tabla 18 DROPP comparativa - Análisis congestión 119

Tabla 19 Average End to End Delay - Análisis congestión 120

Tabla 20 Elección de protocolos por métricas - Análisis congestión 120

Tabla 21 Eficiencia - Análisis congestión 121

Tabla 22 Análisis Ciuadad Compleja 132

Tabla 23 Protocolo seleccionado por parámetro. Ciudad compleja 133

Tabla 24 Análisis Ciuadad Regular 133

Tabla 25 Protocolo seleccionado por parámetro. Ciudad regular 133

Tabla 26 Análisis Ciuadad Simple 134

Tabla 27 Protocolo seleccionado por parámetro. Ciudad simple 134

Tabla 28 Documentos de referencia 146


5. GLOSARIO DE ACRÓNIMOS

ABR Associativity-Based Routing

ADV Adaptative Distance Vector

AODV Associativity-Based Routing

CBR Constant Bit Rate

CBRP Cluster-Based Routing Protocol

CDMA Code Division Multiple Access

CEDAR Core-Extraction Distributed Ad Hoc Routing

CGSR Cluster Gateway Switch Routing

CSMA/CA Carrier Sense Multiple Access, Collision Avoidance

DAG Directed Acyclic Graph

DREAM Distance Routing Effect Algorithm for Mobility

DSDV Destination-Sequenced Distance Vector

DSR Dynamic Source Routing Protocol

DYMO Dynamic MANET On demand

FQMM Flexible QoS Model for MANET

GLS Grid Location Service

GPSR Greedy Perimeter Stateless Routing

GRPH Group Hello

GSR Geographic Source Routing

HGR Hybrid Geocast Routing

HSR Hierarchical State Routing

IERP Interzone Routing Protocol

IETF Internet Engineering Task Force

IPSec AH IP Security Authentication Header

LAR Location-Aided Routing

LBM Location Based Multicast

LLS Locality aware Location Service


LSP Link State Packet

MACT Multicast Activations

MANET Mobile Ad Hoc Network

MMWN Multimedia support in Mobile Wireless Networks

MPRs Multipoint Distribution Relays

NAM Network Animator

OLSR Optimised Link State Routing

PSAP Public Safety Answering Point

QOLSR QoS Object Tool Command Language

QOS Quality of Service

RREP Route Reply

RREQ Route Request

RTS/CTS Request-to-Send/Clear-to-send

SLURP Scalable Location Update Routing Protocol

STAR Source-Tree Adaptative Routing

TBP Ticket-Based Probing

TBRPF Topology dissemination Based on Reverse-Path Forwarding

TDMA Time Division Multiple Access

TORA Temporally Ordered Routing Algorithm

VANET Vehicular ad-hoc network

WRP Wireless Routing Protocol

ZHLS Zone-based Hierarchical Link State

ZRP Zone Routing Protocol

GAMER Geocast Adaptative Mesh Environment for Routing

CEDAR Core-Extraction Distribu-ted Ad-hoc Routing


1. REDES AD-HOC INALÁMBRICAS

Introducción 1.

Bajo una perspectiva tradicional, una red de comunicaciones puede concebirse como un conjunto de

dispositivos que ofrecen servicios de comunicación a usuarios externos. De esta forma, el conjunto de

parámetros que deben ser considerados para su diseño, operación y consecución de los niveles de

calidad exigidos se restringe al ámbito interno de la misma, limitando el papel de los usuarios a un

mero acceso a la red bajo ciertas condiciones impuestas. Sin embargo, hoy en día el usuario final no se

resigna a jugar un papel tan sólo secundario en la comunicación, en su comunicación. En un principio,

reclamó movilidad, más tarde diversidad de medios y contenidos y por último libertad para el

establecimiento de sus propias redes que atiendan necesidades concretas en tiempo y espacio. Este

requerimiento hace necesarios nuevos esquemas en los que la red esté conformada únicamente por

dispositivos terminales, que actúen por tanto como nodos sin infraestructura externa y fija, y cuyo

despliegue sea sencillo y de bajo coste. Todo ello obliga a una respuesta tecnológica que desplace el

control de dichas comunicaciones hacia los extremos más periféricos de las redes.

A diferencia de las redes cableadas tradicionales, en una red ad hoc inalámbrica, cada uno de los

componentes o nodos funciona simultáneamente como estación y como encaminador. Para que cada

nodo sea capaz de comunicarse con el resto, es necesario que mantenga información de la red a la

que pertenece y disponga de algún algoritmo que rija el envío y recepción de paquetes. El conjunto

que forma el algoritmo de encaminamiento y la información sobre las condiciones de la red recibe el

nombre de protocolo de encaminamiento. Los protocolos de encaminamiento en redes ad hoc deben

adaptarse de manera rápida y correcta a los frecuentes e imprevisibles cambios de la topología de la

red, haciendo un uso mínimo de memoria, potencia de transmisión y ancho de banda.

Definición 2.

El término ad hoc es una locución latina que significa literalmente <<para esto>>. El Instituto de

Ingenieros Eléctricos y Electrónicos define las redes ad hoc como aquellas redes compuestas

únicamente por estaciones, estando cada una de ellas dentro del rango de cobertura de alguna de las

otras a través de un medio inalámbrico. Una red ad hoc se crea típicamente de manera dinámica y su

principal singularidad es su limitación tanto temporal como espacial. Estas restricciones permiten crear

y disolver redes de manera suficientemente sencilla y práctica. Formalmente, una red ad hoc

inalámbrica se puede parametrizar considerando los siguientes calificativos:

Inalámbrica: Los nodos se comunican a través de medios de transmisión no guiados (radio,

infrarrojos, etc.).

Ad hoc: La red es temporal y se establece dinámicamente de manera arbitraria por un

conjunto de nodos según se necesite.

Autónoma y sin infraestructura: La red no depende de ninguna infraestructura establecida ni

de ninguna administración centralizada. Cada nodo opera de manera distribuida de par a par1,

actúa como un encaminador independiente y genera datos por sí mismo.


Multisalto: No se necesitan encaminadores dedicados, cada nodo actúa como un encaminador

y reenvía paquetes hacia otros nodos para facilitar el intercambio de información entre los

integrantes de la red.

Adicionalmente, los nodos pueden estar dotados de movilidad. En este caso, estas redes reciben el

nombre de redes ad hoc móviles (MANETs, Mobile Ad hoc NETworks). La topología en este tipo de

redes es dinámica debido al constante movimiento de los nodos participantes, haciendo que los

patrones de comunicación entre los miembros de la red evolucione constantemente.

En definitiva, las redes ad hoc inalámbricas eliminan las restricciones impuestas por las

infraestructuras fijas, permitiendo a los dispositivos crear y adherirse a redes improvisadamente,

haciéndolas adecuadas para adaptarse virtualmente a cualquier aplicación.

Aplicaciones 3.

La cualidad más notable de las redes ad hoc es su flexibilidad. El hecho de que puedan establecerse en

cualquier lugar y en cualquier momento sin infraestructura, administración o preconfiguración, las

hace muy atractivas para un amplio rango de campos de aplicación. La Tabla 1 muestra una

clasificación de las aplicaciones presentes y futuras de las redes ad hoc, así como de los servicios que

ofrecen.

Aplicaciones Servicios ofrecidos

Redes tácticas Comunicaciones en operaciones militares

Campos de batalla automatizados

Redes de sensores Recogida de datos en tiempo real, generalmente altamente correlados en espacio y tiempo

Servicios de salvamento y emergencia

Operaciones de búsqueda y rescate

Sustitución de redes con infraestructuras en caso de catástrofes naturales

Entornos comerciales Comercio electrónico

Acceso remoto a los registros de los cliente desde una base de datos centralizada

Oficina móvil

Servicios vehiculares

Redes para particulares y empresas

Redes de área local inalámbricas (WLAN, Wireless Local Área Network) para hogares u oficinas

Redes de área personal (PAN, Personal Área Network)

Aplicaciones educativas Configuración de clases virtuales

Configuración de comunicaciones ad hoc en reuniones, conferencias y congresos

Ocio Juegos multi-usuario

Robots mascota


Acceso a Internet en exteriores

Servicios de localización Servicios de seguimiento

Servicios de información

Tabla 1 Campos de aplicación de las tecnologías inalambricas ad hoc

Encaminamiento ad hoc 4.

En esencia, el proceso de encaminamiento se define como el acto de transmisión de información

desde una fuente u origen hasta un destino, esto es, extremo a extremo. El encaminamiento se asimila

como el proceso de selección de caminos desde un origen hasta un destino dentro de una red. Un

protocolo de encaminamiento para redes ad hoc permite que la red se organice completamente por sí

sola, y su objetivo principal es el establecimiento correcto y eficiente de rutas entre un par de nodos,

de tal modo que los mensajes sean entregados de manera fiable y a tiempo. La construcción de rutas

debe producirse con una mínima sobrecarga en las cabeceras de los paquetes de control y un mínimo

consumo de ancho de banda.

Las consideraciones que han de tenerse en cuenta en el diseño y estudio de los nuevos protocolos de

encaminamiento incluyen:

Simplicidad y facilidad de implementación.

Convergencia rápida de rutas, libres de bucles y óptimas. Incluso, puede que sea posible

establecer diferentes rutas entre el mismo par de nodos origen y destino, para aumentar la

robustez.

Naturaleza distribuida y ligera, de tal forma que, ante cambios en la topología y en los patrones

de tráfico, la reacción del protocolo implique una mínima sobrecarga de cabeceras.

Eficiencia en términos de ancho de banda, potencia de transmisión y computación, con una

sobrecarga de cabeceras mínima.

Escalabilidad, de tal forma que si la red aumenta significativamente en número de nodos, no se

degraden las prestaciones.

Seguridad a nivel de confidencialidad, control de acceso y denegación de ataques de servicio

producidos por nodos maliciosos.

Capacidad de soportar requerimientos de calidad de servicio. La garantía de calidad de servicio

es esencial para la entrega a tiempo de tráfico multimedia.

Clasificación de los protocolos de encaminamiento para redes 5.ad hoc

Se han propuesto numerosos protocolos de encaminamiento con la finalidad de cubrir las diferentes

necesidades en función de los distintos entornos y condiciones de tráfico. La gran variedad de


protocolos existentes hace que existan diversos criterios para su clasificación, que a su vez reflejan los

aspectos más importantes considerados para su diseño. Las fuentes consultadas proponen diferentes

catalogaciones que en muchos casos son incompletas, ya que no contemplan todos los criterios

existentes. Es por esto por lo que se ha considerado oportuno realizar un estudio pormenorizado de

los protocolos que más frecuentemente aparecen en esta literatura para confeccionar una nueva

clasificación que incorpore todos los criterios mencionados. Para complementar todo ello, se ha

elaborado una gráfica que, a modo de resumen, ilustra esta renovada catalogación y que se muestra

en la Ilustración 1. Las siguientes páginas desgranan esta figura, describiendo las características

estudiadas para esta nueva clasificación.

Ilustración 1 Clasificación de los protocolos de encaminamiento en redes ad hoc


5.1. Planificación

El criterio de planificación supone la clasificación más ampliamente empleada en la literatura y atiende

al momento en el que se calcula la ruta desde un nodo origen hasta un nodo destino. Mientras que en

los protocolos proactivos se conserva la información actualizada en todo momento, en los reactivos se

busca la ruta hacia el destino sólo cuando surge la necesidad de establecer una comunicación.

Protocolos de encaminamiento proactivos. Mantienen información consistente y actualizada

desde cada nodo hacia todos los demás, propagando proactivamente actualizaciones de rutas.

Puesto que la información de encaminamiento se suele mantener en tablas, es común

referirse a estos protocolos como protocolos dirigidos por tabla (table-driven routing

protocolos). Se diferencian entre ellos en el número de tablas necesarias y en los métodos

utilizados para difundir los cambios de la red.

Protocolos de encaminamiento reactivos. Establecen una ruta hacia el destino solamente

cuando se precisa, generalmente iniciada por el nodo origen a través de un procedimiento de

descubrimiento de rutas. Una vez que se ha establecido la ruta, el nodo se ocupa de

mantenerla hasta que ya no se necesita o caduca. También se conocen como protocolos de

encaminamiento iniciados en origen bajo demanda (source-iniciated demand driven).

5.2. Modelo de información de estado

Al igual que ocurre en los protocolos de encaminamiento de las redes cableadas tradicionales, los

protocolos ad hoc pueden clasificarse atendiendo a cuál es la información mantenida en cada nodo y

cuáles son los destinatarios de esa información, distinguiendo entre la familia de estado de enlaces y la

familia de vector de distancias.

Basado en topología de estado de enlaces (EE) La información de encaminamiento se

transmite en forma de paquetes de estado de enlaces. Los paquetes que envía cada nodo

incluyen información acerca de sus nodos vecinos y cualquier cambio en alguno de sus enlaces

provoca inmediatamente la inundación de la red. Cada nodo es así capaz de reconstruir y

mantener un mapa de la topología global de la red a través de los LSP que recibe, pudiendo

calcular por sí mismo las rutas hacia cualquier otro nodo. El principal inconveniente es que se

puede producir sobrecarga si la naturaleza de la red es altamente dinámica. Un caso particular

son los protocolos basados en asociatividad de estado de enlaces, en los que los nodos

mantienen información sobre el nivel de señal recibida en periodos espacio-temporales. Otra

modalidad consiste en mantener información de estado de enlaces nivel de enlace,

intercambiando información de bajo nivel.

Basados en destino o de vector de distancias (VD) Cada nodo mantiene una estructura de

datos a modo de array denominada vector de distancias en la que se incluye cierta

información. Los campos que como mínimo deben aparecer en este vector son la tripleta

formada por la dirección IP del nodo destino, la dirección IP del siguiente salto y la distancia

más corta para alcanzarlo. Cada componente de la red intercambia periódicamente sus

vectores de distancias con sus nodos vecinos. Cuando un nodo recibe los vectores de distancias

de los nodos que le rodean, calcula de nuevo las rutas y actualiza su propio vector de

distancias. La principal desventaja es la lenta convergencia y la tendencia a crear bucles. Un


caso particular son los protocolos basados en inversión de enlaces (IE), en los que cuando se

detecta una fallo en un enlace, es el nodo afectado el que se encarga de encontrar una ruta

hacia el origen.

5.3. Modelo de transmisión

El modelo de transmisión atiende qué destinatarios deben recibir los paquetes. Cabe pensar que en un

canal inalámbrico, todos los nodos dentro del rango de cobertura del nodo origen recibirán los

paquetes, estableciendo un modelo de comunicación broadcast. No obstante, se pueden establecer

otros mecanismos para restringir el grupo de destinatarios. De hecho, el modelo de comunicación más

ampliamente extendido para la transmisión de mensajes de control es el método unicast

Unicast. Se refiere a la comunicación uno a uno, es decir, de un nodo origen a un único nodo

destino. La mayor parte de los protocolos de encaminamiento para redes ad hoc se ubica

dentro de esta categoría, ya que se trata del modo de operación normal en cualquier red.

Multicast. Este modelo de comunicación se emplea cuando un nodo necesita enviar

información idéntica a varios destinos. Un nodo puede incorporarse o disgregarse de un grupo

multicast cuando lo desee, pero en contrapartida, los nodos deben mantener información

adicional sobre los nodos que se adhieren o abandonan su grupo multicast. En este tipo de

protocolos, se suele emplear la técnica de envío por inundación (flooding), por la que cuando

un nodo recibe un paquete por un interfaz, lo reenvía por todos los interfaces salvo por el que

le llegó.

Geocast. Se trata de un caso particular de envío multicast que se utiliza para entregar paquetes

a un grupo de nodos situados dentro de un área geográfica específica. Un nodo puede

adherirse o abandonar un grupo geocast simplemente entrando o saliendo de esa área

geográfica. Este tipo de protocolos facilita el procedimiento de descubrimiento de rutas al

proporcionar información sobre la localización física de los nodos.

Broadcast. Se trata del modo de operación básico en un canal inalámbrico, ya que cada

mensaje emitido por un nodo en un canal inalámbrico es recibido por todos sus vecinos. Sin

embargo, sólo algunos protocolos implementan este tipo de modelo de transmisión y siempre

a modo de apoyo. Emplear exclusivamente el modo de transmisión broadcast no es prudente,

ya que se consume un ancho de banda excesivo y en muchas ocasiones de forma innecesaria.

5.4. Direccionamiento

El direccionamiento hace alusión a la organización de la red en niveles jerárquicos lógicos, según todos

los nodos estén al mismo nivel, dando lugar a un direccionamiento plano o no lo estén, originando un

direccionamiento estratificado o jerárquico.

Plano. No existe jerarquía en la red, todos los nodos están al mismo nivel. Si un nodo falla, no

afecta a todos los demás.

Jerárquico. Existen nodos de niveles superiores y nodos de niveles inferiores. Los primeros

pueden clasificarse en nodos clusterhead, que gestionan la comunicación dentro de un cluster

o agrupación, y nodos pasarela o Gateway-Node, responsables de la comunicación entre

agrupaciones. Los nodos de niveles superiores devienen en un punto único de fallo, ya que si


uno de estos nodos falla, perjudica todos sus nodos subordinados.

5.5. Estructura

La estructura de la de la red está relacionada con la uniformidad de los roles que desempeñan los

nodos que la integran. Mientras que unos protocolos tratan a todos los nodos de igual modo,

estructurándolos uniformemente, otros hacen distinciones entre diferentes nodos de la red,

estableciendo una estructura no uniforme.

Uniforme. Todos los nodos cumplen idénticas funciones, enviando mensajes de control y

respondiendo a los mismos de igual modo.

No uniforme. Algunos nodos ejercen papeles específicos en cuanto al tratamiento de la

información de encaminamiento. Dentro de los protocolos no uniformes, se puede distinguir

entre los que hacen uso del método de selección de vecinos, si los nodos centran su actividad

de encaminamiento sólo en algunos de sus vecinos; y los que emplean el método de

particionamiento, por el que la red se divide lógicamente en subredes.

5.6. Modelo de comunicación

Dependiendo del uso del espectro, los protocolos de encaminamiento en redes ad hoc se pueden

catalogar según la tecnología de acceso al medio empleada y a los mecanismos para compartir dicho

medio de transmisión. Se trata de una clasificación que atiende a características de nivel de enlace,

distinguiendo entre modelos de comunicación multicanal y monocanal.

Multicanal. Son protocolos de bajo nivel que, además de funcionalidad de encaminamiento,

incorporan mecanismos para la asignación de canal. Se suelen emplear en redes basadas en las

técnicas de reparto del canal de acceso múltiple por división de tiempo, TDMA, y de acceso

múltiple por división de código, CDMA.

Monocanal. La mayoría de los protocolos asumen que los nodos se comunican sobre un único

canal lógico inalámbrico y comúnmente emplean la técnica de acceso múltiple por detección

de portadora con evasión de colisiones, CSMA/CA.

5.7. Modos de actualización

La información de encaminamiento necesita diseminarse por la red para asegurar que la información

sobre el estado del canal y la topología de la red se mantiene actualizada en los nodos. Según cuándo

se difunde esta información, se puede distinguir entre protocolos que envían actualizaciones

periódicamente, protocolos que activan las actualizaciones cuando se produce un evento, y protocolos

que emplean una mezcla de ambas técnicas.

Actualizaciones periódicas. Los nodos distribuyen la información de encaminamiento cada

cierto periodo fijo de tiempo. Las actualizaciones periódicas simplifican los protocolos y sobre

todo facilitan que los nuevos nodos que se adhieren a la red aprendan la topología y el estado

de la misma. Sin embargo, si el periodo entre actualizaciones es demasiado alto, la información

no siempre será válida, ya que los cambios en la red no serán detectados inmediatamente. Por

el contrario, si el periodo es excesivamente pequeño, se enviará un número de mensajes

considerable, consumiendo un ancho de banda excesivo.


Actualizaciones dirigidas por eventos. Cuando un nodo detecta un evento, tal como el fallo de

un enlace o la aparición de un nuevo enlace, envía un paquete de actualización en modo

broadcast para difundir el nuevo estado de la red. En contrapartida, si la naturaleza de la red es

altamente dinámica, se deberán enviar abundantes paquetes de actualización, degradando la

red. Ocasionalmente, puede incluso desencadenar la fluctuación de rutas.

Actualizaciones híbridas. Algunos protocolos hacen un uso conjunto de las dos técnicas

anteriores, creando un mecanismo denominado actualización híbrida. Por ejemplo, en un

protocolo con modelo de información de estado basado en destino, un nodo puede difundir su

vector de distancias periódicamente y si descubre que un enlace ha fallado, distribuir un

mensaje de manera inmediata.

5.8. Número de caminos buscados

La mayoría de los protocolos de encaminamiento para redes ad hoc se limitan a buscar una única ruta

desde un nodo origen hasta un nodo destino, pero otros descubren varios caminos hacia el mismo

nodo destino, de tal forma que el nodo origen, atendiendo a diferentes criterios, puede elegir el que

considere más oportuno.

Único camino. Los protocolos que hallan una sola ruta permiten un ahorro en el

almacenamiento de la información y la simplificación del algoritmo de búsqueda.

Múltiples caminos. Los protocolos de encaminamiento que buscan múltiples rutas son más

robustos y confiables, ya que cuentan a su favor con una rápida recuperación ante fallos de

enlaces. Además, el encaminamiento con rutas múltiples ocasiona un mayor rendimiento,

puesto que el nodo origen, al disponer de varias rutas hacia el destino, puede realizar reparto

de carga.

5.9. Método de cálculo de rutas

En función de cómo y dónde se calcula una ruta, se definen dos categorías de protocolos de

encaminamiento para redes ad hoc. El cálculo de rutas puede realizarse en cada nodo de manera

independiente o bien puede llevarse a cabo de forma cooperativa entre varios nodos.

Cálculo descentralizado. Cada nodo mantiene información global y completa sobre la

topología de la red, siendo capaz de computar una ruta hacia cualquier nodo destino cuando lo

desee.

Cálculo distribuido. Cada nodo de la red mantiene sólo información local sobre la topología de

la red. Cuando un nodo necesita descubrir el camino hacia un destino, varios nodos deben

colaborar para calcular la ruta.

Estudio comparativo 6.

Con el fin de ofrecer una perspectiva global sobre el panorama actual de los protocolos de

encaminamiento para redes ad hoc, se ha elaborado un estudio comparativo de los protocolos más

representativos. Para la confección de esta revisión, se ha seguido el siguiente procedimiento:

1. Elección de los protocolos bajo análisis. La elección de los protocolos bajo estudio se ha


determinado en función de su popularidad, escogiendo aquellos que aparecen en todas o la

mayoría de las fuentes consultadas.

2. Revisión de documentos. Se han examinado los artículos y publicaciones originales en los que

se describen los protocolos elegidos, así como otras referencias adicionales.

3. Elaboración de la información extraída. Se han elaborado las Tabla 2 y Tabla 3 con el fin de

mostrar de manera resumida y estructurada la información obtenida.

Existe un gran número de protocolos para redes ad hoc inalámbricas. Esa variedad se debe a que cada

protocolo posee ciertas particularidades que lo hacen apropiado para cubrir las necesidades de los

diferentes escenarios y condiciones de tráfico que se pueden dar en este tipo de redes. En este estudio

se comparan los protocolos de encaminamiento para redes ad hoc escogidos atendiendo a esas

características distintivas, construyendo para ello las Tabla 2 y Tabla 3. La primera de ellas reúne los

protocolos proactivos elegidos, la segunda concentra los protocolos reactivos. Las ocho primeras filas

definen cada protocolo según la clasificación recogida en 5. Las tres filas siguientes señalan para qué

tipo de red está indicado cada protocolo, considerando conceptos como la escalabilidad, mencionada

anteriormente, y que se define como la propiedad de los protocolos a adaptarse al crecimiento de la

red. Las tres filas posteriores hacen alusión a qué información se almacena, se envía y se recibe. El

término altura de los vecinos se refiere a la estructura de datos que se intercambia en los algoritmos

de IE. Las cuatro filas siguientes se refieren a términos relacionados con la complejidad, el uso de

ancho de banda y la longitud de los mensajes de control. La complejidad de almacenamiento se

define como el tamaño de almacenamiento que cada nodo necesita para mantener la información

necesaria. La complejidad temporal es el número de pasos necesarios para realizar una operación del

protocolo. Por último, el consumo de ancho de banda depende del número de mensajes necesarios

para realizar una operación del protocolo. Todos estos parámetros están expresados en notación de

Landau. La notación de Landau, denotada por O(), permite describir el comportamiento asintótico de

una función cuando su argumento tiende a un valor particular o a infinito, generalmente en términos

de funciones más simples. La notación de Landau permite expresar funciones de manera simplificada,

prestando atención sólo a su tasa de crecimiento, de tal forma que diferentes funciones se pueden

representar bajo la misma notación si su tasa de crecimiento es idéntica. Formalmente, la notación de

Landau se define a partir de dos funciones reales, f(x) y O (g(x)), de tal manera que: f(x) = O(g(x))

cuando x → ∞. Los símbolos empleados en esta notación asintótica se presentan a continuación:

N: Número de nodos en la red.

M: Número medio de nodos en la agrupación o cluster.

A: Grado de un nodo, esto es, número de nodos adyacentes o primeros vecinos.

/A: Grado medio de un nodo.

D: Diámetro de la red.

: Número máximo de destinos deseados en el caso de protocolos que buscan múltiples caminos.

W: Diámetro del camino por el que se transmite el paquete de respuesta.

Y: Número total de nodos que forman el camino por donde se transmite el paquete de respuesta.

Seguidamente, se presentan otros parámetros que no son agrupables bajo ninguna categoría y cuyo


significado conviene aclarar. En los protocolos con encaminamiento en origen, se indica el camino

completo en la cabecera de los paquetes de control, de tal modo que los nodos intermedios sólo se

limitan a reenviarla. La reconfiguración de rutas apunta a la capacidad del protocolo para actuar ante

fallos de enlace.

Los mensajes hello, también denominados mensajes beacon, son aquéllos mensajes que los nodos

intercambian para informar de su presencia en la red. El parámetro de calidad de servicio se refiere a si

el protocolo dispone o puede incorporar mecanismos para garantizar una tasa de de bit constante que

haga posible el intercambio de tráfico multimedia. Por su parte, la existencia de un único punto de

fallo alude a la vulnerabilidad del protocolo, de tal modo que si falla un nodo, todos los demás se ven

perjudicados. Para finalizar, se incluye el acrónimo del protocolo antecesor, de quien hereda las

características más significativas, el año de aparición de la primera propuesta, y las referencias

originales y complementarias que han servido de referencia para este estudio.

Eficiencia de encaminamiento 7.

Medir las prestaciones de un protocolo de encaminamiento para redes ad hoc no es una tarea trivial

puesto que es necesario seleccionar aquellas variables que evalúan cualitativa y cuantivamente sus

bondades. No obstante, el Grupo de Trabajo en Ingeniería de Internet, IETF, ofrece en su documento

una lista de métricas cuantitativas que pueden ser empleadas para valorar las prestaciones de

cualquier protocolo de encaminamiento:

Throughput y retardo. Esta métrica se basa en medir la efectividad de encaminamiento de

datos desde una perspectiva externa, realizando medidas estadísticas tales como media o

varianza.

Tiempo de adquisión de rutas. Esta medida calcula el tiempo necesario para establecer una

ruta desde que se solicite, por lo que sólo tiene sentido en protocolos en los que el

procedimiento de descubrimiento de rutas se realiza bajo demanda.

Porcentaje de entregas desordenadas. Se trata de otra medida externa que mide el

rendimiento del encaminamiento cuando algunas de las conexiones no están operativas. Es

especialmente relevante desde el punto de vista de la capa de transporte.

Eficiencia. Si la efectividad de encaminamiento de datos es la medida externa del rendimiento

de una política de encaminamiento, la eficiencia es su medida interna.

A su vez, para evaluar estas prestaciones, no ha de olvidarse el contexto de red en el que trabaja el

protocolo de encaminamiento bajo estudio. Los parámetros esenciales que definen un contexto de

red incluyen:

Tamaño de la red. Medido en número de nodos.

Conectividad de la red. Grado medio de un nodo.

Tasa de cambio en la topología. Velocidad a la que varía la topología de la red.

Capacidad de los enlaces. Velocidad efectiva del enlace medida [bits/segundo].

Fracción de enlaces unidireccionales. Cómo responde el protocolo cuando un porcentaje de

los enlaces trabaja solamente en una dirección.


Patrones de tráfico. Cómo se adapta el protocolo cuando el patrón no es uniforme.

Movilidad. Cuándo y bajo qué circunstancias la correlación temporal y espacial afecta al

rendimiento de un protocolo de encaminamiento.

Porcentaje y fracción de nodos no operativos. Cómo responde el protocolo en presencia de

nodos que dejan de estar activos o vuelven a estarlo tras un periodo de inactividad.

Protocolo DSDV CGSR WRP GSR OLSR FSR HSR

Nombre Destinati

on-

Sequence

d

Distance-

Vector

Routing

Protocol

Cluster-

Head

Gatewa

y Switch

Routing

Protocol

Wireless

Routing

Protocol

Global

State

routing

Protocol

Optimized

Link State

Routing

Protocol

Fisheye State

Routing

Protocol

Hierarchi

cal State

Routing

Protocol

Planificación Proactivo Proactiv

o

Proactivo Proactivo Proactivo Proactivo Proactivo

Modelo de

información

de estado

VD VD VD EE EE EE EE

Modelo de

transmisión

Broadcas

t

Broadca

st

Broadcast Broadcast Broadcast Broadcast Broadcas

t

Direccionami

ento

Plano Jerárqui

co

Plano Plano Plano Plano Jerárquic

o

Estructura Uniforme No

uniform

e

Uniforme Uniforme No

uniforme

No uniforme No

uniforme

Modelo de

comunicación

Monocan

al

Multican

al

Monocanal Monocanal Monocanal Mono/Multic

anal

Monoca

nal

Periodo de

actualizacion

es

Híbrido Periódic

o

Híbrido Periódico Híbrido Periódico con

diferentes

frecuencias

Híbrido

Número de

caminos

buscados

Único Único Único Único/Múlt

iple

Único/Múlt

iple

Único/Múltipl

e

Único


Adecuación

para redes

altamente

dinámicas

No No No Sí Sí Sí Sí

Adecuación

para redes

densas y

extensas

No Sí No Sí Sí Sí Sí

Escalabilidad Media Muy

buena

Limitada Buena Buena Muy mala Buena

Información

almacenada

VD VD,

tabla

miembr

os de la

agrupaci

ón

Tabla

distancias,tab

la de

encaminamie

nto, coste del

enlace, MRL

Topología

completa

Topología

completa

Topología

completa

Topologí

a

jerárquic

a

Información

de las

actualizacion

es

VD VD,

tabla

miembr

os de la

agrupaci

ón

VD, lista de

respuestas

EE de todos

los estados

EE de los

vecinos

EE del

alcance de

fisheye

EE virtual

Destinatarios

de las

actualizacion

es

Vecinos Vecinos

y nodo

principal

Vecinos Vecinos Todos Vecinos Nodos

de la

agrupaci

ón

Complejidad

de

almacenamie

nto

O(N) O(2N) O(N × /A) O(N × /A) O(N × /A) O(N × /A) O(N ×

)

Complejidad

temporal

O(D) O(D) O(D) O(D) O(D) O(D) O(D)

Consumo de

ancho de

banda

O(N) O(N) O(N) O(N) O(N) O(N) O(N)

Tamaño del

paquete de

control

O(N) O(N) O(N × /A) O(N) O(N) Determinado

por el

protocolo

O(M)

Encaminamie

nto en origen

No No - No

generalmen

No

generalmen

No

generalment

No


te te e

Reconfiguraci

ón de rutas

No aplica No

aplica

No aplica No aplica No aplica No aplica No aplica

Necesidad de

mensaje hello

No No Sí No No No No

Calidad de

servicio

No Sí No Sí Sí Sí Sí

Único punto

de fallo

No Sí No No No No Sí

Antecesor DBF DSDV DBF - - GSR -

Año de la

primera

propuesta

1994 1997 1995 1998 1998 2000 1999

Tabla 2 Estudio comparativo de los protocolos de encaminamiento ad hoc proactivos


Protocolo DSR AODV TORA ABR SSA

Nombre Dynamic

Source

Routing

Ad hoc On

Demand

Distance

Vector

Protocol

Temporally-

Ordered Routing

Algorithm

Routing Protocol

Associativity-

Based Routing

Protocol

Signal Stability-

based

Adaptative

Routing

Protocol

Planificación Reactivo Reactivo Reactivo Reactivo Reactivo

Modelo de

información de

estado

EE VD IE EE asociativo EE a nivel 2

Modelo de

transmisión

Unicast Unicast

/Broadcast

Broadcast Unicast

/Broadcast

Unicast

Direccionamiento Plano Plano Plano Plano Plano

Estructura Uniforme Uniforme Uniforme Uniforme Uniforme

Modelo de

comunicación

Monocanal Monocanal Monocanal Monocanal Monocanal

Modos de

actualización

Dirigido por

eventos

Dirigido por

eventos

Dirigido por

eventos

Híbrido Híbrido

Número de caminos

buscados

Múltiples Múltiples Múltiples-DAG Único Único

Adecuación para

redes altamente

dinámicas

No Sí Media Sí Sí

Adecuación para

redes densas y

extensas

No Sí Media Media Sí

Escalabilidad Media Buena Muy buena Buena Muy buena

Información

almacenada

Rutas al

destino

deseado

Próximo salto

al destino

deseado

Altura de los

vecinos

Información

asociativa de

los vecinos

Estabilidad de

la señal, tabla

de rutas

Información de las

actualizaciones

Error de ruta Error de ruta Altura de los

nodos

Información

vecinos o error

de ruta

Error de ruta

Destinatarios de las

actualizaciones

Origen Origen Vecinos Vecinos/

Origen

Origen

Complejidad de O(D) O( ) O( × /A) O(D × /A) O(D × /A)


almacenamiento

Complejidad

temporal

O(2D) O(2D) O(2D) O(D+W) O(D+W)

Consumo de ancho

de banda

O(2N) O(2N) O(2N) O(N+Y) O(N+Y)

Tamaño del paquete

de control

O(D) O( ) O(1) O(D) O(1)

Encaminamiento en

origen

Sí No No Sí No

Reconfiguración de

rutas

Si borrado de

rutas, notificar

a la fuente

Si borrado de

rutas, notificar

a la fuente

Si inversión de

enlace,

reparación de

enlace

Solicitud de

broadcast local

Si borrado de

rutas, notificar

a la fuente

Necesidad de

mensaje hello

No Sí No Sí Sí

Calidad de servicio Sí Sí Sí Sí Sí

Único punto de fallo No No No No No

Antecesor - DSDV LMR - -

Año de la primera

propuesta

1996 1999 2001 1996 1996

Tabla 3 Estudio comparativo de los protocolos de encaminamiento ad hoc reactivos


2. REDES VANET

Introducción 1.

Las redes VANETs son un caso particular de las redes ad-hoc (Mobile Ad- hoc Network (MANET))

enfocadas a entornos vehiculares. Se trata de un conjunto de nodos que se comunican entre sí

mediante enlaces inalámbricos sin la necesidad de una infraestructura de red fija. Cada nodo actúa

como router y tiene capacidades de encaminamiento para redirigir paquetes hacía su destino.

Características 2.Veamos a continuación el conjunto de características que definen estas redes:

Autonomía. Cada nodo es un nodo autónomo con capacidad de procesado de 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 los nodos de la red siendo así más tolerante a fallos.

Encaminamiento distribuido. De la misma manera que son autónomos, los nodos deben ser

capaces de encaminar información, deben tener capacidades de router. Por lo tanto, es

necesario definir nuevos protocolos de encaminamiento capaces de soportar esa

característica.

Topología de red variable. En una MANET los nodos se pueden mover de forma arbitraria. Esa

característica se debe matizar en el caso de las VANETs ya que los vehículos suelen seguir un

cierto patrón de movimiento, por ejemplo siguiendo las curvas de un circuito urbano. 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 y minimicen sus efectos.

Capacidad variable de los enlaces. Esta característica tiene cabida en todas las comunicaciones

inalámbricas, pues es intrínseca al medio de transmisión pero sus efectos se agravan más en

las VANETs. Esto se debe a que cada nodo actúa como router y la información atraviesa

múltiples enlaces inalámbricos.

Terminales limitados. En la mayoría de los casos los nodos de este tipo de redes serán

terminales ligeros embarcados en vehículos con capacidades limitadas de procesamiento,

comunicación y alimentación por lo que es primordial que los algoritmos utilizados optimicen

estos tres recursos.


Tecnologías inalámbricas usadas en redes VANETS 3.En este aparto se detallan tecnologías inalámbricas susceptibles de dar soporte a redes VANETs.

3.1. Tecnología IEEE 802.11

Más conocida como WiFi, se basa en el estándar IEEE 802.11. Opera en bandas libres. Las versiones b y

g se han extendido mucho hasta el punto de que la mayoría de los equipos portátiles y PDAs la traen

incorporada de serie. Tiene un alcance de unos centenares de metros y un ancho de banda de hasta

54 Mbps, dependiendo de la versión del estándar. La nueva versión, 802.11n pretende aumentar las

tasas de transferencia hasta un 500Mps. La seguridad forma parte de los protocolos desde el principio

y fue mejorada en la revisión 802.11i

3.2. 802.11a

Este estándar fue aprobado por la IEEE al mismo tiempo que el estándar 802.11b. El estándar 802.11a

opera en la banda de 5Ghz y su velocidad máxima de transmisión es de 54 Mbps. No puede

interoperar con equipos del estándar 802.11b, excepto si se dispone de equipos que implementen

ambos estándares.

Dado que la banda de 2,4 GHz es utilizada por dispositivos electrónicos como microondas, teléfonos

inalámbricos y otros equipos, el utilizar la banda de 5 GHz representa una ventaja del estándar

802.11a, dado que se presentan menos interferencias. Sin embargo, la utilización de esta banda

también tienen sus desventajas, dado que restringe el uso de los equipos 802.11a a únicamente

puntos en línea de vista, se hace necesario la instalación de un mayor número de puntos de acceso.

Esto significa también que los equipos que trabajan con este estándar no pueden penetrar tan lejos

como los del estándar 802.11b dado que sus ondas son más fácilmente absorbidas.

3.3. 802.11p

También conocida como Wireless Access for the Vehicular Environment (WAVE), está en proceso de

estandarización y será la encargada en un futuro de soportar las comunicaciones vehiculares. WAVE es

una evolución del estándar IEEE 802.11a con modificaciones a nivel físico y MAC para mejorar su

comportamiento en el entorno vehicular y dar soporte a sistemas de transporte inteligente (Itelligent

Transportation Systems (ITS)). Asimismo, WAVE será la base sobre la que se desarrollará el DSRC

(Dedicated Short Range Communications), otro proyecto de estandarización impulsado por el

ministerio de transporte de EEUU y por un número importante de fabricantes de la industria del

automóvil, cuyo objetivo es crear una red nacional de comunicaciones vehiculares. El propósito del

proyecto es definir un estándar para las comunicaciones V2V y las comunicaciones con la

infraestructura vial (V2I) que se puede instalar en semáforos o paneles de información, por ejemplo.

WAVE pretende aumentar las tasas de trasferencia a corto alcance, típicamente entre 100 y 500m. La

técnica de modulación se basa en IEEE802.11a, utilizando OFDM pero con tasas de transmisión de 3,

4.5, 6, 9, 12, 18, 24 y 27 Mbps en canales de 10MHz. Utiliza 52 sub-portadas moduladas utilizando

BPSK, QPSK, 16-QAM, o 64-QAM. En cuanto a la canalización, 7 canales no solapados de 10MHz en la

banda de 5.9 GHz: 6 canales de servicio (SCH) y uno de control (CCH). El CCH está utilizado como canal

de referencia para realizar una primera detección de los vehículos cercanos como paso previo al

establecimiento de las comunicaciones. Al mismo tiempo, dicho canal se usa para anunciar los


servicios disponibles en canales SCH (acceso a Internet, descarga de contenidos..etc.) El canal CCH se

usa para la transmisión en modo broadcast de mensajes de seguridad vial. Este contenido es

prioritario sobre los demás y se transmite en el canal CCH con una tasa de datos de 6Mbps,

correspondiente a una modulación QPSK. En la capa MAC, WAVE se basa en las de niciones del

IEEE802.11 usando una técnica de acceso basada en CSMA/CA. Sin embargo, CSMA/CA no logra

solucionar el problema del terminal escondido.

Ilustración 2 Problema del terminal escondido

Como se puede observar en la Ilustración 2, la estación 1 y la estación 3 intentan mandar tráfico al

mismo instante a la estación 2, ya que no se escuchan, no tienen alcance la una a la otra. Se produce

entonces colisiones de paquetes. El problema del terminal escondido surge siempre cuando dos nodos

se hallan fuera del alcance radio entre ellos e intentan mandar información a un mismo nodo en un

mismo instante. Para tratar ese problema se implementa un mecanismo de intercambio de mensajes

RTS/CTS. Antes de mandar datos, la estación 1 manda una trama RTS al destino para indicar que desea

mandar tráfico. La estación 2 recibe el RTS e informa al resto de los nodos a su alcance que va a

reservar el canal para la comunicación con la estación 1. De esta forma la estación 3 queda informada

que tiene que esperar antes de mandar paquetes. Podrían darse casos de colisiones de paquetes RTS,

sin embargo el efecto sería reducido ya que se tratan de paquetes de pequeño tamaño (hasta 2347

octetos). Este mecanismo evita colisiones pero introduce una sobrecarga de tráfico en la red y retardo

en las transmisiones. Por esas razones, WAVE no implementa RTS/CTS en el canal CCH por transmitir

en modo broadcast. Como consecuencia, todos los nodos que utilizan el canal de control están sujetos

al problema del terminal escondido, incrementando el riesgo de pérdidas de paquetes y de congestión

del canal.

3.4. Bluetooh

También conocido como 802.15.1. Es la tecnología más extendida en cuanto a comunicaciones

inalámbricas personales (wPAN). Hay varias clases dependiendo de su alcance y consumo de potencia,

alcanzando tasas de 2Mbps y rangos de hasta 100m. Opera en banda libre y sus mecanismos de

seguridad son suficientemente robustos.

3.5. UWB

Ultra Wide Band es un estándar basado en 802.15.3 que funciona emitiendo a muy baja potencia en

un espectro enorme. Su alcance es muy limitado (<10m) pero proporciona tasas de transferencia muy

elevadas llegando a los 480 Mbps. Su consumo de energía es muy reducido.


3.6. ZigBee

Ultra Wide Band, es un estándar basado en 802.15.3 que funciona emitiendo a muy baja potencia en

un espectro enorme. Su alcance es muy limitado (<10m) pero proporciona tasas de transferencia muy

elevadas llegando a los 480 Mbps. Su consumo de energía es muy reducido.

A continuación se muestra una Tabla 4 con las características más relevantes de cada tecnología:

Tecnología Cobertura Tasas Consumo

802.11b 500m 11 Mbps Alto

802.11a 500m 54 Mbps Alto

802.11p 500m 6 Mbps Alto

802.11g 500m 54 Mbps Alto

WiMAX (802.16e) 50Km 75 Mbps Alto

Bluetooh(802.15.1) 20m 2 Mbps Medio

UWB(802.15.3) < 10m 480 Mbps Bajo

Zigbee(802.15.4) 75m 250 Kbps Muy bajo

Tabla 4 Características de las tecnologías inalámbricas consideradas

Protocolos de encaminamiento 4.

La investigación en el campo de los protocolos de encaminamiento para redes ad-hoc se ha

multiplicado estos últimos años. La movilidad de los nodos, la inestabilidad de las topologías, y la

ausencia de una infraestructura de centralización hacen obsoletos los protocolos que se usan en redes

fijas. En redes VANET, los protocolos de encaminamiento deben ser capaces de funcionar de manera

automática y distribuida.

A la hora de clasificar los protocolos de encaminamiento existen varios criterios. Se puede considerar:

El alcance: unicast, broadcast o multicast, geocast, etc.

El modo de descubrimiento de rutas: proactivo, reactivo, híbrido.

Tipo de algoritmo que implementan: vector de distancias, estado de enlace.

Todos los detalles de la clasificación anteriormente explicada aparecen en 4.

En la siguiente Tabla 5 se muestran los protocolos más representativos atendiendo a la clasificación

antes citada.


Protocolo Alcance Esquema Información geográfica

Blind Foodig Broadcast - No

MPR Broadcast - No

NES Broadcast - No

CDS Broadcast - No

DSDV Unicast Proactivo No

DSR Unicast Reactivo No

AODV Unicast Reactivo No

LAR Unicast Proactivo Sí

TORA Unicast Reactivo No

ZRP Unicast Híbrido No

FSR Unicast Proactivo No

OLSR Unicast Proactivo No

LBM Geocast Proactivo Sí

GeoTORA Geocast Reactivo Sí

GeoGRID Geocast Reactivo Sí

GAMER Geocast Proactivo Sí

Tabla 5 Características de los protocolos

En el presente documento se hará hincapié en los protocolos de encaminamiento AODV , DSR, DSDV,

OLSR, AOMDV, ZRP y DYMO y no en hacer un estudio completo de todos los protocolos pero si que

cabe destacar algunas características de ellos.

En las siguientes subsecciones se mostrarán algunos detalles de los protocolos de encaminamiento

anteriormente clasificados en base al alcance.

4.1. Protocolos Broadcasting

El broadcasting consiste en mandar tráfico desde un nodo origen a todos los nodos presentes en la red

usando la técnica de múltiples saltos.

4.1.1. Blind Flooding

A la recepción de un mensaje, un nodo lo reenvía a todos sus vecinos. La única optimización que

presenta este protocolo es que cada nodo recuerda los paquetes flooding que ha recibido y si le


vuelven a llegar no los retransmite evitando así duplicidades. Aunque sea muy simple de implementar,

el Blind Flooding introduce mensajes redundantes y colisiones a nivel MAC que empeoran el

rendimiento de la red.

4.1.2. Multi-point Relay Flooding (MPR)

Consiste en elegir un conjunto de nodos vecinos que cubre el acceso a los nodos distantes de 2 saltos.

Los nodos de ese conjunto reenvían el tráfico, los demás no. Esa mejora permite dividir por 2 el

número de mensajes de control.

4.1.3. Neighbor Elimination Scheme (NES)

Un nodo que recibe un mensaje de broadcast no retransmite directamente sino que espera un tiempo

aleatorio para ver si otro nodo manda la información. Los nodos escuchan los mensajes y apuntan que

nodos ha mandado información a cual otro. Después del tiempo de espera, el nodo manda el tráfico a

sus vecinos que no han sido informados por otros nodos. En la Ilustración 3 se puede ver como B

después de un tiempo de espera se da cuenta de que no es necesario mandar tráfico a ningún nodo.

Ilustración 3 Mecanismo NES

4.1.4. Connected Dominating Sets (CDS)

La idea de este mecanismo es organizar los nodos de la VANETs en una jerarquía. Se hace una

clasificación de los nodos en dos categorías: los nodos dominantes y los nodos pasivos. Los nodos

dominantes son elegidos de manera que cubran la totalidad de la red en sus retransmisiones. Existen

varias formas de construir la jerarquía dentro de la red. La más simple y conocida es la siguiente; Se

asigna una prioridad a cada nodo. Un nodo es pasivo si dentro de sus vecinos directos existe un nodo

de prioridad superior que ya cubre el vecindario. Si no es el caso, el nodo es dominante. La asignación

de prioridades a los nodos es un mecanismo complicado que usa algoritmos matemáticos complejos

que no vamos a detallar aquí. A la recepción de un mensaje broadcast un nodo retransmite ese

mensaje solo si se trata de un nodo dominante.


Ilustración 4 Mecanismo CDS

4.2. Protocolos Unicast

En este subapartado también se enmarcan los protocolos DSR y AODV pero que se explicarán en

apartados posteriores por su relevancia dentro de este trabajo.

4.2.1. LAR

Es un protocolo proactivo que introduce la idea de enrutamiento geográfico para disminuir la

sobrecarga en el descubrimiento de rutas. Esa información geográfica puede ser obtenida usando un

sistema de posicionamiento global (GPS, Galileo...), lo que limita el espacio de búsqueda y una

diminución de la cantidad de mensajes intercambiados y por lo tanto un incremento del rendimiento

de la red.

El algoritmo introduce dos conceptos innovadores: el de “Expected Zone" (EZ) y el de “Request Zone"

(RZ). El protocolo usa el mismo mecanismo de descubrimiento de rutas en cuanto a los mensajes

intercambiados que otros algoritmos como AODV o DSDV. La diferencia esencial es que esos mensajes

no se mandan a todos los vecinos, sino que a partir de la información geográfica, se consigue una

inundación controlada de la red. Un nodo origen S que quiere descubrir una ruta hacia un destino D,

calcula una EZ que corresponde a una previsión de la posición de D. Esa previsión se calcula como una

aproximación. S gracias a un sistema como GPS sabe que a un momento el nodo D está en una

posición L y que se mueve a una velocidad media . Por lo tanto, S asume que D al instante se

encuentra en la EZ delimitada por el círculo de rayo y de centro L. Si además se sabe que D

se mueve hacia el norte podemos restringir la EZ al semicírculo como se muestra en la Ilustración 5.


Ilustración 5 Ejemplo de Expected zone

El segundo concepto es el de “Request Zone” (RZ). Corresponde a la zona a la cual se restringe el

flooding de descubrimiento de rutas. Para que un mensaje de descubrimiento se mande a un nodo,

ese nodo tiene que estar en la RZ. Para aumentar la probabilidad de alcance a D, se han definido reglas

de definición de la RZ:

La RZ debe incluir al nodo origen S, a la EZ y a la región que la rodea.

Si se elige una RZ muy pequeña puede ocurrir que todas las rutas de S hacia D queden fuera y

que el proceso de descubrimiento de rutas se vea afectado de mayor retraso.

Si se elige una RZ demasiado grande, el mecanismo de rutas puede ser muy costoso e

introducir overhead innecesario.

A la luz de esas consideraciones, se ve claramente que existe un compromiso entre la latencia en la

determinación de una ruta y la sobrecarga de mensajes diseminados. Uno de los esquemas

propuestos es establecer una RZ rectangular, de tal forma que el rectángulo sea el mínimo que

contenga a la EZ y al nodo origen ubicado en las coordenadas ( ; ). El nodo origen puede estar

tanto fuera como dentro de la EZ, no influye en el mecanismo. En la Ilustración 6, se ven dos nodos J e

I, vecinos de S; si el RREQ le llegara a I, éste lo retransmitirá a sus vecinos ya que pertenece a la RZ

mientras que si el nodo J, que queda fuera de la RZ, recibe un RREQ, lo rechazará.


Ilustración 6 LAR con nodo origen fuera de la RZ

4.2.2. TORA

Es un protocolo reactivo basado en el concepto de “Links Reversal”. Fue propuesto para mejorar las

prestaciones en redes altamente dinámicas. La idea básica es la generación de mensajes de control del

protocolo en un pequeño conjunto de nodos cerca de la localización de un cambio topológico. El

protocolo desarrolla tres funciones básicas: la creación de rutas, el mantenimiento y su eliminación.

La fase de creación corresponde a la selección de una métrica para establecer un DAG hacia el destino.

El DAG consiste en asignar una dirección a los enlaces basada en las alturas relativas de los nodos

vecinos. El nodo origen tiene la altura mayor y el nodo destino la menor. La fase de descubrimiento de

rutas es similar a los expuestos anteriormente.

El mantenimiento de rutas se refiere al hecho de adaptar la estructura de encaminamiento en

repuestas a los cambios topológicos de la red. Cuando un enlace no está disponible, el DAG se rompe y

es necesaria una reparación de la ruta para restablecerlo. El nodo que detecta el fallo en el enlace

genera para sus vecinos un mensaje con un nuevo nivel de referencia. Los nodos reaccionan a esa

información invirtiendo los enlaces hacia el nodo. Haciendo una inversión del sentido de los enlaces,

hace que un nodo no contenga el destino y por lo cual la ruta será eliminada. La fase de eliminación de

rutas involucra un broadcast de “clear packet” para eliminar las rutas que no contienen la ruta hacia

un destino. TORA elimina las rutas inválidas, busca una nueva alternativa para un destino, y construye

otra ruta en un sólo paso del algoritmo. En cambio, ese mecanismo en AODV o DSR corresponde a tres

pasos (route error / route request / route reply).


Ilustración 7 Esquema funcionamiento TORA

4.2.3. FSR

Es un protocolo proactivo basado en el concepto de estado de enlaces. El “Ojo de un pez” es un

mecanismo mediante el cual se captura con detalle los píxeles que se encuentran cerca del punto de

focal. El detalle disminuye a medida que se aumenta la distancia al punto focal. FSR se basa en una

analogía de ese algoritmo. Mantiene distancias exactas y alta calidad de la información relativa a los

nodos los más cercanos y pierde progresivamente detalles a medida que la distancia al nodo aumenta.

FSR, de manera similar al algoritmo de estado de enlace manda mensajes de información de forma

periódica o seguida a un evento de ruptura de enlace. Sin embargo, los mensajes no inundan la red

sino que se intercambian únicamente entre vecinos locales. En la implementación de este protocolo,

cada nodo almacena:

Lista de vecinos

Tabla con la topología (TT)

Tabla con el próximo salto de la ruta

Tabla de distancia al destino

En redes grandes, el tamaño de los mensajes intercambiados puede ser muy grande y el consumo de

banda ancha importante. Por esas razones FSR utiliza diferentes frecuencias para el envío de esos

mensajes. Las entradas correspondientes a nodos más cercanos son propagadas con una frecuencia

más alta. Mediante esa técnica, FSR funciona bien en redes de gran tamaño y mantiene el overhead

bajo sin comprometer la exactitud de la computación de rutas cuando el destino está cerca. Cuando la

movilidad de los nodos aumenta, las rutas hacia los destinos remotos se hacen menos exactas. Sin

embargo, cuando un paquete se acerca a su destino, encuentra información de encaminamiento más

exacta. Como resultado, FSR es más útil para redes de gran tamaño donde la movilidad es alta y el

ancho de banda bajo


4.3. Protocolos Geocast

Aunque los protocolos geocast sean un caso particular de los multicast es interesante detallar algunos

de ellos debido al hecho de que son muy usados en redes VANETs. Los protocolos geocast son

protocolos multicast dónde los grupos están organizados en función de la posición geográfica de los

nodos de la red. Se usan protocolos geocast cuando se desea mandar un mensaje a un grupo de

vehículos de una determinada zona, para anunciar por ejemplo la presencia de un peligro en la

carretera.

4.3.1. LBM

Es un protocolo orientado a la transmisión de datos que se basa en el protocolo unicast LAR, expuesto

anteriormente. LBM se basa en un flooding tradicional salvo que los nodos tienen que decidir si

retransmiten o no a los demás nodos según dos esquemas:

LBM box

LBM step

Ilustración 8 Esquema LBM box

Si el esquema considerado es LBM box, un nodo, a la recepción de un paquete geocast retransmite a

los nodos que se encuentran el zona de forwarding, sino no reenvía el paquete. Según ese esquema la

zona de forwarding es el rectángulo mínimo que engloba el origen del paquete geocast y la zona

geocast, como se puede apreciar en la Ilustración 8.

En cambio, en el esquema de LBM step se usa otra forma para determinar la zona de forwarding. Si A

recibe un paquete geocast de un nodo B, A retransmite el paquete si está más cerca del centro de la

zona geocast que B de por lo menos una distancia δ. Este mecanismo se ilustra en la Ilustración 9.

Consideramos que δ = 0. B reenviará el paquete recibido de A ya que distA > distB, dónde distX es la

distancia del nodo X al centro de la zona geocast. Sin embargo, K descartará el paquete de B por estar

más lejos del centro de la zona geocast. Resumiendo, este protocolo asegura que en cada

retransmisión el paquete se acerca más a la zona geocast.


Ilustración 9 Esquema LBM step

4.3.2. GEOTORA

Como su propio nombre lo indica deriva directamente del algoritmo unicast TORA. Se construyó de la

siguiente manera: se modificó TORA para hacer un protocolo anycast, modificando este protocolo

anycast se consiguió un protocolo multicast. Veamos primero como funciona el algoritmo anycast.

En la versión unicast de TORA se asigna un DAG para cada nodo de la red. En cambio, en la versión

anycast se asigna un DAG para todo el grupo anycast. Así se consigue que todos los nodos del grupo

sean destino. En este caso, los enlaces entre nodos del grupo no tienen dirección ya que no nos

interesa realizar encaminamiento dentro del grupo anycast, basta con alcanzar un nodo del grupo

anycast.

El protocolo GEOTORA solo presenta una pequeña variación respeto a la versión anycast de TORA. Se

mantiene un único DAG para todo el grupo geocast, logrando que cualquiera de los nodos presentes

en la zona geocast sea destino. Primero, el protocolo realiza un anycast hacia un nodo de la zona

geocast. A la recepción de un paquete de anycast, el nodo se encarga de retransmitir en modo

flooding a todos los nodos de su zona geocast. Veamos un ejemplo con la Ilustración 10. Si el nodo E

quiere mandar paquetes a una zona geocast, reenvía el paquete por el enlace (E,G) al nodo G. A su vez

el nodo G lo reenvía al nodo A, como este ya pertenece a la zona geocast, inicia el flooding limitado.

Los nodos B y C al recibir el paquete de A reenvían el paquete a sus vecinos. Cuando el nodo A recibe

el paquete de B o C no reenvía el paquete ya que lo ha hecho previamente. De esta manera el paquete

llega a todos los nodos de la región geocast.


Ilustración 10 Funcionamiento de GEOTORA

4.3.3. GEOGRID

Es un protocolo geocast derivado del unicast GRID. Al igual que GRID, GEOGRID realiza una partición

del área geográfica que ocupa la red en celdas de dos dimensiones. Cada celda es un cuadrado de

dimensiones . La zona de forwarding está definida por los nodos origenes y la zona geocast, de

forma similar a la versión box de LBM. En cada celda, se elige un nodo gateway. La diferencia principal

entre LBM y GEOGRID es que sólo los nodos gateways tienen la responsabilidad de transmitir los

paquetes geocast. Existen dos versiones de GEOGRID: la versión basada en ding y la versión basada en

tickets.

En la versión basada en flooding, sólo los nodos gateways de la zona de forwarding transmiten los

paquetes geocast. En la versión basada en tickets del protocolo, sigue siendo verdad que sólo los

gateways retransmiten pero no todos. El origen distribuye tickets para una zona geocast de

celdas a los nodos gateways de la zona de forwarding que están más cerca de la zona

geocast. El gateway que recibe X tickets sigue el mismo método de distribución que el origen. En la

Ilustración 11 vemos que el nodo origen genera 5 tickets, 2 los entrega a A, 2 a B y 1 a C, que son los

gateways más cercanos a la zona de geocast.


Ilustración 11 Esquema GEOGRID

Cada gateway transmite paquetes GATE que indica su naturaleza de gateway al resto de la red. Un

nodo que quiere mandar tráfico geocast y que no tiene conocimiento de un gateway en su celda,

manda un paquete BID para ofrecerse como gateway para esa celda. Un nodo que recibe un BID y que

está más cerca del centro de la zona geocast manda a su vez un BID. El nodo que transmite el último

BID (2 ms sin recepción de BID) en la celda se considera gateway para esa celda. Otra opción para

elegir el gateway es elegir múltiples gateways temporales dentro de la misma celda. En esta situación

si un gateway recibe un paquete de otro gateway más cercano al centro deja de ser gateway

automáticamente sin enviar ningún mensaje de control explícito. Otra manera efectiva de elegir

gateway se basa en el concepto de pesos, por ejemplo asignando a cada nodo un peso inversamente

proporcional a su velocidad.

Además, cada gateway evalua cada 300 ms si ha quitado la celda. Si es el caso, el nodo manda un

paquete RETIRE que inicia un nuevo proceso de elección de gateway en la celda.

4.3.4. GAMER

Es un protocolo geocast que se basa en la idea de crear rutas redundantes desde el origen hacia una

zona geocast. Esa idea proviene de la constatación que una sóla ruta hacia la zona geocast es frágil

sobre todo en un entorno de movilidad muy alta, como es el entorno vehícular. Por eso, GAMER

propone rutas redundantes basadas en mallas hacia una zona geocast.

Un nodo que desea transmitir un paquete geocast, primero manda mediante un flooding un paquete

de JOIN-DEMAND. El flooding sigue en la zona de forwarding hasta alcanzar un nodo de la zona

geocast. El nodo alcanzado de la zona geocast manda en sentido inverso unicast hacia el origen un

paquete JOIN-TABLE. Cuando el nodo origen recibe la respuesta JOIN-TABLE puede empezar a mandar

paquetes geocast a través de las mallas de la red.

GAMER se adapta de forma dinámica a la topología de red cambiando el tamaño de la zona de

forwarding, lo que cambia la densidad de las mallas en tiempo real. Como consecuencia, cuando los

nodos son de movilidad alta una malla densa se crea. En cambio, cuando baja la movilidad, la malla se

hace menos densa. GAMER puede elegir entre tres esquemas de zonas de forwarding: CONE,

CORRIDOR y FLOOD.


Ilustración 12 Zona de forwarding GAMER

Los autores de GAMER proponen dos versiones del protocolo: una activa y otra pasiva. En la versión

pasiva, se manda un paquete de JOIN-DEMAND a intervalos regulares sin consideración de si se ha

recibido o no un JOINTABLE. En su versión activa GAMER establece igualmente un intervalo para

mandar JOIN-DEMAND a la diferencia de que se adapta a los eventos de recepción de JOIN-TABLE. Si

no se ha recibido un paquete JOIN-TABLE después de un tiempo conocido como SWITCH-TIMER se

intensifica la frecuencia de envío de JOIN-DEMAND.

Seguridad 5.Los requisitos de seguridad en una VANET son los mismos que en una red tradicional, es decir:

Confidencialidad: La información sólo debe ser legible por los autorizados.

Integridad: La información sólo puede ser modificada por los autorizados.

Disponibilidad: El sistema debe ser disponible cuando se necesita.

No repudio: No se puede negar la autoría.

Sin embargo, todas las características de las VANETs que hemos descrito anteriormente (topología

dinámica, falta de un procesamiento centralizado...etc.) hacen que sea mucho más difícil cumplir estos

requisitos de seguridad. La política de seguridad a aplicar en un entorno ad-hoc dependerá, en gran

media, de la aplicación y del escenario concreto para los que se realiza el despliegue de la red.

Las propuestas de seguridad se centran en aspectos concretos del problema. Se identifican cuatro

aspectos clave que deberán ser cubiertos por cualquier política de seguridad en redes ad-hoc: control

de acceso, sistema de detección de intrusos (SDI), seguridad de los protocolos de encaminamiento y

servicios de gestión de claves.

5.1. Ataques en redes Vanets

Ataques básicos:

Falsificación de la información: El atacante difunde información falsa o errónea para que afecte

al resto de los vehículos.

Manipulación de la información del sensor: Modificar su posición, dirección, velocidad, etc.

Para escapar de ciertas responsabilidades por ejemplo al haber provocado un accidente.

Denegación de servicio: utilizar un inhibidor de frecuencia para conseguir que un vehículo no

reciba ninguna señal de su entorno en una cierta zona.


Falsificación de identidad.

Rastreado de vehículos: Seguir la pista de un vehículo infectándolo con algún virus que

monitorice el estado de dicho vehículo.

5.2. Control de acceso

Como en las redes tradicionales, las VANETs necesitan un mecanismo que controle el acceso tanto a la

red como a los servicios que provee. Las consecuencias de un ataque en el cual un intruso tendría

acceso a los servicios de la red pueden ser catastróficas ya que en las VANETs los nodos asumen tareas

de gestión y de encaminamiento al no tener una unidad de centralización. Un intruso podría desviar el

tráfico durante el encaminamiento o tener acceso a claves de identificación.

En la capa de red, es necesario garantizar que ningún nodo no autorizado se una a la red bien para

recibir información o para encaminarla. Así mismo a nivel de aplicación también es imprescindible

asegurarse que elementos sin autorización no acceden a servicios, por ejemplo al servicio de gestión

de claves.

El control de acceso consiste generalmente en la autenticación de los usuarios de la red. Es decir para

acceder a la red y a sus servicios, un usuario debe identificarse de forma unívoca y la red lo autentica

como autorizado para el acceso. En ciertas redes ad hoc los servicios se encuentran centralizados

mientras que en otras están distribuidos, este hecho hace necesario el uso de diferentes mecanismos

de control de acceso. Si elegimos un mecanismo de control de acceso distribuido para la red, será

necesario un control de acceso basado en certificados digitales y autoridades certificadoras. En otros

esquemas con servicios centralizados se requiere una autenticación basada en usuario y contraseña.

Es muy útil hacer un estudio previo de las necesidades de seguridad de la red a desplegar, de esta

forma, se podrán adecuar los mecanismos de control de acceso a la red.

5.3. Sistema de detección de intrusos

El control de acceso consiste en una primera línea de defensa para impedir el acceso a la red a

intrusos. Los sistemas de detección de intrusos (SDI) forman una segunda línea de protección muy

importante.

Existen varias propuestas de SDI para VANETs, veamos las más interesantes:

Una arquitectura distribuida y cooperativa para la detección de intrusos, en este sistema, cada

nodo ejecuta un agente SDI que monitoriza las actividades locales al nodo. Si el SDI detecta una

intrusión a partir de las trazas locales inicia un procedimiento de respuesta. Si se detecta una

anomalía pero que no hay evidencias formales de la intrusión se usa un protocolo cooperativo

con los vecinos para determinar si la intrusión tuvo lugar o no.

Un sistema distribuido basado en tecnología de agentes móviles. Un agente móvil se define

como una entidad software autónomo, ligero y dinámicamente actualizable que atraviesa la

red y se ejecuta sobre ciertos nodos. Este método es especialmente apropiado en el caso de

las VANETs, dónde los recursos como el ancho de banda de los enlaces o la capacidad de los

nodos pueden ser limitados. Las diferentes funciones del SDI se distribuyen entre diferentes

tipos de agentes de forma que la carga introducida por el SDI se reparte de forma eficiente

entre los nodos de la red.


En cualquier caso, el empleo de técnicas de SDI depende siempre de la aplicación y del escenario

concreto sobre el cual se ejecuta. Dada la sobrecarga que pueden introducir estos mecanismos, en

términos de transmisión sobre el medio inalámbrico, de procesamiento y almacenamiento en los

nodos, su uso puede resultar justificable únicamente en aplicaciones con fuertes requisitos de

seguridad y en aquellas en las que los dispositivos involucrados dispongan de suficiente capacidad y

autonomía como para que el SDI no imponga limitaciones intolerables para las prestaciones de los

servicios finales ofrecidos al usuario.

5.4. Seguridad en el encaminamiento

Los nodos en una VANETs actúan como routers, participando en el protocolo de encaminamiento para

descubrir y mantener rutas hacia otros nodos de la red. En las redes tradicionales, los routers son

administrados por operadores de confianza pero eso deja de ser cierto en las VANETs dónde cada

nodo que se une a la red participa en la toma de decisiones. Si el resultado del algoritmo de

encaminamiento es manipulado, el funcionamiento normal de la VANET puede verse seriamente

afectado. Por este motivo la seguridad en el encaminamiento es de primera importancia para la

seguridad global del sistema.

La investigación para proporcionar protocolos de encaminamiento seguros sigue hoy en día, ya se han

propuesto algunos esquemas. Se ha definido un conjunto de técnicas para diseñar algoritmos de

encaminamiento ad-hoc resistentes a intrusiones, este conjunto se llama TIARA. Varios protocolos se

basan en las técnicas TIARA como por ejemplo SRP o ARIADNE.

SRP proporciona información segura y autenticada a cada par de nodos que desea establecer una

comunicación. El establecimiento se hará bajo una asociación de seguridad entre el nodo que inicia la

comunicación y el nodo destino.

ARIADNE usa un proceso de criptografía simétrica que permite asegurar la integridad y la

autenticación en las comunicaciones del protocolo.

5.5. Cifrado y gestión de claves

El empleo de técnicas de cifrado y de firmas digitales como mecanismo de seguridad requiere el uso

de claves criptográficas, que serán compartidas por todos los nodos. Por lo tanto, se debe disponer de

un mecanismo seguro para la gestión de claves.

Se puede dividir las VANETs en dos grupos: las auto-organizadas que se gestionan de forma autónoma

y las VANETs que hacen uso de una entidad externa de confianza para la gestión de claves. En

esquemas de VANETs pura, sin red de respaldo, es más apropiado usar un esquema de gestión de

clave que no depende de ninguna entidad externa. En cambio, si se dispone de una red de respaldo, se

puede optar por esquemas de tipos centralizados. Las soluciones las más populares son:

Para una red VANET pura:

o Gestión de claves en cadena de certificados.

o Gestión de claves basada en movilidad.

Para una red VANET híbrida:

o Autoridades de certificación distribuidas.


o Gestión paralela de claves.

5.5.1. Gestión de claves en cadena de certificados

Cada nodo genera su certificado, se distribuye y se almacena en cada nodo de la red. Si un nodo deja

de fiarse de otro nodo, se puede pedir una renovación del certicado. Del mismo modo, si un nodo

sospecha que su clave privada ha sido comprometida, puede revocar su propio certicado y generar

otra clave privada.

5.5.2. Gestión de claves basadas en la movilidad

Se basa en un esquema de distribución peer-to-peer de las claves de los nodos basada en la movilidad

de cada nodo. Se transmite una clave a un nodo según la movilidad que tiene en un momento para

que este nodo distribuya las claves a los nodos a su alcance. Se rompe así la necesidad de tener una

entidad externa para compartir las claves.

5.5.3. Autoridades de certificación distribuidas

Se basa en una entidad externa de certicación que se encarga de distribuir las claves a los nodos de la

red. Esta entidad debe ser altamente segura para que ningún atacante pueda tomar el control de ella y

comprometer los mecanismos de certicación. Se puede distribuir los certicados de forma parcial o

total.

En un mecanismo de distribución parcial de los certificados se elige un subconjunto de nodos llamados

servidores a los cuales se transmiten las claves. Esos nodos deben disponer de una clave privada y una

clave pública para que la entidad externa les pueda identificar de forma unívoca. Cada uno de los

servidores genera una firma parcial utilizando su clave privada que es enviada a un combinador, que

puede ser cualquier servidor. El combinador reconstruye así la firma digital.

En un mecanismo de distribución total de los certificados, la clave se distribuye a todos los nodos de la

red y requiere que un nodo use la entidad externa para contactar con cualquier vecino. No es

necesario el concepto de combinador ya que será el propio nodo quién reconstruye la firma digital del

grupo.

5.5.4. Gestión paralela de claves

Esta alternativa se basa en una distribución parcial de los certificados por parte de una entidad externa

y de un mecanismo de cadenas de certificados. La propuesta es conocida como Composite Key

Management. La entidad externa distribuye el certicado a nodos servidores y luego tiene lugar el

mecanismo de cadenas de certicados.

Aplicaciones 6.

La gama de las distintas aplicaciones diseñada para arquitecturas que permitan la comunicación entre

vehículos va desde el simple intercambio de datos del estado del vehículo, a intercambios más

altamente complejos que nos permiten realizar una gestión inteligente del tráfico, incluyendo la

gestión de los recursos de la infraestructura dinámica desplegada. En esta sección intentaremos


analizar las diferentes aplicaciones que serán clasificadas por categorías. Aunque aún no se han

obtenido detalles uniformes del buen funcionamiento de la mayoría de las aplicaciones, el panorama

presentado ofrece diferentes recursos como mecanismos básicos, componentes y limitaciones

involucradas en el sistema. Este nos proporciona una contextualización inicial de las propiedades de

las comunicaciones en redes VANET.

Categoría Situación/Propósito Ejemplo

Seguridad Activa Peligros en la carretera 1. Advertencia curva peligrosa 2. Advertencia violación de señales de

parada en un cruce

Tráfico anormal y estado de la

carretera

1. Alerta vía en obras 2. Potenciar la visibilidad del conductor 3. Aviso infraestructura basada en carretera

Peligros por colisión 1. Aviso cambio rasante

2. Alerta cambio carril

3. Luces de frenado de emergencia

4. Advertencia de peatones en la calzada

Colisión inminente 1. Detección pre-colisión

Incidente ocurrido 1. Aviso post-colisión 2. Aviso de frenado 3. Servicios SOS

Servicio público Respuesta de emergencia 1. Aviso aproximación a vehículo con

emergencia 2. Servicios de emergencia (ambulancias,

bomberos) en escena

Soporte para autoridades 1. Número de bastidor electrónico 2. Licencia electrónica de conducción 3. Rastreo de vehículos robados

Mejora de la conducción Mejorar la conducción 1. Tren de conducción adaptable 2. Reducción encandilamiento

Tráfico eficiente 1. Notificación de colisión y estado de la calzada

2. Control inteligente del tráfico 3. Mejorar orientación y cálculo de rutas

Negocios/Entretenimiento Mantenimiento del vehículo 1. Diagnóstico inalámbrico 2. Actualización de software 3. Recordar aviso de mantenimiento

Servicios móviles 1. Servicio de internet 2. Mensajería instantánea 3. Notificación punto de interés

Soluciones empresa 1. Gestión de flotas 2. Alquiler de coches 3. Zona de control de acceso 4. Seguimiento de transporte de materiales

peligrosos

Comercio electrónico 1. Pago de peaje 2. Pago de reserva de hotel 3. Pago de combustible

Tabla 6 Aplicaciones VANET


Con el fin de establecer un límite más preciso entre las diferentes categorías descritas,

seguidamente, se va a definir las características de cada una de ellas para así establecer una mejor

relación entre las diversas aplicaciones existentes con la categoría a la que pertenecen.

6.1. Seguridad activa

Las aplicaciones de esta categoría están consideradas como el servicio más demandado por la

tecnología VANET con impacto directo sobre la seguridad vial. El propósito de las aplicaciones que se

encuentran en esta categoría es el de suministrar recursos a los conductores para que estos realicen

una conducción segura, obteniendo información acerca de una situación peligrosa, permitiendo que el

vehículo esté capacitado para evitar un accidente o para reaccionar adecuadamente si un accidente no

puede evitarse. En el cuadro anterior podemos observar la existencia de un orden en el tipo de

aplicaciones para esta categoría en función del nivel de peligro que entraña. Por ejemplo, los sucesos

estáticos, como pueden ser un camino en mal estado, una curva cerrada, o situaciones anormales de

circulación, tienen un nivel de peligrosidad baja. Sin embargo, aquellos casos en los que la aplicación

debe prevenir colisiones, como por ejemplo el supuesto en el que un vehículo realiza una frenada

fuerte porque se encuentra en un escenario con congestión, tienen un nivel de peligrosidad alto. En

caso de un peligro inminente donde no se puede evitar el riesgo de colisión, las aplicaciones tipo

precrash-sensing prepararán al vehículo para la colisión con el fin de minimizar el impacto, por

ejemplo aumentando la presión en los amortiguadores. Por último, cuando se produce un accidente

es de vital importancia advertir de tal hecho a los vehículos cercanos para que no se produzca un

accidente en cadena, o para pedir ayuda.

Los servicios dirigidos a la seguridad vial son de forma clara los más importantes y los más críticos dado

que su objetivo no es otro que salvar vidas disminuyendo el número de accidentes en la carretera. En

este contexto se está haciendo un esfuerzo importante por parte de la comisión europea en la

investigación, desarrollo e implementación de este tipo de servicios con el fin de que entren en

actividad lo antes posible.

6.1.1. Mecanismos anti-colisión

Se trata de un servicio de ayuda a la conducción que sirve para detectar posibles obstáculos en la vía.

La funcionalidad principal consiste en el aviso mediante señales acústicas al conductor de la presencia

de otro vehículo o de que se acerca a una velocidad peligrosa para ese entorno. Este servicio requiere

mucha rapidez a la hora de establecer el enlace y no es tan importante el tema de encaminamiento ya

que básicamente la comunicación se dará entre vehículos con visión inalámbrica directa sin nodos

intermediarios.

Para un correcto despliegue será necesaria una pequeña instalación en los equipos de los usuarios que

enviase a sus vecinos información de posición, trayectoria y velocidad así como un mecanismo que

permanentemente escuche la información enviada por el resto de los vehículos y la infraestructura.

6.1.2. Aviso de peligro

La funcionalidad principal de ese servicio consiste en detectar eventos peligrosos para informar al

resto de los vehículos de la red. Los sensores pueden detectar un peligro y avisar al conductor con una

breve descripción o el conductor mismo puede detectar el peligro y a través de una interfaz vocal


describir el peligro para el resto de los usuarios.

Puede interesar mandar la información a todos los usuarios de la red para informar por ejemplo que

se produce un atasco en un cierto punto de la carretera dónde están circulando. Por otro lado, se

puede necesitar un envío geocast, por ejemplo si se detecta un vertido de aceite en una salida de la vía

solo interesa mandarla a aquellos que van a tomar esa salida. Por lo tanto, es necesario que los

vehículos soporten protocolos broadcast y geocast que no sobrecarguen la red con mensajes de

control para que la información llegue al destino de manera eficiente y rápida.

6.2. Servicio público

Este tipo de aplicaciones están destinadas a colaborar con la labor de los servicios públicos como la

policía o las unidades de emergencia, ya sean ambulancias, bomberos, llamadas de urgencia (ecall)…,

realizando una labor de apoyo a la actividad de los mismos mediante sirenas virtuales o dotando de

capacidades de señales preventivas. Mediante el uso de estas solicitudes se pretende que los

vehículos de emergencia sean capaces de llegar a su destino mucho más rápido que hoy día. Además,

este tipo de aplicaciones permitirían simplificar la vigilancia como si se estuviera tratando de un

sistema de correo electrónico.

6.2.1. e-call

Se trata de una regularización de la Unión Europea (UE). Este futuro servicio consiste

fundamentalmente en una llamada desde el vehículo a un número de emergencia en caso de

accidente.

En caso de accidente, el equipo embarcado transmite una llamada de urgencia al centro de recepción

de llamadas más adecuado y envía al mismo tiempo, determinados datos sobre el vehículo

(principalmente su localización precisa). El sistema se basa en el empleo del número de urgencia único

europeo 112, que permitirá garantizar su interoperabilidad en toda la UE. La llamada de emergencia

puede ser generada manualmente por los ocupantes del vehículo o automáticamente, en caso de

accidente grave, mediante la activación de sensores instalados en el vehículo.

6.2.2. Identificación de vehículos y obtención de información

Este servicio a largo plazo aportará una forma segura y ágil de recibir información de los vehículos sin

necesidad de detenerlos. Será necesaria una legislación acorde que permita que todos los vehículos

dispongan de la información necesaria en formato electrónico y que se transmita de manera

automática siempre que un dispositivo debidamente autorizado lo requiera.

Esto facilitará el control por parte de las autoridades para que todos los vehículos que circulen por vías

públicas tengan en regla toda la documentación necesaria (permiso de circulación, seguro, tarjeta

ITV...). Cuando se detecte una infracción el servicio podrá transmitir la consecuente denuncia de forma

automática. Más a largo plazo aún, este servicio podrá tener una extensión asociando también la

identificación del conductor.

6.2.3. Detección de infracciones

Otro servicio desplegable gracias a una plataforma de comunicaciones V2I/V2V permitirá monitorizar


los parámetros de conducción de los vehículos. Gracias al sistema de posicionamiento y las

comunicaciones, los elementos de infraestructura podrán obtener información sobre múltiples datos

sensibles de ocasionar peligro, como son:

Velocidades excesivas.

Tiempos de conducción sin parar.

Infracciones en semáforos y stops.

Tránsito por zonas prohibidas.

6.2.4. Mejora de la conducción

Esta categoría incluye aplicaciones que tratan de mejorar o simplificar la conducción mediante el uso

de medios de comunicación entre los coches. La idea comprende escenarios en los alrededores

inmediatos de un vehículo, así como la gestión de un tráfico eficiente. En el primer caso, las

aplicaciones están destinadas a ayudar al conductor en situaciones de incorporación a una autopista,

en la reducción de un encandilamiento debido a las luces de carretera en situaciones de cambio de

rasante o en otras situaciones análogas. En el segundo caso, el tráfico eficiente está destinado a dirigir

el tráfico en un área de mayor dimensión. Esto conlleva que la advertencia de un accidente se difunde

en un área mayor para informar a los vehículos del posible obstáculo, con la finalidad de que los

conductores puedan tomar una ruta alternativa y de este modo prevenir los atascos. Otro servicio que

pertenecería a esta categoría sería la difusión de información sobre aparcamiento o incluso la reserva

de estacionamiento.

6.3. Negocios/Entretenimiento

Un gran bloque de aplicaciones pueden reseñarse bajo los términos de negocios y entretenimiento.

Aquí la atención se centra en la prestación de servicios a los clientes, automatización de tareas del

vehículo o solicitudes de pago, así como en la descarga de música, gestión de flota para empresas

dedicadas al transporte, un mantenimiento más sencillo de vehículos, o realizaciones de pago por

estacionamientos o por el peaje de las carreteras. La mayoría de estas aplicaciones se centran en el

aumento del disfrute y del confort para los usuarios del vehículo.

6.3.1. Calculo óptimo de rutas con datos de tráfico en tiempo real

Este servicio puede ser usado tanto desde el propio vehículo como desde cualquier punto conectado a

Internet. Podría ofrecerse como un servicio Web que permanentemente informa del estado de las

carreteras en tiempo real. El hecho de que a largo plazo todos los vehículos puedan disponer de este

sistema facilitaría la identificación y recuento por parte de los equipos instalados en la infraestructura

vial a tal efecto. Estos datos convenientemente recogidos y analizados servirán para mostrar el estado

y prever futuros atascos.

6.3.2. Tele diagnóstico y ayuda on-line en caso de avería

Este servicio se enmarca en las directivas de la comisión europea para liberar los manuales de

reparación de los diferentes vehículos por parte de los fabricantes. Gracias a esta futura liberalización

se podrán desplegar funcionalidades como:


Consulta del manual electrónico y multimedia por parte del conductor desde el propio equipo

embarcado.

Consulta del manual por parte de las empresas de asistencia en carretera.

Consulta a un sistema experto automático de datos en caso de avería.

Envío automático de datos en caso de avería.

Tele diagnóstico. Esta utilidad permite de forma remota valorar el grado de avería y en su caso

facilitar la solución al conductor (instrucciones, envío de grúa...).

6.3.3. Acceso a internet desde los vehículos

Este servicio facilitará el acceso a Internet desde pantallas táctiles dentro de los vehículos. Enmarcado

dentro del grupo de ocio y entretenimiento este servicio genérico suplirá posibles carencias en los

contenidos del resto de los servicios. Los usuarios podrán acceder a toda la red e informarse de las

condiciones meteorológicas del destino, reservar un hotel e incluso descargar contenidos.

Aunque podría ser tratado como un servicio aparte, una funcionalidad del acceso a Internet es la

descarga y reproducción de contenidos multimedia. Debido a su gran aceptación es previsible que a

medio plazo gran cantidad de vehículos dispongan de medios para reproducir contenidos de video por

lo que es razonable pensar que habrá una demanda de este tipo de servicios de descarga e incluso de

Video On Demand.

Para ofrecer estos servicios el sistema de comunicaciones deberá ser capaz de acceder a Internet, bien

a través de la red VANET o mediante tecnología móvil celular. Tanto la navegación como la descarga

de correo electrónico no presentan grandes requisitos en términos de jitter, retardo y ancho de banda

mientras que para el streaming de contenido multimedia es necesario unos buenos valores de calidad

de servicio.

6.3.4. Acceso a pasarelas para el paso de peajes

Muchos de los problemas de retenciones en las autopistas y vías de pago se producen en los tramos

de peaje, tanto en la entrada recogiendo el ticket como en la salida a la hora de pagar. Un servicio que

gestionase esto de forma automática y evitase a los conductores el parar en estas zonas ahorraría

tiempo a la vez que reduciría el coste para la empresa gestora de la vía.

Se ha pensado en un mecanismo mediante el cual los vehículos puedan asociar de forma segura su

equipo a un medio estándar de pago, tipo tarjeta de crédito o moneder. Esta asociación permitirá el

cargo automático del peaje de la vía sin necesidad de detener el vehículo.

El funcionamiento será el siguiente: el usuario asocia su equipo embarcado a una pasarela de pago e

indica los cargos permitidos para facturación inmediata. Una vez configurado el sistema, la próxima

vez que se acerque a un punto de peaje el sistema instalado en el puesto se comunicará con el

vehículo y preguntará si soporta este servicio, con la respuesta afirmativa por parte el vehículo y los

datos de la forma de pago, se habilita el paso sin necesidad de detener el vehículo.

Este sistema aportará mejoras a los sistemas tradicionales de pago en peajes ya que por un lado,

aumenta la distancia de comunicación y permite atravesar el peaje a mayores velocidades que las

actuales.


Por supuesto la seguridad de este servicio debe estar garantizada para evitar posibles ataques y el uso

fraudulento de las tarjetas de pago de los usuarios.

6.3.5. Búsqueda y reserva de plazas de aparcamiento en el destino

Muchos de los parkings públicos ya disponen de un mecanismo informatizado que informa a los

vehículos entrantes de la localización de las plazas libres. Este servicio deberá ser una extensión a este

mecanismo de forma que los usuarios desde el propio vehículo y en ruta puedan comunicarse con el

parking destino, notificarle la hora aproximada de llegada y reservar una de las plazas. El sistema del

parking por su parte aceptará la petición, facturará el cargo (si procede) e indicará al usuario como

llegar hasta su plaza.

6.3.6. Información y alertas de gasolineras

A través de este servicio, los usuarios podrán interrogar al sistema de las distancias a las gasolineras

más próximas, la empresa y las tarifas de los distintos carburantes. Para ello las diferentes gasolineras

que lo deseen entregarán esta información y se comprometerán a tenerla actualizada en cada

momento.

Una extensión de este servicio, a largo plazo será la integración de sensores en el equipo que informan

de la cantidad de combustible restante y con la ruta programada informa al conductor la gasolinera

recomendada para repostar.

6.3.7. Envio de publicidad

Siempre contando con el permiso de los usuarios, se puede desplegar un servicio mediante el cual los

equipos de la infraestructura envíen publicidad, básicamente relacionada con los servicios de la vía.

Los usuarios podrían configurar sus equipos para aceptar o rechazar este tipo de publicidad incluso

definir un perfil con sus preferencias al respecto. Este perfil sería modificable dinámicamente de forma

que al circular por autopistas aceptara avisos de publicidad de restaurantes y gasolineras y, circulando

por tramos urbanos, anuncios de parkings.

Calidad de servicio 7.

El concepto de calidad de servicio (QoS) se utiliza para evaluar las prestaciones cuantitativas y

cualitativas que se pueden ofrecer por una red a un servicio dado. los requisitos de calidad de servicio

son:

Retardo extremo a extremo

Ancho de banda disponible

Probabilidad de pérdida de paquetes

Jitter

La llegada de nuevas aplicaciones de tiempo real como son el video streaming o el tráfico de voz por

ejemplo, han hecho que la calidad de servicio de las redes se convierta en un requisito de primera

importancia. Las redes móviles, debido a sus especiales características, hacen que la provisión de QoS

sea un tema especialmente complicado. En este apartado se ofrece una revisión sobre el estado del

arte de las QoS en redes ad-hoc. Se realizará un repaso de las principales iniciativas y se presentarán


las líneas de trabajo que mayor viabilidad presentan en la actualidad.

7.1. Modelos de calidad de servicio

Las mayores propuestas de modelos de QoS son las estudiadas por el IETF a través de dos grupos de

trabajo: Intserv (servicios integrados) y Diserv (servicios diferenciados).

Intserv se basa en la idea de reserva de recursos en la red por flujos. Para cada flujo entrante se

definen los recursos (ancho de banda, retardo,...) que serán necesarios para este flujo. Cada nodo en

el camino entre la fuente y el destino indica si puede asegurar la reserva y mantiene una tabla con el

estado de reserva por flujo. La principal limitación de este modelo es la gran cantidad de información

que se debe almacenar en cada nodo, provocando que la solución no sea aplicable en situaciones con

gran cantidad de flujos entre usuarios finales.

Diffserv propone la agregación de flujos según la QoS, solucionando de esta forma los problemas de

escalabilidad de Intserv. Diffserv define un campo de la cabecera IP, Diffserv Code Point (DSCP)

asociado a la cabecera IP, de manera que el tratamiento de este tráfico en los nodos intermedios

vendrá determinado por el valor asociado a este campo. De esta forma, se logra la agregación de

flujos, consiguiendo un tratamiento especial para cada servicio en función del código DSCP.

7.2. Señalización para la reserva de recursos

Se necesita un mecanismo de señalización que se encargue de efectuar la reserva y la liberación de

recursos en la red.

Uno de los mecanismos más extendidos es el protocolo RSVP, definido por el IETF. Se basa en la

reserva de recursos extremo a extremo mediante los mensajes PATH y RESV que recorren el camino

de una fuente hacia un destino estableciendo une reserva en los nodos intermedios. Sin embargo, este

mecanismo no resulta tan eficiente en redes VANETs ya que introduce una sobrecarga importante y

no se adapta muy bien a la topología altamente dinámica de estos tipos de red.

Para resolver este problema nace INSIGNIA, que propone incluir los mensajes de señalización en las

cabeceras de los paquetes. Así, la cabecera indica si el paquete necesita recursos o si ya tiene la

reserva hecha. En caso de que se trate de una petición, el paquete pasa a un módulo de decisión que

analiza la red para saber si puede ofrecer los recursos necesarios. Se marca la decisión en la cabecera y

el paquete es retransmitido.

7.3. Calidad de servicio ligada a encaminamiento

Un protocolo de encaminamiento que soporta QoS debe ser capaz de optimizar las rutas utilizadas en

términos de ancho de banda, retardo, jitter...etc. Sin embargo, la topología dinámica de las VANETs

hace muy complicada la evaluación de las prestaciones en una ruta.

A continuación se expone la propuesta CEDAR. Se trata de un protocolo de encaminamiento con

soporte de QoS. En primer lugar la extracción de núcleo permite identificar un conjunto mínimo de

nodos en la red que formarán parte del núcleo. Todo nodo debe formar parte del núcleo o ser vecino

de un nodo del núcleo. CEDAR propone un algoritmo para la elección de los nodos que compondrán el

núcleo, y define un proceso de pseudo-broadcast para el intercambio de información entre los nodos

del núcleo.


Otro de los pilares que componen CEDAR es la propagación del estado de enlace, cuyo objetivo es que

cada nodo del núcleo conozca el estado y topología de los enlaces locales, así como los enlaces más

lejanos pero estables y con gran ancho de banda.

El proceso de cálculo de ruta se realiza de la siguiente manera; cuando un nodo desea enviar

información a un destino, previamente manda un mensaje indicando origen, destino y ancho de banda

solicitado. Esta información se propaga por el núcleo a través del pseudo-broadcast, hasta que alcanza

el destino, mientras los nodos intermedios comprueban la disponibilidad de ancho de banda en cada

salto.

Factores que afectan a una VANET 8.

La movilidad característica de los nodos de una red VANET influye en parámetros como la ruta

conseguida, el mantenimiento de la topología, capacidad de mantenimiento y de reconstrucción de

rutas. En cada instante, tenemos una red en la cual conviven elementos móviles y estáticos, cuyo rol

puede variar sin previo aviso. Entre los principales factores que influyen a la hora de implementar una

red VANET destacan:

Disposición de las calles: las calles fuerzan a los nodos a seguir caminos definidos. Este

movimiento restringido destaca la importancia de factores como la distribución espacial de los

nodos y la conectividad de la red. También implica que se tengan en cuenta cuestiones propias

de diseños de vehículos como vehículos circulando por calles paralelas o la posibilidad de que

existan vehículos situados en el límite del rango de comunicación. También se tiene que tener

en cuenta que las calles pueden tener uno o más carriles y ser de único sentido o de doble

sentido.

Tamaño de las manzanas: Las áreas urbanas están divididas en manzanas de edificios de

distintos tamaños. El tamaño de las manzanas dicta de la densidad de intersecciones en la

zona, lo cual influye directamente en el número de paradas que tiene que realizar el vehículo.

Mecanismos de control de tráfico: Los mecanismos de control de tráfico más comunes están

situados en las intersecciones y son la señal de STOP y los semáforos. Estos mecanismos

causan la formación de colas y conjuntos de vehículos, así como reducen el promedio de

velocidad de los mismos. Reducir la movilidad implica un aumento de nodos estáticos y una

tasa de cambio menor en la topología de la red.

Estos y otros factores son los que se tienen que tener en cuenta a la hora de elegir y estudiar una zona

con la finalidad de implementar/simular una red VANET. El estudio de la zona escogida es muy

importante ya que no existe un exhaustivo trabajo previo de análisis, y aunque la simulación y

extracción de datos sea excelente, se tendrán unos resultados engañosos y poco acordes con la

realidad.


3. PROTOCOLOS DE ENCAMINAMIENTO BAJO

ESTUDIO

El objetivo de este capítulo es hacer hincapié en los detalles de los protocolos bajo estudio para

ofrecer una visión clara sobre su funcionamiento. Los protocolos que van a ser sometido a estudio y

que a continuación se exponen son AODV, DSR, AOMDV, DSDV, DSR, ZRP y DYMO.

En el capítulo anterior para presentar los protocolos se clasificaron en función del alcance. Sin

embargo ahora la clasificación se hará en base al modo de descubrimiento de ruta (Proactivo, Reactivo

e Híbrido).

Protocolos Reactivos 1.

Buscan las rutas cuando se necesitan, mediante la inundación de la red de paquetes de ruta. Las

desventajas de estos protocolos son el alto tiempo de latencia hasta que la ruta es descubierta y la

posibilidad de saturación.

I. AODV

1. Introducción

El protocolo de encaminamiento AODV fue proyectado en 1999 por Charles E. Perkins, del grupo de

desarrollo avanzado de Sun Microsystems, y Elizabeth M. Royer, de la Universidad de California, Santa

Bárbara. Su propósito fue diseñar un protocolo de encaminamiento para redes ad hoc formadas por

nodos móviles tomando como punto de partida el protocolo DSDV, con el fin de solventar sus

deficiencias: el alto número de envíos en modo broadcast y la latencia de transmisión. A su vez, el

protocolo DSDV también había sido concebido por Perkins en colaboración con Pravin Bhagwat cuatro

años antes. El documento oficial vigente que describe las especificaciones del protocolo AODV, la

RFC3561 (Request For Comments) número 3561, se publicó en julio de 2003 con la categoría de

experimental.

Como ya se indicó en las Secciones anteriores, el protocolo AODV es un protocolo reactivo, ya que el

proceso de búsqueda de rutas se inicia sólo cuando un nodo necesita enviar información a otro nodo y

desconoce cómo acceder a él. Además, está basado en la familia de algoritmos de vector de distancias

y puede transmitir en modo unicast y multicast. Su modelo de comunicación es multicanal y tiene

direccionamiento plano y estructura uniforme.

El protocolo AODV combina técnicas extraídas de los protocolos DSDV y DSR, dando lugar a un

algoritmo que usa el ancho de banda de manera eficiente y que responde con rapidez a los cambios en

la red al tiempo que garantiza la ausencia de bucles. Con el fin de mantener sólo la información de

encaminamiento más reciente, el protocolo AODV toma prestado de su predecesor, el protocolo

DSDV, el concepto de número de secuencia. Tanto en el protocolo AODV como en el protocolo DSDV,

cada nodo se encarga de mantener su propio contador o número de secuencia. Este número no es

más que un valor entero que cada nodo incrementa monótonamente antes de generar un mensaje de


control para copiarlo en éste antes de enviarlo. De manera complementaria al número de secuencia,

cada nodo se distingue por un identificador único dentro de la red. De este modo, con la pareja de

valores formada por el identificador del nodo y el número de secuencia, es posible distinguir la

información válida de la anticuada. Si un nodo recibe dos paquetes con el mismo identificador de nodo

pero con diferentes números de secuencia, la información más reciente será la incluida en el paquete

de mayor número de secuencia. Puesto que cada nodo es responsable de su propio contador, no es

necesario mantener un reloj único y común a toda la red, lo cual simplifica enormemente la

implementación del protocolo. El uso de estos números de secuencia garantiza la ausencia de bucles

en todo momento y evita problemas como el de la “cuenta al infinito”. En los protocolos que no

incluyen ningún mecanismo de prevención, esta anomalía se produce cuando cae un enlace,

afectando al menos a dos nodos. Considérese un primer nodo con dos enlaces: uno de ellos le conecta

con un segundo nodo y el otro ha dejado de estar operativo. El segundo nodo, que desconoce que ha

fallado el enlace, desea acceder a un destino al otro lado del enlace averiado, por lo que tendría que

pasar por el primero de los nodos. Sin embargo, como el primer nodo no puede usar el enlace dañado,

reenvía el paquete al segundo. Cada nodo cree equivocadamente que puede llegar a su destino a

través del otro, por lo que ambos degeneran en un bucle infinito. Este problema de cuenta al infinito

está típicamente asociado a los protocolos clásicos de vector de distancias, ya que con este modelo de

información de estado, los nodos sólo conocen el siguiente salto y no mantienen la topología completa

de la red.

El protocolo AODV emplea un mecanismo de descubrimiento de rutas en modo broadcast que

también emplea el protocolo DSR aunque con ciertas modificaciones. En el protocolo DSR, es el nodo

origen quien se encarga de calcular la ruta completa hasta el nodo destino. Esto puede degradar las

prestaciones de la red cuando ésta es muy extensa, ya que cada paquete incluye en su cabecera la

secuencia de nodos por los que debe pasar desde el origen hasta el destino. Por el contrario, en el

protocolo AODV, el camino se forma gracias a la información mantenida en las tablas de rutas de los

nodos intermedios.

2. Información de encaminamiento

El protocolo AODV almacena la información de encaminamiento en forma de tablas de rutas. Cada

uno de los nodos de la red mantiene su propia tabla, que tiene tantas entradas como destinos conoce

el nodo. Una entrada consta típicamente de los siguientes campos:

Dirección IP destino.

Número de secuencia del nodo destino. Número de secuencia asociado al nodo destino, cuyo

valor se obtiene de los mensajes de control.

Indicador de validez del número de secuencia del nodo destino. Si se pretende alcanzar un

nodo destino y ha fallado uno de los enlaces implicados, o la ruta ha expirado, el número de

secuencia asociado a ese nodo destino se marca como inválido.

Otros indicadores sobre estado y rutas. Por ejemplo, indicadores sobre si la ruta es o no

válida, y en este último caso si es reparable, no es reparable y se debe buscar un camino

alternativo, o bien, si está siendo reparada.

Interfaz de red


Número de saltos. Número de saltos necesarios desde ese nodo para alcanzar el destino.

Siguiente salto. Nodo adyacente al que se debe enviar el paquete para llegar al destino

deseado.

Lista de precursores. Lista de nodos que forman el camino resultante del proceso de

descubrimiento de rutas.

Tiempo de vida de la ruta. Tiempo en el que la ruta caduca o debe ser borrada.

3. Descubrimiento de caminos

El proceso de descubrimiento de caminos se inicia cuando un nodo origen desea comunicarse con otro

nodo pero desconoce cómo acceder a él, es decir, no tiene información de encaminamiento en su

tabla de rutas acerca de ese nodo destino. Para ello, se intercambian principalmente dos tipos de

mensajes: mensajes de solicitud o petición de ruta (RREQ, Route Request) y mensajes de respuesta de

ruta (RREP, Route Reply). En esta operación de búsqueda de rutas se pueden distinguir a su vez dos

fases: la formación del camino de vuelta y la formación del camino de ida. En primer lugar, la

formación del camino de vuelta establece todos los itinerarios posibles desde el origen hasta el

destino, trazados por el recorrido de los mensajes RREQ. En segundo y último lugar, la formación del

camino de ida determina la ruta que finalmente seguirán los paquetes desde el nodo origen hasta el

nodo destino una vez finalizado el descubrimiento de caminos.


4. Formación del camino de vuelta

Cuando un nodo origen desea alcanzar un nodo destino y desconoce cómo acceder a él, genera un

mensaje RREQ. En él se incluyen las direcciones IP y los números de secuencia de los nodos origen y

destino. Antes de enviar esta solicitud, el nodo origen incrementa su número de secuencia para evitar

conflictos con peticiones anteriores. En el campo correspondiente al número de secuencia de destino,

el nodo incluye el último valor aprendido, en caso de que ya hubiese solicitado esa ruta con

anterioridad, o bien indica que es desconocido. El mensaje RREQ se difunde por inundación. La

inundación es una técnica de envío de paquetes por la que cuando un nodo tiene información dirigida

a un destino concreto, la transmite a sus vecinos. Si el nodo que la recibe no es el destinatario de esta

información, la reenvía de nuevo. Este proceso continúa sucesivamente hasta alcanzar el nodo

destino. En complemento a la técnica de inundación y con el objeto de evitar un consumo excesivo del

ancho de banda, el nodo origen emplea el algoritmo de búsqueda expansiva en anillo (expanding ring

search). De acuerdo a este algoritmo, inicialmente el mensaje RREQ tiene asociado un valor pequeño

de su tiempo de vida TTL (Time-To-Live), de tal manera que el mensaje se descarta cuando este

tiempo expira. Si no se encuentra el destino antes de un plazo determinado, este valor se incrementa

progresivamente en el envío de las posteriores solicitudes de rutas. Con el fin de que un nodo no

permanezca eternamente intentando alcanzar un destino inaccesible, se tiene un número máximo de

intentos, cuyo valor es típicamente dos. La Ilustración 13 representa una red compuesta por diez

nodos, en la que se indica mediante flechas el recorrido de los mensajes RREQ. El nodo origen inicia el

proceso de inundación con mensajes RREQ, que llegan a sus dos vecinos, quienes a su vez reenvían

sucesivamente la solicitud. En este caso, se considera que ninguno de los nodos intermedios conoce el

camino, por lo que la inundación se propaga hasta alcanzar el nodo destino.

Ilustración 13 Inundación con mensajes RREQ

Cada vez que un nodo recibe el mensaje RREQ, comprueba si es él el destino buscado o si al menos


conoce cómo acceder a él. Si no es así, el nodo recoge un registro de la solicitud y vuelve a reenviar el

mensaje RREQ a sus vecinos, continuando con el proceso de inundación. Los nodos toman nota de los

mensajes RREQ recibidos para no reenviar la misma solicitud varias veces, ya que esto sobrecargaría la

red de manera innecesaria. La Ilustración 14 Generación de caminos de vuelta potenciales muestra la fase de

formación de los caminos de vuelta. Puesto que los nodos intermedios anotan de dónde proviene la

solicitud, se forman cuatro caminos de vuelta, representados con líneas continuas. Como se puede

apreciar, los caminos en colores rosados no son factibles, sólo las dos rutas trazadas en colores

azulados comunican origen y destino. El proceso de inundación, y en consecuencia, la formación del

camino de vuelta, se detiene cuando el nodo que recibe la solicitud es el nodo destino o conoce cómo

llegar al mismo, dando lugar a la siguiente fase, la formación del camino de ida.

Ilustración 14 Generación de caminos de vuelta potenciales

5. Formación del camino de ida

Si el nodo que recibe la solicitud es el propio nodo destino o es un nodo intermedio que tiene una ruta

activa hacia el destino, se genera un mensaje de respuesta de ruta. Se considera que un nodo

intermedio tiene una ruta activa hacia el destino cuando el número de secuencia del nodo destino

almacenado en la tabla de rutas es mayor o igual al número de secuencia del nodo destino de la

solicitud. Cuando es el nodo destino quien genera la respuesta, incluye en el mensaje RREP como

número de secuencia el valor máximo entre su propio número de secuencia y los números de

secuencia de destino incluidos en los mensajes de solicitud de rutas. A diferencia de la solicitud, el

mensaje RREP se reenvía de vuelta al origen de forma unicast. Un mensaje RREP siempre sigue el


camino inverso de su mensaje RREQ correspondiente, por lo que los nodos típicamente asumen que

los enlaces son bidireccionales. La Ilustración 15 detalla la trayectoria de las respuestas para completar

la fase de formación del camino de ida, en la que se indica mediante flechas el recorrido de los

mensajes RREP. En este caso, puesto que se supone que ninguno de los nodos intermedios conoce la

ruta, es el nodo destino quien genera la respuesta, por lo que los dos mensajes RREP que llegan al

nodo origen tienen el mismo número de secuencia de destino. Para escoger una de las dos rutas

posibles, se atiende al menor número de saltos, y así se selecciona el camino trazado en verde

azulado, de tres saltos, en lugar del de color turquesa, que consta de cuatro.

Ilustración 15 Reenvío de mensajes RREP

Cuando los nodos intermedios por los que pasó previamente la solicitud reciben la respuesta de rutas,

pueden verse en la necesidad de actualizar su tabla de rutas. En la Ilustración 16 se muestra la lógica

que siguen los nodos intermedios para decidir si actualizar o no la entrada en la tabla correspondiente

al nodo destino. Un nodo intermedio procede a la actualización de rutas en dos casos. En primer lugar,

refresca su ruta si el nuevo número de secuencia asociado al nodo destino que se incluye en el

mensaje RREP es mayor que el que figura en su tabla para ese destino. En segundo lugar, cuando

ambos números de secuencia coinciden, se procede a la actualización cuando el número de saltos

indicado en la respuesta es inferior al indicado en su tabla. Para computar el número real en función

del número de saltos que aparece en la respuesta ha de sumarse una unidad para incluir al propio

nodo.


Ilustración 16 Diagrama de flujo para la actualización de rutas en los nodos intermedios durante la fase de formación del camino de ida

Los mensajes RREP redundantes o con un número de secuencia de destino menor se descartan

automáticamente. Cuando finalmente el nodo origen recibe el mensaje de respuesta, guarda la ruta

hacia el destino y puede comenzar a transmitir paquetes de datos. La Ilustración 17 muestra el camino

de ida definitivo. Sobre él se muestra el recorrido de los paquetes de datos mediante flechas.

Ilustración 17 Envío de paquetes de datos sobre el camino de ida seleccionado

Antes de concluir con esta sección resulta bastante interesante mostrar un ejemplo para enfatizar más


en el proceso de descubrimiento de rutas en AODV, el cual es uno de los aspectos más importantes del

protocolo, el siguiente ejemplo detalla las múltiples posibilidades del proceso de descubrimiento.

1. El nodo S necesita una ruta al nodo D.

2. El nodo S crea un mensaje de petición de ruta (RREEQ). En el paquete se introduce la dirección IP

de D, el número de secuencia, dirección IP de S, y número de saltos hasta D.

Ilustración 18 Descubrimiento de ruta AODV I

3. El nodo S broadcast el mensaje RREQ a sus nodos vecinos, Ilustración 19.

4. El nodo A recibe el mensaje RREQ, Ilustración 20

Hace una entrada invertida en su tabla a la solicitud de S. Introduce destino S, siguiente salto S, número de cuenta igual a 1, ya que este es el primer salto.

Como este no tiene ruta para el destino D, vuelve a retransmitir el paquete a todos sus vecinos.

Ilustración 19 Descubrimiento de ruta AODV II


Ilustración 20 Descubrimiento de ruta AODV III

5. El nodo C recibe el mensaje RREQ.

Hace una entrada invertida para la petición de S. Destino S, Siguiente salto A. Número de cuenta 2, ya se han producido dos saltos.

Éste tiene una ruta para D, y el número de secuencia es mayor que el que se encuentra en el mensaje RREQ, Ilustración 21.

C crea un mensaje de réplica a la petición de ruta RREP. Introduce la dirección IP de D, el número de secuencia, la dirección IP de S, y el número de salto lo pone a 1.

Crea un mensaje unicast de vuelta hacia A.

Ilustración 21 Descubrimiento de ruta AODV IV

6. El nodo A recibe el mensaje de réplica RREP, Ilustración 22

Realiza una entrada a D. Destino D. Siguiente nodo A. Número de saltos 1.

Crea un mensaje unicast de vuelta hacia S

Ilustración 22 Descubrimiento de ruta AODV V

7. El nodo S recibe el mensaje de réplica de ruta RREP, Ilustración 23.

Realiza una entrada a D. Destino D. Siguiente nodo A. Número de saltos 3.

La ruta ha sido ya establecida, luego se puede comenzar a enviar datos desde S a D.


II. DSR

1. Introducción

DSR es un protocolo de enrutamiento muy similar a AODV. Ambos son reactivos y mantienen los mismos tipos de paquetes en su funcionamiento. Para realizar el análisis de DSR se harán múltiples referencias al estudio ya realizado en este mismo documento a AODV, comparando ambos protocolos y viendo sus puntos débiles y fuertes.

Sus características básicas son las mismas:

Funciona bajo demanda, es decir, sólo se buscarán rutas cuando sea necesario enviar información a un nodo. Esto provoca una alta latencia en las primeras comunicaciones con nodos que no hayan sido descubiertos aún.

Detecta rápidamente cambios en la arquitectura de la red adaptando las rutas cuando estos se producen.

Trabaja bien incluso en condiciones donde la movilidad es alta.

Incorpora un mecanismo para evitar la formación de bucles.

Sin embargo, presenta otras características que lo diferencian de AODV:

Permite tener varias rutas para un mismo destino permitiendo así balanceo de carga y mayor robustez.

Para encaminar un paquete, éste incorpora toda la ruta completa con todos los nodos por los que pasaría hasta llegar al destino. Con este mecanismo un nodo puede obligar que sus mensajes pasen forzosamente por determinados nodos, o todo lo contrario, evitar que sus mensajes transiten algún nodo que se quiera sortear. En AODV esto es completamente imposible.

Su diseño no es escalable, por lo que a partir de un número de nodos las cabeceras crecen demasiado y deja de funcionar correctamente.

La principal ventaja de este tipo de protocolos reactivos es que reducen la carga de la red debida a tráfico de control y actualización de rutas, ya que no es necesario inundar la red periódicamente con estos mensajes, como en los protocolos proactivos.

2. Descubrimiento de rutas

Cuando un nodo fuente tiene un paquete para enviar, lo primero que hace es buscar en su tabla de

rutas un camino hacia el destino. Si lo tiene, crea un nuevo paquete añadiendo a la cabecera la ruta

completa, en donde se indican los saltos que debe seguir hasta llegar al destino y finalmente lo envía.

Ilustración 23 Descubrimiento de ruta AODV VI


Aquí nos encontramos la primera diferencia con AODV, en donde si el nodo encontraba en su tabla de

rutas el destino, éste enviaba simplemente el paquete al primer vecino sin añadir ni modificar nada

más. En DSR se añade toda la ruta primero antes de ser enviado.

El nodo emisor tiene en su tabla de rutas todos los caminos hacia los nodos que ha descubierto

previamente. En el caso de que no encontrara ninguna ruta, es cuando se inicia el mecanismo de

descubrimiento de rutas para encontrar dinámicamente un nuevo camino hacia el nodo destino.

3. Formación del camino de ida

Lo primero que hace el nodo fuente es enviar un paquete por broadcast denominado Route Request

(RREQ), el cual es recibido por todos los nodos que se encuentren dentro del rango de transmisión del

nodo fuente. El paquete RREQ de DSR suele tener mayor tamaño que el de AODV. Contiene:

Discriminador: campo que se utiliza para identificar el tipo de paquete que se ha recibido. En el

caso de DSR los paquetes que se pueden identificar son: RREQ, RREP y RERR.

Tamaño: Qué tamaño tiene el paquete no incluyendo el discriminador ni esta opción. Hay que

recordar que los RREQ van creciendo de tamaño según van saltando de nodo en nodo.

Identificador: Valor incremental generado por el nodo fuente para identificar de manera única

una petición.

Ip destino: La dirección del nodo objetivo de la petición.

Lista de Ips de ruta: Cada vez que se reenvía la petición el nodo se agrega al final de la lista e

incrementa el tamaño en 4.

TTL: Atributo que contiene cualquier paquete UDP y que mide cuántos saltos podrá dar un

mensaje. Cobra especial importancia ya que limita la profundidad a la que llegará la petición.

Cuando un nodo recibe un RREQ y comprueba que no es el destino de la ruta, mira si ya ha recibido

recientemente otro RREQ con la misma fuente, destino e identificación o si su propia dirección ya

aparece en el paquete. En cualquiera de los dos casos el nodo descarta el paquete silenciosamente.

Como en AODV, en DSR también es necesario ir recordando las peticiones que ya han sido contestadas

para evitar la saturación de la red respondiendo varias veces una misma petición. También se

comprueba que no aparezcan en la ruta que se ha ido construyendo para evitar que se produzcan

bucles.

En el momento en el que no se cumple ninguna de las dos condiciones anteriores y por tanto es la

primera vez que el nodo recibe la petición, comprueba primero en su tabla de rutas si existe alguna

hacia el nodo destino. Si fuera así, el nodo responde con un Route Reply (RREP) hacia el origen en lugar

de reenviar el RREQ. Por otra parte, si el nodo no encuentra ninguna ruta, entonces añade su

dirección en el paquete y lo reenvía mediante broadcast para intentar llegar al nodo destino o a otro

que conozca un trayecto hacia él. Si finalmente el nodo destino recibe un RREQ, procederá a contestar

la petición con un RREP al nodo fuente.

Para ilustrar la formación del camino de ida se va a emplear una ilustración la cual representa un claro

ejemplo de funcionamiento, donde se puede observar una secuencia de cómo se transmitirá un RREQ

en DSR. El nodo A inicia la petición y envía una petición poniéndose así mismo como primer nodo.

Cuando los nodos B, E y H reciben la petición y se cercioran de que no la han recibido antes se añaden


automáticamente a la lista de paquetes. Una vez hecho esto procederán a enviarlo de nuevo por

broadcast. Seguramente lleguen esos paquetes también a A, que los descartará silenciosamente.

Posteriormente los nodos C y F recibirán la petición, junto con E, que al ser la segunda vez que la

recibe, esta vez a través de H, la descartará. Tanto C como F vuelven a enviar la petición agregándose a

la lista que se va generando. Finalmente llegará a D a quién le corresponderá contestar ya que ninguno

de los nodos anteriores conocían una ruta hasta él.

Ilustración 24 Ejemplo formación de camino de ida para DSR

4. Formación del camino de vuelta

Existen dos situaciones en las que un nodo podrá contestar con un RREP. Cuando el nodo recibe una

petición de ruta en la que él es el objetivo. Enviará un RREP que contiene una copia de las direcciones

acumuladas en el RREQ recibido pero de manera invertida. En el caso de que la petición llegue a un

nodo que conozca una ruta hasta el nodo destino, entonces éste procederá a responder con una ruta

en la que los nodos son aquellos que conforman su ruta hacia el destino, añadiendo al final los nodos

por los que ha ido pasando el RREQ recibido. Este último proceso no es más que unir una parte del

camino que se ha descubierto con el RREQ, a otra parte ya conocida por el nodo que responde, que es

su ruta hacia el destino.

Además a diferencia del RREQ y como ocurre en AODV, los RREP no se transmiten en broadcast, sino

en unicast, saltando de nodo a nodo siguiendo la ruta marcada por el propio paquete hasta llegar al

nodo fuente.

Sobre el ejemplo que ilustraba la formación del camino de ida. Se propone para la respuesta.

Ilustración 25 Ejemplo de camino de vuelta para DSR

Como el nodo destino D responde a la petición iniciada por A. La cabecera es la misma que la que llegó

al nodo D pero ordenada de manera inversa. Se puede observar cómo el mensaje se va transmitiendo

de manera unidireccional hasta llegar al nodo emisor, en contraposición a los RREQ que se extienden

por toda la red.


Una vez el nodo origen recibe el RREP, éste guarda dicha ruta en su tabla de rutas. Esta ruta será

incluida en la cabecera de cada paquete que el nodo envíe, de esta manera todos los nodos que

van recibiendo el paquete sabrían cual es su próximo salto. Esto conlleva enviar más datos para

transmitir la misma información y por tanto una disminución del ancho de banda que se gastará

en enviar una y otra vez la ruta en los mensajes.

Por último, para el nodo A que ya recibió la ruta a través del RREP, puede enviar la información al

nodo D agregando la ruta completa en la cabecera y saltando de nodo en nodo hasta el destino.

Ilustración 26 Envio de datos establecido la ruta. DSR

5. Mantenimiento de camino

Cuando se envía un paquete a través de una ruta, cada nodo es responsable de confirmar que el

paquete se ha recibido en el siguiente nodo. Este reconocimiento se suele hacer a nivel de enlace.

Después de haber retransmitido un paquete un número máximo de veces, si el paquete no ha podido

ser recibido por el siguiente salto, entonces el nodo considera que el enlace está roto. En ese caso, el

nodo debe eliminar ese enlace de su caché y enviar un Route Error (RERR) a cada nodo que haya

enviado un paquete con una ruta que use el enlace roto.

Un paquete RERR está formado por los siguientes atributos:

Discriminador

Tamaño

Tipo de error: Existen tres posibles errores.

o NODE UNREACHABLE: Un RERR enviado con este tipo de error es lanzado cuando un

nodo detecta que no puede comunicarse con otro y necesita enviarle algún paquete.

o OPTION NOT SUPORTED: El protocolo DSR tiene varias funcionalidades que son

opcionales y no todas las implementaciones tienen porque proveerlas. Cuando un

nodo recibe alguna opción extra que no tiene implementada devuelve un RERR con

este tipo de error.

o FLOW STATE NOT SUPPORTED: Existe una funcionalidad adicional de DSR que es

conocer el estado del flujo de una ruta. Es un poco especial porque necesita una

cabecera algo distinta para implementarse. Cuando los nodos reciben un paquete de

este tipo y no tienen implementada esa opción deben responder con un RERR con este

tipo de error.

Dirección origen del error: dirección del nodo que origina el error de la ruta.


Dirección de destino: dirección del nodo a la cual este paquete debe ser entregado.

Información específica de error: Para la situación en el que el error sea nodo inalcanzable, este

campo contendrá el nodo con el que se perdió la conexión.

Cuando un nodo recibe un paquete RERR de tipo nodo inalcanzable comprueba si tiene alguna ruta

que contenga el salto que se ha roto. En caso de que fuera así, procederá a eliminar a todas ellas. Aquí

se puede observar otra diferencia entre AODV y DSR. En ambos protocolos el error es notificado hasta

el nodo fuente, pero en AODV se invalida completamente la ruta, mientras que en DSR se envía

simplemente el salto que ha dejado de funcionar, y de esta forma, aprovechando el conocimiento de

rutas completas, descartar otras rutas que también han quedado invalidadas.

Posteriormente comprobará si la dirección de destino del paquete es él mismo. En el supuesto de que

él no fuera el destino del paquete, éste procederá a reenviar el paquete para que siguiera su ruta.

Cuando el RERR llega finalmente al nodo fuente, además de eliminar todas las rutas que han quedado

inutilizables empieza lo que se denomina “salvamento del paquete". Se buscan rutas alternativas para

los paquetes que no se han podido transmitir a causa del fallo de la ruta. Si se encuentra alguna se

procederá a reenviar los mensajes con la ruta alternativa que no pudieron llegar anteriormente. De

esta forma se intenta realizar de nuevo la comunicación de manera absolutamente transparente para

el usuario, aunque se hayan producido errores durante los primeros intentos.

En el caso que no tenga ninguna otra ruta en su caché, el nodo origen tiene que iniciar un nuevo

descubrimiento de ruta para encontrar un nuevo camino hacia el nodo destino. En este proceso se

envía, junto con la petición de ruta, el mensaje de error recibido (piggybacking del mensaje de error)

para informar a los demás nodos del enlace roto y así evitar que respondan con una ruta que utilice el

enlace recién invalidado. En AODV, para evitar estos casos se utiliza simplemente el reloj lógico.


III. AOMDV

AOMDV comparte muchas características en su funcionamiento básico con AODV. Se basa en el

concepto de vector de distancia y utiliza la aproximación de salto en salto. Este protocolo además

descubre rutas bajo demanda utilizando un procedimiento de descubrimiento de ruta. La principal

diferencia es el número de rutas encontradas para cada descubrimiento de ruta. En AOMDV la

propagación de RREQ de fuente hacia el destino establece múltiples caminos en reserva junto con los

nodos intermedios al igual que el nodo destino.

Varios RREPS atraviesan estos caminos de retorno utilizando varias rutas. AOMDV también provee

nodos intermedios con caminos alternos, de esta manera se puede reducir la frecuencia de

descubrimiento de rutas.

El núcleo de AOMDV busca asegurar que se descubran múltiples caminos libres de lazos, además de la

eficiencia al encontrar rutas mediante inundación de la red. Este protocolo actualiza las reglas

aplicadas localmente a un nodo, juega un papel fundamental al mantener la red libre de bucles.

AOMDV confía en la información de ruteo bajo los lineamientos de AODV, en general no emplea

ningún control de paquetes, de hecho el envío de RREPS y RERRS para descubrir múltiples rutas y

mantenerlas, junto con capos extra en los campos de ruteo constituyen la única sobrecarga para el

protocolo.

IV. DYMO

1. Introducción

El protocolo DYMO es un protocolo reactivo que no envía paquetes de control si no está realizando

funciones de encaminamiento, transmisión o recepción de información, lo que es bueno para redes en

las que los recursos son escasos.

Básicamente DYMO tiene dos mecanismos de forma similar a otros protocolos reactivos como DSR o

AODV: el de descubrimiento de ruta, que se utiliza cuando en la tabla de encaminamiento no está la

ruta del nodo destino, y el de mantenimiento de ruta, que puede utilizar varias formas para descubrir

si una ruta se rompe. Hay tres posibles mensajes de control; el RE (Route Element) que engloba el

RREQ (Route Request) para descubrir una ruta, y el RREP (Route Reply) para contestar el

descubrimiento de una nueva ruta; el mensaje RERR (Route Error) que indica una ruta errónea y el

UERR (Unsupported-element Error) que es un mensaje de error no soportado por el protocolo.

El primero se envía en el descubrimiento de ruta y los dos ultimos se utilizan para el mantenimiento de

rutas. Dependiendo de la técnica de mantenimiento de las rutas empleada, también pueden existir

mensajes de hellos o de reconocimiento, todos estos enviados en UDP.

2. Descubrimiento de ruta

Siempre que un nodo intenta enviar un paquete a un destino, el emisor comprueba que el destino

esté en la tabla de encaminamiento. En el caso que ya exista esta ruta, el paquete envía la información


al siguiente nodo basándose en la tabla. En el caso de que no esté, se realiza el mecanismo de

descubrimiento de ruta.

Este mecanismo envía en modo broadcast el paquete RE indicando en un flag, que se trata de un

mensaje de control RREQ. Cuando se crea este mensaje el OwnSeqNum se tiene que incrementar en

una unidad. Los principales datos de este mensaje de control son:

El TTL indica el número de saltos que le faltan para desechar el paquete, cuando es creado el

valor es NET_DIAMETER.

La dirección del nodo a la que se quiere enviar datos.

El número de secuencia del nodo destino, en el caso que no se conozca este valor está a cero.

Número de saltos por el que ha pasado el paquete (THopCnt).

Estructuras de datos que informan del Encaminamiento en una dirección (Rblock).

Cuando se crea un RREQ se tiene que crear el primer RBlock, el cual contiene:

La dirección del nodo del RBlock al que pertence.

El número de secuencia del nodo que tiene la dirección en el bloque.

El número de saltos que ha pasado este bloque.

Un bit indicando si actúa como gateway.

El nodo que crea el RREQ se tiene que esperar RREQ_WAIT_TIME para poder enviar otro mensaje de

RREQ. Para reducir una posible congestión en la red, éste tiene que seguir un tiempo de backoff

binario exponencial, es decir, el primer intento de RREQ tiene que esperar el tiempo

RREQ_WAIT_TIME por dos, el segundo por cuatro y así sucesivamente. Se pueden hacer hasta

RREQ_TRIES intentos antes de notificar que el nodo no es accesible. En el descubrimiento de la ruta el

nodo emisor guarda los paquetes en un buffer, del que se borra la información si se agotan los

intentos.

En el caso que le llegue un RREQ a un nodo intermedio y éste no disponga de la dirección del nodo

destino, o el número de secuencia del RREQ (RBNodeSeqNum) sea superior al de su tabla de

Encaminamiento (Route.SeqNum), este paquete deberá actualizar la tabla de Encaminamiento del

nodo para realizer la ruta inversa. El nodo tiene que actualizar su OwnSeqNum sumándole uno,

introducer un nuevo RBlock con sus propios valores, disminuir el valor del TTL y sumarle un salto al

campo THopCnt. Una vez introducidos los cambios en el paquete se reenvía en modo broadcast.

Si un nodo recibe un paquete RREQ que contenga la dirección destino en su tabla de encaminamiento,

entonces compara si el Route.SeqNum es superior al TargetSeqNum del paquete. En caso que no lo

sea, se reenvía, ya que el nodo tiene caduca su tabla y actualize los campos. Cuando es superior el

nodo tiene que actualizar su OwnSeqNum su mándose uno y crear un paquete RE indicando que es

RREP de respuesta al descubrimiento. Se introducen los saltos que le falta para llegar a dicho nodo, el

número de secuencia del nodo destino, la dirección del siguiente salto y el RBlock del nodo que lo

emite. Este nodo no debe enviar ningún paquete de RREQ al destino, por lo que el nodo destino tiene

que hacer también un descubrimiento de ruta si desea realizar un enlace bidireccional.

Por último tenemos el caso que el nodo destino sea el que procesa el RREQ, en este caso el nodo


compara si el OwnNumSeq es superior al TargetSeqNum, en el caso que no sea así se descarta el

paquete. Contrariamente, si es superior, el nodo guarda los datos del RREQ en la tabla de

encaminamiento para un posible enlace bidireccional. El nodo debe crear un paquete RE indicando

que es una repuesta a un descubrimiento (RREP). Aumenta en uno el OwnSeqNum e introduce los

datos en el paquete, este paquete se transmite al último nodo que ha transmitido el RREQ.

Una vez se envía el mensaje RREP por la ruta inversa, los nodos tienen que transmitirlo de forma

unicast por la ruta inversa que le ha llegado el RREQ, estos nodos tienen que sumarle uno al

OwnSeqNum y actualizar su tabla de enrutamiento. Cuando es recibido por el creador del mensaje

RREQ, éste está preparado para transmitir los datos, estos son enviados vía el buffer.

3. Mantenimiento de las rutas

Cada nodo es el encargado de mantener el enlace del siguiente nodo. Cuando un nodo detecta la

pérdida de un enlace, éste crea un RERR y lo transmite a los nodos anteriores de la ruta. Para el

descubrimiento de una ruptura en una ruta. Cuatro son las posibles alternativas:

Reconocimiento en la capa de enlace.

Mensajes de Hellos.

Descubrimiento de vecinos.

Timeout de ruta: Este mecanismo no transmite el RERR. Una vez pasado un tiempo

ROUTE_TIMEOUT la ruta queda inhabilitada, este tiempo va actualizandose cada vez que pasa

un paquete por el nodo que utiliza dicha ruta.

Cuando un nodo descubre una ruptura, este tiene que crear un paquete RERR, el caul tiene que

introducir en el campo UNodeAddress1 la dirección del nodo inalcanzable, en el caso que se sepa el

número de secuencia del nodo se introduce en el campo UNodeSeqNum. En caso que se conozca, este

campo toma valor cero. En el campo TTL se introduce el NET_DIAMETER y se envía en modo

broadcast, si hay otra ruta que es perjudiciada por la ruptura del enlace, se introduce también en el

paquete RERR, en el cual se añadem nuevos campos de dirección y de numerous de secuencia.

Cuando un nodo recibe un RERR tiene que invalidar la ruta si:

La ruta que invalida tiene como siguiente salto la misma dirección IP del paquete que ha

transmitido el RERR.

La ruta que invalida tiene como siguiente salto la interfaz del paquete que ha transmitido el

RERR.

El número de secuencia del nodo que nos ha llegado es cero o el resultado de restar el

Route.SeqNum del nodo destino y el número de secuencia de la ruta inalcanzable del paquete

es menor o igual a cero

Si no pasa por algún filtro de éstos, la ruta inválida se retira del paquete y si el RERR contiene alguna

ruta más se reenvia en modo broadcast. En caso que el paquete ya no tenga nunguna ruta inválida,

éste ya no transmitirá más. Si el paquete pasa todos los filtros, el nodo tiene que reenviarlo en modo

broadcast bajando el campo TTL.


Protocolos Proactivos 2.

En este tipo de protocolo periódicamente se emiten paquetes de datos utilizados para descubrir

nuevos nodos en la red y la ruta hacia ellos, presuponiendo que en algún momento dichas rutas serán

necesarias y utilizadas. Se usa una tabla para mantener actualizadas todas las rutas a los distintos

nodos. Las principales desventajas que presenta este tipo de protocolo son la generación de tráfico de

mantenimiento y actualización de las tablas de enrutado, que disminuye el Troughput, y la lenta

reacción ante cambios o fallos en la topología.

I. DSDV

1. Introducción

Destination Sequenced Distance Vector (DSDV) ha sido uno de los protocolos proactivos más

populares para redes ad-hoc. Esta propuesta de encaminamiento fue presentada por Per-kins y

Bhagwat en 1994 y su funcionamiento se basa en el algoritmo vector-distancia de Bellman-Ford (BF). A

pesar de la simplicidad y eficiencia de este algoritmo, es bien sabido que éste puede ocasionar la

creación de bucles. Una de las primeras causas que propician este problema es que los nodos

seleccionan, basándose en información que se obtiene de manera distribuida, al nodo inmediato que

permite enviar un paquete de datos hasta un nodo destino; sin embargo, esta decisión puede estar

basada en información antigua y muy probablemente incorrecta. Cuando esto sucede, un paquete

puede ser enviado por un bucle y continuar transitando en el mismo aun cuando el nodo destino a

donde va dirigido es inalcanzable en la red y su ausencia no fue detectada a tiempo. En una red ad hoc,

la movilidad, y en consecuencia los cambios de la topología, requieren que cada nodo sea capaz de

detectar oportunamente la ausencia de un nodo con el que evitar el envío de información a través de

bucles en las trayectorias.

Para atender este problema, DSDV utiliza números de secuencia y al mismo tiempo mantiene la

simplicidad del algoritmo de BF. Dado que este protocolo es de carácter proactivo, el intercambio de

información de encaminamiento y el cálculo de rutas de comunicación se realiza de manera periódica,

de este modo, cada nodo obtiene y procesa información actualizada y confiable de la organización de

la red. El funcionamiento distribuido de este protocolo demanda que cada uno de los nodos que

componen la red comparta su tabla de encaminamiento con sus nodos vecinos. Solo de este modo,

cada nodo podrá calcular, para cada destino dentro de la red, al nodo vecino que proporcione la mejor

ruta de comunicaciones.


El procedimiento de descubrimiento de ruta utiliza información, principalmente sobre la forma en la

que se organiza la red, para determinar el camino óptimo que permite enviar información desde un

nodo fuente hasta un nodo destino.

DSDV es un protocolo que utiliza tablas de encaminamiento para almacenar y compartir las rutas

óptimas de comunicación. Cada uno de los nodos que compone la red, administra su propia tabla de

encaminamiento y en ésta se almacenan todos los posibles destinos de la red, el costo del camino para

llegar a cada uno de ellos así como el nodo inmediato que le permite comunicarse con cada nodo

destino de manera óptima. Para poder construir esta tabla de encaminamiento tan detallada es


necesario conocer la topología de la red, y una forma de hacerlo es a través de la cooperación de los

elementos que la componen. El protocolo DSDV exige que cada nodo comparta su visión de la red con

sus nodos vecinos y al mismo tiempo la reciba de éstos. Cuando este procedimiento se realiza en

repetidas ocasiones, cada nodo puede obtener una visión global de la red. Con esta información, cada

nodo puede determinar cuál es el nodo vecino que ofrece el mejor camino de comunicación hacia un

nodo destino; este resultado es almacenado en la tabla de encaminamiento y compartido de nueva

cuenta con los nodos vecinos. Cada uno de los elementos que se almacena en esta tabla de encamina-

miento es etiquetado con un número de secuencia. Este número de secuencia es un contador,

administrado por cada nodo destino, el cual es adjuntado e incrementado por cada paquete de

señalización enviado por este nodo. Este identificador permite discernir la información actualizada de

aquella que no lo es.

Para mantener actualizada la información sobre la topología de la red en cada nodo, DSDV requiere

que cada uno de ellos comparta periódicamente los datos que residen en su tabla de

encaminamiento. Para que este procedimiento sea significativo, la frecuencia con la que se comparte

esta información debe ser lo suficiente como para detectar los cambios que suceden en la red. En la

Ilustración 27 se ejemplifica la carga de señalización necesaria para la utilización de DSDV en una red

compuesta por 9 nodos. Cada mensaje de señalización, en su forma más elemental, está integrado

por:

Su número de secuencia actualizado, correspondiente al nodo que envía el paquete de

señalización.

El identificador del nodo de destino.

El número de saltos necesarios para llegar al nodo destino.

El número de secuencia actualizado y correspondiente al nodo destino.

Cada vez que un nodo recibe información de la tabla de encaminamiento de sus nodos vecinos,

almacena o actualiza la ruta de comunicaciones tomando como base las siguientes condiciones:

Cualquier ruta con un número de secuencia más reciente comparada con el de la misma ruta

almacenada, será seleccionada.

Si una ruta tiene el mismo número de secuencia pero menor costo de encaminamiento,

entonces esta dicha ruta se escoge.


Ilustración 27 Carga de señalización en Dsdv

Haciendo referencia a la Ilustración 28, cuando el nodo X recibe información proveniente de Y

sobre la ruta para comunicarse con Z, y asumiendo que el último número de secuencia de Z visto

por X es Xz y el último visto por Y es Yz, el proceso de actualización de la ruta deberá satisfacer las

siguientes condiciones:

Si Xz > Yz, se ignora la información de encaminamiento recibida de Y.

Si Xz = Yz, se toma en consideración el costo de la ruta. Aquella cuyo costo sea el menor

será almacenada en la tabla de encaminamiento.

Si Xz < Yz, X selecciona a Y como el siguiente salto para alcanzar a Z y se asigna a Xz el valor

de Yz.

Ilustración 28 Envio de un paquete de señalización DSDV

Cuando un enlace de comunicaciones se pierde, ocasionado principalmente por la movilidad de

los nodos, la distancia hacia este nodo se define como infinita. Y si este nodo es un nodo vecino

que sirve como salto inmediato para llegar a otros nodos, la distancia hacia estos nodos también

se considera infinita. Este evento se envía inmediatamente para que se propague en la red y alerte

a los otros nodos. La movilidad, es un evento que puede provocar la pérdida de enlaces de

comunicación, y en un entorno altamente dinámico sus efectos serán desastrosos, pues la

cantidad de mensajes de señalización, necesarios para dar aviso de estos eventos, se incrementará

al grado de consumir gran parte de los recursos de la red. La solución para este tipo de eventos

consiste en utilizar dos tipos de mensajes de control: el primero (full dump), contiene toda la

información de la tabla de encaminamiento y el segundo (Incremental Dump) solo contiene los

cambios menores que ha sufrido la tabla de encaminamiento desde el último full dump enviado.


II. OLSR

1. Introducción

Se trata de un protocolo basado en el estado de enlace. OLSR es una optimización directa del

algoritmo de estados de enlace adaptado a los requisitos específicos de una WLAN con alta movilidad.

La optimización consiste principalmente en la reducción del tamaño de las tablas de enlaces

intercambiadas así como del número de retransmisiones necesarias durante los periodos de

inundación. La clave del algoritmo reside en el uso de retransmisiones multipunto (MPR).

El concepto principal de este protocolo es que en lugar de que cada nodo retransmita cualquier

mensaje que reciba de entre sus vecinos, todos los nodos de la red seleccionan entre sus vecinos un

conjunto de multipoint relays (Retransmisores) que se encargan de retransmitir los mensajes que

envía el nodo en cuestión. El resto de nodos vecinos no pueden retransmitir de modo que se reduce el

tráfico generado por inundación.

2. Descubrimiento de ruta

Para descubrir la topología de la red, los nodos intercambian información acerca del estado del enlace

que los conectan con los nodos MPR. Los intercambios son periódicos o generados por eventos

relativos a rupturas de enlace. Incluir en las tablas sólo los enlaces a los nodos MPR reduce el tamaño

de las mismas, lo que permite reducir el ancho de banda consumido durante su intercambio. Al

mismo tiempo permite que las rutas que se vayan creando a posteriori sean óptimas en cuanto a

números de saltos ya que sólo usan nodos MPR. OLSR se adapta bien a redes con un gran número de

nodos y alta movilidad.

Para una red enrutada con OLSR son dos los tipos de mensajes intercambiados:

Los mensajes HELLO, los cuales son enviados periódicamente por cada nodo de la red a sus

nodos vecinos, pero nunca son retransmitidos más allá del primer salto desde su emisor. Estos

mensajes contienen la lista de vecinos conocidos por el nodo emisor así como la identidad de

los multipoint relays seleccionados por el transmisor. Su intercambio permite a cada nodo de

la red conocer los nodos situados a 1 y 2 saltos de distancia (es decir, aquellos a los que se

puede hacer llegar un mensaje con una transmisión directa o con una transmisión indirecta) y

saber si ha ido seleccionado como MPR por alguno de sus vecinos.

Los mensajes TC (Topology Control) son enviados periódicamente y de forma asícrona. A

través de ellos, los nodos informan al conjunto de la red acerca de su topología cercana. Al

contrarioi que los HELLO, los mensajes TC son de alcance global y deben llegar a todos los

nodos de la red. El conjunto de los mensajers TC recibidos por un nodo inalámbrico le permite

reconstruir su base de datos topológica, computar el árbol de caminos mínimos y calcular así

su tabla de encaminamiento hacia todas las posibles destinaciones. La diseminación de

mensajes TC se hace de acuerdo con el mecanismo de inundación basado en MPR.


Protocolos Híbridos 3.Este tipo de protocolos auna las ventajas de los protocolos proactivos y reactivos.

I. ZRP

1. Introducción

Para este protocolo todos los nodos mantienen proactivamente dentro de una zona local conocida

como zona de encaminamiento (IARP). Sin embargo, a nivel global ZRP emplea mecanismos reactivos

(IERP) para encaminar los paquete4s entre las áreas locales.


Se define un parámetro llamado Radio de la zona y que define una zona local de encaminamiento. ZRP

mantiene las rutas hacia todos los nodos que se encuentran a una distancia menor o igual al radio de

la zona, implementando mensajes HELLO.

El IERP está basado en un mecanismo de distribución de mensajes conocido como “Bordercast

Resolutioin Protocol” (BRP). La ventaja de este sistema sobre el broadcasting es que en lugar de

recorrer la red nodo por nodo, BRP permite que las consultas sean dirigidas fuera de la red local y

hacia regiones de la red que no hayan sido cubiertas por la consulta. Para llevar a cabo ese mecanismo

es necesario tener un control de las consultas para saber que regiones han sido cubiertas y no volver a

mandar mensajes redundantes. Cuando un nodo detecta que un nodo ha mandado una consulta,

todos los miembros de su zona vecindaria se marcan como cubiertos.

Para mandar tráfico el nodo comprueba si el destino está en su tabla de encaminamiento local. Si no,

manda una consulta mediante el algoritmo de bordercast. Cuando un nodo recibe la consulta, verifica

si el nodo está en su zona o si tiene alguna ruta válida hacia el destino. Si la respuesta es afirmativa, el

nodo enviará un RREP hacia la fuente. Si la respuesta es negativa se difunde la consulta a sus vecinos

mediante bordercast.

Para que el protocolo funcione de manera correcta es importante que el radio de la zona sea

adecuado al tipo de red en cuestión. Se recomiendan radios pequeños para redes densas compuestas

Ilustración 29 Mecanismo de inundación en OLSR


de grupos con pocos nodos que se mueven rápido, y radios mayores para redes dispersas de nodo con

movilidad más baja.

Ilustración 30 Protocolo ZRP


4. MODELOS DE MOVILIDAD

Introducción 1.

Un modelo de movilidad es un conjunto de reglas que unidas entre sí describen el comportamiento

espacial de cuerpos durante un periodo de tiempo. En este trabajo los modelos de movilidad se

refieren exclusivamente a vehículos. Un modelo de movilidad es una pieza más en un sistema que

pretende interconectar varios vehículos. En concreto, es la parte que se encarga de describir cómo

tiene que desplazarse un vehículo y qué decisiones tiene que tomar.

Los distintos modelos muchas veces eligen entre complejidad y detalle, es decir, eligen entre

aproximarse a la realidad de una forma relativamente simple, analizando los principales factores, o

aproximarse a la realidad con el máximo de detalle posible, estudiando todos los factores que parecen

influir. En cualquier caso es importante que los modelos de movilidad sean fieles a la realidad. Para

conseguirlo es necesario tener en cuenta aspectos básicos que influyen en la movilidad:

Trazado de las calles: Los vehículos tienen que moverse obligatoriamente dentro de las calles,

por lo que la movilidad queda limitada a su trazado.

Tamaño de la manzana: Una manzana puede ser considerada como la menor área rodeada

por calles. El tamaño de la manzana determina el número de intersecciones en un área y por

tanto establece la frecuencia con la que un vehículo tiene que parar en una intersección y la

distancia a la que un vehículo vecino es capaz de detectar la transmisión de otro vehículo.

Mecanismos de control del tráfico: Las formas más comunes de controlar las intersecciones

son las señales de stop y los semáforos. Estos mecanismos crean clusters y colas de vehículos

en las intersecciones. Como es lógico estas colas provocan una reducción de la media de la

velocidad de los vehículos. La disminución de la velocidad favorece que haya menos cambios

en el enrutamiento de datos de la red. Pero por otra parte los clusters de vehículos pueden

afectar negativamente al funcionamiento de la red por suponer un aumento en la contención

del canal.

Movimiento independiente de los vehículos: A pesar de que cada vehículo puede tomar sus

propias decisiones, éste se mueve influido por los vehículos que le rodean.

Velocidad media: La velocidad de un vehículo establece cómo de rápido cambia su posición, lo

que determina a la vez cómo cambia la topología de red. La media de velocidad varía en

función de los límites de velocidad establecidos las características y el estado de la calzada, la

aceleración y deceleración, y la topología de las calles. Del mismo modo, si hay pocas

intersecciones los vehículos aceleran a velocidades mayores que si hay muchas intersecciones.


Descripción de los modelos de movilidad 2.

Son varios los modelos de movilidad que se van a presentar en este capítulo aunque solo se obtendrán

resultados de alguno de ellos.

Movimiento a velocidad constante

El modelo de movimiento a velocidad constante (CSM, Constant Speed Motion) es el típico ejemplo de

modelo estocástico, por lo que el movimiento de los vehículos es generado bajo parámetros

aleatorios. El movimiento de los coches está estructurado en trayectos, que es el movimiento entre

dos puntos correspondientes a un origen y un destino. Al principio de un trayecto un vehículo elige su

siguiente destino. Una vez elegido el destino el vehículo calcula la ruta basándose principalmente en el

camino más corto posible. Este modelo tiene la desventaja de que calcula el movimiento de los

vehículos de forma individual. Al no tener en cuenta los vehículos que le rodean, pueden producirse

solapamientos entre vehículos. También hay que señalar que este modelo explica bien el movimiento

para vehículos aislados pero, sin embargo, falla para explicar el movimiento de grupos de vehículos,

pueden producirse solapamientos entre vehículos. También hay que señalar que este modelo explica

bien el movimiento para vehículos aislados pero, sin embargo, falla para explicar el movimiento de

grupos de vehículos.

Puesto que este modelo calcula la velocidad que han de llevar los vehículos a continuación según

siguiente ecuación:

Ecuación 1 Modelo de moviento a velocidad constante

Donde es una variable aleatoria uniformemente distribuida comprendida entre 0 y 1. Este modelo

incluye la posibilidad de realizar paradas durante la duración del viaje de un vehículo. Supone una

forma rudimentaria de gestionar las paradas durante un trayecto.

Manhattan Grid Model (ManhattanGrid)

Se trata de un modelo de movilidad de ciudad, el área de simulación es una red de calles que

representan una parte de la ciudad donde existe una red ad hoc. Las calles y los límites de velocidad

están basados en el tipo de ciudad que está siendo simulada. Por ejemplo, las calles pueden formar

una rejilla en el centro de la ciudad. Cada nodo móvil empieza la simulación en un punto definido de

alguna calle. Los nodos en este caso cuando llegan a una intersección eligen aleatoriamente cuál

será la siguiente calle que seguirán. Los vehículos ya no se solapan. Por contra este modelo

presenta como desventaja que falla en la gestión de las intersecciones.

Las ecuaciones que describen las velocidades de los nodos son:

{

Ecuación 2 Descripción de la velocidad según el modelo de Manhattan


La Ecuación 2 añade una restricción para evitar que los vehículos se solapen, lo que en este caso se

considera una colisión con otro vehículo. Esta ecuación implica que si un vehículo ha alcanzado la

distancia de seguridad mínima, entonces hay que frenar. Si no se aplica la forma estándar de calcular

la velocidad en el modelo.

} }

Ecuación 3 Restricción sobre los límites de velocidad en el modelo Manhattan

La Ecuación 3 propuesta para este modelo supone que la velocidad de un vehículo no puede ser

más pequeña que el valor mínimo de y tampoco puede superar el valor máximo de

durante cualquier instante del trayecto. El modelo de Manhattan añade la aceleración de forma

aleatoria a la descripción de la velocidad.

Modelo de Kerner

También conocido como teoría de las tres fases del tráfico. Se centra principalmente en las

congestiones de vehículos. Para explicarlas define tres estados frente a los dos estados que se

usaban clásicamente:

Flujo libre: se da cuando la tasa de vehículos por tiempo es menor que la densidad de

vehículos. Si no se cumple esta condición se considera que el tráfico está congestionado.

Cuando hay flujo libre, los vehículos pueden circular sin problemas de congestión.

Flujo sincronizado: se da en el tráfico congestionado y se caracteriza por tener una densidad

de tráfico que permite viajar con fluidez pero que en ocasiones puede obligar a reducir la

marcha. La punta del flujo de tráfico se comporta como en flujo libre pero a una determinada

distancia de ésta se crea un cuello de botella.

Amplio congestionamiento: es un caso de tráfico congestionado que se da cuando la

densidad de tráfico es extremadamente alta y la velocidad a la que circulan los vehículos es

casi nula. Este caso se caracteriza porque en la parte delantera de la congestión los vehículos

aceleran cambiando su estado a flujo libre y los vehículos de detrás van frenando cambiando

su estado a amplio congestionamiento.

Este modelo también explica cómo se da la transición entre los diversos estados y sus características.

Modelo de Krauβ

Es un modelo de movilidad basado en los vehículos predecesores. La idea es que los vehículos deben

ajustar su velocidad a la del vehículo predecesor para evitar colisiones. La velocidad está definida

según la siguiente ecuación:

Ecuación 4 Velocidad según el modelo de Krauβ


Donde es la velocidad, t es el tiempo, es el tiempo de reacción y ƞ es una variable aleatoria entre 0

y 1. En esta ecuación se ve claramente que la velocidad está restringida continuamente por los

vehículos de alrededor (apreciable en los parámetros y ).

Modelo de conducción inteligente

Se trata de un modelo determinista. La aceleración de un vehículo depende de la suya propia, de la

de los vehículos que le rodean y del espacio que tiene con el vehículo precedente. Propone

además la posibilidad de simular el comportamiento de conductores distintos. Para simular este

comportamiento vamos a suponer tres tipos de conductores: agresivo, normal y tímido.

Asimismo se consideran las diferencias entre conductores de coches y camiones. Este tipo de

comportamiento se rige por la siguiente ecuación:

√

Ecuación 5 Distancias entre vehículos según el modelo IDM.

La Ecuación 5 hace referencia a la distancia existente entre vehículos tomando para su cálculo los siguientes parámetros:

Velocidad deseada : Es la velocidad máxima que un conductor desea alcanzar en condiciones

en las que la densidad de tráfico permite circular con rapidez. Un conductor normal elegirá la

velocidad máxima legal, mientras que un conductor agresivo sobrepasará esta velocidad y

finalmente, un conducto tímido circulará por debajo de esta velocidad. Los camiones por su

parte, en la mayor parte de países, se ven sometidos a fuertes restricciones de velocidad, por

lo que suelen comportarse como conductores normales.

Tiempo espacial deseado: Este factor se refiere a distancia preferida por un conductor a

una velocidad v. Es decir, la distancia que hay entre un vehículo y otro a una velocidad v. Este

factor suele tener un valor típico de 1.4 s.

Distancia mínima entre parachoques : Cuanto más agresivo es un conductor menor es

la distancia entra parachoques que deja. Los conductores de camiones, en cambio, dejan una

mayor distancia debido a la distancia que necesitan estos vehículos para frenar.

Aceleración deseada a: Describe el comportamiento de un conductor durante las

aceleraciones. Como es de esperar, cuanto más agresivo es un conductor mayor es la

aceleración aplicada. Hay que tener en cuenta que esta aceleración está supeditada a

restricciones físicas, por lo que la aceleración en un camión necesariamente será, en general,

menor que la de un coche.

Frenado confortable b: Describe la deceleración de un vehículo al aproximarse a un obstáculo

en la calzada. Los conductores agresivos se aproximan a gran velocidad, por lo que es

necesario que la deceleración aplicada sea superior que en un conductor tímido que se

aproxima lentamente. Como se puede comprobar, cuanto más agresivo es un conductor,

mayor es el valor de deceleración.


Parámetros IDM Normal Tímido Agresivo Común

Velocidad deseada (en Km/h) 120 100 140 85

Tiempo espacial T deseado (en s) 1.5 1.8 1.0 2.0

Distancia de seguridad (en m) 2.0 4.0 1.0 4.0

Aceleración a máxima (en

) 1.4 1.0 2.0 0.7

Deceleración b (en

) 2.0 1.0 3.0 2.0

Tabla 7 Parámetros para simular el comportamiento de tres tipos de conductores y de conductor de camión

También existen otras variables de modelos de conducción inteligente, IDM con gestión en las

intersecciones e IDM con cambio de carril, aunque no se hará enfasis en ellos.

Herramientas para la generación de los modelos de movilidad 3.

En el presente documento se emplearán dos herramientas distintas y cada una de ellas se emplearán

para reproducir un determinado modelo de movilidad.

BonnMotion

BonnMotion es una herramienta programada en Java que permite generar escenarios sintéticos

según los diferentes patrones de movilidad y distribución. Está implementada y tiene copyright por la

University of Bonn en Alemania.

Esta herramienta es de común uso en la comunidad de investigación para generar escenarios de

movilidad diversos. Es compatible con formatos NS-2, que a su vez se pueden cargar en NS-3 utilizando

las librerías de compatibilidad.

Son dos las formas de hacer uso de esta herramienta. La primera, a través de la línea de comado. Y la

segunda sería a través de un fichero de texto. Para este trabajo se ha usado la primera de ellas.

Son varios los modelos de movilidad que se pueden simular haciendo uso de esta herramienta aunque

en este caso se ha empleado para generar el modelo de ManhattanGrid.

No obstante presenta una serie de parámetros comunes para todos los modelos a simular:

Número de nodos a simular: “-n”

Dimensiones, en metros, del escenario: “-x” “-y”

El valor de la semilla: “-R”

Tiempo transcurrido hasta iniciar la creación del escenario: “-d” e “i”. Hay algunos modelos

en los cuales al comienzo de la simulación todos los nodos se encuentran en el centro y


esta situación puede no resultar óptima.

Para el caso que nos concierne, ManhattanGrid, además de los parámetros anteriormente descritos

también resulta de interés otros más.

Número de calles: “-u” “-v”

Ilustración 31 Ejemplo de escenario Manhattan Grid

Para el ejemplo mostrado en la imagen anterior los valores de u y v son 3 y 2 respectivamente.

Velocidad máxima de los nodos: “-p”

Establece la velocidad máxima que podrá alcanzar un vehículo en un determinado momento.

Citymob for Roadmaps (C4R)

Se trata del otro generador de movilidad que se va a emplear en el presente trabajo.

Es un generador de trazas de movilidad para redes de vehículos. Esto significa que es un software que

permite simular el tráfico en distintas localidades, valiéndose para ello, de mapas de ubicaciones

reales. Citymob for Roadmaps es una herramienta software libre, ya que su finalidad es ser usado por

la comunidad científica. Se permite tener acceso al código fuente para determinar la validez de sus

algoritmos y a la vez, permite realizar adaptaciones y correcciones por los propios usuarios si son

requeridas.

El funcionamiento básico de esta herramienta resulta muy intuitivo, no obstante a continuación se

presenta una breve guía de cómo hacer uso de ella.

1. Generar/importar mapa del proyecto.

Ilustración 32 Barra menú-Selección de mapa

Desde este botón se abre una vista que permite seleccionar un mapa a través de openStreetMap.

Además de seleccionar un mapa también existe la posibilidad de importar un mapa, es decir usar un

mapa que ya haya sido generado utilizarlo para generar el modelo de movilidad.

Seleccionado el mapa, la vista previa del mismo tendría un aspecto como sigue:


Ilustración 33 Vista de un mapa cargado con OpenStreetMap

2. Añadir vehículos

La adición de vehículos, visto desde el punto de vista del desplazamiento que realizan, puede hacerse

de manera aleatoria o manual.

a. Aleatoriamente

Ilustración 34 Adición de vehículos aleatoriamente

Son varios los parámetros que se pueden configurar:

Número de vehículos

Número de vehículos, entre 0 y 1, que aparecen en las zonas de atracción.

Instante en el que aparecen los vehículos.

Ilustración 35 Configuración modelo aleatorio

b. Manualmente

Para este caso se marca el punto de origen y el punto de destino en el mapa así como el número de

vehículos y el instante de inicio del movimiento.


Ilustración 36 Configuración del modelo manual

c. Vehículos con unas características especiales

Permite configurar determinadas características en el comportamiento de un vehículo.

Ilustración 37 Configuración de vehículos especiales

Todas las variables a configurar tienen un nombre bastante intuitivo, por lo que no merecen especial

atención excepto una de ellas sigma que mide la imperfección del conductor durante la conducción.

3. Centros de atracción

El área del mapa que se marque como tal tendrá la característica de que todos los vehículos tendrán

tendencia a acercarse a él, en función de una constante que se configura a la hora de crearlo.

Ilustración 38 Configurar centro de atracción

Ilustración 39 Configuración del centro de atracción

4. Selección del modelo de movilidad


Ilustración 40 Configurar modelo de movilidad

En los apartados de simulación que se exponen más adelante se darán los valores exactos de cada una

de las variables requeridas para la simulación.


5. ENTORNO DE TRABAJO

Las herramientas de simulación son un elemento clave en el diseño de redes Ad-hoc, debido a que

éstas por naturaleza están compuestas por un gran número de nodos, lo que implica un coste de

implantación elevado. Es por ello que las herramientas de simulación son fundamentales cuando se

quiere proponer nuevos diseños. Es necesario comprobar la idoneidad de una nueva composición de

red antes de ponerla en práctica en escenarios reales.

Las redes de sensores inalámbricas (WSN) pueden ser consideradas un ejemplo particular de redes Ad-

hoc. Ambas redes comparten problemas parecidos, ambas redes están compuestas por un gran

número de nodos, estos nodos pueden ser móviles o estáticos. El consumo energético es un desafío

en ambas redes, debido a que se desea que los nodos tengan una larga autonomía.

En el presente capítulo se van a evaluar dos elementos claves a la hora de elegir una herramienta de

simulación:

Comprobar que los modelos utilizados son correctos.

La idoneidad de la herramienta de simulación para implementar los modelos.

1. Modelado

En la Ilustración 41 se representa el modelo general de una herramienta de simulación de redes.

Se consideran los siguientes componentes:

Nodos, cada nodo es un dispositivo físico que mide variables físicas del entorno que le rodea.

Cada nodo es capaz de comunicar con sus nodos vecinos. Cada nodo internamente

implementa una pila de protocolos.

Entorno, la principal diferencia con respecto a las redes convencionales es el hecho del

modelado del entorno que rodea cada nodo. Además, los nodos medirán alguna variable

característica de dicho entorno.

Radio canal, este componente caracteriza la propagación de la señales a través del medio.

Nodos “sink”, son los encargados de recolectar toda la información medida por las redes de

sensores. Este tipo de nodos normalmente tiene una mayor capacidad de procesamiento, y

suelen estar conectados a un nivel superior de red, como puede ser internet.

Agentes, generador de eventos de interés. Es decir, la herramienta de simulación debe generar

los eventos de interés para los nodos. Este componente es útil cuando su comportamiento

puede ser implementado de manera independiente al entorno.


Ilustración 41 Modelo de simulación de redes de sensores

En la siguiente Ilustración 42 se representa un posible modelo de un nodo en una red de sensores. Se

pueden destacar los siguientes componentes:

El stack de protocolos implementados en el nodo, normalmente este stack está compuesto por

un protocolo MAC, un protocolo de enrutamiento y protocolo específico de aplicación.

Physical-node representa la plataforma hardware. Modela las características físicas de los

nodos en la red de sensores. Es importante el modelo energético implementado en el modelo,

ya que como se comentó anteriormente el consumo de energía es un parámetro fundamental

en redes ad-hoc. Otros aspectos de los nodos también son tenidos en cuenta en este

componente, como son, movilidad, posiciones, etc.

El componente medio, los nodos con el mundo real que les rodea. Los nodos están conectados

al mundo real a través de un canal radio, o a través de canales físicos.

Ilustración 42 Modelo de nodo


2. Herramienta de simulación de red

Las simulaciones asistidas por ordenador modelan objetos o actividades hipotéticas o de la vida real,

permitiendo estudiar cómo funciona un sistema si se eligen adecuadamente los parámetros que lo

caracterizan. Concretamente, los simuladores de red se emplean para diseñar, simular, verificar y

analizar el rendimiento de protocolos y algoritmos de una manera controlada y reproducible. Por lo

general, un simulador de red reúne una amplia gama de tecnologías y protocolos de red, ofreciendo la

posibilidad de crear redes complejas compuestas de elementos básicos tales como equipos finales,

concentradores, conmutadores, encaminadores o unidades móviles. Las áreas de aplicación de los

simuladores de red son tan dispares como la investigación académica, los desarrollos industriales y los

procesos de garantía de calidad. En el área de las redes de ordenadores, es muy costoso implementar

un banco de pruebas completo con varios equipos, encaminadores y enlaces. Afortunadamente, los

simuladores de red permiten analizar a bajo coste una gran variedad de escenarios. No obstante, los

simuladores de red no son ideales, ya que no pueden modelar perfectamente todos los detalles reales.

Sin embargo, si están bien diseñados, serán lo suficientemente precisos para ofrecer una idea del

funcionamiento de la red real. Es por ello por lo que conviene estudiar qué características ofrecen los

simuladores de red disponibles para conocer cuál es el más conveniente en cada circunstancia.

2.1. Comparativa de heramientas de simulación de red

Actualmente existen en el mercado numerosos simuladores de red que presentan variadas

características. Una breve lista de los simuladores actuales más extendidos incluye ns-2, ns-3,

OMNeT++, OPNET, REAL, SSNFNet, QualNet, J-Sim y TOTEM. Los más ampliamente empleados son los

cuatro primeros: ns-2, ns-3, OMNeT++ y OPNET, los cuales, además, representan la evolución reciente

en el campo de los simuladores de red. En las siguientes páginas se ofrece una síntesis de las

características más relevantes de estos cuatro simuladores bajo estudio.

Simulador de red ns-2

El simulador de red ns-2 (Network Simulator version 2) es uno de los simuladores de red de código

abierto más populares. Su nombre proviene de su segunda versión, ampliamente extendida. La

primera versión, desarrollada en 1989, se basa originalmente en REAL, un simulador de eventos

discretos orientado a la creación de redes de investigación. El proyecto actual bajo el que se desarrolla

el simulador cuenta con el apoyo de la Agencia de Investigación de Proyectos Avanzados de Defensa

de los Estados Unidos, (DARPA, Defense Advanced Research Projects Agency). El simulador de red ns-2

fue desarrollado originalmente en la Universidad de California, Berkeley, y al igual que su predecesor,

está basado en eventos. Emplea dos lenguajes de programación, C++ y OTcl (Object Tool Command

Language), ambos orientados a objetos. En las siguientes secciones se profundiza en esta

herramienta, ya que se trata del simulador de red elegido para la generación de datos.

Simulador de red ns-3

El simulador de red ns-3 guarda muchas semejanzas con ns-2, ya que también es un simulador de red

basado en eventos de código fuente libre y está dirigido primordialmente a la investigación y al uso

educativo. El simulador ns-3 está diseñado para sustituir al simulador ns-2. No obstante, ns-3 no es

una mera versión actualizada de su predecesor, por el contrario, la nueva herramienta ha sido


completamente rediseñada y no es compatible hacia atrás. En comparación con ns-2, ns-3 pone

mucho más énfasis en la documentación y emplea Python en lugar de OTcl.

Simulador de red OMNet++

El simulador de red OMNet++ es también un simulador de código público y está respaldado por una

potente interfaz gráfica de usuario (GUI, Graphical User Interface). Su principal área de aplicación es el

ámbito de la industria y no el de la investigación. Es especialmente adecuado en redes de

comunicaciones, sistemas de información y telecomunicaciones, redes de colas, arquitecturas

hardware, y procesos de negocio.

Simulador de red OPNET

El simulador de red OPNET es uno de los simuladores de red comerciales más extendidos. Se trata de

un simulador muy robusto y que copa una gran cuota de mercado especializada en la investigación y

desarrollo de redes en la industria. Puede ser utilizado con flexibilidad para estudiar redes de

comunicación, dispositivos, protocolos y aplicaciones. Por el hecho de tratarse de software comercial,

la compañía OPNET ofrece a los usuarios una interfaz gráfica potente y robusta. El editor, a través de

esta interfaz gráfica, puede ser utilizado para configurar topologías de red desde la capa física hasta la

capa de aplicación.

2.2. Justificación de la elección del simulador de red ns-2

El simulador de red ns-2 es la herramienta elegida para la obtención de datos experimentales en el

presente proyecto. Una de las principales razones es que goza de gran popularidad en el mundo

académico, constituyendo un estándar de-facto para la investigación en una amplia variedad de áreas

en el campo de las redes. Numerosos artículos, hacen uso extensivo de ella para la ejecución de

experimentos en redes inalámbricas.

Como ya se introdujo en apartados anteriores, el simulador NS se basa en dos lenguajes. En primer

lugar consta de un simulador orientado a objetos, escrito en C++ y de un intérprete de scripts de

usuario implementado en OTcl. El empleo de dos lenguajes diferentes se justifica por las bondades de

los lenguajes compilados, como C++, y los lenguajes interpretados o de scripting, como OTcl. Los

lenguajes compilados son robustos y eficientes para el diseño de aplicaciones, mientras que programar

en lenguajes interpretados es una tarea más sencilla. En la Ilustración 43 se muestra la interrelación

entre estos dos lenguajes de programación en el entorno del simulador ns-2 desde el punto de vista de

un usuario. Con el fin de interactuar con el programa, el usuario define un script en OTcl en el que

describe todas las características del modelo que se desea reproducir: la topología de red, los

protocolos, los patrones de tráfico, así como la forma en la que el simulador debe producir la salida.

Por otro lado, las librerías de ns-2, escritas y compiladas en C++, incluyen los objetos que modelan el

planificador de eventos y los componentes básicos de red, permitiendo reducir el tiempo de

procesamiento de paquetes y eventos. El simulador ns-2 analiza el script de usuario a través de su

módulo intérprete OTcl y crea una correspondencia unívoca entre cada objeto OTcl y cada objeto de

las librerías codificadas en C++. El simulador ns-2, debido a su arquitectura modular, permite la

reutilización de código, de tal modo que cuando un usuario quiere crear un nuevo objeto de red,

puede programar el nuevo objeto o bien emplear entidades ya definidas en la biblioteca. El script de


entrada arranca un planificador de eventos, que lleva la cuenta del tiempo de simulación y dispara los

diferentes eventos programados para cada instante de tiempo invocando los componentes de red

pertinentes. Cada evento produce una determinada información que el usuario recoge como salida del

programa en forma de fichero de trazas (trace file). Si el usuario desea modificar los escenarios, no ha

de hacer más que reprogramar el script OTcl. . En cuanto a la visualización de las simulaciones existe la

posibilidad de definir un archivo de trazas para ser usado por la herramienta de visualización Nam, la

cual será descrita en el siguiente apartado.

Ilustración 43 Perspectiva de ns-2 desde el punto de vista de usuario

Los componentes que se necesitan describir en ns-2 son:

La apariencia de la red. Esto conlleva la posición de todos los nodos, descrita bajo coordenadas

(x, y,z). El movimiento de los nodos, así como el tiempo en el que se producen estos

movimientos. Velocidad de movimiento y dirección.

Tráfico de los nodos. Definición de los nodos que actúan como fuentes y como destinos.

Definición de las conexiones.

Otros parámetros relacionados con el desarrollo de la simulación, como por ejemplo el tiempo

de simulación, o definición del archivo de trazas.

Ns-2 requiere una curva de aprendizaje debido a los numerosos factores que intervienen

conjuntamente, pero una vez que se adquiere cierta destreza en el uso del simulador, los

resultados pueden ser muy satisfactorios.

Existen numerosos manuales y tutoriales de ns-2 disponibles en la red. En este trabajo se

quiere destacar [3], el cual proporciona una descripción detallada de las principales

características de ns-2, así como una gran cantidad de ejemplos de aplicación, los cuales

permiten adquirir práctica en el uso del simulador y al mismo tiempo obtener resultados.

Además este manual proporciona ciertas nociones básicas y ejemplos para el uso de lenguajes

de procesamiento de texto. Estos lenguajes son muy útiles cuando se quiere procesa el archivo

de trazas generado por ns-2.

Visualización de las simulaciones Nam

Una vez se ha definido el script donde se define el escenario de simulación, se puede correr una


simulación gráfica usando el simulador gráfico Nam que incorpora ns-2. Con esta herramienta se

puede observar la transmisión de los paquetes y todos los eventos relacionados con estas

transmisiones, como puede ser la perdida de paquetes, etc. Además ns-2 permite aplicaciones

móviles. Estos movimientos se pueden visualizar utilizando Nam.

La herramienta Nam utiliza un archivo de traza específico el cual es generado por ns-2. Este archivo de

trazas es definido en el script.

La herramienta de visualización permite parar y continuar la simulación cuando se deseé. Además

todos los eventos de transmisión y recepción de paquetes son visualizados mediante líneas que entran

y salen de los nodos. Sin ser una herramienta gráfica muy potente, ésta nos permite obtener una idea

de los eventos ocurridos durante el tiempo de simulación.

Modelo energético

NS-2 contiene un modelo energético que puede ser activado. Este modelo energético es activado en el

script Otcl, donde se modelan todos los componentes de la red.

Cuando el modelo energético es activado, todos los nodos tienen prefijados un nivel de energía, el cual

se va consumiendo conforme los nodos realizan diversas tareas en la red, como son el envío o la

recepción de paquetes. El consumo de los nodos en estas tareas puede ser configurado por el usuario.

Una vez que el nivel energético de un nodo llega al mínimo, este nodo se vuelve inservible en la red.

Cuando el modelo energético está activado y se utiliza la herramienta de visualización Nam, se puede

observar como los nodos cambian de color conforme la energía de éstos se va agotando. Además toda

la información relativa al consumo energético en cada evento se refleja en el archivo de trazas

generado por ns-2.

En el archivo de trazas se puede observar el consumo asociado a cada evento.


Metodología de trabajo 4.

Con este trabajo se ha querido comprobar el funcionamiento de una red VANET para ello se ha hecho

uso de la herramienta NS-2 la cual proporciona la posibilidad de generar nodos móviles pero estos

nodos no tienen un comportamiento vehicular, ni tampoco las limitaciones de una ciudad (carreteras

delimitadas, semáforos, etc) como para que las simulaciones gocen del mayor realismo posible. Para

resolver esta situación en el presente trabajo se han usado dos generadores de modelos de movilidad,

Bonnmotion y por otro lado se ha hecho uso de C4R.

Con lo anteriormente mencionado cabe destacar la forma de trabajar que se ha seguido hasta la

obtención de los resultados finales.

1. Implementar el protocolo de comunicación elegido para establecer la comunicación entre los

vehículos, en este caso 802.11p.

2. Fijar parámetros como el modelo de propagación, tiempo de simulación, número de nodos,

modelo de tráfico, …

3. Establecer el modelo de movilidad. Haciendo uso de la herramienta Bonnmotion en el caso de

estar simulando el comportamiento de una ciudad con un patrón como Manhattan o C4R para

otro tipo de ciudades

Para modelar los puntos anteriores se hace uso de un script en Otcl el cual será empleado por la

herramienta de simulación (NS-2) para simular el escenario en cuestión. NS-2 devuelve como

resultado de la simulación un fichero de texto, fichero de traza, a partir del cual se pueden extraer los

correspondientes resultados en cuanto a las métricas se refiere y de ese modo poder elaborar las

gráficas oportunas.

Para cada número de nodos o cada número de conexiones, según proceda, se realiza la simulación

para 50 semillas distintas de modo que el resultado final por cada número de nodo o de conexión es la

media de los resultados obtenidos de ir variando las semillas.

El procesamiento de los datos (fichero de traza) se ha llevado a cabo con un lenguaje de scripting,

Ilustración 44 Esquema flujo de trabajo


Python. El resultado obtenido tras el procesamiento de los datos ha sido de nuevo un fichero de texto

en el cual se muestran los resultados de las métricas y que por último han sido exportados a Excell y de

ese modo generar las gráficas.

En la imagen superior, de manera muy sencilla, se ha querido reflejar el flujo de trabajo seguido hasta

llegar al resultado final (gráficas).

A modo de resumen, el usuario modela la red y selecciona el modelo de movilidad correspondiente

estos datos son usados por NS-2 que vuelca como resultado un fichero de traza del que se obtienen,

usando Python, las métricas correspondientes para finalmente ser representadas con Excell.


6. EVALUACIÓN DE RESULTADOS

Para evaluar el comportamiento de los protocolos anteriormente descritos se han evaluado en

distintos escenarios.

Pero antes de comentar los resultados obtenidos es necesario describir conceptualmente todos las

magnitudes que se van a medir, métricas.

Métricas 1.

A continuación se describen las métricas utilizadas para comparar los distintos protocolos de

enrutamiento. Estas métricas son consideradas en numerosos artículos que abordan esta temática.

Throughput [kb/s]: Número total de paquetes recibidos divido por el tiempo de simulación.

Average End-to-End delay [s]: Tiempo de retardo de nodo a nodo. Esta métrica tiene en

cuenta todos los posibles retardos causados por buffering, tiempo de retardo en cola,

retransmisión de paquete en la capa MAC, y tiempos de propagación y transmisión de los

paquetes.

Packet Delivery Fraction (PDF) [%]: Representa la tasa de paquetes enviados por la capa de

aplicación dividido entre el número de paquetes recibidos por los destinos correctamente. Con

esta métrica se obtiene una idea de la tasa de paquetes que se pierden.

Normalised Routing Load (NRL) [%]: Representa la tasa de paquetes enviados por la capa de

enrutamiento divido por el número de paquetes recibidos correctamente por la capa de

aplicación. En protocolos donde el número de paquetes utilizados por la capa de enrutamiento

es muy elevado, el rendimiento de la red se ve penalizado.

Dropped packetes: Número total de paquetes perdidos.

Evaluación de métricas para Manhattangrid 2.

1. Análisis de densidad (Variando el número de nodos)

El estudio que se propone en éste apartado tiene como base un estudio [1] realizado acerca del

comportamiento de los protocolos DSR, DSDV y AODV para VANET en escenarios reales. En este

estudio se miden varios parámetros bajo determinadas condiciones.Además de evaluar los protocolos

citados en el documento de referencia se han añadido varios protocolos más a estudiar.


Parámetros de simulación

Se ha simulado, usando Bonnmotion, un escenario con las siguientes características:

Área: 2000 x 2000 m

Modelo de ciudad: ManhattanGrid, entramado de 10 x 10 calles

Velocidad nodos: 0 – 50 Km/h

Nº nodos: de 25 a 200 nodos.

Nº de conexiones: 5

Modelo de propagación: TwoRayGround.

El modelo de tráfico seleccionado ha sido:

Tráfico utilizado: “Constant Bit Rate” (CBR)

El agente de aplicación es “User Datagram Protocol” (UDP).

El tamaño de los paquetes es 512 bits.

Resultados de la simulación

En esta sección se van a presentar los resultados agrupados por métricas, es decir en cada gráfica se

van a mostrar todos las métricas y en cada una de ella se van a comparar los protocolos bajo estudio.

1. Packet Delivery Fraction (PDF)

Se puede apreciar una diferencia sustancialmente importante entre ZRP y el resto de protocolos en

cuanto al packet delivery fraction esto se debe a que ZRP tarda más tiempo en localizar su destino y en

muchas ocasiones no lo alcanza y por tanto los paquetes enviados por el nivel de aplicaión no

alcanzan su destino, ni siquiera llegan a ser enviados, y esa situación se ve reflejada en la gráfica

anterior.

Dejando a un lado al protocolo híbrido (ZRP), en la siguiente Ilustración 46, se puede apreciar una

Ilustración 45 PDF-Manhattan

0

20

40

60

80

100

120

25 50 75 100 125 150 175 200

PD

F (%

)

Nº de nodos

AODV

DSR

DSDV

OLSR

AOMDV

DYMO

ZRP


diferencia importante entre los protocolos reactivos y proactivos. Dentro de los protocolos reactivos

se puede apreciar como existe una diferencia considerable entre DSR y AODV a medida que el número

de nodos crece, esto se debe principalmente a que cuando se invalida una ruta se envia un mensaje

RERR que reduce la tasa de envío hasta descubrir una nueva ruta, en consecuencia disminuye el PDF a

medida que aumenta el número de nodos. Sin embargo, una vez lograda la comunicación AODV es

más estable. Coincidiendo con otros autores y ante los datos obtenidos, el comportamiento de AODV

es mejor que el de DYMO. No obstante con DYMO como protocolo de encaminamiento a medida que

aumenta el número de nodos mejora su comportamiento en cuanto a la tasa de entrega de paquetes

se refiere. Sin embargo para 200 nodos la tasa de entrega se reduce sustancialmente pudiéndose

deber esta situación a que aumenta el número de colisiones.

Comparando entre sí los protocolos proactivos (OLSR y DSDV) se puede apreciar que OLSR presenta un

mejor comportamiento debido a que trata de eliminar las rutas obsoletas haciendo uso de los

mensajes Hello y TC por lo tanto en condiciones donde el número de rutas es alto OLSR entrega más

paquetes y por tanto hace un uso eficiente del ancho de banda y en consecuencia el PDF es mayor

que para DSDV.

Se puede apreciar que para un bajo número de nodos el comportamiento entre AODV, protocolo

Unicast, y AOMDV, protocolo Multicast, es similar. Sin embargo al aumentar el número de nodos

cambia, y el comportamiento de AOMDV se hace sustancialmente mejor que el de AODV. Esto se

debe a que AOMDV mantiene múltiples rutas libres de bucles mientras que AODV mantiene solo las

rutas más recientes y no múltiples rutas.

Pero si en lugar de comparar con AODV se hiciera con DSR, otro protocolo Unicast, el

comportamiento de este último es en todo momento mejor pero para un número de nodos altos se

llegan a parecer bastantes.

Ilustración 46 PDF-Manhattan sin ZRP

60

65

70

75

80

85

90

95

100

105

25 50 75 100 125 150 175 200

PD

F (%

)

Nº de nodos

AODV

DSR

DSDV

OLSR

AOMDV

DYMO


2. PAQUETES PERDIDOS

En la gráfica superior puede observarse que para un número de nodos bajo el protocolo que mejor

comportamiento presenta en cuanto al número de paquetes perdidos es OLSR (proactivo). Si es

comparado con un protocolo de su misma categoría, caso de DSDV, existe una diferencia

importante debido a que OLSR elimina de sus tablas de enrutamiento todos aquellas rutas

obsoletas de modo que la mayoría de paquetes perdidos en OLSR se deben a vencimiento de

temporizadores.

Para el caso de protocolos proactivos, por ejemplo AODV y DSR, y bajo la condición de un número

de nodos bajos el protocolo AODV presenta un mejor comportamiento que DSR. Sin embargo

cuando aumenta el número de nodos el comportamiento de DSR mejora con respecto a AODV. El

comportamiento de Dymo se asemeja bastante a los dos anteriores principalmente por el hecho

de que éste es una evolución de AODV y DSR para redes con alta movilidad, además se puede

apreciar que al aumentar el número de nodos se reduce el número de paquetes perdidos.

Para el caso de ZRP (proactivo) el número de paquetes perdidos es elevado y constante. No

obstante se observan algunos puntos, correspondientes a 75 y 150 nodos, en los que los

resultados mejoran sutilmente esto se debe a la disposición de los nodos. ZRP es un protocolo de

enrutamiento de zona, si los nodos con los que desea comunicarse el nodo emisor se encuentran

dentro de la zona las rutas están inmediatamente disponible y en consecuencia el número de

paquetes perdidos se reduce.

ZRP mantiene unas tasas de perdidas de paquetes elevadas pero de forma constante a la hora de

aumentar el número de nodos. Cabe destacar el caso de AOMDV en el que número de paquetes

perdidos es directamente proporcional al número de nodos esto se debe en esencia a que la

estratégia de este protocolo es mantener múltiples caminos entre origen y destino, si aumenta el

número de nodos aumenta el número de posibles caminos y es la consecuencia directa que se

observa en la gráfica superior.

Ilustración 47 Paquetes Perdidos-Manhattan

0

100

200

300

400

500

600

700

800

900

25 50 75 100 125 150 175 200

Nº

Paq

ue

tes

Pe

rdid

os

Nº de nodos

AODV

DSR

DSDV

OLSR

AOMDV

ZRP

DYMO


3. AVERAGE END TO END DELAY

Analizando la gráfica superior y evaluando solamente los protocolos reactivos (AODV, DSR y AOMDV)

se puede comprobar que DSR es el que presenta unos valores muy bajos, no obstante AODV para un

número de nodos bajos (25 y 50) los comportamientos son similares. Este cambio de comportamiento

se debe a que DSR permite tener varios rutas activas consiguiendo el balanceo de carga. Sin embargo

AOMDV presenta un comportamiento intermedio entre ZRP y AODV.

Evaluando el comportamiento de los protocolos proactivos (DSDV y OLSR) se puede observar que

mantienen unos valores constantes de retrasos dado que al tratarse de protocolos proactivos toda la

información de enrutamiento se encuentra almacenada en las tablas de encaminamiento.

Por su parte ZRP presenta unos valores más altos de retrasos debido a la forma de operar que tiene

este protocolo, concepto de zonas, si no encuentra el destinatario dentro de su zona necesita buscar

en otra zona así sucesivamente esta funcionalidad propicia mayors retrasos, además se puede apreciar

que al aumentar el número de nodos también va creciendo estos retrasos.

Si se observa el comportamiento de AOMDV y AODV se puede apreciar que los tiempos de éste último

es peor a medida que aumenta el número de nodos, sin embargo para AOMDV se mantiene constante

e incluso se reduce cuando se alcanza los 200 nodos, esto se debe a que se trata de un protocolo

multicast y presenta varios caminos libres de bucles para llegar al destino reduciendo de ese modo los

tiempos de entregas.

De entre los protocolos, reactivos y proactivos, el que presenta un peor comportamiento a medida

que aumenta el número de nodos es Dymo esto se debe a que debe procedar mayor volumen de

información, la referente a las rutas hasta llegar al destino mas la información referente a los nodos

intermedios.

Ilustración 48 Average End to End Delay - Manhattan

0

10

20

30

40

50

60

70

25 50 75 100 125 150 175 200

Ave

rage

En

d t

o E

nd

De

lay

(s)

Nº de nodos

AODV

DSR

DSDV

OLSR

AOMDV

ZRP

DYMO


4. NORMALISED ROUTING LOAD (NRL)

Esta métrica va a ser expuesta de una forma especial por el hecho de que ZRP necesita de una mayor

cantidad de paquetes de enrutamiento para alcanzar su destino y por ello el NRL se hace muy grande y

no permite apreciar las diferencias entre los otro protocolos (reactivos y proactivos).

El hecho de que ZRP presente unos valores tan altos es por el motivo que antes se ha mencionado,

radio de la zona.

En la gráfica superior se ha eliminado ZRP.

Ilustración 49 NRL- Manhattan

Ilustración 50 NRL - Manhattan sin ZRP

0

20000

40000

60000

80000

100000

120000

140000

160000

180000

200000

25 50 75 100 125 150 175 200

NR

L (%

)

Nº de nodos

AODV

DSR

DSDV

OLSR

AOMDV

DYMO

ZRP

0

2000

4000

6000

8000

10000

12000

25 50 75 100 125 150 175 200

NR

L (%

)

Nº de nodos

AODV

DSR

DSDV

OLSR

AOMDV

DYMO


Comparando entre los protocolos reactivos, se puede observar que DSR es el mejor de ello mientras

que AOMDV es uno de los que muestra el peor comportamiento, esto se debe a que en el caso de DSR

cuando un paquete sale del nodo emisor con destino a otro nodo el paquete enviado lleva como

parte de él una cabecera en la que incluye los nodos por los que debe pasar hasta llegar a su destino,

en el caso de AOMDV para establecer la comunicación entre el origen y destino se crean múltiples

caminos entre los nodos intermedios hasta llegar al destino, la consecuencia inmediata de esta

situación es que se envían multitud de RREQ y de RREP en respuesta con esta estratégia AOMDV busca

reducir los posibles bucles. Como muestra la gráfica anterior al aumentar el número de nodos

aumenta también el número de paquetes de encaminamiento y en consecuencia lo hace el NRL. El

que presenta el peor comportamiento es DYMO puesto que los nodos además de la información

acerca de una ruta destino también recibe la información acerca de todos los nodos intermedios lo

que hace que el número de paquetes de Encaminamiento aumente a medida que aumenta el número

de nodos.

5. TROUGHPUT

Se puede apreciar que el protocolo que mejor comportamiento presenta es DSR mientras que si se

observa AOMDV para un número de nodos bajos es el que peor comportamiento, entre los protocolos

reactivos presenta pero al aumentar el número de nodos (200) se aprecia como su comportamiento se

empiza a aproximar a DSR y esto es debido a que AOMDV trata de encontrar el mayor número de

caminos para evitar los bucles. Sin embargo AODV inicialmente presenta un comportamiento

semejante al de DSR pero cuando el número de nodos crece su comportamiento comienza a

empeorar debido a que cuando una ruta se queda invalidada se reduce tasa de envio y al aumentar el

número de nodos también aumenta el número de rutas inválidas.

Para el caso de los protocolos reactivos el Troughput se mantiene en unos valores constantes a pesar

de aumentar el número de nodos. El que presenta el peor comportamiento es DYMO, pero a medida

que aumenta el número de nodos mejora dicha métrica.

Ilustración 51 Troughput- Manhattan

0

0,5

1

1,5

2

2,5

3

3,5

4

4,5

5

25 50 75 100 125 150 175 200

Tro

ugh

pu

t (K

bp

s)

Nº de nodos

AODV

DSR

DSDV

OLSR

AOMDV

ZRP

DYMO


ZRP en media mantiene unos valores relativamente próximos a pesar de que se pierden un elevado

número de paquetes con este protocolo.

Las métricas PDF y Troughput tienen unos valores proporcionales puesto que se basan en el número

de paquetes entregados en el destino.

Análisis de los resultados

A modo de resumen en esta sección se presentan los resultados, en forma de tablas, destacando

aquellos cuyos valores son los mejores, esta distinción va a servir de ayuda a la hora de seleccionar el

protocolo idóneo.

Métrica Nodos AODV DSR DSDV OLSR AOMDV ZRP DYMO

PD

F

25 97,88 99,12 77,67 88,60 91,16 32,50 91,96

50 97,74 97,81 76,89 88,74 90,3 36,76 74,83

75 89,53 98,05 80,57 93,56 90,74 42,69 75,30

100 89,03 98,50 76,35 87,26 89,06 25,55 81,40

125 84,60 97,94 78,28 88,26 28,75 82,24

150 87,31 99,90 93,86 95,64 49,00 83,00

175 78,78 96,50 77,18 89,06 17,21 84,70

200 79,19 98,13 77,21 93,22 32,27 69,07

Tabla 8 Comparativa PDF – Manhattan


TRO

UG

HP

UT

25 4,45 4,52 3,53 4,028 4,16 1,49 3,81

50 4,45 4,46 3,5 4,032 4,11 1,69 3,09

75 4,08 4,47 3,66 4,2622 4,15 1,95 3,15

100 4,06 4,49 3,47 3,98 4,04 1,17 3,39

125 3,86 4,46 3,57 4,02 1,32 3,47

150 3,98 4,56 4,28 4,37 2,26 3,51

175 3,59 3,98 3,51 4,06 0,79 3,50

200 3,62 4,49 3,41 4,25 1,48 2,90

Tabla 9 Comparativa Troughput – Manhattan


NR

L

25 107,0 29,7 92,7 516,6 629,3 3120,2 177,6

50 264,1 54,3 190,9 1133,6 1241,5 8844,4 1303,0

75 607,0 128,2 304,6 1650,3 1870,7 14753,7 1507,0

100 684,1 122,3 430,7 1932,2 2539,0 43054,4 2515,8

125 1500,4 222,0 539,0 3283,4 59088,3 2498,4

150 874,7 63,0 547,9 3355,2 45705,9 4608,6

175 2413,0 249,2 799,1 4525,2 182263,8 3016,5

200 2402,4 316,9 863,5 4666,2 112519,0 8669,5

Tabla 10 Comparativa NRL – Manhattan



DR

OP

P

25 51 58 260 83 146 465 42

50 103 154 298 82 229 436 139

75 146 231 219 47 247 393 145

100 254 226 260 85 381 510 154

125 217 356 247 469 491 107

150 171 137 81 300 353 142

175 283 221 232 727 569 92

200 439 312 225 485 466 186

Tabla 11 Comparativa Dropp packet – Manhattan


AV

ERA

GE

END

TO

EN

D

DEL

AY

25 1,54 0,54 15,8 7,77 5,98 34,44 2,76

50 1,37 0,46 12,98 5,43 5,31 26,53 12,66

75 10,21 1,06 16,42 4,44 6,49 43,91 13,01

100 11,14 0,76 19,91 8,01 7,79 42,14 7,97

125 13,43 0,93 16,95 7,73 40,62 8,00

150 13,95 0,05 4,37 3,22 34,08 7,56

175 20,97 1,1 19,9 7,45 61,95 6,47

200 19,32 0,89 18,68 3,85 45,94 12,88

Tabla 12 Comparativa Average end to end delay – Manhattan

En las tablas superiores se puede apreciar como el protocolo que presenta el mejor comportamiento

en todas las métricas es DSR. No cabe lugar a dudas que si fuera necesario implementar en la realidad

una red sobre un escenario con las características anteriormente citadas y para los nodos estudiados

se emplearía como protocolo de enrutamiento DSR. Los factores determinantes son: tasa de entrega

de paquetes, nivel de congestión de la red y tiempos medios de entrega de paquetes.

La siguiente tabla recoge de forma visual lo antes mencionado.

Métrica Nº conex

Tasa de Entrega

Nivel de Enrutamiento Delay

Bajo DSR DSR DSR

Alto DSR DSR DSR

Tabla 13 Elección de protocolos por métricas – Análisis de densidad

Además de realizar la elección de forma cualitativa resulta de interés definir una nueva métrica

(Eficiencia) para comprobar de forma cuantitativa cúal es el protocolo que presenta el mejor

comportamiento o en este caso el mejor resultado.



EFIC

IEN

CIA

5 0,5941 6,1720 0,0530 0,0221 0,0242 0,0003 0,1876

10 0,2701 3,9130 0,0310 0,0144 0,0137 0,0002 0,0045

15 0,0144 0,7218 0,0161 0,0128 0,0075 0,0001 0,0038

20 0,0117 1,0601 0,0089 0,0056 0,0045 0,0000 0,0041

25 0,0042 0,4744 0,0086 0,0035 0,0000 0,0041

30 0,0072 31,7244 0,0392 0,0089 0,0000 0,0024

35 0,0016 0,3521 0,0049 0,0026 0,0000 0,0043

40 0,0017 0,3479 0,0048 0,0052 0,0000 0,0006

Tabla 14 Comparativa Eficiencia – Manhattan

De forma cuantitativa no cabía la menor duda posible, numéricamente queda también confirmado

que DSR sería el protocolo seleccionado para un escenario como este.

Visualización del escenario

Haciendo uso de la herramienta gráfica que dispone Ns-2, NAM, se puede visualizar el

comportamiento de los nodos en el escenario en cuestión, para tener disponible esta opción solo es

necesario ejecutar la herramienta tras haber ejecutado el correspondiente Script que modela el

comportamiento de los nodos.

A continuación se muestra una captura de dicha herramienta para 25 nodos usando como modelo de

movilidad ManhattanGrid. No obstante la mejor forma de visualizar el comportamiento de los nodos y

comprobar que describen una trayectoria definida y que concuerda con una ciudad es poder visualizar

una simulación completa y no una simple captura en un instante determinado.

Ilustración 52 Simulación con herramienta NAM


2. Análisis de congestión (Variando el número de conexiones)

En el apartado anterior se presentaban los resultados correspondientes para un escenario en el que el

número de conexiones se mantenia constante e igual a 5 y el número de nodos aumentaba. Para la

sección que a continuación se expone se mantiene el escenario anterior pero el número de nodos se

fija en 100 y el número de conexiones varia entre 5 y 40 con el objetivo de comprobar el

comportamiento de los distintos protcolos bajo estudio.

Parámetros de simulacón

Se ha simulado, usando Boonmotion, un escenario con las siguientes características:

Área: 2000 x 2000 m

Modelo de ciudad: ManhattanGrid, entramado de 10 x 10 calles


Nº nodos: 100.

Nº de conexiones: 5 a 40 (de 5 en 5).







En este apartado se muestran los resultados obtenidos en las simulaciones bajo las condiciones antes citadas.


1. PACKET DELIVERY FRACTION

En lo que respecta a los protocolos reactivos (AODV, DSR y AOMDV), salvo DYMO, presentan mejor

comportamiento que los proactivos (DSDV) e híbrido (ZRP) excepto para DSR que a partir de 25

conexiones empieza a empeorar debido a que este protocolo necesita colocar una cabecera con los

saltos necesarios entre el origen y destino para ello necesita de un determinado tiempo, y los

correspondientes buffer de los nodos se llenan, por tanto el número de paquetes perdidos aumenta y

en consecuencia se reciben menos paquetes en destino que se traduce en una reducción del PDF. El

protocolo reactivo DYMO presenta inicialmente un peor comportamiento que DSDV (reactivo) pero a

medida que aumenta el número de conexiones mejora su comportamiento puesto que éste está

diseñado para redes grandes en las que los nodos se comunican con una porción pequeña del resto

como es el caso de los escenarios que se están realizando en este proyecto por lo que si se hubiera

podido similar hasta las 40 conexiones se habría comprobado que mejoraría a otros protocolos.

Para ZRP puede observarse como el PDF mejora a partir de 10 conexiones y se mantiene en unos

valores próximos para el resto de conexiones.

Ilustración 53 PDF - Análisis congestión

20

30

40

50

60

70

80

90

100

110

5 10 15 20 25 30 35 40

PD

F (%

)

Nº de conexiones

AODV

DSDV

DSR

AOMDV

ZRP

DYMO



Lo que mas destaca de esta gráfica es el elvado número de paquetes perdidos por DSR, el motivo fue

expuesto en el apartado correspondiente a Packet delivery fraction, son muchos los paquetes perdidos

en los buffers de los nodos. En la gráfica, Ilustración 55, que a continuación se muestra se puede

comprobar ese detalle, número de paquetes perdidos en la cola de los buffers.

Puede verse de manera clara como casi la totalidad de los paquetes perdidos es por el motivo antes

citado. Ocurre algo similar con ZRP en el que la mayoría de los paquetes perdidos son en los buffers de

los nodos.

Para el resto de protocolos además de perder paquetes en la cola de los buffers, menor proporción

que ZRP y DSR, también se pierden debido a la expiración del tiempo de vida de los paquetes dado que

si un paquete entra en un bucle la única forma que tiene de que ese bucle finalice y de no saturar la

red en un momento determinado es que el paquete sea descartado, caso de AODV.

Si por un momento el protocolo DSR es eliminado de la gráfica, al tener unos valores tan elevados

enmascara el comportamiento del resto, y sólo se muestran los otro cinco se puede observar que

independientemente del tipo de protocolo (reactivo o proactivo) el número de paquetes perdidos

aumenta a medida que aumenta el número de conexiones.

Ilustración 54 Dropp Packet - Análisis congestión

0

5000

10000

15000

20000

25000

30000

35000

40000

45000

5 10 15 20 25 30 35 40

Nº

de

Paq

ute

s P

erd

ido

s

Nº de conexiones

AODV

DSDV

AOMDV

ZRP

DSR

DYMO


Si se comparan los protocolos multicast y unicast se puede comprobar como AOMDV pierde mas

paquetes, se trata de paquetes de enrutamiento, debido a que necesita fijar un mayor número de

rutas entre nodos.

Ilustración 55 Paquetes perdidos en Bufffer - Análisis congestión

Ilustración 56 Dropp Packet sin DSR - Análisis congestión

0

1000

2000

3000

4000

5000

6000

7000

8000

9000

5 10 15 20 25 30 35 40

Nº

de

Paq

ue

tes

Pe

rdid

os

en

Bu

ffe

r

Nº de conexiones

AODV

DSDV

DSR

AOMDV

ZRP

DYMO

0

500

1000

1500

2000

2500

3000

5 10 15 20 25 30 35 40

Nº

de

Paq

ute

s P

erd

ido

s

Nº de conexiones

AODV

DSDV

AOMDV

ZRP

DYMO



El protocolo que mejor se comporta es DSR, a pesar de ser el que mayor número de paquetes pierde,

esto se debe a que este protocolo añade los saltos necesarios para llegar del origen al destino en cada

paquete transmitido, no obstante también empeora para un número de conexiones elevadas. Sin

embargo para un número de conexiones mas elevado el comportamiento mas bueno lo proporcionan

AODV y AOMDV dado que ambos protocolos, reactivos, comprueban en sus tablas de

encaminamiento los siguientes saltos si no existe ruta hacia el nodo en cuestión se busca y se añade a

la tabla ésto solo se realiza una vez a no ser que la ruta quede fuera de servicio en cuyo caso se vuelve

a relizar la búsqueda, de modo que si aumenta el número de conexiones puede ocurrir que algunos

paquetes vayan de un nodo emisor que tenga en su tabla de encaminamiento la ruta hacia un nodo

destino en cuyo caso solo tendrá que buscar una vez y el resto de veces no tendrá que perder el

tiempo en descubrirla; es esta la causa que hace que el retraso sea menor al aumentar el número de

conexiones.

Si hubiera que resaltar un protocolo por mejorar su comportamiento a medida que aumenta el

número de conexiones ése es el caso de DYMO ya que éste está diseñado para redes con un número

elevado de conexiones.

Ilustración 57 End to End Delay - Análisis congestión

0

5

10

15

20

25

30

35

40

45

50

5 10 15 20 25 30 35 40

End

to

en

d D

ela

y (s

)

Nº de conexiones

AODV

DSDV

DSR

AOMDV

ZRP

DYMO



Al aumentar el número de conexiones, para ZRP, disminuye el número de paquetes de enrutamiento

y por tanto se reduce el NRL.

Dejando a un lado ZRP.

Se puede apreciar que el NRL disminuye a medida que aumenta el número de conexiones para todos

los protocolos de enrutamieto excepto para DSR en cuyo caso aumenta.

Ilustración 58 NRL - Análisis congestión

Ilustración 59 NRL sin ZRP - Análisis congestión

0

5000

10000

15000

20000

25000

30000

35000

40000

45000

5 10 15 20 25 30 35 40

NR

L (%

)

Nº de conexiones

AODV

DSDV

DSR

AOMDV

ZRP

DYMO

0

2000

4000

6000

8000

10000

12000

5 10 15 20 25 30 35 40

NR

L (%

)

Nº de conexiones

AODV

DSDV

DSR

AOMDV

DYMO


5. TROUGHPUT

Todos los protocolos experimentan un crecimiento lineal salvo DSR que presenta un desnivel entorno

a las 35 conexiones debido a que para ese número de conexiones el número de paquetes perdidos se

hace importante. Todos los protocolos presentan un crecimiento lineal ascendente descatacando el

caso de DYMO que si hubiera sido possible continuar realizando simulaciones su comportamiento

hubiera mejorado al del resto.

Ilustración 60 Troughput - Análisis congestión

0

5

10

15

20

25

30

35

40

5 10 15 20 25 30 35 40

Tro

ugh

pu

t (K

bp

s)

Nº de conexiones

AODV

DSDV

DSR

AOMDV

ZRP

DYMO



A modo de resumen en esta sección se presentan los resultados, en forma de tablas, destacando

aquellos cuyos valores son los mejores. Esta distinción va a servir de ayuda a la hora de seleccionar el

protocolo idoneo.

Métrica Nodos AODV DSR DSDV AOMDV ZRP DYMO

PD

F

5 89,02 98,49 85,33 89,07 26,29 75,41

10 93,45 98,88 85,13 92,85 47,87 77,15

15 96,51 98,03 85,41 93,67 44,19 79,64

20 97,25 98,5 87,35 94,18 48,57 82,41

25 96,94 97,56 85,35 93,39 44,53 87,57

30 96,78 91,77 85,12 93,07 42,54

35 97,45 75,52 85,46 93,27 42,44

40 97,55 75,01 86,48 93,65 45,12

Como se puede apreciar el comportamiento de algunos protocolos (AODV, AOMDV y ZRP) mejora al

aumentar el número de conexiones, para DSR ocurre algo distinto puesto que su comportamiento

empeora. Sin embargo DSDV presenta un comportamiento uniforme para el número de conexiones

bajo estudio.

Ante los resultados expuestos en la Tabla 15 donde se han remarcado los mejores resultados,

correspondientes a cada protocolo, para cada una de las conexiones se puede comprobar que DSR

presenta el mejor comportamiento para un número de conexiones bajas pero que al aumentarlas su

comportamiento empeora y AODV presenta un mejor comportamiento.

Si el criterio de elección solo atendiera a la tasa de paquetes entregados podríamos decir que DSR

sería el protocolo seleccionado para un número de conexiones bajas y que AODV sería para un

número de conexiones mayor pero antes de tomar esta decisión hay que evaluar el comportamiento

del resto de métricas y con los resultados de todas ellas tomar una decisión.


TRO

UG

HP

UT

5 4,06 4,49 11,55 4,04 1,20 3,47

10 8,47 8,96 7,7 8,42 4,34 10,58

15 13,12 13,33 11,6 12,72 6,00 10,14

20 17,62 18 15,83 17,02 8,79 11,70

25 21,92 22,08 19,32 21,14 10,06 16,34

30 24,8 24,93 23,08 25,24 11,54

35 30,85 23,91 27,00 29,52 13,45

40 35,28 27,13 31,25 33,87 16,31

Tabla 15 PDF Comparativa - Análisis congestión

Tabla 16 Troughput comparativa - Análisis congestión


A pesar de que DSR presenta lo valores más altos de Troughput para un número de conexiones baja se

puede observar que AODV presenta unos valores muy próximos a DSR y además presenta un mejor

comportamiento para un número de conexiones alta. Por otro lado es lo que se esperaba puesto que

el Packet delivery ratio y el Troughput son métricas directamente proporcionales.


NR

L

5 959,30 122,26 424,72 2539,29 41788,05 3614,36

10 610,52 83,31 194,40 1249,83 12108,72 4250,36

15 458,85 77,95 129,15 850,80 9248,59 3978,63

20 379,79 70,64 94,92 657,06 6548,11 3786,33

25 415,32 342,21 78,34 574,53 6051,90 3507,01

30 429,97 2002 65,38 507,63 5553,13

35 474,80 7.591 56,28 443,59 4951,52

40 359,92 6196,05 48,51 394,43 4189,83

Tabla 17 NRL comparativa - Análisis congestión

En lo referente al número de paquetes de enrutamiento a bajo número de conexiones el protocolo

que presenta mejor comportamiento es DSR sin embargo al aumentar el número de comunicaciones

se comienza a comportar mejor DSDV.


DR

OP

P

5 254 226 456 381 2738 232

10 316 319 337 475 2694 642

15 462 439 538 678 2647 509

20 528 506 634 821 2594 430

25 705 528 903 1138 2557 454

30 801 11967 1106 1456 2515

35 1078 39514 1302 1635 2502

40 1245 41312 1387 1719 2474

Para un número de conexiones pequeña con el protocolo que menos paquetes se pierde es con DSR

aunque también es cierto que AODV presenta también un comportamiento muy similar, sin embargo

el comportamiento de éste para un número de conexiones elevadas es bastante mejor que para DSR.

Tabla 18 DROPP comparativa - Análisis congestión



Ave

rage

En

d t

o E

nd

Del

ay

5 11,19 0,77 12,45 7,79 41,96 18,83

10 6,13 0,47 10,94 4,42 31,98 22,90

15 3,24 1,14 11,83 3,91 34,95 18,45

20 2,32 0,87 9,60 3,50 32,96 10,60

25 2,81 1,01 11,43 4,30 36,31 8,04

30 2,73 1,83 11,39 4,47 36,59

35 2,10 7,37 11,31 4,47 37,20

40 2,01 6,49 10,70 4,18 35,49

Tabla 19 Average End to End Delay - Análisis congestión

Se puede comprobar en la Tabla 19 que el tiempo medio en entregar los paquetes para un número bajo

y medio de conexiones es mejor el protocolo DSR sin embargo para un número mayor de éstas los

tiempos son mejores. Puede comprobarse en el caso de DSR una reducción de los tiempos al

aumentar el número de conexiones, sin embargo en el caso de DSDV ocurre lo opuesto cuando el

número de conexiones aumenta.

Como conclusión final y si fuera necesario elegir uno u otro habría que sopesar si lo que se persigue es

una red menos sobrecargada tomando como alternativa DSDV para un número de conexiones

elevadas y DSR para un número menor. Por el contrario si la intención es conseguir una tasa de

entrega elevada la opción es escoger AODV para un número de conexiones pequeño y DSR para un

número de conexiones alto. Si lo que se busca es unos tiempos de entrega lo más reducido posible la

solución pasaría por optar por DSR para un número de conexiones reducido mientras que para un

número de conexiones más alta la alternativa sería AODV.

Métrica Nº conex

Tasa de Entrega Nivel de Enrutamiento Delay

Bajo DSR DSDV DSR

Alto AODV DSR AODV

Tabla 20 Elección de protocolos por métricas - Análisis congestión

En la tabla anterior se puede apreciar de forma visual cual sería la elección óptima en cuanto al

protocolo elegido en función del número de conexiones y el objetivo que se persiga, optimizar la carga

de la red, el número de paquetes entregados o el retraso medio de entrega de paquetes.

Como conclusión final a esta sección, si lo que se persigue es optimizar tasa de entrega de paquetes y

retraso medio (delay) la solución pasa por usar DSR y AODV para bajo y alto número de conexiones

respectivamente mientras que si lo que se pretende es reducir el número de paquetes de

enrutamiento la solución sería optar por DSDV para bajas conexiones y DSR para altas.

Además se propone volver a usar la métrica definida en el apartado anterior, Eficiencia, para

comprobar de forma cuantitativa cual es el protocolo que presenta el mejor comportamiento o en

este caso el mejor resultado.



EFIC

IEN

CIA

5 0,0083 1,0462 0,0161 0,0045 0,0000 0,0011

10 0,0250 2,5253 0,0400 0,0168 0,0001 0,0008

15 0,0649 1,1003 0,0559 0,0282 0,0001 0,0011

20 0,1104 1,6028 0,0958 0,0410 0,0002 0,0021

25 0,0831 0,2823 0,0953 0,0378 0,0002 0,0031

30 0,0824 0,0250 0,1143 0,0410 0,0002

35 0,0978 0,0013 0,1343 0,0470 0,0002

40 0,1348 0,0019 0,1665 0,0568 0,0003

Tabla 21 Eficiencia - Análisis congestión

Los resultados que arroja esta tabla son, para un número de conexiones reducidas el protocolo que

mejor comportamiento presenta es DSR mientras que a medida que aumenta el número de

conexiones DSDV presenta un mejor comportamiento.


Evaluación de métricas para diferentes escenarios 3.

Hasta ahora el comportamiento de los distintos protocolos se ha realizado para un escenario que

modela a la ciudad de Manhattan pero se pretende hacer un estudio para distintos tipos de ciudades

atendiendo a la clasificación de las ciudades que se hace en [2] en la que se distinguen a las ciudades

atendiendo a la distribución de las calles. En este articulo las ciudades se clasifican en ciudad simple,

regular y compleja.

A partir de la clasificación anterior se pretende mostrar en esta sección el comportamiento de todos

los protocolos bajo estudio en el presente documento y determinar cual de ellos presenta mejores

comportamientos.

Parámetros de simulación

Se ha simulado, usando Citymob for Roadmaps (C4R), un escenario con las siguientes

características:

Área: 2000 x 2000 m

Modelo de movilidad: IDM - Conductor normal

Modelo de ciudad:

o Ciudad compleja: Tokio

o Ciudad regular: Madrid

o Ciudad simple: Nueva York


Nº nodos: 400 nodos.

Nº de conexiones: 5






Elevar el número de nodos a simular se debe a que para un número pequeño de éstos no se aprecian

las características de uno y otro protocolo y de este modo poder compararlos entre sí. Como

consecuencia de esta determinación se elevan sustancialmente los tiempos de simulación incluso para

el caso de OLSR y DYMO se convierte en inviable de simular haciendo uso de equipos de uso

domésticos como con el que se ha realizado el presente proyecto.



Los resultados se expresarán atendiendo a la clasificación por ciudades y métricas, y por protocolo y

métrica.

1. Resultados por tipo de ciudad

Ciudad Regular

Para modelar el comportamiento de un tipo de ciudad como esta, se ha elegido un fragmento de la

ciudad de Madrid.



Ilustración 61 PDF - Ciudad Regular – Todos los protocolos

Ilustración 62 Paquetes perdidos - Ciudad Regular – Todos los protocolos

91,6

22,71

94,7 98,54

49,27 56,04

0

20

40

60

80

100

120

PD

F (%

)

Ciudad Regular - Todos los protocolos

AODV DSR DSDV AOMDV ZRP DYMO

1289

1312750

294 411 187230

1500 0

500000

1000000

1500000

2000000

2500000

3000000

Nº

Paq

ue

tes

pe

rdid

os

Ciudad regular - Todos los protocolos





Ilustración 63 Average End to End Delay - Ciudad Regular – Todos los protocolos

Ilustración 64 NRL - Ciudad Regular – Todos los protocolos

7,69 1,79 4,6 1,19

38,69

13,22

0

10

20

30

40

50A

vera

ge e

nd

to

en

d d

ela

y (s

)



1368,22

861452,84

339,81 1174,47

423698,06

29856,25 0

200000

400000

600000

800000

1000000

1200000

1400000

1600000

NR

L (%

)




5. TROUGHPUT

Ilustración 65 Troughput - Ciudad Regular – Todos los protocolos

33,19

1,24

31,8 35,69

17,85 17,24

0

5

10

15

20

25

30

35

40Tr

ou

ghp

ut

(Kb

ps)

Ciudad Regular - Todos los protocolos



Ciudad Compleja


ciudad de Tokio.



Ilustración 66 PDF - Ciudad Compleja – Todos los protocolos

Ilustración 67 Paquetes Perdidos - Ciudad Compleja – Todos los protocolos

92,49

7,4

74,55

96,12

69,21

38,69

0

20

40

60

80

100

120

PD

F (%

)

Ciudad Compleja - Todos los protocolos


2398

835803

2261 2547 182927 2250 0

200000

400000

600000

800000

1000000

1200000

Nº

Paq

ue

tes

pe

rdid

os

Ciudad compleja - Todos los protocolos





Ilustración 68 Average End to End Delay - Ciudad Compleja – Todos los protocolos

Ilustración 69 NRL - Ciudad Compleja – Todos los protocolos

6,57

3,04 3,49 2,32

20,98

18,24

0

5

10

15

20

25A

vera

ge e

nd

to

en

d d

ela

y (s

)



1584,47

354839,79

784,72 1304,83

384012,33

34726,36

0

100000

200000

300000

400000

500000

600000

NR

L (%

)




5. TROUGHPUT

Ilustración 70 Troughput - Ciudad Compleja – Todos los protocolos

33,44

8,22

25,04

34,89

25,08

38,694

0

5

10

15

20

25

30

35

40

45Tr

ou

ghp

ut

(Kb

ps)

Ciudad Compleja - Todos los protocolos



Ciudad Simple


ciudad de Nueva York.



Ilustración 71 PDF - Ciudad Simple – Todos los protocolos

Ilustración 72 Paquetes Perdidos - Ciudad Simple – Todos los protocolos

91,2 93,06 95,68 97,87

3,4

29,08

0

20

40

60

80

100

120

PD

F (%

)

Ciudad Simple - Todos los protocolos


1068 154167

233 1563

668292

2773 0

100000

200000

300000

400000

500000

600000

700000

800000

Nº

Paq

ue

tes

pe

rdid

os

Ciudad simple - Todos los protocolos





Ilustración 73 Average End to End Delay - Ciudad Simple – Todos los protocolos

Ilustración 74 NRL - Ciudad Simple – Todos los protocolos

7,79 2 3,71 1,99

32,7

18,39

0

5

10

15

20

25

30

35

40A

vera

ge e

nd

to

en

d d

ela

y (s

)



1244,99 10851,1 280,99 1265,39

657800,6

38925,33

0

100000

200000

300000

400000

500000

600000

700000

NR

L (%

)




5. TROUGHPUT

Ilustración 75 Troughput - Ciudad Simple – Todos los protocolos

32,98 33,8 32,14

35,46

0,98 7,75

0

5

10

15

20

25

30

35

40

45Tr

ou

ghp

ut

(Kb

ps)

Ciudad Simple - Todos los protocolos




A modo de resumen, en esta sección se presentan los resultados, en forma de tablas, de todos los

protocolos para los distintos escenarios marcando aquellos que presentan mejor resultado para cada

una de las métricas. La finalidad es encontrar el protocolo que mejor se ajusta a cada escenario dado

que no habrá uno que alcance los mejores resultados en todas las métricas.

Además de realizar la elección de forma cualitativa ha resultado de interés, al igual que las

evaluaciones realizadas en apartados anteriores, definir una nueva métrica (Eficiencia) para

comprobar de forma cuantitativa cual es el protocolo que presenta el mejor comportamiento o en

este caso el mejor resultado.

Esta nueva medida tiene como objetivo obtener un resultado numérico que demuestre cual es el

protocolo que presenta el mejor comportamiento.

1. Ciudad Compleja


PDF 92,49 7,4 74,55 96,12 69,21 38,694

DROPP 2398 835803 2261 2547 182927 2250

DELAY 6,57 3,04 3,49 2,32 20,98 18,24

NRL 1584,47 354839,79 784,72 1304,83 384012,33 34726,36

TROUGHPUT 33,44 8,22 25,04 34,89 25,08 38,694

EFICIENCIA 0,00888475 6,86E-06 0,02722121 0,03175206 8,5905E-06 6,1077E-05

Tabla 22 Análisis Ciuadad Compleja

Marcado de color rojo se destacan los mejores resultados para cada métrica correspondiente a cada

protocolo de enrutamiento. Para este tipo de ciudades si lo que se busca es que la tasa de paquetes

recibidos y que los retrasos sean mínimos lo ideal sería elegir AOMDV pero sin embargo DSDV

presenta una ventaja, se trata del número de paquete perdidos en total, puede parecer extraño que

presentando AOMDV una mejor tasa de paquetes entregados tenga una tasa de paquetes perdidos

por encima que DSDV pero tiene una explicación asociada y tiene que ver con el número de paquetes

de encaminamiento necesarios para alcanzar su destino, en AOMDV se requiere de un mayor número

y el número de paquetes (enrutamiento) perdidos es mayor mientras que en DSDV se necesitan

menos paquetes de este tipo, por tanto el número total de paquetes perdidos es menor, esta

explicación tiene una relación directa con el NRL que para el caso de DSDV es menor. En conclusión si

lo que se desea es que el número de paquetes de encaminamiento en la red sea el menor posible lo

ideal sería emplear DSDV, sin embargo si lo que se busca es una tasa de paquetes recibidos alta sería

necesario usar AOMDV.

Puestos a tomar una decisión AOMDV sería el elegido porque si bien es cierto DSDV presenta un

mejor comportamiento en cuanto al número de paquetes de enrutamiento necesita, pero puede

resultar más interesante asumir el inconveniente de tener una red más congestionada a cambio de

tener una tasa de entrega de paquetes más buena y unos tiempos de entrega más reducidos.

La elección de AOMDV se confirma si se tiene en cuenta los resultados de la nueva métrica a evaluar,

que muestra un mejor resultado que DSDV.


Como resumen, de forma ilustrativa, se presenta la siguiente tabla que recoge lo expuesto

anteriormente.

C.Compleja Tasa de Entrega


Protocolo AOMDV DSDV AOMDV

Tabla 23 Protocolo seleccionado por parámetro. Ciudad compleja

2. Ciudad Regular


PDF 91,6 22,71 94,7 98,54 49,27 56,04

DROPP 1289 1312750 294 411 187230 1500

DELAY 7,69 1,79 4,6 1,19 38,69 13,22

NRL 1368,22 861452,84 339,81 1174,47 423698,06 29856,25

TROUGHPUT 33,19 1,24 31,8 35,69 17,85 17,24

EFICIENCIA 0,00870589 1,4728E-05 0,06058373 0,07050561 3,0056E-06 0,00014201

Para este tipo de ciudades ocurre lo mismo que para una ciudad del tipo compleja, si lo que se busca

es reducir el número de paquetes de encaminamiento o por el contrario se prefiere alcanzar una tasa

de entrega mayor. Para el caso de DSDV el número de paquetes entregados mejora sustancialmente

con respecto al otro tipo de ciudad algo similar ocurre con el número de paquetes perdidos y el NRL,

sin embargo aumentan los tiempos de entrega aunque no de manera muy elevada. Si el criterio de

elección estuviese marcado por reducir el número de paquetes de enrutamiento porque se desee

tener una red lo menor congestionada posible. El hecho de elegir DSDV no implicaría alejar el

comportamiento de la red si se usase AOMDV como protocolo ya que los comportamientos de uno y

otro están muy próximos salvando las distancias en cuanto al tiempo de entrega se refiere se tendrá

una red más lenta pero con la certeza que los paquetes llegarían a su destino casi en igual medida que

si se eligiese AOMDV.

C.regular Tasa de Entrega

Nivel de Enrutamiento

Delay


Tabla 25 Protocolo seleccionado por parámetro. Ciudad regular

A lo anteriormente mencionado hay que añadir el resultado obtenido en la nueva métrica calculada

para comprobar el comportamiento de los protocolos la cual confirma que AOMDV sería la mejor

opción.

Además, se puede apreciar que con respecto a una ciudad del tipo compleja el protocolo DSR mejora

su comportamiento en algunos aspectos, mayor tasa de entrega de paquetes al destino, sin embargo

empeora en otros ya que el número de paquetes de encaminamiento aumenta en consecuencia

aumenta también el número de paquetes perdidos de este tipo y por tanto el número de paquetes

perdidos total.

Para el caso de ZRP, empeora en todos sus aspectos.

Tabla 24 Análisis Ciuadad Regular


3. Ciudad Simple


PDF 91,2 93,06 95,68 97,87 3,4 29,08

DROPP 1068 154167 233 1563 668292 2773

DELAY 7,79 2 3,71 1,99 32,7 18,39

NRL 1244,99 10851,1 280,99 1265,39 657800,6 38925,33

TROUGHPUT 32,98 33,8 32,14 35,46 0,98 7,75

EFICIENCIA 0,00940354 0,00428804 0,09178176 0,0388662 1,5807E-07 4,06255E-05

Tabla 26 Análisis Ciuadad Simple

La disyuntiva está entre los mismos protocolos que en ciudades anteriores, pero al igual que antes hay

que hacer prevalecer si una red más congestionada a cambio de recibir más paquetes o lo contrario o

si lo que interesa es que los tiempos de entrega sean lo menor posible.

Si no resulta de vital transcendencia tener una tasa de entrega los mayor posible lo conveniente sería

hacer uso de DSDV puesto con éste la red estaría muy descongestionada a cambio de tener unos

tiempos de entrega, aquí si se aprecia diferencia, un poco mayores. De hecho si se evalúa el resultado

de la nueva métrica, Eficiencia, confirma los antes citado.

Para el caso de ZRP se observa la misma tendencia, a un empeoramiento del comportamiento. Sin

embargo para DSR se observa una mejoría importante en su comportamiento postulándose como un

candidato para ser el elegido pero que sin embargo pierde muchos puntos a su favor cuando se

observa el elevado número de paquetes de enrutamiento que presenta en comparación con DSDV por

ejemplo.

Cabe destacar el comportamiento uniforme de AODV, presenta unos valores muy próximos para todas

las métricas en todos los protocolos y para los tres tipos de ciudades. Si hubiera que seleccionar un

protocolo como el más estable sería éste pero tiene dos inconvenientes que lo hace poco

seleccionable, se trata del tiempo medio que tardan los paquetes en llegar a su destino así como el

elevado número de paquetes de encaminamiento.

En la siguiente tabla se muestra, de forma gráfica, los protocolos que mejor comportamiento

presentan atendiendo a los tres factores que marcan la elección de un protocolo como el mejor.

C.simple Tasa de Entrega



Tabla 27 Protocolo seleccionado por parámetro. Ciudad simple


2. Resultados por tipo de protocolo

En este apartado se van a agrupar los resultados clasificados por tipo de protocolo comparando entre

sí a las ciudades para cada uno de ellos.

1. PDF

92,49

91,6

91,2

90,5

91

91,5

92

92,5

93

PD

F (%

)

AODV - Por tipo de ciudad

Compleja Regular Simple

7,4 22,71

93,06

0

10

20

30

40

50

60

70

80

90

100

PD

F (%

)

DSR - Por tipo de ciudad


Ilustración 76 PDF - AODV - Ciudades

Ilustración 77 PDF - DSR - Ciudades


74,55

94,7 95,68

0

20

40

60

80

100

120

PD

F (%

)

DSDV - Por tipo de ciudad


96,12

98,54

97,87

94,5

95

95,5

96

96,5

97

97,5

98

98,5

99

PD

F (%

)

AOMDV - Por tipo de ciudad


69,21

49,27

3,4 0

10

20

30

40

50

60

70

80

PD

F (%

)

ZRP - Por tipo de ciudad


Ilustración 78PDF - DSDV - Ciudades

Ilustración 79 PDF - AOMDV - Ciudades

Ilustración 80 PDF - ZRP - Ciudades



2398

1289 1068

0

500

1000

1500

2000

2500

3000

Nº

Paq

ue

tes

Pe

rdid

os



835803

1312750

154167 0

200000

400000

600000

800000

1000000

1200000

1400000

Nº

Paq

ue

tes

Pe

rdid

os



Ilustración 82 Paquetes Perdidos - AODV - Ciudades

Ilustración 83 Paquetes Perdidos - DSR - Ciudades

38,69

56,04

29,08

0,00

10,00

20,00

30,00

40,00

50,00

60,00

PD

F (%

)

DYMO - Por tipo de ciudad


Ilustración 81 PDF - DYMO - Ciudades


2261

294 233 0

500

1000

1500

2000

2500

Nº

Paq

ue

tes

Pe

rdid

os



2261

294 233 0

500

1000

1500

2000

2500

Nº

Paq

ue

tes

Pe

rdid

os



182927 187230

668292

0

100000

200000

300000

400000

500000

600000

700000

800000

Nº

Paq

ue

tes

Pe

rdid

os



Ilustración 84 Paquetes Perdidos - DSDV - Ciudades

Ilustración 85 Paquetes Perdidos - AOMDV - Ciudades

Ilustración 86 Paquetes perdidos - ZRP - Ciudaddes


2250

1500

2773

0

500

1000

1500

2000

2500

3000

Nº

Paq

ue

tes

Pe

rdid

os



Ilustración 87 Paquetes perdidos - DYMO - Ciudaddes



6,57

7,69 7,79

5,8

6

6,2

6,4

6,6

6,8

7

7,2

7,4

7,6

7,8

8

Ave

rage

En

d t

o E

nd

De

lay



3,04

1,79 2

0

0,5

1

1,5

2

2,5

3

3,5

Ave

rage

En

d t

o E

nd

De

lay



3,49

4,6

3,71

0

0,5

1

1,5

2

2,5

3

3,5

4

4,5

5

Ave

rage

En

d t

o E

nd

De

lay



Ilustración 88 Average End to End Delay - AODV - Ciudades

Ilustración 89 Average End to End Delay - DSR - Ciudades

Ilustración 90 Average End to End Delay - DSDV - Ciudades


2,32

1,19

1,99

0

0,5

1

1,5

2

2,5

Ave

rage

En

d t

o E

nd

De

lay



20,98

38,69

32,7

0

5

10

15

20

25

30

35

40

45

Ave

rage

En

d t

o E

nd

De

lay



Ilustración 91 Average End to End Delay - AOMDV - Ciudades

Ilustración 92 Average End to End Delay - ZRP - Ciudades

18,24

13,22

18,39

0

2

4

6

8

10

12

14

16

18

20

Ave

rage

En

d t

o E

nd

De

lay



Ilustración 93 Average End to End Delay - Dymo - Ciudades



1584,47

1368,22 1244,99

0

200

400

600

800

1000

1200

1400

1600

1800

NR

L (%

)



354839,79

861452,84

10851,1 0

100000

200000

300000

400000

500000

600000

700000

800000

900000

1000000

NR

L (%

)



784,72

339,81 280,99

0

100

200

300

400

500

600

700

800

900

NR

L (%

)



Ilustración 94 NRL - AODV - Ciudades

Ilustración 95 NRL - DSR - Ciudades

Ilustración 96 NRL - DSDV - Ciudades


1304,83

1174,47

1265,39

1100

1150

1200

1250

1300

1350

NR

L (%

)



384012,33 423698,06

657800,6

0

100000

200000

300000

400000

500000

600000

700000

NR

L (%

)



Ilustración 97 NRL - AOMDV - Ciudades

Ilustración 98 NRL - ZRP - Ciudades

34726,36

29856,25

38925,33

0

5000

10000

15000

20000

25000

30000

35000

40000

45000

NR

L (%

)



Ilustración 99 NRL - Dymo - Ciudades


5. TROUGHPUT

33,44

33,19

32,98

32,7

32,8

32,9

33

33,1

33,2

33,3

33,4

33,5Tr

ou

ghp

ut

(Kb

ps)



8,22

1,24

32,98

0

5

10

15

20

25

30

35

Tro

ugh

pu

t (K

bp

s)



25,04

31,8 32,14

0

5

10

15

20

25

30

35

Tro

ugh

pu

t (K

bp

s)



Ilustración 100 Troughput- AODV - Ciudades

Ilustración 101 Troughput- DSR - Ciudades

Ilustración 102 Troughput- AODV - Ciudades


34,89

35,69

35,46

34,4

34,6

34,8

35

35,2

35,4

35,6

35,8

Tro

ugh

pu

t (K

bp

s)



25,08

17,85

0,98 0

5

10

15

20

25

30

Tro

ugh

pu

t (K

bp

s)



Ilustración 103 Troughput- AOMDV - Ciudades

Ilustración 104 Troughput- AOMDV - Ciudades

38,694

17,24

7,75

0

5

10

15

20

25

30

35

40

45

Tro

ugh

pu

t (K

bp

s)



Ilustración 105 Troughput - Dymo - Ciudades


4. Comparación con otros estudios

Con esta sección se persigue realizar una comparación entre el estudio realizado en este proyecto con

respecto a otros que abordan temas similares en cuanto al estudio de los protocolos de

encaminamiento para diferentes escenarios y bajo distintos modelos de movilidad.

La forma de presentar estos datos será a través de una tabla en la cual se hará énfasis en los

protocolos, métricas, modelos de movilidad, simuladores y otros aspectos empleados para obtener los

resultados que se muestran en los correspondientes estudios que se detallan a continuación.

DOC PROTOCOLO MÉTRICAS Nº NODOS CONEX MOVILIADAD

[13] aodv, dsr,

dsdv Pdf, Troughput, Delay 10,30,50 8,25,40 Manhattan Grid - Boonmotion

[9] aodv,dsr Pdf, Delay 1218 20 Aleatorio - SUMO

[14] aodv, dsr,

dsdv Troughput, paquetes perdidos y

recibidos 70 - Avenida de Bogotá - SUMO [15] olsr Delay, Pdf, NRL 10 50 Avenida de Málaga - SUMO

[16] aodv, dsr,

dsdv NRL, Paquetes perdidos 15, 50 - - [10] dsdv, aodv Troughput, paquetes perdidos 30 - Intersección - SUMO

[2] aodv Paquetes perdidos 100,200,300 - Madrid, Los Ángeles,… - SUMO

[11] aodv, dsr,

olsr Pdf, Troughput, Delay, Paquetes

perdidos 50 5,10,15,20 RPGM - Boonmotion

Tabla 28 Documentos de referencia

En la tabla superior las columnas representan de izquierda a derecha el documento con respecto al

cual se está realizando la comparativa, los protocolos bajo estudio, las métricas evaluadas, el número

de nodos para los cuales se ha evaluado, el número de conexiones fijadas y por último el modelo de

movilidad y el simulador empleado para obtenerlo.

A modo de resumen con respecto a lo que se ha evaluado en este documento, se han realizado

evaluaciones para un número de nodos variables con un número de conexiones fijas, se ha variado el

número de conexiones y mantenido el número de nodos, se han generado modelos de movilidad con

dos herramientas distintas, Boonmotion y C4R. Para todo lo anteriormente citado se ha realizado la

evaluación de 5 métricas distintas.


7. CONCLUSIONES Y VÍAS FUTURAS

Este proyecto tiene como finalidad conseguir simulaciones lo más realistas posibles para arquitecturas

VANETS, con el objeto de analizar el rendimiento de los distintos protocolos de encaminamiento en

entornos urbanos.

En primer lugar se realizó un estudio de las distintas tecnologías inalámbricas, eligiendo como la más

idónea la versión del estándar 802.11p, el cual es conocido como Wave, y es ampliamente usado por

desarrolladores en comunicaciones vehículo a vehículo, y vehículo a infraestructura.

Como tareas complementarias se han evaluado distintas herramientas de simulación de redes ad hoc.

Siendo NS-2 la herramienta elegida, NS-2 ofrece la posibilidad de generar nodos móviles, pero carecen

de un comportamiento vehicular real, ya que no permite tener en cuenta aspectos secundarios como

limitaciones de carreteras, cruces de vías, semáforos, etc. Gracias al simulador Boonmotion y Citymob

for Roadmaps (C4R) se puede resolver esta cuestión, cubriendo todas las carencias que presenta el

anteriormente mencionado NS-2.

Se ha evaluado el funcionamiento de distintos protocolos de encaminamientos y se han ido

mostrando las bondades y carencias de unos frentes a otros bajo determinadas condiciones y

escenarios, todos ellos urbanos con entramados de calles más o menos complejos.

Con este proyecto de integración y simulación, se ha obtenido un análisis del rendimiento que

presenta cada protocolo bajo estudio atendiendo a cinco métricas diferentes: Packet delivery ratio,

Troughput, número de paquetes pedidos, average end to end delay y Normalised Routing Load. La

elección de un protocolo como el mejor ha dependido del escenario en el que se vaya a usar, del

número de nodos que estén presentes y de algunos otros factores, como el modo de propagación, que

aunque no hayan sido evaluados en el presente documento también tendrá un peso importante a la

hora de seleccionar el protocolo a usar.

Como trabajo futuro, puede resultar de interés estudiar el efecto de los modelos de propagación en

los escenarios propuestos y para los protocolos de enrutamientos estudiados ya que en este

documento todo el estudio se ha realizado atendiendo a uno solo de ellos.

También sería interesante poder comprobar el comportamiento del protocolo OLSR para un número

elevado de nodos, por encima de 75, y poder compararlo con el resto, dado que por su

funcionamiento requiere de equipos más potentes para su simulación en un tiempo admisible, al igual

que poder realizar simulaciones con más de 200 nodos(vehículos) y más de 40 conexiones para el

resto de protocolos bajo estudio lo cual resulta costoso en cuanto a tiempo se refiere haciendo uso de

un equipo doméstico como con el que se ha realizado el presente proyecto. Ocurre una situación

similar para DYMO pero en el caso del número de conexiones, a partir de 30 conexiones los tiempos

resultan muy elevados de modo que para futuros trabajos sería interesante comprobar su

funcionamiento para un número de conexiones mayor.

Además también puede resultar de interés añadir mejoras a los protocolos, estudiados en este

documento, que lo hagan más apropiado para aplicaciones de transporte inteligente. Así como poder

evaluar otros que aún se encuentran en fase de desarrollo.


8. Apéndice

En este apartado se describe el código utilizado para llevar a cabo las distintas simulaciones descritas en este estudio.

El código se puede dividir en tres grupos:

Programación en OTcl, el cual es utilizado por NS-2 para describir los escenarios, y sus

principales características como son, posiciones de los nodos, movimientos, etc.

Programación en Python, el cual es utilizado para procesar los archivos de trazas generados

por NS-2.

Modelado del escenario 1.

set val(netif) Phy/WirelessPhyExt

set val(chan) Channel/WirelessChannel

set val(prop) Propagation/TwoRayGround #Modelo de propagación

set val(mac) Mac/802_11Ext

set val(ifq) Queue/DropTail/PriQueue #Modelo de Cola

set val(ll) LL

set val(ant) Antenna/OmniAntenna #Modelo de antena

set val(ifqlen) 50 #Tamaño de la cola

set val(nn) 25 #Número de nodos

set val(rp) AODV #Protocolo de enrutamiento

(DSR,OLSR,DSDV,ZRP,AOMDV)

set val(x) 2100 #Tamaño (horizontal) del

escenario (m)

set val(y) 2100 #Tamaño (vertical) del

escenario (m)

set val(stop) 150 #Tiempo de simulación (ms)

#Agent/ZRP set radius_ 2 #Define el radio de zona

(ZRP)

########################### 802.11p parámetros ###########################

Phy/WirelessPhyExt set Pt_ 0.1

Phy/WirelessPhyExt set freq_ 5.9e+9

Phy/WirelessPhyExt set noise_floor_ 1.26e-13

Phy/WirelessPhyExt set L_ 1.0

Phy/WirelessPhy set bandwidth_ 75e6

Phy/WirelessPhyExt set PowerMonitorThresh_ 3.981071705534985e-18

Phy/WirelessPhyExt set HeaderDuration_ 0.000040

Phy/WirelessPhyExt set BasicModulationScheme_ 0

Phy/WirelessPhyExt set PreambleCaptureSwitch_ 1

Phy/WirelessPhyExt set DataCaptureSwitch_ 1

Phy/WirelessPhyExt set SINR_PreambleCapture_ 3.1623

Phy/WirelessPhyExt set SINR_DataCapture_ 10.0

Phy/WirelessPhyExt set PHY_DBG_ 0

Mac/802_11Ext set CWMin_ 15

Mac/802_11Ext set CWMax_ 1023

Mac/802_11Ext set SlotTime_ 0.000013

Mac/802_11Ext set SIFS_ 0.000032

Mac/802_11Ext set ShortRetryLimit_ 7

Mac/802_11Ext set LongRetryLimit_ 4

Mac/802_11Ext set HeaderDuration_ 0.000040

Mac/802_11Ext set SymbolDuration_ 0.000008

Mac/802_11Ext set BasicModulationScheme_ 0


Mac/802_11Ext set use_802_11a_flag_ true

Mac/802_11Ext set RTSThreshold_ 2346

Mac/802_11Ext set MAC_DBG 0

#############################################################################

if { $val(rp) == "DSR" } { #DSR requiere de una cola

distinta

set val(ifq) CMUPriQueue

} else {

set val(ifq) Queue/DropTail/PriQueue

}

set ns [new Simulator]

set tracefd [open resultado_aodv_25.tr w] #Fichero de traza generado

set namtrace [open simwrls.nam w]

$ns trace-all $tracefd

$ns namtrace-all-wireless $namtrace $val(x) $val(y)

# Topología

set topo [new Topography]

$topo load_flatgrid $val(x) $val(y)

create-god $val(nn)

# Configuración de los nodos

$ns node-config -adhocRouting $val(rp) \

-llType $val(ll) \

-macType $val(mac) \

-ifqType $val(ifq) \

-ifqLen $val(ifqlen) \

-antType $val(ant) \

-propType $val(prop) \

-phyType $val(netif) \

-channelType $val(chan) \

-topoInstance $topo \

-agentTrace ON \

-routerTrace ON \

-macTrace ON \

-movementTrace ON

#Creación de los nodos

for {set i 0} {$i < $val(nn) } { incr i } {

set node_($i) [$ns node]

}

#Modelo de movilidad

source "/home/jose/bonnmotion-2.0/bin/scenario_25.tcl"

#Modelo de tráfico

source "/home/jose/ns-allinone-2.34/ns-2.34/AODV/traffic.tcl"

# Posición inicial de los nodos en NAM

for {set i 0} {$i < $val(nn)} { incr i } {

$ns initial_node_pos $node_($i) 50

}

# Comunica a los nodos cuando empieza

for {set i 0} {$i < $val(nn) } { incr i } {

$ns at $val(stop) "$node_($i) reset";

}

# Fin de la simulación

$ns at $val(stop) "$ns nam-end-wireless $val(stop)"

$ns at $val(stop) "stop"

$ns at 150 "puts \"end simulation\" ; $ns halt"

proc stop {} {

global ns tracefd namtrace


$ns flush-trace

close $tracefd

close $namtrace

#Ejecutar la herramienta NAM

exec nam simwrls.nam &

}

$ns run

Procesado de los ficheros de traza 2.

Con este Script se calculan cada una de las métricas a partir de los ficheros de traza y además se

escriben en un fichero de texto para su posterior procesado.

#!/usr/bin/python

# -*- coding: utf-8 -*-

#f=open ("/home/dany/ns-allinone-2.34/ns-2.34/AODV/resultado_aodv_200.tr")

import subprocess

import math

from math import sqrt

import time

import os

from array import *

def funcion_simula (f): #f= Fichero de traza;

d=0

routing=0;

num_paq_rec=0;

num_paq_rec=0

num_paq_send=0

num_send=0

num_rec=0

a=0

throughput=0

dropp_tiempo_vida=0

dropp_buffer=0

t_sim=150

start_time= []

end_time=[]

aeted=0

i=0

for line in f:

linea = line.split(' ')

if linea [0]== "D":

d=d+1 #Cuenta los paquetes perdidos.

if (linea [0]== "s" or linea [0]== "f") and (linea[7]=="AODV" or

linea[7]=="DSR" or linea[7]=="OLSR" or linea[7]=="message") and linea[3]=="RTR":

routing+=1; #Cuenta los paquetes de routinog enviados.

if linea [0]== "r" and linea[7]=="cbr" and linea[3]=="AGT":

num_paq_rec+=1; #Cuenta los paquetes recibidos OK.

if linea [0]== "s" and linea[7]=="cbr" and linea[3]=="AGT":

num_send+=1 #Cuenta los paquetes enviados


if linea [5]== "TTL":

dropp_tiempo_vida+=1; #Paquetes perdidos por vencimiento del

temporizador

if linea [3]== "IFQ":

dropp_buffer+=1; #Paquetes perdidos por llenarse buffer

if (linea [0]== "s" and linea[7]=="cbr" and linea[3]=="AGT"):

start_time.insert(int(linea[6]),float(linea[1]))

if (linea [0]== "r" and linea[7]=="cbr" and linea[3]=="AGT"):

end_time.insert(int(linea[6]),float(linea[1]))

for i in range(len(end_time)):

aeted+=(float((end_time[i]-start_time[i])))/len(end_time)

throughput= float(num_paq_rec)/t_sim #Troughput

pdf=float(num_paq_rec)/(num_send) #PDF

if (num_paq_rec!=0):

routing_pack=float(routing)/(num_paq_rec); #NRL

f1=open('resultados_trazas/resultados_pdf.txt', 'a')

f1.write("PDF: " +str(pdf*100) + "\n")

f1.close()

f2=open('resultados_trazas/resultados_troughput.txt','a')

f2.write("Throughput: " + str(throughput) + "\n")

f2.close()

f3=open('resultados_trazas/resultados_recibidos.txt','a')

f3.write("Recibidos: " + str(num_paq_rec) + "\n")

f3.close()

f4=open('resultados_trazas/resultados_enviados.txt','a')

f4.write("Enviados: " + str(num_send) + "\n")

f4.close()

f5=open('resultados_trazas/resultados_nrl.txt','a')

f5.write("NRL: " + str(routing_pack*100) + "\n")

f5.close()

f6=open('resultados_trazas/resultados_cbr_perdidos.txt','a')

f6.write("CBR_perdidos: " + str(num_send-num_paq_rec) + "\n")

f6.close()

f7=open('resultados_trazas/resultados_perdidos.txt','a')

f7.write("Dropp: " + str(d) + "\n")

f7.close()

f8=open('resultados_trazas/resultados_vencer_temp.txt','a')

f8.write("Temporizador: " + str(dropp_tiempo_vida) + "\n")

f8.close()

f9=open('resultados_trazas/resultados_buffer_lleno.txt','a')

f9.write("Buffer: " + str(dropp_buffer) + "\n")

f9.close()


f10=open('resultados_trazas/resultados_delay.txt','a')

f10.write("Delay: " + str(aeted) + "\n")

f10.close()

Procesado de la métrica 3.

La finalidad de este script es evaluar los resultados de las métricas volcados en ficheros de texto a

través del script anterior.

#!/usr/bin/python

# -*- coding: utf-8 -*-

import subprocess

from math import sqrt

import time

import os

def funcion_procesa_datos(f_resultados):

outfd = open('archivo_out_a', 'w+')

errfd = open('archivo_err_a', 'w+')

n=0

dropp_media=0

pdf_media=0

troughput_media=0

AETED_media=0

paq_rec_media=0

nrl_media=0

recibidos_media=0

enviados_media=0

cbr_media=0

venc_temp_media=0

venc_buffer_media=0

delay_media=0

dropp_array=[]

pdf_array=[]

troughput_array=[]

AETED_array=[]

paq_rec_array=[]

nrl_array=[]

recibidos_array=[]

enviados_array=[]

cbr_array=[]

venc_temp_array=[]

venc_buffer_array=[]

delay_array=[]

dropp_desviacion=0

pdf_desviacion=0

troughput_desviacion=0

AETED_desviacion=0

paq_rec_desviacion=0

nrl_desviacion=0

recibidos_desviacion=0

enviados_desviacion=0

cbr_desviacion=0

venc_temp_desviacion=0

venc_buffer_desviacion=0

delay_desviacion=0


#Calcula desviación estandar

def desviacion_estandar(valores,n,prom):

suma_dif_cuadrado=0

varianza=0

for x in valores:

suma_dif_cuadrado+=(x-prom)**2

varianza=suma_dif_cuadrado/float(n-1)

return sqrt(varianza)

#Calcula intervalo de confianza del 95%

def intervalo_confianza (n,desviacion):

valor=0

z=1.96

valor=z*(desviacion/sqrt(n))

return valor

#Calcula la media, varianza e intervalo de confianza para todos los valores de

PDF obtenidos

f1=open('/home/dany/ns-allinone-2.34/ns-

2.34/AODV/resultados_trazas/resultados_pdf.txt', 'r')

for line in f1:

n=n+1


pdf_media+=float(linea[1])

pdf_array.append(float(linea[1]))

f1.close()

pdf_media=float(pdf_media)/n

pdf_desviacion=desviacion_estandar(pdf_array,n,pdf_media)

f0=open(f_resultados, 'w')

f0.write("###################PDF###############################\n")

f0.write("Media: " + str(pdf_media) + "\n")

f0.write("Desviacion: " + str(pdf_desviacion) + "\n")

f0.write("Intervalo de Confianza (95%) (" + str(pdf_media -

(intervalo_confianza(n,pdf_desviacion))) + "," + str(pdf_media +

(intervalo_confianza(n,pdf_desviacion))) + ")\n\n")

f0.close

f0=open(f_resultados, 'a')


2.34/AODV/resultados_trazas/resultados_troughput.txt', 'r')

#####################################PDF#################################


Troughput obtenidos

for line in f2:


troughput_media+=float(linea[1])

troughput_array.append(float(linea[1]))

troughput_media=troughput_media/n

troughput_desviacion=desviacion_estandar(troughput_array,n,troughput_media

)

f2.close()

f0.write("###################TROUGHPUT########################\n")

f0.write("Media: " + str(troughput_media) + "\n")

f0.write("Desviacion: " + str(troughput_desviacion) + "\n")

f0.write("Intervalo de Confianza (95%) (" + str(troughput_media -

(intervalo_confianza(n,troughput_desviacion))) + "," + str(troughput_media +


(intervalo_confianza(n,troughput_desviacion))) + ")\n\n")

#################################TROUGHPUT###############################


Paquetes recibidos obtenidos


2.34/AODV/resultados_trazas/resultados_recibidos.txt','r')

for line in f3:


recibidos_media+=float(linea[1])

recibidos_array.append(float(linea[1]))

recibidos_media=recibidos_media/n

recibidos_desviacion=desviacion_estandar(recibidos_array,n,recibidos_media

)

f3.close()

f0.write("###################RECIBIDOS########################\n")

f0.write("Media: " + str(recibidos_media) + "\n")

f0.write("Desviacion: " + str(recibidos_desviacion) + "\n")

f0.write("Intervalo de Confianza (95%) (" + str(recibidos_media -

(intervalo_confianza(n,recibidos_desviacion))) + "," + str(recibidos_media +

(intervalo_confianza(n,recibidos_desviacion))) + ")\n\n")

###########################Paquetes recibidos###############################


Paquetes enviados obtenidos


2.34/AODV/resultados_trazas/resultados_enviados.txt','r')

for line in f4:


enviados_media+=float(linea[1])

enviados_array.append(float(linea[1]))

enviados_media=enviados_media/n

enviados_desviacion=desviacion_estandar(enviados_array,n,enviados_media)

f4.close()

f0.write("###################ENVIADOS#########################\n")

f0.write("Media: " + str(enviados_media) + "\n")

f0.write("Desviacion: " + str(enviados_desviacion) + "\n")

f0.write("Intervalo de Confianza (95%) (" + str(enviados_media -

(intervalo_confianza(n,enviados_desviacion))) + "," + str(enviados_media +

(intervalo_confianza(n,enviados_desviacion))) + ")\n\n")

##############################Paquetes Enviados#############################


NRL obtenidos


2.34/AODV/resultados_trazas/resultados_nrl.txt','r')

for line in f5:


nrl_media+=float(linea[1])

nrl_array.append(float(linea[1]))

nrl_media=float(nrl_media)/n

nrl_desviacion=desviacion_estandar(nrl_array,n,nrl_media)

f5.close()

f0.write("###################NRL##############################\n")

f0.write("Media: " + str(nrl_media) + "\n")

f0.write("Desviacion: " + str(nrl_desviacion) + "\n")

f0.write("Intervalo de Confianza (95%) (" + str(nrl_media -

(intervalo_confianza(n,nrl_desviacion))) + "," + str(nrl_media +


(intervalo_confianza(n,nrl_desviacion))) + ")\n\n")

#####################################NRL#####################################


#Paquetes CBR perdidos obtenidos


2.34/AODV/resultados_trazas/resultados_cbr_perdidos.txt','r')

for line in f6:


cbr_media+=float(linea[1])

cbr_array.append(float(linea[1]))

cbr_media=float(cbr_media)/n

cbr_desviacion=desviacion_estandar(cbr_array,n,cbr_media)

f6.close()

f0.write("###################CBR PERDIDOS#######################\n")

f0.write("Media: " + str(cbr_media) + "\n")

f0.write("Desviacion: " + str(cbr_desviacion) + "\n")

f0.write("Intervalo de Confianza (95%) (" + str(cbr_media -

(intervalo_confianza(n,cbr_desviacion))) + "," + str(cbr_media +

(intervalo_confianza(n,cbr_desviacion))) + ")\n\n")

#############################Paquetes CBR perdidos#########################


Paquetes perdidos obtenidos


2.34/AODV/resultados_trazas/resultados_perdidos.txt','r')

for line in f7:


dropp_media+=int(linea[1])

dropp_array.append(int(linea[1]))

dropp_media=dropp_media/n

dropp_desviacion=desviacion_estandar(dropp_array,n,dropp_media)

f7.close()

f0.write("###################PAQUETES PERDIDOS####################\n")

f0.write("Media: " + str(dropp_media) + "\n")

f0.write("Desviacion: " + str(dropp_desviacion) + "\n")

f0.write("Intervalo de Confianza (95%) (" + str(dropp_media -

(intervalo_confianza(n,dropp_desviacion))) + "," + str(dropp_media +

(intervalo_confianza(n,dropp_desviacion))) + ")\n\n")

##############################Paquetes perdidos############################


Paquetes perdidos por vencimiento del temporizador obtenidos


2.34/AODV/resultados_trazas/resultados_vencer_temp.txt','r')

for line in f8:


venc_temp_media+=int(linea[1])

venc_temp_array.append(int(linea[1]))

venc_temp_media=venc_temp_media/n

venc_temp_desviacion=desviacion_estandar(venc_temp_array,n,venc_temp_media

)

f8.close()

f0.write("###################PAQUETES PERDIDOS POR TTL################\n")

f0.write("Media: " + str(venc_temp_media) + "\n")

f0.write("Desviacion: " + str(venc_temp_desviacion) + "\n")

f0.write("Intervalo de Confianza (95%) (" + str(venc_temp_media -

(intervalo_confianza(n,venc_temp_desviacion))) + "," + str(venc_temp_media +

(intervalo_confianza(n,venc_temp_desviacion))) + ")\n\n")

############################Paquetes perdidos TTL############################



Paquetes perdidos por llenado del buffer obtenidos


2.34/AODV/resultados_trazas/resultados_buffer_lleno.txt','r')

for line in f9:


venc_buffer_media+=int(linea[1])

venc_buffer_array.append(int(linea[1]))

venc_buffer_media=venc_buffer_media/n

venc_buffer_desviacion=desviacion_estandar(venc_buffer_array,n,venc_buffer

_media)

f9.close()

f0.write("###############PAQUETES PERDIDOS POR BUFFER################\n")

f0.write("Media: " + str(venc_buffer_media) + "\n")

f0.write("Desviacion: " + str(venc_buffer_desviacion) + "\n")

f0.write("Intervalo de Confianza (95%) (" + str(venc_buffer_media -

(intervalo_confianza(n,venc_buffer_desviacion))) + "," + str(venc_buffer_media +

(intervalo_confianza(n,venc_buffer_desviacion))) + ")\n\n")

###########################Paquetes perdidos buffer#########################


End to end delay obtenidos


2.34/AODV/resultados_trazas/resultados_delay.txt','r')

for line in f10:


delay_media+=float(linea[1])

delay_array.append(float(linea[1]))

delay_media=delay_media/n

delay_desviacion=desviacion_estandar(delay_array,n,delay_media)

f10.close()

f0.write("###############END TO END DELAY################\n")

f0.write("Media: " + str(delay_media) + "\n")

f0.write("Desviacion: " + str(delay_desviacion) + "\n")

f0.write("Intervalo de Confianza (95%) (" + str(delay_media -

(intervalo_confianza(n,delay_desviacion))) + "," + str(delay_media +

(intervalo_confianza(n,delay_desviacion))) + ")\n\n")

f0.close()

###############################End to end delay#############################

Script maestro 4.

Este script es el encargado de llamar a los ficheros anteriores, primero modela el escenario para a

continuación procesar los ficheros de traza y por ultimo obtener las métricas resultantes.

#!/usr/bin/python

# -*- coding: utf-8 -*-

import shutil

import time

import os

import sim

import procesa_datos

import subprocess


fichero_vuelca_resultados='resultados/resultados_datos_200_nodos.txt'

g= open('lista_200.txt','r')

outfd = open('archivo_out_a', 'w+')

errfd = open('archivo_err_a', 'w+')

otros= open('otro_out', 'w+')

da1 = time.time()

print time.localtime(da1)

for line in g:

if not os.path.isdir('resultados_trazas'):

os.mkdir('resultados_trazas')

subprocess.call(line,shell=True, stdout=outfd, stderr=errfd)

subprocess.call('./ns manhattan_200.tcl',shell=True,

stdout=otros,stderr=errfd)

fichero_traza=open ("/home/dany/ns-allinone-2.34/ns-

2.34/AODV/resultado_aodv_200.tr")

sim.funcion_simula(fichero_traza)




procesa_datos.funcion_procesa_datos(fichero_vuelca_resultados)

shutil.rmtree('resultados_trazas')



for line in g:
















for line in g:

















for line in g:
















for line in g:

















for line in g:
















for line in g:
















for line in g:















da2 = time.time()

print time.localtime(da2)

result=(da2-da1)/60

print ("\nEl tiempo transcurrido es: " +str (result) + "min")


9. REFERENCIAS

[1] Chandel, N. (s.f.). Comparative Analysis of AODV, DSR and DSDV Routing protocols for VANET city scenario. International Journal on Recent and Innovation Trends in Computing and Communication. (Autor, 2012)

[2] Identifying the Key Factors Affecting Warning Message Dissemination in VANET Real Urban Scenarios

[3] The Ns-2 manual http://www.isi.edu/nsnam/ns/ns-documentation.html

[4] City for Roadmaps. http://www.grc.upv.es/Software/c4r.html

[5] Reina, Diseño de Redes Móviles Ad Hoc en aplicaciones de transporte sobre entornos NS-2.

[6] Gonzalez, Python para todos

[7] Didac, Comparativa de implementación de protocolos reactivos de encaminamiento en redes Ad-hoc

[8] Maldonado, Comparación de protocolos de enrutamiento y modelos de movilidad para Redes Ad-Hoc Vehiculares usando mapas reales

[9] Simulation of Realistic Mobility Model and Implementation of 802.11p (DSRC) for Vehicular Networks (VANET)

[10] Jiménez, Estudio de la eficiencia de encaminamiento del protocolo AODV en redes ad hoc inalámbricas de gran escala

[11] Kioumourtzis, Simulation and evaluation of routing protocols for mobile ad hoc networks

[12] Doumenc, Estudio comparativo de protocolos de encaminamiento en redes Vanet

[13] Youssef Saadi, Simulation Analysis of Routing Protocols using Manhattan Grid Mobility Model in MANET

[14] Jiménez, Simulación y análisis de desempeño de protocolos unicast para Redes VANET

[15] Toutouh, Configuración Óptima del Protocolo de Encaminamiento OLSR

[16] Roman Lara, Evaluación de protocolos de enrutamiento usados en redes móviles Ad-hoc utilizando el software network simulator 2

http://www.isi.edu/nsnam/ns/ns-documentation.html

http://www.grc.upv.es/Software/c4r.html

proyecto fin de carrera - servidor de la biblioteca de ingeniería. universidad de...

Documents