Mejora de los servicios de comunicaciones

Mejora de los servicios de comunicaciones

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.