No obstante, las características que imponen las redes VANET en cuanto a topología dinámica, falta de procesamiento centralizado, … etc. dificultan el cumplimiento de estos requisitos de seguridad. La política de seguridad a aplicar en un entorno ad-hoc dependerá, en gran media, de la aplicación y del escenario concreto para los que se realiza el despliegue de la red.Las propuestas de seguridad deben adaptarse a las necesidades específicas que surgen en el planteamiento de una u otra red de comunicación. Para nuestro caso, redes VANET definidas sobre la teoría de redes ad-hoc, estas políticas de seguridad deberán cubrir básicamente cuatro requisitos: control de acceso a la red, sistema de detección de intrusos (SDI), seguridad de los protocolos de encaminamiento y servicios de gestión de claves. 

Estas políticas de seguridad deberán ser lo suficientemente robustas como para garantizar que un posible atacante sea incapaz de comprometer el sistema, entendiendo el papel de atacante como cualquier individuo o equipo que realice alguno de los siguientes ataques básicos (principalmente)

Ataques básicos :
- Falsificación de la información : El atacante difunde información falsa o errónea para que afecte al resto de los vehículos.
- Manipulación de la información del sensor: Modificar su posición, dirección, velocidad, etc. para escapar de ciertas responsabilidades por ejemplo, haber provocado un accidente.
- Denegación de servicio: utilizar un inhibidor de frecuencia para conseguir que un vehículo no reciba ninguna señal de su entorno en una cierta zona.
- Falsificación de identidad.
- Rastreado de vehículos: Seguir la pista de un vehículo infectándolo con algún virus que monitorice el estado de dicho vehículo.

Al igual que ocurre en redes tradicionales, las VANETs no quedan exentas de intrusiones externas y, por lo tanto, es necesario establecer un mecanismo de control de acceso a la red y sus servicios. Ante un ataque en el que un intruso acceda a los servicios de la red puede derivar en consecuencias catastróficas ya que, en las VANETs, los nodos asumen tareas de gestión y encaminamiento, dado que no existe una entidad central que asuma dicha responsabilidad. De esta forma, un intruso puede desviar el tráfico durante el encaminamiento o tener acceso a claves de identificación.

Tanto en la capa de red como en la de aplicación es necesario llevar a cabo un control de acceso que impida que un nodo sin autorización sea capaz de recibir o encaminar información (nivel de red) o que pueda acceder a servicios críticos como sería el de gestión de claves (nivel de aplicación).

Así pues, parece determinante ofrecer una política de control de acceso robusta. Veamos más detenidamente este aspecto.

Control de acceso

A través del control de acceso, un usuario puede acceder a la red y sus servicios tras un proceso de identificación y autorización. La forma en que se realiza este tipo de procesos depende en gran medida de las características de la red. Así, existen redes ad-hoc en la que los servicios de autenticación se encuentran centralizados, mientras que en otras redes estos servicios se encuentran distribuidos. Esto supone la aplicación de unos u otros mecanismos de control de acceso. Si elegimos un mecanismo de control de acceso distribuido para la red, será necesario un control de acceso basado en certificados digitales y autoridades certificadoras. En otros esquemas con servicios centralizados se requiere una autenticación basada en usuario y contraseña. Es muy útil hacer un estudio previo de las necesidades de seguridad de la red a desplegar, de esta forma, se podrán adecuar los mecanismos de control de acceso a la red.

Como primera línea de defensa, el control de acceso es una buena alternativa, sin embargo, debemos buscar soluciones en caso de que esta barrera se vea comprometida. Así, los sistemas de detección de intrusos (SDI) podrían protegernos en caso de que un individuo no autorizado accediera a la red.

Para las redes VANETs, se presentan varias propuestas SDI, veamos las más interesantes:

(SDI) Sistemas de detección de intrusos

Una solución basada en arquitecturas distribuidas y cooperativas para la detección de intrusos, es la que se propone en [YZWL 2000]. En este sistema, un agente de monitorización SDI lanzado en cada nodo monitoriza todas las actividades locales que ocurren a su alrededor. Si el SDI detecta una intrusión a partir de las trazas locales inicia un procedimiento de respuesta. Si se detecta una anomalía pero que no hay evidencias formales de la intrusión se usa un protocolo cooperativo con los vecinos para determinar si la intrusión tuvo lugar o no.

Otra alternativa, contemplada en [OKRG 2002], también presenta un SDI distribuido pero optimizado para las redes VANET. En este caso, cada nodo no ejecuta un agente de monitorización y control, sino que ofrecen el paso y alojamiento de agentes móviles -entidades software autónomas, ligeras y dinámicamente actualizables- que son capaces de desplazarse por la red y ejecutarse en ciertos nodos, de forma que minimizan el uso de los recursos, que en este tipo de redes suele ser limitado (ancho de banda, capacidad de proceso de los nodos…).

Es por ello que el empleo de técnicas de SDI debe realizarse previo estudio de las características de la aplicación y del escenario en el que ésta vaya a ejecutarse, debido a la sobrecarga que estos mecanismos pueden introducir, en términos de procesamiento, transmisión y almacenamiento en nodos. Si los requisitos de seguridad exigen fuertes técnicas de control y detección, y si los nodos disponen de suficiente capacidad y autonomía para soportar un SDI, entonces la elección y aplicación de este mecanismo de seguridad es justificable.

