FACULTAD DE INFORM ´
ATICA
E
STUDIO COMPARATIVO DE PROTOCOLOS
DE ENCAMINAMIENTO EN REDES VANET
Trabajo Fin De Carrera
AUTOR:H´
EL`
ENE DOUMENC
TUTOR:JOSE MAR´
IA PE ˜
NA
No es f´acil agradecer en pocas palabras a todas las personas que han hecho posible que se lleve a cabo este proyecto de fin de carrera. Pero todos los que no menciono se saben aludidos.
En primer lugar y en un plano personal quiero agradecer a mis padres todo los esfuerzos y sacrificios que han hecho para que pueda llegar ser la persona que soy hoy en d´ıa y para que pueda cumplir con mis ambiciones. Tambi´en agradecerles a mis hermanos, Nicolas y Dalila, la comprehensi´on y el apoyo recibido a lo largo de todos esos a˜nos.
Es necesario mencionar a mis compa˜neros de universidad que son mis ami-gos y que me han acompa˜nado todos esos a˜nos en los buenos y en los malos momentos. Doy las gracias a Benji, Rita, R´emi All`egre, R´emi Cazenave. Es-pero poder ayudaros como me hab´eis ayudado.
En un plan profesional quiero agradecer a mi tutor en Telef´onica, Iv´an Lequerica Roca. Ha hecho posible la realizaci´on de este proyecto, me ha apo-yado para que pueda integrarme en la empresa y gracias a sus consejos y directivas me ha ense˜nado mucho. No puedo olvidar tampoco a mis compa-˜
neros de trabajo que me han ayudado siempre que lo pod´ıan y que me han permitido trabajar en un ambiente agradable. Pienso en particular en Miguel que adem´as de compa˜nero es amigo.
1. OBJETIVOS Y MOTIVACI ´ON 1
1.1. Introducci´on . . . 1
1.2. Objetivos . . . 2
1.3. Requisitos de la soluci´on propuesta . . . 3
1.3.1. Requisitos de la plataforma de simulaci´on . . . 3
1.3.2. Requisitos de topolog´ıa . . . 4
1.4. Descripci´on de los cap´ıtulos . . . 4
2. ESTADO DEL ARTE 7 2.1. Redes VANETs . . . 7
2.1.1. Caracter´ısticas . . . 7
2.1.2. Desaf´ıos . . . 8
2.1.3. Tecnolog´ıas inal´ambricas usadas en redes VANETs . . 9
2.1.4. NFC . . . 12
2.2. Protocolos de encaminamiento . . . 12
2.2.1. Introducci´on . . . 12
2.2.2. Clasificaci´on . . . 13
2.2.3. Protocolos Broadcast . . . 17
2.2.4. Protocolos unicast . . . 20
2.2.5. Protocolos multicast . . . 30
2.2.6. Protocolos geocast . . . 30
2.3. Seguridad . . . 36
2.3.1. Ataques en redes VANETs . . . 36
2.3.2. Control de accesso . . . 37
2.3.3. Sistemas de detecci´on de intrusos . . . 37
2.3.4. Seguridad en el encaminamiento . . . 38
2.3.5. Cifrado y gesti´on de claves . . . 39
2.4. Servicios . . . 40
2.4.1. Sevicios para la seguridad vial . . . 41
2.4.2. Servicios para la administraci´on . . . 42
2.4.3. Servicio de utilidad y entretenimiento . . . 43
2.5. Calidad de servicio . . . 46
2.5.2. Se˜nalizaci´on para la reserva de recursos . . . 47
2.5.3. Calidad de servicio ligada al encaminamiento . . . 47
3. Especificaci´on de escenarios 49 3.1. Escenarios . . . 49
3.1.1. Escenario 1: VANET pura . . . 49
3.1.2. Escenario 2: Comunicaci´on VANETs pura a trav´es de nodos intermedios . . . 50
3.1.3. Escenario 3: Comunicaci´on entre dos veh´ıculos con red de respaldo UMTS . . . 51
3.1.4. Escenario 4: Comunicaci´on entre un veh´ıculo y la in-fraestructura vial . . . 52
3.2. Indicadores de rendimiento de red . . . 53
3.2.1. Protocolos unicast . . . 53
3.2.2. Protocolos geocast . . . 54
4. Plataforma de simulaci´on 57 4.1. Componientes Software de la plataforma de simulaci´on . . . . 57
4.1.1. Ns2 . . . 58
4.1.2. MObility model generator for VEhicular networks (MO-VE) . . . 59
4.1.3. Simulation for Urban mobility (SUMO) . . . 61
4.1.4. Tracegraph y Parse Java . . . 61
4.2. Procesos de simulaci´on . . . 61
4.3. Instalaci´on de la plataforma . . . 62
4.3.1. ns2 . . . 63
4.3.2. SUMO . . . 64
4.3.3. MOVE . . . 65
4.4. Modificaciones al c´odigo de ns2 . . . 65
4.4.1. Protocolos geocast . . . 65
4.4.2. Respaldo UMTS . . . 66
5. Resultado de las simulaciones 69 5.1. Comunicaci´on entre dos veh´ıculos . . . 69
5.1.1. Comunicaciones unicast en circuito urbano . . . 71
5.1.2. Comunicaciones unicast en autopista . . . 79
5.1.3. Conclusiones generales de la comparativa de protocolos unicast . . . 88
5.2. Comunicaci´on entre un veh´ıculo y la infraestructura vial. Di-fusi´on de mensajes. . . 89
5.2.1. Protocolos geocast en circuito urbano . . . 90
5.2.2. Protocolos geocast en autopista . . . 95
5.3. Comunicaciones VANET con respaldo UMTS . . . 98 5.3.1. Comunicaciones en circuito urbano . . . 98 5.3.2. Comunicaciones en autopista . . . 102 5.3.3. Conclusiones generales de la comparativa entre los
es-cenarios de VANET pura y los con respaldo UMTS . . 105
6. Conclusiones 107
6.1. Logros . . . 107 6.2. Futuras l´ıneas de trabajo . . . 108
A. GLOSARIO DE ACR ´ONIMOS 111
2.1. Problema del terminal escondido . . . 10
2.2. Mejoras de MPR frente a Blind-Flooding . . . 18
2.3. Mecanismo NES . . . 19
2.4. Mecanismo de CDS . . . 20
2.5. Mecanismo de descubrimiento de rutas en DSR . . . 22
2.6. Ejemplos de Expected Zone . . . 25
2.7. LAR con nodo origen fuera de la RZ . . . 26
2.8. Esquema de funcionamiento de TORA . . . 27
2.9. Esquema de LBM-box . . . 31
2.10. Esquema de LBM-step . . . 32
2.11. Funcionamiento de GEOTORA . . . 33
2.12. Esquema GEOGRID . . . 34
2.13. Zonas de forwarding GAMER . . . 35
3.1. Escenario de comunicaciones VANET puras . . . 50
3.2. Escenario de comunicaciones VANET puras con nodos inter-medios . . . 51
3.3. Escenario de comunicaciones VANET con respaldo UMTS . . 52
3.4. Escenario de comunicaciones V2I . . . 53
4.1. Esquema de m´odulos Ns2 . . . 59
4.2. Menu del MOVE . . . 60
4.3. Mapas generados por MOVE . . . 60
4.4. Proceso de simulaci´on . . . 62
4.5. Arquitectura UMTS . . . 66
5.1. Porcentaje de ´exito unicast UDP en circuito urbano . . . 72
5.2. Retardo unicast UDP en circuito urbano . . . 73
5.3. Overhead unicast UDP en circuito urbano . . . 73
5.4. Througput unicast TCP en circuito urbano . . . 76
5.5. Porcentaje de ´exito unicast TCP en circuito urbano . . . 77
5.6. Retardo unicast TCP en circuito urbano . . . 77
5.7. Overhead unicast TCP en circuito urbano . . . 78
5.9. Retardo unicast UDP en autopista . . . 82
5.10. Overhead unicast UDP en autopista . . . 83
5.11. Througput unicast en autopista . . . 86
5.12. Porcentaje de ´exito unicast TCP en autopista . . . 86
5.13. Retardo unicast TCP en autopista . . . 87
5.14. Overhead unicast TCP en autopista . . . 87
5.15. Esquema geocast en circuito urbano . . . 91
5.16. OSDR en protocolos geocast en circuito . . . 93
5.17. Overhead en protocolos geocast en circuito . . . 93
5.18. Bajada de prestaciones de LBM-Box con densidades de tr´afico bajas . . . 94
5.19. Esquema geocast en autopista . . . 95
5.20. OSDR en protocolos geocast en autopista . . . 97
5.21. Overhead en protocolos geocast en autopista . . . 97
5.22. Pdfr en circuito urbano . . . 100
5.23. Overhead en circuito urbano . . . 101
5.24. Retardo en circuito urbano . . . 101
5.25. Pdfr en autopista . . . 103
5.26. Overhead en autopista . . . 104
OBJETIVOS Y MOTIVACI ´
ON
1.1.
Introducci´
on
Las redes in´alambricas han revolucionado los intercambios de datos y defi-nido un nuevo paradigma, el del“Always On-Always Connected”. Dentro de este paradigma, las comunicaciones en entornos veh´ıculares abren un nuevo campo de investigaci´on en la comunidad cient´ıfica.
La forma m´as com´un de considerar las redes inal´ambricas es aquella en la cual los clientes m´oviles se conectan a una estaci´on base (BS) que controla las comunicaciones. Esta BS cubre una cierta ´area de cobertura en la cual todos los clientes que controla pueden comunicarse entre s´ı. El alcance a clientes de otras redes se hace a trav´es de un segmento generalmento fijo. Los clientes son capaces de desplazarse y de cambiar de BS sin corte de cobertura mediante un proceso llamado handover.
Las comunicaciones ad-hoc, y m´as precisamente las comunicaciones VA-NETs (“Vehicular Ad-Hoc Network”) plantean nuevos retos. En este tipo de redes no existe infraestructura de red sino que se compone de los propios no-dos m´oviles aut´onomos comunic´andose entre s´ı por enlaces inal´ambricos. En este entorno desaparece el control centralizado de la red que proporcionaba la BS. Los nodos deben asumir responsabilidades de encaminamiento y de mantenimiento de la red.El control de red est´a distribuido entre los mismos nodos.
se basa en las capacidades de cada nodo. Los protocolos de encaminamiento cl´asicos no sirven en ese entorno ya que no est´an preparados para variaciones de topolog´ıa, puede que no converjan.En tal entorno, el env´ıo de paquetes entre nodos se vuelve todo un reto.
1.2.
Objetivos
El WG IETF MANET [W1] ha permitido la creaci´on de varios protocolos de encaminamiento para el entorno veh´ıcular como est´andares. A pesar de esos esfuerzos a´un existe mucho trabajo por realizar.El objetivo de este tra-bajo es proporcionar una comparativa del rendimiento de los diferentes pro-tocolos de encaminamiento para las comunicaciones entre veh´ıculos, tambi´en conocidas como“vehicule-to-vehicule Communications”(V2V) o“Vehicular Ad Hoc Networks”(VANET).
Para llevar a cabo este estudio comparativo nos centraremos en primer lu-gar en definir una plataforma de simulaci´on que nos permita simular escena-rios reales de comunicaciones VANET. Una vez implementada la plataforma de simulaci´on ser´a necesario especificar escenarios de comunicaciones para las simulaciones Esos escenarios nos permitir´an obtener resultados emp´ıricos del rendimiento de los protocolos de encaminamiento en redes VANET que sean unicast o multicast.
La plataforma a definir constar´a tambi´en de un enlace de respaldo so-bre tecnolog´ıa UMTS. Gracias a un proceso de monitarizaci´on continua del estado de los enlaces de comunicaciones de la red, cada equipo decidir´a en cada momento en que enlace se debe mandar la informaci´on, bien por el en-lace VANET o bien por el enen-lace de respaldo UMTS. Si el escenario implica comunicaci´on con el exterior y que no se llega a una pasarela con acceso a Internet por la VANET, se mandar´a por el enlace de respaldo celular; en el resto de los casos se usar´an comunicaciones VANET.
Los escenarios se ver´an simulados en caso de que se disponga del enlace de respaldo UMTS por un lado y por otro lado los mismos escenarios ser´an probados en comunicaciones VANET pura. Este hecho nos permitir´a com-probar si la introducci´on de un enlace de respaldo celular mejora de forma significativa los resultados en cuanto al rendimiento de los protocolos.
En cada estudio se har´an comparativas de los diferentes protocolos con indicadores como el porcentaje de ´exito, el retardo extremo a extremo, el overhead... Esta comparativa de indicadores se mostrar´a de forma gr´afica.
1.3.
Requisitos de la soluci´
on propuesta
En este apartado se describen los requisitos m´ınimos a los cuales se deber´a ajustar la soluci´on propuesta para resolver el problema previamente plantea-do. Dada la multitud de propuesta en cuanto a programas de simulaci´on de red y la variedad de escenarios posibles se tendr´a que definir de manera con-creta los requisitos de la soluci´on contemplada. De un lado, se comentar´an los requisitos que la plataforma de simulaci´on debe cumplir para proporcionar un entorno fiable para las simulaciones. Por otro lado, se definir´an requisitos de topolog´ıa de redes para cada escenario.
1.3.1.
Requisitos de la plataforma de simulaci´
on
Para cumplir de manera satisfactoria los requisitos de este proyecto la plataforma de simulaci´on debe presentar caracter´ısticas espec´ıficas. Estos re-quisitos son:
- Los diferentes programas que componen la plataforma deben ser libres y de c´odigo abierto. Este requisito es fundamental por dos razones. Pri-mero, por razones econ´onomicas obvias;el car´acter libre del c´odigo nos libera de la necesidad de pagar licencias. Por otro lado, es necesario que sea de c´odigo abierto para temas de flexibilidad a la hora de modificar partes del c´odigo si fuese necesario para alcanzar nuestros objetivos de simulaciones.
- Es necesario tener implementado en el simulador todos los protocolos elegidos para la comparativa.
- Es necesario disponer de herramientas que nos permitan especificar de forma r´apida los escenarios que nos proponemos simular. Esas herra-mientas nos deben proporcionar la posibilidad de definir patrones de movimiento de los veh´ıculos, de variar el n´umero de nodos...etc.
- Es necesario que el simulador proporcione indicadores de rendimiento de red o en el caso de que no sea posible debe proporcionar trazas para permitir la extracci´on de los valores de tales indicadores.
- A partir de los indicadores o de las trazas obtenidas ser´a necesario disponer de una herramienta que permita representar de forma gr´afica los valores de los indicadores.
1.3.2.
Requisitos de topolog´ıa
El objetivo final de ese proyecto es obtener una comparativa de los proto-colos de encaminamineto en entornos vehiculares, por lo cual los escenarios a definir deben ser aproximaciones de la situaciones reales de este entorno. Por lo tanto se han elegido dos topolog´ıas t´ıpicas: un circuito urbano y una autopista, cada una con tres densidades de tr´afico diferentes.
Circuito urbano
Este circuito debe tener unas caracter´ısticas las m´as cercanas a un tramo de v´ıa real.
- Un ´unico sentido de circulaci´on con dos carriles.
- Velocidades absolutas de los veh´ıculos entre 50 y 80 km/h.
- Curvas cerradas (90 grados).
Autopista
Al igual que en el caso del circuito urbano se debe considerar situaciones las m´as realistas posibles. Sin embargo, considerar una autopista en su inte-gralidad nos llevar´ıa a un consumo de tiempo y de memoria considerable. Por lo tanto, consideraremos un tramo bastante significativo de las comunicacio-nes intercambiadas en ese entorno y aproximaremos el comportamiento total considerando que corresponde a la suma de los comportamientos individuales simulados. Los requisitos son los siguientes:
- 3 Kms de recorrido.
- Dos sentidos de circulaci´on pr´oximos entre s´ı, con dos carriles por senti-dos. Cada sentido separado por una mediana de 10 metros de longitud.
- Velocidades absolutas de los veh´ıculos entre 100 y 120 Km/h.
- Tramos muy uniformes, sin fuertes pendientes y con radios de curvatura muy elevados.
1.4.
Descripci´
on de los cap´ıtulos
los protocolos de encaminamiento que se han desarrollado para este tipo de redes, dado que este tema es el eje central de nuestro proyecto. Por fin, describiremos los principales servicios que se esperan desarrollar sobre las redes veh´ıculares.
En el tercer cap´ıtulo definiremos los escenarios de comunicaci´on a simular. Es decir estudiaremos que pruebas queremos llevar a cabo. En segundo lugar, definiremos indicadores para poder comparar los resultados de las pruebas consideradas.
El cap´ıtulo 4 se centra en la plataforma de simulaci´on que hemos desarro-llado para llevar a cabo este proyecto. Se describen los programas utilizados, sus instalaciones y el funcionamiento de la plataforma de simulaci´on. Lue-go, se detallan las modificaciones efectuadas al c´odigo fuente original para la perfecta adecuaci´on a nuestros objetivos.
En el cap´ıtulo 5, presentaremos los resultados a las simulaciones realizadas. A partir de los escenarios definidos en el cap´ıtulo 3, nos centraremos primero en una comparativa de los protocolos unicast, seguido de un estudio de los protocolos geocast para acabar finalmente con un estudio de un red VANEt con respaldo UMTS. Intentaremos demostrar que la introducci´on de un enlace de respaldo UMTS es una mejora significativa para la red VANET.
ESTADO DEL ARTE
En este cap´ıtulo vamos a intentar dar una visi´on general de los desaf´ıos que plantean las VANETs e expondremos algunas de sus aplicaciones. Siendo muy conscientes de la envergura de la investigaci´on actual sobre estos temas, y de las limitaciones de cantidad de informaci´on que podemos aportar, nos limitaremos a una exposition muy superficial, y quedar´ıan muchos temas por abordar en particular en cuanto a seguridad y calidad de servicio. El ´unico aspecto que trataremos de manera m´as detallada es el encaminamiento en redes VANETs por ser directamente vinculado con nuestro proyecto.
2.1.
Redes VANETs
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 in´alambricos sin la necesidad de una infraestructura de red fija. Cada nodo act´ua como router y tiene capacidades de encaminamiento para redirigir paquetes hac´ıa su destino.
2.1.1.
Caracter´ısticas
Veamos a continuaci´on el conjunto de caracter´ısticas de estas redes:
- Autonom´ıa. Cada nodo es un nodo aut´onomo con capacidad de proce-sado de la informaci´on 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´as tolerante a fallos.
ca-pacidades 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´on de movi-miento, por ejemplo siguiendo las curvas de un circuito urbano. A´un as´ı, los veh´ıculos se mueven de forma m´as r´apida que un terminal en una red m´ovil cl´asica. Debido a esa variabilidad de posici´on se pueden pro-ducir p´erdidas importantes de paquetes. Ser´an necearios mecanismos que detecten estas circunstancias y minimicen sus efectos.
- Capacidad variable de los enlaces. Esta caracter´ıstica tiene cabida en todas las comunicaciones inal´ambricas, pues es intr´ınseca al medio de transmisi´on pero sus efectos se agravan m´as en las MANETs. Esto se debe a que cada nodo act´ua como router y la informaci´on atreviesa m´ultiples enlaces in´ambricos.
- Terminales limitados. En la mayor´ıa de los casos los nodos de este tipo de redes ser´an terminales ligeros embarcados en veh´ıculos con capa-cidades limitadas de procesamiento, comunicaci´on y alimentaci´on por lo que es primordial que los algoritmos utilizados optimicen estos tres recursos.
2.1.2.
Desaf´ıos
Las caracter´ısticas de las redes VANETs y m´as generalmente de las MA-NETs abren un nuevo campo de investigaci´on para la comunidad cient´ıfica ya que no se han resueltos muchos de los problemas que plantean ese tipo de redes. Veamos a continuaci´on una serie de temas que quedan abiertos a la investigaci´on:
- Encaminamiento. Existe una movilidad constante en las redes VA-NETs, lo que supone cambios extremadamente r´apidos de la topolog´ıa de la red e implica una necesidad de reconfigurar las tablas de enca-minamiento presentes en cada nodo. En este estudio expondremos con detalles las propuestas de soluciones que se han dado para paliar ese problema.
o el cifrado de los paquetes por ejemplo. Se sigue investigando para proporcionar mecanismos de seguridad a ese tipo de redes.
- Calidad de servicio (QoS). La calidad de servicio en redes cableadas se proporciona mediante mecanismos de reserva de recursos. Sin embargo, la reserva de recursos se complica con la variabilidad de la topolog´ıa de las VANETs. Adem´as ninguna red puede prescendir de QoS ya que las aplicaciones de tiempo real como la videoconferencia o el videostrea-ming exigen un nivel alto de QoS. Actualmente existen propuestas, sin embargo muchas de ellas son te´oricas, simuladas o implementadas con pocos nodos, y ninguna de ella aporta una soluci´on definitiva.
- Consumo de potencia. Hemos destacado previamente el car´acter ligero de muchos terminales de la red, por lo cual es importante optimizar los procesos de comunicaci´on y procesamiento para garantizar un ba-jo consumo de energ´ıa. Este recurso depende mucho de la tecnolog´ıa usada.
2.1.3.
Tecnolog´ıas inal´
ambricas usadas en redes
VA-NETs
En este aparto se detallan tecnolog´ıas inal´ambricas susceptibles de dar soporte a redes VANETs.
Tencolog´ıa IEEE 802.11
M´as conocida como WiFi, se basa en el est´andar 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´atiles y PDAs la traen incorporada de serie. Tiene un alcance de unas centenares de metros y un ancho de banda de hasta 54 Mbps, dependiendo de la versi´on del est´andar. La nueva versi´on, 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´on 802.11i
802.11p
Range Communications), otro proyecto de estandarizaci´on impulsado por el ministerio de transporte de EE UU y por un n´umero importante de fabri-cantes de la industria autom´ovil, cuyo objetivo es crear una red nacional de comunicaciones vehiculares. El prop´osito del proyecto es definir un est´andar para las comunicaciones V2V y las comunicaciones con la infraestructura vial (V2I) que se puede instalar en sem´aforos o paneles de informaci´on, por ejem-plo. La fecha de publicaci´on de la primera versi´on del est´andar est´a prevista para Abril 2009.
WAVE pretende aumentar las tasas de trasferencia a corto alcance, tipica-mente entre 100 y 500m. La t´ecnica de modulaci´on se basa en IEEE802.11a, utilizando OFDM pero con tasas de transmisi´on 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´on, la norma define 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´a utilizado como canal de referencia para realizar una pri-mera detecci´on 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 con-tenidos..etc.) El canal CCH se usa para la transmisi´on en modo broadcast de mensajes de seguridad vial. Este contenido es prioritario sobre los dem´as tr´aficos y se transmite en el canal CCH con una tasa de datos de 6Mbps, co-rrespondiente a una modulaci´on QPSK con un ratio de codificaci´on de 1\2. En la capa MAC, WAVE se basa en las definiciones del IEEE802.11 usan-do una t´ecnica de acceso basada en CSMA/CA (Carrier Sense Multiple with Collision Avoidance). Sin embargo, CSMA/CA no logra solucionar el pro-blema del t´erminal escondido.
Figura 2.1: Problema del terminal escondido
trama RTS al destino para indicar que desea mandar tr´afico. La estaci´on 2 recibe el RTS e informa al resto de los nodos a su alcance que va a reservar el canal para la comunicaci´on con la estaci´on 1. De esta forma la estaci´on 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 redu-cido ya que se tratan de paquetes de peque˜no tama˜no (hasta 2347 octetos).
Este mecanismo evita colisiones pero introduce una sobrecarga de tr´afico en la red y retardo en las transmisiones. Por esas razones, WAVE no imple-menta RTS/CTS en el canal CCH por transmitir en modo broadcast. Como consecuencia, todos los nodos que utilizan el canal de control est´an sujetos al problema del terminal escondido, incrementando el riesgo de p´erdidas de paquetes y de congesti´on de canal.
Bluetooth
Tambi´en conocido como 802.15.1. Es la tecnolog´ıa m´as extendida en cuanto a comunicaciones inal´ambricas personales (wPAN). Hay varias clases depen-diendo de su alcance y consumo de potencia, alcanzando tasas de 2Mbps y rangos de hasta 100m. Opera en banda libre y sus mecanimos de seguridad son suficientemente robustos.
UWB
Ultra Wide Band es un est´andar basado en 802.15.3 que funciona emitien-do a muy baja potencia en un espectro enorme. Su alcance es muy limitaemitien-do (<10m) pero proporciona tasas de transferencia muy elevadas llegando a los 480 Mbps. Su consumo de energ´ıa es muy reducido.
ZigBee
Es la tecnolog´ıa m´as utilizada en redes de sensores ad hoc. Se basa en el est´andar 802.15.4. Presenta anchos de banda muy peque˜nos y cobertu-ra reducidas (250 Kbps hasta 75m). Es de gcobertu-ran utilidad pacobertu-ra enviar poca informaci´on en peque˜nas distancias. la gran ventaja es que su consumo es extremadamente reducido.
Cuadro 2.1: Caracter´ısticas de las tecnolog´ıas inal´ambricas consideradas
Tecnolog´ıa Cobertura Tasas Consumo
802.11b 500m 11 Mbps Alto 802.11g 500m 54 Mbps Alto WiMAX (802.16e) 50 Kms 75 Mbps Alto Bluetooth (802.15.1) 20m 2 Mbps Medio
UWB (802.15.3) <10m 480 Mbps Bajo Zigbee (802.15.4) 75m 250 Kbps Muy bajo
2.1.4.
NFC
“Near Field Communication”, NFC es una nueva tecnolog´ıa de comuni-caci´on inal´ambrica que proviene de la combinaci´on de varias tecnolog´ıas de identificaci´on e interconexi´on.
NFC provee una forma de comunicaci´on entre dispositivos electr´onicos, como pueden ser los tel´efonos m´oviles, las PDAs...etc. La comunicaci´on se realiza entre dos dispositivos de forma”peer-to-peer“.Trabaja en la banda de los 13.56 MHz, banda que no necesita compra de licencia para su uso. El alcance de NFC es extremadamente corto, se usa para comunicaciones de dispositivos que se encuentran a menos de 4 cm de distancia. Dado ese rango muy corto de cobertura, las comunicaciones son de forma inherente total-mente seguras. Las tasas de transferencia son de hasta 424 Kbps.
Seg´un el entorno de los dispositivos se negocia las velocidades de trans-ferencia y se puede reajustar ese par´ametro en cualquier momento de la comunicaci´on.
En entorno vehicular, NFC ofrece muchas posibilidades de aplicaci´on. Po-demos citar por ejemplo, el pago de peajes, el uso del dispositivos como llave integrada, control de acceso a servicios de ocio...etc. NFC goza de una gran aceptaci´on por parte de fabricantes e industrias del sector en general, por lo cual se espera una gran implementaci´on en todo tipo de dispositivos de comunicaci´on en un futuro.
2.2.
Protocolos de encaminamiento
2.2.1.
Introducci´
on
nodos, la inestabilidad de las topolog´ıas, y la ausencia de una infraestruc-tura de centralizaci´on hacen obsoletos los protocolos que se usan en redes fijas. En redes ad-hoc, los protocolos de encaminamiento deben ser capaces de funcionar de manera autom´atica 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´ıb rido.
- Tipo de algoritmo que implementan : vector de distancias, estado de enlace.
2.2.2.
Clasificaci´
on
Basada en el alcanceSe distinguen dos familias de protocolos: los protocolos unicast y los pro-tocolos multicast.
Los protocolos unicast son los que transmiten informaci´on de un ´unico destino a un ´unico receptor. En contraposici´on, los multicast env´ıan la infor-maci´on a un grupo de nodos.
El multicast consiste en mandar simult´aneamente informaci´on a m´ ulti-ples destinos, usando la estrategia m´as eficiente para el env´ıo de los mensajes sobre cada enlace de red. Antes del env´ıo de la informaci´on, deben estable-cerse una serie de par´ametros. Para poder recibirla, es necesario unirse a lo que se denomina ”grupo multicast“. Ese grupo multicast tiene asociado una direcci´on. En IPv4, por ejemplo, se reservan las direcciones de tipo D pa-ra la multidifusi´on (224.0.0.0 a 239.255.255.255). Dentro de los protocolos multicast hay casos particulares que son interesantes de destacar: el caso del protocolo broadcast,el protocolo geocast, y el anycast.
Basada en el modo de descubrimiento de rutas
Para descubrir las rutas hacia los destinos de la red, las MANETs usan dos esquemas distintos: el esquema reactivo y el esquema proactivo.
Los protocolos proactivos intentan tener en cada momento, y indepen-dientemente de las necesidades de encaminamiento, una visi´on precisa del estado de la red. Se busca mantener actualizadas las tablas de encamina-miento a trav´es del env´ıo de mensajes de forma peri´odica. Esta caracter´ıstica procura una respuesta r´apida ante solicitudes de ruta y suele ofrecer un buen comportamiento en los escenarios de movilidad alta. Sin embargo, para man-tener una actualizaci´on permanente de las rutas, se introduce una sobrecarga importante de la red con los mensajes de control.
Por otro lado, existen los protocolos reactivos, que que s´olo obtienen in-formaci´on de encaminamiento cuando es necesario. Son protocolos bajo de-manda que buscan la ruta hacia un destino en el momento en el que se quiere mandar informaci´on a ese destino. Obviamente, en las redes que usan esos tipos de protocolos la sobrecarga es menor que para los protocolos proacti-vos. Sin embargo, los retardos al establecimiento de las comunicaciones son mayores.
Existen protocolos h´ıbridos que combinan esos dos esquemas utilizando, por ejemplo, proactividad en las cercan´ıas del nodo considerado pero buscan-do las rutas bajo demanda para los nobuscan-dos m´as alejados.
En todos casos, la eficiencia del mecanismo depende del escenario y del patr´on de movimiento considerado. Hay que llegar a un compromiso entre la frescura de las rutas, el overhead y la latencia en descubrimiento. En es-te proyecto, ines-tentaremos definir la eficiencia de los protocolos en distintos escenarios.
Basada en el algoritmo implementado
Atendiendo al tipo de informaci´on intercambiada podemos hablar de dos familias de protocolos : estado de enlace y vector de distancia.
En un protocolo basado en el vector de distancia, cada nodo mantiene una tabla de encaminamiento de este estilo:
Desde A hasta Enlace Coste
A Local 0
B 1 1
C 2 3
D 2 5
Por otro lado, encontramos los protocolos basado en el estado del enlace. Todos los nodos mantienen una tabla del mapa completo de la red.
Desde Hasta Enlace Distancia
A B 1 1
A C 2 1
B A 1 1
B D 3 1
C A 2 1
C D 4 1
D B 3 1
D C 4 1
Cada nodo manda peri´odicamente el estado del enlace con sus nodos vecinos . El nodo A mandar´ıa<B,1,1><C,2,1>.Los mensajes se inundan en la red por todos los enlaces salientes. A la recepci´on de una tabla de n´umero de secuencia X:
- Si X es superior al n´umero actual de mapa, se actualiza la tabla y se reenv´ıa.
- Si X es inferior al n´umero actual de mapa, se manda el mapa actual por el enlace de llegada del mensaje.
- Si X es igual al n´umero actual de mapa, no se hace nada.
Con las tablas conseguidas, cada nodo aplica el algoritmo de Dijkstra pa-ra calcular las rutas ´optimas.
independientement de su algoritmo o de su esquema de descubrimiento de rutas. En cada escenario se quiere probar un determinado tipo de comunica-ciones : unicast, geocast... etc.
Los protocolos que vamos a estudiar con m´as profundidad son:
- Broadcast: Flooding,MPR, NES, CDS
- Unicast: DSDV, DSR, AODV, LAR, TORA, ZRP, OLSR y FSR
- Multicast: MAODV
- Geocast : LBM, GeoTORA, GeoGRID, y Gamer.
Se han elegido esos protocolos por ser representativos de su grupo, por ser los m´as usados o por haber trabajado con ellos a nivel de simulaci´on.
Cuadro 2.2: Caracter´ısticas de los protocolos
Protocolo Alcance Esquema Informaci´on geogr´afica Blind Floodig 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
MAODV Multicast Reactivo No
LBM Geocast Proactivo S´ı
GeoTORA Geocast Reactivo S´ı GeoGRID Geocast Reactivo S´ı GAMER Geocast Proactivo S´ı
2.2.3.
Protocolos Broadcast
[FIDSIS 2005]Blind-Flooding
El protocolo lo m´as simple es el ”Blind-Flooding“. A la recepci´on de un mensaje, un nodo lo reenv´ıa a todos sus vecinos. La ´unica optimizaci´on 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´ı duplicida-des. Aunque sea muy simple de implementar, el ”Blind Flooding”introduce mensajes redundantes y colisiones a nivel MAC que empeoran el rendimiento de la red.
Multi-Point Relay Flooding (MPR)
MDR 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´afico, los dem´as no. Esa mejora permite dividir por 2 el n´umero de mensajes de control.
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 infor-maci´on. Los nodos escuchan los mensajes y apuntan que nodos ha mandado informaci´on a cual otro. Despu´es del tiempo de espera, el nodo manda el tr´ a-fico a sus vecinos que no han sido informados por otros nodos. En la figura 2.3 se puede ver como B despu´es de un tiempo de espera se da cuenta de que no es necesario mandar tr´afico a ning´un nodo.
Figura 2.3: Mecanismo NES
Connected Dominating Sets (CDS)
[JBMDATXC 2004]
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 vecin-dario. Si no es el caso, el nodo es dominante. La asignaci´on de prioridades a los nodos es un mecanismo complicado que usa algoritmos matem´aticos com-plejos que no vamos a detaller aqu´ı. A la recepci´on de un mensaje broadcast un nodo retransmite ese mensaje solo si se trata de un nodo dominante.
Figura 2.4: Mecanismo de CDS
2.2.4.
Protocolos unicast
DSDVDestination-sequenced Distance-Vector Routing (DSDV) [CEPPB 1994] es un protocolo unicast proactivo adaptado del tradicional RIP (Routing Information Protocol). Su principal objetivo es evitar los problemas de bucles en la actualizaci´on de las tablas de encaminamiento. Por lo cual a˜nade un nuevo campo a las tablas RIP, el n´umero de secuencia que permite distinguir entre una tabla antigua y una m´as reciente.
Como su nombre lo indica, DSDV implementa un algoritmo basado en el vector de distancias. Eso significa que mantiene tablas con todos sus destinos accesibles junto con el siguiente salto, la m´etrica, y un n´umero de secuencia de la entrada en la tabla generado por el nodo destino.Las tablas se mandan en modo broadcast de forma peri´odica o cuando ocurre un cambio significativo de la topolog´ıa de red. Una ruta es considerada mejor que otra si tiene un n´umero de secuencia mayor o, en caso de empate, si la distancia al destino es menor.
incremen-tado el n´umero de secuencia en uno y la distancia se marca como infinita. Cuando A recibe este mensaje incorpora a su tabla la actualizaci´on de la entrada hacia D a trav´es de B siempre que no tuviera una entrada mejor para alcanzar D.
Para conseguir una cierta consistencia en las tablas de encaminamiento de cada nodo al cambiar la topolog´ıa de la red, las actualizaciones deben ser frecuentes y suficientemente r´apidas para que cada nodo pueda tener una visi´on realista de la red en un momento dado. El problema fundamental de DSDV es la elevada sobrecarga de control que genera. Al no haber una espe-cificaci´on est´andar, no hay productos comerciales basados en este protocolo. Sin embargo, es la base sobre cual se han desarrollado otros protocolos como por ejemplo AODV.
DSR
Dynamic Source Routing es un protocolo reactivo unicast. El protocolo se compone de dos mecanismos : el descubrimiento y el mantenimiento de rutas que permiten a un nodo origen descubrir y mantener las rutas hacia un nodo destino cuando se necesita mandar tr´afico en la red ad-hoc. Se basa en una t´ecnica de“Source Routing”. La idea de esta t´ecnica es determinar la mejor ruta completa hacia un destino. El nodo origen inunda la red con una trama de exploraci´on. Al recibir una replica de la trama exploradora, cada nodo se agrega expl´ıcitamente en la cabecera de la trama, y actualiza sus tablas con la informaci´on contenida en la cabecera de dicha trama.
El descubrimiento de rutas es el mecanismo por el cual un nodo origen S que desea mandar tr´afico a un nodo destino D, obtiene la ruta hacia D. Si S no dispone de ninguna ruta hacia D, empieza un proceso de descubrimien-to de rutas mediante un broadcast del Route Request Packet(RREQ). Este paquete contiene la direcci´on de destino, la direcci´on del nodo fuente y un n´umero ´unico de identificaci´on. Cada nodo que recibe un paquete RREQ, re-visa si conoce la ruta hacia el destino. Si no la conoce, se reenv´ıa el paquete. Si la tiene contesta en sentido inverso con un Route Reply Packet(RREP). Todos los nodos que participan al reenv´ıo del RREP a˜naden su direcci´on en la cabecera del paquete, creando de ese modo la ruta completa hasta el destino.
de transmisi´on. Este paquete de error contiene las direcciones de los dos no-dos que est´an unidos por el enlace que fall´o. En este caso, si S conoce otra ruta hacia D se puede usar, o bien se vuelve a invocar el mecanismo de descu-brimiento de rutas para remplazar la ruta ca´ıda hacia D. El mantenimiento de rutas s´olo tiene cabida cuando S est´a mandando tr´afico a D.
DSR es un protocolo totalmente reactivo, opera bajo demanda, lo que im-plica que no existe ning´un tipo de mensaje peri´odico, lo que permite reducir de forma significativa el tr´afico de control en la red y aprovechar m´as los recursos de red para paquetes ´utiles. Adem´as cada vez que se lleva a cabo el descubrimiento de rutas, los nodos implicados pueden extraer y almacenar informaci´on sobre la topolog´ıa de red, lo que ahorra muchos mensajes de control.
Para evitar que se produzca el problema de m´ultiples respuestas simult´ a-neas y optimizar la ruta final, cuando un nodo recibe un RREQ, se introduce un peque˜no retardo variable en la respuesta de cada nodo con una ruta en su cach´e. Antes de responder con una de las rutas conocidas, cada nodo debe efectuar las siguientes acciones:
- Elegir un retardod=H×(h−1 +r), donde h es la m´etrica (en saltos) de la ruta que se debe enviar, r es un n´umero flotante aleatorio entre 0 y 1, y H es un peque˜no retardo constante : H≥2×R,(R es el retardo m´aximo de propagaci´on en el enlace).
- Retardar la transmisi´on de un RREP para este nodo por un per´ıodo igual a d.
- Durante ese per´ıodo si el nodo recibe otra respuesta mejor a dicho RREQ proveniente de otro nodo, se cancela la respuesta y se retrans-mite la nueva.
La figura 2.5 ilustra el RREQ por una parte (a la izquierda) y el RREP por otra (a la derecha). En una preocupaci´on de claridad, s´olo se ilustra el campo nodo origen de la cabecera del paquete. Es interesante notar como un nodo al recibir dos rutas distintas para un mismo destino elige las menos costosa en cuanto a n´umero de saltos. En estos casos el mecanismo de retardo aleatorio previamente descrito cobra toda su importancia ya que as´ı un nodo es capaz de proveer la ruta ´optima al siguiente salto.
AODV
Ad-hoc On-Demand Distance-Vector Routing [CEPERSD 2003] es un pro-tocolo reactivo unicast. Se construye sobre el propro-tocolo DSDV analizado pre-viamente. La idea es mejorar DSDV minimizando el n´umero de paquetes broadcast requeridos para crear rutas, ya que al ser bajo demanda, los nodos que est´an en el camino no tienen que participar en el intercambio de tablas ni que mantener la ruta. A pesar de ser un protocolo reactivo, AODV tiene la peculiaridad de emitir mensajes alertando sobre su presencia de forma peri´ o-dica mediante una t´ecnica llamadaLink Layer Feedback. Esa t´ecnica permite que los nodos tengan conocimiento de sus vecinos m´as cercanos y mantegan sus tablas actualizadas reflejando los cambios en la topolog´ıa cercana. Es-tas tablas se mantienen actualizadas a lo largo del tiempo, eliminando las entradas innecesarias.
Las tablas se mantienen actualizadas mientras est´e en uso el enlace. Si un nodo origen se mueve, ´el mismo reinicia el proceso de descubrimiento de rutas. Si un nodo intermediario se mueve, su vecino anterior (en el sentido directo origen-destino) propaga hasta S, un RREP no solicitado con un n´ u-mero de secuencia mayor y con valor de saltos al destino infinitos. De esa manera, S sabe que si quiere seguir usando el enlace tiene que reiniciar el proceso de descubrimiento de rutas.
Cuando no hay tr´afico y que se quiere mantener las entradas de los no-dos vecinos, se manda mensajes peri´odicos HELLO, generalmente uno por segundo. Estos mensajes son un tipo especial de RREP no solicitados, cuyo n´umero de secuencia es igual al del ´ultimo RREP enviado y con un TTL = 1 para no inundar la red sino informar s´olo el vecindario. Cuando durante m´as de tres segundos no se ha recibido ning´un HELLO de parte de un vecino se considera el enlace roto y se borra la entrada correspondiente en la tabla de encaminamiento. En la especificaci´om de AODV se sugiere la posibilidad de utilizar datos de la capa de enlace o f´ısica para determinar el estado de los enlaces, como puede ser por ejemplo escuchar las retransmisiones realizadas por los nodos vecinos.Cada vez que se borra una entrada por rotura del enlace se debe indicar a los nodos que lo usaban como siguiente salto hacia una ruta que deben reanudar el proceso de descubrimiento de rutas. Esto se consigue mediante elUNSOLICITED ROUTE REPLY que contiene un valor infinito como distancia hacia el destino y un n´umero de secuencia igual al del ´ultimo RREP enviado.
LAR
“Location Aided Routing” [YKNHV 1998] es un protocolo proactivo que introduce la idea de enrutamiento geogr´afico para disminuir la sobrecarga en el descubrimiento de rutas. Esa informaci´on geogr´afica puede ser obte-nida usando un sistema de posicionamiento global (GPS, Galileo...), lo que limita el espacio de b´usqueda y una diminuci´on 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´on geogr´afica, se consigue una inundaci´on controlada de la red.
mueve a una velocidad mediaυ. Por lo tanto, S asume que D al instante t1 se encuentra en la EZ delimitada por el c´ırculo de rayoυ(t1−t0) y de centro L. Si adem´as se sabe que D se mueve hacia el norte podemos restringir la EZ al semic´ırculo como se muestra en la figura 2.6 b).
Figura 2.6: Ejemplos 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´on de la RZ:
- La RZ debe incluir al nodo origen S, a la EZ y a la regi´on que la rodea.
- Si se elige una RZ muy peque˜na 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´on de una ruta y la sobrecarga de mensajes diseminados. Uno de los esquemas propuestos es establecer una RZ rectan-gular, de tal forma que el rect´angulo sea el m´ınimo que contenga a la EZ y al nodo origen ubicado en las coordenadas (Xs, Ys). El nodo origen puede estar
Figura 2.7: LAR con nodo origen fuera de la RZ
TORA
”Temporally-Ordered Routing Algorithm“ (TORA) es un protocolo reactivo basado en el concepto de ”Links Reversal“. Fue propuesto para mejorar las prestaciones en redes altamente din´amicas. La idea b´asica es la generaci´on de mensajes de control del protocolo en un peque˜no conjunto de nodos cerca de la localizaci´on de un cambio topol´ogico. El protocolo desarrolla tres funciones b´asicas: la creaci´on de rutas, el mantenimento y su eliminaci´on.
La fase de creaci´on corresponde a la selecci´on de una m´etrica para estable-cer un DAG(”Directed Acyclic Graph”) hacia el destino. El DAG consiste en asignar una direcci´on 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.
una nueva alternativa para un destino, y construye otra ruta en un s´olo paso del algoritmo. En cambio, ese mecanismo en AODV o DSR correponde a tres pasos (route error / route request / route reply).
Figura 2.8: Esquema de funcionamiento de TORA
ZRP
”Zone Routing Protocol”[NB 2008] es un protocolo clasificado como h´ıbri-do ya que mezcla las capacidades de los algoritmos reactivos y proactivos. Todos los nodos mantienen proactivamente las rutas dentro de una zona local conocida como zona de encaminamiento (IARP). Sin embargo, a nivel global ZRP emplea mecanismos reactivos (IERP) para encaminamar los paquetes entre las ´areas locales.
Se define un par´ametro 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”, protocolos de la capa f´ısica, etc.
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 regi´on 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 vecindario se marcan como cubiertos.
Para mandar tr´afico el nodo comprueba si el destino est´a 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´a en su zona o si tiene alguna ruta v´alida hacia el destino. Si la respuesta es afirmativa, el nodo enviar´a un RREP (Route Reply) hacia la fuente. Si la respuesta es negativa se difunde la consulta a sus vecinos mediante el 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´on. Se recomiendan radios peque˜nos para redes densas compuestas de grupos con pocos nodos que se mueven r´apido, y radios mayores para redes dispersas de nodo con movilidad m´as baja.
OLSR
“Optimized Link State Routing“ [TCPJ 2003] es un protocolo proactivo basado en el estado de enlace. OLSR es una optimizaci´on directa del algorit-mo de estados de enlace adaptado a los requisitos espec´ıficos de una WLAN con alta movilidad. La optimizaci´on consiste principalmente en la reducci´on del tama˜no de las tablas de enlaces intercambiadas as´ı como del n´umero de retransmisiones necesarias durante los periodos de inundaci´on. La clave del algoritmo reside en el uso de retransmisiones multipunto (MPR). El meca-nismo MPR ha sido descrito en el apartado 2.2.3.
Para descubrir la topolog´ıa de la red, los nodos intercambian informaci´on acerca del estado de enlace que los conectan con los nodos MPR. Los inter-cambios son peri´odicos o generados por eventos relativos a ruptura de enlace. Incluir en las tablas s´olo los enlaces a los nodos MPR reduce el tama˜no de las mismas, lo que permite reducir el ancho de bando consumido durante su intercambio. Al mismo tiempo permite que las rutas que se vayan creando a posteriori sean ´optimas en cuanto a n´umeros de saltos ya que s´olo usan nodos MPR. OLSR se adapta bien a redes con gran n´umero de nodos y alta movilidad.
FSR
”Fisheye State Protocol”[MGXH 2002] 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´on relativa a los nodos los m´as cercanos e 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´on de forma peri´odica o seguido a un evento de ruptura de en-lace. Sin embargo, los mensajes no inundan la red sino que se intercambian ´
unicamente entre vecinos locales. En la implementaci´on de este protocolo, cada nodo almacena :
- Lista de vecinos
- Tabla con la topolog´ıa (TT)
- Tabla con el pr´oximo salto de la ruta
- Tabla de distancia al destino
de encaminamiento m´as exacta. Como resultado, FSR es m´as ´util para redes de gran tama˜no donde la movilidad es alta y el ancho de banda bajo.
2.2.5.
Protocolos multicast
MAODVMAODV es la extensi´on multicast de AODV conocida tambi´en como Mul-ticast AODV. Lo que se pretende construir son ´arboles multicast bidirec-cionales compartidos que conecten m´ultiples fuentes y destinos para cada grupo multicast. Estos ´arboles se mantienen mientras hay miembros del gru-po conectados a alguna parte del ´arbol. Cada grupo multicast tiene un nodo l´ıder, responsable de mantener el valor del n´umero de secuencia. gracias a ese n´umero de secuencia se consigue que el grupo multicast use siempre rutas actualizadas. El nodo l´ıder es la raiz del ´arbol multicast. MAODV comparte muchas similitudes con el protocolo unicast AODV como son los paquetes de Route Request (RREQ) y Route Reply (RREP) as´ı como la tabla de en-caminamiento. Adem´as se usan mensajes de Multicast Activations (MACT) y Group Hello (GRPH). El rango de diseminaci´on de los RREQ lo indica el campo TTL de la cabecera.
Los nodos l´ıderes de grupo inundan la red peri´odicamente anunciando su direcci´on y su situaci´on de l´ıder de grupo as´ı como el n´umero de secuencia del grupo. Cuando un nodo quiere enviar mensajes a dicho grupo multicast para el cual no conoce el l´ıder, primero intenta hacerse l´ıder del grupo. Si no recibe respuesta ´el mismo se convierte en l´ıder y comienza a emitir. Si ya conoc´ıa la identidad del l´ıder por haber recibido previamente un mensaje de anuncio, env´ıa los mensajes de datos directamente al l´ıder del grupo para que este los distribuya por el ´arbol multicast.
Cuando un nodo desea unirse a un grupo como receptor, env´ıa una peti-ci´on inundando la red. Estas peticiones pueden ser contestadas por cualquier miembro del grupo multicast. Las respuestas son enviadas al origen de modo que los nodos por los que pasa se convierten en nuevos miembros del ´arbol multicast.
2.2.6.
Protocolos geocast
mensajes a un grupo de veh´ıculos de una determinada zona, para anunciar por ejemplo la presencia de un peligro en la carretera.
LBM
“Location Based Multicast” [YKNHV 1999] es un protocolo orientado a la transmisi´on 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´as nodos seg´un dos esquemas:
- LBM box
- LBM step
Figura 2.9: Esquema de LBM-box
Si el esquema considerado es LBM box, un nodo, a la recepci´on de un paquete geocast retransmite a los nodos que se encuentran el zona de forwar-ding, sino no reenv´ıa el paquete. Seg´un ese esquema la zona de forwarding es el rect´angulo m´ınimo que engloba el origen del paquete geocast y la zona geocast, como se puede apreciar en la figura 2.9.
En cambio, en el esquema de LBM step se usa otra forma para determi-nar la zona de forwarding. Si A recibe un paquete geocast de un nodo B, A retransmite el paquete si est´a m´as cerca del centro de la zona geocast que B de por lo menos una distancia δ. Este mecanismo se ilustra en la figura 2.10. Consideramos que δ = 0. B reenviar´a el paquete recibido de A ya que
geocast. Sin embargo, K descartar´a el paquete de B por estar m´as lejos del centro de la zona geocast. Resumiendo, este protocolo asegura que en cada retransmisi´on el paquete se acerca m´as a la zona geocast.
Figura 2.10: Esquema de LBM-step
GEOTORA
GEOTORA como su propio nombre lo indica deriva directamente del al-goritmo unicast TORA. Se construy´o de la siguiente manera: se modific´o TORA para hacer un protocolo anycast, modificando este protocolo anycast se consigui´o un protocolo multicast. Veamos primero como funciona el algo-ritmo anycast.
En la versi´on unicast de TORA se asigna un DAG para cada nodo de la red. En cambio, en la versi´on 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´on ya que no nos in-teresa realizar encaminamiento dentro del grupo anycast, basta con alcanzar un nodo del grupo anycast.
paquete a sus vecinos. Cuando el nodo A recibe el pquete 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´on geocast.
Figura 2.11: Funcionamiento de GEOTORA
GEOGRID
GEOGRID [WLYTKLJS 2000] es un protocolo geocast derivado del uni-cast GRID. Al igual que GRID, GEOGRID realiza una partici´on del ´area geogr´afica que ocupa la red en celdas de dos dimensiones. Cada celda es un cuadrado de dimensionesd×d. La zona de forwarding est´a definida por los nodos origenes y la zona geocast, de forma similar a la versi´on box de LBM. En cada celda, se elige un nodo gateway. La diferencia principal entre LBM y GEOGRID es que s´olo los nodos gateways tienen la responsabilidad de trans-mitir los paquetes geocast. Existen dos versiones de GEOGRID: la versi´on basada en flooding y la versi´on basada en tickets.
5 tickets, 2 los entrega a A, 2 a B y 1 a C, que son los gateways m´as cercanos a la zona de geocast.
Figura 2.12: Esquema GEOGRID
Cada gateway transmite paquetes GATE que indica su naturaleza de gateway al resto de la red. Un nodo que quiere mandar tr´afico 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´a m´as cerca del centro de la zona geocast manda a su vez un BID. El nodo que transmite el ´ultimo BID (2 ms sin recepci´on de BID) en la celda se considera gateway para esa celda. Otra opci´on para elegir el gateway es elegir m´ultiples gateways temporales dentro de la misma celda. En esta situaci´on si un gateway recibe un paquete de otro gateway m´as cercano al centro deja de ser gateway autom´aticamente sin enviar ning´un 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´as, 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´on de gateway en la celda.
GAMER
origen hacia una zona geocast. Esa idea proviene de la constataci´on que una s´ola ruta hacia la zona geocast es fr´agil sobre todo en un entorno de movili-dad 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 median-te un flooding un paquemedian-te 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 paque-te JOIN-TABLE. Cuando el nodo origen recibe la respuesta JOIN-TABLE puede empezar a mandar paquetes geocast a trav´es de las mallas de la red.
GAMER se adapta de forma din´amica a la topolog´ıa de red cambiando el tama˜no 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 elehir entre tres esquemas de zonas de forwarding: CONE, CORRIDOR y FLOOD.
Figura 2.13: Zonas de forwarding GAMER
2.3.
Seguridad
Los requisitos de seguridad en una VANET son los mismos que en una red tradicional, es decir:
- Confidencialidad: La informaci´on s´olo debe ser legible por los autoriza-dos.
- Integridad : La informaci´on s´olo puede ser modificada por los autoriza-dos.
- 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 descri-to anteriormente (descri-topolog´ıa din´amica, falta de un procesamiento centraliza-do...etc.) hacen que sea mucho m´as d´ıficil cumplir estos requisitos de seguri-dad. La pol´ıtica de seguridad a aplicar en un entorno ad-hoc depender´a, en gran media, de la aplicaci´on 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´an ser cubiertos por cualquier pol´ıtica de seguridad en redes ad-hoc: control de acceso, sistema de detecci´on de intrusos (SDI), seguridad de los protocolos de encaminamiento y servicios de gesti´on de claves.
2.3.1.
Ataques en redes VANETs
Ataques b´asicos :- Falsificaci´on de la informaci´on : El atacante difunde informaci´on falsa o err´onea para que afecte al resto de los veh´ıculos
- Manipulaci´on de la informaci´on del sensor: Modificar su posici´on, di-recci´on, velocidad, etc. para escapar de ciertas responsabilidades por ejemplo al haber provocado un accidente.
- Denegaci´on de servicio: utilizar un inhibidor de frecuencia para con-seguir que un veh´ıculo no reciba ninguna se˜nal de su entorno en una cierta zona.
- Rastreado de veh´ıculos: Seguir la pista de un veh´ıculo infect´andolo con alg´un virus que monitorice el estado de dicho veh´ıculo.
Existen ataques sofisticados como el veh´ıculo oculto o el t´unel pero no los vamos a detallar en este documento.
2.3.2.
Control de accesso
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 consequencias de un ataque en el cual un intruso tendr´ıa acceso a los servicios de la red pueden ser catastr´oficas ya en las VANETs los nodos asumen tareas de gesti´on y de encaminamiento al no tener una unidad de centralizaci´on. Un intruso podr´ıa desviar el tr´afico durante el encaminamiento o tener acceso a claves de identificaci´on.
En la capa de red, es necesario garantizar que ning´un nodo no autorizado se una a la red bien para recibir informaci´on o para encaminarla. As´ı mismo a nivel de aplicaci´on tambi´en es imprescindible asegurarse que elementos sin autorizaci´on no acceden a servicios, por ejemplo al servicio de gesti´on de claves.
El control de acceso consiste generalmente en la autenticaci´on de los usua-rios 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 centrali-zados mientras que en otras est´an distribuidos, este hecho hace necesario el uso de diferentes mecanismos de control de acceso. Si elegimos un mecanis-mo de control de acceso distribuido para la red, ser´a necesario un control de acceso basado en certificados digitales y autoridades certificadoras. En otros esquemas con servicios centralizados se requiere una autenticaci´on basada en usuario y contrase˜na. Es muy ´util hacer un estudio previo de las necesida-des de seguridad de la red a necesida-desplegar, de esta forma, se podr´an adecuar los mecanismos de control de acceso a la red.
2.3.3.
Sistemas de detecci´
on 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´on de intrusos (SDI) forman una segunda l´ınea de protecci´on muy importante.
En [YZWL 2000] los autores proponen una arquitectura distribuida y cooperativa para la detecci´on de intrusos. En este sistema, cada nodo eje-cuta un agente SDI que monitoriza las actividades locales al nodo. Si el SDI detecta una intrusi´on 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´on se usa un protocolo cooperativo con los vecinos para determinar si la intrusi´on tuvo lugar o no.
En [OKRG 2002] se propone un sistema distribuido basado en tecnolog´ıa de agentes m´oviles. Un agente m´ovil se define como una entidad software aut´onoma, ligera y din´amicamente actualizable que atraviesa la red y se eje-cuta sobre ciertos nodos. Este m´etodo es especialmente apropiado en el caso de las VANETs, d´onde 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´ecnicas de SDI dependen siempre de la aplicaci´on y del escenario concreto sobre el cual se ejecuta. Dada la sobre-carga que pueden introducir estos mecanismos, en t´erminos de transmisi´on sobre el medio inal´ambrico, de procesamiento y almacenamiento en los no-dos, su uso puede resultar justificable ´unicamente 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 im-ponga limitaciones intolerables para las prestaciones de los servicios finales ofrecidos al usuario.
2.3.4.
Seguridad en el encaminamiento
Los nodos en una VANETs act´uan como routers, participando en el proto-colo de encaminamiento para descubrir y mantener rutas hacia otros nodos de la red. En las redes tradicionales, los routers son administrados por ope-radores de confianza pero eso deja de ser cierto en las VANETs d´onde 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 pueder verse seriamente afectado. Por este motivo la seguridad en el encaminamiento es de primera importancia para la seguridad global del sistema.
basan en las t´ecnicas TIARA como por ejemplo SRP o ARIADNE.
SRP proporciona informaci´on segura y autenticada a cada par de nodos que desea establecer una comunicaci´on. El establecimiento se har´a bajo una asociaci´on de seguridad entre el nodo que inicia la comunicaci´on y el nodo destino.
ARIADNE usa un proceso de criptograf´ıa sim´etrica que permite asegurar la integridad y la autenticaci´on en las comunicaciones del protocolo.
2.3.5.
Cifrado y gesti´
on de claves
El empleo de t´ecnicas de cifrado y de firmas digitales como mecanismo de seguridad requiere el uso de claves criptogr´aficas, que ser´an compartida por todos los nodos. Por lo tanto, se debe disponer de un mecanismo seguro para la gesti´on de claves.
Se puede dividir las VANETs en dos grupos: las auto organizadas que se gestionan de forma aut´onoma y las VANETs que hacen uso de una entidad externa de confianza para la gesti´on de claves. En esquemas de VANETs pura, sin red de respaldo, es m´as apropiado usar un esquema de gesti´on 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´as populares son:
Para una red VANET pura:
- Gesti´on de claves en cadena de certificados.
- Gesti´on de clave basada en movilidad.
Para un red VANET h´ıbrida:
- Autoridades de certifiaci´on distribuidas.
- Gesti´on paralela de claves.
Existen muchas otras opciones muy interesantes, pero dado el alcance de este documento nos conformaremos con explicar las alternativas mencionadas.
Gesti´on de claves en cadena de certificados
Gesti´on de claves basada en la movilidad
Se basa en un esquema de distribuci´on peer-to-peer de las claves de los nodos basada en la movilidad de cada nodo. Se transmite una clave a un nodo seg´un 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.
Autoridades de certificaci´on distribuidas
Se basa en una entidad externa de certificaci´on que se encarga de distri-buir las claves a los nodos de la red. Esta entidad debe ser altamente segura para que ning´un atacante pueda tomar el control de ella y comprometer los mecanismos de certificaci´on. Se puede distribuir los certificados de forma par-cial o total.
En un mecanismo de distribuci´on parcial de los certificados se elige un subconjunto de nodos llamados servidores a los cuales se transmiten las cla-ves. Esos nodos deben disponer de una clave privada y una clave p´ublica 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´on total de los certificados, la clave se dis-tribuye 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´a el propio nodo qui´en reconstruye la firma digital del grupo.
Gesti´on paralela de claves
Esta alternativa descrita en [SYRK 2004] se basa en una distribuci´on 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 certificado a nodos servidores y luego tiene lugar el mecanismo de cadenas de certificados.
2.4.
Servicios
entorno veh´ıcular permite desplegar una infinidad de servicios, en el presente apartado se mostrar´an los m´as aceptados y los que pensamos que aportan las mejoras las m´as significativas a medio o largo plazo.
2.4.1.
Sevicios para la seguridad vial
Los servicios dirigidos a la segurida vial son de forma clara los m´as im-portantes y los m´as criticos dado que su objetivo no es otro que salvar vidas disminuyendo el n´umero de accidentes en la carretera. En este contexto se est´a haciendo un esfuerzo importante por parte de la comisi´on europea en la investigaci´on, desarrollo e implementaci´on de este tipo de servicios con el fin de que entren en actividad lo antes posible.
Mecanismos anti-colisi´on
Se trata de un servicio de ayuda a la conducci´on que sirve para detectar posibles obst´aculos en la v´ıa. La funcionalidad principal consiste en el aviso mediante se˜nales ac´usticas 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´asicamente la comunicaci´on se dar´a entre veh´ıculos con visi´on in´alambrica directa sin nodos intermediarios.
Para un correcto despliegue ser´ıa necesaria una peque˜na instalaci´on en los equipos de los usuarios que enviase a sus vecinos informaci´on de posici´on, trayectoria y velocidad as´ı como un mecanismo que permanentemente escuche la informaci´on enviada por el resto de los veh´ıculos y la infraestructura.
Aviso de peligro
La funcionalidad principal de ese servicio consiste en detectar eventos pe-ligrosos 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´on o el conductor mismo puede detectar el peligro y a trav´es de una interfaz vocal describir el peligro para el resto de los usuarios.
