nueva página del texto (beta)
Español (pdf)
Artículo en XML
Referencias del artículo
Traducción automática
Enviar artículo por email
Citado por SciELO 
Similares en
SciELO 
Permalink
1. Introducción
Las redes vehiculares ad-hoc episódicamente conectadas (Delay Tolerant Vehicular Ad-hoc Network, DT-VANET) son una tecnología que integra las capacidades de las redes inalámbricas ad hoc en los vehículos para proveer conectividad ubicua a los usuarios móviles mientras están en carretera, incluso cuando no haya acceso a infraestructura fija que permita conexiones de extremo a extremo conectando a usuarios y servidores. Las DT-VANETs pueden incorporar comunicación vehículo a vehículo (Vehicle-to-Vehicle, V2V), vehículo a unidades de asistencia en carretera (Vehicle-to-Roadside, V2R) y vehículo a infraestructura (Vehicle-to-Infrastructure, V2I) para dar soporte a un número cada vez mayor de aplicaciones de sistemas inteligentes de transporte (Intelligent Transportation Systems, ITS) [23,26] y de ciudad inteligente (Smart City) [1].
Las DT-VANETs y redes vehiculares ad-hoc regulares (Vehicular Ad-hoc Network, VANET) pertenecen a una subcategoría de las redes ad-hoc móviles (Mobile Ad-hoc Networks, MANET) porque comparten características generales como auto-organización, auto-administración y un limitado acceso al ancho de banda. Sin embargo, las VANET y las DT-VANETs presentan características únicas que incluyen el frecuente cambio de la topología de la red, la alta variación en la velocidad de los nodos, y restricciones en los patrones de movilidad impuestas por las calles y carreteras [5,24].
Debido a que en las VANETs y DT-VANETs los nodos son vehículos, en lugar de pequeños dispositivos portátiles, las VANETs se pueden distinguir aún más de otras formas de MANETs porque no tiene limitaciones en cuanto al consumo de energía, capacidad de almacenamiento, y poder de cómputo de los nodos.
Adicionalmente, en las VANETs y DT-VANETs los nodos tienen acceso a una variedad de sensores que producen información que puede ser usada en el proceso de enrutamiento, por ejemplo, un sistema de posicionamiento global (Global Positioning System, GPS) que provee al vehículo con su posición geográfica [15].
Las DT-VANETs se pueden distinguir aún más por una baja densidad de nodos y el hecho de que no asumen la existencia de caminos de extremo a extremo contemporáneos de origen a destino.
La comunidad clasifica a los protocolos de enrutamiento VANET en seis categorías [6,24]:
(I) protocolos basados en la topología (ad-hoc),
(II) protocolos basados en la posición,
(III) protocolos basados en grupos,
(IV) protocolos broadcast,
(V) protocolos geocast, y
(VI) protocolos multicast.
De las seis categorías antes mencionadas, los protocolos basados en la posición y geocast tienden a ser los predominantes. Además, estudios [5] indican que estos protocolos se desempeñan bien en las condiciones de alta movilidad de los nodos de las VANETs. Los protocolos geocast son aquellos que enrutan paquetes desde el nodo origen hacia todos los nodos que se encuentren dentro de un área geográfica destino. Los protocolos basados en la posición usan la información geográfica de los vehículos para decidir en cual dirección deben transmitir los paquetes de datos.
Generalmente, toman esta decisión de acuerdo a una heurística la cual selecciona al vehículo vecino que está más cerca del área destino [6]. Esta estrategia es llamada reenvío voraz (greedy forwarding).
La gran ventaja del greedy forwarding es que solamente depende de información local y la de sus nodos vecinos directos: su propia posición geográfica, la posición geográfica de los nodos vecinos, y la posición geográfica del área destino. Sin embargo, la desventaja de solamente usar información local es el riesgo de caer en un óptimo local, es decir, no poder encontrar un nodo vecino que se encuentre más cerca del área destino que el nodo actual.
Por esta razón, para solucionar esto se puede usar otra estrategia, llamada almacena-carga-y-transmite (store-carry-and-forward), el cual funciona de la siguiente forma: cuando un nodo queda atrapado en un óptimo local, el nodo actual almacena el paquete en memoria, y carga el paquete hasta que (i) se encuentra con un nodo más cercano a la región destino, o (ii) el nodo mismo llega a la región destino, en cualquiera de estos dos casos transmite el paquete [5].
La estrategia de enrutamiento store-carry-and-forward permite que los nodos actúen como nodos relevo inalámbricos y móviles que pueden almacenar, cargar, y esperar por una mejor oportunidad de contacto para transmitir los paquetes a nodos encontrados en el camino. Este comportamiento es ventajoso en ambientes episódicamente conectados. Varios tipos de tecnologías de red inalámbricas se benefician de la estrategia store-carry-and-forward: MANETs, VANETs, Wireless Sensor Networks (WSN), Inter-Planetary Networks (IPN), y redes vehiculares tolerantes al retardo o episódicamente conectadas (DT-VANETs) [27].
Dependiendo de la topología de la red, las redes vehiculares se comportan en dos formas distintas: (i) con una alta densidad de nodos muestra una topología conectada, y (ii) con una baja densidad de nodos muestra una topología episódicamente conectada. Por lo tanto, se pueden identificar dos categorías de redes vehiculares: redes vehiculares ad-hoc (VANETs) cuando hay una topología conectada, y en condiciones de baja densidad vehicular las redes vehiculares episódicamente conectadas.
Además, los protocolos de Internet comunes no pueden ser aplicados en cualquier ambiente porque esos protocolos fueron diseñados con ciertas suposiciones que las VANET no cumplen, como baja latencia y la existencia de un camino de extremo a extremo durante la duración completa de la comunicación. Es crucial crear protocolos de enrutamiento que pueden superar los desafíos presentes en las redes vehiculares [4].
En el contexto de Smart Cities y ITS, las redes vehiculares episódicamente conectadas pueden ayudar a descargar tráfico tolerante al retardo de redes de infraestructura, pero aún con mayor importancia, pueden como la plataforma de comunicación que conecta a una variedad de dispositivos compuestos por vehículos, dispositivos personales móviles, dispositivos del Internet de las Cosas (Internet of Things, IoT) instalados en edificios o en equipo de carretera, y la Nube (Cloud) [20].
Tradicionalmente, aplicaciones para esto emplean protocolos de enrutamiento geocast para VANETs (e.g., [9, 30]) para entregar información a grupos de nodos ubicados en una región geográfica destino especificada.
Desafortunadamente, la comunicación geocast tradicional no toma en cuenta el ámbito temporal de los datos, y por lo tanto, los datos solamente son entregados a los nodos que se encuentren dentro de la región destino en el momento en que los paquetes llegan. Esto es particularmente perjudicial para las comunicaciones tolerantes al retardo porque podría ser el caso de que en el momento no exista ningún nodo dentro de la Región de Interés.
Además de esto, cuando la red es episódicamente conectada, el conjunto de nodos que son el destino no está especificado porque el tiempo en que los nodos lleguen a la región destino es altamente impredecible. La comunicación de ámbito espacio-temporal, también llamada abiding geocast o time-stable geocast, resuelve este problema al definir de manera explícita el ámbito temporal de los mensajes de datos en términos de un intervalo de tiempo durante el cual un mensaje debe ser entregado a cualquier nodo dentro de la región destino.
En este artículo se presenta Oportunistic Greedy Routing over Street-layout Graph (OGRoSG), un protocolo de enrutamiento de ámbito espacio-temporal que, a diferencia de propuestas previas, no supone que los mensajes son generados dentro de la región destino (e.g., [2, 8, 10, 11, 16, 17, 21, 29, 31]) o la existencia de un protocolo de enrutamiento subyacente que se encargara de llevar los mensajes desde su origen hacia la región destino (e.g., [14, 18]). El protocolo propuesto aprovecha la información disponible en sistemas de navegación actuales para procesar árboles de caminos más cortos de grafos que representan el mapa de las calles.
Estos árboles de caminos más cortos tienen como raíz un componente conectado que incluye todos los nodos que representan las intersecciones de calles localizadas dentro de la región destino. Mientras los mensajes viajan por los aristas de estos árboles, los mensajes pueden llegar a la región destino desde cualquiera de las calles con acceso a la región. Además, en situaciones en las que no existan vehículos dentro de la región destino, OGRoSG usará estos árboles para mantener los mensajes lo más cerca posible a la región destino.
Nuestros resultados experimentales, realizados en simulaciones en el simulador de redes NS-3 que consideran trazas de movilidad generadas en un mapa de calles basado en la ciudad de Murcia, España, muestran que OGRoSG se desempeña bien. Obtiene un mejor porcentaje de entrega mientras produce la menor sobrecarga que un grupo de protocolos de ámbito espacio-temporal para redes vehiculares episódicamente conectadas (Epidemic, Spray & Wait yBinary Spray & Wait).
El resto de este artículo está organizado de la siguiente manera. La Sección 2 presenta una muestra del trabajo dedicado a enrutamiento de ámbito espacio-temporal. La Sección 3 presenta el modelo del sistema y la formulación del problema de enrutamiento de ámbito espacio-temporal en redes vehiculares episódicamente conectadas. La Sección 4 describe el protocolo propuesto, algunos algoritmos relacionados, y algunos teoremas que caracterizan su complejidad temporal. La Sección 5 presenta los resultados experimentales obtenidos y finalmente en la Sección 6 presentamos nuestras conclusiones.
2. Trabajo relacionado
En esta sección se presenta una muestra de los trabajos dedicados al análisis y diseño de protocolos de ámbito geocast espacio-temporal para redes vehiculares. Este análisis revela que los trabajos previos asumen que los mensajes de datos son generados dentro de la región destino, o que dependen de otro protocolo de enrutamiento geocast que entrega los paquetes en el área destino.
De acuerdo a estas suposiciones, los protocolos previamente propuestos en la literatura solamente se concentran en mantener los paquetes de ámbito espacio-temporal dentro de su región destino durante su tiempo de vida definido.
2.1. Protocolos que retienen los paquetes dentro de su región destino
En [10], los autores presentan un protocolo basado en la tecnología IEEE 802.11 que entrega mensajes de ámbito espacio-temporal a nodos localizados dentro de una región destino. Los nodos que cargan un mensaje de ámbito espacio-temporal definen de manera dinámica una región de transmisión que contiene la región destino original. El tamaño de la región de transmisión depende de la densidad vehicular percibida por cada nodo. El objetivo de tener una región de transmisión extendida es mejorar la probabilidad de que los nodos reciban el paquete antes de entrar a la región destino. Por cada región destino, el protocolo establece un único Identificador de Conjuntos de Servicios (Service Set Identifier, SSID), y los nodos dentro de la región destino forman un Conjunto de Servicio Básico Independiente (Independent Basic Service Set, IBSS).
Cuando un nodo en la región de transmisión detecta a un nuevo nodo dentro de su rango de comunicación, le transmite el mensaje. Si el nodo receptor no posee el mensaje, entonces verifica si está dentro de la región destino, y si lo está, pasa el paquete a las capas superiores y se une al IBSS. Los nodos mantienen los mensajes de ámbito espacio-temporal durante el tiempo que permanezcan en la región de transmisión y mientras el tiempo de vida del paquete no ha expirado.
En [29], los autores proponen un protocolo basado en temporizadores diseñado para diseminar y retener información de seguridad a lo largo de un tramo de calle bidireccional. Cuando un vehículo detecta una emergencia, comienza a emitir en broadcast un mensaje de advertencia para informar a los otros vehículos sobre el evento. Tras recibir el mensaje de advertencia, otros vehículos se convierten en retransmisores activos que son responsables de transmitir el mensaje de advertencia a los vehículos que viajan en la dirección opuesta. El protocolo también define una región de transmisión donde el mensaje de advertencia debe ser difundido. El cómputo de la región de transmisión supone que los arribos de los vehículos en ambos extremos del tramo de calle sigue una distribución de Poisson. Cuando los nodos reciben un mensaje desde un vehículo que viaja en la misma dirección, de manera dinámica calculan un tiempo de espera y esperan ese tiempo antes de realizar la próxima transmisión en broadcast. El cálculo de este tiempo de espera depende de la dirección y velocidad de los vehículos, además de sus posiciones relativas y la distancia hacia los bordes de la región de transmisión.
El protocolo Dynamic Time Stable Geocast (DTSG) [21] es también un protocolo basado en temporizadores diseñado para carreteras de dos sentidos. Al igual que los enfoques de los protocolos previos, el protocolo define una región de transmisión, que abarca la región destino original, donde los vehículos difunden los mensajes de ámbito espacio-temporal. El comportamiento dinámico del protocolo permite reducir, extender, o cancelar la duración de los paquetes. El protocolo tiene dos fases: pre-estable, la cual termina cuando el mensaje ha sido difundido a lo largo de la región destino; y la fase estable, la cual se encarga de mantener el mensaje en la región destino durante su tiempo de vida. En la fase pre-estable el vehículo fuente genera y transmite en broadcast un mensaje después de atestiguar un evento.
El vehículo fuente transmite el mensaje en broadcast de manera periódica hasta que al menos un vehículo auxiliar que viaje en sentido opuesto reciba el mensaje. Cada vez que un vehículo recibe un mensaje, inmediatamente después lo transmite en broadcast, y de esta manera confirma su recepción. El vehículo auxiliar periódicamente transmite el paquete en broadcast hasta que alcanza el final de la región destino, donde una región extra comienza. En este punto, el vehículo cambia la bandera de estado del mensaje a la fase estable. Después, comienza a transmitir el mensaje en broadcast nuevamente, hasta que mínimo un vehículo con dirección al evento recibe el mensaje. Entonces, el vehículo receptor deja de retransmitir el mensaje hasta que llega a la región extra; y una vez que ha llegado a la región extra, lo retransmite periódicamente hasta que recibe una confirmación de recepción. Este ciclo continúa hasta que el mensaje expira o es cancelado. El protocolo Traffic Light Time-Stable Geocast (T-TSG) [11] es una extensión del protocolo DTSG para entornos urbanos, el cual toma en cuenta el estado de los semáforos al momento de seleccionar los vehículos transmisores.
El protocolo Abiding Geocast for Commercial Ad Dissemination [16] también es un protocolo basado en temporizadores; este protocolo supone que una unidad de carretera (roadside unit, RSU) inicia la diseminación de un mensaje comercial (como publicidad). El proceso comienza cuando el RSU transmite un mensaje de publicidad (advertisement, ADV), el cual incluye la identidad de sus próximos dos nodos retransmisores.
Después, cuando un vehículo seleccionado recibe un mensaje transmitido por el RSU, y entonces espera a que transcurra un tiempo proporcional a su actual distancia hacia el centro de la región destino antes de efectuar una transmisión. Este mensaje también contiene la lista de los próximos vehículos retransmisores, seleccionados por el portador actual.
Si el portador actual recibe otra transmisión de un vehículo que viaje en la misma dirección y se encuentre adelante antes de que el temporizador expire, cancela su propio temporizador. Este proceso se repite hasta que el mensaje llega a los bordes de la región destino y mientras el tiempo de vida del mensaje esté activo.
En [2] los autores proponen Semantic and Self-Decision Geocast Protocol (SAS-GP), un protocolo basado en temporizadores en el cual los vehículos diseminan un mensaje de advertencia cuando se encuentran un accidente, para informar a otros vehículos localizados en el área afectada por el evento. Esta área, referida como Dominio Geocast Semántico (Semantic Geocast Domain, SGD), incluye todas las calles que lleven a la ubicación del evento, y su tamaño depende de la información de tráfico actual.
SAS-GP opera en tres fases: propagación, preservación y aseguramiento. Durante la fase de propagación, el paquete se disemina hasta los bordes de la SGD. Después, en la fase de preservación, el mensaje se retiene en el SGD durante el tiempo de vida del mensaje. El objetivo de la fase de aseguramiento es garantizar que el mensaje se entrega a todos los vehículos que se encuentran dentro del SGD.
En [31] los autores proponen Abiding Geocast protocol based on Carrier Sets (AG-CS), el cual divide el área destino en segmentos de calles cubiertos por un conjunto de vehículos portadores. Los vehículos en un conjunto portador almacenan y periódicamente retransmiten mensajes espacio-temporales. Estos vehículos son seleccionados por otros vehículos portadores de acuerdo a un índice de estimación de estabilidad, el cual es una función de la duración del enlace y la conexión.
En [8], los autores proponen un enfoque basado en temporizadores probabilísticos para retener los paquetes dentro de la región destino al retransmitir los mensajes de datos de manera periódica. El tiempo se divide en celdas, y al inicio de cada celda, de manera aleatoria el protocolo determina el próximo tiempo de transmisión dentro de la celda. El protocolo adapta las probabilidades de transmisión de acuerdo a la densidad de los vehículos en el vecindario. Controla el periodo de de transmisión de datos de acuerdo a la contribución del vehículo a la cobertura de la región destino; la contribución es proporcional al tamaño del área donde el rango de cobertura del vehículo no se traslapa con la de otro vehículo.
2.2. Protocolos que suponen la ayuda de un protocolo de enrutamiento geocast
En [17, 18], Maihofer et al. proponen tres estrategias para implementar enrutamiento geo-cast espacio-temporal: la estrategia de servidor, la estrategia de elección y la estrategia de vecinos. En la estrategia de servidor, los paquetes son transmitidos a un servidor geocast el cual es responsable de difundir la región destino. Alternativamente, el servidor geocast también puede transmitir paquetes bajo demanda como respuesta a solicitudes transmitidas por nodos dentro del área destino.
La estrategia de elección supone que trabaja en conjunto con un protocolo geocast subyacente, este protocolo geocast se encarga de llevar los paquetes al área destino. Después, de manera dinámica se elige a un nodo que se encuentra dentro del área destino, y este nodo elegido se encarga de almacenar y transmitir el mensaje a otros nodos que se encuentren dentro del área destino. Las transmisiones del nodo elegido pueden ser periódicas o por demanda. La estrategia de vecinos es similar a la estrategia anterior, pero en este caso, cada nodo dentro del área destino se encarga de almacenar y transmitir los paquetes a los nodos vecinos localizados dentro del área destino.
El protocolo Opportunistic Spatio-Temporal Dissemination (OSTD) [14] disemina información de eventos en una región geográfica destino durante el tiempo de vida del evento. El protocolo OSTD sigue un enfoque de suscripciones, en el cual los vehículos sólo reciben mensajes de los eventos de los temas a los que están suscritos. Al igual que enfoques anteriores, el protocolo OSTD supone que el paquete es generado dentro de la región destino o que hay un protocolo de enrutamiento geocast subyacente que se encarga de llevar el paquete desde su origen hasta la región destino, por ejemplo, el protocolo GeOpps [13].
El protocolo OSTD usa un esquema de múltiples réplicas de paquetes, y designa vehículos que cargan las réplicas, y periódicamente transmiten el mensaje en broadcast para cubrir las áreas donde es probable que se encuentren los vehículos destino. Cuando un vehículo que carga una réplica sale de la región destino, tiene que transferir su réplica a otro vehículo que entre a la región destino.
3. Modelo del sistema y formulación del problema
En esta sección se presenta la notación usada a lo largo de este artículo y se define una formulación precisa del problema de enrutamiento de ámbito espacio-temporal en redes vehiculares ad hoc episódicamente conectadas.
Sea GCALLES = (I,V) un multígrafo dirigido con pesos que describe la topología de las calles del área geográfica, donde I representa al conjunto de las intersecciones de las calles, V representa al conjunto de las calles, y el peso de los aristas (u,v) representa la longitud de la calle (en metros).
Sea GVANET(t) = (V(t),E(t)) un grafo dirigido variable en el tiempo que representa la topología de la VANET en el tiempo t, donde V(t) es un conjunto dinámico y dependiente del tiempo que representa a los vehículos y E(t) es un conjunto dinámico y dependiente del tiempo que representa los enlaces inalámbricos de comunicación que conectan a dos vehículos vu,vv ∈ V(t) en el tiempo t.
En este trabajo se supone que todos los vehículos están equipados con un Sistema de Navegación que incluye un receptor de GPS. Así, en todo momento, cada vehículo vu ∈ V(t) puede obtener sus propias coordenadas geográficas de posición y acceder al grafo GCALLES.
Un flujo de datos de ámbito espacio-temporal generado por un vehículo fuente es una secuencia de n mensajes de datos ⟨m1,m2,...,mn⟩. Cada mensaje mi tiene una longitud de |mi| bytes, y contiene la siguiente información:
– Un identificador único compuesto por la dirección IP (v4) del vehículo origen y un número secuencial.
– Una región geográfica destino de forma rectangular, denotada por D = {(x0,y0),(x1,y1)}, donde (x0,y0) y (x1,y1) son las coordenadas de las esquinas suroeste y noreste respectivamente.
– El ámbito temporal del mensaje, denotado por τ = (t0,t1), el cual es definido por el intervalo de tiempo que comienza en t0 y termina en t1.
– El número de saltos que el mensaje ha viajado hasta el momento, donde 0 significa que el mensaje está en el vehículo origen.
– Los datos a distribuir.
Se define M para denotar el conjunto de todos los mensajes de ámbito espacio-temporal generados por todos los vehículos fuente en la red.
Entonces, a partir de las definiciones anteriores, se define el problema del time-stable geocast en VANETs episódicamente conectadas como entregar todos los mensajes en M a todos los vehículos que en algún instante del periodo de tiempo τ, se encuentren dentro de la región destino D. Minimizando el retardo y la sobrecarga total; y maximizando el porcentaje de paquetes entregados a los vehículos destino.
Es importante hacer énfasis en que no siempre existirá un camino de extremo a extremo, por lo que es importante que el protocolo cuente con mecanismos tolerantes al retardo.
4. El protocolo Oportunistic Greedy Routing over Street-layout Graph (OGRoSG)
4.1. Resumen de operación
OGRoSG es un protocolo de ámbito espacio-temporal oportunista que aprovecha las oportunidades de contacto entre los vehículos para distribuir mensajes espacio-temporales hacia sus regiones geográficas destino correspondientes, para después retener los mensajes en su región destino durante su tiempo de vida. Para poder detectar las oportunidades de contacto anteriormente mencionadas, los vehículos transmiten a intervalos regulares pequeños paquetes HELLO.
Los vehículos enrutan los mensajes m de ámbito espacio-temporal hacia su región destino D siguiendo un árbol de caminos más cortos TD ⊆ GCALLES = (I,V) que tiene como raíz a un componente conectado que contiene todas las intersecciones iu ∈ I que se encuentran dentro de la región destino D. Al viajar en los aristas pertenecientes al árbol de caminos más cortos TD, una réplica del mensaje m puede alcanzar la región destino D desde cualquiera de las calles con acceso a D.
Además, la naturaleza voraz del protocolo asegura que durante el tiempo de vida de m, la región destino atraerá las réplicas de m. Una vez que una réplica de m llega a la región destino extendida D′, la cual contiene a D y al componente conectado de las intersecciones dentro de D, OGRoSG opera en modo epidémico [28] para informar a todos los vehículos sobre el mensaje m. Es importante notar que todos los vehículos que se encuentran dentro de la región destino D durante algún instante del ámbito temporal del mensaje τ son receptores destino, o receptores deseados, del mensaje m.
Durante una oportunidad de contacto, OGRoSG emplea un esquema de prioridad para determinar la prioridad de transmisión de los mensajes, y así transmitir primero el paquete con mayor prioridad de transmisión. Los paquetes de alta prioridad (aquellos que se encuentran dentro de su región destino) se transmiten antes que los de prioridad regular (aquellos fuera de su región destino). La prioridad de los paquetes se determina en base a las posiciones geográficas de los vehículos, las trayectorias de los vehículos transmisor y receptor, el número de saltos que el mensaje m ha viajado hasta el momento, y el número de vehículos del vecindario que tienen a m en su memoria.
Esta misma prioridad es usada para eliminar paquetes cuando la cola de paquetes se llena: el paquete con menor prioridad de transmisión es eliminado. Los paquetes también se eliminan cuando su tiempo de vida expira. Los vehículos usan la Evaluación de Viabilidad de un Vehículo Portador para transmitir mensajes solamente a vehículos relevo viables, los cuales son los vehículos que hacen progreso en el árbol TD hacia la región destino extendida D′.
Finalmente, con la finalidad de limitar la cantidad de recursos asignados a cada mensaje, OGRoSG restringe el número de réplicas de los mensajes que los vehículos pueden transmitir cuando están fuera de la región destino extendida.
4.2. Intercambio de paquetes
Para poder detectar las oportunidades de contacto y trabajar en equipo, los vehículos deben poder comunicarse y compartir información entre ellos. Por esta razón, OGRoSG usa un paquete de datos (DATA) y cinco paquetes de control:
– HELLO: Anuncia la presencia de un vehículo a los vehículos de su alrededor.
– REPLY: Respuesta a un HELLO. Contiene el Vector Resumen, el cual incluye los identificadores de los paquetes que el vehículo transmisor ofrece.
– REPLY_BACK: Respuesta a un REPLY. Contiene el Vector Disjunto, el cual incluye los identificadores de los paquetes solicitados por el vehículo transmisor.
– ACK: Transmitido para confirmar la exitosa recepción de un paquete DATA.
– DATA_ACK: Es la combinación de los paquetes ACK y DATA.
Con excepción del paquete HELLO, los demás paquetes contienen la información geográfica actual del vehículo: su posición y trayectoria.
El protocolo usa esta información para determinar si el nodo es un portador válido para el paquete de datos.
Este proceso es descrito posteriormente, en la Sección 4.3.
La Figura 1 ilustra el intercambio de mensajes que ocurre durante una oportunidad de contacto entre dos vehículos. Cuando dos vehículos, vu y vv, entran en rango de transmisión, se inicia una sesión de anti-entropía (Paso 1).
Fig. 1 Secuencia de paquetes intercambiados durante una oportunidad de contacto entre los vehículos vu y vv.
En la sesión anti-entropía los vehículos ignoran paquetes HELLO transmitidos en broadcast por vehículos cuyo identificador es menor.
En este ejemplo, el vehículo con identificador mayor (vehículo vv) ignora el paquete HELLO transmitido por por el vehículo con un identificador menor (vehículo vu).
Después, el vehículo vv transmite un paquete HELLO que no es ignorado y es procesado para iniciar el intercambio de paquetes de control.
Cuando un paquete HELLO es procesado, el protocolo inserta el identificador del vehículo que transmitió el paquete en una lista de vehículos vecinos contactados recientemente.
Con el fin de reducir el número de conexiones frecuentes redundantes, el protocolo no tiene contacto con los vehículos incluidos en esta lista. La duración las entrada de esta lista es configurable.
En el Paso 2, como respuesta al paquete HELLO transmitido por el vehículo vv, el vehículo vu transmite un paquete REPLY con su Vector Resumen
El Algoritmo 1 muestra el evento que se ejecuta cuando un vehículo vv recibe un paquete REPLY. Después, el vehículo vv almacena en memoria el Vector Disjunto del otro vehículo (
– Si |
– Si |
– Si |
En el Paso 4, el vehículo vv transmite un paquete REPLY_BACK que incluye su Vector Disjunto
En el Paso 5, después de que ambos vehículos conocen el Vector Disjunto del otro vehículo, entonces están listos para comenzar el intercambio de paquetes de datos. Para poder transmitir un paquete DATA, antes el vehículo transmisor vu debe seleccionar el paquete a enviar. Esta selección no es aleatoria; de los paquetes de datos contenidos en el Vector Disjunto del otro vehículo (
Cuando ocurre un empate en la prioridad de transmisión, alta o regular, el empate se rompe usando otra métrica llamada conteo de saltos. El paquete con el menor conteo de saltos tiene mayor prioridad de transmisión; la lógica detrás de esto es que los paquetes con menor conteo de saltos deben tener prioridad para viajar por la red y puedan ser difundidos. Si el empate aún persiste, entra en juego el número de vehículos que conocen al paquete; el paquete conocido por el menor número de vehículos tiene mayor prioridad de transmisión.
En este caso la motivación de esto es similar, dar oportunidad para que los paquetes menos conocidos tengan mayor difusión. Como se describe en la Sección 4.3, los vehículos siempre usan la Evaluación de Viabilidad de un Vehículo Portador para determinar si el vehículo receptor vv es un portador válido para el paquete antes de transmitirlo. Además, antes de transmitir el paquete, el vehículo vu también verifica si el contador de réplicas disponibles es mayor a cero, y si lo es, reduce el valor el contador en una unidad y transmite el paquete.
Cuando el vehículo vv recibe el paquete DATA trasmitido, incrementa el contador de saltos del paquete en uno, establece el contador de réplicas disponibles al máximo valor, y almacena el paquete en memoria. El Algoritmo 2 detalla el evento que ocurre cuando el protocolo recibe un paquete DATA. Esto completa el Paso 5.
Después, en el Paso 6, el vehículo receptor vv transmite una respuesta para confirmar la recepción del paquete DATA. Para esto, transmite un paquete ACK, que contiene el identificador del paquete DATA recibido, o un paquete DATA_ACK, que combina los paquetes ACK y DATA, solamente si también tiene un paquete de datos que enviar, es decir, cuando |
Finalmente, los vehículos repiten el Paso 6, enviando y recibiendo paquetes ACK, DATA y DATA_ACK, hasta que han intercambiado todos los paquetes de datos en
4.3. Evaluación de Viabilidad de un Vehículo Portador
Debido a que cada vehículo dispone de un número limitado de réplicas por cada paquete, para maximizar el impacto de cada réplica transmitida verifica la viabilidad de un vehículo receptor antes de transmitir una réplica. A continuación se describe el proceso que se ejecuta para determinar si un nodo receptor es un portador viable del mensaje m:
Usando el algoritmo descrito en la Sección 4.4, se procesa la región destino para generar la región destino extendida y un árbol de caminos más cortos con la región destino extendida como raíz. Las distancias que se utilizan en los pasos posteriores utilizan las distancias reportadas en el árbol de caminos más cortos.
Si cualquiera de los dos vehículos está dentro de la región destino extendida, entonces el vehículo receptor es un portador viable.
Si el vehículo receptor está más cerca de la región destino extendida que el vehículo transmisor, de acuerdo a las distancias en el árbol de caminos más cortos, y el vehículo receptor no se está alejando de la región destino, entonces el vehículo receptor es un portador viable.
Si el vehículo receptor está más cerca de la región destino extendida que el vehículo transmisor pero se está acercando hacia la región destino, entonces el vehículo receptor es un portador viable.
Dado que el vehículo receptor no cumple ninguna de las tres condiciones previas, entonces el vehículo receptor no es un portador viable.
El propósito del punto (2) es difundir las réplicas del paquete en la región destino y mantener estas réplicas en la región destino durante su tiempo de vida.
Mientras que los puntos (3) y (4) del proceso de Evaluación de Viabilidad de un Vehículo Portador aseguran que el protocolo logre enrutar los paquetes de datos hacia su región destino al seleccionar vehículos que están más cerca de la región destino extendida.
Además, los puntos (3) y (4) también se encargan de atraer paquetes a la región destino en caso de que no existan vehículos dentro de ella.
4.4. Región destino extendida y cálculo del árbol de caminos más cortos
Para calcular las distancias de los vehículos hacia el área destino, OGRoSG utiliza un árbol de caminos más cortos. Sin embargo, dependiendo de la topología de las calles, el simplemente computar un árbol de caminos más cortos podría crear situaciones desfavorables para la naturaleza voraz del enrutamiento geográfico que realiza el protocolo OGRoSG. La Figura 2 muestra un ejemplo del problema mencionado. El subgrafo generado a partir de los vértices y aristas del grafo GCALLES que se encuentran dentro de la región destino conforman un grafo desconectado, compuesto por dos componentes: {u,v} y {w}.
Fig. 2 Ejemplo visual del árbol de caminos más cortos, representado por los aristas azules, que tiene como raíz a la región destino, representada por el rectángulo verde. También muestra el subgrafo conformado por los componentes {u,v} y {w}, en rojo, que se encuentran dentro de la región destino
Entonces, si un vehículo transmisor tiene un mensaje destinado para la región destino coloreada en verde en la Figura 2, la naturaleza voraz del protocolo mantendrá aislado el mensaje en el componente {w}, con dificultades para llegar al componente {u,v}. Para que el mensaje pudiera ser llevado hacia el componente {u,v}, los vehículos tendrían que enviar el mensaje a vehículos que se encuentran más lejos de la región destino, lo cual va en contra del comportamiento voraz del protocolo (ver Sección 4.3).
Para solucionar el problema anteriormente descrito, se creó un algoritmo que procesa la región destino y el grafo de calles GCALLES. Este algoritmo es una pieza clave del protocolo OGRoSG, y es una solución innovadora, puesto que ningún protocolo del estado del arte hace un proceso similar. Este algoritmo genera una región destino extendida y un árbol de caminos más cortos con la región extendida como raíz, y se garantiza que dentro de la región destino extendida exista un subgrafo conformado por un solo componente conectado. De esta manera, la naturaleza voraz del protocolo fomenta que el mensaje sea difundido por toda la región destino.
A continuación se describen los pasos del algoritmo de procesamiento del grafo de calles y la región destino. La Figura 3 representa un ejemplo visual de los pasos del algoritmo. El algoritmo recibe como entrada la región destino D y el grafo de calles GCALLES = (I,V). La Figura 3(a) ilustra la entrada del algoritmo; el rectángulo verde con borde negro punteado representa la región destino D y el grafo dirigido representa a GCALLES, en este grafo los aristas sin dirección explícita son bidireccionales:
Fig. 3 Ejemplo visual del procesamiento de la región destino extendida y su correspondiente árbol de caminos más cortos. (a) El rectángulo verde con borde punteado negro delimita la región destino D. (b) - (h) Muestran los pasos del procesamiento. El rectángulo verde con borde sólido verde delimita la región destino extendida D′
Paso 1 A partir del grafo GCALLES = (I,V) se genera el grafo G′CALLES = (I,V′). G′CALLES contiene una copia idéntica del conjunto de nodos I. Y el conjunto V′ contiene los mismos aristas de V pero sin dirección. Por lo que G′CALLES es un multígrafo no dirigido con pesos. La Figura 3(b) muestra el grafo G′CALLES donde los aristas no tienen dirección.
Paso 2 Se define el conjunto de nodos IIN que contiene a todos los nodos que se encuentran dentro de la región destino D. Después, de entre los nodos del conjunto IIN se designa como icentroide al nodo que se encuentre más cercano al centro de la región D. La Figura 3(c) resalta los nodos pertenecientes a IIN en color rojo, y señala al nodo icentroide.
Paso 3 En el grafo G′CALLES se computan los caminos más cortos desde el nodo icentroide hacia los otros nodos en IIN. La Figura 3(d) muestra en color rojo los aristas que conforman los caminos más cortos, y en amarillo a los nodos fuera de la región D que forman parte de los caminos más cortos.
Paso 4 Se define el conjunto ISUPER que contiene a todos los nodos en IIN y también a los nodos que se encuentran fuera de la región D pero forman parte de los caminos más cortos computados en el paso anterior. Después, se genera la región destino extendida D′, la cual es el área de menor tamaño posible que contenga a la región destino D y a todos los nodos en ISUPER. La Figura 3(e) muestra a los nodos pertenecientes al conjunto ISUPER en color naranja y a la región destino extendida D′ en el rectángulo con borde verde.
Paso 5 Se define el conjunto de nodos I′ que contiene a todos los nodos en I que no están en ISUPER, es decir, I′ ← I \ ISUPER, y se agrega a I′ el nuevo nodo isuper, el cual es un nodo que representa a los nodos en ISUPER. La Figura 3(f) muestra los nodos del conjunto I′ en verde y la forma azul que representa al nodo isuper.
Después, se define un nuevo conjunto de aristas V′′ inicialmente vacío, el cual se construye a partir del conjunto V′. De esta manera, se inspecciona cada arista (iu,iv) ∈ V′:
– Si la arista (iu,iv) es incidente a dos nodos pertenecientes a ISUPER, es decir, iu ∈ ISUPER ∧ iv ∈ ISUPER, entonces esta arista no se agrega a V′′. La Figura 3(f) muestra a estas aristas en color rojo.
– Si la arista (iu,iv) no incide con ningún nodo perteneciente a ISUPER, es decir, iu ∉ ISUPER ∧ iv ∉ ISUPER, entones esta arista se agrega a V′′ conservando la misma longitud. Estas aristas aparecen en color negro en la Figura 3(f).
-
– Si únicamente un extremo de la arista (iu,iv) pertenece a ISUPER, ya sea iu ∈ ISUPER o iv ∈ ISUPER, entonces se modifica un extremo del arista al agregarlo a V′′, pero conservando la misma longitud (peso) de la arista.
La Figura 3(f) muestra a estos aristas en color amarillo.
Paso 6 Usando I′ y V′′ se genera un nuevo grafo GSUPER = (I′,V′′). La Figura 3(g) muestra el grafo GSUPER.
Paso 7 Finalmente, se ejecuta el algoritmo de Dijkstra [7] al grafo GSUPER con el nodo isuper como raíz, de esta manera se genera un árbol de caminos más cortos TD hacia la región destino D. La Figura 3(h) muestra el árbol de caminos más cortos TD con el nodo isuper como raíz, los aristas azules con dirección son los aristas que pertenecen al árbol TD.
4.5. Uso de réplicas de los paquetes de datos
OGRoSG usa un mecanismo para controlar el número de réplicas dispersas en la red, de esta manera se limita la cantidad de recursos de red y de cómputo asignados a los paquetes de datos. Los nodos de OGRoSG usan un número de réplicas configurable de L réplicas. OGRoSG solamente usa este contador para limitar el número de réplicas de paquetes fuera de su región destino, porque cuando un paquete está dentro de su región destino entonces el vehículo es un receptor deseado y el paquete es transmitido indiscriminadamente.
4.6. Complejidad temporal
En esta Sección se presentan el Teorema 1 y el Teorema 2 que caracterizan la complejidad temporal de los procesos más importantes que implementa el protocolo OGRoSG: determinar la viabilidad de un vehículo receptor y la generación de la región destino extendida y el árbol de caminos más cortos.
Teorema 1. La complejidad del proceso de determinar la viabilidad de un vehículo receptor, descrito en la Sección 4.3, es O(|V|).
Demostración. Calcular la distancia de los vehículos toma O(|V|), porque determinar el segmento de calle donde está localizado el vehículo toma O(|V|), y calcular la distancia de cualquier nodo a la raíz del árbol de caminos más cortos también toma O(|V|). Las demás operaciones se pueden procesar en tiempo constante.
Teorema 2. La complejidad del proceso de generar la región destino extendida y el árbol de caminos más cortos (ver Sección 4.4) es Θ((|V| + |I|)log|I|).
Demostración. Generar el grafo G′CALLES toma O(|V| + |I|), procesar IIN toma O(|I|), y encontrar el nodo icentroide toma O(|I|). Encontrar a los elementos de ISUPER toma Θ((|V| + |I|)log|I|) porque se puede aprovechar una sola ejecución del algoritmo de Dijkstra para encontrar y almacenar los caminos más cortos desde icentroide hacia todos los nodos en IIN. Encontrar los nodos que pertenecen a la región destino extendida toma O(|I|) porque involucra ejecutar operaciones máx y mín a conjuntos de números reales de cardinalidad O(|I|). El proceso de creación del conjunto V′′ en el Paso 5 puede ser implementado en O(|V|log|V|) si se usa un árbol binario de búsqueda equilibrado para almacenar el conjunto ISUPER. Por lo tanto, la complejidad general del proceso de generación de la región destino extendida y el árbol de caminos más cortos es Θ((|V| + |I|)log|I|).
5. Evaluación de desempeño
En esta sección se presentan los resultados de un conjunto de experimentos basados en simulaciones ejecutadas en NS-3 [19,22] y SUMO [3,12]. El mapa de movilidad (Figura 4) usado está basado en la ciudad de Murcia, España, y contiene algunas de las principales calles y avenidas de la ciudad real. El área del mapa es de 20 km2 (4 × 5 km) y la longitud total de las calles es de 164.6 km. Se generaron cuatro diferentes escenarios de densidad vehicular al variar el tiempo entre arribos de los mismos.
Además, la densidad vehicular es heterogénea en el mapa; la mitad norte del mapa tiene una mayor densidad vehicular que la mitad sur, para lograr esto la frecuencia entre arribos es menor en la mitad norte que en la mitad sur. La Tabla 1 contiene el número de vehículos involucrados en los cuatro escenarios de densidad vehicular. La Figura 4 también muestra las 10 regiones destino usadas en los 4 escenarios de densidad vehicular. El tamaño de las regiones destino varía desde 0.33 km2 a 0.92 km2.
Tabla 1 Número de vehículos en cada escenario de densidad vehicular de la ciudad de Murcia
| Densidad vehicular | Número de vehículos | |
| Máximos simultáneos | Total | |
| Baja | 173 | 234 |
| Media baja | 296 | 394 |
| Media alta | 311 | 418 |
| Alta | 339 | 466 |
En todos los escenarios, los vehículos están equipados con interfaces de radio inalámbricas IEEE 802.11b con un alcance máximo de transmisión de aproximadamente 250 metros. Esta selección tiene dos propósitos. El primer propósito es también considerar escenarios heterogéneos donde los nodos pueden ser vehículos, pero también permitir otro tipo de dispositivos, tal como dispositivos personales móviles que pueden ser transportados en los vehículos. El segundo propósito es obtener un desempeño base de los protocolos cuando se utilizan radios estándar.
Se compara el desempeño de OGRoSG contra el de variantes de ámbito espacio-temporal de Spray & Wait [25], Binary Spray & Wait [25] y Epidemic [28]. El código fuente de todos los protocolos está disponible en github1.
El funcionamiento de estos protocolos es el siguiente:
– Spray & Wait Espacio-Temporal: Los mensajes se diseminan usando Spray & Wait cuando están fuera de su región destino. Cuando llegan a su región destino, se diseminan de manera epidémica hasta que expira su tiempo de vida.
– Binary Spray & Wait Espacio-Temporal: Fuera de la región destino los mensajes se diseminan usando Binary Spray & Wait. Cuando los mensajes llegan a su región destino, se diseminan de manera epidémica hasta que su tiempo de vida expira.
– Epidemic Espacio-Temporal: Los mensajes se diseminan de forma epidémica hasta que expira su tiempo de vida.
En este trabajo se usan el porcentaje de entrega, retardo de entrega, sobrecarga de datos, sobrecarga de control, y sobrecarga total como métricas de desempeño:
– Porcentaje de entrega: Es el porcentaje de vehículos que estuvieron dentro de la región destino durante el tiempo activo del mensaje y recibieron el mensaje dividido entre el número total de vehículos que estuvieron dentro de la región destino durante el tiempo activo del mensaje.
– Retardo de entrega: Es el tiempo promedio que le toma a los vehículos recibir el mensaje después de haber entrado a la región destino durante el tiempo activo del mensaje. Si el vehículo llega a la región destino con el mensaje, entonces su tiempo de entrega es cero.
– Sobrecarga total: Es el número total de bytes transmitidos por todos los vehículos en la simulación dividido por el número de bytes de datos entregados exitosamente.
– Sobrecarga de control: Es el número total de bytes de control transmitidos por todos los vehículos en la simulación divido por el número de bytes de datos entregados exitosamente.
– Sobrecarga de datos: Es el número total de bytes de datos transmitidos por todos los vehículos en la simulación divido por el número de bytes de datos entregados exitosamente.
La Tabla 2 resume otros parámetros de simulación relevantes.
Tabla 2 Parámetros de simulación
| Configuración | Valor |
| Tiempo total de simulación | 600 segundos |
| Tiempo activo de los mensajes | 100 segundos |
| Intervalo entre transmisiones de paquetes HELLO | 1 segundo |
| Tamaño de la cola de paquetes | 128 paquetes |
| Interface Wi-Fi | IEEE 802.11b |
| Tasa de transmisión | 1 Mbit/s |
| Potencia de transmisión | 33 dBm |
| Umbral de detección de energía | -61.8 dBm |
| Rango de transmisión (aproximado) | 250 metros |
| Ejecuciones independientes de simulación | 30 |
| Intervalos de confianza | 95% |
| Versión de NS-3 | 3.29 |
Para todos los resultados presentados en esta sección, cada línea de color en las gráficas representa el promedio de la métrica representada en 30 ejecuciones independientes de la simulación, y el área matizada alrededor de cada línea representa el intervalo de confianza con un nivel de confianza del 95%. Se realizó un análisis de sensibilidad para determinar los valores adecuados para los parámetros de configuración de los protocolos rivales. Las leyendas de las gráficas incluyen entre paréntesis los valores de estos parámetros.
5.1. Evaluación de resultados variando la densidad vehicular
Para este conjunto de experimentos cambia la densidad vehicular para evaluar los protocolos bajo diferentes condiciones relacionadas a la longitud y frecuencia de las oportunidades de contacto que se presentan. En cada ejecución de la simulación hay 32 vehículos fuente, 16 de ellos se seleccionan uniformemente al azar entre los vehículos que visitan cualquiera de las regiones destino predefinidas. Tras su llegada a su región destino correspondiente, el vehículo fuente genera 32 mensajes de una longitud de 256 bytes. El ámbito temporal del mensaje, su tiempo activo, comienza en el instante en que el vehículo llega a la región destino y termina 100 segundos después, lo cual significa que los mensajes son generados dentro de su región destino y deben ser retenidos en ella durante 100 segundos.
Los 16 vehículos restantes son elegidos uniformemente al azar de los vehículos que no visitan una región destino. La región destino para estos vehículos se selecciona uniformemente al azar del conjunto de regiones destino predefinido. El tiempo activo de estos mensajes comienza 30 segundos después de que el vehículo arriba a la simulación y termina 100 segundos después, lo cual significa que deben ser llevados a su región destino y después retenidos ahí. Se realizaron 30 ejecuciones independientes para cada valor de densidad vehicular (bajo, con 234 vehículos totales participando en la simulación; medio bajo, con 394 vehículos totales; medio alto, con 418 vehículos totales; y alto, con 466 vehículos totales). La duración de cada simulación es de 600 segundos simulados.
De la Figura 5(a) se puede observar que OGRoSG supera a los demás protocolos, logrando entregar hasta 7% más mensajes. Esto indica que al usar la Evaluación de Viabilidad de un Vehículo Portador (ver Sección 4.3) para seleccionar vehículos relevo, el protocolo OGRoSG es capaz de aprovechar las oportunidades de contacto para transportar y retener en su región destino durante su tiempo de vida a los mensajes de ámbito espacio-temporal de manera efectiva. También se puede observar que Binary Spray & Wait Espacio-Temporal tiene un desempeño ligeramente superior al de Spray & Wait Espacio-Temporal.
Fig. 5 Desempeno variando la densidad vehicular. (a) Porcentaje de entrega, (b) Retardo de entrega, (c) Sobrecarga total, (d) Sobrecarga de control, y (e) Sobrecarga de datos
La razón de esto es debido a la forma en que Binary Spray & Wait Espacio-Temporal distribuye las réplicas que puede distribuir cada nodo, entregando la mitad en cada oportunidad de contacto, mientras que en Spray & Wait Espacio-Temporal solamente un vehículo se encarga de la distribución de las réplicas de los mensajes. Por la naturaleza de estos dos protocolos, un análisis detallado revelo que la mayoría de los mensajes que llegan a su región destino son generados por vehículos que se encuentran muy cerca o dentro de su región destino correspondiente. Finalmente, al figura también muestra que Epidemic Espacio-Temporal es el protocolo con peor desempeño y muestra una mayor variabilidad, esto se debe a que satura los recursos de la red por su naturaleza epidémica.
La Figura 5(b) muestra que Binary Spray & Wait Espacio-Temporal y Spray & Wait Espacio-Temporal obtienen los menores retardos de entrega. Sin embargo, como se discutió en el párrafo anterior, la mayoría de los mensajes que entregan a tiempo a su región destino correspondiente estos dos protocolos son generados por vehículos que están cerca o dentro de estas regiones. La figura también muestra que OGRoSG obtiene un mejor retardo que el protocolo Epidemic Espacio-Temporal.
Estos resultados indican que al transmitir paquetes de acuerdo a la Evaluación de Viabilidad de un Vehículo Portador reduce de manera efectiva el número de réplicas de los mensajes en la red, lo que reduce los retrasos experimentados de espera colas de paquetes.
De la Figura 5(c) se puede observar que consistentemente, los vehículos con OGRoSG transmiten menos bytes, por cada byte de datos recibido por un vehículo destino.
Al igual que en las métricas anteriores, la eficiencia mostrada por OGRoSG es debido a Evaluación de Viabilidad de un Vehículo Portador para seleccionar vehículos relevo, OGRoSG solamente entrega mensajes a vehículos que están más cerca de la región destino, y por lo tanto tienen mayores probabilidades de entregar el mensaje a los vehículos destino.
Lo cual contrasta con Epidemic Espacio-Temporal, el cual produce una sobrecarga hasta tres veces mayor.
Las Figuras 5(d) y (e) confirman la noción anterior. La Figura 5(d) muestra que OGRoSG consistentemente provoca una menor sobrecarga de control que los otros protocolos. Esto indica que OGRoSG aprovecha los bytes de control extra incluidos en los paquetes de control que contienen la posición y trayectoria de los vehículos para entregar los mensajes a los vehículos destino.
Finalmente, de la Figura 5(e) se puede notar que la sobrecarga de datos producida por OGRoSG es similar a la de los protocolos basados en Spray & Wait, los cuales limitan de manera estricta el número total de réplicas de cualquier mensaje en la red.
Como se puede esperar, esta figura también muestra que Epidemic Espacio-Temporal es el protocolo menos eficiente, obteniendo una sobrecarga hasta cuatro veces mayor que la de OGRoSG.
5.2. Evaluación de resultados variando el número de vehículos fuente
En este conjunto de experimentos evaluamos el desempeño de los protocolos mientras incrementamos el número de vehículos que generan mensajes de ámbito espacio-temporal.
El propósito de esto es evaluar la habilidad de los protocolos para adaptarse a una carga de tráfico mayor. Para estos experimentos se uso el escenario con alta densidad vehicular (466 vehículos totales) y se varía el número de vehículos fuente de 8 hasta 128. El resto de los parámetros de simulación son los mismos que en la sección anterior.
La Figura 6(a) muestra que Epidemic Espacio-Temporal obtiene un alto porcentaje de entrega bajo condiciones de una carga de tráfico baja, pero debido a su enfoque de fuerza bruta, su porcentaje de entrega cae drásticamente cuando más vehículos producen mensajes en la red.
Fig. 6 Desempeño variando el número de vehículos fuente. (a) Porcentaje de entrega, (b) Retardo de entrega, (c) Sobrecarga total, (d) Sobrecarga de control, y (e) Sobrecarga de datos
En general, el protocolo OGRoSG obtiene el mejor porcentaje de entrega, logrando entregar hasta 7% más mensajes que los protocolos variantes de Spray & Wait.
Como se mencionó en la sección anterior, la razón de esto es la forma en que OGRoSG selecciona los vehículos relevo a quien transmite réplicas de mensajes, la cual toma en cuenta la información geográfica y el mapa de las calles.
Los resultados presentados en las Figuras 6(b) a (e) son consistentes con los resultados de la sección anterior, es decir, que OGRoSG logra un retardo de entrega mejor que el protocolo Epidemic Espacio-Temporal pero con un costo de uso de red menor que los otros protocolos.
6. Conclusiones
En este trabajo se presentó OGRoSG, un protocolo de enrutamiento de ámbito espacio-temporal para redes vehiculares episódicamente conectadas que aprovecha información provista por el sistema de navegación de los vehículos, la información geográfica de los vehículos y el mapa de las calles, para seleccionar vehículos relevo de acuerdo a una Evaluación de Viabilidad de un Vehículo Portador.
De esta manera, los vehículos diseminan mensajes con ámbito espacio-temporal para informar a todos los vehículos que transitan en la región destino durante el tiempo de vida del mensaje.
OGRoSG es el primer algoritmo de enrutamiento para tráfico de ámbito espacio-temporal para redes vehiculares que no supone que existe otro protocolo el cual será encargado de llevar el paquete a su región destino. Para evaluar el desempeño de OGRoSG se realizaron experimentos basados en trazas de movilidad en la ciudad de Murcia, España.
Al constantemente conseguir entregar a tiempo más mensajes a los vehículos destino mientras causa la menor sobrecarga, se comprobó que tiene un mejor desempeño que versiones con ámbito espacio-temporal de los protocolos Epidemic, Spray & Wait y Binary Spray & Wait.
Estos resultados indican que la Evaluación de Viabilidad de un Vehículo Portador permite que OGRoSG seleccione vehículos relevo con probabilidades de llegar a la región destino.
Debido a su eficacia, OGRoSG puede dar soporte a aplicaciones de Ciudad Inteligente (Smart City) y de sistemas inteligentes de transporte (Intelligent Transportation Systems), las cuales requieren diseminación de información de posición y también información de ámbito espacio-temporal.