Cifrado y firmas digitales

Si optamos por utilizar técnicas de cifrado y firmas digitales como mecanismo de seguridad, tendremos que hacer uso de claves criptográficas. En esta situación, las claves criptográficas deberán ser compartidas entre los nodos y debe ofrecerse un mecanismo para gestionar dichas claves.
En este sentido, nos encontramos ante dos posibles configuraciones de nuestras redes VANET. Podemos permitir que nuestra propia red gestione de forma autónoma las claves, en cuyo caso nos encontraríamos con VANET auto organizadas; o bien podemos delegar dicha gestión a una entidad externa de confianza para la gestión de estas claves, VANET con gestión de claves externa.
En esquemas de VANETs pura, sin red de respaldo, es m´s apropiado usar un esquema de gestión de clave que no depende de ninguna entidad externa. En cambio, si se dispone de una red de respaldo, se puede optar por esquemas de tipos centralizados.
Las soluciones las mas populares son:

Para una red VANET pura:
- Gestión de claves en cadena de certificados.
- Gestión de claves basada en movilidad.

Para un red VANET híbrida:
- Autoridades de certifiación distribuídas.
- Gestión paralela de claves.

Gestión de claves en cadena de certificadosCada nodo genera su certificado, se distribuye y se almacena en cada
nodo de la red. Si un nodo deja de fiarse de otro nodo, se puede pedir una
renovación del certificado. Del mismo modo, si un nodo sospecha que su clave privada ha sido comprometida, puede revocar su propio certificado y generar otra clave privada.Gestión de claves basada en la movilidad 

Se basa en un esquema de distribución peer-to-peer de las claves de los nodos basada en la movilidad de cada nodo. Se transmite una clave a un nodo según la movilidad que tiene en un momento para que este nodo distribuya las claves a los nodos a su alcance. Se rompe así la necesidad de tener una entidad externa para compartir las claves.

Autoridades de certificación distribuidas

Se basa en una entidad externa de certificación que se encarga de distribuir las claves a los nodos de la red. Esta entidad debe ser altamente segura para que ningún atacante pueda tomar el control de ella y comprometer los mecanismos de certificación. Se puede distribuir los certificados de forma parcial o total.

En un mecanismo de distribución parcial de los certificados se elige un subconjunto de nodos llamados servidores a los cuales se transmiten las claves. Esos nodos deben disponer de una clave privada y una clave pública para que la entidad externa les pueda identificar de forma unívoca. Cada uno de los servidores genera una firma parcial utilizando su clave privada que es
enviada a un combinador, que puede ser cualquier servidor. El combinador reconstruye así la firma digital.

En un mecanismo de distribución total de los certificados, la clave se distribuye a todos los nodos de la red y requiere que un nodo use la entidad externa para contactar con cualquier vecino. No es necesario el concepto de combinador ya que será el propio nodo quién reconstruye la firma digital del grupo.

Gestión paralela de claves

Esta alternativa descrita en [SYRK 2004] se basa en una distribución parcial de los certificados por parte de una entidad externa y de un mecanismo de cadenas de certificados. La propuesta es conocida como Composite Key Management. La entidad externa distribuye el certificado a nodos servidores y luego tiene lugar el mecanismo de cadenas de certificados.

SOLUCIÓN ADOPTADA

Autorización de certificación distribuída

Apoyándonos en los trabajos de investigación de Alexandre Viejo, Francesc Sebé, Josep Domingo-Ferrer y Jesus Manjón, de la Universitat Rovira i Virgili (Comunicaciones Privadas en Redes Ad-hoc Vehiculares), optamos por un sistema de gestión de claves distribuído, gasado en agentes externos.

El sistema ofrecerá un mecanismo de seguridad y privacidad en el envío de mensajes siempre que los agentes externos que gestionan los identificadores (señales de tráfico, dispositivos específicos, nodos certificados, …) sean fiables. Así, estas señales están facultadas para revocar identificadores y alertar a la red sobre nodos de dudosa fiabilidad o cuyas intenciones son entorpecer y comprometer al sistema.

Se propone así un sistema basado en pseudónimos válidos firmados por autoridades de tráfico que permiten identificar a usuarios fiables y distinguirlos de aqueños que pudieran ser dañinos, en cuyo caso, su pseudónimo queda marcado como “rebocado”, y cualquier mensaje que envíe será automáticamente identificado como no seguro. El sistema, además, impone una política de renovación de pseudónimos para ofrecer al usuario un mayor nivel de privacidad, al exponer en menor grado el seguimiento y traceado por terceros.

Propuesta

Distinguimos en nuestra red VANET dos elementos principales:
i) Señales de tráfico o dispositivos específicos.
ii) Vehículos moviéndose por nuestra zona de cobertura.

Las señales de tráfico se consideran nodos estáticos y son gestionados por las autoridades de tráfico (DGT).

Suponemos que las señales de tráfico son nodos fiables, que no guardan información acerca de los nodos de la red ni realizan actividades dañinas en la misma. Estos nodos tienen la capacidad de generar y almacenar una clave privada SKt, gestionada por la autoridad de tráfico. La clave pública asociada es accesible, conocida y aceptada como válida por todos los demás nodos de la red.

