U NIVERSIDADE DE V IGO D EPARTAMENTO DE E NXEÑERÍA T ELEMÁTICA EE DE T ELECOMUNICACIÓN T ESIS DOCTORAL M EJORA DE LOS SERVICIOS DE COMUNICACIONES SOBRE REDES MÓVILES AD HOC EN ESCENARIOS PEDESTRES Y VEHICULARES MEDIANTE VIRTUALIZACIÓN . Autor: Jack Fernando Bravo Torres Directores: Dr. Martín López Nores Dra. Yolanda Blanco Fernández 2015 A mi esposa Cinthya y a mis hijas Sophía y Elena, compañeras inseparables en esta nuestra aventura. Agradecimientos La fe y la razón son dos cuestiones opuestas, según quien lo mire; pero en mi caso, ha sido mi fe la que me ha permitido profundizar en el mundo de la razón. Por ello, mi eterno agradecimiento a Dios porque a lo largo del camino transitado he podido percibir cotidianamente su presencia y ayuda en las personas a mi alrededor. Mi agradecimiento profundo a mis directores Dr. Martín López Nores y Dra. Yolanda Blanco Fernández, porque, sin temor a equivocarme, han sido las personas más influyentes en mi formación académica. Gracias por el tiempo, la dedicación y la pasión que le han puesto a este trabajo; gracias por su paciencia ante mis errores y por el ánimo infundido para alcanzar la meta; gracias por compartir su conocimiento y enseñarme a través del ejemplo; y, sobretodo, gracias por su amistad que es la mayor recompensa que he podido obtener. De igual forma, expreso mi más sincero agradecimiento a los profesores del Grupo de Investigación de Servicios para la Sociedad de la Información del Departamento de Ingeniería Telemática de la Universidad de Vigo, en especial a los doctores José Pazos y Manolo Ramos por compartir su experiencia y su conocimiento para enriquecer el trabajo desarrollado. Hago extensivo mi agradecimiento al Padre Javier Herrán, al Dr. Luciano Bellini y al Dr. Edgar Loyola, rector, ex-rector y ex-vicerrector de la Universidad Politécnica Salesiana del Ecuador (UPS) por confiar en mi trabajo y brindarme su apoyo para desarrollar mis estudios doctorales en la Universidad de Vigo. Gracias a Luis Caldas, Juan Carlos Zaruma, Juan Pablo Hurtado y Edgar Siguenza, estudiantes de la UPS, por el trabajo desarrollado en la implementación del simulador utilizado en esta tesis. En estos años en Vigo, he tenido la suerte de conocer muy buenos amigos que me han hecho sentir como en casa, en una tierra ajena. Gracias a Miguel, Manuela, Fernando, Sandra, Fátima, Gabriel, Ricardo e Hilario; por compartir el día a día y por hacer más ameno el trabajo. Gracias a Fabián por abrirnos las puertas de su casa en Madrid y por el cariño brindado. Gracias a Lito y Pepita, por facilitar mi estancia y la de mi familia con sus atenciones en casa. Gracias a Susi, Andrea y Diego por el cariño que nos han brindado a mi familia y a mí. En el plano estrictamente personal, quiero expresar mi gratitud a mi esposa y mis hijas por la infinita paciencia, cariño y el amor que me han demostrado al ceder el tiempo que les correspondía para que pudiera avanzar en mi trabajo. Gracias por conEstos agradecimientos se hacen extensivos a la Secretaría Nacional de Ciencia y Tecnología del Ecuador y la Universidad Politécnica Salesiana de Ecuador, ya que la financiación recibida a través del contrato de beca No 2013-AR6C270 y el convenio No LCS-0001-2013, respectivamente, han permitido realizar este trabajo en las mejores condiciones, tanto en lo referente a medios materiales como a las posibilidades de participación en congresos internacionales. III IV vertir este proyecto personal en un emprendimiento familiar y por aventurarse conmigo a descubrir nuevos horizontes. Gracias a mis padres Wilson y Mariela, porque con su ejemplo me enseñaron que los sueños son posibles si te propones hacerlos realidad. Gracias a mis hermanos Wilson, Juan Carlos y Mariela por estar siempre ahí para apoyarme y darme su cariño. En definitiva, dejo constancia de mi gratitud a todos quienes de una u otra forma han sido parte de esta aventura. Muchas gracias. Resumen La idea de las redes ad-hoc (MANET) nace con el fin de proporcionar servicios de comunicaciones sin el soporte de infraestructura alguna. Típicamente, el estudio de este tipo de redes ha sido orientado a aplicaciones militares o a escenarios de desastres naturales donde la infraestructura es escasa, inexistente o no funcional. Sin embargo, en los últimos años, con el desarrollo de la tecnología inalámbrica, los investigadores han vislumbrado la oportunidad de prestar nuevos servicios de comunicación entre usuarios de electrónica de consumo. Así, los esfuerzos de la comunidad investigadora en este campo se han centrado en el diseño y evaluación de algoritmos y protocolos para implementar comunicaciones eficientes en escenarios donde los nodos móviles colaboran y comparten recursos para proveer funcionalidades usuales en las redes con infraestructura. En ese contexto, las redes móviles ad-hoc (MANETs) y las redes vehiculares adhoc (VANETs) han sido un tópico de extensa investigación por muchos años, con un sinnúmero de propuestas en la literatura para hacer frente a los desafíos planteados principalmente por la movilidad de los dispositivos. Muchos autores han defendido las MANETs como un elemento crucial para el futuro de los servicios de comunicación ubicuos. De igual forma, el desarrollo de las tecnologías de comunicaciones inalámbricas nos permite vislumbrar que en un futuro cercano las VANETs se convertirán en una extensión del Internet cableado, allanando el camino a un conjunto de nuevos servicios de comunicaciones. Esas visiones requieren medios para tornar este tipo de redes en ambientes de comunicación más robustos, capaces de soportar la operación de sistemas distribuidos que cursen grandes cantidades de información multimedia. Desde esta perspectiva, investigadores del Instituto Tecnológico de Massachusetts (MIT) propusieron una capa de virtualización, denominada Virtual Node Layer (VNLayer), con procedimientos para que nodos móviles físicos emulasen colaborativamente nodos virtuales que podrían ser direccionados como servidores en localizaciones conocidas. Esta aproximación se demostró conveniente para facilitar el desarrollo de software de aplicación en entornos tradicionales de MANETs. Esta tesis analiza las potencialidades de la virtualización para brindar nuevos servicios de comunicación en ambientes MANETs y VANETs, diseñando, desarrollando y evaluando nuevos mecanismos en la capa de virtualización para alcanzar este objetivo. Así, en primera instancia, presentamos un grupo de mejoras y nuevos mecanismos orientados a incrementar el rendimiento de la capa de virtualización en entornos MANETs de mayor movilidad y con aplicaciones más demandantes, otorgándole flexibilidad para ajustarse a las necesidades de los usuarios, y una mayor robustez y rapidez para reaccionar ante los fallos provocados por la movilidad de los nodos o las condiciones adversas del medio inalámbrico (pérdida de paquetes de control debido a V VI colisiones, ruido, etc.). De igual forma, proponemos una serie de mejoras a la versión virtualizada del protocolo de encaminamiento AODV para aprovechar las nuevas características de la capa de virtualización, así como nuevos procedimientos para evitar la pérdida de paquetes debido a la movilidad de los nodos físicos que le dan soporte. Ya en el campo de las VANETs, este trabajo introduce por primera vez el concepto de la capa de virtualización en estos ambientes. Para ello, hemos diseñado varios procesos que permiten (i) adaptar la forma y ubicación de las regiones cubiertas por los nodos virtuales a las condiciones de los planos de las calles y vías, propias del entorno urbano, y (ii) ofrecer una reacción más rápida y robusta de los nodos virtuales frente la alta variabilidad y movilidad de los vehículos y las condiciones de mayor pérdida de paquetes de las redes vehiculares. Adicionalmente, diseñamos un nuevo protocolo de encaminamiento que aprovecha las ventajas ofrecidas por la capa de virtualización en los entornos vehiculares para obtener un mejor rendimiento que algunos protocolos presentes en la literatura. Nuestras contribuciones a la capa de virtualización, tanto en el campo de las MANETs como en el de las VANETs, son validadas a través de una serie de experimentos de simulación, desarrollados en diferentes escenarios y aplicaciones, y contrastadas con varios protocolos relevantes en la literatura. Los resultados muestran que los nuevos mecanismos que hemos implementado superan notablemente el rendimiento de la VNLayer original, al tiempo que aseguran mejores prestaciones en las comunicaciones que varios algoritmos relevantes en el campo de los escenarios propuestos, asegurando una buena tasa de entrega de paquetes gracias a la efectiva explotación de las comunicaciones multisalto. Abstract Ad-hoc networks arose with the aim of providing communication services without the support of any fixed infrastructure. Typically, the study of these kind of networks has been focused on military applications or natural disaster scenarios where infrastructure is scarce, nonexistent or nonfunctional. However, in recent years, with the development of wireless technology, researchers have envisioned the opportunity to provide new communication services among users of consumer electronics. Thus, the efforts of the research community in this field have focused on the design and evaluation of algorithms and protocols to implement efficient communications in scenarios where mobile nodes collaborate and share resources to provide functionalities which are common in networks with infrastructure. In this context, mobile ad-hoc networks (MANETs) and vehicular ad-hoc networks (VANETs) have been a topic of extensive research for many years, with countless proposals in the literature dealing with the challenges raised mainly by the mobility of devices. Many authors have defended MANETs as a crucial element for the future of pervasive communication services. Similarly, the development of wireless communication technologies allows us to foresee that VANETs will become an extension of the wired Internet in the near future, paving the way to a set of new communication services. These visions require means to turn this kind of networks into more robust communication environments, capable of supporting the operation of distributed systems carrying large amounts of multimedia information. From this perspective, researchers from the Massachusetts Institute Technology (MIT) presented a layer of virtualization, called the Virtual Node Layer (VNLayer), with procedures for physical mobile nodes to collaboratively emulate virtual nodes that could be addressed as server devices in known locations. This approach has proven suitable for easy development of application software in traditional MANET environments. In this thesis we are interested in analyzing the potential of the virtualization to provide new communication services in MANET and VANET environments, designing, developing and testing new mechanisms within the virtualization layer to achieve this goal. So, firstly, we present a set of improvements and new mechanisms aimed at increasing the performance of the virtualization layer in MANET environments with higher mobility and more demanding applications, giving it flexibility to adapt to the needs of users, and greater robustness and speed to react to failures caused by the mobility of nodes or adverse conditions of the wireless medium (control packet loss due to collisions, noise, etc.). Likewise, we propose a set of enhancements to the virtualized version of the routing protocol AODV to exploit new features of the virtualization layer, as well VII VIII as new procedures to avoid packet losses due to the mobility of physical nodes that support it. To the best of our knowledge, this thesis is the first study to introduce the concept of virtualization layer in VANET environments. To do this, we designed several processes that allow (i) adapt the shape and location of the regions covered by the virtual nodes to the conditions of the layouts of the streets and roads, typical of urban environment, and (ii) provide a faster and more robust response of the virtual nodes to deal to high variability and mobility of vehicles, and the major conditions for packet loss in vehicular networks. Additionally, we design a new routing protocol that takes advantage of the virtualization layer to deliver better performance than recent protocols in the literature. Our contributions to the virtualization layer, both in the field of MANETs as in VANETs, are validated through a set of simulation experiments, developed in different scenarios and applications, and compared with several relevant protocols representative of the current state-of-the-art. The results of simulation experiments conducted in MANET and VANET environments show that the new mechanisms we have implemented significantly outperform the original VNLayer, while ensuring best performance in communications that the most relevant algorithms in the field of the proposed scenarios. A good packet delivery rate is assured thanks to the effective operation of multi-hop communications. “El éxito no reside en vencer siempre, sino en no desanimarse nunca” Napoleón Bonaparte Índice general Índice de figuras XVII Índice de tablas XIX I Ámbito, objetivos y planteamiento de la tesis 1. Introducción 1.1. Redes inalámbricas ad-hoc multisalto . . . . . . . . . . . . . . . 1.1.1. Redes móviles ad-hoc . . . . . . . . . . . . . . . . . . . 1.1.2. Redes vehiculares ad-hoc . . . . . . . . . . . . . . . . . . 1.1.3. Redes inalámbricas en malla . . . . . . . . . . . . . . . . 1.2. Computación en nube en ambientes móviles . . . . . . . . . . . . 1.3. Computación social ubicua . . . . . . . . . . . . . . . . . . . . . 1.4. Problema a resolver . . . . . . . . . . . . . . . . . . . . . . . . . 1.5. La plataforma SPORANGIUM . . . . . . . . . . . . . . . . . . . 1.5.1. SPORANGIUM: aplicación en lugares de encuentro . . . 1.5.2. SPORANGIUM: aplicación en redes sociales vehiculares 1.5.3. SPORANGIUM: aplicación en ciudades inteligentes . . . 1.6. Objetivos y contribuciones . . . . . . . . . . . . . . . . . . . . . 1.7. Organización de la memoria . . . . . . . . . . . . . . . . . . . . 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 2. Mecanismos para hacer frente a la movilidad en las redes inalámbricas ad-hoc 2.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2. Mecanismos de encaminamiento para MANETs . . . . . . . . . . . . 2.2.1. Protocolos de encaminamiento proactivos . . . . . . . . . . . 2.2.2. Protocolos de encaminamiento reactivos . . . . . . . . . . . . 2.2.3. Protocolos de encaminamiento híbridos . . . . . . . . . . . . 2.2.4. Protocolos de encaminamiento jerárquicos . . . . . . . . . . 2.2.5. Protocolos de encaminamiento de multidifusión . . . . . . . . 2.2.6. Protocolos de encaminamiento geográficos . . . . . . . . . . XI 3 4 4 6 7 9 11 13 14 17 18 19 21 21 23 23 24 24 27 29 34 37 39 ÍNDICE GENERAL XII 2.2.7. Protocolos de encaminamiento multitrayecto . . . . . . . . . 41 2.2.8. Protocolos de encaminamiento basados en la potencia . . . . 43 2.2.9. Protocolos de encaminamiento basados en inteligencia de enjambre (SI) . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 2.3. Mecanismos de encaminamiento para VANETs . . . . . . . . . . . . 47 2.3.1. Protocolos de encaminamiento basados en topología . . . . . 48 2.3.2. Protocolos de encaminamiento geográficos . . . . . . . . . . 50 2.3.3. Protocolos de encaminamiento jerárquicos . . . . . . . . . . 52 2.3.4. Protocolos de encaminamiento basados en intersecciones . . . 55 2.3.5. Protocolos de encaminamiento tolerantes al retardo . . . . . . 56 2.4. Mecanismos de encaminamiento para redes inalámbricas en malla . . 58 2.5. Virtualización en redes móviles ad-hoc . . . . . . . . . . . . . . . . . 62 2.5.1. La capa de nodos virtuales . . . . . . . . . . . . . . . . . . . 62 2.5.2. Versión virtualizada de AODV (VNAODV) . . . . . . . . . . 67 2.5.3. Versión virtualizada de RIP (VNRIP) . . . . . . . . . . . . . 70 2.6. Sumario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 II Mejoras a la capa de virtualización 73 3. Mejoras a la capa de virtualización en entornos MANET 75 3.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 3.2. VNLayer+: Mejoras a la VNLayer . . . . . . . . . . . . . . . . . . . 77 3.2.1. Disposición de los VNs acorde a la aplicación . . . . . . . . . 77 3.2.2. Un nuevo proceso para la elección del líder . . . . . . . . . . 78 3.2.3. Manejo del liderazgo duplicado . . . . . . . . . . . . . . . . 80 3.2.4. Un nuevo enfoque para la designación de los nodos backup . . 81 3.2.5. Manteniendo la información de estado para sincronizar nodos advenedizos . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 3.2.6. Gestionando las regiones vecinas a través de instantáneas de su estado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 3.2.7. Un cambio adicional en la interfaz a la capa de red . . . . . . 83 3.3. VNAODV+: Mejoras a VNAODV . . . . . . . . . . . . . . . . . . . 83 3.3.1. Retornando a los esquemas de transmisión de AODV . . . . . 84 3.3.2. Un nuevo proceso de corrección de ruta . . . . . . . . . . . . 85 3.3.3. Un procedimiento de soft handoff . . . . . . . . . . . . . . . 86 3.4. Aplicación a la distribución de contenido P2P en entornos MANET . 88 3.4.1. REENACT . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 3.4.2. Rediseño del Sistema . . . . . . . . . . . . . . . . . . . . . . 90 3.4.3. Experimentos de Simulación . . . . . . . . . . . . . . . . . . 90 3.5. Discusión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 ÍNDICE GENERAL 4. Mejoras a la capa de virtualización en entornos VANET XIII 97 4.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 4.2. VaNetLayer: Mejoras a la VNLayer para entornos VANET . . . . . . 98 4.2.1. Un arreglo más vinculado al trazado para los VNs . . . . . . . 98 4.2.2. Mejoras al procedimiento para la elección de líder . . . . . . 101 4.2.3. Haciendo que los backups den un mayor apoyo al trabajo del líder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 4.2.4. Varios líderes por región . . . . . . . . . . . . . . . . . . . . 103 4.3. Modelado de los procesos de la capa de virtualización . . . . . . . . . 104 4.3.1. Análisis de los procesos de la VNLayer . . . . . . . . . . . . 104 4.3.2. Análisis de los procesos de la VaNetLayer . . . . . . . . . . . 105 4.4. VNIBR: Un nuevo protocolo de encaminamiento sobre nodos virtuales basado en intersecciones . . . . . . . . . . . . . . . . . . . . . . . . 108 4.5. Rendimiento de la VNLayer+ y VNAODV+ en escenarios vehiculares 112 4.5.1. Medidas en la capa de virtualización . . . . . . . . . . . . . . 112 4.5.2. Medidas en la capa de red . . . . . . . . . . . . . . . . . . . 119 4.5.3. Discusión . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 4.6. Análisis del rendimiento de la VaNetLayer . . . . . . . . . . . . . . . 125 4.6.1. Medidas en la capa de virtualización y de red . . . . . . . . . 125 4.6.2. Discusión . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 4.7. Análisis del rendimiento de VNIBR . . . . . . . . . . . . . . . . . . 129 4.7.1. Discusión . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 5. Descarga colaborativa de contenidos y acceso a Internet 135 5.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 5.2. Distribución P2P de contenidos en VANETs . . . . . . . . . . . . . . 135 5.3. Aplicación de la VaNetLayer a la descarga colaborativa y diseminación P2P de contenidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 5.3.1. Discusión . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 5.4. Soporte de la VaNetLayer al acceso individualizado a contenido web . 143 5.4.1. Discusión . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 III Conclusiones 6. Conclusiones y futuros trabajos 155 157 6.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 6.1.1. Contribuciones en entornos MANET . . . . . . . . . . . . . 157 6.1.2. Contribuciones en entornos VANET . . . . . . . . . . . . . . 160 6.2. Líneas de trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . 162 ÍNDICE GENERAL XIV IV Apéndices A. Publicaciones derivadas de la tesis A.1. Publicaciones en revistas internacionales . . . A.1.1. Publicaciones aceptadas . . . . . . . A.1.2. Artículos en proceso de revisión . . . A.2. Publicaciones en conferencias internacionales A.2.1. Publicaciones aceptadas . . . . . . . A.2.2. Artículos en proceso de revisión . . . 169 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 171 171 172 172 172 173 Índice de figuras 1.1. Representación de una red móvil ad-hoc (MANET). . . . . . . . . . . 5 1.2. Representación de una red vehicular ad-hoc (VANET). . . . . . . . . 7 1.3. Representación de una red WMN. . . . . . . . . . . . . . . . . . . . 8 1.4. Arquitectura conceptual de la plataforma SPORANGIUM. . . . . . . 15 1.5. Visión combinada de las redes ad-hoc y la computación móvil en nube. 17 2.1. Clasificación de los protocolos de encaminamiento en MANETs. . . . 24 2.2. Retransmisores multipunto. . . . . . . . . . . . . . . . . . . . . . . . 26 2.3. Funcionamiento del protocolo AODV. . . . . . . . . . . . . . . . . . 28 2.4. Ejemplo de ZRP con ρ=2. . . . . . . . . . . . . . . . . . . . . . . . . 30 2.5. Conectividad en ZHLS. . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.6. Ejemplo de cluster físico y virtual [106]. . . . . . . . . . . . . . . . . 35 2.7. Un ejemplo mostrando un posible conjunto de nodos de núcleo y sus conexiones físicas y virtuales. . . . . . . . . . . . . . . . . . . . . . 36 2.8. Ejemplo de gestión de los nodos miembro en AQM [32]. . . . . . . . 39 2.9. Generación de la ruta anycast en GeoTORA. . . . . . . . . . . . . . 41 2.10. Proceso de descubrimiento de ruta con ARA. . . . . . . . . . . . . . 45 2.11. Clasificación de los protocolos de encaminamiento en VANETs. . . . 48 2.12. Cluster pasivo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 2.13. Ejemplo de red WMR. . . . . . . . . . . . . . . . . . . . . . . . . . 59 2.14. Ejemplo de red WMN para MR-TBMPA. . . . . . . . . . . . . . . . 60 2.15. Nodos virtuales estáticos (cuadrados blancos) superpuestos a los nodos móviles físicos (círculos negros) en una MANET. . . . . . . . . . . . 63 2.16. Ilustración de la retransmisión de paquetes basada en la VNLayer con la implementación desarrollada por Brown (cuadro grande) y Wu (cuadro pequeño). Las líneas dobles indican fuentes o destinos de los paquetes de datos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 2.17. Máquina de estados del procedimiento de elección de líder definida en [240]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 2.18. Evolución de la ruta de comunicación de VNAODV entre dos PNs cuando uno de ellos se mueve, con y sin correcciones de ruta. . . . . . 69 XV XVI ÍNDICE DE FIGURAS 3.1. Regiones de nodos virtuales superpuestos a una parte del centro de Cuenca, Ecuador. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 3.2. La máquina de estados de nuestro nuevo proceso de elección de líder. 79 3.3. Evolución de la ruta de comunicación de VNAODV+ entre dos PNs cuando uno de ellos se mueve, con y sin corrección de rutas. . . . . . 85 3.4. Una configuración para ilustrar el mecanismo de soft handoff de VNAODV+. 87 3.5. Las cinco configuraciones comparadas en nuestros experimentos. . . . 88 3.6. Sobrecarga del tráfico de control (overhead) en las MANETs debido a la capa de virtualización (si existe), la capa de red y la de transporte. . 93 3.7. Tasa de entrega de paquetes en las MANETs frente al número de usuarios. 93 3.8. Ad-hoc goodput frente al número de usuarios. . . . . . . . . . . . . . 94 3.9. Consumo total de la batería. . . . . . . . . . . . . . . . . . . . . . . 95 4.1. Nodos virtuales estáticos (cuadrados blancos) superpuestos a los movimientos de los vehículos (círculos negros) de una VANET. . . . . . 98 4.2. Un arreglo de regiones VN con la VNLayer. . . . . . . . . . . . . . . 99 4.3. Un arreglo de regiones VN con la VaNetLayer. . . . . . . . . . . . . 100 4.4. Regiones VN alrededor de curvas con la VNLayer y la VaNetLayer. . 100 4.5. Máquina de estados para el proceso de elección de líder en la VaNetLayer.101 4.6. Comportamiento de los backups con respecto a los líderes en la VNLayer.102 4.7. Un backup retransmitiendo un paquete perdido por el líder de su región. 102 4.8. Un paquete transmitido dos veces a una región porque un backup no pudo escuchar la retransmisión de su líder. . . . . . . . . . . . . . . . 103 4.9. Modelamiento del tránsito vehicular dentro un segmento de calle simple.104 4.10. En la aproximación de la ecuación 4.5, dos nodos no vecinos pueden intercambiar mensajes de forma segura a través de la región vacía si ellos están √más cerca que la dimensión del lado de la región multiplicada por 5; más allá de ese límite, los mensajes se pierden. . . . . . 107 4.11. Estimaciones de la sobrecarga de virtualización. . . . . . . . . . . . . 107 4.12. Estimaciones de la probabilidad de la indisponibilidad del VN. . . . . 108 4.13. VNIBR en la pila de los protocolos de comunicación. . . . . . . . . . 109 4.14. Nodos virtuales estáticos definidos por la VaNetLayer. . . . . . . . . 109 4.15. Muestra de PNs, VNs y rutas en VNIBR. . . . . . . . . . . . . . . . 110 4.16. Duración promedio de los tiempo de parada de los VNs. . . . . . . . 114 4.17. Sobrecarga de virtualización. . . . . . . . . . . . . . . . . . . . . . . 115 4.18. Duplicado de liderazgo. . . . . . . . . . . . . . . . . . . . . . . . . . 117 4.19. Rendimiento de la VNLayer y la VNLayer+ frente a la variación del número de seciones de comunicación simultáneas, con 160 PNs y 36 VNs.118 4.20. Los esquemas de encaminamiento comparados en nuestras simulaciones.120 4.21. Variación de la sobrecarga total de tráfico de control (capa de virtualización si hay + capa de red). . . . . . . . . . . . . . . . . . . . . . . 121 4.22. Variación de la tasa de entrega de paquetes. . . . . . . . . . . . . . . 122 ÍNDICE DE FIGURAS 4.23. Variación del retardo extremo a extremo. . . . . . . . . . . . . . . . . 4.24. La pila de protocolos para la comparación de la VNLayer y la VaNetLayer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.25. Comparación de las métricas de las capas de red y de virtualización de la VNLayer y la VaNetLayer. . . . . . . . . . . . . . . . . . . . . . . 4.26. Comparación de las métricas de las capas de red y de virtualización de la VNLayer y la VaNetLayer. . . . . . . . . . . . . . . . . . . . . . . 4.27. La pila de protocolos de nuestras simulaciones. . . . . . . . . . . . . 4.28. Cantidad relativa (con respecto a VNIBR) de sobrecarga de tráfico de control, tasas de entrega de paquetes y retardo extremo a extremo frente a diferentes valores de densidad de tránsito vehicular. . . . . . . . . . 5.1. Los cinco esquemas de encaminamiento usados para la aplicación de descarga y diseminación P2P. . . . . . . . . . . . . . . . . . . . . . . 5.2. Sobrecarga de tráfico de control de los cinco esquemas de encaminamiento de la figura 5.1 frente a diferentes densidades de tránsito. . . . 5.3. Tasas de entrega de paquetes de los 5 esquemas de encaminamiento de la figura 5.1 frente a diferentes densidades de tránsito. . . . . . . . . . 5.4. Tiempos promedio de descarga medidos para los 5 esquemas de encaminamiento de la figura 5.1 frente a diferentes densidades de tránsito. 5.5. La pila de protocolos de nuestra propuesta. . . . . . . . . . . . . . . . 5.6. Sobrecarga de tráfico de control de los cuatro esquemas de comunicación, frente a los diferentes niveles de swarming. . . . . . . . . . . . 5.7. Tasas de entrega de paquetes de los cuatro esquemas de comunicación, frente a diferentes niveles de swarming. . . . . . . . . . . . . . . . . 5.8. Tiempos de descarga promedio medida para los cuatro esquemas de comunicación, frente a disferentes niveles de swarming. . . . . . . . . 5.9. Variaciones de la sobrecarga de tráfico de control, las tasas de entrega de paquetes y los tiempos de descarga, frente a diferentes números de vehículos soportando cada uno el esquema de comunicación (50 % swarming). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.10. Variación de la sobrecarga de control, las tasas de entrega de paquetes y los tiempos de descarga, frente a diferente número de descargas simultáneas (50 % de swarming). . . . . . . . . . . . . . . . . . . . . XVII 124 125 127 128 130 131 138 140 141 142 144 146 147 148 151 152 6.1. La pila de protocolos de nuestra propuesta de VCN sobre la VaNetLayer.164 6.2. Principales elementos de nuestra plataforma de compartición de viajes sobre una smart VANET. . . . . . . . . . . . . . . . . . . . . . . . . 167 Índice de tablas 2.1. 2.2. 2.3. 2.4. 2.5. Tabla de encaminamiento intrazona del nodo 4_c, figura 2.5(a) . . . Tabla de encaminamiento interzona del nodo 4_c, figura 2.5(a) . . . Características de los protocolos de encaminamiento para MANETs Características de los protocolos de encaminamiento para VANETs . Características de los protocolos de encaminamiento para WMNs . . . . . . . 33 33 47 57 61 3.1. Porcentaje de tráfico entregado a los nodos a través de los enlaces MANET. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 4.1. Valores de los parámetros usados para nuestras simulaciones. . . . . . 4.2. Valores relevantes de los parámetros de simulación. . . . . . . . . . . 113 126 5.1. Valores relevantes de los parámetros de simulación. . . . . . . . . . . 5.2. Valores de los parámetros usados en nuestra simulación. . . . . . . . 5.3. Número promedio de vehículos sufriendo al menos un quiebre en la conexión TCP con diferentes cantidades de datos a descargar. . . . . . 137 145 XIX 150 Parte I Ámbito, objetivos y planteamiento de la tesis 1 Capítulo 1 Introducción El avance de los dispositivos electrónicos, las tecnologías inalámbricas y las redes de comunicación está modificando la forma en la que interaccionamos con nuestro entorno. Por una parte, la presencia de dispositivos móviles y sistemas microelectrónicos embebidos en objetos cotidianos de nuestra vida (teléfonos móviles, ordenadores portátiles, cámaras, equipos de audio y vídeo, prendas de vestir, vehículos, etc.) generan ambientes ricos en fuentes de información digitalizada, accesibles en cualquier momento y lugar. Por otra parte, la omnipresencia de Internet y el auge de las redes sociales crean nuevas formas de interacción social, rompiendo las limitaciones espacio-temporales de las relaciones cara a cara. Este entorno digital ha impulsando el desarrollo de sistemas y servicios que se adaptan de forma dinámica al contexto y las necesidades de los usuarios. Por ejemplo, en las ciudades, los Sistemas de Transporte Inteligente (ITS, del inglés Intelligent Transportation Systems) brindan servicios que mejoran la seguridad, la eficiencia y la conveniencia del transporte. Las nuevas capacidades de cómputo, procesamiento y comunicación de los vehículos permitirán a los usuarios acceder a servicios ricos en contenidos multimedia, descargar o compartir información, crear o acceder a redes sociales... Avanzando hacia la visión de ciudades inteligentes (smart cities) [205], las personas desplazándose por museos, plazas, parques y centros comerciales disfrutarán de servicios interactivos, enriqueciendo sus experiencias y/o facilitando sus tareas. Asimismo, la creciente popularidad de los teléfonos inteligentes y los nuevos patrones de interacción impulsados por la Web permitirá habilitar una nueva era de servicios de información, adaptados al contexto físico y social de las personas [228, 251]. Estos servicios, relacionados con la computación social ubicua [251], generarán muchas oportunidades para el desarrollo de significativas interacciones entre grupos cercanos, permitiendo a cada individuo sacar el máximo partido de esas personas y recursos. Desplegar estos servicios requerirá apoyarse en redes ad-hoc (sin infraestructura) tendidas entre los dispositivos móviles próximos. Sin embargo, las limitaciones de cómputo, restricciones de batería y tiempo de procesamiento de estos terminales obligarán a que muchas de las tareas que requieran QoS sean llevadas fuera de estos dispositivos hacia Internet [207]. En este punto, la computación en nube móvil [75] surge como el medio para proporcionar esta clase de servicios, trasladando las necesidades de almacenamiento y/o cómputo de los nodos hacia la nube. En lo que sigue de este capítulo, se hace una breve revisión de las tecnologías de redes inalámbricas ad-hoc multisalto, la computación en nube en ambientes móviles y la computación so3 4 Introducción cial ubicua. Estos conceptos nos darán pie para abordar el problema que se analiza en este trabajo junto con sus objetivos y las contribuciones desarrolladas. 1.1. Redes inalámbricas ad-hoc multisalto Durante las últimas décadas, las comunicaciones inalámbricas han experimentado un crecimiento explosivo, convirtiéndose en el principal soporte para proveer al usuario de capacidades de computación y acceso a la información, sin importar su ubicación [96]. Si bien, las redes inalámbricas basadas en infraestructura (sistemas celulares de tercera (3G) y cuarta generación (4G), redes Wi-Fi, WiMAX) son un gran medio para que los dispositivos móviles accedan a los servicios de red (especialmente Internet), los costes y tiempos de implementación pueden limitar su factibilidad en ambientes dinámicos, donde los usuarios requieren conexiones esporádicas, o en zonas sin una infraestructura preexistente (zonas de desastre, campos de batalla, redes vehiculares, etc.). En estos escenarios, las redes inalámbricas ad-hoc se están posicionando como una alternativa eficaz para hacer viable la entrega de los servicios de comunicaciones requeridos [51, 78]. Tres tipos de redes inalámbricas ad-hoc son de especial interés para escenarios con dispositivos móviles: las redes móviles ad-hoc (MANETs, del inglés Mobile AdHoc Networks), las redes vehiculares ad-hoc (VANETs, del inglés Vehicular Ad-Hoc Networks) y las redes inalámbricas en malla (WMNs, del inglés Wireless Mesh Networks). A continuación analizaremos sus principales características. 1.1.1. Redes móviles ad-hoc Las redes móviles ad-hoc (MANETs) son redes descentralizadas y auto-configuradas, conformadas por dispositivos móviles o semi-móviles que, aprovechando sus interfaces inalámbricas, intercambian información sin la necesidad de una infraestructura de por medio (ver figura 1.1). En su forma más simple, redes peer-to-peer, los nodos se comunican directamente con otros dispositivos dentro de su rango de cobertura, usando tecnologías como Zigbee/IEEE 802.15.4 [101], Bluetooth/IEEE 802.15.1 [103] e IEEE 802.11 [102]. Por otra parte, en la configuración multisalto, aquellos dispositivos que no están directamente conectados pueden comunicarse retransmitiendo sus paquetes a través de una secuencia de nodos que enlazan sus posiciones. Los nodos intermedios con interfaces inalámbricas (típicamente 802.11 en modo ad-hoc) cooperan para proveer las funcionalidades usuales en redes con infraestructura, actuando como routers, switches o servidores [54]. Al no existir una estructura central (como en el caso de las redes con infraestructura), la gestión y control de la red es distribuida entre todos los nodos que la conforman. La movilidad de los nodos y el medio inalámbrico generan redes variables en el tiempo, tanto en su topología como en la conectividad y calidad de los enlaces de comunicación. Las MANETs necesitan adaptarse a los patrones de movilidad de los nodos y a las condiciones de propagación del medio inalámbrico. Por una parte, los nodos dinámicamente establecen rutas entre ellos a medida que se mueven, formando sus propias redes sobre la marcha. Por otra, la naturaleza inalámbrica del medio de comunicación, sujeta a ruido, desvanecimiento e interferencia, y a las característi- 1.1 Redes inalámbricas ad-hoc multisalto Enlace inalámbrico 5 Nodo Radio de cobertura Figura 1.1: Representación de una red móvil ad-hoc (MANET). cas multisalto de los trayectos de comunicación hacen que las múltiples conexiones inalámbricas sean heterogéneas, generando fluctuaciones en las capacidades de los enlaces de comunicación [165]. Asimismo, los dispositivos móviles que conforman estas redes, en su mayoría, tienen limitaciones de procesamiento, almacenamiento y de batería, lo que hace necesario el desarrollo de algoritmos y mecanismos que optimicen los recursos existentes para proveer las funcionalidades requeridas. Entre las aplicaciones típicas de las MANETs se cuentan las siguientes: Aplicaciones militares. En la década de los 70, las MANETs fueron inicialmente desarrolladas para dar soporte a las necesidades de comunicación y coordinación de soldados y puestos de mandos fijos o itinerantes en los campos de batalla. Al día de hoy, las MANETS están participando en la generación de redes de comunicaciones desplegadas en los campos de batallas que conectan a soldados, vehículos, drones e incluso sensores ubicados en diferentes dispositivos (minas, cascos, prendas de vestir, etc.), dando a los combatientes la capacidad de aprovechar la información disponible en todo momento y obtener una ventaja decisiva frente a sus enemigos [49,50,111]. De igual forma, estas redes están permitiendo la coordinación de dispositivos y vehículos autónomos desplegados en las zonas de conflicto [148, 198, 220]. Situaciones de emergencia. Otro escenario de aplicación de las MANETs son las operaciones de rescate en situaciones de emergencia. En escenarios como incendios, inundaciones, terremotos,... donde la infraestructura de telecomunicaciones está dañada o es inexistente, el rápido despliegue de las redes móviles ad-hoc brinda el soporte necesario para coordinar las acciones y servicios del personal de socorro [160] o para desplegar en las zonas de riesgo dispositivos auto-organizados como vehículos aéreos no tripulados (UAVs, del inglés Unmanned Aerial Vehicles) o robots autónomos para obtener información que permita a los socorristas identificar y contener el peligro, y coordinar el rescate de las víctimas [196, 197, 215]. 6 Introducción Redes de área local y personal. En escenarios como aulas, estadios deportivos, aviones, las redes móviles ad-hoc son una solución adecuada para implementar redes temporales entre los dispositivos de los usuarios (ordenadores portátiles, teléfonos inteligentes, cámaras digitales) que permitan difundir o intercambiar información [167, 221]. De igual forma, las redes domésticas (home networks) son un ambiente propicio para el desarrollo de aplicaciones basadas en la comunicación directa de los dispositivos para el intercambio de información [218]. Computación ubicua. Las MANETs surgen como una de las principales tecnologías habilitantes para el desarrollo de una computación integrada en nuestro entorno [72, 121]. Información accesible de forma transparente y objetos que se ajustan en función de las condiciones del ambiente y las necesidades de los usuarios son dos de los principales objetivos de la computación ubicua. Aquí se incluyen aplicaciones relacionadas con el cuidado de ancianos [66, 166], monitorización del estado de salud de enfermos [105,181], casas y edificios inteligentes [125, 158], entre otras. 1.1.2. Redes vehiculares ad-hoc En los últimos años, los vehículos están experimentando un gran desarrollo tecnológico. Computadoras a bordo les permiten procesar datos generados en sus subsistemas y en otros dispositivos embebidos (sensores de temperatura, luz y lluvia, radares de colisión de corto alcance, cámaras, etc.). Equipos de radio habilitan el intercambio de datos con otros vehículos usando estándares como IEEE 802.11p —algunas entidades reguladoras alrededor del mundo ya han asignado bandas específicas del espectro radioeléctrico, en principio, para uso de aplicaciones relacionadas con la seguridad en las vías [134]. De igual forma, un creciente número de fabricantes están trabajando para que los teléfonos inteligentes (smartphones) y tabletas (tablets) se conviertan en una extensión de los equipos del vehículo, brindando, adicionalmente, dispositivos GPS, pantallas táctiles, tarjetas de memoria y más facilidades de comunicación (al menos, Bluethooth, Wi-Fi y 3G/4G) [15]. Este escenario tecnológico ha impulsado la investigación en el área de los Sistemas de Transporte Inteligente, con una variedad de enfoques para que los vehículos intercambien datos en redes ad-hoc (Vehículo a Vehículo, V2V) y con servidores en Internet a través de comunicaciones Wi-Fi con puntos de acceso ubicados junto a las calles o con redes celulares (Vehículo a Infraestructura, V2I) [244] (ver figura 1.2). Si bien las VANETs son una clase de red inalámbrica ad-hoc, sus particulares características las diferencian de otras redes de este tipo. En primera instancia, los nodos 1 presentan una mayor movilidad que en las redes MANETs; pero además, a diferencia de estas últimas cuyo movimiento es aleatorio, el desplazamiento de los vehículos está condicionado por factores como el trazado de las calles, las normas y señales de tránsito y los semáforos ubicados en las vías. Estas restricciones de movimiento junto con la variabilidad en la densidad vehicular hacen que estas redes presenten rápidos cambios en su topología y frecuentes fragmentaciones (presencia de grupos de nodos inconexos) [239]. Por otra parte, a diferencia de los dispositivos usados en las MANETs, los vehículos no tienen limitaciones en su capacidad de cómputo, almacenamiento o energía. Típicamente, las aplicaciones en redes VANETs pueden ser agrupadas en: 1 En este trabajo, los términos nodo y vehículo son usados indistintamente. 1.1 Redes inalámbricas ad-hoc multisalto 7 Enlace inalámbrico Radio de cobertura Figura 1.2: Representación de una red vehicular ad-hoc (VANET). Aplicaciones orientadas a la seguridad. Buscan mejorar la seguridad de los conductores, pasajeros y peatones, evitando accidentes en la calles y carreteras, o ayudando a la acción efectiva de los grupos de socorro. Estas aplicaciones cubren aspectos como la asistencia a conductores en la vía, soporte de equipos de emergencia, diseminación de mensajes de alarma por accidentes y condiciones de tránsito, diagnóstico remoto de los vehículos, etc. [11, 59, 94, 130, 151, 193]. Aplicaciones orientadas a la información y el entretenimiento. Estas aplicaciones buscan mejorar la eficiencia del tránsito, el confort y entretenimiento de los pasajeros, y el despliegue de servicios de comercio electrónico. Esto incluye la provisión de información del clima y las condiciones de tránsito, basada en datos recolectados desde sensores colocados en la infraestructura o desde los mismos vehículos [68, 154, 164, 169, 186, 243, 246]; el acceso a información generada localmente (localización de restaurantes, estacionamientos, locales comerciales, museos, etc.) [43, 48, 117]; soporte a la compartición y distribución de contenidos generados por los usuarios o accesibles a través de Internet [46, 85, 127, 131, 139]; interacción con pasajeros o conductores a su alrededor para conversaciones, juegos, o acceso a redes sociales formadas sobre la marcha [12, 84, 212, 223, 245]; recepción de campañas publicitarias y acceso a comercio electrónico en la vía [226], entre otras. 1.1.3. Redes inalámbricas en malla Las redes inalámbricas en malla (WMNs) se están convirtiendo en una de las principales tecnologías para dar acceso ubicuo a Internet de banda ancha [195]. Estas redes son una combinación de nodos móviles y fijos que se organizan y configuran por sí mismo para establecer una red ad-hoc y mantener la conectividad de la malla. Estos nodos, al igual que en las MANETs y VANETs, tienen la capacidad de retransmitir los paquetes de datos en modo multisalto, para enlazar fuente y destino. Dos tipos de 8 Introducción nodos conforman estas redes: los routers mesh y clientes mesh. Los routers mesh, a más de las funcionalidades de los routers inalámbricos tradicionales, poseen características adicionales (por ejemplo, interfaces inalámbricas multi-radio) para soportar el encaminamiento en una estructura en malla y permitir la integración de la WMN con otras redes tales como Internet, redes celulares, Wi-Fi, WiMAX, etc. Salida a Internet Router mesh con pasarela Router mesh Router mesh Router mesh Router mesh Router mesh Clientes mesh Punto de Acceso Malla de clientes Clientes mesh Conexión cableada Conexión inalámbrica Figura 1.3: Representación de una red WMN. En función de su arquitectura y la configuración de despliegue, podemos identificar tres tipos de WMNs [10]: red con infraestructura, red de clientes y red híbrida. En la red en malla con infraestructura, los routers mesh, de movilidad limitada o nula, colectivamente conforman la estructura troncal de la red (backbone). Los nodos clientes mesh acceden a la red directamente a través de los routers mesh, ellos no colaboran en la infraestructura de la red. En la configuración de malla de clientes, la red actúa de forma similar a una red ad-hoc pura. No existe una infraestructura de red por lo que los nodos deben realizar funciones de encaminamiento y retransmisión de paquetes. La combinación de los dos conceptos anteriores genera una red híbrida (ver figura 1.3). Como posibles aplicaciones de esta clase de redes, tenemos las siguientes: Redes comunitarias. Estas aplicaciones están enfocadas al acceso a Internet de un grupo de usuarios que comparten el mismo enlace [20]. Basadas principalmente en Wi-Fi, soportan aplicaciones tales como compartición de archivos, acceso a Internet de alta velocidad, voz sobre IP, entre otras [77]. Además, WMN es una excelente opción para proveer de estos servicios a zonas rurales [104]. Redes metropolitanas. WMN se está consolidando como una tecnología de bajo coste para extender el acceso a Internet en áreas metropolitanas. Numerosos 1.2 Computación en nube en ambientes móviles 9 municipios y entidades gubernamentales en muchos lugares del mundo están desplegando estas redes [23, 153, 168]. Sistemas de transporte inteligente. Las WMNs pueden ser una solución económica para la implementación de algunos de los servicios de los Sistemas de Transporte Inteligentes. Por ejemplo, el despliegue de sistemas de recolección de información sobre el transporte público o de las condiciones de tránsito en tiempo real, mejorando la información provista a los usuarios [8, 42]. 1.2. Computación en nube en ambientes móviles La computación en nube (en adelante, CC del inglés Cloud Computing) se basa en la entrega de recursos de computación como un servicio, mediante el cual un conjunto de recursos compartidos (redes, servidores, capacidad de almacenamiento, aplicaciones y servicios) son proporcionados como un servicio sobre una red (típicamente Internet). Esta novedosa propuesta permite dar la ilusión a los usuarios de poseer un conjunto ilimitado de recursos, los cuales pueden ser ajustados dinámicamente en función de sus necesidades. La idea de que las empresas puedan invertir en alquilar, más que en adquirir infraestructura de telecomunicaciones, ha hecho que CC sea adoptado por un gran número de proveedores y clientes en el mundo [178]. Tres modelos de servicios han sido definidos [161]: Infraestructura como un Servicio (IaaS). El proveedor ofrece a sus clientes recursos de procesamiento, almacenamiento y redes, entre otras. Software como un Servicio (SaaS). El cliente usa aplicaciones del proveedor que se están ejecutando en la infraestructura disponible en la nube. En este tipo de servicio, la aplicación es accesible desde algún dispositivo e interfaz de cliente. Plataforma como un Servicio (PaaS). En este servicio, el cliente tiene acceso a plataformas de desarrollo alojadas en la nube, desde las cuales puede implementar y desplegar sus aplicaciones. Esta visión de aprovechar el exceso de recursos de unos para soportar las necesidades de otros, se está posicionando en los entornos inalámbricos como un factor clave para que los dispositivos móviles —con sus limitaciones en recursos de procesamiento, almacenamiento y computación— puedan acceder a servicios más demandantes (procesamiento de imágenes, compartir datos GPS/Internet, aplicaciones de sensores de datos, búsqueda e intercambio de archivos multimedia, aplicaciones generadas desde el uso de redes sociales, entre otras) [75]. La computación en nube móvil (MCC del inglés, Mobile Cloud Computing) tiene por objeto permitir el procesamiento de una gran cantidad de datos, bajo demanda, en cualquier momento y lugar, de forma tal que los dispositivos móviles conectados a Internet usen un ambiente que integre diversas plataformas y tecnologías [76]. En su visión clásica, MCC traslada la capacidad de cómputo y el almacenamiento de datos fuera de los dispositivos móviles hacia la nube, trayendo de esta manera los modelos de servicios de la CC (SaaS, PaaS, IaaS) y la computación móvil a un amplio rango de usuarios en movimiento. Otra aproximación de MCC considera a los dispositivos móviles como potenciales proveedores de recursos [99,157]. Esta propuesta requiere extender la visión tradicional 10 Introducción de MCC orientada a una conexión permanente y estable a Internet, a una nueva en la que los recursos de la nube, por lo menos parcialmente, son provistos por los propios dispositivos móviles. Este enfoque brinda una oportunidad para que los dispositivos conectados en una red ad-hoc puedan compartir sus recursos individuales (capacidad de cómputo, almacenamiento, monitorización, conexiones a Internet, etc.) —a menudo subutilizados— para generar una infraestructura distribuida que dé soporte a nuevos servicios y aplicaciones [76]. Esta visión de MCC no es ajena a las redes vehiculares. Como se analizó en la sección 1.1.2, el avance tecnológico de los vehículos modernos, con sistemas de computación, comunicación y monitorización integrados, está llevando a que los investigadores y la industria de la automoción en general planteen el desarrollo de nuevas aplicaciones y servicios orientados al confort y el entretenimiento de conductores y pasajeros. Con miras en este objetivo, la computación en nube vehicular (VCC, del inglés Vehicular Cloud Computing) ha sido propuesta como el mecanismo para desarrollar, desplegar y ejecutar los servicios previamente mencionados, aprovechando, de forma transparente, los recursos contribuidos por grupos de vehículos y provocando con ello una evolución similar al del paso de las aplicaciones cliente-servidor en Internet a la clásica computación en nube [1, 73]. El objetivo de VCC es explotar los recursos disponibles, tanto en las unidades de datos ubicados en redes externas (al estilo de CC y la visión clásica de MCC) como los recursos presentes en los propios vehículos, para brindar servicios más demandantes. A más de los conocidos modelos de servicio de CC (Iaas, PaaS y Saas) considerados en numerosos escenarios [73, 237], nuevos modelos han sido definidos para promover la explotación de los recursos disponibles en los vehículos y que son subutilizados por sus propietarios [237]: La Red como un Servicio (NaaS). Los usuarios con acceso a Internet pueden ofrecer el exceso de capacidad de su conexión como un servicio para otros usuarios que requieran dicha conectividad mientras se desplazan. Almacenamiento como un Servicio (SaaS). Muchos usuarios con una capacidad de almacenamiento mayor que sus requerimientos ofrecen este exceso como un servicio. Cooperación como un Servicio (COaaS). La colaboración es ofrecida como un recurso para que otros usuarios puedan acceder a servicios en la red y de los cuales el cooperante es parte. En esta modalidad, el nuevo usuario anuncia sus preferencias para un servicio o conjunto de servicios en la red, mientras que los vehículos subscritos cooperan para brindarle la información necesaria sobre ese servicio y sobre los anuncios de la red. Computación como un Servicio (CaaS). La capacidad de computación y almacenamiento de los vehículos que están estacionados por un periodo de tiempo en un aparcamiento —generalmente no utilizada— es aprovechada para ofrecerla como un servicio para aquellos que la requieran. Fotos como un Servicio (PaaS). Los recursos de las cámaras de fotografía o vídeo embebidos en los vehículos son ofrecidos como un servicio para aplicaciones de monitorización —expandiendo su alcance más allá de la ubicación de sus sensores estáticos— o para la captura de fotos y/o vídeos de accidentes para propósitos de reclamaciones judiciales o de seguros. 1.3 Computación social ubicua 11 Información como un Servicio (INaaS) y Entretenimiento como un Servicio (ENaaS). En INaaS, la información relacionada con la seguridad de conductores y pasajeros (condiciones del tránsito, avisos de alerta, accidentes, emergencias, etc.) son ofrecidas en su conjunto como un nuevo servicio de información; mientras que en ENaaS, aprovechando la presencia de pantallas táctiles y de vídeo en las cabinas de los modernos vehículos, nuevos servicios de confort y entretenimiento (anuncios de publicidad, películas, compras, etc.) podrán ser ofrecidos a los pasajeros, haciendo más amenos sus trayectos. No obstante el creciente interés acerca de VCC, los trabajos publicados hasta ahora se han enfocado en escenarios que omiten muchos de los retos técnicos derivados de la movilidad de los nodos: vehículos estacionados en aparcamientos de aeropuertos o centros comerciales [17], vehículos circulando lentamente en atascos [229] o grupos de vehículos desplazándose por las carreteras con muy pocos movimientos relativos entre ellos [27], dan cuenta de una parte muy pequeña del alcance de VCC, puesto que el funcionamiento de estas propuestas depende de ambientes bastante estables para las comunicaciones V2V. Se necesita, por tanto, establecer mecanismos que permitan desplegar la VCC en ambientes con condiciones desfavorables, más pertinentes a las VANETs, con flujos de tráfico irregulares y a ráfagas, con vehículos moviéndose de forma no restringida y con abundantes pérdidas de paquetes debido al ruido, reflexiones y obstáculos. 1.3. Computación social ubicua En 1991, Mark Weiser presentó su visión de la computación ubicua [236], la cual en esencia describía un ambiente saturado de capacidades de computación y comunicación que se integran en el entorno y que interaccionan con el individuo, mientras se desplaza dentro de ese ambiente. Los dispositivos presentes en ese espacio se conectan y coordinan entre ellos y con redes de servicios a través de sistemas de comunicación inalámbrica, con el objetivo de proveer al usuario acceso a información y servicios y/o asistirle en la ejecución de sus tareas [21]. Este tipo de ambientes, denominados también en la literatura como espacios o ambientes inteligentes [57, 137], está cambiando la forma en la que las personas percibimos e interaccionamos con el entorno, incorporándose en todas las situaciones de nuestra vida. Por ejemplo, numerosos dispositivos están empezando a ser embebidos en prendas de vestir o, en muchos casos, ser introducidos en nuestro cuerpo a través de implantes bajo la piel. Estos dispositivos, con capacidades de computación, monitorización y comunicación tienen la posibilidad de interaccionar con sistemas de comunicación y redes de servicio para controlar y mejorar aspectos de nuestra salud [2]. Por otra parte, la extensión de la idea de computación ubica hacia las áreas residenciales y de trabajo está llevando al desarrollo de conceptos como casas inteligentes [72, 162], edificios inteligentes [158] y oficinas inteligentes [125] cuya finalidad es la de facilitar las condiciones de vida y de trabajo de los habitantes de esos entornos, reaccionando y ajustando automáticamente parámetros como temperatura, luminosidad, intensidad del sonido... De igual forma, pero a una mayor escala, la idea de contar con un entorno inteligente que facilite las tareas cotidianas de las personas, nos lleva al concepto —desde el punto de vista tecnológico— de ciudades inteligentes [205]. La infraestructura de comunicación, sensores y dispositivos a lo largo de estas ciudades coadyuvan 12 Introducción en el mejoramiento de las condiciones de salud, seguridad, confort, ocio y, en general, en la ejecución de las actividades de los ciudadanos. Por ejemplo, como se analizó en la sección 1.1.2, el desarrollo tecnológico de los equipos embebidos en los vehículos modernos y el despliegue de los ITSs están llevando a la generación de numerosas aplicaciones que están beneficiando considerablemente la eficiencia, seguridad y confort en el transporte. Al igual que el desarrollo de la computación ubicua está transformando la forma en la que las personas perciben e interaccionan con su entorno, el creciente interés de los usuarios por las redes sociales como Facebook, Twitter, Instagram, Foursquare y LinkedIN está brindando nuevas formas de interacción social a través de la Web, evitando la necesidad de una cercanía física y, por tanto, rompiendo las limitaciones espaciotemporales. La computación ubicua y las redes sociales, unidas a las capacidades de procesamiento de las técnicas de gestión del conocimiento (minería de datos, filtrado colaborativo y basado en contenido, entre otros) y el emergente soporte de la computación en nube están llevando a la academia y a la industria a proponer y desplegar una amplia variedad de sistemas de computación ubicuos que reaccionan y actúan de forma automática, de acuerdo al contexto social, la situación y a las necesidades del usuario [58, 121, 181, 199, 201]. Estos sistemas ubicuos socialmente adaptativos tienen en el conocimiento generado desde las redes sociales el punto clave para su desarrollo [26,251]. En una red social, las entidades (individuos, organizaciones y sistemas) se encuentran enlazadas a través de una o más interdependencias (amistad, intereses comunes, creencias, conocimiento, entre otras) [115]; las relaciones que se generan entre estas entidades sirve para gradualmente construir bases de conocimiento, útiles, en muchos casos, para mejorar los servicios de comunicación. Por ejemplo, el análisis de las relaciones generadas entre individuos al intercambiar piezas de información en la red (e.g., comentarios, documentos, imágenes, etc.), permite mejorar o adicionar características a las aplicaciones y servicios, para hacer recomendaciones de contenidos potencialmente interesantes para cada persona [124, 135], lanzar campañas de publicidad específicas para grupos o segmentos de la población [29], identificar afinidades entre personas o sinergias entre diferentes áreas de actividad [47, 232], entre otras. Este concepto, explotado de forma amplia en el ámbito de los servicios de comunicación basados en Internet y los ordenadores está surgiendo en el ámbito de las comunicaciones inalámbricas y móviles. La incursión de las redes sociales móviles (MSNs, del inglés Mobile Social Networks) está permitiendo que las capacidades de interacción y de servicio de las redes sociales estén disponibles en cualquier lugar y tiempo. Las MSNs, como servicios basados en redes sociales y soportados por sistemas de comunicación móvil, involucran el aprovechamiento de la información de conectividad de las redes sociales y la movilidad de los usuarios para generar oportunidades de interacción [147]. No obstante la penetración de las redes sociales, es evidente que las interacciones que ellas habilitan están ampliamente confinadas al mundo virtual de Internet; ellas no están acompañadas por una interacción cara a cara, excepto en el caso en el que la gente acuerda un encuentro físico por trabajo o entretenimiento. Más aún, es notable que las interacciones de los individuos están cada vez más enfocadas a un conjunto de personas dentro de su grafo social, las cuales son accesibles en algún momento. De esta forma, el individuo queda atrapado en una burbuja de comunicación formada por sus contactos. Esta situación, conduce a que los sistemas y servicios de comunicación no puedan aprovechar el potencial conocimiento de los individuos (extraños o no) presentes en el entorno —por ejemplo, personas extrañas pero con intereses potencialmente 1.4 Problema a resolver 13 afines que coinciden en lugares como museos, teatros, salas de conciertos y estadios deportivos, entre otros. Se requiere, por tanto, de plataformas que soporten la generación de sistemas ubicuos que aprovechen el conocimiento y las interacciones sociales que se pueden generar entre personas cercanas (conocidas o no), con la finalidad de soportar adaptativamente las necesidades de los usuarios presentes en su entorno. 1.4. Problema a resolver La alta complejidad de los servicios de comunicación ubicuos genera muchos retos de investigación. Desde un punto de vista tecnológico, brindar los servicios de comunicación mencionados en las secciones anteriores requiere aprovechar las capacidades de comunicación y computación de los dispositivos para conformar redes conectadas e integradas. En ese sentido, como se analizó en la sección 1.1, las redes inalámbricas ad-hoc multisalto se están posicionando como elementos clave a la hora de brindar servicios en entornos ubicuos [55, 195, 218]. Su importancia radica en la flexibilidad y dinamismo con la que estas redes pueden soportar servicios de comunicación sin la necesidad de una infraestructura de por medio. A nivel más bajo, debido a la proximidad física, los nodos deben ser capaces de intercambiar paquetes de datos directamente o en pocos saltos a través de la red adhoc y aprovechar las potencialidades del peer to peer (P2P) y de las redes oportunistas [55, 218]. De igual forma, las redes ad-hoc deben servir como canal para distribuir contenidos generados localmente o descargados de Internet a través de cualquier Wi-Fi, DSRC, WiMAX, 3G o conexiones LTE disponibles para los dispositivos móviles. Para esto, es necesario hacer frente a los problemas planteados por las propiedades del medio inalámbrico —ruido, interferencia, desvanecimiento, etc.—, la movilidad de los nodos —dependiendo del contexto, vehicular o pedestre, la topología variará en mayor o menor medida— y la heterogeneidad de los dispositivos de usuario —en escenarios pedestres, los dispositivos pueden tener limitada memoria, capacidad de cálculo y de batería; lo que no ocurre con las redes vehiculares. Por encima de las comunicaciones ad-hoc, se debe definir mecanismos para que los nodos móviles puedan recurrir a la infraestructura de telecomunicaciones, mediante conexiones habilitadas por otros usuarios en su entorno, para solventar sus restricciones y/o aprovechar los recursos disponibles —y por lo general subutilizados— de los dispositivos móviles. En el ámbito de acceso al contenido, se necesita explotar conceptos como Web Semántica, minería de datos y sistemas recomendadores con el fin último de conseguir una personalización de la información ofrecida por cada dispositivo, sea dirigido a una sola persona (como típicamente sucede con los teléfonos móviles) o a varias (como podrían ser los ocupantes de un vehículo). En el contexto de estos retos, en esta investigación nos centramos en los problemas generados en las comunicaciones ad-hoc a partir de la movilidad de los nodos — ruptura frecuente de los trayectos de comunicación, sobrecarga de tráfico de control en la red para enfrentar la variabilidad de la topología y la presencia de redes inconexas por largos periodos de tiempo debido a las fluctuaciones de la densidad de nodos en la red [83]— y en la necesidad de proporcionar mecanismos para estructurar redes inalámbricas ad-hoc más estables, que den soporte a las aplicaciones y servicios en entornos ubicuos. 14 Introducción Estos problemas han sido abordados de manera amplia en la literatura a través de mecanismos de encaminamiento que hacen uso de patrones de movilidad para anticiparse a los quiebres de enlace, direcciones de encaminamiento basadas en la localización de los nodos o la conformación de estructuras jerárquicas entre dispositivos móviles con determinadas características [10, 13, 71, 128]. Otra propuesta para hacer frente a los retos derivados de la movilidad es la virtualización. Shlomi Dolev et al. [67] introdujeron el concepto de capa de nodos virtuales (VNLayer, del inglés Virtual Node Layer), el cual define procedimientos para que los nodos físicos colaborativamente emulen nodos virtuales que pueden ser considerados como servidores virtuales ubicados en lugares conocidos. Este concepto ha probado facilitar el diseño y operación de servicios de comunicación, dado que se pueden desplegar aplicaciones sobre dispositivos móviles y servidores virtuales sin tener que hacer frente a los retos derivados de la movilidad [41]. Además, la virtualización crea un nivel jerárquico que trae nuevas oportunidades de rediseñar los protocolos desarrollados para redes MANET planas de manera tal que operen de forma más eficiente y fiable [240]. Esta visión, probada únicamente en ambientes MANET, nos ha llevado a la pregunta de si la virtualización puede también producir mejores comunicaciones en un campo más específico como el de las VANETs. Es más, nuestro interés se centra en analizar las posibilidades de la virtualización para brindar servicios de comunicación en ambientes pedestres, vehiculares y mixtos. Esta tesis se enmarca dentro de los trabajos desarrollados para la generación de infraestructuras de redes para la provisión de servicios ubicuos y confiables que concentra actualmente los esfuerzos de investigación del Grupo de Servicios para la Sociedad de la Información del Departamento de Ingeniería Telemática de la Universidad de Vigo y, específicamente, en el diseño e implementación de la plataforma SPORANGIUM. 1.5. La plataforma SPORANGIUM SPORANGIUM (del inglés «SPORadic social networks in the Next-Generation Information services for Users on the Move») es una plataforma que busca facilitar la creación y explotación de redes sociales esporádicas (de corta duración), comunicando a cada individuo con la gente a su alrededor en un determinado momento —conocidos o no— y considerando la información que puede ser relevante para ellos en diferentes contextos y niveles (edificios, calles, ciudades, etc.). El objetivo es que los individuos puedan aprovechar lo mejor de su entorno en todo momento. Esta propuesta es aplicable en varias áreas, que van desde la formación de grupos y la orquestación de actividades en torno a eventos o lugares que atraen a gente con intereses relacionados potencialmente (museos, parques o salas de conciertos), a la generación de oportunidades de mejora de las comunicaciones y el acceso a información relevante en las calles (servicios de información avanzada en redes vehiculares) o avances en la visión de las ciudades inteligentes (relacionadas con las planificación de la movilidad personal o la celebración de juegos urbanos basados en localización). Esta plataforma está siendo desarrollada como una extensión de las tecnologías ya disponibles en los dispositivos de los usuarios, para incorporar las redes sociales esporádicas (SSN, del inglés Sporadic Social Networks) y los mecanismos que las hacen posible en el contexto tecnológico de la conocida Web 2.0. De forma conceptual, su arquitectura tiene cuatro niveles, como se muestra en la figura 1.4: comunicaciones ad- 1.5 La plataforma SPORANGIUM 15 hoc, computación en nube móvil, gestión del conocimiento y el bloque de construcción de aplicaciones. · Texto/voz/interacciones gestuales · Realidad Aumentada · Imágenes panorámicas de 360 grados · Muestras de audio/vídeo · ... Bloque de construcción de aplicaciones · Perfiles de usuarios · Minería de datos · Filtrado colaborativo y basado en contenido · Identificación y gestión del contexto · Métricas de aptitud, conveniencia y afinidad · ... Gestión del conocimiento · Almacenamiento (semi-)permanente en espacios de la nube · Sincronización de flujos de información · Organización de juegos en vivo · Fusión de los datos obtenidos desde diferentes sensores en la red · Asignación de tareas sobre los recursos de computación · Diferenciación de servicios · ... Computación en nube móvil · Gestión de la movilidad · Encaminamiento · Virtualización · ... Comunicaciones ad-hoc Figura 1.4: Arquitectura conceptual de la plataforma SPORANGIUM. Las redes sociales esporádicas, y en general las comunicaciones en ausencia de infraestructura, se basan, en primera instancia, en redes ad-hoc establecidas dinámicamente entre los dispositivos móviles de las personas quienes resultan estar cerca unas de otras en un momento dado. Con las bases adecuadas, las redes ad-hoc serán, sin duda, la forma más natural y eficaz para el intercambio de información entre ellas, en vez de enviar los paquetes de datos a servidores que pueden estar muy lejos solo para que hagan eco de esos mismos paquetes en el enlace descendente. A este respecto, SPORANGIUM proporciona los mecanismos para establecer conexiones de forma proactiva y transparente para los usuarios, siempre que sea considerado apropiado desde los niveles más altos de la arquitectura. Así, en la capa de Comunicaciones Ad-Hoc, esta plataforma incorpora los constructos de virtualización propuestos en [241] y refinados en esta tesis para usar las redes ad-hoc como canales fiables y como repositorios de información disponible para los miembros de la SSN. La virtualización provee mecanismos escalables, por medio de los cuales los dispositivos móviles pueden colaborar para soportar comunicaciones desde, hacia y a través de ellos, directamente o en forma de saltos múltiples, incluso con la capacidad de diferenciar una gama de demandas de QoS [172]. Siempre que las redes ad-hoc no sean estables o suficientemente fiables, la capa de Computación en Nube Móvil puede usar la infraestructura accesible a través de conexiones 2G/3G/4G o puntos de acceso Wi-Fi para mantener la conectividad tanto como sea posible y almacenar información temporalmente durante los periodos de descone- 16 Introducción xión. A diferencia de la visión clásica de la computación en nube móvil, enfocada en individuos que no podrían hacer prácticamente nada sin acceso a Internet (ver [75]), el objetivo de la capa de computación en nube móvil de SPORANGIUM es habilitar servicios de valor añadido para grupos de personas que ya están en el nivel de comunicaciones ad-hoc, aprovechando los recursos disponibles para cada uno de ellos a través de sus dispositivos móviles. Hay muchas funcionalidades que se pueden ofrecer sin acceso a Internet, las cuales pueden ser explotadas (y compartidas), siempre que sea posible, para brindar otras más avanzadas y contenidos más abundantes. Siguiendo esta filosofía (la cual es explícita en el diagrama de la figura 1.5) la capa de computación en nube móvil de SPORANGIUM provee los siguientes servicios, con solo el último y penúltimo dependientes de la conectividad en redes externas a la red ad-hoc: Almacenamiento de información en espacios en la nube (dentro de la red adhoc), vinculado a los dispositivos fuente o destino, a los usuarios creadores o consumidores, a la ubicación, entre otros. Acceso y uso de la información de alto nivel de los perfiles de los usuarios durante la creación de las redes ad-hoc para la formación de redes sociales esporádicas entre usuarios afines (en base a las preferencias o intereses particulares). Sincronización de los múltiples flujos de información provenientes de la contribución de diferentes usuarios. Supervisión y cumplimiento de las contribuciones de los múltiples usuarios para soportar el desarrollo de juegos en vivo (diferentes roles, toma de decisiones, etc.). Puesta en común de los datos de varios sensores sobre múltiples dispositivos para lograr una mayor precisión en la geolocalización. Delegación de tareas complejas en máquinas remotas, para superar las limitaciones de los dispositivos móviles en términos de batería, memoria y/o potencia de cálculo. Provisión de acceso a los servicios en nube sobre Internet: mapas, bases de datos, repositorios semánticos, etc. En la parte superior de la arquitectura, la capa de Gestión del Conocimiento es el lugar para automatizar la selección de las piezas de información para el mayor beneficio de los miembros de la SSN, mientras se personalizan los contenidos entregados a cada dispositivo. En el último nivel de la arquitectura, el Bloque de Construcción de Aplicaciones, de forma conceptual contiene los componentes de software que proporcionan servicios de valor añadido a los miembros de la SSN, además de las interfaces que ayudan a la mayoría de esas nuevas características: realidad aumentada, fotos panorámicas de 360 grados, interacciones gestuales, etc. En lo que queda de esta sección, se describe algunas de las características que pueden ser habilitadas por la visión de las redes sociales esporádicas en diferentes escenarios de aplicación. 1.5 La plataforma SPORANGIUM 17 Figura 1.5: Visión combinada de las redes ad-hoc y la computación móvil en nube. 1.5.1. SPORANGIUM: aplicación en lugares de encuentro El uso de la plataforma SPORANGIUM en puntos de encuentro tiene que ver con la formación de grupos, la orquestación de actividades, la sincronización de múltiples flujos de información y el uso colectivo de los dispositivos en manos de los diferentes individuos. Museos, salas de conciertos, campamentos, guarderías, estadios,... son todos lugares donde muchas personas coinciden y, a pesar de que pueden no conocerse entre sí, es probable que tengan intereses comunes (por ejemplo, en historia o ciencias, en un cierto tipo de música, en la naturaleza, en cosas de niños, en deportes, etc.). Para lo que sigue, nos centraremos en las características activadas por la SSN en museos, esto nos permite proponer ideas que pueden ser fácilmente extrapolables a otros tipos de lugares de reuniones. La gente va a los museos durante su tiempo libre a propósito de aprender sobre un tema específico, lo cual hace que estos lugares sean propicios para ir más allá del uso individual de los dispositivos móviles, promovidos por muchos trabajos previos que proporcionaban itinerarios personalizados dentro de los edificios, continuidad de experiencias de una visita a otra, etc. [233] Con la correspondiente aplicación de la SSN, un visitante del museo estaría listo para empezar a interaccionar con la gente fuera de sus contactos cotidianos al entrar en el edificio. Para empezar, el usuario puede navegar por un tablón de anuncios virtual que contiene una selección de los mensajes publicados en Twitter por otros visitantes actuales con perfiles similares. Opiniones cortas y fotos de áreas para visitar, rankings de las mejores actividades y exposiciones, ... pueden ser un buen punto de partida para que los recién llegados puedan conocer el 18 Introducción lugar y gente nueva, sin necesidad de haber navegado alguna vez por sus perfiles de Twitter y, por supuesto, sin necesidad de haber establecido previamente relaciones de seguimiento. La plataforma también puede tomar la iniciativa de reunir a grupos de visitantes para participar en las visitas guiadas en el interior del museo, teniendo en cuenta parámetros tales como el idioma, el país/provincia de origen, sexo y edad. Después de haber identificado un número de visitantes para la tarea, sus dispositivos móviles podrían utilizarse para ponerse de acuerdo sobre la hora, la duración y el tema del tour en estrecha interacción con el personal del museo. Entonces, cuando la visita se está ejecutando, los dispositivos móviles de los visitantes y el guía podrían estar contribuyendo contenidos (comentarios de texto, imágenes, audio grabado, etc.) a un espacio en la nube, para ser de acceso compartido para otros usuarios de acuerdo a los criterios establecidos por el titular de cada dispositivo: «este comentario está abierto a todos para lectura», «esta imagen puede ser solo vista por las personas que aparecen en ella»,... Los contenidos procedentes de múltiples dispositivos en una SSN pueden ser automáticamente, anotados y sincronizados en la capa de Computación en Nube Móvil para permitir el acceso a ellos de diferentes maneras. Por ejemplo, se pueden visualizar en una línea de tiempo virtual que el usuario puede desplazar para recordar lo que el guía había dicho minutos antes, para comparar una imagen en la pantalla con otra en la sala anterior, etc. También se pueden mostrar en un mapa deslizable o como elementos de realidad aumentada superpuestas en la salida en vivo de una cámara. 1.5.2. SPORANGIUM: aplicación en redes sociales vehiculares La aplicación de SPORANGIUM en entornos vehiculares fue motivado por algunas de las visiones presentadas en [84] sobre el futuro del Internet móvil, que son en gran parte compartidas por los investigadores, los fabricantes de automóviles y las autoridades de transporte. Se demostró en [140] que, debido a la longitud y la regularidad de los viajes de las personas en los coches privados y/o en el transporte público, los encuentros entre vehículos exhiben una estructura y un comportamiento característico en las redes sociales. Estos hechos pueden ser explotados a nivel de comunicaciones para mejorar el rendimiento de los protocolos como 802.11j [74], pero estamos más interesados en el concepto —introducido primero en [213]— de redes sociales vehiculares como grupos de personas que pueden tener intereses comunes, preferencias o necesidades en un contexto de proximidad temporal y espacial en las carreteras. Un primer objetivo en el desarrollo del SPORANGIUM es proporcionar un marco común para apoyar las características ya probadas en trabajos anteriores [133, 225]. Para ello, se pretende ofrecer mecanismos fiables para establecer comunicaciones de voz directas entre los vehículos cercanos, con la capacidad de filtrar las llamadas entrantes en función de la distancia, el perfil de la persona que llama, etc. Tales comunicaciones fluirán principalmente sobre las redes inalámbricas ad-hoc, típicamente salto a salto, pero usando redes de telefonía móvil solo en los casos en que los mecanismos ad-hoc no puedan garantizar la calidad requerida. Podemos imaginar diferentes motivaciones para el desarrollo de estas llamadas, desde mensajes/preguntas en una sola dirección (por ejemplo, «parece que usted está conduciendo con una rueda baja de aire») a los multidifusión («¿ puede alguien decirme el camino a la plaza de toros?») o comentarios que pueden conducir a conversaciones y nuevas relaciones en una red social clásica (por ejemplo, «es eso un alerón JRS, ¿no?»). 1.5 La plataforma SPORANGIUM 19 Además, las funcionalidades proporcionadas por SPORANGIUM a través de las capas de Computación en Nube Móvil y Gestión del Conocimiento están destinadas a permitir nuevas características relacionadas con una gestión inteligente de la información de manera colaborativa. Por ejemplo, mediante la gestión de perfiles, que incluyen una caracterización de los usuarios y sus patrones de movilidad, la plataforma puede ayudar en la detección de oportunidades para compartir el vehículo en determinados trayectos, al estilo de las iniciativas impulsadas por sitios web como carpooling.com.uk y rideshare.co.uk (Reino Unido), blablacar.es y vao.es (España), carpool.com.pt (Portugal), mitfahrgelegenheit.de (Alemania), 123envoiture.com (Francia) y zimride.com (Canada, USA y México), para reducir los costes, descongestionar carreteras y estacionamientos, reducir la contaminación, etc. Especialmente en las proximidades de las grandes ciudades, muchas personas viajan por rutas que a menudo se superponen significativamente, excepto por unos pocos kilómetros hacia el principio y el fin. Este hecho es particularmente interesante para explotar las situaciones de congestión del tráfico durante horas pico para detectar automáticamente pares que tienen previsto viajes para los próximos días, notificando a los conductores proactivamente y dejando que ellos acuerden los detalles a través de los mecanismos de comunicación directa mencionados anteriormente. Una red ad-hoc creada entre un número de vehículos puede soportar la descarga y el intercambio o difusión de piezas de contenido relevantes para la ubicación de los conductores, que van desde las notificaciones de accidentes y sugerencias de desviación a las relacionadas con la provisión de material publicitario sobre tiendas o atracciones cercanas. Este último punto abre múltiples posibilidades de personalización de acuerdo a los perfiles de cada conductor y de los pasajeros que le acompañan, teniendo en cuenta que el material puede dejar de ser relevante (porque el lugar en cuestión ya no es alcanzable) después de cualquier cruce o unión. En línea con el punto anterior, hacer un seguimiento de los flujos de tráfico y perfiles de conductor pueden ayudar a crear sistemas de publicidad dinámica, capaces de adaptar el contenido que aparece en las vallas publicitarias, carteles u otros canales para mejorar la eficacia de las campañas. Los mecanismos de la SSN permiten implementar estrategias encaminadas a aglutinar a grupos de clientes, por ejemplo, ofreciendo descuentos a condición de que un número mínimo de personas se presenten en una estación de servicio para el almuerzo con el mismo código de cupón. Puede también haber entradas previas desde clientes potenciales, como cuando se utilizan las redes subyacentes para transmitir la información de diagnóstico desde sus vehículos (por ejemplo, niveles de combustible/aceite o la presión de las ruedas) a los establecimientos que podrían realizar las tareas de mantenimiento apropiados. 1.5.3. SPORANGIUM: aplicación en ciudades inteligentes Muchas instituciones están promoviendo el concepto de ciudad inteligente como un movimiento estratégico para mejorar la eficiencia de los servicios públicos, para impulsar la actividad de las empresas locales, y para mejorar la calidad de vida de los ciudadanos. En esta línea, las redes sociales esporádicas habilitadas por SPORANGIUM podrían permitir nuevas formas de comunicación y colaboración entre conocidos o extraños para varios propósitos. Para empezar, las SSNs podrían soportar las iniciativas de bancos de tiempo (time banking) como medio para forjar fuertes conexiones entre comunidades. Los bancos 20 Introducción de tiempo son un patrón de intercambio recíproco de servicios que utiliza unidades de tiempo como moneda: básicamente, el tiempo que un usuario gasta en proveer ese tipo de servicios comunitarios es reembolsado en servicios que podría necesitar él. Esto ha sido utilizado principalmente para proporcionar incentivos y recompensas por trabajos, tales como tutoría a niños o el cuidado de ancianos, que en un sistema de mercado puro está devaluado. Sin embargo, esto también funciona con trabajos pagados de otra manera, como hacer cortes de pelo o jardinería. A pesar de su creciente interés en el contexto de la crisis económica mundial [200], los bancos de tiempo generalmente fallan en no lograr involucrar más allá de unas pocas decenas de personas, a menudo de círculos relativamente cercanos. Aquí es donde las SSNs pueden traer beneficios, ya que la capacidad para activar las comunicaciones entre extraños en las cercanías puede facilitar enormemente el descubrimiento de ofertas potencialmente interesantes y gente que podría estar atraída en lo que cada uno puede aportar. Al igual que sucedió con las redes vehiculares, las SSNs pueden proporcionar medios para ofrecer publicidad de tiendas grandes y pequeñas de forma más efectiva. Por ejemplo, la valoración positiva de un usuario de un restaurante podría hacerse visible no solo a sus contactos en alguno de los sitios Web 2.0, sino también a otras personas con perfiles similares en los alrededores. La valoración podría convertirse en un cupón que, cuando es rescatado por un nuevo cliente, se revertirá en un beneficio para quien hizo la valoración, como un café o un postre gratis. Del mismo modo, las SSNs podrían utilizarse dinámicamente en la identificación de oportunidades para, de manera dinámica, comerciar los lotes de productos en condiciones ventajosas (por ejemplo, ofrecer un 20 % de descuento para un teléfono inteligente si por lo menos 20 personas acuden en el plazo de 20 minutos a comprar una unidad cada una). Las empresas podrían unirse a las SSNs para adaptar sus ofertas, e incluso colaborar para ofrecer paquetes, por ejemplo, cena, entrada a discoteca y taxi privado para el amanecer. Las SSNs también podría convertirse en un elemento básico para mejorar los sistemas de navegación/orientación clásicos basados en GPS. La mayoría de esos sistemas funcionan únicamente con nombres de calles, lo que obliga al usuario que recibe instrucciones a buscar señales que pueden ser difíciles de localizar o incluso desaparecidas. Uno podría ciertamente esperar indicaciones más útiles y naturales desde la ciudad inteligente, por ejemplo, para avanzar «hacia el edificio rojo en la parte inferior», «hacia la rotonda con una estatua de Botero» o «en línea recta hacia el mar hasta encontrar un puesto de periódicos a la izquierda». Estas indicaciones —que deben ser adaptadas a cada individuo (no todo el mundo puede reconocer una estatua de Botero)— podrían derivar de la actividad de los ciudadanos en los sitios Web 2.0 mejorado con los mecanismos de las SSNs, funciones de geolocalización, la posibilidad de hacer y compartir imágenes, etc. Por ejemplo, suele ocurrir que una persona (A) le pregunta a otra (B, probablemente un desconocido) por indicaciones para ir a un lugar determinado. Más allá de una cierta distancia, las explicaciones se hacen más largas y más complicadas, hasta el punto de que a menudo es necesario preguntar a una tercera persona. Los mecanismos de SPORANGIUM podrían simplificar el proceso mediante el establecimiento de una conexión de corta duración entre los teléfonos móviles de A y B. De esta manera, A podría seguir las indicaciones dadas en principio por B hasta un cierto punto y luego enviar una panorámica de 360◦ a B preguntando por dónde seguir... y así proceder sucesivamente. Por último, las SSNs podrían proporcionar bases adecuadas para el funcionamiento de juegos urbanos (también conocidos como juegos basados en la localización) que involucran a grupos de personas —de nuevo, conocidas o no— en actividades de en- 1.6 Objetivos y contribuciones 21 tretenimiento o educativas en el contexto de la ciudad inteligente. Los participantes en este tipo de encuentros, acordados mediante el uso de teléfonos móviles o correos electrónicos, podrían también ser reclutados sobre la marcha. Las experiencias que se ejecutan hasta ahora en varias ciudades de todo el mundo [81,210] revelan grandes posibilidades para la creación de comunidades en la explotación de nuevas herramientas para la comunicación, la interacción y la personalización de contenidos. 1.6. Objetivos y contribuciones El objetivo de esta tesis es diseñar, definir y evaluar una serie de procesos para que los dispositivos móviles colaborativamente creen una infraestructura de nodos virtuales que convierta a las redes inalámbricas ad-hoc en entornos de comunicación más fiables, no solo para mejorar el funcionamiento de algoritmos y protocolos previos, sino para soportar nuevos servicios de comunicación en ambientes pedestres, vehiculares y mixtos. El análisis que hemos desarrollado acerca del rendimiento de los mecanismos empleados por la capa de virtualización frente a escenarios MANETs de mayor movilidad y con servicios más demandantes que los inicialmente estudiados por sus autores [241], nos ha permitido determinar varias fuentes de ineficiencia que resultan en un pobre rendimiento. En respuesta, hemos refinado los procedimientos de la VNLayer y hemos diseñado e implementado nuevos mecanismos que mejoran significativamente la fiabilidad y respuesta de los nodos virtuales. Los resultados obtenidos en la evaluación de las mejoras implementadas a la capa virtual en escenarios MANETs, nos llevó a la pregunta de si la virtualización podría también dar mejores comunicaciones en un campo más específico y demandante como las redes vehiculares ad-hoc. Para analizar esta posibilidad, diseñamos varios experimentos en entornos vehiculares a través de un ambiente de simulación que desarrollamos para tal propósito. Esto nos permitió diseñar, implementar y probar varios refinamientos a la VNLayer y nuevos mecanismos alternativos que le imprimen mejoras significativas para su funcionamiento en estos escenarios, logrando una respuesta más rápida y fiable. Nuestras contribuciones también se han extendido a los procesos de encaminamiento que se ejecutan sobre la capa virtual. Por una parte, hemos implementado una serie de mejoras y nuevos mecanismos a la versión virtualizada de AODV —uno de los protocolos de encaminamiento más conocidos y analizados en la literatura para MANETs— (denominada VNAODV) que permiten alcanzar un mejor rendimiento, no solo en comparación con su versión original y de otros protocolos de encaminamiento en ambientes MANETs, sino también en el soporte de aplicaciones relacionadas con la descarga y diseminación de contenidos en ambientes VANETs. Por otra parte, hemos diseñado un nuevo protocolo de encaminamiento para entornos vehiculares que alcanza un mejor rendimiento que algunos protocolos existentes en la literatura, por haber sido diseñado para trabajar sobre la capa de virtualización, que permite abordar los problemas de la movilidad de forma más efectiva. 1.7. Organización de la memoria La memoria de esta tesis se organiza con arreglo a la siguiente estructura: 22 Introducción La parte I comienza introduciendo el trabajo (Capítulo 1, el presente); a continuación se describe el estado del arte acerca de los mecanismos para hacer frente a la movilidad de los nodos en redes inalámbricas ad-hoc multisalto, en ambientes pedestres y vehiculares (Capítulo 2). La parte II presenta las mejoras y nuevos mecanismos desarrollados a la VNLayer para incrementar su respuesta a la movilidad de los nodos en ambientes MANETs (Capítulo 3) así como para su aplicación en el despliegue de servicios de comunicación en VANETs y el soporte de un nuevo protocolo de encaminamiento (Capítulo 4). Ya en el Capítulo 5, aprovechando los nuevos mecanismos desarrollados en la capa virtual, presentamos un conjunto de escenarios de simulación en los que evaluamos su rendimiento con aplicaciones en el ámbito del acceso a Internet y la descarga colaborativa de contenidos. Por último, la parte III, contiene el Capítulo 6, que recoge las conclusiones de la tesis y las futuras líneas de investigación. Capítulo 2 Mecanismos para hacer frente a la movilidad en las redes inalámbricas ad-hoc En este capítulo analizamos los principales mecanismos propuestos en la literatura para hacer frente a los problemas derivados de la movilidad de los nodos en las redes inalámbricas ad-hoc multisalto. Por una parte, se presenta una revisión del estado del arte de los protocolos de encaminamiento para redes MANETs, VANETs y WMNs; y por otra, se describen las principales características, estructura, funcionamiento y aplicaciones de encaminamiento desarrolladas hasta el momento sobre la capa de virtualización. 2.1. Introducción La movilidad de los nodos es una de las características fundamentales de las redes inalámbricas ad-hoc multisalto. Esta capacidad permite a los dispositivos móviles formar redes de comunicación sobre la marcha, siendo uno de los principales motivos para ser consideradas como una de las tecnologías clave para habilitar los nuevos servicios de la computación ubicua [56,194,218,247]. No obstante, esta movilidad también representa uno de los mayores retos a superar a la hora de diseñar protocolos de comunicación eficientes [65, 83, 249]. Gerla [83] identifica tres problemas derivados de la movilidad: Ruptura de trayectos. Dependiendo de la velocidad de los nodos y sus patrones de movilidad, los trayectos previamente calculados entre nodos comunicantes fallarán frecuentemente. Esta ruptura provocará la pérdida de paquetes de datos y, por tanto, la reducción del rendimiento de la red. Sobrecarga en el tráfico de control de topología. La naturaleza dinámica de estas redes hace que su topología esté en constante cambio, lo que lleva a los protocolos de comunicación a incrementar su carga de tráfico de control para actualizar sus tablas de encaminamiento o para descubrir nuevas rutas. 23 24 Mecanismos para hacer frente a la movilidad en las redes inalámbricas ad-hoc Desconexiones duraderas. La variabilidad en la densidad de nodos, combinada con su movilidad, puede llevar a la formación de redes inconexas por grandes periodos de tiempo, lo que incrementa el retardo en la entrega de los paquetes de datos y/o su pérdida. Para hacer frente a estos retos, se han propuesto dos enfoques. Por una parte, los investigadores han generado una gran cantidad de mecanismos de encaminamiento que consideran aspectos de los nodos como patrones de movilidad, localización, grado de afinidad, entre otros [10, 13, 31, 71, 128]. Por otra parte, se plantea el uso de una capa de virtualización, independiente a la de encaminamiento, como medio para afrontar los problemas de la movilidad y enmascararlos a la vista de los protocolos que se ejecutan sobre ella [67]. En este capítulo, se analiza estas dos propuestas: se realiza una revisión del estado del arte de los protocolos de encaminamiento para redes MANETs, VANETs y WMNs, y se presenta las principales características de la capa de virtualización y las aplicaciones de encaminamiento desarrolladas sobre ella. 2.2. Mecanismos de encaminamiento para MANETs Durante los últimos quince años, la comunidad científica ha generado un gran número de protocolos para las redes MANETs, que van desde las propuestas iniciales de algoritmos adaptables a una amplia gama de escenarios hasta los más recientes centrados en limitaciones específicas (en términos de parámetros de movilidad, limitaciones de energía, conocimiento de la localización física de los nodos, etc.). Consecuentemente, mientras que las primeras revisiones del estado del arte solo consideraban categorías como centralizado/distribuido y proactivo/reactivo/híbridos, las más recientes (por ejemplo [13, 31]) cubren nuevas familias incluyendo algoritmos jerárquicos, multicasting, geográficos, multitrayecto, basados en la potencia (power-aware) y los basados en inteligencia de enjambre (ver figura 2.1). En lo que sigue de esta sección analizaremos esas categorías y algunos de sus protocolos más representativos. Proactivos ZRP ZHLS DSDV OSLR FSR Reactivos DSR AODV Multitrayecto Multidifusión Híbridos DCMP AQM Jerárquicos HSR CEDAR Basados en la potencia DEAR PARO AOMDV GAODM Geográficos LANDY GeoTORA Basados en inteligencia de enjambre ARA BeeAdHoc Figura 2.1: Clasificación de los protocolos de encaminamiento en MANETs. 2.2.1. Protocolos de encaminamiento proactivos En estos protocolos cada nodo mantiene información acerca de cómo alcanzar a los otros nodos en la red a través del intercambio de mensajes de actualización de la topología. Para ello, se generan tablas de encaminamiento en cada nodo a partir del 2.2 Mecanismos de encaminamiento para MANETs 25 intercambio periódico de paquetes con información de la topología entre los miembros de la red. De esta forma, los nodos pueden decidir, con un retardo mínimo, el próximo salto para sus paquetes salientes. Sin embargo, el mantener las tablas de encaminamiento actualizadas implica una significativa carga de tráfico de control y consumo de ancho de banda (aun cuando no haya flujo de datos). Algunos ejemplos de protocolos proactivos son: DSDV [185], OLSR [108] y FSR [183] . Destination-sequenced distance-vector (DSDV) Al ser un protocolo proactivo, los nodos mantienen una visión general de toda la topología de la red. DSDV [185] es un algoritmo basado en vector de distancia. En estos algoritmos, cada nodo en la red tiene una tabla de encaminamiento con las rutas a todos los posibles destinos. Cada registro de esa tabla, referido a un solo destino, contiene información sobre el próximo salto y el número de saltos requeridos para alcanzarlo. En el proceso de encaminamiento, los mensajes transmitidos en la red solo llevan la dirección de los nodos fuente y destino. Cuando un dispositivo recibe un mensaje, busca en su tabla el próximo salto para el destino solicitado y lo retransmite. Para mantener los registros actualizados, cuando un nodo detecta un cambio en la distancia mínima (número mínimo de saltos al destino) informa a sus vecinos de este hecho. Esta técnica, definida como algoritmo Distributed Bellman Ford (DBF), no prevé mecanismos para evitar la posibilidad de producir bucles en los trayectos, por lo que DSDV lo implementa con algunas modificaciones para evitar este problema. Se añade un número de secuencia a cada entrada de la tabla de encaminamiento, lo cual le permite diferenciar las rutas antiguas de las nuevas. Para actualizar las tablas de encaminamiento, se envían mensajes de control periódicamente a sus vecinos. Estos mensajes son de dos tipos: el primero contiene toda la información de los trayectos disponibles en el nodo, mientras que el segundo lleva datos solo de aquellas rutas que han cambiado desde el último envío. Cuando un nodo recibe estos mensajes, compara el valor de la distancia mínima de los enlaces que recibe con los que tiene actualmente en su tabla. Si hay modificaciones, procede a actualizar su valor y vuelve a calcular la distancia del trayecto en cuestión. Cada ruta actualizada tiene un número de secuencia distinto, asignado por el transmisor, de forma que desde ese momento se usa la ruta con el número de secuencia más reciente. En caso de existir dos trayectos con el mismo número de secuencia, se adopta el más corto. Optimized link state routing (OLSR) OLSR [108] está basado en un proceso de encaminamiento inspirado en la técnica de estado de enlace, en la cual, los nodos mantienen una visión de toda la topología de la red con un coste para cada enlace. Esta visión les permite calcular las rutas a los destinos con el mínimo valor de coste. Para mantener actualizado el conocimiento de la topología, cada nodo, periódicamente, inunda la red con paquetes que contienen los costes de sus enlaces salientes a los otros dispositivos [159]. Al igual que otros protocolos de esta familia, OLSR emplea un intercambio periódico de mensajes entre los nodos para mantener la información sobre la topología de la red en cada nodo. Para limitar el alcance de los mensajes difundidos en la red, se utiliza una técnica de retransmisión multipunto. Cada nodo (por ejemplo, S) selecciona un conjunto de vecinos, denominados retransmisores multipunto (MPRs, del inglés Multipoint Relays), para que reenvíen sus paquetes, de tal forma que los nodos fuera de 26 Mecanismos para hacer frente a la movilidad en las redes inalámbricas ad-hoc este conjunto pueden procesar los paquetes recibidos desde S, pero no pueden retransmitirlos. Los nodos escogen sus MPRs de entre sus vecinos a un salto (en términos del alcance de su radio), de manera que puedan llegar a todos los nodos que se encuentren a dos saltos de distancia. Por ejemplo, en la figura 2.2, los nodos A, B, C, D, E y F son los vecinos a un salto de S. Sin embargo, solo A, C, D y F son escogidos como sus MPRs, dado que constituyen el número mínimo de nodos a un salto que le permiten alcanzar a todos los nodos a dos saltos. B Nodo MPR S Nodo Fuente Figura 2.2: Retransmisores multipunto. En el proceso de construcción de las tablas de encaminamiento, los nodos usan dos tipos de paquetes de control: mensajes HELLO y mensajes de control de topología (TC, del inglés Topology Control). Los mensajes HELLO, difundidos periódicamente por cada nodo, contienen información acerca de sus vecinos y el estado de sus enlaces, lo que permite a cada nodo tener la información suficiente para seleccionar su lista de MPRs. Los mensajes HELLO posteriores contendrán la lista calculada de manera que los nodos puedan construir una lista adicional con los vecinos que los han seleccionado como MPRs. La lista de MPRs es recalculada cada vez que se detecta un cambio dentro del vecindario a uno o dos saltos (e.g., fallo de enlace, ingreso de un nuevo nodo, etc.). Por su parte, los TCs son empleados por cada nodo para construir su tabla de topología. Estos mensajes contienen la lista de los vecinos que han seleccionado los nodos generadores de los TCs como sus MPRs y un número de secuencia asociado a esa lista. De esta forma, solo aquellos nodos que han sido seleccionados como MPRs pueden enviar mensajes TC. En el caso de la figura 2.2, los nodos A, B, C, D, E y F seleccionan a S como su MPR, G escoge a F , mientras que H e I hacen lo propio con A. De esta forma tenemos que TC (S ) = {A, B , C , D , E , F }; TC (G) = {F }; T C(H) = {A} y T C(I) = {A}. Con base en esta información, los nodos calculan su tabla de encaminamiento para la retransmisión de los datos buscando la ruta más corta. Fisheye state routing (FSR) Al igual que OLSR, FSR [183] es un protocolo basado en la técnica de estado de enlace. No obstante, a diferencia de otros protocolos de este tipo, FSR no inunda la red con paquetes de control cada vez que detecta un cambio en la topología, sino que, por el 2.2 Mecanismos de encaminamiento para MANETs 27 contrario, periódicamente intercambia dichos datos con sus vecinos (sin inundación), disminuyendo el tráfico de control en la red. Con ese mismo propósito y siguiendo la técnica de «ojo de pez» (del inglés fisheye), diferentes tamaños de paquetes de control se emplean en los procesos de actualización. Cada nodo define varios alcances en función de la cantidad de dispositivos dentro de un determinado número de saltos. Las entradas de las tablas de encaminamiento cuyos destinos están presentes en los alcances más próximos al nodo tendrán una frecuencia de actualización mayor que aquellas ubicadas en los alcances más alejados. Esta aproximación hace de FSR un protocolo implícitamente jerárquico (sección 2.2.4). 2.2.2. Protocolos de encaminamiento reactivos A diferencia de los protocolos proactivos, esta clase de protocolos no intentan encontrar rutas a cada uno de los nodos en la red, sino solo a aquellos a los que actualmente tienen que enviar algún paquete de datos. Los algoritmos reactivos típicamente inundan la red con mensajes de solicitud cuando necesitan descubrir algún destino. Este proceso implica la existencia de una cierta latencia antes que los paquetes puedan llegar a su destino; sin embargo, suelen tener menos carga adicional de tráfico de control y menos demanda de memoria que sus pares proactivos, lo cual incrementa su escalabilidad. Varios protocolos reactivos como DSR [112] y AODV [184], ambos descritos a continuación por ser los más representativos, han sido propuestos en la literatura. Otros protocolos de esta categoría pueden ser encontrados en [13, 31]. Dynamic source routing (DSR) DSR [112] es un protocolo reactivo que emplea la técnica de encaminamiento basada en fuente (del inglés source-based). Cada paquete de datos lleva en su cabecera, cargado desde el nodo fuente, la secuencia completa de nodos del trayecto hasta el destino. Esto permite evitar los bucles en las rutas y la necesidad de mantener información actualizada en los nodos intermedios. Se emplean típicamente dos procesos: descubrimiento y mantenimiento de ruta. Ambos procesos se desarrollan bajo demanda. El descubrimiento de ruta permite al nodo fuente aprender el camino hacia el destino —no obstante, el nodo también aprende nuevas rutas escuchando procesos similares desarrollados por otros nodos. Cuando un nodo S desea enviar un paquete a un nodo D, primero busca en su memoria caché una ruta a ese nodo; si no la encuentra, se inicia un proceso de descubrimiento de ruta. El nodo S difunde un mensaje de solicitud de ruta (RREQ, del inglés Route Request) hacia sus vecinos. Cada nodo escuchando este mensaje agrega a la cabecera del paquete su identificador y lo vuelve a difundir. Este proceso se repite hasta alcanzar al nodo D o a algún nodo que tenga una ruta válida hacia él. En cualquiera de los dos casos, un mensaje de respuesta de ruta (RREP, del inglés Route Reply), con la secuencia completa fuente-destino, es enviado de vuelta hacia el nodo S. DSR asume que el primer paquete en retornar al nodo fuente es el que tiene la distancia más corta. Con esta información, el nodo S iniciará el proceso de envío de los paquetes de datos. Para el mantenimiento de ruta, durante la transmisión de los datos, los nodos intermedios que reciben los paquetes envían al nodo precedente un mensaje ACK (del inglés Acknowledgement) acusando su recepción; lo que permite detectar problemas en los enlaces. Esta confirmación también se realiza mediante un proceso conocido 28 Mecanismos para hacer frente a la movilidad en las redes inalámbricas ad-hoc con acuse de recibo pasivo (del inglés pasive acknowledgement), en el cual el nodo transmisor escucha si el próximo salto ha retransmitido el paquete en la ruta hacia el destino. En caso de fallar el proceso de acuse de recepción, un mensaje de error de ruta (RERR, del inglés Route Error) es enviado de vuelta al nodo fuente para que inicie un nuevo proceso de descubrimiento. Los nodos intermedios que reciben este mensaje de error borran de su memoria caché la ruta fallida. Ad-hoc on-demand distance vector (AODV) AODV [184] es un protocolo reactivo, que, a diferencia de DSR, usa una técnica de encaminamiento salto a salto, en la que las decisiones de encaminamiento sobre el próximo salto al destino son tomadas en cada uno de los nodos intermedios. Su operación es como sigue: B A G F H c I (a) Propagación del mensaje de solicitud de ruta. (RREQ) B A G F c H I (b) Camino tomado por el mensaje de respuesta de ruta (RREP). Figura 2.3: Funcionamiento del protocolo AODV. 2.2 Mecanismos de encaminamiento para MANETs 29 Descubrimiento de ruta. Como se muestra en la figura 2.3(a), cuando un nodo S necesita enviar un paquete a otro nodo D, pero no conoce la ruta, almacena el paquete y difunde un mensaje RREQ. Los vecinos que reciben este paquete lo difunden hasta alcanzar a D o algún nodo con una ruta válida a él. Dicho nodo genera un RREP, el cual es enviado al nodo fuente por unicast1 a través de la ruta aprendida con el mensaje RREQ. Por ejemplo, en la figura 2.3(b) el nodo destino D envía de vuelta a S un RREP a través de los nodos G, B y A que constituyen la ruta más corta. El mensaje RREP permite a los nodos a lo largo del trayecto de retorno configurar un camino de reenvío al destino en su tabla de encaminamiento. Reenvío de los paquetes de datos. Una vez que la ruta desde la fuente al destino ha sido establecida, los paquetes son enviados nodo a nodo por unicast. Por tanto, los errores de enlace pueden ser detectados rápidamente por los servicios de la capa de enlace (por ejemplo, cuando no puede resolver la dirección MAC del próximo nodo encaminador (router), cuando el mecanismo RTS/CTS de IEEE 802.11 2 no puede reservar el canal con el próximo salto, o cuando no hay un acuse de recibo para confirmar la recepción de un paquete de datos y los intentos de retransmisión fallidos). Mantenimiento de ruta. De todos modos, cuando un nodo detecta un fallo, se puede o informar de su ocurrencia a los llamados precursores (es decir, los nodos vecinos para los cuales un mensaje de respuesta de ruta se generó o retransmitió) mediante el envío de un RERR o probar una reparación local mediante la difusión de un mensaje de RREQ y esperar por un mensaje RREP para restablecer el enlace. En el primer caso, los paquetes de datos que el nodo estuvo retransmitiendo se descartan, por lo que no van a llegar a sus destinos; en el segundo, los paquetes se almacenan temporalmente el mayor tiempo posible. El principal inconveniente de AODV tiene que ver con la sobrecarga causada por la difusión de mensajes RREQ y la inestabilidad de las rutas durante los periodos de movilidad, media o alta (ver [120]). 2.2.3. Protocolos de encaminamiento híbridos Los protocolos híbridos combinan características tanto de los protocolos proactivos como de los reactivos, siguiendo la intuición que los protocolos de encaminamiento proactivos son más convenientes para áreas donde las conexiones cambian relativamente poco, mientras que los protocolos reactivos son mejores en áreas con frecuentes cambios en la topología. Algunos protocolos híbridos, tales como DST [189] y DDR [173], construyen explícitamente un backbone con los nodos que tienen conexiones más estables; los nodos en el backbone usan un protocolo proactivo, mientras que los otros son alcanzados a través de uno reactivo. Otros protocolos clasifican a los nodos en zonas definidas desde la perspectiva del nodo origen, ya sea basados en el número de saltos 1 Unicast es la transmisión de información desde un único transmisor a un único receptor. el mecanismo RTS/CTS, cuando un nodo desea enviar datos, primero transmite al destinatario un paquete denominado RTS (del inglés Request to Send), quien le responderá con un paquete CTS (del inglés Clear to Send). Este intercambio informa a los demás nodos que el medio está ocupado, sin importar si solo han escuchado uno de los dos mensajes. Luego del intercambio exitoso del RTS y CTS, se envía la trama de datos, que se asiente con un ACK. Este proceso solo se utiliza con los paquetes enviados a través de unicast. 2 Mediante 30 Mecanismos para hacer frente a la movilidad en las redes inalámbricas ad-hoc como con ZRP [90], FSR [183] y RDMAR [6] o basados en la localización física como con SLURP [98] y ZHLS [110]. En general, estos protocolos mantienen principios de funcionamiento similares por lo que a continuación describiremos únicamente a ZRP y ZHLS para ilustrar sus características. Zone routing protocol (ZRP) ZRP [90] es un protocolo de encaminamiento híbrido que basa su funcionamiento en el concepto de zonas. Cada nodo define una zona de encaminamiento con un radio de cobertura ρ expresado por el número de saltos. La zona incluye todos los nodos cuya distancia, desde el nodo en cuestión, es menor o igual a ρ saltos. En cada zona, se definen dos clases de nodos: periféricos, cuya distancia mínima al nodo central es exactamente ρ saltos, e internos con una distancia mínima menor a ρ. Por ejemplo, en la figura 2.4(a), S define una zona con ρ=2, donde los nodos A, B, C, D, y E son internos; mientras que los nodos F , G y H son periféricos. En este protocolo, las zonas se traslapan, por lo que los nodos cumplirán diferentes roles en función del origen de la zona. Así, el nodo A es interno para la zona definida por S (figura 2.4(a)) pero es periférico para la zona de H (figura 2.4(b)). S (a) Zona de S. E D (b) Zonas de H y M . Figura 2.4: Ejemplo de ZRP con ρ=2. 2.2 Mecanismos de encaminamiento para MANETs 31 ZPR utiliza un protocolo proactivo para el encaminamiento dentro de la zona (IARP, del inglés IntrA-zone Routing Protocol) y un protocolo reactivo para las comunicaciones externas. El algoritmo mantiene una tabla de vecinos por cada uno de los nodos en la red a través de la emisión periódica de mensajes HELLO. Esta información permite a IARP actualizar sus tablas de encaminamiento con los destinos en el interior de la zona. El proceso de encaminamiento de ZRP es como sigue. Cuando un nodo desea enviar un paquete, primero revisa si el destino se encuentra en su zona usando la información provista por IARP. Si es el caso, el paquete es encaminado en forma proactiva mediante las rutas disponibles; de no ser así, el nodo inicia un proceso de encaminamiento reactivo. Al igual que en otros protocolos reactivos, se difunden en la red paquetes RREQ para determinar el trayecto hacia el destino. Sin embargo, a diferencia de otros protocolos de esta clase, ZRP usa la información presente en IARP para dirigir la búsqueda de la ruta hacia los nodos periféricos. Estos nodos comprueban si conocen al destino buscado, si es así, envían un RREP al nodo solicitante para iniciar la transmisión de los datos; de lo contrario, el RREQ es reenviado a los nodos en el borde de su zona para que continúen con el mismo proceso. Por ejemplo, en la figura 2.4, el nodo S desea enviar datos al nodo X. Al determinar que el destino no se encuentra dentro de su zona, envía un RREQ a sus nodos periféricos F , G y H (figura 2.4(a)). El nodo H no encuentra a X en su tabla de encaminamiento por lo que reenvía el RREQ a sus nodos periféricos A, M y S (figura 2.4(b)). Dado que el RREQ proviene de la zona S, los nodos A y S no lo retransmitirán. El nodo M , por su parte, al localizar a X dentro de su zona envía de regreso a S un RREP para que se inicie la transmisión de los datos. Zone based hierarchical link state routing protocol (ZHLS) ZHLS [110] divide la región en zonas no superpuestas, cuyo ancho depende de factores tales como la movilidad de los nodos, la densidad de la red, la potencia de transmisión y las características de propagación del medio. A cada una de estas zonas le corresponde un identificador, el cual es conocido previamente por los nodos. Además, se asume que cada nodo puede determinar su posición a través de sistemas GPS y, por tanto, determinar la zona en la que se encuentra. Basado en esta división geográfica, ZHLS divide la topología de la red en dos niveles: un nivel inferior (nivel de nodo), en la que todos los nodos en el interior de la zona conocen su conectividad (por ejemplo, en la figura 2.5(a), los nodos de la zona 4 conocen que hay conectividad entre los nodos 4_a y 4_b, 4_b y 4_c, y entre 4_d y 4_c, y así en cada una de las zonas), y un nivel superior (nivel de zona), en la que los nodos conocen la conectividad de las zonas en toda la red. La conectividad entre zonas está determinada por la presencia de al menos un nodo en cada zona, con conectividad entre ellos. En este caso se dice que existe una conexión virtual. El nivel de zona nos dice cómo están conectadas las zonas a través de esas conexiones virtuales. En la figura 2.5(b), podemos observar, por ejemplo, que la conexión entre las zonas 5 y 2, es 5 − 4 − 1 − 2. ZHLS es un esquema híbrido: proactivo si el destino se encuentra dentro de la zona del nodo fuente y reactivo si está fuera de esa zona. En la parte reactiva, los paquetes son encaminados a través de una dirección jerárquica del nodo destino (un identificador 32 Mecanismos para hacer frente a la movilidad en las redes inalámbricas ad-hoc 1 3 2 2.a 3.b 1.a 1.c 3.a 2.c 1.b 3.c 2.b 4 4.b 4.a 5 6.a 6 5.a 4.c 6.b 5.b 5.c 4.d 7 9 8 7.a 8.d 9.a 8.b 7.b 8.a 7.c 8.c (a) Topología a nivel de nodo. 1 2 3 4 5 6 7 8 9 (b) Topología a nivel de zona. Figura 2.5: Conectividad en ZHLS. 2.2 Mecanismos de encaminamiento para MANETs 33 de zona y un identificador de nodo) ubicada en la cabecera del paquete. No se especifica una lista de nodos intermedios entre fuente-destino. La topología de la red es construida a partir de la difusión de dos tipos de paquetes de estado de enlace (LSPs, del inglés Link State Packets): nodo LSPs y zona LSPs. Los mensajes nodo LSPs de cada nodo contienen la lista de sus vecinos conectados y es propagada dentro de su zona. Por su parte, los mensajes zona LSPs contienen la lista de sus zonas conectadas y son propagadas en toda la red. Para desarrollar estos listados, los nodos difunden en forma asíncrona un mensaje de solicitud de enlace. Los nodos dentro del rango de cobertura del emisor recibiendo esta solicitud responden con un mensaje de respuesta de enlace que contiene su identificación de nodo y de la zona en la que se encuentran. Con esta información, cada nodo genera un paquete nodo LSPs con la identificación de los nodos con los cuales mantiene conexión dentro de su zona y además la identificación de las zonas conectadas a la suya. Esto permite a los nodos construir su tabla de encaminamiento intrazona mediante un algoritmo que calcula los trayectos más cortos entre nodos. Por ejemplo, en la red de la figura 2.5(a), el nodo 4_c emitirá un mensaje nodo LSPs indicando conexión con los nodos 4_b, 4_d y la zona 5. Los nodos en su zona difundirán mensajes similares, permitiendo al nodo 4_c construir su tabla de encaminamiento intrazona (ver tabla 2.1). Destino 4_a 4_b 4_d 1 5 7 Próximo nodo 4_b 4_b 4_d 4_b 5_c 4_d Tabla 2.1: Tabla de encaminamiento intrazona del nodo 4_c, figura 2.5(a) Además, cada nodo genera los paquetes zona LSPs, con los datos de la conexión entre zonas. Los mensajes zona LSPs son difundidos en la red a través de las pasarelas (nodos que conectan dos zonas). En el caso de la zona 4 en la red de la figura 2.5(a), sus nodos pasarela 4_b, 4_c y 4_d difunden el mensaje zona LSPs de esta zona a toda la red, indicando conexión con las zonas 1, 5 y 7. Mensajes similares son difundidos por los nodos pasarela de las otras zonas. A partir de estos datos, los nodos generan sus tablas de encaminamiento interzona, calculando el trayecto más corto a las zonas (ver la tabla 2.2 para el caso del nodo 4_c). Este proceso se repite periódicamente; sin embargo, para limitar la carga de tráfico de control, las pasarelas no retransmitirán aquellos mensajes zona LSPs que no muestren cambios en la red. Zona destino 1 2 3 5 6 7 Próxima zona 1 1 1 5 1 7 Próximo nodo 4_b 4_b 4_b 5_c 4_b 4_d Tabla 2.2: Tabla de encaminamiento interzona del nodo 4_c, figura 2.5(a) De esta forma, cuando un nodo fuente necesita enviar un paquete (por ejemplo, el nodo 4_c en la figura 2.5(a)), primero indaga en su tabla de encaminamiento intrazona para determinar si el nodo destino (e.g., el nodo 2_b) se encuentra dentro de su zona. 34 Mecanismos para hacer frente a la movilidad en las redes inalámbricas ad-hoc Si es así, el paquete es encaminado directamente al destino deseado; caso contrario, se difunde un mensaje de solicitud de zona para averiguar la zona en la que se encuentra. Cada nodo intermedio retransmite este mensaje zona a zona siguiendo su tabla interzona. Los nodos pasarela verifican si el nodo buscado se encuentra en su región; si es el caso (nodo 2_a), se envía de vuelta al nodo origen un mensaje de respuesta de localización, conteniendo la identificación de la zona (zona 2). Luego de ello, el paquete de datos es transmitido desde el origen hasta el destino basado en su dirección jerárquica (<2, 2_b>). 2.2.4. Protocolos de encaminamiento jerárquicos Estos protocolos pueden ser vistos como un caso particular de los protocolos híbridos, en los cuales los nodos forman grupos (clusters) tal que el intercambio de mensajes puede ser manejado en forma diferente dentro del mismo cluster (e.g., con un algoritmo proactivo) y entre diferentes clusters (e.g., con una aproximación reactiva). Uno o más líderes de cluster son responsables de la transmisión de los paquetes en nombre de los nodos que pertenecen a cada cluster, lo cual hace que los mecanismos de encaminamiento entre clusters traten con un número reducido de nodos (favoreciendo así la escalabilidad). A su vez, esto es de suma importancia para tratar apropiadamente el movimiento de los nodos de una región a otra, especialmente en el caso de los nodos líder de cluster. Ejemplos de encaminamiento jerárquico son los protocolos HSR [106] y CEDAR [211]. Hierarchical state routing (HSR) HSR [106] es un protocolo de encaminamiento que combina una estructura jerárquica basada en grupos de nodos con una gestión de localización a través de la afinidad entre nodos. En un primer nivel de jerarquía, los nodos se agrupan basados en su proximidad. En la figura 2.6, podemos observar un ejemplo de la estructura jerárquica de los nodos. En el nivel 0, cada cluster está conformado por tres clases de nodos: un nodo líder (nodos 1, 2, 3 y 4), que coordina las transmisiones del grupo; los nodos internos, ubicados geográficamente en el interior de la zona del grupo (nodos 5, 9 y 10) y los nodos pasarela, pertenecientes a dos o más clusters (nodos 6, 7, 8 y 11). Dentro del cluster, cada nodo monitoriza el estado de su enlace con cada vecino y lo difunde dentro del grupo. Cada nodo líder consolida la información de su grupo y la comparte con los líderes vecinos a través de los nodos pasarela. Basados en la conectividad entre nodos líderes, se forma un segundo nivel de agrupamiento. Al igual que en el nivel anterior, se selecciona un líder para este nuevo nivel (e.g., los nodos 1 y 2 constituyen un segundo nivel de agrupamiento con el nodo 1 como líder; al igual que con los nodos 3 y 4, con el nodo 3 como líder). Este mecanismo de agrupamiento se repite para formar los siguientes niveles (los nodos 1 y 3 conforman el último nivel jerárquico, con el nodo 1 como su líder). Se usan dos clases de direcciones en el proceso de encaminamiento. Por una parte, las direcciones jerárquicas (HIDs, del inglés Hierarchical ID) se utilizan para encaminar los paquetes a través de la estructura jerárquica formada. Los paquetes de datos son enviados a los líderes de los niveles superiores a través de los enlaces virtuales (caminos que conectan a dos nodos líderes) hasta que el paquete alcance el nivel jerárquico inmediato del nodo destino. Por ejemplo, si consideramos que el nodo 5, con dirección jerárquica HID(5) =< 1, 1, 5 > (dado que es miembro de C1−1 y C2−1 2.2 Mecanismos de encaminamiento para MANETs 35 Figura 2.6: Ejemplo de cluster físico y virtual [106]. en los niveles superiores), desea enviar un paquete de datos al nodo 10, con dirección jerárquica HID(10) =< 3, 3, 10 > (dado que es miembro de C1−2 y C2−1 en los niveles superiores), primero reenvía el paquete a su nivel superior, el nodo 1. Este nodo a su vez lo entrega al nodo 3, que es el nivel superior del nodo 10, quien finalmente lo entrega a su destino. El trayecto que sigue el paquete es a través de la conexión virtual formada por los nodos 1, 7, 2, 8 y 3, como se muestra en la figura 2.6. Por otra parte, a cada nodo se le asigna una dirección lógica <subred, nodo>. Cada subred corresponde a un grupo de usuarios particulares (por ejemplo, equipos de búsqueda, grupos de combate, etc.) que pueden estar ubicados en diferentes secciones de la estructura jerárquica. Esta nueva división lógica permite generar un servicio de localización distribuida para la búsqueda de los nodos en el momento de enviar un paquete. Para ello, en cada una de estas subredes se define un nodo agente encargado de la gestión de la afiliación de los nodos a la subred. Estos nodos difunden su HIDs a los niveles jerárquicos superiores de manera que cada miembro de la subred conoce la HIDs de su nodo agente y puede registrarse periódicamente. Los nodos en la red únicamente conocen la localización de aquellos que están dentro de su nivel jerárquico y cluster. Por ello, cuando un nodo desea enviar un paquete a otro nodo cuya localización le es desconocida, usa su nodo agente para determinar la HIDs del destino y proceder a encaminarlo. Core-extraction distributed ad hoc routing algorithm (CEDAR) CEDAR [211] basa su funcionamiento en el establecimiento dinámico de un conjunto de nodos que conforman el núcleo de la red (nodos de núcleo) y que se encargan de la gestión del estado de enlace y el cálculo de las rutas. Este núcleo se genera a través 36 Mecanismos para hacer frente a la movilidad en las redes inalámbricas ad-hoc 9 15 6 5 2 3 Figura 2.7: Un ejemplo mostrando un posible conjunto de nodos de núcleo y sus conexiones físicas y virtuales. de un conjunto mínimo de nodos que representa el conjunto dominante y que hace que todos los nodos de la red pertenezcan a ese conjunto o sean vecinos de alguno de sus miembros. Para ello, debe existir al menos un nodo de núcleo cada tres saltos con algún nodo normal (no perteneciente al núcleo) bajo su dominio dentro de una distancia no mayor a un salto. Cada nodo de núcleo mantiene la topología local de los nodos bajo su dominio y también realiza los cálculos de las rutas en nombre de ellos. Por ejemplo, en la figura 2.7, los nodos 1, 4, 10, 12 y 17 constituyen los nodos de núcleo de la red, mientras que el resto de nodos se encuentran a máximo un salto de distancia de alguno de ellos. Cada nodo de la red difunde periódicamente un mensaje BEACON con información acerca del número de vecinos que lo han escogido como su dominador, así como el id de su propio nodo dominador —si no tiene uno, escogerá como tal a su vecino a un salto con el mayor número de nodos en su dominio. Los nodos que han sido escogidos por al menos otro nodo en la red como su dominador se convierten en parte del núcleo. Este proceso hace que el núcleo se adapte a la movilidad, permitiendo que los nodos ingresen o salgan de él dinámicamente. Estos nodos de núcleo anuncian su presencia en una área a tres saltos, de manera que la topología local del núcleo de la red, conformada por nodos de núcleo y enlaces virtuales —trayectos a través de nodos físicos a cada uno de ellos— es conocida por todos los vecinos. Por otra parte, el estado de los enlaces es monitorizado por cada nodo. Cuando un enlace se restablece o se cierra, o cuando su ancho de banda se incrementa o disminuye más allá de un umbral determinado, los nodos a los extremos del enlace notifican de este hecho a sus dominadores para que lo difundan a través del núcleo de la red. El alcance de estos mensajes está en función del incremento o disminución del ancho de banda, de manera que los enlaces de bajo ancho de banda o inestables se mantengan a nivel local, mientras que los enlaces de mayor ancho de banda y estabilidad son propagados a mayor distancia en el núcleo de la red. Esto permite que estos últimos sean más utilizados que aquellos con valores bajos o inestables. El proceso de encaminamiento de CEDAR es bajo demanda y tiene tres elementos principales: establecimiento del trayecto de núcleo, cálculo de la ruta con QoS y recálculo de las rutas con QoS para las conexiones en curso. Cuando un nodo fuente (e.g., el nodo 2 en la red de la figura 2.7) desea comunicarse con un nodo destino (nodo 18) envía a su dominador (dom(2), el nodo 1) un mensaje conteniendo los identifi- 2.2 Mecanismos de encaminamiento para MANETs 37 cadores de la fuente, el destino y el ancho de banda deseado. Si dom(2) ya tiene la ruta hacia el dom(18) en su memoria caché, inicia la fase de establecimiento de la ruta con QoS; en caso contrario, el dom(2) difunde en el núcleo de la red un mensaje de requerimiento para establecer la ruta a través del núcleo de la red hacia dom(18). Este mensaje se propaga hasta llegar a algún nodo de núcleo con un trayecto al dominador deseado o hasta llegar a él. En nuestro caso, cuando el mensaje llega a dom(18) (el nodo 17) envía de vuelta a dom(2), vía unicast, un mensaje core_path_ack con el trayecto de núcleo entre dom(2) y dom(18). En el establecimiento de la ruta con QoS, aprovechando del conocimiento de la topología local, dom(2) intenta encontrar una ruta a través del trayecto de núcleo que cumpla la QoS requerida. Entre todas las rutas disponibles se escoge la más corta usando el algoritmo de Dijkstra. La concatenación de los tramos parciales calculados a lo largo del trayecto de núcleo provee la ruta extremo a extremo que permite el envío de los datos entre los nodos 2 y 18. Mientras se establece esta ruta definitiva, los paquetes pueden ser enviados usando el trayecto de núcleo, constituyéndose, así, en un camino de respaldo. En caso de fallo de algunos de los enlaces, dos procesos pueden ser seguidos. Si el enlace con error es cercano al destino, se inicia un proceso de establecimiento de ruta con QoS local, similar al descrito previamente. En ese caso, luego de la reparación de la ruta, los paquetes son reenviados a través del nuevo enlace. Por otra parte, si el enlace con fallo está más cerca a la fuente que al destino, entonces se notifica al nodo fuente para que sea este quien inicie el procesos de recálculo del enlace, deteniendo la transmisión de datos hasta que se restablezca. 2.2.5. Protocolos de encaminamiento de multidifusión La multidifusión (en inglés, multicasting) es la transmisión simultánea de datos desde un transmisor a múltiples receptores, habilitada por algoritmos de encaminamiento tales como DCMP [61] y AQM [32]. El soporte de la multidifusión en la capa de red proporciona una solución mucho más escalable para aplicaciones tales como la transmisión de vídeo en tiempo real, que recurrir a la transmisión individual de la fuente hacia cada uno de los receptores o implementar multidifusión en la capa de aplicación. Dynamic core based multicast routing (DCMP) DCMP [61] genera una estructura de malla para soportar la multidifusión de los datos. Para ello, clasifica a los nodos fuente en tres categorías: activos, activos de núcleo y pasivos. Los nodos fuente activos son los encargados de crear y mantener la malla de multidifusión. Los activos de núcleo son aquellos nodos fuente activos que dan soporte a los pasivos para la transmisión de sus paquetes, dado que estos últimos no pueden enviarlos de forma directa. La cantidad de nodos pasivos soportados por cada uno de los nodos fuente activos de núcleo y el número de saltos máximo desde un nodo fuente pasivo a uno activo de núcleo están limitados por determinados valores que aseguran la presencia de un número mínimo de nodos fuente activos para soportar y mantener la estructura de la malla. Cuando un nodo fuente activo tiene datos para enviar, inunda la red con mensajes JoinReq. Los nodos intermedios que reciben paquetes no duplicados los retransmiten añadiendo su identificador en la cabecera del paquete. Un nodo receptor que desee estos datos prepara un paquete de respuesta y lo envía de vuelta al nodo fuente a través del 38 Mecanismos para hacer frente a la movilidad en las redes inalámbricas ad-hoc trayecto cargado en la cabecera del paquete JoinReq recibido. Los nodos intermedios que constan en el trayecto de retorno del paquete de respuesta se convierten en nodos de retransmisión. Finalmente, los paquetes de datos son enviados a los nodos receptores a través de la malla generada. Ad hoc QoS multicasting (AQM) Para la difusión de los mensajes, AQM [32] genera una estructura de árbol cuya raíz es el nodo iniciador de la sesión (MCN_INIT). Este nodo difunde un paquete SES_INIT que contiene el identificador de la sesión y la QoS solicitada —diferentes clases de QoS son definidas para soportar varios tipos de aplicaciones y para limitar la cantidad de información que es transmitida entre los nodos de la red. En los nodos, se mantienen una tabla de sesiones activas (TBL_SESSION) con información sobre cada una de ellas y una tabla de miembros (TBL_MEMBER) que indica el estado de los predecesores (MCN_PRED) que han informado al nodo sobre la presencia de una determinada sesión de multidifusión y la QoS soportada desde el iniciador hasta ellos a través de ese predecesor. Las tabla de sesiones y la de miembros permiten que los nodos retransmitan únicamente los paquetes SES_INIT de sesiones nuevas que cumplan las condiciones de QoS requeridas. Por ello, antes de retransmitirlo, cada nodo actualiza el campo de información de QoS del paquete con las condiciones actuales de calidad de servicio que experimenta. De no cumplirse las condiciones requeridas, se descarta el paquete. La información de la sesión es actualizada constantemente a través de la difusión de un paquete SES_UPDATE enviado por el nodo iniciador. Al igual que el SES_INIT, este paquete es difundido a través de la red mientras se cumplan las condiciones de QoS; no obstante, el SES_UPDATE es difundido para todas las sesiones, sean nuevas o antiguas, lo que permite que los nodos conozcan las posibles sesiones para posteriores accesos. Las sesiones son finalizadas mediante un mensaje SES_TERMINATE enviado por el nodo iniciador. Con la recepción de este mensaje, los nodos borran las entradas de sus tablas correspondientes a esa sesión, liberando los recursos asignados. Los miembros de una sesión son el iniciador, los retransmisores y los receptores. Un nodo solo puede unirse a una sesión que es conocida por él. Puede también unirse directamente a una sesión si ya es un retransmisor; en caso contrario, debe enviar una solicitud de adhesión (JOIN_REQ), que es retransmitida por los nodos en dirección del servidor que tienen conocimiento de la sesión (siempre que se cumplan las condiciones de QoS). La dirección de flujo del JOIN_REQ es garantizada comparando el contador de saltos del paquete con la distancia al servidor en cada nodo intermedio. Estos nodos mantienen una tabla de solicitudes temporales (TBL_REQUEST) para registrar las solicitudes y respuestas que ellos retransmite, evitando de esta manera duplicar paquetes ya procesados. Cuando el (JOIN_REQ) alcanza algún nodo miembro responde con un paquete JOIN_REP. Los nodos en la dirección del solicitante que han retransmitido el JOIN_REQ y que reciben la respuesta, almacenan durante un tiempo determinado los paquetes JOIN_REP que llegan desde diferentes miembros de la sesión para escoger el de mejor QoS que será retransmitido finalmente. La información del nodo generador de la respuesta y del retransmisor inmediato son mantenidos en el paquete. El nodo solicitante selecciona la respuesta con mejor QoS, pasa su estado de predecesor a receptor (MCN_RCV) y envía un mensaje de reserva (JOIN_RES) al nodo originador del JOIN_REP seleccionado. Los nodos intermedios que reciben este paquete verifican si ellos están en el trayecto seleccionado, si es es así, cambian su estado de predecesor 2.2 Mecanismos de encaminamiento para MANETs 0 39 0 2 3 2 3 5 5 (a) (b) Figura 2.8: Ejemplo de gestión de los nodos miembro en AQM [32]. a retransmisor (MCN_FWD), reservan recursos y actualizan sus tablas de miembros. Si quien responde al JOIN_REQ es el iniciador y este es su primer miembro, cambia su estado a servidor (MCN_SRV). Por ejemplo, en la figura 2.8(a) el nodo 5 quiere unirse a la sesión iniciada por el nodo 0 para ello difunde un mensaje JOIN_REQ, el cual es propagado hacia algún miembro de la sesión. Los nodos 1 al 4 propagan el mensaje y actualizan sus tablas de requerimiento dado que ellos no son miembros de la sesión. El nodo iniciador responde con un paquete JOIN_REP que alcanza al nodo 5 a través de dos trayectos 0−1−3 y 0−2−4. El nodo 5 envía un JOIN_RES a través de los nodos del trayecto con QoS seleccionado 4−2−0, reservando los recursos y cambiando su estado, como se muestra en la figura 2.8(b). Los otros nodos ignoran los mensajes. Si múltiples mensajes JOIN_RES llegan a un nodo miembro, este reserva los recursos requeridos en orden de llegada de las solicitudes hasta alcanzar su ancho de banda límite. Para las solicitudes restantes se envía un mensaje de error JOIN_ERR al originador de manera que pueda solicitar la reserva de recursos a la siguiente alternativa desde su tabla de requerimiento. 2.2.6. Protocolos de encaminamiento geográficos En este tipo de algoritmos, el nodo transmisor envía paquetes usando la localización geográfica del nodo destino en vez de su dirección de red. Por tanto, no es esencial tener el conocimiento global de la topología de la red, lo cual repercute en una menor carga de tráfico de control. Más aún, muchos de los algoritmos de encaminamiento geográfico son escalables y tolerantes a fallos, a pesar que su rendimiento depende en gran medida de la exactitud y antigüedad de la información de ubicación de los nodos, lo cual puede estar no disponible en muchos escenarios de aplicación. LBCR [188] y LANDY [149] son dos algoritmos de esta categoría. El término geodifusión (del in- 40 Mecanismos para hacer frente a la movilidad en las redes inalámbricas ad-hoc glés geocasting) es usado para algoritmos que permiten que los paquetes sean enviados desde el nodo fuente hacia un grupo de nodos destinos usando solamente su información de localización geográfica, como en el caso de GeoTORA [119]. En lo que sigue analizaremos un protocolo de cada categoría (LANDY y GeoTORA) para ilustrar su funcionamiento. Local area network dynamic routing protocol (LANDY) LANDY [149] es un protocolo geográfico que hace uso de la información de locomoción (posición, velocidad y dirección) de los nodos para encaminar los paquetes. Este protocolo asume que los nodos tienen acceso a un servicio de localización y que están equipados con dispositivos GPS, lo que les permite conocer su propia ubicación y la del nodo destino. La posición de los vecinos son determinadas a través de la difusión periódica de mensajes HELLO con los datos de su locomoción. Estos mensajes están limitados en su alcance a un salto. En el proceso de retransmisión de los paquetes, cada nodo hace uso de esta información para seleccionar al nodo que se acerque más a la posición del destino como el próximo salto de ese paquete. Este proceso se repite en cada salto hasta alcanzar al destino. GeoTORA GeoTora [119] mantiene una estructura de enlaces lógicos dirigidos para alcanzar a alguno de los nodos ubicados dentro de una región específica (grupo de geocast). A cada nodo se le asigna un peso relacionado con su cercanía (en número de saltos) a la región: inicialmente NULL para aquellos fuera de ella y cero para el resto. Los enlaces lógicos de los nodos que pertenecen al grupo de geocast no tienen una dirección específica debido a que dentro de la zona los paquetes que llegan a algún nodo son difundidos entre los miembros del grupo. Siguiendo la secuencia mostrada en la red de la figura 2.9(a), los nodos fuera de la región y que se encuentran a un salto de distancia de la zona (nodos C y F ), orientan sus enlaces lógicos salientes con dirección a la zona de geocasting (instante t1), valiéndose del hecho que el valor NULL asignado a su peso es considerado mayor a cualquier otro valor. En el instante t2, cuando un nodo (por ejemplo, A) desea enviar datos a la región, y dado que no tiene un enlace de salida, difunde un paquete QRY (del inglés query) a sus vecinos y configura una bandera de ruta solicitada. Este paquete llega a los nodos B y E (instante t3) quienes, a su vez, lo pasan a sus vecinos (D, C y F ) y activan sus banderas correspondientes. El nodo D hace lo propio al recibir el mensaje, en t4; sin embargo, los nodos C y F al tener ya un enlace lógico saliente no difunden el QRY sino que modifican el valor de su peso de NULL a 1 y envían un mensaje UPD (del inglés update) a sus vecinos informando del cambio (instante t5). Sobre la recepción del UPD por los vecinos, estos cambian su peso al siguiente valor, por ejemplo los nodos B, D y E pasan a 2 y asignan la dirección a sus enlaces lógicos salientes dirigiéndolos de manera que las rutas hacia la región sean decrecientes. Finalmente, en t6, el nodo A recibe un UPD desde B y E pasando su peso a 3 y actualizando la dirección de sus enlaces lógicos como se muestra en la figura 2.9(b). En caso que algún nodo se quede sin enlaces lógicos salientes debido a su fallo, envía paquetes UPD a sus vecinos para reestructurar la dirección de los enlaces de manera tal que pueda acceder a la zona a través de otro camino. 2.2 Mecanismos de encaminamiento para MANETs 41 B A E (a) Propagación de los paquetes QRY en la red. (b) Propagación de los paquetes UPD y asignación de direcciones a los enlaces lógicos. Figura 2.9: Generación de la ruta anycast en GeoTORA. Una vez establecida la ruta, un nodo con paquetes para el grupo de geocast los envía a través de alguno de sus enlaces lógicos de salida disponibles. Cada nodo intermedio recibiendo este paquete, lo retransmite por uno de sus enlaces de salida. Eventualmente el paquete alcanzará a alguno de los nodos en la zona de geocasting que a su vez lo difundirá al resto de miembros. 2.2.7. Protocolos de encaminamiento multitrayecto Consiste en la creación (proactivamente o bajo demanda) de múltiples rutas desde la fuente al destino, en vez de considerar una sola ruta. Descubrir múltiples trayectos sirve para prevenir puntos únicos de fallo y balancear el uso del ancho de banda a través de la red, típicamente a expensas de un mayor consumo de memoria y carga de tráfico de control debido a las tareas de mantenimiento de ruta. Ejemplos de encaminamiento multitrayecto incluyen a AOMDV [156], SMR [129], OMR [70]; esto es también una opción común en encaminamiento geográfico como con GAODM [248]. Dado que los principios de funcionamiento de estos protocolos son similares, únicamente describiremos a AOMDV y GAODM. 42 Mecanismos para hacer frente a la movilidad en las redes inalámbricas ad-hoc Ad-hoc on demand multipath vector routing (AOMDV) Este protocolo es una modificación de AODV [184] para calcular múltiples trayectos libres de bucles y con enlaces disjuntos. En AOMDV [156], a diferencia de AODV, cada entrada en la tabla de encaminamiento contiene una lista con los próximos saltos y el número de saltos de los múltiples caminos descubiertos a ese destino, un número de secuencia, el máximo número de saltos de todos los caminos disponibles en el nodo a ese destino (número de saltos anunciado) y un tiempo de validez de la entrada. Para evitar la presencia de bucles, un nodo aceptará una ruta alternativa al destino solo si esta tiene un número de saltos menor que el valor del número de saltos anunciado para ese destino. AOMDV se puede utilizar para encontrar trayectos con nodos disjuntos o enlaces disjuntos. A diferencia de AODV, las copias de los paquetes RREQ recibidos por los nodos no son descartadas directamente. En primera instancia, se analiza si estos paquetes provienen desde rutas con nodos disjuntos a las rutas de los paquetes previamente recibidos —se hace uso de información adicional provista en los RREQ— y si el nodo posee una ruta válida hacia el nodo destino. Si se cumplen estas condiciones, un paquete RREP es enviado de regreso al nodo fuente; en caso contrario, solo el primer RREQ recibido es difundido nuevamente. En el destino —a la espera de obtener rutas con enlaces disjuntos—, por cada RREQ proveniente de nodos disjuntos, un RREP es enviado de vuelta al nodo fuente siguiendo su misma ruta. Geography based ad hoc on demand disjoint multipath (GAODM) GAODM [248] asume que cada nodo conoce su posición, usando sistemas GPS (del inglés Global Positioning System); la de sus vecinos, a través del intercambio periódico de mensajes de información de distancia; y la del nodo destino, mediante algún servicio de localización. Dos tipos de rutas pueden ser encontradas, con nodos y enlaces disjuntos. Cada nodo en la red mantiene una lista de vecinos con su localización. Los nodos involucrados en el proceso de descubrimiento generan una tabla de vecinos candidatos (CNT, del inglés Candidate Neighbor Table) con campos que registran los IDs de la fuente, destino y del RREQ; así como la lista de los vecinos a los cuales un particular RREQ puede ser enviado (CL, del inglés Candidate List) —esta lista inicialmente incluye todos sus vecinos. Por su parte, el paquete RREQ lleva una lista con los vecinos que se espera reciban o reenvíen ese mensaje (NHL, del inglés Next Hop List). Cuando un nodo S desea comunicarse con D, calcula la distancia Euclidiana desde cada vecino al destino, selecciona los k nodos más cercanos (con k ≤ que el número de vecinos) y registra su ID en el campo NHL del RREQ, y luego lo difunde. Los nodos intermedios que reciben o escuchan un RREQ, revisan su tabla CNT por una ruta para ese paquete, borrando del CL todos los IDs de los nodos que se encuentren presentes en la NHL del RREQ recibido, excepto el del destino. Si la lista de candidatos no está vacía y el nodo es parte de la lista de próximo salto del RREQ (no es un paquete duplicado), identifica en su CL al vecino más cercano a D, actualiza el NHL con esa dirección y reenvía este paquete; en caso contrario, es descartado. La tabla de encaminamiento de los nodos, a más de los IDs de los nodos fuente, destino y la distancia a este, posee campos en los que se registran el próximo salto y el último salto desde donde se recibe un RREQ; esta ruta es configurada como inválida, a la espera de una confirmación. En el destino, por cada RREQ que recibe, envía de vuelta un RREP a través de la ruta 2.2 Mecanismos de encaminamiento para MANETs 43 descubierta, validando las rutas en los nodos intermedios. Este proceso garantiza que los diferentes RREQ que llegan al nodo D son disjuntos. En el caso de querer obtener enlaces disjuntos, los paquetes RREQ duplicados no son eliminados. Cuando un nodo intermedio recibe otro RREQ desde un vecino diferente, este reenvía el paquete siempre que su lista CL no esté vacía. El proceso de reenvío es el mismo que cuando se descubren rutas con nodos disjuntos; sin embargo, el último nodo vecino al destino solo retransmite el primer RREQ que recibe y descarta los siguientes. Los trayectos así obtenidos son disjuntos, dado que los RREQ que llegan al destino van por diferentes enlaces debido a que un nodo no reenvía un RREQ recibido desde un mismo vecino. 2.2.8. Protocolos de encaminamiento basados en la potencia En las decisiones de encaminamiento se considera la disponibilidad de energía de los nodos con la finalidad de maximizar el tiempo de vida de la red (una importante consideración en las redes de sensores). Este objetivo puede ser mucho más complicado que simplemente encontrar la ruta más corta desde el origen al destino, porque es necesario tener en cuenta la heterogeneidad de los recursos energéticos de los nodos, el consumo de energía irregular debido a la topología de red y la naturaleza de los flujos de datos. Ejemplos de protocolos de encaminamiento basados en la potencia son DEAR [19] y PARO [86]. Device and energy aware routing protocol (DEAR) En DEAR [19] se considera la presencia en la red de dos tipos de dispositivos: nodos energizados externamente y nodos energizados a través de baterías internas. La idea principal de este protocolo es redirigir los paquetes de datos hacia los nodos energizados externamente, ya que se les otorga un coste cero. Además se asume que esta clase de nodos tienen la capacidad de incrementar su potencia de transmisión para alcanzar a cualquier otro en la red. En este proceso, DEAR incorpora en el algoritmo de encaminamiento Distributed Bellman-Ford (DBF) una función de coste basada en el recíproco de la energía residual del nodo (la energía inicial del nodo menos la que ha gastado hasta el momento). No obstante, para disminuir la sobrecarga de tráfico de control, las actualizaciones de encaminamiento son desarrolladas en forma periódica y no cada vez que ocurren cambios en los valores de los enlaces. Cada nodo en la red mantiene dos tablas, una de encaminamiento, con campos que contienen la dirección del nodo destino, coste de transmisión (en términos de energía), próximo salto y clase del dispositivo de destino (energizado interna o externamente); y otra de redireccionamiento, con la dirección del destino y la necesidad o no de redirigir un paquete. Siempre que la tabla de encaminamiento es actualizada, el nodo determina el trayecto con menor coste C a un nodo energizado externamente (nodo P ). Las entradas en la tabla de redireccionamiento con un coste mayor a C son marcadas para ser redirigidas a P . Cuando un nodo recibe un paquete para ser reenviado, primero busca en su tabla de redireccionamiento para verificar si está marcada para ser redirigida; si es así, el nodo lo reenvía a P , en caso contrario, el paquete es reenviado al siguiente nodo de acuerdo con su tabla de encaminamiento. 44 Mecanismos para hacer frente a la movilidad en las redes inalámbricas ad-hoc Dynamic power controlled routing (PARO) PARO busca minimizar la potencia de transmisión necesaria para enviar paquetes entre dos nodos en la red. Se asume que los nodos tienen dispositivos de radio capaces de ajustar su potencia de transmisión de forma dinámica, de acuerdo a los requerimientos del protocolo. En el proceso de encaminamiento de los paquetes, PARO no mantiene a priori rutas para cada uno de los nodos en la red, sino que descubre estas rutas nodo por nodo y bajo demanda. En este proceso, los mismos paquetes de datos son usados para descubrir la ruta hacia el destino. En la cabecera de los paquetes, los nodos cargan la potencia usada para transmitirlos, de forma que otros nodos escuchando esa transmisión usan esa información y la medida de la potencia recibida para calcular la mínima potencia de transmisión necesaria para alcanzar al nodo transmisor. Se usan dos tablas en el proceso de encaminamiento. La primera contiene los datos de los nodos vecinos escuchados y la segunda está formada por los nodos de próximo salto hacia un destino determinado; estos nodos son denominados redirectors. En cada nodo, el paquete escuchado es analizado para determinar si al redireccionar la ruta a través de ese nodo se puede disminuir el uso de potencia. De ser ese el caso, el nodo informa a los nodos intervinientes en la comunicación para que redirijan sus paquetes a través de él. En primera instancia, si el nodo transmisor no tiene conocimiento de la potencia necesaria para transmitir datos al nodo destino transmitirá con la máxima potencia. Luego de ello, los nodos escuchando estos paquetes actuarán de la forma descrita previamente hasta converger a la mínima potencia posible. 2.2.9. Protocolos de encaminamiento basados en inteligencia de enjambre (SI) Estos protocolos están inspirados en el comportamiento colectivo y social de insectos como hormigas y abejas. Típicamente, estos algoritmos usan agentes para explorar la red, recolectar información y, o bien dejar huellas en las tablas de encaminamiento de los nodos por los que atraviesan o compartir la información recolectada con otros agentes. Los ejemplos más relevantes de algoritmos basados en enjambres son ARA [88], ANSI [190], SAMP-DSR [116], ODASARA [191] y BeeAdHoc [235]. Para ilustrar sus principios de funcionamiento, en lo que sigue, describiremos los protocolos ARA y BeeAdHoc. Ant-colony-based routing algorithm (ARA) Este algoritmo se basa en el comportamiento de las hormigas durante la búsqueda de comida. En este proceso, las hormigas hacen uso de una sustancia denominada feromona para dejar rastros en el camino que han utilizado para llegar a la comida. Debido a que la intensidad de esta sustancia disminuye con el tiempo, los caminos más cortos poseen una mayor concentración y son utilizadas por otras hormigas para localizar la comida. ARA hace uso de esta idea para desarrollar el proceso de encaminamiento en las MANETs. Tres fases son empleadas en este algoritmo: descubrimiento de ruta, mantenimiento y gestión de errores de ruta. En el proceso de descubrimiento de ruta, se utilizan dos clases de paquetes: FANT (del inglés Forward Ant) y BANT (del inglés Backward Ant). Al igual que en el caso de las hormigas, los paquetes FANT son los encargados de encontrar el destino y dejar rastros (feromona) en cada uno de los nodos por los que atraviesan. En la figura 2.10(a), 2.2 Mecanismos de encaminamiento para MANETs 45 E C G A L J I B N K D M F H (a) Propagación de los mensajes FANT. E C B G A D F H (b) Propagación de los mensajes BANT. Figura 2.10: Proceso de descubrimiento de ruta con ARA. el nodo S desea comunicarse con D, al no tener una ruta establecida, genera un FANT y lo difunde en la red hasta alcanzar al destino. La primera vez que un nodo recibe un FANT, crea en su tabla de encaminamiento un registro con la dirección del destino, el próximo salto y el valor de la feromona. En el nodo destino D, una vez extraída la información de encaminamiento, el FANT es eliminado; se genera un paquete BANT y se lo envía a la fuente. Al igual que el FANT, este paquete deja un rastro, pero hacia la fuente. A diferencia del FANT que solo deja un rastro de feromona hacia el nodo fuente, el BANT puede dejar más de un rastro, por lo que ARA puede soportar múltiples trayectos. En el caso de la figura 2.10(b), el nodo J tiene dos caminos hacia D, a través de lo nodos L y K. Cuando el nodo fuente recibe el BANT desde el nodo destino, el trayecto es establecido y los paquetes de datos pueden ser enviados. El mantenimiento de ruta se desarrolla usando los mismos paquetes de datos. Las rutas disminuyen progresivamente el valor de la feromona si no hay paquetes de datos para esas rutas y, por el contrario, incrementan su valor cuando llegan paquetes para esas entradas. Si los nodos reciben paquetes de datos duplicados, activan una bandera denominada DUPLICATE_ERROR y envían de vuelta el paquete al nodo precedente. De esta forma, el nodo previo desactiva este enlace para que no se pueda enviar nuevos paquetes a través de ese salto. Para gestionar los errores de las rutas, los nodos hacen uso de mensajes de error de ruta. Cuando un nodo recibe uno de estos paquetes, desactiva el enlace con error, estableciendo su valor de la feromona a cero. Luego de ello, el nodo busca en su tabla de encaminamiento una ruta alternativa, si la encuentra hace uso de ella para enviar el paquete; de lo contrario, informa a sus vecinos con rutas válidas para que lo retransmitan. De no existir un trayecto al destino, el proceso pue- 46 Mecanismos para hacer frente a la movilidad en las redes inalámbricas ad-hoc de continuar hasta alcanzar el nodo origen, quien iniciará un nuevo descubrimiento de ruta. BeeAdHoc Este algoritmo está inspirado en los principios de alimentación de una colonia de abejas. BeeAdHoc [235] modela este comportamiento a través de cuatro clases de agentes: empacadores, exploradores, recolectores y enjambres. Los empacadores residen en el nodo, recibiendo y almacenando los paquetes de datos desde la capa de transporte. Ellos son los encargados de encontrar un agente recolector para esos paquetes, luego de lo cual son eliminados. Los exploradores, por su parte, descubren las rutas entre su nodo y un destino. Estos paquetes, con un identificador único y un número de saltos máximo, son difundidos en la red. Todas las copias que alcanzan el destino son enviadas de vuelta siguiendo sus respectivas rutas para asegurar el descubrimiento de múltiples trayectos. Cada explorador que regresa a su nodo origen escoge un recolector para su ruta. Los recolectores son los encargados de recibir los paquetes de datos desde los empacadores y transportarlos a sus destinos. Estos agentes son de dos tipos: los recolectores de retardo, que obtienen información de retardo desde la red; y los recolectores de tiempo de vida que hacen lo propio con la información de la capacidad de batería remanente de los nodos que atraviesan. Los primeros tratan de encaminar sus paquetes por las rutas con mínimo retardo; mientras que los otros buscan las rutas que incrementen el tiempo de vida de la red. Estos agentes siguen las rutas establecidas por los exploradores o por algún otro recolector. Cuando llegan a su destino son mantenidos en él por un tiempo determinado hasta que pueden ser transportados de vuelta usando el tráfico de red desde el destino a su nodo fuente (por ejemplo, utilizando los paquetes ACK de TCP). En el caso de no tener una forma implícita de retorno (como cuando se usa UDP en la capa de transporte), BeeAdHoc emplea los agentes enjambre para ese propósito. Cuando el número de recolectores de un nodo i presentes en el nodo destino j supera un determinado umbral, un agente de enjambre es enviado por j con uno de esos recolectores como cabecera del paquete y el resto como parte de su carga. Una vez en el nodo origen, estos agentes son extraídos y almacenados en el orden en el que hubieran arribado de forma normal. En cada nodo, el BeeAdHoc se estructura como una colmena con tres pisos: empaquetado, danza y entrada. El piso de empaquetado es la interfaz a la capa de transporte, mientras que el de entrada lo es con la capa de acceso al medio. El piso de danza (en referencia la danza de la abejas) es donde se toman decisiones de encaminamiento con la llegada de los agentes de recolección. Por ejemplo, cuando se genera un paquete desde la capa de aplicación, un empacador es creado para que busque un recolector adecuado para ese paquete. Si es que hay alguno, el paquete es entregado a este para ser llevado al destino y el empacador es eliminado; en caso contrario se espera un tiempo determinado por un recolector regresando de su viaje, si no arriban en ese tiempo, se envía un explorador para descubrir una nueva ruta. Cuando llega un recolector después de su viaje, recluta nuevos recolectores acorde a la calidad de su ruta, por lo que si hay nuevos paquetes se generan clones de este. Si el último recolector hacia un destino sale del nodo, este queda sin una ruta hacia él. No obstante, si la ruta está activa, el recolector debería retornar dentro de un determinado tiempo; de no ser así se da la ruta por perdida por lo que se generará un nuevo explorador, evitando el incremento de la sobrecarga de paquetes para el control y mantenimiento de los enlaces y la corrección de errores. 2.3 Mecanismos de encaminamiento para VANETs 47 Para concluir nuestro estudio de los mecanismos de encaminamiento para MANETs, en la tabla 2.3 prestamos un resumen con las principales características de los protocolos estudiados en esta sección. Características Reactivos (R) / proactivos (P) / híbridos (H) / geográfico (G) Plano (F) / jerárquico (J) Sobrecarga de tráfico de control alta (H) baja (L) / media (Md) Trayecto simple (S) / multitrayecto (M) Basado en potencia Best effort (B) / QoS (Q) Reactivos (R) / proactivos (P) / híbridos (H) / geográfico (G) Plano (F) / jerárquico (J) Sobrecarga de tráfico de control alta (H) baja (L) / media (Md) Trayecto simple (S) / multitrayecto (M) Basado en potencia Best effort (B) / QoS (Q) Protocolos de encaminamiento DSDV OSLR FSR DSR AODV ZRP ZHLS HSR CEDAR P P P R R H H H H F H F H F H F Md F Md F Md J Md J Md J Md S No B S No B S No B S No B S No B S No B S No B S No B S No Q DCMP AQM LANDY GeoTORA AOMDV GAODM DEAR PARO ARA BeeAdHoc R R G G-R R G P R R R F Md F Md F L F Md F Md F Md F Md F Md F Md F M No B S No Q M No B M No B M No B M No B S Si B S Si B M No B M No Q Tabla 2.3: Características de los protocolos de encaminamiento para MANETs 2.3. Mecanismos de encaminamiento para VANETs Al igual que en las redes móviles ad-hoc, los mecanismos de encaminamiento en las redes vehiculares ad-hoc han generado mucho interés en la comunidad científica, produciendo una gran cantidad de propuestas durante las últimas décadas [71, 128]. Muchos de los protocolos de encaminamiento diseñados para las MANETs (e.g., AODV, OLSR, DSR,... revisados en la sección 2.2) han sido propuestos para ser utilizados en escenarios vehiculares. Sin embargo, estos protocolos, tal como fueron diseñados, no son apropiados para los entornos vehiculares [179], debido a la naturaleza dinámica de las VANETs que les impone una serie de retos y restricciones mucho más demandantes que las MANETs: Topología altamente dinámica. La alta movilidad de los vehículos hace que la topología de las red esté en constante cambio, produciendo enlaces de mucha menor duración que en las MANETs. Conectividad intermitente. La alta variabilidad de la topología genera redes con desconexiones frecuentes. Debido a la movilidad de los nodos, los enlaces pueden desaparecer rápidamente. Esto, además, es exacerbado por la variabilidad en la densidad de los nodos, ya que dependiendo del tiempo y del lugar habrá una mayor o menor cantidad de vehículos. Patrones de movilidad. A diferencia de los nodos en las MANETs, los patrones de movilidad de los vehículos se rigen en función de restricciones como el trazado de las calles, las luces de los semáforos, las normas de tránsito y el comportamiento de los conductores. Modelo de propagación. La presencia de edificios, árboles y otros vehículos en los escenarios VANETs hace que el modelo de propagación de espacio libre no sea adecuado para la evaluación de las comunicaciones en este tipo de redes. 48 Mecanismos para hacer frente a la movilidad en las redes inalámbricas ad-hoc Capacidad de potencia y almacenamiento ilimitado. Una ventaja importante de los dispositivos en las redes vehiculares con respecto a las MANETs es que en este tipo de redes se considera que los nodos no tienen restricciones de energía y poseen una mayor capacidad de procesamiento. Uso de sensores a bordo. Los vehículos modernos están equipados con una serie de sensores que les permiten tener información de su posición (mediante sistemas de posicionamiento global, GPS), dirección y velocidad. La topología de las calles también es conocida a través de mapas digitales integrados en los sistemas de comunicación a bordo. Los protocolos de encaminamiento en VANETs pueden ser clasificados en las siguientes categorías (ver figura 2.11): basados en topología, geográficos, jerárquicos, basados en intersecciones y tolerantes al retardo. En lo que sigue de esta sección, describiremos las características más importantes de cada categoría junto con algunos de los protocolos más representativos. Basados en topología PBR RBVT ARBR Geográficos GPSR GSR A-STAR GVGrid IGRP Jerárquicos GyTAR RTRP PassCAR Basados en intersecciones Tolerantes al retardo RCBR iCAR VADD GeOpps IBR Figura 2.11: Clasificación de los protocolos de encaminamiento en VANETs. 2.3.1. Protocolos de encaminamiento basados en topología En este grupo aparecen muchos de los protocolos reactivos y proactivos propuestos para las MANETs y que han sido utilizados o modificados para ser adaptados a los escenarios VANETs. OLSR [108], DSDV [185], FSR [183], PBR [170], RBVT-R [177] y S-RCBR [34] son ejemplos de algoritmos reactivos. Por su parte, entre los algoritmos proactivos tenemos a DSR [112], AODV [184], RBVT-P [177], D-RCBR [33] y ARBR [18]. Prediction based routing (PBR) Este protocolo es desarrollado para comunicaciones desde un nodo móvil (vehículo) a cualquier nodo fijo (pasarela) que dé acceso al servicio buscado. En el proceso de descubrimiento, la red es inundada con paquetes de solicitud de ruta (RREQ). Los nodos pasarela que reciben los paquetes RREQ responderán con un paquete de respuesta de ruta (RREP). Si múltiples paquetes RREP llegan al nodo fuente, este prioriza la elección de la ruta en función del número de saltos y su dirección. Por su parte, el mecanismo de mantenimiento de ruta se basa en la predicción del tiempo de vida de cada trayecto. Aunque los automóviles tienen alta velocidad y cambian rápidamente de dirección, su movimiento aún es predecible. Para ello, durante su 2.3 Mecanismos de encaminamiento para VANETs 49 recorrido hacia la fuente, los paquetes RREP recolectan datos de velocidad y aceleración de los nodos. La fuente, en base a esos datos, predice el tiempo de vida de los trayectos, lo que le permite descubrir y establecer nuevas rutas antes de que se produzca la ruptura de los enlaces. Road based using vehicular traffic (RBVT) Este protocolo presenta dos versiones [177]: una reactiva RBVT-R y otra proactiva RBVT-P. En su versión reactiva, al igual que en otros protocolos de este estilo, RBVT inunda la red con mensajes de solicitud de ruta (RREQ). Tan pronto como el nodo destino recibe la solicitud de descubrimiento, envía un paquete de respuesta de ruta (RREP) por el camino establecido. En caso de ruptura de algún enlace, los nodos intermedios informan al nodo fuente, quien pone en cola los paquetes de datos hasta que el camino sea restablecido. Si no se puede corregir el fallo del enlace, el nodo fuente iniciará un nuevo proceso de descubrimiento de ruta. En la versión proactiva, RBVT-P hace uso de información de tiempo real para seleccionar el camino con mayor probabilidad de conectividad. Los paquetes de conectividad (CP, del inglés Connectivity Package) recolectan información de los segmentos de vía3 e intersecciones por donde cruzan. Estos paquetes son generados de forma aleatoria por los nodos de la red en función del número estimado de vehículos, información histórica del tráfico en cada hora y el intervalo de tiempo transcurrido desde el último CP recibido. Los datos recogidos por el CP son extraídos y cargados en un paquete de actualización de ruta, el cual es difundido a todos los nodos en el área cubierta por el CP. Cuando un nodo tiene datos para transmitir, calcula el trayecto más corto al destino usando solo aquellos segmentos de vía que están marcados como alcanzables en su tabla de encaminamiento. Dicha ruta se establece como una secuencia de intersecciones entre los nodos fuente y destino y es insertada en la cabecera del paquete de datos. Los nodos intermedios, con información más reciente, pueden actualizar el trayecto seleccionado. En caso de una ruptura del enlace, el nodo pasa a un modo de encaminamiento geográfico (i.e., se selecciona el próximo salto que esté más cerca al destino) hasta que el paquete alcance un nuevo nodo con información más reciente y se pueda establecer una nueva ruta. Para mejorar la retransmisión de los paquetes, solo los nodos más lejanos son seleccionados como próximo salto. Para ello, antes de reenviar un paquete, un nodo espera un tiempo proporcional a la distancia al nodo del cual lo recibe. Si durante ese tiempo no lo han retransmitido, el nodo considera que es el más lejano y procede con su envío; en caso contrario, lo descarta. Adaptative road based routing (ARBR) ARBR [18] es diseñado para trabajar en un contexto donde la fuente es móvil y el destino es fijo (estación base). Al igual que otros protocolos reactivos, el proceso de descubrimiento inicia con la inundación de paquetes de solicitud de ruta (RREQ). Cuando la estación base recibe un RREQ envía de vuelta al nodo fuente un paquete de respuesta de ruta (RREP), insertando el camino descubierto en su cabecera. En el caso de que lleguen nuevos paquetes RREQ, la estación base generará un nuevo RREP 3 Un segmento de vía corresponde a la porción de calle entre dos intersecciones. 50 Mecanismos para hacer frente a la movilidad en las redes inalámbricas ad-hoc siempre que presente un retardo menor o bien cuando el vehículo fuente ha cambiado de segmento de vía. Para el mantenimiento de ruta, los nodos intermedios comparan los segmentos de los trayectos del RREQ y del RREP, de modo que se actualizará el segmento del lado RREQ si se detecta un cambio, puesto que se considera que RREP tiene una visión más actualizada de la red. 2.3.2. Protocolos de encaminamiento geográficos Al igual que en las MANETs, los protocolos de encaminamiento geográficos se basan en información de la posición del nodo destino y de los nodos vecinos, la cual es obtenida a través de sistemas GPS, servicios de localización y/o anuncios periódicos difundidos en la red [30]. Estos datos permiten que los paquetes puedan ser encaminados directamente sin necesidad de conocer la topología de la red o iniciar procesos de descubrimiento. GPRS [114], GSR [141], A-STAR [138], GVGrid [219] e IGRP [203] son ejemplos de este tipo de protocolos. Greedy perimeter stateless routing (GPSR) GPRS [114] toma las decisiones de retransmisión de paquetes basado en la localización del nodo y del destino del paquete. Este protocolo asume que la ubicación del nodo destino es conocida a través de algún servicio de localización. Se utilizan dos mecanismos de retransmisión de paquetes: greedy forwarding y el modo perímetro. En el mecanismo greedy forwarding, los nodos intermedios retransmiten los paquetes al nodo vecino más cercano a la ubicación del destino. Cuando un nodo intermedio no tiene nodos vecinos más cerca al destino que él y, por tanto, no puede seguir retransmitiendo el paquete, se dice que ese nodo es un máximo local. En escenarios urbanos, la presencia de edificios pueden ayudar a ocultar los retransmisores óptimos, incrementando la frecuencia de este problema [25]. En un máximo local, el protocolo de encaminamiento cambia a modo perímetro, en el cual la regla de la mano derecha es usada para enviar el paquete al siguiente salto. Cuando un nodo x ejecuta el modo perímetro, un vector virtual es trazado desde este nodo al destino D. El nodo x reenviará el paquete al primer nodo alcanzable en el sentido horario desde el vector, sin que lo intercepte. Luego de ello, el paquete retorna a greedy forwarding para ser retransmitido al siguiente nodo más cercano a D. Si se produce un bucle, el paquete es eliminado. Geographic source routing (GSR) GSR [141] inunda la red con paquetes de solicitud de ruta (RREQ) para encontrar la posición del nodo destino; puesto que, a diferencia de GPSR [114], este protocolo no asume tener conocimiento de su localización. Tan pronto como el nodo destino recibe el RREQ, responde al nodo fuente con su posición. Usando esta información y un mapa digital de las calles, el nodo fuente calcula la ruta más corta, constituida por una secuencia de intersecciones, que será usada en el encaminamiento de los paquetes de datos. Finalmente, los paquetes son enviados de intersección a intersección hasta alcanzar el destino. En cada segmento de vía, se usa el mecanismo de greedy forwarding para la retransmisión nodo a nodo. 2.3 Mecanismos de encaminamiento para VANETs 51 Anchor based street and traffic aware routing (A-STAR) A-STAR [138] usa la información de la programación de las rutas de las líneas de autobuses y del estado del tránsito para determinar la secuencia de puntos de anclaje (intersecciones) por donde los paquetes deben pasar hacia el destino. Este protocolo considera que las calles por donde transitan los autobuses presentarán un mayor grado de conectividad. Mapas digitales con información estadística de las rutas de los autobuses o con información dinámica del tránsito —dependiendo de la hora, algunas calles presentan una mayor o menor densidad vehicular— son usados para determinar la conectividad de las calles y establecer un peso para cada una de ellas (cuantos más vehículos menos peso y viceversa). Puesto que a menor peso se espera una mayor conectividad, se selecciona la secuencia de intersecciones con menor peso. Si durante la transmisión de paquetes un máximo local se presenta, se calcula un nuevo trayecto. Se marca a la intersección donde ocurrió el máximo local como fuera de servicio y se comunica de su situación a los nodos en la red o simplemente se incluye esta información en el paquete de datos recuperado. GVGrid GVGrid [219] encuentra rutas desde un nodo fuente (fijo o móvil) a vehículos en una zona geográfica determinada, utilizando mapas digitales y sistemas GPS para obtener información de la posición y dirección de los nodos. Este protocolo basado en posición divide el área geográfica de difusión en cuadrados de igual tamaño. En la fase de descubrimiento, GVGrid inunda la red con paquetes de solicitud de ruta (RREQ). Para limitar su alcance, los paquetes son difundidos dentro de una zona de solicitud que corresponde al área rectangular más pequeña que contiene al nodo fuente y destino; su ancho es un compromiso entre el número de paquetes RREQ y las potenciales rutas a ser encontradas. El próximo salto del RREQ es seleccionado considerando factores tales como posición, dirección de movimiento y cercanía a la intersección de los potenciales candidatos en la cuadrícula adjunta. El objetivo es descubrir una ruta de encaminamiento a lo largo del mapa de vías que contenga la menor cantidad de calles e intersecciones, ya que se prevé que en estos trayectos hay una mayor probabilidad de que los vehículos mantengan sus velocidades y direcciones y, por tanto, una menor tasa de desconexiones. Los mensajes RREQ contienen una ruta de red que consiste en una secuencia de identificadores de nodos; un mapa de ruta formado por una secuencia de identificadores de segmentos de vía y una secuencia de cuadrículas sobre la cual la ruta de red existe. Esta información es usada por un nodo en la cuadrícula de destino para escoger el mejor trayecto y por los nodos intermedios para reponerse en caso de un fallo de ruta. Cuando un RREQ llega a un nodo d′ , en una cuadrícula vecina a la del destino d, se le asigna a este nodo el identificador más pequeño de la cuadrícula de d antes de retransmitir el RREQ. Este nodo es denominado como nodo representativo de d. Dado que múltiples mensajes de RREQ pueden llegar al nodo d′ después de atravesar diferentes caminos por la red, la mejor de esas rutas deberá ser escogida en función de la calidad del mapa de ruta cargado en cada RREQ. La ruta seleccionada es aquella que provee el mayor tiempo de vida esperado y por tanto la menor tasa de desconexiones, la cual es calculada en función de parámetros como el tiempo de conmutación de las luces de señalización de los semáforos, la probabilidad de que un vehículo al salir de una intersección se encuentre dentro de la ruta establecida y del número de desconexiones 52 Mecanismos para hacer frente a la movilidad en las redes inalámbricas ad-hoc de enlace en base a la velocidad de los nodos. Sobre la ruta escogida, un mensaje de respuesta (RREP) es enviado al nodo fuente, para que inicie la transmisión de datos. Intersection-based geographical routing protocol (IGRP) IGRP [203] busca seleccionar una secuencia de intersecciones a través de la cual un paquete alcance algún nodo pasarela (GW, del inglés Gateway) en la infraestructura que le permita acceder a Internet. Este protocolo asume que los vehículos conocen su ubicación a través de sistemas de posicionamiento (GPS) o servicios de localización, y mapas digitales. Los nodos pasarela mantienen una visión actualizada de la topología local de la red. Para ello, cada vez que el vehículo se aleja de su posición previa una distancia mayor a su rango de transmisión, envía un reporte al GW con su nueva localización. Esta información permite que el GW calcule un conjunto de rutas entre los nodos móviles y él para ofrecer la mayor probabilidad de satisfacer la calidad de servicio (QoS) requerida. Si un nodo fuente desea una ruta hacia GW, primero consulta a los nodos vecinos; si alguno de ellos tiene un trayecto establecido para las mismas condiciones de QoS, responde con la información solicitada; en caso contrario, el nodo fuente procede a realizar la consulta directamente al GW. 2.3.3. Protocolos de encaminamiento jerárquicos En este tipo de protocolos, los nodos (vehículos o dispositivos en la infraestructura) presentes dentro de una área de agrupamiento (cluster) escogen un nodo líder (CH, del inglés cluster head), el cual coordina y difunde los paquetes de datos del resto de nodos miembros del cluster. GyTAR [109], RTRP [97] y PassCAR [231] son ejemplos de este tipo de protocolos. Greedy traffic aware routing protocol (GyTAR) GyTAR [109] se fundamenta en una estructura de cluster. Para ello, las calles entre dos intersecciones son divididas en celdas. El nodo más cercano al centro de cada celda (punto de anclaje) es denominado nodo líder. Dentro de cada celda, cada nodo periódicamente envía mensajes con información de su localización, velocidad y dirección. Para calcular la densidad de vehículos y su desviación estándar promedio en el segmento de vía, el nodo líder que abandone el segmento envía un paquete de densidad de celda (CDP, por sus siglas en inglés Cell Density Package) a los otros nodos líderes dentro del mismo segmento de vía. Cada nodo líder actualiza el CDP con los datos de su celda. El nodo líder del cluster ubicado en la entrada del segmento de vía difunde la información del CDP a los vehículos presentes en la intersección. Los paquetes son encaminados de intersección a intersección a través de las calles que más se acerquen al destino y que tengan la mayor densidad vehicular. La retransmisión nodo a nodo, en cada segmento de vía, se realiza a través de un mecanismo de greedy forwarding mejorado. Cada vehículo, a través de la emisión periódica de mensajes HELLO, mantiene una tabla con información de velocidad, dirección y posición de sus vecinos. Esta información permite al nodo retransmitiendo el paquete predecir la próxima posición de sus vecinos y seleccionar aquel más cercano a la intersección de destino. En caso de un máximo local, una estrategia de carry and forwarding es usada: el vehículo llevará el paquete hasta la próxima intersección o hasta que otro nodo más cerca de la intersección de destino esté dentro de su rango de transmisión. 2.3 Mecanismos de encaminamiento para VANETs 53 Road and traffic aware routing (RTRP) Al igual que GyTAR, RTRP [97] se basa en una estructura de cluster. Los segmentos de vía son divididos en celdas de radio menor o igual al rango de comunicación de los nodos. El nodo más cercano al centro de la celda es definido como líder (LD, del inglés Leader). En el proceso de descubrimiento, el líder retransmite paquetes de solicitud de ruta (RREQ) al nodo más lejano en la celda y de este al líder de la siguiente celda o al primer nodo en el próximo segmento de vía. El primer paquete RREQ recibido por el destino se considera como el de la ruta más corta. Un paquete de respuesta (RREP) es enviado de vuelta al nodo fuente, a través del camino descubierto. Esta ruta consiste en una secuencia de intersecciones a lo largo de la cual los paquetes deberán ser transmitidos. Con la finalidad de disminuir el retardo extremo a extremo y el número de saltos entre fuente y destino, se usan dos métricas para la selección de los nodos retransmisores: el tiempo de llegada a la intersección (RIT, del inglés Reaching Intersection Time) y la probabilidad de cambio de dirección (TDP, del inglés Turning Direction Probability). En cada segmento de vía, se usa una estrategia greedy forwarding para la retransmisión de los datos. Para ello, cada T u segundos, los nodos difundirán información acerca de su localización y próximo giro en la intersección. Con esos datos, el retransmisor puede determinar el nodo más cercano a la intersección y cuántos de ellos girarán en la dirección de la ruta establecida. Si existen nodos en esta última condición, se calculará el RIT para cada uno de ellos y se escogerá al que tenga un valor menor o igual al T u, más un tiempo de garantía; en caso contrario, se escoge el vehículo más cercano a la intersección. De no existir algún nodo vecino, el paquete se almacena para intentar una nueva búsqueda en el próximo periodo T u. Passive clustering aided routing protocol (PassCAR) El mecanismo de agrupación pasiva (PC, del inglés Passive Cluster) [231] hace uso de los paquetes de datos, en vez de paquetes de control explícitos, para construir y mantener el cluster. Los paquetes de datos llevan, adicional a su carga, información predefinida sobre la estructura del cluster —el estado del nodo transmisor dentro del cluster es enviado en la cabecera de los paquetes—, disminuyendo la sobrecarga de tráfico debido a la presencia de paquetes explícitos de control. De acuerdo al rol de los nodos en el cluster, cuatro estados externos pueden ser asumidos: Inicial, Ordinario, Cluster-Head o Gateway. Adicionalmente, se definen dos estados internos: Clusterhead-Ready y Gateway-Ready. Estos estados internos representan los roles tentativos que tomarán los nodos cuando desean enviar paquetes. El nodo líder (CH, del inglés cluster-head) se ubica en el centro del cluster, los nodos que pertenecen a dos clusters se denominan nodos gateways, mientras que el resto de nodos son llamados nodos ordinarios. En esta estructura, solo el nodo CH y los gateways retransmiten los paquetes. Por ejemplo, en la figura 2.12 se muestra el proceso de transmisión de datos en una estructura de cluster pasivo. El nodo fuente S entrega el paquete a su nodo líder CH1 y este a su gateway GW 1, quién a su vez lo envía al líder del siguiente cluster, CH2; el proceso continúa hasta que el paquete llega a CH4 y de este a D. En la elección del CH, se usa la regla de la primera declaración gana (FWD, del inglés First Declaration Wins) es usada. El primer nodo que declara su intención de convertirse en líder de grupo coordinará al resto de nodos en su área de cobertura. 54 Mecanismos para hacer frente a la movilidad en las redes inalámbricas ad-hoc Cuando un nodo está listo para convertirse en CH y tiene paquetes de aplicación para enviar, añade a estos paquetes su estado en el cluster; los nodos en su rango de transmisión aprenderán la información del CH y cambiarán sus propios estados: aquellos nodos que escuchen más de un CH se convierten en gateways, los demás asumen el rol de nodos ordinarios. D CH2 CH4 GW3 GW2 GW1 CH3 CH1 Líder de cluster S Nodo ordinario Gateway Figura 2.12: Cluster pasivo. Cuando hay un periodo de inactividad (i.e., ningún paquete es enviado o recibido durante un tiempo determinado), todos los nodos revierten su estado a Inicial. De igual forma, cuando un gateway deja de escuchar a más de un CH, tras un periodo de espera, su estado pasa a Ordinario. Para reducir el número de gateways al mínimo necesario para mantener la conectividad, se implementa un algoritmo heurístico. Los nodos que no son CH monitorizan y mantienen un registro del número de nodos cluster-head y gateways dentro de su rango. Los nodos ordinarios que escuchen un paquete desde un CH o un gateway decidirán convertirse en gateway siempre que un valor determinado, calculado en base al número de nodos CH y la redundancia deseada, supere el número de gateways existentes. PassCAR modifica el mecanismo usado por PC y diseñado para redes MANETs, para mejorar la estabilidad de los clusters formados en ambientes vehiculares. Para ello, PassCAR hace uso de una estrategia de elección de los nodos que retransmitirán los paquetes, considerando el número de nodos en el rango de comunicación y la estabilidad y tiempo de vida de los enlaces. Esta métrica permite que los nodos calculen su prioridad en el momento de convertirse en cluster-head o gateway. La prioridad se traduce en un mayor o menor tiempo de espera antes de incluir su nuevo estado de cluster en los paquetes a transmitir. El proceso de encaminamiento sigue tres fases: descubrimiento de ruta, establecimiento de ruta y transmisión de paquetes. La principal idea de PassCAR es seleccionar los mejores nodos para convertirse en cluster-heads y gateways. Estos nodos son los responsables de retransmitir los paquetes de solicitud (RREQ) durante la fase de descubrimiento. Una vez la ruta es descubierta, el destino envía un paquete de respuesta (RREP). Finalmente, la transmisión de datos es iniciada a través de la ruta establecida. 2.3 Mecanismos de encaminamiento para VANETs 55 2.3.4. Protocolos de encaminamiento basados en intersecciones En estos protocolos, las decisiones de encaminamiento son tomadas por los nodos en las intersecciones. En los segmentos de vía, generalmente, la retransmisión de los paquetes de datos se basa en el mecanismo de greedy forwarding. Ejemplos de esta clase de protocolos son: RCBR [33, 34] e iCAR [14]. Road connectivity based routing (RCBR) En su proceso de encaminamiento, RCBR [33, 34] usa información de tiempo real y espacial acerca del tránsito en las calles para establecer la conectividad del trayecto fuente-destino. La conectividad es determinada por el número de vehículos en el segmento de vía que permiten la transmisión de los paquetes entre sus intersecciones. Un grafo de conectividad, describiendo el estado de cada de segmento de vía como conectado o no, es construido en un servidor ubicado en la infraestructura de red. Para su cálculo, se analiza el tiempo de duración de los enlaces entre dos vehículos y un modelo de predicción de movilidad presentado en [216]. En la literatura se han propuesto dos versiones de este protocolo: una reactiva, S-RCBR y una proactiva, D-RCBR. En la version proactiva, D-RCBR usa una visión local de la conectividad de la red. Las decisiones de encaminamiento son tomadas solo cerca de las intersecciones. A través de mensajes HELLO, los nodos en las intersecciones pueden estar informados de la conectividad de los segmentos. Cada nodo ubicado dentro del rango virtual de la intersección —el cual corresponde a un círculo de radio igual al rango de comunicaciones de los nodos y centro localizado en la intersección—mantiene una tabla de conectividad local con entradas de las intersecciones adyacentes. Con esta información y mediante el algoritmo de Dijkstra, los nodos seleccionan la intersección conectada más cercana al destino. En caso de que este mecanismo falle, los nodos usan la regla de la mano derecha para escoger la próxima intersección entre las conectadas. Por su parte, S-RCBR utiliza un modelo de conectividad global de la red. Un servidor (CS, del inglés connectivity server), ubicado en la infraestructura de red, construye un grafo de conectividad mediante la información provista por los mensajes de conectividad (CP, del inglés Connectivity Packet) enviados por los nodos cercanos a las intersecciones. Un nodo con datos para transmitir solicita este grafo al servidor. Con esta información, el nodo selecciona el mejor camino hacia el destino y lo incluye en la cabecera de sus paquetes para ser usado en la transmisión. Este camino esta conformado por una secuencia de intersecciones que el paquete debe atravesar. Constantes actualizaciones son solicitadas desde la fuente al servidor para mantener la información. En los segmentos de vía entre dos intersecciones, los paquetes son retransmitidos usando greedy forwarding. En el caso de desconexiones en el trayecto, se emplea el mecanismo de carry and forwarding (ver sección 2.3.3). Intersection-based connectivity aware routing in vehicular ad-hoc networks (iCAR) iCAR es un protocolo diseñado para permitir servicios de infotainment4 y aplicaciones interactivas en redes vehiculares. iCAR asume que los nodos tienen conocimiento de su posición (a través del uso de GPS) y la del nodo destino (a través de servicios 4 Infotainmet es un término usado para referirse a sistemas y aplicaciones relacionadas con información y entretenimiento de los usuarios en los automóviles. 56 Mecanismos para hacer frente a la movilidad en las redes inalámbricas ad-hoc de localización). Para tener información en tiempo real de la densidad vehicular y conectividad de los segmentos de vía, los nodos en la intersección generan, con cierto valor de probabilidad, paquetes de control (CP, del inglés Control Packet), encargados de recolectar esta información mientras atraviesan el segmento. Determinadas puntuaciones son asignadas a cada segmento de vía en función de su densidad vehicular y el retardo experimentado por el CP. Estos valores son diseminados localmente en las intersecciones por paquetes periódicos intercambiados por los vehículos. En cada intersección, los nodos transmitiendo los paquetes de datos escogen la próxima intersección basados en las puntuaciones de las intersecciones adyacentes, la localización geográfica de las intersecciones y la localización del destino. En los segmentos de vía, los paquetes son retransmitidos siguiendo el mecanismo de greedy forwarding. 2.3.5. Protocolos de encaminamiento tolerantes al retardo Este tipo de protocolos ataca el problema de la inexistencia de caminos directos entre fuente y destino, el cual es generado por redes dispersas, con baja frecuencia de contactos y con alto dinamismo. En estas situaciones, los nodos intermedios deben transportar los paquetes hasta encontrar otros vehículos con mejores condiciones para alcanzar el destino. GeOpps [132], VADD [250] e IBR [52] son ejemplos de protocolos tolerantes al retardo. Vehicle assisted data delivery (VADD) VADD se basa en el mecanismo de carry and forwarding para afrontar el problema de zonas inconexas durante la transmisión de los paquetes de datos. En las intersecciones, los vehículos escogen el trayecto con el menor retardo de entrega para la retransmisión de los paquetes. El cálculo de este retardo se basa en datos históricos de la densidad vehicular en los segmentos de vía, los retardos esperados de la transmisión de los paquetes y la velocidad promedio de los vehículos. VADD presenta tres variaciones para escoger el próximo salto para la retransmisión de los paquetes en las intersecciones: L-VADD (del inglés, Location First Probe), D-VADD (del inglés Direction First Probe) y H-VADD (del inglés Hybrid Probe). En L-VADD se escoge al nodo más cercano al destino como el próximo salto. Sin embargo, debido a que esta forma de selección puede llevar a la generación de bucles, se propone que cada paquete lleve información sobre su nodo de procedencia. Por su parte, D-VADD elije el nodo moviéndose en la misma dirección de envío del paquete, solucionando de esta forma el problema de los bucles. H-VADD es una mezcla de las dos propuestas anteriores. Geographical Opportunistic Routing (GeOpps) GeOpps aprovecha la información provista por los sistemas de navegación de los vehículos para encaminar los mensajes a una determinada localización. El proceso de encaminamiento se basa en el mecanismo de carry and forwarding. Así, cuando un vehículo recibe un paquete para una determinada ubicación D, calcula un punto denominado NP (del inglés Nearest Point), el cual es el lugar más cercano a D por el que pasará el vehículo basado en la ruta establecida por su sistema de navegación al destino del conductor. Además, valiéndose de la información de su mapa digital, el nodo calcula el tiempo estimado de arribo (ETA, del inglés Estimate Time of Arrival) hasta NP y el tiempo que podría tomar a un vehículo llegar desde el NP a D. Esta información se 2.3 Mecanismos de encaminamiento para VANETs 57 denomina tiempo mínimo estimado de entrega para el paquete (METD, del inglés Minimum Estimated Time of Delivery for the Packet). Para el proceso de encaminamiento, los vehículos periódicamente difunden el destino de los paquetes que almacenan. Los vehículos vecinos (a un salto de distancia) calculan el METD que requieren e informan al vehículo que transporta el paquete, el cual decide seguir llevando el paquete (si su valor de METD es menor) o reenviarlo al nodo con menor valor de METD. Este proceso continúa hasta que el paquete alcanza el destino. Intersection-based routing protocol for vanet (IBR) IBR usa una estrategia carry and forwarding. Los vehículos llevan sus paquetes hasta las intersecciones en donde se escoge un nuevo portador que los llevará hasta la siguiente intersección. Este proceso se repite hasta alcanzar al destino. En el proceso de encaminamiento, un servicio de localización es usado para determinar la ubicación del destino. En las intersecciones, el nodo que transporta el paquete escoge el próximo salto en función de la dirección del paquete y la dirección de los vehículos. Si ningún vehículo se desplaza en la dirección del segmento de vía escogido, el paquete es mantenido en la intersección hasta poder pasarlo. En caso de que la intersección este vacía, el vehículo llevará el paquete consigo hasta encontrar algún vehículo en la dirección correcta. Para finalizar nuestro estudio de los mecanismos de encaminamiento en VANETs, en la tabla 2.4 presentamos las principales características de los protocolos analizados en esta sección. Características Reactivos (R) / proactivos (P) geográfico (G) Plano (F) / jerárquico (J) Sobrecarga de tráfico de control alta (H) baja (L) / media (Md) Trayecto simple (S) / multitrayecto (M) Encaminamiento basado en intersecciones Tolerante al retardo Best effort (B) / QoS (Q) Reactivos (R) / proactivos (P) geográfico (G) Plano (F) / jerárquico (J) Sobrecarga de tráfico de control alta (H) baja (L) / media (Md) Trayecto simple (S) / multitrayecto (M) Encaminamiento basado en intersecciones Tolerante al retardo Best effort (B) / QoS (Q) Protocolos de encaminamiento PBR RBVT ARBR GPRS GSR A-STAR GVGrid IGRP R R\P R G R-G G R-G G-P F Md F Md-H F Md F L F Md F L F Md F Md S No No B S No No B S No No B S No No B S Si No B S Si No B S No No B S Si No Q GyTAR RTRP PassCAR RCBR iCAR VADD GeOpps IBR G R R R-P G G G G J L J Md J Md F Md-H F L F L F L F L S Si Si B S Si Si B S No No B S Si Si B S Si No B S No Si B S No Si B S Si Si B Tabla 2.4: Características de los protocolos de encaminamiento para VANETs 58 Mecanismos para hacer frente a la movilidad en las redes inalámbricas ad-hoc 2.4. Mecanismos de encaminamiento para redes inalámbricas en malla Si bien las redes inalámbricas en malla (WMNs) pueden ser consideradas como una clase especial de las MANETs [51, 208] —en ambos casos, los nodos comparten la capacidad para la retransmisión multisalto de paquetes y, en cierta medida, la movilidad—, estas redes presentan características muy particulares que las diferencian de las MANETs [113]. Por una parte, las WMNs son diseñadas principalmente para ofrecer una conexión entre usuarios y una red externa (usualmente Internet). Para ello, estas redes tienen unos nodos especiales, denominados pasarelas, que cumplen la función de enlazar la WMN con las redes externas. El tráfico clientes-Internet fluirá a través de estos nodos, lo que produce que el proceso de encaminamiento sea orientado a destinos fijos o conocidos en la red. Por otra parte, como se explica en la sección 1.1.3, las redes inalámbricas en malla presentan dos clases de nodos: unos con alta movilidad, similares a las redes MANETs, y otros con movilidad limitada o nula, y mayores prestaciones para formar una red con infraestructura. Muchos de los protocolos de encaminamiento diseñados para las MANETs (e.g., AODV, OLSR, DSR, ZRP, ...) han sido propuestos y están siendo usadas en algunas versiones comerciales de la WMN [163]; es más, en general, los protocolos de encaminamiento propuestos para WMN siguen estrategias similares a estas redes. Así tenemos protocolos reactivos, proactivos e híbridos —muchos de ellos derivados de protocolos MANET como en el caso de AODV-MR [187] y WMR [242]—, protocolos multitrayecto, como con MR-TBMPA [136] o protocolos multi-radio como MCR [123]. Multi-radio ad-hoc on-demand distance vector routing (AODV-MR) AODV-MR [187] es una evolución de AODV para trabajar en redes inalámbricas en malla multiradio. Se asume que cada nodo está equipado con múltiples radios, funcionando en canales diferentes y no superpuestos. En el proceso de descubrimiento de ruta, un nodo difunde un paquete de solicitud de ruta (RREQ) por todas sus interfaces de radio. Los nodos intermedios con una o más interfaces trabajando en un mismo canal reciben este paquete RREQ con información que les permite crear una ruta hacia el nodo fuente. Estos nodos retransmiten los RREQ por todas sus interfaces de radio, excepto por aquella a través de la cual recibieron el mensaje RREQ. AODV-MR mantiene un número de interfaz para cada una de las entradas generadas en su tabla de encaminamiento. Cuando un paquete RREQ alcanza el destino o a otro nodo con una ruta válida hacia él, un paquete de respuesta de ruta (RREP) es generado y enviado de vuelta a la fuente a través de la ruta descubierta. Una vez establecido el camino fuente-destino se procede con el envío de los datos. Wireless mesh routing (WMR) Este protocolo de encaminamiento es diseñado para una red inalámbrica en malla con una infraestructura LAN inalámbrica subyacente. Como se muestra en la figura 2.13, esta red está conformada por dos tipos de entidades: nodos móviles y puntos de acceso (AP, del inglés Access Point). Los nodos móviles actúan tanto como consumidores y/o como proveedores de servicios en la red (e.g., retransmitir los paquetes 2.4 Mecanismos de encaminamiento para redes inalámbricas en malla 59 dirigidos a otros nodos); mientras que los APs sirven tanto para retransmitir los paquetes entre nodos dentro de la red o como un puente hacia redes externas (e.g., Internet). Cada nodo en la red mantiene una etiqueta de distancia, la cual contiene la distancia al AP más cercano. Periódicamente, los nodos en la red difunden mensajes HELLO que les permiten generar una lista de vecinos y compartir sus etiquetas de distancia. Tráfico externo Tr á Tráfico interno Figura 2.13: Ejemplo de red WMR. El proceso de descubrimiento de ruta es diferenciado para el tráfico dirigido hacia los nodos internos o externos de la red. El protocolo asume que los nodos conocen la localización del destino. Cuando un nodo necesita establecer una ruta hacia otro, un paquete de solicitud de ruta (RREQ), con los requerimientos de calidad de servicio (QoS) del flujo de datos y su etiqueta de distancia, es difundido por la red. En el caso del tráfico externo, la retransmisión de estos paquetes se desarrolla de forma tal que los RREQs solo pueden ser reenviados por aquellos nodos que tienen una etiqueta de distancia menor a la del nodo precedente —cada retransmisor añade su etiqueta de distancia al paquete de solicitud de ruta para la comparación. De esta forma, las futuras retransmisiones acercan cada vez más el RREQ al AP. Para los datos dirigidos a nodos internos, los paquetes de solicitud son inundados en la red. Para limitar su alcance, los RREQ son retransmitidos solo dentro de un número máximo de saltos, luego de los cuales son descartados. Una vez recibido el paquete de solicitud de ruta por el destino o por el AP (en el caso de flujos externos), un paquete de respuesta de ruta (RREP) es enviado de vuelta a la fuente para que inicie la transmisión de datos a través de la ruta establecida. Multipath routing using tree-base multi-portal association (MR-TBMPA) Este protocolo se diseña para trabajar en una WMN con una arquitectura como la que se muestra en la figura 2.14. Tres componentes principales la conforman: nodos pasarela (MPP, del inglés Mesh Portal/Gateway), puntos de acceso (MAP/MR, del inglés Mesh Access Point/Mesh Router) y estaciones móviles (STA, del inglés Mobile Station). Los MPP conectan la red inalámbrica con la parte cableada; mientras que los MAPs se comunican con las STAs y con otros MAPs para la retransmisión de los datos. Los STAs sólo envían y reciben datos, no retransmiten ningún paquete. 60 Mecanismos para hacer frente a la movilidad en las redes inalámbricas ad-hoc STA STA MPP 1 S S S S Conexión cableada S Conexión inalámbrica S S S Figura 2.14: Ejemplo de red WMN para MR-TBMPA. MR-TBMPA [136] busca reducir el problema de los cuellos de botella que se generan en arquitecturas donde las STAs solo se pueden asociar con un solo MAP para el envío y recepción de datos. Para ello, el flujo de datos entre una STA y un dispositivo en la red cableada (e.g., un servidor de Internet) es dividido en múltiples flujos dirigidos a través de diferentes MPPs. Por ejemplo, en la figura 2.14, el flujo de datos desde el STA1 hacia la red cableada es enviado a través del MPP1 y el MPP2. El patrón de tráfico usado en la capa de aplicación es solicitud-respuesta: el STA envía un paquete APP_Pkt de solicitud al nodo en la parte cableada y este contesta con un APP_Pkt de respuesta. Un despachador central (CD, del inglés Central Dispatcher) es usado para resolver estas solicitudes y para decidir el trayecto o trayectos para el tráfico del enlace descendente. En la WMN, los MPP periódicamente difunden un paquete RNN_Pkt (del inglés Root Announcement Packet) con su identificación. Este paquete permite a los MAP registrar una entrada dirigida al MPP que difunde el RNN_Pkt y, además, incluir en este paquete su propio identificador de manera que los MPPs y las STAs que lo reciben puedan también incluirlo en su registro. Los RNN_Pkt tienen asociado un número de secuencia y un número de saltos máximo para evitar ser duplicados y limitar su alcance. De esta forma, los nodos inalámbricos conocen cómo acceder a los diferentes MPPs. Para determinar el estado de los enlaces, en términos del tiempo estimado de transmisión (ETX, del inglés Estimated Time of Transmission) los nodos periódicamente difunden a sus vecinos un paquete de prueba (Probe-ACK). MR-TBMPA escogerá los caminos con los valores ETX acumulados más pequeños. Para determinar los trayectos en el enlace descendente, el CD necesita información del ETX para tener una visión global del estado de los enlaces y calcular su tabla de estado de enlace global. Con este fin, periódicamente, cada nodo inalámbrico envía un paquete de reporte ETX al CD, a través de los MPPs. 2.4 Mecanismos de encaminamiento para redes inalámbricas en malla 61 Los paquetes generados desde la capa de aplicación son encapsulados en paquetes de red (NTW_Pkt, del inglés Network Packet). Una STA envía un APP_Pkt de solicitud a través de un NTW_Pkt, adjuntando el camino completo, salto a salto, hasta el CD. Cuando el CD recibe el NTW_Pkt con la solicitud de la STA, se genera un paquete de respuesta y se lo envía de vuelta por los trayectos calculados a partir de su tabla de estado de enlace global. Multi-chanel routing (MCR) MCR [123] es un protocolo reactivo multicanal. En el proceso de encaminamiento, MCR hace uso de una métrica que combina el coste de la conmutación de canales (en términos de retardo) y la calidad de los enlaces a lo largo del trayecto fuente-destino. Esta métrica permite seleccionar trayectos con diversidad de canales y menor número de saltos. Al igual que DSR, MCR es un protocolo reactivo basado en fuente. En el proceso de descubrimiento de ruta, el nodo fuente difunde un paquete de solicitud de ruta (RREQ) en todos sus canales. Además de un único número de secuencia para cada proceso de descubrimiento, cada RREQ contiene los costes de conmutación relacionados con su correspondiente canal de transmisión, el coste de cada enlace y los canales usados en los saltos previos. Esta información permite que el nodo que recibe un RREQ pueda calcular el coste de enlace de los saltos previos. Los nodos intermedios retransmitirán los RREQ en dos casos: i) si el número de secuencia de RREQ es recibido por primera vez, en cuyo caso, el coste del trayecto atravesado es cargado en la tabla local o ii) si el coste del trayecto descubierto en el RREQ es más pequeño que el coste mantenido desde previos RREQs con el mismo número de secuencia. Cuando el destino recibe un RREQ responderá con un paquete RREP siempre que el valor de su coste sea menor que el valor recibido desde otros RREQ con el mismo número de secuencia. El nodo fuente hace uso de la ruta recibida con el menor coste para enviar sus paquetes. Para el mantenimiento de la ruta, se llevan a cabo procesos de descubrimiento periódicos, aún en el caso de que las rutas no estén rotas. La reparación de rutas se desarrolla a través de paquetes de error (RERR), de forma similar a lo descrito para DSR (ver sección 2.2.2). A modo de resumen, en la tabla 2.5 se muestran las principales características de los protocolos de encaminamiento para WMNs estudiados en esta sección. Características Reactivos (R) / proactivos (P) / híbridos (H) / geográfico (G) Plano (F) / jerárquico (J) Sobrecarga de tráfico de control alta (H) baja (L) / media (Md) Trayecto simple (S) / multitrayecto (M) Uso de múltiples canales de radio Basado en potencia Best effort (B) / QoS (Q) Protocolos de encaminamiento AODV-MR WMR MR-TBMPA MCR R G-R H R F Md F Md J Md F Md S No No B S No No Q M No No B M Si No B Tabla 2.5: Características de los protocolos de encaminamiento para WMNs 62 Mecanismos para hacer frente a la movilidad en las redes inalámbricas ad-hoc 2.5. Virtualización en redes móviles ad-hoc Como se analizó en la sección 2.2, las MANETs han sido objeto de una intensiva investigación durante muchos años, con incontables propuestas en la literatura para hacer frente a los problemas y retos que surgen de las propiedades de los medios inalámbricos, la variabilidad de la topología debido a los movimientos impredecibles de los nodos y al hecho de que estos pueden tener memoria limitada , capacidad de procesamiento y batería [55]. Convertir a las redes ad-hoc en entornos de comunicación más robustos, capaces de soportar la operación de sistemas de información distribuidos, es el objetivo de la capa de nodos virtuales (VNLayer, del inglés Virtual Node Layer) presentada por Shlomi Dolev et al. en [67]. La VNLayer es un enfoque basado en cluster para la gestión de las comunicaciones en redes móviles ad-hoc, proporcionando una abstracción de regiones geográficas fijas servidas por nodos virtuales como medio para hacer frente a los desafíos planteados por la movilidad de los nodos reales. Esta capa virtual define procedimientos para que nodos móviles reales colaborativamente emulen nodos virtuales que pueden ser considerados como servidores ubicados en lugares conocidos. Este enfoque hace más fácil la tarea de los desarrolladores de aplicaciones para trabajar en las capas superiores de los nodos, dado que ellos pueden desplegar aplicaciones sobre dispositivos móviles y servidores virtuales sin tener que hacer frente a los desafíos derivados de la movilidad [41]. Además, la virtualización crea un nivel de jerarquía contraria a la estructura de las MANETs planas, lo cual trae oportunidades para rediseñar protocolos MANET de manera que operen en forma más eficiente y fiable. Al respecto, los trabajos publicados por Jiang Wu [240, 241] y Rekha Patil [182] prueban que una versión virtualizada de AODV puede superar al mismo AODV en términos de tasa de entrega de paquetes, latencia, sobrecarga de paquetes de control y estabilidad de las rutas en una variedad de escenarios; pero también al algoritmo de encaminamiento RIP [152] y el protocolo DHCP para la configuración dinámica de direcciones IP [69]. En lo que sigue de esta sección, se presenta una revisión de la estructura y funcionamiento de la VNLayer y las versiones virtualizadas de ADOV y RIP. 2.5.1. La capa de nodos virtuales En las implementaciones presentadas en [41, 182, 241], la VNLayer define procedimientos para que nodos móviles físicos (PNs, del inglés Physical Nodes) emulen nodos virtuales (VNs) que pueden ser direccionados como servidores estáticos. Como se muestra en la figura 2.15, el área geográfica de las MANETs es dividida en regiones cuadriculadas, cuyo ancho es escogido de tal forma que cada PN puede enviar y recibir datos hacia y desde algún otro PN dentro de su actual región y en regiones vecinas. Los nodos virtuales (VNs, del inglés virtual nodes) pueden ser considerados como ubicados en el centro de las correspondientes regiones (un único VN por región), siendo capaces de enviar mensajes directamente a los VNs vecinos. Los VNs son emulados por los PNs en la región correspondiente. Un PN en cada región es escogido como líder y se encarga de las tareas de recepción, almacenamiento y retransmisión en las comunicaciones con otros VNs. Un subconjunto de los nodos no-líder trabajan como copias de seguridad (backups) para mantener réplicas de la información de estado desde las capas superiores, consistentes con la versión del líder. De esta forma, los VNs pueden mantener un estado persistente y ser tolerante a fallos aun cuando los PNs fallen o abandonen la región. El estado de un VN se pierde solo 2.5 Virtualización en redes móviles ad-hoc 63 Figura 2.15: Nodos virtuales estáticos (cuadrados blancos) superpuestos a los nodos móviles físicos (círculos negros) en una MANET. cuando la región se vacía de PNs. La interfaz entre la VNLayer y la capa de red ofrece la noción de regiones, el rol jugado por el correspondiente PN en ese momento, y un conjunto de funciones para enviar y recibir mensajes, y para obtener, configurar y comprobar la información de estado. La forma en la que la retransmisión de paquetes trabaja en la implementación de la VNLayer provista por Brown et al. [41] es ilustrada en el cuadro grande de la figura 2.16, con una red ad-hoc que cubre 9 regiones. Asumamos que el PN 3, desde la región 0.0, envía un paquete destinado al PN 9 en la región 1.2. El paquete saliendo desde PN 3 (el cual no es ni líder ni backup) es primero procesado por el líder local PN 1 y el backup PN 2. El líder PN 1 retransmite el paquete a la región 1.0, mientras que el backup PN 2 almacena el paquete en su cola de envío. Cuando PN 2 escucha que este paquete ha sido retransmitido por el líder PN 1, lo elimina desde su cola —mantener esta información permite al backup continuar con las tareas pendientes dejadas por el líder en caso de asumir el liderazgo. Los VNs en las regiones 1.0, 2.1 y 1.2 retransmiten el paquete a lo largo de todo el camino hasta el nodo destino PN 9 (los nodos físicos que realmente retransmiten el paquete son PN 4, PN 7 y PN 8). PN 6 y PN 9 (el nodo destino) trabajan como backups para PN 7 y PN 8, respectivamente. La flechas de puntos indican que los paquetes retransmitidos son escuchados por los nodos backups. PN 5 es otro cliente puro (ni líder ni backup) que no está involucrado en la retransmisión de paquetes. En 2011, Wu et al. [240] presentó una versión mejorada de la VNLayer que extendió sus reglas básicas de comunicación. Primero, introdujo los mecanismos de recepción directa (DR, del inglés Direct Receipt) y recepción temprana (ER, del inglés Early Receiving) para evitar las comunicaciones con el nodo líder local del VN. En la figura 2.16, por ejemplo, PN 3 en la región 0.0 podría enviar los paquetes directamente al líder de la región vecina 1.0, PN 4, mientras que PN 9 podría aceptar paquetes recibidos desde el líder de la región 2.1 (PN 7), sin tener que esperar por una copia enviada por PN 8 —en su lugar, PN 8 sería relevado de procesar los paquetes tras verificar que están dirigidos a algún PN en su región. Esos mecanismos, los cuales hacen que las comunicaciones fluyan como se muestra en el cuadro pequeño de la figura 2.16, fueron 64 Mecanismos para hacer frente a la movilidad en las redes inalámbricas ad-hoc 9 9 0.2 0.2 8 1.2 7 0.1 1.1 1 1.1 2.1 6 4 3 5 1.0 2.0 4 2 3 0.0 2.1 2 6 0.0 1 2.2 2.2 7 0.1 8 1.2 Líder Backup 5 1.0 2.0 Cliente Figura 2.16: Ilustración de la retransmisión de paquetes basada en la VNLayer con la implementación desarrollada por Brown (cuadro grande) y Wu (cuadro pequeño). Las líneas dobles indican fuentes o destinos de los paquetes de datos. usados en los estudios de simulación de [182, 240, 241]. Adicionalmente, Wu propuso un mecanismo de enlaces largos (LL, del inglés Long Links) para permitir que los PNs acepten algunos mensajes que ellos podrían escuchar, aún desde regiones no vecinas. En la figura 2.16, LL permitiría a PN 4 en la región 1.0 enviar paquetes directamente a PN 8 en la región distante 1.2 (note que PN 8 está más cerca a PN 4 que PN 7, aunque la región de PN 7 es adyacente a la región de PN 4). Sin embargo, este mecanismo fue dejado como una opción, debido a que los ahorros conseguidos por LL en términos de la longitud del trayecto de retransmisión y latencia vendrían a expensas de una mayor complejidad y mayor probabilidad de inconsistencias entre líderes y backups en una región (e.g., como cuando PN 9 no puede escuchar los paquetes que PN 8 recibe desde PN 4). En lo que sigue de esta sección analizaremos los procesos de elección de líder, designación de los nodos backup, los mecanismos de sincronización de estado, el mantenimiento de la información de estado de vecinos y regiones y los modos de transmisión empleados en la VNLayer. Finalmente, presentamos una descripción de las únicas versiones virtualizadas de protocolos de encaminamiento desarrolladas por Wu et al. [240], VNAODV y VNRIP. Elección del Líder El proceso definido en [240] (y usado en [182,241]) para dar el rol de líder/no-líder a cada uno de los PNs que están dentro de la misma región es gestionada por tres tipos de eventos diferentes: recepción de mensajes, tiempos de espera y cambios de región. Cuatro tipos de mensajes fueron definidos: M_LeaderRequest: usado para solicitar el liderazgo. 2.5 Virtualización en redes móviles ad-hoc 65 M_LeaderReply: enviado por el líder para negar una solicitud de liderazgo emitido por un nodo de la región. M_Heartbeat: usado por el líder para periódicamente confirmar su liderazgo. M_LeaderLeft: usado por un nodo líder para informar a los no-líderes que está abandonando la región. Habían también cuatro temporizadores diferentes : T_LeaderRequest: usado para controlar cuánto tiempo espera un nodo para enviar un mensaje LeaderRequest después de entrar en una nueva región o después de escuchar que el líder ha abandonado la región actual. T_RequestWait: usado para controlar el tiempo que un nodo espera por la respuesta de un líder después de enviar un mensaje M_LeaderRequest. T_Heartbeat: usado por líderes y no-líderes para controlar cuándo enviar o esperar mensajes M_Heartbeat. T_LeaderElect: usado por no-líderes para decidir cuándo empezar una elección del líder en ausencia de mensajes M_Heartbeat. Los diferentes eventos llevan a cada PN a uno de seis posibles estados: INITIAL, UNKNOWN, UNSTABLE, REQUEST, LEADER and NON-LEADER. El comportamiento es representado en la gráfica de la figura 2.17: INITIAL if (expires<2) { in: expire(T_LeaderElect) out: start(T_LeaderElect); expires=2;} in: RegionChange OR OR recv(M_LeaderLeft) out: start(T_LeaderRequest); in: expire(T_LeaderRequest) out: send(M_LeaderRequest); start(T_RequestWait); in: RegionKnown out: start(T_LeaderRequest); if (expires==2) { in: expire(T_LeaderElect) out: start(T_LeaderRequest); expires=0;} UNSTABLE UNKNOWN in: RegionChange OR recv(M_LeaderLeft) out: start(T_LeaderRequest); in: recv(M_Heartbeat) out: start(T_LeaderElect); in: expire(T_LeaderElect) out: start(T_LeaderElect); expires=1; NONLEADER REQUEST in: RegionChange out: start(T_LeaderRequest); in: RegionChange out: send(M_LeaderLeft); start(T_LeaderRequest); in: recv(M_LeaderRequest) OR recv(M_Heartbeat) out: start(T_LeaderElect); in: expire(T_RequestWait) out: send(M_Heartbeat); start(T_Heartbeat); LEADER in: recv(M_Heartbeat) out: start(T_LeaderElect); in: recv(M_Heartbeat) out: start(T_LeaderElect); in: expire(T_Heartbeat) out: send(M_Heartbeat); start(T_Heartbeat); in: recv(M_LeaderReply) OR recv(M_Heartbeat) OR recv(M_LeaderRequest) out: start(T_LeaderElect); Fig. 4. The state machine of the leader election procedure defined in [12]. Figura 2.17: Máquina de estados del procedimiento de elección de líder definida en [240]. 66 Mecanismos para hacer frente a la movilidad en las redes inalámbricas ad-hoc El PN comienza en el estado INITIAL. Después de identificar su región, cambia a UNKNOWN e intenta descubrir si hay un líder en la región, poniendo en marcha el temporizador T_LeaderRequest. Si el PN recibe un mensaje M_Hearbeat desde el líder de la región o un mensaje M_LeaderRequest desde otro nodo antes que el temporizador expire, el PN cambia su estado a NON-LEADER; en caso contrario, este pasa al estado REQUEST y difunde un mensaje M_LeaderRequest. Desde el estado REQUEST, el PN espera por la confirmación de su liderato durante el tiempo definido por el T_RequestWait. Si recibe algún mensaje (M_Heartbeat o M_LeaderReply desde el líder actual, o un M_LeaderRequest desde otro nodo) antes de la finalización del tiempo progamado para el T_RequestWait, su estado cambia a NON-LEADER; en caso contrario, el PN se convierte en LEADER. Si un M_Heartbeat le anuncia acerca de un líder que asumió el liderazgo previamente, el PN cambia su estado a NON-LEADER. Cuando un PN en el estado de LEADER abandona su actual región, cambia su estado a UNKNOWN y difunde un mensaje M_LeaderLeft para empezar un nuevo proceso de elección de líder. Esto causa que los restantes nodos de la región cambien su estado a UNKNOWN e inicien sus respectivos temporizadores T_LeaderRequest (cada nodo añade un pequeño valor aleatorio para prevenir colisiones cuando envían el mensaje M_LeaderRequest). Finalmente, un PN en estado NON-LEADER usa el temporizador T_LeaderElect para detectar la presencia de un líder en la región. El temporizador es reiniciado una vez recibido un M_Heartbeat. Si este expira una vez, el PN cambia su estado a UNSTABLE y reinicia el T_LeaderElect. Si el temporizador expira una vez más antes de recibir un M_Heartbeat, el PN asume que el líder se ha retirado y cambia su estado a UNKNOWN para elegir un nuevo líder en la región. El nodo esperará el tiempo que se define en el T_RequestWait antes de difundir un M_LeaderRequest dentro de la región. Designación de los nodos backup y sincronización del estado El enfoque definido en [240] (y usado en [182,241]) para designar los nodos backup entre los nodos no-líderes fue probabilístico. Inmediatamente después de entrar en el estado NON-LEADER, el PN llama una función de lanzamiento de moneda (CTF, del inglés Coin Tosser Function) para decidir si se convierte en backup o no. La CTF toma una decisión aleatoria Booleana acerca de convertirse en backup con una probabilidad p directamente proporcional a un umbral dado (T H) e inversamente proporcional a una estimación del número de nodos en la región (N N ): TH (2.1) NN Según esta fórmula, cuanto mayor el número de nodos en la región, menor es la probabilidad de que un PN sea escogido para convertirse en backup. La motivación de este enfoque fue evitar tener muchos backups en MANETs densas y así reducir la sobrecarga debido a las sincronización del estado, proceso que exige el intercambio de mensajes destinados a garantizar que las réplicas de la información de estado desde las capas superiores (por ejemplo, tablas de encaminamiento) mantenidas en los nodos de reserva son compatibles con la versión del líder. La sincronización puede activarse en dos casos: p∝ 2.5 Virtualización en redes móviles ad-hoc 67 (I) Las llamadas sincronizaciones de movimiento se activan cuando un nodo entra en una región y se convierte en un backup, para así poder obtener la información de estado desde el nodo líder. (II) Por su parte, las sincronizaciones de inconsistencia se activan cuando un nodo backup escucha un paquete retransmitido por el líder que no está almacenado en su cola de envío (una señal de que el backup se ha perdido algo) o cuando un nodo backup, por medio de algún tipo de procesamiento en la capa de red, detecta que el líder no se comporta acorde con su copia local de la información de estado. Ambos tipos de sincronización confían en mensajes M_SyncRequest para llevar las peticiones desde los nodos no-líder y mensajes M_SyncAck para transportar las repuestas de los líderes. Mantenimiento del estado de los vecinos y de la región, y modos de transmisión La emulación de los nodos virtuales confía en dos tablas gestionadas por los nodos físicos que le dan soporte: Por una parte, la tabla de actividad de la región mantiene un registro de las regiones desde las cuales el VN puede escuchar mensajes. Cada entrada mantiene un identificador (id) de región, la dirección MAC (del inglés media access control) del líder actual de la región y parámetros para medir la actividad de la misma (más detalles en [240]). Por otra parte, la lista de vecinos mantiene una relación de nodos físicos desde los cuales se han escuchado mensajes recientemente. Cada entrada mantiene un id del nodo, un id de la región actual y un tiempo de vida. El mantenimiento de estado de los vecinos y de la región se lleva a cabo mediante el intercambio de mensajes específicos M_Hello (enviado periódicamente por cada PN) y por la escucha de mensajes generados por los nodos líderes, incluyendo M_Heartbeat, M_LeaderReply, M_LeaderLeft, M_SyncAck y mensajes de aplicación. Cuando se quiere enviar un paquete a un VN más que a un PN específico, la VNLayer buscará el actual líder del VN en la tabla de actividad de la región. Si el actual líder fuere desconocido, el paquete podría ser transmitido utilizando una dirección de destino de difusión (broadcast 5 ). De lo contrario, el paquete sería enviado a la dirección MAC correspondiente por unicast. 2.5.2. Versión virtualizada de AODV (VNAODV) Como se ha explicado en la sección 2.2, AODV es un protocolo reactivo, lo cual significa que las rutas de comunicación son creadas solo cuando hay paquetes de datos para ser entregados. Su funcionamiento se basa en tres procesos: descubrimiento de la ruta, retransmisión de los paquetes y mantenimiento de la ruta. El principal problema de AODV tiene que ver con la sobrecarga de tráfico de control causado por la difusión de los mensajes de RREQ y la inestabilidad de las rutas 5 Broadcast es el envío de información desde un emisor a todas las estaciones en la red. 68 Mecanismos para hacer frente a la movilidad en las redes inalámbricas ad-hoc durante los periodos de movilidad media o alta (ver [120]). Ambos problemas pueden ser abordados con la abstracción provista por la VNLayer, la cual cubre el área de la red con nodos virtuales estáticos que actúan en nombre de un número comparativamente mayor de nodos físicos. El algoritmo de encaminamiento VNAODV mantiene el núcleo de AODV, incluyendo los tipos de paquetes y la configuración de la mayoría de los parámetros. Los principales cambios que se requieren para enviar datos a través de VNs en lugar de PNs son los siguientes (ver [240] para más detalles): (I) Las entidades de encaminamiento no son identificadas por direcciones IP, sino más bien por identificadores de región. En consecuencia, los paquetes de control (RREQ y similares) tienen campos adicionales para indicar los identificadores de la región y las entradas de las tablas de encaminamiento contienen el identificador de la región del próximo VN de las rutas (campo next_region). (II) Todos los PNs procesan los paquetes de control para actualizar sus tablas de encaminamiento. Adicionalmente, los backups pueden escuchar los paquetes de control transmitidos desde el líder local para actualizar sus propias tablas siempre que se pueda, preguntando a la VNLayer para ejecutar una sincronización de inconsistencia si se detecta un error significativo. (III) Dado que la VNLayer puede transmitir paquetes por unicast o broadcast (como se explicó en la sección 2.5.1), el mantenimiento de ruta no puede confiar solo en los servicios de la capa de enlace como en AODV. Por tanto, VNAODV implementa un mecanismo en la capa de red llamado acuse pasivo, ya sugerido en las especificaciones de AODV como un complemento a las notificaciones de la capa de enlace. Mediante este mecanismo, si un nodo escucha al próximo vecino a un salto retransmitir algún mensaje, el nodo trata a ese mensaje como una confirmación y por tanto como una prueba de que el enlace está activo. En el último salto en el trayecto de retransmisión entre fuente y destino, el nodo destino confirma la recepción de los paquetes de datos considerándolos como un mensaje de acuse (ACK, del inglés acknowledgment) explícito, lo que implica una sobrecarga proporcional a la cantidad de tráfico de datos. 6 Además Wu et al. añaden una optimización denominada corrección de ruta por destino, para tener en cuenta el hecho de que el PN suele permanecer dentro de la región cubierta por un VN solo por un tiempo limitado. Por lo tanto, a menudo sucede que, poco después de establecer una ruta a un determinado PN a través de una secuencia de VNs, el PN se mueve fuera del alcance del último VN en el trayecto y se inicia una reparación de ruta local. Este tipo de reparaciones costosas podrían evitarse en VNAODV aprovechando el hecho que los paquetes de datos difundidos desde un VN pueden ser escuchados en las regiones vecinas: cuando un PN recibe un paquete dirigido a él, pero que contiene el identificador de una región que ha abandonado, el PN difunde un mensaje RREP no solicitado con un tiempo de vida (TTL, del inglés time to live) TTL = 1 y sin especificar el próximo salto. Esto causa que las tablas de encaminamiento de su VN y de los VNs vecinos se actualicen para que los paquetes puedan ser encaminados correctamente hacia el PN mientras se mueve. 6 La especificación de AODV también sugiere un mecanismo para detectar fallo de enlaces en la capa de red por el envío periódico de mensajes HELLO para mantener una lista de vecinos. Wu et al. descartan aquella opción para VNAODV porque plantea un compromiso poco interesante entre el retardo promedio en la detección de los enlaces rotos y la cantidad de sobrecarga en la red, constante y no correlacionado con los datos de tráfico. 2.5 Virtualización en redes móviles ad-hoc 69 8 0.2 1.2 2.2 3.2 7 1 2 0.1 6 1.1 2.1 3.1 3 4 0.0 Sin corrección de ruta Con corrección de ruta 1.0 Región 3.1 0.1→1.0→2.0→3.1 0.1→1.0→2.0→3.1 2.0 Región 2.1 0.1→1.0→2.0→2.1 0.1→1.0→2.1 5 3.0 Región 2.2 0.1→1.0→2.0→2.1→2.2 0.1→1.0→2.1→2.2 Líder Cliente Región 1.2 0.1→1.0→2.0→2.1→1.2 0.1→1.2 Figura 2.18: Evolución de la ruta de comunicación de VNAODV entre dos PNs cuando uno de ellos se mueve, con y sin correcciones de ruta. Ilustremos este comportamiento mediante el ejemplo mostrado en la figura 2.18. Asumamos que PN 2 ha estado enviando paquetes a PN 6 a través de una ruta que atraviesa las regiones 0.1→1.0→2.0→3.1. Si PN 6 empieza a moverse como se muestra desde la región 3.1 a la región 1.2, el mecanismo de corrección de ruta sirve para actualizar las tablas de encaminamiento para que los paquetes de datos sean entregados a través de 0.1→1.0→2.1, luego a través de 0.1→1.0→2.1→2.2 y, finalmente, directamente a través de 0.1→1.2.7 Sin la corrección de ruta, por el contrario, la reparación local haría que la ruta inicial 0.1→1.0→2.0→3.1 crezca para convertirse en 0.1→1.0→2.0→2.1→1.2 después que el PN 6 entre en la región 1.2. Este ejemplo muestra que las correcciones de ruta sirven no solo para seguir los movimientos del PN, sino también para reducir la longitud de las rutas y, por tanto, reducir el tiempo de entrega de los paquetes. Mientras VNAODV sigue siendo un algoritmo reactivo como AODV, también puede ser visto como un ejemplo de encaminamiento jerárquico (recuérdese sección 2.2), ya que la idea es formar grupos de nodos que intercambian mensajes para soportar la creación de redes de comunicaciones a una mayor escala. Sin embargo, mientras que la mayor parte de los trabajos previos sobre encaminamiento jerárquico en MANETs cuentan con un diseño inter-capas (del inglés cross-layer design) con un alto grado de acoplamiento entre los procedimientos de agrupamiento y de encaminamiento (ver [13, 31]), la VNLayer aparece como una capa separada en la pila de protocolos, dirigida a blindar a la capa de red de los retos derivados de la movilidad de los nodos. En consecuencia, la interfaz hacia la capa de red simplemente expone las nociones áreas geográficas sobre las cuales los paquetes deben ser retransmitidos (es decir, lo que hemos llamado regiones) y nodos que deberían gestionar los paquetes allí (líde7 Las rutas serían más cortas si el mecanismo de enlaces largos (LL) mencionado en sección 2.5.1 fuera habilitado. 70 Mecanismos para hacer frente a la movilidad en las redes inalámbricas ad-hoc res). De esta manera, la VNLayer, sobre la que descansa VNAODV, facilita el tener una amplia gama de esquemas y protocolos auxiliares de encaminamiento por encima de esta capa, destacándose como una solución versátil para soportar comunicaciones en diferentes dominios. 2.5.3. Versión virtualizada de RIP (VNRIP) RIP (por sus siglas en inglés Routing Information Protocol) es un protocolo de encaminamiento diseñado para pequeñas redes cableadas. Se basa en un algoritmo de vector de distancia y usa la cuenta de saltos como métrica para seleccionar la ruta de encaminamiento. Las entidades de red utilizan mensajes de actualización para intercambiar información de encaminamiento. Cada entidad que participa en el proceso de encaminamiento mantiene una tabla con información de las subredes conectadas a él. Al inicio del proceso, los routers solicitan a sus vecinos una copia de su tabla de encaminamiento, de forma que los mensajes de respuesta son usados para actualizar sus propias tablas con la ruta más corta a los diferentes destinos en la red. A más de enviar periódicamente estos mensajes de actualización, RIP también permite que los mensajes de actualización puedan ser enviados por los routers a solicitud explícita de sus vecinos. Con ello se posibilita mantener rutas óptimas para todo el sistema usando solo la información obtenida desde los routers vecinos. VNRIP [240] es una versión simplificada de RIP, adaptada para trabajar en redes móviles ad-hoc y sobre la VNLayer. Al igual que RIP, los nodos virtuales, emulando los clásicos routers de las redes cableadas, precalculan las rutas a todos los destinos disponibles en la red, usando los mensajes de actualización inundados por otros VN. Tres tipos de mensajes de control se utilizan en el proceso de encaminamiento: Mensajes de solicitud, de respuesta y HELLO. Los dos primeros son también empleados en RIP y el tercero es un mensaje propio de la VNLayer. Los nodos periódicamente difunden mensajes HELLO para anunciar su presencia tanto en su región como en los VNs vecinos. De esta forma los VNs pueden conocer los nodos a los cuales pueden acceder directamente. Los mensajes de respuesta, por su parte, llevan la información de las rutas de encaminamiento presente en los VN. Esta información incluye para cada entrada, la dirección de los nodos, el próximo salto y el número de saltos necesarios para que el VN alcance el destino. Los mensajes de solicitud son usados por los VNs para buscar rutas a nodos en otros VNs vecinos. Estos mensajes sirven para buscar una ruta a un solo destino o solicitar la actualización de toda la tabla de encaminamiento desde los VNs vecinos. En las tablas de encaminamiento de los VNs, cada entrada registra el id del nodo destino, el id del próximo salto —a diferencia de RIP, el próximo salto hace referencia al siguiente nodo virtual en el trayecto—, en número de saltos entre fuente y destino, una bandera de cambio para registrar si la entrada ha cambiado o no recientemente y su tiempo de validez. Estas tablas de encaminamiento son actualizadas por medio de cuatro mecanismos: difusión de mensajes HELLO, actualizaciones parciales, actualizaciones completas y actualizaciones bajo demanda. 2.6 Sumario 71 En el primer mecanismo, los mensajes HELLO difundidos periódicamente por los nodos físicos permiten a los VNs actualizar sus tablas de encaminamiento y/o refrescar el tiempo de validez de las rutas hacia estos nodos. Además, estos mensajes HELLO son emitidos también cada vez que un nodo físico ingresa a la región de un VN (de esta forma, los VNs vecinos pueden conocer rápidamente los cambios que se generan). Un segundo mecanismo son las actualizaciones parciales (TPU, del inglés Triggered Partial Update). Cada vez que una entrada de la tabla de encaminamiento cambia, un TPU con todas las rutas modificadas es programada dentro de un intervalo de actualización (TUI, del inglés Triggered Update Interval). Mientras no finalice un TUI, ninguna nueva actualización es programada. Esto disminuye la carga de tráfico de control en la red. Un tercer mecanismo son las actualizaciones bajo demanda. Dos casos son posibles. Por una parte, un nodo virtual que es inicializado —por ejemplo, cuando un nodo físico ingresa en la región vacía cubierta por un VN— difunde un mensaje de solicitud. En respuesta a este mensaje, los VNs vecinos envían un mensaje de respuesta con su tabla de encaminamiento completa y con las entradas que tienen como próximo salto al VN solicitante configuradas como ruta inválida para prevenir bucles. Esta información permite que el VN reiniciado pueda construir su tabla de encaminamiento. Por otra parte, si un VN recibe un paquete de datos a un destino que no consta en su tabla de encaminamiento, envía un mensaje de solicitud a sus VNs vecinos. Aquellos VNs que tengan una ruta válida hacia el destino buscado responderán solo con la ruta solicitada. Finalmente una actualización completa es desarrollada periódicamente. En esta actualización los nodos difunden su tabla de encaminamiento completa. En el proceso de retransmisión de paquetes, cuando un VN recibe un paquete de datos busca en su tabla de encaminamiento una ruta disponible. Si encuentra dicha ruta, retransmitirá el paquete al próximo salto, usando una dirección de difusión. Si la ruta no es conocida, el paquete es encolado y un mensaje de solicitud es enviado a los VNs vecinos. Una vez aprendida la ruta, el paquete es retransmitido hacia el próximo salto. En el caso de RIP, los routers simplemente descartan los paquetes hacia rutas desconocidas. Para el proceso de mantenimiento de ruta, VNRIP, al igual que VNAODV, hace uso del mecanismo de acuse pasivo. El nodo destino emite un mensaje HELLO como ACK explícito. 2.6. Sumario En este capítulo, hemos revisado los principales protocolos de encaminamiento propuestos en la literatura para afrontar los problemas derivados de la movilidad de los nodos en las redes inalámbricas ad-hoc multisalto. Así, los mecanismos empleados por los protocolos proactivos otorgan a cada nodo una visión global de la red, generando respuestas rápidas a las necesidades de encaminamiento de las aplicaciones soportadas por ellos. Sin embargo, esto se logra a costa de una gran sobrecarga de tráfico de control, lo que les convierte en poco escalables. Para resolver este problema, los protocolos reactivos realizan un proceso de descubrimiento de ruta bajo demanda. Este procedimiento, si bien disminuye la sobrecarga de control en redes grandes y altamente 72 Mecanismos para hacer frente a la movilidad en las redes inalámbricas ad-hoc dinámicas con respecto a los protocolos proactivos, sigue teniendo una alta sobrecarga de tráfico de control al inundar la red con paquetes RREQ. Además los tiempos empleados en el establecimiento de las rutas generan retardos en el inicio del envío de los datos mucho mayores que los alcanzados con protocolos proactivos. Formar grupos de nodos estructurados en forma jerárquica (clusters) permite reducir esta sobrecarga, al limitar los intercambios de información inter o extra cluster a unos pocos nodos seleccionado en la red. Si bien, esta estructura permite lograr una mayor escalabilidad, también genera puntos únicos de fallo tanto en los nodos líderes como en los nodos pasarela que conectan a dos o más clusters. Un aproximación para resolver ese problema es el uso de múltiples trayectos; sin embargo esta solución requiere de un mayor consumo de memoria e incremento en la sobrecarga de tráfico de control para el mantenimiento de las rutas. Una visión diferente es seguida por los protocolos geográficos. En estos algoritmos, el proceso de encaminamiento se basa en la localización del nodo destino más que en su dirección de red, lo que permite disminuir considerablemente la sobrecarga de control. No obstante, su rendimiento depende en gran medida de la exactitud y antigüedad de la información de localización. Otro inconveniente es el hecho de que muchos de estos protocolos asumen que los nodos tienen acceso a servicios de localización para conocer la ubicación del destino, lo cual dista mucho de los escenarios reales actuales. En el contexto de las VANETs, el problema de las redes inconexas de larga duración ha sido manejado a través de mecanismos como carry and forwarding, en el que la movilidad de los nodos se convierte en parte de la solución para el transporte físico de paquetes, enfocándose principalmente a la provisión de servicios tolerantes al retardo. De igual forma, en el caso de la ruptura de trayectos, los patrones de movilidad de los vehículos han sido usados como medio para anticiparse a esos quiebres o para generar rutas más robustas entre nodos con movimientos similares. La capa de virtualización (VNLayer), por su parte, basa su funcionamiento en la conformación de clusters; sin embargo, a diferencia de los protocolos de encaminamiento de este tipo, la VNLayer trabaja como una capa independiente en la pila de protocolos, lo que le permite ocultar las complejidades de los procesos de conformación y mantenimiento del cluster a las capas superiores. Esta aproximación nos brinda un soporte adecuado para mejorar el rendimiento de protocolos de encaminamiento existentes o generar otros nuevos que integren muchos de los mecanismos desarrollados en la literatura para hacer frete a los problemas derivados de la movilidad. No obstante, estas capacidades de la VNLayer no han sido suficientemente analizadas en la literatura para determinar su rendimiento en el soporte de servicios de comunicaciones en escenarios genéricos (pedestres, vehiculares y mixtos) y con aplicaciones más demandantes. Por ello, en lo que sigue de este trabajo doctoral estudiaremos las ventajas e inconvenientes de la VNLayer, proponiendo un conjunto de mejoras y nuevos mecanismos para incrementar su rendimiento en diferentes escenarios y con aplicaciones orientadas a la computación social ubicua. Parte II Mejoras a la capa de virtualización 73 Capítulo 3 Mejoras a la capa de virtualización en entornos MANET En este capítulo presentamos las mejoras desarrolladas a los procedimientos de la VNLayer para su funcionamiento en entornos MANET. En concreto, introducimos nuevos mecanismos para incrementar la fiabilidad y capacidad de respuesta de los nodos virtuales y aumentar el rendimiento del protocolo de encaminamiento virtualizado VNAODV. 3.1. Introducción Para iniciar nuestro trabajo con la VNLayer y con VNAODV, replicamos sus implementaciones siguiendo los extensos detalles incluidos en [240], luego procedimos a validar el software generado ejecutando algunos de los experimentos de simulación presentados en [182,241]. Los resultados fueron prácticamente idénticos a los ya publicados, por lo que pasamos a usar VNAODV en diferentes escenarios. Esto nos permitió identificar las siguientes fuentes de ineficiencia en los constructos de la VNLayer: El diseño de la ubicación estática de las VNs, cubriendo zonas de igual tamaño y forma —similar a una rejilla cuadricular, (ver figura 2.15)—, direccionado solo por las coordenadas GPS, descuida la presencia de obstáculos (paredes o edificios) y las condiciones de propagación adversas para las comunicaciones dentro de cada región y entre regiones vecinas. El procedimiento para la elección del líder, tal como se muestra en la figura 2.17, podría reaccionar muy lentamente cuando el líder abandona la región (por ejemplo, para la recepción de mensajes M_LeaderLeft), debido, principalmente, a los tiempos de espera en el estado UNKNOWN. Esto incide fuertemente en las comunicaciones durante periodos con movilidad media o alta, dado que los VNs no proveerán el servicio durante una porción no despreciable de tiempo a los nodos que permanecen dentro de la región. 75 76 Mejoras a la capa de virtualización en entornos MANET La duplicidad de liderazgo (resultantes de la pérdida de paquetes durante la elección del líder) se trató de una manera simplista, lo que permite que un nodo que acaba de llegar a la región, sin información del estado de las capas superiores, pueda imponerse a un líder de mayor trayectoria y con una gran cantidad de datos valiosos. El procedimiento para la elección del líder también podría designar como nuevo líder a un nodo que no actuaba como backup o un nodo backup no sincronizado con su anterior líder, incluso en los casos en el que hubiera backups sincronizados en la región. Como resultado, los intercambios previos de mensajes M_SyncRequest y M_SyncAck se convertirían en una sobrecarga de tráfico de control sin sentido, dado que se perdería innecesariamente información de estado de las capas superiores, activando nuevas sincronizaciones. Debido a la naturaleza probabilística del proceso de designación de los backups (ver sección 2.5.1), siempre existirá la posibilidad de que ningún nodo no-líder escoja trabajar como backup. No tener nodos backups (o pocos) en una región tiene un impacto significativo en la capacidad de recuperación de los nodos virtuales1 . Para empeorar las cosas, no existían mecanismos para sustituir los nodos backups salientes por otros nodos no-líder presentes en la región; solo los nodos recién llegados podrían tomar su lugar. La máquina de estados no permite a un nodo líder renunciar a su rol hasta dejar su actual región, implicando el riesgo de hacer una gran cantidad de trabajo a favor de otros nodos por un periodo largo de tiempo, y por tanto, incurrir en un mayor consumo de batería. Finalmente, un aspecto crítico que encontramos en nuestro análisis es que la VNLayer no hace ningún intento por preservar el estado de los VNs cuando sus regiones quedan vacías, sin el soporte de los nodos físicos. Este problema no se mostró en las simulaciones presentadas en [182, 241] debido a que los modelos de movilidad aleatoria producían una distribución bastante uniforme de los nodos físicos (PNs, del inglés Physical Nodes) sobre las diferentes regiones. Sin embargo, los movimientos de los nodos en aplicaciones prácticas no son del todo aleatorios y de tiempo en tiempo las regiones quedan con un soporte mínimo de nodos físicos, lo que implica un aumento de la probabilidad de errores en los VNs. En su conjunto, estas ineficiencias resultaron en pérdidas frecuentes de información de estado desde las capas superiores, tablas de encaminamiento incongruentes, tráfico de datos ampliado, bucles de encaminamiento, eliminación incorrecta de paquetes y un aumento en la sobrecarga de tráfico de control en general. En las secciones siguientes analizaremos los diferentes mecanismos que hemos propuesto para resolver estos inconvenientes en la nueva VNLayer, a la que hemos denominado VNLayer+. Luego, introducimos un conjunto de refinamientos y nuevos mecanismos a VNAODV en una versión mejorada a la que llamamos VNAODV+. Finalmente, presentaremos los resultados y la discusión de los experimentos de simulación desarrollados en escenarios 1 En el extremo opuesto, el hecho de que todos los nodos no-líder pudieran decidir de forma autónoma si convertirse o no en un backup también implica el riego de tener demasiados backups en una región, incrementando la sobrecarga de tráfico de control debido a los procesos de sincronización de estado. Es cierto, sin embargo, que esto solo ocurrió ocasionalmente en nuestros experimentos. 3.2 VNLayer+: Mejoras a la VNLayer 77 relacionados con la computación social ubicua; en concreto, sobre una aplicación para aprendizaje colectivo y de inmersión acerca de la historia en museos y sus alrededores. 3.2. VNLayer+: Mejoras a la VNLayer En términos generales, hicimos las siguientes mejoras: (i) modificamos las interfaces superiores para permitir que la posición, ancho y vecinos de cada región puedan ser decididos por los desarrolladores de cada aplicación; (ii) diseñamos un procedimiento más sencillo para acelerar la elección del líder, dando prioridad a los backups sincronizados sobre los no sincronizados, y los backups no sincronizados sobre los restantes no-líderes; (iii) definimos una forma para que los nodos líderes entreguen su rol a otro nodo con el fin de ahorrar batería; (iv) modificamos el proceso de designación de nodos backups para asegurar que el número de este tipo de nodos en la región permanezca dentro de ciertos valores máximo y mínimo; (v) se introdujo un mecanismo que permite el manejo de instantáneas de la información de estado de las regiones vecinas; (vi) hicimos algunos cambios en la interfaz a la capa de red que hace que los protocolos virtualizados puedan cuidar de las regiones vecinas y conocer con certeza si los paquetes que ellos envían serán transmitidos por unicast o por broadcast, lo cual es importante en tanto que los dos modos de transmisión proporcionan diferentes garantías (sección 2.2.2). 3.2.1. Disposición de los VNs acorde a la aplicación Como se señaló en la sección 2.5.1, la VNLayer divide el área de una MANET en regiones cuadradas sobre una rejilla, cuyo ancho es escogido solo como una función del rango teórico de transmisión de los dispositivos. Esta distribución puede ser apropiada para aplicaciones en la cual los nodos se mueven en un espacio abierto, pero ciertamente no lo es para ambientes en el interior de edificios o en el exterior de ellos en entornos urbanos, en la medida que los edificios, paredes, aparatos eléctricos y vehículos pueden provocar pérdidas significativas debido a la reflexión, absorción o ruido [192]. Para evitar que estas pérdidas causen un mal funcionamiento de los procedimientos de virtualización, la VNLayer+ deja las tareas de localización y la definición de las regiones de los nodos virtuales en manos de quienes diseñan e implementan las aplicaciones. Esto puede ser visto claramente como una elección natural, puesto que los desarrolladores son quienes están bien informados acerca de la disposición de las áreas en las que los usuarios se moverán, los mecanismos disponibles para localizar a los usuarios, el número y la colocación de los repetidores o puntos de acceso Wi-Fi, etc. Nuestra solución es enteramente local, es decir, no requiere de comunicaciones entre los nodos. Las aplicaciones solo necesitan enviar un paquete especial a la dirección de loopback 127.255.255.255 siempre que un cambio de región es detectado por el mecanismo de localización (ver [87] para un mayor detalle de sistemas de posicionamiento en ambientes en el interior de edificios). El paquete contiene el ID de la región a la cual ha entrado recientemente y de las regiones vecinas con las cuales es posible comunicarse directamente. Este paquete va a través de la pila de protocolos hasta ser usado por la VNLayer+ para comprobar su localización y desencadenar las acciones apropiadas desde el estado INITIAL del procedimiento de elección de líder. 78 Mejoras a la capa de virtualización en entornos MANET Con este mecanismo es posible ir más allá de las regiones que son iguales en forma y tamaño, habilitando comunicaciones entre ambientes en el interior y exterior de los edificios. La figura 3.1 muestra una distribución de VNs alrededor de las Catedrales vieja y nueva de Cuenca (Ecuador), en ella se representan las regiones internas, externas y mixtas con diferentes colores. Esta disposición de los nodos virtuales es usada en algunos escenarios de simulación, los cuales son analizados más adelante en la sección 3.4. Figura 3.1: Regiones de nodos virtuales superpuestos a una parte del centro de Cuenca, Ecuador. 3.2.2. Un nuevo proceso para la elección del líder Nuestro nuevo procedimiento para la elección del líder aborda el problema de una reacción lenta de los nodos frente a la salida de un líder de la región, eliminando el estado UNKNOWN y reorganizando las transiciones entre los estados restantes, como se muestra en la figura 3.2. También hemos eliminado el estado UNSTABLE, pero esto solo debido a que era redundante en el uso de un contador de vencimientos del temporizador T_Heartbeat. Los mayores cambios que hemos desarrollado son los siguientes: Primero, cuando los no-líderes reciben el mensaje M_LeaderLeft tras la partida del líder, ellos cambian su estado a REQUEST y arrancan sus temporizadores T_RequestWait. El PN cuyo temporizador expira primero se convierte en LEADER e inmediatamente envía un mensaje M_Heartbeat para forzar a que los otros nodos cambien su estado a NON-LEADER. No existe el T_LeaderRequest como en [240] (lo cual implica menos tiempo de espera) y los valores iniciales de los temporizadores T_RequestWait son seleccionados para asegurar que el mejor candidato posible es escogido como nuevo líder: valores bajos para nodos que 3.2 VNLayer+: Mejoras a la VNLayer 79 fueron backups sincronizados, valores medios para backups no sincronizados y valores altos para los otros nodos no-líderes2. Un nuevo mecanismo que permite evitar por completo los tiempos T_RequestWait. Como explicaremos a continuación, en la sección 3.2.4, este mecanismo permite establecer prioridades entre los nodos backup sincronizados, de modo que el que tiene la prioridad más alta (indicada por MaxPriority en la figura 3.2) puede cambiar inmediatamente su estado de NON-LEADER a LEADER. Cuando un nodo se mueve a una nueva región, su estado cambia directamente a REQUEST e inmediatamente compite por el liderazgo difundiendo un mensaje M_LeaderRequest. Si en la región ya existe un líder, el recién llegado recibirá un mensaje M_LeaderReply y cambiará su estado a NON-LEADER; de lo contrario, este nodo se convertirá en líder en un tiempo mucho más corto que lo que es posible con el procedimiento de [240]. Este enfoque acelera el levantamiento del estado de los nodos virtuales en aquellas regiones que han quedado sin el soporte de PNs y también acorta los tiempos de parada debido a la pérdida de los mensajes M_LeaderLeft: en lugar de esperar por dos periodos T_Heartbeat, es suficiente esperar hasta que un nodo nuevo llegue a la región. INITIAL in: expire(T_Heartbeat) out: send(M_Heartbeat); start(T_Heartbeat); in: RegionKnown out: start(T_RequestWait); in: expire(T_Heartbeat) AND expires==2 out: start(T_RequestWait); in: expire(T_RequestWait) out: send(M_Heartbeat); start(T_Heartbeat); REQUEST LEADER in: RegionChange out: send(M_LeaderLeft); send(M_LeaderRequest); start(T_RequestWait); in: recv(M_LeaderLeft) AND NOT MaxPriority out: start(T_RequestWait); in: RegionChange out: send(M_LeaderRequest); start(T_RequestWait); in: recv(M_Heartbeat) OR recv(M_LeaderReply) out: start(T_Heartbeat); expires=0; NONLEADER in: expire(T_Heartbeat) AND expires<2 out: start(T_Heartbeat); expires++; Fig. 7. in: recv(M_Heartbeat) out: start(T_Heartbeat); expires=0; in: BatteryAlert out: send(M_LeaderLeft); MinPriority=true; in: recv(M_Heartbeat) out: start(T_Heartbeat); expires=0; in: recv(M_LeaderLeft) AND MaxPriority out: send(M_Heartbeat); start(T_Heartbeat); The state machine of our new leader election procedure. Figura 3.2: La máquina de estados de nuestro nuevo proceso de elección de líder. Un cambio adicional es indicado por la nueva transición desde LEADER a NONLEADER, disparada por el evento BatteryAlert. Esta transición permite a un nodo líder renunciar a su rol en caso de que haya soportado la carga de ser un VN durante mucho tiempo o su batería esté aproximándose hacia un nivel bajo. En este caso, el nodo difunde un mensaje M_LeaderLeft como es usual y se convierte en un nodo backup 2 Cada nodo añade un pequeño valor aleatorio al T_RequestWait para prevenir colisiones y/o liderazgos duplicados que pudieran ocurrir, por ejemplo, cuando los temporizadores de varios backups sincronizados son iniciados simultáneamente y por tanto expiran en exactamente el mismo tiempo. 80 Mejoras a la capa de virtualización en entornos MANET (obviamente, sincronizado) con la mínima prioridad. En esta forma, nosotros evitamos el problema de que un único nodo pueda enfrentarse a un pico de consumo de su batería solo porque ha sido designado como líder de una región en el que se mantienen durante mucho tiempo. En lugar de eso, un grupo de nodos puede turnarse para actuar como líderes en una forma colaborativa. 3.2.3. Manejo del liderazgo duplicado El hecho de que haya menos mensajes y tiempos de espera involucrados en la elección del líder que en la versión previa de la VNLayer puede conllevar un mayor riesgo de un liderazgo duplicado con mayores niveles de pérdida de paquetes (ya sea por el ruido o colisiones). Por ejemplo, si dos nodos, PN X y PN Y, se precipitan a un estado REQUEST luego de escuchar un mensaje M_LeaderLeft enviado desde el líder anterior, aquel nodo cuyo temporizador T_RequestWait expire primero (por ejemplo, PN X) cambiará a LEADER y difundirá un M_Heartbeat; sin embargo, si este mensaje se pierde, el temporizador T_RequestWait de PN Y expirará poco después y PN Y también cambiará su estado a LEADER. De la misma forma, un nodo que acaba de llegar a la región puede entrar al estado de LEADER, incluso si ya existe un líder solo por el hecho de que un M_LeaderReply enviado al NO-LEADER se pierde. Con la máquina de estados de la figura 2.17, los liderazgos duplicados aparecerán después de la pérdida de dos mensajes (por ejemplo, M_LeaderRequest y M_Heartbeat); con nuestra propuesta, se necesita solo la pérdida de uno. El liderazgo duplicado puede ser muy perjudicial. Por ejemplo, si se trata de un algoritmo de encaminamiento como VNAODV que se encuentra ejecutándose sobre la capa de virtualización, el liderazgo duplicado implica que un nodo virtual puede enviar el mismo mensaje de datos múltiples veces hacia el siguiente salto, haciendo que el tráfico de datos se amplifique. En segundo lugar, ya que los nuevos auto-proclamados líderes pueden no tener conocimiento de las rutas, los paquetes de datos enviados a través de ellos pueden desencadenar una incorrecta eliminación de paquetes de datos y un innecesario proceso de descubrimiento de ruta. Esto interrumpe la retransmisión de datos e incrementa la sobrecarga de tráfico de control. En tercer lugar, cuando hay varios líderes en una región, cada uno con diferente información de estado desde las capas superiores, cada mensaje entrante podría generar un proceso de sincronización de estado en la región, aumentado la sobrecarga de control por sincronización, lo cual a su vez podría incrementar aún más el problema de la duplicidad de liderazgo. El mecanismo implementado en [182,240,241] para hacer frente a la duplicidad de liderazgo es representado por la transición desde el estado LEADER a NON-LEADER en la figura 3.2: cualquier líder abandona su rol inmediatamente después de escuchar un M_Heartbeat difundido por otro líder. De esta forma, la situación rara vez dura más de un periodo de tiempo que pasa entre la difusión de los M_Heartbeat, pero no hay garantía en cuanto a qué líder mantendrá su rol: por ejemplo, un advenedizo sin información de estado desde las capas superiores puede expulsar a un líder de larga data con una gran cantidad de datos valiosos. Para evitar esta fuente de problemas, hemos introducido un nuevo campo en el mensaje M_Heartbeat denominado Since para indicar cuándo exactamente el nodo emisor pasó al estado de LEADER. Siempre que un nodo líder recibe un M_Heartbeat compara el valor del campo Since con el tiempo de su liderazgo: si el mensaje proviene de un líder anterior, el nodo abandona el liderazgo; de lo contrario, responde después de un pequeño retardo aleatorio mediante la difusión de su propio M_Heartbeat para asegurar su posición. Como resultado, solo 3.2 VNLayer+: Mejoras a la VNLayer 81 el mejor líder persiste y los problemas debido a la duplicación de liderazgo se pueden reducir drásticamente. 3.2.4. Un nuevo enfoque para la designación de los nodos backup El primer objetivo de nuestro enfoque para la designación de backups es asegurar que el número de nodos backup en el interior de la región se mantiene, siempre que sea posible, dentro de un mínimo (para garantizar la capacidad de recuperación de los nodos virtuales frente a la salida de los nodos líderes) y un máximo determinado (para evitar la excesiva sobrecarga de sincronización). Con este objetivo, el líder informa el número de backups en la región en cada M_Heartbeat que difunde, de forma tal que los otros nodos no-líderes pueden aprender si deberían ofrecerse o no para dar soporte al VN. De esta manera, convertirse en un backup ya no es una decisión fortuita y autónoma como en [182, 240, 241], sino más bien soportada e informada por el líder. Los PNs que optan para convertirse en nodos backup difunden cada uno un mensaje M_SyncRequest—después de un tiempo aleatorio controlado por un nuevo temporizador, T_BackupRequest, para evitar colisiones— para sincronizar su estado con el líder. Luego, el líder responde a los recientemente aceptados backups enviando la información de estado en un nuevo mensaje (M_SyncData) vía unicast y, finalmente, aquellos nodos confirman que se han convertido en backups por la difusión de un mensaje M_SyncAck. Tres mensajes de sincronización son manejados en lugar de dos, pero los acuses de recibo explícitos previenen al líder de depender de un número errado de backups sincronizados en caso de que los mensajes M_SyncData se pierdan. Por la misma razón, cualquier nodo backup abandonando la región difunde un nuevo mensaje, M_BackupLeft, para anunciar que algún otro nodo debe tomar su lugar. Hay dos aspectos que señalar sobre el citado intercambio de mensajes: Por una parte, los mensajes M_SyncData son enviados vía unicast para disfrutar de la posibilidad de detectar errores en las transmisión por medio de notificaciones desde la capa de enlace. Aquellos mensajes son potencialmente grandes ya que llevan información de estado, la cual es muy importante y debe transmitirse correctamente. Por otra parte, los mensajes M_SyncRequest, M_SyncAck y M_BackupLeft son enviados vía broadcast para asegurar que puedan ser escuchados por todos los nodos, de modo que puedan mantener réplicas de las tablas de los backups en la región (B_table). Cada entrada de esas tablas contienen la dirección física de un nodo backup junto con su estado (sincronizado o no) y el nivel de prioridad que permite la sustitución inmediata como se explicó en la sección precedente. La gestión de las prioridades es bastante simple. Cada no-líder que aplica para convertirse en un backup aparece en la tabla B_table con un nivel de prioridad igual al número de nodos backup reportados en el último mensaje desde el líder, más el número de mensajes M_SyncRequest enviados por otros nodos solicitantes antes de la expiración de su temporizador T_BackupRequest. Además, los mensajes M_BackupLeft sirven para borrar entradas desde la tabla B_table, lo cual implica que los nodos con niveles de prioridad inferiores al backup saliente pueden subir un nivel. Por ejemplo, asumamos que los nodos no-backups PN X y PN Y reciben un mensaje desde el líder indicando que actualmente no existen backups (0) en la región. Dado que está, 82 Mejoras a la capa de virtualización en entornos MANET obviamente, por debajo del mínimo, los dos nodos se preparan para solicitar convertirse en backups inicializando sus respectivos temporizadores T_BackupRequest con un valor aleatorio. Si el temporizador de PN X expira primero, difundirá un mensaje M_SyncRequest y asumirá un nivel de prioridad 0, el cual es el más alto, obteniendo así MaxPriority=true. A su vez, PN Y al escuchar el M_SyncRequest de PN X asumirá el nivel de prioridad 1 (0 + 1), obteniendo así MaxPriority=false. Si PN X sale de la región poco después, PN Y escuchará el mensaje M_BackupLeft y accederá al nivel de prioridad 0 y MaxPriority=true. 3.2.5. Manteniendo la información de estado para sincronizar nodos advenedizos La existencia de las réplicas de la tabla B_table en todos los nodos de una región es la clave para evitar la pérdida de información de estado de las capas superiores cuando un nodo recién llegado asume el liderazgo poco después de que el anterior líder ya dejó la región, superando a los backups sincronizados que no hayan recibido el correspondiente M_LeaderLeft. El advenedizo (recién llegado) no tiene la información de estado del nodo virtual de la región, pero los backups sincronizados sí. Así que, cuando el nodo que acaba de llegar difunde su primer M_Heartbeat, erróneamente informará que el número de backups en la región es 0 y los nodos backups identificarán fácilmente la situación. En tales casos, la acción más rápida y robusta por hacer es que el backup de más alta prioridad responda con un mensaje M_SyncData incluyendo no solo la información de estado de las capas superiores, sino también la tabla B_table, la tabla de actividad de la región y el listado de vecinos (sección 2.5.1), de modo que el nuevo líder pueda empezar a trabajar tal como el líder precedente en un tiempo muy corto. Nosotros llamamos a este procedimiento una sincronización de advenedizo. 3.2.6. Gestionando las regiones vecinas a través de instantáneas de su estado En el VNLayer, si una región se queda sin el soporte de PNs, el VN colapsa y la información de estado de las capas superiores se pierde, sin importar cuánto tiempo dure esta situación. Un nodo puede entrar en la región dentro de un plazo muy corto y convertirse en su líder inmediatamente, pero va a tener que empezar a construir un nuevo estado para el VN desde cero. Esto puede ser una importante fuente de problemas en las comunicaciones, apareciendo especialmente en simulaciones con patrones de movimiento no aleatorias. Con VNAODV ejecutándose sobre la VNLayer, por ejemplo, las tablas de encaminamiento desaparecen y todos los trayectos de comunicación que atraviesan esta clase de regiones se rompen, causando pérdidas de paquetes y desencadenando una amplia difusión de paquetes de control para repararlos. Con el fin de prevenir tales efectos, la VNLayer+ implementa un nuevo mecanismo que proporciona un marco para que los protocolos en la capa de red lidien no solo con regiones vacías, sino también con otras situaciones transitorias (por ejemplo, tras la elección de un nuevo líder). El nuevo mecanismo aprovecha el hecho de que las transmisiones desde un PN pueden ser escuchadas, por lo menos, en su región y en las vecinas. Para empezar, cuando un nodo líder deja su región (por ejemplo, la región A), no descarta la información de estado que estaba manejando, sino que la transfiere a la mayor brevedad 3.3 VNAODV+: Mejoras a VNAODV 83 posible al líder de la nueva región en la que entra (digamos, la región B) en un mensaje especial M_SyncData—el ex líder de la región A borra la información de estado almacenada en su memoria al recibir el mensaje M_SyncAck. Nosotros denominamos a este mecanismo sincronización de vecino. Con la instantánea del estado de la región A en la memoria, la VNLayer+ llama a una nueva función de la interfaz de la capa de red (receiveForNeighbourRegion()) cada vez que escucha un mensaje desde o hacia esa región. El número de nodos vecinos que se encuentran actualmente en la región A (según los datos de la lista de vecinos) se pasa como argumento, junto con la información de estado. Mediante la implementación de esta función, los algoritmos de la capa de red pueden decidir qué hacer cuando la región A está vacía o cuando no está vacía pero el líder parece no comportarse de una manera coherente. El valor devuelto indica si la VNLayer+ debe descartar inmediatamente la instantánea de estado (valor de retorno -1), mantenerla indefinidamente (0) o guardarla durante el número de milisegundos devueltos como un número positivo. La VNLayer+ toma medidas por sí misma cuando tiene una instantánea de estado en la memoria para una región que está vacía. Asumamos, por ejemplo, que la región A está vacía y el líder de la región vecina B tiene una instantánea de la región proporcionada por el último nodo saliendo de la misma. Cuando un nuevo nodo entra a la región A, asume el papel de líder de inmediato y difunde su primer mensaje M_Heartbeat. Al escuchar este mensaje, el líder de la región B responderá con un mensaje M_SyncData que contiene la información de la instantánea (este es otra sincronización de vecino). El estado anterior es restaurado y los protocolos trabajando en las capas superiores a la de virtualización tienen un menor impacto debido a los errores transitorios del VN. 3.2.7. Un cambio adicional en la interfaz a la capa de red Con la interfaz ofrecida a la capa de red por el VNLayer, como se explica en la sección 2.5.1, un protocolo puede tener la intensión de enviar un paquete a un nodo específico, pudiendo ser este realmente transmitido vía unicast o broadcast. Esto implica que el protocolo no puede depender de algún subconjunto específico de servicios de la capa de enlace, por lo que es necesario complementarlo con mecanismos de la capa de red. En el caso de VNAODV, por ejemplo, era obligatorio implementar los acuses de recibo pasivos para afrontar la ruptura de enlace (sección 2.5.2), a pesar de que la detección es mucho más lenta que solo con las notificaciones de la capa de enlace. La VNLayer+ proporciona dos funciones adicionales y diferentes para el envío de paquetes (sendBroadcast() y sendUnicast()) con el fin de permitir a los protocolos de las capas superiores decidir explícitamente si transmiten los paquetes por unicast o por broadcast. Los protocolos de la capa de enlace normalmente definen diferentes medios para usar uno de los dos métodos y muchos protocolos de la capa de red han sido diseñados sobre esa base. Además nuestra experiencia con VNAODV ha demostrado que dejar la elección a la VNLayer no proporciona ninguna ventaja significativa sino que más bien hace las cosas más complicadas e ineficientes. 3.3. VNAODV+: Mejoras a VNAODV Durante la implementación de VNAODV según los detalles que figuran en [240], hemos identificado varias posibles ineficiencias que luego fueron confirmadas por nuestros experimentos de simulación. Estas deficiencias en la capa de red se acumulan a las 84 Mejoras a la capa de virtualización en entornos MANET limitaciones de la VNLayer discutidas en la sección 3.1. Al respecto, ya se observó en [240] que cualquier error en la capa de virtualización para preservar la información de estado supone un riesgo de retransmitir paquetes dentro de rutas de encaminamiento sin salida o que forman bucles, lo cual es completamente indeseable. A continuación presentamos nuestras propuestas para la capa de red, las cuales hemos incluido en una versión mejorada de VNAODV llamada VNAODV+. Los principales objetivos son: (i) evitar el uso excesivo de broadcast, (ii) el perfeccionamiento del procedimiento de corrección de ruta de [240] para evitar algunas pérdidas de paquetes y (iii) la introducción de un nuevo mecanismo para evitar rupturas de enlaces, incluso cuando nodos líderes intermedios abandonan sus regiones. 3.3.1. Retornando a los esquemas de transmisión de AODV Una fuente importante de problemas con VNAODV fue el hecho de que los paquetes de control y de datos podrían ser entregados por broadcast, incluso si estaban destinados a un nodo determinado —específicamente, la VNLayer podría usar broadcast en lugar de unicast cuando la tabla de actividad de la región de uno nodo no contenía la dirección MAC del siguiente salto (sección 2.5.1). Como se muestra en [240], el usar broadcast en la transmisión hace que las comunicaciones sean menos fiables, necesitando implementar acuses de recibo pasivos para el mantenimiento de la ruta (sección 2.5.2), lo que implica que los enlaces serán marcados como rotos solo después de un cierto periodo de inactividad. En consecuencia, las acciones de reporte o reparación de ruta son iniciadas en forma mucho más lenta que en AODV, hasta el punto que no pueden seguir el ritmo del movimiento de los nodos. AODV utiliza unicast cada vez que se sabe qué nodo está destinado a recibir un paquete, dejando la transmisión por broadcast solo para paquetes que pueden ser procesados por cualquier nodo (como es el caso de los paquetes RREQ utilizados para el descubrimiento de rutas). Gracias a las modificaciones en la interfaz de la VNLayer+ con respecto a la VNLayer (sección 3.2.7), se puede seguir el mismo enfoque en VNAODV+, asegurando que los paquetes de control como RREP y RERR y los paquetes de datos son transmitidos a través de unicast entre los líderes de los VNs. Para este objetivo, las entradas de las tablas de encaminamiento contienen no solo el ID de la región de la siguiente VN en las rutas (campo next_region), sino también la dirección IP del nodo que se espera maneje los mensajes allí (campo next_hop). Con el fin de preservar la capacidad de mantener sincronizados a los nodos backups y líderes, configuramos la capa de enlace en el modo promiscuo, de modo que maneje todos los paquetes que oye en el medio inalámbrico compartido (independientemente de la dirección MAC, el ID de la región o la dirección IP) para la VNLayer+, que a su vez los envía hacia VNAODV+. En la capa de red, cada PN puede procesar los paquetes según su rol, al igual que en VNAODV: los líderes y backups procesan los paquetes de control para actualizar sus tablas de encaminamiento, los líderes reenvían los paquetes hacia los próximos saltos, los backups hacen comprobaciones de coherencia, etc. De esta manera, VNAODV+ está menos expuesto a las colisiones que VNAODV, puede manejar notificaciones desde la capa de enlace para detectar roturas de enlace más rápido y, finalmente, se libera de la carga computacional de mantener el seguimiento de los acuses de recibo pasivos. 3.3 VNAODV+: Mejoras a VNAODV 85 3.3.2. Un nuevo proceso de corrección de ruta Nuestro segundo punto de preocupación acerca de VNAODV hace referencia al procedimiento de corrección de ruta para el destino como se explica en la sección 2.5.2. Este mecanismo sirve para evitar una serie de rupturas en los enlaces cuando los nodos destino se mueven, pero si cambiamos los esquemas de transmisión de la capa de virtualización como se explicó anteriormente, un defecto sutil parece que causa la eliminación de paquetes en los PNs que soportan el tráfico pesado (principalmente, porque estos nodos se encuentran en medio de varias rutas de comunicación). Si retomamos el ejemplo de la figura 2.18 con el reenvío de paquetes salto a salto (en vez de región a región) obtenemos la figura 3.3. Es aún evidente que las correcciones de ruta sirven para acortar los trayectos y reducir los tiempos de entrega de paquetes, pero hay una deficiencia. 8 0.2 1.2 2.2 3.2 7 1 2 0.1 6 1.1 2.1 3.1 3 4 0.0 Sin corrección de ruta Con corrección de ruta 1.0 Región 3.1 2→3→5→6 2→3→5→6 2.0 Región 2.1 2→3→5→6 2→3→6 5 Líder Cliente 3.0 Región 2.2 2→3→5→7→6 2→3→7→6 Región 1.2 2→3→5→7→6 2→6 Figura 3.3: Evolución de la ruta de comunicación de VNAODV+ entre dos PNs cuando uno de ellos se mueve, con y sin corrección de rutas. Para ilustrar el problema, consideremos el momento en que PN 6 está en la región de 2.1 y recibe un paquete dirigido a él, pero en el campo next_region indica 3.1. En respuesta a este desajuste, el procedimiento de corrección de ruta de Wu et al. haría que PN 6 difunda un mensaje RREP no solicitado, que será procesado por los nodos líderes PN 3, PN 5, PN 7 y PN 8 para actualizar sus tablas de encaminamiento. Las tablas de actividad de la región manejadas por PN 5, PN 7 y PN 8 en la capa de virtualización ya contendrán el mapeo de las direcciones IP y MAC del PN 6 (porque era líder de una región vecina), por lo que las rutas renovadas podrán ser usadas sin demora. En contraste, la tabla de vecinos de la región de PN 3 podría no contener ese mapeo, porque PN 6 nunca había sido su vecino antes. Por lo tanto, la ruta corta 2→3→6 no será funcional hasta que PN 3 y PN 6 hayan completado un intercambio de mensajes ARP (Address Resolution Protocol). Durante ese tiempo, PN 3 encolará los paquetes 86 Mejoras a la capa de virtualización en entornos MANET para la ruta 2→3→6. Así que, si hay muchas rutas pasando por la región 1.0 y sucede que varias correcciones de ruta están teniendo lugar al mismo tiempo, PN 3 estaría expuesto al riesgo de un desbordamiento de su buffer. El problema de pérdidas de paquetes con el procedimiento de corrección de ruta de Wu et al. surge porque las entradas de las tablas de encaminamiento obtienen nuevos next_hop antes de que las direcciones MAC de los nodos correspondientes sean conocidas. En respuesta a eso, hemos cambiado las comunicaciones de la siguiente manera: (I) Cuando un nodo de destino (por ejemplo, PN B) da cuenta de un valor errado de next_region en un paquete recibido, difunde un mensaje de RREQ como si estuviera tratando de descubrir una ruta al nodo de origen (por ejemplo, PN A), pero indicando TTL=1. (II) Cuando el mensaje RREQ es procesado por los líderes de los VNs vecinos, envían mensajes RREP por unicast a PN B, indicando si pueden alcanzar a PN A y cómo se llega a él a través de ellos. (III) Por último, PN B envía un mensaje RREP final a través de unicast a cada uno de los nodos que respondieron, de manera que puedan actualizar la entrada correspondiente a PN B en sus tablas de encaminamiento. Con este procedimiento, todos los líderes vecinos tendrán sus rutas hacia el nodo de destino corregidas solo después de haber intercambiado mensajes unicast RREP con él. Por lo tanto, sus tablas de actividad de región siempre contendrán el mapeo IP-MAC necesario y las rutas renovados podrán ser utilizadas sin demora. Con ello, se evita el riesgo de desbordamiento del buffer y la pérdida de paquetes. Es cierto que, el intercambio de mensajes necesita algún tiempo para ser completado, pero esto no causa ningún problema porque los paquetes se transmiten a través de las rutas originales (sin corregir) en el ínterin. 3.3.3. Un procedimiento de soft handoff El reenvío de paquetes a través de unicast, como se explica en la sección 3.3.1, plantea la cuestión de qué sucede cuando el líder abandona su región, ya que los pares (next_region, next_hop) en las tablas de encaminamiento de los líderes vecinos no serán correctos por más tiempo. En la figura 3.4, por ejemplo, supongamos que se ha establecido una ruta entre PN 1 y PN 4 a través de PN 2 (originalmente, el líder de la región 1.0). La tabla de encaminamiento de PN 1 tendrá una entrada con la dirección IP de PN 4 como destino, la región 1.0 como next_region y la dirección de PN 2 como next_hop; mientras que la tabla de encaminamiento de PN 2 tendrá una entrada con la dirección IP de PN 4 como destino, la región 2.0 como next_region y la dirección IP de PN 4 como next_hop. Después de que PN 2 se mueve a la región 1.1, los valores de next_hop todavía sirven para la entrega de paquetes desde PN 1 a PN 4, debido a que PN 2 se mantiene dentro del alcance de ambos extremos. Sin embargo, cuando PN 2 entra a la región 2.1, se pone fuera del alcance de PN 1 con lo que la ruta se rompe. Recuperarse de esta situación necesariamente lleva algún tiempo, incluso si se detecta mediante una notificación desde la capa de enlace. Sin embargo, ese tiempo puede ser evitado gracias a un nuevo mecanismo que llamamos soft handoff, tomando prestada la terminología desde el área de las redes celulares. 3.3 VNAODV+: Mejoras a VNAODV 87 7 1 0.1 1.1 2.1 2 4 3 0.0 1.0 6 2.0 5 Líder Backup Cliente Figura 3.4: Una configuración para ilustrar el mecanismo de soft handoff de VNAODV+. El mecanismo de soft handoff es en realidad una extensión del nuevo proceso de corrección de ruta de la VNLayer+: el objetivo es mantener las rutas válidas y estables de forma proactiva, pero teniendo en cuenta los movimientos de los PNs intermedios en la ruta (siempre nodos líderes) en lugar de los destinatarios. Dado que la capa de enlace es configurada en modo promiscuo, éste mecanismo puede realizarse haciendo que cada nodo inspeccione los paquetes reeviados en su región para comprobar si el campo next_hop contiene su dirección IP. Si no, el mismo diálogo de la sección 3.3.2 (un RREQ y dos RREP) se llevan a cabo para lograr las actualizaciones adecuadas en las tablas de encaminamiento del correspondiente VN y de los vecinos. Mientras tanto, los paquetes se transmiten a lo largo de la secuencia original de PNs. En el caso de la figura 3.4, la salida de PN 2 de la región de 1.0 desencadena diálogos RREQ-RREP-RREP entre el mismo PN 2 y PN 3 y sus respectivos líderes vecinos cuando PN 1 envía el primer paquete a PN 4 con la región 1.0 como next_region pero PN 2 como next_hop. Eventualmente, PN 1 y PN 4 aprenderán que ellos pueden intercambiar paquetes a través de PN 3 en la región 1.0 (PN 3 pasa de backup a líder después de que PN 2 sale) o PN 7 en la región 1.1. Mientras tanto, los paquetes serán entregados a través de PN 2. De esta manera, una vez más, podemos prevenir las rupturas de los enlaces y la pérdida de paquetes. Además, gracias al mecanismo de instantáneas de la información de estado de la sección 3.2.6, el procedimiento de soft handoff puede también hacer frente a situaciones en las que la salida de un líder deja una región vacía. En tales casos, el líder saliente puede continuar con la retransmisión de los paquetes para las rutas cuyas regiones anterior y siguiente son vecinas, e iniciar las acciones de reporte y reparación para las otras rutas de inmediato. Este comportamiento se implementa en la nueva función receiveForNeighbourRegion() de la interfaz de la VNLayer+ (section 3.2.7). Por ejemplo, si no existiera PN 3 en la figura 3.4, después de que PN 2 deja la región 1.0 vacía, los paquetes entre PN 1 y PN 4 fluirán a través del VN de la región 1.1: los primeros paquetes serán manejados por el mismo PN 2, y PN 7 (el líder de la región) se hará cargo una vez que la instantánea de la información de estado haya sido transferida a través del mecanismo de sincronización de vecino. 88 Mejoras a la capa de virtualización en entornos MANET 3.4. Aplicación a la distribución de contenido P2P en entornos MANET En esta sección, presentamos los experimentos de simulación y las medidas tomadas sobre un despliegue real, donde probamos que nuestra solución alcanza mejor rendimiento que otras propuestas para soportar una aplicación social ubicua relacionada con el aprendizaje de la historia en museos llamada REENACT (descrita en [28, 143]). Específicamente, comparamos el rendimiento alcanzado por la aplicación REENACT en la distribución de contenido multimedia con cinco esquemas de encaminamiento mostrados en la figura 3.5: AODV, VNAODV sobre la VNLayer, VNAODV+ sobre la VNLayer+, OLSR [108] y ARA [88]. AODV, OLSR y ARA son los más representativos ejemplos de algoritmos de encaminamiento usados para la distribución de contenido P2P en MANETs, junto con DSDV [185] (predecesor de OLSR) y Bee [234] (conceptualmente similar a ARA) [24, 44, 62, 89, 100, 204, 222, 230] (ver sección 2.2). !@=C>*>CD<% )//&!76% 6-*<?@A-B,% 6789:#8% ),;% $C-BE*=CF*>CD<% /<=*>,% !"#$% $&!"#$% !"#$%!&' $&'*+,-% !"()*+,&' "'()% !)!% .///%0123445% Figura 3.5: Las cinco configuraciones comparadas en nuestros experimentos. 3.4.1. REENACT REENACT es un enfoque pedagógico destinado a involucrar a grupos de visitantes de los museos en experiencias colectivas para mejorar su comprensión de las batallas históricas y guerras. Esta propuesta reúne diferentes elementos utilizados durante la última década para mejorar la pedagogía de la historia a través de la tecnología, incluyendo teléfonos inteligentes y tabletas [9,142], videojuegos para el aprendizaje [45,79], herramientas educacionales de realidad virtual y basadas en la localización [107, 224], realidad aumentada [174, 206] y redes sociales [4, 16, 63]. Las experiencias de REENACT fueron diseñadas para promover el aprendizaje sobre el preludio, el curso y las consecuencias de los acontecimientos en tres etapas (más detalles en [144]): Etapa 1: recreación. La etapa de recreación plantea un juego de roles para vivir el evento desde el interior. Después de ver una breve proyección que explica el contexto histórico, los participantes toman un rol y empiezan a moverse dentro o en los alrededores de las instalaciones del museo para encontrar distintas zonas identificadas por marcadores de realidad aumentada sobre el suelo o en las paredes. En esas zonas, cada participante puede disfrutar de vistas de 360◦ de lugares relevantes en los tiempos antiguos, navegar por los contenidos multimedia que describen el estado actual de las cosas desde su punto de vista, compartir anotaciones de texto, imagen, audio o vídeo; ver dónde se encuentra localizado en un mapa; y recibir indicaciones y opciones para seguir la reconstrucción de los 3.4 Aplicación a la distribución de contenido P2P en entornos MANET 89 hechos. La gama de posibles acciones es una función de las opciones de cada individuo, decisiones tomadas por otros en el pasado o las tomadas colectivamente por medio del voto, según lo determinado por un guión del evento. Etapa 2: reproducción. Una vez que la recreación ha terminado, un experto se une a la experiencia desde una ubicación remota para explicar cómo la recreación de los participantes se compara con los hechos reales, ayudándoles a aprender más por ver las cosas desde fuera. El experto brinda interfaces para examinar las líneas de tiempo de la recreación, el repositorio de contenidos multimedia y los contenidos generados por los propios participantes, tal que pueda destacar hitos importantes sobre el curso del evento y explicar qué aspectos de la recreación divergen de los hechos reales (ya sea porque los guiones hacen algunas concesiones o porque los participantes han hecho lo contrario a las decisiones de los personajes reales). Además, el experto puede ejecutar un juego colectivo de preguntas de opción múltiple sobre el preludio y el transcurso del evento. Etapa 3: debate. En la última etapa de las experiencias de REENACT, el experto conduce una reflexión colectiva sobre las consecuencias del suceso en cuestión, en el corto, mediano y largo plazo, preguntando qué podría haber sido diferente en la historia si las cosas hubieran sucedido de otra manera. Durante el debate, la pantalla de proyección se convierte en un gran tablero dinámico para mostrar los comentarios publicados por los visitantes, que pueden ser reorganizado por el experto y/o sometido a votación al público. De nuevo, el experto puede elegir contenidos multimedia para ilustrar los diferentes puntos que se plantean en cualquier momento. Los participantes pueden escribir sus comentarios utilizando los dispositivos móviles táctiles y, de ser elegido por el experto, pueden explicar sus ideas o puntos de vista a todo el público en una llamada de audio o vídeo. El primer despliegue de REENACT se completó en colaboración con la Fundación del Mundo Helénico3 en el contexto del proyecto EXPERIMEDIA 7PM4 , para tratar con el acontecimiento histórico de la Batalla de las Termópilas. La Fundación proporcionó un lugar para la experimentación en Atenas, además de una gran cantidad de contenidos 3D, audio y vídeo para los repositorios de contenidos y el apoyo de expertos historiadores para desarrollar guiones rigurosos, juegos de preguntas y temas sobre las etapas de reproducción y debates. Ellos también reclutaron voluntarios para los experimentos, que más tarde fueron complementados con sesiones adicionales en las instalaciones de la Universidad de Vigo. Esos experimentos (cuyos resultados fueron documentados en [145]) sirvieron para confirmar, entre otros hechos, que la propuesta pedagógica era interesante para personas de diferentes edades y niveles educativos, y que la activación de las interacciones sociales entre conocidos o desconocidos pueden ser una característica atractiva para los museos, a condición de que se les dé los incentivos adecuados (por ejemplo, en la forma de entretenimiento inesperado). En el aspecto técnico, la primera versión del sistema REENACT no explotó las capacidades de las comunicaciones ad-hoc entre los dispositivos de los recreadores, sino que todos los datos se intercambian mediante un servidor de Internet, conectándose a través de puntos de acceso WiFi. Este enfoque plantea una serie de problemas de 3 http://www.fhw.gr/fhw/ 4 http://www.experimedia.eu/ 90 Mejoras a la capa de virtualización en entornos MANET escalabilidad y conectividad que hemos abordado con un re-diseño del motor de comunicaciones, para pasar a un sistema de descarga colaborativa y diseminación P2P de contenidos basado en la VNLayer+. Ahora estamos utilizando la nueva versión del sistema para desarrollar nuevos escenarios para revivir los episodios de la época colonial de Ecuador en el centro histórico de la ciudad de Cuenca, incluyendo actividades en interiores y al aire libre para los recreadores. 3.4.2. Rediseño del Sistema El nuevo esquema para soportar los múltiples flujos de información generados durante las experiencias REENACT se basan en dos ideas principales en la capa de aplicaciones; a saber, la conexión compartida y las descargas paralelas entre una malla de pares cooperantes: Por un lado, los dispositivos móviles pueden activar conexiones 2G/3G/4G siempre que una conexión Wi-Fi no esté disponible (o tenga un desempeño pobre) y, además, compartirlas en una MANET tal que otros dispositivos accedan a descargas desde Internet. Los nodos que tienen acceso permanente o transitorio a Internet se anuncian como proxies HTTP usando el protocolo presentado en [95]. Por otro lado, la descarga y compartición de contenidos ocurre en una forma Torrent, de manera que los nodos pueden obtener diferentes partes (trozos) de los contenidos de Internet y luego buscar las piezas que les falta desde otros nodos en la MANET. Aquí, hemos adoptado el protocolo presentado en [127, 171], que incluye un mecanismo de gossip para propagar la información de disponibilidad de contenido y una estrategia de selección de piezas impulsadas por la proximidad. En la capa de transporte, la aplicación de REENACT se basa en UDP para entregar transmisiones de vídeo en vivo desde los expertos, los anuncios y mensajes de gossip; TCP es usado para todo lo demás (imágenes, clips de audio, comentarios, etc.). Al replicar las secuencias de eventos y los rastros de movilidad registrados durante las sesiones de experimentación de Atenas y Vigo, hemos confirmado que el nuevo esquema de comunicaciones supera al anterior en términos de una mejor conectividad, latencias más bajas (un ahorro medio del 18 % en la descarga de imágenes y fragmentos de audio o vídeo), un menor consumo de batería (ahorro de 3 % a pesar de la sobrecarga debido a la virtualización, los mensajes de anuncio y el gossip) y mayor capacidad para atender a más participantes en las experiencias (casi cuatro veces más, del 17 a 60 participantes, gracias a la reducción de la carga en los servidores de contenidos y la conexión a Internet detrás de los puntos de acceso Wi-Fi). Con estos datos positivos soportando la adopción de las comunicaciones ad-hoc, se pasó a hacer experimentos de simulación para evaluar las ventajas de la VNLayer+ y VNAODV+ en comparación con el resto de soluciones de encaminamiento de la figura 3.5. 3.4.3. Experimentos de Simulación Con el fin de ejecutar las simulaciones, primero obtuvimos trazas realistas de movilidad para los usuarios de la aplicación REENACT en el centro histórico de Cuenca en Ecuador. Para los movimientos en interiores (por ejemplo, en las catedrales vieja 3.4 Aplicación a la distribución de contenido P2P en entornos MANET 91 y nueva, que se muestra en la figura 3.1), se utilizó BonnMotion5 con una variante del modelo de movilidad comunidad nómada6 [214], sus parámetros fueron adaptados para que coincidan con los patrones de movimiento que había caracterizado los experimentos de Atenas. Para los movimientos al aire libre, utilizamos rastros de movilidad previstas preliminarmente por el modelo de comunidad nómada y post-procesado con un simulador de movilidad urbana llamada SUMO [217] para garantizar que los movimientos de los usuarios se adhieran al plano de las calles y obedeciendo las leyes de tránsito. Las trazas de movilidad se introdujeron en el simulador de red ns-2 [175], el cual maneja varias condiciones para las comunicaciones interiores y exteriores utilizando diferentes parámetros para el modelo de propagación shadowing [209] (β=4 y β=2.7, respectivamente). Un número aleatorio de puntos de acceso Wi-Fi (entre 0 y 3) fueron desplegados dentro y fuera de los edificios, y los repetidores fueron colocados en las entradas de los edificios. Todos los dispositivos móviles de los usuarios podían activar conexiones 3G (específicamente, WCDMA) siempre que el acceso a los contenidos a través de las redes ad-hoc estuviere interrumpido o presentara un pobre desempeño (por ejemplo, cuando la fluctuación en la recepción de los paquetes del vídeo del experto superaba un cierto umbral o cuando TCP incurría en demasiadas retransmisiones o tiempos de espera). En cuanto a la implementación de las soluciones de encaminamiento de la figura 3.5, vale la pena señalar que todos los mecanismos opcionales presentados en [240] (recepción directa, enlaces largos, etc.) se han habilitado tanto en la VNLayer como en la VNLayer+ para asegurar comparaciones justas, y que la forma de geocasting habilitada por VNAODV y VNAODV+ (véase la sección 3.3) fue explotada para reducir las transmisiones de mensajes redundantes correspondientes no solo al intercambio de trozos de contenidos multimedia, sino también para la entrega de anuncios de proxy y mensajes gossip. Dentro de estas configuraciones, nos fijamos en las siguientes métricas: Porcentaje de datos de la aplicación entregados a los dispositivos a través de las MANETs y las redes 3G. Sobrecarga del tráfico de control (overhead) en las MANETs debido a la capa de virtualización (si existe), la capa de red y la capa de transporte. Tasa de entrega de paquetes en las MANETs; es decir, la relación entre el número de paquetes de la capa de red entregados a los destinos y el número de paquetes enviados por los nodos fuente sobre las redes ad-hoc. El ad-hoc goodput, es decir, el número de bits de información útiles entregados por las MANETs a los destinos por unidad de tiempo. El consumo de batería, la suma de los costes de las comunicaciones WCDMA y 802.11 según los modelos de [92]. Hemos simulado escenarios con 10, 20 y 40 usuarios, de acuerdo con el número de participantes que consideraríamos en el funcionamiento de las sesiones del sistema 5 http://sys.cs.uos.de/bonnmotion/ 6 El modelo de movilidad comunidad nómada representa grupos de nodos desplazándose colectivamente de un lugar a otro. Cada grupo mantiene una región en la cual sus integrantes pueden moverse en forma aleatoria al rededor de un punto de referencia o un nodo líder. Cuando este punto de referencia cambia de lugar, todos los integrantes del grupo se desplazan a la nueva ubicación. 92 Mejoras a la capa de virtualización en entornos MANET de REENACT. Para empezar, la tabla 3.1 muestra el porcentaje de datos de la aplicación entregados a los nodos a través de enlaces MANET. Se puede ver que VNAODV+ ejecutándose sobre la VNLayer+ asegura consistentemente la mayor utilización de comunicaciones ad-hoc (ya sea para llegar a los puntos de acceso Wi-Fi o a otros dispositivos móviles que habían activado sus conexiones 3G), que en la práctica ayuda a acelerar los tiempos de descarga mientras alivia la carga en los servidores de contenido. VNAODV sobre VNLayer muestra un rendimiento promedio, comparable a OLSR y ARA, mientras que AODV resultó ser la solución que hace uso en menor porcentaje de las comunicaciones multisalto. En general, el porcentaje relativo de la utilización de las MANETs crece con el número de usuarios moviéndose alrededor, porque implica redes más densas y una mayor conectividad. Configuración AODV VNLayer/VNAODV VNLayer+/VNAODV+ OLSR ARA 10 usuarios 78 % 82 % 84 % 81 % 78 % 20 usuarios 80 % 83 % 89 % 82 % 82 % 40 usuarios 86 % 89 % 92 % 90 % 88 % Tabla 3.1: Porcentaje de tráfico entregado a los nodos a través de los enlaces MANET. Centrándonos en lo que sucede dentro de las MANETs, la figura 3.6 representa la sobrecarga de tráfico debido a la capa de virtualización (si existe), la capa de red y la capa de transporte. Se puede observar que, a pesar de que la virtualización implica una cantidad no despreciable de sobrecarga de tráfico de control para mantener los VNs, el intercambio de mensajes de la VNLayer o la VNLayer+ sirve para mejorar el funcionamiento de los protocolos de capa de red y la capa de transporte, puesto que las cantidades totales de la sobrecarga de tráfico debido a la segunda y tercera configuración de la figura 3.5 son significativamente más bajas que las de las otras. Con los nuevos mecanismos introducidos en esta tesis, la VNLayer+ causa una mayor sobrecarga de virtualización que la VNLayer original, pero esto ya se compensa en la capa de red (VNAODV+ tiene una menor carga que VNAODV) y sobre todo en la capa de transporte. De hecho, la sobrecarga de transporte sugiere que la combinación VNLayer+/VNAODV+ ofrece el mejor soporte a las comunicaciones TCP, seguido por VNLayer/VNAODV y luego por OLSR, ARA y AODV. Con una reducción de la sobrecarga de tráfico de control de cerca del 40 % con 40 usuarios, la virtualización ayuda a prevenir la congestión en el medio inalámbrico, que a su vez implica un menor número de pérdidas de paquetes debido a colisiones. Esto se refleja en los resultados de la simulación para la tasa de entrega de paquetes y goodput, que se muestra en las figuras 3.7 y 3.8. Con incrementos de al menos 4 % en la tasa de paquetes que llegan a sus destinos, se observa que los mecanismos que hemos puesto en la VNLayer+/VNAODV+ mejoran significativamente la capacidad de recuperación de la VNLayer/VNAODV, la cual resultó no ser comparativamente mejor que OLSR y ARA (AODV rezagado en al menos 12 %, saca poco beneficio de la cantidad de paquetes que se mueve alrededor de las MANETs). Del mismo modo, VNLayer+/VNAODV+ generó incrementos promedios del 5 % y 15 % en la cantidad de datos a nivel de aplicación que pueden ser entregados por las MANETs por unidad de tiempo con respecto a la VNLayer/VNAODV, OLSR y ARA, mientras hizo las redes más rápidas alrededor del 40 % en comparación con AODV. El pobre desempeño de AODV en MANETs densas se debe en gran parte a los incrementos en la longitud pro- 3.4 Aplicación a la distribución de contenido P2P en entornos MANET 93 Cantidad de datos (MB) 80 70 60 50 40 Transporte Red Capa virtual 30 20 10 0 AO DV VN VN OL AR L S A ye aye R r/ r VN +/V AO NA DV OD V AO La DV VN + 10 usuarios VN OL AR L S A ye aye R r/ r VN +/V AO NA DV OD V AO La DV VN + 20 usuarios VN OL AR L S A ye aye R r/ r VN +/V AO NA DV OD V La + 40 usuarios Figura 3.6: Sobrecarga del tráfico de control (overhead) en las MANETs debido a la capa de virtualización (si existe), la capa de red y la de transporte. medio de las rutas de múltiples saltos, lo cual es evitado con el agrupamiento inherente que se produce en la capa de virtualización y los procedimientos de corrección de ruta de VNAODV y VNAODV+. 1 Tasa de entrega 0.95 0.9 AODV VNLayer/VNAODV VNLayer+/VNAODV+ OLSR ARA 0.85 0.8 0.75 0.7 0.65 10 20 40 Cantidad de usuarios Figura 3.7: Tasa de entrega de paquetes en las MANETs frente al número de usuarios. Con respecto a la escalabilidad, se observa que los esquemas no virtualizados (AODV, OLSR y ARA) ya se enfrentan a problemas en el incremento de 20 a 40 usuarios, desde la figura 3.6 se muestra grandes incrementos en sus respectivas cantidades de sobrecarga de tráfico de control y la figura 3.8 revela que el goodput disminuye. En contraste, el uso de una capa de virtualización con VNAODV y VNAODV+ garantiza un incremento lineal de la sobrecarga de tráfico de control (de hecho, la sobrecarga de virtualización permanece prácticamente constante) y un mayor goodput cuando el número de dispositivos conectados crece. Añadiendo más usuarios a los experimentos de simulación, confirmamos que VNLayer+/VNAODV+ podría soportar con eficacia hasta 80 dispositivos conectados. Más allá de estos valores, todavía medimos baja sobrecarga, pero las tasas de entrega de paquetes y goodput empezaron a disminuir, debido al cuello de botella que surge de tener un solo nodo líder en cada región para 94 Mejoras a la capa de virtualización en entornos MANET 290 280 Goodput (Kbps) 270 260 AODV VNLayer/VNAODV VNLayer+/VNAODV+ OLSR ARA 250 240 230 220 210 200 190 10 20 40 Cantidad de usuarios Figura 3.8: Ad-hoc goodput frente al número de usuarios. afrontar la recepción de paquetes y su retransmisión en nombre de todos los demás. La solución puede venir de un nuevo refinamiento del procedimiento de designación líder, permitiendo que varios líderes colaboren y se dividan la carga (más sobre esto en el capítulo siguiente). Para terminar este análisis, la figura 3.9 muestra el coste total de las comunicaciones en términos de consumo de la batería, contando los datos de la aplicación y la sobrecarga de tráfico de control a través de las MANETs y las redes 3G. Los resultados están en línea con las observaciones antes mencionadas acerca de la sobrecarga (figura 3.6) y la utilización relativa de las redes MANETs y 3G (cuadro 3.1): las configuraciones de la VNLayer/VNAODV y VNLayer+/VNAODV+ acarrean un coste significativamente más bajo que los otros. Vale la pena señalar que, a pesar de las notables ganancias con respecto a las otras métricas, el consumo de batería con nuestro VNLayer+/VNAODV+ es ligeramente mayor que con la VNLayer/VNAODV originales. Esto se debe al tratamiento de los paquetes recibidos en modo promiscuo y la forma en que usamos los modos de transmisión unicast y broadcast. Sin embargo, el hecho de que la VNLayer+ permite a nodos líderes renunciar a su rol, como se explica en la sección 3.2.2 causa el efecto beneficioso de que el consumo de la batería se distribuye más uniformemente que con la VNLayer (la desviación estándar promedio con la VNLayer+ fue σ=120 mAh, mientras que la VNLayer produjo un σ=150 mAh). 3.5. Discusión A juzgar por los resultados obtenidos, podemos confirmar que las evoluciones de la VNLayer+ y VNAODV+ con respecto a la VNLayer y VNAODV sirven para soportar la distribución de contenidos multimedia dentro de los grupos de dispositivos móviles que abarcan entornos interiores y exteriores, en una representativa aplicación de la computación social ubicua. Por un lado, la VNLayer+ convierte las redes ad-hoc en entornos de comunicación más ágiles y fiables de lo que era posible con la VNLayer. Algunos de los nuevos procedimientos —especialmente los tres mensajes de sincronización y la gestión de las instantáneas de la información de estado de las regiones vecinas— podrían implicar, en principio, un mayor gasto y coste computacional, pero los beneficios derivados de evitar pérdidas de información de estado de las capas superiores da sus frutos al final. Por otro lado, nuestro algoritmo VNAODV+ aprovecha los 3.5 Discusión 95 Consumo medio (mAh) 1400 1200 1000 800 600 400 200 0 AO DV VN VN La OL La ye AR SR ye r/ A r+ VN DV 10 usuarios AO DV VN VN La V+ A AO DV VN DV /V AO DV V+ A r+ VN OD AR SR ye r/ NA OL La ye /V 20 usuarios VN La r+ AO OD AR SR ye VN NA OL La ye r/ /V AO NA OD V+ 40 usuarios Figura 3.9: Consumo total de la batería. nuevos procedimientos de la capa de virtualización para prevenir o resolver rupturas de trayectos en una forma mucho más eficaz que AODV y VNAODV, que finalmente resulta en mayores tasas de entrega de paquetes y más bits de información entregados a los destinos por unidad de tiempo. Vale la pena señalar también que a pesar de que VNAODV+ es un refinamiento de VNAODV, no está conceptualmente más lejos de AODV sino todo lo contrario, debido a la forma en que se maneja las transmisiones unicast y broadcast, así como las notificaciones de la capa de enlace. Sabiendo esto, podemos destacar el hecho de que la virtualización hace al concepto reactivo de AODV superar el rendimiento de un algoritmo proactivo como OLSR y el enfoque de la inteligencia de enjambre de ARA, que fueron, sin embargo, mejores que AODV no virtualizado, con respecto a todas las métricas que hemos analizado. Este resultado nos llevó a cuestionarnos sobre la capacidad de la virtualización para producir mejores comunicaciones en un campo más específico y demandante como el de las redes vehiculares ad-hoc (VANETs), el cual progresivamente se está convirtiendo en un tópico de interés para las compañías de automoción para proveer servicios de comunicación innovadores a sus usuarios sobre las vías y calles [84]. En el siguiente capítulo presentamos una capa de virtualización mejorada, la que hemos llamado VaNetLayer, que introduce nuevos mecanismos a la VNLayer para incrementar su rendimiento en entornos vehiculares. Capítulo 4 Mejoras a la capa de virtualización en entornos VANET En este capítulo presentamos las mejoras y nuevos procedimientos para que la VNLayer incremente su fiabilidad y capacidad de respuesta en entornos VANET. Adicionalmente, introducimos un nuevo protocolo de encaminamiento para redes vehiculares diseñado para ejecutarse sobre la capa de virtualización, aprovechando sus nuevas funcionalidades. 4.1. Introducción Los resultados obtenidos con las mejoras que hemos implementado a la VNLayer para incrementar su rendimiento en el campo de las MANETs, nos llevaron a cuestionarnos sobre su capacidad para permitir el despliegue de aplicaciones sobre redes vehiculares ad-hoc. Como se destaca en [84], los fabricantes de automóviles y las autoridades del transporte están apoyando cada vez más el desarrollo y la estandarización de los componentes esenciales para estructurar una rejilla de vehículos (radios, puntos de acceso, espectro, etc.), lo que conduce a prever una gran cantidad de servicios innovadores de información y entretenimiento. Nuestro objetivo es hacer la infraestructura de nodos virtuales suficientemente flexible para abarcar las comunicaciones en contextos interiores, pedestres y vehiculares, definiendo diferentes perfiles y configuraciones de la capa de virtualización desde donde escoger. Las VANETs plantean retos importantes debido a los movimientos relativamente rápidos de los nodos (condicionados por factores como el trazado de la vía, la planificación urbana, las regulaciones de tránsito, entre otros1 ) y a una mayor abundancia de pérdidas de paquetes producida por los obstáculos, la reflexión y el ruido. En lo que sigue de este capítulo presentamos las mejoras que hemos introducido a la VNLayer para incrementar su rendimiento en entornos VANETs, a más de un análisis teórico sobre los procesos de la capa de virtualización en estos escenarios; presentamos un 1 Una buena revisión del estado del arte y taxonomía de los modelos de movilidad para VANETs puede ser encontrada en [93]. 97 98 Mejoras a la capa de virtualización en entornos VANET nuevo protocolo de encaminamiento diseñado para ejecutarse sobre nodos virtuales; y, finalmente, evaluamos las prestaciones de nuestras propuestas a través de experimentos de simulación en diferentes escenarios vinculados a la computación social ubicua. 4.2. VaNetLayer: Mejoras a la VNLayer para entornos VANET Nuestros experimentos iniciales con la VNLayer en el campo de las VANETs arrojaron una serie de ineficiencias similares a las presentadas en la sección 3.1, solventadas en parte por la mejoras implementadas en la VNLayer+ (ver sección 3.2); no obstante, debido a las características particulares de las redes vehiculares, introducimos nuevos mecanismos para incrementar su rendimiento y para corregir los problemas detectados debido a la sobrecarga de trabajo de los nodos que mantiene el liderazgo en redes de alto tráfico (ver sección 3.4.3). A esta nueva versión de la VNLayer, que incluye los mecanismos diseñados para la VNLayer+, la hemos denominado VaNetLayer. Figura 4.1: Nodos virtuales estáticos (cuadrados blancos) superpuestos a los movimientos de los vehículos (círculos negros) de una VANET. En términos generales hicimos las siguientes mejoras: (i) diseñamos un procedimiento iterativo que permite ajustar el despliegue de los VNs al plano de las calles; (ii) mejoramos el proceso de elección de líder para hacerlo más rápido y para evitar los problemas generados por los tiempos de inactividad debidos a la salida del líder; (iii) ampliamos las atribuciones de los backups para que brinden un mayor soporte a sus líderes; y (iv) diseñamos un nuevo mecanismo para que los VNs puedan soportar más de un líder. 4.2.1. Un arreglo más vinculado al trazado para los VNs Como se mostró en la sección 2.5, la VNLayer divide el área en regiones cuadradas, por lo que los VNs pueden ser vistos como localizados sobre una cuadrícula (ver figura 4.1). Esta disposición reticular es problemática en las redes VANETs, porque 4.2 VaNetLayer: Mejoras a la VNLayer para entornos VANET 99 compromete el supuesto de que todos los PNs dentro de una misma región pueden comunicarse directamente entre sí y que sus transmisiones pueden ser escuchadas por todos los PNs en las regiones vecinas (ver la sección 2.5.1). En la figura 4.2, por ejemplo, hay varios pares de vehículos que, pese a estar localizados en la misma región, no pueden comunicarse directamente entre sí debido a los edificios (no representados) en el medio; lo mismo sucede con otros pares de vehículos en las regiones vecinas. Como resultado, la disposición de los VNs aplicada por la VNLayer tiene dos inconvenientes principales: (i) que a menudo conlleva problemas en las comunicaciones dentro de la región que pueden obstaculizar el funcionamiento coordinado de los líderes y los backups, y (ii) los nodos líderes pueden decidir enviar paquetes en callejones sin salida, porque las regiones vecinas son inalcanzables. Figura 4.2: Un arreglo de regiones VN con la VNLayer. Para resolver estos problemas, la VaNetLayer introduce un nuevo enfoque para cubrir el plano de las calles, alejándose de las regiones de igual tamaño y forma — siguiendo el mismo concepto de la VNLayer+ en las redes MANET (ver sección 3.2.1). Hemos ideado un procedimiento iterativo mediante el cual cada PN puede determinar localmente las posiciones, formas, tamaños e identificadores de las regiones con poco coste computacional2. La regla básica es tener una región rectangular de forma predeterminada en cada intersección y luego cubrir la longitud de los segmentos de vía entre ellas con regiones cuadrangulares adicionales, siguiendo las orientaciones de la calle y eligiendo su tamaño de acuerdo con los siguientes principios: Se prefieren regiones de tamaños grandes para maximizar el número de PNs y el tiempo que permanecen dentro de ellas (ambas variables son beneficiosas para la estabilidad de las VNs). La distancia máxima entre dos puntos de regiones vecinas no debe superar el 75 % del rango de transmisión de los PNs, con el fin de asegurar que cada PN pueda enviar y recibir datos desde y hacia todos los demás PNs en su región y las regiones vecinas. 2 Dado que las regiones (y, por lo tanto, los VNs) son estáticas, solo necesitamos que los vehículos manejen los mismos mapas (o muy similares) para asegurar que todos ellos dividen el área de la VANET en el mismo conjunto de regiones. Entonces, nombrando cada nodo virtual con un número derivado de las coordenadas GPS de su centro, podemos asegurar un funcionamiento adecuado de la infraestructura virtual habilitada por la VaNetLayer, incluso con ligeras imprecisiones en las lecturas de GPS. 100 Mejoras a la capa de virtualización en entornos VANET Con el fin de evitar los obstáculos al borde de la carretera, las líneas rectas que unen dos puntos entre regiones vecinas no pueden tener segmentos más largos que 13 de toda su longitud cayendo fuera de las calles.3 Como se muestra en la figura 4.3, este enfoque sirve para soportar la conectividad y reducir drásticamente los problemas debidos a los obstáculos, adaptando la disposición de los nodos virtuales al mapa de calles. A su vez, evitamos situaciones como que algunas calles pudieran ser cubiertas por muchos más VNs de los necesarios, que darían lugar a una mayor frecuencia en los cambios de región de los PNs e incrementarían la sobrecarga de tráfico de control debido a la virtualización. Figura 4.3: Un arreglo de regiones VN con la VaNetLayer. Otro interesante efecto de nuestro algoritmo se observa alrededor de las curvas cerradas. En la parte izquierda de la figura 4.4, por ejemplo, representamos una curva cubierta por regiones cuadradas como se establece por la VNLayer, es notorio que hay dos nodos en la misma región, sin línea de vista del uno al otro. Con la disposición adaptativa de los VNs en la VaNetLayer, en contraste, las curvas cerradas siempre terminan con una región comparativamente pequeña colocada en el ángulo (cuanto más cerrada es la curva, menor es la región), lo que maximiza las probabilidades de que los PNs dentro de la misma región sean capaces de comunicarse directamente entre sí. El pequeño tamaño de estas regiones no es problemático porque los vehículos las atraviesan a una velocidad comparativamente más baja. Figura 4.4: Regiones VN alrededor de curvas con la VNLayer y la VaNetLayer. 3 Los valores de 75 % y 31 se eligieron empíricamente, después de unas cuantas rondas de pruebas. Dejamos para el futuro hacer estudios con mayor profundidad para comprobar los posibles efectos derivados del uso de valores ligeramente superiores o inferiores. 4.2 VaNetLayer: Mejoras a la VNLayer para entornos VANET 101 4.2.2. Mejoras al procedimiento para la elección de líder Como se analizó en la sección 3.2.2, el nuevo procedimiento de elección de líder implementado en la VNLayer+ asegura una rápida reacción a la recepción de mensajes M_LeaderLeft al borrar los estados UNKNOWN y UNSTABLE y reorganizar las transiciones entre los estados restantes. No obstante, a más de esos cambios, hemos añadido un estado denominado INTERIM que evita los tiempos inactivos que resultan de la pérdida de mensajes M_LeaderLeft. En lugar de esperar hasta que el líder actual salga de la región (lo que deja a la región sin atención de un líder por al menos dos periodos T_Heartbeat si se pierde el mensaje M_LeaderLeft) la VaNetLayer permite al líder empezar una nueva elección (como de costumbre, difundiendo un mensaje M_LeaderLeft) poco antes de salir. Mientras tanto, antes de que otro nodo solicite el liderazgo mediante el envío de un M_Heartbeat, el líder renunciante continúa reenviando los paquetes y respondiendo a los mensajes M_SyncRequest desde el estado INTERIM. Además, retransmite el mensaje M_LeaderLeft si al momento de enviar un nuevo M_Heartbeat ningún otro nodo ha reclamado el liderazgo. De esta manera, la VaNetLayer aumenta significativamente la probabilidad de que haya algún nodo en el liderazgo del VN siempre que existan PNs en la región. Estos cambios se reflejan en la nueva máquina de estados para la elección del líder mostrado en la figura 4.5. in: expire(T_Heartbeat) out: send(M_Heartbeat); start(T_Heartbeat); INITIAL in: expire(T_RequestWait) out: send(M_Heartbeat); start(T_Heartbeat); in: RegionKnown out: start(T_RequestWait); in: RegionChange out: send(M_LeaderLeft); send(M_LeaderRequest); start(T_RequestWait); REQUEST in: recv(M_LeaderLeft) AND NOT PriorityBackup out: start(T_RequestWait); in: recv(M_Heartbeat) OR recv(M_LeaderReply) out: start(T_Heartbeat); expires=0; in: RegionChange out: send(M_LeaderRequest); start(T_RequestWait); LEADER in: Relinquishing out: send(M_LeaderLeft); in: recv(M_Heartbeat) out: start(T_Heartbeat); expires=0; INTERIM in: expire(T_Heartbeat) AND expires==2 out: start(T_RequestWait); in: expire(T_Heartbeat) AND expires<2 out: start(T_Heartbeat); expires++; Fig. 7. NONLEADER in: expire(T_Heartbeat) out: send(M_LeaderLeft); send(M_Heartbeat); start(T_Heartbeat); in: recv(M_LeaderLeft) AND PriorityBackup out: send(M_Heartbeat); start(T_Heartbeat); in: recv(M_Heartbeat) out: start(T_Heartbeat); expires=0; The state machine of our new leader election procedure. Figura 4.5: Máquina de estados para el proceso de elección de líder en la VaNetLayer. 4.2.3. Haciendo que los backups den un mayor apoyo al trabajo del líder En la VNLayer, los nodos backups se utilizan simplemente como rápidos reemplazos para aquellos líderes que dejan sus regiones o se desconectan por cualquier razón. Un nodo backup captura cada paquete dirigido a su líder y mantiene una copia en una cola hasta que escucha a su líder reenviar ese paquete o recibir posteriormente algún otro. Por lo tanto, la VNLayer no considera como un problema la situación en la que 102 Mejoras a la capa de virtualización en entornos VANET A B C LB NL n n+ 1 n /n//+ ///1/ LA n n+1 M_SyncRequest LC Líder Backup BB No líder Figura 4.6: Comportamiento de los backups con respecto a los líderes en la VNLayer. un backup pierde la retransmisión de un paquete en su cola; solo toma medidas cuando el backup no tiene una copia contrastada de un paquete reenviado, lo que provoca un proceso de sincronización para obtener desde el líder cualquier otra información que podría haber perdido. Un ejemplo se muestra en la figura 4.6: el líder de la región A (LA ) transmite dos paquetes (n y n + 1) y el líder de la región B (LB ) recibe ambos paquetes, mientras que al nodo backup BB solo le llega el paquete n; el backup solicita iniciar la sincronización después de escuchar que LB reenvía ese paquete a la región C. En el entorno con pérdidas de una VANET puede haber muchos casos en los que los paquetes no llegan al líder, pero al menos uno de los backups en la región podrá obtenerlos desde el nodo emisor. Con el comportamiento que se explicó anteriormente, aquellos paquetes no podrían llegar a sus destinos, ya que los backups los descartarían al oír que el líder reenvía paquetes más recientes. Para evitar estas pérdidas, la VaNetLayer modifica el comportamiento de los nodos backup de manera que reenvíen los paquetes que el líder puede haber perdido: si un backup escucha la transmisión de un paquete que no está a la cabeza de su cola, espera una cantidad de tiempo proporcional a su nivel de prioridad y reenvía los paquetes que lo preceden en nombre del líder. En el caso de la figura 4.7, por ejemplo, el paquete n alcanza la región C a través del nodo backup BB , a pesar de que ese paquete no fue recibido por LB . De esta manera, los nodos backups dan un mayor soporte al trabajo de reenvío de paquetes del líder, reforzando los enlaces entre los VNs vecinos. A B C LB NL /n/ n+ n+1 1 n n+ LA LC 1 BB Líder Backup n No líder Figura 4.7: Un backup retransmitiendo un paquete perdido por el líder de su región. La extensión de las atribuciones de los nodos backups en la VaNetLayer tiene la desventaja de que algunos paquetes pueden ser replicados fuera de orden a la siguiente región. En la figura 4.8, por ejemplo, el paquete n alcanza al nodo LC dos veces porque BB no pudo escuchar a LB y reenvió el paquete a la región C. Para evitar que esto se convierta en un problema cada vez mayor a lo largo de los saltos sucesivos, hemos modificado el algoritmo de gestión de colas de la VNLayer para que reordene los paquetes y elimine los duplicados. 4.2 VaNetLayer: Mejoras a la VNLayer para entornos VANET A B C LB NL n n+ 1 n n n+ LA 103 n+ 1 // n LC 1 n+1 BB Líder Backup n No líder Figura 4.8: Un paquete transmitido dos veces a una región porque un backup no pudo escuchar la retransmisión de su líder. 4.2.4. Varios líderes por región Dado que los líderes de las regiones gestionan la retransmisión de los paquetes de los diferentes flujos de datos que pasan por los VNs, en escenarios de alto tráfico puede llegar a convertirse en un cuello de botella. Para resolver esta situación, la VaNetLayer implementa un procedimiento que permite la coexistencia de más de un líder en la región. Si un líder detecta una sobrecarga de trabajo (su cola de salida crece más allá de un umbral determinado), envía un mensaje M_LeaderBecomeRequest a su backup sincronizado de mayor prioridad para que asuma también el rol de líder, pasando a comportarse como un segundo líder e iniciando su difusión de mensajes M_Heartbeat. Gracias a que cada uno de los líderes tiene asociado un identificador único, el resto de nodos pueden diferenciar entre los mensaje de los distintos líderes. Este identificador permite que los protocolos ejecutándose sobre la capa virtual puedan elegir qué nodo virtual utilizar en su proceso; por ejemplo, en el caso de tener dos nodos líderes en la región, los protocolos de encaminamiento que tengan sus rutas a través del VN pueden ser distribuidos entre ellos como una función de la paridad del identificador del paquete; así, si este valor es par, el paquete es dirigido al líder 0 y si es impar, al líder 1. Los nuevos líderes se reparten los backups en forma equitativa. En función de su nivel de prioridad, los backups decidirán apoyar a un líder u otro. Dado que el identificador del líder en la región (L_id) y el valor de la prioridad de cada backup (Bprt) son números enteros que irán creciendo secuencialmente desde cero, cada backup calcula el identificador del líder al que apoyará como L_id = Bprt − (N ro_LD)(j), donde N ro_LD es el número de líderes en la región y j es el mayor número entero que mantiene el resultado mayor o igual que cero. Por ejemplo, en el caso de dos líderes (líder 0 y 1), los backups de prioridad par apoyarán al líder 0 mientras que los de prioridad impar apoyarán al líder 1. Durante el tiempo que exista más de un líder en el VN, si un backup abandona la región, la prioridad del resto de los backups se mantendrá igual y el backup saliente será reemplazado por otro nodo, una vez que el líder anuncie a través de un M_Heartbeat esta carencia. El nuevo backup asumirá la prioridad dejada por su predecesor y se sincronizará con el líder. De igual forma, si uno de los líderes abandona la región, será reemplazado por su backup sincronizado de mayor prioridad, acorde con el proceso de elección de líder detallado en la sección 4.2.2. Cuando los líderes colaboradores detectan que sus colas de salida permanecen durante un tiempo determinado por debajo de un umbral, asumen que la situación de sobrecarga ha cesado, por lo que difunden un mensaje M_CeaseLeaderAnnouncement para renunciar al liderazgo y dejan de difundir los M_Heartbeat (lo que hace que los 104 Mejoras a la capa de virtualización en entornos VANET nodos en la región y los vecinos den a ese líder de baja). No obstante, los líderes salientes mantendrán el reenvío de aquellos paquetes que aún han sido dirigidos hacia ellos. Los backups que brindaban soporte a estos nodos se sincronizarán con el VN principal, manteniendo su nivel de prioridad. 4.3. Modelado de los procesos de la capa de virtualización 4.3.1. Análisis de los procesos de la VNLayer Dentro de ciertos supuestos, podemos usar algunas expresiones matemáticas para analizar la operación de la VNLayer. Para este objetivo, consideremos la calle de dos vías de la figura 4.9, sobre la que hemos delimitado una región VN. Se modela la entrada de PNs en la región como eventos independientes, separados por un tiempo aleatorio dado por la distribución exponencial de tasas λ1 en una dirección y λ2 en la otra. Suponemos condiciones de un tránsito que fluye perfectamente (no se forman colas) y constante, con igual velocidad para todos los PNs, dando un tiempo determinista T para cada PN dentro de la región. Con esas condiciones, las partidas de los PNs desde la región tienen las mismas propiedades como las entradas (de hecho, son entradas a una región vecina) y nosotros podemos aplicar las fórmulas del modelo M/D/∞ [118], por las que la probabilidad de tener n PNs en la región (n ≥ 0) está dada por la ecuación (4.1): λ2 λ1 M/D/∞ Figura 4.9: Modelamiento del tránsito vehicular dentro un segmento de calle simple. n pn = [(λ1 + λ2 ) · T ] · e−(λ1 +λ2 )·T n! (4.1) Para una estimación de la sobrecarga de virtualización, por simplicidad, consideraremos escenarios sin pérdida de paquetes en las comunicaciones en el interior de una región. Además, asumiremos que la función de lanzamiento de moneda (Coin Tosser Function) mencionada en la sección 3.2.4 asegura que, en promedio, algún PN tiene una probabilidad BP de ser un backup, y que hay suficiente tráfico de datos a través de la capa de virtualización que no es necesario enviar mensajes M_Hello. Entonces, tenemos que sumar las siguientes fuentes de sobrecarga de virtualización Mensajes M_LeaderLeft enviados por los líderes salientes, más el subsecuente intercambio de mensajes M_SyncRequest y M_SyncAck si el nuevo líder no fuera ya un backup. Esto último sucede con una probabilidad de 1 − BP , mientras que la tasa de líderes salientes puede ser calculada como (λ1 + λ2 ) · p1 + p22 + p33 + . . . (porque siempre hay un líder entre los n PNs 4.3 Modelado de los procesos de la capa de virtualización 105 en la región). Así, podemos obtener las siguientes expresiones este compoP∞ para pi nente de la sobrecarga: (λ1 + λ2 ) · [1 + 2 · (1 − BP )] · i=1 i . Dos mensajes de sincronización debidos a algún nodo que entra a la región y escoge convertirse en un nodo backup. La tasa de esos mensajes es dada directamente por la tasa de entrada y la probabilidad BP , así obtenemos la expresión 2 · (λ1 + λ2 ) · BP . 1 El envío continuo de mensajes M_Heartbeat. La tasa es dada por T_Heartbeat siempre que haya un líder en la región (es decir, cuando no esta vacía). En general, obtenemos la estimación de la ecuación (4.2) para la tasa de mensajes de virtualización, la cual confrontaremos con las correspondientes expresiones para la VaNetLayer: (λ1 + λ2 ) · [1 + 2 · (1 − BP )] · ∞ X pi i=1 i ! + 2 · (λ1 + λ2 ) · BP + + (1 − p0 ) · 1 T_Heartbeat (4.2) También podemos estimar la probabilidad de error de la VN (lo que implica la pérdida de la información de estado almacenada en él) por adicionar dos componentes: los periodos en los que la región está vacía, y los periodos en los que la región no está vacía pero no hay aún algún PN en el estado LEADER. La primer componente es directamente dada por p0 desde la ecuación (4.1). La segunda componente, a su vez, puede ser estimada por considerar que el PN obligado a entrar al estado LEADER, en promedio, estará en el medio de su viaje desde un extremo al otro de la región cuando el antiguo líder sale y envía el M_LeaderLeft. Aquel PN no estará actuando como líder por T2 , sino más bien por aquel tiempo menos lo gastado en los estados UNKNOWN y REQUEST. Por tanto, obtenemos la siguiente ecuación 4.3 para la probabilidad de indisponibilidad de un VN con la VNLayer: p = p0 + (1 − p0 ) · mı́n T 2 , T_LeaderRequest T 2 + T_RequestWait (4.3) 4.3.2. Análisis de los procesos de la VaNetLayer Manteniendo los supuestos de la sección 4.3.1, ahora explicaremos cómo las expresiones matemáticas derivadas de la VNLayer cambian debido a los refinamientos de la VaNetLayer. Por simplicidad, no consideraremos los tres tiempos de ida-vuelta necesarios en los procesos de sincronización de los backups, tal que los nodos salientes pueden ser siempre reemplazados inmediatamente por un backup sincronizado.Además, consideraremos a 1 y M como el número mínimo y máximo de backups que la VaNetLayer intenta tener. En esas condiciones, los mensajes de virtualización tienen tres posibles orígenes: Mensajes M_LeaderLeft enviados por los nodos salientes. ComoP se explicó en ∞ pi . la sección 4.3.1, la tasa de mensajes aquí es dada por (λ1 + λ2 ) · i=1 i 106 Mejoras a la capa de virtualización en entornos VANET La transferencia de instantáneas para preservar y restaurar el estado de información de regiones vacias. Esto sucede cuando el líder saliente está solo en su región y que la región vecina no está vacía; así que, si nosotros asumimos por simplicidad que esta última no se convertirá en vacía antes de que el estado es transferido de nuevo a un nodo entrante en la región de origen de ese estado, podemos contar 4 mensajes, obteniendo (λ1 + λ2 ) · (4 · p1 · (1 − p0 )). Tres mensajes de sincronización debido a que algún nodo es llamado a servir como backup, ya sea porque hay menos que M backups en la región o para remplazar a algún backup saliente. Dado que la VaNetLayer busca tener M backups siempre que sea posible, por un lado, tenemos un intercambio de mensajes de sincronización para cada entrada cuando hay hasta M PNs en la región; por otra parte, tenemos una tasa de backups salientes de Mi cada vez que hay i > M PNs. Por tanto, obtenemos las siguientesexpresiones para esta fuente de PM P∞ pi sobrecarga de tráfico de control: 3 · (λ1 + λ2 ) · p + M · i i=1 i=M+1 i . El envío continuo de mensajes M_Heartbeat. Esto es igual a la sección 4.3.1. En general, la estimación de la tasa de mensajes de virtualización se convierte en la de la ecuación (4.4): (λ1 + λ2 ) · +3 · (λ1 + λ2 ) · ∞ X pi i=1 i + 4 · p1 · (1 − p0 ) M X ∞ X pi pi + M · i i=1 i=M+1 + (1 − p0 ) · ! + ! + 1 T_Heartbeat (4.4) En cuanto a la probabilidad de indisponibilidad de los VNs, asumir la sustitución inmediata de los líderes salientes implica descartar el segundo sumando de la ecuación 4.3. El primer sumando tiene que ser cambiado debido a que la información de estado de un VN no está necesariamente perdida cuando la región se convierte en vacía, debido al mecanismo de instantáneas. Teniendo en cuenta la figura 4.10, el flujo de paquetes de la región A a la región C puede seguir si uno de sus respectivos líderes tiene una instantánea de B en su memoria y los dos líderes no están demasiado lejos el uno del otro. Sabiendo que el tamaño de las regiones se elige para asegurar la comunicación entre los puntos más distantes de dos regiones vecinas, pero no más, podemos tomar la ecuación 4.5 como una estimación pesimista de la indisponibilidad de los VNs para la VaNetLayer. p = p1 · (1 − p0 ) · √ ! 5 1− √ 10 (4.5) En este punto podemos hacer comparaciones teóricas del rendimiento y complejidad de la VNLayer y la VaNetLayer. Para empezar, la figura 4.11 representa las estimaciones del número de mensajes de virtualización generadas por cada esquema frente a una variación de las tasas de vehículos entrando y saliendo de la región (λ1 + λ2 ). Incluimos curvas para difetentes valores de T (tiempo gastado por los vehículos para 4.3 Modelado de los procesos de la capa de virtualización A 107 C B √5 ∝ √ 0 1 ∝ Figura 4.10: En la aproximación de la ecuación 4.5, dos nodos no vecinos pueden intercambiar mensajes de forma segura a través de la región vacía √ si ellos están más cerca que la dimensión del lado de la región multiplicada por 5; más allá de ese límite, los mensajes se pierden. cruzar de un lado al otro) como también para diferentes valores de los parámetros BP y M que intervienen en la designación de los nodos backup. Se puede observar que la VaNetLayer escala mejor que la VNLayer, mientras que esta última genera menor número de mensajes solo con tránsito muy ligero (bajos valores de λ1 + λ2 ). Sin embargo, esto no implica que la VNLayer pueda trabajar mejor que la VaNetLayer en tales condiciones. Como se muestra en el gráfica de la figura 4.12 —con valores más bajos en el eje x que en la figura 4.11—, la sobrecarga extra causada por la VaNetLayer sirve para mantener la probabilidad de indisponibilidad de los VNs en valores muy bajos (prácticamente 0 con (λ1 + λ2 ) > 2), mientras que la VNLayer enfrenta mayores dificultades, especialmente con valores bajos de T (vehículos que cruzan la región VN a mayor velocidad). 6 Estimationofvirtualisationmessagespersecond 5 4 3 2 1 0 2 3 4 5 6 7 8 Totalvehiclesentering/leavingpersecond VNLayer(T=10s,BP=1/10) VNLayer(T=10s,BP=1/3) VNLayer(T=15s,BP=1/10) VNLayer(T=15s,BP=1/3) VaNetLayer(T=10s,M=3) VaNetLayer(T=10s,M=5) VaNetLayer(T=15s,M=3) VaNetLayer(T=15s,M=5) Figura 4.11: Estimaciones de la sobrecarga de virtualización. 108 Mejoras a la capa de virtualización en entornos VANET 0.09 EstimatedprobabilityofVNfailure 0.08 0.07 0.06 0.05 0.04 0.03 0.02 0.01 0 1 1.5 2 2.5 Totalvehiclesentering/leavingpersecond VNLayer(T=5s) VNLayer(T=10s) 3 VaNetLayer(T=5s) VaNetLayer(T=10s) Figura 4.12: Estimaciones de la probabilidad de la indisponibilidad del VN. A pesar de las muchas asunciones, aproximaciones y simplificaciones de nuestra modelización y análisis matemático, estas observaciones (y todas las tendencias sugeridas por las ecuaciones 4.2 a 4.5) son en gran medida consistentes con los resultados de simulación presentados más adelante en este capítulo, frente a diseños complejos de las calles, patrones de movimiento realistas para los vehículos, pérdidas de paquetes en las comunicaciones, etc. 4.4. VNIBR: Un nuevo protocolo de encaminamiento sobre nodos virtuales basado en intersecciones La nueva disposición de los nodos virtuales en la VaNetLayer ofrece un escenario conveniente para desarrollar nuestra nueva combinación de encaminamiento topológico y geográfico, con trayectos basados en las calles que unen las intersecciones sucesivas que conectan a fuentes y destinos. Nuestra propuesta, denominada VNIBR (Intersection-Based Routing on Virtual Nodes), funciona de acuerdo con tres ideas centrales: (i) direccionamiento de los nodos por sus IPs, (ii) toma de decisiones de encaminamiento en las intersecciones de calles, y (iii) reenvío de paquetes de una intersección a la siguiente de manera geográfica. La principal novedad con respecto a las alternativas existentes en la literatura es que VNIBR se soporta en la capa de virtualización (ver figura 4.13) que involucra colaborativamente a los vehículos para emular una infraestructura de nodos virtuales estacionarios, que permite desacoplar la lógica de encaminamiento de las identidades de otros nodos diferentes de los nodos fuente y destino. Como se muestra en la figura 4.14, la VaNetLayer divide el área geográfica de la red ad-hoc en regiones siguiendo un disposición basada en las intersecciones, ubicando un VN en cada intersección y cubriendo los segmentos entre ellas VNs equidistantes (ver sección 4.2.1). Los VNs son identificadas por direcciones IP clase E (Experimental, entre 240.0.0.0 y 255.255.255.255) y sus anchos son determinados por el rango de comunicaciones del protocolo de la capa de enlace subyacente, para garantizar que un PN en alguna posición en una región pueda comunicarse directamente con algún otro PN en una región vecina (ver sección 4.2.1). 4.4 VNIBR: Un nuevo protocolo de encaminamiento sobre nodos virtuales basado en intersecciones 109 *+,-./,# !"#$%& !'"()*'+(,& !"""#$%&'(()# Figura 4.13: VNIBR en la pila de los protocolos de comunicación. Figura 4.14: Nodos virtuales estáticos definidos por la VaNetLayer. En VNIBR, se diferencian tres tipos de entidades de encaminamiento: Entidades de nivel 1 (L1VNs, de color azul en la figura 4.14) son los VNs colocados en las intersecciones. Aquí es donde se toman las decisiones de encaminamiento, utilizando un procedimiento adaptado de la lógica de AODV (detallado más adelante en esta sección). Las tablas de encaminamiento son mantenidas en forma transparente por la VaNetLayer como información de estado persistente, con entradas que indican cuál es el siguiente segmento de vía (identificado por el L1VN en el otro extremo) que los paquetes deben atravesar para llegar al destino correspondiente. Los L1VNs que están a un segmento de vía de distancia el uno del otro, constantemente intercambian paquetes HELLO para realizar un seguimiento de las condiciones de conectividad que proveen. Entidades de nivel 2 (L2VNs, aquellas de color rojo en la figura 4.14) son los VNs vecinos de una intersección. Estos VNs comienzan el reenvío de los paquetes a lo largo del segmento de vía como es dispuesto por el nodo vecino L1VNs, independientemente de qué PN realmente hace la transmisión. Además, utilizando el mecanismo de instantáneas de la VaNetLayer, los L2VNs actúan como entidades de respaldo, tratando de continuar con la retransmisión de los paquetes hacia otros segmentos de vía durante los tiempos de parada de los L1VNs vecinos. De esta manera, por ejemplo, el líder del PN vn44 en la figura 4.15 puede 110 Mejoras a la capa de virtualización en entornos VANET ayudar a evitar un quiebre de la ruta dibujada con una línea discontinua cuando no hay vehículos en la región cubierta por VN4. Por último, las VNs en posiciones intermedias de los segmentos de vía son las entidades de nivel 3 (L3VNs, aquellas de color amarillo en la figura 4.14), las cuales simplemente retransmiten paquetes de un lado a otro, de nuevo independientemente de PNs específicos. Figura 4.15: Muestra de PNs, VNs y rutas en VNIBR. Los L2VNs y L3VNs reenvían los paquetes desde un extremo al otro de los segmentos de vía, sin ningún otro proceso que establecer a 1 el bit de entrega en la cabecera del paquete si el destino PN está dentro de la región actual. Por ejemplo, si el vehículo PN1 de la figura 4.15 se está comunicando con PN2 a través de la ruta trazada con línea continua, si bien el PN2 se encuentra dentro de la región cubierta por un L2VN (el vn43), los paquetes enviados continuarán al siguiente L1VN (que es VN4) pasando por vn43. De esta manera, el L1VN puede detener el reenvío y llevar a cabo acciones de mantenimiento, como se explicará más adelante. De acuerdo con la naturaleza reactiva, las rutas de comunicación en VNIBR se crean solo cuando un PN fuente necesita enviar un paquete pero no conoce la ruta al PN destino. En ese caso, el PN fuente encola el paquete e inicia un proceso de inundación enviando un paquete de solicitud de ruta (RREQ) a los L1VNs que delimitan su segmento de vía. Cada uno de esos L1VNs pone su ID como el primer elemento de una lista de L1VNs en la cabecera del paquete RREQ y envía una copia a otros L1VNs que están a un segmento de vía de distancia4 . Un ID de broadcast se incluye en el paquete RREQ para evitar que cualquier L1VN transmita el mismo paquete más de una vez. De todos modos, la inundación implica muy poca sobrecarga, ya que involucra solo a los líderes de los VNs atravesados (salvo algunos PNs backups que los asisten como consecuencia de las pérdidas de paquetes). 4 En este proceso, se omite los segmentos de vía que no proporcionan conectividad con el otro extremo, tal como se determina por el intercambio de mensajes HELLO. 4.4 VNIBR: Un nuevo protocolo de encaminamiento sobre nodos virtuales basado en intersecciones 111 Una ruta se establece (i) cuando el paquete RREQ alcanza un L1VN que conoce una ruta válida hacia el destino PN, (ii) cuando un L1VN recibe el paquete RREQ con el bit de entrega configurado a 1, lo que significa que el destino PN justo está en el segmento de vía atravesada, o (iii) cuando un L1VN recibe el paquete RREQ con el bit de entrega establecido a 0, pero el destino PN está en la intersección actual. A continuación, se crea un paquete de Respuesta de Ruta (RREP) que viaja a lo largo del trayecto establecido en la cabecera del RREQ, permitiendo que los L1VNs en el trayecto configuren una ruta al PN destino en sus tablas de encaminamiento —al igual que la lista de L1VNs en el cabecera del paquete RREQ permitió a los L1VNs atravesados configurar entradas de ruta al PN fuente. Una vez que se ha establecido una ruta entre los PNs origen y destino, los paquetes de datos son enviados VN a VN mediante transmisiones unicast entre nodos líderes. La VaNetLayer sube las notificaciones de la capa de enlace a la capa de red cada vez que no es posible resolver la dirección MAC del siguiente salto, cuando el mecanismo RTS/CTS de IEEE 802.11 no puede reservar el canal compartido, o cuando no se puede recibir un acuse de recibo para un paquete de datos y cuando los intentos de retransmisión también son errados. En cualquier caso, cuando el PN transmisor detecta un fallo, este puede informar de ello a los otros nodos mediante el envío de un paquete de Error de Ruta (RERR) para los llamados precursores (es decir, los nodos vecinos para los que un paquete RREP fue generado o retransmitido) o intentar una reparación local mediante la difusión de un paquete RREQ y esperar una RREP para restablecer el enlace. En el primer caso, los paquetes de datos que el nodo estuvo retransmitiendo son descartados, por lo que no llegarán a sus destinos; en el segundo, los paquetes se almacenan temporalmente, el mayor tiempo posible. Gracias al intercambio de mensajes HELLO, los L1VNs puede adoptar medidas proactivas cuando las condiciones de conectividad a lo largo de un segmento de vía empeoran significativamente. También con respecto a las tareas de mantenimiento de rutas, VNIBR implementa un procedimiento de corrección para seguir los movimientos de los PN sin incurrir en reparaciones locales que podrían tomar un tiempo relativamente largo para resolver. Cuando un vehículo se mueve a un nuevo segmento de vía, este primero transmite un paquete RREQ con TTL=1, sin un destino explícito, al L1VN por donde acaba de pasar, en consecuencia este último actualiza su tabla de encaminamiento. Además, si hay otro L1VN en el otro extremo del segmento (es decir, si el segmento no es un callejón sin salida), el PN le envía un paquete RREQ especial con una lista de los PNs destino con los cuales mantiene sesiones de comunicación en curso, además de una lista de valores TTL configurados para el número de segmentos de vía atravesados en las correspondientes rutas. El L1VN comienza los procesos de inundación como se indicó anteriormente, en un intento por descubrir mejores rutas a esos destinos, evitando así el crecimiento innecesario en el número de saltos. Por ejemplo, si el vehículo PN1 en la figura 4.15 llega a la intersección de VN1 y gira a la izquierda en el segmento de vía entre VN1 y VN3, el paquete RREQ enviado hacia atrás para VN1 sirve para extender la ruta antigua VN5→VN2 para convertirse en VN5→VN2→VN1, mientras que el paquete RREQ enviado hacia adelante a VN3 puede ayudar a descubrir una mejor ruta a través de las intersecciones de VN3 y VN4. En lo que sigue de este capítulo analizaremos el rendimiento de nuestras propuestas en varios escenarios relacionados con la computación social ubicua. Para iniciar, valoraremos el comportamiento de la VNLayer+ y VNAODV+ en entornos VANETs; a continuación estudiaremos el rendimiento de la VaNetLayer con métricas orientadas a 112 Mejoras a la capa de virtualización en entornos VANET la capa de virtualización y a la capa de red. Finalmente, evaluaremos las prestaciones de nuestro nuevo protocolo de encaminamiento VNIBR. 4.5. Rendimiento de la VNLayer+ y VNAODV+ en escenarios vehiculares Para iniciar nuestro análisis sobre la capacidad de la capa de virtualización para brindar servicios de comunicación en entornos vehiculares, desarrollamos una serie de experimentos de simulación en los que analizamos el rendimiento de la VNLayer+ y VNAODV+ (descritos en el capítulo anterior) en comparación con la VNLayer, VNAODV, AODV y otros protocolos relevantes en la literatura. Para ello, diseñamos un ambiente de simulación que combina el simulador de red ns-3 [176] y el simulador de tránsito vehicular SUMO (del inglés, Simulator of Urban Mobility) [217]. Por un lado, empleamos ns-3 (versión 3.21) para simular las comunicaciones basadas en el estándar IEEE 802.11p, con la propagación de las señales inalámbricas en base al modelo de pérdida de propagación Nakagami y un rango de transmisión de 350 metros, de acuerdo con las mediciones de estudios recientes [150]. Por otro lado, SUMO nos proveyó de trazas de movilidad realistas para todos los vehículos en las calles de un área urbana de 872 × 872 metros del centro de Cuenca (Ecuador)5. Las comunicaciones involucran sesiones de tasa de bit constante (CBR, del inglés Constant Bit Rate) entre pares de nodos elegidos al azar para cada escenario. Cada sesión CBR se creó para transmitir cincuenta mensajes de 500 bytes por segundo durante todo el tiempo de simulación. El protocolo UDP (User Datagram Protocol) se utilizó en la capa de transporte, por lo que no hubo acuses de recibo ni retransmisiones. Cada simulación duró 450 segundos, pero las trazas para los primeros 50 segundos fueron omitidas para permitir que el protocolo de encaminamiento se estabilice antes de que se inicien las mediciones. Repetimos cada prueba 10 veces para cada punto de datos recogido. Estos y otros valores de los parámetros utilizados en nuestros experimentos se muestran en la tabla 4.1. En este escenario, primero compararemos las métricas relacionadas directamente con el desempeño general de la VNLayer y la VNLayer+. Luego de ello, pasamos a analizar métricas del rendimiento de encaminamiento para AODV, VNAODV, VNAODV+ (sobre la VNLayer+) y otros algoritmos relevantes de la literatura. 4.5.1. Medidas en la capa de virtualización Con el fin de comparar el rendimiento de los procedimientos de virtualización, pusimos a prueba tanto a la VNLayer como a la VNLayer+ bajo un mismo conjunto de escenarios generados al azar, variando el número de PNs moviéndose alrededor (de 40 a 320 vehículos) y el tamaño de las regiones cuadrangulares de las VNs (que dividen la región cuadrada del centro de la ciudad de Cuenca en rejillas de 4×4, 6×6 y 8×8). Analizaremos las siguientes mediciones: Duración promedio de los tiempos de parada de los VNs, directamente relacionada con el tiempo que se gasta en la recuperación de los VNs tras la salida de un líder. 5 Los mapas fueron extraídos de OpenStreetMap (de libre acceso). 4.5 Rendimiento de la VNLayer+ y VNAODV+ en escenarios vehiculares 113 VNLayer T_LeaderRequest T_RequestWait T_Heartbeat T_LeaderElect 50 ms 150 ms 5000 ms 5100 ms VNLayer+ T_RequestWait T_Heartbeat 200 ms 5000 ms VNAODV y VNAODV+ TTL de los paquetes RREQ Simulaciones Número de PNs Número de VNs Tasa de comunicaciones CBR Número de ejecuciones Monte Carlo por cada punto de dato 5 40, 80, 160, 320 4×4, 6×6, 8×8 50×500 bytes/s 10 Tabla 4.1: Valores de los parámetros usados para nuestras simulaciones. Sobrecarga de virtualización, relacionado con el número de mensajes de la VNLayer y de la VNLayer+, intercambiados entre los vehículos. Número de liderazgos duplicados, es decir, situaciones en las que dos vehículos actúan erróneamente al mismo tiempo como líderes del mismo nodo virtual. La duración promedio de los tiempos de parada de los VNs se representan en las figura 4.16 contra un número variable de PNs y VNs, respectivamente. El número de sesiones de comunicación se fijó inicialmente a 10. Se puede observar que la VNLayer+ reduce consistentemente la duración de los tiempos de parada alrededor del 10 % en comparación con la VNLayer, favoreciendo así una mayor disponibilidad de los nodos virtuales. Para un número fijo de VNs, como se muestra en la figura 4.16(a), incrementar el número de PNs implica un mayor número promedio de vehículos en cada región, aumentando así la probabilidad de que algunos nodos no líder (o incluso un recién llegado de una región vecina) puedan ser capaces de reclamar el liderazgo rápidamente. Por el contrario, con un número fijo de PNs, un mayor número de VNs implica un menor número de vehículos en cada región, aumentando así el número de situaciones en que la salida del líder tendría lugar en ausencia de backups sincronizados o provocaría regiones vacías. Por lo tanto, como se muestra en la figura 4.16(b), un aumento en el número de VNs implica un aumento en la duración media de sus tiempos de parada. La figura 4.17 representa la variación de la sobrecarga de virtualización causada por la VNLayer y la VNLayer+, de nuevo con 10 sesiones de comunicación. En general, un mayor número de PNs implica que más nodos intercambian mensajes para decidir sus roles, pero se puede ver en la figura 4.17(a) que la VNLayer+ logra un ahorro sustancial y tiene capacidad para acomodar un mayor número de PNs de una forma más escalable. A su vez, más regiones VNs implican que los diálogos ocurren en más lugares; de esta manera, los puntos correspondientes a 320 PNs y 64 VNs muestran que regiones VNs muy pequeñas —en relación con el rango de transmisión de las PNs— conducen a un fuerte aumento de la sobrecarga de tráfico de control en condiciones de tráfico denso. En la figura 4.17(b), sin embargo, observamos que las regiones no pueden ha- 114 Mejoras a la capa de virtualización en entornos VANET VNLayer (16 VNs) VNLayer (36 VNs) VNLayer (64 VNs) VNLayer+ (16 VNs) VNLayer+ (36 VNs) VNLayer+ (64 VNs) Tiempo medio de parada (s) 9 8 7 6 5 4 3 2 1 0 40 80 160 Cantidad de PNs 320 (a) Frente al número de nodos físicos. VNLayer+ (40 VNLayer+ (80 VNLayer+ (160 VNLayer+ (320 PNs) PNs) PNs) PNs) VNLayer (40 VNLayer (80 VNLayer (160 VNLayer (320 PNs) PNs) PNs) PNs) Tiempo medio de parada (s) 9 8 7 6 5 4 3 2 1 0 16 36 64 Cantidad de VNs (b) Frente al número de nodos virtuales. Figura 4.16: Duración promedio de los tiempo de parada de los VNs. 4.5 Rendimiento de la VNLayer+ y VNAODV+ en escenarios vehiculares VNLayer (16 VNs) VNLayer (36 VNs) VNLayer (64 VNs) VNLayer+ (16 VNs) VNLayer+ (36 VNs) VNLayer+ (64 VNs) Mensajes de capa virtual 60000 50000 40000 30000 20000 10000 0 40 80 160 Cantidad de PNs 320 (a) Frente al número de nodos físicos. VNLayer+ (40 VNLayer+ (80 VNLayer+ (160 VNLayer+ (320 PNs) PNs) PNs) PNs) VNLayer (40 VNLayer (80 VNLayer (160 VNLayer (320 PNs) PNs) PNs) PNs) Mensajes de capa virtual 60000 50000 40000 30000 20000 10000 0 16 36 Cantidad de VNs (b) Frente al número de nodos virtuales. Figura 4.17: Sobrecarga de virtualización. 64 115 116 Mejoras a la capa de virtualización en entornos VANET cerse arbitrariamente grandes, con el fin de no comprometer la premisa básica de que las transmisiones de un PN puedan ser escuchadas por todos los PNs en las regiones vecinas (sección 2.5.1). En el caso de 16 VNs (una rejilla de 4×4), de hecho, tenemos grandes cantidades de sobrecarga debido a que dos PNs entre regiones vecinas pueden estar activos hasta 616 metros de distancia, fallando así para comunicarse como se esperaba6 (recordamos al lector que el alcance de la transmisión fue de 350 metros). Centrándonos en la comparación de la VNLayer y la VNLayer+, está claro que las políticas de la VNLayer+ respecto a la elección de líder y designación de los backups son muy beneficiosas en términos de sobrecarga de tráfico de control, ya que compensan el hecho de que las sincronizaciones involucran tres mensajes en lugar de dos (véase la sección 3.2.4), y también por la sobrecarga debido al nuevo mecanismo de sincronización de vecinos (sección 3.2.6). Este último representa una parte significativa de la cantidad total de mensajes intercambiados por la VNLayer+ (del 15 % con 16 VNs a casi un 40 % con 64 VNs)7 , pero la gestión de las instantáneas de la información de estado es muy beneficioso para las capas superiores, como se muestra en la siguiente sección. En cuanto a los liderazgos duplicados, se confirmó la expectativa de que el nuevo procedimiento para la elección de líder aumentaría su probabilidad de ocurrencia (sección 3.2.3): como se muestra en la figura 4.18, tales situaciones no ocurren en absoluto en las simulaciones de la VNLayer, mientras que la VNLayer+ tuvo que lidiar con cientos de ellas. Los duplicados ocurrieron más a menudo con un mayor número de PNs, porque eso implica que más nodos recién llegados a los VNs pueden ser confundidos por las pérdidas de mensajes M_LeaderReply. Asimismo, el caso de 16 VNs evidencia una vez más que las regiones grandes —en relación con el rango de transmisión de los PNs— son propensas a causar problemas. Con regiones de tamaño medio, la gestión de los valores Since en los mensajes M_Heartbeat (ver sección 3.2.3) sirvieron para asegurar que el mejor líder siempre prevalecería y, como se verá en la siguiente sección, el rendimiento del protocolo de encaminamiento ejecutándose sobre la VNLayer+ no fue afectado por las muchas veces que dos (o más) nodos transitoriamente se comportaron como líderes de una misma VN. Finalmente, las gráficas de la figura 4.19 muestran la variación de las métricas anteriores con respecto al número de sesiones de comunicación entre pares de vehículos, considerando números fijos de PNs y VNs (160 y 36, respectivamente). Se puede observar que la VNLayer+ puede acomodar mayores cargas de tráfico que la VNLayer, porque sus cifras son consistentemente mejores en términos de disponibilidad de los VNs y sobrecarga de virtualización. El número de liderazgos duplicados aumenta moderadamente con el número de sesiones con la VNLayer+ debido a un mayor número colisiones en el medio inalámbrico; sin embargo, nuevamente, como veremos en la siguiente sección, esto no tiene un impacto en el rendimiento en las capas superiores. 6 A pesar de que esto no será mostrado en la sección 4.5.2, las numerosas pérdidas de paquetes incurridas con regiones excesivamente grandes tienen un gran impacto en el rendimiento de los protocolos que trabajan sobre la capa de virtualización. 7 Las sincronizaciones de vecinos implican dos mensajes cada vez que un nodo líder deja su región actual y esto obviamente ocurre más a menudo con regiones pequeñas que con las grandes. 4.5 Rendimiento de la VNLayer+ y VNAODV+ en escenarios vehiculares VNLayer (16 VNs) VNLayer (36 VNs) VNLayer (64 VNs) VNLayer+ (16 VNs) VNLayer+ (36 VNs) VNLayer+ (64 VNs) Liderazgos duplicados 600 500 400 300 200 100 0 40 80 160 Cantidad de PNs 320 (a) Frente al número de nodos físicos. VNLayer+ (40 VNLayer+ (80 VNLayer+ (160 VNLayer+ (320 PNs) PNs) PNs) PNs) VNLayer (40 VNLayer (80 VNLayer (160 VNLayer (320 PNs) PNs) PNs) PNs) Liderazgos duplicados 600 500 400 300 200 100 0 16 36 Cantidad de VNs (b) Frente al número de nodos virtuales. Figura 4.18: Duplicado de liderazgo. 64 117 118 Mejoras a la capa de virtualización en entornos VANET VNLayer VNLayer+ 3.5 45000 40000 3 Mensajes de capa virtual Tiempo medio de parada (s) VNLayer VNLayer+ 2.5 2 1.5 1 0.5 35000 30000 25000 20000 15000 10000 5000 0 0 0 5 10 15 20 25 0 Cantidad de sesiones 5 10 15 20 25 Cantidad de sesiones (a) Tiempos promedio de parada de los VNs. (b) Sobrecarga de virtualización. VNLayer+ VNLayer 450 Liderazgos duplicados 400 350 300 250 200 150 100 50 0 0 5 10 15 20 25 Cantidad de sesiones (c) Liderazgo duplicado. Figura 4.19: Rendimiento de la VNLayer y la VNLayer+ frente a la variación del número de seciones de comunicación simultáneas, con 160 PNs y 36 VNs. 4.5 Rendimiento de la VNLayer+ y VNAODV+ en escenarios vehiculares 119 4.5.2. Medidas en la capa de red Después de haber analizado las diferencias de rendimiento entre el VNLayer y la VNLayer+, ahora estudiaremos la capa de red con el fin de evaluar hasta qué punto el algoritmo VNAODV+ (ejecutándose sobre la VNLayer+) logra encaminar mejor que VNAODV (ejecutándose sobre la VNLayer) y AODV. Además, dado que AODV por mucho tiempo se ha ignorado como una opción adecuada para el encaminamiento en VANETs (ver [91, 128]), hemos querido evaluar el rendimiento de VNAODV+ en comparación con otros algoritmos relevantes en el estado del arte, que replicamos de los datos que aparecen en la literatura: Por un lado, hemos elegido PassCAR [231] como una instancia de encaminamiento basada en cluster que exhibe un gran nivel de acoplamiento entre las tareas de agrupamiento y de encaminamiento, como se explica en la sección 2.3.3. Este algoritmo se basa en la técnica de cluster pasivo presentada en [122], añadiendo un número de nuevos campos a los paquetes de una versión modificada de AODV (por ejemplo, los paquetes RREQ incluyen la ubicación del remitente, su velocidad, información de estado del cluster y una estimación de la vida útil del enlace). Por otra parte, consideramos los protocolos RBVT presentados en [177], que introducen un componente de encaminamiento geográfico sin depender de un servicio de localización para asegurar la disponibilidad de datos de localización precisos de todos los vehículos en la VANET. Tanto la versión reactiva (RBVTR) como la proactiva (RBVT-P) han mostrado un mejor desempeño que algoritmos topológicos (como AODV y OLSR [108]) y geográficos (GPSR [114] y GSR [141]). En la comparación de las pilas de protocolos representadas en la figura 4.20, hemos analizado los siguientes parámetros: Total de sobrecarga de tráfico de control, sumando la sobrecarga de encaminamiento y la de virtualización en los casos de VNAODV y VNAODV+. Tasa de entrega de paquetes, el ratio entre el número de paquetes entregados a los destinos y el número de paquetes enviados por las fuentes8 . Retardo extremo a extremo, como el promedio de tiempo que tardan los paquetes en alcanzar sus destinos después de su envío por las fuentes. A raíz de las observaciones realizadas sobre el tamaño de las regiones de los VNs, hemos fijado el número de VNs para la VNLayer y la VNLayer+ a 36 (ver sección 4.5.1). Ahora, vamos a ver el impacto de variar el número de PNs y el número de sesiones de comunicación establecidas entre ellos. La figura 4.21(a) representa la sobrecarga total medida para los seis esquemas de encaminamiento frente a un número variable de PNs moviéndose alrededor, con 10 sesiones de CBR entre ellos. En primer lugar, puede verse que AODV genera una gran cantidad de sobrecarga en todos los casos, sobre todo debido al quiebre de las rutas y el 8 Los paquetes pueden perderse debido a que UDP no gestiona acuses de recibo y retransmisiones, por lo que no hay manera de recuperarse de colisiones en la difusión de paquetes, quiebre de rutas, errores en la capa de virtualización para preservar la información del estado de los VNs, etc. 120 Mejoras a la capa de virtualización en entornos VANET !.1A0(0ABC8)% @#'% !"#$% $&!"#$% !"#$%!&' $&6(789% !"()*+,&' '())*!+% ,!"#$%-% .())/%01/2% +3$45+% +3$45'% :;;;%<=>/??.% Figura 4.20: Los esquemas de encaminamiento comparados en nuestras simulaciones. consecuente informe de errores y las acciones de reparación locales. Los procesos de cluster de VNAODV, VNAODV+ y PassCAR logran un ahorro significativo, porque siempre hay un PN que hace el trabajo (es decir, la generación de tráfico) en nombre de los otros. Sin embargo, VNAODV+ es más ventajoso, debido a las numerosas roturas evitadas por el procedimiento de corrección de ruta refinado (sección 3.3.2) y el nuevo procedimiento de soft handoff (sección 3.3.3), que se suman a la capacidad de la VNLayer+ para preservar su información de estado (las tablas de encaminamiento). Gracias al componente de encaminamiento geográfico, RBVT-R logra la sobrecarga de tráfico más baja, mientras que RBVT-P implica un coste mucho mayor (especialmente en los casos de VANETs densas) debido a la difusión continua de información de la topología de la red. La figura 4.21(b) muestra la variación de la sobrecarga con el número de sesiones CBR establecidas entre pares de vehículos, centrándose en las redes con 160 PNs. En este caso, VNAODV y VNAODV+ muestran un aumento más suave que AODV y PassCAR, lo que confirma la ventaja del encaminamiento a través de VNs estacionarios en lugar de PNs móviles. RBVT-R también escala bien y RBVT-P no se ve afectado notablemente a causa de la difusión continua de información topológica sin importar si hay nodos de comunicación o no. Las figuras 4.22(a) y 4.22(b) representan las tasas de entrega de paquetes medidas frente a un número variable de PNs (con 10 sesiones de comunicación) y de sesiones de comunicación (con 160 PNs), respectivamente. Los resultados muestran que VNAODV+ superó a los otros protocolos, excepto en los casos de VANETs dispersas con pocos nodos físicos (40 y 80 PNs), debido a los largos períodos de indisponibilidad de los VNs (ver figura 4.16(a)). RBVT-P logró los mejores resultados en esos escenarios, pero no pudo escalarlos a redes más densas, que fueron más favorables para RBVT-R debido a su sobrecarga mucho menor. Muchas de las pérdidas de paquetes con RBVT-R se produjeron porque, a pesar de que las rupturas de los trayectos no sucedieron con la misma frecuencia que con otros protocolos, las operaciones de reparación tomaron un tiempo relativamente más largo para ser completadas (el protocolo no permite reparaciones locales, por lo que la actualización de las rutas de los paquetes siempre tenía que llegar a las fuentes). VNAODV no pudo producir buenas tasas debido a los inconvenientes mencionados en la sección 3.2 sobre la VNLayer y en la sección 3.3 sobre la capa de red. En cambio, los mecanismos específicos de PassCAR para VANETs permitieron garantizar tasas de al menos un 80 %. AODV fue la peor elección en todos los casos. La figura 4.23 muestra que, con 10 sesiones de comunicación, las latencias de entrega con VNAODV+ fueron significativamente más bajas que las obtenidas con 4.5 Rendimiento de la VNLayer+ y VNAODV+ en escenarios vehiculares VNAODV+ VNAODV AODV PassCAR 121 RBVT-R RBVT-P 45 Sobrecarga total (MB) 40 35 30 25 20 15 10 5 0 40 80 160 Cantidad de PNs 320 (a) Frente al número de nodos físicos. VNAODV+ VNAODV AODV PassCAR RBVT-R RBVT-P 45 Sobrecarga total (MB) 40 35 30 25 20 15 10 5 0 1 5 10 15 20 25 Cantidad de sesiones (b) Frente al número de sesiones. Figura 4.21: Variación de la sobrecarga total de tráfico de control (capa de virtualización si hay + capa de red). 122 Mejoras a la capa de virtualización en entornos VANET VNAODV+ VNAODV AODV PassCAR RBVT-R RBVT-P 1 Tasa de entrega 0.9 0.8 0.7 0.6 0.5 40 80 160 Cantidad de PNs 320 (a) Frente al número de nodos físicos. VNAODV+ VNAODV AODV PassCAR RBVT-R RBVT-P 1 Tasa de entrega 0.9 0.8 0.7 0.6 0.5 1 5 10 15 20 25 Cantidad de sesiones (b) Frente al número de sesiones de comunicación. Figura 4.22: Variación de la tasa de entrega de paquetes. 4.5 Rendimiento de la VNLayer+ y VNAODV+ en escenarios vehiculares 123 VNAODV y AODV, lo que implica que nuestra propuesta no solo ofrece más paquetes, sino que además los entrega en menor tiempo. También fue más rápido que PassCAR, porque las rutas de múltiples saltos establecidas a través de las VNs fueron más cortas que las rutas calculadas con la técnica de cluster pasivo. Los retardos en RBVT-R y RBVT-P fueron comparables a los de VNAODV+ en redes VANETs dispersas, pero notamos una tendencia a hacer las rutas de múltiples saltos más largas con VANETs densas. A su vez, la figura 4.23(b) muestra que los retardos extremo a extremo con RBVT-R y RBVT-P se mantuvieron bastante constantes frente a un número cada vez mayor de sesiones de comunicación, debido al característico manejo del encaminamiento geográfico de las rutas de múltiples saltos a lo largo de las calles, independientemente de los nodos específicos que puedan estar allí. Por el contrario, VNAODV, VNAODV+ y PassCAR (los esquemas basados en cluster) imponen una carga mayor sobre los líderes de los clusters atravesados, y por tanto este incremento en el tráfico de datos implica una mayor espera en sus colas de salida. La curva correspondiente a AODV se mantiene también bastante constante, cerca de los tiempos de VNAODV+ con 25 sesiones. En este punto, es importante recordar que AODV entrega menos del 70 % de los paquetes, mientras que VNAODV+ entrega casi 20 % más de ellos. Muchos de estos paquetes adicionales llegan a su destino después de sobrevivir percances (por ejemplo, retiros de líderes o períodos de regiones vacías) gracias a los nuevos mecanismos de la VNLayer+, pero el exceso de retardo no supera unos pocos tiempos de ida y vuelta (del inglés round-trip times), por lo que los paquetes todavía pueden ser útiles para muchas aplicaciones. 4.5.3. Discusión A juzgar por los resultados que hemos obtenido, podemos confirmar que los cambios que hemos hecho a la VNLayer y el algoritmo VNAODV sirven para aumentar los beneficios de la capa de virtualización cuando se trata de soportar la ejecución de un algoritmo de encaminamiento reactivo como AODV en el dominio exigente de las VANETs. Los nuevos procedimientos que hemos puesto en la VNLayer+ convierten las redes vehiculares ad-hoc en entornos de comunicación más ágiles y fiables de lo que era posible con la VNLayer. Esto se produce a expensas de algún mayor coste computacional —hay varios procesos que se ejecutan detrás de las escenas— pero esto no debe considerarse como un problema en la medida en que los nodos en las VANETs no están sujetos a restricciones de energía, capacidades de almacenamiento y de computación como en el caso de las MANETs. A su vez, nuestro algoritmo VNAODV+ aprovecha los nuevos procedimientos de la capa de virtualización para prevenir o resolver rupturas de los trayectos en forma mucho más eficaz que AODV y VNAODV, que finalmente resulta en mayores tasas de entrega de paquetes y latencias más bajas. En general, nuestros experimentos de simulación han demostrado que la propuesta combinada de tener VNAODV+ sobre la VNLayer+ es competitiva con respecto al estado del arte en encaminamiento en redes VANET, al menos en escenarios urbanos. A pesar de que los resultados de la VNLayer+ ya son muy prometedores en escenarios vehiculares, vamos a refinarlos todavía más gracias a las mejoras diseñadas en la VaNetLayer (sección 4.2). En los siguientes experimentos estudiaremos el rendimiento de esta versión mejorada de la capa de virtualización diseñada específicamente para entornos vehiculares. 124 Mejoras a la capa de virtualización en entornos VANET VNAODV+ VNAODV AODV PassCAR RBVT-R RBVT-P Retardo extremo a extremo (ms) 120 100 80 60 40 20 0 40 80 160 Cantidad de PNs 320 (a) Frente al número de nodos físicos. VNAODV+ VNAODV AODV PassCAR RBVT-R RBVT-P Retardo extremo a extremo (ms) 120 100 80 60 40 20 0 1 5 10 15 20 25 Cantidad de sesiones (b) Frente al número de sesiones de comunicación. Figura 4.23: Variación del retardo extremo a extremo. 4.6 Análisis del rendimiento de la VaNetLayer 125 6*7*+(89+&8*&:+;<=9&>?@& 4%5& !"#$%!& !"#$%!& !"'()*+& !"#$%&"'$() ,---&./01223& Figura 4.24: La pila de protocolos para la comparación de la VNLayer y la VaNetLayer. 4.6. Análisis del rendimiento de la VaNetLayer En esta sección, presentamos los resultados de los experimentos de simulación desarrollados para evaluar los beneficios de los mecanismos de la VaNetLayer. Nos centramos en una comparación con la VNLayer, observando sus respectivas actuaciones en términos de métricas de la capa de virtualización y de red. 4.6.1. Medidas en la capa de virtualización y de red Con nuestro ambiente de simulación basado en SUMO y ns-3 procedimos a desarrollar nuestros experimentos considerando un escenario sobre las calles de una área urbana de 476 × 476 metros para el centro de la ciudad de Cuenca (Ecuador), previamente capturado en OpenStreetMap. Las comunicaciones fueron simuladas acorde al estándar IEEE 802.11p PHY/MAC (con la propagación de las señales inalámbricas de acuerdo al modelo shadowing radio y un rango máximo de transmisión de 250 metros). En los experimentos desarrollados, como se indica en la pila de protocolos mostrada en la figura 4.24, las comunicaciones involucran flujos de comunicación CBR entre pares de vehículos escogidos aleatoriamente para cada escenario, mientras el protocolo de transporte escogido fue UDP, lo que implica que no hay acuses de recibo (ACKs) ni retransmisión de paquetes desde la capa de transporte. El protocolo de encaminamiento escogido fue VNAODV9 con todas los mecanismos opcionales presentados en [240] (Recepción Directa, Enlaces Largos, ...) habilitados tanto para la VNLayer como para la VaNetLayer para asegurar justas comparaciones. La única diferencia fue que VNAODV ejecutándose sobre la VaNetLayer implementó la función receiveForneighborRegion() (sección 3.2.6) para permitir a los nodos recibir y retransmitir los paquetes que llegan a regiones vecinas vacías. Los valores escogidos para los parámetros más relevantes son mostrados en la tabla 4.2. Vale la pena señalar que, aunque cada escenario de simulación duró 450 segundos, las trazas de los primeros 50 segundos se han omitido para permitir que VNAODV se estabilice antes de que se inicien las mediciones. Con estos parámetros, nos hemos fijado las siguientes métricas, obteniendo los resultados representados en las figuras 4.25 y 4.26: 9 Aunque los resultados de los experimentos presentados en la sección anterior nos muestran un rendimiento superior de VNAODV+ sobre VNAODV, usaremos este último en ambas capas virtuales dado que VNAODV+ no es soportado por la VNLayer original y nuestra intensión es comparar las ventajas que los nuevos mecanismos introducidos en la VaNetLayer ofrecen a la capa de red.. 126 Mejoras a la capa de virtualización en entornos VANET VNLayer T_LeaderRequest T_RequestWait T_Heartbeat T_LeaderElect VaNetLayer T_RequestWait T_Heartbeat 50–250 ms 150 ms 5000 ms 5100 ms 200 ms 5000 ms VNAODV TTL de los paquetes RREQ Simulaciones Duración de los escenarios de simulación Número de ejecuciones Monte Carlo por cada punto de datos Número de vehículos (PNs) Límite de velocidad en el área urbana Número de flujos CBR Tasa de bit de los flujos CBR Coeficiente shadowing (β) 5 450 s 10 10 – 60 80 Km/h 10 500 KB/s 3 Tabla 4.2: Valores relevantes de los parámetros de simulación. Duración promedio de los tiempos de parada de los VNs, esto es, periodos durante los cuales hay PNs en una región pero ninguno de esos nodos está actuando como líder. Sobrecarga de tráfico de virtualización y de red, relacionado con el número de mensajes de la VNLayer y la VaNetLayer intercambiado entre los vehículos. Tasa de entrega de paquetes, esto es, la tasa entre el número de paquetes entregados a los destinos y el número de paquetes enviado por las fuentes. Número de liderazgos duplicados10 , esto es, situaciones en las cuales dos vehículos erróneamente actúan simultáneamente como líderes del mismo nodo virtual. Número de quiebres de ruta detectado por el mecanismo de acuse de recibo pasivo de VNAODV (ver sección 2.5.2). Para empezar, se puede ver en la figura 4.25(a) que la VaNetLayer reduce la duración de los tiempos de parada de los VNs en más de un 70 %, favoreciendo así a una mayor disponibilidad de los nodos virtuales. Esto pone de manifiesto las ventajas de pasar de la máquina de estados de la figura 3.2 a la de la figura 4.5, eliminando tiempos sin actividad en el estado UNKNOWN y el no esperar a que los líderes abandonen su región actual antes de iniciar una nueva elección. Por su parte, los resultados obtenidos con respecto a la sobrecarga de virtualización (figura 4.25(b)) y al número de liderazgos duplicados (figura 4.25(c)) fueron similares a los alcanzados con la VNLayer+ en ambientes vehiculares (ver sección 4.5.1). La VaNetLayer es una evolución de esta última y por tanto se beneficia de los distintos mecanismos implementados para mejorar la elección del líder y la designación de los 10 Estos estados de liderazgo duplicado en un VN son producidos por errores en la recepción de los mensajes de virtualización y difieren totalmente del nuevo mecanismo que escoge a uno o varios líderes adicionales para soportar la sobrecarga de tráfico de datos descrito en la sección 4.2.4 4.6 Análisis del rendimiento de la VaNetLayer 127 Tiempo promedio de parada (s) 1.6 VNLayer VaNetLayer 1.4 1.2 1 0.8 0.6 0.4 0.2 0 60 80 100 120 140 160 Cantidad de PNs (a) Duración promedio de los tiempos de parada de los VNs. 80000 Sobrecarga total (KB) 70000 60000 50000 40000 30000 20000 10000 VNLayer VaNetLayer 0 60 80 100 120 140 160 Cantidad de PNs (b) Sobrecarga del tráfico de virtualización y de red. 400 Liderazgos duplicados 350 300 250 VNLayer VaNetLayer 200 150 100 50 0 60 80 100 120 140 160 Cantidad de PNs (c) Número de liderazgos duplicados. Figura 4.25: Comparación de las métricas de las capas de red y de virtualización de la VNLayer y la VaNetLayer. 128 Mejoras a la capa de virtualización en entornos VANET Tasa de entrega (%) 1 0.8 0.6 0.4 0.2 VNLayer VaNetLayer 0 60 80 100 120 Cantidad de PNs 140 160 (a) Tasa de entrega de paquetes. 100 VNLayer VaNetLayer 90 Quiebres de ruta 80 70 60 50 40 30 20 10 0 60 80 100 120 140 160 Cantidad de PNs (b) Número de quiebres de ruta de VNAODV. Figura 4.26: Comparación de las métricas de las capas de red y de virtualización de la VNLayer y la VaNetLayer. 4.7 Análisis del rendimiento de VNIBR 129 backups, compensando de esta forma el tráfico adicional debido a los distintos procesos de sincronización. La VaNetLayer experimentó una gran cantidad de liderazgos duplicados, tal como sucedió con la VNLayer+ en la sección anterior; pero al igual que esta última, su impacto fue reducido gracias a la gestión de los valores Since en los mensajes M_Heartbeat (sección 3.2.3), lo que garantizó que el mejor líder sea escogido. Esto permitió que el rendimiento alcanzado del protocolo de encaminamiento VNAODV ejecutándose sobre la VaNetLayer no se vea afectado por las muchas veces en que 2 (o más) nodos, transitoria y erróneamente, se comportaron como líderes de un mismo VN. La evidencia preliminar es proporcionada por las curvas de rupturas de los trayectos representadas en la figura 4.26(b), con una diferencia de nueve veces, confirmando que VNAODV funciona mucho mejor ejecutándose sobre la VaNetLayer. Con respecto a la tasa de entrega de paquetes, la figura 4.26(a) muestra que la VaNetLayer consiguió superar el 90 % en todos los casos 11 , mientras que la VNLayer obtuvo valores entre un 30 % y 40 % menores, lo que implicó que muchos paquetes no llegaran a sus destinos. Estas ganancias también se vieron favorecidas —a más de las ventajas proporcionadas por el mecanismo de instantáneas de estado— por el nuevo diseño de los VNs para entornos vehiculares (sección 4.2.1), el comportamiento de mayor soporte de los backups al trabajo de los líderes (sección 4.2.3) —lo cual previno muchas pérdidas debido a los obstáculos—, así como los refinamientos a las políticas de gestión de los backups —que contribuyeron a la preservación de la información de estado de VNAODV— y la capacidad dinámica de ajustar el número de líderes en una VN en función de la sobrecarga de tráfico de datos. 4.6.2. Discusión Los resultados de nuestros experimentos muestran que las evoluciones interpuestas por la VaNetLayer sirven para aplicar con éxito el concepto de virtualización en las VANETs. La nueva disposición de los nodos virtuales, la gestión más eficiente de los líderes y backups, las nuevas funcionalidades de los backups para dar mayor soporte al trabajo de los líderes, la posibilidad de un mayor número de líderes por región, y los nuevos mecanismos para evitar la pérdida de información de las capas superiores han demostrado proporcionar un mayor rendimiento de la capa de virtualización en entornos vehiculares y generar un mejor respuesta del algoritmo VNAODV de lo que obtiene ejecutándose sobre la VNLayer original. En la sección siguiente, ampliaremos el análisis de las capacidades de la VaNetLayer para brindar un soporte adecuado para el despliegue de un nuevo protocolo de encaminamiento (VNIBR), contrastando su rendimiento con otros protocolos referentes en la literatura. 4.7. Análisis del rendimiento de VNIBR Con el fin de validar nuestra propuesta de encaminamiento sobre la VaNetLayer, al igual que los experimentos anteriores, hemos utilizando un entorno de simulación basado en ns-3 y SUMO. Por un lado, utilizamos ns-3 para las comunicaciones basadas 11 Hay que considerar que el número de vehículos en estas simulaciones fueron elegidos para garantizar densidades suficientemente altas y, por lo tanto, un cierto nivel de conectividad entre los VNs. De lo contrario, se producirían pérdidas adicionales tanto para el VNLayer como para la VaNetLayer, pero no habría nada que hacer al respecto solamente con las comunicaciones ad-hoc. 130 Mejoras a la capa de virtualización en entornos VANET en el estándar IEEE 802.11p, con la propagación de las señales de radio de acuerdo al modelo de Nakagami y un rango de transmisión de 350 metros. Por otro lado, SUMO proporcionó las trazas de movilidad realistas para un número variable de vehículos en las calles de una área urbana de 476 × 476 metros del centro de la ciudad de Cuenca (Ecuador). Específicamente, comparamos el rendimiento de encaminamiento de VNIBR frente a los cinco protocolos usados en los experimentos desarrollados en la sección 4.5.2 y mostrados en la figura 4.27: VNAODV+ y VNIBR ejecutándose sobre la VaNetLayer, las versiones reactiva y proactiva de RBVT, e IGRP en combinación con RLSMP como servicio de localización. Nuestros experimentos se enfocaron en la clase de escenarios para los cuales fue diseñado IGRP, con 32 vehículos descargando contenidos desde Internet a través de pasarelas en la vía (colocamos 3 de ellos en lugares al azar) y con un ancho de banda mucho mayor en el enlace de bajada que en el de subida. )7879:;<9&;7&=9>?@<&A"!& 56'& !"#$%!&' !"()*' !"#$%!& !"#$%'& ()!'&*&!+,-'& !+",-.+/,0' (...&/012334& Figura 4.27: La pila de protocolos de nuestras simulaciones. Dentro de estas configuraciones, hemos medido la sobrecarga de tráfico de control global (incluidos la sobrecarga debido a la capa de virtualización y al servicio de localización, si es que existen), las tasas de entrega de paquetes y los retardos extremo a extremo alcanzados por los esquemas de encaminamiento, repitiendo las simulaciones 10 veces para cada punto de datos recogidos. La figura 4.28 presenta los resultados promedio normalizado con respecto a los resultados de VNIBR, frente a diferentes valores de densidad del tránsito vehicular: escaso, medio, alto y congestionado (64, 128, 256 y 512 vehículos en movimiento alrededor, respectivamente). En términos de sobrecarga de tráfico de control, resultó que VNIBR es el esquema más eficiente salvo en escenarios de escaso tránsito vehicular, donde el intercambio de mensajes debido a la VaNetLayer supera la sobrecarga debido a IGRP y su servicio de localización, RLSMP. Con mayores densidades de tránsito, sin embargo, la sobrecarga debida a la difusión de información de localización acerca de muchos vehículos en movimiento hacen a IGRP inconveniente, a pesar de que RLSMP cuenta con mecanismos de agrupación y agregación de mensajes para evitar el crecimiento excesivo. VNAODV+ tiene la misma carga de virtualización que VNIBR, pero su sobrecarga es sostenidamente mayor debido a los intentos de mantener información de estado persistente en todo VN, no solo en los que cubren las intersecciones. RVBT-R provoca una mayor sobrecarga debido a los procesos de inundación en el descubrimiento de ruta (que implican a todos los nodos), debido a las frecuentes operaciones de mantenimiento ruta en escenarios de movilidad sin obstáculos (densidades de tránsito escaso y medio) y debido a la utilización de encaminamiento en la fuente, lo que hace que todos los paquetes sean grandes por incluir la lista de intersecciones para atravesar desde el origen al destino (esto se evita en VNIBR porque los L1VNs pueden gestionar las 4.7 Análisis del rendimiento de VNIBR 131 1.8 Sobrecarga relativa 1.6 1.4 1.2 1 0.8 0.6 64 128 256 Nodos en la VANET VNAODV+ VNIBR RBVT-R RBVT-P 512 IGRP Tasa de entrega relativa 1.15 1.1 1.05 1 0.95 0.9 0.85 64 128 256 512 Nodos en la VANET VNAODV+ VNIBR RBVT-R RBVT-P IGRP Retardo extremo a extremo relativo 1.2 1.15 1.1 1.05 1 0.95 64 128 256 Nodos en la VANET VNAODV+ VNIBR RBVT-R RBVT-P 512 IGRP Figura 4.28: Cantidad relativa (con respecto a VNIBR) de sobrecarga de tráfico de control, tasas de entrega de paquetes y retardo extremo a extremo frente a diferentes valores de densidad de tránsito vehicular. 132 Mejoras a la capa de virtualización en entornos VANET tablas de encaminamiento como estado persistente). Por último, no es de extrañar que RVBT-P conlleve una mayor sobrecarga debido a los periódicos esfuerzos para proactivamente descubrir y difundir la gráfica de conectividad entre los segmentos de vía; sin embargo, su enfoque estadístico basado en intersección, escala proporcionalmente mucho mejor para VANETs más densas que los algoritmos proactivos clásicos como OLSR. Respecto a las tasas de entrega de paquetes, la estabilidad garantizada por la VaNetLayer arrojó mejores resultados que los otros enfoques con densidades de tránsito medias y altas, mientras que hay pequeñas diferencias en los escenarios congestionados debido a la escasa movilidad de los vehículos. Con escaso tránsito, sin embargo, la VaNetLayer tenía problemas para mantener las tablas de encaminamiento como información persistente en los L1VNs. El impacto es mayor en VNAODV+, porque intenta almacenar información persistente en todos los VNs y hay más puntos potenciales de fallo. La estrategia de encaminamiento en la fuente de RBVT-R es más eficaz con escaso tránsito, pero sus tasas de entrega de paquetes tienden a ser peores que las de VNIBR con densidades medias y altas, ya que se ven afectadas por las pérdidas transitorias de la conectividad a lo largo de los segmentos de vía o en las intersecciones. Además, RBVT-R trata de hacer cumplir la ruta más corta desde el origen al destino, que no es necesariamente la mejor solución. Comentarios similares son válidos para el IGRP puramente geográfico, que es la mejor opción con bajas densidades, pero también sufre de pérdidas transitorias de la conectividad y desde los retardos ocasionados por el servicio de localización para seguir los movimientos de los vehículos que se comunican. Con RBVT-P, por último, se notaba que la difusión proactiva de la topología de la red erró en seguir los movimientos de los vehículos con densidades de tránsito escasos y medios. Para finalizar, observando el retardo extremo a extremo sufrido por los paquetes que llegan a los destinos deseados, VNIBR resultó ser más rápido que VNAODV+ en todos los casos, debido a que este último realiza un reenvío de paquetes más lento a lo largo de los segmentos de carretera (debido al procesamiento de los paquetes en todos los VNs) y sus procedimientos de mantenimiento de ruta produjeron rutas multisalto más largas. RBVT-R y RBVT-P, en contraste, tuvieron éxito en la explotación de rutas más cortas (i.e. rutas con pocos saltos) debido a que implementan mecanismos para que la distancia promedio entre saltos sucesivos sea mayor que la longitud promedio de una región VN de la VaNetLayer. Finalmente las rutas gestionadas por IGRP, al inicio de las sesiones de comunicaciones lograron tener un número de saltos menor que los de VNIBR, pero nuestros mecanismos de mantenimiento de ruta resultaron ser más sensibles, por lo que el resultado de VNIBR fue positivo. 4.7.1. Discusión Nuestros resultados muestran que la VaNetLayer puede soportar una combinación eficiente de mecanismos de encaminamiento topológico, geográfico y basado en intersecciones en escenarios urbanos de densidades de tránsito que van de medias a muy altas. VNIBR asegura un mejor rendimiento que VNAODV+ (un algoritmo virtualizado puramente topológico) gracias a los ahorros derivados de hacer toda la toma de decisiones en las intersecciones, debido a que esto significa una menor sobrecarga, un reenvío de paquetes más rápido y un menor número de puntos de fallo a lo largo de las rutas. En la comparación con encaminamientos topológicos, geográficos y basados en intersecciones sin virtualización, VNIBR aprovecha la capacidad de mantener un 4.7 Análisis del rendimiento de VNIBR 133 estado permanente en las intersecciones para superar al algoritmo proactivo RBVT-P en todos los escenarios y al reactivo homólogo RBVT-R con densidades de tránsito medio a muy alta. Por último, la comparación con IGRP (un algoritmo basado en intersección puramente geográfico) refuerza el punto de motivación de que el servicio de ubicación es un problema en gran medida sobrestimado: muchos autores han dado por sentado que los nodos pueden tener siempre la información de ubicación reciente y precisa sobre los demás nodos, pero esto solo puede lograrse razonablemente con una gran cantidad de sobrecarga en la red ad-hoc. A la luz de los resultados alcanzados en este capítulo, en lo que sigue de esta tesis analizaremos el rendimiento de la VaNetLayer frente a diferentes escenarios y experimentos relacionados con el soporte de una aplicación de descarga colaborativa y acceso a Internet. Capítulo 5 Descarga colaborativa de contenidos y acceso a Internet Habiendo introducido en el capítulo anterior las principales funcionalidades de la VaNetLayer, ahora estudiaremos su capacidad para soportar una aplicación orientada al acceso a Internet para la descarga colaborativa y la compartición de información en entornos VANET. 5.1. Introducción Como se analizó en la sección 1.1, se espera que las VANETs se conviertan en una extensión del Internet en un futuro cercano, allanando el camino a un amplio conjunto de innovadores servicios de información. El paradigma propuesto para la mayoría de esos servicios se basa en tres pasos: (i) descarga de contenidos desde servidores remotos a través de la infraestructura de Internet, (ii) introducción de esos paquetes de datos en el interior de la red VANET a través alguna conexión Wi-Fi, DSRC o 2G/3G/4G disponible en todos los vehículos (o en parte de ellos), y (iii) entregar los paquetes a los nodos pertinentes a través de peer to peer o comunicaciones oportunistas (aprovechando los encuentros entre vehículos). En este capítulo nos valdremos de este escenario para profundizar en las ventajas proporcionadas por la VaNetLayer tanto a la capa de red como a la de aplicación. En lo que sigue, en primera instancia hacemos una breve revisión de los protocolos de distribución P2P de contenido en las redes VANET; para luego analizar la capacidad de la VaNetLayer para dar soporte a aplicaciones de este tipo (sección 5.3) y a la descarga individual de contenidos desde la web (sección 5.4). 5.2. Distribución P2P de contenidos en VANETs Muchos servicios de información previstos para el futuro de las comunicaciones entre vehículos se basan en la infraestructura de Internet para descargar contenido desde servidores remotos, para luego entregar el contenido a los nodos pertinentes a través de comunicaciones peer-to-peer o redes oportunistas [84,85]. Uno de los primeros protocolos para descarga colaborativa de contenidos desde Internet en redes VANETs fue 135 136 Descarga colaborativa de contenidos y acceso a Internet SPAWN [171], inspirado en el conocido protocolos BitTorrent [53]. SPAWN gestiona enjambres (swarms) de nodos móviles que obtienen diferentes partes (chunks) de los contenidos desde hosts (semillas) a través de Internet durante periodos de conectividad. Un mecanismo de susurro (del inglés gossip) propaga la información de disponibilidad de contenido dentro de los enjambres, de forma tal que los nodos pueden obtener los pedazos de contenido que están necesitando desde los otros dispositivos. Los pedazos son transmitidos por TCP en la capa de transporte, mientras que UDP son empleados para los mensajes de susurro. Se emplea AODV para el encaminamiento dentro de la VANET. CarTorrent [127] fue propuesto como una evolución de SPAWN, con una estrategia diferente para seleccionar los pedazos a descargar. Este protocolo usa AODV en la capa de red y UDP en la de transporte. Los mensajes de susurro son limitados a un área de propagación de k-saltos, permitiendo a los pares conocer información sobre las piezas disponibles en otros nodos y la topología de red. Estos datos permiten a los usuarios escoger la pieza que solicitarán. En la selección de pares y contenidos se prefieren las piezas más raras en posesión de los pares más cercanos al nodo. Por su parte, CodeTorrent [131] introduce nuevos mecanismos para acelerar los procesos y ser más resistente contra la rápida movilidad, evitando cualquier protocolo de encaminamiento subyacente y dependiendo solo de las comunicaciones unicast a un salto. Denotamos a este esquema como MAID-0 por ser el representante más simple de una familia de algoritmos de encaminamiento llamados difusión de información asistida por movilidad (ver [22]). En este protocolo el nodo fuente y los nodos intermedios pueden codificar las piezas de contenido antes de transmitirlas. La decodificación de los contenidos se realiza cuando se ha obtenido n piezas codificadas, linealmente independientes. CodeTorrent utiliza UDP en la capa de transporte, pero no mantiene rutas multisalto de forma explícita en la capa de red; más bien, las comunicaciones multisalto están implícitas: los nodos intercambiando los paquetes de datos son siempre vecinos a un salto, pero los datos se propagan en la red a través de sus pares con intereses comunes. Esta aproximación (que denotamos por MAID-0) es usada en V-Torrent [85]. Este algoritmo introduce incentivos para que los nodos con capacidades de conexión 4G —dentro de un enjambre— habiliten sus conexiones para obtener nuevas piezas de contenido desde Internet siempre que el rendimiento de las conexiones al AP a través de la VANET sea deficiente (por ejemplo, debido a errores de transmisión por obstáculos o a la existencia de muchos saltos en los trayectos). Con la finalidad de disminuir los costes que se generan de la utilización de conexiones 4G por parte de los usuarios, los nodos interesados en conectarse a LTE (del inglés, Long Term Evolution) forman un cluster y seleccionan un líder que soporte esa conexión. Para evitar que los nodos rechacen convertirse en líderes debido a los costes, una estrategia round robin es usada para compartir el liderazgo entre todos. Siguiendo una aproximación radicalmente diferente, MobTorrent [46] usa redes inalámbricas de área amplia (WWANs, del inglés Wireless Wide-Area Networks) 2G/3G/4G como un canal de control para explotar el acceso intermitente de los vehículos a puntos de acceso a Internet (APs). Usando aquel canal, los vehículos (i) pueden pedir a uno o múltiples APs obtener previamente contenidos antes de pasar por su rango de cobertura y (ii) ofrecerse como colaboradores (mobile helpers) para transportar el contenido descargado previamente a otros nodos. Para ello, MobTorrent asume que la movilidad de los nodos puede ser predicha con un alto nivel de exactitud por sistemas de localización automática de vehículos (AVL, del inglés Automatic Vehicle Location) y por su historial de tránsito. Además, aplica un algoritmo sofisticado de programación 5.3 Aplicación de la VaNetLayer a la descarga colaborativa y diseminación P2P de contenidos 137 VaNetLayer T_RequestWait T_Heartbeat TTL de los paquetes de descubrimiento de VNAODV+ Simulaciones TTL para los paquetes de descubrimiento de ruta de AODV Duración de los escenarios de simulación Ejecuciones Monte Carlo por cada punto de datos Número de vehículos (PNs) Límite de velocidad en el área urbana Coeficiente shadowing (β) 200 ms 5000 ms 5 5 450 s 10 60 – 160 80 Km/h 3 Tabla 5.1: Valores relevantes de los parámetros de simulación. para explotar los procesos de obtención previa de contenidos por los APs y la replicación de datos en los vehículos colaboradores para maximizar la cantidad total de datos transferidos y la tasa promedio de transferencia a los nodos clientes. 5.3. Aplicación de la VaNetLayer a la descarga colaborativa y diseminación P2P de contenidos En esta sección analizamos la capacidad de la VaNetLayer para dar soporte a la descarga colaborativa y diseminación P2P de contenidos en redes vehiculares. Nuestro escenario está inspirado en la lógica de compartición de contenidos usada en SPAWN y CarTorrent (sección 5.2). La descarga y compartición de contenido se realiza al estilo Torrent, de manera que los nodos de un grupo (swarm) pueden obtener diferentes trozos de contenidos desde Internet y luego buscar las piezas que les faltaren desde otros nodos. Adoptamos el protocolo presentado en [127, 171], que incluye un mecanismo de susurro, para propagar la información sobre la disponibilidad de contenido y una estrategia para la selección de piezas de información impulsadas por la proximidad. Para el acceso a Internet utilizamos puntos de acceso Wi-Fi con un rango de transmisión de 250 metros y una tasa de bits de 11 Mbps, pero el intercambio de las piezas de información se llevó a cabo exclusivamente a través de las comunicaciones ad-hoc. Para la ejecución de los experimentos usamos nuestro ambiente de simulación basado en SUMO y ns-3, considerando un escenario sobre las calles de una área urbana de 476 × 476 metros del centro de la ciudad de Cuenca (Ecuador), previamente capturado en OpenStreetMap. Las comunicaciones fueron simuladas acorde al estándar IEEE 802.11p PHY/MAC (con el modelo shadowing para la propagación de señales inalámbricas y un rango máximo de transmisión de 250 metros). Los valores escogidos para los parámetros más relevantes son mostrados en la tabla 5.1. En la capa de transporte, usamos UDP para entregar los mensajes de susurro y las piezas de contenido. Por debajo, en la pila de protocolos, consideramos 5 diferentes esquemas de encaminamiento como se muestra en la figura 5.1: El primer esquema es AODV, usado en muchos trabajos en la literatura relacionados a los mecanismos de encaminamiento en VANETs (ya sea soportando nuevas 138 Descarga colaborativa de contenidos y acceso a Internet propuestas en la capa de transporte o en la capa de aplicación, o como referencia para comparaciones del rendimiento de encaminamiento [60, 127, 155, 227]). El segundo esquema es AODV ejecutándose sobre la técnica de cluster pasivo de PassCAR [231]. El tercer esquema es nuestra versión virtualizada de AODV (VNAODV+) desplegada sobre la VaNetLayer1. El cuarto esquema es el algoritmo reactivo llamado RBVT-R, que se basa en el reenvío geográfico para transferir paquetes a lo largo de los segmentos de vía en el trayecto desde fuentes a destinos con el fin de reducir la sensibilidad de la ruta a los movimientos individuales de los nodos2 . El quinto esquema es el mecanismo de difusión de información de movilidad asistida (MAID-0) [22], por el cual los nodos intercambian mensajes de la disponibilidad de contenidos y piezas de información solo cuando están dentro del rango de comunicación directa entre sí (ellos también pueden escuchar las transmisiones en el medio inalámbrico compartido). Las rutas multisalto no se manejan aquí de forma explícita, pero la comunicación multisalto se produce cuando los paquetes de datos se propagan a través de la red de pares con intereses comunes. #<2=1>?1%@%A32<B3C1=3DC%;8;% :#;% !"#$% !"#$% !"#$%!&' -./%012345% !(")*+(,)-' &'$()&% *!+#),% +666%7,8/990% Figura 5.1: Los cinco esquemas de encaminamiento usados para la aplicación de descarga y diseminación P2P. Hemos medido el rendimiento de cinco esquemas de encaminamiento en términos de sobrecarga de tráfico de control, tasa de entrega de paquetes y tiempos de descarga, considerando escenarios en los que todos los vehículos podrían descargar D MB de contenido (para este escenario, D fue establecido a 10 MB). Se consideraron 3 valores diferentes de densidad del tránsito vehicular (bajo, medio y alto), así como 3 niveles diferentes de densidad de agrupamiento (swarming): LoS=0 (0 % de swarming) significa que todos los vehículos se descargan D MB de contenidos individualizados, así que no hay trozos de contenido comunes y 1 En los experimentos desarrollados en este capítulo, hemos utilizado VNAODV+ en la capa de red dado que al momento de realizar estos experimentos aún no contábamos con la propuesta y validación de VNIBR que posteriormente mostró un mejor rendimiento, como se evidenció en el capítulo anterior. 2 A diferencia de los algoritmos puramente geográficos como GPSR [114] y GSR [141], RBVT-R no depende de un servicio de localización para proporcionar datos de localización precisos de todos los nodos de la VANET. Como se explica en [202], la disponibilidad global de dicha información a menudo se da por sentado en los estudios sobre encaminamiento geográfico, mientras que sigue siendo un problema importante debido a la sobrecarga adicional y los muchos inconvenientes causados por datos imprecisos o antiguos. 5.3 Aplicación de la VaNetLayer a la descarga colaborativa y diseminación P2P de contenidos 139 simplemente mide la capacidad de cada esquema de encaminamiento para soportar las comunicaciones con los puntos de acceso Wi-Fi. LoS=1 (100 % de swarming) significa que todos los vehículos están interesados en los mismos D MB de contenido, por lo que (si lo permite el esquema de comunicación) pueden descargar diferentes trozos de contenido a través de los puntos de acceso Wi-Fi y luego intercambiar esos trozos en el VANET. Finalmente, LoS=0.5 (50 % de swarming) denota el caso intermedio en que cada D vehículo descarga D 2 MB de contenido individualizado, más 2 MB que son comunes a todos los demás vehículos. Los resultados en términos de sobrecarga de tráfico de control están representados en la figura 5.2. En primer lugar, AODV causa la mayor cantidad de sobrecarga en todos los casos, principalmente debido a las tormentas de broadcast de los paquetes de control que involucran a todos los nodos en los procesos de descubrimientos de ruta. El enfoque de cluster de PassCAR y la VaNetLayer logran ahorros significativos mediante la selección sistemática de un nodo para actuar en nombre de muchos otros. Los procedimientos de nuestra VaNetLayer causan mayor sobrecarga que el cluster pasivo de PassCAR debido a las sincronizaciones de estado entre los líderes y los backups, que son sin embargo importantes para otros parámetros del rendimiento de encaminamiento (como explicaremos a continuación). La sobrecarga debido a RBVTR fue aún más reducida, gracias a las características de encaminamiento geográfico. Por último, el enfoque MAID-0 resultó producir la menor sobrecarga porque no hace ningún intento por establecer rutas de comunicación o para crear una infraestructura virtual de ningún tipo. El impacto del nivel de swarming es similar en AODV y RBVT-R: cuanto mayor sean las posibilidades de obtener contenido desde nodos cercanos en lugar de atravesar rutas potencialmente largas para llegar a los puntos de acceso Wi-Fi, menor es la sobrecarga. Con respecto a PassCAR y la VaNetLayer, la sobrecarga causada por sus procesos de cluster también disminuyen, pero en menor medida dado que son independientes de las fuentes y destinos de comunicaciones. En el caso del enfoque MAID-0, un mayor nivel de swarming provoca una mayor sobrecarga, debido a los mensajes intercambiados tras descubrir que un nodo tiene trozos de contenido necesarios para otros. La figura 5.3 resume los resultados de los cinco esquemas de encaminamiento con respecto a las tasas de entrega de paquetes alcanzadas. En este caso, el enfoque MAID0 logra las mejores tasas (muy cercanos al 100 %). Sin embargo, esto es algo engañoso debido al hecho de que solo permite la comunicación a un salto, mientras que los otros esquemas también permiten rutas multisalto. AODV tiene las peores cifras, una vez más, a pesar de que mejoran con el nivel de swarming (las rutas entre dos vehículos son comparativamente más cortas que las rutas a los puntos de acceso Wi-Fi). El enfoque de cluster pasivo de PassCAR mejora los ratios de AODV significativamente, gracias a la forma en que gestiona las estimaciones de la densidad de vehículos, calidad del enlace y la sostenibilidad del enlace. RBVT-R alcanza resultados similares, que se mejoran con mayores niveles de swarming. En cualquier caso, la VaNetLayer aseguró mejores tasas de entrega que estos esquemas, alcanzando valores similares a los de la figura 4.26(a). Esta observación refuerza el impacto positivo de la mayoría de los mecanismos establecidos en esta tesis, que se esfuerzan por evitar las pérdidas de paquetes y así preservar la información que pasa a través de los nodos virtuales. 140 Descarga colaborativa de contenidos y acceso a Internet Sobrecarga (MB) 3.5 3 2.5 2 1.5 1 0.5 0 AO P V R M AO Pa VN RB MA AO Pa VN RB MA DV ass NAO BVT AID DV ss AO VT ID DV ss AO VT ID CA DV -R -0 CA DV -R -0 CA DV -R -0 R +/ R +/ R +/ Va Va Va Ne Ne Ne tL tL tL ay ay ay er er er Densidad baja Densidad media Densidad alta (a) Con LoS=0. Sobrecarga (MB) 3.5 3 2.5 2 1.5 1 0.5 0 AO P V R M AO Pa VN RB MA AO Pa VN RB MA DV ass NAO BVT AID DV ss AO VT ID DV ss AO VT ID CA DV -R -0 CA DV -R -0 CA DV -R -0 R +/ R +/ R +/ Va Va Va Ne Ne Ne tL tL tL ay ay ay er er er Densidad baja Densidad media Densidad alta (b) Con LoS=0.5. Sobrecarga (MB) 3.5 3 2.5 2 1.5 1 0.5 0 AO P V R M AO Pa VN RB MA AO Pa VN RB MA DV ass NAO BVT AID DV ss AO VT ID DV ss AO VT ID CA DV -R -0 CA DV -R -0 CA DV -R -0 R +/ R +/ R +/ Va Va Va Ne Ne Ne tL tL tL ay ay ay er er er Densidad baja Densidad media Densidad alta (c) Con LoS=1. Figura 5.2: Sobrecarga de tráfico de control de los cinco esquemas de encaminamiento de la figura 5.1 frente a diferentes densidades de tránsito. Tasa de entrega (%) 5.3 Aplicación de la VaNetLayer a la descarga colaborativa y diseminación P2P de contenidos 141 1 0.95 0.9 0.85 0.8 0.75 0.7 AO P V R M AO Pa VN RB MA AO Pa VN RB MA DV ass NAO BVT AID DV ss AO VT ID DV ss AO VT ID CA DV -R -0 CA DV -R -0 CA DV -R -0 R +/ R +/ R +/ Va Va Va Ne Ne Ne tL tL tL ay ay ay er er er Densidad baja Densidad media Densidad alta Tasa de entrega (%) (a) Con LoS=0. 1 0.95 0.9 0.85 0.8 0.75 0.7 AO P V R M AO Pa VN RB MA AO Pa VN RB MA DV ass NAO BVT AID DV ss AO VT ID DV ss AO VT ID CA DV -R -0 CA DV -R -0 CA DV -R -0 R +/ R +/ R +/ Va Va Va Ne Ne Ne tL tL tL ay ay ay er er er Densidad baja Densidad media Densidad alta Tasa de entrega (%) (b) Con LoS=0.5. 1 0.95 0.9 0.85 0.8 0.75 0.7 AO P V R M AO Pa VN RB MA AO Pa VN RB MA DV ass NAO BVT AID DV ss AO VT ID DV ss AO VT ID CA DV -R -0 CA DV -R -0 CA DV -R -0 R +/ R +/ R +/ Va Va Va Ne Ne Ne tL tL tL ay ay ay er er er Densidad baja Densidad media Densidad alta (c) Con LoS=1. Figura 5.3: Tasas de entrega de paquetes de los 5 esquemas de encaminamiento de la figura 5.1 frente a diferentes densidades de tránsito. Descarga colaborativa de contenidos y acceso a Internet Tiempo de descarga (s) 142 60 50 40 30 20 10 0 AO P V R M AO Pa VN RB MA AO Pa VN RB MA DV ass NAO BVT AID DV ss AO VT ID DV ss AO VT ID CA DV -R -0 CA DV -R -0 CA DV -R -0 R +/ R +/ R +/ Va Va Va Ne Ne Ne tL tL tL ay ay ay er er er Densidad baja Densidad media Densidad alta Tiempo de descarga (s) (a) Con LoS=0. 60 50 40 30 20 10 0 AO P V R M AO Pa VN RB MA AO Pa VN RB MA DV ass NAO BVT AID DV ss AO VT ID DV ss AO VT ID CA DV -R -0 CA DV -R -0 CA DV -R -0 R +/ R +/ R +/ Va Va Va Ne Ne Ne tL tL tL ay ay ay er er er Densidad baja Densidad media Densidad alta Tiempo de descarga (s) (b) Con LoS=0.5. 60 50 40 30 20 10 0 AO P V R M AO Pa VN RB MA AO Pa VN RB MA DV ass NAO BVT AID DV ss AO VT ID DV ss AO VT ID CA DV -R -0 CA DV -R -0 CA DV -R -0 R +/ R +/ R +/ Va Va Va Ne Ne Ne tL tL tL ay ay ay er er er Densidad baja Densidad media Densidad alta (c) Con LoS=1. Figura 5.4: Tiempos promedio de descarga medidos para los 5 esquemas de encaminamiento de la figura 5.1 frente a diferentes densidades de tránsito. 5.4 Soporte de la VaNetLayer al acceso individualizado a contenido web 143 Por último, los tiempos promedio de los nodos en descargar completamente el contenido están representados en la figura 5.4. La mayor densidad de tránsito y los mayores niveles de swarming fueron positivos para todos los esquemas de encaminamiento, pero en grados muy diversos. Una vez más, el esquema de cluster pasivo de PassCAR mejoró el desempeño relativamente pobre de AODV, hasta el punto de lograr resultados ligeramente mejores que RBVT-R (la estructura de cluster tuvo el efecto positivo de reducir el número de saltos a lo largo de las rutas). VNAODV+ ejecutándose sobre nuestra VaNetLayer garantiza los tiempos de descarga más cortos, independientemente de la densidad del tránsito con 0 % de swarming y el 50 % de swarming, debido a los beneficios combinados de (i) el establecimiento de rutas con menor número de saltos que AODV y RBVT-R, y (ii) de disfrutar mayores tasas de entrega de paquetes como se explicó anteriormente. El buen desempeño de la VaNetLayer seguía siendo notable con 100 % de swarming, pero en este caso fue superado por MAID-0, que tiene una velocidad impresionante con muchos vehículos en movimiento alrededor y descargando los mismos contenidos. Por el contrario, MAID-0 fue muy inferior a todos los demás esquemas con 0 % de swarming (dado que cada nodo solo podía conseguir nuevas piezas al pasar cerca de los puntos de acceso Wi-Fi) y nos dieron resultados promedio con el 50 % de swarming. 5.3.1. Discusión Los resultados de nuestros experimentos muestran que las mejoras y nuevos mecanismos implementados a la VaNetLayer han demostrado ser ventajosos en las simulaciones de un arquetipo de aplicación de descarga P2P y difusión de contenidos. Es notable que, mientras AODV estaba prácticamente descartado para aplicaciones en ambientes vehiculares (ver [128]), VNAODV+ supera a otros esquemas de encaminamiento en escenarios urbanos, incluyendo muestras de cluster pasivo, encaminamiento geográfico y de difusión de información asistida por movilidad. Por lo tanto, podemos decir que la infraestructura de nodos virtuales convierte a las VANETs en entornos de comunicación más rápidos y fiables, para lograr un equilibrio interesante entre la sobrecarga de tráfico de control y la tasa de entrega de paquetes a nivel de aplicación, independientemente de la densidad de tránsito y trabajando bien para entregar tanto los contenidos individualizados, como los comunes a todos los nodos. En la siguiente sección ampliaremos nuestro estudio de la VaNetLayer, estudiando las prestaciones que brinda en el soporte de una propuesta de aplicación para la descarga individualizada de contenidos web. 5.4. Soporte de la VaNetLayer al acceso individualizado a contenido web En esta sección, presentamos y evaluamos una aproximación para soportar el acceso individual a contenidos web dentro de un entorno vehicular, basado en la VaNetLayer. Nuestra propuesta toma lugar a través de HTTP como es usual. Para ello, los nodos que tienen un acceso permanente o transitorio, se anuncian como proxies HTTP usando un protocolo push como el presentado en [95]. La pila de protocolos de nuestra propuesta se muestra en la figura 5.5, VNAODV+ se emplea para ejecutar los procesos de encaminamiento y TCP en la capa de transporte. 144 Descarga colaborativa de contenidos y acceso a Internet .-/01)2'344.' 2345644789% 521% !"#$%!&' 26:75644789% 0#1% !"#$% &!'#()% !(")*+(,)-' '***%+),-../% Figura 5.5: La pila de protocolos de nuestra propuesta. Desarrollamos un conjunto de simulaciones para comparar nuestra solución sobre la VaNetLayer con CarTorrent y CodeTorrent, que implementamos desde los detalles en la literatura —en la figura 5.5 se puede observar la pila de protocolos para soportar estos dos algoritmos. De entre el resto de soluciones mencionadas en la sección 5.2, no pudimos considerar a V-Torrent, porque al momento del desarrollo de estos experimentos era demasiado reciente y a MobTorrent dado que no encontramos detalles suficientes para replicar su algoritmo de planificación. Nuestros entorno de simulación, al igual que en los experimentos precedentes, se basó en ns-3 para simular las comunicaciones con IEEE 802.11p PHY/MAC (utilizando el modelo de propagación shadowing [209]) y todos los protocolos en las capas superiores, y SUMO [217] para obtener trazas de movilidad realistas para 128 vehículos en las calles de una área urbana de 714 × 714 metros del centro de la ciudad de Cuenca, Ecuador (capturada previamente en OpenStreetMap). Cuatro puntos de acceso Wi-Fi (colocados al azar al borde de las calles) proveyeron de las únicas conexiones a Internet (es decir, no hubo conexiones 2G/3G/4G disponibles para los vehículos). Los valores elegidos para los parámetros más relevantes se muestran en la tabla 5.2; vale la pena señalar que los parámetros de CarTorrent fueron los mismos que en los experimentos de [131], excepto por el hecho de que el TTL de los paquetes de descubrimiento de ruta de AODV se fijó a 5 (en lugar de 3) para hacer más probable para los vehículos encontrar rutas hacia los puntos de acceso Wi-Fi. Dentro de estos parámetros, medimos el rendimiento de 4 esquemas de comunicación en términos de sobrecarga de tráfico de control, tasas de entrega de paquetes y los tiempos de descarga, frente a los siguientes parámetros: Sup: el porcentaje de nodos que soportan el esquema en cuestión. Sim: el número de vehículos descargando contenido al mismo tiempo. D: la cantidad de datos que cada vehículo quiere descargar. LoS: el nivel de swarming, como en el caso de los experimentos de la sección anterior, con valores de 0 % de swarming (LoS=0), 50 % de swarming (LoS=0.5) y 100 % de swarming (LoS=1). A continuación, vamos a discutir primero el impacto de LoS en la sobrecarga de tráfico, las tasas de entrega de paquetes y los tiempos de descarga obtenidos por cada esquema con valores fijos para los otros parámetros, es decir, Sup=64 vehículos de soporte, Sim=16 vehículos (elegidos al azar entre los ya mencionado 64) descargando contenido al mismo tiempo, y D=1 MB de datos a descargar por cada vehículo. A 5.4 Soporte de la VaNetLayer al acceso individualizado a contenido web VNLayer T_LeaderRequest T_RequestWait T_Heartbeat T_LeaderElect TTL de los paquetes de descubrimiento de ruta de VNAODV VaNetLayer T_RequestWait T_Heartbeat TTL de los paquetes de descubrimiento de ruta de VNAODV+ CarTorrent TTL de los paquetes de descubrimiento de ruta de AODV TTL de los mensajes de susurro Periodo de difusión de los mensajes de disponibilidad de piezas Probabilidad de difusión de mensajes de susurro para nodos no interesados Probabilidad de difusión de mensajes de susurro para nodos interesados Punto de acceso Wi-Fi Rango de transmisión Tasa de bits Simulador Ejecuciones Monte Carlo por cada punto de dato Coeficiente shadowing (β) 145 50–250 ms 150 ms 5000 ms 5100 ms 5 200 ms 5000 ms 5 5 3 5000 ms 0.1 0.8 250 m 11 Mbps 10 3 Tabla 5.2: Valores de los parámetros usados en nuestra simulación. 146 Descarga colaborativa de contenidos y acceso a Internet partir de ello, en esta misma sección, discutiremos el impacto de la variación de estos parámetros. Sobrecarga de tráfico de control frente al nivel de swarming Las gráficas en la figura 5.6 representan la cantidad de la sobrecarga combinada generada por la capa de encaminamiento y la capa de virtualización (cuando exista) con Sup=64, Sim=16 y D=1 MB. Sobrecarga (KB) 300 250 200 150 100 50 0 VN VN Ca Co VN V C C VN V C C A r d AO NAO arT ode AO NAO arT ode DV ODV Tor eTo DV D o T DV D o T /V + r r /V V+/ rre orr /V V+/ rre orr NL /Va ent ren NL Va nt en NL Va n en ay Ne t ay Ne t ay Ne t t er tL er tL er tL ay ay ay er er er AO LoS=0 LoS=0.5 LoS=1 Figura 5.6: Sobrecarga de tráfico de control de los cuatro esquemas de comunicación, frente a los diferentes niveles de swarming. En primer lugar, llama la atención que la VNLayer original causa la mayor cantidad de sobrecarga en todos los casos, debido a las numerosas deficiencias mencionadas al principio de la sección 3.2 que hacen muy difícil obtener el contenido entregado a los vehículos. Por el contrario, la sobrecarga de CodeTorrent es mucho menor, ya que no realiza intentos por establecer trayectos de comunicación o crear una infraestructura virtual de cualquier tipo. A medio camino entre esos extremos, la VaNetLayer causa una cantidad de sobrecarga comparable a la de CarTorrent, pero sus orígenes son radicalmente diferentes: Por un lado, la mayor parte de sobrecarga de CarTorrent es debido a (i) las «tormentas de broadcast» causadas por el proceso de descubrimiento de ruta de AODV (al igual que en los experimentos analizados en la sección anterior), y (ii) las operaciones de reparación frecuentes resultantes de los numerosos quiebres en las rutas que se producen simplemente cuando dos vehículos que eran nodos consecutivos a lo largo de un trayecto se separan el uno del otro. Por otro lado, con la VaNetLayer, el mantenimiento de la infraestructura de VNs conlleva un intercambio constante de mensajes y la distribución de los anuncios de proxy implica un mayor volumen de datos que los provocados por los mensajes de susurro de CarTorrent. Sin embargo, la estructura de cluster inherente (seleccionando sistemáticamente un nodo para actuar en nombre de muchos otros) asegura un ahorro significativo para VNAODV+ en comparación con AODV, y el hecho de que las rutas de comunicación unen nodos virtuales (en lugar de 5.4 Soporte de la VaNetLayer al acceso individualizado a contenido web 147 nodos físicos) hace que que las reparaciones de ruta ocurran con mucho menos frecuencia, con una dependencia significativamente menor de los movimientos individuales de los vehículos. Ciertamente, está claro que las políticas de la VaNetLayer respecto a la elección de líder y designación de backups son muy beneficiosas, ya que compensan el hecho de que las sincronizaciones en la VaNetLayer involucran tres mensajes en lugar de dos como con la VNLayer (sección 3.2.4), y también para la sobrecarga debido al nuevo mecanismo de instantáneas de estado (sección 3.2.6). El nivel de swarming no afectó a la sobrecarga causada por la VNLayer y los esquemas de la VaNetLayer, porque nuestro enfoque basado en proxies HTTP no permite obtener trozos comunes desde otros nodos en la VANET (en otras palabras, se requiere que cada vehículo obtenga D MB a través de los puntos de acceso Wi-Fi). Por el contrario, un mayor nivel de swarming es beneficioso para CarTorrent, porque implica mayores posibilidades de obtener el contenido de los vehículos cercanos, en lugar de ir a través de rutas potencialmente largas para llegar a los puntos de acceso WiFi. En el caso de CodeTorrent, un mayor nivel de swarming aumenta las probabilidades de que dos vehículos que se encuentran puedan tener fragmentos de los archivos de contenidos para intercambiar, lo que les permite obtener datos no sólo al pasar por los puntos de acceso Wi-Fi. Una mayor cantidad de mensajes intercambiados entre pares de vehículos conllevan mayor sobrecarga, pero CodeTorrent alcanza las cantidades más bajas de todos modos. Tasa de entrega de paquetes frente al nivel de swarming La figura 5.7 resume los resultados de los 4 esquemas de comunicación con respecto a las tasas de entrega de paquetes que ellos alcanzan, de nuevo con Sup=64, Sim=16 y D=1 MB. Tasa de entrega (%) 1 0.95 0.9 0.85 0.8 0.75 0.7 0.65 0.6 VN V C C VN VN Ca Co VN VN Ca Co AO NAO arT ode AO AO rT de AO AO rT de DV DV or To DV DV or To DV DV or To /V +/ re rr /V +/ re rr /V +/ re rr NL Va nt en NL Va nt en NL Va nt en ay Ne t ay Ne t ay Ne t er tL er tL er tL ay ay ay er er er LoS=0 LoS=0.5 LoS=1 Figura 5.7: Tasas de entrega de paquetes de los cuatro esquemas de comunicación, frente a diferentes niveles de swarming. En este caso, el enfoque MAID-0 de CodeTorrent logra consistentemente los mejores ratios (muy cercanos al 100 %). No obstante, como se comentó en la sección Descarga colaborativa de contenidos y acceso a Internet Tiempo de descarga (s) 148 60 50 40 30 20 10 0 VN VN Ca Co VN V C C VN V C C A r d AO NAO arT ode AO NAO arT ode DV ODV Tor eTo DV D o T DV D o T /V +/ re rr /V V+/ rre orr /V V+/ rre orr NL V n en NL V n en NL V n en ay aNe t t ay aNe t t ay aNe t t er tL er tL er tL ay ay ay er er er AO LoS=0 LoS=0.5 LoS=1 Figura 5.8: Tiempos de descarga promedio medida para los cuatro esquemas de comunicación, frente a disferentes niveles de swarming. anterior, esto es algo engañoso debido al hecho de que solo permite comunicaciones a un salto, mientras que los otros esquemas permiten también rutas con múltiples saltos. La VNLayer original tuvo un mal rendimiento en todos los casos, debido a la ausencia de mecanismos adecuados para comunicaciones en ambientes vehiculares. En el caso de CarTorrent, AODV causó muchas pérdidas debido a las roturas de trayectos, especialmente con 0 % de swarming (lo que generó rutas de comunicación más largas). Por su parte, la VaNetLayer aseguró consistentemente tasas de entrega mucho mejores que la VNLayer y CarTorrent, evidenciando el impacto positivo de los mecanismos establecidos en esta tesis, que se esfuerzan por evitar las pérdidas de paquetes y así preservar la información que pasa a través de los nodos virtuales. Tiempos de descarga frente al nivel de swarming Teniendo en cuenta los mismos escenarios que los experimentos precedentes, la figura 5.8 muestra el tiempo promedio que tomó a los 16 vehículos elegidos al azar descargar completamente los D=1 MB de contenido. Como consecuencia de las buenas tasas de entrega de paquetes aseguradas por la VaNetLayer, nuestra solución garantiza los tiempos de descarga más cortos con 0 % de swarming y 50 % de swarming. El buen desempeño de la VaNetLayer seguía siendo notable con 100 % de swarming, pero en este caso CodeTorrent tuvo un mejor rendimiento, ya que tiene una velocidad impresionante con muchos vehículos en movimiento alrededor y descargando los mismos contenidos. Por el contrario, CodeTorrent estuvo muy a la zaga de los demás esquemas con 0 % enjambre (cada nodo solo podía obtener trozos en las inmediaciones de los puntos de acceso Wi-Fi) y nos dieron resultados promedio con el 50 % de swarming. Gracias a la posibilidad de explotar las comunicaciones multisalto, CarTorrent tuvo un desempeño ligeramente mejor que CodeTorrent con 0 % de swarming, mientras que las malas tasas de entrega de paquetes de la VNLayer incidieron fuertemente en el funcionamiento de TCP, causando grandes retrasos. En muchos casos, de hecho, TCP no pudo trabajar sobre las rutas multisalto y los vehículos solo fueron capaces de obtener los archivos completos desde la comunicación directa con los puntos de acceso Wi-Fi. 5.4 Soporte de la VaNetLayer al acceso individualizado a contenido web 149 Efecto del número de vehículos de soporte En los apartados anteriores, nos hemos centrado en escenarios con Sup=64 nodos que soportan los diferentes esquemas de comunicación, de los 128 vehículos que se movían alrededor de la zona simulada de la ciudad. En el conjunto de experimentos siguientes queremos analizar el impacto que tiene la variación en el número de vehículos sobre las métricas estudiadas anteriormente. Así, manteniendo el número de vehículos que desarrollan descargas simultáneas a Sim=16, el tamaño del archivo a descargar en D=1 MB y fijando el nivel de swarming a LoS=0.5, hicimos experimentos con Sup=32 y Sup=128, es decir, con la mitad y el doble de vehículos que ofrecen la posibilidad de comunicarse mediante el régimen en cuestión. En esos escenarios, obtuvimos la variación de la sobrecarga, las tasas de entrega de paquetes y los tiempos de descarga que se muestra en la figura 5.9. Las principales observaciones son las siguientes: Con más vehículos capaces de intercambiar mensajes, la sobrecarga de virtualización de la VNLayer y la VaNetLayer aumenta. Sin embargo, los nuevos mecanismos de la VaNetLayer hacen que la capa de red trabaje mucho mejor, así que la sobrecarga combinada de nuestra solución crece de una forma escalable, mientras que los resultados en términos de tasa de entrega de paquetes y los tiempos de descarga no se convierten en peores. En contraste, el esquema basado en la VNLayer original permanece como la solución más costosa, independientemente del número de nodos de soporte. CarTorrent aun produce significativamente menor sobrecarga que nuestra solución con 32 vehículos conectados, pero se enfrenta a problemas con un número mayor ya que la longitud promedio de las rutas multisalto establecidas por AODV se incrementa, y también lo hace la probabilidad de quiebre de los trayectos. Como resultado, el rendimiento de CarTorrent en términos de tasa de entrega de paquetes y tiempos de descarga empeoró significativamente con 128 vehículos conectados. Por último, la sobrecarga, la tasa de entrega de paquetes y los tiempos de descarga de CodeTorrent no se ven afectados notablemente por el parámetro Sup debido a las peculiaridades del encaminamiento basado en MAID-0. Efectos del número de descargas simultáneas Fijando Sup=64, D=1 MB y LoS=0.5, hicimos experimentos con un número variable de descargas simultáneas, considerando Sim ∈ { 1, 2, 4, 8, 16, 32, 64}. Las variaciones resultantes en la sobrecarga de tráfico de control, las tasas de entrega de paquetes y los tiempos de descarga se muestran en la figura 5.10. Las principales observaciones son las siguientes: Un mayor número de descargas simultáneas provoca un mayor número de operaciones de establecimiento y mantenimiento de rutas para VNAODV+; pero, de nuevo, los mecanismos establecidos en esta tesis para la VaNetLayer pueden acomodar la mayor carga de una manera más eficiente de lo que es posible con la VNLayer original, asegurando incrementos moderados de la sobrecarga de tráfico de control y reducciones en las tasas de entrega de paquetes menos 150 Descarga colaborativa de contenidos y acceso a Internet severas. Además, se observa que los tiempos de descarga empeoran significativamente para la VNlayer una vez que un cierto número de descargas simultáneas se ha superado (Sim=16) porque los líderes de las VNs comienzan a ser abrumados por la cantidad de tráfico de datos que pasa a través de sus regiones. Este efecto no se notó en la VaNetLayer debido al mecanismo que de coexistencia de dos o más líderes por región en caso que la carga de tráfico sea elevada (ver sección 4.2.4). Un mayor número de descargas simultáneas tiene un impacto significativo en la sobrecarga causada por CarTorrent, debido a las tormentas de broadcast y las reparaciones de rutas de AODV. Las tasas de entrega de paquetes empeoran en menor grado, mientras que los tiempos de descarga mejoran ligeramente debido al hecho de que hay vehículos descargando 12 MB de contenido común, cuyos trozos se pueden recuperar desde los vehículos cercanos en vez de atravesar rutas multisalto a los puntos de acceso Wi-Fi. Con CodeTorrent, tal como sucedió con el parámetro Sup en los apartados anteriores, encontramos que la sobrecarga de tráfico de control y las tasas de entrega de paquetes no cambiaron notablemente con el número de descargas simultáneas. En contraste, un número mayor implica la descarga mucho más rápida de los contenidos comunes, mientras que los contenidos individualizados todavía dependen del paso por los puntos de acceso Wi-Fi. Como resultado, nuestra solución ejecutándose sobre la VaNetLayer todavía logró mejores tiempos de descarga que CodeTorrent con el umbral ya mencionado de 32 descargas simultáneas. Efectos de la cantidad de datos a descargar Por último, manteniendo constante Sup=64, Sim= 16 y LoS=0.5, hicimos experimentos con diferentes cantidades de datos a descargar, desde D=1 MB a D=9 MB. En este caso, no notamos ningún impacto significativo en el rendimiento de CarTorrent y CodeTorrent (utilizan UDP en la capa de transporte) y sus tiempos de descarga aumentaron casi linealmente. Los esquemas soportados por nuestra VaNetLayer y la VNLayer original, por el contrario, están basadas en TCP, por lo que la presencia de archivos de mayor tamaño implica mayores probabilidades de problemas durante la explotación de las rutas multisalto. Sin embargo, los nuevos mecanismos de la VaNetLayer mejoraron la capacidad de recuperación de las comunicaciones también en este caso y el número de vehículos que se enfrentó a la ruptura de las conexiones TCP fue mucho menor que con la VNLayer original. La tabla 5.3 muestra el número medio de vehículos (fuera de los 16) que sufrieron al menos una interrupción de la conexión TCP en las simulaciones de los apartados anteriores frente a la variación de los valores de D. Sin embargo, vale la pena recordar que el impacto de estos quiebres se puede aliviar mediante la implementación de mecanismos en la capa de aplicación para gestionar las descargas parciales, como la mayoría de los navegadores web lo hacen. D 1 MB 3 MB 5 MB 7 MB 9 MB VNLayer VaNetLayer 3.4 0.7 5.8 1.4 6.6 2.6 11.3 4.4 14.1 5.4 Tabla 5.3: Número promedio de vehículos sufriendo al menos un quiebre en la conexión TCP con diferentes cantidades de datos a descargar. 5.4 Soporte de la VaNetLayer al acceso individualizado a contenido web 151 Sobrecarga (KB) 350 300 250 200 150 VNAODV/VNLayer VNAODV+/VaNetLayer CarTorrent CodeTorrent 100 50 0 Tasa de entrega (%) 32 128 1 0.95 0.9 0.85 0.8 0.75 0.7 0.65 0.6 VNAODV/VNLayer VNAODV+/VaNetLayer CarTorrent CodeTorrent 32 Tiempo de descarga (s) 64 64 128 60 50 40 30 20 VNAODV/VNLayer VNAODV+/VaNetLayer CarTorrent CodeTorrent 10 0 32 64 128 Figura 5.9: Variaciones de la sobrecarga de tráfico de control, las tasas de entrega de paquetes y los tiempos de descarga, frente a diferentes números de vehículos soportando cada uno el esquema de comunicación (50 % swarming). 152 Descarga colaborativa de contenidos y acceso a Internet Sobrecarga (KB) 350 300 250 200 150 VNAODV/VNLayer VNAODV+/VaNetLayer CarTorrent CodeTorrent 100 50 0 Tasa de entrega (%) 1 2 8 16 32 64 1 0.95 0.9 0.85 0.8 0.75 0.7 0.65 0.6 VNAODV/VNLayer VNAODV+/VaNetLayer CarTorrent CodeTorrent 1 Tiempo de descarga (s) 4 2 4 8 16 32 64 70 60 50 40 30 VNAODV/VNLayer VNAODV+/VaNetLayer CarTorrent CodeTorrent 20 10 0 1 2 4 8 16 32 64 Figura 5.10: Variación de la sobrecarga de control, las tasas de entrega de paquetes y los tiempos de descarga, frente a diferente número de descargas simultáneas (50 % de swarming). 5.4 Soporte de la VaNetLayer al acceso individualizado a contenido web 153 5.4.1. Discusión En esta sección hemos evaluado el rendimiento de la VaNetLayer para dar soporte al acceso a contenido web desde dentro de las VANETs a través de una solución que utiliza HTTP como es habitual y permitiendo, además, a TCP trabajar correctamente sobre VNAODV+. Nuestros experimentos demuestran que los nuevos mecanismos que hemos implementado en la VaNetLayer sirven para mejorar drásticamente el rendimiento de la VNLayer, lo que garantiza buenas tasas de entrega de paquetes (incluso con un número promedio de vehículos de soporte) gracias a la explotación efectiva de las comunicaciones multisalto. Los resultados de la simulación muestran que el esfuerzo invertido en el establecimiento y mantenimiento de la infraestructura de nodos virtuales realmente tiene efectos positivos y nuestra propuesta obtiene mejores tiempos de descarga que soluciones tipo Torrent en un conjunto de escenarios, sobre todo cuando hay una porción significativa de contenido individualizado —en efecto, las aceleraciones mostradas por las gráficas de la figura 5.9 y la figura 5.10 serían aún más evidente con 0 % de swarming, lo que está más en línea con las expectativas de los pronósticos para el acceso web dentro de las redes vehiculares (ver [3]). Además, nuestra propuesta escala bien con el número de nodos de soporte y con la cantidad de datos para descargar, resolviendo el problema de cuello de botella que se produce cuando el número de descargas simultáneas causa unas pocas decenas de trayectos de comunicación pasando por el mismo nodo virtual (como lo sucedido con la VNLayer con Sim=16), permitiendo la coexistencia de varios líderes por región (ver sección 4.2.4). Por tanto, llegamos a la conclusión de que nuestra propuesta puede ser una solución conveniente para el acceso web, mientras que el enfoque de CodeTorrent (o su evolución, V-Torrent) ofrece grandes ventajas para los servicios de difusión o multidifusión. Enfoques basados en la predicción de la movilidad como MobTorrent podrían no ser apropiadas para explotar largas rutas multisalto debido a la acumulación de los errores de predicción. Vale la pena señalar que nuestra propuesta permite obtener datos individualizados de Internet no solo a través de puntos de acceso Wi-Fi, sino también a través de conexiones 2G/3G/4G compartidas por los vehículos en movimiento. Esas conexiones pueden ser utilizadas por otros vehículos para sus descargas, mientras que en otras soluciones esas conexiones solo pueden servir para contenidos similares entre vehículos pertenecientes al grupo. Parte III Conclusiones 155 Capítulo 6 Conclusiones y futuros trabajos En este capítulo, se resumen las conclusiones de la tesis, enumerando las principales contribuciones desarrolladas al mejoramiento de la capa de virtualización para el despliegue de servicios de comunicación tanto en ambientes MANETs como VANETs y el diseño de nuevos mecanismos de encaminamiento. Seguidamente, se sugieren líneas de trabajo futuro como una continuación natural de esta tesis. 6.1. Conclusiones En esta tesis hemos desarrollado una serie de mejoras y nuevos mecanismos a la capa de virtualización VNLayer que incrementan significativamente su rendimiento para soportar servicios de comunicación más demandantes en entornos pedestres, vehiculares y mixtos; convirtiendo a las redes móviles ad-hoc en entornos de comunicación más fiables de lo que era posible con la VNLayer orginal. Nuestras contribuciones se centran en la capa de virtualización y en la capa de red, tanto en entornos MANET como VANET. 6.1.1. Contribuciones en entornos MANET El análisis inicial que desarrollamos acerca del rendimiento de los mecanismos empleados por la VNLayer frente a escenarios de mayor movilidad y con servicios más demandantes que los inicialmente estudiados por sus autores [241] en ambientes MANETs, nos permitió determinar varias fuentes de ineficiencia que derivaron en un pobre rendimiento. En respuesta, diseñamos e implementamos varios mecanismos alternativos que mejoran significativamente el rendimiento de la VNLayer: Disposición de los VNs acorde a la aplicación. La disposición estática de los VNs cubriendo regiones de igual tamaño y forma descuida la presencia de obstáculos y las condiciones adversas para la propagación de las señales de radio. Nuestra versión mejorada de la capa de virtualización para entornos MANET (VNLayer+) deja en manos de los diseñadores de las aplicaciones la localización y definición de los VNs, para aprovechar su conocimiento acerca de las áreas en la que los usuarios se moverán y los recursos desplegados sobre ellas. Con este mecanismo es posible ir más allá de las regiones que son iguales en tamaño y 157 158 Conclusiones y futuros trabajos forma, habilitando comunicaciones entre ambientes en el interior y exterior de los edificios. Un nuevo proceso de elección de líder. El proceso de elección de líder a través de la máquina de estados propuesta en [240] genera una reacción lenta de los nodos frente a la salida del líder, lo cual es un problema en entornos de mayor movilidad y con aplicaciones más demandantes, debido a los tiempos —nada insignificantes— en los que la región se queda sin servicio. La VNLayer+ establece un nuevo proceso de elección de líder eliminando varios estados y reorganizando las transiciones entre los estados restantes, mejorando los tiempos de reacción y recuperación de los nodos virtuales ante fallos o salidas de los líderes. De igual forma, establecimos los tiempos de espera de los nodos para solicitar el liderazgo de acuerdo a su estatus (backup sincronizado, no sincronizado, o nodo no-líder) para asegurar que el mejor candidato sea escogido como líder; es más, se da prioridades a los backups sincronizados de manera que el de máxima prioridad puede cambiar inmediatamente su estado de NON-LEADER a LEADER evitando completamente el tiempo de espera para el levantamiento del VN. Por otra parte, introducimos un nuevo estado que permite a los líderes renunciar a su rol en el caso de que hayan soportado durante mucho tiempo el liderazgo de la región o la carga de batería esté aproximándose a un nivel bajo. De esta forma, los nodos pueden turnarse y actuar como líderes en forma colaborativa. Manejo del liderazgo duplicado. No obstante, el nuevo proceso de elección de líder produce una mayor cantidad de liderazgos duplicados, debido a la eliminación de algunos estados para obtener una reacción más rápida de los nodos ante la salida de los líderes o fallos en el VN. El mecanismo implementado en la VNLayer original para enfrentar estos problemas no garantiza qué líder se impondrá, pudiéndose dar el caso en el que un nodo recién llegado a la región expulse a un líder de larga data con una gran cantidad de datos valiosos. Para evitar esta situación, hemos introducido un nuevo campo en el mensaje M_Heartbeat denominado Since para indicar desde cuándo el nodo pasó al estado LEADER, permitiendo al líder más antiguo mantenerse en el liderazgo. Un nuevo enfoque para la designación de los nodos backup. La VNLayer designa sus nodos backup en forma probabilística por lo que siempre existirá la posibilidad de que ningún nodo no-líder escoja trabajar como backup o, por el contrario, tener una gran cantidad de estos nodos en la región, ambos casos perjudiciales para el rendimiento del VN. Para evitar esta situación, en nuestro enfoque, el líder periódicamente informa el número de backups presentes en la región para que los nodos no-líderes puedan decidir si se ofrecen o no como nuevos backups, siempre que el número de estos nodos esté por debajo de un valor determinado. A cada backup se le asigna un nivel de prioridad, lo que disminuye sus tiempos de espera en la elección del líder. Estos valores son almacenados en una tabla B_table, que es mantenida por todos los nodos en el VN. Cuando un backup abandona la región, difunde un mensaje anunciando su salida. Esto permite que los backups por debajo de su nivel de prioridad incrementen este valor en uno y que los nodos no-líderes compitan para tomar su lugar, garantizando así (siempre que se pueda) la existencia de un número adecuado de estos nodos en el VN. 6.1 Conclusiones 159 Mantenimiento de la información de estado para sincronizar nodos advenedizos. En el caso de que un nodo recién llegado asuma el liderazgo de la región superando a los backups sincronizados presentes en ella que no recibieron el M_LeaderLeft, la VNLayer+ (a diferencia de la VNLayer que no realiza ninguna acción en estos casos) introduce un nuevo proceso de sincronización que permite al nodo backup de mayor prioridad pasar la información de estado que almacena al nuevo líder. De esta forma, este nodo pueda iniciar su trabajo tal como el líder precedente en un tiempo muy corto. Gestión de las regiones vecinas a través de instantáneas de su estado. Un aspecto crítico es el hecho de que la VNLayer no desarrolla ningún intento por preservar la información de estado de las regiones que quedan sin el soporte de nodos físicos, lo que hace que toda esa información se pierda. La VNLayer+, por el contrario, implementa un nuevo mecanismo de sincronización que permite al nodo líder saliente pasar una instantánea de su estado al líder de la región vecina a la que ingresa. De esta forma, el líder vecino brindará el soporte necesario a la región vacía o en la cual el nuevo nodo líder parece no comportarse de una manera coherente. Un cambio adicional en la interfaz a la capa de red. Hemos implementado dos funciones a la interfaz a la capa de red para permitir que sean las aplicaciones quienes escojan el modo de transmisión de datos: unicast o broadcast. Nuestra experiencia con VNAODV ha demostrado que dejar la elección a la VNLayer no proporciona ninguna ventaja sino que más bien hace las cosas más complicadas e ineficientes. Nuestras contribuciones a la capa de red, a su vez, incluyen las adaptaciones necesarias de la versión virtualizada de AODV (VNAODV) para aprovechar las nuevas características de la VNLayer+, y nuevos mecanismos para actualizar las rutas multisalto en respuesta al cambio de región de los nodos fuente, destinos y nodos líderes intermedios. Los objetivos perseguidos con estas mejoras e innovaciones son (i) evitar el uso excesivo de broadcast, (ii) refinar el procedimiento de corrección de ruta propuesto en [241] para evitar la pérdida de algunos paquetes e (iii) implementar un nuevo mecanismo para evitar la ruptura de los enlaces cuando los nodos líderes intermedios en la ruta fuente-destino abandonan sus regiones. Nuestras contribuciones al respecto son las siguientes: Retorno a los esquemas de transmisión de AODV. El hecho de que VNAODV transmita los paquetes de control y datos vía broadcast genera una fuente importante de problemas ya que este mecanismo tiene una reacción lenta en las acciones de corrección de ruta, debido al uso de acuses de recibo pasivo para detectar fallos en los enlaces, lo que limita su capacidad para seguir el movimiento de los nodos. Para resolver este inconveniente, gracias a las modificaciones en la interfaz de red que hemos implementado en VNLayer+, nuestra versión mejorada VNAODV+ permite que los paquetes de control RREP, RERR y los paquetes de datos sean transmitidos a través de unicast entre líderes de los VNs, tal como en el caso de AODV. De igual forma, para mantener la capacidad de sincronización de los nodos backups, configuramos la capa de enlace en modo promiscuo de modo que se maneje todos los paquetes del medio compartido para la VNLayer+, que a su vez los envía hacia la capa de red. De esta forma, VNAODV+ está menos expuesto a las colisiones que VNAODV, puede manejar notificaciones 160 Conclusiones y futuros trabajos desde la capa de enlace para detectar roturas de enlace más rápido y, finalmente, se libera de la carga computacional de mantener el seguimiento de los acuses de recibo. Un nuevo proceso de correción de ruta. El cambio de los esquemas de transmisión, tal como se indica en el item anterior, genera un problema de pérdida de paquetes en el procedimiento de corrección de ruta en el nodo destino definida por Wu et al., dado que las entradas de las tablas de encaminamiento obtienen nuevos next_hop antes que las direcciones MAC de los nodos correspondientes sean actualizadas, existiendo la posibilidad de un desbordamiento de los buffers en rutas de alto tráfico. En respuesta, modificamos las comunicaciones de manera tal que cuando el nodo destino detecta un error en la ruta difunde un RREQ con TTL=1 como si estuviere buscando una nueva trayecto al origen e intercambia mensajes RREP por unicast con los VNs vecinos con un ruta válida. Esto permite que las tablas de actividad de región contengan el mapeo IP-MAC necesario para utilizar las rutas renovadas sin demora. Un procedimiento de soft handoff. Finalmente, desarrollamos un nuevo procedimiento de corrección de ruta en los nodos intermedios, denominado soft handoff. Este mecanismo permite mantener el enlace activo entre los VNs intermedios en una ruta fuente-destino cuando un líder abandona la región y un nuevo nodo asume su rol. Los líderes salientes mantendrán el reenvío de los paquetes que contienen su dirección IP pero que son dirigidos a la región anterior. Para la corrección de ruta se realiza el mismo intercambio de paquetes de control (un RREQ y dos RREP) que en el caso de la corrección desarrollada por el nodo destino. Además, gracias al mecanismo de instantáneas de la información de estado, el procedimiento de soft handoff puede mantener el enlace activo cuando la región queda vacía, e iniciar los procesos de reporte y reparación de las rutas de inmediato. De esta forma, se puede prevenir la ruptura de los enlaces y la pérdida de paquetes. Nuestros experimentos de simulación desarrollados en un escenario de distribución de contenidos P2P demuestran que los mecanismos implementados en nuestra VNLayer+ convierten a las redes ad-hoc en entornos de comunicación más rápidos y fiables de lo que era posible con la VNLayer original. Las nuevas características de la capa de virtualización y los nuevos mecanismos implementados en VNAODV+ le permite obtener un mayor rendimiento que VNAODV y algunos protocolos como AODV, OSLR y ARA, en métricas como la tasa de entrega de paquetes y goodput. 6.1.2. Contribuciones en entornos VANET Los resultados obtenidos en la evaluación de la capa virtual en escenarios MANET, nos llevó a la pregunta de si los constructos de la VNLayer podría también dar mejores comunicaciones en el campo más específico (y demandante) de las VANETs. Para analizar esta posibilidad, diseñamos varios experimentos de simulación en entornos vehiculares a través de un ambiente de simulación que desarrollamos para este propósito. Los resultados de esos experimentos nos arrojaron varios problemas en la VNLayer. Esta problemática está relacionada con las características que trabajaron bien en ambientes MANET pero que se convierten en ineficientes frente a los modelos de movilidad de las VANETs, los cuales cuentan con movimientos relativos más rápidos 6.1 Conclusiones 161 y condicionados por factores como el curso de la vía, la planificación urbana, los reglamentos de tránsito, etc. Frente a esto, diseñamos, implementamos y probamos un número de refinamientos a la capa virtual que alcanza un mejor rendimiento en ambientes vehiculares. Nuestras contribuciones tienen que ver con los siguientes puntos: Un arreglo más vinculado al trazado para los VNs. Las características propias de los escenarios de las redes de comunicación vehiculares, con calles y edificios dentro de las zonas de cobertura de los VNs, hacen que la disposición reticular de la VNLayer original no sea adecuada. Esta disposición de los nodos virtuales compromete el supuesto de que dentro de una misma región los PNs pueden comunicarse directamente entre sí y que sus transmisiones pueden ser escuchadas por los PNs de la regiones vecinas. La versión mejorada de la VNLayer para entornos vehiculares (VaNetLayer) introduce un nuevo enfoque para cubrir el plano de las calles, alejándose de las regiones de igual tamaño y forma. Para ello, sigue un procedimiento iterativo que permite a los PNs determinar localmente las posiciones, formas, tamaños e identificadores de las regiones con poco coste computacional. Este mecanismo nos permite reducir los problemas debidos a obstáculos, adaptando la disposición de los VNs al mapa de las calles. Mejoras al procedimiento para la elección de líder. La mayor velocidad de los nodos físicos en la redes VANETs requiere un proceso de elección de líder más ágil. A más de los cambios desarrollados en la VNLayer+, añadimos un nuevo estado denominado INTERIM que permite iniciar el proceso de elección de líder antes de que el líder actual abandone la región. Hasta que otro nodo reclame el liderazgo mediante el procedimiento normal, el líder renunciante mantendrá el reenvío de paquetes y contestará los pedidos de sincronización desde el estado INTERIM. De esta forma, la VaNetLayer aumenta significativamente la probabilidad de que haya algún nodo en el liderazgo del VN siempre que exista PNs en la región y evita, a su vez, que el nodo virtual quede sin servicio por al menos dos periodos de T_Heartbeat debido a la pérdida de los mensajes M_LeaderLeft. Un mayor soporte de los backups al trabajo del líder. La VaNetLayer modifica el comportamiento de los backups —que en la VNLayer original actuaban como simples reemplazos rápidos del líder— de manera que reenvíen los paquetes que su líder pudo haber perdido. De esta forma los nodos backup dan un mayor soporte al trabajo de reenvío de paquetes del líder, reforzando los enlaces entre los VNs vecinos. Soporte de varios líderes por región. La VaNetLayer implementa un mecanismo que permite la coexistencia de varios líderes en una región, de manera que se puedan superar los posibles cuellos de botella producidos por la presencia de un solo líder en escenarios de alto tráfico. En el mismo campo de las VANETs, uno de los mecanismos usados para reducir la sensibilidad de los trayectos a los movimientos individuales de los vehículos ha sido el uso de algoritmos de encaminamiento basado en el reenvío geográfico. Revisando estas ideas diseñamos e implementamos un nuevo algoritmo de encaminamiento llamado VNIBR que basa su operación en las ventajas proporcionadas por la capa de virtualización, desacoplando la lógica de encaminamiento de las identidades de otros nodos diferentes de los nodos fuente y destino. Este protocolo es una combinación efectiva de encaminamiento topológico y geográfico, con trayectos basados en las calles que unen 162 Conclusiones y futuros trabajos intersecciones sucesivas que conectan a fuentes y destinos. Su funcionamiento se basa en tres ideas principales: (i) direccionamiento de los nodos por sus IPs, (ii) toma de decisiones de encaminamiento en las intersecciones y (iii) reenvío de paquetes de una intersección a otra de forma geográfica. Para analizar el rendimiento de nuestras propuestas desarrollamos varios experimentos con escenarios relacionados a la descarga colaborativa y compartición P2P de contenido. Las principales conclusiones son detalladas a continuación. Los resultados de los experimentos de simulación desarrollados demuestran que los nuevos mecanismos que hemos introducido con la VaNetLayer sirven para aplicar con éxito los conceptos de la virtualización en las VANETs, proporcionando una mejor respuesta del algoritmo VNAODV de lo que se obtiene ejecutándose sobre la VNLayer original. Nuestro análisis en el soporte de una aplicación de descarga colaborativa de contenidos y acceso a Internet muestran que la VaNetLayer permite a VNAODV+ superar a otros protocolos de encaminamiento, incluidos muestras de cluster pasivo, encaminamiento geográfico y de difusión de información asistida por movilidad. De igual forma, nuestras simulaciones muestran que los esfuerzos invertidos en el establecimiento y mantenimiento de la infraestructura de nodos virtuales genera efectos positivos al permitir que nuestra propuesta de descarga individualizada de información desde Internet presente mejores resultados en los tiempos de descarga que soluciones tipo Torrent en un conjunto de escenarios, lo que demuestra la capacidad de la VaNetLayer para permitir un apropiado funcionamiento de TCP ejecutándose sobre VNAODV+ en estos entornos. Por otra parte, las simulaciones realizadas con VNIBR confirmaron que nuestro algoritmo presenta un mejor rendimiento que algunas muestras de protocolos de encaminamiento topológico, geográfico y basado en intersecciones, esto gracias al aprovechamiento de las ventajas que la VaNetLayer ofrece en el manejo de la movilidad de los nodos y en la capacidad del algoritmo de tomar las decisiones de encaminamiento en las intersecciones lo que significa una menor sobrecarga de tráfico de control, un reenvío de paquetes más rápido y un menor número de puntos de fallo a lo largo de las rutas. De esta forma, los resultados de los diferentes experimentos de simulación desarrollados a lo largo de este trabajo doctoral nos permiten llegar a la conclusión de que las mejoras y nuevos mecanismos introducidos en la capa de virtualización convierten a las redes multisalto ad-hoc en entornos de comunicación más fiables, no solo para mejorar el funcionamiento de algoritmos y protocolos previos (como en el caso de VNAODV) sino para soportar nuevos servicios de comunicaciones en ambientes pedestres, vehiculares y mixtos. 6.2. Líneas de trabajo futuro Entre las posibles líneas de trabajo futuro que se derivan de esta tesis podemos destacar las siguientes: Aplicación de VNIBR a la descarga y compartición P2P de contenido. Debido a que los experimentos presentados en el capítulo 5 fueron anteriores al diseño y evaluación de nuestro protocolo de encaminamiento VNIBR, un trabajo 6.2 Líneas de trabajo futuro 163 pendiente por desarrollar es el análisis de la capacidad de VNIBR ejecutándose sobre la VaNetLayer para dar soporte a esa clase de aplicaciones. QoS en redes vehiculares. La estructura colaborativa de los nodos virtuales puede ser aprovechada para proporcionar calidad de servicio a las comunicaciones desarrollándose sobre la capa virtual. Por ejemplo, en las redes vehiculares, ampliando nuestro estudio del protocolo VNIBR, los nodos virtuales en las intersecciones pueden mantener información de la QoS prevista en los segmentos de vía que gestionan, la cual puede ser calculada a partir de los reportes periódicos enviados por los VNs en el interior del segmento. De esta forma, los nodos virtuales en las intersecciones podrán admitir o no nuevas comunicaciones, reservando los recursos requeridos y redirigiendo las solicitudes de ruta solo a través de los segmentos de vía con capacidad para soportar esas comunicaciones. Además, las correcciones de ruta pueden ser desarrolladas a medida que las condiciones de calidad se vayan degradando. De igual forma, estos reportes, junto con la información histórica del tránsito, los sistemas de información de tránsito en tiempo real y la promoción de los sistemas de compartición de vehículos, pueden ser aprovechados para desplegar una plataforma virtual de comunicaciones en la que los servicios sean ofrecidos por segmentos de vía acorde a las condiciones de calidad esperadas. Nuestros trabajos preliminares pueden ser encontrados en [36–38]. Geocasting en VANETs. Aprovechando la división natural de la capa de virtualización en regiones, un tema de interés es el soporte de geocasting (ver sección 2.2.6). Para ello, se puede asignar a cada nodo virtual una dirección geográfica que lo identifique. En el proceso de encaminamiento de los paquetes hacia la región deseada (cubierta por un VN determinado) varios mecanismos pueden ser probados. Por ejemplo, podemos usar paquetes RREQ, difundidos desde el nodo fuente, para descubrir la ruta a la zona deseada. Estos paquetes pueden ser transmitidos de intersección a intersección hasta alcanzar la región destino. El nodo líder del VN destino enviará un paquete RREP a la fuente a través de la ruta descubierta para que inicie la transmisión de los datos. Gracias a que la difusión de los mensajes de control se desarrolla únicamente entre nodos líderes, la cantidad de sobrecarga de tráfico puede ser disminuida. Otra aproximación puede ser un enfoque geográfico puro, los paquetes de datos son enviados directamente sin necesidad de establecer previamente la ruta. En los segmentos de vía, los paquetes son retransmitidos en forma geográfica hasta alcanzar la intersección en donde son encaminados basados en la información de la conectividad observada en los segmentos de vía bajo su gestión y la localización geográfica del nodo virtual deseado. El paquete de datos es redirigido a la próxima intersección más cercana al VN de la zona de geocasting deseada, con la mejora conectividad posible. Vehicular Cloud Networking. Como se analizó en la sección 1.2 en un futuro cercano, cada vehículo estará equipado con dispositivos de comunicación, computación y de monitorización, lo que permitirá el intercambio de paquetes con los vehículos alrededor y con la infraestructura en las vías. Esas nuevas capacidades junto con el incremento de la accesibilidad inalámbrica a Internet desde los vehículos han impulsado la investigación en el área de la Sistemas de Transporte Inteligente con una serie de enfoques para el intercambio de datos 164 Conclusiones y futuros trabajos -+.# *+,# !"#$%& !'"()*'+(,& !"""#$%&'(()# Figura 6.1: La pila de protocolos de nuestra propuesta de VCN sobre la VaNetLayer. en redes ad-hoc V2V y con servidores localizados en Internet a través de comunicaciones Wi-Fi con puntos de acceso en la infraestructura o redes celulares (V2I). Sin embargo, es evidente que los recursos disponibles en los vehículos son generalmente subutilizados. Así, este escenario está allanando el camino para el desarrollo de nuevos paradigmas para aprovechar los ricos recursos de los vehículos modernos, la creación de plataformas virtuales en la que los vehículos colaboren y compartan sus recursos para apoyar el despliegue de nuevos y más exigentes servicios [244]. Una de esas aproximaciones fue presentada en [126], donde los autores introducen un nuevo modelo de computación y configuración de redes denominado Vehicular Cloud Networking (VCN). Este modelo integra la computación en nube vehicular (VCC, del inglés Vehicular Cloud Networking) [82] y las redes centradas en la información (ICN, del inglés Information Centric Networking ) [7]. La idea es usar los recursos disponibles en los vehículos y la infraestructura en las vías para que operen como una plataforma virtual común sobre la cual poder desplegar servicios de comunicación avanzados. En ese contexto, la VCN puede ser soportada en forma natural y fiable por la VaNetLayer. En la figura 6.1 se muestra una primera propuesta de la pila de protocolos requerida para soportar la VCN. La VaNetLayer maneja conceptos que fácilmente pueden ser usados por la lógica de VCN. El intercambio de los mensajes entre los vehículos es llevado a cabo por VNIBR en la capa de red y TCP en la capa de transporte. En la parte inferior de la pila, las capas física y MAC son provistas por IEEE 802.11p. Nuestra propuesta se orienta a crear una plataforma virtual para estructurar y organizar el trabajo de los vehículos que están dentro de una determinada región, de manera tal que colaboren para llevar a cabo las tareas, compartir recursos y mantener la estructura virtual; todo esto de una manera transparente para el usuario. Sobre esta plataforma de nodos virtuales, los diferentes procesos de coordinación se realizan con el fin de estructurar una nube de nodos virtuales. En esta estructura, las tareas son asignadas por nodo virtual más que por vehículos individuales. Los principales procesos serían los siguientes: • Descubrimiento de recursos y formación de la nube. El nodo que requiera formar una nube, envía un mensaje a los nodos virtuales en el segmento de vía donde se encuentra para recolectar información de los recursos disponibles, luego de ello intercambia mensajes con los VNs escogidos para formar la nube y reservar los recursos. 6.2 Líneas de trabajo futuro 165 • Asignación de tareas y recolección de resultados. En base a la información recolectada sobre la capacidad de los VNs seleccionados, las tareas son divididas por el nodo generador de la nube y enviados a los líderes de los VNs seleccionados. Cada líder, a su vez, subdivide las tareas de acuerdo a las capacidades de los nodos físicos presentes en su región; dependiendo de la tarea asignada, los resultados son enviados por el nodo líder del VN al nodo solicitante o mantenidos en la región para ser usados por otros usuarios. • Mantenimiento y disolución de la nube. Gracias a los procesos desarrollados por la VaNetLayer, la estructura de los nodos virtuales (nodo líder, backups y los nodos no líderes) es soportada en forma transparente a las aplicaciones. Así, cuando un nodo líder sale de la región, el nuevo líder asumirá las tareas dejadas por su predecesor; de igual forma, si la región se convierte en vacía, los VNs vecinos apoyarán al VN caído hasta que se restablezca. De esta forma, la estructura de la nube no sufre cambios importantes gracias al soporte brindado por la VaNetLayer. Sin embargo, si un nodo virtual no puede permanecer dentro de la nube, comunica de este hecho al nodo de aplicación de modo que seleccione otro VN para asumir sus tareas. Nuestro diseño crea nubes que cubren el tramo de la calle entre dos intersecciones. Por lo tanto, dependiendo de la tarea ejecutándose, cuando el nodo de aplicación no utiliza la nube o abandona el espacio cubierto por la misma, los recursos de la nube son liberados para que puedan ser utilizados por otros dispositivos. Para ello, el nodo de aplicación envía un mensaje de liberación de la nube a todos los miembros. Nuestras propuestas preliminares en esta área pueden ser encontradas en [40, 180]. Redes sociales esporádicas. Los mecanismos propuestos en esta tesis para la generación de la VNLayer+ y la VaNetLayer, junto con los protocolos de encaminamiento virtualizados VNAODV+ y VNIBR brindan el soporte necesario para profundizar y ampliar la visión de las redes sociales esporádicas. Nuestras propuestas dan pie para avanzar hacia el desarrollo de SPORANGIUM (ver sección 1.5) como una plataforma que se adapta dinámicamente al contexto en el que el usuario se mueve (pedestre, vehicular, mixto, en el interior o exterior de los edificios) y que actúa proactivamente para establecer redes sociales esporádicas de acuerdo a los diferentes perfiles, gustos y necesidades de los usuarios. En ese sentido, se abren múltiples lineas de trabajo futuro para continuar con el desarrollo de las siguientes capas de esta plataforma. Algunas ideas en esta línea fueron incluidas en [35, 39, 146, 180]. Descubrimiento proactivo de viajes compartidos en VANETs. El aumento de los costes y los persistentes problemas del tránsito vehicular hacen necesario el desarrollo de soluciones asequibles y flexibles para la gestión de la movilidad de las personas. En la actualidad, muchos organismos gubernamentales de diversos países promueven iniciativas de compartición de viajes (también conocido como carpooling) para luchar contra los problemas de sus redes de transporte. Estos mecanismos también han cobrado impulso en la comunidad científica en los últimos años [5, 64, 80, 238], donde los investigadores han propuesto iniciativas que 166 Conclusiones y futuros trabajos requieren (i) a los conductores introducir explícitamente información acerca de los viajes que van a realizar (básicamente, origen, destino, ruta, fecha y hora), y (ii) los potenciales pasajeros para hacer búsquedas, expresando sus necesidades de movilidad junto con criterios de proximidad espacio-temporales. Después de descubrir una posibilidad para hacer un viaje compartido, las dos partes se ponen en contacto para acordar los detalles del viaje. En la fecha y la hora establecida, conductor y acompañante se encuentran y comparten el vehículo según lo acordado. Una nueva línea de trabajo futuro derivada de esta tesis se orienta a explorar las características de mayor fiabilidad y robustez de la VaNetLayer para ofrecer nuevas oportunidades de compartición de viajes, dirigido al descubrimiento proactivo de los trayectos que los usuarios hacen frecuentemente y la selección automática de los conductores para esas rutas. Para ello, nuestro enfoque establecería redes esporádicas entre las personas que están físicamente cerca unas de otras en un momento determinado, mediante el apoyo a las conexiones ad-hoc entre sus dispositivos móviles. Es decir, desplegaríamos una red vehicular adhoc inteligente (smart VANET) sobre los vehículos cercanos en la vía con el fin de intercambiar entre los vehículos la información necesaria para (i) emparejar los itinerarios de los usuarios y sus preferencias particulares y (ii) la identificación de los conductores potencialmente semejantes, interesados en compartir el vehículo a lo largo de rutas comunes. Se puede explotar el hecho de que existen muchas zonas de tránsito pesado que reúnen a un gran número de personas cada día en determinados momentos (por ejemplo, cuando comienzan o acaban los días de trabajo en las horas pico, al dejar o recoger a los niños en la escuela, o asistir a las actividades de ocio durante los fines de semana...). Esta situación convierte a las VANETs en entornos propicios para identificar proactivamente oportunidades de compartición de viajes. La provisión de estas funcionalidades requiere mecanismos para asegurar que la VANET es un entorno de comunicación confiable, donde la piedra angular son las conexiones ad-hoc multisalto establecidas entre terminales móviles de los usuarios. Además, teniendo en cuenta las restricciones computacionales de estos terminales de mano, nuestro enfoque también necesita esquemas destinados a repartir entre los nodos (vehículos) de la VANET las tareas y los cálculos necesarios en la organización de los viajes compartidos. De esta forma, gracias a las ventajas ofrecidas por la VaNetLayer, podemos explorar el desarrollo de servicios de información complejos que permanecieron inexplorados hasta ahora en el ámbito de las redes ad-hoc (sin ninguna infraestructura preestablecida). Una primera propuesta para la arquitectura de esta plataforma de compartición de viajes se representa en la figura 6.2. Podemos ver que la base es una smart VANET que se implementa a través de los dispositivos de mano de los usuarios en las vías (soportada por la VaNetLayer que trabaja en conjunto con el protocolo de encaminamiento VNIBR). Su potencial se explota para identificar a los usuarios cercanos con preferencias similares cuyas necesidades de movilidad encajan con las rutas atravesadas a menudo por un determinado usuario. Las condiciones finales del viaje compartido (por ejemplo, punto de encuentro, precio, tiempo...) pueden ser discutidas a través de un sistema PBX que permite a los conductores ponerse en contacto unos con otros. Esta información es registrada por un sistema gestor de la smart VANET, que mantiene una cuenta para cada usuario para almacenar datos personales, cuenta bancaria o datos de la tarjeta de crédito (con 6.2 Líneas de trabajo futuro 167 Figura 6.2: Principales elementos de nuestra plataforma de compartición de viajes sobre una smart VANET. el fin de cobrar o pagar por la realización de los viajes compartidos), junto con la información de contacto (como números de teléfonos móviles y direcciones de correo electrónico). Parte IV Apéndices 169 Apéndice A Publicaciones derivadas de la tesis En este apéndice se enumeran las publicaciones que se han derivado del trabajo desarrollado en esta tesis. A.1. Publicaciones en revistas internacionales A.1.1. Publicaciones aceptadas BRAVO TORRES, J. F., LÓPEZ NORES, M., BLANCO FERNÁNDEZ, Y., PAZOS ARIAS, J., y ORDOÑEZ MORALES, E. F. VaNetLayer: A Virtualization Layer Supporting Access to Web Contents from within Vehicular Networks. En Journal of Computational Science (2015). BRAVO TORRES, J. F., LÓPEZ NORES, M., BLANCO FERNÁNDEZ, Y., PAZOS ARIAS, J., RAMOS CABRER, M., y GIL SOLLA, A. An Improved Virtualization Layer to Support Distribution of Multimedia Contents in Pervasive Social Applications. En Journal of Network and Computer Applications (2015). BRAVO TORRES, J. F., LÓPEZ NORES, M., BLANCO FERNÁNDEZ, Y., PAZOS ARIAS, J., RAMOS CABRER, M., y GIL SOLLA, A. Optimising reactive routing over virtual nodes in VANETs. En IEEE Transactions on Vehicular Technology (2015). BRAVO TORRES, J. F., LÓPEZ NORES, M., y BLANCO FERNÁNDEZ, Y. Virtualization Support for Complex Communications in Vehicular Ad Hoc Networks. En MTA Review (2013). PERNEL, I., UDDIN, M. A., y BRAVO TORRES, J. F. HotMobile 2012. En IEEE Pervasive Computing (2012), pág 84–87. (Reseña breve resultante de la participación en el doctoral consortium). 171 172 Publicaciones derivadas de la tesis A.1.2. Artículos en proceso de revisión BRAVO TORRES, J. F., LÓPEZ NORES, M., BLANCO FERNÁNDEZ, Y., PAZOS ARIAS, J., y SAIÁNS VÁZQUEZ, J. V. Intersection-based routing in VANETs on top of a virtualization layer. En EURASIP Journal on Wireless Communications and Networking. BRAVO TORRES, J. F., BLANCO FERNÁNDEZ, Y., LÓPEZ NORES, M., PAZOS ARIAS, J., RAMOS CABRER, M., y GIL SOLLA, A. Proactive discovery and management of ride-sharing opportunities in smart vehicular ad-hoc networks. En Information Technology and Control. A.2. Publicaciones en conferencias internacionales A.2.1. Publicaciones aceptadas BRAVO TORRES, J. F., LÓPEZ NORES, M., BLANCO FERNÁNDEZ, Y., SERVIA RODRÍGUEZ, S., y GARCIA DUQUE, J. A virtualization layer for mobile consumer devices to support demanding communication services in vehicular ad-hoc networks. En Consumer Electronics (ICCE), 2012 IEEE International Conference on (enero 2012), pág. 225–226. Special Merit Award for Outstanding Paper. Las Vegas, USA : IEEE. BRAVO TORRES, J. F., LÓPEZ NORES, M., y BLANCO FERNÁNDEZ, Y. Supporting More Efficient Communications in Vehicular Ad Hoc Networks with New Constructs Based on a Virtualization Layer. En sesión de póster de HotMobile(febrero 2012). San Diego, USA. BRAVO TORRES, J. F., LÓPEZ NORES, M., BLANCO FERNÁNDEZ, Y., y PAZOS ARIAS, J. On the Use of Virtual Mobile Nodes with Real-World Considerations in Vehicular Ad Hoc Networks. En 9th International Conference on Communications (junio 2012). Bucharest, Rumanía : IEEE, pág. 193-196. BRAVO TORRES, J. F., LÓPEZ NORES, M., BLANCO FERNÁNDEZ, Y., y PAZOS ARIAS, J. Virtual virtual circuits: One step beyond virtual mobile nodes in vehicular ad-hoc networks. En Vehicular Technology Conference (septiembre 2012), Quebec, Canadá : IEEE , pág. 1-2. BRAVO TORRES, J. F., LÓPEZ NORES, M., y BLANCO FERNÁNDEZ, Y. Experiences with virtual mobile nodes that do move in vehicular ad hoc networks. En 3th International Conference on the Network of the Future (noviembre 2012), Túnez : IEEE. LÓPEZ NORES, M., BRAVO TORRES, J. F., BLANCO FERNÁNDEZ, Y., y PAZOS ARIAS, J. SPORANGIUM: A platform to support sporadic social networks based on ad-hoc communications and mobile cloud computing —Shortlived virtual networked organizations in venues, on the road and in the smart city. En 2nd International Conference on Virtual and Networked Organizations Emergent Technologies and Tools (noviembre 2013). Póvoa de Varzim, Portugal. A.2 Publicaciones en conferencias internacionales 173 BRAVO TORRES, J. F., LÓPEZ NORES, M., BLANCO FERNÁNDEZ, Y., y PAZOS ARIAS, J. En 2nd International Conference on Future Generation Communication Technologies (noviembre 2013). Londres, UK : IEEE Computer Society. BRAVO TORRES, J. F., LÓPEZ NORES, M., BLANCO FERNÁNDEZ, Y., PAZOS ARIAS, J., y ORDOÑEZ MORALES, E. F. Leveraging ad-hoc networking and mobile cloud computing to exploit short-lived relationships among users on the move. En International Conference on Intelligent Cloud Computing (febrero 2014). Muscat, Oman : Springer-Verlag. BRAVO TORRES, J. F., ORDOÑEZ MORALES, E. F., LÓPEZ NORES, M., BLANCO FERNÁNDEZ, Y., y PAZOS ARIAS, J. Virtualization in VANETs to Support the Vehicular Cloud: Experiments with the Network as a Service model. En 3rd International Conference on Future Generation Communication Technologies (agosto 2014). Luton, UK : IEEE. BRAVO TORRES, J. F., LÓPEZ NORES, M., BLANCO FERNÁNDEZ, Y., PAZOS ARIAS, J., y ORDOÑEZ MORALES, E. F. VaNetLayer: A Virtualization Layer Supporting Access to Web Contents from within Vehicular Networks. En International Conference on Internet of Vehicles (septiembre 2014). Beijing, China. BRAVO TORRES, J. F., LÓPEZ NORES, M., BLANCO FERNÁNDEZ, Y., PAZOS ARIAS, J., y ORDOÑEZ MORALES, E. F. A Platform to Exploit ShortLived Relationships among Mobile Users: A Case of Collective Immersive Learning. En Dregvaite, G. y Damasevicius, R. (editores), ICIST 2014 - Communications in Computer and Information Science (octubre 2014). Druskininkai, Lituania: Springer. BRAVO TORRES, J. F., ORDOÑEZ MORALES, E. F., LÓPEZ NORES, M., BLANCO FERNÁNDEZ, Y., PAZOS ARIAS, J., GIL SOLLA, A., y RAMOS CABRER, M. Connection Sharing on top of a Virtualization Layer to Support Vehicular Cloud Computing. En 3rd International Conference on Connected Vehicles and Expo (noviembre 2014). Viena, Austria : IEEE. ORDOÑEZ MORALES, E. F., LÓPEZ NORES, M., BLANCO FERNÁNDEZ, Y., BRAVO TORRES, J. F., PAZOS ARIAS, J., y RAMOS CABRER, M. En 3rd World Conference on Information Systems and Technologies (abril 2015). Azores, Portugal. BRAVO TORRES, J. F., SAIÁNS VÁZQUEZ, J. V., LÓPEZ NORES, M., BLANCO FERNÁNDEZ, Y., y PAZOS ARIAS, J. An efficient combination of topological and geographical routing for VANETs on top of a virtualization layer. En IEEE 81st Vehicular Technology Conference (mayo 2015). Glasgow, UK : IEEE. A.2.2. Artículos en proceso de revisión BRAVO TORRES, J. F., LÓPEZ NORES, M., BLANCO FERNÁNDEZ, Y., PAZOS ARIAS, J., y SAIÁNS VÁZQUEZ, J. V. Mobile data offloading in urban 174 Publicaciones derivadas de la tesis VANETs on top of a virtualization layer. En International Wireless Communications & Mobile Computing Conference (IWCMC 2015). Bibliografía [1] A BUELELA , M., AND O LARIU , S. Taking vanet to the clouds. En Proceedings of the 8th International Conference on Advances in Mobile Computing and Multimedia (New York, NY, USA, 2010), MoMM ’10, ACM, pp. 6–13. [2] ACAMPORA , G., C OOK , D., R ASHIDI , P., AND VASILAKOS , A. A survey on ambient intelligence in healthcare. Proceedings of the IEEE 101, 12 (dic. 2013), 2470–2494. [3] AGARWAL , A., AND L ITTLE , T. D. Prospects for networked vehicles of the future. En Proc. Smart Transportation Workshop in IEEE Real-Time and Embedded Technology and Applications Symposium (RTAS), Bellevue, WA, USA (2007). [4] AGARWALA , M., H SIAO , I.-H., C HAE , H. S., AND NATRIELLO , G. Vialogues: Videos and dialogues based social learning environment. En IEEE 12th International Conference on Advanced Learning Technologies (ICALT) (julio 2012), pp. 629–633. [5] AGATZ , N. A., E RERA , A. L., S AVELSBERGH , M. W., AND WANG , X. Dynamic ride-sharing: A simulation study in metro atlanta. Transportation Research Part B: Methodological 45, 9 (2011), 1450 – 1464. [6] AGGELOU , G., AND TAFAZOLLI , R. Rdmar: A bandwidth-efficient routing protocol for mobile ad hoc networks. En Proceedings of the 2Nd ACM International Workshop on Wireless Mobile Multimedia (New York, NY, USA, 1999), WOWMOM ’99, ACM, pp. 26–33. [7] A HLGREN , B., DANNEWITZ , C., I MBRENDA , C., K UTSCHER , D., AND O HL MAN , B. A survey of information-centric networking. Communications Magazine, IEEE 50, 7 (julio 2012), 26–36. [8] A HMED , H., E L -DARIEBY, M., M ORGAN , Y., AND A BDULHAI , B. A wireless mesh network-based platform for its. En Vehicular Technology Conference, 2008. VTC Spring 2008. IEEE (mayo 2008), pp. 3047–3051. [9] A KKERMAN , S., A DMIRAAL , W., AND H UIZENGA , J. Storification in history education: A mobile game in and about medieval amsterdam. Computers & Education 52, 2 (2009), 449 – 459. [10] A KYILDIZ , I. F., WANG , X., AND WANG , W. Wireless mesh networks: a survey. Computer Networks 47, 4 (2005), 445 – 487. 175 176 BIBLIOGRAFÍA [11] A L -S ULTAN , S., A L -D OORI , M. M., A L -BAYATTI , A. H., AND Z EDAN , H. A comprehensive survey on vehicular ad hoc network. Journal of Network and Computer Applications 37, 0 (2014), 380 – 392. [12] A LAM , K., S AINI , M., A HMED , D., AND E L S ADDIK , A. Vedi: A vehicular crowd-sourced video social network for vanets. En IEEE 39th Conference on Local Computer Networks Workshops (LCN Workshops) (sept. 2014), pp. 738– 745. [13] A LOTAIBI , E., AND M UKHERJEE , B. A survey on routing algorithms for wireless ad-hoc and mesh networks. Computer Networks 56, 2 (2012), 940 – 965. [14] A LSHARIF, N., C ESPEDES , S., AND S HEN , X. icar: Intersection-based connectivity aware routing in vehicular ad hoc networks. En IEEE International Conference on Communications (ICC) (junio 2013), pp. 1736–1741. [15] A MERICAN -B USINESS -C ONFERENCE . Improving the reliability of smartphone connectivity and integration with embedded systems to optimize vehicle competitiveness. En Proceedings of Smartphone & Embedded Connectivity Vehicle Integration (San Francisco (CA), USA, 2014), American Business Conferences. [16] A RENDS , M., W EINGARTNER , M., F ROSCHAUER , J., G OLDFARB , D., AND M ERKL , D. Learning about art history by exploratory search, contextual view and social tags. En IEEE 12th International Conference on Advanced Learning Technologies (ICALT) (julio 2012), pp. 395–399. [17] A RIF, S., O LARIU , S., WANG , J., YAN , G., YANG , W., AND K HALIL , I. Datacenter at the airport: Reasoning about time-dependent parking lot occupancy. IEEE Transactions on Parallel and Distributed Systems 23, 11 (nov. 2012), 2067–2080. [18] A RZIL , S., AGHDAM , M., AND JAMALI , M. Adaptive routing protocol for vanets in city environments using real-time traffic information. En International Conference on Information Networking and Automation (ICINA) (oct. 2010), vol. 2, pp. V2–132–V2–136. [19] AVUDAINAYAGAM , A., FANG , Y., AND L OU , W. Dear: a device and energy aware routing protocol for mobile ad hoc networks. En MILCOM 2002. Proceedings (oct. 2002), vol. 1, pp. 483–488 vol.1. [20] BACCARELLI , E., B IAGI , M., B RUNO , R., C ONTI , M., AND G REGORI , E. Broadband wireless access networks: a roadmap on emerging trends and standards. Wiley, 2005. [21] BACON , J. Toward pervasive computing. Pervasive Computing, IEEE 1, 2 (abril 2002), 84–. [22] BAI , F., AND H ELMY, A. Impact of mobility on mobility assisted information diffusion (maid) protocols. Tech. rep., 2005. [23] BAR , F., AND PARK , N. Municipal wi-fi networks: The goals, practices, and policy implications of the us case. Communications & Strategies 61, 1 (2006), 107–125. BIBLIOGRAFÍA 177 [24] BARBEAU , M. Point-to-point voice over ad hoc networks: A survey. Pervasive and Mobile Computing 8, 3 (2012), 376 – 387. [25] BAUZA , R., G OZALVEZ , J., AND S EPULCRE , M. Operation and performance of vehicular ad-hoc routing protocols in realistic environments. En Vehicular Technology Conference, 2008. VTC 2008-Fall. IEEE 68th (sept. 2008), pp. 1–5. [26] B EN M OKHTAR , S., AND C APRA , L. From pervasive to social computing: Algorithms and deployments. En Proceedings of the 2009 International Conference on Pervasive Services (New York, NY, USA, 2009), ICPS ’09, ACM, pp. 169–178. [27] B ITAM , S., AND M ELLOUK , A. Its-cloud: Cloud computing for intelligent transportation system. En Global Communications Conference (GLOBECOM), 2012 IEEE (dic. 2012), pp. 2054–2059. [28] B LANCO -F ERNÁNDEZ , Y., L ÓPEZ -N ORES , M., PAZOS -A RIAS , J. J., G IL S OLLA , A., R AMOS -C ABRER , M., AND G ARCÍA D UQUE , J. Reenact: A step forward in immersive learning about human history by augmented reality, role playing and social networking. Expert Systems with Applications 41, 10 (2014), 4811 – 4828. [29] B OND , C., F ERRARO , C., L UXTON , S., S ANDS , S., ET AL . Social media advertising: An investigation of consumer perceptions, attitudes, and preferences for engagement. En Proceedings of the Australian and New Zealand Marketing Academy (ANZMAC) Conference 2010-’Doing More with Less’ (2010), Department of Management University of Canterbury, pp. 1–7. [30] B OUKERCHE , A., O LIVEIRA , H. A., NAKAMURA , E. F., AND L OUREIRO , A. A. Vehicular ad hoc networks: A new challenge for localization-based systems. Computer Communications 31, 12 (2008), 2838 – 2849. Mobility Protocols for ITS/VANET. [31] B OUKERCHE , A., T URGUT, B., AYDIN , N., A HMAD , M. Z., B ÖLÖNI , L., AND T URGUT, D. Routing protocols in ad hoc networks: A survey. Computer Networks 55, 13 (2011), 3032 – 3080. [32] B ÜR , K., AND E RSOY, C. Ad hoc quality of service multicast routing. Computer Communications 29, 1 (2005), 136 – 148. [33] B RAHMI , N., B OUSSEDJRA , M., M OUZNA , J., AND BAYART, M. Dynamic routing based on road connectivity for urban vehicular environments. En Vehicular Networking Conference (VNC), 2009 IEEE (oct. 2009), pp. 1–6. [34] B RAHMI , N., B OUSSEDJRA , M., M OUZNA , J., AND BAYART, M. Road connectivity-based routing for vehicular ad hoc networks. En International Conference on Advanced Technologies for Communications (ATC) (oct. 2010), pp. 255–259. [35] B RAVO T ORRES , J., L OPEZ N ORES , M., B LANCO F ERNANDEZ , Y., AND PA ZOS A RIAS , J. Leveraging short-lived social networks in vehicular environments. En Second International Conference on Future Generation Communication Technology (FGCT) (nov. 2013), pp. 196–200. 178 BIBLIOGRAFÍA [36] B RAVO T ORRES , J., L OPEZ N ORES , M., B LANCO F ERNANDEZ , Y., S ER VIA RODRIGUEZ , S., AND G ARCIA D UQUE , J. A virtualization layer for mobile consumer devices to support demanding communication services in vehicular ad-hoc networks. En IEEE International Conference on Consumer Electronics (ICCE) (enero 2012), pp. 225–226. [37] B RAVO T ORRES , J. F. Virtualization support for complex communications in vehicular ad hoc networks. MTA Review 23, 2 (jun 2013), 121–140. [38] B RAVO T ORRES , J. F., L OPEZ N ORES , M., B LANCO F ERNANDEZ , Y., AND PAZOS A RIAS , J. Virtual virtual circuits: One step beyond virtual mobile nodes in vehicular ad-hoc networks. En Vehicular Technology Conference (VTC Fall), 2012 IEEE (sept. 2012), pp. 1–2. [39] B RAVO T ORRES , J. F., L ÓPEZ N ORES , M., B LANCO F ERNÁNDEZ , Y., AND PAZOS A RIAS , J. J. A platform to exploit short-lived relationships among mobile users: A case of collective immersive learning. En Information and Software Technologies, G. Dregvaite and R. Damasevicius, Eds., vol. 465 of Communications in Computer and Information Science. Springer International Publishing, 2014, pp. 384–395. [40] B RAVO T ORRES , J. F., O RDONEZ M ORALES , E., L OPEZ N ORES , M.N ORES , M., B LANCO F ERNANDEZ , Y., AND PAZOS A RIAS , J. Virtualization in vanets to support the vehicular cloud - experiments with the network as a service model. En Third International Conference on Future Generation Communication Technology (FGCT) (agt. 2014), pp. 1–6. [41] B ROWN , M., G ILBERT, S., LYNCH , N., N EWPORT, C., N OLTE , T., AND S PIN DEL , M. The virtual node layer: A programming abstraction for wireless sensor networks. SIGBED Rev. 4, 3 (2007), 7–12. [42] B RUNO , R., C ONTI , M., AND G REGORI , E. Mesh networks: commodity multihop ad hoc networks. Communications Magazine, IEEE 43, 3 (marzo 2005), 123–131. [43] C ALISKAN , M., G RAUPNER , D., AND M AUVE , M. Decentralized discovery of free parking places. En Proceedings of the 3rd International Workshop on Vehicular Ad Hoc Networks (New York, NY, USA, 2006), VANET ’06, ACM, pp. 30–39. [44] C ASTRO , M., K ASSLER , A., C HIASSERINI , C.-F., C ASETTI , C., AND KOR PEOGLU , I. Peer-to-peer overlay in mobile ad-hoc networks. En Handbook of Peer-to-Peer Networking, X. Shen, H. Yu, J. Buford, and M. Akon, Eds. Springer US, 2010, pp. 1045–1080. [45] C HARSKY, D., AND R ESSLER , W. Games are made for fun: Lessons on the effects of concept maps in the classroom use of computer games. Comput. Educ. 56, 3 (2011), 604–615. [46] C HEN , B. B., AND C HAN , M. C. Mobtorrent: A framework for mobile internet access from vehicles. En Proceedings of 24th IEEE Conference on Computer Communications (INFOCOM) (Rio de Janeiro, Brasil, 2009). BIBLIOGRAFÍA 179 [47] C HEN , J., G EYER , W., D UGAN , C., M ULLER , M., AND G UY, I. Make new friends, but keep the old: recommending people on social networking sites. En Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (2009), ACM, pp. 201–210. [48] C HENG , H. T., S HAN , H., AND Z HUANG , W. Infotainment and road safety service support in vehicular networking: From a communication perspective. Mechanical Systems and Signal Processing 25, 6 (2011), 2020 – 2038. Interdisciplinary Aspects of Vehicle Dynamics. [49] C HIANG , C.-Y., C HADHA , R., N EWMAN , S., AND L O , R. Towards automation of management and planning for future military tactical networks. En Military Communications Conference, 2006. MILCOM 2006. IEEE (oct. 2006), pp. 1–7. [50] C HIANG , C.-Y. J., C HADHA , R., N EWMAN , S., L O , R., AND BAUER , R. Integrated network operations for future army tactical networks. En Military Communications Conference, 2007. MILCOM 2007. IEEE (oct. 2007), pp. 1–7. [51] C HLAMTAC , I., C ONTI , M., AND L IU , J. J.-N. Mobile ad hoc networking: imperatives and challenges. Ad Hoc Networks 1, 1 (2003), 13 – 64. [52] C HOU , L.-D., YANG , J.-Y., H SIEH , Y.-C., AND T UNG , C.-F. Intersectionbased routing protocol for vanet. En Second International Conference on Ubiquitous and Future Networks (ICUFN) (junio 2010), pp. 268–272. [53] C OHEN , B. Incentives build robustness in bittorrent. En Workshop on Economics of Peer-to-Peer systems (2003), vol. 6, pp. 68–72. [54] C ONTI , M., AND G IORDANO , S. Multihop ad hoc networking: The theory. Communications Magazine, IEEE 45, 4 (abril 2007), 78–86. [55] C ONTI , M., AND G IORDANO , S. Multihop Ad Hoc Networking: The Evolutionary Path. John Wiley & Sons, Inc., 2013, pp. 1–33. [56] C OOK , D., AND DAS , S. Smart Environments: Technology, Protocols and Applications (Wiley Series on Parallel and Distributed Computing). WileyInterscience, 2004. [57] C OOK , D. J., AUGUSTO , J. C., AND JAKKULA , V. R. Ambient intelligence: Technologies, applications, and opportunities. Pervasive and Mobile Computing 5, 4 (2009), 277 – 298. [58] C OOK , D. J., AND DAS , S. K. Pervasive computing at scale: Transforming the state of the art. Pervasive and Mobile Computing 8, 1 (2012), 22 – 35. [59] DAR , K., BAKHOUYA , M., G ABER , J., WACK , M., AND L ORENZ , P. Wireless communication technologies for its applications [topics in automotive networking]. Communications Magazine, IEEE 48, 5 (mayo 2010), 156–162. [60] DAS , S., R AW, R., DAS , I., AND S ARKAR , R. Performance analysis of routing protocols for vanets with real vehicular traces. En Intelligent Computing, Networking, and Informatics, D. P. Mohapatra and S. Patnaik, Eds., vol. 243 of Advances in Intelligent Systems and Computing. Springer India, 2014, pp. 45– 56. 180 BIBLIOGRAFÍA [61] DAS , S. K., B. S. M ANOJ , B. S., AND R AM M URTHY, C. S. A dynamic core based multicast routing protocol for ad hoc wireless networks. En Proceedings of the 3rd ACM International Symposium on Mobile Ad Hoc Networking &Amp; Computing (New York, NY, USA, 2002), MobiHoc ’02, ACM, pp. 24–35. [62] D HURANDHER , S. K., M ISRA , S., P RUTHI , P., S INGHAL , S., AGGARWAL , S., AND W OUNGANG , I. Using bee algorithm for peer-to-peer file searching in mobile ad hoc networks. J. Netw. Comput. Appl. 34, 5 (2011), 1498–1508. [63] D IAZ , P., PAREDES , P., A LVARADO , D., AND G IACCARDI , E. Co-designing social games with children to support non formal learning. En IEEE 12th International Conference on Advanced Learning Technologies (ICALT) (julio 2012), pp. 682–683. [64] D IMITRIJEVIC , D., N EDIC , N., AND D IMITRIESKI , V. Real-time carpooling and ride-sharing: Position paper on design concepts, distribution and cloud computing strategies. En Federated Conference on Computer Science and Information Systems (FedCSIS) (sept. 2013), pp. 781–786. [65] D IVECHA , B., A BRAHAM , A., G ROSAN , C., AND S ANYAL , S. Impact of node mobility on manet routing protocols models. Journal of Digital Information Management 5, 1 (2007), 19. [66] D OHR , A., M ODRE -O PSRIAN , R., D ROBICS , M., H AYN , D., AND S CHREIER , G. The internet of things for ambient assisted living. En Information Technology: New Generations (ITNG), 2010 Seventh International Conference on (abril 2010), pp. 804–809. [67] D OLEV, S., G ILBERT, S., LYNCH , N., S CHILLER , E., S HVARTSMAN , A., AND W ELCH , J. Virtual mobile nodes for mobile ad hoc networks. En Distributed Computing, R. Guerraoui, Ed., vol. 3274 of Lecture Notes in Computer Science. Springer Berlin Heidelberg, 2004, pp. 230–244. [68] D ORNBUSH , S., AND J OSHI , A. Streetsmart traffic: Discovering and disseminating automobile congestion using vanet’s. En Vehicular Technology Conference, 2007. VTC2007-Spring. IEEE 65th (abril 2007), pp. 11–15. [69] D ROMS , R. Dynamic host configuration protocol. RFC 2131 (1997). [70] D U , J., L IU , H., AND C HEN , P. Omr: An opportunistic multi-path reliable routing protocol in wireless sensor networks. En International Conference on Parallel Processing Workshops (sept. 2007), pp. 74–74. [71] D UA , A., K UMAR , N., AND BAWA , S. A systematic review on routing protocols for vehicular ad hoc networks. Vehicular Communications 1, 1 (2014), 33 – 52. [72] E DWARDS , W. K., AND G RINTER , R. E. At home with ubiquitous computing: Seven challenges. En Proceedings of the 3rd International Conference on Ubiquitous Computing (Londres, UK, UK, 2001), UbiComp ’01, Springer-Verlag, pp. 256–272. BIBLIOGRAFÍA 181 [73] E LTOWEISSY, M., O LARIU , S., AND YOUNIS , M. Towards autonomous vehicular clouds. En Ad Hoc Networks, J. Zheng, D. Simplot-Ryl, and V. Leung, Eds., vol. 49 of Lecture Notes of the Institute for Computer Sciences, Social Informatics and Telecommunications Engineering. Springer Berlin Heidelberg, 2010, pp. 1–16. [74] F EI , R., YANG , K., AND C HENG , X. A cooperative social and vehicular network and its dynamic bandwidth allocation algorithms. En IEEE Conference on Computer Communications Workshops (INFOCOM WKSHPS) (abril 2011), pp. 63–67. [75] F ERNANDO , N., L OKE , S. W., AND R AHAYU , W. Mobile cloud computing: A survey. Future Generation Computer Systems 29, 1 (2013), 84 – 106. Including Special section: AIRCC-NetCoM 2009 and Special section: Clouds and ServiceOriented Architectures. [76] FORUM , M. Discover the world of mobile cloud computing. [77] F RANGOUDIS , P., P OLYZOS , G., AND K EMERLIS , V. Wireless community networks: an alternative approach for nomadic broadband network access. Communications Magazine, IEEE 49, 5 (mayo 2011), 206–213. [78] F RODIGH , M., J OHANSSON , P., AND L ARSSON , P. Wireless ad hoc networking-the art of networking without a network. Ericsson Review 4, 4 (2000), 249. [79] F ROSCHAUER , J., Z WENG , J., M ERKL , D., A RENDS , M., G OLDFARB , D., AND W EINGARTNER , M. Artournament: A mobile casual game to explore art history. En IEEE 12th International Conference on Advanced Learning Technologies (ICALT) (julio 2012), pp. 80–84. [80] F URUHATA , M., D ESSOUKY, M., O RDOÑEZ , F., B RUNET, M.-E., WANG , X., AND K OENIG , S. Ridesharing: The state-of-the-art and future directions. Transportation Research Part B: Methodological 57, 0 (2013), 28 – 46. [81] G ENTES , A., G UYOT-M BODJI , A., AND D EMEURE , I. Gaming on the move: urban experience as a new paradigm for mobile pervasive game design. Multimedia Systems 16, 1 (2010), 43–55. [82] G ERLA , M. Vehicular cloud computing. En The 11th Annual Mediterranean Ad Hoc Networking Workshop (Med-Hoc-Net) (junio 2012), pp. 152–155. [83] G ERLA , M., C HEN , L.-J., L EE , Y.-Z., Z HOU , B., C HEN , J., YANG , G., AND DAS , S. Dealing with node mobility in ad hoc wireless network. En Formal Methods for Mobile Computing. Springer, 2005, pp. 69–106. [84] G ERLA , M., AND K LEINROCK , L. Vehicular networks and the future of the mobile internet. Computer Networks 55, 2 (2011), 457 – 469. Wireless for the Future Internet. [85] G ERLA , M., W U , C., PAU , G., AND Z HU , X. Content distribution in vanets. Vehicular Communications 1, 1 (2014), 3–12. 182 BIBLIOGRAFÍA [86] G OMEZ , J., C AMPBELL , A. T., NAGHSHINEH , M., AND B ISDIKIAN , C. Paro: Supporting dynamic power controlled routing in wireless ad hoc networks. Wirel. Netw. 9, 5 (2003), 443–460. [87] G U , Y., L O , A., AND N IEMEGEERS , I. A survey of indoor positioning systems for wireless personal networks. Communications Surveys Tutorials, IEEE 11, 1 (enero 2009), 13–32. [88] G UNES , M., S ORGES , U., AND B OUAZIZI , I. Ara-the ant-colony based routing algorithm for manets. En International Conference on Parallel Processing Workshops, 2002. Proceedings. (2002), pp. 79–85. [89] G URUMURTHY, S. Envisioning social computing applications on wireless networks. Master’s thesis, University of Massachusetts - Amherst, 2009. [90] H AAS , Z. J., P EARLMAN , M. R., AND S AMAR , P. The zone routing protocol (zrp) for ad hoc networks. draft-ietf-manet-zone-zrp-04. txt (2002). [91] H AERRI , J., F ILALI , F., AND B ONNET, C. Performance comparison of aodv and olsr in vanets urban environments under realistic mobility patterns. En Proceedings of the 5th IFIP mediterranean ad-hoc networking workshop (2006), pp. 14–17. [92] H ARJULA , E., K ASSINEN , O., AND Y LIANTTILA , M. Energy consumption model for mobile devices in 3g and wlan networks. En Consumer Communications and Networking Conference (CCNC), 2012 IEEE (enero 2012), pp. 532– 537. [93] H ARRI , J., F ILALI , F., AND B ONNET, C. Mobility models for vehicular ad hoc networks: a survey and taxonomy. Communications Surveys Tutorials, IEEE 11, 4 (abril 2009), 19–41. [94] H ARTENSTEIN , H., AND L ABERTEAUX , K. A tutorial survey on vehicular ad hoc networks. Communications Magazine, IEEE 46, 6 (junio 2008), 164–171. [95] H ELAL , S., D ESAI , N., V ERMA , V., AND L EE , C. Konark: A service discovery and delivery protocol for ad-hoc networks. En Proceedings of 3rd IEEE Conference on Wireless Communication Networks (WCNC) (New Orleans (LA), USA, 2003). [96] H OEBEKE , J., M OERMAN , I., D HOEDT, B., AND D EMEESTER , P. An overview of mobile ad hoc networks: Applications and challenges. JournalCommunications Network 3, 3 (2004), 60–66. [97] H ONG , P. T., PARK , H., AND K ANG , C.-H. A road and traffic-aware routing protocol in vehicular ad hoc networks. En 13th International Conference on Advanced Communication Technology (ICACT) (Feb 2011), pp. 24–28. [98] H ONG , X., X U , K., AND G ERLA , M. Scalable routing protocols for mobile ad hoc networks. Network, IEEE 16, 4 (julio 2002), 11–21. [99] H UERTA -C ANEPA , G., AND L EE , D. A virtual cloud computing provider for mobile devices. En Proceedings of the 1st ACM Workshop on Mobile Cloud Computing & Services: Social Networks and Beyond (New York, NY, USA, 2010), MCS ’10, ACM, pp. 6:1–6:5. BIBLIOGRAFÍA 183 [100] H WANG , R.-H., AND H OH , C.-C. Cross-layer design of p2p file sharing over mobile ad hoc networks. Telecommunication Systems 42, 1-2 (2009), 47–61. [101] IEEE. Standard for Local and metropolitan area networks–Part 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs).. [102] IEEE. Standard for Information technology–Telecommunications and information exchange between systems Local and metropolitan area networks–Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications Ame. [103] IEEE. Standard for Information Technology - Telecommunications and Information Exchange Between Systems - Local and Metropolitan Area Networks - Specific Requirements. - Part 15.1: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Wireless Personal Area Networks (WPANs) (2005), 01–580. [104] I SHMAEL , J., B URY, S., P EZAROS , D., AND R ACE , N. Deploying rural community wireless mesh networks. Internet Computing, IEEE 12, 4 (julio 2008), 22–29. [105] I STEPANIAN , R., S UNGOOR , A., FAISAL , A., AND P HILIP, N. Internet of mhealth things "m-iot". En IET Seminar on Assisted Living 2011 (abril 2011), pp. 1–3. [106] I WATA , A., C HIANG , C.-C., P EI , G., G ERLA , M., AND C HEN , T.-W. Scalable routing strategies for ad hoc wireless networks. IEEE Journal on Selected Areas in Communications 17, 8 (agt. 1999), 1369–1379. [107] JACOBSON , A. R., M ILITELLO , R., AND BAVEYE , P. C. Development of computer-assisted virtual field trips to support multidisciplinary learning. Computers & Education 52, 3 (2009), 571 – 580. [108] JACQUET, P., M UHLETHALER , P., C LAUSEN , T., L AOUITI , A., Q AYYUM , A., AND V IENNOT, L. Optimized link state routing protocol for ad hoc networks. En IEEE International Multi Topic Conference, 2001. IEEE INMIC 2001. Technology for the 21st Century. Proceedings. (2001), pp. 62–68. [109] J ERBI , M., S ENOUCI , S.-M., R ASHEED , T., AND G HAMRI -D OUDANE , Y. Towards efficient geographic routing in urban vehicular networks. IEEE Transactions on Vehicular Technology 58, 9 (nov. 2009), 5048–5059. [110] J OA -N G , M., AND L U , I.-T. A peer-to-peer zone-based two-level link state routing for mobile ad hoc networks. IEEE Journal on Selected Areas in Communications 17, 8 (agt. 1999), 1415–1425. [111] J OHNSEN , F., F LATHAGEN , J., AND H AFSOE , T. Pervasive service discovery across heterogeneous tactical networks. En Military Communications Conference, 2009. MILCOM 2009. IEEE (oct. 2009), pp. 1–8. [112] J OHNSON , D., AND M ALTZ , D. Dynamic source routing in ad hoc wireless networks. En Mobile Computing, T. Imielinski and H. Korth, Eds., vol. 353 of The Kluwer International Series in Engineering and Computer Science. Springer US, 1996, pp. 153–181. 184 BIBLIOGRAFÍA [113] J UN , J., AND S ICHITIU , M. L. Mrp: Wireless mesh networks routing protocol. Comput. Commun. 31, 7 (2008), 1413–1435. [114] K ARP, B., AND K UNG , H. T. Gpsr: Greedy perimeter stateless routing for wireless networks. En Proceedings of the 6th Annual International Conference on Mobile Computing and Networking (New York, NY, USA, 2000), MobiCom ’00, ACM, pp. 243–254. [115] K AYASTHA , N., N IYATO , D., WANG , P., AND H OSSAIN , E. Applications, architectures, and protocol design issues for mobile social networks: A survey. Proceedings of the IEEE 99, 12 (dic. 2011), 2130–2158. [116] K HOSROWSHAHI -A SL , E., N OORHOSSEINI , M., AND P IROUZ , A. S. A dynamic ant colony based routing algorithm for mobile ad-hoc networks. Journal of Information Science and Engineering 27, 5 (2011), 1581–1596. [117] K IHL , M. Vehicular Network Applications and Services. Vehicular Networks: Techniques, Standards, and Applications. CRC Press, 2009. [118] K LEINROCK , L. Queueing Systems, vol. I: Theory. Wiley Interscience, 1975. (Published in Russian, 1979. Published in Japanese, 1979. Published in Hungarian, 1979. Published in Italian 1992.). [119] KO , Y.-B., AND VAIDYA , N. Geotora: a protocol for geocasting in mobile ad hoc networks. En International Conference on Network Protocols, 2000. Proceedings. (2000), pp. 240–250. [120] K UMAR , J. Comparative performance analysis of aodv, dsr, dymo, olsr and zrp routing protocols in manet using varying pause time. International Journal of Computer Communications and Networks (IJCCN) 3, 1 (2012), 43–51. [121] K URKOVSKY, S. Pervasive computing: Past, present and future. En ITI 5th International Conference on Information and Communications Technology, 2007. ICICT 2007. (dic. 2007), pp. 65–71. [122] K WON , T. J., AND G ERLA , M. Efficient flooding with passive clustering (pc) in ad hoc networks. SIGCOMM Comput. Commun. Rev. 32, 1 (2002), 44–56. [123] K YASANUR , P., AND VAIDYA , N. H. Routing and link-layer protocols for multi-channel multi-interface ad hoc wireless networks. SIGMOBILE Mob. Comput. Commun. Rev. 10, 1 (2006), 31–43. [124] L Ü , L., M EDO , M., Y EUNG , C. H., Z HANG , Y.-C., Z HANG , Z.-K., AND Z HOU , T. Recommender systems. Physics Reports 519, 1 (2012), 1 – 49. Recommender Systems. [125] L E G AL , C., M ARTIN , J., AND D URAND , G. Smart office: An intelligent and interactive environment. En Managing Interactions in Smart Environments, P. Nixon, G. Lacey, and S. Dobson, Eds. Springer London, 2000, pp. 104–113. [126] L EE , E., L EE , E.-K., G ERLA , M., AND O H , S. Vehicular cloud networking: architecture and design principles. Communications Magazine, IEEE 52, 2 (febr. 2014), 148–155. BIBLIOGRAFÍA 185 [127] L EE , K., L EE , S.-H., C HEUNG , R., L EE , U., AND G ERLA , M. First experience with cartorrent in a real vehicular ad hoc network testbed. En 2007 Mobile Networking for Vehicular Environments (mayo 2007), pp. 109–114. [128] L EE , K. C., L EE , U., AND G ERLA , M. Survey of routing protocols in vehicular ad hoc networks. Advances in vehicular ad-hoc networks: Developments and challenges (2010), 149–170. [129] L EE , S.-J., AND G ERLA , M. Split multipath routing with maximally disjoint paths in ad hoc networks. En IEEE International Conference on Communications, 2001. ICC 2001. (2001), vol. 10, pp. 3201–3205 vol.10. [130] L EE , U., C HEUNG , R., AND G ERLA , M. Emerging vehicular applications. Vehicular Networks: From Theory to Practice. Chapman and Hall/CRC (2009). [131] L EE , U., PARK , J.-S., Y EH , J., PAU , G., AND G ERLA , M. Code torrent: Content distribution using network coding in VANET. En Proceedings of 1st International Workshop on Decentralized Resource Sharing in Mobile Computing and Networking, in conjunction with MobiShare (New York, USA, 2006). [132] L EONTIADIS , I., AND M ASCOLO , C. Geopps: Geographical opportunistic routing for vehicular networks. En IEEE International Symposium on a World of Wireless, Mobile and Multimedia Networks, 2007. WoWMoM 2007. (junio 2007), pp. 1–6. [133] L EQUERICA , I., G ARCÍA L ONGARON , M., AND RUIZ , P. Drive and share: efficient provisioning of social networks in vehicular scenarios. Communications Magazine, IEEE 48, 11 (noviembre 2010), 90–97. [134] L I , Y. An overview of the dsrc/wave technology. En Quality, Reliability, Security and Robustness in Heterogeneous Networks, X. Zhang and D. Qiao, Eds., vol. 74 of Lecture Notes of the Institute for Computer Sciences, Social Informatics and Telecommunications Engineering. Springer Berlin Heidelberg, 2012, pp. 544–558. [135] L I , Y.-M., W U , C.-T., AND L AI , C.-Y. A social recommender mechanism for e-commerce: Combining similarity, trust, and relationship. Decision Support Systems 55, 3 (2013), 740 – 752. [136] L IN , P., Y EUNG , K., AND W ONG , K. Multiple path routing using tree-based multiple portal association for wireless mesh networks. En 6th International Symposium on Wireless and Pervasive Computing (ISWPC) (febr. 2011), pp. 1– 6. [137] L IU , B., WANG , F.-Y., G ENG , J., YAO , Q., G AO , H., AND Z HANG , B. Intelligent spaces: An overview. En IEEE International Conference on Vehicular Electronics and Safety, 2007. ICVES. (dic. 2007), pp. 1–6. [138] L IU , G., L EE , B.-S., S EET, B.-C., F OH , C.-H., W ONG , K.-J., AND L EE , K.K. A routing strategy for metropolis vehicular communications. En Information Networking. Networking Technologies for Broadband and Mobile Networks, H.K. Kahng and S. Goto, Eds., vol. 3090 of Lecture Notes in Computer Science. Springer Berlin Heidelberg, 2004, pp. 134–143. 186 BIBLIOGRAFÍA [139] L IU , J., G E , Y., B I , J., AND G UO , L. Cooperative downloading strategy on highway scenario. En IEEE 12th International Conference on Computer and Information Technology (CIT) (oct. 2012), pp. 828–832. [140] L IU , X., L I , Z., L I , W., L U , S., WANG , X., AND C HEN , D. Exploring social properties in vehicular ad hoc networks. En Proceedings of the Fourth AsiaPacific Symposium on Internetware (New York, NY, USA, 2012), Internetware ’12, ACM, pp. 24:1–24:7. [141] L OCHERT, C., H ARTENSTEIN , H., T IAN , J., F USSLER , H., H ERMANN , D., AND M AUVE , M. A routing strategy for vehicular ad hoc networks in city environments. En Intelligent Vehicles Symposium, 2003. Proceedings. IEEE (junio 2003), pp. 156–161. [142] L OIDL , S. Towards pervasive learning: Welearn.mobile. a {CPS} package viewer for handhelds. Journal of Network and Computer Applications 29, 4 (2006), 277 – 293. [143] L OPEZ -N ORES , M., B LANCO -F ERNANDEZ , Y., G IL -S OLLA , A., R AMOS C ABRER , M., G ARCIA -D UQUE , J., AND PAZOS -A RIAS , J. Leveraging shortlived social networks in museums to engage people in history learning. En 8th International Workshop on Semantic and Social Media Adaptation and Personalization (SMAP) (dic. 2013), pp. 83–88. [144] L ÓPEZ -N ORES , M., B LANCO -F ERNÁNDEZ , Y., PAZOS -A RIAS , J. J., G IL S OLLA , A., G ARCÍA -D UQUE , J., AND R AMOS -C ABRER , M. Reenact experiment - experiment problem statement, requirements and PIA review. EXPERIMEDIA project deliverable D4.9.1, http://www.experimedia.eu/publications, 2012. [145] L ÓPEZ -N ORES , M., B LANCO -F ERNÁNDEZ , Y., PAZOS -A RIAS , J. J., G IL S OLLA , A., G ARCÍA -D UQUE , J., AND R AMOS -C ABRER , M. Reenact experiment - results and evaluation. EXPERIMEDIA project deliverable D4.9.4, http://www.experimedia.eu/publications, 2013. [146] L ÓPEZ N ORES , M., B RAVO T ORRES , J. F., B LANCO F ERNÁNDEZ , Y., AND PAZOS A RIAS , J. J. Sporangium: A platform to support sporadic social networks based on ad-hoc communications and mobile cloud computing. shortlived virtual networked organizations in venues, on the road and in the smart city. En 2nd International Conference on Virtual and Networked Organizations Emergent Technologies and Tools (ViNOrg) (Póvoa de Varzim, Portugal, nov. 2013), Universidade de Minho. [147] L UGANO , G. Mobile social networking in theory and practice. First Monday 13, 11 (2008). [148] L UU , B., O’B RIEN , B., BARAN , D., AND H ARDY, R. A soldier-robot ad hoc network. En Fifth Annual IEEE International Conference on Pervasive Computing and Communications Workshops, 2007. PerCom Workshops ’07. (marzo 2007), pp. 558–563. [149] M ACINTOSH , A., G HAVAMI , M., S IYAU , M. F., AND L ING , S. L. Local area network dynamic (landy) routing protocol: A position based routing protocol for BIBLIOGRAFÍA 187 manet. En European Wireless, 2012. EW. 18th European Wireless Conference (abril 2012), pp. 1–9. [150] M AHLER , K., PASCHALIDIS , P., KORTKE , A., P ETER , M., AND K EUSGEN , W. Realistic ieee 802.11p transmission simulations based on channel sounder measurement data. En Vehicular Technology Conference (VTC Fall), 2013 IEEE 78th (sept. 2013), pp. 1–5. [151] M AILE , M., N EALE , V., A HMED -Z AID , F., BASNYAKE , C., C AMINITI , L., D OERZAPH , Z., K ASS , S., K IEFER , R., L OSH , M., AND L UNDBERG , J. Cooperative intersection collision avoidance system limited to stop sign and traffic signal violations (cicas-v). Tech. rep., United States Department of Transportation, Federal Highway Administration, 2008. [152] M ALKIN , G. RIP: An Intra-domain Routing Protocol. Addison-Wesley networking basics series. Addison-Wesley, 2000. [153] M ANDVIWALLA , M., JAIN , A., F ESENMAIER , J., S MITH , J., W EINBERG , P., AND M EYERS , G. Municipal broadband wireless networks. Commun. ACM 51, 2 (2008), 72–80. [154] M ANNA , S., B HUNIA , S., AND M UKHERJEE , N. Vehicular pollution monitoring using iot. En Recent Advances and Innovations in Engineering (ICRAIE), 2014 (mayo 2014), pp. 1–5. [155] M ANVI , S., K AKKASAGERI , M., AND M AHAPURUSH , C. Performance analysis of aodv, dsr, and swarm intelligence routing protocols in vehicular ad hoc network environment. En International Conference on Future Computer and Communication, 2009. ICFCC 2009. (abril 2009), pp. 21–25. [156] M ARINA , M., AND DAS , S. On-demand multipath distance vector routing in ad hoc networks. En Ninth International Conference on Network Protocols, 2001. (nov. 2001), pp. 14–23. [157] M ARINELLI , E. E. Hyrax: cloud computing on mobile devices using mapreduce. Tech. rep., DTIC Document, 2009. [158] M ARTINS , J., O LIVEIRA -L IMA , J., D ELGADO -G OMES , V., L OPES , R., S IL VA , D., V IEIRA , S., AND L IMA , C. Smart homes and smart buildings. En 13th Biennial Baltic Electronics Conference (BEC) (oct. 2012), pp. 27–38. [159] M C Q UILLAN , J., R ICHER , I., AND ROSEN , E. The new routing algorithm for the arpanet. IEEE Transactions on Communications 28, 5 (mayo 1980), 711– 719. [160] M EISSNER , A., L UCKENBACH , T., R ISSE , T., K IRSTE , T., AND K IRCHNER , H. Design challenges for an integrated disaster management communication and information system. En The First IEEE Workshop on Disaster Recovery Networks DIREN 2002 (2002), vol. 24. [161] M ELL , P., AND G RANCE , T. The nist definition of cloud computing. http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf, septiembre 2011. 188 BIBLIOGRAFÍA [162] M ENNICKEN , S., V ERMEULEN , J., AND H UANG , E. M. From today’s augmented houses to tomorrow’s smart homes: New directions for home automation research. En Proceedings of the 2014 ACM International Joint Conference on Pervasive and Ubiquitous Computing (New York, NY, USA, 2014), UbiComp ’14, ACM, pp. 105–115. [163] M ICROSOFT-R ESEARCH . Microsoft mesh networks. En Disponible desde http://research.microsoft.com/en-us/projects/mesh/. Accedido el 11 de diciembre del 2014. [164] M ITRA , G., C HOWDHURY, C., AND N EOGY, S. Application of mobile agent in vanet for measuring environmental data. En Applications and Innovations in Mobile Computing (AIMoC), 2014 (Feb 2014), pp. 48–53. [165] M OHAPATRA , P., L I , J., AND G UI , C. Qos in mobile a hoc networks. Wireless Communications, IEEE 10, 3 (2003), 44–52. [166] M OWAFEY, S., AND G ARDNER , S. Towards ambient intelligence in assisted living: The creation of an intelligent home care. En Science and Information Conference (SAI), 2013 (oct. 2013), pp. 51–60. [167] M UKHERJEE , S., PAL , S., C HOUDHURY, P., AND NANDI , S. Challenges of establishing a collaborative learning environment using manet. En 2nd International Conference on Business and Information Management (ICBIM) (enero 2014), pp. 23–26. [168] M UNI W IRELESS . www.muniwireless.com/2010/04/24/municipal-wirelessnetworks-in-spain/. accedido el 13 de diciembre del 2014. [169] NADEEM , T., DASHTINEZHAD , S., L IAO , C., AND I FTODE , L. Trafficview: Traffic data dissemination using car-to-car communication. SIGMOBILE Mob. Comput. Commun. Rev. 8, 3 (2004), 6–19. [170] NAMBOODIRI , V., AND G AO , L. Prediction-based routing for vehicular ad hoc networks. IEEE Transactions on Vehicular Technology 56, 4 (julio 2007), 2332– 2345. [171] NANDAN , A., DAS , S., PAU , G., G ERLA , M., AND S ANADIDI , M. Cooperative downloading in vehicular ad hoc networks. En Proceedings of 2nd International Conference on Wireless On-Demand Network Systems and Services (WONS) (St. Moritz, Switzerland, 2005). [172] NATKANIEC , M., KOSEK -S ZOTT, K., S ZOTT, S., G OZDECKI , J., G OWACZ , A., AND S ARGENTO , S. Supporting qos in integrated ad-hoc networks. Wireless Personal Communications 56, 2 (2011), 183–206. [173] N IKAEIN , N., L ABIOD , H., AND B ONNET, C. Ddr-distributed dynamic routing algorithm for mobile ad hoc networks. En First Annual Workshop on Mobile and Ad Hoc Networking and Computing, 2000. MobiHOC. (2000), pp. 19–27. [174] N INCAREAN , D., A LIA , M. B., H ALIM , N. D. A., AND R AHMAN , M. H. A. Mobile augmented reality: The potential for education. Procedia - Social and Behavioral Sciences 103, 0 (2013), 657 – 664. 13th International Educational Technology Conference. BIBLIOGRAFÍA [175] NS -2. Network simulator (ns-2), (http://isi.edu/nsnam/ns/). [176] NS -3. Network simulator (ns-3), (http://www.nsnam.org/). 189 [177] N ZOUONTA , J., R AJGURE , N., WANG , G., AND B ORCEA , C. Vanet routing on city roads using real-time vehicular traffic information. IEEE Transactions on Vehicular Technology 58, 7 (sept. 2009), 3609–3626. [178] O LARIU , S., H RISTOV, T., AND YAN , G. The Next Paradigm Shift: From Vehicular Networks to Vehicular Clouds. John Wiley & Sons, Inc., 2013, pp. 645– 700. [179] O LARIU , S., AND W EIGLE , M. C. Vehicular Networks: From Theory to Practice, 1 ed. Chapman & Hall/CRC, 2009. [180] O RDOÑEZ M ORALES , E. F., B LANCO F ERNÁNDEZ , Y., L ÓPEZ -N ORES , M., B RAVO T ORRES , J. F., PAZOS A RIAS , J. J., AND R AMOS C ABRER , M. Sporangium: Exploiting a virtualization layer to support the concept of sporadic cloud computing with users on the move. En New Contributions in Information Systems and Technologies, A. Rocha, A. M. Correia, S. Costanzo, and L. P. Reis, Eds., vol. 353 of Advances in Intelligent Systems and Computing. Springer International Publishing, 2015, pp. 959–966. [181] O RWAT, C., G RAEFE , A., AND FAULWASSER , T. Towards pervasive computing in health care–a literature review. BMC Medical Informatics and Decision Making 8, 1 (2008), 26. [182] PATIL , R., AND S HAH , S. R. Cross layer based virtual node layer for reactive manet routing. International Journal of Engineering Research & Technology 1, 6 (agt. 2012). [183] P EI , G., G ERLA , M., AND C HEN , T.-W. Fisheye state routing: a routing scheme for ad hoc wireless networks. En IEEE International Conference on Communications, 2000. ICC 2000. (2000), vol. 1, pp. 70–74 vol.1. [184] P ERKINS , C., AND ROYER , E. Ad-hoc on-demand distance vector routing. En Second IEEE Workshop on Mobile Computing Systems and Applications, 1999. Proceedings. WMCSA ’99. (febr. 1999), pp. 90–100. [185] P ERKINS , C. E., AND B HAGWAT, P. Highly dynamic destination-sequenced distance-vector routing (dsdv) for mobile computers. En Proceedings of the Conference on Communications Architectures, Protocols and Applications (New York, NY, USA, 1994), SIGCOMM ’94, ACM, pp. 234–244. [186] P FOSER , D., B RAKATSOULAS , S., B ROSCH , P., U MLAUFT, M., T RYFONA , N., AND T SIRONIS , G. Dynamic travel time provision for road networks. En Proceedings of the 16th ACM SIGSPATIAL International Conference on Advances in Geographic Information Systems (New York, NY, USA, 2008), GIS ’08, ACM, pp. 68:1–68:4. [187] P IRZADA , A. A., P ORTMANN , M., AND I NDULSKA , J. Evaluation of multiradio extensions to aodv for wireless mesh networks. En Proceedings of the 4th ACM International Workshop on Mobility Management and Wireless Access (New York, NY, USA, 2006), MobiWac ’06, ACM, pp. 45–51. 190 BIBLIOGRAFÍA [188] P OPA , L., ROSTAMIZADEH , A., K ARP, R., PAPADIMITRIOU , C., AND S TOI CA , I. Balancing traffic load in wireless networks with curveball routing. En Proceedings of the 8th ACM International Symposium on Mobile Ad Hoc Networking and Computing (New York, NY, USA, 2007), MobiHoc ’07, ACM, pp. 170–179. [189] R ADHAKRISHNAN , S., R ACHERLA , G., S EKHARAN , C., R AO , N., AND BATSELL , S. Dst-a routing protocol for ad hoc networks using distributed spanning trees. En Wireless Communications and Networking Conference, 1999. WCNC. 1999 IEEE (1999), pp. 1543–1547 vol.3. [190] R AJAGOPALAN , S., AND S HEN , C.-C. Ansi: A swarm intelligence-based unicast routing protocol for hybrid ad hoc networks. Journal of Systems Architecture 52, 89 (2006), 485 – 504. Nature-Inspired Applications and Systems. [191] R AMESH K UMAR , R., AND DAMODARAM , A. Odasara: A novel on demand ant based security alert routing algorithm for manet in grid environment. IJCSNS 10, 4 (2010), 154. [192] R APPAPORT, T. Wireless Communications: Principles and Practice, 2nd ed. Prentice Hall PTR, Upper Saddle River, NJ, USA, 2001. [193] R AWASHDEH , Z., AND M AHMUD , S. Intersection collision avoidance system architecture. En Consumer Communications and Networking Conference, 2008. CCNC 2008. 5th IEEE (2008), IEEE, pp. 493–494. [194] R EINA , D., T ORAL , S., BARRERO , F., B ESSIS , N., AND A SIMAKOPOULOU , E. The role of ad hoc networks in the internet of things: A case scenario for smart environments. En Internet of Things and Inter-cooperative Computational Technologies for Collective Intelligence, N. Bessis, F. Xhafa, D. Varvarigou, R. Hill, and M. Li, Eds., vol. 460 of Studies in Computational Intelligence. Springer Berlin Heidelberg, 2013, pp. 89–113. [195] R IGGIO , R., M IORANDI , D., C HLAMTAC , I., S CALABRINO , N., G REGORI , E., G RANELLI , F., AND FANG , Y. Hardware and software solutions for wireless mesh network testbeds. Communications Magazine, IEEE 46, 6 (junio 2008), 156–162. [196] ROBINSON , W., AND L AUF, A. Resilient and efficient manet aerial communications for search and rescue applications. En International Conference on Computing, Networking and Communications (ICNC) (enero 2013), pp. 845– 849. [197] ROCHA , R., P ORTUGAL , D., C OUCEIRO , M., A RAUJO , F., M ENEZES , P., AND L OBO , J. The chopin project: Cooperation between human and robotic teams in catastrophic incidents. En IEEE International Symposium on Safety, Security, and Rescue Robotics (SSRR) (oct. 2013), pp. 1–4. [198] ROLADER , G. E., ROGERS , J., AND BATTEH , J. Self-healing minefield. En Defense and Security (2004), International Society for Optics and Photonics, pp. 13–24. [199] ROUSSOS , G., M ARSH , A., AND M AGLAVERA , S. Enabling pervasive computing with smart phones. Pervasive Computing, IEEE 4, 2 (enero 2005), 20–27. BIBLIOGRAFÍA 191 [200] RYAN -C OLLINS , J., S TEPHENS , L., C OOTE , A., M URPHY, M., AND F OUN DATION , N. E. The New Wealth of Time: How Timebanking Helps People Build Better Public Services. New Economics Foundation, 2008. [201] S AHA , D., AND M UKHERJEE , A. Pervasive computing: a paradigm for the 21st century. Computer 36, 3 (marzo 2003), 25–31. [202] S ALEET, H., BASIR , O., L ANGAR , R., AND B OUTABA , R. Region-based location-service-management protocol for vanets. IEEE Transactions on Vehicular Technology 59, 2 (febr. 2010), 917–931. [203] S ALEET, H., L ANGAR , R., NAIK , K., B OUTABA , R., NAYAK , A., AND G OEL , N. Intersection-based geographical routing protocol for vanets: A proposal and analysis. IEEE Transactions on Vehicular Technology 60, 9 (nov. 2011), 4560– 4574. [204] S BAI , M., S ALHI , E., AND BARAKAT, C. P2p content sharing in spontaneous multi-hop wireless networks. En Second International Conference on Communication Systems and Networks (COMSNETS) (enero 2010), pp. 1–10. [205] S CHAFFERS , H., KOMNINOS , N., PALLOT, M., T ROUSSE , B., N ILSSON , M., AND O LIVEIRA , A. Smart cities and the future internet: Towards cooperation frameworks for open innovation. En The Future Internet, J. Domingue, A. Galis, A. Gavras, T. Zahariadis, D. Lambert, F. Cleary, P. Daras, S. Krco, H. Müller, M.-S. Li, H. Schaffers, V. Lotz, F. Alvarez, B. Stiller, S. Karnouskos, S. Avessta, and M. Nilsson, Eds., vol. 6656 of Lecture Notes in Computer Science. Springer Berlin Heidelberg, 2011, pp. 431–446. [206] S CHRIER , K. L. Revolutionizing history education: Using augmented reality games to teach histories. PhD thesis, Massachusetts Institute of Technology, 2005. [207] S HIRAZ , M., G ANI , A., K HOKHAR , R., AND B UYYA , R. A review on distributed application processing frameworks in smart mobile devices for mobile cloud computing. Communications Surveys Tutorials, IEEE 15, 3 (marzo 2013), 1294–1313. [208] S ICHITIU , M. L. Wireless mesh networks: opportunities and challenges. En Proceedings of World Wireless Congress (2005), vol. 2. [209] S INGH , P. K., AND L EGO , K. Comparative study of radio propagation and mobility models in vehicular adhoc network. International Journal of Computer Applications (0975-8887) 16, 8 (2011). [210] S INTORIS , C., Y IANNOUTSOU , N., D EMETRIOU , S., AND AVOURIS , N. M. Discovering the invisible city: Location-based games for learning in smart cities. IxD&A 16 (2013), 47–64. [211] S IVAKUMAR , R., S INHA , P., AND B HARGHAVAN , V. Cedar: a core-extraction distributed ad hoc routing algorithm. IEEE Journal on Selected Areas in Communications 17, 8 (agt. 1999), 1454–1465. 192 BIBLIOGRAFÍA [212] S MALDONE , S., H AN , L., S HANKAR , P., AND I FTODE , L. Roadspeak: Enabling voice chat on roadways using vehicular social networks. En Proceedings of the 1st Workshop on Social Network Systems (New York, NY, USA, 2008), SocialNets ’08, ACM, pp. 43–48. [213] S MALDONE , S., H AN , L., S HANKAR , P., AND I FTODE , L. Roadspeak: Enabling voice chat on roadways using vehicular social networks. En Proceedings of the 1st Workshop on Social Network Systems (New York, NY, USA, 2008), SocialNets ’08, ACM, pp. 43–48. [214] S ÁNCHEZ , M., AND M ANZONI , P. Anejos: a java based simulator for ad hoc networks. Future Generation Computer Systems 17, 5 (2001), 573 – 583. I: Best of Websim99. II: Traffic Simulation. [215] S TORMONT, D. Autonomous rescue robot swarms for first responders. En Proceedings of the 2005 IEEE International Conference on Computational Intelligence for Homeland Security and Personal Safety, 2005. CIHSPS 2005. (marzo 2005), pp. 151–157. [216] S U , W., L EE , S.-J., AND G ERLA , M. Mobility prediction and routing in ad hoc wireless networks. International Journal of Network Management 11, 1 (2001), 3–30. [217] SUMO. Simulation of urban mobility (sumo), (http://sumo.sourceforge.net/). [218] S UN , J.-Z. Mobile ad hoc networking: an essential technology for pervasive computing. En International Conferences on Info-tech and Info-net, 2001. Proceedings. ICII 2001 - Beijing. (2001), vol. 3, pp. 316–321 vol.3. [219] S UN , W., YAMAGUCHI , H., Y UKIMASA , K., AND K USUMOTO , S. Gvgrid: A qos routing protocol for vehicular ad hoc networks. En 14th IEEE International Workshop on Quality of Service, 2006. IWQoS 2006. (junio 2006), pp. 130–139. [220] S UNG , M., D E VAUL , R., J IMENEZ , S., G IPS , J., AND P ENTLAND , A. Shiver motion and core body temperature classification for wearable soldier health monitoring systems. En Eighth International Symposium on Wearable Computers, 2004. ISWC 2004. (oct. 2004), vol. 1, pp. 192–193. [221] S UNG , M., G IPS , J., E AGLE , N., M ADAN , A., C ANEEL , R., D E VAUL , R., B ONSEN , J., AND P ENTLAND , S. Mit. edu: M-learning applications for classroom settings. Journal of Computer Assisted Learning (JCAL) (2004). [222] TANG , B., Z HOU , Z., K ASHYAP, A., AND CKER C HIUEH , T. An integrated approach for p2p file sharing on multi-hop wireless networks. En IEEE International Conference on Wireless And Mobile Computing, Networking And Communications, 2005. (WiMob’2005). (agt. 2005), vol. 3, pp. 268–274 Vol. 3. [223] T ONGUZ , O. K., AND B OBAN , M. Multiplayer games over vehicular ad hoc networks: A new application. Ad Hoc Networks 8, 5 (2010), 531 – 543. Vehicular Networks. [224] T OSATTO , C., AND G RIBAUDO , M. A 3d history class: A new perspective for the use of computer based technology in history classes. En Learning in the Synergy of Multiple Disciplines, U. Cress, V. Dimitrova, and M. Specht, Eds., BIBLIOGRAFÍA 193 vol. 5794 of Lecture Notes in Computer Science. Springer Berlin Heidelberg, 2009, pp. 719–724. [225] T SE , R., L IU , D., H OU , F., AND PAU , G. Bridging vehicle sensor networks with social networks: Applications and challenges. En IET International Conference on Communication Technology and Application (ICCTA 2011). (oct. 2011), pp. 684–688. [226] VARSHNEY, U. Vehicular mobile commerce. Computer 37, 12 (dic. 2004), 116–118. [227] V IDHALE , B., AND D ORLE , S. Performance analysis of routing protocols in realistic environment for vehicular ad hoc networks. En 21st International Conference on Systems Engineering (ICSEng). (agt. 2011), pp. 267–272. [228] V IDYA L, D., B RUCE , T., AND A DREW, M. Social computing goes mobile - a social computing report. Forrester Research (2007). [229] V IGNESH , N., S HANKAR , R., S ATHYAMOORTHY, S., AND R AJAM , V. Value added services on stationary vehicular cloud. En Distributed Computing and Internet Technology, R. Natarajan, Ed., vol. 8337 of Lecture Notes in Computer Science. Springer International Publishing, 2014, pp. 92–97. [230] WANG , B., C HEN , X., AND C HANG , W. A light-weight trust-based qos routing algorithm for ad hoc networks. Pervasive and Mobile Computing 13, 0 (2014), 164 – 180. [231] WANG , S.-S., AND L IN , Y.-S. Passcar: A passive clustering aided routing protocol for vehicular ad hoc networks. Computer Communications 36, 2 (2013), 170 – 179. [232] WANG , X., L IU , H., AND FAN , W. Connecting users with similar interests via tag network inference. En Proceedings of the 20th ACM International Conference on Information and Knowledge Management (New York, NY, USA, 2011), CIKM ’11, ACM, pp. 1019–1024. [233] WANG , Y., S TASH , N., S AMBEEK , R., S CHUURMANS , Y., A ROYO , L., S CHREIBER , G., AND G ORGELS , P. Cultivating personalized museum tours online and on-site. Interdisciplinary Science Reviews 34, 2-3 (2009), 139–153. [234] W EDDE , H., AND FAROOQ , M. The wisdom of the hive applied to mobile adhoc networks. En Swarm Intelligence Symposium, 2005. SIS 2005. Proceedings 2005 IEEE (junio 2005), pp. 341–348. [235] W EDDE , H. F., FAROOQ , M., PANNENBAECKER , T., VOGEL , B., M UELLER , C., M ETH , J., AND J ERUSCHKAT, R. Beeadhoc: An energy efficient routing algorithm for mobile ad hoc networks inspired by bee behavior. En Proceedings of the 7th Annual Conference on Genetic and Evolutionary Computation (New York, NY, USA, 2005), GECCO ’05, ACM, pp. 153–160. [236] W EISER , M. The computer for the 21st century. Scientific american 265, 3 (1991), 94–104. 194 BIBLIOGRAFÍA [237] W HAIDUZZAMAN , M., S OOKHAK , M., G ANI , A., AND B UYYA , R. A survey on vehicular cloud computing. Journal of Network and Computer Applications 40, 0 (2014), 325 – 344. [238] W ISCHHOF, L., E BNER , A., AND ROHLING , H. Information dissemination in self-organizing intervehicle networks. IEEE Transactions on Intelligent Transportation Systems 6, 1 (marzo 2005), 90–101. [239] W ISITPONGPHAN , N., BAI , F., M UDALIGE , P., AND T ONGUZ , O. On the routing problem in disconnected vehicular ad-hoc networks. En INFOCOM 2007. 26th IEEE International Conference on Computer Communications. IEEE (mayo 2007), pp. 2291–2295. [240] W U , J. A simulation study on using the Virtual Node Layer to implement efficient and reliable MANET protocols. PhD thesis, The City University of New York, 2011. [241] W U , J., G RIFFETH , N., N EWPORT, C., AND LYNCH , N. Engineering the virtual node layer for reactive manet routing. En 10th IEEE International Symposium on Network Computing and Applications (NCA). (agt. 2011), pp. 131–138. [242] X UE , Q., AND G ANZ , A. Qos routing for mesh-based wireless lans. International Journal of Wireless Information Networks 9, 3 (2002), 179–190. [243] YANG , L., AND WANG , F.-Y. Driving into intelligent spaces with pervasive communications. Intelligent Systems, IEEE 22, 1 (enero 2007), 12–15. [244] YANG , Y., AND BAGRODIA , R. Evaluation of vanet-based advanced intelligent transportation systems. En Proceedings of the Sixth ACM International Workshop on VehiculAr InterNETworking (New York, NY, USA, 2009), VANET ’09, ACM, pp. 3–12. [245] YASAR , A.-U.-H., M AHMUD , N., P REUVENEERS , D., L UYTEN , K., C O NINX , K., AND B ERBERS , Y. Where people and cars meet: social interactions to improve information sharing in large scale vehicular networks. En Proceedings of the 2010 ACM Symposium on Applied Computing (New York, NY, USA, 2010), SAC ’10, ACM, pp. 1188–1194. [246] Y UAN , J., Z HENG , Y., X IE , X., AND S UN , G. T-drive: Enhancing driving directions with taxi drivers intelligence. IEEE Transactions on Knowledge and Data Engineering 25, 1 (enero 2013), 220–232. [247] Z EADALLY, S., H UNT, R., C HEN , Y.-S., I RWIN , A., AND H ASSAN , A. Vehicular ad hoc networks (vanets): status, results, and challenges. Telecommunication Systems 50, 4 (2012), 217–241. [248] Z ENG , K., R EN , K., AND L OU , W. Geographic on-demand disjoint multipath routing in wireless ad hoc networks. En Military Communications Conference, 2005. MILCOM 2005. IEEE (oct. 2005), pp. 1–7. [249] Z HANG , Y., AND G ULLIVER , T. Quality of service for ad hoc on-demand distance vector routing. En IEEE International Conference on Wireless And Mobile Computing, Networking And Communications, 2005. (WiMob’2005). (agt. 2005), vol. 3, pp. 192–196 Vol. 3. BIBLIOGRAFÍA 195 [250] Z HAO , J., AND C AO , G. Vadd: Vehicle-assisted data delivery in vehicular ad hoc networks. IEEE Transactions on Vehicular Technology 57, 3 (mayo 2008), 1910–1922. [251] Z HOU , J., S UN , J., ATHUKORALA , K., W IJEKOON , D., AND Y LIANTTILA , M. Pervasive social computing: augmenting five facets of human intelligence. Journal of Ambient Intelligence and Humanized Computing 3, 2 (2012), 153– 166.