Cada vehículo está equipado con un dispositivo no manipulable (similar a una tarjeta inteligente), que no puede ser desinstalado y que impide que el usuario modifique su identificación.

Transmisión de mensajes

Cuando transmitimos mensajes en nuestra red, ya sean mensajes de alerta o informativos, estos serán enviados siguiendo la técnica de difusión uno-a-todos. Así, una señal de tráfico puede indicar a la red la existencia de un nodo no fiable o deshonesto de esta forma. De la misma manera, los vehículos deben indicar cada cierto tiempo si siguen o no activos, a través de mensajes “hello-beacons”, que ayudan a gestionar la propia red VANET.

Los mensajes transmitidos vía broadcast por las señales de tráfico son de confianza, esto es, están correctamente firmados y no utilizan pseudónimo.

En cambio, los vehículos sí necesitan incorporar esta información en el envío de sus mensajes. Este pseudónimo IDnode está formado por la concatenación de cuatro valores, a los cuales se le aplica la firma SKt.

El primer campo es un valor v aleatorio. El segundo es una marca temporal que indica cuándo se generó dicho pseudónimo. Y los otros dos campos son las dos claves públicas del nodo (PKSnode, PKEnode), utilizadas para firmar y cifrar, respectivamente. Mediante el uso del sello temporal, podemos determinar, si ésta es más antigua que un cierto tiempo preestablecido, si es o no un mensaje válido.

La tarjeta inteligente del vehículo contiene su Idnode actual y las claves secretas SKs,node ,
SKe,node .
Gracias a estos datos, cualquier mensaje enviado por un vehículo es válido si su Idnode es un pseudónimo válido, esto es, si IDnode no ha sido marcado como “revocado”. Para los mensajes “hello_beacon”, aparte del pseudónimo, se transmiten las coordenadas GPS actuales del vehículo, así como otros posibles datos, todo ello firmado con SKs,node :

Obtención de un pseudónimo

Cuando una señal recibe un mensaje “hello_beacon” que contiene un pseudónimo caducado, es decir, el sello temporal ha expirado, ésta avisa al propietario del mensaje a actualizar su Idnode.

Para ello, el nodo sigue los siguientes pasos:

1. Generación de dos parejas de claves:

(SKSnode’ , PKSnode’ ) (SKEnode’, PKEnode’ )

2. El nodo genera un nuevo pseudónimo

*vRandom’, timeStamp’, PKSnode’ y PKEnode’ son valores nuevos, y firmados con SKt antigua.

3. El nodo envía el siguiente mensaje cifrado a la señal de tráfico

4. La señal de tráfico descifra el mensaje,verifica su contenido (en particular se ase-
gura que Idnode no ha sido revocado por un mal comportamiento anterior) y genera el mensaje firmado:

5. IDnode es enviado al vehículo cifrado bajo PKEnode’.6. El vehículo descifra el mensaje y obtiene su nuevo pseudónimo Idnode . 

El sistema descrito trabaja bajo el supuesto de que cada vehículo lleva implantado de fábrica un identificador inicial. Éste identificador es firmado con SKt, pero no es un IDnode válido. Será después, cuando se comunique con una señal, cuando el pseudónimo será actualizado.

Broadcast de mensajes coche-a-todos

Un usuario que quiere enviar una alerta a la red selecciona el mensaje a enviar, concatena el sello temporal y su pseudónimo y firma el mensaje entero utilizando su clave privada.

Un posible ejemplo de esta situación se daría cuando un coche, atrapado en un atasco, alerta a los coches cercanos sobre esta situación.
Al recibir el mensaje, los otros coches verifican la validez del pseudónimo. El mensaje se considera válido si el pseudónimo no ha sido revocado.
Las señales de tráfico tienen dos maneras de decidir si un usuario es deshonesto o no:

1. Se considera que un mensaje es falso si hay al menos i (parámetro de seguridad) mensajes de diferentes usuarios informando que un cierto mensaje es falso.

2. La segunda opción se basa en la posibilidad de que las señales de tráfico reciban información directamente de la autoridad de tráfico sobre situaciones peligrosas en la carretera. Un usuario que envíe información contradictoria con la fuente oficial será considerado como deshonesto.

Una vez una señal detecta a un usuario deshonesto, notifica a toda la red dicha situación mediante broadcast.

 

En términos simplificados, este tipo de pérdida de señal viene dada por la forma en que la onda se propaga, como podemos observan en la imagen. Por un lado, el receptor tiene una visión directa del emisor, a una distancia dlos, desde donde se recibe la señal, pero, por otro lado, la misma señal se ve reflejada sobre la tierra, con un cierto ángulo de reflexión, produciendo un retardo en la señal que origina un tipo de interferencia conocido como Two-Ray Interference, y que viene dado por la siguiente expresión:

Este tipo de pérdida de señal viene determinado directamente por el entorno en el que nos encontremos, con los obstáculos que se dibujen alrededor de cada vehículo y de su forma y composición. El valor de atenuación que nos impone cada uno de los obstáculos que pudiéramos encontrarnos podría determinarse empleando algoritmos basados en ray-tracing con gran exactitud y granularidad, sin embargo, podemos realizar aproximaciones basadas en medidas empíricas anteriores. En este caso, nos apoyaremos en los estudios realizados por Christoph Sommer & Co. Univ. of Eralngen, Germany [REF ] en el cual determinan que la pérdida de señal al atravesar un determinado obstáculo (un edificio común en un área urbana) tiene en cuenta el número de paredes que se atraviesan multiplicado por un factor de atenuación  (que para un edificio se aproxima a 9.6 dB) y el espacio interno multiplicado por un factor de atenuación  aproximado a 0.45 dB/m.

De esta forma, nos encontramos ante la siguiente expresión:

Con estos dos parámetros de atenuación a tener en cuenta definimos un entorno de simulación simple donde podamos comprobar dicha influencia en valores relativos dB. Para ello, situamos dos vehículos a una cierta distancia, uno de ellos fijos, y otro en movimiento, donde, en un determinado momento un obstáculo se interpondrá entre ambos, como muestra la siguiente figura:

 

El resultado de las mediciones es el siguiente:

Una vez comprobado que el modelo con obstáculos se comporta como esperamos, incluyendo los dos parámetros de atenuación comentados, el siguiente paso es llevar dichos valores al escenario con el que hemos venido trabajando hasta ahora.

En este sentido, podríamos incluirlos tanto en el escenario de grid manhattan como en el escenario real del campus universitario de Alcalá, sin embargo, dado que la definición de la estructura que representa los obstáculos es compleja de elaborar, para el escenario real del campus se hace demasiado laboriosa. No obstante, podemos obtener unos resultados concluyentes con el grid manhattan como observamos en las estadísticas que se presentan a continuación.

Para ello, hemos incluido en el grid manhattan una retícula de obstáculos en los espacios existentes entre las vías de circulación como se muestra en la siguiente imagen:

Estadísticas con obstáculos:

En las siguientes gráficas se muestran los resultados obtenidos con obstáculos, y los que se obtuvieron sin tenerlos en cuenta.
nº vehiculos tiempos medios
25 0,007209680001107 0,007072685627817
50 0,007617448143321 0,007199787745076
75 0,008395350651071 0,010987959991301
100 0,013129935217123 0,013574591837651
125 0,018938251818686 0,016334174503593
150 0,025972732589758 0,035179274952087
175 0,030080657313761 0,045466363075213
200 0,031529364457014 0,049251359616137
225 0,044340576195803 0,06505717896325
250 0,036982368803253 0,062109701641809
275 0,043089638515126 0,061436680713181
300 0,046655336079543 0,071436680713181

nº vehiculos no ciegos
25 2,52 89,92 89,16
50 4,51 90,98 91,84
75 5,45 92,7333333333333 90,02
100 12,62 87,38 86,25
125 19,16 84,672 85,09
150 35,43 76,38 66,42
175 44,33 74,6685714285714 51,04
200 48,03 75,985 35,35
225 99,03 55,9866666666667 14,08
250 104,13 58,348 16,66
275 144,8 47,3454545454545 21,89
300 141,73 52,7566666666667 23,78

velocidad (m/s) tiempos medios
5 0,048370934391316 0,048343629270837
10 0,055500794271592 0,061024494525718
15 0,063731446790672 0,062833164664556
20 0,05123674211268 0,053831343588155
25 0,052311978312052 0,053874989359417
30 0,042951989775603 0,0426030364312
35 0,044822091702791 0,041898096643327

Velocidad (m/s) nº vehiculos no ciegos
5 225 154,36 31,3955555555555 24,47
10 225 138,4 38,4888888888889 21,35
15 225 174,16 22,5955555555556 16,8
20 225 149,46 33,5733333333333 27,58
25 225 127,83 43,1866666666667 35,57
30 225 112,06 50,1955555555556 46,65
35 225 107,43 52,2533333333333 47,4

A continuación se presentan los resultados para diferentes pruebas:

Tiempo medio de recepción de mensaje de alerta (en función del número de vehículos)

nº vehiculos tiempos medios (segundos)
25 0,007072685627817
50 0,007199787745076
75 0,010987959991301
100 0,013574591837651
125 0,016334174503593
150 0,035179274952087
175 0,045466363075213
200 0,049251359616137
225 0,06505717896325
250 0,062109701641809
275 0,061436680713181
300 0,071436680713181

Observamos en estos resultados como, a medida que aumentamos el número de vehículos en circulación, aumenta el tiempo medio de recepción de los paquetes de alerta. Este resultado es lógico pues a mayor número de vehículos, mayor probabilidad de que un paquete deba atravesar más nodos de la red, con el consiguiente retardo que cada uno de ellos suma en el reenvío del mismo. No obstante, aunque pueda esto significar que para un aumento de vehículos el resultado global nos pueda parecer negativo, esto no es así como podremos ver a continuación.

Blind Vehicles – Número de vehículos ciegos que no reciben el mensaje de alerta (en función del número de vehículos)

nº vehiculos vehículos no ciegos % vehículos ciegos
25 2,71 89,16
50 4,08 91,84
75 7,48 90,0266666666667
100 13,75 86,25
125 18,63 85,096
150 50,36 66,4266666666667
175 85,68 51,04
200 129,3 35,35
225 193,31 14,0844444444444
250 208,35 16,66
275 214,8 21,8909090909091
300 228,64 23,7866666666667
Así, como comentábamos en la gráfica anterior, podría pensarse que un retardo mínimo, como el que se obtiene para un bajo número de vehículos en escena, sería preferible que un retardo algo mayor como el que tenemos si nos aproximamos a la centena de vehículos activos. Sin embargo, fijándonos en esta otra gráfica, donde se muestra el porcentaje de vehículos que no consiguen recibir el mensaje de alerta, la sensación global cambia, y nos damos cuenta de que aunque el retardo aumente, para 225 vehículos activos el número de vehículos ciegos disminuye por debajo del 25%.

Vemos por tanto una tendencia a la baja según aumentamos el número de vehículos en circulación. Esto se debe a que para pocos vehículos, los huecos existentes entre ellos impiden una cobertura amplia en la que difundir los mensajes, y mejora según aumenta la densidad de vehículos.

Pero cabe señalar un punto de inflexión existente en los resultados, a partir de la cifra 225 vehículos en circulación, donde comienza a aumentar lentamente el número de vehículos ciegos. Este hecho pone de manifiesto el problema de “broadcast storming” que se produce con un número grande de vehículos conviviendo en un determinado espacio.

Tiempo medio de recepción de mensaje de alerta (en función de la velocidad)

velocidad (m/s) tiempos medios
5 0,048343629270837
10 0,061024494525718
15 0,062833164664556
20 0,053831343588155
25 0,053874989359417
30 0,0426030364312
35 0,041898096643327

El siguiente resultado nos ofrece unos valores de eficacia de entrega, en tiempo medio de entrega, en función de la velocidad a la que se mueven los vehículos. Para realizar esta prueba hemos seleccionado el número de vehículos en circulación que ofrecía menor número de “blind vehicles”, esto es 225 vehículos en escena.

Observamos como para bajas velocidades (5 m/s) el tiempo medio de entrega es bajo, mientras que según aumentamos la velocidad hasta los 15 m/s dicho valor aumenta para volver a disminuir. Estos resultados, lejos de ser concluyentes, podrían darnos una idea de lo que realmente ocurre para diferentes velocidades.

Así, podríamos suponer que para velocidades próximas a 30 m/s (100 km/h aprox.) cada nodo puede estar facilitando la entrega a un nodo próximo que, de no ser por la velocidad a la que se mueve, dependería de un nodo intermedio para realizarla, con el consiguiente aumento de tiempo que esto conlleva. No obstante, estas conclusiones requerirían un estudio más profundo para extraer los motivos reales que originan estos tiempos de entrega.

Blind Vehicles – Número de vehículos ciegos que no reciben el mensaje de alerta (en función de la velocidad)

Velocidad (m/s) nº vehiculos vehículos no ciegos % vehículos ciegos
5 225 169,93 24,4755555555556
10 225 176,96 21,3511111111111
15 225 187,2 16,8
20 225 162,93 27,5866666666667
25 225 144,96 35,5733333333333
30 225 120,03 46,6533333333333
35 225 118,34 47,4044444444444

Como para las primeras gráficas, vemos cómo el número de vehículos ciegos nos ayuda a comprender mejor los resultados obtenidos sobre tiempos medios de entrega. Aún cuando suponíamos que para velocidades mayores el tiempo medio de entrega disminuía gracias a que esas velocidades favorecían dichos resultados, comparando con estos datos podemos deducir que esa disminución se debe a un número mayor de vehículos que no reciben dichos mensajes, es decir, a altas velocidades, un vehículo tiene mayor dificultad para alcanzar a sus vecinos. Esto es lógico si pensamos que éstos le acompañarán por menos tiempo debido a la rapidez con la que se mueven.

Además, como en la primera gráfica, aquí también podemos ver un punto de inflexión que devuelve un mayor número de vehículos ciegos según nos aproximamos hacia velocidades más lentas, a partir de los 15 m/s. Podría pensarse en esta gráfica como una simetría inversa de la anterior. En este caso, que los vehículos se muevan más lentamente hace que el problema de “broadcast storming” aumente, favoreciendo el incremento de vehículos ciegos.

ESTADÍSTICAS – MAPA CAMPUS EXTERNO UAH

Repetimos las mismas pruebas, pero esta vez para el escenario basado en el campus externo de la Universidad de Alcalá de Henares.

Tiempo medio de recepción de mensaje de alerta (en función del número de vehículos)

nº vehiculos tiempos medios
25 0,006970784380327
50 0,015033684924406
75 0,020233480086205
100 0,01832821694987
125 0,019000897152919
150 0,027706380111591
175 0,025834554016553
200 0,027218716558081
225 0,02595455744488
250 0,028664003185155
275 0,030286470339648
300 0,03243668071318

Blind Vehicles – Número de vehículos ciegos que no reciben el mensaje de alerta (en función del número de vehículos)

nº vehiculos vehículos no ciegos % Vehículos ciegos
25 6,78 72,88
50 22,8 54,4
75 38,5 48,6666666666667
100 63,3 36,7
125 95,53 23,576
150 113,53 24,3133333333333
175 113,26 35,28
200 145,6 27,2
225 176,36 21,6177777777778
250 188,76 24,496
275 211 23,2727272727273
300 228,64 23,7866666666667

Analizando conjuntamente la gráfica de tiempos medios de recepción de mensajes y el porcentaje de vehículos ciegos en escena, y comparándolo con los que obtuvimos en el escenario de “red manhattan”, podemos observar cómo en este caso el número de vehículos ciegos es menor, y que acusa una disminución más temprana de ellos frente a dicho escenario. Este hecho se debe principalmente a que en un escenario real, el número de caminos posibles que puede tomar un vehículo es mucho mayor que el que determina la rejilla manhattan, que obliga a un mayor número de vehículos a ir en una sola dirección (cuatro máximo), repartiendo de una forma más heterogénea a los vehículos y dejando un mayor hueco entre ellos (para manhattan) que para el caso real que se contempla en esta gráfica, en la que los vehícuos se distribuyen aleatoriamente, favoreciendo el alcance cuando hay pocos vehículos, y disminuyendo el problema de “broadcast storming” cuando crece.

Tiempo medio de recepción de mensaje de alerta (en función de la velocidad)

velocidad (m/s) tiempos medios
5 0,018167114012302
10 0,026948991491393
15 0,018931593578406
20 0,024597942705083
25 0,023744718627626
30 0,020520994142238
35 0,025668026274513

Si nos fijamos ahora en los resultados que obtenemos al variar la velocidad de los vehículos, observamos una gráfica poco definida, que no nos indica concreto, a priori, del hecho de aumentar o disminuir la velocidad máxima a la que se mueven los mismos. No obstante, es una gráfica coherente con las condiciones que un escenario aleatorio y heterogéneo como es que se sirve en la simulación impone. Al ofrecer tantas vías, con tantos cruces, la velocidad de los vehículos realmente no va a mantenerse constante y cercana al límite que hemos marcado, y, por tanto, no podemos extraer unos resultados válidos de dicha gráfica.

Blind Vehicles – Número de vehículos ciegos que no reciben el mensaje de alerta (en función de la velocidad)

Velocidad (m/s) nº vehiculos vehículos no ciegos % vehículos ciegos
5 225 183,33 18,52
10 225 136,93 39,1422222222222
15 225 177,93 20,92
20 225 161,63 28,1644444444444
25 225 168,4 25,1555555555556
30 225 167,3 25,6444444444444
35 225 157,56 29,9733333333333

De la misma forma, el gráfico que nos indica el número de vehículos ciegos genera valores incoherentes que llevan a confusión, aunque podemos deducir cierto aumento del número de vehículos ciegos a medida que aumentamos la velocidad de los vehículos, de la misma forma que ocurría en el escenario de manhattan.

Así, con este tipo de trazado, muy utilizado para diferentes operaciones heurísticas (“manhattan distance”), podremos obtener de los vehículos un comportamiento más irregular, aleatorio, variable y caótico. Más real, a fin de cuentas. 

Como describimos en un punto anterior, podemos realizar nuestras propias descripciones de caminos y vías de forma manual, mediante la definición de nodos, bordes y carriles. Para un escenario simple como en el que hemos llevado a cabo las simulaciones anteriores, dicha descripción es sencilla y rápida. Sin embargo, para el nuevo escenario que proponemos, el número de nodos aumenta, así como los bordes y carriles asociados, lo que conlleva un trabajo meticuloso y arduo. Para evitar la definición manual y ahorrar tiempo, podemos utilizar una serie de herramientas que automatizan este proceso.

Creación automática del archivo de red – MOVE

Así, una de las herramientas que permiten generar automáticamente el archivo que define el mapa de carreteras (*.net.xml), es la aplicación MOVE (MObility model generator for VEhicular networks). Podemos descargarla desde la página oficial (http://lens1.csie.ncku.edu.tw/wiki/doku.php?id=%E2%80%A7realistic_mobility_generator_for_vehicular_networks).

En nuestro caso, como habíamos comentado, crearemos un escenario basado en “rejilla manhattan”, en concreto definida por seis calles horizontales y seis calles verticales, con una separación entre ellas de cuatrocientos metros:

Para ello, situándonos en el directorio donde hemos descargado MOVE.jar, ejecutaremos MOVE de la siguiente forma:

java -jar MOVE.jar

Nos encontraremos entonces con la siguiente ventana:

Tras seleccionar “Mobility Model”, nos encontraremos con las siguientes opciones:

Tras seleccionar “Random Map” la aplicación nos presenta la opción de definir una serie de parámetros antes de generar el mapa aleatorio. Así, en nuestro caso, seleccionamos el método de generación basado en rejilla (“grid layout”), estableciendo el número de intersecciones vertical y horizontal igual a seis y una separación entre ellas de cuatrocientos metros. Establecemos el nombre de salida de nuestro archivo de red (“manhattan.net.xml”) y confirmamos.

El resultado es un archivo xml que contiene la descripción de dicha red, y que más tarde SUMO podrá interpretar adecuadamente:

 

Creación automática del archivo de rutas – JTRROUTER

Una vez disponemos del archivo de red con la rejilla manhattan, necesitamos generar el comportamiento de cada uno de los vehículos. De la misma forma que con la definición del mapa, o archivo de red de carreteras, podríamos ir carril por carril, intersección por intersección, para cada uno de los vehículos que vayamos a inyectar en nuestro escenario, realizar la descripción de rutas únicas que permitan concluir en una simulación más o menos aleatoria. Sin embargo, si la definicion manual del mapa era tediosa, la definición de rutas de esta forma lo es mucho más.

Por suerte, de la misma manera que existe una herramienta para generar de forma automática la descripción del archivo de red, existe otra aplicación que facilita y automatiza la generación del archivo de rutas. Se trata de JTRROUTER (http://sourceforge.net/apps/mediawiki/sumo/index.php?title=JTRROUTER), una aplicación que, mediante la entrada de diferentes archivos, genera el archivo de rutas que necesitamos.

En concreto, esta aplicación puede tomar como entrada el archivo de red (*.net.xml) que hemos generado anteriormente; un archivo de flujos, que establezca el número de flujos diferentes que podemos tener; un archivo de “giros”, que define las probabilidades de que un determinado vehículo tome una u otra trayectoria en una intersección; o un archivo de configuración global que jtrrouter interpreta y aplica en consecuencia.

Para nuestro caso, basta con el archivo de red (“manhattan.net.xml”), el archivo de flujos (“mahattan.flows.xml”) y el archivo de configuración (“manhattan.jtr.cfg”) que detallamos a continuación:

<configuration>
<input
net-file="manhattan.net.xml"
flow-definition="manhattan.flows.xml"
/>
<output
output-file="manhattan.rou.xml"
/>
<processing
continue-on-unbuild="true"
turn-defaults="25,25,25,25"
sinks="4/0to5/0"
/>
</configuration>

Mediante este archivo de configuración, indicamos a jtrrouter que deseamos generar un archivo de rutas para un mapa que se encuentra definido en “manhattan.net.xml” y que, mediante el archivo de flujos “manhattan.flows.xml”, cuyo contenido es el siguiente,

<flowdefs>
<flow id="flow0" from="0/5to0/4" begin="0" end="100" no="25" />
</flowdefs>

tenemos la intención de que las rutas que se generen partan desde el edge “0/5to0/4” y se aplique a un total de 25 vehículos, que serán generados entre el intervalo de tiempo 0 a 100 segundos.

Pero además, y lo que es más importante, y que es lo que otorga a nuestro escenario el carácter aleatorio y caótico, se encuentra en las últimas líneas. En concreto, “turn-defaults”, que indica la probabilidad de que un vehículo gire a la izquierda, a la derecha, al frente, o hacia atrás, y que establecemos en un valor de 25% (el valor “sinks” define el punto final en el que muere un vehículo).

Finalmente, ejecutaremos, en línea de comandos:

jtrrouter -c manhattan.jtr.cfg -t manhattan.turns.xml

El resultado es un archivo (“manhattan.rou.xml”) que podremos inyectar a SUMO, junto con el archivo de red (“manhattan.net.xml”) para generar la simulación en la rejilla manhattan.

net.nod.xml:

<nodes>
<node id="a" x="0.0" y="300" />
<node id="b" x="300.0" y="300" />
<node id="c" x="300.0" y="0" />
<node id="d" x="0.0" y="0" />
</nodes>

net.edg.xml:

<edges>
<edge id="ed_ab" fromnode="a" tonode="b" priority="1" nolanes="1" speed="11.111" />
<edge id="ed_bc" fromnode="b" tonode="c" priority="1" nolanes="1" speed="11.111" />
<edge id="ed_cd" fromnode="c" tonode="d" priority="1" nolanes="1" speed="11.111" />
<edge id="ed_da" fromnode="d" tonode="a" priority="1" nolanes="1" speed="11.111" />
</edges>

net.rou.xml:

<routes>
<route id="basica" multi_ref="x" edges="ed_ab ed_bc ed_cd ed_da ed_ab ed_bc ed_cd ed_da ed_ab ed_bc ed_cd ed_da ed_ab ed_bc ed_cd ed_da ed_ab ed_bc ed_cd ed_da ed_ab ed_bc ed_cd ed_da ed_ab ed_bc ed_cd ed_da ed_ab ed_bc ed_cd ed_da ed_ab ed_bc ed_cd ed_da"/>
<flow id="flujo_basico" route="basica" begin="50" end="500" no="10"/>
</routes>

A continuación, debemos implementar tanto en nuestra capa de aplicación como en el observador, las correspondientes funciones que permitan extraer el tiempo medio que tarda en llegar un mensaje a cada receptor, desde que el primer vehículo lo envía. Debemos tener en cuenta que este emisor realiza broadcast de un mensaje nuevo cada segundo y, por tanto, debemos diferenciar todos y cada uno de los mensajes que coexistan y calcular para cada uno de ellos su tiempo medio de recepción y promediar el total.

Para ello, crearemos un vector que vaya guardando los tiempos medios que van acumulándose para cada uno de esos mensajes, que podremos identificar mediante su campo de identificación único, y gracias al sello “timestamp” de inicio que también se almacena en los mensajes en su respectivo campo.

Así pues, el flujo de trabajo para obtener el tiempo de vida que tarda un mensaje en llegar a un determinado host sería el siguiente:

 

Partiendo de la configuración del ejemplo que anteriormente hemos modificado (en ella aparece una configuración de una carretera determinada), comprobaremos que el funcionamiento es correcto sobre una red simple como es un cruce en aspa:

 

Dentro de las simulaciones que llevemos a cabo, tendremos que contemplar tres archivos.

Por un lado, un archivo de definición de la propia red (red de vías), en la cual se definen los elementos que constituyen una determinada topología (vías, cruces, puntos de inicio y fin,…). Para nuestro caso, este archivo es “net.net.xml” (omitiremos el código por ser algo amplio).

Por otro lado, un archivo que define el comportamiento y la identidad de los propios vehículos. En nuestro ejemplo, “routes.rou.xml”. Este archivo identifica cada vehículo que aparecerá en el escenario, su velocidad, su inicio y su fin, los puntos intermedios por los que pasará, … Además, dado que trabajamos conjuntamente con el simulador OMNET++, debe existir una relación con el módulo que define un determinado nodo o host en él (en nuestro caso, se trataba del módulo “Car”. Observamos el código del cual se deducen los puntos aquí señalados:

<routes>
<vtype id="org.mixim.examples.mi_traci.Car;i=misc/node2;is=vs;r=0,,#707070,1" accel="2.6" decel="4.5" sigma="0.5" length="5" maxspeed="14" color="1,1,0"/>
<vehicle type="org.mixim.examples.mi_traci.Car;i=misc/node2;is=vs;r=0,,#707070,1" id="host[0]" depart="0">
<route id="always_right" multi_ref="x" edges="1i 4o 4i 2o 2i 3o 3i 1o 1i"/>
</vehicle>
<vehicle type="org.mixim.examples.mi_traci.Car;i=misc/node2;is=vs;r=0,,#707070,1" id="host[1]" depart="3">
<route id="always_left" multi_ref="x" edges="3i 2o 2i 4o 4i 1o 1i 3o 3i"/>
</vehicle>
<vehicle type="org.mixim.examples.mi_traci.Car;i=misc/node2;is=vs;r=0,,#707070,1" id="host[2]" depart="6">
<route id="horizontal" multi_ref="x" edges="2i 1o 1i 2o 2i"/>
</vehicle>
<vehicle type="org.mixim.examples.mi_traci.Car;i=misc/node2;is=vs;r=0,,#707070,1" id="host[3]" depart="9">
<route id="vertical" multi_ref="x" edges="3i 4o 4i 3o 3i"/>
</vehicle>
</routes>

Finalmente, descripción de red y descripción de comportamiento deben reflejarse en el simulador de redes OMNET++ a través de un tercer archivo de configuración. Este es un archivo de configuración de la propia simulación en el que se indica explícitamente el nombre de esos dos archivos, y los datos de conexión que necesitaría OMNET++ para comunicarse con el servidor SUMO-TRACI. Este archivo, que nosotros llamamos “sumo.sumo.cfg” contiene las siguientes líneas:

<configuration>

<files>
<net-file>net.net.xml</net-file>
<route-files>routes.rou.xml</route-files>
<remote-port>8888</remote-port>
<penetration>1</penetration>

<srand>88888</srand>
<abs-rand>false</abs-rand>
</files>

<simulation>
<route-steps>200</route-steps>
<begin>0</begin>
<end>86400</end>
</simulation>
</configuration>

Construyendo nuestras vías:

El caso anterior aprovechaba uno de las redes de ejemplo existentes dentro del simulador SUMO. A continuación, describiremos la forma de construir nuestras propias redes partiendo de descripciones realizadas mediante archivos xml. La idea es analizar el comportamiento futuro de nuestro sistema en redes complejas, partiendo de situaciones muy particulares y aisladas.

Así, comencemos con el caso básico en el cual necesitamos tener una vía de un único sentido y un único carril unidireccional.

En primer lugar, crearemos el archivo de descripción de nodos. En nuestro caso, lo llamamos “via_recta_ud.node.xml”.

 

La idea esquemática de la vía la mostramos en la anterior figura, y la descripción de este esquema, en términos xml, será la siguiente:

<nodes> <!-- The opening tag -->
<node id="0" x="0.0" y="0.0"/> <!-- def. of node "0" -->
<node id="1" x="500.0" y="0.0"/> <!-- def. of node "1" -->
</nodes> <!-- The closing tag -->

Por otro lado, uniremos los dos nodos mediante una configuración de vías determinada, otorgando un número de carriles por sentido, y el inicio y final de dichas vías.

<edges>
<edge id="0t1" fromnode="0" tonode="1" priority="1" nolanes="1" speed="11.11"/>
<edge id="1t0" fromnode="1" tonode="0" nolanes="1" speed="11.11"/>
</edges>

A partir de estos dos archivos descriptivos, crearemos el archivo de red propiamente dicho (.ned.xml), mediante la herramienta que toma como entrada ambos archivos y nos devuelve la red:

netconvert --xml-node-files=net.nod.xml --xml-edge-files=net.edg.xml --output-file=net.net.xml

Finalmente, necesitaremos un archivo de rutas, donde se describe el tipo de vehículo que circulará por las vías, su trayectoria y, opcionalmente, un flujo de vehículos que permite automatizar la creación de vehículos: (incluiremos directamente el tipo de vehículo para utilizarlo en omnetpp como nodo mixim-sommer)

<vtype id="org.mixim.examples.mi_traci.Car;i=misc/node2;is=vs;r=0,,#707070,1" accel="2.6" decel="4.5" sigma="0.5" length="5" maxspeed="14" color="1,1,1"/>
<route id="from0" multi_ref="x" edges="0t1 1t0"/>
<flow id="from0" type="org.mixim.examples.mi_traci.Car;i=misc/node2;is=vs;r=0,,#707070,1" route="from0" begin="1" end="5002" period="1"/>
</routes>